JP7089510B2 - アプリケーションのサービス層のモビリティ管理 - Google Patents

Description

（関連出願の相互参照）
本出願は、２０１６年１０月６日に出願された米国特許仮出願第６２／４０４，９４１号に対する利益を主張するものであり、その開示はその全体が記載されたかのように参照により本明細書に組み込まれる。

Ｍ２Ｍの利益の可能性によって、マシンが互いに通信することを可能にするためのいくつかの分野特有のアプリケーションすなわちバーティカルアプリケーションがもたらされた。例えば、ヘルスケア分野、エネルギー分野、および自動車分野で解決策が見つかる。これらの解決策は、これらの垂直統合型アプリケーション向けに最適化されているが、異なる垂直統合型アプリケーションからのマシンおよびモノどうしが相互作用する、包括的なＩｏＴを実現することを約束していない。

この目的のために、いくつかの標準化団体（例えば、ｏｎｅＭ２Ｍ）が、異なる産業分野のものであっても、すべてのアプリケーション間でデータを交換および共有するための単一のホリゾンタルプラットフォームを定義するサービス層を開発している。

プロトコルスタックの観点からは、サービス層は、典型的には、アプリケーションプロトコル層の上に置かれ、アプリケーションに付加価値サービスを提供する。従って、サービス層は、しばしば、「ミドルウェア」サービスとして分類される。例えば、図１は、ＩＰネットワークスタック１０６とアプリケーション１０４との間の例示的なサービス層１０２を示す。

Ｍ２Ｍサービス層は、アプリケーションを提供することができ、デバイスは、サービス層によってサポートされるＭ２Ｍ指向の機能（Ｍ２Ｍサービス）の集合にアクセスする。これらの機能は、アプリケーションプログラミングインターフェース（ＡＰＩ）を介してアプリケーション利用できるようにされる。例えば、Ｍ２Ｍサービス層は、（Ｍ２Ｍアプリケーションが適切なアクセス権を有する場合に）Ｍ２Ｍアプリケーションによって発見（ｄｉｓｃｏｖｅｒｅｄ）、参照（ｒｅｔｒｉｅｖｅｄ）、またはサブスクライブ（ｓｕｂｓｃｒｉｂｅｄ－ｔｏ）され得る大量のＭ２Ｍデータを維持することができる。サービス層によって提供され得るＭ２Ｍサービスのさらなる例としては、セキュリティ、課金、デバイス管理、プロビジョニング、および接続管理が挙げられる。

典型的なＭ２Ｍ配備（図２に示す）は、様々なレベルのＭ２Ｍサービス機能を提供するいくつかのエンティティ／ノードを有する。非限定的な例では：
・Ｍ２Ｍサービスをホストし、Ｍ２Ｍサービスプロバイダによって運用される、Ｍ２Ｍサーバ２０２、
・Ｍ２Ｍサービスをホストする、Ｍ２Ｍミドルノード（またはゲートウェイ）２０４、２０６、２０８、２１０、および２１２、
・Ｍ２Ｍサービス２１４、２１６、２１８、２２０、２２２、２２４をホストする、Ｍ２Ｍデバイス、ならびに
・Ｍ２Ｍサービス２２６、２２８、および２３０を通常ホストしない「軽」Ｍ２Ｍデバイス。

これらのエンティティ上に存在するか、ネットワークを介してこれらのエンティティにアクセスするかのいずれかであり得るＭ２Ｍアプリケーションは、提供されているＭ２Ｍサービスを利用する。図２に示すように、これらのＭ２Ｍサービスは、ローカルに提供することができ、例えば、Ｍ２Ｍアプリケーション１は、データストレージを提供するためにＭ２Ｍデバイス１によって提供されるローカルＭ２Ｍサービスを使用することができる。加えて、Ｍ２Ｍサービスはまた、リモートで提供されてもよい。例えば、Ｍ２Ｍアプリケーション２は、Ｍ２Ｍサーバによって提供されるサービスを使用して、そのデータを発見可能にすることができる。図示のＭ２Ｍサービス配備は、本質的に階層的であり、これは、ｏｎｅＭ２ＭおよびＥＴＳＩ Ｍ２Ｍにおいて記載されているＭ２Ｍサービス層の典型であることに留意されたい。

ｏｎｅＭ２Ｍは、Ｍ２Ｍサービス層の作成をターゲットとしている１つの標準化機関（ＳＤＯ）である。ｏｎｅＭ２Ｍは、そのサービス層をオペレーティングシステムに似た分散型ソフトウェア層として記述している。この分散型ソフトウェア層は、Ｍ２Ｍアプリケーションとデータ転送を提供する通信ハードウェア（ＨＷ）／ソフトウェア（ＳＷ）との間に位置する共通サービス層に実装される。

共通サービス層は、機能別に、共通サービス機能（ＣＳＦ）にまとめてグループ化された、一式の標準化されたＭ２Ｍサービスを提供する。いくつかのインスタンス化されたＣＳＦが、共通サービスエンティティ（ＣＳＥ）３０２を構成する。図３に示すように、これらのサービス層（ＣＳＥ）３０２は、以下とインターフェースする：
・Ｍｃａ参照点を介して、アプリケーション（ｏｎｅＭ２Ｍの用語体系ではアプリケーションエンティティまたはＡＥ ３０４）、
・Ｍｃｃ（またはＭｃｃ’）参照点を介して、他のサービス層（ＣＳＥ）、
・Ｍｃｎ参照点を介して、基礎となるネットワーク（ｏｎｅＭ２Ｍの用語体系ではネットワークサービスエンティティまたはＮＳＥ ３０６）。

図３には、ｏｎｅＭ２Ｍによって現在定義されている１２個のＣＳＦも示されている。ＣＳＦのそれぞれについて以下に簡単に説明する：
・アプリケーションおよびサービス層管理ＣＳＦ：ＡＥおよびＣＳＥの管理を提供する。これには、ＣＳＥの機能を構成、トラブルシューティング、およびアップグレードする機能、ならびにＡＥをアップグレードする機能が含まれる。
・発見ＣＳＦ：フィルタ基準に基づいてアプリケーションおよびサービスに関する情報を検索する。
・登録ＣＳＦ：ＡＥ（または他のリモートＣＳＥ）がＣＳＥに登録するための機能を提供する。これにより、ＡＥ（またはリモートＣＳＥ）はＣＳＥのサービスを使用できる。
・通信管理／配信処理ＣＳＦ：他のＣＳＥ、ＡＥ、およびＮＳＥとの通信を提供する。このＣＳＦは、いつ、どの通信接続で通信を配信するかを決定し、必要に応じ、かつ許可されている場合に、通信要求をバッファリングして後で転送できるようにする。
・グループ管理ＣＳＦ：グループ関連の要求を処理する。Ｍ２Ｍシステムが複数のデバイス、アプリケーションなどの一括操作をサポートできるようにする。
・セキュリティＣＳＦ：識別、認証、および認可を含むアクセス制御など、サービス層にセキュリティ機能を提供する。
・データ管理および蓄積ＣＳＦ：データストレージおよび仲介機能（集約のためのデータ収集、データの再フォーマット、分析とセマンティック処理のためのデータストレージ）を提供する。
・位置情報（Ｌｏｃａｔｉｏｎ）ＣＳＦ：ＡＥが地理的な位置情報を取得できるようにするための機能を提供する。
・サービス課金および管理（Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ ＆ Ａｃｃｏｕｎｔｉｎｇ）ＣＳＦ：サービス層に課金機能を提供する。
・デバイス管理ＣＳＦ：Ｍ２ＭゲートウェイおよびＭ２Ｍデバイス上のデバイス機能の管理を提供する。
・ネットワークサービス連携（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ｅｘｐｏｓｕｒｅ，Ｓｅｒｖｉｃｅ Ｅｘｅｃｕｔｉｏｎ ａｎｄ Ｔｒｉｇｇｅｒｉｎｇ）ＣＳＦ：ネットワークサービス機能にアクセスするための基礎となるネットワークとの通信を管理する。
・サブスクリプションおよび通知ＣＳＦ：イベントへのサブスクライブを許可し、このイベントが発生したときに通知されるようにする機能を提供する。

ｏｎｅＭ２Ｍは、図４に示すリソース指向アーキテクチャ（ＲＯＡ）と呼ばれるサービス層アーキテクチャを開発している。

ＲＯＡでは、アーキテクチャはリソースを中心に開発されている。ＣＳＦは、これらのリソースを操作してサービスを実行する。リソースは、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥなどのＲＥＳＴの原則に沿った（ＲＥＳＴｆｕｌ）方法を介して操作され得る表現を有するアーキテクチャ内で、一意にアドレス指定可能な要素である。これらのリソースは、統一資源識別子（ＵＲＩ）を使用することによりアドレス可能となっている。リソースは、子リソース（複数可）と属性（複数可）とを含むことができる。子リソースは、親リソースと包含関係にあるリソースである。結果として、リソースは、ベースリソースから派生した階層ツリーとみなすことができる。親リソースの表現には、その子リソース（複数可）への参照が含まれている。子リソースの存続期間は、親のリソース存続期間によって制限される。各リソースは、リソースに関連する情報を格納する一式の「属性」をサポートしている。一式の属性はすべてのリソースに共通であるが、他の属性は特定のリソースにのみ適用される。後者は「リソース固有の属性」と呼ばれる。

ｏｎｅＭ２ＭのＲＯＡ内では、ｏｎｅＭ２Ｍサービス層でホストされているリソースと、ｏｎｅＭ２Ｍシステムと相互作用するエンティティと、の間には違いがある。サービス層では、すべての相互作用は要求操作を通じてエンティティ（ＡＥまたはＣＳＥ）によって開始され、これらの要求は常にリソースをターゲットとしている。これらの要求のそれぞれに対する応答は、常に、２つのエンティティ間にある。結果として、Ｍ２Ｍサービスプロバイダドメイン内では、各リソースは固有のリソースＩＤによって識別される必要があり、各エンティティ（ＡＥおよびＣＳＥ）は固有のエンティティＩＤによって識別される必要がある。追加の非限定的な詳細を以下に提供する：
・ＣＳＥ識別子（ＣＳＥ－ＩＤ）：このＩＤは、ＣＳＥを識別し、ＣＳＥとのすべての相互作用に使用される。サービスプロバイダは、各ＣＳＥに相対ＣＳＥ－ＩＤを割り当て、相対ＣＳＥ－ＩＤは、サービスプロバイダドメイン内で一意である。相対ＣＳＥ－ＩＤは、一意のＭ２ＭサービスプロバイダＩＤをプレフィックスとして付けることによって、グローバル・ユニークにすることができる。
・アプリケーションエンティティ識別子（ＡＥ－ＩＤ）：「Ｍ２Ｍノードに存在するＡＥ、またはＭ２Ｍノードと相互作用することを要求するＡＥ」（ｏｎｅＭ２Ｍ－ＴＳ－０００１（ｏｎｅＭ２Ｍ アーキテクチャ仕様書Ｖ２．６．０））を一意に識別するために使用される。ｏｎｅＭ２Ｍサービス層によって提供されるＭ２Ｍサービスを使用するために、アプリケーションは最初にＣＳＥに登録する必要がある。この登録要求の際、アプリケーションエンティティは、サービスプロバイダによって割り当てられた（ＩＮ－ＣＳＥによって割り当てられた）ＡＥ－ＩＤまたは「ローカル」に割り当てられた（レジストラＣＳＥとしても知られる、アプリケーションの登録先のＣＳＥによって割り当てられた）ＡＥ－ＩＤのいずれかを要求できる。ＩＮ－ＣＳＥによって割り当てられた場合、ＡＥ－ＩＤはサービスプロバイダドメイン内で一意である。そのような場合、ＡＥ－ＩＤは「Ｓ」の文字で始まる。対照的に、ＡＥ－ＩＤがレジストラＣＳＥによって割り当てられている場合、ＡＥ－ＩＤは、このＣＳＥに登録されているすべてのアプリケーション間でのみ一意である。そのような場合、ＡＥ－ＩＤは「Ｃ」の文字で始まる。ローカルに割り当てられたＡＥ－ＩＤは、レジストラＣＳＥのＣＳＥ－ＩＤのプレフィックスを付けることによって、サービスプロバイダドメイン内で一意にすることができる。
・リソースＩＤ：ほとんどのリソースＩＤは、リソースをホストしているＣＳＥによって割り当てられる。ＣＳＥは、非構造化ＩＤまたは構造化ＩＤを割り当てることができる。非構造化ＩＤは、ホスティングＣＳＥ内のリソースを一意に識別する一連の文字である。対照的に、構造化ＩＤは、その親子関係を通じてＣＳＥ内のリソースを識別する。これは、オペレーティングシステムのディレクトリ構造において、ファイル名がパスによって識別される方法と非常によく似ている。リソースＩＤは、ホスティングＣＳＥのＣＳＥ－ＩＤをプレフィックスとして付けることによって、サービスプロバイダドメイン内で一意にすることができる。そのような場合、ＩＤは「サービスプロバイダ相対リソースＩＤ」と呼ばれる。特に、このＩＤは、Ｍ２Ｍサービスプロバイダドメイン内のリソースおよびリソースがホストされているＣＳＥを一意に識別する。加えて、一意のＭ２ＭサービスプロバイダＩＤをプレフィックスとして付けることによって、任意のリソースＩＤをグローバルに一意にすることができる。そのような場合、ＩＤは「絶対リソースＩＤ」と呼ばれる。Ｍ２ＭリソースＩＤに関する１つの重要な注意は、それらがルーティング情報を運ばないということである。そのため、例えば、図５は絶対リソース識別子を示している。このリソースは：
・Ｍ２ＭサービスプロバイダＩＤ＝「ｗｗｗ．ｍ２ｍｐｒｏｖｉｄｅｒ２．ｃｏｍ」のサービスプロバイダドメイン内にあり、
・ＣＳＥ－ＩＤ＝ＣＳＥ００１のＣＳＥ内にあり、
・リソース「／ＡＥ１／」の下にあり、
・「ｃｏｎｔ００１」というリソース名を有する。
重要なのは、このリソースが、ＦＱＤＮがｗｗｗ．ｍ２ｍｐｒｏｖｉｄｅｒ２．ｃｏｍであるサーバ上にないということである。そうではなく、このリソースは、ＣＳＥ－ＩＤ ＣＳＥ００１のＣＳＥをホストしているサーバ上にある。ｏｎｅＭ２Ｍでは、このサーバのルーティング情報は、このＣＳＥのルーティング可能な場所を提供するアクセスポイント（ＰｏＡ）属性で維持される。ただし、ＰｏＡは、ＣＳＥ－ＩＤ ＣＳＥ００１のＣＳＥをホスティングしているサーバを示す別のＦＱＤＮを含む場合があることに留意されたい。

図６Ａ，Ｂは、ｏｎｅＭ２Ｍドメイン内の相互作用の例を示している。この図では、エンティティはボックスとして示され、またリソースはそれらのボックス内の楕円として示されている。ｏｎｅＭ２Ｍで定義されているすべてのサービス層の相互作用は、発信者（Ｏｒｉｇｉｎａｔｏｒ）と受信者（Ｒｅｃｅｉｖｅｒ）との間の要求／応答の交換を通じて行われる。発信者はＡＥまたはＣＳＥであり得、受信者は通常ＣＳＥである（図６Ａ参照）。これは、リソースの登録、参照、変更、または削除（ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥ要求を通じて実装される）を含む相互作用のためのものである。しかしながら、ｏｎｅＭ２Ｍは、受信者がＡＥである場合の相互作用を１つ定義している（図６Ｂ参照）。これは通知相互作用であり、ＮＯＴＩＦＹリクエストを通じて実装される。

図６Ａに示すように、受信者がＣＳＥである場合、要求は、エンティティから出て、受信者ＣＳＥ上の特定のリソースをターゲットとすることができる。対照的に、応答は、受信者エンティティ６０４から出て、発信者エンティティ６０２をターゲットとしている。要求の矢印は特定のリソースを指しているが、他のすべての矢印はエンティティを始点および終点としていることに留意されたい。図からわかるように、これらの矢印は発信者または受信者を指しており、リソースを指していない。図では、このことは、ボックス内のリソースではなく、ボックスの端部で終わる矢印で示されている。

図６Ｂに示すように、ＡＥへのＮＯＴＩＦＹ要求に関して状況はわずかに異なる。このような場合、発信者６０２からの要求は、ＡＥを「表す」リソースをターゲットとする必要がある。これは、ＡＥがこのＣＳＥに登録するときに、レジストラＣＳＥ上に作成された＜ＡＥ＞子リソースに対応する（この＜ＡＥ＞子リソースは、図６Ｂに示されている）。レジストラＣＳＥ ６０６が＜ＡＥ＞リソースをターゲットとするＮＯＴＩＦＹ要求を受信した場合、ＣＳＥは、これが登録ＡＥをリターゲティングすることを知っている。

サービス層によって提供されるサービスを使用するために、ＡＥおよびＣＳＥは最初にそのサービス層に登録しなければならない。これは、レジストラＣＳＥをターゲットとした特殊なＣＲＥＡＴＥ操作によって行われる。

