基于6LOWPAN的IPv6傳感器網(wǎng)絡(luò)報(bào)頭壓縮方案

　　無線傳感器網(wǎng)絡(luò)是由大量按需隨機(jī)分布的集成有傳感器、數(shù)據(jù)處理單元和通信模塊的微型節(jié)點(diǎn)以自組織方式構(gòu)成的無線網(wǎng)絡(luò)。傳感器網(wǎng)絡(luò)具有成本低、能耗代、靈活性高等優(yōu)點(diǎn)，可以應(yīng)用于國防軍事、環(huán)境監(jiān)測(cè)、交通管理、醫(yī)療衛(wèi)生、反恐抗災(zāi)等領(lǐng)域，具有重要的研究?jī)r(jià)值和應(yīng)用前景。無線傳感器網(wǎng)絡(luò)節(jié)點(diǎn)的資源非常有限，因此需要一個(gè)輕量級(jí)的無線通信規(guī)范。IEEE 802.15.4標(biāo)準(zhǔn)定義了一個(gè)短距離、低復(fù)雜度、低功耗、低數(shù)據(jù)速率的介質(zhì)訪問控制層(MAC)和物理層(PHY)規(guī)范，該標(biāo)準(zhǔn)的技術(shù)特點(diǎn)決定了它特別適合傳感器網(wǎng)絡(luò)、智能家庭網(wǎng)絡(luò)、工業(yè)控制網(wǎng)絡(luò)等節(jié)點(diǎn)眾多、數(shù)據(jù)率較低的應(yīng)用環(huán)境。IPv6作為下一代網(wǎng)絡(luò)協(xié)議，具有地址資源豐富、地址自動(dòng)配置、安全性高、移動(dòng)性好等優(yōu)點(diǎn)，可以滿足無線傳感器網(wǎng)絡(luò)在地址、安全、移動(dòng)及與現(xiàn)有網(wǎng)絡(luò)融合等方面的需求。因此，IPv6與IEEE 802.15.4在傳感器網(wǎng)絡(luò)上的結(jié)合有著無可比擬的應(yīng)用前景。

　　本文以北京交通大學(xué)下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國家工程實(shí)驗(yàn)室自主開發(fā)和研制的微型傳感路由器所構(gòu)建的IPv6無線傳感器網(wǎng)絡(luò)為基礎(chǔ)，設(shè)計(jì)并實(shí)現(xiàn)了一種更為高效的IPv6報(bào)頭壓縮方法，并對(duì)壓縮性能進(jìn)行了分析。

　　1 平臺(tái)簡(jiǎn)介

　　本文基于IPv6無線傳感器網(wǎng)絡(luò)平臺(tái)的拓?fù)浣Y(jié)構(gòu)及協(xié)議層次如圖1所示。IPv6無線傳感器網(wǎng)絡(luò)節(jié)點(diǎn)設(shè)備可以自組織形成多跳Mesh網(wǎng)絡(luò)，將采集到的溫度、濕度、光強(qiáng)等環(huán)境信息發(fā)送給網(wǎng)關(guān)設(shè)備。網(wǎng)關(guān)設(shè)備通過以太網(wǎng)直連的方式與服務(wù)器進(jìn)行通信，并把收到的來自傳感器節(jié)點(diǎn)的數(shù)據(jù)提交給服務(wù)器，服務(wù)器端完成對(duì)整個(gè)IPv6傳感器網(wǎng)絡(luò)的控制和環(huán)境信息的人性化顯示。

　　傳感器節(jié)點(diǎn)采用ATmega128作為處理器、使用CC2420作為射頻芯片，能量供應(yīng)模塊可以使用9 V直流穩(wěn)壓電源或使用9 V干電池直接供電，同時(shí)配備溫濕度傳感器和光強(qiáng)傳感器對(duì)環(huán)境信息進(jìn)行采集。節(jié)點(diǎn)通信協(xié)議分為5層，物理層采用IEEE 802.15.4通信規(guī)范，使用OQPSK方式進(jìn)行調(diào)制，發(fā)送頻段使用2.4 GHz，傳輸速率可達(dá)250 Kb/s。適配層實(shí)現(xiàn)數(shù)據(jù)包的分片和重組、報(bào)頭壓縮以及Mesh路由等功能。網(wǎng)絡(luò)層運(yùn)行精簡(jiǎn)的微型IPv6協(xié)議棧，該協(xié)議棧代碼量小、簡(jiǎn)易輕型并且可以與使用完整的IPv6協(xié)議棧的對(duì)等節(jié)點(diǎn)進(jìn)行通信。應(yīng)用層主要運(yùn)行傳感器網(wǎng)絡(luò)應(yīng)用級(jí)程序，比如數(shù)據(jù)采集、環(huán)境監(jiān)控等。節(jié)點(diǎn)的層次協(xié)議設(shè)計(jì)完全遵守RFC4919和RFC4944中定義的規(guī)范。

