When you power on 5G/NR UE(NR Standalone UE) or When LTE is adding NR Cell as a secondary cell, the first thing happening in UE is the process described below. This summary is based on Matlab 5G Toolbox example (Ref [1]) and the implementation on UE may vary a little bit from this.

• Decoding Steps
• Why the order is fixed
• The Channel Decoding Chain
• MIB Decoding
• Reference

Decoding Steps

The nine steps below are listed in the order the UE performs them, and the order is not a presentation choice. Each step consumes something the step before it produced, so the sequence is forced rather than convenient. The section after the list works through where those dependencies come from.

i) Search Frequency in which SSB (PSS + SSS + PBCH) is transmitted.

ii) Search PSS ==> By detecting PSS, UE can figure out . This is done in time domain by calculating correlation between each reference NID(2) sequences with the received signal. With the correlation calculation, we can figure out the exact timing offset(i.e, exact symbol start timing of PSS) in addition to finding out the best NID(2). This timing value (let's call it as 'offset') is the crucial information to construct the accruate resource grid that is used in step iii) and onwards.

iii) Construct the resource grid from the received signal and the detected timing from step ii)

iv) Search SSS by correlating the extracted SSS REs and calculating the correlation between the extracted SSS and Reference SSS ==> By detecting SSS, UE can figure out  

v) From and , UE can calculate Physical Cell ID ()

vi) Search PBCH DMRS

==> from PBCH DMRS UE can

• estimate channel ==> Calculate the channel matrix H. This will be used for equalization
• estimate noise
• figure out

vii) (based on Channel and Noise estimation) Perform Equalization(MMSE) for PBCH extraction

==> Once this equalization is done properly, UE can

• figure out RE for PBCH
• figure out PBCH CSI

viii) Demodulate PBCH ==> figure out PBCH bits

ix) Decode PBCH ==> Figure out MIB

Why the order is fixed

A list of steps is easy to read and easy to misremember, because nothing in it says which steps could be reordered. In this chain none of them can. Every step needs a quantity that only an earlier step can supply, and naming those quantities is the quickest way to hold the list in mind.

Timing comes first because everything else is defined relative to it. PSS is detected by correlation in the time domain, and that correlation is what gives the symbol boundary. Until the UE has that boundary it cannot cut the received samples into OFDM symbols, so it cannot build the resource grid in step iii. Without the grid there are no resource elements to extract, so the SSS search in step iv has nowhere to look.

The cell identity then needs both halves. 38.211 gives 1008 unique physical-layer cell identities, and that number factors as 3 times 336. PSS carries the part with three values and SSS carries the part with 336. Neither signal identifies the cell on its own. That is why step v is a separate step rather than something step ii or step iv produces by itself.

Two more dependencies sit at the end and they are the ones most often missed. The equalisation in step vii needs the channel matrix H, and H comes from the PBCH DM-RS in step vi, so demodulation cannot precede reference signal processing. Step vi also yields the SS/PBCH block index, and that index seeds the second PBCH scrambling. Decoding in step ix therefore cannot start until the index from step vi is known.

That last point is the one worth remembering. The UE does not know the block index before it decodes, and it cannot decode without the block index. The chain is closed by trying the candidates rather than by deriving the answer, and the CRC is what tells the UE which one was right.

• Timing gates everything : the resource grid cannot be constructed before PSS correlation has given the symbol boundary, so no frequency domain step can run first.
• The cell identity needs two signals : 1008 identities factor as 3 times 336, with PSS carrying the three and SSS the 336, so neither alone resolves the cell.
• Equalisation waits for the reference signal : the channel matrix H comes from PBCH DM-RS, so step vi has to complete before step vii can run.
• Decoding depends on the block index : the index recovered in step vi seeds the second scrambling, so the descrambler cannot be set up before then.
• The last link is closed by trial : the UE cannot know the block index before decoding, so it tries the candidates and lets the CRC pick the right one.

The Channel Decoding Chain

