UL grant的分配？怎么分？

UE有UL data时，会发送BSR的告知网络侧自己详细的请求，期望网络能够如期下发UL grant，正常情况下网络侧会给UE足够的UL grant去发送UL data，整个过程都会比较顺利。UE收到UL grant后，欣喜若狂，接下来要分配UL grant，但是很快就有一个难题摆在眼前，有时候UE侧会有很多逻辑信道有UL data发送，也就是UE需要将多个逻辑信道复用到一个MAC PDU中，这么多逻辑信道，手心手背都是肉，那怎么分？毫无疑问spec上给出了解决方式，答案在38.321 5.4.3.1Logical channel prioritization (LCP)，这部分算是很久的内容了，整体逻辑和LTE一样。在配置之初，网络侧会为每个逻辑信道分配一个priority，进而可以决定多个逻辑信道的复用顺序。拥有最高priority的逻辑信道的data会被优先处理，高优先级逻辑信道的data会优先包含在MAC PDU中，接着是第二高priority的逻辑信道的data，直到分配的UL grant被全部用完或没有UL data要发送。

但是又有一个难题出现了，如果高priority的逻辑信道一直有UL data要发，那这个逻辑信道就会一直占用UL grant，其他逻辑信道无法发送自己的data，从而出现问题。和LTE一样，NR引入了Prioritized Bit Ratio(PBR)和Bucket Size Duration(BSD)的概念，即通过RRC信令配置各个逻辑信道参数时，提前为每个逻辑信道配置好各自的PBR及BSD，这样使得当前逻辑信道的的发送UL data增长到PBR×BSD时，其他待传输数据就不能再继续用UL grant，剩下的UL grant就要分配给其他低优先级的逻辑信道，PBR*BSD对应的就是每个逻辑信道的最小数据速率保证，从而保证了其他低优先级逻辑信道的QoS。由于这部分R17和R15相比，基本没有什么变化，只是多了几个参数，就直接看看R17 spec是怎么写的，都有哪些规定。

相关参数

logical channel prioritization过程中UL data调度的相关参数如下

priority: 逻辑信道的优先级，value对应1～16，value越小 优先级越高。

bucketSizeDuration(BSD): 单位是ms， ms5代表 5 ms， ms10代表 10 ms。

prioritisedBiteRate(PBR): 单位是kiloBytes/s，kBps0代表 0 kiloBytes/s ，kBps8代表 8 kiloBytes/s 依次类推，对于SRB，该值只能设置为infinity，如下，是实网环境下各个RB和逻辑信道之间的配置关系，SRB1的优先级通常是最高的，一般对应逻辑信道 id 1，只有有UL data 要发，所有的UL grant都会先分配给该逻辑信道，毕竟其他逻辑信道都是弟弟。

LCP 过程的控制参数如下

allowedServingCells 可以限制逻辑信道能够应用的服务小区。

allowedCG-List 用于限制可以configured grant的传输，具体看下面的RRC层参数的具体意义。

allowedPHY-PriorityIndex用于设定动态 grant传输 允许的PHY priority index。

allowedHARQ-mode：R17新增参数，对应uplinkHARQ-mode，可以用于控制允许的HARQ mode；uplinkHARQ-mode 可以控制enable/disable HARQ feedback，分别对应HARQmodeA/HARQmodeB。

allowedSCS-List规定了允许传输的SCS，maxPUSCH-Duration规定了传输的最大PUSCH duration，两个参数的设定与业务时延要求有关系，如果业务时延要求较短，可以将allowedSCS-List配置为较大SCS或将maxPUSCH-Duration配置为较小duration。

configuredGrantType1Allowed用于控制configured grant type 1是否可以用于上行传输。

allowedSCS-List、maxPUSCH-Duration 和 configuredGrantType1Allowed还与UE 能力挂钩，如下。

lcp-Restriction:指示 UE 是否支持根据 RRC 配置限制,使用 RRC 参数 allowedSCS-List、maxPUSCH-Duration 和 configuredGrantType1Allowed为每个 UL grant选择逻辑信道。

上述几个参数在RRC层具体描述如下：

maxPUSCH-Duration: 某个逻辑信道配置该参数的情况下，则对应的UL MAC SDU 只能使用PUSCH持续时间小于等于该字段指示时间的UL grant进行传输；不配置时，没有限制。

