• 沒有找到結果。

VoIP聚合環境之行動性與互用性的支援

N/A
N/A
Protected

Academic year: 2021

Share "VoIP聚合環境之行動性與互用性的支援"

Copied!
102
0
0

加載中.... (立即查看全文)

全文

(1)國立交通大學 資訊工程系 博 士 論 文. VoIP 聚合環境之行動性與互用性的支援 Mobility and Interoperability Supports for VoIP Converged Environments. 研 究 生: 張弘鑫 指導教授: 曾建超 教授 張明峰 教授. 中 華 民 國 九 十 五 年 六 月. i.

(2) VoIP 聚合環境之行動性與互用性的支援 Mobility and Interoperability Supports for VoIP Converged Environments 研 究 生: 張弘鑫. Student: Hung-Hsin Chang. 指導教授: 曾建超. Advisor: Chien-Chao Tseng. 張明峰. Ming-Feng Chang. 國 立 交 通 大 學 資 訊 工 程 系 博 士 論 文. A Dissertation Submitted to Department of Computer Science College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Computer Science and Information Engineering June 2006 Hsinchu, Taiwan, Republic of China. 中華民國九十五年六月. ii.

(3) 國. 立. 交. 通. 大. 學. 博碩士論文全文電子檔著作權授權書 本授權書所授權之學位論文,為本人於國立交通大學 資訊工程 系所 ______組,. 94. 學年度第. 2. 學期取得碩士. 學位之論文。 論文題目:VoIP 聚合環境之行動性與互用性的支援 指導教授:曾建超、張明峰 教授 ■ 同意 □不同意 本人茲將本著作,以非專屬、無償授權國立交通大學與台灣聯合 大學系統圖書館:基於推動讀者間「資源共享、互惠合作」之理 念,與回饋社會與學術研究之目的,國立交通大學及台灣聯合大 學系統圖書館得不限地域、時間與次數,以紙本、光碟或數位化 等各種方法收錄、重製與利用;於著作權法合理使用範圍內,讀 者得進行線上檢索、閱覽、下載或列印。 論文全文上載網路公開之範圍及時間: 本校及台灣聯合大學系統區域網路. ■ 中華民國 95 年 6 月 8 日公開. 校外網際網路. ■ 中華民國 95 年 6 月 8 日公開. 授 權 人:張弘鑫 親筆簽名: 中華民國. 95 年. 6 月. 8 日. iii.

(4) 國. 立. 交. 通. 大. 學. 博碩士紙本論文著作權授權書 本授權書所授權之學位論文,為本人在國立交通大學 資訊工程 學 院 資訊工程 系所 _________ 組 94 學年度第 2 學期取得碩士學 位之論文。 論文題目:VoIP 聚合環境之行動性與互用性的支援 Mobility and Interoperability Supports for VoIP Converged Environments 指導教授:曾建超、張明峰 教授 ■ 同意 本人茲將本著作,以非專屬、無償受權國立交通大學,基於推動讀 者間「資源共享、互惠合作」之理念,與回饋社會與學術研究之目 的,國立交通大學圖書館得以紙本收錄、重製與利用;於著作權法 合理使用範圍內,讀者得進行閱覽或列印。. 授權人:張弘鑫 親筆簽名: 民國. 95 年. 6月. 8日. iv.

(5) 國家圖書館 博碩士論文電子檔案上網授權書 ID:GT008717806 本授權書所授權之論文為授權人在國立交通大學 資訊工程 學院 資訊工程 系所 _________ 組 94 學年度第 2 學期取得碩士學位之 論文。 論文題目:VoIP 聚合環境之行動性與互用性的支援 Mobility and Interoperability Supports for VoIP Converged Environments 指導教授:曾建超、張明峰 教授 茲同意將授權人擁有著作權之上列論文全文(含摘要) ,非專屬、無 償授權國家圖書館,不限地域、時間與次數,以微縮、光碟或其他 各種數位化方式將上列論文重製,並得將數位化之上列論文及論文 電子檔以上載網路方式,提供讀者基於個人非營利性質之線上檢 索、閱覽、下載或列印。. ※ 讀者基於非營利性質之線上檢索、閱覽、下載或列印上列論文,應依著作權法 相關規定辦理。. 授權人:張弘鑫 親筆簽名: 民國. 95 年. 6月. 8日. v.

(6) 國立交通大學 資訊工程系博士班 論文口試委員會審定書 本校 所提論文:. 資. 訊. 工. 程. 系. 張 弘 鑫 君. VoIP聚合環境之行動性與互用性的支援. 合於博士資格水準、業經本委員會評審認可。 口試委員:. 指導教授:. 系主任:. 中 華 民 國 九十五 年 四 月 十九. vi. 日.

(7) Department of Computer Science College of Computer Science National Chiao Tung University Hsinchu, Taiwan, R.O.C. Date: April 19, 2006. We have carefully read the dissertation entitled Mobility and Interoperability Supports for VoIP Converged Environments submitted by Hung-Hsin Chang in partial fulfillment of the requirements of the degree of Doctor of Philosophy and recommend its acceptance.. vii.

(8) Abstract in Chinese. VoIP 聚合環境之行動性與互用性的支援 指導教授: 曾建超 教授 張明峰 教授. 學生:張弘鑫. 國立交通大學資訊工程學研究所博士班 摘. 要. 隨著網路技術及終端設備的快速發展,未來的網路電話(VoIP)的環境將傾向於發展成 為一個支援多類網路的聚合環境。這些網路將包含公眾交換網路(PSTN)、公用陸地行動 通訊網(PLMN)、有線(Wire-line)交換網路及無線(Wireless)交換網路。但在目前,要發展 這樣的聚合網路,仍存在著一些問題。例如不同通訊信令(Signaling)之間的互通、穿越 位址轉換器(NAT)的問題、交遞的問題、加密金鑰的傳遞問題及計費問題都仍需克服。 本篇論文重點在探討互通性及行動交遞問題。 不同網路電話信令的互通是最根本需要解決的問題,不同的機構已經發展或定義出 許多不同的信令規格,例如 H.323、MGCP 及 SIP。然而,在目前使用不同信令的電話 設備仍無法互通。NAT 穿越問題也會阻礙同信令或不同信令之間的互通。現今許多的 設備因為缺乏實體 IP 位址(Public IP),紛紛改採虛擬 IP 位址(Private IP)而變成隱藏在 NAT 之後。造成信令交換過程中,不管是通話發起或是接收端,會因無法得到正確的 網路位址而致無法通訊。 再則,無線通訊技術的進展以及 SIP 在行動上的支援,使用者或終端設備可以在通 話過程中間,改變其網路連接點而且仍能保持繼續通話。這過程稱為交遞(Handover),. viii.

(9) 它除了變更網路連接點(一般稱為 Access Point,AP)之外,仍包含有網路位址的改變以 及通知對方更新網路位址的信令交換。這一連串的過程相當的長久,對於 VoIP 這類的 及時應用會讓使用者感覺到中斷,所以必須要設計一機制來加速交遞過程。 行動通訊中有一個註冊伺服器(Registrar)來記錄使用者目前所在的位置(或網路位 址)。交遞時除了通訊中的彼此需要位址更新之外,更必須要將新的位址重新登錄到註 冊伺服器,以便新的通話能夠再接通。然而,這個資料庫因為會經常性的被讀取及更新, 有可能會產生錯誤或損毀,如此,找不到使用者的位置以致無法建立通話。 本篇論文發表了一系列的解決方案來克服上述的諸多問題。用一個簡單又富有彈性 的方法,利用 half-call model 來簡化設計並減少因新的通訊協定的加入所需的額外修 改。在 NAT 穿越問題上,我們將應用層閘道器(Application level gateway, ALG)的概念從 NAT 中分離出來,所以此方法僅需更動到 Proxy,而不需修改 NAT 及使用者設備。我 們也另外發展了一套利用服務網域的位置資訊進行快速網域交遞的協定,採用跨階層式 的設計,大大減少交遞時所需花費的時間。最後,再針對位置資訊資料庫的毀損問題, 我們分析了多種資料庫回復的方法,並比較其回存成本(Checkpoint)及通話斷訊成本 (Lost-call)之間的關係。我們發現,資料庫的回存與否與此兩成本之間的比重是有相關 的,若通話斷訊成本較高,並不需要使用到很複雜的回存機制,使用簡單的復製資料庫 (Duplicated)的方法,就能達到最佳效益。. 關鍵字: 通話狀態模型,互通性,SIP,H.323,MGCP,NAT 穿透,交遞,AP 探索,跨 階層設計,位置資料庫,個人化回存,詢呼成本. ix.

