Eden Net NRT MLB Guide

EdenNet 21
Near Real-time Mobility Load Balancing

Guide
DN1000039451
Issue: 1-0
Near Real-time Mobility Load Balancing Guide DN1000039451 1-0 Disclaimer
The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein.
This document is intended for use by Nokia' customers (“You”) only, and it may not be used except for the purposes defined in the agreement
between You and Nokia (“Agreement”) under which this document is distributed. No part of this document may be used, copied, reproduced,
modified or transmitted in any form or means without the prior written permission of Nokia. If you have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this document in any manner and You
are obliged to return it to Nokia and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility when using
it. Nokia welcome Your comments as part of the process of continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability, capacity,
fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document, and Nokia reserves
the right to change any such information and statements without notice. Nokia has made all reasonable efforts to ensure that the content of
this document is adequate and free of material errors and omissions, and Nokia will correct errors that You identify in this document. But,
Nokia' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia does not warrant that the use of
the software in the Product will be uninterrupted or error-free.
N O WA RRA NT Y O F AN Y KI ND , EI T HER EXPR ES S OR I M P L I E D , I N C L U D I N G B U T N O T L I M I T E D TO A N Y

WARR ANT Y OF AVA IL ABI LI T Y, AC CU RAC Y, R EL I A B I L IT Y, T I T L E , N O N - I N F R I N G E M E N T, M E R C H A N TA B I L I TY
OR F IT NE SS FO R A PA RT ICU LAR PU RPO SE, I S M A D E IN R E L AT I O N TO T H E C O N T E N T O F T H I S D O C U M E N T.
IN NO EVEN T WI L L NOK IA B E LI ABLE F OR AN Y DA M A G E S , I N C L U D I N G B U T N O T L I M I T E D TO S P E C I A L ,
D IRE CT, IN D IRECT, I NCI DE NTAL OR C ON SEQ UE N T IA L OR A N Y L O S S E S , S U C H A S B U T N O T L I M I T E D TO LO SS
OF PRO F IT, REVE NU E, B US IN ESS IN T ER RU PT I ON , B U S I NE S S O P P O RT U N I T Y O R D ATA T H AT M AY A R I S E
FRO M T HE USE O F TH IS DO CU M EN T O R T HE IN F OR M AT IO N I N I T, E V E N I N T H E C A S E O F E R R O R S I N O R
OM IS SI O NS FRO M T HI S DOC UM EN T O R IT S CO NT E N T.
This document is Nokia’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the
prior written consent of Nokia.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their
respective owners, and they are mentioned for identification purposes only.
Copyright © 2021 Nokia. All rights reserved.
Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the
safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this
document or documentation set.
Nokia is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you
as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the
recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia for
any additional information.
Near Real-time Mobility Load Balancing DN1000039451 1-0 Table of Contents
Guide
Contents
1 Summary of changes...................................................................................................................................... 5
2 Overview of nRT MLB.....................................................................................................................................6

2.1 Supported vendor and technology............................................................................................................6
2.2 nRT MLB dependencies and interactions.................................................................................................6
2.2.1 Dependencies................................................................................................................................... 6
2.2.2 Interactions........................................................................................................................................6
3 nRT MLB functional description and guidelines......................................................................................... 8

3.1 Operational modes of nRT MLB...............................................................................................................8
3.1.1 Open loop mode............................................................................................................................... 8
3.1.2 Closed loop mode.............................................................................................................................8
4 nRT MLB algorithm....................................................................................................................................... 10

4.1 Input data retrieval.................................................................................................................................. 10
4.2 Pre-filtering.............................................................................................................................................. 10
4.3 Congestion detection...............................................................................................................................11
4.4 Candidate neighbor cell selection...........................................................................................................11
4.5 Congestion mitigation..............................................................................................................................11
4.6 Continuous iterations...............................................................................................................................12
4.7 Automatic verification and rollback......................................................................................................... 12
4.8 Decongestion...........................................................................................................................................13
5 nRT MLB execution.......................................................................................................................................14

5.1 nRT MLB prerequisites........................................................................................................................... 14
5.1.1 License details................................................................................................................................ 14
5.1.2 Cell plan data..................................................................................................................................14
5.1.3 PM data and CM data....................................................................................................................15
5.2 Configuring and executing nRT MLB......................................................................................................15
6 nRT MLB configuration parameters............................................................................................................ 18

6.1 nRT MLB GUI parameters...................................................................................................................... 18
6.2 nRT MLB INI parameters........................................................................................................................20
6.2.1 Example of nRT MLB INI file......................................................................................................... 28
6.3 Importing INI parameters........................................................................................................................ 32
7 Viewing nRT MLB report.............................................................................................................................. 34

7.1 nRT MLB report...................................................................................................................................... 34
7.1.1 Hourly report................................................................................................................................... 35
7.1.1.1 Summary.................................................................................................................................35
7.1.1.2 HO KPIs..................................................................................................................................36
7.1.1.3 Parameters............................................................................................................................. 37
7.1.1.4 Mitigation.................................................................................................................................37
EdenNet 21 © 2021 Nokia 3

Near Real-time Mobility Load Balancing DN1000039451 1-0 Table of Contents
Guide
7.1.1.5 KPI_data_vendor.................................................................................................................... 38
7.1.2 Daily report......................................................................................................................................39
7.1.2.1 Summary.................................................................................................................................39
7.1.2.2 Mitigation.................................................................................................................................40
7.1.3 Rollback...........................................................................................................................................42
8 Viewing nRT MLB events............................................................................................................................. 44

8.1 nRT MLB events..................................................................................................................................... 45
9 Viewing SON change reports.......................................................................................................................46

9.1 Cell level records.................................................................................................................................... 46
10 Monitor nRT MLB........................................................................................................................................ 48

10.1 nRT MLB impact on the network..........................................................................................................48
10.2 nRT MLB RAN KPIs............................................................................................................................. 48
11 Push verification and rollback................................................................................................................... 49

Near Real-time Mobility Load Balancing DN1000039451 1-0 Summary of changes
Guide
1 Summary of changes
Release Change description
EdenNet 21 No change.
EdenNet 20 FP No change.
2011
2010
2009
2008
2007
EdenNet 20 This document provides information about the Near Real-time Mobility Load
Balancing (nRT MLB) module. The nRT MLB module optimizes the selected
scope of cells in near real-time.
Table 1: Summary of changes

Near Real-time Mobility Load Balancing DN1000039451 1-0 Overview of nRT MLB
Guide
2 Overview of nRT MLB

The Near Real-time Mobility Load Balancing (nRT MLB) module offers a measurement based solution
for mitigating congestion in the LTE cells. Yo can off-load the idle and connected mode User Equip-
ments (UEs) from the congested cell to the underutilized neighboring cells to mitigate congestion.
The nRT MLB module retrieves near real time Performance Management (PM) counter values every
one minute and evaluates the cells in a given scope. Based on the result, the algorithm makes
changes to the Configuration Management (CM) parameters to mitigate congestion. The CM parame-
ter changes are reverted when the cell is decongested. The nRT MLB module also monitors the KPIs
after the parameter changes are provisioned. If KPI degradation is detected in the network, then previ-
ous changes are rolled back by the nRT MLB module.
2.1 Supported vendor and technology

This chapter provides information on the supported vendor and technology of the nRT MLB module.
Table 2: Supported vendor and technology lists the supported vendor and technology of the nRT MLB
module.
Vendor Technology
Ericsson LTE
Table 2: Supported vendor and technology
2.2 nRT MLB dependencies and interactions

