JP6367465B2 - Ｍｑｔｔプロトコルを使用するサービス層インターワーキング - Google Patents

Description

ｏｎｅＭ２Ｍサービス層は、共通機能（またはサービス能力）の組として編成され、そのインスタンス化は、共通サービスエンティティ（ＣＳＥ）と称される。図１は、図１に示されるようなＭｃａ、Ｍｃｃ、およびＭｃｎ参照点を介してエクスポージャされる、ｏｎｅＭ２Ｍサービス層の共通機能を図示する略図である。

Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）１０２とＣＳＥ１０４との間の通信フローを指定する一方、Ｍｃｃ参照点は、同一Ｍ２Ｍサービスプロバイダドメイン内のＣＳＥ１０４と１０６との間の通信フローを指定する。ＭｃａおよびＭｃｃを横断する通信は、ペアにされた要求／応答メッセージを介して生じ、各要求は、標的ＣＳＥ上にホストされたリソースに特定のＲＥＳＴｆｕｌ動作（例えば、作成、読み出し、更新、削除）を行う。

Ｍｃｃ’は、異なるＭ２Ｍ ＳＰのインフラストラクチャドメイン内に位置するＣＳＥ間で使用される。Ｍｃｎは、トランスポートおよび接続以外のサービスのために、ＣＳＥ１０４と下層ネットワークサービスエンティティ（ＮＳＥ）１０８との間で使用される。

ｏｎｅＭ２Ｍサービス層では、ＣＳＥは、「ノード」と称されるアーキテクチャエンティティ上にホストされる。ノードは、ａ）１つのＣＳＥおよびゼロ以上のＡＥ、または、ｂ）１つ以上のＡＥを含む、機能エンティティである。

図２は、種々のタイプのノード構成をサポートするｏｎｅＭ２Ｍアーキテクチャの略図である。図２は、簡略化された表現であり、エンティティ間の全ての可能である構成または関係を反映するわけではない。

図３は、ｏｎｅＭ２Ｍ ＣＳＥ ３０２によって行われる共通サービス機能（ＣＳＦ）の初期の組を図示する略図である。特定のＣＳＥ実装は、全ての機能をサポートしない場合があるが、完全実装は、例証における全機能を含むことができる。

ユニフォームリソース識別子共通構文は、５つのコンポーネント（スキーム、オーソリティ、パス、クエリ、およびフラグメント）の階層シーケンスから成る、インターネット構造である。図４は、ｏｎｅＭ２Ｍアドレスにおいて有意である、ユニフォームリソース識別子共通構文のスキーム、オーソリティ、およびパスコンポーネントを図示する略図である。

ｏｎｅＭ２Ｍサービス層内の全てのエンティティは、ＲＯＡアーキテクチャにおいてリソースとして表される。サービス層ノード上のＡＥまたはＣＳＥの各インスタンス化は、固有の識別子を有することが要求される。この固有の識別子は、絶対ユニフォームリソース識別子（ＵＲＩ）を導出するために使用され、絶対ＵＲＩは、そのホストＣＳＥ上のそのエンティティのためのリソース構造のルート（またはベース）アドレスを表す。その構造内の全てのリソースも、階層または非階層方式のいずれかにおいて標的リソースを個別的に識別するパスコンポーネントを有する完全修飾ドメイン名（ＦＱＤＮ）ＵＲＩを介して、固有にアドレス可能でなければならない。ＦＱＤＮは、リソースをホストするＣＳＥを含むノードのネットワークアドレスを提供し、パスは、そのノード上の標的リソースの精密な場所を提供する。

以下の２つの例示的ＵＲＩ値は、同一のリソースをアドレスし、最初に、階層パス構造を用いて、次いで、非階層構造を用いて、前述の原理を図示する。
１） ／／ＣＳＥ０４．Ｍ２ＭＳＰａｂｃ．ｃｏｍ／ＣＳＥＢａｓｅ０１／ａｌｐｈａ／ｃｏｎｔａｉｎｅｒ０２／ｉｎｓｔａｎｃｅ０１
２） ／／ＣＳＥ０４．Ｍ２ＭＳＰａｂｃ．ｃｏｍ／ＣＳＥＢａｓｅ０１／ｒｅｓｏｕｒｃｅ１２３４５６７８
ＵＲＩ＃２の下線部分は、この例示的ＣＳＥのためのベースリソース構造のアドレスを表し、さらに、対応するＣＳＥ識別子を具現化する。ＵＲＩ＃１の下線部分は、「ａｌｐｈａ」と命名されたアプリケーションのためのリソース構造のアドレスを表し、さらに、対応するＡＥ識別子を具現化する。

ＣＳＥまたはＡＥに関連付けられたリソース構造は、ＰｏＡ（ｐｏｉｎｔＯｆＡｃｃｅｓｓ）として知られる属性を含み、ＰｏＡは、ＣＳＥまたはＡＥをホストするノードとの通信を確立するために使用されるルーティング情報（概して、１つ以上のＩＰアドレス）を保持する。ＡＥを標的化するために（例えば、通知を用いて）、最初に、ＡＥが登録されているＣＳＥに到達し、次いで、ＡＥ−ＰｏＡ属性における情報を使用して、要求を標的ＡＥにアドレスすることが必要である。

サービス層要求／応答メッセージは、ＡＰＩを含み、ＡＰＩは、サービス層エンティティ間のメッセージ移動を促進するために、アプリケーションプロトコルを経由して搬送される。サービス層は、それがサービス提供するアプリケーションと下位ネットワーク層との間に位置するため、多くの場合、図５に図示されるように、「ミドルウェア」と称される。

アプリケーションプロトコル層においてバインディングするために、多数の選択肢が存在するが、ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、最初に、ＨＴＴＰおよびＣｏＡＰに合意している。ｏｎｅＭ２Ｍは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）プロトコルバインディングも同様にサポートすることを約束しており、それは、サービス層のＲＥＳＴｆｕｌ要求／応答（１対１）メッセージペアとイベント駆動型パブリッシュ／サブスクライブ（１対多）ＭＱＴＴプロトコルとの間の対比によって興味深いものとなっている選択肢である。これらの差異にもかかわらず、ＭＱＴＴは、その非常に低いプロトコルオーバーヘッドおよび単純な効率的設計に起因して、Ｍ２Ｍアプリケーションのための魅力的な選択肢のままである。

ＭＱＴＴプロトコルは、最初に、ＩＢＭおよびＥｕｒｏｔｅｃｈによって、１９９０年代後半に開発された。それは、正式な採択（プロセスは継続中）およびさらなる開発のために、２０１３年にＯＡＳＩＳ標準化団体に提出された。ＭＱＴＴは、制約のあるデバイスおよび低帯域幅ネットワークのために調整された低オーバーヘッドメッセージ待ち行列およびトランスポートプロトコルであり、それは、最も有名なものとして、Ｆａｃｅｂｏｏｋ Ｍｅｓｓｅｎｇｅｒモバイルアプリにおいて展開されている。

図６は、ＭＱＴＴのパブリッシュ／サブスクライブ（またはクライアント／サーバ）モデルを図示する略図である。ＭＱＴＴのコア要素は、クライアント（パブリッシャ６０２および加入者６０４の両方であり得る）、サーバ（ブローカとも称される）、セッション、サブスクリプション、およびトピックである。

図７は、ＭＱＴＴの要素を図示する略図である。ＨＴＴＰのように、ＭＱＴＴプロトコルは、２つの異なる役割（すなわち、クライアント７０２およびサーバ７０４）を区別するという点において非対称である。

ＭＱＴＴ用語では、クライアント７０２は、ＭＱＴＴを使用するプログラムまたはデバイスである。それは、常時、サーバへのネットワーク接続を確立する。クライアント７０２は、以下を行うことができる：
・他のクライアントが関心を持ち得るアプリケーションメッセージをパブリッシュすること
・それが受信することに関心があるアプリケーションメッセージを要求するためにサブスクライブすること
・アプリケーションメッセージのための要求を除去するためにサブスクリプションを解除すること
・サーバを切断すること
ＭＱＴＴサーバ７０４は、接続をクライアントから受け取る、エンティティである。ＨＴＴＰと異なり、概して、任意のアプリケーション論理を起動せず、代わりに、ＭＱＴＴサーバ７０４は、アプリケーションメッセージをパブリッシュするクライアントと、それらをサブスクライブし、受信する、クライアントとの間の中間体としてアクションする。

トピックは、ＭＱＴＴ内の「Ｑ」であり、それは、メッセージ待ち行列と命名され、パブリッシャを加入者とリンクするために、サーバによって維持される。ＭＱＴＴクライアント７０２は、ＰＵＢＬＩＳＨメッセージ（すなわち、供給されたトピック名にサブスクライブされた任意のクライアントに不透明メッセージペイロードを配信するための命令）をＭＱＴＴサーバ７０４に発行する場合、パブリッシャの役割を担い、ＳＵＢＳＣＲＩＢＥメッセージ（すなわち、供給されたトピックフィルタに一致する任意のＰＵＢＬＩＳＨメッセージを受信するための命令）をＭＱＴＴサーバ７０４に発行する場合、加入者の役割を担う。トピックフィルタは、１つ以上のトピックへの関心を示すためにサブスクリプション内に含まれる表現である。トピックフィルタは、ワイルドカード文字を含み得る。ＰＵＢＬＩＳＨメッセージは、３つのＱｏＳ保証レベル（最高１回、少なくとも１回、正確に１回）のうちの１つを用いて配信される。

図８は、ＭＱＴＴにおけるクライアントとサーバとの間のアタッチメントの２つのレベルを表す、セッションおよびサブスクリプションを図示する略図である。セッション８０１および８０２は、クライアントとサーバとの間のステートフル相互作用（すなわち、アクティブＴＣＰ／ＩＰネットワーク接続）であり、固有のクライアント識別子によって識別される。セッション８０１および８０２は、クライアントがＣＯＮＮＥＣＴメッセージをサーバに送信することによってのみ確立されることができる。ＣＯＮＮＥＣＴ、ＰＵＢＬＩＳＨ、およびＳＵＢＳＣＲＩＢＥメッセージ内のフラグは、セッションが切断される場合、セッション状態が維持される方法を決定する。

