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.

 

 

 

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

 

 

 

Two Types of Sequence : Short Sequence and Long Sequence

 

 

 

 

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

 

 

< 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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

 

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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

 

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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

 

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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

 

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

 

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

 

According to symbol location equation described above, the rach transmission symbol is calculated as follows.

 

 

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

 

 

 

 

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 >

 

 

 

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. (NOTE : Regarding 'Restricted sets', refer to zeroCorrelationZoneConfig and Ncs)

 

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

 

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

 

 

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

 

 

 

 

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 >

 

 

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

 

 

 

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 v15.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, spare7, 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,   -- Need R

    prach-RootSequenceIndex                 CHOICE {

        l839                                    INTEGER (0..837),

        l139                                    INTEGER (0..137)

    },

    msg1-SubcarrierSpacing                  SubcarrierSpacing,

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

    ...

}

 

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 (-200..-74),

    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}

}

 

 

RACH-ConfigDedicated ::= SEQUENCE {

    cfra                             CFRA OPTIONAL,

    ra-Prioritization                RA-Prioritization OPTIONAL,

    ...

}

 

CFRA ::= SEQUENCE {

    occasions SEQUENCE {

        rach-ConfigGeneric               RACH-ConfigGeneric,

        ssb-perRACH-Occasion             ENUMERATED {

                                           oneEighth, oneFourth, oneHalf, one, two, four,

                                           eight, sixteen

                                         } OPTIONAL -- Cond SSB-CFRA

    } 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-v1530 INTEGER (1..63)        OPTIONAL -- Cond Occasions

    ]]

}

 

 

CFRA-SSB-Resource ::= SEQUENCE {

    ssb                   SSB-Index,

    ra-PreambleIndex      INTEGER (0..63),

...

}

 

 

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

    ...

}

 

 

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 : Regarding the details of Timing Advance File, refer to Timing Advance Page

 

 

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

 

 

 

 

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 transmission when 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 of the newUE-Identity as the C-RNTI for this cell group;

 

 

 

 

 

< 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

 

 

 

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)

[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