任萬春， 馬廷淮， 劉 琦

(南京信息工程大學(xué) 計(jì)算機(jī)與軟件學(xué)院，江蘇 南京 210044)

0 引 言

無線傳感器網(wǎng)絡(luò)(WSNs)在實(shí)地部署之后,隨著用戶需求的變化和技術(shù)的進(jìn)步,不可避免地需要修改傳感器節(jié)點(diǎn)的軟件功能或者修復(fù)節(jié)點(diǎn)軟件中存在的問題。傳感器節(jié)點(diǎn)可能部署在環(huán)境非常惡劣的人類不可抵達(dá)區(qū)域(如火山、深海)，人工回收傳感器節(jié)點(diǎn)也有可能破壞監(jiān)測(cè)過程(如鳥類生活習(xí)性監(jiān)測(cè))，因此，人工燒錄節(jié)點(diǎn)的方式不能滿足實(shí)際應(yīng)用的需要。使用代碼分發(fā)協(xié)議通過無線方式進(jìn)行代碼更新是上述問題的有效解決途徑[1]。代碼分發(fā)協(xié)議已經(jīng)成為現(xiàn)階段無線傳感器網(wǎng)絡(luò)研究的熱點(diǎn)問題。

Deluge協(xié)議[2]是TinyOS系統(tǒng)的標(biāo)準(zhǔn)代碼分發(fā)協(xié)議，采用ADV-REQ-DATA三次握手機(jī)制和NACK(negatrue acknowledge)機(jī)制來保證可靠性。該協(xié)議提出了分頁機(jī)制，使得網(wǎng)絡(luò)能夠使用流水線進(jìn)行空間多路分發(fā)，大大提高了分發(fā)速度。

Typhoon協(xié)議[3]使用Snoop機(jī)制進(jìn)行數(shù)據(jù)偵聽，在進(jìn)行快速重傳的同時(shí)，降低了數(shù)據(jù)碰撞概率，使用信道轉(zhuǎn)換技術(shù)解決了隱蔽站問題，提高了空間多路傳輸?shù)男省?/p>

ECD協(xié)議[4]提出了一種基于鏈路質(zhì)量的發(fā)送節(jié)點(diǎn)選擇算法，該算法選擇鏈路質(zhì)量最優(yōu)的節(jié)點(diǎn)作為發(fā)送節(jié)點(diǎn)，提高了發(fā)送節(jié)點(diǎn)選擇的精確度。此外,該協(xié)議能夠動(dòng)態(tài)地對(duì)數(shù)據(jù)包大小進(jìn)行配置，極大提高了代碼分發(fā)的效率。

SYNAPASE++協(xié)議[5]使用無比率噴泉碼對(duì)數(shù)據(jù)包進(jìn)行錯(cuò)誤恢復(fù)，通過降低數(shù)據(jù)包重傳次數(shù)提高代碼分發(fā)效率,同時(shí)采用了基于NACK的ARQ錯(cuò)誤恢復(fù)機(jī)制進(jìn)一步提高了代碼分發(fā)效率。

綜上所述，傳統(tǒng)的代碼分發(fā)協(xié)議基于傳染病[6]機(jī)制通過廣播方式進(jìn)行數(shù)據(jù)傳輸，網(wǎng)絡(luò)中所有節(jié)點(diǎn)都要參與代碼分發(fā)并接收到完整的新代碼文件。在實(shí)際應(yīng)用中，不同傳感器節(jié)點(diǎn)的硬件結(jié)構(gòu)可能不同，不同傳感器節(jié)點(diǎn)也可能需要負(fù)責(zé)不同的感知或通信任務(wù)，這樣就造成不同傳感器節(jié)點(diǎn)執(zhí)行的代碼鏡像文件的差異，對(duì)不同類型的節(jié)點(diǎn)需要分發(fā)不同的代碼鏡像文件。使用傳染病算法對(duì)特定目標(biāo)節(jié)點(diǎn)進(jìn)行代碼分發(fā)有以下不足：1)冗余代碼鏡像的傳輸浪費(fèi)大量的網(wǎng)絡(luò)資源；2)所有節(jié)點(diǎn)參與代碼分發(fā)，對(duì)網(wǎng)絡(luò)監(jiān)測(cè)應(yīng)用造成影響。

