Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP): Requirements

3GPP TS 32.521 V9.0.0 (2010-03)
Technical Specification
	
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.

3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Telecommunications Management;
Self-Organizing Networks (SON) Policy Network Resource 
Model (NRM) Integration Reference Point (IRP);
Requirements
 (Release 9)



Keywords
SON, Self-Optimization, management

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2010, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.


Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc257711244 \h 5
Introduction	 PAGEREF _Toc257711245 \h 5
1	Scope	 PAGEREF _Toc257711246 \h 6
2	References	 PAGEREF _Toc257711247 \h 6
3	Definitions and abbreviations	 PAGEREF _Toc257711248 \h 6
3.1	Definitions	 PAGEREF _Toc257711249 \h 6
3.2	Abbreviations	 PAGEREF _Toc257711250 \h 6
4	Concepts and background	 PAGEREF _Toc257711251 \h 7
4.1 	Overview	 PAGEREF _Toc257711252 \h 7
4.2	Self-Optimization Concept	 PAGEREF _Toc257711253 \h 9
4.2.1	Logical Function Blocks	 PAGEREF _Toc257711254 \h 9
4.2.1.1	Self-Optimization Input Monitoring Function (SO_MON_F)	 PAGEREF _Toc257711255 \h 9
4.2.1.2	Triggering Optimization Function (TG_F)	 PAGEREF _Toc257711256 \h 9
4.2.1.3	Optimization Fallback Function (O_FB_F)	 PAGEREF _Toc257711257 \h 9
4.2.1.4	Self-Optimization Progress Update Function (SO_PGS_UF)	 PAGEREF _Toc257711258 \h 9
4.2.1.5	NRM IRP Update Function (NRM_UF)	 PAGEREF _Toc257711259 \h 9
4.2.1.6	Self-Optimization Monitoring and Management Function (SO_MMF)	 PAGEREF _Toc257711260 \h 9
4.2.1.6.1	Self-Optimization Monitoring and Management Function (SO_MMF_NM)	 PAGEREF _Toc257711261 \h 9
4.2.1.6.2	Self-Optimization Monitoring and Management Function (SO_MMF_EM)	 PAGEREF _Toc257711262 \h 9
4.2.1.7	Load Balancing Function (LB_F)	 PAGEREF _Toc257711263 \h 10
4.2.1.8	Interference Control Function (IC_F)	 PAGEREF _Toc257711264 \h 10
4.2.1.9	Coverage and Capacity Function (CC_F)	 PAGEREF _Toc257711265 \h 10
4.2.1.10	RACH Optimization Function (RACH_F)	 PAGEREF _Toc257711266 \h 10
4.2.1.11	HandOver Optimization Function (HO_F)	 PAGEREF _Toc257711267 \h 10
5	Business level requirements	 PAGEREF _Toc257711268 \h 10
5.1	Requirements	 PAGEREF _Toc257711269 \h 10
5.1.1	Self-Optimization Monitoring and management Requirements	 PAGEREF _Toc257711270 \h 10
5.1.2	Load Balancing	 PAGEREF _Toc257711271 \h 11
5.1.3 	 Handover (HO) Parameter optimization	 PAGEREF _Toc257711272 \h 11
5.1.4	 Interference control	 PAGEREF _Toc257711273 \h 11
5.1.5	 Capacity and coverage optimization	 PAGEREF _Toc257711274 \h 11
5.1.6	 RACH optimization	 PAGEREF _Toc257711275 \h 12
5.2	 Actor roles	 PAGEREF _Toc257711276 \h 12
5.3	 Telecommunications Resources	 PAGEREF _Toc257711277 \h 12
5.4	 High-Level use case	 PAGEREF _Toc257711278 \h 12
5.4.1	 Load Balancing	 PAGEREF _Toc257711279 \h 12
5.4.2	 Interference control	 PAGEREF _Toc257711280 \h 13
5.4.3	 Capacity and coverage optimization	 PAGEREF _Toc257711281 \h 14
6	 Specification level requirements	 PAGEREF _Toc257711282 \h 16
6.1	Requirements	 PAGEREF _Toc257711283 \h 16
6.1.1	Self-Optimization Monitoring and Management	 PAGEREF _Toc257711284 \h 16
6.1.1.1	Management Part	 PAGEREF _Toc257711285 \h 16
6.1.2	Load Balancing	 PAGEREF _Toc257711286 \h 17
6.1.3	Handover (HO) Parameter optimization	 PAGEREF _Toc257711287 \h 17
6.1.3.1	HO failure categorization	 PAGEREF _Toc257711288 \h 17
6.1.3.1.1	HO failures due to too late and too early HO triggering	 PAGEREF _Toc257711289 \h 17
6.1.3.2	Reducing inefficient use of network resources due to unnecessary HOs	 PAGEREF _Toc257711290 \h 18
6.1.3.3	Requirements	 PAGEREF _Toc257711291 \h 19
6.1.4	 Interference control	 PAGEREF _Toc257711292 \h 19
6.1.5	 Capacity and coverage optimization	 PAGEREF _Toc257711293 \h 19
6.1.6	 RACH optimization	 PAGEREF _Toc257711294 \h 20
6.2	 Actor roles	 PAGEREF _Toc257711295 \h 20
6.3	 Telecommunications Resources	 PAGEREF _Toc257711296 \h 20
6.4	Use case	 PAGEREF _Toc257711297 \h 20
6.4.1	Use case Self-Optimization Monitoring and Management	 PAGEREF _Toc257711298 \h 20
6.4.2	Use case Load Balancing Allowed/Prohibited Management	 PAGEREF _Toc257711299 \h 20
7	Functions and Architecture	 PAGEREF _Toc257711300 \h 22
7.1	Self-Optimization Logical Architecture	 PAGEREF _Toc257711301 \h 22
7.2	Self-Optimization Reference Model	 PAGEREF _Toc257711302 \h 22
Annex A (informative):	Steps for SON self-optimization Technical Specifications	 PAGEREF _Toc257711303 \h 23
Annex B (informative):	Change history	 PAGEREF _Toc257711304 \h 24

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The present document is part of a TS-family covering the 3rd Generation Partnership Project Technical Specification Group Services and System Aspects, Telecommunication management; as identified below:
32.521:	“Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP): Requirements”
32.522:	“Self-Organizing Networks (SON) Policy  Network Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS)”
32.523	“Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS)”
32.525	“Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP): Bulk CM eXtensible Markup Language (XML) file format definition”

