I think the most steps in any wireless system (especially high end wireless system like Cellular communication system) is Synchronization.  However, in terms of troubleshooting this step would be one of the trickest part. If you just take outside looking of the device or of Basestation, you would not get any clue on what got wrong in this step. Also, most of device (UE) log or Base station log, you would not see much detailed information about this step. You may only see 'Pass / Fail' print out in the log. Even when you find a specific log that print out some further details of this process, in most case those information would be printed out as a series of mysterious numbers. If you do not have the detailed understandings of the algorithm used for the synchronization process of the specific device, it would be almost impossible to interpret those information in the log.  Usually this is the area of lower layer DSP engineer or FPGA engineer.  However, it would be helpful if you have at least general understanding on how Synchronization process works and overall design concept of this process.

• NR Synchronization Process - Conclusion First !!! 
• Overal Procedure of Synchronization and Initial Access
• How Synchronization work ?
• What kind of Information can be derived from the Synchronizaiton Signal ?
• Where to put and when to send ?
• Synchronization Signal in Frame Structure
• What Was Actually Specified
• The five questions, answered
• The block, symbol by symbol
• Where the blocks may sit
• What the block carries
• Reference

NR Synchronization Process - Conclusion First !!!

For those who does not like long reading (including me -:), I would like to put the conclusion first. But I would suggest you to go through the whole page when you have some free time and try to get some big picture or principles of synchronization process in general in most of wireless communication.

When we say 'Synchronization' in communication technology, it usually mean 'synchronization for transmission' and 'synchronization for reception'.

In UE's point of view, 'transmitting direction' is called 'Uplink' and 'receiving direction' is called 'Downlink'. Applying this terms to synchronization process, we have two types of synchronization in cellular communication including 5G/NR called 'Downlink Synchronization' and 'Uplink Synchronization'.

Donwlink Synchronization : This is the process in which UE detect the radio boundary (i.e, the exact timing when a radio frame starts) and OFDM symbo boundary(i.e, the exact timing when an OFDM symbol starts). This process is done by detecting and analyzing SS Block. This is a pretty complicated process and follow through SS Block Page for the detailed understanding.

Uplink Synchronization : This is the process in which UE figure out the exact timing when it should send uplink data (i.e, PUSCH / PUCCH).  Usually a network (gNB) is handling multiple UEs and the network has to ensure that the uplink signal from every UE should be aligned with a common receiver timer of the network. So this involves much more complicated process and sometimes it has to adjust UE Tx timing (uplink timing) of each UE. This is called RACH process. Of course, you need to go through much longer pages of reading. Read through RACH page for the details.

NOTE :  The rest of this page is not specific description for NR Synchronization. It is overall description for any cellular communication (especially WCDMA, LTE, NR). So it is not required for you to read through this part if you don't like long reading.

Overal Procedure of Synchronization and Initial Access

Following is overall sequence of the Initial Access for most of cellular system with the focus on Synchronization process.  Technically, step (1), (2), (3) can all be regarded as synchronization step. But when we just say "Synchronization", it usually mean Downlink Synchronization as indicated in step (1), (2). Of course, Uplink Synchronization is very important as well, but usually the uplink process (step (3)) is regarded as part of RACH process and normall treated under "RACH Procedure" or "Initial Access" process.

In this page, I would mostly handle on 'Downlink Synchronization' and I would treat Uplink Synchronization in another page dealing with RACH process / Initial Access.

When we design the synchronization signal and procedure, you have consider a lot of things into consideration. In NR(5G), there would be even longer list of factors you would have to consider in designing this procedure. I put down some of common factors being proposed in 3GPP technical discussions (TDocs) on this illustration, but there would be never ending list of factors you may add.

The four boxes are the order of events. The list beside them is the design space, and NR answered every one of those questions differently from LTE.

Two things in the drawing are worth remembering while reading the rest of the page. Steps 1 and 2 are drawn as one bracket, because in NR they really are one thing. The synchronization signal and the broadcast channel share a block, so a UE that has finished step 1 has already received the payload of step 2. LTE kept them apart.

The other is step 3. Uplink synchronization does not begin until downlink synchronization has succeeded, and it needs a timing reference the UE can only get from step 1. That ordering is why a RACH failure is so often really a synchronization failure.

