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

08:32 - No comments

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.

07:47 - 2 comments

LTE data transmissions.

We have seen a lot of terms around when we discuss LTE data transmissions, especially when we get into some of the details of sending data over the PDSCH using multiple antenna techniques. We describe transport blocks as holding the data we're trying to send, but how do they relate to codewords? Assigning bits to different layers can be used to improve reliability or throughput, but are layers the same as antenna ports? Let's have a closer look at what's going on down in the Physical (PHY) Layer.

User data and signaling messages are processed by the PDCP, RLC and MAC layers before being passed down to the PHY layer to be sent over the air. A lot happens to a data packet before PHY gets it, but for the moment, let's just treat the MAC PDU (Protocol Data Unit) that PHY receives from MAC as "data". To PHY, it's just a string of bits anyway. This will be our transport block.

Transport Blocks to Codewords

Query: What does PHY do with a transport block? 

First, it converts the transport block into a codeword. There are a number of steps involved in this process, depending on the length of the transport block:
  • Append a 24 bit checksum (CRC) to the transport block. This CRC is used to determine whether the transmission was successful or not, and triggers Hybrid ARQ to send an ACK or NACK, as appropriate
  • Segment the transport block into code blocks. A code block must be between 40 and 6144 bits long. If the transport block is too small, it is padded up to 40 bits; if the TB is too big, it is divided into smaller pieces, each of which gets an additional 24 bit CRC.
  • Process each code block with a 1/3 turbo coder
  • Reassemble the resulting code blocks into a single codeword

A codeword, then, is essentially a transport block with error protection. Note that a UE may be configured to receive one or two transport blocks (and hence one or two codewords) in a single transmission interval.

Codewords to Layers

PHY then converts each codeword into modulation symbols. For each codeword, PHY must:
  • Scramble the contents of each codeword, using a sequence based on the UE's C-RNTI and the cell's Physical Cell ID (PCI) 
  • Convert the bit sequences into the corresponding modulation symbols (using QPSK, 16QAM or 64QAM) 
  • Assign the modulation symbols to one or more layers, depending on the specific transmission scheme being used

In the case of a single transmit antenna, the last step is pretty simple: the contents of the codeword are mapped to a single layer. For transmit diversity, it's almost as easy: the symbols from the codeword are distributed evenly across the 2 or 4 layers in a round-robin fashion.

In spatial multiplexing situations, things get a little more complicated, since one or two codewords may be distributed across 1, 2, 3 or 4 layers. In brief, here's how the mapping is handled:


The number of layers used in any particular transmission depends (at least in part) on the Rank Indication (RI) feedback from the UE, which identifies how many layers the UE can discern.

Layers to Antenna Ports

The final steps apply any required precoding adjustments and assign the modulation symbols to the physical resources:
  • Apply the required precoding factors to the modulation symbols in each layer
  • Map the precoded symbols to the appropriate antenna ports
  • Assign the modulation symbols to be transmitted on each antenna port to specific resource elements (the subcarriers and symbols within the resource blocks)
  • Generate the final time-domain OFDM signal for each antenna port

Note that the number of layers is always less than or equal to the number of antenna ports (transmit antennas). If there's only one antenna port, then it carries just a single layer. In multiple (2 or 4) antenna situations, though, each antenna port may end up carrying a complicated combination of the symbols from multiple layers. 

for more info you can check out spec 36.211, section 6.3.4 if you really want to dig into the details.

Conclude? One transport block -> one codeword -> one or two layers -> one or more antenna ports. Fortunately, the eNodeB and the UE always know what's going on, even if I have trouble keeping it all straight sometimes.

06:22 - No comments

What is an antenna port and their mapping?

The LTE standard defines what are known as antenna ports. These antenna ports do not correspond to physical antennas, but rather are logical entities distinguished by their reference signal sequences. Multiple antenna port signals can be transmitted on a single transmit antenna (C-RS port 0 and UE-RS port 5, for example). Correspondingly, a single antenna port can be spread across multiple transmit antennas (UE-RS port 5, for example).The LTE standard defines what are known as antenna ports. These antenna ports do not correspond to physical antennas, but rather are logical entities distinguished by their reference signal sequences. Multiple antenna port signals can be transmitted on a single transmit antenna (C-RS port 0 and UE-RS port 5, for example). Correspondingly, a single antenna port can be spread across multiple transmit antennas (UE-RS port 5, for example).

