- Email: [email protected]
A new flow-based fast handover method for Mobile IPv6 network with route optimization
Available online at www.sciencedirect.com
Computer Communications 30 (2007) 3870–3880 www.elsevier.com/locate/comcom
A new flow-based fast handover method for Mobile IPv6 network with route optimization Chen Jin *, Zhang Xi-Huang College of Information Engineering, Jiangnan University, Wuxi 214122, China Received 9 November 2006; received in revised form 2 October 2007; accepted 2 October 2007 Available online 13 October 2007
Abstract Flow-based fast handover method is designed for Mobile IPv6 network. The FFHMIPv6 uses the flow state information to redirect the traffic flow to a new location. This makes it possible that the reception of packets simultaneously with the BU registration process, thus minimizing the delay experienced in the handover. But it does not consider the route optimization. In this paper, a new flow-based fast handover method is proposed which enhanced the existing flow-based fast handover method to support route optimization. The analysis shows that this scheme has a better performance than the existing FFHMIPv6 scheme. 2007 Elsevier B.V. All rights reserved. Keywords: Mobile IPv6; Fast handover; FFHMIPv6; Route optimization
1. Introduction Mobile IPv6 [1] enables a Mobile Node to maintain its connectivity to the Internet when moving from one access router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This ‘‘handover latency’’ resulting from standard Mobile IPv6 procedures, namely movement detection, new care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as voice over producing the handover latency could be beneficial to non-real-time, throughput-sensitive application as well [2]. In [2], the improved idea of Mobile IPv6 [1] is presented to minimize the handover latency in Mobile IPv6 networks. This proposal utilizes the L2 trigger to obtain the new CoA at the new Router in advance and then establishes a bidirectional tunnel between the oAR and the NAR, so that it can minimize the packet loss, handover delay and the ser-
*
Corresponding author. Tel.: +86 510 85912448. E-mail address: [email protected] (C. Jin).
0140-3664/$ - see front matter 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2007.10.008
vice disruption during the handover. In [3,4], a Hierarchical Mobile IPv6 (HMIPv6) proposal presents a new entity named Mobile Anchor Point (MAP) to act as a local HA to reduce the signaling delays during handover. The single combination of Fast and Hierarchical Mobile IPv6 ([F+H]MIPv6) [3] tries to incorporate the advantages of FMIPv6 and HMIPv6 together. Based on [2–4], the enhanced fast handover HMIPv6 (F-HMIPv6) scheme [5] is presented. In this paper, the tunnel for a handover is established between the MAP and NAR, and the MN exchanges the signaling messages for the handover with MAP. F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages [5]. However, the handover delay still remains unacceptable for some applications. In the past few years, many different proposals have been presented. Some of the proposed method is router-assisted. They require modifications for functional extension of the ARs. Several slightly different handover solutions using local mobility has been proposed in [6–8], which is proposed as an extension to MIPv6 for Localized Mobility Management (LMM) [9]. They utilize a Local Mobility Agent (LMA) located in the visited domain to act as a local HA. When the MN changes its point of attachment within the
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
LMM domain, it only informs to the LMA, whereas its globally perceived IP address remains unchanged. This diminishes signaling for re-registration with HA and CNs, thus reduces the handover latency. There are many similar ideas about local HA, namely hierarchical schemes based on HMIPv6 such as [10,11]. In [10], a ProMAP entity is used to act as the same role of HMIPv6’s MAP, which accesses and manages the mobility profile for MNs in the administrative domain. The mobility profile contains the information on a MN’s mobility information (i.e. the average residence time in the current subnet) [11] presents a new method named Cross-over MAP-based Hierarchical Mobile IPv6 (XMAP-HMIPv6) which inherits the advantage of Hierarchical Mobile IPv6 of reducing signaling load for inter-domain mobility. While one approach to diminish the handover delay is to concentrate on the modifications of the ARs, another method is to modify the MNs. In [12], a Mobile Node (MN) extension employing a buffering function. The MN buffers the TCP Acks just before the handover, then the CN stops its transmission and begins L2 handoff. After the handoff the buffered TCP Acks are delivered to the CN and it resumes the transmission. In [13], the RAs only send when a handoff is necessary. The MN keeps a RA cache to help to decide where to handover. There are also some methods to reduce the handover delay resulting from Movement Detection (MD) and Duplicate Address Detection (DAD) such as optimistic Duplicate Address Detection [14], Router Advertisement Cashing in Access Point (AP) for Fast Router Discovery [15] and Advance Duplicate Address [16]. In [17], a more efficient fast Neighbor Discovery and DAD scheme is proposed. This approach requires each access point to execute movement detection by unicast transmission of the stored Router Advertisement message and implementation of a modified Neighbor Cache to handle care of address configuration with fast DAD. In flow-based fast handover for Mobile IPv6 (FFHMIPv6) [18,19], when the MN moves to a new subnet, it probes the crossover router (CR) – the first Router that is common to the path from its old CoA and new CoA to the HA. Every router maintains the state information of the flow it receives, sends or routes. A Flow is defined by the source and destination address and the Flow Label. The Hop-by-Hop frame including the old flow information is added to the BU register message heading for the HA. If the traffic flow is found, a temporary tunnel is established between the CR and the nCoA of the MN. Thus the traffic flow for the MN is redirected to the established tunnel, which is active for a time period (normally 6 s) sufficient enough for MN to complete its registration with its HA and all the CNs. Recently, many route optimization schemes have also been proposed to reduce the delay in handovers [10,20– 22]. In [10], a new hierarchical scheme is proposed that enables any CNs to send packets to a MN without helps
3871
of the intermediate mobility agent using a subnet residence time in the profile. In [20], handover operation is considered in macro mobility handover. This paper propose simultaneous processing for new address registration in the new network and forwarding the in-flight packet from the new access router to the Mobile Node (MN). This can be achieved by adopting the multicast scheme to the MAP. MAP multicasts the packet to new access router and forward the packet to the MN during handover. [21] proposes a unified route optimization scheme based on Path Control Header (PCH) piggybacking for network mobility. By taking the functional extension of routing facilities such as Home Agent, Mobile Router and Correspondent Router, it can dynamically incrementally optimize the routes over CN–HA–MR without the loss of transparency to Correspondent Node. In the adaptive local route optimization (ALRO) scheme [22], MN informs the CN of the MN’s LCoA if the packet delivery cost is more dominant than the binding update cost. Otherwise, the CN is aware of only the MN’s RCoA. Namely, the ALRO scheme minimizes either the packet delivery cost or the binding update cost depending on the session-to-mobility ratio (SMR) of each CN. In this paper, we proposed a new flow-based fast handover method for Mobile IPv6 with route optimization (NFFHMIPv6). It utilizes the CR to decide which route optimization method to be used. Through the usage of CR reasonablely, the BU message process and the packet delivery cost will be deduced. The rest of this paper is organized as follows. Section 2 reviews the existing FFHMIPv6 method. the NFFHMIPv6 method is proposed in Section 3. In Section 4, the analytical model is presented. Section 5 analyze the BU process, the handover delay of downstream and upstream flows compared of MIPv6, FFHMIPv6 and NFFHMIPv6 methods. Section 6 give the simulation process. Section 7 concludes this paper. 2. Flow-based fast handover for Mobile IPv6 In [18,19], the FFHMIPv6 method is proposed, which utilizes the features of IPv6 protocol and benefits from IPv6 traffic control. It requires every routers in the path between the MN and the HA to fill and maintain the flow state information of the traffic flows it receives, sends or routes. Packet classifiers use the triplet of Flow Label, Source Address and Destination Address fields to identify which flow a particular packet belongs to. When the MN moves to a new subnet, it obtains a new care-of address (NCoA) through stateless address autoconfiguration and register it to the HA and CNs via BU process. In FFHMIPv6, the Hop-by-Hop frame with a FHMIPv6 option is included in the BU message. At every router between the MN and HA, the flow state information is compared with the old flow information from the Hopby-Hop frame. If the two informations are corresponding
3872
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
to each other, namely the traffic flow is found, the router (i.e. cross-over router) sends ICMP message to the MN’s new CoA so that it knows the other end of the IPv6 tunnel. Then the IPv6 tunnel is established and the traffic flows is redirected to the tunnel. Next, the Flow path field in the Hop-by-Hop frame is set to one to indicate that the FFHMIPv6 process is performed and does not perform again. Finally, the BU message is forwarded to HA and the MIPv6 registration process continues. This FFMIPv6 method ensures that the traffic flow can be redirected to the new location through the tunnel, which is temporary and durationally constant (some seconds), during the registration process to both HA and CNs. After the registration is done, the traffic flow can be delivered to the new CoA of the MN directly without any tunnel. This makes it possible that the reception of packets can be done simultaneously with the BU registration process. The FFHMIPv6 method assumes that the CR can be found. If the CR cannot be found, the handover process is the same as MIPv6. When the MN moves from one subnet to another, there is a period of time during which it cannot receive and send, namely handover. In FFHMIPv6, there are some drawbacks that remains unsolved. Firstly, the route optimization is not used so all the flows from CNs are routed via HA. The FFHMIPv6 method is therefore used to redirect the flow from the HA to the new CoA. The handover delay is defined to be the time from the first BU register message to the time when the MN is able to receive the flow, which is redirected from the CR. Secondly, the upstream traffic handover delay is defined to be the time from the first BU register message to the time when the MN receives the Back message from the HA. This process may last a long time. Thirdly, since every time MN moves to a new subnet, it must register its new location to HA and CNs, the MN’s mobility is not transparent to the HA and CNs.
3. The new flow-based fast handover method for Mobile IPv6 with route optimization The new flow-based fast handover method is proposed based on the FFHMIPv6. It has enhanced the FFHMIPv6 to support route optimization. When the MN moves to a new subnet, it sends a BU message with the old flow state. At every router it utilizes the flow state to find the first common router on the path from HA to its oAR and its NAR. This first common router is named crossover route (i.e. CR). When the CR is found, the traffic flow can be redirected to the new location of the MN through the tunnel established between the CR and the MN. Simultaneously, CR can choose a scheme to perform the router optimization, which depends on the location of the CR. Next we concentrate on the more detailed modification which can make the new flow-based fast handover method (NFFHMIPv6) have a more better performance. 3.1. Requirements The NFFHMIPv6 requires a few modifications to the FFHMIPv6. Normally the Hop-by-Hop frame includes Option Type, Option Data Length and Option Data. In this paper, we modify the Hop-by-Hop header to support NFFHMIPv6. Fig. 1 shows the format of the NFFHMIPv6 option [19] and descripts the parameter of the NFFHMIPv6 option. The CN, HA and the MN must send the IPv6 packets with the same Flow Label so that the traffic flow can be identified correctly. The routers must be able to form the IPv6 tunnel and maintain state information of the traffic flow. To the CR, a especial requirement that must be taken into account to process the BU message is that it must have a BU cache. Also it is required that the HA must have a buffering table which maintains the map between the CoA of the MNs and the HA.
NFFHMIPv6 option:IPv6 Hop-by-Hop Options Header Option Type:00 0 xxxxx 00-skip over this option and continue processing the header 0-Option Data does not change en-route xxxxx=function identification(To be assigned by IANA) Option Data: HA
CN1
CN2
CNn
Old care-of addresses: 16bytes(oCoA) CN addresses:n*16bytes n:the number of the CNs HA,CN1-CNn:flow path field,if set to 1,means the RO and/or flow tunnel have been established Fig. 1. Hop-by-Hop frame with the FFHMIPv6 option.
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
3.2. Router’s functions At every router it maintains the flow state information and also a binding cache which maintains a binding information between AR and MN. When the MN moves to a new subnet, it sends a BU message to the HA. When the router receives the BU message, it will compare the flow state information with the old flow state information in Hop-by-Hop frame. If the CR is found, i.e., the flow state information matches each other very well, it will handle the receiving BU message. By comparing the oCoA’s prefix with the NCoA’s, the CR can be aware whether the MN moves within the same link or not. If the movement is within the same link, the CR will respond to the BU message by sending to the MN a Back message. Thus a tunnel can be established between the CR and the MN. This tunnel is exactly named RO tunnel. On the other hand, if the movement is not in the same link, but the CR is found, the CR will redirect the traffic flow through a temporary tunnel between the CR and the MN. If the MN receives the Back message from the CR, it means that the handover process has finished. 3.3. BU process and packet delivery The BU process to the NFFHMIPv6 method is quite depending on the network environment. In this paper, we analyze the BU process and packet delivery process under three topologies, which is shown in Fig. 2.
3873
the BU message. Here we take into account a special case, when the CN and the MN are crossed through the same CR. At this special case, the RO process is as follows. When the MN moves to a new link, it sends the BU message (MN, HA). The CR receives the BU message and respond a BACK message (MN, CR). At the same time, the CR forwards the BU message which is modified to map the CR and MN to the CN. When the CN receives the BU message, it sends a Back message (CN, MN) to the MN. Thus a RO tunnel is established between MN and CN. Then any packets from the CN to MN can be delivered directly. Fig. 3 shows the process in this case. 3.3.2. The MN moves from one link to another with a CR Under this environment, the BU process is performed as follows. When MN moves to a new link, it will register to HA. At the CR, it intercept the binding update message of the MN. According to the information of the BU message, it changes its route table and its BU cache to binding the CR to MN’s new CoA. Then the CR returns a Back message to the MN. When the MN receives the Back message, the MN updates its binding update list. Then the RO tunnel between CR and the NAR has been established. Packets from CN can be sent subsequently to the CR by using the old route table directly. And the CR forwards the CN
CR
MN BU(MN, HA) BACK(MN,CR) RO TUNNEL
3.3.1. The MN moves within the same link with a CR to be found In this case, the CR acts as a local HA. Its functions is very similar with the ProMAP, the MAP or the XMAP. When the MN moves to a new location in the same link, it sends a BU message with FFHMIPv6 option to the CR. At the cross point between the Path from the HA to the oCoA and the new Path from the HA to the nCoA, the router, namely crossover router, must handle the packet through it. After received the BU message, the CR sends to the MN a BACK message as response to
CN
Scenario 1
BU(MN,CR) BACK(CN,MN) RO TUNNEL Packet delivery
Fig. 3. Packet delivery in case 1.
Scenario 2
HA
CN
Scenario 3
CN
HA AR
HA
AR(CR)
PAR
AR(CR)
PAR
MN
MN
NAR
PAR
movement
movement
NAR
NAR
MN
MN
MN movement
Fig. 2. The analysis scenarios.
MN
3874
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 CR
MN
CN
BU(MN,HA) BACK(MN,CR) Packet delivery
RO TUNNEL Packet delivery
Fig. 4. Packet delivery in case 2. MN
CN
HA BU(MN,HA)
BU(MN,CN)
BACK(HA, MN)
BACK(CN, MN) RO TUNNEL Packet delivery
Fig. 5. Packet delivery in case 3.
receiving packets to the new location of MN through the RO tunnel. Fig. 4 shows the process in this case. 3.3.3. The MN moves from one link to another without finding the CR When the MN moves to a new sublink, it sends a BU message to HA. The HA register the binding update to its binding cache. As the response to the BU, HA sends a Back message to MN. After received the Back message, the MN knows that the CN has not register the nCoA, so it sends a BU message to CN. When the CN receives the BU message, it registers it in the binding cache and respond a Back message to MN, thus establishes a RO tunnel between the CN and the MN. Then any packet sending from the CN can be directly delivered to the MN. Fig. 5 shows the registration process. The BU process is very similar to the BU in MIPv6. 4. Total cost analytical 4.1. Analytical model To evaluate the performance of the NFFHMIPv6 method, an analytical cost model is developed. In the analytical model [22], we calculate the BU cost (CBU) and the packet delivery (PD) cost (CPD) from the CN to the MN. The total cost is the sum of the BU cost and the PD cost. The analytical model is described as follows.
session generation rate of the CN kS E(s) average session length (in numbers of packets) Lp packet length Bw band width in wired link Bwl band width in wireless link LBU (LBACK) BU message length (BACK message length) dAB hop distance between A and B g latency of the wired link s latency of the wireless link kf the arrival rate of first packet p the cell crossing rate E(T) the average cell residence time CCN–HA unit packet delivery cost from the CN to the HA Lp ¼ d CN–HA Bw þg CCN–CR unit packet delivery cost from the CN to the CR Lp ¼ d CN–CR Bw þg CHA–NAR unit packet delivery cost from the HA to the Lp new CoA of MN ¼ d HA–NAR Bw þg CCR–NAR unit packet delivery cost from the CR to the new Lp CoA of MN ¼ d CR–NAR Bw þg CCN–NAR unit packet delivery cost from the CN to NAR Lp without finding the CR ¼ d CN–NAR Bw þg BUNEW CR12 unit binding update cost to CR with CR to be BU found in NFFHMIPv6 ¼ d CR–NAR LBw þ L LBACK LBU BACK gÞ þ Bwl þ s þ d CR–NAR Bw þ g þ Bwl þ sÞ BUOLD CN unit binding update cost to the CN in FFHMIPv6 BU BU ¼ ðd HA–NAR þ d CN–HA Þ LBw þ g þ LBwl þ sþ LBACK LBACK ðd HA–NAR þ d CN–HA Þ Bw þ g þ Bwl þ sÞ BUOLD HA unit binding update cost to the HA in the same BU link in FFHMIPv6 ¼ d HA–NAR LBw þg þ LBACK LBACK LBU Bwl þ s þ d HA–NAR Bw þ g þ Bwl þ sÞ BUNEW HA3 unit binding update cost to CN without the CR BU BU ¼ d HA–NAR LBw þ g þ LBwl þ s þ d HA–NAR LBACK LBACK þ g þ þ sÞ Bw Bwl BUNEW unit binding update cost to CN without the CR CN3 LBU BU ¼ d CN–NAR Bw þ g þ LBwl þ s þ d CN–NAR LBACK LBACK Bw þ g þ Bwl þ sÞ the binding entry lifetime TBU In no route optimization (NRO) scheme (FFHMIPv6), there is no BU message to the CN, all BU messages are sent via HA. All packets sending from the CN must be routed to the HA and then HA forwards the packets to the MN in the NRO method. On the other hand, in our proposed new handover method, a route optimization method is used to improve the performance. The number of packets in a session is approximated to kS Æ E(s). In this paper, with the route optimization used, the cost must be analyzed depending on the different case scenarios mentioned above. Now we analyze the cost, respectively.
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
4.2. The signaling cost In FFHMIPv6 and NFFHMIPv6 methods, the registration process is shown in Table 1. As is shown in Table 1, the registration process in FFHMIPv6 must always be handled at HA and CN, which is same as the registration in Mobile IPv6, so the BU cost per a unit of cell residence time is shown as the following equation: 1 OLD p ðBUOLD C FFHMIPv6 ¼ HA þ BUCN þ PCHA þ PCCN Þ BU EðT Þ 1 LBU LBU p d HA–NAR þg þ þs ¼ EðT Þ Bw Bwl LBACK LBACK þ d HA–NAR þg þ þs Bw Bwl LBU LBU þg þ þ ðd HA–NAR þ d CN–HA Þ Bw Bwl LBACK þg þ s þ ðd HA–NAR þ d CN–HA Þ Bw LBACK þ þ s þ PCHA þ PCCN ð1Þ Bwl In typical MIPv6, the BU cost can be obtained by the following equation: 1 MIPm6 p ðBUHA þ BUCN þ RR þ PCHA þ PCCN Þ C BU ¼ EðT Þ 1 LBU LBU þg þ p d HA–NAR ¼ Bw Bwl EðT Þ LBACK LBACK þg þ þs þ s þ d HA–NAR Bw Bwl LBU LBU þg þ þs þ d CN–HA Bw Bwl LBACK LBACK þg þ þs þ d CN– HA Bw Bwl þ Maxfd HA–NARþ d CN–HA ; d CN–NAR g g þ s
3875
4.2.2. The MN moves from one subnet to another without finding the CR In this case, the MN must register its location to HA and the Corresponding CN. The BU cost can be obtained by 1 NEW p BUNEW HA3 þ BUCN3 þ RR þ PCHA þ PCCN EðT Þ 1 LBU LBU þg þ p d HA–NAR ¼ Bw Bwl EðT Þ LBACK LBACK þ s þ d HA–NAR þg þ Bw Bwl LBU LBU þ s þ d CN–NAR þg þ Bw Bwl LBACK LBACK þg þ þ s þ d CN–NAR Bw Bwl
C NFFHMIPv6 ¼ BU 3
þ s þ Maxfd HA–NAR þ d CN–HA ; d CN–NAR g g þ2s þ rCN þ PCHA þ PCCN
ð4Þ
4.3. The packet delivery cost During the BU process, the packets is forwarded to the new location of MN through the CR using a route optimization method, while in FFHMIPv6 the packets are all forwarded to the CR via HA. On the other hand, if the CR cannot be found, the packet delivery process is the same as it in MIPv6, while in FFHMIPv6 packets sent from CN must be forwarded via HA. The total packet delivery cost in FFHMIPv6 and NFFHMIPv6 method can be calculated by Eq. (4). (Here CHA, CR denote the handling cost at HA and CR, CT denotes the transmission cost from CNs to MNs.)
ð2Þ
þPCHA þ PCCN
C FFHMIPv6 ¼ C FFHMIPv6 þ C FFHMIPv6 þ C FFHMIPv6 PD HA CR T 4.2.1. The MN moves with a CR to be found In this case, the MN need not register its BU message to the HA, and only need to register to the CR. The BU cost can be calculated as the following equation: 1 C NFFHMIPv6 p ðBUNEW ¼ CR12 þ PCCR Þ BU12 EðT Þ 1 LBU LBU p d CR–NAR þg þ ¼ EðT Þ Bw Bwl LBACK LBACK þg þ þ s þ d CR–NAR Bw Bwl þ s þ PCCR
ð3Þ
C NFFHMIPv6 ¼ C NFFHMIPv6 þ C NFFHMIPv6 þ C NFFHMIPv6 PD HA CR T C MIPv6 PD
¼
C MIPv6 HA
þ
ð5Þ
C MIPv6 T
We assume that hHA denotes a packet processing cost at the HA, which is a constant. In FFHMIPv6, all packets sent from CNs to MNs must be forwarded by HA. On the other hand, in NFFHMIPv6, only the first packet in a session must be forwarded via HA. So CHA in the two method can be obtained by C FFHMIPv6 ¼ kS EðsÞ hHA HA
ð6Þ
C NFFHMIPv6 ¼ C MIPv6 ¼ kf hHA HA HA
Table 1 Registration process Method
Scenario 1
Scenario 2
Scenario 3
BU
BU process
BU
BU process
BU
BU process
FFHMIPv6
CN + HA
BU fi HA + BU fi CN
HA + CN
BU fi HA + BU fi CN
HA + CN
BU fi HA + BU fi CN
NFFHMIPv6
CR
BU fi CR
CR + HA + CN
BU fi HA + BU fi CN + BU fi CR
HA + CN
BU fi HA + BU fi CN
3876
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
In NFFHMIPv6, when the packets sent from CNS pass by CR, it will look up its mapping tables to translate between CR and NcoA. So the lookup time required for the mapping table must be considered. After that, the packet is routed to the MN. So the processing cost at the CR is consisted of look-up cost and routing cost. Clookup is proportional to the size of mapping table, which is proportional to the number of MNs that having the tunnel to it. Crouting is proportional to the logarithm of the number of ARs linking to a CR. Here we assume that NAR denotes the number of ARs, NMN denotes the number of MNs, which is proportional to the number of ARs. If the number of MNs in a AR area is K, then the total number of MNs can be obtained by N MN ¼ N AR K ð7Þ Therefore, the processing cost at the CR is expressed by Eq. (8), where n and d denote the weight factors. C FFHMIPv6 ¼ kS EðsÞ n N MN CR ¼ kS EðsÞ n N AR K C NFFHMIPv6 CR
ð8Þ
¼ kS EðsÞ ðC lookup þ C routing Þ ¼ kS EðsÞ ðn N MN þ d logðN AR ÞÞ ¼ kS EðsÞ ðn N AR K þ d logðN AR ÞÞ
In BU process, the packets can be delivered to the new location of MNs through the CR. Because in FFHMIPv6 method, route optimization is not supported, so every packet sent from CNs must be forwarded via HA. In NFFHMIPv6, packets can be sent to MNs’ new location directly because of route optimization. So the transmission cost can be calculated by the following equation: C FFHMIPv6 ¼ kS EðsÞ ðC CN–HA þ C HA–CR þ C CR–NAR T Lp þ þs Bwl ¼ kS EðsÞ ððd CN–HA þ d HA–CR þ d CR–NAR Þ Lp Lp þg þ þs ð9Þ Bw Bwl ¼ kf ðC CN–HA þ C HA–CR Þ þ ðkS kf Þ ðLs 1Þ C NFFHMIPv6 T Lp C CN–CR þ kS Ls C CR–NAR þ þs Bwl Lp þg ¼ kf ðd CN–HA þ d HA–CR Þ Bw Lp þg þ ðkS kf Þ ðLs 1Þ d CN–CR Bw Lp Lp þg þ þs þ kS Ls d CR–NAR Bw Bwl C MIPv6 ¼ k ðC þ C Þ þ ðk k Þ ðEðsÞ 1Þ f CN–HA HA–NAR S T f Lp C CN–NAR þ kS EðsÞ þs Bwl Lp þ g þ ðkS kf Þ ¼ kf ðd CN–HA þ d HA–NAR Þ Bw Lp þg ðEðsÞ 1Þ d CN–NAR Bw Lp þs þ kS EðsÞ Bwl
4.4. Session disrupt time In FFHMIPv6 and NFFHMIPv6, the packets sent from CNs can be redirected to the new location of MNs simulateously with the BU process. When taken into account the upstream packets, in FFHMIPv6 and MIPv6, it can be obtained by CNs until the BU to the HA and CN can be finished. But in NFFHMIPv6, when the CR is found, the packets sent from MNs can be tunneled to CR and then forwared to CNs by the old path recorded in the route table. So the session disrupt time in case of upstream and downstream can be obtained by (here TL denotes the L2 handover time, TI denotes the IP connectivity time): LBU down þ g þ d CR–NAR g T FFHMIPv6 ¼ T L þ T I þ d CR–NAR Bw LBU þ2s þ Bwl OLD OLD T up FFHMIPv6 ¼ T L þ T I þ BUHA þ BUCN LBU LBU þg þ ¼ T L þ T I þ d HA–NAR Bw Bwl LBACK LBACK þg þ þ s þ d HA–NAR Bw Bwl LBU þ s þ ðd HA–NAR þ d CN–HA Þ þg Bw LBU þ þ s þ ðd HA–NAR þ d CN–HA Þ Bwl LBACK LBACK þg þ þs Bw Bwl up T down NFFHMIPv6 ¼ T NFFHMIPv6
ð10Þ
LBU þ g þ d CR–NAR ¼ T L þ T I þ d CR–NAR Bw LBACK LBU LBACK þg þ þ þ2s Bw Bwl Bwl
up T down MIPv6 ¼ T MIPv6
LBU LBU þg þ þs ¼ T L þ T I þ d HA–NAR Bw Bwl LBACK LBACK þ d HA–NAR þg þ þs Bw Bwl LBU LBU þ d CN–NAR þg þ þ s þ d CN–NAR Bw Bwl LBACK LBACK þg þ þs Bw Bwl
5. Numerical results In order to analyze the performance of the proposed fast handover method, we consider some of the system parameters as constants, which are shown in Table 2. The parameter values for the analysis were referenced from [23,24]. In
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
3877
Table 2 Parameter values for numerical analysis kS
E(s)
Lp
dCN–HA
TL + TI
LBU
LBACK
g
s
kf
dHA–CR
Bwl
0.1
10
1500
6
165
112
96
1
2
0.02
6
11M
dCN–CR
dHA–NAR
dCR–NAR
dCN–NAR
n
d
hHA
PCHA
PCCN
PCCR
Bw
4
8
3
8
0.1
0.2
20
24
6
6
100M
this paper, we discuss the impact of average residence time and the rate of MN’s movement to Signaling Cost. We also analyze the impact of the MNs to the packet delivery cost.
100
Signaling cost
80
5.1. The impact of user’s mobility If the cell residence time is large, it means that the MN is most likely to remain in a cell and seldom moves to other location, so the signaling cost is very small. So the signaling cost is inversely proportional to the average residence time, which is shown in Fig. 6. Here p is set to 1, Bw is set to 100 Mbps, Bwl is set to 11 Mbps, respectively. On the other hand, if the MN moves frequently, the BU cost will increase accordingly. So the BU cost is proportional to the rate of MN’s movement. Fig. 7 shows the relationship of MN’s mobility rate and BU cost. 5.2. The impact of user population In this paper, when packets passing by the CR, it will look up the mapping table to find the NAR tunneling the packets, and also it will find the route path. So the handling cost at the CR is logarithm to the number of ARs and proportional to the number of MNs. In Fig. 8, the impact of the user population to packet delivery cost is shown. (Here we only consider the case when the CR can be found.) When the CR cannot be found, the packet delivery costs of the three methods are equal. 5.3. Delay time In this paper, based on the FFHMIPv6 method, we proposed a new flow-based fast handover method which sup-
60 50 40 20 10 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fig. 7. The impact of user mobility (E(T) = 1).
port route optimization. So the packets sent from the CNs can be redirected to the MNs by the tunnel ahead of time, which is equal to that of FFHMIPv6. When taken into account the upstream packets, in FFHMIPv6, the MNs cannot send packets until the BU process to HA and CN is finished. But in our proposed NFFHMIPv6, if the CR can be found, the BU process is only to CR, so the BU process is shorter than that of FFHMIPv6 and MIPv6 methods. The numerical results considering that the CR can be found are shown in Fig. 9. If the CR cannot be found, when MNs move to a new link, they will register its new location to its HA and its corresponding CNs. So in this case, the downstream and upstream delay time are the same as that in MIPv6. Because no route optimization is supported in FFHMIPv6, so the BU process to the CN must be forwarded via HA, which results in larger BU cost than that of NFFHMIPv6 and MIPv6. Fig. 10 shows the results.
60
80
Signaling cost
70
FFHMIPv6 MIPv6 NFFHMIPv6
90
FFHMIPv6 MIPv6 NFFHMIPv6
50 40 30
70 60 50 40 30
20
20
10
10 1
2
3
4
5
6
7
average residence time(sec) (a)in case of CR to be found
8
9
10
1
the rate of user mobility
100
80
Signaling Cost
70
30
90
0
FFHMIPv6 MIPv6 NFFHMIPv6(CR) NFFHMIPv6(no CR)
90
0
1
2
3
4
5
6
7
8
average residence time(sec) (b) in case of no CR
Fig. 6. The impact of average residence time to signaling cost.
9
10
3878
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 80
80 FFHMIPv6 MIPv6 NFFHMIPv6
60 50 40 30 20
60 50 40 30 20 10
10 0
FFHMIPv6 MIPv6 NFFHMIPv6
70 Packet delivery cost
Packet delivery cost
70
0 1
2
3
4 5 6 7 8 number of MNs in a cell (a)the number of AR is 7
9
10
7
14
21
28 35 42 49 56 number of ARs (b)number of MNs is 2 in a cell
63
70
Fig. 8. The impact of user population.
270 FFHMIPv6 MIPv6 NFFHMIPv6
downstream delay time(ms)
240 210 180 150 120 90 60 30
FFHMIPv6 MIPv6 NFFHMIPv6
240
upstream delay time(ms)
270
210 180 150 120 90 60 30
0
0 the case with CR
the case with CR
Fig. 9. The delay time in case that the CR can be found.
300
FFHMIPv6 MIPv6 NFFHMIPv6
down/up stream delay time
270 240 210 180 150 120 90 60 30 0
the case without CR
Fig. 10. The delay time in case without CR.
6. Simulative studies We have used NS-2.31 [25] to simulate our proposed fast handover method. In order to support Mobile IPv6, we added the FHMIP1.3.1 extension [26], which is provided by SeaSon. The simulations required the implementations of FFHMIPv6 and NFFHMIPv6 and some necessary modifications to the ns-2 and FHMIP1.3.1. The NFFHMIPv6 implementation required some modifications to the FHMIP1.3.1 code, especially to the MHAgent, the MIPv6 header and classifiers. We implemented flow cache to every node, thus all nodes cache the traffic
flows it sends, receives or routes. MHAgent adds the FFHMIPv6 option in its Hop-by-Hop header to the first BU message after obained a new CoA. At every node on the way to HA the FFHMIPv6 information in the first BU message is compared to that of flow cache of the node. If the specified flow is found, a tunnel is created to the new CoA and the flow is redirected to the new location. Then the BU process continues. The simulation scenario with all of the participating entities and links is described in Fig. 11. The scenario consists of two 2 Mbps Wireless LAN 802.11 Distributed Coordination Function (DCF) accordant base stations (BSs). All BSs are connected to a different ARs and thus represent different IP subnet. The BSs are connected via two routers (R1 and R2) and duplex links to the border router (BR), which act as ingress and egress point to outer network. The HA and the CN are located in the outer network. In the scenario, the base stations are at the horizontal positions, the movement area is 1000 · 1000 m2 and the BSs cover the whole area. The transmission range of the BSs with omni-directional antennas is about 250 m and the minimum distance between the BSs is 350 m. During the handover CN sends TCP-based FTP traffic to the MN. The size of crowd window is 32, the packet size is 512. The MN, originally situated in PAR area, moves at a constant speed of 10 m/s towards NAR. The simulation result is shown in Fig. 12, which compare with the
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
CN 100MB
HA 100MB
/2ms BR /2ms 10MB 10MB/50msCR 10MB /2ms /2ms R1 1000KB /2ms PAR
R2 1000KB /2ms NAR
MN Fig. 11. Simulation scenario.
Fig. 12. Simulation result.
NFFHMIPv6 and FFHMIPv6. The result shows that the NFFHMIPv6 has the better delay performance. 7. Conclusions In this paper, we present a new flow-based fast handover method for Mobile IPv6 network with route optimization.The NFFHMIPv6 method is theoretically compared with the FFHMIPv6 method. The simulation result show that the NFFHMIPv6 have a shorter handover time compared with the FFHMIPv6 method. References [1] D.B. Johnson, C. Perkins, J. Arkko, Mobility support in IPv6, RFC 3775, June 2003. [2] R. koodli, Fast handover for Mobile IPv6, IETF draft, work in progress, 2003. [3] H. Soliman, C. Castelluccia, K. El-malki, L. Bellier, Hierarchical Mobile IPv6 mobility management(HMIPv6), IETF draft (work in progress), draft-ietf-mobileip-hmipv6-08.txt, June 2003. [4] C. Castelluccia, HMIPv6: a hierarchical Mobile IPv6 proposal, ACM Mobile Computing and Communications Review 4 (1) (2000) 48–59. [5] Hee Young Jung, Eun Ahkim, Jong Wha Yi, Hyeong Ho Lee, A scheme for supporting fast handover in hierarchical Mobile IPv6 networks, ETRI Journal 27 (6) (2005) 798–801.
3879
[6] V.L.L. Thing, H.C.J. Lee, Y. Xu, Performance evaluation of hop-byhop local mobility agents probing for Mobile IPv6, in: Proceedings of the Eighth IEEE International Symposium on Computers and Communications 2003 (ISCC 2003), June 30–July 3 2003, pp. 576– 581. [7] V.L.L. Thing, H.C. Lee, Y. Xu, Hop-by-hop local mobility agents probing for Mobile IPv6, IETF Internet Draft version1 (work in progress), October 2002. [8] V.L.L. Thing, H.C. Lee, Y. Xu, Designs and analysis of local mobility agents discovery, selection and failure detection from Mobile IPv6, in: IEEE Conference on Mobile and Wireless Communications Networks, 2002. [9] C. Williams, Localized mobility management Requirements, IETF Internet Draft version2 (work in progress), June 2002. [10] S.-H. Hwang, B.-K. Lee, Y.-H. Han, C.-S. Hwang, An adaptive hierarchical vehicular technology conference 2003 (VTC 2003Spring), vol. 3. 22–25 April, 2003, pp. 1502–1506. [11] A.K.M. Mahtab Hossain, Kanchana Kanchanasut, A handover management scheme for Mobile IPv6, in: The 14th International Conference on Computer Communications and Networks ( ICCCN 2005), 17–19 October 2005, pp. 43–48. [12] K. Omae, T. Ikeda, M. Inoue, I. Okajima, N. Umeda, Mobile node extension employing buffering function to improve handoff performance, in: The 5th International Symposium on Wireless Personal Multimedia Communications 2002, vol. 1, 27–30 October 2002, pp. 62–66. [13] L. Patanapongpibul, G. Mapp, A client-based handoff mechanism for Mobile IPv6 wireless networks, in: Proceedings of the Eighth IEEE International Symposium on Computers and Communication 2003 (ISCC 2003), 30 June–3 July 2003, pp. 563–568. [14] N. Moore, Optimistic duplicate address detection, draft-ietf-ipv6optimistic-dad-05.txt, February 2005. [15] J. Choi, Dong Yun Shin, Fast router discovery with RA, draftjinchoi-mobileip-frd-00.txt, June 2002. [16] Y. Han, Y. Choi, S. Park, Advance duplicate address detection, drafthan-mobileip-adad-00.txt, February 2003. [17] B. Park, S. Lee, H. Latchman, A fast neighbor discovery and dad scheme for fast handover in Mobile IPv6 networks, ICNICONSMCL’06. [18] M. Sulander, T. Hamalainen, A. Viinikainen, J. Puttonen, Flowbased fast handover method for Mobile IPv6 network, in: Proceeding of the 59th IEEE Semiannual Vehicular Technology Conference (VTC’S04), May 2004. [19] Jani Puttonen, Ari Viinikainen, M. Sulander, T. Hamalainen, Performance evaluation of the flow-based fast handover method for Mobile IPv6 Network, in: Proceedings of the 60th Semiannual IEEE Vehicular Technology Conference(VTC’F04), September 2004. [20] Vivaldi, B.M. Ali, H. Habaebi, V. Prakash, A. Sali, Routing scheme for macro mobility handover in hierarchical Mobile IPv6 network, in: Proceedings of the 4th National Conference on Telecommunication Technology 2003 (NCTT 2003), 14–15 January 2003, pp. 88–92. [21] J. Na, J. Choi, S. Cho, A unified Route optimization Scheme for Network Mobility,.
3880
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 Chen Jin was born in 1976. She is a Post graduate student of Jiangnan University in China. She is interested in the researching fields such as Mobile IPv6 and embedded system.
Zhang Xi-Huang was born in 1962. He is an associate professor and his researching works include wireless networks and embedded system.
Computer Communications 30 (2007) 3870–3880 www.elsevier.com/locate/comcom
A new flow-based fast handover method for Mobile IPv6 network with route optimization Chen Jin *, Zhang Xi-Huang College of Information Engineering, Jiangnan University, Wuxi 214122, China Received 9 November 2006; received in revised form 2 October 2007; accepted 2 October 2007 Available online 13 October 2007
Abstract Flow-based fast handover method is designed for Mobile IPv6 network. The FFHMIPv6 uses the flow state information to redirect the traffic flow to a new location. This makes it possible that the reception of packets simultaneously with the BU registration process, thus minimizing the delay experienced in the handover. But it does not consider the route optimization. In this paper, a new flow-based fast handover method is proposed which enhanced the existing flow-based fast handover method to support route optimization. The analysis shows that this scheme has a better performance than the existing FFHMIPv6 scheme. 2007 Elsevier B.V. All rights reserved. Keywords: Mobile IPv6; Fast handover; FFHMIPv6; Route optimization
1. Introduction Mobile IPv6 [1] enables a Mobile Node to maintain its connectivity to the Internet when moving from one access router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This ‘‘handover latency’’ resulting from standard Mobile IPv6 procedures, namely movement detection, new care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as voice over producing the handover latency could be beneficial to non-real-time, throughput-sensitive application as well [2]. In [2], the improved idea of Mobile IPv6 [1] is presented to minimize the handover latency in Mobile IPv6 networks. This proposal utilizes the L2 trigger to obtain the new CoA at the new Router in advance and then establishes a bidirectional tunnel between the oAR and the NAR, so that it can minimize the packet loss, handover delay and the ser-
*
Corresponding author. Tel.: +86 510 85912448. E-mail address: [email protected] (C. Jin).
0140-3664/$ - see front matter 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2007.10.008
vice disruption during the handover. In [3,4], a Hierarchical Mobile IPv6 (HMIPv6) proposal presents a new entity named Mobile Anchor Point (MAP) to act as a local HA to reduce the signaling delays during handover. The single combination of Fast and Hierarchical Mobile IPv6 ([F+H]MIPv6) [3] tries to incorporate the advantages of FMIPv6 and HMIPv6 together. Based on [2–4], the enhanced fast handover HMIPv6 (F-HMIPv6) scheme [5] is presented. In this paper, the tunnel for a handover is established between the MAP and NAR, and the MN exchanges the signaling messages for the handover with MAP. F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages [5]. However, the handover delay still remains unacceptable for some applications. In the past few years, many different proposals have been presented. Some of the proposed method is router-assisted. They require modifications for functional extension of the ARs. Several slightly different handover solutions using local mobility has been proposed in [6–8], which is proposed as an extension to MIPv6 for Localized Mobility Management (LMM) [9]. They utilize a Local Mobility Agent (LMA) located in the visited domain to act as a local HA. When the MN changes its point of attachment within the
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
LMM domain, it only informs to the LMA, whereas its globally perceived IP address remains unchanged. This diminishes signaling for re-registration with HA and CNs, thus reduces the handover latency. There are many similar ideas about local HA, namely hierarchical schemes based on HMIPv6 such as [10,11]. In [10], a ProMAP entity is used to act as the same role of HMIPv6’s MAP, which accesses and manages the mobility profile for MNs in the administrative domain. The mobility profile contains the information on a MN’s mobility information (i.e. the average residence time in the current subnet) [11] presents a new method named Cross-over MAP-based Hierarchical Mobile IPv6 (XMAP-HMIPv6) which inherits the advantage of Hierarchical Mobile IPv6 of reducing signaling load for inter-domain mobility. While one approach to diminish the handover delay is to concentrate on the modifications of the ARs, another method is to modify the MNs. In [12], a Mobile Node (MN) extension employing a buffering function. The MN buffers the TCP Acks just before the handover, then the CN stops its transmission and begins L2 handoff. After the handoff the buffered TCP Acks are delivered to the CN and it resumes the transmission. In [13], the RAs only send when a handoff is necessary. The MN keeps a RA cache to help to decide where to handover. There are also some methods to reduce the handover delay resulting from Movement Detection (MD) and Duplicate Address Detection (DAD) such as optimistic Duplicate Address Detection [14], Router Advertisement Cashing in Access Point (AP) for Fast Router Discovery [15] and Advance Duplicate Address [16]. In [17], a more efficient fast Neighbor Discovery and DAD scheme is proposed. This approach requires each access point to execute movement detection by unicast transmission of the stored Router Advertisement message and implementation of a modified Neighbor Cache to handle care of address configuration with fast DAD. In flow-based fast handover for Mobile IPv6 (FFHMIPv6) [18,19], when the MN moves to a new subnet, it probes the crossover router (CR) – the first Router that is common to the path from its old CoA and new CoA to the HA. Every router maintains the state information of the flow it receives, sends or routes. A Flow is defined by the source and destination address and the Flow Label. The Hop-by-Hop frame including the old flow information is added to the BU register message heading for the HA. If the traffic flow is found, a temporary tunnel is established between the CR and the nCoA of the MN. Thus the traffic flow for the MN is redirected to the established tunnel, which is active for a time period (normally 6 s) sufficient enough for MN to complete its registration with its HA and all the CNs. Recently, many route optimization schemes have also been proposed to reduce the delay in handovers [10,20– 22]. In [10], a new hierarchical scheme is proposed that enables any CNs to send packets to a MN without helps
3871
of the intermediate mobility agent using a subnet residence time in the profile. In [20], handover operation is considered in macro mobility handover. This paper propose simultaneous processing for new address registration in the new network and forwarding the in-flight packet from the new access router to the Mobile Node (MN). This can be achieved by adopting the multicast scheme to the MAP. MAP multicasts the packet to new access router and forward the packet to the MN during handover. [21] proposes a unified route optimization scheme based on Path Control Header (PCH) piggybacking for network mobility. By taking the functional extension of routing facilities such as Home Agent, Mobile Router and Correspondent Router, it can dynamically incrementally optimize the routes over CN–HA–MR without the loss of transparency to Correspondent Node. In the adaptive local route optimization (ALRO) scheme [22], MN informs the CN of the MN’s LCoA if the packet delivery cost is more dominant than the binding update cost. Otherwise, the CN is aware of only the MN’s RCoA. Namely, the ALRO scheme minimizes either the packet delivery cost or the binding update cost depending on the session-to-mobility ratio (SMR) of each CN. In this paper, we proposed a new flow-based fast handover method for Mobile IPv6 with route optimization (NFFHMIPv6). It utilizes the CR to decide which route optimization method to be used. Through the usage of CR reasonablely, the BU message process and the packet delivery cost will be deduced. The rest of this paper is organized as follows. Section 2 reviews the existing FFHMIPv6 method. the NFFHMIPv6 method is proposed in Section 3. In Section 4, the analytical model is presented. Section 5 analyze the BU process, the handover delay of downstream and upstream flows compared of MIPv6, FFHMIPv6 and NFFHMIPv6 methods. Section 6 give the simulation process. Section 7 concludes this paper. 2. Flow-based fast handover for Mobile IPv6 In [18,19], the FFHMIPv6 method is proposed, which utilizes the features of IPv6 protocol and benefits from IPv6 traffic control. It requires every routers in the path between the MN and the HA to fill and maintain the flow state information of the traffic flows it receives, sends or routes. Packet classifiers use the triplet of Flow Label, Source Address and Destination Address fields to identify which flow a particular packet belongs to. When the MN moves to a new subnet, it obtains a new care-of address (NCoA) through stateless address autoconfiguration and register it to the HA and CNs via BU process. In FFHMIPv6, the Hop-by-Hop frame with a FHMIPv6 option is included in the BU message. At every router between the MN and HA, the flow state information is compared with the old flow information from the Hopby-Hop frame. If the two informations are corresponding
3872
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
to each other, namely the traffic flow is found, the router (i.e. cross-over router) sends ICMP message to the MN’s new CoA so that it knows the other end of the IPv6 tunnel. Then the IPv6 tunnel is established and the traffic flows is redirected to the tunnel. Next, the Flow path field in the Hop-by-Hop frame is set to one to indicate that the FFHMIPv6 process is performed and does not perform again. Finally, the BU message is forwarded to HA and the MIPv6 registration process continues. This FFMIPv6 method ensures that the traffic flow can be redirected to the new location through the tunnel, which is temporary and durationally constant (some seconds), during the registration process to both HA and CNs. After the registration is done, the traffic flow can be delivered to the new CoA of the MN directly without any tunnel. This makes it possible that the reception of packets can be done simultaneously with the BU registration process. The FFHMIPv6 method assumes that the CR can be found. If the CR cannot be found, the handover process is the same as MIPv6. When the MN moves from one subnet to another, there is a period of time during which it cannot receive and send, namely handover. In FFHMIPv6, there are some drawbacks that remains unsolved. Firstly, the route optimization is not used so all the flows from CNs are routed via HA. The FFHMIPv6 method is therefore used to redirect the flow from the HA to the new CoA. The handover delay is defined to be the time from the first BU register message to the time when the MN is able to receive the flow, which is redirected from the CR. Secondly, the upstream traffic handover delay is defined to be the time from the first BU register message to the time when the MN receives the Back message from the HA. This process may last a long time. Thirdly, since every time MN moves to a new subnet, it must register its new location to HA and CNs, the MN’s mobility is not transparent to the HA and CNs.
3. The new flow-based fast handover method for Mobile IPv6 with route optimization The new flow-based fast handover method is proposed based on the FFHMIPv6. It has enhanced the FFHMIPv6 to support route optimization. When the MN moves to a new subnet, it sends a BU message with the old flow state. At every router it utilizes the flow state to find the first common router on the path from HA to its oAR and its NAR. This first common router is named crossover route (i.e. CR). When the CR is found, the traffic flow can be redirected to the new location of the MN through the tunnel established between the CR and the MN. Simultaneously, CR can choose a scheme to perform the router optimization, which depends on the location of the CR. Next we concentrate on the more detailed modification which can make the new flow-based fast handover method (NFFHMIPv6) have a more better performance. 3.1. Requirements The NFFHMIPv6 requires a few modifications to the FFHMIPv6. Normally the Hop-by-Hop frame includes Option Type, Option Data Length and Option Data. In this paper, we modify the Hop-by-Hop header to support NFFHMIPv6. Fig. 1 shows the format of the NFFHMIPv6 option [19] and descripts the parameter of the NFFHMIPv6 option. The CN, HA and the MN must send the IPv6 packets with the same Flow Label so that the traffic flow can be identified correctly. The routers must be able to form the IPv6 tunnel and maintain state information of the traffic flow. To the CR, a especial requirement that must be taken into account to process the BU message is that it must have a BU cache. Also it is required that the HA must have a buffering table which maintains the map between the CoA of the MNs and the HA.
NFFHMIPv6 option:IPv6 Hop-by-Hop Options Header Option Type:00 0 xxxxx 00-skip over this option and continue processing the header 0-Option Data does not change en-route xxxxx=function identification(To be assigned by IANA) Option Data: HA
CN1
CN2
CNn
Old care-of addresses: 16bytes(oCoA) CN addresses:n*16bytes n:the number of the CNs HA,CN1-CNn:flow path field,if set to 1,means the RO and/or flow tunnel have been established Fig. 1. Hop-by-Hop frame with the FFHMIPv6 option.
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
3.2. Router’s functions At every router it maintains the flow state information and also a binding cache which maintains a binding information between AR and MN. When the MN moves to a new subnet, it sends a BU message to the HA. When the router receives the BU message, it will compare the flow state information with the old flow state information in Hop-by-Hop frame. If the CR is found, i.e., the flow state information matches each other very well, it will handle the receiving BU message. By comparing the oCoA’s prefix with the NCoA’s, the CR can be aware whether the MN moves within the same link or not. If the movement is within the same link, the CR will respond to the BU message by sending to the MN a Back message. Thus a tunnel can be established between the CR and the MN. This tunnel is exactly named RO tunnel. On the other hand, if the movement is not in the same link, but the CR is found, the CR will redirect the traffic flow through a temporary tunnel between the CR and the MN. If the MN receives the Back message from the CR, it means that the handover process has finished. 3.3. BU process and packet delivery The BU process to the NFFHMIPv6 method is quite depending on the network environment. In this paper, we analyze the BU process and packet delivery process under three topologies, which is shown in Fig. 2.
3873
the BU message. Here we take into account a special case, when the CN and the MN are crossed through the same CR. At this special case, the RO process is as follows. When the MN moves to a new link, it sends the BU message (MN, HA). The CR receives the BU message and respond a BACK message (MN, CR). At the same time, the CR forwards the BU message which is modified to map the CR and MN to the CN. When the CN receives the BU message, it sends a Back message (CN, MN) to the MN. Thus a RO tunnel is established between MN and CN. Then any packets from the CN to MN can be delivered directly. Fig. 3 shows the process in this case. 3.3.2. The MN moves from one link to another with a CR Under this environment, the BU process is performed as follows. When MN moves to a new link, it will register to HA. At the CR, it intercept the binding update message of the MN. According to the information of the BU message, it changes its route table and its BU cache to binding the CR to MN’s new CoA. Then the CR returns a Back message to the MN. When the MN receives the Back message, the MN updates its binding update list. Then the RO tunnel between CR and the NAR has been established. Packets from CN can be sent subsequently to the CR by using the old route table directly. And the CR forwards the CN
CR
MN BU(MN, HA) BACK(MN,CR) RO TUNNEL
3.3.1. The MN moves within the same link with a CR to be found In this case, the CR acts as a local HA. Its functions is very similar with the ProMAP, the MAP or the XMAP. When the MN moves to a new location in the same link, it sends a BU message with FFHMIPv6 option to the CR. At the cross point between the Path from the HA to the oCoA and the new Path from the HA to the nCoA, the router, namely crossover router, must handle the packet through it. After received the BU message, the CR sends to the MN a BACK message as response to
CN
Scenario 1
BU(MN,CR) BACK(CN,MN) RO TUNNEL Packet delivery
Fig. 3. Packet delivery in case 1.
Scenario 2
HA
CN
Scenario 3
CN
HA AR
HA
AR(CR)
PAR
AR(CR)
PAR
MN
MN
NAR
PAR
movement
movement
NAR
NAR
MN
MN
MN movement
Fig. 2. The analysis scenarios.
MN
3874
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 CR
MN
CN
BU(MN,HA) BACK(MN,CR) Packet delivery
RO TUNNEL Packet delivery
Fig. 4. Packet delivery in case 2. MN
CN
HA BU(MN,HA)
BU(MN,CN)
BACK(HA, MN)
BACK(CN, MN) RO TUNNEL Packet delivery
Fig. 5. Packet delivery in case 3.
receiving packets to the new location of MN through the RO tunnel. Fig. 4 shows the process in this case. 3.3.3. The MN moves from one link to another without finding the CR When the MN moves to a new sublink, it sends a BU message to HA. The HA register the binding update to its binding cache. As the response to the BU, HA sends a Back message to MN. After received the Back message, the MN knows that the CN has not register the nCoA, so it sends a BU message to CN. When the CN receives the BU message, it registers it in the binding cache and respond a Back message to MN, thus establishes a RO tunnel between the CN and the MN. Then any packet sending from the CN can be directly delivered to the MN. Fig. 5 shows the registration process. The BU process is very similar to the BU in MIPv6. 4. Total cost analytical 4.1. Analytical model To evaluate the performance of the NFFHMIPv6 method, an analytical cost model is developed. In the analytical model [22], we calculate the BU cost (CBU) and the packet delivery (PD) cost (CPD) from the CN to the MN. The total cost is the sum of the BU cost and the PD cost. The analytical model is described as follows.
session generation rate of the CN kS E(s) average session length (in numbers of packets) Lp packet length Bw band width in wired link Bwl band width in wireless link LBU (LBACK) BU message length (BACK message length) dAB hop distance between A and B g latency of the wired link s latency of the wireless link kf the arrival rate of first packet p the cell crossing rate E(T) the average cell residence time CCN–HA unit packet delivery cost from the CN to the HA Lp ¼ d CN–HA Bw þg CCN–CR unit packet delivery cost from the CN to the CR Lp ¼ d CN–CR Bw þg CHA–NAR unit packet delivery cost from the HA to the Lp new CoA of MN ¼ d HA–NAR Bw þg CCR–NAR unit packet delivery cost from the CR to the new Lp CoA of MN ¼ d CR–NAR Bw þg CCN–NAR unit packet delivery cost from the CN to NAR Lp without finding the CR ¼ d CN–NAR Bw þg BUNEW CR12 unit binding update cost to CR with CR to be BU found in NFFHMIPv6 ¼ d CR–NAR LBw þ L LBACK LBU BACK gÞ þ Bwl þ s þ d CR–NAR Bw þ g þ Bwl þ sÞ BUOLD CN unit binding update cost to the CN in FFHMIPv6 BU BU ¼ ðd HA–NAR þ d CN–HA Þ LBw þ g þ LBwl þ sþ LBACK LBACK ðd HA–NAR þ d CN–HA Þ Bw þ g þ Bwl þ sÞ BUOLD HA unit binding update cost to the HA in the same BU link in FFHMIPv6 ¼ d HA–NAR LBw þg þ LBACK LBACK LBU Bwl þ s þ d HA–NAR Bw þ g þ Bwl þ sÞ BUNEW HA3 unit binding update cost to CN without the CR BU BU ¼ d HA–NAR LBw þ g þ LBwl þ s þ d HA–NAR LBACK LBACK þ g þ þ sÞ Bw Bwl BUNEW unit binding update cost to CN without the CR CN3 LBU BU ¼ d CN–NAR Bw þ g þ LBwl þ s þ d CN–NAR LBACK LBACK Bw þ g þ Bwl þ sÞ the binding entry lifetime TBU In no route optimization (NRO) scheme (FFHMIPv6), there is no BU message to the CN, all BU messages are sent via HA. All packets sending from the CN must be routed to the HA and then HA forwards the packets to the MN in the NRO method. On the other hand, in our proposed new handover method, a route optimization method is used to improve the performance. The number of packets in a session is approximated to kS Æ E(s). In this paper, with the route optimization used, the cost must be analyzed depending on the different case scenarios mentioned above. Now we analyze the cost, respectively.
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
4.2. The signaling cost In FFHMIPv6 and NFFHMIPv6 methods, the registration process is shown in Table 1. As is shown in Table 1, the registration process in FFHMIPv6 must always be handled at HA and CN, which is same as the registration in Mobile IPv6, so the BU cost per a unit of cell residence time is shown as the following equation: 1 OLD p ðBUOLD C FFHMIPv6 ¼ HA þ BUCN þ PCHA þ PCCN Þ BU EðT Þ 1 LBU LBU p d HA–NAR þg þ þs ¼ EðT Þ Bw Bwl LBACK LBACK þ d HA–NAR þg þ þs Bw Bwl LBU LBU þg þ þ ðd HA–NAR þ d CN–HA Þ Bw Bwl LBACK þg þ s þ ðd HA–NAR þ d CN–HA Þ Bw LBACK þ þ s þ PCHA þ PCCN ð1Þ Bwl In typical MIPv6, the BU cost can be obtained by the following equation: 1 MIPm6 p ðBUHA þ BUCN þ RR þ PCHA þ PCCN Þ C BU ¼ EðT Þ 1 LBU LBU þg þ p d HA–NAR ¼ Bw Bwl EðT Þ LBACK LBACK þg þ þs þ s þ d HA–NAR Bw Bwl LBU LBU þg þ þs þ d CN–HA Bw Bwl LBACK LBACK þg þ þs þ d CN– HA Bw Bwl þ Maxfd HA–NARþ d CN–HA ; d CN–NAR g g þ s
3875
4.2.2. The MN moves from one subnet to another without finding the CR In this case, the MN must register its location to HA and the Corresponding CN. The BU cost can be obtained by 1 NEW p BUNEW HA3 þ BUCN3 þ RR þ PCHA þ PCCN EðT Þ 1 LBU LBU þg þ p d HA–NAR ¼ Bw Bwl EðT Þ LBACK LBACK þ s þ d HA–NAR þg þ Bw Bwl LBU LBU þ s þ d CN–NAR þg þ Bw Bwl LBACK LBACK þg þ þ s þ d CN–NAR Bw Bwl
C NFFHMIPv6 ¼ BU 3
þ s þ Maxfd HA–NAR þ d CN–HA ; d CN–NAR g g þ2s þ rCN þ PCHA þ PCCN
ð4Þ
4.3. The packet delivery cost During the BU process, the packets is forwarded to the new location of MN through the CR using a route optimization method, while in FFHMIPv6 the packets are all forwarded to the CR via HA. On the other hand, if the CR cannot be found, the packet delivery process is the same as it in MIPv6, while in FFHMIPv6 packets sent from CN must be forwarded via HA. The total packet delivery cost in FFHMIPv6 and NFFHMIPv6 method can be calculated by Eq. (4). (Here CHA, CR denote the handling cost at HA and CR, CT denotes the transmission cost from CNs to MNs.)
ð2Þ
þPCHA þ PCCN
C FFHMIPv6 ¼ C FFHMIPv6 þ C FFHMIPv6 þ C FFHMIPv6 PD HA CR T 4.2.1. The MN moves with a CR to be found In this case, the MN need not register its BU message to the HA, and only need to register to the CR. The BU cost can be calculated as the following equation: 1 C NFFHMIPv6 p ðBUNEW ¼ CR12 þ PCCR Þ BU12 EðT Þ 1 LBU LBU p d CR–NAR þg þ ¼ EðT Þ Bw Bwl LBACK LBACK þg þ þ s þ d CR–NAR Bw Bwl þ s þ PCCR
ð3Þ
C NFFHMIPv6 ¼ C NFFHMIPv6 þ C NFFHMIPv6 þ C NFFHMIPv6 PD HA CR T C MIPv6 PD
¼
C MIPv6 HA
þ
ð5Þ
C MIPv6 T
We assume that hHA denotes a packet processing cost at the HA, which is a constant. In FFHMIPv6, all packets sent from CNs to MNs must be forwarded by HA. On the other hand, in NFFHMIPv6, only the first packet in a session must be forwarded via HA. So CHA in the two method can be obtained by C FFHMIPv6 ¼ kS EðsÞ hHA HA
ð6Þ
C NFFHMIPv6 ¼ C MIPv6 ¼ kf hHA HA HA
Table 1 Registration process Method
Scenario 1
Scenario 2
Scenario 3
BU
BU process
BU
BU process
BU
BU process
FFHMIPv6
CN + HA
BU fi HA + BU fi CN
HA + CN
BU fi HA + BU fi CN
HA + CN
BU fi HA + BU fi CN
NFFHMIPv6
CR
BU fi CR
CR + HA + CN
BU fi HA + BU fi CN + BU fi CR
HA + CN
BU fi HA + BU fi CN
3876
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
In NFFHMIPv6, when the packets sent from CNS pass by CR, it will look up its mapping tables to translate between CR and NcoA. So the lookup time required for the mapping table must be considered. After that, the packet is routed to the MN. So the processing cost at the CR is consisted of look-up cost and routing cost. Clookup is proportional to the size of mapping table, which is proportional to the number of MNs that having the tunnel to it. Crouting is proportional to the logarithm of the number of ARs linking to a CR. Here we assume that NAR denotes the number of ARs, NMN denotes the number of MNs, which is proportional to the number of ARs. If the number of MNs in a AR area is K, then the total number of MNs can be obtained by N MN ¼ N AR K ð7Þ Therefore, the processing cost at the CR is expressed by Eq. (8), where n and d denote the weight factors. C FFHMIPv6 ¼ kS EðsÞ n N MN CR ¼ kS EðsÞ n N AR K C NFFHMIPv6 CR
ð8Þ
¼ kS EðsÞ ðC lookup þ C routing Þ ¼ kS EðsÞ ðn N MN þ d logðN AR ÞÞ ¼ kS EðsÞ ðn N AR K þ d logðN AR ÞÞ
In BU process, the packets can be delivered to the new location of MNs through the CR. Because in FFHMIPv6 method, route optimization is not supported, so every packet sent from CNs must be forwarded via HA. In NFFHMIPv6, packets can be sent to MNs’ new location directly because of route optimization. So the transmission cost can be calculated by the following equation: C FFHMIPv6 ¼ kS EðsÞ ðC CN–HA þ C HA–CR þ C CR–NAR T Lp þ þs Bwl ¼ kS EðsÞ ððd CN–HA þ d HA–CR þ d CR–NAR Þ Lp Lp þg þ þs ð9Þ Bw Bwl ¼ kf ðC CN–HA þ C HA–CR Þ þ ðkS kf Þ ðLs 1Þ C NFFHMIPv6 T Lp C CN–CR þ kS Ls C CR–NAR þ þs Bwl Lp þg ¼ kf ðd CN–HA þ d HA–CR Þ Bw Lp þg þ ðkS kf Þ ðLs 1Þ d CN–CR Bw Lp Lp þg þ þs þ kS Ls d CR–NAR Bw Bwl C MIPv6 ¼ k ðC þ C Þ þ ðk k Þ ðEðsÞ 1Þ f CN–HA HA–NAR S T f Lp C CN–NAR þ kS EðsÞ þs Bwl Lp þ g þ ðkS kf Þ ¼ kf ðd CN–HA þ d HA–NAR Þ Bw Lp þg ðEðsÞ 1Þ d CN–NAR Bw Lp þs þ kS EðsÞ Bwl
4.4. Session disrupt time In FFHMIPv6 and NFFHMIPv6, the packets sent from CNs can be redirected to the new location of MNs simulateously with the BU process. When taken into account the upstream packets, in FFHMIPv6 and MIPv6, it can be obtained by CNs until the BU to the HA and CN can be finished. But in NFFHMIPv6, when the CR is found, the packets sent from MNs can be tunneled to CR and then forwared to CNs by the old path recorded in the route table. So the session disrupt time in case of upstream and downstream can be obtained by (here TL denotes the L2 handover time, TI denotes the IP connectivity time): LBU down þ g þ d CR–NAR g T FFHMIPv6 ¼ T L þ T I þ d CR–NAR Bw LBU þ2s þ Bwl OLD OLD T up FFHMIPv6 ¼ T L þ T I þ BUHA þ BUCN LBU LBU þg þ ¼ T L þ T I þ d HA–NAR Bw Bwl LBACK LBACK þg þ þ s þ d HA–NAR Bw Bwl LBU þ s þ ðd HA–NAR þ d CN–HA Þ þg Bw LBU þ þ s þ ðd HA–NAR þ d CN–HA Þ Bwl LBACK LBACK þg þ þs Bw Bwl up T down NFFHMIPv6 ¼ T NFFHMIPv6
ð10Þ
LBU þ g þ d CR–NAR ¼ T L þ T I þ d CR–NAR Bw LBACK LBU LBACK þg þ þ þ2s Bw Bwl Bwl
up T down MIPv6 ¼ T MIPv6
LBU LBU þg þ þs ¼ T L þ T I þ d HA–NAR Bw Bwl LBACK LBACK þ d HA–NAR þg þ þs Bw Bwl LBU LBU þ d CN–NAR þg þ þ s þ d CN–NAR Bw Bwl LBACK LBACK þg þ þs Bw Bwl
5. Numerical results In order to analyze the performance of the proposed fast handover method, we consider some of the system parameters as constants, which are shown in Table 2. The parameter values for the analysis were referenced from [23,24]. In
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
3877
Table 2 Parameter values for numerical analysis kS
E(s)
Lp
dCN–HA
TL + TI
LBU
LBACK
g
s
kf
dHA–CR
Bwl
0.1
10
1500
6
165
112
96
1
2
0.02
6
11M
dCN–CR
dHA–NAR
dCR–NAR
dCN–NAR
n
d
hHA
PCHA
PCCN
PCCR
Bw
4
8
3
8
0.1
0.2
20
24
6
6
100M
this paper, we discuss the impact of average residence time and the rate of MN’s movement to Signaling Cost. We also analyze the impact of the MNs to the packet delivery cost.
100
Signaling cost
80
5.1. The impact of user’s mobility If the cell residence time is large, it means that the MN is most likely to remain in a cell and seldom moves to other location, so the signaling cost is very small. So the signaling cost is inversely proportional to the average residence time, which is shown in Fig. 6. Here p is set to 1, Bw is set to 100 Mbps, Bwl is set to 11 Mbps, respectively. On the other hand, if the MN moves frequently, the BU cost will increase accordingly. So the BU cost is proportional to the rate of MN’s movement. Fig. 7 shows the relationship of MN’s mobility rate and BU cost. 5.2. The impact of user population In this paper, when packets passing by the CR, it will look up the mapping table to find the NAR tunneling the packets, and also it will find the route path. So the handling cost at the CR is logarithm to the number of ARs and proportional to the number of MNs. In Fig. 8, the impact of the user population to packet delivery cost is shown. (Here we only consider the case when the CR can be found.) When the CR cannot be found, the packet delivery costs of the three methods are equal. 5.3. Delay time In this paper, based on the FFHMIPv6 method, we proposed a new flow-based fast handover method which sup-
60 50 40 20 10 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Fig. 7. The impact of user mobility (E(T) = 1).
port route optimization. So the packets sent from the CNs can be redirected to the MNs by the tunnel ahead of time, which is equal to that of FFHMIPv6. When taken into account the upstream packets, in FFHMIPv6, the MNs cannot send packets until the BU process to HA and CN is finished. But in our proposed NFFHMIPv6, if the CR can be found, the BU process is only to CR, so the BU process is shorter than that of FFHMIPv6 and MIPv6 methods. The numerical results considering that the CR can be found are shown in Fig. 9. If the CR cannot be found, when MNs move to a new link, they will register its new location to its HA and its corresponding CNs. So in this case, the downstream and upstream delay time are the same as that in MIPv6. Because no route optimization is supported in FFHMIPv6, so the BU process to the CN must be forwarded via HA, which results in larger BU cost than that of NFFHMIPv6 and MIPv6. Fig. 10 shows the results.
60
80
Signaling cost
70
FFHMIPv6 MIPv6 NFFHMIPv6
90
FFHMIPv6 MIPv6 NFFHMIPv6
50 40 30
70 60 50 40 30
20
20
10
10 1
2
3
4
5
6
7
average residence time(sec) (a)in case of CR to be found
8
9
10
1
the rate of user mobility
100
80
Signaling Cost
70
30
90
0
FFHMIPv6 MIPv6 NFFHMIPv6(CR) NFFHMIPv6(no CR)
90
0
1
2
3
4
5
6
7
8
average residence time(sec) (b) in case of no CR
Fig. 6. The impact of average residence time to signaling cost.
9
10
3878
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 80
80 FFHMIPv6 MIPv6 NFFHMIPv6
60 50 40 30 20
60 50 40 30 20 10
10 0
FFHMIPv6 MIPv6 NFFHMIPv6
70 Packet delivery cost
Packet delivery cost
70
0 1
2
3
4 5 6 7 8 number of MNs in a cell (a)the number of AR is 7
9
10
7
14
21
28 35 42 49 56 number of ARs (b)number of MNs is 2 in a cell
63
70
Fig. 8. The impact of user population.
270 FFHMIPv6 MIPv6 NFFHMIPv6
downstream delay time(ms)
240 210 180 150 120 90 60 30
FFHMIPv6 MIPv6 NFFHMIPv6
240
upstream delay time(ms)
270
210 180 150 120 90 60 30
0
0 the case with CR
the case with CR
Fig. 9. The delay time in case that the CR can be found.
300
FFHMIPv6 MIPv6 NFFHMIPv6
down/up stream delay time
270 240 210 180 150 120 90 60 30 0
the case without CR
Fig. 10. The delay time in case without CR.
6. Simulative studies We have used NS-2.31 [25] to simulate our proposed fast handover method. In order to support Mobile IPv6, we added the FHMIP1.3.1 extension [26], which is provided by SeaSon. The simulations required the implementations of FFHMIPv6 and NFFHMIPv6 and some necessary modifications to the ns-2 and FHMIP1.3.1. The NFFHMIPv6 implementation required some modifications to the FHMIP1.3.1 code, especially to the MHAgent, the MIPv6 header and classifiers. We implemented flow cache to every node, thus all nodes cache the traffic
flows it sends, receives or routes. MHAgent adds the FFHMIPv6 option in its Hop-by-Hop header to the first BU message after obained a new CoA. At every node on the way to HA the FFHMIPv6 information in the first BU message is compared to that of flow cache of the node. If the specified flow is found, a tunnel is created to the new CoA and the flow is redirected to the new location. Then the BU process continues. The simulation scenario with all of the participating entities and links is described in Fig. 11. The scenario consists of two 2 Mbps Wireless LAN 802.11 Distributed Coordination Function (DCF) accordant base stations (BSs). All BSs are connected to a different ARs and thus represent different IP subnet. The BSs are connected via two routers (R1 and R2) and duplex links to the border router (BR), which act as ingress and egress point to outer network. The HA and the CN are located in the outer network. In the scenario, the base stations are at the horizontal positions, the movement area is 1000 · 1000 m2 and the BSs cover the whole area. The transmission range of the BSs with omni-directional antennas is about 250 m and the minimum distance between the BSs is 350 m. During the handover CN sends TCP-based FTP traffic to the MN. The size of crowd window is 32, the packet size is 512. The MN, originally situated in PAR area, moves at a constant speed of 10 m/s towards NAR. The simulation result is shown in Fig. 12, which compare with the
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880
CN 100MB
HA 100MB
/2ms BR /2ms 10MB 10MB/50msCR 10MB /2ms /2ms R1 1000KB /2ms PAR
R2 1000KB /2ms NAR
MN Fig. 11. Simulation scenario.
Fig. 12. Simulation result.
NFFHMIPv6 and FFHMIPv6. The result shows that the NFFHMIPv6 has the better delay performance. 7. Conclusions In this paper, we present a new flow-based fast handover method for Mobile IPv6 network with route optimization.The NFFHMIPv6 method is theoretically compared with the FFHMIPv6 method. The simulation result show that the NFFHMIPv6 have a shorter handover time compared with the FFHMIPv6 method. References [1] D.B. Johnson, C. Perkins, J. Arkko, Mobility support in IPv6, RFC 3775, June 2003. [2] R. koodli, Fast handover for Mobile IPv6, IETF draft, work in progress, 2003. [3] H. Soliman, C. Castelluccia, K. El-malki, L. Bellier, Hierarchical Mobile IPv6 mobility management(HMIPv6), IETF draft (work in progress), draft-ietf-mobileip-hmipv6-08.txt, June 2003. [4] C. Castelluccia, HMIPv6: a hierarchical Mobile IPv6 proposal, ACM Mobile Computing and Communications Review 4 (1) (2000) 48–59. [5] Hee Young Jung, Eun Ahkim, Jong Wha Yi, Hyeong Ho Lee, A scheme for supporting fast handover in hierarchical Mobile IPv6 networks, ETRI Journal 27 (6) (2005) 798–801.
3879
[6] V.L.L. Thing, H.C.J. Lee, Y. Xu, Performance evaluation of hop-byhop local mobility agents probing for Mobile IPv6, in: Proceedings of the Eighth IEEE International Symposium on Computers and Communications 2003 (ISCC 2003), June 30–July 3 2003, pp. 576– 581. [7] V.L.L. Thing, H.C. Lee, Y. Xu, Hop-by-hop local mobility agents probing for Mobile IPv6, IETF Internet Draft version1 (work in progress), October 2002. [8] V.L.L. Thing, H.C. Lee, Y. Xu, Designs and analysis of local mobility agents discovery, selection and failure detection from Mobile IPv6, in: IEEE Conference on Mobile and Wireless Communications Networks, 2002. [9] C. Williams, Localized mobility management Requirements, IETF Internet Draft version2 (work in progress), June 2002. [10] S.-H. Hwang, B.-K. Lee, Y.-H. Han, C.-S. Hwang, An adaptive hierarchical vehicular technology conference 2003 (VTC 2003Spring), vol. 3. 22–25 April, 2003, pp. 1502–1506. [11] A.K.M. Mahtab Hossain, Kanchana Kanchanasut, A handover management scheme for Mobile IPv6, in: The 14th International Conference on Computer Communications and Networks ( ICCCN 2005), 17–19 October 2005, pp. 43–48. [12] K. Omae, T. Ikeda, M. Inoue, I. Okajima, N. Umeda, Mobile node extension employing buffering function to improve handoff performance, in: The 5th International Symposium on Wireless Personal Multimedia Communications 2002, vol. 1, 27–30 October 2002, pp. 62–66. [13] L. Patanapongpibul, G. Mapp, A client-based handoff mechanism for Mobile IPv6 wireless networks, in: Proceedings of the Eighth IEEE International Symposium on Computers and Communication 2003 (ISCC 2003), 30 June–3 July 2003, pp. 563–568. [14] N. Moore, Optimistic duplicate address detection, draft-ietf-ipv6optimistic-dad-05.txt, February 2005. [15] J. Choi, Dong Yun Shin, Fast router discovery with RA, draftjinchoi-mobileip-frd-00.txt, June 2002. [16] Y. Han, Y. Choi, S. Park, Advance duplicate address detection, drafthan-mobileip-adad-00.txt, February 2003. [17] B. Park, S. Lee, H. Latchman, A fast neighbor discovery and dad scheme for fast handover in Mobile IPv6 networks, ICNICONSMCL’06. [18] M. Sulander, T. Hamalainen, A. Viinikainen, J. Puttonen, Flowbased fast handover method for Mobile IPv6 network, in: Proceeding of the 59th IEEE Semiannual Vehicular Technology Conference (VTC’S04), May 2004. [19] Jani Puttonen, Ari Viinikainen, M. Sulander, T. Hamalainen, Performance evaluation of the flow-based fast handover method for Mobile IPv6 Network, in: Proceedings of the 60th Semiannual IEEE Vehicular Technology Conference(VTC’F04), September 2004. [20] Vivaldi, B.M. Ali, H. Habaebi, V. Prakash, A. Sali, Routing scheme for macro mobility handover in hierarchical Mobile IPv6 network, in: Proceedings of the 4th National Conference on Telecommunication Technology 2003 (NCTT 2003), 14–15 January 2003, pp. 88–92. [21] J. Na, J. Choi, S. Cho, A unified Route optimization Scheme for Network Mobility,
3880
C. Jin, Z. Xi-Huang / Computer Communications 30 (2007) 3870–3880 Chen Jin was born in 1976. She is a Post graduate student of Jiangnan University in China. She is interested in the researching fields such as Mobile IPv6 and embedded system.
Zhang Xi-Huang was born in 1962. He is an associate professor and his researching works include wireless networks and embedded system.