Final UBICC Manuscript HTM 347

8/7/2019 Final UBICC Manuscript HTM 347

1/14

Ubiquitous Computing and Communication Journal 1

ADAPTIVE END-TO-END MOBILITY SCHEME FOR SEAMLESS

HORIZONTAL AND VERTICAL HANDOFFS

Abdellatif Ezzouhairi, Alejandro Quintero, Samuel PierreMobile Computing and Networking Research Laboratory (LARIM)

Department of Computer Engineering, cole Polytechnique de MontralP.O. Box 6079, succ. Centre-Ville, Montreal, Quebec, H3C 3A7, Canada

Phone: (514) 340-3240 ext. 4685. Fax: (514) 340-3240E-mail: {Abdellatif.Ezzouhairi; Alejandro.Quintero; Samuel.Pierre}@polymtl.ca

ABSTRACT

Mobility management constitutes one of the most significant task to beinvestigated for Next Generation Mobile Networks (4G). Motivated byconnectivity facilities and flow control offered at the transport layer, a number ofStream Control Transmission Protocols (SCTPs) based mobility schemes havebeen proposed to handle this important issue. However, these proposals arehindered by drawbacks such as unnecessary handoff delays incured by horizontal

handoffs. Moreover, the throughput measured immediately after a handoff isaffected quite considerably by spurious retransmissions due to failed SelectiveAcknowledgment messages (SACKs) and data retransmission lost. This paperproposes a new Hierarchical Transport layer Mobility protocol (HTM) that dealswith local and global mobility and improves throughputs during the handoff period.HTM exploits the dynamic address reconfiguration feature of SCTP and introducesan Anchor Mobility Unit (AMU) in order to complete more efficient handoffprocedures. Simulation and numerical results reveal that HTM guarantees lowerhandoff latency and packet loss, good throughput and limited signaling loadcompared to mSCTP (mobile SCTP) based mobility.

Keywords: Heterogeneous networks, mobility management, SCTP, end-to-endroaming.

1 INTRODUCTIONThe next generation of mobile communication

systems, referred to as 4G, 3G+ or beyond 3G, isintended to integrate both current and emergingmobile networks around an IP backbone. Forexample, this will include second and thirdgeneration cellular networks (2G and 3G), satellitesystems, Wireless Local Area Networks (WLANs),amongst others. Since each technology is tailored toreach a particular market or a specific type of userservices, integrating these heterogeneous systemsbecomes highly interesting as they offer manypossibilities to increase bandwidth, Internetaccessibility and area coverage. For example, amobile user may choose to access a WLAN to senda large data file, but selects a 3G cellular network toplace a voice call. However, implementing this typeof integrated system implies numerous challengesin mobile handset design, wireless systemdiscovery, terminal mobility, security and billing[1]. Mobility management remains the mostsignificant task to be investigated since it aims toguarantee mobile users disruption-free connectionswhile roaming through heterogeneous networks.Traditionally, mobility management comprises

location managementand handoff management[4].Location management is a process which

allows networks to localize mobile users currentattachment point for data delivery.

Handover or handoff management enables thenetwork to sustain mobile user connections, whilethey move and change network access points.

Handoff mechanisms are usually categorizedinto: hard and soft handoffs. A hard handoff, alsoknown as break-before-make, is completed by firstdisconnecting with the current access point beforeswitching to another one. This type of handoffmechanism is particularly suitable for delay-tolerant communications traffic. On the other hand,the soft handoff also known as make-before-break,is employed by establishing a connection with anew access point before disconnecting from theexisting point of attachment. This category ofhandoff mechanism is particularly suitable forhandling latency-sensitive communication servicessuch as videoconferencing. In this sense, Mobile IP[6] and its further enhancements such as HMIPv6[7], FMIPv6 [8] and FHMIPv6 [9] are consideredamong the IETF standards widely accepted to dealwith mobility management. However, this categoryof mobility schemes suffers from weaknesses such


2/14


as handoff latency, packet loss and signaling loadpertaining to the number of bindings to be executed.In addition, certain mobility schemes based on TCP[10] and SIP [11] have been investigated asalternate solutions to the traditional mobile IP.Generally, these proposals need tremendous

modifications in both protocol stacks and networkarchitecture [12]. With the standardization of SCTP[13], and more particularly with its novel ADDIPExtensions [14], more attention has been paid toexperiment mobility over the transport layer.Actually, the transport layer mobility schemes donot depend on the underlying infrastructures andoffers the possibility to control the flow and topause transmission in expectation of a handoff.Thus, a number of solutions which exploit themultihoming features of SCTP have beenintroduced. Yet, to the best of our knowledge, noneof these proposed approaches deal with local

mobility at the transport level. This means thatcurrent SCTP-based mobility proposals focus onthe multihoming feature and do not consider thefact that most of the MN's handoffs are completedinside the same wireless technology (i,e., horizontalhandoff). Note that inside an homogeneoustechnology, an MN may not simultaneously use itstwo wireless interfaces for communication [15].Obviously, this leads to superfluous delays due toL2 handoff, movement detection, authenticationand address configuration. Moreover, certainhidden effects pertaining to fast handovers, such asfailed SACKs (Selective Acknowledgements) are

not addressed.The main concern of this paper is to propose anew Hierarchical Transport layer Mobility scheme(HTM) that takes into account local and globalmobility in order to reduce handoff latency, packetloss and signaling costs. Additionally, the problemof spurious retransmissions due to failed SACKsand data retransmission lost is addressed. Finally,several simulations and an analytical model areinvestigated in order to demonstrate theeffectiveness of the proposed mobility scheme. Inthe rest of this paper, the terms mobile user andmobile node will be used interchangeably.

