SOCRATES

D2.1

INFSO-ICT-216284 SOCRATES D2.1 Use Cases for Self-Organising Networks

Contractual Date of Delivery to the CEC: 31.03.08 Actual Date of Delivery to the CEC: Authors: 31.03.08

Neil Scully, Stefan Thiel, Remco Litjens, Ljupco Jorguseski, Renato Nascimento, Ove Linnell, Kristina Zetterberg, Mehdi Amirijoo, Chris Blondia, Kathleen Spaey, Ingrid Moerman, Irina Balan, Thomas Krner, Andreas Hecker, Thomas Jansen, Jakub Oszmianski, Lars Christoph Schmelz Hans van den Berg, Andreas Eisenbltter VOD, TNO, ATE, EAB, IBBT, TUBS, NSN-PL, NSN-D WP2 Use cases and framework 12 PU R 1.0 71

Reviewers: Participants: Workpackage: Estimated person months: Security: Nature: Version: Total number of pages:

Abstract: The SOCRATES (Self-Optimisation and self-ConfiguRATion in wirelEss networkS) project aims at the development of self-organisation methods for LTE radio networks. Self-organisation comprises selfoptimisation, self-configuration and self-healing. As one of the first steps in the project a number of use cases has been set up. Each use case provides a description of a functionality to be made self-organising. The use cases also point out what the solutions, to be developed in the SOCRATES project, should achieve. Keyword list: Self-organisation, self-configuration, self-optimisation, self-healing, LTE, E-UTRA, radio interface, use cases

Page 1 (71)

SOCRATES

D2.1

Executive Summary
Future communication networks will benefit from a significant degree of self-organisation. The principal objective of introducing self-organisation is to alleviate network operations while improving network quality. This shall substantially reduce the need for human intervention in network operations, yielding significant reductions in operational expenditure (OPEX). Self-organisation comprises self-optimisation, self-configuration, and self-healing. The SOCRATES (Self-Optimisation and self-ConfiguRATion in wirelEss networkS) project develops self-organisation methods for LTE radio networks. The focus is on integrating three traditional steps in network operations into one single, mostly integrated process. These steps are network planning, configuration, and optimisation. Use cases are an established means of describing what a solution to a particular problem shall achieve. In particular, in this document, as a first step in the SOCRATES project, use cases are used to describe functionalities to be made self-organising and to specify their desired effects. A total of 24 use cases have been identified. These use cases cover important aspects of LTE radio network operations such as preoperational parameter planning, radio parameter optimisation, and cell outage management. For some of these use cases, 3GPP is already considering the implications on standardisation, but few final decisions have yet been made. Others, such as admission control parameter optimisation, have received little attention so far. (Note that 3GPP does not intend to standardise full technical solutions to the use cases. The focus of 3GPP is on technical enablers such as measurement capabilities, harmonised notions of quality indicators, interfaces, and flexible protocols.) The use cases are analysed in detail. In each case this comprises in which situation to apply the use case and with which objectives, the required input data, the desired output parameters, the actions to be conducted, possible dependencies on further standardisation, and an initial assessment of its potential gain in terms of OPEX / CAPEX reduction as well as quality improvements. The significant potential for self-organisation in LTE networks is evident from the examination of the described 24 use cases. The subsequent steps are as follows. Technical aspects of the implementation and details on how to assess the individual effect on network operations will be developed in Activities 2.2 and 2.3. The interdependencies among the use cases will be analysed in Activity 2.4. Using the results and insights obtained from these activities, a selection of use cases will be made for which technical solutions are to be developed in WP3 (Self-optimisation) and WP4 (Self-configuration and selfhealing).This selection will, in particular, be based on answers to the following questions: Is the use case already extensively considered elsewhere? Is SOCRATES likely to contribute to progress beyond stateof-the-art for this use case? Is there sufficient reason to believe that a worthwhile gain can be achieved from this use case?

Page 2 (71)

SOCRATES

D2.1

Authors
Partner Name Phone / Fax / E-mail

VOD

Neil Scully

Phone: +44 1635 682380 Fax: +44 1635 676147 E-mail: Neil.Scully@vodafone.com Phone: +44 1635 673964 Fax: +44 1635 676147 E-mail: Stefan.Thiel@vodafone.com

Stefan Thiel

TNO

Remco Litjens

Phone : +31 6 5191 6092 Fax: +31 15 285 7375 E-mail: remco.litjens@tno.nl Phone: +31 6 5121 9560 Fax: +31 15 285 7370 E-mail: ljupco.jorguseski@tno.nl Phone: +31 6 5310 8732 Fax: +31 15 285 7370 E-mail: renato.nascimento@tno.nl

Ljupco Jorguseski

Renato Nascimento

EAB

Ove Linnell

Phone: +46 13 284136 Fax: +46 13 287567 E-mail: ove.linnell@ericsson.com Phone: +46 13 284854 Fax: +46 13 287567 E-mail: kristina.zetterberg@ericsson.com Phone: +46 13 322290 Fax: +46 13 287567 E-mail: mehdi.amirijoo@ericsson.com

Kristina Zetterberg

Mehdi Amirijoo

IBBT

Chris Blondia

Phone: +32 (0)3 265.39.03 Fax: +32 (0)3 265.37.77. E-mail: chris.blondia@ua.ac.be Phone: +32 (0)3 265.38.80 Fax: +32 (0)3 265.37.77. E-mail: kathleen.spaey@ua.ac.be Phone: +32 (0) 9 33 14925 Fax: +32 (0) 9 33 14899 E-mail: ingrid.moerman@intec.UGent.be Phone: +32 (0) 9 33 14975 Fax: +32 (0) 9 33 14899 E-mail: irina.balan@intec.ugent.be

Kathleen Spaey

Ingrid Moerman

Irina Balan

Page 3 (71)

SOCRATES

D2.1

TUBS

Thomas Krner

Phone: +49 531 391 2416 Fax: +49 531 391 5192 E-mail: kuerner@ifn.ing.tu-bs.de Phone: +49 531 391 2406 Fax: +49 531 391 5192 E-mail: hecker@ifn.ing.tu-bs.de Phone: +49 (0)531 391 2486 Fax: +49 (0)531 391 5192 E-mail: jansen@ifn.ing.tu-bs.de

Andreas Hecker

Thomas Jansen

NSN-PL

Jakub Oszmianski

Phone: +48 71 777 3280 Fax: +48 71 777 4610 E-mail: jakub.oszmianski@nsn.com

NSN-D

Lars Christoph Schmelz Phone: +49 89 636-79585 Fax: +49 89 636-75147 E-mail: lars.schmelz@nsn.com

Page 4 (71)

SOCRATES

D2.1

List of Acronyms and Abbreviations

3GPP aGW ARQ ATM BCH BLER BS BTS C/I CN DHCP DL DoS EDGE eNB eNodeB E-UTRA E-UTRAN FDD FFS GERAN GoS GPS GSM HII HO HSPA HW ICIC ID IP KPI LA LTE MA MAC MME MOC MTC NE NEM NGMN NodeB O&M OAM OFDM OFDMA OMC OPEX OSS PA PBCH PCFICH PDCCH PDSCH PHICH Third Generation Partnership Project Access Gateway Automatic repeat-request Asynchronous Transfer Mode Broadcast CHannel BLock Error Rate Base Station Base Transceiver Station Carrier to Interference ratio Core Network Dynamic Host Configuration Protocol DownLink Denial of Service Enhanced Data Rates for GSM Evolution eNodeB E-UTRAN NodeB Evolved Universal Terrestrial Radio Access Evolved Universal Terrestrial RAN Frequency Division Duplex For Further Study GSM EDGE RAN Grade of Service Global Positioning System Global System for Mobile communications High Interference Indicator HandOver High-Speed Packet Access HardWare Inter Cell Interference Cancellation IDentity Internet Protocol Key Performance Indicator Location Area Long Term Evolution Movement Area Media Access Control Mobility Management Entity Mobile Originated Call Mobile Terminated Call Network Element Node Element Manager Next Generation Mobile Network Base station Operations and Maintenance Operations, Administration, and Maintenance Orthogonal Frequency Division Multiplexing Orthogonal Frequency-Division Multiple Access Operations and Maintenance Centre OPerational EXpenditure Operations Support System Paging Area Physical Broadcast CHannel Physical Control Format Indicator CHannel Physical Downlink Control CHannel Physical Downlink Shared CHannel Physical Hybrid ARQ Indicator CHannel

Page 5 (71)

SOCRATES PM PMCH PRACH PRB PUCCH PUSCH QoS RA RACH RAN RAT RB RP RRM RS RSRP SAE SCH SINR SOCRATES SON SRS SW TA TAC TAI TAP TAU TDD UE UL UMTS UPE URA VLA WCDMA WWW Performance Measurement Physical Multicast CHannel Physical Random Access CHannel Physical Resource Block Physical Uplink Control CHannel Physical Uplink Shared CHannel Quality of Service Routing Area Random Access CHannel Radio Access Network Radio Access Technology Radio Bearers RACH parameters Radio Resource Management Reference Signal Reference Signal Received Power System Architecture Evolution Synchronisation CHannel Signal to Interference and Noise Ratio Self-Optimisation and self-ConfiguRATion in WirelEss NetworkS Self Organising Network Sounding RS SoftWare Tracking Area TA Code TA Identity TA Parameters TA Update Time Division Duplex User Equipment UpLink Universal Mobile Telecommunications System User Plane Entity User Registration Area Virtual LA Wideband Code Division Multiple Access World Wide Web

D2.1

Page 6 (71)

SOCRATES

D2.1

Table of Contents
1 Introduction ................................................................................................. 8
1.1 1.2 Self-organisation in future radio access networks ....................................................................... 8 Use cases for self-organisation .................................................................................................... 9

2 Self-configuration use cases ................................................................... 11

2.1 Planning and deployment .......................................................................................................... 11 2.1.1 Intelligently selecting site locations .................................................................................. 11 2.1.2 Automatic generation of default parameters for NE insertion .......................................... 13 2.2 Non-radio................................................................................................................................... 15 2.2.1 Network authentication ..................................................................................................... 15 2.2.2 Hardware/capacity extension ............................................................................................ 17

3 Self-optimisation use cases..................................................................... 19

3.1 Radio network optimisation....................................................................................................... 19 3.1.1 Interference coordination .................................................................................................. 19 3.1.2 Self-optimisation of physical channels ............................................................................. 21 3.1.3 RACH optimisation........................................................................................................... 23 3.1.4 Self-optimisation of home eNodeB................................................................................... 26 3.2 GoS/QoS related parameter optimisation .................................................................................. 29 3.2.1 Admission control parameter optimisation ....................................................................... 29 3.2.2 Congestion control parameter optimisation ...................................................................... 31 3.2.3 Packet scheduling parameter optimisation ........................................................................ 33 3.2.4 Link level retransmission scheme optimisation ................................................................ 35 3.2.5 Coverage hole detection.................................................................................................... 38 3.3 Handover related optimisation................................................................................................... 40 3.3.1 Handover parameter optimisation ..................................................................................... 40 3.3.2 Load balancing.................................................................................................................. 42 3.3.3 Neighbour cell list............................................................................................................. 46 3.4 Other.......................................................................................................................................... 46 3.4.1 Reduction of energy consumption..................................................................................... 46 3.4.2 Tracking areas ................................................................................................................... 49 3.4.3 TDD UL/DL switching point ............................................................................................ 54 3.4.4 Management of relays and repeaters................................................................................. 57 3.4.5 Spectrum sharing............................................................................................................... 59

4 Self-healing use cases.............................................................................. 60

4.1 Cell outage management ........................................................................................................... 60 4.1.1 Cell outage prediction ....................................................................................................... 61 4.1.2 Cell outage detection......................................................................................................... 63 4.1.3 Cell outage compensation ................................................................................................. 66

5 Concluding remarks ................................................................................. 70

Page 7 (71)

SOCRATES

D2.1

Introduction

Future communication networks will benefit from a significant degree of self-organisation. The principal objective of introducing self-organisation, comprising self-optimisation, self-configuration and selfhealing, is to effectuate substantial operational expenditure (OPEX) reductions by diminishing human involvement in network operational tasks, while optimising network efficiency and service quality. The SOCRATES (Self-Optimisation and self-ConfiguRATion in wirelEss networkS) project aims at the development of self-organisation methods to enhance the operations of LTE radio networks, by integrating network planning, configuration and optimisation into a single, mostly automated process requiring minimal manual intervention. SOCRATES primarily concentrates on wireless access networks, as the wireless segment generally forms the bottleneck in end-to-end communications, both in terms of operational complexity and network costs. As a consequence, the largest gains from self-organisation can be anticipated here. The 3GPP LTE (3rd Generation Partnership Project, Long Term Evolution) radio interface is the central radio technology in SOCRATES studies. This is because 3GPP LTE is the natural, highly promising and widely supported evolution of the worlds most popular cellular networking technologies (GSM/EDGE, UMTS/HSPA).

1.1

Self-organisation in future radio access networks

The envisioned operational process applied in self-organising radio access networks is illustrated by Figure 1.

Measurements
(Gathering and processing)

continuous loop

Setting parameters

Selfoptimisation

Selfconfiguration

Selfhealing

triggered by incidental events

Figure 1 Envisioned self-optimisation and configuration process in future radio access networks. Consider a fully configured and operational radio access network and, somewhat arbitrarily, start at the depicted measurements phase. This phase indicates a continuous activity where a multitude of measurements are collected via various sources, including network counters and probes. These raw

Page 8 (71)

SOCRATES

D2.1

measurements of e.g. radio channel characteristics, traffic and user mobility aspects, for example, are processed in order to provide relevant information for the various related self-optimisation tasks. The required format, accuracy and periodicity of the delivered information depend on the specific mechanism that is to be self-optimised. In the self-optimisation phase, the processed measurements are used to derive an updated set of radio parameters, including e.g. antenna tilts, power settings, neighbour lists and a range of radio resource management parameters. In case the self-optimisation methods are incapable of meeting the performance objectives, capacity expansion is indispensable and timely triggers with accompanying suggestions for human intervention are delivered, e.g. in terms of a recommended location for a new site. The self-configuration phase, depicted as an external arm reaching into the continuous self-optimisation cycle, is triggered by incidental events of an intentional nature. Examples are the addition of a new site and the introduction of a new service or new network feature. These upgrades generally require an initial (re)configuration of a number of radio parameters or resource management algorithms, e.g. pilot powers and neighbour lists. These have to be set prior to operations and before they can be optimised as part of the continuous self-optimisation process. Self-healing methods aim to resolve, to the extent possible, the loss of coverage/capacity triggered by incidental events of a non-intentional nature, such as the failure of a cell or site. This is done by adjusting the parameters and algorithms in surrounding cells. Once the actual failure has been repaired, all parameters are restored to their original settings.

1.2

Use cases for self-organisation

Before solutions for self-organising networks are developed, it is essential to have a clear common view on the situation and particular problems to be solved. For this purpose, use cases will be defined. A use case provides a description of a functionality to be made self-organising and points out what the solution should achieve. The particular goals of the use case descriptions in this document are: Identify where and how self-organising functionality can be applied Provide a basis for defining requirements for these use cases Specify what needs to be achieved, so that solutions can be developed based on that in WP3 (Self-optimisation) and WP4 (Self-configuration and self-healing) Provide input to the decision process so that use cases can be prioritised, and decisions can be made on which of them will be addressed first in WP3 and WP4.

For each use case, the following items are addressed: Description: A general description of what the use case is about, also providing some background information. The description will also include the classification into selfconfiguration, self-optimisation or self healing (or a combination of these). The area of relevance (planning, deployment, optimisation, maintenance) will also be included. Objective: This item describes what the use case aims to achieve, i.e. what problem(s) does it solve, or what optimisation(s) does it provide. Scheduling (Triggers): This will describe how often the functionality described by the use case is triggered, for example, whether it is periodical or continuous. A use case may also be triggered by a particular event. Input source: A description is provided on which input information is required for the use case. The solution will use the input information, and process it to determine appropriate parameter settings List of parameters: These are the parameters that will be adjusted by the self-organisation solution. Actions: This will describe at a high-level what the process is for the implementation of solutions for the use case Expected results: Here information will be given on how the mobile network will benefit from the use case, i.e. what will have improved. Status in 3GPP: As SON use cases are being considered in 3GPP standards, an overview will be given of the status in 3GPP.

Page 9 (71)

SOCRATES

D2.1

Measurements / parameters / interfaces to be standardised: Based on the above items, requirements for standardisation in 3GPP will be listed Architectural aspects: This will define the network architecture this is required. Particularly focus is on whether a distributed or centralised solution is preferred. Example (Informative description): A specific example is given of a scenario where the use case can be applied. Potential gain: The gain from the use case is estimated. There are different types of gain that can result from the use cases. The three main types of gain are: o OPEX and/or CAPEX reduction o Capacity and coverage improvement o QoS improvement Of course, these three types are closely related to each other. The gain described in this section will be just an initial estimate, based on technical expertise, rather than detailed study. The feasibility of implementing a solution will also be taken into account. Related use cases: A list of related use cases References: Particularly 3GPP/NGMN documents, but also other references.

In describing the use cases, input was taken from 3GPP and NGMN. However, for most use cases this document provides significantly more detail than was available from these sources. In addition, several use cases are included which have until now not been considered by 3GPP and NGMN. Where appropriate, references to 3GPP and NGMN documents have been provided. The decision on which use cases to include in this document was based on whether or not they were relevant to the 3GPP LTE radio interface. Inclusion in this document of a use case does not necessarily indicate that SOCRATES will work on that use case. That decision, to be made as part of Activity 2.4, will be based on: Is the use case already extensively considered elsewhere? Is SOCRATES likely to contribute to progress beyond state-of-the-art for this use case? Is there sufficient reason to believe that a worthwhile gain can be achieved from this use case? The use cases described in this document are divided into three categories, in line with the process described in Figure 1: Self-configuration (Chapter 2) Self-optimisation (Chapter 3) Self-healing (Chapter 4) For self-configuration, we distinguish two subcategories of use cases: Planning and deployment and Non-radio. These use cases focus on enabling a new eNodeB to be activated with minimal manual interaction required. For self-optimisation, the use cases are clustered in the subcategories Radio network optimisation, GoS/QoS related parameter optimisation, Handover related optimisation and Other. These use cases aim to maximise the efficiency with which the network resources are used. For selfhealing, there is just one subcategory: Cell outage management. This deals with situations related to hardware or software failure at the eNodeB.

Page 10 (71)

SOCRATES

D2.1

Self-configuration use cases

The self-configuration phase is generally seen as the first step within self-organisation, as it is the first occasion the system may adapt its set-up or parameters with regards to external influences. Within this document, self-configuration has been split into two subcategories: Planning and deployment (section 2.1) and Non-radio (section 2.2). We are also considering the following related use cases, which contain elements of self-configuration, but are listed elsewhere in this document. Self-optimisation of physical channels (section 3.1.2) Self-optimisation of home eNodeB (section 3.1.4) Tracking areas (section 3.4.2)

2.1
2.1.1

Planning and deployment

Intelligently selecting site locations
Self-optimisation (as input to self-configuration) Deployment

Description Classification: Area of relevance:

