LTE - PHY - CRC Calculation

LTE - PHY - CRC Calculation

Lets see the Transport channel functionality on the LTE eNodeB PHY layer. Transport channel is present between the MAC & PHY.
The Transport channel functionalities are provided by DSP part of the L1/L2 Chip before feeding the information to RF transceiver.

CRC Calculation & Attachment:
The Output of the Logical channel is the Transport Block. This is provided as the input stream to Transport channel. So for better error detection mechanism,
each Transport Block is padded with CRC bits or parity bits.

Input bits  = a0 , a1 , a2 , a3 ,..., aA−1 where A is the Size of the Input sequence in bits.
Parity bits = p0 , p1 , p2 , p3 ,..., pL−1 where L is the number of parity bits.

The parity bits are generated by one of the following cyclic generator polynomials:

If Parity Bit L = 24:
- gCRC24A(D) = [D24 + D23 + D18 + D17 + D14 + D11 + D10 + D7 + D6 + D5 + D4 + D3 + D + 1] and
- gCRC24B(D) = [D24 + D23 + D6 + D5 + D + 1]
If Parity Bit L = 16:
- gCRC16(D) = [D16 + D12 + D5 + 1]
If Parity Bit L = 08:
- gCRC8(D) = [D8 + D7 + D4 + D3 + D + 1]

So for Example if the Input stream is 100 bits, the Transport block with CRC length of 24 after CRC attachment will be 100 + 24 = 124 bits.

The encoding is performed in a systematic form, which means that in GF(2), the polynomial:
a0D^A+23 + a1D^A+22 + .. + aA-1D^24 + p0D^23 + p1D^22 + .. + P22D^1 + P23
yields a remainder equal to 0 when divided by the corresponding length-24 CRC generator polynomial, gCRC24A(D) or
gCRC24B(D).

Similarly, the polynomial:
a0D^A+15 + a1D^A+14 + .. + aA-1D^16 + p0D^15 + p1D^14 + .. + P14D^1 + P15
yields a remainder equal to 0 when divided by gCRC16(D)

Also the polynomial:
a0D^A+7 + a1D^A+6 + .. + aA-1D^8 + p0D^7 + p1D^6 + .. + P6D^1 + P7

yields a remainder equal to 0 when divided by gCRC8(D).

The bits after CRC attachment are denoted by b0 ,b1 , b2 , b3 ,...,bB−1 , where
B = A+ L. The relation between ak and bk is:
bk = ak for k = 0, 1, 2, …, A-1
bk = p k−A for k = A, A+1, A+2,..., A+L-1.

So, the CRC bits can be 24 or 16 or 8 depending on the Initial configurations & Implementation of the eNodeB in general. Also i dont think, CRC Length will differ for each Transport block as well. In general higher the CRC bit (here 24 bits) better the error detection technique even in worst channel conditions.

Accordingly the Cyclic genertaor polynomial will be used for the computation of CRC & its additiong to the Transport Block.

Note: The Lowest order information a0 will be mapped to the MSB of the transport block as book reading format.

Pls Refer, Spec:36.212 sec 5.1.1 & 5.3.1.1 for further reference.

LTE - MAC CE - BSR

LTE MAC CE - BSR

BSR - Buffer status report is used by UE to indicate the eNodeB about the pending data at higher layers in UE to send it to eNodeB, so that eNodeB will allocate the grants accordingly. This is sent by the UE in UL_SCH channels. to eNodeB.

Types:
3 types of BSR's available. Long BSR, Short BSR & Truncated BSR. Long BSR will generally carry the actual data. Short & Truncated BSR are used for carrying padding data's.

Short & Truncated BSR:
Length is of 1 byte. It comprises of LCG ID & Buffer Size elements in it.

LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is being reported. The length of the field is 2 bits
Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a logical channel group after all MAC PDUs for the TTI have been built. The amount of data is indicated in number of bytes. It shall include all data that is available for transmission in the RLC layer and in the PDCP layer. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits.

If extendedBSR-Sizes is not configured, the values taken by the Buffer Size field will be lesser compared to the extendedBSR-Sizes configured at eNodeB. Refer the BSR buffer size index to Data avialable in the UE mapping table below.

Long BSR:
It carries 3 bytes of  UE's actual data available to send to eNodeB from each Logical channel group ID (LCG-ID) So explicit lcg-id mapping is not required to inform the eNodeB about which lcgid is having the data to send.

Note: LCID & LCGID are different. LCID for MAC CE for BSR is given below. This will be present in the MAC-CE to inform what type of MAC-CE is sent by the UE.

X2 - Handover without MME/SGW relocation

X2 Handover without MME/SGW Relocation

