51学通信

深度解析 3GPP TS 38.423：9.2.1 容器与列表IE定义 (Part 3 - 资源修改与高级特性)

16分钟阅读

好的，我们继续深入XnAP协议的“数据字典”，完成对9.2.1节中剩余关键“容器”与“列表”IE的解读。

深度解析 3GPP TS 3GPP TS 38.423：9.2.1 容器与列表IE定义 (Part 3 - 资源修改与高级特性)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“9.2.1 Container and List IE definitions”的核心章节。本文是该系列的第三部分，我们将聚焦于双连接（DC）资源动态修改阶段，以及支撑DAPS切换、MBS业务等高级特性所依赖的核心“数据表格”，包括PDU Session Resource Modification Info (9.2.1.9/11), PDU Session Resource Change Required Info (9.2.1.18), 以及DAPS和MBS相关的IE。

1. 引言：从“蓝图”到“装修图”与“特种装备清单”

在上一篇中，我们的工程师小林已经掌握了双连接资源建立阶段的“施工图纸”。然而，正如导师陈工所说，双连接的生命周期中，更多的是动态的“装修”和“改造”。

小林在研读S-NODE MODIFICATION REQUEST消息时，发现其中同样嵌套了复杂的列表IE，如PDU Session Resource Modification Info。他向陈工请教：“陈工，我理解了建立资源的‘Setup Info’，那么这个‘Modification Info’里面又该填写什么呢？是只填写变化的部分，还是需要把完整的配置再写一遍？另外，规范里还提到了DAPS切换、MBS会话这些高级功能，它们在切换时，相关的特殊信息又是如何通过这些列表IE来传递的？”

“你的问题非常精准，已经触及了协议设计的核心——如何高效地处理‘变化’，以及如何优雅地支持‘扩展’。”陈工说道，“Modification Info就是双连接的‘装修图’，它的设计核心在于效率，避免冗余信息的传递。而像DAPS、MBS这些高级功能的IE，则如同‘特种装备清单’，它们被巧妙地嵌入到基础的移动性数据结构中，实现了协议的可扩展性。”

今天，我们将完成对9.2.1节的探索，深入解构这些负责“装修”和“特种作战”的“数据表格”，看看XnAP协议是如何实现其灵活性和前瞻性的。

2. 9.2.1.9 & 9.2.1.11 PDU Session Resource Modification Info - 双连接的“装修图”

这两个IE是S-NODE MODIFICATION REQUEST等修改流程中的核心载体，分别用于定义SN终止承载和**MN终止承载（分离/SCG承载）**的修改信息。

2.1 PDU Session Resource Modification Info – SN terminated (9.2.1.9) - “全权委托”业务的调整

场景：主节点（MN）需要修改一个已建立在次节点（SN）上的SN终止承载。例如，核心网通过PDU Session Modification流程，要求提升该承载的QoS。

...Modification Info – SN terminated IE 内容解析

IE/Group NamePresenceIE type and referenceSemantics description
QoS Flows To Be Modified ListO核心！ 需要修改的QoS流列表
>QoS Flow IdentifierM
>QoS Flow Level QoS ParametersO新的QoS参数
QoS Flows To Be Released ListO需要释放的QoS流列表
…O其他如安全、数据转发等修改信息

陈工的解读：“这是‘装修图’的核心思想——增量更新。与Setup Info需要提供完整信息不同，Modification Info中大部分IE都是可选的。MN只需要填写那些发生变化的字段。例如，如果只是提升一个QoS流的GBR，MN就只需要在QoS Flows To Be Modified List中，提供该QoS流的ID和新的QoS Flow Level QoS Parameters即可，而无需重复发送PDU会话类型、安全指示等未发生变化的信息。这大大降低了信令开销。”

2.2 PDU Session Resource Modification Info – MN terminated (9.2.1.11) - “协同作业”的调整

场景：MN需要修改一个分离承载（Split Bearer）的配置，例如，增加一个新的QoS流到这个分离承载上，或者调整其RLC模式。

