1. a comparison of mechanisms for improvingmobile ip hand-10.1.1.9.8288

7/31/2019 1. a Comparison of Mechanisms for ImprovingMobile IP Hand-10.1.1.9.8288

1/13

A Comparison of Mechanisms for Improving Mobile IPHandoff Latency for End-to-End TCP

Robert Hsieh and Aruna SeneviratneSchool of Electrical Engineering and Telecommunications

The University of New South WalesSydney, NSW, Australia 2052

[email protected], [email protected]

ABSTRACT Handoff latency results in packet losses and severe End-to-EndTCP performance degradation as TCP, perceiving these losses ascongestion, causes source throttling or retransmission. In order tomitigate these effects, various Mobile IP(v6) extensions have beendesigned to augment the base Mobile IP with hierarchicalregistration management, address pre-fetching and local

retransmission mechanisms. While these methods have reducedthe impact of losses on TCP goodput and improved handoff latency, no comparative studies have been done regarding therelative performance amongst them. In this paper, wecomprehensively evaluated the impact of layer-3 handoff latencyon End-to-End TCP for various Mobile IP(v6) extensions. Fivesuch frameworks are compared with the base Mobile IPv6framework, namely, i) Hierarchical Mobile IPv6, ii) HierarchicalMobile IPv6 with Fast-handover, iii) (Flat) Mobile IPv6 withFast-handover, iv) Simultaneous Bindings, and v) Seamlesshandoff architecture for Mobile IP (S-MIP). We propose anevaluation model examining the effect of linear and ping-pongmovement on handoff latency and TCP goodput, for all aboveframeworks. Our results show that S-MIP performs best underboth ping-pong and linear movements during a handoff, withlatency comparable to a layer-2 (access layer) handoff. All otherframeworks suffer from packet losses and performancedegradation of some sort. We also proposed an optimization forS-MIP which improves the performance by further eliminating thepossibility of packets out of order, caused by the local packetforwarding mechanisms of S-MIP.

Categories and Subject Descriptors C.2.1 [ Computer-Communication Networks ]: Network Architecture and Design - Wireless communication; C.4[Computer Systems Organization ]: Performance of Systems

General Terms Performance, Design, Experimentation

Keywords Mobile IP, Hierarchical Mobile IP, Fast-handover, S-MIP,Handoff Management, Seamless Handoff

1. INTRODUCTIONIn the Internet (IP) environment, when a mobile node moves and

attaches itself to another network, it needs to obtain a new IPaddress. This changing of IP address means that all existing IPconnections to the mobile node need to be terminated and then re-established. This is essential as the IP routing mechanisms rely onthe topological information embedded in the IP address to deliverthe data to the correct end-point. Mobile IP (MIP) [14] describesa global solution that overcomes this problem through the use of indirection provided by a set of network agents. It does notrequire any modifications to existing routers or end correspondentnodes.

With MIP, each mobile node is identified by an address from itshome network, regardless of the point of attachment. While amobile node is away from its home network, it obtains an IPaddress from the visiting network and registers it with a home

agent within its home network. The home agent intercepts anypackets destined to the mobile node, and tunnels or explicitlyroutes (source routing) them to the mobile nodes currentlocation. Thus, initiating this indirection requires a timely addressreconfiguration procedure and a home network registration process. The time taken for a mobile node to configure a newnetwork care-of address in the visiting network, and the timetaken to register with the home agent together constitute the(overall) handoff latency.

Handoff latency is the primary cause of packet loss and resultingin performance degradation, especially in the case of reliable end-to-end communication. As a result, numerous methods of minimizing the handoff latency have been proposed in theliterature. The proposed schemes can be broadly classified into

those that operate above the IP layer [4], [5], [2], [1] and thosethat operate at the IP layer [20], [16], [17], [9]. In general, thesolutions that operate at the IP layer are regarded as being moresuitable as they do not violate any of the basic Internet designprinciples [3], and more importantly because they do not requireany changes to the protocols at the corresponding nodes. Wefocus on the IP layer solutions in this paper.

Essentially, the IP layer solutions attempt to minimize theregistration delay by introducing a hierarchical structure, andlower the address (re)configuration delay through advanced

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.

MobiCom03 , September 14-19, 2003, San Diego, California, USA.Copyright 2003 ACM 1-58113-753-2/03/0009$5.00.


2/13


3/13

wishes to perform a fast-handover to a new attachment point. The RtSolPr contains the link-layer address of the new attachmentpoint, which is derived form the NARs (New Access Router)beacon messages. The MN will receive, in response, a ProxyRouter Advertisement ( PrRtAdv ) message from the PAR, with aset of possible responses indicating that the point of attachment isi) unknown, ii) known but connected through the same access

router or iii) is known and specifies the network prefix that theMN should use in forming the new CoA. Subsequently, the MNsends a Fast Binding Update ( F-BU ) to the PAR using its newlyformed CoA based on the prior PrRtAdv response, as the lastmessage before the handover is executed. The MN receives a FastBinding Acknowledgement ( F-BAck ) either via the PAR or theNAR indicating a successful binding.

The tunnel establishment phase creates a tunnel between the NARand the PAR. To establish a tunnel, the PAR sends a HandoverInitiation ( HI ) message (containing the MNs requesting CoA andthe MNs current CoA) to the NAR. In response, the PARreceives a Handover Acknowledgement ( HAck ) from the NAR. If the new CoA is accepted by the NAR, the PAR sets up atemporary tunnel to the new CoA. Otherwise, the PAR tunnels

packets destined for the MN to the NAR, which will take care of forwarding packets to the MN temporarily.

Finally, the packet forwarding phase is performed to smoothen thehandoff until subsequent registration by the MN to the homeagent is completed. The PAR interacts with the NAR to facilitatethe forwarding of packets between them, through the previouslyestablished tunnel. The initiation of the forwarding is based on ananticipation timing interval heuristic, that is, the network anticipates as to when a mobile node is likely to handoff andtherefore infers the appropriate packet forwarding moment basedon the anticipation timing interval. Such an interval is howeverextremely difficult to generalize, and forwarding too early or toolate will result in packet losses, negating the purpose of packetforwarding. Once arriving at the new access network, the MNsends the Fast Neighbor Advertisement ( F-NA ) message to initiatethe flow of packets (to itself) from the NAR.