The remainder of this paper is structured as follows:Section 2 presents related work and Section 3describes the proposed mobility scheme. Ananalytical model is introduced in section 4.Performance analyses and simulation results arepresented in Section 5. Finally, Section 6 concludesthe paper.

2 RELATED WORKThe IP layer is traditionally considered as the

default place where mobility is implemented sincethe IP protocol remains widely used to connect

heterogeneous communication systems. However,an increasing interest is recently given to

experience mobility at the transport and applicationlevels. In this section, we give an overview of thewell-known mobility mechanisms available in theliterature.

2.1 IP layer mobility

Traditionally, mobility management isperformed at the network layer due to the use of theInternet Protocol (IP) that allows routing packetsbetween different technologies. In this context,several approaches propose coping strategies for IPlayer mobility. Among these, Mobile IPv6 (MIPv6)is the most popular mechanism that allows mobilenodes to remain reachable in spite of theirmovements within IP-based mobile environments.However, MIPv6 has some well-known drawbacks,such as high signaling overhead, packet loss andhandoff latency, thereby causing real-time trafficdeterioration which can be perceived by users [17].

These weaknesses led to the investigation of othersolutions designed to enhance MIPv6. The IETFproposed new MIPv6 extensions including Hawaii[18], Cellular IP [19] and Hierarchical MIPv6(HMIPv6). These protocols tackle intra-domain ormicro-mobility, while MIPv6 is used for inter-domain or macro-mobility. However, this solutiongenerates extensive bidirectional tunneling as longas the mobile moves inside the same administrativedomain. Additionally, FMIPv6 was proposed toreduce handoff latency and minimize servicedisruption during handoffs pertaining to MIPv6operations, such as movement detections, binding

updates and address configurations. AlthoughFMIPv6 paves the way for improving MIPv6performance in terms of handoff latency, it does notefficiently reduce signaling overhead (due to newmessages being introduced and exchanged forhandoff anticipation) nor does it prevent packet loss(due to space requirements). This may lead tounacceptable service disruptions for real timeapplications. Combining HMIPv6 and FMIPv6motivates the design of Fast Handover for HMIPv6(FHMIPv6) to increase network bandwidthefficiency. However, FHMIPv6 may inheritdrawbacks from both HMIPv6 and FMIPv6, those

pertaining to synchronization and signalingoverhead issues, for instance. Furthermore, theIETF has also proposed a network-based mobilityreferred to as Proxy Mobile IPv6 [5] to ensuremobile user roaming without its participation in anymobility-related signaling. However, this type ofmobility schemes depends entirely on the networkinfrastructure and need a permanent bidirectionaltunnel between the MN and CN.

2.2 Application layer mobility

Handling mobility at the application layer hasalso received a lot of attention since this category of

solutions is almost independent of the underlyingtechnologies. To accomplish this type of mobility,


3/14


the SIP [4] protocol is widely used. Thus, when amobile node moves during an active session intodifferent network, it first receives a new address,and then sends a new session invitation to itscorrespondent node. Subsequent data packets areforwarded to the MN using this new address.

However, SIP by itself does not guarantee themaintenance of established Transmission ControlProtocol (TCP) sessions or User Datagram Protocol(UDP) port bindings when moving, so furtherextensions such as S-SIP [20] are needed to provideseamless handover capabilities.

2.3 Transport layer mobility

Recently, transport layer-based mobility isgaining attention since it does not require a conceptof home network and mobile nodes can performsmooth handovers if they are equipped withmultiple interfaces. Moreover, this category of

mobility schemes may benefit from flow controland the possibility to pause transmission during thehandoff period. The first transport layer mobilitysolutions were based on TCP, and then otherinteresting mobility approaches have been proposedwith the standardization of SCTP [13] and mSCTP[14].2.3.1 TCP-based mobility

In the last few years, several transport layermobility schemes have been proposed to benefitfrom the connectivity facilities and flow controloffered at the transport level. From this perspective,a new TCP protocol architecture was proposed to

support mobility [22]. However, tremendouschanges must be performed over the entire networkto reach this goal. MSOCKS [23] is another TCP-based proposal which does not require changes tothe network layer infrastructure. However, it suffersfrom high latency and packet loss, since it follows amake-after-break approach (disable MNconnections until a new path is ready). Migrate [10]is another TCP-based mobility solution which aimsto ensure transparent TCP connection migration.Nevertheless, this solution requires changes to TCPimplementation at both ends of the connection.Multi-homed TCP, introduced by [24], aims to use

several addresses in parallel for the sameconnection by proposing to use new TCP ProtocolControl Bloc (PCB) to name the TCP socket,thereby allowing underlying IP addresses to change.However, this approach needs huge modificationsand remains, accordingly, not used.2.3.2 SCTP-based mobility

Performing mobility on the transport layerbecomes more realistic with the emergence of theStream Control Transmission Protocol (SCTP), andeven more so with its mobile extension. Indeed,SCTP is a new transport layer protocol that wasrecently standardized under the RFC 4960. It

inherited many TCP properties, but it alsointroduces novel and interesting features, such as

multistreaming and multihoming. Multistreamingconsists of delivering independent data streams bydecoupling reliable deliveries from messageordering. This feature prevents receiver head-of-line blocking in cases where multiple independentdata streams occur during a single SCTP session.

