基于6LoWPAN的物聯(lián)網(wǎng)尋址策略研究

王義君 錢志鴻 王 雪 孫大洋

(吉林大學通信工程學院 長春 130012)

1 引言

物聯(lián)網(wǎng)(Internet of Things, IoTs)包含如下兩層涵義：(1)互聯(lián)網(wǎng)是物聯(lián)網(wǎng)的核心和基礎，物聯(lián)網(wǎng)必須在互聯(lián)網(wǎng)的基礎上進行延伸和擴展；(2)終端用戶延伸和擴展到了所有物品與物品之間，可以使它們之間進行信息交換和通信。國際電信聯(lián)盟將射頻識別技術(Radio Frequency IDentification, RFID)[1,2]、傳感器技術、納米技術、智能嵌入式技術列為物聯(lián)網(wǎng)的關鍵技術。當前階段，物聯(lián)網(wǎng)所要解決的關鍵問題之一是底層異構(gòu)網(wǎng)絡與互聯(lián)網(wǎng)的相互融合[3]。IEEE 802.15.4通信協(xié)議是短距離無線通信標準，相對于藍牙技術[4]而言，更適用于物聯(lián)網(wǎng)底層異構(gòu)網(wǎng)絡設備間的通信。IPv6是下一代互聯(lián)網(wǎng)網(wǎng)絡層的主導技術，在地址空間、報文格式、安全性方面具有較大的優(yōu)勢。6LoWPAN(IPv6 over Low-power Wireless Personal Area Networks)技術通過在網(wǎng)絡層和數(shù)據(jù)鏈路層之間引入適配層[5]，實現(xiàn)基于IEEE 802.15.4通信協(xié)議的底層網(wǎng)絡與基于IPv6協(xié)議的互聯(lián)網(wǎng)的相互融合，適配層主要完成接入過程中的以下功能：(1)為了高效傳輸對 IPv6數(shù)據(jù)包進行分片與重組；(2)網(wǎng)絡地址自動配置；(3)為了降低 IPv6開銷對IPv6分組進行報頭壓縮；(4)有效路由算法。其中，網(wǎng)絡地址自動配置以及IPv6報頭壓縮兩類功能，對于識別接入物聯(lián)網(wǎng)的每個終端節(jié)點，使節(jié)點間能夠相互進行資源共享和信息交換具有最為重要的意義，因此本文圍繞以上兩個方面，在6LoWPAN適配層的基礎上，實現(xiàn)了物聯(lián)網(wǎng)中基于 IEEE 802.15.4通信協(xié)議的底層異構(gòu)網(wǎng)絡與基于IPv6協(xié)議的互聯(lián)網(wǎng)的統(tǒng)一尋址，保證了物聯(lián)網(wǎng)時代網(wǎng)絡層向傳輸層提供靈活簡單、無連接、滿足QoS需求的數(shù)據(jù)報服務[6,7]。

2 研究背景

6LoWPAN協(xié)議基本功能是實現(xiàn)基于 IEEE 802.15.4通信協(xié)議的底層網(wǎng)絡與基于IPv6協(xié)議的互聯(lián)網(wǎng)相互無縫鏈接[8]，從而為物聯(lián)網(wǎng)大規(guī)模應用提供實時可靠的網(wǎng)絡協(xié)議保證[9]，但相關技術存在諸多挑戰(zhàn)。

