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.


Subscribe to: Posts (Atom)