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”.
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.