(10) Abstract. Mobility and Interoperability Supports for VoIP Converged Environments student:Hung-Hsin Chang. Advisors: Dr. Chien-Chao Tseng Dr. Ming-Feng Chang. Department of Computer Science National Chiao Tung University ABSTRACT As the network and terminal technologies advance, the future Voice over IP (VoIP) environment is likely to be a converged infrastructure that consists of Public Switch Telecommunication Networks (PSTNs), Public Land Mobile Networks (PLMNs), Wire-line Packet-switched Networks, and Wireless Packet-switched Networks. However, in such VoIP converged environments, there exist several problems, such as signals interoperability, NAT traversal, handover delay, key distribution, and billing, which remain to be solved. This dissertation focuses on the mobility and interoperability supports for the VoIP converged environments. The interoperability of different VoIP signaling protocols is one of the most important problems for the future VoIP converged environment. Several signaling protocols, such as H.323, SIP and MGCP, have been developed by different organizations to support VoIP communications. A device using a signaling protocol cannot operate with other devices using a different signaling protocol. NAT traversal is another interoperability problem for SIP-based VoIP applications. In a VoIP converged environment, devices may situate behind an enterprise network with an NAT router due to the lack of public IP addresses and/or the administration purpose. For a device beneath an NAT router, it cannot establish, whether it initiates the communication or not, a VoIP session with another device. Previous solutions to this NAT traversal problem require. x.

(11) changes to the NATs and/or SIP user agents. Moreover, wireless technologies and SIP mobility make it possible for a device to change its network attachment from one point to another (henceforth referred to as handover), while retaining its VoIP session. The handoff procedure also includes sending user location update messages to both the correspondent node and the registrar for SIP-based VoIP applications. Such a handover process is considerably long and may cause serious interruption to the real-time VoIP session. Therefore a fast and smooth handover mechanism is a necessity for a VoIP converged environment. Moreover, a registrar maintains the locations of VoIP users in a database, called user mobility database; users who wish to communicate with others should query the registrar to acquire the locations of the communication peers first. However, the user mobility database in a registrar may crash; causing call requests to fail. Therefore, failure recovery of the user location databases is another important issue for the mobility supports in VoIP converged environment. In this thesis, we present a series of solutions to the aforementioned problems. We first propose a simple, flexible framework for interworking gateway for different VoIP signaling protocols; the framework is based on a half-call model to reduce the design and implementation effort. For the NAT traversal problem, our method makes SIP proxies act like an application gateway and thus requires modification only to SIP proxies. Therefore our NAT traversal mechanism is more practical because it leaves NAT routers and SIP user agent programs intact. We also propose a novel topology-assisted cross-layer handover mechanism that can effectively reduce the overall handover delay of a VoIP session from several seconds to less than 120 ms. Finally, we study several user mobility database checkpoint methods and find that in most conditions the optimum checkpointing interval is either zero or infinity. That is to say, a user location record should either be always checkpointed at the registration, or be never checkpointed at all, depending on the weighting factor of checkpointing cost and that of lost-call cost. Keyword: call state model, interworking, SIP, H.323, MGCP, NAT traversal, handover, AP probe, cross layer design, Mobile IP, location database, per-user checkpointing, paging cost. xi.

(12) Acknowledgement. I would like first to thank my two instructors Chien-Chao Tseng and Ming-Feng Chang. Especially for Tseng who have been guiding me from my early 20s to late 30s. Having their advice, I know how to do researches and state results formally and precisely. During my first three years, both economic and emotional hardships came to me. Therefore, little progress was made. My family has always been the most powerful bolster and leads me to the fulfillment. Please allow me to deeply appreciate all my friends, they share with me in joy and sad and encourage me at any given time. Thank my colleagues in Chin-Min Institute of Technology for their help freeing me from tedious committee meetings. Special thank to Mr. Yeh, chairman of the ShinWay Co., for his financial aid easing my economic difficulty. Respect should be phrased to my father-in-law for his full support my PhD studentship. No doubt I must acknowledge greatly to my wife for her nonstop love and patient, so I could focus myself in research, for which I am eternally grateful. Finally, I dedicate this achievement to my father, who left me in my 5th PhD year.. xii.

(13) Contents. Abstract in Chinese ..............................................................................................................viii Abstract ..................................................................................................................................... x Acknowledgement ................................................................................................................. xii Contents .................................................................................................................................xiii List of Figures......................................................................................................................... xv List of Tables......................................................................................................................... xvii Chapter 1 Introduction ............................................................................................................ 1 Chapter 2 Background............................................................................................................ 5 2.1 VoIP protocols ........................................................................................................... 5 2.1.1 H.323 ............................................................................................................... 5 2.1.2 SIP ................................................................................................................... 7 2.1.3 MGCP.............................................................................................................. 8 2.1.4 IN Basic Call State Model........................................................................... 10 2.1.5 Interoperation ............................................................................................... 11 2.2 NAT traversal ........................................................................................................... 12 2.2.1 NAT ................................................................................................................ 12 2.2.2 Application-aware NAT solutions............................................................... 13 2.2.3 Application-unaware NAT solutions .......................................................... 14 2.2.4 Locating a VoIP user inside a NAT ........................................................... 15 2.3 Fast handoff ............................................................................................................. 16 2.3.1 Handoff procedures..................................................................................... 17 2.3.2 Mobile IP handoff......................................................................................... 19 2.3.3 Analysis handoff delays .............................................................................. 21 2.3.4 Cross-Layer topology information ............................................................. 22 2.4 User mobility database........................................................................................... 25 2.4.1 Re-registration.............................................................................................. 25 2.4.2 Checkpointing and restoration................................................................... 26 Chapter 3 Integrated call agent ........................................................................................... 28 3.1 Integrated call agent architecture ......................................................................... 28 3.1.1 Interworking gateway .................................................................................. 28 3.1.2 Integrated call agent.................................................................................... 30 3.2 Mapping of VoIP protocol messages to the BCSM messages ........................ 31 3.2.1 Uniform events ............................................................................................. 31 3.2.2 H.323 slow-start ........................................................................................... 33 3.3 Implementation and result ..................................................................................... 35 Chapter 4 VoIP's NAT traversal........................................................................................... 37 4.1 NAT traversal architecture ..................................................................................... 37 4.2 NAT type decision ................................................................................................... 38. xiii.