1	Scope
The present document describes concept and requirements of OAM for Self-Optimization.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[ seq ref 1]	3GPP TS 32.101: "Telecommunication management; Principles and high level requirements".
[ seq ref 2]	3GPP TS 32.102: "Telecommunication management; Architecture".
[ seq ref 3]	3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept and definitions".
[4]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
3	Definitions and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [ REF_TS32101 1], 3GPP TS 32.102 [ REF_TS32102 2], 3GPP TS 32.150 [ REF_TS32150 3] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TS 32.101 [1], TS 32.102 [2], TS 32.150 [ REF_TS32150 3] and TR 21.905 [4], in that order.
Target: Target provides a clear basis for assessing performance of self-optimization functions. Targets need to be carefully specified in terms of a series of performance measurements and/or KPIs, which can be specific, and which can be used also to identify problems. A target should be expressed in terms of a specific value or specific value range. The present document does not specify the specific value or desired value range of each target since those should be set by operators according to their policy and different network situation.
Trigger condition: The condition at which self-optimization should be triggered. Different self-optimization algorithms may have different trigger conditions for achieving same objectives and targets. 
3.2	Abbreviations
For the purposes of the present document, the following abbreviations apply:
EM	Element Manager
eNodeB	evolved NodeB
EPC	Evolved Packet Core
E-UTRAN	Evolved Universal Terrestrial Radio Access Network
HO	Handover
ICIC	Inter Cell Interference Coordination
LB	Load Balancing
NE	Network Element
NM	Network Manager
NRM	Network Resource Model
OAM	Operation Administration Maintenance
PRB	Physical Resource Block
SON	Self Organizing Networks
UE	User Equipment
4	Concepts and background
4.1 	Overview
A self-optimization functionality will monitor input data such as performance measurements, fault alarms, notifications etc. After analyzing the input data, optimization decisions will be made according to the optimization algorithms. Finally, corrective actions on the affected network node(s) will be triggered automatically or manually when necessary.  
IRPManager should be able to control the self-optimization procedures according to the operator’s objectives and targets.
The following diagram is illustrated how the self-optimization functionality works:
 SHAPE  \* MERGEFORMAT 
