摘要：無線傳感器網絡節(jié)點的資源非常有限，如果能夠對IPv6報頭進行壓縮可以在較大程度上減小數據傳輸量，提高IPv6傳感器網絡的整體性能。通過對6LoWPAN報頭壓縮方案的研究，并結合無線傳感器網絡的特點和實際需求，在已有無線傳感器網絡底層協議和基本IPv6協議棧基礎上，設計并實現了一種支持對跳教限制壓縮的IPv6報頭壓縮方法。實驗結果表明，報頭壓縮可以有效節(jié)省網絡能耗，降低丟包率，減小數據傳輸時延。
關鍵詞：無線傳感器網絡；IPv6；報頭壓縮；6LoWPAN

0 引言
    無線傳感器網絡是由大量按需隨機分布的集成有傳感器、數據處理單元和通信模塊的微型節(jié)點以自組織方式構成的無線網絡。傳感器網絡具有成本低、能耗代、靈活性高等優(yōu)點，可以應用于國防軍事、環(huán)境監(jiān)測、交通管理、醫(yī)療衛(wèi)生、反恐抗災等領域，具有重要的研究價值和應用前景。無線傳感器網絡節(jié)點的資源非常有限，因此需要一個輕量級的無線通信規(guī)范。IEEE 802．15．4標準定義了一個短距離、低復雜度、低功耗、低數據速率的介質訪問控制層(MAC)和物理層(PHY)規(guī)范，該標準的技術特點決定了它特別適合傳感器網絡、智能家庭網絡、工業(yè)控制網絡等節(jié)點眾多、數據率較低的應用環(huán)境。IPv6作為下一代網絡協議，具有地址資源豐富、地址自動配置、安全性高、移動性好等優(yōu)點，可以滿足無線傳感器網絡在地址、安全、移動及與現有網絡融合等方面的需求。因此，IPv6與IEEE 802．15．4在傳感器網絡上的結合有著無可比擬的應用前景。
    2004年11月IETF成立了6LoWPAN(IPv6 overLow power WPAN)工作組，研究IPv6在IEEE 802．15．4網絡上的應用方案。6LoWPAN工作小組對適配層技術、報頭壓縮技術、路由技術、IPv6技術等提出了相應的解決辦法。IPv6要求支持1 280 B的MTU，而IEEE802．15．4標準規(guī)定的物理層最大幀為127 B，除去物理層25 B的幀負載，在無安全機制的情況下MAC層最大幀長度為102 B，因此需要在網絡層之下引入適配層來協調二者的關系。由于IPv6標準報頭是40 B，為了在IEEE 802．15．4上更加有效的傳輸IPv6數據包，提高凈荷的傳輸效率，報頭壓縮是一個很好的解決辦法。
    本文以北京交通大學下一代互聯網互聯設備國家工程實驗室自主開發(fā)和研制的微型傳感路由器所構建的IPv6無線傳感器網絡為基礎，設計并實現了一種更為高效的IPv6報頭壓縮方法，并對壓縮性能進行了分析。

1 平臺簡介
    本文基于IPv6無線傳感器網絡平臺的拓撲結構及協議層次如圖1所示。IPv6無線傳感器網絡節(jié)點設備可以自組織形成多跳Mesh網絡，將采集到的溫度、濕度、光強等環(huán)境信息發(fā)送給網關設備。網關設備通過以太網直連的方式與服務器進行通信，并把收到的來自傳感器節(jié)點的數據提交給服務器，服務器端完成對整個IPv6傳感器網絡的控制和環(huán)境信息的人性化顯示。

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

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

    如圖2所示，版本、傳輸類型和流標簽(全部為零)、凈荷長度(可以從IEEE 802．15．4 MAC頭中凈荷長度字段推斷出來)均可以壓縮掉，下一個報頭字段攜帶在HC1字節(jié)中，跳數限制字段不壓縮，存放在未壓縮字段中。標準中規(guī)定IPv6地址采用無狀態(tài)的配置式，地址由64位前綴和64位接口標識符(Interface ID，IID)生成。IEEE 802．15．4定義了兩種尋址模式：IEEE 64位擴展地址和16位短地址。每一個IEEE802．  15．4設備都有一個分配的EUI-64標識符，該標識符用作64位擴展地址進行尋址，具有全球惟一性，并且通過該EUI-64標識符可以生成一個IPv6接口標識符，實現IPv6地址的自動配置。16位短地址是在節(jié)點成功加入網絡后，由節(jié)點所在PAN內的協調者動態(tài)分配，只能保證在該PAN內的惟一性，不能用作實現IPv6地址的自動配置。因此如果IPv6地址為本地鏈路地址(前綴為fe80：：／64)，并且IEEE 802．15．4尋址模式為64位擴展地址，就可以將IPv6地址壓縮掉，否則就要將其在未壓縮字段中攜帶。
    圖3為HC1字節(jié)具體編碼格式。

    另一種是現有報頭壓縮草案中定義的方案。該方案提出了對本地鏈路地址、全球單播地址、多播地址等IPv6地址的壓縮方法，同時解決了源壓縮方案不具有協議層次性的弊端。而且該壓縮方案支持IPv6擴展報頭的壓縮和流標簽、服務類型的區(qū)分。但是這種壓縮方案過于復雜，對于處理能力有限、能量受限、硬件資源匱乏并且以環(huán)境監(jiān)測為主要應用的傳感器節(jié)點來說并不實用。因此本文提出一種基于RFC4944的IPv6報頭壓縮改進方案。