首先，傳統(tǒng)的地址自動配置方案不適合于物聯(lián)網(wǎng)，主要有兩方面原因：(1)對于有線網(wǎng)絡來說，一個廣播消息可以達到鏈路中的所有節(jié)點，而物聯(lián)網(wǎng)中底層網(wǎng)絡通常采用無線傳輸方式，具有多跳路由的特點，而物聯(lián)網(wǎng)的底層網(wǎng)絡一般不存在帶有整個網(wǎng)絡信息的中心服務器，因此像 DHCP(Dynamic Host Configuration Protocol)這樣的配置方案不適用于物聯(lián)網(wǎng)；(2)物聯(lián)網(wǎng)的底層網(wǎng)絡一般會受到能量的限制，而傳統(tǒng)的地址自動配置方案會給整個物聯(lián)網(wǎng)絡帶來較高的能量和帶寬消耗、通信延遲以及存儲空間的占用。所以，需要研究適用于物聯(lián)網(wǎng)的新的地址自動配置方案。文獻[10]提出利用三原色坐標和節(jié)點位置信息實現(xiàn) IPv6地址自動配置(IPv6 lightweight stateless Address Autoconfiguration for 6LoWPAN using Color Coordinators, CCAA)。相對于傳統(tǒng)方案而言，該方法的重復地址檢測(Duplicate Address Detection, DAD)開銷較小，但由于其需要通過協(xié)調(diào)器節(jié)點獲取地理位置信息，使其在硬件實現(xiàn)及擴展性上存在一定的限制，與此同時，當網(wǎng)內(nèi)傳感器節(jié)點數(shù)量增加時，傳遞 DAD消息的范圍隨之增大，網(wǎng)絡開銷也會大幅度增加。其次，每一種鏈路層協(xié)議都會規(guī)定幀的數(shù)據(jù)部分的長度上限——最大傳送單元MTU(Maximum Transfer Unit)。IEEE 802.15.4協(xié)議定義的MTU為127 byte，除去必要的幀開銷外，留給 MAC幀載荷的長度約為81 byte，而IPv6分組最少為1280 byte，因此IEEE 802.15.4 MAC幀不能封裝完整的IPv6分組。而通過報頭壓縮技術可以提高數(shù)據(jù)傳輸效率和網(wǎng)絡資源利用率。RFC4944[11]中提出的 HC1(Head Compression 1)報頭壓縮方案對于鏈路本地單播通信是十分有效的。但是，由于鏈路本地地址通常適用于局部協(xié)議交互，一般不用于應用層數(shù)據(jù)流，因此 HC1的實際應用價值非常有限。IPHC[12](IPv6 Head Compression)方案選擇性的采用有狀態(tài)壓縮方式，并且利用上下文標識擴展位來增加后續(xù)編碼的策略，對于物聯(lián)網(wǎng)的底層網(wǎng)絡來說，系統(tǒng)開銷和軟件復雜度都會大幅度提升。

本文在6LoWPAN基礎上提出一種適用于物聯(lián)網(wǎng)應用的尋址方案。尋址策略包括IPv6地址自動配置和報頭壓縮兩部分。分層地址自動配置策略，首先在底層網(wǎng)絡內(nèi)部允許節(jié)點使用16 bit短地址導出的鏈路本地地址進行數(shù)據(jù)分組傳輸，并將該鏈路本地地址經(jīng)過基于分簇的重復地址檢測保證唯一性；其次，每個底層網(wǎng)絡中的Sink節(jié)點通過上層IP路由器獲取全球地址路由前綴，并與自身的接口標識符相結(jié)合，形成Sink節(jié)點的全球地址。同時，本文提出一種適用于物聯(lián)網(wǎng)應用的報頭壓縮方案IIPHC(IoTs IPv6 Header Compression)，通過在編碼中植入鏈路本地地址和全球地址控制位決定采用報頭壓縮方案的類型。

本文組織結(jié)構(gòu)如下：本節(jié)介紹了在網(wǎng)絡尋址方面，基于6LoWPAN的底層異絡與互聯(lián)網(wǎng)融合的相關研究背景及技術挑戰(zhàn)；第3節(jié)從地址自動配置和報頭壓縮兩個方面提出了基于6LoWPAN的物聯(lián)網(wǎng)尋址策略；第4節(jié)對物聯(lián)網(wǎng)尋址策略進行了仿真及分析；第5節(jié)對本文的研究作出結(jié)論，總結(jié)全文。

3 物聯(lián)網(wǎng)尋址策略

3.1 地址自動配置

