design and evaluation of ﬂow handoﬀ signalling for...

Available online at www.sciencedirect.com

Computer Networks 52 (2008) 1647–1674

www.elsevier.com/locate/comnet

Design and evaluation of flow handoff signalling formultihomed mobile nodes in wireless overlay networks

Qi Wang *, Robert Atkinson, John Dunlop

Mobile Communications Group, Department of Electronic and Electrical Engineering, University of Strathclyde, Glasgow G1 1XW, UK

Received 18 May 2007; received in revised form 19 February 2008; accepted 19 February 2008Available online 29 February 2008

Responsible Editor: W. Kellerer

Abstract

With the increasing deployment of wireless overlay networks, a mobile node with a range of network interfaces can beconnected to multiple heterogeneous or homogeneous access networks simultaneously. Such host multihoming technologycan be exploited to distribute (or hand off) application flows among the most appropriate interfaces and access networksdynamically to achieve end-to-end seamless, robust and even quality-of-service-aware communications for mobile users. Itis essential that an efficient and effective flow handoff signalling scheme be in place. Nevertheless, little prior work hasaddressed this problem sufficiently in a systematic way and little performance evaluation is readily available. We proposea set of signalling procedures for a comprehensive, flexible yet standard-oriented flow handoff solution. Two candidateschemes are designed by extending and optimising related IETF work based on Mobile IPv6 or Network Mobility(NEMO). Theoretical analyses are performed and numerical results are then presented with a focus on signalling loadsto compare the two proposals and to demonstrate that the designs can largely meet the requirements on desired signallingperformance. Preliminary implementations and experimental results are also reported to validate the concepts of thedesigns, investigate the flow handoff signalling delays and verify the effectiveness of the policy-based flow handoff supportfor typical real-time and non-real-time applications.� 2008 Elsevier B.V. All rights reserved.

Keywords: Multihoming; Flow handoff; Mobile IPv6; NEMO; Signalling performance

1. Introduction

The next-generation wireless systems are evolvingtowards all-IP wireless overlay networks, compris-

1389-1286/$ - see front matter � 2008 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2008.02.005

* Corresponding author. Tel.: +44 141 5706041; fax: +44 141552 4968.

E-mail addresses: [email protected] (Q. Wang), [email protected] (R. Atkinson), [email protected]. ac.uk(J. Dunlop).

ing heterogeneous or homogeneous networks whosecoverage areas are overlapped [1]. A multihomedmobile node (MN) is either a single mobile host ora mobile router, together with a whole mobile net-work, that is equipped with multiple network inter-faces. A multihomed MN has the potential to fullyutilise value-added benefits from wireless overlaynetworks where Wi-Fi, WiMAX, and cellularsystems are complementary to each other in manyaspects such as coverage ranges and data rates.

.

mailto:[email protected]




1648 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674

In this context, it is desired and practical thatboth a mobile user and the network can strategicallytrigger a handoff to switch all or selected applicationflows from one interface or access network toanother. We refer to such an operation as a flowhandoff. Clearly, effective flow handoff support isa key enabler to achieve the ‘‘Always Best Con-nected” (ABC) vision [2] when coupled with intelli-gent network selection algorithms. From the user’sperspective, a flow handoff may be triggered byeither the user’s movement or quality of service(QoS) preferences even in static state. For instance,a user may select an access technology with lowertariff, when available. Certain applications runningin the MN may trigger a flow handoff with the helpof end host measurements such as redirection ofdelay-sensitive application flows to the link withlower round-trip time. From the network’s perspec-tive, a flow handoff may be initiated to improve thenetwork’s service such as load sharing and fault tol-erance. For example, if the network detects that oneaccess network is overloaded it has the option ofdistributing a subset of the flows through anotheraccess network. Similarly, an underutilised accessnetwork could share some of the load. Detectionof such network events can be fulfilled by the net-work more accurately. Certainly, there are manyother examples that necessitate such flow handoffsto improve QoS for a mobile user, the networkoperator and/or the service provider. These obser-vations justify a hybrid flow handoff approach,where both a user and the network can trigger aflow handoff, and both user- and network-triggeredhandoffs can be supported in a unified architecture.

In conjunction with the IST MULTINET project[3], we aim to support multihomed nomadicworkers in charge of repairing and maintaining dis-tributed high-tech and complex machines. Typi-cally, after roaming to the scene of work, theseworkers would stay there working on the staticmachines. With the increasing deployment of wire-less overlay networks, the workers often work inthe coverage of multiple access networks. Duringthe working process at the site, these workers needto communicate with their back office regularly forremote support, transmitting real-time or non-real-time data or downloading documentationsand instructions. From time to time, the multipletasks being performed would generate multiplesimultaneous application flows with different QoSrequirements or user/application preferences. Thecore objective of MULTINET is to investigate

standard-oriented solutions to comprehensive flowhandoffs in wireless overlay networks to accomplishrobust, seamless and QoS-aware service delivery. Inthis paper, we focus on the design and evaluation offlow handoff signalling procedures. The design andanalysis take into account flow handoffs triggeredby either movement for mobile users or by intelli-gent network selection for nomadic users, althoughthe latter is concentrated on in our experiments.Despite the extensive related work on handoff man-agement and multihoming support, much work isstill needed in design and evaluation. In fact, littleprior work has provided a systematic design of flowhandoff signalling procedures that exploit bothusers’ and the network’s intelligence; and even lesshas offered an in-depth analytical or experimentalevaluation or comparison of promising approaches.

The remainder of this paper is organised as fol-lows. We survey related work on mobility and mul-tihoming in Section 2. Section 3 presents ourmotivations for flow handoff support signallingschemes, the overview of the proposals and the ref-erence network model. In Section 4, we expoundour proposed signalling schemes towards a compre-hensive and standard-oriented solution. A set ofprocedures are illustrated and described includingboth user- and network-triggered flow handoffsand supporting routines. The theoretical analysesand numerical results of the proposed schemes arethen provided in Sections 5 and 6, respectively. Sub-sequently, implementations and experimentalresults are presented in Section 7 to complementthe analytical results and validate the concepts ofthe proposed designs. Finally, Section 8 concludesthis paper.

2. Related work

2.1. Mobile IPv6-based approach

The IETF plays an essential role in IP-basedmobility management. Mobile IPv6 (MIPv6) [4] isthe de facto standard for IPv6 mobility support.Unfortunately, MIPv6 in its current form does notsupport advanced multihoming beyond handingoff all the flows from one interface to another. Anumber of MIPv6 variants such as HierarchicalMIPv6 (HMIPv6) [5] and Fast Handovers forMIPv6 (FMIPv6) [6] have been proposed for perfor-mance optimisation and extension. In particular,Network Mobility (NEMO) [7] extends the IPmobility support from a single mobile host (MH)

Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1649

to a whole mobile network managed by a mobilerouter. However, MIPv6 and these variants havenot addressed advanced flow handoffs in a multih-oming context. Following the end-to-end principlein the Internet design, the IETF has concentratedon the user-centric approach though there is a needfor the network-supported approach [8] and thusthe Network-based Localised Mobility Manage-ment (NETLMM) WG has been launched.

Recently, the Mobile Nodes and Multiple Inter-faces in IPv6 (MONAMI6) WG has been standar-dising MIPv6/NEMO-based host multihomingmechanisms to facilitate flow handoffs for multih-omed MNs. Multiple Care-of-Addresses (CoAs)registrations are allowed in [9] so that a single HomeAddress (HoA) can be bound with more than oneCoA through a pair of Binding Update (BU) andBinding Acknowledgement (BA) messages. To dis-tinguish the different (HoA, CoA) bindings for agiven MN, an extra identifier called the BindingUnique ID (BID) is introduced. Typically, eachBID corresponds to and identifies a specific inter-face of the MN.

Furthermore, the flow bindings draft [10] enablesa particular flow to be bound with a CoA associatedwith an interface. A Flow ID option accommodatesthe flow identifier such as a subset of the five-tuple(source and destination addresses and port numbers,transport protocol), e.g., the well-known port num-bers can identify different application flows (e.g.,8080 for HTTP flows, 20 for FTP flows). The FlowID option, also placed in a BU or BA message,can indicate adding, replacing or deleting of a flowbinding policy (Flow ID, BID), identified by a FlowID identifier. A default binding exists in case of nomatching. A major problem in this proposal is thatonly user-initiated flow handoffs are addressed as aBU is always sent from a MN to its Home Agent(HA), although both user- and network-initiatedflow handoffs are desired and should be supported.

The flow distribution draft [11] targets the similartask from a different approach. An XML schemafragment is defined to code the policies and appliesthe Simple Object Access Protocol (SOAP) [12] overHTTP or HTTPS web service to deliver the messag-ing. Since SOAP request and reply messages can besend from a MN or its HA, potentially network-trig-gered flow handoffs could be introduced. Neverthe-less, a dedicated intelligent network selection serverwould be more advantageous to prevent the HAfrom overloading. No such server or network intelli-gence to trigger the flow handoffs has been reported.

Furthermore, the two approaches presented in[10,11] lack a systematic design and presentationof a full set of signalling procedures needed for flex-ible policy-based flow handoff support. In addition,numerical comparisons based on either theoreticalanalysis or implementations between them are miss-ing. We attempt to fill these gaps in this paper.

2.2. SCTP-based approach

The Stream Control Transmission Protocol(SCTP) [13] is an emerging transport protocol thatsupports multihoming in its own right. SCTP mul-tihoming allows binding of one transport layer’sconnection to multiple IP addresses at each end ofthe connection. This binding allows a sender totransmit data to a multihomed receiver through dif-ferent destination addresses. Simultaneous trans-mission to multiple destination addresses is beinginvestigated. For instance, Iyengar et al. [14] pro-posed and analysed concurrent multi-path transfer(CMT) between multihomed source and destinationhosts to increase an application’s throughput. Notethat this is different from the simultaneous use ofmultiple interfaces for concurrent different applica-tions’ transmissions and their dynamic flow hand-offs among the interfaces in our study.

The multihoming capability in SCTP has alsobeen employed for handoff management such as inmSCTP [15] and mobile-SCTP [16]. Those schemesutilise end-to-end semantics for signalling handoffs.The end-to-end approach would reduce the homeregistration delay and eliminate the tunnelling costthat exists in the Mobile IP-based handoff manage-ment protocols. On the other hand, the end-to-endparadigm lacks the support from network intelli-gence that can be very beneficial for overall QoSprovision. In our design, network intelligence isexploited to trigger network-initiated flow handoffs.

After all, the SCTP multihoming is mainlydesigned to enable retransmissions to alternate IPaddresses for survivability when the primary IPaddress becomes unavailable. There is little, if any,SCTP-based work aims to enable policy-basedhandoffs of different application flows among theinterfaces of a multihomed node. More importantly,SCTP multihoming is operating in the transportlayer and thus it would only benefit applicationsthat are based on SCTP rather than TCP or UDP,over which most IP applications are currently run-ning. Therefore, although SCTP-based multihominghandoff management is a promising approach, we


believe that a network-layer solution e.g., enhancedMIPv6/NEMO would be more appropriate in thenear future.

2.3. Other relevant work

The Host Identity Protocol (HIP) [17] is anotherpromising proposal that could facilitate IP mobilityand multihoming. HIP introduces a new ‘‘host”layer between the network and the transport layers.Consequently, flows are bound to host identitiesinstead of IP addresses so that the change of IPaddresses can be transparent to the applications asin the basic MIPv6/NEMO. Regarding multihom-ing, similar to SCTP alternate IP addresses can beexchanged between the MN and its peer so that sur-vivability can be achieved. In addition to the similarlimitation as found in SCTP-style multihoming, add-ing a new layer to the protocol stack is not a minormodification and this may cause an updating ofnumerous IP applications. Hence, HIP-based mul-tihoming may not be preferred in the short to middleterm either.

