You are on page 1of 71

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 Kürner, Andreas Hecker, Thomas Jansen, Jakub Oszmianski, Lars Christoph Schmelz Hans van den Berg, Andreas Eisenblätter 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)

de Phone: +49 531 391 2406 Fax: +49 531 391 5192 E-mail: hecker@ifn.ing.tu-bs.oszmianski@nsn.tu-bs.de Andreas Hecker Thomas Jansen NSN-PL Jakub Oszmianski Phone: +48 71 777 3280 Fax: +48 71 777 4610 E-mail: jakub.1 TUBS Thomas Kürner Phone: +49 531 391 2416 Fax: +49 531 391 5192 E-mail: kuerner@ifn.ing.de Phone: +49 (0)531 391 2486 Fax: +49 (0)531 391 5192 E-mail: jansen@ifn.com Page 4 (71) .schmelz@nsn.SOCRATES D2.tu-bs.ing.com NSN-D Lars Christoph Schmelz Phone: +49 89 636-79585 Fax: +49 89 636-75147 E-mail: lars.

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.SOCRATES D2. 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) . Administration.

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) .

................................2 Automatic generation of default parameters for NE insertion .....................1 Cell outage management ......................................................................1..................................3...................................2 Cell outage detection................................................. 17 3 Self-optimisation use cases...................1 Radio network optimisation........ 8 Use cases for self-organisation ............................................................ 19 3..5 Coverage hole detection..............................................................1 Interference coordination .................................................................................... 54 3......................................................3 TDD UL/DL switching point ................. 61 4...........................................................................2...........................................1 Reduction of energy consumption................ 8 1..........................1.................................... 26 3......................2..............2 Hardware/capacity extension ............................................................................................ 15 2.....1 Intelligently selecting site locations ...2 Self-optimisation of physical channels .............................................. 66 5 Concluding remarks .......................1 Planning and deployment ....... 19 3........3...................................................................................................1 1.................................................................................................................. 29 3............................................................................................. 46 3........1..........................................SOCRATES D2.................................................4... 49 3...........1..........................2 Tracking areas ................. 40 3.....................................................................................................................................................4........ 46 3...........2........................... 59 4 Self-healing use cases..............................................................3 Handover related optimisation.................................... 63 4..2.3 RACH optimisation.....2 Load balancing.................................................................................................................4........................................................................... 23 3...................................................... 46 3..........................................................1.....2 Non-radio.................... 70 Page 7 (71) .................................................4 Other....................................................................................................... 42 3............................................................ 31 3.....................................................4 Link level retransmission scheme optimisation ........................................2...................................................... 29 3............................. 13 2.......3 Packet scheduling parameter optimisation ...1........2 Congestion control parameter optimisation ........................ 38 3.........3 Neighbour cell list...................................1 Admission control parameter optimisation .............................2 GoS/QoS related parameter optimisation .....................................4..............................4 Self-optimisation of home eNodeB..................................1 Cell outage prediction .......................2.3.. 11 2........................................ 57 3....................................................................................1 Table of Contents 1 Introduction ......................1 Handover parameter optimisation ..................4 Management of relays and repeaters..................................................... 9 2 Self-configuration use cases .................. 19 3......4...................................................................1...............1. 15 2....................5 Spectrum sharing................................................................................................. 33 3................................................... 11 2....2 Self-organisation in future radio access networks ............................................................................................................................... 60 4..................................................................... 35 3............... 21 3............... 11 2..1...............................3 Cell outage compensation .......2....................................................1 Network authentication ................. 40 3............... 60 4.................