For information about dependencies and interactions of the nRT MLB module, see:
• Dependencies
• Interactions
2.2.1 Dependencies
The nRT MLB module has the following dependencies:
• For Ericsson, the near real time counters are retrieved from the eNB directly via Advanced MO
Scripting (AMOS) interface. Necessary license for AMOS should be installed.
• The nRT MLB module optimizes the inter-frequency mobility parameters for mitigating congestion.
It is mandatory to activate the SIB5 broadcast before running the nRT MLB module in closed loop.
• CM and PM integrations to AMOS must be performed in EdenNet.

Near Real-time Mobility Load Balancing DN1000039451 1-0 Overview of nRT MLB
Guide
2.2.2 Interactions
The nRT MLB module has the following interactions:
• The nRT MLB module conflicts with the parameter changes made by MRO and other DSON MLB
features. The LTE MRO module adjusts the inter-frequency offset parameters to secure the mobili-
ty between the cells. It might conflict with the nRT MLB module, which could tune mobility parame-
ters to push the traffic to offload a given cell at the expense of mobility performance.
• Load balancing features enabled in the eNB might be push the traffic to less loaded neighbor cells
with or without changing the offset values. Uunpredicted load triggers are caused if the nRT MLB
module runs when the load balancing feature is enabled in the eNB.
• If the coverage thresholds are optimized, customer layering strategy might be impacted.

Near Real-time Mobility Load Balancing DN1000039451 1-0 nRT MLB functional description and
Guide guidelines
3 nRT MLB functional description and guidelines

The nRT MLB module detects congested cells and mitigates congestion by offloading the UEs to un-
derutilized neighbors. This is done by optimizing inter-frequency mobility parameters. It supports opti-
mization of both idle and connected mode mobility parameters. The nRT MLB module supports traffic
offloading to both co-sector and non co-sector inter-frequency neighbor cells.
The traffic offloading is done by making adjustments to the:
• neighbor cell offset parameters used in the idle mode and connected mode.
• handover or measurement thresholds.
The nRT MLB module examines the load on the neighbor cells and attempts to distribute the load
among the target neighbor cells. It continuously measures the load on the top filtered neighbors and
adjusts the relevant parameters to allow UE offloading to these neighbor cells. The nRT MLB module
monitors the load on the neighbor cell and ensures that corrective actions do not cause the neighbor
cells themselves to become congested. If the loading consistently decreases over a set number of pe-
riods, the module returns all the parameters to the original operator defined values. It also checks the
performance of the source and neighbor cells after the mitigation. If there is a degradation, necessary
corrective action is triggered.
3.1 Operational modes of nRT MLB

The nRT MLB module supports the following operational modes:
• Open loop mode

• Closed loop mode
Note: The nRT MLB module operates in an iterative mode for both open loop and closed
loop modes.
3.1.1 Open loop mode

In the open loop mode, the nRT MLB module identifies the congested cells and generates a report
with necessary corrective actions. The changes are not applied to the network.
The module output consists of a report listing the congested cells, proposed mitigation, logs, KPIs, and
so on.
3.1.2 Closed loop mode

In the closed loop mode, the nRT MLB module pushes the algorithm recommended parameter
changes to the live network. After pushes are complete, the module waits for a pre-defined period to

Near Real-time Mobility Load Balancing DN1000039451 1-0 nRT MLB functional description and
Guide guidelines
assess the impact on monitoring metrics. If there are any critical performance degradations, the mod-
ule rolls back the changes made to the scope cells.

Near Real-time Mobility Load Balancing DN1000039451 1-0 nRT MLB algorithm
Guide
4 nRT MLB algorithm

This chapter describes the nRT MLB module algorithm.
The nRT MLB module detects the LTE cells that exceed the loading threshold triggers and attempts to
reduce the congestion by moving the idle and connected mode UEs on the congested cell to the un-
derutilized neighbor cells. The UEs are offloaded by optimizing both co-sector and non co-sector in-
ter-frequency neighbor cells.
The nRT MLB module algorithm is described in the following steps:
• Input data retrieval

• Pre-filtering
• Congestion detection
• Candidate neighbor cell selection
• Congestion mitigation
• Continuous iterations
• Automatic verification and rollback
• Decongestion
4.1 Input data retrieval

Once the nRT MLB module is triggered for a user defined scope, AMOS connection is automatically
established for all the cells in the scope. The required nRT PM counters are retrieved directly from the
network element via AMOS interface. The CM data is fetched from NAdC or from AMOS based on the
user defined module configurations (Use_AC_LITE_For_CM).
The nRT MLB module reads the following data for successful execution:
• Module configuration GUI and INI parameters

• Non nRT performance metrics
4.2 Pre-filtering
The cells and relations that meet the following pre-filtering criteria are considered for optimization:
• The cells that are not part of SON exclusion list.

• The cells that are not part of nRT MLB module exclusion list.
• The cells that are not part of other instances of the nRT MLB module. For example, when two in-
stances are triggered one after the other, and if cell A is part of instance_1, then cell A will not be a
valid target for instance_2 (only for closed loop).
• The cells that are part of the geofence list (if it is set for the user).

Guide
• The cells with mandatory cell level parameters missing (for example, Site or Antenna coordinates,
EARFCN, Technology, and Azimuth).
• The cells without any EUTRAN relations.
4.3 Congestion detection

The algorithm identifies suitable candidate cells for optimization as follows:
• Identifies the congested source cell based on the congestion_criteria INI parameter.
• For each congested source cell, the module detects the underutilized neighbor cells for offloading
the traffic.
4.4 Candidate neighbor cell selection

For each congested cell, the nRT MLB module ranks the inter-frequency neighbor cells based on
the Hand Over (HO) attempts and HO success rate KPIs aggregated over the period defined in the
KPI_HO_periods INI parameter.
The nRT MLB module selects the neighbor cells that meet the following criteria:
• The neighbor cells are within the selected scope.

• The neighbor cells must meet the user defined Non_congestion_criteria.
• The bidirectional relation exists between the congested cell and the neighbor cell.
• If the value of the Mode of Optimization parameter is set to IDLE, then all the inter-
frequency neighbors (source to target relation) whose success rate is greater than the
Minimum_HO_Success_Rate configuration parameter are considered as neighbor candidates.
• If the value of the Mode of Optimization parameter is set to IDLE AND CONNECTED or
CONNECTED, then all the inter-frequency neighbors (source to target relation and target to source
relation) whose success rate is greater than the Minimum_HO_Success_Rate configuration
parameter are considered as neighbor candidates.
• The neighbor cells with frequencies in the Target_EARFCN_list configuration parameter are
considered.
• Only co-sector inter-frequency neighbors are considered if the value of the module configuration
parameter Use_co-sector_inter_frequency_neighbors_only is set to True. If the value
of the Use_co-sector_inter_frequency_neighbors_only parameter is set to False, all
the inter-frequency neighbors are considered.
4.5 Congestion mitigation

After selecting the top neighbor cells of the congested source cell, the nRT MLB module mitigates the
congestion by adjusting the cell pair level offset values, A2 measurement thresholds, and layer priority
thresholds.

Guide
All the parameters are optimized within the user defined minimum and maximum limits.
4.6 Continuous iterations

The nRT MLB module runs in iterations for both open loop and closed loop modes.
Note: In the open loop mode, the previous iteration results are not saved, that is, for each it-
eration, the nRT MLB module considers the congested source cell as a new cell.
In the closed loop mode, to check if the mitigated source cell is still in congested, decongested, or per-
formance degraded state, the module verifies the following KPI criteria:
• congestion_criteria
• Non_congestion_criteria
• avr_policy
The module determines the state of the source cell (congested, decongested, or performance degrad-
ed) by checking the KPIs for the consecutive periods. The module also checks the neighbor cell con-
gestion after mitigation.
4.7 Automatic verification and rollback

