In any cellular communication system (2G, 3G, 4G, 5G), there are specific procedure called Cell Search. Even though the detailed mechanism varies a little bit depending on each specific Cellular Technology, the basic concept and purpose is same. They are same in 5G/NR as well.

• Why this is harder than it sounds
• What the UE knows after each step
• The steps in detail
• When cell search fails : where to look
• Matlab Reference on Cell Search

38.300 - 5.2.5.3 defined 5G/NR as follows.

Cell search is the procedure by which a UE acquires time and frequency synchronization with a cell and detects the Cell ID of that cell. NR cell search is based on the primary and secondary synchronization signals, and PBCH DMRS, located on the synchronization raster.

I think this is well phrased definition that shows both overal defintion that can be applied to every cellular technology and NR specific technology. As I highlighted with different color, the first sentence is the definition of celllar technology for every technology and the second sentence is the definition that are specific for NR.

It is worth slowing down on those two sentences, because between them they contain the entire problem.

The first sentence lists three things the UE has to come away with, and they are not the same kind of thing at all :

• Time synchronization - where does a symbol start, where does a slot start, where does a radio frame start. Without this the UE cannot even run an FFT, because it does not know where to put the window.
• Frequency synchronization - the UE's own oscillator is not exactly on the network's frequency, and any residual offset destroys the orthogonality between subcarriers. This has to be corrected before anything can be demodulated.
• Cell ID - which of the 1008 physical cell identities this is. Almost every reference signal in NR is scrambled by the PCI, so until the UE knows it, nothing else in the cell can be descrambled.

The second sentence names the three signals NR gives the UE to do it with - PSS, SSS and PBCH DMRS - and then adds four words that are easy to read past : located on the synchronization raster. That phrase is what makes the whole procedure finite rather than hopeless, and it is the subject of step i) below.

Why this is harder than it sounds

Before the steps, it is worth being honest about the starting position, because it explains why the procedure is shaped the way it is.

A UE that has just been switched on in an unknown place knows nothing. It does not know the frequency, the bandwidth, the subcarrier spacing, the cell identity, where a frame starts, or even whether there is a network there at all. Every one of those is normally a parameter you need in order to receive anything - and the UE has none of them.

So cell search is a bootstrapping problem. Each step has to be decodable using only what the previous steps produced, and the whole chain has to start from a signal that can be found with no prior knowledge whatsoever. That constraint is why the procedure looks the way it does :

• PSS is a short, fixed sequence with only 3 possibilities, so it can be found by brute force correlation with no timing knowledge at all.
• The SSB always uses the same 20 resource blocks and 4 symbols regardless of the cell's real bandwidth, so the UE does not need to know the bandwidth to receive it.
• MIB is tiny - 23 bits - because it has to survive being sent before the UE knows almost anything.
• MIB does not contain SIB1. It contains just enough to find the scheduling of SIB1, and SIB1 then carries the real configuration.

Every one of those is a consequence of the same rule : you can only use what you already have.

Based on this definition, NR Cell Search procedure can be broken down to several steps as follows : (Even though it may seem simple process, this is very complicated process if you go in detail. First, try to understand overall procedure as described below and then follow through the linked pages for further details for each of the steps).

• i) UE tunes to a specific frequency (How UE select this specific freuqency to tune to ?)  [detail]
• ii) UE tries to detect SSB and decode PSS, SSS. If UE fails at this step, it goes to step i) and passes at this step, go to next  [detail]
• iii) Once UE successfully detect PSS/SSS, UE tries to decode PBCH.  [detail]
• iv) Once UE successfully detect PBCH, it decode MIB  [detail]
• v) Based on MIB.pdcch-ConfigSIB1, find the location of CORESET0 (CORESET for PDCCH/DCI for SIB1 transmission) and SearchSpace information. This CORESET0 finding is done by predefined parameters as described here.  [detail]
• vi) Blind decode DCI 1_0 in the SearchSpace.  [detail]
• vii) Based on the contents of the DCI 1_0. (NOTE : In order to interpret the DCI 1_0 for SI RNTI, UE need to have some additional table like TimeDomainResourceAllocation which is usually configured in RRC message (e.g, SIB1, RRCConfiguration etc). But this step is before decoding any RRC message. It implies that UE should know of TimeDomainResourceAllocation from predefined tables in 3GPP. Refer to [NOTE 1] in SI-RNTI DCI 1_0 for further details )  [detail]
• viii) Detect and decode PDSCH carrying SIB1.  [detail]
• ix) decode SIB1 and other SIBs (if SIB1 carries information on other SIBs).  [detail]
• x) Once the SIB1 is decoded, UE can figure out various other fundamental information like channel bandwidth, center frequency of the channel etc as shown here.  [detail]

