# 5G RedCap：轻量终端的瘦身哲学
> 一部5G手机动辄几千块，但你手腕上的智能手表、工厂里的温湿度传感器、路边的监控摄像头——它们也需要5G，却不需要Gbps峰值速率。RedCap就是给这些"小个子"量身定制的5G"简装版"。
## 一、从一个类比说起：为什么需要"瘦身版5G"
想象你去超市购物。如果你是采购一家餐厅的食材，你会推一辆大购物车，什么都往里装——这就像eMBB终端，追求极致性能。但如果你只是下班路上买瓶酱油，开辆卡车去就太浪费了——你需要的是一辆自行车。
**RedCap（Reduced Capability，降低能力）** 就是为那些"买瓶酱油"的场景设计的。它在5G NR框架内，有选择地裁剪终端能力，把不需要的东西砍掉，只保留业务真正需要的部分。
结果是什么？**终端成本降低约50%~65%，功耗大幅下降，模组体积缩小到可以塞进智能手表。**
但这里有一个关键的设计哲学：**不是另起炉灶搞一套新标准，而是在现有5G NR框架内做减法。** RedCap终端依然使用5G的帧结构、信道设计、网络架构——基站只需要软件升级就能支持RedCap，不需要新建一张网。
## 二、5G设备生态的"中间地带"
在RedCap出现之前，5G设备生态是两极分化的：
```mermaid
graph LR
A["🏆 eMBB
高端5G终端
手机/CPE/笔记本
Gbps级速率
~$200+模组"] --- B["❓ 中间地带
Mbps级需求
传感器/摄像头/手表
之前只有4G方案"]
B --- C["🔋 mMTC
低端物联网
NB-IoT/LTE-M
Kbps级速率
~$5-10模组"]
style A fill:#4CAF50,color:#fff
style B fill:#FF9800,color:#fff
style C fill:#2196F3,color:#fff
```
这个"中间地带"的需求非常庞大：
| 场景 | 典型速率需求 | 时延要求 | 设备量级 |
|------|-------------|---------|---------|
| 工业无线传感器 | ~2 Mbps | <100 ms | 千万级 |
| 视频监控 | 2~25 Mbps上行 | <100 ms | 亿级 |
| 可穿戴设备（手表/眼镜） | 5~50 Mbps | <10 ms | 数亿级 |
在RedCap之前，这些场景只有两个选择：用昂贵的eMBB模组（大材小用），或者退回4G Cat.1/Cat.4（无法享受5G切片、低时延等特性）。**RedCap的出现，填补了这个空白。**
## 三、RedCap裁了什么？——六大瘦身术
理解RedCap的关键是搞清楚它到底砍掉了什么，以及为什么砍掉这些不影响业务。我们逐一看这六大"瘦身术"：
### 瘦身术1：带宽缩减——从8车道变成2车道
**类比**：一条100 MHz的高速公路有8个车道，但你的车最多只能跑到20 MHz的速度，剩下的6个车道白白浪费了。RedCap直接把车道缩减到2条。
$$\text{RF带宽缩减} = \frac{20\text{ MHz}}{100\text{ MHz}} = 20\%$$
**技术细节**：
| 参数 | eMBB终端 | RedCap终端 |
|------|---------|-----------|
| FR1（Sub-6GHz）最大RF带宽 | 100 MHz | **20 MHz** |
| FR2（毫米波）最大RF带宽 | 200 MHz | **100 MHz** |
| 激活BWP带宽 | 最大100 MHz | 最大20 MHz |
带宽缩减带来的好处是**ADC/DAC采样率降低、滤波器变窄、基带处理量下降**——这些直接反映在芯片成本和功耗上。
### 瘦身术2：天线数减少——从四耳变单耳
**类比**：人的两只耳朵可以分辨声音的方向。4根接收天线（4Rx）能做空间复用和接收分集，但对一个传感器来说，1根天线就够用了。
$$\text{天线缩减因子} = \frac{1}{4} \text{（从4Rx到1Rx）}$$
| 参数 | eMBB终端 | RedCap（FR1） |
|------|---------|-------------|
| 接收天线数 | 4Rx | **1Rx（可穿戴）或2Rx（工业/监控）** |
| 下行MIMO层数 | 最多4层 | **最多1层** |
| 空间复用 | 支持 | **不支持** |
**为什么1根天线够用？** 对于传感器和手表这类设备，它们通常不在高速移动，信道环境相对稳定。1Rx虽然损失了分集增益（约3~6 dB），但在良好的覆盖环境下完全可以满足业务需求。
**实战影响**：天线数减半意味着射频前端器件（LNA、滤波器、混频器）数量直接减半，这对成本和PCB面积是巨大的节省。
### 瘦身术3：半双工FDD——发和收不同时
**类比**：对讲机就是半双工——你说话的时候不能听，听的时候不能说。但电话是全双工——同时说和听。全双工需要双工器（duplexer）来隔离发送和接收信号，这个器件又贵又占地方。
$$\text{HD-FDD: } T_{TX} \cap T_{RX} = \emptyset$$
**半双工FDD（HD-FDD）** 让终端在不同频段上交替发送和接收，但**不同时进行**。这样就可以用一个简单的开关（switch）替代昂贵的双工器。
| 对比项 | 全双工FDD | 半双工FDD |
|--------|----------|----------|
| 同时收发 | 是 | **否** |
| 所需器件 | 双工器（~$2-5） | **射频开关（~$0.3）** |
| 峰值速率 | 更高 | **略低（时隙交替）** |
| 适用频段 | 所有FDD | **特定FDD频段** |
### 瘦身术4：调制降级——256QAM到64QAM
**类比**：256QAM就像在同一个格子里放256个不同的符号，每个符号携带8 bit信息；64QAM只有64个符号，每个符号只带6 bit。符号越密集，对信号质量要求越高。
$$\text{频谱效率损失} = \frac{\log_2(64)}{\log_2(256)} = \frac{6}{8} = 75\%$$
最高调制从256QAM降到64QAM，峰值速率损失约25%。但对RedCap的目标场景来说，这完全够用——一个温湿度传感器根本不需要256QAM。
### 瘦身术5：控制信道简化——减少盲检次数
5G终端在每个时隙都要做大量PDCCH盲检（Blind Decoding），来搜索基站发给自己的控制信息。RedCap大幅减少了盲检次数和搜索空间配置。
| 参数 | eMBB | RedCap |
|------|------|--------|
| PDCCH盲检次数（每时隙） | 44次（FR1） | **大幅减少** |
| CSI-RS跟踪要求 | 完整 | **简化** |
| CSI反馈 | 完整 | **简化** |
**为什么可以简化？** 因为RedCap终端的BWP窄、天线少、MIMO层数低，基站调度给它的控制信息本身就少，不需要那么多盲检。
### 瘦身术6：节能机制——更深更长的睡眠
RedCap在DRX（不连续接收）基础上增加了更激进的节能策略：
```mermaid
graph TD
A["RRC_CONNECTED
活跃态：正常收发数据"] -->|"数据空闲"| B["Light Sleep DRX
短周期浅睡眠
微秒级唤醒"]
B -->|"更长时间空闲"| C["Deep Sleep DRX
长周期深睡眠
毫秒级唤醒"]
C -->|"超长空闲"| D["RRC_INACTIVE
极深睡眠
秒级唤醒"]
D -->|"长时间无活动"| E["RRC_IDLE
关机级睡眠
保持注册"]
style A fill:#4CAF50,color:#fff
style B fill:#8BC34A,color:#fff
style C fill:#FFC107,color:#333
style D fill:#FF9800,color:#fff
style E fill:#F44336,color:#fff
```
此外，RedCap还引入了**RRM测量放松**——当终端静止或低速移动时，可以降低邻区测量的频率和精度，进一步省电。
## 四、RedCap在5G协议栈中的位置
理解RedCap的另一个关键角度是：它在协议栈的哪些层做了裁剪？
```mermaid
graph TB
subgraph "5G协议栈"
NAS["NAS层
✅ 保留（正常注册/会话管理）"]
RRC["RRC层
⚠️ 简化（能力上报、测量放松）"]
SDAP["SDAP层
✅ 保留（QoS映射）"]
PDCP["PDCP层
✅ 保留（加密/完整性保护）"]
RLC["RLC层
⚠️ 简化（减少HARQ进程）"]
MAC["MAC层
⚠️ 简化（减少盲检、简化调度）"]
PHY["物理层
❌ 大幅裁剪
带宽↓ 天线↓ 调制↓"]
end
NAS --> RRC --> SDAP --> PDCP --> RLC --> MAC --> PHY
style PHY fill:#F44336,color:#fff
style MAC fill:#FF9800,color:#fff
style RLC fill:#FF9800,color:#fff
style RRC fill:#FFC107,color:#333
style NAS fill:#4CAF50,color:#fff
style SDAP fill:#4CAF50,color:#fff
style PDCP fill:#4CAF50,color:#fff
```
核心思想：**高层协议基本不动，主要在物理层和MAC层做减法。** 这保证了RedCap终端可以正常接入5G网络、使用网络切片、享受安全保护——它仍然是"纯正的5G公民"。
## 五、RedCap vs eRedCap：两代轻量化演进
3GPP并没有止步于Rel-17的RedCap。在Rel-18中引入了**eRedCap（enhanced RedCap）**，进一步压缩：
| 对比维度 | RedCap（Rel-17） | eRedCap（Rel-18） |
|---------|-----------------|------------------|
| FR1最大带宽 | 20 MHz | **5 MHz（可选）/ 20 MHz** |
| FR2最大带宽 | 100 MHz | **50 MHz** |
| 接收天线（FR1） | 1Rx 或 2Rx | **1Rx（强制）/ 2Rx（可选）** |
| HD-FDD | 支持 | **支持 + 增强** |
| 最大调制阶数 | 64QAM | 64QAM |
| 目标峰值速率 | ~220 Mbps DL | 进一步降低 |
| 新增节能特性 | 基础DRX | **增强DRX + 更激进测量放松** |
| 典型场景 | 工业传感器、监控、手表 | **更小型传感器、低功耗标签** |
```mermaid
graph LR
subgraph "5G设备能力谱系"
direction LR
E["eMBB
100MHz/4Rx/256QAM"] --> R["RedCap
20MHz/1-2Rx/64QAM"]
R --> ER["eRedCap
5MHz/1Rx/64QAM"]
ER --> M["mMTC
NB-IoT/LTE-M
200kHz~1.4MHz"]
end
style E fill:#4CAF50,color:#fff
style R fill:#2196F3,color:#fff
style ER fill:#FF9800,color:#fff
style M fill:#9C27B0,color:#fff
```
eRedCap的核心理念是**"能省则省"**——5 MHz带宽比20 MHz再省75%，这让那些只需要几Mbps甚至几百kbps的场景也能用上5G。
## 六、RedCap如何接入网络？——信令流程的关键差异
RedCap终端接入5G网络时，和普通eMBB终端有一个重要区别：**它必须在接入阶段就告诉网络"我是RedCap终端"**，否则基站可能给它分配超出能力的资源。
这个过程通过**Msg1/Msg3阶段的标识**来实现：
```mermaid
sequenceDiagram
participant UE as RedCap终端
participant gNB as 5G基站
participant AMF as 核心网AMF
Note over UE: 1. 读取SIB1广播
检查小区是否支持RedCap
UE->>gNB: Msg1（PRACH Preamble）
可选：使用RedCap专用前导码
gNB->>UE: Msg2（RAR）
UE->>gNB: Msg3（RRC SetupRequest）
携带UE Identity
gNB->>UE: Msg4（RRC Setup + Contention Resolution）
UE->>gNB: RRC SetupComplete
携带UECapabilityInformation
【关键】上报RedCap能力
gNB->>AMF: Initial UE Message
携带RedCap指示
AMF->>gNB: 初始上下文建立
基站据此调整调度策略
Note over gNB: 基站为RedCap终端
配置窄BWP、减少盲检
```
**几个关键设计点：**
1. **SIB1中的RedCap指示**：基站在系统信息广播中声明本小区是否支持RedCap，终端据此决定是否驻留
2. **能力上报是关键**：终端必须在RRC连接建立后尽快上报RedCap能力，包括带宽、天线数、是否支持HD-FDD等
3. **基站自适应调度**：基站收到RedCap能力后，会自动将调度参数调整到终端能力范围内——比如只分配20 MHz BWP、只用单层MIMO
## 七、成本分析：到底省了多少钱？
用一个具体的成本拆解来说明RedCap的省钱逻辑：
| 成本项 | eMBB模组占比 | RedCap节省 | 原因 |
|--------|------------|-----------|------|
| 基带芯片 | 30% | ~40% | 采样率降低、MIMO处理简化 |
| 射频前端 | 25% | ~60% | 天线数减少、双工器→开关 |
| 功放（PA） | 15% | ~30% | 峰值功率要求降低 |
| 内存 | 10% | ~50% | 缓冲区缩小（速率低、HARQ进程少） |
| 电源管理 | 8% | ~20% | 功耗整体下降 |
| 其他（封装/测试） | 12% | ~30% | 引脚数减少、测试项简化 |
**综合下来，RedCap模组的目标价格是50~100美元区间，而当前5G eMBB模组在150~250美元。** 考虑到规模效应，未来RedCap模组有望降到30美元以下——这才是物联网大规模商用的心理价位。
## 八、实战连接：工程师调试RedCap要注意什么
### 1. 覆盖补偿
RedCap终端只有1Rx，接收灵敏度比4Rx差3~6 dB。在实际部署中需要注意：
$$\text{覆盖余量} = P_{RX,4Rx} - P_{RX,1Rx} \approx 3\text{~}6 \text{ dB}$$
如果是在小区边缘部署RedCap传感器，可能需要**基站侧提升发射功率**或**增加RS功率偏置**来补偿。
### 2. BWP配置
基站需要为RedCap终端配置专用的窄BWP（≤20 MHz）。如果BWP配置不当（比如配置了超过20 MHz的BWP），RedCap终端将无法正常工作。调试时关注RRC Reconfiguration中的BWP字段。
### 3. HD-FDD时隙配比
半双工FDD终端不能同时收发。基站调度器必须确保不会在同一个时刻给HD-FDD终端分配上行和下行资源。这需要调度器感知终端的双工能力，属于**厂家实现相关的特性**，不同设备商的表现可能不同。
### 4. 功耗调优
RedCap的功耗优势需要配合合理的DRX配置才能充分发挥。常见的调试陷阱包括：
- DRX周期配置过短，导致终端频繁唤醒
- RRM测量配置过于激进，静止终端仍在频繁测量邻区
- 未启用RRC_INACTIVE状态，终端频繁在IDLE和CONNECTED之间切换
## 九、RedCap vs 4G IoT方案：为什么要"新的旧问题"
一个常见的疑问是：**4G已经有Cat.1、Cat.4、NB-IoT等方案，为什么还要搞RedCap？**
| 对比维度 | LTE Cat.1 | LTE Cat.4 | 5G RedCap |
|---------|----------|----------|-----------|
| 峰值速率 | 10 Mbps DL | 150 Mbps DL | ~220 Mbps DL |
| 时延 | 50~100 ms | 20~50 ms | **<10 ms** |
| 网络切片 | 不支持 | 不支持 | **支持** |
| 5G LAN | 不支持 | 不支持 | **支持** |
| 定位精度 | ~50 m | ~50 m | **米级（配合5G定位）** |
| 网络寿命 | 4G逐步退网 | 4G逐步退网 | **5G长期演进** |
| 时间敏感网络 | 不支持 | 不支持 | **支持TSN集成** |
**核心差异不是速率，而是5G生态能力。** RedCap终端可以享受5G网络切片（端到端QoS保障）、5G LAN（二层通信）、高精度定位、TSN集成等5G独有能力——这些是4G IoT方案无法提供的。
更重要的是，**4G网络终将退网**。全球多家运营商已宣布2030年前后关闭4G网络。RedCap为物联网设备提供了一个面向未来的5G原生方案。
## 常见问题
**Q1: RedCap和NB-IoT是什么关系？会替代NB-IoT吗？**
A: 不是替代关系，而是互补。NB-IoT面向极低速率（<100 kbps）、极低功耗（电池寿命10年+）、极低成本的场景（如智能水表），RedCap面向中速率（Mbps级）场景。两者在5G生态中并存，各有分工。
**Q2: 现有的5G基站支持RedCap需要什么改动？**
A: 主要需要软件升级。基站需要新增RedCap终端识别、窄BWP配置、HD-FDD调度支持、RRM测量放松配置等功能。大部分5G基站厂商已通过软件更新支持RedCap，不需要更换硬件。
**Q3: RedCap终端的手机号（USIM）和普通5G手机一样吗？**
A: USIM卡本身是通用的，RedCap终端使用和普通5G终端相同的USIM。区别在于终端能力——网络通过终端上报的能力信息来区分RedCap和eMBB终端，并据此提供不同的服务。
**Q4: RedCap可以用于FWA（固定无线接入）吗？**
A: 可以，这也是RedCap的一个重要应用方向。特别是eRedCap的5 MHz带宽版本，适合为家庭提供中等速率的宽带接入（~50~100 Mbps），作为光纤到户的补充方案。成本远低于eMBB CPE。
**Q5: RedCap终端的峰值速率到底能达到多少？**
A: 以FR1、20 MHz带宽、64QAM、1Rx为参考：下行峰值约85~220 Mbps（取决于MCS和调度效率），上行峰值约50 Mbps。实际商用速率取决于网络配置和信道条件，通常为峰值的50%~70%。
## 参考来源
1. [5G RedCap: Unlocking Scalable IoT and FWA Innovation](https://www.3gpp.org/news-events/partner-news/redcap-gsa-article01) — 3GPP官方GSA联合文章，RedCap标准背景与应用全景
2. [RedCap/eRedCap - standardizing simplified 5G IoT devices](https://www.ericsson.com/en/blog/2024/12/redcap-eredcap) — 爱立信技术博客，RedCap与eRedCap的技术对比
3. [5G NR-Light (RedCap): Revolutionizing IoT | Qualcomm](https://www.qualcomm.com/news/onq/2022/07/what-is-5g-nr-light--a-k-a--redcap--and-how-will-it-accelerate-t) — 高通技术解读，NR-Light设备类别定位
4. [5G RedCap vs eRedCap: Key Differences](https://www.rfwireless-world.com/terminology/difference-between-5g-redcap-and-eredcap) — RF Wireless World技术对比表
5. [解构RedCap：5G轻量级物联网技术的特性、场景与落地路径](https://rf.eefocus.com/article/id-339699) — RF技术社区，RedCap完整技术特性分析
---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
