NR PUSCHconfigured grant Type1 or Type 2

Posted 2022-10-25 modem协议笔记

目前微信更新稍快，欢迎关注同名“modem协议笔记”

这篇看下PUSCH，上下行调度主要通过PDCCH DCI 动态分配时频域资源的方式进行上下行传输，除此之外，还可以通过提前配置grant的方式进行传输，对于PUSCH ，对应的就是configured grant type 1和2的传输；对于PDSCH ，对应的就是SPS-config的调度方式，这里先看下configured grant type 1和2的传输。

下面分别梳理下各个specification 中的相关内容，进一步看下configured grant type 1和2的传输。

先看38.214中的内容。

PUSCH 可以由DCI 0_0/0_1/0_2动态调度，也可以根据是否有提前分配好UL grant的情况分为configured grant Type1 or Type 2 的传输。 configured grant type 1和type 2根据IE ConfiguredGrantConfig中字段rrc-ConfiguredUplinkGrant进行区别，type1 传输网络端会配置好时频资源（rrc-ConfiguredUplinkGrant提供），UE不用等待DCI 进行激活，直接可以进行传输；type2 的传输 因为没有rrc-ConfiguredUplinkGrant提供的具体时频资源，所以在收到ConfiguredGrantConfig(没有包含rrc-ConfiguredUplinkGrant)后，还需要收到有限DCI （CS-RNTI加扰）激活，根据DCI 信息确定上行grant 后，才能进行传输。 

ConfiguredGrantConfig详细配置如下图

从上图中的参数periodicity可以看出，UL configuration grant 传输周期最小为2个符号。假定子载波间隔为15KHz，那么1 slot = 14 symbol，如果configured grant 传输周期配置为2 symbol，则在1 slot中UE会进行7次上行传输，如果周期配置为14 symbol，则UE会在每个上行slot都会进行上行传输。configured grant 传输一旦配置被激活，UE就会一直按照周期进行上行传输(除非去激活)，所以不会像动态分配上行资源一样，每次都要根据DCI内容进行调度，因而configured grant 传输这可以节省UE发送SR、BSR以及gNB通过上行DCI进行资源指示的空口传输时间，configured  grant 传输较适应于低时延场景。

如开头所述rrc-ConfiguredUplinkGrant用于给CG Type 1传输提供UL grant，如果此项缺省，则说明是CG type 2,此时需要根据CS-RNTI加扰的DCI 获得UL grant后 再进行传输。

timeDomainAllocation:对于type 1 用于指示UL grant 的SLIV和PUSCH mapping type, 是必须要配置的。

FrequencyDomainAllocation: 18bit 用于指示频域RB的分配情况。

ConfiguredGrantConfig用于配置ConfiguredGrant type1和type2的UL传输，type1和type2的UL传输不需要DCI动态调度，type1的UL grant 由RRC参数(rrc-ConfiguredUplinkGrant)配置,而type2的UL grant通过接收CS-RNTI加扰 DCI激活后才能开始传输。  

用于激活configured grant type 2的DCI是有具体要求的，相关内容集中在38.213 10.2，下面就来看下。

UE需要根据DCI field的内容确定是要激活还是要release掉DL SPS assignment/configured UL grant Type 2。当UE收到CS-RNTI加扰的DCI，此时如果enable的TB NDI=0，DFI=0（如果有的话，其中DFI 只可能在 DCI 0_1 中 包含，其他DCI 不会带这个），且DL sps assignment PDSCH-to-HARQ_feedback timing indicator所带的value 不是无效值（根据dl-DataToUL-ACK-r16的配置）；当满足上述条件时，UE要根据38.213 Table 10.2-1(激活)和Table 10.2-2(release)中规定的相关field 的value去判断 此时的DCI 是要激活还是释放掉DL SPS assignment/configured UL grant Type 2 的配置，当然再未激活之前要先考虑激活的情况，激活后才要考虑去激活；具体DCI field 取值情况如下。

当网络端给UE配置了多个DL SPS assignment/configured UL grant Type 2 配置时，会带 ConfiguredGrantConfigIndex用于指定配置对应的index；当要激活某个配置时，DCI 中的HARQ process number 的value对应的就是要激活的ConfiguredGrantConfigIndex的值，此场景DCI RV field对应的情况参考38.213 Table 10.2-3， 如下表

(ConfiguredGrantConfigIndex同rrc-ConfiguredUplinkGrant 配置结构一样，是ConfiguredGrantConfig下的一个IE，当一个BWP下有多个UL configured grant 配置时，ConfiguredGrantConfigIndex就用于区分不同的UL configured Grant 配置，当激活或去激活时，通过索引确定对应的配置。)

当UE有被配置configuredGrantConfigType2DeactivationStateList/sps-ConfigDeactivationStateList时，DCI中的HARQ process number field用于指示要release掉的配置的index，例如HARQ process number =0,则要relase掉configuredGrantConfigType2DeactivationStateList 中的第一个 entry对应的配置；如果没有配置configuredGrantConfigType2DeactivationStateList/sps-ConfigDeactivationStateList，DCI中的HARQ process number field 就对应ConfiguredGrantConfigIndex，根据ConfiguredGrantConfigIndex取release掉对应的配置。DCI 中的相关field要满足38.213 Table 10.2-4中的要求 才能算作有效的release 命令。

当根据上述提及的要求及4个table中的内容，UE认为DCI 信息是有效的激活或者release 命令，UE才能进行对应的操作，否则就忽略对应的DCI。 

下面看下重复传输的场景，重复传输可以提高传输的可靠性，可带来增益，在eMTC和NB-IoT中已采用重复的形式，以便带来增益。在PUSCH  configured grant type 1和2的传输场景也支持重复传输，其重复传输的次数通过IE ConfiguredGrantConfig中type 1和type 2公用参数repK进行配置。

