>
Home5G NTNMobility & Higher LayersRRC & Connection Control (NR-NTN)
📡 Mobility & Higher LayersAdvanced

RRC in NR-NTN — States, Timers & Key IEs

RRC in NR-NTN keeps the terrestrial state machine and message set, but a satellite link forces a handful of pointed additions: ephemeris-driven cell selection, a GNSS-fix gate before RRC setup, and timers scaled to a round trip that can reach half a second.

📚 3GPP-basedTS 38.331TS 38.304TR 38.821

RRC (Radio Resource Control) is the layer that gets a UE from switched-on to a configured, connected radio bearer — and NR-NTN reuses that layer almost untouched. There is no new RRC message set for satellite access: RRCSetupRequest, RRCSetup, RRCReconfiguration and the rest all carry over from TS 38.331 verbatim. What changes is what has to be true before those messages fire, and how long the state machine is willing to wait once they do. This page walks the NR-NTN deltas layer by layer: cell (re)selection, connection establishment, the NTN-specific information elements, and the timer scaling that keeps T300/T301/T304 honest over a GEO round trip.

Introduction

Every NR-NTN deep dive on this site — timing advance, Doppler, RACH, SIB19 — eventually lands back at RRC, because RRC is where the network tells the UE how to use all of those satellite-specific corrections. The state machine itself (RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED) is the same three states as terrestrial NR, and the procedures — connection setup, reconfiguration, re-establishment, release — use the same ASN.1 defined in TS 38.331. NR-NTN did not need a new protocol; it needed new preconditions and new patience.

Those two words are the whole page. Preconditions: a UE cannot usefully start RRC signalling without a GNSS fix and current ephemeris, because everything downstream (its own timing-advance term, its Doppler pre-compensation) depends on knowing where it is and where the satellite is. Patience: once signalling starts, every timer that assumes a few-millisecond terrestrial round trip has to be re-derived for a link that can be forty times longer.

RRC states are unchanged — what surrounds them is not

RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED mean exactly what they mean terrestrially: no signalling connection with the UE keeping its own mobility going via cell reselection; a suspended context the network can resume quickly; and an active connection with dedicated configuration. NR-NTN adds no fourth state.

What is different is what a cell is while the UE sits in each state. A terrestrial cell is a fixed patch of ground. An NTN cell can be Earth-fixed (a GEO beam that stays over the same footprint, or a LEO beam electronically steered to compensate for satellite motion so its footprint doesn’t move) or Earth-moving (a LEO beam that simply sweeps across the ground with the satellite, so a stationary UE eventually falls outside it even with zero UE mobility). cellBarred, TAC assignment and the UE’s idea of “same cell, still valid” all depend on which model the satellite operator has chosen — see Mobility & Feeder-Link Switch for the moving-cell implications.

Cell (re)selection: SIB19 before anything else

Terrestrial cell selection ranks candidate cells on Srxlev/Squal from SSB measurements. NR-NTN keeps that S-criteria math but adds a gate in front of it: a UE cannot treat a satellite cell as selectable until it has read SIB19 and validated that its own GNSS-derived position and the satellite’s broadcast ephemeris are usable together. SIB19 also carries the elevation-angle threshold a cell may require before letting a UE camp — low-elevation geometry means longer, noisier paths, so operators can simply refuse cell selection below a configured angle.

Reselection inherits the same dependency: an Earth-moving beam’s coverage boundary is a function of time and orbit, not RF geometry alone, so a UE has to keep its ephemeris current (bounded by ntn-UlSyncValidityDuration, see Timing Advance & Koffset) purely to know whether it is still inside the cell it thinks it’s in.

The GNSS-fix gate on RRCSetupRequest

This is the single most consequential NR-NTN addition to RRC procedure. Before a UE sends RRCSetupRequest (or resumes via RRCResumeRequest), it must have a valid GNSS position and a current, non-expired ephemeris for the serving satellite. Without both, it cannot compute the UE-specific timing-advance term or the Doppler pre-compensation that Msg1/MsgA of random access assumes — see Random Access in NTN. A UE that attempts RACH without these will either miss the gNB’s preamble-detection window or land its Msg3 in the wrong slot, so implementations gate the attempt entirely rather than let it fail downstream.

🎯

Practical effect: the very first thing a fresh, powered-on NTN device does before touching RRC is acquire a GNSS fix. On a cold GNSS start this can add several seconds to time-to-first-RRC-attempt versus a terrestrial device — a UX and power-budget consideration that doesn’t exist on the ground.

NTN-specific IEs riding inside familiar messages

NR-NTN doesn’t add new RRC messages, but it does add new information elements carried inside the existing ones, mostly within SIB19 and the connected-mode NTN-Config structure signalled in RRCReconfiguration:

