JP2019033519A - マシンツーマシン通信システムにおける異なるデバイスのトリガリング - Google Patents

Abstract

【課題】Ｍ２Ｍデバイス間の通信を促進するための方法および装置を提供する。【解決手段】マシンツーマシン（Ｍ２Ｍ）通信システムにおいて、共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスについてのリクエストをＣＳＥ−ＩＤとともに基盤ネットワークから受信する５０２。Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて、サービスのリクエストについてＣＳＥ−ＩＤと対応付けられたＭ２Ｍデバイスを識別する５０４。互いに異なるドメインにおいて、事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについての準備する５０６。【選択図】図５

Description

＜関連出願に対する相互参照＞
本特許文書は、２０１４年２月１０日出願の米国仮出願６１／９３８，１１５号；２０１４年２月１６日出願の米国仮出願６１／９４０，４８９号；２０１４年２月１８日出願の米国仮出願６１／９４１，３５９号；２０１４年３月１１日出願の米国仮出願６１／９９１，６０８号；の優先権を主張する。これら特許出願の全内容は、参照により本文書の開示の一部として組み込まれる。

本文書は、マシンツーマシン（Ｍ２Ｍ）通信に関する。

Ｍ２Ｍ通信は一般に、２つの異なるデバイス間の通信であって、ユーザが明示的にトリガしないもののことである。デバイスは、有線または無線接続を用いてＭ２Ｍ通信を実施することができる。通信は通常、いずれかのマシン上のアプリケーションによって起動され、他マシン上の対応するアプリケーションから情報を収集し、または情報を送信する。

本文書は、Ｍ２Ｍデバイス間の通信を促進するための技術を記載する。本開示の技術を用いることにより、実施形態において、Ｍ２Ｍ通信エンドポイントまたはエンドポイント上のアプリケーションエンティティをトリガして、エンドポイント間の通信を促進することができる。

Ｍ２Ｍ通信を促進する１例、方法、システム、および装置は、共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスについてのリクエストをＣＳＥ−ＩＤとともに基盤ネットワークから受信するステップ；前記サービスのリクエストについて前記ＣＳＥ−ＩＤに対応付けられたＭ２Ｍデバイスを、Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて識別するステップ；互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するステップ；を有する。

他の側面において、Ｍ２Ｍ通信を促進する技術は、基盤ネットワークからデバイストリガサービスについてのリクエストを受信するステップ；Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを用いて、トリガリングをルーティングすべきリモートエンティティを識別するステップ；互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するステップ；を有する。

これらおよびその他側面、実装例、および変形例は、以下の図面、詳細説明、および特許請求範囲に記載されている。

無線ネットワークアーキテクチャの例を示す。

無線ネットワークで動作することができる無線デバイスのブロック図である。

Ｍ２Ｍ通信システムのアーキテクチャ例を示す。

ＣＳＥＢａｓｅリソースの例を示す。

ｒｅｍｏｔｅＣＳＥリソースの例を示す。

Ｍ２Ｍ通信を促進する方法の例を示す。

Ｍ２Ｍ通信を促進する装置の例を示す。

マシンツーマシン（Ｍ２Ｍ）通信を促進する方法７００のフローチャートの例を示す。

マシンツーマシン（Ｍ２Ｍ）通信を促進する装置８００のブロック図の例を示す。

各図面における同様の符号は、同様の要素を示す。

本文書において、以下の略語を用いる。

ＡＮＤ：アプリケーション専用ノード

ＡＤＮ−ＡＥ：アプリケーション専用ノード上のＡＥ

ＡＥ：アプリケーションエンティティ

Ａｐｐ：アプリケーション

ＡＳＮ：アプリケーションサービスノード

ＡＳＥ−ＡＥ：アプリケーションサービスノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ

ＡＳＮ−ＣＳＥ：アプリケーションサービスノード上のＣＳＥ

ＢＢＦ：ブロードバンドフォーラム

ＣＳＥ：共通サービスエンティティ

ＣＳＦ：共通サービス機能

ＥＦ：イネーブラ機能

ＩＥＥＥ：Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ

ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ

ＩＮ：インフラノード

ＩＮ−ＡＥ：インフラノードにおいてＣＳＥとともに登録されたアプリケーションエンティティ

ＩＮ−ＣＳＥ：インフラノード上のＣＳＥ

ＪＮＩ：Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ

ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ

ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ

Ｍ２Ｍ：マシンツーマシン

ＭＮ：ミドルノード

ＭＮ−ＣＳＥ：ミドルノード上のＣＳＥ

ＮＳＥ：ネットワークサービスエンティティ

ＳＤＯ：規格開発団体

ＳＰ：サービスプロバイダ

ＵＮｅｔ：基盤ネットワーク（Ｍ２Ｍデバイスが存在するネットワーク）