下面的内容适用于CG type 1和2中应用PUSCH repetition type A和B的场景，因为PUSCH repetition type A和B的内容重复所以就没有分开截图，至于PUSCH repetition type A和B有什么区别，下一篇再说。

IE ConfiguredGrantConfig中参数repK和repK-RV定义了传输TB的重复次数K，及应用于重复的冗余版本模式。如果在ConfiguredGrantConfig中没有配置参数repK-RV，则configured grant 上行传输的RV应设置为0，否则，重复传输中的第n(n = 1,2,...,K)次传输时机，其所关联的RV与配置的RV序列中的(mod(n-1,4)+1)th­值所关联。如果参数startingFromRV0 为off, TB的初始传输只能对应k次重复传输的第一次传输时机，否则就要参考配置的repK-RV具体value进行区分，RRC层参数repK-RV可指示三种RV模式：

       - 如果配置的RV序列是0,2,3,1，则TB的初始传输就要从K次重复的第一个传输时机开始传输；

       - 如果配置的RV序列是0,3,0,3，则TB的初始传输的可以起始于K次重复传输的任意一个关联了RV = 0的传输时机；

       - 如果配置的RV序列是0,0,0,0，若K = 8，则TB的初始传输的可以是K次重复内除最后一个传输时机的其他任意传输时机；若K = 2、4，则TB的初始传输的RV可以起始于K次重复的任意传输时机。

 对于任何RV序列，重复传输应在发送K个重复传输之后终止，或者在周期P内的K个重复传输的最后一个传输时刻终止，或如果重复传输的开始符号与DCI format 0_0或0_1/0_2调度具有相同HARQ进程的PUSCH的符号出现overlap 也要终止。除此之外，当收到DCI 0_1，DFI flag为1时，UE也收到了正在传输TB的HARQ ACK，这时候也要停止这个TB的重复传输。

网络端配置的K次重复传输的持续时间不能大于周期P的持续时间，如果一个时隙内可用于PUSCH 传输的符号数小于K次重复传输时间，UE就要取消这次传输。

    对于configured type 1和type 2 PUSCH传输，当UE配置的参数repK > 1，但没有配置cg-nrofSlots和cd-nrofPUSCH-Inslot参数, UE 应在K个传输时机上重复发送相同TB K次，其中K个传输时机位于一个周期内连续的K个时隙，每个时隙的符号分配情况也是相同的；否则就要根据配置cg-nrofSlots和cd-nrofPUSCH-Inslot参数进行传输,。如果UE确定某个时隙上被配置用于发送PUSCH的符号为下行符号，则UE取消在该时隙上的PUSCH传输。

最后再看下38.321 5.8.2中的内容

不需要DCI 动态提供UL grant 的上行传输有两种，configured grant type 1由RRC参数提供UL grant ；configured type 2需要根据L1 DCI 确定何时激活传输及再何时deactivate对应配置。configured type 1/2是BWP 级别的配置，可能会存在一个BWP 内同时激活多个configured type 传输的情况。对于configured type 2，激活和去激活是独立的；相同的BWP， MAC entity也可以同时配置configured type 1和2的传输。

网络端在configured grant type 1和2传输时，必须要配置的参数如上。

当在configured uplink grant 场景有配置重传时，需要配置参数cg-RetransmissionTimer,这个参数的值用于初始化configured retransmission timer，且该值要小于configuredGrantTimer。在shared spectrum channel access中必须配置。在授权频谱中不需要配置。

在收到configured grant Type 1的配置时，MAC要将配置的ul grant 存起来，然后根据UL grant的配置，初始化UL 传输。

对于两种配置授权类型，其有公共配置参数“periodicity”，因此两种配置类型一旦被激活，则UE会周期在PUSCH上发送上行数据，每一次上行grant开始的符号要满足以下关系式：

       对于配置授权type 1，其关系式如下：

                    [(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame ×                          numberOfSymbolsPerSlot) + symbol number in the slot] =

timeReferenceSFN*numberOfSlotsPerFrame*numberOfSymbolsPerSlot+timeDomainOffset*numerOfSymbolsPerSlot+S+N*periodicity)modulo(1024*numberOfSlotsPerFrame*numberOfSymbolsPerSlot) for all N >= 0.   

对于配置授权type 2，其关系式如下：

                        [(SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot) + (slot number in the frame ×                                                    numberOfSymbolsPerSlot) + symbol number in the slot] =

[(SFN_start tine*numberOfSlotsPerFrame*numberOfSymbolsPerSlot+slot_start time*numberOfSymbolsPerSlot+symbol_start time)+N*periodicity]module(1024*numberOfSlotsPerFrame*numberOfSymbolsPerSlot), for all N >= 0.

       其中SFN_start time、slots_tart time、symbol_start time分别表示PUSCH的第一次传输时机(配置上行授权初始化或重新初始化时)的系统帧号、时隙、符号。

当RRC层收到要release configured uplink grant 的命令时，MAC 要release 对应的配置。

MAC还有新传的资源分配，且根据configuredGrantConfigToAddModList 的配置，发现此时还有不止一个configured uplink grant传输处于激活状态， MAC要生成Multiple Entry Configured Grant Confirmation MAC CE,用于通知网络端，目前UE 收到了哪些configured uplink grant type2 的激活或者去激活命令；如果只有配置一个configured uplink grant传输，就生成Configured Grant Confirmation MAC CE，用于单个配置的通知。

对于configured grant type 2,MAC在传输完对应的MAC CE后，就要立刻清除configured uplink grant的配置(针对网络端要求取消的配置)。