好的，遵照您的指令，我们继续这场对3GPP TR 2

23.700-27解决方案的深度剖析之旅。在前序文章中，我们已经完整地探索了应对Key Issue #1（动态QoS控制）的各种战术。现在，我们将进入一个全新的领域，专注于解决一个更为棘手的问题——在动态变化的卫星链路下，如何为最苛刻的业务（如URLLC）提供精准、高效的QoS监控和保障。

本文将专门深度解读6.9节，这是一个高度集成的、堪称Key Issue #1“终极版”的解决方案——动态卫星回传时延控制的QoS监控。

深度解析 3GPP TR 23.700-27：6.9 终极哨兵：动态时延控制的QoS监控方案

本文技术原理深度参考了 3GPP TR 23.700-27 V18.0.0 (2022-12) Release 18 规范中，关于“6.9 Solution for Key Issue #1: QoS Monitoring for dynamic satellite backhaul delay control”的核心章节，旨在为读者深入剖析一套集双向监控、策略驱动、实时上报、闭环控制于一体的高级QoS保障框架，它代表了5G网络应对卫星回传动态性的最高智慧。

引言：从“尽力而为”到“精准达标”

在此前的解决方案中，我们已经赋予了5G网络诸多能力：它能被动适应（Sol #1），能主动择路（Sol #2），能预测未来（Sol #3），还能维持秩序（Sol #8）。然而，这些能力在面对一类“零容忍”的王者级业务时，可能依然不够精细。这类业务，就是URLLC（超可靠低时延通信）。

想象一下“极光探索队”正在执行一项前所未有的高难度任务：远程遥控一台手术机器人，为一只受伤的珍稀北极熊进行野外紧急缝合手术。这个场景对网络的要求是极致的：

• 时延必须稳定在20ms以内，任何一次超过50ms的抖动都可能导致手术刀的致命误差。

• 可靠性必须达到99.999%，任何一个控制指令的丢失都可能酿成悲剧。

对于这样的业务，仅仅知道链路“时延大约是30ms”是远远不够的。网络需要像一位心外科手术的麻醉师，对病人的生命体征进行持续、双向、高频的监控，并能在任何指标偏离预设阈值的瞬间，立刻做出反应。

Solution 9正是为了打造这样一位终极的“网络麻醉师”而生。它不再满足于笼统地、周期性地了解链路状况，而是要建立一套策略驱动的、精细化的QoS监控（QoS Monitoring）机制。这套机制不仅监测UPF到gNB的用户面，还首次将gNB侧的空口和处理状况也纳入了监控视野，实现了真正的端到端（核心网-UE）QoS保障闭环。

1. 方案描述 (6.9.1 Description) - 超越单向探测的立体化监控

本节描述了现有监控机制的不足，并提出了新方案的核心理念——引入RAN侧的QoS监控。

规范原文引用 (6.9.1 Description):

In Rel-17, the single satellite backhaul network is used and the AMF reports to the SMF the satellite backhaul category… In order to adapt Policy/QoS control for dynamic delay in satellite backhaul network used in UP, the QoS monitoring over GTP-U path between RAN and UPF is required.

这段话首先回顾了之前方案的基础：为了适应动态时延，我们需要在gNB和UPF之间的GTP-U路径上进行QoS监控。这主要解决的是核心网回传段的问题。

规范原文引用 (6.9.1 Description):

As example scenarios depicted above, the RAN may use one or more type of backhaul networks with the 5GC, and also the RAN may use different type of backhaul networks in CP and UP… For efficient and precise monitoring, the PCF needs to generate the appropriate QoS Monitoring Policy and needs to adjust the PCC rules based on the monitoring results in time.

深度解析与场景链接：

• 复杂场景的挑战: Figure 6.9.1-1: Example scenarios of satellite backhaul network with dynamic delay 描绘了极为复杂的混合回传场景。RAN（gNB）可能同时通过卫星和地面链路连接核心网，甚至控制面（CP）和用户面（UP）走的是完全不同的回传路径。在这种情况下，仅仅监控UPF到gNB的GTP-U路径，可能只看到了“大象的一条腿”。