• Downlink first, always : the UE cannot transmit anything useful until it knows where the frame boundary is, so every uplink step inherits the accuracy of step 1.
• The design questions were open for years : periodicity, carried information, detection complexity and beam behaviour were all still being argued when this page was written. The section at the end of this page gives the answers.

How Synchronization work ?

Every system solves this the same way, and the idea is older than cellular. The transmitter sends something the receiver already knows, at a moment the receiver can predict. Correlating the two gives the timing. What differs between systems is which sequence is used, where it is placed, and how often it repeats.

The most common way to implement the Synchronization is

i) Create a predefined signal (a predefined data sequence : This signal is called Sync signal)

ii) Put the signal into a specific OFDMA symbol in a specific subframe and transmit

Since UE already have (or can derive) all the details of the predefined sync signal, it can search and detect the data from the stream of data reaching the UE. Because the sync signal is located in the predefined location in time, UE can detect the exact timing from the decoded sync signal.

Two properties decide whether that works, and both are properties of the sequence rather than of the receiver. The first is autocorrelation. The sequence has to correlate sharply with itself at zero offset and weakly everywhere else, because the peak is the timing estimate. A blunt peak means a blunt estimate.

The second is cross-correlation. Neighbouring cells transmit at the same time on the same frequency, so their sequences have to correlate weakly with each other. Otherwise the UE synchronises to the wrong cell, or to a sum of two cells that resembles neither.

NR gives PSS and SSS 127 subcarriers each, numbered 56 to 182 inside the block. That width matters more than it looks. 127 subcarriers at 15 kHz spacing is under 2 MHz. A UE can therefore search with a narrow receiver and a low sampling rate, before it knows anything about the carrier. The search therefore works the same way on a 5 MHz carrier and on a 100 MHz one.

• The peak is the measurement : timing accuracy is set by how sharp the correlation peak is, so sequence choice is a physical layer performance decision and not a formality.
• The sequence must be narrow as well as sharp : the UE searches before it knows the channel bandwidth. The search signal therefore has to fit the smallest receiver the band allows.
• Predefined means derivable, not memorised : the UE generates the candidate sequences itself, from the cell identity hypotheses. Detecting the signal and detecting the cell identity are therefore one operation.

What kind of Information can be derived from the Synchronizaiton Signal ?

Most part of the answer to this question is obvious from the definition of 'Synchronization'. Roughly we can derive following informations from the synchronization signal. Item i) or ii) is obvious...  but we can design the Synchronization signal in such a way that we can derive some additional information from it. For example, in LTE (as you see in LTE Physical Cell IDpage), we can derived Physical Cell ID from LTE Sync signal.

In NR (5G), it has been discussed on adding some additional information onto the sync signal.

i) Radio Frame Boundary (the location of the first symbol in a radio frame)

ii) Subframe Boundary (the location of the first symbol in a subframe)

iii) Some additional information (e.g, Physical Cell ID, Hypercell ID, System ID etc)

Now wiith the final decision on NR Sync signal specification , I don't see much of the additional information comparing to LTE sync signal. Even though the location and transmission period of the sync signal is pretty much different from LTE Sync signal, it looks almost same as LTE Sync signal  in terms of the type of information we can derive from the sync signal.  However, in NR Sync signal and PBCH signal is regarded as single block. If we consider PBCH as a part of sync signal, we can say NR sync signal carries more information as mentioned above.

Where to put and when to send ?

NOTE : NR Synchronization Signal transmission method is now determined and specified in 38.211 and what is described in this section would not be exactly same as NR Sync Signal Transmission. But I leave this section as it is, just to give you the general idea of various options of Sync signal transmission. If you are not interested in this kind of general description and jump directly into NR Synchronization, go to What Was Actually Specified at the end of this page.

The questions is "At which subframe and at which OFDM symbol(s), the Sync signal will be placed". Several different idea / possibilities are proposed as shown below.

