Enhancements to SON
Cases in SON ANR and SON PCI
Niraj Nanavaty
BTS Security Specification
NSN
Bangalore, India
Niraj.nanavaty@nsn.com
Abstract — The paper highlights two problems in the domain of
Self-Organizing Networks (SON) – one in SON ANR (Automatic
Neighbor Relations) feature and the other in SON PCI (Physical Cell
Identifier) feature and proposes resolutions to these problems.
It was observed during a customer issue resolution that SON
ANR could lead to multiple copies of the same neighbor data coming
from different neighbors. There is no method specified in 3GPP
specification currently to circumvent this problem. First part of the
paper will address this issue by describing a method to identify the
latest or oldest version of the data and thus using one copy and
discarding the rest.
It was also observed during a customer feature development that
life would become much easier for SON PCI feature if change in a
cell’s PCI either due to SON PCI Conflict Resolution Preview Mode
feature or due to operator intervention, was communicated to all its
neighbors through X2 interface or possibly, S1 interface. The second
part of the paper deals with this issue by suggesting a solution that
dictates sharing Proposed PCI with neighbors. This enhancement is
especially useful when Proposed PCI is yet to be ratified by operator.
Keywords—SON, ANR, PCI, CNL, NRT
I. INTRODUCTION
Self-Organizing Networks (SON) is a vast domain that
addresses many network management and performance issues
through automation. SON includes many features. Following
are some of these features [1]:
 Load Balancing Optimization (LBO): This feature
supports optimization of load balancing for
Overlapping Coverage, Hierarchical Coverage and
Neighboring Coverage scenarios in intra-frequency,
inter-frequency, and inter-RAT deployment cases.
 Handover (HO) Parameter optimization: This feature
supports reduction in number of HO failures that cause
degradation in user experience, such as call drops,
radio link failures during or shortly after HO, and
reduced data rates and aids in reducing inefficient use
of network resources due to unnecessary handovers.
This feature is also known as Mobility Robustness
Optimization (MRO).
 Interference control: This feature supports uplink inter
cell interference coordination (ICIC) and downlink
inter cell interference coordination.
 Capacity and coverage optimization (CCO): This
feature helps identify E-UTRAN Coverage holes with
2G/3G coverage, E-UTRAN Coverage holes without
any other radio coverage, E-UTRAN Coverage holes
with isolated island cell coverage and E-UTRAN cells
with too large coverage and allows to take remedial
actions – mostly automatic but at times, requiring
operator intervention.
 RACH optimization: This feature helps optimize
Random Access Channel (RACH).
 Automatic Neighbor Relation (ANR): This feature
supports monitoring of cell signal quality data as
reported by mobile device and adding a neighbor cell
in neighbor relation table (NRT) or deleting a neighbor
cell from NRT when certain thresholds on cell signal
quality are crossed.
 Physical Cell Identifier Management (PCI): While
this feature is not distinctly specified in 3GPP, NSN
supports this unique feature to allocate and manage
Physical Cell Identifier to LTE cells in automatic
manner. The feature also includes detection and
resolution of PCI Conflict.
This paper focuses on two major SON features – SON
ANR and SON PCI. It was observed during a customer issue
resolution that SON ANR could lead to multiple copies of the
same neighbor data coming from different neighbor cells.
There exists no method in 3GPP specification currently to
circumvent this problem. Next section of the paper addresses
this issue by describing a method to identify the latest or oldest
version of the data and thus using that copy and discarding the
rest.
 II. CUSTOMER PROBLEM, SON ANR ALGORITHM, ISSUE
AND IMPROVEMENT
The focus of this section is to state the customer problem,
explain SON ANR algorithm, highlight an issue with this
algorithm and propose an improvement to the algorithm.

A. Customer Problem
 One of NSN’s preferred LTE customers observed increased
activity on the EMS (Element Management System).
Investigation revealed that the root cause was increased
uploads of eNodeB configuration file to the system in a day.
Increase observed in uploads was around 70% (25K-50K
actual uploads instead of expected 15K-30K in a day). Many
eNodeBs (400 to 600 eNodeBs) were affected. eNodeB
configuration file is typically uploaded from eNodeB to EMS
whenever its contents change. After further deep dive, it was
found that eNodeB configuration file was changing because
cell neighbors were getting updated frequently (more than 10
updates in a day). Finally, it was concluded that there were
many reasons behind heavy and continuous churn to cell
neighbors. One reason could be an issue with the SON ANR

Figure 1 SON ANR problem Message Sequence

algorithm. This paper investigates this aspect only. Readers are

encouraged to contact the author for details on complete
account of all the reasons!

B. SON ANR Algorithm

It would be worthwhile to understand NSN SON ANR

algorithm [2] at this juncture.
 Table 1 New 3GPP Information Element
