MAC

MAC(Media Access Control)

What is the main job of MAC layer -  

1) Multiplexing

2) Acquiring the resources from the e-NB. 

If we see the architecture of layer, there is transport channel in between MAC and PHY layer.

There are 5 transport channels-

1)Broadcast channel (BCH) – Is for system information

2)Paging channel (PCH) – Is for paging information

3)Downlink Share Channel (DL-SCH) – Is carrying the data in downlink.

4)Uplink Share Channel (UL-SCH) – Is carrying the data in uplink.

5)Random Access Channel (RACH)- For preamble

Downlink Transport Channels:

Downlink means e-NB to UE. E-NB MAC will produce the transport channels.

BCH- Broadcasting information (SIBs, MIB)

PCH- Paging information

DL-SCH - Carrying actual data in downlink but twist is all these three transport channel is send to mobile equipment by using a single physical channel PDSCH to carry any of the data but how to separate these information whether the data belongs to BCH or PCH or DL-SCH etc. through RNTI (Like SI-RNTI, P-RNTI, C-RNTI etc).

Uplink Transport Channels: 

Uplink means UE to e-NB. UE  MAC will produce the transport channels.

UL-SCH- Carrying actual data in uplink and this will be send on physical channel PUSCH.

RACH- RACH is used for sending the preamble on special physical channel PRACH. In PRACH some symbols are reserved to the preamble  whenever is asked for resources then we will send the preamble.

Logical Channels :

There are different type of logical channels in LTE. On what basis different types of logical channel ?? Based on the type of  information we have decided-

BCCH ------à Carries Broadcasting information

PCCH ------à Carries paging information

CCCH ------à Carries RRC information before RRC connection

DCCH -----à  Carries RRC information after RRC connection

DTCH -----à  Carries user data ( belong to application)

BCCH ,PCCH and CCCH are called standard common logical channels. Specialty of these  common logical channels is they standard and unchanged the configuration. The meaning is, for these logical channels what are the headers RLC should used that is unchanged/fixed.
BCCH, PCCH both are down link only but CCCH one is uplink and one is downlink.

DCCH, DTCH  are called dedicated logical channels. Specialty of these logical channels is PDCP,
RLC , MAC configuration are dynamic. But the configuration of these layer is known only after establishment of RRC connection.
Why dynamic configuration is chosen for DCCH and DTCH ? Because we want to optimized the resource utilization. 
There can be two DCCH in LTE. One is two DCCH in uplink and one is two DCCH in downlink.
Why two DCCH ? In LTE what is the information that is carried  in DCCH information produced after RRC connection ? Specialty of these two channels is total RRC messages is divided in to two message. Half of the messages will be send on one DCCH channel and another half of the messages will be send on another DCCH channel. Because some of the RRC messages comes under high priority category and some of the RRC messages comes under low priority category. 
So, if the information is available at same time, then MAC will pull the data from high priority channel not from low priority channel. 
There can be many DCCH channels because it is possible to open the many application if we want.

Pure Physical Channels (Downlink/Uplink):

Pure physical channel means not associate transport channels or not linked with MAC layer. It is Used only for physical layer operation and no data would be present.

Downlink-

PSS,SSS- It is used for synchronization purpose.

PDCCH- In this channel the information comes from e-NB to mobile equipment about which resources are allocated to RNTI.

Resource allocation information is depend based on RNTI.

PCFICH- It is used for how many symbols are reserved for PDCCH/ Knowing PDCCH symbols reserved.

Uplink-                           

PUCCH- It is used for sending HARQ(ACK/NACK), SR and CQI report.

Channel Mapping :  

Dedicated Control Information -
Signalling - RRC connection setup Complete 
While sending "RRC connection setup complete" UE should configure dedicated channel, to do this RRC inform to every layer like how to work, what is the header field size etc  everything has to configure based on what configuration received from e-NB in RRC setup message. This DCCH information has pass form below layers . So from now onwards any RRC messages that is from UE to e-NB or e-NB to UE, DCCH should be used.

Data:
Application layer will produce the data. From application layer the data comes to PDCP , then PDCP will give it to RLC, RLC give it to MAC through DTCH ,then MAC will put in to UL-SCH and send it to Physical layer. 
Now the same story will be down link case as well but only the difference is in down link application wont be there at e-NB side.

Note:
We are making RRC connection for two purpose-
1. Acquiring the resources from e-NB.
2. Connection establishment with e-NB. Means to get the configuration of DCCH and DTCH.



MAC layer produced 5 transport channels BCH, PCH, RACH, DL-SCH and UL-SCH.
There is no header for BCH and PCH. Means transparent MAC workout for BCH and PCH.
RACH is used for sending preamble. 
For UL-SCH and DL-SCH we should definitely have MAC header because different information which travel in these two channel. On UL-SCH/DL-SCH information can be travel on CCCH, DCCH  and DTCH .DL-SCH sometimes may contain broadcasting and paging information.
Once the data is received we need to identify this data belongs to CCCH /DCCH / or DTCH . 
But the information will be separated by physical layer with the help of RNTI.

MAC SUB-Header-
Sub means small part of the full headers.

We used one one MAC sub header for one one logical channel information. Actually MAC can make multiple logical channel information put together. For each logical channel information we used one sub-header.

The duty of MAC layer is to multiplex different logical channel data in to one transport channel.

While multiplexing we keep each an every logical channel information in to sub header such that on other side we can do de-multiplexing.

MAC specific point of view this one logical channel information can actually called one sub header.

So how many sub header we have that depend on the how many logical channel information we have.

MAC sub header is used for DATA as well as MAC control information.

MAC will do two task- 

1.  MAC is actually send the data with the help of multiplexing that belongs to higher layer. 

2. Acquiring the resources with the help of BSR(Buffer Status Report).

MAC layer having two information -
1. One is DATA and
2. Other one is MAC control information.
What is the meaning of DATA and MAC control information ?
For uplink how much information we have in the buffer that need to report to the e-NB. This is called Buffer Status Report(BSR). MAC layer generates the BSR. So this BSR we actually called MAC control information. Control means MAC own information.
DATA means that belongs to higher layer. That means any thing coming from higher layer is called DATA.

But the advantage of MAC layer is we can send both the things together. Means simultaneously MAC can send both control and data information. But receiving guy should understand that there is some control and data information are present inside it. But how receiving guy understand this ?
He can understand with the help of headers.

DATA Header-

Control Header-

For MAC control sub header length field is absent because MAC control information has fixed size but for data purpose we need length field which explain how much amount of data we have.

R-  Stands for Reserved bit for future. It is set to "0".
E- The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set to "1" to indicate another set of at least R/R/E/LCID fields. The E field is set to "0" means no sub header is there.
LCID-  It indicating that in which logical channel the data belongs to.

F(Flag)- F bit explain that what is the length field size. Length field are 7 bits and 15 bits.
                    If F is set to '1' then length bits is 15 . If F is set to '0' then length is 7 bits only. But how 
                    can we decide F bit either 1 or 0 ? If the data is less than 127 bytes then we put F=0.
                    If the data more than 127 bytes then we put F=1. Data means logical channel 
                    information.
                      


Example of the data header -

In LTE the maximum number of logical channel is 10.

Assume that RLC1 has got 10,000 bytes, RLC2 has got 500 bytes, RLC3 has got 2400 bytes and RLC4 has got 6000 bytes. All these data  is produced by application layer. It has comes from application layer, PDCP has compressed  it. After compression the data is 10,000 bytes, 500 bytes, 2400 bytes and 6000 bytes. Each logical channel has priority. MAC layer will send the data on the basis of TTI (Transmission of Time Interval) that is 1ms. In 1ms how much data we can send out that will be dependent on how much PRB we acquired.

Assume that we acquired n number of PRB with that we can send x number of data every time.

MAC 1st TTI :

First time- MAC has pull the data 2500 bytes. But from where MAC pull the data ?

                   MAC pull the data on the basis of priority. So he pull the data one from RLC3 (2400 bytes)
                   and another from RLC2 (100 bytes).

MAC 2nd  TTI

Second time- MAC has pull the data 7500 bytes.
                        Here, based on priority MAC pull the remaining data from RLC2, then from RLC4 and at last from RLC1.   

This way MAC is multiplexing with the help of sub headers. Each sub-header explain about last piece of data.

NOTE:
when the sub-header contains F/L bits we can understand that this belongs to data. Because length field is only present for Data but when F/L is not present only R/R/E/LCID is present we can easily understand this sub-header is for control field. 

