SON stands for Self Organizing Network. What does this mean ? Ideally it means that just add a eNB wherever you want to put and just connect power and switch on, it would configure all of its configuration by itself and makes itself ready for service.

If you think a whole mobile network as a single PC, SON is like 'Plug-and-Play' functionality. (just Plug a any hardware (e.g, Keyboard, Printer etc) and it would play).

This page starts from the idea, moves to the reasons for it, and then checks what 3GPP actually standardized. Keep one thing in mind while reading. The SON use cases were written in the Release 9 time frame, and the functions that were standardized are now in clause 22 of 36.300.

Followings are the topics to be covered in this page.

• Which steps of building a network does SON automate ?
• Why do we need SON ?
• Major Goals for SON
• Use Cases for SON
• Where did the SON use cases end up in the LTE specification ?
• Reference

Which steps of building a network does SON automate ?

Let's first look at what an operator does by hand when a new eNB goes on air. SON is easiest to understand as a list of those manual steps, with a mark on each step that the network could do by itself.

Normally when a system operator construct a network, they go through following steps.

i) Network Planning

ii) Bring the hardware (e.g, eNB) to the locations determined at Network Planning Process

iii) Hardware installation

iv) basic configuation

v) Otimizing parameters

Ideal goal of SON is to automate large portions of step i) and all of step iv), v) meaning that the installed system do all of iv), v) by itself.

In more formal way, SON framework can be illustrated as follows.(This illustration is from from nomor research - Self-Organizing Networks (SON) in 3GPP Long Term Evolution )

The framework has three stages, from top to bottom. Self-configuration runs in the pre-operational state and covers Basic Setup and Initial Radio Configuration. Basic Setup includes the IP address, the association with a gateway, authentication and the software download. Self-optimization and self-healing run in the operational state. Self-optimization tunes the neighbor list and the coverage and capacity, and self-healing detects and handles failures.

36.300 clause 22.1 uses the same split. The pre-operational state lasts from the moment the eNB is powered up and has backbone connectivity until the RF transmitter is switched on. In the operational state, the RF interface is also switched on. Self-configuration belongs to the first state, and self-optimisation uses UE, eNB and performance measurements in the second. Clause 22.1 names only these two processes, so self-healing in the diagram above goes beyond the 36.300 text.

But we know from experience that any Fancy idea takes very long time to be fully implemented and adopted by everybody and sometimes the idea would disappear even before it is realized. SON itself is at its very early stage (as of now, May 2012 at least). I would say it is at the stage of doing only a portion of step iv).  I personally don't think SON concept would disappear but it would take pretty long time to be realized at the level of Plug-and-Play of our PC component.

Clause 22.2 of 36.300 also puts a requirement on the UE. The UE shall support the measurements and procedures that the network uses for self-configuration and self-optimisation. As far as possible, these are the same measurements the UE already reports for normal operation.

• Self-configuration happens before the RF transmitter is on : it gives the new eNB its basic setup and its initial radio configuration.
• Self-optimisation happens during service : it tunes parameters from UE, eNB and performance measurements.
• The UE is part of SON : its measurement reports are the main input to most self-optimisation functions.

Why do we need SON ?

A new idea needs a reason, and SON has three. All three come from the cost of configuring and tuning a network by hand, and each cost grows as networks grow.

You may have a question "Why we need this kind of idea ?", "Why we want to achieve this ?"

Typical answers that I can think of is

• i) Generally as the data rate of a technology gets higher, the cell coverage (range) gets smaller. It means we need to deploy more eNBs. and especially in LTE, we would see a lot of pico cells and femoto cells even inside of our house (If you take presentation or workshop for femto cell, you would hear a lot of about SON). So it would be practically impossible or highly costly to send specialized engineer to install and configure all of those hardware.  If we can make the hardware configure itself, we can have less skilled person just setup the hardware at any location and power on, or we can just deliver the hardware (e.g, femtocell) to a home and let them just plug in the power.
• ii) Normally as new (advanced) technology introduced, number of configuration parameters gets exponentially increased, so manual tuning of all those parameters whould gets more and more difficult as we have new technology.
• iii) Now we have all the different technologies (CDMA, GSM, WCDMA, LTE) are running simulteneously and in many cases these technologies interact each other. This makes the mannual optimization almost inpractical.

The first reason became stronger with small cells. A home eNB is installed by the subscriber, so no engineer plans its PCI or its neighbor list on site. The second and third reasons explain why most of the use cases that 3GPP chose are about mobility parameters. Handover and reselection parameters are numerous, they interact across RATs, and they change whenever a neighbor cell changes.

• Cell density drives SON : more and smaller cells mean more sites to configure without an engineer on site.
• Parameter count drives SON : every new feature adds parameters that someone has to tune.
• Multi-RAT operation drives SON : LTE parameters interact with the parameters of the legacy networks around it.