It is also noted that work is underway on sitemultihoming, where a site’s network has connec-tions to multiple IP service providers. The IETF SiteMultihoming in IPv6 (MULTI6) WG defines a basearchitecture and the Site Multihoming by IPv6Intermediation (SHIM6) WG is developing the pro-tocols. Our current research concentrates on hostmultihoming although advances in site multihomingmay be complementary in improving performances.

The IETF Detecting Network Attachment(DNA) WG is extending the current IPv6 hostauto-configuration protocols to allow MNs todetect their IP layer configuration and connectivitystatus more quickly so that the current MIPv6/NEMO handoff performance would be optimised.The IEEE 802.21 [18] is defining new signalling pro-cedures and APIs related to the link layer for L2triggers and network selection. These schemesintend to complement the IETF IP mobility proto-cols. Our proposals follow the IETF track.

In addition to the standardisation work, there isan increasing interest in multihoming in the widerresearch community. TCP traffic multihoming issupported in [19] with the IP Network AddressTranslator (NAT) function. IP-in-IP tunnelling isemployed in [20] to aggregate the bandwidth of mul-tiple IP paths for improved throughput. The RouterAdvertisement messages are extended in [21] toenforce multihoming signalling between a MN and

an access router (AR) for load balancing and faulttolerance. These studies did not address advancedpolicy-based flow handoffs based on MIPv6/NEMO. Regarding handoff decision-making algo-rithms for multihomed MNs, Wang et al. [22] pro-posed a policy-enabled scheme with a cost functioncovering available bandwidth, power consumptionand service tariff in heterogeneous networks. In[23], the handover decision-making process uses con-text information regarding user devices and location,network environment and requested QoS. Morealgorithms are designed in [24] to optimise the costsand performances for multihomed users. The policydefined in [22] and the pilot algorithms proposed in[23,24] may serve as a subset of the desired intelligentnetwork selection algorithms, which are beyond thispaper’s scope. In addition, host multihoming wouldalso facilitate seamless handoffs from anotherapproach compared with FMIPv6 as reported in[25]. The work in [25] complements our focus of thispaper on handoffs triggered by network selectionintelligence other than user movement.

3. Proposed system overview

3.1. Motivations

The work-in-progress in the IETF MONAMI6WG has laid a foundation for flow handoff support.In our design, these separate proposals are exploitedas building blocks towards a comprehensive unifiedarchitecture. Refs. [10,11] provide a good starttowards flexible policy identification and distribu-tion for flow handoffs. However, neither a detailedanalysis of such solutions nor a comparative studywith each other is available. Furthermore, to sup-port advanced flow handoff signalling, a completeset of procedures and some key components are stillmissing in both approaches as mentioned in Section2.1.

Our contributions in this paper are threefold.Firstly, we attempt to design two complete sets offlow handoff signalling schemes by enhancing andextending the approaches in [10,11], respectively.Secondly, we present an original and pioneeringnumerical comparison of both approaches in termsof signalling efficiency through an analytical meth-odology. Thirdly, we validate our designs withpreliminary implementations of both approaches,and further evaluate and compare their perfor-mances in terms of flow handoff signalling delays.The effectiveness of the flow handoffs are also


verified for both real-time and non-real-timeapplications.

Compared with the existing work, we take amore systematic design approach to flow handoffsfor multihomed MNs with a set of design require-ments considered. Functionally, the system shouldsupport both user- and network-triggered flowhandoffs in a unified platform to satisfy the practicaldemands from both sides’ perspectives. This wouldallow flexible generation of handoff triggers wher-ever appropriate and convenient, as aforemen-tioned; and fully utilise the intelligence of both theMN and the network. The signalling system shouldcoordinate the MN and the network and fulfil thesynchronisation of the flow binding policies at bothsides. Moreover, it may be desirable that a user begranted a negotiation option in case of network-triggered handoffs. Architecturally, the systemshould facilitate an incremental deployment. Thus,a centralised paradigm may be established in thefirst stage since such a paradigm is more easily man-ageable. In a later stage, a more distributed para-digm may be deployed for optimised performances.

Regarding the performance of the proposed sig-nalling schemes, signalling efficiency is among thetop concerns of any signalling system. Efficient sig-nalling is required for bandwidth-limited wirelessnetworks. Decent handoff signalling delays due topolicy distribution and enforcement are also desiredso that a policy-based flow handoff can take effectquickly and smoothly. As to implementations, it isdesirable that the proposed system should raise aslittle concern as possible in implementation conve-nience and operation interoperability. Standard-ori-ented schemes should alleviate such concerns. Inaddition, good message readability and extensibilityare preferable to the signalling designers anddevelopers.

3.2. Overview of the proposals

We have designed two independent standard-ori-ented signalling schemes. Briefly, Scheme I extendsthe flow bindings draft [10] by enabling flow bindingsignalling from the HA to a MN for network-trig-gered flow handoffs. Following the tradition inMIPv6, we define new ICMPv6/UDP messages forsupporting signalling such as network triggers andprobes. Alternatively, Scheme II enhances the flowdistribution draft [11] by defining new SOAP mes-sages for the supporting signalling. Both schemesreuse the multiple CoA registration procedure [9]

built upon MIPv6/NEMO. Therefore, both schemesare based on standard protocols and the interoper-ability should not be of great concern.

Furthermore, both schemes are designed to meeta set of challenges. They support both kinds of trig-gers and they can fall back to user triggers only ifthe required network selection algorithm is unavail-able. Detailed intelligent network selection algo-rithms are beyond the scope of this paper as weconcentrate on the signalling aspects. Support ofgradual deployment is also taken into account. Inthe current stage, the HA is enhanced to be incharge of handling multiple CoA registrations of aMN, synchronising flow binding policies with theMN, and handing off selected downlink flowsaccording to the up-to-date policies. In our futurework, the Mobility Anchor Point (MAP) definedin HMIPv6 would be enhanced to act as a virtuallocal HA in a foreign domain for the visiting MNsso that most of the signalling to the HA can belocalised and the workload at the HA can bedistributed.

For secure signalling, MIPv6/NEMO has recom-mended IPsec [26,27]. The same security mechanismis also applicable to the proposed schemes, whichare IP-based protocols. Therefore, standard securesignalling can be achieved in our design withoutinventing new specific security mechanisms. Furtherdiscussions on Authentication, Authorisation andAccounting (AAA) are beyond the scope of thispaper.

Both schemes can operate over the reliable TCPor the unreliable UDP. When UDP is used, a signal-ling protocol (MIPv6/NEMO, ICMPv6 or SOAP)needs to employ its own timer-based retransmissionmechanism in the same manner as defined in theMIPv6 specification [4]. Signalling reliability canthus be provisioned to ensure successful end-to-end message delivery. Secure and reliable signallingis further considered and explained in Section 5 toderive the signalling loads.

Finally, the messages defined in both schemes areextensible. In particular, the textual XML-codedSOAP messages appear more readable and modifi-able to developers, especially in a joint project likeMULTINET.

3.3. Reference model

The network model is illustrated in Fig. 1 to facil-itate the description of the subsequent design andanalysis. It is a simplified version of the MULTINET

Fig. 1. Reference network model.


reference architecture [3]. In this model, a MN can beequipped with multiple network interfaces thoughtwo interfaces IF1 and IF2 are demonstrated. TheMN under consideration is visiting a foreigndomain. The HA is located in the home domainand it collaborates with the MN and the intelligentNetwork Selection Algorithm server (NSA) for flowhandoff support. Symmetric flow binding policies arestored, synchronised and enforced in both the MNand the HA for distributing the identified uplinkand downlink flows, respectively. A correspondentnode (CN) is stationary in a third domain. All thedomains are interconnected to each other througha common IP core network. The MIPv6 bi-direc-tional tunnelling mode between the MN and theHA is demonstrated for incremental deploymentand NEMO base protocol compatibility. Fig. 1 onlyshows the downlink flows for presentation clarity.An additional advantage of this mode is that theCN can be unaware of the MN’s location or beingmultihomed. The CN always sends packets to theMN’s HoA. The route optimisation or HMIPv6adoption would be investigated in future work.

In the foreign domain, two access routers AR1and AR2 provide wireless access to the MN ini-tially. Subsequently, the MN may be connected toother ARs, e.g., ARx, on the user’s movement. Nev-

ertheless, it is important to notice that the MN canexperience flow handoffs due to either MN move-ment or intelligent network selection for dynamicMN/network QoS-driven adaptation. A servingNSA collects and processes periodic network QoSmeasurement reports from the ARs, and determinesif the network should initiate a network-triggeredflow handoff based on the output of the intelligentnetwork selection algorithms running in the NSA.Note that there is no constraint on the physicallocation of the NSA: it can be located whereverappropriate as chosen by the service provider. Forinstance, more than one foreign domain may sharea NSA in a gradual deployment. Security associa-tions between the signalling entities are establishedfor secure signalling. Pure IPv6 is assumed in thismodel although the support for IPv4–IPv6 transi-tion is also considered [3].

4. Proposed signalling design

In this section, we describe the proposed signal-ling procedures in the two schemes aforementioned.We focus on the signalling protocols with involvedmessages briefed. The detailed message formatsare defined whereas they are not expounded herefor conciseness.


4.1. Initial registration of multiple CoAs

To obtain the flow handoff support for downlinktraffic and network-triggered flow handoff notifica-tion, a MN must configure and register themultiple CoAs assigned to its interfaces at the HAas the first step. This kick-off procedure is illustratedin Fig. 2.

On being powered up in a foreign domain, theMN may wait for the next scheduled unsolicitedRouter Advertisement (RA). Since an unsolicitedRA may not arrive promptly or may not includethe complete prefix information [28], the MN mayalternatively send a Router Solicitation (RS) fromeach of its interfaces to request a RA from the corre-sponding ARs. A RS is typically sent to the All-Rou-ters multicast address [28]. Consequently, all of itsinterfaces can be configured with a unique IPv6address (CoA) through either the default IPv6 state-less address auto-configuration [29] or an optimised

IF1 IF2

MN AR2AR1

1

2

3

4

RS

RS

RA

RA

Fig. 2. Multiple CoA registrat

2

1

IF1 IF2

3

4

MN AR2AR1

BU {default flow binding poli

BA {...}

5

ICMPv6 Ack

ICMPv6 Profile

Flows (Flow 1 & 2)

Fig. 3. Default user flow binding policy a

variant that can accelerate the process and reducethe overheads. We assume the latter approach asshown in Fig. 2. The signalling for this procedureis the same in Scheme I and Scheme II. ‘‘{. . .}”means a specific reply to the corresponding request.Once the interfaces are configured with unique IPv6addresses, the MN sends one or more BU messagesto the HA to register these CoAs as defined in [9].To reduce the signalling loads, the bulk registrationis preferred so that the multiple CoA registration isperformed by a single BU. After verifying and pro-cessing the BU, the HA then replies with a BA indi-cating the success or failure (with the correspondingerror code) of the registration.

4.2. Default flow binding policy and profile

registration

Subsequently, as shown in Fig. 3 the MN shouldregister its default flow binding policies and user

HA

BU {bulk multiple CoA-BID registration}

BA {…}

ion in Schemes I and II.

Flows (Flow 1 & 2)

HA CNNSA

cies}

nd profile registration in Scheme I.


