SSB配置异常引起的问题解析过程

这篇是两个SSB配置异常导致的问题总结，第一个问题很简单，但是由于第一次看到这种log，看起来也比较蒙，另外也是没想到还能有这么弱鸡的问题；之后又遇到了另外一个SSB相关的问题，因为涉及时频域资源的确定，看起来相对来说就比较费劲，这两个都是lab问题。

长话短说，先看第一个问题，这个问题UE连注册都没有完成，从空口看，每次收到RRC setup 就fail了，具体过程如下。

06:35:34.650315 Registration request

06:35:34.650667 UL_CCCH / RRC Setup Req

06:35:34.747433 DL_CCCH / RRC Setup

06:35:34.749251 NR5GML1/CONFIG/High/NR5GML1 [ nr5g_ml1_rrc_intf.c 3134] RRC-ML1 config validate: BWP pdsch ded cfg validation

06:35:34.749252 NR5GML1/STRM/High/NR5GML1 [ nr5g_ml1_rrc_intf.c 2786] RRC-ML1 config validate tci id 0: serv_cell_idx 0 ssb_id=1 ssb_bmask=0x1 failed

06:35:34.749253 NR5GML1/STRM/High/NR5GML1 [ nr5g_ml1_rrc_intf.c 3194] RRC-ML1 config validate tci: Dedicated pdsch validation TCI state references active 0x0000000000000000000000000 addmod 0x0000000000000000000000001 not in enabled SSB bitmask

06:35:34.749272 RRC/HighFreq/Error/NR5GRRC [ nr5g_rrc_llc.c 5365] failed to construct lower layer cmds (validation failure). step1_step2_status(0x1)

06:35:34.749707 NR5GMAC_QSH_EVENT_MAC_RESET [ nr5g_mac_cfg.c 16192] QEvent 0xB810A454 | NR5GMAC_QSH_EVENT_MAC_RESET | event_data=0x00000004 | MAC Reset triggered with cause: CONNECTION_CANCEL

通过上面的log打印，可以确定是validation fail 的问题，应该和RRC setup中的BWP dedicated有关，具体的可能和pdsch TCI state的配置相关，第一次见这种log打印云里雾里的 ，anyway，还是查查相关的配置的定义，先看UE 收到RRCSetup后应该怎么做 。

看上述内容，UE就是要根据场景配置一些参数，log中的场景是initial注册，直接从红色字体部分开始，就是UE要根据masterCellGroup进行一系列的配置。

上面的RRC setup中masterCellGroup配置，确实有pdsch tci-state的配置，只配置了一个tci-stateId 0，只有一个DL RS(qcl-Type1)，包含referenceSignal ssb:1 ， qcl-Type typeD 等信息。下一步再看TCI state的qcl-type的定义。

在spec 38331 中，TCI State的定义如上，TCI State 描述的是1个或者2个DL参考信号之间的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对两个DL参考信号配置QCL关系，如果配置2个DL参考信号的话，QCL type的值应该不同。

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

波束是有方向性的，而TCI state这个关系主要给天线发送接收提供一个参考模板，根据配置的参考信号，设置空域特性，以便于UE和基站侧可以更好地通信。例如：PDSCH DM-RS 配置参考信号SSB，配置Type D时，则指示了PDSCH DMRS的发送波束和SSB的波束很类似（相同或接近），换句话说，TCI state配置的referenceSignal应该是实际存在的,不然UE还怎么做参考。

通过上述信息，qcl-Type 只要配置成Type A~D任意一个都没有什么问题。

再看下ReferenceSignal中SSB-Index的含义。

SSB-Index代表ss-burst中的SSB，具体到这里对应的就是SIB1中的ssb-PositionsInBurst，其有两个参数inOneGroup和groupPresence，含义如下：

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。

在FR1中 L=4/8，L=64的情况对应的是FR2。如果对应的是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的值，举个例子 假如L=8，配置如下，那代表这个小区对应的SSB 0~7都有在传输，UE正常情况下可以读到SSB0～7。

ssb-PositionsInBurst

inOneGroup '11111111'B

假如FR2 L=64

ssb-PositionsInBurst

inOneGroup '10101010'

groupPresence '01000000'

groupPresence代表可能SSB 8~15有在传输；具体还要看inOneGroup ，而inOneGroup代表实际SSB 8，10，12，14有在传输，那UE可以在现实环境中读到SSB 8/10/12/14。