每個802.15.4設備都可以通過一個IEEE EUI-64長地址或一個可分配的16 bit短地址作為該設備的鏈路層地址完成通信鏈接。為了使IPv6地址在物聯(lián)網(wǎng)絡中能夠保證唯一性以及降低底層網(wǎng)絡的通信開銷，本文采用分層地址自動配置策略：首先，在底層網(wǎng)絡內(nèi)部允許節(jié)點使用16 bit短地址導出的鏈路本地地址進行數(shù)據(jù)分組傳輸，該鏈路本地地址需經(jīng)過基于分簇的 DAD保證唯一性；其次，每個底層網(wǎng)絡中的Sink節(jié)點通過上層IP路由器獲取全球單播路由前綴，并與IEEE EUI-64地址計算出的接口標識符(ID)相結(jié)合，形成Sink節(jié)點的全球單播地址，實現(xiàn)底層網(wǎng)絡與互聯(lián)網(wǎng)的數(shù)據(jù)交換。

(1)基于16 bit短地址的鏈路本地地址 通過在物聯(lián)網(wǎng)底層網(wǎng)絡建立邏輯樹結(jié)構(gòu)實現(xiàn)16 bit短地址分配。當?shù)讓泳W(wǎng)絡中的某一節(jié)點允許一個有需求的新節(jié)點加入網(wǎng)絡時，它們之間形成父子關系，每個加入網(wǎng)絡的節(jié)點都會得到父節(jié)點為其分配的用于路由和數(shù)據(jù)傳輸?shù)?6 bit短地址。

Sink節(jié)點首先根據(jù)需要規(guī)定3個參數(shù)：每個父節(jié)點最多可以連接的子節(jié)點個數(shù)Cm，子節(jié)點中最多可以連接的路由節(jié)點個數(shù)Rm，網(wǎng)絡的最大深度Lm，其中Cm≥Rm。Cskip(d)是網(wǎng)絡深度為d的父節(jié)點為其子節(jié)點分配的地址之間的偏移量如式(1)所示。

一個父節(jié)點的Cskip(d)為0時，不具備為其子節(jié)點分配地址的能力，Cskip(d)大于 0 時，則可以接受其它節(jié)點成為它的子節(jié)點，并且向子節(jié)點分配不同的地址。利用 Cskip(d)作為偏移量，向網(wǎng)內(nèi)子節(jié)點分配網(wǎng)絡地址。父節(jié)點為第1個與它連接的路由節(jié)點分配比自己大1的地址，后續(xù)與之連接的節(jié)點的地址之間都相隔偏移量 Cskip(d)，以此類推為所有的節(jié)點分配16 bit短地址。假設父節(jié)點的地址為Aparent，對于它的第n個子節(jié)點，地址分配公式如式(2)所示：

為了避免分配的16 bit短地址在網(wǎng)絡中的重復使用，需要利用 DAD確定地址的唯一性。本文通過分簇方式執(zhí)行DAD，確定地址的唯一性。在網(wǎng)絡建立過程中，以Sink節(jié)點為根節(jié)點建立虛擬邏輯樹結(jié)構(gòu)，其深度L=0。從根節(jié)點開始，已經(jīng)存在的網(wǎng)絡節(jié)點作為后續(xù)加入節(jié)點的父節(jié)點建立分簇，使邏輯樹結(jié)構(gòu)不斷壯大，虛擬邏輯樹結(jié)構(gòu)如圖1所示。通過虛擬邏輯樹結(jié)構(gòu)，待分配節(jié)點只需與本簇內(nèi)的節(jié)點交換信息，減少了 DAD過程中信息交換次數(shù)及網(wǎng)絡通信范圍。

當節(jié)點獲取16 bit短地址并確定唯一性后，通過步驟(a)將其轉(zhuǎn)換為48 bit的標準MAC地址，然后利用該48 bit標準MAC地址再通過步驟(b)得到自動配置的IPv6地址的接口ID：

圖1 DAD虛擬邏輯樹結(jié)構(gòu)

(a)首先最左邊的32 bit利用源節(jié)點的PAN ID和后加入的16 bit零形成，其次該32 bit域與源節(jié)點的16 bit短地址相結(jié)合，形成一個48 bit的標準MAC地址，結(jié)構(gòu)如圖2所示。

