JP6340345B2 - ネットワークシステム及びその構成方法、プログラム - Google Patents

Description

本発明は、電気通信技術を用いてＭ２Ｍ(Machine to Machine)サービスを提供するためのプラットフォーム・ネットワークシステム及びその構成方法、ならびにプログラムに関する。

インターネットに代表されるＩＰ(Internet Protocol)が広く普及している。一方、センサネットワーク分野においては、Ｚｉｇｂｅｅ（登録商標）に代表されるようなｎｏｎ−ＩＰのプロトコルが普及しつつあり、クラウドへの接続要求が高まりつつある。

これらｎｏｎ−ＩＰのセンサネットワークをクラウドに接続・管理するには、ＩＰ／ｎｏｎ−ＩＰ相互のルーティングを可能にすることが必要である。異種ネットワークを跨ぐ到達性確保のため、端末の識別子(ＩＤ)と端末の接続位置(ロケータ)を分離するＩＤ／ロケータ分離アーキテクチャが提唱されている(非特許文献１)。

複数のネットワーク間でのルーティングのためのアドレス解決を実現するＩＤ/ロケータ分離手法として、ＬＩＳＰ(Locator/Identifier Separation Protocol)、ＨＩＰ(Host Identity Protocol)、ＨＩＭＡＬＩＳ(Heterogeneity Inclusion and Mobility Adaptation through Locator ID Separation)等が検討されている(非特許文献２)。ＬＩＳＰとＨＩＰはＩＰネットワーク同士の接続を想定し、ＨＩＭＡＬＩＳではＩＰ/ｎｏｎ−ＩＰネットワーク間の接続を想定している。ロケータを参照する装置の違いによって、下記３種類の構成に大別できる。

構成（１）
構成（１）は、エンド端末自身が分離された新たなＩＤやロケータ を認識して参照する方式である。複数のネットワークが接続される場合において、 プロトコルが共通(例えばＩＰ)で、エンド端末自身でＤＮＳ等を参照して複数ネットワークをまたがるアドレス解決を行う。Host Identityと呼ばれる新規のＩＤを導入するＨＩＰなどがこれに該当するが、Ｍ２Ｍ端末自身がこれらを解釈し参照する必要があるため、Ｍ２Ｍデバイスへの機能追加の負担が大きくなる。また、ＨＩＰはＩＰ空間に閉じているため、複数のネットワークが接続される場合において、プロトコルが異なるＩＰからｎｏｎ−ＩＰへのＭ２ＭエリアＮＷへの適用は想定していない。

構成（２）
構成（２）は、エンド端末とＧＷ装置の両方で新たなＩＤとロケータを認識して参照する方式である。例えばＨＩＭＡＬＩＳでは、ＩＰ/ｎｏｎ−ＩＰの異種ＮＷを接続したルーティングを想定している。ＩＤとロケータのアドレス解決を行うための共通ＩＤ層を、Ｍ２Ｍ端末やＧＷ装置など全てのＮＷ上の装置に共通に実装させる必要があり、やはり構成（１）同様Ｍ２Ｍデバイスへの新規機能追加の負担が避けられない。

構成（３）
構成（３）は、複数ネットワークの境界に配置されるＧＷ装置のみがＩＤとロケータの分離を解決し、Ｍ２Ｍデバイスへのルーティングを実現する方式である。エンド端末(ここではＭ２Ｍ端末)にインパクトを与えないメリットがある。ＬＩＳＰはこの一つといえるが、複数のＩＰネットワークでＩＰ空間内に閉じてアドレスを解決する手法であるため、そのままではｎｏｎ−ＩＰのＭ２ＭエリアＮＷには適用困難である。

ＩＤ・ロケータ分離による新世代ネットワークアーキテクチャ，http://www.nict.go.jp/publication/researcher/pdf_data/01/01/014_017.pdf Ved P. Kafle, Yusuke Fukushima, Kenji Fujikawa and Hiroaki Harai, "ID-Based Communication Framework for New Generation Networks" ICUFN 2014.

上記の構成（１）又は（２）の従来技術をネットワーク全体に適用した場合、「すべてのネットワーク装置(以下、ＮＷ装置)へのＩＤ層の追加が必要」「すべてのＮＷ装置からMapping Server (以下、ＭＳ)への参照が必要」となり、既存ＮＷ装置の更新負担が大きくなる。また、上記の構成（３）の従来技術はＭ２Ｍデバイスに新たな機能追加の負担を与えない観点から、ＰＦサーバ〜Ｍ２Ｍ−ＧＷ間のトランジットネットワークに閉じてアドレス解決が可能な構成（３）が有効であると考えられるが、ｎｏｎ−ＩＰのＭ２ＭエリアＮＷには適用困難である。

