Carrier Aggregation Feature Parameter Description: Issue Date
Carrier Aggregation Feature Parameter Description: Issue Date
Issue Draft A
Date 2020-12-29
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: https://www.huawei.com
Email: [email protected]
Contents
1 Change History.........................................................................................................................1
1.1 eRAN17.1 Draft A (2020-12-29)........................................................................................................................................ 1
3 Overview....................................................................................................................................6
3.1 Background................................................................................................................................................................................ 6
3.2 Classification............................................................................................................................................................................. 6
3.3 Intra- and Inter-eNodeB CA................................................................................................................................................. 7
3.3.1 Intra-eNodeB CA Scenarios.............................................................................................................................................. 7
3.3.2 Inter-eNodeB CA Scenarios.............................................................................................................................................. 9
4 General Principles................................................................................................................. 10
4.1 Related Concepts.................................................................................................................................................................. 10
4.2 Protocol Stack Architecture............................................................................................................................................... 11
4.3 CA-related Events................................................................................................................................................................. 12
4.4 Configuration Modes........................................................................................................................................................... 15
4.5 Band Combinations.............................................................................................................................................................. 19
4.5.1 3GPP-defined Band Combinations.............................................................................................................................. 19
4.5.2 Private Band Combinations............................................................................................................................................19
4.5.3 Network-requested CA Band Combination Capability Signaling......................................................................23
4.6 Carrier Management for RRC_CONNECTED UEs....................................................................................................... 30
4.6.1 PCC Anchoring.................................................................................................................................................................... 31
4.6.1.1 Triggering Conditions....................................................................................................................................................32
4.6.1.2 CA-Group-based PCC Anchoring Procedure......................................................................................................... 33
4.6.1.3 Adaptive PCC Anchoring Procedure......................................................................................................................... 35
4.6.2 PCC Anchoring Enhancement....................................................................................................................................... 37
4.6.2.1 CA-Group-based PCC Anchoring Procedure......................................................................................................... 38
4.6.2.2 Adaptive PCC Anchoring Procedure......................................................................................................................... 38
4.6.3 SCell Management............................................................................................................................................................ 39
4.6.3.1 SCell Configuration........................................................................................................................................................40
4.6.3.1.1 Triggering Conditions................................................................................................................................................ 40
18 Parameters......................................................................................................................... 323
19 Counters.............................................................................................................................. 324
20 Glossary............................................................................................................................... 325
21 Reference Documents...................................................................................................... 326
1 Change History
Editorial Changes
● Added the statement that the scenarios of PCC anchoring for CA UEs vary
depending on the setting of the CaTrafficTriggerSwitch option. For details,
see 4.6.1.1 Triggering Conditions in 4.6.1 PCC Anchoring.
● Added the impacts of the CPU usage of the BBP on the SCell configuration
procedure. For details, see 4.6.3.1.1 Triggering Conditions in 4.6.3.1 SCell
Configuration.
● Revised the thresholds for events A4 and A2. For details, see 4.6.3.1.2 CA-
Group-based SCell Configuration Procedure, 4.6.3.1.3 Adaptive SCell
Configuration Procedure, and 4.6.3.6 SCell Removal.
● Added the impact relationship with flexible bandwidth based on overlapping
carriers and with compact bandwidth. For details, see 5.2.2 Impacts in 5
Downlink 2CC Aggregation.
● Added the MML-based configuration procedure for baseband interconnection
scenarios. For details, see 12.4.1.2 Using MML Commands in 12 Downlink
FDD+TDD CA.
● Added impact analysis for uplink 2CC aggregation. For details, see 13.2.2
Impacts.
● Revised 4.5.2 Private Band Combinations, with the description of the
PrivateBand.BandType parameter added.
This document only provides guidance for feature activation. Feature deployment and
feature gains depend on the specifics of the network scenario where the feature is
deployed. To achieve the desired gains, contact Huawei professional service engineers.
Software Interfaces
Any parameters, alarms, counters, or managed objects (MOs) described in this
document apply only to the corresponding software release. For future software
releases, refer to the corresponding updated product documentation.
8 Downlink 5CC
Aggregation
3 Overview
3.1 Background
3GPP requires that LTE-Advanced networks provide a downlink peak data rate of 1
Gbit/s. However, radio spectrum resources are so scarce that in most cases
operators own only non-adjacent portions of the spectrum. Due to the limited
bandwidth available on any single portion of the spectrum, the 1 Gbit/s data rate
requirement is hard to meet.
To deal with this situation, 3GPP introduced carrier aggregation (CA) for LTE-
Advanced networks. CA allows for aggregation of contiguous or non-contiguous
component carriers (CCs) to expand bandwidth.
Figure 3-1 illustrates an example of CA.
3.2 Classification
CA can be classified into downlink CA and uplink CA.
● Downlink CA
An eNodeB selects multiple intra- or inter-band carriers for CA in the
downlink based on the CA capability reported by a CA UE and carrier
management principles (see 4 General Principles). This provides wider
bandwidth for downlink data transmission to the UE.
Currently, Huawei supports the following numbers of CCs in the downlink:
In this document, "FDD+TDD" indicates a network deployed with both FDD and TDD
spectrum resources.
● Uplink CA
An eNodeB selects two intra- or inter-band carriers for CA in the uplink based
on the CA capability reported by a CA UE and carrier management principles
(see 4 General Principles). This provides the UE with wider bandwidth for
uplink data transmission.
Currently, Huawei supports uplink 2CC aggregation. For details about this
function, see 13 Uplink 2CC Aggregation.
Uplink FDD+TDD CA can be enabled on networks with both FDD and TDD
spectral resources deployed. This function aggregates FDD and TDD carriers
for a CA UE to widen bandwidth and maximize carrier usage. For details, see
14 Uplink FDD+TDD CA.
Uplink CA and downlink CA work between intra- and inter-eNodeB cells. The
inter-eNodeB cells are served by eNodeBs connected through relaxed backhaul or
ideal backhaul. For details about the scenarios, see 15 Inter-eNodeB CA Based on
Relaxed Backhaul and 16 Inter-eNodeB CA Based on eNodeB Coordination.
For details about how CA collaborates with other key technologies, see 17
Collaboration Between CA and Other Key Technologies.
For details about the CA-group-based and adaptive configuration modes, see 4.4
Configuration Modes.
The following figures show the intra-eNodeB CA scenarios. In the figures, F1 and
F2 denote two carrier frequencies.
Figure 3-4 Intra-eNodeB carriers (one for macro coverage; another for edge
coverage)
Figure 3-5 Intra-eNodeB carriers (one provided by the site; another provided by
RRHs)
Figure 3-6 Intra-eNodeB carriers (one provided only by the site; another provided
by the site and a repeater)
4 General Principles
SCell
A secondary cell (SCell) is a cell that an eNodeB configures for a CA UE through
an RRC Connection Reconfiguration message. This cell operates on a different
frequency from the PCell. It provides the CA UE with additional radio resources. In
an SCell, there can be downlink transmission only or both downlink and uplink
transmission.
CC
Component carriers (CCs) are the carriers that are aggregated for a CA UE.
PCC
The primary component carrier (PCC) is the carrier of the PCell.
SCC
A secondary component carrier (SCC) is the carrier of an SCell.
PCC Anchoring
During PCC anchoring, the eNodeB selects a high-priority cell as the PCell for the
UE.
Ensure that the total number of frequencies configured as candidate PCCs and SCCs
does not exceed 17. Any additional frequencies will not be selected for CA.
● Route setup principles for CA
– A cell can work with a number of other cells for CA. Static routes are set
up between them so long as CaGroupSCellCfg MOs are configured. The
maximum number of other cells depends on the settings of the
Dl2CCAckResShareSw option of the CellAlgoSwitch.PucchAlgoSwitch
parameter and the CaRouteNumberExtensionSwitch option of the
CaMgtCfg.CellCaAlgoSwitch parameter.
▪ An LTE cell or LAA cell acts as the SCell. In the case of an LAA cell,
the LaaRoutePunishmentSwitch option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter must be selected.
With this function, the eNodeB checks whether the duration of a route
from a cell acting as a PCell to a cell acting as an SCell for CA is less than
the sum of the CaMgtCfg.SCellAgingTime and
CaMgtCfg.CaRouteConfigPenaltyOfs parameter values.
▪ If the duration is less than the sum, the eNodeB considers the route
to be of low value and will not dynamically set up this route again
within a period that is equal to
CaMgtCfg.CaRouteConfigPenaltyWeight multiplied by
CaMgtCfg.SCellAgingTime.
▪ If the duration is greater than or equal to the sum, the eNodeB will
not prohibit dynamic setup of this route for CA.
When the penalty function takes effect on a network, CA takes effect for
a smaller number of UEs, as indicated by smaller values of the
L.CA.DLSCell.Add.Att, L.CA.DLSCell.Add.Succ, and
L.Traffic.User.PCell.DL.Avg counters for cells that act as PCells in the
penalties. As a result, cell throughput decreases.
This function does not take effect for cells that are served by LMPT
boards and act as PCells.
– Dynamic route setup in the case of an insufficient backplane bandwidth
Routes set up for CA consume the backplane bandwidth of each eNodeB,
which is shared by all features. If there is not enough backplane
bandwidth, the routes will fail to be set up. If three consecutive attempts
to set up a route to a single cell fail because of an insufficient backplane
bandwidth, the eNodeB prohibits the subsequent 30 attempts on the
route to this cell. This cell will not be configured as an SCell if route setup
fails. As a result, the value of the L.CA.DLSCell.Add.Att counter
decreases, but the value of the L.CA.DLSCell.Add.Succ counter is not
affected.
Take the LTE private CA band combination 7a (10 MHz) + 7a (10 MHz) + 28a (10
MHz) as an example. Assume that the PrivateCaBandComb.PrivateCaCombId
parameter is set to 1 for the band combination. Each of the three bands in this
band combination is associated with the band combination by setting the
PrivateBand.PrivateCaCombId parameter to 1 for each band.
The parameters for the bands are listed in Table 4-3, Table 4-4, and Table 4-5.
Table 4-3 Parameter settings for the first band in the operator-defined band
combination
Parameter ID Value
PrivateBand.PrivateCaCombId 1
PrivateBand.CombBandIndex 1
PrivateBand.CombBandId 7
PrivateBand.CombBandBw Bandwidth_10M
PrivateBand.BandType LTE(LTE)
Table 4-4 Parameter settings for the second band in the operator-defined band
combination
Parameter ID Value
PrivateBand.PrivateCaCombId 1
PrivateBand.CombBandIndex 2
PrivateBand.CombBandId 7
PrivateBand.CombBandBw Bandwidth_10M
PrivateBand.BandType LTE(LTE)
Table 4-5 Parameter settings for the third band in the operator-defined band
combination
Parameter ID Value
PrivateBand.PrivateCaCombId 1
PrivateBand.CombBandIndex 3
PrivateBand.CombBandId 28
PrivateBand.CombBandBw Bandwidth_10M
PrivateBand.BandType LTE(LTE)
NOTE
For this whitelist control function to take effect, operators must run man-machine
language (MML) commands to configure the UE-supported band combinations on
eNodeBs. The operators then must set the UeCompat.WhiteLstCaCombSwitch
parameter to the IDs of the band combinations, which are specified by the
PrivateCaBandComb.PrivateCaCombId parameter.
This whitelist control mechanism takes effect only for band combinations whose
value of PrivateCaBandComb.PrivateCaCombId is within the range of 0–31.
● Scenario 1: During the initial access of a UE to a cell, the EPC does not send
the E-UTRAN capabilities of the UE to the eNodeB.
The CA band combination reporting procedure is as follows:
a. The eNodeB includes the requestedFrequencyBands IE (which contains a
maximum of 16 bands) in the UECapabilityEnquiry message and sends
this message to the UE.
b. If the UE supports network-requested CA band combination capability
signaling, it includes the requestedBands, supportedBandCombination,
and supportedBandCombinationAdd IEs in the UECapabilityInformation
message and sends this message to the eNodeB. The
supportedBandCombination and supportedBandCombinationAdd IEs
convey up to 128 and 256 CA band combinations for the requested
bands, respectively. These two IEs include a maximum of 384
combinations in total.
● Scenario 1: During the initial access of a UE to a cell, the EPC does not send
the E-UTRAN capabilities of the UE to the eNodeB.
The CA band combination reporting procedure is as follows:
a. The eNodeB sends a UECapabilityEnquiry message to the UE to query its
CA band combination capability.
b. The UE reports the supported CA band combinations (a maximum of 128
combinations) to the eNodeB through the 3GPP Release 10 IE
supportedBandCombination. If the UE complies with 3GPP Release 11, it
also sends the freqBandRetrieval-r11 IE to report its capability of
network-requested CA band combination capability signaling.
c. If the UE complies with 3GPP Release 11, and if the size of the UE-
reported UE-EUTRA-Capability IE exceeds the value of the
GlobalProcSwitch.UeEutraCapbIeSizeThld parameter or the number of
CA band combinations reported by the UE reaches 128, the eNodeB
includes the requestedFrequencyBands IE (which contains a maximum of
16 bands) in a second UECapabilityEnquiry message and sends this
message to the UE. Otherwise, the procedure ends.
d. The UE includes the requestedBands, supportedBandCombination, and
supportedBandCombinationAdd IEs in the UECapabilityInformation
message and sends this message to the eNodeB. The
supportedBandCombination and supportedBandCombinationAdd IEs
convey up to 128 and 256 CA band combinations for the requested
bands, respectively. These two IEs include a maximum of 384
combinations in total.
● Scenario 2: During the initial access of a 3GPP Release 11 UE to a cell, the
UE's E-UTRAN capability information sent from the EPC to the eNodeB
includes the requestedBands IE, but none of the CA bands conveyed by this IE
are supported by the eNodeB.
The CA band combination reporting procedure is as follows:
a. The eNodeB includes the requestedFrequencyBands IE (which contains a
maximum of 16 bands) in the UECapabilityEnquiry message and sends
this message to the UE.
b. The UE includes the requestedBands, supportedBandCombination, and
supportedBandCombinationAdd IEs in the UECapabilityInformation
message and sends this message to the eNodeB. The
supportedBandCombination and supportedBandCombinationAdd IEs
convey up to 128 and 256 CA band combinations for the requested
bands, respectively. These two IEs include a maximum of 384
combinations in total.
● Scenario 3: During the initial access of a 3GPP Release 11 UE to a cell, the
UE's E-UTRAN capability information sent from the EPC to the eNodeB does
not include the requestedBands IE. In addition, the size of the UE-EUTRA-
Capability IE exceeds the value of the
GlobalProcSwitch.UeEutraCapbIeSizeThld parameter, or the number of CA
band combinations included in the E-UTRAN capability information reaches
128.
The CA band combination reporting procedure in this scenario is the same as
that in scenario 2.
● Scenario 4: During an RRC connection reestablishment or handover of a 3GPP
Release 11 UE to a cell, the UE's E-UTRAN capability information sent from
the source eNodeB includes the requestedBands IE, but none of the CA bands
conveyed by this IE are supported by the target eNodeB.
The CA band combination reporting procedure in this scenario is the same as
that in scenario 2.
● Scenario 5: During an RRC connection reestablishment or handover of a 3GPP
Release 11 UE to a cell, the UE's E-UTRAN capability information sent from
the source eNodeB does not include the requestedBands IE. In addition, the
size of the UE-EUTRA-Capability IE exceeds the value of the
GlobalProcSwitch.UeEutraCapbIeSizeThld parameter, or the number of CA
band combinations included in the E-UTRAN capability information reaches
128.
The CA band combination reporting procedure in this scenario is the same as
that in scenario 2.
In this situation, as the eNodeB needs to store more CA band combinations for
each UE, the memory usage of the eNodeB increases slightly. Moreover, the
additional procedure for querying CA band combination capabilities has a negative
impact on performance indicators such as the number of signaling messages,
access delay, and E-RAB setup success rate. For example, E-RAB Setup Success
Rate decreases and the values of the following counters increase:
L.Signal.Num.Uu, L.E-RAB.InitEst.TimeAvg, L.E-RAB.InitEst.TimeMax, L.E-
RAB.Est.TimeAvg, and L.E-RAB.Est.TimeMax.
In this situation, as the eNodeB needs to store more CA band combinations for
each UE, the memory usage of the eNodeB increases slightly. Moreover, the
additional procedure for querying CA band combination capabilities has a negative
impact on performance indicators such as the number of signaling messages,
access delay, and E-RAB setup success rate. For example, E-RAB Setup Success
Rate decreases and the values of the following counters increase:
L.Signal.Num.Uu, L.E-RAB.InitEst.TimeAvg, L.E-RAB.InitEst.TimeMax, L.E-
RAB.Est.TimeAvg, and L.E-RAB.Est.TimeMax.
● SCells configured for a CA UE are activated when certain conditions are met.
The PCell and SCells are not actually aggregated until the SCells are activated.
For details, see 4.6.3.4 SCell Activation.
● If SCells meet deactivation conditions, the eNodeB delivers MAC control
elements (CEs) to deactivate the SCells. For details, see 4.6.3.5 SCell
Deactivation.
● If SCell signal quality deteriorates, the eNodeB may remove the SCells. For
details, see 4.6.3.6 SCell Removal.
NOTE
● No bearer with a QCI of 1 has been established for the UE. QCI 1 indicates a
voice over LTE (VoLTE) service or an emergency call.
● If a bearer with a QCI of 1 has been established for the UE, the conditions
described in 17.7 VoLTE are fulfilled.
● No bearer with a QCI of 65 has been established for the UE. QCI 65 indicates
a mission-critical push-to-talk (MCPTT) service.
● A bearer with a QCI of 65 has been established for the UE, and the
McpttVoiceCaSwitch option of the CaMgtCfg.CellCaAlgoSwitch parameter
has been selected.
For the detailed PCC anchoring procedures, see 4.6.1.2 CA-Group-based PCC
Anchoring Procedure and 4.6.1.3 Adaptive PCC Anchoring Procedure.
In the current serving cell of a CA UE, PCC anchoring is triggered by event A1 and
event A1 is reported only once.
The PCell of a CA UE cannot be deactivated or removed. It changes only during
handovers.
The scenarios of PCC anchoring for CA UEs vary depending on the setting of the
CaTrafficTriggerSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter.
● If this option is selected, PCC anchoring can be triggered for CA UEs during
both necessary and unnecessary incoming handovers. As a result, PCC
anchoring is repeatedly triggered for CA UEs, or even ping-pong PCC
anchoring occurs.
● If this option is deselected, PCC anchoring can be triggered for CA UEs only
during necessary incoming handovers. This prevents repeated PCC anchoring
and ping-pong PCC anchoring.
1. The eNodeB checks whether the current serving cell (for example, cell 1) has
the highest PCell priority, as specified by the
CaGroupCell.PreferredPCellPriority parameter, of all the cells in the CA
group.
– If cell 1 has the highest PCell priority, the eNodeB retains cell 1 as the
PCell for the UE and does not perform further PCC anchoring.
– If cell 1 does not have the highest PCell priority, the eNodeB treats the
cells that have higher PCell priorities than cell 1 in the CA group as
candidate PCells. The eNodeB then arranges the candidates in descending
order of PCell priority and goes to the next step.
1. The eNodeB checks whether the current serving carrier (for example, carrier
1) has the highest PCC priority, as specified by the
PccFreqCfg.PreferredPccPriority parameter, of all the carriers identified by
PccFreqCfg MOs.
– If carrier 1 has the highest PCC priority, the eNodeB retains the cell on
carrier 1 as the PCell for the UE and does not perform further PCC
anchoring.
– If carrier 1 does not have the highest PCC priority, the eNodeB treats
higher-priority carriers as candidate PCCs for the UE, arranges them in
descending order of PCC priority, and goes to the next step.
2. The eNodeB checks whether the UE is capable of working at the top-priority
candidate PCC (for example, carrier 2).
If a candidate PCC is not accompanied by candidate SCCs, the eNodeB does not
deliver A5 measurement configurations related to this candidate PCC.
The triggering quantity parameter values and threshold 2 parameters for
event A5 correspond as follows:
with routes set up between them exchange their load status, and the eNodeB
selects a low-load candidate cell as the PCell. (A cell not in the high load state is
considered to be in the low load state.)
A cell is in the high PCell load state if the number of CA UEs that treat the cell as
their PCell (referred to as PCell-served UEs in this document for clarity) exceeds
the high PCell load threshold.
High PCell load threshold = Maximum allowed number of PCell-served UEs in the
cell (specified by the CaMgtCfg.CellMaxPccNumber parameter) x Percentage
specified by the CaMgtCfg.PccUserNumberOffloadThd parameter
This function takes effect when both of the following options are selected:
● EnhancedPccAnchorSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter
● PccSmartCfgSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter
For inter-eNodeB CA, these options must be selected for all of the eNodeBs
involved. In addition, eX2 interfaces must be set up for load information exchange
between these eNodeBs.
This function introduces special handling to the basic PCC anchoring procedure, as
described in 4.6.2.1 CA-Group-based PCC Anchoring Procedure and 4.6.2.2
Adaptive PCC Anchoring Procedure.
If the PCell load status of a candidate PCell changes, it takes several seconds for
the new load status to be exchanged between BBPs or eNodeBs for inter-BBP or
inter-eNodeB CA. If multiple UEs access the candidate PCell within a short time,
the eNodeB may make an incorrect decision on the load status before the status
exchange is complete.
– If the number has reached the threshold, the eNodeB prohibits SCell
configuration for this UE.
If a CA UE reverts to the single carrier state after the number of PCell-
served UEs reaches the threshold, the eNodeB does not immediately
allow SCell configuration for other UEs. Instead, the eNodeB allows SCell
configuration for other UEs only when the number of PCell-served UEs
falls below 90% of the threshold.
NOTE
A UE enters the SCell configuration procedure after the procedure is triggered. For
details about the SCell configuration procedure, see 4.6.3.1.2 CA-Group-based
SCell Configuration Procedure and 4.6.3.1.3 Adaptive SCell Configuration
Procedure.
The CPU usage of the main control board and that of the BBP have the impacts
listed in Table 4-7 and Table 4-8 on the SCell configuration procedure.
Table 4-7 Impacts of the CPU usage of the main control board on the SCell
configuration procedure
CPU Usage of Impact on the SCell Configuration Procedure
the Main
Control Board
(Unit: %)
[0,70) No impact
Table 4-8 Impacts of the CPU usage of the BBP on the SCell configuration
procedure
CPU Usage of Impact on the SCell Configuration Procedure
the BBP (Unit:
%)
[0,70) No impact
[70,90) SCell configuration is not allowed for CA UEs that access the
network through initial access, incoming handovers, or
incoming RRC connection reestablishments.
Figure 4-8 CA-group-based SCell configuration procedure for uplink/downlink 2CC aggregation
▪ The cell has not been configured as an SCell for the UE.
▪ The cell belongs to the public land mobile network (PLMN) serving
the UE, or to an equivalent PLMN.
● If the CaGroup.CnOperatorList parameter is not set for the CA group to
which the PCell of a CA UE belongs, the eNodeB treats any cell that meets all
the following conditions as a candidate SCell for the PCell of the CA UE:
– The cell is in the same CA group as the PCell.
– The cell has not been configured as an SCell for the UE.
– The cell belongs to the PLMN serving the UE, or to an equivalent PLMN.
The eNodeB arranges all candidate SCells in descending order of SCell priority
(specified by the CaGroupSCellCfg.SCellPriority parameter) and attempts to
select a candidate SCell as an SCell for the UE. Cells with the priority value of 0
cannot be configured as SCells.
The SCell configuration procedure varies depending on the parameter settings
related to blind SCell configuration.
● The SccBlindCfgSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter is selected, and the CaGroupSCellCfg.SCellBlindCfgFlag
parameter is set to TRUE for a top-priority candidate SCell.
The eNodeB does not send the A4 measurement configuration related to the
operating frequency of this candidate SCell. Instead, the eNodeB directly
delivers an RRC Connection Reconfiguration message to configure this
candidate cell as an SCell for the UE. If multiple candidate SCells have the
same top SCell priority and have their blind configuration flag set to TRUE,
the eNodeB randomly selects one cell from these candidate SCells and
attempts to configure this cell as an SCell for the UE in a blind manner.
– If the SCell is configured successfully, the SCell configuration procedure
ends.
– If the SCell fails to be configured, the eNodeB evaluates next-priority
candidate SCells in the same way.
It is recommended that blind SCell configuration be enabled to have SCells
quickly configured.
For UEs that support NSA DC, if any New Radio (NR) cell is defined as a blind-configurable
candidate SCell on the eNodeB, the eNodeB preferentially configures the NR cell as an SCell
in a blind manner. After the NR SCell is configured, the eNodeB then performs blind E-
UTRA SCell configuration.
From the carriers defined in the SccFreqCfg MOs for the PCC of a CA UE, the
eNodeB selects carriers depending on whether operator information has been
specified:
● Operator information has been specified (by the SccFreqCfg.CnOperatorList
parameter) for any of these carriers.
The eNodeB selects the carriers used by the operator that is serving the UE.
Among the selected carriers, the eNodeB treats those that have not been
configured as SCCs for the UE and are supported by the UE for CA as
candidate SCCs. The eNodeB then arranges all candidate SCCs in descending
order of SCC priority (specified by the SccFreqCfg.SccPriority parameter) and
attempts to select a cell on a candidate SCC as an SCell for the UE, as
described in the follow-up procedure.
● No operator information has been specified for any of these carriers.
The eNodeB treats those that have not been configured as SCCs for the UE
and are supported by the UE for CA as candidate SCCs. The eNodeB then
arranges all candidate SCCs in descending order of SCC priority and attempts
to select a cell on a candidate SCC as an SCell for the UE, as described in the
follow-up procedure.
1. The eNodeB checks whether a blind-configurable candidate cell (with
CaGroupSCellCfg.SCellBlindCfgFlag set to TRUE) on the top-priority
candidate SCC has been specified for the PCell of the UE.
– Such a cell has been specified.
The eNodeB delivers an RRC Connection Reconfiguration message to
configure this cell as an SCell for the UE, without delivering measurement
configurations.
NOTE
▪ If a bearer with a QCI of 1 has been established for the UE, then:
The procedure goes as described in 17.7 VoLTE.
For inter-eNodeB CA, this option must be selected only for the serving eNodeB of
the PCell.
The evaluation of load status indicators for candidate SCells varies depending on
the setting of CellMLB.MlbTriggerMode. It is recommended that the following
parameters be set consistently for all of the cells on the network.
● Set to PRB_ONLY
– High-load entering condition: physical resource block (PRB) usage ≥
CellMLB.InterFreqMlbThd + CellMLB.InterFreqOffloadOffset
throughout 5s
– Low load condition: before the cell enters the high load state or after it
exits the high load state
High-load leaving condition: PRB usage < CellMLB.InterFreqMlbThd +
CellMLB.InterFreqOffloadOffset – CellMLB.LoadOffset throughout 5s
● Set to UE_NUMBER_ONLY
– High-load entering condition: Number of UEs in the cell ≥
CellMLB.InterFreqMlbUeNumThd +
CellMLB.InterFrqUeNumOffloadOffset throughout 5s
For the definition of the number of UEs in a cell, see Intra-RAT Mobility
Load Balancing.
– Low load condition: before the cell enters the high load state or after it
exits the high load state
High-load leaving condition: Number of UEs in the cell <
CellMLB.InterFreqMlbUeNumThd +
CellMLB.InterFrqUeNumOffloadOffset – CellMLB.MlbUeNumOffset
throughout 5s
● Set to PRB_OR_UE_NUMBER
– A cell enters the high load state if it meets either of the following
conditions throughout 5s:
▪ The cell meets the low load condition used when this parameter is
set to PRB_ONLY.
▪ The cell meets the low load condition used when this parameter is
set to UE_NUMBER_ONLY.
Load-based SCell configuration introduces special handling to the basic procedures
described in 4.6.3.1.2 CA-Group-based SCell Configuration Procedure and
4.6.3.1.3 Adaptive SCell Configuration Procedure. The special handling varies
depending on whether blind-configurable candidate SCells have been set for the
PCell of the CA UE:
● Blind-configurable candidate SCells have been set.
Blind SCell configuration takes place.
– If the number of blind-configurable candidate SCells under a given
priority is greater than the number of SCells to be configured, the
eNodeB checks the load status indicator of each candidate and delivers
an RRC Connection Reconfiguration message to preferentially configure
low-load cells as SCells. If the candidates are in the same load state
(either high or low), the eNodeB randomly selects cells from them as
SCells.
– If the number of blind-configurable candidate SCells under a given
priority is less than or equal to the number of SCells to be configured, the
eNodeB starts SCell configuration without comparing the load states of
the candidates.
● Blind-configurable candidate SCells have not been set.
When there are multiple candidate SCells with the same priority, the eNodeB
acts differently depending on the number of these candidates:
– The number of these candidates is greater than the number of SCells to
be configured.
The eNodeB collects the measurement reports about all these candidates.
(If the eNodeB does not receive measurement reports about any cell on a
frequency within 3s, it considers the UE to be outside of the coverage
area of the frequency and instructs the UE to stop the measurements.)
The eNodeB then checks the load status indicator of each candidate.
Based on the load status indicators, the eNodeB delivers an RRC
Connection Reconfiguration message to preferentially configure low-load
cells as SCells for the UE. This measurement-based SCell configuration
procedure has a longer delay than the blind SCell configuration
procedure. If the candidates are in the same load state (either high or
low), the eNodeB selects the cells with the greatest RSRP values as SCells.
– The number of these candidates is less than or equal to the number of
SCells to be configured.
The eNodeB does not check the load status indicators of candidates.
Instead, it starts configuring SCells upon receiving measurement reports.
For FDD, eNodeBs do not consider the load status indicators of candidate SCells
during A6-based SCell changes. For details about the load status indicators for
candidate SCells, see 4.6.3.2 SCell Configuration Enhancement.
After receiving an A6 measurement report from the CA UE, the eNodeB evaluates
the reported cells in the CA group and selects the one with the highest RSRP
value. The eNodeB then sends an RRC Connection Reconfiguration message to
change the SCell to the selected cell. If the SCell change fails, the eNodeB selects
the cell with the next highest RSRP value among the reported cells and makes
another SCell change attempt.
● If the PCell can set up a data link to the top-priority candidate SCell (for
example, cell 2), the eNodeB sends an RRC Connection Reconfiguration
message to change the SCell from cell 1 to cell 2 for the UE.
● If the PCell cannot set up a data link to cell 2, the eNodeB tries the next-
priority candidate SCell.
If the PCell cannot set up a data link to any candidate SCell, the eNodeB does not
change the SCell for the UE.
eNodeB prepares to send data to the UE. This consumes a large amount of
radio resources.
To ensure synchronization between the UE and the eNodeB, SCells are activated
on the UE and eNodeB sides simultaneously. If the eNodeB sends a MAC CE for
SCell activation to the UE in subframe n, then the SCell is activated on the UE and
eNodeB sides in subframe (n + x). The value of x is stipulated by physical layer
protocols.
● For FDD, x is equal to 8.
When cells are heavily loaded, SCell activation can be prohibited to ensure user
experience. This prohibition function is enabled when the
CaMgtCfg.ScellNoActivationUeNumThld parameter is set to a non-zero value.
This parameter specifies the threshold for determining heavy cell load.
● If the number of UEs in a cell exceeds the value of this parameter, the eNodeB
determines that the cell is heavily loaded. If the cell is heavily loaded, new
SCell activation quotas will not be provided for CA UEs. When the existing
SCell activation quota is reached (that is, the number of UEs that have this
cell activated as their SCell has reached the quota), the activation quota
becomes 0 and this cell will no longer be activated as an SCell for any CA UE.
● If the number of UEs in a cell is a little smaller than the value of this
parameter, simultaneous SCell activation for a number of CA UEs will cause
the number of UEs in the cell to exceed the value of this parameter even if no
UEs are admitted to the cell through initial access, incoming RRC connection
reestablishments, or incoming handovers.
The eNodeB measures the number of UEs in each cell every second.
The following UEs are counted into the number of UEs in a cell:
● Non-CA UEs
● CA UEs that treat the cell as their PCell
● CA UEs for which the cell has been activated as an SCell
For FDD, it is recommended that this function be enabled when the cell
bandwidth is 1.4 MHz, 3 MHz, or 5 MHz.
SCells will be low when CA UEs are located in weak coverage areas or are
experiencing strong interference. The low CQI will cause a decrease in Cell
Downlink Average Throughput and an increase in the number of RRC connection
reestablishments, the uplink and downlink initial block error rate (IBLER) values,
the packet loss rate, and the service drop rate.
Before enabling this function, ensure that the CaSccSuspendSwitch option of the
ENodeBAlgoSwitch.CaAlgoSwitch parameter has been deselected.
After deactivating an SCell based on channel quality, the serving eNodeB of the
PCell does not immediately remove this SCell, regardless of whether the
CaTrafficTriggerSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter is selected.
▪ ACK returned
The eNodeB resumes the scheduling of the UE in the SCell.
▪ NACK returned
The eNodeB adjusts the CQI and then continues the detection. The
CQI adjustment varies with the setting of the
CaMgtCfg.SccDetectCqiDecreaseStep parameter.
○ CaMgtCfg.SccDetectCqiDecreaseStep set to 0
The eNodeB decreases the CQI by the basic adjustment value.
○ CaMgtCfg.SccDetectCqiDecreaseStep set to a value other than
0
The eNodeB decreases the CQI by the sum of the basic
adjustment value and the CaMgtCfg.SccDetectCqiDecreaseStep
parameter value.
If the number of detection failures reaches the maximum, the
eNodeB delivers a MAC CE to deactivate the SCell.
● In the uplink:
The processing of residual block error–triggered SCell deactivation depends on
the setting of the CaMgtCfg.SccQuietTime parameter and the
SccDeactByUlDtxSwitch option setting of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter.
– CaMgtCfg.SccQuietTime set to 0
NOTE
When an SCell meets the triggering conditions for event A2, the eNodeB removes
the SCell. If the eNodeB removes n SCells for a CA UE in the uplink or downlink
mCC aggregation state, the UE will be served by (m–n) carriers.
NOTE
When a bearer for an emergency call or with QCI 1, 65, 66, or an enhanced extended QCI is
set up for a CA UE whose SCells have been configured, the eNodeB does not remove the
SCells.
SCell removal is performed by the eNodeBs serving the PCells of CA UEs. Figure
4-13 illustrates this function.
NOTE
● For details about the entering condition for event A4, see 4.6.3.1.3 Adaptive
SCell Configuration Procedure.
● Entering condition for event A2: (Ms + Hys < Thresh) is true throughout a
period specified by TimeToTrig.
In the formula:
maximum number of carriers supported by the UE. After receiving the IE, the
eNodeB removes all the SCells of the UE and saves the reducedMaxCCs IE
reported by the UE. The number of SCells to be configured for the UE will not
exceed the value of reducedMaxCCs.
● When the UE recovers from overheating, it reports the OverheatingAssistance
IE to the eNodeB again. However, this IE no longer contains the
reducedMaxCCs IE. The eNodeB removes the reducedMaxCCs IE from its
storage space and continues to configure SCells for the UE.
With this function, CA UEs that support overheating protection can exit the CA
state or have fewer SCells configured when they experience overheating. As a
result, the throughput of the CA UEs and the number of their SCells decrease.
5.1 Principles
This function aggregates two intra- or inter-band carriers, as shown in Figure 5-1,
to provide higher bandwidth.
The switch control over this function varies, as described in Table 5-1.
5.2.1 Benefits
This function enables CA UEs to reach higher downlink peak data rates.
Table 5-2 lists the theoretical peak data rates that a CA UE can reach using
downlink 2CC aggregation.
For FDD, these values assume a TBS suitable for the 20 MHz cell bandwidth
(equivalent to 100 RBs in the frequency domain).
Table 5-2 Theoretical peak data rates for downlink 2CC aggregation (unit: Mbit/s)
RAT 2x2 MIMO 2x2 MIMO 4x4 MIMO 4x4 MIMO
+ 64QAM + 256QAM + 64QAM + 256QAM
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports a downlink peak data rate of 450 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 450 Mbit/s in the downlink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryDL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
5.2.2 Impacts
Network Impacts
This function has the following impacts on the network:
● System capacity
A CA UE with SCells configured has only one RRC connection to the network.
It consumes one sales unit of the license for the number of RRC_CONNECTED
UEs. However, the CA UE consumes a hardware resource unit in each of its
serving cells. In an extreme case with nCC aggregation for all UEs on the
network, the maximum number of UEs that can access the network decreases
to 1/n (n is an integer.) When all hardware resources are used, the eNodeB
preferentially releases CA UEs in their SCells to maximize the number of UEs
that can access the network.
● Resource usage
– Physical resource block (PRB) usage
The CPU usage of the main control board and BBPs may change as the
number of SCCs increases.
● Network performance
– Overall throughput in the entire network
CA does not directly affect network capacity. However, when resources on
a network have not been exhausted, CA increases the resource usage and
overall network throughput.
– Number of CQI reports
In accordance with section 10.1.1 "PUCCH format information" of 3GPP
TS 36.213 V10.10.0, CA UEs cannot send CSI reports together with ACK/
NACK over the PUCCH with format 1b. The UEs discard CSI reports as
stipulated by 3GPP specifications. CSI reports include periodic CQI reports.
As a result, the number of CQI reports from CA UEs decreases, as
indicated by the values of the L.ChMeas.CQI.DL.0 to L.ChMeas.CQI.DL.
15 counters, after CA is enabled.
When the number of CQI reports from CA UEs decreases, the total
number of CQI reports in the entire network may decrease, increase, or
remain unchanged, depending on the radio conditions of the CA UEs and
the ratio of CA UEs to all UEs. For example, if CA UEs are located in cell
centers and account for a large proportion of all UEs, the total number of
CQI reports may also decrease. If CA UEs are not located in cell centers or
they account for a small proportion, the total number of CQI reports may
increase or remain unchanged.
– Downlink cell performance
The downlink IBLER of a cell will fluctuate if the 2CCDlCaEnhanceSwitch
option of the CaMgtCfg.CellCaAlgoSwitch parameter is selected.
– Key performance indicator (KPI) fluctuation
The PCell and SCells of each CA UE may not have the same channel
quality. Therefore, CQIs fluctuate after SCells are configured for CA UEs.
If the CaMgtCfg.ScellNoActivationUeNumThld parameter is set to a
non-zero value, SCell activation prohibition upon heavy cell load is
enabled. This parameter specifies the threshold for determining heavy cell
load. When the number of UEs in a cell exceeds the value of this
parameter, the eNodeB determines that the cell is heavily loaded. If the
heavy load state persists, the eNodeB will not activate this cell as an SCell
for CA UEs. This prohibition function helps increase the average downlink
perceived data rates of non-CA UEs in the cell, especially those at the cell
edge, but it decreases the average downlink perceived data rates of CA
UEs that treat the cell as their SCell. In addition, the overall average
downlink data rate of the network decreases.
● Data rates of CA UEs
– When resources on a network have not been exhausted, CA in the
network increases the data rates of CA UEs.
– When resources on a network have been exhausted, the data rates of CA
UEs are dependent on scheduling policies (described in 17.5.1
Scheduling) and UE locations.
In the full load situation, activating an SCell may result in a decrease in
the overall throughput of this cell if the UE is located at the edge of this
cell.
Function Impacts
● Functions in the category "RAN functions"
RAT Function Function Reference Description
Name Switch
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Flash oud.Spectru NR Spectrum the number of
Dynamic mCloudSwit Sharing downlink RBs
Spectrum ch available for LTE.
Sharing parameter Therefore, the
set to throughput of UEs in
LTE_NR_SPE the downlink FDD
CTRUM_SHR CA state decreases.
FDD GSM and LTE SpectrumCl GSM and LTE Cells with 5 MHz
spectrum oud.Spectru Spectrum bandwidth are not
concurrency mCloudSwit Concurrency recommended as
ch PCells. If these cells
parameter act as PCells, the
set to PUCCH overhead is
GL_SPECTRU so large that SRSs
M_CONCUR cannot be
RENCY configured.
5.3 Requirements
5.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
None
5.3.3 Hardware
Boards
CA works between intra- or inter-BBP cells.
▪ If the baseband equipment ID is 255, the specified cell has not been
bound to any baseband equipment. In this case, proceed to the next
step.
b. Run the ADD BASEBANDEQM command to add baseband equipment.
The baseband equipment ID must be different from any other assigned
IDs.
c. Run the MOD EUCELLSECTOREQM command on the macro eNodeB or
the MOD EUSECTOREQMGROUP command on the LampSite eNodeB to
bind the cell to the new baseband equipment.
The cell will then be reestablished, and then the new binding takes effect.
● Slot requirements
– Intra-BBP CA
RF Modules
To meet the time alignment requirements (see 5.3.4 Networking), intra-band CA
requires one of the following radio frequency (RF) module configurations:
● One multi-carrier RF module
● Multiple active antenna units (AAUs) of the same product model
● Multiple RRUs of the same product model
● Multiple radio frequency units (RFUs) with the same hardware version
number
For example, the two RFUs are a combination of MRFU V6 and MRFUd V6.
The hardware version number (such as V1, V2, or V6) can be observed on the
RFU panel.
NOTE
5.3.4 Networking
Frequencies
● There must be at least two frequencies on the live network.
● The channel spacing between the center frequencies of two intra-band
contiguous CCs must meet the following requirement:
Coverage
The coverage areas provided by the cells to be aggregated must overlap. The areas
where CA takes effect are dependent on the overlapping ranges. The smaller the
overlapping range, the smaller the CA area.
Cells
● Any cells possible for CA must have the same cyclic prefix (CP) length: either
normal or extended.
● Candidate SCells must be inter-frequency neighboring cells of PCells.
There is one exception: After a CA UE reports its CA capabilities during initial
access, the eNodeB sends an RRC Connection Reconfiguration message to
configure a blind-configurable candidate SCell, if any, as an SCell to work with
the PCell. This candidate SCell is not necessarily an inter-frequency
neighboring cell of the PCell. However, in any subsequent SCell configuration
procedure for this UE, the candidate SCells must be inter-frequency
neighboring cells of the PCell.
● Intra-frequency cell requirements
– Inter-BBP data exchange for this function is bandwidth-consuming. If this
function is activated together with CoMP or SFN, the available backplane
bandwidth may be insufficient. To prevent this, it is recommended that
intra-frequency cells be configured on the same BBP.
– Network planning must mitigate physical cell identifier (PCI) conflicts.
When the PCI of a candidate SCell conflicts with the PCI of an intra-
frequency neighboring cell, the eNodeB will configure this candidate cell
as an SCell only if all of the following options have been selected:
5.3.5 Others
● UEs
UEs must comply with 3GPP Release 10 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
NOTE
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink 2CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink 2CC
aggregation is to be deployed in an eNodeB coordination scenario.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink 2CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink 2CC
aggregation is to be deployed in an eNodeB coordination scenario.
RLC/PDCP Parameters
Set parameters in the RlcPdcpParaGroup MO.
Frame Offset
Set parameters in the ENodeBFrameOffset MO.
Compatibility Parameters
Set parameters in the GlobalProcSwitch MO.
1526728426 L.Traffic.User.PCell.DL.Avg
1526728427 L.Traffic.User.SCell.DL.Avg
1526728424 L.ChMeas.PRB.DL.PCell.Used.Avg
1526728425 L.ChMeas.PRB.DL.SCell.Used.Avg
Message Tracing
After a CA UE accesses a cell, the eNodeB configures a cell that meets CA
conditions as an SCell for the UE. When traffic conditions are met, the eNodeB
activates this SCell.
You can use the MAE-Access or MML commands to verify SCell configuration and
activation:
● MAE-Access
– Observe the RRC_CONN_RECFG message traced on the Uu interface.
1526726740 L.ChMeas.PRB.DL.Used.Avg
1526728516 L.Traffic.User.PCell.DL.Max
1526728426 L.Traffic.User.PCell.DL.Avg
1526728517 L.Traffic.User.SCell.DL.Max
1526728427 L.Traffic.User.SCell.DL.Avg
1526728424 L.ChMeas.PRB.DL.PCell.Used.Avg
1526728425 L.ChMeas.PRB.DL.SCell.Used.Avg
1526728564 L.Thrp.bits.DL.CAUser
1526728565 L.Thrp.Time.DL.CAUser
1526728514 L.E-RAB.AbnormRel.CAUser
1526728515 L.E-RAB.NormRel.CAUser
1526728520 L.HHO.ExecSuccOut.CAUser.PCC
1526728519 L.HHO.ExecAttOut.CAUser.PCC
1526728518 L.HHO.PrepAttOut.CAUser.PCC
1526729602 L.HHO.InterFddTdd.PrepAttOut.CA
User.PCC
1526729603 L.HHO.InterFddTdd.ExecAttOut.CA
User.PCC
1526729604 L.HHO.InterFddTdd.ExecSuccOut.C
AUser.PCC
1526729045 L.CA.DLSCell.Add.Att
1526729046 L.CA.DLSCell.Add.Succ
1526729047 L.CA.DLSCell.Rmv.Att
1526729048 L.CA.DLSCell.Rmv.Succ
1526730592 L.CA.DLSCell.Add.Meas.Att
1526730593 L.CA.DLSCell.Add.Meas.Succ
1526730594 L.CA.DLSCell.Rmv.Meas.Att
1526730595 L.CA.DLSCell.Rmv.Meas.Succ
1526730590 L.CA.DLSCell.Add.Blind.Att
1526730591 L.CA.DLSCell.Add.Blind.Succ
1526730596 L.CA.DLSCell.Mod.Att
1526730597 L.CA.DLSCell.Mod.Succ
1526728999 L.CA.DLSCell.Act.Att
1526729000 L.CA.DLSCell.Act.Succ
1526729001 L.CA.DLSCell.Deact.Att
1526729002 L.CA.DLSCell.Deact.Succ
1526732658 L.CA.Traffic.bits.DL.PCell
1526729259 L.CA.Traffic.bits.DL.SCell
1526729003 L.CA.DL.PCell.Act.Dur
1526729004 L.CA.DL.SCell.Act.Dur
1526732656 L.Traffic.User.SCell.Active.DL.Avg
1526732657 L.Traffic.User.SCell.Active.DL.Max
In addition, monitor the function subsets listed in Table 5-10, which are
included in "Measurement of Cell Performance (Cell)", to collect CQI, MCS,
and MAC statistics about PCells and SCells.
1526739796 L.RB.DL.PCell.CAUsed.PLMN
1526739797 L.RB.DL.SCell.CAUsed.PLMN
1526739766 L.Traffic.User.PCell.DL.Avg.PLMN
1526739767 L.Traffic.User.SCell.DL.Avg.PLMN
1526739743 L.Thrp.bits.DL.CAUser.PLMN
1526739744 L.Thrp.Time.DL.CAUser.PLMN
1526739798 L.Traffic.bits.CA.DL.PCell.PLMN
1526739799 L.Traffic.bits.CA.DL.SCell.PLMN
1526739800 L.Traffic.bits.DL.PLMN
1526739769 L.E-RAB.AbnormRel.CAUser.PLMN
1526739771 L.E-RAB.NormRel.CAUser.PLMN
1526739773 L.CA.DLSCell.Add.Att.PLMN
1526739774 L.CA.DLSCell.Add.Succ.PLMN
1526739775 L.CA.DLSCell.Rmv.Att.PLMN
1526739776 L.CA.DLSCell.Rmv.Succ.PLMN
6.1 Principles
This function aggregates three intra- or inter-band carriers, as shown in Figure
6-1, to provide higher bandwidth.
Adaptive (FDD) 40 MHz < Select this option. Select this option.
Bandwidth ≤ 60
MHz
6.2.1 Benefits
This function enables CA UEs to reach higher downlink peak data rates.
Table 6-2 lists the theoretical peak data rates that a CA UE can reach using
downlink 3CC aggregation.
For FDD, these values assume a TBS suitable for the 20 MHz cell bandwidth
(equivalent to 100 RBs in the frequency domain).
Table 6-2 Theoretical peak data rates for downlink 3CC aggregation (unit: Mbit/s)
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports a downlink peak data rate of 450 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 450 Mbit/s in the downlink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryDL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
6.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function requires additional RBs for PUCCH format-3 overhead. Therefore, the
downlink IBLER of the PCell fluctuates. The impact of this function on the PUCCH
overhead varies depending on the setting of the PucchSwitch option of the
CellAlgoSwitch.PucchAlgoSwitch parameter:
● Option selected to enable adaptive allocation of PUCCH resources
The cell spares one RB for PUCCH format-3 overhead. As a result, the number
of RBs available for the PUSCH decreases by at least one. (This number must
be a multiple of 2, 3, or 5. For details, see section 5.3.3 "Transform precoding"
in 3GPP TS 36.211 V10.1.0 (2011-03).) The total uplink throughput decreases.
● Option deselected to use fixed allocation of PUCCH resources
For FDD, the cell changes the usage of one PUCCH RB from periodic CQI
reporting to PUCCH format-3 overhead. As a result, fewer RBs of the cell are
used for periodic CQI reporting, and more UEs have to use aperiodic CQI
reporting. Downlink UE throughput may slightly decrease.
Function Impacts
RAT Function Function Reference Description
Name Switch
6.3 Requirements
6.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Switch Remarks
Name
6.3.3 Hardware
Base Station Models
For FDD, the following base stations are compatible with this function:
● 3900 and 5900 series base stations
● DBS3900 LampSite and DBS5900 LampSite
Boards
For details, see Boards in 5.3.3 Hardware.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
6.3.4 Networking
For details, see 5.3.4 Networking.
6.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate described in 6.2.1
Benefits, the maximum bit rate that each UE subscribes to in the EPC cannot
be lower than this theoretical value.
Moreover, for adaptive CA, prepare data as described in Table 6-5 for each
possible set of PCell and SCells on carriers whose aggregated bandwidth is
between 40 MHz and 60 MHz (inclusive).
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink 3CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink 3CC
aggregation is to be deployed in an eNodeB coordination scenario.
Counter Observation
If the counters listed in Table 6-6 produce non-zero values on a network that is
serving CA UEs capable of downlink 3CC aggregation, downlink 3CC aggregation
has taken effect in the network.
1526732907 L.Traffic.User.PCell.DL.3CC.Avg
1526732915 L.Traffic.User.PCell.DL.3CC.Active.Avg
Message Tracing
For the tools and IEs to observe, see Message Tracing in 5.4.2 Activation
Verification.
1526732907 L.Traffic.User.PCell.DL.3CC.Avg
1526732908 L.Traffic.User.PCell.DL.3CC.Max
1526732915 L.Traffic.User.PCell.DL.3CC.Active.Avg
1526732916 L.Traffic.User.PCell.DL.3CC.Active.Max
1526732917 L.CA.DL.PCell.3CC.Act.Dur
1526737809 L.Thrp.Time.DL.3CC.CAUser
1526733012 L.Thrp.bits.DL.3CC.CAUser
7.1 Principles
This function aggregates four intra- or inter-band carriers, as shown in Figure 7-1,
to provide higher bandwidth.
7.2.1 Benefits
This function enables CA UEs to reach higher downlink peak data rates.
Table 7-1 lists the theoretical peak data rates that a CA UE can reach using
downlink 4CC aggregation.
For FDD, these values assume a TBS suitable for the 20 MHz cell bandwidth
(equivalent to 100 RBs in the frequency domain).
Table 7-1 Theoretical peak data rates for downlink 4CC aggregation (unit: Mbit/s)
RAT 2x2 MIMO 2x2 MIMO 4x4 MIMO 4x4 MIMO
+ 64QAM + 256QAM + 64QAM + 256QAM
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports a downlink peak data rate of 450 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 450 Mbit/s in the downlink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryDL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
7.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function requires additional RBs for PUCCH format-3 overhead. Therefore, the
downlink IBLER of the PCell fluctuates. The impact of this function on the PUCCH
overhead varies depending on the setting of the PucchSwitch option of the
CellAlgoSwitch.PucchAlgoSwitch parameter:
● Option selected to enable adaptive allocation of PUCCH resources
The cell spares one RB for PUCCH format-3 overhead. As a result, the number
of RBs available for the PUSCH decreases by at least one. (This number must
be a multiple of 2, 3, or 5. For details, see section 5.3.3 "Transform precoding"
in 3GPP TS 36.211 V10.1.0 (2011-03).) The total uplink throughput decreases.
● Option deselected to use fixed allocation of PUCCH resources
For FDD, the cell changes the usage of one PUCCH RB from periodic CQI
reporting to PUCCH format-3 overhead. As a result, fewer RBs of the cell are
used for periodic CQI reporting, and more UEs have to use aperiodic CQI
reporting. Downlink UE throughput may slightly decrease.
Function Impacts
RAT Function Function Reference Description
Name Switch
7.3 Requirements
7.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Switch Reference
Name
7.3.3 Hardware
Base Station Models
For FDD, the following base stations are compatible with this function:
● 3900 and 5900 series base stations
● DBS3900 LampSite and DBS5900 LampSite
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition, do not use LBBPc boards, which do not support this function.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
7.3.4 Networking
For details, see 5.3.4 Networking.
7.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate described in 7.2.1
Benefits, the maximum bit rate that each UE subscribes to in the EPC cannot
be lower than this theoretical value.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink 4CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink 4CC
aggregation is to be deployed in an eNodeB coordination scenario.
1526737780 L.Traffic.User.PCell.DL.4CC.Avg
1526737793 L.Traffic.User.CA.4CC.PCell.DL.Active.Avg
Message Tracing
For the tools and IEs to observe, see Message Tracing in 5.4.2 Activation
Verification.
1526737780 L.Traffic.User.PCell.DL.4CC.Avg
1526737781 L.Traffic.User.PCell.DL.4CC.Max
1526737793 L.Traffic.User.CA.4CC.PCell.DL.Active.Avg
1526737794 L.Traffic.User.CA.4CC.PCell.DL.Active.Max
1526737812 L.Thrp.Time.DL.4CC.CAUser
1526737813 L.Thrp.bits.DL.4CC.CAUser
8.1 Principles
This function aggregates five intra- or inter-band carriers, as shown in Figure 8-1,
to provide higher bandwidth.
8.2.1 Benefits
This function enables CA UEs to reach higher downlink peak data rates.
Table 8-1 lists the theoretical peak data rates that a CA UE can reach using
downlink 5CC aggregation.
For FDD, these values assume a TBS suitable for the 20 MHz cell bandwidth
(equivalent to 100 RBs in the frequency domain).
Table 8-1 Theoretical peak data rates for downlink 5CC aggregation (unit: Mbit/s)
RAT 2x2 MIMO 2x2 MIMO 4x4 MIMO 4x4 MIMO
+ 64QAM + 256QAM + 64QAM + 256QAM
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports a downlink peak data rate of 450 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 450 Mbit/s in the downlink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryDL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
8.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function requires additional RBs for PUCCH format-3 overhead. Therefore, the
downlink IBLER of the PCell fluctuates. The impact of this function on the PUCCH
overhead varies depending on the setting of the PucchSwitch option of the
CellAlgoSwitch.PucchAlgoSwitch parameter:
● Option selected to enable adaptive allocation of PUCCH resources
The cell spares one RB for PUCCH format-3 overhead. As a result, the number
of RBs available for the PUSCH decreases by at least one. (This number must
be a multiple of 2, 3, or 5. For details, see section 5.3.3 "Transform precoding"
in 3GPP TS 36.211 V10.1.0 (2011-03).) The total uplink throughput decreases.
● Option deselected to use fixed allocation of PUCCH resources
For FDD, the cell changes the usage of one PUCCH RB from periodic CQI
reporting to PUCCH format-3 overhead. As a result, fewer RBs of the cell are
used for periodic CQI reporting, and more UEs have to use aperiodic CQI
reporting. Downlink UE throughput may slightly decrease.
Function Impacts
RAT Function Function Reference Description
Name Switch
8.3 Requirements
Table 8-2 lists the license models and sales units for these features.
8.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Switch Reference
Name
8.3.3 Hardware
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition:
● Do not use LBBPc boards, which do not support this function. Among BBPs,
UBBP is recommended.
● Among main control boards, UMPT is recommended.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
8.3.4 Networking
For details, see 5.3.4 Networking.
8.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate described in 8.2.1
Benefits, the maximum bit rate that each UE subscribes to in the EPC cannot
be lower than this theoretical value.
In addition, for either mode, prepare data as described in Table 8-3 and Table 8-4
for function activation and optimization.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink 5CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink 5CC
aggregation is to be deployed in an eNodeB coordination scenario.
Counter Observation
If the counters listed in Table 8-5 produce non-zero values on a network that is
serving CA UEs capable of downlink 5CC aggregation, downlink 5CC aggregation
has taken effect in the network.
1526739805 L.Traffic.User.PCell.DL.5CC.Avg
1526740442 L.Traffic.User.CA.5CC.PCell.DL.Active.Avg
Message Tracing
For the tools and IEs to observe, see Message Tracing in 5.4.2 Activation
Verification.
Calculate the throughput of UEs in the downlink 5CC aggregation state by using
the following formula: L.Thrp.bits.DL.5CC.CAUser/L.Thrp.Time.DL.5CC.CAUser.
1526739805 L.Traffic.User.PCell.DL.5CC.Avg
1526739806 L.Traffic.User.PCell.DL.5CC.Max
1526740442 L.Traffic.User.CA.5CC.PCell.DL.Active.Avg
1526740443 L.Traffic.User.CA.5CC.PCell.DL.Active.Max
1526740438 L.Thrp.Time.DL.5CC.CAUser
1526740439 L.Thrp.bits.DL.5CC.CAUser
9.1 Principles
This function aggregates six to eight intra- or inter-band carriers to provide a
higher bandwidth. Figure 9-1 uses 6CC aggregation as an example.
9.2.1 Benefits
This function enables CA UEs to reach higher downlink peak data rates.
Table 9-1 lists the theoretical peak data rates that a CA UE can reach using
downlink 6CC, 7CC, and 8CC aggregation.
These values assume a TBS suitable for the 20 MHz cell bandwidth (equivalent to
100 RBs in the frequency domain).
Table 9-1 Theoretical peak data rates for downlink 6CC, 7CC, and 8CC
aggregation (unit: Mbit/s)
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports a downlink peak data rate of 450 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 450 Mbit/s in the downlink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryDL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
9.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function has the following impacts on the network:
● Additional RBs are required for PUCCH format-5 overhead. The impact varies
depending on the setting of the PucchSwitch option of the
CellAlgoSwitch.PucchAlgoSwitch parameter:
– Option selected to enable adaptive allocation of PUCCH resources
The PCell spares two RBs for PUCCH format-5 overhead. As a result, the
number of RBs available for the PUSCH decreases by at least two. (This
number must be a multiple of 2, 3, or 5. For details, see section 5.3.3
"Transform precoding" in 3GPP TS 36.211 V10.1.0 (2011-03).) Total uplink
throughput decreases.
– Option deselected to use fixed allocation of PUCCH resources
The PCell changes the usage of two PUCCH RBs from periodic CQI
reporting to PUCCH format-5 overhead. As a result, fewer RBs of the cell
are used for periodic CQI reporting, and more UEs have to use aperiodic
CQI reporting. Downlink UE throughput may slightly decrease.
Function Impacts
Function Function Reference Description
Name Switch
UMTS and LTE UMTS_LTE_ZER UMTS and LTE There are fewer PUSCH
Zero Bufferzone O_BUFFER_ZO Zero Bufferzone and SRS resources in a
NE_SW option cell in the bufferzone
of the than in a common cell.
ULZeroBufferZ Therefore, when the LTE
one.ZeroBufZo bandwidth is 5 MHz or
neSwitch 10 MHz, using a cell in
parameter the bufferzone as a PCell
for CA is not
recommended. If the cell
is used as a PCell, CA
performance
deteriorates.
LTE FDD and SpectrumCloud LTE FDD and LTE cells with LTE FDD
NR Flash .SpectrumClou NR Spectrum and NR Flash Dynamic
Dynamic dSwitch Sharing Spectrum Sharing
Spectrum parameter with enabled are not
Sharing the value of recommended as PCells.
LTE_NR_SPECT If these cells act as
RUM_SHR PCells, the PUCCH
overhead is so large that
SRSs cannot be
configured. Therefore,
the LTE network
throughput decreases.
LTE FDD and SpectrumCloud LTE FDD and LTE cells with LTE FDD
NR Uplink .SpectrumClou NR Uplink and NR Uplink Spectrum
Spectrum dSwitch Spectrum Sharing enabled are not
Sharing parameter with Sharing recommended as PCells.
the value of If these cells act as
LTE_NR_UPLIN PCells, the PUCCH
K_SPECTRUM_ overhead is so large that
SHR SRSs cannot be
configured. Therefore,
the LTE network
throughput is affected.
GSM and LTE SpectrumCloud GSM and LTE LTE cells with GSM and
spectrum .SpectrumClou Spectrum LTE spectrum
concurrency dSwitch Concurrency concurrency enabled are
parameter with not recommended as
the value of PCells. If these cells act
GL_SPECTRUM as PCells, the PUCCH
_CONCURRENC overhead is so large that
Y SRSs cannot be
configured. Therefore,
the LTE network
throughput is affected.
9.3 Requirements
9.3.1 Licenses
Each FDD cell involved in downlink massive CA has the following license
requirements:
● Each FDD cell requires one sales unit for each of the following features:
– LAOFD-001001 LTE-A Introduction
– LAOFD-080207 Carrier Aggregation for Downlink 3CC in 40MHz
– LEOFD-110303 Carrier Aggregation for Downlink 4CC and 5CC
– LEOFD-151308 Downlink Massive CA
● If the aggregated bandwidth of any two of the cells exceeds 20 MHz, each of
the two cells also requires one sales unit of the license for LAOFD-001002
Carrier Aggregation for Downlink 2CC in 40MHz.
● If the aggregated bandwidth of any three of the cells exceeds 40 MHz, each
of the three cells also requires one sales unit of the license for LAOFD-080208
Carrier Aggregation for Downlink 3CC in 60MHz.
Table 9-2 lists the license models and sales units for these features.
9.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
Function Name Function Switch Reference
9.3.3 Hardware
Base Station Models
The following base stations are compatible with this function:
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition, note that:
● BBU3910A and BBU3910C cannot be used for this function.
● LBBPc and UBBPex2 boards cannot be used for this function.
● Only cells on UBBPd, UBBPe, or UBBPg boards can act as PCells.
● The main control boards of the serving eNodeBs for PCells must be UMPT
boards.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
9.3.4 Networking
For details, see 5.3.4 Networking.
9.3.5 Others
● UEs
UEs must comply with 3GPP Release 13 or later and support the frequency
bands of the carriers to be aggregated and their channel bandwidths. UEs
must also support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate described in 9.2.1
Benefits, the maximum bit rate that each UE subscribes to in the EPC cannot
be lower than this theoretical value.
Table 9-3 and Table 9-4 describe the parameters used for function activation and
optimization, respectively.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if downlink massive
CA is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink massive
CA is to be deployed in an eNodeB coordination scenario.
1526749452 L.Traffic.User.PCell.DL.6CC.Avg
1526749489 L.Traffic.User.CA.6CC.PCell.DL.Active.Avg
1526749453 L.Traffic.User.PCell.DL.7CC.Avg
1526749490 L.Traffic.User.CA.7CC.PCell.DL.Active.Avg
1526749454 L.Traffic.User.PCell.DL.8CC.Avg
1526749491 L.Traffic.User.CA.8CC.PCell.DL.Active.Avg
Message Tracing
For the tools and the IEs to observe, see Message Tracing in 5.4.2 Activation
Verification.
1526749452 L.Traffic.User.PCell.DL.6CC.Avg
1526749489 L.Traffic.User.CA.6CC.PCell.DL.Active.Avg
1526749453 L.Traffic.User.PCell.DL.7CC.Avg
1526749490 L.Traffic.User.CA.7CC.PCell.DL.Active.Avg
1526749454 L.Traffic.User.PCell.DL.8CC.Avg
1526749491 L.Traffic.User.CA.8CC.PCell.DL.Active.Avg
1526749443 L.Thrp.Time.DL.6CC.CAUser
1526749440 L.Thrp.bits.DL.6CC.CAUser
1526749444 L.Thrp.Time.DL.7CC.CAUser
1526749441 L.Thrp.bits.DL.7CC.CAUser
1526749445 L.Thrp.Time.DL.8CC.CAUser
1526749442 L.Thrp.bits.DL.8CC.CAUser
10 Flexible CA
10.1 Principles
This function allows an eNodeB to select the most suitable carriers for downlink
CA from a larger number of candidate carriers, as shown in Figure 10-1. The
selections are based on the CA capabilities reported by the CA UE and on carrier
management principles.
10.2.1 Benefits
This function enables an eNodeB to select the most suitable carriers for downlink
CA from a larger number of candidate carriers.
For the theoretical peak data rates that a CA UE can reach using downlink 2CC,
3CC, 4CC, or 5CC aggregation, see the "Benefits" sections that describe these
downlink CA functions.
For the theoretical peak data rates that a CA UE can reach using downlink FDD
6CC–8CC aggregation, see 9.2.1 Benefits.
10.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
None
Function Impacts
RAT Function Function Reference Description
Name Switch
FDD LTE FDD and SpectrumClo LTE FDD and The selected serving
NR Flash ud.Spectrum NR Spectrum cell combination may
Dynamic CloudSwitch Sharing change.
Spectrum parameter
Sharing with the value
of
LTE_NR_SPEC
TRUM_SHR
FDD LTE FDD and SpectrumClo LTE FDD and The selected serving
NR Uplink ud.Spectrum NR Uplink cell combination may
Spectrum CloudSwitch Spectrum change.
Sharing parameter Sharing
with the value
of
LTE_NR_UPLI
NK_SPECTRU
M_SHR
10.3 Requirements
Table 10-1 lists the license models and sales units for these features.
10.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
10.3.3 Hardware
Boards
For details, see Boards in 5.3.3 Hardware.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
10.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition, the
number of frequencies on the live network must be greater than or equal to three.
10.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate for downlink 2CC, 3CC,
4CC, or 5CC aggregation, the maximum bit rate that each UE subscribes to in
the EPC cannot be lower than this theoretical value. For the theoretical values,
see the relevant "Benefits" sections.
11.1 Principles
11.1.1 Overview
Intelligent selection of serving cell combinations can be used when CA is working
in adaptive configuration mode. With this function, the eNodeB selects the most
suitable serving cell combination for a CA UE based on the CA capabilities
reported by the UE and based on factors such as the coverage overlap between
cells, cell load status, bandwidths, and spectral efficiency. The eNodeB then
informs the UE of the combination.
If CA has been deployed with PCC anchoring for RRC_CONNECTED UEs enabled
before this intelligent selection function is activated, the serving cell combinations
selected after the function activation might be different from those selected
before the activation. As a result, the CA UE distribution may change. (PCC
anchoring for RRC_CONNECTED UEs is controlled by the
EnhancedPccAnchorSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter.)
11.1.2 Triggers
The triggering scenarios are as follows:
● During initial access, an incoming RRC connection reestablishment, or an
incoming handover of a CA UE, the eNodeB initiates a procedure for
intelligent selection of serving cell combinations after it receives UE
capabilities reported by the UE.
● The eNodeB initiates a procedure for intelligent selection of serving cell
combinations for a UE again after an E-RAB, with a QCI for which the
SMART_CA_ALLOWED option of the CellQciPara.QciAlgoSwitch parameter
is selected, is set up. In this situation, the eNodeB selects the most suitable
serving cell combination for the UE again.
● With PCC anchoring for RRC_CONNECTED UEs enabled (by selecting the
EnhancedPccAnchorSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter)
During initial access, an incoming RRC connection reestablishment, or an
incoming coverage-based handover of a CA UE, the eNodeB delivers A1
measurement configurations related to PCC anchoring for RRC_CONNECTED
UEs to the UE. After the UE reports event A1, the eNodeB initiates a
procedure for intelligent selection of serving cell combinations. This event A1
is reported only once.
The RSRP threshold for event A1 involved in PCC anchoring for
RRC_CONNECTED UEs is specified by the
CaMgtCfg.EnhancedPccAnchorA1ThdRsrp parameter.
● With A1-based enhanced SCell selection enabled (by setting the
CaMgtCfg.EnhancedSccSelA1ThldRsrp parameter to a value other than –40
dBm)
During initial access, an incoming RRC connection reestablishment, or an
incoming coverage-based handover of a CA UE, the eNodeB delivers A1
measurement configurations related to A1-based enhanced SCell selection to
the UE. After the UE reports event A1, the eNodeB initiates a procedure for
intelligent selection of serving cell combinations. This event A1 is reported
only once.
The RSRP threshold for event A1 involved in enhanced SCell selection is
specified by the CaMgtCfg.EnhancedSccSelA1ThldRsrp parameter.
● With both PCC anchoring for RRC_CONNECTED UEs and A1-based enhanced
SCell selection enabled
During initial access, an incoming RRC connection reestablishment, or an
incoming coverage-based handover of a CA UE, the eNodeB first delivers A1
measurement configurations related to A1-based enhanced SCell selection to
the UE. After the UE reports event A1, the eNodeB initiates a procedure for
intelligent selection of serving cell combinations. When this procedure is
complete, the eNodeB delivers A1 measurement configurations related to PCC
anchoring for RRC_CONNECTED UEs to the UE. After the UE reports event A1,
the eNodeB initiates another procedure for intelligent selection of serving cell
combinations.
It is recommended that the RSRP threshold for event A1 involved in enhanced
SCell selection be lower than that for event A1 involved in PCC anchoring for
RRC_CONNECTED UEs.
▪ Option deselected
○ If the UE's PCell is included in the candidate cells, which have a
higher duplex mode priority and the highest PCC priority, the
eNodeB keeps the PCell unchanged for the UE.
○ If the UE's PCell is not included in the candidate cells, the
eNodeB randomly selects one from the candidate cells as the
PCell.
– With the CaMgtCfg.SmartCaPccAnchoringHyst parameter set to a non-
zero value:
For this function to deliver its optimal performance, it is recommended that the
CaUl2CCSwitch option of the CaMgtCfg.CellCaAlgoSwitch parameter be
selected for all possible PCells and SCells.
11.2.1 Benefits
This function enables an eNodeB to select the most suitable carriers for CA from a
larger number of candidate carriers.
For the theoretical peak data rates that a CA UE can reach using downlink 2CC,
3CC, 4CC, or 5CC aggregation or using uplink 2CC aggregation, see the "Benefits"
sections that describe these CA functions.
11.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
● Intelligent selection of serving cell combinations changes the distribution of
PCells and SCells of CA UEs in frequency bands. These changes may, in turn,
make alterations to performance indicators such as the traffic volume of each
band and the CPU usage.
● If the EnhancedPccAnchorSwitch option of the
ENodeBAlgoSwitch.CaAlgoSwitch parameter is selected, intelligent selection
of serving cell combinations causes an increase in the number of inter-
frequency handovers for PCC anchoring. The service drop rate may rise for
UEs with abnormal performance in handovers.
In this situation, if the SmartCaPccSelSwitch option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter is selected, there will be a
further increase in the number of inter-frequency handovers for PCC
anchoring. The service drop rate may further rise for UEs with abnormal
performance in handovers.
● If intelligent selection of uplink serving cell combinations is enabled, the
number of UEs in the uplink CA state increases and the CPU usage of BBPs
rises. In addition, the CPU usage of the main control board may vary, affecting
the RRC connection setup success rate and delay.
● If PCC anchoring for NSA DC is enabled at an eNodeB, this function will select
PCells for UEs that support NSA DC, after the UEs access the cells served by
the eNodeB. Intelligent selection of serving cell combinations can select only
SCells but cannot change PCells for these UEs.
Function Impacts
RAT Function Function Reference Description
Name Switch
FDD LTE FDD and SpectrumClo LTE FDD and The selected serving
NR Flash ud.Spectrum NR Spectrum cell combination may
Dynamic CloudSwitch Sharing change.
Spectrum parameter
Sharing with the value
of
LTE_NR_SPEC
TRUM_SHR
FDD LTE FDD and SpectrumClo LTE FDD and The selected serving
NR Uplink ud.Spectrum NR Uplink cell combination may
Spectrum CloudSwitch Spectrum change.
Sharing parameter Sharing
with the value
of
LTE_NR_UPLI
NK_SPECTRU
M_SHR
11.3 Requirements
Table 11-1 lists the license models and sales units for these features.
11.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
11.3.3 Hardware
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition, LMPT cannot be used for intelligent selection of uplink serving cell
combinations or for the functions controlled by the
CaMgtCfg.SmartCaPccAnchoringHyst and
CaMgtCfg.MinDlAvgToBeScheduledUeNum parameters.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
11.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition:
● There must be at least three frequencies on the live network.
● For inter-eNodeB CA, X2 interfaces must be functioning.
They are required for load status exchange, signaling exchange, and user data
transmission between eNodeBs. If the X2 interfaces are not correctly
configured, appropriate serving cell combinations cannot be selected for inter-
eNodeB CA.
Due to X2-related protocol specifications, eNodeBs can exchange information
about only eight frequencies. Certain inter-eNodeB CA combinations may fail
to take effect if there are more than eight frequencies on which inter-
frequency neighboring cells with EutranInterFreqNCell.OverlapInd set to
YES or with CaGroupSCellCfg.SCellBlindCfgFlag set to TRUE are operating.
11.3.5 Others
For details, see 10.3.5 Others.
Table 11-2 and Table 11-3 describe the parameters used for function activation
and optimization, respectively.
● Single/Batch configuration
This function can be activated for a single base station or a batch of base
stations on the MAE-Deployment. For detailed operations, see Feature
Configuration Using the MAE-Deployment.
12 Downlink FDD+TDD CA
12.1 Principles
Downlink FDD+TDD CA aggregates two to eight downlink FDD and TDD CCs.
Figure 12-1 uses 5CC aggregation as an example.
▪ UE capabilities
○ The UE complies with 3GPP Release 12 or earlier and supports
FDD+TDD CA.
If the UE capability message carries the tdd-FDD-CA-
PCellDuplex-r12 IE, the eNodeB configures an FDD or TDD cell
as the PCell based on the reported UE capabilities.
If the message does not carry the tdd-FDD-CA-PCellDuplex-r12
IE, the eNodeB configures an FDD or TDD cell as the PCell based
on the FddTddCaPcellDuplexFdd or FddTddCaPcellDuplexTdd
option setting of the
ENodeBAlgoSwitch.CompatibilityCtrlSwitch parameter.
○ The UE complies with 3GPP Release 13 or later and supports
FDD+TDD CA.
The eNodeB configures an FDD or TDD cell as the PCell based
on the reported UE capabilities.
Both FDD and TDD carriers can act as SCCs. For details about the SCell
configuration procedure in this situation, see 4.6.3.1.2 CA-Group-based
SCell Configuration Procedure and 4.6.3.1.3 Adaptive SCell
Configuration Procedure.
Usage Scenarios
This function works in both intra- and inter-eNodeB scenarios:
● Intra-eNodeB
In intra-eNodeB scenarios, FDD and TDD cells are served by the same
eNodeB. For details, see 3.3.1 Intra-eNodeB CA Scenarios.
● Inter-eNodeB
Inter-eNodeB scenarios include:
– Relaxed backhaul
For details, see 15 Inter-eNodeB CA Based on Relaxed Backhaul.
– Centralized eNodeB coordination
For details, see 16 Inter-eNodeB CA Based on eNodeB Coordination.
Subframe Configurations
TDD cells for CA must use uplink-downlink configuration 1 or 2 and one of special
subframe configurations 4, 5, 6, 7, and 9. A TDD cell using special subframe
configuration 4 cannot work with another TDD cell using special subframe
configuration 5, 6, 7, or 9 for CA. TDD cells served by LampSite eNodeBs can only
use special subframe configurations 6 and 7.
Table 12-1 lists the supported FDD+TDD CC combinations, which vary depending
on the PCell duplex mode and TDD subframe configuration.
Table 12-1 FDD+TDD CC combinations supported (by PCell duplex mode and TDD
subframe configuration)
12.2.1 Benefits
This function deals with spectrum shortages by utilizing both FDD and TDD
spectrum resources, addresses mobile broadband service competition, and
improves service quality.
The theoretical peak data rates that downlink FDD+TDD CA can reach are as
follows:
● Theoretical peak data rate for downlink 2CC aggregation = Theoretical peak
data rate on a single FDD carrier in the downlink + Theoretical peak data rate
on a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 3CC aggregation = Theoretical peak
data rate on two FDD carriers in the downlink + Theoretical peak data rate on
a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 4CC aggregation = Theoretical peak
data rate on three FDD carriers in the downlink + Theoretical peak data rate
on a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 5CC aggregation = Theoretical peak
data rate on four FDD carriers in the downlink + Theoretical peak data rate
on a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 6CC aggregation = Theoretical peak
data rate on five FDD carriers in the downlink + Theoretical peak data rate on
a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 7CC aggregation = Theoretical peak
data rate on six FDD carriers in the downlink + Theoretical peak data rate on
a single TDD carrier in the downlink
● Theoretical peak data rate for downlink 8CC aggregation = Theoretical peak
data rate on seven FDD carriers in the downlink + Theoretical peak data rate
on a single TDD carrier in the downlink
12.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function has the following impacts on the network:
● When an FDD carrier is working as the PCC and TDD carriers are working as
SCCs for a CA UE:
The downlink TDD spectrum resources are fully utilized, which increases the
downlink data rate. The FDD PCC also provides better uplink coverage for the
CA UE than a TDD PCC would do.
● When a TDD carrier is working as the PCC:
– The TDD PCC can obtain beamforming gains, represented by an increased
downlink data rate. However, in certain scenarios, TTI bundling may be
triggered due to the limited number of bits for ACK/NACK over the
PUCCH in the TDD PCell, causing the downlink data rate to drop on each
CC. TTI bundling may be triggered when:
Aggregation of more than five CCs has the following additional impacts on the
network:
● Additional RBs are required for PUCCH format-5 overhead. The impact varies
depending on the setting of the PucchSwitch option of the
CellAlgoSwitch.PucchAlgoSwitch parameter:
– Option selected to enable adaptive allocation of PUCCH resources
The PCell spares two RBs for PUCCH format-5 overhead. As a result, the
number of RBs available for the PUSCH decreases by at least two. (This
number must be a multiple of 2, 3, or 5. For details, see section 5.3.3
"Transform precoding" in 3GPP TS 36.211 V10.1.0 (2011-03).) Total uplink
throughput decreases.
– Option deselected to use fixed allocation of PUCCH resources
The PCell changes the usage of two PUCCH RBs from periodic CQI
reporting to PUCCH format-5 overhead. As a result, fewer RBs of the cell
are used for periodic CQI reporting, and more UEs have to use aperiodic
CQI reporting. Downlink UE throughput may slightly decrease.
● The total number of bits of HARQ feedback transmitted on the PUSCH
increases. This reduces the spectral efficiency of the PUSCH and decreases
uplink throughput.
● More messages are exchanged in inter-BBU CA scenarios, and the values of
the VS.SctpLnk.RxMeanSpeed and VS.SctpLnk.TxMeanSpeed counters
increase.
Function Impacts
● Functions in the category "RAN functions"
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Flash oud.Spectru NR Spectrum the number of
Dynamic mCloudSwit Sharing downlink RBs
Spectrum ch available for LTE.
Sharing parameter Therefore, the
with the throughput of UEs in
value of the downlink FDD
LTE_NR_SPE CA state decreases.
CTRUM_SHR
FDD GSM and LTE SpectrumCl GSM and LTE Cells with 5 MHz
spectrum oud.Spectru Spectrum bandwidth are not
concurrency mCloudSwit Concurrency recommended as
ch PCells. If these cells
parameter act as PCells, the
with the PUCCH overhead is
value of so large that SRSs
GL_SPECTRU cannot be
M_CONCUR configured.
RENCY
FDD UMTS and LTE UMTS_LTE_ZERO UMTS and LTE There are fewer PUSCH and
Zero Bufferzone _BUFFER_ZONE_ Zero Bufferzone SRS resources in a cell in
SW option of the the bufferzone than in a
ULZeroBufferZo common cell. Therefore,
ne.ZeroBufZoneS when the LTE bandwidth is
witch parameter 5 MHz or 10 MHz, using a
cell in the bufferzone as a
PCell for CA is not
recommended. If the cell is
used as a PCell, CA
performance deteriorates.
FDD LTE FDD and NR SpectrumCloud. LTE FDD and NR LTE cells with LTE FDD and
Flash Dynamic SpectrumCloudS Spectrum Sharing NR Flash Dynamic
Spectrum Sharing witch parameter Spectrum Sharing enabled
with the value of are not recommended as
LTE_NR_SPECTR PCells. If these cells act as
UM_SHR PCells, the PUCCH
overhead is so large that
SRSs cannot be configured.
Therefore, the LTE network
throughput decreases.
FDD LTE FDD and NR SpectrumCloud.S LTE FDD and NR LTE cells with LTE FDD and
Uplink Spectrum pectrumCloudS Uplink Spectrum NR Uplink Spectrum
Sharing witch parameter Sharing Sharing enabled are not
with the value of recommended as PCells. If
LTE_NR_UPLINK_ these cells act as PCells, the
SPECTRUM_SHR PUCCH overhead is so large
that SRSs cannot be
configured. Therefore, the
LTE network throughput is
affected.
FDD GSM and LTE SpectrumCloud.S GSM and LTE LTE cells with GSM and LTE
spectrum pectrumCloudS Spectrum spectrum concurrency
concurrency witch parameter Concurrency enabled are not
with the value of recommended as PCells. If
GL_SPECTRUM_C these cells act as PCells, the
ONCURRENCY PUCCH overhead is so large
that SRSs cannot be
configured. Therefore, the
LTE network throughput is
affected.
FDD UMTS and LTE SpectrumCloud. UMTS and LTE Downlink massive CA is not
spectrum sharing SpectrumCloudS Spectrum Sharing recommended for cells with
witch parameter UMTS and LTE spectrum
with the value of sharing enabled.
UL_SPECTRUM_S
HARING
12.3 Requirements
12.3.1 Licenses
Each FDD cell involved in downlink FDD+TDD CA requires one sales unit of the
license for MRFD-101222 FDD+TDD Downlink Carrier Aggregation(LTE FDD).
Each TDD cell involved in downlink FDD+TDD CA requires one sales unit of the
license for MRFD-101231 FDD+TDD Downlink Carrier Aggregation(LTE TDD).
In addition:
● If six to eight cells are involved in downlink FDD+TDD CA:
– Each of the FDD cells requires one sales unit of the license for
MRFD-151309 FDD+TDD Downlink Massive CA(LTE FDD).
– Each of the TDD cells requires one sales unit of the license for
MRFD-151401 FDD+TDD Downlink Massive CA(LTE TDD).
● If two or more FDD cells are involved in downlink FDD+TDD CA, the licensing
principles for these cells are the same as those described in the corresponding
"Licenses" section.
● If two or more TDD cells are involved in downlink FDD+TDD CA, the licensing
principles for these cells are the same as those described in the corresponding
"Licenses" section.
Table 12-2 lists the license models and sales units for these features.
1F+1T Intra- Each cell requires one Each cell requires one
eNodeB sales unit of the license sales unit of the license
for MRFD-101222 FDD for MRFD-101231 FDD
+TDD Downlink Carrier +TDD Downlink Carrier
Aggregation(LTE FDD). Aggregation(LTE TDD).
1F+1T FDD cell and Each cell requires one Each cell requires one
TDD cell sales unit of the license sales unit of the license
being served for MRFD-101222 FDD for MRFD-101231 FDD
by different +TDD Downlink Carrier +TDD Downlink Carrier
eNodeBs Aggregation(LTE FDD). Aggregation(LTE TDD).
2F+1T Intra- Each cell requires one Each cell requires one
eNodeB sales unit of the license sales unit of the license
for each of the for MRFD-101231 FDD
following features: +TDD Downlink Carrier
● MRFD-101222 FDD Aggregation(LTE TDD).
+TDD Downlink
Carrier
Aggregation(LTE
FDD)
● LAOFD-001001 LTE-
A Introduction
2F+1T ● FDD: two Each cell requires one Each cell requires one
intra- sales unit of the license sales unit of the license
eNodeB for each of the for MRFD-101231 FDD
cells following features: +TDD Downlink Carrier
● FDD cells ● MRFD-101222 FDD Aggregation(LTE TDD).
and TDD +TDD Downlink
cell being Carrier
served by Aggregation(LTE
different FDD)
eNodeBs ● LAOFD-001001 LTE-
A Introduction
2F+1T ● FDD: two Each cell requires one Each cell requires one
inter- sales unit of the license sales unit of the license
eNodeB for each of the for MRFD-101231 FDD
cells in a following features: +TDD Downlink Carrier
relaxed ● MRFD-101222 FDD Aggregation(LTE TDD).
backhaul +TDD Downlink
scenario Carrier
● FDD cells Aggregation(LTE
and TDD FDD)
cell being ● LAOFD-001001 LTE-
served by A Introduction
different
eNodeBs In addition, the serving
eNodeB of each FDD
cell requires one sales
unit of the license for
LAOFD-080201 Inter-
eNodeB CA Based on
Relaxed Backhaul.
2F+2T Intra- Each cell requires one Each cell requires one
eNodeB sales unit of the license sales unit of the license
for each of the for each of the
following features: following features:
● MRFD-101222 FDD ● MRFD-101231 FDD
+TDD Downlink +TDD Downlink
Carrier Carrier
Aggregation(LTE Aggregation(LTE
FDD) TDD)
● LAOFD-001001 LTE- ● TDLAOFD-001001
A Introduction LTE-A Introduction
2F+2T ● FDD: two Each cell requires one Each cell requires one
intra- sales unit of the license sales unit of the license
eNodeB for each of the for each of the
cells following features: following features:
● TDD: two ● MRFD-101222 FDD ● MRFD-101231 FDD
inter- +TDD Downlink +TDD Downlink
eNodeB Carrier Carrier
cells in a Aggregation(LTE Aggregation(LTE
relaxed FDD) TDD)
backhaul ● LAOFD-001001 LTE- ● TDLAOFD-001001
scenario A Introduction LTE-A Introduction
In addition, each of the
serving eNodeBs for the
TDD cells requires one
sales unit of the license
for TDLAOFD-081402
Inter-eNodeB CA Based
on Relaxed Backhaul.
2F+2T ● FDD: two Each cell requires one Each cell requires one
inter- sales unit of the license sales unit of the license
eNodeB for each of the for each of the
cells in an following features: following features:
eNodeB ● MRFD-101222 FDD ● MRFD-101231 FDD
coordinati +TDD Downlink +TDD Downlink
on Carrier Carrier
scenario Aggregation(LTE Aggregation(LTE
● TDD: two FDD) TDD)
intra- ● LAOFD-001001 LTE- ● TDLAOFD-001001
eNodeB A Introduction LTE-A Introduction
cells
In addition, each of the
serving eNodeBs for the
FDD cells requires one
sales unit of the license
for LAOFD-070202
Inter-eNodeB CA based
on Coordinated
eNodeB.
2F+4T Intra- Each cell requires one Each cell requires one
eNodeB sales unit of the license sales unit of the license
for each of the for each of the
following features: following features:
● MRFD-101222 FDD ● MRFD-101231 FDD
+TDD Downlink +TDD Downlink
Carrier Carrier
Aggregation(LTE Aggregation(LTE
FDD) TDD)
● MRFD-151309 FDD ● MRFD-151401 FDD
+TDD Downlink +TDD Downlink
Massive CA(LTE Massive CA(LTE
FDD) TDD)
● LAOFD-001001 LTE- ● TDLAOFD-001001
A Introduction LTE-A Introduction
● TDLAOFD-081405
Carrier Aggregation
for Downlink 3CC
● TDLEOFD-081504
Carrier Aggregation
for Downlink 4CC
and 5CC
2F+4T ● FDD: two Each cell requires one Each cell requires one
inter- sales unit of the license sales unit of the license
eNodeB for each of the for each of the
cells in an following features: following features:
eNodeB ● MRFD-101222 FDD ● MRFD-101231 FDD
coordinati +TDD Downlink +TDD Downlink
on Carrier Carrier
scenario Aggregation(LTE Aggregation(LTE
● TDD: four FDD) TDD)
intra- ● MRFD-151309 FDD ● MRFD-151401 FDD
eNodeB +TDD Downlink +TDD Downlink
cells Massive CA(LTE Massive CA(LTE
FDD) TDD)
● LAOFD-001001 LTE- ● TDLAOFD-001001
A Introduction LTE-A Introduction
Moreover, each of the ● TDLAOFD-081405
serving eNodeBs for the Carrier Aggregation
two FDD cells requires for Downlink 3CC
one sales unit of the
license for ● TDLEOFD-081504
LAOFD-070202 Inter- Carrier Aggregation
eNodeB CA based on for Downlink 4CC
Coordinated eNodeB. and 5CC
2F+4T ● FDD: two Each cell requires one Each cell requires one
intra- sales unit of the license sales unit of the license
eNodeB for each of the for each of the
cells following features: following features:
● TDD: four ● MRFD-101222 FDD ● MRFD-101231 FDD
inter- +TDD Downlink +TDD Downlink
eNodeB Carrier Carrier
cells in a Aggregation(LTE Aggregation(LTE
relaxed FDD) TDD)
backhaul ● MRFD-151309 FDD ● MRFD-151401 FDD
scenario +TDD Downlink +TDD Downlink
Massive CA(LTE Massive CA(LTE
FDD) TDD)
● LAOFD-001001 LTE- ● TDLAOFD-001001
A Introduction LTE-A Introduction
● TDLAOFD-081405
Carrier Aggregation
for Downlink 3CC
● TDLEOFD-081504
Carrier Aggregation
for Downlink 4CC
and 5CC
In addition, each of the
serving eNodeBs for the
four TDD cells requires
one sales unit of the
license for
TDLAOFD-081402
Inter-eNodeB CA Based
on Relaxed Backhaul.
12.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
● TDD
There are no mutually exclusive functions.
12.3.3 Hardware
Base Station Models
When the total number of FDD and TDD carriers aggregated in the downlink is
less than or equal to five, there are no requirements on base station models.
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition, note that:
● Do not use LBBPc boards, which do not support this function. If a physical cell
of an SFN cell is established on an LBBPc board, this function cannot be used
with the SFN cell either.
● Do not use an FDD cell on any LBBPd4 board as the PCell for aggregation of
three or more downlink FDD and TDD CCs. Otherwise, the aggregation will
not work.
● When the total number of FDD and TDD carriers aggregated in the downlink
exceeds five, the following constraints also apply:
– BBU3910A and BBU3910C cannot be used for this function.
– LBBPc and UBBPex2 boards cannot be used for this function.
– Only cells on FDD UBBPd, UBBPe, or UBBPg boards can act as PCells.
– The main control boards of the serving eNodeBs for PCells must be UMPT
boards.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
Cells
For details, see Subframe Configurations in 12.1 Principles.
12.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition:
● eNodeBs must be time-synchronized (with the TASM.CLKSYNCMODE
parameter set to TIME). The time alignment error must be within:
– 130 ns between two contiguous CCs.
– 260 ns between two non-contiguous CCs.
● If this function is to be deployed in a relaxed backhaul scenario, the inter-
eNodeB one-way delay must be less than or equal to 4 ms and the RTT must
be less than or equal to 8 ms. Moreover, the requirements described in 15.3.4
Networking must be fulfilled.
● If this function is to be deployed in an eNodeB coordination scenario, the
requirements described in 16.3.4 Networking must be fulfilled.
● When this function is used together with LTE and NR uplink spectrum sharing,
the following requirements must be met:
– If LTE TDD and NR TDD are deployed in the same band and both LTE and
NR uplink spectrum sharing and uplink and downlink decoupling are
deployed in an LTE FDD band, LTE and NR uplink spectrum sharing does
not work with FDD+TDD CA.
– If LTE TDD and NR TDD are deployed in different bands and both LTE and
NR uplink spectrum sharing and uplink and downlink decoupling are
deployed in an LTE FDD band, FDD+TDD CA can be deployed in these
bands so long as the following conditions are fulfilled:
▪ The in-use frame offset of the LTE TDD cell (specified by the
CellFrameOffset.FrameOffset or
ENodeBFrameOffset.TddFrameOffset parameter) is greater than
that of the LTE FDD cell (specified by the
CellFrameOffset.FrameOffset or
ENodeBFrameOffset.FddFrameOffset parameter). In addition, the
difference between them is equal to the timing advance (TA) offset
of the NR TDD cell (specified by the NR parameter
NRDUCell.TaOffset). Table 12-4 provides the details.
▪ The in-use frame offset of the LTE TDD cell is equal to that of the NR
TDD cell (specified by the gNodeBParam.FrameOffset parameter).
The in-use frame offset values of LTE FDD, LTE TDD, and NR TDD cells
have the following relationships with their respective parameter settings:
▪ If the configured value is within the range of 0 Ts to 3072 Ts, the in-
use value is equal to the configured value.
Table 12-4 Requirements on the in-use frame offset values for LTE TDD,
LTE FDD, and NR TDD cells
12.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
Downlink FDD+TDD massive CA requires UEs to comply with 3GPP Release 13
or later.
● EPC
For this function to reach a theoretical peak data rate, the maximum bit rate
that each UE subscribes to in the EPC cannot be lower than this theoretical
value. For the theoretical values, see 12.2.1 Benefits.
In addition, for either mode, prepare data as described in Table 12-5 and Table
12-6 for function activation and optimization.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in the relevant "Data Preparation" sections if two,
three, four, or five FDD and TDD CCs need to be aggregated in the downlink.
● Prepare data as described in 16.4.1.1 Data Preparation if downlink FDD+TDD
CA is to be deployed in an eNodeB coordination scenario.
● Prepare data as described in 15.4.1.1 Data Preparation if downlink FDD+TDD
CA is to be deployed in a relaxed backhaul scenario.
● Prepare the data described in Table 12-7 and Table 12-8 if downlink FDD
+TDD massive CA is required. Downlink FDD+TDD massive CA works only in
adaptive configuration mode.
1526737782 L.Traffic.User.FddTddCA.PCell.DL.Avg
1526737795 L.Traffic.User.FddTddCA.PCell.DL.Active.A
vg
1526737776 L.Traffic.User.FddTddCA.3CC.PCell.DL.Avg
1526737797 L.Traffic.User.FddTddCA.
3CC.PCell.DL.Active.Avg
1526737778 L.Traffic.User.FddTddCA.4CC.PCell.DL.Avg
1526737799 L.Traffic.User.FddTddCA.
4CC.PCell.DL.Active.Avg
1526741758 L.Traffic.User.FddTddCA.5CC.PCell.DL.Avg
1526741735 L.Traffic.User.FddTddCA.
5CC.PCell.DL.Active.Avg
1526749452 L.Traffic.User.PCell.DL.6CC.Avg
1526749489 L.Traffic.User.CA.6CC.PCell.DL.Active.Avg
1526749453 L.Traffic.User.PCell.DL.7CC.Avg
1526749490 L.Traffic.User.CA.7CC.PCell.DL.Active.Avg
1526749454 L.Traffic.User.PCell.DL.8CC.Avg
1526749491 L.Traffic.User.CA.8CC.PCell.DL.Active.Avg
(L.Thrp.bits.DL.FddTddCAUser – L.Thrp.bits.DL.3CC.FddTddCAUser)/
(L.Thrp.Time.DL.FddTddCAUser – L.Thrp.Time.DL.3CC.FddTddCAUser)
1526737782 L.Traffic.User.FddTddCA.PCell.DL.Avg
1526737783 L.Traffic.User.FddTddCA.PCell.DL.Max
1526737795 L.Traffic.User.FddTddCA.PCell.DL.Active.A
vg
1526737796 L.Traffic.User.FddTddCA.PCell.DL.Active.M
ax
1526737807 L.Thrp.Time.DL.FddTddCAUser
1526737808 L.Thrp.bits.DL.FddTddCAUser
1526737768 L.E-RAB.AbnormRel.FddTddCAUser
1526737774 L.E-RAB.NormRel.FddTddCAUser
1526737776 L.Traffic.User.FddTddCA.3CC.PCell.DL.Avg
1526737777 L.Traffic.User.FddTddCA.3CC.PCell.DL.Max
1526737797 L.Traffic.User.FddTddCA.
3CC.PCell.DL.Active.Avg
1526737798 L.Traffic.User.FddTddCA.
3CC.PCell.DL.Active.Max
1526737810 L.Thrp.Time.DL.3CC.FddTddCAUser
1526737811 L.Thrp.bits.DL.3CC.FddTddCAUser
1526737764 L.E-RAB.AbnormRel.FddTddCAUser.3CC
1526737770 L.E-RAB.NormRel.FddTddCAUser.3CC
1526737778 L.Traffic.User.FddTddCA.4CC.PCell.DL.Avg
1526737779 L.Traffic.User.FddTddCA.4CC.PCell.DL.Max
1526737799 L.Traffic.User.FddTddCA.
4CC.PCell.DL.Active.Avg
1526737800 L.Traffic.User.FddTddCA.
4CC.PCell.DL.Active.Max
1526737814 L.Thrp.Time.DL.4CC.FddTddCAUser
1526737815 L.Thrp.bits.DL.4CC.FddTddCAUser
1526737765 L.E-RAB.AbnormRel.FddTddCAUser.4CC
1526737771 L.E-RAB.NormRel.FddTddCAUser.4CC
1526741758 L.Traffic.User.FddTddCA.5CC.PCell.DL.Avg
1526741735 L.Traffic.User.FddTddCA.
5CC.PCell.DL.Active.Avg
1526741754 L.Thrp.Time.DL.5CC.FddTddCAUser
1526741755 L.Thrp.bits.DL.5CC.FddTddCAUser
1526741756 L.E-RAB.AbnormRel.FddTddCAUser.5CC
1526741757 L.E-RAB.NormRel.FddTddCAUser.5CC
1526749452 L.Traffic.User.PCell.DL.6CC.Avg
1526749489 L.Traffic.User.CA.6CC.PCell.DL.Active.Avg
1526749453 L.Traffic.User.PCell.DL.7CC.Avg
1526749490 L.Traffic.User.CA.7CC.PCell.DL.Active.Avg
1526749454 L.Traffic.User.PCell.DL.8CC.Avg
1526749491 L.Traffic.User.CA.8CC.PCell.DL.Active.Avg
1526749443 L.Thrp.Time.DL.6CC.CAUser
1526749440 L.Thrp.bits.DL.6CC.CAUser
1526749444 L.Thrp.Time.DL.7CC.CAUser
1526749441 L.Thrp.bits.DL.7CC.CAUser
1526749445 L.Thrp.Time.DL.8CC.CAUser
1526749442 L.Thrp.bits.DL.8CC.CAUser
1526739768 L.Traffic.User.FddTddCA.PCell.DL.Avg.PLMN
1526739746 L.Thrp.Time.DL.FddTddCAUser.PLMN
1526739745 L.Thrp.bits.DL.FddTddCAUser.PLMN
1526739770 L.E-RAB.AbnormRel.FddTddCAUser.PLMN
1526739772 L.E-RAB.NormRel.FddTddCAUser.PLMN
13.1 Principles
This function aggregates two intra- or inter-band carriers, as shown in Figure
13-1, to provide higher bandwidth (up to 40 MHz) for the uplink.
13.2.1 Benefits
This function enables CA UEs to reach higher uplink peak data rates.
Table 13-1 lists the theoretical peak data rates that a CA UE can reach using FDD
uplink 2CC aggregation. These values assume a TBS suitable for the 20 MHz cell
bandwidth (equivalent to 100 RBs in the frequency domain).
Table 13-1 Theoretical peak data rates for FDD uplink 2CC aggregation (unit:
Mbit/s)
The peak data rate that CA can achieve for a CA UE is subject to:
● Peak data rate capability of the board where the PCell for the CA UE is
located
For example, if the PCell of a CA UE is served by an LBBPd1 board that
supports an uplink peak data rate of 225 Mbit/s, the peak data rate that CA
can achieve for the CA UE will not exceed 225 Mbit/s in the uplink.
● Capability of the CA UE
If the UE capability is limited, the actual peak data rates will be lower than
the theoretical values. The UE capability is indicated by ue-categoryUL. For
details about this IE, see section 4.1A "ue-CategoryDL and ue-CategoryUL" in
3GPP TS 36.306 V15.2.0.
13.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function has the following impacts on the network:
● Uplink interference may increase because CA UEs consume additional uplink
resources.
● If multiple timing advances (MTA) is enabled, the counters related to random
access to SCells return larger values, because of non-contention-based
random access to the SCells. In addition, if uplink power of CA UEs is limited,
MTA measurements result in certain throughput loss.
● Uplink throughput rises when the UlCaPuschPcOptSwitch option of the
CellAlgoSwitch.UlPcAlgoSwitch parameter is selected, as long as uplink
resources are sufficient. When this option is selected, the transmit power on
each PRB decreases so that more PRBs can be allocated to UEs. This function
extends the number of UEs in the uplink CA state. However, because more
resources are now used by CA UEs, uplink interference may rise, resulting in a
higher uplink IBLER and a larger number of discontinuous transmissions
(DTXs). Consequently, the RRC Setup Success Rate and E-RAB Setup Success
Rate may decrease and the Service Drop Rate may increase.
Function Impacts
● Functions related to RAN performance
RAT Function Function Reference Description
Name Switch
repeatedly
reestablished for the
UE. When an FDD
massive MIMO cell
acts as an uplink
SCell for uplink 2CC
aggregation, a UE
may not be
configured with SRS
resources in the SCell
because of
compatibility issues.
As a result, the
measurement results
of this cell are
inaccurate. To
mitigate this issue, it
is recommended that
SRS measurement
boundary protection
in TM9 be enabled in
the massive MIMO
cell, with the
SectorSplitGroup.T
m9SrsMeasThreshol
d parameter set to
-3 dB.
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Flash oud.Spectru NR Spectrum the number of uplink
Dynamic mCloudSwit Sharing RBs available for LTE.
Spectrum ch Therefore, the
Sharing parameter throughput of UEs in
with the the uplink FDD CA
value of state decreases.
LTE_NR_SPE
CTRUM_SHR
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Uplink oud.Spectru NR Uplink the number of uplink
Spectrum mCloudSwit Spectrum RBs available for LTE.
Sharing ch Sharing Therefore, the
parameter throughput of UEs in
with the the uplink FDD CA
value of state decreases.
LTE_NR_UPL
INK_SPECTR
UM_SHR
13.3 Requirements
13.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Name Function Switch Reference
13.3.3 Hardware
Base Station Models
For FDD, the following base stations are compatible with this function:
● 3900 and 5900 series base stations
● DBS3900 LampSite and DBS5900 LampSite
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition:
● Do not use LBBPc boards, which do not support this function.
● For downlink massive CA plus uplink 2CC aggregation, only cells on UBBPd or
UBBPe boards can act as the uplink SCell.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
13.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition, if
an SFN cell whose layer 1 and layer 2 are deployed in different BBUs participates
in uplink CA, the versions of the eNodeBs where these BBUs are configured must
be eRAN11.1 or later so that MTA can be enabled.
13.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
● EPC
For this function to reach a theoretical peak data rate, the maximum bit rate
that each UE subscribes to in the EPC cannot be lower than this theoretical
value.
– For the theoretical peak data rates for downlink, see the relevant
"Benefits" sections.
– For the theoretical peak data rates for uplink, see 13.2.1 Benefits.
Moreover, take the following necessary actions for this function to take effect:
● Prepare data as described in 15.4.1.1 Data Preparation if uplink 2CC
aggregation is to be deployed in a relaxed backhaul scenario.
● Prepare data as described in 16.4.1.1 Data Preparation if uplink 2CC
aggregation is to be deployed in an eNodeB coordination scenario.
Counter Observation
If the counters listed in Table 13-5 produce non-zero values on a network that is
serving CA UEs capable of uplink 2CC aggregation, uplink 2CC aggregation has
taken effect in the network.
1526732905 L.Traffic.User.PCell.UL.Avg
1526732894 L.Traffic.User.SCell.UL.Avg
1526733015 L.ChMeas.PRB.UL.PCell.Used.Avg
1526733016 L.ChMeas.PRB.UL.SCell.Used.Avg
1526733013 L.Thrp.bits.UL.CAUser
1526742185 L.Thrp.Time.UL.CAUser
Message Tracing
After a CA UE accesses a cell, the eNodeB configures a cell that meets CA
conditions as an SCell for the UE. When traffic conditions are met, the eNodeB
activates this SCell.
You can use the MAE-Access to verify SCell configuration and activation:
● Observe the RRC_CONN_RECFG message traced on the Uu interface. If the
RadioResourceConfigCommonSCell-r10 IE in the RRC_CONN_RECFG message
contains the UL-Configuration-r10 IE, the SCell has been configured.
● Observe the number of RBs and total TBS for the CA UE in the PCell and
SCell. If the numbers are not zero, the SCell has been activated.
1526732905 L.Traffic.User.PCell.UL.Avg
1526732906 L.Traffic.User.PCell.UL.Max
1526732894 L.Traffic.User.SCell.UL.Avg
1526732895 L.Traffic.User.SCell.UL.Max
1526733015 L.ChMeas.PRB.UL.PCell.Used.Avg
1526733016 L.ChMeas.PRB.UL.SCell.Used.Avg
1526733017 L.CA.Traffic.bits.UL.PCell
1526733018 L.CA.Traffic.bits.UL.SCell
1526733019 L.Traffic.User.SCell.Active.UL.Avg
1526733020 L.Traffic.User.SCell.Active.UL.Max
1526733021 L.CA.UL.PCell.Act.Dur
1526742185 L.Thrp.Time.UL.CAUser
1526733013 L.Thrp.bits.UL.CAUser
14 Uplink FDD+TDD CA
14.1 Principles
This function aggregates two uplink FDD and TDD CCs, as shown in Figure 14-1.
The PCC anchoring and SCell configuration procedures for uplink FDD+TDD CA are
as follows:
Either FDD or TDD carriers can act as SCCs. The SCell configuration procedure
is the same as that for downlink FDD+TDD CA. For details, see 12.1
Principles.
Usage Scenarios
For details, see Usage Scenarios in 12.1 Principles.
Subframe Configuration
The TDD cells involved in this function must use uplink-downlink configuration 2.
If a non-zero frame offset is configured for a TDD cell, the same frame offset must
be specified for the FDD cells involved in CA. FDD hardware of SRAN10.1 or later
versions all support frame offset setting.
14.2.1 Benefits
This function deals with spectrum shortages by utilizing both FDD and TDD
spectrum resources, addresses mobile broadband service competition, and
improves service quality.
Theoretical peak data rate for uplink FDD+TDD 2CC aggregation = Theoretical
peak data rate on a single FDD carrier in the uplink + Theoretical peak data rate
on a single TDD carrier in the uplink
14.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function has the following impacts on the network:
● When a TDD cell acts as an SCell for a CA UE, the SCell offers beamforming
gains in the downlink and experiences an increase in downlink cell
throughput.
● When MTA is configured in FDD+TDD CA scenarios, this function increases the
uplink throughput of CA UEs and improves uplink performance if there is a
noticeable difference (for example, about 78 meters, which is equivalent to
one TA) between the distances of a CA UE to the receive antennas of the
PCell and an SCell. In addition, due to the non-contention-based random
access to the SCell, the performance counters related to random access to the
SCell produce larger values.
● When CA is deployed between eNodeBs in relaxed backhaul scenarios, ACKs/
NACKs for the PCell and SCell may not be received promptly because of inter-
eNodeB transmission delay. This results in a decrease of no more than 5% in
Function Impacts
● Functions related to RAN performance
RAT Function Function Reference Description
Name Switch
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Flash oud.Spectru NR Spectrum the number of uplink
Dynamic mCloudSwit Sharing RBs available for LTE.
Spectrum ch Therefore, the
Sharing parameter throughput of UEs in
with the the uplink FDD CA
value of state decreases.
LTE_NR_SPE
CTRUM_SHR
FDD LTE FDD and SpectrumCl LTE FDD and This function reduces
NR Uplink oud.Spectru NR Uplink the number of uplink
Spectrum mCloudSwit Spectrum RBs available for LTE.
Sharing ch Sharing Therefore, the
parameter throughput of UEs in
with the the uplink CA state
value of decreases.
LTE_NR_UPL
INK_SPECTR
UM_SHR
14.3 Requirements
14.3.1 Licenses
Each FDD cell involved in uplink FDD+TDD CA requires one sales unit for each of
the following features:
● MRFD-101222 FDD+TDD Downlink Carrier Aggregation(LTE FDD)
● MRFD-111222 FDD+TDD Uplink Carrier Aggregation (LTE FDD)
Each TDD cell involved in uplink FDD+TDD CA requires one sales unit for each of
the following features:
● MRFD-101231 FDD+TDD Downlink Carrier Aggregation(LTE TDD)
● MRFD-111232 FDD+TDD Uplink Carrier Aggregation (LTE TDD)
Table 14-1 lists the license models and sales units for these features.
14.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Name Function Switch Reference
14.3.3 Hardware
Boards
The requirements described in Boards of 12.3.3 Hardware must be fulfilled. In
addition, for downlink massive CA plus uplink 2CC aggregation, only cells on
UBBPd or UBBPe boards can act as the uplink SCell.
RF Modules
For details, see RF Modules in 12.3.3 Hardware.
Cells
For details, see Subframe Configuration in 14.1 Principles.
14.3.4 Networking
For details, see 12.3.4 Networking.
14.3.5 Others
● UEs
– UEs must comply with 3GPP Release 12 or later and support the
frequency bands of the carriers to be aggregated and their channel
bandwidths. UEs must also support the peak data rates that CA can
achieve.
– UEs must support MTA.
● EPC
For this function to reach a theoretical peak data rate, the maximum bit rate
that each UE subscribes to in the EPC cannot be lower than this theoretical
value. For the theoretical values, see 14.2.1 Benefits.
Moreover,
Counter Observation
If the counters listed in Table 14-4 produce non-zero values, uplink FDD+TDD CA
has taken effect.
1526741844 L.Traffic.User.FddTddCA.PCell.UL.Avg
1526742034 L.Traffic.User.FddTddCA.SCell.UL.Avg
1526741932 L.Traffic.User.FddTddCA.SCell.Active.UL.Avg
1526743685 L.Traffic.User.PCell.UL.RelaxedBackhaul-
CA.Avg
1526743658 L.Traffic.User.SCell.UL.RelaxedBackhaul-
CA.Avg
1526743661 L.Traffic.User.RelaxedBackhaul-
CA.SCell.Active.UL.Avg
Message Tracing
For details, see Message Tracing in 13.4.2 Activation Verification.
1526741844 L.Traffic.User.FddTddCA.PCell.UL.Avg
1526742034 L.Traffic.User.FddTddCA.SCell.UL.Avg
1526741932 L.Traffic.User.FddTddCA.SCell.Active.UL.Avg
1526741933 L.CA.UL.FddTddCA.PCell.Act.Dur
1526741931 L.CA.UL.FddTddCA.SCell.Act.Dur
1526741919 L.Thrp.bits.UL.FddTddCA.CAUser
1526743685 L.Traffic.User.PCell.UL.RelaxedBackhaul-
CA.Avg
1526743658 L.Traffic.User.SCell.UL.RelaxedBackhaul-
CA.Avg
1526743661 L.Traffic.User.RelaxedBackhaul-
CA.SCell.Active.UL.Avg
15.1 Principles
This function allows for downlink 2CC to 8CC aggregation and uplink 2CC
aggregation between inter-eNodeB cells in relaxed backhaul scenarios (that is,
non-ideal backhaul scenarios), as illustrated in Figure 15-1.
The switch control over this function varies, as described in Table 15-1.
Usage Scenarios
The relaxed backhaul scenarios are classified into the following types:
● Inter-eNodeB one-way delay ≤ 4 ms and RTT ≤ 8 ms
In this scenario, both downlink CA and uplink CA work between inter-eNodeB
cells.
● 4 ms < inter-eNodeB one-way delay ≤ 8 ms and 8 ms < RTT ≤ 16 ms
In this scenario, only downlink CA works.
To enable inter-eNodeB CA in this scenario, the RelaxedBHCaEnhanceSwitch
option of the ENodeBAlgoSwitch.CaAlgoSwitch parameter must be selected.
● 8 ms < inter-eNodeB one-way delay ≤ 16 ms and 16 ms < RTT ≤ 32 ms
In this scenario, only downlink FDD CA works.
To enable inter-eNodeB CA in this scenario, the RelaxedBHCaEnh2Switch
option of the ENodeBAlgoSwitch.CaAlgoExtSwitch parameter must be
selected.
The eNodeB combination can be one of the following:
For details about eX2 or X2 interfaces between eNodeBs, see eX2 Self-
Management or S1 and X2 Self-Management.
Procedures
This function employs the same PCC anchoring and SCell management procedures
as for intra-eNodeB CA. For details, see 4.6 Carrier Management for
RRC_CONNECTED UEs and 4.7 Carrier Management for RRC_IDLE UEs.
This function implements SCell configuration and SCell removal with inter-eNodeB
transmission quality requirements considered, in addition to the principles
described in 4.6.3 SCell Management.
15.2.1 Benefits
This function enables inter-eNodeB carriers to be aggregated to increase user-
perceived data rates for CA UEs.
15.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
corresponding "Impacts" sections.
Network Impacts
In relaxed backhaul scenarios, when CA and other inter-eNodeB features (such as
UL CoMP) are enabled together, these features share transmission bandwidth. If
transmission bandwidth is insufficient, delays increase and the benefits of these
features are affected.
This function has the following impacts on the network:
● CA UEs cannot promptly acquire the real-time CQI changes about inter-
eNodeB SCells. This causes slight deterioration in frequency-selective
scheduling performance and an increase in IBLER.
● Due to inter-eNodeB delay, HARQ feedback is postponed, which affects the
RBLER of CA UEs. In HARQ retransmission statistics, the values of the RBLER-
related counters may rise. CQI reports for SCells of CA UEs are also delayed,
which affects the IBLER of these UEs. The IBLER-related counters may produce
larger values. If a UE in the inter-eNodeB CA state is located a medium or
long distance from the center of its PCell or SCell, the data rate of the UE
fluctuates.
● Due to the differences in the RLC data arrival time for the aggregated carriers,
CA UEs have to combine and organize the received data. This process places
an additional burden on the UEs' CPUs. If the CPU capacity is insufficient, the
data rates of the UEs fluctuate.
● To minimize the impact of inter-eNodeB delay, RLC retransmissions occur only
in PCells. If the Uu bandwidth of a PCell is used up by GBR services, RLC
retransmissions for the CA UE are often blocked and the data rate of the UE
fluctuates.
● Due to possible errors in the estimated scheduling priorities of CA UEs, the
PRBs in SCells for the UEs may not be fully utilized when the SCells are each
serving a small number of non-CA UEs and the non-CA UE traffic is light.
● Routes are added between eNodeBs. As a result, SCell bandwidth and lower-
layer link bandwidth specifications may be exceeded, causing
L.CA.SccAddFail.PhyLinkFail.Dur to increase.
● In relaxed-backhaul-based inter-eNodeB CA scenarios, if MBSFN subframes
and MTA are configured, the PCell MBSFN subframe numbers described in the
following table are recommended for different SCell PRACH subframe number
settings. If the MBSFN subframes are not set as recommended, uplink
synchronization may fail in SCells. This failure causes SCells to be deactivated
and therefore affects the perceived data rates of CA UEs. If multiple SCell
PRACH subframes are set within 10 ms, the intersection of the corresponding
MBSFN subframe number settings is recommended.
Table 15-2 Recommended PCell MBSFN subframe numbers for different FDD
SCell PRACH subframe number settings
0 3, 6, 7, 8
1 1, 2, 6, 7, 8
2 1, 2, 6, 7, 8
3 1, 2, 3, 6, 7, 8
4 1, 2, 3, 6, 7, 8
5 1, 2, 3, 8
6 1, 2, 3, 6, 7
7 1, 2, 3, 6, 7
8 1, 2, 3, 6, 7, 8
9 1, 2, 3, 6, 7, 8
At the 80%
beginning
– When the SCTP congestion level of the eX2 interface has changed from
high to low, the target SCell configuration success rate is 95%.
– When the SCTP congestion status of the eX2 interface has changed from
no congestion to low-level congestion, the inter-eNodeB SCell
configuration procedure is not affected.
– The eX2 interface flow control status is updated every minute. Flow
control will be canceled for the eX2 interface if inter-eNodeB SCell
configuration is not performed or the target inter-eNodeB SCell
configuration success rate is 95%. After the canceling, the inter-eNodeB
SCell configuration procedure is not affected.
Function Impacts
RAT Function Function Referen Description
Name Switch ce
As a result, an incorrect
handover occurs
because the calculated
air interface capability
of the serving cell
combination is less than
the actual capability.
You are not advised to
enable both of the two
functions.
15.3 Requirements
NOTE
Table 15-4 lists the license models and sales units for these features.
15.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
15.3.3 Hardware
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition, note that:
● BBU3910A does not support this function.
● When deployed on LBBPc boards, FDD cells:
– Cannot act as SCells for uplink inter-eNodeB CA.
– Can act as neither PCells nor SCells when the inter-eNodeB one-way
delay is between 8 ms and 16 ms (inclusive) and the RTT is between 16
ms and 32 ms (inclusive).
● If the LMPT is used as the main control board, no more than seven inter-
eNodeB BBPs can be interconnected because the transport resource group
bandwidth of the LMPT is limited.
● For 5CC aggregation to 100 MHz, the UBBP and UMPT boards are
recommended. If LBBPd and LMPT are used, the peak data rate may not
reach the expected value, due to the lower hardware capabilities.
● If the data rate of transmission from the EPC to the eNodeB exceeds the
transmission capability of the BBP or main control board, the PCell cannot
transfer data to SCells. As a result, the SCells may be activated but their
scheduling is suspended.
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
15.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition, CA
in relaxed backhaul scenarios has the following requirements:
● It is recommended that this function be deployed in urban areas to prevent
CA failures caused by large inter-site distances.
In accordance with section J.1 "Deployment Scenarios" in 3GPP TS 36.300
V10.11.0, the delay spread among the inter-eNodeB CCs monitored at the UE
cannot exceed 30.26 μs. A delay spread of 30.26 μs corresponds to a signal
transmission distance difference of about 9 kilometers among the CCs.
● The eNodeBs must use the same software version.
● The eNodeBs must be time-synchronized to within 3 μs.
The DSP CLKTST command can be used to query clock quality test
monitoring results.
● Routes between inter-eNodeB cells must be established and working properly.
eX2 or X2 interfaces must be set up between the eNodeBs. For details, see
eX2 Self-Management or S1 and X2 Self-Management.
– If the eNodeBs belong to the same operator and are managed by the
same MAE-Access:
eX2 or X2 interfaces between the eNodeBs support self-setup.
– If the eNodeBs belong to different operators or are managed by different
MAE-Access systems:
SCTP links and endpoint groups for eX2 or X2 interfaces must be
manually configured.
Both the control plane and user plane must be configured for X2 interfaces.
Otherwise, the routes between inter-eNodeB cells are unreachable, causing
CA failures. The DSP X2UPINFO command (in endpoint mode) or DSP
IPPATH command (in link mode) can be executed to check whether user-
plane information has been configured for an X2 interface.
eNodeBs will automatically create IP PM sessions to detect link status of eX2
or X2 interfaces. If an IP PM session of bidirectional activation type is
configured at either end of an eX2 or X2 interface, it may conflict with an
automatically created session. Therefore, the eX2 or X2 interface fails to work
properly.
If three consecutive attempts of a cell to set up an eX2 or X2 route to an
inter-eNodeB cell fail in a relaxed backhaul scenario, the subsequent setup
attempts on this route will be prohibited within the next 5 minutes.
The maximum number of inter-eNodeB cells that can be associated varies
depending on the type of main control board, as listed in Table 15-5.
Table 15-5 Maximum number of inter-eNodeB cells for each type of main
control board
LMPT UMPTa/UMPTb UMPTe UMPTg
Best 0 0.0001
Recommended 1 0.001
Tolerable 2 0.5
● The bandwidths of the links between the eNodeBs must meet requirements.
The required link bandwidth can be planned based on network conditions. It
must be within the transmission bandwidth capacities of the eNodeBs.
– Link bandwidth
Required link bandwidth = Bandwidth of the SCC x Spectral efficiency of
the SCC x Percentage of CA UEs on the SCC x Number of SCells to be
associated
Take a 20 MHz SCC as an example. Each time the serving eNodeB of the
PCell associates an inter-eNodeB SCell with the PCell:
▪ A link bandwidth of 35 Mbit/s is required for the uplink and also for
the downlink, assuming the average SCC spectral efficiency of 3.5
and a CA UE percentage of 50% for the SCC. The required link
bandwidth is calculated as follows:
20 x 3.5 x 50% x 1 = 35 Mbit/s
In consideration of transport protocol overheads, a bandwidth
margin of about 12% must be reserved. As a result, the bandwidth to
be configured is calculated as follows: 35 x (1 + 12%) = 39 Mbit/s.
▪ A link bandwidth of 150 Mbit/s is required for the uplink and also for
the downlink, assuming the maximum SCC spectral efficiency of 7.5
and a CA UE percentage of 100% for the SCC.
With the bandwidth margin of 12% considered, the bandwidth to be
configured is calculated as follows: 150 x (1 + 12%) = 168 Mbit/s.
Spectral efficiency = (L.Traffic.DL.SCH.QPSK.TB.bits + L.Traffic.DL.SCH.
16QAM.TB.bits + L.Traffic.DL.SCH.64QAM.TB.bits + L.Traffic.DL.SCH.
256QAM.TB.bits)/(L.ChMeas.PRB.DL.Used.Avg x measurement period),
where the measurement period is expressed in seconds.
– Transmission bandwidth capacities of eNodeBs
The CA-related transmission bandwidth capacities of eNodeBs depend on
the base station type and main control board type.
For macro and LampSite eNodeBs, the capacities depend on the main
control board type and the setting of the
GlobalProcSwitch.ProcTypeForNonIdealServData parameter, as
described in Table 15-7.
▪ SCells are removed, so the instantaneous data rates of the UEs will
decrease even temporarily to zero.
In SCells participating in inter-eNodeB CA, the data rates on the radio interface are
determined by the transport block sizes selected by eNodeBs for UEs. The sizes must
not exceed the maximum allowed transmission bandwidth, and the size type is subject
to protocol-stipulated restrictions. It is possible that a selected transport block size
does not precisely match the transmission bandwidth. As a result, the actual data
throughput may fail to reach the maximum allowed bandwidth even though spare
radio resources are available in the SCells.
In inter-eNodeB CA based on relaxed backhaul, the PCell for a UE can allocate a
maximum of 50 KB of data to each SCell in each TTI. As a result, the air interface data
rate of the UE in the SCells cannot reach the peak value in some scenarios. For
example, if uplink-downlink subframe configuration 2 is used in TDD, the peak data
rate over the air interface in the affected SCells is 320 Mbit/s, which is lower than the
peak data rate that can be reached using TM9 in 8x8 MIMO.
15.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
6CC–8CC aggregation requires UEs to comply with 3GPP Release 13 or later.
● EPC
For this function to reach a theoretical peak data rate, the maximum bit rate
that each UE subscribes to in the EPC cannot be lower than this theoretical
value. For the theoretical values, see 15.2.1 Benefits.
Counter Observation
If the counters listed in Table 15-10 produce non-zero values on a network that is
serving CA UEs, inter-eNodeB CA based on relaxed backhaul has taken effect in
the network.
1526732909 L.Traffic.User.PCell.DL.RelaxedBackhaul-
CA.Avg
1526732955 L.Traffic.User.SCell.DL.RelaxedBackhaul-
CA.Avg
1526732911 L.ChMeas.PRB.DL.PCell.RelaxedBackhaul-
CAUsed.Avg
1526732912 L.ChMeas.PRB.DL.SCell.RelaxedBackhaul-
CAUsed.Avg
1526743685 L.Traffic.User.PCell.UL.RelaxedBackhaul-
CA.Avg
1526743658 L.Traffic.User.SCell.UL.RelaxedBackhaul-
CA.Avg
1526743661 L.Traffic.User.RelaxedBackhaul-
CA.SCell.Active.UL.Avg
Message Tracing
For the tools and IEs to observe, see Message Tracing in 5.4.2 Activation
Verification and Message Tracing in 13.4.2 Activation Verification.
In addition, monitor the counters in Table 15-11 and compare the results with the
network plan to evaluate network performance.
1526732909 L.Traffic.User.PCell.DL.RelaxedBackhaul-
CA.Avg
1526732910 L.Traffic.User.PCell.DL.RelaxedBackhaul-
CA.Max
1526732955 L.Traffic.User.SCell.DL.RelaxedBackhaul-
CA.Avg
1526732954 L.Traffic.User.SCell.DL.RelaxedBackhaul-
CA.Max
1526732911 L.ChMeas.PRB.DL.PCell.RelaxedBackhaul-
CAUsed.Avg
1526732912 L.ChMeas.PRB.DL.SCell.RelaxedBackhaul-
CAUsed.Avg
1526733184 L.Thrp.bits.DL.RelaxedBackhaulCAUser
1526733185 L.Thrp.Time.DL.RelaxedBackhaulCAUser
1526733198 L.Traffic.User.PCell.RelaxedBackhaulCA.OFF
1526737803 L.CA.Traffic.bits.RelaxedBackhaul-
CAUsed.DL.Pcell
1526737804 L.CA.Traffic.bits.RelaxedBackhaul-
CAUsed.DL.Scell
1526743685 L.Traffic.User.PCell.UL.RelaxedBackhaul-
CA.Avg
1526743658 L.Traffic.User.SCell.UL.RelaxedBackhaul-
CA.Avg
1526743661 L.Traffic.User.RelaxedBackhaul-
CA.SCell.Active.UL.Avg
1526759044 L.CA.SCell.DLSCell.RelaxedBackhaul-
CA.Mod.Att
1526759045 L.CA.SCell.DLSCell.RelaxedBackhaul-
CA.Rmv.Att
1526759046 L.CA.SCell.DLSCell.RelaxedBackhaul-
CA.Add.Att
16.1 Principles
This function allows for downlink 2CC to 8CC aggregation and uplink 2CC
aggregation between inter-eNodeB cells in eNodeB coordination scenarios.
For FDD, in eNodeB coordination scenarios, the eNodeBs are deployed in a
centralized or distributed manner.
Figure 16-1 illustrates an example of the scenarios.
This function employs the same PCC anchoring and SCell management procedures
as for intra-eNodeB CA. For details, see 4.6 Carrier Management for
RRC_CONNECTED UEs and 4.7 Carrier Management for RRC_IDLE UEs.
Centralized Deployment
In the centralized architecture of eNodeB coordination, the eNodeBs exchange
signaling messages and transmit service data through one or two levels of
universal switching units (USUs). For details about this architecture, see USU3900-
based Multi-BBU Interconnection and USU3910-based Multi-BBU Interconnection.
CA works in this centralized architecture only when the inter-eNodeB round trip
time (RTT) is less than 44 μs.
CA works in this distributed architecture only when the inter-eNodeB RTT is less
than 260 μs.
16.2.1 Benefits
This function enables inter-eNodeB carriers to be aggregated to increase user-
perceived data rates for CA UEs.
16.2.2 Impacts
This section describes the network and function impacts of this function itself.
For the network and function impacts of the prerequisite functions, see the
"Impacts" sections for the prerequisite functions.
Network Impacts
This function has the following impacts on the network, because of the delay:
● In the centralized architecture
This function has a slight negative impact on the peak data rates of CA UEs
but does not affect user experience. The reason is that the data to be sent
does not arrive at SCells precisely at the moment of the SCells' scheduling
occasion and the UEs cannot be scheduled for that moment.
● In the distributed or hybrid architecture (FDD only)
– CA UEs cannot promptly acquire the real-time CQI changes about inter-
eNodeB SCells. This causes slight deterioration in frequency-selective
scheduling performance and an increase in IBLER.
– Reports of HARQ retransmission demodulation results are delayed,
affecting the single-UE peak data rate and resulting in an increase in
RBLER.
– CQI and IBLER feedback is delayed, causing variations in the data rates of
UEs located medium or long distances from the center of their SCells.
– Due to the differences in the RLC data arrival time for the aggregated
carriers, CA UEs have to combine and organize the received data. This
process places an additional burden on the UEs' CPUs. If the CPU capacity
is insufficient, the data rates of the UEs fluctuate.
– To minimize the impact of inter-eNodeB delay, RLC retransmissions occur
only in PCells. If the Uu bandwidth of a PCell is used up by guaranteed
bit rate (GBR) services, RLC retransmissions for the CA UE are often
blocked and the data rate of the UE fluctuates.
– Due to possible errors in the estimated scheduling priorities of CA UEs,
the PRBs in SCells for the UEs may not be fully utilized when the SCells
are each serving a small number of non-CA UEs and the non-CA UE
traffic is light.
– When route setup is triggered for the first time between the PCell and an
inter-eNodeB SCell for a CA UE, this route is set up assuming the eNodeB
is in the centralized eNodeB coordination architecture by default, before
the inter-eNodeB transmission delay is detected. If the detected inter-
eNodeB transmission delay indicates the distributed eNodeB coordination
architecture, the eNodeB removes this SCell for the UE. The eNodeB will
attempt to configure this SCell for the UE again when the uplink or
downlink traffic volume of the UE meets the SCell activation conditions
described in 4.6.3.4 SCell Activation. For subsequent CA UEs, the
eNodeB configures this SCell considering that it is in the distributed
eNodeB coordination architecture.
Function Impacts
RAT Function Function Reference Description
Name Switch
16.3 Requirements
16.3.2 Software
Before activating this function, ensure that its prerequisite functions have been
activated and mutually exclusive functions have been deactivated. For detailed
operations, see the relevant feature documents.
Prerequisite Functions
RAT Function Function Reference Description
Name Switch
16.3.3 Hardware
Boards
The requirements described in Boards of 5.3.3 Hardware must be fulfilled. In
addition:
● Do not use LMPT, which does not support this function.
● For FDD, do not use LBBPc, BBU3910A, or BBU3910C, which does not support
this function.
● Do not use BBU5900A or BookBBU5901, which does not support this function.
● Before deploying this function, contact Huawei engineers for a resource audit.
This function shares system resources with SFN, UL CoMP, and coordinated
scheduling based power control (CSPC).
RF Modules
For details, see RF Modules in 5.3.3 Hardware.
16.3.4 Networking
The requirements described in 5.3.4 Networking must be fulfilled. In addition, CA
in eNodeB coordination scenarios has the following requirements:
● The eNodeBs must use the same software version.
● The eNodeBs must be time-synchronized.
● Routes between inter-eNodeB cells must be established and working properly.
– When USU3910 is used, eX2 interfaces must be set up between the
eNodeBs.
▪ If the eNodeBs belong to the same operator and are managed by the
same MAE-Access, eX2 self-setup works.
16.3.5 Others
● UEs
UEs must comply with 3GPP Release 12 or later and support the frequency
bands of the carriers to be aggregated and their bandwidths. UEs must also
support the peak data rates that CA can achieve.
6CC–8CC aggregation requires UEs to comply with 3GPP Release 13 or later.
● EPC
For this function to reach a theoretical peak data rate, the maximum bit rate
that each UE subscribes to in the EPC cannot be lower than this theoretical
value. For the theoretical values, see 16.2.1 Benefits.
Counter Observation
If the counters listed in Table 16-5 produce non-zero values on a network that is
serving CA UEs, inter-eNodeB CA based on eNodeB coordination has taken effect
in the network.
1526739785 L.Traffic.User.PCell.USUCA.Avg
1526739786 L.Traffic.User.SCell.USUCA.Avg
Message Tracing
For the tools and IEs to observe, see Message Tracing in 5.4.2 Activation
Verification and Message Tracing in 13.4.2 Activation Verification.
▪ Condition for entering the high-load state: Number of UEs that can
be paired in the massive MIMO cell >
CaMgtCfg.HLUeCntThldForScellConfig
▪ Condition for exiting the high-load state: Number of UEs that can be
paired in the massive MIMO cell ≤ max{0,
CaMgtCfg.HLUeCntThldForScellConfig – 20}
– With the CaMgtCfg.HLUeCntThldForScellConfig parameter set to
65535
The eNodeB determines the load status of the cell based on the number
of UEs in the cell. Number of UEs in a cell = Number of CA UEs that treat
the cell as their PCell + Number of CA UEs that treat the cell as their
SCell + Number of non-CA UEs that treat the cell as their serving cell
▪ Condition for entering the high-load state: Number of UEs in the cell
> CaMgtCfg.HLUeCntThldForScellConfig
▪ Condition for exiting the high-load state: Number of UEs in the cell ≤
max{0, CaMgtCfg.HLUeCntThldForScellConfig – 20}
– With the CaMgtCfg.HLUeCntThldForScellConfig parameter set to
65535
The eNodeB does not determine the load status of the cell.
● CaMgtCfg.HighLoadCellTypeNotAsScell set to ALL_CELL
During downlink SCell configuration for a CA UE at initial access, an incoming
RRC connection reestablishment, or an incoming necessary handover:
– If the CA UE cannot participate in pairing in high-load massive MIMO
cells, these cells cannot be configured as SCells for the UE.
– If a candidate SCell is a high-load normal cell, the cell cannot be
configured as an SCell for the CA UE.
MIMO Schemes
In CA scenarios, each CC supports 2T or 4T MIMO (the number of antennas may
vary with carriers). The MIMO scheme is separately configured for each CC.
UEs
The way the terminal industry chain has developed, some UEs do not support
aggregation of the maximum number of CCs while using the highest-order MIMO
configurations. For example, some UEs support aggregation of three 2x2 MIMO
CCs or aggregation of one 4x4 MIMO CC and one 2x2 MIMO CC, but not
aggregation of three 4x4 MIMO CCs.
For these UEs, the CaMgtCfg.CaMimoPriorityStrategySw parameter can be used
to determine the policy for adaptive selection of CA or high-order MIMO when the
UEs have been configured with a maximum number of CCs.
● If this parameter is set to CA_PRIOR, CA takes precedence.
● If this parameter is set to MIMO_PRIOR, the eNodeB attempts to configure as
many 4x4 MIMO-capable CCs as possible.
For this purpose, the eNodeB removes SCells for a CA UE when two conditions
are fulfilled. The UE falls back to be served by fewer CCs and enables rank-4-
based transmission on the 4x4 MIMO-capable CCs. These conditions are:
– The UE determines that SCell removal will allow a larger number of CCs
to be capable of 4x4 MIMO.
– The eNodeB determines that, after the fallback, any one of the 4x4
MIMO-capable CCs will meet the conditions described in Table 17-1.
NOTE
● After an RRC connection is set up between a CA UE and a cell, the cell acts as
the PCell of the UE. The PCell transmits non-access stratum (NAS) messages
for the UE.
● An eNodeB configures SCells for a CA UE by sending messages over the RRC
connection. After the SCells are configured, the CA UE still has only one RRC
connection with the network and is allocated only one cell radio network
temporary identifier (C-RNTI).
● The PCell and SCells of a CA UE each have a complete set of channels with
one exception: the PUCCH. This channel carries layer 1 uplink control
information, such as ACKs or NACKs to downlink data, scheduling requests,
and periodic CSI reports. The PUCCH exists only in the PCell.
● The PCell is set up for a CA UE during initial access or an RRC connection
reestablishment. A handover is required to change the PCell for the UE. An
RRC connection reestablishment procedure is triggered if a radio link failure
(RLF) occurs in the PCell.
● SCells can be deactivated, but the PCell cannot. Only the serving eNodeB of
the PCell can deactivate and remove SCells.
Handover Messages
The handover procedures for CA UEs have the following characteristics:
The difference in the number of CCs between source and target eNodeBs has no
impact on the handover procedure.
The RRC Connection Reconfiguration message and the preceding IEs can be traced
as described in 5.4.2 Activation Verification.
Measurement Configuration
If an eNodeB performs CA for a CA UE whose signal quality is so poor that an
inter-frequency handover may occur, the spectral efficiency of the network
decreases and the block error rate (BLER) increases. To prevent this, set thresholds
as described in Table 17-3.
Handover Events
CA UEs report events for eNodeBs to evaluate the following handovers:
● Intra-frequency handover (Related parameters are configured in the
IntraFreqHoGroup MO.)
An eNodeB performs an intra-frequency handover for a CA UE when it
receives an A3 measurement report from the UE in the PCell.
● Inter-frequency handover (Related parameters are configured in the
InterFreqHoGroup MO.)
After receiving an A2 measurement report from a CA UE in the PCell, the
serving eNodeB of the PCell delivers the inter-frequency measurement
configuration to the UE. The measurement configuration varies depending on
whether SCells have been configured for the UE:
– If SCells have been configured, the eNodeB delivers an A3 or A5
measurement configuration: A3 in case the
EutranInterNFreq.InterFreqHoEventType parameter is set to EventA3
and A5 in case this parameter is set to any other value.
– If no SCells have been configured, the eNodeB delivers a measurement
configuration related to the event specified by the
EutranInterNFreq.InterFreqHoEventType parameter.
● For the triggering conditions for these events, see Mobility Management in
Connected Mode. Event A5 is triggered if the signal quality in the PCell is lower
than the threshold for handover event A2 and the signal quality in at least one
neighboring cell is higher than the threshold for handover event A4.
● It is recommended that threshold 1 for event A5 be the same as the threshold for
inter-frequency handover event A2. If threshold 1 is lower than or equal to the
threshold for blind handover event A2, the eNodeB will not deliver A5
measurement configurations to the UEs.
Frequency-Priority-based Handover
If the operator-specified frequency with the highest priority for frequency-priority-
based handovers is different from the frequency with the highest priority for PCC
anchoring, you are advised to select the FreqPriBasedHoCaFiltSwitch option of
the ENodeBAlgoSwitch.CaAlgoSwitch parameter. In such a case, the eNodeB
does not deliver the measurement configurations related to frequency-priority-
based handovers to CA UEs. If you do not select this option, frequency-priority-
based handovers may occur on CA UEs soon after the UEs are handed over to a
frequency with a high PCC anchoring priority.
Load-based Handover
If the PCell of a CA UE meets the triggering conditions for load balancing and the
UE meets the UE selection conditions, the eNodeB performs a load-based inter-
frequency handover on the UE. For details about this type of handover, see Intra-
RAT Mobility Load Balancing.
● If the HoWithSccCfgSwitch option is selected for both the source and target
eNodeBs, this function is enabled. The procedure is as follows:
a. The source eNodeB includes the reportAddNeighMeas IE in the handover-
related A3, A4, and A5 measurement configurations delivered to the CA
UE.
b. The CA UE sends the source eNodeB the measurement reports that
contain the measurement result of the best cell on each serving
frequency (in the measResultBestNeighCell IE) and the PCell and SCell
measurement results (in the measResultPCell and measResultSCell IEs).
c. The source eNodeB includes the best cell information in the
CandidateCellInfoList IE of the handover request message and sends the
message to the target eNodeB.
The source eNodeB also includes the blind-configurable candidate SCells
of the source cell in the CandidateCellInfoList IE of the handover request
message if the ENodeBAlgoSwitch.HoWithSccCfgAddBlindSwitch
parameter is set to ON.
d. The target eNodeB acquires measurement results from the
CandidateCellInfoList IE, determines the new SCell to be configured to
accompany the target cell (acting as the PCell) of the handover, and
updates the sCellToAddModList IE with the new SCell information. The
target eNodeB then sends the updated information in the handover
command to the source eNodeB.
The eNodeB preferentially selects blind-configurable candidate SCells as
new SCells. This takes effect in adaptive configuration mode and only if
the HoWithSccCfgBlindFirstSw option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter is selected. It takes
effect in CA-group-based configuration mode without switch control.
e. The source eNodeB sends an RRC Connection Reconfiguration message
containing the mobilityControlInfo, sCellToReleaseList, and
sCellToAddModList IEs to remove the original SCells and configure the
new SCells during the handover.
After the HoWithSccCfgSwitch option of the
ENodeBAlgoSwitch.CaAlgoSwitch parameter is selected, the SCell
configuration success rate changes as affected by the handover success rate.
(The SCell configuration success rate can be observed using the
L.CA.DLSCell.Add.Succ and L.CA.DLSCell.Add.Att counters.)
The CaTrafficTriggerSwitch option of the ENodeBAlgoSwitch.CaAlgoSwitch
parameter does not take effect in this procedure. The source and target
eNodeBs perform the procedure without considering traffic volume for
configuring SCells, even if the CaTrafficTriggerSwitch option has been
selected.
If this procedure fails, no SCell is configured for the UE that has been handed
over to the target cell. The target eNodeB then performs an SCell
configuration procedure. For details, see 4.6.3.1.2 CA-Group-based SCell
Configuration Procedure and 4.6.3.1.3 Adaptive SCell Configuration
Procedure.
NOTE
SCell configuration, SCell change, and PCC anchoring may or may not be affected by event
A2 reporting, depending on the setting of the RcvA2CfgSccSwitch option of the
CaMgtCfg.CellCaAlgoSwitch parameter:
● If this option is deselected, SCell configuration, SCell change, and PCC anchoring are
affected by event A2 reporting.
If the serving eNodeB of the PCell for a CA UE receives a handover-related event A2
report from the UE, the eNodeB stops configuring SCells, changing SCells, and
performing PCC anchoring for the UE. If the eNodeB receives a handover-related event
A1 report, the eNodeB can configure SCells in a blind manner (if blind SCell
configuration is enabled) or after receiving an event A4 report related to carrier
management from the UE, can change SCells, and can perform PCC anchoring for the
UE.
● If this option is selected, SCell configuration, SCell change, and PCC anchoring are not
affected by event A2 reporting. The serving eNodeB of the PCell for a CA UE can still
configure SCells, change SCells, and perform PCC anchoring for the UE after receiving a
handover-related event A2 report from the UE.
Admission Control
Admission control under CA differs from admission control without CA in the
following ways:
● Admission control based on the number of UEs
When an eNodeB receives an access request from a CA UE (for RRC
connection setup or reestablishment, an incoming handover, or a transition
from out-of-synchronization to in-synchronization), the eNodeB performs
admission control in both the PCell and SCells based on the number of UEs in
the individual cells. If the eNodeB accepts the access request, it treats the UE
as an RRC_CONNECTED UE in each serving cell. However, only the
RRC_CONNECTED UEs in the PCell consume UE count license units. Take 2CC
aggregation as an example. If all UEs on the entire network have their SCells
activated and are working in the 2CC aggregation state, the maximum
number of UEs that can access the network decreases by half, and the
number of consumed UE count license units is equal to the actual number of
UEs that have accessed the network.
The UE count threshold used to determine whether to admit a CA UE to an
SCell is equal to 90% of the CellRacThd.AcUserNumber parameter value
specified for this cell.
Congestion Control
Huawei eNodeBs relieve traffic congestion mainly by releasing GBR services. When
a cell is overloaded, GBR services in the cell do not meet their QoS requirements.
If the DlLdcSwitch and UlLdcSwitch options of the
CellAlgoSwitch.RacAlgoSwitch parameter are selected for the cell, the eNodeB
releases low-priority GBR services in the cell to ensure satisfaction rates for high-
priority GBR services. This congestion control mechanism works in CA scenarios.
If congestion control over GBR services is triggered in a cell because there are
insufficient radio resources, the eNodeB releases GBR services of CA UEs that treat
this cell as their PCell and of non-CA UEs in this cell. (Non-CA UEs are terminals
that do not support CA.) When the eNodeB selects the UEs whose services are to
be released, it removes CA UEs that treat the cell as their SCell from the list of
prioritized candidates. If a service to be released is the only GBR service of a UE
(either CA UE or non-CA UE) that meets conditions for redirection, the eNodeB
redirects the UE. If the service is not the only GBR service or the conditions for
redirection have not been met, the eNodeB releases this GBR service of the UE.
For more details about congestion control, see Admission and Congestion Control.
17.5.1 Scheduling
This section describes how scheduling works when CA is enabled. For more details
about scheduling, see Scheduling.
For GBR services, scheduling with CA enabled is almost the same as scheduling
with CA disabled. The goal of scheduling is still to meet the QoS requirements of
GBR services.
For non-GBR services, Huawei has designed two scheduling methods for the
enhanced proportional fair (EPF) policy: basic and differentiated. The method used
is specified by the CellDlschAlgo.CaSchStrategy parameter. The default method is
basic scheduling. The scheduling method must be consistent between serving cells
to prevent data transmission exceptions. The following presents the characteristics
of the two methods:
● Basic scheduling
When PRBs on a network are abundant, basic scheduling works in the same
way as differentiated scheduling. CA UEs can use sufficient PRBs to meet their
service requirements.
When there is PRB congestion on a network, basic scheduling works to
maintain fairness. The data rate of a CA UE is almost the same as the data
rate of a non-CA UE that is running services with the same QCI.
Due to inconsistent spectral efficiency for the CA UE between CCs, basic
scheduling does not achieve the same data rates for the CA UE and the non-
CA UE when planning to allocate the same number of PRBs to the two UEs.
– If the difference in spectral efficiency between CCs is large (for example,
when the CA UE is located at the edge of its PCell or SCell), there is a
large difference in the number of allocated PRBs between the CA UE and
the non-CA UE.
– If the spectral efficiency is almost the same between CCs, the number of
PRBs allocated to the CA UE is close to that of PRBs allocated to the non-
CA UE.
The CellDlschAlgo.CaSchWeight parameter has been added in eRAN11.1 to
specify a differentiated scheduling factor for CA UEs when the scheduling
method is basic scheduling. This parameter can be set to values of 0 to 10,
which correspond to actual values ranging from 0 to 1. It takes effect only for
downlink scheduling. A larger parameter value results in more scheduling
differentiation between CA UEs and non-CA UEs. A smaller parameter value
results in fairer scheduling. This is a parameter to be set only for PCells. If this
parameter is set to its default value 0, basic scheduling works in the same
way as before. If this parameter is set to a non-zero value, the number of
PRBs allocated to a CA UE is (1 + n x m) times the number of PRBs allocated
to a non-CA UE, where n is the number of activated SCells and m is the actual
value of the parameter that specifies the differentiated scheduling factor.
● Differentiated scheduling
The data rate of a CA UE for priority calculation is defined as the data rate
only on the current CC of the UE. On each CC, the CA UE is allocated the
same number of RBs as a non-CA UE on the same CC would be. Therefore,
the number of RBs allocated to the CA UE is the sum of the average number
of RBs per non-CA UE in each of the serving cells. The data rate of the CA UE
served by n CCs is almost n times the data rate of a non-CA UE, assuming
that the spectral efficiencies of the CCs are close to each other, UEs are evenly
distributed on the CCs, and channel conditions are the same between the CCs.
In differentiated scheduling, a CA UE is treated as a common UE on each CC.
It is scheduled separately in the CCs. Therefore, a CA UE can be allocated
more PRBs and deliver a better user experience than a non-CA UE. However,
radio resources for non-CA UEs decrease.
Currently, frequency selective scheduling is not used in SCells by default. To enable
frequency selective scheduling in SCells, set the CellDlschAlgo.CaSccDopMeas
parameter to FROMPCC.
NOTE
If an SCell is configured in the uplink for a CA UE, uplink scheduling uses the method
configured for downlink scheduling: basic or differentiated scheduling.
Table 17-4 Relationships between the configured values and effective values of
the related threshold parameters
Parameter Configured Effective Value
Value
If an SCell has been activated for a CA UE, the CCE usage of the PCell for the UE is
calculated as follows:
The calculation result will be filtered. The value obtained after filtering will be
compared with the values of CellDlschAlgo.DataSplitCceUsageHighThld and
CellDlschAlgo.DataSplitCceUsageLowThld to determine whether the PCell is in
the congested state.
Table 17-5 provides the definitions of the PCell congested state and non-
congested state and the corresponding handling mechanisms.
Table 17-5 Definitions of the PCell congested state and non-congested state and
the corresponding handling mechanisms
Congested The CCE usage in the PCell for the The downlink data of the
CA UE is greater than the effective UE is transmitted only in
value of the the LTE SCells. However, in
CellDlschAlgo.DataSplitCceUsage- the case of relaxed-
HighThld parameter. backhaul-based inter-
eNodeB CA, the downlink
RLC retransmission data of
inter-eNodeB SCells is still
transmitted in the PCell.
Non- The CCE usage in the PCell for the Downlink data of the UE is
congested CA UE is less than or equal to the transmitted as usual.
effective value of the
CellDlschAlgo.DataSplitCceUsage-
LowThld parameter.
If the CCE usage in the PCell for the CA UE is less than or equal to the effective
value of CellDlschAlgo.DataSplitCceUsageHighThld and greater than the
effective value of CellDlschAlgo.DataSplitCceUsageLowThld, the congestion
status of the PCell is the same as that in the last second.
If the downlink data of a CA UE cannot be transmitted in the PCell:
● The user-perceived data rate decreases. In this situation, if the SCells are
unavailable due to coverage or air interface quality deterioration or because
the transmission rate of downlink data from the core network to the eNodeB
exceeds the transmission specification of the BBP or main control board, the
user-perceived data rate will notably decrease.
● The downlink retransmission rate and downlink scheduling delay will increase
for the CA UE but decrease for non-CA UEs. Therefore, the downlink
retransmission rate and downlink packet delay of the cell will change.
● More resources in the PCell can be spared to non-CA UEs or VoLTE services.
When there are a large number of small-packet services, the number of
scheduling times in the PCell increases. As a result, the CCE usage in the PCell
increases.
NOTE
Extended PHR is an information element introduced by 3GPP for uplink CA UEs. It contains
the PHR for each CC. For details, see section 6.1.3.6a "Extended Power Headroom MAC
Control Element" in 3GPP TS 36.321 V11.0.0.
this option does not produce gains for uplink CA UEs that experience poor uplink
SINR in their SCells in relaxed backhaul scenarios.
17.5.3 MTA
For UEs that support uplink CA, both PCells and SCells provide uplink resources. It
is recommended that multiple timing advances (MTA) be enabled in either of the
following scenarios because using a single TA has a significant impact on
demodulation performance:
● There is a noticeable difference (for example, about 78 meters, which is
equivalent to a TA) between the distances of a CA UE to the receive antennas
of the PCell and an SCell.
● The PCell and an SCell are not served by the same pRRU of a LampSite
eNodeB.
The switch used to enable MTA varies depending on the CA scenario:
● Single-duplex-mode uplink 2CC aggregation: the MtaAlgSwitch option of the
ENodeBAlgoSwitch.CaAlgoSwitch parameter
● FDD+TDD uplink 2CC aggregation: the FTMtaAlgSwitch option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter
After an SCell is configured and activated in both downlink and uplink for a CA
UE, the eNodeB sends a PDCCH order to the UE and, as instructed, the UE initiates
a non-contention-based random access procedure in the SCell. The eNodeB then
sends the UE a random access response to configure a secondary timing advance
group (sTAG) for the UE. The network maintains a TA for each serving cell of the
UE.
If the number of preamble retransmissions in the SCell reaches the maximum
number allowed, the random access procedure fails. The UE stops random access
without instructing the PCell to perform an RRC connection reestablishment. As a
result, the UE is out-of-synchronization in the uplink, and only downlink
scheduling is allowed. If the SCell activation conditions are met and the
resynchronization timer expires, a random access procedure is triggered again. The
eNodeB removes the SCell if consecutive random access attempts fail.
NOTE
For details about PDCCH order, see section 8.0 "UE procedure for transmitting the physical
uplink shared channel" in 3GPP TS 36.213 V11.4.0.
If a TDD cell and an FDD cell are acting as the PCell and SCell respectively in
uplink 2CC aggregation for a UE and the FTMtaAlgSwitch option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter is selected:
● The eNodeB preferentially instructs the UE to send SRSs in the 13th
orthogonal frequency division multiplexing (OFDM) symbol of an uplink
subframe. Uplink scheduling of the UE in the FDD cell yields to the SRS
transmission to ensure beamforming gains in the TDD cell.
● If the CellPdcchAlgo.ComSigCongregLv parameter is set to CONGREG_LV8
for the TDD cell, the PDCCH control channel element (CCE) aggregation level
for common control signaling is so high that the eNodeB transmit power
might be insufficient for sending a Random Access Response message to the
UE. This negatively affects configuration of the uplink SCell for the UE.
For this purpose, all the serving cells use the DRX parameters of the PCell,
including On Duration Timer, DRX Inactivity Timer, and DRX Short Cycle Timer.
Figure 17-1 shows an example of the DRX configuration under CA.
● If DRX is enabled in the PCell and all of the SCells for a CA UE, the UE states
in the cells are handled as follows when the serving eNodeB of the PCell
sends a MAC CE to activate the SCells:
– If the UE has entered the DRX state in the PCell, the UE now also enters
the DRX state in SCells, with the DRX parameters for the PCell applied to
the SCells.
– If the UE has not entered the DRX state in the PCell, the eNodeB
determines whether the UE should enter the DRX state in all the PCell
and SCells based on the traffic volume of the UE.
● If DRX is enabled in the PCell but disabled in an SCell, the UE exits and does
not return to the DRX state after the SCell is configured for the UE.
● If DRX is disabled in the PCell, the UE will not enter the DRX state in either
the PCell or SCells, regardless of whether DRX is enabled in the SCells.
● If DRX and uplink FDD+TDD CA are both enabled, the
DrxParaGroup.OnDurationTimer parameter must be set to a value greater
than four subframes for the FDD cell.
● QCI-specific DRX for the UE is controlled only by the PCell.
For more details about DRX control, see DRX and Signaling Control.
● When the eNodeB detects that the UE has started to access the specific IP
address, the eNodeB removes the limitation on the maximum number of CCs
and immediately initiates an SCell reconfiguration. For example, when the UE
is accessing the specific IP address, CA is allowed for the UE even if this
parameter is set to 1.
● When the eNodeB detects that the UE has stopped accessing the specific IP
address, the eNodeB removes all SCells and then configures SCells for the UE
under the limitation imposed by SpidCfg.MaximumNumberOfCarriers.
The following explains how the eNodeB evaluates access to specific IP addresses.
● The parameters in the ServerConfig MO specify an IP address.
● The MAX_CARRIER_NUM_CONTROL_SW option of the
ServerConfig.IpAdDetectPurposeControlSw parameter specifies whether to
detect the start and stop of access to the IP address.
– If this option is selected, the eNodeB detects the start and stop of access
to the IP address.
NOTE
This function does not work with QCI-based SCell management. Before enabling this
function, ensure that the QciBasedCarrierNumCtrlSw option of the
ENodeBAlgoSwitch.CaAlgoExtSwitch parameter is deselected. For details about QCI-based
SCell management, see HVC Experience Guarantee.
17.7 VoLTE
Collaboration between CA and voice over LTE (VoLTE) is controlled by the
CaMgtCfg.VolteCaA2RsrpThld parameter and the
VolteSupportCaInterFreqMeasSw option of the CaMgtCfg.CellCaAlgoSwitch
parameter. The LMPT is incompatible with the CaMgtCfg.VolteCaA2RsrpThld
parameter.
▪ Option selected
If the VoLTE UE has never reported CA event A2 because the PCell
RSRP is less than or equal to the threshold when it is in the
RRC_CONNECTED state, PCC anchoring and SCell configuration
based on inter-frequency measurements, as well as PCC anchoring
and SCell configuration based on virtual grids, take effect for the UE
while the VoLTE service is ongoing.
If the VoLTE UE has ever reported CA event A2 because the PCell
RSRP is less than or equal to the threshold when it is in the
RRC_CONNECTED state, PCC anchoring and SCell configuration
based on inter-frequency measurements, as well as PCC anchoring
and SCell configuration based on virtual grids, take effect for the UE
only after the QCI-1 bearer of the UE is released.
▪ Option deselected
PCC anchoring and SCell configuration based on inter-frequency
measurements, as well as PCC anchoring based on virtual grids, do
not take effect for the VoLTE UE.
If the CaMgtCfg.VolteCaA2RsrpThld parameter is set to a value in the range
of -140 to -43, the eNodeB initiates an SCell configuration procedure for the
UE with the current serving cell as its PCell upon release of the bearer with a
QCI of 1.
18 Parameters
You can find the EXCEL files of parameter reference and used reserved parameter list for
the software version used on the live network from the product documentation delivered
with that version.
Step 2 On the Parameter List sheet, filter the Feature ID column. Click Text Filters and
choose Contains. Enter the feature ID, for example, LOFD-001016 or
TDLOFD-001016.
Step 3 Click OK. All parameters related to the feature are displayed.
----End
Step 1 Open the EXCEL file of the used reserved parameter list.
Step 2 On the Used Reserved Parameter List sheet, use the MO, Parameter ID, and BIT
columns to locate the reserved parameter, which may be only a bit of a parameter.
View its information, including the meaning, values, impacts, and product version
in which it is activated for use.
----End
19 Counters
The following hyperlinked EXCEL files of performance counter reference match the
software version with which this document is released.
● Node Performance Counter Summary: contains device and transport counters.
● eNodeBFunction Performance Counter Summary: contains all counters related
to radio access functions, including air interface management, access control,
mobility control, and radio resource management.
NOTE
You can find the EXCEL files of performance counter reference for the software version used
on the live network from the product documentation delivered with that version.
----End
20 Glossary
21 Reference Documents