What is the use of Rank Indication in LTE

The eNodeB configures the RI reporting periodicity for every UE during the attach procedure and UE has to honour it. The RI reporting periodicity can overlap with CQI reporting periodicity in which case the UE will drop CQI and report RI.

Now coming to the RI itself, the contents of RI is just a couple of bits. The number depends on antenna configuration. If the eNodeB is configured with 2 transmit antennas on downlink then the number of bits reported in RI will be one and if its 4 then number of RI bits will be 2.

Lets consider the two antenna case where RI is indicated using one bit, so a bit 0 indicates RANK1 and a bit 1 indicates RANK2. RANK1 means the UE is seeing a good SINR only on one of its receive antenna so asking the eNodeB to bring down the transmission mode to single antenna or transmit diversity. A RANK2 from the UE means good SINR on both the antenna ports and eNodeB can schedule MIMO.

Its very essential for the eNodeB to decode a UEs RI report to know the channel conditions so that it can schedule downlink appropriately. The LTE specifications also say that if the UE is not reporting any RI then the eNodeB should assume RANK1.

Reference:https://ltebasics.wordpress.com/2014/09/21/use-of-rank-indication-in-lte/

Basic LTE call flow

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

How the UE goes out of sync in LTE?

The full procedure for determining if the link has failed due to being out of sync is shown in the figure below. There are 3 main parameters/timers involved:

n310: This parameter indicates the number of 200 ms intervals when the UE is unable to successfully decode the PDCCH due to low RSRP detected. That is, this parameter indicates the number of times in which the UE cannot successfully decode 20 consecutive frames in the downlink.

t310: It is a timer, in seconds, used to allow the UE to get back in synchronization with the eNodeB.

n311: This parameter indicates the number of 100 ms intervals that the UE must successfully decode the PDCCH to be back in-synch with the eNodeB. That is, this parameter indicates the number of times in which the UE must successfully decode 10 consecutive frames in the downlink in order for the UE to assume the radio link is in-synch.

If the UE detects n310 consecutive out-of-sync indications, it starts the t310 timer. If the timer expires, the link has failed. If the UE detects n311 consecutive in-sync indications prior to the t310 timer expiring, then the timer is stopped and the link has will not fail. 

RACH Preamble and Root Sequence Planning

The total number of RACH preambles available in LTE is 64. These preambles are shared among users for initial access and handover. Access to LTE systems can be classified based on the reservation or not of preambles for access. When users have a reserved signature to access the system, they are said to be using Contention Free Random Access (CFRA). On the contrary, when users don't have a reserved signature for access they are said to use Contention Based Random Access. CFRA is typically used during handover and  at the arrival of DL data. 

The 64 preambles are not implicitly communicated to the UEs by the eNodeB but rather, the UE is informed about the process of how to generate them via parameters broadcast in SIB2. These parameters are:
a)     RootConfigurationIndex
In LTE, there are 838 root Zadoff-Chu sequences available for preambles. The length of each root sequence is 839. RootConfigurationIndex, informs the UE via SIB2 which sequence is to be used.
b)    ZeroCorrelationZoneConfig.
One root sequence can generate several preambles by cyclic shift. One or more root sequences are needed to generate all preambles in a cell. The UE starts with the broadcasted root index and applies cyclic shifts to generate preambles. ZeroCorrelationZoneConfig points to a table where the cyclic shift is obtained from.
The smaller the cyclic shift, the more preambles can be generated from a root sequence. Hence, the number of sequences needed to generate the 64 preambles in a given cell is:
                        # of rows = ceiling (64 / (integer (sequence length/cyclic shift)))
For example, if the rootsequence index is 300 and the cyclic shift is 119, then, the number of rows needed to generate the 64 preambles in a cell is:
# of rows = ceiling(64 /(integer(839/119))) = 10
This means, that if we allocated rootsequenceindex 300 to cell X, then cell Y must have rootsequenceindex 310 and cell Z must have rootsequenceindex 320 to avoid root sequence conflict which might affect the RACH success rate of the cell.
Below is the mapping between NCS & Cell radius

Reference:http://lteuniversity.com/get_trained/expert_opinion1/b/lauroortigoza/archive/2011/10/20/rach-preamble-planning.aspx