接着回到log中的SIB1，通过inOneGroup '10000000'发现当前驻留的小区实际上只有SSB 0，UE也是注册在NARFCN 123890 PCI 0 ssb 0上。

那现在问题就很明显了，UE驻留小区SIB1中显示只有SSB0，但在RRC setup中配置pdsch TCI state时，却将referenceSignal 设置成了SSB 1，一个不存在的参考信号，进而UE校验失败，导致UE NR注册失败，就算UE校验松点，这里不判错，后面要是激活这个tci state，也肯定要发生问题。

06:35:34.749252 NR5GML1/STRM/High/NR5GML1 [ nr5g_ml1_rrc_intf.c 2786] RRC-ML1 config validate tci id 0: serv_cell_idx 0 ssb_id=1 ssb_bmask=0x1 failed

06:35:34.749253 NR5GML1/STRM/High/NR5GML1 [ nr5g_ml1_rrc_intf.c 3194] RRC-ML1 config validate tci: Dedicated pdsch validation TCI state references active 0x0000000000000000000000000 addmod 0x0000000000000000000000001 not in enabled SSB bitmask

回过头来再看log打印，才发现，其实log打印描述的fail原因已经很清楚，如果一开始读懂，就能节省不少时间。到这里也能看出这个问题确实很弱鸡。

问题原因找到了，解决方案也就有了，最终可以通过将SIB1 中的inOneGroup 改成'11000000'B(最起码得有SSB1)或者直接将tci-state 0中的ReferenceSignal ssb:0 修正该问题。

后面看SIB1中的inOneGroup 改成'01000000'B，NR pcell注册成功，然而问题还没有结束，后面再次测试时，又有新问题，在Pcell注册没有问题，但是后面配置上Scell后，在Scell上出现了稳定的DL bler 25%的问题，如下图。

凭直觉这么稳定的问题，大概率和资源配置有关系，可能是某些资源周期性的冲突导致的。log中Scell PDSCH的调度情况如下：

fail 场景

success 场景

总结规律，看出TE只会在slot 0和slot 8对Scell下发DCI 1_1的调度，且UE只会在偶数frame的slot 0发生CRC fail。

话不多说，直接看下Scell的配置参数，先看最重要的PointA 和SSB信息。

absoluteFrequencyPointA 指CRB 0的绝对频率位置。CRB0的最低子载波即subcarrier 0的中心频域就是Point A 。

absoluteFrequencySSB 指serving cell SSB的Freq，是为服务小区提供的 SSB 相关参数（例如 SSB index）指的是该SSB freq(其他情况会另有说明)。PCell 的 cell-defining SSB 始终位于sync raster上。如果该freq用GSCN value识别，则被认为是在sync raster上。如果该字段不存在，则 SSB相关参数应不存在，例如 ServingCellConfigCommon IE 中的 ssb-PositionsInBurst、ssb-periodicityServingCell 和 subcarrierSpacing等参数。 SCell 与 SpCell 处于相同频带时，如果该字段不存在，UE要从 SpCell 获得timing reference。

通过上面的截图，可以看出absoluteFrequencyPointA和absoluteFrequencySSB 对应的都是ARFCN value，下面看下ARFCN 和RF freq之间的对应关系。

NARFCN的取值范围对应[0,3279165] ，3279165正好对应38.331中的maxNARFCN，3GPP 将0~100GHZ 的频率范围划分成了3个区间，并给出了NARFCN和RF频率之间的转换关系式。NREF对应的就是NR ARFCN，RF 的参考频率就是FREF，两者的转换关系就是FREF = FREF-Offs + ΔFGlobal x ( NREF- NREF-Offs)。举个例子，NR ARFCN（NREF）= 600 000在第二个区间中（FREF-Offs为3000 MHz，NREF-Offs为600 000），FREF为3000 000 + 15 x ( 600 000 – 600 000) = 3000 000 kHz，即3GHz。

结合问题log，absoluteFrequencyPointA=109334指定了Scell的PointA的位置，absoluteFrequencySSB 127970为SSB的位置。紧接着就计算下PointA和SSB的实际freq，进而就可以确定SSB 和Scell BWP的频域位置关系。

absoluteFrequencyPointA=109334，在第一区间，FREF-Offs=NREF-Offs=0，FREF=0 + 5 x ( 109334 – 0) = 546670 kHz，

absoluteFrequencySSB=127970，在第一区间，FREF-Offs=NREF-Offs=0，FREF=0 + 5 x ( 127970– 0) = 639850 kHz。

