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


20 comments:

  1. I wonder why "cif - Presence" - parameter is needed, because UE should know that Pcell will have always CIF enabled when any of the SCell has "Cross carrier" - enabled.

    ReplyDelete
  2. The presence of CIF matters when it comes to decoding of PDCCH. PDCCH payload size varies based on whether or not CIF is present.

    ReplyDelete
  3. cif-Presence-r10 thsi IE is present at 2 place-
    1- PhysicalConfigDedicated {
    cif-Presence-r10 BOOLEAN OPTIONAL, -- Need ON
    }
    2- PhysicalConfigDedicatedSCell-r10 ::
    crossCarrierSchedulingConfig-r10 {
    cif-Presence-r10
    }
    }

    If presence of mentioned can srve the purpose at place 1, what is the need of repeating the same IE at place 2?


    ReplyDelete
    Replies
    1. Hi Brajesh,

      Cif-Presence in the first case is to inform the UE about CIF presence on the PDCCH received on the pCell whereas in the second case it is for sCell. CIF presence field is separate for each configured cell

      Delete
  4. It's clear to understand! Thanks.
    Can you give the reference? i.e., specification number?

    ReplyDelete
  5. Hi, Not mentioning cfi-presence field will cause the ue assume the value false?

    ReplyDelete
  6. Hi, Not mentioning cfi-presence field will cause the ue assume the value false?

    ReplyDelete
  7. Hi, Lets assume a simple scenario. CC1 is Cross Schduled to CC0.
    Is it possible :
    CC0 --> own_r10-->cif_presence_r10 = 0 (Can_cif_presence_flag be 0 for CC0 ? )
    CC1 --> other_r10-->schdulingCellId_r10 = x (from 1-7)

    ReplyDelete
    Replies
    1. There is no own-r10 IE for Pcell defined. It is part of CrossCarrierSchedulingConfig-r10 which is only applicable for sCell. As pCell always schedules for itself, "Own" doesn't mean anything.

      On the other hand, cif_presence_r10 could be TRUE in the pCell. So, pCell in addition to carrying its own scheduling could also schedule for some other carriers.

      Delete
  8. Ayok Merapat kepada Kami hanya Di @BOLAVITA Www.Dewasabungayam.com

    ReplyDelete
  9. info menarik dari www.bolavita.pro

    ReplyDelete
  10. Hi,
    is it necessary to do the measurement report before activating the secondsary cells

    ReplyDelete
    Replies
    1. It is up to the network implementation. In the initial deployment days of CA, I have seen a couple of networks and even in IOTs, that sCell addition and activation happens blindly....

      Delete
  11. Can we have Scells with same physical Cell id's but different Scell Index configured to a PCELL in a RRC Connection Reconfiguration message? If yes , what would be the usecase for this situation. Thanks for response in advance

    ReplyDelete
  12. How can i enable cross carrier Scheduling, is there any related parameter? or its enabled by default when activating CA since all signaling parts will be handled by PCell

    ReplyDelete
  13. Thanks For Sharing this valuable content from Smiligence Carrier Option

    ReplyDelete