This use case is a mixture of classical performance management and network planning tasks. The use case thereby consists of two parts: Detection phase: identification of performance degradations and coverage gaps by near real time analysis of respective performance data (e.g. call drops, neighbour relationships, handover failures etc.) Solution phase: by using information about existing infrastructure (installed NE types, cell size, transmission power, antenna orientation), a solution to overcome the identified shortcomings is generated, which could e.g. be o higher transmission power of existing cells o cell split o re-location of existing antenna o installation of additional NE(s) For the first two solutions, the system could also recommend a temporary re-configuration of dedicated NEs or cells if the performance degradation only occurs infrequently within dedicated time windows, e.g. few times per week for some minutes only. For the latter two solutions, a proposal for a new location is calculated, thereby using available geographical information or potential antenna locations. It is clear that this use case does not apply for the initial setup of a newly deployed network at least some installed base is necessary, otherwise the detection phase cannot work. Objective The main objectives for this use case are: Detect and identify performance degradations and coverage holes during operation (near real time), without requiring subsequent extensive calculation from aggregated performance measurements (usually on a weekly or monthly basis) Reduce reaction time on performance degradations to minimise service interruption Reduce manual effort for the optimisation of the network and coverage Scheduling (Triggers) The trigger for automated identification and selection of new site locations or enhancement of existing locations requires either a continuous or at least a periodical analysis of appropriate performance measurement data. The attainment of pre-defined or self-learned threshold values triggers the solution phase. For example, an operator could define a dedicated number of call drops in the affected area due to bad coverage or small bandwidth during daytime or busy hours as threshold.

Page 11 (71)

SOCRATES

D2.1

Input source Input sources are performance measurements or KPIs as they are already today used for long-term network performance management. However, to automate the corresponding tasks the measurement periods may have to be shortened, since periods of 30 minutes or above may not be sufficient to allow a fine granular analysis of coverage or bandwidth problems, especially during busy hours.. List of parameters The list of parameters to be influenced and modified depends on the results of the solution phase. In case the solution can be achieved by the modification of settings and parameters at operational NEs (e.g. transmission power, cell configuration, etc.) the solution can be applied automatically and instantly (selfoptimisation). For solutions that require hardware modifications or the insertion of new NEs, the new network configuration can be prepared to accelerate the subsequent configuration update. Actions Detection phase: Acquisition of dedicated performance data (e.g. call drop rate, signal strength of neighbouring nodes, handover failure rate, number of call attempts, signal strength of mobile terminals, etc.) Analysis of the acquired data to identify coverage holes, performance degradations, etc., preferably in a continuous way or within short time frames. Since the data of one NE may not suffice to detect performance degradations or coverage holes, the analysis algorithms should be implemented either in a central entity or in a distributed manner using clusters of neighbouring nodes. Solution phase: In case of identified performance degradations, acquisition of background information: information about the installed infrastructure (type of NEs, location of NEs, installed hard- and software, current configuration, modifiability of current configuration, etc.), information about geographic conditions (e.g. urban / rural area, antenna height, identified barriers for radio wave propagation, etc; the information could e.g. be available from network planning tools), and other (site-specific) boundary conditions (e.g. maximum allowed transmission power, potential interference sources, restricted areas, but also cost boundaries). Identification of a (graded set of) solution by using the acquired data. This could be done, for example, by applying a set of rules or policies, or by the algorithm-driven comparison of the data with best practice information from previous cases. As already described above, the solutions can be coarsely classified: o higher transmission power within existing cells to enhance cell size o cell split, i.e., the subdivision of one cell area into two or more cells to enhance the network capacity in the respective area o re-location of existing antenna to optimise the coverage of the affected area o installation of additional NEs to enhance the capacity of the affected area or eliminate coverage gaps Execution of the necessary tasks to implement the identified solution. In case this can be achieved by the modification of parameters of the installed equipment, the use case triggers the corresponding self-configuration or self-optimisation entities by submitting the modified parameters. In case the solution cannot be realised without hardware modifications, the system provides detailed instructions to the responsible operations and services team for the installation of new hardware, e.g. via a trouble ticket tool. Expected results Expected results are: Automated detection, analysis and compilation of solution proposals, automated conduction / trigger of tasks to achieve the proposed solution (if applicable) Efficient detection of performance degradations and coverage holes, reduction of response time to solve these problems Reduction of necessary effort to a minimum regarding the identification of necessary hardware modifications and enhancements Measurements / parameters / interfaces to be standardised Depending on the required real-time capabilities of the use case, some real-time counters or NE measurements may have to be standardised.

Page 12 (71)

SOCRATES

D2.1

Architectural aspects To establish the intelligent selection of site locations at least the following entities are required: Depending on the real-time requirements in the detection phase, corresponding real-time capable interfaces and data management systems at NE and OAM side may be required. A database that stores measurement results for a mid- to long term analysis, especially for periodical performance degradations Analysis tools for the identification of performance degradations and coverage holes from the acquired data A database that has all necessary background information available Solution tools (e.g. rules / policy-based, self-learning algorithms, etc.) that determine corresponding solutions by taking the available performance and background data Interfaces to self-configuration and self-optimisation systems to trigger necessary parameter modifications Interfaces to trouble ticket tools to trigger necessary hardware updates Already standardised interfaces 3GPP Itf-N (northbound interface of element manager towards network manager, e.g. for transfer of performance data) the Itf-N is the major standardisation topic of 3GPP SA5 (OAM) 3G LTE X2 interface (between eNodeBs) e.g. for the exchange of performance data to feed distributed cluster-based algorithms for the detection of coverage holes (see Actions Detection phase) Example (Informative description) See Introduction Potential gain Fast reaction on coverage holes and performance degradations, increasing customer satisfaction. Reduction of necessary manual effort (performance management) to identify coverage leaks and performance degradations, and to find appropriate solutions OPEX reduction. Related use cases Load balancing (section 3.3.2) GoS/QoS related parameter optimisation (section 3.2)

2.1.2

Automatic generation of default parameters for NE insertion

Self-configuration Deployment

Description Classification: Area of relevance:

Several approaches are possible for the introduction of network elements, reflecting an evolution from necessary manual intervention towards fully automatic introduction: Pre-configuration of network elements (e.g. manually on-site or in the factory): this approach actually describes todays situation, which shall be avoided in future due to its high expenses and necessary modifications on site. Pre-configuration of network elements with some default values, specific values are determined after initial boot: this approach could e.g. provide the network element with some standard or best-practice values before it is introduced in the network. The final network element (NE) and site-specific values then have to be assigned either manually or by automated configuration or self-optimisation mechanisms. No pre-configuration of network elements, specific configuration is determined and installed after initial boot: with this approach, the NE is delivered to the site completely without configuration, except for some standard software for initial NE start-up. The complete software and configuration is assigned during the self-configuration procedure, including radio settings, neighbourhood configuration etc. Hybrid solutions between these three approaches could also be applied. For the introduction of a new NE, several different types of parameters are to be assigned. While for some of these parameters it is not useful to provide default parameters, since the likelihood that they will have

Page 13 (71)

SOCRATES

D2.1

to be changed after installation of the NE is rather high, or they cannot be optimised automatically, this does make sense for other parameters: Network and security parameters, e.g. IP address, certificates, server addresses; for these parameters it is not useful to provide default parameters, since they cannot be optimised; for these parameters it is sensible to provide self-configuration mechanisms. Software parameters, e.g. SW version / load; since a SW version / load cannot be optimised it does not make sense to provide a default version; it is more sensible to provide the required version through self-configuration mechanisms. NE / hardware specific parameters, e.g. firmware, drivers, amplifier settings; except for the amplifier settings the same applies as for SW parameters; for the amplifier settings see radio network specific parameters. Radio network specific parameters, e.g. cell parameters, transmission power, neighbour relationships, X2 interface configuration etc.; since this type of parameters does not only depend on the NE type but also on other radio network conditions (site and neighbourhood specific), it does make sense to provide default values as basis for self-optimisation. On the other hand, if no default values are provided, the self-optimisation process may need much more time since it always has to start from the scratch. Core / transport network specific parameters, e.g. pooling, S1 interface configuration: for some of these parameters a default configuration may make sense (e.g. pooling), but for others not. This use case describes the generation of the default values for NE radio network specific parameters, subsequently described as default parameters. Objective The main objectives for this use case are: Provide newly installed NEs with a default set of radio network related parameters as basis for site specific configuration / optimisation Reduce required time for self-optimisation Avoid necessary pre-calculation of radio network parameters for self-configuration Scheduling (Triggers) The provisioning of the NE with default parameters takes place during the self-configuration phase. The default parameters are generated by using parameters from previous and current NE configurations that show comparable boundary conditions (e.g. NE type, number of neighbours etc.). These parameters could e.g. be available from a database and selected for the dedicated NE by self-learning algorithms. Input source Configuration management functions and self-optimisation functions provide the data for default parameter generation. List of parameters The parameters modified during the default parameter generation use case can conclude all parameters that are required and modified within the self-optimisation process. In addition, the NE type and HW / SW configuration is to be stored. Actions For each successful insertion of an NE the (finally optimised) radio network parameters are stored in a dedicated parameter database, in association with the NE type HW and SW configuration. From the data set of each NE type default parameters are calculated that represent e.g. the average values of the stored data, or represent some kind of best practice values following self-learning algorithms. These self-learning algorithms may also include additional, e.g. site-specific parameters (urban / rural area, number of neighbours etc.) that allow a more detailed assignment of default parameters to a new NE. Expected results A set of default parameters for each NE type that represent average or best-practice values, to simplify and accelerate the integration of new NEs in the radio network without having to start from the scratch every time. Measurements / parameters to be standardised None specific depend on self-optimisation process.

Page 14 (71)

SOCRATES

D2.1

Architectural aspects To establish default radio network parameter generation at least the following entities are required: A database that stores parameters from previous insertions or the current configuration A set of algorithms that calculate default parameters from this database A set of algorithms that selects a set of default parameters for a dedicated NE type during selfconfiguration process A module within the self-configuration process that handles the data exchange between NE and the default parameter module during self-configuration Already standardised interfaces No specific interfaces required apart from existing configuration management Example (Informative description) Examples are given in the Description part of this use case. Potential gain For the insertion of a new NE, the availability of default parameters can accelerate the self-configuration process significantly, since the self-optimisation of the radio parameters does not have to start at zero but already at a default configuration. The insertion can therefore be completed more quickly and reduces the necessary time efforts and thereby OPEX. Related use cases The listed use cases provide information which is required to generate the default parameters: Radio network optimisation: o Interference coordination (section 3.1.1) o Self-optimisation of physical channels (section 3.1.2) o RACH optimisation (section 3.1.3) GoS/QoS related parameter optimisation o Admission control parameter optimisation (section 3.2.1) o Congestion control parameter optimisation (section 3.2.2) o Packet scheduling parameter optimisation (section 3.2.3) o Link level retransmission scheme optimisation (section 3.2.4) Handover related o Handover parameter optimisation (section 3.3.1) o Load balancing (section 3.3.2)

2.2
2.2.1

Non-radio
Network authentication
Self-configuration Deployment

Description Classification: Area of relevance:

There exists growing set of topics that puts high challenges on the security architecture and concepts of future communication networks, including the corresponding OAM: the migration of the network and transport infrastructure towards all-IP (i.e. for the communication between all network endpoints, IP and Internet technologies and mechanisms are used, including transport, routing, security) the introduction of new technologies at the link layer (e.g. Metro Ethernet) site sharing and multi-vendor networks the outsourcing of network operations to 3rd party companies by the operators the use of transport backbone networks from 3rd party suppliers In comparison with the rather closed environments of todays 2G and 3G networks, the stated changes open up a large set of potential leaks for intrusion into the network, e.g. for data theft, DoS attacks, or the introduction of bogus nodes. With the introduction of home base stations, another potential risk appears for the operators, since these base stations are no longer under their physical control.

Page 15 (71)

SOCRATES

D2.1

With this background, self-configuration especially for the deployment of new network elements require mechanisms for the mutual authentication of node and network, e.g. to prevent from the misuse of home BSs for intrusion into the network, and to make sure the node is connected to the right network. A detailed analysis of the potential threats of the stated changes in network technology and architecture is necessary to develop an overall solution. Objective The main objectives for this use case are: Avoid potential service degradation or interruption due to bogus nodes Minimize the risk of network outage and data theft due to hacker attacks Scheduling (Triggers) Network authentication will be performed during node start-up, e.g. after node insertion or re-location, or in case of home eNodeB always after switching on. In some cases it might also be necessary to perform network authentication also during operational phase, e.g. in case of network re-configuration or for the purpose of SW or HW updates. The triggers for network and node authentication may be operator-specific, depending on the corresponding network architecture and security framework and requirements, but the sub-use-cases should be generally defined. However, it might be useful to define different procedures for different levels of security. Input source As input data for network and node identification, the following information may be used: Node ID (to be defined; could be a HW ID, a unique identifier, a location-based identifier, a certificate etc.) Network ID (to be defined; could e.g. be a unique identifier or a certificate) List of parameters Parameters that may be modified by network and node identification are: Node address (e.g. IP address) Certificates Node identifiers (e.g. unique identifier, node location etc.) Network database that contains node information Actions At this stage, it is not possible to specify detailed actions since there has been no agreement about the required level of security up to now. However, some basic actions can be described already now: Network side: After connecting the node to the network, determine node identifier and compare with (planned) node database in the network Provide (temporary) network address to the node Generate and provide certificate to the node Enter node data to the node database, activate data set Node side: After establishment physical network connection gathering (temporary) network address Provide node data to the network for registration Expected results Validation and authentication of node towards network Validation of network towards node With respect to self-optimisation the major aspect is the unambiguous identification of a node, such that its identity is settled for other self-optimisation tasks and use cases. Measurements / parameters to be standardised Node identifier Network identifier

Page 16 (71)

SOCRATES Certificates (optional)

D2.1

Architectural aspects To establish an authentication infrastructure several levels are possible: A simple DHCP-like infrastructure with MAC address filtering, requiring pre-configuration of DHCP server A DHCP infrastructure with validation at DHCP server side, e.g. through node database matching or comparison of location data An authentication infrastructure e.g. with certificate authorities etc. Already standardised interfaces Node and network authentication is performed at least between the node and the responsible OAM system, but may also be performed between node and neighbouring nodes (e.g. other base station, gateways, and controllers). The interface between node and OAM system is not standardised. Currently discussions continue about a standard auto-configuration process with corresponding standardised interfaces and protocols (or protocol enhancements) The interface between 3G LTE eNodeB and aGW is standardised (S1-IF), the actual interface setup and authentication procedure is not fixed yet. Most probably the same process will be used as for the X2 interface. The interface between 3G LTE eNodeBs is standardised (X2-IF), currently there is a mutual authentication foreseen during the X2 interface setup. Example (Informative description) Examples are the first steps of the self-configuration of a new macro eNodeB. Given that the new eNodeB does not have an appropriate SW load and basic configuration installed, this has to be downloaded and installed before the site- and radio network-specific configuration can be applied. Firstly, it has to be ensured that this specific eNodeB is allowed to get connected to the (OAM-) network of the operator at this specific site, i.e., the node has to be authenticated towards the network. This may be complicated in the case that the site is not directly connected to the operators OAM network but to the network of a 3rd party operator that can not carry out the authentication. Therefore, a temporary virtual connection with the operators OAM network has to be established, for the purpose of node authentication. If this has been accomplished successfully, a trusted connection between eNodeB and the operators OAM network can be established, e.g. to download the required SW load and necessary basic configuration. Potential gain Network authentication does not provide a gain w.r.t. network performance, but is a mandatory requirement for future network generations, to guarantee the robustness of the network against attacks. However, the implementation may have impact on the overall performance of the network, e.g. in case of IPSec or other encryption technologies being used. Related use cases None

2.2.2

Hardware/capacity extension

This use case refers to functionality that would enable seamless continuity of service for an eNodeB while having new hardware installed. Currently, base stations have to be switched off and various manual configurations are required before the base station can be re-activated. This is recognised as a good use case, but it is considered to be outside the scope of the SOCRATES project. A description of this use case can be found in [1].

Page 17 (71)

SOCRATES

D2.1

References [1] NGMN Project 12, Informative List of SON Use Cases, v 1.53, section 5.2 (included in 3GPP S5071944)

Page 18 (71)

SOCRATES

D2.1

Self-optimisation use cases

The importance of self-optimisation within the Socrates project can be seen by the fact that this section contains the most use cases. Self-optimisation use cases cover Radio network optimisation (section 3.1), GoS/QoS related parameter optimisation (section 3.2), Handover related optimisation (section 3.3) and Other (section 3.4) important use cases. The use cases provide a framework for adjusting network and equipment parameters on the basis of network measurements. All the use cases share the aim to improve on key performance indicators and to use the available network resources more efficiently.

3.1
3.1.1

Radio network optimisation

Interference coordination
Self-optimisation Optimisation

Description Classification: Area of relevance:

One of the main limiting factors for the performance of a mobile radio network is interference. Efficient management of interference can increase the efficiency of the system and improve the quality-of-service (QoS). As LTE systems employ OFDM, intra-cell interference between users is not an issue. Inter-cell interference does, however, clearly influence performance. Assuming that LTE will use a frequency reuse of one, therefore, interference will be high at the cell edge for loaded cells. This can potentially lead to low throughput and unsatisfactory QoS for users at the cell edge. Features such as frequency-selective scheduling shall schedule on resource blocks with low interference. However, on 3GPP forum it is believed that this alone is not sufficient, and further gains can be achieved by using SON techniques to further improve performance. This use case considers mainly macro/micro deployments. Interference issues for femto-cells are considered in a separate use case. Objective The main objectives for this use case are: Minimise the impact of inter-cell interference by managing the resources used in neighbouring cells Ensure good cell edge performance Maintain a fair balance between cell edge user performance and performance of users closer to eNodeB: Ideally all users should have equal performance, but in practice it may not be efficient to give high throughput to cell edge users, at the expense of users closer to the eNB. It is necessary to find the right trade-off. Consider QoS requirements of users when managing interference: for example, reducing the maximum transmit power for a non real-time user is likely to be more acceptable than doing the same for a real-time user. Consider both uplink and downlink Scheduling (Triggers) It is expected that interference control will operate based on continual monitoring of the network. Potentially it will be necessary to have both pro-active and reactive algorithms. Pro-active algorithms will monitor interference levels, and will take action before problems start to occur. However, in some cases the pro-active algorithm may not sufficiently avoid problems, and then a reactive algorithm will be necessary. Events that can trigger a reactive algorithm are: Dropped calls Low QoS

Page 19 (71)

SOCRATES

D2.1

It is worth noting that Interference Control can be considered both a SON and an RRM (Radio Resource Management) functionality. Functionality that works on a timescale of less than seconds is generally considered to be RRM. However, algorithms that intelligently manage interference, and implement specific policies, are considered to be SON. Input source As input data to an interference control algorithm, the following information may be used: User QoS (throughput, delay, packet loss) User location (how close to cell edge based on pathloss measurement) Interference level for each resource block Load/Interference indicator from other cells List of parameters Parameters that may be modified by an interference control algorithm are: Sub-band transmit power Resource block transmit power Scheduler settings Power control settings Assignment of resource blocks to users Actions At this stage, it is not possible to specify detailed actions, as no algorithms have been defined yet. However, using a high level description, a possible process is: Monitor interference levels, QoS and load/interference status from neighbour cells Detect problems (e.g. high interference levels, QoS degradation) Take action to deal with problem, for example: o Switch to a fractional re-use scheme o Change maximum transmit power o Send indicators to neighbour cells

Expected results Expected results are: Better data throughput Reduction in dropped calls Higher cell capacity Better cell edge performance, while maintaining spectral efficiency Higher user satisfaction (lower delays, jitters for real time traffic) Status in 3GPP For a distributed solution, the X2 interface will be used. Work is already ongoing in 3GPP to define signalling over this interface, but no decisions have been made yet. The focus so far has been on the uplink (3GPP R1-075050, R1-074851), where indicators referred to as High Interference Indicator and Overload Indicator are being considered. Another method is presented in 3GPP R1-074984. High Interference Indicator has been agreed during meeting in Sorrento. It was decided that the HII should be a bitmap with one bit per Physical Resource Block and that a cell can send HII with different, neighbour-cell specific contents to different neighbour cells. Overload Indicator is still discussed. Summary of companies positions can be found in 3GPP R1 081048. For the downlink, some 3GPP contributions (3GPP R1-074641) support the use of an indicator on the downlink, to be used to control transmit power. Other contributions (3GPP R1-072974) see no gain from doing this. Current status is described in 3GPP R1 081048. Measurements / parameters / interfaces to be standardised To support the interference control use case, the following standardised measurements are required: QoS measurements, per user (throughput, delay, packet loss) Estimation of user location (close to cell edge or not) Measurement of interference levels, both in uplink and downlink, per resource block

