STUDY PAPER

ON

Self Organising Network

By:

Ranjana Sridhar

ADET(P),

MDivision, TEC
 Self Organising Network

1. Introduction

The concept of Self organizing networks (SON) has picked up only after the transition from 3G
to 4G started. This was because of the exponential increase in the data traffic which required a
change in the way the network coverage and capacity were planned. Huge volumes of data
traffic clogged up the network while not leading to proportional increase in the revenue. This
required a rethink on how the network was managed so that a reduction in OPEX could be
achieved. Also, the data traffic pattern is very different from the voice traffic pattern and it
requires a different approach towards network planning. A data centric network requires a
large number of small base stations with small coverage area which provide high capacity that
may fit inside homes/offices or are present at airports/cafes/public places etc. The problem
that arises is in the backhaul connectivity and in the management of the large number of small
base stations so that optimum capacity and coverage can be provided while minimizing
interference from nearby cells (eNodeBs). These problems can be mitigated through the use of
Self organizing networks which help in faster deployment and rollout of the network with lesser
human intervention. They also help in automating subsequent tuning of the network which is
required to maintain optimum coverage and capacity with respect to the number of users.

2. SON Definition:

Because of the large number of parameters involved, the process of automating the network
planning is gaining support. Self organizing network (SON) is a concept where automated
processes enable a constant monitoring of service and network performance and analyses data
collected from different parts of the network providing useful feedback that can be used for
making decisions. SON capabilities aim to support mobile broadband business priorities and
manage network complexity in a smart way. It leaves operators free to focus on providing an
excellent user experience as the management of multi technology; multi vendor network is
simplified and streamlined. Fig. 1 shows the continuous process which is SON. Fig 2 shows how
SON replaces human effort through automation.

1
 Fig 1. Concept of Self Organisation

Fig 2. SON-Facilitating Automation instead of Human Efforts

3. General Guidelines

To implement the SON concepts in a network, SON algorithms are developed which have to
follow some general guidelines so that the implementation of SON as a whole, benefits the
network. The guidelines include the technical requirements, the business requirements and

2
also, the assessment criteria so that performance comparison between the SON algorithms can
be done.

3.1 Technical Requirements of SON Algorithms:

a) Performance and complexity requirements: For all SON use cases, an appropriate
balance should be maintained between the performance gains accrued by adding SON
functionality and the resulting implementation complexity. Implementation complexity
can be measured by means of e.g., the extra signalling over the radio interface and
transport network, computational effort, memory requirements and storage
requirements, required measurements.

b) Stability requirements: Since SON works in a feedback loop the parameters altered by
SON algorithms and their resulting impact should reinforce each other i.e move towards
the same goal. Else the parameter values will oscillate and not reach a stable optimised
value.

c) Robustness requirements: The SON algorithms should be capable of identifying

corrupted or wrong measurements so that algorithm can still provide the correct
output.

d) Timing requirements: The time frame, over which the SON algorithm functions, ranges
from milliseconds to days depending on the use case. For the coverage and capacity
optimisation use case for example, the algorithm responds at a time scale which is in
weeks as it analyses and responds to the changes in the radio environment. For the
mobility load balancing optimisation. The cell outage compensation algorithm for
example should determine new parameter settings sufficiently fast, meaning in the
order of seconds or at most minutes, after being triggered by the cell outage detection
algorithm.

e) Interaction requirements: Coordination between all the algorithms that modify the
same parameters or influence the same performance is needed so as to ensure that the
parameters or the performance is not pulled in opposite directions. In such a case a
conflict is said to occur. Therefore, rules to handle such conflicts should be specified. For
example, the cell outage compensation algorithm may adjust pilot powers to direct
traffic to non-outage cells, upon which the load balancing algorithm may respond to the
induced traffic load imbalances with undesirable countermeasures.

3
f) Architectural and scalability requirements: SON algorithms can be implemented in a
central or a distributed way. For centralised implementations, centralised monitoring,
data storage and data analysis capabilities are required. If the algorithms are
implemented in a distributed way, appropriate computing power, memory and storage
capacity at the NEs are required.