Hierarchical Mobile IPv6 (HMIPv6) with Fast-handover [17] isanother attempt to further reduce the overall handoff latency fromwhat Fast-handover can offer alone. By combining HMIPv6 withFast-handover, latency due to i) address configuration and ii) thesubsequent home network/agent registration, can both be reduced.The MAP can be viewed as the local home agent, and in mostcases, it is located closer to the MN than the Home Agent (HA).Therefore, the signaling cost saved is the difference between theroundtrip time of the MN to the MAP and the roundtrip timebetween the MN to the HA, assuming that message processingtime within a network node is insignificant in comparison. Thiscombination requires minor modification to the standard HMIPv6protocol and the Fast-handover protocol, i.e., relocating theforwarding anchor point from the PAR to the MAP as outlined in[17].

An alternative to the packet forwarding scheme has also beenproposed, namely, the Simultaneous Bindings framework [11]. Itproposes to reduce packet losses at the MN by n-casting packetsfor a short period to the MNs current location and to n-otherlocations where the MN is expected to move to. The n-casting canbe carried out by the PAR, the MAP or the HA. The SimultaneousBindings scheme recognizes the problem of not knowing when

the MN is likely to move the timing ambiguity and attempts toremove it by careful packet duplication to multiple accessnetworks. It also claims to be able to address the problemassociated with ping-pong movement of MNs between two accessrouters by this packet duplication process, as it is not necessary tore-configure the MNs CoA during ping-pong movement (rapidback and forth movement between two access routers/points).

2.3 The S-MIP ProtocolThe Seamless Handoff architecture for Mobile IP (S-MIP) [8]provides a different approach to solve the timing ambiguityproblem. Unlike the Hierarchical Mobile IPv6 with Fast-handoverapproach (which uses the L2-trigger) or the SimultaneousBindings (which uses the L2-trigger and n-casts packets tomultiple destinations), in S-MIP, the network uses mobile nodelocation and movement patterns to instruct the MN when andhow handoff should be carried out. It is a structured approachamalgamating mobile node location tracking, movementpatterning and handoff algorithm(s) into an integral unit,providing smarter handoffs. The mobile node initiates a handoff while the network determines the handoff decision. S-MIP usessignal strength together with triangulation to track the MNslocation [8], and determine its movement pattern. The entity

which stores the history of the locations and determines themovement pattern, referred to as the Decision Engine (DE), issimilar to a MAP, and covers a group of access routers and theassociated MNs. The DE makes the handoff decision for the MNas described below. Once a decision is made, it is relayed to theaccess routers (PAR and NAR) and eventually to the MN as partof the Fast-handover PrRtAdv message 2.

From the movement pattern, the DE decides whether i) the MN ismoving linearly, ii) the MN is moving stochastically (includingping-pong), or iii) the MN is stationary and near the centerdividing boundary of two network coverage areas (see Figure 1).If determined to be moving linearly, every subsequent packet froma corresponding node (CN) arriving at the MAP, after the handoff decision is made, will be duplicated and send to both the PAR and

the NAR simultaneously. This is referred to as the Synchronized-Packet-Simulcasting (SPS) [8] process. These packets will bemarked with a S bit, as an option parameter in the IP header. TheNAR maintains an f-buffer, containing packets forwarded fromthe PAR (f-packets) and an s-buffer, containing packets that aremarked with the S bit (s-packets). Upon reception of the F-NA

2 S-MIP builds on the structure of HMIPv6 with Fast-handoverand operates similar to that of the Mobile Node Initiated Fast-handover.

Figure 1. Movement Scenarios

MAP

PAR NAR

MN

Center dividing boundary of 2 network coverage areas

Linear Movement ScenarioStochastic Movement Scenario

(inc. Ping-pong)

MAP

PAR NAR

MN

MAP

PAR NAR

MN

Stationary Scenario


4/13

message from the MN, the NAR will start emptying the f-bufferfollowed by the s-buffer. Meanwhile at the PAR, SPS specifiesthat only those packets (duplicated copy) which do not have the S bit marked will be forwarded to the NAR. In addition, all packets(s/f packets) will be sent on the wireless channel by the PAR. Inthe case that the MN does not switch networks immediately, itwill still be able to receive packets from the PAR.

If determined to be moving in a stochastical manner (includingping-pong movement), the PAR and the NAR will be put intoanticipation-mode where even through a MN might no longerwish to be associated with an AR, the AR will still maintain theMNs binding, in preparation for the MN returning. This avoidsthe unnecessary re-setup resource and time costs. In thisscenario, the MN is able to switch networks freely, using an F-

NA message, once the signal strength has decreased to a certainpredefined (by the DE) threshold. Lastly, if determined to be in astationary state near the center dividing boundary between twonetwork coverage, the MN will establish multiple bindingsbetween itself and the ARs, i.e. the MN uses more than one care-of address simultaneously.

In short, S-MIP is able to differentiate the movement type of theMN and act accordingly using different handoff strategies.Moreover, it is able to determine the likelihood of MNs next move, inferring from the history of recent mobile nodemovements. Coupling with an advanced local forwardingmanagement scheme, namely the SPS, the S-MIP framework uniquely differentiates itself from other frameworks describedprior.

3. A CASE FOR AN OPTIMIZED S-MIPFRAMEWORKWhile it has been shown in [8] that S-MIP provides a wellcomposed solution in providing a seamless handoff, we believethat there still exist some deficiencies within the framework.

Consider the following (see Figure 2), during a linear handoff, thePAR forwards packets which are not marked with an S bit in theIP option parameter to the NAR (f-packets), as well as sending acopy (f-packets) onto the wireless channel, as part of the SPSprocess. The sending of f-packets on the PARs wireless channelis to allow the MN to still receive these packets, in case it doesnot switch networks immediately [8]. Therefore the worst casescenario is one where the MN receives all the f-packets while stillin the access network of the PAR, but again receives all theforwarded f-packets (from PAR to NAR), when arriving at theNARs access network. In the case of reliable end-to-endcommunication, received packets that are out of sequence (inreality duplicated packets) will be interpreted as errors. In termsof TCP, duplicated acknowledgements will be sent by the receivercausing source throttling and maybe even retransmission. Asimple solution to this is simply not to send the f-packets onto thewireless channel.

In what follows we elaborate on our solution. Assuming that theaccess technology in use is 802.11b where the message/link corruption in the effective coverage area is zero [8], we caneliminate the out of sequence behavior by simplifying the handoff procedure as follows. Upon sending the F-BU message to thePAR, the MN must immediately switch to the NAR. Furthermore,the PAR must immediately forward packets to the NAR after

receiving the F-BU (which is then forward to the MAP, same asspecified in [8]). Therefore, the PAR only needs to send the F-

BAck message to the NAR. With this modification, the possibilityof receiving duplicated packets is reduced to zero. Furthermore,the only possible way that packet losses may occur, if thisoptimization is enforced, is through channel error duringtransmission. The probability of this happening is no greater thanin the original S-MIP. We argue that it is unnecessary for the PARto send f-packets onto the wireless channel. Unlike schemes suchas Simultaneous Bindings, in S-MIP, once a handoff decision hasbeen received by the MN, it must take place.

