BeamManagement

Posted 2022-12-05 modem协议笔记

微信同步更新欢迎关注同名modem协议笔记

NR中所有的上下行信道的发送和接收都是基于波束。基站通过对信道质量的测量来动态选择UE和基站之间波束的方向和频率，进而完成通信。NR使用的频率信号是高频信号，高频意味着波长越短，天线也就越短。当无线信号辐射变为波束形状后，就很难使用单个的天线传输同时覆盖多个UE，因而NR的天线数量大大增加，形成更多波束，提升覆盖；NR使用Massive MIMO技术时，就需要使用大规模天线阵列，进而实现多用户空分，提升频谱利用率; 提升能量利用率，满足覆盖需求（特别是高频）。beam forming 不是本篇的重点(其实我也不太会)，可以百度看下具体内容。这里只关注3GPP spec中相关的波束管理的内容。

本篇的内容分散在38.331 ，38.321，38.212,38,213,38.214等。波束管理分为上行和下行波束管理，换个角度又可以分成idle 初始接入过程和connected mode过程，先看idle 初始接入过程。

idle 初始接入过程

首先根据支持band的情况进行底层扫频，decode 到SIB1时，可以通过ssb-PositionsInBurst 确定当前小区对应的SSB 数量信息。

inOneGroup(8bits): 当每半帧SSB max number=4时，最左边的4bit有效(从左到右依次为SSB 0～3)，其余4个暂时忽略；当每半帧SSB max number=8时，8个bits都有效，从左至右分别为SSB 0～7；当每半帧SSB max number=64时，8个bits都有效，从左至右，第一个bits对应SSB0，8，16，24，32，40，48，56；第二个bit对应SSB1，9，17，25，33，41，49，57；第三个bit对应 SSB 2，10，18，26，34，42，49，58,依次类推。bit=1代表对应的SSB有正常传输，就是在环境中有这个ssb，bit=0，代表环境中没有这个SSB。L=64的情况对应的是FR2， 在FR1中 L=4/8。如果对应的是FR2，那还会有groupPresence出现。

groupPresence(8bits) 针对的是SSB L=64的情况，用8bits表示，从左至右分别表示一组 SSB的情况，第一个bit对应SSB0～7，第二个bit对应SSB 8～15，第三个bit对应SSB 16～23，第4个bit对应SSB 24～31，第5个bit对应SSB 32~39，第6个bit对应SSB 40～47，第7个bit对应SSB 48～55，第8个bit对应SSB 56～63。

每半帧SSB max number L的确定与频谱相关，UE在小区搜索过程中就可以确定L的值，详见NR小区搜索(一) SSB。

举个例子 假如L=8，配置如下，那代表这个小区对应的SSB 0~7都有在传输，UE正常情况下可以测量到SSB0～7的信号值。

 

ssb-PositionsInBurst

inOneGroup '11111111'B

假如L=64

ssb-PositionsInBurst

inOneGroup '10101010'

groupPresence '01000000'

groupPresence代表SSB 8~15有在传输；具体还要看inOneGroup 代表实际SSB 8，10，12，14有在传输，UE可以在现实环境中测量到SSB 8/10/12/14的信号值。

 

SSB信息确定之后，UE小区搜索阶段就会选SSB信号最强的那个驻留，之后会进行随机接入，进行注册，在发起RACH发送preamble的时候，网络端就可以通过preamble确定UE所选的SSB，进而确定UE驻留小区的具体SSB信息，完成UE和基站的SSB beam配对，NR PRACH(四)PRACH与SSB的映射有解释preamble和SSB的关系，当然这里为了连续性还是简单看下。

假设L=8，inOneGroup '11111111'B   网络实际发送了SSB 0~7。

ssb-perRACH-OccasionAndCB-PreamblesPerSSB eight : 4, N=8,R=4, N=8 代表一个RO 映射到8个SSB，SSB n 就有4个连续的CB preamble，每个RO 的起始preamble index 是n*totalNumberOfRA-Preambles /N ，则SSB0 对应的CB preamble 为0～3，SSB1对应的CB preamble 为8～11，SSB2 对应的CB preamble 为16～19，SSB3对应的CB preamble 为 24～27，SSB4对应的CB preamble 为 32～35,SSB5对应的CB preamble 为 40～43,SSB6对应的CB preamble 为 48～51,SSB7对应的CB preamble 为 56～59。