アプリケーション登録には、少なくとも次の目的がある：
１．アプリケーションにＡＥ－ＩＤを割り当て、
２．サービス層内でアプリケーションを表したり、アプリケーションと通信したりするために使用される＜ＡＥ＞リソースをレジストラＣＳＥに作成する。

加えて、アプリケーションは、ローカルのレジストラＣＳＥによってＡＥ－ＩＤを割り当てさせる、またはこの割り当てにサービスプロバイダを含めるかを選択できる。アプリケーションが前者を選択した場合、ＡＥ－ＩＤはレジストラＣＳＥで一意であるが、サービスプロバイダドメイン内ではグローバル・ユニークではない。アプリケーションが後者を選択した場合、サービスプロバイダはＡＥ－ＩＤを割り当て、加えてＩＮ－ＣＳＥは＜ＡＥ＞リソースを（＜ＡＥＡｎｎｃ＞リソース内で）アナウンスする。このアナウンスメントにより、そのアプリケーションは他のアプリケーションまたはＣＳＥによって発見され得る。ＡＥ－ＩＤがサービスプロバイダによって割り当てられる場合、それはサービスプロバイダドメイン内でグローバル・ユニークであることが保証される。

２つのタイプのＡＥ－ＩＤを区別するために、ｏｎｅＭ２Ｍは、ＡＥ－ＩＤに１文字のプレフィックスを使用する。すなわち、
・ＡＥ－ＩＤは、ローカルのレジストラＣＳＥによって割り当てられている場合、「Ｃ」の文字で始まる。
・ＡＥ－ＩＤは、サービスプロバイダによって割り当てられている場合、「Ｓ」の文字で始まる。

サービスプロバイダによって割り当てられたＡＥ－ＩＤを使用することにより、サービス層は、アプリケーションが再登録を（例えば、接続が切断されたため、または最初の登録の有効期限が切れたために）試みているときを知ることができる。

ｏｎｅＭ２Ｍによって定義されたいくつかのＭ２Ｍサービスは、ＡＥと相互作用する。これらについては、以下で手短により詳しく説明する。

サブスクライブ／通知は、発信者がリソースにサブスクライブし、このリソースに関連する特定の基準が満たされたときに通知を送信させることを可能にする手順である。発信者は、次のようにリソースへのサブスクリプションを作成する：
１）＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞子リソースを作成する。
２）監視対象の基準を提供する（ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ属性で定義）。例えば、リソースのサイズが閾値を下回った場合、リソースが変更（ｕｐｄａｔｅｄ）または削除された場合、リソースに新しい子リソースがある場合、またはリソースの子リソースのうちの１つが削除された場合、イベントがトリガされ得る。
３）通知ターゲットのリストを提供する（ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性で定義）。これは、サブスクリプションリソースをホストしているＣＳＥがイベントの通知を（ＮＯＴＩＦＹ要求／応答の交換を通じて）送信する必要がある場所である。リスト内の各ターゲットは、ｏｎｅＭ２Ｍ準拠のリソースＩＤとして、またはｏｎｅＭ２Ｍ対応のプロトコルバインディングに準拠した識別子としてフォーマットできる。
４）他の通知関連ポリシーを提供する。例えば、発信者は次のようにし得る：
・送信する通知の最大数を制限する（ｅｘｐｉｒａｔｉｏｎＣｏｕｎｔｅｒ属性で定義）。
・バッチ通知を要求する（ｂａｔｃｈＮｏｔｉｆｙ属性で定義）。および／または
・通知を送信するレートを制限する（ｒａｔｅＬｉｍｉｔ属性で定義）。

典型的なサブスクリプションの例を図７に示す。加入者７０２は、サブスクライブ先リソースをホストしているＣＳＥにサブスクリプション要求をする（ステップ１）。ホスティングＣＳＥ ７０４は、その要求を受け入れた場合、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞子リソースを作成し（ステップ２）、加入者に応答して、サブスクリプションが正常であったことを通知する（ステップ３）。その後、サブスクライブ先リソースにおいて、加入者によって指定された基準に一致する変更があった場合（ステップ４）、ホスティングＣＳＥ ７０４は、通知ターゲットリスト上のすべてのターゲットに通知を送信する（ステップ５およびステップ６）。ステップ６における受信者はＡＥ（ＡＥ１）７０８であるため、通知は、ＡＥ１への通知をリターゲティングする役割を果たすＡＥ１のレジストラＣＳＥ ７０６に送信される（ステップ８、９、１０）。図を簡単にするために加入／通知手順のいくつかの詳細、すなわちステップ２の間に行われるサブスクリプション検証に関する詳細は省略されていることに留意されたい。

ｏｎｅＭ２Ｍでは、要求は、３つのタイプ、すなわち、ブロッキング、非ブロッキング同期、および非ブロッキング非同期の要求であり得る。各タイプは、発信者および中間ＣＳＥが、要求が宛先まで進むときに要求をどのように処理するかを定義する。特に、発信者、または要求の結果について知る必要がある他のエンティティが通知メッセージを受信できる場合は、非ブロッキング非同期要求が使用される。つまり、「要求された操作を実行するＣＳＥは、要求された操作のステータスおよび結果を１つまたは複数の通知ターゲットに送信するために、任意の時点で発信者または他の指示されたエンティティに非送信請求メッセージを送信し得る」。発信者は、ＣＳＥに要求を発行し、そして、この要求プリミティブには、応答を知らされることになっている通知ターゲット（エンティティ）のリストが含まれる。簡単なコールフローが図８に示されており、これは発信者８０２がホスティングＣＳＥ ７０４上のリソースをＵＰＤＡＴＥし、この要求に対する応答をＣＳＥ１およびＡＥ１に送信しようと試みていることを示している（ステップ１）。ホスティングＣＳＥ ７０４は、ターゲット情報を格納し（ステップ２）、要求が受け入れられたことを発信者８０２に応答する（ステップ３）。リソース変更に関連する処理が完了した後、ホスティングＣＳＥ ７０４は、ＮＯＴＩＦＹ要求を使用してターゲットに通知する（ステップ５およびステップ６）。ステップ６では、ターゲットはＡＥ ７０８であり、そのため、応答は、最初にＡＥレジストラＣＳＥ ７０６に送信され、ＡＥレジストラＣＳＥ ７０６は、次いでＡＥ ７０８へ応答をリターゲティングすることに留意されたい。

サービス層は、発信者が一式の宛先リソースにグループ要求を送信するのを助けることができる。これらの宛先リソースは、典型的には同じタイプであるが、リソースタイプの混在も可能であることが想定されている。一例として、グループを作成して、一操作がいくつかの＜ＡＥ＞リソースにファンアウトできるようにすることができる。

これを達成するために、＜ｇｒｏｕｐ＞リソースは、グループホスティングＣＳＥで作成される必要がある。＜ｇｒｏｕｐ＞リソースには、グループのすべてのメンバーのリソースＩＤのリストが含まれている（ｍｅｍｂｅｒＩＤｓ属性に含まれている）。グループの作成時に、グループホスティングＣＳＥは、グループリソースの子として仮想リソース（＜ｆａｎＯｕｔＰｏｉｎｔ＞）を作成する。その後、発信者は、仮想＜ｆａｎＯｕｔＰｏｉｎｔ＞リソースをターゲットとする要求操作を送信することができ、グループホスティングＣＳＥは、発信者に代わって、グループの個々のメンバー（ｍｅｍｂｅｒＩＤｓ属性にリストされたもの）に要求をファンアウトする。ファンアウトされた要求のそれぞれからの応答を受信すると、グループホスティングＣＳＥは、発信者に応答する前に、結果を集約する。

サービス層は、発信者がリモートＣＳＥにリソースをアナウンスするのを助けることができる。発信者がホスティングＣＳＥ上で元のリソースを作成した場合、それはこのリソースがリモートＣＳＥにアナウンスされることを要求できる。リモートＣＳＥで作成されたリソースは、アナウンスされたリソースと呼ばれる。アナウンスされたリソースは、元のリソース属性のミラーである一式の属性を持つことができ、独自の属性、特に元のリソースを指す「ｌｉｎｋ」属性を持つこともできる。リソースを発表することには、主に２つの目的がある：
１）発見を助ける－アナウンスされたリソースを通じて、元のリソースが発見され得る。実際、ｏｎｅＭ２Ｍは、「ｌｉｎｋ」属性を通じて、リモートＣＳＥにより元のリソースを取得できるため、これをさらに一歩進めている。この場合、ホスティングＣＳＥの元のリソースを取得するのはリモートＣＳＥの役割である。
２）リモートＣＳＥでの属性のミラーリング－これらの属性は、リモートＣＳＥから直接取得できる。元のホスティングＣＳＥとリモートＣＳＥとの属性が同期していることを確実にするのは、元のホスティングＣＳＥの役割である。

ＡＥ、コンテナ、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ、グループ、およびリモートＣＳＥを含む、いくつかのリソースタイプをアナウンスできる。

モビリティ管理は、学術界および産業界で非常に活発に研究されている分野であり、主に、モバイルデバイスの急増とこれらのデバイスを使用するユーザの要求に対処するためのものである。モビリティ管理により以下が可能になる：
・位置管理：ネットワークが移動体の接続点を特定して、この移動体にトラフィックを配信することを可能にする。
・ハンドオフ管理：接続点を変更し続けている間、移動体がその接続を維持することを可能にする。

図９は、モバイルノードが、その接続点を、ＷＣＤＭＡ（登録商標）基地局ではなく、あるＬＴＥ基地局から別のＬＴＥ基地局へと変え、最後にＷｉ－Ｆｉ（登録商標）アクセスポイントへと変えるときの、モバイルノードの一例を示す。

モビリティ管理は、プロトコルスタックの多くの異なる層で処理され得る。例えば、モビリティ管理は、ＩＰへの拡張を通じて、ネットワーク層で処理され得る、および／または移動体がその接続点を変えるときに移動体への接続を維持するために無線アクセスネットワークに依拠するメカニズムを通じて、リンク層で処理され得る。以下、両方のメカニズム、ならびにモビリティアンカーの使用に依拠しない手法である分散モビリティ管理（ＤＭＭ）について説明する。

モバイルＩＰ（ＭＩＰ）の背後にある基本原理は、モバイルノード（ＭＮ）にそのＩＰアドレスを保存させるが、ホームネットワークから外部ネットワークへ移動するときに気付けアドレス（ＣｏＡ）を使用することである。各ネットワークでは、移動体はルータ（ホームルータまたは外部ルータ）を介して通信する。新しい機能を実装するには、３つの主な機能が必要である：

ルータ（エージェント）発見：ルータが周期的に自分の存在を告知する、またはモバイルノードがこれらのルータを発見するために告知要請を送信できる。ルータが外部ネットワーク上にあることをモバイルノードが発見した場合、外部ルータはルータにＣｏＡを割り当てる。

登録：モバイルノードは、そのホームルータにそのＣｏＡを登録し、ホームルータはその後、そのモビリティバインディングテーブルを変更する。同時に、外部エージェントルータは、訪問先モバイルノードのリスト－訪問者リストを保持する。

転送：モバイルノードが出ていくトラフィックの場合、これは通常のＩＰルーティングに従う。
モバイルノードが入ってくるトラフィックの場合、データはまずモバイルノードのホームルータに送信され、ホームルータは通信のアンカーとして機能する。ホームルータは、モビリティバインディングテーブルを使用して、モバイルノードが外部ネットワーク内にあることを判定する。モバイルノードは、自身と外部ルータとの間に作成されたトンネルを介してＣｏＡにデータを送信する。外部ルータは、それが維持しているビジターリストと相互参照することによってモバイルノードがそのローカルネットワーク上にあることを判定し、次いでトラフィックをモバイルノードに配信する。

後述するように、ＭＩＰは、モバイルノードとルータ／エージェントとの両方に対する変更を要求する。すべての変更をネットワーク側に移そうという強力なオペレータの後押しがあった。モバイルＩＰｖ６（ＭＩＰｖ６）に基づくＰＭＩＰｖ６は、ホームルータの概念を再利用するが、モバイルノードに代わってモバイルノードの位置の変化をシグナリングしなければならないネットワーク内のノードを定義する。モバイルアクセスゲートウェイ（ＭＡＧ）は、そのアクセスリンクに接続されているモバイルノードに代わってモビリティ関連のシグナリングを実行する。コアネットワーク内のローカルモビリティアンカー（ＬＭＡ）は、モビリティドメインに接続されている各モバイルノードについての経路の集合を維持する。これは、ＭＮ宛てのトラフィックのアンカーポイントである。

ＭＮは、ルータ要請を使用して最初のＭＡＧに接続する。次いで、ＭＡＧは、そのアドレスをＭＮの識別情報に関連付けることをＬＭＡに通知する。ＬＭＡは、ＭＮにプレフィックスを割り当て、ＭＡＧとのトンネルを確立する。ＭＡＧは、ＭＮがそのアドレスを構成できるように、プレフィックスをＭＮに転送する。

ＭＮが移動して新しいＭＡＧにコンタクトすると、新しいＭＡＧは、新しいＭＮ位置によりＬＭＡを更新する。新しいＭＡＧはまた、ＭＮに同じプレフィックスを告知する－従ってＭＮは移動するときに同じアドレスを有する。

外部からモバイルノードに送信されたダウンリンクパケットはＬＭＡに到着し、ＬＭＡはトンネルを介してそれらをサービングＭＡＧに転送する。ＭＡＧは、アクセスリンクを介してパケットをモバイルノードに直接送信する。

モバイルノードから発信されたアップリンクパケットは、トンネルを介してＭＡＧからＬＭＡに送信され、次いでＬＭＡはパケットを宛先に転送する。

ＬＴＥネットワークでは、モビリティはモバイル支援型であるがネットワーク制御型である。モバイルノードがその接続点を１つのソース基地局からターゲット基地局に変更するときに、モビリティが発生する。２つの基地局が同じサービングゲートウェイ（Ｓ－ＧＷ）に属する場合、ＬＴＥはリンク層モビリティに依拠する。基本的な前提は、ソース基地局からターゲット基地局へトラフィックを転送するためのアンカーポイントとしてＳ－ＧＷを使用することである。このことは、次の基本ステップで可能となる：

ステップ１：移動体は、ソース基地局に測定値を提供し、これがハンドオーバをトリガすることができる。

ステップ２：ソース基地局は、モバイルコンテキストをターゲット基地局に転送し、ソース基地局とターゲット基地局との間でデータトラフィックを転送することによって、ハンドオーバを準備する。

ステップ３：ソース基地局は、ハンドオーバを実行するように移動体に通知し、その時点で移動体はソース基地局から切断され、ターゲット基地局に接続する。一旦接続されると、移動体はターゲット基地局へのハンドオーバ要求を確認する。

ステップ４：転送中に、Ｓ－ＧＷは、トラフィックをソース基地局に移動させ、次いでターゲット基地局に移動させるモビリティアンカーポイントとして機能する。

ネットワーク層モビリティおよびリンク層モビリティ（ＬＴＥネットワーク）で説明されているすべての解決策は、少なくとも次の態様を共有している。
・セッション識別子と転送との間のマッピングが保たれることに関する位置情報は、単一のモビリティアンカーである。
・このセッション識別子宛てのパケットは、このアンカーによって転送される。

以下の理由から、集中管理に代わるものを見つけるためのＩＥＴＦの取り組みがあることが、本明細書では認識されている。
・これらのアンカーポイントは、集中する部分（ｆｕｎｎｅｌ）になる－ネットワークにはほとんどなく、それらは高負荷になり得る。
・これらのアンカーポイントは、単一障害点となる。および／または
・多くの場合、ネットワークはよりフラットになっている－それらは階層的配備ではなくなっている。

その結果、ＩＥＴＦは、モビリティ管理機能が複数のネットワークに分散されるＤＭＭを開発し、それによって、適切な転送管理機能（ＦＭＣ）を有する近くの機能によってモバイルノードがサービスされることを可能にする。

ｏｎｅＭ２Ｍ－ＴＳ－０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ－Ｖ－２．６．０

Ｍ２Ｍサービス層によって提供されるいくつかのサービスは、アプリケーションと相互作用するために使用されるコンタクト情報を有する。例えば、サービス層は、アプリケーションに通知メッセージを送信する必要がある場合がある。これを行うために、サービス層は、アプリケーションへの到達方法を知るために、格納されたコンタクト情報に依拠する。アプリケーションをホストしているデバイスが移動し、アプリケーションがそのコンタクト情報を変更した場合、サービス層にあるコンタクト情報は古くなっている。その結果、これらのサービスは非効率的になり、場合によってはまったく役に立たなくなる。

とりわけ上記の問題に対処するためのメカニズム、およびＭ２Ｍサービス層において古いコンタクト情報を更新するためのメカニズムについて以下に説明する。これを行うために、メカニズムは新しいコンタクト情報を伝播させるためにＭ２Ｍサーバに依拠し得る。問題および解決策は、移動するアプリケーションエンティティ（ＡＥ）に関して提供されているが、サービス層が移動してそのコンタクト情報を変更し得る場合にも適用可能である。