profile with the HA and the NSA, respectively. InScheme I, the MN initiates these tasks by sendinga BU and an ICMPv6 Profile message to the HAand the NSA, respectively. The HA and the NSAthen reply with a BA and an ICMPv6 Ack messageaccordingly. The BU requests to register the defaultflow binding policies, which are a set of (Flow ID,BID) bindings. Each Flow ID is a subset of thefive-tuple aforementioned. The BU also indicatesthe default flow binding priority for each BID.When a flow does not match any flow bindingpolicies, it will be bound to the BID that has thehighest default flow binding priority. The Profilemessage specifies the user information, terminalinformation, and application preferences regardingnetwork conditions. Note that it is possible tocombine this procedure with the initial multipleCoA registration in Scheme I. The two proceduresare designed to be distinct since some users mayonly be interested in registering multiple CoAs.

In Scheme II, pure SOAP messages are used tofulfil the above signalling. A pair of SOAP Policyor Profile Registration request and reply messagesare exchanged between the MN and the HA orbetween the MN and the NSA, respectively. Tofacilitate the processing of specific policies andreduce policy refresh loads, a Policy ID similar tothe FID identifier in the Flow ID option definedin [10] is introduced to optimise [11].

4.3. User-triggered flow handoffs

On a user-triggered flow handoff, the MN wouldupdate specific policies including modifying, delet-ing or adding selected policies at the HA. This pro-cedure manages two scenarios depending onwhether a user handoff is triggered by the user’smovement or not. The signalling varies accordingto the scenarios or the schemes.

In Scenario A, one (or more) of the interfaces ofthe MN connects to a new AR due to movement.After the movement is detected through a link-layertrigger (e.g. [18]) or a network-layer mechanism (e.g.upon receiving an unsolicited RA from the newAR), the MN sends an AS to the All-Routers mul-ticast address or the new AR directly if possible, andthe new AR in turn replies with a RA as shown inSteps 2A-1 and 2A-2. Consequently, the MNobtains a unique IPv6 address for that interfacethrough the IPv6 stateless address auto-configura-tion or an optimised variant. Here we assume thatan optimised router detection and address distribu-

tion scheme (e.g., [18,30]) is in place to minimise theotherwise considerable overheads and delay in themovement detection [31] and the duplicate addressdetection processes. In Scheme II, a pair of BUand BA is exchanged for new CoA registration inSteps 2A-3 and 2A-4; and if flow binding policyupdate is needed, a pair of SOAP messages are usedin Steps 2A-5 and 2A-6. In contrast, in Scheme I,both new CoA registration and the possible policyupdate can be performed through one pair of BUand BA in Steps 2A-3 and 2A-4. Note that if thenew AR uses a homogeneous radio technology theMN would typically only need to update the CoA(s)associated with the involved BID(s) and leave thepolicies intact since the policies are bindingsbetween BIDs and Flow IDs.

In Scenario B, the MN, even in a stationarystate, triggers a flow handoff based on its own intel-ligence for better connections. As an example, weassume that two flows (flow 1 and flow 2) havebeen established between the CN and the MN asshown in Step 1. When a flow handoff is user-trig-gered, the MN sends a BU with the new flow bind-ing policies enclosed to the HA, as depicted in Step2B-1. Note that the MN may prefer to use the tar-geted (secondary) interface for the signalling espe-cially when the source interface is going down.We assume that the new flow policies indicate thatone of the flows (flow 2) needs to be handed overfrom the current interface to the secondary one.Upon receiving the BU, the HA authenticates andverifies the BU. If the authentication and verifica-tion are successful, the HA updates the pre-installed flow binding policies of the MN andreplies with a BA in Step 2B-2. Afterwards, theHA hands off flow 2 to its interface connected tothe access network corresponding to the MN’s sec-ondary interface. The handoff is achieved by tun-nelling (IP-in-IP encapsulation). Consequently,flows are distributed between the interfaces asdesired in Step 3.

In the illustrations, we assume that the MN usesthe new CoA in Scenario A or the existing CoAassociated with the targeted interface in ScenarioB for CoA registrations and/or flow binding policyupdates. In addition, the illustrations only demon-strate the downlink flows, and selected downlinkflows are handed over to another access networkby the HA on a flow handoff. Regarding an uplinkflow handoff, the MN itself switches selected flowsto another interface by tunnelling in a similarmanner.


4.4. Network-triggered flow handoffs

On a network-triggered flow handoff, the HAupdates specific policies at the MN based on a trig-ger from the NSA. Fig. 5 depicts this procedure inScheme I. As shown in Step 2, the monitor modulecollocated with a AR measures the QoS metrics andsends the measurements in a Probe message to theNSA periodically. A Probe message provides thecurrent QoS of the access network in terms of a ser-ies of selected metrics. Four metrics have beendefined including traffic load, available bandwidth,Received Signal Strength Indication (RSSI) and Sig-nal-to-Noise Ratio (SNR). The NSA collects andinput these QoS measurements to the predefinedintelligent network selection algorithms. Assuminga flow handoff is to be triggered as shown in Step3, the NSA sends a Trigger message to the HA inStep 4. A Trigger message comprises one or more

IF1 IF2

MN ARxAR1

3

1Flows (Flow 1 & 2)

Scenario A: User-movement triggered flow handoff decis2A

RS

RA

2A-1

2A-2

2B Scenario B: User-intelligence triggered flow handoff dec

Flow 2

Flow 1

I: BU (II2B-1

I: BA (II:2B-2

I: BA {…

II: BA {…2A-4

II: BU {A2A-3

I: BU {A

II only for possible policy update

II: SOAP2A-5

II: SOAP2A-6

Fig. 4. User-initiated flow han

triggers, each of which is a binding of a Flow IDand a AR prefix. More than one Flow IDs can bebound with a same AR prefix. A Flow ID used ina trigger is typically a subset of a three-tupleincluding the source and destination port numbersand the transport protocol since the source and des-tination addresses are typically unavailable at theNSA. Triggers for multiple MNs can be enclosedin a single Trigger message for scalability. MNs withsimilar user profiles can be classified into the sameservice class and may be triggered under the samenetwork conditions. The HA would authenticateand verify the request and acknowledges it in Step 5.

Subsequently, a notification process with a nego-tiation option between the network (the HA trig-gered by the NSA) and the user (the MN) isproposed as follows. Firstly, the HA formulatesthe new flow binding policies based on the receivedtrigger. This involves a mapping operation between

HA CN

Flows (Flow 1 & 2)

ion

ision

Flows (Flow 1 & 2)

: SOAP Req) {flow binding policy update}

SOAP Rep) {…}

}

}

1: new CoA registration}

1: new CoA registration and A2: possible policy update}

Req {A2: possible policy update}

Rep) {…}

doff in Schemes I and II.

ICMPv6 Probe

2

1

IF1 IF2

Flow 2 Flows (Flow 1 & 2)

Flow 1

3

4

6

ICMPv6 Trigger

ICMPv6 Ack

MN AR2 HAAR1 CNNSA

9

Flows (Flow 1 & 2) Flows (Flow 1 & 2)

BA {…}

BU {flow binding policy update and/or negotiation}

BRR {flow binding policy update}

5

7

8

Network-triggered handoff decision

ICMPv6 Probe

Fig. 5. Network-initiated flow handoff in Scheme I.


the ARs’ prefixes and the BIDs of the involved MNsby matching the AR’s prefixes and the correspond-ing CoAs’ prefixes. Afterwards, the changed policiesneed to be signalled from the HA to the MN. Thiscan be accomplished by extending the MIPv6 Bind-ing Refresh Request (BRR) message by introducinga new mobility option for the modified policies, andallowing the HA to send such an extended BRR tothe MN (Step 6). The mobility option is based onthe Flow ID option defined in [10]. An optionalnew flag could also be defined in the option to indi-cate if the new policies are negotiable. Note thatsuch an extension is supported by the extensibilityof the BRR message as defined in the MIPv6 speci-fication [4]. By extending the BRR message ratherthan defining a brand new mobility message, wecan largely reuse the BU message (and optionallythe BA) enhanced for user-initiated handoffs thanksto the existing MIPv6 BRR-BU signalling logic asto be shown in the subsequent steps. Moreover,the built-in security specified in the original MIPv6messages can be naturally utilised.

Secondly, on receiving the BRR, the MN mayaccept or reject the new flow binding policies bysending back a BU with an explicit reply, e.g. by

repeating the new policies if accepted or repeatingthe existing policies if rejected, or simply by settinga flag. This is performed in Step 7. Optionally, theHA may acknowledges with a BA in Step 8. In thisBA, the HA may confirm the final decision. It isnoted that either the MN’s current interface in use(IF1) or the secondary interface (IF2) can be usedfor the above signalling since the CoAs associatedwith these interfaces have already been registeredat the HA and they are refreshed regularly to main-tain their validity. The use of the interfaces in Fig. 5is for demonstration only though such a use may bepreferred for the HA to double-check their avail-ability. Consequently, as an example, one of thetwo flows is redirected to another interface by theHA tunnelling as shown in Step 9.

Scheme II uses all SOAP messages for the probes,triggers, and policy update. In addition, it mayworth mentioning that it would be also possiblefor the HA to advise policies in user-initiated flowhandoffs or even for the default flow handoff poli-cies. In that case, the HA should include anextended Binding Refresh Advice option (the baseoption is defined in MIPv6 [4]) in the BA messagewhen replying the MN’s BU message.


4.5. Flow binding policies and multiple CoA

registrations refresh

To keep alive the multiple CoA registration andthe flow binding policy registration at the HA, theMN needs to periodically refresh these registrationsbefore they expire. Fig. 6 illustrates this procedurein both schemes.

In Scheme I, the MN sends a BU to the HAaccording to the predefined lifetime of the registra-tions. Since the CoAs and the policies share thesame lifetime, this single BU is used to refresh bothmultiple CoA registration and flow binding policiessimultaneously. The MN replies with a BA to theMN. In the BU and the BA, for each policy onlythe first eight-bytes including the FID identifierother than the whole Flow ID option are enclosed.

IF1 IF2

MN AR2AR1

2

1

For I

For II

2

1

4

3

Fig. 6. Registrations refresh

IF1 IF2

2

1

MN AR2AR1

3

4

Fig. 7. Deregistration in

Scheme II has to use an extra pair of SOAP Regis-tration refresh request and reply messages with thePolicy ID identifiers enclosed in addition to a pairof BU and BA message for policy refresh andCoA refresh, respectively.

4.6. Deregistration

Finally, to deregister the flow handoff service theMN would initiate the deregistration procedure asshown in Fig. 7. The MN may deregister selectedCoAs by sending a BU to the HA whilst retainingat least one CoA if it is still in a foreign domainand would like to receive standard MIPv6 service.Usually a MN deregisters all of the CoAs only whenreturning the home domain. The MN may sendanother BU or a SOAP message to the HA to

HA

BU {flow binding policy & CoA refresh}

BA {…}

BU {CoA refresh}

BA {…}

SOAP Req {flow binding policy refresh}

SOAP Rep {…}

in Schemes I and II.

I, II: BU {deregistration}

I: ICMPv6 (II: SOAP Req) {deregistration}

I, II: BA {…}

I: ICMPv6 (II: SOAP Rep) {…}

HANSA

Schemes I and II.


explicitly rearrange the flow binding policies associ-ated with the deregistered BIDs by defining newflows and flow bindings or just rebinding existingFlow IDs to the desired BIDs. Otherwise, by defaultthe flows bound to these deleted BIDs are thenbound to the BID with the highest default flowbinding priority set in the default user flow bindingpolicy and profile registration procedure. For sim-plicity, we assume the latter case. Meanwhile, theMN should send an ICMPv6 or SOAP Deregistra-tion request message to the NSA should it want toderegister the network-triggered flow handoff sup-port service.

5. Signalling analysis

In this section, we develop an analytical modelfor signalling performance evaluation of the twoproposed schemes.

5.1. Evaluation metric and associated parameters

