SCATLINE Vol.97

SCATLINE Vol.97

May, 2015

SEMINAR REPORT

oneM2M 標準化；初期リリースの概要と今後（Telecommunications Industry Association）や ATIS（Alliancefor Telecommunications Industry Solutions）などの成果を持ち寄ることで始まりましたが、実際はその時点で最も先行していた欧州の ETSI（European Telecommunications Standards
Institute）の仕様書がベースとなりました。
oneM2M の周辺には、例えば携帯電話の 3GPP/3GPP2 という標準化団体があり、他には OMA（Open Mobile Alliance）、固
定網の BBF（Broadband Form）などの標準化団体もあって、

日本電気株式会社
第二キャリアサービス事業部
シニアエキスパート

小林 中 氏

これらと協調して進めて、もしその団体に使える標準仕様があるなら、それも再利用していく、というスタンスで取り組んでいます。
また oneM2M は各業種・業界セグメントからの参加を歓迎し、IoT（Internet of Things）というのは、色々な方が様々な解釈をしています。本日は M2M の標準化について、事業部サイトの観点からご説明します。日本の標準化では、IoT と M2M（Machine to Machine）をあまり区別せず、M2M をできるだけe-Health 系の団体である Continua、HGI（Home Gateway
Initiative ：ホームゲートウェイの標準化団体）、ESMIG（European Smart Metering Industry Group：スマートメータ関連の標準化団体）などと連携しています。

広範囲に、幅広く標準化しようと取り組んでいます。本日の話は、第1 部と第2 部の構成になっています。
第1 部ではoneM2Mの初版のリリースについて、第 2 部では次期以降についてお話します。

次に oneM2M の実際の標準化作業はまず、
ユースケースに関する TR（Technical Report）を完成させ、要求条件（リクワイ
アメント）
を集めて、
その仕様書を完成させます。
これは Stage1と呼ばれています。その次に、要求条件を実現するためのアー第 1 部の資料の一部については、ARIB と TTC が共催で行ったセミナー「M2M 標準化最新動向」の内容を見直して、最新化したものとなっています。第 2 部でご紹介する Underlying
Network との連携、セマンティックスサポートについては、弊キテクチャを検討して、その仕様書を完成させます。これがStage2 です。
2014 年 8 月に、プロトコルの仕様書、デバイス管理仕様書、
セキュリティ関連仕様書を含めて、初版の仕様書をリリースし社が取り組んでいる、あるいは取り組みたいという観点で取り上げさせていただきます。

ました。その後、外部からのパブリックコメントを募集し、コメントを反映し、2015 年 1 月に改訂版をリリースするという段取りになっています。
2014 年 12 月 9 日に、欧州 ETSI の協力を得て、oneM2M 初

oneM2M 技術仕様

版リリースのためのイベントとして、色々なデモ機を複数のベンダが持ち寄って、
フランスでプロモーションを行ないました。
12 月の現時点では、色々なコメントが反映された正式な初版リリースに向けて取り組んでいるところです。

最初に「oneM2M の意義と初版技術仕様書の公開」について
ご説明します。
2012 年 7 月に、M2M の統合したサービス層の標準化を行う組織として、oneM2M と呼ばれる団体が設立されました。そこ
では M2M のサービス層に注目して、要求条件、機能アーキテ
クチャ、プロトコル、セキュリティを中心に検討が行われました 。 当 初 は 、 各 国 の SDO （ Standards Development

主要な Verticals（業界団体）においても、この oneM2M の仕様への関心が高まっており、今後積極的に Verticals にもoneM2M を広めていきたいと考えています。

Organization：標準化団体）からの成果物をベースとして検討
が 始 ま り ま し た 。 日 本 の TTC や ARIB 、 米 国 の TIA(1) oneM2M の概要
ETSI では、2009 年 1 月から M2M サービスの標準化が進め
15

SCATLINE Vol.97

られていました。そのような状況下で、米国の TIA、中国のウェイなどであり、M2M エリアネットワークは、具体的にはCCSA（China Communications Standards Association）など、各国の標準化団体も自国の M2M の標準化を行うということで、作業があちこちで始まってきました。かたや OMA、BBF などの関連する標準化団体でも、自ら M2M の標準化を手がけると小電力無線、ZigBee、Bluetooth などです。ただし、M2M ゲー
トウェイと M2M エリアネットワークは、必ずしも実装される必要はなく、中には最下層のデバイスからネットワークに対して直接アクセスするパターンもあります。

