51学通信

深度解析 3GPP TR 23.700-27：6.0 & 6.1 动态时延解决方案 (Dynamic delay solution)

27分钟阅读

好的，遵照您的指令，我们正式开启3GPP TR 23.700-27第六章“解决方案”的深度解读之旅。在前面的章节中，我们已经完整地勘探了问题的版图——识别了三大关键议题（Key Issues）。现在，我们将深入到工程师们智慧的结晶中，逐一审视他们为这些挑战所设计的精妙蓝图。

本文将首先解读6.0节的解决方案地图，然后聚焦于第一个、也是最具基础性的解决方案——6.1 动态时延解决方案。

深度解析 3GPP TR 23.700-27：6.0 & 6.1 动态时延解决方案 (Dynamic delay solution)

本文技术原理深度参考了 3GPP TR 23.700-27 V18.0.0 (2022-12) Release 18 规范中，关于“Chapter 6 Solutions”的开篇章节，并重点剖析“6.1 Dynamic delay solution”的核心原理、信令流程与网元影响，旨在为读者揭示5G系统应对卫星回传动态性的首个核心战术。

引言：从提出问题到给出答案

我们跟随“极光探索队”的脚步，已经深刻体会了5G网络在仰望星空时所面临的重重考验：变幻莫测的“天路”质量（KI#1），海量数据无法“翻山越岭”的困境（KI#2），以及近在咫尺却远在天涯的本地通信效率黑洞（KI#3）。第五章“关键议题”为我们绘制了一幅详尽的“挑战地图”。

现在，我们翻开了规范中最为厚重和关键的一章——第六章“解决方案”（Solutions）。这里是理论与实践交汇的战场，是工程师们用逻辑和信令为挑战谱写答案的篇章。本章内容繁多，提出了多达十种不同的解决方案或思路，分别从不同角度、采用不同策略来攻克前述的三大难题。

在深入第一个具体方案之前，规范非常贴心地在6.0节为我们提供了一张“解决方案导航图”，让我们对整个第六章的结构一目了然。随后，6.1节将打响解决Key Issue 1的第一枪，提出一个基于“测量-响应”模型的动态时延解决方案。

让我们再次回到北极科考现场。团队正准备进行一项至关重要的同步科学实验：队员艾娃将操控一架高精度无人机掠过冰盖，同时，营地的地震检波器阵列将记录无人机产生的微弱震动，以绘制地下冰层结构。这个任务要求无人机控制链路的时延必须稳定在40ms以下，而数据采集链路则需要至少50Mbps的持续带宽。面对头顶上那颗不断移动的LEO卫星，5G网络能否智能地保障这次任务的成功？答案，就藏在我们将要解读的解决方案之中。

1. 解决方案导航图 (6.0 Mapping of Solutions to Key Issues)

本节内容虽短，却扮演着整个第六章“总纲”的角色。它通过一个清晰的表格，将后续提出的各个解决方案与它们所要解决的关键议题一一对应起来。

规范原文引用 (Chapter 6):

The following table provides a mapping of the solutions described in this specification to the key issues.

在深入分析之前，我们首先需要将规范中的核心表格1:1重绘出来。

表格内容解析：

规范原文中的 Table 6.0-1: Mapping of Solutions to Key Issues 清晰地展示了各个解决方案的“火力覆盖范围”。

| Solutions | Key Issues: 1 (QoS Control) | Key Issues: 2 (Edge Computing) | Key Issues: 3 (Local Switching) |

| :--- | :---: | :---: | :---: |

| 1 | X | | |

| 2 | X | | |

| 3 | X | | |

| 4 | | X | X |

| 5 | | X | |

| 6 | | X | X |

| 7 | | | X |

| 8 | X | | |

| 9 | X | | |

| 10 | | X | |

表格深度解读：

