摘   要： 提出一種新方法來(lái)降低IEEE 802.11協(xié)議中多跳傳輸?shù)臅r(shí)延，并利用NS2仿真器分析比較了原來(lái)的IEEE802.11協(xié)議和改進(jìn)后的協(xié)議性能，證明了后者在任何鏈路負(fù)荷的情況下都更加適合多跳傳輸。
關(guān)鍵詞： 802.11協(xié)議  多跳傳輸時(shí)延  無(wú)線網(wǎng)絡(luò)

1  現(xiàn)有的縮短時(shí)延的方法
　　時(shí)延是衡量網(wǎng)絡(luò)性能的一大標(biāo)準(zhǔn)。為縮短時(shí)延，國(guó)內(nèi)外提出了許多方法[1]。在無(wú)線傳感網(wǎng)絡(luò)中提出了消息傳遞機(jī)制來(lái)縮短時(shí)延。該機(jī)制一次將大量數(shù)據(jù)完整地從一個(gè)節(jié)點(diǎn)傳遞到下一個(gè)節(jié)點(diǎn)，會(huì)導(dǎo)致這2個(gè)節(jié)點(diǎn)間的信道長(zhǎng)期不能被其他節(jié)點(diǎn)使用，造成其他需要使用這段信道的節(jié)點(diǎn)的長(zhǎng)時(shí)間等待，并不能真正起到整體縮短時(shí)延的效果[2]。因此提出了自適應(yīng)方法來(lái)縮短樹(shù)型應(yīng)用中多跳傳輸時(shí)延， 但該方法的適用范圍很有限。基于非同步的用于Ad Hoc網(wǎng)絡(luò)中實(shí)時(shí)傳輸?shù)臋C(jī)制MACA/PR和RTMAC來(lái)縮短時(shí)延用到了時(shí)隙分配(類似TDMA)，這又會(huì)帶來(lái)其他開(kāi)銷(xiāo)[3][4]。
　　本文利用無(wú)線網(wǎng)絡(luò)的一個(gè)獨(dú)特之處：一個(gè)節(jié)點(diǎn)發(fā)送的數(shù)據(jù)只會(huì)傳給它的傳輸范圍內(nèi)的所有節(jié)點(diǎn)，它的數(shù)據(jù)活動(dòng)范圍是一個(gè)空間的球體，而有線網(wǎng)絡(luò)的則是一條線。利用這個(gè)由物理層特性決定的特點(diǎn)可節(jié)省部分控制幀ACK的發(fā)送(多跳傳輸時(shí))，縮短傳輸時(shí)延，使目的節(jié)點(diǎn)更早收到分組。但是發(fā)送節(jié)點(diǎn)等待確認(rèn)幀ACK的時(shí)間變長(zhǎng)了。當(dāng)然，如果節(jié)省下來(lái)的ACK幀的發(fā)送能量能夠抵消掉接收所需的額外能量，在以節(jié)能為目的的無(wú)線傳感網(wǎng)絡(luò)中也可以這樣做。
2  對(duì)IEEE 802.11的MAC層協(xié)議的改進(jìn)
2.1 原IEEE 802.11的思想
　　IEEE 802.11協(xié)議(以下都簡(jiǎn)稱802.11)利用CSMA/CA技術(shù)[5]避免沖突。工作過(guò)程：站A向站B發(fā)送數(shù)據(jù)前，先向B發(fā)送一個(gè)請(qǐng)求發(fā)送幀RTS，RTS中含有整個(gè)通信過(guò)程需要持續(xù)的時(shí)間(duration)。立即發(fā)送站地址、立即接收站地址、非立即接收站的節(jié)點(diǎn)收到該幀就依據(jù)該幀中duration域的值設(shè)置自己的NAV(網(wǎng)絡(luò)分配向量，用于判斷信道是否被其他節(jié)點(diǎn)占用)，等待該通信過(guò)程結(jié)束后再去競(jìng)爭(zhēng)信道。B收到RTS后就立即給A發(fā)送一個(gè)允許發(fā)送幀CTS。CTS中含有剩下通信過(guò)程所需時(shí)間及A站地址。其他節(jié)點(diǎn)收到該CTS幀后同樣也要設(shè)置自己的NAV。這樣的2次握手可以很大程度上保證整個(gè)通信過(guò)程不受其他節(jié)點(diǎn)干擾。A收到CTS后就發(fā)送數(shù)據(jù)，B收到數(shù)據(jù)后就發(fā)送ACK，于是一次通信過(guò)程結(jié)束。
2.2 改進(jìn)思想
　　多跳情況下，如果數(shù)據(jù)從A發(fā)送給C，中間經(jīng)過(guò)B來(lái)轉(zhuǎn)發(fā)，當(dāng)B收到A的數(shù)據(jù)后，除了要立刻回送給A一個(gè)ACK， 還要競(jìng)爭(zhēng)信道，給C發(fā)送RTS?？紤]到ACK和RTS一個(gè)在前，一個(gè)在后，時(shí)間上連續(xù)，因此希望將2個(gè)幀合為1個(gè)幀，讓該幀既能起到ACK的確認(rèn)作用，又能發(fā)揮RTS的請(qǐng)求發(fā)送功能。這樣就可以克服802.11浪費(fèi)控制幀的缺點(diǎn)，節(jié)約1個(gè)確認(rèn)幀ACK。
　　為實(shí)現(xiàn)新的功能，需構(gòu)造1個(gè)新的控制幀(一種新的RTS)。該控制幀就是通過(guò)在RTS中加1個(gè)地址(FA)：轉(zhuǎn)發(fā)節(jié)點(diǎn)的上一站的地址。原來(lái)的RTS與修改后的RTS的結(jié)構(gòu)如圖1所示。

