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

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

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

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

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

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