51学通信

深度解析 3GPP TS 38.415：第1-4章 基础篇：5G用户面协议的“开篇序言”

19分钟阅读

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

深度解析 3GPP TS 38.415：第1-4章 基础篇：5G用户面协议的“开篇序言”

本文技术原理深度参考了3GPP TS 38.415 V18.2.0 (2025-03) Release 18规范中，关于“第1章 Scope”、“第2章 References”、“第3章 Definitions and abbreviations”以及“第4章 General”的核心章节，旨在为读者提供一个理解5G用户面传输“随路信令”协议的基础框架。

引言：从“沉默的”集装箱到“会说话”的智能货柜

在上一篇的概述中，我们认识了自动驾驶汽车“领航者一号”。它的开发者，瑞德博士，将TS 38.415比作是为5G数据传输的“GTP-U集装箱”加贴的“智能标签”。这个“标签”使得原本沉默寡言、只负责闷头运货的GTP-U协议，变成了一个“会说话”的智能货柜，能够在运输途中，实时地告诉每一个经手的中转站关于这批货物的关键信息。

“小李，在你深入研究这张‘智能标签’上密密麻麻的字段之前，你必须先理解它的‘材质’、‘标准规范’和‘使用说明书’。”瑞德博士对她的助手小李说，“TS 38.415的前四章，就是这份‘总纲’。它虽然没有触及任何一个具体的协议字段，但它定义了这份规范的法律地位、知识背景、专业术语和核心实现原理。不读懂它，你后面就会迷失在比特和字节的丛林里。”

这篇文章，我们将跟随初级工程师小李的视角，在瑞德博士的指导下，系统地学习TS 38.415的基石——第1至第4章。我们将一起解开这部定义了5G用户面“随路信令”协议的“开篇序言”，为后续深入探索其精妙的协议设计，打下坚实的基础。

1. 明确边界：这份规范到底管什么？ (第1章 Scope)

任何严谨的技术规范，开篇必谈范围。TS 38.415的第一章“Scope”，用极其精炼的语言，划定了它的“一亩三分地”。

The present document specifies the PDU Session user plane protocol being used over the NG-U, Xn-U and N9 interfaces. Applicability to other interfaces is not precluded.

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.

1.1 深度解析：定义两大协议，覆盖核心UP接口

瑞德博士为小李划出了这段话的重点：

  • 定义了两大协议:

    1. PDU Session user plane protocol: 这是R15就引入的基础协议，我们称之为“逐包模式”。它为每一个用户数据包（PDU）都附加控制信息。

    2. PDU Set Information user plane protocol: 这是R16为URLLC等场景引入的增强协议，我们称之为“打包模式”。它将一组（a Set）PDU聚合在一起，只附加一个公共的控制信息头。

  • 覆盖了三大/四大用户面接口:

    • NG-U (gNB ←> UPF): 这是RAN和核心网之间的主用户面接口，是保障业务的“最后一跳”陆路运输。

    • Xn-U (gNB ←> gNB): 这是基站之间的用户面接口，主要用于切换时的数据转发，保障移动业务的连续性。

    • N9 (UPF ←> UPF): 核心网内部UPF之间的接口，用于多UPF级联或漫游场景。

    • F1-U (gNB-CU ←> gNB-DU): 这是分离式gNB架构下，中央单元和分布单元之间的用户面接口。值得注意的是，更高效的“打包模式”(PDU Set)也适用于这个对时延和效率要求极高的中传接口。

  • 开放的可能性: Applicability to other interfaces is not precluded. (不排除适用于其他接口)。这为未来协议的扩展应用（例如，应用在非3GPP接入的接口上）留下了空间。

“所以，小李，你要记住，”瑞德博士总结道，“38.415的核心使命，就是在RAN内部和RAN与核心网之间的用户面隧道上，为GTP-U包附加一层‘随路控制信令’。它的战场，不在空口，而在这些有线接口上。”

2. 知识的源头：它山之石，可以攻玉 (第2章 & 第3章)

第2章“References”和第3章“Definitions and abbreviations”，是这份规范的“学术背景”和“专业词典”。

2.1 关键参考文献解读

瑞德博士指出了几个必须理解的关键“源头”规范：

3GPP TS 29.281: “General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)“.

3GPP TS 23.501: “System Architecture for the 5G System; Stage 2”.

3GPP TS 38.401: “NG-RAN; Architecture Description”.

