asd199086的博客

在5G时代，某些场景的终端并不需要特别复杂，只要满足成本低，功耗小，尺寸小等要求即可，例如视频监控，可穿戴设备，工业无线传感器等，redcap就是在这样的背景下提出的。目前的大环境下，3GPP R17 redcap标准已经冻结，华为，中兴，爱立信，vivo，诺基亚贝尔等厂家已经完成关键技术及外场验证测试，R17 redcap商用基本没有悬念。但是到底什么是redcap UE？其工作机制又是怎样的？这里我们一步步来看下。Redcap的内容分散在38.300/38.306/38.331/38.321等spec中

如果在UplinkConfigCommonSIB中为UE提供了initialUplinkBWP-RedCap 但是没有配置 dedicated PUCCH资源配置，则UE使用由pucch-ResourceCommonRedCap提供的PUCCH resource set进行PUCCH HARQ-ACK信息的发送，这里的PUCCH跳频要注意下，如果PUCCH-ConfigCommon中存在intra-SlotFH，那PUCCH 跳频是disable的。

到NR同样有类似需求，在NR R17也引入eDRX，于是38.300就增加了9.2.10的如下内容。当使用eDRX时，以下规则适用：(1)对于RRC_INACTIVE的RAN paging eDRX配置由NG-RAN决定和配置。在 RRC_INACTIVE 中，UE要监听RAN和CN paging；(2)对于RRC_IDLE，用于CN paging的eDRX由上层配置。在RRC_IDLE中，UE仅需要监听CN paging；

无论FR1 的baseband bandwidth 是否有降低，eRedCap UE的峰值数据速率被进一步降低。(1)FR1的最大带宽为 20 MHz。eRedCap UE 不支持 FR1 中带宽大于20 MHz 的场景。值得注意的是eRedCap UE不支持FR2和FR1 SCS=60kHz 的场景。(2)eRedCap UE不支持CA、MR-DC、DAPS、CPAC 和 IAB（即 eRedCap UE 不充当 IAB 节点）等相关功能。

而eRedCap作为R18引入的升级版本，进一步将峰值速率限制为10Mbps，仅支持FR1频段，通过减少物理资源块（PRB）数量和优化休眠机制，实现了更低的功耗和成本，成为NB-IoT/LTE-M的理想升级路径。RedCap与eRedCap的出现，正是为了填补“中间地带”—它们既具备高于mMTC的传输速率（接近LTE Cat 4水平），又能实现传统5G NR无法企及的低功耗与低成本，完美适配智能电表、工业网关、智能穿戴设备等“中等需求”物联网设备。时延则低至50ms以下，满足工业机械远程控制的实时性需求。

在回复UE恢复RRC连接的请求或为SDT发起的恢复过程时，网络可以恢复suspend的RRC连接并让UE进入RRC_CONNECTED，也可以拒绝恢复请求并让UE继续在RRC_INACTIVE(使用wait timer)，亦或直接重新suspend RRC连接并让UE待在RRC_INACTIVE，还可以直接释放RRC连接并将UE进入RRC_IDLE，最后还可以指示UE发起NAS级别恢复(在这种情况下，网络会发送RRC setup消息)。对于后续的UL传输，UE无法通过CG资源发起重传。

这篇是SDT相关的具体过程，包括RRC层初始化SDT 的条件，MAC 层初始化SDT过程的判断，CG-SDT的具体过程，TA Validation for CG-SDT， CG-SDT TA 验证的路径损耗参考推导，SDT Uplink Time Alignment，RRC inactive中的CG based PUSCH传输和RA based PUSCH传输，依次看下。

RedCap UE可以通过发送MSG3/MSGA的特定LCID识别，可选条件是通过MSGA/MSG1的PRACH occasion/PRACH preamble识别，根据这段描述，通过MSG3/MSGA的识别是必须项，而MSGA/MSG1的识别过程是可选项。如果通过MSG3/MSGA识别，RedCap UE 由CCCH 标识（CCCH 或 CCCH1）指示的专用 LCID 标识识别，此时忽略网络配置的 RedCap特定RA配置。MSG3/MSGA的特定LCID识别(必须要支持的配置)。