サービス層において古いＡＥコンタクト情報を処理するために本明細書に導入されたシステムおよび方法は、非限定的な例において、以下に簡単に要約される：
・Ｍ２Ｍサーバが再登録の試みをＡＥモビリティイベントとして評価し、アクティブ／進行中のＭ２Ｍサービスを転送し、すべてのローカルＡＥコンタクト情報を更新し、ＡＥコンタクト情報の変更について他のすべてのサービス層に通知するメカニズム。
・ローカルサービス層が再登録の試みをＡＥモビリティイベントとして評価し、コンタクト情報の変更をＭ２Ｍサーバに通知するメカニズム。
・ＡＥコンタクト情報に基づく検索基準を用いた修正された発見方法。
・ローカルサービス層がすべてのＡＥコンタクト情報を有するリソースを維持するメカニズム。
・Ｍ２Ｍサーバが各サービス層のすべてのＡＥコンタクト情報のマスターリストを維持するメカニズム。Ｍ２Ｍサーバは、サービス層に対する追加および削除要求に基づいてこのリストを更新する。
・発信者がリソースに結び付けられていないイベントの監視を要求できる拡張されたサブスクリプションメカニズム。例えば、ＡＥモビリティイベント。

加えて、本出願はまた、これらのメカニズムおよび拡張したものをｏｎｅＭ２Ｍに実装するための実施形態を含み、ＡＥコンタクト情報を監視／表示し、上記のメカニズムのうちのいくつかをトリガすることを可能にするグラフィカルユーザインターフェースを提供する。

この「発明の概要」は、以下の「発明を実施するための形態」でさらに説明される一連の概念を簡略化した形で導入するために提供される。この「発明の概要」は、特許請求の範囲に記載の主題の重要な特徴または本質的な特徴を特定することを意図するものでもないし、特許請求の範囲に記載の主題の範囲を限定するために使用されることを意図するものでもない。さらに、特許請求の範囲に記載の主題は、本開示の任意の部分に示されるありとあらゆる欠点を解決する制限に限定されない。

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

サービス層をサポートする例示的なプロトコルスタックを説明する図である。 分散型Ｍ２Ｍサービスを用いた典型的なＭ２Ｍ配備を説明する図である。 共通サービス機能を説明する図である。 ｏｎｅＭ２Ｍリソース指向アーキテクチャを説明する図である。 リソースＩＤを説明する図である。 リソース、エンティティ、およびＡＥリターゲティングを説明する図である。 リソース、エンティティ、およびＡＥリターゲティングを説明する図である。 サブスクライブ／通知を説明する図である。 非ブロッキング非同期要求を説明する図である。 モビリティ管理を説明する図である。 モビリティ管理の概要を説明する図である。 アラートを用いたヘルスモニタリングを説明する図である。 グループファームウェアアップグレードを説明する図である。 移動するＡＥへの通知ターゲットを説明する図である。 サービスプロバイダがＡＥ－ＩＤを割り当てるケース１を説明する図である。 ローカルサービス層がＡＥ－ＩＤを割り当てるケース２を説明する図である。 発見の影響を受けるサービス層を説明する図である。 Ｍ２Ｍサーバにおけるマスターリストを説明する図である。 ＡＥモビリティイベントへのサブスクライブを説明する図である。 新しいモビリティ（ＭＯＢ）ＣＳＦを説明する図である。 新しい＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースを説明する図である。 新しい＜ａｅＣｏｎｔａｃｔＬｉｓｔ＞リソースを説明する図である。 ＣＳＥのためのグラフィカルユーザインターフェースを説明する図である。 １つまたは複数の開示されている実施形態を実施することができる例示的なマシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムのシステム図である。 図２３Ａで説明されたＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム内で使用され得る例示的なアーキテクチャのシステム図である。 図２３Ａおよび図２３Ｂで説明される通信システム内で使用され得るＭ２Ｍ／ＩｏＴ／ＷｏＴデバイス、ゲートウェイ、またはサーバなどの例示的な通信ネットワークノードのシステム図である。 図２３Ａおよび図２３Ｂの通信システムのノードを具体化することができる例示的なコンピューティングシステムのブロック図である。

別段の指定のない限り、本明細書では以下の定義を使用する。

別段の指定のない限り、本明細書では以下の略語を使用する。
ＡＤＮ アプリケーション専用ノード
ＡＥ アプリケーションエンティティ
ＡＰＩ アプリケーションプログラミングインターフェース
Ａｐｐ アプリケーション
ＡＳＭ アプリケーションおよびサービス層の管理
ＡＳＮ アプリケーションサービスノード
ＣＭＤＨ コミュニケーション管理および配信処理
ＣＳＥ 共通サービスエンティティ
ＣＳＦ 共通サービス機能
ＤＩＳ 発見
ＤＭＲ データ管理および蓄積
ＩＮ インフラストラクチャノード
ＩｏＴ モノのインターネット
ＩＰ インターネットプロトコル
ＬＯＣ ロケーション
Ｍ２Ｍ マシンツーマシン
ＭＮ ミドルノード
ＭＯＢ モビリティ
ＮＳＥ 基礎となるネットワークサービスエンティティ
ＮＳＳＥ ネットワークサービス連携（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ｅｘｐｏｓｕｒｅ，Ｓｅｒｖｉｃｅ Ｅｘｅｃｕｔｉｏｎ ａｎｄ Ｔｒｉｇｇｅｒｉｎｇ）
ＲＥＧ 登録
ＲＯＡ リソース指向アーキテクチャ
ＳＣ サービス能力
ＳＣＡ サービス課金および管理（Ｓｅｒｖｉｃｅ Ｃｈａｒｇｉｎｇ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）
ＳＥＣ セキュリティ
ＳＯＡ サービス指向アーキテクチャ
ＳＵＢ サブスクリプションおよび通知
ＵＤＰ ユーザデータグラムプロトコル
ＵＲＩ 統一資源識別子

以下の説明は、モバイルＭ２Ｍアプリケーションがサービス層によって提供されるサービスを利用する２つの例示的なユースケースを示す。これらのアプリケーションは、ローカルサービス層、ならびに潜在的にいくつかのリモートサービス層から、Ｍ２Ｍサービスを取得すると仮定される。

第１のユースケース例は、リモートヘルスモニタリングに関するものであり、図１１に示されている。図１１に示すユースケースでは、高齢者介護施設の２人の医師（医師Ａおよび医師Ｂ）が、患者（患者Ａ）の血糖値を心配している。情報は患者の身体センサによって収集され、ローカルのゲートウェイに格納される。加えて、この情報は、設定された閾値などに基づいてアラートを提供するＷｅＭｏｎｉｔｏｒという健康モニタリング会社にも送信される。患者の状態を見るために、医師は、インストールされた一組のＭ２Ｍ健康アプリケーションによりタブレットを使用する。彼らが高齢者介護施設を移動するにつれて、彼らのタブレットは異なるゲートウェイに接続する。

両医師とも、以下のいずれかの場合には通知するように、ＷｅＭｏｎｉｔｏｒに要求している。
・患者Ａの血糖値が４０ｍｇ／ｄｌよりも下に下がった場合、または
・患者Ａの心拍数が著しく上昇した場合。

ＷｅＭｏｎｉｔｏｒは高齢者介護施設内における各医師の位置を追跡していないため、両医師とも、彼らのホームオフィスのゲートウェイを通じてのみ通知を受けるように要求している。これは、ｏｎｅＭ２Ｍサービス層がＡＥにＡＥのレジストラＣＳＥに基づいて通知を送信する方法と一致している。時間ｔ１において、患者Ａの血糖値が閾値を下回る。両医師とも各自のオフィスにいるため、医師らはアラーム／通知を受け取ることができる。幸いなことに、両医師とも患者を往診し、必要な薬を処方する－何も問題はない。その日の後に（時刻ｔ２）なって、患者の心拍数が上昇し始める。医師Ｂは、まだ自らのオフィスにいるが、医師Ａは、カンファレンスルームにいて、ミーティングに参加している。医師Ｂは自らのオフィスのゲートウェイ上にいないため、彼は通知を受け取らない。

第２のユースケース例は、グループファームウェアのアップグレードに関するものである。ある会社がいくつかの既製のセンサを購入し、それらを工場に設置したいと考えている。設置した時点で、使用前に、同社はすべてのデバイスが同じソフトウェアバージョンを稼働していることを保証するためにファームウェアアップグレードをしたいと考えている。これらのデバイスは通信範囲が限られており、最も近いゲートウェイと通信する。これらのゲートウェイのそれぞれは、センサにＭ２Ｍサービスを提供する。最初の起動時に、デバイスは最も近いゲートウェイに接続して登録する。これで、デバイスはＭ２Ｍサービスを利用する準備ができている。同社は、アップグレードをより効率的にするために、サービス層のグループ機能を利用したいと考えている。同社は、各センサがどこに登録されているかを知っているため、すべてのセンサを含むグループを作成してから、ファームウェアのアップグレードを送信する。サービス層グループ機能は、ファームウェアアップグレードを個々のデバイスに配信する役割を果たす。
数ヵ月後、新しいパッチが入手可能になり、同社はこれを自社のすべてのセンサに適用したいと考えている。その間、一部のセンサは移動され、異なるゲートウェイに接続されている。例えば、図１２は、２つのデバイス（ｓｅｎｓ３およびｓｅｎｓ４）がゲートウェイ１に接続されなくなったが、今ではゲートウェイ２に接続されるようになった場合を示している。この場合、同じグループを使用してファームウェアアップグレード＃２を送信すると、２台のデバイスはアップグレードされない。

上記の両方のユースケースは、Ｍ２Ｍアプリケーションをターゲットとした相互作用を含む典型的なユースケースを示している。これは、Ｍ２Ｍ空間では極めて一般的なことと予想される。ただし、サービス層（特にｏｎｅＭ２Ｍ）を使用すると、上記のユースケースでいくつかの問題が発生する。サービス層を開発する際の原則の１つは、アプリケーションにかかる負担の一部を軽減することである。その意図は、これらのアプリケーションがそれらがサービス層からサービスを要求することを可能にするＡＰＩを持つことである。結果として、アプリケーションは、通常、サービス層に登録して、それらが提供するＭ２Ｍサービスを使用する。

残念ながら、このプロセスではいくつかの問題が発生し、理由は以下のとおりである：
１）アプリケーションは、Ｍ２Ｍサービスを取得するためにサービス層に登録しなければならない。
２）アプリケーションが移動するにつれて、それらは異なるサービス層に再登録しなければならない場合がある（例えば近接性のため）。
３）アプリケーションは登録地点を通じてコンタクトされる。
４）いくつかのサービスはアプリケーションにコンタクトする方法を持つ必要がある。

特にｏｎｅＭ２Ｍの場合、アプリケーションがＣＳＥに登録すると、そのＣＳＥに＜ＡＥ＞リソースが作成される。＜ＡＥ＞リソース、またはその子リソースのいずれかは、このリソースを一意に識別するＵＲＩを介して参照される。このＵＲＩは階層的または非階層的（ｒｅｓｏｕｒｃｅＩＤを使用）であり得る。このＵＲＩは、リモートＣＳＥでホストされているリソースの属性として存在する場合があり、これにより、リモートＣＳＥは＜ＡＥ＞にサービスを提供できる。非限定的な例では、以下のサービスが提供され得る：
・アナウンスサービス：元の＜ＡＥ＞リソースを指す「ｌｉｎｋ」属性を持つ。
・グループサービス：グループへのメッセージをファンアウトする場合、これらのグループメンバーのうちのいくつかはＡＥに関連している場合がある。例えば、グループメンバーは、＜ＡＥ＞リソースのｒｅｓｏｕｒｃｅＩＤまたは＜ＡＥ＞リソースの子リソースであり得る。
・サブスクライブ／通知サービス：サブスクライブ／通知の一部として、加入者は通知対象として＜ＡＥ＞リソースを指定することができる。
・ポーリングサービスおよびリターゲティング：ＡＥの登録点に依拠する。

背景技術のセクションで述べたように、Ｍ２Ｍサービスは、様々なエンティティ（ミドルノード、ゲートウェイ、デバイスサーバなど）内のサービス層に分散させることができる。これらのサービス層内で、いくつかのＭ２Ｍサービスは、アプリケーションを参照するコンタクト情報を有する。アプリケーションが登録点を変更した場合、そのコンタクト情報が変更され、その結果、サービス層に格納されているコンタクト情報は無効になる。例えばｏｎｅＭ２Ｍでは、ＡＥが（同じまたは異なるＳＰドメイン内の）別のＣＳＥに「移動」して登録した場合、元のレジストラＣＳＥでホストされている＜ＡＥ＞リソース（またはその子リソースのうちの１つ）を参照するサービスは、今や古いＵＲＩ情報を持つ（ＵＲＩで使用されているＣＳＥ－ＩＤおよび潜在的にＳＰ－ＩＤが変更されている可能性があるため）。このことにより、Ｍ２Ｍサービスが非効率的になり、場合によっては役に立たなくなる。

図１３は、ｏｎｅＭ２Ｍのサブスクライブ／通知サービスの問題を示している。ＡＥ １３０２は既にＣＳＥ１に登録されていると仮定する。さらに、ＩＮ－ＣＳＥ上でホストされているリソース／ｒｅｓ１へのリモートサブスクリプションがあると仮定する。ＣＳＥ１上の＜ＡＥ＞子リソースは、サブスクリプションの通知ターゲットのうちの１つとして含まれている。時間１において、／ｒｅｓ１に変更がある。ＩＮ－ＣＳＥのサブスクリプションサービスは通知を生成し、ＣＳＥ１を通じてＡＥに送信する。時間２において、ＡＥは、ＣＳＥ１ １３０４への接続が切れ、ＣＳＥ３ １３０６に接続する。ＡＥは、ＣＳＥ３ １３０６に登録し、今やＣＳＥ３ １３０６を通じてのみ到達することができる。また、ＣＳＥ３ １３０６への接続の結果として、ＡＥがそのネットワークアドレスを変更すると仮定する。時間３において、／ｒｅｓ１に別の変更がある。ＩＮ－ＣＳＥは、ＣＳＥ１を通じてＡＥに通知を送信しようと試みる（時間４）が、ここで、この通知をＡＥ １３０２にリターゲティングすることはできない。まとめると、ＡＥがＣＳＥ１に登録されている場合は、次のようになる：
・ＣＳＥ１ １３０４の古い＜ＡＥ＞リソースは移動できず、
・ＡＥが移動した場合、ＣＳＥ３ １３０６上に新しい＜ＡＥ＞リソースが作成され、
・ただし、通知は常に古い＜ＡＥ＞リソースに関連付けられている。

以下、とりわけ、アプリケーションモビリティから生じる問題に対する２つの解決策を説明する。第１の解決策は、アプリケーションが自らをＭ２Ｍサーバにアナウンスする場合に適用することができ、登録時にアプリケーションエンティティに一意の識別子（ＡＥ－ＩＤ）を提供するのはＭ２Ｍサーバである。このＡＥ－ＩＤはサービスプロバイダドメイン内で一意である。第２の解決策は、Ｍ２Ｍサーバがアプリケーションを認識さえしていない場合に適用され、ローカルサービス層（例えばゲートウェイ）がアプリケーションに識別子（ＡＥ－ＩＤ）を提供する。このＡＥ－ＩＤはローカルサービス層内でのみ一意である。サービスプロバイダドメイン内では必ずしも一意ではない場合がある。どちらの場合も、主なアイデアは、Ｍ２ＭサーバにＡＥモビリティイベントが発生したと判定させ、プロアクティブなアクションをとらせることである。

以下、「ＡＥモビリティイベント」という用語は、アプリケーションがその登録点を１つのサービス層から別のサービス層に変更する、または登録点のトランスポート層アドレスが変更される（すなわち、ＩＰアドレス変更）、あらゆるイベントを表すために使用される。これは、例えば以下の理由で発生し得る：
・モビリティ：アプリケーションが新しいＣＳＥ（サービス層エンティティ）に移動して登録する、
・無線干渉：アプリケーションが１つのサービス層への接続性を切り、代替のサービス層を見つける、および／または
・プロファイル／ポリシーベース：アプリケーションが何らかのポリシーに基づいてサービス層を変更する。例えば：
・１日のうちの時間、
・基礎となるネットワーク接続（例えば、両方が利用可能な場合には、エンティティはセルラー方式よりもＷｉ－Ｆｉ（登録商標）を選択し得る）、および／または
・利用可能な電力（より少ない送信電力を使用することになるサービス層を選択する）。