The second part of the optimization is an IP packet filteringmechanism at the NAR. This is to proactively prevent erroneouspacket forwarding by the PAR. One possible cause is when thePAR incorrectly forwards IP packets with the S bit set as f-packetsto the NAR. Essentially, a matching algorithm that compares IPpackets within the s-buffer and the f-buffer at the NAR is requiredto discard any identical packets in the s-buffer which have alreadybeen sent by the f-buffer. One way to proceed in such comparisonis to examine the 16 bit IP identification, fragment offset and flag(used in conjunction with the fragment offset) fields in the IPpacket header. In this way, one can be sure that even if IP packetshave been fragmented on the traversing path, they can be uniquelyidentified and therefore be compared and discarded whereappropriate. The actual implementation method is not within thescope of this paper. Furthermore, as such matching is onlynecessary when there are packets in the f-buffer, the computationresources required are minimal as the f-buffer size is small. This isbecause the size of the f-buffer depends on the time it takes amobile node to perform an L2 handoff, and the relay time betweenthe two access routers, which amount to tens of milliseconds atmost. It must be stressed that this mechanism need not be

performed by default at the NAR as the likelihood of packetduplication error, after the first part of our optimization, is verysmall.

Since our optimization deals with reducing the possibility of packets out of sequence during the forwarding (SPS) phase, theactual handoff latency remains the same when compared with theoriginal S-MIP. Thus, in the simulation experiment that follows,we will initiate the optimization by default. In our comparison, wewill illustrate the impact of out of sequence packets in the S-MIP

Figure 2. S-MIP Handoff Deficiency


5/13

framework, in other words, what might happen without suchoptimization.

4. SIMULATION MODELThe goal of our simulation is to examine the effectiveness of various Mobile IP extension architectures in L3 (IP layer) handoff latency reduction, over reliable end-to-end communication,namely TCP. In particular, we are interested in examining thebulk data flow rather than the interactive data flow scenario, sincebulk data flow is more prone to disruption during a handoff.

4.1 Implementation DetailsThis section describes the protocols we have implemented asextensions to the Network Simulator version 2 ( ns-2 ). Theseprotocols include Mobile IPv6, Hierarchical Mobile IPv6, Fast-handover, Simultaneous Bindings and S-MIP. The base nsdistribution (ns-allinone2.1b7a) [18] was patched with the nswireless extension module [21], allowing basic Mobile IP(v4)protocol operations. It was further extended with ourimplementation.

For the Mobile IPv6 protocol suite, we did not implement acomplete set of proper IPv6 features as this is unnecessary for oursimulation purposes. It must be noted that we did not implementall the protocols mentioned in this paper in full. Rather, we onlyimplemented what is necessary for our simulation purposes. Inrespect to our simulation, the key differentiator between MobileIPv4 and Mobile IPv6 is the Binding Cache Management. Thisincludes the IP Destination Option, which is necessary to supportthe Home Address Option. We implemented these on top of theexisting registration, packet encapsulation/decapsulationmechanisms of the ns wireless extension module. No securitymechanism was implemented for the binding cache update.

For Hierarchical Mobile IPv6 protocol suite, a MAP Agent wasimplemented to provide the MAP registration functionalities. The

MAP agent only supports the use of its address as the RCoA forthe MN. A simplified MAP discovery mechanism was created toenable the MAPs RCoA to be discovered by MNs. The MobileIP router advertisement (beacon) message was modified to includethe MAP advertisement option. The schematic of a MAP node isdepicted in Figure 3.

For the Fast-handover protocol suite, we made a slightmodification to the ns Node entity to facilitate the use of theencapsulator/decapsulator provided by the wireless extensionmodule. This enables tunnel mechanisms (IP encapsulations in IP[13]) to be setup between all types of node in ns , namely, wired,wireless and hybrid wired-wireless nodes (i.e. theBaseStationNode entity). Further, the new messages required bythe Fast-handover, that is, PrRtAdv , RtSolPr , HI , HAck , F-BU , F-

BAck and F-NA were also added. The BaseStation Node in ns-2 was further modified to handle these messages.

For the Simultaneous Bindings protocol suite, we are onlyinterested in the case where the MN binds with the MAP entity.Other cases, binding with the HA or the PAR, are not consideredin our comparison. Therefore we implemented purely theoperations required for the MAP binding case. The bicasting/n-casting mechanism was added to the MAP Node.

For the S-MIP protocol suite, we implemented the DecisionEngine Agent which collects the MN position information andmakes handoff decisions based on movement patternidentification. The positioning in this case can be easily calculatedusing the Node classs getLoc() support (not necessarily with thesignal strength value as described in [8]). Also, all new messagesassociated with the S-MIP protocol were implemented in full. Thesupport for simulcasting (SPS) was also included, consisting of the s-buffer, the f-buffer, and the forwarding techniques. Theoptimization techniques described in Section 3 were implementedand executed as default for the S-MIP framework.

Apart from these protocol extensions, two other importantmodifications were necessary. Firstly, the WaveLanimplementation of the current ns-2 , was conceived through theMonarch project [12], and was mainly developed for thesimulation of wireless ad-hoc networks (broadcast mode). What isrequired for our purpose is the support for the infrastructuremode. While a new implementation of the complete 802.11bstandard would be ideal, we opted for a simpler emulativesolution. This is made possible by a new Connection Monitor(CMon) entity. It is inserted between the port classifier (dmux_)and the receiving agent(s) (e.g. TCP/UDP) connecting to specificport(s) of the port classifier (dmux_). The CMon controls theMNs reception of packets of a communication flow, e.g. TCP.When the MN starts a L2 handoff to the new access network,CMon is set to drop any received packets until the L2 handoff is

Figure 4. Schematic of Mobile Node

Figure 3. Schematic of a MAP Node


6/13

complete. With this, we are able to treat the receptions of control

messages, (e.g. periodic beacons from ARs which arrive at theregistration agent (regagent_) bypassing the CMon) as if operatingin the periodic channel scanning mode. On the other hand, CMonemulates the channel change, which occurs when the MN isswitching between two access networks, by blocking the agentsfrom receiving any packets during this period. We assume thatadjacent access networks use different frequency channels. (SeeFigure 4 for the schematic of the Mobile node.) Anotheradvantage of using the CMon is the flexibility to identifycommunication flows. For instances, if operating in the routeoptimized mode where the MN is required to perform a bindingupdate to the corresponding node, the MN is able to query theCMon about the identity of any corresponding node percommunication flow.

