5G/NR - Initial Access/RACH                                           Home : www.sharetechnote.com

 

 

 

 

Initial Access 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.

 

 

 

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.

 

 

Two types of RACH : Contention Based and NonContention Based

 

This is also almost same as in LTE as described below.

 

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.

 

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" 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 Based' RACH Procedure is as follows :

 

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.

 

Typical 'Contention Free' RACH Procedure is as follows :

 

i) UE <--NW : RACH Preamble (PRACH) Assignment

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)

 

 

Fundamental Difference from LTE RACH

 

As I mentioned above, the overall protocol sequence would be almost same in LTE and NR. 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.

 

 

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

 

 

 

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

 

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

 

 

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

 

 

 

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.

 

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.

 

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

 

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.

 

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

 

NOTE : Kappa is defined as 64 in 38.211-4.1 as below.

 

 

 

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 v2.0.0 - Table 6.3.3.2-2: Random access configurations for FR1 and paired spectrum. >

 

 

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

 

Example 1 > PRACH Configuration Index = 0

    In this case, x is 2 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 2 = 1).

    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 = 14

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

    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.

 

 

 

RRC Parameters for RACH Process

 

Parameter (IE)

Description

Reference

prach-ConfigurationIndex

  38.321-5.1

prach-RootSequenceIndex

   

zeroCorrelationZoneConfig

   

restrictedSetConfig

   
PreambleInitialReceivedTargetPower    
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

   

msg2-SubcarrierSpacing

   

rach-ControlResourceSet

   

msg3-transformPrecoding

Msg3 Transform Precoding 38.213-8.3

msg3-SubcarrierSpacing

Msg3 Subcarrier Spacing 38.213-8.3
     
     

 

 

RACH-ConfigCommon ::=               SEQUENCE {

 

    groupBconfigured                SEQUENCE {

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

                                                    b1000, spare7, spare6, spare5, spare4, spare3,

                                                    spare2, spare1},

        messagePowerOffsetGroupB        ENUMERATED { minusinfinity, dB0, dB5, dB8, dB10, dB12,

                                                    dB15, dB18}

    } OPTIONAL,

 

    cbra-SSB-ResourceList               CBRA-SSB-ResourceList,

 

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

    ssb-Threshold                       TYPE_FFS!            OPTIONAL,

    sul-RSRP-Threshold                  FFS_Value            OPTIONAL,

    prach-ConfigurationIndex            INTEGER (0..255)     OPTIONAL,

    prach-RootSequenceIndex                 CHOICE {

        l839                                    INTEGER (0..837),

        l139                                    INTEGER (0..137}

    }                                                        OPTIONAL,

    zeroCorrelationZoneConfig               INTEGER(0..15),

    restrictedSetConfig                     ENUMERATED {unrestricted, restrictedToTypeA, restrictedToTypeB},

    preambleReceivedTargetPower             ENUMERATED {

                                                dBm-120, dBm-118, dBm-116, dBm-114, dBm-112,

                                                dBm-110, dBm-108, dBm-106, dBm-104, dBm-102,

                                                dBm-100, dBm-98, dBm-96, dBm-94,dBm-92, dBm-90,

                                                dBm-88, dBm-86, dBm-84, dBm-82, dBm-80, dBm-78,

                                                dBm-76, dBm-74, dBm-72, dBm-70, dBm-68, dBm-66,

                                                dBm-64, dBm-62, dBm-60, dBm-58, dBm-56, dBm-54,

                                                dBm-52, dBm-50, dBm-48, dBm-46, dBm-44, dBm-42,

                                                dBm-42, dBm-40, dBm-38, dBm-36, dBm-34, dBm-32,

                                                dBm-30, dBm-28, dBm-26, dBm-24, dBm-22, dBm-20,

                                                dBm-18, dBm-16, dBm-14, dBm-12, dBm-10, dBm-8,

                                                dBm-6,dBm-4, dBm-2, dBm-0, dBm2, dBm4, dBm6 }     

                                                OPTIONAL,

    powerRampingStep                        ENUMERATED {dB0, dB2, dB4, dB6}  OPTIONAL, -- Need R

    PreambleTransMax ::=                    ENUMERATED {n3, n4, n5, n6, n7, n8, n10, n20, n50,

                                                        n100, n200}

    ra-ResponseWindow                       TYPE_FFS!

    msg2-SubcarrierSpacing                  SubcarrierSpacing,

    rach-ControlResourceSet                 FFS_Value       OPTIONAL,

    msg3-SubcarrierSpacing                  SubcarrierSpacing,

    msg3-transformPrecoding                 ENUMERATED {true}    OPTIONAL, -- Need R

}

 

CBRA-SSB-ResourceList ::=       SEQUENCE (SIZE(1..maxRAssbResources)OF CBRA-SSB-Resource

CBRA-SSB-Resource ::=           SEQUENCE {

    ssb                             SSB-ID,

    startIndexRA-PreambleGroupA     PreambleStartIndex,

    numberofRA-PreamblesGroupA      NumberOfRA-Preambles,

    numberOfRA-Preambles            NumberOfRA-Preambles,

    ra-Resources                RA-Resources

}

 

PreambleStartIndex      ::= INTEGER (0..maxRA-PreambleIndex)

NumberofRA-Preambles    ::= INTEGER (1.. maxNrOfRA-PreamblesPerSSB)

 

 

SpCellConfig ::=                        SEQUENCE {

    reconfigurationWithSync             SEQUENCE {

        spCellConfigCommon                  ServingCellConfigCommon,

        newUE-Identity                      C-RNTI,

        t304                                ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000,

                                                        ms2000, ms10000-v1310},

        rach-ConfigDedicated                RACH-ConfigDedicated           OPTIONAL,   -- Need M

    }   OPTIONAL,   -- Cond SpCellChange

 

    spCellConfigDedicated               ServingCellConfigDedicated     OPTIONAL,   -- Need M

}

 

 

 

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

 

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

 

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 :

    RA-RNTI = 1 + s_id + 14 * t_id + 14 * X * f_id + 14 * X * Y * 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 < X)

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

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

       

 

 

Step (2) and (C) :

 

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

  • UE tries to detect a PDCCH (DCI) with the corresponding RA-RNTI within the period of RAR-Window.
  • 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.
  • This PDCCH and PDSCH should be carried in same subcarrier spacing and cyclic prefix as SIB1.

 

 

Step (3) :

 

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-Transform Precoding)
  • 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

 

 

Step (4) :

 

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

  • Start ra-ContentionResolutionTimer
  • Monitor to decode PDCCH with TC-RNTI
  • 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

 

 

 

Reference

 

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