深度解析 3GPP TS 38.423：9.2.1 容器与列表IE定义 (Part 2 - 双连接与数据转发)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.2.1 Container and List IE definitions”的核心章节。本文是该系列的第二部分，我们将聚焦于双连接（DC）和数据转发场景下的关键“数据表格”，包括
PDU Session Resource Setup Info(9.2.1.5/7),DRBs Subject To Status Transfer List(9.2.1.14), 和Data Forwarding Info(9.2.1.16/17)等，深入剖析这些结构化IE如何支撑起5G最复杂的协同场景。
1. 引言：从“蓝图”到“施工详图”
在上一篇中，我们学习了PDU Session Resources To Be Setup List这个宏观的“项目蓝图”，它描绘了在切换或双连接建立时，需要为UE构建哪些PDU会话。今天，我们的工程师小林和他的导师陈工，将从“项目经理”的角色，下沉到“施工队长”，去研究更具体的“施工详图”。
小林在研读S-NODE ADDITION REQUEST消息时发现，PDU Session Resources To Be Added List中嵌套着PDU Session Resource Setup Info – SN terminated和– MN terminated这两种IE。他向陈工请教：“陈工，我理解我们需要为PDU会话建立资源，但这两个名字相似、作用却不同的‘施工图’，它们内部的具体构造和使用场景是怎样的？还有，我们一直提到的数据转发和状态传递，它们的‘包裹清单’和‘交接清单’又是在哪个‘表格’里定义的？”
“非常好的问题！你已经开始关注协议设计中最精细、也是最关键的部分。”陈工说道，“如果说PDU Session Resources...List是‘建筑群规划图’，那么今天我们要学习的...Setup Info系列IE，就是每一栋‘大楼’（承载类型）的具体建筑图纸。而DRBs Subject To Status Transfer List和Data Forwarding Info...，则是搬家时必不可少的‘物品清单’和‘转运单’。没有这些详尽的‘施工详图’，双连接和无损切换都将是空中楼阁。”
今天，我们将深入XnAP协议的“材料库”，逐一解构这些支撑着5G双连接和无损移动性的核心列表与容器IE。
2. 9.2.1.5 & 9.2.1.7 PDU Session Resource Setup Info - 双连接的两种“施工图”
这两个IE是S-NODE ADDITION REQUEST消息中用于定义双连接承载类型的核心“施工图纸”，它们共同描绘了次节点（SN）需要承担的具体工作。
2.1 PDU Session Resource Setup Info – SN terminated (9.2.1.5) - “全权委托”施工图
场景：主节点（MN）决定将一个PDU会话（例如，一个新的文件下载任务）的用户面完全卸载给SN。数据流将从核心网UPF直接通往SN，再到UE。
PDU Session Resource Setup Info – SN terminated IE 内容解析
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| UL NG-U UP TNL Information at UPF | M | 9.2.3.30 | 关键！ 该会话上行数据的最终目的地（UPF） |
| PDU Session Type | M | 9.2.3.19 | |
| QoS Flows To Be Setup List | 1.. | 需要建立的QoS流列表 | |
| Security Indication | O | 9.2.3.52 | 用户面安全指示 |
| … (其他) | O | 如数据转发信息、冗余传输信息等 |
陈工的解读：“这是SN终止承载的‘施工图’。最关键的信息是UL NG-U UP TNL Information at UPF。MN在这里告诉SN：‘这个活儿全权交给你了，你处理完上行数据后，记得直接送到核心网的这个地址’。SN收到后，就会建立一条从自己到UPF的直接NG-U隧道。同时，QoS Flows To Be Setup List详细规定了这项任务的‘质量标准’（QoS要求）。”
2.2 PDU Session Resource Setup Info – MN terminated (9.2.1.7) - “协同作业”施工图
场景：MN决定让SN分担一个由MN自己终止的PDU会话的流量。最典型的就是分离承载（Split Bearer）或SCG承载。
PDU Session Resource Setup Info – MN terminated IE 内容解析
| IE/Group Name | Presence | IE type and reference | Semantics description |
|---|---|---|---|
| DRBs To Be Setup List | 1.. | 核心！ 需要建立的DRB列表 | |
| … | O |
陈工的解读：“这是分离/SCG承载的‘施工图’。它的核心是DRBs To Be Setup List。MN在这里告诉SN：‘对于我主管的这个PDU会话，请你为我分担这几个DRB的无线传输任务’。”
DRBs To Be Setup Item的内部构造:
DRB ID: 需要建立或修改的DRB的ID。MN UL PDCP UP TNL Information: 关键！ 这是SN的上行“交货地址”。SN从UE收到属于这个分离承载的上行数据后，需要通过Xn-U隧道，将数据转发给MN的PDCP层进行汇总。这个IE提供的就是MN侧的GTP-U隧道信息。DRB QoS: 该DRB需要满足的QoS参数。RLC Mode: MN指示SN应该为这个DRB配置的RLC模式（如AM或UM）。QoS Flows Mapped To DRB List: 明确告知SN，这个DRB上承载的是哪些QoS流。
通过这两份不同的“施工图纸”，MN可以灵活地指挥SN，实现不同模式的双连接协同。
3. 9.2.1.14 DRBs Subject To Status Transfer List - “财产交接清单”
在切换或SCG承载类型变更时，源节点需要向目标节点同步PDCP序列号（SN）和超帧号（HFN）的状态。这个IE就是承载这份“交接清单”的标准表格。
DRBs Subject To Status Transfer List IE 内容解析
| IE/Group Name | Presence | Range | IE type and reference |
|---|---|---|---|
| DRBs Subject To Status Transfer Item | 1.. | ||
| >DRB ID | M | 9.2.3.33 | |
| >CHOICE PDCP Status Transfer UL | M | 上行状态 | |
| >>UL COUNT Value | M | COUNT Value (12/18 bit) | |
| >>Receive Status of UL PDCP SDUs | O | 上行接收状态位图 | |
| >CHOICE PDCP Status Transfer DL | M | 下行状态 | |
| >>DL COUNT Value | M | COUNT Value (12/18 bit) |
陈工的解读：“这是我们在SN STATUS TRANSFER消息中详细讨论过的‘交接清单’的具体格式。它以DRB为单位，清晰地列出了每个DRB的上下行COUNT值。UL COUNT Value是接收进度的同步点，而DL COUNT Value是发送进度的同步点。可选的Receive Status...位图则为上行重传优化提供了精细化的信息。这份清单是实现无损移动性的数据核心。”
4. 9.2.1.16 & 9.2.1.17 - 数据转发的“包裹转运单”
这两个IE分别用于响应/指示和请求数据转发，是数据转发流程中的“包裹转运单”。
4.1 Data Forwarding Info from target NG-RAN node (9.2.1.16) - “请把包裹寄到这里”
场景：目标基站B在HANDOVER REQUEST ACKNOWLEDGE中，或新SN在S-NODE ADDITION REQUEST ACKNOWLEDGE中，向源节点/MN提供接收转发数据的地址。
Data Forwarding Info from target NG-RAN node IE 内容解析
| IE/Group Name | Presence | Range | IE type and reference |
|---|---|---|---|
| QoS Flows Accepted For Data Forwarding List | O | 1.. | |
| >QoS Flow Identifier | M | ||
| >PDU Session level DL data forwarding… | O | PDU会话级的转发隧道地址 | |
| Data Forwarding Response DRB List | O | 0..1 | |
| >DL Forwarding UP TNL Information | O | DRB级的转发隧道地址 |
陈工的解读：“这份‘转运单’可以提供两种粒度的‘收货地址’。既可以为整个PDU会话提供一个统一的转发隧道（PDU Session level...），也可以为每个DRB提供一个独立的转发隧道（DRB List中的DL Forwarding UP TNL Information）。这提供了极大的灵活性，目标节点可以根据自身的处理能力和业务特性来决定如何接收转发的数据。”
4.2 Data Forwarding and Offloading Info from source NG-RAN node (9.2.1.17) - “我准备寄出这些包裹”
场景：源基站A在HANDOVER REQUEST中，向目标基站B提议进行数据转发。
Data Forwarding and Offloading Info from source NG-RAN node IE 内容解析
| IE/Group Name | Presence | Range | IE type and reference |
|---|---|---|---|
| QoS Flows To Be Forwarded List | 1.. | ||
| >QoS Flow Identifier | M | ||
| >DL Forwarding | M | ENUMERATED (dl-forwarding-proposed, …) | |
| Source DRB to QoS Flow Mapping List | O |
陈工的解读：“这是源基站的‘发货意向书’。通过QoS Flows To Be Forwarded List，A明确告知B：‘对于这些QoS流，我提议进行下行数据转发 (dl-forwarding-proposed)’。同时，通过可选的Source DRB to QoS Flow Mapping List，A还可以告诉B这些QoS流当前在A侧与DRB的映射关系，为B建立新的DRB配置提供了参考。”
5. 总结：模块化与嵌套——复杂性的优雅解决方案
小林在深入学习了这些列表和容器IE后，对协议设计的艺术有了更深的体会。面对双连接和无损切换这样极其复杂的场景，3GPP的工程师们并没有设计一个臃肿庞大的“万能”消息，而是通过模块化和嵌套的方式，将复杂问题分解。
- 宏观列表 (
PDU Session Resources...) 定义了“要做什么”（为哪些PDU会话建资源）。 - 微观容器 (
...Setup Info) 定义了“具体怎么做”（是建SN终止承载还是分离承载）。 - 辅助列表 (
DRBs...List,Data Forwarding...) 则为这些核心操作提供了必要的“配套工具”（状态同步、数据转发）。
这种设计哲学，使得协议既能清晰地表达复杂的逻辑，又保持了良好的可扩展性。对于小林这样的开发者来说，理解并正确实现这些结构化的“数据表格”，是构建一个稳定、高效、可互通的5G协议栈的根基。
FAQ
Q1：PDU Session Resource Setup Info – SN terminated和– MN terminated只能在S-NODE ADDITION REQUEST中使用吗？
A1：主要用于S-NODE ADDITION REQUEST。但在M-NODE MODIFICATION REQUEST中，如果MN需要为UE新添加一个承载并将其部署在SN上，同样会使用这两个IE。例如，在已有的双连接基础上，为UE添加一个新的SN终止承载。
Q2：DRBs Subject To Status Transfer List中的COUNT值是如何计算的？
A2：COUNT值由PDCP实体维护。
- 下行 (DL)：
DL COUNT Value是发送方PDCP实体维护的TX_NEXT变量，即下一个待发送的PDCP PDU的COUNT值。 - 上行 (UL)：
UL COUNT Value是接收方PDCP实体维护的RCV_NEXT变量，即期望接收的下一个PDCP PDU的COUNT值。 在发送SN STATUS TRANSFER消息时，源节点会读取其PDCP实体的这些状态变量，并将其填入IE中。
Q3：数据转发总是需要的吗？ A3：不是。数据转发是一种优化手段，但会消耗Xn-U接口的带宽和节点的处理资源。是否进行数据转发，是一个由源基站提议、目标基站确认的协商过程。对于时延不敏感的业务（如文件下载），进行数据转发可以避免TCP重传，提升用户体验。但对于某些实时业务，或者网络资源极其紧张时，基站可能选择不进行转发，而是直接丢弃“在途”数据，依靠上层协议来恢复。
Q4：为什么Data Forwarding Info from target NG-RAN node中也包含上行隧道信息（UL Forwarding UP TNL Information）？
A4：在某些特定的移动性或双连接场景下，可能需要进行上行数据的转发。一个典型的例子是，当一个分离承载的SN部分需要被迁移时，旧SN可能需要将已经从UE接收到、但还未转发给MN的上行数据包，转发给新的SN或MN。目标节点通过这个IE，为源节点提供接收上行转发数据的“收货地址”。
Q5：这些列表的最大长度（如maxnoofPDUSessions）对网络性能有什么影响？
A5：这个值定义了协议处理能力的上限。例如，maxnoofPDUSessions为256，意味着理论上一个UE最多可以同时拥有256个PDU会话（尽管实际中远少于此）。这个值会影响基站协议栈在设计时需要预留的内存大小和处理能力。对于普通的智能手机，这个上限绰绰有余。但对于一些特殊的物联网网关设备，它可能同时为背后成百上千个传感器设备建立PDU会话，此时这个上限就可能成为一个需要考虑的瓶颈。