Anthanassios Liakopoulos - GRNET- IPv6

7/31/2019 Anthanassios Liakopoulos - GRNET- IPv6

1/31

IPv6 Consideration in LTEIPv6 Consideration in LTE --

Autonomic Mobility (w PMIPv6)Autonomic Mobility (w PMIPv6)& Resource Management/& Resource Management/QoSQoS

19 May 2010 6th LTE WorldSummit 2010

Symeon Papavassiliou, Timotheos KastrinogiannisInstitute of Communications and Computer Systems (ICCS)

National Technical University of Athens (NTUA)

Mick Wilson, Zhaojun LiFujitsu Laboratories of Europe (FLE)

Athanassios LiakopoulosGreek Research & Technology Network (GRNET)

1


2/31

Outline

IPv6 Consideration in LTE

EFIPSANS Autonomic Extensions



3/31

Outline


Key Messages

Introduction to Mobile Packet Services Technical Challenges

Transitioning Strategies


3


4/31

Key Messages

IPv4 address depletion may impact business continuity (at least) formobile operators

LTE deployment could trigger the wide deployment of IPv6



5/31

Introduction to Mobile Packet Services

The logical network topology in LTE is rather simple

Packet Data Protocol (PDP) context is the link between the terminal

and the access router. Multiple entities such as eNodeB in LTE are IP aware but

transparently transfer UE traffic.

IPv6 interconnection services can be introduced without chan in the


existing infrastructure. Multiple entities such as HSS have to be upgraded in order to support

IPv6 interconnection services to UE.

5


6/31

Technical Challenges

LTE terminals need to maintain an IP address permanently

Current deployments involve either public IPv4 addresses or private

addresses plus NAT IPv4 address depletion becomes a significant challenge

Short term solutions


,

Address scalability challenges

Long term solution

Deploy IPv6 to LTE terminals and the infrastructure

Achieve interconnection of IPv6 terminals with the IPv4 Internet Address transitioning mechanisms challenges

6


7/31

Dual Stack IPv6/IPv4 Terminals

Use the appropriate PDP context to connect to an Internet nodesupporting the same IP stack

A dual stack PDP context will be possible in LTE In legacy infrastructures, a separate PDP context is required per stack



8/31

Extend the use of IPv4

Temporarily allocate IPv4 address to UE for accessing IPv4 services

A short term solution under the condition that

Use private addresses NAT444 or NAT464 Scalability issues has to be addressed

Some application simultaneously establish multiple connections, such as


.

The number of concurrent TCP/UDP connections per user may stress themobile providers NAT gateways

Operational considerations

Controlling NATs may be complex Introduction of new services/protocols may require changes in the NAT

Keep-alive messages for NAT drain the battery

Necessary for many applications such as Skype, Facebook IM, etc.

8


9/31

Deploy IPv6 to LTE terminals and the infrastructure

Traffic is gradually transported over IPv6

Challenges arise for interconnecting IPv6 UE to the IPv4 Internet

Use NAT64 + DNS64 translation mechanisms Stateless and statefull NAT64 flavours

More complex than NAT444


ec an sms st evo ve n

9


10/31

Conclusions (IPv6 consideration in LTE)

IPv6 services may be deployed (to same extend) today

IPv4/IPv6 coexistence is required for a period of time

Use IPv6 whenever possible, effect may be significant

Long term strategy should only involve IPv6



11/31

Outline


EFIPSANS Autonomic Extensions

Introduction to EFIPSANS GANA Framework

Autonomic Mobility with PMIPv6


esource anagemen an o

11


12/31

Introduction to EFIPSANS Who we are?

