隨著無線網(wǎng)絡(luò)技術(shù)的快速發(fā)展和廣泛應(yīng)用，無線移動用戶已經(jīng)不能僅僅滿足于簡單的數(shù)據(jù)通信。視頻通信，特別是有嚴(yán)格時延、錯誤率限制的實時多播業(yè)務(wù)需求正在迅猛增加[1]。大量的實時多播應(yīng)用充斥于無線網(wǎng)絡(luò)中，包括：數(shù)字視頻廣播、視頻會議、游戲、VoIP、IPTV等。
    然而,IEEE802.11[2]對多播數(shù)據(jù)的MAC層傳輸不提供糾錯，多播數(shù)據(jù)無法得到可靠性保證。如何在高丟包率的無線網(wǎng)絡(luò)中完成快速、準(zhǔn)確的多播數(shù)據(jù)傳輸，這是無線網(wǎng)絡(luò)下的多播糾錯協(xié)議所要解決的首要問題。
    現(xiàn)有的無線多播糾錯協(xié)議大多是基于應(yīng)用層[3-5]，雖然在可靠性上都較好地達(dá)成了期望,但是由于應(yīng)用層處于物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層等層次之上，在系統(tǒng)中位置較高，基于應(yīng)用層的協(xié)議往往延時較大，有時候不能滿足嚴(yán)格的應(yīng)用程序延時限制。目前對無線MAC層多播糾錯協(xié)議的研究主要有BMW[6] (Broadcast Medium Window)，BMMM[7] (Batch Mode Multicast MAC)和BLBP[8](Beacon-driven Leader Based Protocol)等幾種方法。BMMM傳輸一個數(shù)據(jù)幀要發(fā)送大量的控制幀而增加了傳輸時間。BLBP在可靠性上存在問題。BMW雖然可以確保進行可靠的多播，但是數(shù)據(jù)幀的糾錯時間較長。因此本文在BMW的基礎(chǔ)上,提出了BMW的改進協(xié)議MMW(Multicast Medium Window),既保持了BMW的可靠性,又克服了BMW延時較大的特點。
1 BMW協(xié)議
    BMW協(xié)議提出了一種可靠的MAC層多播機制，其主要思想是輪流對各個鄰居節(jié)點進行單播來達(dá)到多播的效果。
    BMW要求每個節(jié)點保存3個列表：成員列表、發(fā)送列表和接收列表。成員列表用來記錄所有鄰居節(jié)點的MAC地址；發(fā)送列表用來保存已經(jīng)發(fā)送但還沒有被所有鄰居節(jié)點確認(rèn)收到的多播數(shù)據(jù)幀，列表大小應(yīng)不小于鄰居節(jié)點數(shù)量；接收列表用來記錄已經(jīng)收到多播數(shù)據(jù)幀的序列號。
    BMW在RTS幀中新加入LS和RS兩個域,分別用來標(biāo)記發(fā)送列表數(shù)據(jù)幀中的最小序列號和當(dāng)前序列號。CTS新加入SC域用來標(biāo)記需要的數(shù)據(jù)幀序列號。擴展的RTS、CTS報文結(jié)構(gòu)如圖1所示。

    當(dāng)一個節(jié)點需要發(fā)送一個多播幀時，首先將該幀保存到發(fā)送列表中，然后在成功執(zhí)行CSMA/CA后發(fā)送RTS。RTS幀包含當(dāng)前發(fā)送列表中數(shù)據(jù)幀的最小序列號和當(dāng)前序列號，并選擇鄰居列表中第一個鄰居節(jié)點的MAC地址作為目的地址。該鄰居成功接收到RTS后，根據(jù)最小序列號、當(dāng)前序列號和接收列表檢查是否有丟失數(shù)據(jù)幀。如果有則將丟失幀的序列號寫入CTS并回復(fù)，否則回復(fù)帶有當(dāng)前序列號的CTS。發(fā)送節(jié)點收到CTS，從發(fā)送列表中找到對應(yīng)的數(shù)據(jù)幀進行發(fā)送，目的節(jié)點成功收到該數(shù)據(jù)幀后回復(fù)ACK，并把數(shù)據(jù)幀的序列號記錄到接收列表中。其他鄰居在接收到該數(shù)據(jù)幀后也將對序列號記錄到自己的接收列表中。如果發(fā)送節(jié)點發(fā)送的數(shù)據(jù)不是當(dāng)前數(shù)據(jù)幀，則重復(fù)上述與該鄰居節(jié)點對話過程直到發(fā)送當(dāng)前數(shù)據(jù)幀并收到ACK確認(rèn)。如能成功發(fā)送當(dāng)前數(shù)據(jù)幀且該鄰居節(jié)點已經(jīng)確認(rèn)收到發(fā)送列表中的所有幀,則刪除發(fā)送列表中已被所有鄰居確認(rèn)的數(shù)據(jù)幀；然后發(fā)送節(jié)點將選擇鄰居列表中的下一個鄰居重復(fù)上述方法發(fā)送下一個多播幀。如果沒有新的多播幀需要發(fā)送，則選擇鄰居列表中下一個鄰居使用上述方法發(fā)送當(dāng)前的多播幀。當(dāng)發(fā)送列表中沒有數(shù)據(jù)幀時停止BMW循環(huán)過程，直到有新的多播幀需要發(fā)送時，重啟BMW。
