以 CoAP 為基礎運用於異質物聯網 環境中的自動服務整合與遞送機制

國立臺中教育大學資訊工程學系碩士論文

以 CoAP 為基礎運用於異質物聯網

環境中的自動服務整合與遞送機制

A CoAP-Based Transparent Service

Integration and Delivery Mechanism in

Heterogeneous IoT Environment

指導教授：林嬿雯 博士

研究生：侯善尹 撰

中華民國一百零三年七月

摘要

隨著物聯網應用越來越普及，在未來將會有非常多異質的通訊技術與設備共存於物 聯網中，所以必須要整合這些通訊技術與設備使其能夠互通，IPv6 即為目前被視為可 能的解決方案之一。在本文中，我們設計了一個 6LoWPAN 環境，並設計適用於 6LoWPAN 環境的閘道器來進行雙向的接收與轉發 6LoWAPN 封包，閘道器能將封包轉 為目的地節點所能接收的正確封包格式。因此，物聯網環境節點間的無縫雙向端對端通 訊將可達成。此外，於物聯網節點中實作 CoAP，支援 CoAP 的節點能夠記錄自身所提 供的服務，因此，使用者可以使用 CoAP 所規範的方法，使用 URI 輕易取得物聯網中 各異質能力的節點提供的服務，且可直接對節點進行操作。另外，為了因應物聯網中節 點數量相當龐大，本研究設計一平台能夠管理與儲存節點相關資訊，來讓使用者運用更 佳的便利。 關鍵詞:物聯網、6LoWPAN、閘道器、端對端通訊、CoAP

Abstract

IoT (Internet of Things) applications are more and more popular. However, heterogeneous networking technologies will co-exist in future IoT environment. IPv6 is considered as a solution to solve this problem. In this thesis, a 6LoWPAN environment is deployed, and a Gateway is designed to play as the 6LoWPAN Border Router that converts received packets into correct format and forwards them to the destination. Consequently, end-to-end communications between the nodes can be achieved in IoT. Besides, the IoT devices are designed to support the CoAP protocol in the system. Because of the CoAP, the nodes can save the service profile, and the users can use the standardized mechanism to directly access the nodes according to the profiles that are provided by nodes. Moreover, to manage the huge number of IoT nodes, a M2M platform is developed as a manager that can assist the user uses the services conveniently.

目錄

摘要………..I Abstract………II 目錄………III 表目錄………V 圖目錄………VI 第一章 緒論………1 1.1 研究背景與動機……….……….………1 1.2 研究目標……….………2 1.3 論文架構……….…………4 第二章 國內外相關研究………5 2.1 物聯網 (Internet of Things)……….………5 2.2 M2M (Machine-to-Machine)……….………5

2.3 無線感測網路 (Wireless Sensor Network)……….………6

2.4 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) .……7

2.5 於受限環境中的服務感知機制……….………9

2.6 CoAP (Constrained Application Protocol)……….………11

2.7 IPv6 與 IPv4 共存……….……….………14

3.1 系統架構……….……….………16 3.2 6LoWPAN 環境設計……….……….………25 3.3 系統伺服器設計………..…….……….……….………33 3.4 使用者應用：以家庭監控為例……….……….………33 第四章 實測結果………36 4.1 6LoWPAN 與 IPv6 封包轉換………..………33 4.2 IPv6/IPv4 穿隧………..………37 4.3 伺服器察知節點………….. ………39 4.4 Firefox CoAP 外掛套件測試……..………..………40 第五章 結論與未來展望………44 5.1 結論………..……….……….………...…44 5.2 未來展望……..………...…45 參考文獻…..………..………..………46

表目錄

Table 1：CoAP 回應碼………. 13

Table 2：Zigduino R2 硬體規格……….……….. 28

Table 3：Raspberry PI 硬體規格……….. 31

圖目錄

Figure 1(a)：Full UDP/IPv6(64-bit 定址) ………..……….. 8

Figure 1(b)：Minimal UDP/6LoWPAN(16-bit 定址)……….. 9

Figure 2：TCP/IP Stack and 6LoWPAN Stack 比較……….………. 9

Figure 3：使用情境……….……….………. 17 Figure 4：系統架構……….……….………. 19 Figure 5：系統循序圖……….……….………. 20 Figure 6：閘道器註冊……….……….………. 21 Figure 7：節點註冊……….……….………. 23 Figure 8：感測資料儲存……….……….………. 24

Figure 9：IPv6 Stateless Address Auto-configuration 於 Contiki 系統………. 27

Figure 10：閘道器穿隧流程……….……….………. 29

Figure 11：系統伺服器介面……….……….………. 33

Figure 12(a)：使用者介面：節點 4401……….……….………. 34

Figure 12(b)：使用者介面：節點 4403……….……….………. 34

Figure 13(a)：於無線 Sniffer 抓取之封包………...……….………. 37

Figure 13(b)：於閘道器抓取之封包……….……….………. 37

Figure 14(a)：於 SLIP 介面抓取之 IPv6 封包……….………. 38

Figure 15(a)：伺服器自動察知節點測寫檔……….………. 39

Figure 15(b)：CoAP 測寫檔內容……….………….………. 40

Figure 16(a)：CoAP URL………..….………. 41

Figure 16(b)：CoAP 服務察知……….….………. 42

Figure 16(c)：取得溫度………..….…...………. 42

第一章 緒論

1.1 研究背景與動機 近來，物聯網(IoT：Internet of Things)的研究引起一陣風潮，相關應用與服務受到許 多的重視，Gartner 預測 2014 年重點應用也顯示 IoT 是極具影響力的技術之一[1]。其 中，IoT 應用粗略可分為四個 Domain[2]，包括：運輸與物流、醫療照護、智慧環境、 個人與社群。然而，因為物聯網的應用多樣化，如何提供令人滿意的服務品質，仍有許 多問題尚待解決。被廣泛討論的議題包括 標準化、移動性支援、設備異質、異質通訊 協定、異質連網技術、資料異質等[2][3]。其中， 設備異質包括 Sensor、Smartphone、 PC 設備等。異質通訊協定，如 IEEE 802.15.4 (Zigbee)、IEEE 802.15.1 (Bluetooth)、 IEEE802.11(WiFi)、IEEE 802.3(Ethernet)等。異質連網技術，如 3G/4G、IPv4/IPv6 等， 資料異質包括 Json、XML、EXI 等。 M2M(Machine to Machine)機器與機器間的通訊，是物聯網中相當重要的技術之一， 由多家電信組織所組成之 oneM2M 已於 2012 年底開始在制定其標準[4]，而 M2M 的定 義即是指機器與機器之間必須有自主操作性(Autonomously Operate)，能夠以不需人為 介入的方式互相溝通[5]。於物聯網中，M2M 相當重要，若系統運作經常需人為介入是 不合用的，因此，本研究將導入 M2M 的核心概念即自主操作性，於本研究提出的方法中。 如何能夠處理物聯網的異質性，並以友善的(Friendly)、自動的(Autonomously)、透 明的(Transparently)方式提供使用者滿意的服務，是極具挑戰性的課題。為達此一目標，