Figure 4-1 Logical view of self-optimization procedure
The self-optimization functionality working procedure could be interpreted logically as following:
1. The self-optimization functionality keeps monitoring input data according to the operator’s objectives and targets. 
2. Whenever the objectives and targets are not met, optimization algorithms will be triggered.
3. Corrective actions are provided and executed. 
4. Then the self-optimization functionality evaluates the result of the executed corrective actions.
If the system status is not satisfactory after the corrective actions’ execution, fallback may be needed to reverse the system configuration to the previous status, which is before the corrective actions executed. 
If the system status is satisfactory after the corrective actions’ execution, the one time self-optimization procedure ends.
5. Self-optimization functionality returns to monitoring the input data.
4.2	Self-Optimization Concept
4.2.1	Logical Function Blocks
4.2.1.1	Self-Optimization Input Monitoring Function (SO_MON_F)
This functional bloc supports the following functions: [SO1].
4.2.1.2	Triggering Optimization Function (TG_F)
This functional bloc supports the following functions: [SO2], [SO3].
4.2.1.3	Optimization Fallback Function (O_FB_F)
This functional bloc supports the following functions: [SO7], [SO9], [SO10].
4.2.1.4	Self-Optimization Progress Update Function (SO_PGS_UF)
This function updates the self-optimization progress and important events to the operator: [SO11]
4.2.1.5	NRM IRP Update Function (NRM_UF)
This function updates the E-UTRAN and EPC NRM IRP with the optimization modification if needed.
4.2.1.6	Self-Optimization Monitoring and Management Function (SO_MMF)
This function monitors the self-optimization process and provides the operator with this information. This function must be able to get information about all other functional blocs. In addition to this it allows the operator to control the execution of the self-optimization process.
This function also resolves conflicts of different SON functions trying to change or actually changing parameter values in different directions or reports such conflicts, if they cannot be solved.
4.2.1.6.1	Self-Optimization Monitoring and Management Function (SO_MMF_NM)
SO_MMF_NM (IRP Manager): representing the NM portion of SO_MMF (necessary monitoring and limited interaction capabilities to support an automated optimization), as well as related IRPManager functionality
In a centralized conflict resolution approach SO_MMF_NM identifies and resolves conflicts. 
In distributed and hybrid conflict resolution approach SO_MMF_NM sends policy directions towards the SO_MMF_EM.
4.2.1.6.2	Self-Optimization Monitoring and Management Function (SO_MMF_EM)
SO_MMF_EM (IRP Agent): representing the portion of SO_MMF operating below Itf-N, as well as related IRPAgent functionality
In distributed and hybrid conflict resolution approach SO_MMF_EM identifies, resolves and/or reports conflicts, according to the policy directions received by SO_MMF_NM. 
In case SO_MMF_EM is not able to solve a conflict, it will request the SO_MMF_NM to resolve the conflict.
4.2.1.7	Load Balancing Function (LB_F)
This function handles the load balancing optimization.
4.2.1.8	Interference Control Function (IC_F)
This function handles the interference control optimization.
4.2.1.9	Coverage and Capacity Function (CC_F)
This function handles the coverage and capacity optimization.
4.2.1.10	RACH Optimization Function (RACH_F)
This function handles the RACH optimization.
4.2.1.11	HandOver Optimization Function (HO_F)
This function handles the handover optimization.
5	Business level requirements
5.1	Requirements
5.1.1	Self-Optimization Monitoring and management Requirements
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 The IRPAgent should support the capability for the IRPManager to define policy directions in case SON functions request conflicting parameter values. In case no policy directions are given, the IRPAgent shall apply default policy directions. 
Note: A policy direction describes an expected behaviour from the IRPAgent. Examples for such policy directions:
i)	Prioritizing SON functions in case of conflicts
ii)	Prohibiting further changes of a parameter for a certain amount of time
iii)	Selecting preferred value ranges
iv)	Telling the IRPAgent to report conflicts
REQ-SO_MM-CON-12 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.
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
5.1.6		RACH optimization
REQ-SO_RO-CON-1 RACH optimization shall be performed with minimal human intervention.
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.
 SHAPE  \* MERGEFORMAT 
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.
 SHAPE  \* MERGEFORMAT 
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.
 SHAPE  \* MERGEFORMAT 
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
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. 

 SHAPE  \* MERGEFORMAT 
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.

 SHAPE  \* MERGEFORMAT 
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.

 SHAPE  \* MERGEFORMAT 