The 3GPP TS 36.211 LTE standard defines antenna ports for the downlink. An antenna port is generally used as a generic term for signal transmission under identical channel conditions. For each LTE operating mode in the downlink direction for which an independent channel is assumed (e.g. SISO vs. MIMO), a separate logical antenna port is defined. LTE symbols that are transmitted via identical antenna ports are subject to the same channel conditions. In order to determine the characteristic channel for an antenna port, a UE must carry out a separate channel estimation for each antenna port. Separate reference signals (pilot signals) that are suitable for estimating the respective channel are defined in the LTE standard for each antenna port. FIG 1 shows the antenna ports defined in the LTE standard in Releases 8,9 and 10.


The way in which these logical antenna ports are assigned to the physical transmit antennas of a base station is up to the base station, and can vary between base stations of the same type (because of different operating conditions) and also between base stations from different manufacturers. The base station does not explicitly notify the UE of the mapping that has been carried out, rather the UE must take this into account automatically during demodulation (FIG 2). As far asThe way in which these logical antenna ports are assigned to the physical transmit antennas of a base station is up to the base station, and can vary between base stations of the same type (because of different operating conditions) and also between base stations from different manufacturers. The base station does not explicitly notify the UE of the mapping that has been carried out, rather the UE must take this into account automatically during demodulation (FIG 2).


Let us consider antenna ports used for PDSCH allocations since they probably have the most variations. Initially, the 89600 VSA's LTE demodulator supported only analysis of PDSCH transmitted on Antenna Ports 0, (0 and 1), (0, 1, 2), or (0, 1, 2, 3). These ports are considered C-RS antenna ports, and each port has a different arrangement of C-RS resource elements. Various configurations are defined that use these C-RS antenna ports, including 2- or 4-port Tx Diversity and 2-, 3-, or 4-port Spatial Multiplexing.


Then beamforming support was added and single-layer PDSCH allocations transmitted on Port 5 could be analyzed. The LTE demodulator has since been enhanced to support the LTE Release 9 which added Transmission Mode 8--Dual-Layer Beamforming (i.e. beamforming + spatial multiplexing)--where PDSCH is transmitted on Antenna Ports 7 and 8 (note that single-layer beamforming in Rel 9 can also use port 7 or port 8 in addition to port 5). In Rel 10 of the standard, the new transmission mode 9 (TM9) added up to 8-layer transmissions using Ports 7-14. TM9 is supported by the LTE-Advanced demodulator.

As Ports 0-3 are indicated by the existence of C-RS, so Ports 5 and 7-14 are indicated by the UE-specific Reference Signal (UE-RS). The following is a table that summarizes the various PDSCH mappings that can be used along with the corresponding reference signal and antenna ports.

In a MIMO or Tx Diversity configuration, each C-RS antenna port must be transmitted on a separate physical antenna to create spatial diversity between the paths. Single-layer beamforming, on the other hand, is accomplished by sending the same signal to each antenna but changing the phase of the each antenna's signal relative to the others. Since the same UE-RS sequence is sent from each antenna, the 89600 VSA can compare the received UE-RS sequence with the reference sequence and calculate the weights that were applied to the antennas to accomplish the beamforming.

Multi-layer beamforming adds some complexity to beamforming by transmitting as many UE-RS sequences as there are layers to allow demodulation of each layer's PDSCH data. The UE-RS sequence for each antenna port is orthogonal to the others, either in time/frequency domain or in the code domain. This can be thought of as beamforming of each layer independently. N-layer beamforming is an extension of dual-layer beamforming and supports up to 8 data layers with the ability to beamform each layer separately.


Saturday, 4 October 2014

02:35 - 2 comments

Scheduling operation in LTE

Basic Scheduling Operations:
- Purpose
* Efficient SCH(Data) Resources Assignments
- Consideration
* Traffic Volume, QoS (Buffer Status, Priority…)
* Channel Condition
- Scheduling Interval
* Dynamic Scheduling by MAC : One TTI (1ms : One Sub-frame)
* Semi-Persistent for VoIP : Multiple TTIs by RRC
- Resource Assignment : PRBs & Associated MCS

Scheduling information: DCI PDCCH


DCI





Resource Assignment
- Per UE # PRBs Assignment
* Channel Dependent Resource Allocation
  •User Assignment based on Channel Quality
- CQI / MCS / TBS


CQI Reporting for Scheduling
Reporting modes


- In time : Periodic (PUCCH/PUSCH) & Aperiodic (PUSCH)
- In Frequency
• Wide-band CQI : 4 bit
• Differential Sub-band CQI : 2 bit (Sub-band CQI – Wideband CQI)
• Differential Spatial CQI : 3bit for MIMO

Schedulers in LTE

DL Scheduling
DL MAC Scheduler


01:26 - 1 comment

MAC Layer