这张图表告诉了我们几个至关重要的信息：

  1. 多路径攻关同一难题： 我们可以看到，Key Issue #1（动态QoS控制）拥有最多的解决方案支持（Solution #1, #2, #3, #8, #9）。这充分说明了这个问题是本次研究的重中之重，且解决它的思路是多维度的。这意味着后续我们会看到多种不同的方法来测量链路、调整策略，它们可能各有侧重，比如有的侧重实时测量，有的侧重预测，有的侧重解决乱序。

  2. 综合方案应对复合挑战： Solution 4和Solution 6同时覆盖了Key Issue #2（边缘计算）和Key Issue #3（本地交换）。这强烈暗示了这两个问题在技术实现上是高度同源的，可以通过一套统一的架构来解决。星上UPF既可以作为边缘计算的锚点，也可以作为本地交换的核心，这两种能力可以被集成在同一个解决方案中。

  3. 各司其职，精准打击： 像Solution #5, #7, 10等则专注于解决某一个特定的子问题，例如EAS的发现、特定场景下的本地交换等。

这张地图为我们的学习之旅提供了清晰的指引。现在，我们正式踏上征途，深入探索第一个被标记为解决KI#1的方案——Solution #1: Dynamic delay solution。

2. 动态时延解决方案 (6.1 Dynamic delay solution)

这个解决方案是应对Key Issue 1的 foundational approach，它构建了一个基于动态测量和策略响应的闭环控制系统，是理解后续更复杂方案的基础。

2.1 方案描述 (6.1.1 Description)

本节描述了方案的核心思想，即如何从Rel-17的静态类别感知，进化到Rel-18的动态时延感知。

规范原文引用 (6.1.1 Description):

In Rel-17 reference architecture…, the AMF is configured with the awareness of satellite backhaul categories… The AMF informs the SMF of satellite backhaul category… Based on this knowledge, the PCF can set the QoS policies accordingly.

这段话回顾了我们之前讨论过的Rel-17基线：网络知道回传是“卫星”，并据此设置一个比较笼统的QoS策略。

规范原文引用 (6.1.1 Description):

A gNB may have multiple candidate satellite backhaul on N2 and N3 interfaces, e.g. GEO satellite backhaul, LEO satellite backhaul, LEO satellite backhaul with ISL… Awareness of QoS changes is needed to adapt this Rel-17 solution to the dynamic delay requirement in Rel-18. That awareness of variable delay can be obtained by re-using the capability for the SMF to request QoS monitoring from the UPF that is specified in clause 5.33.3.3 of TS 23.501.

深度解析与场景链接：

这两段话是本解决方案的灵魂。

  1. 问题升级: 它指出了一个更复杂的现实，即“极光探索队”的gNB可能并非只有一种回传选择。规范中的 Figure 6.1.1-1: Example scenario that gNB has multiple candidate satellite backhauls 形象地展示了这一点：一个gNB可能同时处于GEO、LEO、带ISL的LEO等多个卫星系统的覆盖之下，并且可以在它们之间切换。静态的“类别”标签已然失效。

  2. 核心武器: 为了获得对“可变时延（variable delay）”的感知能力，方案明确提出要“复用（re-using）”TS 23.501中早已定义好的一项能力——SMF向UPF请求QoS监测（QoS monitoring）。

这是一个非常聪明的工程决策，体现了“架构假设一”的原则：立足现有架构进行增强。我们不需要发明一个全新的监测协议，5G系统本身就内置了这件“武器”，只是在过去，它更多被用于监测地面网络中的特定路径。现在，我们要把它部署到“天路”的监测上。

规范原文引用 (6.1.1 Description):

In addition to the already specified use cases where the SMF informs the PCF of the satellite category, the SMF needs to be enhanced to measure the N3 using the echo procedure and to inform the PCF of not only satellite category but also the observed delay.

深度解析：

