本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“9.3 Information Element Definitions”的核心章节，旨在为读者提供一个关于构成5G NGAP信令消息的“原子”——信息元素（IE）的深度解读。本文为系列解读的第二部分（下），将重点剖析与NAS层、SMF层交互以及移动性相关的核心IE。

深度解析 3GPP TS 38.413：9.3 Information Element Definitions (下) - 解构5G信令的“乐高积木”

大家好，欢迎回到3GPP规范的深度解析系列！在上篇文章中，我们化身材料学家，跟随通信“萌新”小明和他新手机“Phone X”的首次开机过程，解构了NGAP信令中最基础的“乐高积木”——与无线网络层和传输网络层相关的核心信息元素（IEs）。我们理解了网络如何通过Cause、Global RAN Node ID、QoS Parameters和GTP-TEID等IE，来定义“原因”、“身份”、“服务质量”和“数据隧道”。

今天，我们将继续这场深入到比特层面的探索之旅。随着小明开始真正在5G网络中漫游和使用业务，网络需要处理更复杂的身份管理、移动性决策和会话管理信令。我们将聚焦于9.3节中更为高级和抽象的IE类别，揭示它们是如何支撑起这些复杂流程的：

1. 9.3.3 NAS相关IEs (NAS Related IEs)：我们将深入探讨UE在网络中的“护照系统”。从临时的、用于保护隐私的5G-S-TMSI，到标志着特定AMF管辖权的GUAMI，再到承载着所有核心网“密语”的NAS-PDU本身，我们将理解网络是如何在效率和安全之间进行精妙的平衡。

2. 9.3.4 SMF相关IEs (SMF Related IEs)：这一节是理解5G核心网架构分离（AMF负责连接与移动性，SMF负责会话）的关键。我们将看到，几乎所有与PDU会话生命周期相关的复杂操作，都被封装在一个个对AMF“透明”的容器中进行传递。AMF就像一个高效的“联邦快递员”，只负责将这些“机密文件”在gNB和正确的SMF之间准确投递，而无需（也不能）拆阅其内容。

我们将继续跟随小明和他心爱的“Phone X”：

• 场景: 小明正拿着手机在城市中移动，从家里的gNB-Community覆盖区域，移动到了公司附近的gNB-Business覆盖区域，期间触发了一次切换。同时，他发起了一个新的视频通话PDU会话。

通过这个动态的场景，你将看到：

• AMF UE NGAP ID和RAN UE NGAP ID如何像一对“钥匙”，在gNB和AMF之间锁定一个UE的信令连接。
• 5G-S-TMSI如何像一个“动态签证”，在保护小明隐私的同时，帮助网络快速找到他。
• PDU Session Resource Setup Request Transfer这个“透明文件袋”里，究竟装了哪些SMF想要告诉gNB的“悄悄话”。
• 在切换过程中，Path Switch Request Transfer这个“改道通知单”是如何被gNB填写，并由AMF呈报给SMF，以实现用户数据流的无缝切换。

准备好继续我们的微观之旅，彻底掌握5G信令的构建逻辑吧！

---

1. 9.3.3 NAS Related IEs - UE的“护照与签证”系统

这一类IE处理的是UE在核心网层面的身份标识。它们是AMF进行移动性管理和安全管理的基石。

1.1 连接的“双向锁”：AMF UE NGAP ID & RAN UE NGAP ID

一旦UE与AMF之间建立了UE关联的信令连接，就需要一个机制来唯一标识这个点对点的连接。NGAP为此设计了一对ID，像一把双向的锁。

9.3.3.1 AMF UE NGAP ID This IE uniquely identifies the UE association over the NG interface, as described in TS 38.401.

9.3.3.2 RAN UE NGAP ID This IE uniquely identifies the UE association over the NG interface within the NG-RAN node.

• AMF UE NGAP ID: 由AMF分配，在整个AMF范围内唯一。它代表了AMF侧对这个连接的“档案编号”。
• RAN UE NGAP ID: 由gNB分配，在单个gNB范围内唯一。它代表了gNB侧对这个连接的“本地索引”。

场景演绎：

1. 小明的Phone X首次接入，gNB-Community在发送INITIAL UE MESSAGE时，会分配一个RAN UE NGAP ID，例如1001。
2. AMF-CityCore收到后，会为这个连接分配一个AMF UE NGAP ID，例如AABBCCDD。
3. 在后续所有的信令交互中（如DOWNLINK NAS TRANSPORT），AMF和gNB都会同时携带这两个ID。AMF-CityCore发送消息时，它通过RAN UE NGAP ID=1001来告诉gNB这条消息是给哪个连接的；gNB-Community回复消息时，它通过AMF UE NGAP ID=AABBCCDD来告诉AMF这是对哪个连接的响应。

