5G RedCap 物联网实战：为什么它是中速率场景的最优解

中速率物联网在很长一段时间里是个让人头疼的位置。高速设备可以用eMBB，低速设备可以用NB-IoT，但中间那批对带宽、时延、功耗和成本都有要求的设备，总是找不到特别合适的网络。5G RedCap出现以后，很多人觉得这个问题终于有解了。但真正做项目时，它是不是“最优解”，还得看网络、终端和应用场景能不能对上。

RedCap全称是Reduced Capability，3GPP在R17引入，也有人叫它NR Light。它不是一种新的独立网络，而是对5G NR做裁剪后形成的终端能力等级。和普通5G手机相比，RedCap终端不需要支持很宽的带宽，也不需要双天线甚至四天线，调制阶数和MIMO层数也做了限制。这些“减法”换来的是终端复杂度、体积和成本的下降，同时保留了5G NR的时延、覆盖增益和网络特性。

换句话说，RedCap瞄准的正是中速率场景，也就是速率需求在几十Mbps量级、时延要求比NB-IoT高很多、但终端成本又扛不起eMBB的那批设备。这个位置在LTE时代由Cat.1和Cat.4填充，在5G时代，RedCap想接过来。

RedCap到底做了哪些“减法”

理解RedCap，关键在于搞清楚它剪掉了什么。R17定义的RedCap终端，在FR1频段内最大信道带宽被限制为20MHz，而普通eMBB终端往往需要支持100MHz甚至更宽。天线链路从2T2R降为1T1R，MIMO层数只有1层，调制阶数最高到64QAM。这些东西每一项都会直接影响峰值速率，但也每一项都在降低射频前端、基带处理和调度的复杂度。

更大的改动在协议侧。RedCap终端不需要支持完整的PDCCH盲检能力，公共信道上的某些配置可以跳过；网络侧也要为RedCap终端做专用BWP配置，避免它们去解读面向eMBB的高带宽控制资源。这些设计听起来不大，但实际影响着终端能否接入5G小区，以及接入后能不能稳定工作。

功耗方面，RedCap也借助5G NR现有的节能机制。比如SDT（Small Data Transmission）可以让小包数据不经过RRC_INACTIVE到CONNECTED的完整流程，这对周期性上报的传感器很有价值。R18又引入了更低的终端复杂度等级，继续往低功耗和低成本方向推进。

一张表看懂RedCap的位置

选型的时候，最容易的问题是拿着RedCap和eMBB、Cat.4、NB-IoT做对比。这里整理一张常用网络制式的关键差异表，省得再四处翻资料。

注意这里的速率和时延是典型范围，实际取决于频谱带宽、网络负载和业务模型。RedCap在20MHz带宽下单向的理论峰值并不算低，工程上通常利用的是它的“够用”而不是“极限”。

为什么说它是中速率场景的最优解

这里要稍微保守一点。RedCap可以说是中速率场景的一个强解，但前提是网络侧已经具备了R17能力，业务本身又有在线视频、大文件采集或者对时延敏感的需求，这些诉求正好卡在NB-IoT和eMBB之间。

举一个实际的场景。某个做园区设备的团队，原来设备里用的是Cat.4模组，设备每十分钟回传一次状态数据，还要不定时拍照上传。Cat.4在LTE网络里确实够用，但模组价格始终降不下来，而且随着运营商网络重心转向5G，LTE的容量和覆盖优势只会越来越弱。换成RedCap模组之后，速率并没有成为瓶颈，反而因为网络有独立的RedCap BWP配置，调度优先级和时延都更容易保障。

另一个典型的例子是视频监控。一个摄像头持续上传1080p视频，上行吞吐往往需要3-5Mbps，NB-IoT完全不可能，eMBB模组价格高、功耗也高。RedCap能提供数十Mbps的上行能力，配合5G网络的覆盖增强，在城区做点位布控很合适。当然，这里有个前提，摄像头不能长期固定在信号特别弱的位置，否则RedCap的功耗优势会被回传重传抵消。

三个容易踩的坑

第一个误区，是把RedCap当成“便宜版eMBB”。RedCap的限速不是调节目标，而是能力设计。你可以在20MHz带宽里获得不错的吞吐，但如果你硬要跑大带宽、低时延、高可靠场景，它会先触顶。选型时别只看峰值，要定义好业务的95%时间点需求。

