Executive Summary SOCRATES D2.1

Transcription

1 SOCRATES D2.1 INFSO-ICT SOCRATES D2.1 Use Cases for Self-Organising Networks Contractual Date of Delivery to the CEC: Actual Date of Delivery to the CEC: Authors: Neil Scully, Stefan Thiel, Remco Litjens, Ljupco Jorguseski, Renato Nascimento, Ove Linnell, Kristina Zetterberg, Mehdi Amirijoo, Chris Blondia, Kathleen Spaey, Ingrid Moerman, Irina Balan, Thomas Kürner, Andreas Hecker, Thomas Jansen, Jakub Oszmianski, Lars Christoph Schmelz Reviewers: Hans van den Berg, Andreas Eisenblätter Participants: VOD, TNO, ATE, EAB, IBBT, TUBS, NSN-PL, NSN-D Workpackage: WP2 Use cases and framework Estimated person months: 12 Security: PU Nature: R Version: 1.0 Total number of pages: 71 Abstract: The SOCRATES (Self-Optimisation and self-configuration in wireless networks) project aims at the development of self-organisation methods for LTE radio networks. Self-organisation comprises 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)

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

3 Authors Partner Name Phone / Fax / VOD Neil Scully Phone: Fax: Neil.Scully@vodafone.com Stefan Thiel Phone: Fax: Stefan.Thiel@vodafone.com TNO Remco Litjens Phone : Fax: remco.litjens@tno.nl Ljupco Jorguseski Phone: Fax: ljupco.jorguseski@tno.nl Renato Nascimento Phone: Fax: renato.nascimento@tno.nl EAB Ove Linnell Phone: Fax: ove.linnell@ericsson.com Kristina Zetterberg Phone: Fax: kristina.zetterberg@ericsson.com Mehdi Amirijoo Phone: Fax: mehdi.amirijoo@ericsson.com IBBT Chris Blondia Phone: +32 (0) Fax: +32 (0) chris.blondia@ua.ac.be Kathleen Spaey Phone: +32 (0) Fax: +32 (0) kathleen.spaey@ua.ac.be Ingrid Moerman Phone: +32 (0) Fax: +32 (0) ingrid.moerman@intec.ugent.be Irina Balan Phone: +32 (0) Fax: +32 (0) irina.balan@intec.ugent.be Page 3 (71)

4 TUBS Thomas Kürner Phone: Fax: Andreas Hecker Phone: Fax: Thomas Jansen Phone: +49 (0) Fax: +49 (0) NSN-PL Jakub Oszmianski Phone: Fax: NSN-D Lars Christoph Schmelz Phone: Fax: Page 4 (71)

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

6 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 Page 6 (71)

7 Table of Contents 1 Introduction Self-organisation in future radio access networks Use cases for self-organisation Self-configuration use cases Planning and deployment Intelligently selecting site locations Automatic generation of default parameters for NE insertion Non-radio Network authentication Hardware/capacity extension Self-optimisation use cases Radio network optimisation Interference coordination Self-optimisation of physical channels RACH optimisation Self-optimisation of home enodeb GoS/QoS related parameter optimisation Admission control parameter optimisation Congestion control parameter optimisation Packet scheduling parameter optimisation Link level retransmission scheme optimisation Coverage hole detection Handover related optimisation Handover parameter optimisation Load balancing Neighbour cell list Other Reduction of energy consumption Tracking areas TDD UL/DL switching point Management of relays and repeaters Spectrum sharing Self-healing use cases Cell outage management Cell outage prediction Cell outage detection Cell outage compensation Concluding remarks Page 7 (71)