本研究將物聯網中之 Zigbee 感測節點實作 6LoWPAN，並設計一能夠於 IPv4 及 IPv6 皆 能運作的 Gateway 來轉換與轉送 6LoWPAN 封包，以期能夠整合異質連網與通訊技術。 另外，以標準化的方式記錄感測節點的測寫檔(Profile)，使使用者能夠輕易依照感測節 點所提供的 Profile 來使用其所能提供的感測服務，因此，物聯網感測節點的功能異質 性將可被整合。最後，本研究設計ㄧ M2M 的系統，當新的感測節點進入特定 Gateway 服務範圍時，能夠被自動察知，並自動註冊該感測節點的 Profile 至本系統遠端 Server， 全程 M2M 以不需人為介入的方式進行。 1.2 研究目標 本論文將致力於達成以下幾個目標，包括：

 整合物聯網通訊協定異質：由於傳統無線感測網路(WSN: Wireless Sensor Network) 與網際網路通訊協定不同，WSN 無法結合於網際網路中，因此，傳統 WSN 容易成 為一個通訊孤島。為了整合 WSN 與 Ethernet 通訊協定，IETF 所制定的 6LoWPAN[6] 即是將 IEEE 802.15.4 Zigbee 與 IPv6 整合的標準，使 Zigbee 設備能夠使用 IPv6， 並可與網際網路上的設備互相溝通。本研究於感測節點上實作 6LoWPAN，使 WSN 感測節點能夠真正整合入物聯網中。

 整合物聯網連網技術異質：由於 6LoWPAN 封包為壓縮過的 IPv6 封包，因此，無 法直接於網際網路上繞送，必須經過一個 6LoWPAN 邊界路由器(Border Router)， 將 6LoWPAN 封包轉為 IPv6 封包才能於網際網路中繞送。因此，本研究於物聯網

閘道器(Gateway)實作了 6LoWPAN 邊界路由器的功能。然而，6LoWPAN 制定為 IPv6 Only，由於 IoT 環境中有許多設備，設備不一定使用 IPv6，可能造成雙方無法 溝通，因此，本研究亦於物聯網 Gateway 中實作 Tunnel 6to4[7]使 6LoWPAN 亦能 夠使用於 IPv4 環境中。

 整合物聯網感測節點功能異質：本研究於感測節點上實作 CoAP[8]，並利用 CoAP 規範的服務察知功能，以標準化的方式記錄了感測節點之 Profile，因此能夠輕易的 取得各種感測節點所提供的功能，並能以 RESTful 的架構輕易操作節點。

 實現感測節點與網際網路設備端對端通訊：由於傳統 WSN 無法與網際網路溝通， 多由中介 Gateway 結合 Zigbee Coordinator 利用 UART (Universal Asynchronous Receiver/Transmitter)傳送至 Gateway，Gateway 將資料集中整合後，轉發至網際網 路。本研究由於實作 6LoWPAN 於感測節點，並於 Gateway 中實現 6LoWPAN Border Router 功 能 ， 使 得 感 測 節 點 與 網 際 網 路 上 的 設 備 能 夠 進 行 雙 向 的 End-to-End Communication。

 設計ㄧ適用於物聯網的 M2M 平台：本研究致力開發ㄧ M2M 系統平台，用以整合 上述之成果。本研究除開發應用外，也提供平台供使用者開發相關物聯網應用。本 研究之 M2M 系統包含上述之 6LoWPAN Node、Gateway 以及遠端 Server 和資料中 心。本系統之 6LoWPAN 節點進入新的 Gateway 範圍後，會由 Gateway 自動察知， 節點與 Gateway 取得 IPv6 後即會對遠端 Server 進行註冊，Server 收到註冊訊息後， 會記錄 Node 對應的資料，例如記錄 Node Profile、開啟其所需的資料庫等。而這些

自動產生的資料即可讓開發者使用並開發相關應用。

1.3 論文架構

本論文架構如下：第一章為研究背景動機與目標。第二章相關研究將分別敘述物聯 網、M2M、傳統 WSN 與 6LoWPAN 的差異、如何使 6LoWPAN 能夠使用於 IPv4、介紹 現有的 Service Discovery 技術，最後介紹本研究選用的 Service Discovery 技術即 CoAP。 第三章將說明本研究之研究方法，分別為 M2M 系統架構與 6LoWPAN 系統架構以及實 作硬體。第四章將說明本研究之實驗結果。最後，第五章則為結論與未來展望。

第二章 國內外相關研究

2.1 物聯網 (Internet of Things)

根據 Gartner[9]預測，於 2020 年全世界設備將會爆炸成長至 26 億個，這些設備未 來將會透過網際網路互相串連，即為物聯網(Internet of Things)。若是這些設備間的溝通 與操作均需透過人的介入，將會造成極大的不便與負擔，因此，M2M 由機器與機器自 行溝通，將是物聯網中相當重要的技術。Internet of Things 的 Things 可以是智慧型裝置， 包括個人電腦、智慧手機、平板電腦、感測器等；也可能是冰箱、電視、車輛，未來也 可以是衣服、食物、藥品、書本等[10]。而為了能連上 Internet 它們必須使用可唯一的 定址方法(Addressing)，目前，IPv6 Addressing 被視為未來可能的解決方案之一[39]。

2.2 M2M (Machine-to-Machine)

於[5]中提到，Machine-to-machine (M2M)必須有自主操作性(Autonomously Operate)， M2M 機器與機器間的通訊，是物聯網中相當重要技術，因此，M2M 的發展相當快速， M2M 間的通訊方法在 2008 年即已有相關標準，由歐洲電信化標準協會(ETSI：European

Telecommunications Standards Institute)為其制定[11][12]。其中，[11]中提出相當多 M2M

需處理的難題，與本研究相關的異質內容包含，通訊協定的異質、IP 配置管理、Gateway 異質性等。且於 2012 年 7 月 3GPP 主要成員成立了 M2M 標準制定組織即 oneM2M[4]， 包含無線通訊解決方案聯盟(ATIS)、中國通訊標準化協會(CCSA)、歐洲電信標準協會 (ETSI)等等組織，致力於發展 M2M 全球通用的標準，並於 2013 年底發表的技術報告

[13][14]中，整理了各組織制定之 M2M 架構分析與該如何合併，與整理各標準制定組 織所制定的 M2M 架構。

2.3 無線感測網路 (Wireless Sensor Network)

WSN(Wireless Sensor Network)使用之 IEEE802.15.4 通訊協定，具有低頻寬、低耗 電、低成本之特性，為物聯網之感測相關應用的重要網路技術。這些 WSN 設備通常是 微小型的設備，並佈署於環境中，能自動的感知特殊情況的發生，並傳送到它們的 Coordinator[15]。這些感測器通常以 RISC 架構的 Microcontroller 為核心，擁有相當小 的記憶體空間，並配備 Zigbee RF 天線、相關應用之感測器等。RF 天線的資料，將可 經由 URAT、SPI 等 I/O 介面傳輸至 MCU 進行相對應的處理[15]。

WSN 將 Sensor 分為 FFD(Full Function Device)及 RFD(Reduce Function Device)，其 中 FFD 作為 Router 與 Coordinator 使用，RFD 為 End Device。

Coordinator 為ㄧ個 WSN PAN (Personal Area Network) 的 Root，管理 PAN 內之 Router 與 End Device。通常，Coordinator 會安裝於 Gateway，收集 PAN 下之節點所感 測的資料，經由 UART 將資料傳送至 Gateway 後，將資料彙整送至網際網路。Router 為 WSN 中之中介節點，可以將 End Device 或其他 Router 傳送資料送至 Coordinator。End Device 通常功能比 Router 與 Coordinator 還要弱，無法轉送資料，只能感測資料並傳送 至 Router 或 Coordinator。

2.4 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)

6LoWPAN [6]是由 IETF 所制定的標準，目的是為了讓 IPv6 網路協議能夠運用在微 型的 Device 上，讓低功耗的設備可連上 Internet 成為物聯網的一部分，該標準通常使用 於 IEEE 802.15.4 ZigBee，或使用其他低功耗通訊協定的 Device 例如，使用 IEEE 802.15.6 Bluetooth Low Energy[16]。6LoWPAN 以 IPv6 為基礎，支援 IPv6 的功能，包括 routing、 auto-configuration、neighbor-discovery、unicast、multicast 和 broadcast 等。在[6]中提到 IPv6 的 MTU(Maximum Transmission Unit)為 1280byte，但是 IEEE802.15.4 只擁有 127byte 的 MTU，因此必須透過分割與表頭壓縮(Header Compression)再由 Gateway 重組使 IPv6 能在 802.15.4 協定下使用。於[17]中提到，[18][19]等整理出兩種 6LoWPAN 封包格式， 分為 Full UDP/IPv6 及 Minimal UDP/6LoWPAN。其中，Full UDP/IPv6 為將完整的 IPv6 Address 和 UDP Header 放入 ZigBee 封包中，因此，如 Fig 1(a). 所示將完整 UDP 與 IPv6 Header 放入 802.15.4 封包後，IPv6 Header 已占用 40Byte 的資料，UDP Header 占用 8byte 資料，因此，Payload 只剩下 53byte 能夠運用。此外，如 Fig 1(b).所示，該圖為壓縮過 後之 6LoWPAN 封包格式，壓縮處理後的 6LoWPAN 封包較適合在 IEEE 802.15.4 協定 傳輸，經過壓縮後，能夠擁有 108 bytes Payload 放置資料。但支援 6LoWPAN 的小型節 點作業系統所送出的 6LoWPAN 封包並不一定完全符合該標準，詳細將於 4.1 節中說 明。

