51学通信

深度解析 3GPP TS 38.410：5.24 Suspend-Resume function (挂起-恢复功能)

16分钟阅读

好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些为应对网络状态的动态变化、保障服务连续性而设计的关键功能。这一次，我们将聚焦于一个在5G时代被赋予了全新内涵和更广阔应用场景的功能——Suspend-Resume。

深度解析 3GPP TS 38.410：5.24 Suspend-Resume function (挂起-恢复功能)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“5.24 Suspend-Resume function”的核心章节，并结合其在核心网（TS 23.501/502）和NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中，UE如何通过“挂起-恢复”机制，在保持核心网连接不变的情况下，实现超低功耗的待机和秒级的业务恢复。

引言：从“关机重启”到“电脑休眠”，连接的智慧

我们的主角，基站工程师小雷，一直在思考一个问题：如何让用户在不使用数据业务时，既能最大程度地节省手机电量，又能在需要时，以最快的速度恢复上网体验？

传统的IDLE模式，就像是“关机”。UE与网络的连接被彻底切断，所有上下文都被删除。当需要恢复时，必须走一遍完整的“开机、登录”（服务请求）流程，虽然省电，但恢复速度较慢（通常需要几百毫-秒）。

5G引入的INACTIVE模式，则像“待机”。UE的上下文被保留在gNB和AMF中，恢复时只需一个简单的RRC信令交互，速度极快（几十毫-秒），但gNB需要一直为UE保留上下文，消耗了网络资源。

现在，5G为我们带来了第三种选择——Suspend-Resume（挂起-恢复），它就像是“电脑休眠”。

5.24 Suspend-Resume function

This function enables to suspend the UE-associated logical NG-connection and release the NG-U tunnel while storing the UE context in the NG-RAN for a faster subsequent resume…

深度解读“电脑休眠”的精髓：

  • 挂起 (Suspend): 当UE长时间不活动时，网络决定让它进入“休眠”。
    • “内存”存盘 (storing the UE context in the NG-RAN): gNB会将UE的关键上下文信息（如同电脑内存中的工作状态）“冻结”并保存起来。
    • “断开外设” (release the NG-U tunnel): 同时，gNB会通知核心网，拆除为该UE建立的NG-U用户面隧道，释放UPF和传输网络上的资源。
    • “屏幕熄灭”: UE也进入超低功耗的睡眠状态。
  • 恢复 (Resume): 当UE需要恢复业务时。
    • “快速唤醒”: UE向gNB发送一个简单的恢复请求。
    • “从硬盘恢复内存”: gNB从“硬盘”中快速调出之前“冻结”的UE上下文。
    • “重连外设”: gNB通知核心网，快速地重建NG-U隧道。
    • 业务瞬间恢复，就像唤醒一台休眠的笔记本电脑，所有的程序和窗口都还在原来的位置。

1. “挂起-恢复”的使命：功耗、资源与速度的“不可能三角”

Suspend-Resume功能的核心目标，是在UE功耗、网络资源占用和恢复时延这三个通常相互矛盾的目标之间，寻求一个最佳的平衡点。

  • 相比IDLE模式: 它的恢复速度快得多，因为UE的上下文（特别是安全上下文和RRC配置）被保留在了gNB，避免了与核心网进行复杂的NAS信令交互。
  • 相比INACTIVE模式: 它的网络资源占用更少。因为它释放了NG-U隧道，为UPF和传输网络“减负”。这对于那些需要支持海量连接、但每个连接并不总是有数据的物联网场景，尤其重要。

Suspend-Resume的主要应用场景

…In this version of the specification, this function only applies for long eDRX cycles. …as specified for User Plane CIoT 5GS optimizations in TS 23.501.

规范明确指出了当前版本中Suspend-Resume的两个关键应用场景：

  1. 用户面CIoT 5GS优化 (User Plane CIoT 5GS Optimisation): 这是它最核心的用武之地。对于那些使用用户面传输数据的物联网设备（相对于控制面优化），Suspend-Resume提供了一种完美的待机模式。设备可以长时间“休眠”（挂起），在需要上报数据时，通过“恢复”流程，快速重建用户面，完成数据传输，然后再返回“休眠”。
  2. 长eDRX周期 (long eDRX cycles): 对于配置了超长“睡眠”周期的终端（例如，几个小时甚至几天才醒来一次的传感器），使用Suspend-Resume可以在其漫长的睡眠期间，彻底释放掉网络侧的用户面资源，极大地提升了网络的可扩展性。