如上图38.321中的描述，在发起initial RA前，UE会根据SIB1中的rsrp-ThresholdSSB,选取满足门限的SSB，如果所有的SSB都不满足门限，就任意选择一个SSB。SSB与PRACH配置相关联，UE选择关联的PRACH发送 msg1，基站侧通过对应的CB preamble就知道UE驻留的SSB信息，进而基站就会在UE选择的的SSB的方向上返回msg2/msg4，完成初始接入阶段，这就是基于波束的初始训练过程。

在初始接入阶段，基站和UE用SSB的索引，关联PRACH的发送时刻比较内涵的指示了波束信息；在RRC建立进入connected mode后，就可以通过TCI State来指示波束信息, 为利于后续内容理解，这里先看下TCI-state及QCL的概念。

TCI-state/QCL

在spec 38331 中，TCI State的定义如上，TCI State 描述的是1个或者2个下行参考信号之间的QCL 关系

PDSCH DMRS/PDCCH DMRS/CSI-RS都可以配置TCI-State，可能这段描述还是搞不清楚什么是QCL，下面看下38.214 5.1.5章节的相关描述。

TCI-State包含的内容就是1～2个下行参考信号和PDSCH DMRS /PDCCH DMRS /CSI-RS port的QCL关系，网络端可以通过qcl-Type1和qcl-Type2对两个下行参考信号配置QCL关系，如果配置2个下行参考信号的话，QCL type的值应该不同。

简单的说QCL 就是发送信号（目标信号和参考信号）的两个天线端口特性比较接近，指示源参考信号与目标参考信号 的相似程度，代表的是空域信道特性，相似程度分为4种，QCL-Type A: 多普勒频移，多普勒扩展，平均时延，时延扩展的4个方面相似；QCL-Type B:多普勒频移，多普勒扩展两个方面相似；QCL-Type C:多普勒频移,平均时延两个方面相似；QCL-Type D:空间参数 就是波束信息相似。

例如：PDSCH DM-RS 配置参考信号SSB，配置Type D时，则指示了PDSCH DMRS的发送波束和SSB的波束很类似（相同或接近）。波束是有方向性的，而TCI state这个关系主要给天线发送接收提供一个参考模板，根据配置的参考信号，设置空域特性，以便于UE和基站侧更好的通信。

 

connected mode DL Beam

在进入连接态后，DL 可以使用CSI-RS/SSB进行波束训练，上行使用Sounding RS进行波束训练。先看下行波束训练过程，DL 参考信号的RRC层配置结构如下。

CSI-RS有很多功能，例如移动性管理，速率匹配，精准视频跟踪等(CSI部分目前只写了CSI-RS时频域资源配置的内容，后面再展开看其他内容)，这里仅介绍波束管理部分，用于波束训练的CSI-RS也叫CSI-RS BM。

CSI-RS部分RRC层参数配置

aperiodicTriggeringOffset：触发非周期CSI-RS的时隙（DCI触发）到发送CSI-RS的时隙间隔。

nzp-CSI-RS-Resources:关联NZP-CSI-RS资源集的资源，对于CSI，每个资源集最多8个NZP CSI。

trs-Info:配置为Tracking信道跟踪的CSI-RS,与beam management不相干，trs-info和下面的Repetition不能同时配置。

Repetition :是CSI-RS BM的一个关键参数，可以配置On 或Off。设置为Off时，表示CSI-RS资源集中的CSI-RS资源发送时，使用了不同的波束空域传输filter，就是CSI-RS发送的波束不重复，这时候基站发送波束扫描，UE可以保持接收波束不变，进行波束训练；设置为On 时，表示CSI-RS发送的波束重复，即基站在相同波束上发送CSI-RS, UE可以扫描接收波束，进行波束训练。

Repetition =off时， 基站发送不同的CSI-RS供UE进行测量并上报对应的CRI(CSI-RS Resource Indicator)，基站根据CRI 对波束进行调整，完成波束训练。