Page 20 (71)

SOCRATES RSRP (Reference Signal Received Power) and (new) triggers for reporting to ICIC functionalities

D2.1

Architectural aspects The current work in 3GPP RAN1 is based on the assumption that the X2 interface will be used for signalling between eNodeBs (3GPP R1-075050). This implies a distributed solution. In addition, it may be useful to also have a centralised SON function that manages the interaction between different cells. Example (Informative description) For simulations, hexagonal cell layouts are often used. In a real network, irregular cell locations are common. In addition, propagation conditions will result in irregular coverage areas. As a result of this, there will be areas of strong overlap between cells, resulting in bad interference conditions. By adjusting network parameters, it will be possible to reduce this interference. The above is just one example of a situation where interference control will be useful, and other situations should be considered as well. Potential gain LTE is already designed to handle interference. However, there may still be situations where the interference management is not adequate, and a SON solution will be necessary. The most important aspect here is user experience. If users can experience a high bitrate / lower delays independent of where they are (relative to the eNodeB), that would be considered a significant gain. However, the gain in overall cell capacity is unlikely to be significant. In fact, cell capacity may even be reduced. Related use cases QoS related parameter optimisation (section 3.2) Self-optimisation of home eNodeB (section 3.1.4) Load balancing (section 3.3.2) References [1] 3GPP R1-075050, Way forward on UL ICIC Overload Indicator for LTE [2] 3GPP R1-074851, Uplink inter-cell interference coordination [3] 3GPP R1-074984, Semi-Static Interference Coordination Method [4] 3GPP R1-074641, Discussion on the DL Interference Coordination [5] 3GPP R1-072974, Downlink Interference Coordination [6] 3GPP R1-074444, On Inter-cell Interference Coordination Schemes without/with Traffic Load Indication [7] 3GPP R1 081048, Summary of email discussion on UL and DL ICIC

3.1.2

Self-optimisation of physical channels

Self-optimisation (/Self-configuration) Optimisation

Description Classification: Area of relevance:

The physical channels in LTE have a large number of parameters associated with them. For many parameters default settings will be sufficient. However, for other parameters, the default settings may result in unsatisfactory performance, and it is beneficial to use self-optimisation to automatically find good values for these parameters. For the downlink, the physical channel parameters will be stored in the eNodeB. Although uplink parameters are used by the UE, many uplink parameters will be signalled to the UE from the eNodeB, and can therefore also be determined by self-optimising functionality in the eNodeB.

Page 21 (71)

SOCRATES

D2.1

Although this use case focuses on self-optimisation, it will be triggered by the installation of a new base station, and therefore also has an element of self-configuration. Objective Self-optimisation of physical channel parameters has the objectives: Ensure that a new eNodeB can be deployed with little manual effort in initial configuration and optimisation of parameters. Good cell performance, with the objective of avoiding signalling errors and failed calls. Scheduling (Triggers) This use case will be triggered by the installation of a new base station. Input source Information on configuration of physical channels for neighbouring cells. Whether this information is useful may depend on whether the neighbouring eNodeBs are deployed in a similar environment as the new eNodeB. Traffic forecasts eNodeB location eNodeB hardware configuration o Antenna height, pattern Feedback from UEs making calls on the cell o DL RSRP (Reference Signal Received Power) o DL BLER performance for various channels Measurements on UL channels List of parameters The downlink channels for which parameters could be automatically set are: Physical Signals o Reference Signal, RS o Synchronisation Signal, SCH Control Channel o Physical Control Format Indicator Channel, PCFICH o Physical Downlink Control Channel, PDCCH o Physical Hybrid ARQ Indicator Channel, PHICH Data Channel o Physical Downlink Shared Channel, PDSCH o Physical Multicast Channel, PMCH o Physical Broadcast Channel, PBCH The uplink channels are: Physical Signals o Reference Signal, RS o Random Access Preamble Control Channel o Physical Uplink Control Channel, PUCCH Data Channel o Physical Uplink Shared Channel, PUSCH o Physical Random Access Channel, PRACH Exactly which parameters for these channels can be set using self-organising functionality requires further study, but potentially interesting parameters are: (Relative) transmit power (or transmit power range) Power control settings Power Boosting of the Downlink Reference Signal Cazac sequences for UL Reference Signals (PUSCH/PUCCH RS and the Sounding RS (SRS) ) (neighbours should use different sequences) Actions Obtain information about physical configuration of new eNodeB. Obtain information about neighbouring eNodeBs.

Page 22 (71)

SOCRATES Obtain physical layer measurements from UEs making calls on the new eNodeB. Process information and obtain suitable settings for physical channels.

D2.1

Expected results Correct configuration and optimisation of the downlink channels will ensure that they can be correctly received by the UE, therefore avoiding dropped calls. The same applies to the eNodeB for uplink channels. Correct configuration in this context means that the channels are received with a sufficiently low error rate to enable satisfactory communication on these channels. Status in 3GPP This use case is originally derived from the NGMN Automatic Generation of Radio Parameters use case [1], although in its current format it is significantly different to that use case. It had previously not been considered in 3GPP, but based on the description in this document, a contribution was submitted to the 3GPP RAN2 group [2]. Measurements / parameters / interfaces to be standardised For the downlink, it will be necessary to obtain physical layer measurements from UEs to assess the performance of downlink channels. These measurements should reflect the performance of the downlink channels, and it should be possible to use these measurements to determine optimised parameter settings. Useful measurements are: Received power C/I ratio BLER performance For SCH: synchronisation performance Some of these measurements are already standardised, while others will require standardisation. Architectural aspects It is assumed that multiple eNodeBs will be involved in this use case. If a centralised solution is used, information from neighbouring eNodeBs can be used as input to decisions. That would mean that the central O&M/SON entity would have to be aware of self-optimised parameters from all eNodeBs. Example (Informative description) One of the downlink control channels is configured incorrectly, as a result of which many of the UEs on the cell cannot receive data in the downlink. A self-organising solution would automatically detect this, and correctly configure parameters Potential gain This use case could potentially have a high gain, as it will enable new eNodeBs to be deployed with less manual configuration, while resulting in a more reliable network. However, further study may show that for many parameters, default values will result in satisfactory performance anyway. Related use cases Self-optimisation of home eNodeB (section 3.1.4) RACH optimisation (section 3.1.3) References [1] NGMN Project 12, Informative List of SON Use Cases, v 1.53, section 2.4 (included in 3GPP S5071944) [2] 3GPP R2-081780, Measurements for Self-optimisation of DL Physical Channel Parameters

3.1.3

RACH optimisation
Self-optimisation Optimisation/Deployment

Description Classification: Area of relevance:

Page 23 (71)

SOCRATES

D2.1

The configuration of the RACH has great impact on the performance of mobile cellular radio networks. It significantly affects the probability of blocked access attempts from the mobile stations and leads to callsetup-, data-resuming-, TAU(Tracking-Area-Update)- and handover-delays. The RACH configuration also influences the setup-, TAU- and handover-success-rate [1]. In the following the parameters that have to be standardised concerning RACH, are termed RACH parameters (RP). Objective It is the objective to improve the operating grade of the RACH by reducing the blocked access attempts and optimising the RACH configuration, including RACH resource unit allocation and RACH preamble split [1]. Furthermore, automatic configuration/optimisation of RACH and related parameters shall be possible. Scheduling (Triggers) Following scenarios trigger a corresponding action: A new Tracking Area configuration leads to a shift in the Tracking Area boundaries. Since Tracking Area Updates (TAU) that need the RACH are necessary at these boundaries the RPs could need to be reconfigured. Changes within the cell parameters, e.g. antenna tilt, pilot power, handover thresholds [1], etc. for example caused by load balancing and cell outage compensation lead to a different coverage area for the cell and so to a new traffic load. A new configuration of the RPs might be necessary. If the maximal traffic load of an eNB is achieved (all TCH busy) some RACH could be used as TCH. A new configuration of the RPs will be necessary. Configuration and optimisation can be triggered On Demand, Automatically. Input Source The operational demand to the RACH depends on the amount of traffic that is generated in the cell area, the traffic that arrives from the network and the amount of signalling processes that need the RACH. Hence all parameters that contain information about the traffic load have to be known in order to develop algorithms for the RACH optimisation. Additionally the parameters of some signalling processes e.g. the Tracking Area Updates are needed. The input sources for this information are listed below: Mobile Originated Calls (MOCs) Mobile Terminated Calls (MTCs) Blocked access attempts Incoming handovers Tracking Area Updates Load of TCH List of parameters Depending on the standard, the following RACH parameters have to be configured: Number of access attempts before blocking Time delay for next access attempt Number of RACH Preamble split Actions Configuration/optimisation algorithms can trigger the following actions: Request for processed UE and network measurement data Configuration of UE and network measurement jobs (periodic, certain set of UE, certain region) Determination of optimised RPs (online) Implementation/Reconfiguration of RPs Expected results Reduction of blocked access attempts

Page 24 (71)

SOCRATES Status in 3GPP So far RACH optimisation has not been defined as a use case.

D2.1

Measurements / parameters / interfaces to be standardised It will be necessary to obtain information about the actual performance of the RACH. Besides the traffic information provided by the network (see input source) the following measurements would make sense: Blocked access attempts Architectural aspects Since the RACH configuration depends on the individual situation of all eNBs it would make sense to implement the RACH optimisation algorithms in the eNBs. Example (Informative description) Figure 2 shows the process of UEs trying to access the RACH. The access attempt of UE 2 is blocked after the third try. The number of blocked access attempts should be as low as possible.

Figure 2: Flow diagram of access to RACH Potential gain If the traffic load of a cell is high the blocked access attempts increase. The potential gain of the RACH optimisation should be large in this case especially for traffic peaks if it is possible to use some of the RACH as TCH. The GoS level should benefit in these situations. It will not make much sense to optimise the RACH if the traffic load is low because the potential gain will be low as well. Related use cases Tracking Area Optimisation (section 3.4.2) Load Balancing (section 3.3.2) Cell Outage Compensation (section 4.1.3 ) Handover Parameter Optimisation (section 3.3.1) References [1] R2-074122, NTT DoCoMo, eNB Measurements M5: number of received RACH preambles

Page 25 (71)

SOCRATES

D2.1

3.1.4

Self-optimisation of home eNodeB

Self-optimisation, with some aspects of self-configuration Radio parameter optimisation

Description Classification: Area of relevance:

In E-UTRAN an extensive use of home eNodeBs is foreseen. Home eNodeBs will be used to improve or create coverage in limited areas, such as a house, a work place or a coffee bar. The characteristics of home eNodeBs differ from macro eNodeBs in the following aspects: There will potentially be a large number of home eNodeBs in a radio network The coverage areas are small There will probably be only a few users per cell A home eNodeB may be turned on and off frequently A home eNodeB may be switched off and moved to a new geographical position before it is turned on again The home eNodeB is not physically accessible for operators A home eNodeB may have closed or open access, each with different characteristics: o A closed access home eNodeB has the potential to interfere with UEs connected to the macro cell, but within the home eNodeBs coverage area. o An open access home eNodeB network could negatively impact fast moving macro cell users, initiating constant handovers. The home eNodeBs may be deployed in both home environments, office environments and public environments. An office deployment leads to a possible need of closed access for the home eNodeB, while a public home eNodeB should have open access. Furthermore, the home eNodeB may or may not operate on a separate frequency from the macro eNodeBs. The home eNodeB is physically installed by the customer and connected to the operator network through the customers fixed Internet line. The customer cannot be assumed to have the knowledge to install software on and configure the home eNodeB; hence this needs to be done in an automatic manner. Once installed, the home eNodeB runs a number of self-tests to verify a functioning operation. Software installation and self-tests of a home eNodeB is not significantly different from the same functions in macro eNodeB, and will therefore not be investigated in this use case. In order to have seamless mobility between eNodeBs, both between two home eNodeBs and between a home eNodeB and a macro eNodeB, neighbour relations must be set up. These neighbour relations should be symmetric. However, a neighbour relation to a home eNodeB may need to be handled somewhat differently from a relation to a macro eNodeB, since the home eNodeB can be switched on and off arbitrary and more frequently. There can also be a very large number of home eNodeBs in the vicinity of a macro eNodeB. In certain cases it may be beneficial not to hand over to home eNodeBs, especially for macro served fast moving UEs. Further, the neighbour relations list needs to be dynamically updated so that new neighbours are detected and inappropriate neighbour relations (i.e. neighbour relations not used or related to a high amount of failed handover attempts) are removed. For the home eNodeB user, it is important that the home eNodeB provides coverage for the entire area it is intended to do. For example, a home eNodeB is often intended to cover a building, and there should be no coverage holes in that building. The detection and removal, or minimization, of coverage holes (for example, rooms lacking coverage in a building meant to be covered) is therefore desired. A coverage area large enough to cover the areas where users normally move is also desired. For example, if a user walks out on the balcony for a while, it is preferred that his or her call is not handed over to the neighbouring macro cell, unless this is necessary due to the interference situation. The coverage area may be adjusted by configuring radio parameters of the home eNodeB. This is, however, a trade-off with the interference situation. The radio parameters need to be configured in order to optimize the coverage area for the home eNodeB while minimizing the interference on neighbouring eNodeBs. The home eNodeB use case includes certain elements of self-configuration, however, is more related with self-optimization, due to the necessity to constantly being able to adapt to a changing radio environment.

Page 26 (71)

SOCRATES

D2.1

Objective A home eNodeB should automatically, with minimal customer intervention detect neighbouring eNodeBs, including other home eNodeBs. maintain and optimize the neighbouring cell list to provide seamless mobility to and from the home eNodeB configure radio parameters to optimize its coverage area and minimize the interference on other eNodeBs decide if a handover (between macro and home eNodeB) should take place Scheduling (Triggers) At start-up of the home eNodeB, neighbour detection is triggered to detect neighbouring eNodeBs. Radio parameters are set to an initial configuration. The collection of statistics to optimize the coverage area is started, and once sufficient information is collected, the radio parameters are updated. During operation, the following triggers are used: Neighbour list optimization is triggered upon indications of missing or inappropriate neighbours, for example the occurrence of dropped calls. Radio parameter optimization is triggered upon o the detection of a coverage hole o the detection of a too small or too large coverage area o a bad interference situation Handovers are triggered upon o Signal strength measurements Input source Input sources for the self-configuration and self-optimization of home eNodeBs are initial starting configuration set by the supplier of the home eNodeB (i.e. operator specific settings) measurements performed by the home eNodeB, such as o failed handover ratio o uplink interference o ratio of dropped calls measurements performed by UEs, such as o downlink interference o signal strength from serving home eNodeB o signal strength from surrounding eNodeBs o geographical position of the UE o UE speed measurements performed by neighbouring eNodeBs, such as o interference measurements Since a home eNodeB is probable to have only a few users, it could be considered to initially let the home eNodeB itself perform neighbour measurements in order to reduce the number of measurements needed from the UEs. This would however require the home eNodeB to have the ability to measure on the same frequency band as is used for transmission. List of parameters Parameters to be adjusted are neighbour relations cell power Physical Cell ID handover parameters Actions Upon detection of a new or an inappropriate neighbour, the home eNodeB should add or remove the neighbour from the neighbour relation list. Upon the detection of a coverage hole, the home eNodeB should attempt to remove or minimize the hole by for example increasing the cell power. Upon the detection of a coverage area not corresponding to the users movement statistics, the home

Page 27 (71)

SOCRATES eNodeB should attempt to adjust the coverage area, by for example adjusting the cell power.

D2.1

Upon detection of a bad interference situation the home eNodeB should attempt to improve the situation by for example by lowering the cell power or changing the physical cell ID. Upon changes in signal strength/interference the home eNodeB should perform appropriate handover. Expected results The home eNodeB will get up and running with an appropriate configuration without the need of customer intervention. The home eNodeB will dynamically update the neighbour relation list and therefore provide seamless handover to and from other eNodeBs. The coverage area for the home eNodeB will be optimized and in relation to the user needs (under certain constraints) The interference on other eNodeBs will be minimized. Status in 3GPP/NGMN Radio parameter optimization and transport parameter optimisation of Home eNodeBs is listed within the Informative List of SON Use Cases in NGMN Project12 [1]. Project Monotas[2] studied differences in interference aspects of open and closed access home eNodeBs, resulting in a submission to 3GPP[3]. Measurements/parameters/interfaces to be standardised It is anticipated that generally the measurements/parameters/interfaces are not significantly different to those as required by a macro eNodeB. For example the handover parameters required for selfoptimisation as listed in the HO use case are similar to those required for home eNodeB handovers, even though the actions a specific home eNodeB takes might be different to those of a macro eNodeB. Location and speed measurements by the UE are listed as potential input measurements and the feasibility to obtain these reliably (especially for indoor location) should be investigated. Architectural aspects Since the home eNodeBs in a network can be numerous, are covering small areas and may be switched on and off arbitrary, as much as possible of the self-configuration and self-optimisation should be performed in the home eNodeBs. Management of the node must however be possible from the OSS. Therefore, the home eNodeB should immediately register to the network on start-up. The OSS can then for example automatically initiate software updates. Example (description) A customer buys a home eNodeB and plugs it in to a fixed Internet line in her house. When the home eNodeB is switched on it immediately connects to the network and is authenticated. The home eNodeB then downloads the latest software and performs a self-test to make sure the installation succeeded. The customer can then start to use the home eNodeB. When a UE enters the home eNodeB coverage area it will connect to the home eNodeB. The home eNodeB will request measurements from the UE in order to find neighbours and configure its radio parameters in order to optimise the coverage area and minimise interference on other eNodeBs. If the UE leaves the home eNodeB coverage area while connected to the home eNodeB, the connection will be handed over to a neighbouring eNodeB. When a UE enters a closed access home eNodeB coverage area and is denied access to the home eNodeB, the UE will remain connected to the macro eNodeB. The home eNodeB should take steps to reduce potential interference issues with the macro connected UE. Potential gain Operators will not need to perform any configuration from the geographical spot where the home eNodeB is located. The home eNodeB will respond to changes in the environment automatically and potentially negative influences to the mobile operators macro network (and UEs connected to macro eNodeBs) will be reduced. Related use cases Neighbour list optimisation (section 3.3.3) Interference coordination (section 3.1.1 )

Page 28 (71)

SOCRATES Handover parameter optimisation (section 3.3.1) Coverage hole detection (section 3.2.5)

D2.1

References [1] NGMN Project 12, Informative List of SON Use Cases, v 1.53 (included in 3GPP S5-071944) [2] Monotas, http://www.macltd.com/monotas/ [3] 3GPP R4-071231: Open and closed access for Home Node Bs

3.2

GoS/QoS related parameter optimisation