Secondly, we implemented an additional handoff algorithm/strategy, namely Midway handoff, to facilitate thecomparison experiments. Since we know that for S-MIP, a MNwill perform the handoff around the center dividing boundarybetween two access networks [8], the purpose of the Midwayhandoff algorithm is to ensure that all other frameworks handoff near the time vicinity of S-MIP. This is to provide a more accurateand consistent comparison. The Midway handoff is defined assuch that a MN must handoff to an access router closer to itself,determined via the reception of the beacon message. This isespecially tailored for the ping-pong movement experimentspurposes.

4.2 Simulation ScenariosFigure 5 illustrates the network topology used for the simulationexperiments. This topology reflect the setup of an open spacelocal environment (where the MN is situated) connecting to adistant home network. Both Corresponding Node (CN) and theHome Agent (HA) are connected to an (dummy) intermediatenode (N1) with 2 milliseconds (ms) delay, 100 Megabits/s (M/s)links. The link between N1 and the MAP is a 100M/s link with50ms delay. This simulates the distant home network (macromobility). Below the MAP is considered to be the local network (micro mobility). The MAP is connected to 3 intermediate nodes(N2, N3, N4) with 2ms delay, 10M/s links. N2 is connected with

the PAR while others to NARs, all with 2ms delay, 1M/s links.All links use the RED (Random Early Detection) queue, exceptlinks from the intermediate nodes to the ARs (both NAR andPAR), which are Droptail (FIFO) queues. The access routers areset to be 70 meters apart with free space environment in between.This reduces the complexity of results analysis, as we only need toconsider signal interference. We assume the use of 802.11 as our

access technology and the effective coverage area is set to 40meters in radius. A ns TCP source (Tahoe) agent is attached to theCN and a ns TCP sink agent is attached at the MN. The TCPpacket size is set to 512 bytes and window size is 32. A bulk datatransfer application is attached on the established TCP link thattransfers packets from the CN to the MN, 5 seconds after the startof the simulation. The total duration for the simulation is 80seconds.

We model two movement scenarios, namely the MN movinglinearly between two access networks and MN moving in a back and forth (ping-pong) fashion near the midway between twoaccess network coverage areas. For the linear case, the MN startsmoving towards the NAR from the PAR 10 seconds into thesimulation, at the speed of 1 meter/second (approximating human

walking speed). It stops at the NAR when simulation time reaches80 seconds. The corresponding handoff algorithm used in thisscenario is the priority handoff, where the MN switches from oneAR to another AR if the priority (contained in the beaconmessage) of the new AR is higher than that of the current one. Wefavor this handoff strategy over midway handoff to minimizeunexpected interferences and to maintain the consistency as towhen a handoff will take place, for comparison purposes. We setthe beacon priority of the NAR to be higher than the PAR, hencethe handoff should occur when the MN receives the first fewbeacon messages from the NAR at around 40 seconds into thesimulation. (The priority handoff is included with the ns wirelessextension module.) For the ping-pong case, we define themovement of the MN to be similar to that of the linear case,except that at 46 seconds into the simulation (just past midway)the MN reverses its direction of movement back towards the PAR.It reverses its direction every 2 seconds thereafter, until finallyheading towards the NAR again, 52 seconds into the simulation.(See the stochastic scenario in Figure 1 for the illustration of thisping-pong movement.) The corresponding handoff algorithm usedin this scenario is the midway handoff algorithm. Finally, in allsimulations, we consider the simplistic case with only one MNinitiating one single connection at a time.

5. EXPERIMENTAL RESULTSThe experiments were separated into two groups, namely, thelinear movement experiments and the ping-pong movementexperiments. We first simulated all the frameworks mentioned,namely, MIPv6 [15], MIPv6 (flat) with Fast-handover, HMIPv6,HMIPv6 with Fast-handover, Simultaneous Bindings, and S-MIP(both optimized and non optimized), with the linear movementscenario. Following this, we simulated all frameworks with theping-pong movement scenario. We set the L2 handoff time to20ms and address resolution time to 100ms for all experiments 3.

3 Currently, we lack statistical L2 handoff values to formulate aL2-handoff delay distribution. Therefore we are unable to

Figure 5. Simulation Network Topology


7/13

The address resolution time here refers to the time taken for a MNto obtain a new care-of address. We measured the TCP goodput,delay and the cwnd (TCP congestion window) values for allsimulations.

5.1 Hierarchical Mobile IPv6This section describes the handoff latency comparison betweenHMIPv6 and MIPv6. In Figure 6, the source_send_mip and thesource_send_hmip curves (the lower two curves) illustrate thehandoff delay for the MIPv6 and the HMIPv6 respectively fromthe perspective of sources (CN) sending sequence. In the MIPv6case, the time between the first retransmitted packet sent by thesource and the last time this packet was sent is labeled with a , inFigure 6. It is approximately 747 milliseconds (ms). This must not be used as a measure for the overall handoff delay. We need toadd the time required for this packet to reach the MN. At least anadditional 60ms is necessary (five 2ms delay link segments, one50ms link plus wireless link delay, see Figure 5), as we areoperating in non route-optimized mode, where packets from theCN are sent to the HA first before being routed to the MN. Thetotal delay is in fact 814ms. In this paper, we use this duration as a

standard measure for all frameworks analyzed. We refer to thisduration as delay D .

In the HMIPv6 case, label b depicts the L2 handoff duration(happening at the MN) while label c depicts the address resolutionperiod. Subsequently, the MN performs the MAP binding update(label d ). After the successful binding, the MN receives out of sequence packets, and thus sends acknowledgement ( ack )messages, containing the expected sequence number, back to theCN. This period is marked with label e, and consists of the timefor ack messages to traverse from the MN to the MAP, the timefrom the MAP to the HA, and the time from the HA to the CN.After the CN receives three such ack messages, retransmissionstarts. Note that the TCP enters slow start due to duplicated ack messages received previously. The D value for this case is 326ms.

Figure 7 illustrates the effect that address resolution time has onthe handoff latency. The source_send_mip , source_send_hmip ,and the source_send_hmip_long curves illustrate the handoff delay for MIPv6, HMIPv6 with 100ms address resolution delayand HMIPv6 with 200ms address resolution delay respectively.Labels a through e are the same as in Figure 6. Label g depicts the200ms address resolution period, while labels f and h representthe L2 handoff and the MAP binding update. Compared with theapproximately 60ms delay for the previous case (label e in Figure6), there is an approximately 450ms delay period (label i) beforethe retransmission starts. This is because the delay (mainly due toaddress resolution) in obtaining a care-of address means that theMN is unable to receive any packets, which eventually drives theTCP sources (CN) to reach zero window and stop transmitting.When this happens, the performance is similar to that of thesimple MIPv6 case, as all packets sent from the offered windoware lost due to handoff. Eventually, TCP enters retransmissionmode, similar to that of the MIPv6 framework.

