基于6LOWPAN的智能家居控制系統(tǒng)設(shè)計

畢業(yè)設(shè)計基于6LOWPAN的智能家居控制系統(tǒng)設(shè)計學生姓名學號專業(yè)班級指導教師學院答辯日期基于6LOWPAN的智能家居控制系統(tǒng)設(shè)計TheDesignofControlSystemBasedon6LOWPANforSmartHome緒論隨著物聯(lián)網(wǎng)技術(shù)的日益成熟，物聯(lián)網(wǎng)技術(shù)在民生、農(nóng)業(yè)、經(jīng)濟等方面正在發(fā)揮不容忽視的作用。在日常生活中，已經(jīng)有許多物聯(lián)網(wǎng)技術(shù)帶來的細微變化正在人們的身邊發(fā)生?，F(xiàn)在發(fā)展相對比較成熟的，就是汽車移動物聯(lián)網(wǎng)（車聯(lián)網(wǎng)），通過在車輛上安裝各式各樣的傳感器，如紅外感應器、射頻識別、全球定位系統(tǒng)等信息傳感設(shè)備，然后通過無線通信技術(shù)，將采集的各種信息上傳到互聯(lián)網(wǎng)上，進而實現(xiàn)車輛的駕駛?cè)藛T感應、識別、定位等功能，便于統(tǒng)一監(jiān)控和管理。例如現(xiàn)在很多地圖導航應用可以顯示實時路況，就是通過安裝在出租車上的傳感器實現(xiàn)的，通過分析在該路段所有出租車的行車狀況，以此給出路況參照。在物聯(lián)網(wǎng)領(lǐng)域另一個更有發(fā)展?jié)撡|(zhì)的就是智能家居，現(xiàn)在智能家居在人們家庭住宅的應用還很少，但是住宅是每個人家的基礎(chǔ)，一個人一天至少有一半以上的時間在家中度過，如果能夠在生活起居各個方面方便人們的居家生活，智能家居必將具有更大的發(fā)展空間。國家也很重視物聯(lián)網(wǎng)及其在智能家居行業(yè)的發(fā)展與應用，民生才是一個國家的根本，如果一個國家人民的生活水平、生活質(zhì)量提高了，才能真正意味著這個國家的工業(yè)化和信息化水平的提高，在這個大背景下，由國家工業(yè)和信息化部在即將迎來2012之時提出了《物聯(lián)網(wǎng)“十二五”發(fā)展規(guī)劃》，該規(guī)劃中明確將智能家居作為提升民生水平的物聯(lián)網(wǎng)應用作為重點發(fā)展和照顧對象，加以大力支持并力求在未來內(nèi)通過高新技術(shù)手段和創(chuàng)新技術(shù)手段近一步提高人民的生活。盡管在物聯(lián)網(wǎng)技術(shù)的推動下智能家居行業(yè)呈現(xiàn)良好的發(fā)展態(tài)勢，但是這個新興行業(yè)在國內(nèi)經(jīng)過大概10年的發(fā)展，非但沒有進入繁榮期，市場反而一直處于低迷期，基本上沒有取得突破性的發(fā)展。究其原因，主要還是一下3點，行業(yè)標準不統(tǒng)一、系統(tǒng)價格不親民、產(chǎn)品不夠人性化。很多問題顯而易見，但是又得不到太好的解決辦法。1）智能家居行業(yè)還比較混亂，行業(yè)的各個廠家標準和協(xié)議不統(tǒng)一，各自為營，行業(yè)陷入無序發(fā)展，使得彼此之間的產(chǎn)品無法兼容。如果用戶的智能家居系統(tǒng)出現(xiàn)問題，需更換配件時，只能選擇同品牌提供的產(chǎn)品，否則整個系統(tǒng)就得拆掉。這不僅造成巨大的浪費，還在很大程度限制了智能家居的發(fā)展。2）目前智能家居系統(tǒng)的產(chǎn)品價格偏高，只有部分人群能夠消費起，配備智能家居系統(tǒng)的樓盤大多更是天價級別的樓盤。無法進入普通百姓家也就意味著無法將智能家居推廣，如果能夠做到像現(xiàn)在智能手機的普及程度，才認為這個世界進入了智能家居時代。3）智能家居不夠人性化，用戶體驗不夠好，作為一款新興的技術(shù)產(chǎn)品，如果操作系統(tǒng)缺乏人性化設(shè)計，最大優(yōu)化用戶體驗，會使得用戶望而生畏。智能家居的使用場合一般是家庭環(huán)境，家中如果有老人、小孩，就需要系統(tǒng)能夠?qū)崿F(xiàn)通過簡單的操作，達到快捷、便利的效果。但遺憾的是，現(xiàn)在雖然很多智能家居產(chǎn)品功能很多，但是在人性化設(shè)計、用戶體驗方面不完善，使得智能家居系統(tǒng)陷入了一種中看不中用的地步。針對智能家居領(lǐng)域出現(xiàn)的各種問題，如何協(xié)調(diào)解決好這些問題，成為帶領(lǐng)智能家居行業(yè)走出現(xiàn)在這個窘境、實現(xiàn)大步發(fā)展的關(guān)鍵所在。因此，只有選擇一條符合國情、屬于中國發(fā)展模式的道路，才能改變目前的狀態(tài)。因此要想讓智能家居的理念深入人心，首先得讓人們切實的體驗到智能家居所帶來的便捷生活，讓越來越多的人都想要一套智能家居系統(tǒng)。曾經(jīng)有人做過一個行業(yè)的調(diào)查，幾乎所有人都有使用智能家居的美好愿望，但是在問及是否會安裝智能家居系統(tǒng)時，大多數(shù)人總會以價格太高或房子已裝修完為由，拒絕安裝，其實在他們心底，真正的原因是還沒有形成這樣的理念——“智能家居跟電視、冰箱、洗衣機和手機是一樣一樣的，都屬于生活必需品”?；谝陨?點考慮，選擇一個適合智能家居系統(tǒng)的標準協(xié)議，降低系統(tǒng)產(chǎn)品價格，最大優(yōu)化產(chǎn)品用戶體驗，成為一條必經(jīng)之路。目前智能家居系統(tǒng)大多數(shù)是使用Zigbee技術(shù)作為數(shù)據(jù)傳輸協(xié)議。Zigbee是為技術(shù)人員熟知的基于IEEE802.15.4標準的低功耗個域網(wǎng)協(xié)議，該協(xié)議作為無線傳感器網(wǎng)絡(luò)的主流協(xié)議在智能家居領(lǐng)域得到廣泛應用。早期時候，智能家居系統(tǒng)通過增加GSM模塊發(fā)送、接收短信來實現(xiàn)與用戶的遠程交互，現(xiàn)如今多數(shù)智能家居系統(tǒng)都能接入互聯(lián)網(wǎng)，但是基本都是建立在IPv4網(wǎng)絡(luò)基礎(chǔ)上，實現(xiàn)與用戶的遠程交互。這樣做的局限性很明顯：IPv4的32位地址總?cè)萘考s為43億個，然而在2012年之時IP地址就已經(jīng)分配完畢，因為IPv4在設(shè)計之初只考慮到為全球的主機分配IP地址，如果要為全球各家各戶的家電設(shè)備、監(jiān)測傳感器分配一個唯一IP地址，幾乎是不可能的，即不可能實現(xiàn)IPanywhere。隨著技術(shù)的發(fā)展，IPv6的提出很好地解決了地址資源枯竭的問題，有人曾經(jīng)做過一個很貼切的對比來形容IPv6地址的豐富：“IPv6的地址數(shù)量，比地球所有沙子數(shù)量的總和還要來得多得多”。IPv6的提出使IPanywhere成為一種可能，這似乎也成為了解決智能家居所面臨瓶頸的關(guān)鍵所在，但是IPv6的許多其他功能對于智能家居系統(tǒng)來說太過復雜、或者冗余，而且智能家居系統(tǒng)需要在嵌入式設(shè)備上實現(xiàn)，也就是說在硬件條件受限的情況下，如何實現(xiàn)嵌入式設(shè)備的IPv6化，便是主要問題。IETF（InternetEngineeringTaskForce）為了解決這個燃眉之急，在2004的年末成立了6LOWPAN工作組，該小組的主要任務(wù)就是解決上面提到過的“如何在IEEE802.15.4網(wǎng)絡(luò)的基礎(chǔ)上進行并實現(xiàn)IPv6數(shù)據(jù)報文的傳輸”的問題。到目前為止，該小組已經(jīng)進行許多研究并形成草案予以發(fā)布，例如在草案RFC4944中就提出了6LOWPAN適配層的概念來解決一些關(guān)鍵性的技術(shù)問題。本設(shè)計將現(xiàn)有的6LOWPAN技術(shù)應用到智能家居系統(tǒng)上，能有效解決IP地址枯竭的問題。在現(xiàn)階段一個基于6LOWPAN技術(shù)的智能家居系統(tǒng)極為少見，能夠為行業(yè)提供一個應用范例。另一方面，為了降低成本，需要最大限度的把用戶自有的設(shè)備終端納入智能家居系統(tǒng)，如智能手機、路由器等。并且使用市面上已經(jīng)成熟的嵌入式設(shè)備、無線傳感器網(wǎng)絡(luò)節(jié)點以及各式傳感器來開發(fā)智能家居系統(tǒng)。此外，在用戶住宅中安裝智能家居系統(tǒng)時，應充分考慮用戶家庭的布線情況，在盡可能減少二次裝修的前提下，完成智能家居系統(tǒng)的安裝。最后，近年來，隨著B/S結(jié)構(gòu)的興起，即Browser/Server（瀏覽器/服務(wù)器）網(wǎng)絡(luò)結(jié)構(gòu)模式，WEB瀏覽器成為客戶端最主要的應用軟件。相比對C/S結(jié)構(gòu)，即Client/Server（客戶端/服務(wù)器）網(wǎng)絡(luò)結(jié)構(gòu)模式，B/S最大的優(yōu)點就是，訪問互聯(lián)網(wǎng)上任何數(shù)據(jù)，如文本、圖像、聲音、視頻等，都可以通過瀏覽器來完成，而不需要另外安裝軟件。在對當前行業(yè)背景進行上述分析后，本設(shè)計考慮遵照6LOWPAN協(xié)議標準，擬充分應用嵌入式硬件和客戶端來進行設(shè)計，并實現(xiàn)一種采用B/S結(jié)構(gòu)的智能家居系統(tǒng)，這樣可以分別對應解決協(xié)議不規(guī)范、系統(tǒng)成本高昂及用戶體驗不友好等問題。但是由于技術(shù)水平所限，本設(shè)計只是在Contiki操作系統(tǒng)下的Cooja模擬器上實現(xiàn)了由RPL路由協(xié)議下的傳感器網(wǎng)絡(luò)的組網(wǎng)并實現(xiàn)遠程控制。