MAC control information(CE):

Proper logical channel id is only from 1 to 10 , these  are commonly used for data. From 11 onwards if we are using logical channel id , those logical channel represent as control elements. Actually it represent that it is the special control elements.

LTE Advanced - MAC CE

For more details. Please refer to here

MAC Complete Packet :

Size of control header is always fixed because we no need to have length field.

How we attach control element  with data / How MAC can send both control and data element ?

Initially we have to complete the RACH procedure. Once RACH is done we have some uplink resource. With this resource we send the BSR(Buffer Status Report). Here we made 4 Groups. In LTE there are 4 logical channel groups. Basically logical channel groups are decided on the basis of priority(QCI).

Generally BSR is a kind of MAC control element from UE to network carrying the information on how much data is in UE buffer to be send out. There are several types of BSR. So the next duty is to send the BSR.

For example:

Long BSR:
Long BSR we need to have information for the 4 logical channel groups.

If suddenly data come in logical channel  RLC3 whose priority 1. Now we have to send short BSR along with data.

If we send the data for single logical channel group then it is called short BSR.
.

Assume that RLC3 having 12075 byte of data and MAC will send 7500 bytes of data along with short BSR. 

In this TTI, MAC is sending 7500 bytes of data along with short BSR. So MAC will send 1 control element(short BSR) along with

3 data streams.

MAC control elements:

1. UE Contention Resolution Identity: 

UE contention resolution is the part of RACH. Common control logical channel is obviously related part of RACH but it is not a straightway related. This control element has a fixed 48-bit size and consists of a single field. 

There are two types of RACH procedure -1. Contention based RACH procedure,  2. Non contention based RACH procedure.

When collision is not there the procedure is simple. If multiple UE are transmitting a preamble but if they are using the different preamble then collision will not happen. But when they are transmitting at the same time by using same RA-RNTI along with the same preamble picked up out of 64 preamble then definitely we are going to face the collision situation.

How we will overcome this collision situation ? 

The simple solution is contention based RACH procedure. But how it will works?

-First UE  send a preamble by using PRACH channel.

-Second along with the UE  some other UE also send a preamble at the same time in order to request for uplink resources. Both the UE sends the same preamble at the same time. Now e-NB received both the preambles but he must be accepting only one. But he will not be able to differentiate between two preambles because both of them used same preamble. So in response e-NB replied both of them and both are think this is for my preamble resource. But how it can be solved ?     

Here we have to talk about uplink time synchronization called as Timing Advance Command. 

Assume that this is a cell( above figure) and UE1 having near to e-NB than UE2.

[ In case of downlink there won’t be any problem because e-NB itself transmitting and mobile is receiving. He do not care when they received but in case of uplink there is a problem.]

Normally resource will be given 1ms (TTI) of time by the e-NB. Whichever 1ms is given we need to use only that 1ms .If we are below that or it is delayed that occurs the collision with the other signal.

Assume that only two user are there where at 10ms to 11ms UE2 transmit and UE1 transmit at 11ms to 12ms. When UE2 is transmit that is at 10ms and this signal is received by e-NB by some delay. Assume that 0.25ms delay. That means at 11.25ms

e-NB has received the signal from UE2.But if e-NB tell to UE1 now you transmit the signal at 11ms. So what happened if UE1 transmit the signal at 11ms. So definitely both the signal are collide. Actually this is not the correct transmission from the user point of view. So what need to be done here ?. For the users those who is far way of the e-NB, he will start the transmission some little bit earlier such that exactly by the time when other user also has to finish it.      

So e-NB tells to UE2 that don’t start the transmission at 10ms,start the transmission at 9.75ms.

Because there is a delay of 0.25ms. So UE2 has finished the transmission at 11ms and there won’t be any collision with UE1. 
But the users who are different distance time delay will be different. So the adjustment should be according to the time delay of the particular user at the starting time when he sending the preamble and in response e-NB tells timing advance command for the user.   

The speed of the Radio signal is 3*10^-8. We can not change the speed of the Radio signal because it is the property of electromagnetic wave. So the users who is far way and who is near of the e-NB, they can not start the transmission at the same time. They should be some kind of advance mechanism for the user who is far way of the cell. So e-NB can estimate it and he will tell to user to start the transmission in advance.

The timing advance is a continuous command that e-NB sends to users .Once the user is getting timing advance command that is not enough because users moving continuously. So e-NB must be adjusting every time.

In Random Access Response (RAR) message user has receives the timing advance command.  

MAC PDU (Random Access Response) :
A MAC PDU consists of a MAC header and zero or more MAC Random Access Responses (MAC RAR) and optionally padding.

The MAC header is of variable size. A MAC PDU header consists of one or more MAC PDU sub-headers and each sub-header corresponding to a MAC RAR except for the Back-off Indicator sub-header.

A MAC PDU sub-header consists of the three header fields E/T/RAPID    

But for the Back-off Indicator sub-header which consists of the five header field E/T/R/R/BI .

A MAC RAR consists of the four fields R/Timing Advance Command/UL Grant/Temporary C-RNTI .

Padding may occur after the last MAC RAR. Presence and length of padding is implicit based on TB size, size of MAC header and number of RARs. 

Example of MAC PDU consisting of a MAC header and MAC RARs :

Once connection is made and if we get a timing advance command then the value of the TAC is 6 bits.

Why this timing advance command is linked with preamble ?

If the two user have sent same preamble at the same time with same RA-RNTI, when e-NB getting the preamble at the same time, he will send a preamble response basically Random Access Response. But when he sending a RA response definitely includes Timing Advance Command but same preamble response for two user. Both are think this thing is only for them and they decided to send the RRC connection request message to the e-NB by using uplink grant. If two user are sending this message by using same PRB ,e-NB getting both. Now both the user will start the Contention Resolution Timer. Within this timer e-NB has to confirm to both the user that he received the message properly. Now whose’s message e-NB will consider ? Whose transmission comes in the correct timing advance. e-NB will issue only one timing advance message out of this two message whose timing advance is correctly matches with the issued timing advance command that is in RA response. So e-NB sends UE Contention Resolution Identity to both the user in PDSCH by using T-CRNTI. When both the user are going to read  this information the guy whose timing advance is correctly matched he will get the information.

There are two information present in UE Contention Resolution Identity . One is 40 bit random number and other is S-RNTI.                     

When UE get the 40 bit random number and when get the S-RNTI  from the e-NB.

Initially at the starting time when UE going to latch with the network. That time e-NB will assign the same 40 bit random number in UE Contention Resolution Identity when UE have sent 40 bit RAND in 'RRC connection request'.

But if UE is in idle mode and then if he going to connect with the e-NB , that time e-NB will assign the same S-RNTI in UE Contention Resolution Identity when UE have sent S-RNTI in 'RRC connection request'. Actually this S-RNTI MME is assigned to UE at the time of attached with the network in ‘initial context setup request’ message.

What is the purpose of RACH procedure ?
The main purpose of RACH procedure is as follows-

1. Achieve uplink synchronization between UE and e-NB

2. Obtain the resource for Message 3 (e.g, RRC Connection Request)

When RACH Process occurs ?

RACH process happens in following situation

A) Initial access from RRC idle state

UE is trying to access the network in RRC idle state (Contention Base)

B) RACH Procedure on RRC Connection Re-establishment when Out-of-Sync (Non-Contention Base).

C) RACH Procedure on Handover - NonContention Base.

D) UL data arrival during RRC_CONNECTED requiring random access procedure

For example: when UL synchronisation status is "non-synchronised" or there are no PUCCH resources for SR available.

E) When timing advance is needed for positioning purpose in RRC connected state for UE (Non-Contention Base).

Two types of RACH process :

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.

Contention-based :

UE can select "Randomly" one of these preambles. Also there is such possibility that same PRACH preamble from multiple 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 (Explained before).
In contention based, preambles are resurved from 0 to 51. 

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

Contention-free/Non contention-based:

But in this case, due to some reason (e.g, timing restriction) 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 a dedicated 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.
In Non-contention based, dedicated preambles are resurved from 52 to 63. 

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)

PRACH Parameters :

a) prach-ConfigIndex-
This parameter determines what type of preamble format should be used and at which system frame and sub-frame that UE can transmit PRACH Preamble.That means this parameter defines exactly when UE should send RACH in frequency/time grids.  

This  below table would give us at which frame and sub-frame that UE is allowed to transmit a PRACH Preamble.

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 Index 0", UE should transmit the RACH only in EVEN number SFN(System Frame Number).