provide a more realistic simulation except to fix the L2 handoff time. Same applies to address resolution time.

5.2 Mobile IPv6 (Flat) with Fast-HandoverWe compare MIPv6 and MIPv6 with Fast-handover in thissection. Figure 6 illustrates the handoff delay for MIPv6 withFast-handover with the source_send_fast curve, from theperspective of the sources sending sequence. Label f shows thetime taken to set up the fast-handover, that is, measured from thetime the MN sends the RtSolPr message till the time it receivesthe PrRtAdv message, including the intermediate messageexchange between the PAR and the NAR ( HI and HAck messages). As can be observed in Figure 6, at around the 40.5smark, the source_send_fast sends a little longer than thesource_send_mip before being interrupted by the handoff. This isbecause the setting up of fast-handover does not prevent TCPfrom continuing packet transfer. A TCP flow only starts to bedisrupted once entering the binding process. The binding update(with HA) duration is depicted using label g, while the L2 handoff is through label h. We switch network (L2 handoff) immediatelyafter sending the binding updates, for all schemes employing theFast-handover mechanism, in consideration of consistency andeasy comparison purposes. Similar to the MIPv6 case (label e),

6150

6200

6250

6300

6350

6400

6450

40 40.5 41 41.5 42

T C P S e q u e n c e

N u m

b e r

Time (seconds)

source_send_fastsource_send_hmip

source_send_mipa

b dc e

f g

h

i

Figure 6. Comparison between MIPv6, HMIPv6 and MIPv6(flat) with Fast-Handover

6150

6200

6250

6300

6350

6400

6450

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

source_send_hmipsource_send_hmip_long

source_send_mip

a

b c d

f

e

hg i

Figure 7. Comparison between MIPv6, HMIPv6 andHMIPv6 with longer address resolution (200ms)


8/13

label i depicts the delay of the ack message traversing from theMN to the CN. The binding update delay is proportional to theround-trip delay between the CN and the MN (traversing via theHA in our case). This is the weakness of operating Fast-handoverin the flat Mobile IP environment. Even though that theforwarding mechanism is delivering packets from the PAR to theNAR, the MN is unable to receive these until the binding updateis complete, signified by the sending of the F-NA message toactivate the data flow at the NAR. The D value for this case is 358ms.

5.3 Hierarchical Mobile IPv6 with Fast-handoverThis section details the handoff behavior for the HMIPv6 with

Fast-handover scheme. In prior work, Hsieh [7] illustrated theperformance of a simple superimposition of HMIPv6 scheme withthe Fast-handover protocol. It showed that superimposition resultsin a complex behavior. In contrast, we present the integratedapproach, outlined in the Appendix section of [17]. The maindifference being that the forwarding mechanism (part of the Fast-handover) is anchored at the MAP, instead of at the PAR. Theintegrated approach is an optimized solution in comparison tothat of the simple superimposition. Essentially, two notable eventsoccur as denoted with box A and box B in Figure 8a. Firstly,packet loss happens when L2 handoff is initiated (box A).

Secondly, the MN starts receiving out of sequence packets afterswitching to the new access network (box B).

Figure 8a shows the details of handoff from the TCP receivers(sink) perspective. The receivers receiving sequence is denotedby the sink_recv (data) curve while the sending sequence isdenoted by the sink_send (ack) curve. Likewise, Figure 8b showsthe details of handoff from the TCP senders (source) perspective.The senders sending sequence and the receiving sequence aredepicted by the source_send (data) and the source_recv (ack)curves respectively. The label a in Figure 8a depicts the timevicinity where the first instance of disruption in the TCPcommunication occurs, namely the L2 handoff. Some packets arelost as a result. Due to the Fast-handover forwarding setupbetween the PAR and the NAR, the MN is able to receive theforwarded packets (through the use of the F-NA message) at thenew access network from the NAR shortly after arriving, as shownnear label b. However, these packets contain out of ordersequence numbers (higher than expected). As a result, an ack reply, containing the expected sequence number, is sent for eachof the (out of sequence) data packet received (label c). This isreflected in the senders receiving sequence (label g). Theseduplicated acks trigger the TCP sender to enter the congestionmode and slow start occurs (around label h).

The TCP slow start process continues until around label d . By thispoint in time, the missing packets have all been received by theMN. Due to accumulative acknowledgement, the MNs windowmoves a whole segment and opens abruptly. This is reflected inthe TCP sender near label i, as well as the corresponding cwnd curve shown at around 41.2 second (label m). However, packetssent previously by the sender (label j) still arrive at the receiver(label e). These are repeatedly acknowledged with the sameexpected sequence number (label f ) by the receiver. Eventuallythese ack messages arrive at the sender, but are discarded sincethe sequence numbers have already been acknowledged. Thecommunication returns to normal operation after this. The D valuefor this case is 270 ms.

5.4 Simultaneous Bindings and S-MIPWe compare the Simultaneous Bindings scheme and the S-MIPframework (optimized) in this section. A hypothetical result isalso shown for comparison purposes, namely the smip_nonop

5950

6000

6050

6100

6150

6200

6250

40 40.5 41 41.5 42

T C P S e q u e n

c e N u m

b e r

Time (seconds)

sink_recv (data)sink_send (ack)

ae

f

c

db

A

B

5900

5950

6000

6050

6100

6150

6200

6250

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

source_send (data)

5900

5950

6000

6050

6100

6150

6200

6250

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

source_send (data)source_recv (ack) 0

5

10

15

20

25

30

40.6 40.8 41 41.241.4 41.6 41.8 42

c w n

d v a

l u e

0

5

10

15

20

25

30

40.6 40.8 41 41.241.4 41.6 41.8 42

c w n

d v a

l u e

g hj k

i

m

a)

b)

Figure 8. Handoff Behavior for HMIPv6 with Fast-handover in detail

5950

6000

6050

6100

6150

6200

6250

40.2 40.4 40.6 40.8 41 41.2


N u m

b e r

Time (seconds)

source_sendsource_recv

sink_recvsink_send

a

b

Figure 9. Handoff Behavior for S-MIP in detail


9/13

(non optimized) case, where we deliberately created the situationwhere out of sequence (duplicated) packets are present at theNAR.