再看下Scell BWP信息，先看Scell 配置carrier的一些信息。

offsettocarrier:PointA和该carrier上最低可用子载波之间的频域偏移，对应的是PRB的数目，PRB对应的scs由上图中的subcarrierSpacing，最大值对应275*8-1。

carrierBandwidth：对应的是carrier的带宽，即PRB数目(using the subcarrierSpacing defined for this carrier) 。

具体到问题中scell，offsettocarrier=504，carrierBandwidth=79。

Scell active BWP 信息，scs=15khz，locationAndBandwidth 21450 对应 RB_start=0，L RBs=79，即Scell 当前激活的BWP的中带宽对应79个RBs。

SSB freq 对应的是第121个子载波的中心频率，即上图中子载波k=121的位置（单纯的频域RB图，没有显示出SSB占用的时域4 symbols）。结合PointA，SSB和BWP的信息，可以画出如下关系的频域位置图，SSB 占用的频域位置包含在PRB3～PRB22的资源中，SSB并没有和这些PRB对齐，有subcarrier级别的偏移，这里也没有体现。

橙黄色部分对应的是BWP的频域范围，对应的正好是配置carrier的带宽范围，绿色对应的是SSB 的频域范围。

紧接着看下SSB的时域位置情况。

根据ssb-PositionsInBurst shortBitmap:'0100' B，Scell中只有SSB1，SSB 周期是20ms，SSB scs =15khz，因而SSB属于case A且小于3GHZ的情况，在5ms周期内，SSB 的符号索引为：{2,8,16,22}最大发送次数L =4 (2个时隙 每个时隙有2个SSB 共4个SSB)。

如上图,SSB 1在半帧内的位置 是slot 0 的symbol 811，结合ssb-periodicityServingCell =20ms，也就是对应的周期是2 frames，即每个偶数frame的 slot 0 中的symbol 811对应的就是SSB的位置，SSB正好对应的是前半帧的情况，到这里发现SSB的位置信息和UE PDSCH CRC fail的规律一样，那这个问题可能和SSB有关系。紧接着看下Scell 对应的PDSCH时频域资源。

TE侧下发给UE的DCI 1_1 中的Time domain resource assignment 一直为0，正好对应配置的pdsch-TimeDomainAllocationList中唯一一组参数。

pdsch-TimeDomainAllocationList

{

mappingType typeA,

startSymbolAndLength 53  //对应 s =symbol 2， length=12

}

由此可以判断是同时隙调度，一个slot内的PDSCH时域调度情况如下。

下面看下PDSCH的频域信息先看PDSCH DMRS。

对于PDSCH mapping type A ld代表slot内第一个symbol 到最后一个PDSCH symbol 的距离，通过SLIV 可以确定的PDSCH 的最后一个符号的位置，算出与slot内第一个symbol 的距离就是表中的ld，于是ld =14。

PDSCH DMRS还涉及single-symbol 和double-symbol的问题，如果RRC 层没有在DMRS-DownlinkConfig中配置maxLength，默认maxlength =1，采用single-symbol；如果配置maxLength的话，只能配置为 ”len2“，这时候还要根据DCI field确定single-symbol和double-symbol DM-RS具体情况。这份log里并没有配置maxlength =1，即采用single-symbol。dmrs-TypeA-Position pos2 代表l0=2，此例中没有配置dmrs-AdditionalPosition ，默认为 pos2。

上述信息结合38.211 中的表，PDSCH DMRS 对应的符号位置为2，7，11，不考虑CDM group具体配置，一个slot内(对应频域1个RB)，PDSCH资源分布情况如下。

再看看PDSCH 对应的频域资源，最早的log可以看到 DL DCI raw data，但是现在的log只有UL DCI 的 raw data，可能无法确定频域RB的资源分配情况如下图。

但是不要紧，通过0xB887 可以看到调度的RB数目，fail的frame 100 slot 0 调度的num Rbs=79，实际上就是满带宽调度，对应Scell当前激活BWP的带宽。

至此可以发现在偶数frame的slot 0，PDSCH会与SSB overlap，而且symbol 11还会出现PDSCH DMRS 和SSB overlap的情况，进而会对PDSCH的decode产生影响，这也是周期性PDSCH CRC fail的主要原因。

当然协议中也有类似的描述，如上38.211和38.214中PDSCH DMRS RE不能和任何其他资源有overlap的情况。