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 ). 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.
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.
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 ?
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)
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.
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-126.96.36.199.
<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.
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 188.8.131.52-5: Ncs for preamble formats with >
< 38.211-Table 184.108.40.206-6: Ncs for preamble formats with >
< 38.211-Table 220.127.116.11-7: Ncs for preamble formats with >
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 18.104.22.168-3: Mapping from PRACHRootSequenceIndex i to sequence number u for preamble formats with L_RA = 839 >
< 38.211-Table 22.214.171.124-4: Mapping from PRACHRootSequenceIndex i to sequence number u for preamble formats with L_RA = 139 >
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 126.96.36.199-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 188.8.131.52-2: Preamble formats for and where >
NOTE : Kappa is defined as 64 in 38.211-4.1 as below.
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.1.0-Table 184.108.40.206-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.1.0-Table 220.127.116.11-3: Random access configurations for FR1 and unpaired spectrum >