《電子技術應用》
您所在的位置:首頁 > 通信與網絡 > 業(yè)界動態(tài) > 基于移動主機的傳輸控制協(xié)議的研究與實現

基于移動主機的傳輸控制協(xié)議的研究與實現

2008-05-14
作者:楊震宇,舒炎泰,張 亮

  摘 要: 基于無線網絡的特點,提出了一種新的基于移動主機" title="移動主機">移動主機的傳輸層控制協(xié)議" title="控制協(xié)議">控制協(xié)議。該協(xié)議將以接收端" title="接收端">接收端為中心的傳輸層協(xié)議與以發(fā)送端為中心的傳輸層協(xié)議有機結合,以更好適應無線局域網。通過仿真實驗驗證了該協(xié)議的可行性。
  關鍵詞: 無線局域網 傳輸控制協(xié)議 移動主機


  無線局域網WLAN(Wireless LAN)是最后一跳為無線鏈路" title="無線鏈路">無線鏈路的網絡,具有覆蓋面積廣、帶寬高、安裝簡易和使用方便等優(yōu)點,因此被大規(guī)模應用。研究無線移動寬帶接入互聯(lián)網的基礎理論與關鍵技術具有重要意義,提供高性能的無線互聯(lián)網傳輸層協(xié)議是實現無線寬帶接入互聯(lián)網的關鍵。
1 傳統(tǒng)TCP協(xié)議在無線環(huán)境下的局限性
  目前互聯(lián)網使用的傳輸控制協(xié)議TCP是為固定主機和有線網絡設計的。在TCP中,發(fā)送端根據接收端ACK的反饋信息判斷網絡狀況,并假設丟包都是由網絡擁塞造成的。當發(fā)生丟包時,發(fā)送端減小發(fā)送窗口,以減小網絡的負載,避免擁塞。有線網絡的拓撲結構變化不大,鏈路狀況比較穩(wěn)定,因此這種假設是成立的,但在無線環(huán)境下,丟包很可能是由無線鏈路本身的高誤碼率或移動主機切換等情況引起的,傳統(tǒng)TCP缺乏針對不同丟包狀況的處理機制,而將丟包都歸結為擁塞,錯誤地進行擁塞控制,從而導致TCP性能嚴重下降。
2 現有方法及不足
  為解決上述問題,近年來一些文獻[1~3]相繼提出一些適應無線環(huán)境的TCP改進版本。這些改進的協(xié)議都是為了解決最后一跳為無線鏈路的網絡帶來的問題,如無線鏈路高隨機誤碼率,移動主機在不同接入點AP(Access Point)之間切換等。但它們仍然保留了原始TCP以發(fā)送端為控制中心的特點,所以效果并不理想。
  2003年,Hsieh等人提出了一種以接收端為控制中心的傳輸層協(xié)議RCP(Reception Control Protocol)[4]。它只是將控制中心移到了接收端,僅考慮了無線移動主機作為客戶端的情況,而忽略了服務器位于無線鏈路、無線互聯(lián)網中多樣化服務以及異構環(huán)境等情況。
3 MCP協(xié)議的提出與初步實現
3.1 MCP協(xié)議概述

  為更好地適應無線鏈路網絡中的最后一跳,本文提出了以移動主機為控制中心的傳輸層協(xié)議稱為MCP(Mobile host Control Protocol)。該協(xié)議將以發(fā)送端為中心的傳輸層協(xié)議和以接收端為中心的傳輸層協(xié)議有機結合,以移動主機為控制中心,讓移動主機控制整個傳輸過程。在WLAN中,當從固定主機向移動主機傳輸數據時,采用以接收端為中心的控制機制;而當從移動主機向固定主機傳輸數據時,采用以發(fā)送端為中心的控制機制。
  在WLAN中,MCP協(xié)議具有傳統(tǒng)TCP協(xié)議不具備的優(yōu)點:移動主機可以根據網絡狀況判斷丟包原因,根據不同原因采取不同的丟包恢復策略,從而可以避免TCP由于缺少丟包原因檢測機制而造成的傳輸性能下降;同時,移動主機可以根據不同的無線鏈路狀況采取不同的擁塞控制策略" title="控制策略">控制策略,克服了TCP協(xié)議使用單一擁塞控制策略,從而更好地適應不同的無線鏈路;MCP協(xié)議在處理移動主機切換時也有很大優(yōu)勢,傳統(tǒng)TCP協(xié)議在切換過程中發(fā)送數據包失敗時只能等待超時重傳,同時觸發(fā)丟包恢復機制,這樣不但使原AP中緩存的數據包失效,而且浪費了傳輸時間,在MCP協(xié)議中,移動主機能夠在第一時間判斷切換是否完成,并主動請求發(fā)送端重傳丟失的數據包,從而提高了傳輸性能。