MAC FCS

1 byte 53 byte 4 byte

L _IPv6 UDP Payload

8 byte 40 byte

21 byte

Fig. 1(a). Full UDP/IPv6(64-bit 定址)[17]

MAC FCS

2 byte 108 byte 4 byte

L UDP Payload

4 byte 9 byte

Fig. 1(b). Minimal UDP/6LoWPAN(16-bit 定址)[17]

2.4.1 TCP/IP Stack and 6LoWPAN Stack Comparison

本節介紹傳統 TCP/IP Stack 與 6LoWPAN Stack 的差異，如 Fig 2.所示，根據[17]整 理，依照本文的架構再做細微修改。

 Physical 層與 Data Link 層：TCP/IP Stack 支援 IEEE 802.3 Ethernet 而 6LoWPAN 為 IEEE 802.15.4 Zigbee。

 Network 層：6LoWPAN Stack 相較於 TCP/IP Stack 多出了 6LoWAPN Adaptive 層， 用以將 6LoWPAN 格式的封包轉為 IPv6 封包，且 6LoWPAN Stack 並不支援 IPv4。  Transport 層：因為 6LoWPAN 為有限制的環境，而 TCP 協定中的三方交握等需要

穩定的網路環境，因此，TCP 並不適合使用於 6LoWPAN Stack。

 Application 層：TCP/IP Stack 使用 HTTP 協定，和其他未列出之協定，如 FTP、RTP 等；6LoWPAN Stack 中，CoAP 於 2014 年六月制定完 RFC[8]，於本研究中，CoAP 協定已實作於本研究之 6LoWPAN Node 中，詳細說明將於 2.5 節闡述。

Fig. 2 TCP/IP Stack and 6LoWPAN Stack 比較[17]

2.4.2 SLIP (Serial Line Internet Protocol)

SLIP(Serial Line Internet Protocol)[20]並非是新的技術，早於 1988 年，RFC1055 即 制定完成，SLIP 的制定是為了使點對點傳送的 Serial Line 連接能夠使用 TCP/IP Stack 的協定，最早使用的 Modem 撥接網路即為使用 SLIP 協定的上網方式。於 Contiki 系統 中 SLIP 即被使用來將 6LoWPAN 封包轉為 IPv6 封包。

2.5 於受限環境中的服務感知機制

目前大多數 IP-Based 的 Discovery Protocol 都是為了在傳統有線網路的環境下所訂 製 的 協 定 [21] ， 包 括 SLP(Service Location Protocol) 、 UDDI(Universal Description, Discovery, and Integration)、SSDP(Simple Service Discovery Protocol)等，因為這些協定都 需要較高的頻寬與電力，但在受限的環境中電力節省是很重要的議題，在 WSN 中的節 點通常是 Processing 與 Memory Overhead 較低的設備，可能無法負荷傳統的協定。為了

因應 M2M 受限的環境，目前，已經有逐漸在制定專為 M2M 受限環境中所能使用的 Discovery Protocol 的標準，並可區分為 Non-IP based 或 IP-based 的 Service Discovery Protocol。

2.5.1 Non-IP Based Service Discovery

傳統有幾種機制能達到 Service Discovery[21]，例如，Zigbee Device Discovery，可 提供關於 Zigbee 設備的相關資訊，透過 Zigbee Device Profile (ZDP)能去識別設備的應 用程序與屬性類別，此過程可被稱為 ZDP Service Discovery。Non-IP 協定的傳輸機制， 因為 ZDP Service Discovery 的功能會被限制在低功耗網路的區域範圍內，並沒有辦法 讓遠端的使用者與設備連繫，也無法與使用異質通訊技術的設備溝通，因此，無法與外 部溝通。

2.5.2 IP Based Service Discovery

因 M2M 越來越受到重視，所以設備需要 IP 的需求日益增加，有 IP 即能透過網路 來與設備溝通，因此，目前有幾種專為受限環境下所訂製的 service discovery protocol。 在 2005 年時 Sensinode Ltd. [22]開始發展 nanoSLP 協定，此協定能夠用 WAP Binary XML (WBXML)的壓縮機制來減少 HTTP 與 SLP 目錄的繁雜度，但是 nanoSLP 並不支 援 multicast 和有所限制的搜尋能力，所以才有 Simple Service Location Protocol (SSLP) for 6LoWPAN [23]的產生。SSLP 是由 IETF Networking Group 所發展的協定，使用

Tokenized XML 字串來有效減少封包交換的次數，並使用標準的 SLP 架構來增加對 translation agents (或者稱 gateway)的能力，此協定能減少複雜度與傳輸的延遲時間，所 以能適用在 6LoWPAN 內，但於 2009 年 Draft 第二版後即無再更新[23]。最近，IETF 的 Constrained RESTful Environments (CoRE)工作組開始發展資源感知(Resource Aware)的 Service Discovery protocols，並以 REST 為基礎，並可結合現有的網路協定，例如 DNS-SD[24]。CoAP 已於 2014 年六月成為標準[8]，有輕量級的優點與以 IP 協定為基礎，保 證有效率的互操作性以及高適應性，於 2.6 節將詳細介紹 CoAP 協定。

2.6 CoAP (Constrained Application Protocol)

Constrained Application Protocol (CoAP) [8] 是 IETF CoRE (Constrained RESTful Environments)為有限制的環境 (e.g. low-power, lossy) 制定的 Web 應用層傳輸協定，例 如 6LoWPAN 即為一種典型的有限制的環境。CoAP 提供了一個 Request/Response 模組 於兩個 End Points 的應用層間。並支援 Discover 設備的 Service 以及 Resource，並以 URI 的方式下達指令。CoAP 亦支援與 HTTP 的互作性，使用者可以使用 Web 輕易的使用 CoAP，同時也擁有 Multicast 的功能與低 overhead 的特性，因此，非常適合用於有限制 的環境。然而，CoAP 並非只是盲目的壓縮的 HTTP，而是為了使 HTTP 的 REST 架構 能夠用以實現在有限制環境的 M2M 通訊上，並進行相關優化，因此，為有限制 M2M 環境提供了 Service Discovery，Multicast 與 Asynchronous Message Exchanges 等功能。 另外，CoAP 的預設 Port 為 5683，若所處的網路環境為 6LoWPAN 網路，則可以為 61616

至 61631。[8]

2.6.1 CoAP Method Code

CoAP 以 REST 架構為基礎，設計了四種 Method Code[8]，分為，GET、POST、PUT、 DELETE。介紹如下。

 GET：GET 是一種獲取資料的方法，利用 URI 向對方請求相關資源。GET 方法被 認為是安全的，由於 GET 不會更改到任何 Server 資訊。

 POST：POST 方法依賴於 Server 提供的資源，通常用於創建新的資源。POST 被認 為是不安全的方法，可能遭非法植入新的資源。

 PUT：PUT 是用於更新資料的方法，更新方法使用 URI，並於 URI 提供相關資訊， 而資訊格式必須依照系統規範。PUT 被認為是不安全的方法，因為資料可能遭到竄 改。

 DELETE：DELETE 方法用於刪除資源。DELETE 被認為是不安全的方法，資料可 能遭到非法刪除。