self-configuration and selfhealing. while optimising network efficiency and service quality. both in terms of operational complexity and network costs. These raw Page 8 (71) . 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. 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. Long Term Evolution) radio interface is the central radio technology in SOCRATES studies. somewhat arbitrarily. configuration and optimisation into a single. This is because 3GPP LTE is the natural. mostly automated process requiring minimal manual intervention. This phase indicates a continuous activity where a multitude of measurements are collected via various sources. is to effectuate substantial operational expenditure (OPEX) reductions by diminishing human involvement in network operational tasks. SOCRATES primarily concentrates on wireless access networks. UMTS/HSPA). The principal objective of introducing self-organisation. including network counters and probes. highly promising and widely supported evolution of the world’s most popular cellular networking technologies (GSM/EDGE. by integrating network planning. as the wireless segment generally forms the bottleneck in end-to-end communications.1 1 Introduction Future communication networks will benefit from a significant degree of self-organisation. The 3GPP LTE (3rd Generation Partnership Project. Consider a fully configured and operational radio access network and. As a consequence. 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.SOCRATES D2. comprising self-optimisation. start at the depicted ‘measurements’ phase. the largest gains from self-organisation can be anticipated here.

The area of relevance (planning. In case the self-optimisation methods are incapable of meeting the performance objectives.e.2 Use cases for self-organisation Before solutions for self-organising networks are developed. These upgrades generally require an initial (re)configuration of a number of radio parameters or resource management algorithms. • 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. e. A use case may also be triggered by a particular event. Examples are the addition of a new site and the introduction of a new service or new network feature. an overview will be given of the status in 3GPP.e. deployment. In the ‘self-optimisation’ phase. power settings. For each use case. such as the failure of a cell or site. to the extent possible. 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. use cases will be defined. pilot powers and neighbour lists.1 measurements of e. i.g. • Scheduling (Triggers): This will describe how often the functionality described by the use case is triggered. e. The description will also include the classification into selfconfiguration. are processed in order to provide relevant information for the various related self-optimisation tasks.SOCRATES D2. what problem(s) does it solve. is triggered by ‘incidental events’ of an ‘intentional nature’. These have to be set prior to operations and before they can be optimised as part of the continuous self-optimisation process. including e. i. The solution will use the input information.g. in terms of a recommended location for a new site. neighbour lists and a range of radio resource management parameters. and decisions can be made on which of them will be addressed first in WP3 and WP4. A use case provides a description of a functionality to be made self-organising and points out what the solution should achieve. for example. The ‘self-configuration’ phase. • Objective: This item describes what the use case aims to achieve. • Status in 3GPP: As SON use cases are being considered in 3GPP standards. it is essential to have a clear common view on the situation and particular problems to be solved. • Input source: A description is provided on which input information is required for the use case. depicted as an external arm reaching into the continuous self-optimisation cycle. self-optimisation or self healing (or a combination of these). for example.g. ‘Self-healing’ methods aim to resolve. whether it is periodical or continuous. optimisation. antenna tilts. accuracy and periodicity of the delivered information depend on the specific mechanism that is to be self-optimised. or what optimisation(s) does it provide. Page 9 (71) . traffic and user mobility aspects. all parameters are restored to their original settings. maintenance) will also be included. the processed measurements are used to derive an updated set of radio parameters. 1. what will have improved. For this purpose. capacity expansion is indispensable and timely triggers with accompanying suggestions for human intervention are delivered. 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. also providing some background information. The required format. and process it to determine appropriate parameter settings • List of parameters: These are the parameters that will be adjusted by the self-organisation solution. the following items are addressed: • Description: A general description of what the use case is about. the loss of coverage/capacity triggered by ‘incidental events’ of a ‘non-intentional nature’.g. This is done by adjusting the parameters and algorithms in surrounding cells. radio channel characteristics. Once the actual failure has been repaired.

Particularly focus is on whether a distributed or centralised solution is preferred. rather than detailed study. ‘Handover related optimisation’ and ‘Other’.4. That decision. Inclusion in this document of a use case does not necessarily indicate that SOCRATES will work on that use case. Example (Informative description): A specific example is given of a scenario where the use case can be applied. several use cases are included which have until now not been considered by 3GPP and NGMN. For self-optimisation. there is just one subcategory: ‘Cell outage management’. in line with the process described in Figure 1: • Self-configuration (Chapter 2) • Self-optimisation (Chapter 3) • Self-healing (Chapter 4) For self-configuration. The gain described in this section will be just an initial estimate. requirements for standardisation in 3GPP will be listed Architectural aspects: This will define the network architecture this is required. In describing the use cases. for most use cases this document provides significantly more detail than was available from these sources. This deals with situations related to hardware or software failure at the eNodeB. these three types are closely related to each other. 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. However. These use cases focus on enabling a new eNodeB to be activated with minimal manual interaction required. the use cases are clustered in the subcategories ‘Radio network optimisation’. Related use cases: A list of related use cases References: Particularly 3GPP/NGMN documents. Where appropriate. In addition. For selfhealing. The feasibility of implementing a solution will also be taken into account.1 • • • • • • Measurements / parameters / interfaces to be standardised: Based on the above items. Page 10 (71) . Potential gain: The gain from the use case is estimated.SOCRATES D2. 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. but also other references. These use cases aim to maximise the efficiency with which the network resources are used. based on technical expertise. references to 3GPP and NGMN documents have been provided. The three main types of gain are: o OPEX and/or CAPEX reduction o Capacity and coverage improvement o QoS improvement Of course. There are different types of gain that can result from the use cases. to be made as part of Activity 2. ‘GoS/QoS related parameter optimisation’. we distinguish two subcategories of use cases: ‘Planning and deployment’ and ‘Non-radio’. input was taken from 3GPP and NGMN.

self-configuration has been split into two subcategories: ‘Planning and deployment’ (section 2.4) • Tracking areas (section 3. We are also considering the following related use cases. thereby using available geographical information or potential antenna locations. which contain elements of self-configuration.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. which could e. a proposal for a new location is calculated. 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.1) and ‘Non-radio’ (section 2. but are listed elsewhere in this document. 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.SOCRATES D2. antenna orientation).g. neighbour relationships.2). • Self-optimisation of physical channels (section 3.1 2 Self-configuration use cases The ‘self-configuration’ phase is generally seen as the first step within self-organisation. Objective The main objectives for this use case are: • Detect and identify performance degradations and coverage holes during operation (near real time). transmission power. For the latter two solutions. few times per week for some minutes only.g. 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.2) 2. Page 11 (71) . handover failures etc. call drops.4. 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. 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. For example. a solution to overcome the identified shortcomings is generated.g.1.1 2. as it is the first occasion the system may adapt its set-up or parameters with regards to external influences.2) • Self-optimisation of home eNodeB (section 3. 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. Within this document. cell size. e.1. The attainment of pre-defined or self-learned threshold values triggers the solution phase.) • Solution phase: by using information about existing infrastructure (installed NE types. otherwise the detection phase cannot work.1.

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

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. While for some of these parameters it is not useful to provide default parameters.SOCRATES D2.g.1. For the introduction of a new NE. 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. which shall be avoided in future due to its high expenses and necessary modifications on site. corresponding real-time capable interfaces and data management systems at NE and OAM side may be required. increasing customer satisfaction. etc. The final network element (NE) and site-specific values then have to be assigned either manually or by automated configuration or self-optimisation mechanisms. the NE is delivered to the site completely without configuration.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.2) 2. e. manually on-site or in the factory): this approach actually describes today’s situation. rules / policy-based. including radio settings. self-learning algorithms. provide the network element with some standard or best-practice values before it is introduced in the network.to long term analysis.2) • GoS/QoS related parameter optimisation (section 3. • A database that stores measurement results for a mid. specific values are determined after initial boot: this approach could e.g.g. Hybrid solutions between these three approaches could also be applied.) 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. 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. since the likelihood that they will have Page 13 (71) .g. specific configuration is determined and installed after initial boot: with this approach. reflecting an evolution from necessary manual intervention towards fully automatic introduction: • Pre-configuration of network elements (e. • No pre-configuration of network elements. except for some standard software for initial NE start-up. and to find appropriate solutions OPEX reduction. for transfer of performance data) – the Itf-N is the major standardisation topic of 3GPP SA5 (OAM) • 3G LTE X2 interface (between eNodeBs) – e.3. • Pre-configuration of network elements with some default values. The complete software and configuration is assigned during the self-configuration procedure. • Reduction of necessary manual effort (performance management) to identify coverage leaks and performance degradations.g. several different types of parameters are to be assigned. neighbourhood configuration etc. Related use cases • Load balancing (section 3.

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

IP and Internet technologies and mechanisms are used.1.1.3.2. another potential risk appears for the operators. the stated changes open up a large set of potential leaks for intrusion into the network.4) • Handover related o Handover parameter optimisation (section 3. or the introduction of bogus nodes. The insertion can therefore be completed more quickly and reduces the necessary time efforts and thereby OPEX.2) o RACH optimisation (section 3.2) o Packet scheduling parameter optimisation (section 3. since the self-optimisation of the radio parameters does not have to start at zero but already at a default configuration. routing.1) o Self-optimisation of physical channels (section 3. security) • the introduction of new technologies at the link layer (e. e. for data theft.1) o Load balancing (section 3.1. 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.g.2.2.3.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. Potential gain For the insertion of a new NE. since these base stations are no longer under their physical control. for the communication between all network endpoints. including transport. 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 today’s 2G and 3G networks. including the corresponding OAM: • the migration of the network and transport infrastructure towards all-IP (i.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.3) o Link level retransmission scheme optimisation (section 3.1) o Congestion control parameter optimisation (section 3.2 2. With the introduction of home base stations. the availability of default parameters can accelerate the self-configuration process significantly.e. DoS attacks.2.2) 2.3) • GoS/QoS related parameter optimisation o Admission control parameter optimisation (section 3. Page 15 (71) .g.2.SOCRATES D2.

after node insertion or re-location. node location etc.) • Network ID (to be defined. A detailed analysis of the potential threats of the stated changes in network technology and architecture is necessary to develop an overall solution. in case of network re-configuration or for the purpose of SW or HW updates. However.) • Network database that contains node information Actions At this stage. be a unique identifier or a certificate) List of parameters Parameters that may be modified by network and node identification are: • Node address (e. or in case of home eNodeB always after switching on. However. a certificate etc. a location-based identifier. to prevent from the misuse of home BS’s for intrusion into the network. the following information may be used: • Node ID (to be defined.1 With this background.g. Input source As input data for network and node identification.g. some basic actions can be described already now: Network side: • After connecting the node to the network.g. In some cases it might also be necessary to perform network authentication also during operational phase. Measurements / parameters to be standardised • Node identifier • Network identifier Page 16 (71) . 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.g. e.g. The triggers for network and node authentication may be operator-specific. 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. could e. but the sub-use-cases should be generally defined. unique identifier. e. depending on the corresponding network architecture and security framework and requirements. a unique identifier.SOCRATES D2.g. could be a HW ID. and to make sure the node is connected to the right network. such that its identity is settled for other self-optimisation tasks and use cases. it is not possible to specify detailed actions since there has been no agreement about the required level of security up to now. e. it might be useful to define different procedures for different levels of security. self-configuration especially for the deployment of new network elements require mechanisms for the mutual authentication of node and 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. IP address) • Certificates • Node identifiers (e.

Most probably the same process will be used as for the X2 interface.and radio network-specific configuration can be applied. 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). A description of this use case can be found in [1]. but is a mandatory requirement for future network generations.1 Architectural aspects To establish an authentication infrastructure several levels are possible: • A simple DHCP-like infrastructure with MAC address filtering. Already standardised interfaces Node and network authentication is performed at least between the node and the responsible OAM system. This is recognised as a good use case. for the purpose of node authentication.g. gateways. to guarantee the robustness of the network against attacks. Potential gain Network authentication does not provide a gain w. Firstly. e. requiring pre-configuration of DHCP server • A DHCP infrastructure with validation at DHCP server side.g. the node has to be authenticated towards the network.t. with certificate authorities etc. but it is considered to be outside the scope of the SOCRATES project.g. The interface between node and OAM system is not standardised. Currently. the implementation may have impact on the overall performance of the network. e. through node database matching or comparison of location data • An authentication infrastructure e. but may also be performed between node and neighbouring nodes (e. e. i. a trusted connection between eNodeB and the operator’s OAM network can be established. The interface between 3G LTE eNodeBs is standardised (X2-IF).g. network performance. Page 17 (71) . Example (Informative description) Examples are the first steps of the self-configuration of a new macro eNodeB. However. If this has been accomplished successfully. Given that the new eNodeB does not have an appropriate SW load and basic configuration installed.. the actual interface setup and authentication procedure is not fixed yet.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.g. Related use cases None 2. in case of IPSec or other encryption technologies being used.SOCRATES • Certificates (optional) D2. currently there is a mutual authentication foreseen during the X2 interface setup.2. This may be complicated in the case that the site is not directly connected to the operator’s OAM network but to the network of a 3rd party operator that can not carry out the authentication. Therefore. other base station.e. and controllers).r. this has to be downloaded and installed before the site. a temporary virtual connection with the operator’s OAM network has to be established. base stations have to be switched off and various manual configurations are required before the base station can be re-activated. to download the required SW load and necessary basic configuration. 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.

Informative List of SON Use Cases.53. section 5. v 1.2 (included in 3GPP S5071944) Page 18 (71) .SOCRATES D2.1 References [1] NGMN Project 12.

SOCRATES D2.1). and then a reactive algorithm will be necessary.1 3. As LTE systems employ OFDM. Events that can trigger a reactive algorithm are: • Dropped calls • Low QoS Page 19 (71) . on 3GPP forum it is believed that this alone is not sufficient. Pro-active algorithms will monitor interference levels. Assuming that LTE will use a frequency reuse of one.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. However. Inter-cell interference does. Potentially it will be necessary to have both pro-active and reactive algorithms. All the use cases share the aim to improve on key performance indicators and to use the available network resources more efficiently. The use cases provide a framework for adjusting network and equipment parameters on the basis of network measurements. however. at the expense of users closer to the eNB.2). in some cases the pro-active algorithm may not sufficiently avoid problems. ‘Handover related optimisation’ (section 3. • Consider QoS requirements of users when managing interference: for example. This use case considers mainly macro/micro deployments. 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. Efficient management of interference can increase the efficiency of the system and improve the quality-of-service (QoS). intra-cell interference between users is not an issue. and further gains can be achieved by using SON techniques to further improve performance. Self-optimisation use cases cover ‘Radio network optimisation’ (section 3. 3. Interference issues for femto-cells are considered in a separate use case. Features such as frequency-selective scheduling shall schedule on resource blocks with low interference. ‘GoS/QoS related parameter optimisation’ (section 3. • Consider both uplink and downlink Scheduling (Triggers) It is expected that interference control will operate based on continual monitoring of the network.1. therefore.4) important use cases. 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.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. and will take action before problems start to occur. interference will be high at the cell edge for loaded cells. but in practice it may not be efficient to give high throughput to cell edge users. This can potentially lead to low throughput and unsatisfactory QoS for users at the cell edge. However. clearly influence performance. It is necessary to find the right trade-off.3) and ‘Other’ (section 3.

Input source As input data to an interference control algorithm. are considered to be SON. while maintaining spectral efficiency • Higher user satisfaction (lower delays. Measurements / parameters / interfaces to be standardised To support the interference control use case. packet loss) • Estimation of user location (close to cell edge or not) • Measurement of interference levels. The focus so far has been on the uplink (3GPP R1-075050. However. the following standardised measurements are required: • QoS measurements. delay. algorithms that intelligently manage interference.g. where indicators referred to as High Interference Indicator and Overload Indicator are being considered. However. QoS and load/interference status from neighbour cells Detect problems (e. Summary of companies’ positions can be found in 3GPP R1 081048. Other contributions (3GPP R1-072974) see no gain from doing this. Another method is presented in 3GPP R1-074984. 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. jitters for real time traffic) Status in 3GPP For a distributed solution. 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. the X2 interface will be used. Functionality that works on a timescale of less than seconds is generally considered to be RRM. a possible process is: • • • Monitor interference levels. using a high level description. delay. and implement specific policies. the following information may be used: • User QoS (throughput. Work is already ongoing in 3GPP to define signalling over this interface. QoS degradation) Take action to deal with problem. but no decisions have been made yet. Current status is described in 3GPP R1 081048. per resource block Page 20 (71) . High Interference Indicator has been agreed during meeting in Sorrento. R1-074851).1 It is worth noting that Interference Control can be considered both a SON and an RRM (Radio Resource Management) functionality. it is not possible to specify detailed actions. some 3GPP contributions (3GPP R1-074641) support the use of an indicator on the downlink. to be used to control transmit power. both in uplink and downlink.SOCRATES D2. as no algorithms have been defined yet. per user (throughput. Overload Indicator is still discussed. For the downlink. high interference levels. 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.

Potential gain LTE is already designed to handle interference.2) References [1] 3GPP R1-075050. “Summary of email discussion on UL and DL ICIC” 3. the gain in overall cell capacity is unlikely to be significant.1. The most important aspect here is user experience. it will be possible to reduce this interference. Page 21 (71) . In fact.3. that would be considered a significant gain. “Discussion on the DL Interference Coordination” [5] 3GPP R1-072974. In addition. By adjusting network parameters.SOCRATES • RSRP (Reference Signal Received Power) – and (new) triggers for reporting to ICIC functionalities D2. In addition. the physical channel parameters will be stored in the eNodeB.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 other parameters. Although uplink parameters are used by the UE. many uplink parameters will be signalled to the UE from the eNodeB. Related use cases • QoS related parameter optimisation (section 3.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). However. This implies a distributed solution. For the downlink. resulting in bad interference conditions. cell capacity may even be reduced. If users can experience a high bitrate / lower delays independent of where they are (relative to the eNodeB). “On Inter-cell Interference Coordination Schemes without/with Traffic Load Indication” [7] 3GPP R1 081048. and other situations should be considered as well. there will be areas of strong overlap between cells. and a SON solution will be necessary.2) • Self-optimisation of home eNodeB (section 3.1. “Uplink inter-cell interference coordination” [3] 3GPP R1-074984. Example (Informative description) For simulations. As a result of this. and can therefore also be determined by self-optimising functionality in the eNodeB. there may still be situations where the interference management is not adequate. irregular cell locations are common. “Way forward on UL ICIC Overload Indicator for LTE” [2] 3GPP R1-074851. However. However. For many parameters default settings will be sufficient. and it is beneficial to use self-optimisation to automatically find good values for these parameters. propagation conditions will result in irregular coverage areas. The above is just one example of a situation where interference control will be useful. “Downlink Interference Coordination” [6] 3GPP R1-074444. it may be useful to also have a centralised SON function that manages the interaction between different cells. hexagonal cell layouts are often used.4) • Load balancing (section 3. In a real network. the default settings may result in unsatisfactory performance. “Semi-Static Interference Coordination Method” [4] 3GPP R1-074641.

Scheduling (Triggers) This use case will be triggered by the installation of a new base station. SCH • Control Channel o Physical Control Format Indicator Channel. • Traffic forecasts • eNodeB location • eNodeB hardware configuration o Antenna height. with the objective of avoiding signalling errors and failed calls. and therefore also has an element of self-configuration. Page 22 (71) . PRACH Exactly which parameters for these channels can be set using self-organising functionality requires further study. • Good cell performance. PBCH The uplink channels are: • Physical Signals o Reference Signal. PHICH • Data Channel o Physical Downlink Shared Channel. PUSCH o Physical Random Access Channel. PUCCH • Data Channel o Physical Uplink Shared Channel. 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. • Obtain information about neighbouring eNodeBs. it will be triggered by the installation of a new base station. Whether this information is useful may depend on whether the neighbouring eNodeBs are deployed in a similar environment as the new eNodeB. PCFICH o Physical Downlink Control Channel. PDCCH o Physical Hybrid ARQ Indicator Channel.1 Although this use case focuses on self-optimisation. Input source • Information on configuration of physical channels for neighbouring cells. 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. RS o Random Access Preamble • Control Channel o Physical Uplink Control Channel. RS o Synchronisation Signal. 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.SOCRATES D2. PMCH o Physical Broadcast Channel. PDSCH o Physical Multicast Channel.

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

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

The GoS level should benefit in these situations. The access attempt of UE 2 is blocked after the third try. Figure 2: Flow diagram of access to RACH Potential gain If the traffic load of a cell is high the blocked access attempts increase.3. 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. Example (Informative description) Figure 2 shows the process of UE’s trying to access the RACH. The number of blocked access attempts should be as low as possible.1 Measurements / parameters / interfaces to be standardised It will be necessary to obtain information about the actual performance of the RACH. D2.2) • Cell Outage Compensation (section 4. “eNB Measurements – M5: number of received RACH preambles” Page 25 (71) .SOCRATES Status in 3GPP So far RACH optimisation has not been defined as a use case.3.3 ) • Handover Parameter Optimisation (section 3.2) • Load Balancing (section 3. NTT DoCoMo. Related use cases • Tracking Area Optimisation (section 3.1.4.1) References [1] R2-074122. 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 eNB’s it would make sense to implement the RACH optimisation algorithms in the eNB’s. 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.

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

• 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. 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.e. Upon the detection of a coverage area not corresponding to the users’ movement statistics. 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. Radio parameters are set to an initial configuration. such as o failed handover ratio o uplink interference o ratio of dropped calls • measurements performed by UEs.SOCRATES D2. for example the occurrence of dropped calls. and once sufficient information is collected. such as o interference measurements Since a home eNodeB is probable to have only a few users. This would however require the home eNodeB to have the ability to measure on the same frequency band as is used for transmission. operator specific settings) • measurements performed by the home eNodeB. The collection of statistics to optimize the coverage area is started. the home Page 27 (71) . neighbour detection is triggered to detect neighbouring eNodeBs. the following triggers are used: • Neighbour list optimization is triggered upon indications of missing or inappropriate neighbours. with minimal customer intervention • detect neighbouring eNodeBs. the home eNodeB should add or remove the neighbour from the neighbour relation list. the radio parameters are updated. the home eNodeB should attempt to remove or minimize the hole by for example increasing the cell power. 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. During operation.1 Objective A home eNodeB should automatically. 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. Upon the detection of a coverage hole.

Upon changes in signal strength/interference the home eNodeB should perform appropriate handover. D2. 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.SOCRATES eNodeB should attempt to adjust the coverage area.1 ) Page 28 (71) . The home eNodeB then downloads the latest software and performs a self-test to make sure the installation succeeded.3) • Interference coordination (section 3. 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.3. 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]. the home eNodeB should immediately register to the network on start-up. The OSS can then for example automatically initiate software updates. • The home eNodeB will dynamically update the neighbour relation list and therefore provide seamless handover to and from other eNodeBs. by for example adjusting the cell power. The home eNodeB should take steps to reduce potential interference issues with the macro connected UE. For example the handover parameters required for selfoptimisation as listed in the HO use case are similar to those required for home eNodeB handovers. Potential gain Operators will not need to perform any configuration from the geographical spot where the home eNodeB is located. 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. When a UE enters the home eNodeB coverage area it will connect to the home eNodeB. If the UE leaves the home eNodeB coverage area while connected to the home eNodeB. are covering small areas and may be switched on and off arbitrary. resulting in a submission to 3GPP[3]. When a UE enters a closed access home eNodeB coverage area and is denied access to the home eNodeB. The customer can then start to use the home eNodeB. as much as possible of the self-configuration and self-optimisation should be performed in the home eNodeBs. the connection will be handed over to a neighbouring eNodeB. Therefore. the UE will remain connected to the macro eNodeB. When the home eNodeB is switched on it immediately connects to the network and is authenticated. Project Monotas[2] studied differences in interference aspects of open and closed access home eNodeBs. Architectural aspects Since the home eNodeBs in a network can be numerous. Management of the node must however be possible from the OSS. • 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. Example (description) A customer buys a home eNodeB and plugs it in to a fixed Internet line in her house. Related use cases • Neighbour list optimisation (section 3.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. Expected results • The home eNodeB will get up and running with an appropriate configuration without the need of customer intervention. The home eNodeB will respond to changes in the environment automatically and potentially negative influences to the mobile operator’s macro network (and UEs connected to macro eNodeBs) will be reduced.1. even though the actions a specific home eNodeB takes might be different to those of a macro eNodeB.

the packet scheduler to meet the QoS requirements of the admitted calls with sufficient likelihood. quality and coverage. value.2. Although strong (potentially conflicting) relations exist between these mechanisms in the way they influence the GoS versus QoS trade-off. 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. signal propagation effects and the impact of the varying load in neighbouring cells. the carried traffic load. desired QoS of the newly requested and on-going calls.2. resource usage indicators.5) D2. all handover related use cases are discussed in Section 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). 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. congestion control. Page 29 (71) .SOCRATES • • Handover parameter optimisation (section 3. indicator.1) Coverage hole detection (section 3.g. while QoS refers to performance metrics associated with the quality of the services calls in terms of e.com/monotas/ [3] 3GPP R4-071231: Open and closed access for Home Node Bs 3.3. handover control. set of parameters.e. user mobility. The admission control mechanism is proactive. Among the diverse radio resource management mechanisms that fall under this umbrella.macltd. Load per cell. the decision entity has to identify the cause/possible causes and trigger the appropriate mechanism in order to resolve the problem.g.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. Whenever one or more of the monitored parameters falls under a reference value. we consider admission control.53 (included in 3GPP S5-071944) [2] Monotas. GoS refers to performance metrics associated with call accessibility (call blocking) and retainability (call dropping). in the sense that it aims to prevent undesired QoS degradation and fulfils a key role in the trade-off between capacity. packet scheduling and link level retransmission scheme optimisation. As already mentioned the use case ‘Handover parameter optimisation’ is a related use case and could be included in this section. etc). frame error rate. etc.1 References [1] NGMN Project 12. we will define separate use cases to address the self-optimisation of these mechanisms. 3.3. v 1. in light of the uncontrollable uncertainties due to e.g. there should be some kind of common way to estimate/define/measure GoS and QoS (i. Informative List of SON Use Cases. However. http://www. In the applied terminology. Such parameters may include: Handover failure rates. In particular. delay (variation) and throughput. QoS could be estimated by a set of parameters that are constantly monitored by the eNB/decision entity. Call blocking/drop rates. based on the actual capacity.

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

Potential gain Considering previously reported results on auto-tuning of admission control parameters in UMTS networks.2. [5] P. As the likelihood of congestion due to uncontrollable effects is small.Senouci. It further relates to the ‘Load balancing’ (section 3. traffic or propagation effects. detect when overload situations are encountered. Page 31 (71) . “Evaluation of advanced radio resource management”. congestion control is of a reactive nature. the potential gain in terms of capacity/quality enhancement is expected to be high.3. [4] M.2.1 Example (Informative description) Consider a cell with little user mobility. [2] Gandalf project.3. evaluate the degree and urgency of the overload conditions. “Call admission control in cellular networks: a reinforcement learning solution”. 2007 (included in 3GPP S5-071944). References [1] NGMN. “Online automated tuning of RRM parameters of UMTS networks: uplink load factor threshold”. however. aiming to resolve congestion.816 V1.g. It is the objective of the congestion control mechanism to monitor the network load.2). [3] Gandalf project.3). [6] S. the reduction of transfer rates and/or transmit power and (generally as a final resort) controlled call dropping. Related use cases As discussed above. 2007.SOCRATES D2.1 (2007-11) – Use case 8: QoS related radio parameter optimization. “Informative list of SON use cases”. Pujolle. d’Orey and Á. intolerable interference levels or unacceptable packet delays. 2008.3.-L. Hence in contrast to admission control. over time the degree of user mobility increases. and take appropriate counter measures in order to get the system quickly but in a controlled fashion back to a feasible load situation. A.-M. while feasibility is good. Deliverable D4. Gomes.3. [8] 3GPP R3-070118. vol. 2007. ‘Congestion control parameter optimisation’ (section 3. Proceedings of Conftele ’07. If. Peniche. “QoS Design Principles” [9] 3GPP R2-080444. This use case will contribute to ensuring that users are not unnecessarily given a reduced GoS/QoS. Ruiz-Boque. 2006. International Journal of Network Management. “Study on the automated tuning of HSDPA Code Allocation”. 2004. a small admission control margin will suffice. Portugal. 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. Typical counter measures include the rejection of all new call requests.2.2) use case.M. Beylot and G. COST 2100 TD(08) 410.2 Congestion control parameter optimisation Self-optimisation Optimisation Description Classification: Area of relevance: As a consequence of largely uncontrollable effects such as user mobility. 14. even if admission control aims at preventing such situations. 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). [7] 3GPP TR32. 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. overload situations can occur in the sense of e.1). “Advanced mobility and traffic management algorithms”. “eNB measurements for RAN performance monitoring” 3. use case on ‘QoS related parameter optimisation’. Garcia-Lozano and S. 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. ‘Handover parameter optimisation’ (section 3. Deliverable D4.2.

g. and where possible SOCRATES should contribute to ensure that the necessary counters for this use case are standardised. 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. 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.g.g. target load level. prioritisation of different service types. step size of load reduction. inferior service quality in terms of BLER. The associated self-optimisation scheme may be characterised by e. similarly. user mobility. e. Some activities in 3GPP related to performance monitoring are already ongoing .g. but not too early. And all of this in light of the uncontrollable uncertainties due to e. some maximum allowed imbalance in the observed time fraction the network is deemed congested and the degree of congestion-induced service quality degradation. see [3]. the maximum allowed degree of congestion-induced service quality degradation before the self-optimisation algorithm should modify the congestion control algorithm. delay or packet loss. throughput. as needed for issue (i) above).SOCRATES D2. These activities should be monitored.for an example. signal propagation effects and the impact of the varying load in neighbouring cells.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. time windows) and congestion resolution (e. Status in 3GPP Although the QoS related optimisation use case is mentioned in one 3GPP document [2]. Scheduling (triggers) Based on continuous monitoring of experienced service quality (we still have to figure out how that will be monitored) and resource efficiency. Actions Actions taken by the self-optimisation algorithm are the adjustment of the congestion control parameters. in which case congestion control is not activated enough. and (ii) the observed congestion-induced service quality degradation is high. related to both congestion detection (e. step sizes.g. 1 Note that this is something else than congestion control-induced service quality degradation. 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. downlink transmission power. based on uplink noise rise. Page 32 (71) . 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).g. it is has not really been considered yet in 3GPP. and (ii) parameters associated with the congestion resolution phase. Congestion control actions are taken timely. 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. and. thresholds. shared channel utilisation. List of parameters As was the case for the description of the admission control use case. e. load target level).