　可以看出,BMW發(fā)送多播數(shù)據(jù)時，輪流對鄰居節(jié)點進行單播，并在單播的時候?qū)υ撪従庸?jié)點之前丟失的數(shù)據(jù)幀進行重傳。每個多播幀都能確保被所有節(jié)點接收,但是每個節(jié)點只有被選擇作為目的節(jié)點時才能對之前丟失的數(shù)據(jù)幀就行重傳。當(dāng)接收節(jié)點數(shù)目較多時，加大了數(shù)據(jù)傳輸?shù)难訒r。
2 BMW的改進協(xié)議MMW
　MMW是在BMW的基礎(chǔ)上進行改進的，既保持了多播數(shù)據(jù)可靠傳輸?shù)奶攸c，又可以使丟失的報文即時得到重傳，減小了報文傳輸?shù)难訒r。
2.1 改進成員列表
　由于BMW對廣播數(shù)據(jù)和多播數(shù)據(jù)不做區(qū)分，將所有各個多播組的多播數(shù)據(jù)和廣播數(shù)據(jù)共同計算序列號，輪流對各個鄰居節(jié)點進行單播并進行糾錯。實際上把一個多播數(shù)據(jù)發(fā)送給非多播接收節(jié)點的鄰居節(jié)點并進行糾錯是沒有必要的，而且增加了糾錯時間。
　MMW中規(guī)定每個節(jié)點為每一個多播組分別保存成員列表、發(fā)送列表和接收列表：成員列表用來記錄該多播組所有多播接收節(jié)點的MAC地址，該列表在創(chuàng)建多播路由時獲得；發(fā)送列表用來保存已經(jīng)發(fā)送但還沒有被所有多播接收節(jié)點確認(rèn)收到的多播數(shù)據(jù)幀，列表大小應(yīng)不小于多播接收節(jié)點的數(shù)量；接收列表用來記錄已經(jīng)收到多播數(shù)據(jù)幀的序列號。由于MMW對不同的多播組分開計算序列號，所以需要對RTS幀繼續(xù)進行改進，具體報文結(jié)構(gòu)如圖2所示，加入MA域來記錄多播MAC地址。該RTS幀用來表明將要發(fā)送的數(shù)據(jù)屬于哪個多播組的以及源節(jié)點的該多播組發(fā)送列表中的最小序列號和當(dāng)前序列號。廣播被看作一個特殊的多播組，成員列表為鄰居列表，RTS中的MA域填入廣播MAC地址。

    通過對成員列表的改進，每個多播報文只需要對各自多播組的接收節(jié)點進行糾錯，而不需要對所有鄰居節(jié)點糾錯，減少了糾錯延時。