さらに、構成（１）又は（２）又（３）の構成技術のみでは、グローバルなロケータによって、アプリケーションサーバからＭ２Ｍデバイスへ直接到達経路が提供されるため、低機能なＭ２Ｍデバイスに対するセキュリティリスクが大きくなる。

本発明の目的は、簡易な構成で、Ｍ２Ｍデバイスに対するセキュリティを向上した上で、Ｍ２ＭエリアネットワークがＩＰ／ｎｏｎ−ＩＰに依らず、Ｍ２Ｍデバイス−アプリケーションサーバ間のエンド−エンドでのＭ２Ｍサービスを提供し得るネットワークシステム及びその構成方法、プログラムを提供することにある。

上記目的を達成するために、本発明の一観点は、第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムであって、前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤを記憶する記憶手段と、前記デバイスから接続要求を受信するとき、前記接続要求に含まれる前記デバイスＩＤに基づいて前記記憶手段を参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いて前記Ｍ２Ｍサービスを実行するための通信を行うコネクションを確立するコネクション処理手段と、前記アプリケーションサーバから操作要求を受信するとき、前記デバイスと前記アプリケーションサーバとを中継するコネクション中継手段とを備えるようにしている。

また、本発明の一観点は、第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムの構成方法であって、前記第１の通信ネットワーク及び前記第２の通信ネットワークを接続可能なクラウド上に設けられる中継サーバ装置が、前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤをデータベースに記憶し、前記デバイスから接続要求を受信するとき、前記中継サーバ装置が、前記接続要求に含まれる前記デバイスＩＤに基づいて前記データベースを参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いてＭ２Ｍサービスを実行するための通信を行うコネクションを確立し、前記アプリケーションサーバから操作要求を受信するとき、前記中継サーバ装置が、前記デバイスと前記アプリケーションサーバとを中継するようにしている。

さらに、本発明の一観点は、第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムの中継サーバ装置を、前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤを記憶する記憶手段と、前記デバイスから接続要求を受信するとき、前記接続要求に含まれるデバイスＩＤに基づいて前記記憶手段を参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いてＭ２Ｍサービスを実行するための通信を行うコネクションを確立するコネクション処理手段と、前記アプリケーションサーバから操作要求を受信するとき、前記デバイスと前記アプリケーションサーバとを中継するコネクション中継手段として動作させるプログラムである。

本発明により、Ｍ２ＭエリアネットワークがＩＰ／ｎｏｎ−ＩＰに依らず、Ｍ２Ｍデバイス−アプリケーションサーバ間のエンド−エンドでのＭ２Ｍサービスの提供が可能となり、アプリケーションサーバは、ＩＰネットワークをそのまま利用することができるため、アプリケーションサーバを含めた、Ｍ２Ｍ−ＰＦサーバよりアプリケーションサーバ側に位置するＮＷ装置の更新負担を回避できる。

また、Ｍ２Ｍデバイスの状態やセンサ取得値等は、ＰＦサーバ上で一元的に管理され、アプリケーションサーバからは、アプリケーションレベルでの操作等のみを受け付ける構成とする事で、アプリケーションサーバ側からは、ネットワークレイヤでのＭ２Ｍデバイスへの到達性を直接提供しないことで、セキュリティリスクを低減できる。

本発明を適用することにより、既存のサイロ型Ｍ２Ｍソリューションで用いられるような市販のＭ２Ｍモジュールを搭載したＭ２ＭデバイスやＭ２Ｍアプリケーションに機能追加・変更を行うことなく、ＩＰ/ｎｏｎ−ＩＰを跨ったＭ２Ｍシステムの構築が可能になる。

本発明のネットワークシステムの構成を示す図。 プロトコルスタックの比較例を示す図。 本発明の第１の実施形態に係るプロトコルスタックを示す図。 本発明の第２の実施形態に係るプロトコルスタックを示す図。 プロトコルスタックの実施例を示す図。 本発明における認証シーケンス例を示す図。 Ｍ２Ｍデバイス移動時のネットワーク構成例を示す図。 Ｍ２Ｍデバイス移動時のＩＤ／ロケータマッピングシーケンス例を示す図。 Ｍ２Ｍデバイス移動時のＩＤ／ロケータマッピングシーケンス例を示す図。 本発明の第３の実施形態に係るネットワークシステムの構成を示す図。 本発明の第３の実施形態に係るプロトコルスタックを示す図。

以下、本発明の実施形態について図面を参照して詳細に説明する。

図１は、後述の本発明の第１の実施形態及び第２の実施形態に係わるネットワークシステムの一実施形態を示す概略構成図である。このシステムは、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２と、クラウドとしての広域ネットワーク(移動・固定のアクセス・コアネットワーク)ＮＷ３と、インターネット・ＩＳＰ網等のＩＰネットワークＮＷ４の３ドメインに分かれたネットワークを想定する。

Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２には、Ｍ２Ｍアプリケーションの操作対象となる、通信機能付センサ等のＭ２Ｍデバイス１１−１〜１１−ｉ（ｉは整数）が配置されている。

