|
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？是的，我部分同意。你呢？ |
|
|
