JP5973971B2

JP5973971B2 - マシンツーマシン制御システム及び方法

Info

Publication number: JP5973971B2
Application number: JP2013168772A
Authority: JP
Inventors: 美華森; 藤田　隆史; 隆史藤田; 後藤　良則; 良則後藤; 新小池
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2013-08-15
Filing date: 2013-08-15
Publication date: 2016-08-23
Anticipated expiration: 2033-08-15
Also published as: JP2015036926A

Description

本発明は、マシンツーマシン(M2M)制御システム及び方法に係り、特に、ネットワークに繋がれたデバイス同士が相互に情報を交換し、様々な制御を自動的に行う仕組みであるマシンツーマシン（M2M）通信を制御するためのM2M制御システム及び方法に関する。

M2Mデバイスを使用するためには、バーチャルリソースという概念がある。これは、地理的に分散している様々な物理的なM2Mデバイスのアクセス（センシング情報の取得やアクチュエータの制御）を容易にするために、ネットワーク上で仮想的にリソースを管理するのに適用可能な技術である。

この仕組みでは、図１に示すように、まず、全てのM2Mデバイスの能力や機能（物理リソース）をあるネットワーク上のサーバにデータベース（DB）として登録し、このDBをリソースディレクトリと呼ぶ。次に、物理リソースとDB上にあるバーチャルリソースを対応させることでユーザ（アプリケーション）は、統一サーバにあるバーチャルリソースを検索するだけで、必要とする物理リソースにアクセスすることができる（例えば、非特許文献１参照）。

"Open M2M Architecture," oneM2M-TP-2013-0236R01.

図２に示すように、実空間上には様々なセンサデバイスがある。しかし、使用するアプリケーションとセンサデバイスとの組み合わせが予め決められた専用システムでない限り、アプリケーションがこれらの未知のセンサデバイスの存在や状態を把握することは困難である。そのため、ユーザ（アプリケーション）が、例えば、『三鷹にある花粉の量を計測できるデバイスを検索する』という要求があっても検索できないという問題がある。
そこで、上記従来技術は、利用する可能性のあるデバイスを予めネットワーク上のDBに登録しておく仕組みである。しかし、全てのデバイスをネットワーク上のDBに登録しないと、ユーザ（アプリケーション）の所望のデバイスを検索できないため、実際には使われない多数のデバイスも予め登録しておく必要がある。これにより、デバイスとサーバ間で多くのトラヒックが発生し、帯域の逼迫につながる。

また、上記従来技術は、物理リソースとバーチャルリソースが対応関係になっているため、物理リソースがなんらかの原因で使用できなくなると、ユーザ（アプリケーション）は、代替の物理リソースを検索し、セッションを張りなおす必要がある。例えば、図３の例において、目的エリアの中でセンサデバイスを備えている自転車と通信していた場合、当該自転車が移動した場合や、通信相手のデバイスが故障した場合など、代替デバイスを、バーチャルリソース管理DB内の膨大な代替デバイス候補リストから検索してセッションを張りなおす必要がある。

本発明は、上記の点に鑑みなされたもので、ある物理リソースが何らかの原因で使えなくなっても、代替的な役割を担う同種の他の物理リソースを効率的に検索し、ユーザ（アプリケーション）は物理リソースが置き換わったことを意識することなく、アプリケーションの実行を継続することが可能なM2M制御システム及び方法を提供することを目的とする。

