INFSO-ICT-316384 SEMAFOUR D5.4 Integrated SON …cordis.europa.eu/docs/projects/cnect/4/316384/080/deliverables/001... · The results of this analysis work are explained in detail

EU FP7 ICT STREP SEMAFOUR (316384)

INFSO-ICT-316384 SEMAFOUR D5.4

Integrated SON Management Implementation Recommendations

Contractual Date of Delivery to the EC: May 31st , 2015 Actual Date of Delivery to the EC: August 11th, 2015 Work Package WP5 – Integrated SON Management Participants: NSN-D, ATE, EAB, FT, TID, TNO, TUBS Authors Luis CAMPOY, Sana BEN JEMAA, Christoph FRENZEL, Dario

GÖTZ, Sören HAHN, Ovidiu IACOBOAIEA, Simon LOHMÜLLER, Pradeepa RAMACHANDRA, Lars Christoph SCHMELZ, Hans VAN DEN BERG

Reviewers Zwi ALTMAN, Colin WILLCOCK Estimated Person Months: 13.5 Dissemination Level Public Nature Report Version 1.0 Total number of pages: 80 Abstract: This document includes the final implementation concepts and guidelines for the SEMAFOUR proposed Integrated SON Management system. These recommendations will pave the way for including SEMAFOUR concepts and solutions into the current 3GPP system architecture, with splitting functionalities across different network functional entities. Furthermore. The document also includes implementation concepts and guidelines for a Decision Support System, focussing on short and long term network evolution. Keywords: Self-organisation, SON, SON Coordination, Policy-based Management, Monitoring and Diagnosis, Decision Support System

Ref. Ares(2015)3550199 - 28/08/2015

SEMAFOUR (316384) D5.4 Integrated SON Management – Implementation Recommendations

Version 1.0 Page 2 of 80

Executive Summary The SEMAFOUR project has designed an architecture, methods and algorithms that define an Integrated SON Management system, capable of defining and coordinating the SON functions’ policies and rules, based on high-level network-oriented objectives. A detailed description of the Integrated SON Management components, namely, Policy-Based SON Management (PBSM), Operational SON Coordination (SONCO), Decision Support System (DSS) and Monitoring & Diagnosis (MD), has already been provided in previous SEMAFOUR deliverables D5.2 [1] and D5.3 [2]. This deliverable describes the recommendations regarding the implementation of the developed solutions for Integrated SON Management. The implementation studies have been conducted from three perspectives. Firstly, the final results for each of the components have been analysed in comparison to the initially defined functional architecture of Integrated SON Management (cf. SEMAFOUR D2.2 [3] and D5.1 [4]), and the impact on this overall architecture is described. Secondly, the impact of the developed concepts and results have been analysed in terms of their expected impact on the network management and operations processes within the mobile network operators’ organisations. The results of this analysis work are explained in detail in this deliverable. As part of this second implementation study, an activity has been conducted with several operational departments at European MNOs. Thirdly, the developed concepts and results have been analysed in terms of their impact to the 3GPP standardised Operation, Administration and Maintenance (OAM) architecture. For each of the components several implementation options have been considered (at least where applicable), and their individual impact on the existing standards has been analysed. Recommendations regarding which of the options is preferable are given within this deliverable. In addition to describing the analysis and results of the different implementation studies, some complementary results regarding the development work within Work Package 5 are provided. As this was not initially planned for D5.4, these results are combined into a dedicated Part II of the document. This deliverable represents the completion of SEMAFOUR Work Package 5, providing the recommendations regarding implementation, and the final update regarding the conceptual and development work.



List of Authors

Partner Name E-mail

NSN-D Lars Christoph Schmelz Christoph Frenzel Simon Lohmüller

[email protected] [email protected] [email protected]

ATE Dario Götz [email protected]

EAB Pradeepa Ramachandra [email protected]

FT Sana Ben Jemaa Ovidiu Iacoboaiea

[email protected] [email protected]

TID Luis Campoy [email protected]

TNO Hans van den Berg [email protected]

TUBS Sören Hahn [email protected]

mailto:[email protected]












List of Acronyms and Abbreviations 2G 2nd Generation mobile wireless communication system (GSM, GPRS, EDGE) 3G 3rd Generation mobile wireless communication system (UMTS, HSPA) 3GPP 3rd Generation Partnership Project ABS Almost Blank Sub-frames ANR Automatic Neighbour Relations CAPEX CAPital EXpenditure CIO Cell Individual Offset CCO Coverage and Capacity Optimisation CL Cell Load CM Configuration Management CER Cell Range Expansion DCR Dropped Call Rate DSS Decision Support System DSS-ONE DSS-Operational Network Evolution DSS-SNM DSS-Strategic Network Migration ECA Event-Condition-Action EDGE Enhanced Data rates for GSM Evolution EM Element Manager e ICIC Enhanced Inter-Cell Interference Coordination eNB, eNodeB evolved NodeB, LTE radio base station E-UTRAN Evolved UTRAN EC Energy Consumption ESM Energy Savings Management GERAN GSM EDGE Radio Access Network GPRS General Packet Radio Service GSM Global System for Mobile communication HetNet Heterogeneous Networks HM High-Mobility HO Handover Optimisation HOSR Handover Success Rate HS Hot Spot HYS HO Hysteresis HSPA High Speed Packet Access ICIC Inter-Cell Interference Coordination IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IMPEX IMPlementational EXpenditure IOC Information Object Class IRAT Inter-RAT Itf-N Interface-N, described in 3GPP OAM architecture KPI Key Performance Indicator KUI Key User Indicator LAN Local Area Network LD Load LF Lineal Features LTE Long Term Evolution LTE-A Long Term Evolution – Advanced MD Monitoring and Diagnosis



MDT Minimisation of Drive Test MIMO Multiple Input Multiple Output MLB Mobility Load Balancing NRM Network Resource Model MRO Mobility Robustness Optimisation NBC Naïve Bayes Classifiers NE Network Element NEM Network Element Manager NGMN Next Generation Mobile Networks NM Network Management NMP Network Measurement Pool NN Neural Network NPZC Neighbour Problem Zone Coverage OAM Operation, Administration and Maintenance OPEX OPerational EXpenditure OSF Operations System Function PAN Personal Area Network PBSM Policy Based SON Management PDP Policy Decision Point PEP Policy Enforcement Point PCI Physical Cell Identifier PM Performance Management PP Ping Pong HOs PZC Problem Zone Coverage PZLS Problem Zone Load Sharing QoE Quality of Experience QoS Quality of Service RACH Random Access Channel RAN Radio Access Network RAT Radio Access Technology RL Reinforcement Learning RRC Radio Resource Control SA State Aggregation SCP SON function Configuration Parameter SCV SON function Configuration parameter Value SeNB Serving eNodeB SFM SON Function Model SLA Service Level Agreement SOM SON Objective Manager SON Self-Organising Network SONCO SON Coordinator SoTA State of The Art SSPI SCV Set Performance Indicator SUMO Simulation of Urban MObility SVM Support Vector Machine TD-LTE Time Division duplex LTE TeNB Target eNodeB TL Too Late HOs TR Throughput HO TTT Time-To-Trigger UE User Equipment



UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network WLAN Wireless Local Area Network WP Work Package



Table of Contents 1 Introduction .................................................................................................. 9

Part I: Integrated SON Management Implementation ................................. 10

2 Implementation According to Functional Architecture ......................... 11 2.1 Policy-Based SON Management .......................................................................................... 13 2.2 Operational SON Coordination ........................................................................................... 13 2.3 Decision Support System ...................................................................................................... 15 2.4 Monitoring and Diagnosis ................................................................................................... 15

3 Implementation According to Operator Processes ................................. 18 3.1 Policy-Based SON Management .......................................................................................... 18

3.1.1 High Level Operator Goals and Technical KPIs ........................................................... 19 3.1.2 Impact of Marketing Campaigns and Special Events .................................................... 20 3.1.3 Incident Handling .......................................................................................................... 21 3.1.4 Conclusions ................................................................................................................... 21

3.2 Operational SON Coordination ........................................................................................... 22 3.3 Decision Support System ...................................................................................................... 22

3.3.1 From the input perspective ............................................................................................ 22 3.3.2 From the output perspective .......................................................................................... 22

3.4 Monitoring and Diagnosis ................................................................................................... 22

4 Implementation According to Standards ................................................. 24 4.1 Policy-Based SON Management .......................................................................................... 24

4.1.1 Option 1: Itf-N between Input Models and SON Objective Manager ........................... 26 4.1.2 Option 2: Itf-N between SON Objective Manager and Policy System ......................... 30 4.1.3 Option 3: Itf-N between PBSM System / MD components and Network ..................... 33 4.1.4 Conclusions ................................................................................................................... 36

4.2 Operational SON Coordination ........................................................................................... 36 4.2.1 SONCO-R in a HetNet Scenario ................................................................................... 37 4.2.2 SONCO-R in a Macro-Only Scenario ........................................................................... 38 4.2.3 SONCO-D ..................................................................................................................... 38

4.3 Decision Support System ...................................................................................................... 39 4.4 Monitoring and Diagnosis ................................................................................................... 40

4.4.1 Localisation in the Network Management System ........................................................ 40 4.4.2 Time Criticality ............................................................................................................. 42

4.4.2.1 Services to the PBSM............................................................................................. 42 4.4.2.2 Services to the DSS ................................................................................................ 43 4.4.2.3 Services to the SONCO-D ..................................................................................... 43

4.4.3 Communication Volume ............................................................................................... 43

Part II: Complementary Development Results .............................................. 45

5 Policy-Based SON Management ............................................................... 46 5.1 Introduction .......................................................................................................................... 46 5.2 SON Management – Final Results ...................................................................................... 47

5.2.1 Input models .................................................................................................................. 47 5.2.1.1 Context Model ....................................................................................................... 47 5.2.1.2 Objective Model..................................................................................................... 48 5.2.1.3 SON Function Model ............................................................................................. 48

5.2.2 SON Function Configuration Process ........................................................................... 49 5.2.2.1 KPI Processing ...................................................................................................... 49 5.2.2.2 SCV Set Processing ............................................................................................... 51 5.2.2.3 Learning Process, Adaptation of Pool 1 ............................................................... 53



5.2.2.4 Example ................................................................................................................. 54

6 Operational SON Coordination ................................................................ 56 6.1 Conflict resolution CRE, eICIC, MRO ................................................................................ 56 6.2 Conflict Detection CRE, eICIC, MRO ................................................................................. 59

6.2.1 Causes and Symptoms ................................................................................................... 60 6.3 Conflict resolution HM, MLB .............................................................................................. 61

7 Decision Support System ........................................................................... 63 7.1 Introduction .......................................................................................................................... 63 7.2 DSS Bottleneck detection benchmarking ............................................................................ 63 7.3 DSS-SNM – Final Results .................................................................................................... 66

7.3.1 Concept of DSS SNM ................................................................................................... 66 7.3.2 New Carrier Integration in LTE Network ..................................................................... 66

7.3.2.1 Coverage Aspect of Higher Frequencies ............................................................... 67 7.3.2.2 Integration in Macro Cell vs. Small Cell ............................................................... 69 7.3.2.3 Upgrade Options Evaluation ................................................................................. 73 7.3.2.4 Conclusions ........................................................................................................... 76

8 Summary and Future Work ...................................................................... 77

9 References ................................................................................................... 79



1 Introduction SEMAFOUR Work Package 5 has developed an Integrated SON Management system that configures and manages the individual SON functions operating in a heterogeneous mobile radio network in a coordinated manner. Several architecture layers, functional elements and interfaces have been developed, implemented and evaluated as part of the overall Integrated SON Management system, these enable the desired network performance to be defined through high-level operator-defined technical objectives. This approach enables the maximum value from the already deployed network to be achieved by automatically and autonomously adapting the network elements’ configuration according to their role, context, and the implemented SON functions. The developed solution allows the operator targets to be fulfilled with simultaneously minimising the OPEX needed to manage the network. In addition, a timely and cost efficient way to identify and manage network upgrades is introduced. The availability of a well-defined interface between the components of Integrated SON Management and the SON functions themselves allows for a multi-vendor implementation, where SON functions provided by different manufacturers can be aggregated together into the operator’s network Operation Administration and Maintenance (OAM) system. An important task of the development work is to provide an analysis in how far the proposed concepts can be implemented into real systems, and where the major impact is expected regarding the initially developed functional architecture, the operational processes, and 3GPP standards. This is the main scope of this document, therefore concluding the work performed within SEMAFOUR WP5. The results of the studies on implementation are described within PART I of the document as explained below. In addition, as the development and implementation work has been ongoing even after the completion of D5.3 [2], some updated results are provided within PART II of the document.

PART I Integrated SON Management Implementation This part provides a detailed analysis of several aspects of implementing the developed Integrated SON Management results: • Implementation according to functional architecture (Chapter 2) – this chapter introduces the

major changes of the final Integrated SON Management functional architecture compared to the initial phase of SEMAFOUR project. It also provides the major reasons for these changes.

• Implementation according to operator processes (Chapter 3) – this chapter describes the impact on the operator’s OAM processes caused by the introduction of Integrated SON Management, in particular through the Policy-Based SON Management component.

• Implementation according to 3GPP standards (Chapter 4) – this chapter describes the different implementation options (if applicable) that have been identified for the Integrated SON Management components, with respect to the existing OAM standards defined by 3GPP.

PART II Complementary Development Results This part contains additional development and implementation results on top of the descriptions provided in D5.3 [2] that have been obtained for some of the components of Integrated SON Management. In particular, this part provides updates to: • Policy-Based SON Management (Chapter 5) – the updates are mainly related to the SON Function

Model learning process which has been briefly introduced with D5.3 • Operational SON Coordination (Chapter 6) – the updates are mainly related to the HetNet conflict

resolution scenario and the conflict detection introduced in D5.3 • Decision Support System (Chapter 7) – the updates are mainly related to bottleneck detection

benchmarking, but in particular include the final results of the DSS-SNM use case



Part I: Integrated SON Management Implementation This part of the document comprises the main goal of D5.4, namely, to describe and analyse the different aspects of solution implementation for Integrated SON Management as developed within WP5, and to provide recommendations which of the identified implementation options is preferable from the perspective of the SEMAFOUR project. The three aspects covered by this work (cf. also the description in Chapter 1) thereby include the major changes to the Integrated SON Management functional architecture as it has initially been introduced in SEMAFOUR deliverable D2.2 [3]. The reasoning for these changes is briefly described. Secondly, the potential impact of the concepts and solutions developed within WP5 on the processes within the mobile network operators’ organisations are elaborated, where processes here mainly consider the operation, administration and maintenance of the network, and the transformation between high-level (business, strategic, customer-related) goals and technical KPI target definition and supervision. Finally, the potential impact of the concepts and solutions within WP5 on the existing 3GPP standards, in particular for network management, are elaborated. Where applicable, different implementation options are highlighted and their pros and cons are analysed. For each of these three aspects conclusions are drawn in how far the analysis results impact existing processes or standards, and where applicable recommendations are given how to proceed in terms of input to 3GPP standardisation.



2 Implementation According to Functional Architecture The SEMAFOUR Integrated SON Management functional architecture was initially described in SEMAFOUR deliverable D2.2 [3] , being composed of the four main components: Policy-Based SON Management (PBSM), Operational SON Coordination (SONCO), Monitoring and Diagnosis (MD), and Decision Support System, as shown in Figure 1. A more detailed description, refinement and split of these components has been elaborated in D5.1 [4].

Figure 1: Integrated SON Management Overall Functional Architecture as described in D2.2



The research and development work conducted within WP5 led to an additional refinement of this overall functional architecture. This applies to the scope of the four components, to the interfaces in between the components as well as to the interfaces between the components and the network. The refined architecture reflecting the final outcome of the WP5 work is shown in Figure 2.

Figure 2: Integrated SON Management Final Overall Functional Architecture



The following sections provide a more detailed comparison between the initially defined functional architecture of the components, and the reasoning why certain changes have been made to the definitions provided with D2.2 [3].

2.1 Policy-Based SON Management The PBSM is the entrance point of the operator’s inputs into the Integrated SON Management system. The concept of PBSM has evolved from an initial view, where High-level Operator Goals (e.g., related to services and service quality, customer perception, or strategic and business targets of the operator, see Figure 2) served as input and, based on this, the overall SON System (i.e., the SON functions and SON Coordinator (SONCO)) is configured and managed. The feedback received from mobile network operators (see Section 3.1) has pointed out that the elaboration and transformation of Technical Objectives, which are based on High-level Goals, is a key strategic process that the operators are not willing to include into an Integrated SON Management system. In so far, the definition of High-level Goals and the development of an automated transformation process into Technical Objectives could not be kept as a main goal within WP5, but PBSM has rather focused on using Technical Objectives (i.e., network context dependent, weighted KPI targets) as the relevant input. In addition, the PBSM not only requires the information related to Technical Objectives as input, but also information on the network system model. This needs to be defined by the operators in order to take into account the network context which is relevant for appropriately configuring the network. The information about the system is described within the Context Model, containing all that information which is relevant to the operator in terms of defining the Technical Objectives. The third input is to be provided by the manufacturers of the SON functions which are implemented in the network. This input, denominated as SON Function Model (SFM), describes a simple mapping between a certain SON function configuration and the induced effects on the KPIs. The work on PBSM therefore led to an update in the requirements, where a clearer separation between the operator and the SON manufacturer domains (regarding the input information to SON management) was defined (for details, see the PBSM description in D5.2 [1] and D5.3 [2]). This requirement could be addressed with the development of the SON Objective Manager as a core function within PBSM. The PBSM component is in charge of the transformations from the operator’s inputs, i.e., the Technical Objectives and the Context Model (see Figure 2) into the definition of a SON Policy. This SON Policy includes all information needed for configuring the SON system to work optimally towards achieving the Technical Objectives. Finally, the PBSM component includes the functions for the actual interpretation and execution of this SON Policy during runtime. While the input considered by PBSM has changed due to the operators’ feedback described above, the output provided by PBSM towards the SON functions and the SON Coordinator remains similar to the requirements and definitions initially foreseen in D2.2 [3]. For example, the configuration information required to configure the SON functions and the SONCO such that the KPI targets defined within the Technical Objectives are fulfilled by the network. In summary, compared to the initial aim described in D2.2 [3], the PBSM development and implementation has focused on the intermediate and bottom layers as depicted in Figure 1, since concrete input has been available for those layers enabling the development of a practically usable and implementable SON management solution.

2.2 Operational SON Coordination The SON Coordinator (SONCO) block has finally been split in three different components to account for its different functions: • Conflict Detection (SONCO-D): This mechanism aims to identify the active conflicts present in

the network (cf. [5]). • Conflict Resolution (SONCO-R): This a mechanism deals with already identified active conflicts

(cf. [6]).



• Conflict Prevention (SONCO-P): This mechanism should take measures such that the conflicts are prevented from happening, e.g., deactivate a SON function in certain areas, choosing certain settings of the SON functions such that the conflict risk is lowered. The SONCO-P should help close a loop via the PBSM in order to optimise the settings of the SON function. This has not been talked in this work.

This section focuses on the SONCO-D and the SONCO-R components and their evolution in the functional architecture from the initial SONCO block as described in D2.2 [3] and D5.1 [4].

Figure 3: SONCO Functional Architecture

Figure 3 show the functional architecture of the 2 blocks finally integrating the SONCO functional architecture, which have the following basic functionalities:

SONCO-D • receives from PBSM the information about which SON functions are currently active, and their

current configuration • provides to the PBSM the information on which SON functions are actively conflicting. This

could include also the reason why they conflict, i.e., the setting of the SON functions which leads to making the conflict active. As a consequence the PBSM may change the settings of the SON functions in order to make the conflict inactive or it may also choose to ask the SONCO-R for a run-time conflict-resolution

• receives the update requests sent by the SON functions. This information is used to identify active parameter conflicts. As mentioned, this information is then transmitted to the PBSM which may choose to change the settings of the SON functions or resort to the SONCO-R as a solution. The criticalness indicator (see D5.3 [2]) is not necessarily needed

• receives network KPIs directly from the network or via the MD. This information is used to identify measurement conflicts

SONCO-R • is activated if the PBSM cannot make a conflict inactive by changing the settings of the SON

functions, or if it simply considers that the SONCO-R solution is better • receives information from the PBSM regarding the ranking of the SON functions: priorities,

weights, etc. • receives information from the SONCO-D (directly or via the PBSM) regarding which conflicts are

active, and thus which conflicts it should focus on • receives the update requests of the SON functions and decides if they are accepted or denied. The

update requests should include the criticalness indicator if available. (see D5.3 [2]) • provides to the SON functions the information if their request were accepted/denied • (optionally) has to be itself capable of implementing the accepted update requests



2.3 Decision Support System The Decision Support System (DSS) automatically provides recommendations about network enhancements and extensions, when it is expected that the desired service level cannot be met by the SON Management System in the (near) future. The main task of DSS has been finally divided into two sub-tasks (or “stages”, see Figure 4 below). The first sub-task (“Bottleneck detection and triggering”) is to timely identify when and where performance problems will occur; the second sub-task (“Recommendation for network upgrades”) is to determine suitable network upgrades solving the expected bottlenecks and optimally trading off costs and performance.

