scheduling Request(SR)

Posted 2023-03-04 modem协议笔记

欢迎关注同名微信公众号“modem协议笔记”。

UE上报BSR，期望网络参照BSR，下发UL grant给UE以便发送UL data，正常情况下，整个过程都会比较顺利。但是世事难料，网络难免有自己的小脾气或者发送BSR不太顺畅，导致UE没有得到自己想要的东西，那UE的情绪多少会发生变化(难道是嫌弃我太啰嗦？)，等达到一定的界限，UE就会换用一种简洁的方式通知网络侧，自己有UL data要发送，那就是SR，BSR触发SR的情景在BSR中有说明。其实UE也指示按规定做事，毕竟UE所有的参数都是网络侧配的，UE能做的，都在网络的掌握之中，到最后UE和网络其实也只是在spec搭的舞台上演戏而已。那这篇就看看SR，先看下SR的配置。

 SR用于UE向网络侧要UL grant。MAC entity可以配置有零个、一个或多个 SR configuration。SR configuration由一组PUCCH resources组成，不同的BWP和Cell的SR对应不同的PUCCH resource。对于每个逻辑信道或 SCell BFR和consistent LBT failure recovery场景，每个 BWP 最多配置一个用于发送SR 的PUCCH resource。

 

每个 SR 配置对应一个或多个逻辑信道和/或 SCell BFR和/或consistent LBT failure recovery。每个逻辑信道、SCell BFR和consistent LBT failure recovery可以映射到零个或一个SR配置，具体由RRC配置。触发BSR或 SCell BFR或consistent LBT failure recovery（如果存在此类配置）的逻辑信道的 SR 配置就用于相应SR的发送。任何 SR 配置都可以用于由Pre-emptive BSR触发的 SR。这段内容晦涩难懂，一堆规定，放在这就好，直接看下实际配置。

 

SR的时频域资源

 通过上述结构使得schedulingRequestId与logical channel进行绑定。例如左图，LogicalchannelIdentity 2 属于LCG 0，LCG0与schedulingRequestID 0绑定，进行确定LogicalchannelIdentity 2与schedulingRequestID 0的关系，之后发送SR时就需要用schedulingRequestID 0对应的资源进行发送。

 

SR时频域资源这块的内容摘自之前的PUCCH部分，主要是RRC层schedulingRequest的时频域配置，包含SR的发送周期及偏移、发送SR所用的PUCCH resource等，SR发送的时频域资源等规定，这里简短过一下。

 periodicityAndOffset：SR 的发送周期及偏移，例如periodicityAndOffset sl40 : 38 ，即每40个时隙 发一次，要在第39个时隙传输SR（index 0~39）；具体配置时还要考虑SCS，不同的SCS可用的配置不同，如下。

SCS = 15 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 5sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl

SCS = 30 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 10sl, 16sl, 20sl, 40sl, 80sl, 160sl

SCS = 60 kHz: 2sym, 7sym/6sym, 1sl, 2sl, 4sl, 8sl, 16sl, 20sl, 40sl, 80sl, 160sl, 320sl

SCS = 120 kHz: 2sym, 7sym, 1sl, 2sl, 4sl, 8sl, 16sl, 40sl, 80sl, 160sl, 320sl, 640sl

sym6仅仅在SCS =60 kHz及extended cyclic prefix时才能使用；对于发送周期不大于1个 slot的情况，offset默认为0 slot。

phy-PriorityIndex-r16：指示在物理层处理SR时的优先级，p0 代表low priority, p1代表high priority。没有配置时默认priority 0。用于物理层处理PHY 优先级或复用时的优先级参考。

resource：UE发送SR时要使用的PUCCH resource id,对于SR，只能配置PUCCH-format0或PUCCH-format1。

schedulingRequestID：The ID of the SchedulingRequestConfig that uses this scheduling request resource.

periodicityAndOffset可以提供SR_periodicity 和SR_offset。如果SR_periodicity 大于1个时隙时，SR 的具体发送时刻由上面的蓝色公式决定；如果SR_periodicity =1个时隙，这时候SR_offset应该配置为0，则每个时隙都是SR 的发送时刻；如果SR_periodicity <1个时隙,SR 的发送时刻对应的符号l 由公式 （l-l0 mod SR_periodicity）mod SR_periodicity=0 决定，其中l0是PUCCH format中配置的startingSymbolIndex。

 SR 的发送要对应UL symbol，如果SR 的PUCCH transmission occasion可用的symbol小于对应 PUCCH format的nrofSymbol，那UE就不能在这个slot发送SR。

 

一个SR发送的例子，SR 对应PUCCH format 1一个时隙内对应时频域示图如下：

 SR发送周期及偏移periodicityAndOffset sl40 : 38 ，即每40个时隙 传一次，要在第39个时隙传输SR（index 0~39）。