Figure 5.4.3-3: Coverage holes with isolated island cell coverage
6		Specification level requirements
6.1	Requirements
6.1.1	Self-Optimization Monitoring and Management
6.1.1.1	Management Part
REQ-SO_MM-FUN-1	IRPManager shall be able to configure objectives and targets for the self-optimization functions.
REQ-SO_MM-FUN-2	For open loop, IRPManager shall be able to configure whether a confirmation is needed before the execution of optimization actions. The necessity of a confirmation will be decided case by case.
REQ-SO_MM-FUN-3	For open loop, IRPManager shall be able to confirm the execution of optimization actions in case IRPManager configured a confirmation is needed.
REQ-SO_MM-FUN-4 For open loop, IRPAgent shall provide information to the IRPManager about the optimization actions. The necessity of this capability will be decided case by case.
REQ-SO_MM-FUN-5 IRPAgent shall provide information to the IRPManager about the execution result of self-optimization actions.
REQ-SO_MM-FUN-6 The IRPAgent shall provide information to the IRPManager about the outcome of self-optimization. 
REQ-SO_MM-FUN-7 IRPManager shall be able to configure the values of KPIs or performance counters which may be used to trigger the optimization function.
REQ-SO_MM-FUN-8	When the IRPAgent is aware of disruptive situations for the SON functionality, it shall support optimization functions in coping with them as much as possible without the need for an intervention from the IRPManager. Disruptive situations are e.g. an outage of a cell, the insertion of a new cell, deactivation of a cell etc. 
Editor’s note: Requirements REQ-SO_MM-FUN-2 & REQ-SO_MM-FUN-3 & REQ-SO_MM-FUN-4 have to be revisited in the context of the outstanding study on whether or not open loop management is applicable to R9 self-optimization functions. A specific Stage 2 solution (Interface IRP) is not implied by these requirements. 
6.1.2	Load Balancing
REQ-SO_LB-FUN-1	The IRPManager shall be able to disable/enable the load balancing function.
REQ-SO_LB-FUN-2	The IRPManager shall be informed about the eNodeB load.
REQ-SO_LB-FUN-3	The IRPManager shall be able to request that load balancing be allowed from source cell to target cell.
REQ-SO_LB-FUN-4	The IRPManager shall be able to request that load balancing be prohibited from source cell to target cell. 
REQ-SO_LB-FUN-5	The IRPAgent shall inform the IRPManager about success or failure of IRPManager operations to allow load balancing, prohibit load balancing.
6.1.3	Handover (HO) Parameter optimization
6.1.3.1	HO failure categorization
6.1.3.1.1	HO failures due to too late and too early HO triggering
HO failures can be categorized as follows:
HO failures due to too late HO triggering
HO failures due to too early HO triggering 
Failures due to HO to a wrong cell
Consequently, the HO parameter optimisation should aim at detecting and mitigating too early HOs, too late HOs and HOs to a wrong cell. The following subsections provide the scenarios for too early HO, too late HO and HO to a wrong cell triggering leading to HO failures.
6.1.3.1.1.1	Too late HO triggering
Example scenario for too late HO triggering is shown in Figure 6-1. If the UE mobility is more aggressive than what the HO parameter settings allow for, the HO could be triggered when the signal strength of the serving cell is already too low or may not be triggered at all if a radio link failure preempts it. The connection may be re-established on a different cell from the serving cell. This is a common scenario in areas where user mobility is very high, such as along the highways, train lines etc. 
 SHAPE  \* MERGEFORMAT 
