Eden Net Lte Anr Guide

EdenNet 21
LTE Automatic Neighbor Relations Guide

DN09238435
Issue: 1-0
LTE Automatic Neighbor Relations Guide DN09238435 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.
LTE Automatic Neighbor Relations Guide DN09238435 1-0 Table of Contents
Contents
1 Summary of changes...................................................................................................................................... 7
2 Overview of LTE ANR................................................................................................................................... 15

2.1 Overview of ANR Blacklisting and Cleanup LTE module....................................................................... 15
2.1.1 ANR Blacklisting and Cleanup LTE dependencies and interactions.............................................. 17
2.1.1.1 Dependencies......................................................................................................................... 17
2.1.1.2 Interactions............................................................................................................................. 17
2.2 Overview of LTE ANR Frequency Rules module................................................................................... 17
2.2.1 LTE ANR Frequency Rules dependencies and interactions.......................................................... 19
2.2.1.1 Dependencies......................................................................................................................... 19
2.2.1.2 Interactions............................................................................................................................. 19
2.2.2 LMS configuration file template for LTE ANR Frequency Rules module........................................19
2.3 Overview of ANR-4G IRAT module........................................................................................................ 24
2.3.1 ANR-4G IRAT dependencies and interactions............................................................................... 25
2.3.1.1 Dependencies......................................................................................................................... 25
2.3.1.2 Interactions............................................................................................................................. 25
2.3.2 LMS configuration........................................................................................................................... 25
2.3.2.1 Example for LMS configuration file........................................................................................ 26
3 LTE ANR functional description and guidelines........................................................................................30

3.1 ANR Blacklisting and Cleanup LTE functional description and guidelines............................................. 30
3.2 LTE ANR Frequency Rules functional description and guidelines......................................................... 31
3.3 ANR-4G IRAT functional description and guidelines.............................................................................. 32
3.4 Operational modes.................................................................................................................................. 32
3.4.1 Open loop mode............................................................................................................................. 32
3.4.2 Closed loop mode...........................................................................................................................33
4 LTE ANR algorithms......................................................................................................................................34

4.1 ANR Blacklisting and Cleanup LTE algorithm........................................................................................ 34
4.1.1 Execution flow of ANR Blacklisting and Cleanup LTE module.......................................................34
4.1.2 Blacklisting based on handover......................................................................................................35
4.1.3 Blacklisting based on tier and distance..........................................................................................37
4.1.4 Blacklisting based on PRACH non-reachable neighbors............................................................... 37
4.1.5 Unblacklisting.................................................................................................................................. 38
4.1.6 Cleanup based on handover.......................................................................................................... 38
4.1.7 File Based Blacklisting, Unblacklisting and Clean-up.....................................................................39
4.1.8 Cross OSS...................................................................................................................................... 40
4.1.8.1 Cross OSS support for ANR Blacklisting and Cleanup LTE (with NAdC).............................. 40
4.1.8.2 Cross OSS support for ANR Blacklisting and Cleanup LTE (without NAdC)......................... 40
4.2 LTE ANR Frequency Rules algorithm.....................................................................................................40
4.2.1 Frequency rule creation through user distance input..................................................................... 41
4.2.2 Frequency rule creation or deletion through user CSV input......................................................... 41
4.2.3 Frequency rule deletion through user distance input and LMS......................................................42
EdenNet 21 © 2021 Nokia 3

4.2.4 Frequency rule update through LMS..............................................................................................42

4.2.5 Frequency rule creation based on instance ID.............................................................................. 43
4.2.6 Blacklist and whitelist frequencies through user CSV input........................................................... 44
4.2.7 LMS support for LTE ANR Frequency Rules................................................................................. 44
4.3 ANR-4G IRAT algorithm..........................................................................................................................45
4.3.1 Tier counting and geo-scoring........................................................................................................ 46
4.3.2 LMS configuration........................................................................................................................... 46
4.3.3 Cross OSS...................................................................................................................................... 47
4.3.3.1 Cross OSS support for ANR 4G IRAT (with NAdC).............................................................. 47
4.3.3.2 Cross OSS support for ANR 4G IRAT (without NAdC)..........................................................47
4.3.4 Neighbor trimming...........................................................................................................................48
4.3.5 Whitelisting and blacklisting............................................................................................................48
4.3.6 Neighbor additions.......................................................................................................................... 49
4.3.7 Neighbor replacements...................................................................................................................51
4.3.8 KPI reliability................................................................................................................................... 52
4.3.9 Configuring relation DN ID for Ericsson (4G).................................................................................53
5 LTE ANR execution....................................................................................................................................... 56

5.1 Prerequisites............................................................................................................................................56
5.1.1 ANR Blacklisting and Cleanup LTE prerequisites.......................................................................... 56
5.1.1.1 License details........................................................................................................................56
5.1.1.2 PM data and CM data............................................................................................................57
5.1.2 LTE ANR Frequency Rules prerequisites.......................................................................................57
5.1.2.1 License details........................................................................................................................57
5.1.3 ANR-4G IRAT module prerequisites...............................................................................................58
5.1.3.1 License details........................................................................................................................58
5.2 Configuring and executing LTE ANR modules....................................................................................... 59
6 LTE ANR configuration parameters.............................................................................................................62

6.1 LTE ANR GUI parameters...................................................................................................................... 62
6.1.1 LTE ANR Frequency Rules GUI parameters................................................................................. 62
6.1.1.1 ANR Blacklisting and Cleanup LTE GUI parameters............................................................. 65
6.1.1.2 Frequency object creation file................................................................................................ 73
6.1.1.3 Frequency object deletion file................................................................................................ 73
6.1.1.4 Whitelist and blacklist target frequencies file......................................................................... 74
6.1.2 ANR-4G IRAT GUI parameters...................................................................................................... 74
6.2 LTE ANR INI parameters........................................................................................................................ 76
6.2.1 Common INI parameters................................................................................................................ 76
6.2.2 ANR Blacklisting and Cleanup LTE INI parameters....................................................................... 77
6.2.2.1 Example of ANR Blacklisting and Cleanup LTE configuration file......................................... 80
6.2.3 ANR 4G IRAT INI parameters........................................................................................................ 80
6.2.3.1 Example of ANR-4G IRAT configuration file.......................................................................... 89
6.3 Configuring INI parameters.....................................................................................................................91

7 Viewing LTE ANR targets............................................................................................................................. 93
8 Viewing LTE ANR reports.............................................................................................................................94

8.1 LTE ANR reports.....................................................................................................................................95
8.1.1 ANR Blacklisting and Cleanup LTE module reports.......................................................................95
8.1.1.1 Output report naming conventions......................................................................................... 96
8.1.1.2 Tier count................................................................................................................................97
8.1.1.3 Blacklisting.............................................................................................................................. 98
8.1.1.4 Cell Level Summary............................................................................................................... 99
8.1.1.5 Detected relations.................................................................................................................100
8.1.1.6 HO report..............................................................................................................................101
8.1.1.7 Logs...................................................................................................................................... 102
8.1.1.8 Parameters........................................................................................................................... 103
8.1.1.9 Reasons for neighbor addition............................................................................................. 103
8.1.1.10 Reasons for neighbor removal...........................................................................................103
8.1.1.11 IRAT Reuse Conflicts......................................................................................................... 104
8.1.1.12 UnBlacklisting..................................................................................................................... 104
8.1.1.13 Changes..............................................................................................................................105
8.1.1.14 Provisioning Details............................................................................................................ 105
8.1.1.15 Detected Neighbor Removal.............................................................................................. 106
8.1.1.16 Removed X2 links.............................................................................................................. 107
8.1.2 LTE ANR Frequency Rules module reports................................................................................. 107
8.1.2.1 Parameters........................................................................................................................... 108
8.1.2.2 Changes................................................................................................................................108
8.1.2.3 Logs...................................................................................................................................... 109
8.1.3 ANR-4G IRAT module reports......................................................................................................109
8.1.3.1 Output report naming conventions....................................................................................... 111
8.1.3.2 Tier count..............................................................................................................................111
8.1.3.3 Parameters........................................................................................................................... 112
8.1.3.4 IRAT Neighbor Performance................................................................................................ 112
8.1.3.5 Logs...................................................................................................................................... 114
8.1.3.6 Final neighbors..................................................................................................................... 114
8.1.3.7 Detected neighbors.............................................................................................................. 116
8.1.3.8 Changes................................................................................................................................117
9 Viewing LTE ANR events............................................................................................................................119

9.1 LTE ANR events................................................................................................................................... 120
9.1.1 ANR Blacklisting and Cleanup LTE module events..................................................................... 120
9.1.2 LTE ANR Frequency Rules module events..................................................................................120
9.1.3 ANR 4G IRAT module events...................................................................................................... 121
10 Viewing SON change reports...................................................................................................................123

10.1 Cell level records................................................................................................................................ 123
11 Monitoring LTE ANR modules..................................................................................................................126

11.1 Module Monitor Service...................................................................................................................... 126
12 Troubleshooting ANR................................................................................................................................127
12.1 ANR tries to create relations that already exist..................................................................................127

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Summary of changes
1 Summary of changes
Release Change description
EdenNet 21 Updated sections:
• Overview of LTE ANR: A note is added about the deprecation of direct

CM integration.
• ANR Blacklisting and Cleanup LTE GUI parameters: The description
of the Blacklisting, unblacklisting, neighbor deletion
file parameter is updated.
EdenNet 20 FP 2011 Updated section:
• Configuring relation DN ID for Ericsson (4G)
• Unblacklisting
EdenNet 20 FP 2009 No change.
• ANR 4G IRAT INI parameters: A note is added to the description of the

LTE_IRAT_startingarfcn INI parameter.
• Overview of LTE ANR Frequency Rules module

• LTE ANR Frequency Rules GUI parameters: The following GUI parame-
ters are added:
– Parameter enforcement
– Rule based ID check
– White list and Black list target frequencies file
• LTE ANR Frequency Rules functional description and guidelines
• LTE ANR Frequency Rules algorithm
• LMS configuration file template for LTE ANR Frequency Rules module
• ANR Blacklisting and Cleanup LTE module events
• ANR 4G IRAT module events
• ANR-4G IRAT module reports
• Example of ANR-4G IRAT configuration file
Added sections:
• Whitelist and blacklist target frequencies file

• Frequency rule creation based on instance ID

• Frequency rule deletion through user distance input and LMS
• Frequency rule update through LMS
• Blacklist and whitelist frequencies through user CSV input
EdenNet 19A FP 2004 Updated section:
• ANR 4G IRAT INI parameters: A new parameter (Configurable_re-

lation_Id) is added.
Added section:
• Configuring relation DN ID for Ericsson (4G)
EdenNet 19A FP 2003 No change.
EdenNet 19A FP 2002 Updated section:
• ANR 4G IRAT INI parameters: The description of the following parame-

ters is modified:
– LTE_IRAT_Neighbor_List_Size_2G
– LTE_IRAT_Neighbor_List_Size_3G
EdenNet 19A FP 2001 No change.
EdenNet 19A FP 1912 Updated sections:
• ANR 4G IRAT INI parameters: The TimeBetweenPushes_15Mins pa-

rameter is added.
• The names of the following parameters are changed:
– Maximum deletions per cell is changed to Max deletions

per cell
– Maximum deletions per execution is changed to Max
deletions per execution
EdenNet 19A FP 1911 Updated sections:
• ANR 4G IRAT INI parameters: The following parameters are added:
– Buffer_for_detected_neighbors
– Limit_no_of_detected_neighbors
• The note in the Neighbor additions section is modified.
• A note is added to the Overview of LTE ANR section.
EdenNet 19A Updated sections:
• The Frequency object deletion file section is updated.

• All instances of the LTE ANR Cleanup module are removed from this
document.
• Viewing LTE ANR reports: In the Detected relations table, the Blacklist-
ing? column name is changed to Modification.
EdenNet 19 FP 1905 Description of the Reliability threshold parameter is updated.
EdenNet 19 FP 1904 Added sections:
• Cross OSS support for ANR 4G IRAT (with NAdC)

• Cross OSS support for ANR 4G IRAT (without NAdC)
• Cross OSS support for ANR Blacklisting and Cleanup LTE (with NAdC)
• Cross OSS support for ANR Blacklisting and Cleanup LTE (without
NAdC)
Updated sections:
• Instances of Custom modules are changed to Adapted modules in the

following sections:
– Accessing LTE ANR modules

– Configuring INI parameters
• The Order_of_execution INI parameter is added to the ANR 4G
IRAT INI parameters section.
• ANR Blacklisting and Cleanup LTE GUI parameters
• A new INI parameter (consider_HO_or_tier_for_neighbor_

ranking) is added to the ANR 4G IRAT INI parameters section.
• A new INI parameter (Exclude_outdoor_cells) is added to the
Common INI parameters section.
• The description of the LTE_IRAT_Min_LTEintraFreq_HO_Suc-
cess_For_Cell_Add parameter has been updated in the ANR 4G
IRAT INI parameters section.
• The ANR 4G IRAT module events section is updated.
• The range of the Blacklist duration parameter has been changed
in the following sections:
– Execution flow of ANR Blacklisting and Cleanup LTE module

– ANR Blacklisting and Cleanup LTE GUI parameters

• The ANR Blacklisting and Cleanup LTE module events section is updat-
ed.
• The Blacklisting based on PRACH non-reachable neighbors section is
updated.
• The Cell level records section is updated for the ANR_Blacklisting_and_
Cleanup_LTE module.
• The ANR Blacklisting and Cleanup LTE GUI parameters section is up-
dated.
• The ANR Blacklisting and Cleanup LTE INI parameters section is updat-
ed.
EdenNet 18 SP1 1812 No updates.
EdenNet 18 SP1 1811 A note is removed from Viewing SON change reports.
EdenNet 18 SP1 The updated sections are:
• The description of the Module_log_level parameter is modified.

• Warning level events are removed.
• eNodeB rules content is removed from the Example for LMS configura-
tion file section.
• A note is added to the Neighbor replacements section.
• A note is added to the Example of ANR-4G IRAT configuration file sec-
tion.
• Information about distance and tier count is added to the following sec-
tions
– Blacklisting based on tier and distance

– Tier counting and geo-scoring
• A new parameter Update_mobility_parameters_for_existing_
neighbors is added to the ANR 4G IRAT INI parameters section.
EdenNet 18 FP1 The Exclude_indoor_cells parameter is added to the ANR 4G IRAT INI
parameters section.
EdenNet 18 Added content:
• A note about the Tier column is added to the ANR-4G IRAT module
reports, LTE ANR Cleanup module reports, and ANR Blacklisting and
Cleanup LTE module reports sections.
• Cell Level Summary and Cell level records tables are added to the
ANR-4G IRAT module reports section.
• A note is added to the Cleanup based on handover section.

• Added the Execution flow of ANR Blacklisting and Cleanup LTE module
section.
• Added the Provisioning Details table to the ANR Blacklisting and
Cleanup LTE module reports section.
• The Use_modified_CGI_for_ericsson_external_cell_DN pa-
rameter is added to the ANR 4G IRAT INI parameters section.
• The below parameters are added to the ANR Blacklisting and Cleanup
LTE INI parameters section:
– Maximum deletions per cell

– Maximum deletions per execution
– Time_to_wait_for_MO_feedback_in_seconds
• The Troubleshooting ANR section is added.
• Added the Execution flow of ANR Blacklisting and Cleanup LTE module
section.
• Added the Provisioning Details table to the ANR Blacklisting and
Cleanup LTE module reports section.
• The Module_log_level parameter is added to the below sections:
– ANR 4G IRAT INI parameters

– ANR Blacklisting and Cleanup LTE INI parameters
Updated content:
• The LTE ANR reports section has been modified.

• The Overview of ANR-4G IRAT module section is updated.
• The LTE ANR Cleanup module reports section is updated.
EdenNet 17 SP1 FP1 The Open loop mode section is updated with the below information which is
applicable to the ANR 4G IRAT module:
• Open loop mode with deferred provisioning (only for NAdC integration)
The below INI parameters are added to the ANR Blacklisting and Cleanup
LTE INI parameters section:
• Maximum_blacklisting_changes_per_execution
• Allow_processing_after_maximum_changes_to_push_
reached
• Log_warnings_in_Logs_tab
The INI parameter LTE_IRAT_Min_LTEintraFreq_HO_Success_For_

Cell_Retention is added to the ANR 4G IRAT INI parameters section.
The below GUI parameters are added to the ANR-4G IRAT GUI parameters
section.

• Optimize 4G to 3G neighbor relations

• Optimize 4G to 2G neighbor relations
EdenNet 17 SP1 The ANR 4G IRAT INI parameters section has been updated with some new
parameters:
• Enable_trimming
• KPI_data_reliability_threshold
• Maximum_allowed_UARFCNs_for_LTE_IRAT_neighbor
• Maximum_count_redirWithSysInfoAllowed_lnrelw
• Maximum_count_redirWithSysInfoAllowed_lnrelg
The following sections are added for ANR 4G IRAT:
• Neighbor trimming
• Whitelisting and blacklisting
The Plan name tag parameter is added to the following sections:

• LTE ANR Cleanup module GUI parameters
• LTE ANR Frequency Rules GUI parameters
• ANR-4G IRAT GUI parameters
Module Monitor Service information has been added under the section Mon-
itoring LTE ANR modules.
The Neighbor additions section has been updated.
The ANR-4G IRAT GUI parameters section has been updated.
The LTE ANR Cleanup algorithm section is updated.
The ANR Blacklisting and Cleanup LTE algorithm section is updated.
The parameter information for Blacklist duration and Increased

blacklist duration has been updated.
The ANR Blacklisting and Cleanup LTE INI parameters section has been
updated.
The ANR Blacklisting and Cleanup LTE module reports section has been
updated.
The ANR-4G IRAT module reports section has been updated.
The ANR Blacklisting and Cleanup LTE module reports section has been
updated.
The LTE ANR Cleanup module reports section has been updated.

The parameter information for TimeBetweenPushes_15Mins has been

updated in the ANR Blacklisting and Cleanup LTE INI parameters section.
The Closed loop mode section is updated.
The section Example of ANR-4G IRAT configuration file is modified.
EdenNet 17 FP1 The updated sections are:
• The LTE ANR execution section is enhanced by adding Selecting the

configuration file for LTE ANR modules section.
• The Configuring INI parameters section is updated with Save As and
Set As Default options.
• The ANR-4G IRAT module reports section is updated.
EdenNet 17 The document has been restructured. The new sections are:
• LTE ANR functional description and guidelines

• LTE ANR configuration parameters
• Viewing LTE ANR reports
• Viewing LTE ANR events
• Viewing LTE ANR targets
The updated sections are:
• Overview of LTE ANR

• LTE ANR algorithms
• Prerequisites
• Monitoring LTE ANR modules
• Overview of ANR Blacklisting and Cleanup LTE module

• Neighbor replacements
• Common INI parameters
• ANR-4G IRAT module logs
EdenNet 16 SP2 A new section is added: Example for LMS configuration file
EdenNet 16 This is a new document that provides information on how to optimize net-
work performance by automating the task of managing neighbor relations.

Table 1: Summary of changes

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Overview of LTE ANR
2 Overview of LTE ANR
Configuration and management of neighbor relation lists is one of the most labor intensive areas in the
cellular network configuration, especially in mature networks, during network expansion. Automating
the task of configuring and managing neighbor relations results in substantial cost savings for opera-
tors and improves network performance.
EdenNet supports the following LTE ANR (Automatic Neighbor Relations) modules:
• ANR Blacklisting and Cleanup LTE - optimizes network performance by identifying the poorly per-
forming neighbors and blacklisting these neighbors (includes LTE to LTE neighbors and Inter-RAT
neighbors).
• LTE ANR Frequency Rules - automates creation of inter frequency related objects by enabling
handover and idle mode mobility in the LTE network.
• ANR 4G IRAT - optimizes the IRAT neighbor list of LTE cells towards 3G and 2G cells for connect-
ed mode handover.
Note:
Nokia only supports the use of AC based integration for Nokia, Ericsson, and Huawei ven-
dors as direct CM integration is deprecated from EdenNet 21 release onwards for these ven-
dors.
2.1 Overview of ANR Blacklisting and Cleanup LTE module

The ANR Blacklisting and Cleanup LTE module automates disabling of handover or mobility service
across LTE neighbor relations based on their performance.
It supports blacklisting and cleanup of intra-LTE, LTE to WCDMA, and LTE to GSM neighbor relations:
• Intra-LTE neighbor relations are evaluated against their handover performance based on user de-
fined criteria, to blacklist the handover service.
• LTE to WCDMA neighbor relations are evaluated against the performance of their mobility ser-
vices, such as SRVCC (Single Radio Voice Call Continuity) and CSFB/PSHO (Circuit Switched
FallBack/Packet Switched HandOver), to blacklist the corresponding mobility service.
• LTE to GSM neighbor relations are evaluated against the performance of the SRVCC mobility ser-
vice.
This module also supports automatic unblacklisting of the handover or mobility service after a defined
period or as per the defined operator policy.
It also supports blacklisting and cleanup based on distance, tier count mechanism, and cell pairs de-
fined in the CSV file. Additionally, Intra-LTE neighbors can also be blacklisted based on PRACH (Phys-
ical Random Access Channel) non-reachable criteria. Whenever KPIs are used for evaluation, the reli-
ability factor can also be defined so that blacklisting actions are taken using reliable KPIs.

It automates the blacklisting and unblacklisting of neighbor relations, and thereby optimizes the neigh-
bor relations in the LTE network.
Note: In the EdenNet UI, the user has an option to blacklist and whitelist relations. With re-
spect to the ANR_Blacklisting_and_Cleanup_LTE module, blacklisting indicates setting han-
dover to forbidden.
It evaluates the handover or mobility performance of LTE neighbor relations for a given monitoring pe-
riod, keeping track of the number of consecutive blacklisting operations performed on a given neigh-
bor relation, and automatically deciding to either unblacklist the handover or mobility service after a
defined period, or continuing to blacklist the given neighbor relation.
It removes neighbor relations from LTE ANR neighbor lists if the Deletion of neighbors use case is se-
lected. The relation to be removed can be specified in one of two ways:
• Clean-up of intra-LTE neighbor relations: Intra-LTE neighbor relations are evaluated against their
handover performance (based on user defined criteria) to clean-up the neighbor relations.
• Neighbor relation clean-up based on distance, tier count mechanism, and cell pairs defined in the
CSV file.
It does not attempt to block the LTE distributed ANR function from adding the removed neighbors once
again.
It also prevents the ping-pong behavior of removing and adding certain neighbor relations between the
ANR Blacklisting and Cleanup LTE module and the ANR function of distributed SON by RAN vendors.
It performs the following functions for LTE neighbor relations:
• Identifying all LTE neighbor relations in the scope that match the rules specified by the operator.
• Importing neighbor relations to be deleted, blacklisted, or unblacklisted via a neighbor relation file.
• Keeping track of consecutive deletions performed on a given neighbor relation to decide whether
to automatically blacklist or continue deleting a given neighbor relation.
• Keeping track of consecutive blacklisting operations performed on a given neighbor relation to
decide whether to automatically unblacklist or to continue blacklisting a given neighbor relation.
• Preventing autonomous deletion of blacklisted neighbor relations.
• X2 blacklisting on specific neighbor relations can be applied by providing neighbor relation files
and enabling X2 blacklisting.
Supported vendors and technologies
Table 2: ANR Blacklisting and Cleanup LTE module supported vendors and technologies lists the sup-
ported vendors and technologies for the ANR Blacklisting and Cleanup LTE module.
Vendor Technology
Nokia LTE
Ericsson LTE
Huawei LTE