　　B不發(fā)送ACK，而發(fā)送出這樣一個(gè)修改后的RTS。當(dāng)A收到后(C也會(huì)收到這個(gè)RTS，不過(guò)對(duì)于C而言，這個(gè)就是請(qǐng)求通信的RTS)，發(fā)現(xiàn)該幀不是發(fā)給自己的，但是該幀的前一站的地址是自己的地址，即可判斷該幀是發(fā)送給自己的ACK，于是結(jié)束自己和B之間的通信。通常RTS的競(jìng)爭(zhēng)時(shí)間比較長(zhǎng)，所以有時(shí)候A需要等待很長(zhǎng)時(shí)間才能收到B發(fā)送的RTS，因此選擇A等待RTS形式的ACK的timeout時(shí)間很關(guān)鍵。此外各個(gè)幀的duration域的值也變了，必須重新計(jì)算。NAV函數(shù)(虛擬載波檢測(cè)函數(shù))也需在原來(lái)代碼基礎(chǔ)上修改。
　　當(dāng)不再需要轉(zhuǎn)發(fā)的時(shí)候，也就不需要再發(fā)送RTS。所以沒(méi)有必要再發(fā)送RTS與ACK的合成幀，只需要發(fā)送ACK。此時(shí)需要一個(gè)機(jī)制來(lái)區(qū)別對(duì)待，即通過(guò)上層(路由層)來(lái)做特殊處理，因?yàn)镸AC層無(wú)法判斷出最終的目的地址是不是本節(jié)點(diǎn)(IP地址對(duì)MAC層是透明的)。為了不破壞分層的思想，達(dá)到真正的模擬效果，需在路由層和鏈路層增加相應(yīng)的判斷和處理代碼。
　　其實(shí)，該方法只不過(guò)是一種捎帶思想，在發(fā)送RTS時(shí)捎帶了ACK，不發(fā)送RTS時(shí)就不捎帶。改進(jìn)前后802.11的數(shù)據(jù)轉(zhuǎn)發(fā)過(guò)程如圖2所示。