マシンツーマシン（Ｍ２Ｍ）通信において、２つのデバイス（例えばアプリケーションサーバとＭ２Ｍデバイス）は、人間のユーザが明示的に通信を開始することなく、互いに通信することができる。Ｍ２Ｍ通信において、通信が発生する２つのエンドポイントは、異なるネットワーク上に存在する場合がある。一般的なアプリケーションシナリオにおいて、１つのエンドポイントはある期間オフラインになるセンサまたはユーティリティボックスであり、他のエンドポイントはユーティリティ請求サーバやＭ２Ｍサーバなどのような管理ネットワーク上に配置されるアプリケーションサーバである。これら２つのエンドポイント間を行き交うデータパケットは、様々なルーティングオプションによってルーティングすることができる。例えば１つのエンドポイントは、ライセンスされたスペクトル上で（例えばＬｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）またはライセンスされていないスペクトル上で（例えばＷｉ−Ｆｉ）、通信することができる。１つのエンドポイントがある期間オフラインになると（例えば数日あるいは数週間）、最後の通信セッションの間においてパケットがそのエンドポイントへルーティングされた方法は、パケットを現在の通信セッションにおいてルーティングすることができる方法とは、必ずしも一致しない。さらに様々なルーティングオプションを用いると、様々なコストが生じる（例えば帯域幅チャージや通信中のパワー散逸）。

図１は、無線通信ネットワークまたはシステムの例を示す。この無線通信ネットワークは、１以上のベースステーション（ＢＳ）１０５と１０７、１以上の無線デバイス１１０を含む。ベースステーション１０５と１０７は、１以上の無線デバイス１１０に対して、フォワードリンク（ＦＬ）上でシグナル（ダウンリンク（ＤＬ）シグナルとして知られている）を送信することができる。無線デバイス１１０は、１以上のベースステーション１０５と１０７に対して、リバースリンク（ＲＬ）上でシグナル（アップリンク（ＵＬ）シグナルとして知られている）を送信することができる。無線通信システムは、１以上のネットワーク１２５を備え、１以上のベースステーション１０５と１０７を制御することができる。１以上のベースステーションは、無線アクセスネットワークを形成する。ベースステーションは、単独でまたは他のベースステーションとの組み合わせにより無線デバイスに無線アクセスを提供するという性質上、アクセスポイント（ＡＰ）、アクセスネットワーク（ＡＮ）、またはｅＮｏｄｅＢと呼ばれる場合がある。本技術とシステムを実装することができる無線通信システムの例としては、ＣＤＭＡ２０００ １ｘなどのＣｏｄｅ ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ（ＣＤＭＡ）、Ｈｉｇｈ Ｒａｔｅ Ｐａｃｋｅｔ Ｄａｔａ（ＨＲＰＤ）、Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、 Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ）などに基づく無線通信システムが挙げられる。

図２は、無線デバイス、ベースステーション、その他無線通信モジュールを実装する無線トランシーバステーションの例を示す。無線ステーションの例として、図１のベースステーションや無線デバイスが挙げられる。ベースステーションや無線デバイスなどの無線ステーション２０５は、プロセッサ電子部品２１０を備える。プロセッサ電子部品２１０は、例えば本文書が提示する技術のうち１以上の方法を実装するマイクロプロセッサである。無線ステーション２０５は、トランシーバ電子部品２１５を備え、例えば１以上のアンテナ２２０などの１以上の通信インターフェースを介して無線シグナルを送受信することができる。無線ステーション２０５は、データを送受信するためのその他通信インターフェースを備えることもできる。実装例において無線ステーション２０５は、１以上の有線通信インターフェースを備え、有線ネットワークと通信することができる。無線ステーション２０５は、データおよび／または命令などの情報を格納するように構成された１以上のメモリ２２５を備える。実装例においてプロセッサ電子部品２１０は、トランシーバ電子部品２１５とメモリ２２５のうち少なくとも一部を備えることができる。

実装例において無線ステーション２０５は、ＣＤＭＡまたはＧＳＭベース無線インターフェースに基づき相互通信することができる。実装例において無線ステーション２０５は、直交周波数分割多重（ＯＦＤＭ）インターフェースに基づき相互通信することができる。このインターフェースは、例えば直交周波数分割多重アクセス（ＯＦＤＭＡ）インターフェースを含む。実装例において無線ステーション２０５は、１以上の無線技術を用いて通信することができる。例えばＣＤＭＡ２０００ １ｘ、ＨＲＰＤ、ＷｉＭＡＸ、ＧＳＭ、ＬＴＥ、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）である。

実装例において無線ステーション２０５は、例えば８０２．１１（ａ／ｂ／ｇ／ｎ）インターフェースなどのローカルエリアネットワーク接続を用いて構成することができる。このようなインターフェースを利用することにより、ローカルエリア接続を介してインターネットに対して無線ステーション２０５を接続することができる。例えばユーザは、ケーブルモデムネットワークやＤＳＬネットワークなどの固定ブロードバンドネットワーク経由で無線ローカルエリアネットワーク接続（例えばホームＷｉ−Ｆｉアクセス）を通じてサービスに接続することにより、自身の装置（ＵＥ）を介してサービスにアクセスすることができる。上記無線ステーション２０５を用いて、本文書が開示する技術を実装することができる。