因此，本文提出了一種基于多播分發(fā)樹的代碼分發(fā)(multicast dissemination tree-based code dissemination，MTCD)協(xié)議。MTCD協(xié)議通過建立分發(fā)樹將代碼文件發(fā)送到網(wǎng)絡(luò)中指定的目標(biāo)節(jié)點(diǎn)上，使得在面向特定目標(biāo)節(jié)點(diǎn)進(jìn)行代碼分發(fā)時(shí)，降低參與代碼分發(fā)節(jié)點(diǎn)的數(shù)目，避免冗余代碼數(shù)據(jù)的傳輸。

1 MTCD協(xié)議的模型

1.1 MTCD協(xié)議的原理

MTCD協(xié)議能夠?qū)⒋a鏡像文件分發(fā)到網(wǎng)絡(luò)中指定的目標(biāo)節(jié)點(diǎn)中，其核心在于建立以基站節(jié)點(diǎn)為樹根節(jié)點(diǎn)的多播分發(fā)樹。如圖1所示，MTCD協(xié)議通過廣播發(fā)送代碼版本消息，使網(wǎng)絡(luò)中所有節(jié)點(diǎn)建立到基站節(jié)點(diǎn)的路由路徑，形成以基站節(jié)點(diǎn)為根節(jié)點(diǎn)的多播分發(fā)樹。指定目標(biāo)節(jié)點(diǎn)向其上游節(jié)點(diǎn)發(fā)送代碼請(qǐng)求消息，代碼請(qǐng)求消息通過分發(fā)樹多跳傳輸?shù)交竟?jié)點(diǎn)。基站節(jié)點(diǎn)在接收到目標(biāo)節(jié)點(diǎn)的代碼數(shù)據(jù)請(qǐng)求后，沿著代碼請(qǐng)求的路徑將代碼數(shù)據(jù)發(fā)送到目標(biāo)節(jié)點(diǎn)。

圖1 MTCD協(xié)議的代碼分發(fā)過程

1.2 代碼版本廣播

用戶將編譯好的代碼鏡像文件通過串口發(fā)送到基站節(jié)點(diǎn)，當(dāng)基站節(jié)點(diǎn)接收到完整的代碼鏡像文件后，開始廣播發(fā)送代碼版本消息，代碼版本消息描述了代碼鏡像的摘要信息，其中標(biāo)識(shí)號(hào)(UID)是每個(gè)代碼文件的唯一標(biāo)識(shí)；類型號(hào)(Type)用來區(qū)分傳感器網(wǎng)絡(luò)中不同類型的傳感器節(jié)點(diǎn)；版本號(hào)碼(CodeVersion)代表代碼鏡像文件的版本號(hào)碼；代碼大小(CodeSize)和頁數(shù)(PageNum)用來描述代碼文件的大小和代碼文件包含的頁數(shù)；TTL用來描述代碼版本消息的生存周期；序列號(hào)(SequenceNum)用來區(qū)分不同廣播周期發(fā)送的代碼版本消息。MTCD協(xié)議使用泛洪方式發(fā)送代碼版本消息，在泛洪的過程中，網(wǎng)絡(luò)中的每個(gè)節(jié)點(diǎn)都選擇一個(gè)鄰居節(jié)點(diǎn)作為其父節(jié)點(diǎn)，這樣就建立了以基站節(jié)點(diǎn)為根節(jié)點(diǎn)的分發(fā)樹。

1.3 代碼數(shù)據(jù)請(qǐng)求

