32.5223GPPInformation Service (IS)Release 11Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP)Telecommunication managementTS

4.1 Monitoring and Management Operations for Self-Optimization

4.1.1 Monitoring and Management Function

4.1.1.1 Usage of Itf-N

For specifically defined Itf-N NRM Interface see clause 5.

4.2 Load Balancing Optimization Function

4.2.1 Objective and Targets

The objective of LB Optimization is to cope with undesired traffic load distribution and to minimize the number of handovers and redirections needed to achieve the load balancing. One of the following targets or the combination of the following targets shall be used. The specific target value or values shall be configured by operators. Operators should assign weights for targets being used.

Targets drawn from the following table can be configured for LBO:

For the following targets out of the above table, the target values depend on the composite available capacity range in the cell and are defined separately for uplink and downlink. For these tuples can be configured, indicating the capacity ranges together with the target value valid in that range.

RRC connection establishments failure rate related to load,

E-RAB setup failure rate related to load,

RRC Connection Abnormal Release Rate Related to Load,

E-RAB Abnormal Release Rate Related to Load

For the following targets shall be identical with the corresponding targets defined in Handover Optimization.

Rate of failures related to handover

4.2.2 Parameters To Be Optimized

To reach load optimization target, LBO may optimize some mobility settings (HO and/or idle mobility configuration) defined in TS 36.331 [6].

4.2.3 Optimization Method

4.2.3.1 Problem Detection

The problem detection is out of scope of this specification.

4.2.3.2 Problem Solution 

The problem solution is out of scope of this specification.

4.2.4 Architecture

4.2.4.1 Definition of Logical Functions

LB Monitor Function: This function is used for monitoring the load balance optimization (e.g. Monitoring related performance counters or alarms).

LB Policy control function: This function is used for configuring the load balance optimization policies.

4.2.4.2 Location of Logical Functions

NM (IRPManager)

DM

eNB

Itf-N

eNB

EM

LB Monitor Function

LB Policy Control Function

X2

eNB

LB Monitor Function

LB Policy Control Function

X2

EM

For Load Balancing, the SON LB decision algorithm is located in eNB. The detailed SON functionalities in eNB are out of scope of this specification.

4.2.5 PM

IRPManager may collect Load balancing related performance measurements. Performance Measurements related with Load balancing are captured in the table below:

NOTE: The monitoring of performance measurements will make use of existing PM IRP.

4.3 Handover (HO) Parameter Optimization Function

4.3.1 Objective and Targets

For intra-LTE, one of the following targets or the combination of the following targets shall be used. The specific target value shall be configured by operators. Operators should assign weights for targets being used.

The objective of minimizing the number of unnecessary handovers shall always be pursued in case the other target/s configured by the operator is/are achieved. This objective may not need configuration of a target value.

4.3.2 Parameters To Be Optimized

The tables below summarise the handover parameters in TS 36.331 [6].

Table 4.3.2-1. Handover parameters that may be optimized for intra-frequency and inter-frequency handovers

Table 4.3.2-2. Handover parameters that may be optimised for inter RAT handover

4.3.3 Optimization Method

4.3.3.1 Problem Detection

HO Parameter Optimization Function shall focus on detecting the problem scenarios described in TS 32.521 [5]; namely: too early handovers, too late handovers and inefficient use of NW resources due to HOs. For more information about these scenarios see TS 32.521 [5] section 6.1.3.

The following inputs may be used for the identification of the problem scenarios:

– Event capture and analysis

– UE measurements

– Performance measurements

In event capture and analysis, the eNodeB exploits event information associated with a UE context, such as evidence of previous handovers (UE History, see TS 36.423 [7]) and HO failure details (such as in which cell the handover failed and where the UE re-established the connection).

UE measurements are sent within UE measurement reports and they may indicate whether HOs are too early or too late.

HO-related performance measurements (PMs) collected at the source and / or target eNB can be useful in detecting HO-related issues on the cell level. Since the impact of incorrect HO parameter setting will also be on the cell-level, PMs can provide useful information that can be used to detect and resolve HO-related issues due to incorrect parameter settings.