電力その他リソースを節約するため、Ｍ２Ｍデバイスやこれらデバイス上で動作するアプリケーションエンティティのなかには、時間経過にともなって“オフライン”になるものがある。アプリケーションレイヤ通信を再確立するため、これらＭ２Ｍエンティティを通信の前に起動する必要がある。トリガリングを実施する態様や起動されるモジュールもしくはエンティティは、個々のＭ２Ｍデバイスの設定や性能に依拠する。

ｏｎｅＭ２Ｍ、ＥＴＳＩ ＴＣ Ｍ２Ｍ、ＴＩＡ ＴＲ−５０などの団体（Ｍ２Ｍ ＳＤＯ）が開発しているサービスレイヤ仕様は、広範な市場（垂直）組織によるＭ２Ｍソリューションの効率的な配置をサポートする必要がある。サービスレイヤにフォーカスすると、これら組織は送信ネットワークから独立してエンドツーエンドサービスを把握している。ただし、異なるタイプの送信ネットワークとインターフェースをとるため、サービスレイヤ仕様が確実に効率的に使われるようにする必要がある。送信ネットワークの例としては、３ＧＰＰ、３ＧＰＰ２、ＩＥＥＥ、ＩＥＴＦ、ＢＢＦが規定する無線および有線ネットワークが挙げられるが、これに限らない。

サービスレイヤ仕様において、現在、共通サービスリソースを保持するエンティティに関連付けられた特定のＭ２Ｍデバイスをサービスリクエストが識別してＭ２Ｍリクエストを充足する手段はない。さらに、スリープ中のＭ２Ｍデバイスをトリガリング起動してＭ２Ｍ通信リクエストを充足する必要がある場合、リクエストをルーティングすべきトリガリングデバイスを現行システムが特定する方法は、限られている。本文書が提示する技術は、これらおよびその他課題を解決する。

図３は、ｏｎｅＭ２Ｍシステムがサポートする構成３００の例を示す。図３は、ｏｎｅＭ２Ｍが開発している機能アーキテクチャ仕様の抜粋である。

この例３００において、ＡＤＮ（ＡＤＮ−ＡＥ）上のアプリケーションエンティティ（ＡＥ）は、ＩＮ−ＣＳＥに登録する。同様に非ノードＡＥも、ＩＮ−ＣＳＥに登録する。ＡＤＮ−ＡＥは、ＭＮ−ＣＳＥにも登録する。これら登録は、リモートエンティティ／ノードにおけるＡＥとＣＳＥとの間の登録である。

ＣＳＥは、１以上のＣＳＦのインスタンスである。ＣＳＥは、Ｍ２Ｍアプリケーションが使用し共有することができるＣＳＦのサブセットを提供する。ＣＳＥは、ＵＮｅｔ機能を利用することができ、他のＣＳＥと通信してサービスを充足することができる。ＣＳＥは、Ｍ２Ｍ環境において共通の“サービス機能”セットを備える。このサービス機能は、ｏｎｅＭ２Ｍが規定するＭｃａ参照ポイントやＭｃｃ参照ポイントなどの参照ポイント（図３参照）を介して、他のエンティティに対して公開される。Ｍｃｃ参照ポイントは、ＣＳＥ間の通信フローを定義する。参照ポイントＭｃｎは、基盤ネットワークサービスエンティティにアクセスするために用いられる。ＣＳＥが提供するサービス機能の例は以下である：データ管理、デバイス管理、Ｍ２Ｍサブスクリプション管理、位置サービス、など。ＣＳＥが提供するこれら“サブ機能”は、論理的に共通サービス機能（ＣＳＦ）として把握することができる。共通サービスエンティティ（ＣＳＥ）内部において、ＣＳＦのうちいくつかは固定であり、その他はオプションである。ＣＳＦ内部において、サブ機能のうちいくつかは固定またはオプションである（例えば“デバイス管理”ＣＳＦ内部において、“アプリケーションソフトウェアインストール”、“ファームウェアアップデート”、“ログ”、“監視”などのサブ機能のうちいくつかは、固定またはオプションである）。

ＣＳＦは、Ｍ２Ｍ環境において共通のサービス機能セットであり、ｏｎｅＭ２Ｍなどの相互仕様によって規定される。

図３において、以下の略語を用いる：

非ノードＡＥ：このエンティティは、ＩＮ−ＡＥがアプリケーションサービスプロバイダによってホストされていることを示す。

