51学通信

深度解析 3GPP TR 23.700-27：6.8 乱世中的秩序：有序交付解决方案 (In-sequence delivery)

23分钟阅读

好的，遵照您的指令，我们继续这场对3GPP TR 23.700-27解决方案的深度剖析之旅。在前几篇文章中，我们已经系统地探讨了如何应对动态QJaaS挑战（KI#1），以及如何通过星上UPF实现边缘计算和本地交换（KI#2 & KI#3）。现在，我们将聚焦于一个看似细微，却对用户体验至关重要的“细节魔鬼”——数据包的乱序问题。

本文将专门深度解读6.8节，即针对Key Issue 1中最后一个子问题的解决方案——有序交付（In-sequence delivery）。

深度解析 3GPP TR 23.700-27：6.8 乱世中的秩序：有序交付解决方案 (In-sequence delivery)

本文技术原理深度参考了 3GPP TR 23.700-27 V18.0.0 (2022-12) Release 18 规范中，关于“6.8 Solution for Key Issue #1: In-sequence delivery”的核心章节，旨在为读者深入剖析动态卫星回传如何引发数据包乱序这一“隐形杀手”，并阐明5G网络为维护端到端通信秩序而设计的精妙机制。

引言：TCP协议的“阿喀琉斯之踵”

在此前的探索中，我们已经见证了5G网络为了驾驭动态卫星回传，所进化出的种种高级能力：从被动适应到主动选择，再到预测未来。然而，即使我们为“极光探索队”选择了最优的路径，并为其配备了最智能的QoS保障，一个潜在的“幽灵”依然可能在不经意间摧毁他们的网络体验。这个幽灵，就是数据包乱序。

我们知道，卫星网络为了优化路由和保持连接，会频繁地、动态地切换数据传输的物理路径。这就好比我们开车时，导航系统为了躲避拥堵，随时可能让我们从主路切换到辅路，再切回主路。虽然最终都能到达目的地，但后出发的车（数据包）完全有可能因为走了更快的“近路”，而比先出发的车更早到达。

对于人类司机来说，这不成问题。但对于互联网上应用最广泛的TCP协议而言，这却是它的“阿喀琉斯之踵”。TCP天生被设计为在基本有序的网络中工作，它将“乱序”视为“网络拥塞或丢包”的强烈信号。一旦侦测到乱序，TCP会立刻启动保守的拥塞控制算法，主动、急剧地降低发送速率，试图“拯救”它误以为已经崩溃的网络。

这导致了一个极其吊诡的结果：“极光探索队”的网络路径明明切换到了更好、更快的链路上，他们的文件下载速度却可能不升反降，甚至跌入谷底。这便是数据包乱序这位“隐形杀手”的厉害之处。

Solution 8的核心使命，就是派遣一位“网络交通警察”，在数据流的两端站岗，将那些因为“抄近路”而造成的混乱队伍重新整理好，再交付给最终的“客户”（TCP协议栈），从而从根本上消除误判，捍卫网络性能。

1. 方案描述 (6.8.1 Description) - 两种场景，同一种“心病”

本节首先描述了问题的成因，并将其划分为两种不同的应用场景：非5G LAN PDU会话和5G LAN PDU会话，揭示了它们在乱序问题上的共性与差异。

1.1 场景一：非5G LAN PDU会话 (点到点通信)

这是最常见的普通上网场景，比如“极光探索队”的队员艾娃，正在通过卫星链路，将无人机拍摄的视频上传到位于地面总部的单个服务器上。

规范原文引用 (6.8.1 Description):

When backhaul between gNB and UPF involves satellite, the inter satellite link may switch due to the satellite movement. This handover of transmission path may happen without UE mobility… which will cause performance decline and user experience degradation, especially for TCP-based applications. In such case the traffic of the service flow of an application may need in-sequence delivery by the network.

深度解析与场景链接：

  • 问题的根源: 规范明确指出，乱序的根源是“星间链路的切换（inter satellite link may switch）”，并且这种切换是“由传输网络自身引起的，与UE移动性无关”。这再次强调了问题的隐蔽性——即使艾娃的无人机和gNB都静止不动，网络路径也可能在太空中悄然改变。

  • 重灾区: 特别点名了“基于TCP的应用（TCP-based applications）”是性能下降的重灾区。

  • 解决方案的核心诉求: 应用的服务流（service flow）可能需要网络提供“有序交付（in-sequence delivery）”的保障。这意味着，网络需要提供一种增值服务，确保数据包“先进先出”。

