Seamless Roaming

Adrian Popescu, David Erman, Dragos Ilie, Markus Fiedler, Alex Popescu, Karel de Vogeleer

Blekinge Institute of TechnologyKarlskrona, Sweden

October 2008

2

OutlineIntroductionDefinitionGoals and RequirementsShort HistoryMain ChallengesTypes of HandoversStandard BodiesL2/L3 HandoverHandover OperationsIEEE 802.21 MIHInternet MobilityMobility ManagementConnectivity ManagementIMS InterworkingROVERResearch ChallengesSeveral Important ResultsConclusionsReferences

3

IntroductionCurrently, three important developments in telecom

Irreversible move towards IP- and SIP-based networkingDeployment of broadband (wireless) access, e.g., ADSL2+, FTTH, WLANExpansion of mobile communication systems, e.g., UMTS. WLAN, WiMAX

Consequence

Appearance of more advanced and more bandwidth-demanding applications

New paradigms for the next generation mobile communication

Always best connected and securedE2E seamless service delivery

Handover (HO) has been implemented, so far, within

Cellular networksMIP networks, and In media access dependent ways in IEEE 802 networks

Standard bodies: IEEE, 3GPP, 3GPP2, WiMAX, IETF

4

Introduction (cont’d)Traditional HO management was done by using radio specific mechanisms placed at Layer 2 - L2

Recent research and development based on pushing the HO functionality up to

IP layer – L3 (e.g., MIP and FMIP) to easy up the convergence of different technologiesApplication layer mobility – L5, by using the application protocol SIP

An important consequence is the need for cross-layer interaction, e.g., between IEEE 802 MAC/PHY and a “roaming” L3

New solution advanced by BTH: pushing more HO functionality higher up to the application layer – L5

5

Definition Seamless RoamingDefinition

Ability that a user roams in a secure way across different networks while keeping connected and not disturbing ongoing sessions and conversations.

Every specific session has own requirements regarding “non disturbance” state with reference to, e.g., error rate, delay, jitter, security, etc.

6

Goals and RequirementsFundamental goals

Secured and seamless HOMake the heterogeneous network transparent to the user Design the system architecture such as it is independent of the (wireless) access technologyFlexibility

Other requirements

Mobility management: access network location, seamless HO, paging and registration, security provision, policy-based HOProvision of QoS, user and network security, billing, etc.Efficient configuration selection

7

Short HistoryInitial model

Develop common standards across IEEE 802 mediaDefine L2 triggers to make FMIP work wellDefine media independent information to enable cellular/laptop to effectively detect and select networksDefine a way to transport this information and these triggers over all IEEE 802 media

But people wanted cellular inter-working as well; also, wired + wireless was desired with security protection

Consequence: 802.11 and 802.16 802.21

IMS upcoming

Need for better prediction mechanisms

8

Main ChallengesTCP/IP stack was not designed for mobility but for fixed computer networks

Responsibility of individual layers is ill-defined with reference to mobilityConsequence: problems in lower layers may create bigger problems in higher layersHigher layer mobility schemes are likely to better suit Internet mobility

Heterogeneity existent today with reference to

Access networksWireless communication systemsStandard bodiesStandardsArchitectural solutions

Other important problems

Lack of interoperability between different types of vendor equipmentLack of standard for handover interfacesLack of techniques to measure and assess the performance (including security) Incorrect network selectionIncreasing number of interfaces on devicesPresence of different fast handover mechanisms in IETF, e.g., MIPv4, FMIPv6IETF anticipated L2 solutions in standardized form (in the form of triggers, events, etc), but today the situation is that we have NO standards and NOR media independent formUse of L2 predictive trigger mechanisms, which are dependent of L1 and L2 parameters

9

Types of HandoversHorizontal/homogeneous handovers

Within single networkLocalized mobilityLimited facilities

Vertical/heterogeneous handovers

Across different networksGlobal mobilityMore opportunistic

10

Standard Bodies

Handover standards

11

L2/L3 Handover

