In a centralized architecture, SON algorithms for one or more usecases reside on the Element Management System or a separate SON server that manages the eNBs. The output of the SON algorithms namely, the values of specific parameters, are then passed to the eNBs either on a periodic basis or when needed. A centralized approach allows for more manageable implementation of the SON algorithms. It allows for usecase interactions between SON algorithms to be considered before modifying SON parameters. However, active updates to the usecase parameters are delayed since KPIs and UE measurement information must be forwarded to a centralized location for processing. Filtered and condensed information are passed from the eNB to the centralized SON server to preserve the scalability of the solution in terms of the volume of information transported.
Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.
There are three key time intervals associated with Centralized SON.
1. The Collection Interval is the period during which statistics are collected and uploaded. This is also the smallest available granularity for data analysis. This interval is most likely determined by the vendors OAM statistics throughput limitations. Most Network Management solutions would typically support a five minutes interval.
2. The Analysis Interval is the time period considered in the decision process for parameter adjustment. It is beneficial to consider more than a single collection interval in the analysis. While the latest collection interval should have the greatest impact on the analysis, the output should be damped to take into account results from previous intervals.
3. The Change Interval is the period between changes applied to the network by SON. System performance constraints may limit the number of cells for which changes are applied at any given time. This could result in Change Intervals that do not align directly with the Collection Intervals. These limiting factors don’t always apply, but centralized solutions either need to have vastly over provisioned processing and networking capability, or intelligent change management.
Centralized SON (C-SON) are sometimes deployed for Automated Neighbor Recognition (ANR), cell configuration, power control, interference and load management at the network operations center. This is OSS Level SON emerged first for 3G networks as 3GPP introduced a number of Self Organizing Networks (SON) standards starting with Release 8 in 2008 and expanded them in Release 9 with use cases in 2010/11. C-SON provides a centralized architecture that manages all edge radio nodes. It can potentially orchestrate the behavior of radio network equipment across an entire network of multi-vendor and multi-technology environments. C-SON can take into consideration data from all nodes in the network to identify and address network-wide issues. And since the control of all SON functions is done centrally, these interactions can easily be coordinated and managed using a variety of resolution techniques.
C-SON is mostly offered by 3rd-party SON solution providers. Equipment Vendors may also offer some form of centralized SON. C-SON executes at the level of the OSS using standardized IRP as well as proprietary interfaces. Benefits of C-SON are:
Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.
There are three key time intervals associated with Centralized SON.
1. The Collection Interval is the period during which statistics are collected and uploaded. This is also the smallest available granularity for data analysis. This interval is most likely determined by the vendors OAM statistics throughput limitations. Most Network Management solutions would typically support a five minutes interval.
2. The Analysis Interval is the time period considered in the decision process for parameter adjustment. It is beneficial to consider more than a single collection interval in the analysis. While the latest collection interval should have the greatest impact on the analysis, the output should be damped to take into account results from previous intervals.
3. The Change Interval is the period between changes applied to the network by SON. System performance constraints may limit the number of cells for which changes are applied at any given time. This could result in Change Intervals that do not align directly with the Collection Intervals. These limiting factors don’t always apply, but centralized solutions either need to have vastly over provisioned processing and networking capability, or intelligent change management.
C-SON is mostly offered by 3rd-party SON solution providers. Equipment Vendors may also offer some form of centralized SON. C-SON executes at the level of the OSS using standardized IRP as well as proprietary interfaces. Benefits of C-SON are:
- Flexibility of customization satisfies the unique needs and policies of the Operator.
- Access to the converged performance of the entire multi-vendor and multi-technology heterogeneous network (HetNet) including support for segregated shared network configurations.
- Ability to automate optimization and self-healing across network layers.
- Orchestration and coordination of multiple SON functions and across all Vendor-specific D-SON systems.
- Enrichment of SON functions by using business data, for example, Customer Experience Data (CEM) to improve subscriber experience.
- Self-learning capabilities based on patterns of historical network and business data.
- Capability to correlate data across different dimensions including performance measurements, fault management data, configuration changes, and element maintenance activities, etc. to improve root-cause analysis
