5G RedCap在共存场景下的带宽挑战与专属初始上行BWP解决方案

RedCap的应用场景广泛，不仅包括固定的用户设备（UE），也包括有移动性需求的UE。但在应用初期，网络中RedCap UE的数量较少，考虑到成本等因素，运营商可能不会为RedCap搭建专网。因此，RedCap UE需要接入现有网络，和 non-RedCap UE（即不支持RedCap特性的UE）在网络中共存。

在标准设计上，一方面需要分析RedCap UE对网络和non-RedCap UE的影响；另一方面，也需要分析RedCap UE在共存场景下遇到的问题，从而确定需要为RedCap UE做哪些增强。

1. 共存场景下，RedCap UE对网络和non-RedCap UE的影响

现有技术中，基站在系统消息中，为UE配置初始上行BWP（Initial UL BWP）和初始下行BWP（Initial DL BWP），用于随机接入过程、寻呼等信息的传输。

FR1 non-RedCap UE可支持的最大带宽为100MHz，所以，基站可以将初始BWP的带宽，配置在载波范围内的任意位置，配置为符合协议规定的任意大小。

当网络中存在RedCap UE时，基站为了保证上下行传输信号在UE支持的带宽范围内，需要限制配置：初始上/下行BWP <= RedCap UE支持的带宽范围，即在FR1时，不大于20MHz。

但是这样，也就限制了non-RedCap UE的资源配置，降低了频率分集的增益。随着网络中RedCap UE数量的增加，网络中non-RedCap UE的性能也可能受到影响。

例如，在NR R15/R16标准中，初始接入过程中，下行控制信息在CORESET 0传输，而CORESET 0可支持同时传输的下行控制信道候选数量有限。

如果同时需要接入网络的UE数量，远超过控制信道承载的信息数量，就会导致部分UE接入失败或接入时延增加。

再例如，NR R15/R16标准规定的随机接入前导序列最多有64个，随着同时接入网络的UE数量的增加，不同UE选择相同随机接入前导序列而产生碰撞的概率就会增加。

上述内容总结如下：
引入RedCap UE会对传统网络造成两方面影响：

• 限制配置灵活性：为兼容RedCap UE较小的带宽（FR1为20MHz），基站需将小区公共的初始BWP限制在较窄带宽内。这使得能力更强的non-RedCap UE（支持100MHz）无法充分利用大带宽和频率分集增益，性能受限。
• 加剧公共资源竞争：RedCap UE与non-RedCap UE共享有限的公共资源池（如控制信道、前导序列）。随着RedCap UE数量增加，所有终端接入时的冲突、失败概率和时延都可能增加，影响网络整体容量。

因此，应该允许基站可以根据网络容量、调度策略等，合理分配网络资源给RedCap UE及non-RedCap UE。

2. RedCap UE在共存场景下遇到的问题

下面以FR1为例进行描述。标准设计的原则是：最大可能地复用R15/R16的设计。

因此，在RedCap工作项目WI的初期，便形成了如下结论：

• 支持RedCap UE在带宽允许的情况下，与non-RedCap UE 共享SSB和CORESET 0。
• 当non-RedCap的初始下行BWP带宽 <= RedCap UE带宽时，RedCap UE可以使用相同的初始下行BWP。
• 当non-RedCap的初始上行BWP带宽 <= RedCap UE带宽时，RedCap可以使用相同的初始上行BWP。

在连接态配置的非初始上行或下行BWP，是基站针对每个UE独立配置的，因此在配置时，限制其带宽 <= RedCap终端的最大带宽。

但是，对于初始下行和上行BWP，当RedCap与non-RedCap UE在同一小区共存时，情况会有所不同。这是由于初始下行和上行BWP，均是小区级别统一配置的。

先看初始下行BWP。在初始接入过程中，FR1 RedCap UE支持的最大带宽为20MHz。即使在SIB1中配置了初始下行BWP，所有UE仍会保持CORESET 0监听PDCCH，直到RRC连接建立。而CORESET 0的带宽不会超过20MHz，因此，不会出现控制信道监听失败或超出终端能力的频域冲突，在初始下行BWP上没有共存问题。

