通信人家园

标题: NTN的RRC/MAC状态机困境——信令还没到，卫星已飞走 [查看完整版帖子] [打印本页]

时间: 2026-5-2 20:44

作者: 浩瀚颖腾 标题: NTN的RRC/MAC状态机困境——信令还没到，卫星已飞走

一、引言

5G NR从设计之初就是为地面蜂窝网络准备的。基站与终端距离几公里，单向时延不到1毫秒，信令一问一答几乎感觉不到延迟。SFN（系统帧号）每10.24秒绕回一次，在地面足够用了，一个RRC信令流程也就几十毫秒，不会跨周期。这套紧耦合的RRC/MAC状态机运行得非常稳定。

但把5G搬上卫星，尤其是GEO（地球静止轨道）卫星，情况就变了。距离一下子拉到36000公里，单向时延约250毫秒。一个RRC信令从UE到卫星再到地面信关站，处理完再回来，秒级过去了。在这个尺度上，原本假设“连续、低延迟、可靠”的物理层时间基准开始松动，问题接踵而至。

二、RRC状态机：物理层一抖，RRC就重建

地面上，UE在CONNECTED状态依赖物理层同步的持续保持。如果信道质量下降，基站会通过RRC重配调整参数，或者UE触发测量报告、切换流程。本质上，物理层波动可以通过信令的快速反馈来补偿。

在GEO场景下，一条测量报告从UE发出到基站收到，250ms已过；基站再回一条重配指令，又是250ms。前后加起来超过半秒。在这半秒里，卫星和UE的相对位置、信道质量可能已经发生了明显变化。更致命的是，3GPP为了NTN引入的T430等有效性定时器。

T430规定了UE收到的辅助信息（如公共TA、星历）的有效期。一旦超时，UE就认为同步不可靠，必须重新获取辅助信息，甚至触发RRC重建。重建意味着重新随机接入、重新配置资源，中断时间以秒计。在卫星场景下，这种重建可能频繁发生——因为卫星移动快，辅助信息更新周期短。

本质上，RRC状态机绑死了物理层的“实时同步”状态。物理层稍有风吹草动，RRC就要重启流程。这种紧耦合在地面可以接受，因为反馈快；到了GEO，反馈慢如蜗牛，RRC就变成了一个敏感易惊的状态机。

三、MAC调度与“遥远的不确定性”

MAC层的调度器依赖UE的调度请求(SR)、缓存状态报告(BSR)，以及基站下发的DCI和定时提前命令(TA)。地面场景下，SR→DCI→PUSCH的流程几个毫秒就完成了，TA闭环几个时隙就能收敛。

到了GEO，SR从发到收DCI，至少一个RTT（约500ms）。UE的缓存数据可能在等待期间已经变了。基站拿到BSR时，UE的实际缓存状态已经不同了。整个“问-答”调度模式的效率急剧下降。

3GPP的NTN规范引入了“开环辅助”方案：UE用自己的GNSS位置，结合基站广播的星历和参考点，自行推算上行TA。这解决了闭环太慢的问题，但把复杂度甩给了UE，同时对GPS的可用性提出了硬性要求——没有GPS/GNSS，UE根本无法工作。而且这是一种开环推算，没有实时反馈修正，精度完全依赖UE定位、星历精度和时间同步三者的一致性。任何一个环节出偏差，信号就可能落在基站接收窗口之外，而基站无法主动帮UE纠正——因为闭环信令来不及。

四、SFN绕回与“状态漂移”

SFN每1024帧（10.24秒）会从1023翻转到0。地面上，一个RRC信令流程短于10秒，几乎不会跨周期。但在GEO场景，一个测量上报+重配的RRC信令交互可能耗时超过1秒，如果UE或基站侧在跨SFN边界时处理不当，就会导致“看到的SFN不一致”的情况。

举例：基站在SFN=1022时下发了一条携带k_offset的DCI，UE处理这个DCI时本地SFN已经绕回0，那么UE和基站对“定时关系”的理解就可能出现偏差。标准虽然规定了一些对齐规则，但本质上是对紧耦合的一种“打补丁”，没有解决逻辑状态对物理帧号的刚性依赖。

五、小结：紧耦合的代价

RRC状态机、MAC调度器、SFN时序——这些都是5G NR的核心设计。它们在地面高效运转，是因为物理层时间基准是稳定、连续、低延迟的。一旦把这个体系搬到GEO卫星上，每一个假设都被挑战。3GPP通过引入大量补丁（k_offset、TA开环辅助、T430定时器、参考点广播等）试图让5G NTN“能工作”，但系统的复杂度在膨胀，对GNSS的依赖在加深，故障模式在增多。

问题的根源不在参数设置，而在架构本身：RRC/MAC状态机与物理层帧号（SFN/Slot）的紧耦合。

能不能设计一种新的方式，让上层的状态机不再依赖物理层的帧号和时间基准？让通信双方即便在长时延、无GPS、无持续信令的环境下，仍然能保持状态同步、资源自洽？

下一篇文章将讨论这种“解耦”的思路——逻辑时间轴独立于物理层，以及DSF（动态安全根基）如何实现它。如果你对这个方向感兴趣，欢迎留言讨论。

通信人家园 (https://www.txrjy.com/)