8 1 Introduction Future communication networks will benefit from a significant degree of self-organisation. The principal objective of introducing self-organisation, comprising self-optimisation, self-configuration and selfhealing, is to effectuate substantial operational expenditure (OPEX) reductions by diminishing human involvement in network operational tasks, while optimising network efficiency and service quality. The SOCRATES (Self-Optimisation and self-configuration in wireless networks) project aims at the development of self-organisation methods to enhance the operations of LTE radio networks, by integrating network planning, configuration and optimisation into a single, mostly automated process requiring minimal manual intervention. SOCRATES primarily concentrates on wireless access networks, as the wireless segment generally forms the bottleneck in end-to-end communications, both in terms of operational complexity and network costs. As a consequence, the largest gains from self-organisation can be anticipated here. The 3GPP LTE (3rd Generation Partnership Project, Long Term Evolution) radio interface is the central radio technology in SOCRATES studies. This is because 3GPP LTE is the natural, highly promising and widely supported evolution of the world s most popular cellular networking technologies (GSM/EDGE, UMTS/HSPA). 1.1 Self-organisation in future radio access networks The envisioned operational process applied in self-organising radio access networks is illustrated by Figure 1. Measurements (Gathering and processing) continuous loop Setting parameters Selfhealing Selfconfiguration Selfoptimisation triggered by incidental events Figure 1 Envisioned self-optimisation and configuration process in future radio access networks. Consider a fully configured and operational radio access network and, somewhat arbitrarily, start at the depicted measurements phase. This phase indicates a continuous activity where a multitude of measurements are collected via various sources, including network counters and probes. These raw Page 8 (71)

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

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

11 2 Self-configuration use cases The self-configuration phase is generally seen as the first step within self-organisation, as it is the first occasion the system may adapt its set-up or parameters with regards to external influences. Within this document, self-configuration has been split into two subcategories: Planning and deployment (section 2.1) and Non-radio (section 2.2). We are also considering the following related use cases, which contain elements of self-configuration, but are listed elsewhere in this document. Self-optimisation of physical channels (section 3.1.2) Self-optimisation of home enodeb (section 3.1.4) Tracking areas (section 3.4.2) 2.1 Planning and deployment Intelligently selecting site locations Description Classification: Area of relevance: Self-optimisation (as input to self-configuration) Deployment This use case is a mixture of classical performance management and network planning tasks. The use case thereby consists of two parts: Detection phase: identification of performance degradations and coverage gaps by near real time analysis of respective performance data (e.g. call drops, neighbour relationships, handover failures etc.) Solution phase: by using information about existing infrastructure (installed NE types, cell size, transmission power, antenna orientation), a solution to overcome the identified shortcomings is generated, which could e.g. be o higher transmission power of existing cells o cell split o re-location of existing antenna o installation of additional NE(s) For the first two solutions, the system could also recommend a temporary re-configuration of dedicated NEs or cells if the performance degradation only occurs infrequently within dedicated time windows, e.g. few times per week for some minutes only. For the latter two solutions, a proposal for a new location is calculated, thereby using available geographical information or potential antenna locations. It is clear that this use case does not apply for the initial setup of a newly deployed network at least some installed base is necessary, otherwise the detection phase cannot work. Objective The main objectives for this use case are: Detect and identify performance degradations and coverage holes during operation (near real time), without requiring subsequent extensive calculation from aggregated performance measurements (usually on a weekly or monthly basis) Reduce reaction time on performance degradations to minimise service interruption Reduce manual effort for the optimisation of the network and coverage Scheduling (Triggers) The trigger for automated identification and selection of new site locations or enhancement of existing locations requires either a continuous or at least a periodical analysis of appropriate performance measurement data. The attainment of pre-defined or self-learned threshold values triggers the solution phase. For example, an operator could define a dedicated number of call drops in the affected area due to bad coverage or small bandwidth during daytime or busy hours as threshold. Page 11 (71)

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