(14) 4.3 Locate an internal user .......................................................................................... 38 4.3.1 Without a public SIP proxy ......................................................................... 39 4.3.2 With a public SIP proxy............................................................................... 39 4.4 Transport address translation ............................................................................... 40 4.5 Scenarios for call establishment........................................................................... 42 Chapter 5 Topology-aided fast handoff .............................................................................. 46 5.1 LAMP scheme ......................................................................................................... 46 5.1.1 Registration and pre-allocation.................................................................. 48 5.1.2 Handoff .......................................................................................................... 49 5.2 The integrated cross-layer fast handover ........................................................... 50 5.2.1 Predicted bi-casting..................................................................................... 50 5.2.2 AP direct association................................................................................... 51 5.3 Mobile IP handoff .................................................................................................... 52 5.3.1 Using Foreign-Agent CoA .......................................................................... 53 5.3.2 Using Co-located CoA ................................................................................ 54 5.4 Implementation and result ..................................................................................... 56 5.4.1 SIP handoff ................................................................................................... 56 5.4.2 Mobile IP handoff......................................................................................... 59 Chapter 6 Mobility database restoration ............................................................................ 62 6.1 Three checkpointing algorithms............................................................................ 62 6.1.1 Periodically checkpointing the modified record....................................... 62 6.1.2 Lin's per-user checkpointing algorithm with an exponential timer ....... 63 6.1.3 Lin's per-user checkpointing algorithm with a fixed checking interval. 64 6.2 Cost function analysis ............................................................................................ 64 6.2.1 FIXED ............................................................................................................ 65 6.2.2 LINEXP.......................................................................................................... 67 6.2.3 LINFIX ........................................................................................................... 68 6.3 Results...................................................................................................................... 69 6.3.1 Simulation result .......................................................................................... 71 Chapter 7 Conclusions ......................................................................................................... 75 7.1 Integrated call agent ............................................................................................... 75 7.2 VoIP's NAT traversal............................................................................................... 76 7.3 Handoff ..................................................................................................................... 76 7.4 HLR ........................................................................................................................... 77 Chapter 8 Future work .......................................................................................................... 78 Reference ............................................................................................................................... 79. xiv.

(15) List of Figures. Figure 1. Converged VoIP communication environment. ...................................................... 1 Figure 2. A simple H.323 architecture.................................................................................... 6 Figure 3. An H.323 message flow to set up a call.................................................................. 7 Figure 4. A generic SIP architecture....................................................................................... 8 Figure 5. An SIP message flow to establish a session............................................................ 8 Figure 6. MGCP architecture. ................................................................................................ 9 Figure 7. An MGCP message flow to establish a call. ......................................................... 10 Figure 8. IN architecture. ..................................................................................................... 10 Figure 9. Simplified IN BCSMs........................................................................................... 11 Figure 10. Latencies of a handoff......................................................................................... 17 Figure 11. Link-layer handoff procedures and delays.......................................................... 18 Figure 12. Network-layer handoff procedures and delays. .................................................. 18 Figure 13. Application-layer handoff procedures and delays............................................... 19 Figure 14. Mobile IP handoff in the FA-CoA case............................................................... 20 Figure 15. Components developed for a general VoIP gateway........................................... 29 Figure 16. A SIP/H.323 gateway. ......................................................................................... 29 Figure 17. A converged VoIP network using gateways. ....................................................... 30 Figure 18. A converged VoIP network managed by integrated call agents. ......................... 31 Figure 19. An example of H.323 and MGCP interworking using 2 ICAs. .......................... 31 Figure 20. Mapping VoIP messages to BCSM messages..................................................... 32 Figure 21. BCSMs for the H.323 slow-start......................................................................... 34 Figure 22. Call flow of H.323 (slow-start) and SIP interworking........................................ 35 Figure 23. Components used in our platform....................................................................... 36 Figure 24. Call establishment delays.................................................................................... 36 Figure 25. The NAT traversal for VoIP environment. .......................................................... 38 Figure 26. User registration without a public SIP proxy. ..................................................... 39 Figure 27. User registration using a public SIP proxy.......................................................... 40 Figure 28. NAT hole punching. ............................................................................................ 42 Figure 31. LAMP architecture.............................................................................................. 47 Figure 32. The registration and pre-allocation procedures................................................... 49. xv.

(16) Figure 33. Registration and pre-allocation procedures using a dedicated LS...................... 49 Figure 34. Combined handover procedures by applying the proposed cross-layer solutions. ............................................................................................................ 52 Figure 35. Message flow for the FA-CoA case. ................................................................... 53 Figure 36. Message flow for the CCoA case........................................................................ 56 Figure 37. The Mobile IP handoff experimental setup......................................................... 59 Figure 38. Three per-user checkpointing algorithms. .......................................................... 63 Figure 39. Two consecutive checkpoints (FIXED). ............................................................. 65 Figure 40. Two possible cases of checkpointing (LINEXP). ............................................... 67 Figure 41. Comparison of checkpointing algorithms for exponential registration interval................................................................................................................ 71 Figure 43. The effects of timer expiration interval. ............................................................. 73 Figure 42. Cost functions for various weighting factors (exponential registration interval). ............................................................................................................. 71 Figure 44. The effects of registration interval variance. ...................................................... 73 Figure 45. Cost function for various weighting factors and different variance of registration interval. ........................................................................................... 74. xvi.

(17) List of Tables. Table 1. An example of a network deployment table. .......................................................... 48 Table 2. Internal procedures of an SIP UA for initiation, call establishment and handover. ............................................................................................................ 57 Table 3. Measurement results of handover delays before the proposed improvements....... 58 Table 4. Summary of the reduced delays by using different mechanisms. .......................... 58 Table 5. Handover delays by applying the proposed improvements.................................... 58 Table 6. Means and standard deviations of handoff delay and the number of lost packets in different settings................................................................................ 61. xvii.

(18) xviii.

(19) Chapter 1 Introduction. Current network technology helps information exchanging between network nodes via the well-connected Internet within a few second. This information not only includes plain texts but also multimedia data such as the digitized voice/video data that are converted by encoding and compressing methods. The high bandwidth and high transmission rate over the network enable the digitized voice data to reach the destination without much delay, so that a user can hear the reproduced voice in real-time as if the voice was just produced. One important real-time application is the telephony communication, also referred to as VoIP (Voice over IP). Integrated Call Agent. PSTN. CN. SIP Proxy. Internet. Registrar. Internet. Roam. NAT. Location Database. MG. GateKeeper UA. SIP. H.323. MGCP. Figure 1. Converged VoIP communication environment. To support VoIP communications, many signaling protocols such as MGCP (Media Gateway Controller Protocol), H.323 and SIP (Session Initiation Protocol) have been developed. They use sophisticated speech codecs (G.723.1, G.729, and so on.) to reduce the bandwidth required for a call and use RTP/RTCP (Real-time Transfer Protocol/Real-time Transfer Control Protocol) to transport digitized voice packets over IP networks. Using. 1.

(20) RTP/RTCP to transmit and reproduce the voice from digitized packet, VoIP application can withstand the delay, jitter, and out-of-order arrival of the packets due to the network transmission behavior that is based on best-effort delivery. Since these signaling protocols are expected to co-exist in the near future, users of VoIP applications are divided into several groups that cannot communicate with each other because of the incompatibility of the signaling protocols. To enable communications between different groups of VoIP application users, gateways between the different VoIP protocols are needed. The gateways have to perform two functions — signaling conversion and media conversion, because the signaling protocols are different, and the voice media are transmitted in different formats. However, traditional gateways are implemented in a brutal manner that transforms signaling from one protocol to another protocol, so that there are many mutual gateways such as H.323-to-SIP, SIP-to-MGCP and H.323-to-MGCP. It is very inconvenient to install all these gateways together to support the interworking functions of VoIP protocols. Hence, it is necessary to find an easy way to implement a gateway so that VoIP will be easy to install and can be used for supporting all existing signaling protocols. Two VoIP users exchange their terminal capabilities (such as codecs and compression algorithm) and transport addresses (i.e., the port and IP address for receiving RTP packets) before they establish a VoIP call. Two uni-directional connections are then created to transmit digitized voices and the call is established. Yet, as the number of VoIP users booming, more and more users are hidden by NATs (Network Address Translators) and adopt private IP addresses due to the shortage of public IP addresses, they share a common public IP address on the public side of the NAT. The private IP addresses are banned by the Internet, so that any packets designated to a private address will be dropped. It poses the problem of NAT traversal that a VoIP user using a private transport address cannot receive either call request or voice packets from the Internet; their packets are abandoned and their communications are blocked. Many researchers have devoted to the NAT traversal problem. Also, different solutions were proposed to solve different NAT types according to the NAT specification. An application-aware solution enables NATs to interpret the payloads of VoIP signaling. 2.

