LTE资源调度 -- 上行资源申请(1)BSR

1.UE申请上行资源的途径

当UE需要向网侧发送数据的时候,必须要有上行RB资源,如果没有RB资源则需要先向网侧申请RB资源。UE有三种方式向网侧申请RB资源:

(1)向网侧发送BSR。BSR的全称是Buffer Status Report,即缓存状态报告。UE可以在MAC层的PDU(即分组数据单元)中插入一个BSR控制单元来告诉网侧:我的某个或某几个逻辑信道组当前有多少数据需要发送,希望你能分配一些RB资源给我。

这种通过发送BSR控制单元的方式,可以让网侧知道UE需要发送的数据量,网侧可以针对性的分配RB资源。但是这里有个问题,UE发送BSR控制单元这个动作本身也是需要上行RB资源的,如果UE没有任何上行RB资源,则不能发送BSR。

(2)向网侧发送SR。当UE无法发送BSR申请RB资源的时候,可以通过发送SR(Scheduling Request)请求的方式申请资源。SR信号在PUCCH控制信道中传输的,并不需要上行RB资源就可以向网侧发出资源的申请。但这种申请方式有个不好的地方是,网侧收到的只是一个SR信号,并不知道UE接下来需要上传多少字节的数据,从而并不清楚该分配多少的资源是合适的,因此后续UE可能仍然需要发送BSR来申请更多的上行资源。网侧收到UE的SR请求后,分配多少的RB资源是由设备厂家的算法决定的,一般来说网侧分配的RB资源至少能够满足BSR的发送。

       但并不是所有的UE都能发出SR信号。只有配置了SR资源的UE,才能向网侧发送SR请求。如果某个UE既无法发送BSR,又不能发送SR,这个时候UE就需要发起竞争随机接入过程了。

(3)发起竞争随机接入。竞争接入的目的之一就是获取上行RB资源。在这种方式中,UE将在MSG3中插入一个BSR控制单元来告诉网侧需要的资源信息。当然,这种方式也是UE迫不得已才会采用的,毕竟这种方式的时延相对BSR和SR来说是最大的。

       UE申请资源的过程,将优先采用BSR的方式,如果不能发送BSR,则采用SR的方式,最后才会考虑竞争随机接入的方式。如下面的图1所示,无论是上面的哪种方式,是SR申请还是竞争随机接入申请,还是BSR申请,网侧实际分配的资源可能都不足以让UE传完数据,此时UE会继续发送BSR来申请更多的资源。

图1

2.BSR携带的信息

       UE怎么向网侧表达待传数据量呢?最简单的方法,当然是UE将具体的数字(比如1000001这个数)编码到BSR的信息里,但这样的话,在空口中传输的bit位个数就比较多。协议在这里采用了另一种方式来编码BSR信息:使用0~63这64个index索引,来代表不同的字节范围,BSR只需要6个bits的空间就足够了,减少了空口传输的比特位数。

       BSR携带的索引值与字节大小的对应关系具体如图2所示,index=0表示某个逻辑信道组没有数据需要发送,index=63表示某个逻辑信道组有超过150K字节的数据需要发送。当UE有30个字节的数据需要发送时,只需要将BSR控制单元的值填为8。需要注意的是,这并不意味着网侧就会给UE分配26个字节或31个字节对应的资源,UE也不能做类似的假定。因为网侧在收到BSR后需要根据整个网络资源情况来分配BR,不是无条件满足某一个UE的。比如这个例子中,网侧可能只会分配10个字节的资源给UE,而不是26个字节也不是31个字节,甚至有时候,网侧在收到BSR后并不会给该UE分配任何的上行资源。网侧如何给某个UE分配资源,是由设备厂家的算法决定的,UE不应该对资源申请的结果做特定大小的假设。

 图2

3.逻辑信道组

       为了减少在空口中传输的信息比特个数,协议并不是为每个逻辑信道绑定一个BSR值,而是为每个逻辑信道组绑定一个BSR值。上文已经提到,BSR携带的是0~63这64种索引值,每个索引值对应不同范围的字节数目,这个字节数并不是该UE所有待传的数据量,也不是某个逻辑信道待传的数据字节数,而是某个逻辑信道组待传的数据量

       逻辑信道组(Logic Channel Group,简称LCG),顾名思义,就是将一个或多个逻辑信道归为一组。RRC在配置每个逻辑信道属性参数logicalChannelConfig的时候,可以为该逻辑信道分配相应的LCG ID号logicalChannelGroup,这个ID号的范围是0~3,也就是说只有4个逻辑信道组,如图3所示。