13 Architectural aspects To establish the intelligent selection of site locations at least the following entities are required: Depending on the real-time requirements in the detection phase, corresponding real-time capable interfaces and data management systems at NE and OAM side may be required. A database that stores measurement results for a mid- to long term analysis, especially for periodical performance degradations Analysis tools for the identification of performance degradations and coverage holes from the acquired data A database that has all necessary background information available Solution tools (e.g. rules / policy-based, self-learning algorithms, etc.) that determine corresponding solutions by taking the available performance and background data Interfaces to self-configuration and self-optimisation systems to trigger necessary parameter modifications Interfaces to trouble ticket tools to trigger necessary hardware updates Already standardised interfaces 3GPP Itf-N (northbound interface of element manager towards network manager, e.g. for transfer of performance data) the Itf-N is the major standardisation topic of 3GPP SA5 (OAM) 3G LTE X2 interface (between enodebs) e.g. for the exchange of performance data to feed distributed cluster-based algorithms for the detection of coverage holes (see Actions Detection phase) Example (Informative description) See Introduction Potential gain Fast reaction on coverage holes and performance degradations, increasing customer satisfaction. Reduction of necessary manual effort (performance management) to identify coverage leaks and performance degradations, and to find appropriate solutions OPEX reduction. Related use cases Load balancing (section 3.3.2) GoS/QoS related parameter optimisation (section 3.2) Automatic generation of default parameters for NE insertion Description Classification: Area of relevance: Self-configuration Deployment Several approaches are possible for the introduction of network elements, reflecting an evolution from necessary manual intervention towards fully automatic introduction: Pre-configuration of network elements (e.g. manually on-site or in the factory): this approach actually describes today s situation, which shall be avoided in future due to its high expenses and necessary modifications on site. Pre-configuration of network elements with some default values, specific values are determined after initial boot: this approach could e.g. provide the network element with some standard or best-practice values before it is introduced in the network. The final network element (NE) and site-specific values then have to be assigned either manually or by automated configuration or self-optimisation mechanisms. No pre-configuration of network elements, specific configuration is determined and installed after initial boot: with this approach, the NE is delivered to the site completely without configuration, except for some standard software for initial NE start-up. The complete software and configuration is assigned during the self-configuration procedure, including radio settings, neighbourhood configuration etc. Hybrid solutions between these three approaches could also be applied. For the introduction of a new NE, several different types of parameters are to be assigned. While for some of these parameters it is not useful to provide default parameters, since the likelihood that they will have Page 13 (71)

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

15 Architectural aspects To establish default radio network parameter generation at least the following entities are required: A database that stores parameters from previous insertions or the current configuration A set of algorithms that calculate default parameters from this database A set of algorithms that selects a set of default parameters for a dedicated NE type during selfconfiguration process A module within the self-configuration process that handles the data exchange between NE and the default parameter module during self-configuration Already standardised interfaces No specific interfaces required apart from existing configuration management Example (Informative description) Examples are given in the Description part of this use case. Potential gain For the insertion of a new NE, the availability of default parameters can accelerate the self-configuration process significantly, since the self-optimisation of the radio parameters does not have to start at zero but already at a default configuration. The insertion can therefore be completed more quickly and reduces the necessary time efforts and thereby OPEX. Related use cases The listed use cases provide information which is required to generate the default parameters: Radio network optimisation: o Interference coordination (section 3.1.1) o Self-optimisation of physical channels (section 3.1.2) o RACH optimisation (section 3.1.3) GoS/QoS related parameter optimisation o Admission control parameter optimisation (section 3.2.1) o Congestion control parameter optimisation (section 3.2.2) o Packet scheduling parameter optimisation (section 3.2.3) o Link level retransmission scheme optimisation (section 3.2.4) Handover related o Handover parameter optimisation (section 3.3.1) o Load balancing (section 3.3.2) 2.2 Non-radio Network authentication Description Classification: Area of relevance: Self-configuration Deployment There exists growing set of topics that puts high challenges on the security architecture and concepts of future communication networks, including the corresponding OAM: the migration of the network and transport infrastructure towards all-ip (i.e. for the communication between all network endpoints, IP and Internet technologies and mechanisms are used, including transport, routing, security) the introduction of new technologies at the link layer (e.g. Metro Ethernet) site sharing and multi-vendor networks the outsourcing of network operations to 3 rd party companies by the operators the use of transport backbone networks from 3 rd party suppliers In comparison with the rather closed environments of today s 2G and 3G networks, the stated changes open up a large set of potential leaks for intrusion into the network, e.g. for data theft, DoS attacks, or the introduction of bogus nodes. With the introduction of home base stations, another potential risk appears for the operators, since these base stations are no longer under their physical control. Page 15 (71)

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

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

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