6LOWPAN協(xié)議6LOWPAN技術(shù)背景6LOWPAN是一種基于IPv6的低速無線個域網(wǎng)標準，即IPv6overIEEE802.15.4。將IP協(xié)議引入無線通信網(wǎng)絡(luò)一直被認為是不現(xiàn)實的(不是完全不可能)。迄今為止，無線網(wǎng)只采用專用協(xié)議，因為IP協(xié)議對內(nèi)存和帶寬要求較高，要降低它的運行環(huán)境要求以適應微控制器及低功率無線連接很困難。基于IEEE802.15.4實現(xiàn)IPv6通信的IETF6LOWPAN草案標準的發(fā)布有望改變這一局面。6LOWPAN所具有的低功率運行的潛力使它很適合應用在從手持機到儀器的設(shè)備中，而其對AES-128加密的內(nèi)置支持為強健的認證和安全性打下了基礎(chǔ)。IEEE802.15.4標準設(shè)計用于開發(fā)可以靠電池運行1到5年的緊湊型低功率廉價嵌入式設(shè)備(如傳感器)。該標準使用工作在2.4GHz頻段的無線電收發(fā)器傳送信息，使用的頻帶與Wi-Fi相同，但其射頻發(fā)射功率大約只有Wi-Fi的1%。這限制了IEEE802.15.4設(shè)備的傳輸距離，因此，多臺設(shè)備必須一起工作才能在更長的距離上逐跳傳送信息和繞過障礙物。IETF6LOWPAN工作組的任務(wù)是定義在如何利用IEEE802.15.4鏈路支持基于IP的通信的同時，遵守開放標準以及保證與其他IP設(shè)備的互操作性。這樣做將消除對多種復雜網(wǎng)關(guān)(每種網(wǎng)關(guān)對應一種本地802.15.4協(xié)議)以及專用適配器和網(wǎng)關(guān)專有安全與管理程序的需要。然而，利用IP并不是件容易的事情：IP的地址和包頭很大，傳送的數(shù)據(jù)可能過于龐大而無法容納在很小的IEEE802.15.4數(shù)據(jù)包中。6LOWPAN工作組面臨的技術(shù)挑戰(zhàn)是發(fā)明一種將IP包頭壓縮到只傳送必要內(nèi)容的小數(shù)據(jù)包中的方法。他們的答案是“Payasyougo”式的包頭壓縮方法。這些方法去除IP包頭中的冗余或不必要的網(wǎng)絡(luò)級信息。IP包頭在接收時從鏈路級802.15.4包頭的相關(guān)域中得到這些網(wǎng)絡(luò)級信息。最簡單的使用情況是一臺與鄰近802.15.4設(shè)備通信的802.15.4設(shè)備將非常高效率地得到處理。整個40字節(jié)IPv6包頭被縮減為1個包頭壓縮字節(jié)(HC1)和1字節(jié)的“剩余跳數(shù)”。因為源和目的IP地址可以由鏈路級64位唯一ID(EUI-64)或802.15.4中使用的16位短地址生成。8字節(jié)用戶數(shù)據(jù)報協(xié)議傳輸包頭被壓縮為4字節(jié)。隨著通信任務(wù)變得更加復雜，6LOWPAN也相應調(diào)整。為了與嵌入式網(wǎng)絡(luò)之外的設(shè)備通信，6LOWPAN增加了更大的IP地址。當交換的數(shù)據(jù)量小到可以放到基本包中時，可以在沒有開銷的情況下打包傳送。對于大型傳輸，6LOWPAN增加分段包頭來跟蹤信息如何被拆分到不同段中。如果單一跳802.15.4就可以將包傳送到目的地，數(shù)據(jù)包可以在不增加開銷地情況下傳送。多跳則需要加入網(wǎng)狀路由(mesh-routing)包頭。IETF6LOWPAN取得的突破是得到一種非常緊湊、高效的IP實現(xiàn)，消除了以前造成各種專門標準和專有協(xié)議的因素。這在工業(yè)協(xié)議（BACNet、LonWorks、通用工業(yè)協(xié)議和監(jiān)控與數(shù)據(jù)采集）領(lǐng)域具有特別的價值。這些協(xié)議最初開發(fā)是為了提供特殊的行業(yè)特有的總線和鏈路(從控制器區(qū)域網(wǎng)總線到AC電源線)上的互操作性。幾年前，這些協(xié)議的開發(fā)人員開發(fā)IP選擇是為了實現(xiàn)利用以太網(wǎng)等“現(xiàn)代”技術(shù)。6LOWPAN的出現(xiàn)使這些老協(xié)議把它們的IP選擇擴展到新的鏈路(如802.15.4)。因此，自然而然地可與專為802.15.4設(shè)計的新協(xié)議(如ZigBee和ISA100.11a)互操作。受益于此，各類低功率無線設(shè)備能夠加入IP家庭中，與Wi-Fi、以太網(wǎng)以及其他類型的設(shè)備“稱兄道弟”。隨著IPv4地址的耗盡，IPv6是大勢所趨。物聯(lián)網(wǎng)技術(shù)的發(fā)展，將進一步推動IPv6的部署與應用。IETF6LOWPAN技術(shù)具有無線低功耗、自組織網(wǎng)絡(luò)的特點，是物聯(lián)網(wǎng)感知層、無線傳感器網(wǎng)絡(luò)的重要技術(shù)，ZigBee新一代智能電網(wǎng)標準中SEP2.0已經(jīng)采用6LOWPAN技術(shù)，隨著美國智能電網(wǎng)的部署，6LOWPAN將成為事實標準，全面替代ZigBee標準。6LOWPAN技術(shù)優(yōu)勢普及性：IP網(wǎng)絡(luò)應用廣泛，作為下一代互聯(lián)網(wǎng)核心技術(shù)的IPv6，也在加速其普及的步伐，在低速無線個域網(wǎng)中使用IPv6更易于被接受。適用性：IP網(wǎng)絡(luò)協(xié)議棧架構(gòu)受到廣泛的認可，低速無線個域網(wǎng)完全可以基于此架構(gòu)進行簡單、有效地開發(fā)。更多地址空間：IPv6應用于低速無線個域網(wǎng)時，最大亮點就是龐大的地址空間。這恰恰滿足了部署大規(guī)模、高密度低速無線個域網(wǎng)設(shè)備的需要。支持無狀態(tài)自動地址配置：IPv6中當節(jié)點啟動時，可以自動讀取MAC地址，并根據(jù)相關(guān)規(guī)則配置好所需的IPv6地址。這個特性對傳感器網(wǎng)絡(luò)來說，非常具有吸引力，因為在大多數(shù)情況下，不可能對傳感器節(jié)點配置用戶界面，節(jié)點必須具備自動配置功能。易接入：低速無線個域網(wǎng)使用IPv6技術(shù)，更易于接入其他基于IP技術(shù)的網(wǎng)絡(luò)及下一代互聯(lián)網(wǎng)，使其可以充分利用IP網(wǎng)絡(luò)的技術(shù)進行發(fā)展。易開發(fā)：目前基于IPv6的許多技術(shù)已比較成熟，并被廣泛接受，針對低速無線個域網(wǎng)的特性對這些技術(shù)進行適當?shù)木喓腿∩?，可以簡化協(xié)議開發(fā)的過程。6LOWPAN關(guān)鍵技術(shù)分析對于IPv6和IEEE805.15.4結(jié)合的關(guān)鍵技術(shù)，6LOWPAN工作組進行了積極的研究與討論，目前在IEEE802.15.4上實現(xiàn)傳輸IPv6數(shù)據(jù)包的關(guān)鍵技術(shù)如下：1）IPv6和IEEE802.15.4的協(xié)調(diào)。IEEE802.15.4標準定義的最大幀長度是127字節(jié)．MAC頭部最大長度為25字節(jié)，剩余的MAC載荷最大長度為102字節(jié)。如果使用安全模式，不同的安全算法占用不同的字節(jié)數(shù)，比如AES-CCM-128需要21字節(jié)，AES-CCM-64需要13字節(jié)，而AES-CCM-32需要8字節(jié)。這樣留給MAC載荷最少只有81個字節(jié)。而在IPv6中。MAC載荷最大為1280字節(jié)。IEEE802.15.4幀不能封裝完整的IPv6數(shù)據(jù)包。因此，要協(xié)調(diào)二者之間的關(guān)系，就要在網(wǎng)絡(luò)層與MAC層之間引入適配層，用來完成分片和重組的功能。2）地址配置和地址管理。IPv6支持無狀態(tài)地址自動配置，相對于有狀態(tài)自動配置的來說，配置所需開銷比較小，這正適合LR-WPAN設(shè)備特點。同時，由于LR-WPAN設(shè)備可能大量、密集地分布在人員比較難以到達的地方，實現(xiàn)無狀態(tài)地址自動配置則更加重要。3）網(wǎng)絡(luò)管理。網(wǎng)絡(luò)管理技術(shù)對LR-WPAN網(wǎng)絡(luò)很關(guān)鍵。由于網(wǎng)絡(luò)規(guī)模大，而一些設(shè)備的分布地點又是人員所不能到達的，因此LR-WPAN網(wǎng)絡(luò)應該具有自愈能力，要求LR-WPAN的網(wǎng)絡(luò)管理技術(shù)能夠在很低的開銷下管理高度密集分布的設(shè)備。由于在IEEE802.15.4上轉(zhuǎn)發(fā)IPv6數(shù)據(jù)提倡盡量使用已有的協(xié)議，而簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）又為lP網(wǎng)絡(luò)提供了一套很好的網(wǎng)絡(luò)管理框架和實現(xiàn)方法，因此，6LOWPAN傾向于在LR-WPAN上使用SNMPv3進行網(wǎng)絡(luò)管理。但是，由于SNMP的初衷是管理基于IP的互聯(lián)網(wǎng)，要想將其應用到硬件資源受限的LR-WPAN網(wǎng)絡(luò)中。仍需要進一步調(diào)研和改進。例如：限制數(shù)據(jù)類型、簡化基本的編碼規(guī)則等。4）安全問題。由于使用安全機制需要額外的處理和帶寬資源，并不適合LR-WPAN設(shè)備，而IEEE802.15.4在鏈路層提供的AES安全機制又相對寬松，有待進一步加強，因此尋找一種適合LR-WPAN的安全機制就成為6LOWPAN研究的關(guān)鍵問題之一。作為當今信息領(lǐng)域新的研究熱點，6LOWPAN還有非常多的關(guān)鍵技術(shù)有待發(fā)現(xiàn)和研究，比如：服務(wù)發(fā)現(xiàn)技術(shù)、設(shè)備發(fā)現(xiàn)技術(shù)、應用編程接口技術(shù)、數(shù)據(jù)融合技術(shù)等。6LOWPAN技術(shù)概述為了實現(xiàn)屏蔽底層硬件對IPv6網(wǎng)絡(luò)層的限制，在他們之間加入了適配層，同時也實現(xiàn)了IPv6網(wǎng)絡(luò)層與IEEE802.15.4MAC層之間的連接通信。在6LOWPAN的技術(shù)中最重要的就是適配層的技術(shù)，它使整個協(xié)議棧有序的工作。適配層報文格式6LOWPAN網(wǎng)絡(luò)有報文長度小、帶寬低、功耗低等的原因，為了縮短報文的長度，適配層幀頭部采用兩種格式，即分片（用來傳輸數(shù)據(jù)部分小于MAC層最大傳輸單元MTU(102字節(jié))的報文）以及不分片（用來傳輸數(shù)據(jù)部分大于MAC層MTU的報文）的格式。當在IEEE802.15.4鏈路上傳輸IPv6報文時，IPv6報文被封裝在這兩種不同格式的適配層報文中，即在適配層頭部的后邊跟隨的是IPV6報文作為適配層的負載。特殊地，如果把“M”或“B”bit位置為1時，MD或Broadcast字段會首先出現(xiàn)在適配層頭部的后面，出現(xiàn)在這兩個字段之后的就是IPv6的數(shù)據(jù)報文。不分片的報文格式：圖2.1不分片的報文格式其各個字段的含義如下：LF：(LinkFragment)鏈路分片。為2bit，在不分片格式中該位為00。Prot-type：協(xié)議類型。為8bit，表示在報文頭部的報文類型。M：(MeshDelivery)字段標志位。為1bit，如果該位置為1，則適配層頭部后為“MeshDelivery”字段。B：(Broadcast)為1bit，如果該位置為1，則適配層頭部后為“Broadcast”字段。rsv：(reservation)保留字段，全置為0。分片報文格式若一個報文的長度超過適配層傳輸?shù)淖畲箝L度，考慮到節(jié)點存儲以及能量的有限需要對報文進行分片。圖2.2不分片的格式其各個字段的含義如下：LF：(LinkFragment)鏈路分片。為2bit，在分片格式中該字段不為0。有三種表示格式分別是：01表示第一分片，10表示最后的分片，11表示中間分片。Prot-type：協(xié)議類型。為8bit，表示在報文頭部的報文類型。只在第一分片中出現(xiàn)。M：(MeshDelivery)字段標志位。為1bit，如果該位置為1，則適配層頭部后為“MeshDelivery”字段。B：(Broadcast)為1bit，如果該位置為1，則適配層頭部后為“Broadcast”字段。rsv：(reservation)保留字段，全置為0。Datagram-size：負載報文長度。為11bit，支持的最大長度為2048字節(jié)。能滿足IPv6報文在IEEE802.15.4上傳輸1280字節(jié)MTU的要求。Datagram-tag：分片標識符。為9bit，所有同一報文的該標識都相同。fragment-offset：報文分片偏移。為8bit，改字段在第二分片及后繼分片中出現(xiàn)，表示后繼的分片與報文頭部的偏移。分片與重組IPv6規(guī)定的鏈路層的MTU為1280個字節(jié)，但適配層并不支持這個MTU的要求，于是協(xié)議需要對鏈路層的報文進行分片與重組。因此，適配層需要通過對IP報文進行分片和重組來傳輸超過IEEE802.15.4MAC層最大幀長（127字節(jié)）的數(shù)據(jù)報文。將鏈路層的數(shù)據(jù)包分割成多個鏈路層幀，以適應IPv6最小MTU的要求，然后將分片的報文再進行重組繼續(xù)傳輸。1分片當上層為適配層下傳一個超過最大payload長度的報文時，適配層就對該IP報文進行分片傳送。適配層進行分片的判斷依據(jù)是：負載報文長度、不分片頭部長度與MeshDelivery(或Broadcast)字段長度之和大于IEEE802.15.4MAC層的最大payload長度時需要分片。對分片的具體流程如下圖所示：圖2.3分片流程在第一分片中，01就表示第一分片，Prot-type標識上層協(xié)議為IPv6，且沒有fragment_offset字段。在后繼的分片中，分片頭部設(shè)為11或10，表示中間分片跟最后分片。fragment_offset字段被設(shè)為當前的報文分片相對于原負載報文起始字節(jié)的偏移。對于Datagram-tag字段，每發(fā)完一個分片分組該字段就加1，直到增到511后又轉(zhuǎn)為0繼續(xù)增加到分片全部發(fā)送完。2重組當適配層接收到一個分片后，就根據(jù)源MAC地址跟分片頭部的Datagram-tag字段來判斷該分片屬于哪個負載報文。重組的過程如下圖所示：圖2.4不分片報文流程若適配層第一次收到一個負載報文的分片，就將該被分片的源MAC地址和datagram_tag字段記下來方便以后供重組使用。如果該報文的其它分片已經(jīng)收到，就依據(jù)當前分片幀的fragment_offset字段進行重組。若發(fā)現(xiàn)收到的是一個重復但不重疊的分片，應該使用新收到的分片進行替換。若本分片和前面的分片有重疊，則應該丟棄當前分片。以此來簡化處理。在成功收到所有分片后，按根據(jù)分片的offset值進行重組，并將重組好的原始負載報文交給上層。并且還需要刪除開始記錄的源MAC地址和datagram_tag字段的信息。重組一個分片需要一個重組隊列來維護已收到的分片等信息。另一方面，節(jié)點需要在收到第一分片后設(shè)置一個重組定時器來避免長時間未到的分片，定時時間設(shè)為15s，當超過該指定的時間后將刪除隊列中接收到的所有分片以及相關(guān)的信息，認為是錯誤的信息。尋址和自動配置IEEE802.15.4協(xié)議對物理層和MAC層的功能特性做出了詳細的描述。這個協(xié)議的物理層規(guī)定了工作頻段的范圍、調(diào)制的方式、傳輸速率等。而MAC層提供了各種不同功能的通信原語來進行信道掃描和網(wǎng)絡(luò)維護。但是從另一方面來看，MAC層并沒有調(diào)用原語來形成網(wǎng)絡(luò)拓撲結(jié)構(gòu)和對這些拓撲結(jié)構(gòu)進行維護的功能，因此維護拓撲結(jié)構(gòu)的工作將由適配層來進行。6LOWPAN中的每個節(jié)點使用EUI-64標準作為地址標識符，但是大多數(shù)的6LOWPAN網(wǎng)絡(luò)節(jié)點的存儲、能量等非常有限，并且節(jié)點的數(shù)量也比較大，如果采用64-bits的地址可能會占用大量的存儲空間，而且可能使報文載荷增加。因此，在適配層采用動態(tài)16-bits的短地址來標識網(wǎng)絡(luò)中的每一個節(jié)點應該是更加適合的方案。報頭壓縮在沒有校驗等功能的前提下，IEEE802.15.4協(xié)議的MAC層提供的最大載荷(payload）是102個字節(jié)，IPv6規(guī)定的報文的頭部占40個字節(jié)，再加上適配層和傳輸層等的頭部，最后只剩下50個字節(jié)的空間用于傳送數(shù)據(jù)。為了使IPv6數(shù)據(jù)滿足IEEE802.15.4傳輸?shù)淖畲髠鬏攩卧狹TU的要求，一方面可以通過分片和重組機制來傳輸過長的IPv6報文，另一方面需要對IPv6的報文進行壓縮，從而減少冗余和提高數(shù)據(jù)傳輸?shù)男什⑶夜?jié)省節(jié)點的能量。為了實現(xiàn)壓縮，需要將表征頭部壓縮的編碼字段增加在適配層的報文后邊，這個字段將指出IPv6的那些字段被壓縮了，除了對IPv6的頭部字段壓縮外，還可以對上層協(xié)議如UDP、TCP和ICMPv6的頭部進行進一步的壓縮。目前適配層只支持3種方式的壓縮：用于IPv6頭部壓縮的LoWPAN_HC1格式；用于UDP頭部壓縮的HC_UDP格式，用于ICMPv6壓縮的HC_ICMP格式。網(wǎng)絡(luò)管理跟安全問題網(wǎng)絡(luò)管理是一個很重要的一部分。由于網(wǎng)絡(luò)中節(jié)點數(shù)量比較龐大，有些節(jié)點被部署到了網(wǎng)絡(luò)維護人員不能達到的地方。因此要求部署在網(wǎng)絡(luò)中的節(jié)點有自愈功能，在很低的開銷下，網(wǎng)絡(luò)管理技術(shù)能夠管理分布高度密集的節(jié)點。6LOWPAN使用SNMPv3來進行網(wǎng)絡(luò)的管理和維護。安全管理需要消耗額外的帶寬資源。6LOWPAN使用由IEEE802.15.4提供的強大的AES-128的安全機制。雖然網(wǎng)絡(luò)層的安全機制如IPsec和安全鄰居變得越來越成熟，但是他們在6LOWPAN上能否可行仍然被質(zhì)疑。