X2 is the Interface present between the Macro eNB's & HeNB's & between Macro eNB & a HeNB. Basically, X2 is the interface between the eNB's. If you are aware of the WiMax architecture, then you will come to know where basically the X2 interface is adopted from, in LTE. The Concept of Call Anchor is also adopted from WiMax architecure only.

Lets discuss the X2 Handover (X2HO) here with a detailed callflow.

1. When the source cell Signal is weaker than the Target cell, then the UE sends the Measurement Report to Source EnodeB. Prior to this, Soure EnodeB would have been configured for the Measurement Events (A1, A6, as i have explained in the previous blogs).

2. UE reports Measurement report A1, A2, A3, A4 & A5 once by one. Once the A4 & A5 events informed to Source EnodeB, Source EnodeB will decide to move the call to the Target Cell, by performing a Handover.

3. The Handover decision is Taken by the Source EnodeB. It follows the following call flow to do the handover.

i. SeNB sends Handover Request to TeNB.
ii. TeNB sends Handover request Ack to SeNB
iii. SeNB sends RRC Connection Reconfiguration to UE.
iv. SeNB sends Sn Status Transfer to TeNB.
v. SeNB sends the Buffered Data to TeNB
vi. UE sends RRC Reconfiguration Complete to TeNB
vii. TeNB sends Path Switch Request to MME.
viii. MME sends Modify Bearer request to SGW
ix. SGW sends Modeify Bearer Response to MME.
x. MME sends Patch Switch request Ack to TeNB.
xi. TeNB sends UE Context Release to SeNB

Now you might have understood the Call flow for an X2 HO in LTE.

You have to follow many specs to get the Details of each and every message & also get into the details of the Message Contents.

I have attached the callflow of an X2HO for the same explained above.

Spec References: 
RRC - 36.331
X2 Inteface - 36.423
X2HO - 36.300
S1AP - 36.413

NAS - ARP

NAS - ARP

ARP is Allocation and Retention Priority. Understanding ARP requires to chase multiple Specs for its functionality.

As per 3GPP TS 36.413 version 12.3.0 Release 12

ARP contains 3 Mandatory IE's:
1. Priority Level
2. Pre-Emption Capability
3. Pre-Emption Vulnerability

Priority Level - Range: 0 to 15
0 - Logical Error
1 - Highest Priority
14 - Lowest Priority
15 - No Priority

Pre-Emption Capability
It has 2 Enumerated Value:
1. shall not trigger pre-emption, - Cannot preempt other bearers during resource crunch
2. may trigger preemption - Can Trigget preemtion of other bearers during resource crunch

Pre-Emption Vulnerability
It has 2 Enumerated Value:
1. not preemptable - This bearer cannot be pre-emptable by other bearers

2. preemptable - This bearer can be release during resource crunch by other bearers.

As per spec 23.401 Rel 11, 4.7.3 Bearer level QoS parameters

1. The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR bearers).

2. The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover).

3. The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The preemption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority value.

4. Once successfully established, a bearer's ARP shall not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment should be solely determined by the other EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters.

NOTE 1: The ARP is not included within the EPS QoS Profile sent to the UE. So UE will not know about ARP configurations eventhough its one of a Bearer Qos Parameter.

NOTE 2: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention, and Priority".

NOTE 3: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNodeB can then drop the "video bearer" without affecting the "voice bearer". This would improve service continuity. ETSI 3GPP TS 23.401 version 11.3.0 Release 11 65 ETSI TS 123 401 V11.3.0 (2012-11)

NOTE 4: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a case the eNodeB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption vulnerability information allows this.

LTE - Signalling Radio Bearers

LTE - Signalling Radio Bearers

Lets talk about the Radio Bearers in LTE. The Radio bearers exactly comes in the RRC layer with a Logical Channel Mapping. The Radio bearers are classified as Signalling Radio Bearers - SRB's & Data Radio Bearers - DRB's

Signalling Radio Bearer's:

There are 3 SRB's - SRB0, 1 & 2

SRB0:
SRB0 is mapped to CCCH in Uplink & Downlink. The RRC messages RRC Connection request & RRC Connection Setup will be transmitted in SRB0

SRB0:
Direction: UL/DL
RLC - Mode: TM (Transparent Mode)
Logical Channel: CCCH
Logical Channel Group: 0

Messages Transmitted in SRB0:

1. RRC Connection request
2. RRC Connection setup
3. RRC Connection Reestablishment
4. RRC Connection Reestablishment Reject

SRB1:
SRB1 is mapped to DCCH in uplink & downlink. RRC messages & RRC with NAS piggybacked messages prior to the establishment of SRB2 will be transmitted in the SRB1