If the UE is using "PRACH Configuration Index 5“,  UE is allowed to transmit RACH any time only at sub frame number 7.

Which "PRACH Configuration Index", it would be the easiest for the Network to detect the RACH from UE ? and Why ?

The answer would be 14, because UE can send the RACH in any SFN and any slots within the frame.

Preamble Format :

If we see on below table that the length of PRACH preamble varies depending on the preamble format. 

For example, the length of PRACH with preamble format 0 is (3186 + 24567) Samples.

"Why we need various PRACH format with different length in time ?".

The Cyclic Prefix (CP) and Guard Time (GT) are used to avoid interference with the previous and next sub-frames. As it turns out, the GT determines the maximum cell radius.

If we see the radio frame structure, one sample Ts = 1/30.72 = 0.03255 us.
It is defined as 1/(15000 * 2048) seconds =0.03255 us where channel spacing b/w two subcarrier=15 khz and Total radio frame= 2048
If we convert from us to ms , 

Tcp = (Tcp * 0.03255 * 1/1000 ) ms
T seq= ( Tseq * 0.03255 * 1/1000 ) ms

Guard Time (GT) = Total number of sub-frame – Tcp – Tseq 
PRACH Format = Tcp + Tseq.
Cell Radius = Speed of light (C) * Round Trip Delay (GT) /2
                     =3X10 ^-8 * GT/2

Let’s discuss only format 0,1,2,3.

T_SEQ (length of Sequence). We see format 0 and format 1 is made up of single copies of PRACH converted in time domain. Format 2 and 3 is made up of two copies of PRACH sequence concatenated. What would be the advantage that format 2,3 have over format 1,2. Because longer T_SEQ would help decoding PRACH under noised condition because it provide longer correlation window to detect PRACH.

For T_CP part we would notice format 1 and 3 has much longer T_CP comparing to format 0 and 2. Longer CP would give you better tolerance in fading environment and reducing ISI (inter symbol interference) even in highly fading environment.

Just as a brief conclusion for cell size, we can rewrite the table as follows:

'Who determines PRACH Configuration index ?'.

The answer is 'e-NB determines it via prach-Configindex IE in SIB2.

Please refer to prach-ConfigIndex section for the details.

b) RootSequenceIndex, ZeroCorrelationZoneConfig and Highspeed flag :

ZeroCorrelationZoneConfig and Highspeedflg IE is to specify the cyclic shift intervals to generate 64 PRACH Sequence from a single base sequence. These IE(information elements) are specified in SIB2 as in the example below.