アプリケーションは、ＡＥモビリティイベントを経た場合に、サービス層がプロアクティブなアクションをとることを望むか否かを選択することができると仮定される。場合によっては、アプリケーションは、ローカルサービス層からのサービスだけを望む場合がある。結果として、アプリケーションは、ＡＥモビリティイベントの結果としてリモートサービス層のサービスが非効率であるか役に立たないかに関心を持っていない。アプリケーションは、サービス層がＡＥモビリティイベントに反応することを望むか否かを指定するために、サービス層へのその登録メッセージにインジケータを含めることができる。例えば、アプリケーションは、その登録要求にｌｏｃａｌＲｅｇｉｓｔｒａｔｉｏｎパラメータを含めることができる。ＴＲＵＥに設定されている場合、アプリケーションは、検出されたＡＥモビリティイベントが発生した場合にサービス層がプロアクティブなアクションを実行しないことを要求している。ＦＡＬＳＥまたはＮＵＬＬに設定されている場合、アプリケーションは、ＡＥモビリティイベントを経た場合に、サービス層がアプリケーションを支援することを要求している。あるいは、アプリケーションは、ｌｏｃａｌＲｅｇｉｓｔｒａｔｉｏｎと同様の役割を持つ別のフラグを含めることができる。例えば、ｔｒａｃｋＲｅｇｉｓｔｒａｔｉｏｎＰｏｉｎｔｓパラメータである。ＦＡＬＳＥに設定されている場合、アプリケーションは、検出されたＡＥモビリティイベントが発生した場合にサービス層がプロアクティブなアクションを実行しないことを要求している。ＴＲＵＥまたはＮＵＬＬに設定されている場合、アプリケーションは、ＡＥモビリティイベントを経た場合に、サービス層がアプリケーションを支援することを要求している。

さらに、「ＡＥコンタクト情報」という用語は、＜ＡＥ＞リソース（またはその子リソースのうちの１つ）のＵＲＩを指すために使用される。ＡＥコンタクト情報は、階層的ＵＲＩまたは非階層的ＵＲＩ（リソースＩＤを使用）であり得る。ｏｎｅＭ２Ｍでは、ＡＥコンタクト情報は、アプリケーション登録中に作成された＜ＡＥ＞リソースを通じて、アプリケーションが登録されているサービス層に関連付けられる。ＡＥが新しいサービス層に再登録する場合、そのＡＥコンタクト情報は変わり得る。サービス層は、例えば以下の中にＡＥコンタクト情報を有することができる：
１）＜ＡＥ＞リソースまたは＜ＡＥ＞子リソースのいずれかを指すリンク属性をアナウンスする、
２）＜ＡＥ＞リソースを指す通知ターゲットのリストを格納する（何らかのサブスクリプションまたは何らかの非ブロック非同期要求による）、および／または
３）グループメンバーとして＜ＡＥ＞リソース（またはその子リソースのうちの１つ）を含む（ｍｅｍｂｅｒＩＤリストに格納されている）メンバーシップをグループ化する。

本明細書で説明される解決策は、ＡＥモビリティの観点から書かれていることを理解されたい。しかしながら、ＳＬをホストするノードが移動し、ＳＬが異なるサービス層に登録するため、同じ解決策がＳＬモビリティに適用されてもよい。

第１の例示的な実施形態、ケース１では、Ｍ２Ｍサーバは、ＡＥ登録を把握し得る。全体の流れを図１４に示す。強調表示されているステップには番号が付けられ、以下に説明されている。３つのローカルサービス層（ゲートウェイ１内のＳＬ１ １４０４、ゲートウェイ２内のＳＬ２ １４０６、およびゲートウェイ３内のＳＬ３ １４０８）があり、これらは既にＭ２Ｍサーバに登録されていると仮定することに留意されたい。

図１４のステップ１において、アプリケーション１ １４０２は、ゲートウェイ１ １４０４においてローカルサービス層に接続して登録し、この初期登録の一部として、アプリケーション１ １４０４は、その存在をＭ２Ｍサーバ１４１０においてアナウンスすることと、その識別子（ＡＥ－ＩＤ）をＭ２Ｍサーバ１４１０によって割り当てることと、を求める。Ｍ２Ｍサーバ１４１０は、アプリケーション１４０２に対するアナウンスメントを作成し、サービスプロバイダに一意のＡＥ－ＩＤを割り当てる。ｏｎｅＭ２Ｍでは、アナウンスメントは、Ｍ２Ｍサーバ１４１０でアナウンスされたリソースを作成することによって達成され、ＡＥ－ＩＤは、それがＭ２Ｍサーバ１４１０によって提供されることをシグナリングするためにプレフィックス「Ｓ」を有する。

図１４のステップ２において、アプリケーション１ １４０２は、いくつかのアクティブ／進行中のＭ２Ｍサービスを使用し始める。例えば：
・アプリケーション１ １４０２は、その存在をアナウンスするために、Ｍ２Ｍサーバ１４１０および／またはＭ２Ｍゲートウェイ１４０４、１４０６、および１４０８内のサービス層を使用している場合がある。アナウンスメントには、アプリケーション１ １４０２へのリンクが含まれる。例えば、ｏｎｅＭ２Ｍでは、これは、より具体的には、ゲートウェイ１ １４０４におけるサービス層によってホストされているアプリケーションリソース（＜ＡＥ＞）に戻るリンクである。
・アプリケーション１ １４０２は、（Ｍ２Ｍサーバ１４１０および／または別のＭ２Ｍゲートウェイで）サービス層のサブスクリプション／通知サービスを使用している場合がある。例えば、アプリケーション１ １４０２は、サービスプロバイダドメイン内にあるが、それ自体とは異なるゲートウェイ上で、またはＭ２Ｍサーバ上でホストされている何らかのサービス層リソースが変化したときに通知され得る。
・アプリケーション１ １４０２は、（Ｍ２Ｍサーバおよび／または別のＭ２Ｍゲートウェイで）サービス層のリモートグループを使用している場合がある。リモートグループは、そのメンバーのうちの１つとして、アプリケーション１ １４０２を含み得る。結果として、サービスをホストしているサービス層は、要求をアプリケーション１ １４０２にファンアウトする。

図１４のステップ３において、Ｍ２Ｍサーバ１４１０はまた、例えば、データストレージ、セマンティック検索（ｓｅｍａｎｔｉｃ ｄｉｓｃｏｖｅｒｙ）、ファンアウト機能、アクセス制御、およびサブスクライブ／通知サービスを含む、アプリケーション１ １４０２のアナウンスメントにおいてＭ２Ｍサービスを提供してもよい。

図１４のステップ４において、アプリケーション１ １４０２は移動してゲートウェイ１ １４０４への接続性を切り、ゲートウェイ２ １４０６を見つける。

図１４のステップ５において、アプリケーション１ １４０２は、ゲートウェイ２サービス層との再登録手順を開始する。再登録の一部として、アプリケーション１４０２は、そのサービスプロバイダに固有のＡＥ－ＩＤ（ｏｎｅＭ２Ｍではプレフィックス「Ｓ」を伴う）を供給し、その存在がＭ２Ｍサーバ１４１０でアナウンスされることを再度求める。ゲートウェイ２ １４０６は、これが、ａ）以前の登録からＡＥ－ＩＤがサービスプロバイダによって提供されていることから、再登録要求であり、ｂ）未知のアプリケーションからの要求であることに気付く。これら２つの条件により、ゲートウェイ２ １４０６は、要求がモビリティイベントの結果であり得ると判定することができる。結果として、それはＭ２Ｍサーバ１４１０においてアプリケーションのための新しいアナウンスメントを作成する。

ＡＥ－ＩＤがアプリケーション１４０２内に事前プロビジョニングされている場合、アプリケーション１４０２は、これが初期登録であるか再登録であるかを示すために、サービス層に別のインジケータを供給することができることに留意されたい。例えば、アプリケーション１４０２は、登録要求にｉｎｉｔｉａｌＲｅｇｉｓｔｒａｔｉｏｎ指示を含み得る（これが事前プロビジョニングされたＡＥ－ＩＤを用いた初期登録である場合にＴＲＵＥに設定され、初期登録でない場合にＦＡＬＳＥまたはＮＵＬＬに設定される）。あるいは、別のマーカをＡＥ－ＩＤ内で使用して、（例えば、「Ｐ」のプレフィックスでＡＥ－ＩＤを開始する）事前プロビジョニングされたＡＥ－ＩＤをシグナリングすることができる。別の代替策では、登録メッセージは、任意の以前の登録のＣＳＥ－ＩＤを示すための新しいフィールドを含み得る。例えば、ｐｒｉｏｒＲｅｇｉｓｔｒａｒＣＳＥＩＤフィールドにある。登録メッセージを受信すると、受信側ＣＳＥは、受信されたｐｒｉｏｒＲｅｇｉｓｔｒａｒＣＳＥＩＤフィールドを、それ自身のＣＳＥ－ＩＤと比較することができる。一致した場合、ＣＳＥはアプリケーションが同じＣＳＥに再登録しているとみなす。異なる場合、受信側ＣＳＥは、アプリケーションが新しいＣＳＥに再登録しているとみなす。ｐｒｉｏｒＲｅｇｉｓｔｒａｒＣＳＥＩＤがＮＵＬＬの場合、受信側ＣＳＥはこれが初期登録であるとみなす。

図１４のステップ６において、Ｍ２Ｍサーバ１４１０は、（ステップ１からの）以前に割り当てられたＡＥ－ＩＤを使用しているか否かをチェックするために新しいアプリケーションアナウンスメントを調べ、（アプリケーション１４０２がＡＥ－ＩＤが提供されたＭ２Ｍサーバを供給しているため）アプリケーション１４０２が新しいサービス層で再登録していると判定する（要求が以前のアナウンスメントを更新するのではなく、新しいアナウンスメントを作成しようとしているため）。Ｍ２Ｍサーバ１４１０は新しいアナウンスメントを作成する。

図１４のステップ７において、Ｍ２Ｍサーバ１４１０は、ＳＬ１登録アナウンスメントに関連付けられたあらゆるアクティブ／進行中のサービスをＳＬ２登録アナウンスメントに移動する。これは、Ｍ２Ｍサーバ１４１０がＳＬ１登録アナウンスメントに提供するサービスはいずれもＳＬ２登録アナウンスメントに転送されるべきであることを意味する。これには、例えば、データストレージ、サブスクリプション／通知、グループ管理、アクセス制御管理、およびセマンティック検索に関連するサービスが含まれる。転送は、ＳＬ１登録アナウンスメントに関連する進行中のサービスを中断し、ＳＬ１登録アナウンスメントからＳＬ２登録アナウンスメントに関連するリソースをコピーし、ＳＬ２登録アナウンスメントに関連する進行中のサービスを再開することを含む。特に、Ｍ２Ｍサーバは、ＳＬ１ １４０４からのアナウンスされたＡＥリソース（Ｍ２Ｍサーバ１４１０でホストされている）の下に格納されている様々な子リソースを、ＳＬ２ １４０６（同じくＭ２Ｍサーバ１４１０でホストされている）からのアナウンスされたＡＥリソースにコピーする。例えばｏｎｅＭ２Ｍでは、アナウンスされたＡＥリソース＜ＡＥＡｎｎｃ＞は、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞、＜ｓｅｍａｎｔｉｃＤｅｓｃｒｉｐｔｏｒ＞、＜ｃｏｎｔａｉｎｅｒ＞、＜ｆｌｅｘＣｏｎｔａｉｎｅｒ＞、＜ｇｒｏｕｐ＞、および＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞という子リソースが含まれ得る。これらのリソースは、ＳＬ２ １４０６からアナウンスされたＡＥリソースにコピーされてもよい。

あるいは、Ｍ２Ｍサーバ１４１０は、両方の登録アナウンスメントを維持し、ＳＬ１アナウンスメントからＳＬ２アナウンスメントを指す新しいリンク属性を有することができる。Ｍ２Ｍサーバ１４１０は、モビリティイベントを検出すると、ＳＬ２アナウンスメントを指すようにＳＬ１アナウンスメント内の新しいリンク属性を更新することができる。次いで、Ｍ２Ｍサーバ１４１０は、ＳＬ１アナウンスメントへの参照を受信するときはいつでも、ＳＬ２アナウンスメントを指すＳＬ１リンクを取得することができる。

図１４のステップ８では、ＳＬ１登録アナウンスメントを「無効にする」。これはいくつかの方法で行うことができる。例えば、ＳＬ１登録アナウンスメントは削除されてもよい。あるいは、ＳＬ１アナウンスメントは中断され、このアナウンスメントは最終的に有効期限切れになる。あるいは、Ｍ２Ｍサーバ１４１０は、古い登録アナウンスメントを保持してもよいが、アプリケーション１４０２とのあらゆる対話のために常に（最後の修正時刻または作成時刻に基づいて）最新の登録アナウンスメントを使用する。

図１４のステップ９において、アプリケーション１４０２は、もはやＳＬ１ １４０４に登録されていないため、Ｍ２Ｍサーバ１４１０は、例えばＤＥＬＥＴＥ／ＣＳＥ１／Ｓ＿ＡＥ１を通じて、ＳＬ１ １４０４から任意のアプリケーション関連コンテキストをプロアクティブに削除することができる。Ｍ２Ｍサーバ１４１０は、新しいｒｅｑｕｅｓｔＣａｕｓｅパラメータで削除の理由を提供することができる。このコールフローでは、ｒｅｑｕｅｓｔＣａｕｓｅを「ＵＥモビリティイベント」に設定できる。

あるいは、Ｍ２Ｍサーバ１４１０は、ＳＬ１ １４０４において＜ＡＥ＞リソースを無効にする、または一時停止することができる。事実上、これは＜ＡＥ＞リソースに関連付けられているサービスを一時停止するが、ＳＬ１ １４０４がこのリソースに関連したコンテキストを保持できるようにする。結果として、ＡＥが再び移動してＳＬ１ １４０４に再登録した場合には、ＳＬ１ １４０４は、このＡＥ １４０２を認識することになる。これは、ＳＬ１ １４０４がモバイルＡＥをより効率的に処理することを可能にし得る。例えば、ＳＬ１ １４０４がＭ２Ｍサーバ１４１０からこの情報を入手しなければならないことによるオーバーヘッドを減らすことができるように、ＳＬ１ １４０４は、ＡＥ １４０２に対するセキュリティ証明書を維持することができる。これは、ＡＥ １４０２がＣＳＥ間を定期的および／または反復的に移動する場合に役立つ。

図１４のステップ１０において、Ｍ２Ｍサーバ１４１０は、古い登録アナウンスメント（またはその関連する子リソースのうちの１つ）をターゲットとする、入ってくる要求を受信することができる。この場合、Ｍ２Ｍサーバ１４１０は、ＳＬ１登録アナウンスメントに送信された任意の要求をリターゲッティングすることができる。Ｍ２Ｍサーバ１４１０がＳＬ１登録アナウンスメントリソースまたはその子リソースのうちの１つに対する要求を受信するときはいつでも、Ｍ２Ｍサーバ１４１０は、これらをＳＬ２登録アナウンスメントリソースにリターゲッティングする。このリターゲティングの一部として、Ｍ２Ｍサーバ１４１０は、要求パラメータを変更することができる（例えば、宛先／ｔｏフィールドパラメータをＳＬ２登録アナウンスメントに変更する）。

図１４のステップ１１において、Ｍ２Ｍサーバ１４１０は、アプリケーション１４０２についてローカルに維持されているコンタクト情報を更新する。Ｍ２Ｍサーバ１４１０は、それがローカルに維持するすべての通知ターゲット、すべてのアナウンスメントリンク、およびすべてのグループメンバーＩＤ内のコンタクト情報を調べ、ＳＬ１ １４０４を指すあらゆるコンタクト情報を更新する。特に、Ｍ２Ｍサーバ１４１０は、ＳＬ１ １４０４のＣＳＥ－ＩＤをＳＬ２ １４０６のＣＳＥ－ＩＤに置き換えることによって、および必要に応じてＳＬ１ １４０４のＳＰ－ＩＤをＳＬ２ １４０６のＳＰ－ＩＤに置き換えることによって、＜ＡＥ＞リソースを参照するＵＲＩを更新する。

図１４のステップ１２において、Ｍ２Ｍサーバ１４１０は、ＡＥコンタクト情報の変更を、子サービス層および潜在的に他のサービスプロバイダドメイン上の他のＭ２Ｍサーバに伝播させる。Ｍ２Ｍサーバ１４１０が、アプリケーションモビリティによって影響を受けるサービス層を知っている場合、Ｍ２Ｍサーバ１４１０は個別にサービス層にコンタクトすることができる。あるいは、Ｍ２Ｍサーバ１４１０は、すべてのサービス層に要求をファンアウトして、アプリケーション１４０２のコンタクト情報を更新するようにそれらに知らせることができる。これは、ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑ／ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｓｐメッセージ交換を通じて実装できる。要求メッセージは、ｒｅｑｕｅｓｔＣａｕｓｅパラメータに、更新の理由を含むことができる。さらなるオプションについては後述する。

図１４のステップ１３において、これらの要求を受信するサービス層は、すべての通知ターゲット、すべてのアナウンスメントリンク、およびすべてのグループメンバーＩＤ内のコンタクト情報を調べ、ＳＬ１ １４０４上でホストされる対応するＡＥのリソースを指すあらゆるコンタクト情報を更新して、現在登録されている新しいＳＬ（すなわちＳＬ２ １４０６）を反映する。

