51学通信

深度解析 3GPP TS 28.405：附录A & B 实例代码与演进历史 (系列终章)

20分钟阅读

好的，这是本系列文章的最后一篇。我们将一同探索规范的附录部分，通过解读实例代码和演进历史，为我们对3GPP TS 28.405的深度探索之旅画上一个圆满的句号。

深度解析 3GPP TS 28.405：附录A & B 实例代码与演进历史 (系列终章)

本文技术原理深度参考了3GPP TS 28.405 V18.8.0 (2024-12) Release 18规范中，作为最终章的“Annex A (informative): Plant UML source code”和“Annex B (informative): Change history”。本文旨在带领读者从理论走向实践，通过解读附录A中的“设计蓝图”（实例代码），并回顾附录B中的“建设日志”（演进历史），来完整地理解这份规范是如何从概念落地为代码，并随着技术需求不断演进的。

引言：从理论到现实，规范的生命之旅

在过去的九篇文章中，我们仿佛与网络优化工程师老王和5G用户小慧并肩作战，深入了QoE测量的每一个角落。我们理解了它的使命（Scope），学习了它的语言（Definitions），掌握了它在3G/4G/5G战场上的不同战术（Activation Flows），并解码了构成每一次行动的“基因序列”（Parameters）。

现在，是时候揭开幕后的最后两层神秘面纱了。**附录（Annex）**在3GPP规范中扮演着特殊的角色。它们不包含强制性的要求（normative），而是提供参考性的信息（informative），是连接理论与现实的桥梁。

  • 附录A，就像是建筑师完成设计后，提供给施工队的**“效果图源码”**。它用一种名为PlantUML的代码，精确地描绘了我们在第四章看到的那些复杂信令流程图。对于工程师而言，这是将抽象流程转化为具体代码实现的最佳参考。
  • 附录B，则像是一本厚重的**“项目建设日志”**。它记录了这份规范从诞生之初到今天，每一次微小或重大的修订。通过它，我们可以看到技术是如何演进的，新的需求是如何被吸收的，标准是如何在持续的讨论和妥协中变得愈加完善的。

今天，就让我们扮演一次“代码审查师”和“技术考古学家”，完成对TS 28.405的终极探索。

1. 附录A (informative): Plant UML 源码 - 将信令流程化为代码

附录A提供了规范第四章中几个关键5G NR场景的PlantUML源码。PlantUML是一种简单直观的文本标记语言，可以通过编写代码来生成UML图（特别是序列图）。这对于需要精确、无歧义地定义交互流程的通信协议规范来说，是绝佳的工具。

1.1 A.1 NR中UE注册后的QMC激活与上报

The following PlantUML source code is used to describe QMC activation and reporting example in NR after UE is registered. As depicted by Figure 4.6.1.1-1:

这段描述指向了我们在第八篇文章中深入探讨的“热部署”场景——老王需要对已经在网的小慧进行实时QoE监控。附录A.1就是生成Figure 4.6.1.1-1这张图的源码。

让我们摘取几段关键代码，看看它是如何工作的：

participant "MCE" #white
participant "MnS Consumer" #white
...
"MnS Consumer" -> "UDM" :1. Create MOI QMCJob\n- serviceType\n- sliceScope\n...
"UDM" -> "AMF" :2. Nudm_SDM Data Change Notificationn\n- serviceType\n...
  • 代码解读:
    • participant "MCE" #white: 这行代码定义了一个名为“MCE”的参与者（即信令图中的垂直生命线）。
    • "MnS Consumer" -> "UDM" : ...: 这定义了一条从“MnS Consumer”（老王的网管平台）发往“UDM”的消息。->代表了消息的方向。冒号后面的文本，就是我们在图中看到的消息名称和参数列表，\n用于换行。
    • 与理论的呼应: 这两行代码，完美地对应了我们学到的5G信令驱动激活的第一步：老王通过MnS服务化接口在UDM中创建QMCJob对象，UDM随即通过Nudm_SDM_DataChange_Notification服务，主动将变更通知给AMF。代码将抽象的流程，固化为了精确的、可执行的描述。

1.2 A.2 NR中UE注册前的QMC激活与上报

The following PlantUML source code is used to describe QMC activation and reporting example in NR before UE Registration procedure to the network. As depicted by Figure 4.6.1.2-1:

这里对应的是“冷部署”场景——老王提前为小慧配置好任务，等待她第二天开机时自动激活。

...
"UE Access Stratum" -> "gNB" : Registration Request
"gNB" -> "AMF": Registration Request
"AMF" -> "UDM": Nudm_UEContextManagement_Register
|||
"UDM" -> "AMF" :API: Nudm_SDM\n- serviceType\n...
"AMF" -> "gNB" : Initial Context Setup Request\n- serviceType\n...
  • 代码解读:
    • |||: 这个符号在PlantUML中通常用来增加垂直空间，以区隔不同的处理阶段。
    • 与理论的呼ओं应: 这段代码清晰地展示了“拉取”模式。UE发起注册后，AMF向UDM去注册和获取上下文（Nudm_UEContextManagement_Register）。UDM在回复中，通过Nudm_SDM服务将预设的QoE配置返回给AMF。AMF再通过Initial Context Setup Request将这个配置“注入”到gNB中。每一个箭头，都精准地对应着我们在理论学习中分析过的一个信令步骤。