由于代碼文件占用存儲(chǔ)空間很大(10～50 kB)，遠(yuǎn)遠(yuǎn)超過節(jié)點(diǎn)的內(nèi)存容量，因此，代碼鏡像文件被劃分為固定大小的頁，頁被劃分為固定大小的數(shù)據(jù)包，如圖2所示。每頁的數(shù)據(jù)量占用內(nèi)存較小，能夠滿足節(jié)點(diǎn)的內(nèi)存容量要求，基站節(jié)點(diǎn)到目標(biāo)節(jié)點(diǎn)的數(shù)據(jù)傳輸以頁為單位進(jìn)行。目標(biāo)節(jié)點(diǎn)通過發(fā)送代碼請(qǐng)求消息來請(qǐng)求頁面數(shù)據(jù)，代碼請(qǐng)求消息沿著分發(fā)樹進(jìn)行頁面數(shù)據(jù)請(qǐng)求，基站節(jié)點(diǎn)作為分發(fā)樹的根節(jié)點(diǎn)逐頁發(fā)送數(shù)據(jù)。代碼請(qǐng)求消息中包含節(jié)點(diǎn)自身ID、目標(biāo)節(jié)點(diǎn)ID、請(qǐng)求頁號(hào)、請(qǐng)求數(shù)據(jù)包號(hào)。目標(biāo)節(jié)點(diǎn)只有在完整接收到一個(gè)頁的數(shù)據(jù)后，才進(jìn)行下一個(gè)頁的請(qǐng)求。

圖2 代碼鏡像文件劃分

1.4 代碼數(shù)據(jù)發(fā)送

節(jié)點(diǎn)接收到下游節(jié)點(diǎn)發(fā)送的代碼請(qǐng)求消息后，向其父節(jié)點(diǎn)進(jìn)行代碼數(shù)據(jù)請(qǐng)求。代碼請(qǐng)求從目標(biāo)節(jié)點(diǎn)經(jīng)過中間節(jié)點(diǎn)轉(zhuǎn)發(fā)到基站節(jié)點(diǎn)，基站節(jié)點(diǎn)接收到代碼請(qǐng)求消息后，將代碼數(shù)據(jù)封裝在代碼數(shù)據(jù)消息中發(fā)送。代碼數(shù)據(jù)消息包括下游請(qǐng)求節(jié)點(diǎn)ID、目標(biāo)節(jié)點(diǎn)ID和代碼數(shù)據(jù)。代碼數(shù)據(jù)沿著分發(fā)樹從基站節(jié)點(diǎn)先發(fā)送到離基站較近的中間節(jié)點(diǎn)，然后通過多跳傳輸?shù)侥繕?biāo)節(jié)點(diǎn)。

2 多播分發(fā)樹的建立與維護(hù)

MTCD協(xié)議的核心在于通過基站節(jié)點(diǎn)到目標(biāo)節(jié)點(diǎn)之間的路由路徑來進(jìn)行代碼數(shù)據(jù)的分發(fā)。路由路徑的建立基于網(wǎng)絡(luò)中節(jié)點(diǎn)的鄰居節(jié)點(diǎn)表和請(qǐng)求節(jié)點(diǎn)表。鄰居節(jié)點(diǎn)表用來記錄鄰居節(jié)點(diǎn)的狀態(tài)信息，每條記錄包含鄰居節(jié)點(diǎn)ID、鄰居節(jié)點(diǎn)到基站的跳數(shù)、鄰居節(jié)點(diǎn)到本節(jié)點(diǎn)的鏈路質(zhì)量、以及鄰居節(jié)點(diǎn)是否為本節(jié)點(diǎn)的父節(jié)點(diǎn)。請(qǐng)求節(jié)點(diǎn)表用來記錄向本節(jié)點(diǎn)請(qǐng)求數(shù)據(jù)的下游節(jié)點(diǎn)的信息，每條記錄包括其請(qǐng)求節(jié)點(diǎn)ID、代碼文件標(biāo)識(shí)號(hào)(UID)、請(qǐng)求頁的號(hào)碼、請(qǐng)求數(shù)據(jù)包的號(hào)碼和目標(biāo)節(jié)點(diǎn)ID。

2.1 普通節(jié)點(diǎn)的算法流程