ノード：少なくとも１つの共通サービスエンティティ（ＣＳＥ）および／またはアプリケーションエンティティ（ＡＥ）を保持する機能エンティティ。ノードは、例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備などの物理装置内に保持することができる。異なるノード上のＣＳＥは一般に同一ではなく、当該ノードのＣＳＥがサポートするサービスに依拠する。実施形態において、２つのタイプのノードが定義される。１つのノードタイプは、少なくとも１つの共通サービスエンティティおよび／または１以上のｏｎｅＭ２Ｍアプリケーションエンティティを保持する機能エンティティである。このノードをＣＳＥ機能ノードと呼ぶ。もう１つのノードタイプは、１以上のアプリケーションエンティティを保持し共通サービスエンティティを保持しない機能エンティティである。このノードを非ＣＳＥ機能ノードと呼ぶ。ｏｎｅＭ２Ｍアーキテクチャにおいて、ＣＳＥ機能ｏｎｅＭ２Ｍノードは、物理オブジェクト内に保持することができる。例えばＭ２Ｍデバイス、ゲートウェイ、サーバ設備である。非ＣＳＥ機能ｏｎｅＭ２Ｍノードは、例えばセンサ、アクチュエータなどの物理オブジェクト内に保持することができる。ＣＳＥ機能ノードと非ＣＳＥ機能ノードは、Ｍｃａ参照ポイントを介して通信する。

Ｍｃｃ’参照ポイントは、可能な限りＭｃｃ参照ポイントと同様のものであることを意図している。ただしＭ２Ｍ間サービスプロバイダ通信の性質により、いくつかの違いが存在する。

構成２００において、様々なタイプのノードが存在し得る。ノードは実際の物理オブジェクトにマッピングされる場合があるが、必ずしも単一の実際の物理オブジェクトに対してマッピングされる必要はない。以下のノードが存在する：

アプリケーションサービスノード（ＡＳＮ）：アプリケーションサービスノードは、１つの共通サービスエンティティと少なくとも１つのアプリケーションエンティティを保持するノードである。アプリケーションサービスノードは、Ｍｃｃ参照ポイントを介して、１つのミドルノードまたは１つのインフラノードと通信することができる。物理マッピングの例としては、アプリケーションサービスノードがＭ２Ｍデバイス上に配置される場合が挙げられる。

アプリケーション専用ノード（ＡＤＮ）：アプリケーション専用ノードは、少なくとも１つのアプリケーションエンティティを保持し、共通サービスエンティティを保持しない。アプリケーション専用ノードは、Ｍｃａ参照ポイントを通じてミドルノードまたはインフラノードと通信する。物理マッピングの例としては、アプリケーション専用ノードが制約Ｍ２Ｍデバイス上に配置される場合が挙げられる。

ミドルノード（ＭＮ）：ミドルノードは、１つの共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。ミドルノードは、Ｍｃｃを介してＩＮまたは他のＭＮと通信し、さらにＭｃｃを介してＩＮ／ＭＮ／ＡＳＮの少なくともいずれかと通信し、またはＭｃａを介してＡＤＮと通信する。物理マッピングの例としては、ミドルノードがＭ２Ｍゲートウェイ上に配置される場合が挙げられる。

インフラノード（ＩＮ）：インフラノードは、共通サービスエンティティとゼロ以上のアプリケーションエンティティを保持するノードである。インフラノードは、Ｍｃｃ参照ポイントを介して１以上のミドルノードと通信し、および／または１以上のアプリケーションサービスノードと通信する。インフラノードは、Ｍｃａ参照ポイントを介して１以上のアプリケーション専用ノードと通信する。物理マッピングの例としては、インフラノードがＭ２Ｍサーバ設備上に配置される場合が挙げられる。

Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）

Ｍ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ−ＩＤによって識別されるＣＳＥ向けのサービスが基盤ネットワークからリクエストされたとき、Ｍ２Ｍ ＳＰによって用いられる。

Ｍ２Ｍ外部ＩＤにより、基盤ネットワークはサービスリクエストについてＣＳＥ−ＩＤと関連付けられたＭ２Ｍデバイスを識別することができる。その意味において、基盤ネットワークはＭ２Ｍ−Ｅｘｔ−ＩＤをターゲットＭ２Ｍデバイスに割り当てられたＵＮｅｔ固有ＩＤにマッピングする。Ｍ２Ｍ ＳＰは、ＣＳＥ−ＩＤ、Ｍ２Ｍ−Ｅｘｔ−ＩＤ、およびＵＮｅｔ ＩＤの間の対応関係を維持することができる。

様々な実施形態において、ＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤとの間の事前準備した対応関係と動的対応関係をともに実装することができる。

各ＣＳＥ−ＩＤについて、特定の基盤ネットワークＩＤまたはＵＮｅｔｗｏｒｋ−ＩＤについてＭ２Ｍ−Ｅｘｔ−ＩＤが１つのみ存在すべきである。したがって、複数の基盤ネットワークと相互作用するＭ２Ｍ ＳＰは、同一のＣＳＥ−ＩＤに対応付けられた異なるＭ２Ｍ−Ｅｘｔ−ＩＤを基盤ネットワークごとに有し、基盤ネットワークに対して発するサービスリクエストに対して適切なＭ２Ｍ−Ｅｘｔ−ＩＤを選択する。