いうことで、標準化活動が乱立してくるという状況となり、作業が重複したり、市場が分断したりするという懸念が生じました。そのような背景がトリガーとなって、M2M 共通の標準化
ソリューションに向けて M2M サービス層の標準化活動を統合

図 2 の右側が M2M 各階層に対応する標準化団体です。M2M
アプリケーションは各種サービスのことで、各業界それぞれのスタンダードなり、ノウハウなりで規定されています。M2M プ
ラットフォームの標準化は、欧州の ETSI で先行して標準が作し、グローバルなイニシアティブの設立を検討するということ
で、ETSI が提唱して始まったのが oneM2M です。2011 年 12月に各国の 7 つのテレコム通信標準化団体が集まって、設立に基本合意して、2012 年 1 月に oneM2M という名称で発足しま成され、その後世界の 7 つの団体が集まって、oneM2M の標準化作業が始まりました。ネットワークアクセスは、3GPP、
3GPP2 などが活発に標準化を行っています。M2M ゲートウェ
イは、OMA、BBF などが活動していて、oneM2M でも標準化した。図 1 右下に示すのが 7 団体です。正式な発足は 2012 年
7 月です。

を行っています。M2M エリアネットワークは、ZigBee や
Bluetooth にて標準化を行っています。最下層の M2M デバイスにも oneM2M の規定が絡んでいますが、デバイス製造の詳細なインプリではなく、oneM2M サービスのために機能配備すべきロジカルな仕様に関して規定します。

図 1 oneM2M：M2M 標準化のための統合組織
組織の特徴としては、一つは 3GPP と類似の形態をとり、これら各国の標準化 7 団体が共同で運営する仮想的な組織であることです。もう一つは、oneM2M では複数の M2M アプリケー
ションにまたがる共通のユースケースとアーキテクチャに基づいて検討します。その第一歩としてフォーカスするのは M2Mのサービスレイヤです。別の言い方をすると、M2M サービス

図 2 M2M のレイヤ構造と標準化対応
続いて、oneM2M が規定する M2M サービス層についてご説明します。

プラットフォームまたはミドルウェアにフォーカスします。三つ目の特徴として、oneM2M は電気通信関係の標準化団体が結集して始めた活動ですが、各業種・業界セグメントに対しても積極的に協調・連携していくということです。

M2M アプリケーションと M2M デバイスに対して、
CommonService Function と呼ばれている共通のサービス機能を提供します。これは共通プラットフォーム、もしくはミドルウェアに相当すると考えていただいてよろしいかと思います。

M2M の機能を標準化することのベネフィットは大きく二つあります。多数のプロバイダによる相互接続、相互運用可能なコンポーネントを使えることと、スケールメリット（規模の経済性）を利用できることです。要するに、M2M 市場からの期

具体的な機能の例としては、
リモートデバイス管理機能です。
これはデバイス管理機能もしくはデバイスマネジメントと呼ばれていて、皆さんもよくお使いの携帯電話やスマートフォンな
どで、リモートから端末を診断したり、ファームウェアをアッ

待感が高まっているということです。
M2M と構造とその標準化の対応について簡単にご説明します（図 2）。
図 2 の左側が M2M 階層（レイヤ）です。上から順に M2M

プデートしたりといった仕組みです。このような携帯電話で使われているデバイス管理機能は、M2M のセンサや M2M デバイ
スでも使えるということで、重要な機能の一つとなっています。
次には、通信管理・接続処理機能です。これは基盤ネットワー

アプリケーション、M2M プラットフォーム、ネットワーク（アクセス＋コア）となっています。M2M アプリケーションは、通常言われているところのサービスやアプリケーションです。
M2M プラットフォームが今回 oneM2M で対象とするサービス

クを信頼性・拡張性を維持しつつ、効率的に使うためのものです。あとは、データ管理、アプリケーション管理、セキュリテ
ィ、課金、加入管理等の機能が共通的に提供されます。
各業界団体が重複して開発するのではなく、共通的な機能がプラットフォームです。ネットワークは、携帯電話、光電話な
どのコアネットワーク及びそのアクセスネットワーク部分です。
その下に M2M ゲートウェイがあり、さらにその下に M2M エリアネットワークとあります。最下層は M2M デバイスです。

