Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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.
.
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
1650 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1651
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.
1652 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1653
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.
1654 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1655
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.
1656 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1657
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.
1658 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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,
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1659
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Þ
1660 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1661
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
1662 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1663
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.
1664 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1665
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.
1666 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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)
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1667
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.
1668 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1669
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
1670 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
(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
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1671
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.
1672 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
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.
Q. Wang et al. / Computer Networks 52 (2008) 1647–1674 1673
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.
1674 Q. Wang et al. / Computer Networks 52 (2008) 1647–1674
[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).