Overview
之所以把波束放在第二章，是因为在5G NR中，massive MIMO是一个默认使用的关键性技术，同时由于NR使用的是高频段，无线信号存在衰减过快的问题，所以NR-RAN使用波束复形作为上下行数据传输模式。我们知道波束复形需要至少4根天线且只能向具体角度和方位上的终端提供数据传输服务，这就与NR基站的无线信号至少需要覆盖一个扇区相冲突，（其实这个地方说是冲突并不是很准确，只是说单一方向不能形成扇区）为了解决这一冲突，5G NR采用将一个特定的波束复形传输在时间上进行分片，具体说就是在不同的时间将特定的波束复形指向不同的角度，从而达到覆盖一个扇区或者360度区域的需求。这个也导致了一个SSB(SS/PBCH Block)必须和一个指定的PRACH资源联合起来才可以让UE接入对应的小区(这个我们后面会详细介绍)。
基于以上考虑，咱们必须先把Beam这块先说明白，这样大家在阅读后面相关章节的时候才不会感到困惑。
N.B. 本章节主要基于对www.sharetechnote.com作者一篇名为“Beam Management”的文章以及三星SE，Manoharan Ramalingam一篇名为“5G NR Management and Beam Scheduling”的文章翻译而来。尤其是第一篇文章，我认为如果只是出于了解背景技术目的的话该篇文章足够了。另外，推荐大家读读www.sharetechnote.com，里面有很多4G，5G相关的文章。当然大家也可以一边读这位大牛的文章一边和我写的博文对比，这样更容易加深理解。
为什么是Massive MIMO？
个人认为5G使用Massive MIMO的主要原因是5G“没有其他选择了”。因为5G所使用的频率信号是高频信号，也就是我们通常所说的毫米波。高频意味着单根天线的尺寸将会非常小(这是因为天线的长度和波长成正比，而频率和波长又成反比；频率越高，波长越短，因此天线也就越短)而且每根天线的口径(接收无线电波能量的区域)也会非常小。为了克服在高频情况下接收端口径小的问题，5G NR就需要使用数量众多的传输天线。这应该就是主要原因了。当然，在我们使用Massive MIMO技术时，大规模天线阵列还有以下优点：
上面这段翻译不如原文读起来那么让人信服。那个www.sharetechnote.com作者一篇名为“Beam Management”理解起来更舒服。
Massive MIMO可以提升10倍能力并且同时提升100倍的辐射能量效率(radiated energy-efficiency)
Massive MIMO的建设成本较低，而且功耗较小
由于在抗衰落上的鲁棒性，Massive MMIO在空口时延上有显著减小。
Massive MiMO简化了多路存取层。
Massive MIMO提升了对无意的人为干扰和恶意的干扰方面的鲁棒性。
为什么我们需要Beam？
由于无线电波的天然特性，当我们使用低频段或者中频段无线信号时，基站可以在所有方向（图A）或者在一个相对较广的角度内（图B）传输信号或者数据。然而，当我们使用高频段时，除了使用大型天线矩阵留给我们的选择并不多。图C是使用大型天线矩阵时无线信号的辐射为波束的场景
为什么需要波束管理/波束控制?
我不认为在高频部署场景中使用波束传输信号只是出于“选择的目的”，某种程度上说这是“必须的”实现方法。在中/低频域不使用大规模天线阵列的情况下(如图A,B所示)，一个单一的天线传输就能同时覆盖多个UE。然而，当无线信号辐射变为波束形状后(如图C)，就很难使用单个的天线传输同时覆盖多个UE除非这些UE在地理位置上靠的特别近。
为了解决这一问题，我们需要一个非常复杂的方法来管理/控制波束从而达到能覆盖分散在各个方向上多UE的目的。该管理/控制机制应能随着环境不同而调整。 
当发送端没有接收端的位置信息时的Beam management/Control
现在我们来看一个比较明确的例子，在这个例子里beam management/control机制非常重要。让我考虑下面的例子：一个运行在高频下带有massive MIMO功能的基站， 有一个UE在基站附近，然后你正准备给这个UE开机；一旦这个UE开机，它就会开始同步流程。基站始终传输同步信号并且这些同步信号会传送给每个在该基站覆盖范围内的UE。但是当基站所发送的同步信号是在波束中传输的时候就会带来一连串的问题：实际情况是波束只能指向一个很窄的区域并且在同一时间内它不能同时覆盖一个较宽阔区域，那么问题就来了，基站如何能找到UE并让同步信号准确到达UE呢？ 
那么怎么解决这个问题呢？如果每个工作都像你在脑海中设想的那样简单，那么你可能会给出一个像下图一样的解决方案：你可能会希望在所有的方向同时传输多个波束。看起来很好，不是吗？:-)
上面的解决方案可行吗，合理吗，效率如何？ 简单点说答案是 不。(原因显而易见：这么多的波束需要的天线数量恐怕天线阵列也无法提供，而且复杂度也会非常高，更不用提实际上可能还会存在很多覆盖上的盲点)
那么有没有其他可行的解决方案呢？对于这个问题可能会有很多的想法和建议，但是目前最流行的提议是：基站在指定的时间向指定的方向传输波束，然后在下一个时间帧改变一点方向继续传输波束，这样直到基站能扫遍它能覆盖的所有区域。
那么，下一个问题就是如果将该理念在无线帧设计中反映并实现。在这里我们不会去展开来讲，因为这个过于复杂，而且目前3GPP协议中也没有对这一块进行描述介绍，我在本章的附录后面列举了一些与此相关的TDocs，有兴趣的可以自己查找翻阅。
当终端和基站的连接已经建立时的Beam Management/Control
现在我们来谈谈更多的波束管理的例子。根据3GPP TDocs描述，绝大部分的波束管理涉及的都是主题为“在连接态下的波束管理”，只有一个作为主题“小区搜索/初始化接入”的一部分作为某一具体章节提到过。
一旦UE接入一个网络并且处于连接态，至少有一个波束（或者多个波束）正确地将UE和无线网连接在一起。理论上说有多种不同的方法可以使用波束将UE和无线网连接起来，但是我们大致上可以将其精简为以下4种不同的情况。 
在case 1中，UE和无线网通过单一的TRP(Tx/Rx Point)和单一波束相连接。
在case 2中，UE和无线网通过多TRP(Tx/Rx Point)相连，每个TRP有一个单一的波束。
在case 3中，UE和无线网通过单一的TRP(Tx/Rx Point)和多波束相连接。
在case 4中，UE和无线网通过多TRP(Tx/Rx Point)相连，每个TRP有多个波束。
- 无线网传输为波束管理传输特定的参考信号
- UE探测该参考信号并执行对应的测量，然后发送反馈给无线网
你可能已经注意到了，这个普遍概念和LTE中使用的CSI上报机制非常相似。然而，还有一些细节需要决定，例如：
基带信号(symbol)生成公式
资源分配映射(如何将这些参考符号分配给指定的resource element)
UE多长时间需要执行这些测量
UE怎样上报这些测量结果？(通过RRC消息？或者通过MAC/PHY层的处理)
这些问题我们会在后面的博文中详细解释，此处就不再展开讨论。
NR Beam Management in a NutShell
如果要把NR Beam Management用几秒钟做一个简单的解释，那么下面的图表是一个很好的总结。正如你所见，波束管理在两个时期中扮演着重要角色 - 在RACH流程和呼叫连接(call connection)之后 
Reference
'Beam Management'，www.sharetechnote.com
'5G NR Management and Beam Scheduling', Manoharan Ramalingam, www.3gpp.org
3GPP R1-166089. 3GPP TSG RAN WG1 Meeting #86 - Beam Management Procedure for NR MIMO
3GPP R1-166214. 3GPP TSG RAN WG1 Meeting #86 - Discussion on the beam management for the NR
3GPP R1-166389. 3GPP TSG RAN WG1 Meeting #86 - Beam Management in Millimeter Wave Systems
3GPP R1-166565. 3GPP TSG RAN WG1 Meeting #86 - Beam management without prior beam information
3GPP R1-166657. 3GPP TSG RAN WG1 Meeting #86 - Views on beam management for NR
3GPP R1-166785. 3GPP TSG RAN WG1 Meeting #86 - Discussion on TRP beamforming and beam management
3GPP R1-167466. 3GPP TSG RAN WG1 Meeting #86 - Key principles for beam management
3GPP R1-167467. 3GPP TSG RAN WG1 Meeting #86 - Reference signals and reports to support beam management
3GPP R1-167543. 3GPP TSG RAN WG1 Meeting #86 - Beam Management Considerations for above 6 GHz NR
3GPP R1-1712221. 3GPP TSG RAN WG1 Meeting #90 - DL Beam Management Framework
3GPP R1-1610243. 3GPP TSG-RAN WG1 #86-BIS : On procedures for beam selection and feedback signaling
3GPP 38.300 NR;Overall description;Stage-2 - 9.2.4 Measurements
————————————————
版权声明：本文为CSDN博主「梓轩爸爸」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zhangbin_leo/article/details/124589370