一文汇总手机直连卫星场景下的重要物理量及其交互

NTN/DTC 物理层交互全景: 一个端到端的"协议栈"视角

在 SIGMETRICS'26 的 《A Variegated Look at Direct-to-Cell Satellites in the Wild》这篇文章里，团队首次提出DTC场景下的实测。本文重点提及了很多DTC/NTN场景下的物理量及其交互过程。

文章对这些基础概念进行了科普，但对于"试图深入研究NTN"的同学而言，深度可能还不太够。因此本文受该论文的影响与启发，尝试系统整理在手机直连卫星场景下的 物理概念 及 物理量的交互逻辑。

笔者在尝试学习、深入研究这一领域的过程中注意到网上有不少博客:

• ShareTechnote - NTN: 👍 科普概念, 新手向
• ShareTechnote - 6G
• NR-NTN Protocol Stack Overview: 👍 涉及协议栈宏观视角, 写的不错

但是都写的非常浅尝辄止, 用来科普没问题, 但对于 deep dive 还是有点差距 (update: 2026-04-26)

本文尝试深入解析手机直连卫星场景下的NTN协议栈物理交互全过程!

Acknowledgement:

本文的绘图60%是笔者基于PPT绘制, 其他均为手绘后使用GPT-Image润色。创作不易, 希望"后之览者, 亦将有感于斯文"~

文字部分80%是笔者综合各类论坛资料、3GPP官方文档自拟, 另外20%来自AI润色补充. 所有内容全部经过人工核验, 放心阅读.

笔者水平有限, 如有任何不足与改进之处, 欢迎交流指正!

协议栈的骨架: 信道与上下行交互流程

(1) 物理信道的分类

5G NR 的物理信道按"方向"和"功能"正交分解为六个, 理解它们的分工是理解整个交互流程的前提:

Note

• DL: DownLink, 下行链路
• UL: UpLink, 上行链路

方向	信道	全称	承载内容
DL	PDCCH	Physical Downlink Control Channel	DCI (调度信息、上行授权 UL Grant)
DL	PDSCH	Physical Downlink Shared Channel	下行用户数据 + 部分高层信令 (RAR, Msg4, SIB)
DL	PBCH	Physical Broadcast Channel	MIB
UL	PRACH	Physical Random Access Channel	RA Preamble (Msg1/MsgA preamble)
UL	PUSCH	Physical Uplink Shared Channel	上行用户数据 + 大块 UCI
UL	PUCCH	Physical Uplink Control Channel	小量 UCI (HARQ-ACK / SR / CSI)

(2) 常见名词释义

[1] DCI 和 UCI

• DCI = Downlink Control Information
  • 下行控制信息. gNB 的"调度指令"
• UCI = Uplink Control Information
  • 上行控制信息. UE 的"反馈语言"

[1.1] 区分信息载荷与信道:

它们是 5G NR Control Layer 物理层的两类"信息载荷", 不是"物理信道"本身!

理解它们的关键是把"信息"和"承载信息的信道"分开来看:

方向	信息	承载信道
下行	DCI	PDCCH (专用)
上行	UCI	PUCCH (主) 或 PUSCH (复用/piggyback)

注意:

• DCI 只能在 PDCCH 上传
• UCI 两条信道都可以走
  • 优先走 PUCCH, 其次 PUSCH (基于piggyback)

这个不对称源于物理资源约束: 下行 gNB 可以同时发多个信道, 但 UE 上行受 PAPR 约束通常不能同时发 PUCCH 和 PUSCH. 所以必须设计 piggyback 机制

[1.2] DCI/UCI 各自的作用

DCI 是 gNB 用来告诉 UE "下一步该做什么"的指令集:

• 下行调度信息 (DL assignment):
  • 告诉 UE: "我马上在 PDSCH 的某某位置发数据给你,请去解码"
• 上行授权 (UL grant):
  • 告诉 UE: "你可以在 PUSCH 的某某位置发数据给我"
• 功率控制命令 (TPC):
  • 调整 UE 上行发射功率

UCI 包含三类信息, 对应 UE 反馈给 gNB 的三种语义:

(1) HARQ-ACK / HARQ-NACK

"已收到/我没收到". HARQ是负责"重传机制"的, 后面会详细展开

(2) CSI (Channel State Information). 信道状态反馈

"我现在信道情况是..., 请gNB根据情况进行...调整"

• CQI: Channel Quality Indicator. "链路自适应建议"
• PMI: Precoding Matrix Indicator. 不用管
• RI: Rank Indicator. 不用管

(3) SR (Scheduling Request)

UE 在没有 UL grant 的情况下, 告诉 gNB "我有数据要传, 请给我资源"

[2] MIB 和 SIB

5G NR 把"小区配置信息"分成两类:

• MIB: Master Information Block
  • 通过 PBCH 广播
  • 极小, 只够告诉 UE 怎么找到 SIB1
• SIB: System Information Block
  • 通过 PDSCH 广播, 承载具体配置参数

[2.1] 常用 SIB 指令:

SIB	内容	触发场景
SIB1	小区接入参数 (PLMN、TAC、scheduling info)	所有 UE 必读
SIB19	NTN 卫星辅助信息	NTN 小区接入

注意:

1. UE 只在需要某个功能时才解码对应的 SIB, 既节省带宽也节省 UE 功耗
2. SIB19 就是这套体系下 "NTN 功能" 对应的那块

[2.2] SIB-19 承载的核心字段:

1. 卫星星历: pos(x,y,z), vel(x,y,z)
2. 时间同步辅助: commonTA
   • 利用"二阶模型" (梦回OAI源码)
   • 让 UE 可以在 ~30 秒内不重读 SIB19 也能维持 sub-μs 的 TA 精度
   • 这是 LEO 高动态场景下控制广播开销的关键设计
3. 调度时序偏移: kOffset
4. 位置与移动性辅助: referenceLocation ...

(3) 从零开始的互动

初始态:

• UE 在地面
• Sat 作为 gNB, 刚刚进入 UE 的 "视线范围"

我们会在后面详细展开, 现在说有点太“超前”了

这里就放两个数据交互的例子, 给后面详细展开做铺垫:

[1] 一次完整的DL数据交互

我们以 "gNB 给 UE 发送一个 IP 包" 为例, 展示 DL 如何调动整个信道体系

[2] 一次完整的上行数据交互: 从无到有

下行有"广播"的天然便利, 但上行必须解决"UE 凭什么获得发送权"的问题

TA: 上行同步的物理基础

Timing Advance, 简称 TA. 时间提前量

(1) 背景: OFDMA 上行必须时间对齐

OFDMA 系统的正交性建立在 "所有用户的子载波在接收机处保持频率正交" 上, 这要求所有 UE 的 OFDM 符号边界在 gNB 接收天线同时到达

然而, 不同的UE离gNB有远有近! 因此需要: "远的UE提前发"

所以, 对于UE而言, 就有了 "时间提前量"(Timing Advance, TA) 这个概念

(2) TN 中的 TA 机制

5G NR 的 TA 公式:

\[T_{TA} = (N_{TA} + N_{TA,\text{offset}}) \cdot T_c\]

其中:

• \(T_c = 1 / (480000 \times 4096)\) 秒 ≈ 0.509 ns,是 NR 的基本时间单位
• \(N_{TA}\):
  • 由 RAR 中的 12-bit TA Command 初始化 (0-3846), 由 MAC CE 中的 6-bit TA Command 增量更新
  • \(N_{TA} \cdot T_c\) 应该约等于 RTT
• \(N_{TA,\text{offset}}\): 配置项, FR1 默认 25600, FR2 默认 13792
  • 这个偏移本质上是为了避免 UE 在 TDD 切换时上下行时段重叠

UE 收到 TA Command 后:

\[T_{\text{发送时刻}} = T_{\text{下行参考时刻}} - T_{TA}\]

也就是 UE 把自己的发送时刻提前 \(T_{TA}\), 这样信号经过 RTT 后到达 gNB 时, 正好与 gNB 的接收窗口对齐

背后的原理:

TA 的意义是:

让UE的 "UL时序" 整体相对 "DL时序" 提前一个RTT, 使得上行信号到达gNB时 "恰好对齐"

(3) 3GPP NTN 中的 TA 机制

如果直接拿上面TN中的TA公式:

LEO 卫星在 350 km 高度, 过顶仰角变化时单程传播延迟 1.15-2.5 ms, 双程 RTT 2.3-5 ms! 直接超过 TA 字段的表达范围!!!

更糟糕的是, 即使字段够大, TA 维护也是问题: 相对距离变化率高达 ~7 km/s, 对应 TA 漂移率达 2 μs/s

3GPP TS 38.133 规定 TA 偏差超过 0.944 μs 即视为失同步, 意味着即使初始 TA 正确, 0.5 秒内就会失同步...

因此NTN有全新的TA公式:

NTN 把 TA 拆分为四项:

\[T_{TA} = (N_{TA} + N_{TA,\text{offset}} + N_{TA,\text{adj}}^{\text{common}} + N_{TA,\text{adj}}^{\text{UE}}) \cdot T_c\]

• \(N_{TA,\text{adj}}^{\text{common}}\): Common TA
  • 由 SIB19 广播, 等于卫星到地面参考点 (RP) 的 RTT
  • 代表"波束所有 UE 共享的延迟"
• \(N_{TA,\text{adj}}^{\text{UE}}\): UE-specific TA
  • 由 UE 自己用 GNSS 位置 + 卫星星历计算得到
  • 代表"UE 相对于 RP 的 Differential Delay"
• \(N_{TA}\):由 gNB 通过 RAR/MAC CE 下发的微调残差

关键设计点:

在 PRACH 阶段之前, UE 已经用 GNSS + 星历自主计算并应用了 \(N_{TA,\text{adj}}^{\text{common}} + N_{TA,\text{adj}}^{\text{UE}}\)

因此 PRACH preamble 到达卫星时已经基本对齐, RAR 中的 \(N_{TA}\) 只需修正残差 (typically <几十 μs),12-bit 字段绰绰有余

(4) Starlink 中的 TA 机制

这一部分来自《A Variegated Look at Direct-to-Cell Satellites in the Wild》的观测结果.

Starlink 不能要求 UE 修改协议栈, 所以它在卫星侧实现了一个等价机制:

\[TA_{\text{发给 UE}} = RTT - RTT_{RP} + C\]

物理意义:

• 卫星减去一个公共延迟 \(RTT_{RP}\), 使下发的 TA 落入 0-2 ms 字段
• 加常数 \(C\) 防止下发负值

卫星侧记下被减掉的 \(RTT_{RP}\), 在接收上行时用一个公共偏移补回

这本质上是 NTN 协议的 "Common TA" 机制, 但工作量全部压到卫星侧而非 UE 侧

(5) Koffset 和 Kmac 的作用

本质上是个patch, 为了确保UE和gNB在LEO场景(高度动态、时延长...)下, 对于很多过程的时序理解一致

Doppler Shift: 频率同步

(1) 物理起源

Doppler 公式:

\[f_d = \frac{v_r}{c} \cdot f_c\]

LEO 卫星过顶, 径向速度 \(v_r\) 从 \(+7\) km/s 变化到 \(-7\) km/s:

• 在 \(f_c = 2\) GHz (S-band) 上对应 \(\pm 47\) kHz
• 在 \(f_c = 30\) GHz (Ka-band) 上对应 \(\pm 700\) kHz

OFDM 对 CFO (Carrier Frequency Offset) 的容忍度由子载波间隔 \(\Delta f\) 决定:

• LTE: \(\Delta f = 15\) kHz,容忍度约 \(\pm 7.5\) kHz
• NR FR1: 15/30/60 kHz,FR2: 60/120 kHz

LEO 多普勒在 S-band 已经是子载波间隔的 3 倍, 在 Ka-band 是 5-10 倍, 完全无法靠接收机自适应解决, 必须在协议层面有显式补偿

(2) 3GPP NTN 的"两段式补偿"

3GPP NTN 把整条链路分为两段处理:

Service Link (UE ↔ Satellite): UE 负责