あるからそれを使ってもらう。そうすることで、サービスの導入が安価で容易にできるというのがここの狙いです。
oneM2M の組織構成について簡単にご紹介します。図 3 は、2014 年 12 月現在の組織構成です。

M2M ゲートウェイは、ホームゲートウェイやビジネスゲート
16

SCATLINE Vol.97

AE と CSE とのやり取り、CSE と NSE とのやり取りなど、エンティティ間を相互接続するところが参照点となります。デバイス内の通信も、サーバ内の通信も、デバイスとサーバを跨いだ通信も、全てエンティティ間の通信によって実現されます。
oneM2M では 4 つの参照点を定義しています。
Mca は AE-CSE
間、Mcn は CSE-NSE 間、Mcc は CSE 同士の参照点です。Mcc’は異なるサービスプロバイダとの相互接続のための CSE-CSE間の参照点です。

図 3 oneM2M の組織構成
Steering Committee（運営委員会）があって、その下にFinance,
Legal, MARCOM（Marketing & Communication）, MP（Methods& Process）という 4 つのサブコミッティがあります。
Steering Committee の下には Technical Plenary（技術総会）があり、この中で実際に標準化が行われています。Technical
Plenary には 5 つのワーキンググループがあって、そこでそれ
ぞれリクワイアメント、アーキテクチャ、プロトコル、セキュ
リティ、MAS（Management Abstraction & Semantics）のグループに分かれて検討を行っています。11 月に 6 つ目のワーキン

図 4 oneM2M が目指す M2M 市場構造の変革

ググループのテストができました。
仕様を制定するだけでなく、テストして認定するところまで行なおうという動きがあり、それを専門に行うワーキンググループが定義されました。
Technical Plenary の Chairman は米国 TIA の人ですが、Vice
Chair に KDDI の山崎氏が就任されました。山崎氏は、前回一期二年間 Vice Chair を務められて、11 月の改選があって、引き続き二期目も担当していただくことになりました。
(2) oneM2M 標準化の特徴と狙い
oneM2M が目指しているのは、これまで個別に取り扱ってきたモノの情報を、縦割りのサービスの境界を越えて組み合わせ
たり再利用したりすることで、新しい価値、新しいサービスを

図5

oneM2M 機能アーキテクチャ

創造しようという取り組みです。
図 4 にあるように、自動販売機、交通など様々な業種に閉じたサービスが乱立しています。Vertical Player（業種）が乱立していると、そこではデータの定義も独立で、ソリューションも

oneM2M の標準化というのは、
3 つのエンティティ（AE, CSE,
NSE）の中の振る舞いを決めることと、エンティティ間の参照点を規定することを行っています。
図 5 は論理的な構成でしたが、図 6 は物理的な実装に近いイ

独立しています。これでは将来の発展、IoT に向けた発展ができないということで、水平展開して業種を越えて収容し、新サービス、総合的なソリューションを実現しようというのが狙いです。

メージです。

oneM2Mの機能アーキテクチャは図5のようになっています。
左の Field Domain がデバイス側で、右の Infrastructure
Domain がサーバ側（インフラ側）となります。中央に示す階層構造は、上からアプリケーション層、次に共通プラットフォーム層（ミドルウェア）、下にネットワークサービス層という 3つの階層となっています。それぞれのレイヤに対応する機能エンティティとしては、アプリケーションは AE（Application
Entity）、共通プラットフォームは CSE（Common Service
Entity）、ネットワークサービスは NSE（Underlying Network
Service Entity）であり、この 3 つのエンティティをデバイス側に配備し、同じようにサーバ側にも配備する。これによりデバ
イスやサーバの機能を実現します。

図 6 oneM2M アーテクチャ（実装イメージ）
点線から上側が Infrastructure Domain で、下側が Field
Domain となっています。インフラストラクチャドメインは IN

デバイスの内部でも色々とデータのやり取りが行われます。

（Infrastructure Node）を想定していて、サーバと考えていただ
17

SCATLINE Vol.97

ければよいです。フィールドドメインは、上の方がゲートウェを再利用することになっています。

イの階層で、MN（Middle Node）を想定していて、M2M ゲー
トウェイや中継ノードがあります。下の方に M2M デバイスがあります。IN、MN、M2M デバイスには、機能エンティティのAE と CSE を論理的に配備します。これにより物理的なノード