对于初始上行BWP则不然。初始上行BWP是在SIB1中进行配置的，相应的PRACH配置也包括在SIB1中。初始上行BWP可以在随机接入过程中使用，而non-RedCap UE的初始上行BWP带宽可以超过20MHz。

如果RedCap UE复用non-RedCap UE的初始上行BWP，将产生一系列的共存问题，包括RACH、Msg3、PUCCH等的传输带宽均可能超过RedCap的最大带宽。

2.1 RACH的共存问题

RedCap UE支持的最大信道带宽为20MHz，意味着这类UE在初始接入阶段和连接建立之后，均只能工作在最大20MHz的带宽范围内。

按照NR R15/R16协议，网络可以为non-RedCap UE配置一个大于20MHz的初始上行BWP及相应的PRACH资源。

当RedCap UE和non-RedCap UE在同一个网络中共存时，基于上表的计算，在基站配置了8个频分复用（FDM）的随机接入信道机会（RO）的情况下，RO带宽可能大于RedCap UE带宽的20MHz，这将导致对应不同SSB索引的RO，无法位于同一个UE的20MHz带宽内，即终端支持的带宽范围不能包括所有的RO。

为了解决上述问题，标准中讨论了如下一些解决方案。

选项1：采用RF调谐方式
当UE发现其选择的PRACH资源不在当前工作带宽范围之内时，可调整射频中心频点，使带宽内包含该PRACH资源。但RF调谐的时间，可能导致需要延长PRACH到随机接入响应（RAR，即Msg2）的时间。另外，频繁的调谐也不利于终端复杂度和能耗的降低。对于TDD系统，如果下行不随上行进行射频调谐，还会导致上下行中心频点不能对齐。

选项2：为RedCap终端配置专属的初始上行BWP
为RedCap终端配置专属（独立）的初始上行BWP及相应的PRACH资源，以保证随机接入资源始终位于RedCap终端的带宽内。标准的讨论包括：引入一个还是多个专属的初始上行BWP；TDD系统可能会存在上行BWP和下行BWP中心频点不对齐的情况；是否为RedCap配置专属的PRACH资源；配置专属资源后，gNB处理复杂度增加等。

选项3：限制gNB的配置
限制PRACH的序列长度，或限制频分复用的RO的数量等，以保证频域上RO的带宽之和不大于RedCap终端支持的最大带宽。但在共存时，这种方式会导致PRACH的容量受限，增加non-RedCap终端随机接入冲突的概率。

选项4：对RedCap终端进行专属的PRACH配置
例如，对RedCap终端进行专属的PRACH配置，可以很好地解决PRACH资源超出RedCap带宽的问题。但有些公司认为，专属资源的配置增加了上行资源开销，导致资源利用效率下降；同时，增加了gNB资源分配和处理的复杂度。该选项比选项2的灵活性差。

上述问题和解决方案的讨论前提，是出现了网络为non-RedCap UE配置的初始上行BWP带宽大于RedCap UE的最大带宽的场景，因此，标准需要先明确这种场景是否存在。

3GPP RAN1 104b次会议讨论了初始接入阶段及初始接入之后，是否允许网络中该场景的出现，讨论中出现如下三种选项。

• 选项1：允许以上场景出现，并且RedCap终端可以和non-RedCap终端使用相同的上行BWP，即RedCap可以支持工作在初始上行BWP带宽大于其最大带宽的场景。
• 选项2：允许以上场景出现，但是网络要为RedCap终端配置一个专属的初始上行BWP，以保证其初始上行BWP带宽不大于RedCap终端的带宽。
• 选项3：不允许以上场景出现，即RedCap终端不支持工作在初始上行BWP带宽大于其最大带宽的场景。

