基于6LOWPAN的IPv6傳感器網(wǎng)絡(luò )報頭壓縮方案的設計與實(shí)現
加入技術(shù)交流群
3 功能測試及性能分析
3．1 功能測試
該系統中節點(diǎn)使用64位擴展地址作為底層的尋址模式，6LoWPAN網(wǎng)絡(luò )的內部使用IPv6本地鏈路地址進(jìn)行通信，在單跳情況下使用Sniffer無(wú)線(xiàn)嗅探儀捕捉到的壓縮前后數據包內容如圖6所示。根據具體的IPv6報頭格式并按照上文提到的IPv6報頭壓縮方案將原40 B的IPv6報頭壓縮到1 B，壓縮前總數據包長(cháng)度為85 B，壓縮后總數據包長(cháng)度為46 B，壓縮效率為(85-46)／85=45．9％，對于多跳情況下，適配層會(huì )增加一個(gè)Mesh頭部，該頭部長(cháng)度為17 B，因此對應于多跳情況下壓縮效率為[(85+17)-(46+17)]／(85+17)=38．2％?；谝陨鲜聦?shí)，下文通過(guò)存儲開(kāi)銷(xiāo)、網(wǎng)絡(luò )生存時(shí)間、丟包率、平均時(shí)延4個(gè)方面對報頭壓縮進(jìn)行性能分析。
3．2 存儲開(kāi)銷(xiāo)
節點(diǎn)的程序代碼存放在A(yíng)Tmega128的ROM中，大小為128 KB，數據空間為ATmega128的RAM，大小為4 KB。在把報頭壓縮開(kāi)關(guān)打開(kāi)和關(guān)閉的情況下，使用AVR Studio4工具分別對同一序進(jìn)行編譯，軟件輸出結果如表1所示。本文引用地址：http://dyxdggzs.com/article/161471.htm
由表1可知報頭壓縮使程序的代碼空間增加了1 742 B，只占節點(diǎn)ROM的1．32％，但是卻沒(méi)有增加額外的數據空間。AVR Studio 4工具給出的程序所使用的RAM大小只是程序中所使用的全局變量的大小，結果說(shuō)明打開(kāi)報頭壓縮選項并未增加全局變量的使用，經(jīng)計算報頭壓縮所需的局部變量不會(huì )超過(guò)20B。
3．3 網(wǎng)絡(luò )生存時(shí)間
網(wǎng)絡(luò )生存時(shí)間對于傳感器網(wǎng)絡(luò )是一個(gè)非常重要的性能參數。然而傳感器網(wǎng)絡(luò )大部分的能量均消耗在數據包的發(fā)送和處理器的指令處理上。一方面，報頭壓縮可以減少數據包的長(cháng)度，節省單位數據包的發(fā)送能耗。另一方面，報頭壓縮會(huì )增加處理器額外的指令處理，增加單位數據包的發(fā)送能耗。為了驗證報頭壓縮是否能夠增加網(wǎng)絡(luò )的生存時(shí)間，做如下實(shí)驗：采用同一節點(diǎn)，使用9 V干點(diǎn)池供電，分別在報頭壓縮和不壓縮的情況下單跳與網(wǎng)關(guān)通信(鏈路質(zhì)量很好，無(wú)其他無(wú)線(xiàn)設備干擾，發(fā)送功率均為1 mW)，在服務(wù)器端記錄當電池能量耗盡時(shí)壓縮和不壓縮兩種情況下節點(diǎn)發(fā)送數據包的總個(gè)數，實(shí)驗結果如表2所示。
由表2可見(jiàn)節點(diǎn)啟用報頭壓縮發(fā)送的數據包總數要大于關(guān)閉報頭壓縮的情況，顯然報頭壓縮可以有效的提高網(wǎng)絡(luò )生存時(shí)間。
3．4 丟包率
由于使用報頭壓縮會(huì )使節點(diǎn)發(fā)送的數據包長(cháng)度變短，因此在相同的節點(diǎn)發(fā)包速率下會(huì )減小MAC層的碰撞概率，理論上會(huì )減少丟包的發(fā)生。為了驗證上述結論，就要盡可能地減少無(wú)線(xiàn)信道對丟包率的影響，實(shí)驗方案如下：選取10個(gè)傳感器節點(diǎn)與網(wǎng)關(guān)組成星型網(wǎng)路，通信距離均在1 m以?xún)?，發(fā)送功率均為1 mW。在不同的發(fā)包頻率下使節點(diǎn)發(fā)送100個(gè)數據包，在服務(wù)器統計總共收到的數據包個(gè)數，計算網(wǎng)絡(luò )的整體丟包率。實(shí)驗分為2組，分別采用壓縮和不壓縮的方式進(jìn)行數據包發(fā)送，結果如圖7所示。
由圖可見(jiàn)網(wǎng)絡(luò )的丟包率與節點(diǎn)發(fā)送數據包的頻率和長(cháng)度有關(guān)，發(fā)送頻率越高、數據包越長(cháng)，則網(wǎng)絡(luò )產(chǎn)生的信道沖突的可能性越大，丟包率也就越高。
3．5 平均時(shí)延
節點(diǎn)發(fā)送數據包的速率為250 Kb／s，采用壓縮方案單個(gè)數據包可以節省39 B，因此單個(gè)數據包的發(fā)送時(shí)間可以減少39×8／250=1．24 ms。當然報頭壓縮和解壓縮需要額外的處理時(shí)間，本節點(diǎn)ATmega128工作頻率為8 MHz，處理性能為8 MIPS，處理1 000條指令的時(shí)間也僅需125μs，因此綜合來(lái)講報頭壓縮可以有效的減少網(wǎng)絡(luò )時(shí)延，尤其是在大規模網(wǎng)絡(luò )部署的情況下。本文中采用Ping6命令對網(wǎng)絡(luò )時(shí)延進(jìn)行測試，實(shí)驗分為2組分別對應壓縮和不壓縮的情況，每組實(shí)驗使用5個(gè)節點(diǎn)組成5跳網(wǎng)絡(luò )，在服務(wù)器端對每跳節點(diǎn)進(jìn)行100次ICMP響應請求，記錄平均返回時(shí)間，實(shí)驗結果如圖8所示。
由圖可見(jiàn)網(wǎng)絡(luò )的平均延時(shí)基本與跳數為線(xiàn)性增加的關(guān)系，單跳情況下壓縮與不壓縮的網(wǎng)絡(luò )時(shí)延之差大概在2．5 ms左右。因為Ping命令測試的是往返時(shí)間，所以這與理論分析相吻合，隨著(zhù)跳數的增加時(shí)延之差基本線(xiàn)性增長(cháng)。
4 結語(yǔ)
本文設計并實(shí)現了一種IPv6報頭壓縮機制，理想情況下可以將IPv6報頭壓縮到1 B，在節點(diǎn)單跳和多跳通信的情況下壓縮效率分別為45．9％和38．2％。實(shí)驗結果表明，本文所設計的報頭壓縮方案可以在占用較小額外存儲空間的情況下，減小丟包率、延長(cháng)網(wǎng)絡(luò )生存時(shí)間、降低網(wǎng)絡(luò )時(shí)延。由于對下一個(gè)報頭(UDP，TCP，ICMP)的壓縮并不會(huì )給壓縮效率帶來(lái)很高的收益，因此本文中并未討論下一個(gè)報頭的壓縮方案，后續工作中可以考慮增加對下一個(gè)報頭的壓縮支持。
評論