Random Access over Satellite in 5G NTN

Introduction

Random access is the MAC-layer handshake (TS 38.321) a UE runs whenever it needs uplink synchronisation and a scheduling opportunity — power-on from RRC_IDLE, re-establishment, handover, or regaining sync after the timeAlignmentTimer expires. Over a satellite it is the first place the enormous, drifting propagation delay of NTN collides with a procedure that was designed assuming the network could measure timing from the preamble itself.

The messages are identical to terrestrial NR — Msg1 preamble, Msg2 RAR, Msg3 identity, Msg4 contention resolution (or the two-step MsgA/MsgB). But NTN inverts the timing responsibility: the UE arrives already uplink-synchronised by computation, using its GNSS position, the satellite ephemeris, and the common parameters in SIB19. The gNB is left measuring only a tiny residual.

Because the procedure is still four distinct messages, an NTN RACH failure lives in one specific step — and each step has an NTN-specific twist (pre-compensation at Msg1, residual TA at Msg2, K_offset at Msg3, stretched timers at Msg4). Knowing which message broke, and which twist it involves, is most of the debugging.

The terrestrial baseline, in one breath

On the ground the UE runs the classic four-step contention-based procedure (see random access). It sends a PRACH preamble (Msg1), the gNB replies with a Random Access Response (Msg2 / RAR) carrying a Timing Advance Command and an uplink grant, the UE transmits its identity (Msg3), and the gNB echoes it back to resolve contention (Msg4). Two-step RA collapses this into MsgA (preamble + PUSCH payload) and MsgB. The whole point of Msg1 terrestrially is that the gNB has no idea how far away the UE is, so it measures the preamble arrival time and tells the UE its timing advance in the RAR.

Why NTN reshapes random access

Two physical facts drive every NTN change. First, the delay is huge: a LEO round trip is milliseconds to tens of ms, a GEO round trip approaches 540 ms — orders of magnitude beyond the gNB's few-tens-of-µs preamble-detection window and beyond the range the RAR's 12-bit Timing Advance Command can express. Second, the delay drifts: a LEO satellite moves kilometres per second, so timing and Doppler change continuously during a single access attempt.

The procedure copes not by redesigning the messages but by moving work in time and space: the UE pre-computes timing/frequency before Msg1, the RAR carries only a residual, the response timers are stretched to span the true round trip, and cellSpecificKoffset pushes the Msg3 grant far enough into the future to be reachable. The rest of this page walks those changes message by message.

Msg1 — the UE pre-compensates before it transmits

This is the single idea that reshapes NTN random access. A terrestrial UE transmits its preamble "now" and lets the gNB discover the delay. An NTN UE cannot afford that — the delay is enormous and the Doppler is large — so it makes itself uplink-synchronised by computation before Msg1.

Three ingredients make this possible, all available before the UE transmits:

• GNSS position. An NTN UE is assumed to have a GNSS fix, so it knows exactly where it is.
• Satellite ephemeris. SIB19 broadcasts the serving satellite's orbital position and velocity (as ephemeris, either an orbital-element set or a position/velocity state vector). The UE propagates it to the current time to know where the satellite is and how fast it is moving.
• Common timing/frequency parameters. SIB19 also carries a cell-common timing offset — the common TA parameters (ta-Common, ta-CommonDrift, ta-CommonDriftVariation) — that account for the feeder link and a reference-point delay the UE cannot see.

From position + ephemeris the UE computes the service-link propagation delay and its rate of change; it adds the SIB19 common TA to cover the part of the path beyond the satellite. The result is a full timing advance the UE applies to Msg1 itself. It does the same for frequency, pre-compensating the service-link Doppler so the preamble lands near the expected subcarriers. See timing advance in NTN for the exact UE-specific + common decomposition.

The preamble is transmitted on PRACH; there is no DCI and no RNTI for Msg1 (the UE just transmits). From the PRACH occasion the UE derives the RA-RNTI it will use to find the RAR — computed exactly as on the ground from the occasion's symbol, slot, and frequency index (TS 38.321). The preamble formats are the unchanged terrestrial long/short families; see NTN PRACH.

Msg2 — why the RAR only needs to carry a small residual

Because the UE already pre-compensated the bulk of the delay, its preamble arrives at the satellite/gNB nearly aligned. The gNB still measures a tiny leftover — the difference between the UE's computed timing and reality (GNSS error, ephemeris propagation error, quantisation). That leftover is the residual TA.

