Use Cases, Requirements and Assessment Criteria for Future Self- - - PowerPoint PPT Presentation

▶
use cases requirements and assessment criteria for future
SMART_READER_LITE
LIVE PREVIEW

Use Cases, Requirements and Assessment Criteria for Future Self- - - PowerPoint PPT Presentation

Feb 08, 2023 216 likes •670 views

Use Cases, Requirements and Assessment Criteria for Future Self- Organising Radio Access Networks Source: Socrates Project Consortium Thomas Krner, TUBS Outline Project Overview Use Cases Requirements in SOCRATES Technical

slide-1
SLIDE 1

Use Cases, Requirements and Assessment Criteria for Future Self- Organising Radio Access Networks

Source: Socrates Project Consortium Thomas Kürner, TUBS

slide-2
SLIDE 2

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

  • f the main activities of the requirements phase of SOCRATES
slide-3
SLIDE 3

Project Overview

SOCRATES-NGMN call September 17, 2008 Neil Scully Vodafone Group R&D

slide-4
SLIDE 4
  • 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

PROJECT OVERVIEW

slide-5
SLIDE 5

MAIN DRIVERS

  • Effectuate substantial OPEX reductions
  • minimise human involvement
  • Optimise network efficiency and service quality
  • Enhance robustness/resilience in case of failures
slide-6
SLIDE 6
  • Self-organisation in wireless networks
  • Self-configuration
  • e.g. ‘plug-and-play’ of new base

stations

  • Self-optimisation
  • measurements, processing,

parameter adjustment, …

  • continuous loop
  • Self-healing
  • failure detection
  • automatic minimisation of

coverage/capacity loss

  • Focus on 3GPP LTE (E-UTRAN)

KEY ISSUES

Measurements

(Gathering and processing)

Self-

  • ptimisation

Setting parameters Self- healing Self- configuration

continuous loop triggered by incidental events

Measurements

(Gathering and processing)

Self-

  • ptimisation

Setting parameters Self- healing Self- configuration

continuous loop triggered by incidental events

slide-7
SLIDE 7
  • 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, …
  • …

OBJECTIVES

slide-8
SLIDE 8
  • Five work packages

ORGANISATION OF PROJECT WORK

WP 1

Project mgmt (TNO)

WP 2

Use cases, requirements, assessment criteria and framework (VOD)

WP 3

Self-optimisation (EAB)

WP 4

Self-configuration and self-healing (NSN-D)

WP 5

Integration, demonstration and dissemination (IBBT)

Requirements phase Development phase Integration phase

WP 1

Project mgmt (TNO)

WP 2

Use cases, requirements, assessment criteria and framework (VOD)

WP 3

Self-optimisation (EAB)

WP 4

Self-configuration and self-healing (NSN-D)

WP 5

Integration, demonstration and dissemination (IBBT)

Requirements phase Development phase Integration phase

slide-9
SLIDE 9
  • 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

WP2: USE CASES ANDS FRAMEWORK

slide-10
SLIDE 10

Use Cases

SOCRATES-NGMN call September 17, 2008 Neil Scully Vodafone Group R&D

slide-11
SLIDE 11

USE CASES (SELF-OPTIMISATION)

  • 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
  • Others
  • Reduction of energy consumption
  • Tracking areas
  • TDD UL/DL switching point
  • Management of relays and repeaters
  • Spectrum sharing
  • MIMO

See D2.1 and D2.2

slide-12
SLIDE 12

USE CASES (SELF-CONFIGURATION AND -HEALING)

  • 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

See D2.1 and D2.2

slide-13
SLIDE 13

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
slide-14
SLIDE 14

SOCRATES SON requirements

SOCRATES-NGMN call September 17, 2008 Neil Scully Vodafone Group R&D

slide-15
SLIDE 15

Position of SOCRATES SON requirements

SOCRATES Solution Development NGMN SON Recommendation

  • n SON &

O&M requirements SOCRATES Requirements for Self-Organising Networks NGMN Project 12 SON

slide-16
SLIDE 16

Comparing NGMN and SOCRATES requirements

  • NGMN
  • Output at end of two year

project

  • Describes procedure to be

applied for solutions

  • Specifies what the SON

algorithm should do

  • SOCRATES
  • Input at start of project
  • Describes details of technical

