3G MLB Feature Description

3G Mobility Load Balancing (MLB)

Feature Description

Organization Nokia SON

Version 1

Date Oct 02, 2015

Contents
1 Introduction
1.1 Eden-NET Release Information
1.2 Audience
1.3 Background
2 Functional Description
3 Technologies Supported
4 Operational modes
4.1 Open-loop mode
4.2 Closed Loop mode
5 3G Module Inputs 3G
5.1 (CM and PM Data)
6 3G Processing Steps
7 Running the Module
8 3G Configuration file parameters
9 Addendum/Future Additions
10 Acronyms
Document History

Version Date Author(s) Changes

1.0 10/1/2015 Nokia

Introduction
This module was developed to reduce congestion and balance load on 3G. There are two primary objectives of the module:

1. Reduce congestion related triggers on 3G related to downlink power, code congestion and hardware congestion.

1. Balance load between Inter-frequency co-sector neighbors.

The primary mechanism to accomplish these goals is the temporary reduction of CPICH power in the case of congestion and/or a temporary
change in Cell Individual Offset (CIO) relational handover parameter between co-sector cells if a large traffic imbalance is detected.
The functionality in #1 and #2 can be separately enabled/disabled. Through the use of the 3G MLB module, measurable congestion
improvements can be demonstrated.
Eden-NET Release Information
The version of module described in this document is part of the Eden-NET/Nokia release as of 9/30/2015.
Note that the inter-frequency load balancing is a new capability and has only been tested with Huawei RAN. The support for Ericsson and Nokia
RAN will be supported in an upcoming release.

Audience
This document is intended for the use of the following audience(s):

1. Operators using the Eden-NET 3G MLB module

a. This document provides a reference describing the module that may be reviewed by operators and other customers that plan to
use this tool.
b. Please note that the information contained in this document is confidential and proprietary to Nokia Networks
2. Nokia Networks Sales Team
3. Developers
a. This document provides the requirements that feed into the development of the module
b. Testers

Background
The Eden-NET 3G MLB module reduces congestion and balances co-sector loads.

Functional Description
The 3G MLB Module from Eden Net aims to solve two problem areas:

1. Downlink power related congestion, code congestion or hardware congestion through temporary reduction of CPICH of source cell and
co-sector cells.
2. Large traffic imbalances between co-sector cells.

The downlink CPICH power changes are done in a series of up to 7 small (user definable) step sizes. The amount of mitigation depends on
whether the congestion trigger used as the input is reduced to acceptable levels. Regardless of whether state 7 is reached in mitigation, there is
an overall timer (defaulted to 8 hours = 28,800 seconds) which upon expiry will set the CPICH back to the original value.
When large traffic imbalances are detected, the CIO offset values between co-sectors are only applied once in a timer interval (defaulted to 8
hours = 28,800 seconds). Upon expiry of the timer the CIO step change from a->b and the opposite CIO step change from b->a will be returned to
the original values.
The module will only commit to changes when run in closed loop.

Technologies Supported
This module supports congestion detection and mitigation for 3G cells and Inter-frequency co-sectors. The module does not support 2G or LTE
load balancing.

Operational modes

Open-loop mode
In open-loop mode, no changes are applied to the network. The module output consists of two reports that the operator can view.
One is the daily event log file. This file lists the cells for which congestion was detected at any point during the day.
The second is the 15 minute log file. This file lists the cells for that 15 minute period for which congestion was detected.
Closed Loop mode
It is recommended to run this module in closed loop.
The reports in this mode are the daily event log file and 15 minute log files.
In the daily event log file, the file will list all congestion, mitigation, pruning and data pause events.
In the 15 minute log file, this same information is available in addition to the original CPICH and current CPICH settings.

3G Module Inputs 3G
CM Data
This module uses neighbour lists, CPICH settings, Co-sector identifiation and CIO offsets from CM data.

PM Data
This module uses the following information as KPI inputs and traffic loss safeguards.

Nokia
RB Downgrade by Dyn Link Opt due to RL Power Congestion
RB Downgrade by PBS due to Spreading Code Congestion
RRC_Connection_Rejects
Voice Erlangs
HSDPA Erlangs

Ericsson
Congestion control triggered--High DL Power
HS downswitches due to congestion
Congestion due to Lack of DL Codes
Congestion due to Lack of DL Power
Congestion due to Lack of DL HW
Congestion due to Lack of UL HW
Voice Erlangs
HSDPA Erlangs

