深度解析 3GPP TS 38.415：5G用户面协议的“装箱单”与“说明书”
本文技术原理深度参考了3GPP TS 38.415 V18.2.0 (2025-03) Release 18规范，旨在为读者提供一个关于NG-RAN PDU会话用户面协议的全景视图。
引言：自动驾驶汽车“领航者一号”的“瞬间失神”
“博士，测试数据出来了。”在未来汽车的研发中心，初级通信工程师小李将一份数据报告递给了项目负责人，伊芙琳·瑞德博士。报告的主角，是他们倾力打造的全自动驾驶汽车——“领航者一号”。
“大部分路段表现完美，”小李汇报道，“但在穿越金融区CBD的几个路口时，车载系统记录了数次‘控制指令响应抖动’。虽然时间极短，只有几十毫秒，但对于时速80公里的‘领航者一号’来说，这短暂的‘失神’是绝对不能接受的。我们排查了无线信号，覆盖没有问题。但底层日志显示，有几个来自网络的数据包，被标记为‘未知或错误的协议数据’。”
瑞德博士，一位资深的通信与汽车工程专家，眉头紧锁。她知道，这辆车的“生命线”——5G连接，在最关键的用户数据平面上，出现了问题。数据包，作为信息的载体，在从5G核心网到车辆的漫长旅途中，似乎发生了一些“意外”。
她打开了一份看似不起眼的3GPP规范——TS 38.415。“小李，你看这里。我们每天都在谈论的用户数据，在5G的无线网络内部（NG-RAN）传输时，并不是‘裸奔’的。它们被装在一个叫GTP-U的‘标准集装箱’里。但光有集装箱还不够，我们还需要一张详细的‘装箱单’和‘操作说明书’，告诉每一个中转的‘港口’（网络节点），这个集装箱里装的是什么货物（QoS Flow）、是否是易碎品（需要低时延）、以及货物的发出和接收时间戳。TS 38.415，就是定义这张‘装箱单’的规范。”
“‘领航者一号’的‘瞬间失神’，很可能就是因为某张‘装箱单’在传输中被污染，导致基站无法正确、及时地处理其中的高优先级控制指令。要成为一名合格的自动驾驶通信工程师，你必须学会阅读和理解这份规范。”
这篇文章，将作为我们深度拆解38.415系列的第一篇，带领大家对这份定义了5G用户面“游戏规则”的规范进行一次全面的鸟瞰。我们将跟随瑞德博士的视角，理解这份规范的架构，看看它到底为5G数据的高效、可靠传输，提供了怎样一套精密的“打包”与“解包”流程。
1. 规范的使命：为GTP-U集装箱贴上“智能标签” (第1-4章核心思想)
在深入协议细节之前，我们首先要明白TS 38.415的“历史使命”。规范的前四章，为我们勾勒了这幅蓝图。
1.1 管辖范围：NG-RAN的用户面接口
1 Scope The present document specifies the PDU Session user plane protocol being used over the NG-U, Xn-U and N9 interfaces. … The present document also specifies the PDU Set Information user plane protocol being used over the NG-U, Xn-U, F1-U and N9 interfaces.
规范开宗明义，它的“管辖范围”是5G用户面的几大核心接口：
- NG-U: gNB 与 UPF 之间的接口。
- Xn-U: gNB 与 gNB 之间的接口。
- N9: 核心网内部 UPF 与 UPF 之间的接口。
- F1-U: 分离式基站中，gNB-CU 与 gNB-DU 之间的接口。
它定义了两个核心协议：PDU Session user plane protocol 和 PDU Set Information user plane protocol。
1.2 存在的理由：GTP-U的“超载”
4.1 General aspects In this version of the specification, the PDU Session User Plane protocol data is conveyed by GTP-U protocol means, more specifically, by means of the “PDU Session Container” GTP-U Extension Header as defined in TS 29.281.
这段话揭示了38.415协议的核心实现方式：它并非一个独立的传输协议，而是作为**GTP-U的扩展头（Extension Header）**存在的。
瑞德博士解释道：“GTP-U这个‘集装箱’很标准，但也很‘笨’。它只负责把一个IP包从A点运到B点，但它本身并不关心里面装的是什么。到了5G时代，我们需要在传输数据的同时，传递大量的‘随路信令’，比如：
- 这个数据包属于哪个QoS Flow？
- 这个包是否需要进行QoS监控？
- 它的发出和接收时间戳是多少？
- … 如果把这些信息都塞进IP包里，会破坏IP包的透明性。于是3GPP想了一个绝妙的办法：在GTP-U‘集装箱’的外面，加贴一个‘智能标签’。这个‘标签’，就是38.415定义的用户面协议头。基站和UPF在处理GTP-U包时，会先读取这个‘标签’，获取所有必要的控制信息，然后再打开‘集装箱’处理真正的用户数据。”
2. “逐包清点”：PDU Session User Plane Protocol (第5章)
第5章定义了第一个核心协议，也是更常用的协议。它的核心思想是为每一个用户数据包（PDU），都附加一个包含控制信息的头。
2.1 协议的要素：一张精密的“随货清单”
5.5 Elements for the PDU Session user plane protocol Figure 5.5.2.1-1: DL PDU SESSION INFORMATION (PDU Type 0) Format
规范通过帧格式图，详细定义了这张“随货清单”上可以包含哪些字段。我们来预览几个核心字段：
QoS Flow Identifier (QFI): 这是最重要的字段。它明确标识了这个数据包属于哪个QoS Flow。gNB和UPF根据这个QFI，对数据包执行对应的QoS策略（如调度优先级、速率限制等）。Reflective QoS Indicator (RQI): 用于支持“反射QoS”功能。QoS Monitoring Packet (QMP): 一个标志位，告诉接收方“这个包是一个用于QoS监控的‘探针包’，请记录下它的时间戳”。DL/UL Sending/Received Time Stamp: 高精度的时间戳字段，用于精确测量数据包在各段链路上的传输时延。DL/UL Delay Result: gNB或UE计算出某段链路的时延后，可以通过这个字段，将结果“捎带”回核心网，用于端到端的时延监控。DL/UL QFI Sequence Number: 用于支持基于Qos Flow的重排序和冗余传输（R16特性）。
“‘领航者一号’的控制指令，就会被封装在一个带有高优先级QFI的数据包里，”瑞德博士说，“而回传的视频流，则在另一个QFI的数据包里。正是靠着这个字段，基站才能在资源紧张时，永远优先调度前者。”
3. “打包处理”：PDU Set Information user plane protocol (第6章)
对于某些URLLC场景，可能会产生大量、突发的小数据包（例如，来自多个传感器的数据）。如果为每个小包都加上一个独立的GTP-U头和38.415的协议头，协议开销的占比会非常高，效率低下。
为此，3GPP在R16引入了第二个协议——PDU Set Information user plane protocol。
3.1 核心思想：从“零售”到“批发”
6.1 General The PDU Set Information UP layer uses the services of the Transport Network Layer in order to send its packets over the interface.
这个协议的核心思想是：将一组（a Set）属于同一个QoS Flow的小PDU，在发送端进行聚合，只为这一整“组”数据附加一个包含控制信息的头，然后作为一个整体发送。接收端再根据头信息，将这一组数据进行拆分。
这就像是从“寄送多封平信”改为了“将多封信装在一个快递文件袋里一起寄送”，大大降低了单封信的平均“邮费”（协议开销）。
3.2 PDU Set的“快递面单”
6.5 Elements for the PDU Set Information user plane protocol Figure 6.5.2.1-1: DL PDU SET INFORMATION (PDU Type 0) Format
这个协议的头信息，就像是“快递面单”，除了包含QFI等常规信息外，还增加了一些PDU Set特有的字段：
PDU Set Sequence Number (PSSN): 整个“快递包裹”（PDU Set）的序列号。PDU Sequence Number within a PDU Set (PSN): “包裹”内每个“文件”（PDU）的内部序列号。PDU Set Importance (PSI): 指示这个“包裹”的重要性，用于在拥塞时决定优先丢弃哪个包裹。End of Data Burst (EDB): 指示这是否是一个数据突发的最后一个“包裹”。
“‘领航者一号’上的多个传感器（如雷达、激光雷达）数据，就可以被聚合成一个PDU Set，”瑞德博士解释道，“这样不仅提高了传输效率，PSI字段还能告诉网络，哪些传感器数据更关键，在极端情况下必须优先保住。”
结论：一套为精细化、确定性服务而生的协议
通过对TS 38.415的宏观解读，我们揭示了5G用户面传输的“幕后智慧”。它不再是4G时代那个相对“粗放”的GTP-U隧道，而是一个承载了丰富“元数据”的智能管道。
- 协议定位: 作为GTP-U的扩展头，在不改变IP传输基本模型的前提下，巧妙地实现了控制信息与用户数据的“随路同行”。
- 核心功能:
- 通过QFI，将核心网的QoS策略，精准地映射到了无线传输的每一个数据包上，实现了端到端的QoS打通。
- 通过时间戳和延迟结果字段，构建了一套精密的端到端时延监控机制，为保障uRLLC等时延敏感业务提供了数据基础。
- 双模设计:
- PDU Session协议 (逐包模式)，为通用业务提供了灵活的控制能力。
- PDU Set协议 (打包模式)，为URLLC等小包聚合场景，提供了极致的传输效率。
“领航者一号”的“瞬间失神”，正是因为底层依赖的这张精密的“装箱单”出了问题。要确保自动驾驶、远程医疗、工业控制等5G“杀手级”应用的绝对可靠，深入理解和掌握TS 38.415定义的每一个字段、每一个流程，将是每一位5G工程师，特别是RAN和UPF工程师的必备技能。
从下一篇文章开始，我们将正式进入规范的正文，从第一章开始，逐字逐句，结合更具体的场景，去拆解这部5G用户面“说明书”的每一个细节。
FAQ 环节
Q1：TS 38.415协议和GTP-U协议是什么关系？ A1：是**“寄生”与“宿主”的关系，或者说是“标签”与“集装箱”的关系。GTP-U是承载用户IP包的隧道协议，是“宿主”。而TS 38.415定义的用户面协议，是作为一个GTP-U扩展头**来实现的。这意味着，一个在NG-RAN接口上传输的最终数据包，其结构是：[外部IP头/UDP头] [GTP-U主头] [38.415扩展头] [原始用户IP包]。38.415协议本身不负责路由和传输，它只是为GTP-U隧道增加了额外的信息承载能力。
Q2：既然有了PDCP和SDAP层，它们也能处理QoS，为什么还需要在38.415这个新协议里再定义QFI？ A2：这是一个很好的关于协议分层的问题。SDAP层（在gNB的CU-UP）负责将上层的QoS Flow映射到下层的无线承载（DRB）。PDCP层则在DRB上执行序列号、加密等操作。但是，当数据离开CU-UP，通过F1-U或NG-U接口传输时，它是被封装在GTP-U隧道里的。对于接收端（DU或UPF），它看到的是一个个GTP-U包，它需要一种快速的方法来知道这个GTP-U包里的数据应该对应哪个QoS Flow，以便在自己的调度器中应用正确的QoS策略。38.415协议头中的QFI字段，就提供了这个跨节点、跨接口的QoS标识能力，实现了QoS策略的端到端贯穿。
Q3：PDU Set协议是否会取代PDU Session协议？ A3：不会。它们是为不同场景设计的互补协议。PDU Session协议（逐包模式）更加灵活，适用于各种大小、各种类型的业务，是通用的解决方案。而PDU Set协议（打包模式）是一种专用的优化方案，其优势在于处理大量、突发、尺寸较小的PDU时，能显著降低协议开销。它的实现和调度逻辑更复杂，只有在URLLC等特定场景下，其带来的效率提升才足以弥补复杂度的增加。可以预见，在5G网络中，绝大部分流量仍将通过PDU Session协议来承载。
Q4：作为一名RAN工程师，我最需要关注38.415中的哪些信息？ A4：RAN工程师（特别是gNB-DU的开发者）需要重点关注：1）QFI: 这是调度器执行QoS策略的最直接输入。2）DL QFI Sequence Number: 在实现R16的冗余传输（DRB duplication）时，需要用它来消除重复包。3）DL/UL Delay Ind/Result 和时间戳: 如果需要支持精细化的QoS监控，就需要正确地处理这些字段，进行时延计算和结果上报。4）PDU Set相关字段: 如果需要支持URLLC的小包聚合功能，就需要完整地实现PDU Set的解封装和处理逻辑。
Q5：这份规范对核心网（UPF）工程师重要吗？
A5：同样非常重要。UPF是38.415协议的另一个关键端点。UPF工程师需要：1）在下行方向，正确地生成38.415头，并封装好QFI、时间戳等信息。2）在上行方向，正确地解析UE/gNB上报的38.415头，特别是UL Delay Result等QoS监控结果，并将其上报给SMF或OAM系统。3）支持PDU Set的封装与解封装（如果需要支持相关特性）。可以说，38.415是连接RAN和UPF用户面的“握手协议”，双方都必须严格遵守，才能保证端到端业务的正常运行。