“网络交通警察”的上岗流程：

规范通过 Figure 6.8.1-1 及其文字描述，勾勒出了这套有序交付服务的激活和工作流程。

  1. 需求的发起 (Step 1-2):

    • 谁来决定需要有序交付？ 规范指出，决策权可以来自应用层（AF）。比如，视频上传应用的AF，深知其业务对TCP性能敏感，它可以在建立会PDU会话时，通过PCF请求网络为这个特定的服务流开启“有序交付”功能。

    • 场景演绎: 艾娃的视频上传App（其AF）向5G网络请求服务时，附带了一个特殊要求：“我这个业务对网络秩序要求很高，请务必保证数据包按顺序到达服务器。”

  2. 网络侧的决策与执行 (Step 3-4):

    • PCF的角色: PCF收到AF的请求后，会生成一条特殊的PCC规则，指示SMF为该QoS Flow启用有序交付。

    • SMF的角色: SMF收到PCC规则后，做出最终决策。规范还补充道，SMF也可以基于本地配置（比如，策略规定所有经过LEO卫星回传的TCP业务都默认开启）来决定启用该功能。

  3. “交通警察”的部署 (Step 6):

    • SMF下发指令: 在PDU会话建立过程中，SMF会向链路的两端——gNB和UPF——下发指令，要求它们为指定的QoS Flow启用“基于序列号的有序交付”。

    • 两位“交警”正式上岗：

      • 在上行方向 (Uplink):

        1. gNB (发货员): 负责为每一个发出的上行数据包（按照从UE接收到的PDCP顺序），打上一个GTP-U序列号（Sequence Number, SN）。

        2. UPF (收货员): 负责检查收到的上行包的SN。如果发现乱序（比如收到了SN=1, 2, 4），它会启动一个定时器并缓存SN=4的包，耐心等待SN=3的到来。如果在定时器超时前SN=3到达了，就按1,2,3,4的顺序将它们交给核心网；如果超时了，就认为SN=3真的丢了，再将后续的包递交上去。

      • 在下行方向 (Downlink):

        1. UPF (发货员): 负责为每一个发往下行的数据包，打上GTP-U序列号。

        2. gNB (收货员): 负责在空口发送给UE之前，执行与上行UPF相同的缓存和重排序逻辑。

通过在链路两端部署这样一对分工明确的“交通警察”，5G网络成功地为TCP协议屏蔽了底层传输路径切换所带来的混乱，确保了端到端的传输秩序。

1.2 场景二：5G LAN PDU会话 (点对多点通信)

现在，问题变得更加复杂。艾娃需要将一份气象数据同时发送给位于不同地点的两位同事：本（在北极营地，与艾娃在同一个gNB下）和查理（在南极科考站，由另一个gNB通过另一颗卫星接入）。这是一个典型的5G LAN组播/广播场景。

规范原文引用 (6.8.1 Description):

For a 5G LAN PDU session: …the QoS flow level based in order delivery mechanism described above… will not work, since the GTP-U SN received at UPF2 and UPF3 will not be in sequence.

深度解析与场景链接：

  • 原有机制的失效: Figure 6.8.1-2 描绘了这个困境。艾娃的PDU会话锚定在UPF1（作为入口）。数据包从UPF1被复制并分别发往服务于本的UPF2和查理的UPF3。

    • 问题所在: UPF1在复制数据包时，会为发往UPF2和UPF3的包打上相同的序列号（比如SN=N）。但这两条路径（UPF1->UPF2 和 UPF1->UPF3）可能经过了完全不同的星间链路，时延天差地别。

    • 结果: UPF2可能先收到了SN=N, N+2, N+4… 而UPF3则可能先收到了SN=N+1, N+3… 此时，UPF2无法判断SN=N+1是被发往了别处还是在路上丢失了，它可能会一直傻等，导致数据传输卡死。点到点的“交警”机制，在点对多点的场景下完全失灵了。

  • 新的解决方案：分段治理

    规范原文引用 (6.8.1 Description):

    In order to solve this issue, the GTP-U SN is removed over N19 tunnel. … The UE1’s gNB and UPF1 guarantees the in-sequence delivery of packets between UE1’s gNB and UPF1, and UE2’s gNB and UPF2 guarantees the in-sequence delivery of packets between UE2’s gNB and UPF2.