• 上行:
  • UE 用 GNSS 位置 + SIB19 中的卫星 ephemeris (位置 + 速度) 计算自己相对卫星的径向速度, 据此预补偿上行发射频率
• 下行:
  • UE 通过 PSS/SSS 直接观测下行的总频偏 (内含"已被卫星预补偿过"的残差), 用 PLL 跟踪

Feeder Link (Satellite ↔ Gateway): 网络侧负责

• 实现自由,3GPP 不规定具体方法
• 通常由 gateway 侧根据已知卫星 ephemeris 做发送"预补偿"
• 这部分 UE 完全不感知

(3) Starlink 中的 Doppler 机制

这一部分来自《A Variegated Look at Direct-to-Cell Satellites in the Wild》的观测结果.

Starlink 受向后兼容约束, 无法要求 UE 用 GNSS 做"上行预补偿"

它的策略 (论文反向工程):

• 下行:
  • 卫星按"波束参考点 RP 处的多普勒"反向偏移发射频率: \(f_{tx} = f_c - f_{d,RP}\)
  • UE 测得的残差只由 UE 与 RP 的位置差决定 (5.3 kHz 中位)
• 上行:
  • UE 完全不补偿! 卫星接收机的频率跟踪环必须吞掉全部 ±47 kHz doppler shift

后者就是论文 §7.1 中显示的 "Starlink 在 PRACH 失败率上比 NTN 差几乎一个数量级" 的原因

卫星检测器在数十 kHz 频偏下, Zadoff-Chu 序列 的相关"峰"会严重偏移和扩散, 导致漏检

HARQ: 链路层重传机制

(1) HARQ vs 纯 ARQ vs TCP: 三层重传的本质差异

维度	TCP 重传	RLC AM ARQ	HARQ
协议层	传输层 (端到端)	RLC (链路层)	MAC + PHY (链路层)
反馈延迟	端到端 RTT (100+ ms)	UE-gNB RTT (1-10 ms)	UE-gNB RTT, <1 ms
触发判据	重复 ACK / RTO 超时	RLC Status Report (周期性)	CRC + 物理层 ACK/NACK
重传内容	完全相同	完全相同	可不同 (Incremental Redundancy)
失败传输的价值	丢弃	丢弃	软合并->积累能量
流水线	cwnd 控制	RLC Window (AM)	多个并行进程 (stop-and-wait per process)

Soft Combining是什么

在信息论中, 一个非常重要的点是: 可以"累积能量"

比如: https://info-nrlte.com/tag/soft-combining/

看这个例子:

HARQ 与纯 ARQ 的本质差异在于:

接收端不丢弃失败的传输, 而是把解调后的 LLR (Log-Likelihood Ratio, 软信息) 存入软合并缓冲区

下次重传时与之前的 LLR 合并再解码

(2) HARQ Stop/Wait 与多进程并行机制

HARQ 单个进程是 stop-and-wait: 发送一个 TB 后必须等到反馈 (ACK/NACK) 才能在该进程上发送下一个

如果只有一个进程, 在反馈延迟期间链路会闲置, 吞吐率上限 = TB size / 进程 RTT

解决方案:多进程并行!

当进程 1 在等反馈时,进程 2/3/4...继续发送新的 TB

进程数的工程取值:

• LTE: 8 进程 (TDD) / 8 进程 (FDD,UL 同步,DL 异步)
• NR: 最大 16 进程 (UL 和 DL 都异步)
• NR-NTN Rel-17/18: 最大 32 进程 (TS 38.321 enhanced)

HARQ Stalling Issue

"HARQ 单个进程是 stop-and-wait: 发送一个 TB 后必须等到反馈 (ACK/NACK) 才能在该进程上发送下一个"

根据这个特性我们不难发现其 "依赖" 的缺点, 如果始终得不到反馈, 就会卡死; 以及如果反馈时间很长, 比如 LEO 里就是这样, 那就会每次都"白白浪费很长时间"

详见 SIGMETRICS'26 的论文描述

(3) Sync/ASync HARQ

NTN 的延伸:

Rel-18 IoT NTN 引入 "asynchronous HARQ with HARQ feedback disabling" (TS 36.331 update)

