一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議的制作方法
【專利摘要】本發(fā)明公開了基于握手、時(shí)隙及選擇性重傳的一種高效、低數(shù)據(jù)包沖突概率的水下介質(zhì)訪問控制協(xié)議，有效解決了當(dāng)前水下通信長延時(shí)及高錯(cuò)誤概率的現(xiàn)狀。本協(xié)議具有三個(gè)特點(diǎn)：（1）通過握手來避免沖突：可以有效解決暴露/隱藏終端（exposed/hidden terminal）問題，且本協(xié)議一次握手可以發(fā)送多個(gè)數(shù)據(jù)包，在長傳輸延遲的網(wǎng)絡(luò)環(huán)境（如水下無線網(wǎng)絡(luò)）下具有更高效率；（2）采用時(shí)隙機(jī)制來減小沖突窗口：在無線網(wǎng)絡(luò)中，沖突窗口大小和數(shù)據(jù)包沖突概率具有正相關(guān)的關(guān)系，因此，本協(xié)議時(shí)隙機(jī)制可將沖突窗口減半，從而大大降低數(shù)據(jù)包沖突概率；（3）采用選擇性重傳：降低了成功發(fā)送一個(gè)數(shù)據(jù)包所需要的平均時(shí)間；在給定的網(wǎng)絡(luò)丟包率條件下，可降低網(wǎng)絡(luò)能耗、提高網(wǎng)絡(luò)效率。
【專利說明】
一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議
技術(shù)領(lǐng)域
[0001] 本發(fā)明涉及一種高效水下介質(zhì)訪問控制協(xié)議，尤其涉及一種選擇性重傳、握手和 時(shí)隙的水下介質(zhì)訪問控制協(xié)議，屬于水下通信、水聲通信、多跳協(xié)同網(wǎng)絡(luò)以及信息傳輸?shù)燃?術(shù)領(lǐng)域。
【背景技術(shù)】
[0002] 在網(wǎng)絡(luò)協(xié)議中，介質(zhì)訪問控制協(xié)議負(fù)責(zé)在一個(gè)共享的信道中提供點(diǎn)對點(diǎn)的數(shù)據(jù)通 訊。對于無線通訊而言，相鄰網(wǎng)絡(luò)節(jié)點(diǎn)共享一個(gè)信道，當(dāng)它們同時(shí)發(fā)送數(shù)據(jù)時(shí)，會對彼此造 成干擾，引起數(shù)據(jù)包接收的失敗，也稱數(shù)據(jù)包沖突。為了解決這一問題，介質(zhì)訪問控制協(xié)議 應(yīng)運(yùn)而生。它是數(shù)據(jù)鏈路層的一個(gè)子層，主要用來改善數(shù)據(jù)鏈路層的數(shù)據(jù)包沖突問題，并與 此同時(shí)盡量提高信道利用率和網(wǎng)絡(luò)吞吐率。
[0003] 文獻(xiàn)"J. - H. Cui，J. Kong, M. Gerla，and S. Zhou, "Challenges: building scalable mobile underwater wireless sensor networks for aquatic applications,，' IEEE Network, Special Issue on Wireless Sensor Networking, vol. 20, no. 3, pp. 12-18, May 2006. " 和文獻(xiàn) "M. Chitre, S. Shahabudeen, and M. Sto janovic, "Underwater acoustic communication and networks: Recent advanced ans future challenges,，' Marine Technology Society Journal, no. I, pp. 103-116，2006. "詳 細(xì)闡述了水下通信網(wǎng)絡(luò)的顯著進(jìn)展。雖然有大量的網(wǎng)絡(luò)設(shè)計(jì)，但是網(wǎng)絡(luò)協(xié)議的實(shí)現(xiàn)和實(shí)際 測試還幾乎沒有，尤其是海洋實(shí)測研究。水聲網(wǎng)絡(luò)通信協(xié)議最具挑戰(zhàn)的特點(diǎn)就是長的傳輸 延時(shí)，高錯(cuò)誤概率及動態(tài)拓?fù)?。除此之外，協(xié)議實(shí)現(xiàn)，測試及評估也遇到更大困難。協(xié)議需 要通過在控制水聲調(diào)制器的微控制器上實(shí)現(xiàn)。為了測試多個(gè)水聲網(wǎng)絡(luò)節(jié)點(diǎn)，需要部署單節(jié) 點(diǎn)重達(dá)幾百磅的多個(gè)節(jié)點(diǎn)，通常，鋪設(shè)8個(gè)節(jié)點(diǎn)就需要花一天時(shí)間。因此，大部分的網(wǎng)絡(luò)協(xié) 議都沒有經(jīng)過實(shí)際網(wǎng)絡(luò)測試。
[0004] 水聲通信網(wǎng)絡(luò)的接入?yún)f(xié)議，主要有隨機(jī)接入和協(xié)作機(jī)制兩類。文獻(xiàn)"N. Chirdchoo, ff. -S. Soh, and K. C. Chua, ^Aloha-based MAC protocols with collision avoidance for underwater acoustic networks, ，' in Proceedings of IEEE INF0C0M，2007. "為基于Aloha的協(xié)議采用隨機(jī)信道接入機(jī)制。隨機(jī)接入?yún)f(xié)議會引入最小 負(fù)載的控制包；因此，通常會產(chǎn)生更多碰撞。為了避免碰撞，需要在傳輸前進(jìn)行對話。
[0005] 文獻(xiàn)"M. Molins and M. Stojanovic, "Slotted fama: a mac protocol for underwater acoustic networks,，' in Proceedings of MTS/IEEE OCEANS, 2006.，'米 用基于RTS/CTS的握手及時(shí)隙設(shè)計(jì)來避免沖突。文獻(xiàn)"X. Guo，M. R. Frater，andM.J. Ryan, ，'Design of a propagation-delay-tolerant MAC protocol for underwater acoustic sensor networks,，' in IEEE Journal of Oceanic Engineering, 2009.，'提出 了一種改進(jìn)的握手機(jī)制。通過精確設(shè)計(jì)延遲傳輸CTS及數(shù)據(jù)包，可以使用傳播延遲間隙，文 中提出的APCAP協(xié)議能夠提高總數(shù)據(jù)傳輸?shù)男省?br>[0006] 除了握手機(jī)制以外，文獻(xiàn) "A. A. Syed, W. Ye, and J. Heidemann, " T-Lohi: A new class of MAC protocols for underwater acoustic sensor networks, ，' in Proceedings of IEEE INFOCOM，2008. "采用隨機(jī)退避機(jī)制，顯著降低網(wǎng)絡(luò)擁塞及碰撞概 率。通過分析，上述方法已被證明有效，因此，成為目前MAC協(xié)議中應(yīng)用最為廣泛的。
[0007] 文獻(xiàn)"C. Petrioli，R. Petroccia，and J. Potter, "Performance evaluation of underwater MAC protocols: From simulation to at-sea testing, ，' in Proceedings of MTS/IEEE OCEANS, May 2012. "闡述了水下實(shí)測與仿真的差距，主要體現(xiàn)在仿真對于水 下環(huán)境的動態(tài)估計(jì)能力有限，導(dǎo)致實(shí)測與仿真結(jié)果存在很大差距。
[0008] 綜上所述，我們知道了水下無線網(wǎng)絡(luò)通信具有自身特殊性，導(dǎo)致傳統(tǒng)的介質(zhì)訪問 控制協(xié)議無法高效工作，存在若干技術(shù)局限。
[0009] 首先，針對地面有線網(wǎng)絡(luò)設(shè)計(jì)的介質(zhì)訪問控制協(xié)議一般采用載波偵聽技術(shù)來監(jiān)測 沖突。由于無線網(wǎng)絡(luò)通訊硬件大多工作在單工狀態(tài)，沒法同時(shí)進(jìn)行數(shù)據(jù)發(fā)送和載波偵聽。因 此，以帶沖突檢測的載波監(jiān)聽多路訪問技術(shù)（CSM/⑶）為代表的協(xié)議沒法有效工作。
[0010] 其次，針對地面無線網(wǎng)絡(luò)設(shè)計(jì)的介質(zhì)訪問控制協(xié)議沒有考慮水下無線網(wǎng)絡(luò)特有的 長信號傳播時(shí)延。這導(dǎo)致以載波監(jiān)聽多路訪問/沖突避免（CSMA/CA)為代表的協(xié)議在水下 環(huán)境下難以取得滿意的性能。
[0011] 本申請文件致力于提出一種用于水聲網(wǎng)絡(luò)通信的高效協(xié)作傳輸協(xié)議。所提協(xié)議已 經(jīng)經(jīng)過部署于實(shí)際海洋環(huán)境網(wǎng)絡(luò)節(jié)點(diǎn)的測試，具有非常重要的實(shí)踐指導(dǎo)價(jià)值。