g) Required inputs: Each use case has its individual input requirements. For example, for
the coverage and capacity optimisation usr case, the inputs required include the current
radio configuration parameters, performance information and measurements of the
considered NEs and cells, topology and geographical data, network usage patterns and
measurements from the mobiles.

3.2 Business Requirements

Business requirements also need to be considered as solutions that are good in a technical
manner may not be feasible commercially. The business requirements are divided into cost
efficiency requirements and LTE deployment requirements.

a) Cost efficiency requirements: If the cost of rolling out and maintaining a network is too
high, it becomes difficult to provide a profitable consumer service on the network. This
leads to the requirement:
- SON solutions should reduce OPEX by reducing the effort that is required to roll
out and operate a network.
b) SON solutions should reduce CAPEX (Capital Expenditure): This is because once SON is
implemented it will use the radio resources efficiently and hence will require fewer base
stations. However, adding SON functionality will potentially increase the cost of
equipment, including terminals, base stations and operations and maintenance systems,
due to the need for additional hard- and/or software. Therefore, SON impact on the
cost of the entire mobile network should be considered.

3.2.1 LTE deployment: As SON is critical to LTE, it is also necessary to consider the effect
of SON in deployment of LTE networks, we get the following SON requirements:
- The roll-out of LTE networks should be sped up: when a network is first rolled
out, there are usually many problems to solve before satisfactory performance is
achieved. SON solutions should reduce these problems, and reduce the
deployment time.
- SON solutions should simplify processes: Self-organisation functionalities should
be developed and embedded in the network such that operational tasks are
simplified.

4
 - New services should be easily deployable: new services may have new QoS
requirements, which the SON solutions should be able to support with minimum
required configuration.
- The end user should benefit: the users should experience high GoS/QoS.

3.3 Assessment criteria for self-organising networks

To assess the benefits of implementing self-organisation methods in the network, a set of

well-defined metrics and appropriate reference cases (benchmarks) are required. The most
important metrics assess network capacity, coverage, service quality and OPEX/CAPEX. A
set of well-defined metrics helps in the comparison of different SON algorithms with
respect to each other while the presence of a reference case allows the evaluation of gains
from self organisation with respect to contemporary and manually operated networks. In
this section, the key performance metrics that are relevant in the assessment of self-
organisation methods are organised in different categories: performance metrics, coverage
metrics, capacity metrics and OPEX/CAPEX.

a) Performance metrics: These include quality of service metrics, e.g., packet delay
statistics, packet loss ratio, transfer time statistics, fairness, throughput statistics,
mean opinion score, grade of service, e.g., call blocking ratio, call dropping ratio,
which express the service level experience from the user perspective.

b) Coverage metrics: Different types of coverage metrics exist, e.g., the service
coverage, i.e., the fraction of area where a given service can be supported with
adequate service quality and the data rate coverage, i.e., the fraction of area where
a user can experience some specified data rate.

c) Capacity metrics: Cell (or network) capacity is can be defined in several ways which
are enumerated below:
a. Maximum number of concurrent calls: For a given scenario in terms of
network layout, propagation environment, service mix, traffic characteristics
and spatial traffic distribution, the cell capacity is given by the maximum
number of concurrent calls in each cell that can be supported under a pre-
specified quality of service requirement.
b. Maximum supportable traffic load: For a given scenario, now including the
call level dynamics that are due to the random initiation and completion of
calls, the cell capacity is given by the maximum aggregate call arrival rate in
each cell that can be supported under pre-specified quality of service and
grade of service requirements.

5
 c. Spectrum efficiency: Having obtained the maximum number of concurrent
calls (see above), the spectrum efficiency is equal to the corresponding
aggregate net bit rate per cell, divided by the system bandwidth.
d) CAPEX: In general, CAPEX encompasses the investments made to create future
benefits, including e.g., radio and core network elements. The following should be
considered when estimating CAPEX associated with a self-organisation solution:
a. A proposed approach to estimate CAPEX is to determine the number of
network elements that is needed to cover a certain service area with pre
specified grade and quality of service requirements, and multiply this with
the corresponding costs. Given a certain service demand per km2, the
required number of network elements can be determined by maximising the
cell radii such that traffic demand per cell and cell capacity are sufficiently
well balanced to meet the grade and quality of service requirements,
following similar evaluation methods as proposed for the above-mentioned
capacity definitions.
b. An additional aspect to consider is that the introduction of self organisation
features themselves may lead to an increase in equipment cost (per unit).
The additional CAPEX is hard to estimate, but depends on the nature and
complexity of the self-organisation algorithm, the transmission bandwidth
requirements that may be higher due to increased signaling overhead, and
additional costs related to needed site equipment, e.g., electrical antenna
tilt and additional circuitry for enabling power savings.