IE / fieldCarried inPurpose
ephemerisInfoSIB19Satellite position/velocity (state-vector or orbital-elements form) so the UE can compute range, Doppler and elevation.
ta-Common / drift termsSIB19Network-broadcast common timing offset; see Timing Advance.
cellSpecificKoffset, kmacSIB19 / NTN-ConfigScheduling offsets sized to the cell’s worst-case round trip.
ntn-UlSyncValidityDurationSIB19Validity window before the UE must re-read ephemeris and halt uplink.
t-ServiceSIB19For Earth-moving cells: the remaining time this cell serves the current area, used pre-emptively for mobility.
epochTimeSIB19Reference instant the ephemeris and common-TA values apply to.

None of this changes the RRC procedure grammar — a UE still receives a SIB, still gets an RRCReconfiguration, still ACKs it the same way. It changes what the UE must be able to parse and act on before those familiar procedures can succeed.

Scaling the RRC timers for a long round trip

Terrestrial RRC timers (T300 guarding RRCSetupRequest, T301 guarding re-establishment, T304 guarding handover completion, and others) are sized assuming a few milliseconds of propagation. A GEO satellite alone adds roughly 240–280 ms one-way, so an un-scaled T300 can expire before the response has even had time to arrive.

3GPP’s answer is not new timers but a defined scaling factor: the network broadcasts (or signals) an offset/multiplier that stretches the relevant RRC and lower-layer timers by the cell’s known round-trip delay, so a GEO cell effectively runs on a slower clock than a LEO cell, which in turn runs slower than terrestrial. The mechanics live alongside the MAC/RLC timer scaling covered in Timer & Window Scaling — RRC timers use the same underlying round-trip figure.

💡

Rule of thumb: if a terrestrial RRC timer is sized for “a few round trips at a few ms each”, its NTN equivalent needs the same number of round trips at whatever this cell’s round trip actually is — 8–25 ms for LEO, up to ≈540 ms for GEO.

Conditional handover and RRC mobility

Because satellite motion is predictable — a gNB knows a LEO satellite’s ephemeris minutes or hours in advance — NR-NTN leans hard on Conditional Handover (CHO): the network pre-configures a UE with a target cell and an execution condition well before the handover is actually needed, so the RRC exchange doesn’t have to happen reactively inside a shrinking measurement window. This matters because a reactive handover, on a link with hundreds of milliseconds of round trip, risks the target already having moved by the time the command arrives. See Mobility & Feeder-Link Switch for the beam and feeder-link specific triggers layered on top of ordinary CHO.

Procedure-by-procedure summary

RRC procedureTerrestrial NRNR-NTN delta
Cell selectionSSB measurement + S-criteriaGated on SIB19 ephemeris validity; optional elevation-angle threshold
RRCSetupRequestSent once cell is suitableGated on a valid GNSS fix and TA/Doppler pre-compensation being computable
RRCSetup / RRCReconfigurationStandard IEsCarries NTN-Config: ephemeris refs, Koffset/kmac, validity timers
Timers (T300/T301/T304…)Fixed short valuesScaled by the cell’s broadcast round-trip delay
HandoverReactive, measurement-triggeredConditional Handover pre-configured from known ephemeris, plus feeder-link switch

Summary

RRC in NR-NTN is deliberately conservative: reuse the terrestrial state machine and message grammar, and confine all satellite-specific behaviour to (a) preconditions — a GNSS fix and current ephemeris gating cell selection and connection setup, (b) new IEs carried inside existing messages — SIB19 and NTN-Config, and (c) timer scaling — the same procedures, run on a clock stretched to match the cell’s round-trip delay. Everything else — security, bearer configuration, measurement reporting — is unchanged from terrestrial NR.

Q&A Interview quickfire

Q. Does NR-NTN define new RRC messages?

A. No. It reuses the terrestrial TS 38.331 message set unchanged. The differences are new information elements (ephemeris, Koffset, validity timers) carried inside existing messages like SIB19 and RRCReconfiguration, plus preconditions and timer scaling around those same procedures.

Q. Why must a UE have a GNSS fix before sending RRCSetupRequest on an NTN cell?

A. Because the UE has to pre-compute its own timing-advance and Doppler pre-compensation from its position and the satellite ephemeris before it can send a preamble the gNB will detect in the right window and demodulate on the right frequency. Without a fix, RACH and everything after it is effectively guaranteed to fail.

Q. How are RRC timers like T300 handled for a GEO cell with ~540 ms round trip?

A. They are scaled by a broadcast round-trip-delay figure for that cell rather than replaced with new timers, so the same procedure logic holds but with patience proportional to the cell's actual propagation delay.

Where this leads next

RRC is the layer that stitches together everything else in this section — the timing and Doppler corrections, the RACH procedure, and the mobility model. See how it plays out message-by-message in a real connection.