一般に、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＭ２ＭデバイスのＵＮｅｔによるマッピングは、ＵＮｅｔ固有のものである。

構成例において、ＵＮｅｔプロバイダとＭ２Ｍサービスプロバイダは、ＣＳＥ−ＩＤによって識別される各ＣＳＥに対してＭ２Ｍ−Ｅｘｔ−ＩＤを割り当てるに際して、協調することができる。同時にＵＮｅｔプロバイダは、ＣＳＥをホストするＭ２Ｍデバイスに対して割り当てられた、Ｍ２Ｍ−Ｅｘｔ−ＩＤとＵＮｅｔ固有ＩＤとの間の対応関係を維持する。

事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、対応付けられたＣＳＥ−ＩＤとＭ２Ｍ−Ｅｘｔ−ＩＤは、インフラノードにおいて準備することができる。Ｍ２ＭデバイスにおけるＣＳＥは、割り当てられたＭ２Ｍ−Ｅｘｔ−ＩＤを知っておく必要はない。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＭ２Ｍ−Ｅｘｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備することができる。このＭ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。

トリガ受信者ＩＤ（Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤ）

Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＵＮｅｔからデバイストリガリングサービスがリクエストされたとき、実行環境上のトリガをルーティングすべきＡＳＮ／ＭＮ−ＣＳＥインスタンスを識別するために用いられる。例えば３ＧＰＰデバイストリガリングを用いる場合、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤはＡｐｐｌｉｃａｔｉｏｎ−Ｐｏｒｔ−Ｉｄｅｎｔｉｆｉｅｒにマッピングされる。例えば３ＧＰＰ ２３．６８２規格で規定されているものである。

事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、Ｍ２Ｍ−Ｅｘｔ−ＩＤおよび関連するＣＳＥ−ＩＤとともにインフラノードにおいて準備される。動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについて、基盤ネットワーク固有のＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、フィールドドメイン内の各Ｍ２Ｍデバイスにおいて準備される。Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥに対して搬送される。

表１は、Ｍ２Ｍ ＩＤとその使用属性を例示するリストである。具体的には、表１にリストするように、外部ＩＤはＵＮｅｔプロバイダとＭ２Ｍ ＳＰとの間で連結して割り当てられ、ＵＮｅｔサービスを利用することを望むＣＳＥに属するＭ２Ｍノードに対して割り当てられ、２つの準備モードを有する。すなわち事前準備モードと動的モードであり、外部ＩＤは対応するＣＳＥの登録プロセスにおいて搬送される。

Ｍ２Ｍ ＩＤ ライフサイクルおよび特徴

リソースタイプＣＳＥＢａｓｅ

＜ＣＳＥＢａｓｅ＞リソースを用いて、ＣＳＥを表すことができる。この＜ＣＳＥＢａｓｅ＞リソースは、ＣＳＥ上の全てのリソースのルートである。

図４Ａは、ＣＳＥＢａｓｅリソースに含まれる属性を例示するリストを示す。

＜ＣＳＥＢａｓｅ＞リソースは、表２に示す子リソースを含む。

＜ＣＳＥＢａｓｅ＞リソースは、表３に示す属性を含む。

リソースタイプｒｅｍｏｔｅＣＳＥ

＜ｒｅｍｏｔｅＣＳＥ＞リソースは、登録ＣＳＥに登録されたリモートＣＳＥを表す。＜ｒｅｍｏｔｅＣＳＥ＞リソースは、＜ＣＳＥＢａｓｅ＞の下に直接配置される。反対に登録された各ＣＳＥは、登録ＣＳＥの＜ＣＳＥＢａｓｅ＞における＜ｒｅｍｏｔｅＣＳＥ＞リソースのサブセットとして表すことができる。例えば、ＣＳＥ１がＣＳＥ２を登録するとき、２つの＜ｒｅｍｏｔｅＣＳＥ＞リソースが生成される：１つはＣＳＥ１における＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞であり、もう１つはＣＳＥ２における＜ＣＳＥＢａｓｅ２＞／＜ｒｅｍｏｔｅＣＳＥ１＞である。２つのリソースの生成は、必ずしも相互登録を示すものではない。＜ＣＳＥＢａｓｅ１＞／＜ｒｅｍｏｔｅＣＳＥ２＞は、上記例においてＣＳＥ２がＣＳＥ１に登録されることを自動的に意味するものではない。

＜ｒｅｍｏｔｅＣＳＥ＞リソースは、例えば表４に示すような子リソースを含む。

図４Ｂは、＜ｒｅｍｏｔｅＣＳＥ＞リソースに含まれる子リソースを例示するリストである。

実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞リソースは表５にリストする属性を含む。

実施形態において、＜ｒｅｍｏｔｅＣＳＥ＞とアナウンスされた＜ｒｅｍｏｔｅＣＳＥ＞は、２つのリソース間で識別できるようにするため、異なるｒｅｓｏｕｒｃｅＴｙｐｅコードを有する。

