打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
LTE:MAC复用和逻辑信道优先级

MAC复用和逻辑信道优先级

     MAC层负责将多个逻辑信道(logicchannel)复用到同一个传输信道(transportchannel)上。UE每个TTI只能发送一个MACPDU(不考虑空分复用和载波集合的情况),但可能来自多个逻辑信道的RLCSDU需要放到这同一个MACPDU上,这就是MAC复用的由来。如图1、图2所示,多个逻辑信道可能复用到同一个传输信道上。

1:上行信道复用

 


2:下行信道复用


     对于下行而言,MAC复用(multiplexing)和逻辑信道优先级(logicalchannel prioritization)是留给eNodeB来实现的。不同的厂商可能有不同的实现。

     对于上行而言,UE利用分配到的无线资源创建MACPDU并传输的过程是完全规范化的,这就保证接入同一cell的所有UE遵循相同的规范,以一致的方式满足每个配置的无线承载的QoS

     本文介绍的就是UE侧的MAC层复用实现。

     eNodeB是基于per-UE而不是per-bearer分配上行无线资源的,哪些无线承载的数据能够放入分配的无线资源中传输是由UE决定的。

     基于ULgrant分配的上行无线资源,UE需要决定包含在新的MACPDU中的每个逻辑信道的数据总量,如果必要的话,UE还要为MACcontrol element分配资源。换句话说,eNodeB通过ULgrant分配给某UE的上行资源是确定的。该UE基于RRC信令LogicalChannelConfig给定的配置,以及协议规定的规则,来决定放置哪些逻辑信道的数据以及每个逻辑信道放置多少数据。

     MAC PDU只有一个,但要复用的逻辑信道却有多个,这就要求为每个逻辑信道分配一个优先级。最高优先级的逻辑信道的数据优先包含在MACPDU中,接着是次高优先级的逻辑信道的数据,以此类推,直到分配的MACPDU已满或没有更多的数据要发送。每个逻辑信道的优先级是由LogicalChannelConfigpriority字段决定的,值越小,优先级越高。

     但这种分配方式可能使得高优先级的逻辑信道始终占据着eNodeB分配给该UE的无线资源,从而导致低优先级的逻辑信道被“饿死”。为了避免这种情况,LTE引入了优先比特率(PBRPrioritisedBit Rate)的概念,即在给逻辑信道分配资源之前,配置好各个逻辑信道的数据数率,从而为每个逻辑信道提供了最小数据速率保证,避免了低优先级的逻辑信道被“饿死”。PBR是通过LogicalChannelConfigprioritisedBitRate字段决定的。

3:逻辑信道配置


      MAC层使用类似于tokenbucket(令牌桶)的算法实现MAC复用。该算法的基本思想是基于令牌桶内是否有令牌以及令牌的多少来确定是否发送某逻辑信道的数据,并控制组装在MACPDU中的该逻辑信道的数据量。

     BSDBucketSize Duration)决定了令牌桶的“深度”。它与PBR共同决定了令牌桶的最大容量PBR× BSD。令牌桶的最大容量限制了每个逻辑信道可以挂起(pending,即缓存在buffer中)的数据总量。

     UE为每个逻辑信道j维护一个变量Bj,该变量指示了令牌桶里当前可用的token数,且每个token对应1Byte的数据。Bj在逻辑信道建立时初始化为0,且每个TTI增加PBR× TTI(如果prioritisedBitRate指定的PRBkBps8,则PRB8kBps,即每TTI往令牌桶内注入8kBps * 1ms = 8 Bytetoken)。Bj的值不能超过桶的最大容量PBR× BSD(以BSD=500ms为例,最大容量为8kBps* 500ms = 4k Byte)。

4:逻辑信道jMACPDU复用过程


       当有新传(注意:不是重传)的数据时,UE会按照如下步骤进行逻辑信道优先级化(Logical ChannelPrioritization):

     Step1: 对于所有Bj> 0的逻辑信道,按照优先级递减顺序组包,每个逻辑信道分配的无线资源只能满足PBR的要求。当某个逻辑信道的PBR配置成无穷大(“infinity”)时,只有当这个逻辑信道的资源得到满足后,才会考虑比它优先级低的逻辑信道。
     Step2
Bj减去逻辑信道j在步骤1里复用到MACPDU的所有MACSDUs的大小。(参考实现:对于逻辑信道j,每传输一个RLCSDU,先比较Bj是否大于0。如果Bj大于0,则往MACPDU中添加该SDU。然后将Bj减去该SDU的大小Tsdu,并确定是否满足PBR的要求。如此反复,直到Bj小于0,或满足PBR要求,则接着处理下一逻辑信道)
     Step3
