谈谈 CoMP
CoMP随笔
(2014-02 闫剑龙)
(一)
1/ 从coordination说起
协作（coordination），从LTE的第一个版本（R8）开始就引入了小区之间的coordination；但CoMP里的coordination与R8/9/10里的coordination的区别在哪里？
1）松紧的程度: R8/9/10里的coordination是一种slack/slow的coordination，200ms进行一次协作就足够了；而CoMP需要对subframe量级上（1ms）上的PDSCH行为进行协作，因此在协作的密切程度上，CoMP is more more tighter。
2）所利用的信息（information）：R8/9/10里的coordination所使用的信息都是一些long-term 意义上的average channel quality,如RNTP/HII/OI，RSRP/RSRQ等，这些信息体现都是large scale意义上的无线信道信息；而CoMP使用的是大家都很熟悉的物理层triple-I: RI/PMI/CQI,这些都是基于subframe 量级short-term意义上的无线信道状态信息，所以虽然二者都是协调，但所使用的信息层次不在一个层面上；
3）标准化的努力重点不一样：R8/9里的coordination，标准化的重点是在X2接口上，如讨论在eNB之间需要传递哪些信息以帮助它们进行协调；而CoMP的标准化重点在air上，即空口是大头，需要重新定义UE与eNB之间的行为约定，甚至需要颠覆刚刚在R10版达成一致的一些准测和概念，这是后话，暂且不表。
4）对网络的部署要求不一样：对于point与point之间的信息传递时延，R8/9/10里的coordination是基于X2 protocol, 而X2 link一般认为是not-so-low-latency的（十几个毫秒）；而CoMP则必须为low-latency（微秒级），因此光纤是标配；且在point之间的时频（time-frequency）同步要求上，CoMP(尤其是coherent JT)对同步指标要比R8/9/10里的coordination严格的多（要高一个数量级左右，如果后者时间同步精度为3us，则CoMP 的时间同步精度要达到0.3us，才能使得coherent JT成为可能，否则效果是一塌糊涂。）
因此从这个意义上说，CoMP的瓶颈之一是在部署场景的高门槛上，这也是dual-connectivity 把对ponit之间的传输要求又回落到not-so-low-latency的原因之一。呵呵，CoMP就是一白富美，一般屌丝可望不可及。
(二)
2/ 小区虚拟化（virtual Cell）
在进入主题之前，再稍微啰嗦几个概念：
1.Cell：在不同的context里，cell有着不同的含义：在做无线RRM的人看来，cell就是一
个逻辑资源的基本管理单位；在RF人眼里，cell就是一挂天线或天线组在一个载波上所覆盖的一块地理扇区，也即通常说的载扇；在做物理层的人看来，cell就是一个将各种信号打上自己“烙印”的生产单位，这个所谓的“烙印”就是小区的PCI（physical-layer Cell Identity），简称小区标识（CellID），而打“烙印”的主要目的是为了所谓的干扰随机化（randomize interference），virtual cell里的cell指的也是这个概念。（一点题外话：LTE 载波聚合中的Primary Cell/Secondary Cell中的Cell，个人理解就是一个比较扭曲的概念，其中理由，可以后面阐述）
2.参考信号(Reference signal)：这个概念估计大家听得耳朵都长老茧了，的确：RS是LTE
的灵魂，几乎所有LTE关键技术的设计基石都是RS；LTE的版本演进几乎就是RS的设计规则不断自我颠覆并前行的体现。
上面说到：Cell从物理层上看就是一个将自己的PCI作为一枚seed种植到各种伪随机序列发生器中去的发生单位，来实现小区间干扰随机化的目的；但对于不同的信号，这枚seed所埋的“深浅”是不一样的：有的是被“埋”在数据被调制到复符号（complex symbol）之前，如PDCCH/PDSCH；有的是被“埋”在层映射之后预编码之前，如DL-DMRS；还有的是被“埋”在预编码之后RE Mapping之前，如CRS/CSI-RS；
我们说LTE的终极目的就是更好地实现PDCCH/PDSCH的demodulation, 而对于将PCI埋在modulation之前的PDCCH/PDSCH来说，PCI并不会直接影响PDCCH/PDSCH的demodulation；而PDCCH/PDSCH的解调都属于相干解调（coherent demodulation）,因此对应的信道估计是PDCCH/PDSCH解调的先决条件（PDCCH用CRS来估计，PDSCH用CRS 或DL-DMRS来估计，CSI-RS虽然不参与直接参与信道估计，但它直接影响了DL-DMRS 的precoding；而ePDCCH可以视为一种特殊的PDSCH）；
对于DL RS（CRS/DL DMRS/CSI-RS），都是频域上的伪随机序列(上面提到该伪随机序列初始化的关键参数之一就是小区的PCI)，经过各种规则的作用后映射到RE，然后经IFFT 从对应的天线端口上发送到空中。
对于UL RS（PUCCH/PUSCH DMRS,SRS），都是ZC序列，我们知道不同root的ZC是不正交的（但相关性有高有低，相关性低的可以认为是quasi-orthogonal）；原理上相同root 的ZC sequence才具备正交的可能，正交的实现方式可以是cs，也可以occ；所以同一小区内要使用同一个root的序列，而小区之间使用不同root的序列跳跃来实现干扰随机化。对于一个小区，具体所使用的ZC是哪一个，这里面又是通过伪随机序列的运算来实现的，而伪随机序列初始化的关键参数又是这个PCI。
所以：PCI作为伪随机序列初始化的种子，对于下行来说，直接决定了DL RS的序列值；
对于上行来说，直接决定了ZC base sequence的具体选择；因此从这个意义上说：PCI
决定了小区的RS，而RS又决定了数据的解调；因此将PCI视为整个小区物理层的cornerstone这一点都不过分。
说了这么多，和小区虚拟化有啥关系？其实小区虚拟化就是完成参考信号与PCI之间的解耦（de-couple）；也就是说参考信号的“seed”可以比较自由地定义而不需要一定是那个PCI。
小区虚拟化和CoMP有什么关系？其实，R11的CoMP，在标准化方面主要就做了两件事情：一个就是这个所谓的小区虚拟化，解除上/下行参考信号与PCI之间的绑定关系，而引入了terminal-specific或transmission point –specific的参考信号定义机制；第二个就是引入了不同端口类型之间的quasi-co location定义，端口的实质也就是参考信号；
R11的CoMP，在下行上目前看应只支持DPS，传说中的JT，无论是non-coherent JT还是coherent JT，目前似乎仍是传说。
CoMP，it’s just a joke?
(三)
3/ 再谈参考信号
CRS：
是整个LTE的基石，动不得，涉及方方面面；虽然在很多情况下被视为是一个包袱，但不敢也不能甩，否则整个system就失去了最基本的驱动力，转不起来了；这有点类似太祖与咱大宋的关系，你懂的。
CSI-RS:
在RE mapping上不会影响控制域；且在时频维度上比较稀疏，话说回来太密了也不行:密了就会影响R8/R9 UE的PDSCH解调性能；CSI-RS在频域上的稀疏，指的是在单个RB pair内部所占用的RE少，CSI-RS是全带宽发射的，所以CSI-RS的稀疏更多是体现在时间轴上；CSI-RS 从R10到R11的变化是由cell-specific转变为TP-specific；由于CSI-RS在配置上有很大的灵活度，所以对于CoMP cluster里的多个TP（transmission point）来说，只要数量不超过一定的数目，还是比较容易实现相互正交的CSI-RS资源配置，因此在正交的情况下各个TP的CSI-RS sequence可以是一样的序列（seed），而没有必要使用不同的seed；
但，在R11定义了一个结构CSI process，其目的是要求UE能基于multiple transmission hypotheses来上报多个CSI report；如协作节点最大个数max_point_num在R11中定义为3，则一个UE所需要配置的CSI process的最多数量为2^(max_point_num-1)=4种，其分别对应另外2个TP为00/01/10/11的四种假定（其中0表示mute，1表示NZP CSI-RS）；因此在一些情况下UE需要在IMR（Interference Measurement Resource）上测量多个TP同时发送NZP CSI-RS，这样若再使用相同的sequence就有问题了，所以对于shared cell-ID deployment，CSI-RS Sequence的seed也要是TP-specific的；再说这样做只会有好处而基本没有什么代价，何乐而不为呢？
DL-DMRS：
其sequence初始化的Seed在R8是UE-Specific的（即RNTI也参与了初始化）；但在R9/R10改回了cell-specific，但为了支持MU-MIMO，把RNTI替换为了单bit的SCID，也就是说在相同的下行时频资源上，整个小区上只会有2个不同的Sequence，以改善当2个UE间的PMI 不全正交带来的干扰问题（即PMI是quasi-orthogonal）；而对于PMI互相关比较强（即空间隔离度比较低）的2个UE只能通过不同的端口(端口7或端口8，也即不同OCC)来保证DL-DMRS的正交，因此R9/R10的MU-MIMO最多支持4个rank-1或2个rank-2的UE；我们知道MU-MIMO是干扰受限型，总层数超过4层后，层间干扰是主要问题，因此标准也不打算支持超过4层的MU-MIMO。但对于R8基于TM7的MU-MIMO（注意不是TM5），因为DMRS是terminal-specific的，因此只要各个UE之间的空间隔离度足够，那么就可以一起来做MU-MIMO（多用户赋形）；对于这种情况3GPP并没有就UE的个数做一个数量上的限制；这种场景下参与MU-MIMO的UE个数理论上是受限于发射端的天线个数以及UE的空间分布情况；
对于CoMP的场景4（shared cell-ID deployment），在整个shared cell-id的地理范围上具备实施MU-MIMO的UE个数往往远远会超过4，也就是说R9/R10下的MU-MIMO机制已经远不能满足该场景下的MU-MIMO需求；在该问题上，E///在比较早的一篇提案中甚至建议将DL-DMRS的sequence初始化机制回退到R8。
对于场景4，如果只是将每个TP虚拟成一个cell以获取area split gain，并在每个TP对应的virtual cell里依然沿用R9/R10的机制，那么DL-DMRS的sequence可以像CSI-RS那样是TP-specific的而没有必要回退到R8的terminal-specific方式；如果考虑DPS（dynamic point selection）,处于TP coverage边缘的UE可以在网络的控制下动态选择某neighbor point来传送PDSCH，那么这种情况下，DL-DMRS sequence的seed也应follow 该neighbor point的或更好的一种方式是为这些边缘UE系统再来定义一个“common seed”来优化干扰，所以3GPP 在R11中支持为DL-DMRS定义2个seed，当然协议并没有强制这2个seed一定不能一样；具体当前DL-DMRS用的是哪一个seed，这通过DCI来动态指定。
UL-DMRS：
上行与下行不太一样：对于上行，接受者一般来说只有一个（JR: Joint Reception除外），所以在同一个时频资源上，理论上要求DMRS一定要正交；而下行，在同一个时频资源上，接受者（也就是UE）之间只要能保证比较好的空间隔离度即可（即quasi-orthogonal）；所以对于上行，无论是CoMP还是non-CoMP，是R8/9/10还是R11，原则都是一样的：即保证在receiver侧DMRS务必是正交的；如果receiver有多个（即JR），那么需要在这多个receiver 上同时保证DMRS的正交性，也即正交的保证范围从单个receiver扩大到多个，其实这也是一种“virtual”的方式；如果要支持UL 的DPS（Dynamic Point Selection），那么UE的UL-DMRS 的seed也需要支持动态地在各个Point的seed（即virtual cell-ID）之间切换，这与DL-DMRS 的情况不太一样：DL-DMRS的正交性由OCC来保证，因此上面所说的“common seed”其主要作用是完成干扰随机化；而UL-DMRS是ZC序列，其正交性优先由CS（Cyclic Shift,也即phase rotation）来保证，其次才是OCC，所以ZC序列必须一致；因此对于上行，如果支持DPS，那么DMRS的seed必须要follow目标TP；
在R8一开始，PUSCH的JR就是支持的，协议上允许通过一个cell-specific的偏置量来使得多个相邻小区可以具有相同的ZC base sequence，也即UE发射的PUSCH DMRS可以同时保证在这多个相邻小区上都是正交的，因此这多个相邻小区可以同时接受该PUSCH；但不支持PUCCH的JR，因为对于PUCCH没有这种机制；
在R11，个人理解主要的变化如下：
1）UL-DMRS的seed是TP-Specific的；即不同的TP可以定义不同的seed（即Virtual-CellID）；2）对于UE来说，UL-DMRS的seed配置是dedicated，甚至PUCCH与PUSCH可以配置不同的seed；虽然seed的配置是terminal-specific的，但这并不意味着UL-DMRS的seed是terminal-specific的（参见上面第一点）；
3）terminal-specific粒度上的seed配置，主要是为了实现UE粒度上的UL CoMP schema的灵活控制和选择，即不同的UE，根据其不同的地理位置，可以使用不同的UL-CoMP Schema，如JR或DPS；
4）PUCCH在R11也支持JR；
关于JT（Joint Transmission）：
至于JT，首先可以排除coherent-JT，因为这个东西太理想，太高大上，太不实际（qualcomm: when practice constraints are taken into account, the gains deteriorate swiftly）；那么non-coherent JT呢？仿真出来的结果也不理想：所有小区总的平均吞吐量与不使用的对比反而是下降，只是对边缘UE（worst 5%）提升非常明显，但代价是降低了总的网络性能，这个代价使得边缘UE的提升没有了justice，operator们也比较难接受，毕竟劫富济贫太过分了，打土豪分田地也不是这么个干法。（仿真结果来源于自LG/Samsung/Orange/Huawei/NTT DOCOMO/Motorola的6 co-authors的一份报告，非3GPP提案；另外在qualcomm的仿真报告中，gain虽不是负值但很小，和cost相比同样失去了justice）。
联想到很早的时候（2010年？）E///在一篇提案中就对CoMP的各种scheme建议了一个标准化投入上的优先级顺序，从高到低依次是：1)DPS 2)CS/CB 3)non-coherent JT 4)coherent-JT；现在看来还是很老道的；(对于coherent-JT，带头大哥是Huawei？)
R11没有支持JT已是标准上的事实；而在R12里，eCoMP已变为一个小众议题，所关心的重点也是聚焦在non-ideal backhaul上；在E///的一篇提案中认为在non-ideal backhaul的情况下CoMP基本上没有多大的意义，因为CoMP本身固有的特质就是一定要low latency；在该提案中E///的建议是在传统ICIC的手段基础上再考虑一些额外的增强方式来提升系统性能，即coordination的紧密程度又从tight的CoMP回到了比较loose的传统ICIC增强上。
CoMP的筵席已散？