【發(fā)明內(nèi)容】

[0012] 本發(fā)明的目的在于通過設(shè)計(jì)握手、時(shí)隙及選擇性重傳策略，提出一種沖突避免的 水下介質(zhì)訪問控制技術(shù)，降低水下無線網(wǎng)絡(luò)通信的數(shù)據(jù)包沖突概率和提升網(wǎng)絡(luò)傳輸效率。
[0013] 本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"是通過以下技術(shù) 方案實(shí)現(xiàn)的。
[0014] 假設(shè)節(jié)點(diǎn)i和節(jié)點(diǎn)i+Ι分別是數(shù)據(jù)源節(jié)點(diǎn)和目的節(jié)點(diǎn)；節(jié)點(diǎn)i-Ι和節(jié)點(diǎn)i+2分別 是源節(jié)點(diǎn)和目的節(jié)點(diǎn)的一跳鄰居節(jié)點(diǎn)，它們可以分別偵聽到源節(jié)點(diǎn)i和目的節(jié)點(diǎn)i+ι的數(shù) 據(jù)傳輸；且假設(shè)時(shí)間軸被劃分為等長的時(shí)隙：時(shí)隙長度是一個(gè)可以被用戶指定的參數(shù)，其 取值和物理層設(shè)備的工作特性相關(guān)，建議值為網(wǎng)絡(luò)中點(diǎn)對點(diǎn)傳輸?shù)淖铋L信號傳輸延時(shí)加上 物理層的傳播時(shí)延。
[0015] 本申請中有RTS、CTS、HDR、NACK及ACK五種控制包：其中，RTS控制包和CTS控制 包用于握手；HDR控制包是新型控制包，在傳輸控制包或重新傳輸數(shù)據(jù)包之前，從源節(jié)點(diǎn)發(fā) 送到目的節(jié)點(diǎn)，其承載著數(shù)據(jù)包數(shù)目信息，同時(shí)用于選擇重傳及碰撞避免：一方面，通知目 的節(jié)點(diǎn)欲傳輸?shù)臄?shù)據(jù)包數(shù)量，使得接收節(jié)點(diǎn)可以構(gòu)建NACK或ACK控制包；另一方面，相鄰節(jié) 點(diǎn)也可以根據(jù)偵聽到的數(shù)據(jù)包數(shù)量信息，選擇相應(yīng)的退避時(shí)間。上述所有五種建立連接用 的控制包，其發(fā)送都必須在一個(gè)時(shí)隙的開始時(shí)。
[0016] 具體實(shí)施步驟如下： 步驟一、當(dāng)源節(jié)點(diǎn)i欲向目的節(jié)點(diǎn)i+ι傳輸數(shù)據(jù)時(shí)，在下一時(shí)隙的開始時(shí)刻，源節(jié)點(diǎn)i 首先發(fā)出一個(gè)"請求發(fā)送"（RTS)控制包； 其中，所述的RTS控制包中的信息包括目的節(jié)點(diǎn)i+Ι的編號（ID)、要發(fā)送的數(shù)據(jù)包個(gè)數(shù) 以及數(shù)據(jù)長度。
[0017] 步驟二、若節(jié)點(diǎn)i_l偵聽到RTS控制包后，將進(jìn)行退避（Backoff)，以免造成節(jié)點(diǎn)i 處數(shù)據(jù)包沖突；與此同時(shí)，當(dāng)目的節(jié)點(diǎn)i+Ι收到RTS控制包后，它在下一時(shí)隙的開始時(shí)刻，用 "允許發(fā)送"（CTS)控制包進(jìn)行應(yīng)答； 其中，所述的CTS控制包中的信息包括源節(jié)點(diǎn)i的ID、要接收的數(shù)據(jù)包個(gè)數(shù)以及數(shù)據(jù)長 度。
[0018] 步驟三、與步驟二類似，若節(jié)點(diǎn)i+Ι聽到CTS控制包信息之后，同樣會進(jìn)行退避 (Backoff)，以避免造成沖突；CTS控制包被源節(jié)點(diǎn)i收到以后，在下一時(shí)隙的開始時(shí)刻，源 節(jié)點(diǎn)i發(fā)送一個(gè)清單包（HDR)控制包； 其中，所述的清單控制包包含了要傳輸?shù)臄?shù)據(jù)包個(gè)數(shù)和每個(gè)數(shù)據(jù)包的ID。
[0019] 步驟四、源節(jié)點(diǎn)i連續(xù)、順序發(fā)送步驟三節(jié)點(diǎn)i發(fā)送的HDR控制包所指示的數(shù)據(jù)包 到目的節(jié)點(diǎn)i+Ι ; 其中，步驟四中的連續(xù)、順序發(fā)送的數(shù)據(jù)包可占據(jù)多個(gè)時(shí)隙。
[0020] 步驟五、當(dāng)目的節(jié)點(diǎn)i+Ι接收完畢之后，比較HDR控制包中源節(jié)點(diǎn)打算發(fā)送的數(shù)據(jù) 包編號以及實(shí)際收到的數(shù)據(jù)包編號。根據(jù)比較結(jié)果，選擇下述A或B步驟執(zhí)行： A)若一致，則表明所有數(shù)據(jù)包傳輸成功，目的節(jié)點(diǎn)i+Ι向源節(jié)點(diǎn)i發(fā)送一個(gè)應(yīng)答（ACK) 控制包，轉(zhuǎn)至步驟八。
[0021] B)若不一致，則表明有數(shù)據(jù)包丟失，目的節(jié)點(diǎn)i+Ι向源節(jié)點(diǎn)i發(fā)送一個(gè)否定應(yīng)答 (NACK)控制包，轉(zhuǎn)到步驟六。
[0022] 其中，所述的NACK控制包中列出沒有傳輸成功的數(shù)據(jù)包編號。
[0023] 步驟六、若收到NACK控制包，源節(jié)點(diǎn)i在確定哪些數(shù)據(jù)包丟失后，在下一個(gè)時(shí)隙開 始時(shí)刻，發(fā)送一個(gè)HDR控制包到目的節(jié)點(diǎn)i+Ι ; 其中，所述的HDR控制包含重新傳輸?shù)臄?shù)據(jù)包個(gè)數(shù)及其編號。
[0024] 步驟七、源節(jié)點(diǎn)i重新發(fā)送步驟六中源節(jié)點(diǎn)i發(fā)送的HDR控制包指示的數(shù)據(jù)包到 目的節(jié)點(diǎn)i+Ι，轉(zhuǎn)至步驟五； 步驟八、至此，源節(jié)點(diǎn)i向目的節(jié)點(diǎn)i+Ι傳輸信息完畢。轉(zhuǎn)至步驟一，開始下一輪的信 息傳輸。
[0025] 本發(fā)明的關(guān)鍵技術(shù)點(diǎn)有如下四條： (1) 通過握手來避免沖突，解決暴露/隱藏終端（exposed/hidden terminal)問題； (2) -次握手可以發(fā)送多個(gè)數(shù)據(jù)包，以適應(yīng)長傳輸延時(shí)的網(wǎng)絡(luò)環(huán)境； (3) 用時(shí)隙來減小沖突窗口，減低數(shù)據(jù)包沖突概率； (4) 采用選擇性重傳，在給定丟包率下，在統(tǒng)計(jì)上降低成功發(fā)送一個(gè)數(shù)據(jù)包所需要的平 均時(shí)間，大大提1? 了網(wǎng)絡(luò)效率。
[0026] 有益效果 本發(fā)明是一種基于握手、時(shí)隙及選擇性重傳的水下介質(zhì)訪問控制協(xié)議，具有如下有益 效果： 1.本協(xié)議通過握手來避免沖突，可以有效解決隱藏/暴露終端（exposed/hidden terminal)問題。
[0027] 2.本協(xié)議一次握手可以發(fā)送多個(gè)數(shù)據(jù)包，在長傳輸延時(shí)的網(wǎng)絡(luò)環(huán)境(如水下無線 網(wǎng)絡(luò)）下具有更高效率。
[0028] 3.本協(xié)議采用了時(shí)隙來減小沖突窗口。在無線網(wǎng)絡(luò)中，沖突窗口大小和數(shù)據(jù)包沖 突概率具有正相關(guān)的關(guān)系。理論上來說，采用時(shí)隙可以將沖突窗口減半，可以大大降低數(shù)據(jù) 包沖突概率。
[0029] 4.采用選擇性重傳可以降低網(wǎng)絡(luò)能耗，提高網(wǎng)絡(luò)效率，在給網(wǎng)絡(luò)定丟包率下，在 統(tǒng)計(jì)上降低成功發(fā)送一個(gè)數(shù)據(jù)包所需要的平均時(shí)間。
【附圖說明】
[0030] 圖1是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"和實(shí)施 例1中系統(tǒng)工作的流程示意圖。
[0031] 圖2是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中四節(jié)點(diǎn)網(wǎng)絡(luò)的平均傳輸延時(shí)示意圖。
[0032] 圖3是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中七節(jié)點(diǎn)網(wǎng)絡(luò)的平均傳輸延時(shí)示意圖。
[0033] 圖4是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中八節(jié)點(diǎn)網(wǎng)絡(luò)的平均傳輸延時(shí)示意圖。
[0034] 圖5是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中四節(jié)點(diǎn)網(wǎng)絡(luò)的單跳隊(duì)列時(shí)延與單跳數(shù)據(jù)包的包傳遞時(shí)間的關(guān)系示意圖； 其中，圖中的"隊(duì)列時(shí)延"對應(yīng)單跳隊(duì)列時(shí)延；而"總傳輸時(shí)延"對應(yīng)著單跳數(shù)據(jù)包的包 傳遞時(shí)間。
[0035] 圖6是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中七節(jié)點(diǎn)網(wǎng)絡(luò)的單跳隊(duì)列時(shí)延與單跳數(shù)據(jù)包的包傳遞時(shí)間的關(guān)系示意圖； 其中，圖6中的圖示說明與圖5相同。
[0036] 圖7是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 2中八節(jié)點(diǎn)網(wǎng)絡(luò)的單跳隊(duì)列時(shí)延與單跳數(shù)據(jù)包的包傳遞時(shí)間的關(guān)系示意圖； 其中，圖7中的圖示說明與圖5相同。
[0037] 圖8是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 3中端到端傳輸延時(shí)的示意圖。
[0038] 圖9是本發(fā)明"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"實(shí)施例 3中端到端吞吐量的示意圖。
【具體實(shí)施方式】
[0039] 下面結(jié)合附圖1、圖2和圖3以及實(shí)施例對本發(fā)明做進(jìn)一步說明和詳細(xì)描述。
[0040] 在本發(fā)明指出的協(xié)議中，我們把時(shí)間軸劃分為等長的時(shí)隙。時(shí)隙的長度是一個(gè)可 以用戶指定的參數(shù)，其取值和物理層設(shè)備的工作特性相關(guān)，建議值為網(wǎng)絡(luò)中點(diǎn)對點(diǎn)傳輸?shù)?最長信號傳輸時(shí)延加上物理層的傳播延時(shí)。所有建立連接用的控制包(例如RTS/CTS/HDR) 的發(fā)送都必須在一個(gè)時(shí)隙的開始時(shí)。
[0041] 本協(xié)議的工作流程如圖1所示。假設(shè)節(jié)點(diǎn)i和節(jié)點(diǎn)i+Ι分別是數(shù)據(jù)源節(jié)點(diǎn)和目的 節(jié)點(diǎn)。圖1中節(jié)點(diǎn)i-Ι和節(jié)點(diǎn)i+Ι分別代表源節(jié)點(diǎn)i和目的節(jié)點(diǎn)i+Ι的一跳鄰居節(jié)點(diǎn)，這 些一跳鄰居節(jié)點(diǎn)可以為一個(gè)或多個(gè)，本申請為簡單起見，只列出一個(gè)；它們可以分別偵聽到 源節(jié)點(diǎn)i和目的節(jié)點(diǎn)i+ι發(fā)送的控制包和數(shù)據(jù)包傳輸。
[0042] 當(dāng)源節(jié)點(diǎn)i打算向目的節(jié)點(diǎn)i + Ι傳輸數(shù)據(jù)時(shí)，在下一時(shí)隙的開始時(shí)刻，它首先發(fā)出 一個(gè)"請求發(fā)送"(RTS)控制包。RTS控制包中的信息包括目的節(jié)點(diǎn)i+Ι的編號（ID)，要發(fā)送 的數(shù)據(jù)包個(gè)數(shù)，以及數(shù)據(jù)長度。節(jié)點(diǎn)i-Ι偵聽到RTS控制包。之后，將進(jìn)行退避（Backoff)， 以避免造成沖突。
[0043] 當(dāng)目的節(jié)點(diǎn)i+Ι收到RTS控制包后，它在下一時(shí)隙的開始時(shí)刻，用"允許發(fā)送" (CTS)控制包進(jìn)行應(yīng)答。CTS控制包中的信息包括源節(jié)點(diǎn)ID，要接收的數(shù)據(jù)包個(gè)數(shù)，以及數(shù) 據(jù)長度。節(jié)點(diǎn)i+Ι聽到控制包之后，同樣會進(jìn)行退避（Backoff)，以避免造成沖突。
[0044] 當(dāng)CTS控制包被源節(jié)點(diǎn)i收到以后，在下一時(shí)隙的開始時(shí)刻，該節(jié)點(diǎn)i首先發(fā)送一 個(gè)清單包（HDR)控制包。這個(gè)控制包中包含了要傳輸?shù)臄?shù)據(jù)包個(gè)數(shù)和每個(gè)數(shù)據(jù)包的ID。之 后源節(jié)點(diǎn)i便連續(xù)的順序發(fā)送數(shù)據(jù)包。這些數(shù)據(jù)包可以占據(jù)多個(gè)時(shí)隙。為簡單起見，本實(shí) 施例發(fā)送3個(gè)數(shù)據(jù)包，數(shù)據(jù)包ID分別為1、2和3,如圖1中所示。
[0045] 當(dāng)目的節(jié)點(diǎn)i+Ι接收完畢之后，比較HDR控制包中源節(jié)點(diǎn)i打算發(fā)送的數(shù)據(jù)包編 號，以及實(shí)際收到的數(shù)據(jù)包編號。如果一致，則發(fā)送一個(gè)應(yīng)答（ACK)控制包。反之，則表明 有數(shù)據(jù)包丟失，于是向源節(jié)點(diǎn)i發(fā)送一個(gè)否定應(yīng)答（NACK)控制包。NACK包中列出沒有傳輸 成功的數(shù)據(jù)包編號。本實(shí)施例2中，因?yàn)閿?shù)據(jù)包2傳輸錯(cuò)誤比較的結(jié)果是不一致，因此目的 節(jié)點(diǎn)i+Ι向源節(jié)點(diǎn)發(fā)送NACK控制包，控制包中包含丟失數(shù)據(jù)包ID及丟失個(gè)數(shù)。本實(shí)施例 2中丟失數(shù)據(jù)包為1個(gè)，丟失數(shù)據(jù)包ID為2。
[0046] 源節(jié)點(diǎn)i如果收到ACK控制包，表明所有數(shù)據(jù)傳輸成功，可以開始下一輪的信道競 爭。如果收到NACK控制包，源節(jié)點(diǎn)i查看控制包中的信息，得到數(shù)據(jù)包的ID編號。之后， 源節(jié)點(diǎn)i在下一個(gè)時(shí)隙開始時(shí)刻，發(fā)送一個(gè)HDR控制包，列出要重新發(fā)送的數(shù)據(jù)包個(gè)數(shù)及其 編號，緊接著便開始數(shù)據(jù)重傳。本實(shí)施例2中，源節(jié)點(diǎn)i收到的是NACK控制包，得知丟失數(shù) 據(jù)包的編號為2 ;接下來源節(jié)點(diǎn)i在下一時(shí)隙開始時(shí)刻，發(fā)送一個(gè)HDR控制包，列出要重新 發(fā)送的數(shù)據(jù)包個(gè)數(shù)，1個(gè)及其編號2,緊接著便開始重新傳輸數(shù)據(jù)包ID為2的數(shù)據(jù)包。
[0047] 本發(fā)明提出的"一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議"的狀態(tài)機(jī) 描述如下： 主要包含發(fā)送及接收兩個(gè)線程，分別對應(yīng)發(fā)送過程和接收過程。
[0048] 對于發(fā)送線程：起初，傳輸數(shù)據(jù)的源節(jié)點(diǎn)i處于IDLE狀態(tài)。如果需要傳輸一或多 個(gè)數(shù)據(jù)包，進(jìn)入SENDING_RTS狀態(tài)，發(fā)送RTS進(jìn)入WAIT_CTS狀態(tài)。如果CTS控制包沒有被 目的節(jié)點(diǎn)i+Ι接收到，源節(jié)點(diǎn)i將轉(zhuǎn)換到SENDER_BACKOFF狀態(tài)，并且節(jié)點(diǎn)i-Ι進(jìn)行相應(yīng)的 退避。否則，節(jié)點(diǎn)i轉(zhuǎn)換到SENDING_HDR狀態(tài)，發(fā)送HDR控制包，其后接著傳輸數(shù)據(jù)（DATA) 包，進(jìn)入WAIT_SRQ狀態(tài)。在WAIT_SRQ狀態(tài)，若超時(shí)或接收到NACK控制包后，節(jié)點(diǎn)重新回到 SENDING_HDR狀態(tài)，并且啟動重新傳輸。另一方面，如果接收到ACK控制包，或者進(jìn)入IDLE_ BACKOFF狀態(tài)或者進(jìn)入IDLE狀態(tài)，依賴于是否有其他的退避（BACKOFF)要求。
[0049] 對于接收線程：接收的RTS控制包推進(jìn)節(jié)點(diǎn)i+Ι進(jìn)入到SENDING_CTS狀態(tài)，節(jié)點(diǎn) i回復(fù)CTS控制包并進(jìn)入到WAIT_HDR狀態(tài)。接收到HDR控制包后，進(jìn)入DATA_RX狀態(tài)來收 集進(jìn)來的數(shù)據(jù)包。節(jié)點(diǎn)i進(jìn)入SENDING_SRQ狀態(tài)，并發(fā)送NACK控制包或者ACK控制包依賴 于接收到的數(shù)據(jù)包數(shù)量。若接收到的數(shù)據(jù)包數(shù)量不夠，節(jié)點(diǎn)i則進(jìn)入WAIT_HDR狀態(tài)，重新 傳輸；若接收到的數(shù)據(jù)包數(shù)量夠，則節(jié)點(diǎn)i進(jìn)入IDLE狀態(tài)。在IDLE狀態(tài)，節(jié)點(diǎn)i偵聽RTS/ CTS/HDR/NACK控制包，迫使節(jié)點(diǎn)i-1及節(jié)點(diǎn)i+1進(jìn)入IDLE_BACKOFF狀態(tài)，把相關(guān)信息嵌入 到控制包期間，一跳鄰居節(jié)點(diǎn)i-Ι及節(jié)點(diǎn)i+Ι保持靜默。
[0050] 本協(xié)議的節(jié)點(diǎn)一共有三種行為。如果其隊(duì)列中沒有需要傳輸?shù)臄?shù)據(jù)包；就處于 IDLE狀態(tài)。否則,節(jié)點(diǎn)執(zhí)行如下兩種行為： A) -方面，若節(jié)點(diǎn)被通知有可能碰撞或者因 RTS/CTS控制包丟失而握手失敗，此節(jié)點(diǎn) 就執(zhí)行退避（Backoff)，此種情況下，包在節(jié)點(diǎn)中排列，我們稱此種類型行為的時(shí)間間隔為 "隊(duì)列時(shí)延"； B) 另一方面，若節(jié)點(diǎn)感觸到?jīng)_突行為并且完成了握手，就會接著發(fā)送一組數(shù)據(jù)包，在整 組數(shù)據(jù)包發(fā)送前到所有數(shù)據(jù)包成功接收到之間的時(shí)間間隔稱為"傳輸延時(shí)"。
[0051 ] 對應(yīng)到圖1中，"傳輸延時(shí)"是指源節(jié)點(diǎn)i發(fā)出RTS控制包并成功握手到目的節(jié)點(diǎn) i+Ι收到"ACK控制包"之間的時(shí)間間隔。
[0052] 需要說明的是，如果RTS/CTS丟失，節(jié)點(diǎn)將被迫嘗試多次握手，僅在與最近一次 RTS/CTS交換相關(guān)的延遲被計(jì)算為"傳輸延時(shí)"；前次握手消耗的時(shí)間被考慮為"隊(duì)列時(shí)延" 的一部分。一個(gè)單跳數(shù)據(jù)包的傳遞時(shí)間是"傳輸延時(shí)"和"隊(duì)列時(shí)延"的和。
[0053] 實(shí)施例2 我們還進(jìn)行了海洋測試來評估本發(fā)明"一種基于選擇性重傳、握手和時(shí)隙的水下介質(zhì) 訪問控制協(xié)議"的性能。
[0054] 具體來說，主要從"跳-跳性能"(hop-by-hop)及"端-端性能"(end-t〇-end)來兩 方面來綜合評估本申請?zhí)岢龅木W(wǎng)絡(luò)協(xié)議性能。實(shí)施例2分析了"跳-跳性能"(hop-by-hop) ; 而實(shí)施例3分析了 "端-端性能"（end-to-end)。
[0055] 所測海域布置的節(jié)點(diǎn)大致在海深80米處，浪高1. 5米到2. 5米之間。海域環(huán)境受 波浪、潮汐、鹽度及溫度變化影響，也受及各類海洋哺乳動物活動影響。兩個(gè)相鄰節(jié)點(diǎn)間距 離為1千米(公里，km)，發(fā)送節(jié)點(diǎn)到接收節(jié)點(diǎn)間距離為7. 3千米(公里，km)。網(wǎng)絡(luò)拓?fù)洳捎?應(yīng)用廣泛的弦拓?fù)洌⊿tring Topology)結(jié)構(gòu)。部署了 9個(gè)水聲網(wǎng)絡(luò)節(jié)點(diǎn)，節(jié)點(diǎn)部署在新澤 西海岸邊120公里處，每個(gè)節(jié)點(diǎn)上面配置ATM-885的Teledyne Benthos Modem設(shè)備，工作 在16kHz到21kHz的頻段上，調(diào)制速率范圍為140bps到2400bps，本實(shí)施例選取300bps到 600bps范圍進(jìn)行測試，以保證通信可靠性和效率。發(fā)送節(jié)點(diǎn)在Aqua-NET應(yīng)用層運(yùn)行泊松流 量產(chǎn)生器，測試過程中，我們設(shè)置泊松流量產(chǎn)生器的產(chǎn)生速率為0. 005, 0. 015及0. 024。
[0056] 我們進(jìn)行了三組成功的測試，調(diào)制解調(diào)器（modem)的功率等級、操作速率及不同 測試的節(jié)點(diǎn)數(shù)如下表1所示：
我們組建了 5節(jié)點(diǎn)、8節(jié)點(diǎn)機(jī)9節(jié)點(diǎn)(對應(yīng)4跳、7跳及8跳)網(wǎng)絡(luò)。在所有三組測試中， 我們設(shè)定Benthos調(diào)制器的傳輸功率至最低電平來保證節(jié)點(diǎn)能到達(dá)其一跳鄰居?？紤]到海 洋環(huán)境復(fù)雜、丟包率高，故設(shè)定的包長度及數(shù)據(jù)包個(gè)數(shù)都比較少。由于端到端間的傳輸延遲 太長，我們在測試中觀察到，高的流量產(chǎn)生速率可以很容易覆蓋全網(wǎng)絡(luò)。
[0057] RTS控制包及CTS控制包攜載著包訓(xùn)練序列長度；HDR控制包含數(shù)據(jù)包的長度； NACK控制包中包含丟失數(shù)據(jù)包的數(shù)量。假設(shè)會被偵聽節(jié)點(diǎn)i-1偵聽到且要傳輸?shù)臄?shù)據(jù)包 總數(shù)為N ;偵聽到RTS控制包后，節(jié)點(diǎn)i-Ι必須，直至CTS，HDR，DATA及 ACK傳輸完
畢。因此，偵聽到RTS控制包，退避的時(shí)隙數(shù)量 了以表達(dá)為：
其中，前3個(gè)時(shí)隙是CTS，HDR及ACK ;每個(gè)占用一個(gè)時(shí)隙；而（1)公式的第二部分考慮 的是數(shù)據(jù)包的傳輸延時(shí)與傳播延時(shí)Djt ;T是時(shí)隙的長度，等于一個(gè)控制包的最大傳播時(shí) 延與傳輸延時(shí)的和。
[0058] 類似的，我們計(jì)算偵聽到CTS，HDR及NACK到退避的時(shí)隙數(shù)，如下：
其中，％^是偵聽到CTS退避的時(shí)隙數(shù)量:是偵聽到HDR退避的時(shí)隙數(shù)量； 偵聽到NACK退避的時(shí)隙數(shù)量。
[0059] 接下來，分析水下通信網(wǎng)絡(luò)的跳-跳間性能，主要包括單跳包傳輸延時(shí)及影響此 延時(shí)的因素。
[0060] 首先，我們測試了不同網(wǎng)絡(luò)的平均傳輸時(shí)延，如圖2、圖3和圖4所示，其中，圖2是 4跳網(wǎng)絡(luò)的平均傳輸延時(shí)，圖3是7跳網(wǎng)絡(luò)的平均傳輸延時(shí)，圖4是8跳網(wǎng)絡(luò)的平均傳輸延 時(shí)。傳輸延時(shí)通常包含RTS, CTS，HDR，數(shù)據(jù)（DATA )，重傳數(shù)據(jù)（DATA )、ACK及可能的NACK的 傳輸時(shí)延和傳播時(shí)延兩部分。如圖2所示，不同跳對應(yīng)的傳輸延時(shí)呈現(xiàn)很接近的一致，其原 因是，數(shù)據(jù)包丟失極少發(fā)生，因而傳輸延時(shí)的方差小。而在不同跳上顯示的小方差波動產(chǎn)生 于傳輸距離、海水溫度與鹽度變化以及聲音的傳播速度等因素。
[0061] 類似的，從圖3和圖4我們可以看出：在7跳和8跳網(wǎng)絡(luò)中，傳輸延時(shí)在保持相對 穩(wěn)定的同時(shí)出現(xiàn)了峰值點(diǎn)。翻看測試日志，我們進(jìn)一步發(fā)現(xiàn)，對于7跳網(wǎng)絡(luò)，傳輸延時(shí)主要 出現(xiàn)在5跳處；時(shí)延峰值來源于數(shù)據(jù)包的重傳；那條鏈路的數(shù)據(jù)包大量丟失，從而觸發(fā)了相 應(yīng)的選擇性重傳機(jī)制，繼而導(dǎo)致大的延遲。因此，影響傳輸延時(shí)的因素是特定跳的鏈路質(zhì) 量。即當(dāng)鏈路質(zhì)量很差時(shí)，數(shù)據(jù)包的丟失、NACK及ACK控制包引發(fā)重傳丟失的數(shù)據(jù)包，導(dǎo)致 傳輸延時(shí)增加。
[0062] 其次，我們測試了"一個(gè)單跳數(shù)據(jù)包的包傳遞時(shí)間"隊(duì)列時(shí)延的關(guān)系，如圖5到圖 7所示。與圖2到圖4所示的單跳傳輸延時(shí)相比，單跳隊(duì)列時(shí)延更大，且是總傳輸時(shí)延的重 要組成部分，此處，總傳輸時(shí)延定義為隊(duì)列時(shí)延與傳輸延時(shí)的和，即前面所述的"一個(gè)單跳 數(shù)據(jù)包的包傳遞時(shí)間"。如圖5所示，一個(gè)數(shù)據(jù)包的隊(duì)列時(shí)延定義為當(dāng)前節(jié)點(diǎn)接收到該數(shù)據(jù) 包到上次RTS控制包發(fā)出引發(fā)成功握手之間的時(shí)間間隔。前述，我們提到數(shù)據(jù)包的排隊(duì)，是 因?yàn)猷従庸?jié)點(diǎn)偵聽到傳輸正在進(jìn)行或者有RTS/CTS丟失而握手失敗，鄰居節(jié)點(diǎn)退避而產(chǎn)生 的。在測試過程中，發(fā)現(xiàn)了引發(fā)隊(duì)列時(shí)延另外一個(gè)重要因素，即：傳輸距離的不確定性導(dǎo)致 的未預(yù)料的碰撞沖突。
[0063] 在4節(jié)點(diǎn)網(wǎng)絡(luò)測試中，最大的隊(duì)列時(shí)延出現(xiàn)在跳1處，原因是我們采用了 0. 015的 流量產(chǎn)生速率，是三組測試中最高的，即源節(jié)點(diǎn)每66秒產(chǎn)生一個(gè)數(shù)據(jù)包。從圖6可以看出， "一個(gè)單跳數(shù)據(jù)包的包傳遞時(shí)間"即總傳輸時(shí)延大于150秒。而在跳3和跳4上的數(shù)據(jù)包到 達(dá)速率遠(yuǎn)低于第一跳。高的流量產(chǎn)生速率導(dǎo)致源節(jié)點(diǎn)擬發(fā)更高頻率的RTS控制包，從而導(dǎo) 致后續(xù)節(jié)點(diǎn)的RTS控制包的發(fā)送速率提高。
[0064] 相比之下，從圖6和圖7種可以發(fā)現(xiàn)，7節(jié)點(diǎn)網(wǎng)絡(luò)和8節(jié)點(diǎn)網(wǎng)絡(luò)的總傳輸時(shí)延降低 了，原因是流量產(chǎn)生速率被降至0. 005。圖6中的跳3、跳4及跳5與其他跳相比經(jīng)歷了更 大的隊(duì)列時(shí)延。原因是，在弦狀網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中，中間節(jié)點(diǎn)與邊緣節(jié)點(diǎn)相比具有更多鄰居節(jié) 點(diǎn)，這些中間節(jié)點(diǎn)能夠偵聽到兩個(gè)方向的RTS和CTS控制包。與圖6類似，圖7中的8節(jié)點(diǎn) 網(wǎng)絡(luò)中，在跳5出現(xiàn)了異常大的隊(duì)列時(shí)延。這個(gè)現(xiàn)象有兩個(gè)原因：一方面，正在進(jìn)行的傳輸 會導(dǎo)致鄰居節(jié)點(diǎn)發(fā)送和接收的退避（Backoff);另一方面，跳5也受如圖2到圖4所分析的 商包丟失概率影響。
[0065] 實(shí)施例2表明，對于網(wǎng)絡(luò)協(xié)議的"跳-跳性能"評估，該實(shí)施例僅考慮了單跳的傳 輸延時(shí)及隊(duì)列時(shí)延。結(jié)果表明，傳輸延時(shí)僅僅受給定跳的鏈路質(zhì)量影響。隊(duì)列時(shí)延通常源 于退避（Backoff)及握手失敗。
[0066] 然而，傳輸距離的不確定性能導(dǎo)致極大的偵聽負(fù)載機(jī)碰撞，也能導(dǎo)致隊(duì)列時(shí)延的 提高；因此，為降低大的隊(duì)列時(shí)延，我們進(jìn)一步考慮讓一個(gè)節(jié)點(diǎn)暫時(shí)放棄發(fā)送機(jī)會；這樣， 具有最短剩余退避（Backoff)時(shí)間的相鄰節(jié)點(diǎn)，可以作為下一時(shí)隙第一個(gè)傳輸信息的節(jié)點(diǎn)； 另一方面，由于隊(duì)列時(shí)延主要取決于傳輸距離的不確定性，因此，可以考慮通過動態(tài)網(wǎng)絡(luò)拓 撲估計(jì)而不是事先假定網(wǎng)絡(luò)拓?fù)洌瑏斫档完?duì)列時(shí)延。
[0067] 實(shí)施例3 對于網(wǎng)絡(luò)協(xié)議的"端-端性能"評估。本實(shí)施例考慮端到端傳輸延時(shí)，吞吐量，傳輸比 例，結(jié)果如圖8和圖9所示。結(jié)果表明：傳輸范圍不確定性在大網(wǎng)絡(luò)中變得嚴(yán)峻，更多節(jié)點(diǎn) 也導(dǎo)致更多的偵聽負(fù)載及更大的碰撞概率，從而也導(dǎo)致大的延遲(從圖8可以看出）。圖9 表明，網(wǎng)絡(luò)節(jié)點(diǎn)增多，吞吐量降低。
[0068] 考慮"端到端傳輸比例"，4跳，7跳及8跳三種場景都能達(dá)到100%傳輸比例，因?yàn)?本協(xié)議為選擇性ARQ機(jī)制，故保證了端到端傳輸?shù)目煽啃浴?br>[0069] 以上所述為本發(fā)明的較佳實(shí)施例而已，本發(fā)明不應(yīng)該局限于該實(shí)施例和附圖所公 開的內(nèi)容。凡是不脫離本發(fā)明所公開的精神下完成的等效或修改，都落入本發(fā)明保護(hù)的范 圍。
【主權(quán)項(xiàng)】
1.本發(fā)明的一種選擇性重傳、握手和時(shí)隙的水下介質(zhì)訪問控制協(xié)議，其特征在于： 步驟一、當(dāng)源節(jié)點(diǎn)i欲向目的節(jié)點(diǎn)i+ι傳輸數(shù)據(jù)時(shí)，在下一時(shí)隙的開始時(shí)刻，源節(jié)點(diǎn)i 首先發(fā)出一個(gè)"請求發(fā)送"（RTS)控制包； 其中，所述的RTS控制包中的信息包括目的節(jié)點(diǎn)i+Ι的編號（ID)、要發(fā)送的數(shù)據(jù)包個(gè)數(shù) 以及數(shù)據(jù)長度； 步驟二、若節(jié)點(diǎn)i-Ι偵聽到RTS控制包后，將進(jìn)行退避（Backoff)，以避免造成沖突；與 此同時(shí)，當(dāng)目的節(jié)點(diǎn)i+Ι收到RTS控制包后，它在下一時(shí)隙的開始時(shí)刻，用"允許發(fā)送"(CTS) 控制包進(jìn)行應(yīng)答； 其中，所述的CTS控制包中的信息包括源節(jié)點(diǎn)i的ID、要接收的數(shù)據(jù)包個(gè)數(shù)以及數(shù)據(jù)長 度； 步驟三、與步驟二類似，若節(jié)點(diǎn)i+Ι聽到CTS控制包信息之后，同樣會進(jìn)行退避 (Backoff)，以避免造成沖突；CTS控制包被源節(jié)點(diǎn)i收到以后，在下一時(shí)隙的開始時(shí)刻，源 節(jié)點(diǎn)i發(fā)送一個(gè)清單包（HDR)控制包； 其中，所述的清單控制包包含了要傳輸?shù)臄?shù)據(jù)包個(gè)數(shù)和每個(gè)數(shù)據(jù)包的ID ; 步驟四、源節(jié)點(diǎn)i連續(xù)、順序發(fā)送步驟三節(jié)點(diǎn)i發(fā)送的HDR控制包所指示的數(shù)據(jù)包到目 的節(jié)點(diǎn)i+Ι ; 其中，步驟四中的連續(xù)、順序發(fā)送的數(shù)據(jù)包可占據(jù)多個(gè)時(shí)隙； 步驟五、當(dāng)目的節(jié)點(diǎn)i+Ι接收完畢之后，比較HDR控制包中源節(jié)點(diǎn)打算發(fā)送的數(shù)據(jù)包編 號以及實(shí)際收到的數(shù)據(jù)包編號； 根據(jù)比較結(jié)果，選擇下述A或B步驟執(zhí)行： A) 若一致，則表明所有數(shù)據(jù)包傳輸成功，目的節(jié)點(diǎn)i+Ι向源節(jié)點(diǎn)i發(fā)送一個(gè)應(yīng)答（ACK) 控制包，轉(zhuǎn)至步驟八； B) 若不一致，則表明有數(shù)據(jù)包丟失，目的節(jié)點(diǎn)i+Ι向源節(jié)點(diǎn)i發(fā)送一個(gè)否定應(yīng)答（NACK) 控制包，轉(zhuǎn)到步驟六； 其中，所述的NACK控制包中列出沒有傳輸成功的數(shù)據(jù)包編號； 步驟六、若收到NACK控制包，源節(jié)點(diǎn)i在確定哪些數(shù)據(jù)包丟失后，在下一個(gè)時(shí)隙開始時(shí) 亥IJ，發(fā)送一個(gè)HDR控制包到目的節(jié)點(diǎn)i+Ι ; 其中，所述的HDR控制包含重新傳輸?shù)臄?shù)據(jù)包個(gè)數(shù)及其編號； 步驟七、源節(jié)點(diǎn)i重新發(fā)送步驟六中源節(jié)點(diǎn)i發(fā)送的HDR控制包指示的數(shù)據(jù)包到目的 節(jié)點(diǎn)i+Ι，轉(zhuǎn)至步驟五； 步驟八、至此，源節(jié)點(diǎn)i向目的節(jié)點(diǎn)i+Ι傳輸信息完畢；轉(zhuǎn)至步驟一，開始下一輪的信息 傳輸。
【文檔編號】H04W74/08GK106034121SQ201510115301
【公開日】2016年10月19日
【申請日】2015年3月17日
【發(fā)明人】彭鄭, 馬曉莉
【申請人】南通藍(lán)鵬信息科技有限公司, 馬曉莉, 韓貴韜