e) OPEX: The costs associated with the network operations and, in particular, the
reduction of these costs due to the introduction of self-organisation functionalities,
are rather difficult to assess. Noting that actual OPEX reductions depend on the
degree of self-organisation that is deployed, in an extreme implementation, all
OPEX related to manual adjustment of a given parameter set (associated with a use
case) is removed. In order to develop an approach to assess the OPEX level, we
distinguish between three main phases in effectuating parameter adjustments, i.e.,
gathering input data, e.g., via performance counters, drive tests or planning tools;
determining new parameter settings, using (some combination of) manual
adjustments and/or computer-aided adjustments using planning tools or advanced
simulation models; and applying new parameter settings, which may be done
remotely or requires a site visit.
Depending on the applied methods, a use case-based estimation of the human
effort in man hours involved in the three distinct phases can be made by the
operator. Multiplied by the effective cost per expert hour, the number of times per
year such a parameter adjustment is needed and a multiplication factor that
reflects the number of cells (or cell classes) for which separate parameter
adjustments need to be made, yields the OPEX per year for the considered use case.
In case self-organisation functionalities are applied, their specific impact on the
above-mentioned distinct components that contribute to OPEX should be assessed.
6
 For some components the required human effort is significantly reduced, while for
others it remains unchanged.

4. SON Architectures
The self-organization functionality can be located a whole or even split and located in different
nodes. Self-Optimization algorithms can be located in OAM or eNB or both of them. According
to the location of optimization algorithms, SON can be divided into the three main architecture
versions: Centralized SON, Distributed SON and Hybrid SON.
In the three versions of SON, the similarities and differences in the self-optimization
functionality (SOF) with respect to data acquisition, data processing and configuration
management are presented.

4.1 Centralized SON

In Centralized SON, optimization algorithms are stored and executed from the OAM
System. Here, the SON functionality resides in a small number of locations, at a high level in
the architecture. Fig. 3 shows an example of Centralized SON.
In Centralized SON, all SON functions are located in OAM systems, so it is easy to deploy
them but does not support those simple and quick optimization cases. To implement
Centralized SON, existing Northbound Interface (Itf-N), which is the interface between the
Element Manager and the Network Manager, needs to be extended. Also, as the number of
nodes in the network increases, computational requirements will also increase, which might
cause problems in scalability.

Fig. 3 Centralized SON Architecture

4.2 Distributed SON

7
In Distributed SON, optimization algorithms are executed in eNB i.e SON functionality
resides in many locations at a relatively low level in the architecture. This increases the
deployment efforts. Fig 4 shows an example of Distributed SON. When this architecture is
implemented in large number of nodes, it has to be ensured that there is coordination
between them so that the network as a whole is optimised.

Fig. 4 Distributed SON Architecture

4.3 Hybrid SON

In Hybrid SON, part of the optimization algorithms are executed in the OAM system, while
others are executed in eNB. Fig 5 shows an example of Hybrid SON. In Hybrid SON, simple
and quick optimization schemes are implemented in eNB and complex optimization
schemes are implemented in OAM so as to provide flexibility to support different kinds of
optimization cases. But on the other hand, it costs lots of deployment effort and interface
extension work.

Fig 5. Hybrid SON architecture

8
5. Types of SON:

SON solutions can be divided into three categories:

I. Self-Configuration,
II. Self-Optimisation and
III. Self-Healing.

5.1 Self-configuration process is defined as the process where newly deployed nodes are
configured by automatic installation procedures to get the necessary basic configuration for
system operation. This is the dynamic plug-and-play configuration of newly deployed eNBs. The
eNB will by itself configure the Physical Cell Identity (PCI), Cell global ID (CGID), transmission
frequency and power, leading to faster cell planning and rollout.
Examples include:
1) Automated Configuration of Physical Cell Identity
2) ANR or Automatic neighbour relations