(21) messages and replace the private transport addresses with a unique external location. Another approach is an application-unaware solution where the modifications are made to user application and leave the NAT unchanged. In fact, schemes of those approaches made changes to the NAT and user software may not be tangible, because they are usually under the control of the Internet service providers or enterprises. Therefore, a practical way for NAT traversal problem should not make changes to either NATs or user agent programs. For VoIP users, there has been a trend of using handheld devices and roaming between IEEE 802.11 wireless local area networks (WLANs). Although WLANs have been widely deployed as an infrastructure providing high-speed data services to mobile users, offering VoIP services on WLANs is still considered problematic due to an inherent limitation of the IEEE 802.11 MAC protocol — the considerably long handoff process. Moreover, handoff may also involve activities at higher layers. If the handoff entails changing network domains (referred to as an inter-domain handoff), the mobile user needs to acquire a valid IP address using schemes such as DHCP (Dynamic Host Configuration Protocol) in the new network domain. If Mobile IP is used for network-layer mobility management, the mobile user should change its mobility agent and perform registration accordingly (henceforth referred to as a layer-3 handoff). These two steps cause large amount of delay. Nevertheless, VoIP applications are time-sensitive and cannot tolerate long layer-2 plus layer-3 handoff delays. In order to maintain the desired quality of services demanded by VoIP or real-time multimedia applications, the overall handoff latency should be minimized. Many studies have made to reduce the handoff delays. Unfortunately, previous works mainly concentrate on the improvement on a single layer such as link or network layer, and lack of cross-layer considerations and enhancements. In addition to the handoff delay problem, the handoff also poses a user location-tracking problem when a roaming user changes his location from time to time. Usually, a mobile user have to register his recent location to a service agent (such as an SIP registrar) that stores user location to a database, so that other users may know his location by querying this service agent and issue a call request to him. If the mobility database fails, calls to mobile users. 3.

(22) cannot be set up. Henceforward, the service agent should perform user paging to locate the user and rebuild the mobility database; this leads to fairly large cost. One way to solve the call loss problem is to enhance the reliability of the mobility database. For UMTS (Universal Mobile Telecommunications System), the mobility database is periodically checkpointed to a non-volatile storage. Several algorithms have been used to find out the optimal checkpointing interval that minimizes the total cost of checkpointing cost and lost-call cost. In this thesis, we present a series of solutions to the aforementioned problems. A simple, flexible framework for implementing interworking gateways among several VoIP signaling protocols was proposed to achieve a converged VoIP network. This framework is based on a basic call state machine (BCSM) that is used in the intelligent network (IN). We also propose an NAT traversal method to help the VoIP application to operate in an NAT environment without any modification to NATs or VoIP user applications; this method is also applicable to different NAT types. For the handoff delay problem, a topology-aided cross-layer fast handoff mechanism is developed. By integrating the base station information and the relationship between the base stations and the service agents, our mechanism can significantly reduce the handoff delay to less than 120ms, which is considered unperceptible to real-time communications. In addition, we have analyzed several user mobility database restoration methods. Our study finds that there doesn't need a sophisticated checkpointing algorithm. A user location record should either be always checkpointed at the registration, or be never checkpointed at all, depending on the weighting factor of checkpointing cost and that of lost-call cost. The remainder of this thesis is organized as follows. Chapter 2 gives detailed description and causes of the VoIP problems solved in the thesis. Chapter 3 discusses previous related work on those problems. Chapter 4 through chapter 7 elaborates our solutions to those problems. Chapter 8 gives the result. Conclusions and future work are in the Chapter 9.. 4.

(23) Chapter 2 Background. 2.1 VoIP protocols The PSTN (Public Switched Telephone Network) has provided reliable voice communication for decades. A telephone call to anyone in the world can be established in seconds, and the voice quality is good in general. Voice waveform transmitted in the PSTN is encoded using PCM (pulse-code modulation, G.711 A-law and u-law, both 64kbps) technique. To establish a telephone call between two parties, a dedicated link needs to be set up, and the link has to be torn down when the call terminates. This work is performed by telephone switches exchanging standard signaling, such as ISUP (Integrated Services Digital Network User Part). As the Internet becomes overwhelmingly widespread, transporting voice communication traffic using the Internet Protocol (IP) provides advantages over the traditional PSTN. This is often referred to as IP telephony or VoIP (Voice over IP). VoIP can use sophisticated speech codecs, such as G.723.1 and G.729 [1], to reduce the bandwidth required for a call. VoIP communications use RTP/RTCP to transport voice packets over IP networks. To establish a call, the two parties involved should negotiate the codec and the RTP/RTCP [2,3] ports used for the call, as well as exchange messages to set up and terminate the call. H.323 and SIP are two existing VoIP signaling protocols. Both are designed to support the setup, communication capacity exchange and tear-down of a VoIP call. 2.1.1 H.323 H.323 [4] is an ITU-T recommendation for multimedia conferencing over packet-switched networks. It is a protocol umbrella that consists of many standards, including Q.931 call control protocol, H.225 registration and administration, and H.245 media negotiation. NetMeeting of Microsoft and VoIP products from Cisco all support H.323 multimedia communications over packet-switched networks. A simple H.323 environment is depicted at. 5.

(24) Figure 2. H.323 defines a gatekeeper as a manager and arbiter over a network. The gatekeeper is an optional entity in charge of endpoint registration, address translation, and bandwidth assignment. A call setup between two H.323 endpoints needs a large amount of signaling exchange. A gatekeeper can participate in the signaling exchange (a gatekeeper-routed call) or do not involve (a direct call). Figure 3 shows a message flow for a direct call that includes administrative messages (authentication request/confirm, ARQ/ACF), call setup signaling (SETUP, CALLPROC, ALERTING and CONNECT) and capability negotiation (H.245 capability exchange and logical channel opening). H.323 GateKeeper. Internet TM3. TM3. H.323 Endpoint. TM3. H.323 Endpoints. Figure 2. A simple H.323 architecture. One of the major criticisms against H.323 is the time and complexity involved in setting up a call; H.323 version 1 uses multiple stages to exchange signaling and media capabilities. Moreover, messages are transported using TCP, which requires additional session set-up time. Recent H.323 versions can include both signaling and media capabilities in a single message transmitted by UDP [5], which eliminates the additional round-trip time for TCP handshake. However, with too many options within the signaling messages, H.323 still has compatibility problems for the products from different providers.. 6.

(25) Terminal1. H.323 GateKeeper. Terminal2. ARQ ACF SETUP CALLPROC ARQ ACF ALERTING CONNECT H.245 Capability Exchange H.245 Open Logical Channel RTP streams. Figure 3. An H.323 message flow to set up a call. 2.1.2 SIP SIP (Session Initiation Protocol, [6]) has been standardized by IETF for initiating interactive communication sessions between users. It can be used to establish Internet telephony calls. With six text-based commands: REGISTER, INVITE, ACK, OK, INFO, and BYE; SIP is a lightweight and text-based protocol and is simpler than H.323 and other signaling protocols. It has been widely adopted by communication standards such as 3GPP and 3GPP2. With early media capability exchange feature, a SIP terminal can issue only one command, INVITE, to set up a call. Therefore, it is faster than H.323 in call establishing and many consider SIP a powerful alternative to H.323. The network components of an SIP application are depicted in Figure 4. An SIP user agent (UA) that is a user endpoint runs on a desktop PC or a mobile node (MN), and it issues or receives session establishment requests. An SIP UA has to register with an SIP registrar using a REGISTER message. The SIP registrar maintains the user profile such as the subscript information and the user's URL location. Finally, an SIP proxy relays SIP messages on behalf of SIP UAs or other SIP proxies.. 7.

