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.

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.

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)