although this is currently still at a very early stage.2. Page 33 (71) . interactive and background services greatly complicate this. Related use cases As discussed above. use case on ‘QoS related parameter optimisation’. It further relates to the ‘Load balancing’ (section 3. In OFDMA-based LTE systems. References [1] NGMN. “Informative list of SON use cases”.816 V1.1). while satisfying the different flows’ QoS requirements and. the congestion control threshold needs to be decreased so that the likelihood of ‘disastrous’ peaks in resource usage remains at the set tolerable level. The distinct traffic characteristics and QoS requirements of conversational. but discounted for the typical rarity of overload situations. we foresee a distributed implementation of the associated self-optimisation algorithm. throughputs) for a given acceptable likelihood of congestion peaks. this coordination generally considers two distinct dimensions. the time dimension (allocation of time frames) and the frequency dimension (allocation of subcarriers (or subcarrier groups)). If. Architectural aspects Since the congestion control typically operates on a per cell basis. 2007 (included in 3GPP S5-071944) [2] 3GPP TR32.3. possibly.2. achieving some degree of spatial fairness. “eNB measurements for RAN performance monitoring” 3. viz.3 Packet scheduling parameter optimisation Self-optimisation Optimisation Description Classification: Area of relevance: The packet scheduling coordinates the access to shared channel resources. the potential gain of self-optimising congestion control parameters is deemed fair.g. service mix and propagation/interference characteristics. however.1 Appropriate interfaces should be standardised to allow extraction of the input parameters into the selfoptimisation software. 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.1) and ‘Handover parameter optimisation’ (section 3. as well as the feedback flow back into the network in the form of adjusted congestion control parameter settings.3. Packet scheduling directly addresses QoS metrics only. 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.3).SOCRATES D2. these interfaces will be defined by the SA5 group.1 (2007-11) – Use case 8: QoS related radio parameter optimization [3] 3GPP R2-080444. changes in traffic/mobility patterns. GoS metrics are affected indirectly by optimising resource efficiency and hence allowing a maximum number of simultaneous calls. Since in such a scenario the uncontrollable variations of resource usage are relatively small. while feasibility is deemed good. 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. over time the degree of user mobility increases.2) use case. ‘Admission control parameter optimisation’ (section 3. In 3GPP.3. in accordance with the desired spatial fairness and in response to e. A key challenge in devising and setting parameters for a packet scheduler is to optimise resource efficiency. streaming. Potential gain Based on the high potential gains that are expected for the closely related admission control scheme. Example (Informative description) Consider a cell with little user mobility.2. 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.

• 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. • Scheduling weights – These weights are used in the relative QoS differentiation regime in order to give relative preference to calls with higher service. resource efficiency and packet marking.SOCRATES D2. the minimum observed QoS imbalance for the self-optimisation algorithm to affect changes.e. Page 34 (71) . it is has not really been considered yet in 3GPP. the packet scheduler typically has a spatial fairness parameter which specifies the desired balance between resource efficiency and fairness between near and remote users. 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. as listed above. which allow a QoS characterisation that corresponds with the formulation of the QoS requirements. with possible QoS over-achievements distributed over the on-going calls according to some fairness objective. a resource efficiency threshold below which the self-optimisation algorithm studies the potential of parameter changes. the selfoptimisation algorithm is triggered when (i) a significant QoS imbalance is observed. i. as for most radio resource management mechanisms. and the relative QoS differentiation regime. • Resource reservations – Part of the shared resources may be exclusively reserved for a certain class of calls.and/or subscription-base priority.1 Scheduling (triggers) Based on continuous monitoring of experience service quality and resource efficiency. In a rather general implementation. in order to optimise resource efficiency. 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). Status in 3GPP Although the QoS related optimisation use case is mentioned in one 3GPP document [6]. a number of parameters can be used to specify the associated selfoptimisation algorithm. 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. on both the terminal and the network side. the service type of the subscription. Appropriate interfaces should be standardised to allow extraction of the input parameters into the selfoptimisation software. e. where calls of different priorities receive different fractions of the shared resource according to their scheduling weights. based on e. Such reservation levels may also be self-optimised. hence no standard set of scheduling parameters exist. experienced QoS per on-going call. are generally devised by vendors. Besides these scheduling parameters. or (ii) the observed resource efficiency falls below what can be expected. 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. Measurements/parameters/interfaces to be standardised Appropriate counters should be standardised.g. when the QoS targets of some calls are overachieved while those of others remain unsatisfied. Input sources Key input source for the self-optimisation algorithm is the actual service mix.g. required QoS per on-going call. List of parameters Scheduling algorithms. Actions Actions taken by the self-optimisation algorithm are the adjustment of the packet scheduling parameters. as well as the feedback flow back into the network in the form of adjusted packet scheduling parameter settings.

