The 5G Standard

Self-Organising Networks (SON)

Jun 17,2024

By Juha Korhonen, 3GPP MCC

A self-organizing network (SON) is an automated technology which is designed to help the management of mobile networks. SON enables network self-configuration and self-optimization. SON is actually a umbrella concept, covering different techniques which provide different SON solutions. SON is only specified at the concept level. That is, the specifications may contain for example some measurement parameters that will at as input to SON functions, but the actual contents of those functions are left to implementation.

SON as a concept is already quite an old one. It has first introduced into 3GPP specifications in Release 8; that is in year 2009. However, it has not been universally adopted even now, 15 years later. The main reason is the fact that network management is a complex issue, and networks come in many different configurations. They are quite often multi-vendor systems and their management interfaces are not open, i.e., not strictly standardised. As a result, SON applications have to be more or less tailored for each network. This has slowed down their deployments. But more and more operators will adopt SON functions since the networks are becoming more complex with more functions, and their deployments will also become more complex and dynamic. It is no longer enough if a base station is configured when it is connected to the network, and it is then run with the same configuration for the rest of its lifecycle.

For example, energy saving is becoming more and more important issue, also in mobile communications. Mobile networks consume lots of electricity, and operators may want to switch off some base stations when they are not needed, such as at night time when the capacity demand is lower, and configure the neighbouring base stations so that they can serve the coverage area of the base station that was switched off. Again, once the capacity demand increases in the morning, the base station in question has to be switched on, and the surrounding network should be configured correspondingly. And since a large mobile network can have hundreds of thousands of base stations, manual configuration in a situation such as above is out of question.

Network management processes come in two basic types: open-loop and closed-loop. Open loop processes take inputs such as measurement results, process them, but do not actually configure anything without a user input. Closed-loop processes take these inputs, process them, and also configure relevant parameters as a result. User intervention is not needed. SON functions are closed-loop processes.

SON Architecture

At high level, SON comes in three different variants:

  • Centralised SON: SON solution where SON algorithms are executed in the OAM system. Centralised SON has two variants:
    • NM-Centralised SON: SON solution where SON algorithms are executed at the Network Management level.
    • EM-Centralised SON: SON solution where SON algorithms are executed at the Element Management level.
  • Distributed SON: SON solution where SON algorithms are executed at the Network Element level.
  • Hybrid SON: SON solution where SON algorithms are executed at two or more of the following levels: NE or EM or NM.

Distributed SON

In this type of SON (D-SON), functions are distributed among the network elements at the edge of the network, typically at eNodeB elements. SON functions of this kind are usually supplied by the network equipment vendor manufacturing the radio cell.

Centralized SON

In centralized SON (C-SON), SON functions are concentrated closer to higher-order network nodes or the network OSS, to allow a broader overview of more edge elements and coordination of e.g. load across a wide geographic area. Due to the need to inter-work with cells supplied by different equipment vendors, C-SON systems are more typically supplied by 3rd parties.

Hybrid SON

Hybrid SON is a mix of centralized and distributed SON, combining elements of each in a hybrid solution.

SON functionality groups

SON functionalities can be divided into following groups: self-configuration, self-optimisation and self-healing functions.

Self-configuration functions

Self-configuration means that when new base stations are added to the network, they are automatically configured so that they can be part of the network. The configuration parameters are downloaded to a SON-capable base stations at power up. Thereafter the neighbouring base stations have to reconfigure their parameters so that they can work together with the new base station. That is, they should together provide wide enough coverage, enough capacity, and avoid interfering each other as much as possible.

However, self-configuration provides only the initial configuration for the base station. It is done without any feedback from the mobile stations. Any further parameter configuration should be done via the self-optimisation functions, based on measurement results.

Self-optimisation functions

A mobile network operates in a very dynamic environment. A typical base station contains a very large number of configuration parameters which define the base station behaviour. Some of those parameters also affect neighbouring base stations, and any changes to neighbour's parameters can further affect their neighbours. In addition, it is not only the base stations which have an effect on configuration parameters. Mobile stations, their numbers, their movements, the amount of traffic load, etc, must be taken into consideration in network configuration parameters. There can also be external factors, not related to the mobile networks themselves, such as interference from external sources.

Therefore base station configuration parameters have to be continuously updated, based on measurement results from both the network and the mobile stations. These are handled by SON self-optimization functions. The example case for SON in the beginning of this article, night time base station switch off is a good example of a self-optimization energy saving function.

Self-healing functions

When something goes wrong in a mobile network, the problem has to be quickly identified and corrective actions taken. Base station components can get broken, data transmission lines can get cut, electricity network may have supply problems, etc. In case of network problems, the operator must quickly get notified that there is a problem, the location of the problem, and the cause for it. This is not necessarily a trivial task. For example, if a base station does not have working transmission lines, it cannot inform the network that it has a problem. Furthermore, once the problem is identified, corrective measures have to taken at once. The problem itself may be time-consuming to fix, but its effects should be quickly compensated as much as possible using SON self-healing functions. For example if a base station stops working, its neighbouring base stations should reconfigure themselves to provide network coverage over the failing cell. Automated SON mechanisms can handle this task much quicker than a human intervention.

Self-healing functions may not be able to repair the original problem, but they will provide a temporary fix which gives the network operator time to analyse and then correct the problem as appropriate.

Self-protection functions

SON functions can also be used to protect the system from security attacks. As with many other SON functions, in self-protection cases the speed is of essence. If a security attack takes place, it has to be identified at once, and corrective actions should be taken immediately.

SON Use Cases

