基于媒質(zhì)共享的無(wú)線Ad hoc網(wǎng)絡(luò)擁塞避免策略*

馬琳 張軍 劉凱

(北京航空航天大學(xué)電子信息工程學(xué)院∥國(guó)家空管新航行系統(tǒng)技術(shù)重點(diǎn)實(shí)驗(yàn)室，北京100191)

無(wú)線Ad hoc網(wǎng)絡(luò)是一種無(wú)固定基礎(chǔ)設(shè)施、網(wǎng)絡(luò)拓?fù)鋭?dòng)態(tài)變化、多跳的臨時(shí)性自治系統(tǒng).由于其靈活的組網(wǎng)方式，已在無(wú)人機(jī)網(wǎng)絡(luò)、災(zāi)難救援、傳感器網(wǎng)絡(luò)等諸多領(lǐng)域得到廣泛應(yīng)用.隨著網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大和網(wǎng)絡(luò)應(yīng)用業(yè)務(wù)的不斷增多，網(wǎng)絡(luò)擁塞時(shí)常發(fā)生;為了保證網(wǎng)絡(luò)傳輸?shù)目煽啃?，保持網(wǎng)絡(luò)持續(xù)端到端的高吞吐量，需要研究擁塞控制算法，進(jìn)行有效的擁塞控制.文獻(xiàn)［1-4］中指出傳輸控制協(xié)議(TCP)在無(wú)線Ad hoc網(wǎng)絡(luò)中表現(xiàn)出了嚴(yán)重的性能下降現(xiàn)象，這是因?yàn)門CP協(xié)議本是為有線網(wǎng)絡(luò)設(shè)計(jì)的，在有線網(wǎng)絡(luò)里丟包被認(rèn)為是網(wǎng)絡(luò)擁塞發(fā)生的標(biāo)志.不過(guò)，在無(wú)線Ad hoc網(wǎng)絡(luò)中，丟包可能是由多種原因造成［5-6］，如信道錯(cuò)誤、競(jìng)爭(zhēng)共享信道沖突、路由失敗等.文獻(xiàn)［2］中指出，由于信號(hào)干擾造成的無(wú)線鏈路丟包往往發(fā)生在隊(duì)列溢出之前，這種非擁塞丟包引起TCP擁塞控制機(jī)制做出錯(cuò)誤的響應(yīng)，過(guò)度降低源端的發(fā)送速率，使得TCP協(xié)議在無(wú)線Ad hoc網(wǎng)絡(luò)中的性能嚴(yán)重下降.

因此，準(zhǔn)確判斷節(jié)點(diǎn)的擁塞狀態(tài)成為無(wú)線Ad hoc網(wǎng)絡(luò)擁塞控制算法的關(guān)鍵.為此，研究者開始研究媒質(zhì)接入控制(MAC)層的擁塞控制算法［7-8］，以MAC層的各種信息作為新的擁塞度量，從而更加準(zhǔn)確地判斷網(wǎng)絡(luò)的擁塞狀況.典型的算法有LRED［2］、TCPMDA［9］、ARCD［10］等.LRED 利用節(jié)點(diǎn)在 MAC 層的重傳次數(shù)作為網(wǎng)絡(luò)擁塞的指示，該擁塞度量獲取簡(jiǎn)單，幾乎不增加節(jié)點(diǎn)額外的開銷，但它沒有考慮到?jīng)]有重傳并不意味著沒有擁塞，某些“餓死”節(jié)點(diǎn)的分組重傳次數(shù)幾乎為零，因此不能幫助此類節(jié)點(diǎn)從擁塞狀態(tài)中恢復(fù)過(guò)來(lái).TCP-MDA用重傳分組數(shù)和總傳輸分組數(shù)的比值來(lái)度量測(cè)量節(jié)點(diǎn)的擁塞程度，比LRED簡(jiǎn)單地將重傳次數(shù)作為擁塞度量的準(zhǔn)確性高，但在 IEEE 802.11 DCF［11］協(xié)議中，每個(gè)重傳分組都會(huì)經(jīng)歷一段相對(duì)長(zhǎng)的嘗試獲取信道的時(shí)間，因此TCP-MDA不能及時(shí)對(duì)網(wǎng)絡(luò)擁塞做出判斷.文獻(xiàn)［12］中通過(guò)在MAC層實(shí)時(shí)檢測(cè)信道的接收和發(fā)送情況，結(jié)合MAC隊(duì)列的瞬態(tài)長(zhǎng)度來(lái)估計(jì)節(jié)點(diǎn)的可用帶寬，依此判斷節(jié)點(diǎn)的擁塞狀態(tài).該算法雖能較好地判斷出當(dāng)前節(jié)點(diǎn)是否擁塞，但沒有考慮到節(jié)點(diǎn)的公平性問題.ARCD用MAC層隊(duì)列長(zhǎng)度作為節(jié)點(diǎn)擁塞度量，并將整條鏈路上的擁塞信息反饋給源節(jié)點(diǎn)，以便源節(jié)點(diǎn)更合理地調(diào)整分組發(fā)送速率，但MAC層隊(duì)列長(zhǎng)度已經(jīng)被證實(shí)增長(zhǎng)緩慢，難以合理表征節(jié)點(diǎn)的擁塞程度［2］.文獻(xiàn)［13］中利用 TCP擁塞窗口和MAC延時(shí)分別估算傳輸層和MAC層的傳輸速率，根據(jù)兩者的比值調(diào)整TCP擁塞窗口的大小，達(dá)到控制源端發(fā)送速率的目的，但擁塞窗口和MAC層延時(shí)的抖動(dòng)都較大，影響了算法的準(zhǔn)確性.上述算法均沒有考慮節(jié)點(diǎn)間擁塞信息的交互，這就降低了節(jié)點(diǎn)判斷MAC層擁塞的準(zhǔn)確性，限制了算法的性能.