Vendor Technology
Alcatel Lucent LTE
ZTE LTE
Table 2: ANR Blacklisting and Cleanup LTE module supported vendors and technologies
2.1.1 ANR Blacklisting and Cleanup LTE dependencies and interactions

The dependencies and interactions of the ANR Blacklisting and Cleanup LTE module are described in
this section.
2.1.1.1 Dependencies
This module modifies the parameters of LTE neighbor relations, and does not affect other services
in the network. However, scheduled operator activities or other modules modifying the same LTE
neighbor relations should not be executed in the closed loop, at the time this module is implementing
changes to the network.
2.1.1.2 Interactions
User equipment based ANR Distributed SON feature: Once neighbor relations are blacklisted in the
network, measurements are not recorded against the corresponding neighbor relations. Nokia eNBs
can automatically monitor the performance of neighbor relations, and if the relations do not meet
the performance requirements, the neighbor relations are automatically deleted. Hence, blacklisted
neighbors are perceived as under performing and are removed by the eNB. The ANR Blacklisting and
Cleanup LTE module protects blacklisted neighbors from automatically getting deleted by the eNB by
setting the Remove Allowed parameter to false for blacklisted neighbors, thereby avoiding repeated
creation and deletion of blacklisted neighbors.
2.2 Overview of LTE ANR Frequency Rules module

The LTE ANR Frequency Rules module automates the creation of inter frequency related objects by
enabling handover and idle mode mobility in the LTE network.
This module performs the following functions for LTE cells in the selected scope:
• Identifying all the frequencies used by surrounding cells within the search distance
• Creating inter frequency handover and idle mode mobility objects based on the:
– data available in Frequency Object Creation or Frequency Object Deletion files

– identification of the frequency objects using one or more of the following criteria:
• Distance is within the given threshold (for example, 20 kms).

• Frequencies match with the frequency Layer Management Strategy (LMS) defined in the
LMS configuration file. For more information, see LMS configuration file template for LTE
ANR Frequency Rules module.
• Deleting inter frequency handover and idle mode mobility objects based on the:
– data available in the Frequency Object Deletion file.

– data available in the blacklist file.
– identification of the frequency objects using one or more of the following criteria:
• Distance is outside the given threshold (for example, 20 kms).

• Frequencies are not defined in the LMS configuration file. For more information, see LMS
configuration file template for LTE ANR Frequency Rules module.
– Update inter frequency handover and idle mode mobility objects based on the frequencies
matching the frequency LMS defined in the LMS configuration file when the Parameter en-
forcement parameter is set to Audit_and_Enforce. For more information, see LMS con-
figuration file template for LTE ANR Frequency Rules module.
Inter frequency handover and idle mode mobility objects are configured in the scope of LTE cells by
searching other LTE, WCDMA and GSM frequency layers which are nearby. These objects, specific to
a frequency, enable user equipment in the cell to begin searching for neighboring cells operating in the
corresponding frequency, thereby enabling inter frequency handovers and idle mode cell reselection.
This module enables a UE based ANR in the eNB to add inter-frequency neighbors during connected
mode, and enable cell reselection towards cells operating on different frequencies. Nokia eNBs send
both LTE and WCDMA frequency information to the UEs to scan for potential neighbors in the sur-
roundings.
Note:
• This module supports only Nokia LTE cells in the cluster.

• It configures inter-frequency handover and idle mode mobility related objects which do
not affect other services in the network. However, any scheduled activities modifying the
same inter-frequency handover and idle mode mobility objects must not be executed at
the same time that this module is implementing changes to the network.
This module can run in two different modes:
• In open-loop mode, the module identifies frequency layers used in the surrounding LTE, WCD-
MA, and GSM cells with respect to the scope cell, but no changes are applied to the network. The
module output consists of a report listing the source cell and its inter-frequency handover, and idle
mode mobility objects that the module has identified based on the user defined settings.
• In closed loop, the changes are applied to the network. The module can be run in closed loop
mode on a weekly basis.
Table 3: LTE ANR Frequency Rules module supported vendors and technologies lists the supported
vendors and technologies for the LTE ANR Frequency Rules module.

Vendor Technology
Nokia LTE
Table 3: LTE ANR Frequency Rules module supported vendors and technologies
2.2.1 LTE ANR Frequency Rules dependencies and interactions

