5G/NR - Initial Access/RACH  

 

 

 

5G RACH In a Nutshell

 

  • What is it for ?  It is for establishing Uplink Synchronization
  • Two types of RACH Process : Contention based  and Non Contention Based
  • A type of RACH unique to 5G : 2 step RACH which is mainly for simplification of protocol and energy consumption
  • Possible Subcarrier Spacing of RACH Preamble : 1.25, 5, 15, 30, 60, 120 Khz
  • Preamble format and Sequence Length
    • Short Sequence : A1,A2,A3,B1,B2,B3,B4,C0,C2
    • Long Sequence : 0,1,2,3
  • What are main differences among the Preamble Format ? : Length of Preamble
  • Why are there so many different Preamble type ? The biggest reasons are to cover various range of distances between UE and Cell and to enhance reliable reception of the preamble with the optimal use of network resources.
  • RRC Parameter to determine Preamble Type, Sequence Length, PRACH Transmission Time : prach-ConfigurationIndex

5G RACH in Details

RACH stands for  Random Access Channel. It is an essential part of wireless communication systems, including 5G(NR), 4G (LTE) and even 3G(WCDMA). It plays a significant role in establishing an initial connection(Initial Access) between a device and a network.

In layman's terms, you can think of RACH as the first point of contact or the front door to the network. When a device, such as your smartphone or laptop, wants to connect to a network for the first time or after a period of inactivity, it uses the RACH to request access to the network.

Initial Access in this context means a sequence of process between UE and gNB(Network) in order for UE to aquire Uplink Synchronization and obtain specified ID for the radio access communication. In more familiar terms, this Initial Access is refered to be 'RACH process'. Depending on the document, the term Initial Access may mean 'Downlink Synchronization + RACH'. But in my case, Initial Access usually refer to RACH process and I wrote a separate page for downlink synchronization.

Even though the detailed parameter is not determined (as of Apr 2017), the overal logic of NR RACH will be very similar to LTE RACH process (Based on TR 38.804 v1.0.0 - Ref [32]). So if you are already familiar with LTE RACH process, it would easily pick up NR RACH process. If you are not familiar with LTE RACH process, I would strongly recommend to go through LTE RACH page and try to get familiar with the procedure.

Overall Procedure

There are several different types of RACH processes and different use cases where each of those different procedures are used. So it would not be easy to describe every types and use case in short. But I think the overall procedure illustrated below can give you a big picture to help you understand almost every cases of RACH procedure. For example, if you are interested in RACH for NSA Setup, [A]+[C]+[D] would be applicable. If you are interested in Contention Based RACH in SAR, [A]+[B]+[C]+[D] would be applicable.

Following is brief description for each step. Full details for each of these steps are pretty compicated and will be explained in other sections of this note.

Msg1 (Preamble Transmission): The UE selects a random access preamble from a set of predefined preambles. These preambles can be of roughly two categories: Short Preamble  and Long Preamble Format . The UE also selects a random sequence number for the preamble. After choosing the preamble and sequence number, the UE transmits the preamble on the PRACH.

Msg2 (Random Access Response): Upon receiving Msg1, the gNB (5G base station) sends a response called Msg2. Msg2 consists of several critical pieces of information, such as the Time Advance (TA) command for timing adjustment, the RAPID (Random Access Preamble ID) matching the preamble sent by the UE, and an initial uplink grant for the UE. The gNB also assigns a temporary identifier called RA-RNTI (Random Access Radio Network Temporary Identifier) to the UE.

Msg3 :Using the initial uplink grant provided in Msg2, the UE transmits Msg3 on the PUSCH (Physical Uplink Shared Channel). Msg3 is a PUSCH which may carry a certain RRC message(e.g, RrcRequest) or just be pure PHY data.

Msg4 (Contention Resolution): After processing Msg3, the gNB sends Msg4 to the UE. Msg4 is a MAC data which is for Contention Resolution. The Contention Resolution message contains the UE's identity, confirming that the gNB has correctly identified the UE, and contention has been resolved. At this step, network provide UE with C-RNTI(Cell Radio Network Temporary Identifier)

Why RACH ?

The first question poping up in your mind when you first hear about the word RACH or RACH Process would be 'Why RACH ?', 'What is the functionality/purpose of RACH process ?', "Why we need this kind of complicated (looks over-complicated) ?'.

For sure, it is not for confusing you :), RACH has very important functionality especially in LTE (and in WCDMA as well). The main purpose of RACH can be described as follows.

    i) Achieve UP link synchronization between UE and eNB

    ii) Obtain the resource for Message 3 (e.g, RRC Connection Request)

In most of the communication (especially digital comunication regardless of whether it is wired or wireless), the most important precondition is to establish the timing synchronization between the reciever and transmitter. So whatever communication technology you would study, you would see some kind of synchronization mechanism that is specially designed for the specific communication.

In NR (in LTE and WCDMA as well), the synchronization in downlink (Transmitter = gNB, Reciever = UE), this synchronization is achieved by the special synchronization channel (special physical signal pattern). Refer to Synchronization page for the details.

This downlink sync signal gets broadcasted to everybody and it is get transmitted all the time with a certain interval.

However in Uplink(Transmitter = UE, Reciever = gNB), it is not efficient (actually waste of energy and causing a lot of interference to other UEs) if UE is using this kind of broadcasting/always-on synchronization mechanism. You may easily understand this kind of problem. In case of uplink, this synchronization process should meet following criteria

    i) The synchronization process should happen only when there is immediate necessity

    ii) The synchronization should be dedicated to only a specific UE

All the complicated/confusing stories in this page is mostly about the process specially designed mechanism to meet these criteria.

Another purpose of RACH process is to obtain the resource for Msg3 (Message 3). RRC Connection Request is one example of Msg3 and there are several different types of Msg3 depending on situation. You would figure out this part in reading through this page and this is not very complicated to understand.

When we need RACH  ?

There are many situation that triggers RACH process. The list of cases are summarized in 38.300-9.2.6 as follows. The first half of the list(i~iv) is same as in LTE case.  The second half of the list would be NR specific. We don't have RRC_INACTIVE state (item v), On-Demand SIB transmition(item vii) in LTE, we have a primitive types of BeamFormaing / BeamManagement in LTE but not as sophisticated as in NR(item viii). We do have CA(SCell addition) in LTE but we don't trigger RACH in any of CA activity in LTE(item vi).

    i) Initial access from RRC_IDLE;

    ii) RRC Connection Re-establishment procedure;

    iii) Handover;

    iv) DL or UL data arrival during RRC_CONNECTED when UL synchronisation status is "non-synchronised";

    v) Transition from RRC_INACTIVE;

    vi) To establish time alignment at SCell addition;

    vii) Request for Other SI

    viii) Beam failure recovery.

Two types of RACH Procedure : Contention Based and NonContention Based

There are largely two types of RACH procedure in terms of allowable physical resources of PRACH (i.e, time and frequency location of PRACH) and sequence index of the PRACH.  This is also almost same as in LTE.

Contention based RACH Procedure

When a UE transmit a PRACH Preamble, it transmits with a specific pattern and this specific pattern is called a "Signature". In each LTE cell, total 64 preamble signatures are available and UE select randomly one of these signatures.

UE select "Randomly" one of these signatures ?

Does this mean that there is some possibility that multiple UEs send PRACH with identical signatures ?

Yes.

There is such a possibility. It means the same PRACH preamble from multipe UE reaches the NW at the same time.. this kind of PRACH collision is called "Contention" and the RACH process that allows this type of "Contention" is called "Contention based" RACH Process. In this kind of contention based RACH process, Network would go through additional process at later step to resolve these contention and this process is called "Contention Resolution" step.

Typical 'Contention Based' RACH Procedure is as follows : (Typically 4 steps)

    i) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)

    ii) UE <-- NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message)

    iii) UE --> NW : L2/L3 message

    iv) Message for early contention resolution