• 问题的核心——RAN侧的“黑盒”: 从核心网（UPF）侧发起的Echo探测，虽然能测量N3接口的往返时延，但它无法区分时延的构成。例如，测得90ms的总时延，其中有多少是卫星传输的物理时延？有多少是由于gNB侧空口拥塞、处理能力不足导致的排队时延？UPF对此一无所知。对于URLLC业务而言，空口的每一毫秒都至关重要。

• 新方案的破局点: 为了实现“高效和精确的监控（efficient and precise monitoring）”，方案提出，必须让PCF能够生成明确的QoS监控策略（QoS Monitoring Policy），并根据监控结果实时调整PCC规则。这暗示着监控本身需要被策略所驱动，且监控的范围需要被扩大。

2. 核心流程 (6.9.2 Procedures) - 一场由策略驱动的双向侦察

本节是Solution 9的精华所在。规范通过 Figure 6.9.2-1: Procedure for enabling QoS monitoring for dynamic satellite backhaul delay control 这张堪称本技术报告中最复杂的信令流程图，为我们展示了一场由PCF大脑精确指挥，核心网与RAN协同执行的立体化QoS监控行动。

场景启动： 艾娃启动了远程手术机器人控制台，为其与北极熊旁的手术机器人之间建立一条URLLC PDU会话。

流程详解：

• Step 1-3: “动态监控请求”的诞生

  • 原文描述: UE建链。AMF判断gNB是否使用多类型回传或CP/UP分离回传。如果是，AMF在CreateSMContext请求中，向SMF提供一个新的指示：“动态卫星回传时延控制请求（dynamic satellite backhaul delay control request）”。SMF将此请求转发给PCF。

  • 场景演绎: AMF识别出这是一个需要极致QoS保障的场景，它不再仅仅是通知SMF“这里有卫星”，而是发出了一个明确的“一级戒备”信号：“SMF，这条链路极端复杂且动态，请为接下来的会话启动最高级别的动态时延控制程序！” SMF立即将这个“一级戒备”信号上报给总指挥PCF。

• Step 4: PCF的“侦察任务书”

  • 原文描述: PCF生成PCC规则，并带有一个策略控制请求触发器（PCRT）。这个触发器是：“当选择了具有动态卫星回传时延的UPF时（UPF with dynamic satellite backhaul delay is selected）”。

  • 场景演绎: PCF收到“一级戒备”信号，立即下发了一份加密的“侦察任务书”给SMF。任务书的核心指令是：“你先去选择一个UPF。一旦你选定了UPF，立刻触发这个触发器，向我汇报，并带上你对路径的初步探测结果。” 这体现了与Solution 2类似的“选前探测”思想。

• Step 5: UPF侧的初步侦察 (核心网回传段)

  • 原文描述: SMF启动对可用UPFs的GTP-U路径监测。基于测量到的回传时延和PCC规则，SMF选择一个UPF。

  • 场景演绎: SMF指挥所有候选UPF对gNB进行Echo探测，并选定了路径最优的UPF-A。这个过程与Solution 2类似。

• Step 6: 触发！PCF下发精细化监控策略

  • 原文描述: UPF选定后，SMF发现满足了Step 4中的PCRT条件。SMF向PCF发起Update请求，报告触发器被满足，并带上选定UPF测量到的回传时延。

  • 场景演绎: SMF向PCF报告：“总指挥，UPF-A已选定，初步侦察显示其回传时延为15ms。请下达下一步指示！”

• Step 7: 终极监控策略的下发

  • 原文描述: PCF评估收到的信息，并下发更新后的PCC规则。这次的规则里，包含了一个全新的、高度精细化的信息集：“动态卫星回传时延控制的QoS监控信息（QoS Monitoring information for dynamic satellite backhaul delay control）”。这其中可能包括了监控的报告频率、阈值等。

  • 场景演绎: PCF收到15ms的报告，认为满足手术要求。但为了防患于未然，它下发了终极监控策略：“任务确认！现要求对该会话进行最高级别监控。具体指令如下：

    1. 监控指标： 端到端时延。

    2. 报告阈值： 任何时候时延超过20ms，必须立即向我报告。

    3. 报告频率： 即使未超阈值，也需每秒报告一次平均时延。”

