基于6LOWPAN的IPv6傳感器網(wǎng)絡(luò)報(bào)頭壓縮方案的設(shè)計(jì)與實(shí)現(xiàn)

由表1可知報(bào)頭壓縮使程序的代碼空間增加了1 742 B，只占節(jié)點(diǎn)ROM的1．32％，但是卻沒有增加額外的數(shù)據(jù)空間。AVR Studio 4工具給出的程序所使用的RAM大小只是程序中所使用的全局變量的大小，結(jié)果說明打開報(bào)頭壓縮選項(xiàng)并未增加全局變量的使用，經(jīng)計(jì)算報(bào)頭壓縮所需的局部變量不會(huì)超過20B。
3．3 網(wǎng)絡(luò)生存時(shí)間
網(wǎng)絡(luò)生存時(shí)間對(duì)于傳感器網(wǎng)絡(luò)是一個(gè)非常重要的性能參數(shù)。然而傳感器網(wǎng)絡(luò)大部分的能量均消耗在數(shù)據(jù)包的發(fā)送和處理器的指令處理上。一方面，報(bào)頭壓縮可以減少數(shù)據(jù)包的長(zhǎng)度，節(jié)省單位數(shù)據(jù)包的發(fā)送能耗。另一方面，報(bào)頭壓縮會(huì)增加處理器額外的指令處理，增加單位數(shù)據(jù)包的發(fā)送能耗。為了驗(yàn)證報(bào)頭壓縮是否能夠增加網(wǎng)絡(luò)的生存時(shí)間，做如下實(shí)驗(yàn)：采用同一節(jié)點(diǎn)，使用9 V干點(diǎn)池供電，分別在報(bào)頭壓縮和不壓縮的情況下單跳與網(wǎng)關(guān)通信(鏈路質(zhì)量很好，無其他無線設(shè)備干擾，發(fā)送功率均為1 mW)，在服務(wù)器端記錄當(dāng)電池能量耗盡時(shí)壓縮和不壓縮兩種情況下節(jié)點(diǎn)發(fā)送數(shù)據(jù)包的總個(gè)數(shù)，實(shí)驗(yàn)結(jié)果如表2所示。

由表2可見節(jié)點(diǎn)啟用報(bào)頭壓縮發(fā)送的數(shù)據(jù)包總數(shù)要大于關(guān)閉報(bào)頭壓縮的情況，顯然報(bào)頭壓縮可以有效的提高網(wǎng)絡(luò)生存時(shí)間。
3．4 丟包率
由于使用報(bào)頭壓縮會(huì)使節(jié)點(diǎn)發(fā)送的數(shù)據(jù)包長(zhǎng)度變短，因此在相同的節(jié)點(diǎn)發(fā)包速率下會(huì)減小MAC層的碰撞概率，理論上會(huì)減少丟包的發(fā)生。為了驗(yàn)證上述結(jié)論，就要盡可能地減少無線信道對(duì)丟包率的影響，實(shí)驗(yàn)方案如下：選取10個(gè)傳感器節(jié)點(diǎn)與網(wǎng)關(guān)組成星型網(wǎng)路，通信距離均在1 m以內(nèi)，發(fā)送功率均為1 mW。在不同的發(fā)包頻率下使節(jié)點(diǎn)發(fā)送100個(gè)數(shù)據(jù)包，在服務(wù)器統(tǒng)計(jì)總共收到的數(shù)據(jù)包個(gè)數(shù)，計(jì)算網(wǎng)絡(luò)的整體丟包率。實(shí)驗(yàn)分為2組，分別采用壓縮和不壓縮的方式進(jìn)行數(shù)據(jù)包發(fā)送，結(jié)果如圖7所示。

由圖可見網(wǎng)絡(luò)的丟包率與節(jié)點(diǎn)發(fā)送數(shù)據(jù)包的頻率和長(zhǎng)度有關(guān)，發(fā)送頻率越高、數(shù)據(jù)包越長(zhǎng)，則網(wǎng)絡(luò)產(chǎn)生的信道沖突的可能性越大，丟包率也就越高。
3．5 平均時(shí)延
節(jié)點(diǎn)發(fā)送數(shù)據(jù)包的速率為250 Kb／s，采用壓縮方案單個(gè)數(shù)據(jù)包可以節(jié)省39 B，因此單個(gè)數(shù)據(jù)包的發(fā)送時(shí)間可以減少39×8／250=1．24 ms。當(dāng)然報(bào)頭壓縮和解壓縮需要額外的處理時(shí)間，本節(jié)點(diǎn)ATmega128工作頻率為8 MHz，處理性能為8 MIPS，處理1 000條指令的時(shí)間也僅需125μs，因此綜合來講報(bào)頭壓縮可以有效的減少網(wǎng)絡(luò)時(shí)延，尤其是在大規(guī)模網(wǎng)絡(luò)部署的情況下。本文中采用Ping6命令對(duì)網(wǎng)絡(luò)時(shí)延進(jìn)行測(cè)試，實(shí)驗(yàn)分為2組分別對(duì)應(yīng)壓縮和不壓縮的情況，每組實(shí)驗(yàn)使用5個(gè)節(jié)點(diǎn)組成5跳網(wǎng)絡(luò)，在服務(wù)器端對(duì)每跳節(jié)點(diǎn)進(jìn)行100次ICMP響應(yīng)請(qǐng)求，記錄平均返回時(shí)間，實(shí)驗(yàn)結(jié)果如圖8所示。

由圖可見網(wǎng)絡(luò)的平均延時(shí)基本與跳數(shù)為線性增加的關(guān)系，單跳情況下壓縮與不壓縮的網(wǎng)絡(luò)時(shí)延之差大概在2．5 ms左右。因?yàn)镻ing命令測(cè)試的是往返時(shí)間，所以這與理論分析相吻合，隨著跳數(shù)的增加時(shí)延之差基本線性增長(zhǎng)。

4 結(jié)語
本文設(shè)計(jì)并實(shí)現(xiàn)了一種IPv6報(bào)頭壓縮機(jī)制，理想情況下可以將IPv6報(bào)頭壓縮到1 B，在節(jié)點(diǎn)單跳和多跳通信的情況下壓縮效率分別為45．9％和38．2％。實(shí)驗(yàn)結(jié)果表明，本文所設(shè)計(jì)的報(bào)頭壓縮方案可以在占用較小額外存儲(chǔ)空間的情況下，減小丟包率、延長(zhǎng)網(wǎng)絡(luò)生存時(shí)間、降低網(wǎng)絡(luò)時(shí)延。由于對(duì)下一個(gè)報(bào)頭(UDP，TCP，ICMP)的壓縮并不會(huì)給壓縮效率帶來很高的收益，因此本文中并未討論下一個(gè)報(bào)頭的壓縮方案，后續(xù)工作中可以考慮增加對(duì)下一個(gè)報(bào)頭的壓縮支持。