configuredGrantType1Allowed:针对URLLC业务，引入这个可以避免其他业务抢占URLLC业务的Configured Grant参数，配置的话 只能是True；如果有配置这个IE或UE不支持lcp-Restriction 能力，来自该逻辑信道的 UL MAC SDU 可以用configured grant type 1 传输。否则，来自该逻辑信道的 UL MAC SDU 不能用configured frant type 1 传输。

allowedCG-List：仅适用于 Configured UL grant场景，Configured grant场景会配置对应的ConfiguredGrantConfigIndexMAC。如果有配置该IE，则来自该逻辑信道的 UL MAC SDU 只能映射到该IE指示的Configred grant的配置。如果有配置该IE 但是没有配置任何ConfiguredGrantConfigIndexMAC，则来自该逻辑信道的 UL MAC SDU 不能映射到任何已配置的configured grant 配置上 。如果该字段不存在，来自该逻辑信道的 UL MAC SDU 可以映射到任何已配置的configured grant 配置上。如果字段 configuredGrantType1Allowed 存在，则只有在该List中有指示已配置configured grant type 1 才允许由该逻辑通道使用；否则，该list不应包括任何已配置的configured grant type 1配置。

allowedServingCells：针对重复传输(Duplication),引入了这个参数，用于限制重复内容在相同的小区传输,后面，allowedServingCells也被应用来限制逻辑信道能够应用的服务小区。所以这个参数配置时需要注意，如果与逻辑信道关联的 DRB/SRB有配置PDCP CA duplication （即PDCP entity与属于相同Cell group的多个RLC entity相关联），则该字段是强制存在的，其他情况该字段是可选配置的。如果有配置该参数，则来自该逻辑信道的 UL MAC SDU 只能映射到该列表中指示的服务小区。否则，该逻辑信道的 UL MAC SDU 可以映射到对应cell group中的任何已配置服务小区。

allowedPHY-PriorityIndex：此限制仅适用于动态grant 场景。R16 可以通过配置priorityIndicatorDCI =enable，使得DCI 0_1/0_2 带有1 bit的Prority indicator field，进而告知UE 该动态调度对应的priority，priority index 非0即1，具体如下图示；如果该字段存在并且动态grant具有对应的PHY priority index，则来自该逻辑信道的 UL MAC SDU 只能映射到指示PHY priority index等于该字段配置的值的动态grant。如果该字段存在并且动态grant没有 PHY priority index(即对应priority index 0)，则如果该字段的值为p0，则来自该逻辑信道的 UL MAC SDU 只能映射到该动态 grant. 如果该字段不存在，则来自该逻辑信道的 UL MAC SDU 可以映射到任何动态 grant。

下面看下38.321 中UL grant的分配规则

UE为每个逻辑信道j 维护一个参数Bj，当某个logical channel j建立时，对应的Bj初始化为0。

在每次LCP 过程时，Bj增加PBRT，其中T代表上次Bj增长后经过的时间；如果Bj>bucket size(PBRBSD),则Bj=bucket size(PRB*BSD)。

这个bucket size(PBR*BSD)对应的是每一轮资源分配时，每个逻辑信道可以得到的最大的UL grant量。

Selection of logical channels

当UE有新传要执行时，要同时满足下面的条件的前提下才能为UL grant选择逻辑信道：

1 有配置allowedSCS-List时，allowedSCS-List 中允许的SCS index包括与 UL grant关联的SCS；

2 有配置maxPUSCH-Duration时，UL grant 的PUSCH 传输duration 要小于等于maxPUSCH-Duration配置的值；

3 confiuredGrantType1Allowed=true时，UL grant要对应Configured grant type 1；

4 allowedCG-List 包含对应UL grant的configured grant index；

5 allowedPHY-PriotityIndex 包含动态 UL grant 的priority index；

6 allowedServingCells 对应的是允许使用UL grant的cell info(这个参数不会用于CA duplication deactive的情况)；

7 符合allowedHARQ-mode的要求。

上面七个条件是and的关系，对应参数有配置时才要考虑。

Allocation of resources

逻辑信道资源分配步骤如下。

step1：对于所有Bj>0的逻辑信道，按照优先级递减顺序排序。当某个逻辑信道的PBR配置成无穷大时，只有当这个逻辑信道的资源得到满足后，才会考虑比它优先级低的逻辑信道；其他情况每个逻辑信道每次可以分的的最大UL grant只能是bucket size=PRB*BSD。