3.2 MCP的初步實現
  MCP協(xié)議的初步實現主要是在仿真軟件NS-2[5]上完成以移動主機為中心的連接建立、擁塞控制、丟包恢復等功能模塊。
3.2.1 MCP采取移動主機為中心的數據發(fā)送機制
  傳統(tǒng)TCP采用DATA-ACK機制,即發(fā)送端主動發(fā)送數據包,接收端在收到數據包時發(fā)送相應的確認信息ACK,發(fā)送端收到ACK后,根據ACK信息判斷網絡狀況,采取適當的速率繼續(xù)發(fā)送。
  在MCP中,當移動主機作為發(fā)送端時,采用上述的DATA-ACK機制;當移動主機作為接收端時,則采用REQ-DATA機制,即移動主機主動發(fā)送數據請求包,發(fā)送端在收到請求包之后,根據其中的要求進行發(fā)送。具體方法是:接收端將接收窗口的右值填入請求包頭部的adno字段,發(fā)送端只維護一個變量seqno,用來指向下一個要發(fā)送的數據包的序號,發(fā)送端每收到一個請求包,就讀取包頭的adno字段,并發(fā)送序號從seqno到adno的數據包。
3.2.2 MCP的連接建立過程
  傳統(tǒng)TCP的連接建立是通過三次握手過程實現的。MCP的連接建立同樣通過三次握手過程實現,只是在一次連接建立的過程中,移動主機要向固定主機指明此次連接采用的控制機制。具體方法是:如果移動主機作為發(fā)送端,在建立連接的過程中會告知接收端采用以發(fā)送端為中心的控制機制;當移動主機作為接收端時,則會在連接建立的過程中指明采取以接收端為中心的控制機制。
3.2.3 MCP的流量控制策略
  傳統(tǒng)TCP協(xié)議在發(fā)送端維護擁塞窗口(cwnd)和慢啟動門限(ssthresh)兩個變量,以完成流量控制。當cwnd小于ssthresh時,采用慢啟動機制(Slow Start),用來探測網絡的可用帶寬,每個數據包被應答后,cwnd就加1;當cwnd大于ssthresh時,采用擁塞避免機制,以避免發(fā)生擁塞,并盡可能利用可用帶寬,每個數據包被應答之后,cwnd=cwnd+1/cwnd。MCP的流量控制機制與TCP基本相同,只是當移動主機作為接收端時,上述兩個參數要在接收端進行維護。
3.2.4 MCP的丟包恢復策略
  在傳統(tǒng)TCP中,當發(fā)送端收到重復的ACK(DupACK,通常是連續(xù)三個相同序號的ACK包)時,就認為發(fā)生丟包,從而采用快速重傳機制,重發(fā)序號為DupACK+1的數據包,并對cwnd和ssthresh重新賦值,避免進入慢啟動階段;當重傳定時器RTO(Retransmission TimeOut)超時,發(fā)送端會重新發(fā)送那個沒有收到ACK的數據包,同時進入慢啟動階段。
  在MCP中,作為接收端的移動主機如果發(fā)現接收包序號連續(xù)三次發(fā)生亂序,就認為發(fā)生丟包,此時接收端主動發(fā)送一個重傳請求包,要求發(fā)送端重發(fā)丟失的數據包。
  為了將重傳請求包與數據請求包加以區(qū)別,在請求包頭加入loss字段和rtxno字段。如果是重傳請求包就將包頭loss字段設置成1,然后將rtxno字段設置成請求重發(fā)的數據包序號。如果是正常的數據請求包,則包頭的loss字段就設置成0。接受端收到請求包時首先檢查包頭的loss字段,如果loss為1,則重傳rtxno對應的數據包,如果loss為0,則進行正常的數據包發(fā)送。
