ModemProtocol的博客

在overview中有提到，UE可以与网络侧协商是否对能力进行临时限制，38.300中的描述如下。当MUSIM UE需要在 NW B中进行传输或接收时，NW A中处于RRC_CONNECTED状态的MUSIM UE可以将 temp UE capability restriction 或移除某个restriction的perference 告知NW A。NW A 是 NR，NW B 可以是E-UTRA 或 NR。

如果还有musim-GapPriorityToAddModList，要根据其设置每个periodic MUSIM gap的 priority，如果网络侧没有对MUSIM gap配置相关优先级信息，具体怎么操作协议上就没定，但是如果musim gap间有冲突的话，根据38.133中musim gap的描述，这种情况下musim gap的优先级实际上又是需要配置的，保守处理，periodic musim gap有冲突的话，那优先级还是要配置的。从优先级最高的gap开始，按照优先级递减的顺序依次解决冲突。

由于UE实现的限制，也可能不会这样做。对于处于RRC_INACTIVE状态的UE，只有当UE context中存在Paging Cause Indication for Voice service并且检测到触发RAN paging消息的下行数据时，NG-RAN才应在RAN paging消息中提供Voice Service Indication(RAN paging消息与接收到的DL data header中的Paging Policy Indicator的voice service相关)。

如果MUSIM UE需要与另一个USIM进行通信时，则当前USIM关联系统正在进行的业务可能会中断。从网络侧角度考虑，与当前USIM关联系统主动通信时，MUSIM UE确定需要在另一个USIM关联的系统中进行paging response或MRU过程的场景，之前spec规定中，UE可以在不通知网络的情况下，自主release当前USIM系统的RRC connection，这样对于网络侧来说就可能出现一些异常，比较明显的就是无法收到当前系统下行数据或者paging，对于网络侧的资源也会造成浪费。

eRedCap是否有在FR1降低baseband bandwidth要根据能力IEeRedCapNotReducedBB-BW-r18确定，默认情况下eRedCap UE的峰值数据速率是确定要被限制为10 Mbps。(1)FR1的最大带宽为 20 MHz。eRedCap UE 不支持 FR1 中带宽大于20 MHz 的场景。值得注意的是eRedCap UE不支持FR2和FR1 SCS=60kHz 的场景。

UE可以由NAS或RRC层配置eDRX cyclye 的T_eDRX_CN或T_eDRX_RAN。而通过Cond RANPaging 可以清楚的知道，如果有idle edrx参数，后面在进入inactive state时可能通过上述IE配置ran-extendedPagingcycle(T_eDRX_RAN)，也可能不配置T_eDRX_RAN，无论哪种情况38.304 7.1 DRX中都有考虑，当然不配置idle eDRX参数，就一定不会有extendedPagingcycle。

scs=30khz 时 N=7.5，scs=60khz时N=15，否则scs=15khz 时N=14；如上图，和deactived BWP的行为相比，在dormant BWP上 UE不用进行任何上行发送，但是还要进行一些CSI 测量，例如上报除aperiodic 外的其他CSI动作，虽然名字带dormant ，但是实际上还是不如直接deacitive 掉省电，其实最重要的还是相比于传统的MAC CE的控制方式，Scell的添加会快很多，毕竟鱼和熊掌不可兼得，要得到一些东西的前提，就是也要稍微付出点代价。

(4)在overlap 的符号上，UE要drop在set S(c_2)中的serving cell的carrier 上携带仅包括CQI/PMI/L1-RSRP/L1-SINR的aperiodic CSI的PUSCH传输以及 在serving cell c_2的carrier 上的aperiodic SRS传输（包括由于SRS-SwitchingTimeNR的高层参数switchingTimeUL和switchingTimeDL定义的UL或DL RF retuning 时间而导致的任何中断）。

为了减少使用 URLLC 服务的 TDD 操作的 HARQ-ACK 反馈的延迟，就引入了TDD 小区的PUCCH cell switching。