选项1意味着终端可能需要采用RF调谐的方式工作。选项2易于实现，通过配置专属的BWP，既不会限制non-RedCap终端的初始上行BWP带宽，又保证了RedCap终端的工作带宽在其最大带宽范围之内。选项3通过限制RedCap终端与non-RedCap终端共存时的网络配置，也能保证不会出现RedCap终端工作在BWP带宽超出其最大带宽的场景。但这种方式为网络带来了不必要的限制，尤其是在现网中，通常网络部署已经存在大量的non-RedCap终端，形成了相对应的参数配置，如果因RedCap终端的引入而改变网络的参数配置，会对网络产生较大影响，所以不推荐这个选项。

从上述解决方案的选项和对场景支持的选项中可以看到，解决方案及场景的选项1和选项2之间存在一一对应关系，因此，这些问题在后续进行了统一讨论。

由于RF调谐的方式对终端的影响较大，同时也涉及调谐时间对上下行调度、反馈时隙偏移量等的影响，因此，最终场景选项2在RAN1 105次会议上获得通过，即在初始接入期间及初始接入之后，都允许non-RedCap终端的初始上行BWP带宽大于RedCap终端的最大带宽。

这次会议上对于解决共存问题的解决方案，也形成了工作假设：在初始接入期间和初始接入之后，针对网络为non-RedCap终端配置的初始上行BWP带宽大于RedCap终端最大带宽的场景，基站应为RedCap终端配置一个不大于其最大带宽能力的专属初始上行BWP。

工作假设是在3GPP会议讨论中一种获得大部分公司同意，但尚存在一些争议的结论形式，通常会在接下来的会议中进行确认。

在专属BWP的讨论过程中，有公司从运营商的角度，还提出一种负载分流的场景：即使non-RedCap终端的初始BWP带宽不大于20MHz，考虑到空闲态的终端均工作在以CORESET 0带宽定义的初始下行BWP上，且SIB1消息、寻呼消息均会在该BWP上发送，同时non-RedCap终端的初始接入也需要在初始上行BWP上进行；当两种类型终端共享初始上行或者下行BWP时，有可能出现初始接入及传输的拥塞，因此，建议将专属BWP作为一种容量扩展和分流的方案。

这种场景在RAN1 105次小组会上形成了相应的工作假设：在初始接入期间和初始接入之后，在non-RedCap终端的初始上行带宽不大于RedCap终端最大带宽的场景下，网络也可以为RedCap终端配置一个专属的初始上行BWP。

总之：

• 对于网络配置的non-RedCap终端的初始带宽大于20MHz的情况，网络会为RedCap终端配置专属的初始上行BWP。
• 对于网络配置的non-RedCap终端的初始带宽不大于20MHz的情况，网络也可以为RedCap终端配置专属的初始上行BWP。

相应地，如何使不同SSB索引对应的RO，均位于终端可支持的最大带宽范围内的问题，也可以通过配置专属的初始上行BWP解决。标准规定，在专属初始上行BWP上的RO，可以是为RedCap配置的，也可以是RedCap终端与non-RedCap终端共享的。

另外，在标准讨论的过程中，也出现过其他观点。如不同RedCap终端，甚至不同SSB索引关联的RO，对应的初始上行BWP不同。

如上图所示，当频分复用（FDM）的RO的总带宽超过了RedCap终端的最大带宽，通过将初始上行BWP与RO关联的SSB索引建立关系，如SSB0、SSB1、SSB2、SSB3对应初始上行BWP1，而SSB4、SSB5、SSB6、SSB7对应初始上行BWP2。终端通过选择不同的SSB索引，来确定不同的初始上行BWP，从而实现与传统终端PRACH资源的复用。

当然，每个SSB索引也可以对应不同的初始上行BWP，即8个SSB对应8个不同位置的初始上行BWP。但最终为了简化设计，确定所有的RedCap终端，共享一个公共的专属初始化上行BWP。

小结：
标准设计首要原则是最大化复用现有协议。因此，当普通终端初始BWP带宽未超过RedCap终端能力（≤20MHz）时，支持共享相同的BWP。真正的共存问题只出现在：普通终端的初始上行BWP带宽 > 20MHz，而RedCap终端试图复用时。

下行初始BWP因依赖CORESET 0（带宽≤20MHz），无共存问题。矛盾集中于上行初始BWP：若RedCap复用普通终端的大带宽上行BWP，则RACH（随机接入信道）、Msg3 PUSCH、PUCCH等一系列上行传输的带宽均可能超出其能力范围。

