LTE: Multiple Timing Advances for uplink Carrier Aggregation


The Timing Advance related concepts are discussed very much in detail in the post Timing Advance and Time Alignment Timer.
For a UE configured with multiple serving cells in Release-10, the same uplink transmission timing is applied in all serving cells, based on the timing advance on the PCell. This means that base station transceivers of different CCs should be at the same physical location (collocated) to avoid different propagation delays.

In a heterogeneous network (HetNet) for example (as shown below), PCell and a remote radio head (RRH) which are located at different locations (non-collocated) may experience different propagation delays. So, the use of single TA is not practical.

From Release-11 onwards, it is possible to handle CA with CCs requiring different timing advances, for example combining CC from eNodeB with CC from RRH (as shown above) to support non-collocated cells.
Also, support of different uplink transmission timings on different serving cells address the deployment scenario where the propagation delays are different on different serving cells due to e.g. frequency selective repeaters.

It is not practical to maintain TA for each serving cell; instead, it would make sense to group a set of collocated serving cells, so that, the same TA is maintained across all the serving cells belonging to that group. Also, it is very important to have a timing reference cell for the entire group.
In Release-11, Timing Advance Group (TAG) was introduced. A TAG consists of one or more serving cells with the same uplink TA and same downlink timing reference cell. Each TAG contains at least one serving cell with configured uplink, and the mapping of each serving cell to a TAG is configured by RRC.

The TAG containing PCell is called as pTAG (Primary Timing Advance Group). For the pTAG, the UE uses PCell as timing reference.
If a TAG contains only SCells(s), and no PCell, then it is called as sTAG (Secondary Timing Advance Group). In a sTAG, the UE may use any of the activated SCells of this TAG as a timing reference cell, but should not change it unless necessary.

The UE has a configurable timer called timeAlignmentTimer per TAG. This TAG specific timeAlignmentTimer is provided by RRC at the time of sTAG configuration.
E-UTRAN adds or releases sTAG with the help of stag-ToAddModList-r11 and stag-ToReleaseList-r11 respectively and are part of mac-MainConfig in Release-11. 

Configuration of an sTAG includes stag-Id which indicates the TAG of an SCell and a TAG specific timeAlignmentTimer (timeAlignmentTimerSTAG-r11) as shown below.

At the time of SCell addition, the E-UTRAN may optionally indicate the STAG identity for the corresponding SCell.  MAC-MainConfigSCell-r11 is introduced for this purpose and as shown below it only contains STAG-id.


If the field stag-Id is not configured for an SCell (e.g. absent in MACMainConfigSCell), then the SCell is considered to be part of the pTAG.

The number of TAGs that can be configured depends on the TAG capability of the UE.

The UE indicates its support of multiple timing advances using multipleTimingAdvance-r11 under BandCombinationParameters during UE capability transfer procedure.

Initial Uplink Timing Alignment for a sTAG
The initial timing alignment on PCell (or pTAG) can be obtained via UE or eNodeB initiated Random Access (RA) procedure. But the initial UL timing alignment of sTAG is obtained only by an eNodeB initiated RA procedure.

As shown below, the SCell in a sTAG can be configured with RACH resources at the time of SCell addition. These parameters are part of UL configuration under RadioResourceConfigCommonSCell-r10.

In order to establish timing advance for a sTAG, the eNodB may initiate a non-contention based random access (RA) procedure with a PDCCH order that is sent on a scheduling cell of an activated SCell of the sTAG. i.e., the PDCCH order can be received on the same SCell (non-cross carrier scheduling) or on the scheduling cell (cross carrier scheduling with CIF).

It is worth noting that for the pTAG, the PDCCH order reception is and PRACH preamble transmission are only supported on the PCell.
The RA procedure on an SCell shall only be initiated by a PDCCH order which means that UE MAC sublayer cannot initiate RA procedure on SCell in order to obtain TA or for the case of ‘UL data arrival’.

As of Release-11, contention based RA procedure is not supported on SCell.
Upon receiving the PDCCH order, the UE transmits PRACH preamble on the SCell for which the PDCCH order is intended.

The RAR reception takes place on PCell using RA-RNTI in common search space. The grant received in RAR is valid for the SCell on which PRACH preamble was transmitted.
When the UE receives RAR for an SCell, the UE applies the TA Command received in the RAR to the sTAG to which the SCell belongs. As usual, the UE starts or restarts the TimeAlignmentTimer associated with this sTAG.