it would be almost impossible to explain everything about MAC but i have tried to simplify MAC by diagram.
lets start to read diagram first and see what MAC does? i have taken diagram from 3GPP TS:36.321 and modified according to me to simplify MAC



MAC Layer
- Mapping between logical channels and transport channels;

Query_1: what kind of channel used for mapping in UE/eNodeB?
UE    -->  Logical channel (CCCH, DCCH and DTCH) <--> Transport Channel (RACH and UL-SCH)
CCCH, DCCH, DTCH are all mapped to UL-SCH.
There is a special channel called 'RACH', but this does not have any corresponding logical channel.
eNodeB -->  Logical channel (PCCH, BCCH, MCCH, MTCH, CCCH, DCCH and DTCH) <--> Transport Channel (PCH, BCH, MCH and DL-SCH)
PCCH (Logical Channel) is mapped only to PCH (Transport channel).
Some BCCH is mapped to BCH and Some BCCH is mapped to DL-SCH. Do you know which one is which ? BCCH for MIB is mapped to BCCH and BCCH for SIB is mapped to DL-SCH.
DL-CCCH, DCCH, DTCH are all mapped to DL-SCH.

 Query_2: What channel modified or what is not modified by MAC?

 from Diagram:
i) All the logical channes (PCCH, BCCH, CCCH, DCCH, DTCH) goes through MAC layer. (too simple reading ? -:)
ii) It seems that PCCH does not get manipulated by MAC in any special way. It just looks as if it is by passing MAC process. It does not use HARQ procedure meaning 'no retransmission' mechanism being used.
iii) CCCH, DCCH, DTCH all go through the same procedure (Prioritization, Mux/DeMux, HARQ).
iv) Some BCCH goes through HARQ, but some BCCH does not go through HARQ. Do you know which BCCH go through HARQ and which does not ? BCCH for MIB does not go through HARQ, but BCCH for SIB go through HARQ. (But this HARQ is a little different from normal HARQ that we know of.. It does not expecting any ACK/NACK response from the reciever.. but perform 'retransmission' based on a predefined rule).
v) Random Access process orignated within MAC layer, it does not have the correspoding logical channel. (This may apply to Msg1, Msg2 of RACH procedure.. Msg3,4,5 involves RRC layer intervention as well).

 Query_3: what kind of information carry channel?
Logical Channels : Type of information
Transport Channels : How the information is transferred


Try to correlate each messages in the call flow with the channel mapping. And the try to correlate this mapping with the diagrams described above. Ask a couple of questions to yourself, e.g which of these message use HARQ ? Which message is carried by a 'Common' channel and which messages are carried by a 'Dedicated' channel.

- Multiplexing of MAC SDUs from one or different logical channels onto transport blocks (TB) to be delivered to the physical layer on transport channels;
- de-Multiplexing of MAC SDUs from one or different logical channels from transport blocks (TB) delivered from the physical layer on transport channels;

Query_4: How data multiplex/de-mux happen?

 - Scheduling information reporting;

 Query_5: How scheduling report?

 - error correction through HARQ;

 Query_6: How error correction happen through HARQ?

- Priority handling between UEs by means of dynamic scheduling;
- Priority handling between logical channels of one UE;
- Logical Channel prioritization

Query_7: how logical channel prioritize

- Transport format selection.

Query_8: how mac select transport format?
Data is sent from the physical layer to the MAC layer in the form of transport channels. The MAC layer is responsible for mapping the transport channels onto logical channels and transmitting the data up to the RLC layer, and thereverse - receiving data on logical channels from the RLC layer and mapping that data onto transport channels for the physical layer. On those channels, MAC layer is also responsible for segmenting long messages from higher layers into blocks, and reassembling blocks from the physical layer into messages for the higher layers.
MAC layer is also responsible for selecting the transport formats used on the transport channels, and distinguishing between different UEs using the common channels.




Every TTI (1ms) a set of Transport Blocks is transferred from the MAC to the Physical layer. The data will be coded and split into blocks to be sent out every 10ms radio frame.
Data from MAC could be sent in a single large Transport Block or in a set of smaller Transport Blocks. The latter approach allows the number of blocks (and hence the data rate) to be varied more simply in each TTI.

Mac Procedure
- Random Access

Query_9: How RACH happen?

- DL-SCH Data Transfer

Query_10: How DL-SCH data transfer?

- UL-SCH Data Transfer

Query_11: How UL-SCH transfer?

 MAC PDU:

MAC Control Element

RNTI


Friday, 3 October 2014

22:28 - No comments

RNTI