Figure 6-1 – Too late HO triggering scenario
6.1.3.1.1.2	Too early HO triggering
Example scenario for too early HO triggering is shown in Figure 6-2. HO can be triggered when the UE enters unintended island of coverage of the target cell inside the intended coverage area of the serving cell. When the UE exits the island of coverage of the target cell, it cannot acquire the target cell any more and the HO fails, potentially leading to a radio link failure. This is a typical scenario for areas where fragmented cell coverage is inherent to the radio propagation environment, such as dense urban areas.  
 SHAPE  \* MERGEFORMAT 
Figure 6-2 – Too early HO triggering scenarios

6.1.3.1.1.3	HO to a wrong cell
Example scenario for HO to a wrong cell is shown in Figure 6-3. In this scenario UE is moved from cell A to cell C, but because the HO parameter not optimized and a cell A sends a wrong HO command performs a handover to cell B and then a RLF happens. After that UE re-establishes connection with cell C.  
 SHAPE  \* MERGEFORMAT 
Figure 6-3 –HO to a wrong cell scenarios

6.1.3.2	Reducing inefficient use of network resources due to unnecessary HOs
HO procedure is resource-consuming and therefore costly to the network operator. Sometimes, the combination of user mobility patterns and cell coverage boundary layout can generate frequent unnecessary HOs that consume NW resources inefficiently. This scenario is illustrated in Figure 6-4a. HO parameter optimisation function should aim at detecting such scenarios. These scenarios sometimes can be remedied by HO parameter optimisation, as illustrated in Figure 6-4b. Since the goal of reducing unnecessary HOs can sometimes be opposed to the goal of reducing the number of HO failures, operators should be able to set the tradeoff point. 
 SHAPE  \* MERGEFORMAT 
Figure 6-4a – Frequent HOs cause inefficient use of NW resources
 SHAPE  \* MERGEFORMAT 
Figure 6-4b – HO parameter adjustment prevents frequent Hos
Additionally, incorrect cell reselection parameters setting may result unwanted handover right after RRC connection setup, HO parameter optimization function should also aim at detecting misalignment between cell reselection parameters and handover parameters setting and adjust the parameters to avoid such scenarios.
6.1.3.3	Requirements
REQ-SO_HO-FUN-1 HO parameter optimisation function shall aim at detecting too early handover, too late handover and handover to a wrong cell.
REQ-SO_HO-FUN-2 HO parameter optimisation function shall aim at detecting inefficient use of network resources due to unnecessary HOs. 
REQ-SO_HO-FUN-3 HO parameter optimisation function shall aim at meeting the objectives and targets for the HO optimisation function
REQ-SO_HO-FUN-4 The objectives for the HO parameter optimisation function shall reflect the desired tradeoff between the reduction in the number of HO related failures and the reduction of inefficient use of network resources due to HOs.
REQ-SO_HO-FUN-5	The IRPManager shall be able to disable/enable the HO parameter optimization function.
6.1.4		Interference control
REQ-SO_IC-FUN-1	The IRPManager shall be able to disable/enable the Interference Control function.
REQ-SO_IC-FUN-2	The IRPManager shall be able to request that ICIC be allowed from source cell to target cell.  
REQ-SO_IC-FUN-3	The IRPManager shall be able to request that ICIC be prohibited from source cell to target cell. 
REQ-SO_IC-FUN-4	An IRPAgent shall inform the IRPManager about success or failure of IRPManager operations to allow ICIC, prohibit ICIC. 

6.1.5		Capacity and coverage optimization
REQ-SO_CC-FUN-1 Performance measurements with geographical binning may be used as inputs into the coverage and capacity optimisation function.
6.1.6		RACH optimization
REQ-SO_RO-FUN-1 The IRPAgent shall support enabling and disabling the RACH optimization function.
6.2		Actor roles
No new actor. 
6.3		Telecommunications Resources
No new telecommunications resources.
6.4	Use case
6.4.1	Use case Self-Optimization Monitoring and Management