MTCD協(xié)議通過代碼版本消息建立和維護(hù)分發(fā)樹。基站節(jié)點(diǎn)周期性地廣播發(fā)送代碼版本消息，節(jié)點(diǎn)通過代碼版本消息對(duì)其鄰居節(jié)點(diǎn)表進(jìn)行更新，這樣,如果新的節(jié)點(diǎn)加入到網(wǎng)絡(luò)或者節(jié)點(diǎn)失效，依然能夠建立新的分發(fā)樹進(jìn)行數(shù)據(jù)分發(fā)。當(dāng)網(wǎng)絡(luò)中的節(jié)點(diǎn)接收到代碼版本消息時(shí)，可以通過代碼版本消息中的TTL來計(jì)算鄰居節(jié)點(diǎn)到基站節(jié)點(diǎn)的跳數(shù)；鏈路質(zhì)量可以使用無線信號(hào)的接收信號(hào)強(qiáng)度指示(RSSI)或者鏈路質(zhì)量指示(LQI)來表示。節(jié)點(diǎn)選擇鄰居節(jié)點(diǎn)中到基站距離(跳數(shù))最小并且鏈路質(zhì)量最優(yōu)的節(jié)點(diǎn)為父節(jié)點(diǎn)。

如圖3所示，節(jié)點(diǎn)在接收到代碼版本消息后，對(duì)節(jié)點(diǎn)的鄰居節(jié)點(diǎn)表進(jìn)行更新，同時(shí)更新其父節(jié)點(diǎn)。網(wǎng)絡(luò)中的所有節(jié)點(diǎn)在起初都是普通節(jié)點(diǎn)，普通節(jié)點(diǎn)在接收到代碼版本消息后，如果代碼版本消息中的Type號(hào)與自身的相同，并且代碼版本消息中的代碼版本號(hào)也要比自身的新，那么,此節(jié)點(diǎn)成為目標(biāo)節(jié)點(diǎn)。代碼版本消息中的序列號(hào)(SequenceNum)越大，說明是越新的代碼版本消息。如果接收到的是新的代碼版本消息,則節(jié)點(diǎn)重新將此代碼版本消息廣播發(fā)送。當(dāng)節(jié)點(diǎn)接收到代碼請(qǐng)求消息后，對(duì)其自身的請(qǐng)求節(jié)點(diǎn)表進(jìn)行更新。如果節(jié)點(diǎn)已經(jīng)有請(qǐng)求頁的數(shù)據(jù)，那么,節(jié)點(diǎn)直接將請(qǐng)求頁的數(shù)據(jù)發(fā)送給下游的請(qǐng)求節(jié)點(diǎn)；如果節(jié)點(diǎn)正在向父節(jié)點(diǎn)請(qǐng)求這個(gè)頁的數(shù)據(jù)，那么,等接收完請(qǐng)求頁的數(shù)據(jù)后進(jìn)行轉(zhuǎn)發(fā)；否則，節(jié)點(diǎn)將代碼請(qǐng)求消息轉(zhuǎn)發(fā)給其父節(jié)點(diǎn)。當(dāng)普通節(jié)點(diǎn)接收到代碼數(shù)據(jù)消息時(shí)，通過查詢自身的請(qǐng)求節(jié)點(diǎn)表，將代碼數(shù)據(jù)轉(zhuǎn)發(fā)給下游的請(qǐng)求節(jié)點(diǎn)。

圖3 普通節(jié)點(diǎn)流程圖

2.2 目標(biāo)節(jié)點(diǎn)的算法流程

如圖4所示，當(dāng)目標(biāo)節(jié)點(diǎn)接收到代碼數(shù)據(jù)消息時(shí)，如果代碼數(shù)據(jù)消息的目標(biāo)節(jié)點(diǎn)不是本節(jié)點(diǎn)，那么節(jié)點(diǎn)根據(jù)其請(qǐng)求節(jié)點(diǎn)表將收到的代碼數(shù)據(jù)消息轉(zhuǎn)發(fā)給請(qǐng)求節(jié)點(diǎn)。如果代碼數(shù)據(jù)消息的目標(biāo)節(jié)點(diǎn)是本節(jié)點(diǎn)，則將代碼數(shù)據(jù)存儲(chǔ)入外存中；如果已接收到完整的代碼頁數(shù)據(jù)，則發(fā)送代碼請(qǐng)求消息進(jìn)行下一個(gè)頁的傳輸。當(dāng)目標(biāo)節(jié)點(diǎn)接收到完整的代碼鏡像后，目標(biāo)節(jié)點(diǎn)停止周期性發(fā)送代碼請(qǐng)求消息，節(jié)點(diǎn)從目標(biāo)節(jié)點(diǎn)變化為普通節(jié)點(diǎn)。