In the evaluation of a mobility protocol, themajor concern would be the signalling loads [32–34]. Plethoric signalling loads tend to over-consumethe valuable bandwidth of the wireless network, andthe processing capacity of the involved servers, andthus may lead to system performance degradationand affect the committed QoS of the services. Thecontribution of an individual message to the net-work load depends on the message length and thesequence of visited network nodes on the pathbetween its origin and destination [32]. Therefore,the signalling loads generated by a message can becalculated as the product of the message lengthand the number of hops it traverses between thesource and the destination in the network [33].The aggregate signalling loads generated by a proto-col are the summation of the loads contributed byall the involved individual messages. In this paper,the average (or mean) signalling loads per MN aredefined as the expected accumulative IP-level mes-saging traffic for a specific signalling procedure orall kinds of signalling procedures related to flowhandoffs in a unit time (per hour). In the following,we list the main assumptions and parameters for thesubsequent analyses.

Assumptions:Firstly, the involved entities in the signalling sys-

tem are all interconnected through wired linksexcept that a MN and the ARs are communicatingthrough wireless links. The wired hops in the system

are assumed error-free and broadband. The packetloss is only caused by the error-prone wireless hopbetween a MN and a serving AR. In addition, thenumber of hops between two entities is the samefor both downlink and uplink signalling.

Secondly, SOAP run over UDP directly insteadof over HTTP and the underlying TCP. In the wire-less networking context, SOAP over UDP directlywould be significantly more efficient [35,36]. It isreported in [36] that SOAP over UDP can reducemessage size by almost 50% compared with SOAPover HTTP. Therefore, SOAP over UDP is pre-ferred in Scheme II although both HTTP/TCPand UDP can be used. Running over UDP, bothSchemes I and II apply the timer-based retransmis-sion mechanism for recovery of lost/corruptedpackets as defined in MIPv6 [4]. There are no addi-tional retransmission (or other error correction)mechanisms. Every time when a local predefinedtimer expires, the sender of a request messageretransmits the request. This operation is repeateduntil the sender receives a matching reply messagefrom the receiver or the predefined maximumretransmission trials have been conducted. Thereceiver of a request sends back or retransmits areply only upon the receipt of the correct request(either the initial one or a retransmitted copy).

Parameters:bi the bit error rate (BER) of the wireless hop

that packet i (a packet or a non-oversizedmessage of type i) is being transmitted over(bi < 1)

ai the packet loss rate of packet i

qi,i+1 the probability that a transaction consistingof a pair of request and reply packets i andi + 1 fails (we denote packet i + 1 be thereply to packet i that is a request)

Lji the length of packet i in procedure j in the

unit of bytesHA–B the number of hops between entities A and

B, or between B and A (non-directional)Cj

S the signalling loads incurred by procedure j

in Scheme S (S = I or II)Cj

S:iðhÞ; CjS:i;iþ1ðhÞ the signalling loads incurred by

packet i in one direction or by packets i

and i + 1 in each transmission direction ofh hops in procedure j of Scheme S

kj the mean rate at which procedure j isinvoked (kInit-MCoA, kDef-policy, kUsr-HO,kNet-HO, kPolicy-Ref, and kDereg denote themean rate for initial multiple CoA registra-tion, default policy and profile registration,


user-triggered flow handoff, network-trig-gered flow handoff, policy and CoA fresh,deregistration, respectively)

kProbe the mean frequency a Probe message is sentby a AR

pmv the probability that a user-triggered flowhandoff is caused by the user’s movement

pmv-npu the probability that a user-triggered flowhandoff on a user’s movement does not in-vokes a policy update

pi(j), pi,i+1(j) the probability that a request packet i isor both packets i and i + 1 are successfullytransmitted in the jth trial, respectively

Nprobe the average number of probe messages re-ceived at the NSA between two consecutivenetwork-triggered flow handoffs

NAR the average number of involved ARs thatperiodically send Probe messages to theNSA in the MN’s current service area

NMH-tr the average number of involved MNs(MHs) in a network-triggered flow handoff

NHO-IF the average interfaces that need to config-ure a new CoA on a user-triggered flowhandoff due to the user’s movement

NRM the maximum number of transmission trials

MTUmin the minimum IPv6 Maximum Transmis-sion Unit

5.2. Signalling loads analysis

In this subsection, we derive the formulae of thesignalling loads. The average signalling loads gener-ated per MN per unit time by Scheme S consistingof m procedures are calculated as

CS ¼Xm

j¼1

kj � CjS

� �¼Xm

j¼1

kj �Xlj

i¼1

P jS:i � C

jS:i

� �" #; ð1Þ

where lj is the number of messages invoked in pro-cedure j, and P j

S:i is the probability that message iis invoked in procedure j. The signalling loadsincurred by message i in procedure j in Scheme S

are calculated as the product of its length and hops:Cj

S:i ¼ LjS:i � H

jS:i[33]. For a given procedure j, the

average loads are given by

CjS ¼

Xlj

i¼1

P jS:i � L

jS:i � H

jS:i

� �: ð2Þ

In the following, we derive the signalling loads gen-erated by a pair of request and reply packets andthen those generated by specific procedures. First

of all, a successful transmission of packet i requiresthat every bit of the packet is correctly received.Therefore, the packet loss rate of packet i is given by

ai ¼ 1� ð1� biÞ8�Li ; ð3Þ

where 8 � Li is the length of packet i in the unit ofbits. Note that a transmission of a pair of requestand reply packets would fail when either the requestis lost or the request is received whereas the reply islost. Therefore, the probability that a transmissionfails and thus a retransmission is incurred is given by

qi;iþ1 ¼ 1� ð1� aiÞ � ð1� aiþ1Þ¼ ai þ ð1� aiÞ � aiþ1: ð4Þ

The signalling loads provoked by a pair of requestand reply packets consist of two portions: the loadsdue to the final successful transmission and theloads from the unsuccessful transmission trials.Firstly, the mean loads generated by a successfultransmission of both packets on the jth trial (afterj � 1 unsuccessful trials) over h hops including onewireless hop in each direction are given by

Ci;iþ1ðjÞ 1ðhÞ ¼ qj�1i;iþ1 � ð1� qi;iþ1Þ� ðLi þ Liþ1Þ � h½ �: ð5Þ

Next, we calculate the loads from the unsuccessfultrials. When the request is sent from a MN to a net-work entity e, we refer it to as an uplink request;when the request is sent in the opposite direction,it is called a downlink request. The wireless hop isthe first hop for an uplink packet whilst the lasthop for a downlink packet. For an uplink and adownlink request respectively, the mean signallingloads generated by an unsuccessful transmission isgiven by

Cfaili;iþ1ðhÞ ¼

ai � ðLi � 1Þ þ ð1� aiÞ � aiþ1

� ðLi þ Liþ1Þ � h½ � Uplink request;

ai � ðLi � hÞ þ ð1� aiÞ � aiþ1

�ðLi � hþ Liþ1 � 1Þ Downlink request:

8>>><>>>:

ð6Þ

The mean accumulative loads generated by the pre-vious j � 1 unsuccessful trials are then given by

Ci;iþ1ðjÞ 2ðhÞ ¼ qi;iþ1 � Cfaili;iþ1ðhÞ þ q2

i;iþ1 � Cfaili;iþ1ðhÞ

þ q3i;iþ1 � Cfail

i;iþ1ðhÞ þ � � � þ qj�1i;iþ1 � Cfail

i;iþ1ðhÞ

¼ Cfaili;iþ1ðhÞ � q�i;iþ1

1� qj�1i;iþ1

1� qi;iþ1

; qi;iþ1 < 1;

ð7Þ


where h = HAR-e + 1, and HAR-e denotes the hopsbetween the AR and the network entity e. HAR-e =0 when e is the AR itself. When j = 1 (no retransmis-sions), Ci;iþ1ðjÞ 2ðhÞ ¼ 0. This fact can be derivedfrom (7) as well.

The accumulative loads until a successful trans-mission of a pair of request and reply packets onthe jth trial are a sum of the two portions,i.e.,Ci,i+1(j)(h) = Ci,i+1(j)_1(h) + Ci,i+1(j)_2 (h). There-fore, in a given procedure the mean signalling loadsgenerated by both packets under the constraint ofNRM transmissions are calculated as

Ci;iþ1ðhÞ ¼XNRM

j¼1

Ci;iþ1ðjÞðhÞ

¼XNRM

j¼1

qj�1i;iþ1 � ð1� qi;iþ1Þ � ðLi þ Liþ1Þ � h

h i

þXNRM

j¼2

Cfaili;iþ1ðhÞ � qi;iþ1 �

1� qj�1i;iþ1

1� qi;iþ1

" #

¼ ð1� qi;iþ1Þ � ðLi þ Liþ1Þ � h �1� qNRM

i;iþ1

1� qi;iþ1

þCfail

i;iþ1ðhÞ � qi;iþ1

1� qi;iþ1

�XNRM

j¼2

ð1� qj�1i;iþ1Þ

¼ ðLi þ Liþ1Þ � h � ð1� qNRMi;iþ1Þ

þCfail

i;iþ1ðhÞ � qi;iþ1

1� qi;iþ1

� NRM � 1�qi;iþ1ð1� qNRM�1

i;iþ1 Þ1� qi;iþ1

" #;

qi;iþ1 < 1: ð8Þ

For a single packet or a pair of request and responsepackets transmitted between two network entitiesover h wired hops, since no retransmissions areinvoked the signalling loads respectively are givenby

CiðhÞ ¼ Li � h; ð9ÞCi;iþ1ðhÞ ¼ ðLi þ Liþ1Þ � h: ð10Þ

In fact, by examining the first and the second termsof the right hand in (8) we can obtain Ci,i+1(h) ?(Li + Li+1) � h when qi,i+1 ? 0.

Now we can derive the expressions for the signal-ling loads generated in the procedures in Scheme Iand Scheme II, respectively. For the user-triggeredflow handoffs using Scheme I, based on Fig. 4 themean loads in Scenarios A and B are respectivelygiven by

CUsr-HO-AI ¼ CRS;RAð1Þ � NHO-IF þ CUsr-HO-A1

I:BU;BA ðH MH-HAÞ� pmv-npu þ CUsr-HO-A2

I:BU;BA ðHMH-HAÞ� ð1� pmv-npuÞ; ð11Þ

CUsr-HO-BI ¼ CUsr-HO-B

I:BU;BA ðHMH-HAÞ: ð12Þ

The mean subtotal loads generated by both casesare thus given by

CUsr-HOI ¼ kUsr-HO

� pmv � CUsr-HO-AI þ ð1� pmvÞ � CUsr-HO-B

I

� �:

ð13Þ

Note that the mean subnet resident time of a MN iskUsr-HO � pmv

� ��1.

For the same procedure in Scheme II, the signal-ling is different and so are the loads expressions. InScenario A, the BU and BA messages are replacedwith the corresponding SOAP messages; an addi-tional pair of BU and BA is always used for thenew CoA registration. In Scenario B, SOAP mes-sages replace the MIPv6 counterparts. Therefore,in Scheme II the average subtotal loads generatedby both cases are given by

CUsr-HOII

¼ kUsr-HO � pmv � CUsr-HO-AII þ ð1� pmvÞ � CUsr-HO-B

II

� �¼ kUsr-HO � pmv � CUsr-HO-A

II:RS;RA ð1Þ � N HO-IF

�þ CUsr-HO-A1

II:BU;BA ðH MH-HAÞ þ ð1� pmv-npuÞ

�CUsr-HO-A2II:SOAP Req;SOAP RepðH MH-HAÞ

�þ kUsr-HO � ð1� pmvÞ

� CUsr-HO-BII:SOAP Req;SOAP RepðHMH-HAÞ

� �: ð14Þ

For network-triggered flow handoffs using SchemeI, based on Fig. 5 the average subtotal loads are gi-ven by

CNet-HOI ¼ kNet-HO � CICMP ProbeðH AR-NISÞ � N probe