一態様によれば、ネットワークに繋がれた物理リソース同士のマシンツーマシン（M2M）通信を制御するためマシンツーマシン制御システムであって、
アプリケーションを実行する端末と、実空間上に存在する複数の物理リソースと、
前記アプリケーションからのアプリケーション要求に応じて前記物理リソースとの通信を可能にする上位コーディネータと、
前記実空間上の下位コーディネータの管理範囲ごとに設けられ、前記上位コーディネータからの要求に応じて、該下位コーディネータの管理範囲内の前記物理リソースの情報を管理する下位コーディネータと、
を有し、
前記上位コーディネータは、
前記アプリケーション要求に対して動的にバーチャルリソースを生成し、バーチャルリソース管理データベースへ格納するバーチャルリソース生成手段と、
前記アプリケーション要求に基づいて、前記バーチャルリソース管理データベースを参照し、該アプリケーション要求を満たす下位コーディネータを特定し、物理リソース情報要求を送信し、該下位コーディネータから物理リソースの情報が提供されると、該アプリケーション要求元のアプリケーションと該物理リソースを接続し、その後該アプリケーションが通信を継続する場合には、任意のタイミングで該下位コーディネータに対して物理リソースの存在の確認を指示し、該物理リソースが存在しない場合には、該下位コーディネータから新たな物理リソースの情報を取得して、通信先を該新たな物理リソースに切り替えるよう前記下位コーディネータに指示するアプリケーション制御手段と、
を有し、
前記下位コーディネータは、
自装置の管理範囲に存在する物理リソース情報を管理する物理リソース管理データベースと、
前記上位コーディネータからの物理リソースの存在の確認の指示に基づいて、前記物理リソース管理データベースから該物理リソースを検索し、存在確認ができない場合は、該物理リソースと同種別の物理リソースを該物理リソース管理データベースから検索し、検索できた場合には新たな物理リソースを、検索できない場合は「存在なし」の存在確認結果を該上位コーディネータに通知する物理リソース管理手段と、
前記上位コーディネータから物理リソースの切り替えが指示されると、新たな物理リソースに切り替える切替手段と、を有することを特徴とするマシンツーマシン制御システムが提供される。

一態様によれば、ある物理リソースが故障やエリア外移動等、何らかの原因で使えなくなっても、代替的な役割を担う同種の物理リソースを検索し、下位コーディネータのマッピングテーブル上のポインタを置き換えることにより、ユーザ（アプリケーション）は、物理リソースが置き換わったことを意識することなく、アプリケーションの実行を継続することができる。

また、複数のアプリケーションに対して、これらの機能をシステムとして共通に提供することで、アプリケーションの開発を容易にできる。

さらに、物理リソースがたくさんあっても、実際に使用するM2Mデバイスが少ない場合、ネットワークとデバイス間のトラヒックを低減できる。

従来のリソースアクセスの例である。従来の問題点の例（その１）である。従来の問題点の例（その２）である。本発明の一実施の形態におけるシステム構成例である。本発明の一実施の形態におけるバーチャルリソース管理DBの構成例である。本発明の一実施の形態における物理リソース管理DBとマッピングテーブルの例である。本発明の一実施の形態における動作のシーケンスチャートである。本発明の一実施の形態における上位コーディネータのフローチャートである。本発明の一実施の形態におけるデバイスの切替例である。従来技術と本発明の差異を示す図である。

以下、図面と共に本発明の実施の形態を説明する。

図４は、本発明の一実施の形態におけるシステム構成を示す。

同図に示すシステムは、アプリケーションa、アプリケーション要求aに対応するバーチャルリソースを管理する上位コーディネータ１００と、物理リソースの管理、及び同種の物理リソース（デバイス）の選択切り替えを行う下位コーディネータ２００、実空間L上の物理リソース（デバイス）Pを有する。

上位コーディネータ１００は、アプリケーション要求制御部１１０、バーチャルリソース管理DB１２０、下位コーディネータ制御部１３０を有し、アプリケーション要求制御部１１０は、複数のアプリケーションａ₁，ａ₂，ａ₃の要求を受け付ける、下位コーディネータ制御部１３０は、実空間の下位コーディネータ２００に接続されている。

下位コーディネータ２００は、上位コーディネータ要求受付部２１０、物理リソース管理DB２２０とマッピングテーブル２２１を有し、下位コーディネータの管理範囲であるロケーションL₁〜L₃ごとに設けられる。

上位コーディネータ１００のバーチャルリソース管理DB１２０は、図５（Ａ）に示すように、アプリケーションの要求に応じて生成されるバーチャルリソースと下位コーディネータIDのマッピングテーブル１２１と、図５（Ｂ）に示す下位コーディネータ２００に関する情報（例えば、下位コーディネータ0001は三鷹駅に設置されていて、ＩＰアドレスは210．158．88．２である）が格納されている下位コーディネータ情報DB１２２の２つのテーブルを保持する。