As can be seen from the source_send , source_recv , sink_recv andsink_send curves in Figure 9, the S-MIP (optimized) framework performs exceedingly well, considering that the overall handoff perceived by the sender is a mere 100ms in durationapproximately ( source_send curve). There is no apparent packetloss perceived by the sender and therefore no congestion or flowcontrol is required. The D value cannot be calculated since thereare no packets being retransmitted. The emptying of the s-bufferand the f-buffer corresponds to ack message responses near labelb (sink_send curve) in Figure 9. In other words, theseacknowledgements, for data packets sent by the source (around

label a ), are simply delayed slightly in reply, due to the handoff.Subsequently, everything returns to normal as if no handoff hadtaken place. In contrast, the worst case scenario for the nonoptimized S-MIP case is shown as the nonop (S-MIP nonoptimized) curves in Figure 10a-d, where packet out of sequencetakes place at the NAR in the framework.

The source_send_smip_nonop , sink_recv_smip_nonop ,source_recv_smip_nonop , and sink_send_smip_nonop , curvesillustrate the hypothetical case for the S-MIP non optimizedscheme, in Figure 10a-d respectively. A few things can be noted

in this scenario. Due to the coarse grain buffering mechanism of S-MIP, this is a case where no packets are lost during the handoff.However, we deliberately induce duplicated packets within the f-buffer and the s-buffer of the NAR, to cause out of sequencebehavior. This illustrates the effect of receiving out of sequencepackets by the MN and how it may upset the TCP flow within theS-MIP framework. Nevertheless, compared to packet loss, thepenalty is not as severe in our experimental context, because of the accumulative acknowledgement mechanism. The two keyhandoff behaviors are, firstly, the receiving of the duplicatedpackets by the MN (label a in Figure 10b). Secondly, theseduplicated packets cause the MN to send duplicated ack messages(label b). Fortunately, these have already been acknowledgedpreviously, therefore are discarded by the CN (label c).

The handoff behavior for Simultaneous Bindings is similar to thatof the HMIPv6 with Fast-handover case, as can be seen from thesource_send_bicast (Figure 10a), sink_recv_bicast (Figure 10b),source_recv_bicast (Figure 10c), and the sink_send_bicast (Figure 10d) curves, when compared with Figure 8. This isbecause, the benefit of bicasting/n-casting have been erodedaway, as the MN is traversing linearly and switching networksimmediately after sending the binding update to the MAP in oursimulation. For the Simultaneous Bindings case, as the MN isswitching immediately, the only subtle difference between it and

5950

6000

6050

6100

6150

6200

6250

6300

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

Source Sending Sequences

source_send_smip_nonopsource_send_bicast

a)

5950

6000

6050

6100

6150

6200

6250

6300

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

Sink Receiving Sequences

sink_recv_smip_nonopsink_recv_bicast

b)

5900

5950

6000

6050

6100

6150

6200

6250

6300

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

Source Receiving Sequences

source_recv_smip_nonopsource_recv_bicast

c)

5950

6000

6050

6100

6150

6200

6250

6300

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

Sink Sending Sequences

sink_send_smip_nonopsink_send_bicast

d)

a

b

c

Figure 10. Handoff Behavior for Simultaneous Bindings and S-MIP (non optimized) in detail


10/13

the HMIPv6 with Fast-handover case, is that some packetsinside the link segment between the MAP and the PAR might belost as a result of the network switch. However, since the packetforwarding delay between the PAR and the NAR is much smallerthan the time taken to complete a L2 handoff, even if thesepackets are forwarded from the PAR to the NAR (as in the casefor HMIPv6 with Fast-handover), it would nevertheless bedropped by the NAR, since the MN is not likely to havecompleted the L2 handoff.

Even if the MN is to switch slightly later, in order to eliminatesegment packet loss [8], some packet losses will still take placedue to the L2 handoff, similar to that of the HMIPv6 with Fast-handover case. Although Simultaneous Bindings might cover-upthe timing ambiguity, we argue that the performance improvementis minimal, as packet loss is a substantial penalty. In comparison,as shown in Figure 10a-d with the nonop (S-MIP non optimized)curves, the severity of packet loss is much greater than that of packets out of sequence. For this reason, the performance forSimultaneous Binding and HMIPv6 with Fast-handover would besimilar. The D value is 268ms for the Simultaneous Bindingsframework.

5.5 Ping-pong Movement ResultsIn this section, we examine the effect of ping-pong movement forall frameworks which we have examined thus far. We havedefined in the previous section how the ping-pong scenario issimulated (see Figure 1 and Section 4.2). Figure 11 depicts thehandoff behavior of ping-pong movement for the MIPv6, MIPv6(flat) with Fast-handover and HMIPv6 frameworks with curvessource_send_mip_pp , source_send_fast_pp andsource_send_hmip_pp respectively. Similarly, Figure 12illustrates the handoff behavior for HMIPv6 with Fast-handover,Simultaneous Bindings, S-MIP and S-MIP non optimizedschemes with source_send_hmipfast_pp , source_send_bicast_pp ,source_send_smip_pp and source_send_smip_nonop_pp curvesrespectively. (Note that we are only presenting from theperspective of sources sending sequence here.) As can be seen inFigure 11, the MIPv6 completely breaks down during the ping-pong movement. The MIPv6 with Fast-handover and the HMIPv6schemes are also notably disrupted with distinguishable breaks inthe communication flow. Figure 12 shows that the HMIPv6 with

Fast-handover and the Simultaneous Bindings schemes areaffected to a lesser extent. However, severe throttling (i.e. thedecrease in gradient) is still notable for both cases. Remarkably,the S-MIP case illustrates excellent resilience to ping-pongmovement. The communication remains virtually unaffected.Essentially, the ping-pong movement can be perceived as multipleindividual linear handoffs. The ping-pong movement defined inthe experiment is too short for the MIPv6 scheme to complete asingle linear handoff therefore the scheme performs poorly.Except for S-MIP, if we shorten the period in-between theswitching back and forward (towards the D value), eventually allschemes will break down (smaller than D value), similar to that of the MIPv6 case. The S-MIP guards against such break down asanother handoff requested by the MN will not be allowed by theDE until the current one is completed, as specified in [8].

6. DISCUSSION6.1 Performance ComparisonTable 1 illustrates the relative goodput for all frameworks incomparison to that of a scenario where the MN is stationary nearthe PAR, i.e. no handoff takes place. We measure the time takenfor each framework to transfer a 6.5 megabytes (M) file, with the

Table 1. Performance Matrix

Avg. Goodput(Kbytes/second)

Time to transfer6.5M file (seconds)

Frameworks Linear Pingpong Linear Pingpong

MIPv6 100.847 83.820 66.001 79.408

MIPv6 + FastH 101.213 90.240 65.762 73.759HMIPv6 101.520 91.587 65.563 72.674

HMIPv6 + FastH 101.593 93.867 65.516 70.909

Bicast/n-cast 101.580 92.713 65.524 71.051

SMIP (nonop) 102.007 91.113 65.127 68.538