3GPP会议最终达成共识：当普通终端初始上行BWP > 20MHz时，网络必须为RedCap终端配置专属初始上行BWP（带宽≤20MHz）。即使普通终端初始上行BWP ≤ 20MHz，网络也可以（可选）为RedCap配置专属BWP，以作为负载分流和容量扩展的手段。最终，为简化设计，确定所有RedCap终端共享一个公共的专属初始上行BWP。

2.2 初始接入阶段PUCCH和PUSCH的传输问题

除了PRACH是在初始上行BWP中传输的，Msg3/MsgA PUSCH（在两步RACH流程中，在发送PRACH之后，UE会相应地在有效的PUSCH时机上发送PUSCH，这个PUSCH称为MsgA PUSCH）的传输也是基于初始上行BWP进行调度的。

因此，在网络为non-RedCap终端配置的初始上行BWP带宽大于RedCap终端最大带宽的情况下，如果RedCap终端与non-RedCap终端共享相同的初始上行BWP，则会在如下问题：

1. RedCap的上行Msg3/MsgA PUSCH调度传输，有可能超出RedCap终端的最大带宽。
2. 现有协议规定，PUCCH在初始接入之前需进行跳频传输，两跳传输的位置分别在初始上行BWP的两端。因此，会出现PUCCH传输带宽超出RedCap终端最大带宽的情况。

为保证初始接入阶段用于传输Msg4/MsgB（对应于两步RACH过程中UE发送完PRACH及PUSCH之后接收的基站响应信息）的HARQ反馈的PUCCH及Msg3/MsgA PUSCH，均位于RedCap终端的最大带宽内，有如下4种选项：

选项1：RF调谐
对于PUCCH传输，两跳传输之间需要进行调谐时，一些用于传输PUCCH的符号会被用于调频而无法用于传输，从而导致PUCCH的解调性能变差，PUCCH的覆盖率降低。此外，调谐需要占用的符号数量也需要进行标准的讨论和定义。类似地，RF调谐的时间，需占用终端进行PUSCH传输的时间，由此可能会导致PUSCH传输解调性能的降低。

选项2：为RedCap配置专属的初始上行BWP
选项2的问题是专属资源需要在SIB1中进行指示，这会导致SIB1开销增加；网络需要维护两个初始上行BWP（RedCap和non-RedCap各一个）；TDD系统可能存在上下行BWP中心频点不对齐情况，以及上行传输资源的碎片化问题。但随着讨论的深入，各公司逐渐认为较其他方案带来的问题，这些问题相对容易解决。

选项3：为RedCap终端引入单独的PUCCH、Msg3/MsgA PUSCH的配置或者指示
选项3的灵活性比选项2差，也同样存在指示开销的问题。另外，基站需要提前识别出RedCap终端进行匹配的指示，也需要为RedCap终端定义新的跳频模式。而且，选项3也存在资源碎片化等问题，最终未被标准采纳。

选项4：通过基站配置
例如，限制初始上行BWP的带宽总是不大于RedCap终端的最大带宽，或者限制Msg4/MsgB HARQ反馈和Msg3/MsgA PUSCH的频域资源位置及调度的资源数量等。为了保证RedCap终端的正常接入，而限制为non-RedCap终端配置的资源，有可能影响non-RedCap终端的性能，降低网络的容量。另外，该选项同样存在上行PUSCH资源碎片化的问题。因此，这种方式也不被推荐。

由于标准先讨论了RACH的问题，并在RAN1 105次会议上形成结论：当non-RedCap终端的初始BWP带宽大于RedCap终端的最大带宽时，网络为RedCap终端配置一个专属的初始上行BWP。因此，多数公司倾向于采用与RACH一致的设计来解决该问题。

最终在RAN1 105次会议上，通过工作假设：为保证Msg4/[MsgB]的HARQ反馈和Msg3/[MsgA]的PUSCH传输，位于RedCap终端的最大带宽内，支持为终端配置一个带宽不大于其最大带宽的专属上行BWP。