It is very important to note that the RACH initiation by PDCCH order is only supported for an activated SCell.
When SCell is deactivated, the ongoing Random Access procedure on the SCell, if any, is aborted.

Another difference as compared to the RA procedure on PCell is that, the UE, after transmitting PRACH preamble for maximum number times, shall not indicate RA problem to upper layers and it just considers that the RA procedure was unsuccessful.

Timing Advance Command MAC CE
The timing advance for a TAG (pTAG or sTAG) can also be obtained by means of Timing Advance Command MAC CE. For this purpose, the existing Timing Advance Command MAC CE has been enhanced to signal different TA values for different TAGs.

As shown below, previously reserved values are now modified to indicate a new 2-bit Timing Advance Group Identity (TAG Id). The 6-bit Timing Advance Command field is unchanged compared to Release-8.

Since the TAG Id field is 2-bits, it can only indicate values from 0 to 3. The TAG containing the PCell has TAG Identity 0. So, at most three sTAGs can be configured.
Upon reception of a timing advance command (via RAR or MAC CE) for a TAG, the UE shall adjust uplink transmission timing for PUSCH/SRS for all the serving cells in that TAG. Additionally, if the TAG contains the PCell, then uplink transmission timing for PUCCH on the PCell shall also be adjusted.

Maintenance of Uplink Time Alignment
As explained above, the UE maintains TimeAlignmentTimer per TAG. The TimeAlignmentTimer is used to control how long the UE considers the Serving Cells belonging to the associated TAG to be uplink time aligned.

The UE shall start or restart the TAG associated timeAlignmentTimer when a Timing Advance Command is received in a RAR or MAC CE for the corresponding TAG.
The synchronization status of the UE follows the synchronization status of the pTAG. When the timer associated with pTAG is not running, the timer associated with a sTAG shall not be running.

When the timeAlignmentTimer associated with the pTAG is expired, the UE shall:
-      flush all HARQ buffers for all serving cells belonging to pTAG as well as sTAG;
-      notify RRC to release PUCCH/SRS for all serving cells
-      clear any configured downlink assignments and uplink grants (applicable for PCell only);
-      consider that all the running timeAlignmentTimers (timers for sTAG as well) as expired.

When the TimeAlignmentTimer associated with the sTAG is expired, the UE shall:

-      flush all HARQ buffers for all the serving cells belonging to this sTAG;
-      notify RRC to release SRS for all the serving cells belonging to this sTAG.

The UE shall not perform any uplink transmission on a Serving Cell except the RA Preamble transmission when the TimeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running.

When the timeAlignmentTimer associated with the pTAG is not running, the UE shall not perform any uplink transmission on any Serving Cell except the RA Preamble transmission (only) on the PCell.

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

LTE: Cross-Carrier Scheduling in Carrier Aggregation


Cross-carrier scheduling is an important feature in heterogeneous networks (HetNet) where inter-cell interference is significant when the cells within HetNet are deployed on the same carrier frequency.
The PDCCH, carrying Downlink control information (DCI), must be received by the UEs at the cell edge, so, PDCCH may be transmitted with higher power than the traffic channels. This causes inter-cell interference on the PDCCH of the respective carrier. In CA, cross-carrier scheduling enables the UE connected to different nodes to receive the PDCCH on different carriers to eliminate inter-cell interference on the PDCCH.

Cross-carrier scheduling may also be used to balance the loads from traffic and scheduling across different component carriers.
This technique is also effective in scenarios where scheduling of PDCCH on a carrier which has larger bandwidth compared to the carrier of relatively small bandwidth, due to the fact that carriers with smaller bandwidths have relatively low frequency diversity gain.