サブスクリプション８０４および８０６は、サーバによって維持される１つ以上のトピック（すなわち、メッセージ待ち行列）へのクライアントの論理的なアタッチメントである。サブスクリプション８０６は、単一セッション８０１のみに関連付けられているが、セッションの切断の場合、保存され、後続セッションが同一クライアントによって確立されると、記憶されたサブスクライブされたメッセージの配信をトリガするようにセッション状態を構成することも可能である。したがって、サブスクリプションは、「一時的」（サブスクリプション８０６）または「持続的」（サブスクリプション８０４）であり得る。

最高ＱｏＳレベルで動作する持続的サブスクリプション８０４は、サーバが関連付けられたクライアントのためにストアアンドフォワードモードで動作する結果をもたらす（サーバ上の利用可能な記憶容量の限界内で）一方、最低ＱｏＳレベルとペアにされる一時的サブスクリプション８０６は、サーバが関連付けられたクライアントのためにパススルーモードで動作する結果をもたらす。

ＭＱＴＴネットワーク接続は、クライアント７０２とサーバ７０４との間のみに存在する。ＭＱＴＴクライアント７０２の観点から、全ての着信アプリケーションメッセージは、サーバ７０４から発信され、サーバ７０４とのサブスクリプションから生じるアプリケーションメッセージを受信するＭＱＴＴクライアント７０２は、ネットワーク層（例えば、ＩＰ）においてそのメッセージを発信したクライアントに到達することさえできないこともあり得る。この点から、サーバ７０４が、アプリケーションメッセージを転送するべきかどうかを決定する（トピック名をサブスクリプションのそのリストに対して照合する（すなわち、トピックフィルタ））機構は、トピック名フィールドをネットワークアドレスの形態のように取り扱う。

但し、サーバ７０４は、サブスクリプションを直接ネットワーク接続（例えば、ＩＰアドレス）に関連付けないので、考えるべき中間ステップがある。サブスクリプションが、セッションに関連付けられ、セッションが、サーバに接続する全てのクライアントに対して固有でなければならないクライアント識別子（クライアントＩＤ）に関連付けられる。クライアントＩＤは、最大６５，５３５バイトのＵＴＦ−８エンコードストリングである。しかしながら、サーバは、長さを２３ＵＴＦ−８エンコードバイト以下に制限し得る。クライアントＩＤ機構はセッション状態の保存を可能にし、ストアアンドフォワード能力を有効にする（所望に応じて）。

したがって、ＭＱＴＴアドレス関連付けの組は、以下のようになる。

「／」は、トピック名を階層レベルに分割するために使用されるトピックレベルセパレータである。「＃」は、続く任意のレベルにおいて一致するマルチレベルワイルドカード文字である。さらに、１つのみのレベルにおいて一致する単一レベルワイルドカード文字「＋」も存在する（図示せず）。

この例では、Ａｃｍｅ Ａｌａｒｍ Ｃｏ．が、ＭＱＴＴサーバに接続し、「Ａｃｍｅ−Ａｌａｒｍ−ｘｙｚ」のそのクライアントＩＤ値を使用して、セッションを確立している。その所在地住所（１２３４ Ｅｌｍ Ｓｔ．，Ａｎｙｔｏｗｎ）に一致する任意のものに対応するトピック名を伴うアプリケーションメッセージをサブスクライブしている。Ａｃｍｅ Ａｌａｒｍは、センサおよびネットワークコントローラをこの場所にインストールし、コントローラは、トピック名「／Ａｎｙｔｏｗｎ／ＥｌｍＳｔ．／１２３４／＜ｓｅｎｓｏｒＸ＞／＜ｉｎｆｏ＞」を用いてアプリケーションメッセージをパブリッシュしている。サーバは、着信アプリケーションメッセージをＡｃｍｅに属するこのサブスクリプションと比較し、トピック一致を伴う任意のメッセージを対応するネットワーク接続アドレスに転送する。

ＭＱＴＴ Ｖ３．１．１仕様書は、以下の宣言を含む。
「単一エンティティが、ＭＱＴＴクライアントおよびＭＱＴＴサーバ実装の両方として適合し得る。例えば、インバウンド接続を受け入れ、他のサーバへのアウトバンド接続を確立するサーバは、ＭＱＴＴクライアントおよびＭＱＴＴサーバの両方として適合しなければならない」。

ＭＱＴＴ仕様書（上記）からの適合性宣言は、確保されたプロトコルフィールドを利用する実装に対処する（概して、サーバ−サーバ接続をクライアント−サーバ接続から区別するために必要とされる）。しかしながら、以下のように、サーバ−サーバ接続を区別することを必要とせず、かつ仕様書に違反することなく、ＭＱＴＴサーバを相互接続することが可能である。

サーバのうちの１つのみがこのように構成される場合、それらの間には、内蔵されたクライアント機能性を有するサーバに向かう一方向のトラフィックフローのみが存在し得る。これは、図９に示されるように、それが他のサーバにサブスクライブし、トラフィックをそれ自身に向けて操縦することを可能にする。

図９は、ＭＱＴＴサーバ間のメッセージの一方向フローを図示する略図である。図９では、「Ｓ１／Ｃ１」として識別されたＭＱＴＴクライアント９０２は、ＳＵＢＳＣＲＩＢＥメッセージをサーバＳ１に事前に送信しており、サーバＳ１に、トピックフィルタ「Ｓ１／Ｃ１／＃」を有するトピック待ち行列を確立させている。続いて、最初の５文字が「Ｓ１／Ｃ１」に等しいトピック名フィールドを伴う、サーバＳ１に到着した任意のパブリッシュメッセージは、クライアントＳ１／Ｃ１ ９０２に転送されるであろう。

独立型クライアントに示される「パブリッシュ」および「サブスクライブ」機能は、フローに示されるメッセージをハンドリングするときにクライアントが有する役割（パブリッシャまたは加入者）を示す。

サーバＳ１における内蔵されたクライアント機能９０４によってサーバＳ２に送信されるＳＵＢＳＣＲＩＢＥメッセージは、サーバＳ２に、トピックフィルタ「Ｓ１／＃」を有するトピック待ち行列を確立させる。これは、２つのサーバ間に（一方向）接続を形成するアクションである。続いて、最初の２文字「Ｓ１」に等しいトピック名フィールドを伴う、サーバＳ２に到着する任意のＰＵＢＬＩＳＨメッセージは、サーバＳ１に転送されるであろう。このように、サーバＳ１に接続されるクライアントは、サーバＳ１またはサーバＳ２のいずれか（またはサーバＳ１が接続を確立する任意の他のサーバ）に接続されるクライアントによって到達されることができる。

接続は、サーバＳ１内のクライアント９０２がＤＩＳＣＯＮＮＥＣＴメッセージをサーバＳ２に送信することによって、随時、分断されることができる。対応するＣＯＮＮＥＣＴメッセージ（ＳＵＢＳＣＲＩＢＥに先立って）は、示されないが、仮定されている。サーバＳ２は、サーバＳ１内のクライアント９０２からの接続が別のサーバに関連付けられる、インジケーションを有していないことに留意されたい。サーバＳ１は、サーバＳ２に対して任意の他のクライアントのように見える（プロトコルレベルにおいて）。

図１０は、ＭＱＴＴサーバといずれかのサーバに接続されるクライアントとの間の双方向トラフィックフローを図示する略図である。この場合、両クライアントＳ１／Ｃ１およびＳ２／Ｃ１は、ＳＵＢＳＣＲＩＢＥメッセージをそれらのそれぞれのサーバに事前に送信し、それらのサーバに、示されるトピックフィルタを有するトピック待ち行列を確立させている。各サーバ内に内蔵されたクライアント機能によって送信されるＳＵＢＳＣＲＩＢＥメッセージは、受信サーバに、発信側サーバ＋クライアント組み合わせに指し示すトピックフィルタを有するトピック待ち行列を確立させる。一緒に、このペアのアクションは、２つのサーバ間に双方向接続を形成し、一方のサーバに接続されるクライアントは、他方のサーバに接続されるクライアントに到達することができ、逆も同様である。要求／応答メッセージングが、したがって、異なるサーバに接続されるクライアント間で可能にされる。

サーバ間で送信されるＳＵＢＳＣＲＩＢＥメッセージが互いに独立する（すなわち、プロトコルレベルにおいて他方をトリガしない）ことに留意することは、重要である。ＳＵＢＳＣＲＩＢＥメッセージを受信するサーバは、メッセージが純粋なクライアントではなくクライアント対応サーバに関連付けられているということをプロトコルにおいて信号伝達される方法を有しない（少なくとも、実装が標準準拠のままである場合）。このシナリオにおける最も単純なアプローチは、システム初期化の一部としてサーバ間の静的接続を確立することであり、各サーバは、起動時にその接続を確立するために必要とされる情報で事前に構成されることができるであろう。

代替として、独立型サーバ実装内に内蔵された論理が、ＳＵＢＳＣＲＩＢＥメッセージのトピックフィルタフィールド内の特定のパターンをサーバ発信メッセージのためのマーカとして取り扱い、そのマーカを戻り方向のコンパニオンＳＵＢＳＣＲＩＢＥメッセージを開始するための信号として使用し得る。統合されたサーバ機能性を伴う上位層論理も、必要に応じて、接続を動的にトリガおよび開始し得る。

管理対象の階層（またはＵＲＩ様）構造がトピック名空間内で管理され、トピック名フィールドにデータ投入するために使用される値／アドレスの大域的な唯一性が維持される限り、協働するサーバに接続されるクライアント間の継続的双方向通信は、可能である。

ｏｎｅＭ２Ｍは、ＭＱＴＴプロトコルバインディングのための技術仕様書を開発している。いくつかの構成代替が、ｏｎｅＭ２Ｍアーキテクチャ内のＭＱＴＴサーバの設置に関して技術仕様書に示されるが、これらの構成は全て、ＭＱＴＴサーバが、ＭＱＴＴクライアントとのみ通信し、ｏｎｅＭ２Ｍサービス層内の他のＭＱＴＴサーバとは通信しない、機能的および論理的に別個のエンティティであるという特性を共有する。

図１１は、全てのＡＥ１１０４、ＣＳＥ１１０６および１１０８への接続を維持するサービスプロバイダドメイン内の単一のＭＱＴＴサーバ１１０２を図示する略図である。これは、最も簡単な構成である。