The use case GoS/QoS related parameter optimisation is in a sense an umbrella use case covering selfoptimisation of diverse radio resource management mechanisms and their parameters that in one way or another affect the (trade-off between the) achieved grade (GoS) and quality of service (QoS). In the applied terminology, GoS refers to performance metrics associated with call accessibility (call blocking) and retainability (call dropping), while QoS refers to performance metrics associated with the quality of the services calls in terms of e.g. frame error rate, delay (variation) and throughput. Among the diverse radio resource management mechanisms that fall under this umbrella, we consider admission control, congestion control, handover control, packet scheduling and link level retransmission scheme optimisation. Although strong (potentially conflicting) relations exist between these mechanisms in the way they influence the GoS versus QoS trade-off, we will define separate use cases to address the self-optimisation of these mechanisms. In particular, the following use cases fall under the GoS/QoS related parameter optimisation umbrella use case: Use case Admission control parameter optimisation Use case Congestion control parameter optimisation Use case Packet scheduling parameter optimisation Use case Link level retransmission scheme optimisation Use case Coverage hole detection Despite the segmenting of the QoS use case into smaller sections, there should be some kind of common way to estimate/define/measure GoS and QoS (i.e. indicator, value, set of parameters, etc). QoS could be estimated by a set of parameters that are constantly monitored by the eNB/decision entity. Such parameters may include: Handover failure rates, Call blocking/drop rates, Load per cell, resource usage indicators, etc. Whenever one or more of the monitored parameters falls under a reference value, the decision entity has to identify the cause/possible causes and trigger the appropriate mechanism in order to resolve the problem. As already mentioned the use case Handover parameter optimisation is a related use case and could be included in this section. However, all handover related use cases are discussed in Section 3.3.

3.2.1

Admission control parameter optimisation

Self-optimisation Optimisation

Description Classification: Area of relevance:

The objective of admission control is to admit or reject fresh or handover call requests, based on the actual capacity, the carried traffic load, desired QoS of the newly requested and on-going calls. The admission control mechanism is proactive, in the sense that it aims to prevent undesired QoS degradation and fulfils a key role in the trade-off between capacity, quality and coverage. Objective The objective of this use case is to self-optimise the admission control thresholds in order to minimise call blocking while still allowing e.g. the packet scheduler to meet the QoS requirements of the admitted calls with sufficient likelihood, in light of the uncontrollable uncertainties due to e.g. user mobility, signal propagation effects and the impact of the varying load in neighbouring cells.

Page 29 (71)

SOCRATES

D2.1

Scheduling (triggers) Based on continuous monitoring of experienced service quality, call blocking probabilities and congestion events, the self-optimisation algorithm is triggered (i) when any unnecessary blocking is observed to occur (how this is determined is an open issue); (ii) when an observed service- or subscriber class-specific blocking probability exceeds the associated predetermined target (maximum) value, while for other services more is accepted than targeted and/or a significant amount of resources appears to remain unutilised (in the latter case there really should be no blocking at all); and (iii) when an observed dropping probability exceeds a predetermined target (maximum) value or, similarly, observed QoS levels do not satisfy the associated requirements, due to an excessive admitted traffic load. Input sources Key input source for the self-optimisation algorithm of admission control parameters are the experienced service- or subscriber class-specific blocking and dropping probabilities, the actual resource utilisation and an estimate of whether the scheduler is able to meet the QoS requirements of all on-going calls. List of parameters A number of parameters can be used to specify the self-optimisation algorithm, in particular a number of observation thresholds before the self-optimisation algorithm kicks in, e.g. the minimum observed exceeding of the service- or subscriber class-specific blocking and dropping probabilities, the maximum observed resource utilisation in cases where call blocking occurs, the maximum degree to which the scheduler is able to satisfy the QoS requirements of on-going calls and the preference (of the operator) for which services call blocking is preferred over call dropping. While the above example parameters could specify the associated self-optimisation algorithm, the admission control algorithm itself typically involves parameters such as uplink noise rise (or load factor), downlink transmission power, shared channel utilization, hardware utilization. Actions Actions taken by the self-optimisation algorithm are the adjustment of the admission control thresholds, i.e. the absolute and relative settings of the admission thresholds for fresh and handover calls associated with different services and/or subscriber classes. Expected results The expected result is that the self-optimisation algorithm continuously tunes the admission control parameters such that to the extent possible, all service- and/or subscriber class-specific blocking and dropping probabilities lie (as much as possible) below their associated requirements and such that the available resources are optimally used, while the packet scheduler is able to provide the admitted calls with sufficient QoS. Status in 3GPP Although the QoS related optimisation use case is mentioned in one 3GPP document [7], it is has not really been considered yet in 3GPP. Measurements/parameters/interfaces to be standardised Appropriate counters should be standardised to allow an accurate and timely characterisation of the resource utilisation and the actual service- and/or subscriber class-specific blocking/dropping probabilities and QoS experience. Some activities in 3GPP related to performance monitoring are already ongoing - for an example, see [9]. These activities should be monitored, and where possible SOCRATES should contribute to ensure that the necessary counters for this use case are standardised. Appropriate interface should be standardised to allow extraction of the input parameters into the selfoptimisation software, as well as the feedback flow back into the network in the form of adjusted admission control parameter settings. In 3GPP, these interfaces will be defined by the SA5 group, although this is currently still at a very early stage. Architectural aspects Since the admission control typically operates on a per cell basis, we foresee a distributed implementation of the associated self-optimisation algorithm, hence the cells take decisions autonomously without alignment with other cells.

Page 30 (71)

SOCRATES

D2.1

Example (Informative description) Consider a cell with little user mobility. As the likelihood of congestion due to uncontrollable effects is small, a small admission control margin will suffice. If, however, over time the degree of user mobility increases, the admission control margin needs to be increased to reserve sufficient resources to deal with the uncontrollable variations in resource usage due to the varying user locations. Hence in such a scenario an effective self-optimisation algorithm should monitor the degree of mobility and adapt the admission control parameters to this in order to maximise admissibility for a given acceptable likelihood of congestion. Also if the load in a neighbouring cell increases drastically it might be useful to increase the admission control margin (load balancing action to be expected). Potential gain Considering previously reported results on auto-tuning of admission control parameters in UMTS networks, the potential gain in terms of capacity/quality enhancement is expected to be high, while feasibility is good. This use case will contribute to ensuring that users are not unnecessarily given a reduced GoS/QoS. Related use cases As discussed above, this use case falls under the umbrella use case GoS/QoS related parameter optimisation and in that context primarily relates to its sister use cases Packet scheduling parameter optimisation (section 3.2.3), Congestion control parameter optimisation (section 3.2.2), Handover parameter optimisation (section 3.3.1). It further relates to the Load balancing (section 3.3.2) use case. References [1] NGMN, Informative list of SON use cases, use case on QoS related parameter optimisation, 2007 (included in 3GPP S5-071944). [2] Gandalf project, Advanced mobility and traffic management algorithms, Deliverable D4.2, 2006. [3] Gandalf project, Evaluation of advanced radio resource management, Deliverable D4.3, 2007. [4] M. Garcia-Lozano and S. Ruiz-Boque, Study on the automated tuning of HSDPA Code Allocation, COST 2100 TD(08) 410, 2008. [5] P.M. dOrey and . Gomes, Online automated tuning of RRM parameters of UMTS networks: uplink load factor threshold, Proceedings of Conftele 07, Peniche, Portugal, 2007. [6] S.-M.Senouci, A.-L. Beylot and G. Pujolle, Call admission control in cellular networks: a reinforcement learning solution, International Journal of Network Management, vol. 14, 2004. [7] 3GPP TR32.816 V1.3.1 (2007-11) Use case 8: QoS related radio parameter optimization. [8] 3GPP R3-070118, QoS Design Principles [9] 3GPP R2-080444, eNB measurements for RAN performance monitoring

3.2.2

Congestion control parameter optimisation

Self-optimisation Optimisation

Description Classification: Area of relevance:

As a consequence of largely uncontrollable effects such as user mobility, traffic or propagation effects, overload situations can occur in the sense of e.g. intolerable interference levels or unacceptable packet delays, even if admission control aims at preventing such situations. It is the objective of the congestion control mechanism to monitor the network load, detect when overload situations are encountered, evaluate the degree and urgency of the overload conditions, and take appropriate counter measures in order to get the system quickly but in a controlled fashion back to a feasible load situation. Hence in contrast to admission control, congestion control is of a reactive nature, aiming to resolve congestion. Typical counter measures include the rejection of all new call requests, the reduction of transfer rates and/or transmit power and (generally as a final resort) controlled call dropping.

Page 31 (71)

SOCRATES

D2.1

Objective The objective of this use case is to self-optimise the congestion control parameters in order to maximise resource utilisation subject to a maximum allowed degree of congestion-induced service quality degradation. And all of this in light of the uncontrollable uncertainties due to e.g. user mobility, signal propagation effects and the impact of the varying load in neighbouring cells. Scheduling (triggers) Based on continuous monitoring of experienced service quality (we still have to figure out how that will be monitored) and resource efficiency, the self-optimisation algorithm is triggered when (i) the fraction of time the cell is deemed congested seems relatively large given an observed low congestion-induced1 service quality degradation (this would lead to unnecessary congestion control actions); and (ii) the observed congestion-induced service quality degradation is high, in which case congestion control is not activated enough. Input sources Key input source for the self-optimisation algorithm of congestion control parameters are some measure of the experienced congestion-induced service quality degradation as well as the time fraction that the congestion control algorithm decides that the network is congested (and perhaps some correlated version of these two measures, as needed for issue (i) above). List of parameters As was the case for the description of the admission control use case, a distinction can be made between the actual congestion control parameters and the parameters that specify the associated self-optimisation algorithm. A typical congestion control algorithm is parameterised by (i) thresholds and hysteresis parameters to identify an overload situation, e.g. based on uplink noise rise, downlink transmission power, shared channel utilisation, inferior service quality in terms of BLER, throughput, delay or packet loss; and (ii) parameters associated with the congestion resolution phase, e.g. step size of load reduction, prioritisation of different service types, target load level. The associated self-optimisation scheme may be characterised by e.g. the maximum allowed degree of congestion-induced service quality degradation before the self-optimisation algorithm should modify the congestion control algorithm; and, similarly, some maximum allowed imbalance in the observed time fraction the network is deemed congested and the degree of congestion-induced service quality degradation. Actions Actions taken by the self-optimisation algorithm are the adjustment of the congestion control parameters, related to both congestion detection (e.g. thresholds, time windows) and congestion resolution (e.g. step sizes, load target level). Expected results The expected result is that the self-optimisation algorithm continuously tunes the congestion control parameters such that the resource utilisation is maximised given a maximum allowed degree of congestion-induced service quality degradation. Congestion control actions are taken timely, but not too early. Status in 3GPP Although the QoS related optimisation use case is mentioned in one 3GPP document [2], it is has not really been considered yet in 3GPP. Measurements/parameters/interfaces to be standardised Appropriate counters should be standardised to monitor the time fraction that a cell is in congestion (according to the congestion control algorithm), the degree of congestion-induced service quality degradation and some (yet to be determined) correlation between these measures. Some activities in 3GPP related to performance monitoring are already ongoing - for an example, see [3]. These activities should be monitored, and where possible SOCRATES should contribute to ensure that the necessary counters for this use case are standardised.

Note that this is something else than congestion control-induced service quality degradation.

Page 32 (71)

SOCRATES

D2.1

Appropriate interfaces should be standardised to allow extraction of the input parameters into the selfoptimisation software, as well as the feedback flow back into the network in the form of adjusted congestion control parameter settings. In 3GPP, these interfaces will be defined by the SA5 group, although this is currently still at a very early stage. Architectural aspects Since the congestion control typically operates on a per cell basis, we foresee a distributed implementation of the associated self-optimisation algorithm. Example (Informative description) Consider a cell with little user mobility. Since in such a scenario the uncontrollable variations of resource usage are relatively small, a higher degree of resource consumption can be allowed before the congestion control algorithm kicks in to downgrade or release on-going calls and free up resources. If, however, over time the degree of user mobility increases, the congestion control threshold needs to be decreased so that the likelihood of disastrous peaks in resource usage remains at the set tolerable level. Hence an effective self-optimisation algorithm should monitor the degree of mobility and adapt the congestion control parameters to it in order to maximise the allowed resource utilisation (and hence capacity, throughputs) for a given acceptable likelihood of congestion peaks. Potential gain Based on the high potential gains that are expected for the closely related admission control scheme, but discounted for the typical rarity of overload situations, the potential gain of self-optimising congestion control parameters is deemed fair, while feasibility is deemed good. Related use cases As discussed above, this use case falls under the umbrella use case GoS/QoS related parameter optimisation and in that context primarily relates to its sister use cases Packet scheduling parameter optimisation (section 3.2.3), Admission control parameter optimisation (section 3.2.1) and Handover parameter optimisation (section 3.3.1). It further relates to the Load balancing (section 3.3.2) use case. References [1] NGMN, Informative list of SON use cases, use case on QoS related parameter optimisation, 2007 (included in 3GPP S5-071944) [2] 3GPP TR32.816 V1.3.1 (2007-11) Use case 8: QoS related radio parameter optimization [3] 3GPP R2-080444, eNB measurements for RAN performance monitoring

3.2.3

Packet scheduling parameter optimisation

Self-optimisation Optimisation

Description Classification: Area of relevance:

The packet scheduling coordinates the access to shared channel resources. In OFDMA-based LTE systems, this coordination generally considers two distinct dimensions, viz. the time dimension (allocation of time frames) and the frequency dimension (allocation of subcarriers (or subcarrier groups)). A key challenge in devising and setting parameters for a packet scheduler is to optimise resource efficiency, while satisfying the different flows QoS requirements and, possibly, achieving some degree of spatial fairness. The distinct traffic characteristics and QoS requirements of conversational, streaming, interactive and background services greatly complicate this. Objective The objective of this use case is to self-optimise the diverse scheduling-related parameters in order to achieve the individual QoS requirements of all on-going calls most efficiently, in accordance with the desired spatial fairness and in response to e.g. changes in traffic/mobility patterns, service mix and propagation/interference characteristics. Packet scheduling directly addresses QoS metrics only. GoS metrics are affected indirectly by optimising resource efficiency and hence allowing a maximum number of simultaneous calls.

Page 33 (71)

SOCRATES

D2.1

Scheduling (triggers) Based on continuous monitoring of experience service quality and resource efficiency, the selfoptimisation algorithm is triggered when (i) a significant QoS imbalance is observed, i.e. when the QoS targets of some calls are overachieved while those of others remain unsatisfied; or (ii) the observed resource efficiency falls below what can be expected. Input sources Key input source for the self-optimisation algorithm is the actual service mix, required QoS per on-going call, experienced QoS per on-going call, resource efficiency and packet marking. List of parameters Scheduling algorithms, as for most radio resource management mechanisms, are generally devised by vendors, hence no standard set of scheduling parameters exist. In a rather general implementation, the following parameters may apply: Absolute versus relative differentiation threshold This threshold divides the calls with different priority labels into the regimes: the absolute QoS differentiation regime where calls of higher priority are handled with strict priority over calls of lower priority; and the relative QoS differentiation regime, where calls of different priorities receive different fractions of the shared resource according to their scheduling weights. Scheduling weights These weights are used in the relative QoS differentiation regime in order to give relative preference to calls with higher service- and/or subscription-base priority. Resource reservations Part of the shared resources may be exclusively reserved for a certain class of calls, based on e.g. the service type of the subscription. Such reservation levels may also be self-optimised. Channel-awareness (fairness) parameter Intelligent packet schedulers feature some degree of channel-awareness in the sense that they prefer to assign resources to calls with favourable instantaneous channel conditions, in order to optimise resource efficiency. As the purest of channel-aware scheduler (always assigning all resources to the user with the best channel) may be unfair towards users near the cell edge, the packet scheduler typically has a spatial fairness parameter which specifies the desired balance between resource efficiency and fairness between near and remote users. Besides these scheduling parameters, a number of parameters can be used to specify the associated selfoptimisation algorithm, e.g. the minimum observed QoS imbalance for the self-optimisation algorithm to affect changes, a resource efficiency threshold below which the self-optimisation algorithm studies the potential of parameter changes, and for each tuneable parameter a maximum change that can be effectuated by the self-optimisation algorithm (in order to prevent drastic changes and subsequently possible instability). Actions Actions taken by the self-optimisation algorithm are the adjustment of the packet scheduling parameters, as listed above. Expected results The expected result is that the self-optimisation algorithm continuously tunes the packet scheduling parameters such that at all times the QoS requirements of the on-going calls are met most resource efficiently, with possible QoS over-achievements distributed over the on-going calls according to some fairness objective. Status in 3GPP Although the QoS related optimisation use case is mentioned in one 3GPP document [6], it is has not really been considered yet in 3GPP. Measurements/parameters/interfaces to be standardised Appropriate counters should be standardised, on both the terminal and the network side, which allow a QoS characterisation that corresponds with the formulation of the QoS requirements. Appropriate interfaces should be standardised to allow extraction of the input parameters into the selfoptimisation software, as well as the feedback flow back into the network in the form of adjusted packet scheduling parameter settings.

Page 34 (71)

SOCRATES

D2.1

Architectural aspects Since the packet scheduler typically operates on a per cell basis, we foresee a distributed implementation of the associated self-optimisation algorithm. Example (Informative description) As one possible example, imagine a cell with a number of on-going WWW browsing sessions. Considering such a traffic scenario, the packet scheduler is able to schedule downlink transmissions rather purely based on the instantaneous channel quality. Even if the resources are primarily assigned to the users near the base station, they will be freed rather quickly due to the assigned high data rates. Hence the resources become rather quickly available to the remote users, which therefore indirectly also benefit from the applied pure channel-awareness in the packet scheduling. Then at some point in time a very heavy download session pops up near the base station, e.g. downloading the entire 12-disc Lord of the Rings DVD box. Giving near-strict preference to such a heavy download session would cause utter starvation of the remote users and hence in order to provide sufficient fairness the packet scheduler will have to reduce the purity of the applied channel-awareness and retune the fairness parameter of e.g. the applied proportional fair scheduling algorithm. Other examples, e.g. related to service-/subscriber differentiation are readily formulated. Potential gain Based on related studies that have been performed in the wireline domain (e.g. ATM networks), selfoptimisation of scheduling parameters can bring about significant gains with good implementational feasibility. Related use cases As discussed above, this use case falls under the umbrella use case GoS/QoS related parameter optimisation and in that context strongly relates to its sister use cases Admission control parameter optimisation (section 3.2.1), Congestion control parameter optimisation (section 3.2.2), Handover parameter optimisation (section 3.3.1) and Link level retransmission scheme optimisation (section 3.2.4). It further relates to the Load balancing (section 3.3.2) use case. References [1] 3GPP R1-072929, Initial list of eNB measurements, NTT DoCoMo, Orange, AT&T, T-Mobile, China Mobile, Telecom Italia, Telefonica, TeliaSonera, KPN. [2] NGMN, Informative list of SON use cases, use case on QoS related parameter optimisation, 2007 (included in 3GPP S5-071944). [3] M. Garcia-Lozano and S. Ruiz-Boque, Study on the automated tuning of HSDPA Code Allocation, COST 2100 TD(08) 410, 2008. [4] Gandalf project, Evaluation of advanced radio resource management, Deliverable D4.3, 2007. [5] D. Soldani and K. Valkealahti, Genetic approach to QoS optimization for WCDMA mobile networks, Proceedings of VTC 05 (Spring), Stockholm, Sweden, 2005. [6] 3GPP TR32.816 V1.3.1, Use case 8: QoS related radio parameter optimization, 2007. [7] 3GPP R3-070118, QoS Design Principles, 2007.

3.2.4

Link level retransmission scheme optimisation

Self-optimisation Optimisation

Description Classification: Area of relevance:

The objective of the link level retransmission scheme is to enable fast and efficient retransmissions of erroneously received packets on the radio link between eNodeB and UE. There are two types of link level retransmission for LTE: MAC level: These are fast retransmissions, with fast feedback of ACK/NACK messages. Retransmissions are combined using Hybrid ARQ. RLC level: At RLC level, retransmissions are only used for Acknowledged Mode (AM). It will operate on top of MAC-level retransmission. Any residual errors after the maximum number of MAC retransmissions will be handled by the RLC protocol (up to a tuneable degree, after which

Page 35 (71)

SOCRATES

D2.1

the radio access network gives up, leaving any further attempts to the transport layer). At RLC level, feedback on which packets have or have not been received correctly is slower than at MAC level. RLC retransmission will occur a lot less frequently than MAC retransmissions. For MAC retransmission, the key associated trade-off is one of packet delay/loss versus radio resource efficiency. Packet delay and loss are optimised by preventing packet retransmissions (backward error correction) as much as possible by using higher transmit powers and more channel coding (forward error correction). Radio resource efficiency is generally optimised by allowing some amount of retransmissions, achieved by choosing somewhat reduced transmit powers and/or applying less channel coding. Optimisation of the trade-off generally depends on the handled services and, in particular, their delay tolerance. For RLC retransmission, different polling approaches are possible. Polling is the term used to describe the process of requesting status information from the receiver. Upon receiving a polling request, the receiver will send information on which packets (PDU) have or have not been received correctly. Polling can be triggered by different mechanisms: Periodic o After a fixed number of packets have been sent o After a fixed time Non-periodic o After the last packet in the transmission buffer has been sent o Window based. There is a maximum for the number of packets that can be sent before an acknowledgement is required. For window based polling, as this maximum is approached, a polling request is sent. More frequent polling results in a faster retransmission when packets are received in error, but the tradeoff is that it requires a larger signalling overhead. Objective The objective of this use case is to self-optimise the link level retransmission scheme parameters in order to optimise resource efficiency while satisfying service-specific QoS requirements. In addition to individually optimising MAC and RLC retransmissions, it should also be possible to optimise MAC and RLC retransmission together, to optimise link-level retransmission. Scheduling (triggers) For MAC retransmissions, based on continuous monitoring of experienced service quality in terms of experienced packet delays, number of applied retransmissions, link level packet delays and residual BLERs (residual refers to the resulting BLER after the MAC level retransmission scheme gives up), the associated self-optimisation algorithm is triggered when the experienced service quality is too good, in which case there is potential for resource efficiency enhancement, or too bad, in which case there is a need for service quality enhancement at a cost of resource efficiency degradation. For RLC retransmissions, similar monitoring is performed as for MAC retransmission, focusing on delays due to RLC retransmission. If delays are too high, it will be necessary to adjust the polling parameters. Input sources A key input source is statistics regarding the number of retransmissions, the experienced packet delays and the residual BLERs. List of parameters The retransmission scheme itself is parameterised by service-specific parameters, including the instantaneous BLER target (which is then via another self-optimisable mapping translated into an associated SINR target, which in turn is mapped to a corresponding transmit power setting) and the maximum allowed number of retransmissions before the MAC level retransmission scheme gives up. The associated self-optimisation algorithm may be characterised by some thresholds on the experienced service quality measures (see Input sources), indicating that delivered service quality is either unnecessarily good or unacceptably bad. For RLC retransmission, the relevant parameters are those that define the settings for polling (as described in the Description section).

Page 36 (71)

SOCRATES Actions Actions taken by the self-optimisation algorithm are the adjustment of the retransmission scheme parameters, as listed above.

D2.1

Expected results The expected result is that the self-optimisation algorithm continuously tunes the service-specific link level retransmission scheme parameters such that corresponding service quality measures (packet delay, residual BLER) satisfy the associated requirements, while achieving maximum resource efficiency. Status in 3GPP This use case has not been considered in 3GPP Measurements/parameters/interfaces to be standardised Appropriate counters should be standardised to allow an accurate and timely characterisation of achieved service-specific packet delay, number of retransmissions and residual BLER performance. Appropriate interface should be standardised to allow extraction of the input parameters into the selfoptimisation software, as well as the feedback flow back into the network in the form of adjusted link level retransmission scheme parameter settings. Possible specific measurements are: Number of MAC retransmissions MAC level packet delay RLC level packet delay Architectural aspects Since the link level retransmission scheme operates on a per cell basis, we foresee a distributed implementation of the associated self-optimisation algorithm. Example (Informative description) Consider a service for which flows are set to operate with a certain instantaneous BLER target and a preset maximum number of retransmissions. Due to favourable local propagation conditions and little current competition on the shared channel, these parameters may lead to experienced packet delays and residual BLERs that are better than necessary for that service. If this behaviour is structural (rather than incidental), the self-optimisation scheme will identify this and (gradually) adjust the retransmission schemes parameters for that service, e.g. by increasing the instantaneous BLER target (and hence allowing lower transmit power and enhanced resource efficiency). Potential gain Considering the estimated relative impact the link level retransmission scheme has on the achieved resource efficiency, compared to e.g. the admission control and packet scheduling schemes, the potential gain of self-optimising the link level retransmission scheme is expected to be fair. Feasibility is in principle deemed good, although the optimal time scale at which adjustments need to be made is to be investigated but may be rather small. Related use cases As discussed above, this use case falls under the umbrella use case GoS/QoS related parameter optimisation and from that perspective relates to its sister use cases Admission control parameter optimisation (section 3.2.1), Packet scheduling parameter optimisation (section 3.2.3), Congestion control parameter optimisation (section 3.2.2), Handover parameter optimisation (section 3.3.1) and Load balancing (section 3.3.2). References [1] Nokia, Understanding the importance of HSUPA in driving the uptake of profitable applications, presentation, September 2005. [2] K.W. Helmersson, E. Englund, M. Edvardsson, C. Edholm, S. Parkvall, M. Samuelsson, Y.-P.E. Wang and J.-F. Cheng, System performance of WCDMA Enhanced Uplink, Proceedings of VTC 05, Stockholm, Sweden, 2005.

Page 37 (71)

SOCRATES

D2.1

3.2.5

Coverage hole detection

Self-optimisation Optimisation

Description Classification: Areas of relevance:

A coverage hole (as opposed to a cell outage, which is caused by a site failure), is caused by a lack of sites, poor settings of coverage-related radio parameters (antenna tilt, azimuth, pilot power) and/or poor propagation conditions (indoor locations, shadowing by large structures, proximity to highly absorbent mediums, e.g. forests, etc). Users in the affected area have little or no network access and their calls may be dropped. The network operator and the network management entity need to be informed when a structural coverage hole is detected and actions like the adjustment of antenna parameters and/or pilot powers, directed handover to a neighbour cell, etc., need to be triggered, in a seamless fashion for the user. Changing eNB location or new site deployment should only be considered as a last resort, when all other options have failed to improve/solve the current situation. The self-optimisation of the coverage hole detection algorithm aims at dynamically adapting the parameters that determine how often and from which neighbour cells measurements about the network status should be taken. These measurements will be dynamically processed and possibly generate triggers for coverage hole resolution by other mechanisms mentioned in other use cases (not covered by this use case). Objective The objective of this use case is a timely and automatic detection of coverage holes such that the appropriate mechanisms to solve them can be triggered. Scheduling (Triggers) The execution of the optimisation algorithm may be triggered on demand, when problems related to coverage are identified; periodically , based on the expiration of a timer ; Input source The required input for the optimization algorithm will depend on the specific algorithm, but will consist of parameters that give information about the network status: User-generated received pilot signal strength per neighbour (average values, statistical distribution); Observed failures on random access channel (calls cannot be initiated) Timing advance before call drops; Number of call drops in the cell; Number call drops in a certain area (geographical area approximation at sub cell level); List of parameters Parameters that need to be optimized by the coverage hole detection algorithm are with which frequency and from which neighbouring cells measurements that give information about the network status need to be taken. If from some of the constantly monitored parameters it is deduced that there may be a coverage problem, then measurements should be taken more often and from a wider set of neighbouring cells. Actions The optimization algorithm can require / perform the following actions: Network monitoring, retrieving certain parameters and measurements Analysis of the measurements and the parameters calculated from them; comparison of the results with reference values Derivation of the optimized parameters, possibly in several iteration steps Configuration of the optimized parameters Checking of the success of the re-configuration (new set of measurements that show improvement from previous situation ) Once a coverage hole is detected and signalled, the following mechanisms for dealing with the problem could be triggered (not part of this use case):

Page 38 (71)

SOCRATES Adjustment of antenna parameters (tilt, power, etc) HO to neighbour cells / cell reselection Cell outage compensation functionality Load balancing Usage of relays for reaching that area (if present) Adding a Home eNodeB or planning a new site (last resort solution).

D2.1

Expected results It is expected that by the automatic detection and localization of the coverage hole, mechanisms which will solve this issue are triggered faster than when the coverage hole detection was performed manually, and thus (better) services can be offered to users. Status in 3GPP Similar use case formulated in R3-071603 SON use-case: Coverage Hole Detection; text to be included in TS 36.300 (E-UTRAN R8). Measurements / parameters / interfaces to be standardised Standardization of measurements / parameters as mentioned in Input source from which the network status can be derived, is needed. Some of the parameters will probably already be standardized, e.g., RSRP (Reference Signal Received Power), which is a physical layer measurement standardized in 3GPP TS 36.214. Architectural aspects The input parameters for this use case are UE measurements and their analysis will be localized in the eNBs (distributed control). Adjacent eNBs can exchange information if necessary via the X2 interfaces between them. Example (Informative description) The measurements depicted in input source will be constantly gathered and monitored by the eNB. When detecting values under/over a certain threshold or an increased number call drops, the selfoptimisation algorithm will adjust the parameters that influence how often and from which neighbouring cell measurements are taken, such that measurements are taken more often and from a wider set of neighbouring cells. This way, the eNB will attempt to narrow down the location of the UEs experiencing problems. Maps and statistics can be prepared to support the mechanism as mentioned in actions to solve the problem. This is all to be done in a short amount of time and with no visibility for the end user. Potential gain The self-optimisation of coverage hole detection would allow for A reduced need for human control and intervention in the coverage hole detection process, implying a reduced OPEX. Faster actions taken to resolve the problem, implying a possible increase of the performance and QoS. Related use cases Self-optimisation of home eNodeB (section 3.1.4) Load balancing (section 3.3.2) HO parameter optimisation (section 3.3.1 ) Management of relays and repeaters (section 3.4.4) Neighbour cell list (section 3.3.3) References [1] 3GPP R3-071603 SON use-case: Coverage Hole Detection; text to be included in TS 36.300 (EUTRAN R8)

Page 39 (71)

SOCRATES

D2.1

3.3
3.3.1

Handover related optimisation

Handover parameter optimisation
Self-optimisation Radio parameter optimisation

Description Classification: Area of relevance:

Handover in LTE supports mobility and load balancing. This use case considers the self-optimisation of the handover parameters like handover neighbour list, neighbour specific thresholds and hysteresis parameters. Therefore, this use case aims to reduce the occurrence of undesirable effects following handovers, such as call drops and ping-pong handovers between two cells. Also, this use case is strongly linked to the load balancing use case, since the self-optimisation aims at dynamically adapting the handover parameters according to the current load of the cell and that of neighbouring cells, rather than setting them to a constant value. This will also include the potential of handing over UEs to non-optimal cells (w.r.t. signal strength), to harness spare capacity in neighbouring cells. This way, the total network capacity should increase compared to the static / non-optimised case, such that with minimised human intervention more users can be accommodated with good quality. Objective Algorithms to automatically optimise parameters controlling handover. Scheduling (Triggers) The execution of the optimisation algorithm may be triggered By the identification of problems related to handover or unwanted events, like call drops, too many handover failures, ping-pong handovers between cells, QoS indicators under a reference value, etc., for the cell or for a neighbour cell By the fact that certain measurement values reach their reference values By load balancing reasons (need to move UE from a congested cell to a cell with less traffic) On demand, periodically, by external events Input source The required input for the optimisation algorithm will depend on the specific algorithm. It optionally consists of The handover trigger reason Handover related measurements KPIs calculated based on the measurements Current parameter settings Planning data like location of cells, theoretical path loss/interference Drive test results Traces of interfaces List of parameters Parameters that need to be optimised during handover parameter optimisation are: Handover neighbour list Neighbour specific thresholds Hysteresis parameter to reduce the number of unnecessary handovers and to prevent ping-pong effects Actions The optimisation algorithm can require / perform the following actions: Network monitoring, retrieving certain parameters and measurements Analysis of the handover related measurements, the calculated KPIs, the drive test results and the traces; comparison of the results with reference values Deriving of the optimised parameters, possibly in several iteration steps Configuration of the optimised parameters Checking of the success of the re-configuration (e.g., lowering an handover threshold should not increase ping-pong occurrences) Expected results It is expected that with minimised human intervention, the result of the optimisation procedures is that

Page 40 (71)

SOCRATES

D2.1

The changed parameters are active and correctly set A higher handover success rate (= lower handover failure rate) and lower call drop rate is seen Less ping-pong handovers occur The end user experiences minimal quality and performance degradation (caused by e.g., packet loss) during the handover The end user experiences a better throughput (increase in total network capacity) There is a reduction in the number and frequency of unwanted events

Status in 3GPP Handover parameter optimisation is described as a high-level use case in Section 5.1.3.1.7 of 3GPP TR32.816 V1.3.1 (2007-11) [1]. Specification level requirements are not yet defined (Section 5.2.4.1.7). Handover parameterisation optimisation is described as use case O03 in Section 4.4 of 3GPP S5071944 [2]. R3-071600 [3] is a proposal to add handover parameter optimisation as a use case to the list of 3GPP SON use cases. Measurements / parameters / interfaces to be standardised Number of handovers per neighbour cell Handover success/failure rate per neighbour cell Call drop/success rates per neighbour during the handover procedure Number of ping-pong handovers per neighbour cell Throughput before/after handover Received signal strength values per neighbour cell Average C/I (Carrier to Interference Ratio) per neighbour cell (to prevent handovers to cells with a too low C/I) Ideally, the optimisation algorithms will function with the measurements and parameters already supplied by the network for the handover process. Architectural aspects Handover parameter optimisation can be implemented in a centralised or a distributed way. A distributed way seems appropriate, since the handover will be based on local eNodeB and UE measurements (cell and neighbouring cell). It is assumed that the algorithms will be vendor specific. The algorithms and the parameters processed need to be aligned between the multivendor equipment. Example (Informative description) Handover can be performed for several reasons, like UE mobility and local congestion in a single cell (load balancing reason). When a UE moves between two LTE cells, handover should be carried out. Based on the measured radio environment (e.g., signal strength), the UE evaluates the necessity of handover. If the handover criteria are met, it sends the necessary information to the network. The source cell determines the target cell and queries the target cell if it has enough resources to accommodate the UE, in which case it hands over the UE to the target cell. With load balancing, UEs that are close to the border of a congested cell can be handed off to a neighbouring non-congested cell, thus potentially obtaining better throughput than before the handover. A self-optimisation of the handover parameters will be beneficial compared to a fixed parameter setting, because of the unpredictability of the wireless environment, and because in this way the load balancing algorithm can tune the handover parameters such that handover to the congested cell is delayed, and that handover from the congested cell is advanced. Potential gain The self-optimisation of the handover parameters would allow for A reduced need for human control and intervention in the handover optimisation process, implying a reduced OPEX A possible increase of the performance and QoS compared to the non-optimised scenario Seamless mobility Related use cases Load balancing (section 3.3.2)

Page 41 (71)

SOCRATES Neighbour cell list (section 3.3.3) GoS/QoS related parameter optimisation (section 3.2) Tracking areas (section 3.4.2)

D2.1

References [1] 3GPP TR32.816 V1.3.1 (2007-11) [2] 3GPP S5-071944: Informative list of SON Use Cases (included in 3GPP S5-071944) [3] 3GPP R3-071600: SON use case: HO Parameter Optimisation

3.3.2

Load balancing
Self-optimisation Optimisation

Description Classification: Area of relevance:

Depending on the coverage area of the cell and the spatial distribution of the offered traffic it can occur that some cells in the network are more heavily loaded than their neighbours (load imbalance). In these situations it can be beneficial in terms of network accessibility (low blocking) and retainability (low dropping) to shift the traffic from the heavily loaded cell towards the more lightly loaded cell or other RATs. This is referred to as load balancing. Note that in some situations, where the capacity is balanced over the cells, it could be profitable not to shift the load but to perform capacity (un)balancing. This means to adjust the capacity management parameters such as admission/congestion control thresholds, uplink noise rise targets, maximum allowed downlink total power, etc. in the heavily loaded cell and the surrounding cells in order to match the capacity with the traffic demand. This can be seen as a separate use case. The focus of this use case is the situation when the traffic is shifted and the resulting situation is with more balanced load. It is expected that the load balancing can have positive effect on GoS (blocking and dropping) but might have positive or negative effects on QoS (throughput, delay, etc) provided that the desired QoS levels are maintained. Objective The objectives for this use case are twofold: Timely and accurately detecting cells with load imbalance without manual involvement. Taking actions in an automatic way to resolve this load imbalance by shifting traffic towards the lightly loaded cells. The selection of sessions for transfer in other cells (or RATs) can be done on basics of radio propagation conditions, resource consumption of these sessions, etc. Note that after the transfer of ongoing sessions towards more lightly loaded cells their QoS requirements should be still satisfied. Scheduling (Triggers) This use case is triggered on demand i.e. when the load imbalance is discovered, by detecting a value over threshold or by a watchdog mechanism. Input source The most important input sources are eNodeB measurements: Uplink/Downlink Load measurements (e.g. number of ongoing real-time and non-real-time connections) at the cell of interest and its neighbours. Resource utilization i.e. the amount of occupied Uplink and Downlink resources relative to the total available resources at the reference and neighbour cells. Achieved QoS level in uplink and downlink (e.g. throughput, delay, BLER, etc). Achieved GoS level (blocking and dropping probability) load estimation parameters (e.g. the capacity a cell still has available, that can be expressed in terms of a reference unit, like x VoIP calls ) List of parameters There are several parameters that can be offered to the network operator to control the load balancing process:

Page 42 (71)

SOCRATES

D2.1

The maximum allowed load before triggering the load balancing check. For example, at low/medium load levels the load balancing might not be needed. The maximum allowed load imbalance when compared with the neighbour cells before triggering load balancing actions. The maximum number of iterations/time allowed for resolving the load imbalance. Step size i.e. the amount of load to be transferred to neighbour cells (or RATs) at each iteration.

The there are several parameters that will be optimized during this process: Handover thresholds for ACTIVE state including hysteresis parameter Cell reselection parameters for IDLE state Antenna tilt, pilot power, etc. for controlling the coverage area of the cell Actions The load balancing function can initiate the following actions: Changing the cell re-selection parameter (intra-RAT and inter-RAT) in order to shift idle mode terminals towards lightly loaded cells. Changing the handover parameter (intra-RAT and inter-RAT) in order to shift active mode terminals towards lightly loaded cells. Changing the coverage area of the cell and its neighbours by adjusting the pilot powers. The optimization algorithm can require/perform the following actions: Network monitoring Analysis of the load balancing related measurements and comparison with reference values Deriving of the optimized parameters, possibly in several iteration steps Configuration of the optimized parameters Inform non-involved neighbouring cells of the affected cell of re-configuration Checking of the success of the re-configuration Expected results The network can detect timely and accurately in an automated way the cells with load imbalance and consequently take measures to resolve this imbalance. It is noted that although the new situation with balanced load will generally have a positive effect on the GoS (i.e. less blocking and dropping), it can have a positive or negative effect on the QoS levels of the ongoing connections (while still maintaining the QoS targets). The ultimate goal is to obtain, with minimized human intervention in the network management and optimization tasks, a larger system capacity compared to the capacity in a static/non-optimized scenario Status in 3GPP Cell outage detection has been introduced by several 3GPP contributions (see References) and load balancing by self-tuning of handover parameters is proposed as use case in Tdoc R3-070562. The load balancing use case was agreed on by RAN3 and introduced in TR 36.902. RAN3 has agreed to define detailed measurements to assess load information. The load on the following resources has to be assessed: radio, eNodeB hardware, transport network. The definition of the load for eNodeB hardware and transport network resource is an open issue. RAN2 agreed on few measurements for the radio resource that are useful for load balancing. Additional eNodeB measurements are still discussed in RAN1. 3GPP is also discussing the architecture for load balancing. The exchange of load information over X2 interface is agreed by RAN3. The location of cell reselection/handover parameters' reconfiguration decision is an open issue. Additionally the definition of the cell reselection/handover parameters to be reconfigured is an open issue. Measurements / parameters / interfaces to be standardised The required eNodeB measurements (see section Input source) should be standardized such as Uplink/Downlink load (for real-time and non-real time sessions), uplink/downlink resource utilization, Signal strength of pilot channel per cell and per neighbour cell, etc. This means that measurement X should have the same meaning and should provide the same value for a given situation, no matter who the vendor of the eNodeB is. The exchange of the load measurements and resources utilization between neighbour cells should be standardized.