図５は、Ｍ２Ｍ通信を促進する方法５００のフローチャートの例である。

方法５００は、基盤ネットワークから、共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスのリクエストをＣＳＥ−ＩＤとともに受信するステップ５０２を有する。

方法５００は、Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて、サービスリクエストについてＣＳＥ−ＩＤと対応付けられたＭ２Ｍデバイスを識別するステップ５０４を有する。

方法５００は、互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するステップ５０６を有する。実施形態において準備動作は、事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはインフラドメインのインフラノードにおいて対応するＣＳＥ−ＩＤとともにＭ２Ｍ−Ｅｘｔ−ＩＤを準備することにより、動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはフィールドドメインのＣＳＥをホストするＭ２ＭデバイスにおいてＭ２Ｍ−Ｅｘｔ−ＩＤを準備することにより、実施することができる。

実施形態において、方法５００はさらに、Ｍ２Ｍ−Ｅｘｔ−ＩＤを基盤ネットワーク固有ＩＤへマッピングするステップを有する。実施形態において、方法５００はさらに、ＣＳＥ−ＩＤ、Ｍ２Ｍ−Ｅｘｔ−ＩＤ、および基盤ネットワーク固有ＩＤの間の対応関係を保持するステップを有する。

実施形態において、フィールドドメインで準備されるＭ２Ｍ−Ｅｘｔ−ＩＤは、ＩＮ−ＣＳＥに対して送信される。

図６は、Ｍ２Ｍ通信を促進する装置６００の例を示す。装置６００は、基盤ネットワークから、共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスのリクエストをＣＳＥ−ＩＤとともに受信するためのモジュール６０２；Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて、サービスリクエストについてＣＳＥ−ＩＤと対応付けられたＭ２Ｍデバイスを識別するためのモジュール６０４；互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するためのモジュール６０６；を備える。モジュール６０２、６０４、６０６、および装置６００はさらに、本文書が開示する技術を実装することができる。

図７は、マシンツーマシン（Ｍ２Ｍ）通信を促進する方法５００のフローチャートの例である。

方法７００は、基盤ネットワークからデバイストリガリングサービスについてリクエストを受け取るステップ７０２を有する。

方法７００は、Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを用いて、トリガリングをルーティングすべきリモートエンティティを識別するステップ７０４を有する。

方法７００は、互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するステップ７０６を有する。

実装例において準備動作（７０６）は、事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはインフラドメインのインフラノードにおいてＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備するステップを有し、動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはフィールドドメインの共通サービスエンティティ（ＣＳＥ）をホストするＭ２ＭデバイスにおいてＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備するステップを有する。実装例において、準備動作を実施するステップはさらに、インフラノードにおいてＭ２Ｍ−Ｅｘｔ−ＩＤと対応するＣＳＥ−ＩＤを準備するステップを有する。実装例において、フィールドドメインで準備されたＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＩＮ−ＣＳＥへ送信される。

図８は、マシンツーマシン（Ｍ２Ｍ）通信を促進する装置８００のブロック図の例を示す。装置８００は、基盤ネットワークからデバイストリガリングサービスについてリクエストを受け取るための受信モジュール８０２；Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを用いて、トリガリングをルーティングすべきリモートエンティティを識別するための識別モジュール８０４；互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する動作を実施するための準備モジュール８０６；を備える。

実装例において準備モジュールは、事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはインフラドメインのインフラノードにおいてＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備し、動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについてはフィールドドメインの共通サービスエンティティ（ＣＳＥ）をホストするＭ２ＭデバイスにおいてＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備する。実装例において準備モジュールはさらに、インフラノードにおいてＭ２Ｍ−Ｅｘｔ−ＩＤと対応するＣＳＥ−ＩＤを準備する。実装例において、フィールドドメインで準備されたＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＩＮ−ＣＳＥへ送信される。

本文書が開示したものその他の実施形態、モジュール、および機能動作は、デジタル電子回路内、またはコンピュータソフトウェア、ファームウェア、ハードウェア内に実装することができる。これらは本文書が開示する構造およびその等価構造、さらにはこれらの１以上の組み合わせを含む。開示する実施形態およびその他の実施形態は、１以上のコンピュータプログラム製品として実装することができる。すなわち、コンピュータ読取可能媒体に記録され、データ処理装置が実行しまたはその動作を制御する、１以上のコンピュータプログラム命令のモジュールである。コンピュータ読取可能媒体は、機械読取可能記憶装置、機械読取可能記憶基板、メモリデバイス、機械読取可能伝搬信号を生成する合成物、またはこれらの１以上の組み合わせである。データ処理装置という用語は、全ての装置、デバイス、データ処理機械を包含する。これらは例えばプログラム可能プロセッサ、コンピュータ、マルチプロセッサまたはコンピュータを含む。装置は、ハードウェアに加えて、コンピュータプログラムの命令環境を生成するコードを含む。例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、またはこれらの１以上の組み合わせを構成するコードである。伝搬信号は、人工生成された信号である。例えば、適当な受信装置に対して送信するために情報をコード化するように生成された、機械生成による電気的、光学的、または電磁的信号である。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている）は、任意形態のプログラム言語で記述することができる。これはコンパイル言語またはインタプリタ言語を含み、任意形態で配布することができる。これはスタンドアロンプログラムまたはモジュール、コンポーネント、サブルーチン、その他のコンピュータ環境において使用するのに適したユニットを含む。コンピュータプログラムは、ファイルシステムに対応している必要はない。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語文書内に格納された１以上のスクリプト）を保持する、当該プログラム専用の単一ファイル内または複数協調ファイル（例えば、１以上のモジュール、サブプログラム、またはコードの一部を格納するファイル）内におけるファイルの一部に格納することができる。コンピュータプログラムを配布して、１サイトに配置されまたは複数サイトをまたがって通信ネットワークによって相互接続配置された１以上のコンピュータによって実行することができる。

