搜索
查看: 2314|回复: 0

演讲实录:5G新空口中的mMIMO技术

[复制链接]

250

主题

371

帖子

1054

积分

金牌会员

Rank: 6Rank: 6

积分
1054
发表于 2017-6-1 10:33:18 | 显示全部楼层 |阅读模式
Fred Vook(Nokia贝尔实验室)在2017年4月布鲁克林5G峰会上的讲座


关于mMIMO,我想指出并强调三个要点。首先,目前mMIMO正在部署中;其次, mMIMO能够带来容量增强和覆盖增强, 而无论它部署在哪个频段范围中;第三,与LTE接入网相比,3GPP NR 能够带来明显的好处。

从定义出发,我倾向认为mMIMO是传统MIMO技术的扩展。两天线阵列具有大量的可控制阵元,空口的物理层通过这些阵元可以对天线上的信号进行适配和控制。这个概念不仅限于一些特殊的实现,它在导航技术中已经被广泛使用了,现在5G才开始使用这个概念,同时,这个概念还有助于明确区分哪些系统不属于mMIMO。比如,四端口的LTE系统可以使用32个阵元的平板阵列来实现,但是如果这32个阵元聚合成4端口,且空中接口也只能对这4个天线端口进行控制,而不是能控制全部32个阵元,那么,我就不认为这样的系统是mMIMO。但是如果一个系统有32个阵元,且空口能直接控制这32个阵元,我就认为这属于mMIMO系统。
1.png


mMIMO的两个主要好处是,使用波束赋型的高增益来增强覆盖,以及使用高阶阵列复用来增强容量。这两种好处互相关联,两个都是你想要提高的。但是当你设计一个mMIMO系统时,你最好把注意力集中在追求其中的一项上。当然,你也可能有不同的想法,你或者关注提升覆盖,或者关注提升容量。

2.png


那么,为什么今天mMIMO变成了现实哪?这里的两个主要驱动因素是提升容量和覆盖,或者说mMIMO的带来两个主要好处也是当前市场迫切的需求。因为现在宏蜂窝已经不能满足容量需求,而使用毫米波会带来覆盖困难。增强覆盖对于6GHz以下频段也有帮助,我稍后会谈到。从技术角度看,采用AAS(Active Antenna)技术的mMIMO在技术上和商业上都具有可行性。
3.png


你需要把位于铁塔底部或者位于天线下面的盒子中的的无线部分、TRX单元和PA,都集成到AAS中。这样能节省占地空间,用电效率也更高。
4.png

另一个关键是标准支持性。MIMO技术可以回溯到3GPP R8甚至是早前的WCDMA,但mMIMO确实是在R13才出现, 名字是FD MIMO。FD MIMO可以支持最大16个天线端口,这16个端口是从互操作角度或者从空口角度来看的。因此小区参考信号和码本都是根据16个端口来设定的,但是产生这16个端口的阵列大小在R13中是可以随意设定的,波束选择也受限。根据UE反馈,可以采用巨大的阵列能做波束扫描,波束提升,波束赋形以及有限的波束选择。R14扩展到32个端口,R15则在研究NR技术是否能支持32端口,也许以后还要考虑64端口。但是需要再次强调阵列大小可以随意实现。

5.png

这一页说明性能的演进,以2TX/2RX系统做为基准,对于频谱效率或者平均用户吞吐量,8端口提升一倍,16端口提升2.5 倍,64端口提升3倍。这里是3GPP下行链路仿真的详细结论。

6.png


这只是仿真结果,对于现实中已经商用的系统,比如128阵列64TRXTD-LTE 2.6GHz,可以根据TDD的信道互易性做MU-MIMO配置,从而可以同时在多个用户中共享资源。如果关掉MU-MIMO功能,用户资源分配只能在波段间做频分复用。如果打开MU-MIMO功能,则全部用户同时共享全部资源。在外场测试中,关闭MU-MIMO,用户速率大约是80Mbps,打开MU-MIMO后,速率能达到360Mbps。这是实际部署中的真实结果。

7.png


考虑到使用高频和极差的路损情况,我们认为mMIMO能很好地解决这个问题。当我们开始考虑实现时,如果将<6GHz的解决方案用于毫米波,采用全数字波束赋型就会遇到一些问题,天线阵元需要TRX来驱动,带宽增加使A/D和D/A的功耗也增加,因此除了成本还存在功耗问题。好消息是阵子上的单元越来越小,天线也会更小一些,这就可以在RF部分和基带之间独立进行波束赋型,从而可以采用单一平板阵列或是多个平板阵列来形成无线波束。你可以用一个发射机驱动每一个无线波束,你可以使用多个变形波束,你可以做基带预编码操作,从基带角度做预编码,通过无线波束发送信号。而当你考虑覆盖方面的困难时,你开始考虑我们能在控制信道上能做什么。关于覆盖受限问题,你会发现覆盖受限不仅发生在数据信道也发生在控制信道,所以这导致在实践中使用波束赋形来承载系统的全部信道。

8.png


