Professional Documents
Culture Documents
Issue 04
Date 2013-10-30
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: http://www.huawei.com
Email: support@huawei.com
Contents
2 Overview.........................................................................................................................................4
2.1 Basic Concepts...............................................................................................................................................................5
2.1.1 Cell Load.....................................................................................................................................................................5
2.1.2 Service Type................................................................................................................................................................5
2.1.3 Source Cell and Target Cell.........................................................................................................................................6
2.2 MLB Procedure..............................................................................................................................................................6
5 Related Features...........................................................................................................................17
5.1 Features Related to LOFD-001032 Intra-LTE Load Balancing...................................................................................17
5.2 Features Related to LOFD-001044 Inter-RAT Load Sharing to UTRAN...................................................................17
5.3 Features Related to LOFD-001045 Inter-RAT Load Sharing to GERAN...................................................................18
6 Network Impact...........................................................................................................................19
7 Engineering Guidelines.............................................................................................................21
7.1 When to Use MLB........................................................................................................................................................21
7.2 Required Information...................................................................................................................................................21
7.3 Planning........................................................................................................................................................................21
7.3.1 RF Planning...............................................................................................................................................................21
7.3.2 Network Planning......................................................................................................................................................22
7.3.3 Hardware Planning....................................................................................................................................................22
7.4 Deployment..................................................................................................................................................................22
7.4.1 Requirements.............................................................................................................................................................22
7.4.2 Data Preparation........................................................................................................................................................22
7.4.3 Precautions.................................................................................................................................................................32
7.4.4 Activation..................................................................................................................................................................32
7.4.5 Activation Observation..............................................................................................................................................36
7.4.6 Deactivation...............................................................................................................................................................44
7.5 Performance Monitoring...............................................................................................................................................45
7.6 Parameter Optimization................................................................................................................................................47
7.7 Troubleshooting............................................................................................................................................................47
8 Parameters.....................................................................................................................................50
9 Counters......................................................................................................................................105
10 Glossary.....................................................................................................................................108
11 Reference Documents.............................................................................................................109
1.1 Scope
This document describes mobility load balancing (MLB), including its technical principles,
related features, network impact, and engineering guidelines.
Any managed objects (MOs), parameters, alarms, or counters described herein correspond to
the software release delivered with this document. Any future updates will be described in the
product documentation delivered with future software releases.
This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD, and
"eNodeB" refers to LTE FDD eNodeB.
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier version
04 (2013-10-30)
This issue includes the following changes.
03 (2013-08-30)
This issue includes the following changes.
02 (2012-05-31)
This issue includes the following changes.
01 (2013-04-28)
This issue includes the following changes.
Draft A (2013-01-30)
Compared with Issue 05 (2012-12-29) of eRAN3.0, Draft A (2013-01-30) of eRAN6.0 includes
the following changes.
2 Overview
Mobility load balancing (MLB) coordinates load distribution among inter-frequency cells to
maximize network resource usage. To achieve these goals, MLB checks the load status of cells,
exchanges cell load information, and transfers load from heavily loaded cells to lightly loaded
cells. In addition, MLB can transfer load to inter-RAT cells to reduce the E-UTRAN congestion
rate, increase the access success rate, and improve user experience with services.
NOTE
MLB can be classified into inter-frequency load balancing and inter-RAT load sharing.
l The air interface load is represented by the uplink (UL) and DL PRB usages in each cell.
For details about how to calculate the PRB usage, see section 4.1.1 in 3GPP TS 36.314
V10.2.0 (2011-09).
l The hardware load is represented by the hardware resource usage, such as the central
processing unit (CPU) and digital signal processing (DSP) hardware usage.
l The transport network layer load is represented by the S1 bandwidth usage. For details, see
Transport Resource Management Feature Parameter Description.
According to section 9.2.36 in 3GPP TS 36.423 V10.5.0 (2012-03), the hardware and transport
network layer loads can be in one of the following states: LowLoad, MediumLoad, HighLoad,
and Overload.
3900 series eNodeBs currently support only MLB triggered by the air interface load.
In RAN sharing scenarios, cell load is measured on a per cell basis, not on a per operator basis.
NOTE
For concepts related to RAN sharing, see RAN Sharing Feature Parameter Description.
services. In MLB, the eNodeB determines the load balancing type based on the percentage of
resources occupied by each type of service.
After executing MLB, the eNodeB monitors the performance of the source and target cells.
The performance serves as a basis for the next selection of a target cell for MLB.
This chapter describes the optional feature LOFD-001032 Intra-LTE Load Balancing.
Inter-frequency load balancing transfers some UEs in connected mode to balance load between
inter-frequency neighboring cells. This feature applies to inter-frequency cells with the same
coverage or with a large proportion of overlapping coverage. Therefore, inter-frequency load
balancing takes into consideration all the UEs in connected mode in a cell.
The following sections describe the procedure for inter-frequency load balancing.
Load information exchange is triggered for inter-frequency load balancing if the air interface
load of a cell is consistently equal to or greater than the sum of CellMLB.InterFreqMlbThd
(the threshold above which inter-frequency load balancing is started) and
CellMLB.LoadOffset.
Load balancing is preferentially triggered by GBR services, then by total services. If the PRB
usage of GBR services is greater than the specified threshold, load balancing is triggered by
GBR services. If the PRB usage of GBR services is less than the specified threshold but the PRB
usage of total services is greater than the specified threshold, load balancing is triggered by total
services. Services that trigger load balancing are treated separately in the uplink and downlink.
Load offset is used to prevent load fluctuations from frequently triggering and stopping load
balancing.
Load information exchange is stopped if the PRB usage of the serving cell is consistently less
than the value of CellMLB.InterFreqMlbThd .
If the cell does not have any inter-frequency neighboring cells under the same eNodeB, the
serving cell initiates a resource status request towards the neighboring cells on a specified list
to exchange load information. The load information consists of the air interface, hardware, and
transport network layer loads. The air interface load is represented by the total PRB usage, PRB
usage of GBR services, and PRB usage of non-GBR services in the uplink or downlink in each
cell.
NOTE
Inter-eNodeB cells exchange load information through the X2 interface. If the X2 interface is not
configured, load information cannot be exchanged between the cells, and therefore the subsequent activities
are not performed.
l Cells under a neighboring eNodeB to which the local eNodeB is not connected through an
X2 interface
l Cells with a handover success rate less than 98%
The serving cell requests all candidate cells to report their load information. If the serving cell
receives a RESOURCE STATUS RESPONSE message from a neighboring cell, the serving cell
will periodically receive subsequent RESOURCE STATUS UPDATE messages from that
neighboring cell. If the serving cell receives a RESOURCE STATUS FAILURE message from
a neighboring cell, the neighboring cell is not considered a qualified candidate for load balancing
at present.
NOTE
If a neighboring cell stops reporting RESOURCE STATUS UPDATE messages after several reports, the
cell is not considered as a candidate cell at present.
After load information exchange, the eNodeB derives a preliminary candidate cell list based on
factors such as cell bandwidth differences and the uplink or downlink resources occupied by
GBR and total services. Then, the eNodeB generates a target cell list by removing the
neighboring cells that meet any of the following conditions:
l The success rate of handovers from the serving cell to the neighboring cell is less than 98%.
l The TNL load or hardware load of the neighboring cell is in the HighLoad or Overload
state.
l Between the neighboring and serving cells, services in the uplink or downlink that trigger
load balancing is less than the value of CellMLB.LoadDiffThd.
If the target cell list is empty, the eNodeB stops load balancing for the serving cell.
NOTE
In RAN sharing scenarios, a neighboring cell can be the target cell regardless of whether the cell operates
in RAN sharing with common carriers mode or in RAN sharing with dedicated carriers mode.
It is recommended that the CellMLB.InterFreqMlbThd parameter be set to the same value throughout the
network.
The target cell may be so heavily loaded that load balancing from the target cell to other cells is also
triggered in the same direction (uplink or downlink) as load balancing from the source cell. In this situation,
load balancing from the source cell to the target cell is still performed as long as the target cell meets the
load balancing condition.
In addition, the eNodeB considers both the uplink and downlink PRB usages of UEs during UE
selection for load balancing. That is, the uplink and downlink PRB usages of the UEs that are
selected by the eNodeB must meet certain conditions. This prevents ping-pong load balancing
in the transmission direction opposite to the MLB-triggering direction after the UEs are
transferred to the neighboring cell. If uplink or downlink PRB usage of the selected UEs is too
large, load balancing is likely to be triggered in the uplink or downlink of the target cell. If the
uplink or downlink PRB usage of the selected UEs is too small, the load of the source cell may
not be reduced in time.
For example, if load balancing is triggered by GBR services in the downlink, the eNodeB selects
the UEs that meet the following conditions for load balancing:
l The PRB usage of downlink GBR services is greater than 2% and less than or equal to half
of the value of the CellMLB.LoadDiffThd parameter.
l The PRB usage of uplink GBR services is less than or equal to 2%.
This prevents load balancing triggered by GBR services in the uplink after the UEs are transferred
to the neighboring cell.
In inter-frequency load balancing, there are two methods to transfer UEs that support inter-
frequency handover: blind handover and measurement-based handover. Measurement-based
handovers work by default, and in this case it is required that the RSRP of target inter-frequency
cells must be greater than the value of the
InterFreqHoGroup.InterFreqLoadBasedHoA4ThdRsrp parameter. Blind handovers work
only if the InterFreqMlbBlindHo(InterFreqMlbBlindHo) option of the
CellAlgoSwitch.MlbHoMode parameter is selected.
NOTE
The total number of RBs in a cell used by the UEs to be transferred within an inter-frequency load balancing
process cannot exceed the maximum number, which is calculated based on the PRB usage difference
between the source and target cells and the CellMLB.LoadTransferFactor parameter. A greater PRB
usage difference or a larger value of the CellMLB.LoadTransferFactor parameter produces a larger total
number of RBs in a cell used by the UEs to be transferred within an inter-frequency load balancing process.
A UE is considered as a CA UE regardless of whether the UE is in its secondary serving cell (SCell) or
primary serving cell (PCell).
During inter-frequency load balancing, the serving cell rejects incoming handover requests with
the cause value "Resource optimisation handover".
NOTE
For definitions of the cause values for handover requests, see section 9.2.1.3 in 3GPP TS 36.413 V10.6.0
(2012-06) and section 9.2.6 in 3GPP TS 36.423 V11.1.0 (2012-06).
Based on the measurement results reported by the UEs, the eNodeB performs inter-frequency
handovers for UEs that meet the handover conditions. For details about inter-frequency
handovers, see Mobility Management in Connected Mode Feature Parameter Description.
NOTE
The EPC sends an SPID to the eNodeB when a UE accesses the network. The subscriber profile identified
by the SPID includes the mobility and service usage information to which the UE subscribes. The operators'
network plan determines subscriber profiles. For details about SPIDs, see section 8.6.2.2 in 3GPP TS 36.413
V10.6.0 (2012-06) and section 16.1.8 and Annex I in 3GPP TS 36.300 V11.2.0 (2012-06).
The UE will be transferred only to the RATs or frequencies specified in the SPID configuration if the
following conditions are met:
l The UE is to be transferred and the eNodeB has learned the UE's SPID from the EPC.
l The SpidCfg MO corresponding to this SPID has been configured on the eNodeB with the
SpidCfg.InterFreqMlbSwitch parameter set to TRUE(TRUE).
l Total number of UEs that are handed over to target cells and UEs whose RRC connections
are reestablished with the target cells because of radio link failures during handovers
l Total PRB usage
Operators can query the SON logs for the statistics on load balancing within each period.
The eNodeB monitors the success rate of handovers from the source cell. In the next round of
load measurement and evaluation, the handover success rate is considered as an evaluation
standard for selecting target cells for inter-frequency load balancing.
This chapter describes the optional features LOFD-001044 Inter-RAT Load Sharing to
UTRAN and LOFD-001045 Inter-RAT Load Sharing to GERAN.
The decision on inter-RAT load sharing is based on the load of an E-UTRAN cell. If an E-
UTRAN cell becomes heavily loaded, the eNodeB can trigger inter-RAT load sharing based on
UE capabilities, load statistics of the target inter-RAT network, and system performance. After
triggering inter-RAT load sharing, the eNodeB takes one or both of the following actions:
NOTE
For definitions of the cause values for handover requests, see section 9.2.1.3 in 3GPP TS 36.413 V10.6.0
(2012-06) and section 9.2.6 in 3GPP TS 36.423 V11.1.0 (2012-06).
The following sections describe the principles of transferring UEs in connected mode and idle
mode.
If handover is enabled but the UEs do not support handover, the eNodeB performs redirections
for load sharing.
For details about the description of inter-RAT handover, see Mobility Management in Connected
Mode Feature Parameter Description.
NOTE
The EPC sends an SPID to the eNodeB when a UE accesses the network. The subscriber profile identified
by the SPID includes the mobility and service usage information to which the UE subscribes. The operators'
network plan determines subscriber profiles. For details about SPIDs, see section 8.6.2.2 in 3GPP TS 36.413
V10.6.0 (2012-06) and section 16.1.8 and Annex I in 3GPP TS 36.300 V11.2.0 (2012-06).
The UE will be transferred only to the RATs or frequencies specified in the SPID configuration if the
following conditions are met:
l The UE is to be transferred and the eNodeB has learned the UE's SPID from the EPC.
l The SpidCfg MO corresponding to this SPID has been configured on the eNodeB with the
SpidCfg.InterRatMlbSwitch parameter set to TRUE(TRUE).
The actual duration of load sharing with UTRAN is calculated based on the value of the
CellMLB.InitValidPeriod parameter and the number of uplink synchronized UEs. The
CellMLB.InitValidPeriod parameter specifies the initial duration of load sharing with UTRAN
for UEs in idle mode, and the actual duration increases with the number of uplink synchronized
UEs. Therefore, the larger the value of the CellMLB.InitValidPeriod parameter or the number
of uplink synchronized UEs, the larger the actual duration of load sharing with UTRAN. Within
the time of actual duration, UEs preferentially camp on neighboring UTRAN cells if the UEs
are to be released after the inactive timer expires.
Load sharing with UTRAN for UEs in idle mode takes effect only if the priorities of the serving
frequency and the neighboring E-UTRAN frequencies of the serving cell are all higher than or
all lower than those of the neighboring UTRAN frequencies of the serving cell.
Operators can query the SON logs for the statistics on load sharing within each period.
5 Related Features
Impacted Features
None
Impacted Features
None
Impacted Features
None
6 Network Impact
Network Performance
The Intra-LTE Load Balancing feature increases the number of intra-LTE handovers.
Network Performance
The Inter-RAT Load Sharing to UTRAN feature increases the number of inter-RAT handovers
from E-UTRAN to UTRAN and the value of the L.RRC.ConnReq.Att.MoSig counter in the
source cell.
Network Performance
The Inter-RAT Load Sharing to GERAN feature increases the number of inter-RAT handovers
from E-UTRAN to GERAN and the value of the L.RRC.ConnReq.Att.MoSig counter in the
source cell.
7 Engineering Guidelines
Use inter-RAT load sharing if multi-mode base stations are used or base stations of different
RATs provide contiguous coverage.
l Information about each neighboring cell of the cells under the local eNodeB
– Whether information about the neighboring cell is complete
– Whether the neighboring cell has been blacklisted
– Whether the No Handover attribute is set to prohibit handovers to the neighboring cell
l Status of the X2 interfaces with neighboring eNodeBs
l UE capabilities
The proportion of UEs that support inter-frequency or inter-RAT measurements
7.3 Planning
7.3.1 RF Planning
MLB is implemented by handover and reselection. Therefore, the current network coverage must
meet the following UE mobility requirements:
7.4 Deployment
7.4.1 Requirements
There are no requirements for the operating system and transmission networking. Before
deploying MLB, the operator must purchase and activate the licenses for the features listed in
Table 7-1.
l Network plan (negotiation required): parameter values planned by the operator and
negotiated with the EPC or peer transmission equipment
l Network plan (negotiation not required): parameter values planned and set by the operator
l User-defined: parameter values set by users
Required Data
The following table describes the parameters that must be set in the CellMLB managed object
(MO) to configure MLB algorithms.
The following table describes the parameter that must be set in the InterFreqHoGroup MO to
configure inter-frequency handover.
The following table describes the parameter that must be set in the InterRatHoUtranGroup
MO to configure inter-RAT handover to UTRAN.
The following table describes the parameters that must be set in the InterRatHoGeranGroup
MO to configure inter-RAT handover to GERAN.
Scenario-specific Data
Scenario 1: Inter-Frequency Load Balancing
The following table describes the parameters that must be set in the CellAlgoSwitch MO to
enable the inter-frequency load balancing algorithm.
The following table describes the parameters that must be set in the CellMLB MO to configure
the inter-frequency load balancing algorithm.
Local cell ID CellMLB. Network plan This parameter specifies the local
LocalCellId (negotiation not ID of a cell. It uniquely identifies
required) the cell within an eNodeB.
The actual value range is 0 to 17.
Load Transfer CellMLB. Network plan This parameter specifies the factor
Factor LoadTransfer (negotiation not used to control the amount of load
Factor required) transferred during a single MLB
procedure. The value of this
parameter has an impact on the
efficiency of the MLB algorithm
and the algorithm to prevent ping-
pong load transfer.
A larger value of this parameter
leads to the situation where a
larger amount of load can be
transferred, and a smaller value
leads to the situation where a
smaller amount of load can be
transferred. The recommended
value is 0.
(Optional) The following table describes the parameters that must be set in SpidCfg MOs to
configure SPIDs.
The following table describes the parameters that must be set in the CellAlgoSwitch MO to
enable the inter-RAT load sharing algorithm.
The UtranIdleMlbSwitch
(UtranIdleMLBSwitch) check box under
this parameter specifies whether to enable
load sharing with UTRAN for UEs in idle
mode.
l If UtranIdleMlbSwitch
(UtranIdleMLBSwitch) is selected,
the algorithm is enabled.
l If UtranIdleMlbSwitch
(UtranIdleMLBSwitch) is not
selected, the algorithm is disabled.
The GeranMlbSwitch
(GeranMlbSwitch) check box under this
parameter specifies whether to enable load
sharing with GERAN.
l If GeranMlbSwitch
(GeranMlbSwitch) is selected, the
algorithm is enabled.
l If GeranMlbSwitch
(GeranMlbSwitch) is not selected, the
algorithm is disabled.
The following table describes the parameters that must be set in the ENodeBAlgoSwitch MO
to configure the inter-RAT load sharing policy.
The following table describes the parameters that must be set in the CellMLB MO to configure
the inter-RAT load sharing algorithm.
The following table describes the parameters that must be set in SpidCfg MOs to configure
SPIDs.
7.4.3 Precautions
Pay attention to the following when deploying MLB in a live network:
l If the switches for inter-frequency load balancing and inter-RAT load sharing are turned
on for a cell and the cell load meets the conditions for starting both types of MLB, the
probabilities of both types are the same because no priorities have been specified for the
different types of MLB.
l Inter-frequency load balancing is recommended in live networks.
7.4.4 Activation
Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs
Enter the values of the parameters listed in Table 7-2 in a summary data file, which also contains
other data for the new eNodeBs to be deployed. Then, import the summary data file into the
Configuration Management Express (CME) for batch configuration. For detailed instructions,
see section "Creating eNodeBs in Batches" in the initial configuration guide for the eNodeB.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MOs in Table 7-2 are contained in a scenario-specific summary data file. In this
situation, set the parameters in the MOs, and then verify and save the file.
l Some MOs in Table 7-2 are not contained in a scenario-specific summary data file. In this
situation, customize a summary data file to include the MOs before you can set the
parameters.
Step 1 Choose CME > Advanced > Customize Summary Data File (M2000 client mode), or choose
Advanced > Customize Summary Data File (M2000 client mode), to customize a summary
data file for batch reconfiguration.
NOTE
Step 2 Choose CME > LTE Application > Export Data > Export Base Station Bulk Configuration
Data (M2000 client mode), or choose LTE Application > Export Data > Export Base Station
Bulk Configuration Data (CME client mode), to export the eNodeB data stored on the CME
into the customized summary data file.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-2 and close the file.
Step 4 Choose CME > LTE Application > Import Data > Import Base Station Bulk Configuration
Data (M2000 client mode), or choose LTE Application > Import Data > Import Base Station
Bulk Configuration Data (CME client mode), to import the summary data file into the CME.
Step 5 Choose CME > Planned Area > Export Incremental Scripts (M2000 client mode), or choose
Area Management > Planned Area > Export Incremental Scripts (CME client mode), to
export and activate the incremental scripts.
----End
Step 1 In the planned data area, click Base Station in the upper left corner of the configuration window.
Step 2 In area 1 shown in Figure 7-1, select the eNodeB to which the MOs belong.
Step 3 On the Search tab page in area 2, enter an MO name, for example, CELL.
Step 4 In area 3, double-click the MO in the Object Name column. All parameters in this MO are
displayed in area 4.
Step 5 Set the parameters in area 4 or 5.
Step 6 Choose CME > Planned Area > Export Incremental Scripts (M2000 client mode), or choose
Area Management > Planned Area > Export Incremental Scripts (CME client mode), to
export and activate the incremental scripts.
----End
Step 1 Run the MOD CELLMLB command to set the threshold for inter-frequency load balancing.
Step 2 Run the MOD CELLALGOSWITCH command to enable the inter-frequency load balancing
algorithm.
Step 3 (Optional) Run the ADD SPIDCFG command to set an SPID and enable SPID-specific inter-
frequency load balancing. If the SPID already exists, run the MOD SPIDCFG command to
modify the configuration as required.
----End
Scenario 2: Inter-RAT Load Sharing for UEs in Connected Mode
----End
Scenario 3: Inter-RAT Load Sharing for UEs in Idle Mode
Step 1 Run the MOD CELLMLB command to modify the threshold for inter-RAT load sharing, the
threshold for the number of uplink synchronized UEs, and the initial duration for load sharing
with UTRAN for UEs in idle mode.
Step 2 Run the MOD CELLALGOSWITCH command to enable inter-RAT load sharing with
UTRAN for UEs in idle mode.
----End
Step 1 On the M2000 client, choose Monitor > Signaling Trace > Signaling Trace Management.
2. Set the task name, select the eNodeB site, and click Next.
The Usage of RB Monitoring dialog box as shown in Figure 7-4 is displayed.
2. Set the task name, select the eNodeB site, and click Next.
3. Enter the information about a neighboring cell of the local cell to be traced, as shown in
Figure 7-7.
4. Click Finish.
The MLB performance monitoring task starts for the local cell, and the monitoring result
is displayed as shown in Figure 7-8. The monitoring result includes the PRB usage of the
cell, the PRB usage of the neighboring cell, and the type of load that triggers MLB in the
local cell.
NOTE
For details about the types of load that trigger MLB, see the related performance monitoring reference.
3. Click Finish.
The Uu interface tracing task starts for the cell, and the tracing result is displayed as shown in
Figure 7-11.
Step 5 Start X2 interface tracing in a similar way as Step 4, and check the messages traced over the X2
interface.
NOTE
Load information can be traced on the X2 interface only in inter-eNodeB inter-frequency load balancing.
No load information is exchanged over the X2 interface in intra-eNodeB inter-frequency load balancing.
If the serving cell receives a RESOURCE STATUS RESPONSE message from a neighboring
cell after sending a RESOURCE STATUS REQUEST message to the neighboring cell, and later
periodically receives RESOURCE STATUS UPDATE messages from the neighboring cell,
inter-frequency load balancing has been activated. Figure 7-12 shows an example of the
RESOURCE STATUS REQUEST message.
NOTE
The RESOURCE STATUS REQUEST message contains the IDs (eUTRANcellIdentifier IE) of the cells
whose load information is requested and the interval (reportingPeriodicity IE) at which the cell load
information needs to be reported.
Step 6 Use UE1 to access the local cell in the cell center, and use UE2 to access the cell at a place where
UE2 can receive signals from an inter-frequency neighboring cell with RSRP greater than
InterFreqHoGroup.InterFreqLoadBasedHoA4ThdRsrp.
Step 7 (This step simulates downlink overload in a 10 MHz cell as an example.) Inject downlink UDP
packets for UE1 until the M2000 client shows that the RB usage exceeds the sum of Inter-
Frequency Mobility Load Balancing Threshold and Load Offset. Inject downlink UDP
packets at a rate of 2 Mbit/s for at least 1 minute.
Step 8 Check for an RRC_CONN_RECFG message in the Uu interface tracing result and a
HANDOVER_REQUEST message in the X2 interface tracing result.
----End
To use SON logs to verify whether MLB takes effect, perform the following steps:
Step 2 On the Query SON Log tab page, choose MLB Log from the Log Category drop down list in
the upper left corner, and click Inter-Frequency Handover Statistics under Event Name.
Then, click Query to query SON logs. From the logs, check whether the feature is working
correctly.
You can view only the SON logs that were generated at least one day ago.
----End
Step 1 On the M2000 client, start Uu interface tracing, S1 interface tracing, and RB usage monitoring.
For details about how to start these three tasks, see Inter-Frequency Load Balancing earlier
in this section.
Step 2 Use UE1 to access a cell in the cell center, and use UE2 to access the cell at a place where UE2
can receive signals from an inter-RAT neighboring cell with the radio signal greater than the
trigger thresholds for load- and service-based event B1. In addition, ensure that the number of
uplink synchronized UEs in the cell is greater than or equal to the Inter-RAT Mobility Load
Balancing UE Number Threshold value.
Step 3 (This step simulates downlink overload in a 10 MHz cell as an example.) Inject downlink UDP
packets for UE1 until the M2000 client shows that the RB usage exceeds the sum of Inter-RAT
Mobility Load Balancing Threshold and Load Offset. Inject downlink UDP packets for UE2
at a rate of 2 Mbit/s.
Step 4 Check for an S1AP_HANDOVER_REQUIRED message in the S1 interface tracing result.
If the S1AP_HANDOVER_REQUIRED message containing the cause value "reduce-load-in-
serving-cell" exists, inter-RAT load sharing for UEs in connected mode is working correctly.
----End
To use SON logs to verify whether MLB takes effect, perform the following steps:
Step 2 On the Query SON Log tab page, choose MLB Log from the Log Category drop down list in
the upper left corner, and click Inter-RAT Handover Statistics under Event Name. Then, click
Query to query SON logs. From the logs, check whether the feature is working correctly.
----End
Step 1 On the M2000 client, start Uu interface tracing, S1 interface tracing, and RB usage monitoring.
For details about how to start these three tasks, see Inter-Frequency Load Balancing earlier
in this section.
Step 2 Use UE1 to access a cell in the cell center, and use UE2 to access the cell at a place where UE2
can receive signals from an inter-RAT neighboring cell with a signal level higher than the cell-
reselection threshold. In addition, ensure that the number of uplink synchronized UEs in the cell
is greater than or equal to the Inter-RAT Mobility Load Balancing UE Number Threshold
value.
Step 3 (This step simulates downlink overload in a 10 MHz cell as an example.) Inject downlink UDP
packets for UE2 at a rate of 2 Mbit/s. Inject downlink UDP packets for UE1 until the M2000
client shows that the RB usage exceeds the sum of Inter-RAT Mobility Load Balancing
Threshold and Load Offset. Stop injecting downlink UDP packets for UE2. Wait until its
inactivity timer expires, so that UE2 enters idle mode. Check whether the RB usage exceeds the
sum of Inter-RAT Mobility Load Balancing Threshold and Load Offset.
If UE2 enters idle mode within the configured initial duration, the reselection priority contained
in the RRC_CONN_REL message in the Uu interface tracing result meets the requirements, and
UE2 is successfully transferred to the UTRAN cell, inter-RAT load sharing is working correctly.
For details about the reselection priority, see 4.3.2 Transferring UEs in Idle Mode.
----End
7.4.6 Deactivation
Using the CME to Perform Batch Configuration
Batch reconfiguration using the CME is the recommended method to deactivate a feature on
eNodeBs. This method reconfigures all data, except neighbor relationships, for multiple
eNodeBs in a single procedure. The procedure for feature deactivation is similar to that for
feature activation described in Using the CME to Perform Batch Configuration for Existing
eNodeBs. In the procedure, modify parameters according to Table 7-3.
Run the MOD CELLALGOSWITCH command to disable the inter-frequency load balancing
algorithm.
Run the MOD CELLALGOSWITCH command to disable inter-RAT load sharing with
UTRAN for UEs in connected or idle mode or inter-RAT load sharing with GERAN.
Table 7-5 lists the counters used to monitor inter-RAT load sharing performance.
NOTE
LOFD-00105401 Camp & Handover Based on SPID and LOFD-001112 MOCN Flexible Priority Based
Camping also affect the L.RRCRel.DedicatedPri.WCDMA.High counter.
7.7 Troubleshooting
This section provides steps to troubleshoot a possible fault that might occur after MLB is enabled.
Serving Cell Not Initiating Load Information Exchange for Inter-Frequency Load
Balancing
Fault Description
When inter-frequency load balancing is enabled and packet injection is performed for a UE, the
serving cell fails to initiate load information exchange with the neighboring E-UTRAN cells.
Fault Handling
Step 1 On the M2000 client, start X2 interface tracing task by referring to Inter-Frequency Load
Balancing in 7.4.5 Activation Observation.
Step 2 Check whether the serving eNodeB has sent a RESOURCE STATUS REQUEST message,
which contains information about the neighboring cells involved in load information exchange
with the serving cell. If the eNodeB has not sent this message, then this fault did occur. Go to
Step 3.
3. If No handover indicator for the neighboring cell is Permit Ho, go to Step 4. Otherwise,
run the MOD EUTRANINTERFREQNCELL command to change it to Permit Ho.
Step 4 Run the LST INTERFREQBLKCELL command to check whether the displayed inter-
frequency neighboring cells have been blacklisted.
l If all these neighboring cells are blacklisted, this fault occurred because the eNodeB does
not perform MLB on blacklisted cells. No further action is required.
l Otherwise, go to Step 5.
Step 5 On the M2000 client, check whether ALM-29247 Cell PCI Conflict has been reported for the
serving cell.
l If this alarm has been reported, handle the alarm by following handling suggestions in the
alarm reference.
l If this alarm has not been reported, contact Huawei technical support.
----End
Failing to Initiate Inter-RAT Load Sharing with UTRAN for UEs in Connected
Mode
Fault Description
When inter-RAT load sharing with UTRAN for UEs in connected mode is enabled, the
UtranPsHoSwitch(UtranPsHoSwitch) check box under the Handover Mode switch
parameter is selected, and packet injection is performed for UEs, the servicing cell cannot initiate
inter-RAT load sharing to a UTRAN cell for any UE.
Fault Handling
Step 1 On the M2000 client, start RB usage monitoring by referring to Inter-Frequency Load
Balancing in 7.4.5 Activation Observation.
Step 2 Check whether the RB usage of the serving cell exceeds the sum of Inter-RAT Mobility Load
Balancing Threshold and Load Offset.
l If so, go to Step 3.
l If not, increase the traffic volume of UEs.
Step 3 Check whether the number of uplink synchronized UEs exceeds Inter-RAT Mobility Load
Balancing UE Number Threshold.
l If so, go to Step 4.
l If not, this is not a problem. No further action is required.
Step 4 Run the LST UTRANNCELL command to check whether the inter-RAT neighbor relationship
has been configured on the serving cell.
l If so, contact Huawei technical support.
l If not, configure the inter-RAT neighbor relationship on the serving cell.
----End
Failing to Initiate Inter-RAT Load Sharing with UTRAN for UEs in Idle Mode
Fault Description
When inter-RAT load sharing with UTRAN for UEs in idle mode is enabled, no UE in the serving
cell can be transferred to a UTRAN cell by cell reselection.
Fault Handling
Step 1 On the M2000 client, start RB usage monitoring by referring to Inter-Frequency Load
Balancing in 7.4.5 Activation Observation.
Step 2 Check whether the RB usage of the serving cell exceeds the sum of Inter-RAT Mobility Load
Balancing Threshold and Load Offset.
l If so, go to Step 3.
l If not, increase the traffic volume of UEs.
Step 3 Check whether the number of uplink synchronized UEs exceeds Inter-RAT Mobility Load
Balancing UE Number Threshold.
l If so, go to Step 4.
l If not, this is not a problem. No further action is required.
Step 4 Check whether the priorities of E-UTRAN frequencies and those of neighboring UTRAN
frequencies belong to non-overlapping ranges.
l If so, go to Step 5.
l If not, modify the frequency priority configurations.
Step 5 Run the LST UTRANNCELL command to check whether the inter-RAT neighbor relationship
has been configured on the serving cell.
l If so, contact Huawei technical support.
l If not, configure the inter-RAT neighbor relationship on the serving cell.
----End
8 Parameters
enabled to
balance or share
the loads
between
neighboring
cells of the
specified
category. If
IntraFreqMlbS-
witch is set to
On, intra-
frequency load
balancing is
enabled and
therefore
IntraFreqI-
dleMlbSwitch
becomes valid.
If
IntraFreqMlbS-
witch is set to
Off, intra-
frequency load
balancing is
disabled and
therefore
IntraFreqI-
dleMlbSwitch
does not take
effect. This
parameter will
be removed in
later versions. In
this version, the
setting of this
parameter is still
synchronized
between the
M2000 and the
eNodeB, but it is
no longer used
internally.
Therefore, avoid
using this
parameter. If
InterFreqMlbS-
witch is set to
On, inter-
frequency load
balancing is
enabled. If
InterFreqMlbS-
witch is set to
Off, inter-
frequency load
balancing is
disabled. If
UtranMlbSwitc
h is set to On,
load sharing
with UTRAN is
enabled. If
UtranMlbSwitc
h is set to Off,
load sharing
with UTRAN is
disabled. If
GeranMlbSwitc
h is set to On,
load sharing
with GERAN is
enabled. If
GeranMlbSwitc
h is set to Off,
load sharing
with GERAN is
disabled. If
CdmaMlbSwitc
h is set to On,
load sharing
with
CDMA2000 is
enabled. If
CdmaMlbSwitc
h is set to Off,
load sharing
with
CDMA2000 is
disabled. This
parameter will
be removed in
later versions. In
this version, the
setting of this
parameter is still
synchronized
between the
M2000 and the
eNodeB, but it is
no longer used
internally.
Therefore, avoid
using this
parameter. If
both IntraFreqI-
dleMlbSwitch
and
IntraFreqMlbS-
witch are set to
On, intra-
frequency load
balancing for
UEs in idle
mode is enabled.
Otherwise,
intra-frequency
idle load
balancing for
UEs in idle
mode is
disabled. This
parameter will
be removed in
later versions. In
this version, the
setting of this
parameter is still
synchronized
between the
M2000 and the
eNodeB, but it is
no longer used
internally.
Therefore, avoid
using this
parameter. If
UtranIdleMlbS-
witch is set to
On, load sharing
with UTRAN
for UEs in idle
mode is enabled.
If
UtranIdleMlbS-
witch is set to
Off, load sharing
with UTRAN
for UEs in idle
mode is
disabled. If
MlbLoadInfoS-
witch is set to
On, whether the
load sharing
between an E-
UTRAN cell
and an inter-
RAT cell is
performed based
on load of the
inter-RAT cell.
If
MlbLoadInfoS-
witch is set to
Off, load of an
inter-RAT cell is
not considered
when the load
sharing between
an E-UTRAN
cell and the
inter-RAT cell is
performed. In
load sharing
between an E-
UTRAN cell
and an inter-
RAT cell based
on load of the
inter-RAT cell,
the inter-RAT
cell must be a
UTRAN cell. If
MlbLoadInfoS-
witch and
UtranMlbSwitc
h are both set to
On, the UTRAN
cells with the
UMTS cell load
status parameter
set to Normal
CdmaMlbSwitc
h
(CdmaMlbSwit
ch), IntraFreqI-
dleMlbSwitch
(IntraFreqI-
dleMlbSwitch),
UtranIdleMlbS-
witch
(UtranIdleMlbS
witch),
MlbLoadInfoS-
witch
(MlbLoadInfoS-
witch),
InterFreq-
BlindMlbSwitc
h(InterFreq-
BlindMlbSwitc
h)
Unit:None
Actual Value
Range:Intra-
FreqMlbSwitch,
InterFreqMlbS-
witch,
UtranMlbSwitc
h,
GeranMlbSwitc
h,
CdmaMlbSwitc
h, IntraFreqI-
dleMlbSwitch,
UtranIdleMlbS-
witch,
MlbLoadInfoS-
witch,
InterFreq-
BlindMlbSwitc
h
Default
Value:IntraFreq
MlbSwitch:Off,
InterFreqMlbS
witch:Off,
UtranMlbSwitc
h:Off,
GeranMlbSwitc
h:Off,
CdmaMlbSwitc
h:Off,
IntraFreqIdleMl
bSwitch:Off,
UtranIdleMlbS
witch:Off,
MlbLoadInfoS
witch:Off,
InterFreqBlind
MlbSwitch:Off
performed if
InterRatMlb-
BlindHo is set to
OFF.
GUI Value
Range:Inter-
FreqMlbBlindH
o(InterFreqMlb-
BlindHo),
InterRatMlb-
BlindHo
(InterRatMlb-
BlindHo)
Unit:None
Actual Value
Range:Inter-
FreqMlbBlindH
o, InterRatMlb-
BlindHo
Default
Value:InterFreq
MlbBlindHo:Of
f,
InterRatMlbBli
ndHo:Off
number of
uplink-
synchronized
UEs is 20, and a
GUI value of 10
means that the
number of
uplink-
synchronized
UEs is 100.
However, if the
GUI values are
100 and 99, the
thresholds for
the numbers of
uplink-
synchronized
UEs are 1 and 2,
respectively.
GUI Value
Range:1~100
Unit:%
Actual Value
Range:1~100
Default Value:
15
handover to CapSwitch: If
GERAN this switch is
turned on,
CDMA2000
1xRTT supports
VoIP. If this
switch is turned
off, CDMA2000
1xRTT does not
support VoIP.
UtranPsHoSwit
ch: If this switch
is turned on,
UTRAN
supports PS
handovers. If
this switch is
turned off,
UTRAN does
not support PS
handovers.
GeranPsHoSwit
ch: If this switch
is turned on,
GERAN
supports PS
handovers. If
this switch is
turned off,
GERAN does
not support PS
handovers.
CdmaHrpdNon
OtpimisedHoS-
witch: If this
switch is turned
on, non-
optimized
handovers to
CDMA2000
HRPD are
enabled. If this
switch is turned
off, non-
optimized
handovers to
CDMA2000
HRPD are
disabled.
CdmaHrpdOpti
misedHoSwitch
: If this switch is
turned on,
optimized
handovers to
CDMA2000
HRPD are
enabled. If this
switch is turned
off, optimized
handovers to
CDMA2000
HRPD are
disabled.
GeranNaccSwit
ch: This switch
does not take
effect if
GeranCcoSwitc
h is disabled. If
this switch is
turned on,
GERAN
supports
network assisted
cell change
(NACC). If this
switch is turned
off, GERAN
does not support
NACC.
GeranCcoSwitc
h: If this switch
is turned on,
GERAN
supports cell
change order
(CCO). If this
switch is turned
off, GERAN
does not support
CCO.
UtranSrvccSwit
ch: If this switch
is turned on,
UTRAN
supports single
radio voice call
continuity
(SRVCC). If this
switch is turned
off, UTRAN
does not support
SRVCC.
GeranSrvccSwit
ch: If this switch
is turned on,
GERAN
supports
SRVCC. If this
switch is turned
off, GERAN
does not support
SRVCC.
Cdma1xRttSrvc
cSwitch: If this
switch is turned
on, CDMA2000
1xRTT supports
SRVCC. If this
switch is turned
off, CDMA2000
1xRTT does not
support
SRVCC.
UtranRedirectS-
witch: If this
switch is turned
on, redirection
to UTRAN is
enabled. If this
switch is turned
off, redirection
to UTRAN is
disabled.
GeranRedirectS
witch: If this
switch is turned
on, redirection
to GERAN is
enabled. If this
switch is turned
off, redirection
to GERAN is
disabled.
CdmaHrpdRedi
rectSwitch: If
this switch is
turned on,
redirection to
CDMA2000
HRPD is
enabled. If this
switch is turned
off, redirection
to CDMA2000
HRPD is
disabled.
Cdma1xRttRedi
rectSwitch: If
this switch is
turned on,
redirection to
CDMA2000
1xRTT is
enabled. If this
switch is turned
off, redirection
to CDMA2000
1xRTT is
disabled.
BlindHoSwitch:
If this switch is
turned on, blind
handovers for
CSFB are
enabled. If this
switch is turned
off, blind
handovers for
CSFB are
disabled.
LcsSrvccSwitch
: If this switch is
turned on, an
SRVCC
procedure is
triggered when a
UE receives a
CSFB
instruction
during a VoIP
service. If this
switch is turned
off, an SRVCC
procedure is not
triggered when a
UE receives a
CSFB
instruction
during a VoIP
service.
AutoGapSwitch
: If this switch is
turned on and
UEs support
automatic
measurement
gap
configurations
on the target
frequency, the
eNodeB does
not deliver gap
configurations
to UEs. If this
switch is turned
off, the eNodeB
delivers gap
configurations
to UEs during all
inter-frequency
and inter-RAT
measurements.
GUI Value
Range:Eutran-
VoipCapSwitch
(EutranVoipCap
Switch),
UtranVoipCapS
witch
(UtranVoipCap
Switch),
GeranVoipCapS
witch
(GeranVoipCap
Switch),
Cdma1xRttVoip
CapSwitch
(Cdma1xRttVoi
pCapSwitch),
UtranPsHoSwit
ch
(UtranPsHoSwit
ch),
GeranPsHoSwit
ch
(GeranPsHoSwi
tch),
CdmaHrpdNon
OtpimisedHoS-
witch
(CdmaHrpdNon
OtpimisedHoS-
witch),
CdmaHrpdOpti
misedHoSwitch
(CdmaHrpdOpti
misedHoSwitch
),
GeranNaccSwit
ch
(GeranNaccSwi
tch),
GeranCcoSwitc
h
(GeranCcoSwit
ch),
UtranSrvccSwit
ch
(UtranSrvccS-
witch),
GeranSrvccSwit
ch
(GeranSrvccS-
witch),
Cdma1xRttSrvc
cSwitch
(Cdma1xRttSrv
ccSwitch),
UtranRedirectS-
witch
(UtranRedirectS
witch),
GeranRedirectS
witch
(GeranRedirect
Switch),
CdmaHrpdRedi
rectSwitch
(CdmaHrpdRed
irectSwitch),
Cdma1xRttRedi
rectSwitch
(Cdma1xRttRed
irectSwitch),
BlindHoSwitch
(BlindHoSwitch
),
LcsSrvccSwitch
(LcsSrvccSwitc
h),
AutoGapSwitch
(AutoGapSwitc
h)
Unit:None
Actual Value
Range:Eutran-
VoipCapSwitch
,
UtranVoipCapS
witch,
GeranVoipCapS
witch,
Cdma1xRttVoip
CapSwitch,
UtranPsHoSwit
ch,
GeranPsHoSwit
ch,
CdmaHrpdNon
OtpimisedHoS-
witch,
CdmaHrpdOpti
misedHoSwitch
,
GeranNaccSwit
ch,
GeranCcoSwitc
h,
UtranSrvccSwit
ch,
GeranSrvccSwit
ch,
Cdma1xRttSrvc
cSwitch,
UtranRedirectS-
witch,
GeranRedirectS
witch,
CdmaHrpdRedi
rectSwitch,
Cdma1xRttRedi
rectSwitch,
BlindHoSwitch,
LcsSrvccSwitch
,
AutoGapSwitch
Default
Value:EutranVo
ipCapSwitch:O
n,
UtranVoipCapS
witch:Off,
GeranVoipCapS
witch:Off,
Cdma1xRttVoip
CapSwitch:Off,
UtranPsHoSwit
ch:Off,
GeranPsHoSwit
ch:Off,
CdmaHrpdNon
OtpimisedHoS
witch:Off,
CdmaHrpdOpti
misedHoSwitch
:Off,
GeranNaccSwit
ch:Off,
GeranCcoSwitc
h:Off,
UtranSrvccSwit
ch:Off,
GeranSrvccSwit
ch:Off,
Cdma1xRttSrvc
cSwitch:Off,
UtranRedirectS
witch:Off,
GeranRedirectS
NUMBER, a
related UE is
selected based
on the scenario
where the inter-
frequency MLB
is triggered the
number of UEs
in the serving
cell. The
parameter only
applies to blind
inter-frequency
MLB in this
version.
GUI Value
Range:0~50
Unit:%
Actual Value
Range:0~50
Default Value:2
Actual Value
Range:PRB_O
NLY,
UE_NUMBER_
ONLY,
PRB_OR_UE_
NUMBER
Default
Value:PRB_ON
LY(PrbMode)
GUI Value
Range:1~10000
Unit:None
Actual Value
Range:1~10000
Default Value:
100
Default
Value:ALLOW
ED
(ALLOWED)
Actual Value
Range:min5,
min10, min20,
min30, min60,
min120, min180
Default
Value:min10
(10)
RMV Unit:None
EUTRANINTE Actual Value
RNFREQ Range:0~17
Default
Value:None
9 Counters
10 Glossary
11 Reference Documents