本文書において開示するプロセスとロジックフローは、１以上のコンピュータプログラムを実行する１以上のプログラム可能プロセッサによって実施して、入力データ上で動作し出力を生成することにより機能を実施することができる。プロセスとロジックフローは例えばＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）やＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）のような特定用途論理回路によって実施することもできる。装置はこれら回路として実装することもできる。

コンピュータプログラムを実行するのに適したプロセッサは、例えば汎用および特定用途マイクロプロセッサ、または任意タイプのデジタルコンピュータの１以上のプロセッサを含む。一般にプロセッサは、読取専用メモリまたはランダムアクセスメモリまたはこれら双方から命令とデータを受信する。コンピュータの必須要素は、命令を実施するプロセッサと、命令およびデータを格納する１以上のメモリデバイスである。一般にコンピュータはさらに、データを格納する１以上の大規模記憶デバイスを備え、またはこれらと動作可能に連結されデータを受信または送信する。例えば磁気ディスク、光磁気ディスク、または光ディスクである。しかしコンピュータはこれらデバイスを必ずしも備えなくともよい。コンピュータプログラム命令とデータを格納するのに適したコンピュータ読取可能媒体は、不揮発性メモリ、媒体、およびメモリデバイスの全ての形態を含む。これは例えば、ＥＰＲＯＭやＥＥＰＲＯＭのような半導体メモリデバイス、フラッシュメモリデバイス、例えば内部ハードディスクやリムーバブルディスクのような磁気ディスク、光磁気ディスク、ＣＤＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む。プロセッサとメモリは、特定用途論理回路内によって補充され、またはその内部に設けることができる。

本文書は詳細記述を含むが、これらは特許請求しまたはする可能性のある本発明の範囲に対する制約として解釈すべきではない。むしろ特定実施形態に固有の構成の記述として解釈すべきである。個々の実施形態の文脈において本文書が開示する特定要素は、単一実施形態の組み合わせにおいて実装することができる。これとは反対に、単一実施形態の文脈において開示する様々な要素は、複数の実施形態またはその任意の組み合わせにおいて個別に実装することができる。さらに、要素は特定の組み合わせにおいて動作することを説明し、そのように特許請求しているが、特許請求する組み合わせからの１以上の要素は場合によっては組み合わせから除去することができる。特許請求する組み合わせは、サブ組み合わせまたはサブ組み合わせの変形物とすることができる。同様に、図面内の動作は特定順序で示したが、所望結果を実現するために、そのような動作を図示する特定順序で実施することが必要であり、また全動作を実施することが必要であると解釈すべきではない。

数個の例と実装のみを開示した。開示内容に基づき、説明した例および実装に対する変形、修正、拡張、その他の実装をすることも可能である。

Claims (19)

1. マシンツーマシン（Ｍ２Ｍ）通信を促進する方法であって、
   共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスについてのリクエストをＣＳＥ−ＩＤとともに基盤ネットワークから受信するステップであって、前記ＣＳＥは複数のＭ２Ｍサービスに共通の１以上のサービス機能を備える、ステップ、
   前記サービスのリクエストについて前記ＣＳＥ−ＩＤに対応付けられたＭ２Ｍデバイスを、前記Ｍ２Ｍデバイスに対応付けられたＭ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて識別するステップ、
   互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤのうち少なくとも１つの準備動作を実施するステップ、
   を有することを特徴とする方法。
2. 前記準備動作を実施するステップは、
   事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、インフラドメインのインフラノードにおいて対応するＣＳＥ−ＩＤとともに前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備するステップ、
   動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、フィールドドメインで前記ＣＳＥをホストするＭ２Ｍデバイスにおいて前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備するステップ、
   を有することを特徴とする請求項１記載の方法。
3. 前記方法はさらに、前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを基盤ネットワーク固有ＩＤにマッピングするステップを有する
   ことを特徴とする請求項１記載の方法。
4. 前記方法はさらに、前記ＣＳＥ−ＩＤ、前記Ｍ２Ｍ−Ｅｘｔ−ＩＤ、および前記基盤ネットワーク固有ＩＤの間の対応関係を維持するステップを有する
   ことを特徴とする請求項３記載の方法。
