一種基于IPv6的互轉(zhuǎn)網(wǎng)關(guān)體系結(jié)構(gòu)

汪迅寶，劉 超 ，張 程，陳付龍 ，3

(1.安徽國際商務職業(yè)學院信息服務系，安徽合肥230000;2.網(wǎng)絡與信息安全安徽省重點實驗室，安徽蕪湖241002；3.安徽師范大學計算機科學與技術(shù)系，安徽蕪湖241002)

“物聯(lián)網(wǎng)”(Internet of things，IoT)作為一種“物物相連的互聯(lián)網(wǎng)”[1]，其網(wǎng)絡節(jié)點不再是單純的網(wǎng)絡設備，而是通過網(wǎng)絡擴展到的任何物品。異構(gòu)網(wǎng)絡之間的互聯(lián)互通是物聯(lián)網(wǎng)首要解決的問題。在IoT環(huán)境中,不僅要求傳感器節(jié)點能夠?qū)⒉杉瘮?shù)據(jù)通過互聯(lián)網(wǎng)發(fā)送至服務器,還要求互聯(lián)網(wǎng)上服務器能夠準確定位每一個傳感器節(jié)點并向其傳輸控制指令,同時不應受到傳感器節(jié)點網(wǎng)絡環(huán)境變化的影響。傳統(tǒng)的IoT中協(xié)議轉(zhuǎn)換網(wǎng)關(guān)[2]僅考慮協(xié)議數(shù)據(jù)間的轉(zhuǎn)換,當物聯(lián)子網(wǎng)中的節(jié)點網(wǎng)絡環(huán)境發(fā)生變化時,難以有效地實現(xiàn)數(shù)據(jù)通路。

IPv6作為下一代互聯(lián)網(wǎng)核心技術(shù),擁有龐大的地址空間,可滿足部署大規(guī)模、高密度的傳感器網(wǎng)絡設備的需求，其在IoT中的應用成為必然[2]。2007年國際互聯(lián)網(wǎng)工程任務組(The Internet Engineering Task Force，IETF)成立6LoWPAN工作組，專門研究適配層、路由、報頭壓縮、分片、IPv6網(wǎng)絡接入和網(wǎng)絡管理等技術(shù)[3]。歐盟第七框架計劃也設立了IoT6[4]，旨在探索用IPv6及相關(guān)標準(6LoWPAN等)解決物聯(lián)網(wǎng)面臨問題的途徑。國內(nèi)肖融等[5]提出一種IPv6輕量級樹型層次轉(zhuǎn)化模型(TFAD),進而給出IPv6層次結(jié)構(gòu)地址壓縮機制(IACH),利用層次結(jié)構(gòu)中父子節(jié)點的IPv6地址繼承關(guān)系,以保證IPv6數(shù)據(jù)包在轉(zhuǎn)發(fā)過程中使用最為精簡的地址形式。胡光武等[6]設計了基于IPv6的物聯(lián)網(wǎng)末梢網(wǎng)絡分布式源地址驗證方案，以微小的代理實現(xiàn)了物聯(lián)網(wǎng)節(jié)點IP地址的分配，同時保證物聯(lián)子網(wǎng)節(jié)點之間、以及物聯(lián)子網(wǎng)節(jié)點與互聯(lián)網(wǎng)節(jié)點之間通信時雙方IP地址的真實可靠性。然而在模型驗證與實驗驗證方面，尚需要針對具體應用進行測試。

本文引入通信輔助網(wǎng)關(guān)，提出一種基于IPv6的IoT四層體系結(jié)構(gòu),即感知執(zhí)行層、通信輔助層、網(wǎng)絡傳輸層和應用服務層,并對感知執(zhí)行層與通信輔助層工作機理及協(xié)議報文格式進行重點設計，利用Ptolemy II建模環(huán)境對新建IoT通信體系結(jié)構(gòu)進行建模、仿真與驗證。

1 互轉(zhuǎn)網(wǎng)關(guān)體系結(jié)構(gòu)

傳統(tǒng)的ZigBee/WiFi互轉(zhuǎn)網(wǎng)關(guān)[7-10]僅考慮了兩種通信協(xié)議之間的互轉(zhuǎn)，若需要支持藍牙、3G、4G等通信方式，則需要制定更多的互轉(zhuǎn)協(xié)議，不利于IoT通信的擴展。因此，本文利用IPv6[11]作為中間協(xié)議，對上述互轉(zhuǎn)網(wǎng)關(guān)進行改造。