RNTI stands for Radio Network Temporary Identifier. As the name implies, it is a kind of Identification number. Normally we use indentification number to differntiate one thing from all other similar things.
Followings are the brief summary of RNTIs being used in LTE. i hope this diagram will clear you about RNTI what kind of RNTI? what type of RNTI? what are the value for RNTI? what is the mapping of RNTI?



Who issues these RNTI ?
Network issues RNTI.

Exactly what does RNTI do for each of those radio channel ? The detailed process differs with the types of RNTIs, but generally speaking all of these RNTI is used to scramble the CRC part of the radio channel messages. It implies that 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.



One of the most common questions that I got about RNTI is "There are a lot of different types of RNTI and I don't see any RNTI information on DCI or Higher layer signaling message. Then how can PHY layer know which RNTI it has to use to decode a data ?". The answer is "MAC or Layer 1 controller would instruct PHY on which RNTI it has to use". Then a next questions comes out. "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 etc.

 How each of RNTI is used ?
Following is the quotes from 3GPP specification showing how RNTI is used for various cases.. for the exact details, you should see the specification but this partial quote would give you a rough idea of the usage of RNTI.

From 3GPP TS:36.212

5.3.3 Downlink control information
  • A DCI transports downlink or uplink scheduling information, or uplink power control commands for one RNTI. The RNTI is implicitly encoded in the CRC. 
5.3.3.1.3 Format 1A
  • Format 1A is used for random access procedure initiated by a PDCCH order only if format 1A CRC is scrambledwith C-RNTI
  • For distributed VRB: .. if the format 1A CRC is scrambled by RA-RNTI, P-RNTI, or SI-RNTI
5.3.3.2 CRC attachment
  • This section explain in detail on how CRC is scrambled by RNTI. Following is the summary of this process. As you see, RNTI is used to scramble CRC bits of PDCCH.

21:58 - 2 comments

MAC PDU Formats