Even if the resources are primarily assigned to the users near the base station. 2007. Potential gain Based on related studies that have been performed in the wireline domain (e. 2005. Orange.g. Any residual errors after the maximum number of MAC retransmissions will be handled by the RLC protocol (up to a tuneable degree.2). Other examples. Telefonica. Use case 8: ‘QoS related radio parameter optimization’. [5] D.3. Example (Informative description) As one possible example. retransmissions are only used for Acknowledged Mode (AM). COST 2100 TD(08) 410.g. Hence the resources become rather quickly available to the remote users.2. References [1] 3GPP R1-072929. 3.1) and ‘Link level retransmission scheme optimisation’ (section 3. [2] NGMN. 2008. It further relates to the ‘Load balancing’ (section 3. the packet scheduler is able to schedule downlink transmissions rather purely based on the instantaneous channel quality. AT&T. selfoptimisation of scheduling parameters can bring about significant gains with good implementational feasibility. imagine a cell with a number of on-going WWW browsing sessions. they will be freed rather quickly due to the assigned high data rates. “Initial list of eNB measurements”.816 V1. China Mobile. “Evaluation of advanced radio resource management”. “Study on the automated tuning of HSDPA Code Allocation”. Telecom Italia. 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. 2007 (included in 3GPP S5-071944). [4] Gandalf project.3. e. Related use cases As discussed above. ‘Congestion control parameter optimisation’ (section 3.4).1 Architectural aspects Since the packet scheduler typically operates on a per cell basis. Then at some point in time a very heavy download session pops up near the base station.2) use case. Garcia-Lozano and S. e.2.g.1). after which Page 35 (71) .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. • RLC level: At RLC level. ATM networks). ‘Handover parameter optimisation’ (section 3. [3] M. the applied proportional fair scheduling algorithm.3.2. T-Mobile. with fast feedback of ACK/NACK messages. 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. 2007. [7] 3GPP R3-070118. Proceedings of VTC ’05 (Spring). There are two types of link level retransmission for LTE: • MAC level: These are fast retransmissions. related to service-/subscriber differentiation are readily formulated. KPN. Sweden. downloading the entire 12-disc Lord of the Rings DVD box. Considering such a traffic scenario. which therefore indirectly also benefit from the applied pure channel-awareness in the packet scheduling. It will operate on top of MAC-level retransmission. Soldani and K. “QoS Design Principles”.g. “Genetic approach to QoS optimization for WCDMA mobile networks”.2. Retransmissions are combined using Hybrid ARQ. Deliverable D4. Valkealahti. “Informative list of SON use cases”. we foresee a distributed implementation of the associated self-optimisation algorithm. Stockholm.1. NTT DoCoMo. [6] 3GPP TR32. TeliaSonera. 2007. use case on ‘QoS related parameter optimisation’.SOCRATES D2. Ruiz-Boque.3.

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

‘Handover parameter optimisation’ (section 3. If this behaviour is structural (rather than incidental). Related use cases As discussed above. presentation.-P.3. e.W.3). Appropriate interface should be standardised to allow extraction of the input parameters into the selfoptimisation software. Helmersson.-F. S. Englund. Stockholm. 2005. References [1] Nokia. Proceedings of VTC ‘05. the admission control and packet scheduling schemes. Due to favourable local propagation conditions and little current competition on the shared channel. Cheng. while achieving maximum resource efficiency. Edholm. [2] K. M.SOCRATES Actions Actions taken by the self-optimisation algorithm are the adjustment of the retransmission scheme parameters. we foresee a distributed implementation of the associated self-optimisation algorithm. ‘Congestion control parameter optimisation’ (section 3. residual BLER) satisfy the associated requirements. Samuelsson.2. although the optimal time scale at which adjustments need to be made is to be investigated but may be rather small. as listed above. compared to e. Parkvall.2. by increasing the instantaneous BLER target (and hence allowing lower transmit power and enhanced resource efficiency).2). September 2005. Y.E. Page 37 (71) . number of retransmissions and residual BLER performance. C. 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.2). M. 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. 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. ‘System performance of WCDMA Enhanced Uplink’.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.1) and ‘Load balancing’ (section 3.3. Edvardsson. D2. the self-optimisation scheme will identify this and (gradually) adjust the retransmission scheme’s parameters for that service. ‘Packet scheduling parameter optimisation’ (section 3. Feasibility is in principle deemed good.1). E.2. these parameters may lead to experienced packet delays and residual BLERs that are better than necessary for that service. Sweden.g.g. Wang and J. the potential gain of self-optimising the link level retransmission scheme is expected to be fair. 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. Potential gain Considering the estimated relative impact the link level retransmission scheme has on the achieved resource efficiency. ‘Understanding the importance of HSUPA in driving the uptake of profitable applications’. as well as the feedback flow back into the network in the form of adjusted link level retransmission scheme parameter settings.

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. which is caused by a site failure). azimuth. • Observed failures on random access channel (calls cannot be initiated) • Timing advance before call drops. Users in the affected area have little or no network access and their calls may be dropped.1 3.2. need to be triggered. Input source The required input for the optimization algorithm will depend on the specific algorithm. shadowing by large structures. 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). e. If from some of the constantly monitored parameters it is deduced that there may be a coverage problem. Actions The optimization algorithm can require / perform the following actions: • Network monitoring. 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. in a seamless fashion for the user. based on the expiration of a timer . • Number of call drops in the cell. comparison of the results with reference values • Derivation of the optimized parameters. directed handover to a neighbour cell. 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. • periodically . pilot power) and/or poor propagation conditions (indoor locations. the following mechanisms for dealing with the problem could be triggered (not part of this use case): Page 38 (71) . Scheduling (Triggers) The execution of the optimisation algorithm may be triggered • on demand.g. proximity to highly absorbent mediums.SOCRATES D2. • Number call drops in a certain area (geographical area approximation at sub cell level). etc). retrieving certain parameters and measurements • Analysis of the measurements and the parameters calculated from them. then measurements should be taken more often and from a wider set of neighbouring cells. statistical distribution). when all other options have failed to improve/solve the current situation.. forests.5 Coverage hole detection Self-optimisation Optimisation Description Classification: Areas of relevance: A coverage hole (as opposed to a cell outage. is caused by a lack of sites. Changing eNB location or new site deployment should only be considered as a last resort. poor settings of coverage-related radio parameters (antenna tilt. 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. 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. when problems related to coverage are identified. etc. but will consist of parameters that give information about the network status: • User-generated received pilot signal strength per neighbour (average values.

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

this use case aims to reduce the occurrence of undesirable effects following handovers. possibly in several iteration steps • Configuration of the optimised parameters • Checking of the success of the re-configuration (e. such that with minimised human intervention more users can be accommodated with good quality.t. This use case considers the self-optimisation of the handover parameters like handover neighbour list. since the self-optimisation aims at dynamically adapting the handover parameters according to the current load of the cell and that of neighbouring cells. Therefore. Objective • Algorithms to automatically optimise parameters controlling handover. QoS indicators under a reference value.. signal strength).3. retrieving certain parameters and measurements • Analysis of the handover related measurements.1 3. periodically. the drive test results and the traces. like call drops. this use case is strongly linked to the load balancing use case.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.3 3. the total network capacity should increase compared to the static / non-optimised case.r. comparison of the results with reference values • Deriving of the optimised parameters. the result of the optimisation procedures is that Page 40 (71) . to harness spare capacity in neighbouring cells.. 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. Scheduling (Triggers) The execution of the optimisation algorithm may be triggered • By the identification of problems related to handover or unwanted events.SOCRATES D2.g. rather than setting them to a constant value. Also. such as call drops and ping-pong handovers between two cells. neighbour specific thresholds and hysteresis parameters. 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. the calculated KPIs. by external events Input source The required input for the optimisation algorithm will depend on the specific algorithm. This will also include the potential of handing over UEs to non-optimal cells (w. 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. This way. ping-pong handovers between cells. too many handover failures. lowering an handover threshold should not increase ping-pong occurrences) Expected results It is expected that with minimised human intervention.

.2) Page 41 (71) . handover should be carried out. it sends the necessary information to the network.1. • Handover parameterisation optimisation is described as use case O03 in Section 4. Example (Informative description) Handover can be performed for several reasons. signal strength). the optimisation algorithms will function with the measurements and parameters already supplied by the network for the handover process. thus potentially obtaining better throughput than before the handover.1. The source cell determines the target cell and queries the target cell if it has enough resources to accommodate the UE.3.7).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. and because in this way the load balancing algorithm can tune the handover parameters such that handover to the congested cell is delayed. With load balancing. When a UE moves between two LTE cells.3. since the handover will be based on local eNodeB and UE measurements (cell and neighbouring cell). because of the unpredictability of the wireless environment.7 of 3GPP TR32. Architectural aspects Handover parameter optimisation can be implemented in a centralised or a distributed way. 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. If the handover criteria are met. 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. UEs that are close to the border of a congested cell can be handed off to a neighbouring non-congested cell. A self-optimisation of the handover parameters will be beneficial compared to a fixed parameter setting. The algorithms and the parameters processed need to be aligned between the multivendor equipment.2.g..816 V1. like UE mobility and local congestion in a single cell (load balancing reason). and that handover from the congested cell is advanced. A distributed way seems appropriate. 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. It is assumed that the algorithms will be vendor specific. in which case it hands over the UE to the target cell.3.g. Based on the measured radio environment (e.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.1.1 (2007-11) [1]. ‘Specification level requirements’ are not yet defined (Section 5.4. 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. the UE evaluates the necessity of handover.SOCRATES • • • • • • D2.

This means to adjust the capacity management parameters such as admission/congestion control thresholds.816 V1.2) D2. • Achieved GoS level (blocking and dropping probability) • load estimation parameters (e.SOCRATES • • • Neighbour cell list (section 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. etc) provided that the desired QoS levels are maintained.g.e.e. the capacity a cell still has available. BLER. delay. The selection of sessions for transfer in other cells (or RATs) can be done on basics of radio propagation conditions. maximum allowed downlink total power.3. etc. 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) . that can be expressed in terms of a reference unit.2) Tracking areas (section 3.4. number of ongoing real-time and non-real-time connections) at the cell of interest and its neighbours. by detecting a value over threshold or by a watchdog mechanism.g. uplink noise rise targets. The focus of this use case is the situation when the traffic is shifted and the resulting situation is with more balanced load. resource consumption of these sessions. the amount of occupied Uplink and Downlink resources relative to the total available resources at the reference and neighbour cells. Note that in some situations.3) GoS/QoS related parameter optimisation (section 3.g. 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. Note that after the transfer of ongoing sessions towards more lightly loaded cells their QoS requirements should be still satisfied. in the heavily loaded cell and the surrounding cells in order to match the capacity with the traffic demand. when the load imbalance is discovered. 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. This is referred to as load balancing. where the capacity is balanced over the cells. Scheduling (Triggers) This use case is triggered on demand i. Objective The objectives for this use case are twofold: • Timely and accurately detecting cells with load imbalance without manual involvement. • Resource utilization i. etc. throughput.1 References [1] 3GPP TR32. delay. etc). Input source The most important input sources are eNodeB measurements: • Uplink/Downlink Load measurements (e.3. • Achieved QoS level in uplink and downlink (e.3. This can be seen as a separate use case. • Taking actions in an automatic way to resolve this load imbalance by shifting traffic towards the lightly loaded cells. it could be profitable not to shift the load but to perform ‘capacity (un)balancing’.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).

The exchange of load information over X2 interface is agreed by RAN3. RAN2 agreed on few measurements for the radio resource that are useful for load balancing. The exchange of the load measurements and resources utilization between neighbour cells should be standardized. Page 43 (71) . The load on the following resources has to be assessed: radio. It is noted that although the new situation with balanced load will generally have a positive effect on the GoS (i. etc. • Changing the coverage area of the cell and its neighbours by adjusting the pilot powers. Additional eNodeB measurements are still discussed in RAN1.e. it can have a positive or negative effect on the QoS levels of the ongoing connections (while still maintaining the QoS targets). 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). 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. RAN3 has agreed to define detailed measurements to assess load information. 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. 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. with minimized human intervention in the network management and optimization tasks.1 The maximum allowed load before triggering the load balancing check. Additionally the definition of the cell reselection/handover parameters to be reconfigured is an open issue. The location of cell reselection/handover parameters' reconfiguration decision is an open issue.902. less blocking and dropping). This means that measurement X should have the same meaning and should provide the same value for a given situation.e. 3GPP is also discussing the architecture for load balancing. transport network. no matter who the vendor of the eNodeB is. 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. The maximum number of iterations/time allowed for resolving the load imbalance. the amount of load to be transferred to neighbour cells (or RATs) at each iteration. eNodeB hardware. The load balancing use case was agreed on by RAN3 and introduced in TR 36. Signal strength of pilot channel per cell and per neighbour cell. • Changing the handover parameter (intra-RAT and inter-RAT) in order to shift active mode terminals towards lightly loaded cells. uplink/downlink resource utilization. The maximum allowed load imbalance when compared with the neighbour cells before triggering load balancing actions. pilot power. Step size i. at low/medium load levels the load balancing might not be needed. 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. The definition of the load for eNodeB hardware and transport network resource is an open issue. etc. The ultimate goal is to obtain.SOCRATES • • • • D2. For example.

etc. how often the shift of traffic occurs. If adjacent eNodeBs are from the same vendor they will exchange information via X2 interface. throughput and delay).e. 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. 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). amount of traffic that is shifted to other cells. what actions are undertaken to shift the load. A distributed solution would best fall under the requirements of LTE and is already agreed on by RAN3. etc.g. Distributed: • each eNodeB analyzes the measurements it gathers from the network and communicates its decision to neighbour eNodeBs via the X2 interface. 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. Hybrid: • • • • Indicators for each eNodeB regarding its vendor. QoS (e. final decision will be taken at upper level (i. the eNodeBs can directly exchange measurements with their neighbours. Else.g. This results in more balanced number of ongoing sessions per cell. but we need to keep in mind that in a multi vendor environment . Of course. 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) . Each eNodeB thus knows “who” its neighbours are. higher layer decision will be triggered or a convergence layer will be integrates in the eNodeB/aGW. each eNodeB will perform certain measurements according to different algorithms so a centralized entity needs to make the convergence between them. but we have to make sure that their meaning is the same. so we need standardised measurements. blocking and dropping).SOCRATES D2. Example (Informative description) The load balancing is illustrated in Figure 3 below.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). 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. The number of ongoing sessions in Cell B is much larger than the number of ongoing sessions in the neighbour cells A and C. MME). GoS (e. It would be interesting to decide between the following possible solutions: Centralized: • for multi vendor environments. amount of traffic imbalance that is resolved. The load balancing function is able to automatically detect this load imbalance.

The flow diagram presented in Figure 4 explains the working of the load balancing use case. This should be done in cooperation with the handover. These actions are done until the load imbalance is resolved. NTT DoCoMo. • creating a controlled “ripple effect”: cell A and C will further use the load balancing mechanism involving their non-congested neighbours (i.In this case.2) • Coverage hole detection (section 3. 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. “Load Balancing SON Use case”.2.e. T-Mobile. Telecom Italia. Just as a clarification. 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.3.5) • Admission control parameter optimisation (section 3.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).1) • Neighbour cell list (section 3. Telefonica. First. Handover. 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. reduced OPEX due to less manual intervention in the network management and optimization tasks and more users can be accommodated into the system.1) • Congestion control parameter optimisation (section 3. cell D and E). Related use cases • Handover parameter optimisation (section 3. 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.3. less blocking and dropping). “Load balancing use case involving cell reselection and handover parameters self optimization”. optimisation functions. the decision making entity will be situated within each eNodeB.2.3) References [1] R3-072249. “Congestion Status Indication in E-UTRA” Page 45 (71) . When a load imbalance is detected then load balancing actions are initiated. [2] R3-071438. QoS. Orange. Alcatel-Lucent [3] Tdoc R3-070562: Self-optimization use case: self-tuning of handover parameters [4] R3-061197.e.2.