5.1.1 Automated Configuration of Physical Cell Identity

Fig 6.

When centralised assignment is used the OAM system will have a complete knowledge and
control of the PCIs. When the distributed solution is used the OAM system assigns a list of
possible PCIs to the newly deployed eNB, but the adoption of the PCI is in control of the eNB.
The newly deployed eNB will request a report, sent either by User Equipment (UEs) over the air
interface or by other eNBs over the X2 interface, including already in-use PCIs. The eNB will
randomly select its PCI from the remaining values.

2) ANR or Automatic Neighbour relations

ANR or Automatic neighbour relations increases the number of successful handovers and
minimize the number of dropped calls by maintaining correct and up-to-date neighbouring
9
lists.It minimizes the work required for configuration in newly deployed eNBs and also
optimizes configuration during operation. Before a handover can be executed the source eNB
requires the neighboring information: PCI and CGID of the target eNB. The ANR by maintaining
updated neighbour lists expedites the handover process. Fig 7 shows the ANR fuction and its
interaction with the OAM.

Fig 7. Interaction between eNB and O&M due to ANR

The ANR function consists of three functions: the neighbour relation table (NRT) management
function, the neighbour removal function and the neighbour detection function. The neighbour
detection function takes measurement reports from the Radio Resource Control (RRC) finds
new neighbours. The neighbour removal function removes outdated Neighbour cell Relations
(NRs). The NRT has three three attributes:
a. No Remove: If checked, the eNB shall not remove the Neighbour cell Relation
from the NRT.
b. No HO: If checked, the Neighbour cell Relation shall not be used by the eNB for
handover reasons.

10
 c. No X2: If checked, the Neighbour Relation shall not use an X2 interface in order
to initiate procedures towards the eNB parenting the target cell.
The ANR function also allows O&M to manage the NRT. O&M can add and delete NRs. It can
also change the attributes of the NRT. The O&M system is also informed about changes in the
NRT.
5.2 Self Optimization

Self-optimization process is defined as the process where UE & eNB measurements and
performance measurements are used to auto-tune the network.
Some examples are:
1) Coverage and Capacity Optimization
2) Energy Savings
3) Interference Reduction
4) Mobility Robustness Optimisation
5) Mobility Load balancing optimisation
6) RACH Optimisation

5.2.1 Coverage and Capacity Optimization

A typical operational task is to optimize the network according to coverage and capacity. This
was done through measurements in the network and using theoretical propagation models in
the planning tools. This method requires extensive data collection and frequent drive tests
including statistics and measurements. Call drop rates give a first indication for areas with
insufficient coverage, traffic counters identify capacity problems. The algorithm will provide
optimal coverage and provide optimal capacity. For example, this use case can be used to solve
a) a inter RAT coverage hole b) to extend island coverage etc as shown in Fig 8 (a),(b).

Fig 8(a) Optimisation of IRAT coverage holes before and after

11
 Fig 8(b) Isolated Island Coverage Optimisation

5.2.2 Energy Savings

Expected outcome is to save on operational expenses through energy savings. In this use case
the technique used is to power down the cells within low traffic period for energy savings. For
example, for a cell providing additional capacity in a deployment i.e. capacity boosters that can
be distinguished from cells providing basic coverage can be switched off when its capacity is no
longer needed and to be re-activated when needed. Time window will be calculated and
adjusted according to traffic data provided by the network. Fig 9 below shows an example of
the use case.

Fig 9. Energy savings use case

3) Interference Reduction
The goal of SON based Inter Cell Interference Coordination (ICIC) is to have minimized human
intervention in network management and optimization tasks. ICIC requires that neighboring
cells exchange information about which portion of the total bandwidth they are using.
Neighbouring cells can coordinate which portions of the bandwidth are used in each cell and
the transmission powers across various frequency resource blocks. Inter-cell interference can
be reduced or avoided in uplink and downlink by a coordinated usage of the available resources
(PRBs) in the related cells which leads to improved SIR and corresponding throughput. This
12
coordination is realized by restriction and preference for the resource usage in the different
cells. This can be achieved by means of ICIC related RRM mechanisms.
Capacity could be improved through interference reduction by switching off those cells which
are not needed for traffic at some point of time, in particular home eNodeBs when the user is
not at home. In this use case it is expected that increased capacity and quality will result
through interference reduction.