Without cross-carrier scheduling, the downlink scheduling assignments on PDCCH are valid for the component carrier (CC) on which they were transmitted.  Similarly, for uplink grants, there is an association between downlink and uplink CCs (provided in cell's system information) such that each uplink CC has an associated downlink CC. Thus, from the uplink–downlink association, the UE will know to which uplink CC the DCI relates to.
With cross-carrier scheduling, the PDSCH is received on a CC other than the one on which PDCCH/EPDCCH is received. Similarly, the PUSCH would be transmitted on an associated CC other than the one on which uplink grant is received.

The cross-carrier scheduling feature is optional for the UE introduced in Release-10. The UE indicates its support of this feature with parameter crossCarrierScheduling-r10 under PhyLayerParameters-v1020 during the UE capability transfer procedure.
Cross-carrier scheduling does not apply to PCell i.e. PCell is always scheduled via its own PDCCH.

As shown in the figure below, cross-carrier scheduling is only used to schedule resources on a Secondary CC without PDCCH.


For each UE, the eNodeB can either enable or disable the cross-carrier scheduling independently for each CC, via RRC signaling.
When cross-carrier scheduling is active, the UE needs to know to which CC a certain DCI relates. The carrier responsible for delivering scheduling information should add an indication in the DCI, which SCell the DCI is intended for.

A new 3-bit Carrier Indicator Field (CIF) is added at the beginning of Release-8 PDCCH DCI formats. Whether CIF is present in a serving cell’s PDCCH DCI or not is configured by eNodeB via RRC signaling. CIF value ‘zero’ indicates PCell, while the other SCell can be addressed with ServCellIndex i.e., CIF value is the same as ServCellIndex.

The cif-Presence-r10 in physicalConfigDedicated (PCell configuration) indicates whether CIF is present in the PDCCH DCI of the PCell.
Similarly, each SCell may be configured with cross-carrier scheduling as part of SCell addition or modification. crossCarrierSchedulingConfig is responsible for this and is part of PhysicalConfigDedicatedSCell.



schedulingCellInfo under crossCarrierSchedulingConfig indicates whether cross-carrier scheduling is enabled or not. If schedulingCellInfo indicates ‘own’, it means that the SCell will be transmitting its own PDCCH i.e., cross-carrier scheduling not enabled. On the other hand, if cross-carrier scheduling is enabled, then schedulingCellInfo indicates ‘other’, which means that some ‘other’ serving cell would be transmitting PDCCH DCI.
The parameter schedulingCellId informs the UE about which cell signals the downlink allocations and uplink grants for the concerned SCell.
As discussed above, when the cross-carrier scheduling is enabled on an SCell, the UE wouldn’t be decoding PDCCH on that SCell, so UE doesn’t need to decode PCIFH on the concerned SCell. This implies that the UE does not know how many OFDM symbols in the beginning of each subframe are used for control data. Hence, this information referred to as pdsch-Start needs to be informed to the UE at the time of activating cross-carrier scheduling.
pdsch-Start is the starting OFDM symbol of PDSCH (data region) for the concerned SCell. Values 1, 2, 3 are applicable when dl-Bandwidth for the concerned SCell is greater than 10 resource blocks, values 2, 3, 4 are applicable when dl-Bandwidth for the concerned SCell is less than or equal to 10 resource blocks.
Also, it is important to note that, when cross-carrier scheduling is active for an SCell, it can only be scheduled by one CC. Considering the same example above, it is not possible for SCell1 to receive scheduling information on PDCCH from both PCell and SCell2.
The common search space is always on the primary cell, but the UE-specific search space can be on the primary cell or on any of the secondary cells.
A UE configured with the CIF for a given serving cell shall assume that the CIF is not present in any PDCCH of the serving cell in the common search space. On the other hand, the UE shall assume that CIF is present in PDCCH located in the UE specific search space.
Reference: 3GPP TS 36.213, 36.300 and 36.331


LTE: Carrier Aggregation - SCell Measurements


In order to configure/add the secondary cell (SCell), the eNodeB can make use of measurement event A3 (Neighbour becomes offset better than PCell).
Once an SCell is added to the set of serving cells (PCell + one or more SCells), the UE can perform measurements on the SCell (and on all the serving cells) without a need for measurement gaps.

The Secondary component carrier may be activated and deactivated by MAC-CE commands as explained in detail here. The applicable performance requirements depend on whether the SCell is activated or deactivated.
When SCell is active, the requirements are similar to that of PCell. On the other hand, the RRC parameter measCycleSCell controls the measurement requirement when the SCell is in deactivated state.


Measurement Event A6
The eNodeB always tries to configure the UE with best cell (radio conditions) as SCell, in order to increase the spectrum efficiency. This is only possible, if the UE can detect and report best cell(s) on the concerned SCell’s carrier frequency.

None of the reporting events until Release-9 are applicable for the UE to detect and report best cell on the SCell’s carrier frequency.
A new measurement event A6 is introduced in Relese-10 for Carrier Aggregation needs.

Measurement event A6 is defined as ‘Neighbour becomes offset better than SCell which is intended for intra-frequency measurement events on SCell's carrier frequency i.e., event A6 compares the neighbor cell(s) and the SCell that are on the same carrier frequency (illustrated below).


The eNodeB, after receiving measurement report with event A6, will likely to release the old SCell and add the best reported cell in the measurement report as the new SCell.
Event A6 is similar to event A3, but event A3 can be used for PCell (intra and inter-frequency) whereas event A6 is used only for SCell (intra-frequency only).

As a result of the addition of the new event A6, ReportConfigEUTRA in Release-10 contains the following structure for event A6.

Supporting of event A6 is optional for the UEs. The UE shall indicate the support for Measurement reporting trigger Event A6 in the field featureGroupIndRel10 (index: 111) in the IE UE-EUTRA-Capabilityv1020-IEs.
An example measurement configuration for event A6 is given here. An example of measurement report event A6 from the UE is shown below.


The eNodeB configures the UE with event A6 only if the concerned SCell is configured. 

The UE shall remove the measId corresponding to event A6 from it's measurement configuration, if the concerned SCell is not configured or released. This procedure is called as ‘Measurement identity autonomous removal’.



Reference: 3GPP TS 36.133 and 36.331

LTE: Carrier Aggregation - Activation and Deactivation of Secondary Cells


To enable reasonable UE battery consumption when CA is configured, an activation/deactivation mechanism of SCells is supported.
If the UE is configured with one or more SCells, the eNodeB may activate and deactivate the configured SCells. Activation/Deactivation does not apply to PCell.

After Configuring/Adding the SCell, as explained here, the SCell is in deactivated state. When the SCell is modified, the UE does not change the activation status.
During Handover, if the same SCell is in use in the target PCell (i.e., SCell is not released during Handover), the SCell in the target Cell in initially in the deactivated state.

There is no explicit activation/deactivation of uplink component carriers whenever a downlink component carrier is activated/deactivated, the corresponding uplink component carrier is also activated/deactivated.

In order for the UE to receive data (PDSCH/PDCCH) on the SCell, it has to be activated which is different from configuring the SCell. If the SCell is deactivated, the UE maintains the configuration provided by RRC but it is not possible to receive either PDCCH or PDSCH.

Activation/Deactivation of Secondary Cell
A typical use case of Activation of the SCell would that the network configures the UE with one or more component carriers (CCs) but deactivate all of them except the Primary CC. When there is a need of more data throughput (for example, there is a huge amount of data to delivered to the UE in the downlink), the network can activate several secondary CCs to maximize downlink throughput.

Another use case could be that if the PCell is fully loaded, the SCell can be activated and the data transfer can be scheduled only on the SCell (Load balancing).
The network can deactivate the SCell when there is no more data to be delivered to the UE or the channel quality of the SCell turning to be bad.

The UE (and the network) can deactivate the activated SCell without explicit signaling which is based on sCellDeactivationTimer. This is the amount of time (in radio frames) the UE has not received any data on the SCell.
SCell Activation is done via MAC Control Element whereas the deactivation mechanism is either by using MAC control element or by the expiry of the sCellDeactivationTimer.

The Activation/Deactivation MAC control element is identified by a MAC PDU subheader with unique LCID: 11011. It has a fixed size and consists of a single octet containing seven C-fields and one R-field (Reserved bit and is set to “0”). Each C-field represents an SCell with SCellIndex which ranges from 1-7.
The MAC control element carries a bitmap for the activation and deactivation of SCells: set to 1 denotes activation of the corresponding SCell, while a bit set to 0 denotes deactivation.

With the bitmap, SCells can be activated and deactivated individually, and a single activation/deactivation command can activate/deactivate a subset of the SCells.
The Activation/Deactivation MAC CE and its subheader are illustrated in the below Figure.


As discussed before, there is another mechanism than MAC CE to deactivate the activated SCell which is the expiry of sCellDeactivationTimer.
RRC may configure the UE with sCellDeactivationTimer which is located in mac-MainConfig-v1020. sCellDeactivationTimer can take values starting from 20ms to 1280ms (20, 40, 80, 160, 320, 640, and 1280ms)

E-UTRAN configures sCellDeactivationTimer only if the UE is configured with one or more SCells. If the field is absent, the UE shall delete any existing value for this field and assume the value to be set to infinity.
UE maintains a sCellDeactivationTimer (as configured by the RRC) timer per configured SCell and deactivates the associated SCell upon its expiry. The same initial timer value applies to each instance of the sCellDeactivationTimer.

If the UE receives an Activation/Deactivation MAC CE in subframe #n activating the SCell, the UE shall start (SCell Activation) or restart (SCell Reactivation) the sCellDeactivationTimer associated with the SCell in subframe #n+8.
If the UE receives PDCCH on the activated SCell indicating an uplink grant or a downlink assignment it shall restart the sCellDeactivationTimer associated with the SCell.

Similarly, if the UE receives PDCCH on the serving cell scheduling the activated SCell (Cross Carrier Scheduling) indicating an uplink grant or a downlink assignment, the UE shall restart the sCellDeactivationTimer associated with the SCell.
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 in subframe #n+8.

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);
― 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 have to perform blind decoding of PUSCH (if scheduled) from subframe #n+8 till subframe #n+24 or #n+34