允许网络配置某些 HARQ 进程关闭反馈, UE 发完不等 ACK 直接复用进程

(4) NTN 的 HARQ 困境与解法

问题: LEO RTT 5+ ms,GEO RTT 540+ ms. 即使 16 进程并行, GEO 单进程 RTT 内能利用的吞吐 = 16 × TB_size / 540ms, 对宽带吞吐严重受限

Rel-17 NTN 的方案:

1. Number of HARQ processes 增至 32 (Rel-17)
2. Per-process HARQ feedback disabling:
   • RRC 配置 harq-FeedbackEnablerDCI-1-1 等, 允许某些进程"发完即弃", 由 RLC AM 兜底
3. Disable HARQ entirely for GEO:
   • 特定场景下完全关闭 HARQ, 所有可靠性由 RLC 承担

Starlink 的极端选择:

maxHARQ-Tx = 1 (首次失败立即放弃, 完全不进行 HARQ 重传)

这等于把 HARQ 退化为单次传输, 所有可靠性由 RLC AM 重传维持

这当然会导致很多问题, 详见论文~

所以在 NTN 中, 完全保留多进程 HARQ + 适当扩展进程数 比 完全禁用 HARQ + 强化 RLC 是更优解!

这也是为什么 3GPP NTN 选择前者而不是后者~

数据流动全过程

用 claude 生成的一张自顶向下的图解, 经多次检查对拍, 没什么问题.

很直观:

---

现在我们就来进入终极环节: End-to-end Dataflow

我们用 3GPP NTN 标准协议栈, 且使用 regenerative mode

初始条件:

• UE 处于 RRC_IDLE, 刚开机或刚移出无信号区
• 一颗 LEO 卫星正从地平线升起, 即将进入 UE 视野

架构假设:

Regenerative payload: 所有协议交互的对端就是卫星本身; 卫星通过 ISL 或 feeder link 连接到地面核心网, 但这对 Uu 接口(UE-Sat)透明

use nanobanana for drawing. academic style:

详细解读这个过程，架构和交互都要有，严格遵循交互过程

"初始条件:

• UE 处于 RRC_IDLE, 刚开机或刚移出无信号区
• 一颗 LEO 卫星正从地平线升起, 即将进入 UE 视野

架构假设: Regenerative payload

• 卫星上承载完整或部分 gNB 功能(典型为 onboard gNB-DU 或完整 gNB)
• 所有协议交互的对端就是卫星本身
• 卫星通过 ISL 或 feeder link 连接到地面核心网, 但这对 Uu 接口(UE ↔ 卫星)透明

下面按物理时间顺序分七个阶段展开,每阶段精确说明: 信道、方向、信息载荷、为什么必须按此顺序

阶段 0: 同步前奏

UE 刚开机时不知道任何信息. 它做两件并行的事:

(a) 在 NTN 频段上盲扫描

UE 内部预存 3GPP 定义的 NTN 频段:

• n255 / n256 / n257 (S-band, FR1-NTN)
• n510 / n511 / n512 (Ka-band, FR2-NTN, Rel-18 引入)

UE 在这些频段上逐一搜索 SSB 候选位置

此阶段纯接收, UE 不发送任何信号: 它甚至无法发送, 因为还没有时间基准、频偏补偿量、上行授权

(b) GNSS 模块启动

3GPP TS 38.300 §16.14.2.1 规定: Rel-17 NTN UE 必须具备 GNSS 能力

UE 启动 GNSS, 尝试获取自身位置 \(\vec{p}_{UE}\)

GNSS 锁定通常需要数秒到数十秒(冷启动)

阶段 1: 下行同步获取

Cell Search

• 方向: 卫星 → UE (单向)
• 信道: SSB (= PSS + SSS + PBCH)
• 目标: 获得"下行帧"定时、物理小区 ID、SIB1 入口

1.1 PSS 检测

卫星周期性广播 SSB (默认周期 20 ms)。UE 对接收信号做 PSS 时域相关检测:

• 粗时间同步
• 粗频率同步
• 小区组 ID