Page 43 (71)

SOCRATES

D2.1

Architectural aspects The load balancing can be distributed as it is based on local eNodeB measurements (from the cell with load imbalance and its neighbours). It should be noted here that because neighbouring cells are involved in the load balancing actions it should be avoided that cells take contradictory actions for shifting the load. It would be interesting to decide between the following possible solutions: Centralized: for multi vendor environments, final decision will be taken at upper level (i.e. MME); Distributed: each eNodeB analyzes the measurements it gathers from the network and communicates its decision to neighbour eNodeBs via the X2 interface; Hybrid:

Indicators for each eNodeB regarding its vendor; Each eNodeB thus knows who its neighbours are; If adjacent eNodeBs are from the same vendor they will exchange information via X2 interface; Else, higher layer decision will be triggered or a convergence layer will be integrates in the eNodeB/aGW;

A distributed solution would best fall under the requirements of LTE and is already agreed on by RAN3, but we need to keep in mind that in a multi vendor environment , each eNodeB will perform certain measurements according to different algorithms so a centralized entity needs to make the convergence between them. Of course, the eNodeBs can directly exchange measurements with their neighbours, but we have to make sure that their meaning is the same, so we need standardised measurements. Example (Informative description) The load balancing is illustrated in Figure 3 below. The number of ongoing sessions in Cell B is much larger than the number of ongoing sessions in the neighbour cells A and C. The load balancing function is able to automatically detect this load imbalance. After performing adjustments in the handover thresholds the coverage areas of neighbour cells A and C are extended and serve part of the users previously served by the overloaded cell B. This results in more balanced number of ongoing sessions per cell. Note that the self-optimisation of this load balancing algorithm is to automatically adjust the parameters such as the traffic load when the load balancing is triggered, amount of traffic imbalance that is resolved, amount of traffic that is shifted to other cells, how often the shift of traffic occurs, what actions are undertaken to shift the load, etc. The automatic adjustment of these load balancing parameters is based on the measurement history from the network regarding the load conditions (amount of traffic and traffic mix), GoS (e.g. blocking and dropping), QoS (e.g. throughput and delay), etc. Coverage Area Cell A Cell B Cell C

Cell B with load imbalance After load balancing

Cell A Cell B Cell C

Figure 3 Illustration of the load balancing Problem: What happens if both cell A and C are already congested or not accepting any more calls as to avoid a future congestion?

Page 44 (71)

SOCRATES

D2.1

Possible solutions: temporary triggering a medium/low/lower bit rate in the cell and its neighbours (provided that it will not severely affect QoS/GoS); creating a controlled ripple effect: cell A and C will further use the load balancing mechanism involving their non-congested neighbours (i.e. cell D and E);In this case, we have to decide how far this ripple effect can spread throughout the network (maximum x hop process) and weather or not it is a desirable effect. The flow diagram presented in Figure 4 explains the working of the load balancing use case. First, upon collection of the eNodeB measurements (see section about the Input Source) it is decided if the cell is having a load imbalance situation when compared with the load situation at its neighbours. When a load imbalance is detected then load balancing actions are initiated. This should be done in cooperation with the handover, QoS, optimisation functions. These actions are done until the load imbalance is resolved. Just as a clarification, the decision making entity will be situated within each eNodeB.
Congestion Optimization no eNodeB measurements Maximum Load imbalance is yes reached? Coverage Optimization HO Optimization QoS optimization

eNodeB measurements

Load Balancing Actions (Cell re-selection; Handover, etc) no Load imbalance resolved? yes

eNodeB measurements

STOP
decision making entity

Figure 4 Flow diagram for the load balancing

Potential gain If the load imbalance is detected timely and accurately and if consequently the load is balanced among the neighbour cells then there should be improvement in GoS level (i.e. less blocking and dropping), reduced OPEX due to less manual intervention in the network management and optimization tasks and more users can be accommodated into the system. Related use cases Handover parameter optimisation (section 3.3.1) Congestion control parameter optimisation (section 3.2.2) Coverage hole detection (section 3.2.5) Admission control parameter optimisation (section 3.2.1) Neighbour cell list (section 3.3.3) References [1] R3-072249, Load balancing use case involving cell reselection and handover parameters self optimization, Telecom Italia, Orange, T-Mobile, Telefonica, NTT DoCoMo. [2] R3-071438, Load Balancing SON Use case, Alcatel-Lucent [3] Tdoc R3-070562: Self-optimization use case: self-tuning of handover parameters [4] R3-061197, Congestion Status Indication in E-UTRA

Page 45 (71)

SOCRATES

D2.1

[5] Comparison of SON architectures for load balancing, Telecom Italia, Archive of the NGMN SelfOrganising Networks Project 12 mailing list, February 8, 2008. [6] R3-070597, Mechanisms to achieve distributed load balancing in LTE [7] 3GPP TR 36.902 V0.0.1 Evolved Universal Terrestrial Radio Access Network(E-UTRAN); Selfconfiguration and self-optimizing network use cases and solutions

3.3.3

Neighbour cell list

Defining neighbour cell lists is seen as a significant manual effort [1]. Automating this process is therefore commonly seen as beneficial. Neighbour cell list optimisation is a popular application of SON techniques, and it is being extensively addressed in 3GPP (for an example, see [2]). Ericsson and others are already actively working towards solutions (for examples, see [3], [4]). For these reasons, SOCRATES will not spend additional effort on this use case. References [1] NGMN Project 12, Informative List of SON Use Cases, v 1.53, section 4.2 (included in 3GPP S5071944) [2] 3GPP R3-072014, Introduction of automatic neighbour relation function, Ericsson [3] J. Baliosian and R. Stadler, Decentralized configuration of neighboring cells for radio access networks, Proceedings of IWAS 07, Finland, 2007. [4] F. Parodi, et al., An automatic procedure for neighbor cell list definition in cellular networks, Proceedings of IWAS 07, Finland, 2007.

3.4
3.4.1

Other
Reduction of energy consumption
Self-optimisation Optimisation

Description Classification: Area of relevance:

In the past, the primary design goal for wireless networks was increased spectral efficiency, i.e. to support as high data rates with a given spectrum as possible. The power consumption played a minor role so far. However, recently energy costs have become of high interest in public and thereby also in telecommunications. In the future, on top of spectral efficiency, energy efficiency has also to be considered, i.e. to minimize the energy consumption for a given cell load, which might be varying in time and space, as much as possible. This has three principle reasons: Costs for electricity are already a non-negligible component of the operators OPEX. Energy costs are increasing tremendously. Environmental aspects are strong arguments in the public and part of many companies' corporate responsibility portfolios. The CO2 emission is an important figure of merit already now, although no regulatory limits have been defined so far. Objective The main objectives for this use case are: Reduce OPEX cost spent on energy. Reduce CO2 emission. Get positive image of an environment friendly technique and network. Minimize usage of excessive resources during low or light traffic period. Ensure coverage during switch off periods. Consider QoS requirements of users when switching off cells/reducing resources.

Page 46 (71)

SOCRATES

D2.1

Scheduling (Triggers) Reduction of energy consumption will be mainly based on traffic monitoring with regard to QoS and coverage assurance. Not only current situation but also potential state of the network has to be considered. Proposed general triggers are based on the resource utilization When the resource utilization is below specified threshold for an appropriate amount of time then resources are switched off. Threshold and time interval should be based on network statistics as well as state of resource utilization during measurement period. When the resource utilization is above a specified for a sufficient amount of time then resources are switched on. In case of dropped call or QoS degradation resources are switched on. Input source Input data for energy consumption reduction algorithm: Load indicator QoS of users Traffic statistics from the past Coverage data from planning tool or specified measurements List of parameters Parameters that may be modified by an energy consumption reduction algorithm are: State of eNodeB and its cells (On/Off) Transmit power Power control settings Number of Tx antennas Handover parameters Actions Possible actions for reduction of energy consumption algorithm are: Monitoring load in the network and identifying shortage or excess of the resources. Collecting data from coverage measurements to prevent possible coverage holes during switch off periods. Switching on/off redundant resources e.g. Tx antennas, complete NBs Assuring HO for users from switched off cells Adapting radio parameters in neighbourhood of affected cell to new configuration of the network Monitoring impact of parameter reconfiguration Expected results Expected results are: Minimized energy consumption and CO2 emission Full transparency for users Ensured coverage Ensured QoS Status in 3GPP Reduction of energy consumption use case has been put as separate use case into TR 36.902 Selfconfiguring and Self-optimizing network use cases and solutions. Draft descriptions can be found in R3080460 and R3-080528. For a distributed solution, the X2 interface will be used. Work is already ongoing in 3GPP to define signalling over this interface, but no decisions have been made yet. Measurements / parameters to be standardised Reduction of energy consumption requires following measurements: Load measurements Coverage measurements The need and possibility of standardization of above measurements is for further study.

Page 47 (71)

SOCRATES

D2.1

Architectural aspects Current work in 3GPP RAN1 is based on the assumption that the X2 interface will be used for signalling between eNodeBs (3GPP R1-075050). This implies a distributed solution. In addition, it may be useful to also have a centralised SON function, which manages the interaction between different cells. Example (Informative description) In wireless networks, typically load is varying considerably within a day, cf. Figure 5. Network deployment, however, needs to be dimensioned to the peak load, i.e. typically a dense network with small cells will be deployed to accommodate the required maximum traffic. During times with low load it might therefore be possible to switch off certain resources, e.g. the RF of a cell and if necessary provide contiguous coverage by adaptation of parameter settings in neighbouring cells, e.g. transmit power, antenna tilt, etc. Furthermore the problem can also be investigated including the possibility of inter-RAT load balancing / handover for deployments where a certain area is covered by different RATs.

Average Traffic Distribution over Day

1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00

Figure 5 Average traffic distribution over a day

Potential gain Introducing time-variant network configurations to adapt the offered capacity to the actual needs, is a new design goal, which is therefore expected to be a valid field for research and optimizations. The highest potential gain is on high load, capacity limited areas, where umbrella coverage is available. The differences between night and day traffic allow freeing many resources. Gain on reducing energy cost has to be estimated basing on percentile of energy cost in OPEX, regarding also impact on power amplifiers and potential negative effects in network performance (coverage outage, QoS degradation etc.). Additionally there is important but difficult to measure image gain that comes from CO2 emission reduction and environment friendly network performance. Related use cases Cell outage management (section 4.1) Coverage hole detection (section 3.2.5) Load balancing (section 3.3.2) References [1] R3-080460, Energy Savings SON Use case [2] R3-080528, Energy Savings and Interference reduction Use Case Description [3] TR 36.902, Self-configuring and Self-optimizing network use cases and solutions

Page 48 (71)

SOCRATES

D2.1

3.4.2

Tracking areas
Self-optimisation, self-configuration Optimisation/Planning/Deployment

Description Classification: Area of relevance:

The mobility management of UEs in mobile cellular radio networks requires a localisation concept: location and routing areas (LA/RA) in GERAN, user registration areas (URA) in UTRAN and tracking areas (TA) in E-UTRAN. In release 7 of 3GPP [1] the TA concept is under discussion, and several different concepts are proposed prioritising maximal flexibility, requirements of LTE/legacy system architectures, assistance by the UEs, etc. Most of them define one or several TA codes (TAC) for each cell. However, esp. one concept (distance based registration, see below) defines, instead, a distance threshold. These parameters have to be broadcast on the broadcast channel of each cell, can be variably configured and optimised according to a minimisation of UE registration update and paging. This use case takes into account the numerous proposals (see below). UEs are expected to be registered in several systems (GERAN, UTRAN, E-UTRAN), in which they can be localised in a prioritised order. The concept for release 8 might offer the possibility to split TAs and so-called paging areas [15]. Also, the grade of assistance by the UEs in the localisation concept is under discussion. Both issues have an impact on the UE statistics and the available input for optimisation and configuration. [19] (Vodafone) states that the main high-level requirement for LTE is that it should operate efficiently in a pure multi-vendor environment. One of the key areas to allow LTE to satisfy this goal is the standardisation of SON for a multi-vendor RAN. Planning (by means of finding a proper configuration) and optimisation of a localisation concept in selfoptimising networks (SON) require mechanisms for self-configuration and self-optimisation of TAC and, if necessary depending on the standard, related parameters. The goal is to make sure that the SON framework includes standard mechanisms to automate the configuration of these parameters. Input data, both for planning and optimisation, must be standardised including the definition of performance indicators and required measurements by the network as well as by the UEs. Concerning reliability of input data, in many cases the eNodeBs are providing the input data which forms the basis of the SON activities. The quality of the output of the SON algorithm can only ever be as good as the quality of the input, and therefore it is an essential prerequisite that this information is consistent across the eNodeBs of different vendors. To satisfy this requirement there is an initiative in the RAN groups to ensure eNodeB measurements be standardised. A preferred solution would be to use a common object model for the information being passed between the eNodeBs and the Network Manager, as this would avoid any errors unnecessarily introduced into the measurement data [19]. The design of TAs is expected to need no adjustment on short-term basis (in comparison to, e. g., power control). The required overhead, esp. signalling to UEs to update their TAC (lists), is expected to be too large. However, required measurement figures for configuration/optimisation algorithms are expected to have a high variance over time, which is another reason to reconfigure TAs only in a long-term manner; otherwise reconfiguration is expected to happen too often. On the other hand, certain events (in sports, fairs, etc.) might be allowed to trigger a reconfiguration in a certain region. Storage of the above mentioned figures, e. g. in a database, to detect outliers and to trigger an action, accordingly, or remove outliers, is recommended. Configuration and optimisation algorithms require knowledge about the expected signalling load resulting from the determined parameters. For that, procedures are required for estimation of the impact on the signalling load triggered by a change of the cells' coverage area and their user assignment probabilities (eNodeB start-up, shut-off/outage, reconfiguration, etc.). In the following the term tracking area update (TAU) is used for the general term UE registration update in LTE. Furthermore, the parameters that have to be standardised concerning TA, are termed TA parameters (TAP). Objective The main objective is to allow automatic configuration/optimisation of TAP and, if necessary depending on the standard, related parameters. Furthermore, the work load on configuring these parameters in the network has to be reduced. Especially, it should be possible to implement a new parameter configuration without manual shut off of the eNodeBs or without shut off at all (e. g. in GSM BSs have to be shut off during reconfiguration of LA/RA).

Page 49 (71)

SOCRATES

D2.1

A reduction and a good balance of the signalling load in terms of paging and tracking area updates have to be obtained. This also implies a reduction of ping-pong effects and a support to prevent hard TA borders. For the latter requirement, [1] allows the TAs to partially overlap each other. Reliable input for the configuration/optimisation algorithms like network/UE measurements have to be standardised to fulfil the objectives. Scheduling (Triggers) Based on performance indicators defined on statistical performance measurements of paging and TAU counters, the detection of exceeded signalling thresholds trigger an optimisation/reconfiguration of TAPs. A new cell configuration leads to a shift in the assignment probabilities of users to cells and therefore to a shift of signalling. This includes the outage and start-up of cells. In these cases TAPs might have to be reconfigured. Certain events can lead to an exceptionally high traffic in certain regions. Based on the planner's experience and collected information (e. g. in an event manager) a new configuration of TAPs might be necessary. Input source In the operational state, operators will be continuously monitor performance measurements (PM) out of PM counters collected in the OAM (or something similar like OMC, O&M, etc.). In general, configuration/optimisation algorithms require knowledge in terms of the paging contribution per cell and the mobility relation between pairs of cells. Furthermore, the basic signalling load, which is independent of the TA configuration and requires signalling capacity along with TAU and paging, has to be known. For this, mainly based on the experience with GERAN networks, a number of measurements need to be collected from the network and/or UEs (if available): statistics about UE mobility patterns according to the requirements given in [11] (sufficiently large number of UEs, history report of mobility events with the granularity of cells uncorrelated of the result of prior optimisation and configuration of E-UTRANs), number of TAU per cell, number of triggered HO, measured per cell relation, number of paging request per paging area, number of paging responds of the UEs per cell (called Mobile Terminated Calls MTC in GERAN), number of signalling attempts that use the same channel as TAU and/or paging The relation between paging messages sent by the network and the number of responses out of a specific cell deliver statistical information on the paging contribution per cell. In the same manner, the relation between the number of triggered HO between pairs of cells and the number of TAU provides roughly statistical information about the users' mobility in the network. However, in comparison to the paging message/response relation the HO/TAU correlation do not tend to be so high, because the order of magnitude between these two values is very different (up to a factor of 20) and the UE state (idle/connected) is different. Furthermore, it is expected that the number of HO decreases with the use of packet-switched instead of circuit-switched connections. Therefore, the UE assisted collection of statistical (or individual) mobility patterns is recommended and should be supported. Be aware that the collection of signalling traffic and mobility patterns is a long-term job to generate required input data for configuration/optimisation algorithms. In case that an action is triggered, the algorithms request processed measurement data and not the measurement values itself. List of parameters Depending on the standard, following TAPs have to be configured: TAC (list) per cell, distance threshold R , Actions Configuration/optimisation algorithms can trigger the following actions: request for processed UE and network measurement data, configuration of UE and network measurement jobs (periodic, certain set of UE, certain region, request for upload of UE mobility pattern), determination of optimised TAPs, (online) implementation/reconfiguration of TAPs

Page 50 (71)

SOCRATES

D2.1

Be aware that the measurement period should be long enough to detect outliers, missing values, etc. The goal is to determine an average representation of the network usage which is different over time, esp. at weekends when data traffic falls noticeably. Expected results Reduction and good balance of signalling load concerning paging and TAU. Status in 3GPP Within [1], TA is used as a generic name for LA (Location Area, GERAN), RA (Routing Area, GERAN) and URA (UTRAN Registration Area, UTRAN). Agreements on TA issues are that there is only one common TA concept defined for RAN and CN in LTE/SAE. the location of a UE in LTE_IDLE is known by the network on a TA granularity a UE in LTE_IDLE is paged in all cells of the TA in which it is currently registered in order to avoid excessive TAU signalling within LTE, for terminals located on TA border, the following solutions should be considered, but detailed solutions are FFS; o allow one LTE cell to belong to multiple TAs, and allow the TAs to partially overlap each other o support the allocation of multiple TAs to the same terminal. The main concerns, by which the following different proposals are driven, are (some of them depend on each other) the ping-pong effects at the edge of fixed, non-overlapping TAs, user velocity, different frequencies of TAU, different user mobility patterns (static, fast), etc., the compatibility with legacy systems, the necessity to have TAs spread over cells of different systems (GERAN, UTRAN, E-UTRAN), different vendors of network elements [19], adaptation of TAs according to number of users and users' activity which change over time, with new subscribers, new services, unpredicted events, etc. The different, partly overlapping localisation concepts can be classified into overlapping TAs [4], [5], [18], [8], [9] hierarchical TAs [5], [18], [7], [9], [17] dynamically defined user-specific TAs (like distance based registration) [2], [8], [9] and equivalent TAs [8], [9]. A good overview of the different concepts is given in [14] (Huawei). It compares the concepts and concludes that the equivalent TA concept should be the basic solution due to its good performance, low complexity and high flexibility. Some concepts require assistance by the UEs, which is introduced in [3], [10], [12], or the collection of UE mobility patterns, which is introduced in [11], [13]. In the following, all proposals are summarised. Most of the concepts are driven by the objective of minimising TAU. Paging is often only mentioned, but not seen as criteria for optimisation. Furthermore, most of these proposals are also text proposals to [1]. [4] (Ericsson) drives for the overlapping TA concept to avoid hard borders. Most of the functions in LTE_IDLE state should be handled by a central function called MME / UPE. Multiple TAI will be broadcast on the cell BCH. With this concept unnecessary toggling between TAs can be avoided when the terminal is moving around in local area. Special cases concerning MME /UPE relocation and mobility to/from other 3GPP accesses are discussed. An architecture supporting multi-to-multi configuration between MME / UPEs and Node Bs is recommended, so that it is possible for several MME / UPE to have terminals in the same tracking area, which means there is no need for hard tracking area borders between MME / UPE coverage areas. [5], [18] (Samsung) discusses various methods. It concludes that the concept of overlapping TA is beneficial as agreed in [1] and rules out the distance based solution from [2]. It proposes the concept of hierarchical TA incorporating overlapping TAs using several levels of TAs to be configured in a cell. Vertical as well as horizontal TAU is possible. The main thought is to cope with UEs in different speeds.