図１４に示されるステップを実行するエンティティは、図２３Ｃまたは図２３Ｄに示されるような無線および／またはネットワーク通信のために構成された装置またはコンピュータシステムにおいて、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわちコンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。つまり、図１４に示す方法（複数可）は、図２３Ｃまたは図２３Ｄに示す装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、このコンピュータ実行可能命令は、装置のプロセッサによって実行された場合、図１４に示すステップを実行する。また、図１４に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。さらに、図１４に示される任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で装置の通信回路によって実行されてもよいことを理解されたい。

第２の例示的な実施形態、ケース２では、Ｍ２Ｍサーバは、ＡＥ登録を未把握であり得る。ケース１は、Ｍ２Ｍサーバ１４１０がアプリケーション識別情報（ＡＥ－ＩＤ）をアプリケーション１４０２に提供する解決策に焦点を合わせた。これは、アプリケーション１４０２がいつ移動したかを知る上での手がかりをＭ２Ｍサーバ１４１０に与える。しかしながら、Ｍ２Ｍサーバ１４１０にアナウンスされたくない場合がある、またはリモートサービス層と通信したくない場合がある、いくつかのアプリケーションがある。このような場合、アプリケーション識別情報（ＡＥ－ＩＤ）は、通常、ローカルサービス層によって提供され、そのローカルサービス層内で一意であることだけが保証される。このセクションでは、このようなアプリケーションのためにＡＥモビリティイベントを処理するための解決策を説明する。

全体の流れを図１５に示す。強調表示されているステップには番号が付けられ、以下に説明されている。３つのローカルサービス層（ゲートウェイ１内のＳＬ１ １４０４、ゲートウェイ２内のＳＬ２ １４０６、およびゲートウェイ３内のＳＬ３ １４０８）があり、これらは既にＭ２Ｍサーバ１４１０に登録されていると仮定することに留意されたい。最後の仮定（ＳＬ１ １４０４およびＳＬ２ １４０６が、Ｍ２Ｍサーバ１４１０内のサービス層に個々に登録されている）は、この解決策の要件ではないことに留意されたい。実際、説明された方法は、ＳＬ１ １４０４およびＳＬ２ １４０６がＭ２Ｍサーバ１４１０への通信経路を有するあらゆる場合に適用される。

図１５のステップ１において、アプリケーション１ １４０２は、ゲートウェイ１ １４０４においてローカルサービス層に接続して登録し、この初期登録の一部として、アプリケーション１４０２は、その識別子（ＡＥ－ＩＤ）をローカルサービス層によって割り当てることを求める。ゲートウェイ１のローカルサービス層は、ローカルで一意のＡＥ－ＩＤを割り当てる。ｏｎｅＭ２Ｍでは、そのような識別子は文字「Ｃ」で始まる。

図１５のステップ２において、アプリケーション１ １４０２は、（図１４のステップ２で説明したように）ローカルＳＬ１ １４０４によってサポートされているいくつかのアクティブ／進行中のＭ２Ｍサービスを使用し始める。

図１５のステップ３において、ＡＥは移動してゲートウェイ１ １４０４への接続性を切り、ゲートウェイ２ １４０６を見つける。

図１５のステップ４において、アプリケーション１４０２は、ゲートウェイ２サービス層との再登録手順を開始する。再登録の一部として、アプリケーション１４０２は、そのＡＥ－ＩＤを供給する。ゲートウェイ２ １４０６は、これが未知のアプリケーションからの再登録要求であると気付き（ＡＥがＡＥ－ＩＤを供給するため）、その結果、要求がＡＥモビリティイベントの結果であり得ると判定する。提供されたＡＥ－ＩＤのフォーマットおよび／または値に基づいて、ゲートウェイ２ １４０６は、ＡＥ－ＩＤが別のサービス層によって割り当てられたことを知る。あるいは、アプリケーション１４０２は、ゲートウェイ２サービス層に、それが既に接続されていたサービス層（この例ではゲートウェイ１サービス層）の識別子を供給することができる。これにより、Ｇａｔｅｗａｙ２サービス層は、これがＡＥモビリティイベントであることをただちに判定できる。ＡＥ－ＩＤが現在ゲートウェイ２ １４０６において利用可能である場合、サービス層は、ＡＥ－ＩＤを維持し、登録を完了し、ＡＥ－ＩＤが認識されず、ゲートウェイがＡＥ １４０２が以前に登録されていたゲートウェイとは異なるという指示で応答する。ＡＥ－ＩＤがＧａｔｅｗａｙ２ １４０６に登録された別のアプリケーションによって既に使用されている場合、サービス層は、新しいローカルに一意のＡＥ－ＩＤを割り当て、ＡＥ １４０２が以前に登録されたゲートウェイとゲートウェイが異なるという指示を提供する。

ＡＥ－ＩＤがアプリケーション１４０２内に事前プロビジョニングされている場合、アプリケーション１４０２は、これが初期登録であるか再登録であるかを示すために、サービス層に別の指示を供給することができることに留意されたい。例えば、アプリケーション１４０２は、登録要求にｉｎｉｔｉａｌＲｅｇｉｓｔｒａｔｉｏｎ指示を含み得る（これが事前プロビジョニングされたＡＥ－ＩＤを用いた初期登録である場合にＴＲＵＥに設定され、初期登録でない場合にＦＡＬＳＥまたはＮＵＬＬに設定される）。あるいは、別のマーカをＡＥ－ＩＤ内で使用して、（例えば、「Ｐ」のプレフィックスでＡＥ－ＩＤを開始する）事前プロビジョニングされたＡＥ－ＩＤをシグナリングすることができる。

図１５のステップ５において、ゲートウェイ２は、ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑメッセージを送信することによって、アプリケーション１４０２に関するコンタクト情報の潜在的な変化についてＭ２Ｍサーバ１４１０に通知する。このメッセージは、アプリケーション１４０２に関する新旧のコンタクト情報を含む。このメッセージには、このＡＥが現在ゲートウェイ２に登録されていることをＭ２Ｍサーバに通知するために、ゲートウェイ２のＣＳＥ－ＩＤおよびＳＰ－ＩＤが含まれているべきである。

図１５のステップ６において、Ｍ２Ｍサーバ１４１０は、ＡＥ １４０２のコンタクト情報を更新する。これは、非限定的な例において、以下を含み得る：
・古いコンタクト情報のＵＲＩを含む任意の通知ターゲット。ｏｎｅＭ２Ｍでは、これらはＭ２Ｍサーバに含まれている＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースの一部であり得る、または非ブロッキング非同期要求に対する一時停止中の応答の一部であり得る。
・古いコンタクト情報のＵＲＩを含む任意のアナウンスメントリンク。ｏｎｅＭ２Ｍでは、これは、Ｍ２Ｍサーバにアナウンスされた＜ＡＥ＞リソースのリンク属性を含み得る。
・古いコンタクト情報のＵＲＩを含む任意のグループメンバーシップ。ｏｎｅＭ２Ｍでは、これは、＜ｇｒｏｕｐ＞リソースの任意のｍｅｍｂｅｒＩＤｓ属性を含み得る。

図１５のステップ７において、Ｍ２Ｍサーバ１４１０は、コンタクト情報の変更を、子サービス層および潜在的に他のサービスプロバイダドメイン上の他のＭ２Ｍサーバに伝播させる。Ｍ２Ｍサーバが、アプリケーションモビリティによって影響を受ける子サービス層を知っている場合、Ｍ２Ｍサーバ１４１０は個別にサービス層にコンタクトすることができる。あるいは、Ｍ２Ｍサーバ１４１０は、すべてのサービス層に要求をファンアウトして、アプリケーション１４０２のコンタクト情報を更新するようにそれらに知らせることができる。これは、ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑ／ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｓｐメッセージ交換を通じて実装できる。

図１５のステップ８において、サービス層は、通知ターゲット、任意のアナウンスメントリンク、および任意のグループメンバーシップにおけるコンタクト情報を更新する。元のサービス層（ＳＬ１ １４０４）は、アプリケーション１４０２に関連するコンテキストを削除または一時停止することができる。一時停止された場合、ＳＬ１ １４０４は、リソースを削除しないが、このリソースに関連付けられているあらゆるサービス層処理を一時停止する。これにより、アプリケーション１４０２が後でサービス層に再登録しようとする場合に、より簡単に再登録できる。

図１５に示されるステップを実行するエンティティは、図２３Ｃまたは図２３Ｄに示されるような無線および／またはネットワーク通信のために構成された装置またはコンピュータシステムにおいて、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわちコンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。つまり、図１５に示す方法（複数可）は、図２３Ｃまたは図２３Ｄに示す装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、このコンピュータ実行可能命令は、装置のプロセッサによって実行された場合、図１５に示すステップを実行する。また、図１５に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。さらに、図１５に示される任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で装置の通信回路によって実行されてもよいことを理解されたい。

上述のように、Ｍ２Ｍサーバ１４１０がＡＥモビリティイベントがあったことを認識すると、ローカルで（Ｍ２Ｍサーバ１４１０内で）、かつ同じサービスプロバイダドメイン内のすべての子サービス層で、また潜在的に他のサービスプロバイダドメイン内でも同様に、ＡＥコンタクト情報を更新する必要がある。一解決策では、Ｍ２Ｍサーバ１４１０は、これらすべての他のサービス層を含むグループを作成し、次いでＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑをすべてのサービス層にファンアウトすることができる。しかしながら、これは、新しいＡＥコンタクト情報についてサービス層に知らせるための、かなりのシグナリングオーバーヘッドをもたらし得る。効率および／またはセキュリティを向上させるために、以下の方法のうちの少なくとも１つを使用することができ、それらの方法のそれぞれを以下により詳細に説明する。
１）Ｍ２Ｍサーバ１４１０は、影響を受けるサービス層を発見し、それらのサービス層にのみメッセージをファンアウトすることができる。
２）Ｍ２Ｍサーバ１４１０は、ＡＥコンタクト情報の変更によって影響を受けるＳＬのリストを維持することができる。必要に応じて、Ｍ２Ｍサーバ１４１０は、このリストを照会し、影響を受けるＳＬだけにＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｇを送信することができる。
３）ＡＥモビリティイベントがあるときに通知を送信するＭ２Ｍサーバ１４１０において子サービス層にサブスクリプションを作成させる。

Ｍ２Ｍサーバは、影響を受けるサービス層を発見し、それらのサービス層にのみメッセージをファンアウトすることができる。主なアイデアは、（例えばアナウンスリンク、グループメンバーＩＤ、または通知ターゲットを通じて）古いＡＥコンタクト情報を維持しているすべてのサービス層をＭ２Ｍサーバ１４１０に発見させることである。発見されると、Ｍ２Ｍサーバ１４１０は、それらのサービス層に対してのみＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑをターゲットとすることができる。これは発見されたサービス層を含むグループを作成し、その後ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑメッセージをファンアウトすることができる。

Ｍ２Ｍサーバ１４１０は、これを周期的に行うことができ、それが各サービス層で使用されるＡＥコンタクト情報の完全なリストを構築することを可能にする。あるいは、Ｍ２Ｍサーバ１４１０は、特定のＡＥモビリティイベントによって影響を受けるサービス層を見つける必要があるときに、要求に応じてこれを実行してもよい。後者の手順を以下に説明する。ＡＥ１（リソース名：ｔｈｅｒｍｏＣｏｎｔｒｏｌ、リソースＩＤ：ＴＣ００１）は、サービス層１（ＣＳＥ－ＩＤ ＣＳＥ００１）に元は登録されており、モビリティイベントの後、ＡＥ１は、サービス層２（ＣＳＥ－ＩＤ ＣＳＥ００２）に登録されると仮定する。

手順の例を図１６に示し、以下のステップで説明する。

図１６のステップ１において、Ｍ２Ｍサーバ１４１０は、ＡＥ１についてＡＥモビリティイベントを検出した場合、各子サービス層に拡張発見要求を発行する。発見要求は、古いＡＥコンタクト情報を探すようにサービス層に求める（以前に説明したように、これはアナウンスリンク、グループメンバーＩＤ、または通知ターゲットに関連する情報を含むことができる）。発見照会は、ワイルドカード文字（＊）を使用して、ＡＥ１に関連するＡＥコンタクト情報の検索を支援する。例えば、検索は、ＡＥ１のリソース名との任意の一致（例えば、／ＣＳＥ００１／＊／ｔｈｅｒｍｏＣｏｎｔｒｏｌ／＊）に対するものであり得る。あるいは、検索は、ＡＥ１のリソースＩＤとの任意の一致（例えば、／ＣＳＥ００１／＊／ＴＣ００１／＊）に対するものであり得る。要求は、ＡＥコンタクト情報のリストを含み得る。場合により、要求はまた、検索のルートも指定できる－その結果、子サービス層はこのルートで検索を開始する。

図１６のステップ２において、各子サービス層は、発見要求にブール型の結果で応答する：サービス層が一致するコンテンツを有する場合はＴＲＵＥ、または一致するコンテンツがない場合はＦＡＬＳＥ。サービス層からの応答メッセージは、例えば、アナウンスされたリンク属性がアクセスされた回数、ＡＥをターゲットとするグループ操作の数など、一致するコンテンツについての統計情報を任意に含み得る。Ｍ２Ｍサーバ１４１０は、これを使用して、どのサービス層にＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑを送信するかを決定することができる。例えば、サービス層がＡＥ１を含むグループを有し、このグループがめったに使用されないかまたはまったく使用されない場合、Ｍ２Ｍサーバ１４１０は、ＡＥコンタクト情報の更新を見送ることを決定することができる。

図１６のステップ３において、Ｍ２Ｍサーバ１４１０は、ＴＲＵＥと応答したすべてのサービス層の在庫を構築する。

図１６のステップ４において、Ｍ２Ｍサーバ１４１０は、ＡＥモビリティイベントによって影響を受けるサービス層においてのみコンタクト情報を更新する。

代替の実装では、子サービス層は、すべてのＡＥコンタクト情報のリストを含む新しいａｅＣｏｎｔａｃｔＳｕｍｍａｒｙパラメータを作成することによって、発見を支援する可能性があることに留意されたい。このように、Ｍ２Ｍサーバ１４１０は、サービス層全体を通してではなく、ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙパラメータを通して探索するだけでよい。サービス層がＡＥコンタクト情報を生成する要求に気付くたびに、サービス層は、このコンタクト情報のコピーをａｅＣｏｎｔａｃｔＳｕｍｍａｒｙパラメータに自動的に保存する。コンタクト情報が以前の要求から既にある場合、またはＡＥがサービスプロバイダにより割り当てられたＡＥ＿ＩＤを有する場合は、ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙリソースを更新する必要はない。ＡＥコンタクト情報がもはや必要とされない場合、例えばアナウンスされたリソースが削除された場合、ＡＥコンタクト情報はリストから削除されてもよい。別の代替策として、Ｍ２Ｍサーバ１４１０は、このａｅＣｏｎｔａｃｔＳｕｍｍａｒｙパラメータに変化がある場合に通知を受けるようにサブスクライブすることができる。その結果、ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙパラメータに変更があるときはいつでも、Ｍ２Ｍサーバ１４１０に通知される。通知メッセージは、登録、変更、または削除されたＡＥコンタクト情報を含み得る。

図１６に示されるステップを実行するエンティティは、図２３Ｃまたは図２３Ｄに示されるような無線および／またはネットワーク通信のために構成された装置またはコンピュータシステムにおいて、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわちコンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。つまり、図１６に示す方法（複数可）は、図２３Ｃまたは図２３Ｄに示す装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、このコンピュータ実行可能命令は、装置のプロセッサによって実行された場合、図１６に示すステップを実行する。また、図１６に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。さらに、図１６に示される任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で装置の通信回路によって実行されてもよいことを理解されたい。

Ｍ２Ｍサーバは、ＡＥコンタクト情報の変更によって影響を受けるＳＬのリストを維持することができる。このオプションでは、子サービス層のマスターリストおよび関連するＡＥコンタクト情報がＭ２Ｍサーバ１４１０に保持される。子サービス層は、このマスターリストを最新に保つ役割を果たす。子サービス層とＭ２Ｍサーバ１４１０との間の相互作用を示す典型的なコールフローが図１７に示されている。前のセクションと同様に、ＡＥ１（リソース名：ｔｈｅｒｍｏＣｏｎｔｒｏｌ、リソースＩＤ：ＴＣ００１）は、サービス層１（ＣＳＥ－ＩＤ ＣＳＥ００１）に元は登録されており、モビリティイベントの後、ＡＥ１は、サービス層２（ＣＳＥ－ＩＤ ＣＳＥ００２）に登録されると仮定する。

図１７のステップ０において、Ｍ２Ｍサーバ１４１０は、パラメータａｅＣｏｎｔａｃｔＬｉｓｔを既に初期化しており、これは、ＡＥコンタクト情報のマスターリストを保持するために使用されると仮定する。例えば、このパラメータは、Ｍ２Ｍサーバ１４１０上のリソースとして実装され得る。このパラメータに格納されている情報は、子サービス層ごとのＡＥコンタクト情報のリストである。