Handover operation

HO initiation

Network and resource discovery

Network selection

Network attachment

Configuration (identifier configuration; registration; authentication and authorization; security association; encryption)

Media redirection (binding update; media rerouting)

12

L2/L3 Handover (cont’d)Single interface radio

Horizontal handoverRisk for service disruptions when

Performing channel scanning and obtaining QoS information from neighbor PoAsDoing L2 switching and new connection setup, including network entry and route update

Multiple interface radio

Vertical handoverNo link disconnection during the handover procedureExchange of L2 frames, with the consequence of risk for large delaysExchange of L3 MIPv6 messages to update route information

13

L2/L3 Handover (cont’d)HO type (horizontal or vertical) and time needed to perform it are determined with the help of

Neighbor network information provided by the Base Station (BS)Access Point (AP), and 802.21 Media Independent Handover Function (MIHF) Information Server (IS)

The Link Going Down (LGD) trigger should be invoked PRIOR to an actual Link Down (LD) event by at least the time required to prepare and to execute a HO procedure

LGD trigger and prediction

Too late LGD trigger – current link may break before a new link is setupToo early LGD trigger – loss of a “working”connection; unnecessary roll-backs of HO cancellations

Big challenge

How to timely generate a LGD trigger that takes into consideration neighboring network conditions and dynamic channel characteristics

Least Squared Mean (LSM) linear prediction is used to predict expected Link Down (LD) time

14

L2/L3 Handover (cont’d)Main problems L2/L3 handovers

Lack of cross-layer interaction between L2 and L3L2 and L3 operate independently of each otherDependence on the limitations of L1, L2, and L3

FMIPv6 attempts to reduce this problem by using reliable prediction of HO to enable proactive configuration of the involved nodes

Different MIPv6 versions: Fast MIPv6 (FMIPv6); Hierarchical MIPv6 (HMIPv6); Fast Hierarchical MIPv6 (FHMIPv6)

Further performance improvements can be obtained by allowing L3 to have control over certain L2 HO related actions

Conclusion: strong need for further research on cross-layer management!

15

Handover Operations

Direct media routingEncapsulation tunnelingIAPPMedia routing

SIP re-inviteUpdate CN, HACache updateBinding update

SIP registrationARP DADMAC addressAddress uniqueness

URIDHCP statelessESSIDConfiguration

TLS SRTPIPSEC802.11iSecurity association

S/MIMEIKE, PANAEAPoLAuthentication

Domain advertisementRouter advertisementScanningDiscovery

L5L3L2HO operation

16

IEEE 802.21 MIHPurpose

Optimize L3 and above handoversActs across 802 networks and extends to cellular networks (802.3; 802.11; 802.16; cellular) 802.21 MIHF IS server has information about, e.g., location of PoA, list of available networks, cost, L2 information (neighbor maps), higher layer services (ISP, MMS ..)

Key benefits

Optimum network selectionSeamless roaming Low power operation for multi-radio devices

Types of HO

Terminal ControlledNetwork Initiated, Network AssistedNetwork Initiated, Network Controlled

17

IEEE 802.21 MIH (cont’d)

Scope of IEEE 802.21IEEE 802.21 and IETF

18

Internet MobilityBasic functional requirements for mobility support

HO and location managementMulti-homing supportSupport for current services and applicationsSecurity

Limitations of TCP/IP

Limitations of Physical and Link Layer (radio channels show limitations compared to fixed networks)Limitations of IP address, it plays the role of both locator and identifierLack of cross-layer awareness and cooperationLimitations of applications (improper design for mobile environments, e.g., DNS, SIP)Limitations when using different mobility protocols in MN and in network

Performance metrics relevant for Internet mobility

HO latencyPacket lossThroughputSignaling

19

Extending TCP/IP for MobilityMobility support at L3

MIPv4; MIPv6; FMIPv6; HMIPv6; FHMIPv6; LIN6; …

Mobility support at L4

