Saturday, September 12, 2015

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



Wednesday, September 9, 2015

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.

Tuesday, September 8, 2015

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.

Monday, September 7, 2015

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.

Tuesday, August 18, 2015

LTE - RACH Procedure

LTE RACH Procedure

RACH Procedure is the 1st procedure through which UE will send its first Uplink message to the Network element EnodeB. Since its the 1st message sent by UE in UL, its MSG1

1. UE sends Rach Request in MSG1 to EnodeB
2. EnodeB sends Rach Response in MSG2 to UE with Temp_C_RNTI
3. UE sends UE Identification Message in MSG3 to EnodeB
4. EnodeB sends Contention Resolution Message in MSG4 to UE


 UE                                                                          EnodeB


------------------- RACH REQUEST in MSG1 ----------------->


<------------------- RACH RESPONSE in MSG2 ---------------


--------- UE IDENTIFICATION MESSAGE in MSG3 ------->


<--- CONTENTION RESOLUTION MESSAGE in MSG4 --


Note:

Important points to remember about the RACH procedure:

1. RRC connection request will be sent in MSG3 to EnodeB by UE with UE- Identity filled with a Random Value (Random value will be used when the RRC connection Request will be sent for the 1st time by the UE after Switch ON, i.e., UE is not having any identifiers with it.)

2. Once the RRC connection request is received by EnodeB, MSG4 will be sent by the EnodeB MAC  to UE, since MSG4 is a MAC level Message. (All MSG1, MSG2, MSG3, MSG4 are MAC level messages)

3. After RRC connection req is processed, RRC Connection Setup will be sent by EnodeB to UE on Signalling Radio Bearer 0 - SRB0 with a C- RNTI assigned & details to setup the SRB1.

MSG 1:


LTE Random Access Request (MSG1) Report
Version                  = 5
Preamble Sequence        = 25
Physical Root Index      = 129
Cyclic Shift             = 325
PRACH Tx Power           = -44 dBm
Beta PRACH               = 242
PRACH Frequency Offset   = 0
Preamble Format          = 0
Duplex Mode              = FDD
Density Per 10 ms        = 1
PRACH Timing SFN         = 907
PRACH Timing Sub-fn      = 1
PRACH Window Start SFN   = 907
RACH Window Start Sub-fn = 4
PRACH Window End SFN     = 908
PRACH Window End Sub-fn  = 4
RA RNTI                  = 2
PRACH Actual Tx Power    = -44



MSG 2:

LTE Random Access Response (MSG2) Report
Version                 = 1
SFN                     = 907
Sub-fn                  = 6
Timing Advance          = 0
Timing Advance Included = Included
RACH Procedure Type     = Contention Based
RACH Procedure Mode     = Initial Access
RNTI Type               = TEMP_C_RNTI
RNTI Value              = 53



MSG 3:

LTE UE Identification Message (MSG3) Report
Version                   = 1
TPC                       = 3
MCS                       = 1
RIV                       = 302
CQI                       = Disabled
UL Delay                  = Don't Delay
Hopping Flag              = Disabled
SFN                       = 908
Sub-fn                    = 2
Starting Resource Block   = 2
Num Resource Blocks       = 4
Transport Block Size Index = 1
Modulation Type           = QPSK
Redundancy Version Index  = 0
HARQ ID                   = 2

MSG 4:


LTE Contention Resolution Message (MSG4) Report
Version              = 1
SFN                  = 908
Sub-fn               = 7
Contention Result    = Pass
UL ACK Timing SFN    = 909
UL ACK Timing Sub-fn = 1

Thursday, August 6, 2015

LTE - STACKS

LTE - STACKS

Lets see the LTE complete Stack architecture with respect to MME & SGW from the EnodeB. EnodeB is nasically a protocol converter, which converts the messages received from MME with a different set of Stack layers. It Take the NAS messages & encapsulate it to the OTA stack & send it to UE's.

In Downlink, EnodeB receives 3 kind of stack messages.

1. From MME (Control Plane - S1 Interface)
2. From SGW (Data Plane - S1-U Interface)
3. From neighbour EnodeB (Control & Data Plane - X2 interface)