Major Goals for SON

Before looking at individual functions, we need the objective that they all serve. TR 36.902 states it in terms of coverage and capacity, and it ranks the two.

Major Goals for SON is to achieve meeting the following two use cases. (This is defined in 3GPP TR 36.902)

• Providing optimal coverage : User should be able to get access to a network any time/ anywhere if they want. Once a UE get connected to a network, it should be able to maintain the connection as long as they want and the quality of service should be at least default quality.
• Providing optimal capacity : A network should be able to support as many subscribers as possible with enough service quality.

For now (as of ETSI TR 136 902 V9.3.1 (2011-05)), Achieving 'Optimal Converage' is at higher priority than achieving 'Optimal Capacity'.

To be precise, TR 36.902 lists these two objectives under its first use case, coverage and capacity optimization, in clause 4.1.1. The coverage objective asks for continuous coverage, so that users are unaware of cell borders. It applies in both idle and active mode, and in both UL and DL. The capacity objective has to be traded against coverage, because the two are linked. TR 36.902 also notes that this use case is not completed in Release 9.

• Coverage comes first : in Release 9, coverage optimization has higher priority than capacity optimization.
• Coverage means continuous service : users should not notice cell borders, in idle or active mode.
• Capacity is a trade-off : a coverage algorithm must take its impact on capacity into account.

Use Cases for SON

TR 36.902 describes each use case as an objective and an expected outcome. The list below is the full set from Release 9, so it is a good map of what SON was meant to cover.

Following is the list of Use Case described in ETSI TR 136 902 V9.3.1 (2011-05). Each of these items is huge item. Basically 3GPP describes 'what is to be achieved' but does not describe 'how they can be described'. Most of the items are up to network operator and hardware manufacturers. (I will keep updating details as find time)

Three of these use cases were not completed in Release 9: coverage and capacity optimization, interference reduction, and inter-cell interference coordination. For the others, TR 36.902 mostly points to 36.300 for the solution. For example, the energy savings use case switches off a capacity booster cell when its capacity is not needed. The ANR use case lets an eNB build and maintain its own neighbour relations.

• TR 36.902 defines the use cases : it states objectives, and most solutions are in 36.300.
• The algorithms are not standardized : 3GPP defines the measurements and the interfaces, and the vendor writes the algorithm.
• Some use cases stayed open : three of the nine use cases were not completed in Release 9.

Where did the SON use cases end up in the LTE specification ?

TR 36.902 is a Release 9 study, and its last version is v9.3.1. So where do we look for the current SON functions in LTE ? The answer is clause 22 of 36.300, which is updated in every release. The table below maps each function to its clause in 36.300 v19.2.0.

The table shows that the standardized part of SON is mostly signalling. ANR is a good example. The UE reports a neighbour cell with its PCI only. The eNB then asks the UE to read the ECGI, the TAC and the PLMN IDs of that cell. With the ECGI, the eNB adds a Neighbour Cell Relation to its Neighbour Cell Relation Table and, if needed, sets up X2 toward the new eNB. Each relation carries three attributes, set by O&M or to default values: No Remove, No HO and No X2.

PCI selection shows the centralized and distributed options in one clause. In the centralized case, the OAM signals one PCI value and the eNB uses it. In the distributed case, the OAM signals a list. The eNB may then remove the PCIs that UEs report, that neighbouring eNBs report over X2, or that it hears over the air.

Later releases extended the same functions rather than adding new use cases. Load reporting now covers inter-RAT, EN-DC and inter-system scenarios. RACH optimisation also covers NR cells in EN-DC, and energy saving covers EN-DC and NR cells. The RLF report feeds both coverage optimisation and mobility robustness optimisation. Except for NB-IoT, the UE keeps it until the network fetches it, or for 48 hours.

• 36.300 clause 22 is the current reference : TR 36.902 stopped at Release 9.
• ANR and PCI selection are self-configuration : they are in 36.300 clause 22.3.
• MLB, MRO, RACH and energy saving are self-optimisation : they are in 36.300 clause 22.4.
• The UE supplies the data : measurement reports, the RACH report and the RLF report are all inputs to SON.

Reference

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

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

Further Readings

The two articles below are recommended reading outside the 3GPP documents. Both are from the early years of LTE, so check any detail in them against 36.300 clause 22, which follows each release.

• For further details of SON, I strongly recommend to see this presentation : LTE/LTE-A SON for Femtocells 
• Another articles I want to recomment is Further Enhancements of LTE

Presentations on YouTube

The two parts of the presentation below cover self-organizing techniques for heterogeneous networks, where macro cells and small cells share the same area. That is the deployment in which SON matters most.

• A Unified View on Self-Organizing Techniques for Heterogeneous Networks [Part I]
• A Unified View on Self-Organizing Techniques for Heterogeneous Networks [Part II]