Served Cells To Complete list of added cells
Add served by the eNB
EXISTING
>Served Cell M EXISTING
SON ANR algorithm increments the applicable SON ANR D. Information
scoring metrics for each cell neighbor identified in the UE >Neighbour EXISTING
Measurement Report. Processing a UE Measurement Report Information
includes the following SON ANR functions, which are >>Temporal O An Identifier that uniquely
conditionally applied to strongest unknown neighbor cell in the Identifier identifies this information
UE measurement report: temporally uniquely
NEW
 Create a new Composite Neighbor List (CNL) entry
Served Cells To Complete list of modified
 Request the UE to resolve the PCI into ECGI Modify cells served by the eNB
EXISTING
Then, SON ANR operates in two modes: >>Temporal O An Identifier that uniquely
Identifier identifies this information
 ANR Automatic Mode: When the eNodeB cell
temporally uniquely
discovers a new neighbor, which has achieved the
NEW
criteria for the Neighbor Relation Table (NRT), or the >Served Cell M EXISTING
eNodeB receives an X2 message that identifies a Information
serving cell as a neighbor and the far end cell has >Neighbour EXISTING
achieved the criteria for the NRT, the new neighbor is Information
automatically added. >>Temporal O An Identifier that uniquely
 ANR Preview Mode: When the eNodeB cell discovers Identifier identifies this information
a new neighbor, which has achieved the criteria for the temporally uniquely
NEW
Neighbor Relation Table (NRT), or the eNodeB
Served Cells To Complete list of deleted
receives an X2 message that identifies a serving cell as
Delete cells served by the eNB
a neighbor and the far end cell has achieved the criteria EXISTING
for the NRT, the operator is notified. Once the operator >>Temporal O An Identifier that uniquely
confirms the entry, the new neighbor is added. Identifier identifies this information
Note that the SON ANR algorithm operates throughout the temporally uniquely
day and can result in the addition of neighbors to the NRT at NEW
any point in the 24-hour day. Updated NRT is distributed to
neighbors. It is evident that if multiple cells discover the same
neighbor and exchange updated neighbor list, it is possible that
NRT may contain multiple entries for the same neighbor. Note
that due to complex network structure, neighbor data may
arrive in random order so it becomes impossible to determine
latest or oldest entry based on time of receipt.

C. Issue in SON ANR algorithm

Let us take an example to understand the issue. A cell, say

cell A adds an entry to neighbor relation table. All neighbor
cells of this cell receive the newly added neighbor relation
table entry. In turn, they may propagate this information to
their neighboring cells and so on. Now, another cell, say cell B
deletes the same neighbor and propagates this information to
all its neighbors. Yet another cell, say cell C is neighbor to both
the cells – cell A and cell B and receives two copies of the
same neighbor – one indicating addition of the neighbor and
the other indicating deletion of the same. Both these entries are
written in local neighbor relation table (NRT). To operate
reliably, cell C needs to keep only one of these copies and
discard the other. It is apparent that there could be more than
two entries for the same neighbor in neighbor relation table but
finally, only one should exist. However, current algorithm is
limited by keeping all the entries and thus repeated addition
and deletion will be observed by this neighbor and the similar
phenomenon will propagate through the network resulting in
frequent eNodeB configuration file updates followed by
uploads to the EMS.
Figure 2 SON ANR Solution Message Sequence
Improvement to SON ANR algorithm
SON ANR algorithm could use a Temporal Identifier for
each neighbor relation table entry that is communicated to
neighboring cells. Each cell uses this identifier to sort neighbor
relation table entries and picks only the latest or oldest
depending on the context and configuration. Such an identifier
includes but is not limited to UTC time stamp or version
number. The algorithm stabilizes the change in neighbor
relation table thus the change in eNodeB configuration files.
Stretching the logic further, it could be easily seen than this
improvement to the algorithm will solve the problem faced by
the customer.
For example, when a cell, say cell A adds an entry to
neighbor relation table, it also adds current UTC time stamp.
All neighbor cells of this cell receive the newly added neighbor
relation table entry and UTC time stamp. In turn, they may
propagate this information to their neighboring cells and so on.
Now, another cell, say cell B deletes the same neighbor but
with different UTC time stamp and propagates this information
to all its neighbors. Yet another cell, say cell C is neighbor to
both the cells – cell A and cell B and receives two copies of the
same neighbor – one indicating addition of the neighbor and
the other indicating deletion of the same. Both these entries are
written in local neighbor relation table (NRT). To reconcile
these two copies, cell C uses time stamp to keep one of these
copies (older or newer depending on the context and
configuration) and discard the other. It is apparent that this
would stabilize NRT and thus would not cause the problem
experienced by the customer.
It would be interesting to note that the solution could be
extended to other SON feature like SON PCI as well. For
example, when a cell is created and a PCI is allocated, the PCI
will also be identified with a UTC time stamp when it was
created. All neighbor cells of this cell receive PCI and UTC
time stamp. In turn, they may propagate this information to
their neighboring cells and so on. If the PCI is changed, new
PCI will be identified with new UTC time stamp of when the
change was made and the cycle starts again. Meanwhile, if
some other cell receives this PCI from its multiple neighbors,
the PCI with the latest UTC time stamp will be considered as
the latest and used. This will avoid conflict arising due to the
same cell reporting different PCIs with only one being the
latest and valid while rest being stale PCIs. Refer to Figure 1
SON ANR problem Message Sequence and Figure 2 SON
ANR Solution Message Sequence for details.
The 3GPP messages like ENB CONFIGURATION
UPDATE, X2 SETUP REQUEST and X2 SETUP RESPONSE
could be updated with new element as depicted in Table 1 New
3GPP Information Element.
III. CUSTOMER FEATURE ON SON PCI AND POTENTIAL
ENHANCEMENT
The focus of this section is to explain the customer feature
on SON PCI and potential enhancement to the feature that
makes the solution comprehensive and rich.
A. Customer Feature on SON PCI
LTE eNodeB typically contains 3 cells. Each cell is
identified with a unique PCI. SON PCI feature supports
automatic allocation and management of PCI. 256 PCI values
(0 to 255) are possible as PCI is 8-bit number. In large operator
LTE deployment scenario, there could be thousands of
eNodeBs in the system. Due to such large scale deployment of
eNodeBs, at times, two or more non-co-located cells could end
up with the same PCI value.
If a cell detects that it shares PCI with the other cell, it is
called that the cell has detected PCI Collision.
If a cells detects that its neighbors share PCI, it is called the
cell has detected PCI Confusion.
Both of these situations are collectively referred to as PCI
Conflict. There are multiple approaches to resolve PCI
Conflict:
 Automatic PCI Conflict Resolution – One of the cells