Lets see the Stack between UE, EnodeB & MME



Similarly you can see the Stack between UE, EnodeB & SGW:


The EnodeB to EnodeB stack comprises control & Data Planes in the X2 Interface for carrying the control information & data respectively.

Stack for X2 Interface control plane:

Stack for X2 Interface Data Plane:

I hope the you can understand the complexity in the EnodeB stack & its importance in the LTE architecture.

Wednesday, August 5, 2015

LTE - Terminologies & Explanations

LTE - Terminologies & Explanations

PLMN ID is a Public Land Mobile Network Identifier; serves to PLMN unique identification
PLMN ID (not more than 6 digits) = MCC + MNC

MCC is a Mobile Country Code; assigned by ITU; (3 digits)

MNC is a Mobile Network Code; assigned by National Authority; (2 or 3 digits) If the 2 digit MNC is used, then the PLMN will be like ex: 262-09 for 3 didgit MNC, PLMN is like: 262-009

MSIN (MSISDN) is a Mobile Subscriber Identification Number; assigned by operator; (10 digits)

IMSI is an International Mobile Subsciber Identity; serves to uniquely identify a mobile (LTE) subscriber; not more than 15 digits) IMSI will be 14 digits or 15 digits based on the MNC with 2 digits or 3 digits.
IMSI = PLMN ID + MSIN = MCC + MNC + MSIN

ECGI is an E-UTRAN Cell Global Identifier; serves to identify a Cell in global (globally unique); EPC knows the UE location based of ECGI
ECGI (not more than 52 bits) = PLMN ID + ECI

ECI is an E-UTRAN Cell Identifier; serves to identify a cell within PLMN; (28 bits)
ECI = eNB ID + Cell ID

Cell ID is a CELL identifier; serves to uniquely identify a cell within eNB; (8 bits)

eNB ID is an eNodeB Identifier; serves to identify an eNB within PLMN; (20 bits)

Global eNB ID is a Global eNodeB Identifier; serves to identify an eNB in global (Globally unique); (max 44 bits)
Global eNB ID = PLMN ID + eNB ID

Note: The physical Cell ID is different from the Cell ID mentioned above. The Physical Cell ID is used to decode the enodeB signalling by the UE @ phy layer. The Cell ID mentioned above is used by the NAS & RRC layers for EPC management purposes. The most important use of Phy Cell ID is:

Interference to reference signals from reference signals of other cells is eliminated by Physical Cell Identity

Reference: 3GPP 36.508 - Conformance Testing.

Tuesday, July 21, 2015

LTE - MFBI

MFBI - Multi Frequency Band Indicator

EnodeB will inform UE about Multiple Overlapping bands it supports in the SIB1 message provided if MFBI is enabled in the EnodeB.

Consider an example of Serving Band 4 by an EnodeB in a particular Cell. The corresponding Overlapping Band in the FDD is Band 10.

Frequency info:

Band 4:

DL Bw: 2110 to 2155 Mhz
UL Bw: 1710 to 1755Mhz

Band 10:

DL Bw: 2110 to 2170 Mhz
UL Bw: 1710 to 1770 Mhz

So from the Serving BW's its clear that both the Band 10 & 4 are overlapping each other in a range of 45Mhz

Why MFBI?

Now a UE is trying to latch on the Band 4, But the UE wont support band 10, due to the enabling of MFBI, UE will unknowingly latch on to the Band 10 as well.

Overlapping Bands in FDD & TDD:

E-Utra Operating Bands Overlapping E-Utra Bands Duplex Mode
2 25 FDD
3 9 FDD
4 10 FDD
5 18, 19, 26 FDD
9 3 FDD
10 4 FDD
12 17 FDD
17 12 FDD
18 5, 26, 27 FDD
19 5, 26 FDD
25 2 FDD
26 5, 18, 19, 27 FDD
27 18, 26 FDD
33 39 TDD
38 41 TDD
39 33 TDD
41 38 TDD

Monday, July 20, 2015

PHY - PUCCH

PUCCH - Physical Uplink Control Channel

PUCCH carries uplink control information. PUCCH will never be transmitted along with PUSCH in the same subframe.

