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: 31.03.08

Authors: 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

Reviewers: Hans van den Berg, Andreas Eisenbltter

Participants: VOD, TNO, ATE, EAB, IBBT, TUBS, NSN-PL, NSN-D

Workpackage: WP2 Use cases and framework

Estimated person months: 12

Security: PU

Nature: R

Version: 1.0

Total number of pages: 71

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 self-optimisation, 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 pre-operational 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 self-healing).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 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?

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 Stefan Thiel Phone: +44 1635 673964 Fax: +44 1635 676147 E-mail: Stefan.Thiel@vodafone.com TNO Remco Litjens Phone : +31 6 5191 6092 Fax: +31 15 285 7375 E-mail: remco.litjens@tno.nl Ljupco Jorguseski Phone: +31 6 5121 9560 Fax: +31 15 285 7370 E-mail: ljupco.jorguseski@tno.nl Renato Nascimento Phone: +31 6 5310 8732 Fax: +31 15 285 7370 E-mail: renato.nascimento@tno.nl EAB Ove Linnell Phone: +46 13 284136 Fax: +46 13 287567 E-mail: ove.linnell@ericsson.com Kristina Zetterberg Phone: +46 13 284854 Fax: +46 13 287567 E-mail: kristina.zetterberg@ericsson.com Mehdi Amirijoo Phone: +46 13 322290 Fax: +46 13 287567 E-mail: mehdi.amirijoo@ericsson.com IBBT Chris Blondia Phone: +32 (0)3 265.39.03 Fax: +32 (0)3 265.37.77. E-mail: chris.blondia@ua.ac.be Kathleen Spaey Phone: +32 (0)3 265.38.80 Fax: +32 (0)3 265.37.77. E-mail: kathleen.spaey@ua.ac.be Ingrid Moerman Phone: +32 (0) 9 33 14925 Fax: +32 (0) 9 33 14899 E-mail: ingrid.moerman@intec.UGent.be Irina Balan Phone: +32 (0) 9 33 14975 Fax: +32 (0) 9 33 14899 E-mail: irina.balan@intec.ugent.be

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

Page 5 (71)

SOCRATES D2.1

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

Page 6 (71)

SOCRATES D2.1

Table of Contents

1 Introduction ................................................................................................. 8 1.1 Self-organisation in future radio access networks ....................................................................... 8 1.2 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

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 self-healing, 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)

Self-optimisationSetting

parameters

Self-healing

Self-configuration

continuousloop

triggered by incidental

events

Measurements(Gathering and processing)

Self-optimisationSetting

parameters

Self-healing

Self-configuration

continuousloop

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 self-configuration, 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 self-healing, 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

2 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 Planning and deployment

2.1.1 Intelligently selecting site locations Description Classification: Self-optimisation (as input to self-configuration) Area of relevance: Deployment 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 (self-optimisation). 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 Description Classification: Self-configuration Area of relevance: Deployment 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 self-

configuration 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 Non-radio

2.2.1 Network authentication Description Classification: Self-configuration Area of relevance: Deployment 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 D2.1

Certificates (optional) 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 S5-

071944)

Page 18 (71)

SOCRATES D2.1

3 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 Radio network optimisation

3.1.1 Interference coordination Description Classification: Self-optimisation Area of relevance: Optimisation 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 re-use 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 D2.1

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

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 Description Classification: Self-optimisation (/Self-configuration) Area of relevance: Optimisation 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 D2.1

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

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 S5-

071944)

[2] 3GPP R2-081780, Measurements for Self-optimisation of DL Physical Channel Parameters

3.1.3 RACH optimisation Description Classification: Self-optimisation Area of relevance: Optimisation/Deployment

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 call-setup-, 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 D2.1

Status in 3GPP So far RACH optimisation has not been defined as a use case. 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 Description Classification: Self-optimisation, with some aspects of self-configuration Area of relevance: Radio parameter optimisation 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 D2.1

eNodeB should attempt to adjust the coverage area, by for example adjusting the cell power. 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 self-optimisation 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 D2.1

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

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 self-optimisation 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 Description Classification: Self-optimisation Area of relevance: Optimisation 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 self-optimisation 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 Description Classification: Self-optimisation Area of relevance: Optimisation 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 obje