小结：
当RedCap终端共享普通终端的大带宽初始上行BWP时，其Msg3/MsgA PUSCH的调度和PUCCH的跳频传输都可能超出自身带宽能力。

为解决此问题，标准会议讨论了四种方案：

• RF调谐：会损害性能并增加复杂度。
• 配置专属初始上行BWP。
• 为RedCap单独配置PUCCH/PUSCH：灵活性差，未被采纳。
• 限制基站配置：会牺牲普通终端性能。

最终，会议决定采用为RedCap配置专属初始上行BWP的方案。这与解决RACH问题的方案一致，确保了RedCap终端的正常接入。

2.3 资源碎片化

在为RedCap配置专属的初始上行BWP的解决方案，以及引入RedCap专属PUCCH资源配置或解读时，都提到了一个潜在的问题：RedCap可能会引起non-RedCap终端上行PUSCH资源的碎片化。

NR R15/R16协议中，初始上行BWP中可配置小区级的公共资源，用于随机接入过程的传输，具体如下。

1. 公共物理上行控制信道（common PUCCH）：RRC配置之前，承载下行反馈信息的PUCCH资源，使用的是SIB中配置的小区级公共资源；而且，承载Msg4/[MsgB]的HARQ反馈的PUCCH，按照NR R15/R16协议，默认采用跳频方式传输。因此，跳频传输中两端的频域资源，分别位于初始上行BWP的两端。
2. 物理随机接入信道（PRACH）：随机接入过程中，PRACH资源是网络为终端设备配置的周期性资源，其频域资源也在初始上行BWP范围内。
3. 物理上行共享信道（PUSCH）：网络对PUSCH的调度，可在初始上行BWP内灵活分配资源的位置。

峰值速率是终端性能的关键指标。在FR1中，non-RedCap UE支持的最大信道带宽可达100MHz，因此可支持较高的峰值速率。

RedCap UE和non-RedCap UE共存时，RedCap UE发送的上行信号可能导致non-RedCap UE上行发送的资源产生碎片化问题。例如，当RedCap UE和non-RedCap UE共享相同的载波资源时，如果RedCap UE的BWP被配置在载波的中间位置，就可能导致出现如图2-2所示的non-RedCap UE的连续载波资源被分割成多段的情况。

最严重的情况，non-RedCap UE可分配的最大连续资源，会从100MHz降低到40MHz，峰值速率降低60%。

其中一种解决方案，是将专属初始上行BWP配置在载波的边缘位置，这样能够留给non-RedCap终端尽可能连续的频域资源。

但如前所述，初始接入阶段的PUCCH是默认采用跳频传输的，即只要有用户进行初始接入，那么在专属初始上行BWP的两端都会存在PUCCH的传输，此时即使RedCap终端仅占用了少量的资源进行上行数据传输，由于载波的资源被位于专属初始上行BWP靠近载波一侧的跳频PUCCH分割，因此，专属初始上行BWP内的资源无法连同其他位置的上行资源一起，被只支持连续资源调度的non-RedCap终端使用。

资源碎片化的问题，是随着专属初始上行BWP的引入而出现的。既然PUCCH跳频导致了资源的碎片化，最直观的解决方式是把跳频功能去使能，但不一定在所有场景下都有去使能的需求。例如，当前网络中，终端如果在上行高速率传输时，均切换到OFDM方式下，则此时不受连续资源调度的限制。

因此，考虑到PUCCH跳频可以获得频域分集增益，增强PUCCH的检测性能，提升上行PUCCH覆盖等优势，在RAN1 106b次会议上形成会议结论：在为RedCap配置了专属初始上行BWP的情况下，网络可以使能或者去使能在专属初始上行BWP内的PUCCH的时隙内跳频，该方式适用于RedCap的Msg4/MsgB的HARQ反馈的PUCCH传输。