圖2 48 bit標準MAC地址

(b)在上述48 bit MAC地址的中間插入一段16 bit的編碼FFFE，轉(zhuǎn)換成IPv6地址的64 bit接口ID，結(jié)構(gòu)如圖3所示。

圖3 16 bit短地址轉(zhuǎn)換格式

當一個新節(jié)點需要加入網(wǎng)絡時，該節(jié)點需要接口標識符以及鏈路本地地址前綴創(chuàng)建一個鏈路本地地址。如圖4所示，假設節(jié)點K的16 bit短地址為ABCD, PAN標識為0014，那么當其與網(wǎng)絡節(jié)點H建立連接后，通過16 bit短地址得到標準的48 bit MAC地址0014：0000：ABCD，通過插入編碼FFFE可得到節(jié)點K的EUI-64地址0214：00FF：FE00：ABCD，即為該節(jié)點的接口標識符。同時，將節(jié)點K的16 bit短地址通過節(jié)點H報告給信標節(jié)點S，信標節(jié)點S將該16 bit短地址加入到路由表中，然后在接口標識符前加上鏈路本地地址前綴FE80：：/64，即得到一個完整的鏈路本地地址FE80：：0214：00FF：FE00：ABCD。

圖4 鏈路本地地址形成過程

(2)基于 IEEE EUI-64地址的全球地址 對于64 bit長地址來說，其64 bit的擴展標識符構(gòu)成了IPv6地址的接口標識符。所以定義64 bit長地址轉(zhuǎn)換為IPv6地址的結(jié)構(gòu)如圖5所示。下面通過Sink節(jié)點接收路由通告的全球地址前綴，結(jié)合 IEEE EUI-64地址轉(zhuǎn)換為接口標識符形成一個全球地址的方式說明整個全球地址自動配置過程。

圖5 64 bit長地址轉(zhuǎn)換格式

如圖6所示，為了生成全球地址，必須要獲取全球路由前綴。Sink節(jié)點S為獲取全球路由前綴，需要向與其相鄰的IP路由節(jié)點P發(fā)出路由請求RS(Router Solicitation)，該RS消息的源地址是Sink節(jié)點S的鏈路本地地址，目的地址是IP路由節(jié)點P的組播地址。IP路由節(jié)點P接收到RS消息后，會向S返回一個路由通告RA(Router Advertisement)，該RA消息的源地址是IP路由節(jié)點P的IPv6地址，目的地址是 Sink節(jié)點S的鏈路本地地址，同時該RA消息的選項字段會給出全球路由前綴。Sink節(jié)點S獲取全球路由前綴后，與接口標識符結(jié)合形成全球IPv6地址。當Sink節(jié)點獲取全球路由前綴后，網(wǎng)內(nèi)節(jié)點可以通過上述方式向Sink節(jié)點發(fā)出請求，Sink節(jié)點再將前綴信息傳遞給網(wǎng)內(nèi)節(jié)點，使網(wǎng)內(nèi)節(jié)點獲取全球地址并接入互聯(lián)網(wǎng)。至此，整個物聯(lián)網(wǎng)底層網(wǎng)絡節(jié)點的地址自動配置過程全部完成，本文將其稱之為物聯(lián)網(wǎng)地址自動配置方案(Internet Of Things Address Autoconfiguration, IOTAA)。

3.2 報頭壓縮

由于HC1和IPHC方案在物聯(lián)網(wǎng)應用中均存在著不足，所以本文在上述兩種方案的基礎上提出一種適用于物聯(lián)網(wǎng)應用的報頭壓縮方案IIPHC。該方案通過在編碼中植入鏈路本地地址和全球地址控制位決定采用報頭壓縮方案的類型。如果地址類型為鏈路本地地址，則采用簡單靈活的 IIPHC1方案，如果地址類型為全球地址，則采用相對復雜但有效的IIPHC2方案。IIPHC壓縮方案的基本報頭結(jié)構(gòu)如圖7所示，標識位和IIPHC編碼位構(gòu)成了IPv6報頭壓縮的基本編碼格式。

