所謂無線網絡，既包括允許用戶建立遠距離無線連接的全球語音和數據網絡，也包括為近距離無線連接進行優化的紅外線技術及射頻技術，與有線網絡的用途十分類似，最大的不同在于傳輸媒介的不同，利用無線電技術取代網線，可以和有線網絡互為備份。

隨著無線網絡技術的快速發展和廣泛應用，無線移動用戶已經不能僅僅滿足于簡單的數據通信。視頻通信，特別是有嚴格時延、錯誤率限制的實時多播業務需求正在迅猛增加。大量的實時多播應用充斥于無線網絡中，包括：數字視頻廣播、視頻會議、游戲、VoIP、IPTV等。

然而，IEEE802.11對多播數據的MAC層傳輸不提供糾錯，多播數據無法得到可靠性保證。如何在高丟包率的無線網絡中完成快速、準確的多播數據傳輸，這是無線網絡下的多播糾錯協議所要解決的首要問題。

現有的無線多播糾錯協議大多是基于應用層，雖然在可靠性上都較好地達成了期望，但是由于應用層處于物理層、數據鏈路層、網絡層等層次之上，在系統中位置較高，基于應用層的協議往往延時較大，有時候不能滿足嚴格的應用程序延時限制。目前對無線MAC層多播糾錯協議的研究主要有BMW（Broadcast Medium Window），BMMM （Batch Mode Multicast MAC）和BLBP（Beacon-driven Leader Based Protocol）等幾種方法。BMMM傳輸一個數據幀要發送大量的控制幀而增加了傳輸時間。BLBP在可靠性上存在問題。BMW雖然可以確保進行可靠的多播，但是數據幀的糾錯時間較長。因此本文在BMW的基礎上，提出了BMW的改進協議MMW（Multicast Medium Window），既保持了BMW的可靠性，又克服了BMW延時較大的特點。

1 BMW協議

BMW協議提出了一種可靠的MAC層多播機制，其主要思想是輪流對各個鄰居節點進行單播來達到多播的效果。

BMW要求每個節點保存3個列表：成員列表、發送列表和接收列表。成員列表用來記錄所有鄰居節點的MAC地址；發送列表用來保存已經發送但還沒有被所有鄰居節點確認收到的多播數據幀，列表大小應不小于鄰居節點數量；接收列表用來記錄已經收到多播數據幀的序列號。

BMW在RTS幀中新加入LS和RS兩個域，分別用來標記發送列表數據幀中的最小序列號和當前序列號。CTS新加入SC域用來標記需要的數據幀序列號。擴展的RTS、CTS報文結構如圖1所示。

當一個節點需要發送一個多播幀時，首先將該幀保存到發送列表中，然后在成功執行CSMA/CA后發送RTS。RTS幀包含當前發送列表中數據幀的最小序列號和當前序列號，并選擇鄰居列表中第一個鄰居節點的MAC地址作為目的地址。該鄰居成功接收到RTS后，根據最小序列號、當前序列號和接收列表檢查是否有丟失數據幀。如果有則將丟失幀的序列號寫入CTS并回復，否則回復帶有當前序列號的CTS。發送節點收到CTS，從發送列表中找到對應的數據幀進行發送，目的節點成功收到該數據幀后回復ACK，并把數據幀的序列號記錄到接收列表中。其他鄰居在接收到該數據幀后也將對序列號記錄到自己的接收列表中。如果發送節點發送的數據不是當前數據幀，則重復上述與該鄰居節點對話過程直到發送當前數據幀并收到ACK確認。如能成功發送當前數據幀且該鄰居節點已經確認收到發送列表中的所有幀，則刪除發送列表中已被所有鄰居確認的數據幀；然后發送節點將選擇鄰居列表中的下一個鄰居重復上述方法發送下一個多播幀。如果沒有新的多播幀需要發送，則選擇鄰居列表中下一個鄰居使用上述方法發送當前的多播幀。當發送列表中沒有數據幀時停止BMW循環過程，直到有新的多播幀需要發送時，重啟BMW。

可以看出，BMW發送多播數據時，輪流對鄰居節點進行單播，并在單播的時候對該鄰居節點之前丟失的數據幀進行重傳。每個多播幀都能確保被所有節點接收，但是每個節點只有被選擇作為目的節點時才能對之前丟失的數據幀就行重傳。當接收節點數目較多時，加大了數據傳輸的延時。

2 BMW的改進協議MMW

英文全稱：Multi Media World，中文全稱：多媒體世界。多媒體世界其實從字面上可以基本明白它的意思，就是由多種媒體組成，包容了報刊、畫冊、廣播、電影等，并具有自身特有的功能——交互性，只要是能用來傳播信息，任何媒體資源都可以把它加入系統中，所以多媒體是匯集了文字、圖形、動畫、視頻、聲音、特殊效果的系統。它的重要性不亞于早期的造紙及印刷術，是現代傳媒的一場革命，改變了我們學習和理解問題的方式和傳播信息的方式。

