摘 要: 提出一種新方法來降低IEEE 802.11協議中多跳傳輸的時延,并利用NS2仿真器分析比較了原來的IEEE802.11協議和改進后的協議性能,證明了后者在任何鏈路負荷的情況下都更加適合多跳傳輸。
關鍵詞: 802.11協議 多跳傳輸時延 無線網絡
1 現有的縮短時延的方法
時延是衡量網絡性能的一大標準。為縮短時延,國內外提出了許多方法[1]。在無線傳感網絡中提出了消息傳遞機制來縮短時延。該機制一次將大量數據完整地從一個節點傳遞到下一個節點,會導致這2個節點間的信道長期不能被其他節點使用,造成其他需要使用這段信道的節點的長時間等待,并不能真正起到整體縮短時延的效果[2]。因此提出了自適應方法來縮短樹型應用中多跳傳輸時延, 但該方法的適用范圍很有限。基于非同步的用于Ad Hoc網絡中實時傳輸的機制MACA/PR和RTMAC來縮短時延用到了時隙分配(類似TDMA),這又會帶來其他開銷[3][4]。
本文利用無線網絡的一個獨特之處:一個節點發送的數據只會傳給它的傳輸范圍內的所有節點,它的數據活動范圍是一個空間的球體,而有線網絡的則是一條線。利用這個由物理層特性決定的特點可節省部分控制幀ACK的發送(多跳傳輸時),縮短傳輸時延,使目的節點更早收到分組。但是發送節點等待確認幀ACK的時間變長了。當然,如果節省下來的ACK幀的發送能量能夠抵消掉接收所需的額外能量,在以節能為目的的無線傳感網絡中也可以這樣做。
2 對IEEE 802.11的MAC層協議的改進
2.1 原IEEE 802.11的思想
IEEE 802.11協議(以下都簡稱802.11)利用CSMA/CA技術[5]避免沖突。工作過程:站A向站B發送數據前,先向B發送一個請求發送幀RTS,RTS中含有整個通信過程需要持續的時間(duration)。立即發送站地址、立即接收站地址、非立即接收站的節點收到該幀就依據該幀中duration域的值設置自己的NAV(網絡分配向量,用于判斷信道是否被其他節點占用),等待該通信過程結束后再去競爭信道。B收到RTS后就立即給A發送一個允許發送幀CTS。CTS中含有剩下通信過程所需時間及A站地址。其他節點收到該CTS幀后同樣也要設置自己的NAV。這樣的2次握手可以很大程度上保證整個通信過程不受其他節點干擾。A收到CTS后就發送數據,B收到數據后就發送ACK,于是一次通信過程結束。
2.2 改進思想
多跳情況下,如果數據從A發送給C,中間經過B來轉發,當B收到A的數據后,除了要立刻回送給A一個ACK, 還要競爭信道,給C發送RTS。考慮到ACK和RTS一個在前,一個在后,時間上連續,因此希望將2個幀合為1個幀,讓該幀既能起到ACK的確認作用,又能發揮RTS的請求發送功能。這樣就可以克服802.11浪費控制幀的缺點,節約1個確認幀ACK。
為實現新的功能,需構造1個新的控制幀(一種新的RTS)。該控制幀就是通過在RTS中加1個地址(FA):轉發節點的上一站的地址。原來的RTS與修改后的RTS的結構如圖1所示。
B不發送ACK,而發送出這樣一個修改后的RTS。當A收到后(C也會收到這個RTS,不過對于C而言,這個就是請求通信的RTS),發現該幀不是發給自己的,但是該幀的前一站的地址是自己的地址,即可判斷該幀是發送給自己的ACK,于是結束自己和B之間的通信。通常RTS的競爭時間比較長,所以有時候A需要等待很長時間才能收到B發送的RTS,因此選擇A等待RTS形式的ACK的timeout時間很關鍵。此外各個幀的duration域的值也變了,必須重新計算。NAV函數(虛擬載波檢測函數)也需在原來代碼基礎上修改。
當不再需要轉發的時候,也就不需要再發送RTS。所以沒有必要再發送RTS與ACK的合成幀,只需要發送ACK。此時需要一個機制來區別對待,即通過上層(路由層)來做特殊處理,因為MAC層無法判斷出最終的目的地址是不是本節點(IP地址對MAC層是透明的)。為了不破壞分層的思想,達到真正的模擬效果,需在路由層和鏈路層增加相應的判斷和處理代碼。
其實,該方法只不過是一種捎帶思想,在發送RTS時捎帶了ACK,不發送RTS時就不捎帶。改進前后802.11的數據轉發過程如圖2所示。
2.3 NS2下802.11源代碼及修改
主要修改之處是在程序Mac-802_11.h中為RTS的幀增加一個前一站的地址。
struct rts_frame {
struct frame_control rf_fc;//控制域
u_int16_t rf_duration;//RTS的持續時間
u_char rf_ra[ETHER_ADDR_LEN];
//立即接收站的地址
u_char rf_ta[ETHER_ADDR_LEN];
//立即發送站的地址
u_char rf_fa[ETHER_ADDR_LEN];
//增加的,上一站的地址
u_char rf_fcs[ETHER_FCS_LEN];
//幀檢驗序列
};
為了能讓轉發節點將上一站的地址提取出來并保存到立刻要發送的RTS幀的FA域中,在類Mac802_11中增加了一個中間變量former用于事先存儲該地址。
接收站收到DATA后,會判斷該分組是否是重復報文,如果是則要做處理。原來的802.11直接丟棄該報文,沒有給發送站發送ACK,結果發送站就不斷地重發數據,接收站不斷發現是重復報文,就不斷丟棄,直到發送站的重傳次數達到限度,放棄重傳為止。這樣做極為浪費資源,所以本文的方法是立刻發送ACK。此外,發送站可能會收到遲到的ACK,此時該站正在重發數據,可能處于任何一種狀態(發送RTS、等待CTS、發送DATA、等待ACK或IDLE)。但是不管它處在何種狀態,它都應該立刻撤銷重傳,回復到初始狀態。因此本文在類Mac802_11中增設了一個標志變量flag,將它用于重傳機制中。
原來的NAV函數的功能為:收到一個不屬于自己的分組時,依據分組的duration域設置虛擬探測儀的值, 以后再收到不屬于自己的分組時就要比較,看是否新分組的duration值會使虛擬探測儀的值更大。若是,則用新分組的duration值來重設虛擬探測儀的值;否則仍用原來的,不做改變。這樣的功能不好,因為情況可能變了,不需要再等那么長的時間。例如新的協議中源節點可能很早就收到了ACK,其他節點就沒必要還等那么長的時間,這樣就不能充分利用空閑出來的信道,并且還會使收到RTS的節點依據虛擬探測儀就誤以為信道忙,而不敢發送CTS,從而導致RTS的重傳。所以新的NAV函數的功能應該是:只要收到不屬于自己的分組,就要依據該分組的duration域的值來更新虛擬探測儀的值。
當多跳轉發到終點后無需再發送RTS時,上層(路由層)應該通過發送一個新類型的空分組通知MAC層發送ACK。但是NS仿真中任何時候鏈路層都不會將MAC層收到的分組首先交給路由層,而是先將分組交給哈希地址分類器。地址分類器發現該分組的最終目的不是自己,才將它轉交給路由層,若是自己的就不交給路由層,而交給端口分類器。端口分類器再將該分組交給相應的進程。但是由于新協議要求路由層能發現最終目的站是自己,然后通知下層發送ACK。如果在這里分組就被地址分類器給過濾掉了,路由層就永遠無法通知下層發送ACK了,所以在哈希分類器的源代碼中要加入處理代碼,要求無論如何,即使分組已經到了目的站,此時不需要尋找路由了,還是要交給路由層處理。
本文編寫了一個具有基本接收、發送和轉發功能的靜態路由協議SimRoute。用該路由協議,而不用NS中編好的路由協議模塊AODV、DSR、DSDV等,是因為用它容易看出新的802.11協議的效果,排除由于路由尋找而帶來的干擾,并且修改上層也比較容易。
3 模擬仿真
3.1 延時理論計算
在NS的系統文件ns-default.tcl中設定了802.11的許多參數的默認值,如:
SIFS 10μs(短幀間間隔)
PreambleLength 144b(物理層的前同步碼長度)
PLCPHeaderLength 48b(物理層頭部長度)
PLCPDataRate 1Mbps(物理層的數據傳輸速率)
另外根據文件Mac802_11.h中的各個控制幀的結構可以算得各個幀的長度:
RTSLength=44B(原來的802.11中)
RTSLength=50B(新的802.11中)
CTSLength=38B
ACKLength=38B
因默認數據傳輸速率是1Mbps,故各幀所需傳輸時間是:
tRTS=44*8/1μs=352μs(原來的802.11中)
tRTS=50*8/1 μs=400μs(新的802.11中)
tCTS=38*8/1 μs=304μs
tACK=38*8/1 μs=304μs
MAC層的最大處理時延DSSS_MaxPropagationDelay為2μs;LL層處理從MAC層或路由層來的分組的默認時延是25μs;路由層是靜態路由,默認處理時延為0。
新的RTS幀比原來的RTS長6個字節,故多需要6×8b÷1Mbps=48μs的傳輸時間。先考慮只轉發一次所節約的時延。由圖2知,2個協議都發送了2次RTS,但新協議少發送了一個ACK,少需時間10μs+304μs。新協議中要求即使最后分組已經到了目的站,還是要將分組交給路由層讓它通知下層發送ACK,故多出LL層的處理時延50μs(路由層將分組交給LL層, LL層處理用了25μs,LL層再用25μs將分組交給MAC層)。但綜合起來數據仍然提前到達目的節點的應用層,所耗時間可減少:-48-48+10+304-50=168μs。此數據與鏈路負荷輕時的仿真結果一致。
若需轉發N次,數據傳輸速率為VMbps,ACK幀的長度為A字節,新的RTS增加的地址長度為L字節,發送ACK之前等待的時間為SIFSμs,鏈路層處理一次分組所需時間為Tμs,則一共發送了(N+1)個RTS幀,那么所節省的時間為:
t=[-8*L/V+(-8*L/V+SIFS+8*A/V-2*T)*N]μs
當V=1,L=6,SIFS=10,T=25時,t=(216N-48)μs,故N越大,即跳數越多,就越省時。
當N=5時,t=1 032μs,與后面鏈路負荷輕時的仿真結果一致。
3.2 TCL仿真代碼編寫
在TCL仿真代碼中使用新編寫的靜態路由協議SimRoute。利用該路由協議的功能實現程序simroute.cc中的接口函數command( )的功能,依據所要仿真的拓撲結構用TCL代碼填寫出相應的靜態路由表。在流量安排的問題上,為簡單起見,先不綁定應用層,而使用UDP代理,直接在udp層發送數據。這樣就可以自如地控制流量,而不受上層應用的影響,將問題集中在改進前后的802.11協議的性能比較上。
3.3 NS下的仿真數據
3.3.1 拓撲配置與流量安排
為測試不同情況下的協議效果,需要不同的拓撲配置和流量安排。
情況1:為 3個節點的拓撲結構,如圖3所示。3個節點排成一條線,間距250m。這樣選擇是考慮到無線網絡的傳輸范圍是250m,干擾范圍是550m。
節點0只發送一個數據給節點2。節點0每隔0.1s、0.01s、0.005s、0.003s、0.002s給節點2發送數據。
沒有必要考慮節點0和2同時給節點1發送數據的情況,因此時沒有多跳,新協議顯然沒有任何優越性,反而增加了開銷。
情況2:是7個節點的拓撲結構,如圖4所示。7個節點,排成一條線,間距250m。
節點0給節點6發送一個數據。節點0每隔0.1s、0.015s、0.012s、0.01s、0.001s給節點6發送一個數據。節點0和6同時給節點3發送一個數據。節點0和6每隔0.1s、0.015s、0.01s、0.008s給節點3發送數據。
3.3.2 數據處理結果的表格統計
以上二種情況的數據統計分別如表1和表2所示。
3.3.3 繪圖及分析
圖5為情況1下2個協議多跳傳輸的時延差。當每個時間間隔發送分組個數為100時,可以看到負荷重時改進的802.11延時性能不如原來的802.11,且隨著負荷加得更重,2個協議延時性能的差距縮小。但是只要負荷不重,改后的802.11的延時性能要好一些。其原因是此時數據只轉發了一次,跳數太少。同樣,當每個時間間隔發送300個分組時,結果類似,只不過此時鏈路負荷更重,因此時延性能略差于只發送100個分組的情況。由表1數據知跳數不太多時,修改后的802.11的丟包率要高一點,但是隨著負荷加重,丟包率的差距也減小。
圖6和圖7分別為情況2(即一點對一點)的時延差和丟包率。由圖6可知不論鏈路負荷有多重,修改后的802.11的時延始終比原來的802.11協議小。可見,跟原來的協議比,新協議更加適合多跳傳輸,跳數越多,它的優越性就越顯著,且由圖7可知新協議的丟包率也低一些。由表2可知,雖然新協議的沖突次數要少一些,但是RTS沖突導致RTS丟棄,即產生新協議的確認幀丟失,所以會出現重復分組。但是總的說來多跳傳輸性能還是比原來的802.11協議性能好得多。
情況2下多點對一點時的時延差和丟包率分別如圖8和圖9所示。由圖8可知,負荷輕時改進的802.11始終比原來的802.11時延小。負荷比較重時則改進的協議時延要長得多,但是負荷更重的時候時延就短很多。原因是修改后的802.11轉發時不發送ACK,而是發送RTS。這樣除非RTS沖突,否則發送數據的節點就可以將信道的控制權成功地交給下一跳的節點,于是可以連續完成一次多跳傳輸;而原來的802.11轉發時發送ACK,這就導致信道的公平競爭,不能保證下一跳節點獲得信道的控制權,也就不能保證連續完成一次多跳傳輸(尤其在負荷很重的時候,信道的控制權連續交給下一跳的概率將更低),這就會在多跳且負荷很重時引入多余的時延。由圖9知新協議的丟包率始終比原來的低,且鏈路負荷越重它們丟包率的差距就越大。
4 結 論
綜上所述可知:沒有太多沖突的時候,即使負荷很重,在多跳的情況下改進的802.11時延也小很多。但是如果跳數太少,如只轉發一次,則改進的802.11協議的優越性就不明顯;若負荷很重則還比原來的協議時延長不少,并且丟包率也較高。在多個節點同時給同一個節點發送數據時,2個協議都有沖突,結果大多是丟棄RTS。在改進的802.11協議中,此時由于RTS沖突被丟失而導致不必要的數據分組重傳。但此時原來的802.11協議的丟包率更高,成功傳輸的分組數目比改進的802.11協議少很多。在負荷很重時原來的802.11協議的時延反而更長。可見改進的802.11適用于多跳且沖突不多的情況。在一點對一點的情況下,無論鏈路負荷如何,改進的協議更適合多跳傳輸;在多點對一點的情況下,只要鏈路負荷不重,沖突不多,則修改后的協議在多跳傳輸方面更有價值。
參考文獻
1 Ye W,Heidemann J,Estrin D.An Energy-efficient MAC Protocol for Wireless Sensor Networks.In:IEEE INFOCOM, 2002
2 Lu G,Krishnamachari B,Raghavendra C S.An Adaptive Energy-efficient and Low-latency MAC for Data Gathering in Wireless Sensor Networks.In:IEEE Proceedings of the 18th International Parallel and Distributed Processing Symposium,2004
3 Lin C R,Gerla M.MACA/PR:Asynchronous Multimedia Multihop Wireless Network.In:Proc of IEEE INFOCOM,1997
4 Manoj B S,Siva R M.Real-time Traffic Support for Ad Hoc Wireless Networks.In:10th IEEE International Conference,2002
5 ANSI/IEEE Std 802.11.1999