圖4 目標(biāo)節(jié)點(diǎn)流程圖

請(qǐng)求節(jié)點(diǎn)表的每條記錄都有一個(gè)有效時(shí)間，如果記錄在有效時(shí)間內(nèi)未進(jìn)行更新，那么就將此條記錄從請(qǐng)求節(jié)點(diǎn)表刪除。每個(gè)目標(biāo)節(jié)點(diǎn)都會(huì)周期性地發(fā)送代碼請(qǐng)求消息對(duì)路徑上節(jié)點(diǎn)的請(qǐng)求節(jié)點(diǎn)表進(jìn)行更新。當(dāng)目標(biāo)節(jié)點(diǎn)接收到完整鏡像時(shí)，停止發(fā)送代碼請(qǐng)求消息。其上游節(jié)點(diǎn)的請(qǐng)求節(jié)點(diǎn)表中的記錄在超過有效時(shí)間后被刪除。

3 MTCD協(xié)議的可靠性機(jī)制

由于代碼鏡像文件的特殊性，代碼分發(fā)協(xié)議必須保證目標(biāo)節(jié)點(diǎn)接收到100%可靠地代碼鏡像文件。保證傳輸可靠性的機(jī)制主要有兩種，糾錯(cuò)編碼機(jī)制和重傳機(jī)制。糾錯(cuò)編碼機(jī)制在每個(gè)數(shù)據(jù)包附加大量的冗余數(shù)據(jù)來進(jìn)行數(shù)據(jù)恢復(fù)，額外消耗能量較多。傳感器網(wǎng)絡(luò)多采用重傳機(jī)制，即使用數(shù)據(jù)包重傳來保證可靠性，分為NACK(negative acknow-ledge)機(jī)制與ACK(acknowledge)機(jī)制。

ACK機(jī)制由發(fā)送節(jié)點(diǎn)負(fù)責(zé)丟包監(jiān)測(cè)，即接收節(jié)點(diǎn)每接收到數(shù)據(jù)包，就發(fā)送ACK包給發(fā)送節(jié)點(diǎn)進(jìn)行確認(rèn)，發(fā)送節(jié)點(diǎn)在接收到ACK包后確認(rèn)數(shù)據(jù)包成功發(fā)送，否則，需要重傳此數(shù)據(jù)包。傳統(tǒng)的分發(fā)協(xié)議多采用NACK機(jī)制，即接收節(jié)點(diǎn)進(jìn)行丟包監(jiān)測(cè)，接收節(jié)點(diǎn)周期性地根據(jù)數(shù)據(jù)接收狀態(tài)來發(fā)送重傳請(qǐng)求消息進(jìn)行數(shù)據(jù)請(qǐng)求。傳統(tǒng)的分發(fā)協(xié)議由于使用傳染病算法，數(shù)據(jù)發(fā)送采用的是廣播方式。如果使用ACK機(jī)制，由于廣播域內(nèi)的節(jié)點(diǎn)都會(huì)發(fā)送ACK包進(jìn)行數(shù)據(jù)確認(rèn)，會(huì)造成網(wǎng)絡(luò)擁塞。

MTCD協(xié)議代碼數(shù)據(jù)的發(fā)送是基于單播，避免了ACK機(jī)制可能引起的網(wǎng)絡(luò)擁塞問題。如果使用NACK機(jī)制，由于NACK機(jī)制必須由接收節(jié)點(diǎn)周期性地發(fā)送重傳請(qǐng)求消息進(jìn)行數(shù)據(jù)發(fā)送，相比ACK機(jī)制，其數(shù)據(jù)重傳速度較慢，在重傳請(qǐng)求消息的發(fā)送周期上浪費(fèi)大量時(shí)間。因此，MTCD協(xié)議使用ACK機(jī)制進(jìn)行數(shù)據(jù)重傳來保證協(xié)議的可靠性。

