Use Cases, Requirements and Assessment Criteria for Future Self- Organising Radio Access Networks Source: Socrates Project Consortium Thomas Kürner, TUBS
Outline • Project Overview • Use Cases • Requirements in SOCRATES • Technical requirements • Business requirements • Assessment Criteria • Metrics • Benchmarking approach • Conclusions Objective of this presentation is to provide an overview of the main activities of the requirements phase of SOCRATES
Project Overview Neil Scully SOCRATES-NGMN call Vodafone Group R&D September 17, 2008
PROJECT OVERVIEW • SOCRATES • Self-Optimisation and self-ConfiguRATion in wirelEss networkS • Project period • 3-year duration: From 01/01/2008 until 31/12/2010 • Effort • Number of person months: 378 • Total project costs: € 4,980,433 • Consortium
MAIN DRIVERS • Effectuate substantial OPEX reductions • minimise human involvement • Optimise network efficiency and service quality • Enhance robustness/resilience in case of failures
KEY ISSUES • Self-organisation in wireless networks • Self-configuration • e.g. ‘plug-and-play’ of new base Measurements Measurements stations (Gathering and processing) (Gathering and processing) • Self-optimisation • measurements, processing, continuous continuous parameter adjustment, … loop loop • continuous loop Self- Self- optimisation optimisation Setting Setting • Self-healing parameters parameters • failure detection • automatic minimisation of coverage/capacity loss Self- Self- configuration configuration Self- Self- healing healing • Focus on 3GPP LTE (E-UTRAN) triggered by triggered by incidental incidental events events
OBJECTIVES • Project objectives • Development of methods and algorithms for self-organisation • autonomous parameter adjustment • Specification of the required measurements • statistical accuracy, methods of retrieval, needed protocol interfaces • Validation and demonstration of the solutions • extensive simulation experiments • Assessment of the operational impact • e.g. radio network planning and capacity management processes • Input to 3GPP standardisation and NGMN activities • Quantitative character • Development of methods and algorithms • Quantitative assessment • simulation of scenarios • Contacts and cooperation • self-* issues, autonomous networking, … • FP7: E3, 4WARD, AUTOI, EFIPSANS, EURO-NF, …. • COST 2100 • 3GPP, NGMN, WWRF, … • …
ORGANISATION OF PROJECT WORK • Five work packages Requirements Requirements WP 2 WP 2 phase phase Use cases, requirements, assessment criteria and framework Use cases, requirements, assessment criteria and framework (VOD) (VOD) Development Development WP 3 WP 3 WP 4 WP 4 WP 1 WP 1 phase phase Self-optimisation Self-optimisation Self-configuration Self-configuration Project Project and self-healing and self-healing mgmt mgmt (EAB) (EAB) (NSN-D) (NSN-D) (TNO) (TNO) Integration Integration phase phase WP 5 WP 5 Integration, demonstration and dissemination Integration, demonstration and dissemination (IBBT) (IBBT)
WP2: USE CASES ANDS FRAMEWORK • Key objectives • Define the use cases for self-organising networks • Define the requirements and assessment criteria • Establish framework for development of self-organisation methods • determine functional groups of parameters to be self-optimised (‘functionalities’) • investigate relations between self-optimisation, -configuration and – healing • Main activities (January – August 2008) • A2.1: Generate a detailed list of use cases � � deliverable D2.1 � � • A2.2 / A2.3: Determine requirements and assessment criteria � � � � deliverables D2.2, D2.3 • Establish framework for development of self-organisation methods � � deliverable D2.4 � � • Updates of D2.1-D2.4 (framework) in March and December 2009
Use Cases Neil Scully SOCRATES-NGMN call Vodafone Group R&D September 17, 2008
USE CASES (SELF-OPTIMISATION) • Radio network optimisation • Interference coordination See D2.1 and D2.2 • 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 • Others • Reduction of energy consumption • Tracking areas • TDD UL/DL switching point • Management of relays and repeaters • Spectrum sharing • MIMO
USE CASES (SELF-CONFIGURATION AND -HEALING) See D2.1 and D2.2 • Self-configuration • Intelligently selecting site locations • Automatic generation of default parameters for NE insertion • Network authentication • Hardware/capacity extension • Self-healing • Cell outage prediction • Cell outage detection • Cell outage compensation
FOCUS IN WP3 AND WP4 • Already started • Cell outage detection and compensation • Coverage hole detection and compensation • Self-optimisation of home eNodeB • Load balancing • Interference coordination • Handover parameter optimisation • Packet scheduling parameter optimisation • To be started in February 2009 • Management of relays and repeaters • Admission and congestion control parameter optimisation • Automatic generation of default parameters for NE insertion • Links with NGMN/3gpp use cases
SOCRATES SON requirements Neil Scully SOCRATES-NGMN call Vodafone Group R&D September 17, 2008
Position of SOCRATES SON requirements NGMN Project 12 NGMN SON SON Recommendation on SON & O&M requirements SOCRATES Solution Development SOCRATES Requirements for Self-Organising Networks
Comparing NGMN and SOCRATES requirements • NGMN • SOCRATES • Output at end of two year • Input at start of project project • Describes procedure to be • Describes details of technical applied for solutions requirements • Specifies what the SON • Sets requirements for the algorithm should do performance and functioning of the SON algorithm Both documents are valuable input to SOCRATES
Categories of SOCRATES technical requirements Performance and complexity Stability Robustness Timing Interaction Architecture and scalability Required inputs
Technical requirements Performance and complexity Description Description Specification of performance gains that will be required. Specification of performance gains that will be required. Definition of limitations due to complexity issues. Definition of limitations due to complexity issues. Key finding Key finding The trade-off between performance and complexity The trade-off between performance and complexity will be crucial will be crucial Example Example Limitations on measurement related signalling overhead Limitations on measurement related signalling overhead
Technical requirements Stability Description Description The system should be stable in the sense that parameters The system should be stable in the sense that parameters do not continually change without reaching a final value do not continually change without reaching a final value Key finding Key finding Stability is important since many of the algorithms will run Stability is important since many of the algorithms will run completely automatic and without manual intervention completely automatic and without manual intervention Example Example Iterations of the algorithm should converge. Iterations of the algorithm should converge. Only significant changes should trigger the recalculation Only significant changes should trigger the recalculation of parameters. of parameters.
Technical requirements Robustness Description Description Specifies requirements for the ability of the algorithm Specifies requirements for the ability of the algorithm to deal with unexpected events to deal with unexpected events Key finding Key finding Missing, wrong or corrupted input (measurements) should Missing, wrong or corrupted input (measurements) should be detected or compensated by the algorithm be detected or compensated by the algorithm Example Example In case there are inaccuracies in the data the functionality In case there are inaccuracies in the data the functionality should perform such that performance is still satisfactory should perform such that performance is still satisfactory
Technical requirements Timing Description Description Timing constraints such as how often should a specified Timing constraints such as how often should a specified algorithm run and how fast must an algorithm react algorithm run and how fast must an algorithm react Key finding Key finding Timing requirements vary between use cases Timing requirements vary between use cases – timescales range from milliseconds to hours or days – timescales range from milliseconds to hours or days Example Example For load balancing, parameters need to converge on order For load balancing, parameters need to converge on order of minutes, as traffic load may change on a similar timescale of minutes, as traffic load may change on a similar timescale
Recommend
More recommend