(26) SIP Registrar. Internet SIP Proxy. PX1. PX2. UA1. UA2. UA3. SIP User Agent. Figure 4. A generic SIP architecture. Figure 2 shows a typical message flow for establishing a SIP session. Without loss of generality, we assume that UA2 has already registered with the SIP registrar. As shown in the figure, UA1 sends a REGISTER message registers with the SIP registrar via an SIP proxy, and the SIP registrar grants the registration by replying an OK message. After then, if UA1 wishes to request a call to UA2, UA1 issues an INVITE message to UA2. In the meantime, UA1 prepares a RTP channel for receiving voice stream from UA2. Once UA2 accepts the session request, UA2 creates a RTP channel according to the capabilities described in the payload and replies an OK message to UA1. UA1 further sends an ACK message to confirm the success of session establishment. Aftermath, voices are digitized into packets and sent to each other through the RTP channels. UA1. SIP Proxy. REGISTER. SIP Registrar. REGISTER OK. INVITE. OK INVITE. OK ACK. UA2. OK. ACK. RTP streams. Figure 5. An SIP message flow to establish a session. 2.1.3 MGCP To enable communications between VoIP users and PSTN users, gateways between the PSTN and IP-based networks are needed. Since the signaling used in the VoIP networks and. 8.

(27) the PSTN are different, and the voice media are transmitted in different formats, the gateways have to perform two functions: signaling conversion and media conversion. The two functions can be carried out in two separated entities: MGC (Media Gateway Controller) and MG (Media Gateway). An MGC (also referred to as a CA, Call Agent) performs the signaling conversion function, and an MG performs the media conversion function. A standardized protocol can be used between an MGC and MGs. IETF proposed the MGCP (Multimedia Gateway Control Protocol, [7]) architecture depicted in Figure 6. MGCP is a master-slave protocol. A CA is a master and has control over several MGs; an MG acts as a slave and is kept simple and passive. A CA also performs the call control function as a gatekeeper in H.323, but has much tighter control. A CA instructs an MG to establish, maintain, and terminate a call between a VoIP terminal and an endpoint in the PSTN. CA. MGCP. Internet. PSTN. RTP MG. Figure 6. MGCP architecture. The message exchange for connecting a call in MGCP is more complex than SIP and H.323 because the MG is passive. A typical message flow for establishing a call between two MGCP endpoints are depicted in Figure 7. For the detail of the message flow readers are referred to the MGCP specification. MGCP is based on a centralized network infrastructure. To serve to a wide area network, a group of CAs needs to coordinate, but MGCP does not specify how the CAs interact. Signaling used in inter-CA communications can be SIP or ISUP. MGCP describes the media capability and parameter using SDP (Session Description Protocol, [8]). Recently Megaco (or H.248, [9]), an enhanced version of MGCP, is promoted jointly by the IETF and ITU-T.. 9.

(28) MG1. Endpoint1. CA. Endpoint2. MG2. Off Hook NTFY. Dial Tone. OK. RQNT OK. Digit. NTFY OK CRCX OK Ring Tone. RQNT RQNT. Ring OK. OK. Off Hook. NTFY OK CRCX. MDCX Stop Ring Tone. OK. OK RTP streams. Voice. Voice. Figure 7. An MGCP message flow to establish a call. 2.1.4 IN Basic Call State Model An intelligent network (IN, [10]) separates the service logic from the switching function in the telecommunications network; the service intelligence is placed in computer nodes that are distributed throughout the network. This provides the network operators with the means to develop and control services more efficiently. New capabilities can be rapidly introduced and customized for the network. A simple IN architecture is depicted in Figure 8. A service switching point (SSP) is an IN-capable switching system dealing with the call control functions that establish, maintain, and clear a call. In addition, it detects user requests for IN-based services and queries a service control point (SCP) to determine how the call should be handled. The SCP contains the service logic to provide the IN services. SCP SCP. STP SSP SSP. SSP SSP. Figure 8. IN architecture. The basic call control function of an SSP is supported by a finite state machine (FSM) called basic call state model (BCSM). The BCSM consists of point in calls (PICs), detection. 10.

(29) points (DPs), and events. PICs represent the switching activities or states that a call goes through from call origination to termination. DPs are states at which transfer of control from the SSP to the SCP can occur. Events are messages exchanged between BCSMs, and trigger state transitions of the BCSMs. Figure 9 shows that the BCSM is based on half-call model; a call model consists of two half-call models: the originating BCSM (O_BCSM) and terminating BCSM (T_BCSM). The O_BCSM represents the states associated with the call originating party; the T_BCSM represents the states associated with the call terminating party. Note that the originating and terminating BCSMs interact with the call parties using ISUP messages. The call control functions are performed through the exchange of events between the O_BCSMs and T_BCSMs. These events include Setup, Alert, Answer, Disconnect, Busy, No-Answer, and Abandon. For details, the readers are referred to [10]. O_Null ISUP messages. Setup. O_Collect_Info O_Routing. T_Null T_Present_Call. Alert. T_Alerting. ISUP messages. Answer O_Active. T_Active Disconnect. O_Disconnect Originating BCSM. T_Disconnect Events. Terminating BCSM. Figure 9. Simplified IN BCSMs. 2.1.5 Interoperation Since H.323 and SIP are expected to co-exist in the near future, gateways between H.323 and SIP terminals are needed for the interworking function between H.323 and SIP. EURESCOM proposed a project for providing IN functionality for H.323 telephony calls [11]. Vemuri described an inter-operation model called SPHINX (SIP, H.323 and IN interworking) where H.323 and SIP terminals can access IN services [12]. In addition, an SIP-H323 gateway is a byproduct of this inter-operation model based on the half-call state model of the IN. Agrawal, Singh and Schulzrinne [13,14] specified the requirements for SIP-H.323 interworking. Gurbani and Rastogi [15] and Haerens [16] suggested ways to map the call. 11.

(30) control of SIP to IN, but they did not support the H.323 slow-start call setup. Ackermann, et al., have implemented a sip-h323 gateway as a basis for supplementary service interworking [17]. They use a dedicated call model that transfers H.323 messages to SIP messages, and vice versa. Jiang et al. have presented a Columbia InterNet Extensible Multimedia Architecture (CINEMA) where MGCP and H.323 can be interworking through SIP [18]. Nevertheless, it is difficult to modify this call model to cooperate with other VoIP protocols.. 2.2 NAT traversal 2.2.1 NAT The NAT (Network Address Translation Protocol, [19]) provides a way to alleviate the need of the IP address space due to the Internet booming. It enables hosts beneath a NAT (internal host) to share one common IP address for creating network connections to hosts on the Internet (external host). The NAT replaces the source address and port as its IP address and a dynamically allocated port in the IP header in the outgoing packet. Therefore, the correspondent host believes that the connection is originated from the NAT. Within a NAT connections are identified by the bindings between internal hosts' source ports and NAT's outgoing ports. So, the NAT can pass the replied packet destined to the NAT to the exact internal host. The IP header of the replied packet is restored accordingly. Though NATs are operated in port oriented, not all the inbound packets arrived at the binding port on a NAT will be redirected to the internal host. The NAT is further classified as full cone, restrict cone, port restrict, and symmetric NAT according to their port binding rules and delivery restrictions. The rule for the former three NAT types to create address binding is the same, where all requests from the same internal IP address and port are associated to the same port binding. However, delivery restrictions are different. A full cone NAT allows return packets to the internal host from any external host as long as the packet is sent to the associated port. A restrict cone NAT is similar to a full cone one except that an external host can send a packet to the internal host only if the internal host had previously sent a packet to it. A restricted cone NAT maintains a database so as to track which hosts have been visited. A. 12.