SMIP 103.106 102.120 64.554 65.178

No Handoff 103.293 64.438

7100

7200

7300

7400

7500

7600

7700

7800

7900

8000

45 46 47 48 49 50 51 52 53


N u m

b e r

Time (seconds)

source_send_fast_ppsource_send_miph_pp

source_send_mip_pp

Figure 11. Ping-pong behavior for MIPv6, HMIPv6 andMIPv6 (flat) with Fast-handover

7000

7200

7400

7600

7800

8000

8200

8400

8600

8800

9000

45 46 47 48 49 50 51 52 53


N u m

b e r

Time (seconds)

source_send_hmipfast_ppsource_send_bicast_pp

source_send_smip_ppsource_send_smip_nonop_pp

Figure 12. Ping-pong behavior for HMIPv6 with Fast-handover, Simultaneous Bindings and S-MIP


11/13

linear and the ping-pong movement scenarios. As shown in Table

1, with the perfect condition (no handoff), it takes 64.438s totransfer 6.5M file from the CN to the MN with the TCP goodputof 103.293 kilobytes/second (K/s). The S-MIP framework compares well with the no handoff case, achieving a goodput of 103.106 K/s for linear movement and requires slightly longertransfer time of 64.554s. What makes S-MIP stand out is itsperformance during the ping-pong movement scenario, where thegoodput is still maintained at over 100K/s, at 102.120 K/s, andthe transfer time at 65.178s. The closest goodput is at 93.867 K/sin comparison, showing a significant reduction in performance.The worst performer is naturally the MIPv6 scheme, taking almostthe full 80s to transfer the data in the ping-pong scenario, whileachieving a 66.001s transfer time (still the worst) for the linearcase. The spread in time for the linear scenario between the bestand the worst framework is 1.447 seconds. However, thisvariation is amplified for the ping-pong scenario to 14.23 seconds,an increase of almost 10 folds. In conjunction to Table 1, weillustrate the TCP congestion window ( cwnd value) plottedagainst time for the S-MIP framework in Figure 13. As can beobserved, for both the linear (handoff at around t = 40s) and ping-pong movement scenarios (handoff between t = 45s and t = 55s),the cwnd values for S-MIP (SMIP/SMIP PP) do not dropsignificantly unlike the case for the Simultaneous Bindingsscheme (Bicast/Bicast PP), which typifies the cwnd behavior forall other frameworks.

Figure 14 illustrates the handoff delay (linear) for all frameworksmentioned in this paper, from the perspective of the TCP sourcessending sequence. We transpose curves for HMIPv6 with Fast-

handover, Simultaneous Bindings, SMIP non optimized and S-MIP, in order to view clearly the relationship among themselves,as well as between them and those which possess much longerdelay, i.e. MIP, HMIPv6 and MIPv6 with Fast-handover schemes.With our experimental setup, the order of the most effectivelatency reduction scheme to the least effective is: SMIP, SMIPnon optimized (if considered), Simultaneous Bindings ( D =268ms), HMIPv6 with Fast-handover ( D = 270ms), HMIPv6 ( D =326ms), MIPv6 (flat) with Fast-handover ( D = 358ms), and lastlyMIPv6 ( D = 814ms). We rank Simultaneous Bindings higher thanthat of the HMIPv6 with Fast-handover because we believe it can

potentially offer better results, even though in our simulationscenario, the two are comparable. The performance of HMIPv6

and MIPv6 (flat) with Fast-handover are dependent on theexperimental topology layout. Therefore the ordering between thetwo is only applicable to this series of simulation experiments.

It is well understood that, if applying the normal Mobile IPhandoff algorithm, the overall handoff latency is at least 2seconds, as the mobile node is required to wait for 2 beaconmisses before initiating a handoff. In this paper, we look at anoptimization of this, where the MN initiates a handoff when itreceives an unseen beacon from a new access router 4. With this,the handoff latency values ranges from approximately 800ms (forthe MIP(v6) case) to approximately 250ms (for the SimultaneousBindings case), a significant reduction from 2 seconds. Moreimpressively, with the S-MIP scheme, although the actual handoff delay is around 100ms, the latency perceived by the sender and

the receiver is zero, i.e. as if no handoff has ever occurred.

6.2 SummaryThe performance of the L3 handoff latency reduction for theHMIPv6 framework is bounded by the address resolution time(A), the one-way trip time (T) from the CN to the MN, and thesize of the sliding window (W). If time A is greater than the timefor the sender to send W packets to a receiver located T secondsaway, then the performance degrades to that of the MIPv6 case.For the (Flat) MIPv6 with Fast-handover case, its performance isaffected predominantly by the round-trip time between the CNand the MN (the forwarding delay from the PAR to the NAR isvery small in comparison). This time determines the number of packet errors (loss, if the NAR not buffering, duplicated ack , if

the NAR is buffering) that occur at the MN. A recovery process,i.e. slow start, is almost inevitable, unless no more than 3 errorsare detected.

For HMIPv6 with Fast-handover and the Simultaneous Bindingsframeworks, the key deficiency is the packet loss due to the L2handoff, as these two frameworks do not explicitly buffer packets

4 This is only suitable for linear movement or very fast MNmovement, i.e. the MN is within a moving vehicle.

5950

6000

6050

6100

6150

6200

6250

6300

6350

6400

6450

40 40.5 41 41.5 42


N u m

b e r

Time (seconds)

source_send_mipsource_send_hmip

source_send_fastsource_send_hmipfast

source_send_smip_nonopsource_send_bicastsource_send_smip

Figure 14. A comparison between all Frameworks

40

60

80

100

120

140

160

180

30 35 40 45 50 55 60 65 70 75 80

c w n

d

Time (seconds)

SMIP

0

20

40

60

80

100

120

140

30 35 40 45 50 55 60 65 70 75 80

c w n

d

Time (seconds)

Bicast

40

60

80

100

120

140

160

180

30 35 40 45 50 55 60 65 70 75 80

c w n

d

Time (seconds)

SMIP PP

0

20

40

60

80

100

120

30 35 40 45 50 55 60 65 70 75 80

c w n

d

Time (seconds)

Bicast PP

Figure 13. A comparison on cwnd value over time for SMIPand Simultaneous Bindings


12/13

during a handoff, triggering congestion control mechanisms. Incomparison with this, the subsequent packets out of sequencehave a lesser impact on the handoff latency. Even though thisshould have also triggered the congestion control, due to the setupof the forwarding scheme and the accumulative acknowledgementat the sender, the activation of the congestion control mechanismis avoided. Furthermore, initiating a handoff or packet forwarding

