Thursday 26 February 2015

19:32 - 1 comment

How LTE UE determines whether LTE Network supports TDD\FDD LTE configuration?

Typically the LTE UE will either support FDD or TDD mode only. The possition, where PSS & SSS signals are transmitted, is different for FDD and TDD mode. During cell search the LTE UE has to locate & receive these signals. This is how the LTE UE knows whether the LTE cell is TDD or FDD cell.

After detection of location of SSS with respect to PSS, UE distinguish about FDD and TDD..
In FDD mode, the PSS is transmitted in the last symbol of slots 0 and 10, while the SSS is sent one symbol earlier.
In TDD mode, the PSS is transmitted in the third symbol of slots 2 and 12, while the SSS is sent three symbols earlier. thus if SSS and PSS are adjacent to each other then it is FDD and if there is two more more symbols between SSS and PSS then it is TDD 

Saturday 31 January 2015

03:43 - 2 comments

Uu Interface


ROHC is robust header compression performed on the IP packet headers in PDCP
Ciphering performed in PDCP
Integrity checking performed in PDCP for RRC messages (and hence
encapsulated NAS messages)
MAC may multiplex several Logical channels to form a single Transport
channel
HARQ performed in MAC

02:04 - No comments

LTE UE Guide

The internal architecture of the user equipment for LTE is identical to the one used by UMTS and GSM which is actually a Mobile Equipment (ME). The mobile equipment comprised of the following important modules:
  • Mobile Termination (MT): This handles all the communication functions.
  • Terminal Equipment (TE): This terminates the data streams.
  • Universal Integrated Circuit Card (UICC): This is also known as the SIM card for LTE equipments. It runs an application known as the Universal Subscriber Identity Module (USIM).
A USIM stores user-specific data very similar to 3G SIM card. This keeps information about the user's phone number, home network identity and security keys etc.

1.) UE Architecture
2.) UE identifiers
3.) UE Categories

Tuesday 25 November 2014

21:48 - No comments

MAC Scheduler - by developer point of view

MAC scheduler:
The MAC scheduler is part of MAC from a logical view and the MAC scheduler should be independent from the PHY interface.
The interface is defined as a service access point offered by the MAC scheduler to the remaining MAC functionality, as shown in below Figure. A _REQ primitive is from MAC to the MAC scheduler. A _IND/_CNF primitives are from the MAC scheduler to the MAC.


Figure shows the functionality split between the MAC scheduler and the remaining MAC. For the purposes of describing the MAC scheduler interface the MAC consists of a control block and a subframe block, which uses the CSCHED and SCHED SAP respectively. The subframe block triggers the MAC scheduler every TTI and receives the scheduler results. The control block forwards control information to the MAC scheduler as necessary. The scheduler consists of the following blocks:
UL Is responsible for scheduling of the PUSCH resources.
DL Is responsible for scheduling of the PDSCH resources.
PDCCH/RACH Is responsible for shared resources between UL and DL.
HARQ Is responsible for handling HARQ retransmissions, keeping track of the number of retransmissions and redundancy versions.
Cell Cfg Stores the UE configuration needed by the MAC scheduler.
UE Cfg Stores the UE configuration needed by the MAC scheduler. LC Cfg Stores the logical channel configuration needed by the MAC scheduler. Sched Cfg Stores the scheduler-specific configuration needed by the MAC scheduler.

CSCHED – MAC Scheduler Control SAP:

CSCHED_CELL_CONFIG_REQ/CNF: 
CSCHED_UE_CONFIG_REQ/CNF:
CSCHED_LC_CONFIG_REQ/CNF:
CSCHED_LC_RELEASE_REQ/CNF:
CSCHED_UE_RELEASE_REQ/CNF:
CSCHED_CELL_CONFIG_UPDATE_IND:
CSCHED_UE_CONFIG_UPDATE_IND:

SCHED - MAC Scheduler SAP:

DL
SCHED_DL_RLC_BUFFER_REQ:
SCHED_DL_PAGING_BUFFER_REQ:
SCHED_DL_MAC_BUFFER_REQ:
SCHED_DL_TRIGGER_REQ:
SCHED_DL_RACH_INFO_REQ:
SCHED_DL_CQI_INFO_REQ:
SCHED_DL_CONFIG_IND:

UL
SCHED_UL_TRIGGER_REQ:
SCHED_UL_NOISE_INTERFERENCE_REQ:
SCHED_UL_SR_INFO_REQ:
SCHED_UL_MAC_CTRL_INFO_REQ:
SCHED_UL_MAC_CTRL_INFO_REQ:
SCHED_UL_CONFIG_IND

Tuesday 11 November 2014

21:39 - 2 comments

LTE RBs and their mapping between PDCP RLC MAC

LTE Radio Bearer



