scheduling Request(SR)

Posted modem协议笔记

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了scheduling Request(SR)相关的知识,希望对你有一定的参考价值。

欢迎关注同名微信公众号“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的规定拿出最后一套动作......

以上是关于scheduling Request(SR)的主要内容,如果未能解决你的问题,请参考以下文章

5G MAC随机接入流程中的 Msg3 —— Scheduled UL (PUSCH) Transmission

调度 engine._next_request_from_scheduler() 取出request交给handler,结果是request,执行engine.craw(),结果是resp/fail,

SpringCloud(Hoxton.SR3)基础篇:第五章Hystrix-request collapsing(请求合并)

爬虫日记(86):Scrapy的Scheduler类

yield self.engine.open_spider()重点是第一次开始执行nextcall.schedule() 和心跳,接下来分析心跳执行engine._next_request_from_

分布式爬虫