FreePDF XP File - FP7 SOCRATES · Focus on 3GPP LTE (E-UTRAN) Evolutionary approach Measurements (Gathering and processing) Self-optimisation Setting ... – Enhanced service availability

FP7 SOCRATES

FP7 SOCRATES

Hans van den Berg (TNO, NL)

Ljupco Jorguseski (TNO, NL)

Neil Scully (Vodafone, UK)

Informa SON Conference, London, 30 Nov – 1 Dec 2010

WWW.FP7-SOCRATES.EU

2

Hans van den Berg (TNO), Ljupco Jorguseski (TNO), Neil Scully (Vodafone)

1. SOCRATES Overview (15 min)

a) Background, approach, use cases

b) Main results

2. SON Concepts in SOCRATES (15 min)

Q&A (5 min)

3. SON Simulation Demo’s (30 min)

Q&A (10 min)

Outline

2/17

Hans

Neil

Ljupco

WWW.FP7-SOCRATES.EU

3


� 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

FP7 SOCRATES

WWW.FP7-SOCRATES.EU

4


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

� Evolutionary approach

Measurements(Gathering and processing)

Self-optimisation

Setting

parameters

Self-healing

Self-configuration

continuousloop

triggered by incidental

events

Measurements(Gathering and processing)

Self-optimisation

Setting

parameters

Self-healing

Self-configuration

continuousloop

triggered by incidental

events

FP7 SOCRATES: KEY ISSUES

WWW.FP7-SOCRATES.EU

5


SELF-ORGANISATION: EXPECTED GAINS (1/2)

� OPEX reductions …

– Primary objective!

– Network operations increasingly complex

– Less human involvement in

– Network planning/optimisation

– Performance monitoring, drive testing

– Troubleshooting

Coverage GSM

Coverage EDGE

Coverage UMTS

WWW.FP7-SOCRATES.EU

6


SELF-ORGANISATION: EXPECTED GAINS (1/2)

� … and CAPEX reductions …

– Efficiency improvement � delayed capacity expansions

– smart eNodeBs may however be more expensive

� … and performance enhancements

– Enhanced service availability (robustness, resilience), QoS

IMPACT OF 'SELF-HEALING'

0 20 40 60 80 100

TIME

LO

CA

L S

ER

VIC

E Q

UA

LIT

Y

SITEFAILURE

WITH SELF-HEALING:QUICK RECOVERY

TO TOLERABLE LEVEL

WITHOUT SELF-HEALING:DRAMATIC DROP

TO INTOLERABLE LEVEL

LO

CA

L S

ER

VIC

E Q

UA

LIT

Y

WWW.FP7-SOCRATES.EU

7


� Main objectives of SOCRATES

– Development of concepts, methods and algorithms for self-

organisation

– e.g. handover parameters, antenna parameters, admission control

parameters, …

– Specification of architectural requirements

– measurements, interfaces, protocols

– Assessment of the operational impact

– e.g. radio network planning, capacity management, …

SOCRATES: OBJECTIVES

WWW.FP7-SOCRATES.EU

8


FP7 SOCRATES

Overview

� FP7 SOCRATES

– Background

– Approach

– Use cases

– Results

WWW.FP7-SOCRATES.EU

9


SOCRATES: APPROACH (1/2)

9

Defining use cases, assessment criteria, reference scenariosand the framework

Developmentphase

Developing solutionsfor individual use cases

Integrationphase

Integrating use casesinto an overall solution

Requirementsphase O

VE

RA

LL

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

SOA

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

SOA

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

0 200 400 600 800 1000 1200 1400 1600 18000

20

40

60

80

100

120

140

160

180

200

104

35

scenario 3

t [s]

n u

nsatisfied u

sers

in n

etw

ork

reference

with load balancing

• Three phases

WWW.FP7-SOCRATES.EU

10


SOCRATES: APPROACH (1/2)

� Evolutionary approach towards self-optimisation

– Take current architecture as starting point

– Works quite well, when parameters are properly tuned …

– ‘Make’ existing functionalities ‘self-optimising’

– E.g. RRM mechanisms, …

– Determine actual need for self-optimisation by sensitivity analysis

– Algorithms for ‘automatic’ adaptation of parameters

– Required architectural modifications � impact on standardisation

– Measurements, interfaces, signaling, …