4) Mobility Robustness Optimisation (MRO)

This function adjusts the parameters when a handover (HO) failure occurs and tries to minimize
the risk of loss of radio connection due to mobility. It aim is also to reduce the number of
Handovers triggered back and forth i.e. Ping-Pong HO and call drops or radio link failure. Fig 10.
below shows the occurrence of Ping-Pong HO when Hysteresis is set to low value.

Fig 10. Ping Pong HO behaviour when Hysteresis is set to LOW

Within this use case three scenarios are identified:

1) Detect and minimize occurrences of Too Late HOs

Fig 11(a). Too Late HOs

13
 2) Detect and minimize occurrences of Too Early HOs

Fig 11(b). Too Early HOs

3) Detect and minimize occurrences of HO to a Wrong Cell

Fig 11(c). HO to a Wrong Cell

Fig 11(a) shows too late HO where the radio link failure (RLC) occurs between source eNB and
the UE before HO is completed. In Fig 11(b) shows too early HO where RLC occurs as soon as UE
is connected to target eNB because the radio link to the source eNB is stronger. In the last case,
Fig 11(c) shows the case where the UE is handed over from Cell 1 to Cell2 and soon to Cell 3.
This happens because HO from Cell 1 to Cell 2 is too early while the HO from Cell 2 to Cell 3 is
too late. In LTE Release 9, the eNB can ask the UE to report the identity of the cell to which it
was connected and also the radio measurements.

The MRO uses this feature to set the value of the HO threshold, the timer and the hysteresis
value in an optimal manner, so that network resources are not wasted on extra HOs or in HOs
that fail.

5) Mobility Load balancing (MLB) Optimisation

MLB is a function where cells suffering congestion can transfer their load to neighbouring cells
having spare resources. Cell reselection/handover parameters are optimised so that load is
uniformly distributed with minimum number of handovers and redirections needed to achieve
the load balancing. An eNB monitors the load in the controlled cell and exchanges related
14
information over X2 or S1 with neighbouring node(s). The algorithm identifies the need to
distribute the load of the cell towards either adjacent or co-located cells, including cells from
other RATs, e.g. by comparing the load among the cells, the type of ongoing services, the cell
configuration, etc. If the need arises, the algorithm changes the HO parameters appropriately.
To implement the function load reporting between eNBs through S1/X2 is required.

Fig 12 Functional architecture of SON Load Balancing

The functional architecture in Fig 12 shows:

A) Load reporting function
B) HO (cause load balancing)
C) Adapting HO parameters
The aim of SON Load Balancing is to balance the cell load to increase the capacity of the system.

6) RACH Optimisation

This function optimises the RACH parameters based on the load, like:
a. RACH backoff parameter,
b. PRACH Transmission Power Control Parameters,
c. Uplink radio resources reserved for RACH etc.
The load depends upon number of factors like: call arrival rate, the HO rate, traffic pattern and
population cell coverage, the uplink inter-cell interference from the Physical Uplink Shared
Channel (PUSCH), PUSCH load.
RACH optimisation is important because when the RACH is highly loaded, the collision
probability on RACH increases. This causes more retransmissions before a successful random
access and results in larger access delay. Secondly, since the uplink radio resources are reserved
for RACH, configurations resulting in underutilized RACH resources should be avoided. To
implement RACH optimisation, SON uses the procedure to report from UE to eNB, the number
15
of RACH transmission attempts required for most successful random access procedure. This
helps the SON algorithm to set the RACH parameters accordingly for future RACH
transmissions.
The purpose of SON RACH optimisation is to:
1) bring positive System Capacity impact
2) reduction in access delay for all UEs in the system
3) Minimize UL interference due to RACH
4) Minimize interference among RACH attempts

5.3 Self Healing