4.3.3.2 Problem Solution 

HO Parameter Optimization Function will aim at optimizing the HO parameters listed in Section 4.3.2 in such way to mitigate the problem scenarios discussed in Section 4.3.3.1. The optimization algorithms will not be specified. The exact set of HO parameters that may be adjusted by the algorithms is dictated by the choice of triggered HO measurements made by the RRM entity in an eNodeB.

4.3.4 Architecture

4.3.4.1 Definition of Logical Functions

HO Parameter Optimization Monitor Function: This function is used for monitoring the handover parameter optimization (e.g. monitoring related performance counters or alarms).

HO Parameter Optimization Policy Control Function: This function is used for configuring the handover parameter optimization policies.

4.3.4.2 Location of Logical Functions

For HandOver (HO) parameter optimization there are several options for the location of the SON algorithm:

1. The SON algorithm is located in the eNB(s).
2. The SON algorithm is located in the EM, the parameter changes are executed in the eNBs.

An example for the first option is shown in figure 4.3.4.2:

NM

DM

eNB

Itf-N

EM

HO Parameter Optimization Monitor Function

HO Parameter Optimization Policy Control Function

X2

HO Parameter Optimization Monitor Function

HO Parameter Optimization Policy Control Function

X2

eNB

eNB

EM

Figure 4.3.4.2: Example when the SON algorithm is located in the eNB(s)

The detailed SON functionalities in eNB are out of scope of this specification.

4.3.5 PM

IRPManager shall collect HO-related performance measurements from the source and / or target eNB which can be useful in detecting HO-related issues on the cell level. The following input can be used for the identification of the problem scenarios specified:

The number of RLF event happened within an interval after handover success.

The number of unnecessary handovers to another RAT without RLF.

Performance Measurements related to handover failure are captured in the table below.

The Performance Measurements are for outgoing handovers. Further, they should be available on a cell relation basis.

NOTE: The monitoring of performance measurements will make use of existing PM IRP.

4.4 Interference Control Function

4.5 Capacity and Coverage Optimization Function

4.5.1 Objective and Targets

The objective of capacity and coverage optimization is to provide optimal coverage and capacity for the radio network. A tradeoff between capacity and coverage needs to be considered.

The detailed target(s) FFS.

4.5.2 Parameters to be optimized

To reach capacity and coverage optimization targets, the following parameters may be optimized:

• Downlink transmit power
• Antenna tilt
• Antenna azimuth

4.5.3 Optimization Method

4.5.3.1 Problem Detection

The main symptoms of capacity and coverage optimization problems (see TS 37.320 [15]) are:

Coverage hole: A coverage hole is an area where the pilot signal strength is below a threshold which is required by a UE to access the network, or the SINRs of both serving and neighbor cells is below a level needed to maintain the basic service. Coverage holes are usually caused by physical obstructions such as new buildings, hills, or by unsuitable antenna parameters, or just inadequate RF planning. UE in coverage hole will suffer from call drop and radio link failure. Typical phenomenon of coverage hole is either HO failure happens frequently and cannot be optimized by HO parameter optimization or call drop happens frequently and cannot be rescued by RRC re-establishment.

Weak coverage: Weak coverage occurs when the pilot signal strength or the SNR (or SINR) of serving cell is below the level needed to maintain a planned performance requirement (e.g. cell edge bit-rate).

Pilot pollution: In areas where coverage of different cells overlap a lot, interference levels are high, power levels are high, energy consumption is high and cell performance may be low. Typically in this situation UEs may experience high SNR to more than one cell and high interference levels.

Overshoot coverage: Overshoot occurs when coverage of a cell reaches far beyond what is planned. It can occur as an “island” of coverage in the interior of another cell, which may not be a direct neighbor. Reasons for overshoot may be reflections in buildings or across open water, lakes etc. UEs in this area may suffer call drops or high interference.

DL and UL channel coverage mismatch: DL channel coverage is larger than UL channel coverage is one typical scenario of DL and UL channel coverage mismatch. The UE will suffer UL problems when it moves into the mismatch area.

