LTE: TDD Timing Calculator

Uplink/Downlink Config  0 1 2 3 4 5 6                          ttiBundling                        

pdschSF       dci0SF       phichSF        puschSF      ulIndex      Iphich
0 1 2 3 4 5 6 7 8 9           0 1 2 3 4 5 6 7 8 9           0 1 2 3 4 5 6 7 8 9           0 1 2 3 4 5 6 7 8 9           01 10 11           0 1

Select type Display_UL_DL_Configuration Uplink_AckNack_SF PUSCH_for_DCI0 PUSCH_for_PHICH PHICH_SF        

There have been many requests to post some sort of timing calculator for TDD. With TDD, it is often troublesome to refer to multiple tables from different specifications to calculate the subframe in which a specific procedure happens, for instance, the uplink HARQ-ACK timing.

I tried to include the most important timing calculations as of now. I will work to enhance this tool further when I find time.

How this tool works?

The intended purpose or the functionality needs to be selected first (from “Select Type” drop-down). It is mandatory to select UL/DL Configuration for any type of calculation. The purpose of each type of calculation is explained below.

Display_UL_DL_Configuration:

This option just displays uplink/downlink subframe configuration and Downlink-to-Uplink switch-point periodicity from Table 4.2-2 of 3GPP TS 36.211.

Uplink_AckNack_SF:

This option is to calculate the subframe in which HARQ feedback is transmitted in the uplink upon detection of a PDSCH transmission or a PDCCH indicating SPS release in the subframe which is selected from the drop-down labelled as “pdschSF”.

The timing is calculated from Table 10.1.3.1-1 in 3GPP TS 36.213.

PUSCH_for_DCI0:

The purpose here is to calculate the subframe in which PUSCH is transmitted upon detection of PDCCH with uplink DCI format in the subframe which is selected from the drop-down labelled as “dci0SF”.

The timing of PUSCH is calculated from Table 8-2 in 3GPP TS 36.213. For UL/DL Configuration 0, the timing also depends on UL Index received in the corresponding DCI which is selected from the drop-down labelled as “ulIndex”.

In case if TTI Bundling is used, the indicated PUSCH subframe is the first subframe in the bundle.

PUSCH_for_PHICH:

The purpose here is to calculate the subframe in which PUSCH is transmitted upon detection of PHICH in the subframe which is selected from the drop-down labelled as “phichSF”.

In case if TTI bundling is not used, the timing of PUSCH is calculated from Table 8-2 in 3GPP TS 36.213.

In case if TTI Bundling is used, the calculations are done using Table 8-2 and Table 8-2a in 3GPP TS 36.213. The indicated PUSCH subframe is the first subframe in the bundle.

For UL/DL Configuration 0, the timing of PUSCH also depends on I_PHICH value which is selected from the drop-down labelled as “Iphich”.

PHICH_SF:

This option is to calculate the subframe in which HARQ feedback is received (on PHICH) for PUSCH transmission in the subframe which is selected from the drop-down labelled as “puschSF”.

When TTI Bundling is used, select puschSF such that it is the last subframe in the PUSCH bundle.

The timing is calculated from Table 9.1.2-1 in 3GPP TS 36.213 but it is same as using Table 8.3-1 and I_PHICH.

Reference: 3GPP TS 36.211 and 3GPP TS 36.213

LTE Feature Group Indicators Decoder

Feature Group Indictor (FGI) is a bitmap field within UE-EUTRA-Capability IE of UE Capability Information uplink message. FGI is a BIT STRING of size 32 bits, where each bit represents a functionality/feature.

FGI information is important for the eNB or MME before setting up any procedure or enabling a specification functionality.

The UE shall set a specific indicator (bit) to one (1) only if all functionalities for a feature group have been implemented and tested. If any one of the functionalities in a feature group have not been implemented or tested, the UE shall set the indicator as zero (0).

The UE shall set all indicators that correspond to RATs not supported by the UE as zero (0)

