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

The links below jump to each of these topics.

• Standardization
• RAN optimization
• Self-Organized and self-Optimize concepts
• Closed loop
• Resources of input
• DSON and CSON
• Reference

Standardization

SON is an operations topic as much as a radio topic, so the relevant 3GPP documents are spread over two groups. The radio side is in the 36 series, and the management side is in the 32 series. This section shows both and explains why a multi-vendor network needs them.

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.902):

The table above is the Release 9 use case list of TR 36.902, the same document as the quotation. TR 36.902 stops at v9.3.1. The radio-side solutions that were standardized, such as ANR, PCI selection, mobility load balancing, mobility robustness and RACH optimisation, continue in clause 22 of TS 36.300. The management-side documents in the 32 series are also still maintained, and TS 32.500 has reached v19.0.0.

• TR 36.902 lists the use cases : it was not continued after Release 9.
• 36.300 clause 22 carries the radio-side solutions : it is the reference to check for the current behaviour.
• The 32 series carries the management side : it defines how an OAM system configures and controls SON functions in a multi-vendor network.

RAN optimization

Before SON, optimization was a manual loop of measuring, deciding and changing parameters. Let's see how each part of that loop changed over time, because SON is the end point of that change rather than a new idea.

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).

Read the diagram along both axes. On the vertical axis, the network model moves from a flat model built from drive tests, to a 3D model built from mobile statistics, and then to a 3D model with more inputs added. On the horizontal axis, the optimization moves from manual changes and manual monitoring, to software modeling with a mass number of changes and manual monitoring, and finally to software modeling with continuous changes and software monitoring.

The last box, at the upper right, is SON. Both the modeling and the monitoring are done by software, so the changes can be continuous instead of periodic. The three subjects of RAN optimization fit the two axes of the diagram. The vertical axis answers how to model the RAN, and the horizontal axis answers how to decide and implement the changes.

• Better models came from better inputs : drive tests gave a flat picture, and UE statistics gave a 3D picture.
• More changes needed software : a mass retune is not practical with manual monitoring alone.
• SON is continuous : software both makes the changes and monitors their effect.

Self-Organized and self-Optimize concepts

The two words self-organization and self-optimization describe different parts of an eNodeB's life. Following one eNodeB from planning to operation is the easiest way to separate them.

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.

36.300 clause 22.1 draws the line at the RF transmitter. Self-configuration works in the pre-operational state, from power-up with backbone connectivity until the RF transmitter is switched on. Self-optimisation works in the operational state and uses UE, eNB and performance measurements. PCI selection is a self-configuration function in 36.300 clause 22.3.5. It can be centralized, where the OAM signals one PCI value, or distributed, where the OAM signals a list and the eNB chooses from it.

• Static parameters belong to self-configuration : they are set once and follow a network policy.
• Radio-driven parameters belong to self-optimization : they follow the capacity and interference around the eNodeB.
• PCI and neighbor list can be both : they are configured first and optimized later, by DSON or CSON.

Closed loop

A SON function that changes parameters also has to check whether the change helped. That check is what makes the loop closed, and it is the main difference from a one-time optimization.

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:

The diagram shows four steps in a cycle. The SON system analyzes the network, decides on changes and executes them, and then monitors the result. After monitoring, it either reverts the changes or maintains them, and the loop starts again with a new analysis.

The operator keeps control of the loop through OAM. For mobility load balancing in 36.300 clause 22.4.1, all automatic changes on the handover and reselection parameters must be within the range allowed by OAM. So the loop runs freely, but only inside limits that the operator sets.

• Monitoring comes after every change : the loop does not end when the change is executed.
• Revert is a normal outcome : a change is undone when its trigger has passed or when the decision was wrong.
• OAM sets the limits : automatic changes stay within the parameter range that the operator allows.

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).

MDT replaces the drive test with measurements from ordinary UEs. TS 37.320 defines two modes. In Immediate MDT, a UE in connected state measures and reports to the RAN when a reporting condition is met. In Logged MDT, a UE in idle state logs measurements and reports them to the network later. For Immediate MDT, the UE also provides detailed location information, such as GNSS location, if it is available.

MDT reuses the trace functions of the network. When MDT targets a specific UE, for example by IMSI, the signalling based trace procedure is used. Otherwise, the management based trace procedure is used. This is why network traces and MDT are closely related inputs in the list above.

• Counters and traces are the basic inputs : they come from the network elements themselves.
• MDT replaces drive tests : ordinary UEs log and report their measurements.
• Location is the key addition : a UE measurement with GNSS location gives the 3D model described in the RAN optimization section.

DSON and CSON

Where the SON algorithm runs decides what data it can use and how fast it can react. There are three answers to that question, and a real network often uses all three.

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

TS 32.500 gives the formal definitions. Distributed SON executes the SON algorithms at the network element level. Centralised SON executes them in the OAM system, and it has two variants. NM-centralised SON runs at the network management level, and EM-centralised SON runs at the element management level. Hybrid SON executes SON algorithms at two or more of these levels: NE, EM or NM.

This split matches the input discussion above. A distributed function in the eNodeB sees its own events in near real time, and it exchanges information with neighbours over X2. A centralized function sees many cells, and often many vendors, but it works on counters and traces that arrive later.

• DSON runs in the network element : it reacts fast and uses local events and X2 information.
• CSON runs in the OAM system : it can be at the NM level or at the EM level.
• Hybrid SON combines levels : the algorithm runs at two or more of NE, EM and NM.
• Multi-vendor networks favor a third-party CSON : it can apply one policy across vendors.

Reference

[1] 3GPP TR 36.902 v9.3.1 - Self-configuring and self-optimizing network, SON, use cases and solutions

[2] 3GPP TS 36.300 v19.2.0 - clause 22, Support for self-configuration and self-optimisation

[3] 3GPP TS 32.500 v19.0.0 - Self-Organizing Networks, SON, Concepts and requirements

[4] 3GPP TS 37.320 v19.3.0 - Minimization of Drive Tests, MDT, Overall description