�þCICMP Trigger;ICMP AckðHNIS-HAÞ

�=NMH-tr

þkNet-HO � CNet-HOBRR;BUðH MH-HAÞ

� �; ð15Þ

where N probe ¼ kProbe

kNet-HO � N AR. Note that the averageloads per involved MN generated by a Triggerand a Trigger Ack are obtained by dividing theloads by NMH-tr. This also applies to the Probemessages.

For the same procedure in Scheme II, the averagesubtotal loads are given by


CNet-HOII ¼ kNet-HO � CSOAP ProbeðHAR-NISÞ � Nprobe

�þCSOAP Trigger;SOAP AckðH NIS-HAÞ

�=N MH-tr

þ kNet-HO � CNet-HOSOAP Req;SOAP RepðHMH-HAÞ

� �:

ð16Þ

Supporting procedures include initial multipleCoA registration, default flow binding policy anduser profile registration, periodic flow binding pol-icy refresh, and deregistration. Signalling loads forthese procedures can be derived in a similar man-ner based on Figs. 2, 3, 6 and 7, respectively. Forbrevity, these formulae are not shown in the pa-per. In addition, for an oversized message whoselength exceeds MTUmin, we assume that the mes-sage is broken into a few packets, each of whichis acknowledged by the receiver. Thus, the aboveanalysis is still applicable. This effect is taken intoaccount when we calculate the loads to obtain thenumerical results.

5.3. Message length estimation

The length of a message would directly affect thesignalling loads the message generates. In this sub-section, we estimate the IP-level lengths of theinvolved messages. Firstly, we identify the lengthsof the MIPv6-based mobility messages andICMPv6 messages based on their message formatsdefined in the MIPv6, ICMPv6 specifications, andthe extensions we have proposed. Both MIPv6and ICMPv6 run over UDP by default and useIPsec Encapsulating Security Payload (ESP) trans-port mode [37] for secure signalling. We assumethe SEED-CBC algorithm [38] for encryption, andthe HMAC-MD5-96 algorithm [39] for authentica-tion. Fig. 8 illustrates the packet structure of aBU message.

IPv6 header [CoA, HA](40 bytes)

Destination Options header [HoA](24 bytes)

ESP header (8 bytes) + IV

BU Mobility header (variabmultiple of 8 bytes)

8 + (jBU mhdrL n−

(variable)72 bytes + L(IV) (16 bytes using SEED-CBC)

ESP payload CBC; the lengunchanged)

Fig. 8. Packet structure of a

In a BA or a BRR, the HoA of the MN is storedin a 24-byte Type-2 routing header instead of theDestination Options extension header of the samesize used in a BU, and the BU mobility header isreplaced with the corresponding BA or BRR one.In terms of length expression, these differences donot matter. Therefore, based on Fig. 8 the lengthof a mobility message consisting of n BIDs in proce-dure j is given by

LjMMðnÞ ¼ 100þ 10þ Lj

MM-mhdrðnÞ16

� � 16; ð17Þ

where LjMM-mhdrðnÞ is the length of the mobility head-

er of a BU, a BA, or a BRR. The BU case is shadedin Fig. 8. In addition, the length of an ICMPv6 mes-sage consisting of n AR prefixes (or other parame-ters depending on procedures) in procedure j isgiven by

LjICMPv6ðnÞ ¼ 76þ

14þ LjICMPv6-payloadðnÞ

16

& ’� 16;

ð18Þwhere Lj

ICMPv6-payloadðnÞ is the total length of theICMPv6’s own payload, which accommodates thefunctionality-specific customised message. Note thatthe lengths of the BU, BA and BRR mobility head-ers and the ICMPv6 payload vary from proceduresor the number of BIDs, policies, AR prefixes, trig-gers and so forth.

Table 1 summaries the lengths of the mobilityheaders and the payloads of the ICMPv6 messages.All the procedures or functions refer to Scheme Iunless stated otherwise. Regarding Table 1, in agiven procedure or function n is the number ofinvolved BIDs (i.e., CoA-BID bindings or inter-faces) in a mobility message or the number of ARprefixes (i.e., ARs or access networks) in an ICMPv6

le, UDPheader (8 bytes)

ESP Trailer (padding, the 2-byte headers)

ESP Authentication Data

) bytes Variable (>=2 bytes)

(a multiple of 16 bytes if using SEED-th of the ciphertext remain

Variable (12 bytesusing HMAC-MD5-96)

MIPv6 BU message.

Table 1Lengths (bytes) of mobility headers and ICMPv6 payloads

Message Procedure or function Length of mobility header or ICMPv6 payload

BRR (HA ? MN) Network-triggered flow handoff 8þ 8 � nþ 18 � 4þ

Pni¼1

PNij¼1LFID i;j

� �l m� 8

BU (MN ? HA) Multiple CoA registration (Schemes I, II)12þ 28 � n n P 1;odd16þ 28 � n n P 2; even

Initial default policy registration 32þ 8 � nþ 18 �Pn

i¼1

PNij¼1LFID i;j

l m� 8

User-triggered flow handoff Case A1: new CoA registrationonly (Schemes I, II)

12þ 28 � n n P 1;odd16þ 28 � n n P 2; even

User-triggered flow handoff Case A2: new CoA registrationand policy update

8þ 24 � nþ 18 � 4þ 4 � nþ

Pni¼1

PNij¼1LFID i;j

� �l m� 8

User-triggered flow handoff Case B: policy update only 32þ 8 � nþ 18 �Pn

i¼1

PNij¼1LFID i;j

l m� 8

Network-triggered flow handoff 32þ 8 � nþ 18 �Pn

i¼1

PNij¼1LFID i;j

l m� 8

CoA and policy refresh 8þ 24 � nþ 8 �Pn

i¼1Ni þ 18 � 4þ 4 � nð Þ� �

� 8

CoA refresh only (Scheme II) 12þ 28 � n n P 1;odd16þ 28 � n n P 2; even

Deregistration at the HA (Schemes I, II)12þ 28 � n n P 1;odd16þ 28 � n n P 2; even

BA (HA ? MN) Multiple CoA registration (Schemes I, II) 16 + 8 � n

Initial default policy registration 16þ 8 �Pn

i¼1Ni

User-triggered flow handoff Case A1: new CoA registrationonly (Schemes I, II)

16 + 8 � n

User-triggered flow handoff Case A2: new CoA registrationand policy update

16þ 8 � nþ 8 �Pn

i¼1Ni

User-triggered flow handoff Case B: policy update only 16þ 8 �Pn

i¼1Ni

CoA and policy refresh 16þ 8 � nþ 8 �Pn

i¼1Ni

CoA refresh only (Scheme II) 16 + 8 � nDeregistration at the HA (Schemes I, II) 16 + 8 � n

ICMPv6 Trigger (NSA ? HA) 4þ 16 � NMH-tr þ 20 � nþPn

i¼1

PNij¼1LTID i;j

Trigger Ack (HA ? NSA) 4þ 16 � NMH-tr þ 8 �Pn

i¼1Ni

Profile (MN ? NSA) 40Profile Ack (NSA ? MN) 17Deregistration (MN ? NSA) 17Deregistration Ack (NSA ? MN) 17Probe (AR ? NSA) 16


message. Ni is the number of policies or triggersbound to BIDi or AR prefix i. LFID_i,j and LTID_i,j

are the length of FIDj option and TIDj option forBIDi and AR prefix j, respectively. In addition,based on [28] the length of a RS and its correspond-ing RA are 54 bytes and 104 bytes, respectively.

Next, we estimate the IP-level length of theSOAP messages. We assume SOAP over UDP forefficient signalling and fair comparison betweenSchemes I and II. We also assume textual-basedSOAP messages using IPsec ESP and the sameencryption and authentication algorithms as inScheme I. Fig. 9 shows the structure of an IPv6SOAP message.

Based on Fig. 9, the length of a UDP payloadSOAP consisting of n BIDs in procedure j is given by

LjSOAPðnÞ ¼ 76þ

10þ LjSOAP-hdr-payloadðnÞ

16

& ’� 16;

ð19Þ

where LjSOAP-hdr-payloadðnÞ is the total length of the

SOAP’s own header and payload, which is shadedin Fig. 9 and varies from procedures or the numberof policies, triggers or other parameters. Since SOAPis an application-level protocol, its length can hardlybe precisely identified according to the messagedefinition only. We estimate Lj

SOAP-hdr-payloadðnÞ basedon empirical values regarding the length of a void(skeleton) SOAP-over-UDP message etc. from theliterature [36] and express it as

IPv6 header [CoA, HA](40 bytes)

ESP header (8 bytes) + IV

UDPheader (8 bytes)

SOAP header and payload (variable)

ESP Trailer (padding, the 2-byte headers)

ESP Authentication Data

8 + ( )jSOAP hdr payloadL n− − bytes (variable) Variable (>=2 bytes)

48 bytes + L(IV) (16 bytes using SEED-CBC) ESP payload (a multiple of 16 bytes if using SEED-CBC; the length

of the ciphertext remain unchanged)

Variable (12 bytes using HMAC-MD5-96)

Fig. 9. Packet structure of an IPv6 SOAP message.


LjSOAP-hdr-payloadðnÞ ¼ ðLvoid-SOAP-UDP � LUDP-hdrÞ

þ LjSOAP-hdr-extra þ Lj

SOAP-body

ffi 450þ LjSOAP-body

ffi 450þXk

i¼1

LjSOAP-body-i; ð20Þ

where Lvoid-SOAP-UDP is the length of a void SOAPmessage over UDP (including the length of theUDP header, LUDP-hdr), Lj

SOAP-body is the length ofthe body part of a SOAP message in procedure j,Lj

SOAP-hdr-extra is the length difference introduced bythe header part of a SOAP message in procedure j

compared with that of a void SOAP message, andLj

SOAP-body-i is the length of an item in a request suchas a policy, a trigger, a profile item, a measurementin a Probe or an item in a reply to that in the requestdepending on whether the SOAP message is a re-quest or a reply in procedure j. Lj

SOAP-body is esti-mated as the accumulative length of the k policies,triggers, or other parameters enclosed in the bodypart of a SOAP message.

Table 2Typical values for the input parameters

Parameter Typical value

kInit-MCoA, kDef-policy, kUsr-HO, kNet-HO,kPolicy-Ref, kDereg, kProbe

0.1, 0.08, 2, 2, 2, 0.

n, Ni, NHO-IF, NMH-tr 2, 2, 1, 10NRM 3 for a RS [28]; 7 fobi 10�5

pmv, pmv-npu 0.5, 0.5LFID_i,j, LTID_i,j 36, 16 (bytes)Lj

SOAP-body-i a policy: 100, a triggrequest item: 20, arequest item: 15, a

k The number of poli(i.e., k = n � Ni), thethe number of meas4 (i.e., k = n � Ni), tk = NMH-tr), the nu