2.3 NS2下802.11源代碼及修改
　　主要修改之處是在程序Mac-802_11.h中為RTS的幀增加一個(gè)前一站的地址。
struct rts_frame {
　　struct frame_control rf_fc；//控制域
　　u_int16_t  rf_duration；//RTS的持續(xù)時(shí)間
　　u_char  rf_ra[ETHER_ADDR_LEN]；
　　　　　　　　　　　//立即接收站的地址
　　u_char  rf_ta[ETHER_ADDR_LEN]；
　　　　　　　　　　　//立即發(fā)送站的地址
　　u_char  rf_fa[ETHER_ADDR_LEN]；
　　　　　　　　　　　//增加的，上一站的地址
　　u_char  rf_fcs[ETHER_FCS_LEN]；
　　　　　　　　　　　//幀檢驗(yàn)序列
　　}；
　　為了能讓轉(zhuǎn)發(fā)節(jié)點(diǎn)將上一站的地址提取出來(lái)并保存到立刻要發(fā)送的RTS幀的FA域中，在類Mac802_11中增加了一個(gè)中間變量former用于事先存儲(chǔ)該地址。
　　接收站收到DATA后，會(huì)判斷該分組是否是重復(fù)報(bào)文，如果是則要做處理。原來(lái)的802.11直接丟棄該報(bào)文，沒(méi)有給發(fā)送站發(fā)送ACK，結(jié)果發(fā)送站就不斷地重發(fā)數(shù)據(jù)，接收站不斷發(fā)現(xiàn)是重復(fù)報(bào)文，就不斷丟棄，直到發(fā)送站的重傳次數(shù)達(dá)到限度，放棄重傳為止。這樣做極為浪費(fèi)資源，所以本文的方法是立刻發(fā)送ACK。此外，發(fā)送站可能會(huì)收到遲到的ACK，此時(shí)該站正在重發(fā)數(shù)據(jù)，可能處于任何一種狀態(tài)(發(fā)送RTS、等待CTS、發(fā)送DATA、等待ACK或IDLE)。但是不管它處在何種狀態(tài)，它都應(yīng)該立刻撤銷(xiāo)重傳，回復(fù)到初始狀態(tài)。因此本文在類Mac802_11中增設(shè)了一個(gè)標(biāo)志變量flag，將它用于重傳機(jī)制中。
　　原來(lái)的NAV函數(shù)的功能為：收到一個(gè)不屬于自己的分組時(shí)，依據(jù)分組的duration域設(shè)置虛擬探測(cè)儀的值， 以后再收到不屬于自己的分組時(shí)就要比較，看是否新分組的duration值會(huì)使虛擬探測(cè)儀的值更大。若是，則用新分組的duration值來(lái)重設(shè)虛擬探測(cè)儀的值；否則仍用原來(lái)的，不做改變。這樣的功能不好，因?yàn)榍闆r可能變了，不需要再等那么長(zhǎng)的時(shí)間。例如新的協(xié)議中源節(jié)點(diǎn)可能很早就收到了ACK，其他節(jié)點(diǎn)就沒(méi)必要還等那么長(zhǎng)的時(shí)間，這樣就不能充分利用空閑出來(lái)的信道，并且還會(huì)使收到RTS的節(jié)點(diǎn)依據(jù)虛擬探測(cè)儀就誤以為信道忙，而不敢發(fā)送CTS，從而導(dǎo)致RTS的重傳。所以新的NAV函數(shù)的功能應(yīng)該是：只要收到不屬于自己的分組，就要依據(jù)該分組的duration域的值來(lái)更新虛擬探測(cè)儀的值。
　　當(dāng)多跳轉(zhuǎn)發(fā)到終點(diǎn)后無(wú)需再發(fā)送RTS時(shí)，上層(路由層)應(yīng)該通過(guò)發(fā)送一個(gè)新類型的空分組通知MAC層發(fā)送ACK。但是NS仿真中任何時(shí)候鏈路層都不會(huì)將MAC層收到的分組首先交給路由層，而是先將分組交給哈希地址分類器。地址分類器發(fā)現(xiàn)該分組的最終目的不是自己，才將它轉(zhuǎn)交給路由層，若是自己的就不交給路由層，而交給端口分類器。端口分類器再將該分組交給相應(yīng)的進(jìn)程。但是由于新協(xié)議要求路由層能發(fā)現(xiàn)最終目的站是自己，然后通知下層發(fā)送ACK。如果在這里分組就被地址分類器給過(guò)濾掉了，路由層就永遠(yuǎn)無(wú)法通知下層發(fā)送ACK了，所以在哈希分類器的源代碼中要加入處理代碼，要求無(wú)論如何，即使分組已經(jīng)到了目的站，此時(shí)不需要尋找路由了，還是要交給路由層處理。
　　本文編寫(xiě)了一個(gè)具有基本接收、發(fā)送和轉(zhuǎn)發(fā)功能的靜態(tài)路由協(xié)議SimRoute。用該路由協(xié)議，而不用NS中編好的路由協(xié)議模塊AODV、DSR、DSDV等，是因?yàn)橛盟菀卓闯鲂碌?02.11協(xié)議的效果，排除由于路由尋找而帶來(lái)的干擾，并且修改上層也比較容易。
3  模擬仿真
3.1 延時(shí)理論計(jì)算
　　在NS的系統(tǒng)文件ns-default.tcl中設(shè)定了802.11的許多參數(shù)的默認(rèn)值，如：
　　SIFS  10μs(短幀間間隔)
　　PreambleLength   144b(物理層的前同步碼長(zhǎng)度)
　　PLCPHeaderLength      48b(物理層頭部長(zhǎng)度)
　　PLCPDataRate  1Mbps(物理層的數(shù)據(jù)傳輸速率)
　　另外根據(jù)文件Mac802_11.h中的各個(gè)控制幀的結(jié)構(gòu)可以算得各個(gè)幀的長(zhǎng)度：
　　RTSLength=44B(原來(lái)的802.11中)
　　RTSLength=50B(新的802.11中)
　　CTSLength=38B
　　ACKLength=38B
　　因默認(rèn)數(shù)據(jù)傳輸速率是1Mbps，故各幀所需傳輸時(shí)間是：
　　tRTS=44*8/1μs=352μs(原來(lái)的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層的最大處理時(shí)延DSSS_MaxPropagationDelay為2μs；LL層處理從MAC層或路由層來(lái)的分組的默認(rèn)時(shí)延是25μs；路由層是靜態(tài)路由，默認(rèn)處理時(shí)延為0。
　　新的RTS幀比原來(lái)的RTS長(zhǎng)6個(gè)字節(jié)，故多需要6×8b÷1Mbps=48μs的傳輸時(shí)間。先考慮只轉(zhuǎn)發(fā)一次所節(jié)約的時(shí)延。由圖2知，2個(gè)協(xié)議都發(fā)送了2次RTS，但新協(xié)議少發(fā)送了一個(gè)ACK，少需時(shí)間10μs+304μs。新協(xié)議中要求即使最后分組已經(jīng)到了目的站，還是要將分組交給路由層讓它通知下層發(fā)送ACK，故多出LL層的處理時(shí)延50μs(路由層將分組交給LL層， LL層處理用了25μs，LL層再用25μs將分組交給MAC層)。但綜合起來(lái)數(shù)據(jù)仍然提前到達(dá)目的節(jié)點(diǎn)的應(yīng)用層，所耗時(shí)間可減少：-48-48+10+304-50=168μs。此數(shù)據(jù)與鏈路負(fù)荷輕時(shí)的仿真結(jié)果一致。
　　若需轉(zhuǎn)發(fā)N次，數(shù)據(jù)傳輸速率為VMbps，ACK幀的長(zhǎng)度為A字節(jié)，新的RTS增加的地址長(zhǎng)度為L(zhǎng)字節(jié)，發(fā)送ACK之前等待的時(shí)間為SIFSμs，鏈路層處理一次分組所需時(shí)間為T(mén)μs，則一共發(fā)送了(N+1)個(gè)RTS幀，那么所節(jié)省的時(shí)間為：
　　t=[－8*L/V+(－8*L/V+SIFS+8*A/V－2*T)*N]μs
　　當(dāng)V=1，L=6，SIFS=10，T=25時(shí)，t=(216N-48)μs，故N越大，即跳數(shù)越多，就越省時(shí)。
　　當(dāng)N=5時(shí)，t=1 032μs，與后面鏈路負(fù)荷輕時(shí)的仿真結(jié)果一致。
3.2 TCL仿真代碼編寫(xiě)
　　在TCL仿真代碼中使用新編寫(xiě)的靜態(tài)路由協(xié)議SimRoute。利用該路由協(xié)議的功能實(shí)現(xiàn)程序simroute.cc中的接口函數(shù)command( )的功能，依據(jù)所要仿真的拓?fù)浣Y(jié)構(gòu)用TCL代碼填寫(xiě)出相應(yīng)的靜態(tài)路由表。在流量安排的問(wèn)題上，為簡(jiǎn)單起見(jiàn)，先不綁定應(yīng)用層，而使用UDP代理，直接在udp層發(fā)送數(shù)據(jù)。這樣就可以自如地控制流量，而不受上層應(yīng)用的影響，將問(wèn)題集中在改進(jìn)前后的802.11協(xié)議的性能比較上。
3.3 NS下的仿真數(shù)據(jù)
3.3.1 拓?fù)渑渲门c流量安排
　　為測(cè)試不同情況下的協(xié)議效果，需要不同的拓?fù)渑渲煤土髁堪才拧?br /> 　　情況1：為 3個(gè)節(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)，如圖3所示。3個(gè)節(jié)點(diǎn)排成一條線，間距250m。這樣選擇是考慮到無(wú)線網(wǎng)絡(luò)的傳輸范圍是250m，干擾范圍是550m。