深度解析： 这对ID共同锁定了一个UE关联的逻辑NG连接。这种双向标识的设计，使得gNB和AMF都可以高效地通过一个整数索引，快速定位到UE的上下文，而无需每次都进行复杂的查找。当小明的手机切换到gNB-Business后，新的gNB会分配一个新的RAN UE NGAP ID，而AMF UE NGAP ID则保持不变，从而在AMF侧维持了上下文的连续性。

1.2 隐私的“面具”与AMF的“门牌号”：5G-S-TMSI & GUAMI

为了不在空口中暴露用户的永久身份（SUPI），网络会为UE分配一个临时的身份标识——5G-S-TMSI。

9.3.3.20 5G-S-TMSI This IE is used for security reasons, to hide the identity of a subscriber.

5G-S-TMSI本身是一个结构体，由三部分组成：

• AMF Set ID: 标识AMF所属的集合。
• AMF Pointer: 在AMF Set中指向一个特定的AMF。
• 5G-TMSI: 在该AMF内唯一标识一个UE的临时ID。

前两部分组合起来，就构成了**GUAMI (Globally Unique AMF Identifier)**，即AMF的全局唯一标识。

9.3.3.3 GUAMI This IE indicates the AMF identity.

场景演绎：

• 寻呼: 当小明的手机处于RRC_IDLE状态时，AMF需要寻呼他。AMF会在PAGING消息中包含完整的5G-S-TMSI。gNB在空口广播这个ID。
• 初始接入: 小明的手机从IDLE状态发起接入时，它会在INITIAL UE MESSAGE中上报自己持有的5G-S-TMSI。gNB看到这个IE后，会解析出其中的GUAMI部分，并根据GUAMI中的信息，将这条消息路由到正确的AMF（AMF-CityCore）。

深度解析： GUAMI + 5G-S-TMSI的组合，是5G移动性管理和路由选择的核心。GUAMI确保了UE在任何一个gNB接入时，都能被正确地导向其“注册”的AMF；而5G-S-TMSI则在整个过程中充当了UE的“临时马甲”，保护了其隐私安全。

1.3 终极“信封”：NAS-PDU

我们已经多次提到这个IE，但在这里有必要再次强调它的核心地位。

9.3.3.4 NAS-PDU This IE contains a 5GC – UE or UE – 5GC message that is transferred without interpretation in the NG-RAN node.

深度解析： NAS-PDU是接入层与非接入层分离原则的终极体现。所有关于认证、安全模式协商、注册、PDU会话管理等核心网逻辑的信令，都被封装在这个“黑盒子”里，由gNB进行透明传输。对于gNB来说，它只关心承载这个NAS-PDU的NGAP消息（如INITIAL UE MESSAGE）的头部信息，以完成正确的路由和关联，而NAS-PDU本身的内容，对它而言既不可见也无意义。

---

2. 9.3.4 SMF Related IEs - AMF的“透明转发服务”

这一节的所有IE都有一个共同的特点：它们都是OCTET STRING（字节串）类型的透明容器。AMF是这些消息的“二传手”，而不是“读者”。

2.1 会话建立的“申请材料”：PDU Session Resource Setup Request Transfer

当AMF需要为UE建立一个PDU会话时，它会向gNB发送INITIAL CONTEXT SETUP REQUEST或PDU SESSION RESOURCE SETUP REQUEST。这些消息中包含了PDU Session Resource Setup Request Transfer IE。

9.3.4.1 PDU Session Resource Setup Request Transfer This IE is transparent to the AMF.

场景演绎： 小明想发起一个视频通话，他的手机向AMF发送了PDU Session Establishment Request（这是一个NAS消息）。AMF收到后，选择了一个SMF来处理这个请求。SMF完成核心网侧的资源准备后，需要通知gNB在空口上建立相应的无线承载。

SMF会将所有需要gNB知道的信息，打包成一个PDU Session Resource Setup Request Transfer PDU，然后通过N11接口发回给AMF。AMF再将这个PDU原封不动地放入NGAP消息中，发给gNB。

这个“透明文件袋”里装了什么？

• PDU Session Aggregate Maximum Bit Rate: 该PDU会话的总带宽限制。
• UL NG-U UP TNL Information: UPF为该会话准备好的上行GTP隧道信息。
• QoS Flow Setup Request List: 该会话包含的所有QoS流的详细“质量合同”（即我们在上篇文章中剖析的QoS Flow Level QoS Parameters）。
• Security Indication: 是否需要对该会话的用户面数据进行加密和完整性保护。

gNB收到并解析这个透明容器后，就得到了建立空口资源所需的所有详细参数。

2.2 切换时的“改道通知单”：Path Switch Request Transfer

当UE发生切换，用户面路径需要从源gNB切换到目标gNB时，目标gNB需要通知SMF更新下行路径。

9.3.4.8 Path Switch Request Transfer This IE is transparent to the AMF.

场景演绎： 小明从gNB-Community走到了gNB-Business的覆盖范围，触发了切换。当他的手机成功接入gNB-Business后，gNB-Business需要请求UPF将数据流改道至自己这里。

