LTE SON: How Does It Work?

2009-05-18

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.