圖6 路由請求及路由通告

圖7 IIPHC基本報頭結(jié)構(gòu)

(1)IIPHC1方案 通過在標識位中植入GL位對地址類型進行判斷，當?shù)刂奉愋蜑殒溌繁镜氐刂窌r，執(zhí)行 IIPHC1壓縮方案，具體編碼格式如圖 8所示。

圖8 IIPHC1編碼格式

字段含義如下：

(a)0110：表示地址類型為 IPv6地址，與 GL位共同標識需要壓縮的地址類型。

(b)GL(Global/Local)：全球/鏈路本地地址標識位。本方案中 GL=1，表示地址類型為鏈路本地地址。

(c)TF(Traffic Class/Flow Label)：業(yè)務流類別及流標簽壓縮位。由于8 bit的IPv6業(yè)務流類別字段由2 bit的ECN(Explicit Congestion Notification)字段和6 bit的DSCP(Differentiated Services Code Point)字段組成，所以將TF的編碼作如下定義：

00：業(yè)務流類別和流標簽保持默認值；

01：ECN和流標簽保持默認值，DSCP省略；

10：業(yè)務流類別保持默認值，流標簽省略；

11：業(yè)務流類別和流標簽均省略。

(d)SA(Source Address)：源地址壓縮位。

00：地址前綴和接口標識符均不壓縮；

01：地址前綴不壓縮，接口標識符壓縮；

10：地址前綴壓縮，接口標識符不壓縮；

11：地址前綴和接口標識符均壓縮。

(e)DA(Destination Addresses)：目的地址壓縮位。

00：地址前綴和接口標識符均不壓縮；

01：地址前綴不壓縮，接口標識符壓縮；

10：地址前綴壓縮，接口標識符不壓縮；

11：地址前綴和接口標識符均壓縮。

(f)NH(Next Head)：下一報頭壓縮位。

0：8 bit下一報頭字段不壓縮；

1：8 bit下一報頭字段壓縮，并且采用相關的下一報頭壓縮算法；

(g)HL(Hop Limit)：跳極限壓縮位。

0：跳極限字段不壓縮；

1：跳極限字段壓縮并且跳極限的最大值為64。

(2) IIPHC2方案 鏈路本地地址的傳播范圍具有一定的局限性，而全球地址需要更大范圍的消息轉(zhuǎn)發(fā)才能獲取全球路由前綴，因此其報頭壓縮方案必須更加靈活有效，這樣才能在降低報頭開銷的同時，保證地址信息的完備性?；诖耍?shù)刂奉愋蜑槿虻刂窌r，本文放棄了IPHC中的有狀態(tài)壓縮模式，整個壓縮過程無論源地址、目的地址還是中繼節(jié)點的地址都通過無狀態(tài)壓縮的方法進行壓縮，因為這樣更符合物聯(lián)網(wǎng)底層網(wǎng)絡的實際應用環(huán)境，降低了報頭壓縮和地址自動配置的設計復雜性。IIPHC2具體編碼格式如圖9所示。

圖9 IIPHC2編碼格式

IIPHC2編碼格式的部分字段含義與IIPHC1方案中的相同。因此，現(xiàn)將IIPHC2中區(qū)別于IIPHC1的字段含義描述如下：

(a)GL(Global/Local)：全球/鏈路本地地址標識位。本方案中GL=0，表示地址類型為全球地址。

(b)HL(Hop Limit)：跳極限壓縮位。

00：跳極限字段不壓縮；

01：跳極限字段壓縮并且跳極限的最大值為1;

10：跳極限字段壓縮并且跳極限的最大值為64;

11：跳極限字段壓縮并且跳極限的最大值為255。

(c)SMID(Shared Message IDentifier)：共享消息標識壓縮位。為了可以充分利用物聯(lián)網(wǎng)絡中大量的共享消息資源，在共享消息的幫助下獲取相關信息，壓縮冗余報頭結(jié)構(gòu)，本文在 IIPHC2中引入了SMID編碼位。

