51学通信

深度解析 3GPP TR 23.700-27：5.1 Key Issue #1 PCCQoS control enhancement considering dynamic satellite bac...

29分钟阅读

好的，遵照您的指令，我们继续踏上3GPP TR 23.700-27的深度拆解之旅。在上一章中，我们为整个研究工作奠定了坚实的“架构地基”。现在，我们将正式开始攻克这座技术高峰的第一道，也是最险峻的一道关隘——第五章，关键议题（Key Issues）。

本文将聚焦于5.1节，即Key Issue #1，这也是整份报告中最为核心、内容最为丰富的挑战。

深度解析 3GPP TR 23.700-27：5.1 Key Issue #1: PCC/QoS control enhancement considering dynamic satellite backhaul (动态卫星回传下的策略与QoS控制增强)

本文技术原理深度参考了 3GPP TR 23.700-27 V18.0.0 (2022-12) Release 18 规范中，关于“5.1 Key Issue #1: PCC/QoS control enhancement considering dynamic satellite backhaul”的核心章节，旨在为读者深入剖析5G系统在面对卫星回传链路的剧烈动态性时，其策略与服务质量（QoS）控制体系所面临的根本性挑战。

引言：当沉稳的5G遇上善变的“天路”

在上一章的解读中，我们明确了5G与卫星回传融合研究的三大基本法则：沿用标准5G架构、聚焦用户面挑战、明确划分与传输层的责任。这为我们探索未知领域提供了坚实的出发点。现在，我们将直面第一个，也是最根本的一个“已知未知”——Key Issue #1。

这个关键议题的核心，源于一场深刻的“性格冲突”。一方面，是为稳定、可预测的地面光纤网络而生的5G QoS控制框架，它如同一个沉稳、严谨的指挥家，习惯于在谱曲（签约信息）完成后，按部就班地指挥整个乐队（网络资源）进行演奏。另一方面，是卫星回传，特别是低轨（LEO）卫星回传这条变幻莫测的“天路”，它如同一个即兴的爵士乐手，节奏（时延）和音量（带宽）随时都在自由变化。

当沉稳的指挥家遇上即兴的乐手，一场混乱几乎在所难免。Key Issue 1的全部意义，就是要研究如何对这位指挥家进行“特训”，让他学会聆听、适应、甚至预判乐手的即兴发挥，从而将潜在的混乱，重塑为一曲动态和谐的交响乐。

我们的“极光探索队”此刻正深有体会。他们发现网络时好时坏，远程操控无人机时心惊胆战，上传宝贵数据时望眼欲穿。他们所经历的每一个痛点，都精准地刻画了Key Issue 1所要解决的难题。让我们跟随规范的原文，一步步解构这个核心挑战。

1. 问题的根源：从“静态标签”到“动态心跳”的鸿沟

规范在5.1.1章节的描述中，开宗明义地指出了问题的根源所在。

规范原文引用 (5.1.1 Description):

Satellite based backhaul is important for remote area or mission critical scenarios, in case it is not possible to build terrestrial backhaul connections.

In Release 17, a satellite backhaul category indication was defined to indicate the satellite backhaul information in. However, this indication may not enough if the satellite backhaul involves multi-hops of ISL or backhaul connections are over different satellites and terrestrial networks.

深度解析与场景再现：

这段话首先重申了卫星回传的价值——它是地面网络无法触及之地的唯一希望，是“极光探索队”这类任务的生命线。接着，它引入了一个关键的历史背景：Release 17。

在Rel-17中，3GPP已经向前迈出了一步，引入了“卫星回传类别指示（satellite backhaul category indication）”。这好比是给回传链路贴上了一个静态的标签。当“极光探索队”的gNB接入网络时，AMF可以通知SMF：“嘿，注意了，这个gNB用的是‘LEO卫星回传’”。

这在当时是一个巨大的进步，因为它至少让核心网知道自己面对的不是光纤，可以提前调整一些基础策略（比如放宽时延容忍度）。然而，Rel-18的研究者们很快发现，这个静态标签远远不够。为什么？

