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

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

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

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

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

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

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