【学术论文】5G波束故障恢复设计与实现
摘要：
在5G毫米波系统中，由于信道波动较为剧烈，可能发生基站与用户之间的波束失准。波束故障恢复可以帮助基站或用户根据波束测量结果调整当前故障波束到可用的波束，从而避免波束失准造成的频繁无线链路失败。系统地阐述了5G波束故障恢复的设计与实现，包括波束故障探测、候选波束识别、波束恢复请求传输以及基站响应等步骤，为进一步研究波束故障恢复提供参考。
0 引言
波束赋形技术作为第五代移动通信系统（5th-Generation，5G）的关键技术之一，可以有效对抗路径损耗，从而提升系统覆盖范围和容量[1]。通常，波束与用户之间对准得越好，该波束提供的信号增益越大。然而在毫米波系统中，由于信道突然波动、意外障碍中断、用户设备(User Equipment，UE)旋转等因素影响，可能导致5G基站(New Radio NodeB，gNB)与UE之间的波束失准。在这种情况下，UE不能解码任何下行链路(Downlink，DL)信号和/或gNB不能解码由于gNB和UE之间的波束未对准而导致的任何上行链路(Uplink，UL)信号[2]。如果这些故障重复出现，则UE将陷入无线链路故障(Radio Link Failure，RLF)，因此有必要定义和研究波束恢复以避免由于波束故障造成的频繁RLF。在3GPP RAN1 NR Adhoc1次会议上达成了以下协议[3]：新空口(New Radio，NR)支持由UE触发波束故障恢复。
波束故障恢复的主要原理是帮助gNB或UE根据波束测量结果调整当前故障波束到其他可用的波束，从而避免波束失准造成的频繁无线链路失败。NR支持由UE触发波束故障恢复的原因主要是考虑到上行波束故障事件由gNB检测，因此可以通过gNB触发上行波束管理来实现波束恢复。而对于下行波束，波束故障事件由UE检测，由于UE可以有最近的波束测量结果，因此波束恢复过程将由UE触发。通常意义上，波束故障恢复主要指下行波束故障恢复。
截至2018年6月，3GPP已经完成了通过基于非竞争的随机接入过程来实现波束恢复的标准化工作[4]，接下来将陆续开展对通过基于竞争的随机接入过程实现波束恢复和基于物理上行控制信道（Physical Uplink Control Channel，PUCCH）的波束恢复的研究工作。
基于现有标准，本文将从终端侧的角度研究通过基于竞争的随机接入实现波束故障恢复，并对波束故障恢复的方案进行详细阐述。
1 波束故障恢复设计总则
1.1 波束故障恢复与RLF的区别
波束故障恢复与RLF的区别如下[5]：
(1)无线链路监测（Radio Link Monitoring，RLM）的参考信号集合包括用于波束管理和层三移动性的同步信号/物理广播信道（Synchronization Signal/Physical Broadcast Channel，SS/PBCH）块和信道状态信息参考信号（Channel State Information Reference Signal，CSI-RS）。而波束故障恢复的参考信号包括用于波束管理的SS/PBCH块和CSI-RS。两者的参考信号可能不相同，这取决于网络配置。
(2)波束故障恢复是短期流程，可以更加频繁地提供指示；RLF/RLM是长期流程，可以提供周期性的指示。
(3)RLF/RLM是基于假想的下行物理控制信道（Physical Downlink Control Channel，PDCCH）的块差错率（Block Error Rate，BLER）与Qin/Qout的对比结果，用于提供是否同步的指示和评估，而波束故障恢复可以用层一参考信号接收功率（Layer One-Reference Signal Receive Power，L1-RSRP）测量。
1.2 波束故障恢复设计思路
第一步，当出现下行波束故障时，如果UE具有替代/可行的波束来替换当前故障的波束，则有机会避免由波束故障引起的RLF。如图1所示，如果UE检测到波束故障并且具有替代/可行波束，则UE可以尝试基于替代/可行波束进行接入。由于gNB不能确定接收波束以接收来自UE的波束恢复信号，因此gNB可以扫描接收波束以接收恢复信号。第二步，如果接入成功，则可以使用替代波束进行数据传输和接收。因此波束故障恢复的触发条件包括两个内容：(1)发现波束故障事件；(2)找到候选波束。随后，为了使得基站尽早得知波束故障并利用候选波束更新故障波束，UE需要指示波束故障事件以及上报候选波束给基站，即波束故障恢复的第三步是发送波束故障恢复请求（Beam Failure Recovery Request，BFRQ）给基站，第四步是gNB对UE关于BFRQ的响应。在目前的3GPP规范中支持以下信道用于BFRQ的传输，包括基于非竞争的物理随机接入信道（Physical Random Access Channel，PRACH）、PUCCH，并将进一步研究基于竞争的PRACH作为基于非竞争的PRACH的补充[6]。表1针对通过PUCCH和PRACH分别传输BFRQ的优缺点[7]进行了分析。
从表1中可以看出，PUCCH和PRACH传输BFRQ的方案各有利弊，考虑到PRACH的适用范围更广、基于非竞争的PRACH不会涉及冲突解决，本文将研究通过基于竞争的PRACH传输BFRQ的波束故障恢复的设计与实现。
1.3 常见高层参数
表2总结了波束故障恢复流程中涉及到的参数以及其具体含义。
2 波束故障恢复的设计与实现
基于非竞争的PRACH进行波束故障恢复包括4个步骤[8]：（1）波束故障探测；（2）候选波束识别；（3）BFRQ传输；（4）UE监听gNB对BFRQ的响应。图2显示了波束故障恢复的实现流程，下面将对这几部分分别展开说明。
2.1 波束故障探测
(1) 探测波束集合
当UE配置有高层参数Beam-Failure-Detection- RS-ResourceConfig时，高层信令配置的周期CSI-RS资源索引集合就是波束故障探测集合
；当UE没有配置Beam-Failure-Detection-RS-ResourceConfig高层参数时，UE将集合
确定为与其所监听的PDCCH的解调参考信号（Demodulation Reference Signal，DMRS）满足准协同定位（Quasi-colocation，QCL）关系的周期CSI-RS或SS/PBCH块。
(2)波束故障的探测方式
波束故障的检测条件是基于假想的PDCCH的BLER，当某个波束的BLER高于门限值Qout，LR时，认为该波束此刻是故障的，其中Qout，LR对应于高层参数RLM-IS-OOS-thresholdConfig的默认值。
(3)波束故障的条件
UE将结合
中参考信号的BLER以及门限值Qout，LR来评估无线链路的质量。具体地，对于集合
，UE只评估集合中与UE所监听的PDCCH DMRS满足QCL关系的周期CSI-RS或SS/PBCH块。当UE所评估的所有参考信号的无线链路质量都比Qout，LR差时，物理层将会给更高层一个指示，这个指示将会周期性通知给更高层。其中，在RAN1第92b会议上已达成协议，该周期应不低于2 ms[9]，具体周期由
中参考信号的最短周期与周期最小值（2 ms）之间的最大值决定。
当终端的高层收到连续的Beam-Failure-Instance- MaxCount个指示时，则认为波束故障事件成立[10]。
2.2 候选波束识别
(1)候选波束集合
候选波束集合
是由高层参数Candidate-Beam-RS-List配置的周期CSI-RS 资源索引和/或SS/PBCH块索引。
(2)候选波束的探测方式
候选波束的检测条件是L1-RSRP，当这个某个波束的L1-RSRP高于门限值Qin，LR时，认为该波束是可行的，其中Qin，LR对应于高层参数Beam-failure-candidate-beam-threshold的默认值。对于SS/PBCH块，UE将直接把Qin，LR应用于L1-RSRP；对于CSI-RS资源，UE将在用由较高层参数Pc_SS提供的值来缩放各个CSI-RS接收功率之后，再用该CSI-RS资源的Qin，LR阈值应用于L1-RSRP。
(3)候选波束识别的条件
在UE收到来自更高层的请求时，UE应该向该更高层提供集合
中的L1-RSRP值大于等于Qin，LR的周期性CSI-RS配置索引和/或SS / PBCH块索引。当UE至少向更高层上报了一个参考信号索引以及相对应的L1-RSRP时，则认为UE找到了候选波束。
2.3 BFRQ传输
当UE检测到波束故障并找到了至少一个候选波束时，将会向gNB发送BFRQ，其中包括波束故障事件指示以及候选波束信息。对于基于非竞争的PRACH用于BFRQ传输，UE将上报一个候选波束索引qnew给gNB，这个候选波束索引qnew由更高层根据UE上报的候选波束信息决定，并指示给UE。
UE将会被高层参数Beam-failure-recovery-request-RACH-Resource配置用于传输BFRQ的基于非竞争的PRACH资源，其中候选波束参考信号索引与专有PRACH资源相关联。
2.4 UE监听基站对BFRQ的响应
UE会分别由高层参数Beam-failure-Recovery- Response-CORESET和高层参数search-space-config配置一个控制资源集（Control Resource Set，CORESET）和相应的搜索空间用于监听PDCCH。当UE在时隙n传输了BFRQ后，将从时隙(n+4)开始并在高层参数Beam-failure-recovery-request-window配置的窗口内监听用小区无线网络临时标识（Cell Radio Network Temporary Identifier，C-RNTI）加扰的一种DCI（Downlink Control Information，下行控制信息）格式，即gNB对BFRQ的响应。从这段期间到UE收到传输配置指示（Transmission Configuration Indication，TCI）状态的激活或者收到参数TCI-States-PDCCH之前，对于物理下行共享信道（Physical Downlink Share Channel，PDSCH）的接收，UE将假定其天线端口与正在监听的PDCCH满足相同的QCL关系。
当UE在窗口内成功收到基站对其BFRQ的响应时，则认为波束故障恢复成功。当UE直到Beam-failure-recovery-Timer到期也没有收到来自基站的BFRQ响应或者UE进行BFRQ传输的次数达到高层配置的最大次数时，则认为波束故障恢复失败，其中对于Beam-failure-recovery-Timer，UE在波束故障检测事件发生时开始Beam-failure- recovery-Timer计时，而当UE收到基站对BFRQ的响应时结束Beam-failure-recovery-Timer计时。对于通过PRACH的方式进行波束故障恢复，如果不成功，则触发RLF操作。
3 结论
波束故障恢复可以帮助gNB或UE根据波束测量结果调整当前故障波束到其他可用的波束，从而避免波束失准造成的频繁无线链路失败并实现快速波束恢复。本文对5G中基于竞争的PRACH的波束故障恢复的设计与实现进行了系统的阐述，具体流程包括波束故障探测、候选波束识别、BFRQ传输以及gNB响应等，为后续的波束故障恢复研究提供重要的参考。
参考文献
[1] 高程，张光辉，朱雪田.大规模天线标准化进展[J].中国电子科学研究院学报，2018，13(1)：29-34.
[2] Samsung.R1-1612514：discussions on beam recovery mechanism[S/OL].(2016-11-04)[2018-06-10].http：//www. 3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/Docs/.
[3] Qualcomm，Nokia，ASB，et al.R1-1701481：WF on beam recovery in multi-beam NR systems[S/OL].(2017-01-20) [2018-06-10].http：//www.3gpp.org/ftp/tsg_ran/WG1_R1/TSGR1_AH/NR_AH_1701/Docs/.
[4] 3GPP.TS 38.213(V15.1.0)：NR；Physical layer procedures for control[S/OL].(2018-04-08)[2018-06-10].http：//www.3gpp.org/ftp//Specs/archive/ 38_series/38.213/.
[5] Huawei，HiSilicon. R1-1805878：Remaining details on NR RLM[S/OL].(2016-05-11)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_93/Docs/.
[6] ZTE，MediaTek，vivo，et al.R1-1709309：WF on beam recovery[S/OL].(2017-05-18)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_89/Docs/.
[7] LG Electronics.R1-16710283：Discussion on beam failure recovery[S/OL].(2017-06-17)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_AH/NR_AH_1706/Docs/.
[8] vivo.R1-1707245：Beam recovery based on NR-PDCCH and NR-PDSCH[S/OL].(2017-05-06)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/ WG1_RL1/TSGR1_89/Docs/.
[9] Intel，MediaTek，ZTE，et al.R1-1805565：WF on remaining issues for beam failure recovery[S/OL].(2018-04-18)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_92b/Docs/.
[10] MediaTek.R1-1715012：Offline discussion on beam recovery mechanism[S/OL].(2017-08-26)[2018-06-10].http：//www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_90/Docs/.
作者信息:
高 程，朱雪田，刘春花
(中国电信股份有限公司北京研究院 网络技术与规划部，北京102209)