LTE,Listen to Ericsson?
不得不承认,E///一直都是领头羊的位置。
这篇文章就以当时CA载波管理标准制定中若干问题,来分析分析E///的霸主思路。
今天要讲的是,多个载波上系统消息如何获取的问题。
首先一个场景是载波添加的时候如何尽快获取Scell上的系统消息。
在之前的3G中,多个载波的系统消息都在Pcell上传输,这意味着用户一旦驻留到Pcell就可以知道其当前部署场景中的所有载波的系统消息。
该方法可以在CA业务真正开始之前就获取各载波系统消息,此时时延显然是最小的。但是对系统消息的开销很大。
因此LTE中决定不这么做,仅在每个载波上仅广播自己的系统消息。
那如何获取其他载波的系统消息?
如果通过直接去监听各个载波,则会比较慢,因为SIB1的周期就是80ms,对于CA业务的发起而言太慢。
通过专用信令来通知用户关键的系统消息?
这是一种可行的方式。这和切换时在切换信令中通知用户目标小区的系统消息是一个道理。因此这点在当时讨论的时候基本大家都可以达成共识。
毫无悬念。至此,天下太平。
可后续当Scell上有系统消息更新该如何通知用户呢(Scell SI Change)?
如果手机按照原有方式,即在每个载波上都周期性读paging和SIB1?这样做,极度耗电。显然不可行。
于是矛盾产生。分为两大派系:
其中一派以HW和DCM认为:
其他载波上的系统消息修改指示通过Pcell发,这样,UE仅需要周期性读Pcell的上的paging和SIB1,再去读改变的相应载波的系统消息即可。
该方法其好处就是paging机制是R8R9的老的机制,改动也不大,而且对于耗电有所改善,但存在问题是:
终归是需要周期性获取系统消息改变通知。系统消息的获取还是不及时,因为总是需要在系统消息的modify周期之后才能得到。
另一个派系则是E///为首:
希望采用专用信令通知一个个通知用户。其理由是:
在Scell添加的时,系统消息也是通过专用信令通知用户,因此在Scell 的SI Change时也自然而言可以采用该方法,有一定延续性。
E///觉得这样最简单,又快。
而DCM则始终反对。其反驳理由是认为若在网络中很多CA用户其实信令开销也很大。
E///再进行反驳说:
通知的仅仅只是MIB,SIB1和SIB2等关键信息,能有多大个字节?
再说了,在一个小区中CA的原本旨意也是提升部分用户的峰值速率,也不是让人人都去做载波聚合,因此也不会成百上千个用户同时进行CA。
为何不能接受?
本来这两大派系还是对半僵持,到后来最终还是DCM做出了让步,接受了CA用户没有太多,一个个通知,信令开销也可以接收的事实。
那为什么后来写到标准中为何变成了:
若Scell的SI发生改变,则需要通知聚合了该载波的CA用户,通知他要将scell先删除后建立呢?
为什么不是直接信令告诉一下用户,SCell上系统消息进行了哪些改变的这种增量配置呢?
其原因在于,迄今为止,没有哪个专用信令用来通知系统消息改变了哪些的这个流程。所以要是这么做就需要重新设计RRC信令。
那该问题最终如何落笔呢?
最终还是得看E///。E///提议说,要不直接通知用户先删除后建立Scell吧。
而且E///给出了可行的理由:
其分析了MIB,SIB1和SIB2中关键字段,认为其中参数都不会频繁变化,像SIB2中携带的随机接入参数可能变更比较频繁,但是R10中用户不在Scell进行随机接入。
因此这么做是可行的。
因此就沿用了之前给用户删除和增加小区的流程,即会议记录里下面这句话:
Scell SI changes will only be handled by removal + addition of the concerning Scell。
该问题在多次争吵中终于达成一致。
再延伸来看看,说说下一个问题:
Why two steps?为什么要引入载波的添加, 之后进行激活这样两步?
首先要明白载波激活和去激活引入的初衷:
就是为了解决业务量波动的同时又可以起到省电的效果。业务量大的时候多个载波工作,不需要的时候仅Pcell工作。
也许又有人问,不就是要省电吗?DRX是否可以解决该问题?
按照 DRX的方案,若有多个载波,则意味这每一个载波总是在onduration 时间要醒过来,也需要进行测量,也是耗电的。
若是去激活掉不需要的载波,终归会节省一些电。因为去激活载波完全不听任何PDCCH,不发送数据,也不进行CQI测量。
注:为读取到激活和去激活的信令通知,Pcell始终不能被去激活。
当然一种方式是不引入显示方式,即增加载波时就默认为载波就是激活的,不需要的时候就直接删除载波。
E///为首的一大批公司提出了另外一种方式,要引入显示的激活和去激活过程,即载波先配置好,根据业务量进行显式激活去激活操作。
两种方式首先存在信令开销的差异,前者有个问题就是反反复复删除将导致每次都发生载波的一堆信息,而前者仅仅是反复激活和去激活的很少bit。如下图:
虽然说,若激活去激活的频度不高则信令负荷可能差别也不大。但是后者却更加具有实现的灵活性:
eNB可以选择何时激活载波。eNB可以选择配置完成之后,马上激活该Scell,也可以选择不马上激活,这完全取决于各公司算法实现。
因此额外引入激活和去激活流程基本上没有大的异议。
在定下来确实需要激活和去激活后,用何种信令通知用户激活和去激活的问题:
从消息的可靠性而言,RRC是最可靠的,其次是MAC,最后是PDCCH。而从消息的及时性而言,则是反之,PDCCH 是最快的,通常是子帧级别,但是带来的问题是引入了DCI新的格式设计,因此当时高层讨论的时候排除了该方案。
RRC是最慢的,通常十几个ms级别。RRC配置也存在一个问题:
若是根据业务量进行载波的激活和去激活,而该情况显然MAC最清楚。如果用RRC信令,则需要MAC跨层通知RRC,显然不是很合适。
E///当时强烈反对RRC方案。
最终还是选择了PDCCH和RRC之间的均衡,即MAC通知。
为便于理解,我将载波的管理过程串起来理一下(各公司算法实现不一):
1)UE在空闲态驻留在Pcell上,发起业务请求在Pcell;
2)若有业务量需求,配置一个Scell。
该Scell未激活,用户无需监听该Scell的调度信令。
因为该Scell未激活,没有调度,因此不需要测量CQI,但是还是需要测量RSRP/RSRQ,万一信道差了,就可以直接删除了。
3)可以基于一些进一步的细化条件决定是否激活该Scell。或者直接激活Scell。
若需要激活,则在Pcell上发送MAC CE激活该Scell,因为用户始终听Pcell。
4)当Scell激活后,数据在Pcell和Scell上同时收发。此时UE同时监听了Pcell和Scell。
5)若业务需求量小,则下发去激活的MAC CE(可以在任何一个cell下发),该Scell又恢复到配置但非激活状态。
现在回头看看,今天讨论的关于Scell系统消息添加和更新的问题,其实E///的思路还是很有道理的:
一切的原则就是想要尽快获取到配置载波的系统信息,可以给基站进行调度提供了一定灵活度,而不用限制基站还需要等一段时间,让用户获取到Scell的系统消息才进行。于是统一用专用信令通知即可。
后续显式载波激活和去激活也是为此考虑。
面对HW和DCM的唇枪舌战,E///能胜出,水平不一般。
LTE,Listen to Ericsson?是的,我部分同意。你呢?
联系客服