2.6.2 CoAP Response Codes

由於 CoAP 為 REST 架構，因此，Server 回應之 Code 與 REST 架構相似，例如，於 REST 架構中，網頁無法找到時，會出現 404 Not Found，於 CoAP 中也是使用此方式回應， 但由於在有限制的環境中必須節省 Payload Byte 使用量，因此，CoAP 會使用編碼的方

式傳送 Response Codes，並非如 HTTP Response 不編碼直接傳送，CoAP 是將 Response Codes 編碼入 1byte 中再進行傳送。以 412 Precondition Failed 為例，會將 412 分為 4.12， 即為 4 與 12 兩個區塊。套入公式 x*32 + y 中，4*32 + 12 = 140，轉為 16 進位後，以 8C 進行傳送。CoAP 所規範之 Response Code 如 TABLE 1.所示。

Table 1 CoAP 回應碼 [8] Code Description 2.01 Created 2.02 Deleted 2.03 Valid 2.04 Changed 2.05 Content 4.00 Bad Request 4.01 Unauthorized 4.02 Bad Option 4.03 Forbidden 4.04 Not Found

4.05 Method Not Allowed 4.06 Not Acceptable 4.12 Precondition Failed 4.13 Request Entity Too Large 4.15 Unsupported Content-Format 5.00 Internal Server Error

5.01 Not Implemented 5.02 Bad Gateway

5.03 Service Unavailable 5.04 Gateway Timeout

2.7 IPv6 與 IPv4 共存

根據 Google Statistics 統計[25]，至 2014 年七月中為止，連上 Google 的 IP 中 IPv6 最高峰僅占 4.11%，由於 6LoWPAN 為 IPv6 only 的協定，因此，若要使 6LoWPAN 適 用於物聯網，適當的轉換將為必要的。於[26]中介紹了兩種使 IPv6 與 IPv4 能夠互通的 方法。分別為 NAT64 結合 DNS64 與 Tunnel 6to4 兩種方法，介紹如下。

2.7.1 NAT64 with DNS64

NAT64[27]與 DNS64[28]是讓只有 IPv4 功能的設備能夠與只有 IPv6 功能的設備互 相溝通。在封包經過 NAT 作轉換時會將原始的 Header 進行轉換，破壞了設備所送出的 原始封包格式。例如 IPv6 Header 經過 NAT 後將會被轉換為 IPv4 Header。於 IoT 中， 由於對節點定址的需求，轉換封包 IP 將會遺失節點原始的 IPv6，因此，是不被推薦的 作法。

2.7.2 Tunnel 6to4

Tunnel 6to4[7]是使擁有 IPv6 能力但位於 IPv4 環境的設備所制定的標準，該標準能 夠讓位於 IPv4 環境中且有 IPv6 能力的設備能夠連上 IPv6 網路。Tunnel 6to4 的原理是 將 IPv6 封包封裝於 IPv4 Header 內，使該封包能夠於 IPv4 網路上傳送。當封包跨越 IPv4 進入 IPv6 時，將會越過 IPv6 Rely，IPv6 Rely 便會將 IPv4 Header 解封裝，並取出 IPv6 封包，使其傳送於 IPv6 網路中。此種封包稱為 6to4 封包，於 RFC[7]中規定該封包 Prefix

必須為 2002::/16。由於 Tunnel 6to4 並不會破壞設備原始 Header，因此，於本研究中選 用 Tunnel 6to4 實作於 Gateway 中，使得 6LoWPAN 封包能夠使用者 IPv4 網路。

第三章 研究方法

在物聯網的環境中存在許多設備，包含功能限制的設備(如 Sensor)及完整功能且可 自行連上網際網路的設備(如手機)，本文主要以微小型 Zigbee 設備作為處理物聯網異 質的對象。於物聯網中，這些微小型設備依照所使用的感測器、應用方式、使用情境會 產生不同的功能與應用，因此，這些微小型設備通常為異質的，包括連網技術、通訊技 術、感測功能等。傳統上這些微小型設備所使用的網路技術，與網際網路通常是不同的， 容易變成一座通訊孤島。而這些微小型設備所提供的功能並不相同，因此，必須有ㄧ機 制來記錄微小型設備的 Profile，用以得知這些微小型設備所提供的服務。 本文將針對上述微小型設備的異質性進行適當的處理，處理的異質包括通訊協定異 質、連網技術異質、設備異質。其中，通訊協定異質包括 IEEE 802.3(Ethernet)、IEEE 802.11(WiFi)與 IEEE 802.15.4(Zigbee)以 IP 的方式整合使其能夠互相溝通。連網異質為 物聯網中各個設備可能使用不同技術連上網路，包括 IPv4、IPv6、3G/4G。設備異質則 為物聯網中各個設備可能擁有不同的服務能力，因此，本研究以標準化的方式記錄 Profile 以進行服務能力的整合。

3.1 系統架構

3.1.1 使用者情境 本研究典型的使用情境如 Fig. 3 所示，以智慧環境為例，使用者希望能夠從 Server 或微小設備讀取智慧環境的感測資料，但使用者可能與 Server 以及 Sensing 環境使用異 質的網路技術，因此，系統設計目的是讓使用者不論在哪個環境都可以順利讀取到資料。 並加以利用資料，甚至可以直接對微小型設備進行控制。 Fig. 3 使用情境 3.1.2 設計者系統架構 本研究致力於設計一能適應於 IP 為基礎之物聯網環境 M2M 平台，並能以此平台 為基礎開發相關應用程式，系統架構如 Fig. 4 所示，分為 IPv6、IPv4 與 6LoWPAN 網 路環境，由於本系統之 6LoWPAN Gateway 能夠適用於 IPv4 與 IPv6 環境，因此，於 IPv6

IoT Server

Internet(IPv4/IPv6)

Data Center

End User IoT Gateway

感測資訊至 IPv6 或 IPv4。且不論終端位於 IPv4 或 IPv6 也可利用 IP 對節點進行操控， 如 End User 或 Server 可使用 CoAP 協定對節點進行控制。

本系統角色包括 Server、6LoWPAN Node、 IoT Gateway 與 Data Center 等，能夠 適應異質網路環境，且當新的 6LoWPAN Node 加入本系統 IoT Gateway 的服務範圍後， 系統能夠自動察知其服務能力。並給予其適當的資料存儲空間給予後續使用者使用。以 下將介紹系統中各個角色的功能。

 6LoWPAN Node：負責環境感測之 Zigbee 節點，以 Contiki 2.6 設計，支援 6LoWPAN 與 CoAP，詳細於 3.2.2 節介紹。

 IoT Gateway：支援 6LoWPAN Border Router 功能且能夠查知 Server 以及自身所在 網路環境(IPv6 或 IPv4)，為 6LoWPAN 封包作適當的轉換與轉送以對應 IoT 的通訊 及連網異質性，詳細於 3.2.3 節介紹。

 Server：系統中央控管程序，架設於遠端之網際網路，能夠接收 Gateway 所轉送的 6LoWPAN 封包，並作適當的處理。於新節點加入時能夠接收節點的註冊訊息以及 察知節點所能提供的服務(Profile)，詳細於 3.3 節介紹。

 Data Center：M2M 系統資料儲存中心，儲存 Gateway、6LoWPAN Node 的相關資 訊。

 End User：不需知道系統中間的繁複程序，只需使用 M2M 系統所產生的資料即可 使用相關應用。

Fig. 4 系統架構

3.1.3 系統訊息流程