FP7 EU IP ProjectEFIPSANS (http://www.efipsans.org/)

EFIPSANS aims at exposing the features in IPv6 protocols that can be exploited for

designing autonomic networks and services. EFIPSANSs long term objective is to pursue and call for the standardization of the

specified autonomic behaviour specifications for diverse networking environments Contributes to ETSI ISG AFI (Autonomic network engineering for the self-managingFuture Internet)


What is GANA? Generic Autonomic Networking Architecture (GANA): An evolvable holistic

Architectural Reference Model for Autonomic Network Engineering and Self-Management within Node/Device and Network Architectures.

12


13/31

Generic Control Loop

Decision-making Element

(DE) - knows the goals andpolicies

Behaviour or Algorithmic

Scheme or Policy (1)Monitoring Information and/or

other Type of Information

(knowledge) (1)


Scheme or Policy (2)

Control

Loop

(generic)

Trigger or Execute a Behaviour orSelect an algorithmic scheme or Policy

to enforce on the managed entityUse the supplied

Information

HorizontalInformation/

Communicationflow

Other peer DE(s)

Views exposed tothe upper DE:

Informationknown only by

this DE

policies, goals andcommand statements

from its upper DE

A Decision-Element (DE)implements the decisionlogic that drives a control-


Managed Resource (1) or a Managed Automated

Task (1) such as a Networking Function e.g.Routing, implemented by a single protocol or diverse

protocols, which may employ diverse AlgorithmicSchemes or Policies

Monitoring Information and/or

other Type of Information(knowledge) (n)


Scheme or Policy (n)

A dedicated InformationSharing Component/

Function e.g. a Monitoring

Component/Function/Sensor or a DataBase

Managed Resource (n) or a Managed Automated

Task (n) such as a Networking Function e.g.Routing, implemented by a single protocol or diverse

protocols, which may employ diverse AlgorithmicSchemes or Policies

UpwardInformation

Suppliers

An Underlying Substrate e.g. Networking Function

Upward InformationSupply

Downward Information/Communication flow

Upward Information

Supply: Required for e.g.

Self-Learning/Discovery

Downward Information/Communication flow:

Required for e.g. processes such as Self-

Description, Self-Advertisement, etc

loop over its assigned

Managed Entities (MEs).

In GANA, self-*functionalities (such as self-configuration, -healing, -optimization, etc) are

functionalities implementedby a Decision Element(s).


14/31

Hierarchical Control Loops (Different Levels of Abstraction) In order for a node to control its behaviour in an autonomic manner, and thus take

decisions about most of its functionalities, specific control loops have to be defined

in a hierarchical approach

Network Control Loop: It manages and determines the overall behaviour of the networkaccording to policies imposed by a third party (manager) or co-operatively by the

components of the network itself.

Node Control Loop: It manages and determines the overall behaviour of the node,


imposed by the Network Control loop. Functions Control Loop: It abstracts a particular Networking Function(s) -such as

routing, forwarding, mobility management- and its associated mechanisms and controls all

the protocols and mechanisms/algorithms collectively abstracted by a particular

Networking Function

Protocol Control Loop: It can be used to realize autonomic-driven (monolithic) protocolsand control their corresponding operation and functionalities.

Decision-making Elements that drive Control Loops follow the same Hierarchyconsisting of four levels of autonomicity

14


15/31

Hierarchy, Peering and Sibling Relations between DEs

Hierarchical relationships: Alower level DE(s) is managed by

its upper level DE. Peering relationships:

Communication between DEs for

exchanging information.


entities are created or managed bythe same upper level DE.

15


16/31

Autonomic Mobility with PMIPv6

& Resource Management and QoS

Our Novel Goal

Self-optimisation of the intra-LTE andinter-RAT mobility parameters to the

current load in the cell and in the adjacent

cells can improve the system capacity and


SON in 3GPP LTE (Long Term Evolution)

network management and optimizationtasks.

Optimisation of cell reselection /

handover parameters to cope with the

traffic load and minimize the number of

handovers and redirections needed toachieve the load balancing.

16


17/31

Designing AutonomicsDesigning in 3GPP is a complex task i.e. Various Functionalities

Network Components

Signalling

Synchronization

.

Dont O timi e Current Networkin Functionalities via Autonomics


Design Theoretically-Sound Autonomic Mechanisms

Introducing autonomic attributes increases engineering complexity i.e.

Distributed Optimal Algorithms & Decision Making

Synchronization Communication Orchestration

Stability Scalability .

What is required is a common concrete designing language to set the

foundations of future autonomics.

17


18/31

The Role of GANA, What About Optimality?

From Describing to Deriving Autonomic Architectures


a clever autonomic mobile node.

e es gn.

NUM GANA

18


19/31

An Autonomic Mobility and QoS Management ArchitectureAutonomic Base Station

QoS Management Control

Loop at A Base Station (e.g.

JRM_DE)

Autonomic CDMA Base Station

Control Loop for Enabling

ARRM (A Resource Scheduler)

Mobility Management Control

Loop

MIPv6_DE PMIP6_DE

Autonomic CorrespondingNetwork Element


Autonomic MobileNodes Control Loop

for Enabling ARRM

under a CDMA

QoS Management Control Loop at A Mobile Node (SO_DE)

Autonomic Mobile Node

Autonomic MobileNodes Control Loop

for Enabling ARRM

under a WLAN

Mobile Node Main DE

Autonomic Mobile

Nodes Control Loop

for Enabling ARRM

under a LTE type of

access networks

Mobility Management Control

Loop at a Mobile Node

MIPv6_DE PMIP6_DE

Functionalities implemented by the corresponding

protocols

Horizontal Handoff

Vertical Handoff

Location Management

Network Discovery

Protocol Level DE, steering autonomic QoS-aware

resource allocation protocol in various types of

wireless access network

Autonomic Functionalities:

- Autonomic Joint Resource Management-Autonomic QoS-aware Network Selection

-Autonomic Connection Management

-Autonomic Mutlihoming

-Autonomic QoE support

19


20/31

Key Introduced Novelties & Autonomic MM and QoS Solutions Autonomic mobility management in tune with current 3GPP/SAE

interworking vision. Enhanced PMIPv6 based hierarchical mobility management scheme

efficient inter-system mobility support

Autonomic JOint resource allocation and Network Selection (AJONS) Autonomic Radio Recourse Management (ARRM) Optimization via a common

utilit based framework.


Proficient call admission control Joint resource management

Overall system utility-based load balancing leading to network revenuemaximization.

Enhanced Autonomic Functionalities Autonomic Connection Management (connection based handoff algorithm) Autonomic Enabled QoE Support.

20


21/31

Autonomic Mobility Management ArchitectureSetting the Playground

Enfacing mobility - related

functionalities via autonomicity.

MIPv6 & PMIPv6


Realizing a GANA compatible

mobility architecture.

Enabling and supportingautonomic resource allocation and

QoS functionalities.

The role of Mobility Management DE

1. Steers mobile nodes mobility related behaviours

2. Provides QoS/policy information to the network entities

that control radio/network resources (supporting

ARRM/AJONS functionalities).

21


22/31

Enhanced PMIPv6: Enhanced Network-Based Mobility

Management Mechanism

IPv6 NetworkIPv6 Network

LMA

MAG1 MAG2

MAR - Mobility Access Router

The MAR acts as an immediate access router whichprovides MNs IP mobility support.

It can be located in the radio access network when itis deployed in a wide area wireless communicationsystem.

Allows a MN to send packets as soon as it detects anew subnet link and allows the new access router to

deliver ackets as soon as it detects the MNs

60

70

80

90

100

doverLatency(ms)

FMIPv6

PMIPv6

E-PMIPv6

40

50

60

70

80

ndoverLatency(ms)

FMIPv6

PMIPv6

E-PMIPv6


MN MN

MAR1 MAR2 MAR3 MAR4attachment.

Main benefit:

Reduction in handover related signalling overhead,especially the tunnelling overhead over the air

Reduction in handover latency, and can providelossless handover for downlink data delivery

Protocol Overhead (air) Overhead (network) Number of Messages

FMIPv6 72 Bytes 86 bytes 5

PMIPv6 0 72 bytes 2

E-PMIP 0 116 bytes 4

Handover Signaling Overhead

30

40

50

10 12 14 16 18 20 22 24 26

Wireless Link Delay (ms)

Han

20

30

4 6 8 10 12 14

Router Distance Delay (ms)

H

22


23/31

Resource Control and QoS Management in Autonomic

Wireless NetworksThe Foundations:

QoS provisioning in autonomic CDMA cellular and WLAN networks under a Common Utility-BasedFramework

Adopt and exploit a commoncommon utilityutility basedbased frameworkframework in order to reflect in a unified normalized way various and oftendiverse users QoS prerequisites, under common optimization problems.

Devise proficient QoSQoS--awareaware autonomicautonomic flexibleflexible resourceresource managementmanagement mechanismsmechanisms.

Extend this framework to 3GPP/LTE.


max

,i b

max *

, { }

{ - }

i b bif resource allocation

else QoS triggered AJONS

>

The role of QoS DE.

Steers mobile nodes QoS related

behaviours

Harmonizing QoS-aware

functionalitites with mobility relatedactions

Autonomic Joint Network Selection

(AJONS)

23


24/31

A novel, autonomic, proficient call admission control and joint resource management

mechanism.

Applying a common utility based framework in order to reflect in a unified normalized way

various access networks type of resources, as well as different services QoS prerequisites.

Autonomic QoS-driven Joint Resource Allocation and

Network selection over Integrated Systems (I)


*

, avg b b C

,

k b

, ,argmax ( )b k k b

b C

B J

=

Step_1 Constantly monitors users services

performance and reacts to QoS-triggered events

(i.e. Step_3 of Autonomic Mobile Nodes Control

Loop for Enabling ARRM) or mobility triggered

events (i.e. Step_3 of Mobility Management

Control Loop).

Step_2 Obtains locally available networks

average equilibrium price per unit of resource,

disseminated from all networks cells in his

locality (i.e. ).Step_3 Computes the normalized profit per

resource unit for eachand selects the most

profitable network to handover/attach (i.e. cell B

in accordance to (4)).

Step_4 Disseminates this decision to lower

level control loops that execute the

attachment/handoff.

24


25/31

Autonomic JOint Network Selection (AJONS)Autonomic JOint Network Selection (AJONS)

0,8

0,9

1

orkUtility

1,4

Autonomic QoS-driven Joint Resource Allocation and

Network selection over Integrated Systems (II)


Overall average system utility

based performance

0,3

0,4

0,5

0,6

,

10 20 30 40 50 60 70 80 90 100 110 120 130

Time (s ec)

AverageJoin

tNet

AJONS

SDiff

NSA-INS

RSS

0,6

0,7

0,8

0,9

1

1,1

1,2

1,3

0 20 40 60 80 100 120

Time (sec)

UtilityLoadBalancingFactor

AJONS

Sdiff

RSS

NSA-INS

Utility Load Balancing Factor

1 1

1 1

CDMA WLAN

CDMA WLAN

N N

i j

i j

N U N U

= =

25


26/31

An online autonomic mechanism that allows users to express their (dis)satisfaction withrespect to their services quality of service.

Enabling QoE Functionalities via Autonomicity

From the service. to a GANA node.


Inc (+0.03 $ / min)

Dec (-0.02 $ / min)

Current Performance Level

Max Performance LevelStepwise Increasing Performance

& Corresponding Service Cost ($/min) Inc.

Feasibility of the Request

to users interface.

to a user-centric algorithm.

Dynamic Utility Adaptation

NUM Optimization

Feasibility&

Policies

Resource AllocationAdaptation

Pricing

26


27/31

MM_AN

MM_CL

VH_CL HH_CL

ARM: Advanced Routing Mechanism

CARD: Candidate Access Router Discovery

FHS: Fast Handover Scheme

IIS: Intelligent Interface Selection

MRF: Measurement Report Function

MTC: Mobile Terminal Control

NDF: Neighbor Discovery Function

PCRF: Policy and Charging Rules Function

QoSM: QoS Manager

MM_CN

MM_CL

VH_CL HH_CL

PCRF

Instantiating GANA into Current 3GPP/SAE


AR AP MH

QoSM -- MM

CARDNDF

FHS

MRF

LTEdriver

WLANdriver

WiMAXdriver

MTC

CARD IIS FHS

LTEdriver

WLANdriver

WiMAXdriver

27


28/31

Based on Current Sequential Diagrams

6. HO Request

4.

UE SourceRRC

MME/UPE

TargetRRC

SourcePHY/MAC

TargetPHY/MAC

5. Resource Setup

1. Provision of policy and restrictions

2. Measurement control2. Measurements

3. HO Decision

HO Required


10. Resource Setup ACK 11. HO Request ACK

12. HO

8

7. Admission Control

9. Admission Control

18. Release Resource

13.

15. HO Complete 16. HO Complete

17. Release Resource

. Resource Setup

CommandHO Command

14. L1/L2 signalling

28

GANA & S i l Di


29/31

GANA & Sequential Diagrams



30/31

Conclusions (EFIPSANS Autonomic Extensions) A architectural reference model for autonomic network engineering

and self-management is necessary

More focus may be given to design autonomic mechanisms (ratherthan optimizing existing ones)

Viable autonomic-based algorithms have already been proposed.



31/31

Thank youThank you


Anthanassios Liakopoulos - GRNET- IPv6

Documents

Transcript of Anthanassios Liakopoulos - GRNET- IPv6