“你看，”瑞德博士解释道，“要理解38.415，你至少需要这三份‘前置知识’：”

  1. TS 29.281: 这是GTP-U协议的“圣经”。因为38.415是作为GTP-U的扩展头存在的，所以你必须先了解GTP-U的基本格式和扩展头机制。

  2. TS 23.501: 这是5G系统架构的“总纲”。38.415中定义的很多概念，如QoS Flow, PDU Session, Reflective QoS等，其最原始的定义和业务逻辑都在这份架构规范里。

  3. TS 38.401: 这是NG-RAN架构的“说明书”。它详细定义了NG-U, Xn-U, F1-U这些接口的位置和功能，是理解38.415应用场景的基础。

2.2 核心术语辨析

第3章定义了本规范中使用的专业术语。瑞德博士挑出了几个小李容易混淆的概念：

Data Burst: as defined in TS 23.501.

PDU Set: as defined in TS 23.501.

  • Data Burst (数据突发): 在23.501中，它通常指一段时间内连续到达的一批数据，这批数据前后都有明显的静默期。它是触发QoS监控和吞吐率计算的一个逻辑单元。

  • PDU Set (PDU集): 这是R16为URLLC引入的新概念。它指的是一组在发送端被特意聚合在一起，共享某些属性（如重要性、序列号）并作为一个整体进行处理的小PDU。

“‘Data Burst’是一个被动观察到的现象，而‘PDU Set’是一个主动构造的实体。”瑞德博士强调，“这是理解两个协议适用场景的关键区别。”

QFI (QoS Flow Identifier)

RQI (Reflective QoS Indication)

  • QFI: 6比特的数字，是QoS Flow的唯一标识。它是38.415协议中最核心的字段。

  • RQI: 1比特的标志，用于指示网络是否要为这个下行数据流开启“反射QoS”。开启后，UE可以在上行方向，“模仿”下行数据流的QoS标记，来发送自己的上行数据，从而简化了UE侧的QoS配置。

3. 实现的总纲：协议的定位与承载 (第4章 General)

第4章是基础篇的“灵魂”，它用最简洁的语言，揭示了38.415协议的实现本质。

4.1 General aspects

The PDU Session User Plane protocol and PDU Set Information User Plane protocol are located in the User Plane of the Radio Network Layer above the Transport Network Layer of the interface.

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.

3.1 深度解析：“层上层”的巧妙设计

这段话信息量巨大，瑞德博士为小李画了一张协议栈简图：

| |

| :---: |

| 38.415 Protocol (PDU Session / PDU Set) | ⇐- Radio Network Layer

| GTP-U |

| UDP | ⇐- Transport Network Layer

| IP |

  • above the Transport Network Layer: 38.415协议逻辑上位于传输网络层（UDP/IP）之上。这意味着它不关心底层是用IPv4还是IPv6，也不关心物理链路是光纤还是微波。

  • conveyed by GTP-U protocol means: 它不是一个独立的协议，而是被承载在GTP-U协议之上的。

  • "PDU Session Container" GTP-U Extension Header: 这就是最关键的实现细节。38.415协议的所有信息，都被封装在一个名为“PDU Session Container”的GTP-U扩展头中。

3.2 场景化举例：“领航者一号”控制指令的封装之旅

当一条“紧急刹车”指令（一个IP包）从核心网的UPF发往“领航者一号”时，它会经历以下封装过程：

  1. 38.415层: 网络为这个IP包创建一个DL PDU SESSION INFORMATION（PDU Type 0）的38.415协议头。头中包含了高优先级的QFI、QMP（QoS监控）标志、DL Sending Time Stamp（发送时间戳）等关键信息。

  2. GTP-U层: GTP-U协议将这个“38.415头 + 原始IP包”的组合，封装成自己的Payload。然后在前面加上GTP-U主头（包含隧道ID等），并特别在主头中设置一个标志位，告诉对端“我后面跟了一个扩展头！”。这个扩展头的类型，就是“PDU Session Container”。

  3. UDP/IP层: 最终，整个GTP-U大包被封装在UDP/IP包中，通过N3接口的物理网络，发往gNB。

“你看，”瑞德博士总结道，“这个设计的最大优点是向后兼容和灵活性。不认识38.415的旧网络设备，依然可以根据GTP-U主头进行正常的隧道转发。而支持38.415的新设备，则可以通过解析这个扩展头，获取到丰富的QoS和监控信息，从而实现精细化的处理。这就是所谓的‘智能标签’的实现原理。”