图3 

虽然逻辑信道的组号LCGID由RRC配置,但协议对其中的某些特定的逻辑信道规定了具体的LCGID值,比如:SRB0、SRB1、SRB2这三个逻辑信道,要固定配置LCGID=0。从这个细节我们也可以看到,虽然逻辑信道组是没有优先级概念的,但协议还是偏向LCGID=0的优先级高于其他LCGID,eNB的RRC在给其他逻辑信道配置LCGID的时候,不应该将DRB的LCGID配置成0。另外,逻辑信道与逻辑信道组的匹配还需要参考该逻辑信道承载业务的QCI,对于优先级比较高的业务,可以将该逻辑信道的LCGID配置为1。

4.BSR控制单元的格式

UE上报的BSR控制单元(control element)有两种格式:

(1)Short BSR(短BSR)或者Truncated BSR(截短BSR),BSR控制单元固定占1个字节,只能携带1个逻辑信道组的BSR信息。该BSR信息所对应的逻辑信道组ID固定占用2比特,取值0~3,BSR域固定占6比特,取值0~63。

(2)Long BSR(长BSR),BSR控制单元固定占3个字节,可以携带所有逻辑信道组的BSR信息。因为协议只规定了4种逻辑信道组,因此不需要再携带LCG ID值,从LCG ID0到LCG ID3依次编码6个比特的BSR域:Buffer Size #0对应LCGID0的BSR值,Buffer Size #1对应LCGID1的BSR值,Buffer Size #2对应LCGID2的BSR值,Buffer Size #3对应LCGID3的BSR值。

两种格式如下面的图4所示。

图4

 注意,图4中的Buffer Size #1和#2是跨字节的,关于跨字节的高低位合并问题,与DCI码流的高低位合并规则是相同的。

       每个MAC控制单元都对应着一个MAC子头,这个子头里的LCID域用来表示控制单元的类型。上面提到的BSR的三种类型Short BSR、Truncated BSR、Long BSR,就是通过子头中的LCID值确定的,如下图5所示。协议为这三种BSR类型分别定义了不同的LCID值:如果与控制单元相对应的子头的LCID值是28(即二进制11100),那么表示UE上传的是Truncated BSR,这个时候网侧MAC层只需要提取1个字节的控制单元码流,从中就可以解析出逻辑信道组ID号和BSR值;类似的,如果与控制单元相对应的子头的LCID值是30,则表示UE上传的是Long BSR,网侧需要提取3个字节的控制单元码流,从中解析出所有逻辑信道组的BSR值。

 

 图5

5.UE触发BSR的时机

当以下事件之一发生时,UE将会触发一个BSR(注意:这里只是触发BSR,能否发送BSR需要看有没有上行RB资源):

(1)当属于某个逻辑信道组的某个逻辑信道有上行数据可供传输,并且这条逻辑信道的优先级高于目前任何逻辑信道组中任何逻辑信道的优先级,或者目前同个逻辑信道组中所有其它的逻辑信道均无可传数据,此时将触发一个BSR,且该BSR叫做常规BSR(Regular BSR)。如下文的图6所示,后面还会继续用到这个图。

前一个触发场景的意思是,无论UE之前是不是已经发出了BSR,亦或这个时候还在等待上行授权,只要具有更高优先级的逻辑信道有新数据要传,那么这个时候UE就要重新触发一次BSR。后一个触发场景的意思是,有一个逻辑信道组之前是没有数据可传的,此时其中某个逻辑信道有数据可传了,那么不管其他逻辑信道组的状态是什么,都要重新触发一次BSR。

 图6

当UE触发了一个BSR且当前TTI时刻有上行RB可用时,UE将组建BSR控制单元;当UE触发了一个常规BSR且当前TTI时刻没有上行RB可用时,是没有办法发送BSR的,但是否就需要发送SR申请资源呢?不然,此时还要看下面两种情况,(注:只有当常规BSR不能发送的时候才会考虑是否发送SR,而周期BSR和填充BSR不能发送的时候,是不会考虑发送SR的):

(A)没有已经配置的上行授权。如果网侧激活了UL SPS,那么认为该UE的上行授权已经被配置。