5. 前記フィールドドメインにおいて準備された前記Ｍ２Ｍ−Ｅｘｔ−ＩＤは、ＩＮ−ＣＳＥへ送信される
   ことを特徴とする請求項１記載の方法。
6. マシンツーマシン（Ｍ２Ｍ）通信を促進する装置であって、
   共通サービスエンティティ（ＣＳＥ）をターゲットとするサービスについてのリクエストをＣＳＥ−ＩＤとともに基盤ネットワークから受信する受信モジュール、
   前記サービスのリクエストについて前記ＣＳＥ−ＩＤに対応付けられたＭ２Ｍデバイスを、Ｍ２Ｍ外部ＩＤ（Ｍ２Ｍ−Ｅｘｔ−ＩＤ）を用いて識別する識別モジュール、
   互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤの準備動作を実施する準備モジュール、
   を備えることを特徴とする装置。
7. 前記準備モジュールは、
   事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、インフラドメインのインフラノードにおいて対応するＣＳＥ−ＩＤとともに前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備し、
   動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、フィールドドメインで前記ＣＳＥをホストするＭ２Ｍデバイスにおいて前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを準備する
   ことを特徴とする請求項６記載の装置。
8. 前記基盤ネットワークは、前記Ｍ２Ｍデバイスに対して割り当てられた前記基盤ネットワーク固有ＩＤへ前記Ｍ２Ｍ−Ｅｘｔ−ＩＤをマッピングする
   ことを特徴とする請求項６記載の装置。
9. 前記Ｍ２Ｍデバイスにおける前記ＣＳＥは、前記Ｍ２Ｍデバイスに対して割り当てられた前記Ｍ２Ｍ−Ｅｘｔ−ＩＤを認識しない
   ことを特徴とする請求項６記載の装置。
10. 前記フィールドドメインにおいて準備された前記Ｍ２Ｍ−Ｅｘｔ−ＩＤは、ＣＳＥ登録プロセスにおいてＩＮ−ＣＳＥへ送信される
    ことを特徴とする請求項６記載の装置。
11. マシンツーマシン（Ｍ２Ｍ）通信を促進する方法であって、
    基盤ネットワークからデバイストリガサービスについてのリクエストを受信するステップ、
    前記リクエストとともに受信したＴｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを用いて、トリガリングをルーティングすべきリモートエンティティを識別するステップ、
    互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤのうち少なくとも１つの準備動作を実施するステップ、
    を有することを特徴とする方法。
12. 前記準備動作を実施するステップは、
    事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、インフラドメインのインフラノードにおいて前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備するステップ、
    動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、フィールドドメインで共通サービスエンティティ（ＣＳＥ）をホストするＭ２Ｍデバイスにおいて前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備するステップ、
    を有することを特徴とする請求項１１記載の方法。
13. 前記準備動作を実施するステップはさらに、前記インフラノードにおいて前記Ｍ２Ｍ−Ｅｘｔ−ＩＤおよび対応するＣＳＥ−ＩＤを準備するステップを有する
    ことを特徴とする請求項１２記載の方法。
14. 前記フィールドドメインにおいて準備された前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＩＮ−ＣＳＥへ送信される
    ことを特徴とする請求項１２記載の方法。
15. マシンツーマシン（Ｍ２Ｍ）通信を促進する装置であって、
    基盤ネットワークからデバイストリガサービスについてのリクエストを受信する受信モジュール、
    Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを用いて、トリガリングをルーティングすべきリモートエンティティを識別する識別モジュール、
    互いに異なるドメインにおいて事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤと動的Ｍ２Ｍ−Ｅｘｔ−ＩＤの準備動作を実施する準備モジュール、
    を備えることを特徴とする装置。
16. 前記準備モジュールは、
    事前準備Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、インフラドメインのインフラノードにおいて前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備し、
    動的Ｍ２Ｍ−Ｅｘｔ−ＩＤについては、フィールドドメインで共通サービスエンティティ（ＣＳＥ）をホストするＭ２Ｍデバイスにおいて前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤを準備する
    ことを特徴とする請求項１５記載の装置。
17. 前記準備モジュールはさらに、前記インフラノードにおいて前記Ｍ２Ｍ−Ｅｘｔ−ＩＤおよび対応するＣＳＥ−ＩＤを準備する
    ことを特徴とする請求項１６記載の装置。
18. 前記フィールドドメインにおいて準備された前記Ｔｒｉｇｇｅｒ−Ｒｅｃｉｐｉｅｎｔ−ＩＤは、ＩＮ−ＣＳＥへ送信される
    ことを特徴とする請求項１６記載の装置。
19. コードを格納するコンピュータプログラム製品であって、前記コードは請求項１〜５と１１〜１４のいずれか１項記載の方法をプロセッサに実行させる
    ことを特徴とするコンピュータプログラム製品。

Images