本系統簡易循序圖如 Fig. 5 所示，依序可分為五個階段，包括：Gateway Registration、 Node Joining、Node Registration、Sensed Data Storage、User Access。以下將分別進行介 紹。

 Gateway Registration：若欲使用本系統，Gateway 的註冊是必需的，由於 Gateway 為每個 6LoWPAN 感測環境中之中介點與管理節點的角色，容易發生安全性問題， 因此，於本系統設計 Gateway 註冊必須經過系統管理者審核後，由系統管理者註冊 至本系統後再發行至感測環境中。

 Node Joining：本系統的 Gateway 能夠自動偵測符合本系統設定的 6LoWPAN Node， 當新的 Node 欲加入 Gateway 所管轄的環境時，Gateway 能夠自動察知 Node 加入。 且 Node 取得 Gateway 的 Prefix 後即能 Auto-Configuration 出 IPv6 Address，詳細方 法將於 3.1.3.2 節說明。

6LoWPAN

IPv4

IPv6

6LoWPAN

IoT Gateway (Prefix Provider)

IoT Gateway (Prefix Provider) IPv6 Rely Join PAN IoT Server Data Center End User End User IoT Server Data Center

發送註冊訊息，當 Server 收到註冊訊息後便會使用 CoAP 察知 Node 的服務能力後 記錄，並於資料中心開啟相對應的資料儲存空間。

 Sensed Data Storage：當 Node 註冊完成後，便會開始因事件發生回報或定期回報所 配備之感測器相關資訊至 Server，並由 Server 儲存至資料中心。

 User Access：使用者或應用程式開發者即可使用這些由系統自動產生的資料進行相 關應用的開發。

Server Data Center 6LoWPAN Node

Save Node IoT Gateway

Join DAG Provide Prefix Auto Configuration IPv6

Registration Get Node Service Profile

Content _{Save Node Profile}

End User

Sensed Data Periodically/On Demand

Save Sensed Data

Read Sensed Data Read Profile Advertisment

Create Data Table Registration _{Save Gateway}

1 2 3 4 5 Fig. 5 系統循序圖 3.1.3.1 閘道器註冊(Gateway Registration) 本節將詳細介紹 Gateway 註冊流程，於本系統中，Gateway 的審核與註冊是必需的， 由於安全性的考量，Gateway 將由系統管理員由 Server 中特定之介面新增至本 M2M 系

所發送的封包，將會進行封包的過濾以確保系統的安全性。本系統之 Gateway 新增模組 之循序圖如 Fig. 5.第一區塊所示，詳細系統流程如 Fig. 6 所示，由系統管理員輸入 Gateway 相關訊息後，系統便會自動判斷該 Gateway 是否已被註冊，若有則跳出，若無 則判斷註冊成功，並將 Gateway 相關資料寫入資料中心，經過該步驟後，Gateway 即可 用於本系統。 Gateway Registration Exists? No Registration Success Save Gateway Profile Yes A lr ea d y E x is t E rr o r End Fig. 6 閘道器註冊 3.1.3.2 節點加入 (Node Joining)

IPv6 Address 形成方法是使用 IPv6 Stateless Address Auto-configuration [29]，Node 進入 Gateway 的服務範圍後，將會收到 Gateway 的廣告信(Advertisement)，並加入該 Gateway， 於廣告信中 Gateway 會提供 Node 該 Gateway 的 Prefix，Node 即可使用此 Prefix 進行 IPv6 Auto-Configuration，循序圖如 Fig. 5 第二區塊所示，詳細 Auto-Configuration 方法 將於 3.2 節說明。

3.1.3.3 節點註冊 (Node Registration)

如 Fig. 5 第三區塊所示，本節將介紹 Node 註冊過程，詳細系統流程圖如 Fig. 7.所 示，當 6LoWPAN Node 組合完 IPv6 Address 後，即會發送註冊系統之 6LoWPAN UDP 封包，當 Gateway 收到後，會透過 Gateway 中之 SLIP 介面轉為 IPv6 封包，而基於安 全性問題，會再由防火牆判斷該 Node 所產生的封包 Prefix 是否與 Gateway 相同，若相 同則通行，不相同則丟棄。判斷完成後，合法的封包將發送至本系統之 Server，當 Server 收到該訊息後，便會再進行ㄧ次封包過濾，判斷此封包 Prefix 是否與已註冊至 Server 的 Gateway 相同，以確保安全性問題。若上述之安全判斷皆通過後，Server 即會查詢資料 中心該 Node 是否已註冊過，若是，則可能是攻擊行為並予以丟棄。否則將會依照 Node 的 Prefix 加入同一 Prefix 的 Gateway 關聯資料表中，代表為該 Gateway 管轄範圍中之 Node。於上述步驟後，Server 將會自動發送 CoAP Discover 的封包至 Node，用以察知 Node 所能提供的 Service Profile，並記錄於資料庫中，而 Server 亦會依照該 Node 所提 供的 Service Profile 來開啟對應的資料表，給予該 Node 專用。

Node Registration Server Node Exists? An Illegal Registration Data Drop End According to Profile Create Node Dedicated Table Discovery Node Profile Gateway Node.Prefix==Gateway.Prefix? Yes No An Illegal Registration Data Drop Yes No Add Node to Gateway According to Prefix No Yes Node.Prefix==Registered Gateway.Prefix? Fig. 7 節點註冊

3.1.3.4 感測資料儲存 (Sensed Data Storage)

如 Fig. 5.第四區塊所示，本節將介紹 Node 發送感測資料之過程，詳細系統流程圖如 Fig.8 所示。6LoWPAN Node 會定期發送包含感測資訊的 6LoWPAN UDP 封包，當 Gateway 收到後，會透過 Gateway 中之 SLIP 介面轉為 IPv6 封包，基於安全性問題，會

相同則丟棄。判斷完成後，合法的封包將由 Gateway 發送至本系統之 Server，Server 收 到該訊息後，便會再進行ㄧ次封包過濾，判斷此封包 Prefix 是否與已註冊至 Server 的 Gateway 相同，以確保安全性問題。若上述之安全判斷皆通過後，該感測封包即會記錄 到於 Node 註冊時為其開啟的專用資料表，以供後續使用者查詢。 Node Sensed Data Gateway Server Yes No Yes Save Data to Table End An Illegal Sensed Data Drop Node.Prefix==Gateway.Prefix? Node.Prefix==Registered Gateway.Prefix? An Illegal Sensed Data Drop No Fig. 8 感測資料儲存

3.1.3.5 使用者存取 (User Access)

如 Fig. 5 第五區塊所示，使用者只需於資料庫讀取系統所記錄的 Profile 與感測資訊即 可使用本系統。另外，若有需求，使用者也可直接訪問節點並使用 CoAP 取得相關資訊。

3.2 6LoWPAN 環境設計

3.2.1 6LoWAPN System Architecture

如 Fig 4. 所示，以 IoT Gateway 分界，6LoWPAN Network 為內網，而 IPv4 以及 IPv6 為 外網，6LoWPAN Node 將感測到的資料使用 IEEE 802.15.4 協定將 6LoWPAN 格式的封 包傳至 Gateway，並由 Gateway 接收後將 6LoWPAN 封包經過 SLIP(Serial Line Internet Protocol)轉為 IPv6 的封包。若 Gateway 位於 IPv6，則直接將封包送出，若 Gatway 位於 IPv4，則會將封包封裝入 IPv4 Header，並使用 IPv4 Header 中 Protocol 欄位，將其設定 為 41 表示原始封包為 IPv6 封包，並於 IPv4 網路上傳送。詳細步驟將於下節說明。

3.2.2 6LoWPAN Node Design

3.2.2.1 6LoWPAN Node Functionality

作為於環境中的感測節點，能夠因配備的 Sensor 不同，感測不同的資訊，例如溫濕度、 二氧化碳、水位等。本研究於 Node 中實作 6LoWPAN 使其能夠與 Internet 真正互通， 並且在 Node 上實作 CoAP，用於記錄 Node 之 Profile，且能夠讓使用者直接利用 CoAP 來 Access Node，進行控制與讀取即時感測資料。另外，本研究之新的 Node 進入新環

境時，即會對 Server 進行註冊，Server 即會將 Node 的 CoAP Profile 儲存於資料中心。