多媒體設備應從兩個層面來談：一是對普通用戶，即多媒體產品的使用者——就象報刊的讀者、電視的觀眾一樣，只需要一臺多媒體PC電腦，就可感受多媒體的無窮魅力。另一層面則是針對多媒體的設計人員，作為多媒體產品的制作者，除了要有性能較好的多媒體電腦外，還需配置一些輸入設備，象掃瞄儀、收錄機、麥克風、MIDI、錄像機、視頻壓縮卡等，這樣就能處理各種多媒體資料，另外在制作完成后還需要刻錄機這類的輸出設備。當然，制作多媒體并不是非得將每種設備都配齊，特別是對初學多媒體制作的朋友，有一臺性能不錯的多媒體PC電腦就行了。

MMW是在BMW的基礎上進行改進的，既保持了多播數據可靠傳輸的特點，又可以使丟失的報文即時得到重傳，減小了報文傳輸的延時。

2.1 改進成員列表

由于BMW對廣播數據和多播數據不做區分，將所有各個多播組的多播數據和廣播數據共同計算序列號，輪流對各個鄰居節點進行單播并進行糾錯。實際上把一個多播數據發送給非多播接收節點的鄰居節點并進行糾錯是沒有必要的，而且增加了糾錯時間。

MMW中規定每個節點為每一個多播組分別保存成員列表、發送列表和接收列表：成員列表用來記錄該多播組所有多播接收節點的MAC地址，該列表在創建多播路由時獲得；發送列表用來保存已經發送但還沒有被所有多播接收節點確認收到的多播數據幀，列表大小應不小于多播接收節點的數量；接收列表用來記錄已經收到多播數據幀的序列號。由于MMW對不同的多播組分開計算序列號，所以需要對RTS幀繼續進行改進，具體報文結構如圖2所示，加入MA域來記錄多播MAC地址。該RTS幀用來表明將要發送的數據屬于哪個多播組的以及源節點的該多播組發送列表中的最小序列號和當前序列號。廣播被看作一個特殊的多播組，成員列表為鄰居列表，RTS中的MA域填入廣播MAC地址。

通過對成員列表的改進，每個多播報文只需要對各自多播組的接收節點進行糾錯，而不需要對所有鄰居節點糾錯，減少了糾錯延時。

2.2 引入重傳請求幀

BMW中假設1個節點有n個鄰居節點，當它向第一個鄰居發送第一個多播數據時，鄰居列表中第n個鄰居由于沖突等原因沒有成功接收到這個數據，則第n個鄰居此時已經發現自己出現丟失了數據包，但必須在等待傳輸了n-1個數據后，當發送節點選擇第n個鄰居單播多播數據幀時，才會重傳這個數據?？梢钥闯?，BMW不能及時進行糾錯，加大了丟失幀的糾錯延時。

MMW引入了重傳請求幀，其報文格式如圖３所示，RA域、TA域與RTS幀相同，MA域為多播組MAC地址，SC域為丟失幀的序列號。在每次數據傳輸完成后，接收節點都會根據最大序列號、當前序列號以及自己的接收列表來檢查是否有丟失幀。如果有，則在執行完CSMA/CA后發送重傳請求幀通知源節點。源節點接收到重傳請求幀后，立刻與該節點進行RTS/CTS交換，完成交換后發送丟失幀。在傳輸丟失幀時，其他丟失該數據幀的接收節點也接收此幀并更新各自的接收列表。同時可能有不止1個節點發現丟失多播數據幀，都要發送重傳請求幀，其他節點也有可能要發送RTS幀。因此，在發送重傳請求幀前使用了CSMA/CA避免沖突，一個節點在競爭到信道使用權后，才能發送重傳請求幀通知源節點對丟失幀進行重傳。

重傳請求幀的引入是為了讓接收節點在發現自己存在丟失數據幀后，可以主動地請求源節點立即進行重傳，而不必等到被選擇作為目的節點時才會對丟失的包進行糾錯，減少了數據幀的傳輸延時。

3 仿真實驗

通過仿真實驗對MAC層糾錯協議BMW、BMMM、BLBP和MMW進行比較。發送10 000個大小為1 500 B的多播數據幀，比較不同數量接收節點情況下各個協議所需要的時間以及在一定延時限制內的數據丟包情況。物理層部分參數如表1所示，參數使用801.11a標準。所有的接收節點與發送節點只有一跳的距離。

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

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

圖6是接收節點數量為10個時，不同網絡丟包率環境下發送數據幀的最大延遲時間?？梢钥闯?，BMMM、MMW、BLBP最大延遲時間都在10 ms以下，而BMW由于不能即時丟失的數據幀進行重傳，增大了數據幀傳輸的延時。

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

綜上所述，可以發現BMMM在接收節點變大時需要傳輸大量的控制幀而加大了傳輸時間；BMW由于不能即時對丟失的數據幀進行重傳，增大了數據幀糾錯延時；而BLBP的可靠性存在問題。MMW卻解決了以上問題，為上層的多播服務提供了更可靠的實時性保障。

本文在BMW的基礎上進行改進，提出了無線局域網糾錯協議MMW。MMW通過對BMW成員列表的改進和引入了重傳請求幀，減少了BMW協議中的糾錯延時，保證了無線多播數據在MAC層快速、可靠傳輸。通過仿真實驗表明，在網絡丟包率為0.1、存在10個多播接收節點、延時限制為10 ms的情況下，MMW仍能保證所有的數據報正確傳輸，為上層多播服務提供了很好的保證。