• Step 8-12: RAN侧监控的激活 (空口与gNB处理段)

  • 这是本方案与之前所有方案的根本区别！

  • 原文描述: SMF执行N4会话建立。然后，SMF通过AMF，使用N1N2MessageTransfer消息，将从PCF规则中派生出的QoS监控指示、报告频率、阈值等信息，封装在N2 SM information中，发送给RAN (gNB)。RAN根据这些信息为UE建立AN资源，并回复是否接受执行QoS监控。

  • 场景演绎:

    1. SMF不仅配置了UPF，还通过AMF给gNB下达了指令：“gNB请注意，你现在需要为艾娃的URLLC会话，启动你那一侧的QoS监控。监控要求与PCF下发的一致（阈值20ms，频率1秒）。”

    2. gNB收到指令后，在其内部启动了监控模块。它开始监测数据包从到达gNB到成功在空口发送给UE的全部时延，这包括了gNB内部的处理时延、排队时延和空口传输时延。

    3. gNB向核心网回复：“指令已收到，监控已启动。”

• Step 13-16: 双向监控数据的汇集与闭环控制

  • 原文描述: SMF可能会向UPF发起N4会话修改，下发监控策略。当SMF从UPF（上报N3时延）或RAN（通过UpdateSMContext上报RAN侧时延）收到超阈值的测量报告时，SMF会再次通知PCF，触发新一轮的策略调整。

  • 场景演绎:

    • 双哨兵同时站岗： 此刻，UPF在监控着核心网回传段的时延，而gNB则在监控着RAN段的时延。

    • 告警响起： 突然，gNB发现由于太阳耀斑导致空口信号瞬时衰落，RAN侧时延飙升到了30ms，超过了20ms的阈值。

    • gNB立即上报： gNB立刻通过PDUSessionUpdateSMContext消息向SMF发出告警：“报告！我这里（RAN侧）出现拥塞，时延30ms！”

    • SMF上报PCF，形成闭环： SMF收到告警，立即上报PCF。PCF分析后，可能会采取更激进的措施，比如指示SMF尝试将会话切换到另一条备份的回传路径上，或者通过AF通知手术平台暂停操作，等待网络恢复。

3. 网元影响分析 (6.9.3 Impacts on services, entities and interfaces) - 全面协同的网络智能

这个方案对网络核心部件的能力要求，达到了前所未有的高度。

• 对AMF的影响: 需要能识别出最复杂的动态回传场景，并发起全新的“动态时延控制请求”。

• 对SMF的影响: 成为监控数据的汇集中心。它需要能将PCF的监控策略，分别“翻译”成给UPF的N4指令和给RAN的N2指令。它还需要能接收并区分来自UPF和RAN两路的监控报告，并将它们汇总上报给PCF。

• 对PCF的影响: 成为监控策略的制定者。它需要能生成包含频率、阈值等精细化参数的QoS监控策略，并能处理来自SMF的实时超阈值告警。

• 对RAN (gNB)的影响 (最关键的新增能力): gNB不再只是一个被动的执行者和被探测者。它必须具备主动执行QoS监控的能力，能够测量数据包在RAN内部的“旅行时间”，并能在超阈值时主动向核心网发起上报。

总结：为URLLC打造的“绝对领域”

Solution #9 “动态卫星回传时延控制的QoS监控”，是3GPP为应对Key Issue 1给出的最全面、最精细、也是最强大的答案。它不再满足于单一维度的探测或笼统的策略，而是构建了一个立体的、闭环的、策略驱动的监控与保障体系。