Now let's assume that a contention happened at step i). For example, two UEs sent PRACH. In this case, both of the UE will recieve the same T_C-RNTI and resource allocation at step ii). And as a result, both UE would send L2/L3 message through the same resource allocation(meaning with the same time/frequency location) to NW at step iii). What would happen when both UE transmit the exact same information on the exact same time/frequency location ? One possibility is that these two signal act as interference to each other and NW decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from NW and they all think that RACH process has failed and go back to step i). The other possibility would be that NW could successfully decode the message from only one UE and failed to decode it from the other UE. In this case, the UE with the successful L2/L3 decoding on NW side will get the HARQ ACK from Network. This HARQ ACK process for step iii) message is called "contention resolution" process.

This process can be summarized as below

  • In this procedure, multiple UEs can choose the same random access preamble and send it to the base station (eNodeB in LTE or gNodeB in 5G).
  • Since multiple UEs might choose the same preamble, there's a possibility of "contention" or collision.
  • After sending the preamble, the UEs wait for a response from the base station. If they receive a valid response, they proceed to send additional information to resolve the contention.
  • The network then confirms the successful access of one of the contending UEs using a unique identifier (e.g., C-RNTI). UEs that do not receive confirmation know that there was a collision, and they initiate a backoff procedure before trying again.
  • This method is typically used for initial access, when the UE is not synchronized with the network or when the network does not have prior scheduling information about the UE.

Non-Contention Based (Contention Free) RACH Procedure

But there is some cases that these kind of contention is not acceptable due to some reason (e.g, timing restriction) and these contention can be prevented. Usually in this case, the Network informs each of the UE of exactly when and which preamble signature it has to use. Of course, in this case Network will allocate these preamble signature so that it would not collide. This kind of RACH process is called "Contention Free" or "Non-Contention based RACH" procedure. To initiate the "Contention Free" RACH process, UE should be in Connected Mode before the RACH process as in Handover case.

Typical 'Contention Free' RACH Procedure is as follows : (Typically 2 steps)

    i) UE <--NW : RACH Preamble (PRACH) Assignment (This is done by RRC Configuration, not exactly part of RACH Proc)

    ii) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)

    iii) UE <--NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)

This process can be summarized as below

  • In this procedure, the network provides dedicated random access resources to specific UEs, ensuring that there's no contention or collision.
  • The UE uses the dedicated preamble provided by the network to initiate the RACH procedure.
  • Since the resources are dedicated, there's no need for a contention resolution process.
  • This method is typically used in scenarios where the network has prior knowledge about the UE's intention to initiate communication. For example, it can be used for handover procedures or when the network anticipates uplink data transmission from the UE based on downlink data or signaling.

Fundamental Difference from LTE RACH

As I mentioned above, the overall protocol sequence would be almost same in LTE and NR, but there are a few differences between the two as summarized below.

  • The major difference between LTE RACH and NR RACH would lie just before RACH Preamble gets transmitted.  It is due to BeamForming which would be supported by default (especially in mmWave) in NR. So in case when NR is operating in Beamforming mode, UE need to detect and select a best beam for RACH process. This beam selection process would be the fundamental difference between LTE RACH and NR RACH process.
  • There are much diverse preample format in 5G/NR comparing to LTE. In LTE, there are only 4 different types of Preamble types which can be comparable to Long Sequence Preamble type in 5G/NR named as type 0,1,2,3, but there are many more in 5G/NR which does not have any equivalent types in LTE. They are called short Sequence Preamble named A1,A2,A3,B1,B2,B3,B4,C0,C2.
  • Another difference is the support of 2 Step RACH for initial access. In LTE, the RACH for initial access is always 4 step process whereas in NR two step RACH is supported even for initial access.

Preamble Sequence Generation

Like LTE Preamble Sequence, NR Preamble sequence is also based on Zadoff Chu based sequence. Overall sequence generation is as follows.

The resason why we use Zadoff Chu is same as in LTE. It is due to various favorable properties, including constant amplitude before and after DFT operation, zero cyclic auto-correlation and low crosscorrelation (as mentioned in III-B of this paper).

The detailed base sequence generation algorithm can be summarized as follows. Even though the details are different, basically this is similar to LTE as well. There are two types of sequence in terms of sequence length(L_RA = 139 and 839).

< Frequency Domain Sequence Generation >

Following is the equation to generate PRACH sequence in frequency domain based on 36.211-6.3.3.1.

<Time Domain Sequence Generation >

Following is the equation to generate the time domain sequence for PRACH. Basically the big picture is to do IFFT to the frequency domain data generated above. As you notice here, this is very complicated and confusing equation. You would not need to understand every part. I just put down this equation with a lot of messy arrow just to highlight some of the important parameters. There are many small parameters that are not described here. For those details, refer to 38.211-5.3.2

< Examples >

 

Example 01 > TDD FR2 RachConfig = 70, Format A3

 

< 38.211 v15.5-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

Example 02 > TDD FR2 RachConfig = 71, Format A3

 

< 38.211 v15.5-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

 

 

Example 03 > TDD FR2 RachConfig = 74, Format A3

 

< 38.211 v15.5-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

 

Example 04 > TDD FR2 RachConfig = 76, Format A3

 

< 38.211 v15.5- Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

 

Example 05 > TDD FR2 RachConfig = 12, Format A1

 

< 38.211 v15.5- Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

 

Example 06 > TDD FR2 RachConfig = 8, Format A1

 

< 38.211 v15.5-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

With the calculated RACH transmission symbol and Preamble format 3 structure, RACH occasion in time domain can be illustrated as follows.

 

 

Example 07 > TDD FR1 RachConfig = 4, SCS = 15Khz, Format 0

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

Example 08 > TDD FR1 RachConfig = 79, SCS = 30Khz, Format A1

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 09 > TDD FR1 RachConfig = 78, SCS = 30 Khz, Format A1

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 10 > TDD FR1 RachConfig = 131, SCS = 30 Khz, Format A3

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

 

 

 

 

Example 11 > TDD FR1 RachConfig = 128, SCS = 30 Khz, Format A3

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

 

Example 12 > TDD FR1 RachConfig = 133, SCS = 30 Khz, Format B1

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 13 > TDD FR1 RachConfig = 136, SCS = 30 Khz, Format B1

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 14 > TDD FR1 RachConfig = 141, SCS = 30 Khz, Format B1

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 15 > TDD FR1 RachConfig = 160, SCS = 30 Khz, Format B4

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

Example 16 > TDD FR1 RachConfig = 156, SCS = 30 Khz, Format B4

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

 

 

Example 17> TDD FR2 RachConfig = 149, Format C0

 

< 38.211 v15.5-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum. >

 

 

 

 

Impact of Rach Occasion on Scheduling and TDD UL/DL Configuration

As you saw in the examples shown above, you would notice that figuring out exact rach occasion in time domain take some effort and sometimes confusing. In addition, there are further complications caused by RACH Occasion. Even if a UE does not transmit the rach at every possible Rach Occasion, network has to schedule PDCCH, PDSCH and to configure tdd-ul-dl-config in such a way that those valid RACH Occasion is always avaiable for the UE.

Another important thing to consider when you pick a specific Rach configuration index to use, you need to be careful that the RO is not overlapping with SSB symbols or keep a certan distance (Ngap) from the SSB.

These restrictions on validity of Rach Configuration Index (determining Rach Occasion) or validity of PDCCH, PDSCH, CSI-RS locations are specified by following specification.

38.213-8.1

For paired spectrum(FDD),

    all PRACH occasions are valid.

 

For unpaired spectrum(TDD),

    Case 1 : tdd-UL-DLConfigurationCommon is NOT configured,

      a PRACH occasion in a PRACH slot is valid if it does not precede a SS/PBCH block in the

      PRACH slot and starts at least Ngap symbols after a last SS/PBCH block reception symbol

     

    Case 2 : tdd-UL-DL-ConfigurationCommon is configured,

      a PRACH occasion in a PRACH slot is valid if it is within UL symbols, or

      a PRACH occasion in a PRACH slot is valid if it does not precede a SS/PBCH block in the PRACH slot and starts at least Ngap symbols after a last downlink symbol and at least Ngap symbols after a last SS/PBCH block transmission symbol

            < 38.213 - Table 8.1-2: Ngap values for different preamble SCS >

 