1.3 A.3 NR中基于NG接口切换的QMC处理

The following PlantUML source code is used to describe the procedure for SNPN provisioning with 3GPP segments only, as depicted by Figure 4.6.2.1-1

这里对应的是我们在第九篇中分析的高铁切换场景。

...
"Source gNB" -> "AMF":1. Handover Required\nsourceToTargetTransparentContainer\n- qoEReference\n...
"AMF" -> "Target gNB":2. Handover Request\nsourceToTargetTransparentContainer
rnote over "Target gNB" #white
3. Target gNB checks if
measurements to be
continued or not
end note
  • 代码解读:
    • rnote over "Target gNB": 这会在“Target gNB”的生命线上方，创建一个备注框，用于解释其内部处理逻辑。
    • 与理论的呼应: 代码生动地展示了“透明容器”的传递过程。源gNB将QoE上下文打包，通过Handover Required发给AMF。AMF不解析，原封不动地通过Handover Request转发给目标gNB。目标gNB收到后，进行内部检查决策（rnote中的内容）。代码的逻辑与我们分析的切换流程完全吻合。

对于工程师而言，附录A的价值在于，它提供了一个可验证、无歧义的“参考实现”，大大降低了不同厂商设备在进行信令交互设计时的理解偏差。

2. 附录B (informative): 变更历史 - 一部活生生的技术演进史

附录B以一个表格的形式，记录了TS 28.405自诞生以来的每一次修订。这个表格就像是标准的“DNA测序报告”，揭示了它是如何一步步“进化”成今天这个样子的。

在解读这个表格之前，我们先了解几个关键列的含义：

  • TDoc: 技术文档编号，3GPP会议上每一份提案都有一个唯一编号。
  • CR (Change Request): 变更请求。是修改3GPP规范的唯一合法途径。
  • Cat (Category): CR的类别。F代表功能性修正或增强；B代表对模糊描述的澄清或修正；A代表与其它规范的对齐等。F类通常意味着引入了重要的新功能。
  • Subject/Comment: 对本次CR内容的简要描述。

现在，让我们像“技术考古学家”一样，从这张表中挖掘几个关键的“历史切片”：

DateMeetingCRCatSubject/CommentNew version
2022-03SA#95e0005BAdding Management Based Activation and Temporary stop and restart during RAN overload in NR17.1.0
2022-09SA#97e0014BAdding Signalling Based Activation for NR18.0.0
2022-09SA#97e0015BHandling of QoE measurement collection at handover in NR18.0.0
2022-12SA#98e0019BAdd MDT alignment Information and RAN visible QoE Metrics to Handling QMC at Handover18.1.0
2022-12SA#98e0021BDefinition of parameters MDT Alignment Information and Available RAN Visible QoE Metrics18.1.0
2024-03SA#1030028FRel-18 CR TS28.405 Missing QoE Deactivation in NR18.6.0

  • 历史切片1 (2022-03, CR 0005): 这是5G NR中“管理驱动激活”和“RAN过载暂停上报”功能正式被写入规范的时刻。这次修订，标志着5G QoE测量在管理模式上完成了从4G的继承，并首次引入了应对网络拥塞的智能“熔断”机制。老王的工具箱里，增添了应对突发流量的利器。

  • 历史切片2 (2022-09, CR 0014 & 0015): 这是Release 18的开端，也是5G QoE测量能力的一次巨大飞跃。CR 0014正式引入了我们详细分析过的NR信令驱动激活，CR 0015则定义了其在切换中的处理流程。从此，老王才拥有了在5G网络下对小慧进行“实时订阅”式精准监控的能力。

  • 历史切片3 (2022-12, CR 0019 & 0021): 这两次连续的修订，为5G QoE测量引入了两大“杀手级”增强参数：MDT对齐信息和RAN可见QoE指标。这标志着QoE测量不再局限于应用层的“黑盒”数据，而是开始与无线层的物理环境数据进行深度关联，为智能根因分析打开了大门。老王的分析能力，从“知道体验差”进化到了“知道为什么体验差”。

  • 历史切片4 (2024-03, CR 0028): 这是一次F类的功能性修订，补齐了NR中QoE去激活的相关流程。这看似是一个小小的查漏补缺，但它体现了3GPP标准制定过程的严谨性——随着功能的日益复杂，标准也在不断地自我审视和完善，确保每一个流程都有始有终，每一个环节都清晰无误。