这句话为我们揭示了完整的技术链路和所需的核心增强点：

  • SMF的新角色: SMF不再只是一个信息的“二传手”（从AMF接收类别，转发给PCF），而是要成为一个主动的“勘探者”。

  • 测量方法: 明确了测量N3接口（gNB-UPF路径）的方法——回声程序（echo procedure）。这通常指的就是GTP-U协议中的Echo Request/Response消息。

  • 信息升级: SMF上报给PCF的信息，从单一的“卫星类别”这个静态标签，升级为了“卫星类别 + 观测到的时延（observed delay）”这个动态心跳数据。

至此，本解决方案的核心逻辑已经非常清晰：AMF告知SMF链路类别 → SMF根据类别（或PCF指令）决定启动监测 → SMF命令UPF使用echo机制测量N3时延 → UPF上报测量结果 → SMF将实测时延上报给PCF → PCF根据实时时延数据制定/调整PCC策略。

2.2 高层架构原则 (6.1.2 High level architecture principles)

本节通过一个核心的信令流程图，将上述逻辑具象化为一步步可执行的网元交互。规范中的 Figure 6.1.2-1: Dynamic delay monitoring and QoS adaptation 是本解决方案的“施工总图”，我们无法重绘，但将对其进行逐帧的深度解说。

场景启动: 队员艾娃开启了无人机控制终端，准备执行高精度飞越冰盖的任务。这会触发一次PDU会話建立流程。

流程详解:

  • Step 1: PDU session establishment (PDU会话建立)

    • 原文描述: UE发起PDU会话建立、修改或切换，导致连接到具有不同回传类别的NG-RAN。AMF根据配置确定卫星回传类别。

    • 场景演绎: 艾娃的终端发起连接请求。AMF通过gNB ID识别出这是一个通过LEO卫星回传的基站，于是它在内部标记：“这是一个LEO连接”。

  • Step 2 & 3: AMF informs SMF (AMF通知SMF)

    • 原文描述: AMF在Nsmf_PDUSession_CreateSMContext或UpdateSMContext消息中，将“卫星回传类别”包含进去，发送给SMF。SMF进行响应。

    • 场景演绎: AMF为艾娃选择了一个SMF来管理这次会话，并在创建会话上下文的请求中明确告知SMF：“注意，这个会话的回传是LEO类型”。

  • Step 4: SMF informs PCF, PCF makes initial decision (SMF通知PCF，PCF做出初始决策)

    • 原文描述: SMF在与PCF建立策略关联时，将“卫星回传类别”上报给PCF。基于这个类别，PCF可能会在PCC规则中指示SMF激活QoS监测。

    • 场景演绎: SMF向策略大脑PCF“报备”：“艾娃的无人机控制会话已上线，走的是LEO链路”。PCF查询策略库，发现“无人机控制”是最高优先级的URLLC业务，且签约了“动态QoS保障”服务。PCF立即做出决策，在返回给SMF的PCC规则里，附带了一条指令：“激活对此会话N3路径的QoS监测”。

  • Step 5: SMF requests N3 path monitoring (SMF请求N3路径监测)

    • 原文描述: SMF收到了AMF的指示（回传是卫星）和/或PCF的PCC规则（要求监测），于是启动GTP-U路径监测。

    • 场景演绎: SMF收到PCF的指令，立即向管理该会话数据平面的UPF（用户平面功能）发送一条N4接口的指令：“立即开始对目标gNB（通过其IP地址定位）的GTP-U路径进行回声探测（Echo Procedure）”。

  • Step 6: Path monitoring result (路径监测结果)

    • 原文描述: SMF收到GTP-U路径监测结果，其中包含了观测到的时延。

    • 场景演绎: UPF开始工作，它向gNB发送了一个GTP-U Echo Request包，gNB收到后立刻返回一个Echo Response包。UPF计算两者的时间差，得出往返时延（RTT）为32ms。UPF将这个结果通过N4接口上报给SMF。SMF收到了第一份“心跳报告”：“N3路径当前RTT=32ms”。

  • Step 7: SMF informs PCF of the observed delay (SMF将观测时延通知PCF)

    • 原文描述: SMF发起策略关联修改流程，将“卫星回传类别”和（可选的）“观测到的时延”上报给PCF。

    • 场景演绎: SMF立即将这份热乎的“心跳报告”封装在Npcf_SMPolicyControl_Update消息中，发送给PCF：“报告！艾娃的会话，LEO链路，实测时延32ms”。

  • Step 8: [Conditional] SMF informs CHF (有条件地，SMF通知CHF)

    • 原文描述: SMF可能将卫星回传类别和观测到的时延通知CHF（计费功能实体）。这些信息可用于计费、网络统计和客户投诉处理。

    • 场景演绎: 这相当于一个“副本抄送”。SMF可能会把“艾娃在使用LEO链路，时延32ms”这个信息，也发一份给计费系统。未来如果运营商推出了“黄金低时延”套餐，这个数据就是计费的依据。

  • Step 9: PCF policy control (PCF策略控制)

    • 原文描述: PCF根据观测到的N3时延调整QoS策略。PCF可能还需要将时延或类别上报给AF。

    • 场景演绎: PCF收到32ms的实时数据，与任务要求的40ms阈值进行比对。决策： 时延在可接受范围内。PCF向SMF下发确认策略：“继续执行当前QoS保障方案”。

      • 动态调整发生: 半小时后，卫星路径切换，UPF测得时延变为90ms并上报。PCF收到新数据后，立即启动动态调整：

        1. 它下发一条新的PCC规则给SMF：“紧急！时延已超限！”

        2. 同时，它通过NEF（网络能力开放功能）向无人机控制平台的AF发送一条通知：“警告：你所服务的UE（艾娃的终端）下行链路时延已恶化至90ms”。

        3. 无人机平台AF立即指示艾娃的App切换到更稳健的飞行模式。

        4. SMF根据PCF的新规则，可能会调整UPF的队列管理策略，确保无人机的控制包获得绝对最高转发优先级，尽力减小排队时延。