Ｍ２ＭエリアネットワークＮＷ１、ＮＷ２と広域ネットワークＮＷ３との境界にゲートウェイ（Ｍ２Ｍ−ＧＷ）１２−１，１２−２、広域ネットワークＮＷ３とＩＰネットワークＮＷ４との間にＭ２Ｍ−ＰＦサーバ(以後ＰＦサーバと呼称)が配置される。

Ｍ２Ｍ−ＧＷ１２−１，１２−２は、広域ネットワークＮＷ３−Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２間のゲートウェイ(ＨＧＷやスマートホンなど)であり、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２への参加管理とローカルロケータの発行、およびＰＦサーバ１３への認証要求を行う。

ＰＦサーバ１３はデータベース（ＰＦ−ＤＢ）１３１を保持し、Ｍ２Ｍデバイス１１−１〜１１−ｉの状態やセンサ取得値等を一元的に保持・管理する。また、ＰＦサーバ１３はＭ２Ｍデバイス１１−１〜１１−ｉの認証を行う。

Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２と広域ネットワークＮＷ３との区間では、共通に参照可能なＩＤ層を導入し、ＩＤベース通信を行う。広域ネットワークＮＷ３に配置されるマッピング・サーバ（以下、ＭＳ）１４は、ＰＦサーバ１３およびＭ２Ｍ−ＧＷ１２−１，１２−２からの更新情報に基づいて、Ｍ２Ｍ−ＰＦ配下のすべてのＭ２Ｍデバイス１１−１〜１１−ｉのＩＤ／ロケータ管理を行う。

ＰＦサーバ１３のＰＦ−ＤＢ１３１上のデバイスリソースは、例えばＲＥＳＴ（Representational State Transfer）アーキテクチャ等に基づき、ＡＰＰサーバ１５−１、１５−２からのアプリレベルのＣＲＵＤ操作レベルで行う。ＲＥＳＴアーキテクチャに基づくプロトコルとして、ＨＴＴＰ（Hypertext Transfer Protocol）やＣｏＡＰ(Constrained Application Protocol)等がある。

ＡＰＰサーバ１５−１、１５−２は、Ｍ２Ｍ事業者やエンドユーザが所有するアプリケーションサーバである。ＡＰＰサーバ１５−１、１５−２は、ＣＲＵＤ操作等により、ＰＦ−ＤＢ１３１上のデバイスリソース情報の管理更新を行うほか、Ｍ２Ｍデバイス１１−１〜１１−ｉの事前登録、およびＭ２Ｍデバイス１１−１〜１１−ｉ−ＰＦサーバ１３の経路ポリシーを指示設定する。

以下、上記構成における動作について説明する。
図２（ａ）に示すように、全てＩＰネットワークの場合、Ｍ２Ｍデバイス１１−１〜１１−ｉの識別子としてすべてのネットワークにＩＰアドレスが使用できる。ただし、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２としてＺｉｇｂｅｅ（登録商標）などのｎｏｎ−ＩＰのセンサネットワークを用いる場合、Ｍ２Ｍデバイス１１−１〜１１−ｉまでの到達性をエンド−エンド間で管理できない。

一方、図２（ｂ）に示すように、ｎｏｎ−ＩＰのＭ２Ｍエリアネットワークを用いる場合、ネットワーク層をＩＤ層（Ｌ３−ＩＤ）とロケータ層（Ｌ３−Ｌ）に分離することで、異種ネットワーク混在環境(ここではＭ２ＭエリアネットワークＮＷ１，ＮＷ２と広域ネットワークＮＷ３)下でも、デバイスＩＤを用いてＭ２Ｍデバイス１１−１〜１１−ｉへの到達性を確保できる。ただし、すべてのＮＷ装置へのＩＤ層の新規追加と、すべてのＮＷ装置からＭＳ１４へ参照が必要となり、既存ＮＷ設備更改の負担が大きくなる。

そこで、本実施形態では、ＰＦサーバ１３に、ＰＦ−ＤＢ１３１の他に、コネクション処理機能１３２と、コネクション中継機能１３３とを設けるようにしている。

コネクション処理機能１３２は、Ｍ２Ｍ−ＧＷ１２−１を介してＭ２Ｍデバイス１１−１から参加要求を受信するとき、参加要求に含まれるデバイスＩＤに基づきＰＦ−ＤＢ１３１を参照し、デバイスＩＤが登録されている場合に、図５に示すように、デバイスＩＤとＭ２Ｍデバイス１１−１の接続位置を特定するロケータとを対応付けてＭＳ１４に登録し、ネットワーク層（Ｌ３）のサブレイヤ上にデバイスＩＤを用いた通信コネクションを確立する。