図１２Ａおよび１２Ｂは、ｏｎｅＭ２Ｍ実施形態における複数のＭＱＴＴサーバの使用を図示する。インフラストラクチャドメイン内の単一のモノリシックＭＱＴＴサーバの代替は、複数のＭＱＴＴサーバを中間ノードに展開し、ネットワークエッジのより近くで（Ｍｃａ参照点のみを経由して）ＭＱＴＴをサポートすることである。別の代替は、Ｍｃａトラフィックをフィールドドメイン内で搬送する１つ（またはおそらくそれを上回る）ＭＱＴＴネットワークと、インフラストラクチャドメインに戻るＭｃｃトラフィックを搬送する別個のＭＱＴＴネットワークとを有することであろう。このシナリオでは、独立したＭＱＴＴネットワーク間のインターワーキングは、ｏｎｅＭ２Ｍサービス層によって行われるであろう。

図１３は、ＭＱＴＴサーバ１３０２を伴うｏｎｅＭ２Ｍ実施形態を図示する。単一ＭＱＴＴサーバ（図１１）の概念をｏｎｅＭ２Ｍアーキテクチャ構成（図２）に適用することによって、図１３における例証が生じる。任意の２つのサービス層エンティティ間のトラフィックは、ＭＱＴＴサーバ１３０２を通してフローしなければならず、任意の２つのサービス層エンティティ間の通信は、両方がそのＭＱＴＴサーバ１３０２に接続されない限り（またはサービス層がトラフィックをＭＱＴＴ接続エンティティから非ＭＱＴＴ接続エンティティにパスするための追加の論理を提供しない限り）、可能ではない。

図１３に示される構成は、現在の開発研究の焦点である。ＭＱＴＴサーバを追加し、サービス層エンティティをそれらの間に再分配する（例えば、図１２に提案されるように、ＭＱＴＴサーバをフィールドドメイン内に設置する）ことが可能であるが、特定のＭＱＴＴクライアントが接続するＭＱＴＴサーバの任意の変更は、新しいサーバのネットワークアドレスをそのクライアントに事前に提供することを要求するであろう。これは、クライアントがサーバを発見するための機構をＭＱＴＴが欠いているが、クライアントが、常に、サーバへの接続を開始するからである（したがって、ネットワークアドレスは、ネットワーク接続が行われることが可能な前に、クライアントに利用可能でなければならない）。

ＭＱＴＴサーバ機能性をｏｎｅＭ２ＭＣＳＥに統合し、かつそのようなＣＳＥＢａｓｅのＭＱＴＴサーバをリソースアドレスに基づいてトピック構造の周囲に編成されたネットワークに相互接続する方法が、説明される。これは、前述の識別子割り当てとネットワーク集中化およびオーバーヘッド問題との両方に対処する。

方法は、ＡＥ、ＣＳＥ、およびＭＱＴＴサーバによってＡＥ−ＩＤとして使用され得る識別子を動的に配分、割り当て、および配信することができる。これは、アプリケーション登録プロセスの一部として、ＣＳＥの制御下で行われる。

ＭＱＴＴサーバは、ＭＱＴＴサーバがＣＳＥをホストする全てのサービス層ノード内で利用可能になるように、Ｍ２Ｍサービス層にインターワーキングされることができる。ＭＱＴＴサーバ（本開示では、「ＭＱＴＴサーバ＋」と称される）は、クライアント機能性を内蔵し、階層アプリケーション層アドレススキームを適用することによって拡張され、したがって、ＭＱＴＴサーバ機能性を全てのＣＳＥにおいて展開可能にする。

ＭＱＴＴサーバ／サーバ接続は、動的に確立され、サービス層エンティティ間のトラフィックを促進することができる。全てのＣＳＥが、リソースアドレスに基づいて相互接続されたネットワーク内でＭＱＴＴサーバおよびクライアントの両方としての役割を果たすことによって、サービス層プリミティブは、中間サービス層論理によって再びハンドリングされずに、発信側から標的に直接配信されることができる。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサおよびメモリを備えているノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに備え、前記命令は、前記ノードの前記プロセッサによって実行されると、
アプリケーションからパブリッシュ要求を受信することであって、前記要求は、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用している、ことと、
前記所定のトピックフィルタパラメータに応答して、レジストラ共通サービスエンティティ（ＣＳＥ）に対してメッセージをパブリッシュすることであって、前記メッセージは、一時的クライアント識別子（ＩＤ）を含む、ことと、
前記レジストラＣＳＥから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
前記割り当てられたアプリケーション名を前記アプリケーションに提供することと、
前記アプリケーションから、前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を受信することと
を前記ノードに行わせる、ノード。
（項目２）
前記一時的クライアント識別子は、ヌル識別子である、項目１に記載のノード。
（項目３）
前記ノードは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装する、項目１に記載のノード。
（項目４）
前記ＭＱＴＴサーバは、クライアント機能性を含む、項目３に記載のノード。
（項目５）
プロセッサおよびメモリを備えているノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、
アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用しているパブリッシュ要求をメッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバに送信することと、
前記ＭＱＴＴサーバから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を前記ＭＱＴＴサーバに送信することと
を前記ノードに行わせ、
ＭＱＴＴサーバは、クライアント機能性を含むＭＱＴＴサーバ＋である、ノード。
（項目６）
プロセッサおよびメモリを備えているノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、
アプリケーションから、中間ノードおよび前記アプリケーションを示すトピックフィルタを伴うサブスクライブ要求を受信することと、
インフラストラクチャノードにおけるＭＱＴＴサーバに、前記インフラストラクチャノードを示すトピックフィルタをともなうトピックに対するサブスクライブ要求を送信することと、
インフラストラクチャノードにおける前記ＭＱＴＴサーバから、前記インフラストラクチャノードを示すトピックフィルタを伴うトピックに対するサブスクライブ要求を受信することと
を前記ノードに行わせ、
メッセージは、前記中間ノードおよびインフラストラクチャノードに作成されたトピックを使用して、前記アプリケーションと前記インフラストラクチャノードとの間で前記中間ノードを通して転送される、ノード。
（項目７）
前記ノードは、中間ノードである、項目６に記載のノード。
（項目８）
前記ノードは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装する、項目６に記載のノード。
（項目９）
前記ＭＱＴＴサーバは、クライアント機能性を含む、項目８に記載のノード。
（項目１０）
ノードによる使用のための方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
アプリケーションからパブリッシュ要求を受信することであって、前記要求は、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用している、ことと、
前記所定のトピックフィルタパラメータに応答して、レジストラ共通サービスエンティティ（ＣＳＥ）に対してメッセージをパブリッシュすることであって、前記メッセージは、一時的クライアント識別子（ＩＤ）を含む、ことと、
前記レジストラＣＳＥから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
前記割り当てられたアプリケーション名を前記アプリケーションに提供することと、
前記アプリケーションから、前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を受信することと
を含む方法の機能を行う、方法。
（項目１１）
前記一時的クライアント識別子は、ヌル識別子である、項目１０に記載の方法。
（項目１２）
前記ノードは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装する、項目１０に記載の方法。
（項目１３）
前記ＭＱＴＴサーバは、クライアント機能性を含む、項目１２に記載の方法。
（項目１４）
ノードによる使用のための方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用しているパブリッシュ要求をメッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバに送信することと、
前記ＭＱＴＴサーバから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を前記ＭＱＴＴサーバに送信することと
を含む方法の機能を行う、方法。
（項目１５）
前記ノードは、アプリケーションを実装する、項目１０に記載の方法。
（項目１６）
前記ＭＱＴＴサーバは、クライアント機能性を含む、項目１２に記載の方法。
（項目１７）
ノードによる使用のための方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
アプリケーションから、中間ノードおよび前記アプリケーションを示すトピックフィルタを伴うサブスクライブ要求を受信することと、
インフラストラクチャノードにおけるＭＱＴＴサーバに、前記インフラストラクチャノードを示すトピックフィルタをともなうトピックに対するサブスクライブ要求を送信することと、
インフラストラクチャノードにおける前記ＭＱＴＴサーバから、前記インフラストラクチャノードを示すトピックフィルタを伴うトピックに対するサブスクライブ要求を受信することと
を含む方法の機能を行い、
メッセージは、前記中間ノードおよびインフラストラクチャノードに作成されたトピックを使用して、前記アプリケーションと前記インフラストラクチャノードとの間で前記中間ノードを通して転送される、方法。
（項目１８）
前記ノードは、中間ノードである、項目１７に記載の方法。
（項目１９）
前記ノードは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装する、項目１７に記載の方法。
（項目２０）
前記ＭＱＴＴサーバは、クライアント機能性を含む、項目１９に記載の方法。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。

図１は、ｏｎｅＭ２Ｍサービス層の共通機能を図示する略図である。 図２は、種々のタイプのノード構成をサポートする、ｏｎｅＭ２Ｍアーキテクチャの略図である。 図３は、ｏｎｅＭ２ＭＣＳＥによって行われる共通サービス機能（ＣＳＦ）の初期の組を図示する略図である。 図４は、ｏｎｅＭ２Ｍアドレスにおいて重要なユニフォームリソース識別子共通構文のスキーム、オーソリティ、およびパスコンポーネントを図示する略図である。 図５は、例示的サービス層プロトコルスタックを図示する略図である。 図６は、ＭＱＴＴのパブリッシュ／サブスクライブ（またはクライアント／サーバ）モデルを図示する略図である 図７は、ＭＱＴＴのコア要素を図示する略図である。 図８は、ＭＱＴＴにおけるクライアントとサーバとの間のアタッチメントの２つのレベルを表す、セッションおよびサブスクリプションを図示する略図である。 図９は、ＭＱＴＴサーバ間のメッセージの一方向フローを図示する略図である。 図１０は、ＭＱＴＴサーバといずれかのサーバに接続されるクライアントとの間の双方向トラフィックフローを図示する略図である。 図１１は、全てのＡＥおよびＣＳＥへの接続を維持する、サービスプロバイダドメイン内の単一ＭＱＴＴサーバを図示する略図である。 図１２Ａおよび１２Ｂは、ｏｎｅＭ２Ｍ実施形態における複数のＭＱＴＴサーバの使用を図示する。 図１３は、ＭＱＴＴサーバを伴うｏｎｅＭ２Ｍ実施形態を図示する。 図１４は、ｏｎｅＭ２Ｍのための例示的ＭＱＴＴメッセージフローを示す、略図である。 図１５は、インフラストラクチャドメイン内に位置する単一標準的ＭＱＴＴサーバを伴う、例示的メッセージフローを図示する略図である。 図１６は、３つのトピックフィルタの使用を図示する略図である。 図１７は、ＭＱＴＴを伴う、ｏｎｅＭ２Ｍ実施形態を図示する略図である。 図１８は、サービス層作成動作の実施例を図示するフロー図である。 図１８は、サービス層作成動作の実施例を図示するフロー図である。 図１８は、サービス層作成動作の実施例を図示するフロー図である。 図１９は、サービス層読み出し動作の実施例を図示するフロー図である。 図１９は、サービス層読み出し動作の実施例を図示するフロー図である。 図１９は、サービス層読み出し動作の実施例を図示するフロー図である。 図２０は、拡張ｏｎｅＭ２Ｍ ＲＯＡ実施形態におけるＭＱＴＴ ＣＳＦを図示する略図である。 図２１は、一実施形態のグラフィカルユーザインターフェースの略図である。 図２２Ａは、例示的システムおよび方法の１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの略図である。 図２２Ｂは、フィールドドメインおよびインフラストラクチャドメインを伴う、Ｍ２Ｍサービス層の略図である。 図２２Ｃは、ＵＥまたは別のエンドノードデバイス等の例示的デバイスの略図である。 図２２Ｄは、ノードまたは論理エンティティを実装するために使用され得る、コンピュータシステムまたはサーバの略図である。