Figure 4: Functional architecture of DSS (taken from D5.3 [2])

The two sub-tasks have been extensively described and illustrated at a conceptual level in Chapter 4 of D5.2 [1]. Quantitative methods and algorithms for executing the two sub-tasks have been developed during Year 2 / Year 3 of the project; these are provided in Chapter 4 of D5.3 [2], including a large number of illustrative examples. DSS has also been implemented for demonstration purposes, see D3.4 [7]. Most components of DSS do not have an external interface. In fact, the only interaction with other functional entities in the overall Integrated SON Management system architecture (see also Figure 2) is with the Monitoring and Diagnosis (MD) system. MD should provide DSS with traffic and performance measurements and analyses (e.g. predictions based on historical data). This input from MD needs to be complemented with required information from the operator (e.g. marketing expectations and information regarding the network configuration, upgrade options, etc.; see also Section 3.3). On the other hand, the operator will also receive the main output from DSS, i.e. information about expected bottlenecks and a ranked list of ‘best’ network upgrade alternatives solving these bottlenecks. Again, see Section 3.3 for further information regarding the interface of DSS to the operator. The integration of the DSS into the Integrated SON Management functional architecture has remained mostly unchanged throughout the project, with the same input and output interfaces as defined in D2.2 [3]. The individual steps for the DSS triggering part and the derivation of recommendations part that have been outlined in D2.2 [3] have been further refined in D5.2 [1] and D5.3 [2]. In particular, new mechanisms for estimating and predicting KPI values at cell level based on rule-based statistical regression model trees have been introduced and experimentally evaluated in D5.3 [2].

2.4 Monitoring and Diagnosis The Monitoring and Diagnosis (MD) function is an infrastructure component of the Integrated SON Management system responsible for collecting, storing, and statistically processing network performance and configuration data. It acts as a database of statistically cleaned and enriched data, which it provides various analysis and processing services to management system entities. Each function of the Integrated SON Management system introduces a high level of automation that relies on network intelligence in order to fulfil the individual goals of each function. The MD function



aims at automatically providing reliable performance and configuration data that may be interpreted easily in terms of reliability (labelling, consolidation, missing data recovery) and performance (performance assessment), see [4]. Addressing the needs for automatic network monitoring of the various entities of the management system, the MD offers several services: • Provision of performance measurements and corresponding configuration data • Evaluation and statistical aggregation of performance objectives • Informing other functional entities about relevant events occurring within the network • Analysis of historical performance data such as the extraction of trend or seasonal information or

computation of data based predictions. In SEMAFOUR deliverable D2.2 [3], the MD function’s basic structure and requirements have been defined. The major functional blocks, consisting of statistical processing and performance assessment, have been identified, and envisioned tasks within the functional blocks - sketched. The general functional architecture described in that deliverable remained valid throughout the duration of the project. In the SEMAFOUR deliverables D5.1 [4], D5.2 [1] and D5.3 [2], the previously defined functional blocks have been described in more detail within the architectural frame described in D2.2 [3], and new functional blocks concerned with event generation (in D5.1 [4]) and cell class analytics (in D5.3 [2]) have been added.

Figure 5: Monitoring and Diagnosis Functional Architecture ([1])

D5.1 [4] describes in more detail interrelations between the MD functions and the entities of the Integrated SON Management system, i.e. which MD services are provided to which part of the PBSM and DSS. This description follows closely the functional architecture described in D2.2 [3] and is meant to provide further detail from an architectural point of view. D5.2 [1] is meant to go further into the details of the performance assessment functionalities sketched in the functional architecture in D2.2 [3]. A model has been developed that enables a statistical evaluation of network performance for different parts of the network. Using a standardised form developed in D5.2 [1], the entities of the Integrated SON Management system can request performance assessment jobs from the MD. Further refinement of the performance assessment functionalities in particular with respect to the requirements for the PBSM have been developed in D5.3 [2]. This includes the computation of statistical performance representatives for particular cell classes as well as functionalities that are used



to characterise cells with respect to their context and performance. Due to the strong statistical nature of definition and management of cell classes, the algorithms to classify cells and to supervise the statistical quality of the defined cell classes have been considered as MD functionality. Since most MD components do not have an external interface, but are used for internal service purposes such as data reduction, data quality, performance assessment, cell classification, etc, the impact on existing OAM structure outside the Integrated SON Management system focuses on data collection mechanisms. The requirements for data collection will be discussed in further detail in Section 4.4.1.



3 Implementation According to Operator Processes In this chapter, the impact of the developed Integrated SON Management concepts on the OAM processes at the operator is described. The main interface provided by the Integrated SON Management solution developed in SEMAFOUR are the DSS as a source of information for network update requirements, and PBSM as the input component for the operators’ definition of the network performance and behaviour requirements.

3.1 Policy-Based SON Management PBSM is the entrance point for operator-defined high-level goals (e.g., related to services and service quality, customer perception, or strategic and business targets of the operator), and therefore major effort has been spent within WP5 to understand the current State-of-The-Art (SoTA) in operators’ Operation, Administration and Maintenance (OAM) processes. These processes stretch from defining the high-level goals, via network planning and defining network Key Performance Indicators (KPIs), to the day-to-day configuration, fault and performance management and analysis. For most of these tasks dedicated operator internal responsibilities, procedures and processes are implemented. The study of this current SoTA has been carried out twice within the project. At first, a study with operational personnel of the two mobile network operators involved in the project has been carried out in 2014, in order to get a first insight into the processes of OAM as they are conducted today. However, though the results of this first activity were agreed to be kept confidential, they already had some influence on the further work within WP5 in such way that the “Transformation 1” component of PBSM as shown in Figure 1 had to be de-prioritised. This was caused by the fact that there was only very little information available about the underlying processes and data required to conduct this process, which made it almost impossible to develop and define a corresponding automated transformation component. In order to substantiate the findings of this first activity, a second investigation has been launched in 2015, by defining a detailed questionnaire with more than 60 questions related to the current SoTA in OAM processes. This questionnaire has been sent to six European mobile network operators (members of the project’s Advisory Board) that had agreed to provide feedback. Meetings with the operators were organised where necessary or requested, in order to clarify issues related to the questionnaire and the evaluation process. The skeleton of this questionnaire was divided into four main sections, reflecting the open issues from the perspective of SEMAFOUR WP5:

1. Regular high-level goals o Who defines high-level goals, may they come from outside, how often are they

reviewed, are they weighted? o Processes related to Service Level Agreement (SLA) definition, enforcement and

control o Incident ticketing related to high-level goals; what is the RAN share in such incidents?

2. High-level goals for marketing and special events o Who defines the goals, how are they taken into account for long-term and short-term

planning, who implements them? o How is the routing between high-level goals definition and implementation done?

(What kind of information is routed? How long does this take?) o How is the achievement of high-level goals monitored?

3. Technical objectives / KPI targets o Who defines objectives, who defines their values, are they weighted, how often do

they change?



o Mapping process: How does the interrelation between high-level goals and technical objectives look like? Are there well-defined transformation processes? Examples for such a mapping

4. Performance Monitoring o High-level quality monitoring o SON monitoring / verification o Role / importance / areas / frequency of drive tests

In addition, the improvements of recently deployed by SON functionalities and their management to the existing processes were evaluated. For the sake of confidentiality, the answers by the operators as described in the following paragraphs are mainly aggregate values of the trends observed through the different questionnaire replies received from the six operators.

3.1.1 High Level Operator Goals and Technical KPIs High-level goals as they have been defined in D2.2 [3] and D5.1 [4] are a mix of technical, economical, and marketing objectives of mobile network operators. Within the operators’ organisations, technical, commercial and marketing boards are in charge of jointly defining these targets, usually on a yearly basis, but intermediate redefinitions could also take place. Therefore the high-level networks goals are, from SON point of view, a long term influence, driving network performance objectives in accordance to the economical restrictions (CAPEX and OPEX). In fact, the implementation of the high-level goals takes several months, as they usually involve some strategic decisions that are beyond network optimisation. These goals may be influenced through external (service) providers, dedicated (large) customers or mobile virtual network providers, but are defined internally by teams within the operators’ organisations as a strategic decision. The transformation of the high-level goals into detailed technical objectives (i.e., targets for network KPIs), as originally planned by the PBSM layer “Transformation 1” (cf. Figure 1), is a very sensitive task, since it involves on the one hand the operator’s strategic and confidential inputs, and on the other hand it has a huge impact on cost and performance. Currently, this transformation is manually performed by teams of specialised and highly skilled technical network operations experts. The transformation process is thereby based on experience and specific analysis, and is currently foreseen by operators as a topic not being susceptible to become automated. In fact, due to trade-offs between different KPIs, in some cases the achievement of different KPIs need to be balanced or weighted. Only one of the six operators uses a model-based approach for refinement (i.e., a mapping model between high-level goals and KPIs), but this model is kept as confidential and could not be used by SEMAFOUR. In order to verify the match between the high-level goals and the network KPIs, as well as their degree of achievement, both are monitored. This monitoring is performed in different ways, from marketing results (customer satisfaction pools, churn rate, brand perception …) to network KPIs achievements. For fixed network (or other facilities such as power plants) performance monitoring, the information is easily extracted from the equipment itself or from specific probes installed in operator owned equipment. However, for monitoring cellular service, the performance of drive test is also perceived as highly important, including the test made with portable equipment in in-building or other areas not accessible to cars. Even when the number, frequency and design of drive tests varies from one operator to another, there neither seems to be a real substitution for drive test available nowadays, nor is it foreseen that they will diminish in the next years. However, the Minimisation of Drive Tests approach and technology is considered to become a possible substitution for at least some “manual” drive tests. In Figure 6 an exemplary schematic representation of the existing manual processes existing within operators’ organisations is shown. The major issue for SEMAFOUR WP5 in terms of the transformation between high-level goals and technical objectives is thereby described as a “magic



triangle”, since the definition of KPI thresholds and the context-dependent cell configurations (“Templates”, including configuration parameter values) used as actual input for the network engineering and operations teams is based in principle on globally defined high-level goals. However, the translation from goals on the one side, and templates and KPI thresholds on the other side, is in general not described through a written process. This makes the development of an automation concept for this process rather difficult, as this strategic knowledge is barely shared even within the operators’ organisations, and definitely not published.

Figure 6: Graphical representation of an exemplary mobile network operator OAM process

3.1.2 Impact of Marketing Campaigns and Special Events Marketing campaigns (i.e., offers to the end customers), or special events (such as sport events, music events or demonstrations …) are associated to the definition and implementation of new high-level goals. For marketing campaigns these goals usually affect the full network, and for special events the goals have mainly local impact. These goals are in any case planned changes of the “regular” high-level goals, and therefore their process of transformation into network KPIs follows a similar path that the previously explained high-level operator goals. Depending on the foreseen impact, different levels of senior specialists are involved in the transformation, but in any case, the transformation is included in a long-term network planning. Most operators use at least a dedicated process or even dedicated tools to follow the evolution of technical requirements related to marketing campaigns and special events. The monitoring of results also follows a pattern similar to that of high-level goals, with pools of probes and drive tests comparable to the standard procedures for obtaining the feedback. In general, the whole process is comparable to the "regular" high-level goals definition, implementation and supervision, but in particular the time scope is reduced in both planning (from one year to some months) and implementation (from several months to several weeks or even days for small optimisation tasks).

Global High-level Goals (QoE/QoS targets)

KPI thresholds

Corp

orat

e le

vel

Templates(context-dependent cell

configurations)

“Magic Triangle”

Cell configuration

Team

leve

l

Optimized by Engineer

SON

FunctionPBSM

1 Engineer handles around 100 sites (base stations)

Driven by thresholds + best effort (on top in case all

thresholds have been met)

Driven by thresholdsSpecial Events:• Additional service objectives• Special KPI target? E.g., at

mass event focus on accessibility and not throughput (usually acc. no problem)

Not necessarily a dedicated KPI target but a prioritisation, i.e., accessibility is more important than throughput

Area/region specific

Technology specific (2G/3G/4G)

Technology specific (2G/3G/4G)

Tested in test network

Templates and KPI thresholds are

developed/computed together

Selected by engineer according to concrete cell context

No SON function configurations since

this is only cell configuration but

might be starting point

Prioritisation of KPIs might not

solely be due to importance but

also ease of achievability



3.1.3 Incident Handling Some of the questions to the operators were related to the process of handling incidents in the network, i.e., the occurrence of alarms related to considerable network underperformance (related to QoS) or service failures, reported either by customers or by network operations. Such incidents, by nature, require a quick solution and these solutions are primarily based on fault management / network healing, and network configuration procedures. In case of severe outages (such as damages to the existing network) fast response equipment has to be available for emergency deployments. In case of a service alarm, the first evaluation is usually based on networks elements reporting and probe indications and is conducted by maintenance experts. Based on the results of this first evaluation the alarm is passed to the responsible experts group, depending if it is associated to the RAN segment, other network segments, or power failures, etc. According to the questionnaire answers, the operators’ experience shows that the root cause of the incidents is quite commonly assigned to the RAN segment, even though a precise percentage could not be given. It has to be taken into account that networks are usually over-dimensioned, in order to cope with the maximum load foreseen during busy hours. Therefore, bad performance is in most cases associated to a network element malfunction, and the number of network elements in the RAN is considerably much higher than in the core or transport network, leading to a higher probability of RAN network element failures. With this background information it becomes clear that in particular the approaches that have been conducted with the MD concept (and to some extent with DSS) may need to be enhanced towards providing additional features for short-term root cause analysis, in order to support the operator in identifying the reason for service underperformance and failures. While it might be difficult to overcome a network element malfunction using the PBSM features, at least those service-related issues caused by non-optimal network (or SON) configuration in today’s networks could be addressed by Integrated SON Management features. For example, by defining such incidents as part of the context information, the operator could define dedicated technical objectives for the affected areas (e.g., a changed prioritisation of the KPI targets), and the SON system would try to keep the service quality at least at a minimum level while the root cause is repaired. However, this topic of “advanced self-healing” has been out of scope in SEMAFOUR WP5, but is to be handled in future research work.

3.1.4 Conclusions SON functions are currently being introduced in the operator’s equipment, in order to optimise the network performance and diminish the OPEX associated to the network’s maintenance and optimisation. However, the configuration and tracking of these SON functions is basically included in the usual network management and performance monitoring process, e.g., by means of equipment information, probes and drive test. Presently, the operators’ feedback concerning the transformation of high level goals into technical objectives (or, at least, KPI targets) seems to be rather conservative. The transformation is addressed by the operators at senior company level, and the process itself is mainly based on expertise. In addition, the transformation process is perceived as a strategic decision with major impact on the company. Therefore, operators are usually not willing to automate this process, but rather to assign their best specialists in order to manually perform the transformation. Simulations and other computer assisted tools are only seen in a supporting role but not as being capable of an automatic transformation. The confidential nature of the high-level goals associated with network performance represents another major obstacle to the automatic transformation of high-level goals into technical objectives. A major challenge of present and future research projects on SON is therefore to convince the operators on the utility of such a transformation process. The expected large scale deployment of SON technology in the near future could shed more light on the benefit of this approach.



3.2 Operational SON Coordination From an operator point of view the network management in the context of having a SONCO present in the network requires some changes. The network operator needs a monitoring system that considers also the behaviour and the output of the SONCO. The SONCO-D (Conflict Detection, see Section 4.2.3) will provide the information on the potential and active conflicts. The network operator should plan in which way to deal with these conflicts, for example: to shut off a SON function, to trigger the SONCO-R to deal with the conflict, etc. The SONCO-R (Conflict Resolution, see Sections 4.2.1 and 4.2.2) has to receive the information on the priorities of the SON functions. A supervision and management entity should be included for the SONCO-R.

3.3 Decision Support System The DSS clearly has an impact on the processes of the operator, in particular regarding short- to mid-term network planning (cf. Section 2.3).

3.3.1 From the input perspective From the input perspective DSS depends heavily on the Monitoring and Diagnosis (MD) system (see Section 2.4), which provides the DSS with historical and forecasted traffic and performance measurement data on NE level. But, of course, DSS also needs to be fed with information coming from the network operator. In particular, the operator needs to provide DSS with information about the actual network portfolio that is available in network planning tools (base stations with their properties and configuration including their geographical locations; cells with their properties including azimuths; ...). Some of the DSS algorithms depend on clutter maps. Such maps have to be made available by the operator. All this information should be kept up-to-date, including network upgrades already planned for the future but not yet effectuated. In order to enable DSS to generate cost effective solutions for upcoming bottlenecks, the operator should also provide input to DSS on (relative) costs of potential network upgrades (equipment costs, deployment cost), constraints regarding the use of these upgrades (e.g. predefined location options for new base stations), deployment lead times, etc. Further, complementing the traffic and performance related information provided by the MD, the operator needs to feed DSS with traffic growth forecasts based on market perspectives, etc. Moreover, all this input has to be kept up-to-date. Obviously, the full potential of DSS can only be realised when operator’s processes are streamlined for providing the aforementioned information to DSS and keeping it up-to-date.

3.3.2 From the output perspective From the output perspective, the DSS will provide the operator in a timely manner with a ranked set of suitable network upgrades (‘shortlist’) that aim at solving upcoming (forecasted) bottlenecks, including a comparison of these upgrades with respect to cost, effectiveness on short and longer term, etc. These alternative solutions may still have to be further assessed by the operator, e.g. regarding actual costs and specific practical implications by taking into account more detailed information than available in DSS. This may lead to changes in the ranking of the alternatives and/or slight refinement of the finally selected upgrade alternative. Anyway, as usually high investments are involved in the deployment of network upgrades, the final decision should always be left to the operator itself.

3.4 Monitoring and Diagnosis With the MD function being an infrastructure component of the Integrated SON Management system, its impact on existing operator processes may be regarded as slim. Most of its functionalities are directed at the PBSM (e.g. cell classification and cell class statistics and performance), the DSS (time-series analyses and per-cell forecasts), or internally (data integrity and compression) such that it seldom appears visible to the operator directly. The interfaces to external entities are those for data collection and those for providing performance assessment results to the operator.



Structurally, the MD is located on top of existing PM and CM systems and it does not replace any of their functionalities. A feedback to those systems may be meaningful considering the MD’s data labelling and consolidation capabilities. These may be used to monitor the data quality of the PM systems within the OAM and help detect issues in the data collection and aggregation processes or even feedback of recovered corrupt or missing data. The other external interface provides access to statistical performance assessment results for the network operator. Users of the MD function can request network performance evaluation jobs from the MD within the context of daily network monitoring and operation. As such functionalities, however, may as well be performed on PM and CM data directly, the influence of the MD function to existing processes in this respect may be considered as additional convenience through automation.



4 Implementation According to Standards In this chapter the potential impact in terms of implementing the concepts and solutions developed within SEMAFOUR WP5 into the 3GPP Operation, Administration and Maintenance (OAM) architecture are evaluated. This evaluation is important in so far as it helps estimating the impact of the developed concepts and solutions on existing processes and tools. Furthermore, it helps estimating the potential effort regarding the development of solutions for real systems: the higher the expected effort is to standardise a solution, the longer it usually takes until it is available in the market, since a highly complex solution also causes considerable efforts for determining a compromise within standardisation. From a first glance, the following expectations regarding the severity of the 3GPP standards impact can be made: • There will be some impact by the PBSM on the 3GPP OAM architecture, as the developed

solutions work at the interface between operator and network; however, there exist different options for this implementation, and they will all be analysed. As PBSM heavily interworks with MD, these different options also have some impact on the MD requirements.

• There will be a clear impact from SONCO on the 3GPP architecture, since the performance of SON functionalities is currently analysed by 3GPP in isolation without taking into account the potential correlation between the different SON functionalities.

• For DSS there will only be little impact on 3GPP OAM architecture as the DSS system is clearly above the Itf-N interface and would be located rather closely to mid- to long-term performance management / evaluation. In so far the only requirements expected are related to some additional measurements / KPIs to be made available.

• For MD there could be a clear requirement on the 3GPP architecture in particular in terms of the availability of real-time data. This will be necessary for the MD role of providing the triggers for the PBSM Policy System, allowing the Policy System to react timely on context changes.

4.1 Policy-Based SON Management The SEMAFOUR Policy-Based SON Management (PBSM) concept, in particular, the SON Objective Manager and the Policy System components, have been described within a number of publications (e.g., [8] and [9]) and in the SEMAFOUR deliverables D5.2 [1] and D5.3 [2]. This section describes the different options to implement the PBSM System within the standardised 3GPP OAM architecture, therefore elaborates on different implementation options of PBSM under the 3GPP OAM architecture described in [10]. Figure 7 illustrates the basic domains in a 3GPP system and the related management functional areas. It also introduces Interface-N (Itf-N), which represents the standardised interface between the NE (Network Element), the OSFs (Operations System Functions), and the NM (Network Manager) /SM (Service Manager). OSFs can be used by the network- and service management systems to transfer management messages, notifications, and service management requests via the NE OSF to/from the Network Elements (NEs). Itf-N is thus the key component of the 3GPP OAM standards that hence builds the baseline for investigating the relevant PBSM implementation options.