2.2 引入重傳請求幀
    BMW中假設(shè)1個節(jié)點有n個鄰居節(jié)點，當(dāng)它向第一個鄰居發(fā)送第一個多播數(shù)據(jù)時，鄰居列表中第n個鄰居由于沖突等原因沒有成功接收到這個數(shù)據(jù)，則第n個鄰居此時已經(jīng)發(fā)現(xiàn)自己出現(xiàn)丟失了數(shù)據(jù)包，但必須在等待傳輸了n-1個數(shù)據(jù)后，當(dāng)發(fā)送節(jié)點選擇第n個鄰居單播多播數(shù)據(jù)幀時，才會重傳這個數(shù)據(jù)?？梢钥闯觯珺MW不能及時進行糾錯，加大了丟失幀的糾錯延時。
　MMW引入了重傳請求幀，其報文格式如圖３所示，RA域、TA域與RTS幀相同，MA域為多播組MAC地址，SC域為丟失幀的序列號。在每次數(shù)據(jù)傳輸完成后，接收節(jié)點都會根據(jù)最大序列號、當(dāng)前序列號以及自己的接收列表來檢查是否有丟失幀。如果有，則在執(zhí)行完CSMA/CA后發(fā)送重傳請求幀通知源節(jié)點。源節(jié)點接收到重傳請求幀后，立刻與該節(jié)點進行RTS/CTS交換，完成交換后發(fā)送丟失幀。在傳輸丟失幀時，其他丟失該數(shù)據(jù)幀的接收節(jié)點也接收此幀并更新各自的接收列表。同時可能有不止1個節(jié)點發(fā)現(xiàn)丟失多播數(shù)據(jù)幀，都要發(fā)送重傳請求幀，其他節(jié)點也有可能要發(fā)送RTS幀。因此，在發(fā)送重傳請求幀前使用了CSMA/CA避免沖突，一個節(jié)點在競爭到信道使用權(quán)后，才能發(fā)送重傳請求幀通知源節(jié)點對丟失幀進行重傳。

　重傳請求幀的引入是為了讓接收節(jié)點在發(fā)現(xiàn)自己存在丟失數(shù)據(jù)幀后，可以主動地請求源節(jié)點立即進行重傳，而不必等到被選擇作為目的節(jié)點時才會對丟失的包進行糾錯，減少了數(shù)據(jù)幀的傳輸延時。
3 仿真實驗
　通過仿真實驗對MAC層糾錯協(xié)議BMW、BMMM、BLBP和MMW進行比較。發(fā)送10 000個大小為1 500 B的多播數(shù)據(jù)幀，比較不同數(shù)量接收節(jié)點情況下各個協(xié)議所需要的時間以及在一定延時限制內(nèi)的數(shù)據(jù)丟包情況。物理層部分參數(shù)如表1所示，參數(shù)使用801.11a標(biāo)準(zhǔn)。所有的接收節(jié)點與發(fā)送節(jié)點只有一跳的距離。

    圖4是網(wǎng)絡(luò)丟包率為0.1時，不同數(shù)量的接收節(jié)點環(huán)境下發(fā)送10 000個數(shù)據(jù)幀所用的總傳輸時間。每種協(xié)議所需要的傳輸時間都隨著接收節(jié)點的數(shù)量增加而加大，這是由于接收節(jié)點數(shù)量的增大，造成更多的重傳。其中BMMM增加的速度要快于其他協(xié)議，因為BMMM每發(fā)送1個數(shù)據(jù)包都要進行更多的控制幀交換，控制幀的數(shù)量隨著接收節(jié)點的增加而增大，因此當(dāng)接收節(jié)點數(shù)量加大時，BMMM所用的傳輸時間要高于其他3種協(xié)議。

    圖5是接收節(jié)點為10個時,不同網(wǎng)絡(luò)丟包率環(huán)境下發(fā)送10 000個數(shù)據(jù)幀所用的總時間。由圖可以看出，每種協(xié)議所需要的傳輸時間都隨著丟包率增加而加大，這也是因為網(wǎng)絡(luò)丟包率的增加也造成了更多的重傳。而且四種協(xié)議傳輸時間增大的速度基本相同，但是由于接收節(jié)點為10個時BMMM需要進行大量的控制幀交換，所以BMMM的傳輸時間要高于其他三種協(xié)議。

    圖6是接收節(jié)點數(shù)量為10個時，不同網(wǎng)絡(luò)丟包率環(huán)境下發(fā)送數(shù)據(jù)幀的最大延遲時間?？梢钥闯?BMMM、MMW、BLBP最大延遲時間都在10 ms以下，而BMW由于不能即時丟失的數(shù)據(jù)幀進行重傳，增大了數(shù)據(jù)幀傳輸?shù)难訒r。