从log中看到UE 在frame 573 slot 18 用PUCCH format 1 发送了SR，根据38.213 9.2.4中确定SR发送时机的公式，可知frame 573 slot 18满足公式，确实是可以发送SR（SCS=30khz N_frame_slot =20），计算过程如下。

 

SR的工作流程

下面先看下网络侧给UE配置的SR参数，相关参数的RRC 配置结构如下

schedulingRequestId： 用于修改SR配置，在LogicalChannelConfig中指示逻辑信道映射到的SR配置，在SchedulingRequestresourceConfig中指示SR使用的具体资源。

sr-ProhibitTimer：在PUCCH上发送SR 传输的定时器。以毫秒为单位。ms1 对应 1ms，ms2 对应 2ms，依此类推。当该字段不存在时，UE 用value 0，在发送完一个SR后开启，其运行期间，不能再次发送SR。

sr-TransMax：最大的SR发送次数， n4 代表 4个, n8 代表 8次。

其余部分就是SR一系列的规定主要在38.321 5.4.4。

 

SR 的触发

触发SR 的情况在BSR中有描述，即当前至少一个BSR被触发且还没有取消时，logicalChannelSR-DelayTimer没有run触发了Regualer BSR：

1 当前没有UL grant进行传输;

2 对于configured ul grant的场景，在logicalChannelSR-Mask=false触发了regular BSR;

3 触发BSR 后得到的UL grant还是不够用于新传;

上述三种情况都要触发SR，向网络侧要UL grant。

 

下面是一些琐碎的规定。

 当 SR 被触发时，就认为其处于pending状态，直到被取消。

如果UE触发了一个 SR并且没有其他使用相同配置的pending SR ，则MAC entity要将其SR_COUNTER置为 0。

 只有在 SR 传输时机对应的PUCCH resource处于active BWP 上,才认为这样的SR transmission是有效的。

 

SR取消的条件

在发送出去SR后，达到某些条件的情况下，UE感觉到比较满意的话，就会收起自己的小脾气，也就会停止SR的发送，具体情况如下

由于BSR而触发的SR：

1 当包含long/short BSR MAC CE的MAC PDU 被传输，那在 MAC PDU 组装之前由于BSR的原因导致的所有pending SR 应被取消，每个相应的 sr-ProhibitTimer 应停止( long/Short BSR MAC CE包含buffer status是持续到MAC PDU 组装之前 最后一次触发BSR前的所有data volume)；此时UE有发送BSR MAC CE的UL grant了，UE好开心，那这种情况下UE就不需要继续发送SR。 

2 另一种情况当UL grant足以发送所有的pending data时，UE欣喜若狂，那所有因BSR发送说触发的pending SR都会取消，并且对应的sr-ProhibitTimer也应停止，皆大欢喜。

 对于不是由于BSR触发的SR(还有其他情况也会触发SR，比如BFR场景等等)，serving cell：

(1) 如果此 SR 在 MAC PDU 组装之前由Pre-emptive BSR 过程触发，并且包含相关Pre-emptive BSR MAC CE 的 MAC PDU 被传输；或者

(2) 如果此 SR 是由 SCell 的BFR触发且传输了 MAC PDU，此 PDU 包括 BFR MAC CE 或Truncated BFR MAC CE(包含此 SCell 的BFR信息)；或者

(3) 如果此 SR 由 SCell 的BFR触发但是该 SCell 被deactive；或者

(4) 如果此 SR 是由 SCell 的consistent LBT failure recovery触发且UE正在发送包含SCell consistent LBT failure MAC CE的MAC PDU；或者

(5) 如果此 SR 是由一个 SCell 的consistent LBT failure recovery所触发且该 SCell 的所有触发的consistent LBT failure都被取消 ：

发生以上任意情况时 ，UE MAC也要取消pending SR并停止相应的sr-ProhibitTimer(在run的话)。

 

触发RA 的情况

但是有些时候，事情并不会进行的特别顺利，UE发送完SR后，仍然没有得到UL grant，这时候UE就会换一种强硬的方式继续未完成的任务，这个新的方式就是RA。

 

由SR触发RA的情况有两种：

 第一种情况：只要至少一个SR处于pending状态且当前没有有效的PUCCH resource 用于发送Pending SR，UE就要取消pending SR并初始化RA过程。

第二种情况就是下面的描述，协议上描述的很复杂，条件很多，简单的说就是SR 达到最大发送次数了，SR这个手段行不通了，UE就要触发RA：

 至少一个SR处于pending状态，当前有有效的PUCCH resource用于发送Pending SR，且在SR transmission occasion 期间sr-ProhibitTimer没有run外加SR transmission occasion没有和measurement gap overlap时：