第二个误区，是认为5G网络覆盖到的地方RedCap就能连上。实际部署中，网络侧需要在gNB的RRC层和调度器里开启RedCap特性，还要为RedCap终端配置专门的BWP。如果只是把基站软件版本升级到R17，但没有打开对应开关，RedCap终端很可能无法完成随机接入，或者接入后被调度到eMBB的公共BWP而出现异常。

第三个误区，是用NB-IoT的覆盖预期去做RedCap的链路预算。RedCap虽然继承了5G的覆盖增强，但天线数少、带宽窄，在一些室内角落或地埋场景的覆盖能力并不比Cat.4好多少。部署前建议做现场扫频和业务级测试，用真实终端跑上行重传率和时延，而不是拿理论灵敏度算覆盖半径。

网络侧配置与终端选型

真正动手落地时，首先需要网络侧支持Rel-17及以上版本，并且开启RedCap相关能力。下面是一段简化的基站侧配置示意，用来帮助理解整体思路。

# gNB CU-CP RedCap 功能配置（示意）
redCap:
  enabled: true
  supportedVersion: r17
  bwpList:
    - id: bwp_redcap_1
      bandwidth: 20MHz
      subCarrierSpacing: 30kHz
      modulation: 64QAM
      maxMimoLayers: 1
  linkRecovery: cbg

这段配置不是某个厂商的真实命令，但表达的核心是一致的：网络要为RedCap终端分配一个专用BWP，限制带宽和调制方式，并且保留必要的链路自适应能力。很多问题出在这个BWP没有配好，比如带宽小于终端能力，导致PDSCH/PUSCH资源不够；或者BWP和公共BWP的调度周期冲突，使终端频繁丢同步。

终端选型方面，建议关注RedCap模组的频段支持和系统版本。国内运营商的RedCap普遍先落地在3.5GHz或2.6GHz频段，未来再有低频补充。如果项目需要全网覆盖，还要确认是否支持多频段和双卡策略。另外，模组的功耗指标要和业务上报周期匹配，不能只看待机电流，要看满载上传和弱信号重传时的整体功耗。

什么样的场景现在适合上RedCap

结合几个典型落地场景，可以画出一个相对清晰的边界：

• 工业无线传感器：数据量中等，上传频率高，有确定的时延要求，RedCap比Cat.1/NB-IoT更合适。
• 视频监控与巡检：持续视频流上行，要求稳定速率但不需要超高速率，RedCap能在功耗和成本之间取得平衡。
• 可穿戴和医疗监护：需要周期性上报位置或体征，对终端体积和射频功耗敏感，RedCap的R17/R18低功耗特性有实际价值。
• 配电与公用基础设施：设备数量大且分散，需要长期在线，RedCap的支持范围相比LTE更有长期优势。

反过来，如果业务只能用极低成本、极低功耗来换取很小的数据量，NB-IoT或Cat.1更合适；如果要在高速移动场景下做大文件传输，eMBB仍然是更稳妥的选择。RedCap适合“足够好”的中速率需求，这也是它被称为中速率场景最优解的原因。

落地前需要确认的几件事

1. 确认当前网络是否已开启RedCap能力，最好先做一次工程模式下的接入验证。
2. 向模组厂商索取RedCap能力集和参考功耗数据，不要直接沿用Cat.4的供电和天线设计。
3. 在真实业务点位测至少一周，记录RSRP、SINR、上行丢包率和时延分布，用于评估是否满足SLA。
4. 对比替换成本，如果原有LTE终端仍能支撑业务，可以等RedCap生态更成熟再迁移。

这里的关键点在于，不要被“RedCap最优”这个说法带节奏。它是某个条件下的最优，不是一个放之四海而皆准的答案。网络、终端、业务三端都对齐之后，RedCap才会成为真正顺手的选择。

最后

5G RedCap不是一场突然的话题，而是中速率物联网在5G时代的一次补位。它解决了很多项目在速率、成本和时延之间反复摇摆的问题，但同时也把选择难度从“选网络制式”转移到了“做网络、终端、业务的三方匹配”。

从工程角度来看，RedCap真正吸引人的地方，不是某个极限参数，而是它重新定义了中速率场景的性价比边界。如果你手上的项目正处于这个边界上，值得用一两个月做一次技术验证；如果只是想要一个低成本的连接方案，那还是先回到业务需求本身，再决定要不要追这波5G RedCap的热度。