圖1為基于IPv6的物聯(lián)網(wǎng)體系結(jié)構(gòu)。該體系結(jié)構(gòu)包括了感知執(zhí)行層(由具有Zigbee通信功能的感知和執(zhí)行節(jié)點組成)、通信輔助層(由具有協(xié)議互轉(zhuǎn)功能的通信輔助網(wǎng)關(guān)組成)、網(wǎng)絡傳輸層(由運行IPv6協(xié)議的設備組成的骨干網(wǎng)絡)、應用服務層(提供高能性的計算與存儲等應用服務)組成，其功能主要在于：為具有較強移動性的感知執(zhí)行節(jié)點快速組網(wǎng)、身份識別;將感知執(zhí)行節(jié)點數(shù)據(jù)傳輸至IPv6骨干網(wǎng)、以及從IPv6骨干網(wǎng)有效接收數(shù)據(jù)。其中，通信輔助網(wǎng)關(guān)為一個基于IPv6的互轉(zhuǎn)網(wǎng)關(guān)，保證感知執(zhí)行網(wǎng)絡快速的建立，協(xié)助服務器對感知執(zhí)行節(jié)點進行有效定位并實現(xiàn)感知執(zhí)行網(wǎng)絡與IPv6骨干網(wǎng)互連。

圖1 基于IPv6的物聯(lián)網(wǎng)體系結(jié)構(gòu)Fig.1 Architecture of IoT based on IPv6

2 感知執(zhí)行網(wǎng)絡的建立

感知執(zhí)行網(wǎng)絡中，通信輔助網(wǎng)關(guān)充當類似于ZigBee網(wǎng)絡中全功能集設備，網(wǎng)絡由通信輔助網(wǎng)關(guān)建立，通信輔助網(wǎng)關(guān)上電后，選擇一個信道，隨后啟動整個網(wǎng)絡。同時，為實現(xiàn)節(jié)點快速組網(wǎng)，應考慮網(wǎng)絡拓撲結(jié)構(gòu)的選擇、節(jié)點入網(wǎng)過程及幀結(jié)構(gòu)的優(yōu)化。

節(jié)點入網(wǎng)由節(jié)點主動向通信輔助網(wǎng)關(guān)發(fā)出申請，入網(wǎng)請求交互過程如圖2。

1)新節(jié)點向通信輔助網(wǎng)關(guān)發(fā)送注冊消息；

2)通信輔助網(wǎng)關(guān)接收注冊消息后,向入網(wǎng)請求節(jié)點發(fā)送確認消息；

3)通信輔助網(wǎng)關(guān)向入網(wǎng)請求節(jié)點發(fā)送入網(wǎng)許可消息,并按地址的順序遞增方式為節(jié)點分配網(wǎng)絡地址；

4)入網(wǎng)請求節(jié)點向通信輔助網(wǎng)關(guān)返回確認消息,節(jié)點入網(wǎng)完成。

圖2 感知執(zhí)行節(jié)點入網(wǎng)交互圖Fig.2 Networking interaction diagram of sensing/execution node

3 異元網(wǎng)絡互連方案設計

由于協(xié)議體系差異,IPv6網(wǎng)絡節(jié)點與感知執(zhí)行節(jié)點無法直接進行數(shù)據(jù)傳輸。其通信障礙主要有：感知執(zhí)行節(jié)點網(wǎng)絡地址是局域性的,無法被IPv6網(wǎng)絡唯一識別；感知執(zhí)行網(wǎng)絡與IPv6網(wǎng)絡協(xié)議幀格式不同,且IPv6最大傳輸單元(MTU)最小值為1 280 B,而以IEEE 802.15.4為標準的感知執(zhí)行網(wǎng)絡協(xié)議幀長度規(guī)定不超過127 B,二者之間需進行協(xié)議轉(zhuǎn)換和傳輸效率最優(yōu)化設計。

3.1 感知執(zhí)行節(jié)點識別機制

圖3所示為感知執(zhí)行節(jié)點識別交互過程，其通信輔助網(wǎng)關(guān)實現(xiàn)了IPv6網(wǎng)絡對于低功耗感知執(zhí)行節(jié)點的識別。

圖3 感知執(zhí)行節(jié)點識別交互圖Fig.3 Identification interaction diagram of sensing/execution node

感知執(zhí)行節(jié)點識別主要實現(xiàn)過程如下。

1)通信輔助網(wǎng)關(guān)在建立感知執(zhí)行網(wǎng)絡的同時,通過執(zhí)行IPv6無狀態(tài)地址自動配置協(xié)議,生成EUI-64標識符,并結(jié)合IPv6路由器宣告的地址前綴,獲取IPv6全球單播地址。