...Modification Info – MN terminated IE 内容解析

IE/Group NamePresenceIE type and reference
DRBs To Be Modified ListO
DRBs To Be Released ListO
…

陈工的解读：“这里的逻辑与SN终止承载类似，也是增量修改。MN通过DRBs To Be Modified List来指示需要修改哪个DRB，并提供新的配置，如新的RLC Mode或QoS Flows Mapped To DRB List。通过DRBs To Be Released List来指示需要从SN侧移除哪个DRB。这种基于DRB的精细化管理，使得分离承载的动态调整非常灵活。”

3. 9.2.1.18 & 9.2.1.19 - SN变更的“交接清单”

在SN主动发起的SN变更（8.3.5节）流程中，MN在向旧SN回复S-NODE CHANGE CONFIRM时，需要告知其数据转发等信息。PDU Session Resource Change...系列IE就是为此设计的。

  • PDU Session Resource Change Required Info – SN terminated (9.2.1.18): 在S-NODE CHANGE REQUIRED中，由源SN向MN提供。
  • PDU Session Resource Change Confirm Info – SN terminated (9.2.1.19): 在S-NODE CHANGE CONFIRM中，由MN向源SN提供。

陈工的解读：“这两个IE是SN变更流程中，关于PDU会话级别资源如何交接的‘清单’。Required Info用于源SN向MN声明‘对于这个SN终止的PDU会话，我建议进行路径切换’。而Confirm Info则是MN的最终批复，其中会包含从新SN那里获取的数据转发地址。源SN拿到这个地址后，才能启动向新SN的数据转发。”

4. 9.2.1.33 & 9.2.1.34 DAPS 相关IE - 无缝切换的“特种装备”

DAPS（双协议栈）切换是Rel-16引入的“真·无缝”切换技术。为了支持这种“先连接、后断开”的复杂操作，XnAP在基础的数据结构中嵌入了专门的DAPS信息。

  • DAPS Request Information (9.2.1.33)

    The DAPS Indicator IE indicates that the source NG-RAN node requests a DAPS HO for the concerned DRB. 陈工的解读：“这是源基站在HANDOVER REQUEST的DRB to QoS Flow Mapping List中，为某个特定的DRB打上的‘特殊标记’。当它将daps-HO-required包含在内时，就相当于告诉目标基站：‘对于这个DRB，我请求进行一次DAPS切换，请做好相应准备’。”

  • DAPS Response Information (9.2.1.34)

    The DAPS Response Information IE indicates, per DRB, the response to a requested DAPS Handover. 陈工的解读：“这是目标基站在HANDOVER REQUEST ACKNOWLEDGE中对DAPS请求的逐个DRB的回复。它会在dapsResponseIndicator中明确告知源基站：daps-HO-accepted（我同意进行DAPS切换）或daps-HO-not-accepted（我不同意，只能进行普通切换）。这使得DAPS切换成为一个可协商的过程，增强了网络的灵活性。”

5. 9.2.1.36-40 MBS 相关IE - 组播业务的移动性支持

5G引入了MBS（多播/广播服务），允许向一组UE高效地发送相同的数据。当一个正在接收MBS业务的UE发生切换时，网络需要确保其MBS服务在新小区能够被无缝地接续。

  • MBS Session Information List (9.2.1.36): 在HANDOVER REQUEST中使用，由源基站告知目标基站，该UE正在参与哪些MBS会话。
  • MBS Session Associated Information (9.2.1.37): 提供了MBS会话与哪个PDU会话关联的信息。
  • MBS Session Information Response List (9.2.1.38): 在HANDOVER REQUEST ACKNOWLEDGE中使用，目标基站反馈它为哪些MBS会话准备了资源，并提供了数据转发地址。
  • MBS Mapping and Data Forwarding Request Info (9.2.1.39): 包含了MBS业务流到多播无线承载（MRB）的映射关系。
  • MBS Data Forwarding Response Info (9.2.1.40): 目标基站提供的MBS数据转发地址。

