LTE: Carrier Aggregation - SCell Activation and Deactivation Timings

Use the below calculator for understanding the timing of several actions upon SCell Activation or Deactivation

SCell Activation/Deactivation Details

Activation or Deactivation Activation Deactivation by MAC CE sCellDeactivationTimerExpiry         SFN         subframe 0 1 2 3 4 5 6 7 8 9   

    

If the UE receives an Activation/Deactivation MAC CE in subframe #n activating the SCell, the UE shall apply the below defined actions no earlier than subframe #n+8 and no later than subframe #n+24 or subframe #n+34 (as defined in section 7.7.2 of 36.133)

    ― Transmit SRS on the SCell in case if UL CA and SRS on the SCell is configured;

    ― PDCCH monitoring on the SCell;

    ― PDCCH monitoring for the SCell (Cross Carrier Scheduling);

    ― Start or restart the sCellDeactivationTimer associated with the SCell;

    ― Trigger PHR

    ― CSI reporting for the SCell: The UE should start transmitting valid CSI report no later than subframe #n+24 or #n+34 (as defined in section 7.7.2 of 36.133) but it can report out of range (CQI index = 0) values from subframe #n+8, otherwise the eNodeB has to do blind decoding of PUSCH (if scheduled) from subframe #n+8 till subframe #n+24 or #n+34

If the UE receives an Activation/Deactivation MAC CE in subframe #n deactivating the SCell or if the sCellDeactivationTimer associated with the activated SCell expires in subframe #n, the UE shall deactivate the SCell no later than subframe #n+8.

If the SCell is deactivated, the UE shall apply the following actions:

    ― SRS shall not be transmitted in case if UL CA and SRS on the SCell is configured

    ― The UE shall not transmit UL-SCH on the SCell (UL CA)

    ― PDCCH on/for the SCell shall not be monitored.

    ― The UE shall flush all HARQ buffers associated with the SCell.

    ― The UE shall not transmit RACH on the SCell

    ― Stop the sCellDeactivationTimer associated with the SCell (if running);

    ― The UE shall stop reporting CSI from subframe #n+8 if the sCellDeactivationTimer associated with the SCell expires in subframe #n or if the UE receives an Activation/Deactivation MAC CE in subframe #n deactivating the SCell

Reference: 3GPP TS 36.321, 36.213, 36.331, 36.133, and 36.300

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: PUCCH Frequency Resource Calculator

Select PUCCH Format Format 1 Format 1a/1b Format 2/2a/2b Format 3 Format 1b CS Format 1a/1b SPS Format 1b CS SPS              Bandwidth(MHz)  1.4 3 5 10 15 20        ExtendedCP

nRB-CQI(0..98)         nCS-AN(0..7)         deltaPUCCH-Shift  ds1 ds2 ds3

sr-PUCCH-ResourceIndex(0..2047)             

nRB-CQI(0..98)         nCS-AN(0..7)         n1PUCCH-AN(0..2047) 

nCCE         deltaPUCCH-Shift  ds1 ds2 ds3            

nRB-CQI(0..98)         nCS-AN(0..7)         n1PUCCH-AN(0..2047) 

nCCE         deltaPUCCH-Shift  ds1 ds2 ds3         PCell TM  1 2 3 4         SCell TM  1 2 3 4

n1PUCCH_j (0..2047)         n1PUCCH_j+1 (0..2047)        

nRB-CQI(0..98)         nCS-AN(0..7)         deltaPUCCH-Shift  ds1 ds2 ds3            

N1PUCCH-AN-Persistent(0..2047)             

nRB-CQI(0..98)    nCS-AN(0..7)    N1PUCCH-AN-Persistent(0..2047)

deltaPUCCH-Shift  ds1 ds2 ds3         PCell TM  1 2 3 4         SCell TM  1 2 3 4

n1PUCCH_j (0..2047)         n1PUCCH_j+1 (0..2047)        

cqi-PUCCH-ResourceIndex (0..1184)        

n3PUCCH-AN (0..549)        

How this tool works?

This tool can be used to calculate the Physical Resource Block number (nPRB) to be used for transmission of PUCCH in the Even and Odd slots for PUCCH Formats 1x, 2x, and 3.

Bandwidth must be selected in order to calculate nPRB for all PUCCH formats.