2)當感知執(zhí)行網(wǎng)絡有新節(jié)點請求入網(wǎng)時,通信輔助網(wǎng)關(guān)在接收節(jié)點注冊消息的同時,獲取注冊消息中節(jié)點的MAC地址字段內(nèi)容,并向IPv6網(wǎng)絡中服務器發(fā)送綁定消息報文,進行通信輔助網(wǎng)關(guān)IPv6地址與節(jié)點MAC地址的綁定。

3)服務器接收綁定消息報文后,獲取源地址字段內(nèi)容(即通信輔助網(wǎng)關(guān)IPv6地址)和載荷字段數(shù)據(jù)(即感知執(zhí)行節(jié)點MAC地址),并查找“通信輔助網(wǎng)關(guān)IPv6地址-節(jié)點MAC地址”映射表,若節(jié)點MAC地址字段存在相同數(shù)據(jù),則進行對應的通信輔助網(wǎng)關(guān)IPv6地址更新,否則新增一條記錄。映射表設計如表1。

表1 “通信輔助網(wǎng)關(guān)IPv6地址-節(jié)點MAC地址”映射表Tab.1 Mapping of“communication auxiliary gateway IPv6 address-node MAC address”

4)通信輔助網(wǎng)關(guān)向入網(wǎng)請求節(jié)點發(fā)送入網(wǎng)許可消息,分配網(wǎng)絡地址,在收到入網(wǎng)請求節(jié)點確認消息后,通信輔助網(wǎng)關(guān)在自身的“節(jié)點MAC地址-節(jié)點網(wǎng)絡地址”映射表中記錄入網(wǎng)請求節(jié)點MAC地址與所分配的網(wǎng)絡地址信息,映射表設計如表2。

3.2 協(xié)議幀格式轉(zhuǎn)換及數(shù)據(jù)通路模型

在感知執(zhí)行網(wǎng)絡中,感知執(zhí)行節(jié)點采集的信息數(shù)據(jù)封裝為數(shù)據(jù)消息傳送至通信輔助網(wǎng)關(guān)。通信輔助網(wǎng)關(guān)與IPv6網(wǎng)絡的數(shù)據(jù)傳輸采用IPv6消息報文形式，并封裝為依據(jù)IEEE 802.11標準規(guī)定的WiFi數(shù)據(jù)幀格式(或依據(jù)IEEE 802.3標準規(guī)定的Ethernet數(shù)據(jù)幀格式),隨后傳送至IPv6網(wǎng)關(guān)。

由于IPv6網(wǎng)絡與感知執(zhí)行網(wǎng)絡協(xié)議體系不同,其傳輸幀格式、幀大小限制等存在差異,需進一步進行協(xié)議轉(zhuǎn)換和適配。通信輔助網(wǎng)關(guān)協(xié)議轉(zhuǎn)換模型如圖4,其中緩存區(qū)用于存放“節(jié)點MAC地址-節(jié)點網(wǎng)絡地址”映射表及其他所需的臨時數(shù)據(jù)。感知執(zhí)行網(wǎng)絡接口、WiFi接口、Ethernet接口分別用于對感知執(zhí)行網(wǎng)絡中各類消息、WiFi幀、Ethernet幀的收發(fā)。模塊A和B分別對異元網(wǎng)絡環(huán)境下不同結(jié)構(gòu)數(shù)據(jù)包逐層進行解包或封裝操作。

依據(jù)通信輔助網(wǎng)關(guān)建立的數(shù)據(jù)通路模型如5。在感知執(zhí)行節(jié)點完成入網(wǎng)及綁定操作前提條件下,實現(xiàn)數(shù)據(jù)雙向傳輸。

表2 “節(jié)點MAC地址-節(jié)點網(wǎng)絡地址”映射表Tab.2 Mapping of“node MAC address-node network address”

圖4 通信輔助網(wǎng)關(guān)協(xié)議轉(zhuǎn)換模型Fig.4 Protocol conversion model of communication auxiliary gateway

4 建模與驗證

為了驗證本文所提的基于IPv6的互轉(zhuǎn)體系結(jié)構(gòu)工作機制的可行性，利用Ptolemy II建模環(huán)境[12]對其進行建模仿真，其頂層模型如圖6所示。感知執(zhí)行網(wǎng)絡中的節(jié)點通信通過SenseChannel信道完成,每個感知執(zhí)行網(wǎng)絡均存在一個通信輔助網(wǎng)關(guān),通過WiFiChannel或Ethernet鏈路與IPv6網(wǎng)關(guān)完成連接,IPv6骨干網(wǎng)中設備以有線以太網(wǎng)方式連接,整個模型的運行時間、順序等屬性受到Wireless Director組件的控制。