Improving TCP performance for mobility: Indirect TCP (I-TCP); Mobile TCP (MTCP)Mobility extension to TCP: TCP Redirection (TCP-R); TCP Migrate (TCP-M); MSOCKS; Mobile UDP (M-UDP); Mobile SCTP (MSCTP); …

New layer between L3 and L4

Host Identity Protocol (HIP); Multiple Address Service for Transport (MAST);

Mobility support at L5

Session Initiation Protocol (SIP); Dynamic Updates in the DNS (DDNS); BTH; …

20

MIPv4Main drawbacks

Triangular routing, with risk for large delaysRisk for service interruptions due to large delays in HA registrationIncreased signaling overload

Suggested improvements

Routing optimizationsUse of predictionHierarchical schemesBetter paging systems

21

MIPv6Two types of L3 mobility

Mobile controlled (MC)Network controlled (NC)

MC demands for mobility stack/client in MN (CMIPv6)

MC drawbacks: demand for more resources in MN

NC demands for networking units in network

NC drawbacks: limited mobility domain; use of proxies in the network (PMIPv6)

22

LIN6Basic idea: separation of ID and locator in the IPv6 addressLIN6 ID is used as node IDMore tolerant to errors than MIPv4/MIPv6Less overhead

LIN6 operationLIN6 protocol stack

23

MSCTPMobile Stream Control Transmission Protocol

Recently developed IETF transport protocol (RFC 2960)

Used together with IPSec or Transport Layer Security (TLS) to protect against insecure environments

24

HIPHost Identity ProtocolDesigned by the IETFBasic idea: separation of location from identityProtection against DoS and other security attacks

HIP operationHIP protocol stack

25

SIP Session Initiation Protocol

Developed by IETF as an application-layer multimedia signaling protocol (RFC 3261)

Drawback: risk for HO delay and overload

Solution: use of prediction

26

DDNSTraditional DNS is restricted in mobile Internet

DDNS: Dynamic Update of DNS

Developed by IETF (RFC 2136)

27

Functions of Mobility Paradigms

28

Required Changes

29

Mobility ManagementTwo major elements

Location managementHO management

Location management

Refers to the process used by a network to find out the current attachment point of a mobile userTwo phases involved, namely location registration/update and paging

HO management

Refers to the way the network acts to keep mobile users connected when they move and change their position and access points in the network

Situation today: static algorithms used for Location area (LA) update, no adaptation used to follow the mobility characteristics of the mobile node

Better performance expected by using dynamic location update mechanisms and paging algorithms

Basic idea: consider user mobility and accordingly optimize the signaling cost associated with location update and paging

The goal is to reduce the costs associated with these mechanisms to a minimum

30

Mobility Management (cont’d)Location modeling

One- or two- or three-dimensionsLevels: location area (controlled by a Mobile Switching Center MSC); cell ID; position inside the cell (geo-location problem)

Identity of mobile users and the associated billing information is stored in

Home Location Register (HLR), respectively Visitor Location Register (VLR)

Dynamic algorithms for location update

Distance-basedTime-basedMovement-basedMovement threshold approachInformation theoretic approach

Mobility modeling and prediction

Different criteria: dimension; scale; randomness; geographical constraints; change of parameters; etcPopular models: fluid-flow; random-walk; Gaussian-Markov; geographic-based; group-mobility; kinematic mobility, etc

31

Connectivity ManagementIncreased complexity, mobility refers today more to the change of a logical location with respect to network access point rather than user geographic position

Consequence: mobility management becomes more of a connectivity management procedure

Two aspects must be considered at vertical HO

HO at device levelHO at flow level

Two general classes of HO mechanisms

Traditional algorithms, with focus on L2/L1 HOContext based algorithms

Three classes of context based algorithms

Traffic flow based algorithmsSimple Additive Weighting (SAW) algorithmsAdvanced Multiple Criteria Decision Making (MCMD) algorithms

Another dimension for evaluation and decision

LocalDistributed

32

Example of SAW

Hierarchy evaluation process

33

Case Study BTH