2. “休眠”与“唤醒”的信令之舞

Suspend-Resume功能的实现，在NG接口上是由UE CONTEXT SUSPEND和UE CONTEXT RESUME这两个NGAP流程来承载的。

场景设定： 一个部署在农田里的土壤湿度传感器（CIoT UE），它配置了每小时上报一次数据的任务。

2.1 进入“休眠”：UE CONTEXT SUSPEND 流程

  1. 触发: 传感器上报完一次数据后，在一段时间内没有新的数据传输。小雷的gNB的内部定时器超时，决定将这个UE挂起。

  2. gNB → AMF (UE CONTEXT SUSPEND REQUEST):

    • 挂起流程启动！ gNB向AMF发送一条UE CONTEXT SUSPEND REQUEST消息。
    • 核心内容: 这条消息相当于gNB在向AMF申请：“报告！这个传感器准备要长时间休眠了，我打算在本地‘冻结’它的上下文，并请求核心网侧拆除它的用户面管道，请批准！”

  3. AMF → SMF (Nsmf_PDUSession_UpdateSMContext):

    • AMF收到请求后，通知SMF：“你的用户要休眠了，请释放它的用户面资源。”

  4. SMF → UPF:

    • SMF指令UPF，释放为该UE分配的NG-U隧道资源。

  5. AMF → gNB (UE CONTEXT SUSPEND RESPONSE):

    • 核心网侧的用户面资源释放完成后，AMF向gNB回复UE CONTEXT SUSPEND RESPONSE，表示“批准休眠！”

  6. gNB“冻结”上下文:

    • gNB收到批准后，将UE的上下文（RRC配置、安全信息等）保存起来，并释放本地的RRC连接。UE进入深度睡眠。

2.2 “一键唤醒”：UE CONTEXT RESUME 流程

场景设定： 一小时后，传感器被唤醒，准备上报新的湿度数据。

  1. UE → gNB (RRCResumeRequest):

    • UE向gNB发送一个RRC Resume Request，其中包含了它在被挂起时，从gNB那里获取到的一个““凭证””（Resume ID）。

  2. gNB的“解冻”与“上报”:

    • 小雷的gNB收到了这个“凭证”。它在本地的“冻结区”中，找到了之前保存的该UE的上下文，并对其进行“解冻”。
    • 上下文恢复后，gNB需要立即为UE重建用户面管道。
    • 恢复流程启动！ gNB向AMF发送一条UE CONTEXT RESUME REQUEST消息。
    • 核心内容: 这条消息相当于在向AMF报告：“报告！休眠的传感器已经唤醒，我已在本地恢复其上下文，请核心网立即为它重建用户面管道！” 消息中会包含需要恢复的PDU会话列表等信息。

  3. AMF → SMF → UPF (管道重建):

    • AMF收到请求后，立即通知SMF。SMF会重新选择一个UPF（可能是原来的，也可能是一个新的、更近的），并为其分配新的NG-U隧道资源。

  4. AMF → gNB (UE CONTEXT RESUME RESPONSE):

    • 核心网的管道重建完成后，AMF向gNB回复UE CONTEXT RESUME RESPONSE。
    • 核心内容: 包含了新分配的UPF的隧道信息。

  5. gNB配置空口 & 业务恢复:

    • gNB收到新的隧道信息后，配置好空口的DRB，并将隧道信息通过RRC信令告知UE。
    • 用户面路径完全恢复！ 传感器可以立即开始上报它的湿度数据。

整个“唤醒”过程，由于避免了与AMF之间复杂的NAS认证和安全协商，其时延远低于从IDLE态恢复，实现了名副其实的“秒级恢复”。

总结：在功耗、资源与时延之间，寻找最优的“甜点”

