Mobility & Feeder-Link Switch in 5G NTN

Introduction

NTN mobility is the set of procedures that keep a UE attached as the serving satellite — and therefore its cell — moves out from over you. It spans two states: the connected-mode handover of an RRC_CONNECTED UE from one cell/beam/satellite to the next, and the idle-mode cell reselection of an RRC_IDLE / RRC_INACTIVE UE. In both, the trigger to move is anchored to predictable geometry and time rather than to a fading radio measurement.

It sits immediately after cell selection and registration in the UE lifecycle: once the UE has camped and (for connected mode) established a bearer, mobility is what preserves that service through the relentless churn of a LEO constellation. Get it wrong and a stationary sensor drops its session every few seconds; get it right and coverage feels continuous even though no single satellite is ever overhead for long.

Because NTN mobility is a sequence of distinct signalling steps — measurement/assistance configuration, the conditional-handover trigger, the RACH to the target, and the completion — a failure almost always lives in one step. Knowing which step broke (did the CHO ever get provisioned? did D1 fire? did RACH to the target complete?) narrows the root cause enormously, which is exactly the step-by-step habit this page builds.

Why NTN mobility is needed

Concretely, mobility exists to solve one problem: a LEO satellite is only above your horizon for a few minutes, and any single beam dwells over a ground point for only seconds to tens of seconds. Without a mobility procedure, a connected UE would lose its serving cell — and its bearer — the instant the beam swept away. So the network must (1) provision the next cell as a candidate before the current one dies, (2) trigger the move on something predictable, and (3) execute a fast, usually contention-free, access to the target so the session survives the gap. NTN mobility is the only thing standing between a moving constellation and a dropped call.

Why NTN mobility is upside-down

The intuition to unlearn is "the cell is a fixed place." For a LEO satellite the beam painted on the ground is moving with the satellite, so the geometry between you and your serving cell changes continuously whether or not you move. A stationary IoT sensor in a field will still see its serving satellite climb the sky, pass overhead, and drop toward the far horizon in the space of a few minutes — and during that pass it may be handed over several times as successive beams and successive satellites take over. Handover in NTN is therefore driven by orbital geometry, not by user movement.

The second thing to unlearn is "RSRP tells me when to move." In terrestrial mobility a falling SS-RSRP is a reliable proxy for "you are leaving the cell." In LEO NTN it is not. The whole footprint is sweeping, the path length to the satellite is enormous and changes fast, and a beam can stay roughly equally strong right up until it leaves you behind — or fade and recover as the satellite's antenna pattern rolls over you. Signal strength no longer maps cleanly to "where am I in the cell," so a purely RSRP-triggered handover fires late, early, or not at all. What is reliable is that the satellite's position as a function of time is known precisely from ephemeris, and your own position is known from GNSS. Mobility in NTN leans on that predictable geometry instead of on noisy radio measurements. See ntn-orbits for why LEO in particular forces this.

Earth-moving, earth-fixed and quasi-earth-fixed cells

How the footprint behaves on the ground depends on whether the satellite steers its beams, and 3GPP names three patterns. They matter because each produces a different handover cadence.

All three tie into one broadcast parameter from SIB19: t-Service. This tells the UE the time at which the serving cell will stop serving its current area — the moment an earth-fixed or quasi-earth-fixed cell is about to re-point away, or the moment a moving beam will have swept past. Knowing t-Service in advance, the UE (idle or connected) can prepare to move before the radio actually collapses, which is exactly the kind of predictive trigger that pure RSRP cannot give you.

Location- and time-based conditional handover

Because radio measurements alone are unreliable, Rel-17 extends Conditional Handover (CHO) with two execution conditions that key off geometry instead of RSRP. The network still pre-provisions candidate targets early over Xn and stores a condRRCReconfig plus a condExecutionCond in the UE inside conditionalReconfiguration; only the trigger changes. The two new NTN CHO events are:

• CondEvent D1 — a distance/location condition. The UE computes its distance (from its own GNSS position) to a configured serving-side anchor referenceLocation1 and a target-side anchor referenceLocation2, and executes when it moves further than distanceThreshFromReference1 from the serving reference and closer than distanceThreshFromReference2 to the target reference. In effect: "when I have crossed geometrically from the serving cell's area into the target's."
• CondEvent T1 — a time-window condition. The UE executes when a measured time passes a start threshold t1-Threshold and stays within a configured duration. Because the serving cell's coverage end is predictable (it maps onto t-Service / ephemeris), the network can simply tell the UE "hand over inside this time window."

Contrast this with the classic radio events. Ordinary CHO uses CondEvent A3 (a candidate becomes an a3-Offset better than the serving cell) or CondEvent A5 (serving falls below a5-Threshold1 while a candidate rises above a5-Threshold2) — both comparing SS-RSRP/SS-RSRQ. In NTN those still exist, but D1 and T1 are the workhorses because they fire on where you are and what time it is, quantities that are dead-reckonable from ephemeris and GNSS long before the radio tells you anything. The RRC machinery lives in TS 38.331; the idle/location handling in TS 38.304.