Page 51 (71)

SOCRATES

D2.1

[6] (Mitsubishi Electric) introduces the concept of reference point ENB(s) for the purpose of transferring paging request messages in large tracking areas. It analyses requirements and performance of inter ENB connections, redundancy, MME / ENB processing load and paging transfer delay. This concept is used in [7] proposing the principle of hierarchical TAs, where the tracking area size depends on the velocity of UE and/or the estimated frequency of incoming calls. The MME optimally selects the TA of a given UE camped in a given cell according to the UE movement characteristics. When a MME receives a notification of incoming downlink packet from a UPE, it sends a paging request message with hop information to the reference E-Node B in the TA. The hop information defined by the UE velocity class tells about the number of adjacent ENB tiers the paging request has to be forwarded to. [17] (Lucent Technologies) proposes a concept of hierarchical TAs where every E-node B could be associated a fixed number of TAs with different sizes. A UE is assigned a specific TA size dependent on timer thresholds. [2] (Qualcomm Europe) proposes distance based registration. Each Node B would broadcast in the system information message the Latitude and Longitude of the base Node B position. A UE would only signal a position update if the distance between the position it registered last time and the actual one is bigger than a distance threshold R . [8] (Vodafone) proposes the equivalent TA concept for use in both intra and inter-System LTE mobility, which addresses the issues with signalling load caused by ping-pong and hard mobility boundaries. In keeping the UE and Mobility Area Identities for each system separate, it allows the use of a different code space and the size. Restrictions due to roaming or based on user subscription can be handled easier. The equivalent TA concept could easily be used in conjunction with the overlapping or hierarchical concepts. [9] (Mitsubishi Electric) introduces the concept of Virtual Location Areas (VLA). One concern taken into account is the necessity to have TAs spread over cells of different systems, so as to avoid unnecessary ping-pong procedures at the edge of isolated LTE cells. Concept can include the concepts of overlapping [4], compatibility with legacy systems (GSM, UMTS), hierarchical TAs [5], [7] and dynamically defined user-specific TAs [2]. [3] (LG) proposes that the UE should assist the network with information for the choice of the most suitable TA. Mainly the examples of static and very quickly moving UE are discussed to adjust the sizes of TAs / the number of TAs assigned to a UE. [10] (NEC) propose a concept of flexible TAs which are not broadcast by the network but are individually assigned to UEs based on radio conditions experienced by these UEs (past reselections and/or measurements). The dynamic assignment of TAs to UEs that reports a stationary condition within a set of cells is considered as a method to reduce paging within fixed TAs without any network planning or configuration. It can help reduce the paging increase created by overlapping TAs, but it can also assign to each stationary UE a paging area that spans across non-overlapping static TAs, so that stationary UEs will not contribute to the signalling load at TA border. [12] (Mitsubishi Electric) proposes a mechanism comparable to [10], but deals with TAs only, hiding cells to MME's view. [11] (Mitsubishi Electric) proposes that, at the time the UE sends a TAU message, it reports to LTE/SAE network the list of past visited cells since it performed the last TAU procedure. With this statistics information about mobility across LTE/SAE networks are collected for self-configuration of the design of TAs, determination of neighbour cell lists and needed X2 associations. Optionally UE can be triggered to send cell lists during limited period of time or a limited population of UEs. [13] (ZTE) focuses on self-optimisation of TAs in collecting and analysing the statistical data of the mobility activity pattern of the UEs under certain TAs during observation period. Given information is very rudimental and some things are unclear like the definition of mobility activity pattern or the way of measuring a criteria to split TAs in several smaller TAs, because only TAU are mentioned, no mobility statistics on cell basis. [15] (Huawei) splits the context TA into the terms register area, movement area and paging area. A RA is defined as the area where a UE is registered in the network and could move without initiating registration/update signalling. A PA is defined as the area where the network pages the UE. According to the UE's velocity or the movement characteristic, a MA of UE may be calculated in MME/UPE. The intersection of the movement area and the RA is the PA of the UE. In case of paging failure in the PA, paging in the RA may be initiated. Based on these definitions [16] considers the optimisation of paging signalling when the UE is registered in several RAT and proposes that the UE should camp in a preferred RAT.

Page 52 (71)

SOCRATES

D2.1

Measurements / parameters / interfaces to be standardised The measurements collected from the network and/or UEs depend on the implementation, e. g. if the UEs track themselves on cell level, TA level, etc. Anyway, information about traffic regarding paging and mobility has to be collected, somehow. Recommended measurement procedures are: collect transition information of UEs in active mode, at the time of handover, collect transition information of UEs in idle mode, at the time of TAU procedure, including (if available) mobility history with cell granularity, collect number of paging requests per paging area, collect number of paging responds per cell, collect number of signalling attempts on the channels which are also used for paging and TAU. These measurement procedures require appropriate interfaces to the network elements and, if required, to a separate data base where long-term measurement values are recorded. Architectural aspects It is unclear where the SON mechanisms and the mobility management will be implemented (eNB, MME, OMC). Example (Informative description) The triggers, process connections and actions are summarised in Figure 6.

long-term measurement job (incl. other networks)

optimisation of TAP

yes

signalling treshold(s) exceeded?

PM data base
paging msg/rsp HO, TAU, other

UE mobility history

(re-)configuration of TAP

signalling estimation

measurement processing
average long-term representation of user traffic generation and mobility (incl. other networks)

yes

yes

new configuration?

new event?
paging contribution (cell) TAU mobility relation (cell pair) additional signalling load etc.

list of configured cells

event manager
planners experience (incl. other networks)

Figure 6: Flow diagram of TA optimisation and configuration

Potential gain The potential gain for the tracking area optimisation will be high if long-term developments of changes in the mobility patterns of UEs are considered. The gain will be an improvement in GoS level, reduced OPEX due to less manual intervention in the network management and improvement in the balance of operating load. The gain will be low for optimisations due to short-time traffic peaks because tracking area optimisation needs much signalling traffic and hence time which makes it impossible to adjust to short-time changes.

Page 53 (71)

SOCRATES Related use cases Neighbour cell lists (section 3.3.3) Determination of needed X2 associations [11]

D2.1

References [1] 3GPP TR 23.882 V1.14.0 (2008-01), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution: Report on Technical Options and Conclusions (Release 7)" [2] 3GPP R2-060056, "Distance based Registration", QUALCOMM Europe [3] 3GPP R2-071325, "UE assisted tracking area update", LG Electronics Inc. [4] 3GPP R3-060049, "Idle Mobility and Tracking Area Concept in SAE / LTE", Ericsson [5] 3GPP R3-060148, "Discussion on configuration of tracking area", SAMSUNG [6] 3GPP R3-060151, "Transferring a paging request message", Mitsubishi Electric [7] 3GPP R3-060153, "Hierarchical Tracking Area", Mitsubishi Electric [8] 3GPP R3-060457, "Equivalent Tracking Areas", Vodafone Group [9] 3GPP R3-060490, "Virtual Location Areas", Mitsubishi Electric [10] 3GPP R3-061087, "UE-reporting based network-assigned Tracking Areas", NEC [11] 3GPP R3-070660, "Collecting mobility statistics in support of configuration and optimisation of LTE/SAE networks", Mitsubishi Electric [12] 3GPP R3-070782, "Reported List of Last Visited Tracking Areas", Mitsubishi Electric [13] 3GPP R3-071415, "Self-Optimization for Tracking Areas", ZTE [14] 3GPP S2-061366, "Proposed Tracking Area Concept", Huawei [15] 3GPP S2-061368, "Register Area and Paging Area", Huawei [16] 3GPP S2-061369, "Paging Optimization in Overlapping Area", Huawei [17] 3GPP S2-061434, "Hierarchical tracking Areas in the evolved system", Lucent Technologies [18] 3GPP S2-061652, "Hierarchical TA Concept", Samsung [19] 3GPP S5-071275, "SON philosophy for LTE", Vodafone

3.4.3

TDD UL/DL switching point

Self-optimisation Optimisation

Description Classification: Area of relevance:

In a Time Division Duplex (TDD) system time-slots may be assigned as uplink direction (UL) as well as downlink (DL). One of the main objectives is to assign dynamically the number of uplink and downlink slots to fulfil users requirements (uplink/downlink load). From a synchronous network point of view, all base stations (BS) should have the same frame structure to ensure that interference generated by users transmitting (uplink), or base stations sending data to users (downlink) are synchronized among all eNodeBs in network (see Figure 7). Delays among the cells causing smaller misalignment are not considered here and this is assumed covered by the switching times embedded in the system design.

BS1 BS2
Figure 7 Opposite time-slot configuration for two adjacent base stations

Page 54 (71)

SOCRATES

D2.1

A main theoretical advantage of TDD over FDD is the fast shuffling of capacity between uplink and downlink. However, the above issues significantly hinder this potential of TDD since the fast communication of a DL/UL capacity shift that all BS can agree on is very hard to achieve in practice even when BSs are connected with direct interfaces such as an X2 link. For a local area deployment this is further complicated since the assumption of direct communication among BSs and access to GPS service for frame synchronization is questionable. This further reduces the scope of applicability and the costs of deployment unless methods are sought to allow for more dynamic and independent operation for each TDD BS. Here, it is assumed that BSs are synchronized at frame level (either by GPS, X2 or some over-the-air synchronization scheme). However, it is assumed that not all base stations have the same time-slots allocated for uplink and downlink, because in some areas users need more downlink than uplink and vice versa. From that perspective is very important to have knowledge of the influence on networks performance having opposite assignments of uplink and downlink slot, in the same time, for users belonging to two different base stations. Having a flexible UL/DL switching point, allows switching between downlink and uplink, or in opposite way which is very important for TDD network. Switching between downlink and uplink is realized with a guard period (GP) located in time slot number 1 in frame structure two (FS2). When we must switch between uplink and downlink direction we use timing advance mechanism. Objective The main objectives for this use case are: Minimise the impact of inter-cell interference in unsynchronized slots, by managing the resources used in neighbouring cells Find a fine trade-off between QoS requirements for cells and possible negative impact from unsynchronized UL/DL interferences. Ensure good cell edge performance, while maintaining spectral efficiency Maintain a fair balance between cell edge user performance and performance of users closer to eNodeB: Ideally all users should have equal performance, but in practice it may not be efficient to give high throughput to cell edge users, at the expense of users closer to the eNB. It is necessary to find the right trade-off. Consider both uplink and downlink Scheduling (Triggers) Alignment of switching points should be based on both QoS uplink and downlink capacity requirements based on load monitoring - as well as on continual interference monitoring. Input source As input data to a TDD UL/DL split algorithm, the following information may be used: User QoS (throughput, delay, packet loss) User location (how close to cell edge) Interference level for each resource block Load/Interference indicator from other cells Switching point configuration of neighbours cells List of parameters Parameters that may be modified by an UL/DL switching point alignment algorithm are: Switching point configuration Sub-band transmit power Resource block transmit power Scheduler settings Power control settings Assignment of resource blocks to users Actions At this stage, it is not possible to specify detailed actions, as no algorithms have been defined yet. However, using a high level description, a possible process is: Monitor interference levels, QoS and load/interference status from neighbour cells Detect problems Take action to deal with problem, for example:

Page 55 (71)

SOCRATES o o o o Switch to a fractional re-use scheme Reduce maximum transmit power Change switching point Send indicators to neighbour cells

D2.1

Expected results Expected results are: Better data throughput Higher cell capacity Better cell edge performance, while maintaining spectral efficiency Higher user satisfaction (lower delays, jitters for real time traffic) Status in 3GPP LA-TDD is a Rel.9 related topic. At current stage no direct discussions are settled on 3GPP forum. Full synchronization in the network is assumed by now for TDD system. TDD specification for physical channel can be found in TS 32.611. Measurements / parameters to be standardised To support the interference control use case, the following standardised measurements are required: QoS measurements, per user (throughput, delay, packet loss) Estimation of user location (close to cell edge or not) Measurement of interference levels, both in uplink and downlink, per resource block Architectural aspects The current work in 3GPP RAN1 is based on the assumption that the X2 interface will be used for signalling between eNodeBs (3GPP R1-075050). This implies a distributed solution. In addition, it may be useful to also have a centralised SON function that manages the interaction between different cells. Example (Informative description) Situation where two adjacent base stations have opposite transmission direction assignment of the same time slots have major influence over cell-edge users, because they experience two types of interference: UE-to-UE interference, when users from BS1 have assigned e.g. time slot 5 for UL direction, and users belonging to BS2 have the same slot configured as DL, then users from BS2 receive additionally interferences from BS1 users. This problem is very serious from BS2 cell-edge users, because they are experiencing the highest interference level, generated by cell-edge users from BS1 BS-to-BS interferences, when BS1, configured as uplink for time-slot 5 is receiving signals from own UEs (but not only) will also receive downlink signal (interferences) from BS2. This problem is not serious as mentioned in first bullet, but it has also influences the overall network properties. In Figure 8 the interference situation described above is presented.

BS1

X2
BS B toS

BS2

-to UE

E -U UE2

BS1

UE1

BS2

Figure 8 UE-to-UE and BS-to-BS interferences

Page 56 (71)

SOCRATES

D2.1

Potential gain The usage of adaptivity of switching points allows to achieve best possible capacity and QoS assurance, however it needs good interference coordination mechanism to prevent potentially very high UE-UE interferences. Related use cases Interference coordination (section 3.1.1) GoS/QoS related parameter optimisation (section 3.2) Load Balancing (section 3.3.2) References [1] 3GPP TS 36-211 Physical Channels and Modulation (Release 8)

3.4.4

Management of relays and repeaters

Self-configuration and self-optimisation Deployment, optimisation

Description Classification: Areas of relevance:

Deploying relays and repeaters in a telecommunication network is a way to increase coverage and/or capacity of a cell in a cost-efficient way. The repeater is a simple device that receives and amplifies a received signal, including received interference, while a relay is somewhat more intelligent as it receives the actual data and then forwards it. The configuration and management of relays and repeaters is a complicated task that requires a lot of aspects taken into account and the area is therefore an area where self-configuration and self-optimization are foreseen to be favourable. When a new relay or repeater is added in a network it needs to automatically find its configuration and connect to the network. The interference caused by the relay or repeater should be kept as low as possible. This could be done by adjusting the transmission power or by using beam forming. Objective A newly installed relay or repeater should automatically find its configuration and connect to the network During operation, it should be possible to identify situations when the network does not gain from relaying identify situations when the network would gain from relaying adjust the power from the relay or repeater in order to minimize the interference while still optimizing the gain optimize beam forming parameters of the relay or repeater Scheduling (triggering) At start-up a new relay or repeater must connect to the network Power optimization should be turned on when the interference level in the serving eNodeB, in the surrounding eNodeBs, or in a given percentage of the UEs rises above a given threshold. Input source Possible input sources for the self-configuration and self-optimization are relay signal strength measurements in the eNodeB measurements of the total signal strength deriving from a UE (with or without relaying) performed by the serving eNodeB measurements of the signal strength from a UE performed by the relay measurements of the received signal strength in the UE interference measurements performed by the UE interference measurements performed by the relay interference measurements performed by the serving eNodeB interference measurements performed by surrounding eNodeBs List of parameters Possible parameters to be adjusted are

Page 57 (71)

SOCRATES configuration parameters relay/repeater power beam forming parameters

D2.1

Actions At start-up of a new relay or repeater, it should automatically find its configuration and connect to the network. If the interference level in the eNodeB or in a given share of the UEs rises above a given threshold, the relay transmission power should be lowered. Expected results The relay or repeater will automatically connect to the network The relay or repeater will not disturb the traffic in a cell if it cannot provide gains more valued than the lost capacity. The interference from a relay or repeater in operation will be kept at its minimum leading to a lower error rate and fewer dropped calls. Status in 3GPP Relays have been discussed, but no specifications have yet been presented for approval. Measurements/parameters/interfaces to be standardized The following measurements/parameters/interfaces may be needed for this use case: - Interface between the relay and the serving eNodeB - Relay signal strength measurements in the eNodeB Architectural aspects The network connection and the beam forming are local tasks that should be handled in the relay and/or the serving eNodeB. Power adjustment may however need to be managed from a higher node, where it is possible to evaluate the interference situation from a network perspective. Example (description) Two relays, relay A and relay B are connected to an eNodeB, see Figure 1. In the uplink relay B forwards the signal from UE2 and UE3. Relay A forwards the signal transmitted from UE1. As UE1 moves closer to the eNodeB the total signal strength received in the eNodeB deriving from UE1 becomes greater and greater in relation to the estimated signal strength from relay A. Once the difference between the total received signal strength and the estimated signal strength from relay A falls below a given threshold, relay A actively stops forwarding the signal from the UE in order to reduce the interference it is causing.

Page 58 (71)

SOCRATES

D2.1

eNodeB

UE1 Relay A Relay B

UE2
Figure 9 UE1 amplified by Relay A is moving towards the eNodeB and the forwarding from relay A becomes superfluous. Potential gain Relays introduced in a manner aiming at minimizing the disturbance they cause in the network while still utilizing the increased range and/or channel quality they give will in a cost-efficient way provide larger coverage areas and/or higher capacity. In general, costs will decrease when introducing self-configuring relays. By using self-optimisation the interference caused by the relays will be adjusted more efficiently. For example, the interference can be controlled with a higher frequency than what is possible to do manually, resulting in a timely response to changes in network characteristics. Related use cases Interference control References (3GPP/NGMN) The 3GPP specification 3GPP TS 36.106, Evolved Universal Terrestrial Radio Access (E-UTRA); Repeater radio transmission and reception has not yet been presented for approval. The use case is not a part of the NGNM list of SON use cases.

3.4.5

Spectrum sharing

Spectrum sharing means that different operators use the same spectrum, but detect whether that spectrum is being used otherwise or not. If it is not being used by any other operators, an operator can use this spectrum. Obviously, this requires advanced algorithms to avoid interference issues. This use case is currently seen as a low priority, as it is uncertain what the demand will be for the application of spectrum sharing. It will therefore not be considered by SOCRATES at this point. However, this may be reviewed at a future date.

Page 59 (71)

SOCRATES

D2.1

Self-healing use cases

All the self-healing use cases considered within the SOCRATES project are describing cell outage issues. Predicting outage, before it happens (section 4.1.1, Cell outage prediction), detecting it, when it happens (section 4.1.2, Cell outage detection), and then trying to compensate for the outage of neighbouring cells (section 4.1.3, Cell outage compensation).

4.1

Cell outage management

