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

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

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

A CoAP-Based Transparent Service

Integration and Delivery Mechanism in

Heterogeneous IoT Environment

指導教授：林嬿雯 博士

研究生：侯善尹 撰

中華民國一百零三年七月

I

摘要

隨著物聯網應用越來越普及，在未來將會有非常多異質的通訊技術與設備共存於物

聯網中，所以必須要整合這些通訊技術與設備使其能夠互通，IPv6 即為目前被視為可

能的解決方案之一。在本文中，我們設計了一個 6LoWPAN 環境，並設計適用於

6LoWPAN環境的閘道器來進行雙向的接收與轉發 6LoWAPN封包，閘道器能將封包轉

為目的地節點所能接收的正確封包格式。因此，物聯網環境節點間的無縫雙向端對端通

訊將可達成。此外，於物聯網節點中實作 CoAP，支援 CoAP的節點能夠記錄自身所提

供的服務，因此，使用者可以使用 CoAP 所規範的方法，使用 URI 輕易取得物聯網中

各異質能力的節點提供的服務，且可直接對節點進行操作。另外，為了因應物聯網中節

點數量相當龐大，本研究設計一平台能夠管理與儲存節點相關資訊，來讓使用者運用更

佳的便利。

關鍵詞:物聯網、6LoWPAN、閘道器、端對端通訊、CoAP

II

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.

Keywords: IoT, 6LoWPAN, Gateway, End-to-End Communications, CoAP.

III

目錄

摘要………………………………………………………………………………………..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

第三章 研究方法…………………………………………………………………16

IV

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

V

表目錄

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

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

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

Table 4：Nooliberry 硬體規格……………………………………………………………….. 32

VI

圖目錄

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 14(b)：轉換 6to4 封包………………………..……………………….….……………. 38

VII

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

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

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

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

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

Figure 16(d)：取得空氣品質……………………..…..…………………………………………. 43

1

第一章 緒論

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)方式提供使用者滿意的服務，是極具挑戰性的課題。為達此一目標，

2

本研究將物聯網中之 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 封包才能於網際網路中繞送。因此，本研究於物聯網

3