為此，本研究首先分析MAC層擁塞和節(jié)點(diǎn)沖突問題，探討引起擁塞和沖突的原因，以及由此導(dǎo)致的節(jié)點(diǎn)間不公平性問題.然后從MAC層擁塞控制角度出發(fā)，為無(wú)線Ad hoc網(wǎng)絡(luò)提出一種基于媒質(zhì)共享的公平擁塞控制(MCFCC)算法.基于 IEEE 802.11 DCF的退避機(jī)制，提出一種新的MAC層擁塞度量——退避率(pb)來(lái)描述節(jié)點(diǎn)自身的擁塞程度，傳輸節(jié)點(diǎn)通過(guò)請(qǐng)求發(fā)送(RTS)、清除請(qǐng)求(CTS)捎帶的方式將自身的擁塞信息(簡(jiǎn)稱CI)反饋給鄰居節(jié)點(diǎn)，收到擁塞信息之后節(jié)點(diǎn)還要結(jié)合自身?yè)砣潭扔?jì)算分組丟棄概率，并依此控制源端的發(fā)送速率，從總體上緩解網(wǎng)絡(luò)的擁塞，改善節(jié)點(diǎn)間的公平性.

1 問題描述

IEEE 802.11 DCF協(xié)議已經(jīng)被廣泛應(yīng)用在無(wú)線Ad hoc網(wǎng)絡(luò)中，因此，本部分主要討論MAC層采用IEEE 802.11 DCF協(xié)議時(shí)存在的共享媒質(zhì)沖突和擁塞問題，以及由此導(dǎo)致的TCP吞吐量下降和節(jié)點(diǎn)間的不公平性，最后介紹 IEEE 802.11 DCF的退避算法.

1.1 共享媒質(zhì)沖突引起的擁塞問題

TCP協(xié)議本身傾向于最大化網(wǎng)絡(luò)吞吐量［14］，這常常會(huì)導(dǎo)致節(jié)點(diǎn)的分組發(fā)送速率大于網(wǎng)絡(luò)容量.根據(jù)TCP協(xié)議，節(jié)點(diǎn)每次成功發(fā)送分組后都會(huì)加大擁塞窗口，直到判斷出丟包的發(fā)生.在此期間，源節(jié)點(diǎn)逐漸加大的擁塞窗口使得其發(fā)送速率超出了網(wǎng)絡(luò)的容量，源端發(fā)出的分組逐漸積累到傳輸路徑中的各個(gè)節(jié)點(diǎn)的隊(duì)列里.當(dāng)傳輸路徑上的節(jié)點(diǎn)都有分組需要被轉(zhuǎn)發(fā)時(shí)，流間競(jìng)爭(zhēng)和流內(nèi)競(jìng)爭(zhēng)問題就會(huì)凸顯出來(lái)，導(dǎo)致網(wǎng)絡(luò)性能嚴(yán)重下降［15-16］.這是因?yàn)猷従庸?jié)點(diǎn)為了轉(zhuǎn)發(fā)分組需要持續(xù)競(jìng)爭(zhēng)信道，導(dǎo)致傳輸發(fā)生沖突、延遲增大、擁塞加劇，直到TCP發(fā)現(xiàn)丟包而減小分組發(fā)送速率、消除擁塞.消除擁塞之后，TCP又會(huì)加大擁塞窗口，這樣的循環(huán)會(huì)一直繼續(xù)下去，造成網(wǎng)絡(luò)難以保持良好、穩(wěn)定的工作狀態(tài).

1.2 信道競(jìng)爭(zhēng)和TCP擁塞控制中的不公平性問題

在無(wú)線網(wǎng)絡(luò)中，競(jìng)爭(zhēng)信道導(dǎo)致的分組傳輸沖突和TCP擁塞控制機(jī)制是引起節(jié)點(diǎn)間不公平性［17-18］的主要原因之一.

首先，傳輸流經(jīng)過(guò)的區(qū)域不同，所面臨的競(jìng)爭(zhēng)壓力就不一致，分到的網(wǎng)絡(luò)帶寬也就不同.節(jié)點(diǎn)在傳輸分組的過(guò)程中需要和相鄰節(jié)點(diǎn)競(jìng)爭(zhēng)共享信道，傳輸業(yè)務(wù)流經(jīng)過(guò)區(qū)域內(nèi)的節(jié)點(diǎn)越多，與之競(jìng)爭(zhēng)信道的節(jié)點(diǎn)就越多，那么其分到的帶寬就會(huì)越小，擁塞就會(huì)加劇、丟包延遲就會(huì)加大.

其次，傳輸業(yè)務(wù)流的長(zhǎng)短對(duì)公平性也有影響.路徑長(zhǎng)的業(yè)務(wù)流需要消耗更大的帶寬，遭遇的共享信道競(jìng)爭(zhēng)也越大，會(huì)有更多的分組丟失，而路徑短的業(yè)務(wù)流正好相反，并且在TCP擁塞控制機(jī)制的作用下，丟包使得路徑長(zhǎng)的流進(jìn)一步減小擁塞窗口，只能獲得更小的帶寬.