PS: 卫星上的 gNB 仍负责下行 Doppler 预补偿

1.2 SSS 检测

UE 在 PSS 给定位置附近搜索 SSS, 得到 "完整物理小区 ID"

\[N_{ID}^{cell} = 3 \cdot N_{ID}^{(1)} + N_{ID}^{(2)} \in \{0, ..., 1007\}\]

1.3 PBCH 解码: 获取 MIB

UE 解 PBCH, 获得 MIB, 找到 SIB-1 入口

PBCH 承载 MIB (Master Information Block):

• systemFrameNumber:
  • 10 ms 帧号
• subCarrierSpacingCommon:
  • SIB1 使用的 SCS
• ssb-SubcarrierOffset + pdcch-ConfigSIB1:
  • SIB1 的调度入口

两级跳转设计:

MIB 极小但全频段必发; SIB1 较大但只是"指针", 指向更多 SI

这种分层让 UE 可以渐进式获取所需信息, 避免每次都解码大块 SI

阶段 2: 系统信息获取

SIB-1 && SIB-19

• 方向: 卫星 → UE (单向)
• 信道: PDCCH + PDSCH
• 目标: 获得小区接入参数 + NTN 卫星辅助信息

2.1 解码 SIB1

UE 在 CORESET#0 上盲检测 PDCCH

成功解扰的 DCI 指向 PDSCH, PDSCH 上承载 SIB1

SIB1 关键内容:

• PLMN-IdentityList: UE 判断小区是否属于自己运营商
• TAC: Tracking Area Code. 追踪地区
• cellAccessRelatedInfo / cellSelectionInfo
• servingCellConfigCommon: RACH 配置、初始 BWP、PDCCH/PDSCH 公共配置

NTN 识别点

UE 在 si-SchedulingInfo 中看到 SIB19 被广播, 即可确认"这是一个 NTN 小区"

地面 5G 小区不广播 SIB19!

2.2 解码 SIB19 (NTN 专属)

UE 在指定的 SI-window 内解码 SIB19 (TS 38.331 §6.3.1)。核心字段:

• ephemerisInfo: 服务卫星星历
  • \(\vec{p}_{Sat}(t_0), \vec{v}_{Sat}(t_0)\). 在 ECEF 坐标系
• commonTA-r17: 卫星到参考点 (RP) 的 RTT
• commonTA-DriftRate / DriftVariation: Common TA 的一阶/二阶变化率 (LEO 必备)
• epochTime: 上述参数的参考时刻 \(t_0\)
• kOffset: 小区级 NTN 调度偏移 (0-1023 slot)
• kMac: MAC CE 应用时序的额外偏移
• t-Service: 本波束服务停止时刻 (quasi-Earth-fixed beam)
• ...

至此 UE 拥有所有接入所需信息. 整个阶段 0-2 中,UE 没有发送任何信号

阶段 3: 上行预补偿计算

• 方向: 无, UE本地计算
• 前提: GNSS 锁定 + SIB19 解码完成
• 目标: 算出能让上行信号 "恰好对齐卫星接收窗" 的 TA + Doppler 预补偿量

(1) 几何计算

\[\vec{p}_{Sat}(t) = \vec{p}_{Sat}(t_0) + \vec{v}_{Sat}(t_0) \cdot (t - t_0) \quad \text{(Format 1)}\]

• UE 自己的位置 \(\vec{p}_{UE}\) 来自 GNSS
• RP 的位置 \(\vec{p}_{RP}\) 来自 SIB19 的 referenceLocation

...

(2) TA 预补偿

\[T_{TA} = (N_{TA} + N_{TA,\text{offset}} + N_{TA,\text{adj}}^{\text{common}} + N_{TA,\text{adj}}^{UE}) \cdot T_c\]

(3) Doppler 预补偿

服务链路上的 Doppler:

\[f_{d,\text{service}} = -\frac{v_r}{c} \cdot f_c\]

UE 把这个偏移应用到上行发射频率:

\[f_{tx,UE} = f_c + f_{d,\text{service}}\]

架构