1. A MAC PDU primarily consists of the MAC header and the MAC payload. (it's very simple and general to say)

2. The MAC header is further composed of MAC subheaders, while the MAC payload is composed of MAC Control Elements, MAC SDUs and padding.


•Each MAC PDU corresponds to a single Transport Block (TB)
•There is one sub-header for each MAC Control Element in the PDU and each MAC SDU in the PDU

3. Each MAC subheader consists of a Logical Channel ID (LCID) and a Length (L) field.
4. The LCID indicates whether the corresponding part of the MAC payload is a MAC Control Element, and if not, to which logical channel the related MAC SDU belongs.
5. The L field indicates the size of the related MAC SDU or MAC Control Element.


MAC header consists of multiple sub-headers
•One sub-header for each Control Element, MAC PDU or Padding
•Each sub-header is 1 or 2, 3 bytes in length
–[R/R/E/LCID]: Used for fixed length MAC SDUs and MAC Control Elements
–[R/R/E/LDID/F/Length]: Used for variable length MAC SDUs


MAC Control Elements are used for MAC-level peer-to-peer signalling, including delivery of BSR information and reports of the UE’s available power headroom in the uplink, and in the downlink DRX commands and timing advance commands. For each type of MAC Control Element, one special LCID is allocated. When a MAC PDU is used to transport data from the PCCH or BCCH logical channels, the MAC PDU includes data from only one logical channel. In this case, because multiplexing is not applied, there is no need to include the LCID field in the header. In addition, if there is a one-to-one correspondence between a MAC SDU and a MAC PDU, the size of the MAC SDU can be known implicitly from the transport block size. Thus, for these cases a headerless MAC PDU format is used as a transparent MAC PDU.

12:51 - No comments

MAC Control Element

Seven Control Elements are defined 
4 for DL
•Timing Alignment (8bits): Sent to provide initial and periodic time synchronization to the UE for UL
•DRX Command (8 bits): Initiates discontinuous reception mode at UE
•UE Contention Resolution Identity (48bits): Used during RACH procedure to resolve possible contention b/w multiple UEs trying to simultaneously access the network 
•MCH Scheduling Information MAC Control Element
3 for UL
•UE Buffer Status Reports (8 or 24bits): Reports UE buffer occupancy for UL scheduling
•UE Power Headroom (8 bits): Reports UE transmit power compared to maximum or if the UE is currently power limited
•C-RNTI (16 bits): Identifies a UE when sending information over CCCH

12:43 - 4 comments

How Multiplexing and Logical Channel Prioritization happen in LTE?

The multiplexing and logical channel prioritization is left to the eNodeB implementation, for the uplink the process by which a UE creates a MAC PDU to transmit using the allocated radio resources is fully standardized; this is designed to ensure that the UE satisfies the QoS of each configured radio bearer in a way which is optimal and consistent between different UE implementations. Based on the uplink transmission resource grant message signalled on the PDCCH, the UE has to decide on the amount of data for each logical channel to be included in the newMAC PDU, and, if necessary, also to allocate space for a MAC Control Element.
The Logical Channel Prioritization procedure is applied when a new transmission is performed.
One simple way to meet this purpose is to serve radio bearers in order of their priority. Following this principle, the data from the logical channel of the highest priority is the first to be included into the MAC PDU, followed by data from the logical channel of the next highest priority, continuing until the MAC PDU size allocated by the eNodeB is completely filled or there is no more data to transmit.
RRC controls the scheduling of uplink data by signalling for each logical channel: priority where an increasing priority value indicates a lower priority level, prioritisedBitRate which sets the Prioritized Bit Rate (PBR), bucketSizeDuration which sets the Bucket Size Duration (BSD).
The UE shall maintain a variable Bj for each logical channel j. Bj shall be initialized to zero when the related logical channel is established, and incremented by the product PBR × TTI duration for each TTI, where PBR is Prioritized Bit Rate of logical channel j. However, the value of Bj can never exceed the bucket size and if the value of Bj is larger than the bucket size of logical channel j, it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.
Although this kind of priority-based multiplexing is simple and favours the highest priorities, it sometimes leads to starvation of low-priority bearers. Starvation occurs when the logical channels of the lower priority cannot transmit any data because the data from higher priority logical channels always takes up all the allocated radio resources.
To avoid starvation, while still serving the logical channels according to their priorities, in LTE a Prioritized Bit Rate (PBR) is configured by the eNodeB for each logical channel. The PBR is the data rate provided to one logical channel before allocating any resource to a lower-priority logical channel.
In order to take into account both the PBR and the priority, each logical channel is served in decreasing order of priority, but the amount of data from each logical channel included into the MAC PDU is initially limited to the amount corresponding to the configured PBR. Only when all logical channels have been served up to their PBR, then if there is still room left in the MAC PDU each logical channel is served again in decreasing order of priority.
In this second round, each logical channel is served only if all logical channels of higher priority have no more data for transmission. 
In most cases, a MAC Control Element has higher priority than any other logical channel because it controls the operation of a MAC entity. Thus, when a MAC PDU is composed and there is a MAC Control Element to send, the MAC Control Element is included first and the remaining space is used to include data from logical channels. One exception to this rule occurs when a UE transmits the first RRC message to a target cell during a handover procedure – in this case, a MAC Control Element such as a BSR has lower priority than SRBs. This is because it is more important to complete the handover procedure as soon as possible than to inform the eNodeB of the UE’s buffer status; otherwise, the data transfer interruption time would be longer and the probability of handover failure would increase due to the delayed signalling.

Example:
LTE MAC multiplexing 
LTE MAC multiplexing by way of example. First, channel 1 is served up to its PBR, channel 2 up to its PBR and then channel 3 with as much data as is available (since in this example the amount of data available is less than would be permitted by the PBR configured for that channel). After that, the remaining space in the MAC PDU is filled with data from the channel 1 which is of the highest priority until there is no further room in theMAC PDU or there is no further data from channel 1. If there is still a room after serving the channel 1, channel 2 is served in a similar way. 



Logical Channel Prioritization
The UE shall perform the following Logical Channel Prioritization procedure when a new transmission is performed:
- The UE shall allocate resources to the logical channels in the following steps:
- Step 1: All the logical channels with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a radio bearer is set to “infinity”, the UE shall allocate resources for all the data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio bearer(s);
- Step 2: the UE shall decrement Bj by the total size of MAC SDUs served to logical channel j in Step 1
NOTE: The value of Bj can be negative.
- Step 3: if any resources remain, all the logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.
- The UE shall also follow the rules below during the scheduling procedures above:
- the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources; 
- if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant as much as possible;
- UE should maximise the transmission of data.
The UE shall not transmit data for a logical channel corresponding to a radio bearer that is suspended (the conditions for when a radio bearer is considered suspended are defined in [8]).
For the Logical Channel Prioritization procedure, the UE shall take into account the following relative priority in decreasing order:
- MAC control element for C-RNTI or data from UL-CCCH;
- MAC control element for BSR, with exception of BSR included for padding;
- MAC control element for PHR;
- data from any Logical Channel, except data from UL-CCCH;
- MAC control element for BSR included for padding.

Query: The significance of Bucket size duration(BSD) in logical channel prioritization.
Ans: The BSD is basically used to set the maximum amount of pending data allowed for a logical channel, with respect to the prioritization checks. The more data a logical channel has, the higher its priority tends to be, but it can't exceed the value set by Prioritized Bit Rate x Bucket Size Duration. (e.g. 100 kbps x 1 second = 100 kbits). This keeps a logical channel experiencing a very high burst of data from taking over the transmission and blocking out a lower rate channel. See 36.321, section 5.4.3.1.

 The bucket size duration indicates how much time for transmitting uplink data of a logical channel by using the prioritized bit rate until the bucket size is reached, value in milliseconds.
For a LCID the bucket size = BSD x PBR (both are in MAC config struct) that is the maximum UL data a LCID can buffer. The first time scheduling will happen based on Token bucket model for all LCID's with different priorities. Here every LCID can send PBR amount of data.
Each LCID accumulates BSDxPBR amount of data. The rate of accumulation is PBR * tti upto BSDxPBR.
There is another counter Bj in MAC that is used to make sure that there is no starvation of lower priority LCID's.
The second time on,
If Bj > 0 then higher priority LCID can send RLC data size and reduce Bj accordingly. Other LCID's may or may not be scheduled. If Bj is negative for higher priority LCID then other LCID with lower priority are scheduled.

lRRC IEs LogicalChannelConfig
-                    LogicalChannelConfig
l                    Priority (1 to 16)
l                    PrioritisedBitRate (0kbps to 2048kbps)
l                    BucketSizeDuration (ms50 to ms1000)
l                    LogicalChannelGroup (0 to 3)

Tuesday, 30 September 2014

03:36 - 1 comment

Basic LTE Call Flow

Here, i am trying to describe whole Lte sequence in my way when UE is powered on............................... 

 LTE a terminal must perform certain steps before it can receive or transmit data. These steps can be categorized in cell search and cell selection, derivation of system information, and random access. The complete procedure is known as LTE Initial Access

Successful execution of the cell search and selection procedure as well as acquiring initial system information is essential for the UE before taking further steps to communicate with the network. For this reason, it is important to take a closer look at this fundamental physical layer procedure.

 but I strongly recommend you to try to have some big picture of the whole process. Whenever you have some issues or something for you to work, try to ask your self "Where is the current issue located in the whole picture ?".


Step A: Initial synchronization:
Step A-1: Primary Synchronization Signal
The UE first looks for the primary synchronization signal (PSS) which is transmitted in the last OFDM symbol of the first time slot of the first subframe (subframe 0) in a radio frame. This enables the UE to acquire the slot boundary independently from the chosen cyclic prefix selected for this cell. Based on the downlink frame structure (Type 1, FDD), which is shown in Figure 6, the primary synchronization signal is transmitted twice per radio frame, so it is repeated in subframe 5 (in time slot 11). This enables the UE to get time synchronized on a 5 ms basis, which was selected to simplify the required inter-frequency and inter-RAT measurements.

Query_1: How does UE know to look for the PSS synchronization signal?
Well, UE doesn't need to worry much for this. As, the synchronization signal are always sent only on the center 62 sub carriers irrespective of the  channel bandwidth (1.25,3,5,10,20). Therefore, UE will look for the central sub carriers, i.e at the last OFDM symbol of the 1st time slot and again at the last OFDM symbol of the 11th slot. With this UE synchronizes at the slot level.

Step A-2: Secondary Synchronization Signal
After the mobile has found the 5 ms timing, the second step is to obtain the radio frame timing and the cells’ group identity. This information can be found from the SSS. In the xtime domain, the SSS is transmitted in the symbol before the PSS . The SSS also has 5 ms periodicity, which means it is transmitted in the first and sixth subframes (subframes 0 and 5).


Query_2: How does UE know to look for the SSS synchronization signal?
Once, when the PSS is identified, SSS is always send at the slot before the PSS is present. In other words, SSS immediately precedes the PSS. 

Let's see how the UE derives the Cell ID using these two signals:
From PSS: PHYSICAL LAYER CELL IDENTITY is derived. It carries the value of 0, 1 and 2.
From SSS: PHYSICAL LAYER CELL IDENTITY GROUP is derived. It can take the value to 0 to 167.

Formula: 
Cell ID= (3*PHYSICAL LAYER CELL IDENTITY GROUP) + PHYSICAL LAYER CELL IDENTITY

Step A-3: Downlink Reference Signal
The UE is thus able to become fully synchronized with the radio cell because the reference signals are transmitted in well-defined resource elements. In every sixth subcarrier in the frequency domain a reference symbol from the generated reference signal pattern is transmitted. In the time domain, every fourth OFDM symbol transmits a reference symbol . A resource block contains four reference symbols.


Step B: Broadcast of essential system information
Step B-4: Master information block
From the MIB, UE gets the following information:
  • Channel bandwidth in terms of Resource Blocks
  • SFN (System Frame Number)
  • PHICH configuration (used for HARQ ACK/NACK)
Query_3: How does the UE read MIB?
  • The MIB is transmitted on physical channel (BCCH-BCH-PBCH) and it always occupies the central 72 sub carriers in the Frequency domain irrespective of the channel bandwidth.
  • The first transmission of the MIB is scheduled in sub-frame number 0 of radio frames for which the SFN mod 4 = 0
  • repetitions are scheduled in sub-frame 0 of all other radio frames
Step B-5:  SiB1
i) Cell Access Related Information - PLMN Identity List, PLMN Identity, TA Code, Cell identity & Cell Status
ii) Cell Selection Information - Minimum Receiver Level
iii) Scheduling Information - SI message type & Periodicity, SIB mapping Info, SI Window length