If the SCell is deactivated, the UE shall apply the following activations:
― 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 (Introduced in Release-11, and the RA procedure on an SCell shall only be initiated by a PDCCH order). When SCell is deactivated, the ongoing RA procedure on the SCell, if any, is aborted
― 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

I have created a tool to display timings of different actions defined above based on the activation or deactivation SFN/subframe. Try this timing calculator here

Watch the following deck for more details and a demo of the timing calculator


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

LTE: Carrier Aggregation - Secondary Cell Addition/Modification/Release


The Secondary Cell (SCell) Addition, Release, and Reconfiguration (Modification) are RRC’s responsibility. RRC configures SCell for CA capable UEs only. RRC’s functionality pertaining to Carrier Aggregation is discussed in this post.

In order for the UE to receive data (PDSCH/PDCCH) on SCell, it has to be activated which is different from configuring the SCell. This activation is done via MAC Control Element.


After Configuring/Adding the SCell, the SCell is initially in deactivated state. When SCell is Modified, the UE does not change the activation status of the concerned SCell.
During Handover, if the same SCell is in use in the target PCell (i.e., SCell is not released during Handover), the SCell in the target Cell in initially in the deactivated state.

Activation/Deactivation of SCells will be discussed in detail in further posts.

SCell Addition/Modification 
SCells can not be added/configured at the time of RRC Connection establishment i.e., there is no provision for SCell addition in the RRC Connection Setup message.
The addition of SCells is performed only when AS security has been activated.