Repetition =On时， 基站发送CSI-RS发送的波束重复， UE根据自己的波束测量结果，自行调整接收波束，选择最强波束，完成波束训练，这种场景下UE不需要上报CRI，具体训练方式由UE端算法决定。

虽然波束训练的具体策略，spec上都没提及，是厂家私有做法，但是通常的模型是基站在初始接入SSB波束周围，发送一个或多个比较窄的波束（CSI-RS,对应CSI-RS Resource Indicator, CRI）;UE对CSI-RS参考信号测量，得到L1-RSRP结果，上报不同CRI的测量结果；例如下图基站在SSB0 发送比较窄的CSI-RS 0/1/2 , SSB1发送CSI-RS 3/4/5 ,CSI-RS配下来后，就也就有了方向性，只是这个方向性，UE端感知不到；之后UE 上报CRI，PMI等信息，网络端就可以知道UE的相对具体位置和方向性信息；当然TDD场景，SRS也可以辅助确定上述信息；PDCCH/PDSCH DMRS都可以与CSI-RS 设置QCL 关系，进而就可以很好的确定方向性等等，当UE在信号状况不好的情况下，基站就可以控制UE进行beam的切换，基站选择L1-RSRP最强的CSI-RS对应的波束进行下行信道发送，进而使得UE切换到信号状况良好的beam上。

下行波束训练的大体过程基本阐述完了，具体的工作机制，简单的说DL 波束训练有两条路可走，一条是PDSCH DMRS TCI/QCL的配置流程，通过RRC层在PDSCH配置TCI state 集合->MAC CE激活不超过8个TCI state->DCI field 确定最终选用的TCI-state，另一条是PDCCH DMRS RCI/QCL的配置流程，通过RRC 层配置PDCCH 的TCI state 集合->MAC CE激活其中1个TCI-state，下面我们按照RRC->MAC CE->DCI的顺序逐层看下这两种方式spec中的相关描述。

RRC 层PDSCH

38331 g60版本中，目前PDSCH中最大支持配置128个TCI State，而PDCCH最大支持64个TCI state。

PDSCH 的TCI State 信息，首先在RRC中配置，通过tci-StatesToAddModList 最多配置128个，对于UE来说，RRC信令中配置的TCI State list是下行各种波束（SSB/CSI-RS）的一个大集合，后面还需要基站通过MAC CE/DCI field进一步在这个集合中指示具体的波束信息。

虽然38.331中规定PDSCH 的TCI State 信息，通过tci-StatesToAddModList 最多配置128个，但是实际中这个个数与UE的能力相关。

基站侧会在PDSCH-Config中配置 M个TCI-State 给UE，然后根据DCI field transmission Configuration Indication 激活对应的TCI -state 关系，根据tci-state 调整波束方向后，再decode PDSCH；其中M 由UE能力参数maxNumberConfiguredTCIstatesPerCC决定。

38.306中tci-StatePDSCH中有指出，对于FR2，最少要支持配置64 个TCI states，38.331中规定的最大值128是可选项不强制要求；对于FR1，支持配置的TCI state必须要大于等于supported band 允许的最大SSB数设定，不考虑频谱共享的场景，band支持的最大SSB个数就由38.213 4.1中规定的SSB pattern case A~C(FR1 只能是caseA~C)相关,具体的说就是每半帧SSB的最大发送次数L，具体可以参考小区搜索(一)SSB。 

PDCCH

PDCCH 的TCI State信息，在CORESET参数中下发，最多配置64个，通过上图中蓝色字体tci-StatesPDCCH-ToAddList 的描述，PDCCH配置的TCI State来自PDSCH-config中TCI state ，是PDSCH-config 中TCI state的子集。

如下如图的简单例子，在pdsch-config中通过tci-stateToAddModlist 只配置tci-state id 0/1，在tci-StatedPDCCH-ToAddList中配置的tci-state id 为0，这个0指的就是pdsch-config中tci-stateToAddModlist配置的tci-state id 0。

tci-PresentInDCI 这个参数比较关键，在RRC层配置tci state 集合的情况下，首先会在MAC CE中激活一部分TCI state(最多8个)，如果tci-PresentInDCI 有enable 的话，最终基站会通过在DCI中 的field Transmission configuration indication指示最终UE要采用的那个TCI state。