ネットワークサービス連携CSFもM2Mに特徴的なものです。
M2M デバイスは電力に対してとてもセンシティブで、省電力がたいへん重要な課題となります。例えば、1 日に 1 回データを上げればよいような使い方の場合、データを測定しないときを実現します。
M2M デバイスは 3 種類あります。ASN（Application Service
Node）は AE と CSE の両方を実装したノードで、フルスペッ
クとまでは言わないですが、oneM2M 標準にかなり準拠したデや通信しないときには、デバイスにはできるだけ電力を消費しないで眠っていてほしいです。しかし、通信のコネクション確
立のためには、眠っているデバイスに対して網からトリガーをかけるデバイストリガと呼ばれる仕組みが必要です。トリガー

バイスです。多分、今後開発されるデバイスはこれになると思います。ただし、色々と機能が盛り込まれているので、かなり高機能・高価な端末になるかと思います。そうではなく、もう少し軽量な端末ということで、ADN（Application Dedicatedをかけられて起こされたデバイスが網とのコネクションを確立し、そのパスに乗せて 1 日 1 回、温度や気圧のデータをさっと送り終わったら、再びスリープ状態に戻るという使い方です。
サブスクリプション通知 CSF は、変化が或る閾値を超えたNode）はアプリケーションしか実装していないです。これにはCSE を実装しないで、軽く安くというデバイスです。もう一つは、Non-oneM2M Device で、oneM2M 標準に準拠していない
既存のデバイスです。
これは昔からある既存の oneM2M 非標準

ら通知する機能です。例えば、気温、気圧、河川の水位などの対象となるリソースを監視するのに、登録して変化が生じたら知らせることで、定期的に見に行かなくても済む機能が共通的に提供されます。

のデバイスも、oneM2M の環境に取り込んでいくということです。
CSE は共通機能の集合体です。図 7 では CSE の中に 12 個の CSF（Common Service Function）があることを示していま

要するに、CSF を用いることで色々な共通的機能が提供され、アプリケーションの追加が容易になります。M2M を導入した
いサービスに対して、容易にアプリケーションが追加でき、更にオペレーションコストを下げることを狙った仕組みが CSEす。全部を説明することは難しいので、特徴的なものを選んでご説明します。

の CSF で提供されます。
ここで oneM2M の特徴であるリソースについて簡単に触れておきます。
M2M で扱われるシステムの利用やデバイス制御のために扱われる情報は、全てリソースであって、そのリソースは全てユ
ニークなアドレスを持っているという特徴があります。
このような特徴を持つことでウェブとの親和性がよいと言うことができます。URI を指定することで簡単にリソースにアクセスでき、更にサーバ側で状態を保有する必要がなく、内部状態を管理する必要がありません。これにより、スケーラビリテ
ィが上がり、規模の拡張が容易になり、負荷分散への対応が容易になり、故障に強いシステムの構築が可能になるという特徴

登録 CSF は、エンティティを登録する機能です。AE-CSEがあります。また、メッセージの構造がシンプルであり、ウェブ系のアプリケーション、プロトコルとの親和性が非常に高いです。
オペレーションは、CRUD（Create, Retrieve, Update, Delete）

間の通信では、
データ通信が始まる前に AE が CSE にレジスト
レーションし、CSE-CSE 間の通信では、CSE が CSE にレジ
ストレーションします。登録することによって、被レジスト側の CSE のサービスを享受できるようになります。

と notify の 5 つのオペランドで実現されるとてもシンプルな処理になっています。
このようなアーキテクチャ設計指針を ROA（Resource Oriented Architecture）と呼んでいます。
図 8 は、ROA とそれに対応する SOA（Service Oriented

通信管理/配布機能 CSF は、主として他ノードとの通信を管理する機能です。例えば、伝送網には LAN や WAN など色々ありますが、どれを選択するのが一番効率的なのかを判断する。
他には、通信データの中には小さいものもあって、この小さい

Architecture）の対比です。ROA にはリクエストとレスポンスがありますが、主にサーバ側である Receiver 側には内部状態を管理する必要がなく、状態の不一致という事故が起きないという特徴があります。SOA には Receiver 側できちんと内部状態