コネクション中継機能１３３は、ＡＰＰサーバ１５−１からアプリケーション層（Ｌ４）を介して操作要求（ＣＲＵＤ操作等）を受信するとき、ＰＦ−ＤＢ１３１をキャッシュとして利用することでネットワーク層とアプリケーション層とのプロトコル変換（レイヤ変換）を行うことにより、Ｍ２Ｍデバイス１１−１とアプリケーションサーバ１５−１とを中継する。

このようにすることで、ＩＰアドレスやＺｉｇｂｅｅ（登録商標）用の識別子を用いず、共通のデバイスＩＤを用いて、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２がＩＰ／ｎｏｎ−ＩＰかによらず、Ｍ２Ｍデバイス−ＡＰＰサーバ間でのＭ２Ｍサービス提供が可能となる。

図６は、本発明の第１の実施形態及び第２の実施形態における認証シーケンス例を示す。

ＡＰＰサーバ１５−１の操作者によりＰＦ−ＤＢ１３１に対するデバイス登録操作が行われると（ステップＳＴ５１）、ＡＰＰサーバ１５−１からＰＦサーバ１３上のＰＦ−ＤＢ１３１に対し、デバイス登録要求が送信される（Ｓ１）。すると、ＰＦサーバ１３はＰＦ−ＤＢ１３１に対しＭ２Ｍデバイス１１−１のＩＤ登録を行い（ステップＳＴ４１）、要求元のＡＰＰサーバ１５−１に対しデバイス登録応答を送信する（Ｓ２）。

一方、Ｍ２Ｍデバイス１１−１の設置（例えば電源の投入等）や移動によりＭ２Ｍサービスの参加要求が発生すると（ステップＳＴ１１）、Ｍ２Ｍデバイス１１−１からＭ２ＭエリアネットワークＮＷ１上のＭ２Ｍ−ＧＷ１２−１に参加要求が送られる（Ｓ３）。Ｍ２Ｍ−ＧＷ１２−１は、参加要求があると、まずは(ローカル)ロケータの割当を行い（ステップＳＴ２１）、要求元のＭ２Ｍデバイス１１−１に対し参加応答を送信すると共に（Ｓ４）、Ｍ２Ｍデバイス１１−１のデバイスＩＤ及びロケータを含む認証要求をＰＦサーバ１３へ送信する（Ｓ５）。

ＰＦサーバ１３は、Ｍ２Ｍ−ＧＷ１２−１から認証要求を受信すると、認証要求に含まれるデバイスＩＤに基づいて、ＰＦ−ＤＢ１３１を参照してデバイスＩＤが登録されているか否かの判定を行う（ステップＳＴ４２）。ここで、登録されていない場合（Ｎｏ）、ＰＦサーバ１３はＭ２Ｍ−ＧＷ１２−１に対し認証不可応答を送信する（Ｓ６）。すると、Ｍ２Ｍ−ＧＷ１２−１はＭ２Ｍデバイス１１−１に対するローカルロケータ割り当てを解除し（ステップＳＴ２２）、Ｍ２Ｍデバイス１１−１に認証不可応答を送信する（Ｓ７）。Ｍ２Ｍデバイス１１−１上のソフトウェアやアプリケーションプログラム上に認証失敗の旨が通知される（ステップＳＴ１２）。

一方、上記ステップＳＴ４２において登録されている場合（Ｙｅｓ）、ＰＦサーバ１３はＭＳ１４に対しマッピング要求を送信する（Ｓ８）。ＭＳ１４は、ＰＦサーバ１３からマッピング要求を受信すると、マッピング要求に含まれるＭ２Ｍデバイス１１−１のデバイスＩＤ及びロケータを登録し（ステップＳＴ３１）、ＰＦサーバ１３に対しマッピング応答を返送する（Ｓ９）。

ＰＦサーバ１３は、デバイスＩＤ、ロケータ、認証応答として暗号鍵に関する情報を含む認証通過応答をＭ２Ｍ−ＧＷ１２−１を介してＭ２Ｍデバイス１１−１に送信する（Ｓ１０，Ｓ１１）。最後に、Ｍ２Ｍデバイス１１−１上のソフトウェアやアプリケーションプログラム上に認証成功の旨が通知される（ステップＳＴ１３）。

しかる後に、デバイスＩＤ、ロケータを用いてＭ２Ｍデバイス１２−１とＰＦサーバ１３との間にＭ２Ｍサービスを行うための通信コネクションが確立される。

図７は、Ｍ２Ｍデバイス移動時のネットワーク構成例を示す。