Figure 7: Overview of 3GPP Telecom Management Domains and Itf-N

Figure 8 provides an overview about the PBSM System functional architecture with its basic components: • The central SON Management component includes the SON Objective Manager, which merges

the different input models, creates a SON Policy which is built from Event-Condition-Action (ECA) rules at design time, and stores this SON Policy into the SON Policy Database. The SON Management component includes the Policy System that at runtime decides within the Policy Decision Point if an event (e.g., a context change) and the current conditions match to one or several ECA rules, and launches the related action(s) through Policy Enforcement Point (e.g., the deployment of new SON function configurations). Furthermore, the SON Management includes the Effect Learner functionality, which allows replacing the initially provided SFMs (see below) by a model which is adapted to the actual network environment.

• The input models provided from the network operator, namely, the Context Model describing the network attributes (e.g., cell type, cell technology, cell location, busy hour definition, user mobility pattern definitions, cell load, …) and the Key Performance Indicator (KPI) targets (Technical Objectives that contain the actual definition and target values for the network KPIs). The KPI targets within the Technical Objectives may furthermore be weighted, i.e., different targets have different importance, and be dependent on context as provided within the Context Model.

• The input models provided from the SON function vendor, namely, the SFMs that contain information about the influence of a certain configuration of a SON function on certain network KPIs. In particular, the SFMs contain the available SON Function Configuration Parameter Value (SCV) Sets per SON function, and information about impact on the network KPIs for each of these SCV Sets.

• The Monitoring & Diagnosis (MD) component, providing the current status of the network in terms of Configuration Management data (CM – the current configuration of the network elements), Performance Management data (PM – the current performance status of the network through measurements, counters, timers, or KPIs), and Fault Management data (FM – errors or alarms occurring in the network). From this current status the context information relevant as input to the Policy System is taken, e.g., events and conditions. Furthermore, MD provides input to the learning component of PBSM (cf. Figure 2).

Figure 8 depicts the three different implementation options of the PBSM System that have been identified with respect to where the 3GPP SA5 standardised OAM interface Itf-N [10] could be placed.

Operations System Functions (OSF)for

Network Management and Service Management

Network Elements (NE)

OSF

User Equipment

Domain

OSF

Access Network Domain

OSF

Core Network

Service Specific Entities

OSFCore Network

Basic Entities DomainCommon

Core Network Domain

Evolved Packet Core

Packet Switched Domain

GPRS Packet

Switched Domain

Carrier Switched Domain

Itf-N



• Option 1: Itf-N between Input Models and SON Objective Manager • Option 2: Itf-N between SON Objective Manager / MD and Policy System / Network • Option 3: Itf-N between PBSM System / MD components and Network

Figure 8: The PBSM implementation options, where each red line represents the location of the

3GPP Itf-N within the respective option In the following sections, these three different options for implementing the PBSM System into the 3GPP OAM architecture are described and analysed. The 3GPP standards on which these implementation options are likely to have an impact on are explored, including potentially required enhancements to the existing standard. Based on the analysis and exploration work, the pros and cons of the presented implementation options are discussed, and, where applicable, the required standardisation contributions are discussed.

4.1.1 Option 1: Itf-N between Input Models and SON Objective Manager In this option, the PBSM System (namely, the SON Objective Manager and the Policy System as shown in Figure 8) and the MD are implemented with a vendor-specific solution below interface Itf-N. Therefore, the SON Objective Manager, the Policy System and the MD component are implemented as part of the vendor OAM domain and are not relevant to 3GPP OAM standards. However, the data provided through the Context Model, the Technical Objectives, and the SFMs need to be routed through Itf-N. The corresponding Information Object Class(es) (IOC)s and their transportation methods must be supported by Itf-N. The support can be made based on the relevant standard IOC(s) and transportation methods, if the standard(s) exist. If there are no relevant standard IOC(s) and transportation methods, the corresponding IOC(s) and their transportation methods must be proposed to 3GPP SA5 Specifications Group for standardisation. Currently, the standard 3GPP TS 32.522 [11] has defined the objective/targets, optimisation methods, architecture, etc., for several SON functions individually. These SON functions are: • Mobility Load Balancing (MLB), also denominated as Load Balancing Optimisation



• Mobility Robustness Optimisation (MRO), also denominated as Handover Parameter Optimisation • Inter-Cell Interference Control (ICIC) • Capacity and Coverage Optimisation (CCO) • Radio Access Channel Optimisation (RACH) The 3GPP defined objective/targets, optimisation methods, and architecture that could be used as the basis to support some data elements of the Context Model, the Technical Objectives, and the SFMs. At least the models of the above mentioned SON functions could be supported to some extent by the above standardised objective/targets, optimisation methods, architecture, etc. However, currently no Itf-N standard IOC(s) exists that can be used for the data elements, in particular for the Context Model and the Technical Objectives, and with respect to the current status and ongoing work within 3GPP this is not planned for the future. In addition, it would be difficult to standardise the individual Technical Objectives, Context Models, and SFMs as these always depend on the individual requirements and definitions of the operator and the SON function vendor, respectively. The Context Model and the Technical Objectives depend on the individual network layout, the (number of the) KPIs of interest, and the diversity of the KPI targets an operator is interested in. Additionally, the Context Model and the Technical Objectives may include time dependent components such as the definition of the busy hours or low traffic hours. The SFMs from different vendors are likely to differ in terms of the available SON function configuration options and the related effects on KPIs, and this may also apply even to SFMs coming from the same vendor. In summary, it is barely feasible to achieve a common and future-proof standard for all the input information required by the PBSM System, given that this standard has to be very precise in terms of the description of the individual data elements and their content. Currently, the only practical way seems to be the use of the Bulk Configuration Management (CM) Integration Reference Point (IRP) and its VsDataContainer IOC, defined in 3GPP TS 32.622 [12] and its corresponding transportation methods. The VsDataContainer managed object is a container for vendor specific data. The number of instances of the VsDataContainer can differ from vendor to vendor. This IOC shall only be used by the Bulk CM IRP for Network Resource Models (NRMs). Any Technical Objectives, Context Models, and SFMs required as input to the PBSM System can be put into the corresponding data elements of the bulk configuration files and carried downwards to the PBSM System through Itf-N. In order to exemplify how such a bulk configuration can serve the intended purpose, the data provided in Section 2.6 of SEMAFOUR deliverable D5.2 [1] can be taken as input. Using this data, the bulk configuration file containing Technical Objectives could then look like it is shown in Table 1. Note that with the PBSM conceptual updates described in D5.3 [2] and in Chapter 5, the “Target” descriptions as shown in the following tables become more complex – however, this does not impact the requirements on standardisation.

Table 1: Example of bulk configuration file elements for Technical Objectives Condition IF Target THEN Preference time in [08:00, 17:59] AND location is urban CL_MIN 1 location is urban DCR_MIN 2 time in [08:00, 17:59] HOSR_MAX 3 location is rural EC_MIN 4 time in [08:00, 17:59] CL_MIN 5 time in [00:00, 07:59] OR time in [18:00, 23:59]

EC_MIN 6

Accordingly, the bulk configuration file containing the Context Model could then look like depicted in Table 2.



Table 2: Example of bulk configuration file elements for Context Model Property Name Property Domain time [00:00, 23:59] Cell_Location {rural, urban} Cell_Type {MACRO, MICRO, PICO} Cell_Technology {2G, 3G, LTE, WiFi, FREQUENCY} Mobility_Type {STATIC_PEDESTRIAN, URBAN_SPEED, HIGH_SPEED,

HIGHWAY_SPEED } Traffic_Time {BUSY_HOUR, NORMAL_TRAFFIC, LOW_TRAFFIC,

NIGHTTIME} Energy_Saving {ALLOWED, NOT_ALLOWED} Finally, the bulk configuration file containing the SON functions models could then look like depicted in Table 3.

Table 3: Example of bulk configuration file elements for SFMs Function Name Target SCV Set MLB CL_MIN SCV of MLB_loadEqual MLB EC_MIN SCV of MLB_loadUnequal MLB HOSR_MAX SCV of MLB_handover MLB default SCV of MLB_handover CCO DCR_MIN SCV of CCO_on CCO CL_MIN SCV of CCO_off CCO default SCV of CCO_off ESM EC_MIN SCV of ESM_aggressive ESM CL_MIN SCV of ESM_passive ESM default SCV of ESM_passive MRO HOSR_MAX SCV of MRO_maxSensitive MRO DCR_MIN SCV of MRO_maxSensitive MRO CL_MIN SCV of MRO_minSensitive MRO default SCV of MRO_minSensitive Another alternative solution within this option would be to standardise the constructs of “IF-THEN-Preference” (cf. Table 1), “ContextProperty-ValueDomain” (cf. Table 2), and “FunctionName-Objective-SCVSet” (cf. Table 3), for Objective Model, Context Model, and SFM, respectively. Currently, no definition exists for any of such constructs within Itf-N, and an implementation of this alternative solution requires a prior standardisation within 3GPP. The definitions may not include the constructs with the syntax and semantics described in the tables above but rather in terms of individual parameters. For example, at first the IF condition is defined, second the THEN consequences, etc. Hence, this alternative solution is not recommended in respect of the required standardisation effort, and due to the fact that it does not bring any new benefit compared to the solution based on the Bulk CM interface. Furthermore, an alignment is required between the network operator’s systems above Itf-N and the (vendor-specific) PBSM System below Itf-N. This alignment can be made offline before the provisioning of the models through the Bulk CM interface. The alignment should allow the PBSM System of the vendor to understand the corresponding information of Context Model, Technical Objectives, and the SFMs. The standard notification mechanisms of the Bulk CM interface are used to indicate the success / failure of the corresponding bulk configuration.



Further Discussion In this implementation option, the operator only needs to get the SFMs from the SON function vendor(s), and needs to define the Technical Objectives and the Context Model. It is assumed that the SON function algorithms implemented in the network are provided by the vendors together with the SFMs. The operator does not need to know the inside details of the PBSM System with respect to the mapping between Technical Objectives and SFMs. The provisioning of Technical Objectives, Context Model and SFM to the PBSM System can be performed through the 3GPP defined Bulk CM interface. In current multi-vendor networks, network domains are usually separated by vendor, and each such domain is managed by dedicated Element Managers (EMs). An EM is usually vendor specific, and the PBSM System within Option 1 is thus part of an EM. Figure 9 shows Option 1 with a multi-vendor PBSM System implemented under the 3GPP OAM architecture and with the support of the standard interface Itf-N [10]. Nevertheless, there are some arguments against Option 1. That is, the data elements of the Objective Model, Context Model, and SFMs provided to the PBSM System require some prior alignment, for example, regarding the definition of the used KPIs or the definition of the context. The operator and the vendor of the PBSM System thus need to agree to the set of data elements and their semantics beforehand. This may be problematic in case of change to the models (e.g., in case of the deployment of a new or updated SON function, or in case of changes to the context or KPIs relevant to the operator) where an agreement cannot be reached in time.

Figure 9: Implementation Option 1 for a multi-vendor PBSM System under the 3GPP OAM

architecture, where the red line represents Itf-N In addition to the considerations regarding the SON Management implementation, there may be some issues regarding MD. According to the implementation evaluation provided in Section 4.4, the MD component is preferably implemented at the operator’s OSS level, i.e., above Itf-N. This is in particular due to the exhaustive data analysis and forecasting tasks to be done. However, from the PBSM point of view regarding Option 1, it doesn’t make sense to have the data processing tasks of MD implemented at the OSS level, but rather to have them implemented below Itf-N as part of the



vendor Element Manager domain. Otherwise, if MD is implemented completely at the OSS level, all the input required by PBSM (current context and SCV effects analyses) would also need to be routed through Itf-N. This is possible using the mechanisms described in Option 2, but makes the implementation more complex.

4.1.2 Option 2: Itf-N between SON Objective Manager and Policy System In Option 2 (see Figure 8) the PBSM System is separated through the Itf-N, with the SON Objective Manager and the MD component above Itf-N, and the Policy System being part of the vendor domain, i.e., as part of a vendor-specific Operations, Administration and Maintenance (OAM) System below interface Itf-N. This means that all functionality provided through the Policy System are not relevant to 3GPP standards. The SON Objective Manager and SON Policy (note: the SON Policy is the output generated by the SON Objective Manager and can be stored in a database) are implemented above Interface Itf-N, i.e., the data of the Context Model, the Technical Objectives, and the SFMs are provided above Itf-N. They are specific only to the operator’s OSS, and all their data formats and solution definitions are therefore not relevant to the 3GPP standards. However, the data format and content of the SON Policy need to be provided to the Policy System through Itf-N. The corresponding IOC(s) and their transportation methods must be supported by Itf-N. The support could be made based on the relevant standard IOC(s) and transportation methods, if the standard(s) existed. Currently, there is no such Itf-N standard IOC(s) that can be used for the data elements of the SON Policy, i.e., the ECA rules containing the SON Function Configuration Value (SCV) Sets. In addition, it is not feasible to standardise the individual policies as their content depends on the Technical Objectives defined by the network operators, and the Technical Objectives may therefore be based on different KPI and context definitions. Furthermore, a network operator may change his Technical Objectives over time. In brief, it is not feasible to achieve a future-proof standard for the data elements of the SON Policy. The only practical way to implement Option 2 into a 3GPP standard OAM system seems to be the use of the Bulk CM IRP and its VsDataContainer IOC, defined in 3GPP TS 32.622 [12] and its corresponding transportation methods. The VsDataContainer managed object is a container for vendor specific data. The number of instances of the VsDataContainer can differ from vendor to vendor. This IOC shall be used by the Bulk CM IRP for all the NRMs. Any SON Policy can be put into the corresponding data elements of the bulk configuration files and carried downwards from the SON Objective Manager through Itf-N to the Policy System. In order to exemplify how such a bulk configuration can serve the intended purpose, the data provided in Section 2.6 of SEMAFOUR deliverable D5.2 [1] can be taken as input. Using this data, the bulk configuration file containing the SON Policy could then look like it is shown in Table 4.

Table 4: Example of bulk configuration file elements for the SON Policy Event Condition Use SCV Set EVENT=[busy hour]

CONTEXT=[LTE, urban, normal, busy hour]

MLB_41 {CIOmax=+4dB, CIOmin=-6dB, StepSize=0.5dB, UpLimit=50%, ...}

EVENT=[normal hour]

CONTEXT=[LTE, urban, normal, normal hour]

MLB_37 {CIOmax=+3dB, CIOmin=-6dB, StepSize=1.0dB, UpLimit=30%, ...}

EVENT=[...] CONTEXT=[d1v1, d2v2, d3v1]

A17B32 {…}

... ... ... An alternative solution to using the Bulk CM IRP could be to standardise the “IF-THEN” constructs within the ECA rules of the SON Policy as they are shown in Table 4. Currently, the 3GPP OAM standards do not foresee a definition for any such kind of construct. Such a definition may not define the construct with the above syntax but rather as individual parameters. For example, it first defines the IF condition, second defines the THEN action, etc. Though, this approach does not provide any



major benefit compared to the solution based on the bulk configuration. Moreover, it needs further standardisation effort and thus faces the uncertainty if 3GPP is able to define a compromise. Furthermore, an alignment is required between the network operator’s systems above Itf-N (which contains the SON Objective Manager) and the (vendor-specific) PBSM System below Itf-N (which contains the Policy System). This alignment has to ensure that the SON Policy generated at the operator’s SON Objective Manager can be interpreted by the vendor’s Policy System, i.e., the syntax and semantics of the ECA rules must be aligned. The standard notification mechanisms of the Bulk CM interface are used to indicate the success / failure of the corresponding bulk configuration.

Standard Interface to Support Current Context Report The reporting of information about the current network context such as FM, PM and CM data, provided by the MD component as input to the Policy System (in particular, the Policy Decision Point as shown in Figure 8) must be supported by Itf-N. This context information is required to enable the Policy System to determine if events or conditions of one or several ECA rules apply, and a re-configuration action of the SON functions has to be enforced, i.e., new SCV Sets have to be deployed in the network. The PBSM System is therefore dependent on receiving the current context information from the network during network operation. There is neither an Itf-N standard IOC(s), nor a related transportation method available currently in 3GPP standards, which can be used for the data elements of all possible current context information provided through the MD component. In addition, it may be rather difficult to standardise the individual context information, since the context definition (described within the Context Model and the Technical Objectives) is likely to vary for each operator implementation of the PBSM system. Furthermore, the context definition may change over time in case an operator decides to modify the Context Model. In brief, it is rather impossible to achieve a future-proof standardisation for the context definition. The only practical way to implement the interface between MD and the Policy Decision for Option 2 into a 3GPP standard OAM system seems to be the use of the Bulk CM IRP and its VsDataContainer IOC, defined in 3GPP TS 32.622 [12] and its corresponding transportation methods. The VsDataContainer managed object is a container for vendor specific data. The number of instances of the VsDataContainer can differ from vendor to vendor. This IOC shall be used by the Bulk CM IRP for all the NRMs. Any context information can be put into the corresponding data elements of the bulk configuration files and carried downwards from the MD component through Itf-N to the Policy Decision. In fact, the approach is similar as for providing the SON Policy from the SON Objective Manager to the Policy System as described above. In order to exemplify how such a bulk configuration can serve the intended purpose, the data provided in Section 2.6 of SEMAFOUR deliverable D5.2 [1] can be taken as input. Using this data, the bulk configuration file containing the Context Report could then look like it is shown in Table 5.

Table 5: Example of the elements of a current context report file ContextID Context Report 2209 [TECHNOLOGY=LTE, TYPE=macro, LOCATION=urban,

TRAFFIC=normal, TIME=busy] 2305 [TECHNOLOGY=LTE, TYPE= micro, LOCATION=rural,

TRAFFIC=high, TIME=normal] An alternative solution to using the Bulk CM IRP could be to standardise the “Context ID – Context Report” constructs as they are shown in Table 5. Currently, the 3GPP OAM standards do not foresee a definition for any such kind of construct. Such a definition may not define the construct with the above syntax but rather as individual parameters. For example, it first defines the ContextID part, and second defines the Context Report part. Though, this approach does not provide any major benefit compared to the solution based on the bulk configuration. Moreover, it needs further standardisation effort and thus faces the uncertainty if 3GPP is able to define a compromise.



Furthermore, an alignment is required between the network operator’s systems above Itf-N (which contains the MD component) and the (vendor-specific) PBSM System below Itf-N (which contains the Policy System, in particular, the Policy Decision point). This alignment has to ensure that the current context information generated by the MD component can be interpreted by the vendor’s Policy System, i.e., the syntax and semantics of the context information must be aligned. The standard notification mechanisms of the Bulk CM interface are used to indicate the success / failure of the corresponding bulk configuration. Finally, it has to be ensured that there is no major delay between the availability of the current context at the MD component and its provisioning to the Policy System – otherwise, the reactiveness of the PBSM system would be considerably impacted, i.e., SON functions may not be re-configured timely.

Further Discussion In this implementation option, the operator needs to get the SFM(s) from the SON function vendor(s), and also define the Technical Objectives and the Context Model. It is assumed that the SON function algorithms implemented in the network are provided by the vendors together with the SFMs. The operator furthermore needs to know the syntax and semantics of the SON Policy in order to allow for an alignment of the data elements of the SON Policy with the vendor of the Policy System, but he does neither need to know the internals of the SON Objective Manager, nor the mode of operation of the Policy System. Finally, the operator needs to know about the syntax and semantics of the current context information (which should be the case as the Context Model is generated by the operator). In current multi-vendor networks, network domains are usually separated by vendor, and each such domain is managed by dedicated EMs. An EM is usually vendor specific, and the Policy System within Option 2 is thus part of an EM. Figure 10 shows Option 2 with a multi-vendor PBSM System implemented under the 3GPP OAM architecture and with the support of the standard interface Itf-N [10].


architecture, where the red line represents Itf-N



Nevertheless, there are some cons in implementing Option 2. That is, the data elements of the SON Policy provided by the operator (as output of the SON Objective Manager) must be understood by the (vendor-specific) Policy System. This also applies to the output of the current context information provided through the MD component. The operator and the vendor of the Policy System thus need to agree to the definition of the data elements, i.e., their syntax and semantics beforehand. While this can be performed in terms of an implementation project, every change to the data elements (not their content, but to syntax and semantics) would require an update of the standardisation. Furthermore, in particular the provisioning of the current context information to the Policy System (the Policy Decision point) is time sensitive, as a severe delay in providing this information automatically leads to a delay in reconfiguring the SON functions according to the changed context. It has also to be considered that in a large system with lots of relevant context defined, such context may need to be provided rather frequently, which may lead to considerable load of the OAM interface. In summary, the context provisioning is seen as the major drawback of this Implementation Option 2.