3.2.2.2 6LoWPAN Node Operation System

本研究之 6LoWPAN 感測節點選用 Contiki 2.6 作為本研究的感測節點作業系統， 6LoWPAN 雖已有 RFC [6]，但時至目前 6LoWPAN 並沒有真正標準化，目前市面上有 相當多微小 Device OS 支援 6LoWPAN 但封包格式仍與 RFC 制定規格有所差異。而這 些作業系統包括 Contiki、TinyOS、FreeRTOS、JeNet Proprietary[30]等，其中，FreeRTOS Platform 必須使用 Sensinode；而 JeNet Proprietary Platform 必須使用 Jennic node；Contiki OS 與 TinyOS 所使用的 Platforms 較有彈性，相對於 TinyOS[31]越來越多廠商之 Platforms 支援 Contiki[32]，且路由器最大廠商 Cisco 亦表態未來將支援 Contiki，因此，本研究亦 選用 Contiki 作為 6LoWPAN Node 的作業系統。

3.2.2.3 6LoWPAN Node IPv6 Auto-Configuration

於本研究中，6LoWPAN Node 使用 Contiki 系統來完成，於 Contiki 系統中，6LoWPAN Node 組合 IPv6 的方式是使用 IPv6 Stateless Address Auto-configuration[29]的方式，組合 IPv6。簡單範例如 Fig. 9 所示，Node 的 Zigbee MAC Address 為 02:11:22:ff:fe33:44:04， Gateway 設定之 IPv6 Address 為 2002:786c:cd24:2::2，因此，Prefix 為 2002:786c:cd24:2::/32。 6LoWPAN Node 透過 Advertisement 取得該 Prefix 後即可進行 IPv6 組合，如 Fig. 9 所 示，組合完成的 IPv6 Address 為 2002:786c:cd24:2:11:22ff:fe33:4404，該 IP 為 Global 可

使用的 IP，可用於 Internet，意即可由 Internet 中任意地區對 Node 進行雙向的溝通。

Fig. 9 IPv6 Stateless Address Auto-configuration 於 Contiki 系統

3.2.2.4 6LoWPAN Node System Implementation

本研究選用 Zigduino[33]作為本研究之 6LoWPAN Nodes，於 Git Hub 已有 maniacbug 為 其撰寫 Contiki 硬體層 Platform[34]，但只支援至 Contiki 2.5 版，由於舊版本所產生之 6LoWPAN 封包無法與新版互通，本系統為使其互通已成功將其移植至 2.6 版，使其能 夠與本系統之 Gateway 互通(使用 Nooliberry 作為 Sink)。Zigduino 為 Arduino 相容的微 處理器，因此能夠利用 Digital/Analog Pin 輕易的添加感測器。Zigduino 相關硬體規格如 TABLE 2 所示。

TABLE 2 Zigduino R2 硬體規格[34]

Microcontroller Atmega128RFA1 Operating Voltage 3.3V

Digital I/O Pins 30 PWM Output Pins 6

Analog Input Pins 8 (0-1.8V)

Flash Memory 128 KB , 2 KB is used by the bootloader

SRAM 16KB

EEPROM 4KB Receiver Sensitivity -100db

3.2.3 IoT Gateway (6LoWPAN Border Router) Design 3.2.3.1 Gateway Functionality

Gateway 於本系統中作為 6LoWPAN 與 Internet 的中介點，於 Gateway 中實作 6LoWPAN Border Router 的功能，能夠將 6LoWPAN 封包重組後，轉為能夠於 IPv6 上繞送之封包。 另外，由於 6LoWPAN 原本是制定 IPv6 only，無法於 IPv4 上使用，本研究亦於 Gateway 另外實作 Tunnel 6to4 的功能，使得其亦能於使用 IPv4 上。

3.2.3.1 Gateway Tunnel Process

如 Fig. 10 所示，以下將依照順序說明 Gateway Tunnel Process 的過程

(1) 6LoWPAN Nodes 傳送資料時使用 IEEE 802.15.4 的表頭封裝 6LoWPAN 格式的封包 送至安裝在 Gateway 上的 6LoWPAN Sink Node，當 Sink Node 收到封包後便將 IEEE 802.15.4 表頭解封。

(2) 將 6LoWPAN 格式的 payload 使用 UART 傳至 SLIP 虛擬網路介面。

(3) SLIP 收到 UART 所傳送的封包後會將 6LoWPAN 格式轉為正確的 IPv6 格式。若 Gateway 位於 IPv4 的環境，則會經過 Tunnel 6to4 的虛擬網路介面，將 IPv6 封包封 裝於 IPv4 Header 中。

(4) 將可以使用的封包轉送至 NIC (Network Interface Card)，由 NIC 將封包轉送至網際 網路。 6LoWPAN Sink SLIP 6LoWPAN Node NIC IPv6 Relay 6LoWPAN Node 6LoWPAN Node IPv4 Server IPv6 Server 802.15.4 UART IP Forward 802.3 Gateway 6LoWPAN Network 1 2 3 6to4 4 4 External Network Fig. 10 閘道器穿隧流程 若要使封包能夠成功於網際網路上繞送，需根據 Gateway 所處的網路的位置以及封

(1)若 Gateway 位於 IPv4 網路，封包目的地為 IPv4 位址，則封包可直接傳送。若封包目 的地為 IPv6 位址，則 IPv4 Header 的目的地必須設為 192.88.99.1，該 IP 位址為 anycast 位址，代表為 IPv6 Relay 位址，並由 IPv6 Relay 將 IPv4 Header 解封裝後取出 IPv6 封包 並轉送至 IPv6 網路。

(2)若 Gateway 位於 IPv6 網路，封包目的地為 IPv6 位址，則封包可直接傳送。若封包目 的地為 IPv4 位址，則封包必須經過 2002:c058:6301::位址(IPv6 Relay anycast)，並由 IPv6 Relay 進行位址目的地 IPv4 位址解析後將 IPv6 封包封裝入 IPv4 Header 中再轉送至 IPv4 網路。

3.2.3.2 Gateway System Implementation

本系統 採用 Raspberry PI[35]並外掛 Nooliberry[36] 作為 Gateway，Raspberry PI 為 Embedded Linux，相較於ㄧ般電腦，擁有體積小、低耗電等特性，適合用於物聯網中， Raspberry PI 分為 A、B 兩種型號，本系統採用 B 型進行實作。以下將詳細介紹。  Raspberry PI：一款只有信用卡大小的 Embedded Linux，ㄧ大特色是使用 SD 卡代替

傳統電腦的硬碟，因此，已完成的系統相當容易移植。Raspberry 官方提供相當多 以 ARM 架構為基礎的 Raspberry PI 專用之 Linux 作業系統，例如 Raspbian (Debian)、 Pidora (Fedora)等，本系統採用 Raspbian 作為 Gateway 作業系統。Raspberry PI 的硬 體規格如 TABLE. 3 所示。

TABLE 3 Raspberry PI 硬體規格[35]

SoC Broadcom BCM2835 CPU ARM1176JZF-S 700MHz

GPU Broadcom VideoCore IV, OpenGL ES 2.0, 1080p 30 h.264/MPEG-4 AVC Memory 512 MByte USB 個數 2 網路介面 10/100 乙太網卡 運作功率 700ma 運作電壓 5v GPIO 26 Pin

 Nooliberry：Nooliberry 為一 Raspberry PI 專用之小型 Zigbee 外掛模組，作為本系統 的 6LoWPAN Sink Node 外掛於 Raspberry PI 上，Raspberry PI 上擁有 26 Pin 的 GPIO (General Purpose I/O)腳位，Nooliberry 使用其 20Pin 腳位外掛於 Raspberry，其中， 14、15 Pin 腳(UART)即是用來將 IEEE 802.15.4 的 6LoWPAN 格式 Payload 轉送至 Gateway 中，SLIP 收到該 Payload 即會將其轉為 IPv6 封包。以下 TABLE. 4 為 Nooliberry 之詳細硬體規格。

