51学通信

深度解析 3GPP TS 38.415：第6章 PDU Set Information Protocol (5G URLLC的“集装箱”特运专列)

18分钟阅读

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 38.415：第6章 PDU Set Information Protocol (5G URLLC的“集装箱”特运专列)

本文技术原理深度参考了3GPP TS 38.415 V18.2.0 (2025-03) Release 18规范中，关于“第6章 PDU Set Information user plane protocol”的核心章节，旨在为读者提供一个关于5G如何为URLLC小包业务提升传输效率的深度解析。

引言：智能工厂机械臂的“微指令”风暴

“博士，‘领航者一号’的问题解决了，但智慧工厂的‘力神一号’机械臂又出了新状况。”在一次项目周会上，小李提出了新的挑战，“‘力神一号’由六个独立的关节电机控制，控制系统需要以每10毫秒一次的频率，同时向这六个电机发送微小的控制指令包。我们发现，在业务高峰期，这些‘微指令’包的上行传输成功率会下降，导致机械臂动作出现微小的‘抖颤’。”

瑞德博士调出了网络分析仪的抓包数据。“小林，你看。每个指令包只有几十个字节，但我们为了发送它，却要套上IP头、UDP头、GTP-U头，还有38.415的头……林林总总加起来，协议头的开销竟然是有效载荷的好几倍！这就像是为了寄送一粒米，却用了一个大木箱，效率太低了。”

“更糟糕的是，”她继续分析，“这六个独立的指令包，在无线调度时被当作六个独立的‘散客’。调度器为了凑齐一个更大的传输块（TB）以提高频谱效率，可能会把它们和别的业务‘拼车’，这无疑增加了它们的排队时延。对于要求步调一致的机械臂来说，任何一个指令包的‘迟到’，都会导致整个动作的不协调。”

瑞德博士将TS 38.415的屏幕切换到第6章。“为了解决URLLC场景下这种‘大头娃娃’式的低效传输和‘散客’调度带来的不确定性，3GPP在R16引入了一套全新的‘特运方案’——PDU Set Information user plane protocol。这一章，就是这套方案的‘操作手册’。”

“它的核心思想，是**‘化零为整，打包运输’**。网络不再把这六个指令包当作散客，而是将它们识别为一个‘旅行团’（PDU Set），为它们统一办理‘登机手续’（只加一个公共的头），并安排它们搭乘同一趟‘专机’（在同一个TB中传输）。今天，我们就来学习这套‘集装箱特运专列’的运作机制，看看5G是如何为工业控制等场景，提供极致高效、高同步的传输保障的。”

1. “批发”的艺术：PDU Set协议的核心流程 (6.4)

第6章的核心，在于定义了一套与第5章“零售模式”并行的“批发模式”。

6.4.1.1 Successful operation (DL)

The purpose of the Transfer of DL PDU Set Information procedure is to send PDU Set information and indication of End of Data Burst related to a QoS flow from UPF to NG-RAN node…

1.1 深度解析：聚合与解聚合

  • 发送端 (UPF/gNB-CU): 在发送数据时，协议栈的适配层（Adaptation Layer）会识别出属于同一个QoS Flow、且可以被聚合在一起的一组小PDU（例如，“力神一号”的六个关节指令）。它将这一组PDU作为一个PDU Set，并为它们生成一个统一的38.415 PDU Set Information头，然后将这个“头+PDU Set”的整体，交给GTP-U进行封装和传输。

  • 接收端 (gNB-CU/DU): 收到GTP-U包后，解析出PDU Set Information头。根据头中的信息（如下文详述的PSN、PSSize等），它能准确地知道这个“包裹”里有多少个小PDU、每个PDU的边界在哪里，从而将它们精确地拆分出来，再分别送往上层（如PDCP层）。

这个简单的“聚合-解聚合”流程，带来了两大核心优势：

  1. 降低协议开销: 原本需要6个GTP-U头 + 6个38.415头，现在只需要1个GTP-U头 + 1个38.415头。对于几十字节的小包，效率提升可达数倍。

  2. 保障传输同步性: 由于被捆绑在一个PDU Set里，这一组PDU在网络内部（如F1-U接口）和空口调度时，有极大概率被作为一个整体进行处理和传输。这为机械臂的多个关节指令提供了内生的同步保障。