RPL路由協(xié)議RPL路由協(xié)議制定背景低功耗有損網(wǎng)絡(luò)路由協(xié)議（RPL）是IETF的ROLL（RoutingOverLowpowerandLossynetworks）工作組，專門針對低功耗有損網(wǎng)絡(luò)LLN（LowpowerandLossynetwork）新提出來的路由協(xié)議。低功耗有損網(wǎng)絡(luò)是由功率、存儲空間、處理能力等資源受限的嵌入式設(shè)備所組成的網(wǎng)絡(luò)。它們可以通過多種鏈路連接，比如IEEE802.15.4、藍牙、低功率Wi-Fi，甚至低功耗電力線通信（PLC）等等。ROLL將LLN網(wǎng)絡(luò)的應用主要劃分為四個領(lǐng)域：城市網(wǎng)絡(luò)（包括智能電網(wǎng)應用）、建筑自動化、工業(yè)自動化以及家庭自動化，并且分別制定了針對四個應用領(lǐng)域的路由需求。由于LLN的獨特性，傳統(tǒng)的IP路由協(xié)議，比如OSPF、IS-IS、AODV、OLSR，無法滿足其獨特的路由需求，因此ROLL工作組制定了RPL協(xié)議，其協(xié)議標準RFC6550發(fā)布于2012年3月。RPL協(xié)議工作原理RPL路由協(xié)議是一個基于IPv6的距離矢量路由協(xié)議。它通過一個目標函數(shù)(ObjectiveFunction)和一些路由代價及路由約束建立一個目標導向的有向無環(huán)圖DODAG(DestinationOrientedDirectedAcyclicGraph)。每個DODAG中的節(jié)點(根節(jié)點除外)會選擇一個父節(jié)點作為沿著DODAG向上的默認路由。目標函數(shù)通過路由代價和約束來選擇一條最優(yōu)的路徑。一個節(jié)點上可以有好多種不同的目標函數(shù)，因為同一個節(jié)點可以部署到不同的環(huán)境中去。有的應用環(huán)境要求用期望傳輸次數(shù)ETX(ExpectedTransmissions)作為路由代價，有的應用環(huán)境需要用延遲作為路由代價。當一個RPL節(jié)點獲得一個IPv6地址后(通過DHCPv6動態(tài)獲得或者靜態(tài)指定)，會通過和周圍的節(jié)點交換3種ICMPv6消息(DIS，DIO和DAO)以選擇自己父節(jié)點來加入一個目標導向的有向無環(huán)圖。RPL路由協(xié)議支持點對點(point－To-point)、多點到點(multipoint－To-point)和點到多點(point－To-mutipoint)3種數(shù)據(jù)流動方式。RPL路由協(xié)議可以工作在兩種不同的模式下:Non-StoringMode和StoringMode。在多點到點的流動方式中，Non-StoringMode和Storing模式中的節(jié)點都將父節(jié)點作為默認的下一跳路由，通過父節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)到根節(jié)點。在點到多點方式中，Non-StoringMode只有根節(jié)點存有到下面節(jié)點的路由表，所以根節(jié)點會根據(jù)路由表構(gòu)建到其余節(jié)點的源路由，而在StoringMode中除了根節(jié)點，其余節(jié)點也會存有路由表，所以根節(jié)點只會決定達到目的節(jié)點的下一跳地址，而不會構(gòu)建一個源路由。在點到點流動方式中，Non-StoringMode會將數(shù)據(jù)先發(fā)送到源節(jié)點和目的節(jié)點共同的父節(jié)點，然后通過父節(jié)點將數(shù)據(jù)轉(zhuǎn)發(fā)到目的節(jié)點。但是在StoringMode中會先將數(shù)據(jù)發(fā)送到根節(jié)點，然后通過根節(jié)點將數(shù)據(jù)發(fā)送到目的節(jié)點。RPL路由協(xié)議的拓撲結(jié)構(gòu)圖3.1DODAGVersionNumber低功耗易丟失網(wǎng)絡(luò)，如無線網(wǎng)絡(luò)，通常都沒有一個預先定義好的拓撲結(jié)構(gòu)，所以RPL路由協(xié)議需要發(fā)現(xiàn)連接，然后建立和維護拓撲結(jié)構(gòu)。RPL路由協(xié)議通過4個值來建立和維護一個拓撲結(jié)構(gòu):RPLInstanceID、DODAGID、DODAGVersionNumber和Rank。具體細節(jié)如下圖3.1DODAGVersionNumber1)RPLInstanceID:一個RPLInstanceID指定了一個或者幾個DODAG。RPLInstanceID相同的節(jié)點使用相同的目標函數(shù)。然后是DODAGID，一個RPLInstance中有一個或者多個DODAG，每個DODAG有一個唯一的DODAGID。DODAGID的范圍是一個RPLInstance。一個RPLInstanceID和一個DODAGID唯一的確定了一個DODAG。如圖3.1中整個圖為一個RPLInstance，RPLInstanceID為1。這個RPLInstance中有3個DODAG，DODAGID分別為1，2，3。RPLInstanceID=1和DODAGID=1就唯一地代表最左邊的一個DODAG。圖3.1中所標注的節(jié)點為DODAG根節(jié)點，DODAG根節(jié)點通過骨干網(wǎng)連接到路由器，然后再由路由器連接到傳統(tǒng)的有線網(wǎng)絡(luò)中去。圖3.2DODAGVersionNumber2)DODAGVersionNumber:節(jié)點通常會因為自身的原因(如節(jié)點電池耗盡)或者環(huán)境原因而失去作用，結(jié)果導致DODAG的拓撲結(jié)構(gòu)發(fā)生變化。因此路由協(xié)議必須維護DODAG的拓撲。RPL路由協(xié)議通過DODAGVersionNumber來定義不同DODAG的拓撲版本，當DODAG因為某種原因重新建立的時候，變成另外一個拓撲版本的時候，DODAGVersionNumber會加1。如圖3.2，左邊DODAG的版本號DODAGVersionNumber為N，當拓撲結(jié)構(gòu)發(fā)生變化的時候，DODAG的版本號DODAGVersionNumber圖3.2DODAGVersionNumber圖3.3DODAGRank值3）節(jié)點的Rank值(圖3.3)。Rank值的作用范圍是一個DODAGVersionNumber當DODAGVersionNumber變化的時候，節(jié)點會重新計算Rank值。Rank值的大小代表了該節(jié)點距離根節(jié)點的距離，Rank值越小說明距根節(jié)點越近。DODAG根節(jié)點的Rank值為0，父節(jié)點的Rank值大于子節(jié)點的Rank值。Rank值可以用來避免路由回環(huán)和進行路由回環(huán)檢測。一個節(jié)點Rank值由目標函數(shù)來計算。但值得注意的是Rank值不是一個路徑代價，盡管Rank圖3.3DODAGRank值RPL路由協(xié)議的建立過程運行RPL路由協(xié)議的節(jié)點之間通過交換DIO、DIS和DAO3種ICMPv6控制消息來建立拓撲和路由。整個過程分成兩個過程。第一個過程是拓撲結(jié)構(gòu)的建立和向上路由的建立，第二個過程是向下路由的建立。在建立向下路由的時候存在兩種模式:StoringMode和Non-StoringMode。下面以圖3.4所示的網(wǎng)絡(luò)節(jié)點進行說明:1）拓撲建立和向上路由的建立：在最開始的時候，一些節(jié)點會被指定為DODAG根節(jié)點。當根節(jié)點工作后會向周圍節(jié)點發(fā)送DIO消息。DIO消息中包含RPLInstanceID、DODAGVersionNumber、DODAGID、根節(jié)點Rank值、RPL路由協(xié)議工作的模式、DODAG的配置信息、路由代價以及通過根節(jié)點可以達到的地址等。因為一個RPLInstance中可能有好幾個根節(jié)點，所以一個節(jié)點可能接收到多個根節(jié)點發(fā)送過來的DIO，這個時候節(jié)點會根據(jù)DIO中的路由代價信息使用目標函數(shù)選擇自己的父節(jié)點，然后計算出節(jié)點自己的Rank值。然后該節(jié)點修改DIO中的路由代價和Rank值信息后向自己周圍的節(jié)點發(fā)送DIO數(shù)據(jù)包。同理其余的節(jié)點可能會同時接收到好多節(jié)點給它發(fā)送的DIO，接著節(jié)點用DIO數(shù)據(jù)包中包含的路由代價信息使用目標函數(shù)從發(fā)送DIO的眾多節(jié)點中選擇一個節(jié)點作為自己的父節(jié)點，然后節(jié)點修改路由代價、Rank值等后再向它周圍的節(jié)點發(fā)送DIO。這樣所有節(jié)點都知道自己的父節(jié)點了，DODAG中的節(jié)點會將父節(jié)點作為路由時默認的下一跳節(jié)點，因此當DODAG中的節(jié)點向上發(fā)送數(shù)據(jù)的時候，就將數(shù)據(jù)包發(fā)送給父節(jié)點，然后通過父節(jié)點轉(zhuǎn)發(fā)數(shù)據(jù)。如圖3.4所示，第一個圖為最開始的時候，節(jié)點0和節(jié)點1為根節(jié)點。節(jié)點2和節(jié)點3在節(jié)點0的通信范圍內(nèi)，節(jié)點3和節(jié)點4在節(jié)點1的通信范圍內(nèi)。第二個圖，根節(jié)點開始向周圍的節(jié)點發(fā)送DIO。節(jié)點2收到節(jié)點1的DIO，節(jié)點3同時收到節(jié)點0和節(jié)點1的DIO，節(jié)點4收到節(jié)點1的DIO。顯然節(jié)點2和節(jié)點4分別選擇了節(jié)點0和節(jié)點1作為自己的父節(jié)點，因為它們只收到了一個DIO。節(jié)點3通過目標函數(shù)計算選擇了節(jié)點0作為自己的父節(jié)點。此時RPLInstance的狀態(tài)就到了第三個圖，節(jié)點2、節(jié)點3和節(jié)點4修改路由代價及Rank值能信息后再向自己的周圍節(jié)點轉(zhuǎn)發(fā)DIO，如圖所示節(jié)點2給節(jié)點5和節(jié)點6發(fā)送了DIO，節(jié)點3和節(jié)點4都給節(jié)點6發(fā)送了DIO。最后節(jié)點5將節(jié)點2當作父節(jié)點，而節(jié)點6通過目標函數(shù)選擇了節(jié)點4作為了父節(jié)點。到此時整個拓撲結(jié)構(gòu)都建立起來了。當節(jié)點5要向節(jié)點0發(fā)送數(shù)據(jù)的時候，會將數(shù)據(jù)默認發(fā)給其父節(jié)點2，然后通過節(jié)點2轉(zhuǎn)發(fā)給節(jié)點0。但是此時如果節(jié)點0要給節(jié)點5發(fā)送數(shù)據(jù)，節(jié)點0還不知道發(fā)送的路徑。因為此時圖3.4路由協(xié)議建立過程描述圖3.4路由協(xié)議建立過程描述2）向下路由的建立：向下路由的建立有兩種模式:StoringMode和Non-StoringMode。在StoringMode中所有節(jié)點上都會保存有向下的路由表，而在Non-StoringMode模式中只有根節(jié)點保存向下的路由表。在StoringMode下，一個節(jié)點收到DIO消息選擇好父節(jié)點后，會向父節(jié)點發(fā)送DAO。DAO消息中包含了通過該節(jié)點可以達到的地址或者地址前綴信息。當父節(jié)點收到DAO后會處理DAO消息中的地址前綴，然后在路由表中加入相應的路由項。當父節(jié)點做完這些后就會向它的父節(jié)點發(fā)送DAO數(shù)據(jù)包。如此重復直到整個向下的路由建立起來。在Non-StoringMode下，一個節(jié)點收到DIO消息后不是向父節(jié)點發(fā)送DAO，而是向DODAG根節(jié)點發(fā)送DAO。當然必須要通過父節(jié)點轉(zhuǎn)發(fā)。當根節(jié)點收到所有節(jié)點發(fā)送過來的DAO消息后，就會建立到所有節(jié)點的路由表。當根節(jié)點要向下面的節(jié)點發(fā)送數(shù)據(jù)包的時候，根節(jié)點根據(jù)路由表構(gòu)建源路由。