v 1. Finland. “Introduction of automatic neighbour relation function”. Automating this process is therefore commonly seen as beneficial. Archive of the NGMN SelfOrganising Networks Project 12 mailing list. Ericsson [3] J. the primary design goal for wireless networks was increased spectral efficiency. Stadler. This has three principle reasons: • Costs for electricity are already a non-negligible component of the operator’s OPEX. [4]). and it is being extensively addressed in 3GPP (for an example. [4] F. • Minimize usage of excessive resources during low or light traffic period. i. ‘Decentralized configuration of neighboring cells for radio access networks’.0. 2008. • Ensure coverage during switch off periods. Finland.e. • Get positive image of an environment friendly technique and network.3 Neighbour cell list Defining neighbour cell lists is seen as a significant manual effort [1]. i. SOCRATES will not spend additional effort on this use case. 2007.SOCRATES D2. • Consider QoS requirements of users when switching off cells/reducing resources. 2007. energy efficiency has also to be considered. Parodi. February 8. [6] R3-070597. see [2]). Baliosian and R..2 (included in 3GPP S5071944) [2] 3GPP R3-072014. The CO2 emission is an important figure of merit already now. Proceedings of IWAS ‘07. which might be varying in time and space. Ericsson and others are already actively working towards solutions (for examples. to support as high data rates with a given spectrum as possible. although no regulatory limits have been defined so far. “Mechanisms to achieve distributed load balancing in LTE” [7] 3GPP TR 36.1 Evolved Universal Terrestrial Radio Access Network(E-UTRAN). Page 46 (71) .53. on top of spectral efficiency. • Energy costs are increasing tremendously.1 [5] Comparison of SON architectures for load balancing. For these reasons. Informative List of SON Use Cases.e. 3. section 4.4. see [3].902 V0.3. to minimize the energy consumption for a given cell load. et al. Selfconfiguration and self-optimizing network use cases and solutions 3. However. ‘An automatic procedure for neighbor cell list definition in cellular networks’. Telecom Italia. as much as possible. The power consumption played a minor role so far. • Environmental aspects are strong arguments in the public and part of many companies' corporate responsibility portfolios.1 Other Reduction of energy consumption Self-optimisation Optimisation Description Classification: Area of relevance: In the past. recently energy costs have become of high interest in public and thereby also in telecommunications. Proceedings of IWAS ‘07. References [1] NGMN Project 12.4 3. In the future. • Reduce CO2 emission. Neighbour cell list optimisation is a popular application of SON techniques. Objective The main objectives for this use case are: • Reduce OPEX cost spent on energy.

• When the resource utilization is above a specified for a sufficient amount of time then resources are switched on. Work is already ongoing in 3GPP to define signalling over this interface. 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. For a distributed solution.SOCRATES D2.g. • Collecting data from coverage measurements to prevent possible coverage holes during switch off periods. 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. • In case of dropped call or QoS degradation resources are switched on. the X2 interface will be used. Page 47 (71) . Draft descriptions can be found in R3080460 and R3-080528.1 Scheduling (Triggers) Reduction of energy consumption will be mainly based on traffic monitoring with regard to QoS and coverage assurance.902 “Selfconfiguring and Self-optimizing network use cases and solutions”. Tx antennas. Not only current situation but also potential state of the network has to be considered. • Switching on/off redundant resources e. 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. 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. Threshold and time interval should be based on network statistics as well as state of resource utilization during measurement period.

regarding also impact on power amplifiers and potential negative effects in network performance (coverage outage. capacity limited areas.).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).2) References [1] R3-080460.5) • Load balancing (section 3. Related use cases • Cell outage management (section 4. antenna tilt.2. “Self-configuring and Self-optimizing network use cases and solutions” Page 48 (71) . needs to be dimensioned to the peak load. i. which manages the interaction between different cells.6 1. Network deployment.8 0. cf. 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.g.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. typically load is varying considerably within a day. which is therefore expected to be a valid field for research and optimizations. where umbrella coverage is available.1) • Coverage hole detection (section 3.3.6 0. is a new design goal.4 0. it may be useful to also have a centralised SON function. QoS degradation etc. This implies a distributed solution. Additionally there is important but difficult to measure image gain that comes from CO2 emission reduction and environment friendly network performance. however.SOCRATES D2. In addition. “Energy Savings SON Use case” [2] R3-080528. Figure 5. The highest potential gain is on high load. transmit power. Average Traffic Distribution over Day 1. The differences between “night” and “day” traffic allow freeing many resources. etc.4 1. the RF of a cell and – if necessary – provide contiguous coverage by adaptation of parameter settings in neighbouring cells. Example (Informative description) In wireless networks.e. e. “Energy Savings and Interference reduction Use Case Description” [3] TR 36. 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. Gain on reducing energy cost has to be estimated basing on percentile of energy cost in OPEX. e.g.2 1 0.902.

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. because only TAU are mentioned. [8] (Vodafone) proposes the equivalent TA concept for use in both intra and inter-System LTE mobility. In case of paging failure in the PA. [12] (Mitsubishi Electric) proposes a mechanism comparable to [10]. compatibility with legacy systems (GSM. where the tracking area size depends on the velocity of UE and/or the estimated frequency of incoming calls. it sends a paging request message with hop information to the reference E-Node B in the TA. UMTS). a MA of UE may be calculated in MME/UPE. [3] (LG) proposes that the UE should assist the network with information for the choice of the most suitable TA. [2] (Qualcomm Europe) proposes distance based registration. It can help reduce the paging increase created by overlapping TAs. Restrictions due to roaming or based on user subscription can be handled easier. redundancy. but deals with TAs only. at the time the UE sends a TAU message. It analyses requirements and performance of inter ENB connections. A UE is assigned a specific TA size dependent on timer thresholds. 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. movement area and paging area. A PA is defined as the area where the network pages the UE.1 [6] (Mitsubishi Electric) introduces the concept of reference point ENB(s) for the purpose of transferring paging request messages in large tracking areas. determination of neighbour cell lists and needed X2 associations. The equivalent TA concept could easily be used in conjunction with the overlapping or hierarchical concepts. Optionally UE can be triggered to send cell lists during limited period of time or a limited population of UEs. hiding cells to MME's view. One concern taken into account is the necessity to have TAs spread over cells of different systems. 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. When a MME receives a notification of incoming downlink packet from a UPE. [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). This concept is used in [7] proposing the principle of hierarchical TAs. Each Node B would broadcast in the system information message the Latitude and Longitude of the base Node B position. Page 52 (71) . With this statistics information about mobility across LTE/SAE networks are collected for self-configuration of the design of TAs. but it can also assign to each stationary UE a paging area that spans across non-overlapping static TAs. The intersection of the movement area and the RA is the PA of the UE. A RA is defined as the area where a UE is registered in the network and could move without initiating registration/update signalling. so as to avoid unnecessary ping-pong procedures at the edge of isolated LTE cells. [7] and dynamically defined user-specific TAs [2]. so that stationary UEs will not contribute to the signalling load at TA border. [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. [11] (Mitsubishi Electric) proposes that. [9] (Mitsubishi Electric) introduces the concept of Virtual Location Areas (VLA). no mobility statistics on cell basis. [15] (Huawei) splits the context TA into the terms register area. 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. 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. MME / ENB processing load and paging transfer delay. 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. According to the UE's velocity or the movement characteristic. 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 . paging in the RA may be initiated. The MME optimally selects the TA of a given UE camped in a given cell according to the UE movement characteristics. it reports to LTE/SAE network the list of past visited cells since it performed the last TAU procedure. In keeping the UE and Mobility Area Identities for each system separate. [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. Concept can include the concepts of overlapping [4]. hierarchical TAs [5]. it allows the use of a different code space and the size. which addresses the issues with signalling load caused by ping-pong and hard mobility boundaries.

TAU. These measurement procedures require appropriate interfaces to the network elements and. if the UEs track themselves on cell level. at the time of TAU procedure. The gain will be an improvement in GoS level. 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 UE’s are considered. other networks) optimisation of TAP yes signalling treshold(s) exceeded? PM data base paging msg/rsp HO. Example (Informative description) The triggers. Anyway. at the time of handover. including (if available) mobility history with cell granularity. reduced OPEX due to less manual intervention in the network management and improvement in the balance of operating load. to a separate data base where long-term measurement values are recorded. TA level. process connections and actions are summarised in Figure 6. other networks) yes yes new configuration? new event? paging contribution (cell) TAU mobility relation (cell pair) additional signalling load etc. other UE mobility history (re-)configuration of TAP signalling estimation measurement processing average long-term representation of user traffic generation and mobility (incl. • collect number of paging responds per cell. e. MME. g. • collect number of signalling attempts on the channels which are also used for paging and TAU. • collect transition information of UEs in idle mode. etc. Architectural aspects It is unclear where the SON mechanisms and the mobility management will be implemented (eNB.1 Measurements / parameters / interfaces to be standardised The measurements collected from the network and/or UEs depend on the implementation. if required. Page 53 (71) . list of configured cells event manager planner’s experience (incl. Recommended measurement procedures are: • collect transition information of UEs in active mode. • collect number of paging requests per paging area. information about traffic regarding paging and mobility has to be collected.SOCRATES D2. long-term measurement job (incl. OMC). somehow. 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.

3. Ericsson [5] 3GPP R3-060148. "UE-reporting based network-assigned Tracking Areas". "Idle Mobility and Tracking Area Concept in SAE / LTE". Huawei [15] 3GPP S2-061368. "Hierarchical Tracking Area". Mitsubishi Electric [8] 3GPP R3-060457. "Self-Optimization for Tracking Areas". LG Electronics Inc.3) • Determination of needed X2 associations [11] D2. "Paging Optimization in Overlapping Area". From a synchronous network point of view. "3rd Generation Partnership Project. ZTE [14] 3GPP S2-061366. all base stations (BS) should have the same frame structure to ensure that interference generated by users transmitting (uplink).882 V1. Samsung [19] 3GPP S5-071275.1 References [1] 3GPP TR 23. "SON philosophy for LTE". Mitsubishi Electric [7] 3GPP R3-060153. "UE assisted tracking area update". "Register Area and Paging Area". Lucent Technologies [18] 3GPP S2-061652.0 (2008-01). "Distance based Registration". "Hierarchical tracking Areas in the evolved system". 3GPP System Architecture Evolution: Report on Technical Options and Conclusions (Release 7)" [2] 3GPP R2-060056. 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. One of the main objectives is to assign dynamically the number of uplink and downlink slots to fulfil users’ requirements (uplink/downlink load). [4] 3GPP R3-060049. Huawei [17] 3GPP S2-061434. Vodafone 3. NEC [11] 3GPP R3-070660. Technical Specification Group Services and System Aspects. Vodafone Group [9] 3GPP R3-060490. "Proposed Tracking Area Concept".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). QUALCOMM Europe [3] 3GPP R2-071325.SOCRATES Related use cases • Neighbour cell lists (section 3. Mitsubishi Electric [13] 3GPP R3-071415. "Discussion on configuration of tracking area". BS1 BS2 Figure 7 Opposite time-slot configuration for two adjacent base stations Page 54 (71) . "Collecting mobility statistics in support of configuration and optimisation of LTE/SAE networks". Huawei [16] 3GPP S2-061369. SAMSUNG [6] 3GPP R3-060151. or base stations sending data to users (downlink) are synchronized among all eNodeBs in network (see Figure 7). "Transferring a paging request message".4. "Virtual Location Areas". "Hierarchical TA Concept". Mitsubishi Electric [12] 3GPP R3-070782. "Equivalent Tracking Areas".14. Mitsubishi Electric [10] 3GPP R3-061087. "Reported List of Last Visited Tracking Areas".

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. it is assumed that not all base stations have the same time-slots allocated for uplink and downlink. 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. Objective The main objectives for this use case are: • Minimise the impact of inter-cell interference in unsynchronized slots. QoS and load/interference status from neighbour cells • Detect problems • Take action to deal with problem. Switching between downlink and uplink is realized with a guard period (GP) located in time slot number 1 in frame structure two (FS2). • Ensure good cell edge performance.as well as on continual interference monitoring. because in some areas users need more downlink than uplink and vice versa. 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. However. at the expense of users closer to the eNB. 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. 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.SOCRATES D2. a possible process is: • Monitor interference levels. it is assumed that BSs are synchronized at frame level (either by GPS. the following information may be used: • User QoS (throughput. allows switching between downlink and uplink. Here. Having a flexible UL/DL switching point. it is not possible to specify detailed actions. or in opposite way which is very important for TDD network. for example: Page 55 (71) .1 A main theoretical advantage of TDD over FDD is the fast shuffling of capacity between uplink and downlink. as no algorithms have been defined yet. Input source As input data to a TDD UL/DL split algorithm. However. using a high level description. When we must switch between uplink and downlink direction we use timing advance mechanism. X2 or some over-the-air synchronization scheme). From that perspective is very important to have knowledge of the influence on network’s performance having opposite assignments of uplink and downlink slot. It is necessary to find the right trade-off. delay. • 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 . However. for users belonging to two different base stations. 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. in the same time.

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) . when BS1. 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. but it has also influences the overall network properties. configured as uplink for time-slot 5 is receiving signals from own UEs (but not only) will also receive downlink signal (interferences) from BS2.9 related topic. jitters for real time traffic) Status in 3GPP LA-TDD is a Rel. because they are experiencing the highest interference level. In Figure 8 the interference situation described above is presented. both in uplink and downlink. then users from BS2 receive additionally interferences from BS1 users.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.g. because they experience two types of interference: UE-to-UE interference. In addition. This problem is very serious from BS2 cell-edge users. the following standardised measurements are required: • QoS measurements. This problem is not serious as mentioned in first bullet. and users belonging to BS2 have the same slot configured as DL. time slot 5 for UL direction. TDD specification for physical channel can be found in TS 32.611. per user (throughput. Measurements / parameters to be standardised To support the interference control use case. packet loss) • Estimation of user location (close to cell edge or not) • Measurement of interference levels. Full synchronization in the network is assumed by now for TDD system.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. 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). At current stage no direct discussions are settled on 3GPP forum. when users from BS1 have assigned e. delay. This implies a distributed solution. generated by cell-edge users from BS1 BS-to-BS interferences.

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. while a relay is somewhat more intelligent as it receives the actual data and then forwards it.4. Related use cases • Interference coordination (section 3.1) • GoS/QoS related parameter optimisation (section 3. including received interference.2) • Load Balancing (section 3. in the surrounding eNodeBs. The interference caused by the relay or repeater should be kept as low as possible.3. however it needs good interference coordination mechanism to prevent potentially very high UE-UE interferences. or in a given percentage of the UEs rises above a given threshold.2) References [1] 3GPP TS 36-211 “Physical Channels and Modulation (Release 8)” 3. The repeater is a simple device that receives and amplifies a received signal. When a new relay or repeater is added in a network it needs to automatically find its configuration and connect to the network. 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. 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. This could be done by adjusting the transmission power or by using beam forming.4 Management of relays and repeaters Self-configuration and self-optimisation Deployment.SOCRATES D2. 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) .1 Potential gain The usage of adaptivity of switching points allows to achieve best possible capacity and QoS assurance.1. Objective A newly installed relay or repeater should automatically • find its configuration and connect to the network During operation.