データを網が輻輳していないときにまとめて送るようにスケジューリングすることで、網を効率的に利用する。このような機能を実現しています。
セキュリティ CSF は、アクセス制限のための認証、ノード・を保存するする必要があります。SOA を導入したアーキテクチ
ャについても oneM2M で検討されていますが、これを SCA（Service Component Architecture）と呼んでいます。
SCA では、Service Component 1,･･･, Service Component N

ノード間通信の安全を確立するという機能のことです。
デバイス管理 CSF は、携帯網で広く使われているデバイス管理機能を M2M でも使えるようにすることです。例えば、デバイスファームウェアの更新です。oneM2M では OMA のデバと明示的にサービスコンポーネントを配備し、その機能を露出させて、これによってフレキシブルなサービスの導入を可能としているので、既存ベンダのソリューションとの相性がよいという特徴があります。
提案元は、欧米の ALU、Ericsson、Verizon、

イスマネジメントと、BBF の TR-069 の 2 種類のデバイス管理

AT&T、Orange の他、ZTE、LGE などで、これらの企業が SCA

図 7 共通プラットフォームの各種機能

18

SCATLINE Vol.97

活動を進めています。SCA は oneM2M の初期リリースには入ケーションに共通的に必要となる機能を提供することです。プっておらず、恐らく次期リリースに向けて検討が継続されると思います。

ラットフォーム事業者が CSE を提供すれば、M2M サービス事
業者はアプリとデバイスを準備すればビジネスを始めることができ、ビジネス参入の障壁が低くなるということを狙っています。
二つ目は、アクセスの非依存性です。3GPP、Wi-Fi などの色々な Underlying Network が考えられますが、これらの網に依存しないサービス層の仕様を規定しています。
三つ目は、既存の M2M プロトコルに対応することです。プ
ロトコルを全て oneM2M で規定するのではなく、コア部分だけを TS-0004 で規定する。異なるプロトコルを利用したり、相互接続も実現したりして、スモールスタートも可能とする。そのための手段として、HTTP、CoAP、MQTT との Protocol Binding

図8

ROA と SOA の対比

参照点 Mca/Mcc 上の通信メッセージを図 9 に示します。
左側の Originator から右側の Receiver に向けてプリミティを規定しています。
四つ目は、サービス層のセキュリティや課金等を考慮しています。
五つ目は、既存ベンダのソリューションとのインターワーク

ブ・リクエストが送られます。リクエストで Receiver 側のリソースを参照したり、update したり、delete したりします。オペ
レーションの結果はレスポンスとして返されます。
Mcn 上の CSE-NSE 間通信は、アプリや通信事業者による既を想定しています。
次期リリースでは、
ROA だけではなく SOAの要素を取り入れた SCA の検討も行っていきます。
六つ目は、M2M データの再利用や流通を可能とするセマン
ティックスの仕様についても検討することです。

存のメッセージングサービスやOMA、GSMA等の既存のAPI、
3GPP MTC（Machine Type Communication）でのインターワーキングやセキュリティのスペックを参照することになっています。要するに、oneM2M では詳細に規定しないで、他の規定を使うということです。

図 10

Mca/Mcc 上のメッセージ通信(3) oneM2M 初版技術仕様書、及び次期リリースの展望
初版技術仕様書を公開しました。
時系列的作業の流れとしては、最初にどんな使い方があるか
図9

Mca/Mcc 上の通信メッセージ

図 10 は、図 9 の Mca/Mcc 上のメッセージ通信の詳細を示したものです。Application Server Layer は、テクニカルスペック

をユースケースとテクニカルレポートにまとめて、次にそこから求められる要求条件を集めました（Stage1：2013 年 10 月）。
更に、その要求条件を実現するためのアーキテクチャを決めて発行しました（Stage2：2014 年 8 月）
。続いて、プロトコルのTS-0004 Core Protocol Specification にて詳細に規定されています。Transport Layer については、既存のプロトコルをそのま
ま使うということで、HTTP、CoAP（Constrained Application
Protocol）、MQTT（MQ Telemetry Transport）などが想定され