NOTE : step ii) and iii) can be catagorized as a single step called SSB detection. This process is described in detail in my SSB/PBCH page.

What the UE knows after each step

This is the table I wish I had when I first read this procedure. Cell search is a ladder, and the only way to make sense of any single step is to know what the UE was holding when it started that step and what it is holding when it finishes. Read the middle column downwards and you can watch a UE go from knowing nothing to being ready to camp.

NOTE : notice how late the channel bandwidth arrives. The UE decodes the SSB, the MIB, a PDCCH and a PDSCH - four separate receptions - before it finds out how wide the carrier actually is. It gets away with this because the SSB and CORESET#0 always live within a small, fixed number of resource blocks, so everything up to SIB1 can be received through a narrow window. This is a deliberate design choice, and it is what lets one UE search a 5 MHz carrier and a 100 MHz carrier with exactly the same procedure.

The steps in detail

i) UE tunes to a specific frequency

The question in your own step list - how does the UE select this specific frequency to tune to? - is the right one to ask first, because the naive answer is impossible.

NR carriers can be placed on the channel raster, which has a spacing of 5 kHz, 15 kHz or 100 kHz depending on the band. If the UE had to test every channel raster point in a band it would be searching tens of thousands of frequencies, each one needing a correlation over several milliseconds. A cold start would take hours.

The way out is the phrase from 38.300 quoted above : located on the synchronization raster. The SSB is not allowed to sit anywhere a carrier can sit. It may only be placed on a much coarser grid called the synchronization raster, whose points are numbered by the GSCN (Global Synchronization Channel Number). From 38.104 :

  Frequency range        SSB frequency position                        GSCN
  ---------------------  --------------------------------------------  -----------------
  0 - 3000 MHz           N x 1200 kHz + M x 50 kHz                      3N + (M-3)/2
                         N = 1..2499,  M = 1, 3, 5   (M = 3 default)
  3000 - 24250 MHz       3000 MHz + N x 1.44 MHz,  N = 0..14756       7499 + N
  24250 - 100000 MHz     24250.08 MHz + N x 17.28 MHz, N = 0..4383    22256 + N

Look at the size of those steps against the channel raster and the point becomes obvious :

The synchronization raster is about a hundred times coarser than the channel raster in FR1, and that ratio is the difference between a cell search that finishes and one that does not. On top of this, 38.104 lists the applicable GSCN range for each band, which usually cuts the candidate list down to a few dozen entries or fewer.

And in practice the UE almost never does the full scan at all. 38.304 - 5.2.3 describes two quite different ways of arriving at a cell :

• Initial Cell Selection - the UE scans all RF channels in the bands it supports, with no prior knowledge, and this is where the GSCN really earns its keep.
• Cell Selection using stored information - the UE already has a list of candidate frequencies and goes straight to them.

The second one is what happens almost every time, and the interesting detail is that the specification is deliberately vague about where that stored information comes from. It only says the UE has stored frequency information, optionally with cell parameters, from previously received measurement control information or previously detected cells. Everything beyond that is implementation, and in a real device the list is assembled from several sources :

NOTE : this is why turning a phone on in the same place is nearly instant, while turning it on after a long flight takes visibly longer. The first case is a lookup ; the second is a genuine search. It is also why a factory reset or a new SIM in an unfamiliar country can be slower than either - the stored list is either gone or pointing at the wrong continent, so the UE falls back to scanning.

One consequence that catches people out : because the SSB sits on the sync raster and the carrier sits on the channel raster, the SSB is usually not in the centre of the carrier. There is no requirement for it to be. The UE finds the SSB first and works out where the carrier is afterwards, in step x).

ii) Detect SSB, decode PSS and SSS