3GPP TS 36.331 specifies featureGroupIndicators and featureGroupIndRel9Add in Annex B.1 for release-8 and release-9 capabilities respectively. For release-10 and later, featureGroupIndRel10 is specified in Annex C.

The UE shall include the fields featureGroupIndicators in the IE UE-EUTRA-Capability, featureGroupIndRel9Add  in the IE UE-EUTRA-Capability-v9a0 and featureGroupIndRel10 in the IE UE-EUTRA-Capabilityv1020-IEs.

The FGI field is optional and the UE shall not include FGI bitmap field if the UE supports (implemented and tested) all the functionalities associated with that indicator.

There is not much information to share on this topic. The main intention behind this post is to implement a decoding tool for FGI as there have been several requests.

Reference: 3GPP TS 36.331

FGI Decoding Tool

The following tool has two functionalities.

• Decode the bit or hex string to present the support (‘Supported’ or ‘Not Supported’) for each feature group.
• Display 3GPP definitions table for all 3 FGI releases individually or all at once.

Example bit string: 11111110 00101101 11011000 10000000

Example hex string:  FE0DD880

Note: Spaces are allowed…

Seems like my HTML code has some issues with Internet Explorer, so please use either Google Chrome or Firefox which are tested OK.

Feature Group Indicator                           data               
featureGroupIndicators featureGroupIndRel9Add featureGroupIndRel10 featureGroupAll     

                 

LTE: Carrier Aggregation based ICIC

In a Heterogeneous network (HetNet), terminals in Cell Range Extension (CRE), zone would experience severe interference from the aggressor cells. Aggressor cell could be a macro cell in case of macro-pico or a femto cell in case of macro-femto scenario. A number of features added to the 3GPP LTE specifications to mitigate the above mentioned interference problem in HetNets with small cells. Inter-cell interference coordination (ICIC) has the task to manage radio resources such that inter-cell interference is kept under control.

ICIC is discussed in detail in the earlier post. It is introduced in 3GPP Release-8 specifications to mitigate interference on traffic channels only. Moreover, only frequency domain ICIC was prioritized which manages PRBs, such that multiple cells coordinate use of frequency domain resources. The major problem here is the interference introduced by downlink control channels.

The enhanced ICIC (eICIC) is introduced in 3GPP LTE Release-10 to deal with interference issues in HetNets, and mitigate interference on traffic and control channels. The major change in eICIC is the addition of time domain ICIC. Time domain ICIC is realized through the use of Almost Blank Subframes (ABS). For the detailed discussion, check the post eICIC.

Another approach is based on carrier aggregation (CA) with cross-carrier scheduling which is mainly frequency domain ICIC. The main difference as compared to frequency domain ICIC introduced in Release-8 is that the CA based ICIC would work with control channels (PCFICH, PHICH, and PDCCH) as well.

Carrier Aggregation based ICIC

Carrier aggregation (CA) is one of the most important LTE-Advanced features introduced in Release-10. With CA, two or more component carriers (CCs) are aggregated in order to support wider transmission bandwidths up to 100MHz. A UE may simultaneously receive or transmit on one or multiple CCs depending on its capabilities.

When CA is configured, the UE only has one RRC connection with the network. The serving cell managing the UE’s RRC connection is referred to as the Primary Cell (PCell). Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells.

In CA, a UE may be scheduled via PDCCH over multiple serving cells simultaneously. Cross-carrier scheduling with the Carrier Indicator Field (CIF) allows the PDCCH of a serving cell to schedule resources on another serving cell. In other words, a UE receiving a downlink assignment on one CC may receive associated data on another CC.

Cross-carrier scheduling is an important feature in HetNets where inter-cell interference is significant when the cells within HetNet are deployed on the same carrier frequency. It is discussed in detail in the post cross-carrier scheduling.