规范给出了两个核心原因：

  1. 多跳星间链路 (multi-hops of ISL): LEO卫星网络并非简单的“一上一下”模型。为了实现全球无缝覆盖和路由优化，数据包可能在太空中经历多次“接力”。

    • 场景演绎: 队长艾娃正在与总部视频通话。初始阶段，数据路径是：gNB -> 卫星A -> 地面站，时延25ms。几分钟后，由于卫星A即将飞出服务范围，卫星网络的“天基路由器”为了保持连接，动态地将路径切换为：gNB -> 卫星A -> 卫星B -> 地面站。路径中增加了一跳ISL（星间链路），时延立刻跃升至50ms。艾娃的视频画面瞬间卡顿。那个“LEO卫星回传”的静态标签，完全无法反映这25ms的剧烈变化。

  2. 跨越不同卫星和地面网络的连接: 回传路径可能是一个复杂的混合体，进一步加剧了动态性。

规范原文引用 (5.1.1 Description):

In such case, the capabilities provided by the satellite backhaul can be changed/adjusted dynamically. For example, if inter-satellite links are used on the backhaul path, the delay and bandwidth of the backhaul may be impacted due to the traffic engineering on the links. Satellite backhaul category is not enough to describe such a dynamic satellite backhaul characteristics.

深度解析与场景再现：

这句话道出了问题的本质：“能力”（capabilities）是“动态变化（dynamically changed/adjusted）”的。规范还指出了一个深层原因——空间流量工程（traffic engineering on the links）。

卫星星座的运营方，为了最大化整个系统的容量和效率，会像地面骨干网的网管一样，在太空中持续不断地进行流量调度。他们可能会为了避开一颗即将进入阴影区（太阳能不足）的卫星、绕过一个拥塞的星间链路、或者选择一个更靠近最终用户的地面站，而动态地重塑数据传输的路径。

  • 场景演绎: “极光探索队”正在进行一天中最重要的无人机数据批量上传。卫星网络的后台系统侦测到，他们当前使用的卫星B -> 日本地面站这条下行链路，因为要同时服务一架跨太平洋的航班，网络已经开始拥塞。系统自动做出“流量工程”决策，将探索队的下行链路切换到了卫星B -> 卫星C -> 加拿大地面站。

    • 结果： 这次切换可能带了好消息，也可能带来坏消息。也许新路径的总带宽更大，上传速度得以提升。也许新路径绕了远路，时延增加，带宽反而下降。但无论如何，这个变化是突发的、剧烈的、且对上层5G网络完全不透明的。

结论: 仅仅一个“我是LEO”的静态标签，就像是只告诉医生“我病了”，却不提供心率、血压、体温这些动态的生命体征。医生无法对症下药。因此，Key Issue 1的核心诉求浮出水面：5G系统必须从只认识“静态标签”，升级到能够感知并响应回传链路的“动态心跳”——即实时变化的时延和带宽。

2. 庖丁解牛：KI#1分解出的四大核心研究课题

为了系统性地解决上述挑战，规范将Key Issue 1拆解为四个具体、可操作的研究课题。这四个课题构成了一个完整的“发现问题 → 分析问题 → 解决问题 → 协同优化”的闭环逻辑。

2.1 课题一：感知的基石 —— 如何测量链路的“心跳”？

这是所有增强功能的前提。如果不能准确地测量，一切后续的控制和优化都无从谈起。

规范原文引用 (5.1.1 Description):

To better serve UEs connecting to 5GC via a gNB with satellite backhaul, the following topics are to be studied:

  • Determination of packet delivery latency or bandwidth or both of the satellite backhaul on the UP path.

深度解析：

  • “Determination”（确定/测定）: 这个词强调了获取信息的主动性和精确性。网络不能再“猜”或者依赖静态配置，而是需要有明确的机制去测定链路的真实状态。

  • “packet delivery latency or bandwidth or both”（包传递时延和/或带宽）: 再次强调了两个最核心的QoS指标。时延，衡量的是数据从gNB到核心网UPF单向或往返所需的时间；带宽，衡量的是这条路径单位时间内能够承载的最大数据量。

  • “on the UP path”（在用户平面路径上）: 重申了测量的对象必须是承载用户实际数据的N3接口，因为这直接决定了用户的体验。