There are multiple PUCCH formats: (Source 3GPP spec 36.211 Rel 9)


We will see how PUCCH RB allocation happens in the upcoming blog updates.

RRC STATES

RRC STATES

RRC states in LTE are very simple. Its just 2 states as explained in the 3GPP spec 36.331

1. RRC_IDLE
2. RRC_CONNECTED

RRC_IDLE:

1. A UE specific DRX may be configured by upper layers.
2. UE controlled mobility;
    The UE:
     i. Monitors a Paging channel to detect incoming calls, system information change, for ETWS capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification;
     ii. Performs neighbouring cell measurements and cell (re-)selection;
     iii. Acquires system information
     iv. Performs logging of available measurements together with location and time for logged measurement configured UEs.

RRC_CONNECTED:

Transfer of unicast data to/from UE.

At lower layers, the UE may be configured with a UE specific DRX.
1. For UEs supporting CA, use of one or more SCells, aggregated with the PCell, for increased bandwidth;
2. Network controlled mobility, i.e. handover and cell change order with optional network assistance (NACC) to GERAN;

The UE:
1. Monitors a Paging channel and/ or System Information Block Type 1 contents to detect system
information change, for ETWS capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification;
2.  Monitors control channels associated with the shared data channel to determine if data is scheduled for it;
3. Provides channel quality and feedback information;
4. Performs neighbouring cell measurements and measurement reporting;
5. Acquires system information.

You can find the RRC state change Diagram across LTE/UMTS/GPRS due to inter RAT handovers here:


Source: 3GPP Spec 36.331

DCI

DCI - Downlink Control Information

DCI is transmitted in the PDCCH. It tells the UE how to decode the PDSCH for getting the DL data transmitted to it in the same subframe.

There are many DCI formats which tells specific predefined downlink data formats to be used by UE.

So without decoding the DCI, UE will never come to know about the DL data sent to it by the eNodeB.

What DCI informs to UE?

UE will get the following informations from DCI after successful decoding of the DCI in PDCCH.

1. Number of RB's allocated (This will differ with channel Bandwidth)
2. Modulation & Coding scheme (MCS) used in PDSCH for the DL data.(QPSK or 16QAM or 64QAM)
3. Redundancy version - RV
4. New Data Indicator
5. HARQ process number
6. TPC command for PUCCH

Note: 
Incase of MIMO DCI formats like DCI 2 & 2A, 3 Transport blocks informations will be present in DCI for TB1 & 2. Each contails MCS, RV & NDI informations in it.

CRC added to diff CDI formats is of 16 bits & its scrambled with UE-RNTI.
After that 1/3 Rate matching will happen.

So DCI carries all those above data in it. One quick question which comes to the mind now is? How UE's will come to know whether the DCI is intended for a particular UE?

While the process of encoding, DCI will be padded with the CRC bits scrambled with the UE-RNTI. So, once the UE, descrambles the CRC of DCI, it will come to know whether the intended UE is that or not. If the UE-RNTI passed in DCI CRC not matches with the decoded UE, then UE will simply ignore it.

Different DCI formats:

There are as many as 9 DCI formats as of now in Rel8 3GPP. They are:

DCI - 0
DCI - 1
DCI - 1A
DCI - 1B
DCI - 1C
DCI - 1D
DCI - 2
DCI - 2A
DCI - 3
DCI - 3A

In those formats, DCI 0 is always used to indicate Uplink Data Transmission.

DCI formats 1 to 2A are used to indicate DL data transmission format in PDSCH

DCI formats 3 & 3A are used for Transmit Power Control information for PUCCH & PUSCH.

Sunday, July 19, 2015

PHY - PDCCH

PDCCH - Physical Downlink Control Channel

PDCCH is the most important downlink channel which carries the control information to the UE's. It tells the UE's 2 most important things.

1. Where the Downlink Data is in the current subframe for the UE.
2. Which UE need to transmit the UL data now.

PDCCH is transmitted in PDCCH Quadruplets of 4 RE's each. So 9 PDCCH Quadruplets or 9 REG's comprises 1 CCE

So the number of PDCCH Quadruplets transmitted will differ based on 2 factors.