00：源地址鄰居消息共享。在同一個虛擬簇下通過鄰居消息獲取源地址前綴；

01：目的地址鄰居消息共享。在同一個虛擬簇下通過鄰居消息獲取目的地址前綴；

10：源地址路由消息共享。利用鏈路封裝報頭獲取源地址接口標識符；

11：目的地址路由消息共享。利用鏈路封裝報頭獲取目的地址接口標識符。

(d)SAM(Source Address Mode)：源地址模式壓縮位。

00：源地址不壓縮，長度為128 bit；

01：壓縮源地址前綴，剩余長度為64 bit；

10：壓縮源地址前綴及部分接口標識符，僅保留16 bit短地址，剩余長度為16 bit；

11：源地址完全省略，相關地址信息完全由共享消息計算得出，剩余長度為0 bit。

(e)M(Multicast)：目的地址類型標識位。0：目的地址是單播地址；1：目的地址是組播地址。

(f)DAM(Destination Address Mode)：目的地址模式壓縮位。當M=0時，DAM與SAM的編碼方式相同，當M=1時，壓縮字段含義如下：

00：目的地址不壓縮，長度為128 bit；

01：依據(jù)組標識符的范圍，目的地址壓縮長度為48 bit；

10：依據(jù)組標識符的范圍，目的地址壓縮長度為32 bit；

11：依據(jù)組標識符的范圍，目的地址壓縮長度為8 bit。

4 仿真及測試

通過C++編譯6LoWPAN模塊，并將其嵌入到OMNeT++仿真軟件的Mobility Framework(MF)模塊中，MF模塊包含IEEE 802.15.4協(xié)議，仿真最大數(shù)據(jù)報大小為90 byte，網(wǎng)絡范圍為40 m×40 m，數(shù)據(jù)流類型為CBR，仿真時間為30 min。

(1)地址自動配置仿真實驗 通過網(wǎng)絡開銷和時間延遲兩個性能指標來驗證 IOTAA方案的有效性。

對于網(wǎng)絡開銷而言，在仿真平臺上對 IOTAA,CCAA[10]和Strong DAD[13]進行仿真實驗。本文所采用的網(wǎng)絡開銷衡量標準并不是執(zhí)行該方案時系統(tǒng)消耗了多少能量，而是通過隨著節(jié)點數(shù)的增加，執(zhí)行該方案所產(chǎn)生的消息包數(shù)量來衡量的。圖10比較了3種方案的網(wǎng)絡開銷：Strong DAD方案中，當?shù)讓泳W(wǎng)絡節(jié)點數(shù)量增加時，每個節(jié)點隨機選取地址發(fā)生沖突的概率也隨之增加，需要通過更多的消息包轉(zhuǎn)發(fā)來緩解地址沖突帶來的影響，所以其產(chǎn)生的消息包數(shù)量成指數(shù)增長；CCAA方案由于利用三原色坐標和節(jié)點位置信息實現(xiàn) IPv6地址自動配置，同Strong DAD方案相比取得了很大程度的改進；而IOTAA在60個節(jié)點的情況下所產(chǎn)生的消息包數(shù)量在200個以內(nèi)，一方面是因為在IOTAA的重復地址檢測過程中采用虛擬的邏輯樹結(jié)構(gòu)減少了鄰居請求消息的轉(zhuǎn)發(fā)范圍，另一方面是因為整個網(wǎng)絡中并不是所有網(wǎng)絡節(jié)點都需要獲得 IPv6全球路由前綴進行數(shù)據(jù)轉(zhuǎn)發(fā)和通信，所以取得了優(yōu)于Strong DAD和CCAA的良好效果。