面临的挑战与思考：

这个课题引出了一系列深刻的工程问题，虽然规范在这里只提出问题，但已经为后续的解决方案埋下了伏笔。

  1. 谁来测量？ 是gNB？是UPF？还是由SMF发起，协调两者共同完成？

  2. 怎么测量？

    • 时延测量: 是否可以采用类似ping的主动探测机制？比如，UPF定期向gNB发送一个带有时间戳的GTP-U Echo包，gNB收到后立刻回送，UPF根据时间差计算出往返时延（RTT）。这种方法的优点是直接、准确，缺点是会产生额外的网络开销。

    • 带宽测量: 带宽测量要复杂得多。主动探测（发送大量测试包）会严重占用本已宝贵的带宽资源，并不可取。那么是否可以采用被动观测的方法？比如，UPF监控实际业务流量的吞吐量和排队情况来估算可用带宽？或者，如第四章的架构假设所述，依赖底层传输网络（卫星终端）直接上报？

  3. 何时测量？ 应该周期性测量，还是在检测到某些事件（如丢包率上升）后触发式测量？测量的频率如何自适应调整？链路稳定时降低频率，剧变时提高频率。

对于“极光探索队”来说，这个课题的解决，意味着他们的网络系统里有了一个“随身医生”，时刻在为他们唯一的通信生命线做“心电图”和“血氧饱和度”监测。

2.2 课题二：控制的核心 —— 如何动态调整QoS策略？

拿到了链路的实时“体征数据”后，下一步就是“对症下药”。

规范原文引用 (5.1.1 Description):

  • Policy/QoS control enhancements based on the determined packet delivery latency or bandwidth or both of the satellite backhaul on the UP path.

深度解析：

  • “Policy/QoS control enhancements”（策略/QoS控制增强）: 再次点题，核心工作落在PCC（策略与计费控制）框架和QoS控制流程上。

  • “based on the determined…”（基于测定出的…）: 这句话清晰地建立了**“感知”与“控制”**之间的因果关系，形成了一个动态反馈闭环。

面临的挑战与思考：

这个课题要求我们对现有的5G PCC/QoS框架进行一次深刻的“智能化升级”。

  1. 信息如何流动？ UPF测量（或接收）到时延/带宽数据后，如何将这个信息高效、实时地传递给决策大脑PCF？是UPF -> SMF -> PCF这条标准的上报路径，还是有更快捷的方式？

  2. PCF如何决策？ PCF的“策略引擎”需要被重构。它不能再仅仅依赖静态的签约数据（比如用户签约了100Mbps速率），而是需要一个更复杂的决策矩阵，输入参数包括：签约数据、实时链路状态、业务类型优先级、用户当前位置等。

    • 场景演绎: PCF收到SMF上报：“链路时延90ms，带宽仅20Mbps”。PCF的决策逻辑启动：

      • 查询该PDU会话上的所有QoS Flow。

      • 识别出“无人机控制”Flow，其要求是20ms时延。决策： 时延目标已无法满足，但此业务优先级最高，必须保障其带宽和转发优先权，同时可能需要通过AF通知应用。

      • 识别出“视频上传”Flow，其要求是50Mbps GBR。决策： 带宽目标无法满足，根据策略，将其速率临时压制到15Mbps，并标记为“非保证”。

      • 识别出“网页浏览”Flow。决策： 优先级最低，暂时分配剩余的可用带宽。

  3. 指令如何执行？ PCF生成新的PCC规则后，通过SMF下发给UPF和gNB。UPF和gNB需要能够快速地应用这些新规则，对数据包进行队列调度、速率整形和转发。整个“感知-决策-执行”的闭环必须在秒级甚至亚秒级完成，才能有效应对链路的快速变化。

这个课题的解决，将使5G网络从一个“静态规划师”进化为一个“战术指挥官”，能够在瞬息万变的战场上，动态调配资源，力保核心任务的完成。