The SSB is a fixed block of 4 OFDM symbols x 240 subcarriers (20 resource blocks). Its shape never changes, whatever the cell's bandwidth or subcarrier spacing :

  subcarrier -> 0               48 56                                     182   192          239
                |               |  |                                        |   |              |
  symbol 0      ...................[==================PSS===================]...................
  symbol 1      [=====================================PBCH=====================================]
  symbol 2      [=====PBCH=====]...[==================SSS===================]...[=====PBCH=====]
  symbol 3      [=====================================PBCH=====================================]

  PSS / SSS : 127 subcarriers each, in the middle
  PBCH      : 432 data REs + 144 DMRS REs = 576 REs over symbols 1, 2, 3
  . . . .    : reserved, set to zero (subcarriers 48-55 and 183-191)

PSS first, and only PSS, because it is the only thing findable from nothing. PSS is a length 127 m-sequence, and there are only three of them, selected by N_ID⁽²⁾ = 0, 1 or 2. The UE slides each of the three candidate sequences across the incoming samples looking for a correlation peak. Three hypotheses is a small enough number to brute force, and a correlation peak needs no prior timing knowledge - that is the entire reason PSS is designed the way it is.

When the peak is found, the UE gets three things at once : symbol timing (where the peak is), a coarse frequency offset (from how the peak degrades as the hypothesised offset is varied), and N_ID⁽²⁾.

SSS completes the identity. Now that the UE has timing, it knows exactly where SSS sits - two symbols later, same subcarriers - so it no longer needs to search, only to test. SSS carries N_ID⁽¹⁾, one of 336 values, and the cell identity falls out :

  PCI  =  3 x N_ID(1)  +  N_ID(2)

         N_ID(1) : 0 .. 335   from SSS
         N_ID(2) : 0 ..   2   from PSS
         -----------------------------------
         PCI     : 0 .. 1007   =  336 x 3

Splitting the identity across two signals is not an accident. It means the expensive blind search only ever has 3 hypotheses, and the 336-way part is a cheap test once timing is already known.

Where in the frame is the SSB? The UE does not scan every symbol for it. The candidate positions are fixed by 38.213 as five patterns, chosen by SCS and frequency :

The number of SSBs in a burst, L_max, follows from the frequency : 4 below 3 GHz, 8 between 3 and 6 GHz, and 64 in FR2. In FR1 those few SSBs are usually just sectors or a light beam sweep ; in FR2 the 64 SSBs are a full beam sweep, and finding the cell also means finding which beam - which is what step iii) delivers.

NOTE : for initial cell search the UE assumes an SSB periodicity of 20 ms. The network may actually transmit more often, but the UE cannot know that yet, so 20 ms is the assumption it is allowed to make. This is why cell search timings are usually quoted in multiples of 20 ms, and why a UE that needs several attempts to combine enough energy can take 100 ms or more on a weak cell.

iii) Decode PBCH

PBCH occupies the remaining REs of the SSB - 432 data resource elements carrying 864 QPSK-coded bits, plus 144 DMRS resource elements interleaved among them, one RE in every four.

Two things about PBCH DMRS are worth understanding properly, because 38.300 went out of its way to mention it in the definition.

First, its position depends on the PCI. The DMRS REs sit at subcarriers 4k + v where v = PCI mod 4. The UE already has the PCI from step ii), so it knows exactly where to find them. The practical effect is that neighbouring cells given PCIs with different values of PCI mod 4 put their PBCH DMRS on different subcarriers and interfere with each other far less - which is why PCI planning in NR pays attention to PCI mod 4, in the same way LTE planning cared about PCI mod 3 and mod 6.

Second, it carries information of its own. The DMRS sequence is one of 8 variants, and which one is used encodes the SSB index - that is, which beam of the burst this is - together with the half frame bit. So the UE learns which beam it is looking at simply by working out which DMRS sequence fits best, before decoding a single PBCH data bit :

Once the UE has the SSB index and the half frame bit, it knows where it is inside the 10 ms radio frame, not merely inside a symbol. Combined with the SFN that arrives in the next step, that gives it complete frame timing.