这个疑问主要是上面这段话引起的，对于DownlinkConfigCommonSIB中的initialDownlinkBWP-RedCap提供的initial DL BWP，如果处于RRC_IDLE状态或RRC_INACTIVE状态的UE会根据Type1-PDCCH CSS set监听PDCCH而不根据Type2-PDCCH CSS set监听PDCCH，此时Redcap UE就不期望initial DL BWP包括SSB和CORESET 0。这时候就有人问，此时Redcap UE应该如何接受paging？

如果没有配置initialDownlinkBWP-RedCap，就应用initialDownlinkBWP，但是配置时，要符合RedCap UE的最大带宽要求，不能超过RedCap UE的能力。可能有人对于NCD-SSB的含义不太清楚，这里简单说明下，CD-SSB就是指有关联RMSI(SIB1)的SSB，即在小区搜索过程中通过SSB带的COREST0 去接收RMSI，如果SSB没有带CORESET0，UE就无法接收SIB1，这样的SSB就叫NCD-SSB。Redcap UE配置NCD-SSB的路径如上。

通过上面的内容描述，我们知道RedCap UE的能力肯定是要被削减的，具体的说Redcap UE的最大带宽在FR1是20MHZ，FR2是100MHZ，高于这个带宽RedCap UE是不支持的。强制支持的DRB个数是8个；CA,MRDC DAPS.CPAC IAB等功能也都不支持，毕竟没必要，能满足基本要求就行了，要啥自行车。RedCap UE相比于non-RedCap，能力被削弱具有更低的复杂度，RedCap UE强制支持的特性是在FR1 最大支持20MHZ 带宽，FR2最大支持100MHZ带宽。

如果是因为该小区不支持RedCap UE,同样的先禁止300s，然后选择其他小区尝试驻留，不支持RedCap UE的小区，就是300s后解禁，那RedCap UE还是无法驻留的。值得注意的是如果这个IE 在SIB1 中没有配置时，RedCap UE就认为这个小区是barred的状态，也就是这个小区不支持RedCap UE。当然这些IE值针对RedCap UE,其他UE 可以忽略，设置为barred时，则认为该小区分别对应1Rx/2Rx branches的RedCap UE 是barred的状态。

由于short I-RNTI 没有足够的比特，short I-RNTI 可能对应多个full I-RNTI。正常的UL-CCCH总共也就是48bit, 但是这样就意味着只能使用short-I-RNTI了, 24bit的这种短I-RNTI, 可能会让new gNB在查找时候出现识别锚点gNB的分歧, 所以如果一个小区覆盖比较小的时候, 小站覆盖一般比较好, 可以可靠接收, 所以这个小区可以通过SIB1告诉所有UE可以使用40bit的I-RNTI, 避免查找锚点gNB的分歧。3 支持 4 位原因值。

对于R17中的SDT ，也用于在 RRC_INACTIVE 中启动SDT；当上层或AS要恢复suspend的 RRC 连接，例如要响应RAN paging或者在UE处于RRC_INACTIVE状态时触发RNA update的场景，就要发起RRCResumeRquest；网络侧让UE进入RRC INACTIVE state时，会通过RRCRelease->suspendConfig带下来RRC INACTIVE state中的配置，这里会带下来fullI-RNTI以及shortI-RNTI；

NR中，PSS/SSS 和PBCH总是绑定的，因此也称为SSB block。频域由下往上，第121个SC（k = 120）的中心频率，就是SSB的GSCN对应的SSREF（同步参考频率）的出处如上，同步栅格映射到SSB 的RE位置是10个PRB的位置，然后指向RE index 0，即第121个子载波的中心频率；UE获得N_offset_GSCN后，即可结合当前SSB的GSCN推算下一个SSB的GSCN =N_Reference_GSCN（当前SSB的GSCN） + N_offset_GSCN。