Interface between the relay and the serving eNodeB .SOCRATES • • • configuration parameters relay/repeater power beam forming parameters D2. Example (description) Two relays. where it is possible to evaluate the interference situation from a network perspective. Page 58 (71) . Relay A forwards the signal transmitted from UE1. Power adjustment may however need to be managed from a higher node. In the uplink relay B forwards the signal from UE2 and UE3. 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. Status in 3GPP Relays have been discussed. relay A actively stops forwarding the signal from the UE in order to reduce the interference it is causing.1 Actions At start-up of a new relay or repeater. the relay transmission power should be lowered.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. • 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. it should automatically find its configuration and connect to the network. Once the difference between the total received signal strength and the estimated signal strength from relay A falls below a given threshold. 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. see Figure 1. Measurements/parameters/interfaces to be standardized The following measurements/parameters/interfaces may be needed for this use case: . but no specifications have yet been presented for approval. relay A and relay B are connected to an eNodeB. If the interference level in the eNodeB or in a given share of the UEs rises above a given threshold.

By using self-optimisation the interference caused by the relays will be adjusted more efficiently. an operator can use this spectrum. as it is uncertain what the demand will be for the application of spectrum sharing. Related use cases • Interference control References (3GPP/NGMN) The 3GPP specification 3GPP TS 36. this may be reviewed at a future date. In general. This use case is currently seen as a low priority. Page 59 (71) . the interference can be controlled with a higher frequency than what is possible to do manually. If it is not being used by any other operators. The use case is not a part of the NGNM list of SON use cases. Evolved Universal Terrestrial Radio Access (E-UTRA). Repeater radio transmission and reception has not yet been presented for approval. 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.5 Spectrum sharing Spectrum sharing means that different operators use the same spectrum.SOCRATES D2. this requires advanced algorithms to avoid interference issues. It will therefore not be considered by SOCRATES at this point. Obviously.4. 3.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. For example. resulting in a timely response to changes in network characteristics. However.106. but detect whether that spectrum is being used otherwise or not. costs will decrease when introducing self-configuring relays.

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. detecting it. handover (intra-RAT and interRAT) optimisation.g. This is presented in Figure 10. in the coverage area of the cell. UE measurements. We define that a cell is in outage when the UEs. and coverage optimisation. Cell outage prediction). 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.g. cell outage prediction and detection make decisions based on analysis and correlation of different measurements collected from the network (e.3. It should be stressed that the situations when there is a coverage hole in a certain area of the network due to e. broadcast and/or high-speed data RBs are not available while voice RBs are still established and maintained. Predicting outage. handover optimisation.1. 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.1.SOCRATES D2. before it happens (section 4. This use case is classified as self-healing. Note that via the cell outage compensation actions this use case can be linked with other use cases such as load balancing. Page 60 (71) . for example. by means of load balancing.2. Cell outage compensation).g. when it happens (section 4. extensive interference are out of the scope of this use case. 4.1. This down time or malfunctioning can be on the radio or transport level.. Both. and then trying to compensate for the outage of neighbouring cells (section 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. With limited set of unsupported RBs we address the case when.1. Cell outage detection). 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.1 4 Self-healing use cases All the ‘self-healing’ use cases considered within the SOCRATES project are describing cell outage issues. and coverage optimisation. eNodeB measurements.

At which outage likelihood level these additional actions are taken should be a threshold/parameter Page 61 (71) .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. if the prediction gives increased likelihood of cell outage then additional actions can be taken (e. Consequently.SOCRATES D2. the outage likelihood. However. the whole cell or only a limited set of RBs are not supported.e. etc. as well as the scope and type. In the following we describe the cell outage prediction use case in more detail. when the outage is expected. increased measurement frequency and cooperation with cell-outage detection). the geographic area with low performing RBs (if possible). 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. the cell outage detection function is informed about this estimation for further processing of the trigger.g. Scheduling (Triggers) The prediction of the outage is a continuous process that correlates the relevant information in order to derive the prediction.1.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.

type of the outage.. These weights could be parameters. It is for FFS if the hardware/software failure and utilization reports should be standardized. RF circuits. etc. Page 62 (71) . Measurements / parameters / interfaces to be standardised At the eNodeB side several measurements. For example. model parameters include discretisation thresholds.g.SOCRATES D2. On the other hand the parameters of the outage prediction function depend on the used prediction algorithm/methodology. etc. but even better. neighbour eNodeBs. processing boards. Architectural aspects The input for cell outage prediction is based on localized eNodeB measurements (from the cell in outage and its neighbours).. scope and likelihood of the forthcoming cell outages. time interval of the outage. they could also be self-optimised based on automatic correlation analysis between inputs. etc) and software utilization reports o Temperature of. e. • eNodeB measurements (from the cell that is a candidate for outage or neighbour cells): o Hardware and software error reports. These measurements are then analyzed and correlated and then a soft outage decision is derived. e. The decision entity could be localized in a centralized domain because the inputs from various sources should be aggregated and analyzed. and (ii) the operator’s response time in manually repairing actual outages is reduced. O&M and UE measurements.. affected cells. scope of the outage. corresponding likelihood. the site and hardware o Traffic measurements o Resource utilization measurements o other • Known/scheduled outage events. These measurements are collected from the cell that is candidate for outage. Expected results The network is reporting timely and accurately the location.1 Input source The most important input sources are presented in the bulleted list below. 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. traffic and resource utilization measurements should be standardized. Example (Informative description) From the network different measurements are fed into the cell outage prediction entity (see section about the Input Sources). weighting. 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. e. 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). If this soft outage decision is positive then the cell outage detection function is informed. the predicted outage likelihood and actually detected outage events. which could result in hardware or software failures.g.g. See also ‘Input source’. and O&M. hardware upgrades and software licenses. based on self-tests o Hardware (e. 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. in Bayesian Networks. likelihood. Status in 3GPP Cell outage prediction has not been introduced in 3GPP yet. etc.g.

reporting to the operator/compensation functionality) are triggered when a software/hardware errors occurs. 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. triggers may also be based on observed abnormalities in eNodeB and RB performance. However. this may not be the case).1. Since errors due to software/hardware may be difficult to detect themselves (ideally a software unit reports errors.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. An outage should be detected within appropriately short time interval (e.2) • Cell outage compensation (section 4. Related use cases • Cell outage detection (section 4. A detection mechanism must work in a timely manner.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. the whole cell or only a limited set of RBs are not supported. where a decision to activate the cell outage compensation is taken. both cell outage compensation measures and preparation for manual repairs can be triggered. etc).SOCRATES D2.3) References None 4.1.1.e.e. In the following we describe the cell outage detection use case in more detail. • The type of the outage i. etc. radio or transport part.g. the actions taken by the detection (e.g.e. the geographic area with low performing RBs (if possible). minutes). however. OSS. Page 63 (71) . 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. Scheduling (Triggers) The detection mechanism is “always on” and is not “triggered” in a sense. hardware or software malfunctioning. This affects where the detection functionality operates (at eNodeB. etc.

Status in 3GPP Cell outage detection has been implicitly introduced in the context of outage compensation. downlink/uplink throughput. to the best of our knowledge there are no contributions explicitly on cell outage detection. drop call statistics. and the cell outage characteristics. Reference Symbol Received Power (RSRP) measurements with average values. which in turn restores the coverage as much as possible considering the outage type and the conditions of the neighbour cells. These cell outage reports are used by the cell outage compensation function. i. It is a task for the cell outage detection to determine which neighbour cells are affected by this outage (e. o Cell performance indicators such as capacity (e. 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. 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. 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.g. Page 64 (71) . The cell outage detection function reports that Cell B is in outage and describes the scope and type of outage. It is for FFS whether the hardware/software failure reports should be standardized. etc.g. affected neighbours. Example (Informative description) Figure 12 shows an example of cell outage detection. Cell A and Cell C). Expected results The network is reporting timely and accurately the location of the cell outage (ID of the cell in outage). number of ongoing sessions). the ratio of failed HOs over total number of HOs to a particular neighbour. or at above a certain Timing advance value. At the eNodeB side several measurements should be standardized such as HO performance. 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’).e. Measurements / parameters / interfaces to be standardised The required UE measurements (see section Input source) can be obtained from already standardized measurements. • UE measurements: o UE neighbour measurement reports such as e.SOCRATES D2. It aims at timely identifying the outage and correspondingly report to the cell outage compensation function. 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. However.g.. statistical distributions. A failure occurs resulting in no coverage in the area previously represented by Cell B.1 Input source The most important input sources are presented in the bulleted list below. capacity and load measurements. 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.

acceptable level of dropped and blocked calls) while the underlying hard/software problem can be repaired as soon as possible. These measurements are analyzed and correlated and then a soft outage decision is derived. After the final decision on cell outage the cell outage compensation functionality is triggered in case of positive decision. the UEs. From the network different measurements are fed into the cell outage detection entity. if possible. the hardware/software alarms from the NEM are directly transferred to the cell outage decision entity. from the cell outage prediction functionality at early stage. After considering the feedback from the NEM a final decision is made for cell outage and the cell outage compensation function is triggered. The compensation measures can eventually result in satisfactory coverage (i.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. 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.e.SOCRATES Coverage Area Cell A Cell B Cell C D2. For example. and traffic measurements (see ‘Input source’). Page 65 (71) . neighbour eNodeBs. These measurements are collected from e. 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. 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 input for the soft outage decision can also arrive. It is for FFS how to coordinate the tasks between cell outage prediction and cell outage detection on basis of timing. cell in outage. as indicated with the bi-directional arrow in the flow-diagram. On the other hand. 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.g.

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.g.1 4. Objective The goal of outage compensation is to minimize the network performance degradation when a cell is in outage. or to the largest extent possible. In this case. proper actions to mitigate cell outage should be executed no later than a predefined deadline (after detecting the cell outage)... Input source The main input source for cell outage compensation is the output of cell outage detection.1. radio or transport part. hence. • cell performance indicators (e.3) References None D2...e.g. some parts of the original cell can be covered by neighbouring cells.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. Necessary reconfigurations to minimize RB performance degradations must be done in a timely manner. capacity). and meet operator’s deployment requirements based on coverage and KPIs (e. the whole cell or only a limited set of RBs are not supported. Automated reconfiguration as a result of cell outage serves at completely. The measurements could be for example: • UE neighbour measurement reports (e. The outage compensation may also need to use measurements in order to compensate for the outage in an adequate way. Note that there may be an upper limit for the degree of compensation that is actually possible. assume that a hardware failure occurs at a cell resulting in a total shutdown of the eNodeB. This is done by automatic adjustment of network parameters in order to optimise coverage and performance. number of supported users.1) • Cell outage compensation (section 4. • 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 Related use cases • Cell outage prediction (section 4.e. alleviating and compensating outage in the area previously served by the missing or low performing cell.g. 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). capacity. The cell outage detection mechanism can be a human operator or a subsystem of the network. hardware or software malfunctioning. and data rates) to the largest possible extent.1.g. the geographic area with low performing RBs (if possible) • The type of the outage i. etc.1. we cannot compensate for the cell outage entirely. RSRP measurements). For example. e.