This step verifies the KPI performance after the nRT MLB module changes are provisioned. If any
degradation in network performance is detected, then the previous changes are rolled back.
Note:
• For congestion mitigation, the AVR window for a cell starts with the latest parameter
push time.
• The AVR window is not considered if the push is due to decongestion, degradation, or
rollback.
• The cell is not evaluated for congestion or decongestion if it is in the AVR window.
• The cell must not be considered as neighbor for any other source cell, if it is in it's AVR
window.
• If a cell is out of the AVR window, then the latest parameter push time of that cell must
be considered for congestion evaluation.
• If at the end of the AVR window, the cell does not have No_of_samples_for_AVR
number of valid samples, then the performance degradation in that iteration is not
checked.
• If at the end of AVR window, the cell does not have valid samples, then the nRT MLB
module waits for valid samples until kpi_delay_periods interval. If the module does
not have samples until kpi_delay_period interval, then the changes for the cell are
reverted to the previous step.

Guide
4.8 Decongestion
• Decongestion is evaluated with the help of two parameters:
– Consecutive_intervals_of_non-
congestion_periods_for_reverting_to_previous_step
– Consecutive_De-Congestion_Triggers_for_reverting_to_original_value
• If the cell C1 becomes decongested for n (Consecutive_intervals_of_non-
congestion_periods_for_reverting_to_previous_step) consecutive KPI intervals,
then revert C1 cell level parameters, C1->T1 and T1->C1 relation level parameters to its previous
step value.
• If cell C1 becomes decongested for n (Consecutive_De-
Congestion_Triggers_for_reverting_to_original_value)
consecutive KPI periods (Consecutive_intervals_of_non-
congestion_periods_for_reverting_to_previous_step), then rollback C1 cell level
parameters, C1->T1 and T1->C1 relation level parameters to its original values.
• If T1 is not a neighbor for any other source cell, the cell level parameters for T1 will be rolled back
to the original values when C1 is rolled back.

Near Real-time Mobility Load Balancing DN1000039451 1-0 nRT MLB execution
Guide
5 nRT MLB execution

This chapter describes how to access the nRT MLB module, select the scope, configure GUI, and INI
parameters, and schedule the module execution.
5.1 nRT MLB prerequisites

To execute the nRT MLB module, the following prerequisites must be met:
• Google Chrome or Mozilla Firefox web browser must be installed on your computer.
• The nRT MLB module license must be activated. For more information, see License details.
• The nRT MLB module must be imported and integrated with the respective Element Management
System (EMS) or Network Management System (NMS).
• Cell plan data must be available.
• PM data and CM data must be available.
• Configuration files must be activated. For more information, see the Configuring a module section
in the EdenNet User and Administration Guide.
5.1.1 License details
Table 3: nRT MLB module license details lists the license you must install to access the nRT MLB
module.
Licensed feature Licensed feature component

LK item code LK item object name
component code name
ENSW0035CLK nRT MLB CLK 0000054044 nRT MLB
Table 3: nRT MLB module license details
5.1.2 Cell plan data

The nRT MLB module requires the following information from the cell plan for all cells under optimiza-
tion:
• Cell location, in terms of latitude and longitude in decimal degrees

• Cell azimuth, angle of the antenna main beam relative to a defined geo-grid reference
• Neighbor cell locations, in terms of latitude and longitude in decimal degrees
• Neighbor cell azimuths, angle of the antenna main beam relative to the same geo-grid reference
than above
• Site ID, the unique id for the site
• Cell DN, the distinguished name of the cell

Guide
• MCC, the mobile country code

• MNC, the mobile network code
5.1.3 PM data and CM data

The nRT MLB module uses the Performance Management (PM) counters as input and modifies the
Configuration Management (CM) parameters. For more information, see the following documents:
• EdenNet module specific Data for Ericsson
5.2 Configuring and executing nRT MLB

This section describes how to configure and execute the nRT MLB module. The nRT MLB module predicts state of congestion
at least an hour in advance and trigger algorithms to mitigate the congestion.
Prerequisites
• All the prerequisites mentioned in the nRT MLB prerequisites section must be met.
1. Log in to the EdenNet application by doing the following:

a) In the address field of your Internet browser, type the following URL (for 2 VM, 5 VM, and
Cross-OSS):
https://<EdenNet GUI_SERVERS IP>
where <EdenNet GUI_SERVERS IP> is the IP address of the GUI server.
The EdenNet login page appears.

b) In the Username field, type the username.
c) In the Password field, type the password.
d) Click Log In.
The EdenNet application opens displaying the SON Activity page.
2. Click the Configure tab.
The following module categories appear in the left pane:
• EdenNet modules: Lists the modules provided by Nokia.

• Adapted modules: Lists the modules developed by users.
• Helper modules: Lists the modules used for troubleshooting by Nokia support teams.
3. Click Adapted modules → NRT_MLB.
The Configure Targets page appears.
4. To select the LTE target cells for configuration, do one of the following:
• Based on the Topology Filter or Center Frequency Filter, select the target cells on the map.

Guide
Or
• Based on the Topology Filter or Center Frequency Filter, click the Select all Filtered Items
icon to select all the filtered items.
Or
• Based on the following options, select the existing clusters or create a new cluster:
• From selected cells

• Based on rules
For more information about creating a new cluster, see the Cell Clusters section in the
EdenNet User and Administration Guide.
Or
• Based on the cell ID search or selection tools from the map toolbar.
The target cells are selected on the map and are listed in the Selections pane.
Note: For more information about selecting cells, see the Selecting cells section in the
EdenNet User and Administration guide.
5. Click Next.
The Configure Parameters page appears.
6. In the Parameter Value column, define the values of the GUI configuration parameters. For the list
of GUI parameters, see nRT MLB GUI parameters.
Note: Click the Default Value icon to revert to the default GUI parameter value.
7. Click Next.
The Select Configuration File page appears.
8. In the Module Global Configuration category, select the required configuration file.
Note: You can select only one configuration file from each category.
9. Verify the configuration and click Next.
The Execution Type page appears.
10. To schedule the module execution, do one of the following:
• Activate Now: Select to activate the module immediately.

• Activate Later: Select to activate the module at a later time.

Guide
• Schedule Execution: Select to schedule the module for execution during a certain date and
time.
For more information, see the Configuring execution type section in EdenNet User and Administra-
tion Guide.
11. Click Next.
The Confirm Execution page appears.
12. Verify the configuration summary and click Finish.
Expected outcome
The nRT MLB module is configured and executed as per the defined schedule.
Note: You can monitor the nRT MLB module activities, status, and so on. For more
information, see Monitor nRT MLB.

Near Real-time Mobility Load Balancing DN1000039451 1-0 nRT MLB configuration parameters
Guide
6 nRT MLB configuration parameters

The configuration parameters required to execute the nRT MLB module are as follows:
• nRT MLB GUI parameters

• nRT MLB INI parameters
6.1 nRT MLB GUI parameters

Table 4: nRT MLB GUI parameters describes the GUI parameters.
Range (min, Default

Parameter name Description Step
max) value
Start hour of provi- Indicates the start time for freez- 0-23 hours N/A 22 hours
sioning freeze ing the provisioning of changes
to network when the module is
run in closed-loop. Changes will
not be provisioned after this time.
Ranges from 0 to 23 hours. At
this time module will revert all the
changes to network original val-
ues. Changes will not be reverted
to original value if Start hour
of provisioning freeze is
set equal to End hour of pro-
visioning freeze.
End hour of provi- Indicates the end time for freez- 0-23 hours N/A 8 hours
sioning freeze ing the provisioning of changes to
network when the module is run in
closed-loop. Changes will be provi-
sioned after this time. Ranges from
0 to 23 hours.
Module execution Indicates that if the module exe- 1-5 minutes N/A 1 minute
frequency cution frequency is set 1 minute,
then the module iterations will be
triggered for every 1 minute. Itera-
tion will be skipped if previous run
is still on-going.
Mode of optimiza- Indicates the mode of optimization. • Idle - the N/A Idle and
tion module opti- connected