On the other hand, multihoming allows an SCTPnode to be reached through multiple IP addresses(interfaces). In fact, two SCTP nodes can exchangedata by defining a common association. In SCTPterminology, an association is equivalent to a TCPconnection. End points can be single-homed ormultihomed. When single-homed, SCTP nodes aredefined as [IP address: SCTP port], otherwise theyare designated as [IP1 address, IP2 addressIPnaddress: SCTP port]. When establishing anassociation, end points define their primary path, aswell as the secondary ones. The primary path isused to transfer data, while secondary paths are

used for retransmissions and backups in the eventof primary path failures. The SCTP ADDIP [14]Extension enables SCTP nodes to dynamically add,delete and modify their primary address withoutterminating an ongoing association.

In [26] the authors propose an approach toensure vertical handoffs between UMTS andWLAN networks using SCTP multi-homingcapabilities. In [27], a TraSH mobility scheme wasproposed to perform seamless handovers betweenheterogeneous networks. In SIGMA [28], theauthors propose an SCTP-based mobility

architecture that integrates location management toensure seamless handovers. In [29], the authorsadvance certain triggering rules to improvethroughput during SCTP-based handoffs. All ofthese proposals are based on the mobile SCTPextension (mSCTP) and their correspondingmobility procedure is summarized in Fig. 1.

Figure 1: Mobile SCTP-based handoff procedure

In [30][31], the authors put forward newtransmission techniques by attempting to enableSCTP-based mobility schemes with concurrentmulti-path data transfers. Unfortunately, all of theproposed schemes focus on the inter-systemhandoffs (i,e., vertical handovers) and do notconsider the fact that the majority of handoffs areperformed inside the same wireless system (i,e.,horizontal handoffs). Accordingly, mobile usersmust endure unnecessary handoff delays andsignaling loads which may become significant incase of frequent handovers. Moreover, a number of

hidden effects such as spurious retransmissions dueto failed SACKs and data lost reduce considerably


4/14


5/14


The following section introduces our proposedhierarchical mobility mechanism that deals withlocal and global roaming, and addresses theproblem of spurious retransmissions due to failedSACKs and data chunks.

3.2 HTM Architecture

In order to address the aforementioneddrawbacks, we propose a novel HierarchicalTransport layer Mobility scheme (HTM) thatconsiders local and global mobility. Morespecifically, HTM aims to exploit existinghierarchical topologies to implement its newAnchor Mobility Unit (AMU) which allows mobileusers to perform local handoffs. In fact, topologiesthat use hierarchical routers (as illustrated in Fig. 2)are frequently encountered in wireless network

designs. Hence, routers (or central routers) that mayintegrate AMU functionalities can be easily found.Basically, HTM consists of a two-unit handoff

procedure designed as: localHTM andglobalHTM . The former treats local/intra-domain

mobility, while the latter deals with global/inter-domain roaming.

Figure 5: HTM architecture

The HTM architecture that supports both local

and global handoffs is illustrated in Fig. 5. In thisarchitecture, the MN is assumed to be multihomedwith two active wireless interfaces. Initially, theMN is assigned to Cell 1 and receives data from itsCorrespondent Node (CN) on its IP1 interface.While moving, the MN changes its point ofattachment from Cell 1 to Cell 2 and finally to Cell3. When the MN hands off from Cell 1 to Cell 2, itperforms a local/intra-domain handoff. However,when it moves from Cell 2 to Cell 3, it completes aglobal/inter-domain handover. Additionally, AP1andAP2 belong to the same wireless system, while

AP3 belongs to an external mobile system.Router1

andRouter2 are connected to a Central Router (CR)which supports AMU functionalities. The main role

of the AMU unit consist of assisting mobile nodesto perform seamless handoffs. Each AMU isidentified by an AMU-ID (AMU-Identifier), whichis periodically broadcasted in the AP/AR beacons.AMU-IDs are highly useful for MNs to decidewhether to perform local or global handoff.

Basically, the AMU functionalities consist ofbuffering traffic during the disruption period andperforming redirection when the MN is attached tothe new link. The AMU process is depicted in Fig.6.

More specifically, the AMU continuously listensto the redirect events (Redirect-Init). Once a

Redirect-Init event occurs, the AMU startsbuffering traffic sent to the old MN's IP address.When the MN is attached to its new location, itsends aRedirect-Ready message to notify the AMUthat it is ready to receive data on its newlyconfigured IP address. The AMU redirect process

ends when no more packets are sent to the old MNaddress. The following section provides furtherdetails pertaining to the proposed handoffprocedures when dealing with local and globalmobility.

Figure 6: AMU redirection process

3.3 HTM Handoff Procedures

To take benefit of the SCTP multihomingfeature we have to remember that when a mobilenode moves between cells belonging to a sametechnology, it can use only one wireless interface atime. However, the MN can simultaneously use itstwo wireless cards when it moves through cellsbelonging to heterogeneous technologies. Thus, ifwe take into account the fact that mobile deviceswill become increasingly powerful, intelligent andsensitive to link changes, we can assume that theMN detects its movement toward a new access

router by using L2 triggers (ie., weak signalstrength, high bit error rate, etc.).


6/14


As pointed out earlier, the MN detects thepresence of the AMU unit through the periodicbeacons received from its current point ofattachment. Hence, when the MN receives L2trigger, it sends a RAS_req (Router AddressSolicitation request) message to its serving AMU to