　　2 IPv6報(bào)頭壓縮

　　2.1 現(xiàn)有方案分析

　　到目前為止，6LoWPAN報(bào)頭壓縮方案主要有兩種。其中一種是RFC4944中定義的方案。該方案在最理想的情況下可以將IPv6完整的40 B壓縮到2 B(HC1字節(jié)和跳數(shù)限制字節(jié))，同時(shí)支持UDP，TCP，ICMP下一個(gè)報(bào)頭的壓縮，HC1字節(jié)編碼IPv6報(bào)頭中各字段的壓縮方式，IPv6報(bào)頭中未經(jīng)壓縮的內(nèi)容按順序存放在未壓縮字段中。

　　如圖2所示，版本、傳輸類型和流標(biāo)簽(全部為零)、凈荷長(zhǎng)度(可以從IEEE 802.15.4 MAC頭中凈荷長(zhǎng)度字段推斷出來)均可以壓縮掉，下一個(gè)報(bào)頭字段攜帶在HC1字節(jié)中，跳數(shù)限制字段不壓縮，存放在未壓縮字段中。標(biāo)準(zhǔn)中規(guī)定IPv6地址采用無狀態(tài)的配置式，地址由64位前綴和64位接口標(biāo)識(shí)符(Interface ID，IID)生成。IEEE 802.15.4定義了兩種尋址模式：IEEE 64位擴(kuò)展地址和16位短地址。每一個(gè)IEEE802. 15.4設(shè)備都有一個(gè)分配的EUI-64標(biāo)識(shí)符，該標(biāo)識(shí)符用作64位擴(kuò)展地址進(jìn)行尋址，具有全球惟一性，并且通過該EUI-64標(biāo)識(shí)符可以生成一個(gè)IPv6接口標(biāo)識(shí)符，實(shí)現(xiàn)IPv6地址的自動(dòng)配置。16位短地址是在節(jié)點(diǎn)成功加入網(wǎng)絡(luò)后，由節(jié)點(diǎn)所在PAN內(nèi)的協(xié)調(diào)者動(dòng)態(tài)分配，只能保證在該P(yáng)AN內(nèi)的惟一性，不能用作實(shí)現(xiàn)IPv6地址的自動(dòng)配置。因此如果IPv6地址為本地鏈路地址(前綴為fe80：：/64)，并且IEEE 802.15.4尋址模式為64位擴(kuò)展地址，就可以將IPv6地址壓縮掉，否則就要將其在未壓縮字段中攜帶。

　　圖3為HC1字節(jié)具體編碼格式。

　　另一種是現(xiàn)有報(bào)頭壓縮草案中定義的方案。該方案提出了對(duì)本地鏈路地址、全球單播地址、多播地址等IPv6地址的壓縮方法，同時(shí)解決了源壓縮方案不具有協(xié)議層次性的弊端。而且該壓縮方案支持IPv6擴(kuò)展報(bào)頭的壓縮和流標(biāo)簽、服務(wù)類型的區(qū)分。但是這種壓縮方案過于復(fù)雜，對(duì)于處理能力有限、能量受限、硬件資源匱乏并且以環(huán)境監(jiān)測(cè)為主要應(yīng)用的傳感器節(jié)點(diǎn)來說并不實(shí)用。因此本文提出一種基于RFC4944的IPv6報(bào)頭壓縮改進(jìn)方案。

　　2.2 改進(jìn)方案

　　雖然RFC4944中提到的壓縮方案已經(jīng)很精簡(jiǎn)，但是這種方法仍然存有冗余。方案中對(duì)于IPv6報(bào)頭的跳數(shù)限制字段并沒有壓縮，而是始終占用1 B存放在未壓縮字段中。但是在實(shí)際中，1，64，255這三種跳數(shù)限制已經(jīng)可以滿足大部分的應(yīng)用需求，因此本文提出一種支持對(duì)跳數(shù)限制壓縮的IPv6報(bào)頭壓縮方法，最理想情況下可以將IPv6報(bào)頭壓縮到1B。