Guide
Range (min, Default

max) value
mizes the idle

mode para-
meters.
• Connected -
the module
optimizes the
connected
mode para-
meters.
• Idle and con-
nected - the
module op-
timizes both
the idle mode
and the con-
nected mode
parameters.
SON Operation Indicates the mode of SON opera- • Open Loop N/A Open Loop
Mode tion. • Closed Loop
If the value is set to Open Loop,
the module runs in the open loop
mode. In the open loop mode, the
module cannot automatically push
the parameter changes to the net-
work. The user has to manually
provision the plans to push the
changes to the network.
If the value is set to Closed Loop,

the module runs in the closed loop
mode. In the closed loop mode,
the module pushes the changes
automatically to the network with-
out manual intervention.
Plan Name Tag Text that will be added to the Sequence which N/A N/A
names of all plans that will be gen- contains any com-
erated by this module. binations of:
If the target of the module is a • Uppercase

whole specific cluster (and name and lower-

Guide
Range (min, Default

max) value
of this cluster also matches re- case letters:

quirements specified in Range col- [A-Z, a-z]
umn), then the cluster name will al- • Numbers:
so be added to the plan name. [0-9]
• Underscore: _
Maximum length:
20 characters
Table 4: nRT MLB GUI parameters
6.2 nRT MLB INI parameters

Table 5: nRT MLB INI parameters describes the INI parameters.
Range
Default
Parameter name Description (min, Step
value
max)
[Global]
KPI_resolution Indicates the granularity to be used for 0 0 N/A

fetching KPIs. Resolution 0 indicates 1
min KPIs are used. This is an optional
parameter.
Use_co-sector_in- Indicates the neighbors to be selected • True True N/A

ter_frequency_neigh- for offloading. • False
bors_only
If the value of the Use_co-sector_ • Yes
inter_frequency_neighbors_ • No
only is set to True, only inter
frequency co-sector cells are
considered for mitigation.
Target_EARFCN_list Indicates that the neighbor cells with 0 to N/A 1

downlink EARFCN (Evolved Absolute 262143
Radio Frequency Channel Number)
defined by Target_EARFCN_list is
considered during mitigation. Multiple
EARFCNs is to be provided as comma
separated input.

Guide
Range
Default
value
max)
This is an optional parameter.
Consecutive_inter- Indicates consecutive intervals of non- 1 to 1440 5 1

vals_of_non-conges- congestion after which a decongestion
tion_periods_for_re- action is triggered. As part of decon-
verting_to_previous_ gestion action, the module will revert
step the parameter changes by 1 step.
Consecutive_De- Indicates the minimum continuous de- 1 to 10 3 1

Congestion_Trig- congestion actions taken after which
gers_for_reverting_ all changes are reverted to original val-
to_original_value ues.
Data_stabilization_ Indicates the delay for getting a com- 1 to 60 2 1

time_offset plete KPI data, allowing all the PM files minutes
being produced, fetched, and loaded
in the PM database.
KPI_delay_periods Indicates the number of KPI periods 1 to 60 15 1

to be scanned back for valid and com- minutes
plete data. The KPI values beyond this
period will not be considered for analy-
sis.
No_of_samples_for_ Indicates the minimum number of un- 1-1440 5 1

congestion_evalua- used KPI samples (not none) available
tion for analysis and mitigation. The KPIs
available after the previous push time
will only be considered for evaluation.
%_Congested_kpi_ Indicates that the cell is considered for 1 to 100 80 1

samples_for_mitiga- mitigation procedure, if the percent-
tion age of congested kpi samples in No_
of_samples_for_congestion_evalua-
tion exceeds the % Congested kpi
samples for mitigation parame-
ter value.

Guide
Range
Default
value
max)
KPI_HO_periods Indicates the number of KPI periods 1-168 24 hours 1

to be scanned back for valid and com- hours
plete data. The module picks the lat-
est available (not none) hourly KPI da-
ta from the configured interval.
Note: This parameter is ap-

plicable only for hourly ag-
gregation.
Minimum HO Suc- Indicates the minimum handover suc- 0 -100 95 1

cess Rate cess rate for considering a neighbor
for mitigation.
Neighbor_list_size Indicates the maximum number of in- Any posi- 5 N/A

ter-frequency neighbors to which the tive integer
congested cell is offloaded.
Max_push_failure_ Indicates the maximum number of 0-10 2 1

count times the push operation is allowed to
fail before rolling back the changes.
Performance_logging Indicates the performance statistics, • True No N/A

such as memory consumption and • False
time taken by the module.
• Yes
If the value is set to Yes, time taken for • No
each process as part of the algorithm
is logged in the module instance logs.
If the value is set to No, the perfor-

mance logging is not visible in the
module instance logs.
Note: This parameter is ap-

plicable for performance
monitoring.

Guide
Range
Default
value
max)
Generate_daily_re- The module generates daily reports, if • True Yes N/A

port the value is set to Yes. • False
This is an optional parameter. • Yes
• No
Generate_KPI_ The module generates KPI sheets in • True Yes N/A

sheets hourly report if the value is set to Yes. • False
This is an optional parameter. • Yes
• No
Use_AC_LITE_For_ Indicates if AC based or AMOS inte- • True No N/A

CM gration must be used for CM opera- • False
tions. • Yes
If the value is set to True or Yes, the • No
module will use AC based integration
for CM operations.
[AVR]
No_of_samples_for_ Indicates the sliding window which will 0 - 60 10 1

AVR decide on how many previous sam-
pling periods are considered for taking
a rollback decision. This window will
start from the latest parameter push.
%_degraded_sam- Indicates that out of all the sample 1 - 100 80 1

ples_for_rollback KPIs specified in the No_of_sam-
ples_for_
AVR, if the percentage of degraded

samples are greater than %_
degraded_samples_for_
rollback, then the cell is considered
for rollback.

Guide
Range
Default
value
max)
%_neighbours_de- If the percentage of neighbors degrad- 0 - 100 80 1

graded_to_rollback_ ed is more than the value specified,
cell_level_changes the module will take rollback action
similar to source cell degraded.
[Initial cell level threshold step]: Indicates the step increase or decrease for each cell level threshold
parameter when a new congestion is detected
Snon-Intrasearch Specifies the threshold when inter-fre- 0-30 step 5 1

quency and inter RAT measurements
are required.
ThreshServingLowP Specifies the threshold that the signal 0-30 step 5 1

strength of the serving cell must be be-
low for cell reselection towards a low-
er priority Inter-Frequency or Inter-RAT
frequency.
ThreshXLow The threshold used in reselection to- 0-30 step 5 1

wards frequency X priority from a high-
er priority frequency
ThreshXHigh The threshold used by the UE when 0-30 step 5 1

reselecting towards the higher priority
frequency X from the current serving
frequency
A1A2SearchThreshold The Reference Signal Received Pow- 0-30 step 5 1

er (RSRP) threshold value for events
A1Search and A2Search.
[Initial cell pair offset step]: Indicates the step increase or decrease for each relation level offset para-
meter when a new congestion is detected.
qOffset Indicates the allowed absolute range 0-30 step 2 1

of parameter { -24, -22, -20, -18, -16,
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16,
18, 20, 22, 24 }. The module pushes
the next value in the allowed absolute
range, if the calculated value with step
is not valid.

Guide
Range
Default
value
max)
CIO Indicates the allowed absolute range 0-30 step 2 1

