4G/LTE - SON

SON(Self Organized Network/Self Optimized Network)

Note : This page is posted by Israel Zimerman who is an expert in this area (LinkedIn). It is really appreciated for him to share his experties and experience.

SON stands for Self-organized and Self-optimized Network.

SON has several aspects. Some of them are standardized, others are mentioned in the standard and are open to interpretation and implementation and more are in the spirit of SON and are independent of it.

SON also applies to several aspects in the life cycle of the network elements.

The overall concept is simple but since it has many “faces” it is a bit complex to explain.

The main drivers for SON were the high operational aspects that operators started to face since the initiation of the 4G (i.e. number of network parameters, parallel operation of 2G, 3G, 4G infrastructures, rapidly expanding number of Base Stations).

I’ll try to have an overview of the subject as I know it while going over several main topics, as follows:

1.  Standardization

2.  RAN optimization

3.  Self-organization and self-optimization concepts

4.  Closed loop

5.  Resources of input

6.  DSON and CSON

Standardization

The 3gpp is dealing with SON concept, more or less, since release 8.

Let’s take 3gpp 36.902, Self-configuring and self-optimizing network (SON) use cases and solutions introduction (was not moved forward to R10). I marked few key words in yellow and I’ll relate to them later on in the post:

“Reduction of operational efforts and complexity are key drivers for RAN Long Term Evolution. One of the important aspects to this is that the system operability is improved under multi-vendor environment. It is of importance that measurements and performance data of different vendors share the same “language.” Such alignment is easing ease network performance analyses and problem finding, and reduces efforts in maintaining the network at a properly working state.

It is also of interest to minimize operational effort by introducing self-configuring and self-optimizing mechanisms. A self-optimizing function shall increase network performance and quality reacting to dynamic processes in the network.

Especially in the early deployment phase, the efforts to set up and optimize are significant and traditionally lead to lengthy periods of getting an optimum and stable system setup. It is thus essential to have the necessary set of self

Configuration and self-optimization mechanisms already available when initial deployment starts.

As such, standardization is asked to define the necessary measurements, procedures and open interfaces to support better operability under multi-vendor environment. Such standardized functions shall also facilitate self-configuration and self-optimization under multi-vendor environment. Especially the interaction between self-configuring/optimizing networks and O&M has to be considered.”

In order to standardize the SON functionalities towards multi-vendor capabilities, several procedures were defined as SON fundamentals In LTE.

3gpp defined a set of papers for this purpose under the series 32 series “OAM&P and Charging”:

It is not that these aspects were not here before in RAN of legacy networks, nor they were not addressed, but in order to have multi-vendor alignment and to define interfaces accordingly, they are listed and defined.

The fundamental procedures that were identified by the 3gpp (3gpp 36.905):

RAN optimization

There are 3 main subjects that I noticed go along the history of RAN optimization:

1.  How to model the RAN, meaning, what are the relationships between each and every network element with respect to coverage and interference.

2.  How to conclude what needs to be changed for better performance.

3.  How to implement the concluded changes.

The way I see it, the evolution of RAN optimization till SON is illustrated in the following graph, which consists 2 axes:

Optimization measures, which mean the number of network changes that, are executed for optimization purposes.

Network modeling evolvement, which mean the dimensions of the inputs that feed the optimization process (i.e. drive test is flat; UEs data is 3D as it is from the real UE location).

Self-Organized and self-Optimize concepts

Self-Organized and self-Optimize sometimes are mixed together.

Let’s look at an eNodeB from the time it’s first introduced into the network.

1.An eNodeB is planned, using a planning tool, which is external to the cellular system. Its antenna parameters are decided.

2.It’s built physically and then configured in the OSS via a management system (there are hundreds of parameters to configure, such as radio, back-hole, interfaces, inventory, etc).

3.The eNodeB is then tested and can be activated.

4.The radio parameters along with antenna parameters are set according to preliminary information. It is then needs to be optimized.

Part of the parameters should be changed according to a predefined network policy and then remain static. Part of the parameters should be dynamically changed according to the advancing network deployment. Part of the parameters (normally, a small group) should be dynamically changed according to the eNodeB’s area radio conditions (capacity, interference etc.).

The static parameters are more related to the concept of self-configuration. The radio-driven dynamic parameters are related to self-optimization and the network-configuration-driven dynamic parameters are more likely to be related to self-configuration but can also be referred to as optimization.

Let’s take some parameters as an example:

• Physical cell ID (PCI) - may be planned manually before configuration and set manually. It could also be set by DSON or by CSON, once the eNodeB is activated and afterwards while it is operational and there is a reason to change it for optimization reason.
• Cell’s Neighbor list (NRT) – a preliminary NL can be set before the eNodeB is activated (manually according to planning tool). The neighbor list can be configured and optimized after the eNodeB activation by a DSON function that allows adding new neighbors according to UEs demand. A CSON function can do the same or can also supervise the DSON function.
• Hand over parameters – will need to be changed frequently according to cell’s performance and also according to the network deployment progress. It may also need to be changed according to a new operator’s concept that creates a new policy for traffic management.

Closed loop

Another concept of SON is the closed loop.

It is expected from a SON system to constantly monitor the RAN and look for pre-defined events or anomalies that should be alarmed or handled by the system.

Once an event is triggered, an action is initiated and executed to the network element, and it is expected that the SON system (DSON or CSON) will monitor and revert the parameter or the set of parameters values that were changed, back to its original value, if necessary (i.e. the trigger reason has passed or due to bad algorithm decision) or keep it until a different trigger is initiated.

This is more relevant to self-optimization functionalities. A common description of this functionality looks like the following:

Resources of input

When discussing inputs that feed SON procedures, it is more likely to refer to CSON rather than DSON since DSON can be fed by a near real time events occurring at the network element where the DSON is distribute at.

So, the list of known inputs:

•   Network elements counters/ KPIs.

•   Network traces containing UE measurements.

•   Various applications/agents installed on the mobile that gather UE data and send it to the SON server.

•   Switch / S-GW CDRs (Call Detailed Record).

•   Probes that are coupled to the network elements.

What is not considered an input for SON anymore is drive-test data. Moreover, there is a new 3gpp concept, minimization of drive-test (3GPP TS 37.320).

DSON and CSON

There are several options to implement SON in a cellular network.

•Distributed SON which is implemented within the eNodeB and utilizes X2 interface (a new interface that was defined by 3gpp TS 36.423: "X2 application protocol (X2AP) ) between eNodeBs.

•Centralized SON, which is outside the EUTRAN and is implemented on a managing server, either of the EUTRAN managing system itself or any third party SON management system.

•Hybrid approach.

DSON can be implemented by the eNodeB manufacturer while CSON can be developed either by the eNodeB manufacturer, which also normally provides the management system along with the OSS (Operational and Support System) or it could be developed and implemented by a third party manufacturer.

It is common to see networks that utilize DSON and CSON together as a hybrid solution.

The main advantage of a third party CSON over the network vendor’s CSON is the aspect of multi-vendor. It is very common to see cellular network operators deploying eNodeBs of more than one manufacturer. Normally it is while splitting the coverage area into 2 and deploying each vendor in a separate area, leaving a border line in between. It is also not rare to see mixed networks having eNodeBs of different vendors side by side.

As both, DSON and CSON development evolves; SON functionalities may shift to be more commonly used at the DSON level rather than the CSON level, while CSON may be required to be in charge of new functionalities or over the management of DSON operational aspects