最后，TCP擁塞控制和無(wú)線媒質(zhì)沖突還會(huì)導(dǎo)致節(jié)點(diǎn)“餓死”現(xiàn)象，被“餓死”的節(jié)點(diǎn)吞吐量幾乎為零.如圖1所示，假設(shè)存在兩個(gè)不同的業(yè)務(wù)流A→B和D→E，圖中相鄰節(jié)點(diǎn)間的距離是200 m，每個(gè)節(jié)點(diǎn)的傳輸距離是250m，節(jié)點(diǎn)的載波偵聽范圍和干擾范圍是550m.

圖1 鏈?zhǔn)酵負(fù)浣Y(jié)構(gòu)Fig.1 Structure of chain topology

當(dāng)節(jié)點(diǎn)D正在向節(jié)點(diǎn)E發(fā)送分組時(shí)，如果此時(shí)節(jié)點(diǎn)A要發(fā)送分組到節(jié)點(diǎn)B，由于B在D的干擾范圍之內(nèi)，故B不能正確接收到A發(fā)送的分組.根據(jù)IEEE 802.11 DCF協(xié)議，節(jié)點(diǎn)A的競(jìng)爭(zhēng)窗口加倍，進(jìn)入退避過(guò)程后重傳RTS分組，直至超過(guò)重傳次數(shù)后丟棄相關(guān)數(shù)據(jù)分組.源端確認(rèn)數(shù)據(jù)分組丟棄后把TCP擁塞窗口減半，重傳該數(shù)據(jù)分組，使得吞吐量大幅下降.而節(jié)點(diǎn)D由于成功發(fā)送分組，競(jìng)爭(zhēng)窗口被重置為最小值，TCP的擁塞窗口加倍，發(fā)送速率加大.如果節(jié)點(diǎn)D需要傳輸?shù)臄?shù)據(jù)量較大，那么它會(huì)一直占用媒質(zhì)，而節(jié)點(diǎn)A由于不能接入信道，競(jìng)爭(zhēng)窗口逐漸增大到最大值，TCP擁塞窗口減小，直至被“餓死”.

1.3 IEEE 802.11 DCF 中的退避算法

IEEE 802.11 DCF使用二進(jìn)制指數(shù)退避算法控制節(jié)點(diǎn)的信道訪問接入，根據(jù)當(dāng)前信道的活動(dòng)狀態(tài)，調(diào)整節(jié)點(diǎn)競(jìng)爭(zhēng)窗口的大小，進(jìn)而控制節(jié)點(diǎn)的訪問權(quán)限.802.11 DCF使用載波監(jiān)聽(CS)機(jī)制判斷所共享的信道媒質(zhì)是否空閑.

當(dāng)節(jié)點(diǎn)首次發(fā)送數(shù)據(jù)時(shí)，必須先偵聽信道是否空閑，若信道持續(xù)空閑時(shí)間等于DCF分布式幀間隔時(shí)間(DIFS)，則允許節(jié)點(diǎn)執(zhí)行二進(jìn)制指數(shù)退避過(guò)程后發(fā)送數(shù)據(jù).若節(jié)點(diǎn)偵聽到信道忙，則等到信道空閑后執(zhí)行二進(jìn)制指數(shù)退避過(guò)程發(fā)送數(shù)據(jù)，即在［0，CW－1］間隨機(jī)選擇一個(gè)數(shù)作為當(dāng)前節(jié)點(diǎn)的退避時(shí)隙數(shù)(這里CW為節(jié)點(diǎn)競(jìng)爭(zhēng)窗口的大小)，當(dāng)偵聽到相應(yīng)數(shù)目的退避時(shí)隙空閑后發(fā)起發(fā)送.之后，節(jié)點(diǎn)每次發(fā)送數(shù)據(jù)前仍要偵聽信道，若信道空閑的時(shí)間間隔等于DIFS和當(dāng)前退避計(jì)時(shí)器時(shí)長(zhǎng)之和，則節(jié)點(diǎn)開始發(fā)送RTS分組.若信道忙或者發(fā)送節(jié)點(diǎn)沒有成功接收到CTS分組，則發(fā)送節(jié)點(diǎn)需要進(jìn)入二進(jìn)制指數(shù)退避過(guò)程.若發(fā)送節(jié)點(diǎn)成功收到CTS分組，則開始發(fā)送數(shù)據(jù)分組.DCF使用確認(rèn)(ACK)分組通知發(fā)送節(jié)點(diǎn)該數(shù)據(jù)分組已經(jīng)被下一跳節(jié)點(diǎn)成功接收，如果發(fā)送節(jié)點(diǎn)在ACK超時(shí)發(fā)生之前未成功收到ACK分組，則認(rèn)為沖突發(fā)生，并再次進(jìn)入退避過(guò)程，直到達(dá)到最大重傳限制(802.11允許RTS消息最多重傳7次，允許數(shù)據(jù)分組最多重傳4次).此外，當(dāng)數(shù)據(jù)傳輸成功后，發(fā)送節(jié)點(diǎn)也要進(jìn)入二進(jìn)制指數(shù)退避過(guò)程.通過(guò)對(duì)退避算法的分析可知，節(jié)點(diǎn)每次發(fā)送分組失敗都要進(jìn)入退避過(guò)程.網(wǎng)絡(luò)擁塞越嚴(yán)重，節(jié)點(diǎn)發(fā)送失敗的次數(shù)越多，執(zhí)行退避過(guò)程的次數(shù)也越多.所以節(jié)點(diǎn)進(jìn)入退避過(guò)程的次數(shù)能夠反映網(wǎng)絡(luò)擁塞的程度.

2 MCFCC算法