• "服务链路" Doppler: 由 UE 用 GNSS+ephemeris 预补偿
• "Feeder 链路" Doppler: 由网络侧实现负责
  • 对 UE 透明, 3GPP 不规定具体方法

在 Regenerative 架构下没有独立的 "feeder 链路" Doppler 问题, 因为: 卫星上的 gNB 直接生成基带信号, dist(gNB, sat) = 0.

但卫星与地面核心网之间的 NG 接口仍要通过 feeder link, 这部分由 SIB19 中的 commonTA 涵盖

阶段 4: 随机接入

• 方向: 双向
• 信道: PRACH / PDCCH / PDSCH / PUSCH 全明星阵容~
• 目标: UE 从 RRC_IDLE 转入 RRC_CONNECTED, 获得 C-RNTI

这是 UE 第一次发送上行信号. Msg1 → Msg2 → Msg3 → Msg4 严格顺序执行

4.1 Msg1 — UE 发送 PRACH Preamble, 随机接入

信道: PRACH (上行)

UE 应用阶段 3 计算的 (Common TA + UE-specific TA) + 阶段 3 的 Doppler 预补偿, 在 SIB1 配置的 PRACH occasion 上发送 preamble

4.2 Msg2 — 卫星发送 RAR

RAR: Random Access Response

信道: PDCCH + PDSCH (下行)

卫星(onboard gNB) 检测到 preamble 后, 在 ra-ResponseWindow(NTN 中此窗口长度配置考虑了 Koffset)内通过 PDCCH 调度 PDSCH, PDSCH 承载 RAR

RAR 内容:

• Preamble Index: 回显,UE 据此匹配
• TA Command (12 bits): 卫星实测的残差 \(N_{TA}\)
  • 因为 UE 已经做了 Common TA + UE-specific TA 预补偿
  • 卫星实测到的偏差只是几百 ns 到几 μs 的小残差, 12-bit 字段绰绰有余
• UL Grant for Msg3: 授权 PUSCH 资源
• Temporary C-RNTI (TC-RNTI)

UE 用 RA-RNTI 解扰 PDCCH, 匹配 Preamble Index 后认领 RAR

4.3 Msg3 — UE 发送 RRC Setup Request

信道: PUSCH (上行)

UE 在 RAR 指定的 PUSCH 资源上发 Msg3

TA 此时由四项完整组成:

• \(N_{TA,\text{adj}}^{\text{common}}\): SIB19, UE 自算
• \(N_{TA,\text{adj}}^{UE}\): GNSS + ephemeris, UE 自算
• \(N_{TA}\): 4.2 中 RAR 下发的残差
• \(N_{TA,\text{offset}}\): 协议常数

PUSCH 调度时序在 NTN 中受 Koffset 约束:

\[\text{Msg3 PUSCH slot} = n_{\text{RAR}} + K_2 + K_{\text{offset}} + \Delta\]

(\(\Delta\) 是 SCS-specific 的额外延迟)

Msg3 承载:

• CCCH 上的 RRCSetupRequest 或 RRCResumeRequest
• UE Identity: 5G-S-TMSI(已注册过) 或 39-bit 随机值(首次接入)
• Establishment Cause: 接入原因

4.4 Msg4 — 卫星发送 Contention Resolution

信道: PDCCH + PDSCH (下行)

卫星把 Msg3 中的 UE Identity 完整回显在 UE Contention Resolution Identity MAC CE 中, 通过 PDSCH 下发

UE 比对 Identity:

• 匹配 → 接入成功, UE 进入 RRC_CONNECTED
• 不匹配 → preamble 碰撞且自己输了, 退避后重新从 Msg1 开始

UE 在 PUCCH 上发 1-bit HARQ-ACK 确认 Msg4. 这是 UE 首次使用 PUCCH.

为提升上行覆盖, R-18 引入 PUCCH repetition for Msg4 HARQ-ACK: Msg4 ACK 可以在多个 slot 上重复发送以累积能量

阶段 5: RRC 连接 + NAS 注册

• 方向: 双向
• 信道: PDCCH + PDSCH (下行) / PDCCH + PUSCH (上行)
• 目标: 建立 SRB1. NAS 注册到 5GC, 建立 PDU Session