(31) port restricted cone NAT is like a restricted cone one, but the restriction includes port numbers. A symmetric NAT is more restrictive and secure. Every connection uses a different port binding. Furthermore, only the destination host is allowed to return packets back to the internal host. Usually, users inside a NAT employ private IPs that are reserved by the Internet Assigned Numbers Authority (IANA, [20]). Since private addresses have no global meaning, routing information about private networks will not be propagated. Thus, any packet addressed to these private IP addresses will be ignored. Consequently, connections originated from an external host to an internal host are forbidden and the NAT traversal problem is formed. The impact of the traversal problem also includes the retention of port bindings, where there is no guarantee that the NAT implementation will keep the port binding for a long time [21]. In addition, locating an internal user is difficult because internal users under different NAT may use the same private IP address. These problems hinder the deployment of VoIP applications. 2.2.2 Application-aware NAT solutions An application-awareness NAT means that a NAT has the ability to interpret application payloads and create port bindings on demand. An application-aware NAT acts as a translator that translates application packets back and forth and as a router that routes packets between internal hosts and external hosts. This is also referred to as an application level gateway (ALG [22]). An ALG is application dependent, so that it requires special handling for each VoIP application. Kuthan and Rosenberg [23] suggested decomposition of application-awareness from the NAT. An ALG becomes an intermediate device and controls address processing and associations by communicating with a NAT through a generic application-independent firewall control protocol (FCP). The FCP allocates and releases NAT port binding. Such solution is also known as Middlebox Communications (MidCom [24,25]) where the Middlebox is a device that locates between different realms or networks. Example Middleboxes are NATs. A MidCom agent (an ALG) is a logical entity that is external to a. 13.

(32) Middlebox, handling the application specific processing and communicating with one or more Middleboxes. For example, a SIP proxy can embed a MidCom agent and may communicate with NATs or firewalls to request port bindings. Clearly, this method makes changes to the NATs and is impractical because it is impossible to upgrade the all the NATs on the Internet. 2.2.3 Application-unaware NAT solutions An application-unaware NAT solution leaves NATs unchanged. Rosenberg et al. suggested such a solution called STUN (Simple Traversal of UDP through NAT, [26]). A STUN server is an external host and acts as a MidCom agent to learn the external NAT transport address of an outbound connection issued by an internal STUN client and report the learned port and address to the STUN client (this procedure is referred to as a port-learning). Two STUN servers can be used to determine what NAT type an internal STUN client resided by performs sequences of tests for the port binding rule and delivery constraint of the NAT. If the NAT is a full-cone one, the internal user can proceed the call request and use the learned external transport address as its RTP receiving address since the full-cone NAT will relay any incoming packets reached at the bound port to the internal user. A fortified version of STUN, called TURN (Traversal Using Relay NAT, [27]), was proposed to conquer the constraints of the symmetric NAT type. It uses an external server (TURN server) to relay the packets into a NAT. An internal user may request the TURN server to allocate a pair of transport addresses on the TURN server; one is used as user's destination RTP transport address, and the other is used as a relay transport address that the user host creates an outbound connection to it and receives inbound RTP packets from it. Hereafter, the TURN server receives the inbound RTP packets coming into the destination port and pushes them out of the relay port into the NAT. In STUN and TURN, though NATs remain intact, the user agent program should be STUN/TURN enabled and turn off the silence suppression to keep the port binding on NATs. This requires changes to the VoIP application software.. 14.

(33) 2.2.4 Locating a VoIP user inside a NAT To allow inbound calls, internal users are required to register at a registrar (such as SIP Registrar or SIP Proxy) with routable addresses, so that they can be located. J. Rosenberg et al. [28] suggested employing a STUN server to learn an external signaling address from the outbound REGISTER message out of a NAT as a contact address for call parties. Once the external signaling port binding on the NAT is created, a keep-alive packet should be periodically sent, or the signaling address may expire. Thus, an inbound call request can go through the NAT to the internal user. Unfortunately, not only lots of keep-alive traffic is brought in, but also this external signaling address is not worked for the internal user within a symmetric NAT due to the stern restrictions. Davies et al. [29] mandated a SIP proxy (a TURN-like server) to allocate transport addresses for relaying both signaling and RTP packets into a NAT. They also introduced a proxy interface agent (PIA) inside a NAT to intervene the call establishment between internal users and the SIP proxy. Internal users consider as if they are communicating with the PIA. The PIA acts on behalf of one or more internal users and establishes calls with the external users. As a result, inbound RTP packets from an external user are first sent to the SIP proxy, then relayed via the NAT to the PIA, and finally delivered to the internal user. Meanwhile, outbound RTP packets also follow the same way in the reverse direction. A notable drawback is the performance deterioration due to an additional hop-count of the RTP packets via the PIA. Sen proposed another solution that made changes to the SIP protocol [30]. First, a Behind-NAT tag is added to the REGISTER message indicating a user is behind a NAT. If the tag is set, the SIP proxy should take the source IP address of the REGISTER packet as the user' public address rather than the address specified in the message body. Second, a SIP PING message is introduced for the purpose of keeping the communication path alive between the internal user and the external SIP proxy. Thus, an inbound call request can be delivered to the internal user.. 15.

(34) Sen's method does not need a broker to setup a call. Obviously, an internal user takes care of the NAT traversal problem. The internal user must use symmetric RTP, which sends and receives RTP packets at the same port, and acquire a relay transport address from the media proxy as its source and destination RTP connection. That is to say, the internal user sends RTP packets through a NAT to the media proxy, and then the media proxy relays those packets to the other call party. The symmetric RTP benefits inbound packets to travel into a NAT because the outbound packets have created a port binding for them. The above solutions somehow change the user agent software, the signal proxy, NAT, or all of them, and mandate the coexistence of a signal proxy. Some even alters the protocol. Since those programs and servers are the productions of some companies and may be difficult to be modified at our wish, it seems impractical to implement those solutions in the near future.. 2.3 Fast handoff For ubiquitous Internet accesses, a mobile device is expected to equip multiple wireless interfaces and to roam within an IEEE 802.11 wireless system and/or among heterogeneous wireless systems. The handoffs might involve a few to dozens of procedures, and introduce variant delays depending on the types of handoffs, such as inter-system or intra-system handoffs, and/or link-layer or network-layer handoffs. For instance, a mobile node (MN) moving from one access point (AP) to another AP without changing its IP address, i.e. a link-layer handoff, needs to spend around 300ms to detect the lost of the signal from the original AP, to search and then to re-associate with a new AP [31]. However, if the handoff invokes the IP change of an MN, namely a network-layer handoff, other than the link-layer procedures, the network handoff further requires an MN to acquire network resources, such as an IP address, and to inform the corresponding node (CN) to re-establish a new network connection [32]. In this case, the handoff delay might increase to several seconds. During handoff procedures, network connections between two peer nodes are temporarily lost, and packet delays are thus introduced. For real-time applications such as voice over IP. 16.