If we apply the values in the example above, we would get the Ncs value of 26. (Pick the number at the cross of column 'Unrestricted Set (HighSpeedFlag = False) and the row of Ncs 5).

Highspeed flag:

All the preamble sequences should be orthogonal to each other. Otherwise, various preambles from multiple UEs within the same cell can interfere each other. So we have to shift the generated sequence by a specifically designed value and this value is called Cv (Cyclic Shift Value) and it is defined as follows.

We use different process to calculate Cv depending on whether we use 'unrestricted sets' or 'restricted sets'. This decision is made by 'Highspeedflag' information elements in SIB2. If Highspeedflag is set to be TRUE, we have to use 'restricted sets' and if Highspeedflag is false, we have to use 'unrestricted sets'.

RootSequenceIndex:

There are 838 root Zadoff-Chu sequences available for preambles. The length of each root sequence is 839. RootConfigurationIndex informs the UE on which sequence to use via SIB2 as shown below.

This rootSequenceIndex is a logical value. The real number (physical number) is called 'u' which is a variable used to generate PRACH ZaddOff-Chu Sequence.

ZaddOff Chu Sequence generated by the following equation. This sequence is allocated along Frequency Domain.

UE can select a logical root sequence based on logical RachRootSequenceIndex in SIB2 .

Once UE pick a specific Logical Root Sequence Index value, it can figure out the physical root sequence index (u).

The mapping between the logical rootsequenceIndex and physical root sequenceIndex'u' is determined by the following table.

For example, if the logical rootsequenceIndex is 22 (From SIB2)as in the example shown above, the 'u' become '1' according to following table.

For example, the range that 22 belong to is as follows.

Then we can convert the above row into a table as shown below and we can easily figure out the 'rootSequenceIndex=22' is mapped to 'u=1'.

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.

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:

  Number of rows = celling (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:

  Number of rows = celling(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 as shown in the picture below.

Each cell, then must have a different RootSequenceIndex to avoid the reception of false preambles in adjacent e-NB and the planning could be linked (if desired) to the PCI planning. See figure below.

How UE will get RA-Preambles /or how UE can select RA-preambles /or how does Network knows exactly when UE will transmit the RACH  ?

RACH related information is determine by SIB-2 which is comes from network.

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.

There are total of 64 preambles available which are divided into two groups Group A and Group B. UE decides the preamble index from a group on the basis of parameters received in SIB2.

Group A always exists and Group B exists only with the specific configuration in SIB2 parameter. 

NumberofRA-Preambles :- e-NB sends this value in SIB2 which denotes the total number of preambles available for UE to send a RACH Request.

SizeOfRA-PreamblesGroupA :- It represents the number of preambles available within Group A.

So, number of preamble in Group B =  NumberofRA-Preambles - SizeOfRA-PreamblesGroupA

If sizeOfRA-PreamblesGroupA is equal to numberOfRA-Preambles then there is no Random Access Preambles group B. 

MessageSizeGroupA :- Message size threshold for selecting preamble Group A in term of bits (56, 144, 208 or 256 bits) which is received in SIB2. 

Now UE needs to decide the group from which it needs the preamble. Group is decided on the basis of size of  MSG3( RRC connection request ).

If Msg3 size > messageSizeGroupA , preamble will be selected from Group-B
else preamble will be selected from Group-A.

Mainly this is how UE decides the Group. From the selected group, randomly UE selects a preamble index. 


Power Ramping Step-

This parameter is the power increase step of the random access preambles transmitted before the UE receives the RA response./

OR This is mainly used when e-NB is not able to detect the RACH Request then UE will re transmit the RACH Request by increasing the power to powerRampingStep factor.

This parameter is determine by SIB2 which is comes from network.

Assume that UE is sending the preamble from the edge of the cell but how much power UE can use ?

Assume that he actually use very low power (1 db.). What is the problem if he used very low power for the RACH procedure ? There won’t be any RA-Response received from e-NB. Because UE transmit the preamble with low power, signal may not reached to the e-NB. So what UE will do ?

UE will have to send the preamble again but with increase the power at least 1db.

Basically Value Range of PowerRampStep : 1 to 8
And Physical Value Range : 1 dB to 8 dB, step 1 dB

Parameter Setting : The default value is 2, that is 2 dB.

Impact on the Network Performance
>> If this value is too high, the access process is shortened, but the probability of power waste is higher.
>> If it is too low, the access process is lengthened, but the transmitting power is saved.

How UE decides the Power used for RACH request Transmission .

Power used  for RACH Request transmission =
preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER – 1) *powerRampingStep

Where,

preambleInitialReceivedtargetPower : Power factor which will be used for first transmission of RACH Request.

Value varies from -120dBm to -90 dBm .

DELTA_PREAMBLE = This is preamble format based delta offset. There are four formats available for preamble which are called as preamble formats. Most of the time preamble format 0 is used. 

For Example:-
In Sib2, PreambleInitialReceivedtargetPower = -104
              PowerRampingStep = 2 (Default value)
First Transmission of RACH Request:-
PREAMBLE_TRANSMISSION_COUNTER = 1
For preamble format 0, DELTA_PREAMBLE = 0 

Power used for RACH = -104 + 0 + (1- 1) *2
                     = -104

Suppose e-NB is not able to receive it or e-NB failed to receive it.

Second transmission of RACH request:-
PREAMBLE_TRANSMISSION_COUNTER = 2
Power used = -104 + 0 + (2-1) * 2
                     = -102 

Uplink Time alignment/TimeAlignmentTime :
It was discussed above how the e-NB controls Timing Advance that each UE has to apply. Once the UE gets a Timing Advance Command, UE applies it and now the question is for how long the UE uses the received Timing Advance value?

The e-NB provides the UE with a configurable timer called timeAlignmentTimer.

TimeAlignmentTimer is used to control how long the UE is considered uplink time aligned.

The value of the timer is either UE specific (timeAlignmentTimerDedicated) and managed through dedicated signalling between the UE and the e-NB, or cell specific (timeAlignmentTimerCommon) which is indicated in SIB2.

In both cases, the timer is normally restarted whenever a new Timing Advance is given by the e-NB.

At the time of restart, the timer is restarted to a UE specific value if configured; otherwise it is restarted to a cell specific value.

The UE starts/restarts the TimeAlignmentTimer based on the condition when it received the Timing Advance Command.

1. The Timing Advance Command is received in MAC RAR but if timeAlignmentTimer is not running: This case may arise in situations like, timeAlignmentTimer has expired (connected mode), Initial access from RRC_IDLE, during RRC Connection Re-establishment procedure etc…After the reception of RAR, the UE shall apply the Timing Advance Command value received in RAR and start timeAlignmentTimer. If the contention is not resolved/successful, then the UE stops timeAlignmentTimer, else, the UE continues running the timer.

2. The Timing Advance Command is received in MAC RAR as part of non-contention based Random Access procedure.

After the reception of RAR, the UE shall apply the Timing Advance Command value and starts/restart the timeAlignmentTimer.

3. The Timing Advance Command is received in MAC RAR as part of contention based Random Access procedure in connected mode and timeAlignmentTimer is already running: This could be in situations like UE is requesting for uplink resources but UE doesn’t have valid PUCCH resources for Scheduling Request etc…After the reception of RAR, the UE shall ignore the received

Timing Advance Command value and shouldn’t restart the timeAlignmentTimer.

4. When a Timing Advance Command MAC CE is received, the UE shall apply the received value of Timing Advance Command value and start/restart timeAlignmentTimer.

As we know e-NB continuously measures timing of uplink signal from the UE and adjusts the uplink transmission timing by sending the Timing Advance Command to the UE.

If the UE has not received a Timing Advance Command until the expiry of timeAlignmentTimer, the UE assumes that it has lost the uplink synchronization. Hence, prior to any PUSCH/PUCCH/SRS transmission in the uplink, an explicit timing-re-alignment phase using the random access procedure must be performed to restore the uplink time alignment.

The UE shall perform the following actions upon the expiry of timeAlignmentTimer:

- Flush all HARQ buffers;

- If configured, release PUCCH resources of Periodic CQI and Scheduling Request, and also SRS configuration. By doing so, the UE doesn’t perform transmission of SRS/PUCCH while timeAlignmentTimer is not running. The e-NB has to configure these parameters again in order for the UE to transmit SRS/Periodic CQI/Scheduling Request after UE starts timeAlignmentTimer

- Clear configured downlink assignments and uplink grants. i.e., release SPS grant (uplink) and assignment (downlink) if configured

Note: The UE shall not perform any uplink transmission except the Random Access Preamble transmission when timeAlignmentTimer is not running.

For multiple Timing Advances in uplink Carrier Aggregation concepts in Release-11, refer to here

Non-Contention based RA-Procedure:

Normally it happened in case of handover.

For handover purpose e-NB allocates the special /dedicated preamble for the UE.

When UE is edge of the cell and his signal strength is not good but his signal strength is good in neighbour cell, then UE has indicating that he want to move from old cell of old  e-NB  to new cell of new  e-NB. Now old e-NB is talk to new e-NB in handover request  message that my user want to latch to your network ,please allocate one special preamble for this user to avoid power ramping step because he is in call such that it would not effect for RACH procedure while moving to new cell. So new e-NB sends a special preamble to old e-NB for this user in handover acknowledge message along with bearer configuration. The same information is received by UE from old e-NB in RRC Connection Reconfiguration message and when UE goes from old e-NB to new e-NB he use this special preamble for RACH procedure to avoid the collision. So UE go to the new cell, use may same frequency or may different frequency , read the PSS and SSS and then he got the PCI. After that he read the broadcasting information ,then he read all the system information along with that wanted to perform the RACH procedure. Immediately start RACH procedure after reading SIB2. For RACH procedure UE has to read SIB2 and rest are not mandatory because SIB2 contains information about RACH/PRACH. Once UE has received the uplink grant that is a RA response from the e-NB, he will send the RRC connection reconfiguration complete message to the new e-NB to indicate that handover is complete.

Contention means fighting and Non-contention means no fighting. Why no fighting? because there is special preamble. 

DRX (Discontinuous Reception) Command-
When mobile equipment has to do discontinuous reception ?
Normally mobile equipment is not having any uplink data , he won't ask for uplink resource. Uplink is not a problem but in downlink it is an issue because we dont know when we get the data,we dont know when e-NB schedule the data.
That is why, the mobile equipment has to be awake all the time in order to decode downlink data as the downlink data may arrive at any time. This means that mobile equipment has to be monitoring PDCCH in every sub-frame in order to check if there is any downlink data available.
It means mobile equipment has to be "ON" all the time even when there is no traffic between network and mobile equipment. But being ON all the time would drain the user battery and this consumes a lot of the user equipment power.
What is the ideal solution to save battery consumption and still does not lose chance of receiving the data that Network sent to UE ?

One of the solution for this is let UE get into sleeping mode for a certain period of time and wake up for another period of time for checking if there is any data coming from the network and getting into sleeping mode again if there is no data and wake up again... repeating this cycles. This kind of periodic repetition of "sleep mode and wake up mode" is called DRX (Discontinous Reception".
That's why, in LTE DRX is introduced to improve user battery lifetime. 

There are mainly two type of DRX -1) Short DRX , 2) Long DRX

When e-NB schedule the Short DRX and Long DRX ?
When user is in active state and if there is no data for transmission/reception, then user has to move short DRX. If user is in short DRX and still there is no data for transmission/reception, then user move to long DRX.But the user is in either short DRX or long DRX, if resource is allocated then user goes to the active state. Active state means he will listen the PDCCH in every subframe.  
DRX command won't have any information .It is just a command that it tells the user to move from an active state to short DRX, short DRX to long DRX.Information won't be present.

FGI:

FGI bits 4 and 5 in UE capability info indicate UE’s support on DRX feature.

value UE-EUTRA-Capability ::=
{
  featureGroupIndicators '01011110 00001101 11011000 10000000'B,
}
Bit 4 and 5 indicate CDRX capability
Bit 4: - Short DRX cycle
Bit 5: 
- Long DRX cycle
- DRX command MAC control element

How can we synchronize UE-wakeup timing with Network transmission timing for the UE ?
When network decides to transmit the data for the UE and UE has to be woken up that time. But, how UE will get to know that there is some downlink data ? or how network inform to UE that  there is some downlink data available ?   

Network informs UE by using RRC ConnectionReconfiguration or RRC Connection Setup message as follows-

MAC main config :

The meaning of each DRX configuration parameter as part of RRC message are as follows-

DRX  Cycle -  The duration of one 'ON time' +  one 'OFF time'(opportunity for DRX).

ON DurationTimer - The duration of 'ON time' within one DRX cycle.
DRX-Inactivity timer-  Specify how long UE should remain 'ON' after the reception of a PDCCH. When this timer is on UE remains in 'ON state' which may extend UE ON period into the period which is 'OFF' period.
DRX-Retransmission timer- It indicates the maximum number of sub-frames the UE should wait before entering into sleep mode if a retransmission of data is expected from the e-NB. That is, when retransmissions are expected on duration timer is extended.
shortDRX-Cycle- The duration of short DRX ON time + OFF time. 
drxShortCycleTimer- Specifies the number of consecutive subframes the UE shall follow the short DRX cycle.
LongDRX-CycleStartoffset- Long DRX-Cycle and drxStartOffset. The value of longDRX cycle is in number of sub-frames. Value sf10 corresponds to 10 sub-frames, Value sf20 corresponds to 20 sub-frames and so on.
drxStartoffset- Specifies the sub-frame where the DRX Cycle starts.

Below figures that would help us for more clearer undestanding-

Figure1: 
When Long DRX Cycle is configured and No PDCCH is received during the cycle

Figure2:

When Long DRX Cycle is configured and a PDCCH is received during a cycle(ON duration). 

We will notice that the 'DRX inactivity Timer'  get reset and 'ON duration' of DRX cycle is extended.

Figure3:
When long DRX Cycle is configured and a PDCCH and DRX Command MAC CE are received during a cycle. We will notice that both DRX inactivity timer and ON duration timer are going to stop.

Figure4:
There are certain parameters we have to understand when Long DRX Cycle and Short DRX Cycle are configured.

If any DCI (PDCCH) arrives during the wake-up period of any DRX cycle, the drx-inactivityTimer starts and 'Wake-up(ON duration) status' continues until the drx-inactivityTimer expires.
After drx-inactivityTimer expired and the shortDrxCycle condition meet, the shortDrxCycle starts and drxShortCycleTimer starts.
If there is no DCI(no PDCCH) until drxShortCycleTimer expires, Long Drx Cycle starts.

Following is one example showing this overall logic. 

BSR (Buffer Status Report)- 

BSR is a kind of MAC control information from UE to Network carrying the information on how much data is in UE buffer to be sent out. 

In another way we can say, it is a kind of MAC layer message from UE to Network (e-NB) saying "I have something to transmit, would you give me a Grant to send this data ?" Then Network would allocate the bare minimum amount of UL Grant (Resources for PUSCH) if the resource is available. 

With this mechanism, network can optimize UL resources based on following logics.

Allocate UL resources (UL Grant) only when UE has something to transmit

Avoid allocating too much UL resources (more than what UE needs) which lead to waste of resources.

In LTE logical channel are 4 groups. But why Groups ?

If we have to report the beffer of each and every logical channel we need lots of information.
So for 8 logical channel we need 8 different information.We have to report 8 different channel information to the e-NB. Because, PRB will be allocated to the user only on the basis of whatever the report sent to the e-NB. 
So, according to the QCI we have divided 4 logical channel groups, all the low priority channels will be are the first group, medium priority channels will be second group, high medium priority channels are the third group and high priority channels are 4th group.     
Basically, logical channel groups are decided on the basis of priority.

There are several types of BSR. We can classify these in terms of data structure and BSR Timings.

BSR- 1) Data Structure
             - Short BSR
             - Long BSR
             - Truncated BSR
        
         2) BSR Timings
             - Regular BSR
             - Periodic BSR
             - Padding BSR