バーチャルリソース管理DB１２０のマッピングテーブル１２１は、図５（Ａ）に示すように、アプリケーション要求ID、バーチャルリソースID、下位コーディネータＩＤ、アプリケーション要求デバイス種別を有する。このうちバーチャルリソースIDはアプリケーション要求に伴って動的に生成されたバーチャルリソースのIDであり、下位コーディネータIDは、バーチャルデバイスを割り当てるべき物理デバイスが管理されている下位コーディネータの識別番号である。

下位コーディネータ情報DB１２２は、図５（Ｂ）に示すように、上位コーディネータが管理する全下位コーディネータのリストである。実際の通信の際には、IPアドレスが必要であるため、下位コーディネータIDとIPアドレスの対応表と、下位コーディネータが存在する位置情報として経度・緯度等を有する。下位コーディネータは上記以外の属性を有しても良い。

下位コーディネータ２００は実空間上に複数配置され、図６に示すように、それぞれの管理範囲内にあるデバイスを管理する、物理リソース管理DB２２０とマッピングテーブル２２１を保持する。

このように、M2Mでは、実空間に対してアクションを行う必要があるので、実空間上にある複数の場所に下位コーディネータ２００を配置する。各下位コーディネータ２００は、自管理範囲内のデバイスPを管理するため、上位コーディネータ１００は個々の物理リソースを管理する必要がない。このことから、上位コーディネータ１００と下位コーディネータ２００間のトラヒックを低減することが可能となる。下位コーディネータ２００の物理リソース管理DB２２０は管理範囲内に存在するデバイスの情報が登録される。下位コーディネータ２００の管理範囲は、例えば、1つあるいは複数の無線基地局電波到達範囲などから決定できる。ただし、図４では簡単なため単一の無線基地局のみを示している。また、デバイスの登録されるタイミングは、予めオペレータによって登録する他、車等に搭載されているセンサデバイスPが無線基地局の電波到達範囲に入った時点とする。

図７は、本発明の一実施の形態における動作のシーケンスチャートであり、図８は、本発明の一実施の形態における上位コーディネータと下位コーディネータのフローチャートである。

あるアプリケーションａから上位コーディネータ１００にアプリケーション要求があると（ステップ１）、上位コーディネータ１００のアプリケーション要求制御部１１０は、当該アプリケーション要求を解析し、バーチャルリソース管理DB１２１上にアプリケーションIDを設定し、アプリケーション要求で要求されているデバイスの能力を抽出する（ステップ２）。上位コーディネータ１００の下位コーディネータ制御部１３０は、アプリケーション要求に対応するデバイスを管理する下位コーディネータ２００を位置情報などから特定し、バーチャルリソースIDと特定した下位コーディネータ２００の下位コーディネータIDをマッピングテーブル１２１にマッピングし（ステップ３）。当該下位コーディネータ２００に物理リソース要求（ステップ２で抽出したアプリケーションが要求するデバイスの能力に関する情報等）を送信する（ステップ４）。

下位リソースコーディネータ２００の上位コーディネータ要求受付部２１０は、上位コーディネータ１００からの要求を受け付け、当該要求に対応する物理リソースIDを物理リソース管理DB２２０から取得し（ステップ５）、マッピングテーブル２２１（図６（Ａ））にバーチャルリソースIDと当該物理リソースIDをマッピングする（ステップ６）。

例えば、「三鷹駅周辺のデバイスを使用したい」場合は、下位コーディネータID"０００１"に問い合わせをすればよい。下位コーディネータ "０００１"において、アプリケーション要求（バーチャルリソース）に対応する物理リソースがない場合は、マッピングが失敗したと判断し、失敗をアプリケーションａに通知する（ステップ７）。マッピングが成功した場合は、上位コーディネータ１００は、アプリケーションaとデバイス（物理リソース）(P)の通信路を確立する（ステップ８）。具体的には、上位コーディネータ１００が、下位コーディネータ２００と通信路を確立し、下位コーディネータ２００はデバイスに対して接続要求を発出し、デバイスと接続する。

上位コーディネータ１００のアプリケーション要求制御部１１０は、アプリケーションａに対して、任意のタイミングで通信を継続するかを問合せ（ステップ９）、アプリケーションａから通信継続通知が返信されると（ステップ１０）、上位コーディネータ１００の下位コーディネータ制御部１３０から下位コーディネータ２００に対して物理リソースの存在確認を指示する（ステップ１１）。