HMH-HA, HNIS-HA, HAR-NIS, HMH-NIS 20, 15, 3, 4 (i.e., HM

MTUmin 1280 (bytes) [42]

6. Numerical results

In this section, we illustrate the numerical resultsbased on the above analyses and present corre-sponding explanations and discussions. Table 2 tab-ulates the typical values (unless stated otherwise) forthe input parameters.

Firstly, Fig. 10 depicts the unit signalling loads ofeach procedure generated every time the procedureis invoked. In both schemes, the loads from the ini-tial multiple CoA registration and the deregistrationprocedures are among the lowest and those from thedefault policy and profile registration are the secondhighest. Despite such a difference in the unit loads,their overall contribution to the total signallingloads would be unimportant owing to the very lowrates at which they are provoked. The main contrib-utors would be the remaining three procedures,whose unit loads are not low especially in SchemeII and arrival rates are much higher. Among thethree procedures (and actually all the procedures),the unit loads from network-triggered flow handoffs

1, 60 (h�1)

r the other request messages [4]

er: 80, a profile: 15, a measurement in a Probe: 20, a policy refreshMN’s identifier used in a network trigger: 30, a deregistrationreply item of any request: 15 (bytes) (partially based on [40,41])

cies or triggers or the corresponding reply items in a message: 4number of profile items: 30, the number of profile reply items: 3,

urements in a Probe: 4, the number of policy refresh request items:he number o f MNs’ identifiers in a network trigger: 10 (i.e.,mber of deregistration request or reply items: 3

H-NIS = HAR-NIS + 1)

Uni

t sig

nalli

ng lo

ads

of a

pro

cedu

re (

KB

)

0

10

20

30

40

50Scheme I Scheme II

MCoAregistration

Defaultpolicy

registration

User-triggeredhandoff

Network-triggeredhandoff

Refresh Deregistration

Fig. 10. Unit signalling loads of a procedure.


are the highest because of the periodic Probe mes-sages and the triggers. These additional loads arethe price paid for the network intelligence involvedcompared with the user-triggered handoffs. In addi-tion, the loads from the periodic policy and multipleCoA registration refresh are by no means trivial. Asto a comparison of the two schemes, the unit loadsin Scheme I are extensively smaller than the corre-sponding ones in Scheme II in each procedureexcept the initial multiple CoA registration sharedby both schemes. The reductions in Scheme II rangefrom 31% to 75%. Therefore, we can predict that thetotal loads generated from Scheme I would be con-sistently lower than those from Scheme II. In thefollowing, we scrutinise the total signalling loadsfrom both schemes under different system condi-tions and quantify the differences between the twoschemes.

We start with the effect of the wireless hop’s BER(10�7–10�4) on the total loads, as shown in Fig. 11.Overall, the loads in both schemes increase with theincrease of the BER. Nevertheless, in the range of10�7–10�5 the loads in both schemes remain almostunchanged and the gradual increase is hardlynoticeable. In contrast, when the BER is larger than10�5 the loads in both schemes begin to continu-ously rise significantly especially in Scheme II,where the remarkable increase is 191% from 10�5

to 10�4 compared with the 37% increase in SchemeI. This indicates that deteriorate channel conditionsof the wireless access networks affect Scheme II in a

more severe way, or Scheme I is more resilient to theerror-prone wireless links. The reason lies in the factthat the lengths of the involved SOAP messages inScheme II are much larger than their counterpartsin Scheme I are; and thus the packet loss rate ismuch higher, which leads to more retransmissionsand yields more signalling loads. In contrast toScheme II, Scheme I can decrease the loads by69% under typical wireless channel conditions andup to 86% under seriously lossy conditions. Notethat 10�5 is the typical par value in Wi–Fi networksand should be satisfied normally. Therefore, despitethe differences the loads provoked in Scheme II arestill in an acceptable range under typical conditions.

In Fig. 12, we assume that the rate of non-move-ment-based user handoffs remains the default value(1.0 h�1) when the rate of the movement-basedhandoffs decreases with the increase of the subnetresident time of the MN. The total signalling loadsin both schemes drop sharply first and then slowlywhen the mobile user becomes more and more sta-tic. The resident time 0.5 h is the turning point.The loads decrease 49% and 44% from 0.1 h to0.5 h in Scheme I and Scheme II, respectively whilstjust 18% and 15% from 0.5 h to 2.0 h. When the res-ident time is less than 0.5 h, the rate of movement-based handoffs is larger than 2 h�1 and the corre-spondent contributed loads account for a large por-tion of the total loads and thus the resultant changein the total loads are more obvious. When the resi-dent time is greater than 0.5 h, the loads contributed

Bit Error Rate (BER)

1e-7 1e-6 1e-5 1e-4

Tot

al S

igna

lling

load

s (K

B)

0

100

200

300

400

500

600 Scheme I Scheme II

Fig. 11. Total signalling loads versus BER.


by the movement-based handoffs become more andmore negligible and thus the total loads tend to beunaffected. Regarding the differences between thetwo schemes, Scheme I reduces 65–70% loads withthe increase of a MN’s subnet resident time.

Furthermore, as indicated in Fig. 13 the numberof policies or triggers carried in a message growsand so do the total signalling loads when moreinterfaces are equipped and activated and more cor-responding ARs are involved. Note that the growth

MH subnet res

0.0 0.5 1.0

Tot

al s

igna

lling

load

s (K

B)

0

100

200

300

400

Scheme I Scheme II

Fig. 12. Total signalling loads vers

of the loads is not linear in Scheme II. When thenumber of a MN’s active interfaces is two (thedefault value), every messages in both schemes isnot oversized and thus is carried in a single packet.When more active interfaces are used, some SOAPmessages become oversized: a SOAP message sig-nalling policies (for registration or update) wouldneed one extra packet when the number of activeinterfaces reaches four and over; a SOAP triggermessage would require two or three packets in case

ident time (hour)

1.5 2.0

us MN subnet resident time.

Number of active interfaces (or BIDs, or involved ARs)

2 3 4 5 6

Tot

al s

igna

lling

load

s (K

B)

0

100

200

300

400Scheme I Scheme II

41 KB

75 KB

Fig. 13. Total signalling loads versus active interfaces.


of three to five interfaces and more than six inter-faces, respectively. In contrast, no mobility messageor ICMPv6 messages demand more than onepacket in the concerned range of interfaces. There-fore, there is a much larger leap (from 41 KB to75 KB) when the active interfaces become four inScheme II whilst the rise is almost consistently slowand linear in Scheme I (15–16 KB). The total loadsin Scheme I are 69–71% smaller than those inScheme II. When the polices enclosed in a messageincreases whilst the number of active interfacesremains unchanged, the results are similar withthose shown in Fig. 13 and thus they are not illus-trated here for brevity.

Table 3Comparison of Scheme I and Scheme II

Signalling performance Scheme I

Standardisation Core protocol specificationand development

IETF draMULTIN

Compression Not needBinary characterisation Already

Interoperability Protocol availability MIPv6, I(or UDP

Protocol layer Pure netw

Reliability Lost packet recovery RetransmEfficiency Signalling loads Low (con

Security Encryption, authentication IPsecExtensibility Modifiability to developers Moderat

Finally, we can sum up the above analyses. Thesignalling loads generated in Scheme I are consis-tently low mainly because that the messages basedon binary MIPv6 and ICMPv6/UDP codes aremuch more compact. In addition, the signalling pro-cedures in Scheme I are more efficient due to theintegration of the binding refresh and the policyrefresh, which are separate routines in Scheme II.In contrast, the loads invoked in Scheme II are sig-nificantly higher mainly owing to the lengthy textualSOAP messages that support MIPv6 although theloads in Scheme II are still reasonable under typicalsystem conditions. There are a couple of potentialways to alleviate the verbosity of textual SOAP mes-

Scheme II

ft [9,10] andET deliverables

IETF draft [9,11] andMULTINET deliverables

ed Not standardisedcoded in binary format Work in progress [44]CMPv6directly)

MIPv6, SOAP (UDP orHTTP web service)

ork layer Network layer andapplication layer

ission (UDP) Retransmission (UDP or TCP)sistently) Moderate when over UDP

(can be high e.g., in highly lossynetworks, or many activeinterfaces or policies)IPsec or HTTPS

e High (regarding SOAP)


sages. Firstly, it is noted that at the costs of extraprocessing requirements and overheads, compres-sion would be helpful to shrink the size of very largeSOAP messages. Unfortunately, it is well observed[40,43] that for SOAP messages smaller than theminimum MTU (1280 bytes [42]) compression mayactually expand the length of the message due tothe intrinsic overheads in a compression algorithmsuch as gzip. Alternatively, binary encoding or char-acterisation is another prospective approach. Never-theless, this approach would raise interoperabilityconcerns since no standard SOAP binary encodinghas been widely adopted though this work is in pro-gress in W3C [44] towards a standard solution.Table 3 lists a comparison of Scheme I and SchemeII based on the proposed design, the analyticalresults, and other considerations. We may concludethat the two proposed schemes would adequatelysatisfy most of the common design requirements intypical scenarios. Especially, Scheme I boasts itshigh signalling efficiency whilst Scheme II is moreadvantageous in message extensibility thanks tothe XML-based formats of the SOAP messages.

7. Implementations and experimental results

To complement the analytical work and furtherassess the performance of the proposed signallingschemes, we have constructed a local IPv6 wirelesstestbed. In this section, we present our testbedimplementations and experimental results.

7.1. Testbed setup

Note that in principle our proposed schemes areapplicable to both MIPv6 and its network mobilityextension NEMO. We chose NEMO for demonstra-tion in our testbed since the available NEMO imple-mentation NEPL [45] is more mature in

Table 4Testbed hardware and software

Node Hardware Third-party

NSA, CN VIA Samuel 2(600 MHz, 512 MB RAM)

Apache2, P(FTP serve

HA VIA Nehemiah(1.00 GHz, 256 MB RAM)

Apache2, P

MR VIA Nehemiah(1.20 GHz, 512 MB RAM)

Apache2, P

MNN Pentium D(2.80 GHz, 1 GB RAM)

ftp (FTP cl

AR1, AR2 Linksys WRT54GL OpenWRT

multihoming support compared with its MIPv6counterpart MIPL [46].

Table 4 lists the hardware and software settings.A set of Linux PCs are configured to act as theNSA, the CN, the HA and the NEMO mobile rou-ter (MR) with two Wi-Fi cards. The mobile networknode (MNN) is a Windows XP PC in the mobilenetwork whose multihoming and mobility proxy isthe MR. One can deem that the MR plus theMNN is equivalent to the mobile host in MIPv6.The NSA, the network trigger generator, is collo-cated with the CN, which is a video streaming serverand a FTP server for the MNN. The VLC [47] andthe proftpd [48] software are used for video stream-ing and FTP, representing typical real-time andnon-real-time applications respectively. A coupleof 802.11 b/g ARs with OpenWRT [49] as operatingsystem provide the multihomed MR with two wire-less connections (and thus two separate routesbetween the HA and the MR). The bit rate of thewireless channels is set to be 11 Mbps by defaultduring the following experiments. The testbedtopology is illustrated in Fig. 14.

The handoff execution functionality was builtupon the NEMO implementation NEPL with inte-grated MCoA support. Once a trigger is receivedand parsed, the enclosed policies are installed andenforced with the ip6tables at the HA and the MR.The subsequent packets meeting a policy are markedwith the corresponding BID, e.g., 100 or 200. A rout-ing table per BID is generated, e.g., routing tables #100 and # 200. These tables are looked up for for-warding the marked packets to the correspondinginterfaces. IPv6 stateless host auto-configurationwas achieved through the radvd module [50]. Themultihomed MR automatically configures a CoAfor each of its interfaces and registers the CoAs withthe HA via the MCoA support. Based on the pro-posed Schemes I and II, we have implemented two

software Software

HP5, proftpdr), VLC (video server)

Scheme I: UDP_NSAScheme II: SOAP_NSA

HP5, NEPL + MCoA, radvd Scheme I: UDP_HAScheme II: SOAP_HA

HP5, NEPL + MCoA, radvd Scheme I: UDP_MRScheme II: SOAP_MR

ient), VLC (video client)

, radvd

Fig. 14. Testbed topology.


signalling methods. The first is a variant of Scheme I:it operates over UDP (the ICMPv6 header isoptional) whereas it does not modify the mobilitymessages directly as the MIPv6 BRR message hasnot been available in the current NEMO. The otherone is a HTTP-version realisation of Scheme II. Itwas coded in SOAP messages and developed withPHP5 [51], which has built-in C-based SOAP overHTTP (SOAP over UDP has not been available inPHP5). Apache2 [52] was installed as the HTTP ser-ver. Both implemented schemes were verifiedthrough experiments to achieve the distributionand enforcement of dynamic triggers. Each triggeris composed of one or more policies, which areenforced by manipulating the ip6tables.

7.2. Experimental results

On our testbed, we have designed and conducteda set of experiments including validation and com-parisons of the two implemented signalling schemesand measuring handoff signalling delays, validationof handoffs of different application flows betweeninterfaces, subjective perception of a real-time appli-cation (video streaming), and objective evaluationof a non-real-time application (FTP file download-ing). In the experiments, we focused on network-ini-tiated flow handoffs triggered by intelligent networkselection rather than user movement due to the tar-geted user scenario in MULTINET.

7.2.1. Handoff signalling delay

We started with assessing the implementations ofthe proposed schemes with the handoff signallingdelays measured. The handoff signalling delay isdefined as the elapsed time between a trigger is gen-erated by the NSA and a final acknowledgement isreceived at the NSA from the HA (on completingthe distribution and enforcement of both the triggerat the HA and the symmetric trigger at the MR).Fig. 15 depicts the handoff signalling delay in bothimplementations when the number of policies codedin a trigger varies. Each policy consists of a full five-tuple to identify a flow and a BID [9] to identify aninterface. The action of each policy is adding.Experiments for each scenario were performedrepeatedly and the mean values are reported here.We have examined three cases, where the two mech-anisms operated in the default 11-Mbps wirelesschannel to compare their performances and addi-tionally the UDP-based mechanism (Scheme I)operated under the 1-Mbps condition to show theeffects of the wireless channel bandwidth.

Firstly, as expected the delays in all the casesincrease with the growth of the number of policiesbecause of the increasing latencies invoked fortransmitting and processing more policies. Despiteall the differences to be discussed, all the delaysare well under one second. Furthermore, the delaysgenerated under conditions of the lower date rate(1 Mbps) are higher than those with the higher date

Number of policies in a trigger

1 2 3 4 5

Han

doff

sign

allin

g de

lay

(s)

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Scheme I: UDP 11 MbpsScheme I: UDP 1 MbpsScheme II: SOAP 11 Mbps

Fig. 15. Handoff signalling delay vs. number of policies in a trigger.


rate (11 Mbps) are as shown in the ‘‘UDP 1 M” and‘‘UDP 11 M” cases. The relative difference betweenthe signalling delays achieved by each schemeincreases with the number of policies since eachmore policy tends to enlarge the difference.

Secondly, overall the two schemes appear toincur comparable delays when both operated in11 Mbps in our local testbed. When the number ofpolicies in a trigger is small (one or two), the UDPone generates a clear-cut lower delay although thedifference is decreasing with the number of policiesincreases. When three or four policies are coded ina trigger, the difference in the delays is negligible.In the scenario of five policies in a trigger, the SOAPapproach yields a significantly lower delay. There-

Fig. 16. Policy-based flow han

fore, it seems that the UDP scheme is more effectivewhen the number of policies in a trigger is smallwhilst the SOAP one seems more advantageouswhen the number becomes high. The reason behindthis observation seems to be implementation spe-cific. The SOAP-based implementation utilised thebuilt-in XML object handling for parsing and pro-cessing the policies, and thus Scheme II appearsmore efficient for larger number of policies.

It is noted that the handoff signalling delay in theSOAP/HTTP-based mechanism includes an addi-tional latency for the three-way TCP handshakefor each connection establishment between thenodes, whilst the delay excludes the latency forfetching the web services description language

doffs between interfaces.

Sym

met

ric

po

licy

Ad

dr

srcP

ort

dst

Po

rtP

roto

col

IFsr

cAd

dr

dst

Ad

dr

srcP

ort

dst

Po

rtP

roto

col

IF

1:19

2:16

8:3:

:100

1234

UD

PIF

11:

192:

168:

3::1

0020

TC

PIF

120

01:1

92:1

68:3

::10

020

01:1

92:1

68:1

06::

1020

TC

PIF

11:

192:

168:

3::1

0012

34U

DP

IF2


(WSDL) files. The WSDL files define the proposednetwork services. The latency for fetching theWSDL files is only incurred at the first time beforea trigger is ever transferred or when the local WSDLcaches expire after 24 h. In contrast, no connectiondelays (or the WSDL latency) are incurred in theUDP-based approach. Nevertheless, in our localisedhigh-speed testbed, the TCP connection delays areinsignificant since the transmissions of messagesare overwhelmingly fast.

We conjecture that when the schemes aredeployed in a wide-area network (WAN), thelatency between the HA and the AR would leadto a disadvantage for the SOAP/HTTP mechanismas three additional one-way Internet delays wouldbe incurred for connection setup. It is expected thatthe UDP approach would avoid such extra delays.Consequently, the flow handoff process would beaccelerated so that the aim of the handoff (typicallyfor load sharing/balancing to the targeted nomadicusers) can be achieved sooner. We also note that sig-nalling delay would rise with the WAN propagationdelay. Nevertheless, typically such additional signal-ling delay would not effectively affect the smooth-ness of flow handoffs. The reason is as follows. Inwireless overlays networks, multiple interfaces con-nect to their serving ARs simultaneously. During aflow handoff, the original interface is being usedcontinuously until the flow is handed over to thetarget interface. This is the advantage of multihom-ing-based handoffs in contrast to traditional break-before-make handoffs. Therefore, it is envisionedthat smooth flow handoffs would still be achievableeven in a WAN environment. In future work, wewould enhance our current testbed for further inves-tigations in broader scenarios. Part of the enhance-ments would include a WAN emulator such asnetem or NIST Net.

Tab

le5

Tri

gger

san

dp

oli

cies

Tim

ein

stan

ceT

rigg

erP

oli

cy

srcA

dd

rd

st

T1

Tri

gger

120

01:1

92:1

68:1

06::

1020

0T

3T

rigg

er2

2001

:192

:168

:106

::10

200

2001

:192

:168

:106

::10

200

7.2.2. Flow handoff effectiveness

Next, we have performed numerous tests to ver-ify the effectiveness of the proposed policy-basedflow handoffs. In the following, we present a casestudy of flow handoffs of two different applications,video streaming and FTP file downloading. As illus-trated in Fig. 16, the X axis represents the timesequence of the experiment whilst the Y axis showsthe traffic volume of the application flows. Table 5lists the details of the involved policies. A flow inthis case is identified by a four-tuple: source address(srcAddr), destination address (dstAddr), source or


destination port number (srcPort or dstPort), andtransport protocol.

At T0, a RTP/UDP-based video streaming hasbeen established and is being transmitted from theCN towards the MNN via the MR. By default, alltraffic travels through IF2 of the MR and the corre-sponding interface of the HA.

At T1, the NSA issued Trigger 1, which containsone policy to be enforced at the HA. The policyindicates that the ongoing video streaming shouldbe handed off from IF2 to IF1. The symmetric pol-icy for the MR is optional as the streaming is a one-way traffic (no uplink traffic for acknowledgementor reverse streaming). After the policy is enforcedat the HA, the streaming flow is handed over fromIF2 to IF1.

This handoff decision could be made accordingto the output of the intelligent network selectionalgorithm for load sharing, fault tolerance or user/application preferences. For instance, the NSAhad detected that the route via IF1 was underuti-lised or the route via IF2 was overloaded (or tempo-rarily going down). It could also result form anestablishment request of a new application session(e.g., the subsequent FTP downloading), whichhas the priority to use the IF2 route.

At T2, a FTP file transfer was initiated by theMNN to download a large file from the CN. Again,by default the FTP flow (from the CN to the MNN)and the TCP ACK flow (from the MNN to the CN)were transmitted through IF2.

At T3, the NSA issued Trigger 2, comprising twopolicies. One policy is to switch the FTP flow from

Fig. 17. FTP flow hand

IF2 to IF1. A symmetric policy was also generatedat the HA for the MR to redirect the TCP ACKstogether. Meanwhile, the other policy demands thatthe video streaming be handed off from IF1 to IF2.The symmetric policy to the latter one is optional.Consequently, the three flows were handed over tothe targeted interfaces, respectively.

Such experiments were repeated with randomflow handoffs of the applications between the inter-faces. When the flow handoffs occurred in theseexperiments, no noticeable disruptions were per-ceived by a number of observers viewing the videostreaming at the MNN. Therefore, it seems thatthe flow handoffs do not significantly degrade thesubjective QoS of real-time applications.

Further experiments were carried out to investi-gate the performance of the FTP/TCP applicationsunder flow handoff conditions. Fig. 17 demonstratesa typical result showing the sequence numbers of thereceived TCP segments at the MNN as the time of aFTP downloading elapsed. As shown in Fig. 17, theTCP segments received at the MNN are in goodorder all the time despite the fact that a couple offlow handoffs were experienced at the time instancesaround 11 s and 34 s, respectively. It is noted thatthe time instances on the X axis are not evenly dis-tributed since the FTP downloading is not of con-stant bit rate (CBR) as can be found from Fig. 16.Such in-sequence delivery was also found in addi-tional flow handoff experiments for a TCP flow ofCBR. As illustrated in Fig. 18 (with the X axis plot-ted to scale), although three handoffs occurred dur-ing the session, packets were well received.

off performance.

Fig. 18. TCP (CBR) flow handoff performance.


The experiments presented in this section havevalidated the overall design and provided prelimin-ary performance results of each signalling scheme.The experiments illustrate that the handoff mecha-nisms are appropriate when both real-time andnon-real-time applications are involved.

8. Conclusion

To advance the design and evaluation of flowhandoff support for multihomed mobile users inwireless overlay networks, we have proposed andevaluated two signalling schemes to achieve com-prehensive and standard-oriented flow handoffmanagement. The proposed schemes greatly extendand optimise the work-in-progress specifications inthe IETF to support both user- and network-trig-gered flow handoffs based on MIPv6/NEMO. Bothhandoff methods are able to meet the requirementsimposed by applications and by the network pro-vider. The major differences between the twoschemes lie in signalling efficiency and messageextensibility.

Scheme I utilises the potentials of mobility mes-sages with supporting ICMPv6/UDP messagedefined. The design of the binary-coded messageformats is not straightforward although the resul-tant messages would be very compact and thuswould be outstandingly bandwidth efficient. Theanalyses on signalling loads clearly highlight thisadvantage under various conditions. The numericalresults indicate that Scheme I can reduce around

70% total signalling loads in most cases comparedwith Scheme II. On the other hand, Scheme II isbased on textual SOAP messages. Nevertheless,Scheme II still appears reasonable in signalling effi-ciency under typical conditions. Furthermore, theXML-based SOAP messages are organised in amuch more readable, editable, and extensible wayand thus Scheme II seems understandably moreappealing to developers.

Preliminary implementations in our testbed havevalidated the concepts and effectiveness of the pro-posed designs in achieving policy-based flow hand-offs. The experimental results show that smoothflow handoffs triggered by the network for nomadicusers seems achievable for both real-time and non-real-time applications. In addition, when transmis-sion delays are low as in broadband hybrid wiredand wireless networks as demonstrated in our test-bed, the processing delays would dominate the flowhandoff signalling delays. In that context, the twoschemes seem to generate comparable handoff sig-nalling delays.

In conclusion, Scheme I outperforms Scheme IIin signalling efficiency, which would be desired espe-cially when links of narrow bandwidth are involved.In contrast, Scheme II is superior in signalling read-ability and extensibility, which have well facilitatedthe integration process in our joint project. Bothschemes invoke decent flow handoff signallingdelays and smooth flow handoffs seem promising.Future work would further investigate the effectsof the proposed schemes in large-scale networks.


Acknowledgement

This work is sponsored by the EU IST MULTI-NET project (www.ist-multinet.org). The authorswould like to thank for our project partners in-volved in the discussions on this topic. The authorsalso appreciate the anonymous reviewers’ insightfulremarks and scrupulous editing.

References

[1] Y.-B. Lin, A.-C. Pang, Wireless and Mobile All-IP Net-works, Wiley, New York, 2005.

[2] E. Gustafsson, A. Jonsson, Always best connected, IEEEWireless Communications 10 (1) (2003) 49–55.

[3] O. Lazaro, A. Gonzalez, L. Aginako, T. Hof, F. Sidoti, P.Vaquero, et al., MULTINET: enabler for next generationservices, in: Proceedings of the 17th Wireless WorldResearch Forum (WWRF) Meeting, Heidelberg, Germany,November 2006.

[4] D.B. Johnson, C. Perkins, J. Arkko, Mobility support inIPv6, IETF RFC 3775, June 2004.

[5] H. Soliman, C. Catelluccia, K.E. Malki, Ludovic Bellier,Hierarchical mobile IPv6 mobility management (HMIPv6),IETF RFC 4140, August 2005.

[6] R. Koodli (Ed.), Fast handovers for mobile IPv6, IETF RFC4068, Jul 2005.

[7] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert,Network mobility (NEMO) basic support protocol, IETFRFC 3963, January 2005.

[8] M. Yabusaki, T. Okagawa, K. Imai, Mobility managementin all-IP mobile network: end-to-end intelligence or networkintelligence? IEEE Communications Magazine 43 (2) (2005),supl. 16–supl. 24.

[9] R. Wakikawa, T. Ernst, K. Nagami, Multiple care-ofaddresses registration, IETF Internet Draft. <draft-wakika-wa-mobileip-multiplecoa-05.txt>, work in progress, Febru-ary 2006.

[10] H. Soliman, N. Montavont, N. Fikouras, K. Kuladinithi,Flow bindings in mobile IPv6, IETF Internet Draft. <draft-soliman-monami6-flow-binding-02.txt>, work in progress,September 2006.

[11] K. Mitsuya, K. Tasaka, R. Wakikawa, A schema fragmentfor flow distribution, IETF Internet Draft. <draft-mitsuya-monami6-flow-distribution-00.txt>, work in progress, June2006.

[12] M. Gudgin, M. Hadley, J.-J. Moreau, H.F. Nielsen, SOAP1.2 part 1: messaging framework, W3C Recommendation,June 2003.

[13] R. Stewart, Q. Xie, K. Morneault, et al., Stream con-trol transmission protocol, IETF RFC 2960, October2000.

[14] J.R. Iyengar, P.D. Amer, R. Stewart, Concurrent multipathtransfer using SCTP multihoming over independent end-to-end paths, IEEE/ACM Transactions on Networking 14(2006) 951–964.

[15] S.J. Koh, M.J. Chang, M. Lee, mSCTP for soft handover intransport layer, IEEE Communications Letters 8 (3) (2004)189–191.

[16] A. Argyriou, V.K. Madisetti, A soft-handoff transportprotocol for media flows in heterogeneous mobile networks,Computer Networks 50 (2006) 1860–1871.

[17] R. Moskowitz, P. Nikander, Host identity protocol archi-tecture, IETF RFC 4423, August 2005.

[18] IEEE P802.21TM/D00.01, Draft IEEE specification for localand metropolitan area networks: media independent hand-over services, July 2005.

[19] N. Yamai, K. Okayama, H. Shimamoto, T. Okamoto, Adynamic traffic sharing with minimal administration onmulti-homed networks, in: Proceedings of the IEEE Inter-national Conference on Communications (ICC’01), Helsinki,Finland, June 2001.

[20] D.S. Phatak, T. Goff, J. Plusquellic, IP-in-IP tunnelling toenable the simultaneous use of multiple IP interfaces fornetwork level connection striping, Computer Networks 43(2003) 787–804.

[21] C. Huang, C. Tsai, P. Su, MultiGate6: an IPv6 multihominggateway using a hybrid approach, Computer Communica-tions 29 (2006) 1842–1857.

[22] H.J. Wang, R.H. Katz, J. Giese, Policy-enabled handoffs acrossheterogeneous wireless networks, in: Proceedings of the 2ndIEEE Workshop on Mobile Computing Systems and Applica-tions (WMCSA’99), New Orleans, USA, February 1999.

[23] S. Balasubramaniam, J. Indulska, Vertical handover sup-porting pervasive computing in future wireless networks,Computer Communications 27 (2004) 708–719.

[24] D.K. Goldenberg, L.L. Qiu, H.Y. Xie, Y.R. Yang, Y.Zhang, Optimising cost and performance for multihoming,Computer Communications Review 34 (2004) 79–92.

[25] K. Shima, Y. Uo, N. Ogashiwa, S. Uda, Operationalexperiment of seamless handover of a mobile router usingmultiple care-of address registration, Journal of Networks 1(3) (2006) 23–30.

[26] S. Kent, K. Seo, Security architecture for the Internetprotocol, IETF RFC 4301, December 2005.

[27] J. Arkko, V. Devarapalli, F. Dupont, Using IPsec to protectmobile IPv6 signalling between mobile nodes and homeagents, IETF RFC 3776, June 2004.

[28] T. Narten, E. Nordmark, W. Simpson, Neighbour discoveryfor IP version 6 (IPv6), IETF RFC 2461, December 1998.

[29] S. Thomson, T. Narten, IPv6 stateless address autoconfig-uration, IETF RFC 2462, December 1998.

[30] Q. Wang, M.A. Abu-Rgheff, IPv6-based architecture for fastand cost-effective micro-mobility management, in: Proceed-ings of the IEE 6th International Conference on 3G andBeyond (IEE 3G2005), London, UK, November 2005.

[31] Y.-H. Han, S.-H. Hwang, Movement detection analysis inmobile IPv6, IEEE Communications Letters 10 (1) (2006)59–61.

[32] M. Bafutto, P.J. Khn, G. Willmann, Capacity and perfor-mance analysis of signalling networks in multivendorenvironments, IEEE Journal on Selected Areas in Commu-nication 12 (3) (1994) 490–500.

[33] Q. Wang, M.A. Abu-Rgheff, Signalling analysis of cost-efficient mobility support by integrating mobile IP and SIP inall IP wireless networks, International Journal of Commu-nication Systems 19 (2) (2006) 225–247.

[34] I.F. Akyildiz, W. Wang, A dynamic location managementscheme for next generation multi-tier PCS systems, IEEETransactions on Wireless Communications 1 (1) (2002) 178–189.

http://www.ist-multinet.org


[35] M. Gudgin (Ed.), SOAP-over-UDP, Technical Specification,September 2004.

[36] K.A. Phan, Z. Tari, P. Bertok, A benchmark on SOAP’stransport protocols performance for mobile applications, in:Proceedings of the 2006 ACM Symposium on AppliedComputing (SAC’06), Dijon, France, April 2006.

[37] S. Kent, R. Atkinson, IP encapsulating security payload(ESP), IETF RFC 2406, November 1998.

[38] H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee, The SEED cipheralgorithm and its use with IPsec, IETF RFC 4196, October2005.

[39] C. Madson, R. Glenn, The use of HMAC-MD5-96 withinESP and AH, IETF RFC 2403, November 1998.

[40] J. Kangasharju, T. Lindholm, S. Tarkoma, Requirementsand design for XML messaging in the mobile environment,in: Proceedings of the 2nd International Workshop on NextGeneration Networking Middleware, Waterloo, Canada,May 2005.

[41] A. Ng, S. Chen, P. Greenfield, An evaluation of contempo-rary commercial SOAP implementations, in: Proceedings ofthe AWSA’04, Melbourne, Australia, April 2004.

[42] S. Deering, R. Hinden, Internet protocol, version 6 (IPv6)specification, IETF RFC 2460, December 1998.

[43] A. Ng, P. Greenfield, S. Chen, A study of the impact ofcompression and binary encoding on SOAP performance, in:Proceedings of the 6th Australasian Workshop on Softwareand System Architecture (AWSA’05), Brisbane, Australia,March 2005.

[44] O. Goldman, D. Lenkov (Eds.), XML binary characterisa-tion, W3C Working Group Note, work in progress, Mar2005.

[45] NEMO Implementation for Linux (NEPL). <http://www.nautilus6.org/nemo/>.

[46] Mobile IPv6 for Linux (MIPL). <http://mobile-ipv6.org/>.[47] VLC media player. <http://www.videolan.org/vlc/>.[48] Proftpd FTP server. <http://www.proftpd.org/>.[49] OpenWRT. <http://openwrt.org/>.[50] Linux IPv6 Router Advertisement Daemon (radvd). <http://

www.litech.org/radvd/>.[51] Hypertext Preprocessor (PHP). <http://www.php.net/>.[52] Apache HTTP Server. <http://httpd.apache.org/>.

Qi Wang received his BEng in ElectronicEngineering and MEng in Communica-tion and Electronic System from DalianMaritime University, China, in 1995 and1998, respectively; and his PhD inMobility Support Architectures forNext-Generation Wireless Networksfrom the University of Plymouth, UK, in2006. He was granted a multi-year Brit-ish ORS award for his PhD programme.From 1998 to 2001, he was with the State

Grid Corporation of China (Shandong) as an ICT engineer. Since2006, he has been working on an EU IST FP6 project MULTI-

NET as a postdoctoral research fellow with the University ofStrathclyde, UK. His current research interests include IP net-works, mobility management and multihoming support. He is amember of IEEE and on the technical programme committees ofIEEE PIMRC’08 and CCNC’09.

Robert Atkinson is a Lecturer for Com-munications and Signal Processing,University of Strathclyde, UK. Hecompleted his PhD in Mobile andWireless Communications at Strathclydein 2003. Throughout his time at theUniversity he has worked on a variety oftopics from Medium Access Control toHeterogeneous Networking. He isactively researching intelligent accessnetwork selection, user mobility solu-

tions and Ad Hoc Networking. He is a senior member of IEEEand member of IET.

John Dunlop received the BSc degree inelectrical engineering from UniversityCollege of Swansea in 1966 and the PhDdegree in telecommunications from theUniversity of Wales in 1970. He is cur-rently a Professor of Electronic SystemsEngineering and Head of the MobileCommunications Group, University ofStrathclyde, UK. He has recently com-pleted a three-year term as a Director ofthe UK Virtual Centre of Excellence in

Mobile and Personal Communications. He has been involved inresearch programs in communication systems and electronic
systems engineering for more than two decades. This includesparticipation in RACE Definition Phase, RACE Mobile Com-munications Project (R1043), RACE Advanced Time DivisionMultiple Access ATDMA (R2084), and ACTS Mobile Com-munications Services for High-Speed Trains MOSTRAIN(AC104) and as a full academic member of the UK VirtualCentre of Excellence in Mobile and Personal Communications.He has held several UK Engineering and Physical SciencesResearch Council (EPSRC) awards on local area communica-tions, underwater communications, and mobile communicationsand holds contracts from the Mobile VCE covering work in theareas of Networks and Services. He is also holder of severalcontracts with mobile communications companies. He is authorand co-author of more than 150 scientific papers on ElectronicsSystems Engineering and Communications Engineering ininternational journals and conferences. He is co-author of Tele-
communications Engineering which has been adopted as a stan-dard text in many British Universities and a co-author of Digital

Mobile Communications and the TETRA System (New York:Wiley, 1999).

http://www.nautilus6.org/nemo/

http://www.nautilus6.org/nemo/

http://mobile-ipv6.org/

http://www.videolan.org/vlc/

http://www.proftpd.org/

http://openwrt.org/

http://www.litech.org/radvd/

http://www.litech.org/radvd/

http://www.php.net/

http://httpd.apache.org/

design and evaluation of ﬂow handoﬀ signalling for...

Documents