2. “集装箱封条”的秘密：PDU Set关键字段解析 (6.5)

Figure 6.5.2.1-1: DL PDU SET INFORMATION (PDU Type 0) Format 定义了PDU Set协议头的精细结构。它就像是“集装箱”上的“封条”和“货运单”，记录了这批货物的全部关键信息。

2.1 标识与身份

  • PDU Type (6.5.3.1): 同样是4比特，但在这里，Value range: {0= DL PDU SET INFORMATION, 1-15=reserved...}。PDU Type=0被专门赋予了“DL PDU Set”的含义，接收方一看到这个值，就知道后面跟着的是一组PDU，而不是单个PDU。

  • QoS Flow Identifier (QFI) (6.5.3.3): 同样是6比特，标识了这整个PDU Set属于哪个QoS Flow。

2.2 “包裹”的宏观描述

  • PDU Set Sequence Number (PSSN) (6.5.3.10):

    Description: This parameter indicates the sequence number of the PDU Set… acting as an identifier for the PDU Set.

    Field length: 10 bits.

    解读: 这是为PDU Set这个“大包裹”分配的序列号。接收端通过检查PSSN的连续性，可以检测是否有一整组PDU在传输中丢失。

  • PDU Set Importance (PSI) (6.5.3.9):

    Description: This parameter indicates the importance of the current PDU Set compared to other PDU Sets within the same QoS flow. Lower values shall indicate a higher importance…

    解读: 4比特的重要性指示。它允许发送方在一个QoS Flow内部，再对不同的PDU Set进行优先级细分。例如，“力神一号”的常规移动指令，PSI可能是10；而一个紧急停止的指令组，PSI可以被设为1（最高优先级）。在网络拥塞时，DU或UPF就可以根据PSI，优先丢弃重要性较低的PDU Set。

2.3 “包裹”的内部结构描述

这是实现精确拆分的核心。

  • PDU Sequence Number within a PDU Set (PSN) (6.5.3.11):

    Description: This parameter indicates the sequence number of the current PDU within the PDU Set. The PSN shall be set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU set…

    解读: PDU Set内部每个小PDU的编号，从0开始递增。它与PSSN一起，构成了两级序列号体系。

  • PDU Set Size (PSSize) (6.5.3.12) & PSSI (PDU Set Size Indicator) (6.5.3.5):

    PSSize字段（3个字节）用于指示PDU Set中所有PDU的总大小（不含头）。PSSI是一个1比特的标志位，告诉接收方PSSize字段是否存在。

    解码: PSSize是实现拆分的关键之一，但它只提供了总长度。要找到每个PDU的边界，还需要别的信息。在早期的版本或某些实现中，可能需要依赖上层协议（如PDCP）的定界符。而在更高效的实现中，通常会与其他字段（如固定的PDU大小）配合使用。

2.4 结束的标志

  • End PDU of the PDU Set (EPDU) (6.5.3.7):

    1比特标志，1表示当前这个PDU是本Set的最后一个PDU。

  • End of Data Burst (EDB) (6.5.3.8):

    1比特标志，1表示当前这个PDU是整个数据突发的最后一个PDU。

场景化诊断：机械臂“抖颤”之谜的破解

小李在分析“力神一号”的上行数据包时，发现了一个问题。正常情况下，机械臂每10ms上报的6个关节状态PDU，应该被gNB的适配层聚合成一个PDU Set，并通过F1-U接口发往CU。

然而，抓包数据显示，PDU Set Information头中的EPDU标志位，总是在PSN=2时就被置为了1。这意味着，gNB每次只把前3个关节的数据打包成了一个Set，后3个关节的数据则被打包成了另一个Set。

“王哥，问题在这！”小林说，“DU侧的聚合逻辑有Bug！它错误地将一个完整的‘旅行团’拆成了两个，导致这两个小团体被调度器分开处理，它们到达CU的时间不再同步，从而引发了机械臂的‘抖颤’！”

结论：效率与同步，为URLLC而生的精巧设计

