LTE terminal must perform certain steps before it can receive or transmit data. These steps can be categorized in cell search and cell selection, derivation of system information, and random access. The complete procedure is known as LTE Initial Access
Successful execution of the cell search and selection procedure as well as acquiring initial system information is essential for the UE before taking further steps to communicate with the network. For this reason, it is important to take a closer look at this fundamental physical layer procedure.
but I strongly recommend you to try to have some big picture of the whole process. Whenever you have some issues or something for you to work, try to ask your self "Where is the current issue located in the whole picture ?".
Step A: Initial synchronization:
Step A-1: Primary Synchronization Signal
The UE first looks for the primary synchronization signal (PSS) which is transmitted in the last OFDM symbol of the first time slot of the first subframe (subframe 0) in a radio frame. This enables the UE to acquire the slot boundary independently from the chosen cyclic prefix selected for this cell. Based on the downlink frame structure (Type 1, FDD), which is shown in Figure 6, the primary synchronization signal is transmitted twice per radio frame, so it is repeated in subframe 5 (in time slot 11). This enables the UE to get time synchronized on a 5 ms basis, which was selected to simplify the required inter-frequency and inter-RAT measurements.
Query_1: How does UE know to look for the PSS synchronization signal?
Well, UE doesn't need to worry much for this. As, the synchronization signal are always sent only on the center 62 sub carriers irrespective of the channel bandwidth (1.25,3,5,10,20). Therefore, UE will look for the central sub carriers, i.e at the last OFDM symbol of the 1st time slot and again at the last OFDM symbol of the 11th slot. With this UE synchronizes at the slot level.
Step A-2: Secondary Synchronization Signal
After the mobile has found the 5 ms timing, the second step is to obtain the radio frame timing and the cells’ group identity. This information can be found from the SSS. In the xtime domain, the SSS is transmitted in the symbol before the PSS . The SSS also has 5 ms periodicity, which means it is transmitted in the first and sixth subframes (subframes 0 and 5).
Query_2: How does UE know to look for the SSS synchronization signal?
Once, when the PSS is identified, SSS is always send at the slot before the PSS is present. In other words, SSS immediately precedes the PSS.
Let's see how the UE derives the Cell ID using these two signals:
From PSS: PHYSICAL LAYER CELL IDENTITY is derived. It carries the value of 0, 1 and 2.
From SSS: PHYSICAL LAYER CELL IDENTITY GROUP is derived. It can take the value to 0 to 167.
Formula:
Cell ID= (3*PHYSICAL LAYER CELL IDENTITY GROUP) + PHYSICAL LAYER CELL IDENTITY
Step A-3: Downlink Reference Signal
The UE is thus able to become fully synchronized with the radio cell because the reference signals are transmitted in well-defined resource elements. In every sixth subcarrier in the frequency domain a reference symbol from the generated reference signal pattern is transmitted. In the time domain, every fourth OFDM symbol transmits a reference symbol . A resource block contains four reference symbols.
Step B: Broadcast of essential system information
Step B-4: Master information block
From the MIB, UE gets the following information:
- Channel bandwidth in terms of Resource Blocks
- SFN (System Frame Number)
- PHICH configuration (used for HARQ ACK/NACK)
Query_3: How does the UE read MIB?
- The MIB is transmitted on physical channel (BCCH-BCH-PBCH) and it always occupies the central 72 sub carriers in the Frequency domain irrespective of the channel bandwidth.
- The first transmission of the MIB is scheduled in sub-frame number 0 of radio frames for which the SFN mod 4 = 0
- repetitions are scheduled in sub-frame 0 of all other radio frames
Step B-5: SiB1
i) Cell Access Related Information - PLMN Identity List, PLMN Identity, TA Code, Cell identity & Cell Status
ii) Cell Selection Information - Minimum Receiver Level
iii) Scheduling Information - SI message type & Periodicity, SIB mapping Info, SI Window length
Step B-6:SiB2
i) Access Barring Information - Access Probability factor, Access Class Baring List, Access Class Baring Time
ii) Semi static Common Channel Configuration - Random Access Parameter, PRACH Configuration
iii) UL frequency Information - UL EARFCN, UL Bandwidth, additional emmission
After the above process the UE is synchronized with the network in the Downlink direction and have read SIB1 and SIB 2. Now, it needs to synchronize in the Uplink direction.
The UE cannot start utilizing the services of the network immediately after downlink synchronization unless it is synchronized in the uplink direction too.
Now, RAP (Random Access Procedure) is initiated
There are two types of RAP:
- Contention based RAP
- Non-contention based RAP
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
Typical 'Contention Free' RACH Procedure is as follows :
i) UE <--NW : RACH Preamble 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)
Contention based RAP
In contention based, multiple UE's attempt to connect to the network at the same time. The eNB is intelligent enough to tackle this situation because every UE should be unique to the network.
The UE's can always send the same Preamble ID to the network, thereby resulting on collisions. This kind of collision is called "Contention" and is known as "Contention based" RACH Process. The network would go through additional process to resolve these contention and hence this process is called "Contention Resolution" step.
Step 1: In the first message the UE provides an indication to the network about it's resource requirement. This carries the Preamble ID, RA-RNTI
Query_4: How does UE gets or selects these parameters:
a. Most of the information is passed on to the UE through SIB2 (click here, to know more about SIB2 parameters) i. UE MAC layer has to select the Preamble sequence (Group A or Group B)
ii. UE will configure itself with the max retires it will try for sending RAP (if it doesn't receive RAR)
iii. Also, after every retry, how much power level has to be increased for transmitting the RAP
iv. UE MAC layer constructs the RAP message and passes it to the UE PHY layer. UE PHY layer will transmit this message through PRACH
v. Once the UE has transmiited the RAP on PRACH, it will start looking for RAR immediately after 3 sub-frames. This number i.e. 3 sub-frame is specified by 3GPP.
Query_5: How long should UE monitor the frames for RAR?
This sub-frame number is again specified in SIB2 and is known as window length; so, after the 3 sub-frames as mentioned above, UE will start looking for RAR in the sub-frames as mentioned by the Window length. If by that time UE doesn't receive RAR, it will go back to transmit RAP
Step 2. The eNB conveys the resources reserved for this UE along with the Timing Advance (TA), Preamble ID and T-CRNTI (a number generated by eNB and asks the UE to send the RRC connection)
Step 3. UE sends the RRC connection Request using resources given by the eNB. It also sends the identifier (CRI) to the eNB which is used to resolve the Contention.
Step 4. The eNB runs an algorithm and generates C-RNTI which will be a permanent ID for the UE till the connection is alive. The eNB sends the UE identifier. In this step, the UE which has received the ID continues while other UE's will back off and try again.
Scenario:
Multiple UE's attempt to access the network:
1. So, the UEs initiates RACH with same Preamble sequence, RA-RNTI
2. Therefore, the UEs will receive the same T-C-RNTI and resource allocation from eNB
3. All UEs would send msg 3 (RRCconnectionRequest) message through the same resource allocation to the Network
4. Once, when msg3 is transmitted, two Timers are started:
a. T300 : Transmission of RRCconnectionRequest
b. Contention Resolution Timer: broadcasted in SIB2. If the UE doesn't receive msg4 (Contention Resolution message) within this timer, then it go back to Step 1 i.e. transmitting RAP. If there is a HARQ NACK for msg3 (RRCconnectionRequest) and it has to be re-transmitted then this Contention Resolution Timer will be re-started
Query_6: Now the big question: How should the eNB behave?
1. One: The signals act as interference to each other and eNB decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from eNB and all UE will go back to Step 1.
2. Second: The eNB would successfully decode the message from only one UE and fail to decode from others. The decoded UE will get HARQ ACK from eNB
3. Third: eNB receives msg3 (RRCconnectionRequest) from both the UE's. Here, eNB will send msg4 (Contention Resolution) with MAC CRI (Contention Resolution Identity) to both the UE's. This CRI will carry a reflection of the RRCconnectionRequest as generated by one of the UE. The MAC layer of the UE will match the CRI (as received from msg4) with the CRI embedded in the RRCconnectionRequest. If it matches, then the UE will proceed to decode RRCconnectionSetup and the other UE's will back off and return to Step1, i.e start the RA procedure again.
Contention Resolution process is again of two types:
1. MAC based Contention Resolution
=> C-RNTI on PDCCH
=> uses the DCCH logical channel
=> used in HO scenarios
==>The rule is: if the UE has a valid C-RNTI and is going for RA procedure then it will be a MAC based Contention Resolution procedure
2. L1 based Contention Resolution
=> CRI (Contention Resolution Identity) on DL-SCH based
=> Contention Resolution is addressed to T-CRNTI
=> uses CCCH logical channel
==>The rule is: if the UE doesn't has a valid C-RNTI and is going for RA procedure then it will be L1 based Contention Resolution procedure
Query_6: Exactly when and Where a UE transmit RACH ?
you need to refer to 3GPP specification TS36.211 - Table 5.7.1-2.
Did you open the specification now ? It shows exactly when a UE is supposed to send RACH depending on a parameter called "PRACH Configuration Index".
For example, if the UE is using "PRACH Configuration Idex 0", it should transmit the RACH only in EVEN number SFN(System Frame Number). Is this good enough answer ? Does this mean that this UE can transmit the RACH in any time within the specified the SFN ? The answer to this question is in "Sub Frame Number" colulmn of the table. It says "1" for "PRACH Configuration Idex 0". It means the UE is allowed to transmit RACH only at sub frame number 1 of every even SFN.
Query_7: How does Network knows exactly when UE will transmit the RACH ?
It is simple. Network knows when UE will send the RACH even before UE sends it because Network tells UE when the UE is supposed to transmit the RACH. (If UE fails to decode properly the network information about the RACH, Network will fail to detect it even though UE sends RACH).
Following section will describe network informaton on RACH.
Which RRC Message contains RACH Configuration ?
It is in SIB2 and you can find the details in 3GPP 36.331.
Query_8:Exactly when and where Network transmit RACH Response
We all knows that Network should transmit RACH Response after it recieved RACH Preamble from UE, but do we know exactly when, in exactly which subframe, the network should transmit the RACH Response ? The following is what 3GPP 36.321 (section 5.1.4) describes.
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes.
It means the earliest time when the network can transmit the RACH response is 3 subframe later from the end of RACH Preamble. Then what is the latest time when the network can transmit it ? It is determined by ra-ResponseWindowSize. This window size can be the number between 0 and 10 in the unit of subframes. This means that the maximum time difference between the end of RACH preamble and RACH Response is only 12 subframes (12 ms) which is pretty tight timing requirement.
Query_9: Why/when UE send another PRACH? / When/How soon do I have to send the next PRACH?
Backoff Indicator provide the answer to this question.
Backoff Indicator is a special MAC subheader that carries the parameter indicating the time delay between a PRACH and the next PRACH. (As per 36.321). For example, if the BI field value is 10, Backoff Parameter value is 320 ms. This means UE can send PRACH any time in between 0 and 320 ms from now.
you would notice that BI (Backoff Indicator) field is made up of 4 bits, implying that it can carry the value from 0~15.
BI subheader should always be at the beginning of the whole MAC header. If you see more carefully, you would notice that BI subheader is shown with 'dotted' rectangle. It means that this is optional, implying that the network send or does not send BI depending on the situation.
If you see even more carefully, you would notice that BI subheader does not have any corresponding payload part. It means "Backoff Indicator" information is carried directly by the MAC header/subheader and it doesn't use any payload field.
Reference:http://lteexpert.blogspot.com/2014/09/basic-lte-call-flow.html?m=1