図１４は、ｏｎｅＭ２Ｍのための例示的ＭＱＴＴメッセージフローを示す、略図である。図１４に示されるＭＱＴＴのためのメッセージフローは、実行可能であるが、そのＭＱＴＴサブスクリプションを確立する目的のために、固有のトピックフィルタ値を関連付けられたＭＱＴＴクライアント１４０６および１４０８に提供するサービス層エンティティ（ＡＥ１４０２またはＣＳＥ１４０４）に依拠する。この「自己サブスクリプション」は、応答（および通知）トラフィックをサブスクライブ側エンティティに戻るように向かわせる。図１４では、ＭＱＴＴ接続およびサブスクリプションステップは、成功したと仮定され、ＡＥ１４０２およびＣＳＥ１４０４は、それらのそれぞれのサービス層ＩＤをＭＱＴＴサーバ１４１４の内側に示されるトピック待ち行列のためのトピックフィルタ値として使用していることに留意されたい。この目的のために、ＡＥ−ＩＤおよびＣＳＥ−ＩＤ以外の値を使用することも可能であり得るが、これらのＩＤは、エンティティをすでに固有に識別しており、サービス層ＡＰＩ内で搬送されており、かつＭＱＴＴトピック名構造と良好に関連するという利点を有する。

しかしながら、ｏｎｅＭ２Ｍ ＡＥに関する特定の問題が存在する。ＡＥ１４０２は（その関連付けられたＭＱＴＴクライアントを通して）、初期サービス層登録に先立って、送信される第１のＳＵＢＳＣＲＩＢＥメッセージのトピックフィルタフィールドにおいて固有の識別子をＭＱＴＴサーバ１４１４にパスすることが可能でなければならない。これは、サーバに、ＡＥに向かって戻る応答メッセージをルーティングするための固有のトピックを提供する。ＡＥ−ＩＤは、ここでは使用されることができない。なぜなら、ＡＥ−ＩＤは、ＡＥが登録するまでレジストラＣＳＥによって割り当てられておらず、そもそも、登録要求に対する応答がＡＥ−ＩＤ値をＡＥに返送するものだからである。全体として、ＭＱＴＴトピック名の動的プロビジョニングに利用可能な汎用機構は存在せず、まして、ｏｎｅＭ２Ｍ識別子（例えば、ＡＥ ＩＤ、ＣＳＥ ＩＤ）と整合されるものはない。

第２のより一般的問題は、サーバ周囲のＭＱＴＴネットワークの固有の集中化にある。図１４に図示されるように、ＭＱＴＴクライアントは、直接、互いに通信することができず、それらの間の通信をブローカするためのサーバに依拠しなければならない。しかし、本来のＭＱＴＴプロトコルは、ＭＱＴＴサーバ間の通信をサポートしない。すなわち、サーバＸに接続されるＭＱＴＴクライアントはメッセージをサーバＹに接続されるＭＱＴＴクライアントと交換することができない。したがって、２つ以上のＭＱＴＴサーバが、Ｍ２Ｍ ＳＰドメイン内に存在することになる場合（例えば、ネットワーク拡張の結果として）、ＭＱＴＴサーバ間のインターワーキングは、サービス層レベルで管理されるか（追加のオーバーヘッドを伴う）、または回避されるかのいずれでなければならない。

図１４に図示される機能性は、以下に説明される図２２Ｃまたは２２Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

図１５は、インフラストラクチャドメイン内に位置する単一の標準的ＭＱＴＴサーバを伴う、例示的メッセージフローを図示する略図である。このフローは、ｏｎｅＭ２Ｍシステムが、ＭｃａおよびＭｃｃ参照点の両方に適用されるようなｏｎｅＭ２Ｍ ＴＳ−００１０に規定されたＭＱＴＴプロトコルバインディング（完成すると）に従うことによって動作するであろう方法を表す。それは、以下に説明される図１９の動作ステップにおいて行われる同一サービスレベル動作と比較したこのアプローチの非効率性を図示する。

以下のステップは、図１３に示される構成と整合した単一のＭＱＴＴサーバへの全ＭＱＴＴクライアントの接続およびサブスクリプション（対応するＡＥ−ＩＤまたはＣＳＥ−ＩＤに基づく）を前提とする。

図１５のステップ１では、ＡＤＮ−ＡＥ（「発信側ＡＥ」）１５０２は、サービス層読み出し要求プリミティブをＡＤＮ ＭＱＴＴクライアント１５０４に送信する。プリミティブの「ｔｏ」パラメータは、＜ＩＮＣＳＥＢａｓｅ＞下に位置するリソースのためのＵＲＩである。「ｆｒｏｍ」パラメータは、ＡＥ−ＩＤである。

図１５のステップ２では、ＡＤＮ ＭＱＴＴクライアント１５０４は、ＰＵＢＬＩＳＨメッセージを（グローバル）ＭＱＴＴサーバ１５０６に発行する。トピック名ストリングは、レジストラＣＳＥ−ＩＤ（ＡＥが登録したＭＮ−ＣＳＥ）に設定される。

図１５のステップ３では、ＭＱＴＴサーバは、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、ＭＮ−ＣＳＥ−ＩＤに対する一致を見つける。ＭＱＴＴサーバ１５０６は、ＰＵＢＬＩＳＨメッセージを対応するＭＱＴＴクライアント１５０４に転送する。

図１５のステップ４では、ＭＮ ＭＱＴＴクライアント１５０４は、受信されたペイロード（すなわち、読み出し要求プリミティブ）をＭＮ−ＣＳＥ１５０８（レジストラＣＳＥ）に配信する。

図１５のステップ５では、ＭＮ−ＣＳＥ１５０８は、読み出し要求の「ｔｏ」パラメータを調べ、プリミティブが異なるＣＳＥにアドレスされていることを決定する。

図１５のステップ６では、ＭＮ−ＣＳＥ１５０８は、「ｆｒｏｍ」パラメータをそれ自身のＣＳＥ−ＩＤに更新し、更新されたプリミティブをＭＮ ＭＱＴＴクライアント１５１０に転送する。

図１５のステップ７では、ＭＮ ＭＱＴＴクライアント１５１０は、ＰＵＢＬＩＳＨメッセージをＭＱＴＴサーバ１５０６に発行する。トピック名ストリングは、標的ＣＳＥ−ＩＤ１５１２（リソースが位置するＩＮ−ＣＳＥ）に設定される。

図１５のステップ８では、ＭＱＴＴサーバ１５０６は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、ＩＮ−ＣＳＥ−ＩＤに対する一致を見つける。ＭＱＴＴサーバ１５０６は、ＰＵＢＬＩＳＨメッセージを対応するＭＱＴＴクライアントに転送する。

図１５のステップ９では、ＩＮ ＭＱＴＴクライアントは、受信されたペイロード（すなわち、読み出し要求プリミティブ）をＩＮ−ＣＳＥ１５１２（標的ＣＳＥ）に配信する。

図１５のステップ１０では、規定されたリソースコンテンツが、読み出される（発信側ＡＥ１５０２がアクセス権を有する場合）。

図１５のステップ１１では、ＩＮ−ＣＳＥ１５１２は、読み出し応答プリミティブをＩＮ ＭＱＴＴクライアント１５１４に送信し、動作の成功または失敗を示す。発信プリミティブの「ｔｏ」パラメータは、受信された「ｆｒｏｍ」パラメータ（ＭＮ−ＣＳＥ−ＩＤ）に設定される。「ｃｎ」パラメータは、適切なコンテンツに設定される。すなわち、成功の場合（示される）、読み出されるリソースの要求されるコンテンツに設定される。

図１５のステップ１２では、ＩＮ ＭＱＴＴクライアント１５１４は、ＰＵＢＬＩＳＨメッセージをＭＱＴＴサーバに発行する。トピック名ストリングは、受信側ＣＳＥ−ＩＤ（「ｆｒｏｍ」パラメータ内で識別されたＭＮ−ＣＳＥ１５０８）に設定される。

図１５のステップ１５では、ＭＱＴＴサーバ１５０６は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、ＭＮ−ＣＳＥ−ＩＤに対する一致を見つける。ＭＱＴＴサーバ１５０６は、ＰＵＢＬＩＳＨメッセージを対応するＭＱＴＴクライアントに転送する。

図１５のステップ１４では、ＭＮ ＭＱＴＴクライアント１５１０は、受信されたペイロード（すなわち、読み出し応答プリミティブ）をＭＮ−ＣＳＥ１５０８に配信する。

図１５のステップ１５では、ＭＮ−ＣＳＥ１５０８は、読み出し応答を調べ、それを対応する読み出し要求に関連させる。