The cell outage management is an umbrella use case that covers the whole process of cell outage mitigation from the prediction and detection phase to the cell outage compensation where appropriate actions are taken to counteract a cell outage. We define that a cell is in outage when the UEs, in the coverage area of the cell, cannot establish and/or maintain all or only a limited set of the Radio Bearers (RBs) via that particular cell due to hardware and/or software failures at the eNodeB. This down time or malfunctioning can be on the radio or transport level. With limited set of unsupported RBs we address the case when, for example, broadcast and/or high-speed data RBs are not available while voice RBs are still established and maintained. In order to clearly define the different phases of the cell outage management we define the following use cases that fall under this umbrella use case of cell outage management: Use case: Cell outage prediction Use case: Cell outage detection Use case: Cell outage compensation The cell outage prediction function gives an early warning and assists to speed up the actual cell outage detection and also to start preparation actions in the cell outage compensation function in the system. The cell outage detection confirms that at the current time an outage has occurred and triggers the cell outage compensation function to take appropriate actions. Both, cell outage prediction and detection make decisions based on analysis and correlation of different measurements collected from the network (e.g. eNodeB measurements, UE measurements, and O&M measurements) while cell outage compensation defines which neighbour cells are good candidates to mitigate the detected outage and what is the best approach to solve the occurred outage e.g. by means of load balancing, handover (intra-RAT and interRAT) optimisation, and coverage optimisation,. This is presented in Figure 10. Note that via the cell outage compensation actions this use case can be linked with other use cases such as load balancing, handover optimisation, and coverage optimisation. It should be stressed that the situations when there is a coverage hole in a certain area of the network due to e.g. extensive interference are out of the scope of this use case. This use case is classified as self-healing.

Page 60 (71)

SOCRATES

D2.1

Cell Outage Prediction

eNodeB and UE measurements

Cell Outage Detection

O&M measurements Data analysis & correlation

Outage reports no

Outage ?

Results from outage prediction and detection

yes Cell Outage Compensation

Compensation Actions
Figure 10 Flow diagram of the cell outage management umbrella use case

4.1.1

Cell outage prediction

Self-healing Optimisation and maintenance

Description Classification: Area of relevance:

Based on different measurements the cell outage prediction can estimate which cell is a candidate for outage, when the outage is expected, the outage likelihood, as well as the scope and type. Consequently, the cell outage detection function is informed about this estimation for further processing of the trigger. In the following we describe the cell outage prediction use case in more detail. Objective Automatically and timely notify the network operator and the cell outage detection function about: The cell ID(s) for the cell(s) that are expected to experience outage The time interval when the outage is expected and what is the likelihood List of cells with their cell IDs that are affected by the possible cell outage The scope of the estimated outage i.e. the whole cell or only a limited set of RBs are not supported, the geographic area with low performing RBs (if possible), etc. Scheduling (Triggers) The prediction of the outage is a continuous process that correlates the relevant information in order to derive the prediction. However, if the prediction gives increased likelihood of cell outage then additional actions can be taken (e.g. increased measurement frequency and cooperation with cell-outage detection). At which outage likelihood level these additional actions are taken should be a threshold/parameter

Page 61 (71)

SOCRATES

D2.1

Input source The most important input sources are presented in the bulleted list below. eNodeB measurements (from the cell that is a candidate for outage or neighbour cells): o Hardware and software error reports, based on self-tests o Hardware (e.g. processing boards, RF circuits, etc) and software utilization reports o Temperature of, e.g., the site and hardware o Traffic measurements o Resource utilization measurements o other Known/scheduled outage events, e.g., hardware upgrades and software licenses, which could result in hardware or software failures. List of parameters Note that the cell outage prediction functionality does not aim at adjusting/optimising particular parameters in the network but rather timely indicate towards outage detection and compensation functions about the candidate cells for outage, corresponding likelihood, time interval of the outage, etc. On the other hand the parameters of the outage prediction function depend on the used prediction algorithm/methodology. For example, in Bayesian Networks, model parameters include discretisation thresholds, weighting, etc. It can be expected that the prediction algorithm in some way weighs the different inputs in a mapping function to derive the cell outage likelihood. These weights could be parameters, but even better, they could also be self-optimised based on automatic correlation analysis between inputs, the predicted outage likelihood and actually detected outage events. Actions The cell outage detection functionality and the network operator (to allow possible preparation for manual repair of the likely outage) are informed about the predicted cell outage with a corresponding report that consists of Cell ID(s), affected cells, likelihood, scope of the outage, type of the outage, etc. Expected results The network is reporting timely and accurately the location, scope and likelihood of the forthcoming cell outages, so that (i) appropriate actions can be taken in cooperation with the cell outage detection and compensation functions in order to smoothly resolve the outage situation; and (ii) the operators response time in manually repairing actual outages is reduced. Status in 3GPP Cell outage prediction has not been introduced in 3GPP yet. Measurements / parameters / interfaces to be standardised At the eNodeB side several measurements, e.g., traffic and resource utilization measurements should be standardized. See also Input source. It is for FFS if the hardware/software failure and utilization reports should be standardized. Architectural aspects The input for cell outage prediction is based on localized eNodeB measurements (from the cell in outage and its neighbours), O&M and UE measurements. The decision entity could be localized in a centralized domain because the inputs from various sources should be aggregated and analyzed. Example (Informative description) From the network different measurements are fed into the cell outage prediction entity (see section about the Input Sources). These measurements are collected from the cell that is candidate for outage, neighbour eNodeBs, and O&M. These measurements are then analyzed and correlated and then a soft outage decision is derived. If this soft outage decision is positive then the cell outage detection function is informed.

Page 62 (71)

SOCRATES

D2.1

eNodeB measurements

eNodeB measurement s

no

Cell outage detection

Data analysis & correlation

eNodeB measurement s Known/Planned eNodeB outages

Soft outage ?

yes

decision making entity

Figure 11 Flow diagram of the cell outage prediction Potential gain If the cell outage can be predicted then the preparation can be done on time i.e. both cell outage compensation measures and preparation for manual repairs can be triggered. This results in short time for compensating and actually repairing the cell outage and having an acceptable coverage with minimum periods of low network accessibility. Related use cases Cell outage detection (section 4.1.2) Cell outage compensation (section 4.1.3) References None

4.1.2

Cell outage detection

Self-healing Optimisation and maintenance

Description Classification: Area of relevance:

The output of cell outage prediction is forwarded to cell outage detection, where a decision to activate the cell outage compensation is taken. In the following we describe the cell outage detection use case in more detail. Objective Timely and automatically notify the network operator (it is for FFS to see how frequently and in which phase the operators should be notified about the outage) and the cell outage compensation functionality about: The cell ID(s) for the cell(s) in outage The scope of the outage i.e. the whole cell or only a limited set of RBs are not supported, the geographic area with low performing RBs (if possible), etc. The type of the outage i.e. hardware or software malfunctioning, radio or transport part, etc. A detection mechanism must work in a timely manner. An outage should be detected within appropriately short time interval (e.g. minutes). This affects where the detection functionality operates (at eNodeB, OSS, etc). Scheduling (Triggers) The detection mechanism is always on and is not triggered in a sense. However, the actions taken by the detection (e.g. reporting to the operator/compensation functionality) are triggered when a software/hardware errors occurs. Since errors due to software/hardware may be difficult to detect themselves (ideally a software unit reports errors, however, this may not be the case), triggers may also be based on observed abnormalities in eNodeB and RB performance.

Page 63 (71)

SOCRATES

D2.1

Input source The most important input sources are presented in the bulleted list below. UE measurements: o UE neighbour measurement reports such as e.g. Reference Symbol Received Power (RSRP) measurements with average values, statistical distributions, etc. o downlink interference reported by UEs eNodeB measurements (from the cell in outage or neighbour cells): o Hardware and software error reports o HO failure rate, i.e., the ratio of failed HOs over total number of HOs to a particular neighbour, o Cell performance indicators such as capacity (e.g. number of ongoing sessions), downlink/uplink throughput, etc. o radio link failure rate or number of call drops in the cell at a certain location area (or at a certain signal strength level, or at above a certain Timing advance value, or FFS) o uplink interference reported by eNodeBs o Timing Advance before call drops o Timing Advance at certain signal strength threshold o Relative load indicator (details on the definition of load indicator is FFS) List of parameters Similarly as in the cell outage prediction functionality the outage detection does not aim at adjusting/optimising particular parameters in the network. It aims at timely identifying the outage and correspondingly report to the cell outage compensation function. Actions The cell outage compensation functionality and the network operator are informed about the cell outage with a corresponding outage report (containing characteristics as described above under Objective). Expected results The network is reporting timely and accurately the location of the cell outage (ID of the cell in outage), affected neighbours, and the cell outage characteristics. These cell outage reports are used by the cell outage compensation function, which in turn restores the coverage as much as possible considering the outage type and the conditions of the neighbour cells. Status in 3GPP Cell outage detection has been implicitly introduced in the context of outage compensation. However, to the best of our knowledge there are no contributions explicitly on cell outage detection. Measurements / parameters / interfaces to be standardised The required UE measurements (see section Input source) can be obtained from already standardized measurements. At the eNodeB side several measurements should be standardized such as HO performance, drop call statistics, capacity and load measurements. It is for FFS whether the hardware/software failure reports should be standardized. Architectural aspects The input for cell outage detection is based on localized eNodeB measurements (from the cell in outage and its neighbours) and UE measurements. The decision entity could be localized in a centralized domain because the inputs from the cell in outage and surrounding cell (and the UEs served by these cells) should be aggregated and analyzed. Example (Informative description) Figure 12 shows an example of cell outage detection. A failure occurs resulting in no coverage in the area previously represented by Cell B. The cell outage detection function reports that Cell B is in outage and describes the scope and type of outage. It is a task for the cell outage detection to determine which neighbour cells are affected by this outage (e.g. Cell A and Cell C).

Page 64 (71)

SOCRATES Coverage Area Cell A Cell B Cell C

D2.1

Cell B in Outage
Affected Cell A Cell A Cell C Affected Cell C

Figure 12 Illustration of the cell outage event In Figure 13 the flow diagram for the cell outage detection is described in more detail. From the network different measurements are fed into the cell outage detection entity. These measurements are collected from e.g. the UEs, cell in outage, neighbour eNodeBs, and traffic measurements (see Input source). These measurements are analyzed and correlated and then a soft outage decision is derived. The input for the soft outage decision can also arrive, if possible, from the cell outage prediction functionality at early stage. It is for FFS how to coordinate the tasks between cell outage prediction and cell outage detection on basis of timing. For example, the outage prediction gives the candidate cell to experience outage in certain time interval and with certain likelihood while the cell outage detection is more immediate decision that cell outage is taking place. In case of positive soft outage decision the Node Element Manager (NEM) is polled in order to confirm the cell outage situation and to get more elaborated information about the scope/type of the outage. After considering the feedback from the NEM a final decision is made for cell outage and the cell outage compensation function is triggered. Note that if NEM is not reporting software/hardware problems the decision can still be that the cell is in outage based on abnormal eNodeB and RB performance. On the other hand, the hardware/software alarms from the NEM are directly transferred to the cell outage decision entity, as indicated with the bi-directional arrow in the flow-diagram. After the final decision on cell outage the cell outage compensation functionality is triggered in case of positive decision.

UE measurements & eNodeB measurements Data analysis & correlation

no

Cell outage prediction

UE measurements & eNodeB measurements

Soft outage?
yes

UE measurements & eNodeB measurements Cell outage detection NEM (Hardware & Software Alarms)

Traffic measurements from OMC

no

Cell outage?

yes

Cell outage compensation

decision making entity

Figure 13 Flow-diagram of the cell outage detection Potential gain If the cell outage is detected timely and accurately then the cell outage compensation measures can be triggered. The compensation measures can eventually result in satisfactory coverage (i.e. acceptable level of dropped and blocked calls) while the underlying hard/software problem can be repaired as soon as possible.

Page 65 (71)

SOCRATES Related use cases Cell outage prediction (section 4.1.1) Cell outage compensation (section 4.1.3) References None

D2.1

4.1.3

Cell outage compensation

Self-healing Optimisation and maintenance

Description Classification: Area of relevance:

The goal with cell outage compensation is to determine and set network parameters to mitigate cell outage. Objective The goal of outage compensation is to minimize the network performance degradation when a cell is in outage. This is done by automatic adjustment of network parameters in order to optimise coverage and performance, and meet operators deployment requirements based on coverage and KPIs (e.g., number of supported users, capacity, and data rates) to the largest possible extent. Automated reconfiguration as a result of cell outage serves at completely, or to the largest extent possible, alleviating and compensating outage in the area previously served by the missing or low performing cell. Note that there may be an upper limit for the degree of compensation that is actually possible. For example, assume that a hardware failure occurs at a cell resulting in a total shutdown of the eNodeB. In this case, some parts of the original cell can be covered by neighbouring cells, hence, we cannot compensate for the cell outage entirely. Necessary reconfigurations to minimize RB performance degradations must be done in a timely manner, e.g., proper actions to mitigate cell outage should be executed no later than a predefined deadline (after detecting the cell outage). Scheduling (Triggers) Cell outage compensation is triggered by a cell outage detection and/or prediction mechanism (see use case Cell Outage Detection and Cell Outage Prediction). The cell outage detection mechanism can be a human operator or a subsystem of the network. Input source The main input source for cell outage compensation is the output of cell outage detection. The following information should be provided: List of cells in outage List of cells to be reconfigured (consisting of the group of cells that are affected by the outage or can contribute to heal / reduce the impact of the outage) The scope of the outage i.e. the whole cell or only a limited set of RBs are not supported, the geographic area with low performing RBs (if possible) The type of the outage i.e. hardware or software malfunctioning, radio or transport part, etc. The outage compensation may also need to use measurements in order to compensate for the outage in an adequate way. The measurements could be for example: UE neighbour measurement reports (e.g., RSRP measurements), cell performance indicators (e.g., capacity), downlink interference reported by UEs and uplink interference reported by eNodeBs (to discover reasons for link drops or HO failure) List of parameters The following parameters may be adapted in all cells that are in the list of cells to be reconfigured: cell power antenna tilt HO parameters inter-RAT/frequency mobility parameters

Page 66 (71)

SOCRATES neighbour list tracking areas load balancing parameters

D2.1

Actions Upon the detection of cell outage, the network reacts to compensate the loss of performance in the respective area or cell. The procedure shall need no longer than a predefined deadline. The neighbours of a cell in outage could among other parameters adjust the following parameters to mitigate cell outage (see Figure 14): cell power antenna tilt HO parameters inter-RAT/frequency mobility parameters neighbour list tracking areas load balancing parameters idle mode camping Mobility to GERAN and UTRAN may be increased by altering, e.g., inter-RAT/frequency mobility parameters. An eNodeB may need to compensate outage for several neighbours, where for example the cells in outage may not be neighbours (the compensating cell is in the middle). In this case changes to the radio parameters of the base stations (e.g., tilt, power) might need to be coordinated among the base stations in the vicinity of the cell(s) in outage in order to handle issues such as capacity (in order to avoid one cell being overloaded when it aims at compensating for outages of several cells). In case that nothing can be done for compensating the outage, e.g., neighbouring cells are operating at their maximum power, the antenna tilt is at its minimum, or inter-RAT/frequency neighbours are overloaded and cannot admit incoming services, then the domain manager or the network manager must be informed. When the eNodeB failure has been removed an autonomous reconfiguration to the initial status shall take place.

Page 67 (71)

SOCRATES

D2.1

Cell outage detection

eNodeB and UE measurements

Cell Outage ?

no

yes O&M measurements Cell Outage Compensation

Report from cell outage compenstion

HO Optimisation

Load balancing

Coverage optimisation

...

Figure 14 Flow-diagram of the cell outage compensation Expected results The network is being reconfigured to minimize the loss of performance in an area in outage due to eNodeB failure. This implies that HO failure rate and radio link failure rate are decreased. Automatic coverage compensation procedure leads to the better network performance, coverage, and service quality. Status in 3GPP Cell outage compensation has been identified as a SON use case and some contributions have been discussed, see References for examples. Measurements / parameters / interfaces to be standardised A command from the network management level that initiates cell outage compensation. Architectural aspects The location of self-X functionalities depend on, e.g., timing requirements. Necessary reconfigurations to minimize service degradations must be done in a timely manner and as fast as possible to prevent unnecessarily loss of revenues. This means that cell outage compensation functions must be located at eNodeB or at domain manager (OSS) as the execution of such functionalities higher up would imply unnecessary long reaction times. Further, cell outage compensation affects and involves only the cell that is in outage and cells in the vicinity of that cell. As such, this functionality is best handled by the eNodeBs or the entity managing the eNodeBs (OSS) due to the locality of the problem. Example (Informative description) Figure 15 below shows an example of cell outage compensation. A failure occurs resulting in no coverage in the area previously represented by Cell B. Neighbouring cells (A and C) update their respective pilot powers and antenna tilts so that they can better serve the area originally covered by cell B.

Page 68 (71)

SOCRATES Coverage Area Cell A Cell B Cell C

D2.1

Cell Outage
Adjustment: - Pilot Power - Antenna tilt

Cell A

Cell C

Adjustment: - Pilot Power - Antenna tilt

Cell Outage Compensation

Cell A Cell C

Figure 15 Illustration of cell outage compensation Potential gain Using outage compensation more RBs can be supported in the cell in outage and the coverage of the RBs in the cell in outage is increased. KPIs, such as HO success ratio, capacity, and number of supported users are enhanced. Network accessibility and retainability are improved. Related use cases Cell outage detection (section 4.1.2) Cell outage prediction (section 4.1.1) Neighbour cell list (section 3.3.3) Tracking areas (section 3.4.2) References [1] R3-072179, New SON use-case: Self- Optimization for Coverage Compensation, ZTE, China Mobile [2] R3-072180, Self- Optimization for Coverage Compensation -Required Measurement and Signalling Support templates, ZTE, China Mobile

Page 69 (71)

SOCRATES

D2.1

Concluding remarks

In this document, use cases for self-organising networks have been defined, focusing on the 3GPP LTE radio interface. Although no real conclusions can be drawn yet from the use cases, some points are worth noting: A total of 24 use cases have been identified. These use cases cover many different aspects of the LTE radio interface. Significant advantages of employing SON functionality over current practice have clearly been pointed out, revealing significant potential for self-organisation in LTE networks. For some of the use cases, standardisation requirements are already being considered in 3GPP, but few decisions have been made. Other use cases have hardly or not at all been considered in 3GPP. The SOCRATES consortium seeks opportunities to contribute to 3GPP based on the latter group of use cases. For each of the use cases, a list of related use cases has been provided. For most use cases, there are several related use cases. This points at large interdependencies among the use cases.

Defining use cases is merely the first step towards developing solutions. The next step is to define requirements for the use cases, in Activity 2.2. In Activity 2.4, the interaction between the use cases will be studied in detail, and prioritisation and selection of use cases for WP3 and WP4 will be done. This will be followed by the development of solutions in WP3 (Self-optimisation) and WP4 (Self-configuration and self-healing). In these work packages, detailed algorithms will be developed. These algorithms will then be assessed using advanced simulators. From the above, it is clear that there will be many challenges for SOCRATES to develop solutions for these use cases. However, due to the broad expertise in the SOCRATES consortium, SOCRATES is well placed to address these challenges.

Page 70 (71)

SOCRATES

D2.1

References
In addition to the references included in the individual use case descriptions, this section includes some general 3GPP and NGMN references.

[1] 3GPP TR 36.902 V0.0.1 (2008-02), Evolved Universal Terrestrial Radio Access Network(EUTRAN); Self-configuration and self-optimizing network use cases and solutions (Release 8) [2] 3GPP TR 32.816 V1.3.2 (2008-02), Telecommunication management; Study on Management of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet Core (EPC) (Release 8) [3] 3GPP TS 36.300 V8.3.0 (2007-12), "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 8) [4] 3GPP S5-071944, Informative list of SON Use Cases, T-Mobile, Telecom Italia, Telefonica, Vodafone

Page 71 (71)