:如果前两步执行完还剩有上行资源的话,则不管Bj的大小,把剩余的资源按照逻辑信道优先级分配给各个逻辑信道。只有当所有高优先级的逻辑信道的数据都发送完毕且ULgrant还未耗尽的情况下,低优先级的逻辑信道才能得到服务。即此时UE最大化高优先级的逻辑信道的数据传输。

     与此同时,UE还应遵循如下原则:(1)如果整个RLCSDU能够填入剩余的资源中,则不应对该SDU进行分段;(2)如果UE对逻辑信道中的RLCSDU进行分段,则应根据剩余资源的大小,尽量填入最大分段;(3UE应最大化数据的传输;(4)如果某个无线承载被挂起,则不应传输该无线承载对应逻辑信道的数据。

     如果所有的逻辑信道的PBR都设置成0kBps,则会按照严格的优先级顺序来组包。此时UE会最大限度地满足更高优先级的数据的传输。

 

5MAC复用过程举例


       如上图所示:Channel1优先级最高,所以其数据优先放入MACPDU中,Channel2次之,Channel3最后。所有逻辑信道都处理完后,还有剩余的无线资源,则优先放置Channel1的数据。

     按照令牌桶的原理,当某RLCSDU的大小大于Bj(即Bj– size(RLC SDU) < 0)时,令牌桶中没有足够的令牌用于发送该RLCSDU,此时该SDU应该放在RLC队列中,直到有足够的令牌后再进行传输。但如果SDU缓存在队列中的时间过长,又可能导致队列溢出,又导致了后续SDU的丢弃。权衡之下,LTE允许Bj< 0的情况,即通过“借贷”的方式,将SDU先发出去,后续再“还贷”,贷款没还清之前,不准发送SDU

     即当Bj> 0(令牌桶中有令牌),但Bj– sizeof(RLC SDU) < 0时,数据不会放到队列中,而是采取“借贷”的方式获取到足够的token(此时Bj减去 sizeof(RLC SDU)后,其值小于0),把数据复用到MACPDU中。只有将借到的token还完后(BjTTI增加PBR× TTI,直到Bj> 0),该逻辑信道才能进行后续的数据传输。

     该机制使得某个TTI给某个高优先级的逻辑信道分配更多的资源,使其Bj< 0。但到了下一个或几个TTI,由于Bj增加PBR× TTI后依然小于0,导致逻辑信道无资格再发送数据,从而保证若干个TTI内的公平。出来借,迟早是要还得嘛!

     这里还涉及到一个问题,Bj是在每个TTI开始时,还是在每个TTI结束时加上PBR× TTI?如果在前一个TTI,逻辑信道“借贷”的token数小于PBR× TTI,且在此TTI开始时Bj加上PBR× TTI,则此时Bj > 0,该逻辑信道并未因借贷而导致暂停RLCSDU传输。如果连续几个TTI都是这种情况且该逻辑信道的数据至此发送完毕,那么实际上“借贷”并未产生“归还后,才能继续发送”的效果。所以从实现的角度上看,个人觉得应该在TTI结束的时候Bj再加上PBR× TTI。(由于没有做过LTE手机的实现,这只是个人的想法,仅供参考)

     前面主要介绍了单个逻辑信道的令牌桶算法实现。对于多个逻辑信道,其信道优先级priority应该根据信息重要程度的不同,考虑以下相对优先级(按从高到低的顺序排列):

·       用于C-RNTI或来自UL-CCCH的数据的MACcontrol element

·       用于除“paddingBSR”外的BSRMACcontrol element

·       用于PHR或扩展PHRMACcontrol element

·       UL-CCCH的数据外,来自任意逻辑信道的数据

·       用于“paddingBSR”的MACcontrol element

     简单地做个小结:eNodeB通过限制令牌桶容量PBR× BSD、令牌添加速度PBR× TTI来限制每个逻辑信道的速率,来保证低优先级逻辑信道的数据传输以及一定的流控作用。

     可以看出,PBR越大,每TTI往令牌桶里放置的token越多,逻辑信道也就能够更快地发送数据。而PBR× BSD决定了某个TTI内,逻辑信道能够发送的最大数据量。

 

【参考资料】

[1]     3GPP 36.3215.4.3

[2]    《LTE系统MAC复用实体研究与设计》             冯川,李小文

[3]    LTE– The UMTS Long Term EvolutionFromTheory to PracticeSecondEdition》的4.4.2.6

[4]     Logicalchannel prioritization procedure for generating multiple uplinktransport blocks 

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
【热】打开小程序,算一算2024你的财运
看协议学5G—数据上传(下载)速率控制
一种基于IMS的可视电话系统
无线承载测试(RB) - Neal's Blog - 驀然回首 - 驀然回首,那人卻在,...
第三章 LTE MAC协议解读
LTE - 协议栈层
LTE调度机制很好的总结
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服