Understanding Self-Organizing Networks: the SON essentials

In this article we explain the idea behind self-organizing networks (SONs), what they are, where they are applicable and how organizations can benefit from them.

We will explain some of the technical aspects of SONs, their example applications and use cases, as well as the necessary steps that need to be taken to make a potential investment in SON as beneficial as possible. We wrap up with a few words about the current trends in vendor offerings.

Why self-organizing networks?

Let’s begin by answering the what and the why. Can any type of network self-organize? What does it even mean? And why do we even bother?

The term self-organizing networks (SON) applies to radio access network (RAN) technologies of all generations (2G, 3G, 4G, 5G, and beyond), popularly considered as the mobile network. It wasn’t there from the beginning as its early standardization appeared only in 3GPP Release 8, in which LTE was first introduced, but eventually the previous generations may also benefit from it.

Why do wireless networks benefit so much from self-organization? Because the medium used - radio waves - and their flexibility and availability, are both a curse and a blessing. It may seem simple, that whenever we need to improve the signal reception in some area, we invest in another “antenna” and there you go. In reality however, radio waves propagate and are subject to physical phenomena, causing interference of all sorts, so the effect may be just the opposite.

So before SONs, carrier radio networks needed to be manually designed, planned, configured, measured, optimized, and fixed. The radio spectrum is a precious resource, licenced and expensive. Because it is so limited (the bands for each mobile technology are strictly defined and cannot be extended) it needs to be shared and cannot be physically separated like the wired world. And so the costs of deploying and running such infrastructure were high because it required skilled teams of technicians to do all the heavy lifting. SONs may address these challenges - we will show how later in the article.

Surprisingly enough, even though the concept of SON had been standardized by 3GPP for more than a decade now, the actual adoption among CSPs (communication service providers) was less than 20%       in 2022. There are several reasons for this, but even if early implementations seemed premature for their times, this market is now expected to eventually grow exponentially, as the demand for fast, reliable and accessible mobile data services keeps accelerating, and CSPs are desperate to deliver them with reasonable costs. On top of that, modern SONs are being equipped with the unprecedented powers of AI and ML, which makes their capabilities even more exciting and promising.

How do self-organizing networks work?

First of all let’s split all this “organizing” into groups of functionalities:

When deployed, the radio node (a base station aka cell tower) must be configured. By no means can it come “preconfigured” or remain at some default configuration, because as already mentioned, it needs to have its radio parameters adjusted to the specific environment it is supposed to interwork with, to be able to effectively serve the users who happen to find themselves in that cell (area served by a sector of a base station). 

Self-configuration means that upon deployment the new node measures the parameters of existing cells - not only the new node being tuned but also the local ecosystem of neighboring nodes, so that interference is avoided, the frequency plan/license is met and optimally used, while the coverage and/or capacity are indeed improved. The benefits are:

• “plug and play”,
• super fast rollout procedure,
• effective spectrum license utilization,
• configuration and inventory consistency.

Then to maximize the value added by this new radio node, self-optimization comes into action. Note that unlike the configuration stage, it is a continuous process reacting to the dynamic changes in the environment. Because we must remember that we are dealing here with mobile users, who both by definition and in practice are often on the move, impacting the used medium all the time, even when not actively using any services. What is also distinct, is the fact that a SON will use not only the data measured by the infrastructure itself but also it will make use of the UE (user equipment) measurements to optimize itself. We will dive deeper into specific techniques later in this article. This group of techniques gives us:

• dynamic optimization of spectrum usage,
• optimization of control plane resources,
• congestion avoidance,
• optimal resource utilization with maximum user experience.

Last, but not least, a SON may employ self-healing mechanisms, which will mitigate a bad user experience resulting from a radio node failure or service degradation. Other nodes take over the traffic from the cell served by the faulty node while the failure is being dealt with, and then recover the original topology once service resumes. The benefits from employing self-healing functionality are:

• quicker mitigation and/or resolution of a node failure,
• avoiding the cost of human intervention,
• better customer experience,
• fewer customer complaints and less churn.

The requirements and challenges of SONs

With all the good that SONs may offer, it is important to understand that the implementation of multiple mechanisms at the same time, in a heterogeneous, multi-technology and oftentimes multi-vendor radio access network is not a trivial task.

To understand these challenges let us first take a look at the principles and requirements for SON algorithms to coexist. Primarily, SONs employ closed loop cycles consisting of:

• snapshot  - cells’ KPIs are compared against expected values.
• action - may be triggered if KPIs are not met - SON tunes the parameters to bring (back) the optimal state.
• feedback - measurements (counters) are collected and fed back to the SON controller(s) (the module that runs the SON applications performing the optimizations).

There are several requirements governing this cycle.