For all PUCCH Format 1x, checkbox ‘ExtendedCP’ can be used to toggle between normal and extended cyclic prefix, the nPRB calculation depends on this selection. For PUCCH Formats 2x and 3, it has no effect.

For all PUCCH Format 1x, deltaPUCCH-Shift, nRB-CQI, and nCS-AN are to be taken from PUCCH-ConfigCommon .

PUCCH formats 1a, 1b, and 1b with channel selection (and no collision with SR) need n1PUCCH-AN (from PUCCH-ConfigCommon) and nCCE (the number of the first (lowest) CCE index).

For the cases where a positive SR is scheduled, sr-PUCCH-ResourceIndex shall be taken from SchedulingRequestConfig .

Use PUCCH Format 1 for calculating nPRB for the following scenarios:

1.    1. Only SR transmission

2.    2. SR and HARQ-ACK collision. The actual PUCCH format used is either 1a or 1b depending upon the number of HARQ-ACK bits but for the calculation of resources in this tool one can use ‘PUCCH Format 1’.

3.    3. SR and HARQ-ACK collision with format 1b for up to 4-bit HARQ-ACK with channel selection. The actual PUCCH format used is 1b with channel selection but for the calculation of resources in this tool one can use ‘PUCCH Format 1’.

In order to calculate nPRB for PUCCH Format 2/2a/2b, cqi-PUCCH-ResourceIndex should be taken from CQI-ReportPeriodic.

For PUCCH Format 3, one n3PUCCH-AN value out of 4 (n3PUCCH-AN-List-r10) should be selected based on the TPC field in the DCI format of the corresponding PDCCH on the SCell.

Similarly, for PUCCH Format 1b with channel selection, one n1PUCCH-AN value out of 4 (n1PUCCH-AN-CS-List) should be selected based on the TPC field in the DCI format of the corresponding PDCCH on the SCell. If Transmission Mode on the SCell is either TM1 or TM2 then n1PUCCH_j is sufficient, but if TM3 or TM4 is used for the SCell, then n1PUCCH_j+1 should also be provided.

For PUCCH formats which transmits HARQ feedback for a PDSCH transmission on the primary cell where there is not a corresponding PDCCH detected (SPS case), instead of nCCE and n1PUCCH-AN, N1PUCCH-AN-Persistent should be used. It is one value out of 4 N1PUCCH-AN-PersistentList which is based on TPC command received in the DCI format indicates a semi-persistent downlink scheduling activation.

Reference: 3GPP TS 36.321, 36.213, 36.331, 36.133, and 36.300

LTE: Resource Allocation Calculator

RAtype  0 1 2             Direction  Uplink Downlink             Bandwidth(MHz)  1.4 3 5 10 15 20         

RIV (Decimal)                                      

Resource Allocation is explained in detail in the post ‘Resource Allocation’.

Uplink Resource Allocation Type 0 indicates to a scheduled UE a set of contiguously allocated virtual resource block indices. This type is explained in the post ‘UplinkResource Allocation Type 0’.

Uplink Resource Allocation Type 1 introduced in Release – 10 is used to indicate a scheduled UE, two sets of resource blocks with each set including one or more consecutive resource block groups.

In the Downlink, Resource AllocationType 0 and Resource Allocation Type 1 are used for non-contiguous resource allocation which uses bit-map based signaling.

Similar to Uplink Type 0, there exists a resource allocation type in Downlink which is Type2.

Limitations:

•     Uplink Resource Allocation Type 1 is not supported yet…

Reference: 3GPP TS 36.213 and 36.212

LTE: Random Access Response MAC PDU Decoder

MAC PDU (RAR)                      

Notes

A MAC PDU which is part of Random Access Response (RAR) consists of a MAC header and zero or more MAC Random Access Responses (MAC RAR) and optionally padding.

The MAC header is of variable size.

A MAC PDU (RAR) header consists of one subheader for each MAC RAR and only on subheader for Backoff Indicator.

The subheader for Backoff Indicator, if included, is always the first subheader.

There can be one or more MAC RARs in the MAC PDU (RAR).

Each MAC RAR has a fixed size of 6 Bytes which consists of 1 reserved bit, 11-bit Timing Advance Command, 20-bit UL Grant, and 16-bit Temporary C-RNTI.

Padding may occur after the last MAC RAR. Presence and length of padding is implicit based on TB size, size of MAC header and number of RARs.

Reference: 3GPP TS 36.321 and 36.213