Use Case Stage
Evolution / Specification
<>
Related use 
Goal (*)
Optimize the system in an automated manner.

Actors and Roles (*)
IRPManager as user

Telecom resources
The E-UTRAN/EPC network including its management system.

Assumptions
The network is properly installed and running.

Pre conditions
The self-optimization objectives and targets have been set by operators

Begins when 
Based on the monitored input parameters (KPIs, Alarms, etc.), targets for the objectives defined for the self-optimization functions are not met.

Step 1 (*) (M|O)
The order of the bullet points in the list below does not imply any statements on the order of execution.
[SO1] The input parameters (KPIs, Alarms, etc.) are monitored continuously.
[SO2] When the monitored parameters do not meet the optimization targets, the optimization function is triggered.
[SO3] Optimisation function proposes corrective actions.
[SO4] Operator may confirm the execution/activation of the proposed actions if needed.
[SO5] Corrective actions are executed.
[SO6] Optimisation function monitors system status for a certain pre-defined monitoring time period.
[SO7] The configuration prior to the corrective action is memorised if needed. 
[SO8] If the system status is satisfactory during the monitoring time period, then go to [SO1]. 
[SO9]Operator may confirm if fallback is needed.
[SO10] Fallback is executed.
[SO11] The operator is informed about the progress and important events occurring during the self-optimization process.

Step n (M|O)


Ends when (*)
Ends when all steps identified above are successfully completed or when an exception occurs.

Exceptions
One of the steps identified above fails and retry is unsuccessful..

Post Conditions
System is operating normally.

Traceability (*)
REQ-SO_MM-FUN-1, REQ-SO_MM-FUN-2, REQ-SO_MM-FUN-3, REQ-SO_MM-FUN-4, REQ-SO_MM-FUN-5, REQ-SO_MM-FUN-6


6.4.2	Use case Load Balancing Allowed/Prohibited Management

Use Case Stage
Evolution / Specification
<>
Related use 
Goal (*)
The load balancing (LB) can be allowed/prohibited from a source cell to a target cell by the IRPManager.

Actors and Roles (*)
IRPManager as user

Telecom resources
The E-UTRAN/EPC network including its OSS.

Assumptions
There is operator’s policy for LB allowing/prohibiting management. For example:
LB from the higher priority cell to the lower priority cell is allowed; reverse is prohibited.
LB between an eNB cell and another eNB cell which belongs to another unwanted PLMN is prohibited.

Pre conditions
The network is operational.

Begins when 


Step 1 (*) (M)
The IRPManager makes a decision to allow/prohibit LB from a source cell to a target cell: 
According to operator’s policy, or
According to some information got in run time. For example:
LB would always fail between some particular cells in case of some inappropriate parameters setting. In that situation, the LB function located at eNB may make a decision to prohibit LB between these particular cells and notify this infomation to the IRPManager. 
After the CM parameters adjusting, the LB between those cells may be allowed again based on the good values of relative PM counters.

Step 2 (*) (M)
The IRPAgent is instructed by the IRPManager to allow/prohibit LB from the source cell to the target cell. 

Step 3 (*) (M)
The LB is allowed / prohibited from the source cell to the target cell by the corresponding eNB(s). 

Step 4 (*) (M)
Reporting of the allowing/prohibiting LB operation result to the IRPManager. 

Ends when (*)
Ends when all steps identified above are completed or when an exception occurs.

Exceptions
One of the steps identified above fails and retry is unsuccessful.

Post Conditions
The LB is allowed/prohibited from a source cell to a target cell successfully or unsuccessfully.

Traceability (*)
REQ-SO_LB-FUN-3, REQ-SO_LB-FUN-4, REQ-SO_LB-FUN-5


7	Functions and Architecture
7.1	Self-Optimization Logical Architecture
The lines between the functional blocks do not indicate specific 3GPP interfaces.
For the abbreviations used, please see the headlines of clause 3.
 SHAPE  \* MERGEFORMAT 
