這篇是兩個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的情況。