� Many ‘use cases’ defined and investigated

– Stand-alone functionalities

– Interacting functionalities

– coordination needed!

WWW.FP7-SOCRATES.EU

11


SOCRATES USE CASES (stand-alone functionalities)

11

Self-optimisation

Handover parameter optimisation

Self-configuration Automatic generation of initial params

Self-healing Cell outage management

SON enabler X-map estimation

Load balancing

Packet scheduling optimisation

Admission control optimisation

Interference coordination

HeNB handover optimisation

HeNB interference and cov. optimisation

WWW.FP7-SOCRATES.EU

12


SOCRATES USE CASES (integrated functionalities)

12

Self-optimisation

Admission Control and Handover Optimisation

Load balancing and Handover Optimisation

Macro & Home eNodeB Handover Optimisation

Packet Scheduling and Interference Coordination

� Combinations of use cases where there is either a control parameter conflict or an observability dependency

WWW.FP7-SOCRATES.EU

13


FP7 SOCRATES

Overview

� FP7 SOCRATES

– Background

– Approach

– Use cases

– Results

WWW.FP7-SOCRATES.EU

14


MAIN PROJECT RESULTS (1/2)

� Framework for development of self-organisation methods

– high-level guidelines, requirements, …

� Assessment criteria and methodologies

– OPEX, CAPEX, performance gains

– reference scenarios

� Self-organisation methods and algorithms for selected use cases

– stand-alone

– integrated

localrevenue

time

localrevenue

time

repair time

manualdetection

time

eNodeBdies

eNodeBrevived

repair time

regained revenue due tocell outage compensation

regained revenue due tocell outage detection otherwise

missedrevenueCASE WITH

SELF-HEALING

CASE WITHOUTSELF-HEALING

localrevenue

time

localrevenue

time

repair time

manualdetection

time

eNodeBdies

eNodeBrevived

repair time

regained revenue due tocell outage compensation

regained revenue due tocell outage detection otherwise

missedrevenueCASE WITH

SELF-HEALING

CASE WITHOUTSELF-HEALING

WWW.FP7-SOCRATES.EU

15


MAIN PROJECT RESULTS (2/2)

� SON coordination framework

– alignment of interacting SON functions

� Measurements, architecture & interfaces for SON

– based on use case studies, SON coordinator

� Demonstrations

– visualisation through simulation

– validation

� Implications of SON (ongoing work)

– network planning & operations

AUTOGNOSTICS

POLICY

ALIGNMENTIncl. Guard function

NETWORK SUBSYSTEM (e.g., eNB, neighbours, OSS, NMS)

OPERATOR

SONFUNCTIONS

POLICYinterface

performancequality metric

change requests

objectives

feedback onperformance

SON System

SONFUNCTIONS

SON

FUNCTIONS

SON

FUNCTION

specify data

requests

objectives & constraints

performance data

configuration

changes

performance data

feedback & constraints

control parameterinterface

raw measurements &configuration changes

Communication with peers

Note SON system will often be in the

eNB, but could be in any node

AUTOGNOSTICS

POLICY

ALIGNMENTIncl. Guard function

NETWORK SUBSYSTEM (e.g., eNB, neighbours, OSS, NMS)

OPERATOR

SONFUNCTIONS

POLICYinterface

performancequality metric

change requests

objectives

feedback onperformance

SON System

SONFUNCTIONS

SON

FUNCTIONS

SON

FUNCTION

specify data

requests

objectives & constraints

performance data

configuration

changes

performance data

feedback & constraints

control parameterinterface

raw measurements &configuration changes

Communication with peers

Note SON system will often be in the

eNB, but could be in any node

WWW.FP7-SOCRATES.EU

16


SOCRATES – DISSEMINATION OF PROJECT RESULTS

� Project deliverables, publications, presentations, …

� Organisation of workshops

– at ICT Mobile Summit 2009, Santander, June 2009

– joint SOCRATES / COST2100 workshops– Braunschweig, February 2009

– Athens, February 2010

� Demonstration stand at Future Networks & Mobile Summit 2010

– Florence, June 2010

� Interactions with NGMN

� Liaisons to 3GPP

– several contributions delivered and planned

http://www.fp7-socrates.eu

WWW.FP7-SOCRATES.EU

17


SOCRATES – FINAL WORKSHOP