配置UL Tx switch时，在option1 case1中，UL 两个carrier各支持1Tx传输，此时UE在carrier 1上在1Tx 传输(carrier 2上不能进行UL传输)，此后可以swith到case 2 上，即在carrer 2上进行2tx(UL MIMO)或1 tx传输，而不在carrier 1上进行UL传输。R17对UL CA UL tx switch进行了增强，对两个carriers的情况，支持2Tx-2Tx的switch，根据option的不同支持的场景如上。

5G 载波属于高频段，相同距离下， 频率越高则衰减得越厉害，因而会存在5G 小区覆盖受限的问题。NR中最值得关注的就是UE 的上行覆盖问题。于是，就提出了 SUL 技术，通过在一个NR小区配置一个低频段的SUL载波来扩展实网中的上行覆盖范围。即SUL/NUL +DL。如果 UE 不支持 SUL 或者不支持 NR 小区配置的 SUL 频段时，那 UE 只能在 NUL 载波上发起接入。下面是spec中相关内容的介绍。

如果将注册区域覆盖的区域设置的很大，可以稍微解决mobility registration updating的问题，但是面临的另一个问题就是注册区域内大量UE 的paging问题，所以这种方案注册区域的大小和paging容量要进行一定的权衡。UE在接收到注册接受消息后，应删除其旧的TAI列表并存储接收到的TAI列表。soft switch option指一个cell 广播 more than one TACs per PLMN，根据实际情况，会在小区的系统信息中添加了新的 TAC，并删除旧的TAC。

在feeder link switchover时，受影响的UE上下文在两个gNB之间的传输是基于NG或Xn的切换来执行的，具体取决于gNB的具体实现以及 NTN控制功能提供给gNB的配置信息。列表中的每颗卫星的ID、通过卫星提供服务的 gNB 的小区列表以及卫星的星历数据等。这里主要看下feeder link switchover的内容，先看下38.821中有关的feeder link switchover中的最初研究过程，其实38.821中的这部分内容，R17的协议中基本没用到，但是还是值得看下。

进而在需要高吞吐量的场景，可以通过disable HARQ的方式，改善上述情况；下面分别看下这两个参数的作用。对于DL SPS场景，有配置downlinkHARQ-FeedbackDisabled时候(对应NTN场景)，DL harq feedback有enable的时候，首先HARQ-RTT-TimerDL-NTN =HARQ-RTT-TimerDL+UE lastest avaliable UE-gNB RTT，然后在相关HARQ-ACK发送完的第一个符号开启HARQ-RTT-TimerDL-NTN。

UE在接收到CHO配置之后保持与源gNB的连接，并开始评估候选小区的CHO执行条件，如果至少一个CHO候选小区满足相应的CHO执行条件，则UE从源gNB分离，对所选候选小区应用存储的相应配置，同步到该候选小区，并通过目标gNB发送RRCReconfigurationComplete消息来完成RRC切换过程，在成功完成RRC切换后，UE释放存储的CHO配置。除NTN频段外，UE应分别为所有FDD-FR1频段、所有TDD-FR1频段、所有TDD-FR2-1频段和所有TDD-FR2-2频段设置一致的能力值。

serving卫星相对于地球上UE的会发生移动，因而serving 卫星辅助信息(satellite ephemeris and common TA parameters)会涉及一个有效性的问题，所以38.331中有增加一个T430用于保证UE可以持续获得有效的serving 卫星的辅助信息，简单的说是通过T430控制UE获得SIB19得到有效的serving 卫星辅助信息，以便保证UE获得的NTN辅助信息始终处于有效期。k_mac 是配置的偏移量，需要大于或等于 RP 和 gNB 之间的 RTT。

NTN网络架构可以简单将天上的卫星看作基站的功能，UE和卫星间的service link通过NR实现，卫星和gateway间的Feeder link 通过3GPP/non 3GPP的 无线接口实现，gateway和Data 网络连接；用于 PWS 的小区标识等。两种架构基本介绍完了，下面看下R17 38.300中相关描述，如之前所述R17主要侧重对于GEO/LEO的标准化支持，重点是透明payload，即卫星充当射频中继器的方式，gNB作为网关的一部分位于地面，而Uu是两个馈线中使用的接口和服务连接。

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