　　節(jié)點(diǎn)0只發(fā)送一個(gè)數(shù)據(jù)給節(jié)點(diǎn)2。節(jié)點(diǎn)0每隔0.1s、0.01s、0.005s、0.003s、0.002s給節(jié)點(diǎn)2發(fā)送數(shù)據(jù)。
　　沒(méi)有必要考慮節(jié)點(diǎn)0和2同時(shí)給節(jié)點(diǎn)1發(fā)送數(shù)據(jù)的情況，因此時(shí)沒(méi)有多跳，新協(xié)議顯然沒(méi)有任何優(yōu)越性，反而增加了開(kāi)銷(xiāo)。
　　情況2：是7個(gè)節(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)，如圖4所示。7個(gè)節(jié)點(diǎn)，排成一條線，間距250m。

　　節(jié)點(diǎn)0給節(jié)點(diǎn)6發(fā)送一個(gè)數(shù)據(jù)。節(jié)點(diǎn)0每隔0.1s、0.015s、0.012s、0.01s、0.001s給節(jié)點(diǎn)6發(fā)送一個(gè)數(shù)據(jù)。節(jié)點(diǎn)0和6同時(shí)給節(jié)點(diǎn)3發(fā)送一個(gè)數(shù)據(jù)。節(jié)點(diǎn)0和6每隔0.1s、0.015s、0.01s、0.008s給節(jié)點(diǎn)3發(fā)送數(shù)據(jù)。
3.3.2 數(shù)據(jù)處理結(jié)果的表格統(tǒng)計(jì)
　　以上二種情況的數(shù)據(jù)統(tǒng)計(jì)分別如表1和表2所示。