図１７のステップ１において、ゲートウェイ２内の子サービス層は、ＡＥコンタクト情報を有する要求を受信する。子サービス層は、「追加」ＡＥコンタクト情報要求をＭ２Ｍサーバ１４１０に送信する。

図１７のステップ２において、Ｍ２Ｍサーバ１４１０は、要求からＡＥコンタクト情報を抽出し、ａｅＣｏｎｔａｃｔＬｉｓｔ内の適切なエントリを更新する。要求は、例えばステップ１の要求がメンバーＩＤとして複数のＡＥを含むグループ作成であった場合、２つ以上のＡＥコンタクト情報を含み得る。

しばらく後に、ゲートウェイ１の子サービス層１がアナウンスされたリソースを削除する。リソースは、ＡＥコンタクト情報を有していた。

図１７のステップ３において、子サービス層１は、「削除」ＡＥコンタクト情報要求をＭ２Ｍサーバ１４１０に送信する。

図１７のステップ４において、Ｍ２Ｍサーバ１４１０は、要求からＡＥコンタクト情報を抽出し、ａｅＣｏｎｔａｃｔＬｉｓｔから対応するエントリを除去する。
どの時点においても、Ｍ２Ｍサーバ１４１０は、ＡＥモビリティイベントによって影響を受けるすべての子サービス層の全体像を把握している。例えば、ｏｎｅＭ２Ｍ配備のサンプルａｅＣｏｎｔａｃｔＬｉｓｔを表１に示す。

図１７のステップ５において、Ｍ２Ｍサーバ１４１０は、ＡＥモビリティイベントがＡＥ１について発生したことを知る。このＡＥモビリティイベントのために、ＡＥコンタクト情報／ＣＳＥ００１／ＴＣ００１は古く、／ＣＳＥ００２／ＴＣ００１に変更する必要がある。Ｍ２Ｍサーバ１４１０は、ａｅＣｏｎｔａｃｔＬｉｓｔを見て、このモビリティイベントによって影響を受けるサービス層を判定する。表１に示す例では、影響を受ける２つのＣＳＥのＩＤはＣＳＥ００４およびＣＳＥ００９である。Ｍ２Ｍサーバは、これらの影響を受けるサービス層にのみＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑを送信する。

エンティティがａｅＣｏｎｔａｃｔＬｉｓｔパラメータへの変更について通知を受けるためにサブスクライブすることも可能であることを理解されたい。サブスクリプションは、サービスプロバイダドメイン全体内の変更、または特定の子サービス層のＡＥコンタクト情報の変更のためのものであり得る。

図１７に示されるステップを実行するエンティティは、図２３Ｃまたは図２３Ｄに示されるような無線および／またはネットワーク通信のために構成された装置またはコンピュータシステムにおいて、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわちコンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。つまり、図１７に示す方法（複数可）は、図２３Ｃまたは図２３Ｄに示す装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、このコンピュータ実行可能命令は、装置のプロセッサによって実行された場合、図１７に示すステップを実行する。また、図１７に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。さらに、図１７に示される任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で装置の通信回路によって実行されてもよいことを理解されたい。

子サービス層は、ＡＥモビリティイベントがあるときに通知を送信し得るＭ２Ｍサーバにおいてにサブスクリプションを作成し得る。最初の２つのオプションでは、一般的な手法は、ＡＥモビリティイベントについて通知される必要があるＳＬをＭ２Ｍサーバ１４１０に見つけさせることと、次いでこれらのＳＬに新しいＡＥコンタクト情報を送信することと、に依拠する。この第３のオプションでは、ＳＬは、新しいＡＥコンタクト情報があるか否かを知らされるようにサブスクライブする。

このオプションでは、子サービス層は、ＡＥモビリティイベントが発生したときに通知されるサブスクリプションメカニズムに依拠する。サンプルコールフローを図１８に示す。

図１８のステップ０において、最初に、Ｍ２Ｍサーバ１４１０がＡＥモビリティイベントに対するすべてのアクティブなサブスクリプションを維持していると仮定する。このメカニズムは、リソース上で発生する何らかのイベントに関連付けられているとは限らないために、ｏｎｅＭ２Ｍで定義されているサブスクリプションメカニズムとは少し異なる。むしろ、それはＭ２Ｍサーバ１４１０で気付かれ得るイベントに関連付けられている。各サブスクリプションは、要求を出したサービス層のアドレス、および監視されているＡＥのＡＥコンタクト情報を含む。

図１８のステップ１において、サービス層３は、ＡＥ１のＡＥコンタクト情報を有する要求を受信する。図示の例では、この要求はグループ作成要求である。

図１８のステップ２において、サービス層３は、ＡＥ１に対するＡＥモビリティイベントの通知を受けるようにサブスクライブする。サービス層３はまた、可能なモビリティイベントについて知らされたいと思うアドレスを提供する。

図１８のステップ３において、Ｍ２Ｍサーバ１４１０は、ＡＥモビリティイベントに関するそのサブスクリプション情報を更新する。

図１８のステップ４において、しばらく後に、アナウンスリソースがサービス層２で削除される。アナウンスリソースは、ＡＥ２を指すリンク属性を有している。

図１８のステップ５において、ゲートウェイ２サービス層（ＳＬ２ １４０６）は、自身をＡＥ監視イベントからアンサブスクライブするように、Ｍ２Ｍサーバ１４１０に求める。

図１８のステップ６において、Ｍ２Ｍサーバ１４１０は、そのサブスクリプション情報を更新し、サブスクリプションを削除する。

図１８のステップ７において、モビリティイベントがＡＥ１に対して発生する。Ｍ２Ｍサーバ１４１０は、このイベントが発生したと判定するために、図１４および図１５の方法のうちの１つを使用することができる。次いで、Ｍ２Ｍサーバ１４１０は、ＡＥ１に関連するものを見つけるためにそのすべてのサブスクリプションを調べることができる。ＡＥ１に関連するあらゆるサブスクリプションが、ＡＥモビリティイベントを通知される。Ｍ２Ｍサーバ１４１０は、通知される必要がある複数のサービス層を見つけた場合、これらのメンバーを用いてグループを作成し、ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑをファンアウトすることができる。

図１８に示されるステップを実行するエンティティは、図２３Ｃまたは図２３Ｄに示されるような無線および／またはネットワーク通信のために構成された装置またはコンピュータシステムにおいて、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわちコンピュータ実行可能命令）の形態で実装され得る論理エンティティであり得ることを理解されたい。つまり、図１８に示す方法（複数可）は、図２３Ｃまたは図２３Ｄに示す装置またはコンピュータシステムなどの装置のメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、このコンピュータ実行可能命令は、装置のプロセッサによって実行された場合、図１８に示すステップを実行する。また、図１８に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。さらに、図１８に示される任意の送信および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えばソフトウェア）の制御下で装置の通信回路によって実行されてもよいことを理解されたい。

以下では、ｏｎｅＭ２Ｍアーキテクチャに対して本明細書で説明した方法／拡張したものを実装するための実施形態について説明する。加えて、図２２には、関連するパラメータおよび情報を表示および／または構成するためのユーザインターフェースも含まれる。

（ｏｎｅＭ２Ｍ実施形態）
本明細書で説明される新しい機能は、ＡＥモビリティイベント、および場合によってはｏｎｅＭ２Ｍ層に影響を及ぼし得る他のモビリティシナリオを処理する、新しいモビリティ（ＭＯＢ）ＣＳＦ １９０２において実装され得る。

モビリティＣＳＦ １９０２は、ＩＮ－ＣＳＥならびにＭＮ－ＣＳＥおよびＡＳＮ－ＣＳＥで見出すことができる。この新しいＭＯＢ １９０２は、上述したように、Ｍ２Ｍサーバ１４１０と子サービス層との間の手順およびプロセスをサポートする。サービス層に関連するリソースおよび手順は、ＣＳＥに実装される。

あるいは、本明細書で説明されている新しい機能は、既存のＣＳＦ、例えば発見ＣＳＦ、登録ＣＳＦ、またはロケーションＣＳＦに実装することができる。

図１９に示す機能は、後述する図２３Ｃまたは図２３Ｄに示すもののうちの１つなど、無線デバイスまたは他の装置（例えば、サーバ１４１０、ゲートウェイ、デバイス、または他のコンピュータシステム）において、そのメモリに記憶され、そのプロセッサ上で実行されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。また、図１９に示されている機能は、一式の仮想化ネットワーク機能として実装されてもよいことを理解されたい。ネットワーク機能は必ずしも直接通信する必要はなく、むしろ転送機能またはルーティング機能を介して通信してもよい。

（ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑのマッピング）
通知要求を使用する
上記のＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑメッセージは、ＮＯＴＩＦＹ操作を通じて実装され得る。Ｔｏパラメータは、接続されているＣＳＥに設定できる。例えば、これは次のようになり得る：
１）＜ＣＳＥｂａｓｅ＞リソースのｒｅｓｏｕｒｃｅＩＤ
２）＜ＣＳＥｂａｓｅ＞リソースの階層アドレス
３）ＣＳＥがそのｐｏｉｎｔＯｆＡｃｃｅｓｓで公開したＣＳＥのｐｏｉｎｔＯｆＡｃｃｅｓｓ（ＩＰアドレスおよびポート、またはＦＱＤＮ）

Ｃｏｎｔｅｎｔパラメータは、更新されたコンタクト情報を含み得る。例えば、それは、古いＡＥコンタクト情報および／または新しいＡＥコンタクト情報を含み得る。

２つ以上の形態のコンタクト情報が含まれ得る。例えば、コンタクト情報は、ＡＥのリソース名（／ＭＮ－ＣＳＥ００１／ＣＳＥＢａｓｅ／ＡｐｐＮａｍｅ）の形態、リソースＩＤ（／ＭＮ－ＣＳＥ００１／ＡＥ００００１）の形態、または絶対ＵＲＩ（ＩＰアドレス／ポート、ＦＱＤＮなど）の形態であり得る。

加えて、要求はまた、オプションのｒｅｑｕｅｓｔＣａｕｓｅパラメータを含むことができ、これは、要求が発行された理由を受信者に通知する。このパラメータの可能な値は、例えば以下を含み得る：
・ＡＥモビリティイベント：ＡＥモビリティイベントが検出されたため、発信者がこの要求を発行した。

基本操作は、その全体が参照により本明細書に組み込まれる、ｏｎｅＭ２Ｍ－ＴＳ－０００１（ｏｎｅＭ２Ｍアーキテクチャ仕様書Ｖ－２．６．０の１０．１．５節に定義されているとおりである。その手順のステップ００３の詳細は以下のように変更される：

ＭＮ－ＣＳＥまたはＡＳＮ－ＣＳＥの場合：
・ＣＳＥは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｎｏｔｉｆｉｃａｔｉｏｎＴａｒｇｅｔｓ属性、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＩＤｓ属性、およびアナウンスされたリソースのｌｉｎｋ属性から、提供された古いＡＥコンタクト情報に一致するＵＲＩを検索する。
・ＣＳＥは、見つかった属性のＵＲＩを新しいＡＥコンタクト情報に置き換える。

ＩＮ－ＣＳＥの場合：
・ＩＮ－ＣＳＥがＡＥモビリティイベント処理手順をトリガする。
・ＵＰＤＡＴＥ要求を使用する
本明細書で説明されているＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑメッセージは、ＣＳＥ仮想リソースｃｏｎｔａｃｔＩｎｆｏＣｈａｎｇｅへのＵＰＤＡＴＥ操作を通じて実装され得る。Ｃｏｎｔｅｎｔパラメータは、更新されたコンタクト情報を含み得る。それは、古いＡＥコンタクト情報および／または新しいＡＥコンタクト情報を含み得る。

２つ以上の形態のコンタクト情報が含まれ得る。例えば、コンタクト情報は、ＡＥのリソース名（／ＭＮ－ＣＳＥ００１／ＣＳＥＢａｓｅ／ＡｐｐＮａｍｅ）の形態、リソースＩＤ（／ＭＮ－ＣＳＥ００１／ＡＥ００００１）の形態、または絶対ＵＲＩ（ＩＰアドレス／ポート、ＦＱＤＮなど）の形態であり得る。
加えて、要求はまた、オプションのｒｅｑｕｅｓｔＣａｕｓｅパラメータを含むことができ、これは、要求が発行された理由を受信者に通知する。このパラメータの可能な値は、例えば以下を含む：
・ＡＥモビリティイベント：ＡＥモビリティイベントが検出されたため、発信者がこの要求を発行した。

基本操作は、その全体が参照により本明細書に組み込まれる、ｏｎｅＭ２Ｍ－ＴＳ－０００１（ｏｎｅＭ２Ｍアーキテクチャ仕様書Ｖ－２．６．０の１０．１．５節に定義されているとおりである。その手順のステップ００３の詳細は以下のように変更される。

ＭＮ－ＣＳＥまたはＡＳＮ－ＣＳＥの場合：
・ＣＳＥは、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｎｏｔｉｆｉｃａｔｉｏｎＴａｒｇｅｔｓ属性、＜ｇｒｏｕｐ＞リソースのｍｅｍｂｅｒＩＤｓ属性、およびアナウンスされたリソースのｌｉｎｋ属性から、提供された古いＡＥコンタクト情報に一致するＵＲＩを検索する。
・ＣＳＥは、見つかった属性のＵＲＩを新しいＡＥコンタクト情報に置き換える。

ＩＮ－ＣＳＥの場合：
・ＩＮ－ＣＳＥがＡＥモビリティイベント処理手順をトリガする。

（ＡＥ登録要求に対する変更）
ＡＥ登録手順の一部として、ＡＥはＣＲＥＡＴＥ要求をレジストラＣＳＥに発行する。要求は、以下のオプションのパラメータを含み得る：初期登録、ローカル登録、および現在のレジストラＣＳＥ。

初期登録：ＡＥまたはＣＳＥ登録要求に適用可能なオプションのパラメータ。ＴＲＵＥに設定されている場合、受信者ＣＳＥは、ＣＲＥＡＴＥ操作を発信者からの初期登録として扱う。例えば、発信者がＡＥ－ＩＤまたはＣＳＥ－ＩＤで事前プロビジョニングされている場合に発生し得る。ＦＡＬＳＥまたはＮＵＬＬに設定されている場合、受信者ＣＳＥは、ＣＲＥＡＴＥ操作を再登録要求として扱う。

ローカル登録：ＡＥ登録要求に適用可能なオプションのパラメータ。ＴＲＵＥに設定されている場合、ＡＥモビリティイベントが検出されたときに受信者ＣＳＥは、プロアクティブなアクションを実行しない。ＦＡＬＳＥまたはＮＵＬＬに設定されている場合、受信者ＣＳＥは、ＡＥがＡＥモビリティイベントを経たときにＡＥを助ける。例えば、モビリティイベントが発生したことをＩＮ－ＣＳＥに通知してもよい。

現在のレジストラＣＳＥ：ＡＥまたはＣＳＥ登録要求に適用可能なオプションのパラメータ。発信者によって現在のレジストラＣＳＥのＣＳＥ－ＩＤに設定される。受信者ＣＳＥが提供されたＣＳＥ－ＩＤと異なる場合、これは、これが再登録要求であることを受信者ＣＳＥに示し、発信者が以前に登録されたＣＳＥのＣＳＥ－ＩＤをレジストラＣＳＥに提供する。

（アナウンスリソースの新しい属性）
図１４に関する説明の一部として、ＡＥが新しいレジストラＣＳＥに再登録し、その存在をＩＮ－ＣＳＥにアナウンスした後、ＩＮ－ＣＳＥは、１つは古い登録のためのものであり、もう１つは新しい登録のためのものである、２つのアナウンスされたリソースを有することを説明した。古いアナウンスメントを保持しておくと便利な場合があるため（例えば、ＡＥが移動して元のＣＳＥに戻るなど）、アナウンスされたリソースを維持するが、「無効」状態にしておくことが提案された。これを実装するために、表２において太字で示されているように、新しいステータス属性をアナウンスリソースに導入することができる。

（発見のための新しいフィルタ基準）
図１６に関する説明の一部として、ＣＳＥが（例えば、アナウンスリンク属性内、グループメンバーＩＤ内、または通知ターゲット内の）ＡＥコンタクト情報とのすべての一致を見つけるために発見要求を発行し得ることを説明した。これを実装するために、そのすべてのＡＥコンタクト情報を通して検索を行う必要があることを受信者ＣＳＥにシグナリングするために、新しいフィルタ基準が導入される。これは表３において太字で示されている。

検索の範囲を狭めるために他の情報が発信者に利用可能でない場合、検索のルートは、ターゲットＣＳＥのＣＳＥｂａｓｅに設定されてもよい。