Short BSR: 
When we have data in one logical channel group in the UE buffer to be sent out is called Short BSR.                                      
When sending the short BSR we need to attach the logical channel group id. LCG ID is the 2bit information which tells the data belongs to which group, For example- group0- 00, group1-01, group2-10 and group3-11.

Truncated BSR:
Truncated BSR will be sent even when we don't have the resources available to send a Long BSR. 

When more than one LCG has data available for transmission but remaining UL allocation is not sufficient to send Long BSR then Truncated BSR MAC CE is used.
  
We have the data arrives for all the logical channel information, we need to send a long BSR.But if we want to send a Long BSR we need some resource. Even that resources are not available, then we send the Truncated BSR. It is 1 byte of information by which e-NB understand that we have lots of data arrived from different logical channels but don't have the resource even to report the Long BSR.
Short BSR and Truncated BSR both are 1 byte of information.So,we sand Short BSR instead of Truncated BSR. 
Index id for Short BSR - 11101
Index id for Truncated BSR - 11100

Long BSR-
When we have data in all (4) logical channel group in the UE buffer to be sent out is called Long BSR.
When sending the Long BSR we no need attach the logical channel group id.
Index id for Long BSR - 11110

One thing you would notice here would be that regardless of Long BSR or Short BSR, 'Buffer Size' bit field size is always 6 which means it can represent only 0~63. 

The 'Buffer Size' field in BSR represent the 'Index' value of the following table.

Regular BSR: Regular BSR is sent when a new data arrives in uplink buffer and the new data has higher priority than the one already waiting in the buffer.

When there in no data in the buffer and new data comes in the buffer then also Regular BSR happened. 

When the retransmission BSR timer is going to be expired but still data are available for transmission for any of the logical channels in that case also Regular BSR happened. 

Periodic BSR:

Periodic BSR is sent with the predefined periodicity. The periodicity is defined by Network and get informed to UE by RRC message (e.g, radioResourceConfigDedicated IE in RRC Connection Reconfiguration).

Why the periodic buffer status report is needed?
Let us assume that the data belonging to one logical channel arrive continuously at the UE's buffer and the UE is in the middle of transmission of the data. In this case, the first BSR is triggered when the first data for the logical channel are available. However, provided that the data belonging to other logical channels do not arrive at the UE's buffer, no BSR listed above will be triggered.As time goes by, more data may arrive for the logical channel and some data for the logical channel may be discarded. Thus, to prevent the discarding of the data in a logical channel a BSR is transmitted periodically using the periodic BSR Timer. 

Periodic BSR Timer -

Periodic BSR is sent with the predefined periodicity. The periodicity is defined by Network and get informed to UE by RRC message (e.g, radioResourceConfigDedicated IE in RRC Connection Reconfiguration).

Periodic BSR timer is restarted every time either a long/short BSR is transmitted.

Retransmission BSR Timer(retxBSR- Timer) -

To provide BSR robustness, the LTE standard provides a mechanism to improve the robustness of buffer status reporting. We want to avoid deadlock situations which may occur when the UE sends a BSR but never receives a grant. A BSR retransmission mechanism is built into the UE implementation. The UE keeps a retxBSR-Timer which is started when a BSR is sent and stopped when a grant is received.  If the timer expires, and the UE has still has data available for transmission, a new BSR is triggered. The retransmission timer, configured by RRC, ranges from 320ms up to 10.24 seconds.

For every UL grant received, retxBSR Timer is restarted.

The Retransmission BSR timer expired and UE has data available for transmission for any of the logical channel which belongs to LCG .In this case it is called as Regular BSR.         

Padding BSR:
Padding BSR is sent when the number of padding bits in a data message is equal to or larger than the size of the BSR.

What is padding BSR and why it is needed? However normal BSR also can carry same information but why do we need specific padding BSR?

UE got the UL Grant and the padding data is larger than the size of BSR CE and the sub-header (This is called Padding BSR).
There are some cases where network send UL Grant when UE does not have any data to transmit, in this case UE transmit all 00 data or some garbage data and long padding 0s. In this situation, UE would put BSR MAC CE as part of MAC PDU and set BSR index value all 0.

Schuduling Request Procedure:

The scheduling request is a special physical layer message controlled by the MAC layer for UE to ask the network to send uplink grant (DCI 0).So that UE can transmit the data on PUSCH. 

OR in other way, SR is an Uplink Physical Layer message from UE to Network, saying "I have some data to send to you. Would you send me some Grant (DCI 0) for me to send the data ?"

OR, UE send scheduling request on PUCCH when regular BSR is triggered and UE does not have uplink resource/ uplink grant(DCI 0) to transmit the data on PUSCH.

Regular BSR is triggered when data becomes available for transmission in the uplink.

e-NB needs to configure the UE with SR configuration via RRC message in order for the UE to transmit SR on PUCCH. The SR configuration structure is as given below

-sr-PUCCH-ResourceIndex indicates the UE with the frequency domain resources 

- sr-ConfigIndex determines the time domain resources of PUCCH which carriers SR. 

- e-NB controls the maximum number SR transmissions from each UE on PUCCH using the parameter dsr-TransMax.

If the UE has no valid PUCCH resources (SR is either not configured or released), then the UE initiates Random Access procedure.

if   SR_COUNTER < dsr-TransMax

      increment SR_COUNTER by 1

      else

      Initiate a Random Access Procedure and cancle all pending SRs.

Once SR is triggered, the UE calculates the SR periodicity and offset which is based on sr-ConfigIndex IE. After transmitting the first SR on PUCCH, if the UE doesn’t receive uplink resources from the e-NB, then based on the periodicity, the UE re-sends SR on PUCCH. This process continues till UE transmits SR for dsr-TransMax number of times on PUCCH if the UE doesn’t receive uplink resources from the e-NB. After transmitting SR for maximum (dsr-TransMax) number of times, the UE releases SR resources (frequency as well as time), initiates random access procedure and cancels all pending (triggered) SRs.

SR periodicities of 5, 10, 20, 40, and 80 ms are initially proposed in release-8. In release-9, short SR periodicities of 1 and 2 ms are introduced which reduces the latency.

When a short SR period is configured or when running VoIP traffic, the SR can be retransmitted unnecessarily. To avoid unnecessary SR transmissions, in release-9, an SR prohibit timer (sr-ProhibitTimer-r9) is introduced to reduce the load on PUCCH.

sr-ProhibitTimer-r9 IE is under mac-MainConfig and it can take values from 0 to 7. SR prohibit timer value is in number of SR period(s). Value 0 means no timer for SR transmission on PUCCH is configured. Value 1 corresponds to one SR period, Value 2 corresponds to 2*SR periods and so on. The UE starts this timer after transmitting an SR. When this timer is running, the UE is not supposed to be transmitting SR on PUCCH.

UE uses PUCCH Format 1 for transmitting SR alone. 