3.3.3 繪圖及分析
　　圖5為情況1下2個(gè)協(xié)議多跳傳輸?shù)臅r(shí)延差。當(dāng)每個(gè)時(shí)間間隔發(fā)送分組個(gè)數(shù)為100時(shí)，可以看到負(fù)荷重時(shí)改進(jìn)的802.11延時(shí)性能不如原來(lái)的802.11，且隨著負(fù)荷加得更重，2個(gè)協(xié)議延時(shí)性能的差距縮小。但是只要負(fù)荷不重，改后的802.11的延時(shí)性能要好一些。其原因是此時(shí)數(shù)據(jù)只轉(zhuǎn)發(fā)了一次，跳數(shù)太少。同樣，當(dāng)每個(gè)時(shí)間間隔發(fā)送300個(gè)分組時(shí)，結(jié)果類似，只不過(guò)此時(shí)鏈路負(fù)荷更重，因此時(shí)延性能略差于只發(fā)送100個(gè)分組的情況。由表1數(shù)據(jù)知跳數(shù)不太多時(shí)，修改后的802.11的丟包率要高一點(diǎn)，但是隨著負(fù)荷加重，丟包率的差距也減小。

　　圖6和圖7分別為情況2（即一點(diǎn)對(duì)一點(diǎn)）的時(shí)延差和丟包率。由圖6可知不論鏈路負(fù)荷有多重，修改后的802.11的時(shí)延始終比原來(lái)的802.11協(xié)議小。可見(jiàn)，跟原來(lái)的協(xié)議比，新協(xié)議更加適合多跳傳輸，跳數(shù)越多，它的優(yōu)越性就越顯著，且由圖7可知新協(xié)議的丟包率也低一些。由表2可知，雖然新協(xié)議的沖突次數(shù)要少一些，但是RTS沖突導(dǎo)致RTS丟棄，即產(chǎn)生新協(xié)議的確認(rèn)幀丟失，所以會(huì)出現(xiàn)重復(fù)分組。但是總的說(shuō)來(lái)多跳傳輸性能還是比原來(lái)的802.11協(xié)議性能好得多。