MAC层

 

spec 38321介绍了TCI State相关的MAC CE，包括：

TCI States Activation/Deactivation for UE-specific PDSCH MAC CE

Enhanced TCI States Activation/Deactivation for UE-specific PDSCH MAC CE

TCI State Indication for UE-specific PDCCH MAC CE

TCI state MAC CE: 用0/1表示RRC高层中配置的TCI State列表中对应索引的激活状态，最多激活8个TCI State。

 

PDSCH

网络侧可以通过下发TCI states Activation for UE-specific PDSCH MAC CE或者Enhanced TCI states Activation for UE-specific PDSCH MAC CE,激活最多8个TCI states，之后通过DCI 1_1/1_2 中的field “Transmission Configuration Indication”激活其中一个TCI-state。对应MAC CE的图示如下。通过这段描述，可以直接看出，PDSCH 的TCI states激活流程就是RRC层配置TCI states集合(最多128个)-> MAC CE 激活最多8个TCI states，最后通过DCI field transmission Configuration Indication 激活其中一个，也就是tci-PresentInDCI 这个参数enable与否 是与PDSCH 的tci state激活流程相关联的。

DCI 1_1/1_2 中，Transmission configuration indication

DCI field Transmission configuration indication，在tci-PresentInDCI(DCI 1_1)配置为enabled时，此字段长度为3 bits，表示PDSCH 的TCI State的索引(对应于MAC CE中的最多8个TCI state)；在不配置tci-PresentInDCI 时，字段长度为0。

DCI 1_2  应用于URLLC场景，tci-PresentInDCI-1-2(DCI 1_2)enable时，RRC层可以为DCI 1_2 transmission configuration indication配置成1～3bits；RRC层不配置时，对应0bits;从这段描述可以看出DCI 1_2的transmission configuration indication配置更为灵活，正常情况下transmission configuration indication bit大小应该可以表示MAC CE中激活的TCI state 个数，比如MAC CE中激活2个tci states，DCI field应该配置为1bits；;MAC CE中激活4个tci states，DCI field应该配置为2bits；MAC CE中激活8个tci states，DCI field应该配置为3bits。

MAC CE tci state与DCI field的映射关系在38.321 中有描述，简单的说，如果MAC CE 激活(Ti=1)的TCI state 是 TCI state 1/4/8/9/11/13/15/17时，DCI field 的 3bits 对应的0～7 分别对应TCI state 1/4/8/9/11/13/15/17；DCI field transmission configuration indication 最大只能是3bits，所以通过MAC CE最多只能激活8个 TCI state。

对于DCI 1_2，DCI field transmission configuration indication 可以配置为1～3bits，如果配置为2bits时，MAC CE 却激活了6个TCI state,DCI field 2bits 只能表示4个TCI state，这时候只认为MAC CE 激活的前4个TCI states有效，忽略最后2个TCI state。

MAC 层激活TCI state需要处理时延，所以UE收到DCI 包含transmission Configuration Indication，且要在slot n 传输PDSCH(MAC CE)相关的PUCCH HARQ-ACK时，UE 应该在 slot n+3N_subframe,u_slot +1 才能通过DCI 激活TCI state。 

上面的内容有一个场景并没有考虑到，就是在刚刚进入connected mode时，有段时间UE是没有收到网络端配置的TCI-state ，initial TCI state一般会在注册阶段 完成AS 层SMC后，通过第一条rrc reconfiguration配置下来，此前会用DCI 1_0进行PDSCH的调度或者配置了TCI states，还没有收到MAC CE的激活命令前，PDSCH的DMRS天线端口应该参照什么样的信道特征去工作？当然spec肯定考虑到了，下面就来看下。

不配置tci-PresentInDCI时或使用DCI 1_0调度的PDSCH，UE采用和PDCCH DMRS相同的波束去接收。

tci-PresentInDCI/tci-PresentDCI-1-2 设置为enabled，对应的DL DCI与调度的PDSCH的时间偏移大于等于timeDurationForQCL时，UE收到initial RRC层 TCI state的配置，但是还未收到激活的MAC CE，此时UE可以假设服务小区的PDSCH的DM-RS端口与在初始接入过程中确定的SSB是准共址(QCL)，其中qcl type设置为“typeA”，并且在适用时，qcl也设置为“typeD”。

