5G NTN核心网架构和底层功能部署探讨

张开发
2026/4/10 18:47:57 15 分钟阅读

分享文章

5G NTN核心网架构和底层功能部署探讨
专题讨论一根据3GPP R17/R18标准以及最新的产业实践如中国电信、爱立信等厂商的白皮书目前的主流技术路线已经收敛5GC的核心控制面功能包括AMF倾向于全部下沉到地面网关Feeder Link Gateway而不是放在星上。虽然“再生式载荷”Regenerative Payload允许卫星在星上处理基带信号即gNB-DU/CU在星上但AMF接入和移动性管理功能通常被设计为驻留在地面。以下我结合你提供的参考资料详细解析这种架构的分割逻辑、星间协作方式以及核心网的具体信令流程。1. 功能分割星上(gNB) vs 地面(AMF/UPF)在当前的5G NTN主流架构基于3GPP TS 23.501和TS 23.273中功能分割非常明确1.1 地面部分核心网 5GCAMF (接入和移动性管理功能)完全位于地面。职责负责UE的注册、连接管理、可达性管理、移动性锚点针对信令、安全锚点SEAF。原因AMF需要维护全局的UE上下文数据库且需要与地面网络UDM、PCF进行高频交互。如果AMF在星上每次卫星飞过不同国家/区域都需要与地面UDM建立长时延连接且卫星切换会导致AMF频繁重选造成信令风暴。UPF (用户面功能)通常位于地面网关但在特定场景如星间链路ISL打通下部分UPF功能如分支点可能涉及星上但这属于R19/R20的演进方向。1.2 星上部分无线接入网 NG-RANgNB (基站)位于星上再生式载荷。职责射频处理、基带处理、RRC无线资源控制、PDCP/RLC/MAC/PHY。角色卫星就是一个“飞行的基站”。它通过N2接口控制面和N3接口用户面连接到地面的AMF和UPF。结论目前的协议倾向于“星上只有基站(gNB)核心网(AMF)在地面”。2. 如果AMF在地面卫星之间如何协作处理移动性既然AMF在地面卫星gNB之间不需要像“分布式大脑”那样协商复杂的移动性逻辑它们只需要执行“受控的移交”。2.1 协作模式地面AMF是“指挥官”卫星是“执行者”当UE从卫星ASource gNB移动到卫星BTarget gNB时并不是卫星A直接告诉卫星B“把这个人接过去”而是通过地面AMF进行协调。星间链路ISL的作用如果卫星之间有ISL星间链路数据可以直接在星间转发Xn接口 over ISL减少回传地面的时延。但控制面信令N2通常还是经由各自的馈电链路Feeder Link回到地面AMF。2.2 具体的移动性管理流程基于Xn切换这是最典型的星间切换流程参考3GPP TS 23.502测量与触发UE测量卫星A和卫星B的信号上报测量报告包含T1/D2事件。卫星ASource gNB根据报告决定发起切换。切换请求Xn接口卫星A通过Xn接口可能经过ISL也可能经过地面向卫星B发送 HANDOVER REQUEST。注意这里卫星之间只传递无线上下文Radio Context不涉及核心网移动性逻辑。路径切换核心网介入卫星B接纳UE后向地面AMF发送 PATH SWITCH REQUEST路径切换请求。关键点这是告诉核心网“UE现在归我管了请把下行数据发给我”。核心网确认AMF更新UE上下文通知UPF修改数据路径。AMF向卫星B发送 PATH SWITCH REQUEST ACK。协作总结卫星之间通过Xn接口传递“接力棒”UE上下文但最终的“入网确认”和“路径确权”必须由地面AMF完成。3. 为什么协议倾向于AMF回到地面有利支撑材料你提到的“协议倾向于所有5GC移动性管理和AMF都回到地面网关执行”是完全正确的。以下是支撑这一结论的技术逻辑和材料依据3.1 支撑材料一3GPP标准的“透明”与“再生”统一性依据根据3GPP TS 23.501 (5G System Architecture)和TS 23.273 (5G Location Services)。解析标准定义NTN是5G系统的延伸。无论卫星是“弯管”透明转发还是“再生”星上基站对于核心网5GC而言它看到的只是一个远程的gNB。逻辑核心网的设计假设是“控制面节点是相对稳定的”。LEO卫星的高速移动性每分钟7km与AMF的稳定性要求维护海量UE状态机是互斥的。因此AMF必须固定在地面卫星只作为接入节点。3.2 支撑材料二N2接口的动态管理与“受控移除”依据参考你提供的材料《驾驭星辰之链解析5G NTN再生式卫星载荷的N2接口与连接管理》。核心观点文章明确指出由于卫星高速移动N2接口gNB与AMF之间需要频繁建立和拆除。解决方案采用“NG Removal Procedure”NG接口移除流程。当卫星预知将飞离AMF服务范围时会触发“优雅拆除”。关键操作AMF会先触发“UE Context Release”UE上下文释放将UE置为空闲态CM-IDLE然后再拆除与卫星的N2连接。结论这证明了移动性管理的决策权决定何时释放UE、何时拆除连接完全掌握在地面AMF手中而不是卫星自主决定。3.3 支撑材料三信令风暴与星历管理依据材料《NR NTN移动性管理增强策略分析》。解析如果AMF在星上随着卫星飞离UE需要频繁进行跨AMF的注册更新Registration Update这会导致信令风暴。对策标准引入了多TAI广播和地面固定TA概念。这意味着位置管理的逻辑TA列表的维护是在地面网络规划好的卫星只是负责广播这些信息。卫星本身不具备“管理TA”的能力它只是一个广播塔。4. 具体的信令消息与规程AMF在地面版基于“AMF在地面”的架构以下是关键的移动性管理信令流程4.1 初始入网Initial AccessUE - 卫星(gNB): RRC Setup Request (含GNSS位置信息)。卫星(gNB) - 地面(AMF): N2 Initial UE Message (通过Feeder Link)。注卫星利用UE上报的GNSS位置计算TA定时提前量并在N2消息中透传给AMF。地面(AMF) - 卫星(gNB): N2 Initial Context Setup Request (含安全密钥、UE能力)。卫星(gNB) - UE: RRC Reconfiguration (建立SRB2/DRB)。4.2 星间切换Inter-Satellite HandoverUE - 源卫星: Measurement Report (触发T1/D2事件)。源卫星 - 目标卫星: Xn HANDOVER REQUEST (通过ISL或地面转发)。目标卫星 - 源卫星: Xn HANDOVER REQUEST ACK。源卫星 - UE: RRC Reconfiguration (含切换命令)。UE - 目标卫星: RRC Reconfiguration Complete (同步完成)。目标卫星 - 地面(AMF): N2 PATH SWITCH REQUEST (关键步骤通知核心网更新路径)。地面(AMF) - 地面(UPF): N4 Session Modification (修改下行数据隧道)。地面(AMF) - 目标卫星: N2 PATH SWITCH REQUEST ACK。总结5G NTN的当前协议架构R17/R18坚定地将AMF保留在地面。星上负责处理“快变”的物理层和链路层波形、调度、HARQ、Xn切换执行。地面负责处理“慢变”但“复杂”的控制层AMF、SMF、UDM。这种架构避免了将核心网的复杂性带入太空利用地面成熟的云计算资源处理移动性管理是目前最务实且标准化的选择。专题讨论二如果5GC的AMF全部在地面但为了追求数据面转发效率和低时延效果UPF在星上的话如何进行AMF对会话建立和UPF的建立和切换时的转发路由怎样让用户端对于数据服务过程无感请详尽分析涉及到的信令消息和规程这是一个非常前沿且极具挑战性的架构设计属于5G-AdvancedR18及6G演进的深水区。当控制面AMF在地面而用户面UPF在星上时我们面临的核心矛盾是控制信令的长时延往返地面与用户数据低时延星上处理之间的不匹配。为了实现“用户端无感”且保证数据转发效率必须采用“控制与转发分离 星上锚点 预测式路径切换”的策略。以下是基于3GPP架构演进逻辑的详细技术分析。1. 核心架构设计星上UPF的角色定义在这种架构下星上的UPF不能只是一个简单的“弯管”它必须具备PDU会话锚点PSA的功能或者至少具备上行分类器UL-CL的功能。地面AMF/SMF负责“大脑”工作。处理注册、鉴权、会话建立请求、计费策略。星上UPF负责“手脚”工作。本地锚点作为PDU会话的锚点数据直接在星上路由到互联网或星间链路无需回传地面实现低时延。缓存与缓冲在控制信令往返地面的几百毫秒内暂存用户数据。2. 场景一会话建立流程Session Establishment挑战UE发起请求 - 卫星 - 地面AMF/SMF - 卫星UPF。这个往返时延RTT可能高达几百毫秒LEO甚至数秒GEO。如何让UE不超时解决方案分步建立与预配置详细信令规程UE - 星上gNB发送 PDU Session Establishment Request。星上gNB - 地面AMF通过N2接口转发请求。注意此时链路时延较大。地面SMF决策SMF根据本地策略决定“该会话由星上UPF服务”。SMF生成N4会话建立规则PDR/FAR/QER。地面SMF - 星上UPF发送N4 Session Establishment Request。关键优化SMF在下发规则时会包含“预授权资源”。SMF告诉星上UPF“我给你授权了100Mbps的带宽你先自己管着不用事事汇报。”星上UPF - 地面SMF确认N4会话建立。地面AMF - 星上gNB - UE发送 PDU Session Establishment Accept。如何做到“无感”本地响应机制星上gNB在收到UE请求的瞬间可以先回复一个RRC层的“挂起”或“处理中”信号防止UE因空口超时而重发。快速路径激活一旦星上UPF收到N4确认它立即激活数据转发。由于UPF就在gNB旁边甚至共板卡数据面建立几乎是瞬时的。3. 场景二移动性与切换时的转发路由Handover Forwarding挑战这是最难的部分。当UE从卫星AUPF-A切换到卫星BUPF-B时如果必须等地面SMF来指挥业务必断。解决方案基于Xn接口的“先斩后奏” 星间链路ISL转发详细信令规程触发阶段UE上报测量报告T1/D2事件。源卫星A决定发起切换。准备阶段星间直接交互源卫星A - 目标卫星B通过ISL发送 Xn HANDOVER REQUEST。目标卫星B在本地预分配资源并预配置本地UPF-B。关键点此时地面SMF完全不知情。卫星B的UPF已经准备好接收数据了。执行阶段数据不断流源卫星A - UE发送切换命令。数据转发关键在UE切换过去的几百毫秒内源卫星A的UPF通过星间链路ISL直接将下行数据包转发给目标卫星B的UPF再由B发给UE。效果数据走的是“星间高速公路”完全不经过地面时延极低用户无感。完成阶段通知地面UE接入卫星B成功后卫星B向地面AMF发送 N2 PATH SWITCH REQUEST。地面SMF收到请求更新核心网记录将下行数据的主路径从“发往卫星A”改为“发往卫星B”。地面SMF通知卫星A释放资源。4. 关键技术支撑如何让用户端“无感”为了实现上述流程协议层面必须有三个“神器”4.1 预授权与无状态UPF原理地面SMF不需要对每一个数据包进行审批。SMF给星上UPF下发一套“通用规则”。只要流量在规则内例如非敏感流量、带宽未超标星上UPF可以自主处理无需每次交互都回地面确认。协议支撑3GPP R16/R17定义的CP/UP分离CUPS架构的增强版。4.2 星间链路ISL作为Xn-U接口原理切换时的数据转发Data Forwarding不走地面直接走卫星间的激光链路。协议支撑定义星间链路的GTP-U隧道协议。卫星A的UPF封装数据包目的IP是卫星B的UPF。4.3 预测式路径切换原理利用卫星星历的可预测性。地面SMF可以提前计算出“5分钟后UE将进入卫星B覆盖区”。操作地面SMF可以提前向卫星B下发N4会话建立请求Pre-setup。当切换真正发生时卫星B的UPF已经是“热备”状态无需等待信令直接接管数据。5. 总结信令与数据流向图解表格阶段控制面信令 (N2/N11)用户面数据 (N3/N9)关键动作1. 会话建立UE - 星A -地面AMF/SMF- 星A(无)地面SMF下发规则授权星上UPF自主转发。2. 数据传输(静默)UE -星上UPF- 互联网数据不出星极低时延。3. 切换决策UE - 星A (测量报告)(无)星A判断需切换。4. 切换执行星A -星B(Xn接口)星A_UPF -(ISL)-星B_UPF- UE数据走星间链路转发不经过地面。5. 路径更新星B -地面AMF(Path Switch)地面UPF - 星B_UPF - UE切换完成后通知地面更新主路径。结论要让AMF在地面而UPF在星上核心在于“控制面滞后用户面超前”。建立时靠SMF的预授权机制减少交互次数。切换时靠星间链路ISL进行数据搬运靠Xn接口进行本地协商最后再异步通知地面AMF。这种架构完美解决了“信令回传慢”和“数据要求快”的矛盾是未来6G空天地一体化网络的标准形态。专题讨论三在“AMF在地面、UPF在星上”的架构下除了常规的会话建立和切换流程要实现真正的电信级服务还有三个极具挑战性的深层技术问题需要关注。这些问题直接决定了网络是“能通就行”还是“好用稳定”。以下是针对这三个关键问题的深度分析及相关信令规程 关键问题一星上UPF的“断连生存”与本地会话管理问题分析当卫星飞出地面信关站Gateway的视野或者星地链路Feeder Link因天气等原因中断时地面AMF/SMF与星上UPF的N4接口会断开。传统机制一旦N4心跳丢失地面SMF会认为UPF“挂了”立即触发会话释放导致用户断网。NTN需求卫星虽然看不见地面站了但它在天上还能服务用户通过星间链路或等待下一个信关站。星上UPF必须能够“独立生存”在断连期间维持会话甚至处理简单的移动性。解决方案本地会话管理Local SM与心跳保活相关信令与规程N4 会话上下文增强在N4接口正常时地面SMF下发规则时携带一个“生存时间Survival Time”参数。规则“如果N4断了只要不超过T秒你星上UPF就继续按旧规则转发数据不要丢弃包。”本地心跳代理星上gNB或共板的计算单元充当代理向星上UPF发送伪造的“心跳包”欺骗UPF认为控制面依然连接防止UPF因超时自动释放会话。重连后的状态同步当卫星重新连接地面或连接新信关站后星上UPF向地面SMF发送N4 Session Report Request携带 Usage Report。内容“刚才断连了300秒我帮用户转发了500MB流量这是计费记录。”地面SMF更新上下文继续正常管理。 关键问题二超长时延下的“竞态条件”处理问题分析在LEO场景下星地往返时延RTT可能达到100ms-300ms。场景UE因为信号不好主动发起了“重建请求RRC Reestablishment”或者“去注册Deregister”。冲突与此同时地面AMF因为没收到UE的响应也判定UE超时发起了“隐式分离Implicit Detach”。后果两方都在删上下文导致信令冲突甚至造成UE状态机死锁UE以为连着网侧以为断了。解决方案引入“事务ID”与“去抖”机制相关信令与规程NAS信令的事务管理AMF在发送 NAS Notification 或 Configuration Update 时携带一个Transaction ID。如果AMF在等待响应期间收到了UE的主动请求如 Deregistration RequestAMF需比对Transaction ID。如果是针对同一操作的响应则合并处理而不是报错。星上gNB的“缓冲与去抖”星上gNB监测到UE发起 RRC Reestablishment 时不立即转发给地面。gNB启动一个短定时器例如50ms覆盖掉RTT的抖动。如果在定时器内地面AMF发来了 UE Context ReleasegNB直接回复“已完成”并执行重建避免向地面发送多余的信令减少信令风暴。 关键问题三计费与 lawful interception合法监听的合规性问题分析计费UPF在天上数据直接分流到互联网例如用户在看Netflix地面网关Gateway根本看不到流量。传统的基于网关的计费系统CG无法工作。合规运营商必须能够合法监听用户数据。如果数据在星上直接转发且不回传地面如何满足法律监管解决方案星上生成CDR与镜像分流相关信令与规程增强的N4 Usage Report星上UPF必须内置计费功能。它需要实时生成话单CDR或使用量报告。规程星上UPF通过N4接口利用空闲信令窗口向地面SMF/CHF计费功能发送 N4 Session Report。关键点即使数据不走地面计费日志必须优先回传地面。带外镜像Port Mirroring over ISL对于需要监管的特定用户地面SMF通过N4下发PDR包检测规则标记该用户。星上UPF复制该用户的流量包。复制的流量通过星间链路ISL路由回本国/本区域的地面信关站而不是直接发往互联网。信令这不需要UE参与完全由地面SMF通过N4接口远程配置星上UPF的转发行为FAR - 转发动作规则。 总结从“透明管道”到“智能边缘”在AMF在地面、UPF在星上的架构中最核心的技术转变在于信任关系的重构地面SMF不再实时控制每一个包而是从“指挥官”变成了“立法者”制定规则下发策略。星上UPF从“执行者”变成了“自治体”具备断连生存能力、本地缓存能力、计费能力。最关键的信令优化点在于N4接口的异步化下行SMF - UPF规则预配置含断连生存时间。上行UPF - SMF延迟发送的Usage Report积攒一批发一次减少信令交互次数。这种设计既保留了地面核心网对全局的控制权安全、计费、移动性锚点又释放了星上边缘的计算潜力低时延、本地分流。

更多文章