based on a pre-determined or on-the-fly anticipation timinginterval is undesirable. It is most likely to be sub-optimal, unlessthe anticipation takes into consideration not just the time MN islikely to switch network, but also the movement direction of theMN.

S-MIP is a novel scheme that addresses all of the short comingsdescribed prior. It buffers packets explicitly at the NAR andprovides an explicit anticipation method through network determined handoff, calculated passively using movementtracking and the MN position identification (via triangular signalstrength evaluation). Although in [8], Hsieh illustrated a primitiveMN position identification scheme for open space environment,S-MIP is structured in a way where more sophisticatedpositioning scheme maybe developed and plugged-in to the

framework, allowing it to operate in different physicalenvironments. This is possible since the DE messaging (thetrigger) mechanism is access network independent.

We identified that with the original S-MIP framework, packets outof sequence are still likely to occur if the MN is allow to receivepackets from the PAR (i.e. not switching network immediately),after sending the binding update to the MAP. In this case, theemptying of the f-buffer (containing packets which the MN havealready received previously at the PAR) will cause the MN tosend duplicated ack messages to the CN, resulting in sourcethrottling and performance degradation. Depending on the flavorof the TCP, this error is not as severe as packet loss due to theaccumulative acknowledgement mechanism. We presented anoptimization for S-MIP which prevents the occurrence of suchsituation. We argue that by immediately switching network, aftersending the binding update, the possibility of such performancedegradation can be reduced.

7. CONCLUSIONAnalyses of the various handoff latency reduction frameworksexamined in this paper showed that it is possible to significantlyreduce the latency perceived by a mobile node during a handoff.This is especially true for the S-MIP case, achieving packetlossless handovers, where the mobile node and the correspondentnode are unaware of the handoff which is taking place. We furtheroptimize the S-MIP scheme by eliminating deficiencies associatedwith possible packets out of sequence during its local forwardingmanagement (SPS) phase.

Not knowing when a mobile node will initiate a handoff and how it is likely to move after a handoff will inevitably result in packetlosses. With packet forwarding (as the case for Fast-handovers) orpacket n-casting (Simultaneous Bindings), these losses may bereduced. However, this is at the expense of duplicated packetsand/or delay in receiving packets. The S-MIP framework specifies, with reasonable accuracy, when a mobile node shouldswitch and how it should switch proactively, through passivemovement tracking. It also specifies different techniques inoptimizing a handoff by categorizing movement patterns of

mobile nodes. How a mobile node should switch network iscritical when considering stochastic/ping-pong movements. Lack of proper management leads to unnecessarily high setup cost, andmay results in severe disruption if the switching frequency isshorter than the minimal time required for the L3 handoff.

In future work we plan to study S-MIP under multiple connectionscenarios where connections interfere with each other, andexamine its performance under such condition, in both linear andping-pong movement cases. We will examine the scalability of theDecision Engine and the impact of multiple node and multipleconnections on the S-MIP architectural design. Furthermore, weplan to design more sophisticated positioning schemes whichmaybe used to enable the S-MIP framework to operate undermore complicated physical environments.

8. ACKNOWLEDGMENTSThe authors would like to thank the anonymous reviewers andMobqos Group members. Special thanks to Yuri Ismailov,Stephen Herborn, Tim Hu and Eranga Perera.

9. REFERENCES[1] Bakre, A., and Badrinath, B.R. I-TCP: Indirect TCP forMobile Hosts. In Proceedings of ICDCS , May 1995.

[2] Balakrishnan, H., Seshan, S., and Katz, R. H. ImprovingReliable Transport and Handoff Performance in CellularWireless Networks. ACM Wireless Networks , Vol. 1, No. 4,December 1995.

[3] Blumenthal, M. S., and Clark, D. D. Rethinking the designof the Internet: The end to end argument vs. the brave newworld. ACM Transactions on Internet Technology , Vol. 1,No. 1, August 2001.

[4] Caceres, R., and Iftode, L. Improving the Performance of Reliable Transport Protocols in Mobile ComputingEnvironments. IEEE Journal on Selected Areas inCommunications , Vol. 13, No. 5, June 1995.

[5] Caceres, R., and Padmanabhan, V. N. Fast and ScalableHandoffs in Wireless Internetworks. In Proceedings of

MobiCom , 1996.[6] Campbell, A. T. et al. Comparison of IP Micro-Mobility

Protocols. IEEE Wireless Communications Magazine , Vol.9, No. 1, February 2002.

[7] Hsieh, R., and Seneviratne, A. Performance analysis onHierarchical Mobile IPv6 with Fast-handoff over End-to-End TCP. In Proceedings of GLOBECOM , Taipei, Taiwan2002.

[8] Hsieh, R., Zhou, Z.-G., and Seneviratne, A. S-MIP: ASeamless Handoff Architecture for Mobile IP. InProceedings of INFOCOM , San Francisco, USA, 2003.

[9] Koodli, R. (eds.). Fast Handovers for Mobile IPv6. Internet

Draft, IETF, September 2002. Work in Progress.[10] Malki, K. (eds.). Low Latency Handoffs in Mobile IPv4.

Internet Draft, IETF, June 2002. Work in Progress.[11] Malki, K., and Soliman, H. Simultaneous Bindings for

Mobile IPv6 Fast Handoffs. Internet Draft, IETF, June2002. Work in Progress.

[12] Monarch project. http://www.monarch.cs.rice.edu.[13] Perkins, C. IP Encapsulation within IP. RFC 2003, IETF,

October 1996.


13/13

[14] Perkins, C. IP Mobility support for IPv4. RFC 3344, IETF,August 2002.

[15] Perkins, C., Johnson, D., and Arkko, J. Mobility Support inIPv6. Internet Draft, IETF, January 2003. Work in Progress.

[16] Ramjee, R. et al. HAWAII: A Domain-Based Approach forSupporting Mobility in Wide-area Wireless Networks. InProceedings of ICNP , 1999.

[17] Soliman, H., Castelluccia, C., Malki, K., and Bellier, L.Hierarchical MIPv6 Mobility Management. Internet Draft,IETF, October, 2002. Work in Progress.

[18] The UCB/LBNL/VINT Network Simulator ns (version 2).http://www.isi.edu/nsnam.

[19] Thomson, S., and Narten, T. IPv6 stateless addressautoconfiguration. RFC 2462, IETF, December 1998.

[20] Valko, A. et al. Design and Performance of Cellular AccessNetworks. IEEE Personal Communications , Special issueon IP-Based Mobile Telecommunications Networks, 2000.

[21] Widmer, J. Extensions to the ns Network Simulator.http://www.informatik.uni-mannheim.de/~widmer .

1. a comparison of mechanisms for improvingmobile ip hand-10.1.1.9.8288

Documents