至此，一个完整的“感知-上报-决策-调整-协同”的动态QoS控制闭环，通过这个信令流程完美地实现了。

2.2 网元影响分析 (6.1.3 Impacts on services, entities and interfaces)

本节是对上述流程的总结，明确了为了实现该方案，哪些网络功能实体需要进行能力增强。

规范原文引用 (6.1.3 Impacts):

SMF:

  • Capability to trigger GTP-U path monitoring when satellite backhaul is used.
  • Capability to report the observed delay resulting from GTP-U path monitoring to CHF.

PCF:

  • If observed delay is reported from SMF, PCF needs to have the capability to receive observed delay and to take it into account for policy control decisions.

深度解析：

  • 对SMF的影响:

    1. 触发监测能力: SMF必须被增强，要能“看懂”来自AMF的卫星回传指示和来自PCF的监测指令，并据此向UPF发起GTP-U路径监测。这是SMF新增的核心主动能力。

    2. 上报计费能力: SMF需要能将监测结果上报给CHF，打通QoS与计费的关联。

  • 对PCF的影响:

    1. 接收和理解实时时延的能力: PCF不再只是处理静态信息，它的“策略引擎”必须升级，增加一个新的输入参数——“实时观测时延”。

    2. 基于实时时延进行决策的能力: 这是最关键的增强。PCF的决策逻辑需要从“if (签约等级=VIP)…” 这样的二维判断，升级到“if (签约等级=VIP) AND (实时时延 > 阈值) AND (业务类型=URLLC)…”这样的多维、动态决策矩阵。

这个解决方案，通过对SMF和PCF进行精准的“外科手术式”增强，巧妙地复用了5G系统已有的能力，构建了一套实用、高效的动态时延应对机制，为解决Key Issue 1提供了第一个坚实可靠的答案。

总结：迈出智能化QoS的第一步