(35) (VoIP) and video on demand (VoD), which are sensitive to delays and delay jitters, the handoff latency influences service qualities, and poses a serious problem from a user’s perspective. According to the International Telecommunication Union (ITU) specification [33], less than 150ms handoff delay is recommended for any mobile communication system. 2.3.1 Handoff procedures The handoff process of wireless real-time communications consists of the aforementioned link, network, and application layer handoff procedures that involve various handoff delays, denoted as tLK, tNW and tAPP respectively. Figure 10 shows the handoff latencies of wireless real-time communications based on DHCP (Dynamic Host Configuration Protocol, [34]) and SIP mobility. Link-layer Handover tLK. Network-layer Handover tNW. Application-layer Handover tAPP. AP switch. IP assignment (DHCP). SIP re-invite. Handover tHandover. Figure 10. Latencies of a handoff. Figure 4 shows the delay of an 802.11 link-layer handoff. The link-layer handoff delay consists of a probe, an authentication and an association delays that are denoted as tProbe, tAuth, and tAssoc respectively as shown in the figure. An MN starts a link-layer handoff by performing a probe phase to discover the next AP to associate with. The probe phase would normally introduce a considerable delay because the MN needs to scans channels to find a preferred AP, which is normally the AP with the strongest signal strength. The probe delay depends on both the number of channels the MN scans and the time the MN works with any particular channel. The time the MN works with a channel is further depending on the minimum channel time tWmin that an MN will wait for any AP response after the MN sends a probe request on the channel, and the maximum channel time tWmax that the MN will stays on the channel for other AP responses if it receives an AP response before tWmin elapses After discovering a preferred AP, the MN performs authentication and association. 17.

(36) procedures with the AP as specified in the IEEE 802.11 standard. Although, there are many different authentication approaches such as WPA (Wi-Fi Protected Access, 802.1x [35]) and WPA2 (802.11i [36]) can be used, these authentication approaches perform additional access-right checking through the Internet and further cause delays. Therefore, they are not considered in this paper. We assume the standard 802.11 authentication method is applied. The delay of a link-layer handoff is summarized in Figure 11. tWmax tWmin. tWmin ocia tion. tica tion. .... Au t he n. q. Pr o beR e. Pr o beR e. sp eR e Prob esp eR Prob. q. .... APn. Ass. AP1. MN tProbe. tAuth. tAssoc. tLk. Figure 11. Link-layer handoff procedures and delays. A handoff between two APs that belong to different sub-networks may cause an IP transition. This handoff requires further performing a network-layer handoff procedure, in addition to the link-layer handoff procedure. Once an MN detects the sub-network change, it tries to acquire a new IP address via DHCP. Therefore, the network-layer handoff latency is composed of the time for the subnet change detection (tDetec), IP acquisition (tDHCP) and. que st P re. disc o DHC P. DHC. tDHCP. ok. tDetec. P DHC. MN. fer P of DHC ffer Po DHC. DHCP server. v er y. IP/Gateway configuration (tConf), and is depicted in Figure 12.. tConf. tNW. Figure 12. Network-layer handoff procedures and delays. Afterward the MN needs to follow the procedures that are specified by different application-layer protocols to inform the CNs its new location. The SIP mobility requires. 18.

(37) MNs to perform SIP registration and to re-establish connections to the CNs in order to receive RTP packets from the MN’s new location. Figure 13 shows the procedures and their delays, i.e. SIP registration delay (tReg), SIP re-invite delay (tUpdate), packet sending and receiving. tAPP. RTP. VIT E e-IN SIP r. tUpdate. RTP. tReg. K. S REG IP IST ER. CN O SIP. MN. tRecv. OK SIP. SIP Proxy. OK SIP. SIP Registrar. S REG IP IST ER. delays (tSend, tRecv).. tSend. Figure 13. Application-layer handoff procedures and delays. 2.3.2 Mobile IP handoff Mobile IP (MIP, [46]) is an Internet standards-track protocol that enhances the existing IP protocol to accommodate host mobility. In MIP, a special host called mobility agent (MA) maintains registration information for mobile nodes. When an MN moves away from its home network, the MA located in the MN's home network, referred to as the MN’s Home Agent (HA), will tunnel packets for the MN. Tunneled packets are usually, though not always, handled by the MA on the MN's visiting network called Foreign Agent (FA). With the intervention of HA and FA, an MN away from home network can retain its connection to the Internet. MIP offers two options on care-of address (CoA) that identifies an MN in the visited network: foreign-agent CoA (FA-CoA) and co-located CoA (CCoA). FA-CoA is usually an IP address of the FA. If an MN registers an FA-CoA with the MN’s HA, the FA is responsible for intercepting all tunneled packets destined for the MN and delivering the de-tunneled packets directly to the MN. If the MN uses a CCoA, which is an IP address belonging to the visited network, the MN itself will receive and handle all tunneled packets. When an MN detects that the current serving FA (cFA) is no longer accessible, it will. 19.

(38) initiate a layer-3 handoff from cFA to the next FA (nFA). A layer-3 handoff consists of three phases — agent discovery, address configuration and registration phases. If FA-CoA is in use, the MN must discover nFA first and then register with the MN’s HA through nFA (Figure 14); otherwise, the MN must acquire a CCoA through some external means, such as DHCP, before it can start a registration process. 1. Agent Discovery: This concerns how an MN is made aware of the presence of nFA. Every MA can be uniquely identified by its AgentAdvertisement message. An MN may either listen to AgentAdvertisement messages broadcasted periodically by nFA or actively issue an AgentSolicitation message to request an advertisement. 2. Address Configuration: This concerns how an MN obtains its new CCoA, which is usually achieved by way of DHCP. 3. Registration: This informs the HA of an MN’s CoA. If an FA-CoA is in use, the MN issues a RegistrationRequest message to nFA, where the message is then forwarded to the HA. If a CCoA is used, the MN sends this message directly to the HA. The HA replies. a. RegistrationReply. to. the. MN. to. confirm. the. registration.. The. RegistrationRequest will be relayed by nFA if an FA-CoA is in use. MN. cFA. nFA. HA. Agent Solicitation Move Detection. Agent Advertisment. Registration Request. Registration Request Registration Reply. Registration Reply. Figure 14. Mobile IP handoff in the FA-CoA case. The process for an MN to detect that cFA is no longer accessible is referred to as move detection. MIP specifies two move detection principles: the expiration of the advertisement lifetime and the change of the network prefix. In MIP, each AgentAdvertisement carries an advertisement lifetime. If the lifetime of the most recently received advertisement expires, the MN may assume that cFA is unreachable. This approach usually leads to long move detection delay, as MIP suggests that the advertisement lifetime should be long enough to tolerate three consecutive. losses. of. advertisements.. Alternatively,. if. the. MN. receives. an. AgentAdvertisement with a network prefix different from that of the MN’s current CoA, the. 20.

(39) MN may deduce that cFA is unreachable. This also causes long move detection delay as the MN can receive nFA’s advertisement only after a layer-2 handoff. 2.3.3 Analysis handoff delays Each of the aforementioned delays contributes to the overall handoff. Many researches have aimed to solve those delays. There findings and results are briefed below. 1. AP probe delay: Mishra et al. [31] have pointed out that the probe phase delay largely contributes to the layer-2 handoff latency. They suggested the use of neighbor graphs [37] to capture handoff-to relationship between APs; the MN only needs to probe the APs that are neighbors of the current AP. An AP is a neighbor of another AP only if a handoff from the latter to the former has occurred recently. Neighbor graphs thus capture only temporal handoff-to relationship. 2. Association Delay: Neighbor graph can also be used to reduce the re-association delay by caching security information before the handoff begins, where security information is needed to establish secure communication channels between APs [38]. 3. 802.1x Authentication Delay: Neighbor graph was also utilized to decrease IEEE 802.1x authentication delay between an MN and an authentication server by pre-distributing key material to the candidate set of APs which the MN may potentially re-associate with [39]. 4. Move Detection Delay: A cross-layer design for shortening move detection delay naturally leads to the notion of layer-2 (L2) triggers. A L2 trigger is a layer-2 signal that informs layer-3 entity of particular events before or after a layer-2 handoff [45]. Based on the timing of occurrence, two types of layer-2 triggers can be defined: pre-handoff trigger and post-handoff trigger. A pre-handoff trigger happens before a layer-2 handoff, while a post-handoff trigger indicates the completion of a layer-2 handoff. In IEEE 802.11, a pre-handoff trigger may be conditioned on the execution of probe phase, which only takes place when an MN detects poor link performance. A candidate post-handoff trigger can be a “link up” event that occurs in an AP or MN after an MN successfully completes the re-association phase. Wu et al. [48] utilized the post-handoff trigger in an MN as a realization of move. 21.