如何準(zhǔn)確判斷網(wǎng)絡(luò)狀態(tài)是擁塞控制的難點(diǎn).本研究提出的MCFCC算法以MAC層媒質(zhì)競(jìng)爭(zhēng)失敗的次數(shù)作為網(wǎng)絡(luò)擁塞狀況的度量，同時(shí)利用RTS、CTS分組將此擁塞信息發(fā)送到鄰節(jié)點(diǎn)，各節(jié)點(diǎn)據(jù)此估計(jì)網(wǎng)絡(luò)的擁塞程度，選擇相應(yīng)的分組丟棄概率，從而降低源端的發(fā)送速率.如此便能有效判斷并緩解網(wǎng)絡(luò)的擁塞，同時(shí)，擁塞信息的共享又保證了各業(yè)務(wù)流間傳輸?shù)墓叫?

2.1 擁塞度量

由于無(wú)線信道的廣播共享性，同一時(shí)間只能有一個(gè)節(jié)點(diǎn)使用信道，因此在無(wú)線Ad hoc網(wǎng)絡(luò)中，節(jié)點(diǎn)總是要與其相鄰節(jié)點(diǎn)競(jìng)爭(zhēng)共享信道媒質(zhì)，沖突和丟包的現(xiàn)象會(huì)頻繁發(fā)生.在802.11 DCF協(xié)議中，節(jié)點(diǎn)每次嘗試獲取信道失敗后都要進(jìn)入二進(jìn)制指數(shù)退避過(guò)程，所以網(wǎng)絡(luò)擁塞越嚴(yán)重，信道競(jìng)爭(zhēng)就越激烈，數(shù)據(jù)傳輸失敗的次數(shù)就越多，由于傳輸失敗而執(zhí)行二進(jìn)制指數(shù)退避過(guò)程的次數(shù)也就越多.因此，本研究利用節(jié)點(diǎn)經(jīng)歷退避過(guò)程的多少反映網(wǎng)絡(luò)擁塞程度，提出了一個(gè)新的擁塞度量——退避率(pb)來(lái)描述節(jié)點(diǎn)自身的擁塞程度，退避率能夠準(zhǔn)確反映節(jié)點(diǎn)間的競(jìng)爭(zhēng)沖突以及擁塞對(duì)網(wǎng)絡(luò)造成的影響.

在802.11 DCF協(xié)議中，節(jié)點(diǎn)在如下4種情況下進(jìn)行退避過(guò)程:

(1)節(jié)點(diǎn)首次發(fā)送數(shù)據(jù)時(shí)，在分組發(fā)送之前若節(jié)點(diǎn)偵聽到信道忙，則進(jìn)行退避;

(2)節(jié)點(diǎn)在發(fā)出RTS幀之后，沒有成功接收到CTS幀，則進(jìn)行退避;

(3)節(jié)點(diǎn)在發(fā)出DATA幀之后，沒有成功接收到ACK幀，則進(jìn)行退避;

(4)當(dāng)一個(gè)數(shù)據(jù)幀被成功發(fā)送之后，節(jié)點(diǎn)需要執(zhí)行退避過(guò)程.

顯然，前3種情況都是由于節(jié)點(diǎn)擁塞或競(jìng)爭(zhēng)信道失敗造成的.定義Ns為節(jié)點(diǎn)成功發(fā)送分組后進(jìn)入退避算法的次數(shù)，Nf為節(jié)點(diǎn)發(fā)送分組失敗后進(jìn)入退避算法的次數(shù).退避率的計(jì)算公式如下:

可以看出，在已有的MAC層擁塞度量中，無(wú)論是分組重傳次數(shù)［2，19］還是被重傳的分組數(shù)［8］，都只是Nf的一個(gè)子集.分組重傳次數(shù)沒有考慮到情況(1)，而被重傳的分組數(shù)沒有考慮到每次RTS、DATA重傳對(duì)網(wǎng)絡(luò)的影響.因此，退避率能夠更有效地監(jiān)測(cè)網(wǎng)絡(luò)的擁塞和沖突，從而快速準(zhǔn)確地判斷網(wǎng)絡(luò)的擁塞程度.

2.2 擁塞信息反饋

為了盡可能少地修改IEEE 802.11 DCF協(xié)議，本研究使用RTS、CTS消息捎帶的方式，在RTS、CTS握手過(guò)程中攜帶節(jié)點(diǎn)本身的擁塞信息CI(無(wú)特殊說(shuō)明，文中的擁塞信息均指退避率)，發(fā)送節(jié)點(diǎn)、接收節(jié)點(diǎn)或相鄰節(jié)點(diǎn)在收到反饋的擁塞信息后，相應(yīng)地計(jì)算各自的分組丟棄概率.本研究在RTS、CTS消息中擴(kuò)展了擁塞信息CI字段，簡(jiǎn)稱為RTSC、CTSC，如圖2所示.

圖2 RTSC、CTSC幀格式Fig.2 Frame format of RTSC and CTSC

其中CI字段的內(nèi)容就是節(jié)點(diǎn)自身的擁塞信息，記為Cl，占用一個(gè)字節(jié).定義pb，av是數(shù)據(jù)分組的平均退避率是上次計(jì)算的平均退避率，pb是當(dāng)前分組的退避率，設(shè)a+b=1，a、b為計(jì)算系數(shù)，節(jié)點(diǎn)初始退避率是 0，pb，av的計(jì)算公式如下:

本研究取a=1/8，b=7/8，上述取值表明當(dāng)前的網(wǎng)絡(luò)狀態(tài)在計(jì)算pb，av時(shí)起主要作用，能夠保證算法對(duì)網(wǎng)絡(luò)擁塞作出快速反應(yīng).Cl攜帶的就是pb，av的信息，為了滿足在RTSC、CTSC消息中僅用一個(gè)字節(jié)攜帶 Cl，需要對(duì) pb，av的值進(jìn)行變換，即只保留 pb，av的2位有效數(shù)字填入 CI字段進(jìn)行傳輸(例如，12.3%只保留為12%，那么Cl=12%，CI字段僅發(fā)送12即可，而當(dāng)其它節(jié)點(diǎn)收到CI之后，仍要把12變回為12%后才能進(jìn)行其它方面的計(jì)算).

當(dāng)有分組需要傳輸時(shí)，發(fā)送節(jié)點(diǎn)首先計(jì)算退避率pb，更新Cl并添加到RTSC消息的CI字段中，接收節(jié)點(diǎn)在成功收到RTSC消息后，計(jì)算自身的Cl并添加到CTSC消息的CI字段中，發(fā)送給發(fā)送節(jié)點(diǎn)，發(fā)送節(jié)點(diǎn)提取CTSC消息的CI字段計(jì)算分組丟棄概率.其它的鄰居節(jié)點(diǎn)在收到RTSC、CTSC之后，提取CI字段的信息，這樣就使得一個(gè)區(qū)域內(nèi)的節(jié)點(diǎn)能夠知道周圍網(wǎng)絡(luò)的擁塞狀態(tài)，結(jié)合本節(jié)點(diǎn)的擁塞信息更新自身的分組丟棄概率，能夠改善區(qū)域內(nèi)傳輸流的公平性.如果整個(gè)網(wǎng)絡(luò)的節(jié)點(diǎn)都支持MCFCC算法，那么RTSC、CTSC中的CI字段就能被正確地解析和使用.

2.3 算法描述

為了描述MCFCC算法，用Cd表示計(jì)算分組丟棄概率時(shí)的輔助信息.定義 Cr為節(jié)點(diǎn)接收到的RTSC、CTSC消息中攜帶的擁塞信息，初值為0.MCFCC算法包括更新Cd和擁塞控制兩個(gè)過(guò)程.

(1)更新 Cd.在 MCFCC算法中，當(dāng)節(jié)點(diǎn)收到RTSC、CTSC消息時(shí)提取其中的CI字段對(duì)Cr賦值，然后按照算法1更新Cd;或者當(dāng)有新的分組到達(dá)MAC層時(shí)，也要更新Cd.為了避免一段時(shí)間內(nèi)由于節(jié)點(diǎn)沒有收到RTSC、CTSC消息使得Cr過(guò)于陳舊，也為了避免一段時(shí)間內(nèi)頻繁更新Cr，當(dāng)Cr＞Cl時(shí)，設(shè)置抑制計(jì)時(shí)器t，t時(shí)間內(nèi)不再更新Cr.算法1具體描述如下.

2)擁塞控制.本研究參照 RED［20］將節(jié)點(diǎn)擁塞程度分成無(wú)擁塞、輕度擁塞和重度擁塞3個(gè)等級(jí).設(shè)置兩個(gè)控制閾值ηmin和ηmax，對(duì)于每個(gè)節(jié)點(diǎn)，如果Cd小于ηmin，這意味著節(jié)點(diǎn)或其鄰居很少擁塞，不需要丟棄分組;當(dāng)Cd介于兩個(gè)控制閾值之間時(shí)，認(rèn)為節(jié)點(diǎn)或其鄰居發(fā)生輕度擁塞;當(dāng)Cd超過(guò)ηmax時(shí)，節(jié)點(diǎn)或其周圍網(wǎng)絡(luò)發(fā)生嚴(yán)重?fù)砣?利用Cd作為擁塞信息，節(jié)點(diǎn)按式(3)計(jì)算分組丟棄概率Pd.對(duì)于MAC層每一個(gè)新到來(lái)的分組，需要按照概率Pd判斷是否被丟棄.可以看出，擁塞程度越嚴(yán)重，被丟棄的分組就越多，TCP擁塞控制機(jī)制相應(yīng)地會(huì)減小擁塞窗口，這相當(dāng)于減小了分組發(fā)送速率，有利于緩解擁塞.

需要說(shuō)明的是，在RTSC、CTSC消息中CI字段攜帶的是節(jié)點(diǎn)本身的擁塞信息Cl而不是Cd，這是因?yàn)楣?jié)點(diǎn)只需要把自身的擁塞狀態(tài)反饋給相鄰節(jié)點(diǎn)就可以了.但是在計(jì)算節(jié)點(diǎn)分組丟棄概率時(shí)使用的是Cd，這是因?yàn)楣?jié)點(diǎn)需要考慮其周圍網(wǎng)絡(luò)的擁塞狀況，按照最壞的擁塞信息計(jì)算分組丟棄概率，這樣可以快速消除網(wǎng)絡(luò)的擁塞狀態(tài)，改善節(jié)點(diǎn)間的公平性.

MCFCC算法中，節(jié)點(diǎn)僅通過(guò)自身的MAC層信息就可以計(jì)算出退避率，利用收到的RTSC、CTSC消息獲知節(jié)點(diǎn)周圍網(wǎng)絡(luò)的擁塞狀態(tài)，按照最壞擁塞信息計(jì)算分組丟棄概率，從而做出更恰當(dāng)?shù)牟僮?使用退避率作為節(jié)點(diǎn)的擁塞度量還能夠反映出流間競(jìng)爭(zhēng)、流內(nèi)競(jìng)爭(zhēng)和隱終端問題造成的傳輸沖突引起的擁塞現(xiàn)象，上述問題正是造成無(wú)線多跳網(wǎng)絡(luò)擁塞的主要問題之一.通過(guò)偵聽鄰居節(jié)點(diǎn)的RTSC、CTSC消息，能夠改善傳輸流之間的公平性.MCFCC算法僅需對(duì)802.11 DCF協(xié)議的RTS、CTS幀做少量修改即可，不再增加額外的網(wǎng)絡(luò)開銷，簡(jiǎn)單且易于實(shí)現(xiàn)，節(jié)約了網(wǎng)絡(luò)帶寬.這使得MCFCC算法具有很多優(yōu)勢(shì):本地信息總是可用和可靠的，減少了節(jié)點(diǎn)間額外的信息交換，并減少了額外的網(wǎng)絡(luò)開銷，降低了節(jié)點(diǎn)能耗.