Streaming service vs. Messaging serviceAlternatives: WLAN; UMTS; GPRS

34

IMS InterworkingIMS interworking

Between 3GPP and WLANBetween 3GPP and UMTSBetween 3GPP and CDMA2000

Main ideas

Extend 3GPP services and functionality to other environmentsDevelop bearer services allowing 3GPP subscribers to use other environments to access 3GPP PS services

35

3GPP UMTS/WLAN Architecture

Interworking architectures for 3GPP UMTS/WLAN

Tight couplingLoose couplingP2P architecture

36

ROVERNew architectural solution, called ROVER, suggested by BTH for L5 HO with mobility prediction

ROVER: Routing in OVERlay networks

Goals

Enable mobile users to seamlessly move among networks of diverse technologies, while maintaining the service continuity and the QoS across application and IP domains

Provide support for both unicast and multicast services, with particular focus on content distribution purposes

37

ROVER (cont’d)Project initially supported by .SE (2007/2008), and now part of FP7 EU STREP PERIMETER (2008)

Focus: media distribution in overlay networks (initially) and L5 HO (today)

Particular focus

QoS-aware overlay routingMiddlewareMechanisms for media distributionStudy of protocols for multicast distribution

Blekinge Institute of Technology (BTH) team

Professor Adrian PopescuTeknDr David ErmanTeknDr Doru Constantinescu (now with HiQ, Karlskrona)TeknLic Dragos Ilie (now with Business Security, Lund)PhD student Alex PopescuMSc Karel de Vogeleer

38

ROVER Architecture

39

Research ChallengesMiddleware

Overlay routing

BitTorrent media distribution

Overlay multicast networks

Interworking platform

Vertical handover

Mobility modeling and prediction

Decision-making algorithms

Handover security

40

Several Important ResultsPartial implementation of a dedicated middleware

Framework named Overlay Routing Protocol (ORP) suggested to provide a QoS-aware service on top of IP’s best effort service

Simulation study of ORP

Modifications and extensions suggested to the BitTorrent (BT) tomake it suitable for use in providing a streaming video deliveryservice

Simulation study of the suggested BT modifications and extensions

Comparative simulation study of three representative categories of overlay multicast networks, i.e., Application Layer Multicast Infrastructure (ALMI), Narada and NICE

41

ROVER MiddlewareMiddleware: software that bridges and abstracts underlying components of similar functionality and exposes this through a common API

Object-oriented (C++ ) based API

Based on the Key-Based Routing (KBR) of the common API framework suggested by the authors of CHORD

Intended to work on top of both structured and unstructured underlays; compared to this, the initial KBR was suggested to work only on top of a structured underlay

Quick integration of existing protocol implementations

Development, evaluation, testing, performance analysis of different protocols and combinations of protocols

42

Unicast QoS Routing in Overlay Networks

Particular difficulties

Multiple constraintsDynamic environments; presence of churn“Real-time” performance demand

QoS constraints can be

Additive (e.g., for delay), or Multiplicative (e.g., for packet loss), or min-max (e.g., for bandwidth)

Optimization algorithms

Self-Adaptive Multiple Constraints Routing Algorithms (SAMCRA)The Simplex MethodGradient Projection MethodConjugate Gradient MethodParticle Swarm Optimization

43

Unicast QoS Routing in Overlay Networks (cont’d)

ROUTING: the process of selecting paths in a network suchthat they satisfy a set of simultaneous QoS constraints

Routing algorithms: given a network topology, find the desired pathsRouting protocols: ensure that all nodes have “accurate” topology information

Example: “Find a path from node A to node B with a minimum of 1Mbps capacity, such that the delay does not exceed 100ms and the packet loss probability is no higher than 0.01%”

Types of path QoS metrics (example: path i→j→k→…..→l→m)

Additive (delay, jitter): d(i,j)+d(j,k)+…+d(l,m)Multiplicative (packet loss): 1-(1-p(i,j))x(1-p(j,k)x…x(1-p(l,m)))Min-max (bandwidth): min(c(i,j), c(j,k), …, c(l,m))