Query:
One UE can have the maximum 11 RB's ( 3 SRB and 8 DRB) as per the 36.331. I have referred like there is a one to one mapping between the RB's and LCID's at MAC level. But we have only LCID's 1 - 10. LCID 1 & 2 for SRB1,SRB2, rest are for DRB's. In this case how can we map among them.

Ans:
if you look closely you will find SRB0 is on CCCH and all others are on DCCH and DTCH . 

And all the data goes through as MAC PDU isn't it and it has a MAC header ,you might have gone through the MAC header which is something like this 
|R |R |E | LCID | 

now LCID has value of 00000 for CCCH which is for SRB0 and the missing DRB which you were not able to map. 

for all other values 00001 to 01010 identity of the logical channels starting from SRB1 till the others. 

Wednesday 8 October 2014

UE Feedback: The Measurement Report - Part 1

As UEs have become smarter and the air interface more complex, the need for more detailed communication between the UE and the network has increased dramatically.  The UE has become the eyes and the ears of the radio access network.  Its main goal is to find the best cell and maximize performance with that cell.

To help the UE accomplish this, the eNodeB gathers several pieces of information from the UE and then adjusts its’ downlink transmissions accordingly. The UE tells the network what cells it can see and how strong it can see them, its current channel conditions, the current state of its’ memory buffer, which antennas should be transmitting in the downlink, how many different transmission streams can be supported simultaneously, acknowledgements when data is received successfully, and any other information that the network wants to know.

This is the first in a series of blogs on these different types of UE feedback.  This blog will focus on the measurement report.  The measurement report is the mechanism used by the UE to tell the network whatever results have been requested. Typically, these are measurements of the surrounding cells.  They can also include requested measurements of block error rate, transmit power and other UE-based parameters. The UE learns the requested information using a measurement configuration.

When a UE is in RRC-CONNECTED mode, this measurement configuration is provided to the UE by means of dedicated signaling; typically using the RRCConnectionReconfiguration message.

The measurement configuration provided to the UE includes the following parameters:

Measurement Objects:  the objects on which the UE shall perform the measurements; i.e. frequencies and cells.  In other words:  who should the UE measure? These include intra- and inter- frequency neighbors, IRAT UMTS neighbors, IRAT GSM neighbors and IRAT CDMA2000 HRPD and 1xRTT neighbors.
Reporting Configurations:  the criteria used by the UE to trigger the transmission of a measurement report and the quantities that the UE includes in the report. In other words: when should the UE send a report?  This trigger can either be periodical or event-based.
Measurement Identities: an identifier that links one measurement object with one reporting configuration.  In other words: the UE needs to keep track of the objects to be measured and their specific triggers.  The measurement identity is used as a reference number in the measurement report.
Quantity configurations: the measurement quantities and associated filtering used for all event evaluation and related reporting per Radio Access Technology.
Measurement gaps:  periods of time that the UE may use to perform measurements while in connected mode.
The UE maintains a single measurement object list, a single reporting configuration list and a single measurement identities list.  Any measurement object can be linked to any reporting configuration of the same RAT type.

As mentioned earlier, a report can be event-triggered or periodical.  An event-based measurement report will be transmitted when the criteria for any of the following events have been met:


A1:  Serving Cell becomes better than a defined threshold

A2:  Serving Cell becomes worse than a defined threshold

A3:  Neighbor cell becomes some offset better than the primary cell

A4:  Neighbor cell becomes better than a defined threshold

A5:  Primary cell becomes worse than a defined threshold and a neighbor becomes better than a second threshold

A6:  Neighbor cell becomes some offset better than the serving cell

B1:  Inter-RAT neighbor becomes better a defined threshold

B2:  Primary cell becomes worse than a defined threshold and inter-RAT neighbor becomes better than a second threshold

Periodical measurement reports are sent based on the reporting configuration.  For instance, it could be configured that the UE report its’ transmit power every 2 seconds or its’ transport channel block error rate every second.  This is operator-specific.

We have discussed the vehicle used by the UE to tell the network what it can see as well as other operator-configured parameters.  Another piece of information that the network needs to be successful is some indication of the channel conditions at the UE.  This will help the network adapt its downlink transmission to match the UE’s capability at that time.   These channel quality indicators or CQI’s will be the subject of the next blog in this series.


Source:  LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (3GPP TS 36.331 version 10.5.0 Release 10)

07:50 - No comments

Why a new control channel in LTE rel 11?

One of the major enhancements in 3GPP Release 11 is the introduction of a new downlink control channel, the Enhanced Physical Downlink Control Channel (EPDCCH). The standardization of the E-PDCCH was necessary to support new features like CoMP, downlink MIMO and the considered introduction of a new carrier type with 3GPP Release 12 all with the intention to support the following goals:
  • Support of increased control channel capacity.
  • Support of frequency-domain ICIC.
  • Achieve improved spatial reuse of control channel resources.
  • Support beamforming and/or diversity.
  • Operate on a new carrier type and in MBSFN subframes.
  • Coexist on the same carrier as legacy Rel-8 and Rel-10 devices.