. or inter-RAT/frequency neighbours are overloaded and cannot admit incoming services. e.1 Actions Upon the detection of cell outage. neighbouring cells are operating at their maximum power... e. In case that nothing can be done for compensating the outage. 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 this case changes to the radio parameters of the base stations (e. inter-RAT/frequency mobility parameters.g.g. 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. An eNodeB may need to compensate outage for several neighbours. The procedure shall need no longer than a predefined deadline. then the domain manager or the network manager must be informed. where for example the cells in outage may not be neighbours (the compensating cell is in the middle). the antenna tilt is at its minimum. Page 67 (71) . When the eNodeB failure has been removed an autonomous reconfiguration to the initial status shall take place.g. tilt. the network reacts to compensate the loss of performance in the respective area or cell.SOCRATES • • • neighbour list tracking areas load balancing parameters D2.

Example (Informative description) Figure 15 below shows an example of cell outage compensation. 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 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.. Page 68 (71) . Measurements / parameters / interfaces to be standardised A command from the network management level that initiates cell outage compensation. Status in 3GPP Cell outage compensation has been identified as a SON use case and some contributions have been discussed. timing requirements. e. and service quality. Necessary reconfigurations to minimize service degradations must be done in a timely manner and as fast as possible to prevent unnecessarily loss of revenues. Further..g.SOCRATES D2. Automatic coverage compensation procedure leads to the better network performance. Architectural aspects The location of self-X functionalities depend on. As such. This implies that HO failure rate and radio link failure rate are decreased. see References for examples. cell outage compensation affects and involves only the cell that is in outage and cells in the vicinity of that cell. A failure occurs resulting in no coverage in the area previously represented by Cell B..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 . coverage. this functionality is best handled by the eNodeBs or the entity managing the eNodeBs (OSS) due to the locality of the problem. 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.

Self. KPIs.Pilot Power .1) • Neighbour cell list (section 3. China Mobile [2] R3-072180.3) • Tracking areas (section 3.1 Cell Outage Adjustment: . Network accessibility and retainability are improved. ZTE.2) References [1] R3-072179.1.Optimization for Coverage Compensation -Required Measurement and Signalling Support templates.2) • Cell outage prediction (section 4. such as HO success ratio.4.1.3.Pilot Power . ZTE.Optimization for Coverage Compensation.Antenna tilt Cell A Cell C Adjustment: . and number of supported users are enhanced. China Mobile Page 69 (71) .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. Related use cases • Cell outage detection (section 4. capacity.SOCRATES Coverage Area Cell A Cell B Cell C D2. New SON use-case: Self.

due to the broad expertise in the SOCRATES consortium. detailed algorithms will be developed.2. For most use cases. it is clear that there will be many challenges for SOCRATES to develop solutions for these use cases. From the above. Page 70 (71) . • • Defining use cases is merely the first step towards developing solutions. These use cases cover many different aspects of the LTE radio interface. but few decisions have been made. These algorithms will then be assessed using advanced simulators. there are several related use cases. The SOCRATES consortium seeks opportunities to contribute to 3GPP based on the latter group of use cases. and prioritisation and selection of use cases for WP3 and WP4 will be done. a list of related use cases has been provided. In these work packages. This points at large interdependencies among the use cases. Significant advantages of employing SON functionality over current practice have clearly been pointed out.SOCRATES D2. This will be followed by the development of solutions in WP3 (Self-optimisation) and WP4 (Self-configuration and self-healing). 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. For some of the use cases. focusing on the 3GPP LTE radio interface. use cases for self-organising networks have been defined. The next step is to define requirements for the use cases. Other use cases have hardly or not at all been considered in 3GPP. In Activity 2. However. For each of the use cases. revealing significant potential for self-organisation in LTE networks. standardisation requirements are already being considered in 3GPP. SOCRATES is well placed to address these challenges.1 5 Concluding remarks In this document. in Activity 2. the interaction between the use cases will be studied in detail.4.

[1] 3GPP TR 36.3. “Evolved Universal Terrestrial Radio Access Network(EUTRAN). this section includes some general 3GPP and NGMN references.1 (2008-02).0 (2007-12). Overall description. Telecom Italia. "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN). “Telecommunication management.0. Vodafone Page 71 (71) .902 V0.816 V1.2 (2008-02).1 References In addition to the references included in the individual use case descriptions. Study on Management of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and Evolved Packet Core (EPC) (Release 8) ” [3] 3GPP TS 36. Telefonica.3.300 V8. “Informative list of SON Use Cases”. Self-configuration and self-optimizing network use cases and solutions (Release 8)” [2] 3GPP TR 32. T-Mobile. Stage 2 (Release 8)” [4] 3GPP S5-071944.SOCRATES D2.