4.1.3 Option 3: Itf-N between PBSM System / MD components and Network In Option 3 (see Figure 8), the complete PBSM System is implemented above Itf-N as part of an operator-specific OSS solution. For this reason, there is neither a 3GPP standardisation relevance for any functions and interfaces within the PBSM System, i.e., between SON Objective Manager and the Policy System, nor for the interfaces required to provide the input models (Context Model, Technical Objectives, SFMs) to the PBSM System. Furthermore, in difference to Option 2, as the Policy System is also an integral part of the operator’s OSS, the data exchange between MD and the Policy System (the information on the current context) has no 3GPP standardisation relevance. Thus, the PBSM System, the MD component, the corresponding OSS internal interfaces between the components, and the model solutions, data format (syntax, semantics) and content can be defined according to the requirements of the operator or through the vendor of the corresponding OSS solution. However, the specific SCV Sets generated by the Policy System need to be provided to the SON functions through Itf-N as shown in Figure 8. The corresponding IOC(s) and their transportation methods must be supported by Itf-N. The support could be made based on the relevant standard IOC(s) and transportation methods, if the standard(s) exist. There is currently no Itf-N standard IOC(s) available that can be used for the data elements of all possible SCV Sets to be deployed from the PBSM System to the SON functions. It would be difficult to standardise the individual SCV Sets as they depend on the individual implementation of the SON functions operating in the network. In particular with respect to multi-vendor implementations where different instances of the same SON function (e.g., MLB) are provided by different vendors, also the number and type of the SON Function Configuration Parameters and hence the available SCV Sets may strongly differ. In fact, a standardisation of the SCV Sets would lead to a full standardisation of the SON functions. With this background, the only practical way to provide SCV Sets via the Itf-N to the SON functions seems to be the use of the Bulk CM IRP and its VsDataContainer IOC, defined in TS32.622 [12] and its corresponding transportation methods. The VsDataContainer managed object is a container for vendor specific data. The number of instances of the VsDataContainer can differ from vendor to vendor. This IOC shall only be used by the Bulk CM IRP for all the NRMs. Any SCV Sets can be put into the corresponding data elements of the bulk configuration files and carried downwards from the PBSM System through Itf-N to the SON functions. In order to exemplify how such a bulk configuration can serve the intended purpose, the data provided in Section 2.6 of SEMAFOUR deliverable D5.2 [1] can be taken as input. Using this data, the bulk configuration file containing an SCV Set could then look like it is shown in Table 6.

Table 6: Example of bulk configuration file elements for SCV Sets FunctionID InstanceID SCV Set MLB 1203 {CIOmax=+4dB, CIOmin=-6dB, StepSize=0.5dB,

UpLimit=50%, ...}



An alternative solution to using the Bulk CM IRP could be to standardise the “FunctionID-InstanceID-SCV Set” constructs as shown in Table 6 for the SCV Sets. Currently, the 3GPP OAM standards do not foresee a definition for any such kind of construct. Such a definition may not define the construct with the above syntax but rather as individual parameters. For example, it first defines the FunctionID, second defines the InstanceID, and finally defines the SCV Sets. Though, this approach does not provide any major benefit compared to the solution based on the bulk configuration. Moreover, it needs further standardisation effort and thus faces the uncertainty if 3GPP is able to define a compromise. Furthermore, an alignment is required between the operator’s PBSM System above Itf-N and the (vendor-specific) SON functions below Itf-N. This alignment has to ensure that the SCV Sets deployed by the Policy Enforcement as part of the operator’s PBSM System can be correctly interpreted by the vendor’s SON functions, i.e., the syntax, semantics and content of the SCV Sets must be aligned. The standard notification mechanisms of the Bulk CM interface are used to indicate the success / failure of the corresponding bulk configuration. This alignment is, however, not seen as a major issue since the SCV Sets are provided as input to the PBSM System through the SFMs, and these will in turn be provided by the vendor of the SON functions. The PBSM System (in particular, the SON Objective Manager) does not modify the SCV Sets but just merges them unchanged into the SON Policy.

Standard Interface to Support the Context Collection The collection of PM, CM and FM data from the network during operation as input to the MD component has to be supported by Itf-N (as shown in Figure 8). By analysing the received data the MD component can determine the current context which is relevant as input to the PBSM System, in particular, the Policy Decision Point. 3GPP foresees a large number of standard information elements for PM, CM and FM to be exchanged via Itf-N, as these are major or even mandatory components of the overall OAM system for mobile radio networks, for example, TS 32.425 [13] and TS 32.450 [14] for PM. It can be assumed that this data available from the network, or the vendor-specific EMs, respectively, is sufficient for the MD component to determine the required context information. If there is additional data required, for example, considering network planning data from within the operator’s organisation, this is regarded of being out of scope for the study on implementation options. Note: in particular regarding PM data, many operators have specific requirements on dedicated counters, measurements, timers, etc., that are to be provided by the network elements and the corresponding EMs towards the operator’s OSS. The reason behind is that the 3GPP standardised PM data (including KPIs) only represents an absolute basic set, but does not fulfil the requirements on the degree of detail requested by the operators. For this reason there are lots of non-standard, but operator- / project-specific PM data exchanged via Itf-N using the File Transfer IRP and its IOC, defined in TS32.342 [15]. With respect to the requirements of the PBSM System and the MD component, there is, however, one major issue – the current PM system implementations (independent from the fact that this can be standard PM data or operator- / project-specific PM data) do not foresee the provisioning of real-time PM data. This may have an impact on the reactiveness of the PBSM system to context changes, for example, in case the relevant “current” context information can only be provided every 15 or 30 minutes. While efforts to standardise solutions for real-time PM have been ongoing for some years now, there is no such solution available yet.

Further Discussion For this implementation option, the complete PBSM System together with the MD component(s) and the required input models (Technical Objectives, Context Model, and SFM) are located within the operator-specific OSS. The operator needs to get the SFM(s) from the SON function vendor(s), and needs to define the Technical Objectives and the Context Model. It is assumed that the SON function algorithms implemented in the network are provided by the vendors together with their SFMs. It is furthermore assumed that the PM, CM and FM data available from the vendor-specific EM systems as input to the MD component is sufficient for generating the current context information as input to the PBSM System. The operator can therefore define the requirements on the system internal interfaces



depending on his own needs, and he does even not need to know about the inside details of the PBSM System and the MD component. The information which is to be exchanged via the Itf-N includes the SCV Sets, provided by the PBSM System to the SON functions which are implemented in the network, and furthermore the PM, CM and FM data provided through the EMs towards the MD component. There is no major issue seen for the SCV Sets as they will be provided by the vendor of the SON functions through the corresponding SFMs (and the Bulk CM IOC can be easily used). Furthermore, there is no major issue seen for the PM, CM and FM data as these are already intrinsic part of the existing 3GPP OAM standards. However, some drawbacks may occur from the capabilities of existing PM systems, in particular with respect to their real-time capabilities. Since the impact on the 3GPP Itf-N is seen as rather low within Option 3, or the existing mechanisms can be used for the purpose of SON Management, the major responsibility for enabling the overall functionality of SON Management is now with the operator. Since the different components of SON Management, namely, the SON Objective Manager, The Policy System, the MD, and finally the different input models (SFM, Technical Objective, and Context Model) may be provided by different vendors, ensuring a proper interworking can be a challenge. Regarding a functional view for a multi-vendor implementation of Option 3, Figure 11 shows an example with two different vendor domains in the network. The Policy System implemented is capable of interpreting the SON Policy in a vendor-independent way, i.e., the SCV Sets contained in the ECA rules can be provided to the appropriate (vendor) SON functions. The MD component is connected via Itf-N to the vendors’ EM systems [10] in order to receive the PM, CM and FM data. Note: Since the SCV Sets to be deployed to the SON functions operating in the network are vendor specific, one Policy System per vendor domain may be required (however, as part of the operator domain above Itf-N) in order to ensure that each SON function is only configured with the appropriate SCV Sets.


architecture, where the red line represents Itf-N



4.1.4 Conclusions This section identifies and analyses three different implementation options for the components of the Integrated SON Management system that has been developed within the SEMAFOUR projects (see [8], [9], [1], [2]) into the standardised 3GPP OAM architecture, in particular with respect to the impact on the Itf-N. The components are: • The SON Objective Manager • The Policy System • The MD component • The input models (SFM, Technical Objectives, Context Model) Regarding the implementation of the three options, the following conclusions are drawn: • Option 1 (Itf-N between SON Objective Manager and Technical Objectives / SFMs). This option

seems to be feasible in terms of providing the different input models (Technical Objectives, SFMs, and Context Model) via Itf-N to the PBSM System, as the 3GPP Bulk CM mechanisms can be used. However, a prior alignment of these input models is required in order to ensure that the same definitions for KPIs and context are used within the models.

• Option 2 (Itf-N between SON Objective Manager / MD component and Policy System). This option seems to be feasible in terms of providing the SON Policy created by the SON Objective Manager, and the current context information provided through the MD component, via Itf-N to the Policy System, as the 3GPP Bulk CM mechanisms can be used. However, a strong alignment between the SON Policy creation and the context definition on the one side, and the SON Policy and current context interpretation on the other side needs to be ensured. This may be difficult in particular for multi-vendor SON system implementations. Furthermore, the timing requirements for the context information are unclear and may be a further drawback.

• Option 3 (Itf-N between PBSM System / MD components and Network). This option seems to be feasible in terms of providing the output of the PBSM System, namely, the SCV Sets, via Itf-N to the SON functions operational in the network (using the 3GPP Bulk CM mechanisms), and providing the required network status (in terms of PM, CM and FM data) to the MD component by using the corresponding standard mechanisms. This option has the lowest impact on Itf-N, however, puts a high responsibility on the operator in terms of ensuring the interworking of the different SON Management components.

Taking the above summary for the three implementation options, Option 1 and Option 3 are likely to be the easiest to implement. In Option 1 the major part of SON Management is included in the vendor domain below Itf-N (i.e., as components of the vendor-specific Element Management System). As an effect, in a multi-vendor environment, each vendor domain brings its own SON Management solution. This may have an impact on the usability of SON Management, since most likely different user interfaces for these vendor-specific SON Management Systems will be provided. In Option 3 the complete SON Management is included in the operator domain above Itf-N (i.e., as components of the operator’s OSS). From a usability point of view, this solution could provide a single SON Management user interface towards the operator, even within a multi-vendor environment, which clearly simplifies the simultaneous instrumentation and operation of several independent SON functions

4.2 Operational SON Coordination The SONCO is needed if several SON functions in the network may conflict. The architecture presented in 3GPP TS 28.628 [16] is outlined in Figure 12, where the SONCO functionality is located above the Itf-N. In this section, several implementations, based on the scenarios considered in the project, are provided. The focus is thereby on the SONCO-D (Conflict Detection) and the SONCO-R (Conflict Resolution), see also Section 2.2.



NM

DM

EM

eNB eNB EMX2 X2

SON_X

SON_Y

SON_A SON_C

SONCOFunction

eNB

SON_B

Itf.-N

Figure 12: SON Coordination function located in NM ([16])

4.2.1 SONCO-R in a HetNet Scenario For this implementation, the HetNet scenario described in [6] is used. We consider that the Pico cells act as “slaves” of the Macro cell, i.e., they are meant to help the macro cell by providing additional coverage and capacity (Note that this is a dedicated scenario used within the SONCO development work – according to 3GPP standards there is currently no “master-slave” setup between different cell types foreseen; however, a scenario where Pico cells act as supporting nodes to Macro cells using the standard X2 communication is possible, cf. also Table 7). Thus, cell clusters composed by a macro cell and its slave Pico cells are considered, each cell cluster led by its macro cell. Thus in this scenario it has been proposed that each SONCO-R instance governs independently a cell cluster, and the SONCO-R instance will be running on the Macro cell/eNB. The SON functions on the Macro cell can communicate directly with the SONCO-R while the ones on the slave Pico cells can communicate via the X2 interface. It is expected the SONCO-R response time to be very short due to the limited scope -area. Obviously, this is valid if the scope of the SON functions is limited to one cell cluster. The SONCO-R agents have to collect the necessary information and ensure that it gets to the corresponding SONCO-R Algorithm.

NM

DM EM

eNB(Macro) eNB(Pico) EMX2 X2

SON_A SON_CSONCO-R Agent

SONCO-RAlgorithm

eNB (Pico)

SON_BSONCO -R

Agent

Itf.-N

SONCO-R Agent

Figure 13: SONCO-R in the EM

The messages required to make this happen are summarised in Table 7. The “SON weights/priorities” and the “List of active conflicts” only have to be transferred via Itf-N in case SONCO-R and PBSM are on different sides of Itf-N.



Table 7: Required messages for SONCO-R in HetNet scenario Message content Interface from to List of active conflicts SONCO-D PBSM, SONCO-R

(Itf-N) SONCO-D or PBSM SONCO-R SON weights/priorities (Itf-N) PBSM SONCO-R Update requests X2 SON SONCO-R Accept/deny SON update requests X2 SONCO-R SON

4.2.2 SONCO-R in a Macro-Only Scenario For this implementation the Macro scenario described in [17] is used. The scope area might be very large and thus (normally) as the accept/deny update request decision is centralised it has to be taken higher up the hierarchy, i.e. above the Itf-N. The SONCO-R agents have to collect the necessary information from the SON function and forward it to the corresponding SONCO-R algorithm. The Itf-N has to be able to sustain this forwarding. The employed SON functions send update requests every 5 minutes. Thus, at this time scale, feeding information to the SONCO-R in the NM should not be a problem.

NM

DM

EM

eNB eNB EMX2 X2

SON_X

SON_Y

SON_A SON_CSONCO-R

Agent

SONCO-RAlgorithm

eNB

SON_BSONCO-R

Agent

Itf.-N

SONCO-R Agent

SONCO-R Agent

SONCO-R Agent

Figure 14: SONCO-R in the NM

The messages required to make this happen are summarised in Table 8. The “SON weights/priorities” only has to be transferred via Itf-N in case SONCO-R and PBSM are on different sides of Itf-N.

Table 8: Required messages for SONCO-R in Macro-Only scenario Message content Interface From to list of active conflicts SONCO-D PBSM, SONCO-R SON weights/priorities

(Itf-N) SONCO-D or PBSM SONCO-R (Itf-N) PBSM SONCO-R

update requests Itf-N SON SONCO-R accept/deny SON update requests Itf-N SONCO-R SON

4.2.3 SONCO-D For this implementation the HetNet scenario [5] is used. The Pico cells act as slaves of the Macro cell, i.e., they are meant to help the macro cell by providing additional coverage and capacity. Thus cell clusters are composed by a macro cell and its slave Pico cells. With the SONCO-D the only focus is on diagnosing measurement conflicts. Parameter conflicts are straightforward, i.e., they only identify opposite requests.



The SONCO-D agents collect information about the network symptoms (e.g. KPIs). This information is forwarded to the SONCO-D algorithm, which will output a potential cause (malicious SON function). Initially the SONCO-D has to learn the diagnosis model. Thus, several manual diagnoses have to be performed. After, when testing the diagnosis model, the SONCO-D will provide a potential cause given some symptoms. Consequently, some measures have to be taken to deal with the network fault. If the measures corresponding to the cause are efficient, i.e., if the fault disappears the diagnosis is correct, otherwise it is wrong. This feedback has to be provided to the SONCO-D in order to update the diagnosis model.

NM

DM

EM

eNB(Macro) eNB (Pico) EMX2 X2

SON_X

SON_Y

SON_A SON_C

SONCO-D Agent

eNB (Pico)

SON_B

Itf.-N

SONCO-D Agent

SONCO-DAlgorithm

SONCO-D Agent

SONCO-D Agent

SONCO-D Agent

Figure 15: SONCO-D in the NM

The messages required to make this happen are summarised in Table 9. The “List of active conflicts” and the “List of SONs turned on” only have to be transferred via Itf-N in case SONCO-D and PBSM are on different sides of Itf-N.

Table 9: Required messages for SONCO-D Message content Interface from to KPIs Itf-N Network, MD SONCO-D Alg. List of active conflicts SONCO-D PBSM, SONCO-R

(Itf-N) SONCO-D or PBSM SONCO-R List of SONs turned on (=causes) (Itf-N) PBSM SONCO-D

4.3 Decision Support System From the current perspective, and regarding the concept developed within SEMAFOUR WP5, there is no necessity foreseen to standardise components or interfaces related to the Decision Support System. With respect to the input and output interfaces to the DSS component, which might be relevant for the 3GPP standardised Itf-N interface, the estimation of WP5 is as follows: • Input to the DSS component: The relation of the DSS to the OAM systems is represented through

the interface towards the MD component only (see Section 4.4). As the MD (at least the data analysis part which provides the relevant input to DSS) is located within the operator domain, like the DSS, i.e., both are “above” the Itf-N, there is no standardisation relevance seen for this interface as it is located within the operator domain only.

• Output of the DSS component: The data provided as output of the DSS towards the operator is expected to serve as direct input to network planning tools. Both, the DSS and network planning tools are seen as components of the operator domain within the OAM system, which is “above” Itf-N. In so far, there is no standardisation relevance seen for the DSS output interface.



4.4 Monitoring and Diagnosis

4.4.1 Localisation in the Network Management System The tasks of the MD function may be roughly divided into three parts: • data collection • data consolidation • data analysis The MD function centralises statistical data processing services and holds a database of network performance and configuration data that is relevant for its services to the Integrated SON Management system. The MD’s network intelligence is focused on data at KPI level, i.e. already aggregated raw performance counters. Concerning the data analysis part, the MD interfaces to the PBSM (cell characterisation, classification and performance, notifications), the DSS (per-cell traffic forecasts), and the operator (reports). While the forecasting services for the DSS may be performed solely on PM data of individual cells and thus may run in a distributed setting, more reliable forecasts can be achieved when taking contextual information and cell coupling into account. In particular the performance assessment functionalities including the cell classifications require the MD to be situated at a high level in the OSS within the operator domain, where global network performance data is available from the PM and CM databases, see Figure 16. The natural location of such centralised statistical network intelligence functionality is therefore within the operator’s network management. In case of Implementation Option 2 (according to the standardisation requirements discussed in Section 4.1.2), the PBSM policy decision point is located within the vendor domain and retrieves network context information from the MD. Next to the interfaces to the PBSM and the DSS, no link to network entities in the vendor domain is necessary for MD data analysis functions. In particular, all interfaces lie within the operator-specific domain and there are no requirements for Itf-N specifications. In Section 4.1.1, an implementation option for the PBSM (Option 1) is described that requires the MD function to be located completely within the vendor domain. In this situation, the data collection part of the MD would be located within the vendor domain as well such that network performance and configuration data could be collected directly at element manager level (or even from network elements). This would bypass the real-time performance measurement issues discussed below. On the other hand, the interface between MD and DSS would cross Itf-N and then needed standardisation efforts. The processing logic of the MD function requires the DSS to provide information about the processing job to be executed. Such job requests would have to be subject to standardisation, for example, through the definition of dedicated IOC(s) or by using the Bulk CM interface (cf. Section 4.1.1 – note: the same argumentation as for PBSM is valid here). The results of the processing job are then retrieved using a pull request. In the case of the DSS, the results are network performance forecasts in the form of time-series with respect to KPI values per cell and would need to be standardised as well. In multi-vendor networks, network domains are usually separated by vendors, each domains being managed by dedicated element managers. In this case, MD functions would be vendor-specific as well, such that interfaces towards the PBSM would need to be closely aligned. Moreover, complex correlations required for generating performance forecasts could only take data from one network domain into account, which could result in reduced accuracy. The data consolidation part of the MD function is concerned with ensuring data integrity of the performance and configuration data that it bases its analysis upon. It therefore has the same location within the OAM as the data analysis part, namely the network manager. Recovered missing or corrupt data may be fed back into PM systems in order to detect issues within the existing data collection and aggregation mechanisms. Apart from that, the data consolidation part does not link to any other 3GPP entity. The situation is different with the data collection part of the MD. Due to different requirements on timeliness of the availability of analysis results for the various MD services, it may be insufficient to solely rely on existing PM and CM databases as data sources, see Section 4.4.2. For services that are



not time critical, a direct link to PM and CM systems within the operator domain, i.e. above the Itf-N, is sufficient to provide the necessary performance and configuration data. Such systems usually have a delay in reporting that make them unsuitable for time critical tasks. This delay is composed of the usual PM reporting period granularity (which is mostly above 5 minutes at least) and an aggregation time in which performance data from several cells below a domain/element manager are combined into aggregated measurement reports. This aggregation time depends on the processing power at element management system level and the bandwidth available to transmit the collected data both from network elements to element managers as well as from element managers into the network management system. In particular, in times of high load in the network this time increases as both bandwidth and processing power are shared with the actual operation of the network. For tasks that rely on timeliness of the available performance data, such as notifications towards the PBSM Policy Decision Point on changes in cell contexts or performance leading to a change in the chosen SCV Set, existing PM systems are not suitable and faster systems are necessary. There has been research done on real time performance management for mobile networks that may be applied within the context of automated network intelligence of the MD function. In [18], a policy based approach to real time performance management is investigated that aims at reducing required processing power and bandwidth for performance monitoring by usage of a policy based Real Time Performance Management System at element management level. The idea is to focus performance monitoring on a basic network overview with long granularity periods as long as the network operates in a non-critical state. As soon as parts of the network exhibit unusual behaviour indicating a critical situation, additional measurement jobs are spawned and the granularity of measurements in that region is increased based on instructions coming from an event-condition-action Policy System. At a higher level, such an approach is also described in D5.1 [4] for the processing logic of the MD function that only collects data that is required for the tasks registered at the MD. A combination of both approaches could considerably reduce the stress that the data collection imposes on the network and thus enable lower reporting delays.