requirements

  • Sets requirements for the

performance and functioning of the SON algorithm

Both documents are valuable input to SOCRATES

slide-17
SLIDE 17

Categories of SOCRATES technical requirements

Performance and complexity Stability Robustness Architecture and scalability Timing Required inputs Interaction

slide-18
SLIDE 18

Technical requirements

Performance and complexity

Description Specification of performance gains that will be required. Definition of limitations due to complexity issues. Description Specification of performance gains that will be required. Definition of limitations due to complexity issues. Key finding The trade-off between performance and complexity will be crucial Key finding The trade-off between performance and complexity will be crucial Example Limitations on measurement related signalling overhead Example Limitations on measurement related signalling overhead

slide-19
SLIDE 19

Technical requirements

Stability

Description The system should be stable in the sense that parameters do not continually change without reaching a final value Description The system should be stable in the sense that parameters do not continually change without reaching a final value Key finding Stability is important since many of the algorithms will run completely automatic and without manual intervention Key finding Stability is important since many of the algorithms will run completely automatic and without manual intervention Example Iterations of the algorithm should converge. Only significant changes should trigger the recalculation

  • f parameters.

Example Iterations of the algorithm should converge. Only significant changes should trigger the recalculation

  • f parameters.
slide-20
SLIDE 20

Technical requirements

Robustness

Description Specifies requirements for the ability of the algorithm to deal with unexpected events Description Specifies requirements for the ability of the algorithm to deal with unexpected events Key finding Missing, wrong or corrupted input (measurements) should be detected or compensated by the algorithm Key finding Missing, wrong or corrupted input (measurements) should be detected or compensated by the algorithm Example In case there are inaccuracies in the data the functionality should perform such that performance is still satisfactory Example In case there are inaccuracies in the data the functionality should perform such that performance is still satisfactory

slide-21
SLIDE 21

Technical requirements

Timing

Description Timing constraints such as how often should a specified algorithm run and how fast must an algorithm react Description Timing constraints such as how often should a specified algorithm run and how fast must an algorithm react Key finding Timing requirements vary between use cases – timescales range from milliseconds to hours or days Key finding Timing requirements vary between use cases – timescales range from milliseconds to hours or days Example For load balancing, parameters need to converge on order

  • f minutes, as traffic load may change on a similar timescale

Example For load balancing, parameters need to converge on order

  • f minutes, as traffic load may change on a similar timescale
slide-22
SLIDE 22

Technical requirements

Interaction

Description Requirements on interaction with other functionalities that impact on the function and performance of the use case Description Requirements on interaction with other functionalities that impact on the function and performance of the use case Key finding Alignment with other algorithms in own cell and surrounding cells is required, particularly relating to common parameters Key finding Alignment with other algorithms in own cell and surrounding cells is required, particularly relating to common parameters Example Algorithms affecting various aspects of radio resource management should be aligned Example Algorithms affecting various aspects of radio resource management should be aligned

slide-23
SLIDE 23

Technical requirements

Architecture and scalability

Description Algorithms centralised or decentralised, with resulting requirements for architecture, interfaces, and scalability Description Algorithms centralised or decentralised, with resulting requirements for architecture, interfaces, and scalability Key finding Architecture will depend on the use case. Scalability to large networks is important. Key finding Architecture will depend on the use case. Scalability to large networks is important. Example Standardised definition of performance counters will be required Example Standardised definition of performance counters will be required

slide-24
SLIDE 24

Technical requirements

Required inputs

Description What input is required by the algorithms, e.g., counters, measurements, is described Description What input is required by the algorithms, e.g., counters, measurements, is described Key finding Required inputs depend on the use case Key finding Required inputs depend on the use case Example As input to handover optimisation, information on which handovers have been performed, which ones failed etc. Example As input to handover optimisation, information on which handovers have been performed, which ones failed etc.

slide-25
SLIDE 25

Technical requirements – Final remarks

  • Although requirements were defined for use cases individually,

many use cases have very similar requirements

  • The same principles apply to many use cases
  • Details vary between use cases
  • It is acknowledged that the current requirements are an initial set
  • Requirements will be refined and added to as SOCRATES progresses
slide-26
SLIDE 26

Business requirements