The RAR itself is delivered exactly as on the ground: a MAC RAR on PDSCH, scheduled by a DCI format 1_0 whose CRC is scrambled with the RA-RNTI, decoded by the UE in the Type1-PDCCH common search space (ra-SearchSpace, in CORESET#0 / the initial DL BWP) — but only inside a ra-ResponseWindow that NTN has stretched to span a full round trip. It echoes the detected preamble index (RAPID) and carries the residual Timing Advance Command, an uplink grant for Msg3, and a TC-RNTI.

Msg3 — stretched windows and K_offset

Pre-compensation fixes the arrival alignment, but nothing removes the raw propagation delay from the message exchange. Every "wait for the response" timer must be widened, and every "transmit N slots after you receive a grant" relationship must be pushed out past the round-trip.

Response windows. After Msg1 the UE monitors for the RAR inside ra-ResponseWindow. On the ground that window is a few milliseconds; in NTN the RAR physically cannot arrive until at least one round-trip later, so the permitted values of ra-ResponseWindow (and msgB-ResponseWindow for two-step) are extended so the UE waits long enough. The same applies to ra-ContentionResolutionTimer for Msg4 — it must cover another round-trip. These extensions are tied to the round-trip time and to K_offset; see NTN timers.

Msg3 timing. Here is the subtle one. In the RAR the gNB grants an uplink resource for Msg3 a fixed number of slots after the RAR. Terrestrially the UE can reach that slot easily. In NTN, by the time the grant physically arrives, the "scheduled slot" would already be in the past. So NTN adds a cell-specific offset cellSpecificKoffset (K_offset) into the timing relationship: the UE applies the RAR grant to a slot shifted later by K_offset, guaranteeing the scheduled UL slot is still reachable given the delay. K_offset is broadcast in SIB19 and is sized to the cell's round-trip time.

Msg3 itself is unchanged in form: it is sent on PUSCH using the RAR uplink grant (a Msg3 retransmission is scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI in the Type1-PDCCH CSS), carrying the CCCH SDU (RRCSetupRequest) or a C-RNTI MAC CE, and it is HARQ-protected up to maxHARQ-Msg3Tx.

PRACH capacity and low elevation

A happy side-effect of pre-compensation is that the gNB's job stays manageable. Because every UE arrives inside the expected window, the gNB's timing-estimation range does not have to span the full cell round-trip — it only has to resolve the small residual, so the preamble detector behaves much like a terrestrial one and preamble/occasion capacity is not consumed by wild timing spread.

The stress case is very low elevation. When the satellite is near the horizon, the differential delay and Doppler across the wide beam are largest and change fastest, and residual errors from ephemeris propagation grow. Network planning responds by choosing PRACH configurations and preamble formats (larger cyclic prefix / restricted sets) and by keeping SIB19 ephemeris and common-TA parameters fresh, so residuals stay within the RAR TA command range even at the edge of the pass. This links directly to coverage margins discussed in NTN spectrum.

Channels, DCI and RNTI at a glance

The physical-layer plumbing of each message is identical to terrestrial NR — only the timing around it changes. It is worth pinning down the exact channel / DCI / RNTI / search-space for each step, because in NTN the temptation is to assume "everything is different" when in fact only the timers and offsets are.

Reading NTN RACH in the logs

An NTN RACH trace reads like a terrestrial one with three extra columns bolted on: the UE's pre-compensation state at Msg1, the residual (not full) TA at Msg2, and the K_offset-shifted slot at Msg3. Walk the messages in order and the first NTN-specific field that looks wrong is usually the root cause.

Representative NTN RACH log (UE + gNB, merged) — illustrative, values vary by vendor/build:

Summary

NTN random access is terrestrial four-step RACH with the timing responsibility inverted and the clocks stretched. Walk it message by message. Msg1: the UE must arrive pre-synchronised — check the GNSS fix, SIB19 ephemeris/epoch, the UE-specific + ta-Common terms, and the frequency pre-correction. Msg2: the RAR is ordinary (PDSCH / DCI 1_0 / RA-RNTI / Type1 CSS) but its Timing Advance Command carries only a residual and its ra-ResponseWindow must span a round trip. Msg3: the grant is reachable only because cellSpecificKoffset pushes the slot into the future; check both sides apply the same value. Msg4: contention resolution is unchanged except that ra-ContentionResolutionTimer is extended.

The debugging discipline is the same as terrestrial RACH — find the first broken message — with one added question at each step: is the NTN-specific twist (pre-compensation, residual, K_offset, stretched timer) correct? Get the geometry inputs right at Msg1 and most of the rest follows.