Upon the completion of AS security, the SCell may be added either blindly or after receiving measurement report from the UE indicating that the cell on the carrier frequency used for the SCell is above certain threshold.

SCell is added to the PCell or to a set of serving cells through ‘RRC Connection Reconfiguration’ procedure.
E-UTRAN uses IE sCellToAddModList in RRCConnectionReconfiguration message to add the SCell.
At the time of SCell addition, the eNodeB sends the following information to the UE via RRCConnectionReconfiguration message, a few of which are optional.

SCellIndex: This is used to identify/address the SCell that is being configured/reconfigured/released. If the received SCellIndex is part of the UE’s configuration already, then the UE considers the procedure as SCell Modification. Else if the received SCellIndex is not part of the UE’s configuration, then the UE should consider the procedure as SCell Addition. Based on the UE’s capability, at most four SCells can be configured but the SCellIndex can take values from 1 to 7.
cellIdentification: This is mandatory at the time of SCell Addition and shouldn’t be present at the time SCell Modification. cellIdentification consists of Physical Cell Identity and Downlink Carrier Frequency (EARFCN).

radioResourceConfigCommonSCell: This is a big structure of IEs which is mandatory at the time of SCell Addition and shouldn’t be present if the concerned SCell is being Modified.

When adding a new SCell, radioResourceConfigCommonSCell is used for sending all required system information of the SCell i.e. while in RRC_CONNECTED mode, UEs need not acquire broadcasted system information directly from the SCells.
radioResourceConfigCommonSCell contains downlink configurations such as Downlink Bandwidth, Number of Antenna Ports, List of MBSFN subframe Configurations, PHICH Configuration, PDSCH common configuration, TDD configuration (in case of TDD) etc..
In case of SCells with configured uplink (UL CA), radioResourceConfigCommonSCell contains uplink information such as Uplink Bandwidth, Uplink Carrier Frequency, Uplink Power Control (Common) Information, common information of physical channels, SRS common information etc…
radioResourceConfigDedicatedSCell: This is another big structure of IEs which is mandatory at the time of SCell Addition and is optional otherwise. It contains UE specific (dedicated) configurations for SCell.
radioResourceConfigDedicatedSCell contains downlink dedicated configurations such as information related to Transmission Mode for the SCell, Cross Carrier Scheduling configuration, SCell CSI reference signal information, SCell PDSCH dedicated configuration etc…
E-UTRAN might configure the UE with uplink dedicated configuration as well. This is mandatory in case of UL CA where as it is optional for DL CA. It contains information such as Uplink Transmission Mode for SCell, Uplink dedicated Power Control information, CQI Reporting configuration for SCell, SCell’s dedicated SRS configuration etc…
See an example RRCConnectionReconfiguration message for SCell Addition below. 

