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
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.
ReplyDeleteThe presence of CIF matters when it comes to decoding of PDCCH. PDCCH payload size varies based on whether or not CIF is present.
ReplyDeletecif-Presence-r10 thsi IE is present at 2 place-
ReplyDelete1- 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?
Hi Brajesh,
DeleteCif-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
It's clear to understand! Thanks.
ReplyDeleteCan you give the reference? i.e., specification number?
3GPP TS 36.213, 36.300 and 36.331
DeleteHi, Not mentioning cfi-presence field will cause the ue assume the value false?
ReplyDeleteHi, Not mentioning cfi-presence field will cause the ue assume the value false?
ReplyDeleteYes
DeleteHi, Lets assume a simple scenario. CC1 is Cross Schduled to CC0.
ReplyDeleteIs 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)
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.
DeleteOn 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.
Ayok Merapat kepada Kami hanya Di @BOLAVITA Www.Dewasabungayam.com
ReplyDeleteinfo menarik dari www.bolavita.pro
ReplyDeleteHi,
ReplyDeleteis it necessary to do the measurement report before activating the secondsary cells
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....
DeleteMau Banyak Bonus?, Yuk Gabung Disini >> jago bangkok
ReplyDeleteCan 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
ReplyDeleteHow 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
ReplyDeleteThanks u
ReplyDeleteThanks For Sharing this valuable content from Smiligence Carrier Option
ReplyDelete