好的，我们继续跟随5G基-站工程师小雷，探索NG接口上那些为应对物联网时代海量、多样化连接而生的精巧功能。这一次，我们将聚焦于那些“沉默的大多数”——低功耗、小数据包的NB-IoT设备。

深度解析 3GPP TS 38.410：5.22, 5.23 & 5.25 NB-IoT终端的“轻量化”接入

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“5.22 Retrieve UE Information function”、“5.23 RAN CP Relocation Indication function”和“5.25 Connection Establishment Indication Function”的核心章节，并结合其在5G核心网架构（TS 23.501）中的“Control Plane CIoT 5GS Optimisation”特性，为读者完整呈现NB-IoT设备接入5GC的“轻量化”信令流程。

引言：为“物联网小精灵”开辟的“绿色通道”

我们的主角，基站工程师小雷，在他的gNB覆盖范围内，除了要服务高速上网的手机用户，还要应对成千上万个“物联网小精灵”——例如，部署在城市各个角落的智能水表、共享单车锁、环境传感器等。这些设备，就是**NB-IoT（窄带物联网）**终端。

这些“小精灵”与手机用户有着截然不同的通信行为：

• 极少活动: 可能一天、甚至一周才上报一次数据。

• 数据极小: 每次只上报几十个字节（比如水表读数）。

• 对时延不敏感: 数据晚几秒甚至几分钟送达，通常没什么影响。

• 功耗极度敏感: 一节电池需要工作好几年。

如果让这些“小精灵”也走一遍手机用户那套复杂的、包含建立用户面隧道（NG-U）的“重型”接入流程，那无异于“杀鸡用牛刀”。不仅浪费了大量的信令资源和网络处理能力，更重要的是，频繁的信令交互会迅速耗尽它们的电池。

为此，5G核心网引入了一项名为“控制面CIoT 5GS优化（Control Plane CIoT 5GS Optimisation）”的革命性技术。它的核心思想是：让这些小数据包，直接“搭乘”控制面的信令“便车”送到核心网，而根本不去建立昂贵的用户面“专车”通道。

我们今天要解读的5.22、5.23和5.25这三个功能，正是NG接口为了支撑这一“轻量化”接入方案，而引入的三个关键“专用工具”。

---

1. “搭便车”前的“安检”：Retrieve UE Information 功能 (5.22)

5.22 Retrieve UE Information function

The Retrieve UE Information function enables the NG-RAN node to request UE information (e.g. QoS differentiation information) from the AMF before the setup of the NG connection for NB-IoT UE(s) using Control Plane CIoT 5GS Optimisation.

深度解读与场景演绎：

• 核心使命: 在为NB-IoT设备建立一个完整的NG连接（即包含AMF和gNB两侧的UE上下文）之前，允许gNB提前向AMF“打听”一下这个UE的关键信息。

• 为什么需要“提前打听”？

  • 在标准的流程中，gNB是在INITIAL CONTEXT SETUP REQUEST消息中，才从AMF那里获得UE的详细上下文的。但为了发送这条消息，gNB需要先将UE的初始接入消息（INITIAL UE MESSAGE）送给AMF。

  • 对于NB-IoT的控制面优化方案，我们希望尽可能地减少信令交互。如果能在第一条消息（INITIAL UE MESSAGE）中，就包含一些需要QoS保障的用户数据，那么效率将大大提升。

  • 但要为数据提供QoS保障，gNB就必须提前知道这个UE的QoS配置。这就形成了一个“鸡生蛋还是蛋生鸡”的矛盾。

场景演绎：智能水表的“身份预审”

1. 一个沉睡已久的智能水表（NB-IoT UE）苏醒，它有一个10字节的水表读数需要上报。

2. 它向小雷的gNB发起RRC连接建立，并在RRC Setup Complete消息中，携带了它的NAS初始消息，以及一个明确的指示：“我希望使用控制面优化方案”。

3. 小雷的gNB收到了这个请求。它看到了那个“想搭便车”的指示，但它对这个水表一无所知，不知道应该给它什么等级的服务。

4. 此时，Retrieve UE Information功能启动！gNB向AMF发送一个RETRIEVE UE INFORMATION请求（这是NGAP协议中新增的流程），请求中包含了这个水表的临时身份标识。这相当于gNB在问AMF：“嘿，这个水表是什么来头？它有什么VIP待遇吗？”

5. AMF收到请求后，查询UDM，找到了这个水表的“档案”，比如它的签约QoS是“高优先级”。

6. AMF通过RETRIEVE UE INFORMATION RESPONSE消息，将这份“QoS differentiation information”返回给gNB。

7. 现在，gNB对这个水表的“身份”了然于胸。它可以满怀信心地、带着正确的QoS保障，将水表的NAS消息和那10字节的数据，一同打包在INITIAL UE MESSAGE中，发往AMF。

这个“预审”流程，通过一次额外的查询，打破了“鸡生蛋”的困局，使得在初始接入的第一步，就能实现带QoS保障的数据传输。

---

2. “失联”后的“快速重逢”：RAN CP Relocation Indication 功能 (5.23)

NB-IoT设备为了省电，会长时间处于深度睡眠状态。当它再次醒来时，很可能已经因为无线信号变化，“漂移”到了一个新的基站覆盖下。此时，它需要一个快速恢复连接的机制。