• 监控维度的立体化： 它将监控的触角从核心网的N3接口，首次延伸到了RAN内部和空口，从而获得了对端到端时延构成的完整画像。

• 控制逻辑的闭环化： 它构建了PCF策略 -> SMF分发 -> UPF/RAN执行监控 -> 实时/阈值上报 -> PCF再决策的完美闭环，使得网络的响应速度和精度达到了新的高度。

• 网络协同的深度化： 它要求核心网（SMF/PCF）与接入网（RAN）之间进行前所未有的深度信息交互，真正实现了5G端到端业务保障的承诺。

对于“极光探索队”那场性命攸关的远程手术，只有Solution 9这样“武装到牙齿”的终极哨兵，才能提供真正值得信赖的网络保障。它为URLLC这类“不容有失”的业务，在变幻莫测的卫星回传环境下，撑开了一片宝贵的、可信赖的“绝对领域”。

---

FAQ环节

Q1：这个方案和Solution 2最大的区别是什么？

A1：最大的区别在于监控的范围和驱动方式。Solution 2的监控范围基本局限在核心网侧（UPF发起的N3路径探测），是被动的、由核心网单向发起的。而Solution 9将监控范围扩展到了RAN侧，实现了对核心网回传段和RAN段的双向、立体化监控。此外，Solution 9的监控行为是由PCF的精细化策略（含频率、阈值）严格驱动的，其目的性、实时性和精度都远超前两个方案。

Q2：RAN（gNB）是如何测量RAN侧时延的？

A2：这通常涉及到gNB内部的实现。一种可能的方式是：gNB在N3接口收到一个下行数据包时，会打上一个内部的时间戳（T1）。当这个包经过gNB内部的协议栈处理、排队等待，并最终成功在物理层（空口）发送给UE后，gNB记录下此刻的时间戳（T2）。T2与T1之差，就是这个包在RAN侧的“驻留时延”。gNB会对一个QoS Flow内的所有包进行这样的测量，并计算出平均值、抖动等统计数据，用于与PCF下发的阈值进行比较。

Q3：为什么需要将监控请求通过AMF中转给gNB，而不是SMF直接通知gNB？

A3：这是由5G核心网的架构分工决定的。在5G架构中，AMF是核心网与RAN之间唯一的信令交互“总关口”，所有非透传的N2接口信令都必须经过AMF。SMF负责会话管理，它本身与gNB没有直接的信令接口。因此，SMF要向gNB传递任何与会话相关的控制信息（即N2 SM Information），都必须“委托”AMF通过N1N2MessageTransfer服务代为转交。这保证了架构的清晰和信令路由的统一。

Q4：这个方案引入的“dynamic satellite backhaul delay control request”新指示，和Solution 2的“dynamic satellite backhaul in use”指示有何不同？

A4：可以理解为告警等级的不同。“dynamic satellite backahoal in use”（Sol #2）是一个通知级的指示，它告诉SMF/PCF：“这里有多条路径，请启动‘主动选择’模式”。而“dynamic satellite backhaul delay control request”（Sol #9）则是一个请求/命令级的指示，它告诉SMF/PCF：“这里不仅有多条路径，而且业务要求极高，请启动‘最高级别的精细化监控’模式”。后者通常意味着业务对QoS的要求更为苛刻，需要网络投入更多的监控和控制资源。

Q5：实现了Solution 9之后，是否还需要Solution #1、#2、#8？

A5：需要，它们是互补的。Solution 9是为最高等级的URLLC等业务设计的“豪华套餐”，资源消耗最大。在实际网络运营中，会根据业务需求进行分级服务：

• 普通上网业务： 可能只需要Solution 1的被动适应。

• 高质量视频业务： 可能在建链时使用Solution 2进行择优，后续用Solution 1进行维持。

• TCP大文件传输： 在上述基础上，叠加Solution 8的有序交付。

• 远程手术、工业控制等URLLC业务： 才会启用Solution 9这套终极的、全方位的监控保障体系。

这种分级服务，体现了5G网络切片和精细化运营的核心思想。