in PCI Conflict (usually the cell with the highest
ECGI) changes its PCI value automatically while the
other cells backoff randomly. This cell informs new
PCI value to other cells. The cell is no longer in PCI
Conflict. The cycle repeats with remaining cells until
no cell remains in PCI Conflict.
 Preview PCI Conflict Resolution [3] – One of the cells
in PCI Conflict (usually the cell with the highest
ECGI) identifies a unique PCI value, typically referred
to as Proposed PCI and proposes it to the operator
while the other cells typically backoff for a very long
time to allow operator to react. The operator could,
then, accept, modify or simply ignore the proposed PCI
value. If the operator accepts the proposal, the cell is
no longer in the conflict and the cycle repeats for
remaining cells until no cell remains in PCI Conflict.
Alternatively, the operator may change PCI values of
all the cells in PCI Conflict to resolve the conflict
manually.
While Automatic PCI Conflict Resolution is fast and
propagates through the network instantaneously, it could result
in a wave of PCI value changes across the network (ripple
effect) making it unstable.
Preview PCI Conflict Resolution is inherently slow but
could avoid the issue faced by Automatic PCI Conflict
Resolution. However, it is also not without any drawback as
highlighted in subsequent sub-section.
B. Potential Enhancement
When PCI conflict is resolved through the operator driven
approach as explained in previous section, until operator
intervention, the proposed PCI is neither committed on the RF
nor communicated to neighbor eNodeBs via X2 interface. It is
also not communicated to any NBI (North-Bound Interface)
device like network planner. This could result in some other
cell choosing the same PCI during PCI conflict resolution or
NBI device like network planner assigning the same PCI to
newly upcoming cell and thus causing further PCI Conflict in
the future.
The proposed method is to include Proposed PCI for a cell
also in X2AP messages like X2 Setup Request, X2 Setup
Response and eNodeB Configuration Update over X2
interface. This would allow the neighboring cells to be aware
of this Proposed PCI and exclude it from using when PCI
conflict situation arises.
The method also proposes to propagate this information
over NBI so that newly upcoming cell does not use this PCI.
Note that NSN LTE system deployed in KDDI today
supports sending an alarm to the operator in PCI conflict
situation however, it is limited to EMS (LteMgr) and does not
propagate further into NBI.
 ACKNOWLEDGMENT REFERENCES
Many engineers worked on the issue and the feature [1] 3GPP Specification, 3GPP TS 32.521 V11.1.0 (2012-12) “Self-
mentioned in the paper so it is very difficult to single out one Organizing Networks (SON) Policy Network Resource Model (NRM)
Integration Reference Point (IRP); Requirements”
person. I acknowledge the entire SON team for their
[2] NSN (estwhile Motorola) SON ANR/PCI Features - FR 34277, FR
contributions that made writing this paper possible. 35510, FR 13441
[3] FR12996 – NSN (estwhile Motorola) SON PCI Conflict Resolution
Preview Mode Feature