SRB1:
Direction: UL/DL
RLC - Mode: AM (Acknowledged Mode)
Logical Channel Group: 0

Messages Transmitted in SRB1:

1. RRC Connection setup Complete,
2. RRC Connection Reconfiguration,
3. RRC Connection reconfiguration Complete
4. RRC Connection Re establishment Complete.
5. Security Mode Command &
6. Security Mode Complete,
7. UE Capability Enquiry,
8. UE Capability Information,
9. Measurement reports. etc...

SRB2:

SRB2 is mapped to the DCCH in Uplink & Downlink, but after the integrity & Ciphering protected. All the NAS piggybacked messages for the UE, will be transfered in SRB2 if its present hereafter.

For the SRB2 & DRB's to establish, the AS has to be always Integrity Protected. SRB2 establishment will be taken place with the help of RRC connection reconfiguration coming from E-UTRAN to UE

SRB2:
Direction: UL/DL
RLC - Mode: AM (Acknowledged Mode)
Logical Channel: DCCH
Logical Channel Group: 0

Messages Transmitted in SRB2:

1. UL Information Transfer
2. DL Information Transfer

Note: SRB1 will always have the high priority in transferring the messages over SRB2. LCID is only for DRB's. SRB's will not have the Logical Channel Identity IE.

LTE - BEARERS

LTE - DATA BEARERS

We all know the Default & dedicated bearers established in LTE. Do we know how many such bearers can be established???

Any works only in NAS will say 2 to 11, based on the EPS bearer Identity. If we dig deep across the following specs of NAS, RRC, MAC & UE conformance, we can come to a conclusion that only 8 bearers are successfully established at a time for a UE.

Funda behind the Bearers:

NAS identifies the Bearers based on the EPS - bearer identity which has a range from 0 to 15

In that 0 to 4 are reserved, so 5 to 15 are used for EBI allocation for every bearer that is created.
This counts to 11 from EPC perspective.

From the RRC spec, 36.331 rel 12.3, MaxDRB's per UE = 11

From the RRC spec, 36.331 rel 12.3, LogicalChannelIdentity for DRB = 3 to 10 (Integer values)

Each Bearer will be mapped from NAS/RRC/MAC as EBI/DRB/LCID

Since the LCID in MAC is having the range from 3 to 10, only 8 DRB's can be established per UE @ a time in LTE. So the Limitation comes in the Logical Channel Identity mapping for the data bearers.

From 36.508, DRB configuration is as follows:

If EBI = X + 4; 
Then
DRB ID = X && LCID = X + 2;

Since we have already seen that the Logical Channel Identity range is from 3 to 10, LTE cannot have more than 8 bearers @ a time as of now till Rel 12.3

Hope this helps in better understanding.

LTE - Measurement Reports

LTE - Measurement Reports

We all heard of the word "Handoff". UE moving from the serving cell to a Neighbour cell. 2 Level of functionalities happens here for this process. NAS level control Messages & AS level control Messages.

We see the AS level messages which triggers the Handoff. the Basic Funda behind Handoff is when the Target cell becomes better than the Serving Cell, UE will move on to the better cell for better user experiences.

So How UE will come to know that the Target Cell is better than the Serving Cell? Here comes the Measurement Reports for that purpose. The Measurement reports are carried by the RRC Connection Reconfiguration message in the Connected state.

There are as many as 8 Measurement Events for this purpose. They are classified as Intra-system Handover related events & Inter system Handover related Events.

Intra-system Handover:

This is TAU within the LTE cells moving from source to target. It can be of same frequency or different frequency based on the availability & configuration of the Target Cell.

The measurement Events used for this Handover are A1, A2, A3, A4, A5, A6

A1 - Serving becomes better than Threshold
A2 - Serving becomes worse than Threshold
A3 - Neighbour becomes Offset better than Primary Cell
A4 - Neighbour becomes better than Threshold
A5 - Serving becomes worse than Thresold1 & Neighbour becomes better than Threshold2
A6 - Neighbour becomes Offset better than Secondary Cell


Inter-System Handover:

This is IRAT handover moving from LTE Cell to UMTS Cell or GSM cell based on the availability of the Cell.

The measurement Events used for this Handover are B1 & B2


B1 - Inter RAT neighbour becomes better than Threshold
B2 - Serving cell becomes worse than Threshold1 & Inter RAT neighbout becomes better than Threshold2

All the Thresholds mentioned above are configurable in the E-UTRAN Provisioning file. Once the Events get triggered, Handover happens accordingly.

Spec reference: 36.331, Sec 5.5 Measurements.