下位コーディネータ１００の上位コーディネータ要求受付部２１０は、当該下位コーディネータ２００が管理する実空間(L)からセンサデバイス(P)が移動していないか、または、故障状態にないか等を把握し（ステップ１２）、その結果を存在確認結果として上位コーディネータ１００に返信する（ステップ１３）。なお、存在確認結果は、上位コーディネータ１００と下位コーディネータ２００間のトラフィック量を削減するため返信しなくてもよい。この場合は、上位コーディネータ１００側において、返信が無かった場合は物理リソースが存在したと見なす等の対応を行えばよい。上位コーディネータ１００は、マッピングに失敗した場合には、アプリケーションにマッピングの失敗を通知する（ステップ１５）。

下位コーディネータ２００は、存在確認結果が、通信を確立していたデバイスが当該管理エリアから出てしまった場合や故障状態にある場合（ステップ１３、No）は、代替の同種別のデバイスを物理リソース管理DB２２０から検索しても代替となる物理リソースがない場合には（ステップ１３，１４、No）、マッピング失敗を通知する（ステップ１５）。

新たな物理リソースが見つかった場合には（ステップ１４、Yes）、下位コーディネータ２００の上位コーディネータ要求受付部２１０は、バーチャルリソースIDと新たな物理リソースIDとをマッピングテーブル２２１にマッピングして、当該マッピングテーブル２２１を更新する（ステップ１６）。状態に変化がない場合は以前の通信を続行する。

なお、下位コーディネータ２００では、当該下位コーディネータ２００の管理範囲内に新たにセンサデバイスPが追加されると、当該センサデバイスPの情報が物理リソース管理DB２２０に登録される。

上記の図７、８を用いて具体的な実施例を説明する。

ユーザ（アプリケーションa₁）からアプリケーション要求として、『三鷹駅の花粉情報を収集したい』が送信されると、上位コーディネータ１００は、当該要求について、デバイス能力として「花粉情報をセンシングできるデバイス」と解釈する（ステップ２）。

上位コーディネータ１００の下位コーディネータ制御部１３０は、バーチャルリソース管理DB１２０を参照して、位置情報などから「三鷹駅」に位置する下位コーディネータ２００を特定し、バーチャルリソース管理DB１２０からアプリケーション要求に対応するバーチャルリソースIDと特定した下位コーディネータIDをマッピングテーブル１２１にマッピングし（ステップ３）、特定した下位コーディネータ２００に、デバイス能力の「花粉をセンシングできるデバイス」の要求を通知する（ステップ４）。

下位コーディネータ２００の上位コーディネータ要求受付部２１０は、上位コーディネータ１００からの要求に基づいて、物理リソース管理DB２２０から「三鷹」エリアに存在する「花粉をセンシングできるデバイス」のうち、１つ選出する。デバイスの選択はランダムでもよく、アプリケーションの要求（例えば、花粉センサの種類、精度、電波強度が一番強い等）を反映しても良い。（ステップ５）。このとき、複数の物理リソース情報がある場合には、図６（Ａ）のように複数の情報をマッピングテーブル２２１に書き込む（ステップ６）。

下位コーディネータ２００は、マッピングの結果（成功／失敗）を上位コーディネータ１００に通知する（ステップ７）。マッピングが成功した場合には、上位コーディネータ２００の下位コーディネータ制御部１３０は、取得した物理リソース情報とアプリケーション間の通信路を確立する（ステップ８）。具体的には、「三鷹」エリアに花粉情報をセンシングできるデバイスが存在したので、上位コーディネータ１００は、そのデバイス（物理リソースID=P₂）と通信路を確立する。

上記の処理において、アプリケーションa₁は１分間に１回の間隔で花粉情報を収集しているとする。上位コーディネータ１００のアプリケーション要求制御部１１０は、所定の時間が到来、または、任意の間隔でアプリケーションa₁に対して引き続き情報収集のための通信を継続するかを問い合わせ（ステップ９）、アプリケーションa₁から継続することが通知されると（ステップ１０）、上位コーディネータ１００は、下位コーディネータ２００に対して物理リソースが引き続き存在しているかの確認を要求する（ステップ１１）。