Step ix reads Decode PBCH, and that one line covers eight separate operations. The transmitter builds PBCH in eight steps, set out on the PBCH page, and the receiver has to undo every one of them in reverse. Two of those inverse operations need a key the UE does not hold when it reaches them, and how each key is obtained is the interesting part of this section.

The table below sets the receive chain beside the transmit step it undoes. The right hand column is the one to read, because it is what forces the ordering that the previous section described.

Two rows in that column are highlighted, and they are the only two that need a value rather than a signal. Both are descrambling steps, and each obtains its key in a completely different way.

The two descramblings get their key from different places

Scrambling is symmetric, so descrambling needs the same v the transmitter used. The two scramblings in the PBCH chain derive v from different quantities, and that difference decides whether the receiver can simply compute it or has to obtain it some other way.

The second scrambling is defined in 38.211 clause 7.3.3.1 and its v comes from the SS/PBCH block index. The UE already has that index, because searching the PBCH DM-RS in step vi is what produced it. The key therefore arrives from a signal outside the transport block, and no guess is involved.

The first scrambling is defined in 38.212 clause 7.1.2 and its v comes from the 2nd and 3rd least significant bits of the system frame number. Those bits are inside the transport block the UE is trying to decode, so the requirement looks circular. The UE would need the contents in order to descramble the contents.

3GPP resolves that circularity by exempting the relevant bits from the scrambling. Clause 7.1.2 exempts three groups of bits from the scrambling. They are the candidate SS/PBCH block index, the half frame index, and the 2nd and 3rd least significant bits of the system frame number. Those bits travel in the clear, so the UE reads them straight out of the decoded block and then descrambles everything else.

That exemption is why there is no blind search over the frame number. It also completes the picture for the 64 beam case. The three most significant bits of the SS/PBCH block index are carried in the payload rather than the DM-RS, and the same exemption keeps them readable.

What the CRC is actually checking

38.212 clause 7.1.3 sets the CRC length to 24 bits, which is generous for a payload this small. The reason is that the CRC is not only guarding against channel errors here.

Every step above the CRC row in the table consumed a hypothesis. The resource element demapping assumed a symbol timing from PSS. The equalisation assumed a channel estimate from a DM-RS sequence the UE had to identify. The second descrambling assumed the SS/PBCH block index that same DM-RS search produced. If any of those was wrong, the polar decoder produces bits that fail the CRC.

One consequence is worth remembering when reading a log. A PBCH CRC failure does not mean the channel was bad. It means something in the chain above it was wrong, and a mistaken block index or a half frame error looks exactly the same as noise at that point.

One further note on the polar step. 38.212 specifies the encoder and says nothing about how to decode it. Successive cancellation, list decoding and the CRC aided variants are all implementation choices, so two UEs meeting the same specification can differ measurably in PBCH sensitivity.

• Step ix is eight operations : the receiver undoes resource element mapping, modulation, scrambling, rate matching, coding, CRC, scrambling again and payload generation, in that order.
• Two descramblings, two kinds of key : the second takes v from the block index the DM-RS supplied, and the first from SFN bits inside the block itself.
• The circular case is solved by exemption : clause 7.1.2 leaves those key bits unscrambled, so they are readable before the descrambling runs.
• The CRC validates hypotheses, not just bits : timing, channel estimate and block index are all assumed above it, so a failure implicates the whole chain.
• The decoder is not specified : 38.212 defines polar encoding only, so PBCH sensitivity is a place where implementations genuinely differ.

MIB Decoding

Step ix produces the MIB, and the list stops there. What the UE holds at that point is smaller and stranger than most people expect, and two of its properties decide everything the UE does next. This section covers what comes out of the decoder and what the UE does with it.

The transport block is not all MIB

The bits the UE recovers at step ix come from two different places, and treating them as one block is the most common misreading of this stage. 38.212 clause 7.1.1 draws the line clearly.

The transport block delivered to layer 1 is the payload size generated by higher layers. Layer 1 then adds timing related PBCH payload bits on top of it. Those additional bits are the 4th, 3rd, 2nd and 1st LSB of the SFN, and the half frame bit. After them comes either the most significant bit of k_SSB or bits of the candidate SS/PBCH block index, depending on L_max.