In a realistic network, these symptoms may be tolerated to a certain level. These symptoms may indicate a real problem when combined with other factors such as frequency of symptoms, duration of symptoms, or affected population.

The following inputs may be used for the identification of the problem scenarios:

• UE measurements
• Performance measurements
• Alarms, other monitoring information e.g. trace data

UE measurements are sent within UE measurement reports and they may indicate the capacity and coverage problem.

Capacity and coverage related performance measurements collected at the source and / or target eNB can be useful in detecting capacity and coverage related issues on the cell level. Minimizing Driver Test (MDT) or HO-related performance measurements may be used also in detecting capacity and coverage related issues on the cell level.

Alarms, other monitoring information e.g. trace data can be correlated to get an unambiguous indication of capacity and coverage problem.

4.5.3.2 Problem Solution

Capacity and coverage optimization function will aim at optimizing the parameters listed in Section 4.5.2 in such way to mitigate the problem scenarios discussed in Section 4.5.3.1.

4.5.4 Architecture

4.5.4.1 Definition of Logical Functions

CCO Monitor Function: This function is used for monitoring the capacity and coverage optimization (e.g. monitoring related performance counters, UE measurements or alarms).

CCO Policy Control Function: This function is used for configuring the capacity and coverage optimization policies.

4.5.4.2 Location of Logical Functions

For capacity and coverage optimization (CCO), there are several options for the location of the centralized CCO SON algorithm:

1. The CCO SON algorithm is located in the DM. The capacity and coverage optimization decision is made by the DM centralized CCO algorithm.
2. The CCO SON algorithm is located in the NM. The capacity and coverage optimization decision is made by the NM centralized CCO algorithm.

An example for the first option is shown in figure 4.5.4.2:

DM

NM

eNB

Itf-N

EM

CCO Monitor Function

CCO Policy Control Function

X2

CCO Monitor Function

CCO Policy Control Function

X2

eNB

eNB

EM

Figure 4.5.4.2: Example when the CCO SON algorithm is located in DM

The detailed CCO SON algorithm in OAM (NM centralized or EM centralized) is out of scope of this specification.

4.5.5 PM

The IRPAgent shall support a capability allowing the IRPManager to collect CCO related performance measurements to know the situation of coverage or interference which may then trigger corresponding optimization procedures. Performance measurements related with CCO are captured in the table below:

4.6 RACH Optimization Function

4.6.1 Objective and Targets

The objective of RACH Optimization is to automatically set several parameters related to the performance of RACH. One of the following targets shall be used. The specific target value shall be configured by operators.

4.6.2 Parameters to be optimized

To achieve RACH optimization target, RACH optimization function may optimize several parameters defined in TS 36.300 [14] section 22.4.3.

4.6.3 Optimization Method

4.6.3.1 Problem Detection

The problem detection is out of scope of this specification since the RACH optimization entity resides in the eNB.

4.6.3.2 Problem Solution

The problem solution is out of scope of this specification since the RACH optimization entity resides in the eNB.

4.6.4 PM

The IRPAgent shall support a capability allowing the IRPManager to collect RACH optimization related performance measurements. Performance measurements related with RACH optimization are captured in the table below:

4.7 SON coordination

4.7.1 Introduction

There may be conflicts or dependencies between SON functions; SON coordination means preventing or resolving conflicts or negative influences between SON functions to make SON functions comply with operator’s policy.

As the example shown in figure 4.7.1.1, there is mesh relationship between SON functions and network parameters (or network elements) in which conflicts or negative influences may happen if no SON coordination.

Figure 4.7.1.1: Mesh relationship between SON functions and network parameters (or network elements)

4.7.2 Coordination between SON functions below Itf-N and non-SON CM operations over itf-N

4.7.2.1 Description

Conflict may arise between non-SON CM operation via Itf-N and the SON functions (in particularly self-optimization function) below Itf-N in the following scenario.

The network parameters can be changed by the non-SON CM operations via Itf-N,meanwhile, the SON functions below Itf-N may also require changing the parameters. If these parameters are some (same or associated) parameters of some (same or associated) nodes which will be changed by the non-SON CM operations and the SON functions below Itf-N, conflict arises. (Conflict see clause 4 of 32.521[5])