下位コーディネータ２００は、物理リソースに対して、現在「三鷹」エリアの花粉をセンシングしているデバイスは、「三鷹」エリアにいるのか、移動していないか、または、故障していないか等により要求に即した代替のデバイスがないか等を探索する（ステップ１２）。その結果、「三鷹駅」に物理リソース（ID=P₂）は移動して「三鷹」エリアに存在しないが（ステップ１３,No）、他の物理リソース(ID=P₄)がある場合は（ステップ１４,Yes）、存在確認結果として「存在あり」として物理リソース(ID=P₄)を上位コーディネータ１００に通知し（但し、当該通知処理は省略可能である）、マッピングテーブル２２１を更新し、当該物理リソース (ID=P₄)との通信を継続する（ステップ１６）。

一方、マッピングができない場合は（ステップ１３，１４,No）、アプリケーションａ₁にマッピングの失敗を通知し（ステップ１５）下位コーディネータ１００からアプリケーションａ₁に対して通信の終了を指示する（ステップ１７）。

図９は、本発明の一実施の形態におけるデバイスの切替例である。

同図では、アプリケーションＡの通信相手であるセンサデバイス（紫外線センサ付き自転車）が、下位コーディネータ２００の管理範囲から移動または消滅すると、自動的に同種のデバイス（紫外線センサ）に切り替える例を示している。

アプリケーションＡが、上位コーディネータ１００に、『三鷹駅に紫外線情報を計測できるデバイス』をアプリケーション要求として送信し、上位コーディネータ１００は、バーチャルリソース管理DＢ１２０の下位コーディネータ情報DB１２２に格納されている情報から、当該「三鷹駅」にマッチする下位コーディネータ２００を特定し、「三鷹」エリアを管理する下位コーディネータに対してリクエストを送信する。当該「三鷹」エリアの下位コーディネータ２００はマッピングテーブル２２１からセンサデバイス（紫外線センサ付き自転車）を特定し、上位コーディネータ１００に通知する。これにより、上位コーディネータ１００はアプリケーションＡと紫外線センサ付き自転車との通信を確立する制御を行う。

その後、紫外線センサ付き自転車が当該下位コーディネータ２００の管理範囲内から移動し、通信ができなくなると、下位コーディネータ２００は、以下のいずれかの方法により、下位コーディネータ１００の管理範囲（『三鷹』）内における、紫外線センサ付き自転車と同種の紫外線情報を計測できるデバイスを探索し、探索できた場合は、アプリケーションＡと紫外線センサの通信に切り替える。

デバイスを探索する一つ目の方法として、プロアクティブ方式がある。当該方式は、下位コーディネータ２００が周囲にあるセンサデバイス（紫外線、花粉、放射線）に対して、ブロードキャストし、物理リソース（上記の例では紫外線をセンシングできるデバイス（紫外線センサ））を探索し、探索できた場合には、当該物理リソースに通信を切り替える。

二つ目の方法として、リアクティブ方式がある。当該方式は、下位コーディネータ２００の管理範囲内に物理リソース（上記の例では紫外線をセンシングできるデバイス）が入ると、下位コーディネータ２００の物理リソース管理DB２２０の情報（Macアドレス等）が登録される。もし、通信中にセンサデバイス（上記の例では紫外線をセンシングできるデバイス）が管理範囲から消えると、下位コーディネータ２００の物理リソース管理DB２２０に登録された情報に基づいて、同種のセンサデバイスに通信を切り替える。

図１０は、従来技術と本発明の差異を示す図である。

同図（Ａ）は、バーチャルリソースと物理リソースの対応関係の差異を示している。

従来技術では、それぞれの物理リソースに対応するすべての仮想リソースがネットワーク（例えばクラウド）上の単一ＤＢに存在し、アプリケーション自身が接続先を切り替えていたが、本発明では、ＤＢを上位と下位に分離し、上位コーディネータはどの下位ＤＢとマッピングするかの管理だけ行い、実空間上に存在する物理デバイスの管理や割り当ては下位コーディネータが行うことで、ある物理リソースが何らかの原因で使えなくなっても、ユーザ（アプリケーション）および上位コーディネータは、物理リソースが置き換わったことを意識することなく、アプリケーションを実行することが可能となる。これにより、上位コーディネータのＤＢ規模を小さくシンプルに抑えることができる。

また、複数アプリケーションに対して、上記の機能をシステムとして共通に提供することで、アプリケーションの開発を容易にすることが可能となる。