圖5 數(shù)據(jù)通路模型Fig.5 Data path model

4.1 上行傳輸數(shù)據(jù)通路驗證

理想情況下,感知執(zhí)行節(jié)點按泊松分布函數(shù),以平均時間0.1 s產(chǎn)生數(shù)據(jù)消息報文,經(jīng)過通信輔助網(wǎng)關(guān)及IPv6網(wǎng)絡傳輸至服務器,為便于觀察，提取所傳輸數(shù)據(jù)報文中的應用層數(shù)據(jù)，如圖7所示?？梢钥闯?，由感知執(zhí)行節(jié)點采集的數(shù)據(jù)在經(jīng)過一定的網(wǎng)絡延時(包括通信輔助網(wǎng)關(guān)延時、路由器延時)后,服務器基本能夠正常接收來自感知執(zhí)行節(jié)點的傳輸數(shù)據(jù)。進一步在具有一定丟包率的信道中進行數(shù)據(jù)傳輸測試，發(fā)現(xiàn)存在個別數(shù)據(jù)的丟失,如感知執(zhí)行節(jié)點發(fā)送的第1個、第2個數(shù)據(jù)，但大部分數(shù)據(jù)均能夠被正常接收(圖8)，表明所設計的ZigBee/WiFi互轉(zhuǎn)網(wǎng)關(guān)可以實現(xiàn)傳感器網(wǎng)絡中數(shù)據(jù)向IPv6網(wǎng)絡中節(jié)點的有效傳輸。

圖6 基于Ptolemy II的IoT通信體系結(jié)構(gòu)模型Fig.6 IoT architecture model based on Ptolemy II

圖7 理想情況數(shù)據(jù)上行傳輸情況Fig.7 Data uplink transmission in the ideal case

4.2 下行傳輸數(shù)據(jù)通路驗證

下行傳輸由服務器發(fā)起，服務器按泊松分布函數(shù)以平均時間0.1 s產(chǎn)生數(shù)據(jù)消息報文,理想情況下的下行傳輸結(jié)果如圖9所示,服務器可準確地對指定的感知執(zhí)行節(jié)點傳輸數(shù)據(jù)。在存在丟包率的信道中,存在數(shù)據(jù)丟失情況，如圖10,且由于網(wǎng)絡擁塞，感知執(zhí)行節(jié)點接收部分數(shù)據(jù)的延時大于正常網(wǎng)絡延時，如在6.2 s時刻由服務器發(fā)送的數(shù)據(jù)，直到7.1 s時刻才被感知執(zhí)行節(jié)點接收。盡管存在網(wǎng)絡延時、擁塞、數(shù)據(jù)丟失等情況，但最終仍有較多數(shù)據(jù)能夠被感知執(zhí)行節(jié)點正常接收,從而驗證了下行傳輸數(shù)據(jù)通路的可用性。經(jīng)過上行傳輸數(shù)據(jù)通路與下行傳輸數(shù)據(jù)通路的驗證，可以得以下結(jié)論：在通信輔助網(wǎng)關(guān)的協(xié)助下,IPv6網(wǎng)絡節(jié)點與感知執(zhí)行節(jié)點可以有效進行數(shù)據(jù)傳輸,從而實現(xiàn)異構(gòu)網(wǎng)絡之間的互聯(lián)互通。

圖8 存在丟包率的信道中數(shù)據(jù)上行傳輸情況Fig.8 Data uplink transmission with a certain packet loss rate

圖10 存在丟包率的信道中數(shù)據(jù)下行傳輸情況Fig.10 Data downlink transmission with a certain packet loss rate

5 結(jié) 語

構(gòu)建異元網(wǎng)絡需要解決不同協(xié)議傳輸轉(zhuǎn)換問題，選取ZigBee無線傳輸模式和WiFi無線傳輸模式進行融合，突破了異元網(wǎng)絡傳輸障礙。另外，IPv6在IoT中的應用是大勢所趨，基于IPv6的IoT四層體系結(jié)構(gòu)有效實現(xiàn)了數(shù)據(jù)的雙向傳輸。

需要指出的是，基于IPv6的互轉(zhuǎn)網(wǎng)關(guān)通信體系結(jié)構(gòu)還有很多關(guān)鍵問題需要進一步研究，當感知執(zhí)行網(wǎng)絡中節(jié)點數(shù)量足夠龐大時,通信輔助網(wǎng)關(guān)和服務器中的映射表如何進行高效的存儲與檢索,下行傳輸過程中IPv6消息報文的分片與重組問題[13],面向IoT的IPv6網(wǎng)絡路由機制等問題將是下一步研究工作重點。