Huawei
RRC Connection Rejects for Congestion Reasons
Voice Erlangs
HSDPA Erlangs
Propagation Delay PRACH

3G Processing Steps

The 3G MLB algorithm applies mitigation steps (CPICH reduction) to those cells with unacceptable levels of congestion or in the case of
inter-frequency load balancing CIO offsets are changed between the heavily loaded co-sector and less loaded co-sector.
It is best described in diagrams on the following pages.

Intra-frequency load balancing via CPICH reductions (Nokia, Ericsson, Huawei)

Figure 1 Intra-frequency Load Balancing

Inter-frequency load balancing via CIO offset changes (Huawei)

Figure 2 Inter-frequency Load Balancing

Running the Module

The module is launched using the standard Eden-NET interface. Cells to be optimized are selected by the user. Eden-NET restricts the module to
making changes only to those cells selected by the user. Entire RNCs and multiple RNCs can also be selected.
Note co-sector cells must be chosen as part of the module target list. This is because CPICH adjustments must be applied to all co-sector cells in
the current release. If the co-sector cells are not part of the target list then closed loop pushes for those affected cells will not be executed.
This module works best when a large area is selected (Single RNC). This is because some markets do not have high congestion levels or the
congestion may be intermittent and due to a handful of cells.
The parameters available in the GUI are listed on the next page:
 1. Congestion Pen Size: This value is a safeguard that limits the # of cells that can be in the congestion pen at the same time. Note that
this parameter value applies to the entire OSS.

1. Max Hold Time: This value is in seconds. The default setting of 28,00 equates to 8 hours. When a cell enters mitigation for the first time
and thus enters the congestion time, the timer will start. At the end of the timer period, the cell CPICH is returned to the original setting.
*Note that the inter-frequency load balancing timer is separate and contained in the configuration file. Discussed in next section.

1. Prevent Load Balancing mitigation if neighbor list is unknown: This parameter is defaulted to true and ensures that the module will
not push CPICH or CIO changes for an interval if neighbor list CM information is temporary unavailable. The neighbor lists (all
intra-frequency neighbors + co-sited inter-frequency neighbors) must be known in order for the traffic loss safeguard to function properly
by ensuring no unacceptable traffic loss on neighboring cells. Note that this parameter should probably always remain true.

1. SON Operation Mode: Closed Loop must be selected to enact changes to the network. Open loop will only report congestion events but
will not take any action to resolve or mitigate them.

3G Configuration file parameters

The configuration file for MLB must be setup properly as the config file is the input for the triggering mechanism. This will be broken out into
different sections by RAN vendor.