図１５のステップ１６では、ＭＮ−ＣＳＥ１５０８は、「ｔｏ」パラメータを発信側ＡＥ−ＩＤに更新し、更新された読み出し応答プリミティブをＭＮ ＭＱＴＴクライアント１５１０に転送する。

図１５のステップ１７では、ＭＮ ＭＱＴＴクライアント１５１０は、ＰＵＢＬＩＳＨメッセージをＭＱＴＴサーバ１５０６に発行する。トピック名ストリングは、発信側ＡＥ−ＩＤ（要求を発信した）に設定される。

図１５のステップ１８では、ＭＱＴＴサーバ１５０６は、受信されたトピック名ストリングをそのサブスクリプションリストと比較し、ＡＥ−ＩＤに対する一致を見つける。ＭＱＴＴサーバ１５０６は、ＰＵＢＬＩＳＨメッセージを対応するＭＱＴＴクライアントに転送する。

図１５のステップ１９では、ＡＤＮ ＭＱＴＴクライアント１５０４は、受信されたペイロード（すなわち、読み出し応答プリミティブ）をＡＥ１５０２に配信する。

ＭＱＴＴ Ｖ３．１．１仕様書［２］は、以下の宣言を含む。

サーバ実装は、他の目的のために、前置＄文字から始まるトピック名を使用し得る。
「＄ＳＹＳ／は、サーバ特定の情報または制御ＡＰＩを含むトピックに対するプリフィックスとして広く採用されている」。

ＭＱＴＴのこの特性は、本明細書では、ＡＥ登録プロシージャを行うのに先立ってＡＥ−ＩＤ値をＡＥに割り当てる目的のために、ｏｎｅＭ２Ｍ実施形態に特有のトピック空間を作成するために利用される。特に、トピック名ストリング「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ ＩＤ／」は、ＭＱＴＴサーバ＋実装によって、ヌルクライアント識別子（ＣｌｉｅｎｔＩｄ）を使用してＭＱＴＴサーバ＋への接続を試みるＭＱＴＴクライアントを識別するためのフラグとして使用される。このフラグは、接続するエンティティへのＡＥ ＩＤ値の事前割り当てをもたらす、図１８に概略される一連のアクションをトリガする。そして、このＡＥ ＩＤ値は、接続するエンティティによって、そのサーバ＋に関連付けられたＣＳＥからの応答を受信する目的のために、ＭＱＴＴサーバ＋とのサブスクリプションを確立するために使用される。この機構のさらなる詳細は、以下に提供される。

図１５に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１５に図示される方法は、図２２Ｃまたは図２２Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１５に図示されるステップを行う。図１５に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図１６は、３つのトピックフィルタの使用を図示する略図である。ＭＱＴＴワイルドカード文字は、要求を送信するエンティティが、そのリソースアドレスに基づくサブスクリプションの組を介して、応答トラフィックを受信することを可能にするために利用される。図１６における３つのトピックフィルタストリングは、ＣＳＥＢａｓｅ下の第１のレベルに後置スラッシュを伴うトピック名ストリングを除き、ＭＮ−ＣＳＥ−ＩＤを含むトピック名を伴う全メッセージがＭＮ上のＭＱＴＴクライアントに転送されることをもたらす。したがって、ＡＥは、ＣＳＥに登録され、「／」が付加されたそのＡＥ識別子（ＡＥ−ＩＤ）に対応するＵＲＩにおいて着信メッセージを受信することができる（そのＣＳＥＢａｓｅの周囲に形成されるトピック名を伴う全ての他のメッセージは、ＣＳＥ自体にルーティングされるであろう）。このように、ＡＥリソース上のＣＲＵＤ動作は、アクションのためにＣＳＥに配信されるであろうが、依然として、メッセージがＡＥ自体に到達するためのパスが存在する。

ＭＱＴＴストリングは、大文字・小文字を区別するが、ＲＦＣ ３９６８ ＵＲＩのスキームおよびホストコンポーネントは、大文字・小文字を区別しない。したがって、大文字・小文字を区別するＭＱＴＴトピック名およびトピックフィルタストリングが、ルーティング目的のために使用されるＵＲＩ値（例えば、ホストコンポーネント）と適切に関連することを確実にするために配慮されなければならない。

ｏｎｅＭ２Ｍ機能アーキテクチャは、ＣＳＥの各発生とともに生じるＭＱＴＴサーバ＋機能エンティティの存在を反映するように更新される。そのような実施形態は、以下に説明される双方向インターワーキング能力を利用して、図に示されるように、協働サーバ間のトラフィックフローを有効にするであろう。図１３は、ｏｎｅＭ２Ｍにおける現在のアプローチを表す、ＭＱＴＴサーバの設置に関する代替図を示す。

次の２つの図は、ＡＤＮ−ＡＥ１８０２、ＭＮ−ＣＳＥ１８０４、およびＩＮ−ＣＳＥ１８０６を伴い、ＣＳＥ１８０４および１８０６がＭＱＴＴサーバ＋機能性で拡張されているサンプル通信フローを図示する。サービス層作成および読み出し動作のみが示されるが、本明細書に図示される方法は、ＣＲＵＤ−ＳＮ動作、すなわち、作成、読み出し、更新、削除、サブスクライブ、および通知の全体に等しくて適用される。これらの動作（または「プリミティブ」）は、ＭＱＴＴ ＰＵＢＬＩＳＨメッセージのペイロードパラメータ内で全体的に搬送される。これは、図の「動作」部分に示される。

図１８は、サービス層作成動作の例を図示するフロー図である。

（図１８の前提条件調整ステップ）
これらのステップは、システム初期化の一部として、またはノード間のネットワーク接続が（再）確立されなければならないときは常に行われる。ＱｏＳレベルが、図１８に示されるが、例証の目的のために、レベル０に設定される。実際は、説明される技法は、使用されるＱｏＳレベルから独立している。図１８の前提条件調整ステップ１では、ＭＮ−ＣＳＥ１８０４は、中間ノード（ＭＮ）１８１０上のＭＱＴＴクライアント１８０８に、ＣＯＮＮＥＣＴメッセージをそのＭＮに関連付けられたＭＱＴＴサーバ＋１８１２に発行するように命令する。Ｍ２Ｍサービスプロバイダドメインにわたり固有である、ＭＮ ＣＳＥ識別子が、ＣＯＮＮＥＣＴメッセージ内のＣｌｉｅｎｔＩＤパラメータとして使用される（ＣｌｉｅｎｔＩＤは、そのＭＱＴＴサーバ＋への全接続にわたり固有でなければならない）。

図１８の前提条件調整ステップ２では、ＭＱＴＴサーバ＋１８１２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１８の前提条件調整ステップ３では、ＭＮ−ＣＳＥ１８０４は、ＭＮ ＭＱＴＴクライアント１８０８に、ＳＵＢＳＣＲＩＢＥメッセージをＭＮ ＭＱＴＴサーバ＋１８１２に発行するように命令する。ＭＮ−ＣＳＥ−ＩＤは、ＳＵＢＳＣＲＩＢＥメッセージ内にトピックフィルタパラメータを形成するために使用される。４つの別個のトピックフィルタストリングが、このパラメータ内に含まれる。最初の３つのストリングは、ＭＮ−ＣＳＥ１８０４にアドレスされたトラフィックがそれに向かってルーティングされることをもたらす。第４のストリングは、システム特定の値「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ−ＩＤ／＋」である。このトピックにパブリッシュするクライアントは、サーバ＋／レジストラＣＳＥに、＜ＡＥ＞リソース名値（そして、クライアントは、レジストラＣＳＥとのコンタクト開始に先立って、＜ＡＥ＞リソース名値を「自己サブスクライブ」するために使用することができる）の事前割り当に対する要求を信号伝達する。セクションを参照されたい。

図１８の前提条件調整ステップ４では、ＭＱＴＴサーバ＋１８１２は、ＳＵＢＡＣＫメッセージで応答し、４つのサブスクリプション要求の各々が受信および処理されたことを示す。

（ＡＥヌル接続）
図１８の前提条件調整ステップ５では、アプリケーション専用ノード（ＡＤＮ）１８１６上のＭＱＴＴクライアント１８１４は、ＡＤＮ−ＡＥ１８０２（「発信側ＡＥ」）によって、ＣＯＮＮＥＣＴメッセージをそのレジストラＣＳＥ１８０４に関連付けられたＭＱＴＴサーバ＋１８１２に発行するように命令すされる（このＭＱＴＴサーバ＋１８１２のアドレスは、事前構成される）。クライアント識別子（ＣｌｉｅｎｔＩＤ）パラメータは、ヌル（ゼロバイトの長さ）である。

図１８の前提条件調整ステップ６では、ＭＱＴＴサーバ＋１８１２は、ヌルＣｌｉｅｎｔＩＤの受信の結果として、このセッションのための固有のＣｌｉｅｎｔＩＤ値を割り当て、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１８の前提条件調整ステップ７では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアント１８１４に、ＳＵＢＳＣＲＩＢＥメッセージをレジストラＣＳＥ１８０４のＭＱＴＴサーバ＋１８１２に発行するように命令する。トピックフィルタパラメータは、システム特定のストリング「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ−ＩＤ」であり、それは、＜ＡＥ＞リソース名の事前割り当に対する要求に関連付けられたサブスクリプションを表す。

図１８の前提条件調整ステップ８では、ＭＱＴＴサーバ＋１８１２は、ＳＵＢＡＣＫメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。ＭＱＴＴサーバ＋１８１２は、特殊文字「／」およびこのセッションのためのＣｌｉｅｎｔＩＤ値を受信されたトピックフィルタストリング「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ−ＩＤ」に付加することによって、クライアントのためのサブスクリプションフィルタを作成する。

（ＡＥ−ＩＤ割り当て）
図１８の前提条件調整ステップ９では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアント１８１４に、ＰＵＢＬＩＳＨメッセージをレジストラＣＳＥ１８０４のＭＱＴＴサーバ＋１８１２に発行するように命令する。トピック名パラメータは、システム特定のストリング「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ−ＩＤ」であり、それは、レジストラＣＳＥ１８０４による＜ＡＥ＞リソース名の事前割り当てのためのフラグを表す。ペイロードパラメータは、ヌル（ゼロバイトの長さ）である。