TS（Technical Specification）を決めて、2014 年 8 月に第 1 版を固めて、コメントを募集して、2015 年 1 月に改訂版として正式にリリースする予定となっています。
初版リリースの仕様書では、表 1 の 9 件の TS がリリースさています。これらの実装は選択できます。TS-0004 プロトコルと HTTP などのプロトコルとのマッピングは、TS-0008/9/10
Protocol Binding Specification にて規定されています。つまり、
TS-0004、TS-0008/9/10 規定により、Originator-Receiver 間のれます。TS-0001 が Functional Architecture、TS-0002 がRequirements、TS-0003 が Security Solutions、TS-0004 がService Layer Protocol Core Specification、TS-0005 と TS-0006
がデバイス管理に関するスペックです。OMA と BBF の既存のプロトコル通信が実現されます。ただし、Underlying Network
プロトコルは、今のところ HTTP、CoAP、MQTT の 3 種類だ
けが想定されています。
以下は oneM2M の技術仕様のまとめです。

デバイス管理を使うために必要な対応関係、マッピングがTS-0005 とTS-0006 で規定されています。
TS-0008 と TS-0009
は、CoAP や HTTP とのプロトコル・バインディングについて規定したものです。TS-0011 が全スペック共通的な Common

一つ目は、共通プラットフォーム（CSE）が各業界のアプリ

Terminology で、用語の説明や定義が記載されています。
19

SCATLINE Vol.97

表 1 oneM2M 初版リリース仕様書パッケージ

スマートメータ、画像、セキュリティなどの M2M デバイスが増えてくると、ネットワークの負荷も増えます。そのことで繋がらない、途切れる、通信料を安価にしてほしいなどのモバイ
ルネットワーク上の問題が色々と発生することが予想されます。

（注）2015 年1 月に正式リリースされた仕様書では、MQTT とのプロトコル・
バインディングについての規定 TS0010 MQTT Protocol Binding が追加されて10 件となっています。

2014 年 12 月 9 日にフランスの ETSI にて、oneM2M のLaunch Event、Showcase が行われました。そこでは 7 つのグ
ループがデモを行い、弊社もその中のグループの一つに参加して、アプリケーションのデモを行いました。

図 11 ネットワーク層とサービス層のさらなる連携

次期リリースの展望としては、外部団体との連携が深まってきています。国内では、新世代 M2M コンソーシアムが 2014
年後半に oneM2M に加盟しました。海外では、米国の IEEE や
欧州の CEN（仏：Comité Européen de Normalisation）などが- 3GPP による連携機能の標準化要求条件 この解決には、M2M の特性を把握してネットワーク層に伝えることで、ネットワーク制御を最適化することが必要で、そoneM2M への正式参加を検討しています。
次期リリースは 2015 年 1 月から検討が本格化します。想定される内容は、一つ目が SCA、二つ目が下位伝送網との連携、三つ目がセマンティックスのサポートです。他には、デバイスれを実現するためには、oneM2M のサービス層だけでなく、コアネットワークである3GPPにも標準が必要になるということです。
連携の具体例として、図 12 にて車の移動管理についてご説の関連の標準化、新たな業界のユースケースの収集を行い、更には標準を策定するだけではなく、その後のコンフォーマンス
テスト仕様を作成することも行っていきます。最後に、Home
Domain Enablement というのが注目されています。ここには中明します。

国のハイアールなどの白物家電メーカも参加しており、色々と仕様検討を進めている状況です。

oneM2M 次期リリースへの期待
下位伝送網との連携とセマンティックスのサポートについて
ご説明します。
(1) 下位伝送網との連携
下位伝送網との連携としては、例えば図 11 に示すように、
M2M サービス層と 3GPP が連携することでシナジー効果への期待が高まっています。具体的に言うと、サービスの広がりや図 12 ネットワーク層とサービス層のさらなる連携- 車の移動管理 着信時には3GPPコアネットワークセルに対してページング

ネットワークの最適な運用が期待されるということです。
スマートフォンやセンサなどの物理デバイスは、ネットワー
ク層の下に位置していますが、現状のデバイス・サービス層間の通信では、ネットワーク層をパイプ的に使っています。要す

