English  |  正體中文  |  简体中文  |  Items with full text/Total items : 52068/87197 (60%)
Visitors : 8906053      Online Users : 308
RC Version 7.0 © Powered By DSPACE, MIT. Enhanced by NTU Library & TKU Library IR team.
Scope Tips:
  • please add "double quotation mark" for query phrases to get precise results
  • please goto advance search for comprehansive author search
  • Adv. Search
    HomeLoginUploadHelpAboutAdminister Goto mobile version
    Please use this identifier to cite or link to this item: http://tkuir.lib.tku.edu.tw:8080/dspace/handle/987654321/74729


    Title: 新的機制架構於HMIPv6以增進換手效率在重複位址發生時以達成快速換手之研究
    Other Titles: A novel mechanism to improve handover efficiency considering the duplicate address occurs in HMIPv6
    Authors: 陳宇翔;Chen, Yu-Hsiang
    Contributors: 淡江大學電機工程學系碩士班
    李維聰
    Keywords: 移動IPv6;重複位址檢測;階層式IPv6;快速重組位址機制;MIPv6;HMIPv6;DAD;Mobility management;F-RAM
    Date: 2011
    Issue Date: 2011-12-28 19:23:49 (UTC+8)
    Abstract: 隨著通訊網路技術的快速發展,越來越多的通訊設備,包括手機、PDA、Notebook…等,都具備了可以連結上網的功能,而為了達到Anytime、Anywhere的隨時上線(Always on Line)的目標,在3G網路中對於移動性的支援將會是一個重要的議題。而移動性不只存在於核心網路,也存在於無線網路中。
    在最近幾年來,有許多的研究和討論關於Mobile IPv6(MIPv6),而Mobile Node(MN)在各個不同網路之間的換手延遲,更是值得被探討的問題,在MIPv6換手的過程中造成延遲的原因有三個,移動的偵測(Movement Detection)、重複位址檢測Duplicate Address Detection(DAD)、註冊更新Binding Update(BU)、其中DAD所花費的時間更是造成MIPv6換手延遲的主要原因。這個時間對於即時性的運用是非常大的延遲時間。
    此外,在先前的文獻中並沒有深入探討關於在重複位址檢測的過程中,如果產生的轉送位址Care of Address(CoA)已經被其他的節點使用的話,該怎麼重組一個CoA,以及接下來的換手流程,怎麼產生一個確保獨一無二的CoA使得在換手時能夠更快速,減少換手延遲,避免封包的遺失。如果沒有一個機制去應對這樣的情形,會使得MN在換手時造成更大的延遲時間以及更多封包的遺失。
    因此本論文提出了快速重新組成位址機制Fast-Reconfigure Address Mechanism (F-RAM),使得產生的CoA如果有重複的話可以迅速產生一個確保獨一無二的CoA。避免有二次重複的情形發生。我們考慮了如果位址有重複的情形下,該如何快速的重組一個CoA,使換手的流程並不會因為位址的重複造成更大的延遲時間。我們的實驗結果顯示我們的方法在遇到位址重複的情況時,確實可以減少換手的延遲時間。
    Recently, there have been a lot of research about Mobile IPv6(MIPv6).Mobile Node (MN) in the handover delay between different network is the issue which should be investigated .
    In the MIPv6 handoff delay caused during the three reasons, 1.Movement Detection 2.Duplicate Address Detection (DAD) 3.Binding Update (BU). DAD which time spent is mainly caused by MIPv6 handover delay. This time for real time use is a very big delay.
    In addition, in the previous literature did not explore in depth on the duplicate address detection process, if the Care of Address (CoA) has been the other nodes used, how to reconfigure a CoA and then the hanover process, how to generate a unique CoA made to ensure that when the handover can be more quickly and reduce the handoff delay to avoid packet loss. If there is no mechanism to deal with such situations, would make even greater when the MN in the handover latency and packet loss.
    Our approach is based on (Hierarchical Mobile IPv6) HMIPv6 architecture. We establish an address table in the Mobility Anchor Point (MAP). The address table will store all access to the network address information. When MN access to the new network will creates a nCoA, and then you can confirm whether this nCoA are unique by address table. So, our approach does not have to perform DAD, just have to confirm whether nCoA unique in the address table. If there is duplication, then we must start the F-RAM mechanism for the MN to re-configure a nCoA and to ensure the nCoA is unique
    Therefore, this paper presents a Fast-Reconfigure Address Mechanism (F-RAM).If the CoA duplicate, it Can quickly generate a unique CoA to avoid a second duplication occurred. We consider that if there is duplication address, how to quickly reconfigure a unique address. So that the handover process will not cause even greater delay time when duplicate address occur. Our results show that our propose scheme in case of duplicate address, the exact time can reduce the handover delay
    Appears in Collections:[電機工程學系暨研究所] 學位論文

    Files in This Item:

    File SizeFormat
    index.html0KbHTML139View/Open

    All items in 機構典藏 are protected by copyright, with all rights reserved.


    DSpace Software Copyright © 2002-2004  MIT &  Hewlett-Packard  /   Enhanced by   NTU Library & TKU Library IR teams. Copyright ©   - Feedback