図１８の前提条件調整ステップ１０では、ＭＮ−ＣＳＥ１８０４（レジストラＣＳＥ）のＭＱＴＴサーバ＋１８１２は、システム特定のトピック名ストリング「＄ＳＹＳ／ｏｎｅＭ２Ｍ／ＡＥ−ＩＤ」を伴うＰＵＢＬＩＳＨメッセージを受信すると、特殊文字「／」およびこのセッションのためのＣｌｉｅｎｔＩＤ値をそれに付加する。修正されたトピック名ストリングは、図１８の前提条件調整ステップ３からのＭＮ ＭＱＴＴクライアント１８０８のためのサブスクリプションフィルタに一致し、したがって、ＭＱＴＴサーバ＋１８１２は、修正されたＰＵＢＬＩＳＨメッセージをＭＮ ＭＱＴＴクライアントに転送する。

修正されたトピック名ストリングは、図１８の前提条件調整ステップ７からのＡＤＮ ＭＱＴＴクライアントのためのサブスクリプションフィルタにも一致するが、サーバ＋１８１２は、この場合、パブリッシャおよび加入者が同一であるので、メッセージを転送しない
図１８の前提条件調整ステップ１１では、ＭＮ−ＣＳＥ１８０４は、ＭＮ ＭＱＴＴクライアント１８０８からの修正されたシステム特定のストリングを伴うＰＵＢＬＩＳＨメッセージを受信すると、要求を処理し、＜ＡＥ＞リソース名値を割り当てる。

図１８の前提条件調整ステップ１２では、ＭＮ−ＣＳＥ１８０４は、ＭＮ ＭＱＴＴクライアント１８０８に、ＰＵＢＬＩＳＨメッセージを関連付けられたＭＱＴＴサーバ＋に発行するように命令する。トピック名パラメータは、図１８の前提条件調整ステップ１０で受信された同じシステム特定のストリングに設定される。ペイロードは、（事前に）割り当てられた＜ＡＥ＞リソース名である。

図１８の前提条件調整ステップ１３では、ＭＱＴＴサーバ＋１８１２は、修正されたシステム特定のトピック名ストリングを伴うＰＵＢＬＩＳＨメッセージを受信すると、ストリングが図１８の前提条件調整ステップ８からのＡＤＮ ＭＱＴＴクライアント１８１４のためのサブスクリプションフィルタに一致することを決定する。ＭＱＴＴサーバ＋１８１２は、ＰＵＢＬＩＳＨメッセージをＡＤＮ ＭＱＴＴクライアント１８１４に転送する。

図１８の前提条件調整ステップ１４では、ＡＤＮ−ＡＥ１８０２は、ペイロードパラメータをその新しい＜ＡＥ＞リソース名として記憶する。

（ＡＥヌル解放）
図１８の前提条件調整ステップ１５では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアントに、ＵＮＳＣＲＩＢＥ解除メッセージをレジストラＣＳＥ１８０４のＭＱＴＴサーバ＋１８１２に発行するように命令する。使用されるトピックフィルタパラメータ値は、図１８の前提条件調整ステップ１４に記憶されたものと同一である。

図１８の前提条件調整ステップ１６では、ＭＱＴＴサーバ＋１８１２は、ＵＮＳＵＢＡＣＫメッセージで応答する。

図１８の前提条件調整ステップ１７では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアント１８１４に、ＤＩＳＣＯＮＮＥＣＴメッセージをレジストラＣＳＥのＭＱＴＴサーバ＋１８１２に発行するように命令する。ＡＤＮ ＭＱＴＴクライアントは、次いで、ネットワーク接続を閉鎖する。

図１８の前提条件調整ステップ１８では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアント１８１４に、ＣＯＮＮＥＣＴメッセージをそのレジストラＣＳＥ１８０４に関連付けられたＭＱＴＴサーバ＋１８１２機能に発行するように命令する。ＡＥ識別子（ＡＥ−ＩＤ）または図１８の前提条件調整ステップ１４で記憶された＜ＡＥ＞リソース名に基づくローカルに固有の相対的バージョンが、ＣＯＮＮＥＣＴメッセージ内のＣｌｉｅｎｔＩＤパラメータとして使用される。

図１８の前提条件調整ステップ１９では、ＭＱＴＴサーバ＋１８１２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１８の前提条件調整ステップ２０では、ＡＤＮ ＭＱＴＴクライアント１８１４は、ＳＵＢＳＣＲＩＢＥメッセージをレジストラＣＳＥ１８０４のＭＱＴＴサーバ＋１８１２に発行するように命令される。＜ＡＥ＞ＵＲＩは、ＳＵＢＳＣＲＩＢＥメッセージ内にトピックフィルタパラメータを形成するために使用される。具体的には、特殊文字「／」が、＜ＡＥ＞ＵＲＩに付加され、トピックフィルタストリングを生成する。

図１８の前提条件調整ステップ２１では、ＭＱＴＴサーバ＋１８２は、ＳＵＢＡＣＫメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。

（図１８の動作ステップ）
図１８の動作ステップ１では、ＡＤＮ−ＡＥ１８０２（「発信側ＡＥ」）は、サービス層要求プリミティブをＡＤＮ ＭＱＴＴクライアント１８１４に発行する。ｏｐ（動作）パラメータは、「Ｃ」（作成）に設定される。プリミティブのｔｏパラメータは、＜ＭＮ−ＣＳＥＢａｓｅ＞ＵＲＩ（ＭＱＴＴトピック名ストリングとしても使用される）である。ｔｙパラメータは、＜ＡＥ＞リソースタイプを示し、それは、レジストラＣＳＥに、ＡＤＮ−ＡＥのための＜ＡＥ＞リソースを作成する（すなわち、アプリケーション登録を行う）ように命令する。ｎｍパラメータは、図１８の前提条件調整ステップ１４で受信された＜ＡＥ＞リソース名値に設定される。

図１８の動作ステップ２では、ＡＤＮ ＭＱＴＴクライアント１８１４は、ＰＵＢＬＩＳＨメッセージをＭＮ ＭＱＴＴサーバ＋１８１２（それが接続を確立した）に発行する。

図１８の動作ステップ３では、ＭＮ ＭＱＴＴサーバ＋１８１２は、受信されたトピック名（＜ＭＮ−ＣＳＥＢａｓｅ＞ＵＲＩ）をそのサブスクリプションリストと比較し、ＭＮ ＭＱＴＴクライアント１８０８に対応する一致を見つける（図１８の前提条件調整ステップ３の上記例を参照）。ＭＮ ＭＱＴＴサーバ＋１８１２は、ＰＵＢＬＩＳＨメッセージをＭＮ ＭＱＴＴクライアント１８０８に転送する。

図１８の動作ステップ４では、ＭＮ ＭＱＴＴクライアント１８０８は、受信されたペイロード（すなわち、サービス層作成要求プリミティブ）をＭＮ−ＣＳＥ１８０４（レジストラＣＳＥ）に配信する。

図１８の動作ステップ５では、＜ＡＥ＞リソースが、ＭＮ−ＣＳＥＢａｓｅ下に作成される（ＡＥが、認証に成功し、十分なアクセス権を有する場合）。

図１８の動作ステップ６では、ＭＮ−ＣＳＥ１８０４は、応答プリミティブをＭＮ ＭＱＴＴクライアント１８０８に送信し、ｒｓパラメータ内に作成動作の成功または失敗を示す。発信応答プリミティブのｔｏパラメータは、作成されたばかりの＜ＡＥ＞リソースのＵＲＩに設定される。ｃｎパラメータは、適切なコンテンツに設定される。すなわち、成功の場合（示される）、作成された＜ＡＥ＞リソースのＵＲＩに設定される。

図１８の動作ステップ７では、ＭＮ ＭＱＴＴクライアント１８０８は、ＰＵＢＬＩＳＨメッセージを関連付けられたＭＮ ＭＱＴＴサーバ＋１８１２に発行する。

図１８の動作ステップ８では、ＭＮ ＭＱＴＴサーバ＋１８１２は、受信されたトピック名（＜ＡＥ＞ＵＲＩ）をそのサブスクリプションリストと比較し、ＡＤＮ ＭＱＴＴクライアント１８１４に対応する一致を見つける。ＭＮ ＭＱＴＴサーバ＋１８１２は、ＰＵＢＬＩＳＨメッセージをＡＤＮ ＭＱＴＴクライアント１８１４に転送する。

図１８の動作ステップ９では、ＡＤＮ ＭＱＴＴクライアント１８１４は、受信されたペイロード（すなわち、作成応答プリミティブ）をＡＤＮ−ＡＥ１８０２に配信する。

一実施形態は、ＭＱＴＴサーバ＋１８１２等のＭＱＴＴサーバにおける方法である。パブリッシュ要求が、ＡＤＮ１８１６等のアプリケーションから受信され、それは、図１８の前提条件調整ステップ９におけるように、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用する。所定のトピックフィルタパラメータに応答して、図１８の前提条件調整ステップ１０におけるように、一時的クライアントＩＤを含むメッセージが、レジストラＣＳＥ１８０４のためにパブリッシュされる。図１８の前提条件調整ステップ１２におけるように、割り当てられたアプリケーション名をペイロードとして含むメッセージが、レジストラＣＳＥ１８０４から受信される。割り当てられたアプリケーション名は、図１８の前提条件調整ステップ１３におけるように、アプリケーションに提供される。サブスクリプション要求が、図１８の前提条件調整ステップ２０におけるように、割り当てられたアプリケーション名をトピックフィルタの一部として含むアプリケーションから受信される。

別の実施形態は、ＡＤＮ１８０２等のアプリケーションにおける方法である。図１８の前提条件調整ステップ９におけるように、パブリッシュ要求がＭＱＴＴサーバ＋１８１２等のＭＱＴＴサーバに送信され、それは、アプリケーション識別子に対する要求に関連する所定のトピックフィルタパラメータを使用する。割り当てられたアプリケーション名をペイロードとして含むメッセージが、ＭＱＴＴサーバ＋１８１２から受信される。図１８の前提条件調整ステップ２０におけるように、割り当てられたアプリケーション名をトピックフィルタの一部として含むサブスクリプション要求が、ＭＱＴＴサーバ１８１２に送信される。

図１８に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１８に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１８に図示されるステップを行う、図２２Ｃまたは図２２Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。さらに、図１８に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図１９は、サービス層読み出し動作の実施例を図示するフロー図である。