38.213-11.1

For a set of symbols of a slot corresponding to a valid PRACH occasion and Ngap symbols before the valid PRACH occasion, as described in Sublcause 8.1, the UE does not receive PDCCH, PDSCH, or CSI-RS in the slot if a reception would overlap with any symbol from the set of symbols. The UE does not expect the set of symbols of the slot to be indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated.

 

38.213-11.1.1

For a set of symbols of a slot i corresponding to a valid PRACH occasion and Ngap symbols before the valid PRACH occasion, as described in Sublcause 8.1, the UE does not expect to detect a DCI format 2_0 with an SFI-index field value indicating the set of symbols of the slot as downlink.

zeroCorrelationZoneConfig and Ncs

The Ncs in the above equation is determined by zeroCorrelationZoneConfig in RRC message and the value is determined by the following mapping table.

Following two tables (Table 6.3.3.1-5, Table 6.3.3.1-6) are applicable for Long Sequence RACH Preambles

<  38.211-Table 6.3.3.1-5:  Ncs for preamble formats with   >

 

<  38.211-Table 6.3.3.1-6:  Ncs for preamble formats with   >

 

Following tables (Table 6.3.3.1-7) are applicable for Short Sequence RACH Preambles

<  38.211-Table 6.3.3.1-7:  Ncs for preamble formats with   >

Root Sequence Index

Like LTE Root Sequence Index, NR use different numbering system at RRC layer and Physical Layer for Root Sequence Index and the mapping between these two are defined as in following tables.

 

< 38.211-Table 6.3.3.1-3: Mapping from PRACHRootSequenceIndex  i to sequence number u  for preamble formats with L_RA = 839 >

 

< 38.211-Table 6.3.3.1-4: Mapping from PRACHRootSequenceIndex  i to sequence number u  for preamble formats with L_RA = 139 >

Long vs Short Sequences

In LTE, only one type of sequence length is used (format length varies in LTE as well, but the length of the building block sequence is always same), in NR there are two types of sequence length called Long and Short Sequence are used.

Followings would be a good summary about the design concept and application of the long and short sequence. (this is from III-B of this paper )

    Long Sequence : length 839, four preamble formats that originated from the LTE preambles are supported, mainly targeting large cell deployment scenarios. These formats can only be used in FR1 and have a subcarrier spacing of 1.25 or 5 kHz.

    Short sequence : length 139, nine different preamble formats are introduced in NR, mainly targeting the small/normal cell and indoor deployment scenarios.

    • The short preamble formats can be used in both FR1 with subcarrier spacing of 15 or 30 kHz and FR2 with subcarrier spacing of 60 or 120 kHz.
    • In contrast to LTE, for the design of the short preamble formats, the last part of each OFDM symbol acts as a CP for the next OFDM symbol and the length of a preamble OFDM symbol equals the length of data OFDM symbols.
    • Benefits of Short Sequence :
      • Firstly, it allows the gNB receiver to use the same fast Fourier transform (FFT) for data and random-access preamble detection.
      • Secondly, due to the composition of multiple shorter OFDM symbols per PRACH preamble, the new short preamble formats are more robust against time varying channels and frequency errors.
      • Thirdly, it supports the possibility of analog beam sweeping during PRACH reception such that the same preamble can be received with different beams at the gNB.

Preamble Format

NR also use various types of Preamble Format as shown below. You would notice that NR PRACH preamble format is much more diverse than LTE Preamble Format. 

As you see in the following tables, two different length (L_RA) of PRACH preamble is used depending on subcarrier spacing of the preamble.

< Long Sequence >

When the subcarrier spacing of PRACH preamble is 1.25 or 5 Khz, long sequence (L_RA = 839) is used as in the following table. (NOTE : Regarding 'Restricted sets', refer to zeroCorrelationZoneConfig and Ncs)

< 38.211 - Table 6.3.3.1-1: PRACH preamble formats for   and    >

These long sequence is used only in a specific configuration for FR1. Subcarrier spacing for this configuration applies only for msg1 (PRACH).

Format

msg1 Subcarrier Spacing

Table

ConfigurationIndex

0

1.25 Khz

6.3.3.2-2

0-27

6.3.3.2-3

0-27

1

1.25 Khz

6.3.3.2-2

28-52

6.3.3.2-3

28-33

2

1.25 Khz

6.3.3.2-2

53-59

6.3.3.2-3

34-39

3

5 Khz

6.3.3.2-2

60-86

6.3.3.2-3

40-66

< Short Sequence >

When the subcarrier spacing of PRACH preamble is 15,30,60 or 120 Khz, short sequence (L_RA = 139) is used as in the following table. (NOTE : Regarding 'Restricted sets', refer to zeroCorrelationZoneConfig and Ncs)

< 38.211 - Table 6.3.3.1-2: Preamble formats for   and   where   >

NOTE : Kappa is defined as 64 in 38.211-4.1 as below. (Refer to Timing Unit page for the details)

< Frequency Bandwidth for PRACH Subcarrier Spacing >

Following illustration shows the frequency span occupied by PRACH preamble.

< Time Domain Structure of Preamble Format >

Following is the overall picture of all RACH preamble (as per Rel 15 specification) in time domain. Just pay attention to relative length differences among different types.

Followings are the illustration of RACH Preamble Time domain structure. GP(GAP) length in this illustration are from Ref 36. The number 0.509 ns(0.509 x 10^-6 ms) is the value of the parameter Tc and 64 is the value of the paramter K(Kappa).

< PRACH Cell Dimensioning >

As in LTE, the main reason for why we have so many different types of PRACH Preamble is to provide the best preamble format for vardious cell radius. Following is the table showing the use case of each Preamble format for various cell dimension. This table is from the paper : Table 2 of On the Design Details of SS PBCH Signal Generation and PRACH in 5G-NR

< Preamble Format 0 >

< Preamble Format 1 >

< Preamble Format 2 >

< Preamble Format 3 >

Following illustration shows the short sequence A,B,C. The length calculated here is based on 15 Khz frequency(u=0) interval. As this interval goes higher (e.g, 30, 60, 120, 240 Khz), the length gets shorter.

< Preamble Format A1 >

< Preamble Format A2 >

< Preamble Format A3 >

< Preamble Format B1 >

< Preamble Format B2 >

< Preamble Format B3 >

< Preamble Format B4 >

< Preamble Format C0 >

< Preamble Format C2 >

L1 Processing Time Line for PRACH

PRACH processing is should be done very accurately and in very limited time frame at fractions of a slot. so it is very important to design carefully about the PRACH reception, processing and convey the result to higher layer. The specific time line for each detailed step is not defined in 3GPP and it is upto implementation. 3GPP outlines only high level timing requirement like :

  • At which time (i.e, subframe, slot, symbols) that eNB/gNB expect PRACH (based on PRACH configuration index)
  • The maximum time window during which eNB/gNB transmit the respose to the received PRACH

The L1 processing timeline for PRACH is a sequence of carefully coordinated steps that enable a UE to establish initial communication with a base station. By transmitting a preamble, receiving a response, and adjusting timing, the UE achieves uplink synchronization, allowing for further data transmission and network access. This process is essential for the efficient operation of LTE and 5G networks, ensuring that devices can connect and communicate effectively.

The contetns in this section is an example of processing time line at L1 (Layer 1) level. I said 'an example' because these time line is not defined in 3GPP and it is implementation specific. But it will be very useful to get some understanding at this level.

The timing diagram and description is kindly contribued by HANUMANTHAPPA SH . The original diagram is well illustrated in excel spreadsheet, but it is a little too wide to show the entire span of illustration in this note as an image. It is recommended to refer to this orignal spreadsheet for looking into the detailed diagram.