WWW.FP7-SOCRATES.EU

18


1. SOCRATES Overview (15 min)

2. SON Concepts in SOCRATES (15 min)

a) Assessment Criteria

b) SON Coordination

Q&A (5 min)

3. SON Simulation Demo’s (30 min)

a) Home eNodeB

b) Handover

c) Load Balancing or Cell Outage Compensation

Q&A (10 min)

Outline

18/17

WWW.FP7-SOCRATES.EU

19


Outline

� Assessment criteria for self-organising networks

– Introduction

– Metrics

– Performance / Coverage / Capacity

– OPEX

– Benchmarking approach

� Coordination of SON use cases

– Overview

– Policy Function

– Alignment Function

– Guard Function

19

WWW.FP7-SOCRATES.EU

20


Introduction

� Why define assessment criteria?

– Evaluation of SON algorithms

– Comparing multiple algorithms: Which algorithm is best?

– Fine-tuning of an algorithm to optimise its performance

– Assessment of the gains that can be achieved using SON

– By comparison with manual network operation

– Essential part of development of algorithms

– But also useful for SON trials!

WWW.FP7-SOCRATES.EU

21


Metrics: Performance – Coverage – Capacity

Performance(GoS/QoS)

GoS (Grade of Service)Call blocking ratio, call dropping ratio, …

Coverage Service coverage, data rate coverage, …

CapacityMaximum supportable traffic load, spectrum efficiency, …

QoS (Quality of Service)Packet delay, packet loss ratio, transfer time, throughput, MOS, fairness, …

21

‘Conventional’ metrics, but important for SON

WWW.FP7-SOCRATES.EU

22


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

23


Determining OPEX savings – Methodology

� OPEX without SON1. Determine effort for an individual task

– Task is defined as optimising or adjusting a parameter or parameter set

2. Determine OPEX per task, per network, per year

– Cost per task (Euro) = Effort per task (days) × Cost per day (Euro)

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

� 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 completely autonomously:– Obtain the required inputs?

– Analyse the available data?

– Determine new parameter settings?

WWW.FP7-SOCRATES.EU

24


Benchmarking: Overall assessment

� Approaches to determine overall assessment:

– Single target metric, with constraints on the other metrics

– Combining different metrics using a utility function (with possible constraints on

additional metrics)

� Absolute gains:

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

SOA

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

OV

ER

AL

L

SOA

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOB

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOC

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

Go

S/Q

oS

RO

BU

ST

NE

SS

OP

EX

CA

PE

X

SOD

Operator invests very little

in manual optimisation

Operator invests a lot inmanual optimisation

Gain is mainly in

network quality

Gain is mainlyOPEX reduction

WWW.FP7-SOCRATES.EU

25


Why SON Coordination?

� The research and development work on SON has up to now concentrated on

stand-alone functions

� With an increasing number of SON functions, the likeliness of conflicting

goals and targets of the individual SON functions also increases

� The goal of SON coordination is to avoid or resolve potential conflicts, and

provide a single interface towards the operator regarding policies

SON

Function A

SON Function

B

MetricA

MetricB

P1

P2

P3

P4

SON

Function A

SON Function

B

MetricA

MetricB

P1

P2

P3

P4

SON Function

A

SON Function

B

Metric

A

MetricB

P1

P2

P3

P4

SON Function

A

SON Function

B

Metric

A

MetricB

P1

P2

P3

P4

Control Parameter Conflict Observability Dependency

WWW.FP7-SOCRATES.EU

26


SON Coordinator Framework - Overview

THE OPERATOR

NETWORK SUBSYSTEM

Policy Function

SON System

Guard Function

Alignment Function

Communi-cation with

Peers

Auto-gnosticsFunction

SON Functions

THE OPERATOR

NETWORK SUBSYSTEM

Policy Function

SON System

Guard Function

Alignment Function

Communi-cation with

Peers

Auto-gnosticsFunction

SON Functions

WWW.FP7-SOCRATES.EU

27


Policy Function

OperatorPolicy

FunctionSON Func. A

Policy

SON-specific policies – these change according to cell type

High-level performance

objectives, e.g., accessibility, retainability

Guard

Align-

ment

Auto-gnostics

SON Func. B

Policy

SON Func. C

Policy

OperatorPolicy