TABLE 4 Nooliberry 硬體規格[36] Microcontroller Atmega1281 Operating Voltage 3.3V Flash Memory 128 KB SRAM 8KB EEPROM 4KB Receiver Sensitivity -101db 3.3 系統伺服器設計 3.3.1 Server Functionality

本研究之 Server 屬於中央控管程序，負責管理曾與 Server 註冊之 Gateway，且能夠接 收 Gateway 底下之 6LoWPAN Nodes 的感測資料並儲存於資料中心。當環境中有新的 Node 加入 Gateway 時，Server 收到 Node 所產生的註冊訊息後即會下 CoAP Discover 的 指令查知 Node 的 Profile 並儲存於資料中心。=

3.3.2 Server Implementation

本研究之 Server 如 Fig. 11 所示，使用 Microsoft C# Windows Form 撰寫，使用到的模組 包括 Inet6 UDP、MySQL、CoAP。UDP 模組用於接收感測環境所產生之 IPv6 封包，系

MySQL connector API 進行實作，使用此模組可以輕易的對 MySQL 資料庫進行操作。 CoAP 功能使用 CoAP Sharp API[38]，用於 Discover 6LoWPAN Node 的 Profile。

Fig. 11 系統伺服器介面

3.4 使用者應用：以家庭監控為例

以本研究之 M2M 平台所自動產生之 Data 為基礎所開發出來的程式，以驗證本系統的 可用性，以 Home Monitoring 為例，本程式設計以一個 Gateway 代表一個區域，例如房 間，選擇 Gateway 後即可看到於 Gateway 上安裝的小型攝影機的監視畫面，且察知 Gateway 範圍內的 6LoWPAN Nodes，選擇特定的 6LoWPAN Node 後即可觀看其 Profile， 以及觀看繪製成圖表的感測資訊。另外，由於 Sensor 的異質性，所提供的服務不盡相 同，本程式會依照 Sensor 所提供的 Profile 產生不同的使用者介面(UI：User Interface)， 如 Fig. 12(a) 與 Fig. 12(b)。其中 Fig. 12(a)為選擇 2002:786c:cd24:2:11:22ff:fe33:4401 Node，

該 Node 提供的服務有控制 LED 與溫度計，由 Profile 中判斷溫度計為 Sensor Data，因 此繪製圖表。另外，如 Fig. 12(b)所示，因節點 2002:786c:cd24:2:11:22ff:fe33:4403 擁有 不同的 Profile，新增了空氣品質感測器，因此，圖表便會繪製出兩種感測資訊。

第四章 實測結果

本章將介紹於第三章中，各個功能模組之實測結果。

4.1 6LoWPAN 與 IPv6 封包轉換

如 Fig . 13(a) 所示為 Wireless Sniffer 所擷取到由 6LoWPAN Node 所產生之無線 Zigbee 封包，由圖中可看出 Zigbee 封包的 PAN ID 為與其 Zigbee Source/Destination 和 Payload，Contiki 系統預設之 Zigbee PAN 為 0xABCD，圖上之 Destination 為 Nooliberry 之 MAC address 0x0200000015D63AA6 ， Source 為 Zigduino 之 MAC Address 0x021122FFFE334404。Payload 可看出該封包是使用 6LoWPAN Full Address 格式，但由 此可看出並不完全符合第 2 章中所整理的 6LoWPAN Full Address 封包格式。於 Payload 內容中，最重要的資訊包含了封包之 Source/Destination 之 IPv6 位址，其中，Source Address 為 2002:786c:cd24:0002:0011:22ff:fe33:4404 ， Destination Address 為 2002:786c:cd2b:786c:cd2b 。 以 及 UDP 之 Source/Destination ， 其 中 Source Port 為 8765(223D)，Destination Port 為 5678(162E)。Fig. 13(b) 為於 Gateway 上 WireShark 所 擷取到的封包。對照 Fig 10.1 可觀察出 6LoWPAN 已被 SLIP 正確的轉為 IPv6 封包。

Fig. 13.(a) 於無線 Sniffer 抓取之封包

Fig. 13.(b) 於閘道器抓取之封包

4.2 IPv6/IPv4 穿隧

當 Gateway 位於 IPv4 時，為了使 6LoWPAN 封包能夠用於 IPv4 上，Gateway 會對封包 進行 Tunnel 6to4 的處理，Fig. 14(a)與 Fig. 14(b)為 Gateway 上運行之 WireShark 所擷取 出的封包畫面，介面分別為 eth0 (Network Interface Card (Ethernet))、tun0(SLIP)、 tun6to4(tunnel 6to4)，該順序為依照英文字母順序排列，並非特定之順序。Fig. 14.(a)顯 示出，WireShark 於 tun0 介面擷取出由 SLIP 轉換 6LoWPAN 成為 IPv6 的封包 (NO.3864) 後，封包會經過 tun6to4 介面 (NO.3865) ，tun6to4 即會對封包進行封裝，而由 Fig. 14.(b) 中，於 eth0 上抓取到的封包 (NO.3866) 就可以看出經過 tunnel 6to4 後，IPv6 被封裝於 IPv4 Header 並使用 Gateway 的 IPv4 傳送，且將 Protocol 設為 41 表示其為 IPv6 封包， 此種封包稱為 6to4 Packet，該封包可順利傳輸於 IPv4 網路。

Fig. 14(a) 於 SLIP 介面抓取之 IPv6 封包

4.3 伺服器察知節點

本系統 Server 位址採用節點事先得知的方式達成，當環境中有新的感測節點欲加 入本系統，Node 於 Gateway 取得該區域之 IPv6 Prefix 後，Node 便可組合 Global IPv6， 當 Node 組合完成後，即會對 Server 發送註冊封包。當 Server 收到封包後，如 Fig. 15(a) 所示，並會依照 Prefix 將該 Node 加入所屬 Gateway 中加以管理。另外，如 Fig. 15(b)所 示，為 WireShark 所擷取到由 Server 發送 CoAP Discover 封包以及 Node 所回應的 CoAP Profile。於 Server 收到註冊封包時，會發送 CoAP Discover 的封包，來察知該 Node 的 Profile，由 Fig.15(b)中的封包 Payload 可看出，該 Node 支援 Hello World、Led Control、 Led toggle、Temperature 功能，使用者即可依照此 Profile 對節點進行讀取或控制。

Fig. 15.(b) CoAP 測寫檔內容

4.4 Firefox CoAP 外掛套件測試

為證明本研究之 CoAP 節點可用性，本節使用第三方之軟體來驗證。目前多數瀏覽器並 不支援 CoAP 協定，但於 Firefox 中，已有外掛套件可使用[38]。於本實驗中，於遠端之 電腦使用 CoAP，證實該節點能夠經過 Gateway 傳出相關訊息至遠端。本測試節點之 IPv6 Address 為 2002:786c:cd24:2:11:22ff:fe33:4403，以並開啟 Port 5683 給予 CoAP 使 用。

如 Fig. 16(a)所示，該畫面為於網址列中輸入 CoAP URL 後之初始畫面，選擇 Discover 後，即會查詢.well-known/core 中所記錄之節點所能夠提供的 Service，如 Fig. 16(b)所示，

LED 控制能使用 PUT 或 POST 之方式進行控制，溫度與空氣品質可使用 GET 方式直 接與感測器取得，如 Fig. 16(c) 所示得到溫度計讀值為 35.69 度，另外，Fig. 16(d) 所示 可得到空氣品質感測器為 754(為 Analog 0~1023 讀值越高表品質越好)。

Fig. 16(b) CoAP 服務察知

第五章 結論與未來展望

5.1 結論