ここでは、Ｍ２ＭエリアネットワークＮＷ１からＭ２ＭエリアネットワークＮＷ２へとＭ２Ｍデバイスが移動する場合を想定する。その他の構成は、図１に示すネットワーク構成と同様である。

図８及び図９は、Ｍ２Ｍデバイス移動時のＩＤ／ロケータマッピングシーケンス例を示す。
Ｍ２Ｍデバイス１１−１の設置（例えば電源の投入等）や移動によりＭ２Ｍサービスの参加要求が発生すると（ステップＳＴ１４）、Ｍ２Ｍデバイス１１−１からＭ２ＭエリアネットワークＮＷ１上のＭ２Ｍ−ＧＷ１２−１に参加要求が送られる（Ｓ１１）。Ｍ２Ｍ−ＧＷ１２−１は、参加要求があると、まずは(ローカル)ロケータ（Loc1）の割当を行い（ステップＳＴ２３）、要求元のＭ２Ｍデバイス１１−１に対し参加応答を送信すると共に（Ｓ１２）、Ｍ２Ｍデバイス１１−１のデバイスＩＤ及びロケータ（Loc1）を含む認証要求をＰＦサーバ１３へ送信する（Ｓ１３）。

ＰＦサーバ１３は、Ｍ２Ｍ−ＧＷ１２−１から認証要求を受信すると、認証要求に含まれるデバイスＩＤに基づいて、ＰＦ−ＤＢ１３１を参照してデバイスＩＤが登録されているか否かを判定し、登録されている場合、ＭＳ１４に対しマッピング要求を送信する（Ｓ１４）。ＭＳ１４は、ＰＦサーバ１３からマッピング要求を受信すると、マッピング要求に含まれるＭ２Ｍデバイス１１−１のデバイスＩＤ及びロケータ（Loc1）を登録し（ステップＳＴ３２）、ＰＦサーバ１３に対しマッピング応答を返送する（Ｓ１５）。

ＰＦサーバ１３は、デバイスＩＤ、ロケータ（Loc1）、認証応答として暗号鍵に関する情報（Key）を含む認証通過応答をＭ２Ｍ−ＧＷ１２−１を介してＭ２Ｍデバイス１１−１に送信する（Ｓ１６，Ｓ１７）。しかる後に、デバイスＩＤ、ロケータ（Loc1）を用いてＭ２Ｍデバイス１２−１とＰＦサーバ１３との間にＭ２Ｍサービスを行うための通信コネクションが確立される（ステップＳＴ１５）。

ここで、Ｍ２Ｍデバイス１１−１がＭ２ＭエリアネットワークＮＷ１からＭ２ＭエリアネットワークＮＷ２へと移動したとする（ステップＳＴ１６）。すると、Ｍ２Ｍデバイス１１−１からＭ２ＭエリアネットワークＮＷ２上のＭ２Ｍ−ＧＷ１２−２に参加要求が送られる（Ｓ１８）。Ｍ２Ｍ−ＧＷ１２−２は、参加要求があると、まずは(ローカル)ロケータ（Loc2）の割当を行い（ステップＳＴ２４）、要求元のＭ２Ｍデバイス１１−１に対し参加応答を送信すると共に（Ｓ１９）、Ｍ２Ｍデバイス１１−１のデバイスＩＤ及びロケータ（Loc2）を含むマッピング更新要求をＰＦサーバ１３へ送信する（Ｓ２０）。

ＰＦサーバ１３は、Ｍ２Ｍ−ＧＷ１２−２からマッピング更新要求を受信すると、ＭＳ１４に対しマッピング要求を送信する（Ｓ２１）。ＭＳ１４は、ＰＦサーバ１３からマッピング要求を受信すると、マッピング要求に含まれるＭ２Ｍデバイス１１−１のデバイスＩＤ及びロケータ（Loc2）を登録し（ステップＳＴ３３）、ＰＦサーバ１３に対しマッピング応答を返送する（Ｓ２２）。

ＰＦサーバ１３は、デバイスＩＤ、ロケータ（Loc2）、認証応答として暗号鍵に関する情報（Key）を含む認証通過応答をＭ２Ｍ−ＧＷ１２−２を介してＭ２Ｍデバイス１１−１に送信する（Ｓ２３，Ｓ２４）。しかる後に、デバイスＩＤ、ロケータ（Loc2）を用いてＭ２Ｍデバイス１２−１とＰＦサーバ１３との間にＭ２Ｍサービスを行うための通信コネクションが確立される（ステップＳＴ１７）。