深度解析：

这个方案体现了“分而治之”的智慧。网络不再试图去维持一个端到端（艾娃到查理）的全局序列号，因为这不现实。取而代之的是，它将整个传输路径分成了三段，并对每一段分别保障其内部的秩序：

  1. 第一段 (入口段): 艾娃的gNB <--> UPF1。在这一段，启用前述的点到点有序交付机制，确保艾娃的数据包按顺序到达入口UPF1。

  2. 第二段 (核心网段): UPF1 <--> UPF2 和 UPF1 <--> UPF3。这两条路径（即N19隧道）规范假设它们是在地面上的，因此是稳定可靠的，不需要启用序列号机制（SN is removed）。

  3. 第三段 (出口段): UPF2 <--> 本的gNB 和 UPF3 <--> 查理的gNB。在这两段卫星链路上，再次独立地启用点到点的有序交付机制。

这个方案的精妙之处在于：

  • 它承认了在多点分发的核心网段（N19）维持统一序列号的不可行性，并果断放弃。

  • 它将有序交付的责任，下沉到了每一段不稳定的卫星链路的两端。

  • UPF1的职责是确保“收到的包是有序的”。UPF2的职责是确保“发出的包是有序的”。它们各自管好自己的“一亩三分地”，最终共同实现了整个链路的性能保障。

规范原文引用 (6.8.1 Description):

In summary: The out-of-order problem is introduced by dynamic satellite links, thus SMF needs the satellite backhaul category information to ‘active’ the sequence number. For 5G-LAN N19 tunnel on ground in this scenario, SMF should not ‘active’ the sequence number.

这段总结画龙点睛：有序交付机制的激活开关，掌握在SMF手中。SMF需要根据“卫星回传类别”这个情报，来精准地判断哪一段路径是“动态的、需要交警的”，哪一段路径是“稳定的、无需交警的”，从而实现资源的按需部署。

2. 网元影响分析 (6.8.3 Impacts on services, entities and interfaces) - “交通警察”的能力清单

为了部署这支“网络交警队”，相关的网络功能实体都需要进行能力升级。

规范原文引用 (6.8.3 Impacts):

gNB:

  • Support SN based in-sequence delivery.

SMF:

  • Receive the policy of in-sequence delivery.

UPF:

  • Support SN based in-sequence delivery.
  • For 5G LAN case, remove GTP-U SN when transferring packets over N19.

PCF:

  • Receive indication of in-sequence delivery from AF(or vi NEF) and generate corresponding policy to SMF.

AF:

  • Decide the in-sequence delivery by network or by AF/APP when needed.

深度解析：

  • 对gNB和UPF的影响: 它们是执行者。必须具备为GTP-U包添加序列号、以及对接收到的带序列号的包进行缓存和重排序的核心功能。对于UPF，在5G LAN场景下，还需要有“区别对待”的能力——在N19接口上发送数据时，要移除序列号。

  • 对SMF的影响: 它是总调度。需要能接收来自PCF的策略，并据此向gNB和UPF下发“启用/禁用有序交付”的指令。在5G LAN场景下，它的调度能力要更精细，需要能区分N3接口（需要SN）和N19接口（不需要SN）。

  • 对PCF的影响: 它是策略中心。需要能接收来自应用层（AF）的“有序交付”请求，并将其转化为可执行的PCC规则。

  • 对AF的影响: 它是需求源头。应用的功能实体需要有能力判断自己的业务是否需要这项服务，并在需要时向网络提出请求。

总结：于细微处见真章，为性能保驾护航

