C114门户论坛百科APPEN| 举报 切换到宽版

亚星游戏官网

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索
查看: 38125|回复: 19

[技术讨论] 【原创】CoMP随笔(三) [复制链接]

军衔等级:

亚星游戏官网-yaxin222  上尉

注册:2010-9-219
发表于 2014-3-18 15:51:17 |显示全部楼层
---欢迎讨论

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的筵席已散?
已有 1 人评分家园分 收起 理由
家园副管09 + 20 赞一个!

总评分: 家园分 + 20   查看全部评分

举报本楼

本帖有 19 个回帖,您需要登录后才能浏览 登录 | 注册
您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系大家 |网站地图  

GMT+8, 2024-11-17 00:27 , Processed in 0.188985 second(s), 18 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部
XML 地图 | Sitemap 地图