國
立
交
通
大
學
資訊科學與工程研究所
碩
士
論
文
一個階層式行動網路下的代理式快速換手
機制
A Proxy-based Fast Handover Scheme for Hierarchical
Mobile IPv6
研 究 生：黃紀寰
指導教授：陳耀宗 教授
李義明 教授
一個階層式行動網路下的代理式快速換手機制
A Proxy-based Fast Handover Scheme for Hierarchical Mobile IPv6
研 究 生：黃紀寰 Student：Chi-Huan Huang
指導教授：陳耀宗 Advisor：Yaw-Chung Chen
李義明 Advisor：Yiming Li
國 立 交 通 大 學
資 訊 科 學 與 工 程 研 究 所
碩 士 論 文
A ThesisSubmitted to Institute of Computer Science and Engineering College of Computer Science
National Chiao Tung University in partial Fulfillment of the Requirements
for the Degree of Master
in
Computer Science
July 2010
Hsinchu, Taiwan, Republic of China
一個階層式行動網路下的代理式快速換手機制
學生：黃紀寰
指導教授：陳耀宗 博士
李義明 博士
國立交通大學資訊科學與工程研究所
摘 要
隨著無線網路與通訊技術迅速的發展，IETF 組織提出 Mobile IPv6 (MIPv6)協定以支 援行動裝置在 IPv6 網路上的移動管理。然而，支援 MIPv6 的行動裝置在換手的過程中 會遭受很長的換手延遲(handover latency)與封包遺失(packet loss)，對於即時性的多媒體 服務，例如 VoIP、IPTV 等，其換手延遲時間仍無法滿足使用者的需求。雖然 IETF 組 織隨後提出 Fast Handover for Mobile IPv6 (FMIPv6)來解決此問題，但是上述兩種標準都 需要修改行動裝置的設備，增加了應用普及化的困難度。因此 IETF 組織也提出了 Proxy
Mobile IPv6 (PMIPv6)來管理移動網路，由於 PMIPv6 是一個以網路為基礎的區域(local) 移動管理方法，因此不需要修改到移動網路的設備，但是行動裝置在 PMIPv6 環境換手 的過程仍然會發生換手延遲和封包遺失的狀況。 本論文提出一個快速換手的機制，將階層式網路架構的概念引入 PMIPv6 網路環境， 以解決行動裝置在 PMIPv6 環境下換手過程中所發生的問題，並且加入額外的緩衝區機 制來減少封包遺失並保持封包順序一致。在本篇論文中，我們利用數學解析公式對 PMIPv6 進行分析，並與其他文獻所提出的方法進行比較。從模擬的結果可以看出，本 論文所提出之方法可以有效地減少換手延遲，並且達成無縫隙換手(seamless handover) 的服務水準。 關鍵詞：行動 IPv6、階層式、代理式、快速換手、無縫隙換手、緩衝區機制。
A Proxy-based Fast Handover Scheme for Hierarchical Mobile IPv6
Student：Chi-Huan Huang
Advisors： Dr.
Yaw-Chung Chen
Dr. Yiming Li
Institute of Computer Science and Engineering
National Chiao Tung University
ABSTRACT
The Internet Engineering Task Force (IETF) provides the mobile IPv6 (MIPv6) to support the mobility management of the mobile node (MN). However, MN supporting the MIPv6 suffers from long handover latency and packet loss. For real-time multimedia service such as VoIP and IPTV, the handover latency is not acceptable for service provisioning. Although IETF proposes the Fast Handover for Mobile IPv6 (FMIPv6) to solve the problem, these protocols require modification to the MN and aggravate the difficulty for getting popularity. IETF also provides the Proxy Mobile IPv6 (PMIPv6) to control the mobile networks. The entity of serving network controls the mobility management on behalf of MN without requiring any involvement of MN stack since PMIPv6 is a localized mobility management mechanism. Nevertheless, the MN still suffers from handover latency and packet loss during handover in PMIPv6 domain.
In this thesis, we propose a fast handover mechanism which introduces the idea of hierarchical network architecture into PMIPv6, to solve the problem that the MN encountered during handover in PMIPv6 domain; moreover, we introduce an additional buffering scheme to reduce packet loss and solve packet ordering problem. In this study, we utilize a mathematical formula to analyze the performance of the MN’s handover in the PMIPv6 domain, and compare it with the mechanism in the other literature. The numerical results show that our proposed scheme effectively reduces the handover latency, and fulfills the quality-of-service for seamless handover.
Keywords: Mobile IPv6, Hierarchical, Proxy, Fast Handover, Seamless Handover, Buffering
致 謝
在碩士班研究生涯的三個寒暑，前後經歷了三個實驗室、接受過三位恩師的指導， 一路上要感謝的人實在太多了。這篇碩士論文得以順利產生，首先要感謝的是我的指導 教授 陳耀宗老師，從我剛進實驗室開始、中間幾經波折的換了題目，老師都願意給予 我最大的寬容和自由度，讓我嘗試各種不同的題目作我喜愛的研究，並且在研究過程中， 給予適當地指引使我不致迷失方向；以及 李義明老師，給予我最大的自由度，讓我得 以作我感興趣的研究。在研究上，不僅從老師身上學到了很多作研究的方法；老師處理 事情積極和嚴謹的態度更是令我終身受用。在這裡也要感謝我的論文口試老師 詹家泰 老師和留忠賢老師，感謝老師們對我的論文提出指正與建議，才得以使我的論文更加完 備。第三位要感謝的是恩師 韓復華老師，在運管碩士班期間一年的栽培指導，並且讓 我選擇自已的研究興趣。 接著要感謝的人，就是在研究所期間陪伴我一起成長、打拼的實驗室同學，以及學 長姐、學弟妹。在 MMLAB，我要感謝振華學長、俊利學長、育嘉學長、月慧學姐你們 在我論文研究和寫作上的建議；同時要在這裡特別謝謝強者 振全ㄉㄉ的技術支援、好 麻吉吟珊的精神陪伴、還有瑋芸和嘉瑋的協助，才能讓本篇論文在時間內順利完成。在 YMLAB，感謝國輔、銘鴻、毓翔和英傑，因為有你們這群同學的鼓勵和扶持，以及在 閒瑕時的嘴砲，讓我在這兩年的研究生活中增添了很多歡樂。另外也謝謝志鴻學長、惠 文學姐、忠誠學長、翊修學弟、俊諺學弟、如薇學妹的一路幫忙。在韓 LAB，俊德學長、 朱頭學長、忠傑、鴻祥、小胖、婷尹，謝謝你們讓我度過快樂的運管碩一時光。 最後要感謝我最摯愛的家人，謝謝你們百分之百的支持與體諒，讓我能夠心無旁騖 的完成學業、順利的拿到碩士學位，並繼續追求自已的夢想。 謹誌於 風城交大 2010 年 8 月 25 日 黃紀寰Contents
ZZZ``` . . . i ABSTRACT . . . ii l l l . . . iii Contents . . . iv List of Figures . . . viList of Tables . . . viii
1 Introduction . . . 1
2 Background and Related Work . . . 4
2.1 Mobile IPv6 . . . 4
2.2 Proxy Mobile IPv6 . . . 6
2.3 Hierarchical Mobile IPv6 . . . 9
2.4 Fast Handovers for Mobile IPv6 . . . 10
2.5 Fast Handovers for Hierarchical Mobile IPv6 . . . 13
2.6 Fast Handovers for Proxy Mobile IPv6 . . . 13
2.7 Summary . . . 17
3 Proposed Scheme . . . 18
3.1 Network Architecture . . . 19
3.2.1 Local Proxy Binding Update Message . . . 20
3.2.2 Local Proxy Binding Acknowledgement Message . . . 20
3.3 Proxy-based Fast Handover for Hierarchical Mobile IPv6 . . . 21
3.3.1 MN Enters a New AR Domain . . . 21
3.3.2 MN Enters another AR under same MAP Domain . . . 23
3.3.3 Predictive Mode . . . 23
3.3.4 Reactive Mode . . . 26
4 Performance Analysis . . . 28
4.1 Analytical Models . . . 28
4.2 Performance Comparison . . . 32
5 Simulation and Results . . . 35
5.1 Simulation Scenarios . . . 35 5.2 Experimental Results . . . 36 5.2.1 Predictive Mode . . . 36 5.2.2 Reactive Mode . . . 39 6 Conclusion . . . 45 Bibliography . . . 46
List of Figures
2.1 Overview of MIPv6. . . 5
2.2 Overview of PMIPv6. . . 6
2.3 Signaling flow of PMIPv6. . . 7
2.4 Predictive Fast Handover with MIPv6. . . 12
2.5 Reactive Fast Handover with MIPv6. . . 12
2.6 Predictive Fast handover with PMIPv6. . . 14
3.1 A handover scenario in proxy-based HMIPv6 domain. . . 19
3.2 LPBU message format. . . 20
3.3 LPBA message format. . . 21
3.4 Signal Flow of Mobile Node Attachment. . . 23
3.5 Predictive Fast Handover with proposed scheme. . . 24
3.6 Reactive Fast Handover with proposed scheme. . . 27
4.1 The improved ratio of handover latency. . . 33
4.2 The improved ratio of handover latency compared with FPMIPv6. . . 34
4.3 The improved ratio of handover latency compared with PMIPv6. . . 34
5.1 The network topology for simulation. . . 36
5.2 The packet sequence number in predictive fast handover with PMIPv6. . . 37
5.3 The packet sequence number in predictive fast handover with FPMIPv6. . . 37
5.4 The packet sequence number in predictive fast handover with proposed scheme. 38 5.5 The packet sequence number in reactive fast handover with PMIPv6. . . 39
5.6 The packet sequence number in reactive fast handover with FPMIPv6. . . 40
5.7 The packet sequence number in reactive fast handover with the proposed scheme. 41 5.8 The comparison of handover latency. . . 42
List of Tables
2.1 Mobility Management Protocols Comparison. . . 17 4.1 Parameters for performance analysis. . . 29 5.1 Performance Comparison. . . 44
Chapter 1
Introduction
In recent years, the broadband wireless networks are rapidly evolving towards all-IP net-works. With a quick growth in the number of Internet users in wireless environment, the issue of IP mobility management technology becomes more and more important.
The main purpose of mobility management is to provide continuous service to an MN with-out breaking the connection when an MN changes its point of attachment (PoA) [10]. To support service continuity, mobility management protocols should maintain the continuous connection during handover process. However, the connection disruption is inevitable because an MN usu-ally has single wireless interface, hence MN’s link-layer (L2) would lose connection until it attaches to a new PoA during handover process.
Mobile IPv6 (MIPv6) [1] is a well-known host-based mobility management protocol. The IETF proposed MIPv6 as the main protocol for mobility management in the IP layer. MIPv6 maintains the connection by utilizing two functionalities of the IP address, which are home ad-dress (HoA) and care-of-adad-dress (CoA). However, although MIPv6 is a famous mature protocol for IPv6 mobility management, it has some critical problems such as handover latency, packet loss and signaling overhead during handover process. Therefore, in 2005, the IETF proposed Mobile IPv6 Fast Handover (FMIPv6) [2] to solve these problems. FMIPv6 is a protocol that supports faster seamless handover. A MN first scans its environments to determine whether it needs perform the network-layer (L3) handover before actual link-layer handover. The MN acquires the information about target access router in advance and it notifies the current access
router immediately before it starts handover. After that, the access router performs tunneling and buffering for seamless service. However, although FMIPv6 avoided packet loss and reduced handover latency, it requires modification to the protocol stack of MN to support IP mobility. Hence, it may be difficult for users to promote this protocol.
For improving the handover performance of MIPv6, another typical extension scheme, Hi-erarchical MIPv6 (HMIPv6) [3], is being standardized in the IETF. The HMIPv6 has been designed to enhance MIPv6 in the signaling and handover aspects. HMIPv6 reduces the sig-naling overhead and delay involved with the binding update (BU) using a hierarchical network architecture. In HMIPv6, it introduces a new mobile entity called the mobility anchor point (MAP) and aims to reduce the amount of signaling and registrations between the MN and HA, so that the signaling costs is shortened. However, HMIPv6 still suffers packet loss and handover latency problems. In order to reduce handover latency between ARs within a MAP domain, fast hierarchical MIPv6 (FHMIPv6) has been proposed by IETF [6]. FHMIPv6 introduced the con-cept of FMIPv6 into HMIPv6 to shorten the handover latency.
Recently, a network-based mobility management protocol, so-called the Proxy Mobile IPv6 (PMIPv6), is being proposed by the IETF [4]. Unlike the MIPv6, PMIP6 is designed to provide network-based mobility management support to an MN in a topologically localized domain. Therefore, it does not require the participation of MN in mobility signaling. PMIPv6 is based on MIPv6 that extends MIPv6 signaling and reuses many MIPv6’s original ideas such as func-tionality of Home Agent (HA). It utilizes the MN’s link-layer attachment and performs a local binding update. PMIPv6 does not require the network-layer movement detection or MN’s IP address change after handover. In other words, the MN always maintaines the HoA and does not need to perform Duplicate Address Detection (DAD) procedure. Thus, PMIPv6 can handover relatively faster than MIPv6. However, PMIPv6 still suffers handover latency and packet loss during handover process.
For the latest few years, Xia [12], Park [13], and Yokota [5] et al. suggested several fast handover mechanisms based on PMIPv6 to reduce the handover latency and packet loss with PMIPv6. These mechanisms still have some limitations or problems, e.g. on-the-fly packet loss and packet ordering problem.
Therefore, we combine the characteristics of FHMIPv6 and FPMIPv6, and present a seam-less handover scheme for PMIPv6 in hierarchical architecture. We apply the hierarchical archi-tecture here to reduce the handover latency. Our proposed scheme introduces two new messages called Local Proxy Binding Update (LPBU) message and Local Proxy Binding Acknowledge (LPBA) message, and sends LPBU to the MAP rather than the HA during handover. It can eliminate the packet transmission delay between the ARs and HA. The proposed scheme for solving on-the-fly packet loss, which is routed between the HA and the previous access router (PAR) during handover, the proposed scheme uses the tunneling and the buffering mechanisms, so that a packet destined to the MN can be buffered at the NAR. In addition, this scheme uses an additional packet buffering at the NAR to ensure the packet sequence between the forwarding packets from PAR and the newly arriving packets from the HA through MAP after a handover registration. Simulation results demonstrate that our proposed scheme can avoid the packet loss during a handover. Our proposed scheme is also able to ensure the packet sequence through using additional packet buffer at the NAR.
The rest of this thesis is organized as follows. In Chapter 2, we investigate the host-based mobility management protocol and its handover procedure such as MIPv6, FMIPv6, HMIPv6, and FHMIPv6. We also investigate the network-based mobility management protocol such as PMIPv6 and FPMIPv6. In Chapter 3, we discuss our proposed seamless handover scheme. Per-formance analysis and simulation results are presented in Chapters 4 and 5 respectively. Finally, we draw conclusions.
Chapter 2
Background and Related Work
2.1 Mobile IPv6
The Mobile IP protocol defines a set of entities and procedures that enable a mobile device, often called mobile node (MN) or mobile host (MH), to retain its home address on the move, without requiring changes in the intermediate routing nodes. Figure 2.1 shows the overview of Mobile IPv6 (MIPv6), the protocol consists of a HA that serves the MN when the MN is within home network and AR advertises the address every time when the MN moves into foreign net-work. When the MN wants to move to the visited or foreign network, the MN will acquire a new CoA advertised by AR. The MN then registers its new CoA to the HA and correspondent node (CN). After address registration the HA intercepts those packets coming from the CN and heading for the MN’s HoA, encapsulates these packets, and then tunnels them to the MN’s registered CoA. The CN is the node communicating with the MN. The MN has to report any change in the current CoA by sending a BU to its HA.
Mobile Node (MN)
Home Agent (HA)
Correspondent Node (CN)
Access Router (AR)
Home Network Visited Network Mobile Node (MN) Handover IP Tunnel communication
Figure 2.1 Overview of MIPv6.
In 2002, Mobile IPv4 [9] (MIPv4) was proposed by IETF, MIPv4 is designed to allow mobile device users to maintain a fixed IP address when they roam to a different network do-main. However, MIPv4 has many problems such as triangular routing, security and limitation of address space. In 2004, the IETF proposed MIPv6 to solve these problems and it leads to conversion into All-IP mobile network. After route optimization in MIPv6, the CN can send IP packets directly to the MN. The route optimization procedure is triggered by the MN. A binding update which is similar to the update sent to the HA, is used to inform the CN about the MN’s current location. Note that several messages must be exchanged in this process be-cause it involves a return routability test and binding acknowledgement. Although MIPv6 is a mature protocol in mobility management, it still remains some problems, such as handover latency, packet loss and high signaling overhead. Moreover, for real time application such as VoIP, IPTV and video conference, handover latency and disruption time will directly affect the Quality of Service (QoS) and Quality of Experience (QoE) for these real time services. In re-cent years, research on MIPv6 is focused on improvement of the performance of MIPv6. There are several techniques for reducing the handover latency and packet loss in MIPv6 such as Hi-erarchical Mobile IPv6 [3] (HMIPv6) and Fast Mobile IPv6 [2] (FMIPv6) have been developed by IETF.
2.2 Proxy Mobile IPv6
PMIPv6 is a network-based IP mobility management to support an MN in a topologically localized domain. In a network-based approach, the serving network controls mobility man-agement on behalf of MN. It does not require the participation of MN in any mobility-related signaling. The primary features of PMIPv6’s goal are serving for unmodified MNs, supporting the IPv4 and IPv6, efficient use of wireless resources, and handover performance improvement (more details are addressed in [7]).
Figure 2.2 Overview of PMIPv6.
Figure 2.2 illustrates an overview of how PMIPv6 works within a localized domain. The brief descriptions of the basic terminology are also shown in this figure. As shown in Fig. 2.2, the new major functional entities of PMIPv6 are the mobile access gateway (MAG) and local mobility anchor (LMA). The main function of the MAG is to detect the MN’s movements and initiate mobility-related signaling with the MN’s LMA on behalf of the MN. In addition, the MAG establishes a tunnel with the LMA for allowing the MN to use an address (e.g. HoA) from its home network prefix (HNP) and imitates the MN’s home network on the access net-work for each MN. On the other hand, the LMA acts as MN’s HA in PMIPv6. However, it has additional capabilities required to support PMIPv6. The main role of the LMA is to maintain
reachability to the MN’s address when it moves around within a PMIPv6 domain. The LMA maintains a binding cache entry (BCE) for each currently registered MN. The BCE maintained at the LMA is more extended than that of the HA in MIPv6 with some additional fields. These additional fields include the MN-Identifier, the MN’s home network prefix, a flag indicating a proxy registration, and the interface identifier of the bidirectional tunnel between the LMA and MAG. This information associates the MN with its serving MAG, and enables the relationship between the MAG and LMA to be maintained.
MN P-MAG LMA N-MAG
Bi-Dir Tunnel MN Attached
Rtr Sol
Acquire MN-Id and profile
PBU
PBA
Binding cache (MN-HNP, Proxy-CoA1)
Binding Update List (MN-HNP, LMAA) Rtr Adv IP Address Configuration MN Detached MN Detached event DeReg PBU PBA Start BCE Delete timer Binding update List removed MN Attached MN Attached event Acquire MN-Id and
profile Bi-Dir Tunnel PBA PBU Binding cache (MN-HNP, Proxy-CoA2)
Binding Update List (MN-HNP, LMAA)
Rtr Adv MN retains
HoA/HNP
Figure 2.3 Signaling flow of PMIPv6.
step is described as follows:
1. an MN first attaches to an access network connected to the MAG;
2. using an MN’s identity, e.g. MN-Identifier, the access authentication procedure is per-formed via the deployed access security protocols on the access network;
3. if the access authentication procedure is successful, the MAG obtains the MN’s profile, which contains the MN-Identifier, LMA address, supported address configuration mode, and so on from authentication, authorization, and accounting (AAA) server;
4. then the MAG sends the Proxy Binding Update (PBU) message including the MN-Identifier to the MN’s LMA on behalf of the MN;
5. upon receiving PBU message, the LMA allocates a proper home network prefix for the MN; and
6. then the LMA replies a Proxy Binding Acknowledgement (PBA) message including the MN’s home network prefix option, and sets up a route for the MN’s home network prefix over the tunnel to the MAG.
In PMIPv6, there is a bidirectional tunnel established between the LMA and the MAG. This could be appropriate because the tunneling increases the bandwidth constraints on the wireless link and the processing load on the MN. Once the MAG receives the PBA message from the LMA, it has obtained all the required information to imitate the MN’s home network on the access network, and it then starts to send a router advertisement (RA) message which contains the MN’s home network prefix to the MN. On receiving the RA message, the MN configures its home address by combining the home network prefix and its interface identifier (e.g. MAC address), which is based on the supported address configuration mode (e.g. stateless or stateful address configuration mode) from the AAA server. Because PMIPv6 only supports the per-MN prefix model, a unique home network prefix is assigned to each per-MN. That is, when a per-MN is roaming within a PMIPv6 domain, it always obtains its unique home address. After the bidirectional tunnel is successfully established, the traffic sent from the MN or CN gets routed
to its LMA through this tunnel. After that, the LMA will intercept all data packets sent by the CN to the MN, and forward these packets to the MAG through the tunnel. On the other end of the tunnel, the MAG will receive the packets and removes the outer header, and forward the packets to the MN.
2.3 Hierarchical Mobile IPv6
HMIPv6 separates mobility management into two parts. The first is micro mobility or intra-domain mobility and the second is macro mobility or inter-intra-domain mobility. The central entity of HMIPv6 is the inclusion of a special conceptual element called MAP. In HMIPv6, the MAP acts as a router or a set of routers that maintains a binding cache mapping between itself and the visiting MNs in the local domain currently. It is usually placed into the edges of a net-work, above the access routers, receives packets on behalf of the MNs attached to that network. Whenever an MN attaches itself to a new network, it registers with the MAP serving that net-work domain (MAP domain).
The characteristic of MAP acts as the local home agent for the MN. It intercepts all the packets addressed to the MN and forwards them to the corresponding on link CoA of the MN. When the MN changes its current point of attachment within the same MAP domain, it only needs to register a new on-link care-of address (LCoA) from the foreign agent serving it, and the MN just needs to register the LCoA to the MAP. Therefore it does not need to change the global CoA or regional care-of address (RCoA), all packets heading for MN are intercepted by MAP, which encapsulate the packet and send it to MN’s current LCoA. By using this approach, the signaling cost is limited within a smaller area between MAP and AR. The handover signaling without requiring propagation through the whole network and location update time is reduced. However, if a MN moved into a new MAP domain, the MN needs not only to get a regional care of address (RCoA) but also to acquire an on-Link Care-of address (LCoA), as its current location. Then, the MN uses the new MAP’s address as the RCoA, while the LCoA address can be formed as stated in [8]. The procedure is as follows: After these addresses are formed, the MN sends a regular MIPv6 BU message to the MAP, which will create a binding cache mapping and bind the MN’s RCoA to its LCoA. After creating BCE successfully, the MAP will
return a binding acknowledgement (BAck) message to the MN indicating a successful registra-tion. After registering with the MAP, the MN also needs register its new RCoA with its HA by sending another BU message that specifies the binding (RCoA and MN’s home address), as in MIPv6. Finally, it may send similar BU to its current communicating CN, specifying the binding between its home address and the RCoA.
2.4 Fast Handovers for Mobile IPv6
The fast handover scheme in Mobile IPv6 (FMIPv6) [2] introduce seven additional mes-sage types for use between ARs and the MN. These seven mesmes-sages are: Router Solicitation for Proxy (RtSolPr), Proxy Router Advertisement (PrRtAdv), Handover Initiation (HI), Han-dover Acknowledgement (HAck), Fast Binding Update (FBU), Fast Binding Acknowledgement (FBAck), and Unsolicited Neighbor Advertisement (UNA). FMIPv6 defines two access routers for fast handover. The previous Access Router (PAR) is defined as the router to which the MN is currently attached and the new Access Router (NAR) as the router to which the MN is about to move. The fast handover initiation is based on an indicative trigger from the MN’s wireless link-layer, and this indication informs that the MN imminently handover to another AR. Basically, this indication mechanism anticipates the MN’s movement and performs packet forwarding correspondingly. The handover procedures are as follow.
When the MN detects that the wireless signal from current AR is weak and there is stronger wireless signal from another AR, the handover event imminently occurs. To initiate a fast han-dover, the MN sends a RtSolPr message to the PAR indicating that it wishes to perform a fast handover procedure to a new attachment point, e.g. NAR. The RtSolPr contains the MAC layer address of attachment point to indicate new target attachment point. The MN will receive a PrRtAdv message in response to the PAR with a set of possible responses indicating the attach-ment points. Based on the response, the MN forms a new address using the method described in [8]. Subsequently, the MN sends a FBU message to the PAR including its newly formed address as the last message before the handover is executed. Then the MN receives FBAck message either through the PAR or the NAR indicating that the binding was successful. When the MN moves into the NAR’s domain, it sends the UNA message to initiate the flow of packets
at the NAR.
In addition to the exchange with the MN, the PAR exchanges information with the NAR to facilitate the forwarding of packets among themselves as well as to reduce the handover latency perceived by the MN during the handover. This is realized by the PAR sending a HI message to the NAR with the requested CoA on the NAR and the CoA being used currently at the PAR. In response, the PAR receives a HAck message from the NAR either accepting or rejecting the new CoA. If the new CoA is accepted by the NAR, the PAR sets up a temporary tunnel to the new CoA. Otherwise the PAR tunnels packets heading for the MN to the old CoA, which will be temporarily hosted by the NAR. In either case, the PAR does not forward packets until it has received a BU from the MN.
There are two mechanisms in FMIPv6. On receiving HAck message, the PAR will reply FBAck message to the MN. If the MN receives this message before its handover, the predictive mode of FMIPv6 will be enabled. Figure 2.4 shows the basic operation of the predictive fast handover for MIPv6. The predictive FMIPv6 makes the MN to move to the new subnet and receive packets from the NAR rapidly. If the MN does not receive FBAck message before it at-taches to the new AR, the reactive mode will be triggered. Figure 2.5 shows the basic operation of the reactive fast handover for MIPv6. In reactive mode, the MN has to wait for packet rerout-ing to be executed, and then it can receive packets from the NAR. The detailed explanations are described in [2].
MN PAR NAR RtSolPr HI HAck FBack FBack Data forwarding UNA Data delivery PrRtAdv FBU Disconnect Connect
Figure 2.4 Predictive Fast Handover with MIPv6.
MN PAR NAR RtSolPr HI HAck FBAck Data forwarding UNA Data delivery PrRtAdv FBU Disconnect Connect FBU
2.5 Fast Handovers for Hierarchical Mobile IPv6
In HMIPv6, when an MN moves between ARs within the same MAP domain, the handover process will happen between access routers. Although the location update time can be reduced in HMIPv6, there still have some problems such as handover latency and packet loss. Jung et al. proposes the FHMIPv6 [6] to reduce handover latency between access routers within the same MAP domain. In FHMIPv6, it introduces the handover scheme of FMIPv6 to perform the handover between ARs within the same MAP domain. When the MN roams within the same MAP domain, the MN only configures a new LCoA and registers this new LCoA at the MAP. The MAP then binds this new LCoA with the MN’s current RCoA. Thus, similar to HMIPv6, the MN does not need to register this new LCoA at the HA or CN. However, when an MN roams to different MAP domain, called the macro mobility or inter-domain handover, the MN must create a new LCoA and an RCoA. The MN first registers the new LCoA and RCoA at the new MAP, in which the MN’s new RCoA has replaced old RCoA and binds the new LCoA with the new RCoA. After updating the BCE at new MAP, the MN sends a BU message to its HA and CN to register the new RCoA. Accordingly, the inter-domain handover procedure using HMIPv6 or FHMIPv6 causes the packet loss and the long handover latency.
2.6 Fast Handovers for Proxy Mobile IPv6
In a PMIPv6 domain, it inevitably experiences the packet loss or handover latency until it attaches to the new MAG when an MN moves to a new access network. In recent years, several fast handover mechanisms have been proposed to reduce the handover latency and packet loss with PMIPv6. Xia [12] et al. proposed a method to improve the performance of the network-layer handover using FMIPv6 signal. The MN will provide the target base station information, e.g. target-BS (MAG) ID before it moves from the serving base station to the target base sta-tion. Based on this information, the MN gets the IP address of the target MAG and performs the network-layer handover process before the actual handover starts. However, this scheme has some limitations including that each MAG needs to know all MAGs’ IP address and BS-IDs beforehand, a packet ordering problem may occurs between the packets buffered at previous
MAG (pMAG) and the packets form the LMA after registration after a handover, and the MN needs to provide the information about target base station to pMAG through link-layer signal-ing. Yokota [5] et al. used FMIPv6 signaling to improve the performance of the network-layer handover, called FPMIPv6. Before an MN moves from the current serving MAG to the tar-get MAG, it needs to report the tartar-get AR’s information to previous AR using the link-layer handover signaling process. The PAR then performs network-layer handover and establishes the bidirectional tunnel with NAR using the information from MN’s handover indication. The detailed signaling flow is shown in Figure 2.6.
MN PAR LMA
Report
HAck
P-AN N-AN NAR
Handover indication HI Forward packets Forward packets Handover command Handover command disconnect connect Forward packets PBA PBU Forward packets
Figure 2.6 Predictive Fast handover with PMIPv6.
Figure 2.6 shows the signaling flow of the predictive fast handover procedures for PMIPv6. We do not show the reactive fast handover here because it is similar to FMIPv6. Suppose that an MN first connected to the PAR which has a bidirectional tunnel with a LMA for user data
of the MN. To complete the handover while the bidirectional tunnel is switched to the NAR, a data-forwarding tunnel is established between the PAR and the NAR, according to the following procedures:
1. before executing handover, the MN detects that a handover is imminent and reports its network identifier (MN-ID) and the target access point identifier (New AP ID) to which the MN is most likely to move;
2. the PAR begins preparations for the MN’s handover and sends the HI message to the NAR. The HI message must includes the MN-ID and include the MN’s home network prefix, the MN’s interface identifier (MN-IID) and the address of the LMA which is currently serving the MN;
3. on receiving HI message from PAR, the NAR replies the HAck message;
4. after the PAR receives HAck message from NAR, a bidirectional tunnel is established between PAR and NAR and all packet heading for the MN are forwarded from the PAR to the NAR via this tunnel;
5. the packet delivered by CN will be de-capsulated and buffered at NAR;
6. if the connection between the NAR and N-AN has already been established, those packets may be forwarded to the N-AN;
7. when the MN moves to the NAR domain, it establishes a connection with the N-AN. The connection will be established between the N-AN and NAR if it has not been established already;
8. after the MN is attached to the NAR, the NAR begins forwarding packets heading for the MN via the N-AN; and
9. the NAR sends the PBU message to the LMA, and then the LMA updates its BCE and replies PBA message to the NAR. Afterward the uplink and downlink packets can com-municate directly with the MN.
In FPMIPv6, the NAR may buffer the user data in its buffer resource before the MN is attached to the NAR. The user data buffered in NAR’s buffer resource are released when the NAR recognizes that the MN is attached. However, this scheme has some limitations:
• Each AR needs to have a tuple that contains the AP-IDs and IP address for all the ARs in
PMIPv6 domain.
• After a handover, the packet out-of order problem may occur between the packets buffered
at the PAR and the packets from the LMA after registration.
• The MN should provide information about the target access point identifier to PAR through
2.7 Summary
In Chapter 2, we briefly describe the handover procedure of MIPv6, PMIPv6 HMIPv6, FHMIPv6, and FPMIPv6. In Table 2.1, we present a summary of the main characteristics of host-based mobility protocol compared with network-based mobility protocol [4, 5], which we mentioned in previous sections. The detailed description for these mobility support protocols is provided in [1]-[6].
Table 2.1 Mobility Management Protocols Comparison.
Protocol Characterize MIPv6 HMIPv6 FMIPv6 FHMIPv6 PMIPv6 FPMIPv6 Mobility scope Global Local Global/Local Local Local Local Required infrastructure HA HA, MAP HA, AR HA, MAP, AR LMA, MAG HA, AR
MN modification Required Not Required
MN address HoA/CoA LCoA CoA LCoA HoA(always) HoA(always) Handover latency Bad Moderate Good Good Good Good Seamless handover Not supported Not supported Supported Supported Not supported Supported
Mobility Management Host-based Network-based
Duplicate
address Performed at every subnet movement Performed only one time detection (DAD)
Basically, FMIPv6 and its enhancement protocols such as FHMIPv6 and FPMIPv6 support seamless handover. On the other hand, MIPv6 and PMIPv6 do not support seamless handover. Furthermore, realizing successful deployment of MIPv6 and their enhancement protocols such as FMIPv6, HMIPv6, and FHMIPv6 basically requires the addition or modification of some functionality in both the network and MN sides. In contrast, PMIPv6 and FPMIPv6 do not require any modification on MN’s protocol stack.
Chapter 3
Proposed Scheme
In this chapter, in order to minimize the handover delay time and on-the-fly packet loss, we propose a handover procedure based on FHMIPv6 and PMIPv6, called Proxy-based Fast Handover for Hierarchical Mobile IPv6 (PFHMIPv6).
There are two modes of operations in PFHMIPv6. In the predictive mode, a bidirectional tunnel between the PAR and NAR is established before the MN’s attachment to the NAR. In the reactive mode, this tunnel is established after the MN’s attachment to the NAR. In order to avoid the on-the-fly packet loss during MN’s handover, the downlink packets for the MN have to be buffered at the NAR. It is hence required that all ARs have the capability and enough resources to buffer packets for the MNs to accommodate by them.
3.1 Network Architecture
LMA CN pMAP AP1 MN Internet AR1(PAR) AR3(NAR) nMAP AR2(NAR) AP2 MN MovementFigure 3.1 A handover scenario in proxy-based HMIPv6 domain.
Figure 3.1 illustrates a conventional scenario under the MAP in a visited network. The MAP acted as an anchor that provides seamless mobility management for the MN as it moves from Access Router 1 (AR1 or PAR) to Access Router 2 (AR2 or NAR), while communicating with the CN.
When MN moves from AR1 to AR2 under the previous MAP (pMAP) domain, this cir-cumstance is called intra-MAP domain handover. At this time, MN detects that a handover is forthcoming, so it reports MN ID and new Access Point ID (AP2 ID) to AR1, and then AR1 communicates with AR2 via bidirectional tunnel and updates the Binding Cache Entry in pMAP.
When MN moves from AR2 to AR3 under a new MAP (nMAP) domain, this circumstance is called inter-MAP domain handover. At this moment, the Access Router 3 (PAR) needs to update the Binding Cache Entry in nMAP and LMA. Afterward the packets destined for MN first forward to LMA then tunnel to nMAP, and subsequently tunnel to NAR. In this thesis, we only consider the intra-MAP domain handover.
3.2 Message Formats
The PFHMIPv6 framework requires minor modifications to the signaling messages in PMIPv6. In this section we define two extensions to the Proxy Mobile IPv6 protocol messages.
3.2.1 Local Proxy Binding Update Message
In PFHMIPv6 scheme, we first modified the PBU message, naming it the Local Proxy Binding Update (LPBU) message, by using a bit in reserved fields. An O (Local) flag is added to indicate that the AR requests the MAP to setup the tunnel. This message includes the MN’s home address. The rest of the Proxy Binding Update message format remains the same as defined in [4, RFC5213]. The LPBU message format is shown in Figure 3.2.
0 1 2 3 1 2 3 1 1 3 1 2 3 1 2 3 2 2 3 1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.2 LPBU message format.
3.2.2 Local Proxy Binding Acknowledgement Message
Secondly, we modified the PBA message, naming it the Local Proxy Binding Acknowledge-ment (LPBA) message, by using a bit in reserved fields. An O (Local) flag is added to indicate that the MAP replies the AR that the tunnel has been established. The rest of the Proxy Binding Acknowledgement message format remains the same as defined in [4, RFC5213]. The LPBA message format is shown in Figure 3.3.
0 1 2 3 1 2 3 1 1 3 1 2 3 1 2 3 2 2 3 1 2 3 1 2 3 3 1 2 3 3 3 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|O|Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.3 LPBA message format.
3.3 Proxy-based Fast Handover for Hierarchical Mobile IPv6
In this section, the proposed handover scheme over IEEE 802.11 network is shown for both predictive and reactive mode. It is assumed that the MN handover scenario is under the network architecture shown in the previous section. As shown in Figure 3.1, several scenarios can lead to a MN handover, and we discuss these handover scenarios in the following sections. Furthermore, for simplicity, we consider only one MN attached to the AR. In fact, there is no difference between one MN and multiple MNs in the proposed scheme.
3.3.1 MN Enters a New AR Domain
In the first scenario, a MN enters a new proxy-based HMIPv6 (PHMIPv6) domain. Figure 3.4 shows the message exchanges when the MN enters a PHMIPv6 domain. It is similar to PMIPv6 procedure, the RtrSol message from the MN may arrive at any time after the MN’s attachment. The detailed description of message exchanges is as follows:
1. when an MN enters a new PHMIPv6 domain and attaches to the AR on an access link, the AR identifies the MN and obtains its identity. After identifying the MN’s identity, the system will determine whether the MN is authorized for the network-based mobility
service. If the MN is authorized for network-based mobility service, the network will guarantee that the MN using any of the address configuration mechanisms permitted to obtain the address configuration on the connected interface and move anywhere in that PHMIPv6 domain;
2. in order to register current location of the MN and store this mapping in LMA, we de-fine a Local Proxy Care-of-Address (LPCoA) for each AR. LPCoA is the global address configured on the outgoing interface of the AR and is the transport endpoint of the tun-nel between the MAP and the AR. After the MN attached to the AR, it sends a LPBU message including MN’s HoA and AR’s LPCoA to the MAP;
3. upon accepting this LPBU message, the MAP views the LPCoA as the care-of-address of the MN and registers it in the binding cache entry for the MN, and then the MAP sends a PBU message to the LMA;
4. upon accepting this PBU message, the LMA replies a PBA message including the MN’s home network prefix to the MAP. At this time the LMA also creates the BCE and sets up its endpoint of the bidirectional tunnel to the MN’s MAP;
5. on receiving the PBA message, the MAP sets up its endpoint of the bidirectional tunnel to the LMA and start to forward MN’s traffic, and then sends a Local Proxy Binding Acknowledgement (LPBA) message including the MN’s home network prefix to the AR; 6. also, on receiving the LPBA message, the AR sets up its endpoint of the bidirectional tunnel to the MAP and forwarding for the MN’s traffic. At this point, the AR has all the required information for emulating the MN’s home network. The AR replies the RtrAdv message to the MN and advertises the MN’s HNP as the hosted on-link prefix.
MN MAP Rtr Sol LPBA (MN attached) LMA AR
(Acquire MN-Id and Profile) LPBU PBU PBA Forward packets (Allocate MN-HNP (s), set up BCE and Tunnel)
Rtr Adv
Figure 3.4 Signal Flow of Mobile Node Attachment.
3.3.2 MN Enters another AR under same MAP Domain
In the second scenario, the MN enters another PHMIPv6 domain under the same MAP. In this section, we discuss fast handover in both predictive mode and reactive mode.
3.3.3 Predictive Mode
Although packet buffering in FMIPv6 and FPMIPv6 avoids the on-the-fly packet loss, the MN still experiences the packet ordering problem. The reason is that the packets from the MAP after a new registration may arrive at MN before the buffered on-the-fly packets forwarded by the PAR. To solve the packet ordering problem, PFHMIPv6 uses an additional packet buffering at NAR to store the packets forwarded by MAP. In predictive fast handover of PFHMIPv6, the bidirectional tunnel will be established between the PAR and NAR before the MN attachment to the NAR.
Therefore, in order for the predictive fast handover to work efficiently, the MN requires ca-pable of reporting link-layer information, e.g. MAC address to the AN, and the AN is caca-pable of sending the HI message to the PAR at an appropriate timing. Figure 3.5 shows PFHMIPv6
handover procedure in predictive mode.
MN P-AN N-AN MAP
Report (MN ID, New AP
ID)
Handover Indication
(MN ID, New AP ID) HI (MN ID, MN-HoA, MN IID, MAP) HACK Handover command Handover command (Disconnect) (Connect) PAR NAR LPBU LPBA Forward packtes Forward packets
Buffer packets from PAR
(Setup BCE)
Forward packets
UNA
Buffer packets from MAP
Treport
Tproposed_pre
TL2
TUNA
Figure 3.5 Predictive Fast Handover with proposed scheme. The basic operation of predictive fast handover for PFHMIPv6 is as follows:
1. when a MN detected that a handover event is imminent, the MN reports its identifier (MN-ID) and target Access Point Identifier (t-AP ID) to which it is most likely to move to. The MN-ID could be the network access identifier, link-layer address, or any other suitable identifier. In this case, the MN-ID we used is link-layer address;
2. then the previous access network (P-AN) is the access point to which the MN is currently attached. P-AN sends a handover indication message including the MN-ID and New AP ID to inform the PAR of MN’s handover request;
3. the PAR derives the NAR from the t-AP ID, and sends an HI message to the NAR. The HI message includes the MN-ID, the HNP and the address of the MAP that is currently serving the MN;
4. upon receiving HI message, the NAR sends a Local Proxy Binding Update (LPBU) mes-sage to MAP. The LPBU mesmes-sage has the O flag bit set and includes the NAR’s address (LPCoA). In the meantime, the NAR replies HAck message to the PAR with P flag set; 5. a bidirectional tunnel is established between the PAR and NAR after receiving HAck
message. The packets heading for the MN are forwarded from the PAR to the NAR over this tunnel. After packet de-capsulation, those packets will be buffered at the NAR; 6. when the MAP received a LPBU message, the MAP replies a Local Proxy Binding
Ac-knowledgement (LPBA) message. The LPBA message has the O flag bit set and includes the MN’s HNP. It also creates the BCE and sets up its endpoint of the bidirectional tunnel to the NAR;
7. on receiving the LPBA message from MAP, the NAR sets its endpoint of the bidirectional tunnel to the MAP and then forwards the packet heading for the MN. After these packets are de-capsulated, they are also buffered at the NAR. At this moment, the NAR has all the required information for emulating the MN’s home network. It sends RtrAdv messages to the MN and advertises the MN’s HNP as the hosted on-link prefix;
8. when the MN performs a handover to the new access network, it establishes a physical link connection to the N-AN. If this link connection has not yet been established, it in turn triggers the link-layer connection establishment between the N-AN and NAR; 9. the NAR starts to forward packets heading for the MN via the new access network. Note
that the NAR first forwards packets which are buffered at the PAR, and then forwards packets which are buffered at the MAP.
3.3.4 Reactive Mode
In the case of the reactive handover for PFHMIPv6, the NAR sends the HI message to the PAR after the MN has moved to the new link. The bidirectional tunnel was established between the PAR and NAR after the MN attached to the NAR. The establishment of bidirectional tunnel requires the information of the PAR beforehand. The information should be provided by the MN sending the AP’s ID on the old link or by the link-layer procedure between P-AN and N-AN.
Figure 3.6 illustrates the reactive fast handover procedure for PFHMIPv6, where the bidi-rectional tunnel is established by the NAR. The detailed description of the message exchange is as follows:
1. the MN is detached from the previous access network, and then performs handover from the previous access network to the new access network;
2. the MN established a connection with the N-AN, which then establishes the connection with the NAR. The MN-ID is transferred to the NAR at this time for the following pro-cedures. The old AP’s ID is also transferred to the NAR to help identify the PAR on the new link;
3. to reduce the loss of on-the-fly packets which are sent from the LMA after MN’s detach-ment, the NAR sends an HI message which sets the P flag bit and includes the MN-ID to the PAR for the establishment of a bidirectional tunnel. At the same time the NAR also sends a LPBU message to MAP for the establishment of bidirectional tunnel between the NAR and the MAP. The LPBU message sets the O flag bit and includes the NAR’s address;
4. upon receiving the HI message, the PAR sends a HAck message back to the NAR with the P flag set. The HAck message includes the HNP that is corresponding to the MN-ID in the HI message and includes the MN’s link-layer address;
5. then a bidirectional tunnel is established between the PAR and NAR. The packets heading for the MN are forwarded from the PAR to the NAR over this tunnel, and then buffered
at the NAR after de-capsulation;
6. on the other hand, the MAP received the LPBU message of the NAR and replied a LPBA message. The LPBA message sets the O flag bit and includes the MN’s HNP. It also updates the BCE and sets its endpoint of the bidirectional tunnel to the NAR; and
7. after the NAR receives the LPBA message, the following procedure is same as that in predictive mode. The NAR first releases the buffered packets at the PAR, and then re-leases the buffered packets at the MAP. Since then, the packets heading for the MN are forwarded from the MAP to the NAR over this tunnel, and then delivered to the MN via the new access network.
MN P-AN N-AN MAP
HACK (Disconnect)
MN-NAR connection establishment (substitute for UNA and FBU) (Connect) PAR NAR HI Forward packets LPBU LPBA (Setup BCE) Forward packets Buffer packets
Chapter 4
Performance Analysis
In this chapter, we investigate the handover latency in our scheme. Here we conduct perfor-mance evaluation to compare the proposed scheme with the existing scheme. The goal of fast handover scheme is to reduce the handover latency.
4.1 Analytical Models
In order to evaluate the performance of the entire network, we analyze the handover latency. The Handover Latency, denoted by LT, is defined as the interval from the time that a link-layer handover is triggered from the MN to the time that the MN can communicate with the CN directly via the NAR without using tunnel. In this section, we design an analytical model to compare the handover latency. The network architecture used for analysis is presented in Figure 3.1. In this section, we only consider the predictive fast handover because the tunnel between PAR and NAR by the predictive scheme is established before link-layer handover, so it needs shorter time to perform handover than the reactive fast handover. Table 4.1 shows system parameters for analyzing each protocol.
Table 4.1 Parameters for performance analysis.
Notation Descriptions
TL2 Time consumed to perform layer 2 handover
TRtrSol Time consumed to perform Router Solicitation
T (A, B) Time required for a packet to pass from A to B
TPBU Time required to perform Proxy Binding Update to HA/LMA
TPBA Time required to receive PBA from HA/LMA
TLPBU Time required to perform Local Proxy Binding Update to MAP
TLPBA Time required to receive Local Binding Acknowledgement from MAP
TRtrSol Time consumed to receive Router Advertisement
Treport Time consumed to report the identifier of MN-ID and the New-AP-ID
TUNA Time required to perform Unsolicited Neighbor Advertisement
TFPpre
Time interval from the time point that packets cannot be sent and received to the time point that the MN detaches from the PAR
Tind Time consumed to indicate the handover of the MN to the PAR
THI Time consumed to send Handover Initiation
From Figure 3.5, we obtained the handover latency which includes four parts: L2 report (Treport), the time consumed for preparing tunnel (Tproposedpre), L2 handover (TL2), and TUNA,
where Treport is the time consumed to notify P-AN about MN-ID, Tproposedpre, TL2 and TUNA
are the time consumed to perform tunnel establishment, L2 handover and unsolicited neighbor advertisement respectively. From Figure 3.5, we can see that the time consumed for preparing tunnel will be the maximum of Tproposedpre and TL2. Therefore we can obtain the handover
latency for proposed scheme as follow.
LTproposed= Treport+ max(Tproposedpre, TL2) + TUNA. (4.1)
In Figure 3.5, the Tproposedpreincludes the time consumed for packet transmission from AP to
PAR, PAR to NAR, NAR to PAR, NAR to MAP and MAP to NAR. Thus we can obtain:
Tproposedpre= Tind+ THI+ THAck+ TLPBU+ TLPBA. (4.2)
For convenience, we consider the time interval for each notation as follows:
Tproposedpre=
T (AP, PAR) + T (PAR, NAR) + T (NAR, PAR) + T (NAR, MAP) + T (MAP, NAR). (4.3) and the handover latency for the proposed scheme will be:
LTproposed= T (MN, AP) + max(Tproposedpre, TL2) + T (AP, NAR). (4.4)
Figure 2.3 illustrates the handover latency for PMIPv6. The PMIPv6 handover procedure consists of five operations: perform L2 handover, sending the RtrSol message, sending the PBU message, sending the PBA message and sending the RtrAdv message. Therefore, we can obtain the handover latency for PMIPv6 as follow.
LTPMIPv6= TL2+ TRtrSol+ TPBU+ TPBA+ TRtrAdv, (4.5)
where TRtrSol is the delay between the MN and the MAG, TPBU is the delay between the MAG
between the MAG and the MN.
Also, we have the summarized handover latency for the PMIPv6 will be:
LTPMIPv6= TL2+ 2T (MN, MAG) + 2T (MAG, LMA). (4.6)
Figure 2.6 illustrates the latency for the fast handover in PMIPv6. From Figure 2.6, we can see that the PMIPv6 fast handover procedure consists of five operations: link-layer report, preparation for tunnel establishment, L2 handover, sending the UNA message, sending the PBU message and sending the PBA message. Therefore we can obtain the handover latency for fast handover in PMIPv6 as follow.
LTFP= Treport+ max(TFPpre, TL2) + TUNA+ TPBU+ TPBA, (4.7)
where Treport is the delay between the MN and the AP, TUNA is the delay between the AP and
the NAR, TPBU is the delay between the NAR and the LMA, and TPBA is the delay between the
LMA and the NAR. The delay of preparation for FPMIPv6 is as follows:
TFPpre = Tind+ THI+ THAck, (4.8)
where Tind is the delay between the AP and the PAR, THI is the delay between the PAR and the
NAR, THAckis the delay between the NAR and the PAR.
Therefore, we can summarize the handover latency for Yokota’s FPMIPv6:
LTFP= T (MN, AP) + max(TFPpre, TL2) + T (AP, NAR) + 2T (NAR, LMA). (4.9)
To compare the handover latency, it is assumed that there are N hops between the HA and the AR. In addition, we assumed the packet transmission delay on one hop is t. Because there is an AP between the AR and the MN, so the number of hops between NAR and MN is two. The improved ratio is defined asLT 1−LT 2LT 1 , which is used to estimate the extent that the proposed handover scheme can reduce the handover latency compared with the other handover schemes. In this thesis we compared our proposed scheme with the PMIPv6 and Yokota’s FPMIPv6 [5].
For the PMIPv6, the proposed scheme can improve handover latency by:
LTpmipv6− LTproposed LTpmipv6 =
TL2+ T (MN, NAR) + 2T (NAR, HA) − max(Tproposed, TL2) TL2+ 2T (MN, MAG) + 2T (MAG, LMA) ,
= 2 ∗ (N + 1) ∗ t
2 ∗ (N + 2) ∗ t + TL2. (4.10)
For Yokota’s FPMIPv6, the proposed scheme can improve handover latency by:
LTFP− LTproposed
LTFP =
max(TFPpre, TL2) − max(Tproposed, TL2) + 2T (NAR, HA)
T (MN, AP) + max(TFPpre, TL2) + T (AP, NAR) + 2T (NAR, LMA)
,
= 2 ∗ N ∗ t
2 ∗ (N + 1) ∗ t + TL2. (4.11)
4.2 Performance Comparison
In this section, we analyzed the handover latency for our proposed scheme and compare it with PMIPv6 and Yokota’s FPMIPv6. Based on Equations (4.10) and (4.11), we calculate the improved ratio of handover latency with assumption the link-layer delay in different cases [11]. Mishra et al. [11] present an empirical study of handover process at link-layer in various AP devices. In their experiments they used IEEE 802.11 wireless PC cards from different vendors, and they find that there is large variation in the link-layer delay with the particular AP-STA hardware being used. The variations in handover latency from 53 milliseconds (ms) to 420 ms depend on the AP-STA hardware vendors. Therefore, we consider three different link-layer delay cases into our analytical model. Figure 4.1 shows the improved ratio of handover latency with respect to Yokota’s FPMIPv6 in three different 802.11 link-layer delays, there are 50 ms in the best case, 150 ms in average case and 400 ms in the worst case.
%& '()* '&+, -./0 1 '2 *3&4*5&)* '&+,-.6/0 1'2 784'()*'&+, -.900 1 '2 : : ; < = : : ::::: : : ;: <: = : ; <= >?@ AB CDEF DGHAB IJB B KLMN ON P %& '()* '&+, -./0 1 '2 *3&4*5&)* '&+,-.6/0 1'2 784'()*'&+, -.900 1 '2
Figure 4.1 The improved ratio of handover latency.
From Figure 4.1, if the number of hops between the LMA and the AR are 10, it can improve 28% in the best case and 5% in the worst case. After we examined the network topology in 2010, there are approximate 10 hops between Hsinchu and Taipei. The distance between these two cities is about 70 killometers. As the number of hops between the LMA and the AR increase to 30, the handover latency can be improved 54% in the best case and 13% in the worst case.
Figures 4.2 and 4.3 show the improved ratio of handover latency for the proposed scheme compared with Yokota’s FPMIPv6 and PMIPv6 respectively. The link-layer delay we assumed is 150 ms for WiFi and 200 ms for WiMAX. Supposing the number of hops between the LMA and the AR is less than 5, the improved ratio of handover latency is about 7% for WiFi and 5% for WiMAX respectively. However, if the number of hops between LMA and AR is more than 30, then we could gain a significant improved ratio of handover delay which is larger than 30% and 25% for WiFi and WiMAX respectively. Therefore, we conclude that the larger a LMA distant from an AR, the more handover latency can be improved.
$% & ' $% & ' () *+ ,-. /0. 12+ ,34,,56 78 98: $% & ' $% & '
Figure 4.2 The improved ratio of handover latency compared with FPMIPv6.
!"# $% &' $% &' ( )*+ ,-./0. 12+,3 4 , ,567898 : !"# $% &' $% &'
Chapter 5
Simulation and Results
In this chapter we evaluate the performance of the proposed handover scheme using the NS-2 simulator [14]. For the comparison with standard PMIPv6 and Yokota’s FPMIPv6, we first depict the simulation scenario and then compare the handover latency in different simulation mode.
5.1 Simulation Scenarios
In this simulation, IEEE 802.11b is used as MAC protocol for all ARs, which has a 250 me-ter (m) transmission range and 11Mbps link bandwidth. A constant bit rate (CBR) application sent by the CN with 0.008 second interval and the packet size is 1000 bytes. Both CN and the HA are connected to an intermediate node (N1) with 2 ms delay, 100Megabits/s (Mbps) links. To emulate the network topology that the HA is distant from the AR, there is a link between N1 and MAP, which is a 100Mbps link with 50 ms delay. Under the MAP, it is considered as the local network. The MAP is connected to 3 intermediate nodes (N1, N2, N3) with 50 ms delay, 100Mbps link, 2 ms delay, 100Mbps link and 2 ms delay, 100Mbps link respectively. N2 is con-nected to the PAR while N3 is concon-nected to the NAR, all with 2 ms delay, 100Mbps links. All links use the Random Early Detection (RED) queue, except links from the intermediate nodes to the NAR and PAR, which are Drop-tail (FIFO) queues. The ARs are set to 80 meters apart with free space environment in between. This reduces the complexity of analysis result, as we
HA CN N1 MAP N2 N3 PAR NAR 2ms/100Mbps 2m s/1 00M bps 2ms/1 00Mb ps 2ms/100M bps MN 2ms/100Mbps 50m s/1 00M bps 2ms/100Mbps move
Figure 5.1 The network topology for simulation.
only need to consider signal interference. We assume the use of IEEE 802.11b as our access technology and the effective coverage area is set to 20 meters in radius. The wireless link speed is 11Mbps. Figure 5.1 shows the network topology for this simulation.
5.2 Experimental Results
In this section, we compare our proposed scheme with standard PMIPv6. In order to test our proposed scheme in predictive mode and reactive mode properly, we change the speed of MN forced our simulation switch into predictive mode and reactive mode.
5.2.1 Predictive Mode
In predictive mode, we set the MN to start from PAR and move to NAR with a speed of 10m/s. CBR over UDP traffic sent from the CN to the MN and the total duration for the sim-ulation is 20 seconds. For examining the packet loss, we give each packet a sequence number and keeping track of packet sequence number that MN received. The simulation results of pre-dictive fast handover for each protocol are shown in the following figures.
!" #$%# & '
Figure 5.2 The packet sequence number in predictive fast handover with PMIPv6.
!" #$%# &'
Figure 5.3 The packet sequence number in predictive fast handover with FPMIPv6.
Figures 5.2 and 5.3 show the UDP sequence of MN in standard PMIPv6 and Yokota’s FP-MIPv6 respectively. We just focus on the time period between 8.5 and 10.0 second because the entire handover procedure occurs at this time. In Figure 5.2, we can see that the standard
PMIPv6 has the on-the-fly packet loss during a handover because there is no buffering mech-anism, and the MN experiences the handover latency about 483 ms until MN is attached to NAR at 9.48 seconds. In Figure 5.3, Yokota’s FPMIPv6 has no packet loss due to buffering mechanism and the MN experiences a disruption time of about 396 ms. The disruption time was reduced in Yokota’s FPMIPv6 because of tunneling mechanism. Even though Yokota’s FPMIPv6 uses packet buffering at the PAR to avoid the on-the-fly packet loss, it still experi-ences 484 ms handover latency and some out-of-ordered packets at 9.48 seconds. The reason of the out-of-ordered packet problem is because Yokota’s FPMIPv6 cannot distinguish whether a packet was sent by the PAR via tunnel or sent directly by the NAR.
!" #$ %#&'
Figure 5.4 The packet sequence number in predictive fast handover with proposed scheme.
Figure 5.4 shows the UDP sequence of MN in our proposed scheme. We can see that it has no on-the-fly packet loss during a handover because the buffering mechanism, the PAR forwards the packets heading for MN and buffered at the NAR via tunnel before handover procedure is finished. In order to solve the out-of-ordered packet problem, our proposed scheme maintains an additional buffer to separate those packets from the NAR and the PAR. The NAR first send the buffered packets which forwarded by the PAR, and then send the buffered packets which come
from the MAP. In our simulation, the proposed scheme applied the hierarchical architecture to the standard PMIPv6 domain, the NAR performs the binding update procedure and sends a LPBU message to the MAP rather than the HA after the MN attached to the NAR. It reduces the handover latency effectively. The PAR sends a PBU message to the local MAP rather than a remote HA. In Figure 5.4, the handover latency is reduced to 374 ms until MN attaches to NAR at about 9.37 seconds.
5.2.2 Reactive Mode
In reactive mode, the handover procedure is performed after the MN attached to the NAR. We switched our simulation to reactive mode by setting the speed of MN to 30m/s. The total duration for the simulation is still 20 seconds but the handover event occurs earlier at about 5.0 seconds because the speed of MN is much faster. For examining the packet loss, we only focus on the time interval between 4.5 seconds and 6.0 seconds and we give each packet a sequence number and keep tracking of packet sequence number that MN received. The simulation results in reactive fast handover for each protocol are shown in the following figures.
!" #$ %#&'
!" #$ %#&'
Figure 5.6 The packet sequence number in reactive fast handover with FPMIPv6.
Figure 5.5 shows that the MN experiences about 483 ms handover latency and 60 packets loss in PMIPv6. From Figure 5.6, although Yokota’s FPMIPv6 uses the tunneling mechanism to reduce the disruption time, Yokota’s FPMIPv6 experiences longer handover latency because it has to wait the link-layer handover finish for establishing the tunnel. The MN cannot receive any packet until it is attached to the NAR at about 5.40 seconds. The disruption time was re-duced to 398 ms and the packet loss was rere-duced to 48 packets, but the handover latency is increased to 499 ms. Also, Yokota’s FPMIPv6 has some out-of-ordered packets at about 5.5 seconds.
!" #$ %# & '
Figure 5.7 The packet sequence number in reactive fast handover with the proposed scheme.
The simulation of the proposed scheme is shown in Figure 5.7. We can see that the handover latency is reduced to 389 ms because of the local MAP architecture. Moreover, the proposed scheme has no out-of-ordered packet during a handover because the tunnel between the MAP and the NAR is established earlier than the PAR and the NAR, so that the packet heading for MN will be forwarded to NAR beforehand. For hierarchical network architecture, the NAR performs the binding update procedure and sends LPBU message to the MAP rather than the HA after the MN is attached to the NAR, it can shorten the signaling cost. Although the handover latency was reduced, the proposed scheme still has about 46 inevitable on-the-fly packets loss during the handover, because the tunnel establishment between the PAR and the NAR is performed after the MN attached to NAR.
Figure 5.8 compares the handover latency with the other schemes, and it shows the handover latency in predictive mode and reactive mode respectively. Note that the link-layer delay is 378
ms in our simulation because of NS-2 module. In the predictive mode, the standard PMIPv6
has about 483 ms handover latency while Yotoka’s FPMIPv6 also has about 484 ms handover latency. On the other hand, our proposed scheme reduces the handover latency to 374 ms. Obviously the handover latency is reduced by about 23%. In the reactive mode, the standard PMIPv6 has about 482 ms and Yotoka’s FPMIPv6 has about 499 ms handover latency while our proposed scheme has about 389 ms. Hence, the handover latency was reduced by about 22%.
!" #$" %$&'( &)* +,-, !" . / &'(&)* 0% ,0 , 1$ 23141 5 5
predictive mode reactive mode
!" #$" %$&'( &)* +,-, !" . / &'(&)* 0% ,0 , 1$ 23141
! ! " # $%&$ '(
Figure 5.9 The comparison of handover latency between disruption time.
Figure 5.9 illustrates much detailed handover latency for the proposed scheme, Yokota’s FP-MIPv6 and standard PFP-MIPv6. The upper part is reactive mode while the lower part is predictive mode of these three schemes. The handover latency includes link-layer delay, network-layer delay and the time consumption to establish the tunnel. We can see that the link-layer han-dover latency, about 380 ms, dominates the whole hanhan-dover latency. In this thesis, our proposed scheme effectively reduces the network-layer delay because the tunnel establishment and local binding update are performed simultaneously.