3 實(shí)驗(yàn)驗(yàn)證

本研究使用網(wǎng)絡(luò)模擬器NS-2［21］作為仿真平臺(tái).網(wǎng)絡(luò)層使用DSR協(xié)議，傳輸層采用TCP和UDP協(xié)議.按照IEEE 802.11標(biāo)準(zhǔn)設(shè)置實(shí)驗(yàn)參數(shù):節(jié)點(diǎn)的傳輸距離250 m，偵聽范圍550 m，無(wú)線信道帶寬2Mb/s，使用1000B的有效載荷大小.MCFCC算法中丟包策略的控制閾值 ηmin為0.1，ηmax為0.5，t為2s.實(shí)驗(yàn)測(cè)試了MCFCC算法對(duì)802.11 DCF協(xié)議的改進(jìn)效果，同時(shí)與LRED算法進(jìn)行橫向比較，分析了算法的優(yōu)缺點(diǎn).

3.1 退避率與網(wǎng)絡(luò)擁塞的關(guān)系

采用含有9個(gè)節(jié)點(diǎn)的鏈?zhǔn)酵負(fù)浣Y(jié)構(gòu)進(jìn)行仿真，每個(gè)相鄰節(jié)點(diǎn)間的距離為200m，以保證相鄰節(jié)點(diǎn)在彼此的傳輸范圍內(nèi).在實(shí)驗(yàn)的過(guò)程中，使用1個(gè)TCP流和3個(gè)UDP流作為數(shù)據(jù)源，TCP流始終存在，3個(gè)UDP流分別在50、100、150 s時(shí)加入，以考察網(wǎng)絡(luò)負(fù)載加重時(shí)退避率的變化.顯然，每加入1個(gè)UDP流，就會(huì)加大節(jié)點(diǎn)在MAC層的競(jìng)爭(zhēng)，加劇網(wǎng)絡(luò)擁塞.表1統(tǒng)計(jì)了節(jié)點(diǎn)E執(zhí)行退避過(guò)程的次數(shù)并計(jì)算得到了節(jié)點(diǎn)E的退避率.

表1 退避率與網(wǎng)絡(luò)擁塞的關(guān)系Table 1 Correlation between backoff ratio and congestion

由表1可以看到，節(jié)點(diǎn)E的退避率從10.4%上升到15.9%.這表明隨著網(wǎng)絡(luò)流量的加大，網(wǎng)絡(luò)擁塞和節(jié)點(diǎn)沖突逐漸加重，節(jié)點(diǎn)傳輸失敗后進(jìn)入退避過(guò)程的次數(shù)逐漸增多，退避率也隨著擁塞的加重而逐漸變大，即退避率與網(wǎng)絡(luò)擁塞具有一定的正相關(guān)性，故本研究用退避率度量節(jié)點(diǎn)的擁塞狀況，并設(shè)控制閾值 ηmin為 0.1、ηmax為 0.5.

3.2 吞吐量的比較

在網(wǎng)絡(luò)吞吐量仿真實(shí)驗(yàn)中，仍使用圖1的鏈?zhǔn)酵負(fù)浣Y(jié)構(gòu)，為了考察不同網(wǎng)絡(luò)負(fù)載情況下MCFCC算法的性能，設(shè)置節(jié)點(diǎn)數(shù)的變化范圍是4～40，吞吐量對(duì)比情況如圖3所示，該曲線由100次仿真結(jié)果的平均值得出(文中所有圖中標(biāo)明的802.11 DCF均指未使用 MCFCC算法的標(biāo)準(zhǔn)802.11 DCF協(xié)議).由圖3可以看出，與 LRED和802.11 DCF相比，采用MCFCC算法后吞吐量有了明顯提升.但隨著網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)的增加，網(wǎng)絡(luò)的負(fù)載加重，節(jié)點(diǎn)對(duì)共享信道的競(jìng)爭(zhēng)進(jìn)一步加劇了網(wǎng)絡(luò)擁塞，使得吞吐量明顯下降.不過(guò)，在所有情況下，觀察到MCFCC算法均能夠提高M(jìn)AC協(xié)議的性能，并且提升TCP吞吐量高達(dá)20%，同時(shí)也比使用LRED算法高5%以上，這可以解釋為L(zhǎng)RED算法缺乏對(duì)分組發(fā)送前信道狀態(tài)的感知，弱于MCFCC算法對(duì)網(wǎng)絡(luò)擁塞的控制.當(dāng)節(jié)點(diǎn)數(shù)大于15時(shí)，隨著節(jié)點(diǎn)數(shù)的增加，MCFCC算法能帶來(lái)更多的性能提升.這是因?yàn)楣?jié)點(diǎn)越多，業(yè)務(wù)流途經(jīng)的鏈路越長(zhǎng)，競(jìng)爭(zhēng)沖突現(xiàn)象就越嚴(yán)重，退避率也就越大.故節(jié)點(diǎn)數(shù)越多，MCFCC算法的優(yōu)勢(shì)就越明顯，MCFCC算法能夠及早丟包，從而減小發(fā)送節(jié)點(diǎn)的分組發(fā)送速率，降低了傳輸業(yè)務(wù)流間的競(jìng)爭(zhēng)沖突，有助于改善共享信道的利用率.