obtain a new address from the next access router(NAR). Accordingly, if the MN receives a new IPaddress, it concludes that it has to perform an

localHTM procedure (local handoff). Otherwise, itruns the globalHTM procedure (global handoff).

3.3.1 HTM Local Handoff Procedure (HTMlocal)The localHTM procedure is initiated when an

MN perform a handoff, for example from Cell 1 toCell 2, as illustrated in Fig. 5. In this case, it obtainsan IP address from AR2 through its serving AMUunit. Practically, this task can be completed withDHCP [32] or IPv6 autoconfiguration [33]. TheAMU keeps an association between the new

obtained address and the one currently used by theMN. From this moment, the MN is ready toperform a handoff. Recall, that until now the MNcontinues to receive data from its old path. Whenthe MN decides to move to its new location, itsends a Redirect-Init message to the AMU unit.This message informs the AMU that the MN isperforming a L2 link switching (L2 handoff). Atthis time, the AMU buffers all the packets sent tothe MN's previous address until the MN attaches toNAR's link. As soon as the MN is attached to thenew access router (NAR), it sends aRedirect-readymessage to notify the AMU that it has beensuccessfully attached to its new location. Uponreceiving the Redirect-ready message, the AMUstarts packet forwarding to the new MN's IP address.At the same time, the MN sends an ADDIP_Softchunk to inform the CN that a handoff had occurredand it has to set the new MN's IP address as theprimary path of their association. Finally, when theMN is completely far from its previous attachment

point, the old path is deleted. The entire localHTM procedure is illustrated in Fig. 7.

Figure 7: The localHTM handoff procedure

ADDIP_Soft is a new chunk introduced to

perform the set of primary path when the MN issubject to a local handoff. When the CN receivesthe ADDIP_Soft chunk, it concludes that its pair(MN) has performed a local handoff. The CNimmediately transmits packets through the MN'snew IP address (IP2) and ignores the previous one

(IP1). The description of the new proposedADDIP_Softchunk appears in Fig. 8.

Value = 0x0a010101 (New address)

Value = 0x0a010111 (Old address)

Type = 0xC008 Length = 20

Chunk-ID = 0x11122233

Figure 8: Description of theADDIP_Softchunk

The main advantage of the proposedlocalHTM consists of allowing the MN to perform

fast handoffs when an AMU component is available.Note that the tunnel established between the AMUand CN operates only during the handoff period.This approach is completely different fromHMIPv6 and Proxy Mobile IP principles where thetunnel is maintained as long as the MN movesinside the same administrative domain.Additionally, the Network Address Translation(NAT) concept is not suitable in our case sinceNAT is not designed for mobile purposes.Moreover, many applications and protocols need touse real end-to-end IP addresses. For instance, thisis the case with IP security architecture that cannot

work across a NAT device since the originalheaders are digitally signed. The proposed HTM isexpected to reduce latency and limit signaling loadover the network. Additionally, the problem ofspurious retransmissions due to failed SACKs isconsidered since all messages (including SACKs)destined to the MN are forwarded to the MNthrough the AMU unit. Finally, note that the AMUunit is implemented over an existing architecture.Hence, in cases where adding an AMU componentwould be impossible, the MN can perform its

handovers by using the globalHTM procedure.

3.3.2 HTM Global Handoff Procedure (HTMglobal)In the absence of an AMU unit, all handoffs are

completed with the globalHTM procedure describedin Fig. 9. However, handoffs performed in this case(i.e., without an AMU) may be either horizontal(i.e., same technology) or vertical (i.e., differenttechnology). When the handoff is performed withina same technology (i.e., horizontal handover), thehandoff disruption time will include: L2 handoffmovement detection, authentication, addressconfiguration and association update (i,e., ADDIPand Set-Primary signaling messages). However,when the MN performs a vertical handover, the two

wireless interfaces can be used simultaneously.Thus, L2 handoff, movement detection,


7/14


8/14


follow exponential distribution with parametersr

andd respectively, while session arrival process

follows a Poisson distribution with rates . Hence,