對于時間延遲，本文采用隨著節(jié)點數(shù)的增加，不同數(shù)量網(wǎng)內(nèi)節(jié)點在仿真平臺上執(zhí)行 3次 IOTAA方案所需要的平均時間來衡量。如圖11所示，縱坐標表示執(zhí)行該方案所產(chǎn)生的時間間隔(設定1個時間間隔的大小為100 ms)，執(zhí)行IOTAA方案最多需要消耗1.8 s的時間，最少僅需要幾百毫秒，而傳統(tǒng)地址自動配置方案至少需要 3 s以上的時間延遲才能完成，因此，IOTAA方案在時間延遲方面取得了約1 s的改進，提高了底層網(wǎng)絡的時間同步精度。

(2)報頭壓縮仿真實驗 利用系統(tǒng)吞吐量和RTT(Round-Trip Time)兩個性能指標來驗證IIPHC方案的有效性。

在系統(tǒng)吞吐量方面，將本文提出的IIPHC方案與HC1方案和IPHC方案進行了對比。圖12顯示了隨著數(shù)據(jù)負載的增加，3種壓縮方案的系統(tǒng)平均吞吐量。由圖12可以看出，因為IIPHC方案通過判別壓縮地址類型采用混合的報頭壓縮方案，所以經(jīng)過IIPHC方案壓縮后的數(shù)據(jù)負載同HC1和IPHC方案相比，在吞吐量方面取得了約 30%～60%的改進，這也正是IIPHC壓縮方案的重要優(yōu)勢之一。

圖10 地址自動配置網(wǎng)絡開銷

圖11 地址自動配置時間延遲

圖12 報頭壓縮吞吐量比較

在RTT方面，通過與HC1和IPHC進行比較，驗證了IIPHC方案在往返延遲時間上的有效性。由表1可以看出，IIPHC在平均往返延遲時間和標準偏差方面所用的時間更少。相對于HC1和IPHC來說，執(zhí)行IIPHC方案需要的RTT分別降低了約50%和25%，這樣的仿真結(jié)果證明了執(zhí)行IIPHC方案節(jié)省了節(jié)點存儲空間、降低了系統(tǒng)網(wǎng)絡開銷，與此同時，反映了吞吐量性能指標提升的正確性。

(3)尋址策略能量消耗仿真實驗 通過將本文提出的尋址策略IOTAA+IIPHC與另外兩種組合的尋址策略Strong DAD+HC1和CCAA+IPHC進行對比仿真實驗，驗證了本文提出的尋址策略在節(jié)點傳輸IPv6分組過程中的能量有效性。由圖13可以看出，隨著數(shù)據(jù)負載字節(jié)數(shù)的不斷增加，本文提出的尋址策略能量消耗呈線性增長，但是其始終維持在 1 0-1mJ 的量級上，即使傳輸負載達到最大 90 byte，能量消耗依然會保持在 1 mJ以內(nèi)。而StrongDAD+HC1和CCAA+IPHC尋址策略隨著數(shù)據(jù)負載的增加，能量消耗明顯高于本文提出的尋址策略，因此改進的尋址策略降低了網(wǎng)絡能量消耗，為物聯(lián)網(wǎng)底層網(wǎng)絡的大規(guī)模應用奠定了能量基礎。

表1 RTT對比數(shù)據(jù)(s)

圖13 尋址策略能量比較

5 結(jié)束語

本文在6LoWPAN的基礎上，分析了IPv6地址應用于未來物聯(lián)網(wǎng)存在的技術挑戰(zhàn)，提出了適用于底層網(wǎng)絡向物聯(lián)網(wǎng)擴展的尋址策略。物聯(lián)網(wǎng)尋址最重要的兩個方面是實現(xiàn)底層網(wǎng)絡節(jié)點 IPv6地址的自動配置以及地址的報頭壓縮，本文針對這兩個方面給出了有效的解決方案，使網(wǎng)絡層向上對傳輸層提供簡單靈活、無連接、盡最大努力交付的可靠分組服務，使 MAC層向下不必考慮物理層如何實現(xiàn)位傳輸?shù)募毠?jié)。通過仿真實驗證明該尋址策略對于未來物聯(lián)網(wǎng)應用具有有效融合異構(gòu)網(wǎng)絡、降低系統(tǒng)能耗、增加網(wǎng)絡吞吐量以及保證系統(tǒng)實時性等特點。但是，物聯(lián)網(wǎng)的大規(guī)模應用還存在許多不確定因素，相關技術環(huán)節(jié)有待突破。在上述工作的基礎上，下一步工作目標主要集中在物聯(lián)網(wǎng)絡時間同步以及泛在網(wǎng)絡協(xié)議研究。