5.23 RAN CP Relocation Indication function

The RAN CP Relocation Indication function enables the initiation of the UE-associated logical NG-connection for a NB-IoT UE using Control Plane CIoT 5GS Optimisation following a re-establishment request. It allows to have the re-establishment request authenticated by the AMF.

深度解读与场景演绎：

• 核心使命: 当一个之前已经注册过、但现在“失联”的NB-IoT UE，在一个新的gNB上发起RRC重建立（RRC Re-establishment）时，允许这个新的gNB能够高效地为其重建NG连接，并确保这个过程是安全的（经过AMF的认证）。

• 与手机用户的区别: 手机用户在移动时，通常会通过“切换（Handover）”来保持连接。但NB-IoT设备因为长时间睡眠，无法进行切换，它恢复连接的方式更像是“从休眠中恢复”。

场景演绎：共享单车的“漂移”

1. 一辆共享单车（NB-IoT UE）在北京海淀区的gNB-A下完成了注册，然后上锁，进入了深度睡眠。它的上下文被保留在AMF和gNB-A中。

2. 这辆单车被用户骑到了西城区，停在了一个由gNB-B覆盖的地方。

3. 当用户再次扫码开锁时，单车被唤醒。它发现无线环境变了，无法在原来的小区上恢复连接，于是它向新的gNB-B发起了一个RRC Re-establishment Request。

4. 小雷的新基站gNB-B收到了这个请求。它从请求中解析出UE之前的身份标识，但发现自己本地并没有这个UE的上下文（上下文还在gNB-A那里）。

5. 此时，RAN CP Relocation Indication功能启动！gNB-B向AMF发送一个RAN CP RELOCATION INDICATION消息。这条消息相当于在向AMF报告：“报告！我这里发现一个‘失散’的NB-IoT设备，它之前好像是你的兵，请指示如何处理！”

6. AMF收到了这个“报告”。它首先会对这个请求进行安全认证，确认这确实是之前那个合法的单车，而不是一个伪造的设备。

7. 认证通过后，AMF会执行一次UE上下文的“搬家”。它会向旧的gNB-A发送指令，释放那里的旧上下文。然后，它会向新的gNB-B发起标准的INITIAL CONTEXT SETUP流程，将单车的完整上下文，在新基站上建立起来。

8. 最终，单车在新的gNB-B上成功恢复了连接，并可以继续通过控制面优化方案上报它的开锁状态。

这个流程，为“漂移”的NB-IoT设备，提供了一条安全、高效的“回家之路”。

---

3. “临门一脚”的确认：Connection Establishment Indication 功能 (5.25)

在上述两个流程中，gNB与AMF之间进行了一些“非标准”的、轻量化的交互。但在某些情况下，AMF仍然需要一个明确的信号，来确认UE的NG逻辑连接最终已经“尘埃落定”。

5.25 Connection Establishment Indication Function

The connection establishment indication function enables the AMF to complete the establishment of the UE-associated logical NG-connection.

深度解读：

• 核心使命: 在一些特定的CIoT优化流程之后，由gNB向AMF发送一个“确认信号”，告知AMF：“这个UE的接入流程，在我这边已经全部完成了，你可以放心地认为它的NG连接已经建立成功了。”

• 为什么需要这个“确认”？ 在某些极其精简的优化流程中，AMF可能只是向gNB下发了一个最小化的指令，然后就等待gNB的后续操作。这个CONNECTION ESTABLISHMENT INDICATION消息，就如同gNB完成任务后的一个“回执”，它为AMF提供了一个明确的流程结束的触发点，AMF可以据此更新UE的状态、启动计费等后续操作。

这个功能，如同整个“轻量化”接入流程的“句号”，为这些特殊的、被优化的信令交互，提供了一个清晰的、无歧义的完成标志。

---

总结：为万物互联“减负”，于细微处见真章

通过对5.22、5.23和5.25这三个看似不起眼的功能的联合解读，我们得以一窥5G网络为拥抱海量物联网连接，所进行的深刻而精巧的底层优化。

• Retrieve UE Information，通过“信息前置”，打破了QoS保障与信令简化之间的矛盾，实现了“鱼与熊掌兼得”。

• RAN CP Relocation Indication，通过“失联找回”，为长周期睡眠、频繁移动的物联网终端，设计了一条安全、高效的连接恢复路径。

• Connection Establishment Indication，通过“最终确认”，为这些特殊的优化流程，提供了一个清晰的闭环，保证了网络状态的最终一致性。

这些功能，共同服务于“Control Plane CIoT 5GS Optimisation”这一宏大目标。它们的核心哲学，就是“减负”——减少不必要的信令交互、避免建立昂贵的用户面隧道、最大化终端的电池寿命。

对于基站工程师小雷来说，掌握了这些“专用工具”，他就能游刃有余地应对他网络中那些数量庞大但行为独特的“物联网小精灵”了。他知道，5G网络不仅能为高速的手机提供“阳关道”，也为这些沉默的“小精灵”们，开辟了一条专属的、轻快的“绿色通道”。这正是5G“万物互联”愿景在底层协议设计上的真实写照。