The descriptions below came from Hanumanth.

Below diagram explains wrt PRACH format 0/1/2  L1-L2- RadioInterface timing diagram..

  • Time L1 recieve the configuration L2
  • radio processing time and
  • L1 processing time and time at which sending PHY indication to l2.

< Overall UL processing >

As an example, let us consider N slot is OTA slot radio is processing.

  • with respect to DL : L1 receives configuration from L2 at N-1 and send C plane msg and UL plane msg at T1a_max cp/up time to Radio.
  •  with respect to UL : L1 receives configuration from L2 at N-1 and send C plane msg at T1a_max UL CP time to Radio and later l1 receive the every symbol from radio with Ta4_max time difference sending indiaction to l2 in next splot after L1 processing complete.

Following is the description on each component of the timeline

  • L1 PUSCH processing: L1 processing processing time for PUSCH channel.. i.e l1 processing includes processing of channel estimation/equalization.. demod/deinterleave/descramble and FEC/cb/tb/crc check and preparing msg for sending indication to mac.
  • Cplane: this is an example for symbol where uplink C plane msg is prepare and sending to RU..
  • Uplane: this is an example for symbol where uplink U plane msg is start receiving from RU and copying into L1 buffers..
  • Context: this is context used in l1 as ping pong buffer etc.

< PRACH format 0 >

  • L1 receives configuration from L2 at N-1 and send C plane msg at T1a_max UL CP time to Radio and l1 receive the symbol from radio at slot Nth boundary with Ta4_max time.
  • L1 processing it at n+1 slot and sending indiaction to l2 at N+2 start of the slot.

Following is the description on each component of the timeline

  • L1 processing slot: L1 processing processing time for PRACH channel.. i.e l1 processing includes processing of prach IQ's.. correlation with ref seq/time doamin convert/AGC/IQ Combining/PeakSearch etc and preparing msg for sending indication to mac.
  • Cplane: this is an example for symbol where uplink C plane msg is prepare and sending to RU..
  • Radio processing : processing time for radio..
  • Uplane: this is an example for symbol where uplink U plane msg is start receiving from RU and copying into L1 buffers.

< PRACH format 1 >

  • L1 receives configuration from L2 at N-1 and send C plane msg at T1a_max UL CP time to Radio and L1 receive the each symbol from radio at duration of 800usec with Ta4_max time.
  • L1 receive the all the symbols and process at n+2 slot and sending indiaction to l2 at N+3 start of the slot.

Following is the description on each component of the timeline

  • L1 processing slot: L1 processing processing time for PRACH channel.. i.e l1 processing includes processing of prach IQ's.. correlation with ref seq/time doamin convert/AGC/IQ Combining/PeakSearch etc and preparing msg for sending indication to mac.
  • Cplane: this is an example for symbol where uplink C plane msg is prepare and sending to RU..
  • Radio processing : processing time for radio..
  • Uplane: this is an example for symbol where uplink U plane msg is start receiving from RU and copying into L1 buffers.

< PRACH format 2 >

  • L1 receives configuration from L2 at N-1 and send C plane msg at T1a_max UL CP time to Radio and L1 receive the each symbol from radio at duration of 800usec with Ta4_max time.
  • L1 receive the all the symbols and process at n+4 slot and sending indication to L2 at N+5 start of the slot.

Following is the description on each component of the timeline

  • L1 processing slot: L1 processing processing time for PRACH channel.. i.e l1 processing includes processing of prach IQ's.. correlation with ref seq/time doamin convert/AGC/IQ Combining/PeakSearch etc and preparing msg for sending indication to mac.
  • Cplane: this is an example for symbol where uplink C plane msg is prepare and sending to RU..
  • Radio processing : processing time for radio..
  • Uplane: this is an example for symbol where uplink U plane msg is start receiving from RU and copying into L1 buffers.

Random Access Configuration

As in LTE, NR Random Access Configuration is the parameter that determine when (i.e, which radio frame and which subframe) UE is allowed to transmit PRACH Preamble and what kind of Preamble format it should transmit. If you are familiar with the interpretation of LTE RACH configuration table , you would easily understand this table as well. Except n_SFN mod x = y part, everything is same as in LTE case.

< 38.211 v15.5.0-Table 6.3.3.2-2: Random access configurations for FR1 and paired spectrum/supplementary uplink >

 

Just for clarity, let me give you a couple of examples.

 

Example 1 > PRACH Configuration Index = 0

    In this case, x is 16 and y = 1. It means UE is allowed to transmit PRACH in every odd radio frame (i.e, the radio frame meeting n_SFN mod 16 = 1).  UE is allowed to transmit the PRACH at SFN = 1, 17, 33, ....

    In this case, Subframe number is set to 1. It means that UE can transmit PRACH at the subframe 1 within the radio frame determined as above.

 

Example 2 > PRACH Configuration Index = 27

    In this case, x = 1 and y = 0. It means UE is allowed to transmit PRACH in radio frame (i.e, the radio frame meeting n_SFN mod 1 = 0). UE is allowed to transmit at every SFN.

    In this case, Subframe number is set to 0,1,2,3,4,5,6,7,8,9. It means that UE can transmit PRACH at any subframe within the radio frame determined as above.

 

< 38.211 v15.3.0-Table 6.3.3.2-3: Random access configurations for FR1 and unpaired spectrum >

New configuration added at Release 16.

 

< 38.211 v15.3.0-Table 6.3.3.2-4: Random access configurations for FR2 and unpaired spectrum >

NOTE : I wrote a visualized version of this table using Matlab 5G Toolbox here.

RRC Parameters for RACH Process

Parameter (IE)

Description

Reference

prach-ConfigurationIndex

   38.321-5.1

prach-RootSequenceIndex

   38.211-6.3.3

zeroCorrelationZoneConfig

  38.211-6.3.3

restrictedSetConfig

   38.211-6.3.3
PreambleInitialReceivedTargetPower

initial preamble power

 38.321-5.1.3
rsrp-ThresholdSSB    
csirs-dedicatedRACH-Threshold    
sul-RSRP-Threshold    
ssb-Threshold    

powerRampingStep

   38.321-5.1
ra-PreambleIndex    

PreambleTransMax

   38.321-5.1

ra-Msg3SizeGroupA

   38.321-5.1

messagePowerOffsetGroupB

    

ra-ResponseWindowSize

   38.321-5.1

ra-ContentionResolutionTimer

   38.321-5.1

PreambleStartIndex

   38.321-5.1

NumberofRA-Preambles

    

zeroCorrelationZoneConfig

   38.211-6.3.3

ra-ResponseWindow

    

rach-ControlResourceSet

    

msg3-transformPrecoding

 Msg3 Transform Precoding 38.213-8.3

msg3-SubcarrierSpacing

Msg3 Subcarrier Spacing 38.213-8.3
     
     

Followings are based on 38.331 v16.3.0

 