陈工的解读：“小林，你可以把这套MBS相关的IE看作是为‘团体旅客’（MBS用户）办理切换时，附带的一份‘旅行团名单’和‘行程安排’。源基站必须告诉目标基站：‘这个旅客属于xx旅行团，请确保他在新地点也能跟上团队的活动’。目标基站则回复：‘好的，我已经为这个旅行团安排好了新的集合点，你可以把后续的行程资料转过来了’。这确保了MBS业务在移动性过程中的连续性。”

6. 总结：可扩展性是协议的生命力

通过对这些高级特性相关IE的剖析，小林深刻地体会到了3GPP协议设计的前瞻性与可扩展性。设计者们并没有为每一个新功能都去创造一套全新的、独立的信令体系，而是巧妙地在现有的、成熟的基础流程（如切换准备）的数据结构中，增加新的可选IE来承载这些新功能的信息。

  • Modification系列IE通过增量更新的模式，实现了对双连接资源的高效动态管理。
  • DAPS和MBS系列IE通过可选嵌入的方式，使得基础的移动性流程能够平滑地兼容和支持这些高级特性。

这种设计哲学，就像是在一栋坚固的建筑（基础移动性框架）上，预留了标准的接口和插槽。当需要增加新功能（如DAPS、MBS）时，只需将符合标准的“新家电”插上即可，而无需对整个建筑进行结构性改造。这正是3GPP协议能够历经数十年演进，不断吸纳新技术、适应新场景，却依然保持其核心稳定性和互操作性的奥秘所在。

FAQ

Q1：PDU Session Resource Modification流程和PDU Session Resource Change流程有什么区别？ A1：这两个术语在XnAP中用于不同的场景。Modification（修改）通常指在同一个SN上，对已建立的资源进行参数调整、增删DRB或QoS流等。SN本身不发生变化。而Change（变更）特指SN的更换，即UE的SCG从一个SN切换到另一个SN。Modification是“装修”，Change是“换房”。

Q2：如果MN请求修改一个DRB，而SN无法满足，会发生什么？ A2：在S-NODE MODIFICATION REQUEST ACKNOWLEDGE消息中，SN会在PDU Session Resources Not Admitted List（或类似的失败列表）中，包含这个无法修改的DRB ID，并附上一个明确的Cause值。MN收到后，就知道这次修改是部分成功或完全失败，并根据策略进行后续处理（例如，回退修改，或者直接释放SCG）。

Q3：DAPS切换相比普通切换，对XnAP信令的主要改变是什么？ A3：主要改变在于增加了DRB粒度的协商能力。普通切换的资源准备是PDU会话级的，而DAPS切换允许源基站在HANDOVER REQUEST中，为每一个DRB单独请求是否启用DAPS（通过DAPS Request Information IE）。目标基站也同样在ACKNOWLEDGE中，为每一个DRB单独回复是否接受DAPS。这使得网络可以根据不同DRB承载的业务特性（如时延敏感度），来灵活地决定是否使用DAPS这一高级特性。

Q4：一个UE可以同时加入多个MBS会话吗？ A4：可以。正因为如此，MBS Session Information List被设计成一个列表（List），允许源基站在切换时，一次性告知目标基站该UE当前参与的所有MBS会话，目标基站则需要为每一个会话都尝试准备资源。

Q5：这些高级特性的IE都是可选的（Optional），如果一个老版本的基站收到了包含这些IE的消息，会怎么办？ A5：这取决于该IE的关键性（Criticality）。根据我们在第4章学习的兼容性原则：

  • 如果该IE的Criticality被定义为ignore，老版本的基站会直接跳过这个它不认识的IE，并继续处理消息的其他部分。例如，一个不支持DAPS的基站收到DAPS请求，它会忽略DAPS相关的IE，并按普通切换来准备资源。
  • 如果该IE的Criticality被定义为reject，老版本的基站会认为整个消息都无法处理，并回复一个失败消息。这通常用于那些如果不支持就会导致严重问题的关键特性。 这种机制确保了新老版本设备间的向后兼容性。

关系图谱