Self-Organizing Networks (SON) is a collection of functions for automatic configuration, optimization, diagnostication and healing of cellular networks. It is considered to be necessity for latest mobile networks like 4G and 5G and operations due to the increased cost pressure and configuration complexity. The main drivers are essentially to reduce CAPEX and OPEX, which would otherwise increase dramatically due to increased number of network parameters that has to be monitored and set, the rapidly increasing numbers of base stations in the network and parallel operation of 2G, 3G, 4G and Evolved Packet Core (EPC) infrastructures. This post presents evaluations on the use of some of the most important SON components. Mobile networks are getting more complex to configure, optimize and maintain. Many SON functions will give cost savings and performance benefits from the very beginning of a network deployment and these should be prioritized now. But even if many functions are already available and can give large benefits, the field is still in its infancy and more advanced functions are either not yet implemented or have immature implementations. It is therefore necessary to have a strategy for how and when different SON functions should be introduced in mobile networks.
SON Architecture
There are three main alternatives regarding the architecture of SON functions in cellular networks as illustrated below. These are denoted centralized, distributed, and hybrid architectures. Different SON functions can be implemented by different architectures in the same network. In this chapter, we briefly describe the three different architecture options and discuss pros and cons of the different types.
Centralized SON Architecture
In a centralized SON architecture, the algorithms are executed at the network management level. Commands, requests and parameter settings data flow from the network management level to the network elements, while measurement data and reports flow in the opposite direction. The main benefit of this approach is that the SON algorithms can take information from all parts of the network into consideration , even an updated sites information like location (longitude and latitude) , design (azimut , tilt and Beamwidth ...), otherwise it will influense SON module' results. This means that it is possible to jointly optimize parameters of all centralized SON functions such that the network becomes more globally optimized, at least for slowly varying network characteristics. Also, centralized solutions can be more robust against network instabilities caused by the simultaneous operation of SON functions having conflicting goals. Since the control of all SON functions is done centrally, they can easily be coordinated.
Another advantage is that multivendor and third party SON solutions are possible, since functionality can be added at the network management level and not in the network elements where vendor specific solutions are usually required.
P.I.Works provides the industry-leading of multi-vendor and multi-technology network optimization SON centralized solution.
The main drawbacks of the centralized SON architecture are longer response times, depends on CM and PM granularity and disponibility, increased backbone traffic, and that it represents a single point of failure. The longer response time limits how fast the network can adapt to changes and can even cause network instabilities. The backbone traffic increase since measurement data have to be sent from the network elements to the network management system and instructions must be sent in the opposite direction. This traffic will increase as more as cells are added to the network. If there are many pico- and femto-cells this traffic will be very significant. Also, the centralized processing power needed will be large.
Distributed SON Architecture
In a distributed SON architecture, the SON algorithms are run in the network nodes and the nodes exchange SON related messages directly with each other. This architecture can make the SON functions much more dynamic than centralized SON solutions, so that the network can adapt to changes much more quickly. It is also a solution that scales very well as the number of cells in the network increases.
4G eNodeB provides some distributed SON functions like Automatic Neighbor relations.
The main drawbacks are that the sum of all the optimizations done at cell level do not necessarily result in optimum operation for the network as a whole and that it is more difficult to ensure that network instabilities do not occur.
Another drawback is that the implementation of the SON algorithm in the network elements will be vendor specific, so third party solutions will be difficult.
Even if the algorithms themselves are executed in the network elements, the network management system is usually able to control the behaviour of the SON function, for example, by setting the optimization criteria, receiving periodic reports, and being able to turn it off if necessary.
Hybrid SON Architecture
Hybrid SON solution means that part of the SON algorithm is run on the network management level and part is run in the network elements. The solution represents an attempt to combine the advantages of centralized and distributed SON solutions: centralized coordination of SON functions and the ability to respond quickly to changes at the network element level.
Unfortunately, the drawbacks of both centralized and distributed SON are also inherited. The SON related traffic in the backbone will be proportional to the number of network elements in the network, which means that it might not scale well. The same holds for the SON related processing required at the network management level. Also, since parts of the SON algorithms are running in the network elements and the interface between the centralized and distributed SON functions will be proprietary, third party solutions will be difficult.
It should be noted that the term “Hybrid SON” is not clearly defined and is used differently by different vendors. Some vendors classify their solutions as “hybrid” if the network management system can control the SON function by setting main parameters/policies, receiving reports and being able to turn it off if necessary. If such SON functions otherwise are autonomous, they are classified as “distributed”.
SON Functions
The SON functions are usually categorized into three main groups: self-configuration, self-optimization, and self-healing. It should be noted that a given SON function can belong to more than one of these categories.
Self-Configuration SON
The Self-configuration SON is a collection of algorithms that aims at reducing the amount of human intervention in the overall installation process by providing “plug and play” functionality in network elements such as the E-UTRAN NodeBs (eNBs). This will result in faster network deployment and reduced costs for the operator in addition to a more integral inventory management system that is less prone to human errors.
Self-configuration is a broad concept which involves several distinct functions that are covered through specific SON features, such as automatic software management, self test, physical cell ID configuration (PCI), and automatic neighbor relations (ANR). The latter function is not only used during installation but is also an important part during normal operations.
The self-configuration should take care of all soft-configuration aspects of an eNB once it is commissioned and powered up for the first time. It should detect the transport link and establish a connection with the core network elements, download and upgrade to the latest software version, set up the initial configuration parameters including neighbour relations, perform a self-test, and finally set itself to operational mode. In order to achieve these goals, the eNB should be able to communicate with several different entities.
The self-configuration actions will take place after the eNB is physically installed, plugged to the power line and to the transport link. When it is powered on, the eNB will boot and perform a self test, followed by a set of self-discovery functions, which include the detection of the transport type, tower-mounted amplifier (TMA), antenna, antenna cable length and auto-adjustment of the receiver-path.
After the self-detection function, the eNB will configure the physical transport link autonomously and establish a connection with the DHCP/DNS (dynamic host configuration protocol/domain name server) servers, which will then provide the IP addresses for the new node and those of the relevant network nodes, including serving gateway, mobility management entity (MME), and configuration server. After this, the eNB will be able to establish secure tunnels for operations sdministration and maintenance (OAM), S1, and X2 links and will be ready to communicate with the configuration server in order to acquire new configuration parameters.
One of the OAM tunnels created will communicate the eNB with a dedicated management entity, which contains the software package that is required to be installed. The eNB will then download and install the corresponding version of the eNB software, together with the eNB configuration file. Such configuration file contains the preconfigured radio parameters that were previously planned. A finer parameter optimization will take place after the eNB is in operational state (self-optimization functions).
The self-configuration SON functions were among the first standardized by 3GPP (release 8) and have been more or less stable since then. From the roadmaps of different vendors it can be concluded that self-configuration SON is available and mature. These SON features will be extremely useful in the rollout phase to reduce the installation time compared with ordinary installation procedures, and also later when new eNBs are added to increase the network capacity. The actual decrease in OPEX is not easy to give since the corresponding installation without any (self) automatic features is difficult to foresee.
Self-Optimization SON
SON self-optimization functions are aiming at maintaining network quality and performance with a minimum of manual intervention from the operator. Self-optimization functions monitors and analyzes performance data and automatically triggers optimization action on affected network element(s) when necessary. This significantly reduces manual interventions and replaces them with automatic adjustments keeping the network optimized at all times. Self-optimizing SON functions make it possible to introduce new automatic processes that are too fast, and/or too complex to be implemented manually. This will improve the network performance by making the network more dynamic and adaptable to varying traffic conditions and improve the user experience.
Some of the most important self-optimization SON use cases are:
- 4G PCI/RSI and 3G PSC planning;
- 3G/3G/4G Automatic neighbour relations (ANR);
- 4G Inter-cell Interference coordination (ICIC);
- 4G Mobility robustness optimization (MRO);
- 3G/4G Mobility load balancing optimization (MLB);
- 2G/3G/4G Cell Coverage optimization (CCO);
- Energy Saving.
The two first use cases, PCI and ANR, may as well be categorized as self-configuration algorithms since they will be part of initial configuration procedures, but will also play an important part in normal operation and therefore may be viewed as being self-optimization procedures.
Self-Healing SON
Self-healing functionality was not initially defined a part of the 3GPP SON functionality, but it was taken into the SON standards in release 9 and 10, by 3GPP TS 32.541 “Self-healing concepts and requirements.
Self-healing is a collection of SON procedures which detects problems and solves or mitigates these to avoid user impact and to significantly reduce maintenance costs. Self-healing is triggered by alarms generated by the faulty network elements. If it finds alarms that it might be able to correct or minimize the effects of, it gathers more necessary correlated information (e.g., measurements, testing results, and so forth), does deep analysis, and then trigger the appropriate actions.
The two major areas where the self-healing concept could be applied are as follows.
- Self-diagnosis: create a model to diagnose, learning from past experiences.
- Self-healing: automatically start the corrective actions to solve the problem.
Making use and analyzing data from the current optimization tools (alarm supervision system, OAM system, network consistency checks), optimizers can decide if network degradation occurs, which is the most likely cause, and then perform the needed corrections to solve the problem. The experience of optimizers in solving such problems in the past, and the access to a database of historic solved problems is very useful to improve the efficiency in finding solutions.
This whole optimization process could be enhanced in two steps as follows.
- Diagnosis model creation based on the experience of already solved problems, using a database with faults and their symptoms. Automatic troubleshooting action can be done without human intervention.
- Self-test results from the periodic execution of consistency checks would help during the self diagnosis phase, to address better the healing process.
In the recommendation three different Self-healing SON functions are defined:
- Cell outage detection and compensation,
- Self-recovery of network element (NE) software,
- Self-healing of board faults.
For the time being only cell outage is available in vendor’s roadmaps and the two latter will therefore not be described in this post.
Coordination of SON Functions
Up to now, the work on SON has focused mostly on the development of stand-alone functionalities. However, 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.
Such conflicts can occur if, for example, two different individual SON functions (e.g., cell outage management and interference coordination) aim at different goals when optimising the same parameter, or if the modification of a control parameter by one SON function influences the operation of other SON functions. Such conflicts may cause the whole system to operate far from optimal behaviour, with a negative impact on the operator’s overall objectives on performance and user satisfaction. Thus, the avoidance and/or resolution of conflicts and dependencies between the functions will be beneficial.
A good example of SON functions which need to be coordinated is MRO and MLB which both act and try to optimize the HO parameters and therefore needs to be coordinated.
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 operator’s high-level objectives. This can be achieved by effectively and appropriately harmonising policies and control actions of the SON functions. A SON coordinator should furthermore ensure that the individual SON functions work with a common set of performance targets and measurements, and enable the operator to control the overall SON system through a single interface and thereby minimise the operational effort.
Initially it will be, at least, desirable to have coordination between some SON function like MRO/MLB and ANR/Phy cell ID. Later, as the SON suite grows in number, it will be necessary to introduce some form of SON coordination framework to secure optimal use of the SON suite.
SON Evolution
The inputs of SON has until now be limited to PM, CM and some design information for the development of functionalities. However, customers traces, Geo-location and CRM complaints may be a great inputs for some SON functions. This may enhance results if functions tend to tune parameters based on real user cahnnel quality, satisfaction and target quality of service.
