好的，我们继续深入XnAP协议的“数据字典”。
在完成了对9.1节大部分消息的宏观解读后，我们已经对XnAP的“语言”有了整体的把握。现在，我们将进入更细致、更底层的9.2节——Information Element definitions。这个章节就像一本详尽的词典，逐一解释了构成所有消息的“单词”（IE）的精确含义、数据类型和取值范围。
由于9.2节内容极其庞大，我们将按照功能逻辑，分模块进行解读。今天，我们将聚焦于那些在切换和双连接中扮演着“集装箱”角色的关键IE——容器（Container）与列表（List）IE。
深度解析 3GPP TS 38.423：9.2.1 容器与列表IE定义 (Part 1 - 资源建立)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.2.1 Container and List IE definitions”的核心章节。本文将聚焦于资源建立阶段的四大核心“数据表格”：
PDU Session Resources To Be Setup List，...Admitted List，...Not Admitted List，以及QoS Flow List with Cause，深入剖析这些基础数据结构的设计哲学及其在移动性管理中的关键作用。
1. 引言：从“信件内容”到“信纸规格”
在之前的篇章中，我们的工程师小林已经跟随导师陈工，学习了XnAP协议中各种消息（Messages）的用途和交互流程。他已经能够像一位“信使”一样，理解HANDOVER REQUEST（切换请求）、S-NODE ADDITION REQUEST（S节点添加请求）这些“信件”是在何时、由谁、为了什么目的而发送的。
然而，当小林开始着手编写协议栈代码时，他遇到了新的挑战。他看着9.1节的消息定义，发现里面充满了诸如PDU Session Resources To Be Setup List、QoS Flows To Be Setup List这样的“列表（List）”类信息元素（IE）。“陈工，”小林问道，“我知道切换请求信里要包含UE的所有业务信息，但这封信的具体‘格式’是怎样的？如果UE有5个PDU会话，每个会话又有3个QoS流，这些信息是如何组织起来的？总不能随便写在一张白纸上吧？”
“问得好！你已经从关注‘信的内容’，深入到了‘信纸的规格’和‘表格的设计’。”陈工赞许道，“第9.1节告诉我们信里要附上‘附件’，而第9.2节，特别是9.2.1这一小节，就是专门定义这些‘附件’的标准格式。它们就像预先印制好的、结构化的表格和文件夹，我们称之为列表（List）和容器（Container） IE。”
陈工继续解释道：“这些结构化的IE是协议实现的基础。它们确保了无论一个UE的业务有多复杂，相关信息都能被有序、无歧义地打包和解析。今天，我们就来扮演一次‘文具设计师’，深入剖析这些在XnAP中最常用、也是最重要的‘表格’是如何设计的，看看它们如何承载起UE移动性的所有关键信息。”
2. 9.2.1.1 PDU Session Resources To Be Setup List - 切换请求的“核心附件”
这是在切换准备和双连接S节点添加等流程中，由发起方向目标方传递UE PDU会话资源信息的核心载体。它本质上是一个列表，列表中的每一项都详细描述了一个需要建立的PDU会话。
This IE contains PDU session resource related information used at UE context transfer between NG-RAN nodes.
2.1 列表项的“字段”解析
在看完整的表格之前，我们必须先理解构成这个列表的每一个“原子”——即PDU Session Resources To Be Setup Item中的各个IE，它们就像表格中的每一列。
PDU Session ID: 这是PDU会话的唯一标识，一个0到255的整数。它告诉接收方，接下来的所有信息都是围绕这个特定的PDU会话展开的。S-NSSAI: 切片信息。它明确了该PDU会话属于哪个网络切片（例如，是eMBB切片还是URLLC切片）。目标基站需要根据这个信息，来检查自己是否支持该切片，并将资源分配到正确的切片资源池中。UL NG-U UP TNL Information at UPF: 上行用户面隧道信息。这是源基站告诉目标基站：“这个PDU会话的数据，最终需要送到核心网UPF的这个地址和隧道ID上”。它为目标基站指明了上行数据的“最终目的地”。Security Indication: 安全指示。这个IE告诉目标基站，该PDU会话的用户面数据是否需要进行完整性保护或加密，以及要求的级别是“必须（required）”、“优选（preferred）”还是“不需要（not needed）”。QoS Flows To Be Setup List: QoS流列表。这是一个嵌套列表，是这个IE中最核心的部分。一个PDU会话可以承载多个具有不同服务质量要求的QoS流。这个列表就是逐一说明每个QoS流的具体参数。Data Forwarding and Offloading Info from source NG-RAN node: 数据转发信息。源基站在这个IE中提议是否进行数据转发，以及相关的QoS流到DRB的映射关系。Common Network Instance&Network Instance: 网络实例标识。在复杂的网络切片或网络共享场景下，用于标识PDU会话所使用的特定传输网络资源。
2.2 完整的“标准表格”
理解了上述字段后，我们再来看规范中定义的完整表格，就一目了然了。
表 9.2.1.1-1: PDU Session Resources To Be Setup List IE
| IE/Group Name | Presence | Range | IE type and reference | Semantics description |
|---|---|---|---|---|
| PDU Session Resources To Be Setup Item | 1.. | 列表项 | ||
| >PDU Session ID | M | 9.2.3.18 | PDU会话的唯一标识 | |
| >S-NSSAI | M | 9.2.3.21 | 切片信息 | |
| >PDU session Aggregate Maximum Bit Rate | O | 9.2.3.69 | 该PDU会话的总带宽上限 | |
| >UL NG-U UP TNL Information at UPF | M | 9.2.3.30 | 上行用户面隧道信息 | |
| >Source DL NG-U TNL Information | O | 9.2.3.30 | 源端下行隧道信息，用于路径保持 | |
| >Security Indication | O | 9.2.3.52 | 安全要求指示 | |
| >PDU Session Type | M | 9.2.3.19 | PDU会话类型 (IPv4, IPv6等) | |
| >Network Instance | O | 9.2.3.85 | ||
| >QoS Flows To Be Setup List | 1.. | QoS流列表 | ||
| >Data Forwarding and Offloading Info… | O | 9.2.1.17 | 数据转发与卸载信息 | |
| … (其他可选IE) |
场景代入：
源基站A在向目标基站B发送HANDOVER REQUEST时，会填充这张“表格”。对于“李雷”的VoNR通话PDU会话，A会在列表中创建一项，填入其PDU Session ID和对应的语音切片S-NSSAI，并附上其QoS流信息（低时延、保证比特率）。对于李雷的文件下载PDU会话，A会创建另一项，填入其ID和eMBB切片S-NSSAI，并可能在Data Forwarding...中提议进行数据转发。B收到后，就会逐项解析这个列表，为每一个PDU会话准备相应的资源。
3. 9.2.1.2 & 9.2.1.3 - 响应中的“回执单”
目标基站在处理完REQUEST后，需要在ACKNOWLEDGE消息中反馈结果。Admitted List和Not Admitted List就是用于反馈的两种“回执单”。
3.1 PDU Session Resources Admitted List (已接纳的PDU会话资源列表)
这是“成功”的回执单。
表 9.2.1.2-1: PDU Session Resources Admitted List IE
| IE/Group Name | Presence | Range | IE type and reference | Semantics description |
|---|---|---|---|---|
| PDU Session Resources Admitted Item | 1.. | |||
| >PDU Session ID | M | 9.2.3.18 | ||
| >PDU Session Resource Admitted Info | M | |||
| >>DL NG-U TNL Information Unchanged | O | ENUMERATED(True,…) | 指示下行隧道是否未变 | |
| >>Data Forwarding Info from target NG-RAN node | O | 9.2.1.16 | 关键！ 目标节点提供的下行转发地址 | |
| … |
陈工的解读：“Admitted List的核心在于，目标基站B要在这里提供它为每个成功接纳的PDU会话所分配的下行用户面隧道信息。特别是在需要数据转发的场景，Data Forwarding Info from target NG-RAN node这个IE就是B给A的‘收货地址’。A拿到这个地址后，才能通过XN-U ADDRESS INDICATION（或直接开始）将‘在途’数据转发过去。这是保证无损切换的关键一环。”
3.2 PDU Session Resources Not Admitted List (未接纳的PDU会话资源列表)
这是“失败”的回执单。
表 9.2.1.3-1: PDU Session Resources Not Admitted List IE
| IE/Group Name | Presence | Range | IE type and reference | Semantics description |
|---|---|---|---|---|
| PDU Session Resources Not Admitted Item | 1.. | |||
| >>PDU Session ID | M | 9.2.3.18 | ||
| >>Cause | O | 9.2.3.2 | 关键！ 失败的原因 |
陈工的解读：“当B因为资源不足或其他原因无法接纳某个PDU会话时，它必须在这个列表中明确指出是哪个PDU Session ID，并附上一个精确的Cause值，例如no-radio-resources-available。这使得源基站A能够知道切换是‘部分成功’，并可以根据策略决定是继续执行这次不完美的切换，还是彻底取消并寻找其他目标。”
4. 9.2.1.4 & 9.2.1.4a - QoS流的“清单”与“病历”
这两个IE是PDU Session Resources列表中的嵌套列表，用于更精细地管理QoS流。
QoS Flow List(9.2.1.4a): 就是一个简单的QoS流标识符（QFI）的列表。QoS Flow List with Cause(9.2.1.4): 在QFI的基础上，为每个QoS流增加了一个Cause字段。
陈工的解读：“QoS Flow List with Cause是精细化故障诊断的体现。例如，一个PDU会话被拒绝，原因可能是其中某个关键的GBR QoS流无法满足。目标基站可以在PDU会话级的Not Admitted List中给出宏观原因，并在这个嵌套的QoS Flow List with Cause中，为那个特定的QoS流附上更具体的原因，如invalid-qos-combination。这为源基站和后台运维系统提供了更深层次的诊断信息。”
5. 总结：结构化数据是协议的基石
小林今天收获巨大。他明白了，一个看似复杂的XnAP消息，其内部是通过这些设计精巧、层层嵌套的“列表”和“容器”IE来组织信息的。这些结构化的数据格式，是协议得以实现的关键。
- 它们保证了信息的完整性：通过将相关信息组织在同一个列表项（Item）中，确保了上下文的完整传递。
- 它们提供了极大的灵活性：通过大量的可选（Optional）IE和嵌套列表，协议可以根据不同的场景和需求，动态地增减信息内容。
- 它们实现了协议的解耦与扩展：通过
Container等透明容器，将不同协议层的信息隔离开来，使得各层可以独立演进。 - 它们是精细化管理的基础：通过细化到PDU会话和QoS流的列表，网络可以进行更细粒度的资源控制和故障诊断。
对于小林来说，掌握这些“信纸规格”和“表格设计”，是将其对协议流程的理解，转化为稳定、可靠、可互通的代码的必经之路。在接下来的文章中，我们将继续探索9.2.1节中定义的、用于双连接和数据转发的更多高级“容器”与“列表”，进一步完善我们的XnAP“数据字典”。
FAQ
Q1：maxnoofPDUSessions这个范围限制是在哪里定义的？
A1：这个值通常在规范的ASN.1定义部分（9.3节）或常量定义部分（9.3.7节）可以找到。例如，在TS 38.423中，maxnoofPDUSessions被定义为256。这意味着一个XnAP消息中，最多可以处理256个PDU会话的相关信息。这个上限是为了防止信令消息过大，并为协议实现提供明确的数组边界。
Q2：Source DL NG-U TNL Information这个IE在切换请求中有什么作用？
A2：它用于一种特殊的移动性场景，例如在不改变服务核心网UPF的情况下进行切换（Inter-gNB Handover without UPF change）。源基站A通过这个IE告诉目标基站B：“目前核心网UPF发给我的下行数据，走的是这条隧道”。目标基站B在切换成功后，可以直接向UPF请求将这条隧道的终点切换到自己这里，而无需重新建立一条全新的NG-U隧道。这可以优化路径切换的时延。
Q3：PDU Session Resource Setup Info – SN terminated和- MN terminated这两个IE分别在哪个消息中使用？
A3：这两个IE都用于描述需要建立的PDU会话资源，但它们出现在不同的流程中，以区分不同的双连接承载类型：
PDU Session Resource Setup Info – SN terminated(9.2.1.5): 用于S-NODE ADDITION REQUEST消息，表示请求SN建立一个SN终止承载。PDU Session Resource Setup Info – MN terminated(9.2.1.7): 也用于S-NODE ADDITION REQUEST消息，表示请求SN为MN上的一个分离承载（Split Bearer）或SCG承载分配无线资源。
Q4：为什么这些列表IE的设计中，ID（如PDU Session ID）和具体信息（如Admitted Info）是分开的？
A4：这是一种常见的结构化设计模式，清晰地将“索引”和“内容”分开。PDU Session ID作为列表项的“主键”，首先被解析，接收方可以快速地知道这一项是关于哪个业务的。然后，再根据这个ID去处理后续复杂的、嵌套的资源信息。这种结构使得解析逻辑更清晰，也便于快速查找和关联。
Q5：这些表格中的Reference列指向了9.2节的其他部分，这有什么意义？
A5：Reference列起到了“超链接”的作用。例如，PDU Session ID的Reference是9.2.3.18。这意味着如果你想知道PDU Session ID这个IE本身的数据类型（比如，是一个整数）、取值范围（0-255）等更底层的定义，你需要跳转到9.2.3.18小节去查看。9.2.1节定义的是“宏观的组合”，而9.2.3节及后续章节定义的是构成这些组合的“原子元素”。