The payload, and why it is so small. The bits going into the polar encoder are :

  MIB content                       23 bits
  BCCH-BCH-Message wrapper         +  1 bit    -> 24
  PBCH extra timing bits           +  8 bits   -> 32 bits
      (4 LSBs of SFN, half frame bit, and 3 bits used for
       the SSB index MSBs in FR2 or k_SSB in FR1)
  CRC                              + 24 bits   -> 56 bits
                                                  |
                                       polar coding, rate matched
                                                  v
                                            864 bits -> QPSK -> 432 REs

56 information bits stretched over 864 coded bits is a code rate of about 1/15. That is an enormous amount of protection, and it is deliberate : PBCH has to be decodable by a UE that has no idea whether it is even pointed at a real cell, at the very edge of coverage, with no chance to ask for a retransmission.

On top of that, the same MIB content is repeated across the SSBs of an 80 ms window with different scrambling, so a UE that cannot decode one SSB can soft combine several. This is why a weak cell is slow to find rather than impossible to find.

iv) Decode MIB

23 bits, and every one of them is doing work. There is no padding in MIB and nothing optional :

NOTE : cellBarred being in MIB rather than SIB1 is a good piece of design to notice. Barring is checked at the earliest possible moment, so a UE never wastes a PDCCH search and a PDSCH decode on a cell it was never allowed to use.

v) Find CORESET#0 and SearchSpace#0 from pdcch-ConfigSIB1

This is the cleverest step in the whole procedure, and it is worth saying why in plain terms.

A CORESET normally needs a full configuration - which resource blocks, how many symbols, what mapping, what precoder granularity, plus a search space telling the UE which slots and symbols to monitor and how many candidates to try. In a running connection all of that comes from RRC. But here the UE has no RRC configuration at all, and the entire budget available is 8 bits in MIB.

The trick is that the 8 bits are not a configuration, they are an index into a table that both sides already have :

  pdcch-ConfigSIB1  =  controlResourceSetZero (4 bits)  +  searchSpaceZero (4 bits)
                                |                                   |
                                v                                   v
              38.213 Tables 13-1 .. 13-10            38.213 Tables 13-11 .. 13-15
              indexed also by SSB SCS, PDCCH SCS,    -> O, M, first symbol index,
              and the band's minimum channel BW         number of search space sets
                                |
                                v
              SSB / CORESET multiplexing pattern  (1, 2 or 3)
              N_RB    24, 48 or 96 resource blocks
              N_symb  1, 2 or 3 symbols
              offset  in RBs, from the SSB to the start of CORESET#0

So 4 bits buy a complete CORESET description, because the 16 possible descriptions were agreed in advance and written into the specification. The same applies to the 4 bits of searchSpaceZero, which produce the monitoring occasions.

Two details are worth holding on to :

• The CORESET#0 position is expressed as an offset from the SSB, not as an absolute frequency. It has to be, because at this point the UE still has no idea where the carrier begins. Everything is relative to the one thing it has actually found.
• The multiplexing pattern says how the SSB and CORESET#0 are arranged relative to each other. Pattern 1 has them in different time occasions (the usual FR1 arrangement) ; patterns 2 and 3 place them in the same or overlapping symbols and are used in FR2, where a beam sweep makes time multiplexing expensive.

vi) Blind decode DCI 1_0 in the SearchSpace

The UE now monitors the Type0-PDCCH common search space it just derived, and tries to decode a DCI scrambled with SI-RNTI = 0xFFFF. This value is fixed in the specification, which it has to be - the UE has no way to be told an RNTI before it can read SIB1.

"Blind decode" means the UE does not know where in the CORESET the DCI is, or how large it is, so it tries every allowed combination and lets the CRC decide. For Type0-PDCCH the candidate set is deliberately small :

  Aggregation level   Number of candidates
  -----------------   --------------------
        4                    4
        8                    2
       16                    1
                       ----
                        7 attempts per monitoring occasion

Notice that the low aggregation levels 1 and 2 are not used at all. Every candidate is large, which means heavily coded, which means robust - the same reasoning as the very low code rate of PBCH. A UE doing initial access may be at the edge of the cell, and this PDCCH has to reach it.

The CRC of a correctly decoded DCI is masked with the RNTI, so "the CRC passed after unmasking with 0xFFFF" is simultaneously the proof that the decode was correct and that this DCI is for system information rather than for some other UE.

vii) Interpret the contents of the DCI 1_0

The DCI 1_0 for SI-RNTI is a compact message whose only job is to point at the SIB1 transmission :