of parameter { -24, -22, -20, -18, -16,
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16,
is not valid.
[cell level threshold optimization step]: Indicates the step increase or decrease as mentioned in the
algorithm description for each cell level threshold parameter when a cell continues to be congested.
Snon-Intrasearch Specifies the threshold when inter-fre- 0-30 step 2 1

are required.
ThreshServingLowP Specifies the threshold that the signal 0-30 step 2 1

frequency.
A1A2SearchThreshold The Reference Signal Received Pow- 0-30 step 2 1

[cell pair offset optimization step]: Indicates the step increase or decrease as mentioned in the algo-
rithm description for each relation level offset parameter when a cell continues to be congested.
qOffset Indicates the allowed absolute range 0-30 step 1 1

of parameter { -24, -22, -20, -18, -16,
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16,
is not valid.
CIO Indicates the allowed absolute range 0-30 step 1 1

of parameter { -24, -22, -20, -18, -16,
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16,

Guide
Range
Default
value
max)

is not valid.
[Relative offset]: Neighbor wise allowable limit
Max allowable rela- Indicates the maximum allowable 0-30 10 1

tive offset for cell lev- change in value relative to the original
el thresholds value.
Min allowable rela- Indicates the minimum allowable 0-30 10 1

tive offset for cell lev- change in value relative to the original
el thresholds value.
Max allowable rela- Indicates the maximum allowable 0-30 6 1

tive offset for cell pair change in value relative to the original
offsets value.
Min allowable relative Indicates the minimum allowable 0-30 6 1

offset for cell pair off- change in value relative to the original
sets value.
[Absolute Range]: Absolute range defines the value range of each parameter the module can
change. This should be set in line with operator strategy.
Snon-Intrasearch Specifies the threshold when inter-fre- 0-62 0-30 2

are required.
ThreshServingLowP Specifies the threshold that the signal 0-62 0-26 2

frequency.
ThreshXLow The threshold used in reselection to- 0-62 0-26 2

wards frequency X priority from a high-
er priority frequency
ThreshXHigh The threshold used by the UE when 0-62 0-34 2

re-selecting towards the higher priori-
ty frequency X from the current serving
frequency.

Guide
Range
Default
value
max)
A1A2SearchThreshold The Reference Signal Received Pow- -140 to -44 -120 to -90 1
qOffset Indicates the allowed absolute range -24 to 24 -10 to 10 • 1

of parameter { -24, -22, -20, -18, -16, • 2
-6 to +6
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16, (-24 to -6,
18, 20, 22, 24 }. The module pushes 6 to 24)
is not valid.
CIO Indicates the allowed absolute range -24 to 24 -10 to 10 • 1

of parameter { -24, -22, -20, -18, -16, • 2
-6 to +6
-14, -12, -10, -8, -6, -5, -4, -3, -2, -1,
0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16, (-24 to -6,
18, 20, 22, 24 }. The module pushes 6 to 24)
is not valid.
#Default Congestion Criteria and AVR settings
[Congestion_Triggers]: These triggers are considered as congestion triggers for congestion detec-
tion. You can define the triggers for congestion. This is a mandatory section.
Note: You must provide at least one trigger under this section.
[Congestion_Criteria]: This criteria checks if the scope cell is congested and the congested scope
cell is considered for the load balancing optimization. You can define your own criteria using Con-
gestion_Triggers. Multiple criteria under Congestion_Criteria are considered as simple
OR condition. The complex equations are not supported. Any complex equation must be divided and
provided as lower granular equations. This is a mandatory section.
For example, criteria = X AND (Y OR Z ) must be written as:
criteria_1 = X AND Y
criteria_2 = X AND Z
Use of '( )', '{}', '[]' symbols are not supported.

Guide
Range
Default
value
max)
Note: At least one single criteria using the trigger provided must be present in this section.
[Non_congestion_criteria]: To perform rollback action, this criteria checks if the cell or neighbor is
decongested or not. If this section is not provided, the module considers the cell that is not meeting
Congestion_Criteria as decongested. You can define your own criteria using Congestion_
Triggers. Multiple criteria under Decongestion_Criteria are considered as simple OR condi-
tion. The complex equations are not supported. Any complex equation must be divided and provided
as lower granular equations. This is an optional section.
For example, criteria = X AND (Y OR Z ) must be written as:
Use of '( )', '{}', '[]' not supported.
[AVR_Policy]: This criteria checks the KPIs provided to find the impact of changes made and to do
potential rollbacks. Multiple criteria under avr_policy are considered as simple OR condition. If the
section is not provided, the auto verification and rollback will not be performed. You can compare the
KPIs using operators such as '+', '-', '>', '<', '%'. The complex equations are not supported. Any com-
plex equation must be divided and provided as lower granular equations.
For example, criteria = X AND (Y OR Z) must be written as:
For example, S: KPI1= +5% AND S:KPI1 > 40,
if KPI1 = 50
The module performs the rollback to the previously configured CM value if a new KPI value is greater
than 55. The module will not perform a rollback if the new KPI is less than or equal to 40. Also, it is
possible to specify if the KPI is applicable for Source[S] or Neighbor[N] or both [SN].
This is an optional section.
Table 5: nRT MLB INI parameters
The configuration file is uploaded to the EdenNet application. For more information on uploading the
file, see Importing INI parameters.

Guide
6.2.1 Example of nRT MLB INI file
The following is an example of the nRT MLB module INI file:
# If mandatory parameter is not provided/ provided with wrong value in

ini, then ini import fails with validation error.
## Non-Mandatory parameters are indicated below with the comment.
overlapping scopes are not allowed.
[Global]
# Mandatory Parameter
Use_co-sector_inter_frequency_neighbors_only = Yes
#Mandatory Parameter
Consecutive_intervals_of_non-congestion_periods_for_reverting_to_
previous_step = 5
#Mandatory Parameter
Consecutive_De-Congestion_Triggers_for_reverting_to_original_value = 3
## Mandatory parameter
KPI_delay_periods = 15
## Non Mandatory parameter, If parameter is not provided in ini, module
uses default value 'No'
Performance_Logging = No
uses default value 'Yes'
Generate_daily_report = Yes
## Non Mandatory parameter
Target_EARFCN_list=1-5,6
uses default value 0
KPI_resolution = 0
Data_stabilization_time_offset = 1
No_of_samples_for_congestion_evaluation = 5
%_Congested_kpi_samples_for_mitigation = 80
KPI_HO_periods = 24
Minimum_HO_Success_Rate = 95
Neighbor_list_size = 5

Guide
Max_push_failure_count = 2
uses default value 'Yes'
Generate_KPI_sheets = Yes
uses default value 'No'
Use_AC_LITE_For_CM = No
[Avr]
# Non Mandatory section .If Avr section is not given module won't apply
Avr.
No_of_samples_for_AVR = 10
%_degraded_samples_for_rollback = 80
%_neighbours_degraded_to_rollback_cell_level_changes = 80
[Initial_cell_level_threshold_step]
# Mandatory section.
#Mandatory parameter
Snon-Intrasearch = 10
ThreshServingLowP = 10
ThreshXLow = 10
ThreshXHigh = 10
A1A2SearchThreshold = 10
[Initial_cell_pair_offset_step]
qOffset = 2
CIO =2
[Cell_level_threshold_optimisation_step]
Snon-Intrasearch = 2
ThreshServingLowP = 2
A1A2SearchThreshold = 2
[Cell_pair_offset_optimisation_step]
qOffset = 1