The CHO flow, step by step

Even though the UE executes the handover locally, an NTN CHO is a signalling sequence with four distinct phases. Walk them in order — the first phase that misbehaves is your root cause.

Step 1 — Candidate preparation and CHO configuration

The serving gNB decides, from ephemeris and the UE's reported GNSS/measurements, which cells will next cover the UE, and prepares them over Xn (an Xn Handover Request / acknowledge). It then sends the UE an RRCReconfiguration carrying conditionalReconfiguration — one or more condRRCReconfig entries (each a full target config with its reconfigurationWithSync), each paired with a condExecutionCond selecting CondEvent D1 and/or T1. The UE confirms with RRCReconfigurationComplete and starts evaluating locally. This message is scheduled like any dedicated DL RRC: PDSCH ← DCI format 1_1 / C-RNTI in the UE-specific search space.

Step 2 — Local evaluation and trigger

The UE now continuously computes its distance from referenceLocation1 and referenceLocation2 (using its GNSS position) and tracks the clock against t1-Threshold/t-Service. When CondEvent D1 (far enough from serving and close enough to target) or CondEvent T1 (inside the time window) is satisfied for a prepared candidate, the UE selects that candidate and begins execution — no measurement report is sent to the network; the decision is entirely UE-local.

Step 3 — Random access to the target

On trigger the UE applies the stored target configuration (the reconfigurationWithSync inside the chosen condRRCReconfig) and runs random access toward the target cell. NTN handover normally uses contention-free RACH via a rach-ConfigDedicated in the stored config, so the target already reserves a dedicated preamble for this UE. The critical NTN twist: the UE pre-compensates the target's timing advance and Doppler from that cell's ephemeris (in its SIB19) plus the UE's own GNSS position, so Msg1 lands inside the target's window despite the enormous round trip. The RAR (Msg2) is carried on PDSCH ← DCI format 1_0 / RA-RNTI in the Type1-PDCCH common search space, exactly as in terrestrial RACH — only the timing pre-compensation differs.

Step 4 — Completion and release

After RACH succeeds, the UE sends RRCReconfigurationComplete to the target gNB, which becomes the new serving cell; the path is switched in the core and the old serving resources (and the other prepared candidates) are released. From here the UE resumes normal scheduling under its C-RNTI on the target. If any step failed before completion, the UE falls back to re-establishment (RRCReestablishmentRequest) or, if idle, to reselection.

Representative UE mobility log (NTN CHO) — illustrative, values vary by vendor/build:

Feeder-link switch: changing the ground gateway

There are two radio hops in NTN: the service link (UE ↔ satellite) and the feeder link (satellite ↔ NTN gateway on the ground). As the satellite flies, it eventually moves out of the sky above its current gateway and must hand its feeder link to the next gateway further along the track. This is the feeder-link switch, and it has no analogue in terrestrial networks. Depending on the architecture it can change which gNB (or gNB-DU, for a regenerative payload) serves you, or it can be invisible to the UE if the ground network stitches the change together behind the 5GC.

From the UE's point of view the feeder-link switch may show up as an ordinary handover (if the serving cell's identity or gNB changes with the gateway) or as nothing at all (if the payload is transparent and the ground side keeps the same logical cell). Networks that must protect real-time traffic prefer soft switching so that no user plane is dropped; simpler deployments accept the brief hard-switch gap, often scheduling it for a moment when few UEs are affected.

Idle-mode reselection with location and timing

An idle NTN UE cannot lean on RSRP ranking the way a terrestrial idle UE does, for the same geometric reason. Instead, cell reselection in NTN is assisted by location and timing. The cell broadcasts a reference location and satellite ephemeris in SIB19, and the UE combines that with its own GNSS fix to reason about which cell it should be on and how long the current one will last. Crucially, the UE is told t-Service — the time the serving cell will stop serving its area — so it can reselect in time, before coverage of that cell ends, rather than waiting to discover a dead radio and then scrambling. The ordinary S-criterion (Srxlev) and the broadcast q-RxLevMin thresholds still apply for suitability, but the timing of the move is anchored to predictable geometry, not to a fade.

Summary

The fastest way to root-cause an NTN mobility failure is to remember that the cell, not the user, is what moves — then walk the handover phases in order and find the first that broke. Provision → Trigger → RACH → Complete: if the UE never has a candidate, suspect Xn preparation or a missing conditionalReconfiguration. If the candidate is stored but D1/T1 never fires, suspect thresholds versus t-Service, or a stale GNSS fix. If the trigger fires but RACH to the target fails, suspect TA/Doppler pre-compensation against the wrong ephemeris, or an ra-ResponseWindow too short for the round trip. If RACH succeeds but the UE never settles on the target, suspect the completion message, the core path switch, or context release.

The unifying idea is that NTN replaces the terrestrial "RSRP fell, so move" logic with "geometry and time say the cell is about to leave, so move first." Isolating the broken phase turns a vague "NTN drop" into a specific, testable hypothesis — each phase points at a small, distinct set of causes, so knowing where it broke usually tells you why.

Interview quickfire