A number of HetNet deployment scenarios are presented by means of CA based ICIC. A promising approach is explained below by using a macro-pico example. The basic idea is to split the available spectrum into two downlink CCs denoted as CC1 (f1) and CC2 (f2), both CCs are available in both Macro and Pico layers. Macro layer configures PCell on f1 and SCell on f2 whereas, pico cell configures PCell on f2 and SCell on f1.

As shown in the figure above, three regions are of interest for control signalling (PCFICH, PDCCH, and PHICH); macro cell-center region, pico cell’s CRE region, and pico cell-center region. In the macro cell-center region, both f1 and f2 can carry control signalling. In the CRE region, macro-cell wouldn’t transmit control signalling on f2 i.e., scheduling assignments for SCell are carried by PCell on f1. So, interference caused by control signalling is minimized on f2 in CRE region.

Now, let us look at how pico cell is transmitting. Similar to macro cell, in the pico cell-center region, control signalling is transmitted on both f1 and f2. In the pico cell’s CRE region, pico cell would be transmitting control signalling only on f2 (PCell) and no transmission of control signalling on f1. i.e., scheduling assignments for SCell are carried by PCell on f2. This minimizes the interference in CRE zone which is caused by control signalling from pico cell on f1.

The downside with cross-carrier scheduling is that it will increase the load in the control region of the cell that is scheduling for another cell. This is due to the fact that the scheduling cell has to accommodate resource allocation for PDCCH for both PCell and SCell. In Release-11, a new channel known as Enhanced Physical Downlink Control Channel (EPDCCH) is introduced. This increases the control channel capacity as EDPCCH uses the same resources as PDSCH instead of control region. The EPDCCH could be used for resource allocation within each SCell without using cross-carrier scheduling. Moreover, by applying frequency domain ICIC, the reliability of receiving EPDCCH could be increased as in the case of PDSCH.

So far, the discussion was about control channels only. For data channel (PDSCH) both carriers (f1 and f2) are available in all three regions discussed above. The interference between macro and pico layers is handled by conventional ICIC method which is based on X2 signaling of RNTP between macro and pico eNBs as discussed in the post ICIC.

LTE: Further enhanced Inter-Cell Interference Coordination: FeICIC

Cell Range Extension (CRE), Inter-Cell Interference Coordination (ICIC) and Enhanced Inter-Cell Interference Coordination (eICIC) were discussed in previous posts. FeICIC which is introduced in Release-11 will be discussed in detail in this post.

Introduction

The main idea behind CRE is to offload more traffic from macro cells to small cells and also to increase the HetNet efficiency. The range of the small cell is expanded by implementing a selection offset (UEs in idle mode) or handover threshold in measurement configuration (UEs in connected mode) in the favor of the small cell. A major problem is that, the UEs in CRE zone are forcibly being served by the small cell, but in reality, the downlink received power from the macro cell is higher than the small cell. So, there will be a severe downlink interference from the macro cell to UEs being served by the pico cell.

A number of features added to the 3GPP LTE specifications can be used to mitigate the above-mentioned interference problem in HetNets with small cells. Inter-cell interference coordination (ICIC) has the task to manage radio resources such that inter-cell interference is kept under control.

ICIC is introduced in 3GPP Release-8 specifications to mitigate interference on traffic channels only. Only frequency domain ICIC was prioritized which manages radio resources, notably the physical resource blocks (PRBs), such that multiple cells coordinate use of frequency domain resources. Support for X2 signalling is added for the co-ordination between cells that belongs to two different eNBs. The frequency domain ICIC doesn’t provide significant gain in Heterogeneous Networks (HetNets). This is due to the fact that with ICIC the provided Range Extension is limited as it applies only to data channels and not to control channels where interference can remain significant.

The enhanced ICIC (eICIC) is introduced in 3GPP LTE Release-10 to deal with interference issues in HetNets, and mitigate interference on traffic and control channels. eICIC feature increases the coverage area of the victim cells without boosting downlink power. While ICIC coordinates inter-cell interference in the frequency and power domains, eICIC coordinates inter-cell interference in time, frequency and power domains. The major change in eICIC is the addition of time domain ICIC. Time domain ICIC is realized through the use of Almost Blank Subframes (ABS). ABSs are subframes with reduced transmit power including no transmission on some physical channels and/or reduced activity.