（＜ＡＥ＞リソースの新しい属性）
図１４に関する説明の一部として、ＡＥが新しいレジストラＣＳＥに再登録し、その存在をＩＮ－ＣＳＥにアナウンスした後、ＩＮ－ＣＳＥは、元の＜ＡＥ＞リソースを削除または無効化し得ることを説明した。古い＜ＡＥ＞リソースを保持しておくと便利な場合があるため（例えば、ＡＥが移動して元のＣＳＥに戻るなど）、アナウンスされたリソースを維持するが、「無効」状態にしておくことが提案された。この状態の間、ＣＳＥは、このリソースに関連付けられているすべてのコンテキストを維持し、このリソースに対するＲＥＴＲＩＥＶＥ操作のみを許可し得る。このリソースをターゲットにしている他の操作はすべて、失敗した応答ステータスコードで拒否される。加えて、応答メッセージの内容は、追加のエラー情報（例えば「無効化されたリソース」）を含み得る。これを実装するために、表４において太字で示されているように、新しいステータス属性を＜ＡＥ＞リソースに導入することができる。

（サブスクリプション／通知への変更）
図１８に関して説明したように、ＣＳＥは、特定のＡＥモビリティイベントが発生したときに通知を受けるようにサブスクライブすることができる。結果として、ＡＥ１に対するＡＥコンタクト情報を自らが有することを知っているＣＳＥは、ＡＥ１に対するＡＥモビリティイベントがあるときに通知されるために、ＩＮ－ＣＳＥにサブスクライブすることができる。

これは、サブスクリプションリソースに１つの新しい属性を導入し、新しい通知基準を追加することによって実現され得る。

（サブスクリプションの新しいイベント通知基準）
新しいイベント通知基準により、ＣＳＥは、サブスクリプションリソースの親リソースへの何らかの変更とは関係がないが、ＣＳＥで発生する何らかのアクションに関係する、ＣＳＥにおける特定のイベントを監視できる。図１８に関して提示された解決策の文脈では、イベントはＡＥ監視イベントである。＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースは、＜ＣＳＥｂａｓｅ＞リソースまたは＜ｎｏｄｅ＞子リソースのうちの１つのいずれかの下に作成され得る。詳細を表５の項目に示す（新しい項目は太字で示されている）。

（新しい＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソース）
＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースは、図１６に関して提示された解決策をサポートする。これは、このＣＳＥのためのＡＥコンタクト情報のリストを提供する。要求がＡＥコンタクト情報を作成または削除するたびに、ＣＳＥによって内部的に更新される。リソースは、例えば以下のとおりであり得る：
・リモート－ＣＳＥによって発見または参照された。
・リモートＣＳＥにアナウンスされた／ミラーされた。および／または
・リモートＣＳＥによってサブスクライブされている。

これにより、リモートＣＳＥ（通常はＩＮ－ＣＳＥ）は、ホスティングＣＳＥがＡＥモビリティイベントの影響を受けているか否かを判定できる。ＣＳＥｂａｓｅの下にある場合もあり、図２０に示す。表６には、１つの属性（ａｅＣｏｎｔａｃｔＩｎｆｏ）が定義されている。

（＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの手順）
ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥを含む操作は、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースに対して許可されて、上記の相互作用を実現する。

（＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞の作成）
上記のように、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの作成は、最初のレジストリＡＥがホスティングＣＳＥに登録されたときにＣＳＥで黙示的にのみ実行できる。これにより、＜ＣＳＥＢａｓｅ＞の下に＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞子リソースが作成される。
ホスティングＣＳＥは、以下に概説する手順を辿り得る。

ステップ００１：受信機は以下のことができる：
１）作成する＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースのｒｅｓｏｕｒｃｅＩＤ属性およびｒｅｓｏｕｒｃｅＮａｍｅ属性に値を割り当てる。
２）参照によりその全体が本明細書に組み込まれるｏｎｅＭ２Ｍ－ＴＳ－０００１（ｏｎｅＭ２Ｍアーキテクチャ仕様書Ｖ－２．６．０）の９．６．１．３節に指定されている以下の共通属性に値を割り当てる。
ａ）ｐａｒｅｎｔＩＤ
ｂ）ｃｒｅａｔｉｏｎＴｉｍｅ
ｃ）ｅｘｐｉｒａｔｉｏｎＴｉｍｅ：ホスティングＣＳＥは、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの作成をトリガした＜ＡＥ＞リソースのｅｘｐｉｒａｔｉｏｎＴｉｍｅと一致する値を割り当てることができる。
ｄ）ｌａｓｔＭｏｄｉｆｉｅｄＴｉｍｅ：ｃｒｅａｔｉｏｎＴｉｍｅに等しい。
ｅ）ｓｔａｔｅＴａｇ
ｆ）ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙＩＤ：以下を含む、＜ａｃｃｅｓｓＣｏｎｔｒｏｌＰｏｌｉｃｙ＞の１つのＩＤを入力する。
ｉ）ｐｒｉｖｉｌｅｇｅ属性において：
１）ホスティングＣＳＥに対して作成されている＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースに対するＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ操作を許可する。
２）ＩＮ－ＣＳＥに対して作成されているこの＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースに対するＲＥＴＲＩＥＶＥおよびＤＥＬＥＴＥ操作を許可する。
３）受信者ポリシーの制限内で、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースタイプの任意の他のＲＯ（読み取り専用）属性を割り当てる。
ａ）ａｅＣｏｎｔａｃｔＩｎｆｏ：この＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの作成をトリガした＜ＡＥ＞リソースのＡＥコンタクト情報を含むＵＲＩのリスト。

ステップ００２：受信者は＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースを作成することができる。

（＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞の参照）
この手順は、（例えば、ＩＮ－ＣＳＥにより）＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの属性を参照するために使用され得る。包括的な参照手順は、その全体が参照により本明細書に組み込まれる、ｏｎｅＭ２Ｍ－ＴＳ－０００１（ｏｎｅＭ２Ｍアーキテクチャ仕様書Ｖ－２．６．０の１０．１．２節に定義されているとおりである。

（＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞の更新）
図１６～図１８に関して上述したように、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの更新をサポートする必要はない。＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースの属性の変更は、＜ＡＥ＞リソースがホスティングＣＳＥ上で作成または削除されるため、ホスティングＣＳＥによってのみ実行できる。新しい＜ＡＥ＞リソースごとに、ホスティングＣＳＥは、ａｅＣｏｎｔａｃｔＩｎｆｏ属性およびｅｘｐｉｒａｔｉｏｎＴｉｍｅ属性を更新する（例えば、有効期限が最も長い＜ＡＥ＞リソースのｅｘｐｉｒａｔｉｏｎＴｉｍｅに設定する）。

（＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞の削除）
この手順は、既存の＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースを削除するために使用され得る。既存の＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースを削除すると、ホスティングＣＳＥのＡＥコンタクト情報のそれ以上の処理が終了できる。

加えて、ホスティングＣＳＥは、ホスティングＣＳＥの最後の＜ＡＥ＞リソースが削除されたときに、＜ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙ＞リソースを黙示的に削除し得る。

（新しいａｅＣｏｎｔａｃｔＬｉｓｔリソース）
＜ａｅＣｏｎｔａｃｔＬｉａｔ＞リソースは、図１７に関して提示された解決策をサポートする。サービスプロバイダドメインのすべてのＣＳＥのためのＡＥコンタクト情報のリストを提供する。これはＩＮ－ＣＳＥでのみ維持され、ＣＳＥがＩＮ／ＣＳＥに追加／削除ＡＥコンタクト情報要求を送信したときに更新される。ＣＳＥｂａｓｅの下にある場合もあり、図２１に示す。ＡＥコンタクト情報を提供したＣＳＥごとに１つのサブリソース（＜ｃｓｅＲｅｆ＞）がある。＜ｃｓｅＲｅｆ＞には、表９に定義されている２つの属性（ＣＳＥ－ＩＤおよびａｅＣｏｎｔａｃｔＩｎｆｏ）がある。

（新しいＣＳＥ属性（ｄｅｓｃｅｎｄｅｎｔＡＥ））
ＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑをマッピングするためにＮＯＴＩＦＹまたはＵＰＤＡＴＥ操作を使用することに対する代替の実施形態として、情報は、子孫ＣＳＥ交換を通じて黙示的にＣＳＥからＩＮ－ＣＳＥに送信されてもよい。ＣＳＥ１の子孫ＣＳＥは、登録を通じてＣＳＥ１に関連するすべての子ＣＳＥを指し得る。ＣＳＥ３がＣＳＥ２に登録され、ＣＳＥ２がＣＳＥ１に登録されている場合、ＣＳＥ２およびＣＳＥ３はＣＳＥ１の子孫ＣＳＥである。レジストリＣＳＥとレジストラＣＳＥとの間の登録の結果として、レジストラＣＳＥは、レジストリＣＳＥのための＜ｒｅｍｏｔｅＣＳＥ＞リソースを維持する。この＜ｒｅｍｏｔｅＣＳＥ＞リソースは、レジストリＣＳＥの属性を含む。

子孫ＣＳＥ交換は、レジストリＣＳＥに依拠して、（それらの＜ｒｅｍｏｔｅＣＳＥ＞リソースを通じて）属性をレジストラＣＳＥに再帰的にプッシュする。属性は、１つのレジストリＣＳＥからそのレジストラＣＳＥにプッシュされ、次いで、そのレジストラＣＳＥ（レジストリＣＳＥとして機能する）からそのレジストラＣＳＥにプッシュされる、など、属性がＩＮ－ＣＳＥにプッシュされるまで同様にされる。例えば、ＣＳＥ３がＣＳＥ２に登録され、ＣＳＥ２がＣＳＥ１に登録され、そしてＣＳＥ１がＩＮ－ＣＳＥに登録される場合を考える。ＣＳＥ３はＣＳＥ２の＜ｒｅｍｏｔｅＣＳＥ＞リソースの属性を更新する。ＣＳＥ２はＣＳＥ１の＜ｒｅｍｏｔｅＣＳＥ＞リソースの属性を更新し、ＣＳＥ１はＩＮ－ＣＳＥの＜ｒｅｍｏｔｅＣＳＥ＞リソースの属性を更新する。

提案される属性は、ｄｅｓｃｅｎｄｅｎｔＡＥｓ属性である。これは、＜ＣＳＥ＞リソースおよび＜ｒｅｍｏｔｅＣＳＥ＞リソースの新しい属性である。属性は多重度０．．１（Ｌ）を持ち、読み書き可能である。

この属性は、一式の（ＣＳＥ ＩＤ、アプリケーションエンティティリソースＩＤ）ペアの形でＡＥＣｏｎｔａｃｔＬｉｓｔを含む。属性は、＜ＣＳＥ＞リソースが作成されたときに初期化される。

アプリケーションエンティティリソースＩＤを持つサービスが開始、更新、または削除されると、属性が変更される。例えば、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースが、アプリケーションエンティティリソースＩＤを含むｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ属性を有する場合、または＜ｇｒｏｕｐ＞リソースが、アプリケーションエンティティリソースＩＤを含むｍｅｍｂｅｒＬｉｓｔ属性にメンバーを有する場合、またはアナウンスされたリソースが、アプリケーションエンティティリソースＩＤを指すｌｉｎｋ属性を有する場合である。＜ｒｅｍｏｔｅＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性が変更されると、属性も変更される。

サービスが開始されるとリソースが作成され、これにアプリケーションエンティティリソースＩＤへの参照が含まれている場合、ホスティングＣＳＥはｄｅｓｃｅｎｄｅｎｔＡＥｓ属性に（ＣＳＥ ＩＤ、アプリケーションエンティティリソースＩＤ）のペアを含める。ホスティングＣＳＥはまた、そのレジストラＣＳＥの＜ｒｅｍｏｔｅＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性も更新する。

サービスが停止されるとリソースが削除され、このリソースにアプリケーションエンティティリソースＩＤへの参照が含まれている場合、ホスティングＣＳＥはｄｅｓｃｅｎｄｅｎｔＡＥｓ属性から（ＣＳＥ ＩＤ、アプリケーションエンティティリソースＩＤ）のペアを削除する。ホスティングＣＳＥはまた、そのレジストラＣＳＥの＜ｒｅｍｏｔｅＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性も更新する。

サービスが変更されると、サービスに関連付けられているリソースが変更され、追加（または削除）されたアプリケーションエンティティリソースＩＤへの参照がある場合は、ホスティングＣＳＥはｄｅｓｃｅｎｄｅｎｔＡＥｓ属性に（ＣＳＥ ＩＤ、アプリケーションエンティティリソースＩＤ）のペアを含める。ホスティングＣＳＥはまた、そのレジストラＣＳＥの＜ｒｅｍｏｔｅＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性も更新する。

＜ｒｅｍｏｔｅＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性が変更されると、レジストラＣＳＥはそれに応じて、＜ＣＳＥ＞リソースのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性を更新し、それに応じてエントリを削除／追加／変更する。

Ｍ２Ｍ／ＩｏＴシステム内の任意のＣＳＥ内のｄｅｓｃｅｎｄｅｎｔＡＥ属性におけるあらゆる変更は、ＩＮ－ＣＳＥに伝播する。ＩＮ－ＣＳＥのｄｅｓｃｅｎｄｅｎｔＡＥｓ属性は、図１７に関して提示されているように、完全なＡＥＣｏｎｔａｃｔＬｉｓｔを持つ。

（グラフィカルユーザインターフェース）
グラフィカルユーザインターフェース（ＧＵＩ）２２０２および２２０４などのインターフェースを使用して、ユーザが、アプリケーションのモビリティ管理に関連する機能を制御および／または構成するのを支援することができる。次の目的でＣＳＥにユーザインターフェースを追加できる：
・ミドルノードまたはサービス層をサポートするエンドデバイスにおけるＡＥコンタクト情報の結果を監視／表示する。これにより、ユーザは、図１６に関して定義されたように（例えば、インターフェース２２０２）、ａｅＣｏｎｔａｃｔＳｕｍｍａｒｙを見ることができる。
・インフラストラクチャノードでサービスプロバイダドメイン全体のＡＥコンタクト情報の結果を監視／表示する。これにより、ユーザは、図１７に関して定義されたように（例えば、インターフェース２２０４）、ａｅＣｏｎｔａｃｔＬｉｓｔを見ることができる。
・ＡＥモビリティイベントの影響を受けるＣＳＥを発見する（インフラストラクチャノードにおいて）。
・ＣＳＥ（ミドルノード、サービス層をサポートするエンドデバイス、またはインフラストラクチャノードのいずれか）でＡＥコンタクト情報を手動で更新する。および／または
・ＭＮ－ＣＳＥをトリガしてＩＮ－ＣＳＥにＵｐｄａｔｅＣｏｎｔａｃｔＩｎｆｏＲｅｑを送信する（ミドルノードまたはサービス層をサポートするエンドデバイスにおいて）。

インターフェース２２０２および２２０４は、後述の図２３Ｃおよび図２３Ｄに示すようなディスプレイを使用して製造することができることを理解されたい。

（環境の例）
図２３Ａは、１つまたは複数の開示されている実施形態を実施することができる例示的なマシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の図である。一般に、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴ用のビルディングブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層などであり得る。図２～図４、図６Ａ～図１９、または図２２のいずれかに示されているクライアント、プロキシ、またはサーバ装置のいずれかは、図２３Ａ～図２３Ｄに示すものなどの通信システムのノードを備え得る。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴなどのアプリケーションプロトコル層の上に置かれ、クライアントアプリケーションに付加価値サービスを提供する。サービス層はまた、例えば制御層およびトランスポート／アクセス層などの下位のリソース層でコアネットワークへのインターフェースを提供する。サービス層は、サービス定義、サービスランタイムの有効化、ポリシー管理、アクセス制御、およびサービスクラスタリングを含む、複数のカテゴリの（サービス）能力または機能をサポートする。近年、いくつかの業界標準化団体、例えば、ｏｎｅＭ２Ｍは、インターネット／ウェブ、セルラー、企業、およびホームネットワークなどの配備へのＭ２Ｍタイプのデバイスおよびアプリケーションの統合に関連する課題に対処するためにＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと呼ばれ得るサービス層によってサポートされる、上述の能力または機能の集合またはセットへのアクセスをアプリケーションおよび／または様々なデバイスに提供することができる。いくつかの例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および様々なアプリケーションで一般的に使用され得る接続管理を含むが、これらに限定されない。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造およびリソース表現を利用するＡＰＩを介してそのような様々なアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装することができ、様々なアプリケーションおよび／またはデバイスに公開される（サービス）能力または機能（すなわち、そのような機能エンティティ間の機能インターフェース）を提供して、そのような能力や機能を使用させる、機能エンティティである。

図２３Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣなど）または無線ネットワーク（例えば、ＷＬＡＮ、セルラーなど）、または異種ネットワークのネットワークとすることができる。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数のユーザに提供する複数のアクセスネットワークから構成され得る。例えば、通信ネットワーク１２は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、産業用制御ネットワーク、パーソナルエリアネットワーク、融合パーソナルネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワークなどの他のネットワークを含むことができる。