　　情況2下多點(diǎn)對(duì)一點(diǎn)時(shí)的時(shí)延差和丟包率分別如圖8和圖9所示。由圖8可知，負(fù)荷輕時(shí)改進(jìn)的802.11始終比原來(lái)的802.11時(shí)延小。負(fù)荷比較重時(shí)則改進(jìn)的協(xié)議時(shí)延要長(zhǎng)得多，但是負(fù)荷更重的時(shí)候時(shí)延就短很多。原因是修改后的802.11轉(zhuǎn)發(fā)時(shí)不發(fā)送ACK，而是發(fā)送RTS。這樣除非RTS沖突，否則發(fā)送數(shù)據(jù)的節(jié)點(diǎn)就可以將信道的控制權(quán)成功地交給下一跳的節(jié)點(diǎn)，于是可以連續(xù)完成一次多跳傳輸；而原來(lái)的802.11轉(zhuǎn)發(fā)時(shí)發(fā)送ACK，這就導(dǎo)致信道的公平競(jìng)爭(zhēng)，不能保證下一跳節(jié)點(diǎn)獲得信道的控制權(quán)，也就不能保證連續(xù)完成一次多跳傳輸(尤其在負(fù)荷很重的時(shí)候，信道的控制權(quán)連續(xù)交給下一跳的概率將更低)，這就會(huì)在多跳且負(fù)荷很重時(shí)引入多余的時(shí)延。由圖9知新協(xié)議的丟包率始終比原來(lái)的低，且鏈路負(fù)荷越重它們丟包率的差距就越大。
 

4  結(jié)  論
　　綜上所述可知：沒(méi)有太多沖突的時(shí)候，即使負(fù)荷很重，在多跳的情況下改進(jìn)的802.11時(shí)延也小很多。但是如果跳數(shù)太少，如只轉(zhuǎn)發(fā)一次，則改進(jìn)的802.11協(xié)議的優(yōu)越性就不明顯；若負(fù)荷很重則還比原來(lái)的協(xié)議時(shí)延長(zhǎng)不少，并且丟包率也較高。在多個(gè)節(jié)點(diǎn)同時(shí)給同一個(gè)節(jié)點(diǎn)發(fā)送數(shù)據(jù)時(shí)，2個(gè)協(xié)議都有沖突，結(jié)果大多是丟棄RTS。在改進(jìn)的802.11協(xié)議中，此時(shí)由于RTS沖突被丟失而導(dǎo)致不必要的數(shù)據(jù)分組重傳。但此時(shí)原來(lái)的802.11協(xié)議的丟包率更高，成功傳輸?shù)姆纸M數(shù)目比改進(jìn)的802.11協(xié)議少很多。在負(fù)荷很重時(shí)原來(lái)的802.11協(xié)議的時(shí)延反而更長(zhǎng)。可見(jiàn)改進(jìn)的802.11適用于多跳且沖突不多的情況。在一點(diǎn)對(duì)一點(diǎn)的情況下，無(wú)論鏈路負(fù)荷如何，改進(jìn)的協(xié)議更適合多跳傳輸；在多點(diǎn)對(duì)一點(diǎn)的情況下，只要鏈路負(fù)荷不重，沖突不多，則修改后的協(xié)議在多跳傳輸方面更有價(jià)值。
參考文獻(xiàn)
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