続いて、ＰＦサーバ１３は、Ｍ２Ｍ−ＧＷ１２−１に対しロケータ（Loc1）の状態確認要求を送信する（Ｓ２５）。ＰＦサーバ１３は、Ｍ２Ｍ−ＧＷ１２−１から返送される状態確認応答を受信すると（Ｓ２６）、状態確認応答に基づきＭ２ＭデバイスとＭ２Ｍ−ＧＷ１２−１とのリンクが切断されていた場合、ＭＳ１４にマッピング要求を送信する（Ｓ２７）。

ＭＳ１４は、ＰＦサーバ１３からマッピング要求を受信すると、ＭＳ１４に登録されたロケータ（Loc1）を削除し（ステップＳＴ３４）、ＰＦサーバ１３に対しマッピング応答を返送する（Ｓ２８）。

ＰＦサーバ１３は、ロケータ（Loc1）を含むロケータ削除要求をＭ２Ｍ−ＧＷ１２−１に送信する（Ｓ２９）。すると、Ｍ２Ｍ−ＧＷ１２−１は、ローカル保持されているロケータ（Loc1）を削除する（ステップＳＴ２５）。続いて、ＰＦサーバ１３は、ロケータ（Loc1）を含むマッピング削除要求をＭ２Ｍ−ＧＷ１２−２を介してＭ２Ｍデバイス１１−１に送信する（Ｓ３０，Ｓ３１）。以後、Ｍ２Ｍデバイス１１−１は、経路表に保持されているロケータ（Loc1）を削除する（ステップＳＴ１８）。従って、Ｍ２Ｍデバイス１１−１の移動に伴った通信コネクションをＰＦサーバ１３との間で確立した上で、元のLoc1によるリンクが切断されているか否かを確認し、Loc1による通信コネクションを切断することができる。

（第１の実施形態）
図３は、本発明の第１の実施形態に係るプロトコルスタックを示す図である。

第１の実施形態は、Ｍ２Ｍデバイス−ＰＦサーバ間のみＩＤ／ロケータ分離を行い、ＩＤ層をＬ３のサブレイヤとする場合である。

ＰＦサーバ１３との間でＭ２Ｍ−ＧＷ１２−１を経由して通信コネクションが確立されたＭ２Ｍデバイス１１−１は、例えばセンシング対象物の動きを検出すると、自デバイスを識別するデバイスＩＤ、センシング対象物を検出した旨の情報をＭ２Ｍ−ＧＷ１２−１を介してＰＦサーバ１３に送信する。

ＰＦサーバ１３は、Ｍ２Ｍデバイス１１−１から送られた情報からＭ２Ｍデバイス１１−１の状態やセンサ取得値等を抽出し、Ｍ２Ｍデバイス１１−１の状態やセンサ取得値等をＭ２Ｍデバイス１１−１のデバイスＩＤに対応付けてＰＦ−ＤＢ１３１に登録する。また、ＰＦサーバ１３は、Ｍ２Ｍデバイス１１−２〜１１−ｉから送られる情報からＭ２Ｍデバイス１１−２〜１１−ｉの状態やセンサ取得値等を抽出し、Ｍ２Ｍデバイス１１−２〜１１−ｉの状態やセンサ取得値等をＭ２Ｍデバイス１１−２〜１１−ｉのデバイスＩＤにそれぞれ対応付けてＰＦ−ＤＢ１３１に登録する。

ＡＰＰサーバ１５−１は、ＰＦサーバ１３に対しアプリケーション層（Ｌ４）を介してＣＲＵＤ操作を行うことにより、ＰＦ−ＤＢ１３１に登録されている各Ｍ２Ｍデバイス１１−１〜１１−ｉの状態やセンサ取得値を格納するためのエンティティを作成したり（Create）、センサ取得値を取得したり（Read）、更新したり（Update）、削除したり（Delete）することができる。

以上のように上記第１の実施形態によれば、Ｍ２Ｍデバイス１１−１〜１１−ｉの状態やセンサ取得値等は、ＰＦサーバ１３上のＰＦ−ＤＢ１３１上で一元的に管理され、ＡＰＰサーバ１５−１からは、アプリケーションレベルでのＣＲＵＤ操作等のみを受け付ける構成とすることにより、ＡＰＰサーバ１５−１側からは、ネットワーク層でのＭ２Ｍデバイス１１−１への到達性を直接提供することなく、セキュリティリスクを低減できる。これにより、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２の規模が大規模になるＭ２Ｍサービスにおいても、アプリケーションサーバ１５−１を設置するＩＰネットワークＮＷ４は既存設備を用いたままで容易に構築することが可能となり、さらに、Ｍ２ＭエリアネットワークＮＷ１／ＮＷ２とＩＰネットワークＮＷ４との結合を小さくすることで、セキュリティリスクが軽減されたサービス提供が可能となる。なお、広域ネットワークＮＷ３区間内は、セキュリティリスク軽減のため、既存のＬ２／Ｌ３のトンネリングプロトコルを適用し、Ｍ２Ｍ−ＧＷ１２−１とＰＦサーバ１３との間で論理的なルーティングを行わない構成とすることもできる。