Guide
CIO = 1
[Relative_offset]
Max_allowable_relative_offset_for_cell_level_thresholds = 10
Min_allowable_relative_offset_for_cell_level_thresholds = 10
Max_allowable_relative_offset_for_cell_pair_offsets = 6
Min_allowable_relative_offset_for_cell_pair_offsets = 6
[Absolute_range]
Snon-Intrasearch = 0 to 30
ThreshServingLowP = 0 to 26
ThreshXLow = 0 to 26
ThreshXHigh = 0 to 34
A1A2SearchThreshold = -120 to -90
qOffset = -10 to 10
CIO = -10 to 10
## Supports [[vendor_oss.DEFAULT]] / [[vendor_oss.ERICSSON]]
[Vendor_oss.DEFAULT]
# Mandatory section
[[Congestion_triggers]]
# User defined KPI triggers. KPIs required for [Congestion_criteria],
[Non_congestion_criteria] should be defined as triggers under this
section.
#Atleast one should be defined
congestion_1 = %_DL_PRB_Util
congestion_2 = Avg_Lat_QC1
congestion_3 = Avg_Lat_All_QCI
congestion_4 = RRC_Conn_Stp_Fail_RAC
congestion_5 = ERAB_Fail_Resource
# Mandatory section
[[Congestion_criteria]]
# User defined KPI Criteria. More than 1 criteria can be added to each
section.By default different criteria(s) are combined as OR condition.
criteria_1 = congestion_1 > 80 AND congestion_2 > 30
criteria_2 = congestion_1 > 80 AND congestion_3 > 300
criteria_3 = congestion_4 > 5
criteria_4 = congestion_5 > 5
# Mandatory section
[[Non_congestion_criteria]]

Guide
criteria_1 = congestion_1 < 75 AND congestion_2 < 25
criteria_2 = congestion_2< 75 AND congestion_3 < 250
criteria_3 = congestion_4 < 4
criteria_4 = congestion_5 < 4
# Non Mandatory section
[[Avr_policy]]
# User should assign values in percentage followed by absolute values in
case of more than 1 criteria(seperated by 'AND')
N:%_B_PUSCH_SNR = +5% AND > 5
SN:eRAB_Drop_Rate = -5% AND > -0.5
S:eRAB_Voice_Drop_Rate = +5%
6.3 Importing INI parameters

In EdenNet, you can import and activate the configuration files. You can also edit, export, delete, activate, and deactivate the
configuration files.
Prerequisites
• Only users with Administrator privileges can modify the INI parameters.
• The INI file must be available. For the list of INI file parameters, see nRT MLB INI parameters.

Cross-OSS):

d) Click Log In.
2. Click Administration → Modules.
The following module categories appear in the left pane:
• EdenNet modules: Lists the modules provided by Nokia.

• Adapted modules: Lists the modules developed by users.

Guide
• Helper modules: Lists the modules used for troubleshooting by Nokia support teams.
3. Click Adapted modules → NRT_MLB.
4. Click Configure → Module Configuration.
The NRT_MLB Configuration Manager dialog box appears.
5. Click the Module Global Configuration category and do one of the following:
• Import And Activate: Click to import a file and activate it immediately.

• Import: Click to import a configuration file.
• Activate: Click to activate the selected file.
Note: Multiple configuration files can be activated.
Expected outcome
The nRT MLB configuration file is imported and activated.
Note: In the NRT_MLB Configuration Manager dialog box, you can do one of the following:
• Export: Click to export the selected file to your system.

• Delete: Click to delete the selected file from the list.
Note: Users with Administrator or SON Module Manager permission can

delete the configuration files. The configuration files are deleted if they are not
used by other modules.
• Deactivate - Click to deactivate an activated file.
Note: If a configuration file is not used by other modules listed in the Active
SON Modules or Module History area, you can deactivate the configuration
file.
• Set As Default - Click to set the selected file as the default configuration.
• Reset - Click to reset the edited parameter values in the selected INI file.
• Save - Click to save the new version of the configuration file after editing the parameter
values in the selected INI file.
• Save As - Click to save the configuration file with a different name.
For more information, see the Configuring a module section in the EdenNet User and Admin-
istration Guide.

Near Real-time Mobility Load Balancing DN1000039451 1-0 Viewing nRT MLB report
Guide
7 Viewing nRT MLB report

For every module instance, the nRT MLB module generates a report in an Excel file. You can view the report and take
appropriate actions, if required.

Cross-OSS):

d) Click Log In.
2. Click the Status tab.
The Status page appears.
3. In the Active SON Modules or Module History area, select the NRT_MLB module.
The nRT MLB module status appears in the Execution Status tab.
4. Click the Logs tab.
5. In the User Outputs option, click the username. For example, admin.
The Directory Listing For dialog box appears listing the module filename.
6. Click the NRT_MLB filename.
A list of Excel file appears.
7. Click the required Excel file.
Expected outcome
The Excel file is saved to your local system. You can open and view the report. For more information,
see Viewing nRT MLB report.

Guide
7.1 nRT MLB report

The nRT MLB module generates a report in an Excel file. Each worksheet in the Excel is a report. The
following are the reports:
• Hourly report
• Daily report
• Rollback
7.1.1 Hourly report

Table 6: Hourly report describes each report in the Excel file.
Worksheet name Description
Summary Provided the summary of module execution.
HO KPIs Indicates the handover related KPIs between the congested

source cell and the neighbor cell that is considered for mitigation.
Parameters Indicates the GUI and the INI parameter settings.
Mitigation Indicates the actions, such as increment and decrement of para-

meters value based on the cell state (congestion, decongestion,
or performance degradation). The parameter changes include cell
level and cell pair level changes based on the state of the cell.
Logs Indicates the logs related to the module execution.
KPI_data_vendor Indicates all the KPI data of the respective vendor except HO
KPIs.
Table 6: Hourly report
7.1.1.1 Summary
Table 7: Summary describes the columns present in the Summary sheet.
Column name Description
Time Indicates the time in the UTC format.
KPI start time Indicates the start time for fetching the KPIs.
KPI end time Indicates the end time for fetching the KPIs.
Cell name Indicates the name of the source cell.
Cell DN Indicates the DN of the source cell.
Vendor Indicates the vendor of the source cell.
Region Indicates the region of the source cell.

Guide
Action Indicates the type of action taken on the cell. It can be one of the
following actions:
• Cell congested - Mitigated

• AVR Check - Source degraded
• AVR Check - Majority neighbors degraded
• AVR Check - Neighbor degraded
• AVR Check - Neighbor congested
• Cell decongested - Revert to previous step
• Cell on Hold
• Cell decongested - Revert to originals
Remarks Provides additional information on the action taken.
Associated Source/Neighbors Indicates the details of source and neighbor cells.
Table 7: Summary
7.1.1.2 HO KPIs
Table 8: HO KPIs describes the columns present in the HO KPIs sheet.
Time Indicates the system time in the UTC format.
Congested cell Indicates the congested cell name.
Source cell Indicates the source cell that is congested.
Source DN Indicates the DN of a source cell that is congested.
Source vendor Indicates the vendor of source cell that is congested.
Source region Indicates the region of a source cell that is congested.
Source frequency Indicates the source frequency.
Neighbor cell Indicates the neighbor cell of a source cell that is congested.
Neighbor DN Indicates the neighbor DN of a source cell that is congested.
Neighbor vendor Indicates the vendor of a neighbor cell of a source cell that is con-
gested.

Guide
Neighbor region Indicates the region of neighbor cell of a source cell that is con-
gested.
Neighbor frequency Indicates the neighbor frequency.
HO attempts Indicates the handover attempts between the source and the
neighbor cell.
Success rate Indicates the handover success ratio between the source and the
neighbor cell.
KPI criteria met Indicates the neighbor cell selection criteria.
Table 8: HO KPIs
7.1.1.3 Parameters
Table 9: Parameters describes the columns present in the Parameters sheet.
Parameter Indicates the name of the parameter.
Value Indicates the value of the parameter.
Table 9: Parameters
7.1.1.4 Mitigation
Table 10: Mitigation describes the columns present in the Mitigation sheet.
Time Indicates the system time in UTC format.
Source cell Indicates the source cell name of the cell pair.
Source vendor Indicates the vendor to which the source cell belongs to.
Source region Indicates the region to which the source cell belongs to.
Neighbor cell Indicates the neighbor cell name of the cell pair.
Neighbor vendor Indicates the vendor to which the neighbor cell belongs to.
Neighbor region Indicates the region to which the neighbor cell belongs to.
Cell/Relation DN Indicates the DN of the MO to which the parameter belongs to.
Relation type Indicates the type of the relation:

Guide
• Inter
• Co-sector Inter Frequency
Parameter Indicates the name of the parameter.
Initial value Indicates the network original value of the parameter before the
module execution.
Previous value Indicates the old value of the parameter, that is, the value modified
by the module in the previous iteration.
Proposed value Indicates the proposed value for the parameter, that is, the value
proposed by the module in the current iteration.
Reason Indicates the reason for parameter change, for example:
• Source congested
• Source decongested - reverting to previous step
• Source performance degraded - reverting to previous step
• Neighbor performance degraded - reverting to previous step
• Neighbor congested - reverting to previous step
• Majority neighbors performance degraded - reverting to previ-
ous step
• Push failed for source - reverting to originals
• Push failed for neighbor - reverting to originals
• Rollback - source decongested
• Mitigation paused
Remarks Indicates the additional comments related to the parameter

change, for example:
• No changes made due to offset limits reached

• No changes made due to Parameter limit reached
Push status Indicates the status of plan push. It can be one of the following:
• Success
• Retry - Success
• Failed
• No push attempted
Table 10: Mitigation
7.1.1.5 KPI_data_vendor
Table 11: KPI_data_vendor describes the columns present in the KPI_data_vendor sheet.

Guide
KPI time Indicates the KPI time of the source cell.

1
KPI n Indicates the KPI value of the source cell.
Table 11: KPI_data_vendor
7.1.2 Daily report

Daily report is generated everyday.
Table 12: Daily report describes each report in the daily report Excel file.
Worksheet name Description
Summary Indicates the congestion prediction. Congestion is predicted based

on KPIs. It reflects the current state and predicted state of the
cells.
Note: This report is generated if value of Enable Pre-

dictive MLB GUI parameter is set to Yes.
Mitigation Indicates the parameter changes. The parameter changes include

the cell level and the cell pair level changes based on the status of
the cell.
Table 12: Daily report
7.1.2.1 Summary
Table 13: Summary describes the columns present in the Summary sheet.
Time Indicates the time in the UTC format.
Cell type Indicates if the cell is a source (congested cell) or

neighbor cell.
1
Where n is the KPI.

Guide
Cell DN Indicates the DN of the source cell.
Action Indicates the type of action taken on the cell. It

can be one of the following actions:
• Cell congested - Mitigated

• AVR Check - Source degraded
• AVR Check - Majority neighbors degraded
• AVR Check - Neighbor degraded
• AVR Check - Neighbor congested
• Cell decongested - Revert to previous step
• Cell on Hold
• Cell decongested - Revert to originals
Remarks Provides additional information on the action tak-

en.
Associated Source/Neighbors Indicates the details of source and neighbor cells.
Table 13: Summary
7.1.2.2 Mitigation
Table 14: Mitigation describes the columns present in the Mitigation sheet.
Source cell Indicates the source cell name of the cell pair.
Source vendor Indicates the vendor to which the source cell belongs to.
Source region Indicates the region to which the source cell belongs to.
Neighbor cell Indicates the neighbor cell name of the cell pair.
Neighbor vendor Indicates the vendor to which the neighbor cell belongs to.
Neighbor region Indicates the region to which the neighbor cell belongs to.
Cell/Relation DN Indicates the DN of the MO to which the parameter belongs to.

Guide
Relation type Indicates the type of the relation type between the source cell and
the neighbor cell. The relation type can be:
• Inter
Parameter Indicates the name of the parameter
Initial value Indicates the network initial value of the parameter before the
module execution.
Previous value Indicates the old value of the parameter, that is, the value modified
by the module in the previous iteration.
Proposed value Indicates the proposed value for the parameter, that is, the value
proposed by the module in the current iteration.
Reason Shows the reason for parameter change, for example:
• Source congested
• Source decongested - reverting to previous step
• Source performance degraded - reverting to previous step
• Neighbor performance degraded - reverting to previous step
• Neighbor congested - reverting to previous step
• Majority neighbors performance degraded - reverting to previ-
ous step
• Push failed for source - reverting to originals
• Push failed for neighbor - reverting to originals
• Rollback - source decongested
• Mitigation paused
Remarks Shows the additional comments related to the parameter change,

for example:
• No changes made due to offset limits reached

• No changes made due to Parameter limit reached
• Success
• Retry - Success
• Failed

Guide
Table 14: Mitigation
7.1.3 Rollback
The rollback report is generated only after manually stopping the module execution.
Table 15: Rollback describes the columns present in the Rollback sheet.
Source cell Indicates the source cell that is congested.
Source vendor Indicates the vendor of source cell that is congested.
Source region Indicates the region of a source cell that is congested.
Neighbor cell Indicates the neighbor cell of a source cell that is congested.
Neighbor vendor Indicates the vendor of a neighbor cell of a source cell that is con-
gested.
Neighbor region Indicates the region of neighbor cell of a source cell that is con-
gested.
Cell/Relation DN Indicates the distinguished name of the cell or relation for which
the parameter is rolled back.
Relation type Indicates the relation type between the source cell and the neigh-
bor cell.
• Inter
Parameter Indicates the parameter name for the rollback.
Previous value Indicates the parameter value that is proposed during the last iter-
ation.
Initial value Indicates the network original value of the parameter.
Proposed value Indicates the new value of the parameter.
Remarks Indicates additional comments. For example,
• No rollback required because network value is already at the

original value
• Changing Qoffset value
• Success

Guide
• Retry - Success
• Failed
Table 15: Rollback

Near Real-time Mobility Load Balancing DN1000039451 1-0 Viewing nRT MLB events
Guide
8 Viewing nRT MLB events

In addition to the generic events that the EdenNet framework generates (for example, module started, module idling, and
module finished), you can view events that are specific to the nRT MLB module.

Cross-OSS):

d) Click Log In.
2. Click the Events tab.
A list of filters appears in the left pane.
3. From the Module/Service drop-down list, select the NRT_MLB module instance.
You can view the event logs using the following filters:
• Name: Indicates the event name.

• Category: Indicates the category of the event.
• Level: Indicates the level of the event.
• Source Type: Indicates from where the event originated.
• Target Type: Indicates to where the event is targeted.
• Target: Indicates the target of the event (cell name can be selected).
Note: The common event levels are information and warning. By default, the warning
and error filters are selected. To view all levels of events, remove the warning and error
filters.
4. In the Time Range area, set the required time range.
5. Optional: In the Saved Filters field, enter a name for the event filter and save it using the Save As
New Filter option.
6. Click Filter.

Near Real-time Mobility Load Balancing DN1000039451 1-0 Viewing nRT MLB events
Guide
Expected outcome
The events are listed based on the selected filter. For more information, see Viewing nRT MLB events.
8.1 nRT MLB events

Table 16: nRT MLB module events describes the nRT MLB events.
Name Level Description
Provisioning failed error Indicates that the provisioning has failed for the given cell
changes made by the module.
Table 16: nRT MLB module events

Near Real-time Mobility Load Balancing DN1000039451 1-0 Viewing SON change reports
Guide
9 Viewing SON change reports

You can view the changes made by the nRT MLB module to the managed objects.
Prerequisites
All the prerequisites mentioned in the nRT MLB prerequisites section must be met.

Cross-OSS):

