5 Business level requirements

32.5213GPPRelease 11RequirementsSelf-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP)Telecommunication managementTS

5.1 Requirements

5.1.1 Self-Optimization Monitoring and Management

REQ-SO_MM-CON-1 IRPManager shall be able to control the self-optimization functions.

REQ-SO_MM-CON-2 The self-optimization complex corrective actions shall be executed in a consistent and coordinated way.

REQ-SO_MM-CON-3 Self-optimization functions shall reuse existing standardized solutions as much as possible.

REQ-SO_MM-CON-4 void

REQ-SO_MM-CON-5 The IRPAgent shall support a capability allowing the IRPManager to know the success or failure result of Self-Optimization.

REQ-SO_MM-CON-6 The trigger conditions of self-optimization functions should be able to be managed by the IRPManager. The trigger condition may be the scheduled time to start a self-optimization function or a period of time during which a self-optimization function is forbidden to be started or the event (i.e. do not meet objectives or targets) to start a self-optimization function. Each self-optimization function shall have its own set of trigger condition.

REQ-SO_MM-CON-7 For the self-optimization functions which need continuous monitoring, the IRPManager should be able to manage the execution of self-optimization actions (e.g. setting a period of time during which a self-optimization action is forbidden to be executed).

REQ-SO_MM-CON-8 Each self-optimization function shall have one or several related performance indicator, which may be used as objective to evaluate the performance before the self-optimization is initiated and after the self-optimization function is completed.

REQ-SO_MM-CON-9 For operator controlled (open loop) SON function, the IRPAgent shall support a capability allowing IRPManager to know the information about the self-optimization actions. The necessity of this capability will be decided case by case.

REQ-SO_MM-CON-10 The IRPAgent shall support a capability allowing IRPManager to know the information about the execution result of self-optimization actions.

REQ-SO_MM-CON-11 void.

REQ-SO_MM-CON-12 void. REQ-SO_MM-CON-13 void.

5.1.2 Load Balancing

REQ-SO_LB-CON-1 The optimization of load balancing shall be performed with minimal human intervention.

REQ-SO_LB-CON-2 The following scenarios shall be considered in optimization of load balancing. Each scenario shall include the load balancing on intra-frequency, inter-frequency, and inter-RAT.

1. Overlapping Coverage

2. Hierarchical Coverage

3. Neighbouring Coverage

5.1.3 Handover (HO) Parameter optimization

REQ-SO_HO-CON-1 HO parameter optimization shall be performed with no human intervention as much as possible.

REQ-SO_HO-CON-2 HO parameter optimization function shall aim at reducing the number of HO failures as well as reducing inefficient use of network resources due to unnecessary handovers. In particular, the HO parameter optimization function shall aim at reducing the number of HO related failures that cause degradation in user experience, such as call drops, radio link failures during or shortly after HO, and reduced data rates.

5.1.4 Interference control

REQ-SO_IC-CON-1 Interference control shall be performed with as little human intervention as possible.

REQ-SO_IC-CON-2 The following scenarios shall be considered in interference control.

1. Uplink inter cell interference coordination

2. Downlink inter cell interference coordination

5.1.5 Capacity and coverage optimization

REQ-SO_CC-CON-1 Coverage and capacity optimization shall be performed with minimal human intervention.

REQ-SO_CC-CON-2 Operator shall be able to configure the objectives and targets for the coverage and capacity optimisation function.

REQ-SO_CC-CON-3 Operator shall be able to configure the objectives and targets for the coverage and capacity optimisation functions differently for different areas of the network.

REQ-SO_CC-CON-4 The collection of data used as input into the coverage and capacity optimisation function shall be automated to the maximum extent possible and shall require minimum possible amount of dedicated resources.

REQ-SO_CC-CON-5 The following scenarios shall be considered in capacity and coverage optimization.

1. E-UTRAN Coverage holes with 2G/3G coverage

2. E-UTRAN Coverage holes without any other radio coverage

3. E-UTRAN Coverage holes with isolated island cell coverage

4. E-UTRAN cells with too large coverage

REQ-SO_CC-CON-6 The IRPAgent shall provide a capability allowing the IRPManager to manage tradeoffs between coverage and capacity using policies.

5.1.6 RACH optimization

REQ-SO_RO-CON-1 RACH optimization shall be performed with minimal human intervention.

5.1.7 SON Coordination

REQ-SON_COORD-CON-1 SON coordination shall allow the prevention and resolution of conflicts between SON functions.

REQ-SON_COORD-CON-2 In case the SON coordination function is below Itf-N, the IRPAgent should support the capability for the IRPManager to define policies for the case that SON functions request conflicting parameter values. In case no policy is given, the IRPAgent shall apply default policies.

Note: A policy describes an expected behaviour from the IRPAgent. Examples for such policies:

i) Prioritizing SON functions in case of conflicts

ii) Assigning weights to SON targets

iii) Prohibiting further changes of a parameter for a certain amount of time

iv) Selecting preferred value ranges

v) Telling the IRPAgent to report conflicts

REQ-SON_COORD-CON-3 For the case that the IRPAgent does not resolve the case of SON functions requesting conflicting values for parameters, the IRPAgent should support the capability for the IRPManager to decide about the parameter values.