Contiki操作系統(tǒng)Contiki操作系統(tǒng)簡介Contiki是一個開源的、高度可移植的多任務(wù)操作系統(tǒng)，適用于互聯(lián)網(wǎng)嵌入式系統(tǒng)和無線傳感器網(wǎng)絡(luò)，由瑞典計算機科學學院（SwedishInstituteofComputerScience）的AdamDunkels和他的團隊開發(fā)。Contiki完全采用C語言開發(fā)，可移植性非常好，對硬件的要求極低，能夠運行在各種類型的微處理器及電腦上，目前已經(jīng)移植到8051單片機、MSP430、AVR、ARM、PC機等硬件平臺上。Contiki適用于存儲器資源十分受限的嵌入式單片機系統(tǒng)，典型的配置下contiki只占用約2Kbytes的RAM以及40Kbytes的Flash存儲器。Contiki是開源的操作系統(tǒng)，適用于BSD協(xié)議，即可以任意修改和發(fā)布，無需任何版權(quán)費用，因此已經(jīng)應用在許多項目中。Contiki操作系統(tǒng)是基于事件驅(qū)動（Event-driven）內(nèi)核的操作系統(tǒng)，在此內(nèi)核上，應用程序可以在運行時動態(tài)加載，非常靈活。在事件驅(qū)動內(nèi)核基礎(chǔ)上，contiki實現(xiàn)了一種輕量級的名為protothread的線程模型，來實現(xiàn)線性的、類似于線程的編程風格。該模型類似于Linux和windows中線程的概念，多個線程共享同一個任務(wù)棧，從而減少RAM占用。Contiki還提供一種可選的任務(wù)搶占機制、基于事件和消息傳遞的進程間通信機制。Contiki中還包括一個可選的GUI子系統(tǒng)，可以提供對本地串口終端、基于VNC的網(wǎng)絡(luò)化虛擬顯示或者Telnet的圖形化支持。Contiki系統(tǒng)內(nèi)部集成了兩種類型的無線傳感器網(wǎng)絡(luò)協(xié)議棧：uIP和Rime。uIP是一個小型的符合RFC規(guī)范的TCP/IP協(xié)議棧，使得contiki可以直接和Internet通信。uIP包含了IPv4和IPv6兩種協(xié)議棧版本，支持TCP、UDP、ICMP等協(xié)議，但是編譯時只能二選一，不可以同時使用。Rime是一個輕量級、低功耗無線傳感器網(wǎng)絡(luò)設(shè)計的協(xié)議棧，該協(xié)議棧提供了大量的通信原語，能夠?qū)崿F(xiàn)從簡單的一跳廣播通信，到復雜的可靠的多跳數(shù)據(jù)傳輸?shù)韧ㄐ殴δ?。Contiki操作系統(tǒng)的特點1）事件驅(qū)動（Event-driven）的多任務(wù)內(nèi)核：Contiki基于事件驅(qū)動模型，即多個任務(wù)共享同一個棧（stack），而不是每個任務(wù)分別占用獨立的棧（如uCOS、FreeRTOS、Linux等）。Contiki每個任務(wù)只占用幾個字節(jié)的RAM，可以大大節(jié)省RAM空間，更適合節(jié)點資源十分受限的無線傳感器網(wǎng)絡(luò)應用。2）低功耗無線傳感器網(wǎng)絡(luò)協(xié)議棧：Contiki提供完整的IP網(wǎng)絡(luò)和低功耗無線網(wǎng)絡(luò)協(xié)議棧。對于IP協(xié)議棧，支持IPv4和IPv6兩個版本，IPv6還包括6LOWPAN幀頭壓縮適配器，ROLLRPL無線網(wǎng)絡(luò)組網(wǎng)路由協(xié)議、CoRE/CoAP應用層協(xié)議，還包括一些簡化的Web工具，包括Telnet、http和web服務(wù)等。Contiki還實現(xiàn)了無線傳感器網(wǎng)絡(luò)領(lǐng)域知名的MAC和路由層協(xié)議，其中MAC層包括X-MAC、CX-MAC、ContikiMAC、CSMA-CA、LPP等，路由層包括AODV、RPL等。3）集成無線傳感器網(wǎng)絡(luò)仿真工具：Contiki提供Cooja無線傳感器網(wǎng)絡(luò)仿真工具，能夠多對協(xié)議在電腦上進行仿真，仿真通過后，下載到節(jié)點上進行實際測試，有利于發(fā)現(xiàn)問題，減少調(diào)試工作量。除此之外，contiki還提供MSPsim仿真工具，能夠?qū)SP430微處理器進行指令級模擬和仿真。仿真工具對于科研、算法和協(xié)議驗證、工程實施規(guī)劃、網(wǎng)絡(luò)優(yōu)化等很有幫助。4）集成Shell命令行調(diào)試工具：無線傳感器網(wǎng)絡(luò)中節(jié)點數(shù)量多，節(jié)點的運行維護是一個難題，contiki可以通過多種交互方式，如Web瀏覽器，基于文本的命令行接口，或者存儲和顯示傳感器數(shù)據(jù)的專用程序等。基于文本的命令行接口是類似于Unix命令行的Shell工具，用戶通過串口輸入命令可以查看和配置傳感器節(jié)點的信息、控制其運行狀態(tài)，是部署、維護中實用而有效的工具。5）基于Flash的小型文件系統(tǒng)CoffeeFileSystem：Contiki實現(xiàn)了一個簡單、小巧、易于使用的文件系統(tǒng)，稱為CoffeeFileSystem（CFS），它是基于Flash的文件系統(tǒng)，用于在資源受限的的節(jié)點上存儲數(shù)據(jù)和程序。CFS是充分傳感器網(wǎng)絡(luò)數(shù)據(jù)采集、數(shù)據(jù)傳輸需求以及硬件資源受限的特點而設(shè)計的，因此在耗損平衡、壞塊管理、掉電保護方面、垃圾回收、映射機制方等方面進行優(yōu)化，具有使用的存儲空間少、支持大規(guī)模存儲的特點。CFS的編程方法與常用的C語言編程類似，提供open、read、write、close等函數(shù)，易于使用。6）集成功耗分析工具：為了延長傳感器網(wǎng)絡(luò)的生命周期，控制和減少傳感器節(jié)點的功耗至關(guān)總重要，無線傳感器網(wǎng)絡(luò)領(lǐng)域提出的許多網(wǎng)絡(luò)協(xié)議都圍繞降低功耗而展開。為了評估網(wǎng)絡(luò)協(xié)議以及算法能耗性能，需要測量出每個節(jié)點的能量消耗，由于節(jié)點數(shù)量多，使用儀器測試幾乎不可行。Contiki提供了一種基于軟件的能量分析工具，自動記錄每個傳感器節(jié)點的工作狀態(tài)、時間，并計算出能量消耗，在不需要額外的硬件或儀器的情況下就能完成網(wǎng)絡(luò)級別的能量分析。Contiki的能量分析機制既可用于評價傳感器網(wǎng)絡(luò)協(xié)議，也可用于估算傳感器網(wǎng)絡(luò)的生命周期。7）開源免費：Contiki采用BSD授權(quán)協(xié)議，用戶可以下載代碼，且可以任意修改代碼，無需任何專利以及版權(quán)費用，是徹底的開源軟件。盡管是開源軟件，但是contiki開發(fā)十分活躍，在持續(xù)不斷更新和改進之中。Contiki操作系統(tǒng)的安裝和測試安裝contiki操作系統(tǒng)Contiki操作系統(tǒng)是在Linux系統(tǒng)下進行安裝和配置的，有兩種常見的安裝方式，方法一種是下載已經(jīng)安裝好的鏡像文件，用虛擬機Vmware直接打開；方法二是先安裝ubuntu操作系統(tǒng)在進行contiki系統(tǒng)的下載和配置，這里簡單介紹方法二的安裝。在已經(jīng)安裝好ubuntu的操作系統(tǒng)中，用快捷鍵Ctrl+Alt+t打開虛擬終端，輸入下面命令：sudoapt-getinstallbuild-essentialbinutils-msp430gcc-msp430msp430-libcbinutils-avrgcc-avrgdb-avravr-libcavrdudeopenjdk-7-jdkopenjdk-7-jreantlibncurses5-devdoxygengit輸入用戶密碼等待下載完成后執(zhí)行下面命令：gitclonegit:///contiki-os/contiki.gitcontiki等待命令執(zhí)行完以后，就可以在/home/user/路徑下找到contiki的系統(tǒng)文件，如圖4.1所示。至此，contiki系統(tǒng)下載安裝完成。圖4.1用終端查看安裝完的Contiki操作系統(tǒng)文件夾定制SDCCcontiki中不能直接完成cc2530的編譯，所以需要下載SDCC的源代碼進行編譯，這個過程本質(zhì)是一個定制SDCC的過程。在這里下載的并不是安裝包，而是SDCC的源代碼，我們用這些SDCC的源代碼可以編譯成一個SDCC安裝包。SDCC的版本有7100和8447，我們在這里安裝8447。我們一般將SDCC安裝在/opt路徑下，安裝步驟如下：1）使用如下命令安裝BoostC++Libraries。BoostC++Libraries是一組擴充C++功能性的經(jīng)過同行評審（Peer-reviewed）且開放源代碼程序庫。大多數(shù)的函數(shù)為了能夠以開放源代碼、封閉項目的方式運作，而授權(quán)于Boost軟件許可協(xié)議（BoostSoftwareLicense）之下。sudoapt-getinstalllibboost-graph-dev2）使用如下命令安裝srecordsudoapt-getinstalllibboost-graph-dev等待這兩部分完成以后就開始下載SDCC的源碼。3）通過命令將目錄切換在/opt目錄下，然后通過SVN命令獲得SDCC源代碼，代碼如下：cd/optsudosvnco-r8447/p/sdcc/code/trunk/sdcc等待下載完以后，可以再/opt目錄下找到名為sdcc的文件夾。4）配置SDCCa．打開incl.mk文件，將最后一行MODELS=smallmediumlarge修改為MODELS=smalllargehuge。這里用gedit命令打開文件，命令如下：sudogedit/opt/sdcc/device/lib/incl.mkb．打開Makefile.in文件，找到TARGETS+=modelssmall-mcs51-stack-auto修改為TARGETS+=modelsmodle-mcs51-stack-auto。命令如下：sudogedit/opt/sdcc/device/lib/Makefile.inc．將目錄切換在/opt/sdcc路徑下，首先執(zhí)行命令：sudo./configure--disable-gbz80-port--disable-z80-port--disable-ds390-port\--disable-ds400-port--disable-pic14-port--disable-pic16-port\--disable-hc08-port--disable-r2k-port--disable-z180-port\--disable-sdcdb--disable-ucsim./configure命令就是執(zhí)行當前目錄的名為configure的腳本，主要的作用是對即將安裝的軟件進行配置。接下來執(zhí)行命令：sudomakemake的基本功能是自動根據(jù)makefile里的指令來編譯源文件。等待執(zhí)行完以后，最后執(zhí)行命令：sudomakeinstallmakeinstall：將程序安裝至系統(tǒng)中。如果原始碼編譯無誤，且執(zhí)行結(jié)果正確，便可以把程序安裝到系統(tǒng)預設(shè)的可執(zhí)行文件存放路徑。d．驗證安裝安裝完成后需要驗證安裝是否正確，可以回到home目錄，輸入以下命令：sdcc-v通過命令也可以查看SDCC可執(zhí)行文件的路徑。whichsdcc上面兩條指令的執(zhí)行結(jié)果如圖4.2所示：圖4.2檢查SDCC安裝結(jié)果e．測試SDCC如果SDCC安裝成功，那么contiki就會變得非常簡單。就會和IAR開發(fā)環(huán)境一樣，首先需要編譯工程以便生成hex文件，然后使用smartRFFlashProgrammer下載該.hex文件到目標板，最后便可通過串口調(diào)試助手等工具觀察程序運行情況。使用命令進入cc2530dk目錄中進行編譯，命令如下：cdcontiki/examples/cc2530dk/makeTARGET=cc2530dk編譯后的結(jié)果和生成的.hex文件如圖4.3所示：圖4.3cc2530dk編譯生成.hex文件然后通過將.hex文件下載到開發(fā)板上，就可以進行，程序功能的測試。測試contiki操作系統(tǒng)通過以上步驟，安裝了contiki系統(tǒng)并配置好SDCC，我們進入/hello-world目錄測試contiki。輸入如下命令，make后生成.native文件，運行.native文件，結(jié)果如圖3.4所示。cd/home/user/contiki/examples/hello-world/make./hello-world.native利用快捷鍵Ctrl+c終止正在運行的程序。圖4.4測試contiki

