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_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的规定拿出最后一套动作......
-
RRC
+关注
关注
0文章
28浏览量
11134 -
SCS
+关注
关注
0文章
19浏览量
10548 -
触发器
+关注
关注
14文章
2000浏览量
61134 -
PDU
+关注
关注
0文章
94浏览量
16978 -
PHY寄存器
+关注
关注
0文章
6浏览量
5326
发布评论请先 登录
相关推荐
评论