结论：一份通往精细化用户面的“入门指南”

通过对TS 38.415前四章的学习，我们清晰地了解了这部规范的设计哲学与核心框架。

  1. 明确的使命: 为NG-RAN用户面接口上的GTP-U隧道，提供标准化的**“随路控制信令”**能力。

  2. 清晰的定位: 作为GTP-U的扩展头实现，既利用了GTP-U成熟的隧道机制，又提供了丰富的扩展能力。

  3. 双模的设计: 通过**“逐包模式” (PDU Session)** 和 “打包模式” (PDU Set)，兼顾了通用业务的灵活性和URLLC业务的极致效率。

  4. 开放的生态: 紧密依赖于系统架构（23.501）、RAN架构（38.401）和GTP-U（29.281）等核心规范，是整个5G协议体系中有机的一环。

这四章“开篇序言”，为我们后续深入探索38.415协议的每一个字段、每一个流程，提供了必不可少的上下文和“阅读说明”。掌握了这些基础，我们才能真正理解5G是如何在用户数据平面的微观世界里，为自动驾驶、远程医疗等要求严苛的未来应用，构建起坚实、可靠的“信息基石”的。

FAQ 环节

Q1：为什么这个协议被称为“PDU Session user plane protocol”，而不是直接叫“GTP-U扩展协议”？

A1：这个命名更能体现其功能和逻辑层次。虽然它的实现载体是GTP-U扩展头，但它服务的对象是PDU会话。它承载的所有信息，如QFI、RQI等，其语义和作用域都是在一个PDU会话的上下文中定义的。称其为“PDU Session user plane protocol”，更能清晰地将其与控制面的PDU会话管理协议（NAS信令）区分开，并强调其在用户面（User Plane）的作用。

Q2：这个协议是在哪个网元上终结的？UE会感知到它吗？

A2：这个协议是在NG-RAN的用户面接口两端的网络节点上终结的。例如，在NG-U接口上，它就在gNB和UPF之间进行解析和生成。UE完全感知不到这个协议的存在。UE看到的只是原始的IP包。当一个下行GTP-U包到达gNB时，gNB会解析38.415头，获取QFI等信息用于无线调度，然后剥离掉GTP-U头和38.415头，只将最里面的原始IP包通过空口发送给UE。

Q3：PDU Set Information协议为什么也适用于F1-U接口，而PDU Session协议的Scope里没有明确提F1-U？

A3：这是一个很好的细节观察。PDU Set Information协议（打包模式）的核心优势是降低开销、提升效率，这对于带宽和时延都非常宝贵的F1-U（中传）接口来说，价值巨大。因此规范在R16引入该协议时，明确将其应用范围扩展到了F1-U。而PDU Session协议（逐包模式），虽然在逻辑上也需要在CU和DU之间传递QFI等信息，但在R15的初始设计中，F1-U接口的用户面协议（TS 38.475）有自己独立的帧格式来承载这些信息。随着版本的演进，为了统一，新功能倾向于都使用38.415的框架。但可以理解为，38.415的核心思想（传递QFI等信息）在F1-U上同样适用，只是实现载体略有不同。

Q4：如果一个网络节点（如一个旧的gNB）不支持38.415的扩展头，会发生什么？

A4：根据GTP-U协议（TS 29.281）的规定，如果一个节点收到一个它不认识的GTP-U扩展头，它应该默默地忽略这个扩展头，并继续处理GTP-U包中的下一个头（可能是另一个扩展头，也可能是最终的用户数据）。这意味着，不支持38.415的旧设备，依然可以完成基本的IP包转发功能，但它将无法获取到QFI、时间戳等任何“智能标签”上的信息，也就无法执行任何精细化的QoS、时延监控等5G增强功能。这保证了网络的向后兼容性。

Q5：学习这份规范，对于测试工程师有什么特别的意义？

A5：意义非常重大。对于从事5G用户面协议测试的工程师来说，TS 38.415就是测试用例设计的“圣经”。你需要：1）构造各种合规和异常的38.415协议帧，来测试gNB/UPF的协议栈健壮性。例如，构造一个带有无效QFI的帧，看设备是否能正确处理。2）验证设备生成的38.415协议帧是否符合规范。例如，检查UPF下发的DL Sending Time Stamp是否准确。3）设计基于38.415功能的端到端测试用例。例如，设计一个用例，验证当UPF发送了带有RQI=1的包后，gNB和UE是否正确地激活了反射QoS功能。

关系图谱