深度解析 3GPP TR 21.918：6.2 Enhanced support of Reduced Capability (RedCap) NR devices (对NR RedCap设备增强支持)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“6.2 Enhanced support of Reduced Capability (RedCap) NR devices”的核心章节，旨在为读者深度剖析5G-Advanced如何通过进一步降低终端复杂度和功耗，为中高速物联网（IoT）应用场景打开全新的市场空间。
在5G的万物互联版图中，存在着一个巨大的“中间市场”。一端是eMBB（增强移动宽带）设备，如智能手机，追求极致的速率和性能，但成本高、功耗大；另一端是LPWA（低功耗广域）设备，如NB-IoT，功耗极低、成本便宜，但只能满足小数据量、超低速率的业务需求。那么，对于工业传感器、智能穿戴、视频监控这类需要“中等”速率（几十到上百Mbps）和较低时延，同时又对成本和功耗非常敏感的应用，该何去何从？
为了填补这一空白，3GPP在Release 17中正式引入了RedCap（Reduced Capability）技术，裁剪了NR终端的能力，旨在以更低的成本和功耗，提供“恰到好处”的5G连接。然而，技术的演进永无止境。为了进一步拓展市场，与更低成本的LTE Cat.1/1bis等技术竞争，Release 18对RedCap进行了关键的增强，催生了更轻量级的eRedCap (enhanced RedCap)。
今天，我们的主角是一家领先的智能制造工厂的技术总监，张工。他正在评估一款名为**“鹰眼-C1”**的新型5G工业质检摄像头。这款摄像头需要实时回传高清视频流，用于产线的AI视觉缺陷检测。传统的5G模组成本过高，而LTE-M又无法满足视频上行带宽的需求。而“鹰眼-C1”搭载的，正是Rel-18定义的eRedCap芯片。它能否在满足性能的同时，实现张工对成本和功耗的极致追求？让我们跟随张工的评估过程，深入6.2章节，一探究竟。
1. eRedCap的诞生：极致的复杂度削减
张工首先关注的是成本。他知道，通信模组的成本与其复杂度直接相关，特别是射频前端和基带处理单元。eRedCap的核心使命，就是在RedCap的基础上，进行更深度的“瘦身”。
NR_redcap_enh introduces enhancements of Rel-17 RedCap functionality by introducing features for further UE complexity reduction (through UE peak data rate reduction and UE baseband bandwidth reduction) and further UE power saving… to expand the market for RedCap use cases with low-tier eRedCap devices similar to LTE UE category 1/1bis…
规范开篇就点明了Rel-18增强的核心：进一步降低UE复杂度。目标非常明确，就是要让eRedCap设备在成本上能够与成熟的LTE Cat.1/1bis技术相抗衡，从而打开更广阔的物联网市场。
1.1 大刀阔斧的“降速”：峰值速率的削减
降低复杂度的第一刀，砍向了峰值速率。
Rel-18 introduces an eRedCap UE type allowing for further complexity reduction using the following techniques:
- UE peak data rate reduction in FR1 The UE peak data rate reduction restricts the peak rate in DL and UL to 10 Mbps. For every eRedCap UE, the peak rate target is 10 Mbps in UL and DL regardless of what other features the UE may support.
对于“鹰眼-C1”来说，这是一个好消息。它的高清视频码流大约在5-8 Mbps，10 Mbps的峰值速率绰绰有余。而将速率上限从RedCap的几十甚至上百Mbps降低到10 Mbps，意味着：
- 更简单的硬件：可以采用更少的接收天线（例如单天线）、更低阶的调制方式、更简单的射频链路，这些都直接转化为硬件成本的降低。
- 更小的处理需求：基带处理器需要处理的数据量大幅减少，可以使用更低规格、更低成本的芯片。
1.2 “小马拉大车”的智慧：基带带宽的精简
降低复杂度的第二刀，也是最精妙的一刀，砍向了基带处理带宽。
- UE baseband bandwidth reduction in FR1 The UE baseband bandwidth reduction restricts the maximum number of PRBs for PDSCH/PUSCH that the UE needs to process per slot. This maximum number of PRBs corresponds to about 5 MHz, or more precisely 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS…
这意味着eRedCap芯片的“大脑”（基带处理器）在任何一个时刻（slot），只需要具备处理约5MHz带宽数据的能力。然而，5G NR的最小小区带宽通常是20MHz。一个只有5MHz处理能力的“小脑”，如何在一个20MHz的“大赛道”上工作呢？
- For broadcast (SIB/paging/Msg2) PDSCH, the number of allocated PRBs is not restricted, i.e., any number of PRBs can be allocated within 20 MHz, but it is assumed that the UE is allowed to serialize its processing of these PRBs if they exceed 25/12 PRBs, so that the UE baseband parts process no more than 25/12 PRBs per slot…
这就是eRedCap的智慧所在——串行化处理（Serialize its processing）。
- 化整为零：当网络在一个20MHz的宽频带上广播系统信息（SIB）时，“鹰眼-C1”并不需要一次性将20MHz的信号全部接收并处理。它可以像“扫描”一样，先处理前5MHz，再处理下一个5MHz，分多次完成对整个20MHz带宽信息的解码。
- 时间换空间：这种“分时处理”的方式，虽然会比全带宽设备多花一点时间，但它极大地降低了对基带处理器瞬时处理能力和缓存（Buffer）大小的要求，从而可以用更小、更便宜的芯片实现。这正是典型的“时间换空间”设计哲学。
1.3 网络的“宽容”：为慢处理预留时间
“串行化处理”虽然巧妙，但也带来了副作用——处理延迟。eRedCap设备在随机接入过程中，解码网络下发的第二步消息（Msg2）会比普通设备慢。如果网络不“体谅”这一点，按照标准时间要求它回复第三步消息（Msg3），“鹰眼-C1”可能会因为“反应不过来”而导致接入失败。
As mentioned above, if a gNB wants to schedule a Msg2 PDSCH with more than 25/12 PRBs, then an eRedCap UE may need a relaxed Msg2-Msg3 timeline. This means that the minimum time between Msg2 and Msg3 is increased by 1 slot.
3GPP为此设计了网络与终端的协同机制：网络侧可以配置一个“宽松的”时间线。当gNB知道正在接入的是一个eRedCap设备，并且下发的Msg2带宽超过了它的处理能力时，gNB会“耐心”地多等待一个slot的时间，给“鹰眼-C1”留出充足的“思考时间”来完成解码和准备Msg3的发送。
这种网络侧的“宽容”，确保了极简设计的eRedCap终端依然能够可靠地接入到标准的5G网络中。
2. eRedCap的续航革命：深度睡眠的艺术
对于“鹰眼-C1”这样的工业摄像头，除了成本，功耗是张工考量的另一个核心指标。生产线并非24小时运转，在夜间停工或设备维护期间，摄像头并不需要实时在线，但又必须保持在需要时能够被快速唤醒的能力。RRC_INACTIVE（RRC非活动态）是一个理想的选择，它允许设备在保持核心网连接上下文（如IP地址、安全密钥）的同时，进入低功耗的休眠状态。
然而，在Release 17中，RRC_INACTIVE态的睡眠深度是有限的。
The Rel-17 RedCap work item introduced extended DRX cycles for RRC Idle state (up to 10485.76 seconds, i.e., ~3 hours) and RRC Inactive state (up to 10.24 seconds) as an optional feature…
这意味着，在Rel-17的规范下，如果“鹰眼-C1”进入Inactive态，它最长只能睡10.24秒就必须醒来一次，监听网络寻呼。这对于需要沉睡数小时的夜间停工场景来说，无疑是巨大的电能浪费。
Release 18彻底改变了这一现状。
Further UE power saving (through enhanced eDRX in RRC Inactive state) Rel-18 takes a step further by introducing support for enhanced eDRX cycle length in RRC Inactive state beyond 10.24 seconds, up to the same eDRX cycle length as for RRC Idle state (up to 10485.76 seconds, i.e., ~3 hours), making the RRC Inactive state more power-efficient.
这一增强，让RRC_INACTIVE态的eDRX周期，从短短的10.24秒，一举跃升至与RRC_IDLE态相同的近3个小时。
- 深度睡眠与快速唤醒的兼得：对于“鹰眼-C1”来说，这意味着它可以在夜间停工时，进入长达数小时的深度睡眠，功耗与IDLE态几乎无异。而当第二天产线恢复，需要立即开始工作时，由于它保留了RRC Inactive的上下文，它可以极速恢复连接，无需经历从IDLE态开始的完整、耗时的RRC连接重建过程。这完美地结合了IDLE态的极致省电和CONNECTED态的快速响应。
2.1 端到端的协同：核心网的“数据管家”
要让设备在RAN侧安然沉睡数小时，必须确保核心网（CN）在此期间不会徒劳地向它发送数据。
For eDRX cycles longer than 10.24 seconds, new procedures between RAN and CN have been defined to enable/disable buffering of data and signalling in the CN, based on the RAN configured eDRX cycle and paging time window (PTW).
Rel-18为此定义了全新的RAN-CN协同流程：
- RAN的“休眠通知”：当RAN（gNB）决定让“鹰眼-C1”进入一个长达3小时的Inactive eDRX周期时，它会通过NGAP接口，将这个“休眠计划”（eDRX周期和寻呼窗口信息）通知给核心网的AMF。
- CN的“数据缓冲”：AMF收到通知后，就会扮演起“数据管家”的角色。在此期间，如果UPF有下行数据要发给“鹰眼-C1”，AMF会指示UPF：“这个设备正在深度睡眠，请将数据暂时缓冲起来，不要下发。”
- 精准寻呼：只有当RAN通知AMF，设备的下一个寻呼窗口即将到来时，AMF才会触发下行数据的传输。
这一端到端的协同机制，确保了整个5G系统共同为eRedCap设备的深度睡眠“保驾护航”，避免了任何不必要的网络信令和功耗开销。
总结
通过对“鹰眼-C1”工业摄像头的评估，张工对Rel-18的eRedCap技术有了深刻的认识。它并非简单的功能裁剪，而是一套包含终端侧设计、空口协议和网络侧协同的完整、精巧的系统工程。
通过峰值速率和基带带宽的双重削减，以及“串行化处理”和“宽松时间线”的巧妙设计，eRedCap在硬件成本上实现了质的飞跃，使其能够真正打入过去由LTE Cat.1等技术主导的市场。
通过将RRC Inactive态的eDRX周期扩展至数小时，并建立端到端的RAN-CN协同缓冲机制，eRedCap在功耗上实现了革命性的突破，完美地平衡了“深度睡眠”和“快速唤醒”这对看似矛盾的需求。
最终，张工在评估报告上写下结论：eRedCap技术精准地命中了工业物联网对成本、功耗和性能的“甜蜜点”，是驱动工厂向5G智能化升级的理想选择。“鹰眼-C1”项目，批准通过！
FAQ - 常见问题解答
Q1：Rel-18的eRedCap与Rel-17的RedCap最主要的区别是什么？ A1：最主要的区别在于复杂度和成本的进一步降低。Rel-17 RedCap是“做减法”，例如将天线从4根减到1-2根，最大带宽从100MHz减到20MHz。而Rel-18 eRedCap是“深度减法”，它在RedCap的基础上，引入了两项关键的复杂度削减技术：1）峰值速率限制：将上下行峰值速率严格限制在10 Mbps，这允许使用更简单的射频和基带设计。2）基带带宽限制：将终端的瞬时处理带宽限制在约5MHz，通过“串行化处理”技术来兼容更宽的小区带宽。这两项增强使得eRedCap芯片可以比RedCap更小、更便宜、功耗更低，主要对标LTE Cat.1/1bis市场。
Q2：什么是处理“串行化”（Serialize its processing）？它如何帮助eRedCap降低成本？ A2：处理“串行化”是一种“以时间换空间”的策略。想象一下，要读取一本20页宽的书（20MHz带宽的信号），一个“全能阅读器”可以一次性看完20页。而一个“迷你阅读器”（eRedCap的5MHz基带处理器）一次只能看5页。串行化处理就是允许这个“迷你阅读器”先看第1-5页，再看第6-10页，分4次看完。虽然总时间更长，但这个“迷你阅读器”本身的设计可以非常简单、小巧，其内部需要的“暂存区”（Buffer）也小得多。在芯片设计中，处理器规模和内存大小直接决定了成本和功耗，因此，通过允许更长的处理时间（串行化），eRedCap可以用极低的硬件成本实现对宽带信号的兼容。
Q3：为什么说将RRC Inactive态的eDRX周期延长至数小时，是RedCap省电技术的一大革命？ A3：因为它完美结合了RRC IDLE态的极致省电和RRC CONNECTED态的快速恢复两大优势。在此之前，设备要想实现数小时的深度睡眠，只能进入IDLE态，但这会丢失所有的连接上下文（如IP地址、安全密钥、QoS配置等），唤醒时需要走一遍完整的、耗时耗电的连接重建流程。而Inactive态虽然可以保留上下文实现快速恢复，但最长只能睡10.24秒，无法满足长周期休眠的需求。Rel-18的增强打破了这一壁垒，让设备可以在保留完整上下文的前提下，实现长达数小时的深度睡眠。这对于那些需要长时间静默但又要求在需要时能被快速唤醒的物联网应用（如工业传感器、穿戴设备）来说，是革命性的体验提升。
Q4：eRedCap设备是否需要特殊的网络才能工作？ A4：需要网络侧进行相应的软件升级和配置，但不需要特殊的硬件。gNB（基站）需要能够识别eRedCap设备，并为其配置“宽松的Msg2-Msg3时间线”。同时，gNB和核心网的AMF需要支持新的RAN-CN协同流程，以便在eRedCap进入长周期eDRX时，能够正确地缓冲下行数据。这些都是通过软件更新实现的。从空口协议上看，eRedCap完全兼容标准的5G NR框架，因此它可以与普通5G手机在同一个小区内共存。
Q5：eRedCap（目标10Mbps）与NB-IoT/LTE-M（通常低于1Mbps）相比，主要的应用场景区别在哪里？ A5：它们面向的是物联网金字塔的不同层级。NB-IoT/LTE-M位于金字塔的底端，专注于海量、低功耗、小数据量的应用，如智能水表、烟感、资产追踪等，这些应用每次只传输几十或几百字节的数据，对时延不敏感。而eRedCap则瞄准金字塔的“腰部”，即中高速率物联网应用。它的10Mbps能力，可以轻松支持高清视频监控、工业自动化控制中的大数据量上报、高端智能穿戴设备的数据同步等。这些是NB-IoT/LTE-M完全无法满足的。可以说，eRedCap填补了LPWA与eMBB之间的巨大空白，是推动5G在垂直行业大规模应用的关键技术。