the context of the MEDIEVAL project

qualtaghblurtingMobile - Wireless

Dec 12, 2013 (3 years and 10 months ago)

86 views

Distributed mobility management in
the context of the MEDIEVAL project




MEVICO Final Seminar, part 2

23
rd

November 2012


Carlos J. Bernardos, UC3M

cjbc@it.uc3m.es



Video

is a major
challenge

for the future Internet










Current mobile Internet
IS NOT

designed for
video


Today’s architectures are very inefficient when handling video


Future
mobile Internet architecture

should be tailored to efficiently
support the requirements of this type of traffic


Specific
enhancements for video

should be introduced
at all layers

of
the
protocol stack where needed

Why MEDIEVAL?

Our Vision

LTE
Internet
LTE
WLAN
Local
Gateway
Local
Gateway
Mobile Network Provider
Video
Content
&
Services
Other Mobile
Network Providers
Internet TV
Personal
Broadcasting
local
mobility
global
mobility
Multimode
terminal
Video on
Demand
Interactive
video
Video
Content
&
Services
Content Provider
Evolutionary path for a truly
video
-
for
-
all philosophy

The Consortium

MEDIEVAL is an
operator
-
driven

project specifying
and demonstrating a
mobile video

architecture
with
cross
-
layer

mechanisms to provide high
quality of experience to users


Based on the Distributed Mobility Management
(DMM) paradigm


Integrating the mobility services with video content
distribution services


the DMM+CDN concept


Video caches are co
-
located with the mobility anchors of the

DMM architecture

DMM + CDN

MEDIEVAL has designed and is evaluating a

mobile Internet architecture
to efficiently support
the upcoming growth of
video services


Current Internet mobility schemes rely on a
centralized mobility anchor. E.g.:


Home Agent (HA)
in MIPv6


Local Mobility Anchor (LMA)
in PMIPv6


These entities are the cardinal node both for
control

and
data

plane


Hence they are prone to several problems and limitations


Longer (sub
-
optimal) routing paths


Scalability issues


Single point of failure


Lack of granularity on the mobility service

Why DMM?


The IETF community chartered a working group
called
Distributed Mobility Management

(DMM) to
develop new mobility solutions


http://datatracker.ietf.org/wg/dmm/

is the WG homepage


http://datatracker.ietf.org/doc/draft
-
ietf
-
dmm
-
requirements/

is the first WG document


http://tools.ietf.org/id/draft
-
bernardos
-
dmm
-
pmip
-
01.txt

is the network
-
based mobility solution
proposed by
MEDIEVAL


http://tools.ietf.org/id/draft
-
bernardos
-
mext
-
dmm
-
cmip
-
00.txt

is the client
-
based solution
proposed by MEDIEVAL


Distributed Mobility Management


The central anchor is
removed


The mobility services are pushed

towards the
edge of the network
,

offered in a distributed way

by the
access routers

The MEDIEVAL DMM solution


A new node is introduced


Mobility Access Router (MAR)


First IP
-
hop and default gateway seen by a

Mobile Node (MN)


It implements the following functionalities defined by
IETF standards:


Home Agent

(HA)


Mobile IPv6, RFC 6275


Local Mobility Anchor
(LMA)


Proxy Mobile IPv6,
RFC 5213


Mobile Access Gateway
(MAG)


Proxy Mobile IPv6,
RFC 5213

The MEDIEVAL solution


A set of interconnected MARs forms a

Localized Mobility Domain
(LMD)


Within the LMD, the mobility service is provided in a
network
-
based fashion (PMIPv6
-
like)


The MN is
not required

to update its new location


MARs learn about the MN’s movements by means of a
dedicated Layer 2 control infrastructure


IEEE 802.21 Media Independent Handover Services


The MNs’ mobility sessions are distributed among the
MARs


MARs exchange Proxy Binding Update and Acknowledgement
messages to update the MNs’ mobility sessions and set up the
appropriate routing


The MEDIEVAL solution


The handover is prepared, assisted and notified to
upper layers using a dedicated control plane:


IEEE 802.21 Media Independent Handover (MIH) Services


Make
-
Before
-
Break

handover


Radio link degradation detection


Resource availability query in surrounding

Points of Attachment (PoA)


Target selection and resource preparation before handoff


Detachment and attachment detection


Vertical (i.e., inter
-
technology) handover support


Drives the whole handover phase by means of
MIH users

running
in the terminal and in the network

Layer 2 Handover


When a Mobile Node attaches to a MAR it gets an IPv6 prefix
from the MAR’s prefix pool, with which it configures an
address topologically anchored at the MAR



The MN starts communications with

the just configured address



The MAR acts as standard IPv6

router for this flow


MN can send/receive traffic

with no packet encapsulation


IP mobility management (I)

Pref1::Addr1

MAR1

MAR2

MAR3


Upon moving to a new MAR, the MN gets another IPv6 prefix to configure
a new address


In order to maintain ongoing communication, the new MAR

sends a Proxy Binding Update message to the

previous MAR, indicating its own address

as the MN’s Care
-
of
-
Address (CoA)


The old MAR replies with a Proxy

Binding Acknowledgment message;

a tunnel is established between the

two MARs and flows can be delivered

to the MN’s new location

IP mobility management (II)

Pref1::Addr1

?

Pref2::Addr2

PBA

PBU

MAR1

MAR2

MAR3


This situation for the green flow recalls PMIPv6, given

that MAR2 acts as a MAG and MAR1 as the LMA



However, new communications

are started using the IP address

acquired from the MAR

the MN is currently attached to


The new flow does not

require tunnels nor special

packet handling

IP mobility management (III)

Pref1::Addr1

Pref2::Addr2

MAR1

MAR2

MAR3


When another handover occurs, the new MAR updates MN’s
location at all the MARs anchoring active flows




A PBU/PBA handshake takes place

with each of such MARs



Tunnels are moved/created

and the flows are redirected

IP mobility management (IV)

Pref1::Addr1

Pref2::Addr2

Pref3::Addr3

?

PBU

PBU

PBA

PBA

MAR1

MAR2

MAR3


The DMM protocol allows to benefit from the shortest path
from the MN to destination


Because a new IP address is used by the MN for new IP connections


Ongoing flows are maintained alive through the reachability

of old addresses








DMM + CDN (I)

Applying this concept to video streams,

MEDIEVAL
enhances the quality

of video delivery,

by following the principle that a MN should
download the video from the MAR

it is currently attached to


CDN nodes are
co
-
located with MARs


MARs are provided with video caches


Data delivery through HTTP progressive download


Video file fragmented into chunks, each chunk downloaded using HTTP


If the requested content is available locally, the MAR starts
sending it to the MN


During the video playback, if the MN moves to another MAR:


Current chunk is transferred using the mobility tunnel


Next chunks are downloaded from the new MAR

DMM + CDN (II)


The MN moves within a MEDIEVAL domain with heterogeneous
access technologies, consuming a video stream while having a
VoIP communication

1.
The MN starts being connected

with 3G to MAR1


The video is requested to the

video server


MAR1 intercepts the request and

sends the file to the MN

2.
The MN switches to
WiFi

and

connects to MAR2


The video is delivered by MAR2


The VoIP flow is anchored to MAR1

3.
The MN finally moves to LTE and MAR3


The behavior is replicated in the new access network







CDN nodes are
co
-
located with MARs


The MN is able to download the video from the MAR it is
currently attached to


DMM + CDN Demo


Mobile data traffic is expected to greatly increase in future
years (especially video)


Current mobility management solutions might not be able to cope
with such large amount of traffic


MEDIEVAL project’s objective is to design a mobile
architecture optimized for video transport


The mobility management follows a distributed and dynamic
approach


An hybrid scheme using both PMIPv6 and MIPv6 has been investigated as
basesline

for the development


The handover control is delegated to IEEE 802.21


Controllers in the MN and in the network have been introduced to
perform mobility at flow
-
level and on
-
demand

Conclusion

Thank you for the attention


Questions?




http://www.ict
-
medieval.eu/