4 實(shí)驗(yàn)結(jié)果與分析

本文使用TinyOS系統(tǒng)的專用仿真平臺(tái)TOSSIM[7]進(jìn)行仿真實(shí)驗(yàn)，并與Deluge協(xié)議進(jìn)行對(duì)比。實(shí)驗(yàn)的網(wǎng)絡(luò)拓?fù)涫褂脰鸥?grid)結(jié)構(gòu)，節(jié)點(diǎn)傳輸半徑為5 m，節(jié)點(diǎn)間的間距為3 m，實(shí)驗(yàn)用代碼文件大小為33 kB。如圖5所示為一個(gè)5 grid×5 grid網(wǎng)絡(luò)拓?fù)洌竟?jié)點(diǎn)位于網(wǎng)絡(luò)左上角,為測(cè)試目標(biāo)節(jié)點(diǎn)位置對(duì)MTCD協(xié)議的影響，使用MTCD-T代表目標(biāo)節(jié)點(diǎn)為離基站距離固定為2跳的黑色節(jié)點(diǎn)；MTCD-R代表目標(biāo)節(jié)點(diǎn)為網(wǎng)絡(luò)右下角的2個(gè)灰色節(jié)點(diǎn)。通過改變每條邊上節(jié)點(diǎn)的個(gè)數(shù)，來測(cè)試網(wǎng)絡(luò)3×3～10×10不同節(jié)點(diǎn)規(guī)模下的性能。文獻(xiàn)[8]給出了傳感器每項(xiàng)操作耗費(fèi)能量的經(jīng)驗(yàn)?zāi)Ｐ?，通過統(tǒng)計(jì)各項(xiàng)操作次數(shù)結(jié)合經(jīng)驗(yàn)?zāi)Ｐ陀?jì)算其各項(xiàng)操作的耗費(fèi)能量。

圖5 5 grid×5grid網(wǎng)絡(luò)拓?fù)?/p>

圖6是協(xié)議在不同節(jié)點(diǎn)規(guī)模下的分發(fā)時(shí)間對(duì)比。分發(fā)時(shí)間是與目標(biāo)節(jié)點(diǎn)到基站節(jié)點(diǎn)的距離相關(guān)的，距離越大，需要耗費(fèi)在路由轉(zhuǎn)發(fā)上的時(shí)間就越多。MTCD-R隨著節(jié)點(diǎn)規(guī)模變大，分發(fā)時(shí)間漸漸超過Deluge協(xié)議，這是由于隨著路由路徑變長，路由路徑失效的概率增大，每次路由路徑失效，都需花費(fèi)大量時(shí)間進(jìn)行路由重建。

圖6 分發(fā)時(shí)間對(duì)比

圖7是協(xié)議在不同節(jié)點(diǎn)規(guī)模下的空閑偵聽耗費(fèi)能量對(duì)比?？臻e偵聽耗費(fèi)能量與網(wǎng)絡(luò)中參與分發(fā)的節(jié)點(diǎn)數(shù)目以及分發(fā)耗費(fèi)時(shí)間相關(guān)。Deluge協(xié)議是面向全網(wǎng)節(jié)點(diǎn)分發(fā)的，因此,網(wǎng)絡(luò)中所有節(jié)點(diǎn)總空閑偵聽時(shí)間很大。隨著節(jié)點(diǎn)規(guī)模的擴(kuò)大，MTCD-R路由路徑上節(jié)點(diǎn)數(shù)目變多，分發(fā)時(shí)間耗費(fèi)能量逐漸增多；MTCD-T由于參與分發(fā)節(jié)點(diǎn)數(shù)目很少，分發(fā)耗費(fèi)時(shí)間最低，因此,空閑偵聽能耗是最小的。

圖7 空閑偵聽耗費(fèi)能量