本研究以整合物聯網異質性為目標，並已成功整合部分物聯網異質，其中包括(1)通訊 協定異質：於物聯網中，IEEE 802.15.4 Zigbee 協定扮演了環境感測重要角色，但 Zigbee 協定與網際網路是異質的(Ethernet IEEE 802.3 與 WiFi IEEE 802.11)，無法直接溝通， 容易形成通訊孤島，因此，本研究於 Gateway 中安裝不同的網路介面，包括 Zigbee、 Ethernet、WiFi，使 Zigbee 節點感測資料能夠透過其它介面轉送至網際網路。(2)連網技 術異質：由於傳統 Zigbee 無法使用 IP，因此，本研究於 Zigbee Node 實作 6LoWPAN， 讓 Zigbee Node 能夠使用 IPv6 相關功能。另外，於 Gateway 上實作 6LoWPAN Border Router 的功能，使 Zigbee 節點所送出的 6LoWPAN 封包能夠成功轉為完整的 IPv6 並送 上 Internet。最後，由於物聯網中有許多設備，使用的連網技術並不盡相同，如 IPv6、 IPv4，由於 6LoWPAN 制定為 IPv6 Only，因此，本研究於 Gateway 上實作 Tunnel 6to4 的功能，使 6LoWPAN 不僅能用於 IPv6，也能使用於 IPv4。(3)設備異質：因為每個設 備可提供的能力並不盡相同，本研究以 CoAP 為基礎記錄 Sensor Profile 並設計一 M2M 平台，以不需人為介入的中央控管機制來管理與取得 Sensor Profile 與 Sensor data，並 記錄於資料中心，給予使用者方便後續使用。(4)實現感測節點與遠端設備之 End-to-End Communication：本研究不只將 6LoWPAN 節點所產生之感測資料能夠使用 UDP 封包成 功傳送至遠端 Server。也於 6LoWPAN 節點中實作 CoAP，並證明遠端設備能夠成功直 接訪問節點並取得節點所提供的資料，因此，Global 的雙向 End-to-End Communication

已成功部屬與應用於本系統中。(5)以 M2M 平台為基礎設計使用者應用範例：設計者只 需利用本 M2M 平台所產生的資料，無須了解其中的細節，過程中繁複的處理流程，均 交由平台中 M2M 模組處理完成。

5.2 未來展望

本系統的 Gateway 目前已處理 IEEE 802.15.4 與 IEEE 802.3、IEEE802.11 間的異質，未 來希望能夠加入新的通訊技術用於處理物聯網異質性，使本系統 Gateway 處理異質功 能更加完善。另外，可以於更多的物聯網設備上實作 CoAP 以運用於本系統。

參考文獻

[1] Gartner Identifies the Top 10 Strategic Technology Trends for 2014, Available At:

http://www.gartner.com/newsroom/id/2603623

[2] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” ACM Computer Networks , vol. 54, no. 15, pp. 2787 – 2805, Oct. 2010.

[3] D. Miorandi, S. Sicari, F. D. Pellegrini, and I. Chlamtac, “Internet of Things: Vision, applications and research challenges,” ACM Ad Hoc Networks, vol. 10, no.7, pp.1497-1516, Sep. 2012. [4] oneM2M, Available At: http://www.onem2m.org/

[5] K. C. Chen, and S. Y. Lien. “Machine-to-Machine communications: Technologies and Challenges,” ACM Ad Hoc Networks, vol.18, no. 3, pp. 3-23, Jul. 2014.

[6] Transmission of IPv6 Packets over IEEE 802.15.4 Networks, IETF RFC Standard 4944, Sep. 2007.

[7] Connection of IPv6 Domains via IPv4 Clouds, IETF RFC Standard 3056, Feb. 2001.

[8] Constrained Application Protocol (CoAP), IETF RFC Standard 7252, Jun. 2014.

[9] Gartner Says the Internet of Things Installed Base Will Grow to 26 Billion Units By 2020, Available

At: http://www.gartner.com/newsroom/id/2636073

[10] G. M. Lee, J. Park, N. Kong, N. Crespi, “The Internet of Things – Concept and Problem Statement,” IETF, draft–lee–iot–problem–statement–00, Apr. 2011.

[11] Machine–to–Machine Communications; M2M service requirements, ETSI Standard TS.102

[12] Machine–to–Machine Communications; Functional Architecture, ETSI Standard TS. 102 690

v1.2.1, Jun. 2013.

[13] Architecture Analysis – Part 1: Analysis of architectures proposed for consideration, oneM2M

Standard TR.0002, Nov. 2013.

[14] Architecture Analysis – Part 2: Study for the merging of architectures proposed for consideration

by oneM2M, oneM2Mstandard TR. 0002, Jul. 2013.

[15] P. Barontib, P. Pillaia, V. W. C. Chooka, S. Chessab, et al, “Wireless sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee standards,” ACM Computer Communications, vol. 30, no. 7, pp.1655-1695, May. 2007.

[16] J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, andC. Gomez, “Transmission of IPv6 Packets over BLUETOOTH Low Energy,” IETF, draft–ietf–6lowpan–btle–12, work–in–progress, Feb. 2013.

[17] Z. Shelby, and C. Bormann, 6LoWPAN: The wireless embedded Internet, 2011.

[18] J. Hui, and P. Thubert, “Compression Format for IPv6 Datagrams in Low Power and Lossy Networks,” IETF, draft–ietf–6lowpan–hc–15, Aug. 2011.

[19] Compression Format for IPv6 Datagrams over IEEE 802.15.4–Based Networks, IETF RFC

Standard 6282, Sep. 2011.

[20] A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES:

[21] B. C. Villaverde, R. D. P. Alberola, A. J. Jara, S. Fedor, S. K. Das, and D. Pesch, “Service Discovery Protocols for Constrained Machine-to-Machine Communications,” IEEE

Communication Surveys & Tutorials, vol. 16, no. 1, pp. 41-57, Feb. 2014.

[22] Sensinode Ltd, Available At: http://www.sensinode.com

[23] K. Kim, W. A. Baig, S. Yoo, “Simple Service Location Protocol (SSLP) for 6LoWPAN,” IETF, draft-daniel-6lowpan-sslp-02, Oct. 2009.

[24] DNS-Based Service Discovery, IETF RFC Standard 6763, Feb. 2013.

[25] Google IPv6 Statistics, Available At: http://www.google.com/intl/en/ipv6/statistics.html

[26] G. Lencse, S. Répás, “Performance Analysis and Comparison of 6to4 Relay Implementations,” International Journal of Advanced Computer Science and Applications, vol. 4, no. 9, pp. 13-21,

2013

[27] Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,

IETF RFC standard 6146, Apr. 2011.

[28] DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,

IETF RFC standard 6147, Apr. 2011.

[29] IPv6 Stateless Address Autoconfiguration, IETF RFC standard 4862, Aug. 2007.

[30] Y. Chen, K. M. Hou, H. Zhou , H. L. Shi , X. Liu , X. Diao, H. Ding , J. J. Li ,and d. Vaulx, “6LoWPAN stacks: a survey,” Proceeding of IEEE 2011 7th International Conference on Wireless Communications Networking and Mobile Computing, Wuhan, pp. 1-4, 2011.

[31] TinyOS Home Page, Available At: http://www.tinyos.net/

[32] Contiki: The Open Source OS for the Internet of Things, Available At: http://www.contiki–

os.org/index.html

[33] Zigduino, Available At: http://www.logos-electro.com/store/zigduino-r2

[34] Contiki on Zigduino, Available At: https://github.com/maniacbug/contiki-avr-zigduino/wiki

[35] Raspberry PI, Available At: http://www.raspberrypi.org/

[36] Nooliberry, Available At: https://github.com/Noolitic/Nooliberry/wiki

[37] Coap Sharp, Available At: http://www.coapsharp.com/

[38] Copper, Available At: https://addons.mozilla.org/en-US/firefox/addon/copper-270430/

[39] T. Savolainen, J. Soininen, and B.Silverajan, “IPv6 Addressing Strategies for IoT,” IEEE Sensors Journal, vol. 13, no. 10, pp. 3511-3519, Oct. 2013.