This article is a summary of the problems caused by the abnormal configuration of two SSBs. The first problem is very simple, but since I saw this kind of log for the first time, it seems rather confusing. In addition, I did not expect such a weak problem; Later, I encountered another SSB-related problem. Because it involves the determination of time-frequency domain resources, it seems relatively laborious. Both of these are lab problems.
To make a long story short, let’s look at the first problem first. This problem UE has not even completed the registration. From the perspective of the air interface, it fails every time it receives RRC setup. The specific process is as follows.
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
Through the above log printing, it can be confirmed that it is a verification fail problem, which should be related to BWP dedicated in RRC setup, and the specific one may be related to the configuration of pdsch TCI state. This is the first time I see this kind of log printing. Anyway , or look up the definition of the relevant configuration, first look at what the UE should do after receiving RRCSetup.
Looking at the above content, the UE needs to configure some parameters according to the scene. The scene in the log is the initial registration, starting directly from the red font part, which means that the UE needs to perform a series of configurations according to the masterCellGroup.
The masterCellGroup configuration in the above RRC setup does have pdsch tci-state configuration, only one tci-stateId 0 is configured, and only one DL RS (qcl-Type1), including referenceSignal ssb:1, qcl-Type typeD and other information. Next, look at the definition of qcl-type of TCI state.
In spec 38331, TCI State is defined as above. TCI State describes the QCL relationship between one or two DL reference signals. PDSCH DMRS/PDCCH DMRS/CSI-RS can be configured with TCI-State. Maybe this description I still don't know what QCL is. Let's look at the relevant description in chapter 5.1.5 of 38.214.
The content contained in TCI-State is the QCL relationship between 1~2 downlink reference signals and PDSCH DMRS /PDCCH DMRS /CSI-RS port. The network side can configure the QCL relationship for the two DL reference signals through qcl-Type1 and qcl-Type2. If two DL reference signals are configured, the value of QCL type should be different.
To put it simply, QCL means that the characteristics of the two antenna ports of the transmitted signal (target signal and source reference signal) are relatively close, indicating the similarity between the source reference signal and the target reference signal, representing the channel characteristics in the air domain, and the similarity is divided into 4 types. QCL-Type A: The 4 aspects of {Doppler frequency shift, Doppler spread, average delay, delay spread} are similar; QCL-Type B: {Doppler frequency shift, Doppler spread} two QCL-Type C: {Doppler frequency shift, average delay} is similar in two aspects; QCL-Type D: {spatial parameters} is similar in beam information.
The beam is directional, and the TCI state relationship mainly provides a reference template for antenna transmission and reception. According to the configured reference signal, the airspace characteristics are set to facilitate better communication between the UE and the base station. For example: PDSCH DM-RS configuration reference signal SSB, when configuring Type D, it indicates that the transmission beam of PDSCH DMRS is very similar to the beam of SSB (same or close), in other words, the referenceSignal configured by TCI state should actually exist , otherwise how does the UE refer to it.
Through the above information, as long as qcl-Type is configured as Type A~D, there is no problem. For a detailed introduction to TCI-state, please see BeamManagement (2) if you are interested .
Look at the meaning of SSB-Index in ReferenceSignal.
SSB-Index represents the SSB in ss-burst. Specifically, it corresponds to ssb-PositionsInBurst in SIB1. It has two parameters inOneGroup and groupPresence. The meanings are as follows:
inOneGroup(8bits): When SSB max number=4 in each half frame, the leftmost 4 bits are valid (SSB 0~3 from left to right), and the remaining 4 bits are temporarily ignored; when SSB max number=8 in each half frame , 8 bits are valid, from left to right are SSB 0~7 respectively; when SSB max number=64 in each half frame, 8 bits are valid, from left to right, the first bit corresponds to SSB0, 8, 16 , 24, 32, 40, 48, 56; the second bit corresponds to SSB1, 9, 17, 25, 33, 41, 49, 57; the third bit corresponds to SSB 2, 10, 18, 26, 34, 42, 49, 58, and so on. bit=1 means that the corresponding SSB has normal transmission, that is, there is this SSB in the environment, bit=0, it means that the SSB does not exist in the environment.
In FR1, L=4/8, L=64 corresponds to FR2. If it corresponds to FR2, there will also be groupPresence.
groupPresence(8bits) is aimed at the case of SSB L=64. It is represented by 8bits. It represents a group of SSBs from left to right. The first bit corresponds to SSB0~7, the second bit corresponds to SSB 8~15, and the second bit corresponds to SSB 8~15. The three bits correspond to SSB 16-23, the fourth bit corresponds to SSB 24-31, the fifth bit corresponds to SSB 32-39, the sixth bit corresponds to SSB 40-47, the seventh bit corresponds to SSB 48-55, and the fifth bit corresponds to SSB 40-47. 8 bits correspond to SSB 56~63.
The determination of the SSB max number L of each half-frame is related to the spectrum, and the UE can determine the value of L during the cell search process. For details, see NR cell search (1) SSB. For example, if L=8 and the configuration is as follows, it means that SSB 0~7 corresponding to this cell is being transmitted, and the UE can read SSB 0~7 under normal conditions.
ssb-PositionsInBurst
inOneGroup '11111111'B
If FR2 L=64
ssb-PositionsInBurst
inOneGroup '10101010'
groupPresence '01000000'
groupPresence means that SSB 8~15 may be in transmission; it depends on inOneGroup, and inOneGroup means that SSB 8, 10, 12, and 14 are actually in transmission, so UE can read SSB 8/10/12/14 in the real environment .
Then go back to SIB1 in the log, and find out that the currently camped cell actually only has SSB 0 through inOneGroup '10000000', and the UE is also registered on NARFCN 123890 PCI 0 ssb 0.
Now the problem is obvious. The SIB1 of the cell where the UE resides shows only SSB0, but when configuring the pdsch TCI state in the RRC setup, the referenceSignal is set to SSB 1, a reference signal that does not exist, and the UE fails to verify , causing the UE NR registration to fail. Even if the UE checks loosely, there is no error judgment here. If the tci state is activated later, problems will definitely occur.
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
Looking back at the log printing, I found that the reason for the failure described in the log printing is actually very clear. If you understand it at the beginning, you can save a lot of time. It can also be seen here that this problem is indeed weak.
If the cause of the problem is found, the solution will come. Finally, the problem can be corrected by changing the inOneGroup in SIB1 to '11000000'B (at least SSB1 is required) or directly changing the ReferenceSignal ssb:0 in tci-state 0.
Later, I changed the inOneGroup in SIB1 to '01000000'B, and the registration of NR pcell was successful. However, the problem was not over yet. When I tested again later, there was a new problem. There was no problem with the registration of Pcell, but after configuring Scell later, on Scell There is a stable DL bler 25% problem, as shown in the figure below.
Intuitively, such a stable problem has a high probability to be related to resource allocation, which may be caused by periodic conflicts of certain resources. The scheduling of Scell PDSCH in the log is as follows:
fail scene
success scene
Summarizing the rules, it can be seen that TE will only issue DCI 1_1 scheduling to Scells in slot 0 and slot 8, and UE will only generate CRC fail in slot 0 of an even frame.
Not much to say, just look at the configuration parameters of Scell, first look at the most important PointA and SSB information.
absoluteFrequencyPointA refers to the absolute frequency position of CRB 0. The lowest subcarrier of CRB0, that is, the center frequency domain of subcarrier 0 is Point A.
absoluteFrequencySSB refers to the Freq of the serving cell SSB, which is the SSB-related parameter (such as SSB index) provided for the serving cell refers to the SSB freq (other circumstances will be specified otherwise). The cell-defining SSB of the PCell is always on the sync raster. If the freq is identified with a GSCN value, it is considered to be on the sync raster. If this field does not exist, SSB related parameters shall not exist, such as ssb-PositionsInBurst, ssb-periodicityServingCell and subcarrierSpacing parameters in ServingCellConfigCommon IE. When the SCell and the SpCell are in the same frequency band, if this field does not exist, the UE needs to obtain the timing reference from the SpCell.
From the screenshot above, it can be seen that absoluteFrequencyPointA and absoluteFrequencySSB correspond to ARFCN value, let’s look at the correspondence between ARFCN and RF freq.
The value range of NARFCN corresponds to [0,3279165], and 3279165 corresponds to maxNARFCN in 38.331. 3GPP divides the frequency range of 0~100GHZ into 3 intervals, and gives the conversion relationship between NARFCN and RF frequency. NREF corresponds to NR ARFCN, the reference frequency of RF is FREF, and the conversion relationship between the two is FREF = FREF-Offs + ΔFGlobal x ( NREF- NREF-Offs). For example, NR ARFCN(NREF) = 600 000 In the second interval (FREF-Offs is 3000 MHz, NREF-Offs is 600 000), FREF is 3000 000 + 15 x ( 600 000 – 600 000) = 3000 000 kHz, or 3GHz.
Combined with the problem log, absoluteFrequencyPointA=109334 specifies the position of PointA of Scell, and absoluteFrequencySSB 127970 is the position of SSB. Next, calculate the actual freq of PointA and SSB, and then determine the frequency-domain positional relationship between SSB and Scell BWP.
absoluteFrequencyPointA=109334, in the first interval, FREF-Offs=NREF-Offs=0, FREF=0 + 5 x ( 109334 – 0) = 546670 kHz,
absoluteFrequencySSB=127970, in the first interval, FREF-Offs=NREF-Offs=0, FREF=0 + 5 x ( 127970– 0) = 639850 kHz.
Look at the Scell BWP information again, and first look at some information about the Scell configuration carrier.
offsettocarrier: The frequency domain offset between PointA and the lowest available subcarrier on the carrier, corresponding to the number of PRBs, the scs corresponding to the PRB is determined by the subcarrierSpacing in the above figure, and the maximum value corresponds to 275*8-1.
carrierBandwidth: corresponds to the bandwidth of the carrier, that is, the number of PRBs (using the subcarrierSpacing defined for this carrier).
Specific to the question of scell, offsettocarrier=504, carrierBandwidth=79.
Scell active BWP information, scs=15khz, locationAndBandwidth 21450 corresponds to RB_start=0, L RBs=79, that is, the medium bandwidth of the currently active BWP of Scell corresponds to 79 RBs.
SSB freq corresponds to the center frequency of the 121st subcarrier, that is, the position of subcarrier k=121 in the above figure (pure frequency domain RB diagram, which does not show the 4 symbols in the time domain occupied by SSB). Combining the information of PointA, SSB and BWP, the frequency domain position map of the following relationship can be drawn. The frequency domain position occupied by SSB is included in the resources of PRB3~PRB22. SSB is not aligned with these PRBs, and there is a subcarrier level offset. It is not reflected here either.
The orange part corresponds to the frequency domain range of the BWP, which corresponds to the bandwidth range of the carrier configuration, and the green part corresponds to the frequency domain range of the SSB.
Then look at the time domain position of the SSB.
According to ssb-PositionsInBurst shortBitmap:'0100' B, there is only SSB1 in the Scell, the SSB period is 20ms, and SSB scs =15khz, so SSB belongs to case A and is less than 3GHZ, within the 5ms period, the symbol index of SSB is: {2 ,8,16,22} The maximum number of transmissions L =4 (2 time slots each have 2 SSBs, a total of 4 SSBs).
As shown above, the position of SSB 1 in the half frame is symbol 8~11 of slot 0, combined with ssb-periodicityServingCell =20ms, that is, the corresponding period is 2 frames, that is, symbol 8~11 in slot 0 of each even frame Corresponding to the position of SSB, this problem is the case of the first half of the frame, here we find that the position information of SSB is the same as the law of UE PDSCH CRC fail, then this problem may be related to SSB. Then look at the PDSCH time-frequency domain resources corresponding to the Scell.
The Time domain resource assignment in the DCI 1_1 delivered to the UE from the TE side is always 0, which corresponds to the only set of parameters in the configured pdsch-TimeDomainAllocationList.
pdsch-TimeDomainAllocationList
{
mappingType typeA,
startSymbolAndLength 53 //corresponding to s =symbol 2, length=12
}
From this, it can be judged that it is the same slot scheduling, and the time domain scheduling of the PDSCH in one slot is as follows.
Let's look at the frequency domain information of PDSCH and first look at PDSCH DMRS.
For PDSCH mapping type A ld represents the distance from the first symbol to the last PDSCH symbol in the slot, the position of the last symbol of PDSCH can be determined by SLIV, and the distance from the first symbol in the slot is calculated as ld in the table, Then ld =14.
PDSCH DMRS also involves the issue of single-symbol and double-symbol. If the RRC layer does not configure maxLength in DMRS-DownlinkConfig, the default maxlength = 1, and single-symbol is used; if maxLength is configured, it can only be configured as "len2". At this time, the specific situation of single-symbol and double-symbol DM-RS must be determined according to the DCI field. This log does not configure maxlength = 1, that is, single-symbol is used. dmrs-TypeA-Position pos2 means l0=2, dmrs-AdditionalPosition is not configured in this example, the default is pos2.
Combining the above information with the table in 38.211, the symbol positions corresponding to PDSCH DMRS are 2, 7, and 11. Regardless of the specific configuration of the CDM group, the distribution of PDSCH resources in one slot (corresponding to one RB in the frequency domain) is as follows.
Looking at the frequency domain resources corresponding to PDSCH, the earliest log can see DL DCI raw data, but the current log only has UL DCI raw data, and it may not be possible to determine the resource allocation of RB in the frequency domain, as shown in the figure below.
But it doesn’t matter, you can see the number of RBs scheduled through 0xB887, and the frame 100 slot 0 of fail schedules num Rbs=79, which is actually full bandwidth scheduling, corresponding to the bandwidth of the currently activated BWP of the Scell.
So far, it can be found that in slot 0 of an even frame, PDSCH will overlap with SSB, and symbol 11 will also have PDSCH DMRS and SSB overlap, which will affect the decoding of PDSCH, which is also the main reason for periodic PDSCH CRC fail.
Of course, there are similar descriptions in the agreement, as in 38.211 and 38.214 above, the PDSCH DMRS RE cannot overlap with any other resources.