圖8是協(xié)議在不同節(jié)點(diǎn)規(guī)模下的數(shù)據(jù)消息耗費(fèi)能量對(duì)比，數(shù)據(jù)消息指用來發(fā)送代碼數(shù)據(jù)的消息。數(shù)據(jù)消息耗費(fèi)能量與數(shù)據(jù)消息的傳輸次數(shù)相關(guān)。Deluge協(xié)議將代碼數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中所有節(jié)點(diǎn)，MTCD協(xié)議只需要將代碼數(shù)據(jù)沿分發(fā)樹的路徑進(jìn)行轉(zhuǎn)發(fā)。因此,MTCD協(xié)議的數(shù)據(jù)消息能耗隨分發(fā)樹的路徑長度增大而增大，數(shù)據(jù)消息傳輸?shù)陀贒eluge。

圖8 數(shù)據(jù)消息耗費(fèi)能量

圖9是協(xié)議在不同節(jié)點(diǎn)規(guī)模下的控制消息耗費(fèi)能量對(duì)比，控制消息不進(jìn)行代碼數(shù)據(jù)的傳輸，而是協(xié)議用來進(jìn)行網(wǎng)絡(luò)信息交換，包括代碼版本消息、代碼請(qǐng)求消息以及ACK消息。MTCD協(xié)議的性能稍優(yōu)于Deluge協(xié)議，MTCD-R的控制消息開銷與MTCD-T相差不大。這是由于MTCD協(xié)議的代碼版本消息周期性使用泛洪方式進(jìn)行廣播發(fā)送，造成了大量的控制消息傳輸開銷。

圖9 控制消息耗費(fèi)能量

5 結(jié) 論

本文提出了一種MTCD協(xié)議,與傳統(tǒng)的基于傳染病算法的代碼分發(fā)協(xié)議Deluge相比，MTCD協(xié)議通過建立代碼分發(fā)目標(biāo)節(jié)點(diǎn)與基站節(jié)點(diǎn)之間的路由路徑，減少了網(wǎng)絡(luò)中參與代碼分發(fā)節(jié)點(diǎn)的個(gè)數(shù)，并保證了協(xié)議的可靠性。TOSSIM仿真實(shí)驗(yàn)結(jié)果表明：在對(duì)指定目標(biāo)節(jié)點(diǎn)進(jìn)行分發(fā)時(shí)，MTCD協(xié)議的能量消耗遠(yuǎn)遠(yuǎn)低于Deluge協(xié)議。

參考文獻(xiàn):

[1] 況曉輝,許 飛,劉 麗.無線傳感器網(wǎng)絡(luò)遠(yuǎn)程代碼更新技術(shù)研究進(jìn)展[J].計(jì)算機(jī)科學(xué),2013,40(6):255-261.

[2] Hui J,Culler D.The dynamic behavior of a data dissemination protocol for network programming at scale[C]∥Proc ACM SenSys'04.Baltimore,MD,USA:ACM,2004:81-94.

[3] Liang M,Musaloiu-E M,Terzis A.Typhoon:A reliable data dissemination protocol for wireless Sensor Networks [C] ∥EWSN 2008,Bologna,Italy:Springer,2008:268-285.

[4] Dong Wei,Liu Yunhao,Wang Chao,et al.Link quality aware code dissemination in wireless sensor networks[C]∥The 19th IEEE International Conference on Network Protocols,Vancouver,BC:IEEE,2011:89-98.

[5] Rossi M,Bui N,Zanca G,et al.SYNAPSE++:Code dissemination in wireless sensor networks using fountain codes [J].IEEE Transactions on Mobile Computing,2010,9(12):1749-1765.

[6] Akdere M,Bilgin C,Gerdaneri O,et al.A comparison of epidemic algorithms in wireless sensor networks [J].Computer Communications.2006,29:2450-2457.

[7] Levis P,Lee N,Welsh M,et al.TOSSIM:Accurate and scalable simulation of entire TinyOS Applications[C]∥Proc ACM SenSys’03,Los Angeles,CA,USA:ACM 2003:126-137.

[8] Mainwaring A,Culler D,Polastre J,et al.Wireless sensor networks for habitat monitoring∥Proc the 1st ACM International Workshop on Wireless Sensor Networks and Applications,Atlanta,GA,USA:ACM,2002:88-97.