閘道器(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、開啟其所需的資料庫等。而這些

4

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

1.3 論文架構

本論文架構如下：第一章為研究背景動機與目標。第二章相關研究將分別敘述物聯

網、M2M、傳統WSN與 6LoWPAN的差異、如何使 6LoWPAN能夠使用於 IPv4、介紹

現有的 Service Discovery技術，最後介紹本研究選用的 Service Discovery技術即 CoAP。

第三章將說明本研究之研究方法，分別為M2M系統架構與 6LoWPAN系統架構以及實

作硬體。第四章將說明本研究之實驗結果。最後，第五章則為結論與未來展望。

5

第二章 國內外相關研究

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 年底發表的技術報告

6

[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。

7

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 節中說

明。

8

MAC FCS

1 byte 53 byte 4 byte

L IPv6 UDP Payload

8 byte40 byte21 byte

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

MAC FCS

2 byte 108 byte 4 byte

L UDP Payload

4 byte9 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節闡述。

9

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較低的設備，可能無法負荷傳統的協定。為了

10

因應 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 所發展的協定，使用

11

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

12

至 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會使用編碼的方

13

式傳送 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

5.05 Proxying Not Supported

14

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

15

必須為 2002::/16。由於 Tunnel 6to4並不會破壞設備原始 Header，因此，於本研究中選

用 Tunnel 6to4實作於 Gateway中，使得 6LoWPAN封包能夠使用者 IPv4網路。

16

第三章 研究方法

在物聯網的環境中存在許多設備，包含功能限制的設備(如 Sensor)及完整功能且可

自行連上網際網路的設備(如手機)，本文主要以微小型 Zigbee 設備作為處理物聯網異

質的對象。於物聯網中，這些微小型設備依照所使用的感測器、應用方式、使用情境會

產生不同的功能與應用，因此，這些微小型設備通常為異質的，包括連網技術、通訊技

術、感測功能等。傳統上這些微小型設備所使用的網路技術，與網際網路通常是不同的，

容易變成一座通訊孤島。而這些微小型設備所提供的功能並不相同，因此，必須有ㄧ機

制來記錄微小型設備的 Profile，用以得知這些微小型設備所提供的服務。

本文將針對上述微小型設備的異質性進行適當的處理，處理的異質包括通訊協定異

質、連網技術異質、設備異質。其中，通訊協定異質包括 IEEE 802.3(Ethernet)、IEEE

802.11(WiFi)與 IEEE 802.15.4(Zigbee)以 IP的方式整合使其能夠互相溝通。連網異質為

物聯網中各個設備可能使用不同技術連上網路，包括 IPv4、IPv6、3G/4G。設備異質則

為物聯網中各個設備可能擁有不同的服務能力，因此，本研究以標準化的方式記錄

Profile以進行服務能力的整合。

3.1 系統架構

本節將介紹系統架構，並分別從使用者與從設計者角度分析系統設計。

17

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

與 IPv4 環境皆能運作。由於 Gateway 此ㄧ特性，6LoWPAN 感測節點不僅可對外傳送

IoT Server

Internet(IPv4/IPv6)

Data Center

End UserIoT Gateway

6LoWPAN Sensing Area

18

感測資訊至 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系統所產生的資料即可

使用相關應用。

19

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節說明。

Node Registration：當Node自動產生 IPv6 Address後，Node會對本系統遠端之 Server

6LoWPAN

IPv4 IPv6

6LoWPANIoT Gateway (Prefix Provider)

IoT Gateway (Prefix Provider)

IPv6 Rely

Join PAN

IoT Server

Data Center

End User

End User

IoT Server

Data Center

20

發送註冊訊息，當 Server收到註冊訊息後便會使用 CoAP察知 Node的服務能力後

記錄，並於資料中心開啟相對應的資料儲存空間。

Sensed Data Storage：當 Node註冊完成後，便會開始因事件發生回報或定期回報所

配備之感測器相關資訊至 Server，並由 Server儲存至資料中心。

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

關應用的開發。

Server Data Center6LoWPAN Node

Save Node

IoT Gateway

Join DAG

Provide Prefix

Auto Configuration IPv6

Registration

Get Node Service ProfileContent Save Node Profile

End User

Sensed Data Periodically/On DemandSave Sensed Data

Read Sensed Data

Read Profile

Advertisment

Create Data Table

Registration Save Gateway1

2

3

4

5

Fig. 5 系統循序圖

3.1.3.1 閘道器註冊(Gateway Registration)

本節將詳細介紹 Gateway註冊流程，於本系統中，Gateway的審核與註冊是必需的，

由於安全性的考量，Gateway將由系統管理員由 Server中特定之介面新增至本M2M系

統，Gateway才可被 Server認證，並儲存於資料中心。因此，若系統收到不明 Gateway

21

所發送的封包，將會進行封包的過濾以確保系統的安全性。本系統之 Gateway新增模組

之循序圖如 Fig. 5.第一區塊所示，詳細系統流程如 Fig. 6 所示，由系統管理員輸入

Gateway相關訊息後，系統便會自動判斷該 Gateway是否已被註冊，若有則跳出，若無

則判斷註冊成功，並將 Gateway相關資料寫入資料中心，經過該步驟後，Gateway即可

用於本系統。

Gateway

Registration

Exists?

No

Registration

Success

Save

Gateway

Profile

Yes

Alread

y

Exist E

rror

End

Fig. 6閘道器註冊

3.1.3.2 節點加入 (Node Joining)

本系統使用 Contiki 作業系統作為本系統之微小節點開發環境，於 Contiki 系統中

22

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專用。

23

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封包，基於安全性問題，會

再由防火牆判斷該 Node所產生的封包 Prefix是否與 Gateway相同，若相同則通行，不

24

相同則丟棄。判斷完成後，合法的封包將由 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 感測資料儲存

25

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 進入新環

26

境時，即會對 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可

27

使用的 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所示。

28

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上。

29

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

SinkSLIP

6LoWPAN

NodeNIC

IPv6 Relay6LoWPAN

Node

6LoWPAN

NodeIPv4 Server

IPv6 Server802.15.4

UART

IP Forward

802.3

Gateway6LoWPAN Network

1 2

36to4

4

4

External Network

Fig. 10 閘道器穿隧流程

若要使封包能夠成功於網際網路上繞送，需根據 Gateway所處的網路的位置以及封

包的目的地進行調整，此時分為兩種情形，以下將詳細說明。

30

(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所示。

31

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之詳細硬體規格。

32

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封包，系

統會讀取 Node Profile 後判斷封包資料使屬於何種感測器資料。MySQL 模組使用

33

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，

34

該 Node提供的服務有控制 LED與溫度計，由 Profile中判斷溫度計為 Sensor Data，因

此繪製圖表。另外，如 Fig. 12(b)所示，因節點 2002:786c:cd24:2:11:22ff:fe33:4403擁有

不同的 Profile，新增了空氣品質感測器，因此，圖表便會繪製出兩種感測資訊。

Fig. 12(a) 使用者介面：節點 4401

35

Fig. 12(b) 使用者介面：節點 4403

36

第四章 實測結果

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

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封包。

37

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網路。

38

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

Fig. 14(b) 轉換 6to4封包

39

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.(a) 伺服器自動察知節點測寫檔

40

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 control與 Toggle的功能，以及溫度計和空氣品質感測。其中，

41

LED 控制能使用 PUT 或 POST 之方式進行控制，溫度與空氣品質可使用 GET 方式直

接與感測器取得，如 Fig. 16(c) 所示得到溫度計讀值為 35.69度，另外，Fig. 16(d) 所示

可得到空氣品質感測器為 754(為 Analog 0~1023讀值越高表品質越好)。

Fig. 16(a) CoAP URL

42

Fig. 16(b) CoAP服務察知

Fig. 16(c) 取得溫度

43

Fig. 16(d) 取得空氣品質

44

第五章 結論與未來展望

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

45

已成功部屬與應用於本系統中。(5)以M2M平台為基礎設計使用者應用範例：設計者只

需利用本M2M平台所產生的資料，無須了解其中的細節，過程中繁複的處理流程，均

交由平台中M2M模組處理完成。

5.2 未來展望

本系統的 Gateway目前已處理 IEEE 802.15.4與 IEEE 802.3、IEEE802.11間的異質，未

來希望能夠加入新的通訊技術用於處理物聯網異質性，使本系統 Gateway 處理異質功

能更加完善。另外，可以於更多的物聯網設備上實作 CoAP以運用於本系統。

46

參考文獻

[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

689v2.1.1, Jul. 2013.

47

[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:

SLIP, IETF RFC Standard 1055, Jun. 2011.

48

[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.

49

[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.