2．2 改進方案
    雖然RFC4944中提到的壓縮方案已經很精簡，但是這種方法仍然存有冗余。方案中對于IPv6報頭的跳數限制字段并沒有壓縮，而是始終占用1 B存放在未壓縮字段中。但是在實際中，1，64，255這三種跳數限制已經可以滿足大部分的應用需求，因此本文提出一種支持對跳數限制壓縮的IPv6報頭壓縮方法，最理想情況下可以將IPv6報頭壓縮到1B。
    如果將跳數限制壓縮，就要從HC1字節(jié)中節(jié)省出兩個比特，用來標識跳數限制的4種狀態(tài)(未壓縮、1、64、255)，HC1字節(jié)中前4個比特都用來描述IPv6源地址和目的地址的壓縮狀態(tài)，存在一定的冗余性。因為根據上文的分析，不需要1個比特來專門標識IPv6接口標識符的壓縮狀態(tài)，如果IEEE 802．15．4尋址模式為64位擴展地址，接口標識符可以直接壓縮掉，如果尋址模式為16位短地址，接口標識符不可以壓縮，需要攜帶在未壓縮字段中。因此HC1字節(jié)中只需要2個比特標識IPv6地址前綴的壓縮狀態(tài)，可以節(jié)省下2個比特用來標識跳數限制的壓縮狀態(tài)。具體壓縮方案如圖4所示。

2．3 實現流程
    為了實現IPv6報頭壓縮與解壓縮的功能，在適配層和網絡層之間加入壓縮控制層，網絡層的數據經過壓縮控制層的處理之后交給適配層處理，同樣適配層的數據經過壓縮控制層之后交給網絡層處理，處理流程如圖5所示。系統頭文件中定義一個預編譯開關來控制IPv6報頭是否要進行壓縮，當開關打開時，數據包將會進入壓縮器進行處理。壓縮器首先要完成節(jié)點本地環(huán)境的檢測，主要包括對IEEE 802．15．4地址模式、IPv6地址前綴類型、服務類型和流標簽狀態(tài)、下一個首部類型、跳數限制需求和下一個首部壓縮狀態(tài)的檢測，之后根據節(jié)點本地環(huán)境進行HC1字節(jié)和未壓縮字段的填充。
    數據包的解壓縮過程正好是數據包壓縮的逆程，解壓縮器首先要根據IEEE 802．15．4地址類型還原接口標識符，然后通過解碼HC1字節(jié)可以將IPv6報頭中壓縮掉的字段恢復出來，最后在配合未壓縮字段的內容就可以還原完整的IPv6報頭。

3 功能測試及性能分析
3．1 功能測試
    該系統中節(jié)點使用64位擴展地址作為底層的尋址模式，6LoWPAN網絡的內部使用IPv6本地鏈路地址進行通信，在單跳情況下使用Sniffer無線嗅探儀捕捉到的壓縮前后數據包內容如圖6所示。根據具體的IPv6報頭格式并按照上文提到的IPv6報頭壓縮方案將原40 B的IPv6報頭壓縮到1 B，壓縮前總數據包長度為85 B，壓縮后總數據包長度為46 B，壓縮效率為(85-46)／85=45．9％，對于多跳情況下，適配層會增加一個Mesh頭部，該頭部長度為17 B，因此對應于多跳情況下壓縮效率為[(85+17)-(46+17)]／(85+17)=38．2％。基于以上事實，下文通過存儲開銷、網絡生存時間、丟包率、平均時延4個方面對報頭壓縮進行性能分析。
3．2 存儲開銷
    節(jié)點的程序代碼存放在ATmega128的ROM中，大小為128 KB，數據空間為ATmega128的RAM，大小為4 KB。在把報頭壓縮開關打開和關閉的情況下，使用AVR Studio4工具分別對同一序進行編譯，軟件輸出結果如表1所示。

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

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

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

    由圖可見網絡的平均延時基本與跳數為線性增加的關系，單跳情況下壓縮與不壓縮的網絡時延之差大概在2．5 ms左右。因為Ping命令測試的是往返時間，所以這與理論分析相吻合，隨著跳數的增加時延之差基本線性增長。

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