　　圖7是10個接收節(jié)點、網(wǎng)絡(luò)丟包率為0.1的情況下，每種協(xié)議在不同延時限制下的丟失數(shù)據(jù)幀的數(shù)量。BLBP在beach幀的丟失后，非領(lǐng)導(dǎo)節(jié)點即使丟失數(shù)據(jù)幀后也不會回復(fù)NACK(Negative Acknowledgements)幀，并且存在隱藏節(jié)點問題，造成協(xié)議的不可靠，出現(xiàn)丟包。BMMM、BLBP對一個多播數(shù)據(jù)幀進行糾錯結(jié)束后才發(fā)送下一幀,及時對丟失數(shù)據(jù)進行重傳，因此所有數(shù)據(jù)幀的延時都小于10 ms。而BMW只有在節(jié)點被選擇作為目的節(jié)點時才能對之前丟失的數(shù)據(jù)包進行糾錯，加大了數(shù)據(jù)幀延時，在延時限制10 ms時存在約為1.2%的丟包率。MMW加入了重傳請求幀，使得丟失數(shù)據(jù)包可以及時進行糾錯，所有數(shù)據(jù)幀的傳輸延時保持在10 ms以下。

    綜上所述，可以發(fā)現(xiàn)BMMM在接收節(jié)點變大時需要傳輸大量的控制幀而加大了傳輸時間；BMW由于不能即時對丟失的數(shù)據(jù)幀進行重傳,增大了數(shù)據(jù)幀糾錯延時；而BLBP的可靠性存在問題。MMW卻解決了以上問題，為上層的多播服務(wù)提供了更可靠的實時性保障。
    本文在BMW的基礎(chǔ)上進行改進，提出了無線局域網(wǎng)糾錯協(xié)議MMW。MMW通過對BMW成員列表的改進和引入了重傳請求幀，減少了BMW協(xié)議中的糾錯延時,保證了無線多播數(shù)據(jù)在MAC層快速、可靠傳輸。通過仿真實驗表明,在網(wǎng)絡(luò)丟包率為0.1、存在10個多播接收節(jié)點、延時限制為10 ms的情況下，MMW仍能保證所有的數(shù)據(jù)報正確傳輸，為上層多播服務(wù)提供了很好的保證。
參考文獻(xiàn)
[1]  DUJOVNE D, TURLETTI T. Multicast in 802.11 WLANs: an experimental study[C]. 9th ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM), 2006.
[2]  IEEE Standards Department. Wireless LAN medium access  control(MAC) and physical layer(PHY) specifications[S/OL].  IEEE std 802.11TM, 2007, http://standards.ieee.org/.
[3]  TAN Guo Ping, HERFET T. Optimization of an RTP level     hybrid error correction scheme for DVB services in wireless home networks under strict delay constraints[J]. IEEE Transactions on Broadcasting, 2007,53(1).
[4]  REIMERS U H, DVB-the family of international standards     for digital video broadcasting[J]. Proc. IEEE, 2006,94(1): 173-182.
[5]  MAJUMDAR A, SACHS D G, KOZINTSEZ IV, et al. Multicast and unicast real-time video streaming over wireless LANs[J]. IEEE Transactions on CSVT, 2002,12(6).
[6] TANG K, GERLA M. MAC reliable broadcast in Ad Hoc networks[C]. IEEE MILCOM2001,2001:1008-1013.
[7]  SUN M T, HUANG L, ARORA A,et al. MAC layer multicast in IEEE 802.11 wireless networks[C]. International Conference on Parallel Processing (ICPP) 2002, 2002.
[8]  LI Zhao, HERFET T. BLBP: beacon-driven leader based  protocol for MAC layer multicast error control in wireless LANs[C]. International Conference on Wireless  Communications, Networking and Mobile Computing, WiCOM,2008.