Stability means that different algorithms’ goals must be coordinated, to avoid a situation of back and forth with each of them pulling in a different direction. Clear rules and scenarios for conflict resolution are essential to achieve this.

Robustness means that anomalies and corrupted measurements shouldn’t be able to destabilize the network.

Timing is an important factor that may be very different for various use cases. It defines the time window in which an algorithm collects data and produces a decision for self-organizing actions. For example, it will be very short (minutes at most) in self-healing use cases, while it may take days or weeks for capacity-related optimizations.

Performance, complexity, investment costs depend on finding the right balance between the costs and benefits of SON, as the more sophisticated algorithms we employ, the more overhead they may consume in terms of computational effort, radio and backhaul interface signaling (control plane), data processing and storage, etc.

Data collection is essential. No SON algorithm is able to perform its job without sufficient and accurate data, both in the feedback loop as well as at the baseline. Depending on the use case, the types of data include: network topology, usage patterns, node and UE measurements, QoS requirements, etc.

On the business side of things, any organization considering employing SON in their network will look at the cost reduction opportunities that SONs promise:

• OPEX reduction by automating operations and expediting rollouts, both with less effort and higher reliability.
• CAPEX reduction by relying on the promise that SON will maximize the value of the investment (maximally efficient resource utilization), so that e.g. fewer radio nodes will be needed to achieve the same coverage and capacity.

Of course, SON implementation will incur its own costs (licensing, infrastructure, training, etc.), so the challenge here is to build a feasible business case.

SON architectures and applications

Depending on the location of the “brain” that is driving a SON, we may differentiate between three SON architecture types:

1. A centralized SON (C-SON), where a central SON OAM (operations and maintenance) module, located near the network core, is the decision maker about all of the self-organization of the network. The centralized nature may rule out the very local and the most dynamic optimization techniques, especially in some environments. On the other hand it is easy to deploy and maintain and it is easier to maintain consistency across the network.
2. A distributed SON (D-SON) is the opposite approach, where the optimizing algorithms are executed in every node and the nodes talk to each other and negotiate optimal parameters. This allows us to achieve a very high level of self-optimization at a very low level of the network. A huge advantage is also the speed at which the nodes react to the changes in the environment. On the other hand the coordination of so many decision-making centers may become a challenge for the network to remain consistently optimized as a whole. It goes without saying that such an approach may be quite costly, both CAPEX and OPEX-wise.
3. A hybrid SON (H-SON) is a relatively new architecture trying to make the best of both the above-mentioned worlds by processing the local optimizations locally at the nodes and the global ones at the central OAM. This provides the highest number of optimization applications, but is also the most complex and costly approach.

The choice of the architecture for a given organization is a part of a more complex process which is briefly described later in this article.

Source: SON presentation      

Selected SON-Applications

To better understand SONs, let us now showcase some of the common applications:

1. Automatic Neighbor Relations (ANR) - this self-configuration technique addresses one of the key functionalities of RANs - mobility. To enable a seamless mobile user experience, radio nodes use handovers to keep serving the terminals moving around, i.e. when a user is about to leave a cell, a handover procedure is triggered to enable a neighboring cell to take over the service. For handovers to work, radio nodes must be aware of their neighboring nodes by having lists of neighbor relations. Before SONs, these lists needed to be carefully planned and modified upon any change in the topology - any errors led to the network misbehaving (dropped calls, congested cells, poor signal reception, etc.) Thanks to ANR, SON nodes are able to detect their neighbors and update their lists but also to remove outdated or otherwise specific relations when such an operation is triggered by the OAM. The removal can be temporary or even partial, i.e. only certain types of handovers may be permitted or denied (enabling greater flexibility).

2. Mobility Robustness Optimization (MRO) - this self-optimization function tunes the parameters responsible for the handover decision making process between given cells. The goal here is to do only the necessary handovers, but also not to miss any. On the border zone between cells a decision must be taken before the node A coverage vanishes completely (and the connection will drop), but also not too soon because that may lead to handover ping-pongs or handing over to an intermediate cell, unnecessarily. Three parameters are being tuned by MRO: the handover threshold and hysteresis values for the signal strength, and the timer (delay).  The ultimate goal is effective radio resource utilization.

   Fig.1: MRO scenarios: 1. A handover decision taken too late will lead to signal loss and connection drop when the terminal leaves cell A; 2. A handover decision taken too soon will cause unnecessary handovers back and forth between cells A and C, when the terminal moves around a cell border; 3. A handover decision taken too soon will lead to unnecessary handover from A to B and then brom B to C, instead of directly handing over from A to C when it becomes possible.
   