通过对5.24节“挂起-恢复功能”的深度剖析，我们看到了5G为应对海量物联网连接，所设计的又一重架构智慧。它不再是IDLE（纯省电）和INACTIVE（纯快速）的“二选一”，而是提供了一种兼顾三者的“第三条道路”。

  • 极致的功耗优化: 通过彻底释放用户面隧道和进入深度睡眠，实现了与IDLE模式相媲美的终端功耗。
  • 高效的网络资源利用: 通过释放核心网和传输网上的用户面资源，极大地提升了网络的可扩展性，使得单个UPF能够支持更多数量的“休眠”连接。
  • 敏捷的业务恢复: 通过在gNB侧保留UE上下文，实现了远快于IDLE模式的业务恢复时延。

对于基站工程师小雷来说，Suspend-Resume功能，就像是他工具箱里的一个“智能电源管理器”。对于那些“三分钟热度”、大部分时间都在“摸鱼”的物联网终端，他可以利用这个工具，让它们在不“断气”（丢失核心网连接）的前提下，进入最深度的“休眠”，既为终端省了电，也为他的网络省了资源，实现了双赢。这正是5G网络为赋能千行百业、实现万物智联所做的精巧设计。

FAQ

Q1：Suspend-Resume和RRC INACTIVE状态，有什么本质区别？ A1：本质区别在于核心网用户面（NG-U）的状态。

  • INACTIVE: UE的NG-U隧道在UPF和gNB上是保持建立的。UPF会缓存下行数据。当UE恢复时，可以直接通过这条已有的隧道传输数据，恢复速度最快。但它持续占用着UPF和传输资源。
  • Suspend: UE的NG-U隧道在挂起时，被彻底释放了。UPF不会为它缓存数据。当UE恢复时，需要走一个重新建立NG-U隧道的流程。它的恢复速度比INACTIVE稍慢，但比IDLE快得多。

Q2：如果UE在被gNB-A挂起后，移动到了gNB-B的覆盖下，它还能恢复吗？ A2：可以，但流程会更复杂。当UE在gNB-B上发起Resume请求时，gNB-B会发现自己本地没有这个UE的上下文。此时，gNB-B会向AMF发送一个INITIAL UE MESSAGE，其中包含了UE的Resume ID。AMF看到这个ID后，就知道这是一个“跨站恢复”的场景。AMF会联系旧的gNB-A，通过RETRIEVE UE CONTEXT流程，将UE的上下文从gNB-A“取回”，然后再通过INITIAL CONTEXT SETUP流程，在新的gNB-B上重建。这个过程被称为“上下文迁移（Context Fetch）”，保证了UE在移动场景下的恢复能力。

Q3：为什么规范说这个功能当前版本只适用于ng-eNB (对于UE Context Resume)？ A3：这是一个需要注意的历史版本细节。在早期（如Rel-15/16）的规范版本中，Suspend-Resume功能，特别是用户面CIoT优化，是优先在**连接到5GC的4G基站（ng-eNB）上进行标准化和引入的。随着版本的演进，这些功能也逐步被引入到了5G基站（gNB）**上。在最新的规范（如我们解读的V18.2.0）中，这些功能通常已经同时适用于gNB和ng-eNB。规范中残留的“only applies for ng-eNB”等字样，有时是历史遗留的编辑问题，需要结合最新的核心网规范（TS 23.501）来理解其最广义的适用范围。

Q4：Suspend-Resume功能需要UE的特殊支持吗？ A4：是的。UE必须在其能力信息中，明确声明自己支持“User Plane CIoT 5GS Optimisation”和/或“Suspend-Resume for long eDRX”。网络（gNB和AMF）只有在看到UE的这个能力声明后，才能对它启用Suspend-Resume流程。

Q5：挂起状态下，如果有下行数据到达UPF，会发生什么？ A5：由于NG-U隧道已经被释放，UPF无法直接将数据发往gNB。此时，UPF会像处理IDLE态UE一样，向SMF发送“下行数据通知（Downlink Data Notification）”。SMF再通知AMF。AMF会发起寻呼（Paging）流程，来唤醒处于挂起状态的UE。UE被寻呼唤醒后，会发起我们上文描述的UE Context Resume流程，重建用户面，最终接收到这份下行数据。

关系图谱