所謂無(wú)線網(wǎng)絡(luò),既包括允許用戶建立遠(yuǎn)距離無(wú)線連接的全球語(yǔ)音和數(shù)據(jù)網(wǎng)絡(luò),也包括為近距離無(wú)線連接進(jìn)行優(yōu)化的紅外線技術(shù)及射頻技術(shù),與有線網(wǎng)絡(luò)的用途十分類似,最大的不同在于傳輸媒介的不同,利用無(wú)線電技術(shù)取代網(wǎng)線,可以和有線網(wǎng)絡(luò)互為備份。
隨著無(wú)線網(wǎng)絡(luò)技術(shù)的快速發(fā)展和廣泛應(yīng)用,無(wú)線移動(dòng)用戶已經(jīng)不能僅僅滿足于簡(jiǎn)單的數(shù)據(jù)通信。視頻通信,特別是有嚴(yán)格時(shí)延、錯(cuò)誤率限制的實(shí)時(shí)多播業(yè)務(wù)需求正在迅猛增加。大量的實(shí)時(shí)多播應(yīng)用充斥于無(wú)線網(wǎng)絡(luò)中,包括:數(shù)字視頻廣播、視頻會(huì)議、游戲、VoIP、IPTV等。
然而,IEEE802.11對(duì)多播數(shù)據(jù)的MAC層傳輸不提供糾錯(cuò),多播數(shù)據(jù)無(wú)法得到可靠性保證。如何在高丟包率的無(wú)線網(wǎng)絡(luò)中完成快速、準(zhǔn)確的多播數(shù)據(jù)傳輸,這是無(wú)線網(wǎng)絡(luò)下的多播糾錯(cuò)協(xié)議所要解決的首要問(wèn)題。
現(xiàn)有的無(wú)線多播糾錯(cuò)協(xié)議大多是基于應(yīng)用層,雖然在可靠性上都較好地達(dá)成了期望,但是由于應(yīng)用層處于物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層等層次之上,在系統(tǒng)中位置較高,基于應(yīng)用層的協(xié)議往往延時(shí)較大,有時(shí)候不能滿足嚴(yán)格的應(yīng)用程序延時(shí)限制。目前對(duì)無(wú)線MAC層多播糾錯(cuò)協(xié)議的研究主要有BMW(Broadcast Medium Window),BMMM (Batch Mode Multicast MAC)和BLBP(Beacon-driven Leader Based Protocol)等幾種方法。BMMM傳輸一個(gè)數(shù)據(jù)幀要發(fā)送大量的控制幀而增加了傳輸時(shí)間。BLBP在可靠性上存在問(wèn)題。BMW雖然可以確保進(jìn)行可靠的多播,但是數(shù)據(jù)幀的糾錯(cuò)時(shí)間較長(zhǎng)。因此本文在BMW的基礎(chǔ)上,提出了BMW的改進(jìn)協(xié)議MMW(Multicast Medium Window),既保持了BMW的可靠性,又克服了BMW延時(shí)較大的特點(diǎn)。
1 BMW協(xié)議
BMW協(xié)議提出了一種可靠的MAC層多播機(jī)制,其主要思想是輪流對(duì)各個(gè)鄰居節(jié)點(diǎn)進(jìn)行單播來(lái)達(dá)到多播的效果。
BMW要求每個(gè)節(jié)點(diǎn)保存3個(gè)列表:成員列表、發(fā)送列表和接收列表。成員列表用來(lái)記錄所有鄰居節(jié)點(diǎn)的MAC地址;發(fā)送列表用來(lái)保存已經(jīng)發(fā)送但還沒(méi)有被所有鄰居節(jié)點(diǎn)確認(rèn)收到的多播數(shù)據(jù)幀,列表大小應(yīng)不小于鄰居節(jié)點(diǎn)數(shù)量;接收列表用來(lái)記錄已經(jīng)收到多播數(shù)據(jù)幀的序列號(hào)。
BMW在RTS幀中新加入LS和RS兩個(gè)域,分別用來(lái)標(biāo)記發(fā)送列表數(shù)據(jù)幀中的最小序列號(hào)和當(dāng)前序列號(hào)。CTS新加入SC域用來(lái)標(biāo)記需要的數(shù)據(jù)幀序列號(hào)。擴(kuò)展的RTS、CTS報(bào)文結(jié)構(gòu)如圖1所示。
當(dāng)一個(gè)節(jié)點(diǎn)需要發(fā)送一個(gè)多播幀時(shí),首先將該幀保存到發(fā)送列表中,然后在成功執(zhí)行CSMA/CA后發(fā)送RTS。RTS幀包含當(dāng)前發(fā)送列表中數(shù)據(jù)幀的最小序列號(hào)和當(dāng)前序列號(hào),并選擇鄰居列表中第一個(gè)鄰居節(jié)點(diǎn)的MAC地址作為目的地址。該鄰居成功接收到RTS后,根據(jù)最小序列號(hào)、當(dāng)前序列號(hào)和接收列表檢查是否有丟失數(shù)據(jù)幀。如果有則將丟失幀的序列號(hào)寫入CTS并回復(fù),否則回復(fù)帶有當(dāng)前序列號(hào)的CTS。發(fā)送節(jié)點(diǎn)收到CTS,從發(fā)送列表中找到對(duì)應(yīng)的數(shù)據(jù)幀進(jìn)行發(fā)送,目的節(jié)點(diǎn)成功收到該數(shù)據(jù)幀后回復(fù)ACK,并把數(shù)據(jù)幀的序列號(hào)記錄到接收列表中。其他鄰居在接收到該數(shù)據(jù)幀后也將對(duì)序列號(hào)記錄到自己的接收列表中。如果發(fā)送節(jié)點(diǎn)發(fā)送的數(shù)據(jù)不是當(dāng)前數(shù)據(jù)幀,則重復(fù)上述與該鄰居節(jié)點(diǎn)對(duì)話過(guò)程直到發(fā)送當(dāng)前數(shù)據(jù)幀并收到ACK確認(rèn)。如能成功發(fā)送當(dāng)前數(shù)據(jù)幀且該鄰居節(jié)點(diǎn)已經(jīng)確認(rèn)收到發(fā)送列表中的所有幀,則刪除發(fā)送列表中已被所有鄰居確認(rèn)的數(shù)據(jù)幀;然后發(fā)送節(jié)點(diǎn)將選擇鄰居列表中的下一個(gè)鄰居重復(fù)上述方法發(fā)送下一個(gè)多播幀。如果沒(méi)有新的多播幀需要發(fā)送,則選擇鄰居列表中下一個(gè)鄰居使用上述方法發(fā)送當(dāng)前的多播幀。當(dāng)發(fā)送列表中沒(méi)有數(shù)據(jù)幀時(shí)停止BMW循環(huán)過(guò)程,直到有新的多播幀需要發(fā)送時(shí),重啟BMW。
可以看出,BMW發(fā)送多播數(shù)據(jù)時(shí),輪流對(duì)鄰居節(jié)點(diǎn)進(jìn)行單播,并在單播的時(shí)候?qū)υ撪従庸?jié)點(diǎn)之前丟失的數(shù)據(jù)幀進(jìn)行重傳。每個(gè)多播幀都能確保被所有節(jié)點(diǎn)接收,但是每個(gè)節(jié)點(diǎn)只有被選擇作為目的節(jié)點(diǎn)時(shí)才能對(duì)之前丟失的數(shù)據(jù)幀就行重傳。當(dāng)接收節(jié)點(diǎn)數(shù)目較多時(shí),加大了數(shù)據(jù)傳輸?shù)难訒r(shí)。
2 BMW的改進(jìn)協(xié)議MMW
英文全稱:Multi Media World,中文全稱:多媒體世界。多媒體世界其實(shí)從字面上可以基本明白它的意思,就是由多種媒體組成,包容了報(bào)刊、畫冊(cè)、廣播、電影等,并具有自身特有的功能——交互性,只要是能用來(lái)傳播信息,任何媒體資源都可以把它加入系統(tǒng)中,所以多媒體是匯集了文字、圖形、動(dòng)畫、視頻、聲音、特殊效果的系統(tǒng)。它的重要性不亞于早期的造紙及印刷術(shù),是現(xiàn)代傳媒的一場(chǎng)革命,改變了我們學(xué)習(xí)和理解問(wèn)題的方式和傳播信息的方式。
多媒體設(shè)備應(yīng)從兩個(gè)層面來(lái)談:一是對(duì)普通用戶,即多媒體產(chǎn)品的使用者——就象報(bào)刊的讀者、電視的觀眾一樣,只需要一臺(tái)多媒體PC電腦,就可感受多媒體的無(wú)窮魅力。另一層面則是針對(duì)多媒體的設(shè)計(jì)人員,作為多媒體產(chǎn)品的制作者,除了要有性能較好的多媒體電腦外,還需配置一些輸入設(shè)備,象掃瞄儀、收錄機(jī)、麥克風(fēng)、MIDI、錄像機(jī)、視頻壓縮卡等,這樣就能處理各種多媒體資料,另外在制作完成后還需要刻錄機(jī)這類的輸出設(shè)備。當(dāng)然,制作多媒體并不是非得將每種設(shè)備都配齊,特別是對(duì)初學(xué)多媒體制作的朋友,有一臺(tái)性能不錯(cuò)的多媒體PC電腦就行了。
MMW是在BMW的基礎(chǔ)上進(jìn)行改進(jìn)的,既保持了多播數(shù)據(jù)可靠傳輸?shù)奶攸c(diǎn),又可以使丟失的報(bào)文即時(shí)得到重傳,減小了報(bào)文傳輸?shù)难訒r(shí)。
2.1 改進(jìn)成員列表
由于BMW對(duì)廣播數(shù)據(jù)和多播數(shù)據(jù)不做區(qū)分,將所有各個(gè)多播組的多播數(shù)據(jù)和廣播數(shù)據(jù)共同計(jì)算序列號(hào),輪流對(duì)各個(gè)鄰居節(jié)點(diǎn)進(jìn)行單播并進(jìn)行糾錯(cuò)。實(shí)際上把一個(gè)多播數(shù)據(jù)發(fā)送給非多播接收節(jié)點(diǎn)的鄰居節(jié)點(diǎn)并進(jìn)行糾錯(cuò)是沒(méi)有必要的,而且增加了糾錯(cuò)時(shí)間。
MMW中規(guī)定每個(gè)節(jié)點(diǎn)為每一個(gè)多播組分別保存成員列表、發(fā)送列表和接收列表:成員列表用來(lái)記錄該多播組所有多播接收節(jié)點(diǎn)的MAC地址,該列表在創(chuàng)建多播路由時(shí)獲得;發(fā)送列表用來(lái)保存已經(jīng)發(fā)送但還沒(méi)有被所有多播接收節(jié)點(diǎn)確認(rèn)收到的多播數(shù)據(jù)幀,列表大小應(yīng)不小于多播接收節(jié)點(diǎn)的數(shù)量;接收列表用來(lái)記錄已經(jīng)收到多播數(shù)據(jù)幀的序列號(hào)。由于MMW對(duì)不同的多播組分開計(jì)算序列號(hào),所以需要對(duì)RTS幀繼續(xù)進(jìn)行改進(jìn),具體報(bào)文結(jié)構(gòu)如圖2所示,加入MA域來(lái)記錄多播MAC地址。該RTS幀用來(lái)表明將要發(fā)送的數(shù)據(jù)屬于哪個(gè)多播組的以及源節(jié)點(diǎn)的該多播組發(fā)送列表中的最小序列號(hào)和當(dāng)前序列號(hào)。廣播被看作一個(gè)特殊的多播組,成員列表為鄰居列表,RTS中的MA域填入廣播MAC地址。
通過(guò)對(duì)成員列表的改進(jìn),每個(gè)多播報(bào)文只需要對(duì)各自多播組的接收節(jié)點(diǎn)進(jìn)行糾錯(cuò),而不需要對(duì)所有鄰居節(jié)點(diǎn)糾錯(cuò),減少了糾錯(cuò)延時(shí)。
2.2 引入重傳請(qǐng)求幀
BMW中假設(shè)1個(gè)節(jié)點(diǎn)有n個(gè)鄰居節(jié)點(diǎn),當(dāng)它向第一個(gè)鄰居發(fā)送第一個(gè)多播數(shù)據(jù)時(shí),鄰居列表中第n個(gè)鄰居由于沖突等原因沒(méi)有成功接收到這個(gè)數(shù)據(jù),則第n個(gè)鄰居此時(shí)已經(jīng)發(fā)現(xiàn)自己出現(xiàn)丟失了數(shù)據(jù)包,但必須在等待傳輸了n-1個(gè)數(shù)據(jù)后,當(dāng)發(fā)送節(jié)點(diǎn)選擇第n個(gè)鄰居單播多播數(shù)據(jù)幀時(shí),才會(huì)重傳這個(gè)數(shù)據(jù)??梢钥闯觯珺MW不能及時(shí)進(jìn)行糾錯(cuò),加大了丟失幀的糾錯(cuò)延時(shí)。
MMW引入了重傳請(qǐng)求幀,其報(bào)文格式如圖3所示,RA域、TA域與RTS幀相同,MA域?yàn)槎嗖ソMMAC地址,SC域?yàn)閬G失幀的序列號(hào)。在每次數(shù)據(jù)傳輸完成后,接收節(jié)點(diǎn)都會(huì)根據(jù)最大序列號(hào)、當(dāng)前序列號(hào)以及自己的接收列表來(lái)檢查是否有丟失幀。如果有,則在執(zhí)行完CSMA/CA后發(fā)送重傳請(qǐng)求幀通知源節(jié)點(diǎn)。源節(jié)點(diǎn)接收到重傳請(qǐng)求幀后,立刻與該節(jié)點(diǎn)進(jìn)行RTS/CTS交換,完成交換后發(fā)送丟失幀。在傳輸丟失幀時(shí),其他丟失該數(shù)據(jù)幀的接收節(jié)點(diǎn)也接收此幀并更新各自的接收列表。同時(shí)可能有不止1個(gè)節(jié)點(diǎn)發(fā)現(xiàn)丟失多播數(shù)據(jù)幀,都要發(fā)送重傳請(qǐng)求幀,其他節(jié)點(diǎn)也有可能要發(fā)送RTS幀。因此,在發(fā)送重傳請(qǐng)求幀前使用了CSMA/CA避免沖突,一個(gè)節(jié)點(diǎn)在競(jìng)爭(zhēng)到信道使用權(quán)后,才能發(fā)送重傳請(qǐng)求幀通知源節(jié)點(diǎn)對(duì)丟失幀進(jìn)行重傳。
重傳請(qǐng)求幀的引入是為了讓接收節(jié)點(diǎn)在發(fā)現(xiàn)自己存在丟失數(shù)據(jù)幀后,可以主動(dòng)地請(qǐng)求源節(jié)點(diǎn)立即進(jìn)行重傳,而不必等到被選擇作為目的節(jié)點(diǎn)時(shí)才會(huì)對(duì)丟失的包進(jìn)行糾錯(cuò),減少了數(shù)據(jù)幀的傳輸延時(shí)。
3 仿真實(shí)驗(yàn)
通過(guò)仿真實(shí)驗(yàn)對(duì)MAC層糾錯(cuò)協(xié)議BMW、BMMM、BLBP和MMW進(jìn)行比較。發(fā)送10 000個(gè)大小為1 500 B的多播數(shù)據(jù)幀,比較不同數(shù)量接收節(jié)點(diǎn)情況下各個(gè)協(xié)議所需要的時(shí)間以及在一定延時(shí)限制內(nèi)的數(shù)據(jù)丟包情況。物理層部分參數(shù)如表1所示,參數(shù)使用801.11a標(biāo)準(zhǔn)。所有的接收節(jié)點(diǎn)與發(fā)送節(jié)點(diǎn)只有一跳的距離。
圖4是網(wǎng)絡(luò)丟包率為0.1時(shí),不同數(shù)量的接收節(jié)點(diǎn)環(huán)境下發(fā)送10 000個(gè)數(shù)據(jù)幀所用的總傳輸時(shí)間。每種協(xié)議所需要的傳輸時(shí)間都隨著接收節(jié)點(diǎn)的數(shù)量增加而加大,這是由于接收節(jié)點(diǎn)數(shù)量的增大,造成更多的重傳。其中BMMM增加的速度要快于其他協(xié)議,因?yàn)锽MMM每發(fā)送1個(gè)數(shù)據(jù)包都要進(jìn)行更多的控制幀交換,控制幀的數(shù)量隨著接收節(jié)點(diǎn)的增加而增大,因此當(dāng)接收節(jié)點(diǎn)數(shù)量加大時(shí),BMMM所用的傳輸時(shí)間要高于其他3種協(xié)議。
圖5是接收節(jié)點(diǎn)為10個(gè)時(shí),不同網(wǎng)絡(luò)丟包率環(huán)境下發(fā)送10 000個(gè)數(shù)據(jù)幀所用的總時(shí)間。由圖可以看出,每種協(xié)議所需要的傳輸時(shí)間都隨著丟包率增加而加大,這也是因?yàn)榫W(wǎng)絡(luò)丟包率的增加也造成了更多的重傳。而且四種協(xié)議傳輸時(shí)間增大的速度基本相同,但是由于接收節(jié)點(diǎn)為10個(gè)時(shí)BMMM需要進(jìn)行大量的控制幀交換,所以BMMM的傳輸時(shí)間要高于其他三種協(xié)議。
圖6是接收節(jié)點(diǎn)數(shù)量為10個(gè)時(shí),不同網(wǎng)絡(luò)丟包率環(huán)境下發(fā)送數(shù)據(jù)幀的最大延遲時(shí)間??梢钥闯觯珺MMM、MMW、BLBP最大延遲時(shí)間都在10 ms以下,而BMW由于不能即時(shí)丟失的數(shù)據(jù)幀進(jìn)行重傳,增大了數(shù)據(jù)幀傳輸?shù)难訒r(shí)。
圖7是10個(gè)接收節(jié)點(diǎn)、網(wǎng)絡(luò)丟包率為0.1的情況下,每種協(xié)議在不同延時(shí)限制下的丟失數(shù)據(jù)幀的數(shù)量。BLBP在beach幀的丟失后,非領(lǐng)導(dǎo)節(jié)點(diǎn)即使丟失數(shù)據(jù)幀后也不會(huì)回復(fù)NACK(Negative Acknowledgements)幀,并且存在隱藏節(jié)點(diǎn)問(wèn)題,造成協(xié)議的不可靠,出現(xiàn)丟包。BMMM、BLBP對(duì)一個(gè)多播數(shù)據(jù)幀進(jìn)行糾錯(cuò)結(jié)束后才發(fā)送下一幀,及時(shí)對(duì)丟失數(shù)據(jù)進(jìn)行重傳,因此所有數(shù)據(jù)幀的延時(shí)都小于10 ms。而BMW只有在節(jié)點(diǎn)被選擇作為目的節(jié)點(diǎn)時(shí)才能對(duì)之前丟失的數(shù)據(jù)包進(jìn)行糾錯(cuò),加大了數(shù)據(jù)幀延時(shí),在延時(shí)限制10 ms時(shí)存在約為1.2%的丟包率。MMW加入了重傳請(qǐng)求幀,使得丟失數(shù)據(jù)包可以及時(shí)進(jìn)行糾錯(cuò),所有數(shù)據(jù)幀的傳輸延時(shí)保持在10 ms以下。
綜上所述,可以發(fā)現(xiàn)BMMM在接收節(jié)點(diǎn)變大時(shí)需要傳輸大量的控制幀而加大了傳輸時(shí)間;BMW由于不能即時(shí)對(duì)丟失的數(shù)據(jù)幀進(jìn)行重傳,增大了數(shù)據(jù)幀糾錯(cuò)延時(shí);而BLBP的可靠性存在問(wèn)題。MMW卻解決了以上問(wèn)題,為上層的多播服務(wù)提供了更可靠的實(shí)時(shí)性保障。
本文在BMW的基礎(chǔ)上進(jìn)行改進(jìn),提出了無(wú)線局域網(wǎng)糾錯(cuò)協(xié)議MMW。MMW通過(guò)對(duì)BMW成員列表的改進(jìn)和引入了重傳請(qǐng)求幀,減少了BMW協(xié)議中的糾錯(cuò)延時(shí),保證了無(wú)線多播數(shù)據(jù)在MAC層快速、可靠傳輸。通過(guò)仿真實(shí)驗(yàn)表明,在網(wǎng)絡(luò)丟包率為0.1、存在10個(gè)多播接收節(jié)點(diǎn)、延時(shí)限制為10 ms的情況下,MMW仍能保證所有的數(shù)據(jù)報(bào)正確傳輸,為上層多播服務(wù)提供了很好的保證。
-
數(shù)字視頻
+關(guān)注
關(guān)注
0文章
108瀏覽量
19298 -
無(wú)線網(wǎng)絡(luò)
+關(guān)注
關(guān)注
6文章
1441瀏覽量
66005 -
無(wú)線局域網(wǎng)
+關(guān)注
關(guān)注
1文章
235瀏覽量
29833
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論