Figure 16: Location of the MD in the 3GPP OAM architecture

A more direct approach to real time performance measurements is described in [19]. There, based on an open CORBA interface for performance management, a system of agents acting at different layers of the cellular network hierarchy is discussed. Those agents collect measurements at the lowest layer and pass them upwards to other agents that aggregate the data, perform suitable statistics, and then pass the results further upwards for further processing. Each agent subscribes at an agent of a lower



layer or at a network element directly for a so-called monitoring task. The data that is being sent upwards is limited to what monitoring task the receiving agent has subscribed for. In the other direction, agents can be configured using so-called control tasks that are passed downwards. In the context of the MD function, such an approach would mean that the MD function would subscribe for monitoring jobs at the distributed agents (see Figure 16) that cover only those KPIs and counters that are required for time critical services. This means, that instead of broadly gathering a wide spectrum of performance data at a high granularity and hence introducing a high bandwidth requirement for performance monitoring, the MD function could precisely monitor critical KPIs, keeping the additional stress to the network at a minimum.

4.4.2 Time Criticality In Section 4.4.1 it was described that policy based and distributed performance monitoring may be approaches to reduce delays in the reporting of performance counters and KPIs. In this section, each of the MD’s functionalities is investigated in terms of how time critical the tasks are.

4.4.2.1 Services to the PBSM The MD performs several tasks that are dedicated to the Policy Based SON Management System concerning the provision of network status, context, and performance.

Cell Context Attribute Identification The PBSM SON Objective Manager selects for each cell individually SCV Sets that best suit the cell within its operating environment. For that, it relies on classification of cells based on so-called context attributes. These context attributes are meant to give an abstract description of the type of cell, its role in the network, and the environment it operates in. Examples for such context attributes are the technology (e.g. LTE), size (e.g. micro cell), its mobility type (e.g. whether it serves mostly highly mobile or immobile users), or the land use composition of its environment (e.g. rural or urban cell). Such classification may rely on historical performance data as well as planning data as has been described in D5.3 [2]. Since the network topology changes on time-scales of days rather than seconds, the context attribute identification task has low time criticalness.

Cell Class Generation and Supervision The PBSM abstracts the SCV Set selection process by using cell classes instead of deciding on SCV Sets per cell individually. This has the advantage of a more lightweight system for which the policy rules that need to be generated are still manually manageable. The classification of a cell is based on the context attributes described in the previous paragraph. The aim is to use classes of cells that exhibit similar behaviour in similar situations, i.e. show similar performance data. Similarity here is defined using statistical quantities such as variances, see D5.3 [2] . The determination of suitable cell classes with low variances and their quality supervision is an MD task that needs to be performed each time the context of cells change considerably. With the same arguments as in the previous paragraph, changes in the network topology and hence in cells’ contexts appear at larger time-scales, such that this task can be considered to have low time criticalness.

Cell Class Statistics and Performance In order to estimate the expected gains and losses when the PBSM chooses different SCV Sets, statistics are used on historical performance measurements for each of the found cell classes. With a well-chosen cell class, it is expected that such a statistic gives a good estimation of the behaviour of the included cells. The computation of the cell class statistics happens when a significant amount of new performance data has been gathered such that the performance expectation of the individual cell classes should be updated. This may be done in periodic intervals at time-scales of hours, days, or even weeks depending on how quickly the network is evolving. With this in mind, the computation of cell class statistics and performance is not to be considered time critical.

Notifications for Policy Decision Point The PBSM Policy Decision Point is responsible for deciding which cell is to be equipped with which SCV Set. In the context of the classification of cells the SCV Sets are chosen uniformly within cell



classes. This means that for an individual cell the decision about a suitable SCV Set can be made by assigning the cell to one of the cell classes. Apart from the slowly changing context attributes that are described in the above paragraph, there are parameters describing the cell class that change more frequently such as whether the cell is currently operating in a busy hour or not. These context parameters may change much more rapidly and call for low latency performance management. The time criticalness for this task is high.

4.4.2.2 Services to the DSS The MD function provides performance forecasts at cell level to the DSS as input to its network evolution investigations. This may include time series analyses as well as cell level predictions of parameters using regression trees, see D5.3 [2], DSS chapter. The temporal scope of the DSS investigations is several weeks up to several months. Due to this large temporal scope, the usual reporting delay in existing PM and CM systems does not pose any problems to the MD services towards the DSS. The time criticalness is considered low.

4.4.2.3 Services to the SONCO-D It is the task of the SONCO-D to detect conflicts between SON function that are active in the network and as far as possible, find reasons for them. There are different kinds of conflicts that can be detected and that have different effects in the network. In particular, measurement conflicts often result in oscillations in network performance parameters. In order to detect such conflicts, historical performance measurements need to be analysed. The MD function may support the SONCO in this regard by using time series analyses to find out oscillatory behaviour in KPIs. Since the SONCO needs to timely react to conflicting SON functions, the usual reporting delay of many minutes can be too long to effectively resolve the conflict in a timely way. It is therefore important for these data to be collected with low latency. The time criticalness for this task is high.

4.4.3 Communication Volume Above Itf-N, the performance measurements are not time critical and therefore, higher communication volume can be dealt with by longer transfer times. For time critical data, however, the amount of data to be transferred from monitoring agents deployed on network elements to the MD may impact and be impacted by backhaul capacity and cell loads (as they usually share the same data connections as user traffic). The processing logic of the MD makes sure that only KPIs that are required by the respective measurement jobs that are registered at the MD are requested. This means that communication volume is kept at a minimum. The communication volume required by the various MD tasks differs. For the context attribute identification as well as the cell class definition and supervision, large quantities of data are necessary to guarantee statistically significant decisions of the algorithms. These data, however, can be collected from the PM and CM systems without additional requirements for the existing monitoring system. Also, they can be processed MD-internally and only the results need to be passed on to the PBSM. These results consist of a set of attributes per cell and descriptions of several cell classes in terms of context parameters. The communication volume towards the PBSM for these tasks is hence considered low volume, especially due to the fact that they only need to be computed seldom. The same holds true for cell class statistics and performance, for which most of the computation can be performed within the MD function, and merely the resulting performance values per cell class need to be transported to the PBSM. The time critical task of providing the PBSM Policy Decision Point with the information about changing cell context might pose a communication volume bottleneck if the KPI data were transferred completely to the MD continuously. The Policy Decision Point works with triggers and thresholds and only the information that these thresholds are exceeded is necessary. Using a policy based performance monitoring paired with distributed monitoring agents as described in Section 4.4.1 provides the possibility to reduce the communication volume to a minimum. The monitoring agents are configured with policies that only activate detailed performance monitoring once the critical regions for the PBSM decisions are reached. This way, only data that is relevant for the Policy Decision Point’s SCV Set choices is being transferred towards the MD. The communication from the



MD towards the PBSM can be restricted to simple notifications that registered thresholds are exceeded. In order to carry out DSS performance forecasts, a large amount of performance data is required from the PM and CM systems. Due to the fact that these forecasts need to be computed only rarely (once per night or even only once per week), the required communication volume both from the PM and CM systems towards the MD function as well as from the MD function towards the DSS is considered low. For the oscillation detection services of the SONCO-D, the communication volume might have a stronger impact on the network. In order to detect oscillations in the data, whole time series need to be analysed. This means that, in contrast to the service for the PBSM Policy Decision Point described above, whole datasets need to be communicated while at the same time the data needs to be available with low latency. Table 10 provides an overview about the MD requirements regarding communication latency and communication volume as described in Section 4.4.2 and Section 4.4.3.

Table 10: Communication latency requirements and volume Task Context

Attributes Class Definition

Class Statistics

Policy Decision

DSS Forecasts

SONCO-D Oscillations

Latency Low Low Low High Low High Volume Low Medium High Low/Medium High High



Part II: Complementary Development Results Despite the delivery of SEMAFOUR D5.3 [2] that intended to describe the major results of the research, development and implementation work of the four components of Integrated SON Management, there have been ongoing activities for some of the aspects, in particular, PBSM, SONCO and DSS, after the finalisation of D5.3. The conceptual enhancements and additional findings and results are described in the following chapters.



5 Policy-Based SON Management

5.1 Introduction In its basic version as described in D5.1 [4], Policy-Based SON Management (PBSM) focuses on provisioning SON Function Configuration Values (SCVs) to all SON function instances. Configuration values for the specific SON function instance are derived on the basis of the SON Policy. The update or improvement of the SON Policy based on network performance is not foreseen in this basic version. In a more advanced version, the policy rules shall be updated every now and then in order to maximise the alignment of observed network performance with the operator's performance targets. In the following, we will propose a scheme according to which policy rules can be optimised. It is proposed to use a simple local optimisation for updating policy rules, which first checks whether the observed network performance is in line with the operator's targets. If this is not the case, alternative SCVs shall be determined (and the policy will be updated accordingly). The presented evolution of PBSM is to establish the procedures on how to determine the alternative configuration values. It is assumed that the SON function vendor supplies a SON Function Model (SFM). This model relates network performance indicators to the SCVs (likely based on simulations). The SFM is used in order to optimise the configuration values of the SON functions itself. First, it is estimated in which way the performance of the actual network is likely to change if the current set of configuration values is replaced by another (Section “SCV Set statistics”). Subsequently, the estimated impact to the discrepancy of the observed network performance is compared with the desired performance (Section “SCV Set delta determination”), and finally the configuration values which best matches the desired changes in the network performance (Section “SCV Set filtering” and “SCV Set selection”) are picked out. That is, the procedure relies on the assumption that the SFM is qualitatively sound (i.e., predicts well the direction in which moving from one configuration value set to another will impact the performance indicators). However, the proposed procedure does not depend on the assumption that the model also quantitatively predicts the changes well (i.e., predicts well the values of performance indicators in moving from one configuration value set to another). Beyond the basic idea of using the vendor supplied SFM merely qualitatively, it will also be explained how to use multiple models for the same SON function. One option may indeed be to learn a SFM over time by observing the network performance for various configuration values of the SON function. In this case, the model might be considered not only as qualitatively, but also as quantitatively faithful. In this setting, it is proposed to combine the estimates of the impact of configuration value changes from the models available in a way that takes their (expected) qualitative and quantitative faithfulness into account (Section “KPI measurements selection”). The vendor of SON functions will provide SFMs that indicate the expected KPIs of a network if a certain set is chosen. These models will most likely be generated in a simulation environment (no real data) or derived from observations in some trial / reference network (real data, but from a different environment). The operator has KPI measurements, which come directly from the own (network) system and can also be seen as a model. The main challenge is to bring all KPI sources in a context that enables sophisticated decision-making by replacing the SFMs with real network measurements over time (see Figure 17). Another concern is bringing together operator objectives with SFMs and finding the optimal SCV Set out of it. This is a non-trivial task, since, on the one hand, operator objectives describe KPI targets that should be achieved independent of current KPI values and, on the other hand, the SFM and real KPI measurements describe the effect on KPIs coming from different situations and thus make a comparison difficult.



Figure 17: Various KPI sources in a live network with a deployed PBSM system

5.2 SON Management – Final Results

5.2.1 Input models As for previous versions of the PBSM concept (cf. D5.2 [1] and D5.3 [2]), the mechanisms for PBSM incorporates several input models. Such models include the Context Model, which describes the network with a set of available cell attributes, the Objective Model and the SFMs. For the latter model a whole new concept has been developed in which SON function can be described three-folded: a set of measurements that are coming from the live network operation, data that has been collected in simulations and the known SFMs which will be, most likely, provided by the vendor of such SON functions. The different models will be briefly described in the following, with focus on progress beyond the detailed descriptions that can be found in D5.1 [4], D5.2 [1] and D5.3 [2].

5.2.1.1 Context Model The Context Model that describes the network and especially the considered cell classes has been defined on the basis of [20]. Cell classes have been formulated for LTE and Wi-Fi cells with two different mobility profiles (normal and high-speed users), two different cell types (micro and macro), two cell location areas (rural and urban) and a traffic type that differentiates between normal and buys hour based on the average cell loads. The actual implementation is the same as described in D5.3 [2].



5.2.1.2 Objective Model An operator can express requirements about the performance of the mobile network by means of technical objectives. This information is given as condition-action-rules in the Objective Model. These rules have the following general form:

IF cell class THEN KPI target WITH weight

Assuming an operator has defined the same objectives for all cells in a cell class, then the context can be defined in terms of cell classes. A “KPI target” defines a threshold for a KPI the system should achieve. Finally, the “weight” indicates the importance of achieving a KPI target compared to other KPI targets and thus allows to trade-off the objectives against each other if they cannot be satisfied simultaneously. A weight is a real number between 0 and 1. An Objective Model may contain different objective sets where each set aims at achieving a more abstract goal such as ‘robustness of the network’ or ‘performance of the cells in the network’ which can be enforced by assigning higher weights to certain KPIs and defining more strict KPI targets. An exemplary objective set is given in Table 11 where each line represents one objective rule. Please note that the “Resource Efficiency” here is the ratio between cell throughput and cell load.

Table 11: Example Objective Set Cell Class KPI Target Weight CLASS_001_NORMAL Drop Call Rate < 0.03 0.4 CLASS_001_NORMAL Short Stay Rate < 0.2 CLASS_001_NORMAL Resource Efficiency > 0.3 CLASS_001_NORMAL User Satisfaction > 0.96 0.1 CLASS_001_BUSY Drop Call Rate < 0.04 0.3 CLASS_001_BUSY Short Stay Rate < 0.1 … … …

5.2.1.3 SON Function Model The three different approaches for creating a SFM, as described in D5.3 [2], have been used in the studies. In total, four SON Function Models, one for each SON Function, SFMs need to be available in order to facilitate a SON management operation: Mobility Load Balancing (MLB) [21], Mobility Robustness Optimisation (MRO) [22], High-Mobility (HM) [23] and Traffic-Steering (TS) [23]. Different types of SFMs have been used. The different possibilities and the used SON functions will be described briefly in the following.

Pool 1: Own measurements For the Traffic-Steering SON function, measurements from the simulation, i.e., the “real network operation”, were taken to describe the behaviour of the SON function under certain conditions over the day. The “live” measurements were taken, aggregated and filtered based on the active cell class. This data has been made available to the Policy System.

Pool 2: Simulation Measurements The High-Mobility (HM) SFM was generated with SONLAB in separate simulation scenarios. Such scenarios included LTE micro and macro cells only. The different SCV Sets have been tested in simulations that lasted 1 hour. Each time the simulation environment, i.e. the user distribution, traffic generation, etc., was the same. In the end, the results were taken and aggregated based on the class of the cell the data was coming from.

Pool 3: Vendor SON Function Model The SFMs for MLB and MRO have been generated using a different simulator than SONLAB. The simulation platform SiMoNe (Simulator for Mobile Networks) [24] developed by TUBS served as an instrument to mimic the vendor internal process of generating such models. The main advantage in using SiMoNe is the capability to process a huge amount of SCV Sets in parallel. For this work MLB has been simulated for 28 SCV Sets in five different network scenarios leading to a total sum of 140



simulations. The different network scenarios where chosen to cover different aspects: For example different types of cell locations (urban vs. rural cells) or different user profiles (majority of normal or high-speed users in the scenario). Exemplary results for the KPIs “User satisfaction” and “Short Stay rate” in different scenarios with varying attributes (“Cell Location”, “Traffic Type” and “User Mobility Type”) can be found in Figure 18. It can be seen that the location, the traffic type and the mobility type have, in fact, an influence on the performance of the SON function.

Figure 18: SCV Set performance for different attribute combinations in terms of “USER Satisfaction” and “CELL Short Stay Rate”

On the other hand, Figure 19 presents the impact on the KPI behaviour, here namely the “CELL Resource Efficiency”, for varying (MLB) SCV Sets. It can be seen that, based on the actual SCV Set the impact on a KPI differs. Similar results can be found in [25].

Figure 19: KPI behaviour (illustrated based on the “CELL Resource Efficiency”) for different

MLB SCV Sets

5.2.2 SON Function Configuration Process The whole process of configuring SON functions according to operator objectives is divided into several consecutive steps. The first one is dealing with the KPI processing in Section 5.2.2.1. The KPI processing takes the live measurements from the system, the simulation results and the SFMs and uses statistical tools so that the next part, the SCV Set processing, can work with it and make meaningful decisions which will be described in Section 5.2.2.2. If this is done a new component comes into play. The available SON Functions Models, which are coming from the vendors, and the live measurements, coming from the operating system, are taken to trigger a learning process as it will be shown in Section 5.2.2.3.

5.2.2.1 KPI Processing The KPI processing was conducted by tightly coupling the functionality of the MD with the simulated network performance. All relevant network KPIs have been collected over time, processed and written



into an SQL database every 60 seconds simulation time. Please note that the update time of 60 seconds is an implementation detail. The update time in reality might be much bigger, in the range of 15 minutes to 1 hour. The processing included the aggregation (e.g. counter of handover events), as well as the computation from other performance indicators into a KPI (e.g. the resource efficiency that takes the cell load as well as the achievable cell throughput into account, see SEMAFOUR deliverable D3.4 [7] for more information). Furthermore the processing is cell class based, so the measurements are for each class separately.

KPI Target - Performance Comparison In a very first step the actual KPI performance is compared with the operator targets as depicted in Figure 20. This allows an easy differentiation of which KPIs fulfil the targets and which not. If all targets are fulfilled, no further measures have to be adopted since the system is working as desired.

KPI Performance

CELL ❶ CELL ❶

@ SCV SET 5 @ CLASS A

KPI Target

CLASS A

KPI Comparison

Figure 20: KPI target-performance comparison

KPI Measurements Selection As mentioned, the operator may have access to various KPI measurement sources, which are also called “pools” in the following”, with a varying degree of quantity and quality of the KPI measurement, which indicate how the system had performed or may perform when applying dedicated SCV Sets. In a first step the data has to be preselected. For example not all KPI measurements are of interest, but only those that come from the same cell type. Since the measurements from different pools are not compatible, the filtering happens for each pool of measurements individually, as illustrated in Figure 17. The reason for the incompatibility is that the actual values are coming from different sources, e.g. “real” measurements can hardly be compared with values from a simulator, “real” measurements may look different compared to the values from the SFM and hence a meaningful comparison might hard. An example for available KPI measurements coming from the different sources is shown in Figure 21. Here, all measurement having the label “Class A” are of interest, so every cell with an active SCV Set which is classified as Class A cell is chosen.

KPI @ DATE@ SET ❶

@ CLASS ❸ KPI @ DATE@ SET❷

@ CLASS ❸ KPI @ DATE@ SET 5

@ CLASS A

KPI @ SIM@ SET 4

@ CLASS A

KPI @ Model@ SET ❶

@ CLASS ❸ KPI @ Model@ SET 2

@ CLASS A

Available Data Sets

Selected Data Sets

All relevant KPI measurements

Pool 1(own measurements)

Pool 2(simulation measurements)

Pool 3(SON Function Models)

Figure 21: KPI measurement selection



SCV Set Statistics After all relevant KPI measurements from the various sources have been selected, statistical analyses (e.g., arithmetic mean, variance, etc.) will be applied in order to find performance vectors that represent each SCV Set for each KPI measurement pool respectively. For that, the measurements will be sorted and averaged based on the SCV Sets. The assumption is that if the classes for which the selection/filtering is performed are well-chosen, the statistical variance of measurements for the same SCV Set is small. The chosen representative gives a significant estimate on the performance for a cell in that context class.

𝜑⟨𝑆𝐸𝑇 𝑋|𝐶𝐿𝐴𝑆𝑆 𝐴⟩ = ∑𝐾𝑃𝐼⟨𝑆𝐸𝑇 𝑋|𝐶𝐿𝐴𝑆𝑆 𝐴⟩

#𝐾𝑃𝐼⟨𝑆𝐸𝑇 𝑋|𝐶𝐿𝐴𝑆𝑆 𝐴⟩

So 𝜑⟨𝑆𝐸𝑇 𝑋|𝐶𝐿𝐴𝑆𝑆 𝐴⟩ indicates the average KPI performance for 𝐶𝐿𝐴𝑆𝑆𝑆𝑆 𝐴 if 𝑆𝑆𝐸𝑇𝑇 𝑋 was active at the cell. An example is given in Figure 22. Here the statistics for the different SCV Sets, coming from the measurement pool of the real network data, which are labelled with “Class A” are calculated.