Solution #8 “有序交付”，看似只是解决一个“小问题”，但它却深刻地体现了5G系统设计的严谨和对用户体验的极致追求。在波澜壮阔的空天一体化宏大叙事中，它扮演了一个不可或缺的“细节守护者”的角色。

  • 它直面了动态路径切换带给TCP协议的致命打击，通过在链路两端引入“添加序列号-缓存-重排序”的机制，为上层应用构建了一个虚拟的、有序的传输通道。

  • 它还展现了在更复杂的5G LAN场景下，通过“分段治理”的智慧，将一个端到端的难题，分解为多个可独立保障的链路段，体现了工程上的务实与灵活性。

  • 它清晰地定义了从应用（AF）到策略（PCF），再到控制（SMF）和执行（UPF/gNB）的完整责任链条，展示了一个功能虽小、五脏俱全的策略驱动型网络服务的实现范例。

对于“极光探索队”而言，这个方案的意义是直接而深刻的。当艾娃看到她的大文件上传速度在网络切换后依然能保持稳定甚至提升时，她可能不会意识到，是两位沉默的“网络交通警察”——gNB和UPF，正在链路的两端，为她的每一个数据包一丝不苟地整理着队伍，确保它们能以最完美的秩序，抵达遥远的目的地。这，就是于细微之处见真章的工程之美。

FAQ环节

Q1：启用有序交付功能，是否会增加额外的时延？

A1：是的，这是一个非常重要的权衡（Trade-off）。为了重排序，接收端（UPF或gNB）必须设置一个缓存（Buffer）和一个等待定时器（Timer）。当一个乱序的包到达时，它会被暂时存放在缓存中，等待“掉队”的包。这个等待的过程，本身就引入了额外的时延。因此，这个功能是一把“双刃剑”：它通过牺牲一点点的绝对时延（用于重排序），来换取TCP协议性能的巨大提升（避免拥塞控制导致的速率雪崩）。定时器的长短设置，是决定这个功能效果好坏的关键参数。

Q2：如果一个数据包真的在传输中丢失了，而不是乱序，这个机制会如何处理？

A2：接收端的等待定时器就是用来处理这种情况的。当接收端（比如UPF）收到了SN=1, 2, 4，它会为等待SN=3启动一个定时器。如果在定时器超时后，SN=3依然没有到达，UPF就会判定SN=3确实已经丢失。此时，它会停止等待，将已经收到的、按序的后续数据包（SN=4, 5…）向上层递交。最终，TCP协议栈会发现SN=3丢失，并由TCP自己的重传机制来负责恢复这个丢失的包。5G网络的有序交付机制，只负责“整理队伍”，不负责“找回失踪的人”。

Q3：为什么在5G LAN场景下，N19地面隧道上要移除序列号？

A3：主要有两个原因：

  1. 没有必要： 规范假设N19隧道是承载在稳定的地面网络（如光纤）上的，这种网络本身几乎不会产生乱序，因此为其增加序列号和重排序机制是多余的，只会增加处理开销和不必要的时延。

  2. 会引发问题： 如方案描述中所述，在点对多点的分发场景下，维持一个全局统一的序列号是极其困难且容易引发逻辑错误的。接收端无法判断一个未收到的序列号是被发往了别处，还是真的丢失了。因此，最简洁、最鲁棒的设计，就是在进入稳定、可控的地面核心网后，就“卸下武装”，回归普通的IP转发。

Q4：这项功能是由用户自己选择开启，还是网络自动决定的？

A4：两者皆可，体现了5G策略控制的灵活性。它可以是应用驱动的，即用户使用的App（通过AF）在建立连接时明确向网络请求这项服务。也可以是网络预置的，即运营商可以在SMF或PCF中配置策略，例如：“所有签约了‘白金服务’的用户，在通过LEO卫星回传时，自动为其TCP业务开启有序交付”。在实际运营中，很可能是两者的结合。

Q5：除了TCP，还有哪些应用会从有序交付中受益？

A5：虽然TCP是最大的受益者，但一些基于UDP的实时应用也能从中受益。例如，一些未经优化的实时视频流或语音流应用，如果收到乱序的UDP包，可能会导致解码器工作异常，产生画面破碎（花屏）或声音跳跃。虽然UDP本身不关心顺序，但上层的应用逻辑可能很敏感。为这些应用提供一个有序的数据流，可以简化应用本身的设计，提升其鲁棒性。

关系图谱