FunctionSON Func. A

Policy

SON Func. A

Policy

SON-specific policies – these change according to cell type

High-level performance

objectives, e.g., accessibility, retainability

Guard

Align-

ment

Auto-gnostics

SON Func. B

Policy

SON Func. B

Policy

SON Func. C

Policy

SON Func. C

Policy

WWW.FP7-SOCRATES.EU

28


Alignment Function

ArbitrationShort-term

driven, conflict

resolution

Network Subsystem

Trigger

SO

N

Fu

nctio

n

ActivationCause analysis, management of

SON functions

Policy Function

Alignment Function

Gu

ard

F

un

cti

on

Requests

Feedback,

Notifications,Settings, Start/Stop

Arbitration, Activation & Cause Analysis Settings

Confirmed Parameter Changes

ArbitrationShort-term

driven, conflict

resolution

Network Subsystem

Trigger

SO

N

Fu

nctio

n

ActivationCause analysis, management of

SON functions

Policy Function

Alignment Function

Gu

ard

F

un

cti

on

Requests

Feedback,

Notifications,Settings, Start/Stop

Arbitration, Activation & Cause Analysis Settings

Confirmed Parameter Changes

WWW.FP7-SOCRATES.EU

29


Guard Function

Guard

FunctionOscillation Detection

Absolute Performance Surveillance

Data request definitions

Align-

mentFunction

Auto-

gnosticsFunction

Policy

Function

Performance,Fault, Config. Data

Triggers

Settings for the detection of extreme network behaviour

Guard

FunctionOscillation Detection

Absolute Performance Surveillance

Data request definitions

Align-

mentFunction

Auto-

gnosticsFunction

Policy

Function

Performance,Fault, Config. Data

Triggers

Settings for the detection of extreme network behaviour

WWW.FP7-SOCRATES.EU

30


Questions

30/17

WWW.FP7-SOCRATES.EU

31


SOCRATES Simulation Demo’s

WWW.FP7-SOCRATES.EU

32


1. SON Simulation Demo’s

a) Handover

b) Load Balancing or Cell Outage Compensation

c) Self-optimisation of Home eNodeBs

Q&A

WWW.FP7-SOCRATES.EU

33


Handover self optimisation

� Possible handover problems:

– HPIHOF: Handover failures (too early, too late)

– HPIHPP: Ping-pong handovers

– HPICD: Call dropping

HP = w1HPIHOF + w2HPIHPP + w3HPICD

� Objective

– Minimization of HP via automatic adjustment of hysteresis and time to trigger (TTT)

Ping-pong

time

HO Drop

X

33/17

WWW.FP7-SOCRATES.EU

34


Handover self optimisation approach

� Off-line HO system behaviour

– System level simulations with different hysteresis and time-to-trigger

– Define operating region

34/17

� Derive on-line (self-) optimisation

– Start within the operating region

– Change HYS and/or TTT and measure handover performance (HP)

– If HP improved further change in same ‘direction’. Otherwise change in other ‘direction’. 1 2 3 4 5 6 7 8 9 100

0

Hysteresis [dB]

0.04

0.064

0.08

0.1

0.128

0.16

0.256

0.32

0.48

0.512

0.64

1.024

1.28

2.56

5.12

Legend

Possible HOP

Allowed HOP

WWW.FP7-SOCRATES.EU

35


Handover demo (Thomas Janssen, TU Braunschweig)

35/17

WWW.FP7-SOCRATES.EU

36


Load balancing self optimisation

� Possible load problems:

– Users concentrated in one cell i.e. unequal load distribution causing cell overload

– Users cannot be served with the required quality due to lack of resources

� Objective

– Load transfer from overloaded cell towards neighbour cells via automatic updates of HO offset

– Maximise number of satisfied users

SeNB TeNB

Hysteresis

Distance

SeNB TeNB

SeNB TeNB

LB HO offset

Hysteresish1

h2

WWW.FP7-SOCRATES.EU

37


Load balancing self optimisation approach

� Estimate DL and UL load at target cell after

load balancing

– Based on DL and UL SINR estimation

– UEs do not change location during load balancing

� Decide which and how many UEs from

overloaded cell should be transferred

� Decide which neighbour cells will accept the

overload traffic

� Adjust HO offsets and send HO commands

WWW.FP7-SOCRATES.EU