For example, the non-SON CM operation via Itf-N may try to reduce the CIO (cell individual offset) parameter, it makes the HO trigger between cells (e.g., HO from cell A to cell B) become more difficult. But in the meanwhile, the SON function MRO may try to increase the CIO parameter, it makes the HO easier. In this case, if the conflict is not coordinated, the parameter may be modified twice. Then the failed rate related with handover may rise or ping-pong handover may arise between the two cells.

In case the SON function below Itf-N and non-SON CM operation via Itf-N has conflict, the SON function below Itf-N shall take into account and re-evaluate, if applicable, any non-SON CM operation changes via Itf-N.

As showing in the following example, At Time T3, after Non-SON operation has finished the modification, SON function below Itf-N shall take the non-SON CM operation changes into account for further SON analysis.

4.7.2.2 Prevention

In a real network, it is possible that non-SON CM operations via Itf-N and several SON functions below Itf-N are running at the same time, and they may try to change the same or associated parameters during a short time period. So coordination is needed to prevent this kind of conflicts.

4.7.2.3 Resolution

Refer to common coordination solutions part.

4.7.3 Coordination between different SON functions

Note: The coordination between different SON functions should be decided case by case.

4.7.3.1 Coordination between Cell Outage Compensation and Energy Saving Management

4.7.3.1.1 Description

A conflict could arise between energy saving and cell outage compensation in the following scenario.

One or more candidate cells are configured to possibly take coverage of the original cell. The original cell is in energySaving state or is about to enter energySaving state. One or more candidate cells go into outage with the consequence that coverage of the original cell can not be provided any more.

4.7.3.1.2 Prevention

Prevention is hardly possible, except making the cells as outage proof as possible. But cell outages can happen even to the most stable cell in a network.

4.7.3.1.3 Resolution

If the original cell is in energySaving state, it shall leave energySaving state.

If the original cell is about to enter energySaving state, it shall not go into energySaving state until candidate cell outage is recovered and candidate cell is able to provide the coverage.

The original cell may go into the energySaving state after the candidate cell outage is recovered and coverage of the original cell can be taken over by candidate cell again.

4.7.3.2 Coordination among Cell Outage Compensation, Capacity and Coverage Optimization, and Energy Saving Management

4.7.3.2.1 Description

Capacity and Coverage Optimization (CCO), Cell Outage Compensation (COC) and Energy Saving Management (ESM) may require changes to the coverage and/or capacity of one or more cells during the same time period, which could lead to the following issue:

Cell2

Cell1

Cell3

Cell4

Figure 4.7.3.2 Coordination among COC, CCO, and ESM

Figure 4.7.3.2 is a typical scenario for the coordination among COC, CCO and ESM.

Cell 1 is detected in outage, COC will try to compensate the outage Cell 1 by reconfiguring the RF configuration of some compensation candidate cells, e.g., TX power, antenna tilt and antenna azimuth of Cell 2 and Cell 3.

Before the outage Cell 1 is compensated, CCO may detect the degrading of coverage related KPI (e.g., success rate of RRC connection establishments, cell throughput) of Cell 1 and its neighbour cells (Cell 2 and other blue cells) and make a conclusion that there is a coverage problem in this KPI degraded area.

Meanwhile, ESM is operating on Cell 2 to compensate the coverage of its neighboring cell (Cell 4) which is going into energySaving state.

From the time point at which the outage Cell 1 is detected until Cell 1 has been compensated by Cell 2 and Cell 3, during this period, if there is no coordination among COC, CCO and ESM, there will be possibly different settings for adjusting TX power, antenna tilt and antenna azimuth of Cell 2 for COC, CCO or ESM purposes respectively. It’s most likely that the adjustment from COC, ESM and optimization from CCO may conflict in the common affected outage compensation candidate cell(s) (Cell 2 in the above example).

It is also possible that ESM is operating on Cell 2 to compensate the coverage of Cell 4 that is in energySaving state, while COC detects that Cell 1 has outage, and requests Cell 2 to compensate the coverage of Cell 1. COC and ESM need to be coordinated to determine if this request can be accepted.

