Distributed mobility management in
the context of the MEDIEVAL project
MEVICO Final Seminar, part 2
23rd November 2012
Carlos J. Bernardos, UC3M
cjbc@it.uc3m.es
Why MEDIEVAL?
• 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
Our Vision
Evolutionary path for a truly video-for-all philosophy
Mobile Network Provider
Content Provider
Internet TV
Internet
Video
Content &
Services
Video
Content &
Services
Video on
Demand
Personal
Broadcasting
Local
Gateway
LTE
WLAN
Interactive
video
Local
Gateway
LTE
Multimode
terminal
local
mobility
global
mobility
Other Mobile
Network Providers
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
DMM + CDN
MEDIEVAL has designed and is evaluating a
mobile Internet architecture to efficiently support
the upcoming growth of video services
• 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
Why DMM?
• 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
Distributed Mobility Management
• 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-dmmrequirements/ 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-cmip00.txt is the client-based solution proposed by MEDIEVAL
The MEDIEVAL DMM solution
• 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 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
Layer 2 Handover
• 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
IP mobility management (I)
• 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
MAR1
– MN can send/receive traffic
with no packet encapsulation
Pref1::Addr1
MAR2
MAR3
IP mobility management (II)
• 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
MAR1
MAR3
MAR2
to the MN’s new location
PBU
PBA
?
Pref1::Addr1
Pref2::Addr2
IP mobility management (III)
• 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
MAR1
MAR2
Pref2::Addr2
Pref1::Addr1
MAR3
IP mobility management (IV)
• 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
MAR1
MAR2
PBA
PBA
MAR3
PBU
PBU
?
Pref2::Addr2
Pref1::Addr1
Pref3::Addr3
DMM + CDN (I)
• 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
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
DMM + CDN (II)
• 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 Demo
• 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
Conclusion
• 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
Thank you for the attention
Questions?
http://www.ict-medieval.eu/