通过解读附录B，我们不再将规范视为一本静态的、冰冷的文档，而是理解到它是一个由全球上百家公司的工程师们，通过一次次的会议、一份份的提案、一轮轮的讨论，共同构建和维护的、充满活力的“生命体”。

系列终章：总结与展望

从第一章的Scope到附录B的Change History，我们完成了对3GPP TS 28.405的系统性深度解读。我们看到，这份规范的核心使命，始终是搭建一座桥梁，连接网络深处冰冷的QoS指标与用户终端上温暖的QoE感受。

  • 它定义了一套跨越三代移动通信网络的通用机制，无论是管理驱动的“广撒网”，还是信令驱动的“精确制导”，都为运营商提供了灵活的运维工具。
  • 它巧妙地设计了分层解耦的架构，让管理层、无线层、核心网与应用层各司其职，通过标准化的接口（RRC信令、NGAP/S1AP、AT指令）精密协作。
  • 它在5G时代，全面拥抱服务化（SBA）和面向对象的管理哲学，引入了切片感知、MDT对齐、过载保护等一系列前瞻性功能，为即将到来的万物互联和元宇宙时代，奠定了坚实的体验度量基石。

对于像老王一样的网络工程师，TS 28.405是他们从“保障连接”走向“保障体验”的“圣经”。对于像小慧一样的亿万用户，这份规范虽然看不见、摸不着，但每一次流畅的视频、每一次沉浸的VR、每一次清晰的通话背后，都可能有它在默默守护。

技术的演进永无止境。随着5G-Advanced和6G的到来，更多对体验要求极致苛刻的业务将会涌现。我们可以预见，未来的TS 28.405，必将在附录B中续写新的篇章：也许是引入基于AI的意图驱动QoE测量，也许是为全息通信定义全新的度量维度，也许是实现从“测量-分析”到“感知-预测-自愈”的智能内生闭环。

而我们，作为通信行业的学习者和建设者，理解并掌握好今天这份规范的精髓，就是迈向那个智能未来的最好一步。

FAQ环节

Q1：附录A中的PlantUML代码，我可以自己用来生成序列图吗？ A1：完全可以。PlantUML是一个开源工具，有在线的渲染器，也有很多本地编辑器（如VS Code）的插件。你可以将附录A中的代码复制出来，粘贴到支持PlantUML的工具中，就能1:1地还原出规范中的序列图。这对于学习和理解信令流程，或者在你自己的技术文档中绘制标准流程图，都非常有用。

Q2：附录B的变更历史对于一个普通的网络工程师有什么实际意义？ A2：意义重大。首先，它可以帮助你快速了解不同网络设备版本所支持的功能。比如，你知道了NR信令驱动激活是在Rel-18中引入的，那么当你在处理一个Rel-17的网络问题时，就不会去缘木求鱼地寻找这个功能。其次，通过阅读CR的“Subject/Comment”，你可以快速抓住一个新版本功能的核心，是解决问题（Bug Fix），还是引入新特性（New Feature），这对于学习和网络升级规划非常有帮助。

Q3：为什么规范中要明确区分“normative”（规范性）和“informative”（参考性）？ A3：这是为了保证标准的严格性和互操作性。“Normative”部分包含了所有设备实现必须遵守的强制性要求、流程和参数定义，这是保证不同厂商设备能够互联互通的基础。“Informative”部分则不包含任何强制要求，它提供的是帮助理解和实现的背景信息、示例、解释等。附录A和B都是informative，意味着厂商在实现时可以参考，但不必严格按照示例代码去写，只要最终的信令交互行为符合第四章的规范性要求即可。

Q4：整个TS 28.405规范系列看下来，它的核心设计哲学是什么？ A4：可以总结为三点：1）分层解耦：严格划分管理层、控制层、应用层的职责，通过标准化接口通信，使得各层可以独立演进。2）通用与特化并存：定义了一套通用的激活、切换、去激活流程框架，同时又为不同无线技术（UTRAN/LTE/NR）和业务类型（DASH/VR）保留了特化的参数和实现细节。3）向后兼容与前瞻设计：规范的演进始终考虑对旧版本的兼容，同时在5G NR的设计中，大量引入了服务化、API化、切片感知等面向未来的设计，保证了其长久的生命力。

Q5：学习完TS 28.405之后，如果我想进一步深入研究QoE，下一步应该看哪些规范？ A5：一个很好的路径是“向上”和“向下”延伸。

  • 向上（应用层）：深入阅读TS 26系列规范，特别是TS 26.247 (DASH), TS 26.114 (MTSI), 和 TS 26.118 (VR)。这些规范定义了“QMC configuration file”里的具体内容，即到底要测量哪些指标以及如何测量。
  • 向下（无线/核心网层）：对照TS 28.405中提到的信令，去查阅对应的协议规范，如TS 38.331 (NR RRC), TS 38.413 (NGAP), **TS 29.502 (UDM服务)**等。这会让你对QoE指令是如何被打包和传输的有更底层的认识。

关系图谱