7.2	Self-Optimization Reference Model
The SO_MMF has a part located in the EM and a part located at the NM.
For the abbreviations used, please refer to clause 3.
 SHAPE  \* MERGEFORMAT 
Annex A (informative):
Steps for SON self-optimization Technical Specifications
The TSs for SON self-optimization shall follow the steps below.
1. Goal

2. Problem Scenarios
The problem scenarios need to be optimized under the goal. This part may contain multiple problem scenarios


3. Parameters to be Optimized
The list of parameters needs to be optimized to resolve the problems under the goal. The parameters listed here are the overall parameters need to be optimized; it does not imply that all of the parameters are required to be open over Itf-N.

4. Architecture and Responsibilities
The suitable architecture to optimize the parameters above, it can be centralized, distributed or hybrid SON architectures.
And based on the architecture, the clear split of the responsibilities among NM, EM and NE should be stated here. This will result in the work split among 3GPP WGs.
5. Performance Measurements and NRMs
Performance measurements:
List of the performance measurements which are required via Itf-N to recognize the problem scenarios, and to monitor the result of self-optimization, based on the selected architecture and responsibilities.
This part only includes the descriptions for the performance measurements, and the detailed definitions will be defined in TS 32.425/32.426.


NRMs:
The parameters need to be modeled in NRM, to support the optimizations required over Itf-N according to the selected architecture and split responsibilities.

Annex B (informative):
Change history 
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNewJun 2009SA#44SP-090303----Presentation to SA for Information-1.0.0Mar 2010SA#47SP-100052----Presentation to SA for Approval1.0.02.0.0Mar 2010--------Publication of SA approved version2.0.09.0.0









 STYLEREF ZA 3GPP TS 32.521 V9.0.0 (2010-03)
 PAGE 24
 STYLEREF ZGSM Release 9


3GPP


HOs not triggered due to HO parameter adjustment

Cell A

Cell B



3dTower.emf



3dTower.emf



3dTower.emf



3dTower.emf

= HO triggering

Cell A

Cell B



3dTower.emf



3dTower.emf



3dTower.emf



3dTower.emf

X  = HO failure 

X

Cell A

Cell B

Island of coverage of Cell B inside the coverage area of Cell A



3dTower.emf



3dTower.emf



3dTower.emf



3dTower.emf

    = HO triggering

X 

X  = radio link failure 

Cell A

Cell B

Due to fast movement and inadequate HO parameter setting, UE leaves the source cell coverage before the HO is triggered 



3dTower.emf



3dTower.emf



3dTower.emf



3dTower.emf

2G/3G/Different freq of LTE Coverage

Specific Freq 
Coverage of LTE

Coverage holes

Radio Coverage of E-UTRAN

Coverage holes




Actual Isolated Island Cell 
of E-UTRAN

Coverage holes

Planned Isolated Island Cell of E-UTRAN

Coverage holes

Loop: Keep Monitoring

Is system status better after the corrective actions’ execution?

Analyse input data with Optimization Algorithms 

Execute corrective actions

Monitor input data


One time Self-optimization procedure ends

Fallback may be needed to reverse the system to the previous status, which is before the corrective actions executed.

Yes

No

Meet the targets?

Yes

No







LB Area

Cell A

LB Area

Cell B

Cell A

Cell B

LB Area



Cell B

Cell A







































    = HO triggering

3dTower.emf



3dTower.emf



3dTower.emf



3dTower.emf



Radio link failure due to unproper HO parameter setting between cell A and cell B

Cell B

Cell A

X

X  = radio link failure 

3dTower.emf



3dTower.emf



Cell C

 

N

-

Itf

 

(IRPManager)

 

SO_MMF_NM

 

(IRPAgent)

SO_MON_F

SO_MMF

LB_ F

CC_F

Actor

O_FB_F 

NRM_UF


HO_ F

IC_ F

SO_PGS_UF


RACH_F 

TG_F

 

SO_MMF_EM

SO_MON_F

LB_ F

CC_F

O_FB_F 

NRM_UF


HO_ F

IC_ F

SO_PGS_UF


RACH_F 

TG_F