本文針對無線傳感器網絡與IPv6網絡互聯，在分析現有接入方式不足的基礎上提出了一種基于IPv6的無線傳感器網絡邊界路由器的設計方案。方案主要闡述了邊界路由器的硬件和軟件設計的實現，重點介紹了基于IPv6的無線傳感器網絡協議棧適配層的設計。通過數據包分片與重組機制以及報頭壓縮機制，協議棧適配層實現了IPv6數據包在IEEE 802.15.4鏈路中的傳輸。實驗結果表明，該設計方案實現了無線傳感器網絡與IPv6網絡的無縫融合，數據傳輸穩定可靠，具有實用性的應用價值。
0 引言
無線傳感器網絡(Wireless Sensor Network，WSN)近年來發展迅速，在環境保護、工業設備監控、醫療監護、農田監測、智能家居、市政交通管理、軍事偵察等領域具有廣闊的應用前景。無線傳感器網絡的諸多應用都需要遠程用戶能夠方便地對無線傳感器網絡資源進行訪問、控制和使用。TCP/IP的廣泛應用已經使其成為事實上的協議標準，加之IPv6 的諸多優良特性，都使得實現無線傳感器網絡與IPv6網絡的互聯與融合是當前最現實的選擇。
目前，無線傳感器網絡與IPv6 網絡互聯主要有網關接入和直接接入兩種方式。其中，網關接入是指利用網關在無線傳感器網絡和IP 網絡之間進行協議轉換，實現數據的轉發任務，但是網關接入還存在著網絡結構復雜、成本較高等諸多問題;直接接入方式是指在無線傳感器網絡節點直接運行 IPv6 協議，能夠實現無線傳感器網絡和Internet網絡的無縫融合。無線傳感器網絡是低速率、低功耗的資源受限網絡，在無線傳感器節點上并不適合直接運行標準IPv6協議。
本文提出了一種基于JN5148模塊的無線傳感器網絡邊界路由器的設計方案，該方案能夠實現無線傳感器網絡與IPv6 網絡的無縫融合，并通過實際測試證明了該方案的可行性。
1 邊界路由器硬件設計
邊界路由器硬件包括射頻模塊、處理器模塊和電源模塊等部分。其中，射頻模塊負責IEEE 802.15.4 數據幀的收發;處理器模塊負責解析收到的數據幀，選擇路徑后進行轉發處理;電源模塊負責對其他模塊供電。邊界路由器的硬件結構如圖1所示。
1.1 射頻模塊
目前，無線傳感器網絡領域面向不同應用的協議棧眾多，其中絕大部分協議棧都把IEEE 802.15.4作為物理層和數據鏈路層的無線通信標準。支持IEEE 802.15.4的射頻模塊主要有Jennic 公司的JN5148、Ember250、MC13192、TI公司的CC2430 和Digi公司的XBEE 模塊。
其中，JN5148模塊將射頻芯片與處理器集成一體，內置了IEEE 802.15.4 協議，不需要自行設計無線射頻天線接口，開發成本較低，本文設計中選用Jennic 公司的JN5148 模塊作為邊界路由器的處理器和射頻模塊。
JN5148模塊集成了基于OpenRISC核的32位RISC處理器，擁有完全兼容2.4 GHz IEEE 802.15.4標準的無線收發器，128 KB 的RAM 運行應用程序，512 KB 的FLASH能夠滿足包括存儲應用程序在內的大部分需求。
1.2 串行通信接口設計
無線傳感器網絡數據流量較小，對網絡帶寬要求不高，因此邊界路由器與Internet網絡之間可以采用UART串行總線連接。目前，各種網絡設備中普遍應用USB接口，可以使用轉換電路將USB接口轉換為UART串行總線接口，本文選擇 FTDI232R芯片完成電平匹配和接口轉換，FTDI232R 是一款可編程的USB 接口轉UART 接口的集成芯片，具有3.3 V電壓輸出，可編程顯示數據收發狀態。具體電路如圖2所示。
2 邊界路由器軟件設計
2.1 協議棧框架設計
無線傳感器網絡協議棧是無線傳感器網絡軟件設計的核心，是無線傳感器網絡組網、節點與邊界路由器以及節點與節點之間數據通信的基礎。為了滿足無線傳感器網絡全IP 互聯，需要精簡IPv6 協議以及實現IPv6數據幀在IEEE 802.15.4幀中傳輸。本文設計的邊界路由器采用基于IPv6的無線傳感器網絡協議棧。協議棧框架如圖3所示。
IEEE 802.15.4物理層主要負責啟動和關閉射頻收發器、能量檢測與信道掃描、清除信道評估以及無線電波信號的調制和解調等工作。IEEE 802.15.4 MAC層主要完成信道接入、鏈路的連接及斷開以及數據通信的差錯及流量控制等工作。輕量級操作系統Contiki負責協議棧各層任務調度及管理，保證協議棧工作的實時性。
協議棧包括的任務有自組網任務、適配層主任務、網絡維護任務、IP層任務以及應用層任務，任務調度關系如圖4 所示。
本設計選用的JN5148 模塊內部集成了IEEE802.15.4的物理層和MAC層協議，因此，協議棧設計的重點是適配層、IP網絡層和傳輸層。
2.2 適配層設計
組建網絡是邊界路由器適配層需要完成的基本任務，系統啟動后，自組網任務負責在選定信道和網絡16 位PAN_ID后建立網絡。網絡維護任務在網絡建立后維持父節點與子節點之間的鏈路穩定，并在鏈路出現異常時進行上報并嘗試修復鏈路。IEEE 802.15.4物理層數據單元最大為127 B，而IPv6 要求鏈路支持的最小MTU(Maximum Transmission Unit，MTU)長度為1 280 B，明顯不支持此長度MTU.適配層介于IEEE 802.15.4 MAC層和IP 層之間，因此適配層主任務除了負責管理MAC層協議事件之外，主要完成節點自動地址配置、IP數據包的分片與重組和IP數據包頭壓縮與解壓等功能以實現 IP數據包在IEEE 802.15.4鏈路中的傳輸。
2.2.1 地址映射機制
基于IPv6的無線傳感器網絡中每個節點都需要配置惟一的IPv6 地址，但是手動配置繁瑣并且難以保證地址惟一性。本文設計的無線傳感器網絡邊界路由器采用無狀態地址自動配置機制。IPv6地址由全局地址前綴和接口標識 ID(Interface ID，IID)兩部分組成。因為每一個射頻模塊都分配有一個全球惟一的IEEE EUI-64標識符，即64位MAC 地址，因此可以利用EUI-64標識符獲得一個IPv6地址接口標識ID來實現無狀態地址自動配置。
2.2.2 適配層分片與重組機制
為了減少適配層包頭開銷，適配層幀頭分為不分片和分片兩種格式，分別用于IP數據包長度小于MAC 層MTU 的報文和IP 數據包長度大于MAC 層MTU 的報文。適配層不分片幀頭格式與常規幀頭相同，分片幀頭又分為第一個分片和后續分片兩種格式，如圖5和圖6所示。
節點適配層接收到適配層數據包時，首先檢查該數據包是否分片，如果是一個分片的數據包，則在將所有數據分片重新組合成完整的IP 數據包后，再傳送到IP網絡層處理;若某一個分片丟失，則丟棄該IP數據包的所有后續分片。對于IP 層下發的數據包，節點適配層判斷IP報文長度是否超過鏈路層MTU 長度，若超過鏈路層MTU長度，則將此IP數據包分片后發送;若不超過鏈路層MTU長度，則按照不分片格式發送。
適配層的每一種數據幀都有調度編碼位域(8位)，不同的調度編碼位域表示不同的解析方式，主要包括不分片、分片、IP包頭壓縮、UDP報頭壓縮以及預留功能等多種類型。其中，11000xxx表示本數據幀是已分片適配層數據幀的第一個分片，11100xxx則表示本數據幀是已分片適配層數據幀的后續分片。
datagram_size:11 b，表示鏈路層未分包之前的IP數據包的總長度，該IP 數據包所有鏈路層分片的該字段的值都應該相同。
datagram_tag:16 b，分片標識，用來區分同一數據源節點的不同IP數據包。同一個IP數據包的所有鏈路層分片都具有相同的分片標識，數據源節點每成功發送一個完整的IP數據包都更新(加1)該字段的值。
datagram_offset:8 b，分片偏移量，表示該分片在所有分片中的偏移量(以8 B 為單位)，該字段只出現在第二個及后續分片中。
2.2.3 適配層報頭壓縮機制
標準IPv6 網絡層報文和UDP 報文的報頭分別有40 B 和8 B，由此帶來的數據傳輸報頭開銷極大，因此本文適配層對IP報文和UDP報文的包頭格式進行了壓縮處理。由于TCP報文并不適合無線傳感器網絡這種多跳、數據傳輸延遲較大的網絡[11]，故本文暫不考慮TCP報文。根據無線傳感器網絡的上下文信息，IPv6版本號和負載長度可以省略，通信流類型、流標簽、下一包頭、跳數限制以及源地址和目的地址設置壓縮控制域進行部分壓縮。IPv6 網絡層報文頭部壓縮格式如圖7所示。
011xxxxx為調度編碼位域，其中最右端5位用于報頭壓縮編碼。各編碼字段定義如下：
TF:2 b，通信流類型和流標簽。其中通信流類型由查分服務代碼點DSCP 和顯示擁塞反饋ECN，當TF=11時，通信流類型和流標簽全都省略;當TF=00時，通信流類型和流標簽都不壓縮;當TF=01 時，DSCP 省略;當TF=10時，流標簽省略。
NH:1 b，下一包頭。NH=0，表示下一包頭未壓縮;NH=1時，下一包頭已壓縮。
HLIM:2 b，跳數限制。當HLIM 等于00、01、10 和11時，分別表示未壓縮、1跳、64跳和255跳。
M:1 b，指示目的地址類型。當M=0 時，目的地址不是多播地址;當M=1時，目的地址為多播地址。
SAC:1 b，表示源地址的壓縮方式，當它為0時表示使用的是無狀態頭部壓縮;為1時表示使用的是基于上下文的頭部壓縮。
SAM 用來控制不同壓縮方式下源地址壓縮方式。
DAC與DAM 的控制目的地址的壓縮方式，具體含義與SAC和SAM相似。
傳輸層UDP 報文緊跟在IPv6 網絡層包頭后面，UDP 包頭壓縮比較簡單，是否壓縮由前述NH 字段指定。標準UDP報文頭部中的長度域省略，源端口號、目的端口號以及校驗和域的壓縮方式由P和C字段表示，校驗和域暫不壓縮。UDP報文頭部具體壓縮格式如圖8所示。
眾所周知，TCP/IP 端口號為16 位，通常以0xf0 和0xf0b開始，其壓縮方式由P字段指定，具體如下：
00：不壓縮;01：目的端口號前8位(0xf0)省略，其他部分和源端口號保留;10：源端口號前8位(0xf0)省略，其他部分和目的端口保留;11：目的端口和源端口的前12位(oxf0b)省略，其他部分保留。
2.3 IP網絡層與傳輸層設計
標準TCP/IP 協議占用資源較多，而無線傳感器網絡屬于資源受限網絡，因此邊界路由器的設計要特別注意協議棧資源占用。uip IPv6(uIPv6)協議棧專為資源受限的設備設計，RAM的占用量只有1.7 KB，代碼量只有[12]11.5 KB，因此選擇移植uip IPv6 協議棧作為基于IPv6的無線傳感器網絡協議的IP層和傳輸層。
uip IPv6 協議棧的IP 網絡層和傳輸層使用同一個數據緩存區，因此可以將IP 網絡層和傳輸層統一處理。本設計中各功能模塊由輕量級操作系統Contiki統一調度，因而設計一個IP 網絡層任務集中處理從適配層接收到的數據包和應用層需要發送的數據包。
3 測試與分析
3.1 測試平臺搭建
邊界路由器負責WSN 網絡與IPv6 網絡之間的通信，本文實驗驗證了邊界路由器的工作性能。實驗測試平臺包括一個邊界路由器、一個傳感器節點和一臺Linux主機，其中邊界路由器通過 UART接口與Linux主機的USB口連接，鏈路層運行slip協議。邊界路由器和傳感器節點的IPv6地址配置為 aaaa：：215:8d00:b：6840和aaaa：：215:8d00:b：67d3，Linux主機端運行slip守護程序來監聽USB口，其 IPv6地址為aaaa：：1.
3.2 測試結果分析
通過在Linux 主機上向傳感器節點(IPv6 地址為aaaa：：215:8d00:b：67d3)發送ping6 報文，來測試傳感器節點的可達性，以驗證邊界路由器的正常工作，實驗結果如圖9所示。
實驗對邊界路由器的數據包轉發率、平均傳輸延遲和傳輸穩定性進行了分析。其中，數據包轉發率是指 Linux 主機收到的echo 報文數量和發送的ping6報文數量之比;平均傳輸延遲是指Linux主機發送ping6報文和接收到echo報文之間的平均時間間隔;傳輸穩定性是指傳輸延遲的變化幅度，用算術平均差評定。分析結果如圖10~圖12所示。
如圖10和圖11所示，在發送不同長度ping6報文測試時，邊界路由器均具有良好的數據轉發成功率(大于90%)，并且數據傳輸延遲較小。圖12列舉的是發送不同長度ping6報文測試時鏈路傳輸延遲的算術平均差，對于不同長度的測試報文傳，輸延遲算術平均差基本小于15 ms，網絡鏈路傳輸延遲抖動較小，證明網絡的鏈路穩定性較好。
4 結論
本文針對無線傳感器網絡實際應用的現實需求，提出了基于IPv6 的無線傳感器網絡邊界路由器的設計方案。該設計方案實現了無線傳感器網絡與IPv6網絡的無縫融合，降低了網絡應用布置成本，提高了系統的靈活性。實驗證明，該方案設計的邊界路由器具有較低的數據傳輸延遲，網絡的鏈路比較穩定，能夠滿足實際應用要求。
京公網安備 11010502049343號