gNB-Business会构造一个Path Switch Request Transfer PDU，封装在PATH SWITCH REQUEST消息中，通过AMF发往SMF。

这份“改道通知单”里装了什么？

• DL NG-U UP TNL Information: 目标gNB为该会话的下行数据流分配的新的GTP隧道端点信息。
• User Plane Security Information: 目标gNB侧的安全策略执行结果。
• QoS Flow Accepted List: 目标gNB确认可以承载的QoS流列表。

SMF收到后，立即通知UPF更新下行隧道的目的地，数据流就成功切换到了新的gNB。

深度解析： SMF相关的IEs充分体现了5G核心网CP（控制面）分离和**CUPS（控制与用户面分离）**的设计哲学。AMF作为移动性管理的“大脑”，不应被具体的会话策略（如QoS、计费）所拖累。通过将这些信息封装在透明容器中，实现了AMF与SMF之间的清晰职责划分。AMF只负责“谁、在哪里、要去哪”的移动性问题，而SMF则专注于“什么业务、需要什么质量、数据怎么走”的会话问题。

---

FAQ

Q1: AMF UE NGAP ID的长度是40位，而RAN UE NGAP ID是32位，为什么会有这种差异？

A1: 这种长度差异反映了它们作用范围的不同。AMF UE NGAP ID需要在整个AMF范围内唯一，而一个AMF可能管理着成千上万个gNB，总的UE关联数可能非常庞大，因此需要一个更大的地址空间（2^40）。而RAN UE NGAP ID只需要在单个gNB内唯一，一个gNB同时服务的UE数量相对有限，32位（超过40亿）的地址空间绰绰有余。这种设计是在保证唯一性的前提下，对信令开销的一种优化。

Q2: 如果UE没有有效的5G-S-TMSI（例如，第一次开机），它在INITIAL UE MESSAGE中如何标识自己？

A2: 如果UE没有有效的5G-S-TMSI，它会在NAS层的Registration Request消息中使用其永久身份标识SUPI（通常是IMSI加密后的SUCI）。gNB在收到这个RRC消息后，无法从中解析出GUAMI来选择AMF。在这种情况下，gNB会根据其本地配置的默认路由策略，选择一个AMF来发送INITIAL UE MESSAGE。这个AMF收到后，如果发现自己不是这个UE应该归属的AMF，它会负责将这个请求重定向到正确的AMF。

Q3: 既然AMF不解析SMF相关的透明容器，那么如果容器里的内容有错误，谁来负责？

A3: 最终的“消费者”——SMF或gNB来负责。

• 下行场景: SMF生成容器，gNB消费。如果SMF在PDU Session Resource Setup Request Transfer中填入了一个gNB不支持的QoS参数，gNB在解析时会发现错误。gNB会在PDU SESSION RESOURCE SETUP RESPONSE的透明容器PDU Session Resource Setup Response Transfer中，向SMF报告这个QoS流建立失败，并附上原因。AMF在此过程中仍然只是一个“信使”。
• 上行场景: gNB生成容器，SMF消费。如果gNB在Path Switch Request Transfer中填入了一个无效的隧道地址，SMF在处理时会发现错误，并通过AMF向gNB返回一个包含失败原因的响应。

Q4: 为什么切换时，不直接由AMF告诉目标gNB所有PDU会话的信息，而要依赖源gNB在透明容器里提供？

A4: 因为只有源gNB掌握着UE当前最实时、最完整的AS层上下文。这包括：

• RRC配置: 只有源gNB知道它当前为UE配置了哪些测量、DRX参数等。
• PDCP/RLC状态: 只有源gNB知道数据包的收发序列号。
• UE能力: 虽然AMF也存有UE能力，但RAN侧可能会基于实际交互情况，对UE能力有更精确的掌握（例如，知道UE在特定频段组合下的真实能力）。 让源gNB将这些信息“打包”直接传递给目标gNB，是最高效的方式。如果让AMF来提供，AMF首先需要向源gNB查询这些实时信息，这会增加不必要的信令交互和时延，违背了切换过程对速度的极致要求。

Q5: 学习ASN.1定义对日常的网络优化和故障处理有帮助吗？

A5: 非常有帮助。虽然日常工作中我们更多地是使用信令分析软件（如Wireshark）来查看解码后的消息，但理解ASN.1定义能让你：

1. 深入理解信令结构: 当遇到软件无法正确解码的私有IE或新版本IE时，你能通过阅读ASN.1源码来理解其结构。
2. 精确定位问题: 当信令交互失败时，你可以对照ASN.1定义，检查发送方是否严格遵循了PRESENCE（例如，必填项是否缺失）、Range（数值是否越界）等语法规则。很多互操作性问题，根源就在于对ASN.1定义的细微理解偏差。
3. 理解协议设计思想: 阅读ASN.1是理解3GPP协议设计者“初心”的最佳途径。你会明白为什么某个IE被设计成OPTIONAL，为什么某个结构要用CHOICE，这些都蕴含着对协议健壮性、扩展性和效率的深思熟虑。