　　如果將跳數(shù)限制壓縮，就要從HC1字節(jié)中節(jié)省出兩個(gè)比特，用來標(biāo)識(shí)跳數(shù)限制的4種狀態(tài)(未壓縮、1、64、255)，HC1字節(jié)中前4個(gè)比特都用來描述IPv6源地址和目的地址的壓縮狀態(tài)，存在一定的冗余性。因?yàn)楦鶕?jù)上文的分析，不需要1個(gè)比特來專門標(biāo)識(shí)IPv6接口標(biāo)識(shí)符的壓縮狀態(tài)，如果IEEE 802.15.4尋址模式為64位擴(kuò)展地址，接口標(biāo)識(shí)符可以直接壓縮掉，如果尋址模式為16位短地址，接口標(biāo)識(shí)符不可以壓縮，需要攜帶在未壓縮字段中。因此HC1字節(jié)中只需要2個(gè)比特標(biāo)識(shí)IPv6地址前綴的壓縮狀態(tài)，可以節(jié)省下2個(gè)比特用來標(biāo)識(shí)跳數(shù)限制的壓縮狀態(tài)。具體壓縮方案如圖4所示。

　　2.3 實(shí)現(xiàn)流程

　　為了實(shí)現(xiàn)IPv6報(bào)頭壓縮與解壓縮的功能，在適配層和網(wǎng)絡(luò)層之間加入壓縮控制層，網(wǎng)絡(luò)層的數(shù)據(jù)經(jīng)過壓縮控制層的處理之后交給適配層處理，同樣適配層的數(shù)據(jù)經(jīng)過壓縮控制層之后交給網(wǎng)絡(luò)層處理，處理流程如圖5所示。系統(tǒng)頭文件中定義一個(gè)預(yù)編譯開關(guān)來控制IPv6報(bào)頭是否要進(jìn)行壓縮，當(dāng)開關(guān)打開時(shí)，數(shù)據(jù)包將會(huì)進(jìn)入壓縮器進(jìn)行處理。壓縮器首先要完成節(jié)點(diǎn)本地環(huán)境的檢測(cè)，主要包括對(duì)IEEE 802.15.4地址模式、IPv6地址前綴類型、服務(wù)類型和流標(biāo)簽狀態(tài)、下一個(gè)首部類型、跳數(shù)限制需求和下一個(gè)首部壓縮狀態(tài)的檢測(cè)，之后根據(jù)節(jié)點(diǎn)本地環(huán)境進(jìn)行HC1字節(jié)和未壓縮字段的填充。

　　數(shù)據(jù)包的解壓縮過程正好是數(shù)據(jù)包壓縮的逆程，解壓縮器首先要根據(jù)IEEE 802.15.4地址類型還原接口標(biāo)識(shí)符，然后通過解碼HC1字節(jié)可以將IPv6報(bào)頭中壓縮掉的字段恢復(fù)出來，最后在配合未壓縮字段的內(nèi)容就可以還原完整的IPv6報(bào)頭。

　　3 功能測(cè)試及性能分析

　　3.1 功能測(cè)試

　　該系統(tǒng)中節(jié)點(diǎn)使用64位擴(kuò)展地址作為底層的尋址模式，6LoWPAN網(wǎng)絡(luò)的內(nèi)部使用IPv6本地鏈路地址進(jìn)行通信，在單跳情況下使用Sniffer無線嗅探儀捕捉到的壓縮前后數(shù)據(jù)包內(nèi)容如圖6所示。根據(jù)具體的IPv6報(bào)頭格式并按照上文提到的IPv6報(bào)頭壓縮方案將原40 B的IPv6報(bào)頭壓縮到1 B，壓縮前總數(shù)據(jù)包長(zhǎng)度為85 B，壓縮后總數(shù)據(jù)包長(zhǎng)度為46 B，壓縮效率為(85-46)/85=45.9%，對(duì)于多跳情況下，適配層會(huì)增加一個(gè)Mesh頭部，該頭部長(zhǎng)度為17 B，因此對(duì)應(yīng)于多跳情況下壓縮效率為[(85+17)-(46+17)]/(85+17)=38.2%?；谝陨鲜聦?shí)，下文通過存儲(chǔ)開銷、網(wǎng)絡(luò)生存時(shí)間、丟包率、平均時(shí)延4個(gè)方面對(duì)報(bào)頭壓縮進(jìn)行性能分析。

　　3.2 存儲(chǔ)開銷

　　節(jié)點(diǎn)的程序代碼存放在ATmega128的ROM中，大小為128 KB，數(shù)據(jù)空間為ATmega128的RAM，大小為4 KB。在把報(bào)頭壓縮開關(guān)打開和關(guān)閉的情況下，使用AVR Studio4工具分別對(duì)同一序進(jìn)行編譯，軟件輸出結(jié)果如表1所示。

　　由表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&TImes;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)頭的壓縮支持。