(B)常规BSR是由某个逻辑信道有上行数据可传触发的,但RRC并没有配置该逻辑信道的logicalChannelSR-Mask参数。换句话说,如果UE已经触发了一个常规BSR,且已经配置了上行授权,此时若网侧将参数logicalChannelSR-Mask设置为true,就不会触发SR。logicalChannelSR-Mask参数属于逻辑信道的参数,在logicalChannelConfig信元中配置(见上文图3)。

综合(A)和(B),当UE触发了一个常规BSR,且已经配置了上行授权,同时该逻辑信道的logicalChannelSR-Mask为true,那么就不需要发送SR。

条件(A)和(B)的由来:   
       在最初的R9协议版本中,只要触发了常规BSR且该TTI时刻没有上行RB可用,就需要通过触发SR来申请资源,当时并没有增加(A)和(B)的限制,但后来随着协议的完善,发现UE在进行UL SPS时这里是有缺陷的。如果没有这两个条件,当UE处于UL SPS状态时,原本为了减少信令交互的SPS机制,可能会出现频繁发送SR申请资源的情况,这个与UL SPS的设计初衷是违背的。举个例子:UE在DRB1中进行UL SPS数据的周期传输,在某个非SPS周期的TTI时刻,DRB1中有新数据可传,满足常规BSR的触发条件,由于还没有到ULSPS周期的TTI时刻,所以没有可用的上行RB,此时UE将为DRB1触发一个SR过程。但实际上这个时候是不需要触发SR的,因为在UL SPS周期时刻到的时候,自然就有了上行RB资源,不需要进行申请。
       为了避免UE在UL SPS状态时不必要的SR发送,浪费SR资源,减少UE监测PDCCH的时间,2009年11月,高通、诺西等多家公司联合提出了这样的一个限制方案,从而当UE处于UL SPS状态的时候,可以控制特定逻辑信道的SR发送。
       比如,UE在UL SPS过程中,使用DRB1进行数据的周期上传,这个时候网侧可以将DRB1的logicalChannelSR-Mask设置为true,那么UE在配置了UL SPS之后,就不会因DRB1有了新数据而触发SR过程了。

(2)分配有上行资源,并且填充比特数大于或等于BSR控制单元与其MAC子头的比特数之和,此时将触发一个BSR,且该BSR叫做填充BSR(Padding BSR)。之所以增加这种机制,主要是基于有效利用资源的考虑。示意图参考下文的图7。

(图7)

(3)重传定时器retxBSR-Timer超时,并且UE在某个逻辑信道组中的任意一个逻辑信道有可传数据,此时UE将会触发一个BSR,且该BSR也叫做常规BSR。

(4)周期定时器periodicBSR-Timer超时,此时UE将会触发一个BSR,且该BSR叫做周期BSR(Periodic BSR)。之所以增加这种机制,是防止以上条件都不满足时,eNB侧也可以知道UE的资源需求,为UE分配适当的上行资源。

retxBSR定时器和periodicBSR定时器由RRC配置,可在RRCConnectionSetup、RRCConnectionReestablishment或RRCConnectionReconfiguration消息中的radioResourceConfigDedicated信元的mac-MainConfig字段中带给UE,如图8所示。 

(图8)

参数的取值类似于下面的表格所示,单位是子帧或ms,sf320表示320ms。

mac-MainConfig explicitValue :
{
          ul-SCH-Config
          {
                maxHARQ-Tx                     n4,
                periodicBSR-Timer             sf10,                
                retxBSR-Timer                   sf320,
                ttiBundling                          FALSE
          }
         ... ...
 }

尽管有多个事件可以触发BSR,但一个MAC PDU中最多只能包含一个BSR MAC控制单元,且常规BSR和周期BSR优先于填充BSR的发送。

retxBSR定时器和periodicBSR定时器启动或重启的时机

(1)如果UE已经触发了一个BSR,且在该TTI有新数据传输的上行RB资源,那么除截短BSR外,启动或重启periodicBSR定时器。

(2)如果UE已经触发了一个BSR,且在该TTI有新数据传输的上行RB资源,启动或重启retxBSR定时器。

(3)一旦UE收到了在UL-SCH上传输新数据的授权,则重启retxBSR定时器。

当上行授权可以满足所有待传数据的传输,但不足以额外传输BSR控制单元及其MAC子头的比特总和时,UE将取消全部触发的BSR。当传输的MAC PDU中已经包含了BSR,则取消全部触发的BSR。