这一部分聚焦网元的交互

1. RRC Setup
   • 专用 PUCCH 资源配置
   • NTN-Config
2. Authentication && Security
   • 做安全的人关心, 笔者不关心 :)
3. PDU Session Establishment
   • Registration Accept: 5GC 允许 UE 接入, 下发 5G-GUTI
   • PDU Session Establishment Request / Accept: 建立用户面会话
   • gNB 通过 RRCReconfiguration 配置 DRB(Data Radio Bearer)、QoS Flow Mapping

阶段 6: 稳态数据传输

• 方向: 双向并行
• 目标: 用户数据(IP 包)通过 User Plane 流过

回顾一下:

• DL Data 跟 先前提到的一样, 传送门
• UL 也是一样, 注意要先授权 (by SR), 而后才能发送数据

阶段 7: 持续维护&&切换

• 方向: 双向并行, 与阶段 6 重叠运行
• 目标: 维持服务, 卫星过顶前切换到下一颗

(1) TA 持续维护 ✅

(2) Doppler 持续维护 ✅

(3) SIB19 重读 🌟

ntn-UlSyncValidityDuration 到期前, UE 必须重新解码 SIB19

过期后:

• UE 必须停止所有上行传输, 直至获取新 SIB19
• 新 SIB19 提供新的 epochTime 和漂移参数, UE 重置外推基准

如果 ephemeris 更新晚了, UE 会经历"上行间歇性中断"! 这是 NTN 链路的一个 signature

(4) 测量与切换 🌟 🧠

UE 周期性测量服务/邻小区 RSRP/RSRQ/SINR, 通过 MeasurementReport(在 PUSCH 上的 RRC 消息)上报

NTN 切换触发器:

• RSRP-based: Event A1-A6(传统)
• NTN 新增:
  • 基于位置:UE 距 referenceLocation 超 distanceThresh
  • 基于时间:t-Service 临近,主动切换
  • 基于 TA:TA 超过门限
  • 基于仰角:服务卫星仰角降低到门限以下

切换执行机制:

• 传统 HO:
  • gNB 发 RRCReconfiguration with reconfigurationWithSync, UE 重做 PRACH
• CHO (Conditional Handover):
  • gNB 提前下发多个候选目标小区的配置 + 触发条件
  • UE 在条件满足时自主切换, 避免长 RTT 下的命令延迟
• RACH-less HO:
  • 利用源/目标卫星的已知几何关系, 目标 cell 直接给 UE 配置 TA
  • UE 跳过 PRACH 直接发 RRCReconfigurationComplete
• DAPS HO 不支持(明确禁用):
  • 双连接对卫星硬件资源消耗过大

NTN 的'既要又要'困境

• 基于信号质量(RSRP)的传统切换: 在快衰落下容易 ping-pong
• 基于位置/时间的 NTN 新增触发器: 解决了 ping-pong, 但可能让 UE 连接到 信号强度更差而"几何上更近"的卫星

---

TLDR: 整体时间线

阶段	典型耗时 (LEO)	信道	UE 状态
0 (盲扫描 + GNSS)	几秒(GNSS 主导)	—	RRC_IDLE,纯接收
1 (Cell Search)	50-200 ms	SSB	RRC_IDLE,纯接收
2 (SIB1 + SIB19)	100-500 ms	PDCCH+PDSCH (SI-RNTI)	RRC_IDLE,纯接收
3 (本地预补偿计算)	< 10 ms	—	RRC_IDLE,本地处理
4 (RA, 4-Step)	50-200 ms (无重传)	PRACH/PDCCH/PDSCH/PUSCH	IDLE → CONNECTED
5 (RRC + NAS)	1-3 秒	PDCCH/PDSCH/PUSCH	CONNECTED,认证中
6 (数据传输: RRC-Auth-PDU)	卫星过顶剩余时间	PDCCH/PDSCH/PUSCH/PUCCH	CONNECTED,生产
7 (切换)	50-500 ms (CHO/RACH-less 更快)	PDCCH/PDSCH (+PRACH if needed)	CONNECTED,切换中