PDSCH 的TCI states的激活机制基本上说完了，再总结下流程，首先在RRC 层PDSCH-Config中配置TCI -state 集合，最多128个；之后通过MAC CE最多激活其中的8个TCI state；最后通过DCI field transmission configuration indication 选用MAC CE激活的8个TCI states的其中一个，但是实际中， 情况可能不同 比如 RRC 只配置了 8 个TCI-state 或者更少，这时候只要MAC CE 激活其中1个就可以，不需要DCI，具体还是看基站侧的策略。

 

PDCCH

PDCCH的TCI state激活过程比PDSCH简单，首先PDCCH 的TCI State信息，在RRC层CORESET参数中下发，最多配置64个，通过tci-StatesPDCCH-ToAddList 配置具体的TCI state信息，PDCCH配置的TCI State来自PDSCH-config中TCI state ，是PDSCH-config 中TCI state的子集；之后通过TCI State Indication for UE-specific PDCCH MAC CE激活其中一个，MAC CE的描述如下。

PDCCH激活TCI states前后的规定的相关描述在38.213中。 

除CORESET 0外的其他CORESET，如果UE没有在tci-StatesPDCCH-ToAddList和tci-StatesPDCCH-ToReleaseList配置TCI state，或者提供了不止一个TCI states但是没有收到激活TCI 的MAC CE时，UE要假设PDCCH的DMRS 天线port与初始接入时的SSB是QCL的关系；

如果UE有在tci-StatesPDCCH-ToAddList和tci-StatesPDCCH-ToReleaseList中配置不止一个TCI states，但是没有收到MAC CE的激活命令，这时UE在进行由Reconfiguration with sync 触发的随机接入过程，UE要假设PDCCH 的DMRS天线与SSB或者CSI-RS是QCL的关系。

对于CORESET 0，则认为PDCCH DMRS是与激活的TCI state是QCL的关系；如果此时对应的场景不是PDCCH order触发的CFRA过程，恰巧也没有收到TCI 激活的MAC CE，这时候认为PDCCH DMRS与SSB是QCL的关系。 

除CORESET 0外的其他CORESET，如果UE只提供了一个TCI state，或者MAC CE激活了其中一个TCI state，UE要假设PDCCH DMRS是与配置的TCI state对应的下行参考信号是QCL的关系；对于CORESET 0，UE 期望 下发的MAC CE 激活命令指示的 TCI state 是 qcl-Type=typeD的CSI-RS 。

MAC 层激活TCI state需要处理时延，如果UE 在slot k 传输MAC CE对应的PUCCH HARQ-ACK，那MAC CE激活的TCI state生效的时间要对应时隙k+3N_subframe,u_slot +1。

除了上述内容之外，spec 38.214中在配置TCI state时，对配置的reference set和QCL type还有一些规定，这里简单列出，就不做说明了。

 

不同CSI resource 和QCL的对应关系

PDCCH/PDSCH DMRS和QCL 的规定

connected mode DL beam 训练的流程如下，根据基站的策略不同，流程可能略有不同。

最后看个DL 波束训练过程的例子，首先看PDSCH/PDCCH 的tci states配置情况。

PDSCH 配置了6个TCI state，PDCCH中只用了PDSCH tci state集合中的前4个。

当前UE驻留在SSB1 上的小区，SSB1的信号状况最好基站测有配置CSI 的periodic 上报，UE会周期上报CRI PMI 等信息，CRI用于告知基站侧UE目前测量到的最好CSI-RS的index。

之后UE 依次上报CRI 3->1->0  告知基站侧最好的CSI-RS信息。

之后UE收到了PDCCH MAC CE，代表要激活TCI State id 0，TCI state 0 代表PDCCH DMRS与nzp csi-rs 0 qcl type =typeA，而 csi-rs 0与 SSB 0 qcl type=type c，间接的说明PDCCH DMRS与SSB 0也有某种qcl关系，最后UE切换到了SSB0上，即此时信号状况最好的SSB上。