(40) detection. The move detection delay is therefore eliminated. 5. Agent Discovery Delay: Wu et al. [48] also proposed the use of neighbor lists to cut off agent discovery delay. Entries of a neighbor list store IP addresses of MAs associated with neighbor APs, one for each neighbor AP. On the occurrence of a post-handoff trigger, an MN looks up its neighbor list for nFA's IP address, to which it then directly issues a registration request.1 6. Registration Delay: Handoff latency can be further improved with pre-handoff triggers instead of post-handoff triggers, as an MN could commence a layer-3 handoff even before the layer-2 handoff is completed. An example is the notion of pre-registration or early registration in Malki’s low-latency handoff proposal for Mobile IP [40]2. While this proposal allows the use of both types of L2 triggers, pre-handoff trigger is more appropriate to pre-registration. An MA in Malki’s proposal [40] is required to acquire the advertisements of neighbor MAs prior to MN’s handoffs. When a pre-handoff trigger occurs in an MN, the MN asks for nFA’s advertisement by sending a ProxyRouterSolicitation to cFA (note that the. MN. does. not. yet. have. a. direct. link. with. nFA).. cFA returns. a. ProxyRouterAdvertisement, i.e., nFA’s Agent Advertisement. The MN then can initiate a pre-registration by sending a RegistrationRequest through cFA to nFA. With this pre-registration scheme, layer-3 handoff parallels layer-2 handoff and overall handoff latency is greatly reduced. Preliminary analytical results show that the pre-registration outperforms conventional MIP with route optimization [41]. 2.3.4 Cross-Layer topology information Previous low-latency layer-2 handoff schemes [37-39] did not utilize much topology information: usually only AP’s handoff-to relationship is of interest. However, to facilitate higher-layer handoffs, the definition of topology information should be extended to incorporate cross-layer information such as the association between APs and higher-layer entities. 1. In fact, IP address alone is not sufficient for all types of registrations. Therefore, the contents of neighbor list should be extended to include all relevant information that ought to be retrieved from Agent Advertisement’s. 2 This proposal addresses both pre-registration and post-registration techniques to achieve low-latency handoff.. 22.

(41) In the pre-registration scheme mentioned above, an MN must learn of nFA’s IP address before pre-registration. This implies that the following information must be available to the MN: 1. AP topology, which provides not only handoff-to relationship among APs (which neighbor graph provides) but also the physical locations of APs (could be local or global coordinates.) If AP topology information is implemented in a distributed fashion [38], the MN can acquire it from the current AP. Alternatively, the MN may request it from some designated location server [42]. 2. The location and the moving direction of the MN, which is for an accurate estimate of the next AP. An MN learns of its current location and moving direction somehow, e.g. using GPS (Global Positioning System) or any indoor location technique [43]. 3. Association between APs and MAs (cross-layer information for estimating the next FA to which the next AP belongs). The AP/MA association should be configured and maintained at network side, since such information is network dependent. An MN can acquire associations in a way similar to how it acquires AP topology information. It is also possible to combine AP topology information and AP/MA association. The neighbor list [48] mentioned above is an example. Application-layer handoffs also benefit from such a topology-based cross-layer design. Specifically, we may maintain the association between APs and SIP proxy servers or AAA servers. The association information rarely changes, as network topology is nearly static, and can therefore be gathered off line. With that information, we can do more than simple pre-caching and pre-registration; pre-authentication and pre-reinvitation are also applicable. As an example, Kwon et al. [48] discussed the use of Diameter protocol for authenticating MNs during MIP registration. They proposed Shadow Registration that can be applied to both MIP and SIP to reduce the time to process inter-domain handoff. The key idea is to establish the security association between an MN and authenticators (APs) and between the MN and foreign AAA servers in neighbor domains prior to handoffs. However, little has been addressed on how to determine the set of candidate authenticators and the associated AAA servers. Our idea applies here: with the association information, an MN or a network-side But we focus on the pre-registration case here.. 23.

(42) server can be made aware of the set of candidate authenticators and the associated AAA servers. Previous studies mainly focus on reducing handoff delays on a specific layer. For a link-layer handoff, Mishra [31] indicates that among the delay components of a link-layer handoff, the association delay (tAssoc), and open system authentication delay (tAuth), require 10ms to 20ms each and they are about 20% of the delay of a link-layer handoff (tLK). The scan time (tProbe), contributes 80% of the tLK, which varies from 100ms to 350ms. In order to shorten the scan time, Shin [44] proposes the concept of the neighbor graph to minimize the number of scanned channels from 11 to 2.2 on average, and shortens the scan time to 32ms. For a network-layer handoff, Wu [45] investigates the detection time of network change (tDetec), and finds that it varies from 500ms to a few seconds depending on the expire timer of the agent advertisement renew (AAR) in mobile IP [46]. Dutta et al. [47] proposes the HMMP (Host Mobility Management Protocol) that installs an agent, called SIP_EYE, between the application layer and the network layer of an SIP UA to examine headers of TCP packets. The SIP_EYE agent maintains a connection table before and after a handoff so that the connection can be tracked. By looking up the table, the agent can identify their end-points and redirects the ongoing packets to the UA's new location without any modification on the TCP stack. Kwon [48] and Turányi [49] both note that the IP acquisition and assignment using DHCP causes considerable delays for SIP and mobile IP applications. Typically, DHCP takes about 4 to 5 seconds to complete. Handoff latencies also introduce packet loss. Yokota [50] proposes a link-layer solution using a MAC bridge to forward packets from old AP areas to new AP areas. Therefore, packet loss problem can be eased during network handoffs. However, this approach requires MAC bridges to connect to APs that an MN might attach. Similar to Yokota’s approach, Shim [51] tried a network-layer solution that an MN can receive packets that are forwarded by the new APs as soon as the completion of a link-layer handoff. By applying the above solutions, the number of lost packets can be reduced.. 24.

數據

Figure 1. Converged VoIP communication environment.
Figure 3. An H.323 message flow to set up a call.
Figure 2 shows a typical message flow for establishing a SIP session. Without loss of  generality, we assume that UA 2  has already registered with the SIP registrar
Figure 7. An MGCP message flow to establish a call.
+7

參考文獻

相關文件

When there are PE lessons or co-curricular physical activities to be conducted on venues outside school, the school should draw up contingency measures for adverse weather

(a) The principal of a school shall nominate such number of teachers of the school for registration as teacher manager or alternate teacher manager of the school as may be provided

My friend doesn’t likes movies.. He don’t

分析週邊支援性

It should be stressed that the four eigenvalues obtained here do not change even if we include other field outside KBc subalgebra or outside the dressed B 0 gauge, since such fields

Regarding the course timetable and the commencement arrangement, information will be sent to you via email upon completion of online registration in mid-September 2022.

Regarding the course timetable and the commencement arrangement, information will be announced via email upon completion of online registration in early September.. Lessons will

The empirical results indicate that there are four results of causality relationship between Investor Sentiment and Stock Returns, such as (1) Investor