if we denote: )( rNE as the average number of AR

subnet crossing, )(d

NE as the average number of

AMU domain crossing and )( INE as the averagenumber of AR subnet crossing performed inside anAMU domain, we can define the above averages asintroduced in [21] by:

s

r

rNE

=)( (2)

s

ddNE

=)( (3)

s

IINE

=)( (4)

Notations used in our analysis are given in Table 1.

Table 1: Notation

YXT, transmission cost between nodeXand node Y

ZP processing cost at nodeZYX

hopN , number of hops between nodeXand Y a proportionality constant to illustrate that the

transmission cost for wireless hops are superiorto those of wired hops

c

hopT transmission cost per hop

Xl one lookup cost at node X

X packet tunneling cost at node XYXD , transmission delay between nodesXand Y

tunnelingD

packet tunneling timet

ZP processing time at nodeZ

MDT Movement Detection delay

ACT Address Configuration delay

2LT L2 handoff delay

UFT AMU Update and packet Forwarding delay

In what follows, we use the above equations toanalyze both signaling and packet delivery costs ofthe studied mobility schemes.

4.2 Total cost analysis

We define the total cost ( totalC ) as the sum ofsignaling and packet delivery costs. In other words,

totalC is given by:

deliverysignaltotal CCC += (5)

The signaling cost refers to the amount of signalingtraffic while the packet delivery cost refers to the

network overhead. The signalC and deliveryC are

modeled during an inter-session arrival time thatrefers to the interval time between the arrival of thefirst packet of a data session and the arrival of thefirst packet of the next data session (i,e., one

session lifetime). Note that signalling cost requiredfor L2 handoff and address configuration are not

considered in our analysis since they are the samefor the compared protocols.

4.2.1 HTM total costThe HTM total cost is defined as:

HTM

delivery

HTM

signal

HTM

total CCC += (6)

- HTM signaling costThe HTM signaling cost is incurred when anMN performs either local or global handoffs. Thiscost is given by:

AMU

d

AR

I

HTM

signal CNECNEC += )()( (7)

Where :AR

C : refers to the signaling cost when an MNperforms a handoff of type (a)

AMUC : refers to the signaling cost when an MNperforms a handoff of type (b)Moreover, if we assume that a handoff preparationis always followed by a handoff execution, the

expressions relevant to ARC and AMUC are givenin Table 2.

Table 2: Expression of signalling costs

ARC

= CNAMUCNMNAMUMNAMUMN PPTTT nnp ++++ 22 ,,,

AMC = CNCNMNCNMN PTT np ++ 333 ,,

MNp and MNn refer respectively to the MN's

location before and after a handoff. TheYXT , cost

can be expressed as:c

hop

YX

hopYX TNT += )1(,

, (8)

To illustrate the impact of the MN's mobility andthe MN's average session arrival on the HTMsignaling cost, we introduce a session-to-mobilityfactor (SMR) which represents the relative ratio ofsession arrival rate to the mobility rate.The SMR factor is expressed by :

r

sSMR

=

(9).

Hence, if we consider equations (1), (4) and (9), theequation (7) becomes:

[ ]AMUARHTM

signal CCMMSMRC += )1(

1 (10)

- HTM packet delivery cost

LetpA be the average packets sent by the CN

during one session lifetime. Based on Fig. 11, theMN can perform either handoffs of type (a) or (b).However, only handoffs of type (a) incur a tablelookup and an IP tunneling costs at the AMU.Hence the HTM packet delivery cost is given by :

)(, )()(

a

pAMUAMUICNMNp

HTM

delivery AlNETAC ++= (11)

Where: )(apA refers to the average packet tunneled

during handoffs of type (a),

4.2.2 mSCTP total cost


9/14


The mSCTP total cost is defined as:mSCTP

delivery

mSCTP

signal

mSCTP

total CCC += (12)

- mSCTP signaling costBased on the mSCTP handoff procedure given in

Fig. 9, the mSCTP signaling cost is given by:)333())()(( ,, CNCNMNCNMNdI

mSCTP

signal PTTNENECnp

+++= (13)

To express equation (13) as a function of the SMRfactor, we use equations (1), (4) and (9).

)(3

,, CNCNMNCNMNmSCTP

signalPTT

SMRC

np++=

(14)

- mSCTP packet delivery costSince the mSCTP handoff procedure did not

incur any IP tunneling or table lookup costs, itspacket delivery is given by:

CNMNp

mSCTP

delivery TAC ,= (15)

4.3 Handoff latency and packet loss

The handoff latency is defined as the timeelapsed between sending of the last data packetthrough the old MN's primary address (i.e., oldlocation) and receiving the first data packet on theMN's new primary address (i.e., new location). Thepacket loss refers to the amount of packets lostduring this disruption time.

Figure 10:HTM local handoff timeline delay

Figure 11:mSCTP horizontal handoff timeline delay

Figure 12:mSCTP/HTM vertical handoff timeline delay

If a mobile node moves through cellsbelonging to a same technology (horizontalhandoff), it cannot simultaneously use its twointerfaces since it needs two transceivers accordingto the majority of radio systems [15]. However, if itperforms a handover between heterogeneouswireless technologies (i,e., vertical handoff), it canuse its interfaces in parallel. This means, that theMN continues to receive traffic on its old path

while it performs L2 link switching, movementdetection, address configuration through the newinterface and the association update (ADDIP).Practically, we can divide handoff latency into: linkswitching or L2 handoff delay (TL2), movementdetection delay (TMD), address configuration delay

(TAC) and association updates and packetforwarding time (TUF).According to the handoff scenarios depicted in

Fig. 11, an MN can perform either handoffs of type(a) or (b). Hence, we define the average handofflatency for HTM as:

[ ]))1(()()()()(

1 ),(),()( verticalbhandoffh

horizontalb

handoffhd

a

handoffI

dI

HTM

handoffDPDPNEDNE

NENED ++

+=

(16)

Where:)(a

handoffD : latency relevant to handoff of type (a) (i.e.,

inside an AMU domain), thecorresponding timeline delay is given inFig. 12.

horizontalb

handoffD ),( : latency relevant to horizontal handoff

performed outside an AMU, thecorresponding timeline delay is given inFig. 13.

verticalb

handoffD),( : latency relevant to a vertical handoff, the

corresponding timeline delay is given inFig. 14.

hP : probability that an MN perform a horizontal

handoff outside an AMU domain.The expressions of )(a

handoffD , horizontalbhandoffD),( and verticalb

handoffD

),(

are given in Table 3.

Table 3: Expression of HTM handoff delays

If we consider that 0fd (i,e., we have at leasttwo AMU domains), we use equations (3) and (4)to derive the following relation:

[ ]verticalbhandoffhhorizontalbhandoffhahandoffHTMhandoff DPDPDMM

D ),(),()( )1()1(1

++= (17)

Where: refers to the time between the instantwhen the sender is ready to send data packets andthe instant when it effectively starts sending datapackets to the MN's new location

According to [16] YXD , is defined as:

)()1()(1

1 ,, qw

w

YX

hopwl

wl

YX LB

sNL

B

s

q

qD ++++

+

= (18)

Where s is the message size, q is the average

queuing delay at each intermediate router, q is the

probability of wireless link failure,wlB (resp wB )

the bandwidth of wireless (resp wired) link and

)(ahandoffD

= +++++

t

AMUtunnelingAMUMNMDL PDDTT ,2 2

horizontb

handoffD),(

= +++++t

CNCNMNACMDL PDTTT ,2 4

verticalb

handoffD ),( = ++

t

CNCNMN PD ,2


10/14


11/14


Fig. 16 presents the average handoff latency,for both mSCTP and HTM, as a function of movingspeed. Here, we set id = 20ms (i,e., delay betweencentral router and CN) and we increase the MN'sspeed (v) from 2 m/s to 30 m/s while it performsseveral handoffs starting from AR1 to AR2. We

notice that when the MN's speed is small, HTMshows lower handoff delay than mSCTP. However,when v > 12 m/s, the HTM's latency increasesconsiderably and becomes equivalent to the mSCTPone. This is because when the moving speedincreases, the sojourn time in the overlapping areabecomes too small, so the MN do not have enoughtime to perform its configuration process. Therefore,the advantage of introducing the AMU unit is nolonger considered when the MN's moving speed ishigh.

Figure 15: Impact of moving speed on HTM /mSCTP latencies

To illustrate how the proposed HTM improves

throughput, consider the results illustrated in Fig.17. These results correspond to the throughputrelevant, respectively, to the previous and newMN's paths, i.e, the MN changes its point ofattachment from AR1 to AR2. Observe that thethroughput of the previous path decreases duringthe time interval [ ]sst 25,13 where the handofftakes place. This drop is due to the increasing lossrate of AR1 as the MN moves. Once the handoff isover, notice that the MN throughput increases againuntil it reaches its original level. However, thethroughput reported immediately after the handoff

remains lower than the one computed before thehandoff occurred.

Figure 16: Throughput relevant to an mSCTP pathhandover

This situation is due to failed SACKs that cause a

diminution of the congestion window (CWND),thus reducing throughput. To show how theproposed HTM improves throughput compared tomSCTP, consider the throughput obtainedimmediately after a handoff for HTM and mSCTP.

Fig. 18 shows the throughput pertaining to the

time interval (25-40s) following an MN handoff.Note that the HTM throughput is relatively highcompared to mSCTP. This is due to the fact that

localHTM uses the AMU unit to buffer and forwardall the traffic to the new MN's location. This trafficobviously includes SACKs which are not lost,unlike what happens with mSCTP. Accordingly,MN will receive a majority of its SACKs within theRTO time interval (Retransmission TimeOut) sincethe HTMlocal latency is less than 300 ms while theRTO interval is about 1 second.

Fig. 17. Throughput of localHTM vs mSCTP

5.3 Numerical Results

In this section, we use the developed costmodels (section 4) to illustrate how the proposedmobility scheme HTM improves QoS parameters interms of signaling cost, handoff delay and packetloss compared to mSCTP.The list of the parameter values used for ournumerical results is shown in Table 4.

Table 4: Parameters used for performanceanalysis

Parameters Symbols ValuesWireless link failure probability q 0.5Average queuing delay

q 0.1 ms

Wired link delay Bw 100

MbpsWireless link bandwidth Bwl 11 MbpsMessage size s 296 bytesNumber of AR subnets perAMU/MAP domain

M 4

Average packet arrival persession

Ap 20

Average packets tunneledduring a handoff of type (a)

)(apA

2

Lookup cost at the AMUAMUl

2

Packet tunneling cost at theAMU AMU

2

L2 handoff delay TL2 50 msMovement detection delay TMD 100 msAddress Configuration delay TAC 500 ms

Waiting time before effectivedata transmission 1 ms


12/14


Fig. 19 illustrates the total signaling cost as afunction of the SMR ratio. When the SMR ratio isinferior to 1, the mobility rate is higher than thesession arrival rate that is why the signaling costincreases for both HTM and mSCTP. This increasebecomes more noticeable when the SMR is close to

0. However, the HTM cost remains lower than themSCTP cost. On the other hand when the SMR issuperior to 1, i,e., the session arrival rate is greaterthan the mobility rate, the binding updates, relevantto handoffs, are performed less often.

Figure 18: Impact of the SMR on the totalsignaling cost

Fig. 20 illustrates the total signaling cost as afunction of mobile node velocity. We notice thatthe total signaling cost increases for both HTM andmSCTP. However, the signaling costs involved byHTM remain lower than mSCTP. Moreover the gapbetween mSCTP and HTM signaling costs becomesmore important when the MN's velocity increases.This behaviour is to be expected since the MN willperform frequent handoffs when its velocity reacheshigh values. Nevertheless, HTM reduces theamount of signalling cost since it takes into accountlocal handoffs.

Figure 19: Impact of the MN velocity on the totalsignaling cost

Fig. 21 shows that the HTM total signaling costis proportional to the AMU tunneling cost.However, it remains lower than the mSCTP costeven if high values are used for the AMU tunnelingcost (i., more that 20). Recall that all of theprocessing costs used for our performance analysisare less or equal to 2. On the other hand, mSCTP is

not affected by the AMU cost variation since itdoes not perform traffic redirection.

Figure 20: Impact of the AMU tunneling cost onthe total signaling cost

In Fig. 22 we present the average handoff delayas a function of the wireless link delay. We noticethat the average handoff delay is proportional to thewireless link delay for both HTM and mSCTP.However, it can be noticed that the HTM averagelatency is lower than mSCTP. Moreover, when Phincreases (i,e., probability of horizontal handoffperformed outside an AMU unit), handoff latenciesincrease for both HTM and mSCTP. However, theHTM's latency remains lower than the mSCTP one.This means that the introduction of the AMU unitimproves considerably the MN's handoff delaysduring its roaming through homogeneous networks.

Figure 21: Handoff latency as a function ofwireless link delay

The impact of localHTM on the MN's latency is

clearly illustrated in Fig. 23 where we compare thetwo scenarios of mSCTP handoffs (i.e., horizontaland vertical) with our proposed mobility scheme.Recall, that HTM (i.e., HTMglobal) and mSCTP usethe same vertical handoff procedure. We notice that

localHTM presents lower average handoff latencycompared to mSCTP. The gap between localHTM 'slatency and mSCTP becomes more and moreimportant as the wireless link delay increases. Thisdifference is particularly due to the absence ofaddress configuration delay in localHTM . Moreover,the consideration of local mobility reducesconsiderably the association update delay since the

CN is notified only when the MN is attached to itsnew location.


13/14


Figure 22: Impact of wireless link delay onhorizontal/vertical handoffs

Fig. 24 illustrates handoff latency as afunction of the average subnet crossing rate insidean AMU (E(NI)). When this rate is low, i,e., mostof the MN's handovers are performed in the absenceof the AMU units, we notice that the average HTM

latency is high. With the increase of E(NI), weobserve a noticeable decrease of the HTM averagelatency which becomes approximately constantwhen this rate reach high values. This situationshows again that the consideration of local handoffsby our mobility proposal reduces considerably theoverall average handoff delay when the MNperforms consecutive horizontal and verticalhandoffs. On the other hand, the mSCTP handofflatency remains high and almost insensitive to the

E(NI) rate.

Figure 23: Impact of the intra-subnet crossing rateon the handoff delay

Fig. 25 shows the behavior of packet loss as afunction of packet arrival rate. It is noticed thatpacket loss increases for both HTM and mSCTP.However, the HTM packet loss remains lower thanmSCTP. This situation is quite normal since thehandoff delays for HTM is lower than mSCTP andby definition of all of the packets received at thisperiod are lost. In addition, HTM uses a bufferingstrategy when an MN roams inside a same AMUdomain which helps to avoid as much as possiblepacket loss during the MN's disruption time.

Figure 24: Packet loss behavior for differentpacket arrival rates

6 CONCLUSIONSThis paper proposes a new hierarchical

transport layer mobility scheme called HTM, whosemain goal is to provide mobile nodes with seamless

roaming through heterogeneous networks. Morespecifically, HTM consists of an end-to-endmobility protocol based on SCTP features, whichincludes multihoming and ADDIP Extension. Itparticularly introduces an Anchor Mobility Unit(AMU) to deal with local mobility in order toreduce handoff latency and signaling load.Additionally, HTM addresses the problem ofspurious retransmissions due to failed SACKs.Finally, to ensure mobile node tracking wheninitiating associations, a location managementscheme that uses the Dynamic DNS service(DDNS) is introduced. Simulations and numerical

results show that HTM ensures low latency, goodthroughput and limited signaling load compared tothe mSCTP based handoffs. Future work shallinvestigate how this proposal can be adapted tomobile ad hoc networks as well as the impact of theproposed location management scheme on systemperformance.

7 REFERENCES[1] Frattasi, S., Fathi, H., Fitzek, F. H. P., Prasad, R.,

Katz, M. D. 2006. "Defining 4G technology from the

users perspective". IEEE Network, Vol. 20, No. 1,pp. 35-41.[2] Bauman, F. V., Niemegeers, I. G. 1994. "An

Evaluation of Location Management Procedures".Proceeding Of 3rdAnnual Int'l Conference Universal

Personal Communications (UP' 94), September1994, pp. 359-364.

[3] Fang, Y. 2003. "Movement-Based MobilityManagement and Trade Off Analysis for WirelessMobile Networks". IEEE Transactions onComputers, Vol. 52, No. 06, pp. 791-803.

[4] Akyildiz, I. F., McNair, J., Ho, J. S. M., Uzunalioglu,H., Wang, W. 1999. "Mobility Management in Next-Generation Wireless Systems". Proceeding of the

IEEE, Vol. 87, No. 8, pp. 1347-1384.[5] Gundavelli, S., Leung, K., Devarapalli, V.,


14/14


Chowdhury, K., Patil, B., "Proxy Mobile IP", RFC5213, August 2008.

[6] Johnson, D., Perkins, C., Arkko, J. 2004. "MobilitySupport in IPv6", IETF RFC 3775.

[7] Soliman, H., Castelluccia, C., El-Malki, K., Bellier,L. 2005. "Hierarchical mobile IPv6 mobilitymanagement (HMIPv6)",IETF RFC 4140.

[8] Koodli, G. 2005. "Fast handovers for mobile IPv6".IETF RFC 4068.

[9] Jung, H. Y., Kim, E. A., Yi, J. W., Lee, H. H. 2005."A scheme for supporting fast handover inhierarchical mobile IPv6 networks". ETRI Journal,Vol. 27, No. 6, pp. 798801.

[10]Snoeren, A., Balakrishnan, H. 2000. "An end-to-endapproach to host mobility". ACM MobiCom Boston,pp. 155-166.

[11]Handley, M., Schulzrinne, H., Schooler, E.,Rosenberg, J. 1999. "SIP: Session InitiationProtocol",IETF RFC 2543.

[12]Wei, S. H., Huang, M. H., Long, W. 2005."Research on the scheme supporting mobility of

TCP application", Journal of Chongqing Universityof Posts and Telecommunication, Vol. 17, No. 1, pp.117-120.

[13]Stewart, R. 2007. "Stream Control TransmissionProtocol".IETF RFC 4960.

[14]Stewart, R., Xie, Q., Tuexen, M., Maruyama, S.,Kozuka, M. 2007. "Stream Control TransmissionProtocol (SCTP) Dynamic Address Reconfiguration".IETF RFC 5061.

[15]Atallah, J. G. and Ismail, M., "Future 4G front-endsenabling smooth vertical handovers", IEEE circuitsand Device Magazine, Vol. 22, No. 1, 2006, pp. 6-15.

[16]McNair, J., Akyildiz, I. F., Bender, M. D. 2001."Handoffs for Real-time Traffic in Mobile IP version6 Networks". Proceeding of IEEE GLOBECOM, Vol.

6, pp. 3463-3467.[17]Perez-Costa, X., Torrent-Moreno, M., Hartenstein,

H. 2003. "A performance comparison of mobile IPv6,hierarchical mobile IPv6, fast handovers for MobileIPv6 and their combination". ACM Mobile Comp.and Comm. Rev, Vol. 7, No 4.

[18]Ramjee, R., Varadhan, K., Salgarelli, L., Thuel, S.R., Wang, S. Y., La Porta, T., HAWAII: A domain-based approach for supporting mobility in wideareawireless networks, IEEE/ACM Transactions onNetworking, Vol. 10, No. 3, June 2002, pp. 396-410.

[19]Campbell, A.T., Gomez, J., Valko, A.G., "Anoverview of cellular IP ", Wireless Communicationsand Networking Conference, WCNC 1999 IEEE,

Vol. 2, pp. 606-610.[20]Zhang, J., Chan, H., Leung V. 2007. "A SIP-basedSeamless-Handoff (S-SIP) Scheme forHeterogeneous Mobile Networks". in Proceeding ofthe IEEE Wireless Communications and Networking

Conference, Hong Kong, pp. 3946-3950.[21]Xiao, Y., Pan, Y., Li, J. 2004. "Design and Analysis

of location Management for 3G Cellular Networks". IEEE Transactions on parallel and distributed

systems, Vol. 15, No. 04, pp. 339-349.[22]Hsieh, H., Kim, K., Zhu, Y., Sivakumar, R. 2003.

"A receiver-centric transport protocol for mobilehosts with heterogeneous wireless interfaces". ACMMobiCom, San Diego, pp. 1-15.

[23]Maltz, D., Bhagwat, P. 1998. "MSOCKS: Anarchitecture for transport layer mobility".INFOCOM

San Francisco, pp. 1037-1045.[24]Huitema, C., " Multi-homed TCP ", draft-huitema-

multi-homed-0.txt, 1995.[25]Mishra, A., Shin, M., Arbaugh, W., "An empirical

analysis of the IEEE 802.11 MAC layer handoffprocess", ACM SIGCOMM ComputerCommunication Review, 2003, Vol. 33, No. 2, pp.

93-102.[26]Ma, L., Yu, F., Leung, V. C. M., Randhawa, T. 2004.

"A new method to support UMTS/WLAN verticalhandover using SCTP ". IEEE WirelessCommunications, Vol. 11, No. 4, pp. 44-51.

[27]Fu, F. S., Atiquzzaman, M., Ma, L., Ivancic, W., Lee,Y., Jones, J. S., Lu, S. 2004." TraSH : A TransportLayer Seamless Handover for Mobile Networks".Technical Report: OU-TNRI-04-100.

[28]Fu, F. S., Ma, L., Atiquzzaman, M., Lee, Y.,"Architecture and performance of SIGMA: Aseamless mobility architecture for data networks",40th IEEE International Conference on

Communication (ICC), Seoul, Korea, May 2005, pp.

3249-3253.[29]Koh, S. J., Chang, M. J., Lee, M. 2004. "mSCTP forsoft handover in transport layer". IEEECommunication Letters, Vol. 8, No. 3, pp. 189-191.

[30]Iyengar, J. R., Amer, P. D., Stewart, R.2006."Concurrent Multipath Transfer Using SCTPMultihoming Over Independent End-to-End Paths". IEEE Transactions on Mobile Computing, Vol.14, No. 5, pp. 951-964.

[31]Fracchia, R., Casetti, C., Chiasserini, C. F., Meo, M.2007."WiSE: Best-Path Selection in WirelessMultihoming Environments". IEEE Transactions onMobile Computing, Vol. 6, No. 10, pp. 1130 1141.

[32]Droms, R. 1997. "Dynamic Host ConfigurationProtocol",IETF RFC 2131, March 1997.

[33]Thomson, S., Narten, T. 1998. "IPv6 StatelessAddress Autoconfiguraton". IETF RFC 2462.

[34]http://www.isi.edu/nsnam/ns/[35]SCTP Module http://pel.cis.udel.edu/

Documents

Final UBICC Manuscript HTM 347