38


Load balancing demo (Szymon Stefanski, NSN)

WWW.FP7-SOCRATES.EU

39


Cell outage compensation self optimisation

39/17

� Cell outage problems:

– Lost of coverage

– Unsatisfactory users and lost of revenue

� Objective

– Coverage (partially) restored by neighbour cells via automatic updates of e.g. antenna tilt, or uplink open loop power control operating point P0

– Maximise number of served users under the constraint that UL and DL quality target at neighbour cells are above thresholds

WWW.FP7-SOCRATES.EU

40


Cell outage compensation self optimisation approach

QUL QDL

Quality target

checkL

� Measure UL and DL quality at neighbours

� Quality target check

– QUL <> QT,UL

– QDL <> QT,DL

� Adjust control parameters accordingly

– Decrease/increase DL power/tilt

– Decrease/increase P0

WWW.FP7-SOCRATES.EU

41


Cell Outage Compensation Demo (Mehdi Amirijoo, Ericsson)

WWW.FP7-SOCRATES.EU

42


HeNB handover optimisation: Introduction and scenario

� Handover optimisation in scenario with

open access Home eNodeBs (HeNBs)

� HeNBs are placed indoors, but provide

coverage to outdoor users

� The objective is to determine how to

effectively use open access HeNBs

– Reliability: Minimise dropped calls due

to bad SINR conditions at handover

– User experience: Maximise the

throughput that the user is experiencing

� Optimisation for HeNB scenario may be

different than for macro-only scenarioFigure shows best server based purely on signal strength

X (m)

Y (

m)

-200 -100 0 100 200 300 400 500 600 700-500

-400

-300

-200

-100

0

100

200

300

400

500

3x3 layout of HeNBs

3 sector macro site

WWW.FP7-SOCRATES.EU

43


Handover optimisation algorithm

� Statistics (HPI = Handover

Performance Indicator) used as input to

the algorithm are:

– Dropped call ratio (CDR)

– Ping-pong handover ratio (PPHR)

� Metrics are calculated separately for

each type of handover

– ‘X’ can be M (= Macro) or H (=Home eNodeB)

� Start values:

– PPHRThreshold = 0.1

– CDRThreshold = 0.1

– Hysteresis = 5 dB

– TTT = 320 ms (fixed)

PPHRX < PPHRThresholdX

CDRX > CDRThresholdX

Decrease CIOX by 1 dB

PPHRX > PPHRThresholdX

CDRX < CDRThresholdX

Increase CIOX by 1 dB

PPHRX < PPHRThresholdX

CDRX < CDRThresholdX

Decrease HPI thresholds by 0.02

PPHRX > PPHRThresholdX

CDRX > CDRThresholdX

Increase HPI thresholds by 0.02

Algorithm

WWW.FP7-SOCRATES.EU

44


Macro & HeNB – Simulation results – Call drop ratio (CDR)

SON activated – start values: Hyst=5 dB, TTT=320 ms

No SON – param. values: Hyst=3 dB, TTT=320 ms � Ping-pong handover ratio increases for macro-macro handover

� Ping-pong handover ratio is negligible for all other handovers

0 100 200 300 400 500 6000

10

20

30

40

50

60

70

80

90

Time (s)

Call

dro

p r

atio (

%)

Macro-macro CDR - No SON

Macro-macro CDR - SON activated

HeNB-HeNB CDR - No SON

HeNB-HeNB CDR - SON activated

Even with SON, HeNB handover performanceis still an issue (for the considered scenario)

WWW.FP7-SOCRATES.EU

45


Questions

45/17

WWW.FP7-SOCRATES.EU

46


Contact Details

� Hans van der Berg (TNO)– [email protected]

– +31 88 8667031

� Neil Scully (Vodafone)– [email protected]

– +44 7919 994699

� Ljupco Jorguseski (TNO)– [email protected]

– +31 88 8667154

� Thomas Jansen (TU Braunschweig)– [email protected]

� Szymon Stefanski (NSN)– [email protected]

� Mehdi Amirijoo (Ericsson)– [email protected]

46/17

Documents

FreePDF XP File - FP7 SOCRATES · Focus on 3GPP LTE (E-UTRAN) Evolutionary approach Measurements (Gathering and processing) Self-optimisation Setting ... – Enhanced service availability