前文已经提到,网侧收到的BSR控制单元中只有三种类型:长BSR、短BSR和截短BSR,这些是从BSR长度的角度分类的,而常规BSR、填充BSR和周期BSR,则是从BSR触发原因的角度分类的。这两种分类之间存在着一定的关系,比如对于常规BSR来说,既可能是长BSR也可能是短BSR,下面具体说说这两种分类方式之间的关系。

6.常规BSR、填充BSR、周期BSR与短BSR、截短BSR、长BSR的关系

(1)常规BSR

如果UE发送的是常规BSR,且该TTI有超过1个逻辑信道组有可传数据,那么上报长BSR,否则上报短BSR。上面图6的场景1,有3个逻辑信道组有数据可传,此时上报长BSR;在场景2中,只有1个逻辑信道组有数据可传,此时上报短BSR;场景3与场景1的触发原因相同,也是由于LCG-ID1中只有1个逻辑信道5有可传数据,但因为LCG-ID0中的逻辑信道1也有可传数据,所以上报长BSR。

(2)填充BSR

(A)如果填充比特数大于或等于短BSR与其MAC子头的比特数之和(即2个字节),但小于长BSR与其MAC子头的比特数之和(即4个字节),那么:

--------(a)如果上报BSR的TTI时刻有超过1个逻辑信道组的数据可传,则上报具有最高优先级逻辑信道的逻辑信道组的截短BSR。之所以称为截短BSR,是因为此时有多个逻辑信道组的数据可传,按理说应该上报长BSR的,但限于可用的填充资源有限,只能发送1个逻辑信道组的BSR,所以定义了这个“截短BSR”,以便于区分一个字节的短BSR。

--------(b)否则,上报短BSR。

(B)否则,如果填充比特数大于或等于长BSR与其MAC子头的比特数之和,则上报长BSR。此时不需要关心有多少个逻辑信道组有数据可传,统一向网侧报长BSR。

(3)周期BSR

如果UE发送的是周期BSR,且该TTI有超过1个逻辑信道组有可传数据,那么上报长BSR,否则上报短BSR,不会上报截短BSR。

我们在讨论常规BSR、周期BSR、填充BSR的时候,它的修饰词常常是“触发”(trigger),而在描述长BSR、短BSR、截短BSR的时候,它的修饰词往往是“发送”(report),注意这里的区别。上面几种类型的关系总结如下:

 

(图9) 

  • 2
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
上行grant受限和上行BSR很高是与移动通信网络中的上行链路质量相关的两个问题。 首先,上行grant受限指在移动通信网络中,上行链路资源会被分配给多个用户争夺使用。当请求上行资源的用户过多时,基站会根据一定的调度算法来分配资源,每个用户获得的资源可能会受到限制。这种情况下会导致上行grant受限,即用户无法获得足够的资源进行上行传输,从而影响网络性能和用户体验。 其次,上行BSR(Buffer Status Report)很高是指用户设备缓冲区中待发送数据的数量较多。在移动通信网络中,用户设备发送的数据通常会先缓存在设备的缓冲区中,然后再根据网络的情况选择合适的时机进行发送。当用户设备中的待发送数据较多时,上行BSR就会很高。高上行BSR可能是由于网络拥塞、链路质量差或用户设备负载过高等因素导致的。高上行BSR会增加设备的发送延迟,降低数据传输的实时性,影响用户体验。 针对这两个问题,可以通过以下方法进行优化和改进: 1. 针对上行grant受限问题,可以采用更智能的调度算法,如基于优先级或负载均衡的调度策略,以公平且高效地分配上行资源。 2. 对于上行BSR很高问题,可以考虑增加网络容量、优化网络拓扑结构,以增加链路资源,缓解网络拥塞。同时,还可以利用数据压缩、流量管理等技术手段减少用户设备中待发送数据的数量。 3. 引入新的通信技术和网络架构,如5G、物联网等,提供更高的上行带宽和更低的延迟,以满足日益增长的上行业务需求。 4. 对于个别用户设备上行BSR很高的情况,可以进行适当的设备优化,如增加缓冲区大小、调整数据发送策略等,提升上行传输性能。 通过以上措施的综合应用,可以有效解决上行grant受限和上行BSR很高的问题,提升移动通信网络的性能和用户体验。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值