Step B-6:SiB2
i) Access Barring Information - Access Probability factor, Access Class Baring List, Access Class Baring Time
ii) Semi static Common Channel Configuration - Random Access Parameter, PRACH Configuration
iii) UL frequency Information - UL EARFCN, UL Bandwidth, additional emmission


After the above process the UE is synchronized with the network in the Downlink direction and have read SIB1 and SIB 2. Now, it needs to synchronize in the Uplink direction.
The UE cannot start utilizing the services of the network immediately after downlink synchronization unless it is synchronized in the uplink direction too.
Now, RAP (Random Access Procedure) is initiated

There are two types of RAP:
  • Contention based RAP
  • Non-contention based RAP

Typical 'Contention Based' RACH Procedure is as follows :

i) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)
ii) UE <-- NW : Random Access Response (Timing Advance, T_C-RNTI, UL grant for L2/L3 message)
iii) UE --> NW : L2/L3 message
iv) Message for early contention resolution

Typical 'Contention Free' RACH Procedure is as follows :

i) UE <--NW : RACH Preamble Assignment
ii) UE --> NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)
iii) UE <--NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)


Contention based RAP
In contention based, multiple UE's attempt to connect to the network at the same time. The eNB is intelligent enough to tackle this situation because every UE should be unique to the network. 