1. Channel Bandwidth
2. Number of UE's & amount of control information to be sent for each UE.

In general Higher the BW, higher the PDCCH Quadruplets usage. We will see more about the CCE's & DCI carried by the PDCCH in the upcoming blogs.

Important notes on PDCCH:

1. PDCCH will always be carried on 1st the symbol on every subframe.
2. Depending on the PDCCH format, the number of symbols used for PDCCH will change in every subframe.
3. PDCCH format 1, 2, 3 used for all the Channel Bandwidth's. In addition format 4 which uses the 4th OFDM symbol in a subframe is used only in the 1.4Mhz channel BW.
4. PDCCH always uses QPSK modulation.

Saturday, July 18, 2015

PHY - PCFICH

PCFICH - Physical Control Format Indicator Channel

Physical channels carries Control signals as wells as Data signals. PCFICH is the channel which carries the control signals in DL.

PCFICH carries the control format indicator CFI, which will tell about the PDCCH usage. So without decoding the PCFICH, its not possible for the UE to decode the PDCCH & in turn PDSCH.

How PCFICH RE's are allocated?

PCFICH is carried in the 1st OFDM symbol of every Subframe in 4 REG's each having 4 RE's.

So total RE's in a PCFICH = Number of Resource Element groups * Number if RE's per group

                                           = 4 * 4 = 16 RE's in every Subframe

This implies, PCFICH will be carried on the 1st OFDM symbol of every subframe over 16 subcarriers in the frequency domain.

One important info to be noted down is, All the 16 subcarriers are not continuous. Lets see how the Resource Element Grouping made for PCFICH.

PCFICH Positioning:

PCFICH positioning can be identified by the UE, with the help of 2 parameters, which UE already knows about it.

1. CELL ID
2. Channel Bandwidth

Both the parameters UE's would have got it from the PSS & SSS decoding. Now its to make use of it & decode other channels in the treasure hunt.

3GPP Spec 36.211 talks about the PCFICH decoding.


The 4 REG's are mapped to 4 different values calculated from the above formula.

You can find the PCFICH resource allocation in the Grid for the Cell ID = 0 & Ch BW = 1.4 Mhz below:


Similary the REG spacing will differ for different bandwidth. PCFICH plays an important role in the Physical cell allocation of the live LTE network for better cell edge signalling & throughput. we will discuss more about it in the later blogs.

Friday, July 17, 2015

LTE - PSS & SSS

LTE - PSS & SSS

Primary Synchronisation Signal (PSS):

PSS is the signal which is first decoded by the UE to access the LTE Cell. Lets see how the PSS is decoded & where exactly the PSS is transmitted.

1. PSS is always transmitted on 2 slots in every frame.

Slot 0 & Slot 10 will contain the PSS. i.e., 1st slots of Subframe 0 & Subframe 5.

Where it will be tranmitted in the Slots? 

Its always on the last OFDM symbol of the slot. Which means, out of 7 OFDM symbols in a slot, 7th Slot will carry the PSS.

What UE will achieve by decoding PSS? 

1. Subframe synchronisation.
2. Slot synchronisation.
3. Symbol synchronisation.

All three in the Time Domain.

4. To identify the center of the Channel BW in  Frequency Domain,

5. To deduce the PCI from 3 available PCI's

Note: The PSS cannot be used to achieve radio frame synchronisation

Secondary Synchronisation Signal (SSS):

Once the PSS is decoded successfully the next task for the UE is to decode the SSS. So where SSS will come in Radio frame?

SSS will be carried in the 6th OFDM symbol of the Slot 0 & 10. Which means, like PSS, SSS also be tranmitted twice in a Radio Frame, exactly just before the PSS.

What UE will achieve by decoding SSS? 

1. Radio Frame synchronisation.
2. To deduce one of the 168 PCI groups.

So at the End of SSS decoding, UE will come to know the Complete Cell ID.

RE Allocation's for PSS & SSS:

 6 RB's are allocated for PSS & SSS irrespective of the Channel Bandwidth.

So Total RE's = 6 * 12 = 72 Resource Element's.

Out of this 72 RE's, 1st 5 & the Last 5 RE's are not used for Transmissions, i.e., DTX