2.3 课题三：协同的升华 —— 如何与应用“对话”？

网络内部的优化终有极限。要实现最佳的用户体验，网络必须与运行其上的应用进行“沟通协作”。

规范原文引用 (5.1.1 Description):

  • What kind of backhaul information can be exposed to the AF, and how to perform the exposure?

深度解析：

  • “What kind of backhaul information”（暴露何种回传信息）: 这是一个开放性的问题。是暴露原始的、实时的时延/带宽数值？还是提供更具指导意义的信息，比如“网络状态等级：优/良/差”？甚至是预测性信息，例如：“警告：预计在1分钟后，由于卫星切换，网络将有30秒的抖动期”。信息的粒度和抽象层次，直接决定了其对应用的价值。

  • “how to perform the exposure”（如何执行暴露）: 这涉及到具体的实现机制。3GPP已经定义了NEF（网络能力开放功能）作为能力开放的统一网关。这里的“how”就是要研究：

    1. AF如何向NEF发起订阅请求，表明它对特定UE的回传信息感兴趣？

    2. PCF（作为信息的源头之一）如何将这些信息发布给NEF？

    3. NEF如何对信息进行加工、鉴权，并最终通知给已订阅的AF？

    4. 整个过程的信令开销、安全性和实时性如何保障？

场景演绎：“极光探索队”的“网络-App”一体化体验

  • 无人机操控App: 其后台AF向NEF订阅了操控无人机那台终端的网络状态事件。当网络时延即将剧增时，PCF通过NEF通知了AF。AF立即向App推送一条消息：“警告：卫星信号切换中，时延增加，已自动切换至高精度悬停模式，请暂停复杂机动”。同时，App的UI上，代表信号质量的图标从绿色变成了黄色。—— 体验从“突然失控”变成了“有预期的平稳降级”。

  • 视频会议App: 其AF收到了网络带宽下降的通知。它立即通知客户端，在用户无感的情况下，将视频分辨率从1080p悄悄降到了720p，并略微增加了视频编码的压缩率。—— 体验从“卡顿马赛克”变成了“清晰度略降但依然流畅的通话”。

这个课题的研究，打破了应用与网络之间的“次元壁”，是实现真正智能化、场景化服务的关键一步。

2.4 课题四：秩序的守护 —— 如何解决数据包乱序？

最后，规范关注到了一个看似细微，但对性能影响极为致命的问题——数据包的顺序。

规范原文引用 (5.1.1 Description):

  • Whether and how to solve packet out-of-sequence problems introduced by dynamic satellite backhaul.

深度解析：

  • “packet out-of-sequence problems”（包乱序问题）: 当网络路径发生切换时，后发的数据包完全有可能走上一条更短的“近路”，从而比先发的数据包更早到达目的地。

  • “introduced by dynamic satellite backhaul”（由动态卫星回传引入）: 明确了问题的罪魁祸首就是卫星链路的动态路由切换。

为什么乱序问题如此严重？

这要从TCP协议说起。TCP是互联网上应用最广泛的传输协议，它天生要求数据按序到达。当接收端收到乱序的包时（比如收到了第1、2、4个包，但第3个还没到），它会认为第3个包在传输中丢失了，于是会触发“快速重传”机制，并启动“拥塞控制”算法，错误地判断网络发生了拥塞，从而主动、大幅地降低发送速率。

  • 场景演绎: 队长艾娃正在上传一份重要的报告。上传开始时，路径是长路径A。中途，网络切换到了短路径B。

    1. 艾娃的笔记本发送了数据包 1, 2, 3, 4, 5…

    2. 包1, 2走了长路径A。

    3. 此时路径切换，包3, 4, 5走了短路径B。

    4. 远在总部的接收服务器，收到的顺序是：3, 4, 5, 1, 2…

    5. 服务器的TCP协议栈“大惊失色”： “天哪！1和2丢了！网络肯定堵死了！” 于是，它立刻通知艾娃的笔记本：“降速！降速！把速度降到原来的1/10！”

    结果，明明网络切换到了更好的路径，上传速度反而因为TCP的误判而一落千丈。