The UE's can always send the same Preamble ID to the network, thereby resulting on collisions. This kind of collision is called "Contention" and is known as "Contention based" RACH Process. The network would go through additional process to resolve these contention and hence this process is called "Contention Resolution" step. 



Step 1: In the first message the UE provides an indication to the network about it's resource requirement. This carries the Preamble ID, RA-RNTI

Query_4: How does UE gets or selects these parameters:
a. Most of the information is passed on to the UE through SIB2 (click here, to know more about SIB2 parameters)
    i. UE MAC layer has to select the Preamble sequence (Group A or Group B)
    ii. UE will configure itself with the max retires it will try for sending RAP (if it doesn't receive RAR)
   iii. Also, after every retry, how much power level has to be increased for transmitting the RAP
   iv. UE MAC layer constructs the RAP message and passes it to the UE PHY layer. UE PHY layer will transmit this message through PRACH
   v. Once the UE has transmiited the RAP on PRACH, it will start looking for RAR immediately after 3 sub-frames. This number i.e. 3 sub-frame is specified by 3GPP.

Query_5: How long should UE monitor the frames for RAR?
This sub-frame number is again specified in SIB2 and is known as window length; so, after the 3 sub-frames as mentioned above, UE will start looking for RAR in the sub-frames as mentioned by the Window length. If by that time UE doesn't receive RAR, it will go back to transmit RAP 

Step 2. The eNB conveys the resources reserved for this UE along with the Timing Advance (TA), Preamble ID and T-CRNTI (a number generated by eNB and asks the UE to send the RRC connection)
Step 3. UE sends the RRC connection Request using resources given by the eNB. It also sends the identifier (CRI) to the eNB which is used to resolve the Contention.
Step 4. The eNB runs an algorithm and generates C-RNTI which will be a permanent ID for the UE till the connection is alive. The eNB sends the UE identifier. In this step, the UE which has received the ID continues while other UE's will back off and try again.


Scenario:
Multiple UE's attempt to access the network:

1. So, the UEs initiates RACH with same Preamble sequence, RA-RNTI
2. Therefore, the UEs will receive the same T-C-RNTI and resource allocation from eNB
3. All UEs would send msg 3 (RRCconnectionRequest)  message through the same resource allocation to the Network
4. Once, when msg3 is transmitted, two Timers are started:
a. T300 : Transmission of RRCconnectionRequest
b. Contention Resolution Timer: broadcasted in SIB2. If the UE doesn't receive msg4 (Contention Resolution message) within this timer, then it go back to Step 1 i.e. transmitting RAP. If there is a HARQ NACK for msg3 (RRCconnectionRequest) and it has to be re-transmitted then this Contention Resolution Timer will be re-started

Query_6: Now the big question: How should the eNB behave?
1. One: The signals act as interference to each other and eNB decode neither of them. In this case, none of the UE would have any response (HARQ ACK) from eNB and all UE will go back to Step 1.
2. Second: The eNB would successfully decode the message from only one UE and fail to decode from others. The decoded UE will get HARQ ACK from eNB
3. Third: eNB receives msg3 (RRCconnectionRequest) from both the UE's. Here, eNB will send msg4 (Contention Resolution) with MAC CRI (Contention Resolution Identity) to both the UE's. This CRI will carry a reflection of the RRCconnectionRequest as generated by one of the UE. The MAC layer of the UE will match the CRI (as received from msg4) with the CRI embedded in the RRCconnectionRequest. If it matches, then the UE will proceed to decode RRCconnectionSetup and the other UE's will back off and return to Step1, i.e start the RA procedure again.

Contention Resolution process is again of two types:
1. MAC based Contention Resolution
=> C-RNTI on PDCCH 
=> uses the DCCH logical channel 
=> used in HO scenarios
==>The rule is: if the UE has a valid C-RNTI and is going for RA procedure then it will be a MAC based Contention Resolution procedure

2. L1 based Contention Resolution
=> CRI (Contention Resolution Identity) on DL-SCH based 
=> Contention Resolution is addressed to T-CRNTI
=> uses CCCH logical channel
==>The rule is: if the UE doesn't has a valid C-RNTI and is going for RA procedure then it will be L1 based Contention Resolution procedure

Query_6: Exactly when and Where a UE transmit RACH ?
you need to refer to 3GPP specification TS36.211 - Table 5.7.1-2.
Did you open the specification now ? It shows exactly when a UE is supposed to send RACH depending on a parameter called "PRACH Configuration Index".

For example, if the UE is using "PRACH Configuration Idex 0", it should transmit the RACH only in EVEN number SFN(System Frame Number). Is this good enough answer ? Does this mean that this UE can transmit the RACH in any time within the specified the SFN ? The answer to this question is in "Sub Frame Number" colulmn of the table. It says "1" for "PRACH Configuration Idex 0". It means the UE is allowed to transmit RACH only at sub frame number 1 of every even SFN.

Query_7: How does Network knows exactly when UE will transmit the RACH ?
It is simple. Network knows when UE will send the RACH even before UE sends it because Network tells UE when the UE is supposed to transmit the RACH. (If UE fails to decode properly the network information about the RACH, Network will fail to detect it even though UE sends RACH).
Following section will describe network informaton on RACH.
Which RRC Message contains RACH Configuration ?
It is in SIB2 and you can find the details in 3GPP 36.331. 

Query_8:Exactly when and where Network transmit RACH Response
 We all knows that Network should transmit RACH Response after it recieved RACH Preamble from UE, but do we know exactly when, in exactly which subframe, the network should transmit the RACH Response ? The following is what 3GPP 36.321 (section 5.1.4) describes.
 Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes.
 It means the earliest time when the network can transmit the RACH response is 3 subframe later from the end of RACH Preamble. Then what is the latest time when the network can transmit it ? It is determined by ra-ResponseWindowSize. This window size can be the number between 0 and 10 in the unit of subframes. This means that the maximum time difference between the end of RACH preamble and RACH Response is only 12 subframes (12 ms) which is pretty tight timing requirement.

Query_9: Why/when UE send another PRACH? / When/How soon do I have to send the next PRACH?
Backoff Indicator provide the answer to this question. 
Backoff Indicator is a special MAC subheader that carries the parameter indicating the time delay between a PRACH and the next PRACH. (As per 36.321). For example, if the BI field value is 10, Backoff Parameter value is 320 ms. This means UE can send PRACH any time in between 0 and 320 ms from now.
you would notice that BI (Backoff Indicator) field is made up of 4 bits, implying that it can carry the value from 0~15.

BI subheader should always be at the beginning of the whole MAC header. If you see more carefully, you would notice that BI subheader is shown with 'dotted' rectangle. It means that this is optional, implying that the network send or does not send BI depending on the situation.
If you see even more carefully, you would notice that BI subheader does not have any corresponding payload part. It means "Backoff Indicator" information is carried directly by the MAC header/subheader and it doesn't use any payload field.


Subscribe to: Posts (Atom)