NOKIA RAN
[congestion_triggers.congestion1.RB Downgrade by Dyn Link Opt due to RL Power Congestion]
threshold=5
[congestion_triggers.congestion2.RB Downgrade by PBS due to Spreading Code Congestion]
Threshold=5
[congestion_triggers.congestion3.RRC_Connection_Rejects]
threshold=15
[traffic_triggers.source_ve.Voice Erlangs]
decrease_threshold = 0.02
[traffic_triggers.source_de.HSDPA Erlangs]
decrease_threshold = 0.02
[traffic_triggers.neighbor_ve.Voice Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter
[traffic_triggers.neighbor_de.HSDPA Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter
[mitigation_states.0.cell]
PtxPrimaryCPICH = 0
[mitigation_states.1.cell]
PtxPrimaryCPICH = -0.5
[mitigation_states.2.cell]
PtxPrimaryCPICH = -1.0
[mitigation_states.3.cell]
PtxPrimaryCPICH = -1.5
[mitigation_states.4.cell]
PtxPrimaryCPICH = -2.0
[mitigation_states.5.cell]
PtxPrimaryCPICH = -2.5
[mitigation_states.6.cell]
PtxPrimaryCPICH = -3.0
[mitigation_states.7.cell]
PtxPrimaryCPICH = -3.5
[global]
congestion_monitor_interval=900
congestion_monitor_resolution=1
traffic_monitor_resolution=1
traffic_monitor_interval=900

1. [congestion_triggers.congestion1.RB Downgrade by Dyn Link Opt due to RL Power Congestion]

This trigger tends to track with RL Power Congestion. In markets where this counter does not trend downward after application of load balancing,
then this default value of 5 can be increased to large values.

1. [congestion_triggers.congestion2.RB Downgrade by PBS due to Spreading Code Congestion]

This trigger indicates when codes are exhausted for a carrier. It tends to track with congestion. In markets where this counter does not trend
downward after application of load balancing, then this default value of 5 can be increased to large values.

1. [congestion_triggers.congestion3.RRC_Connection_Rejects]

This trigger tends to track very well with the application of load balancing. The default value can be increased in markets where there is a very
large amount of congestion resulting RRC_Connecton_Rejects.
*Note additional counters may only be used as triggers after consultation with Nokia. Custom triggers that do not improve with load balancing
mitigation can cause performance problems.

1. [traffic_triggers.source_ve.Voice Erlangs]

decrease_threshold = 0.05

1. [traffic_triggers.source_de.HSDPA Erlangs]

decrease_threshold = 0.05

1. [traffic_triggers.neighbor_ve.Voice Erlangs]

decrease_threshold = 0.02
target = intra,cosite_inter

1. [traffic_triggers.neighbor_de.HSDPA Erlangs]

decrease_threshold = 0.02
target = intra,cosite_inter
The config file parameters in steps 4 through 7 are all related to the traffic loss safeguard of the load balancing module. If traffic from one iteration
to the next decreases more than the acceptable amount specified in parameters 4 through 7, then load balancing will revert the last change and
prevent any additional mitigation steps for the remainder of the timer period.
Config parameter 4 requires that there is no source cell voice traffic loss that is more than 5% from one measurement interval to the next.
Config parameter 5 requires that there is no source cell HSDPA traffic loss that is more than 5% from one measurement interval to the next.
Config parameter 6 requires that there is no aggregate neighbor cell voice traffic (all intra neighbors + co-sector inter-frequency neighbors) traffic
loss that is more than 2% from one measurement interval to the next.
Config parameter 7 requires that there is no aggregate neighbor cell HSDPA traffic (all intra neighbors + co-sector inter-frequency neighbors)
traffic loss that is more than 2% from one measurement interval to the next.

1. mitigation_states.0.cell
2. mitigation_states.1.cell
3. …..
4. mitigation_states.7.cell
These mitigation steps apply to CPICH change offsets as referenced to the original CPICH of the cell (and co-sectors) when entering mitigation.
Mitigation 0 will apply no change. Mitigation 1 will apply 0.5 dB change. Mitigation 7 will apply a cumulative change of 3.5 dB.

1. congestion_monitor_interval=900
2. congestion_monitor_resolution=1
3. traffic_monitor_resolution=1
4. traffic_monitor_interval=900

Interval should be set to 900 (seconds) for 15 minute KPI data. .

Resolution specifies kpi resolution - 1 is 15 minutes, 2 is hourly. Hourly KPIs are not recommended for use with load balancing.

ERICSSON RAN
[congestion_triggers.high_dl_power.Congestion control triggered--High DL Power]
threshold=0
[congestion_triggers.hs_downswitch.HS downswitches due to congestion]
threshold=0
[congestion_triggers.dl_codes.Congestion due to Lack of DL Codes]
threshold=0
[congestion_triggers.dl_power.Congestion due to Lack of DL Power]
threshold=0
[congestion_triggers.dl_hw.Congestion due to Lack of DL HW]
threshold=0
[congestion_triggers.ul_hw.Congestion due to Lack of UL HW]
threshold=0
[traffic_triggers.source_ve.Voice Erlangs]
decrease_threshold = 0.05
[traffic_triggers.source_de.HSDPA Erlangs]
decrease_threshold = 0.05
[traffic_triggers.neighbor_ve.Voice Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter
[traffic_triggers.neighbor_de.HSDPA Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter
[mitigation_states.0.cell]
primaryCpichPower = 0
[mitigation_states.1.cell]
primaryCpichPower = -0.5
[mitigation_states.2.cell]
primaryCpichPower = -1.0
[mitigation_states.3.cell]
primaryCpichPower = -1.5
[mitigation_states.4.cell]
primaryCpichPower = -2.0
[mitigation_states.5.cell]
primaryCpichPower = -2.5
[mitigation_states.6.cell]
primaryCpichPower = -3.0
[mitigation_states.7.cell]
primaryCpichPower = -3.5
[global]
congestion_monitor_interval=900
congestion_monitor_resolution=1
traffic_monitor_resolution=1
traffic_monitor_interval=900
The only significant difference between the Ericsson configuration file and the Nokia configuration file described in secton 8.1 are the input KPI
triggers.
Generally the Ericsson input KPI triggers track very well with load balancing mitigation and thus the values are set low > 0. If necessary, in a
market with high congestion levels these trigger thresholds can be increased.
HUAWEI RAN

[congestion_triggers.congestion3.RRC Connection Rejects for Congestion Reasons]

threshold=10
[traffic_triggers.source_ve.Voice Erlangs]
decrease_threshold = 0.05
[traffic_triggers.source_de.HSDPA Erlangs]
decrease_threshold = 0.05
[traffic_triggers.neighbor_ve.Voice Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter
[traffic_triggers.neighbor_de.HSDPA Erlangs]
decrease_threshold = 0.02
target = intra,cosite_inter

[mitigation_states.0.custom]
PCPICHPOWER = 0
module = loadbalance.oss.builder:get_changes
[mitigation_states.1.custom]
PCPICHPOWER = -5
module = loadbalance.oss.builder:get_changes
[mitigation_states.2.custom]
PCPICHPOWER = -10
module = loadbalance.oss.builder:get_changes
[mitigation_states.3.custom]
PCPICHPOWER = -15
module = loadbalance.oss.builder:get_changes
[mitigation_states.4.custom]
PCPICHPOWER = -20
module = loadbalance.oss.builder:get_changes
[mitigation_states.5.custom]
PCPICHPOWER = -25
module = loadbalance.oss.builder:get_changes
[mitigation_states.6.custom]
PCPICHPOWER = -30
module = loadbalance.oss.builder:get_changes
[mitigation_states.7.custom]
PCPICHPOWER = -35
module = loadbalance.oss.builder:get_changes
[global]
write_enabled=True
congestion_monitor_interval=900
congestion_monitor_resolution=1
traffic_monitor_resolution=1
traffic_monitor_interval=900
inter_freq_monitor_interval=900
inter_freq_monitor_resolution = 1
enable_intra_freq_load_balancing=Yes
enable_inter_freq_load_balancing=Yes
cio_interfreq=-2
min_erlang_inter_abs_trigger=10
min_erlang_inter_layer_delta_%=25
interfreq_traffic_footprint_enabled=Yes
footprint_bin_delta=.05
distant_starting_bin=6
maximum_hold_time_inter_freq_lb=28800
In addition to the obvious KPI trigger difference, the Huawei MLB configuration file differs significantly from Nokia and Ericsson because the
Huawei version currently has Interfrequency MLB functionality.

1. enable_intra_freq_load_balancing=Yes

This field enables intra-frequency load balancing

1. enable_inter_freq_load_balancing=Yes

This field enables inter-frequency load balancing

1.
 1. cio_interfreq=-2

This field denotes the magnitude of the CIO offset change. A -2 relational offset is applied to the heavily imbalanced cell towards the less loaded
co-sector cell and a polar opposite vaue of 2 is applied from less loaded co-sector cell towards the heavily loaded cell.

1. min_erlang_inter_abs_trigger=10

This field requires a minimum combined voice + data erlang traffic of 10 in order for the inter-frequency load balancing mechanism to kick in. See
min_erlang_inter_layer_delta_% = 25 which is also a requirement.

1. min_erlang_inter_layer_delta_% =25

This field requires the heavily loaded sector to be at least 25% more loaded (in terms of combined Erlangs) than the next loaded co-sector for the
load balancing mechanism to kick in. Both conditions in 4 and 5 must be met.

1. interfreq_traffic_footprint_enabled=Yes

This field enables the interfreq_traffic_footprint check. If set to Yes this mechanism will ensure that the coverage footprint of the heavily loaded
sector is not significantly greater than the sector that the traffic is steered towards.

1. footprint_bin_delta=.05

If interfreq_traffic_footprint_enabled is set to Yes, then this parameter is used to determine the acceptable amount of footprint imbalance (as
measured by the CDF of PRACH distance) from the heavily loaded sector to the less loaded sector.

1. distant_starting_bin=6

This is the PRACH bin that the cumulative CDF begins from (through bin 11) to determine footprint imbalance.

1. maximum_hold_time_inter_freq_lb=28800

This is the timer for the congestion pen for inter-frequency. The default is 8 hours.

Addendum/Future Additions
Note that as of 9/30/2015 various pilot trials are ongoing for this feature. Changes are possible as a result of the pilot results.
In the next release of MLB, inter-frequency co-sector load balancing will be added for Nokia and Ericsson.
In the next release of MLB, flexibility will be added for tandem CPICH step changes for co-band co-sector cells or all banded co-sector cells.

Acronyms
Acronym Meaning

MLB Mobility Load Balancing

OSS Operational Support Systems

GUI Graphical User Interface

CM Configuration Management

PM Performance Measurement

UMTS Universal Mobile Telecommunications System

LTE Long Term Evolution (4G)