系統(tǒng)仿真本設(shè)計使用虛擬機安裝烏班圖系統(tǒng)，并且安裝了Contiki操作系統(tǒng)使用cooja對智能家居網(wǎng)絡(luò)進行仿真，最后使用安裝了COAP插件的火狐瀏覽器實現(xiàn)了對節(jié)點的遠程控制。Cooja仿真工具介紹Cooja是運行在Contiki操作系統(tǒng)上的一個模擬器，為仿真?zhèn)鞲衅骶W(wǎng)絡(luò)而設(shè)計的。模擬器是用Java實現(xiàn)的，但是傳感器節(jié)點上運行的代碼是用C語言編寫的。不像大多數(shù)無線傳感器仿真器針對一個固定的仿真水平，Cooja實現(xiàn)跨級仿真。它允許同時在三個級別上仿真一個系統(tǒng)，分別是網(wǎng)絡(luò)級別（或者應用程序級別），操作系統(tǒng)級別和機器代碼指令級別。COAP協(xié)議的簡單介紹在2010年3月，CoRE工作組開始制定CoAP協(xié)議，到目前為止，該協(xié)議還沒有定稿。CoAP協(xié)議是為物聯(lián)網(wǎng)中資源受限設(shè)備制定的應用層協(xié)議。CoAP是受限制的應用協(xié)議(ConstrainedApplicationProtocol)的代名詞。在最近幾年的時間中，專家們預測會有更多的設(shè)備相互連接，而這些設(shè)備的數(shù)量將遠超人類的數(shù)量。在這種大背景下，物聯(lián)網(wǎng)和M2M技術(shù)應運而生。雖然對人而言，連接入互聯(lián)網(wǎng)顯得方便容易，但是對于那些微型設(shè)備而言接入互聯(lián)網(wǎng)非常困難。在當前由PC機組成的世界，信息交換是通過TCP和應用層協(xié)議HTTP實現(xiàn)的。但是對于小型設(shè)備而言，實現(xiàn)TCP和HTTP協(xié)議顯然是一個過分的要求。為了讓小設(shè)備可以接入互聯(lián)網(wǎng)，CoAP協(xié)議被設(shè)計出來。CoAP是一種應用層協(xié)議，它運行于UDP協(xié)議之上而不是像HTTP那樣運行于TCP之上。CoAP協(xié)議非常的小巧，最小的數(shù)據(jù)包僅為4字節(jié)。為了克服HTTP對于受限環(huán)境的劣勢，CoAP既考慮到數(shù)據(jù)報長度的最優(yōu)化，又考慮到提供可靠通信。一方面，CoAP提供URI，REST式的方法如GET，POST，PUT和DELETE，以及可以獨立定義的頭選項提供的可擴展性。另一方面，CoAP基于輕量級的UDP協(xié)議，并且允許IP多播。而組通信是物聯(lián)網(wǎng)最重要的需求之一，比如說用于自動化應用中。為了彌補UDP傳輸?shù)牟豢煽啃?，CoAP定義了帶有重傳機制的事務(wù)處理機制。并且提供資源發(fā)現(xiàn)機制，并帶有資源描述。CoAP協(xié)議不是盲目的壓縮了HTTP協(xié)議，考慮到資源受限設(shè)備的低處理能力和低功耗限制，CoAP重新設(shè)計了HTTP的部分功能以適應設(shè)備的約束條件。另外，為了使協(xié)議適應物聯(lián)網(wǎng)和M2M應用，CoAP協(xié)議改進了一些機制，同時增加了一些功能。下圖5顯示了HTTP和CoAP的協(xié)議棧。CoAP和HTTP在傳輸層有明顯的區(qū)別。HTTP協(xié)議的傳輸層采用了TCP協(xié)議，而CoAP協(xié)議的傳輸層使用UDP協(xié)議，開銷明顯降低，并支持多播。圖5.1HTTP和CoAP的協(xié)議棧事務(wù)層(Transactionlayer)用于處理節(jié)點之間的信息交換，同時提供組播和擁塞控制等功能。請求/響應層(Request/Responselayer)用于傳輸對資源進行操作的請求和響應信息。CoAP協(xié)議的REST構(gòu)架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒有采用TCP協(xié)議，也可以提供可靠的傳輸機制。利用默認的定時器和指數(shù)增長的重傳間隔時間實現(xiàn)圖5.1HTTP和CoAP的協(xié)議棧仿真過程打開虛擬機，按CTRL+ALT+T打開終端。圖5.2終端界面進入COOJA目錄輸入antrun啟動Cooja仿真器。圖5.3啟動Cooja點擊File選擇Newsimulation新建仿真。圖5.4Cooja仿真器界面點擊Motes添加sky節(jié)點，建立一個匯聚節(jié)點相當于RPL組網(wǎng)中的根節(jié)點也相當于家里的路由器，傳感器網(wǎng)絡(luò)中的信息最后都會傳輸?shù)竭@一節(jié)點，并且瀏覽器也是通過這一節(jié)點對傳感器節(jié)點進行控制。圖5.5仿真器的Network界面然后添加傳感器節(jié)點，傳感器網(wǎng)絡(luò)就是由這些節(jié)點用RPL協(xié)議組網(wǎng)后形成。這里我們添加了八個傳感器節(jié)點，這些節(jié)點就代表智能家居中的冰箱、電燈、窗簾等可控制的電器或物品。截圖中可以看出除了節(jié)點2和節(jié)點3都不能直接與匯聚節(jié)點通信，所以要用RPL協(xié)議進行組網(wǎng)實現(xiàn)信息的多跳傳輸?，F(xiàn)在軟件內(nèi)的仿真已經(jīng)基本完成，但是還要提供讓瀏覽器訪問的接口以實現(xiàn)遠程控制。圖5.6傳感器網(wǎng)絡(luò)的仿真在節(jié)點1上點擊右鍵選擇Motetoolsforsky1->SerialSocket(SERVER)添加訪問接口。圖5.7為瀏覽器訪問添加接口對添加的接口進行配置，進入contiki-2.7/examples/er-rest-example/目錄輸入connect-router-cooja回車運行。圖5.8對接口進行配置仿真系統(tǒng)測試在仿真界面點擊Start運行傳感器網(wǎng)絡(luò)。圖5.9運行中的傳感器網(wǎng)絡(luò)打開火狐瀏覽器輸入?yún)R聚節(jié)點的地址http://[aaaa::212:7401:1:101]/可以看到傳感器網(wǎng)絡(luò)中的所有節(jié)點地址。圖5.10傳感器網(wǎng)絡(luò)中所有節(jié)點的地址現(xiàn)在雖然瀏覽器能訪問傳感器網(wǎng)絡(luò)但是無法實現(xiàn)遠程控制，因此在火狐瀏覽器上可以安裝COAP插件使用COAP協(xié)議對傳感器節(jié)點進行訪問控制。安裝好COAP插件后例如要控制節(jié)點9，在火狐瀏覽器地址欄輸入節(jié)點9的地址coap://[aaaa::212:7409:9:909]:5683進入控制界面。圖5.11COAP的控制界面點擊左側(cè)light->leds然后點擊菜單中的POST方法可看到節(jié)點9的紅燈被點亮，再次點擊紅燈熄滅。圖5.12控制節(jié)點9的LED燈點擊左側(cè)sensors->temperature,然后點擊上方的GET方法，可以看到輸出框輸出Temperatureis23℃.即通過GET方法可以獲取傳感器溫度。圖5.13獲取傳感器溫度通過對溫度的讀取與LED燈的結(jié)合可以實現(xiàn)對傳感器節(jié)點的數(shù)據(jù)獲取與遠程控制，雖然仿真只是表現(xiàn)為控制LED燈的亮暗但是在實際中可以換為電源開關(guān)等對傳感器節(jié)點進行控制。并且瀏覽器界面的左側(cè)菜單都可自定義，以實現(xiàn)更豐富的功能，但是水平所限未能實現(xiàn)更多更實用的功能這有待以后完善。點擊tools->Radiomessages打開cooja自帶的抓包工具對傳感器網(wǎng)絡(luò)進行分析。打開一條消息的詳細信息可看見消息Type為RPL，由此可見傳感器網(wǎng)絡(luò)是由RPL協(xié)議進行了組網(wǎng)。圖5.14RPL數(shù)據(jù)包