d) Click Log In.
2. Click SON Modules → Reports.
The Network Analysis page is displayed.
3. In the left pane, click Modules, select NRT_MLB, and click Apply.
Expected outcome
The SON changes for nRT MLB are displayed in a tabular format.
9.1 Cell level records

Table 17: Cell level records reports the records at cell level. The cell level records can be viewed from
the Reports tab of the EdenNet GUI. For more information, see the View Reports section in the Eden-
Net User and Administration Guide.
Scenario Description
Congestion mitigation Indicates that congestion is mitigated for cell <source cell> and offloaded
to neighbor <neighbor cell>.
Example: Congestion mitigated for cell DLA33773A31 and offloaded to

neighbor LLA33773A11.

Near Real-time Mobility Load Balancing DN1000039451 1-0 Viewing SON change reports
Guide
Scenario Description
Neighbor congested Indicates that the neighbor cell <neighbor cell> is congested after mitigat-
ing as part of the source cell <source cell>.
Example: Neighbor cell LLA33773A11 is congested after mitigating as part

of source cell DLA33773A31.
Cell decongested Indicates that source cell <source cell> is decongested after mitigating to
neighbor <neighbor cell>.
Example: Source cell DLA33773A31 is decongested after mitigating to

neighbor LLA33773A11.
Source cell performance Indicates that the source cell <source cell> performance is degraded after
degradation mitigating to neighbor <neighbor cell>.
Example: Source cell DLA33773A31 performance is degraded after miti-

gating to neighbor LLA33773A11
Neighbor performance Indicates that the neighbor cell <neighbor cell> performance is degraded
degraded due to mitigating as part of the source cell <source cell>.
Example: Neighbor cell LLA33773A11 performance is degraded because

of mitigating as part of source cell DLA33773A31.
Rollback - module Indicates that the changes made as part of mitigation are rolled back to
stopped network original values when the module execution is stopped.
Rollback – source de- Indicates that the changes are rolled back to its network original values
congested when the source cell is consecutively non-congested.
Rollback failed, retrying Indicates that rollback is retried if it failed in the previous iteration.
Table 17: Cell level records

Near Real-time Mobility Load Balancing DN1000039451 1-0 Monitor nRT MLB
Guide
10 Monitor nRT MLB

You can monitor:
• SON activities - The SON Activity page enables you to view and monitor SON activities. For more
information, see the View and monitor SON activities section in the EdenNet User and Administra-
tion Guide.
• Status - The Status page enables you to view the status of SON modules. For more information,
see the View status of SON modules section in the EdenNet User and Administration Guide.
• Events - The Events page enables you to view SON events. For more information, see the Moni-
tor SON events section in the EdenNet User and Administration Guide.
10.1 nRT MLB impact on the network

For each vendor, the managed objects (created, deleted, or modified in a network) are listed in the Ac-
tions column of the CM objects or parameters section in the following documents:
• EdenNet Module Specific Data for Ericsson
10.2 nRT MLB RAN KPIs

For each vendor, the RAN KPIs section of the following document lists the RAN KPIs :
• EdenNet Module Specific Data for Ericsson

Near Real-time Mobility Load Balancing DN1000039451 1-0 Push verification and rollback
Guide
11 Push verification and rollback

Push Verification
The nRT MLB module immediately verifies the changes after they are pushed to the network. If the
push fails, the module retries the failed pushes based on the Max_push_failure_count parameter.
• If Max_push_failure_count = 0, the module does not retry the failed pushes. However, the
nRT MLB module validates if the push is successful or not. The push status is updated in the
Mitigation sheet.
• If Max_push_failure_count > 0, the module retries the failed pushes for the mentioned
number of counts. The final push status is updated in the Mitigation sheet.
Also, a critical event is raised in case of push failure.
Rollback
The nRT MLB module automatically rolls back a cell to its original network value in the following sce-
narios:
• When a module instance is stopped.

• When the cell is out of congestion, the cell is rolled back to its original network value
either directly or gradually (in steps) based on the value of the Consecutive_De-
Congestion_Triggers_for_reverting_to_original_value parameter.
• When the push fails continuously for Max_Push_Failure_Count number of times, the module
attempts to rollback the changes based on which parameter push has failed. If a source side
parameter push has failed, then the module attempts to rollback all changes related to the
mitigated source cell. If a neighbor side parameter push has failed, the module attempts to revert
the corresponding source to target and target to source offset changes for that neighbor.
• If the rollback to the original network value fails for a cell, the module reattempts the rollback the
changes based on the Max_Push_Failure_Count parameter. A detailed report of the failed
rollback is generated.
If there is a need for manual rollback of offset parameters and handover thresholds provisioned by
nRT MLB, the Rollback tab provides the capability to revert the network elements to a specific date
and time of a previous network state of operation. For more information, see the Applying rollbackAp-
plying rollback section in the EdenNet User and Administration Guide.

Eden Net NRT MLB Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eden Net NRT MLB Guide

Uploaded by

Copyright:

Available Formats

EdenNet 21

Near Real-time Mobility Load Balancing

N O WA RRA NT Y O F AN Y KI ND , EI T HER EXPR ES S OR I M P L I E D , I N C L U D I N G B U T N O T L I M I T E D TO A N Y

Copyright © 2021 Nokia. All rights reserved.

Important Notice on Product Safety

2 Overview of nRT MLB.....................................................................................................................................6

3 nRT MLB functional description and guidelines......................................................................................... 8

4 nRT MLB algorithm....................................................................................................................................... 10

5 nRT MLB execution.......................................................................................................................................14

6 nRT MLB configuration parameters............................................................................................................ 18

7 Viewing nRT MLB report.............................................................................................................................. 34

EdenNet 21 © 2021 Nokia 3

8 Viewing nRT MLB events............................................................................................................................. 44

9 Viewing SON change reports.......................................................................................................................46

10 Monitor nRT MLB........................................................................................................................................ 48

11 Push verification and rollback................................................................................................................... 49

EdenNet 21 © 2021 Nokia 4

Release Change description

Table 1: Summary of changes

EdenNet 21 © 2021 Nokia 5

2 Overview of nRT MLB

2.1 Supported vendor and technology

Table 2: Supported vendor and technology

2.2 nRT MLB dependencies and interactions

EdenNet 21 © 2021 Nokia 6

EdenNet 21 © 2021 Nokia 7

3 nRT MLB functional description and guidelines

The traffic offloading is done by making adjustments to the:

3.1 Operational modes of nRT MLB

• Open loop mode

3.1.1 Open loop mode

3.1.2 Closed loop mode

EdenNet 21 © 2021 Nokia 8

EdenNet 21 © 2021 Nokia 9

4 nRT MLB algorithm

The nRT MLB module algorithm is described in the following steps:

• Input data retrieval

4.1 Input data retrieval

• Module configuration GUI and INI parameters

• The cells that are not part of SON exclusion list.

EdenNet 21 © 2021 Nokia 10

4.3 Congestion detection

4.4 Candidate neighbor cell selection

• The neighbor cells are within the selected scope.

4.5 Congestion mitigation

EdenNet 21 © 2021 Nokia 11

4.6 Continuous iterations

4.7 Automatic verification and rollback

EdenNet 21 © 2021 Nokia 12

EdenNet 21 © 2021 Nokia 13

5 nRT MLB execution

5.1 nRT MLB prerequisites

5.1.1 License details

Licensed feature Licensed feature component

ENSW0035CLK nRT MLB CLK 0000054044 nRT MLB

Table 3: nRT MLB module license details

5.1.2 Cell plan data

• Cell location, in terms of latitude and longitude in decimal degrees

EdenNet 21 © 2021 Nokia 14

• MCC, the mobile country code

5.1.3 PM data and CM data

• EdenNet module specific Data for Ericsson

5.2 Configuring and executing nRT MLB