In case of 1.4Mzh BW, only 6 RB's are present so PSS & SSS will occupy the entire BW.

What will happen if the Channel Bandwidth is 10 Mhz? Where PSS & SSS will occupy?

Since PSS & SSS will occupy the central channel BW, here it will occupy @ the center. IN 10Mhz BW, we have 50 RB's are present.

Total Subcarrier Freq's in 10Mhz = 50 * 12 = 600

So it will start from Subcarrier 264  & end at Subcarrier number 335. Remember the subcarriers starts with 0 to 500 here.

Pls find the Example Pic for PSS & SSS below.




PHY - PBCH

PBCH - Physical Broadcast Channel

PDCH is a downlink only channel. After the successful cell search, UE needs to decode the PBCH to know the few vital informations like

1. System Bandwidth   ------ 3 Bits
2. PHICH information ------- 3 Bits
3. System Frame Number (SFN) ---- 8 Bits

So total 14 Bits of Useful content. Along with that 10 reserved bits added upto 24 Bit Data, comprises a MIB in LTE



MIB will always be carried in the 4 OFDM symbols in the 2nd Slot of the every 10ms frame. So lets calculate the RE's allocated in each MIB in every frame.

Consider the following before we go for the calculations of MIB RE'S.

1. LTE is with FDD with Channel Bandwidth of 10 Mhz.
2. 50 Resource Blocks are supported in the 10Mzh channel Bandwidth.
3. Normal cyclic prefix is followed.

As we know very will, in LTE, 
1 Frame -- 10 ms
1 Subframe -- 1 ms
1 Slot - 0.5 ms

In a time domain, we have 14 OFDM symbols per RB
In Frequency domain, we have 12 Subcarriers per RB

A OFDM symbol in a Time domain mapped with a Single Subcarrier comprise a Resource Element, RE.

So Total available RE's in 1 resource block = 12 * 14 = 168 RE's.

So for a 10Mhz BW, total RE's = 168 * 50 = 8400 RE's

Since, MIB is occupying 4 OFDM symbols in the 2nd Slot in a Frame for 6 RB's, the total Resource Elements allocated for MIB is:

Total RE's for MIB = No of RB's * Number of Subcarriers * Number of OFDM symbols.

                                = 6 * 12 * 4

                                = 288 RE's

So in terms of Bits, how do we calculate? As we know PBCH uses QPSK modulation, it needs 2 Bits to transfer a symbol. 

So, Total number of Bits required to Transmit a MIB = Bits used for QPSK * Number of RE's

                                                                                     = 2 * 288 = 576 Bits



  One more Interesting thing about MIB transmission is about the Duplication Transmissions. Why do we need the Duplicate transmissions? If the UE decodes the MIB in the 1st Frame successfully, why the duplicate Transmission is required for the next 3 Frames?

Example of PBCH decoding for MIB:








LTE - Phy layer

PHY LAYER:

The most interesting part of the LTE is the PHY layer functionality. If any one asks how the bit stearms are carried in PHY layer? I say it by Channels!

The Phy channels posses interesting individuality in its own aspect. what are the channels present? There are many. Few works for UL control & Data, Few for DL control & Data.

Lets discuss about the DL channels 1st...

There are as many as 6 DL channels present in PHY.

1. PBCH
2. PCFICH
3. PHICH
4. PDCCH
5. PDSCH
6. PMCH

What about UL channels in PHY? They are as follows:

1. PUCCH
2. PUSCH

We will see each & every channel in detail in the upcoming pages...

LTE - Overview

LTE - Long term evolution came as a solution for the need of a higher data rates of the internet users. LTE will give a whooping data rate of around 300Mbps in Downlink & 150 Mbps in Uplink. Such a high data rate in DL & UL in our smart phones, tablets will leave us in a merry. But how about looking in to the things which makes it possible? Whats the engineering behind this high end technology? There is a vast change right from UE's to EnodeB's then to the core network elements.

Let's sperate the Topics of research to 3 different elements.

1. Access part
2. Core network
3. ISP & billing.

We will see parallely everyday all the 3 aspects of the buddling technology & its implementations day by day in the most easiest approach. Lets start the game - LTE...