（図１９の前提条件調整ステップ）
これらのステップは、ノード間のネットワーク接続が（再）確立されなければならないときは常に行われることができる。ＡＥ１８０２は、すでに登録され、ＡＥ−ＩＤが割り当てられている。

図１９の前提条件調整ステップ１では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアント１８１４に、ＣＯＮＮＥＣＴメッセージをそのレジストラＣＳＥ１８０４に関連付けられたＭＱＴＴサーバ＋１８１２に発行するように命令する。ＡＥ識別子（ＡＥ−ＩＤ）または＜ＡＥ＞リソース名に基づくローカルに固有の相対的バージョンが、ＣＯＮＮＥＣＴメッセージ内のＣｌｉｅｎｔＩＤパラメータとして使用される。

図１９の前提条件調整ステップ２では、ＭＱＴＴサーバ＋１８１２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１９の前提条件調整ステップ３では、ＡＤＮ−ＡＥ１８０２は、ＡＤＮ ＭＱＴＴクライアントに、ＳＵＢＳＣＲＩＢＥメッセージをレジストラＣＳＥ１８０４のＭＱＴＴサーバ＋１８１２に発行するように命令する。＜ＡＥ＞ＵＲＩは、ＳＵＢＳＣＲＩＢＥメッセージ内にトピックフィルタパラメータを形成するために使用される。具体的には、ＭＱＴＴ特殊文字「／」が、＜ＡＥ＞ＵＲＩに付加され、トピックフィルタストリングを構成する。

図１９の前提条件調整ステップ４では、ＭＱＴＴサーバ＋１８１２は、ＳＵＢＡＣＫメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。

図１９の前提条件調整ステップ５では、ＩＮ−ＣＳＥ１８０６は、ＩＮ ＭＱＴＴクライアント１８２０に、ＣＯＮＮＥＣＴメッセージをそのＩＮ１８２４に関連付けられたＭＱＴＴサーバ＋１８２２に発行するように命令する。ＩＮのＣＳＥ識別子（Ｍ２Ｍサービスプロバイダドメインにわたり固有であるＩＮ−ＣＳＥ−ＩＤ）が、ＣＯＮＮＥＣＴメッセージ内のＣｌｉｅｎｔＩＤパラメータとして使用される。

図１９の前提条件調整ステップ６では、ＭＱＴＴサーバ＋１８１２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１９の前提条件調整ステップ７では、ＩＮ−ＣＳＥ１８０６は、ＩＮ ＭＱＴＴクライアント１８２０に、ＳＵＢＳＣＲＩＢＥメッセージをＩＮ ＭＱＴＴサーバ＋１８２２に発行するように命令する。ＩＮ−ＣＳＥ−ＩＤが、ＳＵＢＳＣＲＩＢＥメッセージ内のトピックフィルタパラメータを構成するために使用される３つの別個のトピックフィルタストリングが、このパラメータ内に含まれる：‘＜ＩＮ−ＣＳＥ−ＩＤ＞’、および、ＭＱＴＴ単一レベルおよびマルチレベルワイルドカード文字を‘＜ＩＮ−ＣＳＥ−ＩＤ＞’に付加することによって形成される２つの追加のストリング。

図１９の前提条件調整ステップ８では、ＭＱＴＴサーバ＋１８２２は、ＳＵＢＡＣＫメッセージで応答し、３つのサブスクリプション要求の各々が受信および処理されたことを示す。

ステップ９−１６では、ＭＱＴＴサーバ＋１８２２は、ＣＯＮＮＥＣＴまたはＳＵＢＳＣＲＩＢＥを発行するとき、ＭＱＴＴクライアントとしての役割を果たす。

図１９の前提条件調整ステップ９では、ＭＮ−ＣＳＥ１８０４は、ＭＮ ＭＱＴＴサーバ＋１８１２に、ＣＯＮＮＥＣＴメッセージをＩＮ ＭＱＴＴサーバ＋１８２２に発行するように命令する（ＩＮ ＭＱＴＴサーバ＋１８２２のアドレスは、事前構成される）。ＭＮ−ＣＳＥ−ＩＤは、ＣｌｉｅｎｔＩＤパラメータとして使用される。

図１９の前提条件調整ステップ１０では、ＩＮ ＭＱＴＴサーバ＋１８２２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１９の前提条件調整ステップ１１では、ＭＮ−ＣＳＥ１８０４は、ＭＮ ＭＱＴＴサーバ＋１８１２に、ＳＵＢＳＣＲＩＢＥメッセージをＩＮ ＭＱＴＴサーバ＋１８２２に発行するように命令する。＜ＭＮ−ＣＳＥ−ＩＤ＞ＵＲＩは、ＳＵＢＳＣＲＩＢＥメッセージ内にトピックフィルタパラメータストリングを形成するために使用される。具体的には、ＭＱＴＴ特殊文字「／＃」が、＜ＭＮ−ＣＳＥ−ＩＤ＞ＵＲＩに付加され、トピックフィルタストリングを構成する。このストリングは、ＩＮ ＭＱＴＴサーバ＋１８２２に、ＭＮ−ＣＳＥＢａｓｅの第１のレベルまたはその下方における任意の受信されたトピック名をＭＮ ＭＱＴＴサーバ＋１８１２に転送するように命令する。

図１９の前提条件調整ステップ１２では、ＩＮ ＭＱＴＴサーバ＋１８２２は、ＳＵＢＡＣＫメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。

図１９の前提条件調整ステップ１３では、ＩＮ−ＣＳＥ１８０６は、ＩＮ ＭＱＴＴサーバ＋１８２２に、ＣＯＮＮＥＣＴメッセージをＭＮ ＭＱＴＴサーバ＋１８２２に発行するように命令する（ＭＮ ＭＱＴＴサーバ＋１８１２のアドレスは、事前構成される）。ＩＮ−ＣＳＥ−ＩＤは、ＣｌｉｅｎｔＩＤパラメータとして使用される。

図１９の前提条件調整ステップ１４では、ＭＮ ＭＱＴＴサーバ＋１８１２は、ＣＯＮＮＡＣＫメッセージで応答し、接続が承認されたことを示す。

図１９の前提条件調整ステップ１５では、ＩＮ−ＣＳＥ１８０６は、ＩＮ ＭＱＴＴサーバ＋１８２２に、ＳＵＢＳＣＲＩＢＥメッセージをＭＮ ＭＱＴＴサーバ＋１８２２に発行するように命令する。＜ＩＮ−ＣＳＥ−ＩＤ＞ＵＲＩは、ＳＵＢＳＣＲＩＢＥメッセージ内にトピックフィルタパラメータストリングを形成するために使用される。具体的には、ＭＱＴＴ特殊文字「／＃」が、＜ＩＮ−ＣＳＥ−ＩＤ＞ＵＲＩに付加され、トピックフィルタストリングを構成する。このストリングは、ＭＮ ＭＱＴＴサーバ＋１８１２に、ＩＮ−ＣＳＥＢａｓｅの第１のレベルまたはその下方における任意の受信されたトピック名をＩＮ ＭＱＴＴサーバ＋１８２２に転送するように命令する。

図１９の前提条件調整ステップ１６では、ＭＮ ＭＱＴＴサーバ＋１８１２は、ＳＵＢＡＣＫメッセージで応答し、サブスクリプション要求が受信および処理されたことを示す。

（図１９の動作ステップ）
以下のステップは、前述の前提条件調整ステップが生じたことを前提とする。

図１９の動作ステップ１では、ＡＤＮ−ＡＥ１８０２（「発信側ＡＥ」）は、サービス層読み出し要求プリミティブをＡＤＮ ＭＱＴＴクライアント１８１４に発行する。プリミティブのｔｏパラメータは、＜ＩＮ−ＣＳＥＢａｓｅ＞下に位置するリソースのためのＵＲＩである（ＭＱＴＴトピック名ストリングとしても使用される）。ｆｒパラメータは、＜ＡＥ−ＩＤ＞ＵＲＩである（標的ＣＳＥによって応答をアドレスするために使用される）。

図１９の動作ステップ２では、ＡＤＮ ＭＱＴＴクライアント１８１４は、要求プリミティブをそのペイロードとして有するＰＵＢＬＩＳＨメッセージをＭＮ ＭＱＴＴサーバ＋１８１２（それが図１９の前提条件調整ステップ１において接続を確立した）に発行する。

図１９の動作ステップ３では、ＭＮ ＭＱＴＴサーバ＋１８１２は、受信されたトピック名（＜ＩＮ−ＣＳＥＢａｓｅ＞下のリソースＵＲＩ）をそのサブスクリプションリストと比較し、ＩＮ ＭＱＴＴサーバ＋１８２２に対応する一致を見つける（上記の図１９の前提条件調整ステップ１４を参照）。ＭＮ ＭＱＴＴサーバ＋１８１２は、ＰＵＢＬＩＳＨメッセージをＩＮ ＭＱＴＴサーバ＋１８２２に転送する。

図１９の動作ステップ４では、ＩＮ ＭＱＴＴサーバ＋１８２２は、受信されたトピック名（＜ＩＮ−ＣＳＥＢａｓｅ＞下のリソースＵＲＩ）をそのサブスクリプションリストと比較し、ＩＮ ＭＱＴＴクライアントに対応する一致を見つける（上記の図１９の前提条件調整ステップ６を参照）。ＩＮ ＭＱＴＴサーバ＋は、ＰＵＢＬＩＳＨメッセージをＩＮ ＭＱＴＴクライアント１８２０に転送する。

図１９の動作ステップ５では、ＩＮ ＭＱＴＴクライアントは、受信されたペイロード（すなわち、読み出し要求プリミティブ）をＩＮ−ＣＳＥ１８０６（標的ＣＳＥ）に配信する。

図１９の動作ステップ６では、規定されたリソースコンテンツが、読み出される（発信側ＡＥ１８０２がアクセス権を有する場合）。

図１９の動作ステップ７では、ＩＮ−ＣＳＥ１８０６は、読み出し応答プリミティブをＩＮ ＭＱＴＴクライアント１８２０に発行する。発信プリミティブのｔｏパラメータは、受信されたｆｒパラメータ（「／」が付加された＜ＡＥ＞ＵＲＩ）に設定される。ｃｎパラメータは、適切なコンテンツに設定される。すなわち成功の場合（示される）、読み出されるリソースの要求されるコンテンツに設定される。