RACH-ConfigCommon ::= SEQUENCE {

    rach-ConfigGeneric                      RACH-ConfigGeneric,

    totalNumberOfRA-Preambles          INTEGER (1..63) OPTIONAL, -- Need S

    ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE {

        oneEighth               ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

        oneFourth               ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

        oneHalf                  ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

        one                       ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

        two                       ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32},

        four                      INTEGER (1..16),

        eight                     INTEGER (1..8),

        sixteen                  INTEGER (1..4)

    } OPTIONAL, -- Need M

    groupBconfigured SEQUENCE {

        ra-Msg3SizeGroupA          ENUMERATED {b56, b144, b208, b256, b282, b480, b640,

                                                               b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, spare1},

        messagePowerOffsetGroupB        ENUMERATED { minusinfinity, dB0, dB5, dB8, dB10, dB12, dB15, dB18},

        numberOfRA-PreamblesGroupA     INTEGER (1..64)

    } OPTIONAL, -- Need R

    ra-ContentionResolutionTimer          ENUMERATED { sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64},

    rsrp-ThresholdSSB                         RSRP-Range OPTIONAL, -- Need R

    rsrp-ThresholdSSB-SUL                  RSRP-Range OPTIONAL, -- Cond SUL

    prach-RootSequenceIndex CHOICE {

        l839             INTEGER (0..837),

        l139             INTEGER (0..137)

    },

    msg1-SubcarrierSpacing                SubcarrierSpacing OPTIONAL, -- Cond L139

    restrictedSetConfig                      ENUMERATED {unrestrictedSet, restrictedSetTypeA, restrictedSetTypeB},

    msg3-transformPrecoder               ENUMERATED {enabled} OPTIONAL, -- Need R

    ...,

    [[

    ra-PrioritizationForAccessIdentity-r16 SEQUENCE {

        ra-Prioritization-r16                  RA-Prioritization,

        ra-PrioritizationForAI-r16           BIT STRING (SIZE (2))

    } OPTIONAL, -- Cond InitialBWP-Only

    prach-RootSequenceIndex-r16 CHOICE {

        l571                                      INTEGER (0..569),

        l1151                                    INTEGER (0..1149)

    } OPTIONAL -- Need R

    ]]

}

 

RACH-ConfigDedicated ::= SEQUENCE {

    cfra                                         CFRA OPTIONAL, -- Need S

    ra-Prioritization                          RA-Prioritization OPTIONAL, -- Need N

    ...,

    [[

    ra-PrioritizationTwoStep-r16         RA-Prioritization OPTIONAL, -- Need N

    cfra-TwoStep-r16                      CFRA-TwoStep-r16 OPTIONAL -- Need S

    ]]

}

 

CFRA ::= SEQUENCE {

    occasions SEQUENCE {

        rach-ConfigGeneric                 RACH-ConfigGeneric,

        ssb-perRACH-Occasion            ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen}

             OPTIONAL -- Cond Mandatory

             OPTIONAL, -- Need S

    }

    resources CHOICE {

        ssb SEQUENCE {

            ssb-ResourceList                SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource,

            ra-ssb-OccasionMaskIndex   INTEGER (0..15)

        },

        csirs SEQUENCE {

            csirs-ResourceList               SEQUENCE (SIZE(1..maxRA-CSIRS-Resources)) OF CFRA-CSIRS-Resource,

            rsrp-ThresholdCSI-RS          RSRP-Range

        }

    },

    ...,

    [[

    totalNumberOfRA-Preambles          INTEGER (1..63) OPTIONAL -- Cond Occasions

    ]]

}

 

CFRA-TwoStep-r16 ::= SEQUENCE {

    occasionsTwoStepRA-r16 SEQUENCE {

        rach-ConfigGenericTwoStepRA-r16           RACH-ConfigGenericTwoStepRA-r16,

        ssb-PerRACH-OccasionTwoStepRA-r16      ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four,

                                                                                     eight, sixteen}

    } OPTIONAL, -- Need S

    msgA-CFRA-PUSCH-r16                              MsgA-PUSCH-Resource-r16,

    msgA-TransMax-r16                                  ENUMERATED {n1, n2, n4, n6, n8, n10, n20, n50, n100, n200}

                                                                                     OPTIONAL, -- Need S

    resourcesTwoStep-r16 SEQUENCE {

        ssb-ResourceList                        SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource,

        ra-ssb-OccasionMaskIndex           INTEGER (0..15)

    },

    ...

}

 

CFRA-SSB-Resource ::= SEQUENCE {

    ssb                            SSB-Index,

    ra-PreambleIndex         INTEGER (0..63),

    ...,

    [[

    msgA-PUSCH-Resource-Index-r16                  INTEGER (0..3071) OPTIONAL -- Cond 2StepCFRA

    ]]

}

 

CFRA-CSIRS-Resource ::= SEQUENCE {

    csi-RS                    CSI-RS-Index,

    ra-OccasionList        SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER (0..maxRA-Occasions-1),

    ra-PreambleIndex      INTEGER (0..63),

}

RACH-ConfigGeneric ::= SEQUENCE {

    prach-ConfigurationIndex                            INTEGER (0..255),

    msg1-FDM                                                ENUMERATED {one, two, four, eight},

    msg1-FrequencyStart                                 INTEGER (0..maxNrofPhysicalResourceBlocks-1),

    zeroCorrelationZoneConfig                           INTEGER(0..15),

    preambleReceivedTargetPower                     INTEGER (-202..-60),

    preambleTransMax                                     ENUMERATED {n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200},

    powerRampingStep                                     ENUMERATED {dB0, dB2, dB4, dB6},

    ra-ResponseWindow                                   ENUMERATED {sl1, sl2, sl4, sl8, sl10, sl20, sl40, sl80},

    ...,

    [[

    prach-ConfigurationPeriodScaling-IAB-r16           ENUMERATED {scf1,scf2,scf4,scf8,scf16,scf32,scf64}

                                                                                         OPTIONAL, -- Need R

    prach-ConfigurationFrameOffset-IAB-r16 INTEGER (0..63) OPTIONAL, -- Need R

    prach-ConfigurationSOffset-IAB-r16 INTEGER (0..39) OPTIONAL, -- Need R

    ra-ResponseWindow-v1610 ENUMERATED { sl60, sl160} OPTIONAL, -- Need R

    prach-ConfigurationIndex-v1610 INTEGER (256..262) OPTIONAL -- Need R

    ]]

}

cfra : Resources for contention free random access to a given target cell

ra-ssb-OccasionMaskIndex : Explicitly signalled PRACH Mask Index for RA Resource selection. The mask is valid for all SSB resources signalled in ssb-ResourceList

ssb : The ID of an SSB transmitted by this serving cell.

ra-PreambleIndex : The preamble index that the UE shall use when performing CF-RA upon selecting the candidate beams identified by this SSB.

csi-RS : The ID of a CSI-RS resource defined in the measurement object associated with this serving cell.

ra-OccasionList : RA occasions that the UE shall use when performing CF-RA upon selecting the candidate beam identified by this CSI-RS.

ra-PreambleIndex : The RA preamble index to use in the RA occasions assoicated with this CSI-RS.

RACH Procedure for Initial Attach