As explained above, for an SCell, EUTRAN provides, via dedicated signalling, all system information relevant for operation in RRC_CONNECTED when adding the SCell (radioResourceConfigCommonSCell).

Upon a change of the relevant system information of an already configured SCell, the E-UTRAN releases and subsequently adds the concerned SCell, which may be done with a single RRCConnectionReconfiguration message (sCellToReleaseList and sCellToAddModList are used).
The SI parameter values configured via dedicated signaling may be different than the ones broadcasted in the SIs of the concerned SCell.

Upon receiving in RRCConnectionReconfiguration message the UE first executes SCell Release command (if included in the message) before executing any SCell Addition Command.
At intra-LTE handover, RRC can also add, remove, or reconfigure SCells for usage with the target PCell. Some of the possible scenarios (considering only one SCell) are given below.

― SCell is already configured in the source PCell and the SCell is left modified/ unmodified i.e., same SCell is used even in the target PCell.
― SCell is already configured in the source PCell and the SCell is left released during handover. i.e., release of the existing SCell during handover

― SCell1 is configured in the source PCell and during the handover, SCell1 released and a new SCell (SCell2) is configured for use in the target PCell i.e., change of SCell during handover.
― SCell is not already configured in the source PCell and an SCell is configured during handover for use in the target PCell.

― SCell is not already configured in the source PCell and an SCell is added during handover for use in the target PCell.
― SCell is already configured in the source PCell and UE receives handover command to handover to configured SCell i.e., Handover to SCell. In this case, RRCConnectionReconfiguration message contains SCell Release and also mobilityControlInfo containing carrierFreq and phyCellId which are same as that of SCell.

― SCell is already configured in the source PCell and UE receives handover command to handover to configured SCell and a new SCell is added whose frequency is same as that of source PCell i.e., Swapping PCell with SCell and vice versa. In this case, RRCConnectionReconfiguration message contains SCell Release (SCell1) and also mobilityControlInfo containing carrierFreq and phyCellId which are same as that of SCell1, SCell Addition whose carrierFreq and phyCellId are same as that of source PCell.
SCell can also be added during Handover from another RAT (e.g. GERAN or UTRAN) to E-UTRAN.


SCell Release
SCell is removed from PCell or from a set of serving cells through ‘RRC Connection Reconfiguration’ procedure.

E-UTRAN uses IE sCellToReleaseList in RRCConnectionReconfiguration message to remove/release an already configured SCell.
UE should release all the configured SCells in case if, RRC Connection Re-establishment procedure is initiated (obviously on PCell).

Reference: 3GPP TS 36.331 and 36.300

RNTIs in LTE


What is RNTI?
RNTI stands for Radio Network Temporary Identifier. It is used to differentiate/identify a connected mode UE in the cell, a specific radio channel, a group of UEs in case of paging, a group of UEs for which power control command is issued by the eNodeB, system information transmitted by the eNodeB etc…

There are a several RNTI types in LTE such as SI-RNTI, P-RNTI, C-RNTI, Temporary C-RNTI, SPS-CRNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, RA-RNTI, and M-RNTI. Each RNTI’s usage, its value range etc…are discussed in detail below.

SI-RNTI (System Information RNTI)
SI-RNTI is used for broadcast of system information.

It is a common RNTI meaning that it is not allocated to any UE explicitly.
SI-RNTI is of 16-bit in length and its value is fixed to 65535 (0xFFFF). A single SI-RNTI is used to address SystemInformationBlockType1 as well as all other SI messages.