4 仿真實驗與性能比較
  為了驗證MCP協(xié)議的可行性,在仿真軟件NS-2下進行了3組對比實驗。實驗采用的WLAN場景中,無線鏈路帶寬為11Mbps,有線鏈路帶寬為100Mbps。
  實驗1:研究移動主機作為接收端時,MCP協(xié)議的發(fā)送窗口隨時間的變化情況。
  分別采用初步實現的MCP和TCP協(xié)議從有線主機向無線主機發(fā)送FTP數據,仿真時間為0~500s,從中分別截取兩種協(xié)議在0~30s之間發(fā)送窗口隨時間的變化情況,得到MCP和TCP發(fā)送窗口隨時間變化如圖1所示。


  從圖1可以看出,初步實現的MCP協(xié)議的發(fā)送窗口隨時間的變化趨勢與原始TCP基本相同,這從微觀上驗證了兩種協(xié)議在控制發(fā)包速率方面是基本一致的。
  實驗2:研究MCP協(xié)議的吞吐量和公平性。
  分別采用初步實現的MCP協(xié)議和TCP協(xié)議從同一個有線節(jié)點向多個無線節(jié)點發(fā)送FTP數據。作為接收端的無線節(jié)點數分別為5、10、15、20和25個,仿真時間均為0~500s,從中截取200~450s之間各個數據流的吞吐率,研究各個流之間的公平性和平均吞吐率。公平性指數的計算公式采用目前比較通用的:
  
  其中FI是公平性指數,n為節(jié)點數,xi是第i個節(jié)點的吞吐率,當FI為1時,說明所有節(jié)點是完全公平的,FI越小說明公平性越差。各個流的公平性指數隨無線節(jié)點數變化情況如圖2所示。


  從圖2可以看出,由MCP協(xié)議得到的公平性指數與具有良好公平性的原始TCP協(xié)議基本持平,說明初步實現的MCP協(xié)議在WLAN環(huán)境下具有很好的公平性。
  各個流的平均吞吐量隨無線節(jié)點數變化情況如圖3所示。


  圖3中的平均吞吐量是由200~450s內各個數據流的吞吐量取平均值得到的。從中可以看出,在WLAN下,這種初步實現的MCP協(xié)議的吞吐量同原始TCP協(xié)議十分接近。
  實驗3:研究MCP協(xié)議和TCP協(xié)議的兼容性。
  采用兩條FTP數據流,其中一條從無線節(jié)點到有線節(jié)點使用TCP協(xié)議;另外一條從有線節(jié)點到無線節(jié)點使用MCP協(xié)議。仿真時間均為0~500s,從中分別截取兩條數據流200~450s的即時吞吐量,如圖4所示。


  圖4中的即時吞吐量計算的是每一秒內的吞吐量,從中可以看出,兩條數據流并沒有出現互相壓制的情況,并且它們的即時吞吐量都在同一均值附近上下波動。這就驗證了在WLAN下,這種初步實現的MCP協(xié)議與TCP協(xié)議具有良好的兼容性。
  上述3組仿真實驗,表明了這種初步實現的MCP協(xié)議在WLAN環(huán)境下,具有與傳統(tǒng)TCP幾乎相同的性能,而且與傳統(tǒng)TCP協(xié)議存在良好的兼容性,從而證明了MCP協(xié)議的可行性,這就為下階段根據無線鏈路的特點,對MCP協(xié)議進行功能上的改進提供了良好的基礎。
  本文提出的以移動主機為中心的傳輸層協(xié)議MCP將控制中心移到移動主機,可以較好地解決最后一跳是無線鏈路的網絡帶來的擁塞控制、丟包恢復以及切換等傳統(tǒng)TCP及其改進版本都不能很好解決的問題,是一種從根本上改善無線互聯(lián)網傳輸層性能的有效途徑。
  現階段主要是將以接收端為中心的傳輸層協(xié)議和以發(fā)送端為中心的傳輸層協(xié)議進行有機集成,并通過仿真實驗,驗證了MCP協(xié)議的可行性。下階段的工作主要是結合無線鏈路高誤碼率、切換等特點,對MCP進行改進。其中工作的重點是提出一種穩(wěn)定的丟包原因檢測機制,并針對不同丟包原因采取不同措施,從而更好地體現MCP在WLAN環(huán)境下性能的優(yōu)越性。
參考文獻
1 Bakshi B,Krishna P,Vaidya N et al.Improving performance of TCP over wireless networks.In:Proceedings of IEEE ICDCS,Baltimore,MD,USA,1997
2 Goff T,Moronski J,Phatak D.Freeze-TCP:A true end-to- end TCP enhancement mechanism for mobile environments.In:Proceedings of IEEE INFOCOM,Tel-Aviv,Israel,2000
3 Sinha P,Venkitaraman N,Sivakumar R et al.WTCP:A reli-able transport protocol for wireless wide-area networks.In:Proceedings of ACM MOBICOM,Seattle,WA,USA,1999
4 Hsieh K,Kim Y Z,Sivakumar R.A Receiver-Centric Trans-port protocol for mobile hosts with heterogeneous wireless interfaces.In:Proceedings of the ninth ACM annual inter-national conference on mobile computing and networking,San Diego,CA,USA,2003
5 Ns-2 Network Simulator.http://www.isi.edu/nsnam/ns.A collaboration between researchers at UC Berkeley,LBL,USC/ISI,and Xerox PARC,2000

本站內容除特別聲明的原創(chuàng)文章之外,轉載內容只為傳遞更多信息,并不代表本網站贊同其觀點。轉載的所有的文章、圖片、音/視頻文件等資料的版權歸版權所有權人所有。本站采用的非本站原創(chuàng)文章及圖片等內容無法一一聯(lián)系確認版權者。如涉及作品內容、版權和其它問題,請及時通過電子郵件或電話通知我們,以便迅速采取適當措施,避免給雙方造成不必要的經濟損失。聯(lián)系電話:010-82306118;郵箱:aet@chinaaet.com。