sdt-SearchSpace的配置路径如上图，PDCCH-ConfigCommon->sdt-SearchSpace，sdt-SearchSpace配置对应的是Type1A-PDCCH CSS set，用于Pcell上C-RNTI或CS-RNTI 加扰的CRC的DCI format的传输。如上图是CG-SDT配置的SSB结构图，主要与sdt-SSB-Subset有关系，sdt-SSB-Subset配置结构和SIB1中的ssb-PositionsInBurst一样，且是其子集。，以进行PDSCH接收。

1 如果UE有进行带有CCCH消息的CG-SDT的初始传输之后，但是还没有收到C-RNTI加扰的PDCCH，此时要进行CG-SDT初始传输的重传，如果用于重传的configured UL grant对应的SSB与CG-SDT的初始传输的SSB相同，就选择该SSB，向下层指示configured UL grant对应的SSB index，并认为当前配置的configured UL grant有效。对于CG-SDT有2个RRC配置需要注意，cg-SDT-CS-RNTI代表用于CG-SDT重传的CS-RNTI；

在回复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消息)。在SDT过程失败后，UE需要转换到RRC_IDLE。

UL full power Tx(ULFPTx Mode)，上行满功率传输，也是R16版本的一个增强，R15由于受限于codebook和PUSCH功率控制，某些情况下无法达到满功率传输（例如26dBm），这就影响了上行覆盖和速率。R16对其进行了增强，因为并不是在所有情况下，每个 PA都一定能达到终端的功率等级所对应的最大输出功率，针对具有不同功放（PA）能力的终端设计了不同的上行满功率传输方案（不同的ULFPTx Mode），可以使得上行双发的终端在小区边缘以上行满功率（ 26dBm）发送，相比 R15

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

在同时配置pdcch-SkippingDurationList和searchSpaceGroupIdList-r17时，可能会切换到非SSSG 0进行PDCCH 监听，这时候切换的timer开启，后面又要进行PDCCH monitoring skip的动作，如果timer先超时，此时UE仍在PDCCH skipping期间，UE要在PDCCH skipping duration 超时的时隙之后，才能进行SSSG index 0的PDCCH 监听。配置的duration值多于1个时，对应 2bits。

密集的PDCCH 监测可以减少gNB在LBT成功后进行DL传输的延迟；(3)如果UE在进行group index 1的search space set 的PDCCH监听，此时根据searchSpaceSwithcTimer的值开启的timer超时，超时对应的时隙是X，则UE要在时隙X至少P_switch符号后的第一个时隙的起始位置开始group index为0的search space set PDCCH监听，停止group index 1 的search space set 的PDCCH监听。

Idle/Inactive状态的UE在DRX周期结束时要醒来进行SSB同步，在SSB multi beam的情况下，UE的唤醒时间会比较长，不利于省电，因而R17支持给idle/inactive状态的UE配置TRS，UE在接收paging前，通过TRS进行同步，这样相比与SSB同步的方式，能够更长的休眠时间。

在开始之前，先总结下PEI 的整体流程，网络侧要做的就是将UE分组，然后将PEI和UE的PO 进行关联，进而达到通过PEI控制PO的目的；如果N_PEI_PO<Ns(1个PF中的PO 数)，从参考帧开始到与PO index i_PO相关联的DCI format 2_7的第一个PDCCH监视时机开始的之间的符号数是firstPDCCH-MonitoringOccasionOfPEI-O 提供的 N_S/(N_PEI_PO ) 个值的第(⌊i_S /(N_PEI_PO)⌋+1)个值。

通过上面的内容描述，我们知道RedCap UE的能力肯定是要被削减的，具体的说Redcap UE的最大带宽在FR1是20MHZ，FR2是100MHZ，高于这个带宽RedCap UE是不支持的。但是到底什么是redcap UE？可能有人对于NCD-SSB的含义不太清楚，这里简单说明下，CD-SSB就是指有关联RMSI(SIB1)的SSB，即在小区搜索过程中通过SSB带的COREST0 去接收RMSI，如果SSB没有带CORESET0，UE就无法接收SIB1，这样的SSB就叫NCD-SSB。