REQ-SON_COORD-CON-4 The IRPAgent shall support a capability allowing the IRPManager to configure the SON coordination policy. The coordination includes the following aspects:

1) Coordination between SON functions below Itf-N and CM operations over Itf-N.

2) Coordination between different SON functions.

5.2 Actor roles

Managed system: The entity performing an IRPAgent role.

Managing system: The entity performing the IRPManager role.

5.3 Telecommunications Resources

The managed E-UTRAN/EPC network equipments are viewed as relevant telecommunications resources in this specification.

5.4 High-Level use case

5.4.1 Load Balancing

1. Overlapping Coverage

In this scenario, two same size cells overlap each other. Cell A and cell B both cover the same area. The load balancing between cell A and Cell B may be considered. The load balancing could be carried out between Cell A and Cell B regardless of the UE location within the coverage of the cells.

Cell A

Cell B

LB Area

Figure 5.4.1-1: Overlapping Coverage

Hierarchical Coverage

In this scenario, two different size cells overlap each other. Cell B that has a smaller area is covered totally by cell A, which has a bigger size. The load balancing between cell A and Cell B may be considered. The load balancing could be carried out from Cell B to Cell A regardless of the UE location within the coverage of the cell B. Only UE located in the overlapping coverage could be considered in the scenario of Cell A to Cell B.

Cell B

Cell A

LB Area

Figure 5.4.1-2: Hierarchical Coverage

Neighbouring Coverage

In this scenario, there are some overlapped area between two neighbour cell A and cell B. This is the usual neighbour cells scenario in EUTRAN. The load balancing between cell A and Cell B may be considered. Load Balancing could only be carried out for UE located in the overlapping coverage of Cell A and Cell B.

Cell A

Cell B

LB Area

Figure 5.4.1-3: Neighbouring Coverage

5.4.2 Interference control

1. Uplink inter cell interference coordination

In this scenario, cell-edge UEs like UE A and B belong to different cell, and they are assigned the same physical resource block (PRB). When they transmit uplink messages, e.g. UE A sends message to its serving cell A, its neighbour cell B may also receives it; UE B has a similar situation. Therefore, cell A cannot judge which is signal-comes from UE A, and which is interference-comes from UE B, so as cell B. In this situation, inter cell interference coordination is essential to compensate for the system performance loss and increase cell edge users’ bit rate.

Figure 5.4.2-1: Uplink Inter Cell Interference Coordination

2. Downlink inter cell interference coordination

In this scenario, when UE located in cell-edge area, it is much adapted to suffer downlink interference from its neighbour cell in case that there is another UE occupying the same PRB in the same region belonging to its neighbour cell. So downlink inter cell interference coordination is essential to restrain interference and increase system capacity.

Figure 5.4.2-2: Downlink inter cell interference coordination

5.4.3 Capacity and coverage optimization

Although, it is of primary interest to provide coverage to users during a roll-out, it is equally important to enhance the capacity of the network during operation. As such, both coverage and capacity are considered in the use case and supported by the SON function. The CCO SON function should be configured through appropriate objectives and targets in order to meet the operator’s requirement on coverage and capacity, and the prioritization between them.

1. E-UTRAN Coverage holes with 2G/3G coverage

In this scenario, legacy systems, e.g. 2G/3G provide radio coverage together with E-UTRAN. However, in the first deployment stage of E-UTRAN, unsuitable planning or error parameters settings will lead to coverage holes in some area. In this scenario, there may be too many IRAT HOs. The SON use case coverage and capacity optimization should enable to detect this kind of problems on network coverage automatically. Another case similar with this is that coverage problems exist between different frequencies in E-UTRAN, i.e. inter-frequency case. For simple reasons, this case is also described here.

Specific Freq

Coverage of LTE

Coverage holes

Figure 5.4.3-1: Coverage holes with 2G/3G coverage

2. E-UTRAN Coverage holes without any other radio coverage

In this scenario, there is no 2G/3G coverage except E-UTRAN. In the first deployment stage of E-UTRAN, unsuitable planning or error parameters settings will lead to un-continuous coverage in some area. That will lead to many drop calls because of bad coverage. The SON use case coverage and capacity optimization should enable to detect this kind of problems on network coverage automatically.

Radio Coverage of E-UTRAN

Coverage holes

Figure 5.4.3-2: Coverage holes without any other radio coverage

3. E-UTRAN Coverage holes with isolated island cell coverage

In this scenario, the actual coverage area of an isolated island cell is smaller than the planned isolated island cell area. The uncovered planned cell area is the coverage holes that need to be detected and optimized by the coverage and capacity optimization.

Actual Isolated Island Cell

of E-UTRAN

Coverage holes

Planned Isolated Island Cell of E-UTRAN

Coverage holes

Figure 5.4.3-3: Coverage holes with isolated island cell coverage

4. E-UTRAN cells with too large coverage

In this scenario, the operator does a gradual network evolution using LTE cells in location where higher capacity is needed. Here the actual LTE coverage is greater than the planned LTE coverage. The overflow area is shown in figure 5.4.3.4. The problem with a too large coverage is that the planned capacity may not be reached. As such, it is important to keep the coverage within the planned area.

Actual LTE coverage

Overflow area

Overflow area

Planned LTE coverage

Figure 5.4.3-4: Difference between actual and planned LTE coverage