Descriptions will posted later (Try to make your own story out of this .. or refer to R1-166653 ([2])

Synchronization Signal in Frame Structure

NOTE : NR Synchronization Signal in Frame Structure is now determined and specified in 38.211 and what is described in this section would not be exactly same as NR Sync Signal locations within NR Frame. But I leave this section as it is, just to give you the general idea of various options of Sync signal transmission. If you are not interested in this kind of general description and jump directly into NR Synchronization, go to What Was Actually Specified at the end of this page.

Since both Single Beam and Multibeam should be supported in 5G, there would be a little bit different strategy depending on whether it is for Single beam or Multi Beam. Within each beam management type, there can be different strategy depending on whether the network transmit the SS signal in repetitive maner or in single transmission. All of these patterns are well described in R1-1611272 as shown below.

A couple of questions that may help you to get more concrete understanding would be (Try to find answers to these questions when 3GPP specification is finalized. You may find answers to these questions even now in case of Pretrial specification)

• What is the unit of SS block ? Is it a OFDM symbol ? or a subframe ?
• What is the unit of SS burst ? Is it a subframe or multiple subframes ?
• What is the size of a SS burst ? (i.e, how many SS blocks in a SS burst) ?
• Are the data in each SS block all the same except Beam Pattern/Direction ?
• How the time gap between each SS burst is defined / configured ?

What Was Actually Specified

Everything above this heading was written while the design was still being argued, and the two NOTE paragraphs above say so. This section is the other half. The synchronization signal is now fully specified in 38.211 clause 7.4 and 38.213 clause 4.1, and the answers turn out to be narrower than the study item suggested. Of the four transmission options drawn further up this page, NR took the first one.

That is worth stating plainly before anything else. The finalised design is periodic, at a fixed position in time and a fixed position in frequency, which is Case A in the table of options above. There is no on demand sync signal, no preamble in front of user data, and no shifting window. What NR added instead is beam sweeping, and the rest of this section describes it.

The five questions, answered

The section above this one ends with five questions and an instruction to answer them once the specification is finalised. It is finalised, so here they are, in the order the page asks them.

• What is the unit of SS block ? Is it a OFDM symbol ? or a subframe ?
  Neither. An SS/PBCH block is 4 OFDM symbols by 240 subcarriers, which is 20 resource blocks. It is smaller than a slot in time and much smaller than the carrier in frequency.
• What is the unit of SS burst ? Is it a subframe or multiple subframes ?
  The term did not survive. The specification counts candidate SS/PBCH blocks inside a half frame, which is 5 ms. The word burst survives only for shared spectrum, where a discovery burst transmission window is defined.
• What is the size of a SS burst ? (i.e, how many SS blocks in a SS burst) ?
  The maximum number of candidate positions in a half frame is 4, 8 or 64, decided by the case and the band. Not all of them are transmitted, and ssb-PositionsInBurst says which ones are.
• Are the data in each SS block all the same except Beam Pattern/Direction ?
  No. Each block carries its own SS/PBCH block index, and the PBCH payload also carries a half frame bit. Two blocks in the same half frame therefore differ in content as well as in beam.
• How the time gap between each SS burst is defined / configured ?
  By ssb-periodicityServingCell, per serving cell. If that is not provided, a UE assumes a periodicity of one half frame. For initial cell selection the UE assumes two frames, which is 20 ms, and 16 frames for NTN.

The block, symbol by symbol

One table in 38.211 defines the whole structure, and four numbers in it carry the design. Read the drawing below for those four : 48, 56, 183 and 192. Everything else follows from where PSS and SSS sit and what PBCH is allowed to use around them.

PBCH gets three of the four symbols and most of the fourth. The sync signals themselves cost about one symbol and a half of the block.

• PSS and SSS never overlap in time : PSS is symbol 0 and SSS is symbol 2, so the UE detects one, then the other, and the gap between them is a fixed known interval.
• The guard around SSS is not wasted by accident : subcarriers 48 to 55 and 183 to 191 in symbol 2 are set to zero. That keeps PBCH energy away from the sequence the UE is still correlating against.
• PBCH and its DM-RS share the same resource : the reference signal is interleaved into the PBCH symbols rather than given symbols of its own. That is what keeps the block at four symbols.

Where the blocks may sit

A warning before the table. The specification labels its SS/PBCH block time patterns Case A through Case G, and the four proposal drawings further up this page are also labelled Case A through Case D. They are unrelated. The study item cases are transmission strategies, and the ones below are symbol position patterns for one strategy.

Each case fixes the first symbol index of every candidate block inside the half frame. Which case applies is decided by the frequency band in 38.101, and not chosen by the operator. One case applies to every SS/PBCH block on a cell.

The subcarrier spacing rises with the band, which is how a 64 block sweep still fits inside 5 ms at millimetre wave.

The candidate positions are indexed from 0 upward in time order inside the half frame. Whether a candidate is actually used is a separate question, answered by ssb-PositionsInBurst in the broadcast configuration. A cell with a maximum of 64 candidates may transmit far fewer.

What the block carries

The section further up this page asks what information can be derived from the synchronization signal. It answers that NR looks much like LTE, unless PBCH is counted as part of the signal. The specification does count it, so the answer is the MIB plus two things the MIB does not contain.

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))
}

