Castle on a Cloud

一般來說, 我們會從兩個角度描述一個通訊網路的關係, 首先, 我們會有一張系統架構圖, 用來描述各裝置的位置, 以及相互之間的關係, 如果更詳細一點, 應該要畫出裝置中各元件在SPEC中的定位, 以及裝置間個連線, 在SPEC中所使用的接口, 接下來, 我們需要有另一張資料流程圖 (data flow), 來表示控制訊息和資料訊息在裝置間(或是元件間)的時間關係. 然而, 不幸的是, oneM2M的TR0001雖然提供了大量的使用案例, 但是每一個案例的細節卻參差不一, 若以較為嚴格的標準來看, oneM2M提供的案例, 都無法直接的套入框架, 不過, 我們仍找一個較為完整的案例作為範例, 說明如何了解oneM2M的資料流程, 我們以9.1的Home Energy Management為例(pp. 73, TR0001 V2.4.1), 一開始, 違建會先用文字介紹環境以及目標 (9.1.1 Description), 接下來, 介紹會出現的裝置和標準 (9.1.3 Actors), 這一部分可以看做系統架構圖的文字版, 幸運的是, 該使用案例有畫出系統架構圖 (figure 9.2), 來自:  http://www.onem2m.org/images/files/deliverables/Release2/TR-0001-Use_Cases_Collection-V2.4.1.pdf

通常, 我們寫通訊架構的文章資料來源有二: 上網搜尋閱讀別人摘要, 或是閱讀SPEC, 閱讀別人的資訊再整理, 的確能夠快速地了解架構, 然而, 畢竟是二手資訊, 如果仍有疑問, 還是要回到官方的文件, 也就是SPEC上 OneM2M的SPEC和3GPP的形式一致, 分成TS (Technical Specification) 和TR (Technical Report), 網址如下: http://www.onem2m.org/technical/published-documents TS是正式的SPEC, 會規範通訊中的細節, 以TS 0001為例, 標題為: Functional Architecture, 裡面就涵蓋了之前文章的多數內容, 比如說, 在第6章, "oneM2M Architecture Aspects", 就介紹了四種節點 (Node) 的定義與相互的角色, 包括: Application Service Node, Application Dedicated Node, Middle Node, Infrastructure Node, 然而, 由於這是SPEC文件, 所以不會有詳細的說明和舉例, 通常只有一到兩句的定義 TR則是在定義SPEC之前討論所產生的技術文件, 以TR 0001為例, 標題為: Use Cases Collection, 就集結了各家提出來OneM2M的使用環境設定, 通常, 我們會從這份文件讀起, 嘗試了解SPEC定義者心目中應用架構, 再一步步推廣到其他細節. 不過, OneM2M和3GPP的SPEC仍有很大的差距, 根據我之前讀TR的經驗, 3GPP文件不論是圖, 表, 文字, 內容, 都十分一致, 但在OneM2M的文件中, 卻有一種像是剪貼簿的感覺, 只是把各家報告複製貼上, 而缺乏整合...

讓我們在這裡總結一下前幾篇文章對oneM2M的介紹, 並嘗試系統化oneM2M的架構. 在oneM2M的架構中, 分成3種基本單元: AE: Application Entity CSE: Common Service Entity NSE: Network Service Entity 以上3個單元, 分別對應於Application Layer, Service Layer和Network Layer, 其中, 在之前文章中, NSE沒有詳細的介紹, 根據定義, NSE provides connectivity services to the CSEs besides the pure data transport. 換句話說, NSE提供CSE基本的資料傳輸功能, 用以建立網路, 若以在網路中的角色來分配, oneM2M有4種不同的節點: Application Dedicated Node Application Service Node  Middle Node  Infrastructure Node. 這四個節點以Middle Node為界, 分屬於兩個網路: M2M網路, 網際網路, 或是以oneM2M的術語來說, 就是field domain 和 infrastructure domain, Middle Node像是gateway一樣, 扮演兩個網路之間資料轉傳的角色, Application Dedicated Node和Application Service Node的差別在於CSE的有無, 換句話說, 若是傳統無oneM2M的裝置, 即是Application Dedicated Node, 若有CSE層, 則是Application Service Node, Application Dedicated Node和Application Service Node同屬於M2M網路中的節點, 關係如下圖: 來自:  https://www.slideshare.net/Hamdamboy/one-m2m-66797390

交大資工林甫俊老師有一篇文章介紹OneM2M, 很值得一看: http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 在該篇文章中, 借用了我們較為熟悉的網路流程, 也就是: 感測器->資料庫->應用, 的架構, 並定義了兩種網路: M2M設備網路, 以及M2M核心網路, 其中介於兩種網路之間, 就是閘道 (gateway), 因此, 架構圖就會表示如下圖: 來自於:  http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 對照 上一篇文章 中的圖示, 我們可以找到其對應關係: Application Service Node (應用服務Node): M2M設備區 Middle Node (中間Node): M2M閘道 Infrastructure Node (基礎設施Node): M2M網路區

在 上一篇文章 中, 介紹了OneM2M的目標以及所處位置, 在這一篇文章中, 將繼續介紹在OneM2M中, 裝置所虛擬化的基本單元. 不同於一般行動網路的通訊協定, 定義了核心網路以及接取網路的架構, OneM2M不提供網路服務, 所以沒有核心網路的設計, 而把自己視為一個轉介層, IoT終端透過此轉介層, 回傳所收集的資料, IoT的應用服務, 也透過此轉介層, 訂閱所需要的資料, 因此, 在OneM2M的架構下, 可以區分出兩個主要的基礎單元: AE (Application Entity): 可以是裝置, 也可以是應用服務 CSE (Common Services Entity): 提供OneM2M溝通介面的裝置 其中關係如下圖所示: 來自:  https://www.slideshare.net/onem2m/onem2m-release-1-primer/54

OneM2M:  http://www.onem2m.org/ 在之前的一系列文章中, 介紹了許多IoT的協定, 其中, 考慮到IoT裝置的省電需求與運算能力限制, 通常不會賦予完整的應用, 而是以資料蒐集, 處理, 以及傳輸為主, 對於IoT應用的架構者而言, 通常是藉由資料庫的查詢, 取得收集的資料, 並透過控制指令, 間接的操作IoT終端裝置, 對於像是SigFox這種封閉式平台當然沒問題, 只要設定好回傳的資料, 週期, 等參數設定, 就能夠自動地把資料回傳到SigFox的資料庫, 而使用者可以直接對資料庫進行操作, 抓取資料做進一步分析. 然而, 對於Bluetooth, Zigbee之類的通訊協定要怎麼處理呢? 這些通訊協定, 通常只定義了MAC和PHY的通訊協定, 而不包含TCP/IP層的協定, 無法提供後端聯網功能, 因此, 在過去, 都是由開發者自行處理資料的轉傳, 儲存與處理, 好處是開發者可以掌控所有細節, 但也堆高了開發成本, 無法像SigFox一樣包裝成應用服務使開發者容易上手.