在标准讨论的后期，还涉及是否将去使能PUCCH跳频的功能，应用到RedCap UE和non-RedCap UE共享的初始BWP内。但绝大多数公司都认为，当RedCap与non-RedCap共享初始BWP时，应该遵守传统终端的方式，即采用跳频传输。因为共享的初始BWP带宽，一定不大于RedCap终端的最大带宽，且non-RedCap终端会在其中进行PUCCH跳频传输，所以RedCap终端的存在，并不会引入额外的PUSCH资源碎片。

在RAN1 108次会议上达成会议结论：去使能RedCap终端的公共PUCCH跳频传输，仅适用于专属初始上行BWP，而不适用于共享的初始上行BWP。

在专属上行BWP上，去使能公共PUCCH跳频传输这一结论达成一致后，3GPP标准的制定还涉及关于PUCCH资源如何映射的问题，如下所述。

1. 所有的PUCCH资源，均映射到BWP的一侧？还是可以部分资源映射到一侧，其他资源映射到另一侧？
2. 去使能跳频后的RedCap终端的PUCCH，如何与non-RedCap终端的跳频PUCCH进行复用？

针对问题（1），多数公司认为去使能跳频的情况下，PUCCH资源应映射到专属初始上行BWP的一侧，如下图所示。

例如：当专属初始上行BWP与non-RedCap终端的初始上行BWP上边缘对齐时，16个公共PUCCH资源可以映射到专属初始上行BWP上边缘；当专属初始上行BWP与non-RedCap终端的上行BWP下边缘对齐时，16个公共PUCCH资源可以映射到专属初始化上行BWP的下边缘，由此避免了资源碎片化的问题。

标准讨论的过程中，也有公司支持将16个公共PUCCH资源分别映射到专属初始上行BWP的两侧。

如上图所示，当专属初始上行BWP与non-RedCap终端的初始上行BWP上边缘对齐时，8个公共PUCCH资源映射到BWP的上边缘，8个公共PUCCH资源映射到BWP的下边缘。该方案可以动态地确定传输PUCCH的传输资源，是在BWP的上边缘还是下边缘，增加了频谱调整增益，但也带来了潜在的PUSCH分割问题。

最终，大部分公司认为，单侧映射符合去使能PUCCH跳频传输的初衷，因此标准仅支持了单侧映射。进一步说，PUCCH资源映射到专属初始上行BWP的哪一侧，是通过系统消息块（SIB）配置的。

关于上述问题（2），主要需要解决初始接入期间的PUCCH复用问题。初始接入期间，终端可用的PUCCH格式为格式0或1。其中，PUCCH格式0的基序列，按照频域升序映射。跳频传输时同一小区的PUCCH，第一跳基序列相同，第二跳基序列相同，两跳基序列可能不同，而非跳频传输时仅使用一个基序列。跳频传输和非跳频传输时的基序列不同/不正交。

如上图所示，RedCap终端使用的非跳频PUCCH3，与non-RedCap终端使用的PUCCH1第一跳和PUCCH2第二跳占用相同的时频域资源。而按照现有协议，无法保证非跳频PUCCH3的基序列与PUCCH1第一跳和PUCCH2第二跳的基序列正交，这将导致基序列相互干扰而降低解调性能。

PUCCH格式0，通过基序列的不同初始循环移位，进行多用户复用。PUCCH格式1的基序列，按照频域升序映射，因此，也存在跳频和不跳频时基序列不正交的问题。进行时域的多用户复用，还可以在时域多个符号上配置不同的正交序列，但初始接入期间，PUCCH格式1使用的时域正交序列0，是一个全1的序列，因此不会通过时域正交序列进行复用。

连接态non-RedCap也可以去使能PUCCH跳频，非跳频PUCCH与跳频PUCCH的复用问题，可以通过配置不同物理资源块（PRB）使其在频域资源位置上正交来解决。

各公司从基序列、初始循环移位、PRB映射的角度，提出以下三种复用方法。

