NTN & the 5G Core
How NR-NTN plugs into an SA 5GC — discontinuous coverage, satellite-aware mobility and paging, regulatory/location services, and the mobility-registration behaviour a moving footprint forces.
Here is the reassuring part of Non-Terrestrial Networks: the core barely notices. With a transparent (bent-pipe) payload — the satellite just amplifies and forwards, see ntn-architecture — the satellite and its ground gateway together look to the 5G Core like an ordinary gNB that happens to sit at the far end of a very long, constantly changing propagation delay. So NR-NTN plugs into a normal Standalone (SA) 5G Core — AMF, SMF, UPF, AUSF, UDM, PCF — with relatively few core changes. Almost all the hard NTN engineering lives in the RAN and physical layer. This page is about the handful of 5GC behaviours that do have to adapt, grounded in TS 23.501 and TS 23.502.
Introduction
This page is about what the 5G Core Network (5GC) has to do differently when the radio link runs through a satellite instead of a ground mast. The headline is deliberately anticlimactic: for a transparent (bent-pipe) NR-NTN deployment, the Service-Based Architecture and its network functions — AMF, SMF, UPF, AUSF, UDM, PCF — are reused essentially unchanged from terrestrial NR SA.
The core sees a satellite deployment only through the ground gNB, which terminates the N2 (NGAP signalling) and N3 (user-plane GTP-U) interfaces on the ground exactly as a terrestrial gNB would. What reaches the 5GC is therefore a normal NG-RAN node — with one difference it cannot design away: the propagation delay is enormous and, for LEO, constantly changing. Every genuine 5GC adaptation for NTN traces back to that single fact.
Understanding this matters because it draws a clean line for engineers and exam candidates alike: know what stays identical (architecture, interfaces, authentication in principle) versus what must adapt (procedure timers, mobility and paging over moving cells, the AMF's location role, reachability under discontinuous coverage, and session continuity across switchovers). The rest of the page walks each adaptation, anchored in TS 23.501 and TS 23.502.
On this page
Why the 5GC must adapt
In plain words: imagine your office phone system suddenly routes every call through a colleague on the far side of the world who instantly relays it. You keep the same phones, the same extensions, the same procedures — nothing about the office changes. But every "are you still there?" check now has to wait for the round-the-world delay, and the person you are calling keeps physically moving. That is the 5GC's whole NTN problem: not new equipment, just patience and a way to keep track of who is where.
The 5GC does not adapt because the satellite is a new kind of node — in transparent NTN it deliberately is not one. It adapts because the one property the core cannot hide from is delay: a GEO round trip is hundreds of milliseconds and a LEO delay changes second by second. Three consequences follow, and they are exactly the adaptations below. Delay makes terrestrial-sized procedure timers fire early, so they must be dimensioned for NTN RTT. Moving satellites make cells and tracking areas sweep across a stationary UE, so mobility and paging must cope with coverage that itself moves. And a beam that spans borders means the network can no longer read geography off the cell, so the AMF's location role becomes central for regulatory compliance and PLMN selection.
To the core, the satellite is "just delay"
Start with the mental model that makes the rest obvious. In a transparent NR-NTN deployment the on-board payload does no protocol processing at all — no scheduling, no HARQ, no RRC. The real gNB is on the ground, next to (or reached through) the NTN gateway. The radio frames it transmits travel up the feeder link to the satellite, get frequency-converted and amplified, and come back down the service link to the UE. From the gNB's point of view it is serving a UE; from the core's point of view it is talking to a normal gNB over N2 and N3.
A transparent payload is an RF repeater. The gNB, the NGAP/N2 termination and the user-plane N3 tunnel to the UPF all live on the ground. The 5GC sees a standard NG-RAN node.
If the core treated the satellite as a network element it would need new interfaces and procedures for it. Keeping the satellite as a "dumb pipe" means Rel-17 could reuse the entire SA architecture and concentrate the new work in NR PHY/MAC and RRC.
The one thing the core cannot ignore is the size and variability of the delay: a GEO round trip is hundreds of milliseconds, and a LEO satellite's delay changes second by second as it races overhead. That single fact drives every 5GC adaptation below.
One line to remember: transparent NTN = "a gNB at the end of a long, moving wire." The 5GC keeps its architecture; it only has to become delay-tolerant, location-aware, and tolerant of moving cells.
Delay-tolerant timers
The most pervasive change is the least glamorous: timers. Many NAS and 5GC procedures start a timer when they send a request and expect a response within it. Those values were dimensioned for terrestrial round-trip times of a few milliseconds. Over GEO the one-way propagation delay alone can approach a quarter of a second, so a request-and-response can eat most of a second before anything has gone wrong. If the timers are left at terrestrial values, perfectly healthy procedures time out, retransmit, and fail.
The RAN handles its own long-delay problem with scheduling offsets and scaled timers (see ntn-timers), but the principle reaches up into the core too: NAS procedure timers and 5GC procedure timers must accommodate the NTN round-trip time so that registration, service request, PDU session and authentication exchanges survive the propagation delay. Concretely, the NAS mobility-management timers (the T35xx family in TS 24.501 that guard registration, service request and de-registration) and the session-management timers that guard PDU Session Establishment must have enough headroom that a reply crossing the satellite twice is not read as a lost message. The point is not that the core invents new logic — it is that the same procedures must run with delay budgets that make sense when a message spends hundreds of milliseconds in flight.
Where the delay bites: any request/response pair with a guard timer — NAS registration and service request, authentication, PDU session establishment. NTN keeps the procedures identical and lengthens the tolerances so a slow satellite link is not mistaken for a failure.
Mobility when the cells themselves move
Terrestrial mobility assumes the cells stand still and the UE moves. In LEO NTN this is turned on its head: the satellite — and therefore its beams and cells — sweep across the ground at thousands of kilometres per hour, while the UE may be sitting perfectly still. A stationary phone can watch cells and even whole tracking areas rise and set over the horizon in minutes.
The consequence for the core is that a UE which never moved can still trigger mobility signalling. As the serving cell's beam leaves it and the tracking area changes, the UE performs a Mobility Registration Update exactly as if it had walked into a new area — because, from the network's map, it has. The AMF must handle these registration-area changes and paging over coverage that is itself moving: an idle UE paged in a registration area must be reachable even though the cells realising that area are different satellites at different moments. To keep this manageable NTN leans on quasi-earth-fixed cells — beams steered to hold a fixed ground footprint for a while — and on tracking-area planning that maps to geography rather than to a given satellite, so a TAI stays meaningful as the constellation rotates beneath it. Cell and satellite handovers (covered in ntn-mobility) and the resulting registration handling (ntn-registration) are where this shows up.
Counter-intuitive but central: in NTN, "the UE is stationary" does not mean "no mobility signalling." Moving satellites make even a fixed sensor generate mobility registration updates and cell changes.
Location, country determination and the serving PLMN
On the ground, geography is implicit: a cell covers a small, fixed patch, so the country and the right serving PLMN are obvious. A satellite beam can straddle borders and cover enormous areas, so the network can no longer assume where the UE physically is from the cell alone. This matters for regulatory and lawful reasons — emergency call routing, lawful intercept, charging, and simply obeying the right country's rules — and for choosing a serving PLMN that is actually licensed to operate over that location.
The AMF supports network-verified UE location: the network confirms where the UE really is rather than trusting the beam or a UE-reported position.
Country determination drives regulatory and lawful-compliance obligations and the choice of a geographically appropriate serving PLMN. A beam covering three countries cannot be allowed to place a UE in the wrong jurisdiction.
The UE reports GNSS-derived position and the network verifies it (cross-checking against the satellite geometry and timing). The AMF uses the verified location for country determination and to admit or steer the UE onto the correct PLMN.
This is the single clearest example of a genuine core-function adaptation: the AMF's location role becomes central rather than incidental, because in NTN the network cannot infer geography from the radio topology. Mechanically it draws on the same location-services framework as terrestrial positioning — the AMF working with the location functions (LMF/GMLC) defined in TS 23.273 — but here the trigger is regulatory country determination rather than a lawful-intercept or app location request (see ntn-registration for how this threads into the registration procedure).
Discontinuous coverage and power saving
A dense GEO deployment offers continuous coverage, but a sparse LEO constellation may not. With too few satellites, there are windows where no satellite is above the horizon for a given UE — the link simply isn't there for minutes at a time. The network and UE therefore have to treat discontinuous coverage as a normal operating condition rather than an outage.
The practical answer is prediction and power saving. If the UE knows the satellite ephemeris (broadcast in system information — see ntn-sib19), it can compute when coverage will next appear and sleep until then instead of burning battery searching an empty sky. Rel-17 laid partial groundwork for this; Rel-18 adds enhanced discontinuous-coverage handling and power saving so the UE and network coordinate around predictable coverage gaps (see ntn-evolution).
Coverage as a schedule: because satellite passes are predictable, a "gap" is not a failure — it is a known interval the UE sleeps through and the network expects, rather than paging into the void.
PDU session continuity across switches
The user plane has its own continuity challenge. The feeder link between a satellite and its ground gateway is periodically switched to a new gateway as the satellite moves (a feeder-link switchover), and the UE is handed between satellites. Both events can change the ground path — and potentially the serving gNB — underneath an active session. The goal is that the UE's PDU session survives these switches without being torn down, so an ongoing data flow rides through feeder-link switchovers and satellite handovers. This is handled with the mobility procedures in ntn-mobility; the core's job is to keep the session context and user-plane path intact across the change — the SMF updating the N3 tunnel toward the (possibly new) gNB via the UPF, without a full session re-establishment.
What changes vs what stays the same
| 5GC aspect | Transparent NTN |
|---|---|
Overall SA architecture (AMF/SMF/UPF, SBA) | Stays the same — the satellite is a normal gNB path. |
N2/N3 interfaces and NGAP procedures | Stay the same — RAN terminates them on the ground. |
Authentication (AUSF/UDM, 5G-AKA) | Stays the same in principle. |
| NAS / 5GC procedure timers | Change — dimensioned for NTN round-trip time. |
| Mobility & paging | Adapt — moving cells/TAs, stationary-UE registration updates. |
AMF location role | Adapts — network-verified location, country/PLMN determination. |
| Reachability | Adapts — discontinuous coverage and power saving. |
| PDU session continuity | Adapts — survive feeder-link switch & satellite handover. |
TN ↔ NTN: in terrestrial NR the 5GC reads geography from the cell, sizes NAS timers for millisecond RTT, and sees mobility only when the UE physically moves. In transparent NTN the same NFs and the same N2/N3 interfaces are reused unchanged, but geography now comes from network-verified GNSS location, the NAS/SM guard timers gain NTN-sized headroom, and even a stationary UE generates mobility updates as cells sweep past. Nothing in the architecture changes; the operating assumptions do.
gNB terminates N2/N3, and the AMF takes on network-verified location.Deployment: NR-NTN on 5GC, IoT-NTN on EPC
One deployment fact is worth stating plainly, because it is a common exam trap. Rel-17 NR-NTN targets Standalone operation on the 5G Core. The parallel Rel-17 IoT-NTN work — NB-IoT and eMTC over satellite — is built on the LTE air interface and typically uses EPS/EPC, not the 5GC (see ntn-iot). So "NTN uses the 5G Core" is true for NR-NTN but not for IoT-NTN, which stays on the evolved packet core it inherited from LTE-M/NB-IoT.
⚠ Common pitfalls / gotchas
- Assuming the satellite is a network element. In transparent NTN it is an RF repeater — the
gNB,N2andN3all live on the ground, so looking for satellite-specific 5GC interfaces is a wrong turn. - Leaving NAS/SM timers at terrestrial values. Over GEO a healthy registration or PDU-session exchange can exceed a terrestrial guard timer, so unscaled timers cause spurious retransmissions and procedure failures on a working link.
- "Stationary UE, no mobility." Moving LEO cells mean a fixed UE still triggers Mobility Registration Updates and cell changes; provisioning for zero mobility signalling on fixed devices underestimates core load.
- Inferring country from the cell. A beam can span borders, so relying on cell identity for regulatory country determination or PLMN selection is unsafe — NTN requires network-verified location.
- Conflating NR-NTN and IoT-NTN cores. NR-NTN runs on 5GC (SA); IoT-NTN typically runs on EPC — assuming both use the 5G Core is the classic trap.
Q. Why does transparent NTN need so few 5GC changes?
A. Because a transparent (bent-pipe) payload does no protocol processing — the gNB, N2 and N3 all terminate on the ground, so the core just sees a normal NG-RAN node. The only thing it must absorb is the large, time-varying propagation delay, which mostly means dimensioning timers and adapting mobility, location and reachability — not redesigning the architecture.
Q. Which core function handles location and regulatory compliance in NTN, and why is it needed?
A. The AMF, via network-verified UE location. Satellite beams can span borders, so the network can't infer geography from the cell. Verified location lets the AMF do country determination for regulatory/lawful compliance and select a serving PLMN that is licensed over that location.
Q. Why might a completely stationary UE trigger core mobility signalling?
A. Because in LEO the cells move, not the UE. As satellites sweep overhead, the serving cell and tracking area change, so a fixed UE performs a Mobility Registration Update and cell changes just as a moving terrestrial UE would. The AMF handles the registration-area change and paging over the moving coverage.
Summary
For transparent NR-NTN the 5GC is reused, not redesigned. The SA architecture and its NFs (AMF, SMF, UPF, AUSF, UDM, PCF), the N2/N3 interfaces and NGAP procedures, and authentication (5G-AKA via AUSF/UDM) all stay the same, because the satellite is an RF repeater and the real gNB terminates everything on the ground. The core's only unavoidable problem is delay — large for GEO, time-varying for LEO.
That one fact drives five adaptations: NAS and 5GC procedure timers dimensioned for the NTN round trip; mobility and paging that cope with moving cells and stationary-UE registration updates; a central AMF location role using network-verified GNSS position for country determination and PLMN selection; discontinuous-coverage handling and power saving driven by predictable satellite passes; and PDU session continuity across feeder-link switchovers and satellite handovers. And one deployment line to keep straight: NR-NTN runs on the 5GC (SA); IoT-NTN typically runs on the EPC.
Where the core meets NTN next
You now know the 5GC absorbs NTN mostly as delay, moving cells and a bigger location role. Follow those threads into how registration actually runs over a satellite, how sessions survive handovers, and how later releases sharpen all of this.