step2：Bj减去逻辑信道j在步骤1中用到MAC PDU的所有MAC SDU的大小。

step3：如果前两步执行后仍有上行资源剩余，则把剩余的资源按照逻辑信道优先级分配给各个逻辑信道，而不再比较Bj的大小。只有当所有高优先级的逻辑信道的数据都发送完毕且UL grant还未耗尽时，低优先级的逻辑信道才能得到服务。两个逻辑信道优先级相同时，就要同等服务。

举个例子如上图，假如只有两个逻辑信道要有UL data要发送，对应的bucket size(BSD*PBR)分别为橘黄色部分和蓝色部分。第一种情况，UL grant只能满足逻辑信道1 的bucket size，就先把逻辑信道1 对应量的data 送出去，剩余的UL grant全部给逻辑信道2；第二种情况，UL grant 正好可以满足两个逻辑信道的bucket size 要求，就按照优先级高低，都装进去；第三种情况，UL grant 装满两个逻辑信道的bucket size后，还有剩余，这时候，只考虑优先级的高低，优先级高的先用，优先级低的后用，直到用完或者逻辑信道没有UL data 发时为止，所以先上逻辑信道1 的其他UL data，装走逻辑信道1的剩余UL data后，UL grant还有余量 再装逻辑信道2。

UE在UL调度时要遵守以下规定：

1 一个完整的RLC SDU(或分段传输的RLC SDU或重传的RLC PDU)，如果剩余UL grant足以发送，UE就不能对它执行segment，这样也可以减轻网络侧接收的处理负担；

2 如果UE需要对RLC SDU执行分段，则要按照ul grant的余量，最大化segment 的size，以便达到尽可能减少RLC SDU segment的目的；

3 UE尽可能传输数据量大的RLC SDU；

4 如果UE MAC entity收到的UL grant >=8Bytes，且有UL data要传输，则MAC entity不能只传输Padding BSR和/或Padding，也应该包含相应的上行数据。

具体到逻辑信道，要按照以下顺序执行优先级过程，优先级顺序由高到底排列。

某些场景，网络侧和能力比较强的UE会达成共识，这样的UE收到 UL grant但是没有data发送时，就可以不发任何东西了，这样可以减轻UE的负担，网络侧也能省去一些麻烦，具体如下。

不生成MAC PDU的情况

SkipUplinkTxDynamic: UE没有UL data要传输时，如果支持该功能，UE就可以在这个UL grant的资源上不发任何data

enhancedSkipUplinkTxDynamic:如果UE没有UL data和UCI要发送时，如果支持该功能，UE就可以在这个UL grant的资源上不发任何data。

简单的说就是UE 没有UL data发，网络开了skip功能，UE也支持，那UE就可以skip；不支持的话UE就要在UL grant上加padding。

如果MAC配置了enhancedSkipUplinkTxDynamic=ture，同时UL grant是通过C-RNTI加扰的DCI 收到的，或对应的是configured UL grant，那HARQ entity满足以下条件，MAC entity就不会生成对应的MAC PDU：

1 此次PUSCH传输不需要发送aperiodic CSI；

2 MAC PDU没有MAC SDU，就是没有data要发；

3 MAC PDU只包括 periodic BSR，同时任何逻辑信道组（LCG）都没有可发送的数据，或MAC PDU只包括Padding BSR。

4 PUSSH 传输不存在UCI复用的情况

除了上面的情况，如果HARQ entity满足以下条件，MAC entity就不会生成对应的MAC PDU：

1 MAC配置了skipUplinkTxDynamic=ture，同时UL grant是通过C-RNTI加扰的DCI 收到的，或对应的是configured UL grant；

2 此次PUSCH传输不需要发送aperiodic CSI；

3 MAC PDU没有MAC SDU；

4 MAC PDU只包括 periodic BSR，同时任何逻辑信道组（LCG）都没有可发送的数据，或MAC PDU只包括Padding BSR。

这部分至此就结束了。回到最初的异常场景BSR->no UL grant->SR->no UL grant->trigger RACH->RAfail->RLF->RRC reestablishment，UE 收到UL grant后，要按照这篇中的规则办事，保证各个逻辑信道可以正常工作。但是BSR送出去后没有收到UL grant，最后触发了SR，如果又没有收到UL grant，这时候UE的内心或许无奈，或许又有点生气着急..... 那UE具体该怎么做？