Distributed mobility management in the context of the MEDIEVAL project

MEVICO Final Seminar, part 223rd November 2012

Carlos J. Bernardos, UC3Mcjbc@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

LTEWLAN

LocalGateway

LocalGateway

Mobile Network Provider

VideoContent & Services

Other MobileNetwork Providers

Internet TV

PersonalBroadcasting

localmobility

globalmobility

Multimodeterminal

Video onDemand

Interactivevideo

VideoContent & 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 amobile 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-requiremen

ts/ 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 wayby the access routers

The MEDIEVAL DMM solution

• A new node is introduced– Mobility Access Router (MAR)

• First IP-hop and default gateway seen by aMobile 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 aLocalized 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 withthe just configured address

• The MAR acts as standard IPv6router 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 MARsends a Proxy Binding Update message to theprevious MAR, indicating its own addressas the MN’s Care-of-Address (CoA)

• The old MAR replies with a ProxyBinding Acknowledgment message;a tunnel is established between thetwo MARs and flows can be deliveredto 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, giventhat MAR2 acts as a MAG and MAR1 as the LMA

• However, new communicationsare started using the IP addressacquired from the MARthe MN is currently attached to– The new flow does not

require tunnels nor specialpacket handling

IP mobility management (III)

Pref1::Addr1Pref2::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 placewith each of such MARs

• Tunnels are moved/createdand the flows are redirected

IP mobility management (IV)

Pref1::Addr1Pref2::Addr2 Pref3::Addr3?

PBU

PBUPBA

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 connectedwith 3G to MAR1– The video is requested to the

video server– MAR1 intercepts the request and

sends the file to the MN2. 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/