制御をかけますが、そのページング制御を抑えて、コアネット
ワーク制御の効率化を狙います。
図 12 の左側が現在のやり方で、コアネットワークと M2M の連携が何もないと、例えば、車のエンジンが止まっていて車がるに、単にネットワーク層を通しているだけの使い方です。そこで、サービス層とネットワーク層が新たに連携することによって、M2M らしく、もっと最適に運用できるようになることを狙っています。現在、oneM2M と 3GPP とで標準化が議論さ動いていない場合でも、その車に着信があると近隣のセルに対してもページングが行われます。これはあまり効率的ではありません。そこで図 12 の右側のやり方では、車のエンジンが止まったことを M2M デバイスからサーバのアプリケーションにれており、3GPP では MTC（Machine Type Communication）
リリース 11 から色々と検討が始まっています。
3GPP で挙げられる連携機能の標準化要求条件が図 11 の右下に列記されていますが、一例として「予想通信パターンに応知らせることで、車は動いていないことを 3GPP のネットワー
クに通知する。
これにより、
車のエンジンが止まっている間は、着信があっても近隣のセルにはページングを行なわず、一つのセルに狙い撃ちでページングを行える。つまり、コアネットワ

じたネットワーク処理最適化」
について具体的にご説明します。

ークの制御の効率化、最適化ができるということです。これが20

SCATLINE Vol.97

3GPP ネットワークとの連携の効果、ユースケースの一つとい

1 が繋がっていて、更にデータ Y が繋がっている。デバイス 1

うことです。

のリソースには、owner が user10 であるというメタデータの注釈記述がされている。業界ごとに色々あると思いますが、図14 の右側に示すように、人とモノとの関係を示したオントロジーがあって、それを見ることでマシンがデータの意味を翻訳し(2) セマンティックスのサポート
セマンティックスは、IT の世界では語り尽くされていることですが、その考え方を M2M の世界に持ち込もうという考えです。
図 13 の左側は、oneM2M 初版リリースそのものです。
oneM2M プラットフォームには色々なアプリケーションが繋て、サービスに繋げるというのを狙ったものです。

がり、また色々なデバイスも繋がっています。しかし、アプリ
ケーションとデバイス間で扱うデータは個別のデータであって、アプリケーション 1 はデバイス 1 のデータ内容は分かるが、ア
プリケーション 2 はデバイス 1 のデータを理解できない。いわ
ゆる縦方向の繋がりだけであって、色々とプラットフォームにサービスやデバイスを収容したが、横方向への広がりは見えてこない。
そこで、今検討を進めているのが図 13 の右側の方で、扱うデータを標準的なデータにして、データの意味が互いに分かるようにする。標準データを oneM2M で定義して、M2M プラッ
トフォームは意味あるデータをデータベース化することによって、デバイス 1 の標準データをアプリケーション 2 でも使える

図 14 セマンティック記述
セマンティック M2M データでできることの一例として、セマンティック的な M2M データ検索があります（図 15）。これようにすることを狙っています。
要するに、注釈を記述したメタデータをデータに付加することで、マシンがデータの意味を翻訳できるようにする。人が介在しなくても効率的にデータの意味を展開して、アプリケーシ

はクラウドを使えば今でもできることかもしれませんが、クラウドなど使わずに、M2M プラットフォームを使ってできるよ
うになります。要するに、データの意味を指定して、データを検索し、複数の情報ソースから情報モデルやモデル言語が異な

ョンでの利用が可能となります。

るが、意味が同じであることを理解して、それを抽出して統計的に処理できるということです。
例えば、「ある指定地域のセンシング情報の平均値を 1 時間ごとに出しなさい」というリクエストや、「センシング情報の平均値 yy（または合計値）が zz 以上になるような地域と時間帯を示しなさい」というリクエストが、M2M プラットフォームに対してできるようになることを狙っています。

図 13 セマンティック M2M データサポートの狙い
セマンティック M2M データをサポートするための要求条件
は幾つもあり、
今まさに標準化にて議論され始めたところです。
図 14 の記述「ある情報モデルにおいて、各情報要素に対してマシンがその意味を翻訳可能とするメタデータや注釈を付与すること」というのは、セマンティックス記述とはいかなるも

図 15 セマンティック的な M2M データ検索のかを表しています。階層情報モデルにおいて、M2M プラッ
トフォームサーバ A があり、そこにはリソースとしてデバイス

以上、oneM2M 初版のリリースの内容と、先々に向けた
oneM2M の取り組みについてご紹介させていただきました。

本講演録は、平成 26 年 12 月 19 日に開催されたＳＣＡＴ主催「第 94 回テレコム技術情報セミナー」のテーマ、「IoT の最新動向」の講演要旨です。
＊掲載の記事・写真・イラストなど、すべてのコンテンツの無断複写・転載・公衆送信等を禁じます。

21