Your NOTE above puts a finger on exactly the right problem, and it is worth restating as the general rule, because it is the theme of this entire page : anything the UE needs before it can read an RRC message must be a constant in the specification.

The time domain resource assignment field is a 4 bit index. In a connected UE it indexes pdsch-TimeDomainAllocationList, which arrives by RRC signalling. Here there is no RRC signalling yet, so it indexes a default table defined in 38.214 instead, chosen by the SSB/CORESET multiplexing pattern from step v). The same pattern appears in step v) with CORESET#0, in step vi) with SI-RNTI, and in step iv) with the default SCS. In every case the answer to "how does the UE know this yet?" is the same : because it was agreed in advance and written down.

viii) Detect and decode PDSCH carrying SIB1

A normal PDSCH reception, but with every parameter sourced from somewhere unusual : the DMRS position from MIB's dmrs-TypeA-Position, the SCS from MIB's subCarrierSpacingCommon, the resource allocation from the DCI, and the scrambling from the PCI and SI-RNTI rather than from a C-RNTI.

There is no HARQ feedback here. The UE does not have an uplink configuration yet, so it cannot acknowledge anything. If the decode fails there is nothing to report - the UE simply waits for the next repetition. SIB1 is sent with a period of 160 ms, with repetitions inside that window, so a failed attempt costs time rather than the whole procedure.

ix) Decode SIB1 and other SIBs

SIB1 is the first real RRC message the UE has ever seen, and it is large compared with everything before it. The parts that matter most at this moment :

NOTE : the on-demand SI mechanism is new compared with LTE. A cell may list a SIB in si-SchedulingInfo without broadcasting it, and the UE asks for it only when it needs it. This keeps the constant broadcast overhead small, which matters more in NR because a beam swept cell has to repeat everything on every beam.

x) Work out the channel bandwidth and centre frequency

This is the step that closes the loop opened in step i). The UE found an SSB on the synchronization raster with no idea where the carrier was. Now it can place it.

The anchor is Point A - the reference point from which the entire common resource block grid is counted, defined as the centre of subcarrier 0 of common resource block 0. Everything in the carrier is expressed relative to it :

  frequency ------------------------------------------------------------------------------>

  Point A
  |<--------- offsetToPointA (RBs) ---------->|
  |                                           |<--- k_SSB --->|
  |                                           |               |                  |
  |                                           |               [=== SSB, 20 RB ===]
  |
  |<============================== carrierBandwidth (RBs) ===============================>|
  [================================= the actual carrier ==================================]

  offsetToPointA   from SIB1  : Point A to the start of the SSB's RB grid
  k_SSB            from MIB   : fine offset, in subcarriers, SSB vs the RB grid
  carrierBandwidth from SIB1  : how wide the carrier really is

  (drawn with offsetToCarrier = 0, so the carrier starts at Point A)

The two offsets do different jobs and it is easy to confuse them. k_SSB, from MIB, is a fine offset in subcarriers, needed early because the SSB sits on the sync raster and will generally not line up with the resource block grid. offsetToPointA, from SIB1, is the coarse offset in resource blocks that says where the grid itself begins. Only with both does the UE know exactly where every resource block of the carrier is.

With Point A and carrierBandwidth in hand, the channel bandwidth and centre frequency are simple arithmetic, and the UE finally has the picture it has been assembling for the whole procedure. Cell search is complete, and the UE can decide whether to camp and then begin random access.

When cell search fails : where to look

Because each step depends only on the ones before it, a failure tells you a lot about where the problem is. The useful question is always "what was the last step that succeeded?".

Matlab Reference on Cell Search

• NR Cell Search and MIB and SIB1 Recovery
• NR HDL Cell Search

Reference

[1]  

• 3GPP TS 38.300 - 5.2.5.3 Cell search
• 3GPP TS 38.104 - 5.4.3 Synchronization raster (GSCN)
• 3GPP TS 38.211 - 7.4.2 Synchronization signals, 7.4.3 SS/PBCH block
• 3GPP TS 38.212 - 7.1 Broadcast channel
• 3GPP TS 38.213 - 4.1 Cell search, 13 CORESET#0 and SearchSpace#0 tables
• 3GPP TS 38.331 - MIB, SIB1