在系统中把波束赋形用于数据信道和控制信道,这也是现在NR正在发展的方向,我称之为基于波束的空中接口,这里一切都使用波束赋形,包括控制信道。所以你需要波束赋形,需要波束赋形传输控制信道信息,你需要做周期性的波束扫描操作,使用窄的波束赋形传输来覆盖扇区,在一个时隙你对准一个方向,在下一个时隙对准下一个方向,通过这样做来保持扫描覆盖整个扇区。用户需要做的是在分配给自己的时隙,当波束对准他们时,听取并得到控制信息,这是用户在初始接入网络阶段或者叫RACH阶段必须需做的。这至少是一个波束管理的课题,是NR支持而LTE不支持的。LTE规范定义了波束赋形控制信道,比如EPDCCH。但我理解这实现的并不顺利,也没有真正被采用。所以从一开始NR就定义全部使用波束赋形的空中接口,一切都是被波束赋形的。那么基站采用什么样的波束标准能够处理获取和保持一个波束集合,并用于发射和接受哪?而UE使用毫米波使得UE自身也拥有了波束赋形的能力。所以我们需要跟踪来自基站的波束和来自用户的波束,我们需要跟踪网络中调度的多个传输点。如果用户在网络中移动,你需要每个传输点有一个波束跟踪一个用户,在用户将要移动到的位置则需要切换到下一个TRP(发射/接收点),所以协调或者COMP功能从一开始就已经考虑进来了。

9.png


所以使用波束赋形承载控制信道的能力从一开始就是我们期望毫米波能做到的,在传统波段上使用波束赋形也是有用的。经常有人问,如果网格化的网络中站间距已经确定,运营商如何部署NR基站?假定这个网络使用800MHz载波,而下一步要采用3.5GHz频段下载波宽度300MHz进行部署。这里需要担心的是某些覆盖问题,所以除了业务信道使用波束赋形外,控制信道也必须使用波束赋形,以便使这个网络能够工作。NR的出现能很好地解决这个问题。我刚才提到NR的一个能力是全部信道都使用波束赋形,NR的第二个能力是支持空口上的高级CSI(信道状态信息)反馈,CSI获取是个很广泛和很丰富的课题,我曾经花了很长时间研究大量相关有趣的概念。3GPP目前正在做的是把这项研究划分为多个阶段,在第一阶段有个概念叫类型II线性混合码本,调查显示当采用这些码本并使用相同大小尺寸的阵列,与在R14给LTE定义的最优码本对比,NR能在速率上有很大增益,在小区边缘也一样。我被问过很多次的一个问题是,如果使用相同大小的天线阵列,NR和LTE相比会怎样?如同我早前说过的,天线阵列的大小跟实现有关,还跟标准支持的无线端口的数量有关。
10.png


对于相同尺寸的天线阵列,根据业务量不同NR码本承诺提升20% - 30%的平均用户速率,小区边缘的提升大约在15% - 65%之间。高级CSI和波束管理功能是NR优于LTE的两个领域。

11.png


最后说一下毫米波的多种场景,为了达到高比特速率,我们可以在发射机和接收机都使用多个平板,每个平板都使用交叉电极,我们假设这里也使用交叉极化阵元,在一个子平板上用交叉极化阵元组成一个波束。当我们组成这些波束时,每个子平板就有两个无线端口,这里我们使用4面板阵列,每个面板的两个交叉极化端口组成的波束可以用于对准用户。如同这里描述的一样,你可以想象这种接入方式,想象这些波束都对准了用户。对于用户,我可以做同样的事情,基站背板上的4个子面板可以用于接收。这样就有了一个8端口发射和8端口接收的系统。你可能问,我能达到8个秩吗?或者能使用超过2个秩做传输吗?因为这是使用普通波形期望做到的。你可以随意使用2个秩,因为极化和隔离都很好。但是我们能调度超过2个秩吗?这能工作吗?在3GPP信道模型中已经一致同意使用30GHz频段,并用于城区宏站的场景。在这个系统中,我们能达到平均4秩,这令我们惊讶,我们为什么能达到那么高的秩哪?当我拜访客户时,客户有8端口LTE阵列工作在28GHz,能做到8个发射8个接收。当我把结论展现给他们时,他们认为在实验室20GHz频段总能达到8秩。实验室的问题是有很多散射。关于这个模型,我们还有一些事情需要确认3GPP模型是否真的正确。你可以确认使用外场实验设备是否能达到这样的速率。无论如何,SU-MIMO可以在系统水平得到很好的增益。另外一件我们能做的事是我们有这类的平板阵列,我们可以把一个平板对准一个用户,另一个平板对准另一个用户,在MU-MIMO系统中得到很好的增益,但是会有很大开销。

12.png


现在用三点来结束我的演讲,mMIMO今天正在部署过程中;在LTE频段或毫米波频段都能提高覆盖和容量;3GPP NR承诺带来比LTE更大的增益。以上是我的全部内容,谢谢!

回复

使用道具 举报

您需要登录后才可以回帖 注册/登录

本版积分规则

关闭

站长推荐上一条 /2 下一条

Archiver|手机版|小黑屋|RF技术社区

GMT+8, 2024-4-27 23:55 , Processed in 0.083507 second(s), 10 queries , MemCache On.

Powered by Discuz! X3.4

Copyright © 2001-2024, Tencent Cloud.

快速回复 返回顶部 返回列表