好的,遵照您的指令,我们继续对3GPP TR 23.700-27第六章的解决方案进行深度拆解。在上一篇文章中,我们剖析了Solution #1,它为5G系统配备了“事后适应”的能力。现在,我们将进入一个更强大、更智能的方案——Solution #2,它将带领5G网络从被动的适应者,进化为主动的决策者。
深度解析 3GPP TR 23.700-27:6.2 QoS control enhancements for dynamic satellite backhauling (动态卫星回传的QoS控制增强)
本文技术原理深度参考了 3GPP TR 23.700-27 V18.0.0 (2022-12) Release 18 规范中,关于“6.2 Solution for KI#1: QoS control enhancements for dynamic satellite backhauling”的核心章节,旨在为读者深入剖析一个更为主动和智能的QoS控制框架,它赋予了5G网络在多路径卫星回传环境中进行动态路径选择的革命性能力。
引言:从被动适应到主动选择的进化
在Solution 1中,我们看到5G网络学会了如何监测一条既定的卫星链路,并在其性能劣化时动态调整策略,这好比为“极光探索队”配备了一位能够根据病人生命体征变化来调整用药的“随队医生”。这已经是一个巨大的进步,但它仍然有一个前提:病人(卫星链路)是唯一的,无论好坏,都只能在他身上治疗。
然而,现实的星辰大海远比这复杂。随着低轨(LEO)、中轨(MEO)、高轨(GEO)卫星星座的交织覆盖,“极光探索队”的gNB可能同时被多颗不同系统的卫星“照耀”。这就好比,他们面前不仅有一条通往后方总部的“天路”,而是同时出现了多条:
-
路径A (LEO星座): 带宽极高,时延极低,但稳定性稍差,几分钟就可能切换一次。
-
路径B (MEO星座): 带宽和时延中等,链路相对稳定,数小时才切换一次。
-
路径C (GEO卫星): 带宽有限,时延巨高,但链路如磐石般稳定。
此时,如果只是被动地适应某一条随机选定的路径,显然不是最优解。一个更高级、更智能的问题摆在了5G网络面前:我能否在建立连接之初,就主动地探测所有可选路径,并为当前的任务选择出最优的那一条?
Solution 2正是为了回答这个问题而生。它不再满足于当一个被动的“医生”,而是要成为一个主动的“医疗顾问”,不仅能治疗,更能为病人选择最合适的医院和最佳的治疗方案。让我们看看,这个方案是如何赋予5G网络这种前所未有的“择路权”的。
1. 方案描述 (6.2.1 Description) - 问题的升级与新武器的引入
本节开宗明义地指出了Rel-17静态模型的局限性,并引入了解决问题的全新思路。
规范原文引用 (6.2.1 Description):
In Rel-17, only a single satellite backhaul category refers to the type of the satellite (i.e. GEO, MEO, LEO or OTHERSAT) can be indicated.
In Rel-18, the multi-hops ISL or multi-types of backhaul will be considered… In such case, only a single satellite backhaul category is not enough to describe the dynamic satellite backhaul characteristics.
这段话重申了我们在解读Solution 1时已经明确的痛点:面对复杂的、由多类型卫星和多跳ISL组成的混合回传环境,一个静态的“类别”标签已经捉襟见肘。规范中的Figure 6.2.1-1: gNB has multiple satellite backhaul UP connections形象地描绘了这种窘境。
规范原文引用 (6.2.1 Description):
Moreover, due to dynamic satellite network topology and distinguished transmission capabilities provided by different type of satellites, statically configured QoS parameters for the PDU session may not always be suitable. Therefore, the QoS control for the case of satellite backhaul needs to be enhanced.
In addition, since the backhaul information (e.g. backhaul delay, backhaul category) can be changed/ adjusted dynamically, the AF may request the backhaul information for application layer optimization or adjustment.
深度解析与场景链接:
这两段话为我们揭示了Solution 2的核心驱动力:
-
静态QoS配置的失效: “ statically configured QoS parameters may not always be suitable”。这意味着,仅仅在会话建立时基于一个笼统的“LEO”标签来配置QoS参数,很可能会在实际链路选择后出现巨大的偏差,导致资源浪费或体验不佳。
-
AF的主动诉求: “the AF may request the backhaul information”。这暗示了应用层对网络透明度的更高要求。一个智能的应用(比如无人机控制平台AF),可能希望在发起关键任务前,主动向网络查询:“请告诉我,你为我的无人机准备的那条路,实时路况(时延、带宽)如何?”
为了满足这些新的、更高级的需求,Solution 2的设计必须超越Solution 1的“事后监测”模型。它需要在连接建立的流程中,引入全新的机制,来实现“事前探测”和“择优选择”。
2. 核心流程 (6.2.2 Procedures) - 一场精心策划的“探路行动”
本节是Solution 2的精华所在。规范通过Figure 6.2.2-1: PDU session establishment when gNB has multiple satellite backhaul UP connections这张详尽的信令流程图,为我们展示了一场由5G核心网精心策划的“多路同步探测与最优路径选择”行动。
场景启动: “极光探索队”的首席科学家艾娃,准备启动一台全新的“量子加密通信仪”,与总部进行一次绝密的数据传输。这项业务对时延和带宽都有着极为苛刻的要求。
流程详解:
-
Step 1-2: AMF的“升级版”情报 (AMF selects SMF/I-SMF)
-
原文描述: UE发起PDU会话建立。AMF选择SMF。如果AMF意识到gNB可以使用多种类型的回传网络,它可以调用
Nsmf_PDUSession_CreateSMContext请求,通知SMF关于“动态卫星回传正在使用”的信息。 -
场景演绎: 艾娃的通信仪开机建链。AMF通过gNB ID识别出,这个gNB正同时被LEO和MEO两个星座覆盖。此时,AMF向SMF发送的不再是简单的“类别=LEO”,而是一个更重要的新情报:“警报!目标gNB具备动态回传能力,存在多条路径可选!”
-
-
Step 3: SMF to PCF - 传递新情报 (SMF informs PCF)
-
原文描述: SMF通过在
Npcf_SMPolicyControl_Create请求中包含“dynamic satellite backhaul in use”指示,将此信息通知PCF。 -
场景演绎: SMF立即向策略大脑PCF汇报:“艾娃的绝密通信任务上线,其gNB存在多路径动态回传,请指示!”
-
-
Step 4: PCF的“B计划” (PCF generates PCC rules)
-
原文描述: PCF基于该指示,生成适合卫星回传的PCC规则,该规则会指示激活QoS监测。此外,如果允许降级的QoS,PCF还可能提供备选QoS配置文件 (Alternative QoS Profile)。
-
场景演绎: PCF收到情报后,立即制定了一套精密的作战计划:
-
A计划 (主计划): 针对“量子加密通信”业务的理想QoS要求(如时延<50ms, 带宽>100Mbps)生成了PCC规则。
-
B计划 (备选方案): PCF考虑到所有路径都可能无法满足A计划,它还准备了一个“Alternative QoS Profile”:“如果最优路径也无法满足A计划,则启动B计划,允许时延放宽到80ms,带宽降至60Mbps,并立即通知应用层”。
PCF将这套带有“B计划”的完整作战方案下发给SMF。
-
-
-
Step 5-9: SMF的“多路同步侦察” (SMF selects candidate UPFs and triggers monitoring)
-
这是整个方案的革命性所在!
-
原文描述: SMF选择候选UPF(s)。基于收到的PCC规则,SMF通过N4接口请求至少一个候选UPF激活对gNB的GTP-U路径的QoS监测。如果候选UPF尚未激活监测,它会向gNB发送Echo Request,gNB响应,UPF将监测结果上报给SMF。
-
场景演绎: SMF现在扮演了“侦察行动总指挥”的角色。它知道,要想到达艾娃的gNB,可以通过两个不同的地面关口站,每个关口站后面都部署了UPF。
-
关口站1 (日本)→UPF-1→LEO星座→gNB -
关口站2 (加拿大)→UPF-2→MEO星座→gNB
-
-
SMF同时向UPF-1和UPF-2下达指令:“立即对目标gNB进行路径探测,并上报时延!”
-
同步行动开始:
-
UPF-1通过LEO链路向gNB发送了一个Echo包。
-
UPF-2通过MEO链路也向gNB发送了一个Echo包。
-
gNB几乎同时收到了两个Echo包,并分别进行了回复。
-
-
情报汇总:
-
UPF-1上报:“报告!路径A(LEO)实测RTT=45ms”。
-
UPF-2上报:“报告!路径B(MEO)实测RTT=120ms”。
-
-
-
Step 10: SMF的“最优决策” (SMF selects the suitable I-UPF and/or PSA UPF)
-
原文描述: SMF收到来自UPF(s)的QoS监测结果后,选择合适的I-UPF和/或PSA UPF,例如,选择具有最低回传时延的UPF。基于收到的结果,SMF可能决定应用降级的QoS(备选方案),或发起策略修改流程。SMF还可能将带宽信息上报给PCF。
-
场景演绎: SMF拿到了两份实时战报。它立即进行决策分析:
-
路径A (45ms) 完美满足了A计划中“时延<50ms”的要求。
-
路径B (120ms) 不满足A计划,但满足B计划。
-
-
最终决策: SMF做出选择:“本次会话选用UPF-1作为PDU会ッション锚点!” 它锁定了这条最优路径。同时,它可能会向PCF汇报:“已为艾娃的业务选择了45ms的优质链路,带宽情况后续监测”。
-
-
Step 11-15: AF的“主动问询” (AF requests to obtain backhaul information)
-
原文描述: AF可以通过NEF,使用
Nnef_AFsessionWithQoS_Create消息,主动请求获取卫星回传信息(如时延、带宽)。NEF授权请求后,与PCF交互,PCF通过上报QoS监测信息来暴露回传详情,最终由NEF传递给AF。 -
场景演绎: 在艾娃启动任务前,她的量子通信仪App的后台(AF)就先向网络发起了一次主动问询:“我即将执行一次关键任务,请告诉我你为我准备的路径的实时QoS是多少?”
-
PCF收到了这个请求,并将SMF刚刚选定的那条路径的实时信息(45ms时延,以及后续监测到的带宽)通过NEF返回给了AF。
-
AF收到信息后,向App显示:“网络已就绪:优质LEO链路,时延45ms,带宽150Mbps,满足任务要求”。艾娃信心满满地按下了“开始传输”按钮。
-
3. 网元影响分析 (6.2.3 Impacts on services, entities and interfaces) - 网络DNA的全面升级
这个强大的方案,要求5G网络的核心网元们都进化出新的能力。
规范原文引用 (6.2.3 Impacts):
AMF:
- Capability to determine dynamical satellite backhaul in use;
- Capability to send the satellite backhaul indication to the SMF.
SMF:
- Capability to trigger GTP-U path monitoring when satellite backhaul is used.
- Capability to report the QoS monitoring results from GTP-U path monitoring to PCF.
- Configured with GTP-U IP addresses per gNB ID
PCF:
- Capability to receive satellite backhaul UP information and to take it into account for policy control decisions.
- Capability to expose dynamical satellite backhaul information to the NEF.
AF & NEF:
- AF: Capability to request dynamical satellite backhaul information
- NEF: Capability to expose dynamical satellite backhaul information
深度解析:
-
对AMF的影响: AMF需要从简单的“识别类别”,升级为能够判断gNB是否具备“动态/多路径”回传能力,并能将这个新的、更关键的指示传递给SMF。
-
对SMF的影响: SMF是变化最大的核心。
-
最重要的变化: 它需要具备在选择最终UPF之前,对多个候选UPF发起路径监测的能力。
-
它需要基于监测结果,执行UPF选择逻辑(如选择时延最低者)。
-
它需要被配置有gNB与候选UPF之间的GTP-U路径信息,以便发起探测。
-
-
对PCF的影响: PCF需要能理解来自SMF的“动态回传可用”指示,并据此生成更复杂的策略,包括提供备选QoS方案。它还要能响应AF的请求,将动态信息通过NEF暴露出去。
-
对AF和NEF的影响: AF从被动接收者,变成了可以主动请求网络QoS信息的参与者,NEF则需要支持这种新的查询和暴露服务。
总结:智能择路,QoS控制的范式转移
Solution #2 “动态卫星回传的QoS控制增强”,相比Solution #1,实现了一次意义深远的范式转移——从“单路径的被动适应”跃迁至“多路径的主动选择”。
它不再满足于在一条未知的道路上随机应变,而是像一位专业的拉力赛领航员,在比赛开始前就派出了多架无人机去勘测所有赛段,然后为赛车规划出那条能夺冠的最佳路线。
-
它引入了“动态回传可用”这一关键指示,从流程的源头(AMF)就启动了全新的智能模式。
-
它赋予了SMF前所未有的**“选前探测”和“择优决策”**的能力,这是保障高性能业务的核心。
-
它提出了“备选QoS方案”的理念,为网络策略增加了韧性和灵活性。
-
它将AF的角色提升为主动的“咨询者”,深化了网络与应用的协同。
对于我们的“极光探索队”来说,这意味着他们的网络不再是听天由命。当艾娃需要执行最严苛的任务时,5G系统不再是随便给她连上一条链路然后尽力保障,而是为她发起了一场小规模的“网络奥运会”,让所有可选的链路同场竞技,最后将“金牌路径”授予她使用。这,就是智能化网络的核心价值所在。
FAQ环节
Q1:Solution 1和Solution 2最根本的区别是什么?
A1:最根本的区别在于QoS监测发生的阶段和目的。在Solution 1中,QoS监测发生在UPF已经选定之后,其目的是适应一条既定路径的动态变化。而在Solution 2中,QoS监测发生在UPF选定之前,其目的是评估多条候选路径,并选择出最优的一条来承载业务。前者是“适应性调整”,后者是“选择性建链”,后者更为主动和智能。
Q2:这个方案中新引入的“dynamic satellite backhaul in use”指示,具体是什么?
A2:它是一个新的信息元素(Information Element),可以理解为一个“标志位”或“枚举值”。当AMF发现一个gNB可能连接到多种卫星回传网络时,它就会在给SMF的信令中将这个标志位设为“True”。这个标志就像一个“警报”,通知SMF和PCF:“注意!情况复杂,请启动高级QoS处理模式(即本方案的流程)”,而不是沿用简单的、基于单一类别的处理模式。
Q3:为什么PCF需要提供一个“Alternative QoS Profile”(备选QoS方案)?
A3:这是为了增加网络的韧性(Resilience) 和策略的灵活性。在某些情况下,即使是所有候选路径中最优的那一条,也可能无法满足业务最理想的QoS要求(例如,所有卫星链路都因为空间天气而性能下降)。如果没有备选方案,SMF可能会因为无法满足严格的QoS要求而拒绝会话建立。有了备选方案,PCF就等于告诉SMF:“如果最好的情况也达不到A计划,那么就执行B计划(比如,速率减半,但依然保持连接),并通知应用层”。这确保了业务的连续性,避免了一刀切的失败。
Q4:这个方案听起来很完美,它是否完全解决了Key Issue 1的所有问题?
A4:它主要解决了KI#1中的“测量”和“策略控制”两个核心课题,并且是以一种非常主动和智能的方式。它也部分涉及了“信息暴露给AF”。但是,对于KI#1中提出的第四个子问题——包乱序(packet out-of-sequence),本方案并未直接提供解决方案。路径的动态选择和切换,反而可能会加剧乱序问题。因此,我们还需要后续的解决方案(如Solution #8)来专门应对这个问题。
Q5:SMF向多个候选UPF发起监测,这在实际网络中是如何实现的?
A5:这要求SMF具备“候选UPF集(Candidate UPF Set)”的管理能力。当一个PDU会话请求到达时,SMF会根据DNN(数据网络名称)、UE位置等信息,从UPF池中筛选出一组可能为该会话服务的候选UPF。在传统网络中,它可能会根据静态的负载均衡策略直接选择一个。而在这个新方案中,SMF会向这个“候选集”中的多个(或全部)UPF下发N4指令,要求它们对同一个目标gNB进行路径探测。这要求N4接口和UPF本身都要支持这种“探测任务”的下发和执行。