Broadcast of System Information uses BCCH logical channel which is then mapped to DL-SCH transport channel which intern mapped to PDSCH physical channel. The UEs should know the scheduling information for PDSCH which is carrying System Information. The required scheduling information is contained in DCI (Downlink Control Information) whose CRC is scrambled by SI-RNTI.
DCI Formats which carries scheduling information for System Information are DCI Format 1A and DCI Format 1C in ‘common search space’.

The UE starts decoding PDCCH scrambled with SI-RNTI at the start of SI-Window (for the concerned SI message) until the end of the SI-window, or until the SI message was received excluding the following subframes.
          -  subframe #5 in radio frames for which SFN mod 2 = 0
        - any MBSFN subframes
          -  any uplink subframes in the case of TDD

If the SI message was not received by the end of the SI-window, the UE repeats reception at the next SI-window occasion for the concerned SI message.

P-RNTI (Paging RNTI)
P-RNTI is used by the UEs for the reception of paging.

It is a common RNTI meaning that it is not allocated to any UE explicitly.
P-RNTI is of 16-bit in length and its value is fixed to 65534 (0xFFFE).

Paging message is carried by PCCH logical channel which is mapped to PCH transport channel. The PCH transport channel is mapped to PDSCH physical channel. The eNodeB scrambles PDCCH’s CRC with P-RNTI for transmission of PDSCH that carries paging information.
DCI Formats which carries scheduling information for paging are DCI Format 1A and DCI Format 1C in ‘common search space’.

RA-RNTI (Random Access RNTI)
As part of Random Access procedure, the eNodeB’s MAC generates Random Access Response (RAR) as a response to the Random Access Preamble transmitted by the UE. RAR is transmitted on DL-SCH transport channel which intern is mapped to PDSCH. The eNodeB scrambles PDCCH’s CRC with RA-RNTI for transmission of PDSCH that carries RAR(s).

RA-RNTI can be addressed to multiple UEs, i.e., multiple UEs might decode PDCCH scrambled by the same RA-RNTI.
RA-RNTI unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random Access preamble (explained below).

RA-RNTI is of 16-bit in length and its value is derived from the below equation

RA-RNTI= 1 + t_id+10*f_id
where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0 ≤ f_id< 6).
For FDD there is at most one PRACH resource per subframe f_id = 0 RA-RNTI range is 1 to10 whereas for TDD, the RA-RNTI ranges from 1 to 60.

The values corresponding to the RA-RNTI of a cell’s PRACH configuration are not used in the cell for any other RNTI (C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI or TPC-PUSCH-RNTI).
DCI Formats which carries scheduling information for RAR are DCI Format 1A and DCI Format 1C in ‘common search space’.

Temporary C-RNTI
As part of Random Access procedure, the eNodeB’s MAC generates Random Access Response (RAR) as a response to the Random Access Preamble transmitted by the UE. The MAC RAR contains Temporary C-RNTI.

Temporary C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
During contention based random access procedure, the UE stores received Temporary C-RNTI (received in RAR) and uses it during random access procedure.

The UE shall discard the Temporary C-RNTI value received in RAR during non-contention based random access procedure.
The UE shall use Temporary C-RNTI for scrambling of msg3 (PUSCH corresponding to RAR grant) and it’s retransmissions.

During contention based RA procedure, the UE monitors PDCCH scrambled with Temporary C-RNTI for DCI0 in ‘common search space’ (This DCI0 monitoring is for possible retransmission of msg3).
In downlink, UE Contention Resolution (UE Contention Resolution Identity MAC Control Element) is on PDSCH for which PDCCH will be scrambled by Temporary C-RNTI. This is applicable only if UE has included CCCH SDU (RRC Connection Request or RRC Connection Re-establishment) in Msg3.

DCI Format which carriers scheduling information for Contention Resolution in the downlink can be either DCI Format 1A in ‘Common and UE specific search space’ or DCI Format 1 in UE specific search space’.
The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a C-RNTI. It is dropped by others (for which contention is not successful).

A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI and discards Temporary C-RNTI.

C-RNTI (Cell RNTI)

C-RNTI is a unique identification used for identifying RRC Connection and scheduling which is dedicated to a particular UE.
The eNodeB assigns different C-RNTI values to different UEs. When Carrier Aggregation is configured, same C-RNTI applies to all serving cells.