通过对第6章的学习，我们深入了解了5G为应对URLLC挑战而设计的这套“集装箱特运专列”系统。它不再是简单的协议，而是一套精巧的、面向特定场景的优化解决方案。

  1. 核心价值: 通过聚合传输，显著降低了小包业务的协议开销，提升了频谱效率和传输效率。

  2. 同步保障: 将一组相关的PDU捆绑为一个PDU Set，为它们在网络内部的同步传输提供了内生机制。

  3. 精细化控制: 引入了两级序列号（PSSN/PSN）和重要性指示（PSI），实现了对聚合数据流更精细的可靠性与优先级管理。

  4. 清晰的边界: 通过PDU Type与第5章的“逐包模式”进行明确区分，保证了协议栈的清晰和可扩展性。

PDU Set Information协议，是5G网络从一个“尽力而为”的通信管道，向一个能够提供“确定性”服务的工业级网络演进的关键一步。理解并善用这套协议及其测量，是每一位致力于将5G技术应用于工业互联网、车联网等垂直行业的工程师，必须掌握的核心能力。

FAQ 环节

Q1：PDU Set聚合是在哪个网络节点上发生的？

A1：聚合发生在发送端。在下行方向，聚合操作由UPF（或gNB-CU，取决于具体实现和接口）的用户面协议栈的适配层完成。在上行方向，聚合操作由gNB-DU的适配层完成，它将从多个UE（或同一个UE的多个逻辑信道）收到的、去往同一个CU的小PDU进行聚合，再通过F1-U接口发送。UE本身通常不执行PDU Set的聚合。

Q2：PDU Set协议是否只适用于URLLC业务？

A2：虽然PDU Set协议的设计初衷主要是为了满足URLLC场景下“海量小包、低时延、高可靠”的需求，但它在技术上并不局限于URLLC。任何符合“小包聚合能显著提升效率”特征的业务，都可以从这个协议中受益。例如，某些eMBB业务中的交互式信令，或者mMTC场景下大量传感器数据的汇聚上报，也可能采用PDU Set来提升传输效率。

Q3：PDU Set Importance (PSI)和QoS Flow的ARP (Allocation and Retention Priority)有什么区别？

A3：它们作用的粒度和范围不同。ARP是QoS Flow级别的优先级，由SMF/PCF在核心网层面定义。它决定了在网络资源竞争时（如接纳控制），哪个QoS Flow应该被优先保留或抢占资源。而PSI是PDU Set级别的优先级，它在同一个QoS Flow内部生效。它允许发送端对属于同一个业务流的不同数据块，再进行一次重要性细分。例如，一个视频流（同一个QFI）中，包含关键帧（I帧）的PDU Set，其PSI可以设为最高；而包含非关键帧（P/B帧）的PDU Set，其PSI可以设为较低。这样，在发生瞬时拥塞时，网络可以优先丢弃非关键帧，最大限度地保证画面的可恢复性。

Q4：接收端是如何知道一个PDU Set中有多少个PDU，以及每个PDU的长度的？

A4：这是一个很好的关于协议实现细节的问题。规范本身定义了PSN（内部序列号）和EPDU（结束标志），这可以告诉接收端一个Set里PDU的数量。但要知道每个PDU的长度，有几种可能的方式：1）固定长度： 对于某些应用（如语音），每个PDU的长度是固定的，接收端可以按固定长度进行切割。2）上层协议定界： PDU Set内部封装的是上层协议（如PDCP）的PDU，PDCP PDU自身包含长度信息或定界符，接收端可以将整个PDU Set的Payload交给PDCP层来解析。3）长度指示列表： 在更高级的实现中，协议头本身可以被扩展，包含一个每个PDU的长度列表。TS 38.415选择了将这些实现细节留给具体的应用场景和适配层来处理，以保持用户面协议的简洁性。

Q5：Unsuccessful operation (6.4.1.2) 为“Void”，是否意味着PDU Set的传输不会失败？

A5：不是。与第5章一样，“Void”意味着规范在本章节没有为PDU Set的传输失败定义专门的、独立的信令流程。PDU Set的传输失败，同样是由底层协议的机制来检测和处理的。例如：1）GTP-U/UDP/IP层的校验和错误，会导致整个包被丢弃。2）PDU Set Sequence Number (PSSN)的不连续，可以让接收端检测到整个PDU Set的丢失，并触发上层（如TCP或应用层）的重传机制。3）PDU Set内部的PDU Sequence Number (PSN)不连续，则可以帮助接收端检测到Set内部的PDU丢失。

关系图谱