After the outage cell comes back to normal, the COC exits the coordination scenario, while CCO and ESM continute to work and need to be well coordinated. For example, CCO may adjust the antenna tilt of Cell 2 in a downward direction to improve the coverage signal quality, but ESM may adjust the antenna tilt of Cell 2 in an opposite direction to enlarge its coverage area for purpose of ES compensation. Therefore, coordination should be continued between CCO and ESM to resolve the possible configuration conflict on Cell 2.

Other conflict scenarios could be:

Cell A is compensating to provide coverage for Cell B that is in energySaving state. COC detects that Cell A has outage. Since Cell A is not able to provide the coverage for Cell B any more, Cell B needs to be covered by another cell, or to deactivate energy saving.

Cell A is in energySaving state. COC detects Cell B has outage, and requests Cell A to compensate the coverage of Cell B. Cell A may need to terminate energy saving in order to compensate the coverage of Cell B.

Cell A which is compensating Cell B in outage shall not go into energySaving state as long as its compensation for Cell B is needed.

4.7.3.2.2 Prevention

Prevention is hardly possible.

4.7.3.2.3 Resolution

Refer to clause 4.7.4 General SON coordination solutions.

4.7.3.3 Coordination between Cell Outage Compensation and Automatic Neighbour Relation

4.7.3.3.1 Description

In case one cell is detected in outage, COC will try to compensate the outage cell by reconfiguring the RF configuration of some compensation candidate cells. As a result of this, there will be new NRs (neighbour relations) which reflect the new topology relations.

For a stable network, ANR could be deactivated for the purpose of system resource saving. If ANR is deactivated, the new NRs cannot be captured in NRT by ANR. Network performance, for example, handover will be impacted negatively by the NRT which lacks of the new NRs.

4.7.3.3.2 Prevention

Prevention is hardly possible, except making the cells as outage proof as possible. But cell outages can happen even to the most stable cell in a network.

4.7.3.3.3 Resolution

The ANR function should monitor if a cell outage or cell outage compensation takes place within its area. If this happens, then the ANR function should check the NRs of the affected cells (for example the outage cell and its neighbours and neighbours’ neighbours). In case the ANR function in the the affected area is deactivated, the possible NRs change of the affected cells should be taken as a factor to reactivate the ANR function.

4.7.3.4 Coordination between HandOver parameter Optimization and Load Balancing Optimization

4.7.3.4.1 Description

HOO function and LBO function both optimize network performance by adjusting handover parameters such as CIO, Hysteresis, TTT, etc. Conflicts may happen when HOO function and LBO function are changing the same or associated handover parameters in opposite direction or towards the same direction but on different scales.

For example, HOO function may adjust handover parameters (e.g. decrease CIO of source cell A to target cell B) to minimize the number of too early handovers from cell A to cell B whilst LBO function may adjust handover parameters (e.g. increase the CIO of source cell A to target cell B) to make the handover from cell A to cell B more easier in case the load of cell B is much less than cell A.

4.7.3.4.2 Prevention

Prevention is hardly possible unless switch off HOO function or LBO function. However, disabling the complete HOO function or LBO function cannot fulfil the requirement that both handover performance and load performance need to be improved at the same time.

4.7.3.4.3 Resolution

For the coordination between HOO and LBO, IRPManager should assign priorities for HOO function and LBO function or weights for targets of HOO function and LBO function according to operator’s policy.

The policy should cover different scenarios well:

• Policy may assign higher priority for HOO function than LBO function or higher weight for target of HOO function than targets of LBO function when resolving MRO issues (HO too early/too late/to wrong cell) is the main objective of network optimization, e.g. in handover optimization scenario for better coverage.
• Policy may assign lower priority for HOO function than LBO function or lower weight for target of HOO function than targets of LBO function when enhancing load performance is the main objective of network optimization, e.g. in load optimization scenario for better capacity.

Concrete way of using priority or weights of targets, refers to clause 4.7.4 General SON coordination solutions.

4.7.4 General SON coordination solutions

4.7.4.1 Overview