Set 1 Set 2

ϕ‹Set 1 |CLASS A›

Mea

sure

men

tsSC

V Se

t St

atist

ics

SCV

Set

Set N

…

Pool 1 (own measurements)

KPI @ [2014-09-12; 08:00]@ SET 1

w/ Attribute {rural, high-speed, busy}

KPI @ [2014-09-12; 09:00]@ SET 1


KPI @ [2014-08-05; 09:00]@ SET 2


KPI @ [2014-09-12; 10:00]@ SET 1


KPI @ [2014-08-05; 15:00]@ SET 2


ϕ‹Set 2|CLASS A› ϕ‹Set N|CLASS A›

Figure 22: KPI measurement statistics

5.2.2.2 SCV Set Processing The SCV Set Processing is the second step towards finding the best possible configuration of SON functions. This decision is made by taking the SCV Set Statistics which result from the KPI Processing step and the operator-defined Objective Model into account. The outcome of this step is a policy that indicates for each cell class a set of SON function configurations that can be evaluated by the Policy System. This process is divided into several parts: The SCV Set Delta Determination, the SCV Set Filtering, the KPI Target-Performance Comparison and the SCV Set Selection.

SCV Set Delta Determination The Delta Determination step iterates over each pool in the SCV Set Statistics and compares each SCV Set effect with the current KPI performance measured in the network to the extent to which they may be applicable for certain cell classes. That means that for each cell class the current class performance will be only compared to SCV Sets that are usable in the context of this cell class.

∆(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴)= 𝜑(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) − 𝜑(𝐴𝑐𝑡𝑖𝑣𝑒 𝑆𝑒𝑡 | 𝐶𝐿𝐴𝑆𝑆 𝐴)



Δ thereby means the resulting delta and 𝜑 means the SCV Sets. The delta is expressed by means of a vector that indicates the difference for each KPI. With this delta, the operator gets an impression about how the KPI performance will be changed by moving from one SCV Set to another. Note that this delta determination has to be done for each measurement pool individually. We thereby assume that measurements within each single pool are consistent which should lead to the same level of “aggressiveness” for deltas from different pools even though the absolute values may be different. Aggressiveness here means how big the performance impact on certain KPIs is, when choosing this SCV Set.

SCV Set Filtering In a next step, the set of possible SCV Sets will be filtered so that SCV Sets that have a negative effect on all KPIs can be discarded. Since there are two different types of KPIs – the ones where an operator aims for the highest possible value (e.g., Resource Efficiency, User Satisfaction) and those where the lowest possible value is targeted (e.g., Call Drop Rate, Short Stay Rate) – the deltas have to be normalised. That means they have to be multiplied by a normalisation vector:

𝑁𝑜𝑟𝑚 =

⎣⎢⎢⎢⎡−1+1−1…

+1⎦⎥⎥⎥⎤𝑓𝑜𝑟

⎣⎢⎢⎢⎡

𝐶𝑀𝑀𝑙𝑙 𝐷𝑟𝑜𝑝 𝑅𝑀𝑀𝑡𝑒𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐸𝑓𝑓𝑖𝑖𝑐𝑖𝑖𝑒𝑖𝑖𝑐𝑦𝑆𝑆ℎ𝑜𝑟𝑡 𝑆𝑆𝑡𝑀𝑀𝑦 𝑅𝑀𝑀𝑡𝑒

…𝑈𝑠𝑒𝑟 𝑆𝑆𝑀𝑀𝑡𝑖𝑖𝑠𝑓𝑀𝑀𝑐𝑡𝑖𝑖𝑜𝑖𝑖 ⎦

⎥⎥⎥⎤

The result is a vector where positive values indicate a KPI improvement and a worsening for negative values.

∆𝑁𝑜𝑟𝑚(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) = ∆(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) ∗ 𝑁𝑜𝑟𝑚 The normalised deltas that contain only negative values lead to a worse performance for all KPIs (compared to the currently active SCV Set) and hence, can be discarded for the current SCV Set processing.

KPI Target-Performance Comparison After determining the impact that certain SCV Sets would have in the network compared to the currently active SCV Set, it has to be discovered which KPIs need an improvement in order to fulfil operator objectives. Therefore, the current behaviour in terms of KPIs (coming from the network) is needed. The KPI targets given in the operator objectives are subtracted from the current performance and the resulting vector is multiplied by the normalisation vector Norm defined in the previous section.

𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 = �𝐾𝑃𝐼𝑃𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 − 𝐾𝑃𝐼𝑇𝑎𝑟𝑔𝑒𝑡𝑠� ∗ 𝑁𝑜𝑟𝑚 KPIComparison represents a vector where negative values indicate that a KPI has to be improved to fulfil the KPI target and positive values indicate that the current SCV Set fulfils the respective KPI target. Furthermore,

𝐾𝑃𝐼𝑃𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 =

⎣⎢⎢⎢⎡𝑐𝑢𝑟𝑟𝑒𝑖𝑖𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝐶𝐷𝑅𝑐𝑢𝑟𝑟𝑒𝑖𝑖𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑅𝐸𝑐𝑢𝑟𝑟𝑒𝑖𝑖𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑆𝑆𝑅

…𝑐𝑢𝑟𝑟𝑒𝑖𝑖𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑈𝑆 ⎦

⎥⎥⎥⎤

𝑓𝑜𝑟

⎣⎢⎢⎢⎡



⎥⎥⎥⎤

and

𝐾𝑃𝐼𝑇𝑎𝑟𝑔𝑒𝑡𝑠 =

⎣⎢⎢⎢⎡𝑡𝑀𝑀𝑟𝑔𝑒𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝐶𝐷𝑅𝑡𝑀𝑀𝑟𝑔𝑒𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑅𝐸𝑡𝑀𝑀𝑟𝑔𝑒𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑆𝑆𝑅

…𝑡𝑀𝑀𝑟𝑔𝑒𝑡 𝑣𝑀𝑀𝑙𝑢𝑒𝑈𝑆 ⎦

⎥⎥⎥⎤

𝑓𝑜𝑟

⎣⎢⎢⎢⎡



⎥⎥⎥⎤

SCV Set Performance Indication Based on the filtered deltas ∆𝑁𝑜𝑟𝑚(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) and the 𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 vector the best possible SCV Sets can be chosen. This is again done for each measurement pool and each cell class individually.



Therefore the 𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 vector is subtracted from each ∆𝑁𝑜𝑟𝑚(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴). Note that “Set” can either be one single SCV Set or a combination of SCV Sets (one for each SON Function) function.

𝑆𝑆𝐶𝑉 𝑆𝑆𝑒𝑡 𝑃𝑒𝑟𝑓𝑜𝑟𝑚𝑀𝑀𝑖𝑖𝑐𝑒 𝐼𝑖𝑖𝑑𝑖𝑖𝑐𝑀𝑀𝑡𝑜𝑟(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) = ∆𝑁𝑜𝑟𝑚(𝑆𝑒𝑡 𝑋 | 𝐶𝐿𝐴𝑆𝑆 𝐴) + 𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 This 𝑆𝑆𝐶𝑉 𝑆𝑆𝑒𝑡 𝑃𝑒𝑟𝑓𝑜𝑟𝑚𝑀𝑀𝑖𝑖𝑐𝑒 𝐼𝑖𝑖𝑑𝑖𝑖𝑐𝑀𝑀𝑡𝑜𝑟 (SSPI) is a vector that contains a positive value for a KPI if the operator given target is fulfilled and a negative value, if not. By means of this vector a utility can be computed according to techniques that have already been described in D5.3 [2]. SCV Set Selection The SCV Sets (or SCV Set combination respectively) with the highest utility are chosen to be the best ones for their pool. If more than one SCV Set or SCV Set combination have the best utility, the decision for one of them can be taken randomly since they both promise the same degree of fulfilment for the operator objectives.

5.2.2.3 Learning Process, Adaptation of Pool 1 The decision which measurement pool is the preferable one depends on the time and the number of measurements in the Network Measurement Pool (NMP). Since measurements coming from the network are more realistic and hence more accurate than the predictions in the SFM (that have been created through simulations), these are the ones that are more promising in terms of network behaviour predictions. However at the beginning, the NMP is empty and has to be filled (learned) over time. In this phase, as much measurements for different SCV Sets and classes as possible should be gathered so that a big number of measurements is available after finishing the collection phase. Thereby, it is helpful to choose SCV Set combinations randomly in case of equal utilities since it guarantees a big variety of measurements in the measurement pool. The duration of the collecting phase can be defined by the operator, and different options for this definition exist, e.g.: • A fixed number of measurement iterations that has to be completed • Until a defined degree of convergence has been achieved per SCV Set • Until a defined degree of convergence has been achieved for all SCV Sets After that phase, SCV Sets are always chosen based on the NMP. However, this NMP is still collecting KPI data after finishing the collecting phase that is based on the SFM. This simple learning process can be extended in different ways. First, the selection of SCV Sets in case of equal utilities can be made by taking distances between the different SCV set performances into account. That means the selection process could, e.g., make use of the Euclidean distance to find not only the SCV sets with the highest utility, but also the best SCV sets (compared to all other SCV sets). Furthermore, if none of the network measurements fulfils all KPI targets, the SFM can be consulted again trying only SCV sets where no measurements exist in the NMP. Therefore, the operator could also define a lower threshold in terms of utilities that indicates how much risk he is willing to take. This helps to also taking SCV sets from the SFM into account whose predicted utility is lower than the predicted utility of some other sets, but which could have a totally different (and possibly better) impact in the real network. If a new SON function is deployed in the network system, there are simply no measurement values available. It needs time to collect and aggregate cell KPIs. Over time, more and more measurements will be available for varying cell classes as well as different SCV set combinations, since new SCV set combination get selected based on the SFMs as described in previous Subsection. This enables a smooth acquisition of knowledge about how a certain SON function performs in a real operator network. Note that the main intension of SFMs within this concept is then to have a starting point or some clues of how a SON function might perform. As it has been said, this information can then be evaluated over time and discarded if enough knowledge is acquired to feed the PBSM with real network measurements solely.



5.2.2.4 Example In this chapter, an example is shown that explains the SCV Set Processing given two KPI measurements sources: the SFM and the network measurements. The vectors below indicate the KPIs used and their order in the whole example, as well as the normalisation vector for these KPIs.

𝐾𝑃𝐼𝑠 = �

𝐶𝑀𝑀𝑙𝑙 𝐷𝑟𝑜𝑝 𝑅𝑀𝑀𝑡𝑒𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒 𝐸𝑓𝑓𝑖𝑖𝑐𝑖𝑖𝑒𝑖𝑖𝑐𝑦𝑆𝑆ℎ𝑜𝑟𝑡 𝑆𝑆𝑡𝑀𝑀𝑦 𝑅𝑀𝑀𝑡𝑒𝑈𝑠𝑒𝑟 𝑆𝑆𝑀𝑀𝑡𝑖𝑖𝑠𝑓𝑀𝑀𝑐𝑡𝑖𝑖𝑜𝑖𝑖

� 𝑁𝑜𝑟𝑚 = �−1+1−1+1

�

The SFM and NMPs contain the following SCV Sets and predicted values (currently active set is bold): SON Function Model Network Measurements