这个课题就是要研究，5G网络（UPF或gNB）是否应该以及如何扮演一个“交通整理员”的角色，在数据包进入核心网或发往UE之前，设立一个“缓冲区”，将乱序的包重新排好队，再按正确的顺序交付。这样做，就可以向上层的TCP协议屏蔽底层的路径切换细节，让一切看起来都井然有序。

总结：打响5G空地融合的第一枪

Key Issue #1，以其无与伦比的深度和广度，构成了TR 23.700-27的核心骨架。它不是一个单一的问题，而是一个由“感知-控制-协同-保序”四大环节构成的系统性工程。

  • 感知是眼睛，解决了“看不清”的问题。

  • 控制是大脑，解决了“不会调”的问题。

  • 协同是语言，解决了“不通气”的问题。

  • 保序是双手，解决了“理不顺”的问题。

这四个课题，环环相扣，共同定义了5G QoS体系为适应卫星回传所必须完成的“进化”。可以说，能否圆满地回答这四大问题，直接决定了5G卫星回传业务的体验优劣和商业成败。在后续的文章中，我们将看到，规范第六章提出的诸多解决方案，正是为了给这四大难题，提交一份份详尽的答卷。

FAQ环节

Q1：Rel-17引入的“卫星回传类别”现在还有用吗？还是被KI#1的研究完全替代了？

A1：它仍然非常有用，但角色发生了变化。它不再是QoS控制的唯一依据，而是成为了一个重要的“初始上下文”。当SMF在会话建立之初就得知这是一个“LEO回传”类别时，它可以立即启用一套预配置的、更具弹性的基础策略，并激活KI#1中所研究的动态监测机制。所以，“类别”就像一个高级别的告警，告诉网络“进入动态模式准备！”，而KI#1的具体机制，则是进入动态模式后执行的精细化操作。

Q2：测量卫星回传的时延和带宽，会消耗很多网络资源吗？

A2：这是一个需要权衡的问题。主动探测（如GTP-U Echo）确实会产生额外的信令开销。因此，后续的解决方案会研究如何智能化地管理探测。例如，可以设计自适应探测频率，在链路稳定时，可能几十秒才探测一次；当检测到性能抖动时，则加密到几秒甚至亚秒级探测一次。同时，对于带宽，更倾向于依赖传输层上报，以避免主动探测带来的巨大开销。目标是在“测量精度”和“资源消耗”之间找到最佳平衡点。

Q3：将网络信息暴露给应用（AF），是否存在安全和隐私风险？

A3：存在，这也是3GPP在设计能力开放框架（NEF）时重点考虑的问题。暴露不是无条件的，而是遵循一套严格的“订阅-授权-认证”流程。应用提供商（AF）必须与网络运营商签订协议，注册其身份。AF在请求信息时，必须经过NEF的严格认证和授权检查，确保它只能获取到它所服务的、且已同意开放信息的那些用户的数据。暴露的信息内容和粒度也会受到严格控制，以防止敏感网络拓扑信息的泄露。

Q4：解决包乱序问题，是在gNB侧做还是在UPF侧做？

A4：两者都可以，取决于数据流的方向。对于上行数据流（从UE到核心网），乱序发生在UPF的接收端，因此UPF需要具备缓存和重排序的能力。对于下行数据流（从核心网到UE），乱序发生在gNB的接收端，因此gNB需要具备相应能力。后续的解决方案（特别是Solution #8）会对此进行更详细的探讨。

Q5：Key Issue 1研究的这些增强功能，是默认对所有用户开启，还是可以按需开启？

A5：通常是按需开启的。这些增强功能会消耗额外的处理和信令资源。因此，网络会根据多种因素来决定是否为某个PDU会话激活它们。这些因素可能包括：用户的签约等级（VIP用户可能默认开启）、业务类型（时延敏感的业务会触发开启）、以及从AMF获取到的回传类型（确认是动态卫星回传后才会激活）。这体现了5G网络资源精细化、策略化管理的思想。

关系图谱