Solution #1 “动态时延解决方案”，为我们展示了5G系统从“静态规划”走向“动态适应”的第一种战术。它没有引入新的网元或颠覆性的架构，而是通过增强SMF的主动监测触发能力和升级PCF的动态决策能力，并复用UPF已有的GTP-U Echo机制，构建了一个优雅的闭环控制系统。

  • 它解决了Key Issue 1中的“如何测量”问题——通过SMF触发UPF进行GTP-U Echo探测。

  • 它解决了“如何调整策略”问题——通过SMF将实测时延上报PCF，由PCF动态生成新策略。

对于“极光探索队”来说，这个方案就像是为他们的网络配备了一位尽职尽责的“随队医生”（SMF+UPF）和一位经验丰富的“远程专家”（PCF）。医生时刻监测着生命线（卫星链路）的脉搏（时延），并将数据实时传送给专家，专家则根据最新的体征数据，动态调整治疗方案（QoS策略），确保在多变的环境下，优先保住最重要的任务（无人机操控）不出意外。

虽然这个方案已经非常强大，但它也留下了进一步探索的空间，比如：如何处理带宽的动态性？如何将信息更有效地暴露给应用？如何解决乱序问题？这些，都将由后续的解决方案来逐一解答。

FAQ环节

Q1：这个方案中，时延是由谁最终测量出来的？gNB、UPF还是SMF？

A1：最终的测量动作是由UPF完成的。具体流程是：SMF作为“大脑”发出指令，UPF作为“手脚”去执行。UPF向gNB发送GTP-U Echo Request报文，gNB收到后回复Response报文，UPF根据发出和收到的时间戳计算出两者之间的往返时延（RTT）。所以，SMF是发起者和结果接收者，而UPF是实际的测量执行者。

Q2：GTP-U Echo探测本身会占用卫星带宽，这是否会影响正常业务？

A2：会占用，但影响通常很小。GTP-U Echo报文本身非常小，通常只有几十个字节。相比于动辄数Mbps甚至Gbps的业务流量，它的占比微乎其微。但是，探测的频率是一个需要权衡的参数。过于频繁的探测会累积成不可忽视的开销，过于稀疏的探测则可能无法及时捕捉到链路的变化。因此，在实际部署中，探测频率通常是可配置的，甚至可以设计成自适应的。

Q3：这个方案能否测量带宽？

A3：这个名为“动态时延解决方案”的方案，其核心机制（GTP-U Echo）主要用于测量时延和连通性，它本身不能直接测量出链路的可用带宽。虽然规范描述中提到了带宽，但具体的带宽测量机制并未在本方案中详细阐述。如架构假设所述，带宽的探测更可能依赖于底层传输网络上报。后续的其他解决方案（如Solution #2）可能会对如何利用带宽信息进行更深入的探讨。

Q4：AMF是如何知道gNB正在使用卫星回传的？

A4：通常是通过本地配置。在网络规划阶段，运营商就会在AMF的配置数据中，将特定的gNB ID（或一片区域的gNBs）与“卫星回传”这个属性进行绑定。当一个UE通过这个gNB接入时，AMF查询其配置库，看到这个gNB ID被打上了“卫星回传”的标签，它就知道了这一信息，并可以在后续的流程中通知SMF。

Q5：PCF是根据什么来决定是否要激活QoS监测的？

A5：PCF的决策是基于多种信息的综合判断，主要包括：

  1. 用户签约信息： 用户是否订购了需要高级别QoS保障的“黄金套餐”或动态保障服务。

  2. 业务类型： UE正在请求的业务是否是时延敏感型（如URLLC、实时游戏、VoNR）或带宽保证型业务。

  3. 网络上报信息： 最关键的就是从SMF处获取到的“卫星回传类别”。当PCF得知链路是 inherently 不稳定的LEO卫星回传时，它触发监测的可能性就远大于链路是稳定的GEO卫星回传或地面光纤。

关系图谱