According to 38.321, I noticed that NR RACH process is very similar to LTE RACH procedure. Of course, there will be small differences in terms of the detailed parameters but overall procedure is almost same. Actually the overall procedure for LTE RACH, LTE BL/CE(M1) RACH, LTE NB RACH and NR RACH are almost same even though there are minor differences in the parameters. I personally recommend you to read through all of these RACH pages. If you read all of these RACH pages for LTE, M1, M2, NR, you will gradually get your own intuitive understandings on RACH procedure (Don't try to memorize these sequence, just read through several times whenever you have time and the overall sequence will automatically be imprinted in your brain).

In following sequence, I put the steps labelled as (A)~(J) and steps as (1)~(9). The steps (A)~(J) is the specific messages being transmitted by gNB and UE. The steps (1)~(9) are internal procedure in UE and gNB that are required to transmit or receive the message.

I will complete the detailed description once RRC specification for this part is finalized.

Step (A) and (1) : System Information (for initial attach) or RRC Connection Reconfiguration (for LTE Interplay)

With the completion of these two steps, UE should be able to get all the information as follows (based on 38.213-8 Random Access Procedure)

  • Configuration of PRACH transmission Parameters
    • PRACH Preamble Format
    • Time Resources
    • Frequency Resources
  • Parameters for determining the root sequences and their cyclic shifts in the PRACH Preamble sequence set
    • index to logical root sequence table
    • Cyclic Shift(Ncs)
    • Set Type (unrestricted, restricted set A or restricted set B)

Step (B) : Msg1 - PRACH Preamble

At this step, UE transmit PRACH Preamble with RA-RNTI if all the condition for PRACH transmission is met. RA-RNTI is calculated by the following equation according to 38.321-5.1.3: (gNB calculate RA-RNTI based on following equation)

    RA-RNTI = RA-RNTI= 1 + s_id + 14 t_id + 14 80 f_id + 14 80 8 ul_carrier_id

      ,s_id : the index of the first OFDM symbol of the specified PRACH (0 <= s_id < 14)

      ,t_id : the index of the first slot symbol of the specified PRACH  in a system frame (0 <= t_id < 80)

      ,f_id : the index of the the specified PRACH in the frequency domain(0 <= s_id < 8)

      ,ul_carrier_id : UL carrier used for Msg1 transmission (0 = normal carrier, 1 = SUL carrier)

Step (2) and (C) : Msg 2 - RAR (PDCCH/PDSCH )

At this step (i.e, after PRACH transmission), following procedure will happen (based on 38.213-8.2 Random Access Response)

  • gNB sends a DCI scrambled with RA-RNTI value calculated as above.
  • UE tries to detect a PDCCH (DCI) with the corresponding RA-RNTI within the period of RAR-Window. (Within ra-ResponseWindow, UE looks for DCI in the search space : Type 1 PDCCH Common Search Space) 
  • DCI format for scheduling RAR PDSCH is DCI format 1_0 with RA RNTI.
  • Resource Allocation Type for the Msg2 PDSCH would be Resource Allocation Type 1 (See How to dertermine the Resource Allocation Type ?)
  • Frequency Domain Resource Allocation for the PDSCH is specified by DCI format 1_0 with RA RNTI.
  • Time Domain Resource Allocation for the PDSCH is specified by DCI format 1_0 with RA RNTIand PDSCH-ConfigCommon.   
  • The RAR-Window is configured by rar-WindowLength IE in a SIB message
  • If UE successfully decoded the PDCCH, it decodes PDSCH carrying RAR data.
  • After decoding RAR, UE checked if RAPID in RAR matches the RAPID assigned to the UE.
  • This PDCCH and PDSCH should be carried in same subcarrier spacing and cyclic prefix as SIB1.

Following is the data structure of MAC PDU that carries RAR(Random Access Response)

NOTE 1 : Regarding the details of Timing Advance File, refer to Timing Advance Page

NOTE 2  : 'Msg3 PUSCH time resource allocation'(K2 for msg3) would refer to pusch-ConfigCommon->pusch-TimeDomainAllocationList in RrcReconfiguration (in case of NSA) or in SIB1 (in case of SA). If this IEs are not configured, it would refer to PUSCH Default Resource Allocation Table.

NOTE 3  : Does UE have to send HARQ ACK/NACK in response to RAR reception ? No. If you look at the DCI 1_0 with RA-RNTI, there is no information about PUCCH or K1 value. This implies that gNB is not expecting HARQ ACK/NACK for RAR.

NOTE 4  : Then how gNB know whether RAR is properly recieved/decoded by UE or not ? According to 38.213-8.2, gNB may conclude that UE received/decoded RAR properly if UE does not transmit PRACH again.

    If the UE does not detect the DCI format 1_0 with CRC scrambled by the corresponding RA-RNTI within the window,or if the UE does not correctly receive the transport block in the corresponding PDSCH within the window

Step (3) and (D) : Msg3 (PUSCH)

At this step (i.e, right before sending Msg3), following things will happen (based on 38.213-8.3 Msg3 PUSCH)

  • UE shall determine whether it will apply transform precoding for Msg 3 PUSCH or not, based on the RRC parameter called msg3-tp (msg3-transformPrecoding)
  • UE shall determine the subcarrier spacing for Msg3 PUSCH from the RRC parameter called msg3-scs (Subcarrier Spacing).
  • UE shall transmit Msg3 PUSCH on the same serving cell to which it sent PRACH

NOTE 1 : k2 is determined by RAR (See NOTE 2 of this section)

NOTE 2  : Δ is determined by following table. uPUSCH refers to subcarrier spacing(numerology) for msg3.

 

< 38.214 v15.3 -Table 6.1.2.1.1-5: Definition of value Δ >

Example >  Following is an example showing how the delay between RAR and msg3 PUSCH is determined in real protocol stack. This is a SA initial attach process. The test and log shown is from Amarisoft.

Based on following informations, the time delay between RAR and msg3 PUSCH is k2 + Δ = 7 + 3 = 10 slots. This is same as SFN time stamp in the log which is 120.17[msg3 SFN] - 120.7[RAR SFN] = 10 slots.

[Info 1] Numerology (Subcarrier Spacing)

 

[Info 2] pusch-TimeDomainAllocationList in SIB1

    pusch-ConfigCommon setup: {

      pusch-TimeDomainAllocationList {

        {

          k2 6,

          mappingType typeB,

          startSymbolAndLength 41

        },

        {

          k2 6,

          mappingType typeB,

          startSymbolAndLength 52

        },

        {

          k2 7,

          mappingType typeB,

          startSymbolAndLength 52

        }

      },

 

[Info 3] RAR Timing and Contents : 120.7

    Message: RAR: bi=0 rapid=57

    Data:
    bi=0
    rapid=57
    ta=4
    ul_grant:
    hopping_flag=0
    riv=0x48e
    time_domain_rsc=2==> This indicates k2 = 7 according to [Info 1]
    mcs=0
    tpc_command=3
    csi_request=0
    tc-rnti=0x6253

 

[Info 4] msg3 PUSCH Timing and Contents : 120.17

    PUSCH @ 120.17 (msg3)

    From: ue01.log #15

    Info: ue01.log (1496562B), v2021-06-17

    Time: 11:52:51.343

    Message: harq=0 prb=0:12 symb=10:4 CW0: tb_len=12 mod=2 rv_idx=0 cr=0.12 retx=0

 

Step (4) and (E) : Msg4 - Contention Resolution (PDCCH/PDSCH)  

At this step (i.e, right after sending Msg3), following things will happen (based on 38.321 - 5.1.5). For simplicity, I would describe only on successful case here.

  • Start ra-ContentionResolutionTimer
  • Monitor to decode PDCCH with TC-RNTI (While ra-ContentionResolutionTimer is running , UE looks for DCI in the search space : Type 1 PDCCH Common Search Space) 
  • If PDCCH is successfully decoded,
    • decode PDSCH carrying the MAC CE
    • Set C-RNTI = TC-RNTI
  • discard ra-ContentionResolutionTimer
  • consider this Random Access Procedure successfully completed

 

Step (5) and (F) : HARQ ACK for Msg4  

Once UE successfully decode Msg4 (Contention Resolution), UE sends HARQ ACK for the data(PDSCH carrying Msg4).

 

38.213 - 8.4 states as follows :

In response to the PDSCH reception with the UE contention resolution identity, the UE transmits HARQ-ACK information in a PUCCH. A minimum time between the last symbol of the PDSCH reception

RACH Procedure for LTE-Interworking (ENDC)

This is the process that happens when a LTE cell add NR Cell as a process of Dual Connectivity. Before you go into the details of this process, I would suggest you to read LTE-Interworking page and get some big picture first.

There are two difference options (cases) of the RACH process for ENDC(EUTRA-NR Dual Connectivity) - CBRA(Contention Based RACH) and CFRA(Contention Free RACH) as described below.

< Case 1 > CBRA (Contention Based RACH)

Since this is CBRA, the basic sequence is very similar to the RACH procedure for the initial attach that is described in previous section. Some minor differences comparing to the initial Attach case are as follows.

  • UE recieves all the information about Sync and RACH configuration from LTE RRC Connection Reconfiguration instead of MIB/SIB in NR.
  • No PDSCH (carrying Contention Resolution MAC CE) is needed for Msg4. A UL Grant(DCI/PDCCH) for PUSCH functions as a kind of CR(Contention Resolution). At first, I felt strange with this step and was wondering where this modification comes from in 3GPP. After some investigation, I think this modification is based on following statements.
    • 38-213 "8.4 PDSCH with UE contention resolution identity" states "In response to an Msg3 PUSCH transmissionwhen a UE has not been provided with a C-RNTI, the UE attempts to detect a PDCCH with a corresponding TC-RNTI scheduling a PDSCH that includes a UE contention resolution identity." => it imply that CBRA for ENDC do not require PDSCH carrying CR MAC CE because C-RNTI has already beed provided to UE via  newUE-Identity in SpCellConfig.ReconfigurationWithSync.
    • 38.321-"5.1.5   Contention Resolution" states

        • Contention Resolution is based on either C-RNTI on PDCCH of the SpCell or UE Contention Resolution Identity on DL-SCH.

        Once Msg3 is transmitted, the MAC entity shall:

        ...

        1> if notification of a reception of a PDCCH transmission is received from lower layers:

          2> if the C-RNTI MAC CE was included in Msg3:

            3>if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission; or

            ...

              4> consider this Contention Resolution successful;

    • 38.331-"5.3.5.5.2 Reconfiguration with sync" states

        • The UE shall perform the following actions to execute a reconfiguration with sync.

        ...

        1>  apply the value ofthe newUE-Identity as the C-RNTI for this cell group;

NOTE : Check Example 01 and Example 02 for clearer understandings on this procedure.

< Case 2 > CFRA (Contention Free RACH)

RACH Occasion

RACH Occasion is an area specified in time and frequency domain that are available for the reception of RACH preamble. In LTE, there is only one RACH occasion specified by RRC message(SIB2) for all the possible RACH preambles, but in NR story gets more complicated. In NR, the sync signal (SSB) is associated with different beam and UE select a certain beam and send PRACH using that beam. In order for NW to figure out which beam UE has selected, 3GPP defines a specific mapping between SSB and RACH Occasion (RO). By detecing which RO UE send PRACH to, NW can figure out which SSB Beam that UE has selected.

The mapping between SSB and RACH Occasion is defined by the following two RRC parameters.

  • msg1-FDM
  • ssb-perRACH-OccasionAndCB-PreamblesPerSSB

msg-FDM specifies how many RO are allocated in frequency domain (at the same location in time domain). ssb-perRACH-OccasionAndCB-PreamblesPerSSB specifies how many SSB can be mapped to one RO and how many premable index can be mapped to single SSB.

The overall mapping logic is descried in 38.213 - 8.1 as below.

  • First, in increasing order of preamble indexes within a single PRACH occasion
  • Second, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions
  • Third, in increasing order of time resource indexes for time multiplexed PRACH occasions within a PRACH slot
  • Fourth, in increasing order of indexes for PRACH slots

I don't think we can easily get a big picture of the mapping logic just from this written description. You may get some visualized form of the mapping logic in R1-1801040.

Based on these two documents, I tried to make some examples based on my interpretation (please send me an email if you don't agree with my interpretation).

NOTE : In the following examples, it is illustrated as if all RO are positioned right next to each other in time domain, but in reality the ROs are dispersed according to RACH configuration table and time domain symbol determination equation. See these examples for the details.

 

Example 01 >

  • msg1-FDM = one
  • ssb-perRACH-OccasionAndCB-PreamblesPerSSB = one

 

Example 02 >

  • msg1-FDM = two
  • ssb-perRACH-OccasionAndCB-PreamblesPerSSB = one

 

Example 03 >

  • msg1-FDM = two
  • ssb-perRACH-OccasionAndCB-PreamblesPerSSB = eight

 

Example 04 >

  • msg1-FDM = two
  • ssb-perRACH-OccasionAndCB-PreamblesPerSSB = oneHalf

RACH Sequence Example 01 > ENDC - CBRA(Contention Based RACH)

This is an example of ENDC CBRA captured and shared by Amarisoft. Following is the RACH configuration for this example sequence.

    rach-ConfigCommon setup: {

      rach-ConfigGeneric {

        prach-ConfigurationIndex 160, ==> Preamble Format B4

        msg1-FDM one,

        msg1-FrequencyStart 0,

        zeroCorrelationZoneConfig 15,

        preambleReceivedTargetPower -110,

        preambleTransMax n7,

        powerRampingStep dB4,

        ra-ResponseWindow sl20

      },

      ssb-perRACH-OccasionAndCB-PreamblesPerSSB one: n8,

      ra-ContentionResolutionTimer sf64,

      prach-RootSequenceIndex l139: 1,

      msg1-SubcarrierSpacing kHz30,

      restrictedSetConfig unrestrictedSet

    },

 

(1) msg1 - PRACH

    PRACH => Message: sequence_index=51 ta=0 prb=0:12 symb=2:12 snr=15.5

 

(2) msg2 - RAR

    MAC => Message: RAR: rapid=51

    PDCCH => Message: ss_id=1 cce_index=0 al=4 dci=1_0

    PDSCH => Message: harq=si prb=0:2 symb=1:13 CW0: tb_len=11 mod=2 rv_idx=0 cr=0.19

 

(3) msg3 - PUSCH

    PUSCH =>

       Message: harq=0 prb=48 symb=0:14 CW0: tb_len=9 mod=2 rv_idx=0 cr=0.30 retx=0 crc=OK snr=23.3 epre=-57.4

 

(4) msg4 - PDCCH with UL Grant

    PDCCH => Message: ss_id=3 cce_index=2 al=2 dci=0_1

 

(5) msg5 - PUSCH

    PUSCH =>

     Message: harq=0 prb=47:2 symb=0:14 CW0: tb_len=101 mod=4 rv_idx=0 cr=0.64 retx=0 crc=OK snr=20.7 epre=-57.3

    MAC => Message: LBSR:bitmap=00 PAD:len=97

RACH Sequence Example 02 > ENDC - CBRA(Contention Based RACH)

Following is an example from Amari Callbox from Amarisoft and a commercial UE.  You may need a full RrcConnectionReconfiguration message to interpret the detailed contents of the physical channels. Check this for the full RrcConnectionReconfig message.

 

PRACH @ SFN 709.19

    Time: 18:50:56.383

    Message: sequence_index=1 ta=4 prb=3:12 symb=2:12 snr=14.4

 

RAR

    Time: 18:50:56.384

    Message: RAR: rapid=1

     

    Data:

        rapid=1

          ta=4

          ul_grant:

            hopping_flag=0

            riv=0x2

            time_domain_rsc=2

            mcs=4

            tpc_command=3

            csi_request=0

          tc-rnti=0x4602

 

PDSCH @ SFN 710.10

    Time: 18:50:56.384

    Message: harq=si prb=49:2 symb=1:13 CW0: tb_len=11 mod=2 rv_idx=0 cr=0.19

 

PDCCH @ SFN 710.10

    Time: 18:50:56.384

    Message: ss_id=1 cce_index=0 al=4 dci=1_0

     

    Data:

        rb_alloc=0x64

        time_domain_rsc=0

        vrb_to_prb_map=0

        mcs=2

        tb_scaling=0

 

PUSCH @ SFN 710.18

    Time: 18:50:56.392

    Message: harq=0 prb=2 symb=0:14 CW0: tb_len=9 mod=2 rv_idx=0 cr=0.30 retx=0

             crc=OK snr=7.5 epre=-122.4 ta=-1.0

 

PDCCH @ SFN 711.5

    Time: 18:50:56.392

    Message: ss_id=2 cce_index=0 al=2 dci=0_1 k2=4

     

    Data:

        rb_alloc=0x4c5

        time_domain_rsc=1

        mcs=0

        ndi=1

        rv_idx=0

        harq_process=0

        dai=3

        tpc_command=1

        antenna_ports=0

        srs_request=0

        dmrs_seq_init=0

        ul_sch_indicator=1

 

PUSCH @ SFN 711.9

    Time: 18:50:56.397

    Message: harq=0 prb=2:29 symb=0:14 CW0: tb_len=133 mod=2 rv_idx=0 cr=0.12 retx=0

             crc=OK snr=21.8 epre=-100.8 ta=-0.5

RACH Sequence Example 03 > SA - CBRA(Contention Based RACH)

Following is an example from Amari Callbox from Amarisoft and a commercial UE.  You may need a full SIB1 message to interpret the detailed contents of the physical channels. Check this for the full SIB1 message.

 

PRACH @ SFN 485.19

    Time: 09:19:50.560

    Message: sequence_index=0 ta=6 prb=3:12 symb=2:12 snr=18.5

RAR

    Time: 09:19:50.562

    Message: RAR: rapid=0

     

    Data:

        rapid=0

          ta=6

          ul_grant:

            hopping_flag=0

            riv=0x2

            time_domain_rsc=2

            mcs=4

            tpc_command=3

            csi_request=0

          tc-rnti=0x4601

PDSCH @ SFN 486.10

    Time: 09:19:50.562

    Message: harq=si prb=46:2 symb=1:13 CW0: tb_len=11 mod=2 rv_idx=0 cr=0.19

PDCCH @ SFN 486.10

    Time: 09:19:50.562

    Message: ss_id=1 cce_index=0 al=4 dci=1_0

     

    Data:

        rb_alloc=0x5e

        time_domain_rsc=0

        vrb_to_prb_map=0

        mcs=2

        tb_scaling=0

PUSCH @ SFN 486.18

    Time: 09:19:50.569

    Message: harq=0 prb=2 symb=0:14 CW0: tb_len=9 mod=2 rv_idx=0 cr=0.30 retx=0

             crc=OK snr=17.3 epre=-110.1 ta=-0.5

     

    Time: 09:19:50.569

    Message: RRC setup request

RrcSetupRequest

    Data:

    0000:  10 59 26 8e 90 e6                                 .Y&...

    {

      message c1: rrcSetupRequest: {

        rrcSetupRequest {

          ue-Identity randomValue: '000001011001001001101000111010010000111'B,

          establishmentCause mo-Signalling,

          spare '0'B

        }

      }

    }

RrcSetup

    {

      message c1: rrcSetup: {

        rrc-TransactionIdentifier 0,

        criticalExtensions rrcSetup: {

          radioBearerConfig {

            srb-ToAddModList {

              {

                srb-Identity 1

              }

            }

          },

          masterCellGroup {

            cellGroupId 0,

         ......

    }

UECRI

    Time: 09:19:50.569

    Message: UECRI:1059268e90e6 LCID:0 len=323 PAD: len=7

PDCCH @ SFN 487.5

    Time: 09:19:50.569

    Message: ss_id=1 cce_index=0 al=4 dci=1_0

     

    Data:

        rb_alloc=0x469

        time_domain_rsc=0

        vrb_to_prb_map=0

        mcs=6

        ndi=1

        rv_idx=0

        harq_process=0

        dai=0

        tpc_command=1

        pucch_rsc=0

        harq_feedback_timing=3

PDSCH @ SFN 487.5

    Time: 09:19:50.569

    Message: harq=0 prb=22:26 symb=1:13 k1=4 CW0: tb_len=341 mod=2 rv_idx=0 cr=0.44 retx=0

Reference - 3GPP

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

[2] 3GPP R1-166222. 3GPP TSG RAN WG1 Meeting #86 - Evaluation and analysis on coverage issue of initial access for NR above 6 GHz

[3] 3GPP R1-166384. 3GPP TSG RAN WG1 Meeting #86 -  Initial Access Consideration for Millimeter Wave Systems

[4]3GPP R1-166385. 3GPP TSG RAN WG1 Meeting #86 - Initial access and mobility consideration for NR sub6GHz

[5] 3GPP R1-166417. 3GPP TSG RAN WG1 Meeting #86 - Overview of NR Initial Access

[6] 3GPP R1-166483. 3GPP TSG RAN WG1 Meeting #86 - NR Initial Access and Mobility Management

[7] 3GPP R1-166586 . 3GPP TSG RAN WG1 Meeting #86 -Considerations on Initial Access Design

[8] 3GPP R1-166639. 3GPP TSG RAN WG1 Meeting #86 - Discussion on initial access and mobility for NR standalone cell

[9] 3GPP R1-166678 3GPP TSG RAN WG1 Meeting #86 - Discussion on initial access in NR

[10] 3GPP R1-166798 3GPP TSG RAN WG1 Meeting #86 - PHY initial access procedure for multi-/single-beam based approaches

[11]  3GPP R1-166944 3GPP TSG RAN WG1 Meeting #86 - Band-agnostic initial access for NR   

[12] 3GPP R1-167055 3GPP TSG RAN WG1 Meeting #86 - Overview of initial access and mobility   

[13] 3GPP R1-167056 3GPP TSG RAN WG1 Meeting #86 - Idle mode operation and initial access   

[14] 3GPP R1-167113 3GPP TSG RAN WG1 Meeting #86 - Link level evaluation for single-beam based and multi-beam based initial access   

[15] 3GPP R1-167114 3GPP TSG RAN WG1 Meeting #86 - Gradual UE-Specific (GUS) initial access and multi-beam-based mobility management   

[16] 3GPP R1-167115 3GPP TSG RAN WG1 Meeting #86 - Discussion on Beam Sweeping for Initial Access   

[17] 3GPP R1-167258 3GPP TSG RAN WG1 Meeting #86 - On System Design for Multiple Numerologies - Initial Access   

[18] 3GPP R1-167294 3GPP TSG RAN WG1 Meeting #86 - Basic Principles for Initial Access and Mobility   

[19] 3GPP R1-167333 3GPP TSG RAN WG1 Meeting #86 - Random access aspects for beam-based NR initial access   

[20] 3GPP R1-167379 3GPP TSG RAN WG1 Meeting #86 - Discussion on initial access and mobility for NR   

[21] 3GPP R1-167526 3GPP TSG RAN WG1 Meeting #86 - Considerations for Synchronization Signals Design in NR Beamformed Initial Access   

[22] 3GPP R1-167542 3GPP TSG RAN WG1 Meeting #86 - Discussion on initial access for NR   

[23] 3GPP R1-167574 3GPP TSG RAN WG1 Meeting #86 - On Beam-based Initial Access for NR    

[24] 3GPP R1-167673 3GPP TSG RAN WG1 Meeting #86 - Impact of multiplexing multiple numerologies on initial access   

[25] 3GPP R1-167704 3GPP TSG RAN WG1 Meeting #86 - On NR Initial Access and Mobility     

[26] 3GPP R1-167706 3GPP TSG RAN WG1 Meeting #86 - Simulation assumptions and scenarios for NR initial access    

[27] 3GPP R1-167840 3GPP TSG RAN WG1 Meeting #86 - Discussion on Beamforming Initial Access Operations    

[28] 3GPP R1-167912 3GPP TSG RAN WG1 Meeting #86 - Discussion on initial access and mobility for NR   

[29] 3GPP R1-168214 3GPP TSG RAN WG1 Meeting #86 - LS on initial accesss and mobility   

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

[31] 3GPP TR 38.802 V2.0.0 (2017-03) - Study on New Radio (NR) Access Technology; Physical Layer Aspects (Release 14)

[32] 3GPP TR 38.804 V1.0.0 (2017-03) - Study on New Radio Access Technology; Radio Interface Protocol Aspects (Release 14)

[33] 3GPP TR 38.801 V2.0.0 (2017-3) - Study on New Radio Access Technology;Radio Access Architecture and Interfaces (Release 14)

[34] 3GPP TR 38.803 V2.0.0 (2017-03) - Study on New Radio Access Technology; RF and co-existence aspects (Release 14)

[35] 3GPP R1-1801040 3GPP TSG-RAN WG1#NR - Summary of Remaining Details on RACH Procedure

[36] Understanding the 5G NR Physical Layer (Keysight)

[37] 3GPP R1-1805701 TSG-RAN WG1 92bis3GPP TSG-RAN WG1 92bis - Summary of Remaining Details on RACH Procedure  

[38] 3GPP R1-1801040 TSG-RAN WG1#NR1801 - Summary of Remaining Details on RACH Procedure

Reference- General Readings