The dependencies and interactions of the LTE ANR Frequency Rules module are described in this
section.
This module configures inter frequency handover and idle mode mobility related objects, and does not
affect other services in the network. However. scheduled operator activities modifying the same inter
frequency handover and idle mode mobility objects should not be executed at the time that this mod-
ule is implementing changes to the network.
This module enables UE based ANR (distributed SON feature) in the eNB to add inter frequency
neighbors during connected mode, and enable cell re-selection towards cells operating on different
frequencies. Nokia eNBs support UE based ANR for adding intra LTE and LTE to WCDMA neighbors.
Nokia eNBs send both LTE and WCDMA frequency information to the UEs to scan for potential neigh-
bors in the surroundings.
2.2.2 LMS configuration file template for LTE ANR Frequency Rules module
The LTE ANR Frequency Rules module uses an Layer Management Strategy (LMS) to check if there
is a rule to create frequency objects between two frequencies. If it exists, the template is used to set
the frequency object attributes.
Note: This template is used only for the LTE ANR Frequency Rules module.
The template to create frequency rules under existing LTE cells to the newly introduced frequency lay-
er is as follows:
1. Define the layers.
"layers": { "LTE": { "technology": "LTE" }, "<frequency layer>":

{ "earfcn": <frequency layer> }}
2. Define rules allowing frequency objects from LTE to frequency layer.
"rules": { "*": { "<freqyency layer>": {
“frequency_relations": {

<frequency layer>": {
"condition" : {“name”: "<condition_name>",
"hop": { "template": "<template_name>_<frequency layer>" } } }
}
3. Define a template to set the attribute values of the created frequency objects.
"templates": {"<template_name>_<frequency layer>":
{"<parameter>":"<value>"} }
For example,
"templates": {"LNHOIF_F1": {"measurementBandwidth":"mbw100"} }

4. Define the conditions.
“conditions”: {“<condition_name>”:{ “target”: {
“filter”: “<target_filter_name>”} }}
5. Define the filter.
"filters": {
"enodeB": {
"dn": "<expression representing the enodeb or controller of the source"
},
“target_filter_name”: {
“type”: “<target filter>”
For example:
"filters": {
"enodeB": {
"dn": ".+/LNBTS-([0-9]+)$" }
“lnhoif”: {
“target”: “LTEConectedMode”
}
6. Define rules allowing frequency objects from LTE to frequency layer 19500.
"rules": { "*": { "LTE": { "<frequency layer>": {"condition" : "always",

"hop": { "template": "<frequency layer>" } } } } }

7. Define a template to set the attribute values of the created frequency objects.
"templates": {"LTE_<frequency layer>": {"measurementBandwidth":"mbw100",

"LNHOIFID": "5"}
8. Define the filter.
"filters": {
"enodeB": { "dn": "<expression representing the enodeb or controller of

the source" }
For example:
"filters": {
"enodeB": { "dn": ".+/LNBTS-([0-9]+)$" }
Note: Use the target filters in Table 4: Key description to define the target frequency objects
allowed by the LMS.
Key Description
LTEIdleMode Inter frequency idle mode managed object
LTEConectedMode Inter frequency connected mode managed object
UMTSIdleMode Inter-RAT to WCDMA idle mode managed object
UMTSConectedMode Inter-RAT to WCDMA connected mode managed object
GSMIdleMode Inter-RAT to GERAN idle mode parent managed object
GNFLMode Inter-RAT to GERAN idle mode child managed object
GSMConectedMode Inter-RAT to GERAN connected mode managed object
FreqRDRT Redirection target
Table 4: Key description
For example, to create frequency rules for the newly introduced frequency layer 19500 from source
18500 for LTE connected mode object:
"filters": {
“lnhoif”: {
“target”: “LTEConectedMode”
}
}
"layers":{
"F18500": {"earfcn": "18500"},

"F19500": {"earfcn": 19500}

}
"rules": {
"*": {
"F18500": {
“frequency_relations”: {
"F19500":
{"condition" : {
“name”: “lnhoif_object”,
"hop": { "template": "LNHOIF_F19500" } }
}
}
}
“conditions”: {“lnhoif_object”:{
“target”: { “filter”: “lnhoif” } }
}
"templates": {"LNHOIF_F19500": {"measurementBandwidth":
"mbw100", "LNHOIFID": "5"}
If the attribute name specified in the template is applicable to the frequency object being created (in
the above example LTE to LTEConectedMode, frequency objects created are LNHOIF objects),
the value specified is used instead of the default value configured in the module template file for that
object.
The LMS file is imported into EdenNet using the Administration tab. For more information, see the
Configure and monitor SON modules section in the EdenNet User and Administration Guide docu-
ment.
Note: The LMS template is mandatory for the creation of frequency objects. See Table 5:
Mandatory parameters for frequency objects per version to identify the mandatory parame-
ters required for each object per version.
Version LNHOIF IRFIM LNHOW UFFIM LNHOG GFIM GNFL
FDD_ measurementBandwidth, measBdw, N/A N/A N/A - N/A

15A_ interPresAntP interPre-
MACRO sAntP
FDD_ measurementBandwidth, measBdw, N/A N/A N/A - N/A

15A_ interPresAntP interPre-
MICRO sAntP
TDD_ a5ReportIntervalInterFreq, measBdw, N/A qRxLevMin- N/A tResGer, ger-

15A_ a5TimeToTriggerInterFreq,interTRe- Utra, gerRes- FrqThrH,
MACRO measurementBand- sEut, inter- utraFrqThrH, TiFHM, ger-
width, interPresAntP, FrqThrH, in- utraFrqThrL, gerRes- FrqThrL,
hysThreshold3InterFreq terFrqThrL, tResUtra TiFMM qRxLevMin
interPre-

sAntP, Ger
qRxLevMinIn-
terF
TDD_ a5ReportIntervalInterFreq, measBdw, N/A qRxLevMin- N/A tResGer, ger-

15A_ a5TimeToTriggerInterFreq,interTRe- Utra, gerRes- FrqThrH,
MICRO measurementBand- sEut, inter- utraFrqThrH, TiFHM, ger-
width, interPresAntP, FrqThrH, in- utraFrqThrL, gerRes- FrqThrL,
hysThreshold3InterFreq terFrqThrL, tResUtra TiFMM qRxLevMin
interPre-
Ger
sAntP,
qRxLevMinIn-
terF
FDD_16 measurementBandwidth, measBdw, N/A N/A N/A N/A N/A

interPresAntP interPre-
sAntP
TDD_16 a5ReportIntervalInterFreq, measBdw, N/A qRxLevMin- N/A tResGer, N/A

a5TimeToTriggerInterFreq,interTRe- Utra, gerRes-
measurementBand- sEut, inter- utraFrqThrH, TiFHM,
width, interPresAntP, FrqThrH, in- utraFrqThrL, gerRes-
hysThreshold3InterFreq terFrqThrL, tResUtra TiFMM
interPre-
sAntP,
qRxLevMinIn-
terF
FDD_ measurementBandwidth measBdw N/A N/A N/A N/A N/A

16A
TDD_ a5ReportIntervalInterFreq, measBdw, N/A qRxLevMin- N/A tResGer, N/A

16A a5TimeToTriggerInterFreq,interTRe- Utra, gerRes-
measurementBandwidth, sEut, inter- utraFrqThrH, TiFHM,
hysThreshold3InterFreq FrqThrH, in- utraFrqThrL, gerRes-
terFrqThrL, tResUtra TiFMM
qRxLevMinIn-
terF

TDD_
17_
17ASP


18_
above
TDD_ measurementBandwidth measBdw N/A qRxLevMin- N/A N/A N/A

18_ Utra,
above utraFrqThrH,
utraFrqThrL
Table 5: Mandatory parameters for frequency objects per version
2.3 Overview of ANR-4G IRAT module

The ANR 4G IRAT (Inter Radio Access Technology) module optimizes the IRAT neighbor list of LTE
cells towards 3G and 2G cells for connected mode handover.
The ANR-4G IRAT module performs the following functions for the LTE IRAT neighbor list:
• It detects missing relations and adds them.

• It evaluates existing relations for potential replacement through the detected missing relations (if
the neighbor list is already at or above defined limits).
• It enforces the operator layer management strategy and attribute values for new neighbor rela-
tions.
Note:
If the relations are created manually, the changes are reflected in EdenNet after a few hours.
The timings for the relation MO update per vendor are:
• Huawei: 12 hours
• Ericsson: 4 hours
• Nokia: 4 hours
• ZTE: 6 to 12 hours
If ANR is triggered before the synchronization, the module may propose the same relations
which are added manually and implementation may fail.
Table 6: ANR-4G IRAT module supported vendors and technologies lists the supported vendors and
technologies for the ANR-4G IRAT module.
Vendor Technology
Nokia LTE

Vendor Technology
Ericsson LTE
Huawei LTE
Alcatel Lucent LTE
ZTE LTE
Table 6: ANR-4G IRAT module supported vendors and technologies
In a cross-OSS phase 3B environment, the mandatory dependent managed objects (frequency MOs)
required by the ANR relations are created by NAdC (NetAct Advanced Configurator) for all vendors.
2.3.1 ANR-4G IRAT dependencies and interactions

The dependencies and interactions of the ANR-4G IRAT module are described.
The EdenNet Reuse Code Optimization module may cause PCI changes and neighbor relation re-
movals. However, these changes are reflected immediately in the EdenNet cache and are therefore
considered by the ANR modules.
Each cell in the network should be included in not more than one ANR closed loop instance, since up-
dates of the cache for the cell in one module instance can occur in the middle of the decision making
process for the other module instance. Manual neighbor relation additions, removals, or changes from
tools outside of EdenNet should not be permitted, or else they should be very carefully planned when
the ANR modules are running in closed loop in a network area. These neighbor changes will not be
immediately visible in the EdenNet cache, and therefore non-optimal decisions in the ANR modules
may result. The ANR modules are the only EdenNet modules that add neighbor relations. Therefore,
no interactions with other modules are expected in terms of neighbor additions.
2.3.2 LMS configuration

The LMS configuration provides the frequency layer details in each technology (LTE, UMTS, GSM)
and the rules for the allowed neighbor definitions from each LTE frequency layer to the IRAT frequency
layers.
The frequency layers for:
• UMTS are determined either by pattern matching on the cell name or from the UARFCN.
• GSM are determined from the band information obtained from the CM data.
For further information about the LMS, see the EdenNet LMS Configuration File Guide.

2.3.2.1 Example for LMS configuration file
Figure 1: Overview of LMS sections provides an overview of the main sections of the LMS used for the
ANR-4G IRAT module.
Figure 1: Overview of LMS sections
An example of row rules used for sites with LTE cells is given below:
row rules
"row rules": {
"optional_LTE_row_rule_P1P2U1": {
"P1": { "condition" : { "name": "majority" }, "hop": { "template":
"lte_umts" } },
"lte_umts" } },
"U1": { "condition" : { "name": "majority" }, "hop": { "template":
"lte_umts" } },
"GSM1900": { "condition" : "always", "hop": { "template": "lte_gsm" } }
},
"optional_LTE_row_rule_P1U1U2": {
"lte_umts" } },
"lte_umts" } },
"lte_umts" } },
"GSM1900": { "condition" : "always", "hop": { "template": "lte_gsm" } }
}, …

In this LMS configuration, when the optional_LTE_row_rule_P1P2U1 is applied, LTE relations to

P1, P2, U1, and GSM layers are allowed. When the optional_LTE_row_rule_P1U1U2 is applied,
LTE relations to P1, U1, U2, and GSM are allowed. The majority condition is used to ensure that
only one UARFCN is associated to each layer. The template refers to the templates to be used for
setting specific attribute values for the managed objects defining individual LTE IRAT relations.
layers
For Nokia, the P1, P2, and U1 layers are defined by the cell name in the layers section of the LMS
configuration file. The GSM layer is defined by technology.
"layers": {
"U1": { "name": "^U.*1$" },
"P1": { "name": "^P.*1$" },
"P2": { "name": "^P.*2$" },
"GSM": { "technology": "GSM" } …
For Ericsson, all IRAT cells are external and it is necessary to define separate layers for UMTS from
the perspective of LTE. These layers must be defined in terms of UARFCN since there is no cell name
in the external cell definitions (the userLabel is available, but this is just a free text field). All UARFCN
to which LTE IRAT relations will be defined must be specified. Use an OR condition if more than one
UARFCN is used for a layer.
"layers": {
"U1": { "name": "^U.*1$" },
"P1": { "name": "^P.*1$" },
"P2": { "name": "^P.*2$" },
"LTE_U1": { "or": [ { "uarfcn": 2062 }, { "uarfcn": 1937 } ] },
"LTE_U2": { "uarfcn": 2087 },
"LTE_P1": { "or": [ { "uarfcn": 462 }, { "uarfcn": 487 } ] },
"GSM": { "technology": "GSM" } …
rules
All sites in the area to be optimized must fall into only one of the site types defined in the rules
section of the LMS. The example below shows the LMS for a site with P1 and P2 UMTS cells and
optional LTE and GSM cells. When LTE cells exist on this site type, then IRAT relations can be defined
as described in the optional_LTE_row_rule_P1P2U1.
"rules": {
"P1P2": {
"P2": {
"P2": { "condition" : { "name": "intra" }, "hop": { "template":
"intra" } },
"P1": { "condition" : { "name": "local" }, "hop": { "template":
"basic2" } }
},
"P1": {

"P1": { "condition" : { "name": "intra" }, "hop": { "template":

"intra" } },
"P2": { "condition" : { "name": "local" }, "hop": { "template":
"basic1" } }
},
"optional_LTE": "optional_LTE_row_rule_P1P2U1",
"optional_GSM": "optional_GSM_row_rule"
}, …
templates
The attribute values to be used for each allowed neighbor relation type are defined in the templates
section of the LMS configuration file. These attribute values should be checked to confirm their
accuracy. An example is given below for setting the mandatory parameters for LNRELW and LNRELG
(Nokia from LTE15A onwards) to operator defined defaults:
"templates": {
"lte_gsm": {
"nrControl": "automatic",
"eNACCAllowed": "allowed",
"srvccAllowed": "allowed"
},
"lte_umts_p": {
"csfbPsHoAllowed": "forbidden",
"psHoAllowed": "allowed",
"srvccAllowed": "allowed",
"removeAllowed": "true",
"utranLbAllowed": "true"
},
"lte_umts_u": {
"csfbPsHoAllowed": "allowed",
"psHoAllowed": "allowed",
"srvccAllowed": "allowed",
"removeAllowed": "true",
"utranLbAllowed": "true"
},
"enodeB_UMTS": {
"srvccHoInd": "CSonly"
},
"enodeB_GSM": {
"dtm": "FALSE",
"networkControlOrder": "NC0",
"systemInfoType": "none"
}
}

Note:
For Nokia, there are some limits on the number of relations that can have certain attribute
value settings.
• redirWithSysInfoAllowed of LNRELW - All the relations (existing and newly added) of

the cell (which are optimized - relations added and removed) are ranked. Depending on
Maximum_count_redirWithSysInfoAllowed_lnrelw (maximum 16 per operating
frequency), relations per operating frequency are set to allowed for the LTE-WCDMA
case.
• redirWithSysInfoAllowed of LNRELG - All the relations (existing
and newly added) of the optimized cell are ranked. Depending on
Maximum_count_redirWithSysInfoAllowed_lnrelg (maximum 16 for LTE-
GSM), relations are set to allowed for the LTE-GSM case.
• csfbPsHoAllowed of LNRELW - the number of relations with csfbPsHoAllowed set
to allowed are dependent on CSFB limits as defined in LNHOW objects. When
csfbPshoAllowed is set as allowed in the LMS during LTE-WCDMA IRAT optimization
(based on the number of maximum CSFB target parameters of LNHOW objects defined
per frequency), the corresponding number of LTE-WCDMA neighbor relations under the
same frequency as LNHOW should have Circuit-switched fallback with PS
handover allowed parameter set as allowed.
• redirWithSysInfoAllowed - there is no need to set the redirWithSysInfoAllowed =
allowed or forbidden in the LMS as the ANR-4G IRAT module automatically limits
the number of relations with setting allowed for this parameter.
• If any of the mandatory parameters listed in Table 7: Mandatory parameters are missing
in the LMS, the ANR-4G IRAT module creates relations with default values.
Parameter Default
srvccAllowed allowed
csfbPshoAllowed forbidden
psHoAllowed allowed
removeAllowed true
utranLbAllowed false
Table 7: Mandatory parameters
• psHoAllowed and srvccAllowed of LNRELW - All the existing and newly added relations
of the optimized cell (where relations have been added and removed) are ranked and the
first 32 relations per operating frequency are set to allowed for the LTE-WCDMA case.

LTE Automatic Neighbor Relations Guide DN09238435 1-0 LTE ANR functional description and
guidelines
3 LTE ANR functional description and guidelines

This section describes:
• ANR Blacklisting and Cleanup LTE functional description and guidelines

• LTE ANR Frequency Rules functional description and guidelines
• ANR-4G IRAT functional description and guidelines
• Operational modes
3.1 ANR Blacklisting and Cleanup LTE functional description and

guidelines
The ANR Blacklisting and Cleanup LTE module performs the following functions for LTE neighbor rela-
tions:
• Blacklisting
– Blacklisting based on Handover
Blacklisting of intra-LTE neighbors is based on the handover performance against the user de-
fined threshold. The rules for analyzing the performance are configurable and the user can
blacklist neighbors based on the following requirements:
• Minimum HO attempts
• Maximum HO attempts
– Blacklisting based on Tier and Distance
This module also supports blacklisting based on distance and tier count mechanism.
– Blacklisting based on PRACH non-reachable neighbors
If there are two neighboring cells whose PRACH settings do not match the actual geographi-
cal distance between the cell’s antennas, any handover occurrence between the two cells has
a high risk of failure. Such neighbors are called PRACH non-reachable neighbors.
– File based Blacklisting, Unblacklisting, and Clean-up
If you specify the neighbor relations to be removed via a file, the module only removes those
neighbors.
• Un-blacklisting
– KPI based automatic verification and unblacklisting: After blacklisting, the module checks
the customer defined KPIs (defined in INI) and initiates unblacklisting on the cells where KPI
degradation was detected. The module unblacklists the relations blacklisted by the module on-
ly if the cell's KPIs are degraded.

guidelines
– Un-blacklisting based on time:
Once neighbor blacklisting runs, relations are un-blacklisted when the timer expires.
• Clean-up
– Clean-up based on Handover:
This module supports clean-up of intra-LTE neighbor relations. Intra-LTE neighbor relations
are evaluated against their handover performance based on user defined criteria to clean-up
neighbor relations.
3.2 LTE ANR Frequency Rules functional description and guidelines

The main purpose of the LTE ANR Frequency Rules module is to create frequency rules and the cor-
responding managed objects in the network. Inter-frequency related objects are required to support in-
ter-frequency handoffs (LTE or IRAT) as well as idle mode mobility.
The LTE ANR Frequency Rules module:
• identifies all the frequencies used by surrounding cells within the search distance.
• ensures that inter-frequency handover and idle mode mobility objects are defined in the frequency
object creation or deletion file.
• creates inter frequency handover and idle mode mobility objects based on the layer management
strategy defined in the LMS configuration file specific to this module.
Frequency rule creation through user distance input
Frequency rule creation is the primary functionality of this module. For the given target cells, the mod-
ule obtains all the neighbors in the given radius, and if the LMS permits creation of inter-frequency ob-
jects, it creates the appropriate object for the target cell.
Frequency rule creation or deletion through user CSV input
Managed objects can also be created for frequency rules by providing a CSV file input. The CSV file
should contain a comma separated list of source cells and target cells (using the cell's label) in each
row.
Frequency rule deletion through user distance input
For the given target cells, the LTE ANR Frequency Rules module obtains all the neighbors in the given
radius. If the source cell contains a frequency relation which is not part of the neighbor cell frequency,
delete the frequency relation.
Frequency rules deletion through LMS
For the given target cells, the LTE ANR Frequency Rules module obtains all the existing frequency ob-
jects. If any of these existing objects is not allowed in the LMS, the frequency objects are deleted.
Frequency rules update through LMS

guidelines
For the given target cells, the LTE ANR Frequency Rules module obtains all the existing frequency
objects. If the Parameter enforcement GUI parameter is set to Audit_and_Enforce, then
the parameters of the existing frequency objects are updated according to the LMS template. If
the Parameter enforcement GUI parameter is set to Ignore, the existing parameters are not
updated. However, creations occur with the LMS template provided.
Blacklisting and Whitelisting frequencies through user CSV input
Managed objects can also be whitelisted or blacklisted for frequencies, by providing a CSV file input.
The CSV files should contain a comma separated list of source cells, frequencies to be whitelisted or
blacklisted, technology, and whitelist/blacklist in each row. The whitelisted frequencies (if not present)
are created for the respective technology or retained (if they already exist). The blacklisted frequencies
are deleted (if present) or not created (if not present).
LMS support for frequency rules
Layer Management Strategy (LMS) is used to create frequency objects.
3.3 ANR-4G IRAT functional description and guidelines

The ANR-4G IRAT module performs the following functions for LTE IRAT neighbor lists:
• It detects missing relations and adds them.

• It evaluates existing relations for potential replacement by detected missing relations (if the neigh-
bor list is already at or above defined limits).
• It enforces operator layer management strategies and attribute values for new neighbor relations.
3.4 Operational modes

The LTE ANR modules support the following operational modes:
• Open loop mode

• Closed loop mode
3.4.1 Open loop mode

In open loop mode, no changes are applied to the network. The module output consists of a report list-
ing the recommended neighbor relation changes to improve network performance but XML plans are
not generated.
The module retrieves the configuration information from the EdenNet configuration management
cache. It does not force any reading from the OSS for data in the cache that has been modified, or that
has expired. However, any changes made by EdenNet through previous successful closed loop itera-
tions of the module are immediately reflected in the EdenNet configuration management cache.
Open loop mode with deferred provisioning (only for NAdC integration)

guidelines
When the ANR 4G IRAT module runs in open loop mode, the plan is visible under SON Modules →
Status → Provisioning Logs.
• When the module run is successful, an entry appears in the provisioning logs area. The provision-
ing status is set as waiting till the plan is provisioned or till it expires.
• A user with closed loop permissions for the ANR module can provision the plan immediately, or
schedule it to be provisioned later.
• When a plan is scheduled, the provision status will be changed to Scheduled. For direct OSS inte-
gration, open loop does not generate a plan.
• If the cells in the plan are a part of the SON module exclusion list, or if they are not a part of the
user’s geofence, the plan will not be provisioned. In such cases, the status remains as waiting and
even the scheduled plans are moved to waiting status.
• The validity of the plan is for a period of 24 hours. The plan validity period can be configured. The
plan expires after the validity period and the user is not allowed to provision the plan.
For more details, see the Editing plan lifetime validity for open loop section in the EdenNet User
and Administration Guide document.
• The user can reschedule and cancel schedules.
3.4.2 Closed loop mode

In closed loop mode, changes are applied to the network. The module attempts to process all the cells
from its target list at each execution.
After running the same algorithm as in open loop mode, the recommended changes are pushed to the
live network. Since any changes made by EdenNet through previous successful closed loop iterations
of the module are immediately reflected in the EdenNet configuration management cache, when Eden-
Net is solely in control of neighbor relation operations, the module always works with the latest config-
uration information.
Periodic updates of relevant managed objects are also performed according to the configured sched-
ule. Typically, these are every hour for cell level managed objects and every four hours for neighbor
relation managed objects.
Note: The LTE ANR Frequency rules module only runs one time. If repeated executions are
required, this module must be run manually, or scheduled.
The ANR Blacklisting and Cleanup LTE module and ANR 4G IRAT module are iterative
in closed loop mode. Once started, the modules run indefinitely (until they are stopped
manually or a scheduled end-time is reached). When an execution is complete, the
modules enter an idle state until another execution is automatically triggered at the
start of the next 15 minute period. Irrespective of the value set for the parameter
TimeBetweenPushes_15Mins, the modules iterate every 15 minutes to check if the
intended ROP (Report Output Period) is met and then decide whether or not to continue that
iteration.

LTE Automatic Neighbor Relations Guide DN09238435 1-0 LTE ANR algorithms
4 LTE ANR algorithms

This section describes the algorithm details of the following LTE ANR modules:
• ANR Blacklisting and Cleanup LTE algorithm

• LTE ANR Frequency Rules algorithm
• ANR-4G IRAT algorithm
4.1 ANR Blacklisting and Cleanup LTE algorithm

This module blacklists the intra-LTE, LTE to WCDMA, and LTE to GSM neighbor relations if Blacklist-
ing of neighbors is selected during use case selection. At each execution, the module iterates all the
source cells and attempts to blacklist, unblacklist, or delete the poorly performing neighbors, assuming
that all handover types (LTE to LTE, LTE-WCDAM, and LTE-GSM) are enabled via the UI settings. The
UI settings to enable the handover types are:
• Blacklist or unblacklist intra-LTE neighbor relations

• Blacklist or unblacklist LTE to WCDMA neighbor relations
• Blacklist or unblacklist LTE to GSM neighbor relations
The default time between iterations of the module running and pushing changes in closed loop is 15
minutes. However, the configuration parameter TimeBetweenPushes_15Mins can be modified to
limit how often this module runs after pushing changes. TimeBetweenPushes_15Mins = 4 means
the module pushes changes a maximum of once per hour in closed loop.
This module is not iterative if the CSV file is imported using blacklisting, unblacklisting, or neighbor
deletion file options.
4.1.1 Execution flow of ANR Blacklisting and Cleanup LTE module

This section describes the flow of the ANR Blacklisting and Cleanup LTE module.
1. In the first iteration, the module proposes the neighbors to be blacklisted based on the provided
constraints such as tier, distance, HO attempts, HO success, expected cell range, and so on.
2. All the proposed changes are provisioned to the network if the module runs in closed loop. For the
successfully provisioned relations, the provision time will be updated in the module data. In case of
partial provisioning, the module updates the time for the successfully implemented relations and ig-
nores the failed relations.
3. The module is re-triggered every 15 minutes as per the EdenNet framework. The pro-
cessing of each run depends on the configured value and provision time of the parameter
TimeBetweenPushes_15Mins. If TimeBetweenPushes_15Mins is 4, the module is processed
once every hour. The other three triggers are skipped.

4. In further iterations, the value configured for KPI_Time_Window_Eval (in hours) is checked
against the blacklisted time for the relation. If the blacklisted time has expired, the source cell is
considered for unblacklisting evaluation.
5. The KPI degradation is checked against the post and pre-optimisation window based on
KPI_Time_Window_Eval and the time that the relation was blacklisted.
For example, if the relation was blacklisted at 10 AM, TimeBetweenPushes_15Mins is set as

4, and KPI_Time_Window_Eval is set as 1, the module will process the relations for blacklisting
and unblacklisting at 11 AM. In this case, the pre-optimisation time is 9 AM to 10 AM and the post-
optimisation time is 10 AM to 11 AM.
The configured KPI from the operator policy is fetched during this time window and compared for
degradation as per the operator policy. The relation is unblacklisted if the KPIs are degraded. The
Reason for Unblacklisting column in the Unblacklisting tab specifies whether the relation is black-
listed based on KPI degradation or timer expiry.
6. If the KPI is not degraded, the Blacklist duration is checked - it can be Ignore or 1-23.
If the time duration is selected, the relation is blacklisted based on the specified number of hours
and it is unblacklisted once the timer expires.
If the Blacklist duration is set to Ignore, only KPI based unblacklisting is performed.
4.1.2 Blacklisting based on handover

Blacklisting of intra-LTE, LTE-WCDMA, and LTE-GSM neighbors is based on the handover perfor-
mance against the user defined threshold. The rules for analyzing the performance are configurable,
and the user can blacklist based on:
• Poorly Performing Neighbors: This represents a case where several attempts are recorded but
the handover performance is not as expected. In this case, blacklisting is achieved by selecting
Minimum HO attempts in HO criteria and Maximum HO success rate in HO success
rate criteria. The handover success ratio is lower than the given threshold whereas the han-
dover attempts are higher than the given threshold.
• Rarely used Neighbors: This represents a case where low attempts are recorded even when
several attempts are successful. In this case, blacklisting is achieved by selecting Maximum HO
attempts in HO criteria and Ignore in HO success rate criteria. The handover
success ratio is higher than the given threshold but handover attempts are lower than the given
threshold.
This module also considers tier and distance to identify the poorly performing neighbors and rarely
used neighbors:
• The tier count between the source cell and the candidate must be greater than or equal to the
Minimum tier count configuration setting.
• The absolute distance (in kms) between the source and target cell must be greater than or equal
to the Minimum distance configuration setting.

Intra-LTE blacklisting requires the following KPIs to be retrieved for daily, weekly, and hourly
summarization levels: (The KPI monitor period configured for the KPI data which is available
during the last defined number of days from the module execution time will be considered for
computation.)
• Intra-LTE handover success ratio

• Intra-LTE Handover attempts
LTE-WCDMA neighbor relation blacklisting can be performed on SRVCC (Single Radio Voice Call
Continuity) and PSHO/CSFB (Packet Switched Handover/Circuit Switched Fallback) mobility types
and requires the following KPIs:
• Number of handovers from LTE to UTRAN attempts

• Handover from LTE to UTRAN success ratio
• Number of SRVCC from LTE to UTRAN attempts
• SRVCC from LTE to UTRAN success ratio
Note:
• LTE to WCDMA and LTE to GSM Handover KPIs are not available for the fALU vendor.
• KPI evaluation is ignored if the HO criteria is enabled in the module when fALU cells are
in the scope or when fALU cells are the neighbors.
For example, LTE cells in Nokia which have neighboring relations with fALU WCDMA or
GSM.
SRVCC service blacklisting sets Single Radio Voice Call Continuity allowed to
forbidden. PSHO/CSFB (Packet Switched Handover/Circuit Switched Fall-back) service blacklisting
sets PSHO allowed and Circuit-switched fall-back with PS handover allowed to
forbidden.
LTE-TD SCDMA neighbor relation blacklisting can be performed on PSHO/CSFB mobility type and re-
quires the following KPIs:
• Number of handovers from LTE to TD-SCDMA attempts

• Handovers from LTE to TD-SCDMA success ratio
The TD-SCDMA target cells are modeled as external WCDMA cells (instances of MOC EXUCE),
where the PSC (Primary Scrambling Code) is set to the otherwise reserved value 65535, that is,
EXUCE::PSC = 65535.
PSHO/CSFB service blacklisting sets PSHO allowed and Circuit-switched fall-back with
PS handover allowed to forbidden.
LTE-GSM neighbor relation blacklisting can be performed on SRVCC mobility type and requires the
following KPIs:
• E-UTRAN Inter-RAT HO Attempts to GERAN SRVCC

• E-UTRAN Inter RAT HO GERAN with SRVCC Success Ratio

SRVCC service blacklisting sets Single Radio Voice Call Continuity allowed to
forbidden.
In the UI, users should be able to configure the percentage value of the Reliability Threshold. This
threshold should be considered during KPI retrieval such that the duration for which KPIs are available
should be compared against the reliability threshold. If the total sum of the period duration is less than
the (monitor period * KPI reliability threshold) then the KPI should be considered as missing and the
corresponding neighbor relation should be excluded from blacklisting and cleanup.
For example, if the monitor period is 1 day (24 hours or 1440 minutes) and the KPI reliability thresh-
old is 80%, then the sum of the durations for a given KPI should be greater than 19.2 hrs (24 * 0.8) or
1152 minutes (1440 * 0.8), so that the KPI is considered for evaluation. The KPI reliability threshold is
a common threshold across all the KPIs used for blacklisting and cleanup, and has to be used for all
KPIs individually.
4.1.3 Blacklisting based on tier and distance

If handover KPIs are not available, blacklisting of intra-LTE neighbors, LTE-WCDMA, and LTE-GSM
relations can be done based on tier and distance against the user defined threshold.
• Distance indicates the distance between the source cell and target cell. If the source cell and tar-
get cell have multiple antenna locations, the distance from all the antenna locations is calculated
and the minimum value is returned.
• Tier Count indicates the tier count between the source cell and target cell. If the cell coverage type
is indoor, then the tier count can be +1.
The Tier Count between the source cell and the candidate must be greater than or equal to the
• Set Ignore in HO criteria and HO success rate criteria.
4.1.4 Blacklisting based on PRACH non-reachable neighbors

PRACH defines the maximum possible size for a cell, that is, till what distance the cell can receive
user calls and accommodate user requests. If a user tries to access the cell from a distance (which
is not allowed by PRACH cell size), the user cannot gain access, resulting in the degradation of the
network and the user's service performance, as well as HO failures. This feature enables you to find
the neighbor relations which have been created due to the inconsistency between the PRACH cell
size configuration and the actual cell coverage, and blacklist the relation from further usage by setting
PRACH based blacklisting to Yes in the GUI.

Note: The relation will be blacklisted only if all the provided constraints such as Tier,
Distance, HO attempts, HO success, and Expected Cell Range (PRACH based) are met. If
any constraint is set to Ignored, that constraint will not be considered during blacklisting.
4.1.5 Unblacklisting
Currently, KPI based verification and unblacklisting is available using the
ANR_Blacklisting_and_Cleanup_LTE module.
Blacklisting and cleanup instances are designed to run continuously in closed loop, with verification
carried out every hour. KPI_Time_Window_Eval is the parameter in the configuration file
that defines the period. When rollback occurs, it unblacklists all the relations blacklisted by the
ANR_Blacklisting_and_Cleanup_LTE instance in the previous verification period.
• KPI based verification and unblacklisting works only in closed loop.

• Verification works on the same target cells on which ANR_Blacklisting_and_Cleanup_LTE was
started.
• KPIs with 1 hour granularity are used.
• KPI reliability is not checked for KPI based verification and unblacklisting.
• The module only supports (as KPI inputs for verification and unblacklisting) cell level KPIs and not
relation level KPIs. Drop call rate is the KPI most affected by neighbor blacklisting.
Unblacklisting based on time
The duration for which a neighbor relation has to be blacklisted can be specified in Blacklist
duration. The blacklisted neighbor relation is eligible for unblacklisting only after the elapse of the
blacklist duration. The unblacklisted relation can be blacklisted again. The user can increase the
blacklist duration to the Increased blacklist duration of neighbor relations that have been
consecutively blacklisted and unblacklisted to a value greater than the specified value of Increased
blacklist trigger count.
To disable time based unblacklisting, set Ignore in the Blacklist duration. Once time
based unblacklisting is ignored, relations are unblacklisted based on KPIs. Relations can also be
permanently blacklisted by setting Permanent in the Increased blacklist duration to avoid
ping pong behavior.
Unblacklisting when amleAllowed is true
During unblacklisting, when amleAllowed is set to True for a relation, handoverAllowed is set to
Allowed and removeAllowed is set to False.
4.1.6 Cleanup based on handover

The ANR Blacklisting and Cleanup LTE module removes neighbor relations from LTE ANR neighbor
lists if Deletion of neighbors is selected in the use case selection.

Removal of intra-LTE neighbors is based on the handover performance against the user defined
threshold. The rules for analyzing the performance are configurable and the user can blacklist based
on:
• Poorly Performing Neighbors: represent a case where several attempts are recorded but handover
performance is not as expected. Blacklisting can be achieved by selecting Minimum HO at-
tempts in HO criteria and Ignore in HO success rate criteria. The Handover suc-
cess ratio is lower than the given threshold whereas the handover attempts are higher than the
given threshold.
• Rarely used Neighbors: This represents a case where low attempts are recorded even when more
attempts are successful. Blacklisting can be achieved by selecting Maximum HO attempts in
HO criteria and Ignore in HO success rate criteria. The handover success ratio is
higher than the given threshold but handover attempts are lower than the given threshold.
It also considers tier and distance to identify the poorly performing neighbors:
• The Tier Count between the source cell and the candidate must be greater than or equal to the
If the relation is blacklisted or blocked, the module will not remove such relations.
For all neighbors identified for removal, the module keeps track of consecutive removals and checks if
the neighbor has been removed by the module previously.
If the number of removals reaches the configured threshold value over a configured period, the mod-
ule blacklists the neighbor instead of removing the neighbor from the neighbor list.
Maximum number of repeated neighbor removal is the neighbor relation deletion count of
a cell which the module monitors, and if it exceeds the defined number during the defined neighbor
removal monitoring period, that is, Neighbor removal monitoring period, the neighbor is
blacklisted instead of being removed.
Note: If the neighbor is blacklisted instead of being removed, the module generates two sep-
arate plans - one for blacklisting and another one for cleanup.
4.1.7 File Based Blacklisting, Unblacklisting and Clean-up

Blacklisting, unblacklisting, neighbor deletion file is the UI option where the user can import the
file on which the blacklisting operations are to be performed. An example of a neighbor relation file
(CSV file) that can be imported for the module to list neighbor cells to be blacklisted, unblacklisted, or
removed is described in Table 8: Example of a neighbor relation file.
Source cell Target cell Status
LCH48857B21 LCH32931A31 blacklist
LCH48857B11 LCH32931A11 unblacklist

Source cell Target cell Status
LCH48857B11 LCH32931A21 delete
Table 8: Example of a neighbor relation file
Each row is a neighbor relation. The first cell name corresponds to the source cell. The second cell
name corresponds to the target cell that needs to be blacklisted, unblacklisted, or removed from the
neighbor list.
X2 blacklisting can be performed on a neighbor eNodeB when:
• X2 Blacklisting is enabled in the GUI.

• a neighbor relation file is uploaded.
• there are no remaining neighbor relations between the source site and neighbor site after all the
neighbor relations in the neighbor relation file are removed.
4.1.8 Cross OSS

The ANR Blacklisting and Cleanup LTE module supports the optimization of neighbor relations across
OSS boundaries. When LTE cells or eNodeBs belong to multiple OSSs in the target, separate plans
are generated and sent to each OSS.
4.1.8.1 Cross OSS support for ANR Blacklisting and Cleanup LTE (with NAdC)
The ANR Blacklisting and Cleanup LTE module supports the optimization of neighbor relations across
OSS boundaries.
When configuring a cross OSS instance:
• Select LTE cells that stretch over the OSS boundary.

• Send the generated plan with neighbor blacklisting, unblacklisting, or removals to NAdC. NAdC
splits the plan per OSS and sends them to the respective OSS for provisioning.
4.1.8.2 Cross OSS support for ANR Blacklisting and Cleanup LTE (without NAdC)
The ANR Blacklisting and Cleanup LTE module is not enhanced to support Cross OSS functionality
without NAdC integration.
4.2 LTE ANR Frequency Rules algorithm

The main purpose of the LTE ANR Frequency Rules module is to create or delete inter-frequency re-
lated object creation in the network. These objects are required to support inter-frequency handoffs
(LTE or IRAT) as well as idle mode mobility. Support for the creation and deletion of the objects is
based on the distance or tier based search as well as based on the plan based frequencies to be pro-
vided via a CSV file.

When the operator introduces a new frequency layer in the LTE network, the new LTE Inter-frequen-
cy neighbors are created only after the network directs the UEs to monitor these inter-frequencies. The
eNodeB can direct the UE to monitor inter-frequencies only if the respective inter-frequency objects
are created by the LTE ANR Frequency Rules module. Then the inter frequency UE based ANR and
idle mode mobility begin to function in the network. In the Nokia LTE network, LNHOIF and IRFIM ob-
jects need to be created and sent to the eNB if Inter-LTE frequencies have to be monitored.
This section explains the following topics:
• Frequency rule creation through user distance input

• Frequency rule creation or deletion through user CSV input
• Frequency rule deletion through user distance input and LMS
• Frequency rule update through LMS
• Frequency rule creation based on instance ID
• Blacklist and whitelist frequencies through user CSV input
• LMS support for LTE ANR Frequency Rules
4.2.1 Frequency rule creation through user distance input

Frequency rule creation is the primary functionality of this module. For the given target cells, the mod-
ule obtains all the neighbors in the given radius, and if the LMS permits the creation of inter-frequency
objects, it creates the appropriate object for the target cell.
For each target LTE cell, it retrieves all the neighbors (Intra-LTE, LTE-WCDMA and LTE-GSM)
in the given Inter Frequency neighbor radius from the target cell and filters the existing
inter-frequency objects for the target. The module checks if there are any frequency objects for this
neighboring cell frequency, and if the LMS configuration allows a new frequency object under the
target cell for this neighboring frequency. If frequency objects do not exist, it generates a Managed
Object DN and creates the frequency object of the neighboring frequency, as long as it does not
exceed the maximum number of that object.
4.2.2 Frequency rule creation or deletion through user CSV input

Managed objects for frequency rules can also be created or deleted by providing a CSV file input. The
CSV file should contain a comma separated list of source cells and target cells (using the cell's label)
in each row.
Users can import the object deletion file under the Frequency Object Deletion File option. They can
import the object creation file under the Frequency Object Creation File option in the GUI.
An example of the frequency object creation file (CSV file) that can be imported for the LTE ANR Fre-
quency Rules module to list the frequency objects to be created in the source cell for the frequency of
the corresponding target cell is defined in Table 9: Example of frequency object creation file format.
Source cell Target cell
LCH48857B21 LCH32931A31

LCH48857B11 LCH32931A11
Table 9: Example of frequency object creation file format
Each row is a cell pair - the first cell name corresponds to the source cell; the second cell name corre-
sponds to the target cell. Frequency objects are created if the LMS configuration file allows creation of
objects across frequency layers.
An example of the frequency object deletion file (CSV file) that can be imported for the LTE ANR Fre-
quency Rules module to list the frequency objects to be deleted in the source cell for the given fre-
quency is defined in Table 10: Example of frequency object deletion file format.
Frequency channel
Source cell Technology Frequency band
number
LCH48857B21 4G 19500
LCH48857B11 3G 1000
LCH48857B31 2G 513 gsm1900
Table 10: Example of frequency object deletion file format
Each row consists of the cell name, technology, frequency channel number, and frequency band (for
2G technology only), depending on the technology.
In the following cases, the LTE ANR Frequency Rules module does not take any action and the output
report file includes the following reasons:
• Source or target cells in the file cannot be found in the network

• Invalid row in CSV (missing or extra columns)
• Version of source cell is not supported by the module
4.2.3 Frequency rule deletion through user distance input and LMS
For the given target cells, the LTE ANR Frequency Rules module obtains all the neighbors in the giv-
en radius, and if the LMS does not permit the creation of inter-frequency objects, it deletes the exist-
ing frequency object for the target cell. If the target cell has a frequency relation which is not part of the
neighbor cell frequency, the frequency relation is deleted.
For each target LTE cell, it retrieves all the neighbors (Intra-LTE, LTE-WCDMA and LTE-GSM) in the
given Inter Frequency neighbor radius from the target cell. If any of the existing frequency objects
have frequencies outside the given radius, the frequency objects are deleted. The LTE ANR Frequen-
cy Rules module checks if there are any frequency objects for this neighboring cell frequency, and if
the LMS configuration does not allow the frequency object under the target cell, the frequency object is
deleted.

4.2.4 Frequency rule update through LMS

For the given target cells, the LTE ANR Frequency Rules module obtains all the existing frequency
objects. If the Parameter enforcement GUI parameter is set to Audit_and_Enforce, the
parameters of the existing objects are updated as per the LMS template.
For each target LTE cell, it retrieves all the neighbors (Intra-LTE, LTE-WCDMA and LTE-GSM) in
the given Inter Frequency neighbor radius from the target cell. The LTE ANR Frequency Rules
module then obtains all the existing objects for the target cell. If the Parameter enforcement GUI
parameter is set to Ignore, the existing parameters are not updated. However, new frequency objects
are created with the LMS template.
4.2.5 Frequency rule creation based on instance ID

For the given target cells, the LTE ANR Frequency Rules module obtains all the neighbors in the
given radius. Based on the Rule based ID check GUI parameter, the module tries to create the
frequency rule for the frequency with the corresponding instance ID provided in the LMS template.
Note: This feature is supported only for intra-LTE and LTE-WCDMA connected and idle
mode objects. It is not supported for LTE-GSM and FreqRDRT objects.
If the Rule based ID check GUI parameter is set to Ignore, the LTE ANR Frequency Rules
module falls back to the sequential ID based creation of frequency rules.
If the Rule based ID check GUI parameter is set to Skip (if any frequency is already existing
with a different instance ID or if the instance ID is used by another existing frequency), the LTE ANR
Frequency Rules module skips such cases and only tries to perform the creation of frequency rules
based on the given instance ID for non-conflicting frequencies. For conflicting frequencies and for
frequencies where no instance ID is mentioned in the LMS template (that are not already created), the
LTE ANR Frequency Rules module follows sequential ID based creation of frequency rules.
If the Rule based ID check GUI parameter is set to Delete_and_Recreate, even if there are
conflicting frequency rules existing, the LTE ANR Frequency Rules module tries to delete and recreate
the same with the required instance ID.
The MO types supported for instance ID based creation are LNHOIF, IRFIM, LNHOW, and UFFIM. In
the corresponding LMS template, the instance ID must be given in the format <MO_NAME>ID.
For example: LNHOIFID, IRFIMID, LNHOWID, UFFIMID
For LNHOIF, IRFIM, and LNHOW, ensure that no two frequencies are requesting the same instance ID
in the LMS template.
For UFFIM, all frequencies must request the same ID as only one MO (that can have multiple frequen-
cies) is created.
Note:
• The instance ID must be a non-negative value. If a negative value is provided as the in-
stance ID, the corresponding positive value is used instead.

• For any whitelisted frequency, instance ID based creation is not supported. If a frequen-
cy requests an instance ID that is already existing for a whitelisted frequency, instance ID
based creation is skipped for that frequency.
4.2.6 Blacklist and whitelist frequencies through user CSV input

You can whitelist and blacklist frequencies by using a CSV file. The CSV file must contain a comma
separated list of source cells, frequencies to be whitelisted or blacklisted, technology, and whitelist/
blacklist in each row.
Users can import the whitelist blacklist CSV file using the Frequency Object Deletion File option.
They can import the object creation file using the White list and Black list target
frequencies file GUI parameter.
An example of the whitelist blacklist file (CSV file) that can be imported for the LTE ANR Frequency
Rules module to list the frequencies to be whitelisted or blacklisted for the source cell is defined in Ta-
ble 11: Example of whitelist blacklist file.
Source cell Frequency Technology Whitelist/Blacklist
LCH48857C11 10640 4g white
LCH48857C11 1060 3g black
LCH48857B11 12 2g white
Table 11: Example of whitelist blacklist file
Frequency objects are created if the LMS configuration file allows the creation of objects across fre-
quency layers.
Note:
• LMS has the highest priority. In case a whitelisted frequency is not allowed in the LMS,
the frequency object is not created for that frequency. For a blacklist, the frequencies are
deleted irrespective of the LMS.
• If the same frequency is provided in both the whitelist and the blacklist, that frequency is
not considered for either operation.
• The whitelist blacklist CSV file must not be provided when the CSV based creation and
deletion file is provided.
4.2.7 LMS support for LTE ANR Frequency Rules

The LMS is used by the LTE ANR Frequency Rules module to check if there is a rule allowing the cre-
ation of frequency objects between two frequencies.
The LMS configuration file defined here is specific to the LTE ANR Frequency Rules module.

For example, to create frequency rules under existing LTE cells for a newly introduced frequency layer
such as 19500 for only LTE connected mode objects.
The layers are defined as follows:
"layers": { "LTE": { "technology": "LTE" }, "F19500": { "earfcn": 19500

}}
The rules allowing the creation of frequencies from LTE to frequency layer 19500 are as follows:
"rules": { "*": { "LTE": { “frequency_relations”: {"F19500":

{"condition" :
{"name":”lnhoif_object”, "hop":{ "template": "LTE_F19500" } } }
} }
Define target filter for the required target frequency objects:
"filters": {“lnhoif”: {“target”: “LTEConectedMode”}}
The conditions are defined as below:
“conditions”: {“lnhoif_object”:{ “target”: { “filter”: “lnhoif” } }

}
To define a template to set attribute values for the created frequency objects, define the attribute and
its values as follows:
"templates": {"LTE_F19500": {"measurementBandwidth": "mbw100"} }
If the attribute name specified in the template is applicable to the frequency object being created (in
the above example, LTE - LNHOIF, LNHOIF frequency objects are created), the value specified in the
template is used instead of the default value configured in the module template file for that object.
4.3 ANR-4G IRAT algorithm

This module performs the following functions for LTE IRAT neighbor lists:
• Detects missing relations and adds them

• Evaluates existing relations for potential replacement through detected missing relations (if the
neighbor list is already at or above the defined limits)
• Enforces the operator layer management strategy and attribute values for new neighbor relations
The ANR 4G IRAT algorithm explains the below concepts:
• Tier counting and geo-scoring

• LMS configuration
• Cross OSS
• Neighbor trimming

• Whitelisting and blacklisting

• Neighbor additions
• Neighbor replacements
• KPI reliability
The default time between iterations of the module running and pushing changes in closed loop is 15
minutes. However, the configuration parameter TimeBetweenPushes_15Mins can be modified to
limit how often this module runs after pushing changes. TimeBetweenPushes_15Mins = 4 means
the module pushes changes a maximum of once per hour in closed loop.
4.3.1 Tier counting and geo-scoring

The ANR-4G IRAT module employs advanced tier counting and geo-scoring to evaluate potential
missing neighbors. Tier counting and geo-scoring provide fundamental components for:
• determining missing neighbors.

• deleting distant or erroneous neighbors.
Tier counting identifies the number of tiers between every source cell and all neighbors or potential
neighbors (within a reasonable range). When polygons are created for tier counting, a first tier neigh-
bor shares a polygon boundary with the source cell, a second tier neighbor shares a boundary with a
first tier neighbor to the source cell and so on.
Geo-scoring is a method of quantifying the degree of radio frequency coupling or isolation between
two or more cells based on the coverage area and antenna relationships between the cells of interest.
Tier counting and geo-scoring use cell locations and antenna information from the cell plan data. This
information is mandatory for every cell in the area under optimization.
Note:
• Distance indicates the distance between the source cell and target cell. If the source cell
and target cell have multiple antenna locations, the distance from all the antenna loca-
tions will be calculated and the minimum value will be returned.
• Tier Count indicates the tier count between the source cell and target cell. If the cell cov-
erage type is indoor, then the tier count can be +1.
• Co-site cells: all the cells that share the same site_id from cell_plan data. Tier count for
co-site cells is 1.
• Co-sector cells: Among co-site cells, all the cells that face the same azimuth direction
(+/- 20 degree) are considered as co-sector cells. For co-sector cells, the tier count is 0.
• If the source and target cells are in the same location (for example, co-site, or two sites
in the same location with different site IDs) then distance is shown as 0 in the report.
4.3.2 LMS configuration

The LMS configuration details the frequency layers in each technology (LTE, UMTS, GSM) and the
rules for the allowed neighbor definitions from each LTE frequency layer to the IRAT frequency lay-

ers. The frequency layers for UMTS are determined either by pattern matching using the cell name or
else from the UARFCN (UTRA Absolute Radio Frequency Channel Number). The frequency layers for
GSM come from pattern matching using the cell name or else from the band information determined
from the CM data.
It is possible to define Max Neighbor Size conditions in the LMS configuration which can be used,
for example, to limit the number of LTE to UMTS relations allowed to a specific UARFCN, or limit the
number of LTE to GSM relations allowed to a specific GSM band.
The permissible LTE to UMTS relations and LTE to GSM relations must be defined in the LMS configu-
ration to ensure that the LMS enforcement module does not remove existing relations.
Note:
• In case both LMS based trimming and Enable_Trimming are true, LMS based trim-
ming will happen only if Max Neighbor Size exists.
• If LMS based trimming is true and Max Neighbor Size exists in the LMS, even the
first tier and co-site or co-sector can be removed.
• During IRAT neighbor addition, if Max Neighbor Size exists in the LMS, the module
will add the relation till Max Neighbor Size reaches the target cell, irrespective of the
module configuration.
4.3.3 Cross OSS

This section describes the cross OSS support for ANR 4G IRAT.
4.3.3.1 Cross OSS support for ANR 4G IRAT (with NAdC)
The ANR 4G IRAT module supports the optimization of neighbor relations across OSS boundaries.

• Send the generated plans with neighbor additions, removals, or changes to NAdC. NAdC splits
the plan per OSS and sends them to the respective OSS for provisioning.
• AC creates external cells in the source OSS, if required.
ANR 4G IRAT instances that stretch over OSS boundaries between different vendors are also support-
ed.
To support cross OSS:
• The LMS file must contain separate LMS definitions per OSS.
• The OSS name must be specified at the beginning of each LMS configuration in the file.
The module configuration supports separate parameter settings per vendor for a few parameters.
4.3.3.2 Cross OSS support for ANR 4G IRAT (without NAdC)
The ANR 4G IRAT module supports the optimization of neighbor relations across OSS boundaries.


• Generate separate plans with neighbor additions, removals, or changes and send them to each
OSS.
• Create external cells in the source OSS, if required.
ANR 4G IRAT instances that stretch over OSS boundaries between different vendors can also be sup-
ported.
To support cross OSS:
• The LMS file must contain separate LMS definitions per OSS.
• The OSS name must be specified at the beginning of each LMS configuration in the file.
The module configuration supports separate parameter settings per vendor for a few parameters.
4.3.4 Neighbor trimming

Before any optimization of neighbors is performed, a separate trimming process is initiated for cells
where the number of neighbor relations exceeds configured limits. The parameter Enable_Trimming
controls the operation of the neighbor trimming functionality.
The trimming function attempts to trim relations to all defined limits

(LTE_IRAT_Neighbor_List_Size_2G and LTE_IRAT_Neighbor_List_Size_3G). If it is
successful and none of these configured limits are exceeded after trimming, the cell is optimized in
the same iteration of ANR. In rare cases where trimming is not successful, meaning any of these
configured limits are still exceeded, the cell is skipped with a warning message to the log and is not
optimized by ANR.
Note:
LTE-GSM trimming is per band and LTE-WCDMA trimming is per UMTS target frequency.
4.3.5 Whitelisting and blacklisting

Within EdenNet, whitelisting indicates that the whitelisted cell will always be a neighbor and if it is not
defined, you must add a relation. Blacklisting indicates that the blacklisted cell will never be a neigh-
bor and if it is already defined, it should be removed. Manual whitelisting and blacklisting functionality
is supported via the Administration > Black and White List tab in the GUI. For each cell that is se-
lected, the IRAT relations to be whitelisted or blacklisted can be added or removed via the map inter-
face. Blacklisted and whitelisted relations can also be imported via a CSV file. The file can use one of
two formats:
• IDN based: This format is defined in Table 12: IDN based file.
Source Target Type
LTE-7222540 LAC-10026/CID-34753 black

Source Target Type
LTE-7222540 RNC-186/CID-53319 black
LTE-7222540 LAC-10026/CID-34751 white
LTE-7222540 RNC-186/CID-53314 white
Table 12: IDN based file
• Cell name based: This format is defined in Table 13: Cell name based file.
Source Target Type
Rescaldina Sud Est SSI-012 MI34753 black
Rescaldina Sud Est SSI-012 MI53319 black
Rescaldina Sud Est SSI-012 MI34751 white
Rescaldina Sud Est SSI-012 MI53314 white
Table 13: Cell name based file
4.3.6 Neighbor additions

At each execution, the module iterates all the source cells and attempts to add or replace neighbors as
required.
Note:
If the source cell is an Ericsson pico cell, GSM target cells will not be considered for evalua-
tion.
For all neighbor additions, a maximum tier limit and maximum distance limit are enforced. A check is
also performed to ensure that scrambling code conflicts are not introduced for the added 3G relations,
or BCCH (Broadcast Control Channel) + BSIC (Base Station Identity Code) conflicts for the added 2G
relations.
The steps below are repeated for each 3G and 2G frequency layer as per the layer management strat-
egy:
1. Missing white-listed neighbors: The module always attempts to add all whitelisted relations. If there
is no room on the neighbor list to add a whitelisted neighbor, then an attempt is made to remove an
existing neighbor from that 3G or 2G frequency layer to make way for the new relation.
2. Missing first tier neighbors identified: The module always attempts to add all cells identified as
missing first tier neighbors - this applies to all relations classified as first tier neighbor. The tier-
map used is based on the frequency layer for the missing IRAT (3G or 2G) neighbor. If there is no
space on a neighbor list to add missing first tier neighbors, an attempt is made to remove an exist-

ing neighbor from that 3G or 2G frequency layer to make way for the new relation. These relations
are called First Tier Neighbor adds in the output report.
3. Additional neighbor adds (based on 3G or 2G co-sectors to top intra-frequency LTE neighbors):
The module attempts to add missing IRAT neighbors based on intra-frequency LTE handovers.
Only LTE intra-frequency neighbors above a threshold for the minimum number of intra-frequency
handover successes are considered. The potential candidates are then ranked based on handover
success counts from the source cell to its intra-frequency LTE neighbors. The co-sector 3G and
2G cells to these LTE neighbors are then taken. Candidates are selected from the second tier up
to the configurable maximum tier limit. The tier-map used is based on the frequency layer for the
candidate IRAT (3G or 2G) neighbor. If there is no space on a neighbor list to add neighbors, an at-
tempt is made to remove an existing neighbor from that 3G or 2G frequency layer to make way for
the new relation. These are called Neighbor Co-sector adds in the output report.
Note: If the KPIs of the co-sector neighbor are not above the defined threshold, they are
not added to the list of co-sectors. In this case, the neighbor is evaluated next based on
the geo-score. It is added and represented as tier 2+ neighbors.
4. Additional neighbor adds (network topology based): The module attempts to add the top candidate
missing neighbors based on network topology.
Note:
• Extended First Tier neighbors are added when there are additional first tier neighbors
outside the maximum count of the Absolute First Tier neighbors (reporting catego-
rization). In case of neighbor removal between the first tier and the extended first tier,
extended first tier neighbors take precedence.
• If the Limit_no_of_detected_neighbors parameter is set to Yes,
the number of topology based detected neighbors is limited based on the
Buffer_for_detected_neighbours parameter.
For LTE to GSM addition, the count of the Maximum LTE - GSM neighbor
size is derived from the lte_irat_neighbor_list_size_2g parameter
that can be added for a cell and the count of the existing LTE-GSM neighbors
for a cell. The remaining neighbors are calculated by subtracting the Max LTE
- GSM neighbor size and Existing neighbor for a cell. Once the
remaining neighbors are identified for LTE-GSM, the buffer is added based on
the Buffer_for_detected_neighbours parameter, to limit topology based
detection.
For example, if the source cell has 20 LTE-GSM IRAT relations, the
lte_irat_neighbor_list_size_2g parameter is set to 32, and the
Buffer_for_detected_neighbours parameter is set to 20, the detected
neighbors for topology based addition are limited to:
Max LTE-GSM list size - Existing relation + Buffer for

detected neighbors

32 – 20 + 20 = 32
The slot is reduced if first tier, whitelisted, or HO based detected neighbors are
present. If topology based (tier 2+) relations already exist, the slot is further reduced.
For example, consider that 5 first tier, 2 white listed and 1 HO based detected neigh-
bor are present. For the same scope cell, there are 2 topology based relations which
are also detected. In this case, detected neighbors are:
Max LTE-GSM list size – (Existing relation + Detected 1st

tier + detected whitelisted + detected HO based) + Buffer for
detected neighbors
32 – (20+5+2+1)+ 20 = 22
It fetches 22 tier 2+ neighbors for the scope cell. It will skip the 2 existing topology
based relations. It will populate 20 topology based neighbors for the scope cell in the
detected sheet.
For LTE-WCDMA, calculations are done per frequency level.
The potential candidates are ranked based on a Cell Coupling Score that is based on the tier
count, distance, and geo-scores. Candidates are selected from the second tier up to the config-
urable maximum tier limit. The tier-map used is based on the frequency layer for the candidate
IRAT (3G or 2G) neighbor. When there is no space on a neighbor list to add neighbors, an attempt
is made to remove an existing neighbor from that 3G or 2G frequency layer to make way for the
new relation. These are called Tier 2+ Neighbor adds in the output report.
Note:
There is a limit built into the module which allows relations to be defined to a maximum of
6 distinct UARFCNs.
4.3.7 Neighbor replacements

Removal of an existing IRAT neighbor to create space on the neighbor list for a new cell can occur for
any neighbor add scenario. The priority for determining which existing IRAT neighbor should be re-
moved to make room for the neighbor addition is as follows:
1. IRAT Neighbor with the same UARFCN + SC for 3G or the same BCCH + BSIC for 2G as the pro-
posed addition
2. IRAT Neighbor with the lowest number of IRAT handover successes in the previous 24 hour period
When an attempt is made to remove an existing IRAT neighbor for replacement by a new IRAT neigh-
bor, the following conditions must be met:
• The existing IRAT neighbor is not whitelisted, co-sited, or a first tier.

• LTE IRAT handover successes to existing neighbors in this period must be available in the PM da-
ta (for at least 16 of the previous 24 hours) and the number of successes must not exceed the de-

fined threshold for removal (LTE_IRAT_Max_HO_Successes_For_Nbr_Removal). Setting the

configuration parameter LTE_IRAT_ho_success_available = FALSE bypasses this condi-
tion (must be done for ALU networks as no LTE IRAT handover success counts per relation are
available).
• LTE intra-frequency handover successes to the LTE cell which is co-sector to the
existing UMTS or GSM cell must not exceed the defined threshold for addition
(LTE_IRAT_Min_LTEintraFreq_HO_Success_For_Cell_Add). This condition exists to pre-
vent cyclical additions or removals in repeated executions of the module.
For IRAT neighbor replacement based on intra-frequency LTE handovers, the below additional criteria
must be met:
• The number of LTE intra-frequency handover successes to the LTE cell which is co-sector to the
candidate UMTS or GSM cell must outperform the existing neighbor by a defined Outperform Mul-
tiplier (LTE_IRAT_Outperform_Multiplier set through the user interface at run time).
For IRAT neighbor replacement based on network topology, (tier count and geo-scores), the below ad-
ditional criteria must be met:
• The combined score (calculated from tier count and geo-scores) for the proposed neighbor addi-
tion must exceed the combined score calculated for the existing neighbor being replaced.
If these criteria cannot be met, the IRAT neighbor with the next lowest number of neighbors, which
meets all the removal criteria, is tried. In case there are multiple IRAT neighbors with zero handover
successes in the previous 24 hour period, those with the highest tier count are selected first, then
those with the lowest cell coupling score within the same tier are selected.
Note: The module will remove the unused LNADJGs and LNADJWs only when Optimize
4G to 2G neighbor relations and Optimize 4G to 3G neighbor relations
are enabled. The unused LNADJGs and LNADJWs can be removed either as part of neigh-
bor replacement or as part of neighbor trimming.
4.3.8 KPI reliability

The KPIs used in the ANR_4G_IRAT module are evaluated against the
KPI_data_reliability_threshold configuration parameter. All the KPIs used are evaluated
against this same reliability threshold.
For example, if a KPI is retrieved for the last 24 hours (1440 minutes), and the KPI reliability threshold
is 50%, then the duration of KPI periods with valid data should be greater than 12 hours (24 * 0.5) or
720 minutes (1440 * 0.5).
Neighbor removals
• Neighbor trimming logic: While finding the bottom neighbor for trimming, the HO success count
(from the source cell to the neighbor) is checked for reliability. If it is reliable, it can be marked for
removal. If the KPI is found to be unreliable, the next bottom neighbor is considered for trimming
till a suitable bottom neighbor is found.

• In the Final Neighbors tab of the Output Report, Cannot Remove Reason is updated with the
message HO Success KPI is not reliable where this is applicable.
Neighbor additions
• Additional neighbor adds – based on 3G or 2G co-sectors to top intra-frequency LTE neighbors:

While adding neighbors based on intra-frequency LTE handovers, a reliability check is carried out
to add neighbors with reliable KPIs. If the KPIs are found to be unreliable, the relation is skipped
and is not added.
With the default value of zero, KPI reliability is bypassed. To enforce KPI reliability, set a value greater
than zero.
4.3.9 Configuring relation DN ID for Ericsson (4G)
An optional INI parameter (Configurable_relation_Id) is added. This parameter can be

configured with any combination of CM parameters to be used as the relation DN ID. At present,
this parameter is only valid for Ericsson in an AC based scenario. As this feature only deals with
configuring relation DNs (RDNs), external cells and internal cells are handled the same way. The ANR
4G IRAT module only deals with proposing relations to external cells and not with the creation of such
cells (creation is handled by NAdC).
This parameter will be a dictionary with the following structure:
Configurable_relation_Id= {
"LTE": {
"LTE_to_WCDMA_relation_Id": "value",
"LTE_to_GSM_relation_Id": "value"
Note: The entire dictionary must be written in a single line.
The following parameters must be configured
• LTE_to_WCDMA_relation_Id
• LTE_to_GSM_relation_Id
The value of these parameters is verified when the INI file is imported into the GUI. The following are
checked in GUI validation:
• If the file is empty, an error message is displayed.

• The value of the Configurable_relation_Id parameter must be a proper dictionary. If the
structure is incorrect, an error message is displayed.

• The parameter must only contain the keys defined for each technology. Illegal keys must not be
present.
• The parameter must contain one of the following valid keys (or else an error message is dis-
played):
– LTE_to_WCDMA_relation_Id
– LTE_to_GSM_relation_Id
• After the above conditions are verified, the parameter values are verified syntactically. An error
message is displayed if they are syntactically wrong.
The value is verified syntactically based on the following rules:
• Each CM parameter must be enclosed within angle brackets (< and >)
For example: <mcc>, <mnc>
– The name specified within angle brackets must be a correct CM parameter name. (validated
during the ANR 4G IRAT module run)
– Any number of CM parameters can be specified in the INI parameters which may or may not
be separated by delimiters.
For example: <mcc><mnc><rncId> or <mcc>_<mnc>_<rncId>

• Only the following delimiters can be used to separate the CM parameters placed within angle
brackets:
[ "-", "_", "+"], for example, <mcc>_<mnc>
– It is not necessary to use the same delimiter in the entire parameter value. Any combination of
delimiters can be used.
For example: <mcc>_<mnc>-<rncId>+<cellId> or <mcc>+<mnc>+<rncId>+<cellId>

– Spaces are not allowed in the configurable RDN ID.
• Other alphanumeric characters can also be mentioned in the INI parameter. The ANR 4G IRAT
module uses these characters while building the value part of the RDN:
– The alphanumeric part can be specified anywhere in the INI parameter value except in be-
tween the angle brackets.
For example: "abc<mcc>_<mnc>" or "ABC<mcc>+Qwe1<mnc>zxc"
The characters "ABC", "Qwe1", "zxc" are placed as is in their respective positions in the final
parsed value for the RDN ID.
– If the parameter contains any keys other than the specified ones (at any level), GUI validation
fails and an error message is displayed.
• The value can also be set to the instance ID of the source cell or the neighbor cell:
– For the instance id of the source cell, use <Source_Instance_Id>

– For the instance id of the neighbor cell, use <Target_Instance_Id>

If the INI file is verified and imported, the ANR 4G IRAT module searches for the configured CM para-
meters during execution, firstly in the neighbor cell object or else in the CM cache.
If the configured CM parameters are still not found, or if the CM parameter names are incorrect, the
default values are used. The default values are different for different technologies and relation types,
as described in Table 14: Default values for relation DN IDs for ANR 4G IRAT:
Module name Parameter name Default value Description
ANR 4G IRAT LTE_to_WCDMA_ OSS RC ENM Relation ID of the

relation_Id LTE to WCDMA
This is the last el- This is the last el-
ement in the FDD ement in the FDD relation MO.
cell's DN: cell's DN:
<ExternalUtran- <ExternalUtran-
CellFddId> CellFddId>
This is the last el- This is the last el-

ement in the TDD ement in the TDD
cell's DN: cell's DN:
<ExternalUtran- <ExternalUtran-
CellTddId> CellTddId>
LTE_to_GSM_re- This is the last el- This is the last el- Relation ID of the
lation_Id ement in the cell's ement in the cell's LTE to GSM rela-
DN: DN: tion MO.
<ExternalGeran- <ExternalGeran-
CellId> CellId>
Table 14: Default values for relation DN IDs for ANR 4G IRAT
The following assumptions are made for this feature:
• The user must populate the config parameter in the Global section of the INI file.
• The user must configure the INI parameter with a combination of CM parameters which will
resolve to a unique value for each RDN ID as the feature does not check for uniqueness.
For example:
If the user configures the INI parameter as <mcc>_<mnc>_<rncId>, this combination is not unique
for different relations of a source cell (as all three parameters can be the same for different rela-
tions). The user needs to configure it as <mcc>_<mnc>_<rncId>_<cellId>, as in this combination -
the cellId is unique for each neighbor of a source cell and hence it is also unique for the relation to
that neighbor.

LTE Automatic Neighbor Relations Guide DN09238435 1-0 LTE ANR execution
5 LTE ANR execution

LTE ANR modules can be accessed from the EdenNet application.
5.1 Prerequisites
To execute the LTE ANR modules, the following prerequisites must be met:
• Google Chrome or Mozilla Firefox Web browser must be installed on your computer.
• The required LTE ANR module license must be activated. For more information, see:
– ANR Blacklisting and Cleanup LTE: License details

– LTE ANR Frequency Rules: License details
– ANR 4G IRAT: License details
• The required LTE ANR module must be imported and integrated with the respective Element Man-
agement System (EMS) or Network Management System (NMS).
• PM data and CM data must be available:
– ANR Blacklisting and Cleanup LTE: PM data and CM data

– LTE ANR Frequency Rules: PM data and CM data
– ANR 4G IRAT: PM data and CM data
• Configuration files must be activated. For more information, see the Configuring a module section
in the EdenNet User and Administration Guide.
5.1.1 ANR Blacklisting and Cleanup LTE prerequisites

The ANR Blacklisting and Cleanup LTE module requires the following information from the cell plan for
all the cells under optimization:
• Cell location, in terms of latitude and longitude in decimal degrees

• Cell azimuth, the 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, the angle of the antenna main beam relative to the same geo-grid
reference mentioned above
The ANR Blacklisting and Cleanup LTE module requires the following information from the OSS for all
the cells under optimization:
• LTE neighbor lists

• PM counts for LTE handover attempts and successes per relationship
Tier counting and distance calculation use the cell locations and antenna information from the cell plan
data. This information is mandatory for every cell in the area under optimization.

5.1.1.1 License details
The LTE ANR module license is listed in EdenNet Licenses table.
Licensed feature com- Licensed feature compo-

LK item code LK item object name
ponent code nent name
ENSW6146CLK LTE ANR CLK 0000025969 4G ANR
Table 15: EdenNet license
5.1.1.2 PM data and CM data

For details about the CM data and PM data of the ANR Blacklisting and Cleanup LTE module, see the
below documents:
• EdenNet module specific Data for Nokia

• EdenNet module specific Data for Huawei
• EdenNet module specific Data for Ericsson
• EdenNet module specific Data for ALU
• EdenNet module specific Data for ZTE
5.1.2 LTE ANR Frequency Rules prerequisites

The LTE ANR Frequency rules module requires the following information from the cell plan for all the
cells under optimization:
• Cell location, in terms of latitude and longitude (in decimal degrees)

• Cell azimuth, the angle of the antenna main beam relative to a defined geo-grid reference (the
magnetic North)
• Neighbor cell locations, in terms of latitude and longitude (in decimal degrees)
• Neighbor cell azimuths, the angle of the antenna main beam relative to the same geo-grid
reference
Distance calculation uses the cell locations and antenna information from the cell plan data. This infor-
mation is mandatory for every cell in the area under optimization.


For details about the CM data and PM data of the LTE ANR Frequency Rules module, see the below
documents:

5.1.3 ANR-4G IRAT module prerequisites

• The ANR-4G IRAT module requires the following information from the cell plan for all the cells
under optimization (source and potential target cells):
– Cell location, in terms of latitude and longitude (in decimal degrees)

– Cell azimuth, the angle of the antenna main beam relative to a defined geo-grid reference (the
magnetic North)
– Neighbor cell locations, in terms of latitude and longitude (in decimal degrees)
– Neighbor cell azimuths, the angle of the antenna main beam relative to the same geo-grid
reference
• The ANR-4G IRAT module requires the following information from the OSS for all the cells under
optimization (source and potential target cells):
– LTE intra-frequency neighbor lists

– LTE IRAT neighbor lists
– PM counts for intra-frequency LTE handover attempts and successes per relationship
– PM counts for LTE IRAT handover attempts and successes per relationship

For details about the CM data and PM data of the ANR 4G IRAT module, see the below documents:



5.2 Configuring and executing LTE ANR modules

This section describes how to configure and execute the LTE ANR modules.
Prerequisites
• All the prerequisites mentioned in the 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. It displays 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. Select the required module:
• ANR_Blacklisting_and_Cleanup_LTE
Or
• LTE_Frequency_Rules
Or
• ANR_4G_IRAT
Expected outcome
The selected ANR module is accessed and the Configure Targets page appears.
4. To select the UMTS or 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.
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 using the toolbar on the map.
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 LTE ANR 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: In each category, you can select only one configuration file.
9. Verify the configuration and click Next.
The Execution Type page appears.
10. To schedule the module execution, do one of the following:
• Select Activate Now to activate the module immediately.

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

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

LTE Automatic Neighbor Relations Guide DN09238435 1-0 LTE ANR configuration parameters
6 LTE ANR configuration parameters

The configuration parameters required to execute the LTE ANR modules are:
• LTE ANR GUI parameters

• LTE ANR INI parameters
6.1 LTE ANR GUI parameters

This section describes the GUI parameters present in the LTE ANR modules:

• LTE ANR Frequency Rules GUI parameters
6.1.1 LTE ANR Frequency Rules GUI parameters
Table 18: LTE ANR Frequency Rules configuration parameters describes the GUI parameters of the
LTE ANR Frequency Rules module.
Default
Parameter Description Range (Min, Max) Step
value
Frequency Ob- CSV file containing the source select a file N/A N/A
ject Creation cell and target cell for frequen-
File cy objects to be created. A fre-
quency object will be created
with the frequency of the target
cell. Each line in the file has
one source cell and one target
cell. The source cell and tar-
get cell are identified by their
common names and separated
with a comma.
Note: Inter Frequen-

cy neighbor radius is
ignored when a file
is given.
Frequency Ob- CSV file containing source cell, N/A N/A N/A
ject Deletion target technology and target
File frequency (sometimes the fre-

Default
value
quency band) to be deleted.

The frequency object of the
target technology and frequen-
cy will be deleted. Each line in
the file has:
• one source cell

• one target technology (4G,
3G, 2G)
• one target frequency
• one frequency band (ap-
plicable only for 2G tech-
nology)
Source cells are identified by

their common names, and they
are separated from technology,
frequency, and frequency band
by a comma.
Inter Frequen- Inter-frequency neighbors with- 10 to 1000 10 100

cy neighbor ra- in the specified radius (km)
dius from each source cell are con-
sidered for the creation of in-
ter-frequency relations.
SON Operation Set to Open Loop to run the Open Loop, Closed N/A Open Loop
Mode module in open loop mode. Loop
Set to Closed Loop to run
the module in closed loop
mode. In Closed Loop mode,
changes are automatically
pushed to the network with-
out user intervention. In Open
Loop mode, the module does
not automatically push para-
meter changes to the network.
The user has to manually pro-
vision plans to push changes
to the network.

Default
value
Plan Name Tag Text that will be added to the Sequence which con- N/A Empty
names of all the plans that will tains any combinations
be generated by this module. of:
If the target of the module is
• Uppercase and low-
a whole specific cluster (and
ercase letters: [A-
the name of this cluster al-
Za-z]
so matches the Range), then
• Numbers: [0-9]
the cluster name will also be
• Underscore: _
added to the plan name.
The maximum length is
20 characters.
Parameter en- This parameter indicates Audit_and_Enforce N/A Ignore

forcement whether to enforce the man- Ignore
aged object parameters along
with creation and deletion of
the dedicated, idle, and redi-
rect mode frequency objects.
Rule based ID This parameter indicates the Ignore N/A Ignore

check mode of rule based ID cre-
Delete_and_Recreate
ation. When this parameter is
set to: Skip
• Ignore: The LTE ANR

Frequency Rules module
proceeds with sequential
ID based creation.
• Skip: The LTE ANR Fre-
quency Rules module
skips recreating existing
frequencies.
• Delete_and_Recreate:
The LTE ANR Frequency
Rules module deletes and
recreates the frequency
object, if required.
White list and This parameter lists the target N/A N/A N/A
Black list target frequencies for frequency ob-
frequencies file ject creation (for whitelisting)

Default
value
and frequency object deletion

(for blacklisting).
The LTE ANR Frequency

Rules module must:
• create and keep the man-

aged objects for whitelist-
ed target frequencies.
• delete and not create
the managed objects for
blacklisted frequencies.
Note: This file must

not be provided if
the CSV files for cre-
ation and deletion
are already avail-
able.
Table 18: LTE ANR Frequency Rules configuration parameters
6.1.1.1 ANR Blacklisting and Cleanup LTE GUI parameters
Table 19: ANR Blacklisting and Cleanup LTE configuration parameters describes the GUI parameters
of the ANR Blacklisting and Cleanup LTE module.
Parameter Description Range (Min, Max) Step Default
Use case selection If Blacklisting of neighbors is Blacklisting of N/A Blacklisting

selected, neighbor relations neighbors, Deletion of neigh-
are blacklisted based on UE of neighbors bors
measurements. If Deletion of
neighbors is selected, neigh-
bor relations are deleted
based on UE measurements.
Blacklisting, unblack- Blacklist or unblacklist or select a file N/A N/A

listing, neighbor dele- delete the neighbor relations
tion file of the cells using a CSV file.
• For blacklist or unblack-

list use case, there is
a CSV file containing

source cell and target

cell names, and the
blacklist/unblacklist con-
dition. Relations between
the source cell and target
cell are blacklisted or un-
blacklisted accordingly.
Each line in the file has
one source cell, one tar-
get cell, and blacklist or
unblacklist, separated by
a comma.
For example:
B7WAW205A11,
B7WAW152A31,
blacklist
• For deletion of neighbors

use case, there is a CSV
file containing source cell
and target cell names.
Target cells are removed
from the neighbor lists
of the source cells. Each
line in the file has one
source cell and one tar-
get cell for removal. The
source cell and target
cell are identified by their
common names, sepa-
rated by a comma.
For example:
B7HCH119A31,
B7HCH031A21
Note: All the user

defined parameters
(except neighbor
control parameter)
are ignored when a

CSV file is import-

ed.
Blacklist or unblacklist If Yes, then intra-LTE neigh- Yes, No N/A Yes

intra-LTE neighbor re- bor relations can be black-
lations listed or unblacklisted. If No,
then intra-LTE neighbor rela-
tions are not considered for
blacklisting or unblacklisting.
Blacklist or unblack- If Yes, then LTE to WCDMA Yes, No N/A Yes

list LTE to WCDMA neighbor relations can be
neighbor relations blacklisted or unblacklisted.
If No, then LTE to WCDMA
neighbor relations are not
considered for blacklisting or
unblacklisting.
Blacklist or unblacklist If Yes, then LTE to GSM Yes, No N/A Yes

LTE to GSM neighbor neighbor relations can be
relations blacklisted or unblacklisted. If
No, then LTE to GSM neigh-
bor relations are not consid-
ered for blacklisting or un-
blacklisting.
Minimum tier count Tier count between the 3 to 10, Ignore 1 10

source cell and the neigh-
bor cell. Neighbor cells must
be at least this number of
tiers from the source cell for
the neighboring relation to
be blacklisted. If this para-
meter is set to Ignore, then
tier count is not used to se-
lect neighboring relations for
blacklisting.
Unit is tiers.
Minimum distance Distance between the source 0.1 to 70 0.1 0.1

cell and the neighbor cell.
Neighbors available at a
distance equal to or greater

than the defined distance

from the source cell are
considered for blacklisting
and deletion. If set to 0,
distance is not considered
while selecting the neighbor
relations for blacklisting and
deletion.
Unit is kms.
HO criteria This parameter defines the Ignore, Minimum N/A Minimum

handover criteria to be used HO attempts, Maxi- HO at-
for blacklisting and deletion mum HO attempts tempts
of neighbor relations. Either
Minimum HO attempts or
Maximum HO attempts can
be used. If set to Ignore, HO
criteria is not considered to
select the neighbor relations
for blacklisting and deletion.
HO success rate cri- This parameter defines the Ignore, Maximum N/A Maximum
teria handover success rate cri- HO success rate HO success
teria to be used for blacklist- rate
ing and deletion of neighbor
relations. Either the parame-
ter can be ignored or Maxi-
mum HO success rate can
be used. If set to Ignore, han-
dover success rate criteria is
not considered to select the
neighbor relations for black-
listing and deletion.
HO attempts This parameter defines the 10 to 1000 10 100

threshold of handover at-
tempts per KPI monitor peri-
od. If the HO criteria is set to
Minimum HO attempts, then
the neighbor relations with
handover attempts equal to
or greater than the defined
threshold of handover at-

tempts are tagged for black-

listing and deletion. If the HO
criteria is set to Maximum HO
attempts, then the neighbor
relations with handover at-
tempts less than or equal to
the defined threshold of han-
dover attempts are tagged for
blacklisting and deletion.
Maximum HO suc- This parameter defines the 1 to 100 5 50

cess rate maximum handover success
rate per KPI monitor peri-
od. Neighbor relations with a
handover success rate less
than or equal to the defined
value are tagged for blacklist-
ing and deletion.
Unit is percentage.
KPI monitor period KPI data available during the 1 to 10 1 1

last defined number of days
from the module execution
time is considered for compu-
tation.
LTE to WCDMA The blacklisting type for LTE CSFB&PSHO, N/A CSFB&
neighbor blacklisting to WCDMA neighbor rela- SRVCC
PSHO
type tion can be either CSFB (Cir-
cuit Switched Fallback) and
PSHO (Packet Switched
Handover) or SRVCC (Single
Radio Voice Call Continuity).
Blacklist duration The duration for which a 1 to 23, Ignore 1 1

neighbor relation has to be
blacklisted. The blacklisted
neighbor relation is eligible
for unblacklisting only after
the elapse of the blacklist du-
ration. If set to Ignore, time
based unblacklisting is not
considered.

Unit is hours.
Increased blacklist Number of times a neighbor 1 to 10 1 3

trigger count relation has to be consec-
utively blacklisted and un-
blacklisted, after which it is
blacklisted for a longer dura-
tion.
Increased blacklist Increase the blacklisting du- 1 to 7, Permanent 1 1

duration ration of neighbor relations
that have been consecutive-
ly blacklisted and unblacklist-
ed to a value greater than the
specified number of blacklist
triggers. Set to Permanent
to blacklist the neighbor rela-
tions permanently.
Unit is days.
Maximum blacklisting Percentage of neighbor rela- 0 to 100 5 50

threshold tions that can be blacklisted
under a given cell. If black-
listing exceeds the maximum
threshold per cell, the re-
mainder of the neighbor re-
lations under the cell will not
be blacklisted. This setting is
common for both intra-LTE
and LTE inter-RAT neighbor
relations.
Unit is percentage.
Autonomous removal This parameter specifies if Allowed, Forbidden N/A Forbidden

of blacklisted neigh- the blacklisted neighbors can
bor relations be automatically deleted. If
set to Allowed, the eNB can
automatically delete blacklist-
ed neighbors. If set to Forbid-
den, the eNB does not auto-
matically delete blacklisted
neighbors.

Reliability threshold Specifies the threshold be- 0 to 100 5 50

low which KPIs are consid-
ered as insufficient data for
blacklisting and deletion of
neighbor relations to happen.
If set to Ignore, the KPI data
is considered reliable for the
defined KPI monitor period.
The unit is percentage.
Percentage of cell This parameter defines the 0 to 100 1 10

range increase percentage of increase to be
done in the cell range by us-
ing PRACH parameters.
Unit is percentage.
PRACH based black- If Yes, then PRACH based Yes, No N/A No

listing blacklisting is enabled. If
the cell range for the giv-
en neighbors correspond-
ing to the configured PRACH
parameters are non-over-
lapping even after scaling
with percentage of cell range
increase, then the neigh-
bors are considered non-
reachable neighbors and are
blacklisted if this parameter is
enabled.
Respect neighbor re- If Yes, then the neighbor Yes, No N/A No

lation control parame- relations are blacklisted or
ter unblacklisted based on the
neighbor relation control pa-
rameter of the relation. If No,
then the neighbor relations
are blacklisted or unblacklist-
ed irrespective of the neigh-
bor relation control parame-
ter. This parameter is consid-
ered only if intra-LTE PRACH
based blacklisting is enabled.

Note: This para-

meter is only ap-
plicable for Nokia.
Neighbor removal This parameter defines the 1 to 18 1 10

monitoring period number of days during which
the neighbor relation removal
is monitored. It is applicable
if the use case selected is
Deletion of neighbors.
Unit is days.
Maximum number of This parameter defines the 1 to 10 1 2

repeated neighbor re- maximum number of times
moval a neighbor relation can be
deleted, after which the
neighbor is blacklisted. If the
neighbor relation deletion
count of a cell exceeds the
defined number during the
defined neighbor removal
monitoring period, then the
neighbor is blacklisted in-
stead of being removed.
X2 Blacklisting The relations specified in the File N/A File

neighbor relation file are re-
moved and the neighbor is
added to the X2 blacklist at
the source eNB. This para-
meter is ignored if a neighbor
relation file is not provided.
SON Operation Mode Set to Open Loop to run Open Loop, Closed N/A Open Loop
the module in open loop Loop
mode. Set to Closed Loop
to run the module in closed
loop mode. In Closed Loop
mode, changes are automat-
ically pushed to the network
without user intervention. In
Open Loop mode, the mod-
ule does not automatically

push parameter changes to

the network. The user has to
manually provision plans to
push changes to the network.
Plan Name Tag Text that will be added to Sequence which N/A Empty
the names of all the plans contains any com-
that will be generated by binations of:
this module. If the target of
• Uppercase and
the module is a whole spe-
lowercase let-
cific cluster (and the name
ters: [A-Za-z]
of this cluster also matches
• Numbers: [0-9]
the Range), then the cluster
• Underscore: _
name is also added to the
plan name. The maximum
length is 20 charac-
ters.
Table 19: ANR Blacklisting and Cleanup LTE configuration parameters
6.1.1.2 Frequency object creation file
A frequency object creation file (CSV file) lists the frequency objects to be created in the source cell for
the frequency of the corresponding target cell. Table 20: Example of frequency object creation file for-
mat describes an example of frequency object creation file format.
LCH48857B21 LCH32931A31
LCH48857B11 LCH32931A11
Table 20: Example of frequency object creation file format
Each row is a cell pair. Frequency objects are created if the LMS (Layer Management Strategy) config-
uration file allows the creation of objects across frequency layers.
6.1.1.3 Frequency object deletion file
A frequency object deletion file (CSV file) lists the frequency objects to be deleted from the source cell
for the given frequency.
Note: Frequency object deletion can only be done using the Frequency Object Deletion
File option.

Table 21: Example of frequency object deletion file format describes an example of frequency object
deletion file format.
Frequency channel
Source cell Technology Frequency band
number
LCH48857B21 4g 19500
LCH48857B11 3g 1000
LCH48857B31 2g 513 gsm1900
Table 21: Example of frequency object deletion file format
Each row is a cell pair. Frequency objects are deleted if the LMS (Layer Management Strategy) config-
uration file allows the deletion of objects across frequency layers.
6.1.1.4 Whitelist and blacklist target frequencies file

A whitelist and blacklist target frequencies file (CSV file) lists the frequencies to be whitelisted or black-
listed for the source cell.
Note: This file must not be provided if the frequency object creation or deletion file is given.
Table 22: Example of whitelist blacklist file lists an example of the file format.
Source cell Frequency Technology Whitelist/Blacklist
LCH48857C11 10640 4g white
LCH48857C11 1060 3g black
LCH48857B11 12 2g white
Table 22: Example of whitelist blacklist file
Each row consists of the source cell, frequency to be whitelisted or blacklisted, technology, and white
or black (for whitelisting or blacklisting respectively).
6.1.2 ANR-4G IRAT GUI parameters

Table 23: ANR-4G IRAT GUI parameters describes the GUI parameters of the ANR-4G IRAT module.
Parameter Description Range (min, max) Step Default value
LTE_IRAT_Out- This parameter applies 1.00 to 2.00 0.10 2.00

perform_Multiplier only to LTE targets. It in-
dicates the amount by
which a cell has to outper-

form another cell before it

is replaced. It is based on
LTE intra-frequency han-
dover counts.
Enforce_LMS_ With this function en- True, False N/A False

Size_For_Exist- abled, neighbor lists are
ing_Neighbors trimmed according to
any maximum neighbor
sizes defined in the LMS
configuration for specif-
ic layer to layer transi-
tions. The number of re-
lations in subset condi-
tions are checked and re-
movals are performed be-
fore higher level set con-
ditions are checked. This
function is used in the roll-
out phase for a new LMS.
Optimize 4G to 3G This parameter controls Yes, No N/A Yes

neighbor relations the optimization of the
IRAT neighbors.
For example:
If Optimize 4G to 3G
neighbor relations
is enabled, only 4G to 3G
relations are optimized
and 4G to 2G relations
are not considered.
Optimize 4G to 2G This parameter controls Yes, No N/A Yes

neighbor relations the optimization of the
IRAT neighbors.
For example:
If Optimize 4G to 2G
neighbor relations
is enabled, only 4G to 2G
relations are optimized
and 4G to 3G relations
are not considered.

SON Operation Set to Open Loop to run Open Loop, Closed N/A Open Loop
Mode the module in open loop Loop
mode. Set to Closed
Loop to run the mod-
ule in closed loop mode.
In Closed Loop mode,
changes are automatical-
ly pushed to the network
without user intervention.
In Open Loop mode, the
module does not auto-
matically push parameter
The user has to manual-
ly provision plans to push
Plan Name Tag Text that will be added to Sequence which N/A Empty
the names of all the plans contains any combi-
that will be generated by nations of:
this module. If the target
• Uppercase and
of the module is a whole
lowercase let-
specific cluster (and the
ters: [A-Za-z]
name of this cluster also
• Numbers: [0-9]
matches the Range), then
• Underscore: _
the cluster name will al-
so be added to the plan The maximum length
name. is 20 characters.
Table 23: ANR-4G IRAT GUI parameters
6.2 LTE ANR INI parameters

This section describes the INI parameters present in the LTE ANR modules:

• ANR Blacklisting and Cleanup LTE INI parameters
• ANR 4G IRAT INI parameters

6.2.1 Common INI parameters
Table 24: Common configuration file parameters lists the common configuration file parameters used
by the ANR modules.
Range (Min,
Parameter Description Step Default
Max)
Extended_1st_ Defines the maximum allowed dis- 1 to 100 1 40

Tier_Distance_ tance for relations to be classified as
Threshold first tier for the algorithm. Additional
first tier relations are classified as ex-
tended first tier.
Absolute_1st_ Defines the maximum number of re- 0 to 32 1 8

Tier_Maximum lations classified as first tier for the
algorithm. Additional first tier rela-
tions are classified as extended first
tier.
Max_Cell_Dis- Usually set to 0 to prevent removal 0 to 2 0.1 0

tance_Prevent_ of relations with missing information
Removal (for example, Distance = None)
Max_Num_ Limits the number of changes 100 to 10000 1 500

Changes_To_ pushed to the OSS in each iteration
Push of the module. Higher priority addi-
tions (whitelist, missing first tiers) are
pushed first.
Neighbors_ Indicates the number of neighbors 50 to 1000 1 300

Pulled_Per_ pulled per cache cycle. There is no
Cache_Cycle impact on the ANR algorithm due to
this parameter and usually it does
not need to be adjusted.
Exclude_outdoor_ When this parameter is set to True, True, False N/A False
cells outdoor cells are excluded from tier
based intra, inter and IRAT neighbor
relation addition for an indoor source
cell, but they will be included in mea-
surement based neighbor relation
addition.
Table 24: Common configuration file parameters

6.2.2 ANR Blacklisting and Cleanup LTE INI parameters
Table 25: ANR Blacklisting and Cleanup LTE configuration file parameters lists the INI parameters of
the ANR Blacklisting and Cleanup LTE module.
Range
Parameter Description Step Default value
(min, max)
KPI_Time_Window_ This parameter indicates the KPI 1 to 24 1 1

Eval evaluation period for unblacklist-
ing.
Unit is hours.
TimeBetweenPush- This parameter can be used to 0 to 96 1 4

es_15Mins extend the time between pushes
by preventing new module execu-
tions based on the last push time.
For example: A setting of 4 indi-

cates four 15 minute periods –
therefore, module execution is
allowed to proceed only if more
than 1 hour has elapsed from the
time of the last push.
Note: The module is

still triggered every 15
minutes but exits im-
mediately without run-
ning.
Log_warnings_in_ If enabled, warning logs are print- True, False N/A False
Logs_tab ed in the Logs tab. If disabled,
warning logs are only available
in the output report log sheet. By
default, the value is set to False.
Maximum_blacklist- Limits the number of changes 0 to any in- 1 5000

ing_changes_per_ pushed to the OSS in each itera- teger, un-
execution tion of the module. limited
Allow_processing_ When the value for this parame- True, False N/A False
after_maximum_ ter is set to False and if the max-
changes_to_push_ imum number of changes to be
reached pushed as defined by the para-
meter Maximum_blacklist-

Range
(min, max)
ing_changes_per_execu-
tion is reached, then the re-
maining relations are not opti-
mized. When the value for this
parameter is set to True, then
all relations are evaluated irre-
spective of whether the num-
ber of changes has exceeded
Maximum_blacklisting_
changes_per_execution or
not.
Time_to_wait_for_ Time interval in seconds for Any positive 1 300

MO_feedback_in_ which the module will wait after integer
seconds provisioning and before fetching
the MO level feedback.
Note: This wait time is

included in the module
execution run time.
Max deletions per Maximum number of relations al- 1 to 20 1 20

cell lowed to be removed per source
cell.
Max deletions per Maximum number of relations al- 1 to 10000 1 3000

execution lowed to be removed in total per
execution.
Module_log_level This parameter controls the log- INFO N/A INFO

ging level at which you can view
DEBUG
the log statements.
Table 25: ANR Blacklisting and Cleanup LTE configuration file parameters
These parameters provide a level of protection so that the module does not remove an excessive
amount of neighbor relations, either from an individual cell, or from all cells on the target list. The limits
for the maximum number of changes are applicable to both modes of operation (automated mode and
neighbor relation file mode). Changes are not pushed to the network if the limits are exceeded in either
mode.
The configuration file is uploaded to the EdenNet application. For more information on how to upload
the file, see the Configuring a module section in the EdenNet User and Administration Guide docu-
ment.

6.2.2.1 Example of ANR Blacklisting and Cleanup LTE configuration file
The below code snippet provides an example of the ANR Blacklisting and Cleanup LTE configuration
file:
[Global]
#------------------------#
# Common parameters #
#------------------------#
Log_warnings_in_Logs_tab = False
TimeBetweenPushes_15Mins = 1
KPI_Time_Window_Eval = 1
[Operator Policy]
# The format is KPI name = +/-number%, aggregation rule
# + means the tolerance can go up to that number
# - means the tolerance can go down to that number
# aggregation rules can be sum, average, or sum/sum
eRAB_Voice_Call_Initiated = +0%, average
Note:
• At least one KPI should be mentioned in the Operator policy. Otherwise, module execu-
tion fails.
• Unblacklisting fails if relation level KPIs are mentioned in the Operator policy.
6.2.3 ANR 4G IRAT INI parameters
During execution of the ANR 4G IRAT module, the module specific configuration file (INI file) para-
meters are considered along with the parameters provided in the Configuration Parameters page.
These parameters are considered for all ANR 4G IRAT instances. The INI file is controlled by the ad-
ministrator.
Table 26: ANR 4G IRAT configuration file parameters lists the INI parameters of the ANR 4G IRAT
module.
Range (min,
max)
LTE_IRAT_ho_ Set to True if connected mode han- True, False N/A True
success_avail- dover from LTE to UMTS and LTE
able to GSM is enabled in the network
and per relation handover counts
are available. If set to False, re-
placement of existing LTE IRAT re-
lations will be permitted even when
handover counts are not available.

Range (min,
max)
It needs to be set to False for ALU

deployments.
LTE_IRAT_HO_ Used to identify poorly performing 0 to 70 10 50

Success_Rate_ IRAT neighbor relations. The IRAT
Threshold_For_ handover success rate must be be-
Cell_Removal low this threshold for removal.
LTE_IRAT_Max_ Used for removal of IRAT neighbors 0 to 50 1 0

HO_Success- and replacement by a candidate
es_For_Nbr_Re- IRAT neighbor. The existing IRAT
moval neighbor cannot be removed if the
number of handovers is above this
threshold.
LTE_IRAT_Max_ Cells can only be added as IRAT 1 to 10 1 2

Tier_Count_For_ neighbors at this tier count or be-
Cell_Add low. The tier map for the candidate
frequency layer is used.
LTE_IRAT_Max_ Cells can only be added as IRAT 1 to 100 1 40

Cell_Distance_ neighbors at this distance or below.
Threshold Keeping this parameter to a high
value allows neighbors with low tier
counts but high distance in rural ar-
eas to be added. Unit is in kilome-
ters.
LTE_IRAT_Min_ It is the threshold for LTE intra-fre- 1 to any positive 1 50

LTEintraFreq_ quency neighbor successes for co- integer
HO_Success_ sector 3G and 2G cells to be con-
For_Cell_Add sidered for addition.
LTE_IRAT_ Number of defined neighbor rela- The range is ven- 1 15

Neighbor_List_ tions allowed for 2G cells per fre- dor specific. For
Size_2G quency layer. Neighbors will be further informa-
added up to this limit before any tion, see Range.
replacement of existing neighbors
takes place.
Note:
This parameter is not lim-

ited to per frequency for:
• Huawei vendor

Range (min,
max)
• ZTE vendor
• Nokia 2G cells
LTE_IRAT_ Number of defined neighbor rela- The range is ven- 1 15

Neighbor_List_ tions allowed for 3G cells per fre- dor specific. For
Size_3G quency layer. Neighbors will be further informa-
added up to this limit before any tion, see Range.
replacement of existing neighbors
takes place.
Note:
This parameter is not lim-

ited to per frequency for:
• Huawei vendor
• ZTE vendor
• Nokia 2G cells
LTE_Max_LNAD- Used to ensure that the maximum 32 to 512 1 256

JW number of managed objects are not
exceeded per technology per eN-
odeB. Different limits apply to dif-
ferent RAN releases. For example,
in the LTE16A release, up to 512
LNADJWs may be defined per eN-
odeB.
LTE_Max_LNAD- Used to ensure that the maximum 32 to 512 1 256

JG number of managed objects are not
exceeded per technology per eN-
odeB. Different limits apply to dif-
ferent RAN releases. For example,
in the LTE16A release, up to 256
LNADJGs may be defined per eN-
odeB.
Maximum_al- A missing LTE to 3G relation is not 3 to 6 1 3

lowed_UARFC- added if it will result in the number
Ns_for_LTE_ of unique target UARFCNs for all
IRAT_neighbor relations exceeding this limit.
KPI_data_reliabil- This parameter represents the min- 0 to 100 1 50

ity_threshold imum percentage of reliable KPI

Range (min,
max)
data which should be available for

evaluation. It is ignored if set to 0.
LTE_IRAT_ger- Indicates the 2G technology sup- GSM, GPRS, 1 GSM

anversion ported by the customer. The pos- EDGE
sible values are GSM, GPRS, and
EDGE.
Note: This parameter

is only applicable to the
Huawei vendor.
LTE_IRAT_ Indicates the first frequency AR- GSM-850: 128 – 1 GSM900: 0

startingarfcn FCN in the carrier frequency bands 251 DCS1800: 512
supported by the customer.
P-GSM-900: 1 –
Note: 124
• This parameter is on- E-GSM-900: 975

ly applicable to the – 1023, 0 - 124
Huawei vendor.
DCS-1800: 512 –
• This parameter is 885
valid only during di-
PCS-1900: 512 –
rect integration. It
810
is not supported for
NAdC based integra-
tion (as NAdC cre-
ates the freqgroup
objects).
Enable_trimming Enables trimming based on the fol- True, False N/A False
lowing configuration parameters:
• LTE_IRAT_Neighbor_List_
Size_2G
• LTE_IRAT_Neighbor_List_
Size_3G
Note: The LMS has high-

er precedence than the
configuration parameters
while trimming.

Range (min,
max)
LTE_IRAT_Min_ If HO successes are less than the 1 to 100 1 5

LTEintraFreq_ defined threshold, such neighbors
HO_Success_ are considered for removal.
For_Cell_Reten-
tion
tabs The ANR_4G_IRAT module gener- • Parameters N/A • Parame-

ates the following sheets in the out- • Changes ters
put report: • Changes
• Detected
• Parameters Neighbors • Detected
• Changes • HO Report Neighbors
• Detected Neighbors • Final Neigh- • IRAT
• HO Report bors Reuse
• Final Neighbors • IRAT Neigh- Conflicts
• IRAT Neighbor Performance bor Perfor- • Logs
• IRAT Reuse Conflicts mance
• Logs • IRAT Reuse

Conflicts
• Logs
Maximum_count_ Maximum number of neighbor cells 0 to 16 1 4

redirWithSysInfo that can be a candidate for provid-
Allowed_lnrelw ing system information in case of
UE redirection to UTRAN.
Maximum_count_ Maximum number of neighbor cells 0 to 16 1 4

redirWithSysInfo that can be a candidate for provid-
Allowed_lnrelg ing system information in case of
UE redirection to GERAN.
Additional_Log- Additional information is logged if True, False N/A False

ging this parameter is set to True. Addi-
tional logs are mainly used for de-
bugging purposes. They include in-
ternal parameters which cannot be
modified and are displayed in the
parameter sheet of the report.
Log_warnings_ If it is enabled, warning logs are True, False N/A False

in_script_logs printed in the log file. If it is dis-
abled, warning logs can only be
seen in the output report log sheet.

Range (min,
max)
Use_modified_ If set to True, the modified CGI is True, False N/A False
CGI_for_erics- used to identify the external cells. If
son_external_ set to False, the cell name or label
cell_DN is used to identify the external cells.
Module_log_level This parameter controls the logging INFO N/A INFO

level at which you can view the log
DEBUG
statements.
Exclude_indoor_ When set to True, indoor cells are True, False N/A False
cells excluded from tier based Intra, In-
ter, and IRAT neighbor relation ad-
dition but they will still be included
in measurement based neighbor re-
lation addition.
Update_mobility_ If this parameter is set to True, the True, False N/A True
parameters_for_ parameters srvccAllowed and
existing_neigh- psHoAllowed for LNRELW will be
bors updated for all neighbors per fre-
quency.
If this parameter is set to False, the

parameters srvccAllowed and
psHoAllowed for LNRELW will be
updated only for the newly added
neighbors per frequency.
Note:
• This parameter is
applicable only for
the Nokia vendor.
• The LMS settings
of the new
neighbors will not
be considered if
there are already 32
existing neighbors
with parameters
srvccAllowed
and psHoAllowed
set to allowed,
when the Update_

Range (min,
max)
mobility_
parameters_
for_existing_
neighbors
parameter is set to
False.
consider_HO_ This parameter indicates the criteria Both, HO, Tier N/A Both
or_tier_for_neigh- to be considered along with the cell
bor_ranking coupling score for neighbor ranking:
• If this parameter is set to HO,

the IRAT handover success
KPI will be considered along
with the cell coupling score.
• If this parameter is set to Tier,
the tier count will be consid-
ered along with the cell cou-
pling score.
• If it is set to Both, then both the
IRAT handover success KPI
and the tier count will be con-
sidered along with the cell cou-
pling score.
Order_of_execu- This parameter allows customers to First_tier, HO_ N/A First_tier,HO_

tion change the order of algorithm exe- based, Topology_ based,Topology_
cution. based based
Note: If the value that First_tier, Topol-

is provided is a partial ogy_based, HO_
string, the ANR 4G IRAT based
module uses the default HO_based, First_
value. The values are not tier, Topology_
case sensitive. based
HO_based,
Topology_based,
First_tier
Buffer_for_De- This parameter is used to limit the 1 to any positive 1 20

tected_Neighbors detected neighbor size for topology integer
based addition.

Range (min,
max)
Note: If a negative value

or any other unsupported
value is set, this parame-
ter defaults to 20.
Limit_no_of_de- This parameter is used to limit the Yes, No N/A No

tected_neighbors number of detected neighbors.
If this parameter is set to Yes,

the ANR 4G IRAT module limits
the detected neighbors based on
the value of the Buffer_for_
detected_neighbors parameter.
If this parameter is set to No, the

ANR 4G IRAT module does not lim-
it the detected neighbors.
TimeBetween- This parameter is used to extend 0 to 96 1 1

Pushes_15Mins the time between pushes by pre-
venting new module executions
based on the expired time since the
last push (rounded down to the last
15 minute period).
For example: A setting of 4 in-

dicates four 15 minute periods.
Therefore, the module execution
is allowed to proceed only if more
than 1 hour has elapsed from the
time of the last push.
Note:
• The module is still

triggered every 15
minutes but exits im-
mediately without
running.
• Setting the value of
this parameter to 0
will trigger the mod-
ule only one time.

Range (min,
max)
Configurable_re- Indicates the relation ID (RDN val- N/A N/A The default
lation_Id ue) of a relation MO. value is dif-
ferent for dif-
For details on how to configure the
ferent rela-
parameter, see Configuring relation
tion types and
DN ID for Ericsson (4G).
technologies.
For more in-
formation, see
the Default
values for re-
lation DN IDs
for ANR 4G
IRAT table in
the Configur-
ing relation
DN ID for Eric-
sson (4G) sec-
tion.
Table 26: ANR 4G IRAT configuration file parameters
Note:
• While trimming, LMS has higher precedence when compared to configuration parame-
ters.
• If Maximum_count_redirWithSysInfoAllowed_lnrelw and
Maximum_count_redirWithSysInfoAllowed_lnrelg are set to 0,
redirWithSysInfoAllowed will be set to forbidden for all the relations of the cells
which are optimized.
• If an invalid value is set for Maximum_count_redirWithSysInfoAllowed_lnrelw
and Maximum_count_redirWithSysInfoAllowed_lnrelg, the module defaults to
4.
Table 27: Range for LTE_IRAT_Neighbor_List_Size_3G and LTE_IRAT_Neighbor_List_Size_2G

parameters describes the range for the LTE_IRAT_Neighbor_List_Size_3G and
LTE_IRAT_Neighbor_List_Size_2G parameters.
Vendor Relation MO MO parent Range (Min, Max)
Huawei UTRANNCELL Cell 0 to 128
Huawei GERANNCELL Cell 0 to 64

Vendor Relation MO MO parent Range (Min, Max)
Ericsson UtranCellRelation Frequency (UARFCN) - UtranFre- 0 to 64

qRelation
Ericsson GeranCellRelation Frequency Group (Group of BCCH) 0 to 64

GeranFreqGroupRelation
ALU UtraFddNeighboring Frequency (UARFCN) - 0 to 64

UtraFddNeighboringFreqConf
CellRelation
ALU GeranNeighboring Frequency Group (Group of BCCH) - 0 to 64

GeranNeighboringFreqsConf
CellRelation
ZTE UtranRelation Cell 0 to 128
ZTE GsmRelation Cell 0 to 128
Nokia LNRELW Cell 0 to 64 per fre-

quency
Nokia LNRELG Cell 0 to 256
Table 27: Range for LTE_IRAT_Neighbor_List_Size_3G and LTE_IRAT_Neighbor_List_Size_2G para-

meters
6.2.3.1 Example of ANR-4G IRAT configuration file
Note:
The Max_Num_Changes_To_Push parameter does not include the LNADJG or LNADJW

additions and removals.
During neighbor replacement, there could be additional changes based on the last
processed cell and the Max_Num_Changes_To_Push parameter limit could be changed by
a maximum of 1.
For example: During neighbor replacement for a cell, if the Max_Num_Changes_To_Push

parameter is set to 500, then 501 changes can be seen in the generated report and its
corresponding change set.
The below code snippet provides an example of the ANR-4G IRAT configuration file:
[Global]
#------------------------#
# Common parameters #
#------------------------#
Max_Num_Changes_To_Push = 5000
Neighbors_Pulled_Per_Cache_Cycle = 300

# 1 to 100, in km, must not be greater than Maximum_Cell_Distance_

Threshold
Extended_1st_Tier_Distance_Threshold = 40.0
# 1 to 32, but setting this greater than 10 is almost always a mistake.
Absolute_1st_Tier_Maximum = 8
TimeBetweenPushes_15Mins = 1
# Additional_Logging = True
Enable_Non_Native_Adds = True
Update_mobility_parameters_for_existing_neighbors = True
#------------------------#
# 4G Specific parameters #
#------------------------#
# Note Dropped Call Rate Threshold for information only. Not used in
algorithm.
LTE_IRAT_DCR_Threshold = 4.0
LTE_IRAT_Max_Cell_Distance_Threshold = 40
LTE_IRAT_Min_LTEintraFreq_HO_Success_For_Cell_Add = 50
LTE_IRAT_Max_Tier_Count_For_Cell_Add = 2
# Existing LTE IRAT relations with more than this number of HO Success
will not be replaced
LTE_IRAT_Max_HO_Successes_For_Nbr_Removal = 0
# Number of relations is per frequency layer

LTE_IRAT_Neighbor_List_Size_2G = 20
LTE_IRAT_Neighbor_List_Size_3G = 20
# Set to False in case LTE IRAT handover counts not available

LTE_IRAT_ho_success_available = True
#Maximum allowed UARFCN

Maximum_allowed_UARFCNs_for_LTE_IRAT_neighbor = 3
#KPI reliability threshold

KPI_data_reliability_threshold = 50
#Set to TRUE to Enable trimming from INI

Enable_trimming = FALSE
#This is Nokia specific setting

lte_max_lnadjw = 256
lte_max_lnadjg = 256
[Output]
tabs = Parameters, Changes, Detected Neighbors, IRAT Reuse Conflicts,
Logs

Note: Max_Num_Changes_To_Push does not include the LNADJG or LNADJW additions

and removals.
6.3 Configuring INI parameters

INI parameters can be modified to change the default settings of a module. You can also import, export, delete, activate, and
deactivate configuration files.
Prerequisites
Only users with admin privileges have permissions to modify the INI parameters.
1. Log in to the EdenNet application:

a) In the address field of your Internet browser, type the following URL (for 2VM, 5VM, and cross-
OSS):

d) Click Log In.
The SON Activity page appears.
2. Click Administration → Modules.
The following module categories appear in the left pane:
• EdenNet modules: The modules that Nokia provides are available in this category.
• Adapted modules: The modules that users develop are available in this category.
• Helper modules: These modules are mainly used for troubleshooting by Nokia support teams.
They are not categorized as Generally Available. General Availability implies that the release is
available to all customers.
Or
Or
• ANR_4G_IRAT
4. Click Configure → Module Configuration.

The <LTE ANR> Configuration Manager dialog box appears.
5. Select the required configuration category from the below options:
• Import And Activate: to import a file and activate it immediately.

• Import: to import a file.
• Export: to export the selected file to your system.
• Delete: to delete the selected file from the list.
The user should have admin or SON manager access permissions to perform the Delete oper-
ation. INI files can be deleted only if they are not used by other modules.
• Activate: to activate the selected file from the list.
Multiple configurations can be activated in the list.

• Deactivate: to deactivate the activated file.
A file can be deactivated only when it is not used by other module instances listed under Ac-
tive SON Modules and Module History.
• Set As Default: to set the selected file as the default configuration.
• Reset: to reset the edited parameter values in the selected INI file.
• Save: to save the new version of the configuration after editing the parameter values in the
selected INI file.
• Save As: to save the configuration with a different name.
For more details, see the Configuring a module section in the EdenNet User and Administration
Guide.
For the INI file parameters, see:

• ANR Blacklisting and Cleanup LTE INI parameters
• ANR 4G IRAT INI parameters

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Viewing LTE ANR targets
7 Viewing LTE ANR targets

You can view the targets which are configured for the specific LTE ANR module instance.

OSS):

d) Click Log In.
2. Click the SON Modules > Status tab.
The list of active SON modules appears in the left pane.
Or
Or
• ANR_4G_IRAT
The Configure Targets page appears.
4. Click the Target tab.
Expected outcome
The target cells which were configured for the selected module instance are displayed on the map.
• The cells selected for module execution are displayed in blue.

• The cells with errors are displayed in red. The LTE ANR modules do not optimize these cells.
The cells with errors also generate error events which can be analyzed in order to perform the
required troubleshooting.

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Viewing LTE ANR reports
8 Viewing LTE ANR reports

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

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 LTE ANR module.
The LTE ANR 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. It lists the module filename.
6. Click the LTE ANR filename.
A list of Excel files 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:
• ANR Blacklisting and Cleanup LTE module reports

• LTE ANR Frequency Rules module reports

8.1 LTE ANR reports

• ANR Blacklisting and Cleanup LTE module reports

• LTE ANR Frequency Rules module reports
8.1.1 ANR Blacklisting and Cleanup LTE module reports

The ANR Blacklisting and Cleanup LTE module generates a report in an Excel file. Each worksheet in
the Excel is a report.
Table 28: ANR Blacklisting and Cleanup LTE module report (Blacklisting of neighbors use case) and
Table 29: ANR Blacklisting and Cleanup LTE module report (Deletion of neighbors use case) describe
each report in the Excel file.
Note:
If multiple clusters are selected to run the module, cluster names are displayed in the Para-
meters sheet.
Worksheet name Description
Parameters Lists the module parameters used for this iteration of ANR_Black-
listing_and_Cleanup_LTE module.
Detected Relations Provides the detected relations between the source and neighbor
cells. Also, it provides the status or reason for blacklisting.
Blacklisting Provides the blacklisted relation details. This sheet is visible only
when some neighbor relations are blacklisted.
Unblacklisting Provides the unblacklisted relation details. This sheet is visible on-
ly when some neighbor relations are unblacklisted.
Logs Details any errors or conditions which indicate that detected neigh-
bors could not be sent for implementation.
Provisioning Details Provides the relation provisioning status when the module runs in
closed loop. This sheet is visible only when some neighbor rela-
tions are blacklisted or unblacklisted.

Table 28: ANR Blacklisting and Cleanup LTE module report (Blacklisting of neighbors use case)
Worksheet name Description
Parameters Presents the module UI and the configuration file parameters used
for ANR_Blacklisting_and_Cleanup_LTE execution.
Detected Neighbor Removal Presents all the detected neighbors which are candidates for re-
moval.
Removed X2 Links It will be populated only when the vendor of the source eNodeB is
Nokia.
It provides a list of X2s which are marked for deletion as part of X2

blacklisting.
Logs Details any errors or conditions which indicate that detected neigh-
bors cannot be sent for implementation.
Changes Provides a list of LTE-LTE Intra or Inter frequency neighbors from

neighbor lists which are marked for deletion.
Table 29: ANR Blacklisting and Cleanup LTE module report (Deletion of neighbors use case)
The tabs within the excel sheet for the Blacklisting of neighbors use case are described in the follow-
ing tables:
• Parameters
• Detected relations
• Blacklisting
• UnBlacklisting
• Logs
The tabs within the excel sheet for the Deletion of neighbors use case are described in the following
tables:
• Parameters
• Detected Neighbor Removal
• Removed X2 links
• Logs
• Changes
• Provisioning Details
8.1.1.1 Output report naming conventions
Table 30: Output report naming conventions describes the output report naming conventions for the
ANR_Blacklisting_and_Cleanup_LTE module.

Output report name Description
LTE_ANR_Blacklisting_Clus- Indicates that the use case is Blacklisting of neighbors.

ter Name_DateTime
Cluster_Name is the name of the cluster selected in the
current run.
LTE_ANR_Cleanup_Cluster Indicates that the use case is Deletion of neighbors.

Name_DateTime
current run.
Module Name_Cluster Name_ Indicates that 1 cluster is selected.

DateTime
current run.
ModuleName_Multi_DateTime Indicates that multiple clusters are selected and the names of
the clusters are displayed in the Parameters sheet of the re-
port.
ModuleName_Datetime Indicates that no clusters are selected and only cells are se-
lected.
ModuleName_Datetime Indicates that a single cluster or multiple clusters are selected

with cells from the map.
Table 30: Output report naming conventions
8.1.1.2 Tier count
Note: For all the reports mentioned in Table 28: ANR Blacklisting and Cleanup LTE module
report (Blacklisting of neighbors use case) and Table 29: ANR Blacklisting and Cleanup LTE
module report (Deletion of neighbors use case), the Tier column defined in Table 31: Tier
count will have values greater than or equal to 10001 for all invalid or missing data related
cells.
Type/Code Name Description
10001 UNREACHABLE There is no path from the source cell to

the target cell (the distance exceeds the
threshold).
Tier count is greater than the maximum

configured value (10), or there is no
path from the source cell to the target
cell beyond 10 tiers.

10002 INVALID_SOURCE_CELL The source cell or one or more of its an-

tennas are missing attributes.
10003 INVALID_TARGET_CELL The target cell or one or more of its an-

10004 CELL_HAS_NO_ANTEN- The source or target cell does not have

NA an antenna.
10005 UNKNOWN_TARGET_ The unique identifier of the target cell

CELL does not match any cell in the tier ser-
vice database.
10006 UNKNOWN_SOURCE_ The unique identifier of the source cell

vice database.
10007 UNKNOWN_ERROR There is an unexpected error indicating

an internal exception.
10008 NO_SURROGATE The source cell or all its antennas have

no surrogates on the target layer.
Table 31: Tier count
8.1.1.3 Blacklisting
Table 32: Blacklisting describes the columns present in the Blacklisting sheet.
Column name Description
Source Cell The source cell name.
Source Cell DN The source cell DN.
Source Cell Region The OSS that manages the source cell.
Source Cell Vendor The source cell vendor.
Neighbor Cell to The target cell name.

Blacklist
Neighbor Cell DN The target cell DN.
Neighbor Cell Region The OSS that manages the target cell.
Neighbor Cell Vendor The target cell vendor.
Neighbor Type The neighbor types are Intra, Inter, or IRAT.

DN The complete distinguished name of the LNREL.
Distance Distance in kms to the neighboring cell.
Tier count Tier count to the resolved cell. The Effective Tier count after Tier Count Ad-
justment has been applied. A tier of 10,000 means that it is unreachable
through the tier map.
Attempts Number of HO Attempts to the neighbor cell.
Success Rate (Ig- The Handover Success rate in percent.

nore)
Sum of Expected Cell The sum of the source and target cell ECR in kms.
Range (km)
Table 32: Blacklisting
8.1.1.4 Cell Level Summary

Table 33: Cell Level Summary describes the columns present in the Cell Level Summary sheet.
Source Parent The parent entity to the Source Cell.
Source Cell DN The Distinguished Name for the source cell managed object.
Source Region The EdenNet region to which the source cell belongs.
Source Vendor The vendor for the source cell.
Status The status can be:
• Evaluated: can result in neighbor additions, removals, or no action if

the cell is already optimized.
• Excluded: the cell is excluded (for example, excluded through the
SON exclusion list or Module exclusion list, missing required data for
analysis, or cannot be trimmed).
Reason Descriptive reason for the Status.
Total Neighbors Added Total number of neighbors added during the execution of the module.
Total Neighbors Removed Total number of neighbors removed during the execution of the module.
Total Neighbors Before Total number of neighbors before this execution of the module.

Total Neighbors After Total number of neighbors after this execution of the module (actual if
run in Closed Loop, hypothetical if run in Open Loop).
Intra Neighbors Total number of intra-frequency neighbors.
Inter Neighbors Total number of inter-frequency neighbors.
IRAT (LTE-WCDMA) Total number of IRAT (LTE-WCDMA) neighbors before the current exe-
Neighbors Before cution of the module.
IRAT (LTE-WCDMA) Total number of IRAT (LTE-WCDMA) neighbors after the current execu-
Neighbors After tion of the module (actual if run in closed loop, hypothetical if run in open
loop).
IRAT (LTE-GSM) Neigh- Total number of IRAT (LTE-GSM) neighbors before the current execution
bors Before of the module.
IRAT (LTE-GSM) Neigh- Total number of IRAT (LTE-GSM) neighbors after the current execution
bors After of the module (actual if run in closed loop, hypothetical if run in open
loop).
Table 33: Cell Level Summary
8.1.1.5 Detected relations

Table 34: Detected relations describes the columns present in the Detected relations sheet.
Neighbor Type The type of neighbor
Date/Time Date and timestamp during module execution
Source Cell The source cell name
Source Cell DN The source cell DN
Source Cell Region The OSS that manages the source cell
Source Cell Vendor The source cell vendor
Neighbor Cell to The target cell name

Blacklist
Neighbor Cell DN The target cell DN
Neighbor Cell Re- The OSS that manages the target cell
gion
Neighbor Cell Ven- The target cell vendor

dor

Relation DN The complete distinguished name of the LNREL
Distance (Ignore ) Distance in kms to the neighboring cell
Tier count (expected Tier count to the resolved cell

>= 3)
Attempts (Ignore) Number of HO Attempts to the neighbor cell
Success Rate (Ig- Handover Success rate in percent

nore)
Sum of Expected Sum of the source and target cell ECR in kms
Cell Range (km)
Modification Provides information about whether the relation is blacklisted or not
Table 34: Detected relations
8.1.1.6 HO report
Table 35: HO report describes the columns present in the HO report sheet.
Neighbor Cell The neighboring cell name.
UserLabel The userLabel of the cell name from the CM data.
Neighbor Type The neighbor type is IRAT.
Neighbor Frequency The frequency layer the neighbor cell belongs to.
Layer
• For WCDMA cells - the UARFCN
• For GSM cells - the Band
Reuse Code • For WCDMA cells - the UARFCN + Primary Scrambling Code
• For GSM cells - the BCCH + BSIC
Neighbor relation exis- Indicates if the relation exists (actual if run in closed loop, hypothetical if
tence run in open loop).
Cross OSS neighbor re- Indicates if the relation is across an OSS boundary.
lation existence
Category The categories are First Tier and Extended First Tier.
Change Reason Descriptive reason for the neighbor addition or removal (for example, first
tier addition, detected neighbor addition, reciprocal addition, replacement).

HO Successes Handover Success count on the relation.
HO Attempts Handover Attempt count on the relation.
Percentage of HO at- Percentage of handover attempts on this relation compared to all the out-
tempts per frequency going neighbor relations for this frequency.
(%)
• For WCDMA targets - the UARFCN
• For GSM targets - the Band
Success rate Handover Success rate in percent.
Failure count Handover Failure count.
Tier Count Tier count to the neighboring cell. The Effective Tier count after Tier Count
Adjustment has been applied. A tier of 10,000 means it is unreachable
Source Cell DN The complete distinguished name of the source cell.
Neighbor Cell DN The complete distinguished name of the neighbor cell.
Source Region Region name of the source cell.
Source Vendor Vendor details of the source cell.
Neighbor Region Region name of the neighbor cell.
Neighbor Vendor Vendor details of the neighbor cell.
Detection Method Describes the proxy relations used to detect missing neighbors. For ex-
ample: 4G->4G (co-sector 3G on target) or 4G->4G (co-sector 2G on tar-
get).
Table 35: HO report
8.1.1.7 Logs
Table 36: Logs describes the columns present in the Logs sheet.
Time Timestamp for the log message during module execution
Type The type of error or warning generated by the module
Message Describes the error or warning

Table 36: Logs
8.1.1.8 Parameters
Table 37: Parameters describes the columns present in the Parameters sheet.
Parameter The configuration parameter name
Value The parameter value used for the execution of the module
Table 37: Parameters
8.1.1.9 Reasons for neighbor addition

Table 38: Reasons for neighbor addition describes the reasons for neighbor addition.
Reason Description
White List Neighbor A neighbor relation was added which was whitelisted through EdenNet.
First Tier Neighbor A missing neighbor relation was added which is a first tier according to the
tier map and is ranked within the value of Absolute_1st_Tier_Maximum.
HO Based Detected A neighbor relation was added based on intra-frequency LTE handovers.
Neighbor
Tier 2+ Neighbor A neighbor relation was added which was tier two or greater according to the
tier map and detected as missing through the network topology.
Table 38: Reasons for neighbor addition
8.1.1.10 Reasons for neighbor removal

Table 39: Reasons for neighbor removal describes the reasons for neighbor removal.
Reason Description
Source Trim (One- A neighbor relation was trimmed to meet the configured neighbor list size lim-
Way) its.
Neighbor List Full. An existing lower ranked neighbor was removed and replaced by a higher
Removed Bottom ranked missing neighbor.
Neighbor
Replaced conflicting A neighbor relation which had an SC conflict was removed and replaced by a
neighbor higher ranked missing neighbor.

Table 39: Reasons for neighbor removal
8.1.1.11 IRAT Reuse Conflicts

Table 40: IRAT Reuse Conflicts describes the columns present in the IRAT Reuse Conflicts sheet.
Candidate Cell The candidate neighbor
Candidate Signal The candidate BCCH/BSIC or UARFCN/SC
Reason for conflict Descriptive reason for the conflict
Source Cell DN Complete distinguished name of the source cell
Candidate Cell DN Complete distinguished name of the neighbor cell
Source Region Region name of the source cell
Source Vendor Vendor details of the source cell
Candidate Region Region name of the neighbor cell
Candidate Vendor Vendor details of the neighbor cell
Table 40: IRAT Reuse Conflicts
8.1.1.12 UnBlacklisting
Table 41: UnBlacklisting describes the columns present in the UnBlacklisting sheet.
Neighbor Cell to Un- The target cell name.

blacklist
Neighbor Cell Vendor The target cell vendor.
Source Cell Vendor The source cell vendor.
Neighbor Type The neighbor types are Intra, Inter, or IRAT.

DN The complete distinguished name of the LNREL.
Reason for Unblack- It provides the reason for unblacklisting.

listing
Table 41: UnBlacklisting
8.1.1.13 Changes
Table 42: Changes describes the columns present in the Changes sheet.
Source Parent The parent entity of the Source Cell. For LTE cells, it is the LTE eNodeB.
Source Cell Vendor The vendor name of the source cell.
Neighbor Parent The parent entity of the Target Cell. For LTE cells, it is the LTE eNodeB.
Neighbor Cell The target cell name.
Neighbor Cell Vendor The vendor name of the target cell.
Neighbor Type The neighbor types are LTE-LTE Intra frequency relation and LTE-LTE Inter
frequency relation.
Relation DN The complete distinguished name of the LNREL.
Distance The distance in kms to the neighboring cell.
Tier Tier count to the resolved cell. The Effective Tier count after Tier Count Ad-
Modification Indicates whether the neighbor relation is removed or blocked.
Reason Provides a description for the neighbor removal or blocking.
Table 42: Changes

8.1.1.14 Provisioning Details
Table 43: Provisioning Details describes the columns present in the Provisioning Details sheet.
Source Cell DN The source cell DN
Neighbor Cell The target cell name
Neighbor Cell DN The target cell DN
Relation DN The complete distinguished name of the relation
Permanently Blacklist- Provides information about whether the relation is blacklisted permanently or
ed not if the Increased blacklist duration is set as Permanent
Provisioning Status Provides details about whether the relation is provisioned successfully
Table 43: Provisioning Details
8.1.1.15 Detected Neighbor Removal

Table 44: Detected Neighbor Removal describes the columns in the Detected Neighbor Removal
sheet.
Source Cell Vendor The vendor name of the source cell.
Neighbor Cell to Re- The target cell name.

move
Neighbor Cell Vendor The vendor name of the target cell.
Tier count Tier count to the resolved cell. The Effective Tier count after Tier Count Ad-
Neighbor Type The neighbor types are LTE-LTE Intra frequency relation and LTE-LTE Inter
frequency relation.
Relation DN The complete distinguished name of the LNREL.

Distance (Ignore) The distance in kms to the neighboring cell.
HO_Attempts (Ignore) The number of HO Attempts to the neighbor cell.
HO_Success_Rate The Handover Success rate in percent.

(Ignore)
Category The Category column can have the following values:
• Removal from file

• Distant Neighbor
• HO Based Neighbor
Removed? Indicates whether the neighbor relation is blocked. The values are Yes or
No.
Table 44: Detected Neighbor Removal
8.1.1.16 Removed X2 links

Table 45: Removed X2 links describes the columns present in the Removed X2 links sheet.
Source eNB The Source eNodeB
Target eNB The Target eNodeB
X2 distinguish Name The removed X2 link
Table 45: Removed X2 links
8.1.2 LTE ANR Frequency Rules module reports

The LTE ANR Frequency Rules module provides a report at each execution. It generates an Excel
spreadsheet with the tabs defined in Table 46: LTE ANR Frequency Rules module report.
Tabs Description
Parameters Provides a summary of all the configuration parameters and the values used
in the execution
LNHOIF Changes Provides all the corresponding frequency objects which are created, updat-
ed, or deleted for the scope cell
IRFIM Changes Provides all the corresponding frequency objects which are created, updat-

Tabs Description
LNHOW Changes Provides all the corresponding frequency objects which are created, updat-
UFFIM Changes Provides all the corresponding frequency objects which are created, updat-
LNHOG Changes Provides all the corresponding frequency objects which are created, updat-
GFIM Changes Provides all the corresponding frequency objects which are created, updat-
GNFL Changes Provides all the corresponding frequency objects which are created, updat-
REDRT Changes Provides all the corresponding frequency objects which are created, updat-
Logs Provides the list of unresolved cases
Table 46: LTE ANR Frequency Rules module report
8.1.2.1 Parameters
8.1.2.2 Changes
Table 48: LNHOIF, IRFIM, LNHOW, UFFIM, LNHOG, GFIM, GNFL, and REDRT Changes describes
the columns present in the LNHOIF, IRFIM, LNHOW, UFFIM, LNHOG, GFIM, GNFL, and REDRT
Changes sheets.
Date/Time The date and timestamp during module execution.
DN The complete distinguished name of the frequency object.
Frequency The list of frequencies in the frequency objects.

Note: The GFIM Changes sheet does not contain this column.
Change Type The change types are created, updated, and removed.
For the REDRT Changes sheet, there is an additional column - Technology, which lists the specified
technology (2G, 3G, or 4G).
Table 48: LNHOIF, IRFIM, LNHOW, UFFIM, LNHOG, GFIM, GNFL, and REDRT Changes
8.1.2.3 Logs
Table 49: Logs
8.1.3 ANR-4G IRAT module reports

In open and closed loop modes, the ANR-4G IRAT module provides a report at each execution. Table
50: ANR-4G IRAT module report describes the tabs in the ANR-4G IRAT module report.
Tabs Description
Detected neighbors Provides information about all the detected 4G to 3G and 4G to 2G

missing neighbors. The Neighbor List Modification column indicates
if the detected neighbor was added as a result of this module run.
The Neighbor List Modification Reason indicates the reasons why
detected neighbors were not added. It also describes whether the
neighbor was added in the ANR run or provides the reason why the
detected neighbor was not added.
Final Neighbors (disabled by Provides information about the final neighbors which exist after ANR
default) execution:
• the relative rank of each neighbor within each neighbor type

• the source LMS layer
• the target (neighbor) LMS layer
• the LMS condition for the relation

Tabs Description
• the maximum size constraints of the LMS neighbor
Changes Details the neighbor additions and deletions that are proposed (open
loop) or actually sent for implementation (closed loop). This list ex-
cludes changes which could not be implemented due to errors or
other conditions such as SC conflicts.
Logs Details any errors or conditions for neighbors that could not be sent
for implementation.
Parameters Lists the module parameters used for this iteration of ANR 4G IRAT.
HO Report (disabled by de- Details an overview per LTE cell of all the changes made by the
fault) module including the change reason. In open loop, the Neighbor re-
lation existence column represents the hypothetical situation if the
module was run in closed loop. PM counter statistics on handover
counts and success rate are also presented and they are used as
a condition for identifying the existing poorly performing neighbors.
It also includes statistics on the IRAT relations and 4G to 4G han-
dovers (based on the PM counter data).
Note:
• If the KPI values are not present (NULL), None is

printed in the report.
• If the dependent KPIs are not available, N/A is printed
in the report derived from the KPIs.
For example, HO Attempts and HO Successes are re-

quired to derive the Success rate. If HO attempts and
HO Successes have the value none, then the Success
Rate column is shown as N/A.
IRAT Reuse Conflicts Provides additional details on the proposed IRAT neighbors that
could not be added because they have the same UARFCN and SC
for 3G, or the same BCCH and BSIC combination for 2G as an exist-
ing neighbor.
IRAT Neighbor performance Provides details about the tier counts and geo-score calculations
(disabled by default) for existing neighbors. It also lists which of the existing relations are
classified as poor performers. It also details which existing neighbors
meet the criteria for potential replacements in case a missing IRAT
neighbor is detected and the neighbor list is past the defined maxi-
mum limit. It is based on the IRAT neighbor definitions.

Tabs Description
Cell Level Summary Presents a summary with one entry per cell regarding the action tak-
en for that cell and the total neighbor list sizes before and after ANR
execution.
The Status column provides information on whether the cell is:
• Evaluated: can result in neighbor additions, removals, or no ac-

tion if the cell is already optimized.
• Excluded: the cell is excluded through the SON exclusion list
or Module exclusion list. It does not have the required data for
analysis and cannot be trimmed.
Table 50: ANR-4G IRAT module report
8.1.3.1 Output report naming conventions

Table 51: Output report naming conventions describes the output report naming conventions for the
ANR-4G IRAT module.
Output report name Description
Module Name_Cluster Indicates that a single cluster is selected.

Name_DateTime
Cluster_Name is the name of the cluster selected in the current
run.
ModuleName_Multi_Date- Indicates that multiple clusters are selected, and the name of the
Time clusters is shown in the Parameters sheet of the report.
ModuleName_Datetime Indicates that clusters are not selected. Only cells are selected.
ModuleName_Datetime Indicates that a single cluster or multiple clusters are selected along
with cells from the map.
Table 51: Output report naming conventions
8.1.3.2 Tier count
Note: For all the reports mentioned in ANR-4G IRAT module reports, the Tier column will
have values greater than or equal to 10001 for all the invalid or missing data related cells.
10001 UNREACHABLE There is no path from the source cell to

the target cell (the distance exceeds the
threshold).

Tier count is greater than the maximum

configured value (10), or there is no
path from the source cell to the target
cell beyond 10 tiers.
10002 INVALID_SOURCE_CELL The source cell or one or more of its an-

10003 INVALID_TARGET_CELL The target cell or one or more of its an-

10004 CELL_HAS_NO_ANTEN- The source or target cell does not have

NA an antenna.
10005 UNKNOWN_TARGET_ The unique identifier of the target cell

vice database.
10006 UNKNOWN_SOURCE_ The unique identifier of the source cell

vice database.
10007 UNKNOWN_ERROR There is an unexpected error indicating

an internal exception.
10008 NO_SURROGATE The source cell or all its antennas have

no surrogates on the target layer.
Table 52: Tier count
8.1.3.3 Parameters
8.1.3.4 IRAT Neighbor Performance
Table 54: IRAT Neighbor Performance describes the columns present in the IRAT Neighbor Perfor-
mance sheet.

Neighbor Cell The neighbor cell name.
Neighbor Type The neighbor types are Intra and IRAT.
Basic Tier Count Basic Tier count before Tier Count Adjustment.
Dist. Distance in kms to the neighboring cell.
S->T GeoScore GeoScore of the angle between the source cell azimuth and the neighbor
cell.
T->S GeoScore GeoScore of the angle between the target cell azimuth and the source
cell.
HO Attempts Number of Handover Attempts.
HO success rate (%) Handover Success Rate in %.
Poor Performing neigh- True if the relation meets all the configured criteria for poorly perform-
bor ing neighbor removal (for example, Tier, Distance, S->T GeoScore, T->S
GeoScore, HO Attempt Number, HO Success Rate).
Available HO attempts KPI value for the available HO attempts duration in hours.
duration (hrs)
Available HO success KPI value for the available HO success duration in hours.
duration (hrs)
Potential Replacement Descriptive reason why an existing neighbor is not a candidate for re-
placement in the case of full neighbor lists. To be replaced, an existing re-
lation must meet all the replacement criteria.
For example:
• an existing relation must not be first tier or co-site

• the percentage of valid handover PM counter data must be at least
equal to the minimum configured limit
• the tier count must be above the configured minimum for removal
Cell Coupling Score It is calculated from the tier count, distance, and relative antenna orienta-
tions. It is also called Coupling Score.
HO Success Score The number of Handover Success counts on the proxy LTE-LTE intra-fre-
quency relation over the last 24 hour period.

Source Cell DN Complete distinguished name of the source cell.
Neighbor Cell DN Complete distinguished name of the neighbor cell.
Neighbor Frequency The frequency layer that the neighbor cell belongs to.
Layer
Table 54: IRAT Neighbor Performance
8.1.3.5 Logs
Table 55: Logs
8.1.3.6 Final neighbors

Table 56: Final neighbors (includes GSM-GSM neighbors and GSM-UMTS neighbors) describes the
columns present in the Final neighbors sheet.
Source cell The source cell name.
Neighbor cell The neighboring cell name.
Neighbor Category The neighbor category is IRAT.
Nbr Frequency Layer The frequency layer the neighbor cell belongs to.
• For LTE cells - the eARFCN


New Neighbor True indicates that a neighbor is added in the current iteration of the mod-
ule. False indicates that it is an existing neighbor.
Tier count Tier count to the neighboring cell. The Effective Tier count after Tier Count
Basic Tier Count Basic Tier count before Tier Count Adjustment.
HO Successes Handover Success count on this relation.
Neighbor Type The neighbor types are existing, added, and removed.
Reason Descriptive reason for neighbor additions (for example, First Tier, HO
Based, Topology/Tier2+, Missing Reciprocal).
Score It is calculated from the tier count, distance and relative antenna orienta-
tions. It is also called the Coupling Score.
Neighbor rank Indicates the ranking with the neighbor type (Intra, IRAT).
Source LMS Layer The layer from the LMS which the source cell belongs to.
Neighbor LMS Layer The layer from the LMS which the neighbor cell belongs to.
Neighbor LMS Condi- The condition from the LMS which permits the neighbor relation.
tion Name
LMS Max Nbr Size The condition from the LMS which determines the maximum neighbor size.
Cannot Remove Rea- Descriptive reason why any existing neighbors are unsuitable for removal.
son
CSFB with PSHO Indicates whether CSFB with PS handover to the related neighbor cell is al-
lowed or forbidden after optimization. The values are:
• Allowed
• Forbidden
Note: Mobility parameters will no longer have the Unchanged val-

ue.
Redirect system infor- Indicates whether the related neighbor cell is a candidate for providing sys-
mation tem information in case of UE redirection to UTRAN or GERAN after opti-
mization. The values are:
• Allowed
• Forbidden

Note: Mobility parameters will no longer have the Unchanged val-

ue.
Table 56: Final neighbors (includes GSM-GSM neighbors and GSM-UMTS neighbors)
8.1.3.7 Detected neighbors

Table 57: Detected neighbors describes the columns present in the Detected neighbors sheet.
Source Parent The parent entity of the Source Cell. For LTE cells, it is the eNodeB ID.
Neighbor Parent The parent entity of the Target Cell.
• For WCDMA cells - the RNC-ID

• For GSM cells - the LAC
Neighbor Cell The target cell name.
Layer
Reason Descriptive reason why the cell is considered for addition. Normally, it is First
Tier (through first tier addition phase), HO Based (through proxy relations) or
Topology/Tier2+ (other additions are done through the Tier map).
Cell Coupling Score It is calculated from the tier count, distance and relative antenna orientations.
It is also called the Coupling Score.
HO Success Score The number of Handover Success counts on the proxy LTE-LTE intra-fre-
quency relation over the last 24 hour period.
Neighbor List Modifi- Indicates whether the neighbor relation is added or not added.
cation

Neighbor List Modifi- Descriptive reason for Not Added (for example, the candidate does not out-
cation Reason perform the current lowest ranked neighbor).
Source Cell DN Complete distinguished name of the source cell.
Neighbor Cell DN Complete distinguished name of the neighbor cell.
Detection Method Describes the proxy relations used to detect missing neighbors. For example:
4G->4G (co-sector 3G on target) or 4G->4G (co-sector 2G on target).
Table 57: Detected neighbors
8.1.3.8 Changes
Table 58: Changes describes the columns present in the Changes sheet.
Source Parent The parent entity of the Source Cell. For LTE cells, it is the eNodeB ID.
Neighbor Parent The parent entity of the Target Cell.
• For WCDMA cells - the RNC-ID

• For GSM cells - the LAC
Neighbor Cell The neighboring cell name.
Layer
Reuse code • For WCDMA cells - the UARFCN + Primary Scrambling Code
• For GSM cells - the BCCH + BSIC

Tier Tier count to the neighboring cell. The Effective Tier count after Tier Count Ad-
justment has been applied. A tier of 10,000 means it is unreachable through
the tier map.
Modification Indicates whether the neighbor relation is added or removed.
Reason Descriptive reason for neighbor addition or removal.
Source Cell DN The complete distinguished name of the source cell.
Neighbor Cell DN The complete distinguished name of the neighbor cell.
Source Frequency Frequency layer that the source cell belongs to.
Layer
Detection Method Describes the proxy relations used to detect missing neighbors.
For example: 4G>4G (co-sector 3G on target) or 4G>4G (co-sector 2G on tar-

get).
HO attempts Number of HO Attempts to the neighbor cell.
Table 58: Changes

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Viewing LTE ANR events
9 Viewing LTE ANR 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 LTE ANR modules.
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):

d) Click Log In.
The EdenNet application opens displaying the SON Activity page.
2. Click the Events tab.
A list of filters appears in the left pane.
3. From the Module/Service drop-down list, select the LTE ANR 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 the levels of events, clear 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 click the Save As New
Filter option to save the filter.
6. Click Filter.

Expected outcome
The events are listed based on the selected filter. For more information, see LTE ANR events.
9.1 LTE ANR events

• ANR Blacklisting and Cleanup LTE module events

• LTE ANR Frequency Rules module events
• ANR 4G IRAT module events
9.1.1 ANR Blacklisting and Cleanup LTE module events

Table 59: ANR Blacklisting and Cleanup LTE module events describes the events of the ANR Black-
listing and Cleanup LTE module
Category: ANR_Blacklisting_and_Cleanup_LTE
Name Level Description
Module crash error The module crashed.
EMS validation errors error The module has EMS validation errors.
Plan push failures error The module has plan push failures.
Skipped Target info The target is skipped because the source cell has
invalid neighbor relations.
Proposed Change Details info This event contains the blacklisted and unblacklist-
ed relation details.
neighbor_removal info A neighbor relation is removed.
Module Iteration Finished info The module run is completed. Since the module is
recursive, there are multiple entries for the same
instance.
X2_blacklisted info An X2 link is blacklisted.
Module Exception info The module has failed. Check the module logs for
more details.
Table 59: ANR Blacklisting and Cleanup LTE module events

9.1.2 LTE ANR Frequency Rules module events

Table 60: LTE ANR Frequency Rules module events describes the events of the LTE ANR Frequency
Rules module
Category: LTE_Frequency_Rules
Module crash error The module crashed.
EMS validation er- error The module has EMS validation errors.
rors
Plan push failures error The module has plan push failures.
Table 60: LTE ANR Frequency Rules module events
9.1.3 ANR 4G IRAT module events

Table 61: ANR 4G IRAT module events describes the events of the ANR 4G IRAT module
Category: ANR_4G_IRAT
Failed to push changes! critical When provisioning fails during closed loop.
Attempted changes did critical When the EMS validation before the actual provisioning fails.
not pass EMS valida-
tion. See log for details.
Could not evaluate cell error If the cell does not satisfy all the initial ANR validations or if it
has a relation pointing to an invalid target cell then the cell is
skipped from optimization.
could_not_build_mos error Whenever there is an exception while building MOs.
No first tiers error When there are no first tiers for the source cell.
No n tiers error When the n tier cannot be fetched for the cell with validation er-
rors.
neighbor_relation_unre- warning When the target cell of the relation is an unknown cell, the in-
solved ternal cell representation is not present in any OSS.
Could not trim neighbor warning When the module is not able to trim targets to the configured
list value.
Could not add particular warning When the target cell is not added because of LMS or module
neighbor configuration constraints.
For example:
• Could not add First Tier Neighbor


• Could not add White List Neighbor
Neighbor change event info Generates a cell event to indicate neighbor addition, removal,
or updation. The event type is added, updated, or removed.
For example:
• LTE_UMTS_Neighbor_Added
• LTE_UMTS_Neighbor_Updated
• LTE_UMTS_Neighbor_Removed
• LTE_GSM_Neighbor_Added
• LTE_GSM_Neighbor_Updated
• LTE_GSM_Neighbor_Removed
Optimizer Exception info An Optimizer exception while building MOs.
Attempted changes did info When the EMS validation before the actual provisioning fails.
not pass EMS valida-
tion. See log for details.
Module Exception info The module has failed. Check the module logs for more details.
Could not remove poor- warning Basic neighbor removal check failed.
ly performing neighbor
Table 61: ANR 4G IRAT module events

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Viewing SON change reports
10 Viewing SON change reports

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

OSS):

d) Click Log In.
2. Click SON Modules → Reports.
The Network Analysis page is displayed.
3. In the left pane, click Modules, select the required module from the below options, and click
Apply.
Or
• ANR_4G_IRAT
Expected outcome
The SON changes for the selected module are displayed in a tabular format.
10.1 Cell level records

The ANR 4G IRAT module reports the records at cell level as defined in Table 62: Cell level records
for ANR 4G IRAT. The cell level records can be viewed from the Reports tab of the EdenNet GUI. See
the View reports section in the EdenNet User Guide for more details.

Scenario Description
Cell neighbor list evalu- <cell1> is evaluated and neighbor list changes are made and/or missing
ated neighbors are detected.
Detected <W> neighbors. Added <X> neighbors and removed <Y> neigh-
bors.
Example: PCH99221A22 is evaluated and neighbor list changes are

made and/or missing neighbors are detected.
Detected 4 neighbors, added 4 neighbors and removed 0 neighbors.
Note: The module generates the record in the Report tab only
for the cell which is evaluated under the following conditions:
• when there are changes to the cell

• when missing neighbors are detected and cannot be added
The Network Analysis tab shows the record, although there is

no change pushed to the network.
Cell excluded <cell1> was excluded from evaluation due to: <reason for exclusion>
Example: PCH19704A21 was excluded from evaluation due to: Could not
trim (PCH19704A21) because sufficient neighbors could not be removed
to meet the max total size limit.
Note: The cell can be excluded for several reasons including:
• on SON Exclusion List

• on Module Exclusion List
• cannot be trimmed
• missing required data
Table 62: Cell level records for ANR 4G IRAT
The ANR_Blacklisting_and_Cleanup_LTE module reports the records at cell level as defined in Table
63: Cell level records for ANR_Blacklisting_and_Cleanup_LTE. The cell level records can be viewed
from the Reports tab of the EdenNet GUI. See the View Reports section in the EdenNet User Guide
for more details.
Neighbor Removal The ANR_Blacklisting_and_Cleanup_LTE module will generate the cell

level record in the Report tab for the cell which is evaluated and then pro-
pose changes for deletion. The Network Analysis tab shows the record
(only in closed loop mode).

Neighbor Blacklisted/ Blacklist Message: Neighbor cells <List of target cell names> are blacklist-
Neighbor UnBlacklisted ed from the source cell <source cell name> based on the LTE ANR Black-
listing module decision.
Unblacklist Message: Neighbor <List of target cell names> are unblacklist-

ed from the source cell <source cell name> based on the LTE ANR Black-
listing module decision.
Example: Neighbor cell VC46722 is blacklisted from the source cell Ver-
celli-032 based on the LTE ANR Blacklisting module decision.
Neighbor cells VC19081, VC19122, VC19084, VC10562 are unblacklisted

from the source cell Vercelli-031 based on the LTE ANR Blacklisting mod-
ule decision.
Note: The ANR_Blacklisting_and_Cleanup_LTE module will

generate the record in the Report tab for the cell which is eval-
uated and then propose changes for blacklisting or unblacklist-
ing . The Network Analysis tab shows the cell level record,
though there is no change pushed to the network.
Table 63: Cell level records for ANR_Blacklisting_and_Cleanup_LTE

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Monitoring LTE ANR modules
11 Monitoring LTE ANR modules

You can monitor the activities, status, and events of the LTE ANR modules.
For more information, see the Configure and monitor SON modules section in the EdenNet User and
Administration Guide.
To view the Network Analysis table for the ANR 4G IRAT module or the ANR Blacklisting and Cleanup
LTE module, see the Viewing network analysis details section in the EdenNet User and Administration
Guide. It provides information about the reasons behind the changes pushed by the EdenNet mod-
ules.
To view the execution status, which provides the Instance Name and State of a selected module, as
well as the SON module's script log detailing the actions taken on individual target cells, see the View-
ing the execution status section in the EdenNet User and Administration Guide.
11.1 Module Monitor Service

This service performs pre-defined checks on the CM data and cell plan data either periodically or up-
on reception of new CM data. When the module runs, the service is queried, and messages indicating
problems or potential problems are inserted at the beginning of the module log.
The problems are categorized into two levels:
• Error: causes the module to stop working and log the incident that caused the module to stop.
• Warning: logs a detailed warning in the instance log.
Currently, only per cell warnings are defined for Module Monitor Service for ANR. These are:
• Triggered at reception of new CM data:
– Cell has no location (latitude, longitude) (indicates that the location in the cell plan should be
checked).
• Triggered once every 24 hours:
– Cell has no first tier information (indicates that the location in the cell plan or tier count service
should be checked).
– Cell does not have any intra-frequency neighbors.
– Cell does not have any inter-frequency neighbors.
– Cell does not have any IRAT type neighbors.
– Cell does not have neighbors of any type.
– Cell has large tier counts for close surrounding cells (indicates that tier count service should
be checked).

LTE Automatic Neighbor Relations Guide DN09238435 1-0 Troubleshooting ANR
12 Troubleshooting ANR
This section describes how to troubleshoot the ANR modules.
12.1 ANR tries to create relations that already exist

Problem
When ANR is run iteratively, it tries to create the same relations in every iteration. This results in provi-
sioning failure from the second iteration onwards. However, if ANR is triggered again after a few hours,
it proposes the correct relations and provisioning succeeds.
Possible scenarios:
The neighbors table is not updated properly because relation creation notifications are getting
dropped.
Solution
1. Log in to the central App Server.

2. Switch to vson user by entering:
su - vson
3. Restart the mo_event_distributor_app by entering:
enet restart {region_name}.cm.mo_event_distribution_app
The provisioning is successful.

Eden Net Lte Anr Guide

Uploaded by

Document Information

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 Lte Anr Guide

Uploaded by

Copyright:

Available Formats

EdenNet 21

LTE Automatic Neighbor Relations Guide

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 LTE ANR................................................................................................................................... 15

3 LTE ANR functional description and guidelines........................................................................................30

4 LTE ANR algorithms......................................................................................................................................34

EdenNet 21 © 2021 Nokia 3

4.2.4 Frequency rule update through LMS..............................................................................................42

5 LTE ANR execution....................................................................................................................................... 56

6 LTE ANR configuration parameters.............................................................................................................62

EdenNet 21 © 2021 Nokia 4

7 Viewing LTE ANR targets............................................................................................................................. 93

8 Viewing LTE ANR reports.............................................................................................................................94

9 Viewing LTE ANR events............................................................................................................................119

10 Viewing SON change reports...................................................................................................................123

11 Monitoring LTE ANR modules..................................................................................................................126

EdenNet 21 © 2021 Nokia 5

11.1 Module Monitor Service...................................................................................................................... 126

EdenNet 21 © 2021 Nokia 6

Release Change description

EdenNet 21 Updated sections:

• Overview of LTE ANR: A note is added about the deprecation of direct

EdenNet 20 FP 2011 Updated section:

• Configuring relation DN ID for Ericsson (4G)

EdenNet 20 FP 2010 Updated section:

EdenNet 20 FP 2009 No change.

EdenNet 20 FP 2008 No change.

EdenNet 20 FP 2007 Updated section:

• ANR 4G IRAT INI parameters: A note is added to the description of the

EdenNet 20 Updated sections:

• Overview of LTE ANR Frequency Rules module

• Whitelist and blacklist target frequencies file

EdenNet 21 © 2021 Nokia 7

Release Change description

• Frequency rule creation based on instance ID

EdenNet 19A FP 2004 Updated section:

• ANR 4G IRAT INI parameters: A new parameter (Configurable_re-

• Configuring relation DN ID for Ericsson (4G)

EdenNet 19A FP 2003 No change.

EdenNet 19A FP 2002 Updated section:

• ANR 4G IRAT INI parameters: The description of the following parame-

EdenNet 19A FP 2001 No change.

EdenNet 19A FP 1912 Updated sections:

• ANR 4G IRAT INI parameters: The TimeBetweenPushes_15Mins pa-

– Maximum deletions per cell is changed to Max deletions

EdenNet 19A FP 1911 Updated sections:

• ANR 4G IRAT INI parameters: The following parameters are added:

EdenNet 19A Updated sections:

• The Frequency object deletion file section is updated.

EdenNet 21 © 2021 Nokia 8

Release Change description

EdenNet 19 FP 1907 No change.

EdenNet 19 FP 1906 No change.

EdenNet 19 FP 1905 Description of the Reliability threshold parameter is updated.

EdenNet 19 FP 1904 Added sections:

• Cross OSS support for ANR 4G IRAT (with NAdC)

• Instances of Custom modules are changed to Adapted modules in the

– Accessing LTE ANR modules

• ANR Blacklisting and Cleanup LTE GUI parameters

EdenNet 19 Updated sections:

• A new INI parameter (consider_HO_or_tier_for_neighbor_

– Execution flow of ANR Blacklisting and Cleanup LTE module