By Dr. Nishith Tripathi

A Self-Organizing Network (SON) in LTE (Long Term Evolution) is a network that automates various tasks related to network planning, configuration, and optimization.  Such automation reduces the amount of "manual" work, thereby reducing the operating expenditure (OpEx) for a service operator.  The specific algorithms that implement the SON functionality are not standardized and are product differentiators for SON vendors.  We will briefly summarize below the SON architecture and SON use cases.

The SON architecture may be centralized, distributed, or hybrid.  In the centralized architecture, the SON functionality is implemented in the OAM (Operations, Administration, and Maintenance) system, and, the OAM system communicates with other entities such as eNodeBs to collect measurements and provide parameter settings.  In a distributed architecture, the SON functionality is implemented at many network elements (NEs) such as eNodeBs.  The hybrid architecture, as the name suggests, is a compromise between the centralized and distributed architectures, where part of the SON functionality is in the OAM system, and, part of the functionality is in the NEs. 

Let's discuss different ways in which the SON can be used.  The SON, in its most comprehensive form, can perform three types of functions- self-configuration, self-optimization, and self-healing.  Self-configuration means that the eNodeB obtains many of its configuration parameters automatically from the SON upon "power-up."  Self-optimization refers to the process in which the SON digests information related to network performance and modifies the parameters (e.g., handover and random access parameters) to enhance the network performance.  Self-healing refers to the mechanism by which certain failures (e.g., software issues) are detected automatically and corrective actions are taken (e.g., fallback to a previous software version).  Initial focus of the LTE standard is on self-configuration and self-optimization, and we will focus on these two as well here.  The UE is required to support these functions by providing relevant feedback to the network.

Self-configuration applies to "pre-operational" state, where the eNodeB has been powered up and has the backbone connectivity but its RF transmitter has not been turned on yet.  Basic setup and radio configuration are considered part of self-configuration.  During the basic setup, the eNodeB acquires an IP address and detects an OAM system.  Initial radio configuration involves downloading of some parameter settings (e.g., an initial neighbor list).  The use cases for self-configuration specified by the standard are mentioned below.

  • Dynamic configuration of the S1-MME interface. This function helps the eNodeB establish an SCTP association with one or more MMEs.
  • Dynamic configuration of the X2 interface. This function helps the eNodeB establish an SCTP association with one or more candidate (i.e., neighboring) eNodeBs.
  • Automatic Neighbor Relation (ANR) function. This function helps create a neighbor list. Support for X2 interface between the neighbors and support for handover to a neighboring cell are also specified. All of intra-frequency, inter-frequency, and interRAT (Radio Access Technology) neighbors are considered.
  • Framework for PCI (Physical layer Cell ID) selection. The PCI could be directly specified by the OAM system, or, the eNodeB could choose a PCI from the PCI list provided by the OAM system by considering additional factors such as PCIs of neighboring eNodeBs.
  • TNL (Transport Network Layer) address discovery. The eNB exploits the Configuration Transfer Function on the S1-MME interface to determine the TNL address (i.e., the IP address) of the neighboring eNodeB.

Self-optimization is executed in the operational state of the eNodeB.  The UE measurements are processed by the SON to optimize parameter settings (e.g., an updated neighbor list).  The self-optimization related use cases specified by the standard are as follows.

  • Automatic Neighbor Relation (ANR) function. This function, when part of self-optimization, allows the cells to be added to and removed from a neighbor list. Reports from UEs are processed to tune the neighbor list.
  • Support for mobility load balancing. This function aims to distribute the loading among neighboring cells and to reduce traffic congestion through handover.
  • Support for mobility robustness optimization. This function helps detect radio link connection failures due to too early handover, too late handovers, or handover to a wrong cell.
  • Support for RACH optimization. The SON processes the UE reports on the use of RACH (e.g., number of preambles sent) to optimize RACH parameters such as power ramping step size.

In the era of fierce competition and frugality, the SON is attractive due to its potential for OpEx reduction.  However, caution must be exercised while embracing the SON for automatic and un-supervised determination of critical parameters.  The SON functionality, while conceptually quite attractive, heavily depends on the design of the SON algorithms.  Until confidence on the SON algorithms is built up, off-line evaluation of the SON-suggested parameter changes can yield a wealth of useful information to configure and optimize the network.  Such evaluation could still provide some OpEx savings while providing a structured method for parameter configuration and optimization.