図１９の動作ステップ８では、ＩＮ ＭＱＴＴクライアント１８２０は、応答プリミティブをそのペイロードとして有するＰＵＢＬＩＳＨメッセージをＩＮ ＭＱＴＴサーバ＋１８２２に発行する。

図１９の動作ステップ９では、ＩＮ ＭＱＴＴサーバ＋１８２２は、受信されたトピック名（「／」が付加されたｒ＜ＭＮ−ＣＳＥＢａｓｅ＞下の＜ＡＥ＞のＵＲＩ）をそのサブスクリプションリストと比較し、ＭＮ ＭＱＴＴサーバ＋１８１２に対応する一致を見つける（上記の前提条件調整ステップ１４を参照）。ＩＮ ＭＱＴＴサーバ＋１８２２は、ＰＵＢＬＩＳＨメッセージをＭＮ ＭＱＴＴサーバ＋１８１２に転送する。

図１９の動作ステップ１０では、ＭＮ ＭＱＴＴサーバ＋１８１２は、受信されたトピック名（「／」が付加された＜ＭＮ−ＣＳＥＢａｓｅ＞下の＜ＡＥ＞のＵＲＩ）を比較し、ＡＤＮ−ＡＥに対応する一致を見つける。ＭＮ ＭＱＴＴサーバ＋１８１２は、ＰＵＢＬＩＳＨメッセージをＡＤＮ ＭＱＴＴクライアント１８１４に転送する。さらに、図１６におけるトピック名一致実施例も参照されたい。

図１９の動作ステップ１１では、ＡＤＮ ＭＱＴＴクライアント１８１４は、読み出し応答（すなわち、ＰＵＢＬＩＳＨメッセージのペイロード）を発信側ＡＥ１８０２に配信する。

一実施形態は、中間ノードのＭＱＴＴサーバ＋１８１２における方法である。図１９の前提条件調整ステップ３に示されるように、サブスクライブ要求が、中間ノード１８１０およびアプリケーション１８１６を示すトピックフィルタを伴ってアプリケーションから受信される。図１９の前提条件調整ステップ１１に示されるように、サブスクライブ要求が、インフラストラクチャノード１８２４を示すトピックフィルタを伴うトピックに対して、インフラストラクチャノード１８２４におけるＭＱＴＴサーバ１８２２に送信される。図１９の前提条件調整ステップ１５に示されるように、サブスクライブ要求が、インフラストラクチャノード１８２４を示すトピックフィルタを伴うトピックに対して、インフラストラクチャノード１８２４におけるＭＱＴＴサーバ１８２２から受信される。メッセージが、中間ノードおよびインフラストラクチャノードに作成されたトピックを使用して、アプリケーションとインフラストラクチャノードとの間で、中間ノードを通して転送されることができる。

図１９に図示されるステップを行うエンティティは、図２２Ｃまたは図２２Ｄに図示されるもの等のネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１９に図示される方法は、コンピュータ実行可能命令が、ノードのプロセッサによって実行されると、図１９に図示されるステップを行う、図２２Ｃまたは図２２Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る。さらに、図１９に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、ノードの通信回路によって行われ得ることも理解されたい。

図２０は、拡張ｏｎｅＭ２Ｍ ＲＯＡ実施形態におけるＭＱＴＴ ＣＳＦを図示する略図である。前述のＭＱＴＴサーバ＋機能は、アドオンソフトウェアライブラリとして実装されることができる。すなわち、それは、機能するために、ＣＳＥの中に統合される必要はない。しかしながら、図２０に示されるように、ＭＱＴＴパブリケーションおよび配信機能性が他のサービス機能とより密に結合される場合、さらなる最適化が可能である。

例えば、接続の動的確立および分断は、ＭＱＴＴサーバ＋２００４およびＣＳＥ２００２が別個である場合、煩雑である。なぜなら、ＣＳＥ２００２が、それらを管理するために、常時、ＭＱＴＴサーバ＋２００４によって維持される接続を把握する必要があるだろうからである（おそらく、別個のエンティティである場合、照会機構を介して）。ＣＳＥ２００２の中への統合は、この問題を軽減する。さらに、ＡＥ−ＩＤ事前割り当ては、統合されたＭＱＴＴサーバ２００４が、ＡＥ−ＩＤ事前割り当てを要求するトリガストリングを処理のために直接ＣＳＥ２００２にパスし、結果を直接要求側ＡＥに返すことができるので、はるかに少ないプロトコルオーバーヘッドを要求するであろう。

図２０に図示される機能性は、以下に説明される図２２Ｃまたは２２Ｄに図示されるもの等のＭ２Ｍネットワークのノード（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、ＭＱＴＴを使用して、サービス層ＲＯＡインターネットワーキングに関係付けられる機能性を制御および／または構成するようにユーザを支援するために使用されることができる。図２１は、ユーザが、識別子番号を決定し、デバイスを登録および登録解除することを可能にする、インターフェース２１０２を図示する略図である。インターフェース２１０２は、以下で説明される図２２Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図２２Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷＯＴだけではなく、ＩｏＴ／ＷｏＴサービス層等のコンポーネントまたはノードであり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の機能性および論理エンティティを含むことができる。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）もしくは無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する多重アクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍ端末デバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２２Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ならびにＣＳＥ１８０４、１８０６、および２００２等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２２Ｃおよび２２Ｄで図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が、存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。

図２２Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示されるシステムおよび方法と併せて使用され得る。

一実施形態では、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の論理エンティティは、図２２Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２Ｍノードによってホストされる、Ｍ２Ｍサービス層インスタンス内にホストされ得る。例えば、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。前述のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、もしくは１つ以上の既存のノードの一部としてのいずれかで実装され得る。実施例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２２Ｃまたは図２２Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で作動するソフトウェアの形態において実装され得る。

さらに、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の本願の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２２Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。デバイス３０は、図２２Ａ−Ｂに示されるようなＭ２Ｍネットワーク、もしくは非Ｍ２Ｍネットワークの一部であり得る。図２２Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装するノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されているコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行い得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させ得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

図２２Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に連結される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御し得る。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図２２Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内に一緒に統合され得ることが理解されるであろう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、他のＭ２Ｍノードに信号を伝送し、またはそこから信号を受信するように構成され得る。例えば、ある実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。ある実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送ならびに／もしくは受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送ならびに／もしくは受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２２Ｃに描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用し得る。したがって、ある実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させるか、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得るか、または情報をユーザに表示するように構成され得る。別の実施例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得るグラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にし得る。

プロセッサ３２は、電源４８から電力を受け取り得、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成され得るＧＰＳチップセット５０に連結され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図２２Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等、Ｍ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の論理エンティティを実行すること、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に連結されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、もしくは変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、それ自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、例えば、図２２Ａおよび図２２Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７等の通信回路を含み、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にし得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等の機械によって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。発信側ＡＥ１８０２、ＭＱＴＴサーバ＋１８１２、１８２２、および２００４、ＣＳＥ１８０４、１８０６、および２００２、ならびにＧＵＩ２１０２を作成するための論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されているコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル特定用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の有形または物理媒体を含むが、それらに限定されない。

図に図示されるような本開示の主題の好ましい実施形態を説明する上で、明確にするために、特定の用語が採用される。しかしながら、請求される主題は、そのように選択された特定の用語に限定されることを意図しておらず、各特定の要素は、同様の目的を達成するように同様に動作する全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、さらに、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合、請求項の範囲内であることを意図している。

Claims (11)

1. メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装するノードであって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに備え、前記命令は、前記ノードの前記プロセッサによって実行されると、
   アプリケーションからパブリッシュ要求を受信することであって、前記パブリッシュ要求は、アプリケーション識別子に関連する所定のトピックフィルタパラメータを使用する、ことと、
   前記所定のトピックフィルタパラメータに応答して、レジストラ共通サービスエンティティ（ＣＳＥ）に対してメッセージをパブリッシュすることであって、前記メッセージは、一時的クライアント識別子（ＩＤ）を含む、ことと、
   前記レジストラＣＳＥから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
   前記割り当てられたアプリケーション名を前記アプリケーションに提供することと、
   前記アプリケーションから、前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を受信することと
   を前記ノードに行わせる、ノード。
2. 前記一時的クライアント識別子は、ヌル識別子である、請求項１に記載のノード。
3. 前記ＭＱＴＴサーバは、クライアント機能性を含む、請求項１に記載のノード。
4. プロセッサおよびメモリを備えているノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、
   アプリケーション識別子に関連する所定のトピックフィルタパラメータを使用するパブリッシュ要求をサーバに送信することと、
   前記サーバから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
   前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を前記サーバに送信することと
   を前記ノードに行わせる、ノード。
5. 前記サーバは、メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバである、請求項４に記載のノード。
6. メッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバを実装するノードによって使用される方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
   アプリケーションからパブリッシュ要求を受信することであって、前記パブリッシュ要求は、アプリケーション識別子に関連する所定のトピックフィルタパラメータを使用する、ことと、
   前記所定のトピックフィルタパラメータに応答して、レジストラ共通サービスエンティティ（ＣＳＥ）に対してメッセージをパブリッシュすることであって、前記メッセージは、一時的クライアント識別子（ＩＤ）を含む、ことと、
   前記レジストラＣＳＥから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
   前記割り当てられたアプリケーション名を前記アプリケーションに提供することと、
   前記アプリケーションから、前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を受信することと
   を含む方法の機能を実行する、方法。
7. 前記一時的クライアント識別子は、ヌル識別子である、請求項６に記載の方法。
8. 前記ＭＱＴＴサーバは、クライアント機能性を含む、請求項６に記載の方法。
9. ノードによって使用される方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
   アプリケーション識別子に関連する所定のトピックフィルタパラメータを使用するパブリッシュ要求をサーバに送信することと、
   前記サーバから、割り当てられたアプリケーション名をペイロードとして含むメッセージを受信することと、
   前記割り当てられたアプリケーション名を前記トピックフィルタの一部として含むサブスクリプション要求を前記サーバに送信することと
   を含む方法の機能を実行する、方法。
10. 前記ノードは、アプリケーションを実装する、請求項９に記載の方法。
11. 前記サーバは、クライアント機能性を含むメッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）サーバである、請求項９に記載の方法。