So the MIB proper is what RRC encoded, and the timing bits around it were inserted by the physical layer. A decoder that hands the whole block to an ASN.1 parser will fail, because only part of it is ASN.1.

Following is based on 38.331 v19.3.0 (Release 19)

                MIB ::=                             SEQUENCE {
                    systemFrameNumber                   BIT STRING (SIZE (6)),
                    subCarrierSpacingCommon             ENUMERATED {scs15or60, scs30or120},
                    ssb-SubcarrierOffset                INTEGER (0..15),
                    dmrs-TypeA-Position                 ENUMERATED {pos2, pos3},
                    pdcch-ConfigSIB1                    PDCCH-ConfigSIB1,
                    cellBarred                          ENUMERATED {barred, notBarred},
                    intraFreqReselection                ENUMERATED {allowed, notAllowed},
                    spare                               BIT STRING (SIZE (1))
                }
                
                PDCCH-ConfigSIB1 ::=                SEQUENCE {
                    controlResourceSetZero              ControlResourceSetZero,
                    searchSpaceZero                     SearchSpaceZero
                }
                
                ControlResourceSetZero ::=          INTEGER (0..15)
                SearchSpaceZero ::=                 INTEGER (0..15)
                

Eight fields, and every one of them is doing something the UE needs before it can take a further step.

The first row is where the trap is. 38.331 states it directly. The field holds the 6 most significant bits of the 10 bit SFN. The 4 LSB are conveyed in the PBCH transport block as part of channel coding, outside the MIB encoding. The UE therefore assembles the frame number from two sources that arrive by different routes in the same decode.

That split is not an oddity of encoding. It is what makes the first scrambling on the PBCH page work, because those SFN least significant bits are exactly what selects v in that step. The UE has to guess them to descramble, and the CRC confirms the guess.

What the MIB sets in motion

Three of the eight fields decide what happens after the decode succeeds, and they are worth reading in a fixed order. Two of them can stop the procedure outright, so checking them before the rest saves work.

cellBarred comes first. If it reads barred, the UE may not use the cell, and intraFreqReselection then says whether it may look at another cell on the same frequency or must move elsewhere. Nothing else in the MIB matters once the cell is barred.

ssb-SubcarrierOffset comes next, and it carries more than an offset. 38.331 says the field corresponds to k_SSB, and that its value range may be extended by an additional most significant bit encoded within PBCH. That extra bit is one of the timing bits described above, and when the combined value falls outside the valid range it means this SS/PBCH block has no SIB1 with it.

pdcch-ConfigSIB1 is the one that carries the procedure forward. Its two halves, controlResourceSetZero and searchSpaceZero, are each an integer from 0 to 15, and they index the tables that define CORESET 0 and the Type0-PDCCH search space. That is how the UE gets from a decoded MIB to a place to look for SIB1.

• The transport block mixes two origins : the MIB is what RRC encoded, and the timing bits around it were added by the physical layer in 38.212 clause 7.1.1.
• The SFN arrives in two halves : 6 bits inside the MIB and 4 outside it, so the frame number is assembled rather than read.
• Check cellBarred before anything else : a barred cell makes the remaining fields irrelevant, and intraFreqReselection says where the UE may go instead.
• k_SSB can say that SIB1 is absent : ssb-SubcarrierOffset may be extended by a bit carried in PBCH, and an out of range value means this block has no SIB1.
• pdcch-ConfigSIB1 is the pointer to SIB1 : two four bit indices give CORESET 0 and the Type0-PDCCH search space, which is where the UE looks next.

Reference

[1] NR Synchronization Procedures (Matlab 5G Toolbox)

[2] 3GPP TS 38.331 - NR; Radio Resource Control (RRC) protocol specification. The MIB definition and its field descriptions.

[3] 3GPP TS 38.212 - NR; Multiplexing and channel coding. Clause 7.1.1 for the timing bits the physical layer adds to the MIB.