1 SR transmission occasion对应的PUCCH resource没有与UL-SCH resource overlap或者

2 有配置lch-basedPrioritization ，SR transmission occasion对应的PUCCH resource没有和RAR UL grant对应的PUSCH或MSGA payload对应的PUSCH或TC-RNTI加扰的UL grant对应的PUSCH overlap，但是pending SR对应的transmission occasion与其他UL-SCH resources overlap时(但触发SR的逻辑信道的优先级比这个UL SCH resource 高)，只要UE可以在一个valid PUCCH resource上发送SR，那触发SR的逻辑信道的优先级是最高的(lch-basedPrioritization存在时，在grant(configured grant和dynamic grant)之间产生overlap或发送SR的PUCCH resource和grant(包括configured grant和dynamic grant)之间产生overlap时，MAC entity会根据LCH priority，UE按照上面的规则处理相关问题)；

满足上述任一条件都可以认为这个SR 传输是一个prioritized SR transmission，与SR传输PUCCH资源overlap的其他UL grant是de-prioritized UL grant。 

否则认为这个SR 是一个 de-prioritized SR transmission。

 

R15这部分，只有SR transmission对应的PUCCH resource与其他任何UL-SCH resource 没有产生overlap时，才能发送SR；R16这部分如上，对SR的发送情况进行了细化，即使SR对应的PUCCH resource与其他UL-SCH resource产生overlap时，只要基于LCH priority判断结束后，SR对应的PUCCH resource是prioritized SR transmission，仍然可以进行候选SR的发送，具体如下(R17基本和R16类似)。

 假如SR 传输是一个prioritized SR transmission，与其参数overlap的其他UL grant就是de-prioritized UL grant：

如果de-prioritized UL grant 是configured UL grant(有配置autonomousTx) 且对应的PUSCH已经开始发送，UE要停止对应HARQ process 的configuredGrantTimer。

如果此时SR_COUNTER<sr-TransMax,UE要在有效PUCCH 资源上发送SR，SR_COUNTER++并开启sr-ProhibitTimer；

如果SR_COUNTER>=sr-TransMax,UE 要通知RRC release serving cell的PUCCH/SRS，清除configured DL assignments/UL grant 和semi-persistent CSI report on PUSCH 资源,最后取消所有SR 并触发RA过程。 

 

SR 触发的RA 过程停止条件

UE换用RA的方式后，可能会得到网络侧比较完美的答复，那UE就没有必要继续纠缠，这时候UE可能会停止RA。对应的场景对应下面三段描述。

 由于 BSR 而触发的pending SR(该 SR 由 MAC entity在MAC PDU 组装之前由于没有配置有效的PUCCH resource触发)，如果：

(1)MAC PDU可以使用UL grant传输，但这个UL grant不是RAR提供的UL grant，也不是2-step中用于传输MSGA payload的UL grant，并且该PDU包括 BSR MAC CE(BSR 包含的是持续到MAC PDU 组装之前 最后一次触发BSR前的所有data volume) ；或者

(2)UL grant(s) 可以用于传输所有的UL pending data。

满足上述情况之一，MAC entity可能会停止（如果有的话）正在进行的RA过程。

 由于 SCell BFR触发的pending SR,由于没有有效的PUCCH resource 而触发RA，如果：

(1)MAC PDU可以使用UL grant传输，但这个UL grant不是RAR提供的UL grant，也不是2-step中用于传输MSGA payload的UL grant，并且该PDU包括 BFR MAC CE(包含SCell BFR info) ；或者

(2)由于Scell被deactive导致所有触发的scell BFR被取消。

满足上述情况之一，MAC entity可能会停止(如果有的话)正在进行的RA过程。

 由于 consistent LBT failure触发的pending SR，由于没有有效的PUCCH resource而触发RA，如果：

(1)MAC PDU可以使用UL grant传输，但这个UL grant不是RAR提供的UL grant，也不是2-step中用于传输MSGA payload的UL grant，并且该PDU包括 LBT failure MAC CE(包含SCell consistent LBT failure info)；或者

(2)由于Scell 被deactive 导致所有触发的consistent LBT failure被取消。

满足上述情况之一，MAC entity可能会停止（如果有的话）正在进行的RA过程。

 

最后针对上述内容整理如下流程图，不用怀疑的是，这个图有问题，并没有完整显示上述内容，只是简单记录了大体流程。

 至此本篇就基本结束了，不管什么道路都难免崎岖不平，UE也一样，即使换用SR后，也可能无法得到UL grant，那就只能触发RA，但是就算是RA，在某些场景下，UE可能仍然无法得到自己想要的东西，在这种情况下，UE只能按照spec的规定拿出最后一套动作......