[1]Welbourne E, Battle L, Cole G,et al.. Building the internet of things using RFID: the RFID ecosystem experience[J].IEEE Internet Computing, 2009, 13(3): 48-55.

[2]王雪, 錢志鴻, 胡正超, 等. 基于二叉樹的 RFID 防碰撞算法的研究[J]. 通信學報, 2010, 31(6): 49-57.

Wang Xue, Qian Zhi-hong, Hu Zheng-chao,et al.. Research on RFID anti-collision algorithms based on binary tree[J].Journal on Communications, 2010, 31(6): 49-57.

[3]Wu Miao, Lu Ting-jie, Ling Fei-yang,et al.. Research on the architecture of Internet of Things[C]. Proceedings of 2010 third International Conference on Advanced Computer Theory and Engineering, Chengdu, China, Aug. 20-22, 2010,5: 484-487.

[4]錢志鴻, 郭雨齊, 侯金鳳, 等. 基于信道轉(zhuǎn)換的藍牙微微網(wǎng)之間同頻干擾抑制方法[J]. 電子與信息學報, 2011, 33(12):2995-3001.

Qian Zhi-hong, Guo Yu-qi, Hou Jin-feng,et al.. Co-channel interference suppression method based on channel switching for Bluetooth piconets[J].Journal of Electronics&Information Technology, 2011, 33(12): 2995-3001.

[5]Evdokimov S, Fabian B, Kunz S,et al.. Comparison of discovery service architectures for the Internet of Things[C].SUTC 2010 IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing, UMC 2010 IEEE International Workshop on Ubiquitous and Mobile Computing, Hyatt Regency Newport Beach,California, USA, June 7, 2010: 237-244.

[6]朱洪波, 楊龍祥, 于全. 物聯(lián)網(wǎng)的技術思想與應用策略研究[J].通信學報, 2010, 31(6): 2-9.

Zhu Hong-bo, Yang Long-xiang, and Yu Quan. Investigation of Technical thought and application strategy for the Internet of Things[J].Journal on Communications, 2010,31(6): 2-9.

[7]張福生. 物聯(lián)網(wǎng)——開啟全新生活的智能時代[M]. 山西 : 山西人民出版社, 2010: 119-174.

Zhang Fu-sheng. Internet of Things.1[M]. Shanxi: Shanxi People’s Press, 2010: 119-174.

[8]Mazzer Y and Tourancheau B. Comparisons of 6LoWPAN Implementations on Wireless Sensor Networks[C]. 2009 Third International Conference on Sensor Technologies and Applications, Athens/Glyfada, Greece, June 18-23, 2009:689-692.

[9]Jara A J, Zamora M A, and Skarmeta A F G. An architecture based on Internet of Things to support mobility and security in medical environments[C]. 2010 Seventh IEEE Consumer Communications and Networking Conference, Las Vegas,Nevada, USA, Jan 9-12, 2010: 1-5.

[10]Shin H, Tlipov E, and Hojung C. IPv6 lightweight stateless address autoconfiguration for 6LoWPAN using color coordinators[C]. Proceedings of the 2009 IEEE International Conference on Pervasive Computing and Communications,Washington, USA, 2009: 1-9.

[11]Montenegro G, Kushalnagar N, and Hui J. Transmission of IPv6 packets over IEEE802.15.4 networks[S]. IETF RFC 4944, 2007.

[12]Hui J and Thubert P. Compression format for IPv6 datagrams over IEEE 802.15.4-based networks[S]. IETF RFC 6282, 2011.

[13]Perkins C, Malinen J, Wakikawa R,et al.. IP address autoconfiguration for Ad hoc networks[S]. IETF draft, 2001.