𝜎𝑆𝐹𝑀(𝑆𝑒𝑡1 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.02512.560.016

0.7819

� 𝜎𝑁𝑀(𝑆𝑒𝑡1 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0429.93

0.0230.7553

�

𝜎𝑆𝐹𝑀(𝑆𝑒𝑡2 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0318.43

0.0230.6974

� 𝜎𝑁𝑀(𝑆𝑒𝑡2 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0457.53

0.0090.5964

�

𝝈𝑺𝑭𝑴(𝑺𝒆𝒕𝟑 | 𝑪𝑳𝑨𝑺𝑺_𝟎𝟎𝟏_𝑩𝑼𝑺𝒀) = �𝟎.𝟎𝟒𝟒𝟗.𝟏𝟑𝟎.𝟎𝟎𝟕𝟎.𝟖𝟑𝟕𝟓

� 𝜎𝑁𝑀(𝑆𝑒𝑡3 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.03511.430.028

0.8111

�

𝜎𝑆𝐹𝑀(𝑆𝑒𝑡4 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.01110.360.034

0.9264

� 𝜎𝑁𝑀(𝑆𝑒𝑡4 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.01510.980.029

0.8830

�

𝜎𝑆𝐹𝑀(𝑆𝑒𝑡5 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0518.52

0.0080.7229

� { }

Furthermore,

𝐾𝑃𝐼𝑇𝑎𝑟𝑔𝑒𝑡𝑠 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌 = �0.02610.850.0120.85

� and 𝐾𝑃𝐼𝑃𝑒𝑟𝑓𝑜𝑟𝑚𝑎𝑛𝑐𝑒 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌 = �0.04513.850.013

0.7943

�,

which leads to the following 𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 vector:

𝐾𝑃𝐼𝐶𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛 = ��0.04513.850.013

0.7943

� − �0.02610.850.0120.85

�� ∗ �−1+1−1+1

� = �−0.019

3.00−0.001−0.0557

�

The normalised deltas to the currently active set are depicted below. Only the SFM is taken into account since there are only four measurements available in the network measurements.

ΔSON Function Model SSPISFM

Δ𝑆𝐹𝑀(𝑆𝑒𝑡1 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0193.33

−0.009−0.0556

� 𝑆𝑆𝑆𝑆𝑃𝐼(𝑆𝑒𝑡1 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0

6.33−0.01−0.1113

�



Δ𝑆𝐹𝑀(𝑆𝑒𝑡2 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.013−0.7−0.016−0.1401

� 𝑆𝑆𝑆𝑆𝑃𝐼(𝑆𝑒𝑡2 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �−0.006

2.3−0.017−0.1958

�

𝚫𝑺𝑭𝑴(𝑺𝒆𝒕𝟑 | 𝑪𝑳𝑨𝑺𝑺_𝟎𝟎𝟏_𝑩𝑼𝑺𝒀) = �𝟎𝟎𝟎𝟎


3.00−0.001−0.0557

�

Δ𝑆𝐹𝑀(𝑆𝑒𝑡4 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.0331.23

−0.0270.0889

� 𝑆𝑆𝑆𝑆𝑃𝐼(𝑆𝑒𝑡4 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �0.014−1.77−0.0280.0332

�

Δ𝑆𝐹𝑀(𝑆𝑒𝑡5 | 𝐶𝐿𝐴𝑆𝑆_001_𝐵𝑈𝑆𝑌) = �−0.007−0.61−0.001−0.1146


2.39−0.002−0.1703

�

Following weights are assumed:

𝐾𝑃𝐼𝑤𝑒𝑖𝑔ℎ𝑡𝑠 = �0.40.10.20.3

�

This leads to the following utilities: Set1 has a utility of 0.5, Set2 a utility of 0.1, Set3 a utility of 0.1, Set4 a utility of 0.7 and Set5 a utility of 0.1. Hence, Set4 is chosen as the new optimized SCV in the SFM as the one with the highest utility. The performance that could be measured when Set3 was active is stored in the NMP.



6 Operational SON Coordination SONCO deals with two types of conflicts: parameter conflicts and measurement conflicts (for details see SEMAFOUR deliverable D5.3 [2]). In this section the solutions for SON conflict resolution (Section 6.1) and conflict detection (Section 6.2) based on a heterogeneous network (HetNet) scenario are presented. First the results obtained from the HetNet Scenario presented in D5.3 [2] concerning the conflict resolution are provided. Second, for the same scenario a conflict detection method based on the Naive Bayes Classifiers (NBC) introduced in D5.3 [2] is presented. Finally, a conflict resolution solution for the conflict between the two SON functions Mobility Load Balancing (MLB) and High Mobility Traffic Steering (HM, see D4.3 [26]) on the handovers (HOs) is presented.

6.1 Conflict resolution CRE, eICIC, MRO In this section the results of the conflict resolution (SONCO-R) from the scenario introduced in D5.3 [2] are presented. The SONCO-R is based on Reinforcement Learning (RL) and two designs are analysed. These designs are named by the employed technique: State Aggregation (SA) and Linear Features (LF). In this section, only results are presented, design details can be found in [6]. The scenario is a network composed of 21 macro cells and 6 pico cells as shown in Figure 23. There are three clusters outlined, each of which contains a macro cell and two pico cells. Three SON functions have been considered: Cell Range Expansion (CRE), Mobility Robustness Optimisation (MRO) and enhanced Inter-Cell Interference Coordination (eICIC). CRE tunes the Cell Individual Offsets (CIOs) of the pico cells. MRO tunes the CIOs and HO Hysteresis (HYS) of the pico cells. Finally, eICIC tunes the number of Almost Blank Sub-frames (ABS) of the Macro cells. The focus is on the CIO parameter conflict between MRO and CRE. Note that the CIO also has an impact on the input measurements of the eICIC (measurement conflict). Furthermore, it is recalled that the update requests contain an indication of how critical their requests are. A SONCO-R instance is applied for each of the clusters. Its job is to find a judicious way to decide when to favour CRE and when to favour MRO, such that it minimises a regret which reflects the maximum criticalness among the requests.

Figure 23: Network Topology (see [6])

This sub-section shows the results aimed at proving the biasing mechanism, i.e. the capability of favouring one SON function or another, based on simulations with stationary traffic λ for a period of 20 days (see [6]). The first 10 days are considered as a sufficiently big time interval for the algorithms to converge and the evaluation of the network parameters is carried out during the last 10 days. Figure 24 shows averages over the parameters controlled by the SON functions: the average CIO (over time and all pico cells), the average HYS (over time and all pico cells) and the average no. of ABS (over time and all macro cells), respectively, for different weights w attributed to the SON functions. The three digits after the 'SA' or 'LF' indication identify the weight of the three SON functions in the following order: CRE, MRO and eICIC (e.g. 'LF181' refers to the LF design with the weights 1, 8 and



1 for CRE, MRO and eICIC, respectively). For simplicity, the analysis has been focused only on the conflict between CRE and MRO. It is expected that a higher priority on the CRE should lead to more aggressive off-loading, i.e. bigger values of the CIO of pico cells, and on the other hand a bigger priority of the MRO would restrict this offloading, i.e., lower CIO values. The number of ABS will also have the same trend as eICIC reacts to the changes of the CRE: the bigger the CIO the more UEs to protect and thus the bigger the number of ABS sub-frames. This trend can be seen in Figure 24 for the two designs SA and LF. The average HYS is also impacted by the different weights as for example a small CIO value would reduce the number of too late HOs and would thus allow for bigger HYS values to also reduce the ping-pong HOs. As mentioned, a bigger weight on the CRE leads to higher average CIO values. This forces the MRO to reduce the values of HYS, as can be seen in Figure 24, in order to reduce the number of too late HOs. Naturally, a bigger weight on the MRO will have the opposite effect, i.e. the average HYS values will be bigger as the number of too late HOs will not be so critical. MRO will profit from this by increasing the HYS in order to reduce the no. of ping-pong HOs.

Figure 24: Average Network Parameters (see [6])

In Figure 25, averages over the KPIs used as inputs for the SON functions are shown: • the average load (over time and all macro cells in the three clusters, over time and all pico cells), • the average number of ping-pong HOs and of too late HOs (over time and over all pico cells), • the average ratio of the bit-rates of UEs attached to the macro cells and of cell-edge UEs attached

to its slave pico cells (over time and all macro cells), scaled by 0.4 in the figure. More details on the KPI calculation are in [6]. One can again see the effects of giving higher priority to either CRE or to MRO, especially on the load of the pico cells and also on the number of ping pong HOs and the too late HOs. More precisely, the load of the pico cells, the number of ping-pong HOs, and the number of too late HOs increases if a higher priority is given to CRE, and consequently decreases if a higher priority is given to MRO. Precise trends on the other KPIs are not expected, given the more complex dependencies.



Figure 25: Average KPIs (see [6])

In addition, the analysis of trained SONCO reactions (in terms of the abstract regret which reflects the highest criticalness among the update requests) to variations of the traffic has been carried out, namely: • the time needed for the algorithms to re-converge after a traffic change. • the regret augment during the re-convergence period as compared to after the re-convergence. For each design, SA and LF, two scenarios have been considered. In the first scenario the simulation time is split into 2 equal time periods of 10 days. During the first period a stationary traffic of 0.90 λ has been considered and during the second time period a stationary traffic of λ has been considered. The second scenario is similar to the first one, the only difference being that during the first time period a stationary traffic of 0.95 λ has been considered. In Figure 26 presents the time-average of the maximum over all instantaneous regret components making use of a sliding time window of 2.5 days during the 20 days simulation period. The prefixes ' SA' and 'LF' indicate the SONCO design and the suffix '.95' and '.90' indicate the scenario. From the performed tests, it is clear that the tracking capability of the LF design is much better than the one of the SA design. The re-convergence time (which starts from time instant 12.5h, i.e., immediately after the traffic change considering also the size of the sliding window) is considerably shorter for the LF design and the regret augmentation during the re-convergence period as compared to the regret after re-convergence is imperceptible.

Figure 26: Tracking capabilities (see [6])

In both designs, a SONCO instance governs one macro cell and its slave pico cells. Thus, the size of the learned information scales linearly with the number of macro cells. With respect to the number of pico cells per macro cell, the SA design scales exponentially whereas the LF design scales polynomial (order 2). Thus, LF proves to have a lower complexity as compared to SA. The LF design converges



much faster than the SA design, and it is also more robust. However, it requires some additional knowledge on the potential impact of changing the network parameters, i.e., it has to be known if the dependency between the network parameters and the regret (components) is linear.

6.2 Conflict Detection CRE, eICIC, MRO SONCO conflict Detection (SONCO-D) is based on Naive Bayes Classifiers (NBC), which is detailed in [5]. In the context of a faulty network first the possible causes (C) should be established, then a set of symptoms (S) is identified, which helps to identify the cause (see Figure 27) of a fault.

Figure 27: Naive Bayes Classifier (see [5])

As in the previous section, three SON functions are considered: CRE, MRO and eICIC. The network topology is outlined in Figure 28. The SON instances are considered to act only on the cells in the dashed area (macro cell ‘M’ and pico cells ‘P1’ and ‘P2’). The same goes for the SONCO-D.

Figure 28: Network Topology (see [5])

In Figure 29 the SON outputs (parameters) are represented by CIO, HYS, and ABS, and the SON inputs (measurements) are represented by load (LD), number of Too Late HOs (TL), number of Ping Pong HOs (PP) and the Throughput Ratio (TR) between macro cell UEs and protected UEs. More details are included in [5]. Also, it is outlined if a parameter may have an impact on a measurement.



Figure 29: SON interaction (see [5])

6.2.1 Causes and Symptoms It should be noted that only CRE and eICIC may create conflicts. Thus, a level 1 cause-set 𝐶1 ={𝐶𝑅𝐸, 𝑒𝐼𝐶𝐼𝐶} is defined. It is noted that the problem may come from one of the different settings of the SON functions like: the triggering thresholds (𝕋) and the step size for the tuned parameters (Δ), and so the level 2 cause-set 𝐶2 = {𝐶𝑅𝐸, 𝑒𝐼𝐶𝐼𝐶} × {𝕋,Δ} is defined. Moreover, it is also possible to target to identify the alteration degree of the problematic SON setting (by how much the setting has to altered in order for the conflict to disappear): low (l), medium (m), high (h), and so to define the level 3 cause-set:𝐶3 = {𝐶𝑅𝐸, 𝑒𝐼𝐶𝐼𝐶} × {𝕋,Δ} × {𝑙,𝑚,ℎ}. Note that, the higher the layer is, the bigger the number of leaves will be in Figure 29. A comparative diagnosis study for the 3 cause-set levels is provided in the following. Four symptoms are considered, each of which is based on one of the network measurements: 𝑆𝑆𝑖, 𝑖𝑖 ∈ {𝐿𝐷,𝑇𝑇𝐿,𝑃𝑃,𝑇𝑇𝑅}. The measurements are computed over the cells in the cluster of interest. More details are available in [5]. 𝕊𝑖 , 𝑖𝑖 ∈ { 𝐿𝑇𝑇,𝑇𝑇𝐿,𝑃𝑃,𝑇𝑇𝑅} is defined to be the targeted performance w.r.t. the symptoms. At time t it is considered that there occurs a network fault (e.g., coming from a erroneous configuration of the SON functions) if ∃𝑖𝑖 ∈ {𝐿𝑇𝑇,𝑇𝑇𝐿,𝑃𝑃,𝑇𝑇𝑅} s.t. 𝑆𝑆𝑖(𝑡) > 𝕊𝑖 . Thirteen scenarios (cf. [5]) have been considered with different SON function settings. For each scenario a simulation with a runtime of 2400 hours has been performed. One of them is the reference (REF) scenarios and the other 12 are meant to generate the causes in 𝐶3 (and implicitly in 𝐶2 and 𝐶1). The details can be found in [5]. Figure 30 shows, for all the scenarios, the percentile of time each fault occurs (LD, TL, PP, TR), and the percentile of time at least one fault occurs (LD, TL, PP, TR). Consequently, these faulty samples represent the input to the designed diagnosis evaluation as presented in the sequel (cf. [5]).



Figure 30: Fault frequency (see [5])

By selecting 1000 faulty time samples from each of the scenarios except REF, and focussing on the level l cause-set 𝐶𝑙, the diagnosis model, i.e., the NBC is learned. A uniform distribution of the probability is considered to have a cause. Subsequently, 400 other faulty time instances are selected from each of the scenarios except REF, and the SONCO-D is tested. The percentile of correct identification of the fault is presented in Figure 31 for all the three levels. The outcome is a performance of more than 91.7 % for detecting the SON function causing the problem (level 1 cause), of more than 82.5% if also detecting the problematic setting (level 2 cause) is required, and of more than 52% in the case detection of the alteration degree of the setting (level 3 cause) is required. As expected, detecting only the problematic SON function is less subject to errors than identifying altogether the problematic SON function, the problematic setting and the degree of alteration.

Figure 31: Correct diagnosis probabilities (see [5])

6.3 Conflict resolution HM, MLB In this section, the SONCO-R solution is presented for a scenario with 2 SON functions: MLB and HM. Briefly: • MLB tunes a per cell pair CIO in order to improve the load distribution. More precisely, if a cell is

over-loaded, MLB searches for users that are suitable to be handed over to one of the



neighbouring cells. It will send an explicit request to HO that particular UE and it adapts the CIO such that it does not handover back shortly after.

• HM tries to anticipate if a UE should handover to a neighbour cell based on past experience. Basically it identifies if the statistics of a UE are similar to some pervious UEs, and with this information it decides if it handovers earlier.

Nevertheless, there is a clear potential conflict between HM and MLB as they both tackle with the UE HOs. In order to characterise this situation a “chained HO” has been defined as the event where a UE performs a HO and shortly after it performs a new HO. Simulations in the SEMAFOUR simulation environment (SONLAB) have been carried out, confirming that there are HOs triggered by the MLB shortly after HOs triggered by the HM, but not the other way around. Thus, two different solutions are needed, depending on who has the bigger priority: • if HM has priority over MLB, then the proposed solution is: the UEs which perform a HM

triggered HO are tagged. The tagged UEs may not be handed over by MLB. This tag should expire after a certain time.

• if MLB has priority over HM then the proposed solution is : once a HO is requested by the HM, the SONCO checks if the targeted cell is not offloading (e.g. by looking at its CIO). If it is, the HO is denied, otherwise the HO is accepted.

As this is work in progress, the results will not be included or presented within SEMAFOUR..



7 Decision Support System

7.1 Introduction This chapter describes the results of the additional work on the Decision Support System (DSS) that have been carried after the release of SEMAFOUR deliverable D5.3 [2]. The main task of the DSS use cases investigated in SEMAFOUR, Operational Network Evolution (DSS-ONE) and Strategic Network Migration (DSS-SNM), is to automatically provide recommendations towards the operator about network enhancements and extensions in case it is foreseen that the desired service level cannot longer be met by the Integrated SON Management system in the future. The involved network upgrades in DSS-ONE are primarily new site deployments or enhancements of the efficiency of established sites. In the DSS-SNM use case, the considered network upgrades are of more strategic nature; they may entail, e.g., the migration of existing sites to support new radio access technologies, spectrum re-farming, or the introduction of new frequency bands. In the first two years of the SEMAFOUR project most effort on DSS has been put in the development of concepts and algorithms for DSS-ONE; final results have been reported in deliverable D5.3 [2]. During the final year of the project these final results have been incorporated in an upgrade of the DSS demonstrator in WP3, see also deliverable D3.5 [27]; demonstrations of DSS-ONE will be given at (amongst others) the SEMAFOUR final workshop. For DSS-SNM the work has been continued and additional studies were carried out since the release of deliverable D5.3 [2]. In particular, the strategy for adding new carriers into the existing network is developed and evaluated via simulation results. These results provide a two step methodology to identify which existing site or set of sites would benefit the most from upgrading the site to a multi-carrier capable site/s.

7.2 DSS Bottleneck detection benchmarking The implementation of the bottleneck detection tool has been finalised and evaluated. The tool is, based on big data algorithms that have already been described in D5.3 [2], namely, the M5 tree model, Neural Network model (NN), and Support Vector Machine (SVM) model. All three models are capable of identifying the need for strategic or operational upgrades of the network due to a future lack of resources. The bottleneck detection tool requires a training period, during which the analysed part of the network (which consists of several Macro and Pico Base Stations) resource usage parameters are recorded together with their associated traffic parameters. Also this process is already described in D5.3 [2]. In order to prove the accuracy of the obtained models with the real network behaviour, the models have been applied to data (traffic parameters) from base stations operational in a real network, and the model output (different resource usage parameters) have been compared with the real data recorded. In Figure 32, Figure 33 and Figure 34 the outcomes of SVM, NN and M5 models are shown, and it can be observed that the match between the real data and the model predictions is better for the M5 model (0,982) than for the NN (0,939) or SVM (0,932) models. Furthermore, the M5 model provides several degrees of freedom, for example, the number of nodes and branches in each node, or the number of neighbour nodes, which enables to increase the model performance at the trade-off to increase its complexity.



Figure 32: Correlation between real data and SVM model prediction

Figure 33: Correlation between real data and NN model prediction



Figure 34: Correlation between real data and M5 model prediction

The research carried out for the characterisation and performance of the M5 model has also shown that good results can already be achieved by only using some basic numbers for traffic parameters as input. As an example, Figure 35 shows that a 0.893 correlation can be achieved using basic parameter inputs for DCH, FACH, HSDPA, HS, Soft HO and voice traffics.

Figure 35: Correlation between real data an M5 tree model prediction with basic configuration

However, in order to obtain more accurate predictions models (such as the one shown in Figure 34 with a 0.982 correlation), a more detailed characterisation is needed. For this reason, the model that generates the results shown in Figure 34 also takes RAN configuration parameters (such as the



Maximum transmission power installed in the cell) and more detailed characteristics of the UE traffic (such as the Reported Channel Quality Indicators by UEs) into account. Therefore, the big data approach with using an M5 tree model for DSS bottleneck detection, could been proven to provide valid output, with a rather high recall ratio compared to real data (over 0,98). The output is usable for bottleneck prediction if relevant traffic characterisation parameters are available.

7.3 DSS-SNM – Final Results DSS-SNM deals with spectrum re-farming and new carrier addition aspects for an existing LTE network. In this section a detailed description of the concept of DSS-SNM and the evaluation results achieved for this concept are provided.

7.3.1 Concept of DSS SNM The spectrum related upgrades in the network are dealt with in the DSS-SNM use case. This use-case can be sub-classified into: • Spectrum re-farming from GSM to LTE • New carrier addition in operator’s LTE network The spectrum re-farming aspects deal with reallocating the spectrum originally provided for one technology to other technology as the UE population distribution starts to change, enabling the opportunity of increasing the spectrum usage efficiency. One good example for such spectrum re-farming is the allocation of GSM spectrum to another technology with higher spectral efficiency like LTE. In order to carry out such a migration, the operators need to have the plans in place well in advance, depending on the changes in the distribution of UEs with different capabilities in their network and on regulatory aspects. This topic has not been further investigated in the framework of the SEMAFOUR project. On the other hand, once the operator has access to a newly acquired bandwidth, a detailed plan as to how to gradually integrate the new carriers into the existing operator’s network needs to be worked out. This will help the operators to invest their capital gradually to buy the necessary technology and equipment from the vendors. In the new carriers addition use case, possible future bottleneck regions are analysed. Based on the analysis of the problem zone, a list of upgrade options is generated and evaluated to show the extent of benefits of each upgrade option. The benefits are measured in terms of: • Quality of the upgrade - ability to solve the problem in the problem zone • Durability of the upgrade - longevity of the ability to solve the problem in the problem zone • Cost of the upgrade – economic expenditure of the upgrade option This information is then tabulated and provided to the operator. The operator can then select the appropriate upgrade option based on their targets in terms of quality and cost.

7.3.2 New Carrier Integration in LTE Network The macro cells have a larger coverage area than the small cells due to their deployment location (mostly rooftop) and their higher transmission powers. In a city environment, the macro propagation is mainly governed by the roof top diffractions and reflections from buildings in the area. Even when several small cells are deployed in the coverage area of a macro cell, the macro cell still captures a lot of users in the area. This is illustrated using the Figure 36 wherein 28 small cells are deployed in the city centre of Hannover but still the macro cell captures large number of users in the area. It is also worth mentioning that the small cells are additionally provided with 6 dB of cell range expansion to increase their coverage. This acts as a good input when the new carrier needs to be added in the area as macro site upgrade seems to be more beneficial as it covers a larger region (of course one needs to understand the size of the problem zone).



Figure 36: Macro coverage despite multiple small cell deployment in the city centre area

Another reason for initially integrating the additional carrier into the macro cell would be from the point of view of covering the indoor users at higher floors who might not get coverage from the low power small cells.

7.3.2.1 Coverage Aspect of Higher Frequencies The simulation scenario considered for the DSS-SNM use case is the entire Hannover city scenario as explained in Section 4.7.1.2 of SEMAFOUR deliverable D2.5 [28]. For the evaluation of the upgrade option, only a smaller region of city centre in the Hannover scenario is considered although the simulation is carried out for the entire Hannover scenario. Both the entire Hannover scenario that is simulated and the city centre region that is used for upgrade option generation and evaluation are shown in Figure 37. The main reason for doing so is to understand the impact of changes from the upgrade options in more detail as will be shown later in Section 7.3.2.2 and Section 7.3.2.3. The reason for selecting the centre of the city of Hannover as the area for evaluation is that there are both small cells’ and macro cells’ coverage in this region. This makes it harder to judge which cells needs to be upgraded i.e., only macro cells, only small cells or a combination of macro and small cells. In these simulations, a realistic traffic intensity map is used, the details of which are provided in section 2.2 of D2.5 [28]. The hotspots are generated only in the city centre (region shown to the right image in Figure 37) of Hannover. The hotspot will cause problems in the area and therefore the city centre region acts as the problem zone in the simulations for upgrade generation and evaluation phase. Other parameters used in the simulations are given in Table 12.

Table 12: Simulation parameters used in DSS-SNM Simulation Parameter Value Existing carrier 1800 MHz (20 MHz bandwidth) Upgrade carrier option 2600 MHz (20 MHz bandwidth) Number of macro cells 195 Number of micro cells 28 Mobility None



Figure 37: Simulated scenario of Hannover (left) and the evaluation region highlighted at the

centre of Hannover (right). In the right image only the central brightly coloured region is taken into account (smaller top left region of the centre is not considered) for upgrade option generation and

evaluation phase. Based on the work in the Bottleneck Detection given in Section 7.2, it is assumed that the size and location of the hotspot/problem zone is known. This information (size and location of hotspot) is fed as the input to the upgrade option generation and evaluation algorithm. The hotspot (HS) that is considered in the following sections is in city centre, but has different locations and different radius in order to create different scenarios. Two different HS locations were chosen and for each HS location five different radius were chosen (the location and the radius were chosen randomly in the city centre area). These HS locations are shown in Figure 38and the used radius of the HS was in the range of 50-500 m.

Figure 38: Different hotspot locations and the hotspot radius



The term HS and problem zone is used interchangeably during the explanations in Section 7.3.2.2 and Section 7.3.2.3. Simulations are carried out with a traffic increase granularity of 5% in the non-hotspot area. For each 5% increase of traffic in the non-hotspot area, the hotspot area will increase by 50% in the traffic.

7.3.2.2 Integration in Macro Cell vs. Small Cell The upgrade options in the problem zone are in terms of which of the existing 1800 MHz site can be upgraded with the additional 2600 MHz carriers. No new site location addition is considered to be an upgrade option, rather only upgrading the existing sites with dual carriers is considered. In the following explanation of how the upgrade option is generated only one hotspot realisation (i.e. right hotspot with a radius of 479 m) from Figure 38 is used, but the same methods are used for any realisation of the HS and a combination of the HSs. All the metrics used in this section will be derived based on the existing spectrum band i.e., the 1800 MHz band. These metrics will be used to understand how the addition of new spectrum in those cells will benefit in solving the problems of the HS. The sites chosen for dual carrier upgrades are based on three parameters: • Problem Zone Coverage (PZC) • Problem Zone Load Sharing (PZLS) • Neighbour Problem Zone Coverage (NPZC)

Problem Zone Coverage (PZC) This parameter provides an estimate of the extent of impact of the hotspot on the cell under consideration. Basically, it is the ratio of the total amount of traffic that is expected from the area of the cell that belongs to the HS region and the total amount of traffic carried by the cell.

𝑃𝑍𝐶 = 𝐴𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝑢𝑠𝑒𝑟𝑠 𝑜𝑓 𝑡ℎ𝑒 𝑐𝑒𝑙𝑙 𝑖𝑖𝑖𝑖 𝑡ℎ𝑒 𝐻𝑆𝑆 𝑇𝑇𝑜𝑡𝑀𝑀𝑙 𝑀𝑀𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝑀𝑀𝑙𝑙 𝑢𝑠𝑒𝑟𝑠 𝑖𝑖𝑖𝑖 𝑡ℎ𝑒 𝑐𝑒𝑙𝑙

Figure 39: Problem Zone Coverage (PZC) for one realisation of the hotspot

A plot showing such a metric for one realisation of the HS scenario is shown in Figure 39. Based on this plot it can be estimated which cells are candidate positions to be upgraded. The actual method for



selection is explained later in the section but it can be stated that such a method will be used to create the candidates which will be evaluated later on.

Problem Zone Load Sharing (PZLS): The metric PZLS is defined as the ratio of the amount of traffic carried by the HS users that are connected to a cell to the total amount of traffic generated in the HS.

𝑃𝑍𝐿𝑆𝑆 = 𝐴𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝑢𝑠𝑒𝑟𝑠 𝑜𝑓 𝑡ℎ𝑒 𝑐𝑒𝑙𝑙 𝑖𝑖𝑖𝑖 𝑡ℎ𝑒 𝐻𝑆𝑆 𝑇𝑇𝑜𝑡𝑀𝑀𝑙 𝑀𝑀𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝑀𝑀𝑙𝑙 𝑢𝑠𝑒𝑟𝑠 𝑖𝑖𝑖𝑖 𝑡ℎ𝑒 𝐻𝑆𝑆

Figure 40: Problem Zone Load Sharing metric

The PZLS metric for a single HS scenario is shown in Figure 40. The metric PZLS indicates to what extent a hotspot is served by a single cell. In other words, it indicates the amount of load of the HS that is carried by a cell.

Neighbour Problem Zone Coverage (NPZC): In interference limited scenarios, the coverage of a cell is limited mainly due to the interference from the neighbouring cells. Therefore, in the absence of interferers in such a region the actual coverage of the cell might be larger. This knowledge is used in bringing another metric that captures the possible coverage of a higher frequency layer that is larger than the current frequency layer. The metric Neighbour Problem Zone Coverage (NZPC) is defined as the ratio of the amount of traffic carried by the users of neighbouring cells that are in the hotspot and within ‘X’ dB of the current cell’s signal strength and the total amount of traffic carried by the hotspot users.

𝑁𝑃𝑍𝐶 =

𝐴𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝐻𝑆𝑆 𝑢𝑠𝑒𝑟𝑠 𝑜𝑓 𝑖𝑖𝑒𝑖𝑖𝑔ℎ𝑏𝑜𝑢𝑟𝑖𝑖𝑖𝑖𝑔 𝑐𝑒𝑙𝑙 𝑡ℎ𝑀𝑀𝑡 𝑀𝑀𝑟𝑒 𝑤𝑖𝑖𝑡ℎ𝑖𝑖𝑖𝑖 𝑋 𝑑𝐵 𝑜𝑓 𝑐𝑢𝑟𝑟𝑒𝑖𝑖𝑡 𝑐𝑒𝑙𝑙′𝑠 𝑠𝑖𝑖𝑔𝑖𝑖𝑀𝑀𝑙 𝑠𝑡𝑟𝑒𝑖𝑖𝑔𝑡ℎ

𝑇𝑇𝑜𝑡𝑀𝑀𝑙 𝑀𝑀𝑚𝑜𝑢𝑖𝑖𝑡 𝑜𝑓 𝑡𝑟𝑀𝑀𝑓𝑓𝑖𝑖𝑐 𝑐𝑀𝑀𝑟𝑟𝑖𝑖𝑒𝑑 𝑏𝑦 𝑀𝑀𝑙𝑙 𝐻𝑆𝑆 𝑢𝑠𝑒𝑟𝑠



Figure 41: Neighbour problem zone coverage metric

Based on this metric, it could be estimated if there exists a cell that currently do not cover any users of the HS but has the potential to cover those HS users and offload them from the overloaded HS cells. Some cells in the hotspot area appear both in the PZC and NPZC metrics as they are serving some HS users and also have potential to serve neighbouring cell’s users (in terms of coverage aspect only). A value of 6 dB is used for the threshold ‘X’ in the above equation for generating these results.

Selection of Upgrade Option for Evaluation: Based on the three metrics mentioned above, namely PZC, PZLS and NPZC, the candidates for the upgrades are chosen. Different thresholds are used while using the combination of the metrics mentioned above. The metric PZLS indicates the extent of the HS that is served by the cell and therefore it is used as a basic metric to derive threshold for other metrics. The method used for such a threshold is based on gauge shown in Figure 42. The reason for selecting such a shape of the curve is that when a given cell is covering a large region of the hotspot, other metrics are not so important to judge that the cell needs to be part of the upgrade option evaluation. Whereas when the cell covers (or potentially cover) a small region of the hotspot, then only if the substantial fraction of the traffic carried by the cell is coming from the hotspot region, then the cell will be considered to be part of the candidate for upgrade evaluations.

Figure 42: A relation between PZLS+NPZC and the threshold for PZC

𝑇𝑇𝑀𝑀𝑀𝑀𝑀𝑀

PZC

Select the cell for upgrade option evaluation if the cell maps in this

region

PZLS + NPZC

𝑇𝑇𝑀𝑀𝑖𝑖𝑖𝑖

𝑆𝑆𝑀𝑀𝑖𝑖𝑖𝑖 𝑆𝑆𝑀𝑀𝑀𝑀𝑀𝑀



The thresholds used in identifying the candidates for upgrade option generation based on Figure 42 are:

𝑇𝑇𝑀𝑎𝑥 = 0.3,𝑇𝑇𝑀𝑖𝑛 = 0.05,𝑆𝑆𝑀𝑎𝑥 = 0.25,𝑆𝑆𝑀𝑖𝑛 = 0.1 Also, for any intermediate value of the sum of PZLS and NPZC, the corresponding value based on the slope of the line between 𝑆𝑆𝑀𝑖𝑛and 𝑆𝑆𝑀𝑎𝑥is used. As mentioned before, the values of the thresholds are chosen based on the reasoning that the cell needs to be selected for evaluation when the cell is covering large region of the hotspot and also when the fraction of the amount of traffic generated by the users in the hotspot for a cell to the total amount of traffic carried by the cell is large. Using this as the basis, the scenario that was considered for the bar plots of Figure 39, Figure 40 and Figure 41 will yield the following candidate locations. 𝐶𝑀𝑀𝑖𝑖𝑑𝑖𝑖𝑑𝑀𝑀𝑡𝑒 𝐿𝑜𝑐𝑀𝑀𝑡𝑖𝑖𝑜𝑖𝑖𝑠= � 13,15,88,89,90,135,196,197,199,

200,201,202,203,204,205,206,207,208,209,210,211,212,215,217,218,219,221,222,223�

The selected cells are shown geographically in the Figure 43. The procedure was used for other radius sizes and location of the HS, and showed promising results that could be directly used for candidate list generation.

Figure 43: Selected cells for upgrade option generation

Upgrade Option Grouping The upgrade options generated are grouped accordingly to their easiness of carrying out the upgrade in terms of whether they are co-located or not. The macro cells from the same site are the best example of such a grouping method and also small cells having common backhaul connectivity could be another example. In this stage for the scenario under consideration, the macro cells from the same site are grouped as a single upgrade option. Based on this, the upgrade options selected for evaluation options for the considered scenario are:



𝐶𝑀𝑀𝑖𝑖𝑑𝑖𝑖𝑑𝑀𝑀𝑡𝑒 𝐿𝑜𝑐𝑀𝑀𝑡𝑖𝑖𝑜𝑖𝑖𝑠= � 13,𝟏𝟒, 15,88,89,90,𝟏𝟑𝟑,𝟏𝟑𝟒, 135,196,197,199,

200,201,202,203,204,205,206,207,208,209,210,211,212,215,217,218,219,221,222,223�

In [29], a network evolution is studied wherein it was found that in low rise cities, every macro site deployment is equivalent to deploying five small cells in terms of performance improvements. The authors in [29] describe that, as no new site addition is considered but only upgrades in terms of carriers, the degree of freedom in choosing the sites will be lost. This will especially impact the small cells as they have smaller coverage region. Therefore, in our study, a macro site is said to be equivalent to eight small cells and this will be used as a grouping criterion. The number eight is chosen based on some coverage analysis in the scenario considered and therefore could vary from scenario to scenario. Based on the resultant candidate cells and the small cell to macro cell deployment results from [29], the candidates are grouped into certain joint upgrade options. Based on this logic, a grouped upgrade option has been generated and is given in Table 13.

Table 13: Grouped upgrade options to be evaluated Upgrade option name Candidate cells for evaluation Group – 1 {13,14,15,88,89,90} Group – 2 {Small Cell Set-1, Small Cell Set-2} Group – 3 {13,14,15, Small Cell Set-1} Group – 4 {88,89,90, Small Cell Set-1} Group – 5 {13,14,15, Small Cell Set-2} Group – 6 {88,89,90, Small Cell Set-2} Group – 7 {13,14,15,88,89,90, Small Cell Set-1} Group – 8 {13,14,15,88,89,90, Small Cell Set-2} Group – 9 {13,14,15,Small Cell Set-1,Small Cell Set-2} Group – 10 {88,89,90, Small Cell Set-1,Small Cell Set-2} Group – 11 {13,14,15,88,89,90,Small Cell Set-1,Small Cell Set-2} In Table 13, the small cells are grouped into two sets and their actual contents are:

𝑆𝑆𝑚𝑀𝑀𝑙𝑙 𝐶𝑒𝑙𝑙 𝑆𝑆𝑒𝑡 − 1 = {1,2,6,7,8,9,10,11} 𝑆𝑆𝑚𝑀𝑀𝑙𝑙 𝐶𝑒𝑙𝑙 𝑆𝑆𝑒𝑡 − 2 = {14,15,16,17,20,26,27,28}

This grouping is based on the geographical locations of the small cells. The reason for grouping the cells based on the geographical vicinity is to provide the opportunity to share the possible wireless backhaul link to reduce the overhead of using separate backhaul link for each small cell.

7.3.2.3 Upgrade Options Evaluation The upgrade options generated in Section 7.3.2.2 are evaluated in the corresponding scenario for which the upgrade options were generated. The upgrade options are evaluated based on the quality, durability and cost (refer to Section 7.3.1 for basic definitions) of the upgrade option.

Upgrade Option Evaluation Criterion: Three basic criterions are considered for upgrade option evaluation.

1. Quality of the upgrade option: This metric will indicate if the upgrade option will resolve the problem for which the problem zone was identified at the first place. In the simulations, the cause for the generation of the problem zone is the load in the cell exceeding a threshold (80% average utilisation in the cell).



The chosen upgrade option is said to fulfil the quality if it brings down the load in the cell to less than the threshold (80%).

𝑄𝑢𝑀𝑀𝑙𝑖𝑖𝑡𝑦 = �1 𝑖𝑖𝑓 𝐶𝑒𝑙𝑙𝐿𝑜𝑀𝑀𝑑𝑖 < 0.8 ∀ 𝑖𝑖0 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑖𝑠𝑒

�

2. Durability of the upgrade option:

This metric will indicate how long the upgrade option resolves the problem in the area. This is expressed in terms of time duration for which the upgrade Quality metric is satisfied.

𝐷𝑢𝑟𝑀𝑀𝑏𝑖𝑖𝑙𝑖𝑖𝑡𝑦 = 𝑇𝑇𝑚𝑎𝑥 ∣ 𝑄𝑢𝑀𝑀𝑙𝑖𝑖𝑡𝑦 𝑀𝑀𝑡 𝑡𝑖𝑖𝑚𝑒 ′𝑡′ = 1 ∀ 𝑡 ≤ 𝑇𝑇𝑚𝑎𝑥

𝑄𝑢𝑀𝑀𝑙𝑖𝑖𝑡𝑦 𝑀𝑀𝑡 𝑡𝑖𝑖𝑚𝑒 ′𝑡′ = 0 ∀ 𝑡 > 𝑇𝑇𝑚𝑎𝑥

3. Cost of the upgrade option:

The cost of upgrading an existing site with additional carriers will involve costs with respect to hardware for the front end and also possibly for the backhaul due to the increased load. In order to avoid getting into the exact numbers, the cost of the upgrade option is computed in relative terms. To begin with, a macro cell upgrade with multi carrier capability is assumed to be ‘X’ times costlier than a small cell upgrade with multi carrier capability. Therefore, the cost of upgrading a small cell with additional carrier is expressed as:

𝐶𝑜𝑠𝑡𝑆𝑚𝑎𝑙𝑙𝐶𝑒𝑙𝑙 = 𝐶𝑜𝑠𝑡𝑀𝑎𝑐𝑟𝑜𝐶𝑒𝑙𝑙

𝑋

Upgrade Option Evaluation Results: For the example scenario of the HS that is used in the upgrade option generation section, the evaluation was carried out. The results of using different upgrade options in terms of the durability of the upgrade option based on the quality criterion is shown in Figure 44. In the figure, four additional upgrade options were also evaluated (these upgrade options cover upgrading only one of the two macro sites or the small cell related upgrades wherein either Small Set-1 or Small Set-2 is upgraded). The y-axis in the Figure 44 is in terms of the time but with no particular time index. This is because the y-axis indicate in terms of scaling of the traffic in the hotspot (with a granularity of 50% increase for every unit increase along the y-axis) and the surrounding region (with a granularity of 5% increase for every unit increase along the y-axis), and such a scaled model could be interpreted in terms of time based on the expected traffic growth by the operator in the near future. Note that the evaluations in terms of durability will purely act as a metric to see the effectiveness of the upgrade options but do not cover the feasibility in terms of cost of the upgrade option.



Figure 44 : Different upgrade evaluation in terms of durability of the upgrades.

A relative cost based view point could be tabulated for each of the upgrade option evaluated in Figure 44 and is shown in Table 14. The method used for the calculation of the relative cost is given in above.

Table 14 : Upgrade option relative cost metric Upgrade option name Relative Cost of the upgrade Group – 1 𝐶𝑜𝑠𝑡𝑀𝑎𝑐𝑟𝑜𝐶𝑒𝑙𝑙 ∗ 6 Group – 2 𝐶𝑜𝑠𝑡𝑀𝑎𝑐𝑟𝑜𝐶𝑒𝑙𝑙 ∗ 16

𝑋

Group – 3 𝐶𝑜𝑠𝑡𝑀𝑎𝑐𝑟𝑜𝐶𝑒𝑙𝑙 ∗ 3 + 𝐶𝑜𝑠𝑡𝑀𝑎𝑐𝑟𝑜𝐶𝑒𝑙𝑙 ∗ 8

𝑋


𝑋


𝑋


𝑋


𝑋


𝑋


𝑋


𝑋


𝑋

The results from Table 14 and Figure 44 will be presented to the operator so that the operator can choose the upgrade option that suits the best both in terms of cost and quality of the upgrade option.



7.3.2.4 Conclusions In the new carrier addition aspects of the DSS-SNM use case, a two-step approach is adapted wherein the first step involves the intelligent generation of the upgrade options and the second step involves evaluation of the upgrade options to provide a qualitative and economical view point of the upgrade options. In the upgrade option generation phase, different upgrades are grouped under a single upgrade option to formulated a more feasible option in terms of ease of deployment for the operator. The results shown in the upgrade option evaluation phase clearly highlight the durability of the upgrade option and a relative cost metric for the upgrade option.



8 Summary and Future Work The SEMAFOUR Work Package 5 results provided a remarkable step forward in the efforts to simplify the mobile network operators’ network operations and management processes, by providing a framework that supports the full automation of the SON system, with scalable and context-specific SON capabilities and means to easily implement strategic decisions. A proof-of-concept of the developed framework and its functional components has been carried out through their implementation into the common SEMAFOUR simulation platform, namely, the SONLAB environment. The implementation has validated the WP5 vision by providing the first results on specific scenarios. In particular, it could be visualised through the SEMAFOUR demonstrator that operator-provided changes to the technical objectives, i.e., KPI targets, of the SON-enabled network are automatically turned in the appropriate SON (and hence network) configuration without requiring additional interventions by the human operator. This appropriate configuration is automatically adapted in case of changes to the network context, always keeping the network at its optimal configuration (at least in so far as this can be influenced by the SON system). In this document the requirements and necessary means for bringing the implementation of Integrated SON Management into operational networks have been elaborated. While changes to the initially developed functional architecture (cf. SEMAFOUR deliverable D2.2 [3] and D5.1 [4]) as described in Chapter 2 are mainly related to findings during the development and implementation process within WP5, the implementation issues related to operator processes as described in Chapter 3 and to standardisation as described in Chapter 4 give an indication where the major potential barriers are located. Where manual operational processes are well-defined and understood (as, for example, at the level of network element), the development of an automation solution is not necessarily straightforward but feasible. In case such well-defined processes do not exist, this becomes difficult. This has been the main obstruction in the efforts of WP5 to use operator-defined high-level (strategic, business, customer-related) goals as input for SON management. Yet, at the level of technical objectives, i.e., KPI targets as input, the original goal has been met. And the solution for PBSM, for example, will have impact to the operational processes at the higher level as well, but this impact mainly appears at the day-to-day network operations and engineering, and the corresponding teams within an operator’s organisation. In so far the realisation of an Integrated SON Management solution within the process landscape of a mobile network operator is expected to be manageable. With respect to 3GPP standardisation impact several implementation options for the different Integrated SON Management components have been analysed. In particular those components having a functional scope that spans between the network elements and SON function access on the one side, and the Operations and Support Systems on the other side (namely, MD and PBSM) are likely to be brought to the 3GPP standardisation process in order to enable their realisation in particular in multi-vendor environments. Due to the integrative characteristics of these components, this work could not be conducted during the runtime of the SEMAFOUR project, as the results for all these components including the results of WP4 had to be present first. However, the goal is to prepare a corresponding input in particular to 3GPP TSG SA5. As an outlook to the future, where the current evolution of mobile networks towards 5G systems again leads to an increased level of network heterogeneity (related with network deployment layers, frequency bands & regimes, simultaneous connectivity, etc.), network planning, operation, administration and management will require a holistic end-to-end approach, capable of supporting seamless management of multiple network segments and even multiple network domains. In addition, the inclusion of new services into the operators’ portfolio (e.g., Internet of Things, tactile internet, …), directly puts new requirements to the network management and operation, where the optimisation of network resources according to these services again moves the focus to the end-to-end benefit. Finally, the development and introduction of new technology trends, including Software Defined Networks, Centralised RAN and Network Function Virtualisation will introduce a completely new definition of what a network node is. With the capability of “flexible functional split” and “flexible functional



mobility”, network functions or network services can be broken into elementary functional units that can be either centralised or distributed in a flexible way. This enables the physical network nodes to be composed of “off-the-shelf hardware” with multiple capabilities, introducing a much higher degree of freedom that will challenge today’s SON approach and therefore also the SEMAFOUR concept of Integrated SON Management. One approach to cope with all these requirements is cognition, or self-learning, with the goal to enable network management and operation to become aware of its context and requirements by itself. First steps in this direction have already been taken within WP5, for example, through the learning of SON Function Models in PBSM (cf. Chapter 5) or the learning of SON coordination effects (cf. Chapter 6).



9 References

[1] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 5.2, ‘Integrated SON Management – Policy Transformation and Operational SON Coordination (first results)’," [Online] available at http://www.fp7-semafour.eu, May 2013.

[2] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 5.3, ‘Integrated SON Management – Policy Transformation and Operational SON Coordination (final results)’," February 2015.

[3] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 2.2, 'Definition of Requirements for a Unified Self-Management System'," [Online] available at http://www.fp7-semafour.eu, July 2013.

[4] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 5.1, ‘Integrated SON Management – Requirements and Basic Concepts’," [Online] available at http://www.fp7-semafour.eu, December 2013.

[5] O. Iacoboaiea, B. Sayrac, S. Ben Jemaa and P. Bianchi, "SON Conflict Diagnosis in Heterogeneous Networks," in IEEE 26th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Hong Kong, China, August 2015.

[6] O. Iacoboaiea, B. Sayrac, S. Ben Jemaa and P. Bianchi, "SON Coordination in Heterogeneous Networks: A Reinforcement Learning Framework.," submitted to Transactions on Wireless Communications, 2015.

[7] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable D3.4, 'Demonstration Scenarios (updated version)'," May 2015.

[8] C. Frenzel, S. Lohmüller and L. C. Schmelz, "Dynamic, Context-Specific SON Management Driven by Operator Objectives," in IEEE/IFIP Network Operations and Management Symposium (NOMS), Krakow, Poland, May 5-9, 2014.

[9] C. Frenzel, S. Lohmüller and L. C. Schmelz, "SON Management based on Weighted Objectives and Combined SON Function Models," in ISWCS 2014 - Fourth International Workshop on Self-Organizing Networks (IWSON 2014), Spain, Barcelona, August 26, 2014.

[10] 3GPP TS 32.102, "Telecommunication management; Architecture," v12.0.0, September 2014. [11] 3GPP TS 32.522, "Self-Organizing Networks (SON) Policy Network Resource Model (NRM)

Integration Reference Point (IRP); Information Service (IS)," v.11.7.0, September 2013. [12] 3GPP TS 32.622, "Generic network resources Integration Reference Point (IRP); Network

Resource Model (NRM)," v11.1.0, June 2013. [13] 3GPP TS 32.425, "Performance Management (PM); Performance measurements Evolved

Universal Terrestrial Radio Access Network (E-UTRAN)," v13.1.0, March 2015. [14] 3GPP TS 32.450, "Key Performance Indicators (KPI) for Evolved Universal Terrestrial Radio

Access Network (E-UTRAN): Definitions," v12.0.0, October 2014. [15] 3GPP TS 32.342, "File Transfer Integration Reference Point (IRP), Information Service (IS),"

v12.0.0, October 2014. [16] 3GPP TS 28.628, "Telecommunication management; Self-Organizing Networks (SON) Policy

Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)," v13.0.0, March 2015.

[17] O. Iacoboaiea, B. Sayrac, S. Ben Jemaa and P. Bianchi, "Local SON Conflict Resolution using Reinforcement Learning," in All things Cellular Workshop (SIGCOMM 2014), 2014.

[18] T. Bandh, G. Carle, H. Sanneck and L.-C. Schmelz, "Automated Real Time Performance Management for Mobile Networks," in IEEE WoWMoM Workshop on Autonomic Wireless AccesS 2007 (IWAS07), Helsinki, Finland, 2007.



[19] P. Gustas, P. Magnusson, J. Oom and N. Storm, "Real-time performance monitoring and optimization of cellular systems," Ericsson Review, vol. 79, no. 1, pp. 4-13, 2002.

[20] S. Hahn, S. Lohmüller, D. Götz and T. Kürner, "Classification of Cells Based on Mobile Network Context Information for the Management of SON Systems," VTC-Spring, Fifth International Workshop on Self-Organizing Networks (IWSON 2015), 2015.

[21] T. Jansen, I. Balan, J. Turk, I. Moerman and T. Kürner, "Handover parameter optimization in LTE self-organizing networks," 2010 IEEE 72nd Vehicular Technology Conference (VTC2010-Fall), Canada, Ottawa, September 6th-9th, 2010.

[22] A. Lobinger, S. Stefanski, T. Jansen and I. Balan, "Load Balancing in Downlink LTE Self-Optimizing Networks," 2010 IEEE 71th Vehicular Technology Conference (VTC2010-Spring), Taiwan, Taipei, May 16th-19th, 2010.

[23] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 4.2, SON Functions for Multi-Layer LTE and Multi-RAT Networks (Final Results)'," August 2014.

[24] D. M. Rose, J. Baumgarten, S. Hahn and T. Kürner, "SiMoNe – Simulator for Mobile Networks: System-Level Simulations in the Context of Realistic Scenarios," VTC-Spring, Fifth International Workshop on Self-Organizing Networks (IWSON 2015), May 2015.

[25] S. Hahn and T. Kürner, "Managing and Altering Mobile Radio Networks by Using SON Function Performance Models," in ISWCS 2014 - Fourth International Workshop on Self-Organizing Networks (IWSON 2014), Spain, Barcelona, August 26, 2014.

[26] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 4.3, 'SON functions for integrated multi-layer and multi-RAT networks'," June 2015.

[27] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable D3.5, 'Demonstrator (full-fledged, results-oriented version) - video recording'," August 2015.

[28] EU FP7 project SEMAFOUR (Self-management for unified heterogeneous radio access networks), "Deliverable 2.5, 'Definition of Reference Scenarios, Modelling Assumptions and Methodologies (Final Results)'," February 2015.

[29] J.-P. Charles, A. Furuskär, M. Frodigh, S. Jeux, M. S. Hassan, A. Saadani, A. Stidwell, J. Söder and B. Timus, "Refined Statistical Analysis of Evolution Approaches for Wireless Networks," IEEE Transactions on Wireless Communications, vol. 14, no. 5, pp. 2700-2710, May 2015.

Documents

INFSO-ICT-316384 SEMAFOUR D5.4 Integrated SON …cordis.europa.eu/docs/projects/cnect/4/316384/080/deliverables/001... · The results of this analysis work are explained in detail