网站建设中 下载,营销推广有哪些,wordpress调用标签代码,足球世界排名一览表欢迎关注同名微信公众号“modem协议笔记”。 以一个实网中的异常场景开始#xff0c;大概流程是有UL data要发送#xff0c;UE触发BSR-no UL grant-SR-no UL grant-trigger RACH-RACH fail-RLF-RRC reestablishment#xff1a;简单描述就是UE触… 欢迎关注同名微信公众号“modem协议笔记”。 以一个实网中的异常场景开始大概流程是有UL data要发送UE触发BSR-no UL grant-SR-no UL grant-trigger RACH-RACH fail-RLF-RRC reestablishment简单描述就是UE触发BSR此时没有UL grant之后触发SR仍然没有 UL grant之后触发RACHRACH fail引起RLF引起RRC reestablishment这个异常场景在弱信号情况下比较常见其中涉及的具体内容其实是比较多的这篇就看下BSR的内容BSR 的内容主要在38.321 5.4.5章节。 开始之前简单看下BSR和SR的区别UE通过SR向gNB请求上行资源时只指明了UE有上行数据需要发送并没有指明需要发送的上行数据数量。而BSR的作用是将UE当前buffer中待发送的数据情况通知给gNBgNB可根据BSR上报的UE buffer的数据量给UE分配上行资源换个角度看UE发BSR时是通过BSR MAC CE既然能发BSR肯定是有UL grant足够发BSR如果没有UL grantUE要通过SR向gNB要UL grant进而UE就要发送SR。接下来看看协议中是如何描述BSR的。 BSR相关的RRC层参数如下 logicalChannelSR-Mask在配置configured uplink grant of type1 or type2 时用于控制SR 的触发。True代表对应logical channel有配置SR masking。
logicalChannelSR-DelayTimerApplied用于指示是否对logical channel 应用SR 传输的delay timer;设置为false的话BSR-Config中就不会包含logicalChannelSR-DelayTimer。
logicalChannelSR-DelayTimer单位是subframe数Value sf20 代表20 subframes, sf40 代表40 subframes,以此类推该timer的作用顾名思义就是在run期间不能触发SR。
periodicBSR-Timer单位是subframe数 Value sf1 代表1 subframes, sf5 代表5 subframes,以此类推。
retxBSR-Timer单位是subframe数 Value sf10 代表10 subframes, sf20 代表20 subframes,以此类推。
logicalChannelGrouplogical channel group的ID, 代表logical channel 对应的LCG ID。 说到参数LCG ID那就顺带看下LC 和LCG的关系。实网下根据业务的不同UE可能建立很多RB如果为每一个逻辑信道(LC)上报一个BSR会带来大量的信令开销。为了减少这种开销和LTE相同NR引入了逻辑信道组LCG的概念不同的是NR将LCG个数由LTE的4个扩展到了8个以满足NR系统更多样的业务场景。所以UE是基于LCG上报BSR而不是为每个逻辑信道上报一个BSR。而逻辑信道的分组是gNB的算法逻辑信道分组也是为了提供更好的BSR上报机制一般会将有相似调度需求的逻辑信道放入同一LCG中。例如将相同QCI/priority的逻辑信道放入同一LCG。如下图logical channel 4/2 分别对应的是LCG 7/0。 既然UE的LCG和逻辑信道的配置是由gNB控制的那gNB就知道每个LCG包含哪些逻辑信道以及这些逻辑信道的优先级。虽然gNB无法知道一个单独的逻辑信道的缓存状态但由于同一LCG中的逻辑信道有着类似的QoS/priority需求所以基于LCG上报BSR也可以在一定程度上满足业务的QoS需求。 下面是38.321中BSR的内容。 BSR是用于向serving gNB 提供 MAC entity中的 UL data volume信息的过程之后gNB根据BSR 中的UL data volume及自身loading向UE下发对应的UL grant用于UE UL 传输。
与BSR相关的几个RRC层参数分别是periodicBSR-TimerretxBSR-TimerlogicalChannelSR-DelayTimerAppliedlogicalChannelSR-DelayTimerlogicalChannelSR-MasklogicalChannelGroup。
每个logical channel 可以使用 logicalChannelGroup 分配到一个 LCG。 LCG 的最大数量为八个。
更具体的MAC entity是根据 RLC和 PDCP中的data volume计算过程确定logical channel可用的 UL 数据量用于BSR的上报。 BSR 触发场景BSR的分类 (1)属于某个LCG的逻辑信道的有UL data要发送 并且该 UL data对应逻辑信道的优先级高于任何其他LCG有UL data要发送的逻辑信道的优先级或
当所有LCG 逻辑信道都没有UL data要发送时某个LCG的逻辑信道有UL data要发送在这种情况下触发的BSR叫做 regular BSR
(2)为了避免UE发送了BSR却一直没有收到UL grant的情况gNodeB为UE配置了一个retxBSR-Timer定时器当retxBSR-Timer 超时并且某个LCG的至少一个逻辑信道有UL data要发送在这种情况下触发的BSR也称为Regular BSR目的是使得UE周期性地向gNB更新Buffer Status
(3)考虑到当regular BSR、padding BSR的触发条件都不满足时网络侧也能知道UE的buffer status以便后续为UE分配适当UL grant定义了在periodicBSR-Timer 超时在这种情况下触发的BSR称为Periodic BSR。
(4)UL grant给多了UL数据组包接收后还有剩余bits没用完就要在对应的资源上加padding(MAC需要用 0 来填充)那padding bits数大于等于BSR MAC CE 加上其subheader的大小时,触发的BSR叫做 padding BSR
当多个逻辑信道同时触发Regular BSR时每个逻辑通道各自触发一个独立的Regular BSR最后UE根据LCG 确定具体的buffer上报BSR。接下来看下BSR MAC CE的结构。
BSR MAC CE 如开头所述为提高空口效率BSR并不是为每个LC绑定一个BSR而是为每个LCG绑定一个BSR上报时以LCG为单位上报如上图的LCG ID用于区分BSR。 BSR MAC CE包含的类型分别是Short BSR/Long BSR/Short Truncated BSR/Long Truncated BSR分别通过LCID 5962进行区分。Pre-emptive BSR MAC CE用于IAB场景不在本篇内容之内。
四种BSR MAC CE的发送与BSR的类型优先序padding BSR 根据场景的不同可以上报上述四种BSR MAC CE而Regular BSR和Periodic BSR 只能上报Short BSR/Long BSR MAC CE,具体内容后面再说。 short BSR/short Truncated BSR MAC CE short BSR和short Truncated BSR MAC CE的结构如上分别由3 bits的LCG ID及5 bits的Buffer size组成其中LCG ID对应的是BSR 上报的LCG id
Buffer size代表PDCP和RLC的data volume 单位是bytes其中RLC header和MAC subheader不在buffer size的计算范围内。 short BSR和short Truncated BSR MAC CE的Buffer size为5bits对应031个value分别代表不同的buffer size value对应如下。 例如上报的Buffer size index 为18 就代表buffer size 实际value在(2014,2806]bytes之间之后网络侧根据实际loading下发对应的UL grant即可。 long BSR/long Truncated BSR MAC CE 从MAC CE的结构看LCGi 对应LCG0LCG7对于long BSR,当LCGi1时代表LCG i的Buffer size field 会上报也就是BSR MAC CE中会包含其Buffer size field 当LCGi0时代表LCG i 不会有Buffer size field上报即BSR MAC CE中不会有其Buffer size field。 对于Long Truncated BSR当LCGi1时代表LCG i 有pending size要发送 当LCGi0时代表LCG i 没有pending size要发送其实功能和long BSR类似。
long BSR/long Truncated BSR的Buffer size对应8bits其Buffer size index范围是0~254(255 reserved)代表不同的bytes值。 Buffer size field 以LCG i升序排列(LCG 0~7) 。对于long Truncated BSRBuffer size的大小有限制不能超过padding bits数。
由于NR可配置8个LCG如果将8个LCG缓存数据的大小全部上报给gNB即使一些LCG中没有缓存数据也会造成资源浪费因此在NR中设计了可变大小的BSR格式。结合上面的描述可以看出short 和long BSR 的区别就是short BSR的大小是固定的long BSR 大小可变其中Truncated BSR是在上行资源不足以上报 normal BSR时向网络侧上报部分LCG的信息。 BSR 上报流程
Regulat BSR 和Periodic BSR 对于Regular BSR如果有logical channel 触发了BSR且有配置logicalChannelSR-DelayTimerAppliedtrue那MAC entity要start/restart logicalChannelSR-DelayTimer其他情况不需要开启logicalChannelSR-DelayTimerlogicalChannelSR-DelayTimer有在running就要停止。 对于Regular BSR和Periodic BSR当多于一个LCG有UL data 要传输时对于有UL data传输的所有LCGs要上报Long BSR;否则只有一个LCG有UL data要传输 就上报Short BSR。 Padding BSR 对于Padding BSR对应padding bits大于等于short BSRsubheader的size但是小于long BSRsubheader的size时
1 恰巧当前不止一个LCG有UL data传输时 1.1如果当前padding bits等于Short BSRsubheader就report 有UL data要传输的最高优先级LC 的short Truncated BSR 1.2 当padding bits大于short BSRsubheader的size但是小于long BSRsubheader的size就根据LCG 中LC的优先级降序的顺序上报Long Truncated BSR(如果出现优先级相同的情况就根据LCGID升序的顺序上报)。
2 如果只有一个LCG有UL data传输时就上报Short BSR。
padding bits大于等于long BSRsubheader的size时就上报包含所有有UL data传输的LCG long BSR。 BSR cancel 当UL grant 足以用于传输所有pending的data但不够额外容纳 BSR MAC CE 及其subheader时可以取消所有触发的 BSR。 当传输的MAC PDU包括long或short BSR MAC CE 时应取消在 MAC PDU 组装之前触发的所有 BSR因为此时的long或short BSR MAC CE对应的buffer status包含MAC PDU assembly之间触发的BSR内容。 其他规定 当前至少一个BSR被触发且还没有取消时如果当前的UL grant足够发送BSR MAC CEsubheader就发送当前的生成功的BSR MAC CE启动或重启 periodicBSR-Timer(所有生成的 BSR 都是long或 short Truncated BSR时 不需要开启periodicBSR-Timer)也要开启retxBSR-Timer。 当前至少一个BSR被触发且还没有取消时logicalChannelSR-DelayTimer没有run且触发了Regualer BSR
1 当前没有UL grant进行传输;
2 对于configured ul grant的场景在logicalChannelSR-Maskfalse时触发了regular BSR比如configured ul grant场景配置的UL grant 不够了也要通过SR取要UL grant;
3 可用于新传输的 UL-SCH 资源不满足发送 经过LCP映射限制过程后的触发的BSR意思就是UL grant不够发送BSR(LCP 过程其他篇再说);
上述情况就要触发SR向网络侧要UL grant。
这里就是开篇 UE发送BSR后没有收到UL grant 之后触发SR的理论依据。 即使多个事件已触发 BSR一个MAC PDU最多应只能包含一个 BSR MAC CE。 Regular BSR 和Periodic BSR 的优先级高于padding BSR对于由retxBSR-Timer超时触发的BSRMACentity 认为触发BSR的LC 的优先级是最高的。即retxBSR-Timer超时引起BSR的LC要优先处理。
MAC entity应在收到在任何 UL-SCH上传输新数据的UL grant后重新启动retxBSR-Timer。 上面这段描述并没有特别强制的问题就描述了下对应情况允许的做法就列在这里做个记录。
最后各个timer的汇总如下 上面主要是根据开篇的那个异常常景走读一遍协议中BSR的具体内容后面针对这个异常场景中涉及的其他流程再看下相关协议内容本篇结束感谢阅读。