Further enhanced Inter-Cell Interference Coordination (FeICIC)

The eICIC scheme introduced in Release-10 did not address interference caused by cell-specific reference signals (CRS), synchronization signals, broadcast and paging messages as these signals are still transmitted by aggressor cell even during ABS. These signals and messages were necessary even during ABS in order to ensure backward compatibility with Release-8/9 UEs.

The major issue with eICIC is that, in CRE region the interference from CRS of aggressor cell (even during ABS). This makes demodulation of data (PDSH) and control channels/signals (PSS/SSS, PBCH, CRS) from victim cell (pico cell) very difficult.

ICIC is evolved in LTE 3GPP Release-11 to Further enhanced ICIC (FeICIC). The focus here is interference handling by the UE through inter-cell interference cancellation. With FeICIC the cell expansion is spread even further by increasing the biasing level from approximately 6dB to more than 9dB. Increase in bias, further extends small cell’s CRE therefore HetNet efficiency is improved.

FeICIC is mainly implemented at the UE side. The UE’s receiver first estimates the interfering signal and then removes/subtracts the interference from the received signal. In order for the UE’s receiver to apply interference cancellation, the UE needs to be assisted by the serving eNB with some information pertaining to the aggressor cell. For each interfering cell, the following CRS assistance information is signalled to the UE.

-   Physical Cell ID

-   Number of Antenna ports

-   MBSFN subframe configuration

With the help of CRS assistance information for each interfering cell, the UE can determine the location and the sequence of interfering CRS. MBSFN configuration is also important as there is no CRS transmitted in the data region in MBSFN subframes.

Furthermore, the UE may use CRS assistance information to mitigate CRS interference while performing RRM/RLM/CSI measurements. These measurements are discussed in detail in eICIC post.

RRC signaling support

In Release-11, a couple of new UE capabilities (shown below) are introduced to inform the eNB that the UE is capable of performing interference cancellation.

The UE’s support of interference handling for CRS is indicated by the parameter crs-InterfHandl whereas ss-CCH-InterfHandl indicates support for synchronization signal and common channel interference handling.

As discussed already, the eNB may send CRS assistance information of the aggressor cells to the UE to aid the UE to mitigate the interference from CRS of the aggressor cells. In Release-11, RadioResourceConfigDedicated may optionally include neighCellsCRS-Info-r11 which is used to send CRS assistance information of one or several aggressor cells as shown in the figure below.

SIB1 via dedicated RRC signalling

With FeICIC, the UE in CRE with 9dB bias, it is expected that the UE may not be able to decode SIB1 as the interference from aggressor cell is very high. One could argue that the interference is equally applicable for MIB, SIB1 and SIB2 which is the most important system information in LTE.

MIB is transmitted on PBCH in subframe#0 of every radio frame (including repetitions) so it encounters a strong interference from aggressor cell’s MIB and other signals. A UE supporting interference cancellation of common channels (UE indicates with ss-CCH-InterfHandl) could easily mitigate this interference problem.

SIB2 and all other SIBs (except SIB1) are scheduled within periodically occurring SI-windows using dynamic scheduling. So, the serving cell can easily schedule these SIBs in protected subframes (aggressor cell’s ABS).

SIB1 uses a fixed schedule. SIB1 and its repetitions are usually transmitted on PDSCH in subframe#5 of a radio frame for which SFN mod 2 = 0 (even radio frames). It is really difficult to avoid or cancel the interference when the subframe overlaps with a non-protected subframe. For this reason, in Release-11, the eNB may provide SIB1 to the UE in the CRE region by a dedicated RRC signaling. A new IE (shown below) systemInformationBlockType1Dedicated-r11 is introduced for this purpose.

Reference: 3GPP TS 36.300, 36.331, 36.101, 36.133, HetNet