LTE deployment

Speed up roll-out of LTE networks Easily solving problems to ensure network quality Simplify processes Solve real problems

  • ccurring in real networks

Do not introduce other manual efforts No extra effort required to set up SON functionality Easy deployment of new services Meet QoS requirements

  • f new services

Deployment trends Impact of network sharing should be considered End user benefits User should experience high GoS and QoS

slide-27
SLIDE 27

Key messages

SOCRATES requirements have been defined to enable development of solutions Uniformly defined requirements ensure that all types of requirements are addressed Many use cases have similar requirements, with differences in the details Business requirements should also be considered SOCRATES requirements complement NGMN work

slide-28
SLIDE 28

Assessment criteria for SON

SOCRATES-NGMN call September 17, 2008 Neil Scully Vodafone Group R&D

slide-29
SLIDE 29

WWW.FP7-SOCRATES.EU 29

Introduction

  • SOCRATES objectives:
  • Evaluation of the SON algorithms that will be developed
  • ‘Which algorithm is best’ if more than one algorithm for a use case
  • Assessment of the gains that can be achieved using SON
  • By comparison with manual network operation
  • Metrics and assessment approaches have been defined
slide-30
SLIDE 30

Metrics: Performance – Coverage – Capacity

Performance (GoS/QoS) GoS (Grade of Service) Call blocking ratio, call dropping ratio, … Coverage Service coverage, data rate coverage, … Capacity Maximum supportable traffic load, spectrum efficiency, … QoS (Quality of Service) Packet delay, packet loss ratio, transfer time, throughput, MOS, fairness, …

WWW.FP7-SOCRATES.EU 30

slide-31
SLIDE 31

Metrics: OPEX

  • OPEX reduction is often quoted as an important SON gain
  • Important to be able to quantify the impact
  • In the SOCRATES approach:
  • OPEX without SON is determined by summing together all

components that contribute to OPEX

  • OPEX with SON is determined by assessing impact on various

components

  • Difference is then assessed

WWW.FP7-SOCRATES.EU 31

slide-32
SLIDE 32

Determining OPEX – without SON

  • 1. Determine cost of an individual task
  • Task is defined as optimising or adjusting a parameter or parameter set
  • Effort per task (days) = A + B + C
  • A = Gathering input info (e.g. planning tools, PM counters, drive tests)
  • B = Determine new settings (e.g. manual, computer assisted by planning

tool/simulator)

  • C = Apply new settings (e.g. automatic processes, site visits, etc)
  • Cost per task (Euro) = Effort per task (days) × Cost per day (Euro)
  • 2. Determine OPEX per task, per network, per year
  • OPEX per task / year =