19 3 Self-optimisation use cases The importance of self-optimisation within the Socrates project can be seen by the fact that this section contains the most use cases. Self-optimisation use cases cover Radio network optimisation (section 3.1), GoS/QoS related parameter optimisation (section 3.2), Handover related optimisation (section 3.3) and Other (section 3.4) important use cases. The use cases provide a framework for adjusting network and equipment parameters on the basis of network measurements. All the use cases share the aim to improve on key performance indicators and to use the available network resources more efficiently. 3.1 Radio network optimisation Interference coordination Description Classification: Area of relevance: Self-optimisation Optimisation One of the main limiting factors for the performance of a mobile radio network is interference. Efficient management of interference can increase the efficiency of the system and improve the quality-of-service (QoS). As LTE systems employ OFDM, intra-cell interference between users is not an issue. Inter-cell interference does, however, clearly influence performance. Assuming that LTE will use a frequency reuse of one, therefore, interference will be high at the cell edge for loaded cells. This can potentially lead to low throughput and unsatisfactory QoS for users at the cell edge. Features such as frequency-selective scheduling shall schedule on resource blocks with low interference. However, on 3GPP forum it is believed that this alone is not sufficient, and further gains can be achieved by using SON techniques to further improve performance. This use case considers mainly macro/micro deployments. Interference issues for femto-cells are considered in a separate use case. Objective The main objectives for this use case are: Minimise the impact of inter-cell interference by managing the resources used in neighbouring cells Ensure good cell edge performance Maintain a fair balance between cell edge user performance and performance of users closer to enodeb: Ideally all users should have equal performance, but in practice it may not be efficient to give high throughput to cell edge users, at the expense of users closer to the enb. It is necessary to find the right trade-off. Consider QoS requirements of users when managing interference: for example, reducing the maximum transmit power for a non real-time user is likely to be more acceptable than doing the same for a real-time user. Consider both uplink and downlink Scheduling (Triggers) It is expected that interference control will operate based on continual monitoring of the network. Potentially it will be necessary to have both pro-active and reactive algorithms. Pro-active algorithms will monitor interference levels, and will take action before problems start to occur. However, in some cases the pro-active algorithm may not sufficiently avoid problems, and then a reactive algorithm will be necessary. Events that can trigger a reactive algorithm are: Dropped calls Low QoS Page 19 (71)

20 It is worth noting that Interference Control can be considered both a SON and an RRM (Radio Resource Management) functionality. Functionality that works on a timescale of less than seconds is generally considered to be RRM. However, algorithms that intelligently manage interference, and implement specific policies, are considered to be SON. Input source As input data to an interference control algorithm, the following information may be used: User QoS (throughput, delay, packet loss) User location (how close to cell edge based on pathloss measurement) Interference level for each resource block Load/Interference indicator from other cells List of parameters Parameters that may be modified by an interference control algorithm are: Sub-band transmit power Resource block transmit power Scheduler settings Power control settings Assignment of resource blocks to users Actions At this stage, it is not possible to specify detailed actions, as no algorithms have been defined yet. However, using a high level description, a possible process is: Monitor interference levels, QoS and load/interference status from neighbour cells Detect problems (e.g. high interference levels, QoS degradation) Take action to deal with problem, for example: o Switch to a fractional re-use scheme o Change maximum transmit power o Send indicators to neighbour cells Expected results Expected results are: Better data throughput Reduction in dropped calls Higher cell capacity Better cell edge performance, while maintaining spectral efficiency Higher user satisfaction (lower delays, jitters for real time traffic) Status in 3GPP For a distributed solution, the X2 interface will be used. Work is already ongoing in 3GPP to define signalling over this interface, but no decisions have been made yet. The focus so far has been on the uplink (3GPP R , R ), where indicators referred to as High Interference Indicator and Overload Indicator are being considered. Another method is presented in 3GPP R High Interference Indicator has been agreed during meeting in Sorrento. It was decided that the HII should be a bitmap with one bit per Physical Resource Block and that a cell can send HII with different, neighbour-cell specific contents to different neighbour cells. Overload Indicator is still discussed. Summary of companies positions can be found in 3GPP R For the downlink, some 3GPP contributions (3GPP R ) support the use of an indicator on the downlink, to be used to control transmit power. Other contributions (3GPP R ) see no gain from doing this. Current status is described in 3GPP R Measurements / parameters / interfaces to be standardised To support the interference control use case, the following standardised measurements are required: QoS measurements, per user (throughput, delay, packet loss) Estimation of user location (close to cell edge or not) Measurement of interference levels, both in uplink and downlink, per resource block Page 20 (71)

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