Gateway 封包轉換

Gateway 封包轉換，如 Figure 18 所示，本文實際測試之結果說明如下，由於系統

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 詳細說明。

Figure 18: Gateway 封包轉換

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 封包轉換