(Cost per task) × (#Changes per network) × (#Changes per year)

  • 3. Determine total OPEX per year
  • OPEX / year = SUMall-tasks(OPEX per task / year)

WWW.FP7-SOCRATES.EU 32

slide-33
SLIDE 33

Determining OPEX – with SON

  • OPEX with SON: use the same method as for without SON,

but assess impact on different components

  • In some cases OPEX may be reduced to zero, but definitely not

always

  • Can the SON algorithm run completely autonomously:
  • Obtain the required inputs?
  • Analyse the available data?
  • Determine new parameter settings?

WWW.FP7-SOCRATES.EU 33

slide-34
SLIDE 34

OPEX – Final remarks

  • The main challenge will be the exact quantification of efforts

and costs

  • Less critical for assessment of relative gains
  • It is acknowledged that the described method is a

simplification of the reality

  • Purpose of the model is to enable assessment

WWW.FP7-SOCRATES.EU 34

slide-35
SLIDE 35

Metrics: CAPEX – Number of sites

  • Specify a scenario
  • System parameters
  • Traffic/mobility, incl. traffic load per km2
  • QoS/GoS requirements
  • For both the case with and without SON:
  • Determine maximum cell size, such that QoS/GoS requirements

are still met

  • CAPEX is determined based on the number of sites needed

including costs for backhaul and core network elements

WWW.FP7-SOCRATES.EU 35

slide-36
SLIDE 36

Metrics: CAPEX - Equipment

  • Increased equipment costs
  • Computational complexity
  • Network bandwidth requirements
  • Extra backhaul capacity for SON
  • Additional site equipment
  • E.g. electrical antenna tilt
  • The main challenge will be the exact quantification of

increased equipment costs Effect on CAPEX will be a combination of reduced number of sites and increased equipment cost per site

WWW.FP7-SOCRATES.EU 36

slide-37
SLIDE 37

WWW.FP7-SOCRATES.EU 37

  • Self-optimisation
  • Clear CAPEX/OPEX gains
  • Variation between use cases
  • Self-configuration
  • OPEX gain is clear
  • Reduction of manual effort for roll-out of a new eNodeB
  • CAPEX gain?
  • No clear gains
  • Self-healing
  • OPEX gain?
  • Most OPEX is in fixing the site, which remains manual
  • CAPEX gain?
  • No clear gains

Discussion CAPEX and OPEX

slide-38
SLIDE 38

Benchmarking approach

  • Various metrics have been defined
  • Questions still remain:
  • How to determine which SON algorithm is best?
  • How to assess gain compared to manual operations?
  • Benchmarking approach has been defined

WWW.FP7-SOCRATES.EU 38

slide-39
SLIDE 39

WWW.FP7-SOCRATES.EU 39

  • 1. Specify a scenario
  • 2. Consider different self-optimisation algorithms (SOA, SOB, SOC,

SOD)

  • 3. Evaluate all metrics for each algorithm
  • 4. Determine overall ranking:
  • Combining different metrics using a utility function
  • Single target metric, with constraints on the other metrics

Benchmarking: Comparing different algorithms

SOA

GoS/QoS COMPLEXITY OPEX CAPEX GoS/QoS COMPLEXITY OPEX CAPEX

SOB

GoS/QoS COMPLEXITY OPEX CAPEX

SOC

GoS/QoS COMPLEXITY OPEX CAPEX

SOD

slide-40
SLIDE 40

WWW.FP7-SOCRATES.EU 40

  • 1. Specify a scenario
  • 2. Consider different SO and MO (manual optimisation)

approaches

Benchmarking: Absolute gains from SON

SOA

OPEX CAPEX OPEX CAPEX

MOD

Self-optimisation Manual optimisation

Assess e.g. OPEX/CAPEX gains

  • f SOA with regard to benchmark MOD

OPEX gain CAPEX gain

slide-41
SLIDE 41

WWW.FP7-SOCRATES.EU 41

Benchmarking: Comparing algorithms

SOA SOB SOC SOD MOA

  • MOB

+

  • MOC

++ +

  • MOD

+++ ++ + SOA SOB SOC SOD ++++ +++ ++ +

CAPEX GAINS OPEX GAINS

quality

  • riented
  • perator

cost

  • riented
  • perator

Operator invests very little in manual optimisation Gain is mainly in network quality Operator invests a lot in manual optimisation Gain is mainly OPEX reduction

slide-42
SLIDE 42

Key messages

Assessment of SON requires the introduction of OPEX and CAPEX metrics Benchmarking is required to obtain an overall assessment The most relevant metrics depend on the use case Absolute gains depend on current operator approach Assessment of gains is an important part

  • f the development of SON algorithms

WWW.FP7-SOCRATES.EU 42

slide-43
SLIDE 43

Conclusions and Future Work

  • Identification of use cases, requriements and assessment

criteria for future self-organising radio access networks

  • Basis for a framework for the development of SON methods

and algorithms

  • Relation an dependencies between different SON requirements
  • SON algorithms for the identified use cases will be

developed

  • Taking into account the identified requirements
  • Evaluated using the proposed algorithms

More detailed results will be presented at the Joint COST2100 SWG3.1/SOCRATES Meeting in February 2009 at Braunschweig

slide-44
SLIDE 44

Reference

  • More info:
  • SOCRATES deliverable D2.1 – “Use case for self-organising

networks”, available via www.fp7-socrates.eu SOCRATES

  • SOCRATES deliverable D2.2 ‘Requirements for Self-Organising

Networks’, available via www.fp7-socrates.eu

  • SOCRATES deliverable D2.3 – “Assessment criteria for self-
  • rganising networks”, available via www.fp7-socrates.eu
  • Contact:

Remco Litjens remco.litjens@tno.nl +31 06 5191 6092

WWW.FP7-SOCRATES.EU 44