OneM2M (6): 資料流程圖 data flow

一般來說, 我們會從兩個角度描述一個通訊網路的關係,

首先, 我們會有一張系統架構圖,

用來描述各裝置的位置, 以及相互之間的關係,

如果更詳細一點, 應該要畫出裝置中各元件在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),

在架構中, 大致上, 我們可以看到這是標準的oneM2M架構,

一個LAN, 一個WAN, 中間有一個M2M Gateway (Middle Node),

從文字中 (9.1.3), 我們可以得到更多資訊,

例如, 該LAN是設想為Zigbee或是Bluetooth, 而非WLAN常見的wifi,

WAN則沒有進一步的說明,

而這一個use case的目標則是為了提供家中的電源管理,

使用者可以透過終端裝置 (圖中ICT devices),

查看當前的使用狀況, 並進一步的控制.

圖9.1則提供了資料交換的流程,

從圖中, 我們可以猜測gateway是一個middle node,

終端感測器 (devices) 或許是一個無CSE能力的AE,

因此, 需要comm. operator來幫忙資料轉傳至gateway,

另一方面, 使用者可以透過oneM2M的標準, 訂閱此服務,

並透過oneM2M的標準取得感測器資訊 (step 2-6), 或是下達控制命令 (step 7-10),

同時, middle node也具備下達指令的功能 (step 3a, 3b),

或許可以根據預先定義的程式, 對於及時蒐集的資料作出反應.

然而, 這裡我們仍只能大略的知道資料的流程,

更詳細的資料交換細節, 例如, 訂閱服務的認證機制等,

在這份文件中都沒有仔細介紹, 可能要進一步查閱TS的內容,

Castle on a Cloud