As described in TS 32.521 [5], multiple SON functions may have conflicting demands on network resources. This situation is considered as “SON functions in conflict” and requires conflict prevention or resolution. A SON Coordination Function will be responsible for preventing or resolving conflicts.

Conflict needs to be detected when there is “SON functions in conflict”. Policies can be preset by operator to SON Coordination Function to avoid conflict on certain associated resources (network elements and/or parameters) among SON functions.

Conflict prevention is to take some advanced methods to prevent the occurrence of conflict. However, no matter what implementation is chosen, it is impossible to guarantee that 100% of conflicts will be prevented, so conflict detection and resolution are needed. Conflict detection should be taken firstly as the pre-condition of conflict resolution.

The SON Coordination Function is a logical function, which means it can be implemented as a separate function entity or as part of SON function.

When the SON Coordination Function is implemented as a separate function entity, all the SON functions send the necessary information to the SON Coordination Function, the SON Coordination Function coordinate these SON functions as a centralized control point. This centralized coordination approach fulfills the requirements of SON coordination in a large area scope, for example, the coordination between NM centralized SON functions and distributed SON functions.

In some other situations, coordination is only needed in a smaller area, for example, the coordination between distributed SON functions inside one domain. Then the SON Coordination Function can be implemented as part of each SON function. The necessary coordination information can be inter-exchanged between each SON functions to achieve coordination as well.

The SON Coordination Function may reside above or below Itf-N. Figure 4.7.4.1 shows an example of a SON Coodination Function, which is a separate function entity, above Itf-N.

NM

EM

eNB

SON_A

eNB

SON_B

eNB

SON_C

SON_Y

SON_X

SON Coordination Function

EM

Itf-N

Figure 4.7.4.1: Example of SON Coordination entity located in NM

The SON Coordination Function may be responsible for conflict prevention, conflict resolution, or both in parallel.

4.7.4.2 Conflict prevention

To prevent conflicts between the SON functions, the SON functions may ask the SON Coordination function for permission before changing some specific configuration parameters. The SON Coordination Function should check the SON coordination interdependancy policy between this requesting SON function and other SON function(s) upon receiving the permission request from the SON function. SON coordination interdependancy policy which is pre-configured can help the SON Coordination Function to find which SON function(s) possibly conflict with this requesting SON function.

As a basis for decisions, the SON Coordination Function will typically use one or some of the following inputs received from the SON function(s)

• Which SON functions are modifying configuration parameters (including information about vendor, release etc.)
• Configuration parameters intended to be changed and/or their existing and proposed new values
• The time duration how long the configuration parameter should not be interfered with (“impact time”)
• The state of SON functions
• The SON targets which are the justification for the configuration change.
• Possible impact of a parameter change on other objects (“impact area”)
• The state of certain managed objects
• Possible impact of the parameter change on Key Performance Indicators
• Priority of SON functions, which can be used to determine the execution order of requests from different SON functions in case of conflicts
• SON coordination policies

The SON Coordination Function sends the decision back to the requesting SON function; the decision may be confirmation or suspension or rejection of the SON executing request, or other actions like configuration of specific parameters with specific value.

After SON function executes action, the SON Coordination Function is then informed about the result (successful/unsuccessful, parameters changes) of the executed SON action.

The SON Coordination Function may prevent parameter changes by one or more SON functions for a specified time period after the same parameter has been changed by another SON function.

The SON Coordination Function may inform a SON Function of a managed object state change which may impact calculation of KPIs.

Detailed description of how to use general SON coordination solutions are in Annex B.

4.7.4.3 Conflict resolution

The SON Coordination Function should detect conflicts and attempt to resolve the conflicts.

To detect conflicts, the SON Coordination Function will typically analyse one or some of the following types of data

• Key Performance Indicators which indicate if SON functions are meeting their targets or improving network performance
• Measurements which indicate if SON functions are meeting their targets or improving network performance
• Unacceptable oscillations in configuration parameters

To resolve conflicts, the SON Coordination Function will typically use one or some of following methods

• Enabling/disabling/suspending certain SON functions
• Stopping/suspending/modifying certain SON actions
• Modifying certain configuration parameters