また、上記第１の実施形態では、広域ネットワークＮＷ３およびＭ２ＭエリアネットワークＮＷ１，ＮＷ２区間において、ＩＤ／ロケータ分離を行うネットワーク構成とし、Ｍ２Ｍデバイス-Ｍ２Ｍ−ＧＷ-ＰＦサーバ間のＩＤベース通信のみ許容することで、ＰＦサーバ１３上から、Ｍ２Ｍデバイス１１−１までの到達性を、ネットワーク層において一元的に管理することが可能になる。従って、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２がＩＰ／ｎｏｎ−ＩＰに依らず、Ｍ２Ｍデバイス１１−１−アプリケーションサーバ１５−１間のエンド−エンドでのＭ２Ｍサービスの提供が可能となる。

さらに、上記第１の実施形態では、ＡＰＰサーバ１５−１側は、ＩＰネットワークＮＷ４を利用することができるため、既存の企業ネットワークやインターネットへの適用が容易となる。

（第２の実施形態）
図４は、本発明の第２の実施形態に係るプロトコルスタックを示す図である。

第２の実施形態は、Ｍ２Ｍデバイス−ＰＦサーバ間のみＩＤ／ロケータ分離を行い、ＩＤ層をＬ４のサブレイヤとする場合である。

第２の実施形態において、各装置の基本的な構成や動作、役割は、ＩＤ層をＬ３のサブレイヤとした場合と同じである。ただし、ＩＤ層をＬ４より上(各ＮＷ装置のＯＳ（Operation System）等で制御できるレベル)で実現することによって、Ｍ２Ｍデバイス−ＰＦサーバ間の中間ルータ等において、既存のＬ２／Ｌ３対応ＮＷ装置を活用することができる。

（第３の実施形態）
図１０は、本発明の第３の実施形態に係わるネットワークシステムの一実施形態を示す概略構成図である。図１１は、本発明の第３の実施形態に係るプロトコルスタックを示す図である。

第３の実施形態は、各装置の基本的な構成や動作、役割については、本発明の第１の実施形態や第２の実施形態と同様である。ただし、Ｍ２Ｍデバイス１１−１〜１１−ｉとＰＦサーバ１３との間で共通のＩＤベース通信を行うのではなく、プロトコル変換機能１２１−１をＭ２Ｍ−ＧＷ装置１２−１に備え、プロトコル変換機能１２１−２をＭ２Ｍ−ＧＷ装置１２−２に備えることで、Ｍ２Ｍデバイス１１−１〜１１−ｉとＭ２Ｍ−ＧＷ装置１２−１，１２−２との間のＩＤ通信(図１１中ではＩＤ（Ｍ）と表記)と、Ｍ２Ｍ−ＧＷ装置１２−１，１２−２とＰＦサーバ１３との間のＩＤ通信(ここではＩＤ（Ｗ）と表記)とで異なるＩＤ通信を行うことができる。

プロトコル変換機能１２１−１，１２１−２は、ＡＰＰサーバ１５−１，１５−２とＭ２Ｍデバイス１１−１〜１１−ｉとの間のコネクション確立のために、ｎｏｎ−ＩＰネットワーク用のＩＤ通信プロトコルと、ＩＰネットワーク用のＩＤ通信プロトコルとの間の変換を行う。この場合、Ｍ２Ｍ−ＧＷ装置１２−１，１２−２は、例えばＩＤ（Ｍ）とＩＤ（Ｗ）との対応を表すテーブルを図示しないメモリに記憶しておく。

第３の実施形態の構成をとることで、新規のＩＤ通信プロトコルを用いることなく、ｎｏｎ−ＩＰネットワークが生来保有する固有の通信プロトコル(たとえばＺｉｇｂｅｅに代表されるネットワークプロトコルそのもの)であるＩＤ（Ｍ）をそのまま適用することが可能となり、新規のＩＤ通信プロトコルはＩＤ（Ｗ）のみでよい構成とできる。また、広域ネットワークＮＷ３およびＭ２ＭエリアネットワークＮＷ１，ＮＷ２区間においては、プロトコル変換機能１２１−１，１２１−２を用いて、本発明の第１の実施形態や第２の実施形態と同様のＭ２Ｍデバイス-Ｍ２Ｍ−ＧＷ-ＰＦサーバ間のＩＤベース通信を実現することで、ＰＦサーバ１３上から、Ｍ２Ｍデバイス１１−１までの到達性を、ネットワーク層において一元的に管理することが可能になる。従って、Ｍ２ＭエリアネットワークＮＷ１，ＮＷ２がＩＰ／ｎｏｎ−ＩＰに依らず、Ｍ２Ｍデバイス１１−１−アプリケーションサーバ１５−１間のエンド−エンドでのＭ２Ｍサービスの提供が可能となる。