硬件實現(xiàn)WSN2530DK是采用TICC2530芯片開發(fā)的ContikiIPv6/6LOWPAN專業(yè)開發(fā)套件，工作在2.4GHzISM頻段，基于windows下的IAREW8051集成開發(fā)環(huán)境，已移植Contiki源代碼、驅(qū)動代碼和協(xié)議棧。WSN2530DK簡介WSN2530DK支持開放的IPv6/6LOWPAN無線網(wǎng)絡(luò)，從此徹底擺脫復雜難懂的Zigbee協(xié)議，技術(shù)在國內(nèi)領(lǐng)先。具有以下優(yōu)勢：1）完全基于Windows開發(fā)WSN2530DK配套開發(fā)環(huán)境以及開發(fā)工具均能夠運行在Windows系統(tǒng)，可以充分利用windows友好的圖形界面，免去原生態(tài)Contiki需要在Linux下輸入命令進行開發(fā)的痛苦，免去開發(fā)者學習Linux的煩惱，降低學習難度，加快開發(fā)速度。2）IAREW8051集成開發(fā)環(huán)境IAR功能強大，編譯器成熟穩(wěn)定，并支持8051、MSP430、ARM等幾乎所有的微處理器，而原生態(tài)的Contiki采用SDCC或者gcc編譯器，存在很多Bug，對于新手而言，簡直是噩夢，很多時候遇到問題不知道是代碼錯誤還是編譯器有問題，對于產(chǎn)品開發(fā)風險很大。3）專業(yè)的sniffer工具sniffer工具與著名的協(xié)議分析軟件Wireshark配套使用，構(gòu)成專業(yè)的網(wǎng)絡(luò)分析工具，能夠分析6LOWPAN，還能夠分析Zigbee，功能十分強大，是網(wǎng)絡(luò)分析、調(diào)試、部署和診斷的必備利器。4）提供網(wǎng)絡(luò)拓撲顯示工具WSNNetworkMonitor網(wǎng)絡(luò)拓撲顯示工具，提供友好的圖形界面，實時顯示網(wǎng)絡(luò)中節(jié)點組網(wǎng)的拓撲結(jié)構(gòu)、拓撲的變化、網(wǎng)絡(luò)鏈路的好壞等，輔助用戶直觀理解組網(wǎng)的過程，是網(wǎng)絡(luò)開發(fā)的必備工具。5）提供windows下的網(wǎng)關(guān)工具winslip6網(wǎng)關(guān)工具，可以將節(jié)點虛擬成電腦上的網(wǎng)口接口，只要在電腦上開啟路由轉(zhuǎn)發(fā)功能，就可以實現(xiàn)6LOWPAN網(wǎng)絡(luò)和計算機網(wǎng)絡(luò)之間路由和數(shù)據(jù)交換，用戶可以輕松ping節(jié)點，或者Web訪問節(jié)點。CC2530SOC芯片CC2530是用于2.4GHzIEEE802.15.4、ZigBee和RF4CE應用的一個真正的片上系統(tǒng)（SoC）解決方案。它能夠以非常低的材料成本建立強大的網(wǎng)絡(luò)節(jié)點。CC2530結(jié)合了領(lǐng)先的RF收發(fā)器的優(yōu)良性能，業(yè)界標準的增強型8051CPU，系統(tǒng)內(nèi)可編程閃存，8KBRAM和許多其它強大的功能。CC2530有四種不同的閃存版本：CC2530F32/64/128/256，分別具有32/64/128/256KB的閃存。CC2530具有不同的運行模式，使得它尤其適應超低功耗要求的系統(tǒng)。運行模式之間的轉(zhuǎn)換時間短進一步確保了低能源消耗。其引腳如圖6.1所示，具有以下優(yōu)勢：圖6.1CC2530引腳電路圖圖6.2SM2530節(jié)點硬件結(jié)構(gòu)1）市場份額最高：在無線自組網(wǎng)領(lǐng)域，國內(nèi)市場份額達80%以上，技術(shù)最成熟，資料最豐富，應用最廣泛。2）價格最低：目前芯片價格在9元以內(nèi)，只需要一片晶振，是其它方案的1/2、甚至1/5，價格占絕對優(yōu)勢。在無線模塊競爭無比激烈的今天，低成本就是最大的優(yōu)勢，這樣才能大規(guī)模應用普及。3）硬件資源豐富：集成8051內(nèi)核、256KBFlash、8KBSRAM、符合802.15.4的RF，以及豐富IO接口，完美滿足絕大多數(shù)應用場合。通常無線組網(wǎng)對處理能力要求低，片面追求硬件高配置是不科學的，會導致處理器大部分時間空閑（空轉(zhuǎn)），還會導致功耗高、芯片價格高。此外，Contiki屬于非搶占的類似于線程的操作系統(tǒng)，本質(zhì)上不適合主頻高的處理器，不適合做復雜的運算。4）整體功耗低：好的方案不是看局部功耗或性能，而是看整體的效果。CC2530芯片高集成度，整體休眠功耗低于1uA，整體功耗低，而其它方案，如MCU+RF雙芯片，通常RF功耗低，MCU功耗很高，總體功耗較高，而且兩個芯片的休眠喚醒管理很復雜，喚醒時間長，需要設(shè)計復雜的休眠算法，整體平均待機功耗通常在1uA~20uA之間。5）軟件開發(fā)簡單：CC2530使用廣泛，中英文資料以及相關(guān)代碼超級多，容易上手，此外，CC2530專門為協(xié)議開發(fā)進行深度優(yōu)化，增加了協(xié)議定時器、AES、地址過濾等高級功能，與射頻數(shù)據(jù)交互更加方便，硬件支持各種低功耗模式，大大降低軟件開發(fā)難度，而其它如MCU+RF方案，則需要軟件實現(xiàn)AES加密和解密（很耗CPU）、與射頻交互復雜、驅(qū)動開發(fā)難，同時導致處理的功耗高。WSN2530DK硬件組成WSN2530DK包括SM2530節(jié)點4個、SmartRF04EB仿真器（1個），以及配套的數(shù)據(jù)線等配件。4個節(jié)點中，1個可以作為網(wǎng)關(guān)（Borderrouter），其余3個可作為普通節(jié)點。所有4個SM2530節(jié)點通過燒寫sniffer固件，均可作為抓包工具使用。SM2530節(jié)點硬件均配置高質(zhì)量的虛擬串口，可以連接電腦使用USB供電和打印調(diào)試信息，或者代替Dongle節(jié)點作為Sniffer或者網(wǎng)關(guān)，十分靈活方便。同時節(jié)點均配有電池盒，可安裝2節(jié)5號電池，便于組網(wǎng)測試。硬件結(jié)構(gòu)如圖6.2所示：SM2530節(jié)點主要組成部分如表6-1所示。表6-1SM2530節(jié)點主要組成部分組成部分數(shù)量說明核心芯片CC2530F2561節(jié)點核心無線SOC芯片，含MCU和RF，256KB的Flash、8KB的SRAM，2個UART/SPI串行接口，具有多種低功耗模式，射頻符合IEEE802.15.4標準，最大可編程輸出功率4.5dBm，QFN40封裝。虛擬串口1將USB接口虛擬化為一個串口。通過串口助手等工具傳輸數(shù)據(jù)，主要用于輸出代碼調(diào)試信息。時鐘晶振132K頻率的時鐘晶體振蕩器，易于實現(xiàn)低功耗休眠以及喚醒。32M晶振1用于MCU高速處理以及無線數(shù)據(jù)收發(fā)。JTAG插針1用于下載程序和調(diào)試程序。用戶按鍵1用戶可控制的按鍵，可用于產(chǎn)生外部中斷、脈沖等。復位按鍵1對系統(tǒng)進行復位。撥動開關(guān)2兩個撥動開關(guān)，用于選擇供電方式。I/O引腳12未使用的12個I/O引腳，用戶可自定義功能。電源電路SM2530節(jié)點有三種供電方式，其硬件電路圖如圖6.3所示，供電方式的選擇如表6-2所示。復位電路復位電路如圖6.4所示。當用戶按下SW1時，系統(tǒng)重新開始運行，進行初始化和相應的事件處理。復位電路只要是為了防止程序跑飛等。圖6.3SM2530節(jié)點電源電路圖6.4復位電路表6-2SM2530節(jié)點供電方式S1狀態(tài)S2狀態(tài)供電方式任意OFF/JTAGJTAG供電BATON電池供電USBONUSB供電USB_UART電路USB_UART電路如圖6.5所示，主要實現(xiàn)USB和串口之間的轉(zhuǎn)換，核心芯片是CP2012。要利用該芯片實現(xiàn)USB和串口之間的轉(zhuǎn)換，需要在PC機上安裝相應的驅(qū)動程序。圖6.5USB_UART電路圖JTAG電路JTAG電路如圖6.6所示，主要完成程序的下載，這里采用10針的下載線，配套SmatrRF04仿真器進行程序下載。同時JTAG還具有供電的功能。圖6.6JTAG電路IO擴展引腳WSN2530DK提供了12個IO口，用戶可以自己定義相關(guān)的功能，進行擴展，如圖6.7所示。圖6.7IO擴展引腳電路圖系統(tǒng)整體設(shè)計該系統(tǒng)主要包含信息采集模塊和終端控制模塊兩部分，兩模塊之間通過miniUSB相連，整體設(shè)計圖如圖6.8所示。其中信采集模塊主要完成基本信息的采集如溫度、濕度和光照，并且執(zhí)行終端的相關(guān)命令，完成相應的控制工作。終端控制模塊主要完成數(shù)據(jù)的友好、可視化顯示，使得客戶能夠清楚的觀察到當前采集的各種數(shù)據(jù)，并通過相應的命令控制各個節(jié)點。圖6.8系統(tǒng)整體設(shè)計數(shù)據(jù)采集在這一部分，各個節(jié)點通過無線的數(shù)據(jù)傳輸方式，將采集到的數(shù)據(jù)傳送到匯聚節(jié)點，并完成匯聚節(jié)點從上位機收到的控制命令。在這里我們將contiki系統(tǒng)移植在IAR下進行程序的編寫和配置，使節(jié)點之間完成通信，并在上位機通過coap來控制和訪問傳感器節(jié)點。匯聚節(jié)點圖6.9SmartRF燒寫程序我們在SM2530節(jié)點中選擇一個節(jié)點作為匯聚節(jié)點，通過SmartRF軟件將程序燒寫到匯聚節(jié)點，如圖6.9所示。在燒寫程序時，仿真器的一端通過AB型USB和PC相連，一端通過10針的JTAG和SM2530節(jié)點相連，如圖6.10所示，在這里我們需要將仿真器復位一次，使指示燈狀態(tài)為綠色。匯聚節(jié)點燒寫hex文件rpl-coap-brouter.hex。圖6.10程序燒寫的連接方式信息采集節(jié)點信息采集節(jié)點主要完成節(jié)點周圍相應數(shù)據(jù)的采集，并將數(shù)據(jù)通過無線的方式發(fā)送給匯聚節(jié)點，同時完成來自上位機的控制命令。我們將SM2530的其他節(jié)點都作為信息采集節(jié)點，燒寫采集信息的程序，我們加入自己的代碼，來采集溫度、濕度和光照，并完成節(jié)點上的LED燈和按鍵的控制，程序代碼詳見附錄III。在這里我們通過IAR編寫、編譯程序，生成hex文件，再通過SmartRF軟件完成節(jié)點程序的燒寫。燒寫完畢后，整個網(wǎng)絡(luò)結(jié)構(gòu)如圖6.11所示。圖6.11網(wǎng)絡(luò)結(jié)構(gòu)圖終端控制上位機環(huán)境配置border通過虛擬串口與電腦連接，通過SLIP協(xié)議與電腦交互，電腦上通過winslip6軟件模擬一個虛擬網(wǎng)口，實現(xiàn)與6LOWPAN網(wǎng)絡(luò)之間的通信。1）使用devcon生成Loopback接口下載和系統(tǒng)相配的devcon文件，這里選擇64位的版本，將該文件拷貝到windows安裝目錄：C:/windows/system32文件夾中。然后以管理員身份運行命令提示符，在命令行中輸入如下命令：devcon.exeinstall%windir%\inf\netloop.inf*msloop該命令將在電腦上生成一個Loopback網(wǎng)絡(luò)接口。運行后的結(jié)果如圖6.12所示。然后執(zhí)行ipconfig/all，顯示出電腦上的網(wǎng)絡(luò)接口信息，在電腦上多出如圖6.13所示的網(wǎng)絡(luò)接口，接口描述為：MicrosoftLoopbackAdapter，物理地址為：02-00-4C-4F-4F-50，我們通過此物理地址訪問該網(wǎng)絡(luò)。重啟電腦，上述網(wǎng)絡(luò)接口才能生效。圖6.12生成一個Loopback網(wǎng)絡(luò)接口圖6.13生成的網(wǎng)絡(luò)接口2）使用winslip6實現(xiàn)通信下載開發(fā)工具winslip6，將下載文件夾放置在一個特定的目錄下，如D:\winslip6。主要方便在命令行中輸入文件夾名字。以管理員權(quán)限打開命令提示符，進入到開發(fā)工具winslip6所在的目錄。通過設(shè)備管理器查看匯聚節(jié)點所在的端口號，這里是COM3口，保證匯聚節(jié)點和電腦連接完好，并且整個網(wǎng)絡(luò)正常運行。然后輸入如下命令：winslip6-sCOM3-baaaa::-aaaaa::1/12802-00-4C-4F-4F-50-sCOM3指定所使用的串口設(shè)備，-baaaa::是將6LOWPAN網(wǎng)絡(luò)的IP地址前綴設(shè)置為aaaa::，-aaaaa::1/128是設(shè)置該Loopback網(wǎng)絡(luò)接口的IPv6址，后面的02-00-4C-4F-4F-50是Loopback網(wǎng)絡(luò)接口的MAC地址（即MicrosoftLoopbackAdapter的物理地址）。輸出結(jié)果如圖6.14所示。圖6.14Loopback網(wǎng)絡(luò)接口的連接3）輸出結(jié)果當winslip6運行之后，它在電腦里建立了到6LOWPAN網(wǎng)絡(luò)的路由表，可以進行查看。打開另一個命令符窗口cmd.exe，輸入如下命令：routePRINT-6該命令顯示IPv6的路由表，在測試機中顯示如圖6.8所示。圖6.15中可以看到“活動路由”中，有個表項：aaaa::212:4b00:53f:9476，這個IPv6地址是border的IPv6全局地址，說明電腦上已經(jīng)可以建立了到達border的路由。另外，在“永久路由”中還有一個表項，其含義是所有前綴為aaaa::/64的IP地址，電腦都將數(shù)據(jù)包轉(zhuǎn)發(fā)給aaaa::212:4b00:1d3:92e4節(jié)點，再由border轉(zhuǎn)發(fā)給6LOWPAN網(wǎng)絡(luò)中的節(jié)點。因此，和IP網(wǎng)絡(luò)一樣，只要建立了路由，就可以ping這個border節(jié)點，以及6LOWPAN中的其它節(jié)點。圖6.15IPv6的路由表在命令提示符窗口輸入命令：ping-6-taaaa::212:4b00:53f:9476其中后面的IP地址為border的全局IPv6地址。輸出結(jié)果如圖6.16所示。圖6.16pingborder節(jié)點在這里也可以ping信息采集節(jié)點，會得到相同的回復信息，我們通過虛擬網(wǎng)絡(luò)接口以及winslip6工具，實現(xiàn)了6LOWPAN網(wǎng)絡(luò)與IPv6網(wǎng)絡(luò)之間的互聯(lián)互通。Web瀏覽器訪問控制節(jié)點接入互聯(lián)網(wǎng)是6LOWPAN相對于其它協(xié)議的重要優(yōu)勢，IETF組織制定了基于CoAP的輕量級Web服務(wù)，能夠與HTTP快捷互換。6LOWPAN節(jié)點實現(xiàn)CoAP服務(wù)器，提供給外部訪問，電腦作為CoAP的客戶端，通過網(wǎng)關(guān)訪問節(jié)點上的數(shù)據(jù)。電腦上需要安裝firefox瀏覽器和Copper插件，這樣就能夠?qū)崿F(xiàn)客戶端的功能。我們以信息采集節(jié)點aaaa::212:4b00:53f:8f8c來說明。1）啟動設(shè)備在完成之前的Loopback網(wǎng)絡(luò)接口的配置和通過命令提示符訪問后，啟動安裝有Copper插件的firefox瀏覽，在地址欄中輸入coap://[aaaa::212:4b00:53f:8f8c]:5683。其中coap為傳輸協(xié)議，aaaa::212:4b00:53f:8f8c位信息采集節(jié)點的全局IPv6地址，5683為coap協(xié)議的端口號。點擊Discover得到如圖6.10所示的資源信息，可以看出，能通過匯集節(jié)點獲得采集節(jié)點采集的數(shù)據(jù)，也能夠通過電腦控制采集節(jié)點實現(xiàn)相應的操作。2）信息采集我們可以通過GET方法獲取節(jié)點采集的數(shù)據(jù)，在這里我們可以獲取溫度temperature、濕度humidity和光照light。獲取溫度的方法如圖6.11所示，首先點擊sensors中的temperature，然后點擊GET就可以可到溫度值。濕度和光照的獲取方法類似與溫度的獲取方法。圖6.17firefox瀏覽器