The purpose of the Self-healing functionality of SON is to solve or mitigate the faults which
could be solved automatically by triggering appropriate recovery actions. In fault management
system, for each detected fault, appropriate alarms are generated by the faulty network entity,
regardless of whether it is an Automatically detected and automatically corrected fault (ADAC)
or an Automatically Detected and Automatically Corrected (ADMC) fault. These alarms can act
as a trigger for the Self-healing function. For example, Cell outage detection / Cell Outage
Recovery.

Fig 13 Cell outage detection / Cell Outage Recovery

The above figure shows cell outage detection/ Cell Outage Recovery process, where there is a
loss of total radio services in the outage cell, all the UEs cannot establish or maintain all the
Radio Bearers (RBs) via that particular cell. Then, through SON, the nearby cells adjust their
pilot power and the antenna atilt so as to cover maximum possible portion of the cell outage
region. In the process, it is ensured that the existing users of the nearby cells do not suffer a
large decrease in their quality of service.

16
In case of Software Faults, Self Healing consists of
system initializations (at different levels),
reload of a backup of software,
activation of a fallback software load,
Reconfiguration, etc.
In case of Hardware Faults, Self Healing consists of
Isolation and removal of the faulty resource from service so that it does not disturb
other working resources;
Removal of the physical and functional resources (if any) from the service, which are
dependent on the faulty one. This prevents the propagation of the fault effects to other
fault-free resources;
Reset the faulty resource etc.

6. Challenges in SON Implementation

Though the implementation of SON is expected to bring lot of benefits to the network, many
challenges are faced when SON is implemented in the network.
a) Managing SON features in Multi-layer, Multi-access Heterogeneous networks.
b) Ensuring SON robustness and scalability in a Multi-technology environment.
As the number of SON functions increases with each new vendor release, one of the main
issues for operators is to determine which functions to introduce and also determine the
appropriate timing for activating these functions to obtain a well-behaving and cost-efficient
network. Several of the different SON functions may have the same target optimization
parameters, that is, the output of two or more algorithms may try to act/optimize the same
parameters. This may cause problems if some SON functions tend to tune parameters in
different direction and this may lead to instabilities. As the SON suite grows it might be
necessary to implement a framework for coordination of SON functions to ensure that the
individual SON functions jointly work towards the same goal, formulated by the operators
high-level objectives.

7. Conclusion

SON functionality enables affordable data centric services owing to its support of leaner service
and network management, and of optimized coverage, capacity and high-quality rollouts
through heterogeneous network deployments. Though the paper also highlights the challenges
in implementing SON features in a multi technology, multi vendor networks heterogeneous
networks SON helps in the optimisation of the network and contributes to the enhancement of
end-user experience. Three guiding principles should be used to ensure that SON functionality
is deployed in a way that optimally supports business objectives:
SON functionality needs to span all radio access technologies 2G, 3G and 4G including the
core and transport network domains.

17
 No single ideal location exists for SON functionality all involved nodes must adhere to SON
principles, and new solutions should not simply be added to existing ones.
As SON functions span several nodes and technologies, it should be ensured that they are not
duplicated or work in a conflicting manner.

18
References

1) Use Cases, Requirements and Assessment Criteria for Future Self-Organising Radio Access
Networks, Socrates Consortium, 2008.
2) 3GPP TS 32.500 version 11.1.0 Release 11
3) 3GPP TS 32.511 version 11.2.0 Release 11
4) 3GPP TR 36.902 version 9.3.1 Release 9
5) 3GPP TS 36.300 version 11.3.0 Release 11
6) 3GPP TS 32.541 version 11.0.0 Release 11
7) Self Optimising Networks: The Benefits of SON in LTE, 4G Americas, July 2011
8) Further Enhancements of LTE- LTE Release 9, Mikio Iwamura, Anil Umesh, Wuri A.Hapsari, NTT
DoCoMo Technical Journal, Vol. 12, No.1.
9) Smarter Self Organising Networks, Ericsson White paper, Feb 2012.
10) Self-Organizing Networks (SON) in 3GPP Long Term Evolution, Sujuan Feng, Eiko Seidel, Nomor
Research GmbH, Munich, Germany, May 2008.

19