The eNodeB uses C-RNTI to allocate a UE with uplink grants, downlink assignments, PDCCH orders etc.
The eNodeB also uses C-RNTI to differentiate uplink transmissions (e.g. PUSCH, PUCCH) of a UE from others.

C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
After connection establishment or re-establishment the Temporary C-RNTI (as explained above) is promoted to C-RNTI.

During Handovers within E-UTRA or from other RAT to E-UTRA, C-RNTI is explicitly provided by the eNodeB in MobilityControlInfo container with IE newUE-Identity.
DCI Formats 0 and 1A in ‘Common and UE specific search space’ and DCI Formats 1, 1B, 1D, 2, 2A, 2B, 2C, and 4 in ‘UE specific search space’ will be transmitted on PDCCH with CRC scrambled by the C-RNTI.

The scrambling initialization of PDSCH corresponding to the PDCCHs with DCI Formats 1, 1A, 1B, 1D, 2, 2A, 2B, and 2C is by C-RNTI.
The scrambling initialization of the PUSCH corresponding to the PDCCHs with DCI Format 0/4 and the PUSCH retransmission for the same transport block is by C-RNTI.

SPS C-RNTI (Semi-Persistent Scheduling C-RNTI)
SPS C-RNTI identifies semi-persistent grants/assignments.

SPS C-RNTI is a dedicated RNTI and is configured by RRC. The eNodeB configures the UE with a SPS C-RNTI as part of sps-Config.
The CRC parity bits obtained for the PDCCH payload are scrambled with the SPS C-RNTI for SPS activation, release, re-activation and retransmission.

SPS C-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).
For SPS activation/re-activation/retransmission in downlink DCI Format 1A (‘Common and UE specific search space’) and DCI Formats 1/2/2A/2B/2C (‘UE specific search space’) with PDCCH’s CRC is scrambled by SPS C-RNTI are used. The scrambling initialization of PDSCH corresponding to these PDCCHs and PDSCH without a corresponding PDCCH is by SPS C-RNTI.

For SPS release in downlink, DCI Format 1A (‘common and UE specific search space’) whose PDCCH’s CRC is scrambled with SPS C-RNTI is used.
For SPS activation/re-activation/retransmission/release in uplink, DCI Format 0 (‘common and UE specific search space’) with PDCCH’s CRC is scrambled by SPS C-RNTI is used. The scrambling initialization of this PUSCH corresponding to these PDCCHs and PUSCH retransmission for the same transport block is by SPS C-RNTI. The scrambling initialization of initial transmission of this PUSCH without a corresponding PDCCH and the PUSCH retransmission for the same transport block is by SPS C-RNTI.

UE monitors SPS C-RNTI only on PCell.

TPC RNTI (Transmit Power Control RNTI)
TPC RNTI is used for uplink power control purpose. There are two types, TPC-PUSCH-RNTI and TPC-PUCCH-RNTI.

Normally TPC RNTI is assigned to a group of UEs. The eNodeB may configure the UE with TPC-PUSCH-RNTI and TPC-PUCCH-RNTI.
TPC-PUSCH-RNTI/TPC-PUCCH-RNTI is of 16-bit in length and its value can range from 1 to 65523 (0x0001 to 0xFFF3).

DCI format 3/3A (‘common search space’) whose CRC is scrambled with TPC-PUCCH-RNTI is used for the transmission of TPC commands for PUCCH.
DCI format 3/3A (‘common search space’) whose CRC is scrambled with TPC-PUSCH-RNTI is used for the transmission of TPC commands for PUSCH.

DCI format 3 is used for the transmission of TPC commands for PUCCH and PUSCH with 2-bit power adjustments.
DCI format 3A is used for the transmission of TPC commands for PUCCH and PUSCH with single bit power adjustments.

The notation 3/3A implies that the UE shall receive either DCI format 3 or DCI format 3A depending on the configuration.

M-RNTI (MBMS RNTI)

Indication of an MBMS specific RNTI, the M-RNTI, on PDCCH is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about an MCCH information change.
The DCI format 1C (‘common search space’) with M-RNTI is used for notification and includes an 8-bit bitmap to indicate the one or more MBSFN Area(s) in which the MCCH change(s).

M-RNTI is of 16-bit in length and its value is fixed to 65533 (0xFFFD).
Reference: 3GPP TS 36.211, 36.213, 36.321, and 36.331