Based on 3GPP TS 38.321 (NR MAC protocol specification), Release 19
1. Why MAC Had to Change for NTN
Terrestrial NR (TN) was designed around propagation delays of microseconds to a few tens of microseconds, and Timing Advance (TA) ranges that comfortably cover cell radii of tens of kilometres. Non-Terrestrial Networks (NTN) — satellites in LEO, MEO, GEO, and HAPS/Air-to-Ground platforms — blow that assumption apart:
- Propagation delay: A GEO round trip can be ~540 ms; even LEO round trips run into tens of milliseconds — orders of magnitude beyond anything TN was built for.
- Doppler shift: Satellite velocities of several km/s introduce large, continuously-changing frequency offsets.
- Cell/beam geometry: A single "cell" can be an earth-moving or earth-fixed beam covering hundreds of kilometres, with the whole beam sweeping across the ground over minutes.
None of the legacy MAC timers, TA command ranges, or grant-timing relationships in TS 38.321 could absorb these deltas without new parameters and new procedures. TS 38.321 therefore added NTN-specific definitions, variables, MAC CEs, and procedural branches, layered on top of — not replacing — the TN MAC state machine.
2. The New Timing Model: Common TA, Koffset, Kmac, and UE-gNB RTT
The centerpiece of NTN MAC changes is a new timing relationship model, built around a few new quantities:
- Common TA: A cell-broadcast timing offset roughly equal to the round-trip time between the gNB (or a reference point, RP, on the ground) and the satellite payload — i.e., the feeder-link delay. This is common to every UE in the cell/beam.
- Service link RTT (UE-specific): The delay between the UE and the satellite, which the UE must estimate itself because it varies with the UE's own geographic position and the satellite's motion.
- Koffset: A configured scheduling offset, broadcast per cell, that must be at least as large as the service-link RTT plus the Common TA. It is added into the existing DL-grant-to-UL-transmission timing (extending k2-style offsets in TS 38.213/38.214) so a UE has enough processing time despite the enormous round trip.
- Kmac: A configured offset approximately equal to the RTT between the RP and the gNB. It delays application of MAC CE commands signalled on PDSCH (so the UE and network agree on exactly when a MAC CE takes effect) and is used to size the RAR/MsgB response windows during Random Access.
- UE-gNB RTT: Defined in TS 38.321 itself as the sum of the UE's Timing Advance value and Kmac — a single quantity the UE (and, via reporting, the network) can use to reason about total round-trip delay for scheduling and timer purposes.
Together these parameters let the gNB schedule around a link where "next slot" might be milliseconds — or hundreds of milliseconds — away, instead of assuming near-instant turnaround as in TN.
3. Autonomous, UE-Driven Timing Advance
In TN, the network is the sole authority on TA: it observes uplink timing and sends periodic Timing Advance Command MAC CEs to correct it. NTN keeps that MAC CE but adds something TN never needed: UE-autonomous TA pre-compensation.
Because NTN UEs are assumed to be GNSS-capable, before even performing Random Access the UE must:
- Acquire a valid GNSS position fix.
- Acquire the satellite ephemeris and the broadcast Common TA from system information.
- Autonomously compute and pre-apply its own Timing Advance (and Doppler pre-compensation) using its own position plus the satellite's position and velocity from the ephemeris.
While RRC_CONNECTED, the UE must continuously refresh this self-computed TA and Doppler correction as the satellite moves — something no TN UE does. The legacy network-driven TA Command MAC CE still exists as a correction on top of this self-compensation, not a replacement for it. This is arguably the single biggest conceptual shift MAC underwent for NTN: TA becomes a closed loop that starts on the UE side, not purely a network-driven correction loop.
4. New/Extended MAC Reporting: Timing Advance Reporting
To close the loop back to the network, Release 17+ added a Timing Advance Reporting procedure and a Timing Advance Report MAC CE (TS 38.321 clauses 5.4.8 and 6.1.3.56). This lets the UE proactively report its current TA-related state to the gNB — useful precisely because, in NTN, the UE (not the network) is the one continuously tracking the true propagation delay via GNSS and ephemeris. This is a capability with no real TN equivalent at this granularity, since TN relies on the gNB's own uplink timing measurements.
Related timing/mobility MAC CEs that matured alongside NTN work include the Differential Koffset MAC CE (clause 5.18.24 / 6.1.3.57), letting the network update a UE's Koffset relative to a baseline as satellite geometry (and hence RTT) changes over the pass — again, a parameter class that simply doesn't exist in TN.
5. HARQ: From "Always-On Feedback" to Configurable Modes
TN MAC assumes fast HARQ round trips, and a HARQ process cannot normally be rescheduled until feedback has been exchanged. Over a GEO link, waiting a full HARQ RTT (over a second, round trip) before reusing a process would cripple throughput given the small, fixed number of HARQ process IDs.
NTN addresses this with configurable HARQ behavior at the MAC layer:
- Downlink: HARQ feedback can be enabled or disabled per HARQ process. Disabling feedback for a process lets the network re-schedule (re-use) that HARQ process ID before a full HARQ RTT has elapsed, since there's no feedback to wait for.
- Uplink: Each HARQ process can be configured into HARQ Mode A or HARQ Mode B, giving different behaviors for retransmission/scheduling flexibility under long RTT.
This is a genuine procedural change inside HARQ entity/process handling (TS 38.321 clauses 5.3.2 and 5.4.2/5.4.3.1), not just a parameter tweak — it changes how many "in-flight" transport blocks a UE can effectively sustain when round-trip latency dominates.
6. Random Access: Bigger Windows, Ephemeris-Aware Timing, RACH-less Handover
Random Access procedures (clause 5.1) gained NTN-aware behavior:
- RAR/MsgB response windows (
ra-ResponseWindow,msgB-ResponseWindow) and the Contention Resolution Timer must be sized to accommodate Kmac/UE-gNB RTT — a UE waiting for a response over a GEO link needs a far larger window than a TN UE ever would. - Because the UE has already autonomously pre-compensated TA and Doppler before Msg1/MsgA, initial uplink synchronization does not rely purely on the network estimating a small, bounded timing offset the way it does in TN.
- For mobility, NTN supports RACH-less handover in specific feeder-link/satellite-switch scenarios, letting a UE move to a new serving arrangement without a full contention-based RA cycle — reducing interruption time that a full RTT-bound RA exchange would otherwise cost. Correspondingly, DAPS handover is not used in NTN the way it is in TN, since maintaining two simultaneous live links across satellite payload constraints is impractical.
7. DRX, Timers, and Other Parameters Scaled for Long RTT
Several existing TN timers and windows (Discontinuous Reception timers, Time Alignment Timer behavior, measurement gap handling, BWP-related timers) needed NTN-aware configuration ranges or interpretations so they remain meaningful when round-trip delay can be measured in tens or hundreds of milliseconds rather than microseconds. The Time Alignment Timer in particular has to tolerate the fact that "no TA update for a while" means something very different when the UE is autonomously tracking its own TA via GNSS/ephemeris versus purely waiting on network commands.
8. Summary Table: NTN-Specific MAC Additions vs. TN Baseline
| Area | Terrestrial NR (TN) | NTN Addition/Change |
|---|---|---|
| TA control | Network-driven only, via TA Command MAC CE | UE autonomously pre-computes/updates TA via GNSS + ephemeris + Common TA; network TA Command still corrects on top |
| New timing parameters | k2, standard TA range | Common TA, Koffset, Kmac, UE-gNB RTT |
| TA feedback | None beyond network's own uplink measurement | Timing Advance Reporting MAC CE (UE → network) |
| Scheduling offset updates | N/A | Differential Koffset MAC CE |
| HARQ | Fixed feedback expected per process | Per-process HARQ feedback enable/disable (DL); HARQ Mode A/B (UL) |
| RA response windows | Sized for microsecond-scale RTT | Sized using Kmac/UE-gNB RTT; ephemeris-aware pre-sync before Msg1/MsgA |
| Handover | DAPS common; RACH-less rare | DAPS not used; RACH-less handover used to cut interruption over long RTT |
| Timers (TAT, DRX, etc.) | Tuned for local-cell delay | Configured/interpreted to tolerate long, GNSS-tracked propagation delay |
9. How the Scheduler Has to Work Differently
The gNB scheduler sits on top of all this, and its job changes in several concrete ways:
a) Grant timing must budget for Koffset, not just k2. Every DL assignment-to-HARQ-feedback and every UL-grant-to-PUSCH timing relationship now has an added Koffset term. The scheduler cannot assume a UE can respond "next slot" or even "next few slots" — it must compute grant timing using Koffset (≥ service-link RTT + Common TA) so the UE physically has time to process and respond. In GEO deployments this can mean scheduling decisions and their effects are separated by over half a second.
b) HARQ process management becomes a throughput lever. Because a small, fixed pool of HARQ process IDs can't sustain the RTT of a satellite link if the scheduler waits for feedback each time, the scheduler must decide, per process, whether to disable HARQ feedback (DL) or which HARQ mode to use (UL) so it can pipeline enough transport blocks in flight to keep the link full. This is effectively a new scheduling degree of freedom — trading blind retransmission risk against throughput — that TN schedulers never had to manage.
c) Timing-advance/RTT state feeds scheduling decisions directly. Since the UE self-tracks and can report its TA/RTT state (Timing Advance Reporting, Differential Koffset updates), the scheduler can use this closed-loop information to keep Koffset and grant timing accurate as the satellite (and therefore the RTT) moves throughout the pass, rather than relying only on its own — much slower — uplink timing observations.
d) Random Access admission and contention windows are sized per-RTT. The scheduler (and the RA response logic) must size RAR/MsgB windows and contention-resolution timers according to Kmac/UE-gNB RTT, and account for the fact that UEs have already pre-synchronized timing/frequency before Msg1 — changing how quickly the network can expect a usable Msg1/MsgA versus a TN cell.
e) Mobility scheduling anticipates beam/satellite motion, not just radio conditions. Since NTN beams and satellite geometry change deterministically and predictably (ephemeris-driven), the scheduler can — and largely must — plan ahead for feeder-link switches, beam handovers, and RACH-less handover triggers on a schedule tied to orbital mechanics, rather than reacting only to instantaneous channel measurements as in TN.
f) Latency-sensitive traffic must be re-prioritized around fixed, large RTT floors. No amount of good scheduling removes a ~500 ms GEO round trip; the scheduler's role shifts from "minimize latency" to "hide/pipeline latency" — maximizing the number of parallel, in-flight HARQ transactions and grants per UE so throughput stays high even though the one-way response time is fixed and large.
10. Bottom Line
NTN did not replace the NR MAC layer — it extended it. The RACH state machine, HARQ entity, LCP, BSR, and DRX frameworks from TN are all still there and still used as the baseline. What NTN added is a parallel timing model (Common TA, Koffset, Kmac, UE-gNB RTT), a UE-autonomous TA/Doppler pre-compensation loop layered on top of the network's TA Command MAC CE, new reporting and reconfiguration MAC CEs (Timing Advance Report, Differential Koffset), and configurable HARQ behavior to survive round trips that dwarf anything TN was designed for. The net effect on the scheduler is that it now has to reason explicitly about propagation delay, satellite geometry, and HARQ pipelining as first-class scheduling inputs — not just channel quality and buffer occupancy.
π¬ Comments
No comments:
Post a Comment