Eight fields, and the block is broadcast every period whether a UE is listening or not. The payload is kept small on purpose. The field systemFrameNumber is only 6 bits here, because the four most significant bits of the SFN travel in the PBCH transport block rather than in the MIB.

The two things outside the MIB are the ones that matter for synchronization. The first is the SS/PBCH block index. When at most 4 candidates exist, the UE reads its 2 least significant bits from which DM-RS sequence the PBCH used. When more exist, 3 bits come from the DM-RS sequence and the remaining 1, 2 or 3 come from the PBCH payload. So the index is carried partly by the reference signal and partly by the message.

The second is the half frame bit. A half frame is 5 ms and a frame is 10 ms, so knowing the position inside the half frame leaves an ambiguity of exactly one half frame. That bit resolves it, and only then does the UE know where the radio frame starts.

• NR chose the least exotic option : periodic, fixed in time and fixed in frequency. The on demand and preamble based proposals drawn above were not adopted.
• Beam sweeping replaced that flexibility : up to 64 candidate positions in a half frame, each with its own index. That is what the rejected proposals were trying to buy.
• 20 ms is an assumption, not a configuration : a UE performing initial cell selection assumes 2 frames because nothing has told it otherwise. A configured UE uses ssb-periodicityServingCell, and with that absent it assumes a half frame instead.
• The case is a property of the band : 38.101 selects Case A through Case G for the band in use, so a deployment does not pick one. Every SS/PBCH block on a cell uses the same case.
• Frame timing needs three separate pieces : the symbol position inside the half frame, the block index, and the half frame bit. PSS and SSS alone do not give the radio frame boundary.
• The two sets of Case labels do not match : Case A to Case D above are transmission strategies from 2016. Case A to Case G here are symbol patterns from 38.213. Pairing them by letter gives nonsense.

Reference

[1] 3GPP R1-166107. 3GPP TSG RAN WG1 Meeting #86 - Synchronization and initial access mechanism in NR

[2] 3GPP R1-166653. 3GPP TSG RAN WG1 Meeting #86 - Consideration on synchronization for NR

[3] 3GPP R1-166910. 3GPP TSG RAN WG1 Meeting #86 -  LG_Discussion on DL Synchronization in NR v1.1_final

[4] 3GPP R1-166948. 3GPP TSG RAN WG1 Meeting #86 - Transmission of synchronization signal on demand

[5] 3GPP R1-166949. 3GPP TSG RAN WG1 Meeting #86 - Band agnostic synchronization and cell search

[6] 3GPP R1-167028. 3GPP TSG RAN WG1 Meeting #86 - Sync and Beam Acquisition Procedure in Multi-Beam Based Approach

[7] 3GPP R1-167672. 3GPP TSG RAN WG1 Meeting #86 -Synchronization in NR considering beam sweeping

[8] 3GPP R1-167705. 3GPP TSG RAN WG1 Meeting #86 - Design on NR DL Synchronization

[9] 3GPP R1-167707. 3GPP TSG RAN WG1 Meeting #86 - Initial performance evaluation of different beamforming options for NR synchronization signals

[10]  3GPP R1-1611272 3GPP TSG RAN WG1 Meeting #87 (RAN1-NR#1) - Overview of NR initial access

[11]  3GPP R1-1703422 3GPP TSG RAN WG1 Meeting #88 - On NR-SS structure and time indexing   

[12] 3GPP TS 38.211 V19.3.0 - NR; Physical channels and modulation. Clause 7.4 defines PSS, SSS and the SS/PBCH block

[13] 3GPP TS 38.213 V19.4.0 - NR; Physical layer procedures for control. Clause 4.1 defines cell search, the seven cases and the periodicity rules

[14] 3GPP TS 38.331 V19.3.0 - NR; RRC protocol specification. Source of the MIB listing above