（その他の実施形態）
上記ＰＦサーバ１３で説明した個々の処理は、コンピュータプログラムによってソフトウェア処理することが可能である。この場合、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１１−１〜１１−ｉ…Ｍ２Ｍデバイス
１２−１，１２−２…Ｍ２Ｍ−ＧＷ
１３…ＰＦサーバ
１５−１,１５−２…アプリケーションサーバ（ＡＰＰサーバ）
１２１−１，１２１−２…プロトコル変換機能
１３１…データベース（ＰＦ−ＤＢ）
１３２…コネクション処理機能
１３３…コネクション中継機能
ＮＷ１,ＮＷ２…Ｍ２Ｍエリアネットワーク
ＮＷ３…広域ネットワーク
ＮＷ４…ＩＰネットワーク

Claims (8)

1. 第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムであって、
   前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤを記憶する記憶手段と、
   前記デバイスから接続要求を受信するとき、前記接続要求に含まれるデバイスＩＤに基づいて前記記憶手段を参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いて前記Ｍ２Ｍサービスを実行するための通信を行うコネクションを確立するコネクション処理手段と、
   前記アプリケーションサーバから操作要求を受信するとき、前記デバイスと前記アプリケーションサーバとを中継するコネクション中継手段と
   を備えることを特徴とするネットワークシステム。
2. 前記コネクション処理手段は、マッピング部に前記デバイスＩＤと、前記第２の通信ネットワークに対する前記デバイスの接続位置を特定するロケータとを対応付けて記憶しておくことにより、前記デバイスとの間で、前記コネクションを確立し、
   前記デバイスが前記第２の通信ネットワークの第１のロケータから第２のロケータに移動するとき、前記デバイスＩＤ及び前記第１のロケータを用いた第１のコネクションを確立した状態で、前記デバイスＩＤ及び前記第２のロケータを用いた第２のコネクションを確立し、前記第１のコネクションが切断されている場合に、前記マッピング部に記憶されている前記第１のロケータを消去するコネクション変更手段をさらに備えることを特徴とする請求項１に記載のネットワークシステム。
3. 前記コネクション処理手段は、ネットワーク層のサブレイヤ上に前記コネクションを確立することを特徴とする請求項１に記載のネットワークシステム。
4. 前記コネクション処理手段は、アプリケーション層のサブレイヤ上に前記コネクションを確立することを特徴とする請求項１に記載のネットワークシステム。
5. 前記コネクション処理手段は、前記アプリケーションサーバと前記デバイスとの間でコネクション確立のための前記デバイスＩＤのプロトコル変換を行うプロトコル変換手段と、
   をさらに備えることを特徴とする請求項１に記載のネットワークシステム。
6. 前記コネクション中継手段は、前記コネクションを介して前記デバイスとの通信により、前記デバイスに関する情報を取得して前記記憶手段に前記デバイスＩＤに対応付けて管理し、前記アプリケーションサーバからの操作要求に応じて、前記記憶手段から前記デバイスに関する情報を取得することを特徴とする請求項１に記載のネットワークシステム。
7. 第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムの構成方法であって、
   前記第１の通信ネットワーク及び前記第２の通信ネットワークを接続可能なクラウド上に設けられる中継サーバ装置が、前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤをデータベースに記憶し、
   前記デバイスから接続要求を受信するとき、前記中継サーバ装置が、前記接続要求に含まれるデバイスＩＤに基づいて前記データベースを参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いて前記Ｍ２Ｍサービスを実行するための通信を行うコネクションを確立し、
   前記アプリケーションサーバから操作要求を受信するとき、前記中継サーバ装置が、前記デバイスと前記アプリケーションサーバとを中継することを特徴とするネットワークシステムの構成方法。
8. 第１の通信ネットワークに接続されるアプリケーションサーバと第２の通信ネットワークに接続されるデバイスとの間でＭ２Ｍサービスを実行するネットワークシステムの中継サーバ装置を
   前記アプリケーションサーバから送られ前記デバイスを特定するデバイスＩＤを記憶する記憶手段と、
   前記デバイスから接続要求を受信するとき、前記接続要求に含まれるデバイスＩＤに基づいて前記記憶手段を参照し、この参照結果に基づいて、前記アプリケーションサーバと前記デバイスとの間で、前記デバイスＩＤを用いて前記Ｍ２Ｍサービスを実行するための通信を行うコネクションを確立するコネクション処理手段と、
   前記アプリケーションサーバから操作要求を受信するとき、前記デバイスと前記アプリケーションサーバとを中継するコネクション中継手段と
   して動作させるプログラム。