同図（Ｂ）は、バーチャルリソース管理DB１２０と物理リソース管理DB２２０の管理範囲の差異を示す。

M2Mは、バーチャル空間と実空間とのインタラクションが必要となる。このため、M2Mデバイス管理機能をネットワーク上に統一的なデータベースとして管理するのではなく、バーチャルリソース管理DB１２０と、地理的な場所（実空間に近いところ）に物理リソース管理DB２２０を配備することで上位コーディネータと下位コーディネータ間のトラヒックを低減することが可能となる。特に、実際に利用するM2Mデバイスが少ない場合に有効である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

a₁〜a₃ アプリケーション
L₁〜L₃ センサデバイス
１００上位コーディネータ
１１０アプリケーション要求制御部
１２０バーチャルリソース管理DB
１３０下位コーディネータ制御部
２００下位コーディネータ
２１０上位コーディネータ要求受付部
２２０物理管理リソース管理DB
２２１マッピングテーブル

Claims

ネットワークに繋がれた物理リソース同士のマシンツーマシン（M2M）通信を制御するためマシンツーマシン制御システムであって、
アプリケーションを実行する端末と、実空間上に存在する複数の物理リソースと、
前記アプリケーションからのアプリケーション要求に応じて前記物理リソースとの通信を可能にする上位コーディネータと、
前記実空間上の下位コーディネータの管理範囲ごとに設けられ、前記上位コーディネータからの要求に応じて、該下位コーディネータの管理範囲内の前記物理リソースの情報を管理する下位コーディネータと、
を有し、
前記上位コーディネータは、
前記アプリケーション要求に対して動的にバーチャルリソースを生成し、バーチャルリソース管理データベースへ格納するバーチャルリソース生成手段と、
前記アプリケーション要求に基づいて、前記バーチャルリソース管理データベースを参照し、該アプリケーション要求を満たす下位コーディネータを特定し、物理リソース情報要求を送信し、該下位コーディネータから物理リソースの情報が提供されると、該アプリケーション要求元のアプリケーションと該物理リソースを接続し、その後該アプリケーションが通信を継続する場合には、任意のタイミングで該下位コーディネータに対して物理リソースの存在の確認を指示し、該物理リソースが存在しない場合には、該下位コーディネータから新たな物理リソースの情報を取得して、通信先を該新たな物理リソースに切り替えるよう前記下位コーディネータに指示するアプリケーション制御手段と、
を有し、
前記下位コーディネータは、
自装置の管理範囲に存在する物理リソース情報を管理する物理リソース管理データベースと、
前記上位コーディネータからの物理リソースの存在の確認の指示に基づいて、前記物理リソース管理データベースから該物理リソースを検索し、存在確認ができない場合は、該物理リソースと同種別の物理リソースを該物理リソース管理データベースから検索し、検索できた場合には新たな物理リソースを、検索できない場合は「存在なし」の存在確認結果を該上位コーディネータに通知する物理リソース管理手段と、
前記上位コーディネータから物理リソースの切り替えが指示されると、新たな物理リソースに切り替える切替手段と、
を有することを特徴とするマシンツーマシン制御システム。
前記上位コーディネータの前記アプリケーション制御手段は、
前記アプリケーションから受け付けた前記アプリケーション要求の物理リソースの能力を解析するアプリケーション要求受付手段と、
前記バーチャルリソース管理データベースを参照して、解析された能力に対応する種別情報に基づいて、下位コーディネータを特定し、前記物理リソース情報要求を該下位コーディネータに送信し、該下位コーディネータから物理リソースの情報が得られた場合には前記アプリケーションと該物理リソース間の通信を確立し、物理リソースの情報が得られない場合には、該通信を終了させる下位コーディネータ制御手段と、
を含む請求項1記載のマシンツーマシン制御システム。
前記上位コーディネータの前記アプリケーション制御手段は、
前記下位コーディネータから前記物理リソースの存在確認結果を取得し、新たな物理リソースが存在する場合には、前記物理リソースの情報を該下位コーディネータに対応付けて、前記バーチャルリソース管理データベースに格納する手段を含む
請求項1記載のマシンツーマシン制御システム。
前記下位コーディネータの前記物理リソース管理手段は、
前記上位コーディネータからの前記物理リソース情報要求を取得した時点、または、任意の時点で、前記下位コーディネータの管理範囲の物理リソースの存在の有無を確認し、前記物理リソース管理データベースを更新する手段を含む
請求項1記載のマシンツーマシン制御システム。
ネットワークに繋がれた物理リソース同士のマシンツーマシン（M2M）通信を制御するためマシンツーマシン制御方法であって、
アプリケーションを実行するユーザ端末と、
実空間上に配置される複数の物理リソースと、
前記アプリケーションからの前記物理リソースの種別情報を含むアプリケーション要求に応じて物理リソースとの通信を可能にする上位コーディネータと、
前記実空間上の下位コーディネータの管理範囲ごとに設けられ、前記上位コーディネータからの要求に応じて、該下位コーディネータの管理範囲内の前記物理リソースの情報を管理する複数の下位コーディネータと、
を有するシステムにおいて、
前記上位コーディネータは、前記下位コーディネータごとの同種の物理リソースの種別情報を格納するバーチャルリソース管理データベースを有し、
前記下位コーディネータは、
自装置の管理範囲に存在する物理リソース情報を管理する物理リソース管理データベースを有し、
前記上位コーディネータが、前記アプリケーション要求に基づいて、前記バーチャルリソース管理データベースを参照し、該アプリケーション要求を満たす下位コーディネータを特定し、物理リソース情報要求を送信する要求送信ステップと、
前記下位コーディネータが、前記上位コーディネータからの前記物理リソース情報要求に基づいて、該物理リソース管理データベースから該要求を満たす物理リソースを検索し、物理リソース情報を該上位コーディネータに物理リソース情報通知ステップと、
前記上位コーディネータが、前記下位コーディネータから物理リソース情報が提供されると、該アプリケーション要求元のアプリケーションと該物理リソースを接続する接続ステップと、
前記上位コーディネータが、前記アプリケーションに通信を継続するか否かを問い合わせ、継続する場合に、任意のタイミングで該下位コーディネータに対して物理リソースの存在確認を要求する物理リソース存在確認要求ステップと、
前記下位コーディネータが、前記上位コーディネータからの物理リソースの存在の確認の指示に基づいて、前記物理リソース管理データベースから該物理リソースを検索し、存在確認ができない場合は、該物理リソースと同種別の物理リソースを該物理リソース管理データベースから検索し、検索できた場合には新たな物理リソースを、検索できない場合は「存在なし」の存在確認結果を該上位コーディネータに通知する存在結果通知ステップと、
前記上位コーディネータが、前記下位コーディネータから取得した前記物理リソースの存在確認結果において新たな物理リソース情報を取得した場合は、該新たな物理リソースに切替を前記下位コーディネータに指示し、該存在確認結果が「存在なし」の場合は通信終了を該下位コーディネータに指示するアプリケーション制御ステップと、
前記下位コーディネータが、前記上位コーディネータからの物理リソースの切替の指示に基づいて、通信先を前記新たな物理リソースに切り替える切替ステップと、
を行うことを特徴とするマシンツーマシン制御方法。
前記要求送信ステップにおいて、
前記アプリケーションから受け付けた前記アプリケーション要求の物理リソースの能力を解析し、
前記バーチャルリソース管理データベースを参照して、解析された能力に対応する種別情報に基づいて、下位コーディネータを特定し、物理リソース要求を該下位コーディネータに送信し、
前記接続ステップにおいて、
前記下位コーディネータから物理リソースの情報が得られた場合には前記アプリケーションと該物理リソース間の通信を確立し、物理リソースの情報が得られない場合には、該通信を終了させる、
請求項５記載のマシンツーマシン制御方法。
前記アプリケーション制御ステップにおいて、
前記下位コーディネータから前記物理リソースの存在確認結果を取得し、新たな物理リソースが存在する場合には、該物理リソースの種別情報を該下位コーディネータに対応付けて、前記バーチャルリソース管理データベースに格納する
請求項５記載のマシンツーマシン制御方法。
前記下位コーディネータが、前記上位コーディネータからの前記物理リソース情報要求を取得した時点、または、任意の時点で、前記下位コーディネータの管理範囲の物理リソースの存在の有無を確認し、前記物理リソース管理データベースを更新するステップを更に行う
請求項５記載のマシンツーマシン制御方法。