When SR and HARQ feedback in uplink happens to coincide in the same sub-frame, the UE shall transmit HARQ feedback on SR's frequency resource using PUCCH Format 1a/1b. Since PUCCH received is on SR resource, the e-NB can easily understand that HARQ feedback and SR are present in the same sub-frame.

UE-specific SR periodicity and sub-frame offset configuration-

UE release SR resources in the following cases-

·         When UE has transmitted SR for maximum amount times (dsr-TransMax)

·         After timeAlignmentTimer expiry

·         During MAC reset procedure

·         During Handover (during Handover, MAC reset is performed)

Padding :

MAC PDU size has got stander PDU sizes. We can only send the data according to the PDU size. If there is some data which is lesser than the PDU size, we need to attach the Padding bits.

But when we attached the padding bits the related sub-header also attached.

So, Padding BSR is sent when the number of padding bits in a data message is larger than the size of BSR.

For byte aligns if some data are not fulfilled, then we have to attach the padding bits to make a byte align. Padding just like a MAC control element. For control element we no need F/L field.

Logical channel id for padding bit is 11111.

Example:

Power Headroom Report:

Power headroom is a type of MAC control element that indicates how much transmission power left for a UE to use in addition to the power being used by current transmission.

The formula of PHR as follows

Power Headroom = UE Max Transmission Power - PUSCH Power 

                             = Pmax  -  P_pusch

Why UE is reported PHR to the e-NB?

Sometimes UE battery running out. At the time of UE battery running out, it is not correct for the UE to ask e-NB for high modulation technique like 16 QAM, 64 QAM ,128 QAM because there is a relationship between modulation technique and transmission power of the UE. More battery is required for a higher modulation technique.

There is a possibility that UE is on the edge of the cell and more power is required for transmission, but actually he is reporting his power headroom report value is (-). If e-NB gives more resource to the UE but he cannot use much resource for the transmission if he does not have enough power headroom. So based on the Power Headroom Report e-NB takes the decision to allocate the resources to the UE to avoid unnecessary resource wasting.

When does UE send Power Headroom Report?

There are two way this can be configured in the UE through RRC messages.

1. When down link pathloss threshold is reached (dl-PathlossChange).

2. When periodicPHR-Timer is set, UE send periodically the Power Headroom Report to the network.

Check for RRC messages like RRC Connection Setup, RRC Connection Reconfiguration to get the details of the Power Headroom configuration used. Search for IE phr-Config.

dl-PathlossChange: DL Pathloss Change and the change of the required power backoff due to power management. Value in dB. Value dB1 corresponds to 1 dB, dB3 corresponds to 3 dB and so on

periodicPHR-Timer: Timer for PHR reporting. Value in number of sub-frames. Value sf10 corresponds to 10 subframes, sf20 corresponds to 20 subframes and so on.

prohibitPHR-Timer: Timer for PHR reporting. Specifies, how long PHR transmission is prohibited. Value in number of sub-frames. Value sf0 corresponds to 0 subframes, sf100 corresponds to 100 subframes and so on.

Header :

Power headroom report MAC control element  length field is 6 bits.

Value is -23db to 40 db ,i.e size is (0-63). 

Power headroom levels for PHR-

 
RNTI(Radio Network Tempory Identifier): 

It is a kind of Identification number. Normally we use identification number to differentiate one thing from all other similar things.

RNTIs are always used to identify information dedicated to a particular subscriber on the radio interface, especially if common or shared channels are used for data transmission.

There are several RNTI types in LTE such as SI-RNTI, P-RNTI, C-RNTI, Temporary C-RNTI, SPS-CRNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, RA-RNTI, and M-RNTI. 

Each RNTI’s usage, its value range etc…are discussed in detail below-

• P-RNTI : It stands for Paging RNTI. Used for Paging Message.
• SI-RNTI : It stands for System Information RNTI. Used for transmission of SIB messages
• RA-RNTI : It stands for Random Access RNTI. Used for PRACH Response.
• C-RNTI : It stands for Cell RNTI. Used for the transmission to a specific UE after RACH.
• T-CRNTI : It stands for Temporary C-RNTI. Mainly used during RACH
• SPS-C-RNTI : It stands for Semi persistance Scheduling C-RNTI
• TPC-PUCCH-RNTI : It stands for Transmit Power Control-Physical Uplink Control Channel-RNTI
• TPC-PUSCH-RNTI : It stands for Transmit Power Control-Physical Uplink Shared Channel-RNTI
• M-RNTI : It stands for MBMS RNTI
• CC-RNTI : It stands for Common Control RNTI
• G-RNTI : It stands for Group RNTI
• SC-RNTI : It stands for Single Cell RNTI
• SL-RNTI : It stands for Sidelink RNTI
• SC-N-RNTI : It stands for Single Cell Notification RNTI
• eIMTA-RNTI : It stands for Enhanced Interference Management and Traffic Adaptation - RNTI

Who issues these RNTI ?
Network(e-NB).
Exactly what does RNTI do for each of those radio channel ? 
Normally we use RNTI for indentification number to differntiate one thing from all other similar things.If UE does not know the exact RNTI values for each of the cases, it cannot decode the radio channel messages even though the message reaches the UE intact.
How can PHY layer know which RNTI it has to use to decode a data ?
MAC or Layer 1 controller would instruct PHY on which RNTI it has to be used.
How MAC or Layer 1 controller would know which RNTI to be used ?
There is no explicit algorithm for this, MAC/L1 controller needs to figure it out "based on context". For example, if it is at the subframe where SIB is transmitted, it would instruct PHY to use SI-RNTI. if UE is in connected mode, it may instruct to use C-RNTI, TPC RNTI , P-RNTI etc.

Following table shows the range of values which is allocated for each RNTI types-

SPS-RNTI:

Actually, in LTE we use dynamic scheduling but one exception is SPS-CRNTI.

SPS means Ream Time Call like VOIP case we use semi persistent scheduling because of VOIP call we sends continuously sending voice and receiving voice.

We need the resource in every TTI, so UE read the PDCCH in every TTI and get the resource information. The UE can get the resource consistently in every TTI no doubt.

If UE continuously read the PDCCH in every TTI (sub-frame) ,this will increase the signalling overhead for the E-UTRAN in order to support a large number of VoIP users. 

So, the optimal solution is to allocate the resources at once and let the UE use these resources instead of allocating the resources periodically(every 1ms).

The advantage is battery power utilization means unnecessary,why we have to read PDCCH in every sub-frame to get the resources.So what theydone, for VoIP call they use in a semi-persistent manner.

For example, scheduling time is like 100 TTI. Meaning is UE will read the PDCCH after 100 TTI and get the resources.

SPS C-RNTI is a dedicated RNTI and is configured by RRC. e-NB configures the UE with a SPS C-RNTI as part of sps-Config in “RRC setup / or RRC reconfiguration” message.                            

Details explanations here.

MAC Architecture :

E-UTRA defines two MAC entities. One in the UE and one in the E-UTRAN. Here is how it looks for user plane and control plane.

The MAC layer is composed of a Hybrid Automatic Repeat request (HARQ) entity, a multiplexing/de-multiplexing entity, a logical channel prioritization entity, and a control entity.

PCCH which  receives the information from PCH. BCCH which receives the information from Broadcasting channel(BCH). but there is probability that the data might be coming DL-SCH because SIB will come on PDSCH with SI-RNTI. Similarly paging will come on PDSCH with 

P-RNTI. But DL-SCH and UL-SCH are used for sending the data either on CCCH or DCCH or DTCH. With the help of logical channel id MAC will do the multiplexing and vice verse. Each sub-header will have a logical channel id which explains from where MAC takes the data. But before doing multiplexing, logical channel prioritizing has to be done. Why MAC use prioritizing? 

Because our MAC buffer size is small , the amount of data available in the buffer is high. So first We need to take the data from high priority of the data. Logical channel prioritization is done in both uplink and downlink side. Uplink transmission data will send out in UL-SCH only but in the downlink de-multiplexing is done at e-NB side and that data is coming through DL-SCH only. 

Now this RACH is isolated. RACH is actually not linked to any higher layer information. RACH is the use of only sending preambles, it is not used for sending data.The data of the logical channel CCCH, DCCH and DTCH are going through UL-SCH and DL-SCH. HARQ mechanism is implemented to correct the error packets in the PHY layer but MAC layer manages the HARQ processes.

RRC protocol is in control of the configuration of MAC that means RRC decides how MAC will behave. For example RRC tells MAC to configure a specific PDU size. MAC control actually decides how to do all this jobs. 