圖3 吞吐量比較Fig.3 Throughput comparison

3.3 端到端延時(shí)的比較

在對(duì)比端到端延時(shí)的仿真試驗(yàn)中，使用含有9個(gè)節(jié)點(diǎn)的鏈?zhǔn)酵負(fù)浣Y(jié)構(gòu)，仿真結(jié)果如圖4所示.由圖4可以看出，與LRED算法和802.11 DCF相比，采用MCFCC算法后端到端延時(shí)顯著減少.這是因?yàn)镸CFCC算法總是監(jiān)測(cè)節(jié)點(diǎn)對(duì)共享信道的競(jìng)爭(zhēng)程度，及早發(fā)現(xiàn)網(wǎng)絡(luò)擁塞，提前做出反應(yīng)，這大大緩解了MAC層的競(jìng)爭(zhēng)沖突，減少M(fèi)AC層分組重傳次數(shù)，降低了MAC層延時(shí).同時(shí)，MCFCC算法使得TCP不用等到MAC層達(dá)到重傳閾值(RTS7次，DATA4次)丟包后才能做出響應(yīng)，這也減少了分組傳輸延時(shí).MCFCC算法對(duì)網(wǎng)絡(luò)擁塞的判斷比LRED算法更加準(zhǔn)確，而且由于MCFCC算法能夠接收來(lái)自鄰居節(jié)點(diǎn)的擁塞狀態(tài)，更能先于LRED算法發(fā)現(xiàn)擁塞，及早處理，降低了端到端延時(shí).仿真開始時(shí)網(wǎng)絡(luò)負(fù)載不大，MCFCC、LRED算法對(duì)網(wǎng)絡(luò)延時(shí)影響不大，隨著網(wǎng)絡(luò)負(fù)載的增加，MCFCC算法能夠?qū)砣皶r(shí)地判斷和處理，使得網(wǎng)絡(luò)可以始終保持在低擁塞、低沖突的狀態(tài)，減少了分組等待時(shí)間，因此，使用了MCFCC算法的IEEE 802.11 DCF協(xié)議具有更低的端到端延時(shí).

圖4 端到端延時(shí)比較Fig.4 End-to-end delay comparison

3.4 公平性的比較

本研究使用圖5的仿真場(chǎng)景驗(yàn)證MCFCC算法的公平性.圖中的3條FTP/TCP流互相沒有公用的轉(zhuǎn)發(fā)節(jié)點(diǎn)，但圖中的節(jié)點(diǎn)都在互相的干擾范圍之內(nèi)，考察MCFCC算法對(duì)節(jié)點(diǎn)公平性的改進(jìn)，仿真結(jié)果見圖6.由圖6可以看到，在未使用MCFCC算法的802.11 DCF協(xié)議中，F(xiàn)TP2的吞吐量幾乎為0，在LRED場(chǎng)景中，F(xiàn)TP2的吞吐量也遠(yuǎn)低于 FTP1和FTP3.這是因?yàn)镕TP2同時(shí)面對(duì)兩條業(yè)務(wù)流的競(jìng)爭(zhēng)，其失敗的次數(shù)較多，每次失敗都會(huì)使TCP擁塞控制機(jī)制減少源節(jié)點(diǎn)A的擁塞窗口，執(zhí)行慢啟動(dòng)階段，這更加削弱了FTP2的競(jìng)爭(zhēng)力.業(yè)務(wù)流FTP1和FTP3則保持著良好的傳輸狀態(tài)，使得它們誤認(rèn)為當(dāng)前網(wǎng)絡(luò)沒有擁塞.而且，由于參與競(jìng)爭(zhēng)信道的傳輸流之間沒有合作機(jī)制，一旦某個(gè)流被“餓死”就很難恢復(fù)出來(lái).在MCFCC算法中，RTSC、CTSC捎帶的擁塞信息能夠讓節(jié)點(diǎn)了解其周圍的網(wǎng)絡(luò)狀況，從而控制自身的發(fā)送速率，避免了“餓死”現(xiàn)象的發(fā)生.實(shí)驗(yàn)中流FTP2由于連續(xù)的競(jìng)爭(zhēng)失敗使得其CI值較大，當(dāng)其成功發(fā)出 RTSC、CTSC消息后，流 FTP1、FTP3旁聽到這些消息，知道某個(gè)相鄰節(jié)點(diǎn)擁塞嚴(yán)重，根據(jù)收到的CI重新計(jì)算自己的分組丟棄概率，從而降低了自身的發(fā)送速率，流FTP2就會(huì)重新競(jìng)爭(zhēng)到信道，使得自己不會(huì)被“餓死”.

圖5 3條FTP傳輸流Fig.5 Three FTP flows

圖6 3條FTP傳輸流的平均吞吐量Fig.6 Average throughput of three FTP flows

4 結(jié)語(yǔ)