44

Unicast QoS Routing in Overlay Networks (cont’d)

Research has been done on

Finding paths suitable for transporting multimedia flows

Path selection is done such as to satisfy a set of simultaneous QoS constraints

Reacting to path failures by reallocating flows to backup paths

Implementing this functionality in an overlay network spawned by end-nodes, without changing existing Internet infrastructures

45

Unicast QoS Routing in Overlay Networks (cont’d)

Study has been done on

Flow allocation problems and optimization algorithms

Gnutella measurements and characteristics modeling

Overlay Routing Protocol (ORP) framework

Route Discovery Protocol (RDP): finds QoS-constrained paths by selective forwardingRoute Maintenance Protocol (RMP): handles churn by reallocating flows to backup paths

Different performance metrics have been evaluated, e.g.,

Call blocking ratio, bandwidth utilization, bandwidth overhead, path stretch (RDP)Path failure ratio, restored paths ratio, bandwidth utilization, bandwidth overhead (RMP)

The experiments have shown that RDP and RMP are viable alternative to provide a QoS-aware service at the application layer

The cost has been observed to be maximum 1.5% of the residual network capacity

Future work regards implementation of RDP and RMP and PlanetLab tests

46

HandoverBTH has developed a solution for vertical handover, called Network Selection Box (NSB)

NSB encapsulates the raw packet in UDP and sends it over a real network

A tunnel is used to send the packets over the interfaces encapsulated in UDP

NSB can be used for the transport over WLAN, UMTS and GPRS

47

ConclusionsVery fascinating and complex research!

Opening for many applications based on “telepresence”, e.g., pay-free system, check in-free system

Need for move towards real-live deployment, e.g., PlanetLab

Need for participation in the standardization efforts

48

References[Con2007] - Constantinescu D., “Overlay Multicast Networks: Elements, Architectures and Performance”, PhD thesis, BTH,

December 2007

[Dim05] - Dimapoulou L., Leoleis G. and Venieris I., “Fast Handover Support in a WLAN Environment: Challenges and Perspectives”, IEEE Network, May/June 2005

[Erm2008] - Erman D., “On BitTorrent Media Distribution”, PhD thesis, BTH, March 2008

[Gol2007] - Golmie N., “Cross-Layer Mobility Management in Support of Seamless Handovers”, GLOBECOM 2007, Washington DC, USA, November 2007

[Gup2006] - Gupta V., Williams M.G., Johnston D.J., McCann S., Barber P. and Ohba Y., “Overview of Standards for Media Independent Handover Services”, IEEE 802 Plenary, San Diego, USA, July 2006

[Ili2007] - Ilie D. and Popescu A., “A Framework for Overlay QoS Routing”, 4th Euro-FGI Workshop on “New Trends in Modelling, Quantitative Methods and Measurements”, Ghent, Belgium, May 2007

[Ili2008] – Ilie D., “On Unicast QoS Routing in Overlay Networks”, PhD thesis, BTH, October 2008

[Isa2006] - Isaksson L., “Seamless Communications Handover Between Wireless and Cellular Networks with Focus on Always Best Connected”, PhD thesis, BTH, March 2006

[Le2006] - Le D., Fu X. and Hogrefe D., “A Review of Mobility Support Paradigms for the Internet”, IEEE Communications Surveys, 1st Quarter 2006, Vol. 8, No. 1

[Pop2008-1] - Popescu A., “Conceptual Architecture for Seamless Roaming”, Deliverable D5.1, Eureka Mobicome, 2008

[Pop2008-2] - Popescu A., Ilie D., Erman D., Fiedler M., Popescu Alex, de Vogeleer K., An Application Layer Architecture for Seamless Handover”, submitted to the Sixth International Conference on Wireless On-Demand Network Systems and Services, Snowbird, Utah, USA, February 2009

49

Semi-Official Logo

Thanks to Eric Jacobson

Semi-Official Logo

50

THANK YOU!