図２３Ａに示すように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインとフィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドのＭ２Ｍ配備のネットワーク側を指し、フィールドドメインは、通常Ｍ２Ｍゲートウェイの背後にあるエリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの様々な異なるノード（例えば、サーバ、ゲートウェイ、デバイスなど）を含むことができる。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４およびデバイス１８を含み得る。必要に応じて、任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８をＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含めることができることが理解されよう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のそれぞれは、通信回路網を使用して、通信ネットワーク１２または直接無線リンクを介して信号を送受信するように構成されている。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が通信ネットワーク１２または直接無線リンクなどの事業者ネットワークを介して通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、通信ネットワーク１２または直接無線リンクを介して、Ｍ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８に対して、データを収集し、データを送信することができる。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、後述するように、Ｍ２Ｍサービス層２２を介してＭ２Ｍアプリケーション２０と送受信することができる。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む様々なネットワークを介して通信することができる。例示的なＭ２Ｍ機器は、タブレット、スマートフォン、医療機器、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲーム機、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電化製品、ガレージドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、およびスマートコンセントを含むがこれらに限定されない。

図２３Ｂを参照すると、フィールドドメイン内の図示のＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍデバイス１８ならびに通信ネットワーク１２にサービスを提供する。Ｍ２Ｍサービス層２２は、必要に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信することができることが理解されよう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイスなどを含むことができるネットワークの１つまたは複数のノードによって実装することができる。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、様々な方法で、例えばウェブサーバとして、セルラーコアネットワーク内で、クラウド内などで実施することができる。

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

また図２３Ｂを参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルズが活用することができるサービス配信能力のコアセットを提供する。これらのサービス能力により、Ｍ２Ｍアプリケーション２０および２０’は、デバイスと対話し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見などの機能を実行することができる。基本的に、これらのサービス能力は、これらの機能を実装する負担からアプリケーションを解放し、アプリケーション開発を簡素化し、市場投入までの時間およびコストを削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスに関連してネットワーク１２などの様々なネットワークを介して通信することを可能にする。

Ｍ２Ｍアプリケーション２０および２０’は、限定されることなく、交通、健康およびウェルネス、コネクテッドホーム、エネルギー管理、資産追跡、ならびにセキュリティおよび監視などの様々な産業におけるアプリケーションを含み得る。上述のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードを横断するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、位置追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合などの機能をサポートし、これらの機能をＭ２Ｍアプリケーション２０および２０’へのサービスとして提供する。

一般に、図２３Ｂに示されているサービス層２２および２２’などのサービス層は、一式のアプリケーションプログラミングインターフェース（ＡＰＩ）および基礎となるネットワーキングインターフェースを介して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭアーキテクチャとｏｎｅＭ２Ｍアーキテクチャの両方でサービス層が定義されている。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と呼ばれる。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの様々な異なるノードに実装することができる。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と呼ばれる）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と呼ばれる）および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と呼ばれる）内に実装されてもよい。ｏｎｅＭ２Ｍサービス層は、一式の共通サービス機能（ＣＳＦ）（すなわちサービス能力）をサポートする。一式の１つまたは複数の特定の種類のＣＳＦのインスタンス化は、異なる種類のネットワークノード（例えば、インフラストラクチャノード、ミドルノード、特定用途向けノード）上でホストされ得る共通サービスエンティティ（ＣＳＥ）と呼ばれる。第３世代パートナーシッププロジェクト（３ＧＰＰ）もまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャを定義している。そのアーキテクチャでは、サービス層とそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬに、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）に、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥに、またはネットワークの何らかの他のノードのいずれに実装されていても、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピューティングデバイスまたはノードを含むネットワーク内の１つまたは複数のスタンドアロンノード上で、または１つまたは複数の既存のノードの一部として、のいずれかで実行される、論理エンティティ（例えばソフトウェア、コンピュータ実行可能命令など）として実装することができる。一例として、サービス層のインスタンスまたはその構成要素は、後述する図２３Ｃまたは図２３Ｄに示す一般的なアーキテクチャを有するネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイスなど）上で稼働するソフトウェアの形で実装され得る。

さらに、本明細書で説明される方法および機能は、サービスにアクセスするためにサービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装することができる。

図２３Ｃは、図２～図４、図６Ａ～図１９、または図２２に示すクライアント、サーバ、またはプロキシのうちの１つなど、ネットワークのノードの例示的なハードウェア／ソフトウェアアーキテクチャのブロック図であり、これらは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または図２３Ａおよび図２３Ｂに示すものなどのＭ２Ｍネットワーク内の他のノードとして動作し得る。図２３Ｃに示すように、ノード３０は、プロセッサ３２、固定式メモリ４４、リムーバブルメモリ４６、スピーカ／マイクロフォン３８、キーパッド４０、ディスプレイ、タッチパッド、および／またはインジケータ４２、電源４８、全地球測位システム（ＧＰＳ）チップセット５０、および他の周辺機器５２を含むことができる。ノード３０はまた、送受信機３４および送信／受信要素３６などの通信回路を備え得る。ノード３０は、一実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含み得ることが理解されよう。このノードは、例えば図６Ａ、図６Ｂ、図７、図８、および図１３～図１８に関して説明されている方法、または図１～図６Ｂ、図１０～図１２、および図１９～図２１、表１～表９、もしくは特許請求の範囲のデータ構造に関して本明細書で説明されているようにアプリケーションのモビリティ管理を実施するノードであり得る。

プロセッサ３２は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと協働する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態機械などとすることができる。一般に、プロセッサ３２は、ノードの様々な必要な機能を実行するために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）に格納されたコンピュータ実行可能命令を実行することができる。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはノード３０が無線環境または有線環境で動作することを可能にする任意の他の機能を実行することができる。プロセッサ３２は、アプリケーション層プログラム（例えばブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または他の通信プログラムを実行することができる。プロセッサ３２はまた、例えばアクセス層および／またはアプリケーション層などで、認証、セキュリティ鍵共有、および／または暗号化動作などのセキュリティ動作を実行することができる。

図２３Ｃに示すように、プロセッサ３２は、その通信回路（例えば、送受信機３４および送信／受信要素３６）に結合されている。プロセッサ３２は、コンピュータ実行可能命令の実行を通じて、ノード３０に、それが接続されているネットワークを介して他のノードと通信させるために通信回路を制御することができる。特に、プロセッサ３２は、本明細書（例えば、図６Ａ、図６Ｂ、図７、図８、および図１３～図１８、ならびに図２５）および特許請求の範囲に記載の送信および受信ステップを実行するために通信回路を制御することができる。図２３Ｃは、プロセッサ３２と送受信機３４とを別々の構成要素として示しているが、プロセッサ３２と送受信機３４とは電子パッケージまたはチップに一緒に集積されてもよいことが理解されよう。

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

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

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

プロセッサ３２は、固定式メモリ４４および／またはリムーバブルメモリ４６などの任意のタイプの適切なメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。例えば、プロセッサ３２は、上述のように、セッションコンテキストをそのメモリに格納することができる。固定式メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶装置を含むことができる。リムーバブルメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ３２は、サーバまたは家庭用コンピュータ上など、ノード３０上に物理的に配置されていないメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。プロセッサ３２は、ノードの状態を反映する、またはノード、特にそのノードと通信する基礎となるネットワーク、アプリケーション、または他のサービスを構成するために、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。一実施形態では、ディスプレイ／インジケータ４２は、図２５に示され、本明細書で説明されているグラフィカルユーザインターフェースを提示することができる。

プロセッサ３２は、電源４８から電力を受け取ることができ、ノード３０内の他の構成要素に対して電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に電力を供給するための任意の適切な装置であり得る。例えば、電源４８は、１つ以上の乾電池（例えば、ニッケル・カドミウム（ＮｉＣｄ）、ニッケル・亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

プロセッサ３２はまた、ノード３０の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されるＧＰＳチップセット５０に結合され得る。ノード３０は、一実施形態との整合性を保ちながら、任意の適切な位置判定方法によって位置情報を取得し得ることが理解されよう。

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

ノード３０は、センサ、家庭用電化製品、スマートウォッチまたはスマートウェアなどのウェアラブルデバイス、医療機器またはｅＨｅａｌｔｈデバイス、ロボット、産業機器、無人機、自動車、トラック、電車、または航空機などの航走体などの他の装置またはデバイスで実施することができる。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェースなどの１つ以上の相互接続インターフェースを介してそのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続することができる。

図２３Ｄは、図２～図４、図６Ａ～図１９、または図２２に示され、本明細書で説明されるクライアント、サーバ、またはプロキシなど、ネットワークの１つまたは複数のノードを実装するために使用され得るコンピューティングシステム９０のブロック図であり、これらは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または図２３Ａおよび図２３Ｂに示すものなどのＭ２Ｍネットワーク内の他のノードとして動作し得る。

コンピューティングシステム９０は、コンピュータまたはサーバを備えることができ、どこにまたはどんな手段で記憶またはアクセスされるかを問わないソフトウェアの形態であり得るコンピュータ可読命令によって主に制御され得る。そのようなコンピュータ可読命令は、コンピューティングシステム９０に作業を行わせるために、中央処理装置（ＣＰＵ）９１などのプロセッサ内で実行することができる。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１はマイクロプロセッサと呼ばれるシングルチップＣＰＵによって実施される。他のマシンでは、中央処理装置９１は複数のプロセッサを含むことができる。コプロセッサ８１は、追加の機能を実行する、またはＣＰＵ ９１を支援する、メインＣＰＵ ９１とは異なるオプションのプロセッサである。ＣＰＵ ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証など、Ｅ２Ｅ Ｍ２Ｍサービス層セッションに関する開示されたシステムおよび方法に関するデータを受信、生成、および処理することができる。

動作中、ＣＰ Ｕ９１は、命令をフェッチし、復号し、実行し、またコンピュータの主データ転送経路であるシステムバス８０を介して他のリソースとの間で情報を転送する。このようなシステムバスは、コンピューティングシステム９０内の構成要素を接続し、データ交換のための媒体を規定する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作させるための制御ラインと、を備える。このようなシステムバス８０の一例としては、ＰＣＩ（ペリフェラル・コンポーネント・インターコネクト）バスがある。

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

加えて、コンピューティングシステム９０は、ＣＰＵ ９１からの指示をプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５などの周辺機器に伝達する役割を果たす周辺機器コントローラ８３を備え得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成された視覚的出力を表示するために使用される。このような視覚的出力は、テキスト、グラフィック、アニメーショングラフィック、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルで実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するのに必要な電子構成要素を備える。ディスプレイ８６は、ＣＰＵ ９１によって実行されるコンピュータ実行可能命令と組み合わせて、図２５およびその付随する説明において図示および説明されているグラフィカルユーザインターフェースを生成および動作させることができる。

さらに、コンピューティングシステム９０は、例えば、図２３Ａ～図２３Ｄのネットワーク１２などの外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得るネットワークアダプタ９７などの通信回路を備えて、コンピューティングシステム９０がそれらのネットワークの他の装置と通信できるようにし得る。通信回路は、単独で、またはＣＰＵ ９１と組み合わせて、本明細書（例えば、図１、図３、図５～図８、図１１～図１５、図２０～図２１、図２４、または図２５において）および特許請求の範囲で説明される送信および受信ステップを実行するために使用することができる。

本明細書に記載のシステム、方法、およびプロセスのいずれかまたはすべては、コンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形で実施され、この命令は、例えばＭ２Ｍサーバ、ゲートウェイ、デバイスなどを含むＭ２Ｍネットワークの装置などのマシンによって実行された場合、本明細書に記載のシステム、方法およびプロセスを実行および／または実装し得ることが理解されよう。具体的には、上記のステップ、動作、または機能のいずれも、そのようなコンピュータ実行可能命令の形で実装され得る。コンピュータ可読記憶媒体は、情報を記憶するための任意の非一時的（すなわち、有形または物理的）方法または技術で実装される揮発性および不揮発性の両方、取り外し可能および固定式の媒体を含むが、そのようなコンピュータ可読記憶媒体は信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または所望の情報を記憶するために使用することができ、コンピュータによってアクセスされ得る任意の他の有形または物理的媒体を含むがこれらに限定されない。

本明細書は、最良の形態を含む本発明を開示するため、また任意のデバイスまたはシステムを作成および使用することと、任意の組み込まれた方法を実行することと、を含み、当業者が本発明を実施できるようにするために、例を用いている。本発明の特許可能な範囲は、特許請求の範囲によって定義され、当業者に想到される他の例を含み得る。そのような他の例は、それらが特許請求の範囲の文言と異ならない要素を有する場合、またはそれらが特許請求の範囲の文言とは実質的に異ならない均等な要素を含む場合、特許請求の範囲内に含まれると意図されている。

Claims (19)

1. プロセッサとメモリとを備える装置であって、
   前記装置が、前記装置の前記メモリに格納されたコンピュータ実行可能命令をさらに含み、
   前記コンピュータ実行可能命令が、前記装置の前記プロセッサによって実行された場合に、
   アプリケーションエンティティ（ＡＥ）がモビリティイベントを経たという指示と、前記ＡＥについての更新されたＡＥコンタクト情報とを含むメッセージを受信することと、
   前記ＡＥをターゲットとするサービスのために、前記更新されたＡＥコンタクト情報を前記ＡＥに割り当てることと、
   前記ＡＥモビリティイベントによって影響を受ける１つまたは複数のサービス層を判定することと、
   前記ＡＥモビリティイベントの通知を含む通知メッセージを前記１つまたは複数のサービス層に送信することと、
   を前記装置に行わせる、
   装置。
2. 前記更新されたＡＥコンタクト情報が、前記ＡＥを識別するＵＲＩである、
   請求項１に記載の装置。
3. 前記通知メッセージが、前記ＡＥについての古いＡＥコンタクト情報と前記更新されたＡＥコンタクト情報とを含む、
   請求項１に記載の装置。
4. 前記決定することが、ＡＥコンタクト情報のマスターリストを照会することを含む、
   請求項１に記載の装置。
5. 前記マスターリストが複数のエントリを含み、
   各エントリが、ノードと、前記ノード上のサービスによって使用されるＡＥコンタクト情報とを含む、
   請求項４に記載の装置。
6. 前記装置がＭ２Ｍサーバである、
   請求項１に記載の装置。
7. 前記サービスが、サブスクリプション／通知サービス、アナウンスメントサービス、および、グループサービスのうちの少なくとも１つを含む、
   請求項１に記載の装置。
8. 前記通知メッセージを送信することが、ＮＯＴＩＦＹ要求を介して行われる、
   請求項１に記載の装置。
9. プロセッサとメモリとを備える装置であって、
   前記装置が、前記装置の前記メモリに格納されたコンピュータ実行可能命令をさらに含み、
   前記コンピュータ実行可能命令が、前記装置の前記プロセッサによって実行された場合に、
   アプリケーションエンティティ（ＡＥ）から登録要求を受信することと、
   前記登録要求が、更新されたＡＥコンタクト情報を含むＡＥモビリティイベントであると判定することと、
   前記ＡＥモビリティイベントの通知を含むメッセージをＭ２Ｍサーバに送信することと、
   前記更新されたＡＥコンタクト情報を前記ＡＥに割り当てることと、
   を前記装置に行わせる、
   装置。
10. 前記登録要求が、前記ＡＥが以前に接続していたサービス層の識別子を含む、
    請求項９に記載の装置。
11. 前記命令が実行された場合に、前記ＡＥモビリティイベントの確認をＭ２Ｍサーバから受信することを前記装置にさらに行わせる、
    請求項９に記載の装置。
12. 前記登録要求が、前記ＡＥについてのＡＥモビリティイベントを追跡するための指示を含む、
    請求項９に記載の装置。
13. 前記ＡＥについてのＡＥモビリティイベントを追跡するための前記指示がフラグを含む、
    請求項１２に記載の装置。
14. 前記装置がサービス層をホストするデバイスである、
    請求項９に記載の装置。
15. 前記更新されたＡＥコンタクト情報が、前記ＡＥを識別するＵＲＩを含む、
    請求項９に記載の装置。
16. プロセッサとメモリとを備える装置であって、
    前記装置が、前記装置の前記メモリに格納されたコンピュータ実行可能命令をさらに含み、
    前記コンピュータ実行可能命令が、前記装置の前記プロセッサによって実行された場合に、
    ＡＥコンタクト情報に依拠するサービスを監視することと、
    監視対象のサービスの変更通知をサーバに送信することと、
    ＡＥの古いＡＥコンタクト情報と前記ＡＥの新しいＡＥコンタクト情報とを含む通知メッセージを受信することと、
    前記古いＡＥコンタクト情報に依拠する監視対象のサービスを前記新しいＡＥコンタクト情報で更新することと、
    を前記装置に行わせる、
    装置。
17. 前記変更が、サービスの作成、サービスの変更、サービスの削除、または、それらの任意の組み合わせに対応し得る、
    請求項１６に記載の装置。
18. 前記監視対象サービスが、サブスクリプション／通知サービス、アナウンスメントサービス、および、グループサービスのうちの少なくとも１つを含む、
    請求項１６に記載の装置。
19. 前記装置がサービス層をホストするデバイスである、
    請求項１６に記載の装置。

Images