• 方法1：PUCCH非跳频传输时，配置2个基序列，基站指示两个基序列对应的时域位置。例如，为上图中非跳频的PUCCH3配置2个基序列，基站指示PUCCH3的两个基序列对应的起始符号分别与PUCCH1的第一跳和PUCCH2的第二跳起始符号相同，从而使两个基序列各自正交。
• 方法2：非跳频PUCCH和跳频PUCCH配置不同初始循环移位。PUCCH格式0和格式1，除了通过基序列正交方法进行复用，还可以通过配置不同的初始循环移位，使非跳频PUCCH和跳频PUCCH复用。由于初始循环移位数有限，因此可复用用户数量有限。
• 方法3：非跳频PUCCH通过不同PRB与跳频PUCCH正交。

大部分公司认为，通过调度PUCCH的频域位置足以保证非跳频PUCCH与跳频PUCCH正交，标准最终采用了方法3。

去使能Msg4/MsgB的HARQ PUCCH时隙内跳频，需要重新设计RedCap非跳频PUCCH的PRB映射位置，以保证相同小区内非跳频PUCCH与跳频PUCCH通过PRB错开，相邻小区间非跳频PUCCH与跳频PUCCH也通过PRB错开。

现有协议通过SIB1的pucch-ResourceCommon指示了16个公共PUCCH资源，用于初始接入期间和初始接入后但未配置专用PUCCH时使用。

PUCCH资源序号小于8时，第一跳PRB位置计算公式为：

第二跳PRB位置是：

PUCCH资源序号大于8时，第一跳PRB位置是：

第二跳PRB位置是：

去使能PUCCH时隙内跳频的每个PUCCH的PRB位置，可由网络配置位于专属初始上行BWP某一侧，PRB具体位置可复用现有公式得到。

小结：
引入RedCap专属初始上行BWP，带来了资源碎片化问题：PUCCH的默认跳频传输会占据BWP两端频域资源，割裂载波，从而影响普通终端PUSCH的连续资源调度与峰值速率。

为解决此问题，3GPP标准形成了两大核心结论：

• 允许禁用PUCCH跳频：在RedCap的专属BWP内，网络可配置关闭时隙内跳频，以消除资源碎片。此功能仅限专属BWP，在共享BWP中RedCap仍需遵循传统跳频规则。
• 采用PUCCH资源单侧映射：当禁用跳频后，所有公共PUCCH资源被集中配置在专属BWP的单侧（上边缘或下边缘，由SIB配置），而非分散在两侧，从而最大限度地减少对连续频域资源的切割。

此外，为确保RedCap的非跳频PUCCH与普通终端的跳频PUCCH互不干扰，标准确定通过调度不同的PRB位置（即频域错开）来实现两者间的正交复用，这是最直接有效的方案。

总结

网络中引入RedCap UE后，一方面会对原有网络和non-RedCap终端产生影响，另一方面会改进RedCap终端的工作流程。于是，在标准讨论的过程中，引入了专属初始上行BWP，以减少对传统网络及终端的性能影响，同时保证RedCap终端在共存网络中能够正常工作。

引入专属初始上行BWP有如下好处：

1. 减少上行资源碎片化的影响：如果RedCap UE的初始上行BWP，被配置在靠近载波边缘的位置，就可以最大限度减少对载波资源的切割，从而减少资源碎片化的影响。
2. 避免带宽限制：通过引入专属初始上行BWP，可以避免对non-RedCap终端的初始上行BWP带宽的配置限制，使网络能为其灵活配置大带宽资源。
3. 减少性能影响：考虑海量RedCap UE对non-RedCap UE性能的影响，尤其是对初始接入过程中的资源调度的影响，引入专属初始上行BWP，可用于分流RedCap UE在随机接入过程中需要传输的信息，避免non-RedCap UE在时延、可靠性等方面受到影响。

对这类移动通信网络底层技术细节感兴趣的开发者，可以关注云栈社区的网络/系统板块，那里有更多关于协议栈、无线接入技术的深度讨论和资源共享。

参考

[1] 黄宇红等《5G RedCap技术标准详解》
[2] https://arxiv.org/ftp/arxiv/papers/2004/2004.00761.pdf
[3] 3GPP TS 38.213 version 17.12.0 Release 17
[4] Final Report of 3GPP TSG RAN WG1 105-e v1.0.0
[5] 3GPP TS 38.331 version 17.12.0 Release 17