國立臺中教育大學資訊工程學系碩士論文
在物聯網中使用 BLE 與 6LoWPAN 技術支
援以 CoAP 為基礎之感測服務
Supporting CoAP-Based Sensing Services
using BLE 6LoWPAN Techniques in IoT
指導教授：林嬿雯 教授
研究生：藍妮 撰
中華民國一百零四年七月
誌 謝
感謝我的指導教授林嬿雯教授，兩年期間提點我許多研究方面的事項，以及耐心
給予學術上的指導，令我對於資工領域的理解、學術方面成長許多，也培養我隨
時擁有好奇心去看待任何事物，保持求知慾，以及自我處理問題的能力。此外，
感謝已畢業的侯善尹學長，在我剛入學時就開始帶領我融入實驗室，讓我在陌生
之地能夠很快的熟悉。並在每次作業或者 meeting 時給我許多寶貴建議與疑點，
培養我的學術能力以及判斷力，教我清楚認知研究所與大學的不同，需要自己擁
有獨立思考的能力。且在畢業後也常回答我的疑問，令我得以順利走到畢業這一
步，並對我的人生影響重大。感謝 102 級的同學們，在上課時對於我的報告給予
寶貴的意見，以及互相交流學術方面的知識，並增進同袍方面的溝通交流，令我
的研究路上並不孤單。感謝學弟妹們，在二年級時必須要一間扛起擔任學姐的責
任，並在他們困難時適時的伸出援手，並訴說自己身為學姐的建議給他們參考，
也讓我學習到如何教導別人的一門學問。此外，感謝在成果展時擔任評審的廖宜
恩主任、張英超教授與朱鴻棋教授，雖然我練習不足導致表現不佳，但是評審們
仍給予我寶貴意見以及肯定。感謝擔任我口試委員的張英超教授、顧維祺教授與
林嬿雯教授，給予我寶貴建議，令我的論文更加完善。最後，感謝我的家人，在
我決定念研究所時給予我支持與鼓勵，令我無後顧之憂順利畢業。
I
摘要
物聯網的應用逐漸受到重視，數量龐大的各式設備需要連結至物聯網中，這些設備越來越
多支援 Bluetooth Low Energy(BLE)協定，因此，本系統中佈署於環境中的節點採用 BLE 通訊
協定。而物聯網中設備數量將持續增長，IPv4 的位址已不足，而 IPv6 可提供許多位址，被視
為目前最佳的解決方法，而本系統透過所設計的 Gateway 協助，讓節點能夠自動取得 IPv6 位
址，進而加入物聯網中。此外，本系統的 Gateway 有考慮到與 IPv4 與 IPv6 技術共存的情況，
根據目的地進行適當的封包轉換，確保能將封包正確地繞送至網際網路中。系統中節點透過
CoAP 協定提供 Service Discovery 機制，使用者使用本系統所提供簡單易用的 Web 介面，直接 與環境中的節點進行溝通與取得感測服務，實現節點與遠端設備之間的雙向溝通，達到全面性
的端對端(End-to End)溝通。
II
Abstract
IoT (Internet of Things) applications become more and more popular. Many devices need to connect
to IoT. Numerous smart devices support the Bluetooth Low Energy (BLE) protocol. Therefore, we
deploy BLE nodes in experiment environment. Because of the continued growth of the number of
devices, IPv6 seems to be the possible solution to solve this problem. In this thesis, we design a
gateway to support the nodes automatically get IPv6 address, that can help the nodes to directly
connect to IoT. Also, the gateway supports the packets routing in IPv6/IPv4 Internet. Moreover, the
system provides the CoAP-based service discovery and friendly web-based services. Therefore, the
end users can directly connect to the nodes and easily get sensing services. The end-to-end
communications can be achieved in the proposed system.
III
目錄
摘要………...……….I Abstract……….II 目錄………..III 表目錄………...VI 圖目錄………VII 第一章 緒論……….………1 1.1 研究背景與動機……….…...1 1.2 研究目標……….……..2 1.3 論文架構……….……..3 第二章 國內外相關研究………...4 2.1 物聯網與機器對機器………..….……4 2.2 異質通訊技術……….…..……5 2.3 BLE 與 6LoWPAN 結合………... …….….……5 2.4 Tunnel 6to4 機制……….….……7 2.5 服務發現機制……….. …….….……9 2.6 雲端資料庫……….………….….…10 第三章 研究方法………. …….….……12 3.1 使用情境……….. ……….….…12IV
3.2 系統架構………. ……….……14
3.2.1 系統需求環境……….………. ……….……16
3.2.1.1 BLE Node 需求……….…….….…...…..17
3.2.1.1.1 6LoWPAN over BLE………. ………..……18
3.2.1.2 Gateway 需求………. ………….…19
3.2.1.2.1 Gateway Kernel 設計……….. ………….….20
3.2.2 系統流程………...………….………..21
3.2.3 IPv6 Auto-Configuration………...………..26
3.2.3.1 IID 組成………. ………..27
3.2.3.2 Global Unique address 組成……….. ………….….28
3.2.4 Gateway 封包轉換……….... ……….29 3.2.4.1 Tunnel 6to4………. ……...….…….31 3.2.5 服務發現機制………... ………..32 3.3 系統設計………. ……….34 3.3.1 系統需求……….. ……….34 3.3.2 Web Portal 設計……….……..34 3.2.2.1 CoAP.NET………35 3.3.3 Local Database 設計……….………...36 3.3.4 Cloud Database 設計………...38
V 3.3.4.1 遷移本地資料庫……….………..39 3.3.4.2 連接 Cloud Database……….…..39 3.4 使用者應用：以室內環境監控為例……….……...40 第四章 實測結果………42 4.1 與 BLE Node 建立連線………..……42
4.2 BLE 6LoWPAN Module………...……….……43
4.3 Gateway 封包轉換………..…….…….44 4.4 提供 CoAP 服務……….……....47 4.5 Microsoft Azure 資料庫測試………..…………..51 第五章 結論與未來展望………53 5.1 結論……….……53 5.2 未來展望……….………54 參考文獻………..55
VI
表目錄
Table.1 nRF51-DK 硬體規格………..18 Table.2 Rapberry Pi 硬體規格……….………....20 Table.3 使用者資料表………37 Table.4 使用者訂閱服務資料表……….37 Table.5 Gateway 資料表……….……….37 Table.6 Node 感測服務資料表………....37VII
圖目錄
Figure 1 BLE 與 BLE 6LoWPAN Stack……….………...7
Figure 2 使用情境……….………...13
Figure 3 Web Portal………...……….……….14
Figure 4 使用者註冊畫面……….……...14
Figure 5 使用者選單……….………...14
Figure 6 訂閱服務畫面……….………...14
Figure 7 系統架構圖……….………...16
Figure 8 CoAP URI 範例……….16
Figure 9 Gateway Kernel 設定………....…………21
Figure 10 Gateway 註冊流程………..22
Figure 11 Node 註冊流程………..……….…………24
Figure 12 搜尋 BLE Node……….………...24
Figure 13 使用者註冊流程……….………….25
Figure 14 on Demand 使用者請求流程………..26
Figure 15 Periodical 使用者請求流程………...……….…………26
Figure 16 IID 組成………...28
Figure 17 Global Address 組成……….…...29
VIII
Figure 19 Tunnel 6to4 介面……….32
Figure 20 CoAP 封包轉換……….…..31
Figure 21 EER 模型………..……….………….…36
Figure 22 Microsoft Azure Web Portal………..……….………38
Figure 23 SSMA 工具轉換資料庫成功之畫面……….……….39
Figure 24 管理者畫面……….……….40
Figure 25 CoAP Request………..41
Figure 26 感測數值圖表……….….41
Figure 27 風扇接線……….…….41
Figure 28 Bluetooth Dongle 資訊………42
Figure 29 L2CAP 連線建立之封包………..……….………43
Figure 30 虛擬 bt0 介面……….………..44
Figure 31 6LoWPAN 封包(a) ………..…….……….45
Figure 32 6LoWPAN 封包(b) ……….45
Figure 33 6LoWPAN Module 還原成完整 IPv6 封包……….……...46
Figure 34 Tunnel6to4 封包………..47
Figure 35 CoAP Cooper 介面………..48
Figure 36 Node Profile. ………...48
IX
Figure 38 CoAP GET 封包(b) ……….………49
Figure 39 CoAP PUT 封包(a) ……….………50
Figure 40 CoAP PUT 封包(b) ……….…………50
Figure 41 包含 CoAP 資訊之 BLE 封包(a) ……….………….51
Figure 42 包含 CoAP 資訊之 BLE 封包(b) ……….………….51
1
第一章 緒論
1.1 研究背景與動機
近年來，物聯網(Internet of Thing，IoT)一直是備受注目的議題，且在 Gartner 預測 2015 年最重要的十大技術中[1]提及物聯網並認為物聯網將改變未來科技。Garner 的定 義中指物聯網為一個網路中包含大量的嵌入式技術實體，這些實體能夠使用無線通訊 溝通與進行感測服務，並擁有設備內部狀態溝通和外部環境互動的能力[2]，這些實體 則為物聯網中的 Things，能無縫地與 Internet 串連。由於目前已被標準化的無線通訊技 術逐漸普及，包含 Bluetooth Low Energy(IEEE 802.15.6)、ZigBee(IEEE 802.15.4)等，以 及物聯網應用盛行(包括建築與家庭自動化、醫療與照護、智慧型運輸系統與環境監控 等)。物聯網備受重視，衍生許多研究議題，包括異質通訊協定、互通性、標準化、自 適應性、異質資料整合、延展性、智慧化與移動性支援等[3][4]，而上述這些問題仍尚 待解決。 M2M(Machine to Machine)機器與機器間的通訊，是物聯網中相當重要的一部分， 由 ETSI 協會制定其標準[5][6]，M2M 的定義是指機器與機器間不需人為介入，即可自 主地互相溝通，若時常需要人為介入，在物聯網中並不合用，且需耗費人力，因此如 何在物聯網中達到 M2M 也為本系統要達到的目標之一。 本系統佈署在 6LoWPAN 環境中以 BLE 通訊能力的感測節點，並設計智慧型 Gateway 處理存在於物聯網中的異質性，此外，架設 Server 控管節點與 Gateway，並連 接 Data Center 儲存相關資料。本系統亦考量到目前 IPv6 的使用率不高[7]，Gateway 與 Server 可能佈署於 IPv6 或 IPv4 環境中，本系統設計之 Gateway 可察知目的地所在之環
2
境，並自動地執行適當的封包轉換。
目前相較於 Zigbee 協定，多數智慧型裝置皆開始支援低功耗藍牙(BLE：Bluetooth Low Energy)協定，因此，本系統佈署於環境中的節點採用 BLE 協定。此外，由於傳統 的 Web 中，並無考慮到 IoT 設備中的限制(如：供電限制、頻寬等，典型例子為 6LoWPAN 環境)，而專為受限設備設計的 CoAP 協定利用網頁則可適用於 IoT 中，形成 Web of Things(WoT)[8][9]。因此，本系統的節點將使用 BLE 通訊協定，並佈署於 6LoWPAN 環境中，透過 CoAP 協定以提供感測服務與控制室內設備的服務為研究目標。
1.2 研究目標
本論文將致力於達成以下幾個目標，包括：
(1) 整合通訊協定異質：傳統無線感測網路與網際網路通訊協定並不相同，通常 WSN 並無法與網際網路結合，因此，本研究以 WSN 中的 BLE 為通訊協定為處理對象， 令 BLE 節點能夠擁有使用 IPv6 協定，並形成 6LoWPAN 環境，使節點能夠自主配 置位址，可與網際網路中的設備互通。
(2) 連網技術共存：位於 6LoWPAN 環境中所傳送的 6LoWPAN 封包並無法直接於網際 網路上傳遞，所以需要 Gateway 來幫助轉換成完整的 IPv6 封包。此外，由於目前 網際網路多數採用 IPv4 協定，完全轉換至 IPv6 協定還需一段過渡期，因此，本系 統考量在 Gateway 中實現 Tunnel 6to4 機制轉換機制，令 Gateway 能夠依照目前需 求，正確轉換異質封包並能夠在網際網路繞送至正確目的地。
3
(3) 達成 End-to-End Communication：由於傳統 WSN 無法與網際網路互通，本系統所 佈署的節點，透過 Gateway 當作橋梁，令本系統所架設之 Node 能夠直接與遠端設 備 進 行 溝 通 與 取 得 節 點 提 供 的 服 務 ， 使 得 節 點 與 遠 端 設 備 之 間 雙 向 溝 通 的 End-to-End Communication。
(4) 服務發現機制：佈署的 BLE 節點支援 CoAP 協定，透過 RESTful 架構能夠簡單取 得服務，(如:提供感測與控制室內設備的服務)，並支援 CoAP Method。節點會將自 身 Profile 傳至 Server，並存放於 Data Center 中，供使用者後續需求使用。
(5) 提供友善的使用介面：使用者無須了解細節與流程，只需使用本系統提供之 Web Portal，便能輕易的取得以 CoAP 為基礎的感測服務。 (6) 結合雲端服務：結合目前雲端 SQL Database 本系統之資料處理與儲存，以提供可 靠、穩定之服務，且減少維護管理系統的成本。
1.3 論文架構
本論文架構包含第一章緒論，說明研究背景動機、研究目標。第二章國內外相關研 究，M2M 與目前推動標準化之國際組織、異質通訊技術，以 6LoWPAN 為基礎之 BLE 架構，Tunnel 6to4 技術、Service Discovery 方式等。第三章研究方法，包含使用情境、 系統架構、系統需求環境、系統流程、Gateway 封包轉換、Service Discovery 與使用者 應用。第四章實測結果，實測結果包含 BLE Node 傳送之 6LoWPAN 封包、BLE 6LoWPAN Module、Tunnel 6to4 與 Microsoft Azure 資料庫測試。第五章結論與未來展望。4
第二章 國內外相關研究
2.1 物聯網與機器對機器
物聯網(Internet of Things)的定義是指人與 Things 能在任何時間及任何地方並與任 何東西或任何人，透過任何網路來取得任何服務[10]。其中，Things 指的是小型感測器 或嵌入式設備等，這些設備會利用無線通訊技術溝通，因此，會形成無線感測網路 (Wireless Sensor Network：WSN)。WSN 主要幾項技術，可包含無線城市網路(WMAN， 例如：WiMAX)、無線個人區域網路(WPAN，例如：Bluetooth)、無線區域網路(WLAN， 例如：Wi-Fi)、無線廣域網路(WWAN，例如：2.5G、3G、4G)與衛星網路(satellite network)。 而感測網路又依照溝通協定相異可分為：Non-IP based(例如：Zigbee、藍牙)、IP based(例 如：IPv6、IPv4)協定。[3][4]中表示物聯網中的 Gateway 將事非常重要的角色，且列舉 出物聯網上待解決的挑戰，包括異質通訊協定、標準化、異質資料整合、移動性支援 等。在本研究中設計適用於物聯網中的智慧型 Gateway，而 Gateway 會遇到的高度異質 (highly heterogeneous)，包含通訊技術(例如：藍牙、Zigbee、WiFi、RFID 與 Ethernet 等)、設備型態(例如：感測器、智慧型手機、電腦等)、連網技術(例如：有線網路、無 線網路等)。設計本系統之架構時須考量到異質特性並改善本研究所設計之 Gateway， 如上所述，感測器為其中某一種技術，必須在相異的技術中確保彼此間的互連性 (Connectivity)。M2M(Machine to Machine)機器與機器間的通訊，是物聯網中的核心精 神 [11][12] ， [11] 列出 Gateway 需 處 理 的難題， 包含通 訊 協定 異 質 (Communication Heterogeneous)、Gateway 異質性(Gateway Heterogeneous) 、IP 配置管理(IP Configuration Management)等。因此，本研究所設計之 Gateway 皆須考量到上述 Gateway 會遭遇到的
5 難題。本研究解決通訊協定異質，令 BLE 與 Internet 互相溝通，以及解決 IP 配置問題， 節點會自主取得 IPv6 位址，在本系統中透過 CoAP 協定使用此 IP 位址即可取得感測服 務。
2.2 異質通訊技術
在物聯網中許多感測器或設備皆受到限制，例如通訊連網能力供電來源、以及傳輸 資料量等。目前存在物聯網中的通訊技術，包含 Zigbee、藍牙、BLE、WiFi 等。Bluetooth Low Energy 簡稱為 BLE[13]或稱為 Bluetooth Smart，為無線個人區域網路技術(WPAN： Wireless Personal Area Network)，特性包含低吞吐量、低延遲與低功耗等，適合運用於 物聯網中。其供電核心為鈕扣電池，供電可長達兩年。[14] 4.1 版中列出更新功能，包 含 LTE 的通訊共存，自動連線機制與專為 IPv6 協定設計支專用通道等，讓 BLE 設備 連上網際網路加入物聯網成為一部分。且相較於 Zigbee，未來智慧型裝置大量且普遍 的支援 BLE 技術，因此，本系統處理 BLE 通訊技術，並於本系統中佈署 BLE 節點於 6LoWPAN 環境中，提供以 CoAP 協定為基礎的感測服務，將透過本研究所設計的智慧 型 Gateway 當作溝通橋樑，進而解決物聯網中異質通訊之問題。2.3 BLE 與 6LoWPAN 結合
6LoWPAN(IPv6 over Low-Power Wireless Personal Area Networks)[15]此標準之目的 為讓 IPv6 協議能夠運用在小型設備上，令設備賦予 IPv6 位址並連結網際網路。在低功
6
耗無線網路中採用 IP 協定[16]，成為 6LoWPAN 環境，將擁有、良好測試(well tested) 可 擴 展 性 (Scalability) 、 可 延 伸 (Extended) 、 靈 活 性 (Flexibility) 以 及 端 對 端 的 連 接 性 (End-to-End Connectivity)等優點。因此，本研究中所配置的感測節點將會利用 IPv6 Stateless Address Auto-Configure(SLAAC)機制取得 IP 位址(於 3.2.3.2 詳述)。感測節點將 採用 Bluetooth SIG 組織所訂定之低功耗藍牙協定(Bluetooth Low Energy : BLE)。專為傳 輸小量資料、頻率不常，資料傳輸率非常低之藍牙設備所設計[17]。
由於 6LoWPAN 是為 Zigbee(IEEE 802.15.4)所設計，並不適合直接將 6LoWPAN 標 準放入 BLE 中，因此，6LoWPAN 工作組目前為適合在 BLE 上運用 6LoWPAN 協定規 劃標準[17]，但尚未成為 RFC 規範，而本研究所實測到的 6LoWPAN 封包並不為標準 的 6LoWPAN 格式，但 Gateway 能夠依據此封包還原成完整的 IPv6 封包。Figure 1 為 BLE 與 BLE 6LoWPAN Stack。BLE Stack 的底層，包含 Physical Layer(PHY)、Link Layer (LL)、Direct Test Mode(DTM)。其中，PHY 負責傳輸與接收封包，LL 負責建立連接、 錯誤控制與流量偵測，DTM 為測試所用。上下層由 Host Controller Interface(HCI)區別， BLE Stack 的上層，包含 Logical Link Control and Adaptation Protocol(L2CAP)、Attribute Protocol (ATT)、Security Manager (SM)、Generic Attribute Profile (GATT)與 Generic Access Profile (GAP)。L2CAP 提供分割與重組能力，以及與上層建立 Data Channel。ATT 負責 分類藍牙的屬性，SM 定義為 Key 分配與其他安全相關管理。GATT 與 GAP 能夠不使 用 IP 建立 Applications。
7
Service(IPSS)，其中 IPSP 能夠發現 IP-enabled 的設備，以及與設備建立傳輸 IPv6 封包 之間的 Link-layer 連接。BLE 6LoWPAN Stack 的底層由 LL 與 PHY 組成，上層左邊包 含 IPSP、GATT 與 ATT，上層右邊包含 IoT Apps、CoAP、UDP、IPv6、6LWPAN for BLE 與 L2CAP。其中，L2CAP 層提供負責 Segmentation and Reassembly (SAR)與
Fragmentation and Recombination (FAR)機制，由於 BLE 的 Maximum Transmission Unit (MTU)在 L2CAP 固定的 Channel 上為 27byte，包含 L2CAP Header 4byte，可供上層傳 輸的 Protocol Data Unit (PDU)大小為 23byte。但 IPv6 封包為 1280byte 或者更大，因此， L2CAP 層來提供與 Link-layer 之間的分割與重組機制，IPSP 則為與 Link-layer 連接與 協商，並依照此 Profile 規則，提供能夠傳輸 IPv6 封包的最小 MTU。
Figure 1: BLE 與 BLE 6LoWPAN Stack(改編自[17][18])
2.4 Tunnel 6to4 機制
Tunnel 6to4 為 IPv4 與 IPv6 之間的過渡轉換機制，因目前 IPv4 仍為大眾所使用， 但位址數量已嚴重不足以供應未來物聯網的需求，而 IPv6 將是一個很好的解決方案。 但是在物聯網中運用 IPv6 可能遇到的挑戰[16]，包含連接性(Connectivity)、可靠性
8
(Reliability)、異質性(Heterogeneity)、安全性(Security)與移動性(Mobility)。在物聯網中 任何設備必須確保全球唯一性，而 IPv6 協定則能夠達成。若感測器有 IPv6 可將資訊即 時智慧型設備使用[19]，能符合使用者目前情況的需求。
IPv6 位址主要可分為三種類型[20]，包含 Link-local address、ULA(Unique Local address)與 GUA(Global Unique address)，分別介紹如下：
Link-local address：若設備具有 IID(Interface ID)即可透過 IPv6 Stateless Address Auto-Configure(SLAAC)[21]或 Neighbor Discovery Protocol 的方式產生 Link-Local Address，而 Link-Local Address 並無法保證全球唯一性(global unique)，因此只能在 single link 上使用，Link-local address 的 Prefix 則固定為 fe80::/64。此外，Link-local address 能運用在群組性設備的成員上，例如 WBAN(Wireless Body Area Network) 等。
ULA(Unique Local address)：ULA 與 Link-Local address 的差異為 ULA 具有全球唯 一性，發生碰撞的可能性非常小，且可用在多跳(multi-hop)網路上，ULA 是專為區 域網路所設計，但並不會將資料傳遞至 Internet，其 Prefix 固定為 fc00::/7，可應用 如智能環境內等。
GUA(Global Unique address)：GUA 具有全球唯一性並可在 Internet 上使用，GUA 為可繞送(Routable)之位址。GUA 適用於需獨立將資料傳遞至網際網路上的設備， 如：手機、Gateway 與物聯網中的設備等。設備可利用 SLAAC 的方式自主的取得 Prefix 並組成 Global IPv6，而 IP 協定讓設備具有可發現性(discoverable)與可定址性 (addressable)的唯一設備，進而達成 M2M 之間遠端或本地的可靠溝通[22]。此外，
9
可從 Prefix 看出是否為 IPv4 轉成 IPv6 的非原生 IPv6 類型，2001::/23 通常為 Native 的 IPv6，2002::/16 為 Tunnel 6to4 轉換為 IPv6 位址，IANA 列出許多 IPv6 位址類型 [23]。
由於目前 IPv6 尚未大量被採用於現存網路，因此需要轉換機制令 IPv6 與 IPv4 能 夠互通，目前較普遍轉換機制包含 Tunnel 6to4[24]、6in4[25]、ISATAP[26]與 Teredo[27] 等，其中，Tunnel 6to4 會保留原始 Header，不會破壞封包，因此，本系統使用 Tunnel 6to4 機制來轉換封包（3.2.4.1 節說明）。
2.5 服務發現機制
在物聯網中如何提供服務發現機制(Service Discovery Mechanisms)為一大重點，且 Discovery Protocols 並無需通過人為介入，提供自動發線設備提供的服務[19]。在設備 上利用 IP 協定，擁有的好處包含可發現性(Discoverable)與可定址性(Addressable)，達成 Machine to Machine(M2M)之間遠端或本地的可靠溝通方式[28]。目前 IP-Based 的 Discovery Protocols 傳統協定[19]，包括 UPnP(Universal Plug and Play)、SLP(Service Location Protocol)、JINI 與 Salutation 等，但是這些協定不適合運用物聯網中，其需求 要較高的電力與頻寬等能力，但物聯網中大多數為受限設備，無法負荷傳統協定要求。 [19]服務發現機制的設計必須符合下列條件，每個控制訊息要有較低的 Overhead，減少 訊息的交換次數以便節省電力消耗與節省頻寬，以及要求較低 Processing 與 Memory， 能透過 Internet 來進行控制。Service Discovery Protocol 區分為 Non-IP based 與 IP-based。 Non-IP based 無支援 IP 協定，會被限制在低功耗網路之內部並且無法與遠端溝通，形
10
成孤島(islands)[19]。IP-based 逐漸受重視，目前幾種專為受限環境中運用之 Service Discovery Protocol，包含 SSLP、nanoSLP、DNS-SD 與 CoAP 等。
CoAP[31]為 IETF 的 CoRE(Constrained RESTful Environments)[31]為 RESTful 的網 頁傳輸協定之架構，專為資源受限的網路與節點所設計，並為輕量級協定，並適合運 用於佈署大量微型節點的 IoT 環境中。CoAP 以 IP 為基礎設計之服務發現機制，與傳 統方法相比，較能減少配置與網路設備間的管理[28]。CoAP 提供資源感知(Resource Aware)服務，使用者透過 Web 即可取得所需資訊。CoAP 與傳統 HTTP 不同之處，包含 將小量封包的 Overhead 優化、Content 標籤化與整合 Low-power and Lossy Networks(LLN) 中的應用程式[16]。因此，本研究採用 CoAP 協定作為 Service Discovery 機制的主軸。
2.6 雲端資料庫
雲端分為三種服務模型，包含平台即為服務(PaaS：Platform-as-a-Service)架構即為 服務(IaaS：Infrastructure-as-a-Service)與軟體即為服務(SaaS：Software-as-a-Service)，提 供某種使用者需要的資源為服務[29]。目前市面上提供的雲端服務，包含 amazon web service(AWS)、Google App Engine、cloudControl 與 Microsoft Azure[30]等。本系統採用 Microsoft Azure，而 Microsoft Azure 提供許多功能，包含發佈與佈署 Web 應用程式、創 建虛擬機器、SQL Database、機器學習等。而 SQL Database 提供彈性的使用需求，能 夠擴充至數千個資料庫，可設定自動還原、資料備份與系統自我管理且無須維護等優 勢。因此，本系統為提供可靠、穩定之服務，減少維護管理系統的成本，以 Microsoft Azure[30]作為本系統之 Cloud Database。Microsoft Azure 提供期間試用服務，租用伺服
11
12
第三章 研究方法
在 IoT 中，存在著大量的異質設備，包含受限制的設備(如:溫濕度感測器等)以及功 能完整且具聯網能力的設備(如:智慧型手機、電腦網路設備)等，位於設備上的通訊技術、 設備型態、聯網技術與資料異質等皆可能為相異的，因此，必需有一角色來處理存在 於 IoT 中的異質，通常為 Border Router 或 Gateway 扮演轉換的重要角色。在本文中實 際架設所設計的智慧型 Gateway，能夠連接 Node 所在的 6LoWPAN 環境，將收到異質 封包做正確且相對應的處理。以及 Gateway 會依照目的地所在的位置(例如:Server 位於 IPv4 或 IPv6 環境)，判斷是否透過 Tunnel 6to4 技術來封裝成可繞送的正確格式，其中， 本系統以 IP 技術將 Bluetooth Low Energy(BLE)、WiFi 與 Ethernet 進行整合達到 IoT 中 異質通訊之解決。此外，本系統利用 RESTful 架構設計使用者 Web Portal，提供使用者 訂閱所需服務(如:溫度、空氣品質變化時通知使用者等)，透過專為受限設備設計之 CoAP 協定，使用者能夠端對端(end-to-end)的對 Node 進行請求感測服務，並可依照 Node 提供的服務類型、使用者的訂閱需求，給予 On Demand 或 Periodical 的感測資料，且可 使用者自訂或由系統自動判斷當前情況，啟動感測 Node 或設備進行相對應的處理(如: 空氣品質不佳，利用 CoAP 命令控制風扇開關)。最後，本系統結合雲端概念與優勢， 將感測資訊等存放至位於雲端的 Data Center 內，令供給使用者的服務品質、系統的延 展性與可靠性更加完善。
3.1 使用情境
13
用者得到相關服務，使用者可使用智慧型手機平板等設備連結 IPv4 或 IPv6 網際網路， 並輸入使用者帳號與密碼，即可存取本系統提供之 Web Portal(使用者介面，如 Figure 3 所示)。若使用者第一次使用本系統，必須要進行註冊(使用者註冊畫面，如 Figure 4 所 示)的動作方可執行後續操作，如 Figure 5 所示為使用者選單畫面，可在此選擇系統服 務，包括訂月服務、增加新服務、使用者中心與使用教學。使用者在平台中可訂閱系 統所提供的服務(訂閱服務畫面，如 Figure 6 所示)。系統時作以室內環境監控為例，每 個房間佈署一個 Gateway 與數個 BLE Node，包含以 BLE 為通訊技術的 Node 並提供多 種感測服務的微型感測器，包含空氣品質、溫濕度偵測等，使用者亦可遠端控制或由 系統自動控制家中設備，包含 LED 與風扇控制等。
14
Figure 3: Web Portal Figure 4: 使用者註冊畫面
Figure 5: 使用者選單 Figure 6: 訂閱服務畫面
3.2 系統架構
15
予使用者便利且可靠穩定之應用平台，使用者可自行架設感測 Node 並給 Node 配置 CoAP URI[31](範例 CoAP URI，如 Figure 8 所示)，本系統即可抓取 Node 所提供的感測 服務，或使用系統預設所提供的感測與控制設備等服務，並可依照使用者需求，設置 客製化的服務(如感測的時間間隔可自行選擇，目前預設為一小時更新一次感測資料)。 本文考慮到目前大部分的網路皆以 IPv4 為主且 IPv6 使用率低[32]，因此，開發 IPv6 與 IPv4 互通之智慧型 Gateway，本系統所設計之 Gateway 能夠適應異質網路環境，包含 IPv4、IPv6 與 6LoWPAN，且 Gateway 具有 BLE 通訊協定能與能力受限之 Node 進行溝 通，因此，實現具異質處理能力之 Gateway。若有新 Node 加入此 Gateway 管轄範圍內， Gateway 會送出包含 Prefix 的廣告信至 Node 出廠即配給的 Bluetooth Device Address， 而 Node 將會利用此 Prefix 資訊，使用 Stateful Auto-Configuration(於 3.2.3.2 節介紹)能 力自主配置 IPv6 位址，並可供系統使用者做後續之應用。
本系統角色包括 BLE Node、Gateway、Server、Azure Cloud 與 User 等，以下分別 介紹系統各個角色的功能：
BLE Node：以 BLE 為通訊技術之感測 Node，負責依照收到的命令，執行相對應的 感測任務。
Gateway：負責管理自身管轄範圍內的 Node，以及將接收到的封包做適當的轉換與 轉送，且具有異質通訊與異質網路之處理。
Server：位於 IPv4 或 IPv6 網路，負責收送傳遞至 Gateway 的封包，並可供後續應 用使用與相關資料儲存，以及提供使用者使用之 Web Portal。
16 Azure Cloud：本系統將相關使用資料存放至此，並且系統定期會自主備份與維護， 確保本系統所提供之服務與可用性。 User：使用者只要具備智慧型手機、平板或一般電腦連結至網際網路，即可使用本 系統所提供之 Web Portal 並取得所需服務。 Figure 7: 系統架構圖
Figure 8: CoAP URI 範例
3.2.1 系統需求環境
如 Figure 6 所示，建構本系統環境，需要數個或一個 Gateway、數個 Node、一台 Server 與 Data Center。以 Gateway 為 6LoWPAN 與 IPv4/IPv6 環境之分界，6LoWPAN
17
為內網，IPv4/IPv6 為外網。Gateway 上接上支援 BLE 之 Bluetooth Dongle，可與 BLE Node 進行溝通，BLE Node 佈於 6LoWPAN 環境內，Node 收到 Gateway 之 Prefix 後並可自行 組成 IPv6，包含 link-local 與 Global address。BLE Node 接上感測器，可將此感測器的 資料透過 CoAP 傳遞至使用者端，並將相關資料儲存於 Data Center 內，詳細流程於 3.2.2 節說明。
3.2.1.1 BLE Node 需求
本系統設計之 Node 採用 NORDIC 公司所生產的 nRF51-DK 開發板[33]，此開發板 的 SoC 為 nRF51 Series 可支援 BLE、ANT 與 2.4GHz 專有應用等，且支援 NORDIC 所 出產的 nRF51822 與 nRF51422 SoC 的相關開發。此開發板為 ARM 系統，因此需採用 Tool-chain 交叉編譯，可使用 IAR Workbench、ARM mbed、GCC 或 Keil MDK，在本系 統中使用 Keil 版本 4 之試用版[34]設計 BLE Node，於 Keil 內撰寫 nRF51 IoT SDK[35] 令其符合本系統之需求，令 Node 能夠在取得 Gateway 發送的 Router Advertisement Message 後，自行組成 IPv6 位址(於 3.2.3 節介紹)。修改成 BLE 可支援 6LoWPAN(於 3.2.1.1 節介紹)，且取得 IP 位址後，即可使用 CoAP Server 所提供的資源(CoAP 協定於 3.2.5 節介紹)。此外，Keil 編譯過後產生 Hex 檔案，將此檔案透過使用支援 Segger J-Link[36]的官方程式 nRFgo Studio[37]燒入程式至開發板內。其詳細規格如 Table.1 所 列。
18
Table.1 nRF51-DK 硬體規格[33]
SoC Nordic nRF51(both nRF51822 and nRF51422) support Bluetooth Smart, ANT and 2.4GHz proprietary application Hardware standard Arduino Uno Revision 3
Program CMSIS-DAP for mbed and tool-chain
Debug Segger J-Link Lite
I/O 4LED and 4 button
USB drag/drop programming USB Virtual COM port for serial terminal
Accepts power USB, External source(1.8V~3.6V), Single 2032 coin-cell battery
3.2.1.1.1 6LoWPAN over BLE
近年來設備數量持續提升，如何連結各設備並運用在物聯網中，IPv6 是很好的解 決方法，並提供有效的 auto-configuration 功能。但由於 6LoWPAN 是為 Zigbee(IEEE 802.15.4)所設計，並不適合直接將 6LoWPAN 標準放入 BLE 中，因此，6LoWPAN 工作 組目前為適合在 BLE 上運用 6LoWPAN 協定規劃標準[17]，但尚未為 RFC 規範，而本 研究所實測到的 6LoWPAN 封包(於 4.3 節說明)並不為標準的 6LoWPAN 格式，但 Payload 含有 IPv6 位址資訊。且 Gateway 能夠將此封包還原成完整的 IPv6 封包。BLE 在 L2CAP 中 MTU 為 27byte[18][47]，L2CAP Header 佔 4byte，Protocol Data Unit (PDU)只有 23byte
19
可供上層使用。但 IPv6 的封包為 1280byte 或更大，因此，要能夠運用在 BLE 中，須 有 L2CAP 的 分 割 與 重 組 之 功 能 。 此 外 ， Internet Protocol Support Profile Specification(IPSP)[17]，IPSP 為支援網際網路所定義的 Profile，依照此 IPSP 的規則， 與目前相連的設備協調，選擇最小的 MTU，確保所有封包皆可有效傳輸。IPSP 能發現 擁有 IP 的設備，並為傳輸 IPv6 封包建立與 Link Layer 之間所需的連接 Channel，由 L2CAP 協定執行分割與重組 IPv6 封包。在本系統中 BLE Node，需支援 6LoWPAN 協 定，使用 BLE 6LoWPAN Library[35]來實現本系統規劃的 Node，其包含 IPSP 與 Link Layer 建立連接、L2CAP 層執行封包分割與重組、封包表頭壓縮與解壓縮等。
3.2.1.2 Gateway 需求
於本系統所規劃之 Gateway 角色，以 Raspberry Pi 小型電腦設計 Gateway 原型，未 來將擴增使用 Smart Phone 支援本系統所設計之 Gateway 角色。目前本系統設計之智慧 型 Gateway 採用 Raspberry Pi[38](又稱樹莓派)，Raspberry Pi 為一款 Embedded Linux 系 統的小型電腦，與一般電腦相較之下，可節省許多電力消耗，適合運用於物聯網中。 Raspberry Pi 所 採 用 的 晶 片 為 Broadcom BCM2835 System on Chip ， 處 理 器 為 ARM1176JZF-S 700MHz。Raspberry Pi 官方與 Raspberry Pi 進階玩家提供多樣化的作業 系統，讓開發者可發展客製化的電腦，其他作業系統包含 Windows 10、Android、Unix 與 RISC OS 等，Raspberry Pi 移植系統相當容易，更改 SD 卡即可，燒錄與備份可透過 Win32 Disk Imager[39]完成。在本系統所開發之智慧型 Gateway 使用官方提供之
20
Raspbian 作業系統。Raspberry Pi 上提供許多介面供開發者發展應用，包含 USB、GPIO、 HDMI、MIPI 相機與 I²S 介面等，詳細硬體規格如 Table.2 所列。
Table.2 Rapberry Pi 硬體規格[38]
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 Network Interface 10/100 Ethernet
Operating Power 700ma
Operating Voltage 5v GPIO 26 Pin
3.2.1.2.1 Gateway Kernel 設計
Linux Kernel[40]為系統上的檔案，而此檔案紀錄許多關於系統的資訊，包括驅動主 機與一些相關的模組，Linux 最大的優點就是使用者能透過編譯 Kernel 滿足使用上的需 求，達到客製化系統的目的，編譯 Kernel 的目的包含新功能的需求，而官方所提供的21
作業系統並不支援 6LoWPAN 需求，因此，為了讓 Gateway 具備支援藍牙的 6LoWPAN 能力，本系統設計之 Gateway 必須自行重新編譯 Linux Kernel 的功能，主要有兩種編譯 的方式，包含 Raspberry Pi 直接編譯與交叉編譯(Cross Compilation)，由於直接在 Raspberry Pi 上編譯受限於硬體規格，編譯的速度將非常緩慢，因此，本文採用交叉編 譯的方式組成自己所需要的系統，使用虛擬機器執行一般 Linux(如 Ubuntu 等)，首先， 必須先建立起 Tool-chain[41]的交叉編譯環境，設定為 Raspberry Pi 的 ARM 架構，並利 用選單的方式選擇 Kernel 功能(如 Figure 9 所示)，支援藍牙 6LoWPAN 之能力，編譯完 成後燒錄 image 檔至 Raspberry Pi 的 SD 內。此外，為支援 BLE 協定之 Bluetooth Dongle， 系統需安裝 BlueZ5.2[42]或更新版本，連接完成後，達到本系統所需之支援 6LoWPAN 的智慧型 Gateway。
Figure 9: Gateway Kernel 設定
3.2.2 系統流程
22
使用者請求與 Periodical 使用請求，以下將分別詳細說明：
Gateway 註冊：如 Figure 10 所示，首先，若要加入本系統所應用之範圍，Gateway 必須要先向 Server 進行註冊，若收到不明的 Gateway 請求註冊(例如:此 Gateway 的 IP 並非本系統的認可範圍內)，為了系統安全性會將此封包丟棄，不處理任何事情。 若此 Gateway 為本系統所認可之範圍內(例如:為本系統認可的 IP 位址)，Server 將 會判斷此 Gateway 是否已註冊過，若確認 Data Center 內無此 Gateway 的資料，則 由管理者進行審核後(確保此 Gateway 為本系統所架設)，通知 Gateway 已加入本系 統，Server 亦會將 Gateway 資訊，送至位於 Azure Cloud 的 Data Center 內創建新資 料表(詳細於 3.3.3 節，Table.5 Gateway 資料表)並儲存其相關資料，其儲存 Gateway 相關資訊包含：IP 位址、系統給予的 Gateway 編號、所提供之應用服務編號、所 管轄範圍內的 Node 數目等。
23
Node 註冊：Node 註冊流程，如 Figure 11 所示。Gateway 會定期使用 BlueZ 所提供 的命令搜尋附近是否存在 BLE Node，如 Figure 12 所示，使用命令為:hcitool lescan， hcitool 為 BlueZ[42]所提供之藍牙相關功能，lescan 為命令 Gateway 上的 Bluetooth Dongle 搜尋 BLE 裝置並在螢幕上顯示搜尋到的結果，顯示附近所在的 BLE 設備名 稱以及 Bluetooth Device Address，Node 收到後，可選擇是否加入至 Gateway 所管 轄範圍內，並由 Gateway 搜尋到 BLE 裝置的 Bluetooth Device Address，依此資訊 建立與 Node 之間連線後，Gateway 會發送 Advertisement(包含自身的 Prefix)至 Node， 而 Node 可利用 auto-configure 能力組成 IPv6 address，執行成功後，可向 Server 進 行 Node 註冊，由 Server 判斷此 Node 先前是否於此 Gateway 範圍內已註冊成功(依 照 Gateway 給予的 Prefix 進行判斷)，若無此 Node 資料，則傳遞 Node 資料至 Data Center，建立 Node 資料表(詳細於 3.3.3 節，Table.6 Node 感測服務資料表)並儲存 NodeProfile 即完成註冊。其儲存 Node 相關資訊，包含：系統配給的服務編號、IP 位址、提供之服務屬性、服務內容、CoAP URI。
24
Figure 11: Node 註冊流程
Figure 12: 搜尋 BLE Node
使用者註冊：如 Figure 13 所示，使用者要使用本系統提供之 Web Portal，第一次使 用必須先要進行註冊，才可提出後續的應用請求。首先，使用者於 Web Portal 登入 畫面下方(如 Figure 2 所示)，點選註冊鈕，填妥相關使用者資料，即可向 Server 進 行註冊手續，由 Server 判別此使用者是否已註冊過，若先前無註冊資料，待系統管 理者審核後，Server 將使用者資料(詳細於 3.3.3 節，Table.3 使用者資料表)存放至 Data Center 內，並由 Server 通知使用者已完成註冊。其使用者相關資訊，包含： 系統給予的使用者編號、使用者帳號、密碼、聯絡電話、姓名、信箱、服務項目編
25 號以及訂閱的服務項目內容。 Figure 13: 使用者註冊流程 使用者請求：如 Figure 14 所示，使用者送出服務請求，由 Server 判斷是否為 on Demand 或 Periodical 的應用服務類型(目前為使用者選擇目前訂閱服務後，選擇 on Demand 或 Periodical，給予不同服務。或可由使用者訂閱服務指定此服務的類型)。 例如為 CoAP PUT/GET 等請求命令為 on Demand 類型，傳送請求至提供此服務的 Node 位置，依照 Data Center 所存放的 Node IP 位址加上服務資源 Path，組成 CoAP URI，並由 Web Portal 進行 CoAP Server Resource Discovery(Service Discovery 於 3.2.5 節說明。CoAP Client 實驗結果於 4.4 節說明)，Node 收到後會執行對應的動作，如 果為 GET 命令，則將感測器傳遞出的訊息放置 Payload 中，並透過 Gateway 送給 使用者，傳遞至 Data Center 內儲存。若為 PUT 命令，則開啟對應的設備開關。如 Figure 15 所示，系統若判斷為 Periodical 的請求，會從 Data Center 中抓取先前定期 儲存的感測資料，且以圖表顯示給使用者(於 3.4 節說明)。此外，於 Data Center 儲
26
存之 Node 相關資訊(詳細於 3.3.3 節，Table.6 Node 感測服務資料表)，包含：感測 到數值的時間、感測到的資料等。 Figure 14: on Demand 使用者請求流程 Figure 15: Periodical 使用者請求流程
3.2.3 IPv6 Auto-Configuration
未來 IoT 中的設備會逐漸增長，要透過唯一的定址方式，令設備連接上網際網路衍 生各種多樣化的 IoT 應用，為保持設備與網路之間的互通性，IPv6 被視為目前應被廣 泛採用接受之解決方式，而且可提供2128個位址並滿足 IoT 中大量位址的需求，因此，27
本文探討 IPv6 所提供的主要三種定址方式，並選擇適合於本系統之做法。IPv6 address 三種主要的類型，本系統採用 Link-local address 與 Global Unique address，Link-local address 為 Single link 所設計，且會自動組成該位址。若本系統所設計之 Gateway 故障， 且無法提供 Prefix 之服務，Node 也可組成 IPv6 位址，但無法至網際網路上傳遞封包。 本系統令 Node 組成 Global Unique address，因此，可透過 CoAP 協定讓使用者取得感 測服務，此外，Gateway 的 IP 為管理者所配給，Node 則由 SLAAC 機制組成 IPv6 address。 以下將說明 Link-local address 與 Global Unique address 組成的過程。
3.2.3.1 IID 組成
IPv6 的位址由 64 bit 的 subnet prefix 與 64 bit 的 interface identifier (IID)組成[20]， 其產生 IID 過程，如 Figure 16 所示，首先，Gateway 會利用 Bluetooth Dongle 搜尋所管 轄範圍內的 BLE Node，BLE Node 在未配對的情況下會一直主動發送藍牙封包給周圍 設備，Gateway 收到 Node 傳送的 48bitPublic Bluetooth Device Address。Gateway 上的 Bluetooth Dongle 與 BLE Node 進行配對之後，Node 會自行將 Public Bluetooth Device Address 轉換為 EUI-64 位址[43]，執行填充的動作，把 0xFF 與 0xFE 放入 Bluetooth Device address 中間的位址。IPv6 Link-local address 為 128bit，並分為兩個部分，Prefix 64 bit 加上 IID 64bit 組成。因此，須將 EUI-64 位址轉換為 IID 的格式，並將位於 Figure 16 黃框處所示之 u 位置(universal/local bit 設為 1 表示 universal scope[20])，在第一個 byte(橘 框處)取得 0x02[26]。
28
Figure 16: IID 組成
3.2.3.2 Global Unique address 組成
128 bit Global Unique address，包含 64 bit Prefix 與 64bit IID 組成[20]。在 Linux Kernel 3.17.0-rc2 版本中開始支援以藍牙 L2CAP 為導向之 6LoWPAN 頻道，如 Figure 16 所示， Node 要取得 IPv6 address 前，Gateway 與 BLE Node 之間必須建立 L2CAP Channel 連接 (於 4.1 節說明建立流程)，才可利用 IPv6 提供之 Stateful Auto-Configuration 或 Stateless Address Auto-Configuration(SLAAC)[21]機制，自動取得 Global address。其中，Stateful 利用 DHCPv6 Server 取得 Prefix，由於 Stateful 需要額外維護一部管理設備配給之 IPv6 訊息的 DHCPv6 Server[44]。SLAAC 利用路由器給予 Prefix 之方式，可讓網管人員提供 相當大的便利性，若需要更改路由器發送之 Prefix，其他設備取得之 IPv6 位址則會自 動覆蓋舊的位址資訊[44]，主動更新 IPv6 位址，因此，在本研究中利用 SLAAC 機制令 Gateway 發送自身的 Prefix 給 Node。SLAAC 機制可讓 Gateway 所傳遞的 Router Advertisement(RA)[45]訊息成為 IPv6 的 Prefix，在 Linux 中可利用 Router Advertisement
29
Daemon(RADVD)[46]，RADVD 會先聆聽是否有收到 Router Solicitation(RS)訊息，需先 配置 RADVD 的設定，包含 AdvAutonomous 與 AdvSendAdvert ，其一，AdvAutonomous 為 RA 訊息中的一部分，配置 on 代表設備在收到 RA 訊息後，可將此 Prefix 組成 Global address，其二，AdvSendAdvert 為令此 Gateway 定期的發送 RA 訊息，配置完成後存檔 並重新啟動 RADVD 功能即會生效改動的部分功能，且在 bt0 介面中會開始廣播 IPv6 Prefix。本系統 Node 取得 Global address 流程，如 Figure 17 所示，Gateway 以 L2CAP 連接上的 Node，Node 可主動發送 RS 訊息，Gateway 會回應包含 Prefix 的 RA 訊息， Node 在收到 RA 訊息後可自主取得 Global address，與 3.2.3.1 節產生 Link-local address 方法相似，取得 Bluetooth Device address 填充為 EUI-64 格式，再轉成 64 bit IID，加上 先前取得的 Gateway Prefix，即形成 IPv6 Global address。
Figure 17: Global Address 組成
3.2.4 Gateway 封包轉換
30
環境包括 6LoWPAN、IPv4 與 IPv6 等形成 IoT 中異質網路環境，因此，需要一個智慧 型 Gateway 執行相對應的正確封包轉換。Gateway 上的主要角色包含 BLE Dongle、 Bluetooth 6LoWPAN Module、Virtual Interface bt0、Tunnel 6to4 與 NIC(網路卡 Network Interface Card)。其中，Bluetooth 6LoWPAN Module 為功能模組，Tunnel 6to4 為轉換介 面。首先，Gateway 上的 BLE Dongle 必須先搜尋附近 BLE Node，並與 BLE Node 進行 配對完成，建立 L2CAP Channel 後，產生 Virtual Interface bt0 網路介面，且 BLE Node 須已自行組成 IPv6 位址才可進行封包的轉換流程。BLE Dongle 收到 BLE Node 所傳送 的 BLE 封包後(實際封包畫面於 4.3 節說明，Figure 31-32)，系統判斷為藍牙的 6LoWPAN 封包，並送至 Kernel 內的 Bluetooth 6LoWPAN Module 進行轉換為 IPv6 封包，在 Virtual Interface bt0 可以觀察到已轉換為 IPv6 封包(實際封包畫面於 4.3 節說明，Figure 33)。 Gateway 會判斷目的地位址為 IPv4 或 IPv6，選擇是否將封包遞送 Tunnel 6to4 介面，若 送至 Tunnel 6to4 會將 IPv6 封包封裝成 IPv4，並送至網路卡(實際封包畫面於 4.3 節說明， Figure 34)，Tunnel 6to4 介面判斷與 Gateway 設定之 Routing Table 於 3.2.4.1 詳細說明。
31
3.2.4.1 Tunnel 6to4
由於目前 IPv6 尚未大量被採用於現存網路，因此需要轉換機制令 IPv6 與 IPv4 能 夠互通，目前較普遍轉換機制包含 Tunnel 6to4[24]、6in4[25]、ISATAP[26]與 Teredo[27] 等，其中，Tunnel 6to4 會保留原始 Header，因此，本系統使用 Tunnel 6to4 機制來轉換 封包，在 Gateway 顯示出的 Tunnel 6to4 介面，如 Figure 19 所示。Gateway 需判斷封包 的 Destination address 位於 IPv4 或 IPv6，以及 Gateway 處於 IPv4 或 IPv6 環境，各情況 詳細說明如下：
若為 Gateway 與 Destination 皆為 IPv4 環境，則不經過 Tunnel 6to4 介面，將封包直 接傳遞至網路卡介面並送到目的地。
若 Gateway 為 IPv4 環境，Destination 為 IPv6 環境，則經過 Tunnel 6to4 界面，並將 外層 IPv4 的 Destination 設為 192.99.88.1，此 Anycast 位址為 IPv6 Relay，傳送至 IPv6 Relay 後將 IPv4 Header 解封裝取出 IPv6 封包，即可傳送至位於 IPv6 的目的地位址。 若 Gateway 與 Destination 皆為 IPv6 環境，封包可直接遞送，無需經過額外處理。 若 Gateway 為 IPv6 環境，Destination 為 IPv4 環境，將此封包傳遞至 Tunnel 6to4
介面，執行封裝並於封包外層加上 IPv4 Header，且必須經過 2002:c058:6301::位址 (代表為 IPv6 Relay Anycast)，最後，繞送至正確的 IPv4 目的位址。
於 Gateway 上設定之簡易 Routing table 如下：
os.system("ip -6 route add 2002::/16 dev tun6to4")：令系統增加 Routing 規則，若為 IPv6 的 Prefix2002::/16(2002 Prefix 代表為 6to4 address)，需經過 Gateway 上的 Tunnel
32
6to4 介面進行封包轉換。
os.system("ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1")：令系統增 加 Routing 規則，若 Prefix 為 2000::/3 的 IPv6(包含多數真實網路上的 IPv6)，固定 送至位於 IPv4 環境中的 192.88.99.1(即為 IPv6 Rely)，即可讓 IPv4 與真實的 IPv6 互通。
Figure 19: Tunnel 6to4 介面
3.2.5 服務發現機制
本系統中利用 CoAP 協定達到 Service Discovery 之目的，CoAP[31]專為受限節點與 受到限制的環境所設計(如:low-power 或 lossy 等，典型例子為 6LoWPAN 環境)，CoAP 以 RESTful 為基礎，亦支援與 HTTP 的互通性，使用者可透過 Web 輕易的使用 CoAP 協定所帶來的便利，可於 CoAP 協定中，使用於 CoAP Server 與 CoAP Client 兩個 End Point 之 間 的 Request/Response Module[31] ， Server 提 供 資 源 ， Client 可 使 用 GET/PUT/POST/DELETE 來 請 求 Server 資 源 。 其 CoAP URI 基 本 格 式 [31] 為”coap：””//”host [”：”port] path-abempty [”?” query]，預設 Port 為 5683，CoAP 中 host 的部份使用 URI 表示，Uniform Resource Identifier(URI)為統一資源標識符，運用於標 示位於網記網路中的資源，在 RFC7252[31]中表示 CoAP 協定使用 URI 來識別 CoAP
33
資源與提供定位的一種方式。其 CoAP 基本格式中的 URI-host 為 Destination IP address， URI-Port 為 Destination UDP Port。
在本系統中，節點配置 IPv6 Global address 後(於 3.2.3.2 節詳細說明)，使用者可透 過此 IP 位址，進行 CoAP 服務請求與服務發現。為了達到上述能力，本系統使用 Keil 撰寫 BLE Node 的 IP 組成與 CoAP 相關設定之程式，將 Keil 編譯過後產生的 Hex 檔， 利用 NORDIC 官方提供的 nRFgo Studio 燒錄至 BLE Node 中，BLE Node 在重新燒錄後 會重設為連接狀態且一直持續發送廣播給鄰近 Node。Gateway 與 BLE Node 連接後， 位於使用者端的 Web Portal 當做 CoAP Client，BLE Node 當做 CoAP Server，而使用者 可需求發送請求至 BLE Node，CoAP 封包轉換如 Figure 20 所示，於 Web Portal 端會將 IPv6 封包(Payload 包含 CoAP Protocol)發送至 Gateway，Gateway 收到此封包後(CoAP 封包於 4.4 節說明，Figure 36-40)，由位於 Gateway 上頭的 Bluetooth Dongle 發送 BLE 封包至 BLE Node，此 BLE 封包為 BLE Header，Payload 為 L2CAP Protocol，內容包含 Source address 與 Destination address，以及 CoAP 資料(可包含 Method 與 URI)(於 BLE 上抓取到包含 CoAP 資訊之封包於 4.4 節說明，Figure 41-42)。BLE Node 收到後，則根 據 CoAP 資訊執行相對應的處理(如:將感測器數值放入回應封包的 Payload 中，或者是 開啟位於 BLE Node 連接的相關設備等)。
34
Figure 20: CoAP 封包轉換
3.3 系統設計
本章節主要介紹 Server 與 Database 相關設計，其整體規劃主要可包含：系統需求、 Web Portal 設計、Local Database 設計以及 Cloud Database 設計，以下將分別說明。
3.3.1 系統需求
本系統設計之 Server，負責控管與 Server 進行註冊之 Gateway，且與 Database 建立 連結，並判斷目前情況做適當處置，如 Node 註冊，則判斷是否已註冊過，若無則相 Node 提供之相關資料存放至 Cloud Database。並提供系統管理者相關管理介面，可查 詢目前存放於 Database 中的相關表格與訊息。
3.3.2 Web Portal 設計
本系統採用 jQuery Mobile Web framwork 與 ASP.NET 開發 Web Portal。由於目前行 動裝置普及化，但是對於開發給行動裝置所設計之網頁，必須依照各種廠牌螢幕大小 進行畫面設計，為了讓系統提供的 Web Portal 能夠依照使用者目前的裝置大小提供更符
35
合使用習慣的畫面，以及行動裝置所處之平台相異(如:Android、iOS 與 Windows Phone 等)，開發者可能需要重新撰寫應用，但 jQuery Mobile 提供很好的解決方式。jQuery Mobile[48]為一套 JavaScript 函式庫，以 HTML5 為基礎，能夠設計出響應式 Web，且 相容行動裝置以及桌上型電腦的大小，自動調整 Web 配置。開發以 jQuery Mobile 設計 之 Web，可利用模擬器來模擬 Web 開啟於行動裝置之畫面，目前支援之模擬器，包含 Electric Mobile Studio、Windows Phone 模擬器、Opera Mobile Emulator 與 MobiOne Studio 等，本文使用 Opera Mobile Emulator[49]來測試 Web Portal。Web Portal 採用 Visual Studio 2010 撰寫 ASP.NET 網站，為了使用 jQuery Mobile 的 farmwork 須令 ASP.NET 支援，可 使用 Visual Studio 內建之 NuGet 套件管理員，直接下載 jQuery 與 jQuery Mobile 套件即 可使用。
3.2.2.1 CoAP.NET
Constrained Application Protocol(CoAP)[31]為 RESTful 的網頁傳輸協定，並且專為 資源受限的網路或節點所設計，為輕量級協定，因此，適合運用於佈署大量微型節點 的 IoT 環境中。由於目前 CoAP 已成為 RFC7252 標準[31]，實現 CoAP 協定的技術逐漸 增加且受到重視，現在已支援 CoAP 協定的方式，分為五種類型[50]，包含 Constrained devices、Server-side、Browser-based、Smartphones 與 Commercial implementations。 Server-side 包含以 Java 為基礎之 nCoAP、Leshan。C#為基礎則有 CoAP.NET、CoAP Sharp。 以 Python 為基礎則有 txThing、aiocoap 等。本系統的 Server 使用 C#撰寫，採用
36
CoAP.NET[51]，CoAP.NET 能夠實現在.NET 應用中以 CoAP 為基礎之服務。本系統為 驗證正確性，採用以 Firefox 瀏覽器的擴充功能 Copper[52]，Copper 在網址列輸入 CoAP URI 即可請求 CoAP Server 資源(實際測試於 4.4 節說明)。
3.3.3 Local Database 設計
本 系 統 初 步 規 劃 時 以 架 設 於 本 地 的 資 料 庫 為 測 試 之 用 ， 使 用 MySQL Workbench6.2[53]，提供 SQL 開發、伺服器配置與管理、使用者管理、備份以及建立 Enhanced entity-relationship(EER)模型等功能，初步設計資料庫時，可利用 EER 模型的 圖形介面，快速開發資料表、欄位、主鍵、外鍵、關聯性資料表連結等，如 Figure 21 所示，為本系統所規劃之 EER 模型。此外，建立完模型後，可利用 MySQL Workbench 所提供之 Synchronize Model 功能，將此規畫好的模型同步至資料庫中即可使用。
37 Table.3 使用者資料表 欄位 說明 資料型態 userNum 使用者編號(PK) INT userID 使用者帳號 VARCHAR(40) userPwd 使用者密碼 VARCHAR(45) phone 連絡電話 INT name 姓名 INT email 信箱 INT Table.4 使用者訂閱服務資料表 欄位 說明 資料型態 userNum 使用者編號(PK) INT userID 使用者帳號 VARCHAR(40) userService 使用者訂閱的應用服務 VARCHAR(45) gwdata_Service_num 服務編號(FK) INT
senseddata_nodeServiceNum Node 服務編號(FK) INT
userdata_userNum 使用者編號(FK) INT
Table.5 Gateway 資料表
欄位 說明 資料型態
Service_num 應用服務編號(PK) INT
gw_num Gateway 編號 VARCHAR(45)
gw_IP Gateway 的 IP 位址 VARCHAR(45)
node 所管的 Node 數量 INT
node_IP Node 的 IP 位址(FK) VARCHAR(45)
nodeServiceNum Node 提供的服務編號(FK) INT
nodeProtocol Node 所使用的通訊技術 VARCHAR(255)
Table.6 Node 感測服務資料表
欄位 說明 資料型態
nodeServiceNum Node 提供的服務編號(PK) INT
nodeIP Node 的 IP 位址 VARCHAR(45)
38
nodeSensedData Node 感測到的資料 VARCHAR(45) coapTag Node 的 CoAP URI 資訊 VARCHAR(225)
sensedTime 感測到資料的時間點 VARCHAR(45)
3.3.4 Cloud Database 設計
本系統為提供可靠、穩定之服務，且減少維護管理系統的成本，以 Microsoft Azure[30] 作為本系統之 Cloud Database，Microsoft Azure 提供期間試用服務，租用伺服器存放 SQL 資料庫。目前市面上提供雲端服務，包含：Google App Engine、amazon web service、 cloudControl 與 Microsoft Azure 等，由於本系統使用 C#撰寫，因此選用一定支援 C#的 Microsoft Azure。Microsoft Azure 提供許多功能，包含：部屬 Web 應用程式、創建虛擬 機器、SQL Database、機器學習等。SQL Database 提供大量擴充至數千個資料庫，並可 設定自動還原或資料備份，系統自我管理無須維護等。登入 Microsoft Azure Web Portal 後，選擇租用伺服器之位置，即可在此伺服器中創建 SQL Database，如 Figure 22 所示， 目前已成功創建 SQL Database 畫面且可與本系統連結。
Figure 22: Microsoft Azure Web Portal
3.3.4.1 遷移本地資料庫
於 3.3.3 節提到，原先以本地資料庫 MySQL 為測試之用，為遷移至 Microsoft Azure 上，使用 SQL Server Migration Assistant(SSMA)[54]工具，此工具能夠將既有資料庫轉
39
換至另一個資料庫(如 Figure 23 所示)，可轉換的項目，包含資料表結構、SQL 陳述式 與資料轉移等。支援的資料庫有 Oracle、Sybass、Access、MySQL，SSMA 可提供轉移 至 SQL Server 與 Microsoft Azure。
Figure 23: SSMA 工具轉換資料庫成功之畫面
3.3.4.2 連接 Cloud Database
Microsoft Azure 為開發者快速使用雲端資料庫，提供連接字串，其支援語言包含 ADO.NET、PHP、Python 與 JDBC。於設計之 Web Portal 中修改資料庫連接字串，系統 管理者登入系統後，列出於的 Microsoft Azure 所有資料，並可直接進行刪除新增等管 理動作，如 Figure 24 所示，為本系統的管理者畫面。
40
Figure 24: 管理者畫面
3.4 使用者應用：以室內環境監控為例
實際架設本系統設計之智慧型 Gateway，並規劃使用者應用，以室內環境監控為例 子。本系統提供簡單易用的 Web Portal，令使用者無需繁複操作即可使用 IoT 環境所提 供之服務。Node 部屬於 6LoWPAN 環境，並由 Gateway 配給 Prefix，Node 可自行組成 IPv6 address，代表當作 CoAP Server，且可提供 CoAP Resource。使用者進行註冊過後， 可使用目前訂閱的服務，如 Figure 25 所示，有捲軸可以滑動選擇所需服務，On demand 按鈕則可傳送 CoAP Request 至提供此服務的 CoAP Server，並顯示結果於下方，可以看 到感測的實際數值並存入資料庫內，以及會判斷目前狀態為 Fresh air、Low pollution 與 High pollution。Periodical 按鈕則會顯示出感測數值圖表，如 Figure 26 所示。Control Fan 按鈕則可依照目前情況作適當的開啟或關閉風扇，實際接線如 Figure 27。由於開發板 通常不支援大電壓(如家電產品通常需較多的電壓來驅動，本系統以風扇為例，小型風 扇額定電壓為 12V)，nRF51-DK 所提供的電壓為 3.3V 與 5V，因此，需要升壓模組來 利用小電壓驅動大電壓，本系統採用 LM2577 升壓式 DC-DC 模組(輸入 3V-30V，輸出 4V-40V)，調整升壓模組上的旋鈕，可調整輸出電壓(Figure 26 所示，調整輸出至 11.7V)，
41
此外，使用電晶體 2N2222 來模擬開關，在使用者按下 Control Fan 按鈕後，會送出 CoAP 封包(包含 CoAP Method 為 PUT，其 Payload 設定為 1，代表開啟風扇)，Node 收到後則 會傳遞開啟風扇，若已為開啟則會將風扇關閉，達到控制室內設備的能力。
Figure 25: CoAP Request Figure 26: 感測數值圖表
42
第四章 實測結果
本章節介紹本文之系統設計之實測結果，包括與 BLE Node 建立連線、BLE 6LoWPAN Module、Gateway 封包轉換、提供 CoAP 服務與 Microsoft Azure 資料庫測試。
4.1 與 BLE Node 建立連線
本節實驗目地為令 Gateway 上的 Bluetooth Dongle 抓取與 BLE Node 之間所傳遞的 封包，以及與 BLE Node 建立 L2CAP 流程是否正確執行。首先，須使用 Wireless Sniffer 或 BlueZ 提供的 hcidump 套件抓取無線 BLE 封包，本系統使用 hcidump 套件，執行監 聽藍牙之間傳送封包。查詢目前藍牙設備(Bluetooth Dongle)的狀態，如 Figure28 所示， 目前狀態為 UP RUNNING(啟動中)，代表此設備已經開始運作。
Figure 28: Bluetooth Dongle 資訊
先前於 3.2.3.2 節說明，由於 BLE Node 需要取得 IP 位址，因此，BLE Node 與 Bluetooth Dongle 須先建立 L2CAP Channel，且 kernel 需支援藍牙使用 6LoWPAN 連接， 成功建立與 BLE Node 的連線後，建立連線之 BLE 封包如 Figure 29 所示，紅框(B)為 BLE Node 的 Public Bluetooth Address，代表與此 BLE Node 建立連線事件，並可使用 L2CAP Channel 傳遞 6LoWPAN 封包。
43
Figure 29: L2CAP 連線建立之封包
4.2 BLE 6LoWPAN Module
本節實驗目的為觀察 Bluetooth Dongle 與 BLE Node 之間建立連線後，所產生的虛 擬 bt0 介面。如上節所述，與 BLE Node 建立 6LoWPAN 之連線成功後，可查詢到 Gateway 上的網路介面已新增虛擬的 bt0 介面，如 Figure 30 所示，可看到此介面的詳細資訊， 包含此介面的 IPv6 Link-local address 與 Global address 等。此外，需利用 RADVD(於 3.2.3.2 說明)機制令此介面發送 Gateway 的 Prefix。
44
Figure 30: 虛擬 bt0 介面
4.3 Gateway 封包轉換
此節實驗目的為觀察 Gateway 是否將收到的 BLE Node 所傳送的 6LoWPAN 封包， 由 Kernel 內的 6LoWPAN Module 轉換為 IPv6 封包，並依照目的地的環境(IPv4 或 IPv6) 做適當的處理。本系統測試封包是否會正確執行轉換，在 Server 端下 PING 指令，由 BLE Node 回應 PING 結果。首先，如 3.2.4 節中 Figure 18 所示，於 Gateway 上的 Bluetooth Dongle 抓取與 BLE Node 之間傳遞的 6LoWPAN 封包。抓取結果如 Figure 31-32 所示， 為利用 BlueZ 提供的 hcidump 套件抓取到於 BLE Node 上傳遞之 6LoWPAN 封包，由圖 中可看出此封包由 BLE Node 送至 Server 端，橘框(A)處 remote 為 BLE Node，localhost 為 Gateway 上的 Bluetooth Dongle。紅框處(B)為 Source address，代表為 BLE Node 的 IPv6 Global address，綠框處(C)為 Destination address，代表為 Server 的位址。
45
Figure 31: 6LoWPAN 封包(a)
Figure 32: 6LoWPAN 封包(b)
在 Bluetooth Dongle 收到 BLE Node 傳送的 6LoWPAN 封包後，會將封包送至 Kernel 內的 6LoWPAN Module，由 6LoWPAN Module 將此封包轉換為 IPv6 封包，傳送至虛擬 bt0 介面，如 Figure 33 所示，為監聽 bt0 介面(橘框標示處 A)的結果，可看出此封包的 Header 包含位址資訊，紅框(B)為 Source address，代表為 BLE Node，綠框(C)為 Destination address，代表為 Server 位址。藍框(D)代表此封包為 IPv6 封包。此外，bt0
46
介面會將此 IPv6 封包傳送至 Tunnel 6to4 介面。
Figure 33: 6LoWPAN Module 還原成完整 IPv6 封包
Tunnel6to4 收到此封包後，判斷 Destination 位址是否需要進行封裝，Figure 34 為 Tunnel 6to4 介面進行封裝後於網路卡(橘框(A)eth0)抓取到的結果，紅框(B)為 Source address，代表為 BLE Node，綠框(C)為 Destination address，代表為 Server 位址。藍框(D) 為此封包為 Tunnel 6to4，其結構為外層具有 IPv4 Header、內層 IPv6 Header 資訊。
47
Figure 34: Tunnel6to4 封包
4.4 提供 CoAP 服務
本節實驗目的為測試本系統所架設的 BLE Node 是否支援 CoAP 協定(CoAP 於 3.2.5 節說明)，以及正確提供 CoAP Method(如 GET 與 PUT)，令使用者取得感測服務。如 Figure 35 所示，使用 Firefox 提供之外掛套件 Copper[52]，於網址列上輸入 BLE Node 節點的 CoAP URI，並點選 Discovery 按鈕，此外，BLE Node 在 CoAP 協定中為 CoAP Server 的角色。左邊選單則會列出此 CoAP Server 提供之 Service，如 Figure 35 左側所示，可 看出目前佈署了空氣感測、風扇與 LED 控制。如選擇 AirQuality，會將 BLE Node 上的 空氣品質感測器上的感測數值放置 Payload，並顯示目前 CoAP 的 Response Code 為 2.05 Content。
48
Figure 35: CoAP Cooper 介面
CoAP Server 會先傳輸自身的 Profile 到 CoAP Client 端，其封包內容如 Figure 36 所 示，紅框處為此 CoAP Server 所提供的 Service，包含空氣品質感測、風扇控制與 LED。
Figure 36: Node Profile
49
Portal，選擇請求 CoAP Request，則會發送 CoAP 封包，紅框處可看出請求的服務為 AirQuality，向此 CoAP Server 請求感測服務(CoAP Method 為 GET)。Figure 38 為 CoAP Server 回應請求之封包，紅框處可看到空氣感測器所感測的數值為 177，並可看出 Response Code 為 2.05 Content。
Figure 37: CoAP GET 封包(a)
Figure 38: CoAP GET 封包(b)
Figure 39 為在 Wireshark 抓取到的 CoAP 封包，使用者可利用本系統提供之 Web Portal，選擇請求 CoAP Request(若為手動控制風扇)，則會發送 CoAP 封包，紅框處可 看出請求的服務為 Fan，設為 1 代表開啟風扇(若判斷已設為 1，則會傳送設為 0 代表關
50
閉風扇)。向此 CoAP Server 請求控制服務(CoAP Method 為 PUT)。Figure 40 為 CoAP Server 回應控制之封包，紅框處可看出 Response Code 為 2.04 Change，並改變 CoAP Server 目前的狀態，CoAP Server 收到後則會執行對應動作。
Figure 39: CoAP PUT 封包(a)
Figure 40: CoAP PUT 封包(b)
先前於 3.2.5 節所述，位於 Gateway 上頭的 Bluetooth Dongle 發送 BLE 封包至 BLE Node，此 BLE 封包為 BLE Header，Payload 為 L2CAP Protocol，內容包含 Source address 與 Destination address，以及 CoAP 資料(可包含 Method 與 URI 等)，如 Figure 41-42 所 示，Payload 與 Figure 39-40 相同，但在 BLE 封包中以 L2CAP 協定格式，並傳送於 L2CAP
51
Channel 中。
Figure 41: 包含 CoAP 資訊之 BLE 封包(a)
Figure 42: 包含 CoAP 資訊之 BLE 封包(b)
4.5 Microsoft Azure 資料庫測試
52
Microsoft Azure[30]作為本系統之 Cloud Database，Microsoft Azure 提供期間試用服務， 租用伺服器存放 SQL 資料庫。於 Azure 的 Portal 中可使用已安裝好的 Visual Studio 開 啟資料庫，畫面如 Figure 43，可看到此資料庫位置存放於 Azure 提供的伺服器中， 0516test 為本系統所使用的 SQL 資料庫名稱，以及先前於 3.3.4.1 節所介紹之 SSMA 工 具已成功遷移所有本地資料庫的結構與資料內容。
53
第五章 結論與未來展望
5.1 結論 在本研究中以設計智慧型 Gateway 為主，並整合物聯網中的異質性為目標，包含 BLE、 6LoWPAN、IPv6、IPv4、Ethernet 與 WiFi。 (1) 整合通訊協定異質：BLE 協定的節點在物聯網中通常負責感測資料，但 BLE 協定 與 Ethernet、WiFi 等無法溝通，因此，於本研究所設計之 Gateway 上擴增連網介面， 並能夠將正確處理異質封包，達到已 Gateway 整合物聯網中的異質通訊之目的。 (2) 連網技術共存：由於 BLE 協定本身並未支援連網技術，而本研究設計之 Gateway將收到的 BLE Node 所傳送的 6LoWPAN 封包，由 Kernel 內的 6LoWPAN Module 轉換為 IPv6 封包，並正確的傳送至目的地。此外，本系統考量到目前 IPv6 的使用 率不高，令 Gateway 具備處理 IPv6 或 IPv4 封包之能力，並利用 Tunnel 6to4 機制， 依照目的地的環境(IPv4 或 IPv6)自動地執行適當的封包轉換。
(3) 達到 End-to-End Communication：本系統所架設之 Node 能夠直接與遠端設備進行 溝通與取得節點提供的服務，且兩個端點並不會得知有一個 Gateway 當作中介橋梁 的轉換。因此，本研究亦實現節點與遠端設備之間的雙向的端對端通訊，成功進行 Global 的 End-to-End Communication。
(4) 服務發現機制：使用 CoAP 協定發現可用服務與傳遞命令，節點會將自身 Profile 傳至 Server，並存放於 Data Center 中，供使用者後續需求使用。此外，BLE Node 支援 CoAP 協定以及正確提供 CoAP Method(如 GET 與 PUT)。
54 (5) 提供友善的(Friendly)使用介面：在本系統中所佈署之 BLE 節點提供感測與控制室 內設備的服務，使用者利用本系統提供的 Web Portal 訂閱所需服務。 (6) 結合雲端服務：本系統為提供可靠、穩定之服務，且減少維護管理系統的成本，結 合目前雲端 SQL Database 本系統之資料處理與儲存。使用者無須了解細節與流程， 只需使用本系統提供之 Web Portal，便能輕易的取得感測服務。 5.2 未來展望 本系統規劃之未來展望包括： (1) 整合多種異質技術：本系統已成功整合 BLE、WiFi、6LoWPAN、Ethernet 之間的異 質環境，未來希望整合各種不同異質技術，令 Gateway 能夠處理的異質性提升，令 本系統計劃的智慧型 Gateway 能夠更加完善。 (2) 智慧型手機結合 Gateway：規劃以智慧型手機為物聯網中的 Gateway 角色，結合進 本系統中。 (3) 雲端服務擴增：未來將尋找更適合本系統的雲端服務，在感測資料大量產生時，如 何有效進行分析、處理以及儲存也為一大挑戰。
![Figure 1: BLE 與 BLE 6LoWPAN Stack(改編自[17][18])](https://thumb-ap.123doks.com/thumbv2/9libinfo/7437165.108651/19.892.79.824.311.954/Figure1BLE與BLE6LoWPANStack改編自1718.webp)