3. Mobility Load Balancing (MLB) - is a self-optimization function which in fact uses handovers as a tool to optimize resource utilization and avoid congestion in a given area. It does so by transferring the load to other cells (adjacent or co-located, including other RATs (radio access technologies, e.g. LTE->UMTS or LTE->GSM)). To achieve this, MLB mechanisms monitor and compare the load measurements and tune the handover parameters to give a less loaded cell a higher chance of taking over some of the traffic.

4. Coverage, capacity, and performance improvements - traditionally a very cumbersome task, which required careful planning and modeling, periodic drive testing, analysis of complex data and multiple quality indicators; finally a time-consuming and expensive implementation process. SONs deal with this by automatic collection of measurements from real devices being on the network and sophisticated algorithms auto-tune the radio parameters to continuously optimize its operation.

5. Cell outage detection and compensation (COD & COC) - these are the major features belonging to the self-healing group, which together ensure quick elimination or mitigation of the two most common cell unavailability use cases:

• sleeping cell - i.e. a situation where a node is powered-up and provides the pilot signal in its service area (users see it as coverage in their terminals), as well as remaining pseudo-operational from the OAM perspective, but in reality does not take on any traffic. COD uses various mechanisms to detect such a state and applies recovery procedures automatically (e.g. reboot).
• hardware or power fault - in such cases, software-level restoration methods will fail, so a self-healing SON may start a COC procedure which will readjust the neighboring nodes’ antenna power and tilt to provide coverage in the faulty cell area (as much as possible and possibly without degradation of service in their own cells)

This list is not exhaustive, but is a good representation of SON capabilities.

Preparing for SON implementation

As usual, SON implementation in a service provider’s network must be preceded by several technical and business steps, performed with scrutiny and careful planning and decision making.

First, an organization must collect and audit detailed information about the current state of the network, such as:

• Used RAN features, per vendor and RAT,
• RAN parameters and policies (regarding e.g. handovers, admission control, neighbor relations, capacity and load balancing, traffic prioritization, frequency plans/licensing, etc.),
• antenna hardware types and capabilities,
• performance counters and KPIs actively measured and collected,
• RAN infrastructure management plane architecture and capabilities to accommodate SON platform needs plus OSS systems dimensioning information,
• RAN infrastructure inventory (cells’ geolocation),
• network expansion and reorganization plans, both in terms of capacity and RAT evolution,
• the numbers describing the network size (nodes, controllers, subscribers, OSS subsystems, etc.)

Second, the carrier organization must define the expected benefits from the investment, putting improvement targets on different aspects like:

• CAPEX and OPEX savings,
• customer satisfaction and churn KPIs,
• various technical KPIs (e.g. data transfer performance, voice call quality, service availability, mobile service continuity, etc.)

Finally, based on collected data and expected outcomes, the optimal architecture design should be developed, i.e. the portfolio of SON applications to be implemented and the infrastructure investments needed for SON adoption, taking into account the required type of architecture, disaster recovery, system orchestration, interworking with OSS, management links capacity, etc. Of course, there is also the non-technical part of this equation, related to choosing the vendor and the best offer, training the staff, running the project, etc.

The evolution of SONs continues…

So far in this article we’ve been describing the standardized (3GPP) shape of SONs. Before we wrap up, let us briefly take a look at some market innovations..

1. Ericsson has proposed an implementation of the O-RANs (Open RAN Alliance) service management and orchestration (SMO) framework called Intelligent Automation Platform      , which can be considered an evolution of SON, capable of running not only 3GPP standardized SON applications, but also custom ones with an open possibility of defining and implementing completely new use cases, including ones leveraging AI and ML. In essence, the Non-Real-Time RAN intelligent controller (Non-RT-RIC) runs automation applications called rApps. Aside from built-in rApps, it can run custom ones defined by the CSP themselves or a third party, and an SDK is provided to facilitate their development.
2. Nokia claims to have gone a step further      , bringing ML capabilities to SON configuration itself, calling it Cognitive SON, and promising a fully autonomous operations model, where a human decision maker defines only the high level objectives for network performance and the system takes care of the rest - including the application selection, defining cell contexts and low level objectives, finally verifying the result and rolling back if necessary. The solution in tests with one production network proved to be 160 times faster in problem resolution and achieved 95% faster load balancing.

Final word

As already mentioned, the adoption of SONs among CSPs is still far from being common. And even among the current adopters, the level of fully entrusting RAN optimization to SONs varies among CSPs and it is not unusual that SONs only serve as a “recommendation” platform for radio engineers who then need to take manual decisions and steps to implement changes, which stretches the duration of the process significantly. It is every organization’s right to choose this approach but we must be aware that with the growing scale and complexity of networks in the newest and coming generations (5G, 6G,...) - that will eventually no longer be possible. Network automation in general is more and more a must not only economically, but physically - the sheer number of decisions and actions that need to be made in complex technical environments is simply unmanageable in the traditional way.