MAC control is a software program which required some external input(from RRC layer) to run this program. For example, we generally send a preamble at the time of handover. This control will get the information from an RRC layer for predefined preamble. Target e-NB will send a special preamble to the old e-NB in 'handover acknowledge' message. So, old e-NB RRC layer will go to control part of the MAC layer and say that if you go to the new cell, use this special preamble, do not use the other preamble. If you use other preamble that possibility may happen collision and service may be delayed.       

HARQ (Hybrid Automatic Repeat Request) :

One of the purpose of LTE to come in is to bring in high data rates. To achieve this UE must use some techniques where it can transmit data quickly and reliably.

What happens when there are error packets received on UE or e-NB. Of-course, there would be some sort of mechanism applied on the devices to rectify the errors. Therefore, in LTE two mechanisms are followed to detect and correct the errors. A mechanism (HARQ) is implemented to correct the error packets in the PHY layer. Furthermore, there might be a chance that some packets are still left with errors. Hence, these are passed to upper layers. The second mechanism (ARQ) is implemented in RLC layer which takes care of these residual errors. It either fixes those errors or discards the packets.

ARQ: 

1. Works at RLC layer

2. If the received data has an error (as detected by ARQ) then it is discarded, and a new re-transmission is requested from the sender

HARQ:

1. Works at PHY layer but controlled by MAC layer

2. If the received data has an error then the Receiver buffers the data and requests a re-transmission from the sender. 

When the receiver receives the re-transmitted data, it then combines it with buffered data prior to channel decoding and error detection. This helps the performance of the re-transmissions.

HARQ adapts SAW (Stop And Wait) processes.

SAW (Stop And Wait) processes :

It also referred as HARQ Process. In LTE FDD there are 8 SAW process.

In normal case, Once a packet is send from a particular process, it waits for an ACK/NACK. Till it receives ACK/NACK, the process will be in-active state and will not process other packets. This significantly reduces the round trip time and does impact throughput. 

Therefore, multiple SAW processes are used.  When the 1st process is waiting for an ACK, the 2nd SAW process will send data and so on with the eight processes.   
MAC layer manages these HARQ (SAW) processes.

Each transmission in LTE corresponds to 1 TTI (Transmission Time Interval). Therefore each SAW process should process the data within 1 ms or 1 sub frame. As we know that there are 8 SAW process hence each process will have to wait for 8 ms before sending another chunk of data or a re-transmission over the Air Interface.   

The sending entity buffers the transmitted data until an ACK is received, because if NACK is received then it has to re-transmit the data.

Example: 
Acknowledge for the sending data --------------------> n+4
Retransmission for the sending data ------------------> n+8

ACK  = Means transmit fresh data

NACK= Means retransmit old data

When the data is removed from the buffer?
--Data is removed when:
1. ACK is received
2. Max number of re-transmission has reached

SYNCHRONOUS and ASYNCHRONOUS HARQ :
Synchronous HARQ (used in UPLINK):
1. Re-transmissions are scheduled at fixed time intervals
2. Generates lower over-head as it doesn't need to include HARQ process Id in the outgoing data
3. Always works in cycle even if no resources are allocated during a specific sub-frame which means that the 1st process will repeat itself after every 8 ms.

Asynchronous HARQ (used in DOWNLINK):
1. e-NB can use any of the HARQ process (out of 1-8 SAW process) in the DL
2. e-NB provides instructions to the UE regarding which HARQ process to use during each sub-frame for which resources are allocated. (The HARQ process identity is included within the PDCCH transmission)
3. Asynchronous HARQ increases signalling overhead because it includes the HARQ process Identity within the DCI.
4. Asynchronous HARQ increases flexibility because re-transmissions doesn't have to be scheduled during every sub-frame.

UL HARQ:
Whenever a re-transmission occurs in up-link, it can be either Adaptive transmission and Non-adaptive transmission.But in downlink case, it is always Adaptive Transmission. 

Adaptive Transmission:

- Triggered when NDI bit is not toggled relative to the previous transmission. This information should be present in the PDCCH DCI0.

- MCS and RB's may change as per resources allocated by the e-NB on PDCCH DCI0 transmission

Non -Adaptive Transmission:

1. Triggered when NACK is received on PHICH

2. Use same resources as per the previous transmission i.e. MCS and RB's remains unchanged

In downlink why always adaptive transmission ? But why not non-adaptive transmission ?

In case of downlink it is always adaptive transmission because e-NB will send DCI ( 1,1A,1B,1C, 1D,2,2A,2D,2C) before sending any downlink data, so that UE should follow for the transmission. That is why it is always adaptive.

In case of uplink ,it may be adaptive and non-adaptive transmission.

When e-NB sends DCI 0 to the UE then it is called as adaptive transmission. For non-adaptive cases

e-NB won't send DCI 0  and MCS and RB's remains unchanged at UE end.

When e-NB sends DCI 0 ?

When e-NB think that there may be some situation occurs where UE transmission and e-NB transmission are same RB position. In that situation there may be data class. So what e-NB will do ? 

e-NB can change the RB start position for the UE.But e-NB won't change the number of RB's. When UE transmits the data, he should use new RB position.  

Important Points:

DCI 0 has been always a higher priority than PHICH. When e-NB send the ACK on PHICH but in there NDI bits is not toggle in DCI 0, then UEretransmit the data.

1. If ACK is there on PHICH and PDCCH carriers the NDI bit as not toggled then NON-ADAPTIVE re-transmission will occur
2. If NACK is there on PHICH and no PDCCH is received then UE will store the data in the HARQ buffer and no re-transmission will occur.

Redundancy Version (RV) :
Redundancy version is associated with the HARQ mechanism. Every uplink and downlink data schedule RV started with '0' and depending on the re-transmission it increases.
In downlink it increases from 0,1,2,3 and in uplink it increases 0,2,3 and 1.
When the RV is increasing the NDI bit is not toggle.  
TTI Bundling:

To understand TTI bundling one need to have the basic idea of Hybrid Automatic Repeat Request (HARQ).

HARQ is a process where data at mac layer is protected against noisy wireless channels through error correction mechanism. There are couple of different versions of HARQ but in LTE we have a type known as 'Incremental Redundancy Hybrid ARQ'. When receiver detects erroneous data, it doesn't discard it. On the other hand, sender will send the same data again but this time, with different set of coded bits. The receiver will combine the previously received erroneous data with newly attempted data by the sender. This way the chances of successfully decoding the bits improve every time. This will repeat as long as the receiver is not able to decode the data. The advantage of this method is  that with each re-transmission, the coding rate is lowered. Whereas in other types of HARQ, it might use the same coding rate in every re-transmission.

In poor RF condition one method is RLC segmentation wherein a VOIP payload is split into smaller size RLC PDUs as shown in Figure.

The smaller RLC PDUs will result in smaller transport blocks which can be decoded with better accuracy. One drawback of this method is the potential overhead increase due to RLC segmentation due to multiple RLC headers needed. For a typical VOIP payload, it has been shown that as we increase the segmentation factor from 1 to 8, the overhead increases from 14% to 55%. Each RLC PDU which is mapped into a transport block will need a separate PDCCH assignment message which will contribute to control signal overhead for such a scheme. There might be retransmissions of each of those transport blocks which will also potentially increase the control signalling overhead. In addition, since we are transmitting many small transport blocks, the chances of interpreting a NACK as a ACK also increases proportionately with the increase in the RLC segmentation size. Hence, RLC segmentation has many disadvantages when We consider the transmission of a VOIP like payload from a power limited terminal.

TTI bundling is one of the features among many others that can help VoIP (Vo-LTE) calls in LTE. has been introduced in FDD and TD-LTE to improve Uplink coverage at cell edge or in poor radio conditions.

UE has limited power in uplink (only 23dBm for LTE) which can result in many re transmissions at cell edge (poor radio). Re transmission means delay and control plan overhead which may not be acceptable for certain services like VoIP.

TTI Bundling Principles

·        Same data is transmitted in the 4 consecutive TTIs, resulting in SINR gain under certain conditions. Theoretical gain is 3dB.

·        Only 1 grant is required for PUSCH transmission in 4 TTIs.

·        Only 1 HARQ feedback per bundle.

·         Lesser RLC/MAC header and CRC overhead.

·         Less L1/L2 messages

Once TTI Bundling is enabled/activated the UE send the same packet but with different error detection and correction bits (Coding rate) in 4 consecutive TTIs

