Introduction

The Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet
Core (EPC) system management evolve from UMTS. The evolvement places new demands
on Operation and Maintenance (O&M) of the network. Therefore, in addition to evolving
existing management solutions, E-UTRAN/EPC also encompasses some new Self-Organized
Network (SON) functionalities such as Auto-Configuration and Auto-Optimization.

As a consequence of flattening the access network architecture, network operators will

require more LTE evolved NodeBs (eNBs) than existing UMTS NodeBs in order to cover an
equivalent geographical area. Network operators also articulated their requirements to have
more flexibility over the choice of eNodeB vendors, irrespective of the Mobility Management
Entity (MME) or Network Management System (NMS) vendors.

The 3GPP Evolved Packet System (EPS) architecture has standard interfaces such as X2
interface and the S1 interface as shown in Figure 1.

Due to these standard interfaces, the automation of network planning, configuration and
optimization is easy through automatically executed functions. The E-UTRAN/EPC networks
will increase the number of Network Elements (NEs) to be managed to reduce network
complexity and operating costs; SON will reduce the Operating Expenditure (OPEX) to
manage the heterogeneous NEs.

Design Architecture
Design considerations of O&M have changed dramatically in recent years due to changes in
the networks being managed and increase in the number and complexity of services being
supported. The emphasis has changed from infrastructure management to services
management.

There are three types of architectural considerations that can be deployed in the
implementation of SON architecture as shown in Figure 2. 

Centralized SON: The SON algorithms are executed at the OAM level of the existing
network management systems or additional standalone servers; SON functionality and
algorithms reside at the NM level in the architecture.

Distributed SON: The SON algorithms are executed at the NE level; SON functionalities
reside at the network level in the architecture.

Hybrid SON: The SON algorithms are executed partly at the OAM level of management
systems and partly at the NE level.

SON Functionalities
The purpose of SON is to incorporate intelligence in the network management by
successfully transforming the possible management operations into automatic executable
software procedures. Figure 3 depicts the SON  process flow briefly.

(1) The first step is the planning process of a new site based on coverage and capacity
requirements including the first initial set of parameters such as location, eNodeB type,
antenna type, cell characteristics (sectors), and required capacity.

(2) After physical installation of the eNodeB, the first initial self test starts with a possible
report R1 in case of failure to the NE manager.

(3) In the next step of self-configuration:

 The eNodeB requests its basic setup information including configuration of IP-
address and detection of OAM, authentication of eNodeB, association of a GW and
downloading of eNodeB software.
 Then as a second part of the self-configuration, the initial radio configuration I2 is
done: data might be provided through the NE manager from the planning tool or
another self-configuration related instance.
(NOTE: The other related parameter should be derivable from a default value by auto-
optimization and sent to the NE manager and planning tool, which can inform the
neighbor eNodeBs about the existence of the new eNodeB which can be included as
the new cell in the corresponding neighborhood list.)

(4) An additional self test, for example, parameter with possible report R2 to the NE manager
could be done.
(5) At the end of the installation, the eNodeB is ready for commercial use and a test call can
be done successfully.
 
Self-Configuration
Self-configuration is the process that must be executed automatically after the physical
installation of the eNodeB. Figure 4 illustrates the step-by-step process of self-configuration.

The brief explanation of these steps is given below:

 IP address is allocated to the new eNodeB.

 The eNodeB connects to the OAM system for authentication, software download and
configuration data download. The initial radio configuration and transport parameters
configuration are done. The software is downloaded into the eNodeB.
 The eNodeB connects to the OAM system for configuration data or normal network
management.
 The S1-links and X2-links are established and dependent nodes such as MMEs and
eNodeBs are updated with new configuration data.
 The inventory system in the OAM is informed that a new eNodeB is ready to perform
the next required operation.

Self-Optimization
Based on the actual location of equipment, the optimization of initial neighbor list is required
(e.g. radio measurements of eNodeBs are required to solve the call drops or handover
problems). For this approach, RRC connections and their accompanying measurements can
be used to gather the needed information about neighbors. Known neighbors can be checked
if they are really appropriate concerning real RF conditions; new ones can be included based
on information about detected cells in UEs. Neighbor related parameters include:

 Location of the neighbors (distance)

 UE measurement reporting or eNodeB radio scanning for neighbors
 Field strength information
 Event measurements like cell specific call drops or handover failures
 NMS/EMS configuration data
 Planning tool data
Self-Healing
Self-healing is a function that mitigates the faults automatically by triggering appropriate
recovery actions. From the point of view of fault management, for each detected fault,
appropriate alarms shall be generated by the faulty network entity, regardless of whether it is
an automatically detected and automatically cleared or an automatically detected and
manually cleared fault.

The self-healing functionality monitors the alarms, and gathers necessary correlated
information (e.g. measurements, testing result, etc.) and does deep analysis, and triggers
appropriate recovery actions to solve the fault. It also monitors the execution of the recovery
actions and decides the next step accordingly. When self-healing iteration ends, the self-
healing functionality shall generate appropriate notifications to inform the IRPManager of all
the changes performed.