出遅れた老舗「oneM2M」、Alljoyn連携で巻き返しなるか：IoT観測所（15）（2/3 ページ）

[大原 雄介，MONOist]

oneM2Mの実装

　話を戻すと、oneM2Mに準拠するデバイスやサービスは基本的に、AE／CSE／NSEのどれかに属している必要がある。そしてAEとCSEはMca、CESとNSEはMcn、CSE同士はMccという接続方法で定義される。最初の“Mc”は“M2M communications”の略で、次が「何と接続するか」を示しており、aがAE、cがCSE、nがNSEとなるわけだ。

　これらを組み合わせた実際の利用シーンの一例がこちら（Photo03）となる。一番上位のIN（Infrastructure Node）はサーバなどを想定しており、MN（Middle Node）はゲートウェイ機能も兼ね備えたノード、ADNはいわゆる末端のエンドポイントとなる。どのノードにおいても、アプリケーション（xx-AE）はCSEと接続する形になっており、NSEはアプリケーションからは見えない形になっているのが分かる。

Photo03：「AE」「CSE」「NSE」の組み合わせ例（Figure 6.1-1より抜粋）

　oneM2M非互換なデバイスノードを排除する訳ではなく、MNあるいはASNに接続されているのがPhoto03でも確認できるが、Photo03にもあるようにこれは「out of scope」、つまり仕様の範囲外とされている。実際にはある種のネットワークとoneM2Mを接続するためのブリッジが提供されることになるだろうが、oneM2Mの仕様はそこまでは言及しないということらしい。

　ではCSEは何を提供してくれるのか？というのが次の話題であるが、Photo04がその概略である。あくまで概略なので、例えばロケーションサービスならばどんなサービスを使ってどんな精度でどんな情報を提供してくれるのかといった細部の議論は残るが、主にM2Mで必要とされるであろう情報や機能をほぼ網羅した形となっている。

Photo04：CSEが提供するサービス（Figure 6.2-1より抜粋）

　ちなみにoneM2M自身は、それ単体でアプリケーションフレームワークを提供する訳ではない。既存のM2Mのフレームワークやエコシステムを提供している事業者が、そこにoneM2Mのサービスをマッピングする形で実装を行うことになる。つまりこれまで独自のAPIとかプロトコルを利用して実装されているものを、oneM2M準拠の形に変える、もしくは独自APIなどと並行してoneM2M準拠のAPIやプロトコルを追加するといった対応が求められることになる。

　ただこれが実現すれば、これまで業種別というか下手をするとフレームワーク別にそれぞれ独立していた小さなエコシステムが、業種やフレームワークの垣根を越えて相互に接続が可能になる、より大きなエコシステムを構築できることになる。「それにメリットがあるのか？」というのはよく言われる話だが、新しいサービスが可能になると、それを生かした新しいビジネスが生まれてくるのは、昨今のクラウドの興隆がそれを証明している。