In this section a few practical SON use cases are presented, to show the benefits of this technology. In general, SON provides cost saving for operators because it reduces the amount of human interventions and improves network performance. It also functions quicker than a traditional human-operated network management system. Moreover, since SON functions are automated, they are more "safe" in that they do not make human errors. That is, a human operator may accidentally switch off the wrong base station, etc.

Energy Saving

Energy Saving is a self-optimization function that allows network to switch off cells if their capacity if not needed temporarily. The amount of energy saved can be considerable since large mobile networks may contain a very large number of base stations (100 000's?) and even if a small number of those can be switched off, the cost savings are significant. An energy saving SON function can be used at night time to switch off such base stations whose capacity is not needed because of the reduced traffic load. Another typical energy saving use case is office blocks which may need lots of capacity during office hours, but almost none at all during weekends.

Because the use of an energy saving function is typically quite common, it is best to be handled via an automated SON function. If a base station is switched off, its neighbouring cells must be reconfigured by SON functions to handle the remaining users from this cell. This may include tasks such as increasing the base station transmission power, or redirecting its antennas.

Like most network management process, energy saving cannot be considered in isolation from other network management issues. Energy saved in one base station will have an effect on load balancing, quality of service and energy consumption elsewhere in the network. A SON energy-saving function has to take care of all these issues and not simply switch off the base station once the cell load becomes lower than a certain set threshold.

Load balancing

In a modern mobile network the cells are oftentimes overlapping, either partially or fully. In fact, in traffic hotspots there can be several "layers" of cells serving the same area. This enables the network operator to balance the cell load so that no cell becomes overloaded. In principle, the mobile station should be connected to the closest base station (or the base station with the strongest radio signal). But this may lead to a situation where base station A gets overloaded during lunch time because it is located in a popular restaurant area, but a nearby base station B has no traffic at all even though the restaurants are also within its cell coverage.

Load balancing function allows the network to direct some of the users from base station A to base station B. The SON load balancing function has to know the load status in the heavily loaded cell, and in all neighbouring cells. In addition, there is a long list of other parameters which have to be known before a successful load balancing procedure can be launched. For example, a mobile station in the heavily loaded cell may not be handed over to any neighbouring cell because of radio conditions. It may also require QoS which is not available in all neighbouring cells. Movement of mobile stations must also be considered. There is no point in ordering the mobile station to make a handover to a base station which is opposite from the direction where the mobile station is moving.

A good load balancing scheme should be able to forecast the cell load after the planned load balancing operation. Is it better than the current situation, or will it simply make some other cell overloaded? Also, there are issues such as how long this load balancing scheme should be maintained. A mobile station which is handed over to another cell because of an overload situation is probably not served by a base station with the best radio conditions. Should the UE be allowed to return to the best serving cell, and when?

Mobility Management

Mobility management takes care of mobile stations which are on the move. The base station cells are typically getting smaller since they have to provide more capacity and oftentimes on higher frequencies. Thus, more handovers will occur, and their management should preferably be handled by an automated SON function.

In simplistic terms, mobility management involves the base station to request frequent signal strength measurements from the UE, for both the serving cell and the neighbouring cells. If the neighbouring cell provides a better radio signal (possibly with some threshold value), a handover may be launched.

However, in real networks the above scheme does not provide good enough mobility management. As with other network management processes, mobility management cannot be considered in isolation of other management processes. A handover to another cell affects also the cell load and base station energy consumption, among other factors.

The type of UE mobility should also be considered. A fast moving mobile station should not be handed over to a small pico or micro cell. Instead a large macro cell should be assigned to the mobile station if such is available. A SON function should be aware of history of handovers in a cell/area. If a road is covered by three base stations A, B and C, then almost all mobile stations which make a handover from A to B, will soon make another handover to cell C, even if some other nearby base station may provide a better signal temporarily. Also, the mobility management must know if the prospective new cell can provide the required QoS.

As seen from above, a mobility management SON function requires lots of input parameters to be able to make the correct decisions and at the correct time.

Future of SON

It is likely that in the future SON processes will adopt Artificial Intelligence (AI) models to improve SON performance. SON processes are very complex, with many input parameters involved. Some SON processes may have conflicting targets. For example energy saving may lead to performance degradation, or indeed increased energy consumption if not handled properly. It may seem that a base station can be switched off because of reduced capacity demand, and the remaining users can be served by neighbouring base stations. However, since those users are now further away from the serving base stations, they will require higher transmission power for their signals. An AI SON model must be trained with lots of different data until it can react appropriately to changing network conditions, and also predict the future, i.e., what will happen in case the network is configured in a certain way, and thus what kind of reconfiguration is preferable.

Similar AI based approaches are also needed for other SON functions. Those AI models have to be trained with large amounts of real-life data which covers all types of situations.

Conclusions

SON deployments enable mobile operators to decrease network roll-out times, reduce dropped calls, improve throughput, lessen congestion and achieve other operational efficiencies including energy and cost savings.

Newly added base stations should be self-configured in line with a "plug-and-play" paradigm while all operational base stations will regularly self-optimize parameters and algorithmic behaviour in response to observed network performance and radio conditions. Furthermore, self-healing mechanisms can be triggered to temporarily compensate for a detected equipment outage, while awaiting a more permanent solution.

And last, it must be stressed again that all SON functions are implementation specific. They are not specified in any public standard. The processes to support SON functions, such as measurements performed by mobile stations, are specified (like anything that is transmitted over the radio interface), but not how those measurements are used. Therefore the more clever the SON implementation, the better the network performance.

Further reading:

3GPP TS 38.300, clause 15.