I was going through the presentation by SKT that I blogged about
here and came across this slide above. SKT is clearly promoting the benefits of their C-SON (centralized SON) here.
The old 4G Americas whitepaper (
here) explained the differences between the three approaches; Centralized (C-SON), Distributed (D-SON) and Hybrid (H-SON). An extract from that paper here:
In
a centralized architecture, SON algorithms for one or more use cases reside on
the Element Management System (EMS) or a separate SON server that manages the
eNB's. The output of the SON algorithms namely, the values of specific
parameters, are then passed to the eNB's either on a periodic basis or when
needed. A centralized approach allows for more manageable implementation of the
SON algorithms. It allows for use case interactions between SON algorithms to
be considered before modifying SON parameters. However, active updates to the
use case 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.
In a distributed approach, SON algorithms
reside within the eNB’s, thus allowing autonomous decision
making at
the eNB's
based
on UE measurements received on the eNB's and additional information from
other eNB's being
received via the X2 interface. A distributed architecture allows for ease of deployment
in multi-vendor
networks and optimization on faster time scales. Optimization could be done for
different
times of
the day. However, due to the inability to ensure standard and identical
implementation of
algorithms in a
multi-vendor network, careful monitoring of KPIs is needed to minimize
potential network
instabilities and
ensure overall optimal operation.
In
practical deployments, these architecture alternatives are not mutually
exclusive and could coexist for different purposes,
as is realized in a hybrid SON approach. In a hybrid approach, part of a given SON
optimization algorithm
are executed in the NMS while another part of the same SON algorithm could be
executed in
the eNB. For example, the values of the initial parameters could be done in a centralized
server and
updates and refinement to those parameters in response to the actual UE measurements
could be
done on the eNB's.
Each
implementation has its own advantages and disadvantages. The
choice of
centralized, distributed or hybrid architecture needs to be decided on a
use-case by use case
basis depending
on the information availability, processing and speed of response requirements
of that
use case.
In the case of a hybrid or centralized solution, a practical deployment would
require specific
partnership between
the infrastructure vendor, the operator and possibly a third party tool company.
Operators can
choose the most suitable approach depending upon the current infrastructure
deployment.
Finally, Celcite CMO recently recently gave an interview on this topic on
Thinksmallcell here. An extract below:
SON software tunes and optimises mobile network performance by setting configuration parameters in cellsites (both large and small), such as the maximum RF power levels, neighbour lists and frequency allocation. In some cases, even the antenna tilt angles are updated to adjust the coverage of individual cells.
Centralised SON (C-SON) software co-ordinates all the small and macrocells, across multiple radio technologies and multiple vendors in a geographic region - autonomously updating parameters via closed loop algorithms. Changes can be as frequent as every 15 minutes– this is partly limited by the bottlenecks of how rapidly measurement data is reported by RAN equipment and also the capacity to handle large numbers of parameter changes. Different RAN vendor equipment is driven from the same SON software. A variety of data feeds from the live network are continuously monitored and used to update system performance, allowing it to adapt automatically to changes throughout the day including outages, population movement and changes in services being used.
Distributed SON (D-SON) software is autonomous within each small cell (or macrocell) determining for itself the RF power level, neighbour lists etc. based on signals it can detect itself (RF sniffing) or by communicating directly with other small cells.
LTE has many SON features already designed in from the outset, with the X.2 interface specifically used to co-ordinate between small and macrocell layers whereas 3G lacks SON standards and requires proprietary solutions.
C-SON software is available from a relatively small number of mostly independent software vendors, while D-SON is built-in to each small cell or macro node provided by the vendor. Both C-SON and D-SON will be needed if network operators are to roll out substantial numbers of small cells quickly and efficiently, especially when more tightly integrated into the network with residential femtocells.
Celcite is one of the handful of C-SON software solution vendors. Founded some 10 years ago, it has grown organically by 35% annually to 450 employees. With major customers in both North and South America, the company is expanding from 3G UMTS SON technology and is actively running trials with LTE C-SON.
Quite a few companies are claiming to be in the SON space, but Celcite would argue that there are perhaps only half a dozen with the capabilities for credible C-SON solutions today. Few companies can point to live deployments. As with most software systems, 90% of the issues arise when something goes wrong and it's those "corner cases" which take time to learn about and deal with from real-world deployment experience.
A major concern is termed "Runaway SON" where the system goes out of control and causes tremendous negative impact on the network. It's important to understand when to trigger SON command and when not to. This ability to orchestrate and issue configuration commands is critical for a safe, secure and effective solution.
Let me know your opinions via comments below.