通过CRI的上报顺序，大概可以推测 基站在SSB0 发送CSI-RS 0/1 , SSB1发送CSI-RS 3/4，用于波束微调，而UE 是从SSB1 靠近CSI-RS 3的位置，逐渐移动到CSI-RS 0的位置，因而UE会按顺序上报CRI 3->1->0，最后换到SSB0上。

目前看到的log，PDSCH配置了QCL/TCI的集合，但是PDSCH都不会收到MAC CE和对应的DCI(RRC 层也没有配置tci-PresentInDCI)，只会通过MAC CE激活PDCCH 的QCL/TCI关系，根据上面的描述，这种情况下PDSCH DMRS和PDCCH DMRS采用相同的波束接收。 

 

connected mode UL

上行方向beam训练也有针对PUSCH 和PUCCH的两种机制，先看PUSCH。UE完成初始接入后，上行方向上主要通过Sounding RS(SRS)进行波束训练，SRS配置参数中，usage 设为 beamManagement时，表示用于波束管理的SRS。用于波束管理的SRS resourceset个数，每个resourceset中SRS resource个数和UE能力有关，在38306中定义。

当SRS resourceset 中的usage 设置为 beamManagement时，同一个SRS-resourceset中同时刻只能用1个SRS resource 传输，但是不同SRS resource sets中的SRS resource在时域相同位置可以同时发送；隐含告诉我们的意思就是说SRS resource set中的1 个SRS Resource对应一个波束，基站侧指示具体SRS 信息就对应beam信息，因此同一个resouce set中的多个SRS resource 不能同时发送，如果多个SRS同时发送，基站侧难以区分具体beam，也就无法达到波束训练的目的。更具体的基站侧可以在SRS Resource中，通过配置spatialRelationInfo参数来配置SRS的发送波束信息。

SRS resource资源配置中的SRS-SpatialRelationInfo，即SRS resource和参考信号的对应关系，代表波束的对应关系，参考信号可以是下行SSB，CSI-RS或者是uplinkBWP指示的SRS。

之前讲了下行波束训练，通过QCL传递波束关系，一般在SSB波束周围，发送一个或多个比较窄的波束（CSI-RS CRI），因此下行方向可以进行从宽波束到窄波束的训练；而上行波束训练，基站指示的spatialRelationInfo就是指定了对应的上行波束和参考信号波束完全相同，不支持逐步波束细化训练。

上行SRS波束训练可以通过两种方式实现，当一个或多个SRS资源集的SRS资源，spatialRelationInfo配置为不同发送波束时，UE自主发送SRS波束，基站保持接收波束不变，例如不配置spatialRelationInfo 时，由UE自行发送SRS波束，基站侧对UE 的SRS进行测量，进行上行波束训练。

或者当一个或多个SRS资源集中的SRS资源，spatialRelationInfo配置为相同发送波束信息时，即UE发送SRS波束不变，基站可以进行接收波束扫描，进行上行波束训练。

在进行完上述过程后，基站侧通过测量就可以确定具体SRS信息，之后可以通过DCI 0_1/0_2 中的SRS resource indicator字段指示对应的SRS资源，SRS 资源和波束一一对应，所以也就隐含的告知了UE 所用采用的PUSCH上行波束。

 

PUCCH这边一般流程是RRC高层配置最后通过PUCCH spatial relation Activation/Deactivation MAC CE激活或者去激活的方式。

RRC 层在PUCCH-Config中配置PUCCH-SpatialRelationInfo 代表PUCCH 和参考信号的空域信息，告知UE PUCCH的发送的方向性应该参照哪个参考信号，与QCL有点类似，其中参考信号可以是SSB/CSI-RS/SRS，采用CSI-RS的场景一般是TDD根据UL/DL 的信道互易性。

下面分别是RRC层和MAC CE的结构。

UL beam 控制机制，目前经验有限，接触的log也有限，还没有见过实际log有配置的情况，不太能详细讲述，通常见到的也都是DL通过 PDCCH DMRS TCI/QCL的路径进行的beam management。

上面的内容都是Beam正常工作的场景，如果遇到不能通过QCL/TCI修正beam的场景，UE就会发生Beam failure,之后就需要先进行beam failure recovery 的方式尝试恢复正常连接，具体的BFD和BFR的过程下一篇再继续。