# Self-Organizing Networks for 5G and Beyond: A View from the Top
## 2 SON Operation Rationale, Use Cases, Standardization, Architectures and Dimensioning
### SON Systems Basic Architectures and Operation Rationale  
In terms of SON system architectures, the 3 GPP consortium defines the following three types of SON architectures that can be applied in 2G/3G/4G and 5G networks [57; 58; 59; 60; 61; 62; 63; 64]:  
* Centralized (C-SON).
* Distributed (D-SON).
* Hybrid (H-SON).  
In centralized SON (C-SON) architectures, a SON platform that resides in a server cluster handles all network elements centrally through the interaction with the OSS (Operations Support System) of each RAN technology. C-SON is the most widespread solution for mobile operators; however, it might present single point of failure characteristics. On the other hand, the basic advantage is that the overall network status information/KPIs are collected and processed centrally, and thus the SON platform has a better insight regarding the network health status. In Distributed SON (D-SON) cases, SON functions run locally at the base stations, while Hybrid SON (H-SON) is a combination of the prementioned cases that is not widely used.  
Moreover, in terms of infrastructure, SON platforms reside on server clusters which host the SON applications running per radio access technology (GSM/UMTS/LTE/5G), the database of the system, the orchestrator, which is the entity managing the applications,and the API (Application Programming Interface). The system interacts directly and in real time with all basic radio access network controllers (BSC/RNC/MME/AMF) and the OSS and collects live performance counters and KPIs, which are analyzed by the running algorithm of each SON application. The outcome is the automated creation of an executable script executed with no manual intervention through the OSS. More specifically, each script is executed through a dedicated privileged SON OSS account and then an evaluation period/timeframe starts where the SON application algorithm decides to revert the action/script created and executed [27]. A high-level LTE SON system design is proposed in Figure 4 and since 5G SON systems derive from LTE, the same design rationale applies to 5G as well and the only difference is that MME is replaced by AMF [13]. A SON platform consists of the hardware part, including the servers and RAN database, the management of SON applications and orchestration module, which handles SON applications and APIs, providing the ability to handle and manage the RAN database. A SON server cluster interacts with the LTE OSS system of each RAN vendor and uses the latter to commit configuration plans that include the changes that each SON application decides. Configuration plans are committed to the OSS of each vendor in case more than one exists and through the MME to the base stations.  
As far as the applications are concerned, the rationale that rules all applications is divided into three phases. As depicted in Figure 5, the snapshot period concerns the evaluation of the current state of the network according to the counters of KPI collection prior to any SON actions taken, the action phase concerns the creation and execution of a script for the OSS through SON applications, and the feedback period concerns the evaluation of the action phase and a decision to keep a specific action in the network or revert it to the initial pre-SON operation status [55; 65].  
Figure 4: High-level SON system architecture.