GNSS, Location Verification & Tracking Areas in 5G NTN
Why the NTN UE needs GNSS, how large satellite footprints map onto tracking areas and countries, location-based PLMN/cell selection, and network location verification.
A terrestrial cell covers a neighbourhood; a single NTN beam can cover a whole country — or several. That one change breaks a pile of assumptions the 5G core quietly relies on: that a cell sits in one Tracking Area, in one country, run by one operator. To put those assumptions back together, NTN leans on two things the UE always has: a mandatory GNSS receiver giving it its own position, and cells that broadcast a set of geographically-mapped Tracking Area Codes. This page is grounded in TS 23.501 / TS 23.502 (5G system and procedures) and TS 38.304 (idle-mode UE procedures).
Introduction
Registration is the NAS procedure by which a UE makes itself known to the 5G core — it authenticates, is assigned a Registration Area, and becomes reachable for paging and callable for sessions. In NTN it is the moment where the network pins a UE that could be anywhere under a country-sized beam to a specific, lawful place: a fixed Tracking Area, a country, and a permitted operator.
It happens right after the UE has selected a cell and completed random access and RRC setup: the very first uplink NAS message the UE sends (Registration Request) rides inside RRCSetupComplete. From then on, mobility (Tracking Area Updates), reachability (paging), charging and lawful intercept all hang off the location established here — which is why getting NTN registration right is a regulatory concern, not just a connectivity one.
Because registration is a defined signalling exchange — connect, send the NAS request, authenticate, receive accept — a failure lives in one identifiable step. In NTN the extra failure modes cluster around location: a missing GNSS fix, a wrong fixed-TA selection, or a location the network cannot verify. Walking the steps tells you which of those bit you.
On this page
Why NTN registration is needed
In plain words: checking into a hotel from a normal street address is easy — the receptionist knows the neighbourhood, the city and the country from the building you walked into. NTN registration is like checking in from inside a hot-air balloon that is drifting over three countries at once: "which building" tells the desk nothing. You have to show your GPS coordinates so they can work out which country you are actually over, which desk is even allowed to serve you, and how to send a message to your balloon later.
Concretely, registration exists so the core can answer three questions it cannot answer from the cell alone in NTN: where is this UE (which fixed Tracking Area and country), who may serve it (which PLMN holds the licence there), and how do we reach it later (which Registration Area to page across). Terrestrial 5G reads all three off the tiny cell the UE camped on. An NTN beam is too big for that, so registration must fold in the UE's GNSS position — and, because the answer has legal weight, must be able to verify that position rather than trust it blindly.
The NAS procedure that authenticates the UE and binds it to a fixed geographic Tracking Area, a country and a permitted PLMN, then makes it reachable via paging.
A country-sized beam cannot imply location the way a small terrestrial cell does. Location, operator rights, charging and lawful intercept are all national, so the core must establish exactly where the UE physically is.
The UE maps its GNSS fix onto one of the fixed TACs the cell broadcasts, sends a Registration Request for that TAI, authenticates, and receives a Registration Accept with its Registration Area — optionally after the network verifies the reported location.
Why an NTN UE must have GNSS
In terrestrial 5G a phone never needs to know where it is to attach. In NTN it does — GNSS support is a baseline requirement for an NR-NTN UE, not an optional extra. There are three independent reasons, and any one of them would be enough on its own.
The UE must acquire its own position (and precise time) from a global navigation satellite system before it can use an NTN cell — GNSS is assumed alongside the NR modem.
It needs its position to pre-compensate the huge propagation delay and Doppler of the service link, and to work out which geographic area (and country) it is actually in for correct cell/PLMN selection and for regulatory compliance.
It combines its GNSS fix with the satellite ephemeris and common timing broadcast in SIB19 to compute a UE-specific timing advance and frequency offset, and to map itself onto a fixed geographic Tracking Area.
The first two reasons are physical. The satellite is hundreds to thousands of kilometres away and moving fast, so the round-trip delay is enormous and the Doppler shift is large. Rather than have the network chase these, the UE computes its own timing advance and Doppler pre-compensation from "where the satellite is" (ephemeris, from SIB19) minus "where I am" (GNSS). Without a position fix the UE simply cannot line up its uplink. The third reason is regulatory and topological: because one beam spans huge areas, the UE's location is what decides which Tracking Area, which PLMN, and which country it should be treated as being in.
The big-footprint problem
A terrestrial macro cell is a few kilometres across, so the long-standing simplification "one cell belongs to one Tracking Area Code (TAC), in one country, under one operator" holds effortlessly. An NTN beam can be tens to hundreds of kilometres across. A single satellite cell can therefore straddle many Tracking Areas, and near borders it can cover parts of several countries at once. That is a genuine problem, not a cosmetic one:
- Registration: the core uses the TAC a UE reports to decide the Registration Area and where to page it. If a giant cell advertised a single TAC, that TAC would be meaningless as a location.
- Regulatory / lawful: spectrum licences, lawful intercept and emergency services are national. The network must know which country a UE is really in — "somewhere under this beam" is not an acceptable answer.
- Operator selection: different operators may hold the rights in different countries under the same footprint, so which PLMN a UE may use depends on where it physically sits.
So NTN cannot keep the naive "cell = TAC = country" mapping. The fix is to make Tracking Areas stay tied to geography even when the radio cell that serves them is enormous and, for LEO, moving.
Keeping Tracking Areas geographic
The mechanism is to decouple the fixed geographic Tracking Area from the moving radio cell. An NTN cell can broadcast multiple TACs — a list, one per fixed geographic Tracking Area that currently falls under its footprint. The UE then uses its GNSS position to decide which of those fixed areas it is actually in, and treats that fixed TA (and its country) as its location. Registration and paging are anchored to the fixed geographic area, not to whichever satellite cell happens to be overhead.
The consequence for mobility is subtle but important. With earth-moving beams, a stationary UE will see the broadcast TAC list change as satellites pass, because a different cell now covers its patch of ground. If the UE registered on the raw cell TAC, it would fire spurious Registration updates every time a satellite handed off — churn for a UE that never moved. By pinning itself to a fixed geographic TA using GNSS, the UE only performs a mobility Registration / Tracking Area Update when it genuinely crosses a fixed-TA boundary, not every time the sky changes. Conversely, a UE that does drift across a fixed-TA border (even slowly) will register even if its serving cell never changed. This is defined across TS 23.501 / TS 23.502, with the idle-mode location handling in TS 38.304.
| Aspect | Terrestrial | NTN |
|---|---|---|
| Cell size vs Tracking Area | Cell < TA; many cells per TA | Cell can span many TAs (and countries) |
| TAC broadcast per cell | Single TAC | A set of TACs, one per fixed geographic TA under the footprint |
| How the UE's country is determined | Implicit from the cell / PLMN | From the UE's GNSS position mapped onto a fixed TA |
| Registration / TAU trigger | UE moves into a cell whose TAC is outside its Registration Area | UE's GNSS position crosses a fixed-TA boundary (not merely a cell change) |
LTE ↔ NR: in LTE the UE reports the single trackingAreaCode broadcast in SIB1 and the MME builds a TA list around it — location is purely cell-implied. NR-NTN keeps the same NAS Registration/TAU machinery but lets a cell broadcast a list of TACs and requires the UE to disambiguate with GNSS. The concept of a geographic-to-TAC mapping and network-verified location has no LTE (non-NTN) counterpart.
The registration flow, step by step
NTN registration is the ordinary 5G registration procedure with location folded in. Walk the phases in order; the first that misbehaves is your root cause.
Registration Request inside RRCSetupComplete, authenticates, is (optionally) location-verified, and receives a Registration Accept with its 5G-GUTI and TA list.Step 1 — GNSS fix and fixed-TA selection
Before any signalling, the UE acquires a GNSS position, reads the broadcast TAC list and geographic mapping (from SIB19 and SIB1), and decides which fixed Tracking Area — and therefore which country and permitted PLMN — it is physically in. That chosen TAI is what it will register against, regardless of which raw cell is overhead.
✅ Debugging steps
- Confirm the UE has a valid, recent GNSS fix before registration begins.
- Check the UE decoded the cell's list of TACs and the geographic-to-TAC mapping, and selected one consistent with its coordinates.
- Verify the selected country/PLMN matches the UE's actual position, not merely the strongest cell.
⚠ Common causes of failure
- No GNSS fix (indoor, cold start, jamming), so the UE cannot pick a TAI or align uplink at all.
- UE picks the wrong fixed TA from an ambiguous mapping, registering in the wrong area/country.
- SIB19/SIB1 decode failure, so the TAC list or mapping is unavailable.
Step 2 — Connection and NAS Registration Request
The UE runs random access and RRC setup, then sends its NAS Registration Request (with its 5G-S-TMSI or SUCI and the selected TAI) piggybacked in RRCSetupComplete. The gNB forwards it to the AMF as an Initial UE Message. This uplink RRC rides on PUSCH; the setup that precedes it uses the RACH chain (Msg2 RAR on PDSCH โ DCI format 1_0 / RA-RNTI, Type1-PDCCH CSS), with NTN's GNSS-plus-ephemeris timing pre-compensation so the messages land in-window despite the long round trip.
✅ Debugging steps
- Confirm RACH and RRC setup completed (see random access) before the NAS request — a registration failure is often really an access failure.
- Check the
Registration Requestcarried the correct selected TAI and identity (5G-S-TMSI/SUCI). - Verify the AMF received an
Initial UE Messagewith a plausible TAI for the UE's position.
⚠ Common causes of failure
- RRC setup never completes (RACH/timing pre-compensation wrong), so no NAS message is ever sent.
- TAI in the request inconsistent with the UE's position, prompting the network to reject or re-locate.
- Long round-trip timers not extended for NTN, so the request times out before the AMF replies.
Step 3 — Authentication, security and (optional) location verification
The AMF runs authentication (5G-AKA) and NAS security setup. In NTN it may additionally invoke network-verified UE location (see below), corroborating the UE-reported GNSS position with RAN assistance before it trusts the claimed TAI/country.
✅ Debugging steps
- Confirm authentication succeeded (correct credentials, reachable AUSF/UDM).
- If location verification is enabled, check the reported position was corroborated (timing/geometry consistency against the known ephemeris).
- Verify NAS security mode completed so the
Registration Acceptcan be delivered ciphered/integrity-protected.
⚠ Common causes of failure
- Authentication failure (bad credentials, subscription issue).
- Location verification fails — reported GNSS position inconsistent with timing/ephemeris geometry (possible spoofing), so service is refused or restricted.
- Wrong country determined, so the serving PLMN is not permitted at the UE's real location.
Step 4 — Registration Accept and reachability
The AMF returns a Registration Accept carrying a fresh 5G-GUTI and the TA list (Registration Area) the UE will be paged across; the UE confirms with Registration Complete. From here the UE is reachable, and it will only re-register (a Tracking Area Update) when its GNSS position crosses out of that fixed-TA-based Registration Area — not merely because a satellite handed off.
✅ Debugging steps
- Confirm the UE received a
Registration Acceptwith a5G-GUTIand a TA list anchored to fixed geographic TAs. - Check the TA list is sized so a stationary UE under sweeping beams does not constantly re-register.
- Verify paging reaches the UE using the accepted Registration Area (see reachability in NTN & the 5GC).
⚠ Common causes of failure
Registration Rejectwith a cause pointing back to location/PLMN/authentication.- TA list built on raw cell TACs rather than fixed TAs, causing spurious TAUs as satellites pass.
- Accept lost on a poor downlink, so the UE retries and appears to fail registration.
Representative UE NAS/RRC log (NTN registration) — illustrative, values vary by vendor/build:
| Field | Meaning | Example | Check |
|---|---|---|---|
GNSS fix/age | UE's own position and how fresh it is. | 3D, 0.8 s | Must be present and recent; no fix = cannot select TAI or align uplink. |
tac-List | Set of TACs the cell broadcasts (one per fixed TA under the footprint). | {0x0A01,0x0A02,0x0B07} | A single TAC on a huge beam is a mis-config; expect a list in NTN. |
selectedTAI | The fixed TAI the UE chose from its GNSS position. | 001-01:0x0A02 | Must be geographically consistent with the GNSS coordinates. |
5G-S-TMSI | UE identity in the Registration Request. | 0x8F3A21 | Present for known UE; SUCI used on first/cold registration. |
geomConsistency | Result of network-verified location check. | OK | A fail means possible spoofing → service refused/restricted. |
taiList | Registration Area returned in Registration Accept. | {0x0A02,0x0A01} | Should be fixed-TA based and sized to avoid churn under sweeping beams. |
5G-GUTI | Assigned temporary identity for paging. | 0x...C4 | Its assignment confirms registration succeeded. |
PLMN and country selection
The same location fix protects operator and country selection. Because a beam can reach across a national border, a UE could otherwise camp on a cell that is, at its position, actually licensed to serve a different country — a regulatory violation, even if the radio is perfectly good. The NTN UE uses its GNSS location to avoid selecting a cell/PLMN that does not correspond to the country it is physically in. In practice the network broadcasts the mapping between geographic areas and the PLMNs/TACs valid there, and the UE cross-checks its own position before treating a cell as a candidate. This is why location, not just signal strength, gates suitability in NTN.
Location is a suitability gate: in NTN a cell can be strong yet wrong for your position — belonging to another country's licence under the same footprint. The UE's GNSS fix decides which fixed TA, which country and which PLMN apply before radio criteria matter.
Network-verified UE location
All of the above trusts the UE to report where it is — and for charging, lawful intercept and regulatory compliance that trust cannot be blind. So NTN supports network-verified UE location: the network (the AMF, working with the RAN) can independently verify the UE-reported GNSS position rather than accepting it at face value. If the reported location cannot be verified or is inconsistent, the network can refuse service or restrict it, because getting the country wrong has legal consequences an operator cannot accept.
A procedure by which the core (AMF) plus the RAN checks that a UE's claimed GNSS location is plausible, instead of trusting the self-report.
Country, TAC, charging, lawful intercept and spectrum-licence compliance all hinge on location. A spoofed or wrong position could put a UE on the wrong operator or the wrong jurisdiction.
The AMF, with RAN assistance (e.g. timing/geometry consistency against the known satellite ephemeris), corroborates the reported position and can restrict service if verification fails.
✅ Debugging steps
- Check whether the deployment mandates location verification for the UE's PLMN/country.
- Compare the reported GNSS position against the timing/geometry the RAN measured (round-trip vs expected range for the known ephemeris).
- On a verification failure, capture the resulting NAS cause — refusal vs restriction points at how strict the policy is.
⚠ Common causes of failure
- Reported position inconsistent with measured timing/geometry (spoofing or a bad GNSS fix), so verification fails.
- Ephemeris at the network stale/incorrect, so a genuine position is wrongly rejected.
- Verification not supported end-to-end where the country requires it, blocking service.
Discontinuous coverage and power saving
A sparse LEO constellation — especially early IoT deployments — may not have a satellite overhead at all times, so coverage of a given spot comes and goes. Rather than let a UE burn power blindly searching during a gap, NTN can give it satellite-assistance information (ephemeris and coverage/availability data) so it knows when the next satellite will be visible. The UE can then sleep through the gap and wake up in time for the next pass — a large battery win for a fixed sensor that would otherwise scan a dead sky. Rel-17 provides partial support for discontinuous coverage; it is enhanced substantially in Rel-18. See ntn-evolution for how this and the wider NTN feature set grow release over release.
Predictable gaps, planned sleep: because orbits are deterministic, "no coverage right now" is not "no coverage" — it is "next satellite in N minutes." The UE reads the ephemeris/availability, powers down its receiver, and wakes for the predicted pass instead of draining the battery searching.
✅ Debugging steps
- Confirm the UE received satellite-assistance / availability information and computed a next-pass time.
- Check the UE slept through the gap rather than scanning, and woke aligned to the predicted pass.
- Verify registration timers (periodic registration) are set with the coverage gap in mind so the UE is not deregistered while legitimately asleep.
⚠ Common causes of failure
- Periodic registration timer expiring during a planned coverage gap, deregistering a healthy UE.
- Assistance info missing/stale, so the UE scans a dead sky and drains its battery.
- Clock drift over a long sleep, so the UE wakes misaligned and misses the pass.
Summary
The fastest way to root-cause an NTN registration failure is to remember that in NTN the cell no longer implies location — the UE's GNSS fix does — and then walk the phases in order. Fix & TA-select → Connect & Request → Authenticate & Verify → Accept: if the UE never registers at all, suspect a missing GNSS fix or a failed SIB19/SIB1 decode. If it registers in the wrong place, suspect fixed-TA selection or the geographic-to-TAC mapping. If it is refused after authenticating, suspect network-verified location or a PLMN/country mismatch. If a stationary UE churns with repeated TAUs, suspect a TA list built on raw cell TACs rather than fixed geographic TAs.
The unifying idea is that NTN reattaches Tracking Areas, countries and operator rights to geography using two things the UE always has — a GNSS position and a cell that broadcasts a set of geographically-mapped TACs — and then, because the answer carries legal weight, lets the network verify it. Isolating the broken phase turns a vague "NTN attach failure" into a specific, testable hypothesis.
Interview quickfire
Q. Why must an NTN UE have GNSS?
A. Three reasons. It needs its own position to compute uplink timing advance and Doppler pre-compensation against the satellite ephemeris (from SIB19); it needs it to map onto the correct fixed Tracking Area and country for cell/PLMN selection; and it is needed for regulatory compliance (which jurisdiction the UE is in). Without a position fix an NR-NTN UE cannot even align its uplink, so GNSS is a baseline requirement, not optional.
Q. How does 3GPP keep Tracking Areas geographic when one cell covers many?
A. It decouples the fixed geographic TA from the moving radio cell. A cell broadcasts a set of TACs, one per fixed geographic Tracking Area under its footprint, and the UE uses its GNSS position to pick which fixed TA (and country) it is in. Registration and paging anchor to that fixed area, so a passing satellite changing the serving cell does not, by itself, trigger a Registration update.
Q. Where in the signalling does the NTN location actually get used during registration?
A. Before the request, the UE turns its GNSS fix into a selected fixed TAI from the broadcast TAC list; that TAI travels in the Registration Request inside RRCSetupComplete and on to the AMF as an Initial UE Message. After authentication the AMF may run network-verified location to corroborate it, and only then returns a Registration Accept with the 5G-GUTI and a fixed-TA-based TA list.
Q. What is network-verified UE location for?
A. Because charging, lawful intercept, spectrum-licence compliance and country determination all depend on the UE's position, the network cannot simply trust a self-reported GNSS fix. The AMF, with RAN assistance, independently verifies the reported location (for example checking timing/geometry consistency against the known ephemeris) and can restrict service if it fails to verify.
Q. Why can a stationary UE need a Registration update in NTN?
A. Two cases. If it registered on the raw moving cell, a satellite handoff would change the broadcast TAC and force spurious updates — which the fixed-TA-plus-GNSS approach specifically avoids. Conversely a UE that genuinely drifts (even slowly) across a fixed-TA boundary must perform a Tracking Area Update even though its serving cell never changed, because its geographic Registration Area changed.
Where NTN registration connects
Location, Tracking Areas and verification all feed how the core keeps a moving UE reachable, how mobility is triggered geometrically, and why the UE computes its own uplink timing. Follow these next.