在無(wú)線Ad hoc網(wǎng)絡(luò)中，節(jié)點(diǎn)每次發(fā)送分組都要競(jìng)爭(zhēng)共享媒質(zhì)，這往往導(dǎo)致分組傳輸沖突，引起網(wǎng)絡(luò)擁塞和不公平問題，造成網(wǎng)絡(luò)性能嚴(yán)重下降.為解決以上問題，本研究提出了一種基于媒質(zhì)共享的公平擁塞控制(MCFCC)算法.在該算法中，提出了一種新的MAC層擁塞度量——媒質(zhì)競(jìng)爭(zhēng)失敗的退避次數(shù)，并仿真驗(yàn)證了該度量的有效性;設(shè)計(jì)了一種節(jié)點(diǎn)間交換擁塞信息的方法，有效改善了各業(yè)務(wù)流間的公平性，避免出現(xiàn)某些節(jié)點(diǎn)被“餓死”的現(xiàn)象.仿真結(jié)果表明，MCFCC算法能夠準(zhǔn)確判斷、緩解網(wǎng)絡(luò)擁塞，顯著提高網(wǎng)絡(luò)的性能，降低端到端延時(shí)，改善業(yè)務(wù)流間的公平性.下一步將針對(duì)大規(guī)模的復(fù)雜場(chǎng)景進(jìn)行仿真實(shí)驗(yàn)，特別是通過(guò)實(shí)驗(yàn)床實(shí)驗(yàn)進(jìn)一步驗(yàn)證算法的有效性.

［1］Chen K，Xue Y，Nahrstedt K.On setting TCP's congestion window limit in mobile Ad hoc networks［C］∥Proceedings of IEEE International Conference on Communications.Anchorage:IEEE，2003:1080-1084.

［2］Fu Z，Zerfos P，Luo H，et al.The impact of multihop wireless channel on TCP throughput and loss［C］∥Proceedings of the 22ndAnnual Joint Conference of the IEEE Computer and Communications Societies.San Francisco:IEEE，2003:1744-1753.

［3］Chen X，Zhai H，Wang J，et al.TCP performance over mobile Ad hoc networks［J］.Canndian Journal of Electrical and Computer Engineering，2004，29(1):129-134.

［4］Xu W，Wu T.TCP issues in mobile Ad hoc networks:challenges and solutions［J］.Journal of Computer Science and Technology，2006，21(1):72-81.

［5］Nahm K，Helmy A，Kuo C-CJ.TCP over multihop 802.11 networks:issues and performance enhancement［C］∥Proceedings of the 6thACM International Symposium on Mobile Ad hoc Networking and Computing.Chicago:ACM，2005:277-287.

［6］De Oliveira R，Braun T.A dynamic adaptive acknowledgment strategy for TCP over multihop wireless networks［C］∥Proceedings of the 24thAnnual Conference Sponsored by IEEE Communications Society.Miami:IEEE，2005:1863-1874.

［7］Razafindralambo T，Lassous I G.SBA:a simple backoff algorithm for wireless Ad hoc networks［J］.Springer Lecture Notes in Computer Science，2009，5550:416-428.

［8］Shen M，Zhao D.Opportunistic link scheduling for multihop wireless networks［J］.IEEE Transactions on Wireless Communications，2009，8(1):234-244.

［9］Armaghani F R，Jamuar S S，Khatun S，et al.An adaptive TCP delayed acknowledgment strategy in interaction with MAC layer over multi-hop ad-hoc networks［C］∥Proceedings of the 2008 International Symposium on Computer Science and Its Applications.Hobart:IEEE Computer Society，2008:137-142.

［10］Wu W，Zhang Z，Sha X et al.Auto rate MAC protocol based on congestion detection for wireless Ad hoc networks［J］.Information Technology Journal，2009，8(8):1205-1212.

［11］IEEE Standard 802.11—1999，Wireless LAN medium access control and physical layer specifications［S］.

［12］王慶輝，潘學(xué)松，王光興.基于帶寬估計(jì)的Ad hoc網(wǎng)絡(luò)擁塞控制機(jī)制［J］.通信學(xué)報(bào)，2006，27(4):42-48.Wang Qing-hui，Pan Xue-song，Wang Guang-xing.Congestion control mechanism based on bandwidth estimation in Ad hoc networks［J］.Journal on Communications，2006，27(4):42-48.

［13］Zhang X，Lü J，Han X，et al.Channel efficiency-based transmission rate control for congestion avoidance in wireless Ad hoc networks［J］.IEEE Communications Letters，2009，13(9):706-708.

［14］Zhai H，Chen X，F(xiàn)ang Y.Improving transport layer performance in multihop Ad hoc networks by exploting MAC layer information ［J］.IEEE Transactions on Wireless Communications，2007，6(5):1692-1701.

［15］Zhai H，F(xiàn)ang Y.Distributed flow control and medium access in multihop Ad hoc networks［J］.IEEE Transactions on Mobile Computing，2006，5(11):1503-1514.

［16］Zhai H，Wang J，F(xiàn)ang Y.Distributed packet scheduling for multihop flows in Ad hoc networks［C］∥Proceedings of IEEE Wireless Communications and Networking Conference.Atlanta:IEEE，2004:1081-1086.

［17］Xu K，Gerla M，Qi L，et al.TCP unfairness in Ad hoc wireless networks and a neighborhood RED solution［J］.Wireless Networks，2005，11(4):383-399.

［18］Xu S，Saadawi T.Does the IEEE 802.11 MAC protocol work well in multihop wireless Ad hoc newtorks?［J］.IEEE Communications Magazine，2001，39(6):130-137.

［19］Liu Z，Park C，Lee B，et al.A routing agent using crosslayer method for collision avoidance in Ad hoc networks［J］.Springer Lecture Notes in Computer Science，2009，5559:325-334.

［20］Floyd S，Jacobson V.Random early detection gateways for congestion avoidance［J］.IEEE/ACM Trans Actions on Networking，1993，1(4):397-413.

［21］The network simulator-ns-2 ［EB/OL］.［2009-03-10］.http://www.isi.edu/nsnam/ns.