TTI Bundling reduces a lot of signalling overhead as the e-NB doesn’t need to send Ack/Nack for every (re-) transmission instead it sends Ack/Nack for the entire bundle

Latency is also reduced as no waiting time (for HARQ feedback) is required between the re-transmissions.

TTI bundling triggered by UE informing the e-NB about its power limitations at the present state. 

A single PDCCH allocation is sufficient for the multiple transmissions thus saving control overhead as compared to the RLC segmentation approach. A single HARQ ACK/NACK for the combined transmissions is generated after processing the TTI bundle which can reduce the error rate of the transport block as compared with processing a single redundancy version. This approach can also reduce the delay in the HARQ process compared to transmissions of the redundancy versions separated in time using the normal approach.

Note: (Brief Knowledge)

HARQ is a process where receiver combines the new transmission every time with previous erroneous data. There is one drawback however, that it can result in delay and too much control overhead in case of poor radio conditions if the sender has to attempt many transmissions. For services like VoIP this means bad end user experience. Well, there is another way- Instead of re-transmitting the erroneous data with new set of coded bits, why not send few versions (redundancy versions) of the same set of bits in consecutive TTI and eNB sends back Ack when it successfully decodes the bits.

I hope  the figure below will make it clear. This way we are avoiding delay and reducing control plane overhead at mac layer.

How to enable TTI bundling for a specific UE ?

UE get to know this information in " RRC Connection reconfiguration message " from e-NB. 

Backoff Indicator: 

It is a special control element. It is part of RACH procedure. As part of random access response, we may receive a T-CRNTI, UL-Grant, Timing advance command. All these things are coming in the RAR message instead of that UE can receive Backoff Indicator.

Meaning is when UE sends a preamble to the e-NB and asking for the resource, if resource is not available at e-NB,depending on the situation e-NB may send Backoff Indicator command and say that you wait for some time and after some time you can send again preamble request. So e-NB will tell to UE that how much time he will wait and not sending any preamble request during that time. UE will get to know by backoff indicator. 

Backoff indicator is timing from 1ms to 960 ms.

Backoff indicator values are-

     Header:

CQI (Channel Quuality Indicator):

Just brief idea.

It is a physical layer parameter. For measurement it is an important parameter.

UE physical layer sends the CQI report to the e-NB, based on report e-NB would allocate the resource to the UE.

Resource allocation methods:

Resource allocation can be different types by using different method-

Assume that one user (UE1) is near by e-NB and other user (UE2) is far away from e-NB. So how e-NB will allocate the resources to the users.


First method (Fair proportion method):

In this method, we will give the same importance to all the users and we will get the same data rate from both the users. But the problem is UE2 has reported bad CQI. If he reports bad CQI we cannot use a high modulation technique for him. Because bad CQI means signal strength is bad. If we use high modulation technique decoding will become a problem. So will use the lower modulation technique for the guy who has reported bad CQI. But this UE1 has reported good CQI. So UE1 can use high modulation technique. But the problem is if we use a high modulation technique for the user UE1 and low modulation technique for UE2 ,definitely the data rate would be more of the user UE1 than UE2.

So in order to match the data rate irrespective in what position are there, we have to give more resources for the user who has reported bad CQI. Because with the additional resource user UE2 can send an equal amount of data with UE1 just like a fair proportion. Everybody will get the same data rate irrespective of their geographical position.

When a company manufactures the products they will implement both method Fair proportion and CQI. Very rare case Fair proportion method is used. Why ?

For example:

Assume that UE1 is using a high modulation technique, let say 64 QAM .We can send 6 bits per symbol. Assume that he got the resource 1 PRB and he sent 1250 bits. At the same time UE2 using low modulation technique and he sent 250 bits by using 5 PRB.

Second Method (CQI Based method ):

The guy who reports good CQI, he will get more resources and who reports bad CQI, he will get less resources. So, the user UE1 will get more resource than UE2.

                             

Note:
Which method is more benefit in prospect of the company's revenue by using the same amount of resources (PRB 6)?

In one situation they could able to send 2500 bits and another situation they could able to send 6500 bits. The second method (CQI based) is more benefits for the operator. In one TTI instead of 2500 bits they are sending 6500 bits, so gets more benefits with this method.

Therefore, operator has decided that the user who reports good CQI, he will get more resources than the user who reports bad CQI. 

What are the factors when allocating the resources from e-NB :
1.  Buffer Status: First to consider for resources data should be exist in the buffer that is Buffer Status. If there is no data available in the buffer of the mobile, e-NB never allocates the resource.
2. CQI report:  CQI strength is good or bad ,based on that e-NB allocates the resources.
3. Guaranteed Bit Rate (GBR).

4. How many PRBs available in the e-NB. 

5. UE capabilities like (HARQ, RLC Buffer, Modulation Techniques etc)

6. QCI (Along with ARP)

7. AMBR (Aggregate Maximum Bit Rate).

Logical channel prioritization handling:

MAC layer only does the two things, one is resource accusation and other is logical channel prioritization and multiplexing. Multiplexing of different logical channel data into a Transport Blocks.

With { UE in E-UTRA  RRC _CONNECTED STATE }

    ensure that 

              {

                  when { sending data on the uplink}

                  then { UE serves the logical channels according to their priority and configured PBR }

               }

First all the logical channel PBR (Prioritized Bit Rate) must be served and after serving the PBR if any space (resources) left out then MAC should give the highest priority channel again. That is how we do the logical channel prioritization.

PBR is equivalent to the GBR.

In what situation e-NB consider Priority and PBR :

1. If enough amount of resources are not available in e-NB ,then we have to consider first priority and then PBR.

2. If enough amount resources are available in e-NB, then we have to consider first PBR and then priority.

Bucket Size Duration (BSD):

Normally Bucket size duration can be some X amount of time. Within that X amount of time UE has to transmit this much amount of data for this logical channel. That is how we will set a prioritized Bit Rate (PBR).

That means if Bucket Size Duration is 100ms, within 100ms this much amount of data need to transmit. Now within 100ms we may get resources in every 1ms or we may get a large amount of data just in 1ms and all the data we will be sending within Bucket Size Duration 100ms. 

So, for each logical channel the Bucket Size Duration of logical channel is equal to PBR*BSD where PBR and BSD are configured by upper layer (RRC layer in "RRC connection setup /RRC connection reconfiguration"  message).

Table :

Uplink data must be scheduled based on the priority for the logical channels.

Prioritized Bit Rate for DRB1 is 8 k bytes/s = 8000 bytes/s .                                                                

Therefore, the packets we need to send within the Bucket Size Duration (100 ms)

                                                                        = PBR * BSD

                                                                        = 8000 * 0.1  bytes.  where, 100 ms=0.1 sec.

                                                                        = 800 bytes /sec.

Below table explains how to schedule data for the logical channels-

These parameters are set by e-NB.                                                                                                                                      

Example: For First run:  (Here, we considered priority)
For first logical channel :

The number of SDUs (N1) and data  present for the logical channel DBR1 is 13 and 4160 bytes.

Indirectly we can say the PDU size for this logical channel DRB1 = D1/N1 = 4160 / 13 = 320.

Therefor for second logical channel DRB2, the PDU size is D2/N2= 8000/25 = 320  is same.

And for third logical channel DRB3, the PDU size is D3/N3= 16000/50 = 320  is also same.

So, that means in all the logical channel the PDU size is same  but the amount of data has changed, for first logical channel is 4160 bytes, for second logical channel is 8000 bytes, for third logical channel is 16000 bytes.

T2 = 500 ms means total time.

T1= 20 ms mean every 20 ms we can send the data (D) 1143 bytes. 

But how many times we can sand ?

T2/T1= 500/20 = 25.

That means total 25 times UE will get the resource and according to that he can send the data 1143 bytes for 25 times.

Total data for all the logical channels is  1143 *25 = 28,575 bytes.

That means within the 500ms (T2) UE can send  28,575 bytes of data to the e-NB.

But out of 28,575 bytes whose data how much ? 

For logical channel DRB1 = 4160    (+/- 10 % )

For logical channel DRB2 = 8000    (+/- 10 % )

For logical channel DRB3 = 16000  (+/- 10 % )

                                       ----------

                                       28,160 bytes   (+/-  10 % of 28,575 bytes)

If the deviation is too much than (+/- 10%) that means UE did not schedule the data for the logical channels perfectly.

If the deviation is (+/- 10%) that means it is perfect scheduled  and it should be working with the above table.

For second, third and fourth run:  Here, we did not consider a priority. We considered PBR.

More information pending to be updated