深度解析 3GPP TR 21.918：6.3 NR RedCap UE with long eDRX for RRC_INACTIVE State (支持长eDRX的NR RedCap非活动态)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“6.3 NR RedCap UE with long eDRX for RRC_INACTIVE State”的核心章节。本文将作为上一篇《6.2 Enhanced support of Reduced Capability (RedCap) NR devices》的姊妹篇，从系统架构（SA）与核心网（CN）的视角，深入剖析5G系统是如何为RedCap设备的深度睡眠与按需唤醒提供端到端支持的。
在上一篇文章中，我们跟随智能制造工厂的技术总监张工，了解了Rel-18 eRedCap技术如何通过降低终端复杂度，为“鹰眼-C1”工业摄像头提供了极具性价比的5G连接方案。我们特别提到了eRedCap的一项革命性省电技术——在RRC_INACTIVE（非活动态）下支持长达3小时的eDRX（扩展非连续接收）周期。
然而，让一个设备在无线侧（RAN）沉睡数小时，绝不仅仅是RAN自己的事。这背后需要整个5G系统的紧密协同。核心网必须知道这个设备“睡着了”，并且知道它“何时会醒”，才能在此期间妥善地管理下行数据，并在恰当的时机将其唤醒。
今天，我们将引入一位新角色——运营商核心网的资深工程师，李伟。他的任务，就是为张工工厂里成百上千台“鹰眼-C1”摄像头，在核心网侧配置和使能深度睡眠与唤醒机制。这正是6.3章节的核心内容，它是6.2章节在系统架构层面的具体实现和延伸。可以说，如果6.2是无线接入网的“行动篇”，那么6.3就是核心网的“协同篇”。
1. 从RAN到CN：一个问题的两个侧面
在深入核心网的协同机制之前，我们先从规范的描述中，再次明确问题的本质。
Summary based on the input provided by Ericsson in SP-240289. The Rel-17 work item enhanced the support of NR RedCap UE in 5GS, including the power saving mechanism (MICO, eDRX) support for NR RedCap UE. However, the eDRX for RRC_INACTIVE state is only limited to 10.24s. This Rel-18 work item enables the usage of eDRX for NR RedCap UE in RRC_INACTIVE state beyond 10.24s, i.e., the same eDRX value range is applicable to both UE in CM-IDLE mode and UE in RRC_INACTIVE state.
规范的这段总结，与6.2章节的描述如出一辙，都指出了Rel-17 Inactive态eDRX周期过短（仅10.24秒）的痛点，以及Rel-18将其扩展至与IDLE态相同（最长近3小时）的目标。这清晰地表明，6.2（由RAN工作组主导）和6.3（由SA工作组主导）是在3GPP内部并行推进的、针对同一个技术特性的不同工作项目。前者聚焦于空口实现，后者则定义了系统级的流程和核心网行为。
李伟的工作，正是要将这些系统级的流程，在核心网的AMF、SMF、UPF等网元上配置和激活。
2. “数据管家”的职责：核心网如何管理沉睡的终端
当张工的“鹰眼-C1”摄像头在夜间停工时，gNB（基站）会让它进入一个长达3小时的eDRX周期的Inactive状态。此时，一场精密的RAN-CN协同大戏便拉开了序幕。李伟作为核心网的“总导演”，需要确保每个环节都万无一失。
2.1 “休眠协议”：RAN向核心网的请求与报备
首先，RAN必须将“休眠计划”告知核心网，请求核心网的配合。
The support for the request of CN based MT data and signalling handling includes a procedure that can be used by NG-RAN to request the CN based MT data and signalling handling for UE in RRC_INACTIVE state; and the NG-RAN provides necessary information for CN to calculate the UE reachability.
这个流程可以类比为：gNB（小区的“楼管”）在允许一位住户（“鹰眼-C1”）长时间外出度假（进入长eDRX）前，必须通知大厦的物业中心（核心网AMF）。
- gNB的请求：当gNB决定让“鹰眼-C1”进入长eDRX周期时，它会通过NGAP接口向AMF发起一个“请求核心网侧数据与信令处理”的请求。
- 关键信息的传递：在这个请求中，gNB会附上所有计算UE可达性所必需的信息，包括：配置的eDRX周期长度、寻呼时间窗口（PTW）的长度和偏移量、UE在RNA（RAN-based Notification Area）内的标识等。
AMF收到这些信息后，就相当于拿到了这位住户的“假期行程单”，并承担起了“数据管家”的职责。它会在UE的上下文中标记：“该UE正在深度睡眠，下一个可联系的时间窗口是…”。
2.2 “精准唤醒”：核心网触发的连接恢复
现在，假设在深夜，工厂的安保系统需要紧急调取“鹰眼-C1”的实时画面。这个请求通过应用服务器到达了核心网的UPF。此时，核心网该如何唤醒沉睡的摄像头？
The support for CN triggered Connection Resume handling includes a CN triggered connection resume procedure for UE in RRC_INACTIVE state; and the AMF calculates the UE reachability based on information provided by NG-RAN.
核心网并不会立即进行寻呼，而是会执行一个“精准唤醒”流程：
- 数据到达通知：UPF检测到有下行数据到达，通知SMF，SMF再通知AMF。
- 可达性计算：AMF查阅之前从gNB收到的“假期行程单”，精确计算出“鹰眼-C1”下一个寻呼窗口的到来时间。
- 触发寻呼：AMF会耐心地等待，直到计算出的寻呼窗口即将开始前，才向gNB发起一个“CN触发的连接恢复”请求，即指示gNB在该窗口期内对“鹰眼-C1”进行寻呼。
- 连接恢复：“鹰眼-C1”在其预设的唤醒时刻醒来，监听到寻呼，随即快速恢复RRC连接，接收下行数据。
这个流程，避免了核心网在UE的深度睡眠期间进行任何无效的寻呼尝试，确保了网络资源的有效利用和终端功耗的最小化。
3. 轻量级交互：MT-SDT在Inactive态的应用
在6.2章节中我们并未深入探讨，但6.3章节明确指出了一个重要的关联增强——对MT-SDT（移动终止-小数据传输）的支持。
It also supports MT-SDT handling for UE in RRC_INACTIVE state as alignment with Rel-18 RAN work NR_redcap_enh. …UPF/SMF reports DL data size per QoS flow to AMF when UPF triggers downlink data notification for UE in RRC_INACATIVE state with CN MT data handling activated; and the AMF provides the DL data size per QoS flow to NG-RAN when UE is considered reachable by AMF.
并非所有的下行业务都需要传输高清视频流。有时，安保系统可能只是想给“鹰眼-C1”发送一个简单的控制指令，比如“向左转动15度”。这个指令的数据量可能只有几十个字节。如果为此就将UE完全唤醒到RRC_CONNECTED状态，无疑是“杀鸡用牛刀”。
MT-SDT正是为这种场景而生。Rel-18将其应用到了Inactive态：
- 数据大小的上报：当UPF收到这个“向左转动”的小数据包时，它在通知AMF有数据到达的同时，还会附上一个额外的信息——“这个数据包很小，只有XX字节”。
- 信息的传递：AMF在向gNB发起寻呼请求时，会将这个“数据大小”的信息一并传递给gNB。
- RAN的智能决策：gNB收到这个带有“小数据”提示的寻呼请求后，就可以做出更智能的决策。它在寻呼UE后，可以选择不建立完整的RRC连接，而是直接利用为Inactive态设计的、更轻量级的小数据传输通道，将这个控制指令发送给“鹰眼-C1”。
- 事了拂衣去：UE在收到并执行完这个指令后，可以立即返回Inactive休眠状态，整个过程无需进入耗电的CONNECTED态。
这个看似微小的增强，对于需要频繁接收小指令的物联网应用来说，意义重大。它进一步降低了终端在Inactive态下的“唤醒成本”，将省电哲学贯彻到了极致。李伟知道，为张工的摄像头开启这项功能，将极大地提升其在待机状态下的续航表现。
4. 端到端流程的闭环
李伟在核心网侧完成了所有配置后，他与张工进行了一次端到端的联合测试，以验证整个流程的闭环。
- 进入休眠：张工在产线侧将“鹰眼-C1”设置为夜间模式。摄像头完成最后一次数据上报后，gNB通过RRC Release消息指示其进入Inactive态，并配置了3小时的eDRX周期。同时，gNB向李伟的核心网AMF发送了包含UE可达性信息的“休眠协议”。
- 下行数据触发：李伟在核心网侧模拟安保系统，向“鹰眼-C1”的IP地址发送了一个50字节的控制指令。UPF收到数据，逐级上报至AMF。AMF查询后发现UE正在长周期休眠，于是指示UPF缓冲数据。
- 精准唤醒与MT-SDT：3小时后，在预设的寻呼窗口到来前，AMF向gNB发起寻呼请求，并附上了“数据大小=50字节”的信息。gNB在指定窗口寻呼“鹰眼-C1”。
- 快速交互：“鹰眼-C1”醒来并响应寻呼。gNB判断数据量很小，决定采用SDT流程，快速将控制指令下发。摄像头收到指令后，调整了镜头角度，并立即返回了Inactive休眠状态。
测试圆满成功！这套由RAN和CN紧密协同的端到端流程，确保了RedCap设备在享受深度睡眠带来的极致省电的同时，依然保持着5G网络应有的“永远在线”的可达性。
总结
3GPP TR 21.918的6.3章节，为我们揭示了RedCap深度睡眠技术背后，核心网所扮演的不可或缺的“智慧管家”角色。它与6.2章节的内容相辅相成，共同描绘了一幅完整的、从无线空口到核心网络的端到端省电蓝图。
通过RAN-CN之间的“休眠协议”，核心网获得了预测UE可达性的能力。通过CN触发的精准唤醒机制，核心网确保了在不打扰UE休眠的前提下，下行数据的可靠送达。而通过将MT-SDT引入Inactive态，系统为小数据包交互开辟了一条更为节能的“绿色通道”。
对于李伟这样的核心网工程师而言，这些标准化的流程和接口，为他们管理和优化海量RedCap物联网终端提供了强大的工具。对于张工这样的行业用户而言，这意味着他们部署的5G物联网设备，将拥有前所未有的超长续航能力和极高的能效比，从而真正加速5G在千行百业的落地与普及。
FAQ - 常见问题解答
Q1：6.2章节和6.3章节都提到了RRC Inactive态的长eDRX，它们到底有什么不同？为什么需要分成两个Work Item？
A1：它们是同一个功能在3GPP不同技术规范组（TSG）下的不同工作项目（Work Item），关注点不同。6.2（WI: NR_redcap_enh）主要由RAN（无线接入网）工作组负责，聚焦于UE和gNB在空口侧的行为，例如定义新的eDRX周期参数、UE如何解释和执行这些参数、相关的物理层/MAC层信令等。而6.3（WI: NR_REDCAP_Ph2）主要由SA（系统架构）工作组负责，聚焦于系统级的端到端流程和核心网的行为，例如定义RAN和核心网（CN）之间需要交互哪些信息（如UE可达性）、CN如何根据这些信息处理下行数据（缓冲、触发寻呼）、以及CN如何与外部应用服务器交互等。分开立项是3GPP标准制定的常规流程，确保各技术领域都能进行深入、专业的讨论。
Q2：在长eDRX期间，如果核心网有数据要发给RedCap UE，数据是缓存在哪个网元上？AMF还是UPF？ A2：数据本身是缓存在**UPF（用户面功能）**上的。AMF（接入与移动性管理功能）是控制面网元，不处理用户数据。整个流程是：UPF收到下行数据后，发现没有通往gNB的用户面隧道，于是向SMF报告“下行数据通知”。SMF再通知AMF。AMF作为“数据管家”，知道UE正在深度睡眠，它不会让数据“白跑一趟”。AMF会指示SMF：“让UPF继续把数据存着（Start Buffering）”。因此，UPF是“仓库”，而AMF是发布“存货”或“发货”指令的“仓库管理员”。
Q3：什么是MT-SDT（移动终止-小数据传输）？它相比普通的连接恢复，省电在哪里？ A3：MT-SDT是一种轻量级的数据传输机制。普通的连接恢复，需要UE从Inactive态转换到Connected态，这个过程涉及到一系列RRC信令交互，会建立完整的信令承载（SRB）和数据承载（DRB），整个过程相对“重”，UE在此期间功耗较高，结束后还需要再走一遍流程回到Inactive态。而MT-SDT则允许UE在不完全进入Connected态的情况下，利用一个临时的、简化的信令通道，快速收发少量数据。它省电在：1）信令开销小：省去了完整的RRC连接建立/释放流程。2）状态维持时间短：UE收发完数据后可以近乎“瞬时”地返回休眠，射频开启时间大大缩短。
Q4：如果一个RedCap UE配置了3小时的eDRX周期，但在第1小时就移动到了一个新的gNB覆盖下，会发生什么？ A4：UE会立即被唤醒并执行一次RNAU（RAN-based Notification Area Update），也就是我们常说的Inactive态下的位置更新。RRC Inactive态的一个核心机制就是UE可以在一个由多个小区组成的RNA区域内自由移动而无需通知网络。但一旦UE移动到这个预定义区域之外，它就必须立即发起一次位置更新，向新的gNB报到。在这个过程中，新的gNB会与核心网AMF联系，重建UE的信令连接。随后，新的gNB会根据网络策略，为UE重新配置一个Inactive态的eDRX周期（可能是3小时，也可能是其他值），或者直接将UE拉入Connected态进行业务处理。所以，长eDRX周期并不会影响Inactive态基本的移动性管理流程。
Q5：这些针对RedCap的增强功能，对普通的5G手机（eMBB UE）适用吗？ A5：不完全适用，是可选的。从技术原理上讲，长eDRX、MT-SDT等机制并非RedCap独占，普通5G手机也可以支持。但是，这些功能主要是为了极致省电而设计的，这对于靠电池供电、数据传输非连续的物联网终端至关重要。而对于追求高性能、高响应速度、且通常会频繁充电的智能手机来说，长时间的深度睡眠可能会影响某些即时应用的体验（如即时消息推送）。因此，在标准中，这些增强功能通常被定义为RedCap设备的核心或推荐特性，而对于eMBB UE，它们通常是**可选（Optional）**的，是否启用取决于手机厂商的实现和运营商的策略。