JP2018513458A - サービス層能力を使用したネットワークおよびアプリケーション管理 - Google Patents

Abstract

本明細書では、サービス層（ＳＬ）のための新しいサービスであるネットワークおよびアプリケーション管理サービス（ＮＡＭＳ）が説明される。例示的実施形態によると、ＮＡＭＳは、アプリケーション、下層ネットワーク、および他のサービスから情報を収集、統合、ならびに処理する。一実施形態において、装置は、その通信回路を介して通信ネットワークに接続されており、装置は、装置のメモリに記憶されたコンピュータ実行可能命令を備え、命令は、装置のプロセッサによって実行されると、ネットワーク上のアプリケーションから通信ネットワークを介して、アプリケーションに関連付けられた少なくとも１つの更新を示す第１のメッセージを受信することと、アプリケーションに関連付けられた少なくとも１つの更新を記憶さすることとを装置に行わせる。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１２６，９３５号（２０１５年３月２日出願）の利益を主張し、上記出願の開示は、その全体が参照により本明細書に引用される。

開発中のｏｎｅＭ２Ｍ規格は、図１に示される「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。ＣＳＥは、ｏｎｅＭ２Ｍ−ＴＳ−０００１，ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｖ０．４．２）でさらに説明されおり、その内容は、本明細書で提示される場合のように、参照することによって組み込まれる。サービス層の目的は、「ホリゾンタル」サービスを提供することであり、「ホリゾンタル」サービスは、例えば、ｅ−ヘルス、フリート管理、ならびにスマートホームに関連するシステムおよびアプリケーション等の、異なる「バーティカル」マシンツーマシン（Ｍ２Ｍ）サイロシステムおよびアプリケーションによって利用されることができる。図１を参照すると、ＣＳＥは、４つの参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点は、同一のサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎは、下層ネットワークをＣＳＥに対して大部分を透過性に保ちながらも、ＣＳＥが下層ネットワーク内の機能にアクセスすることを可能にする標準化インターフェースである。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、例えば、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。下層ネットワークへのＮＳＥのインターフェースは、ｏｎｅＭ２Ｍによって定義されていない。そのようなインターフェースは、典型的には、下層ネットワークによって定義されるが、それらは、ネットワークオペレータによって定義される専用インターフェースであり得る。

図２も参照すると、所与のＣＳＥは、「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含み得る。例示的ＣＳＦは、限定ではないが、提示される、「発見」ならびに「データ管理およびレポジトリ」を含む。図２は、ｏｎｅＭ２Ｍで開発中のＣＳＦを図示する。図示されるネットワークサービスエクスポージャ、サービス実行、およびトリガ（ＮＳＳＥ）機能は、下層ネットワークとインターフェースをとる。ＮＳＳＥによってサポートされる現在の機能は、デバイストリガおよび場所管理である。図２に示されるアプリケーションおよびサービス層管理（ＡＳＭ）ＣＳＦは、ＣＳＥまたはアプリケーションエンティティ（ＡＥ）のソフトウェアモジュールのために、例えば、サービス層においてソフトウェアをインストール、アクティブ化、および非アクティブ化するためのソフトウェア構成ならびに管理を提供する。

ｏｎｅＭ２Ｍに先立って、ＥＴＳＩ Ｍ２Ｍは、ＥＴＳＩ ＴＳ １０２．６９０，Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ（Ｍ２Ｍ） Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｖ２．１．１）で定義されるそれ自身のサービス層指向Ｍ２Ｍ規格を公開しており、その内容は、本明細書に記載される場合のように、参照することによって組み込まれる。ｏｎｅＭ２Ｍのアーキテクチャは、ＥＴＳＩ Ｍ２Ｍに類似する。ＥＴＳＩ Ｍ２Ｍは、サービス能力と呼ばれる種々のサービスモジュールから成るサービス能力層エンティティを定義した。サービスは、ネットワークエクスポージャサービス能力によって、下層ネットワークにエクスポーズされることができる。

ここで図３を参照すると、３ＧＰＰは、３ＧＰＰ ＴＳ ２３．６８２，Ａｒｃｈｉｔｅｃｔｕｒｅ ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ ｆａｃｉｌｉｔａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｗｉｔｈ ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎｓ，Ｒｅｌｅａｓｅ １１，Ｖ１２．０．０においてＭＴＣアーキテクチャを定義し、その内容は、本明細書に記載される場合のように、参照することによって組み込まれる。外部ネットワーク内のＭＴＣアプリケーションは、典型的には、アプリケーションサーバ（ＡＳ）によってホストされ、追加の付加価値サービスのためにＳＣＳを利用し得る。３ＧＰＰシステムは、トランスポート、サブスクライバ管理、およびＭＴＣデバイスのための種々のアーキテクチャの増進を含む他の通信サービス（例えば、制御プレーンデバイストリガ）を提供する。３ＧＰＰは、ＭＴＣデバイスのための３つの通信モデル、すなわち、直接モデル、間接モデル、およびハイブリッドモデルを定義した。直接モデルでは、ＡＳは、オペレータネットワークに直接接続し、いかなる外部ＳＣＳも使用することなくユーザ機器（ＵＥ）との直接ユーザプレーン通信を行う。外部ネットワーク内のアプリケーションは、３ＧＰＰシステムによって提供されるサービスを利用し得る。間接モデルでは、ＡＳは、ＳＣＳのサービスを通してオペレータネットワークに間接的に接続し、ＭＴＣのための追加の付加価値サービス（例えば、制御プレーンデバイストリガ）を利用する。ハイブリッドモデルでは、ＡＳは、直接モデルおよび間接モデルを同時に使用し、オペレータのネットワークに直接接続し、ＳＣＳも使用しながら、ＵＥとのユーザプレーン通信を直接行う。３ＧＰＰネットワークの観点から、ＡＳからの直接ユーザプレーン通信と、ＳＣＳからの任意の付加価値制御プレーン関連通信とは、独立しており、それらは、たとえそれらがＡＳによってホストされる同じＭＴＣアプリケーションにサービス提供していることがあっても、互いに相関関係を有しない。

図３は、上で参照されるｏｎｅＭ２Ｍアーキテクチャ仕様から再現されている。図３は、ｏｎｅＭ２Ｍ参照点が３ＧＰＰ ＭＴＣアーキテクチャに適用されることができる方法を描写する。アプリケーションサービスノードは、１つの共通サービスエンティティ（ＣＳＥ）を含み、少なくとも１つのアプリケーションエンティティ（ＡＥ）を含むノードである。例えば、アプリケーションサービスノードは、Ｍ２Ｍデバイスであることができる。インフラストラクチャノード（ＩＮ）は、１つの共通サービスエンティティを含み、ゼロ以上のアプリケーションエンティティを含むノードである。例えば、ＩＮは、ネットワークサーバであることができる。図３に示されるＭｃｃ参照点は、３ＧＰＰネットワークの上でＩＮ−ＣＳＥとＡＳＮ−ＣＳＥとの間にある。

３ＧＰＰは、３ＧＰＰ ＴＳ ３２．１０１ Ｔｅｌｅｃｏｍｍｕｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ： Ｐｒｉｎｃｉｐｌｅｓ ａｎｄ ｈｉｇｈ ｌｅｖｅｌ ｒｅｑｕｉｒｅｍｅｎｔｓにおいて、ネットワーク管理のためのそのＯｐｅｒａｔｉｏｎｓ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，Ｍａｉｎｔｅｎａｎｃｅ（ＯＡＭ）アーキテクチャを定義し、その内容は、本明細書に記載される場合のように、参照することによって組み込まれる。説明されるように、ネットワークマネージャ（ＮＭ）は、デバイスおよび機器等のネットワーク要素の管理に対する責任を伴う機能のパッケージを提供する。管理機能は、アカウント管理、障害管理、サービス品質（ＱｏＳ）、性能管理等を含む。管理プロシージャは、例えば、シンプルネットワークマネージメントプロトコル（ＳＮＭＰ）等のオープン規格によってサポートされる。

ＲＦＣ ３４１１で定義されるようなシンプルネットワークマネージメントプロトコル（ＳＮＭＰ）は、ＯＳＩモデルにおけるアプリケーション層プロトコルと見なされる。ＳＮＭＰは、一般的に、ネットワーク内のデバイスを管理するために使用される。ネットワーク管理のためにＳＮＭＰを使用するコンピュータネットワークシステムは、以下のコンポーネントから成り得る：ＳＮＭＰマネージャ、ＳＮＭＰエージェント、およびＳＮＭＰ管理情報ベース（ＭＩＢ）。ＳＮＭＰマネージャは、コンピュータネットワークを管理するネットワーク管理者または任意の人間のマネージャのマシン上で起動するソフトウェアであり得る。ＳＮＭＰエージェントは、監視されるネットワークノード上で起動するソフトウェアを指し得る。このノードは、プリンタ、ルータ等であり得る。ＲＦＣ ３４１８で定義されるＳＮＭＰ ＭＩＢは、マネージャとエージェントとの間のデータ交換が構造化されたままであることを確実にするコンポーネントである。ＭＩＢは、ツリー構造で構築され、構造の基本的コンポーネントは、オブジェクトである。例えば、システム動作可能時間は、「ｉｓｏ．ｏｒｇ．ｄｏｄ．ｉｎｔｅｒｎｅｔ．ｍｇｍｔ．ｍｉｂ−２．ｓｙｓｔｅｍ．ｓｙｓＵｐＴｉｍｅ」として表されることができる。

マネージャとエージェントとの間のＳＮＭＰ通信は、メッセージの形態で行われる。通信に使用される基本的な例示的メッセージは、ＳＮＭＰ ＧＥＴ、ＳＮＭＰ ＧＥＴ−ＮＥＸＴ、ＳＮＭＰ ＧＥＴ−ＲＥＳＰＯＮＳＥ、ＳＮＭＰ ＳＥＴ、およびＳＮＭＰ ＴＲＡＰを含む。ＧＥＴおよびＧＥＴ−ＮＥＸＴというメッセージは、特定のＭＩＢオブジェクトの値をフェッチするために使用される。ＧＥＴ−ＲＥＳＰＯＮＳＥというメッセージは、大抵、ＧＥＴまたはＧＥＴ−ＮＥＸＴメッセージへの応答を送信するために、エージェントによって使用される。ＳＥＴというメッセージは、エージェントにおける特定のＭＩＢオブジェクトの新しい値を設定するためにマネージャによって使用される。ＴＲＡＰというメッセージは、あるオブジェクトのためのある警戒値についての情報をマネージャに送信するために、エージェントによって使用される。

ＳＮＭＰを通して、ルータ、プリンタ、ハブ、または一般的コンピュータ等のネットワークデバイスについての情報を読み出すことができる。読み出される情報は、システム動作可能時間、ＣＰＵ使用レベル、ネットワーク設定等を含み得る。デバイスはＳＮＭＰによって構成されることもできる。

ＳＮＭＰは、通常、全体的な管理フレームワークを提供するためのポリシと連動する。例えば、ネットワーク管理者は、システムログメッセージに基づいてイベントのためのトラップを呼び出すイベントポリシを構成することができる。閾値ポーリングポリシは、例えば、メモリ使用量等のシステムおよびネットワーク情報を監視するために、異なる閾値を設定することができる。

Ｗ３Ｃネットワーク情報ＡＰＩは、ウェブアプリケーションのために、デバイスの下層接続情報にアクセスするためのインターフェースを提供する。Ｗ３Ｃ仕様は、現在、ユーザエージェントに２つのプロパティ、すなわち、帯域幅および計測をエクスポーズすることを要求している。インターフェースは、直接的にアプリケーションと下層ネットワークとの間にあると考えられる。

過負荷、輻輳、および弱い信号強度等の潜在的ネットワークコネクティビティ問題は、限定されないが、例えば、接続インタラプト等の最適化されていないエンドツーエンドＭ２Ｍ接続を引き起こし得る。ある場合には、ネットワークにわたり起動するアプリケーションは、ネットワーク状況を認識していないか、または、アプリケーションは、それらが常駐するローカルネットワークの状態のみを認識し得る。ネットワーク問題は、アプリケーションレベルでの接続の長い遅延およびドロップさえも引き起こし得る。そのような問題は、非Ｍ２ＭシステムならびにＭ２Ｍシステムに該当し得る。問題は、例えば、多数のアプリケーション、制約された（例えば、低電力、損失性）デバイス、およびローカルネットワーク内の限界等の種々の要因に起因して、非Ｍ２ＭシステムよりもＭ２Ｍネットワーク内で明白であり得る。例えば、制約されたアプリケーションは、接続問題をハンドリングするために内蔵知能をサポートすることが可能でないこともある。別の例として、制約されたアプリケーションは、ネットワーク接続の変化にもかかわらず、それらのトランザクションを保ち得る。さらに別の例として、制約されたアプリケーションは、典型的には、他のアプリケーションを考慮して、それらのトランザクションを適合させることができない。したがって、上で説明されるように、例えば、リソースが制約された（例えば、Ｍ２Ｍ）デバイスを伴うネットワーク内のネットワークおよびアプリケーション管理への現在のアプローチは、能力および効率を欠いている。

本明細書では、サービス層（ＳＬ）のための新しいサービスであるネットワークおよびアプリケーション管理サービス（ＮＡＭＳ）が説明される。例示的実施形態によると、ＮＡＭＳは、アプリケーション、下層ネットワーク、および他のサービスから情報を収集、統合、ならびに処理する。ＮＡＭＳは、アプリケーションおよび下層ネットワークを最適化するように、それ自身のポリシに基づいて出力を生成し得る。多くの実施例が、Ｍ２Ｍシステムとの関連で本明細書に提示されるが、ＮＡＭＳは、Ｍ２Ｍシステムおよび非Ｍ２Ｍシステムで実装され得ることが理解されるであろう。

例示的実施形態では、ＮＡＭＳを含む装置は、プロセッサと、メモリと、通信回路とを備える。装置は、その通信回路を介して通信ネットワークに接続されており、装置はさらに、装置のプロセッサによって実行されると、装置に、ネットワーク上の第１のノードから通信ネットワークを介して、ネットワークに関連付けられた少なくとも１つのステータス更新を示す第１のメッセージを受信させる、装置のメモリに記憶されたコンピュータ実行可能命令を備える。装置は、ネットワークに関連付けられた少なくとも１つのステータス更新を記憶し、少なくとも１つのステータス更新がアプリケーションまたはサービスに影響を及ぼすかどうかを決定し得る。少なくとも１つのステータス更新がアプリケーションまたはサービスに影響を及ぼす場合、装置は、アプリケーションまたはサービスが少なくとも１つのステータス更新に基づいてアクションをとることができるように、少なくとも１つのステータス更新を示す第２のメッセージを、アプリケーションまたはサービスをホストする第２のノードに送信し得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

図１は、ｏｎｅＭ２Ｍアーキテクチャのブロック図である。 図２は、ｏｎｅＭ２Ｍアーキテクチャの共通サービス機能（ＣＳＦ）を図示する。 図３は、マシンタイプ通信（ＭＴＣ）のための３ＧＰＰアーキテクチャのブロック図である。 図４は、ネットワークおよび管理サービス（ＮＡＭＳ）を含まない例示的マシンツーマシンシステム（Ｍ２Ｍ）を描写する。 図５は、図４で描写される例示的Ｍ２Ｍシステムを描写するが、例示的実施形態によるＮＡＭＳも含む。 図６は、例示的実施形態による、ネットワークおよびアプリケーション管理サービス（ＮＡＭＳ）がサービス層（ＳＬ）アーキテクチャ内で適合することができる方法を示す。 図７は、例示的実施形態による、ＮＡＭＳがサービス層機能的アーキテクチャに適合することができる方法を示す。 図８は、例示的実施形態による、ＮＡＭＳの例示的副機能を示す、ＮＡＭＳのブロック図である。 図９は、別の例示的実施形態による、ＮＡＭＳと相互作用する独立型適応サービスとして図８の副機能を示す。 図１０は、ＮＡＭＳおよびそれに関連付けられた適応サービスによって行われることができる例示的動作を示す、アプリケーションからネットワークへのフローを描写するフロー図である。 図１１は、ＮＡＭＳおよびそれに関連付けられた適応サービスによって行われることができる例示的動作を示す、ネットワークからアプリケーションへのフローを描写するフロー図である。 図１２は、例示的実施形態による、アプリケーション、ネットワーク、および他のサービスを構成するＮＡＭＳを示すコールフローである。 図１３は、例示的実施形態による、アプリケーション、ネットワーク、および他のサービスから種々の情報を収集するＮＡＭＳを示すコールフローである。 図１４は、例示的実施形態による、収集された情報を処理し、アプリケーション、ネットワーク、および他のサービスのための入力を生成するＮＡＭＳを示すコールフローである。 図１５は、例示的実施形態による、サービス層支援ネットワーク最適化の例を図示するフローである。 図１６は、例示的実施形態による、サービス層支援ネットワーク最適化の例を図示するフローである。 図１７は、サービス層におけるＮＡＭＳを示す例示的プロトコルスタックである。 図１８は、ＮＡＭＳがｏｎｅＭ２Ｍリソース指向アーキテクチャ（ＲｏＡ）に適合することができる方法の例を示す。 図１９Ａおよび１９Ｂの各々は、ＮＡＭＳによって使用されることができる、例示的リソース構造を示す。 図２０は、ＨＴＴＰプロトコルおよび図１９Ａに示されるリソース構造を使用して、ＮＡＭＳとアプリケーションエンティティとの間で交換される例示的メッセージを示すコールフローである。 図２１は、ＮＡＭＳおよびそれに関連する機能がｏｎｅＭ２Ｍサービス指向アーキテクチャ（ＳｏＡ）に適合することができる方法の例を示す。 図２２は、例示的実施形態による、ＭＱＴＴプロトコルを使用して、ＮＡＭＳ、サーバ、およびクライアントの間で交換される例示的メッセージを示すコールフローである。 図２３は、例示的実施形態による、ＮＡＭＳによって使用されることができる例示的ネットワークサービスエンティティ（ＮＳＥ）インターフェースのブロック図である。 図２４は、例示的実施形態による、図２３に示されるＮＳＥインターフェースと、ＮＡＭＳとを含む、３ＧＰＰ間接およびハイブリッドモデルのブロック図である。 図２５Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２５Ｂは、図２５Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２５Ｃは、図２５Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２５Ｄは、図２５Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。 （記載なし）

本明細書で使用される場合、別様に規定されない限り、「サービス層」という用語は、論理エンティティを指す。サービス層は、例えば、マシンツーマシン（Ｍ２Ｍ）アプリケーションまたはモノのインターネット（ＩｏＴ）アプリケーション等のサービス層の上のアプリケーションによって共有され得るサービス機能から成ることができる。別様に規定されない限り、Ｍ２ＭおよびＩｏＴという用語は、限定ではないが、同義的に使用されることができる。「エンドノード」という用語は、サービス層エンティティを含む場合も、含まない場合もあるデバイス（例えば、制約されたデバイス）を指す。本明細書で使用される場合、インフラストラクチャノードは、サービス層エンティティを含み、アプリケーションを含む場合も、含まない場合もあるネットワークサーバを指し得る。本明細書で使用される場合、中間ノードは、サービス層エンティティを含み、アプリケーションを含む場合も、含まない場合もあるゲートウェイを指す。ここで、本明細書で使用される例示的参照点を参照すると、Ｍｃａ参照点は、アプリケーションとサービス層との間の通信を指定する。Ｍｃｎ参照点は、サービス層と下層ネットワークとの間の通信を指定する。Ｍｃｃ参照点は、互いに同一のサービスプロバイダドメイン内にある、１つのサービス層と別のサービス層との間の通信を指定する。Ｍｃｃ’参照点は、互いに異なるサービスプロバイダドメイン内にある、１つのサービス層と別のサービス層との間の通信を指定する。Ｍｆｆ参照点は、互いに同一のサービス層内の異なるサービス機能間の通信を指定する。

上で説明されるように、種々のネットワーク問題が、最適化されていないＭ２Ｍ接続を引き起こし得る。一例として、図４は、Ｍ２Ｍシステムに関連付けられることができる問題の例を描写する。図４を参照すると、ユーザ（Ａｌｉｃｅ）が、自分の電話上に２つのスマートホームアプリケーション（アプリ）を有する。１つのアプリケーションは、エネルギー制御のためであり、１つのアプリケーションは、ホームセキュリティのためである。ユーザは、時々、監視カメラおよびエネルギー制御システムからレポートを受信し、システムを遠隔で構成することができる。家に帰る途中、Ａｌｉｃｅは、地下鉄に１時間乗り、その時間中、自分のスマートフォン上のセルラー信号を失う。この期間中、自分のホームエネルギー制御およびセキュリティシステムからのいかなるレポートも配信されないであろう。しかしながら、アプリおよびデバイスの制約された性質に起因して、それらは、電話上の接続の変化を認識せず、配信不能メッセージを送信することを防止することができない。

本明細書では、上での既存の機構は、とりわけ、上での例で例証される問題に十分に対処しないことが認識される。例えば、ＳＮＭＰ等のネットワーク管理プロトコルを使用することによって、ネットワーク管理者は、ネットワーク接続のアラームを得ることができ、デバイスを構成することができる。本明細書では、既存のＳＮＭＰポリシは、アラームのトリガを構成するために使用されることができることが認識される。しかしながら、ＳＮＭＰは、アプリケーション情報を有しておらず、したがって、アプリケーションへのインタラプトを防止するようにアプリケーションに知らせることができない。さらに、本明細書では、３ＧＰＰネットワーク管理機能は、セルラー接続を管理することができるが、キャピラリおよびローカルネットワークを管理せず、キャピラリおよびローカルネットワークに関する情報も有していないことが認識される。クロスレイヤネットワーク管理機構は、ノードにおけるＭＡＣ、ＩＰ、およびアプリケーション層等の異なる層のプロトコルを伴う。そのような機構は、同一のノード内の上層への下層ネットワークの影響を軽減し得るが、エンドツーエンドシナリオを管理するための限界を有し得る。例えば、接続がＴＣＰに基づく場合、ＴＣＰ輻輳制御および低速始動は、送信されるデータの量を低減させ得る。

したがって、本明細書では、既存の機構は、例えば、エンドツーエンドシステム内でそれらが有する限定された役割および情報に起因する問題に完全には対処しないことが認識される。既存の機構は、本質的に反応性でもあり、したがって、それらは、種々の問題が起こることを防止するように設計されていない。

本明細書では、サービス層が、アプリケーション、サービス、および下層ネットワークからの情報を認識しているので、サービス層は、既存の機構と比較して、上での例によって例証される問題等の種々の問題を対処するための候補であることが認識される。さらに、サービス層は、ネットワークおよびアプリケーション管理目的で、そのような情報を集約することができる。現在、異なる下層ネットワークを監視かつ管理し、適切な情報をアプリケーションに提供することができる（または逆も同様である）サービスが存在していない。加えて、本明細書では、サービス層は、現在利用可能ではない、エンドツーエンド通信への高度最適化を提供できることが認識される。本明細書に説明されるように、サービス層において種々の機能を実装することは、下層ネットワークとのある相互作用からアプリケーションを解放することもできる。これは、例えば、Ｍ２Ｍデバイス等のリソース制約されたデバイスに特に有用であり得る。

本明細書に説明される実施形態は、上での例によって例証されるエンドツーエンド通信問題等の種々の通信問題に対処する。以下で説明されるように、例示的実施形態では、エンドツーエンド通信に関与する種々の下層ネットワークの状態が、互いの間で交換されることができる。これらのネットワークは、異なるオペレータに属し得る。同様に、エンドツーエンド通信に関与するアプリケーションの特性が、交換され、下層ネットワークに把握されることができる。情報のそのような交換は、アプリケーションにわたり、ネットワークにわたり、領域にわたり得る。本明細書では、サービス層（ＳＬ）は、アプリケーションと下層ネットワークとの間に常駐するので、ＳＬが種々の通信目標を達成する良好な候補であることが認識される。ＳＬは、アプリケーションおよびネットワーク関連情報を別のＳＬとホリゾンタルに交換することができる。本明細書に説明されるように、ＳＬは、それに関連付けられたポリシを有することもでき、集約された情報を知的に処理することができる。

以下でさらに説明される例示的実施形態によると、アーキテクチャフレームワークは、ＳＬがアプリケーション、下層ネットワーク、および他のサービスのための貴重な入力を提供することを可能にする。したがって、ＳＬは、既存の問題に対処する最適な解決策を提供することができるだけでなく、現在利用可能ではない新しい通信モデルを可能にすることもできる。本開示は、ＳＬのための新しいサービスとしてネットワークおよびアプリケーション管理サービス（ＮＡＭＳ）を説明する。例示的実施形態によると、ＮＡＭＳは、アプリケーション、下層ネットワーク、および他のサービスから情報を収集し、統合し、処理する。ＮＡＭＳは、それ自身のポリシに基づいて、アプリケーションおよび下層ネットワークを最適化するための出力を生成し得る。多くの例が、Ｍ２Ｍシステムとの関連で本明細書に提示されるが、ＮＡＭＳは、Ｍ２Ｍシステムおよび非Ｍ２Ｍシステムで実装され得ることが理解されるであろう。

前置きとして、例示的実施形態によると、ＳＬアーキテクチャは、ネットワークおよびアプリケーション管理、アプリケーション適応、ネットワーク適応、ならびにサービス適応等の種々の副機能を含むＮＡＭＳを含む。種々の参照点（例えば、Ｍｃａ、Ｍｃｃ、Ｍｃｃ’、Ｍｃｎ、Ｍｆｆ）を経由して送信される種々の動作およびメッセージが、以下で説明される。ＮＡＭＳによって行われる種々の動作が、以下で説明される。さらに、本明細書では、ＮＡＭＳによって集約され、生成されることができる特定の情報が定義される。

図５−１６、１８−２２、および２４（以降で説明される）は、ネットワークならびにアプリケーションを管理する方法および装置の種々の実施形態を図示する。これらの図では、１つ以上のクライアント、サーバ、および／もしくはプロキシによって行われている種々のステップまたは動作が、示されている。これらの図に図示されるクライアント、サーバ、およびプロキシは、通信ネットワーク内の論理エンティティを表し得、以下で説明される図２５Ａまたは２５Ｂに図示される一般的アーキテクチャのうちの１つを備え得るそのようなネットワークのノードのメモリに記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることが理解される。すなわち、図５−１６、１８−２２、および２４に図示される方法は、例えば、図２５Ｃまたは２５Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリに記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図に図示されるステップを行う。これらの図に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路（例えば、それぞれ、図２５Ｃおよび２５Ｄの回路３４または９７）によって行われ得ることも理解される。

ここで図５を参照すると、例示的実施形態による、図４に図示される問題が、ＮＡＭＳ１００およびそれに関連するメッセージを用いて解決される方法の例示的使用事例が図示されている。丸は、ＳＬが図示される使用事例で常駐する場所を示す。参照番号は、同一または類似特徴を表すように種々の図で繰り返されることが理解されるであろう。

依然として図５を参照して、図示される例によると、０では、エネルギー制御アプリ（Ａｐｐ１）およびホームセキュリティアプリ（Ａｐｐ２）が、ユーザ（Ａｌｉｃｅ）のスマートフォン５０６上のＳＬに登録される。スマートサーモスタット５０２およびセキュリティカメラ５０４が両方とも、ホームゲートウェイ（ＧＷ）５０８におけるＳＬに登録される。１では、スマートフォン５０６が、（概して、限定ではないが、インターネット５１０またはネットワーク５１０と称されることができる、クラウド５１０内で示される）インフラストラクチャノード内のＳＬにおける場所サービスを使用する。図示される例によると、電話５０６は、その場所をクラウド５１０におけるＳＬに周期的に報告する。例では、電話５０６は、Ａｌｉｃｅが地下鉄に入るときにその更新を報告する。２では、インフラストラクチャノードにおけるＮＡＭＳ１００が、下層セルラーネットワーク５１２から、ネットワーク対象範囲情報を前もって取得している。ある場合には、ＮＡＭＳ１００は、ネットワーク５１２の地理的対象範囲を受信する。インフラストラクチャノードにおけるＮＡＭＳ１００は、例えば、その場所更新に基づいて、電話５０６等のデバイスが対象範囲から外れているかどうかを評価するようにＮＡＭＳ１００をトリガするポリシを有する。デバイスが対象範囲から外れている場合、ＮＡＭＳ１００は、対象範囲から外れているデバイス上のアプリケーションを標的にする、いかなるトランザクションも停止し得る。図示される例によると、ＮＡＭＳ１００は、電話５０６がそのネットワーク接続を失っていることを決定する。

３では、図示される例によると、ＮＡＭＳ１００が、Ａｐｐ１およびＡｐｐ２と通信するアプリケーションを含む他のＳＬにＳＬ交換メッセージを送信する。例示的交換メッセージは、以下の表１に列挙され、以下でさらに説明される。ＳＬ交換メッセージは、デバイス（電話５０６）ＳＬ上のＡｐｐ１およびＡｐｐ２へのメッセージが停止されるべきであることを示す。ＮＡＭＳ１００は、アプリケーション登録サービスおよびデータ交換サービス等のＳＬにおける他のサービスから、そのような情報を取得することができる。４では、ＳＬ交換メッセージを受信すると、ホームＧＷ５０８におけるＳＬが、それ自身のポリシに基づいて決定を行うことができる。例えば、ホームＧＷ５０８におけるＳＬは、Ａｐｐ１およびＡｐｐ２のためのメッセージをバッファリングすることができる。代替として、または加えて、ホームＧＷ５０８におけるＳＬは、エネルギー制御デバイス５０２およびホームセキュリティデバイス５０４がメッセージをＡｐｐ１およびＡｐｐ２に送信することを停止させるためのメッセージをそれらに送信することができる。

したがって、図５の例示的使用事例によって示されるように、ＮＡＭＳは、通信問題が起こることを防止することができ、したがって、ネットワークトラフィックを低減させること、ユーザのためのアプリケーション通信体験を改善すること等もできる。さらに、ＮＡＭＳ１００は、上での例示的使用事例で説明される問題等の種々の問題に対処する高度な特徴をサポートする負担から、制約されたデバイスおよびアプリケーションを解放することができる。例えば、ＮＡＭＳ１００は、制約されたデバイスおよびアプリケーションが、単純論理ならびに軽量プロトコルをサポートすることのみ必要とすることを可能にすることができる。ＮＡＭＳ１００は、異なるノードからＳＬにおいて入手可能な情報を関連付け、複数のデバイス、アプリケーション、または下層ネットワークのために、統合された決定およびアクションを行うことができる。

ここで図６を参照すると、例示的サービス層アーキテクチャ６００が示されている。図６は、ネットワークおよびアプリケーション管理サービス（ＮＡＭＳ）１００が、ＳＬアーキテクチャ、例えば、アーキテクチャ６００内で適合することができる方法の高レベル図を提供する。ＳＬアーキテクチャは、エンドノード６０２と、中間ノード６０４と、インフラストラクチャノード６０６とを含む。ノードの各々は、サービス層６０８を含む。例えば、示されるように、エンドノード６０２は、第１のＳＬ６０８ａを含み、中間ノード６０４は、第２のＳＬ６０８ｂを含み、インフラストラクチャノード６０６は、第３のＳＬ６０８ｃを含む。したがって、示されるように、ＳＬアーキテクチャ６００は、図示されるノードの各々にサービス層ミドルウェアを含み、サービス層の各々は、ネットワークおよびアプリケーション管理サービス機能１００を含む。各ノードは、下層アクセスネットワークに接続される。一例として、エンドノード６０２は、８０２．１５．４ネットワークに接続され得る。さらなる例として、示されるように、中間ノード６０４は、２つの無線（例えば、それがエンドノードのグループに接続することができるように８０２．１５．４のための１つ、および３ＧＰＰセルラーネットワークがバックボーンネットワークに接続するための１つ）を有し得る。インフラストラクチャノードは、有線ネットワークを介してインターネットに接続し得る。異なるノードにおけるサービス層６０８は、互いに通信することができる。ノードの各々は、１つ以上のアプリケーション６１０をホストすることができる。下層ネットワークは、所望に応じて変動し得ることが理解されるであろう。

ここで図７を参照すると、例示的サービス層機能的アーキテクチャ７００が示されている。図７は、ＮＡＭＳ１００がサービス層機能的アーキテクチャ、例えば、ＳＬ機能的アーキテクチャ７００に適合することができる方法を示す。本明細書に説明されるように、種々の実施形態によると、ＮＡＭＳ１００は、サービス層、例えば、図７で描写されるサービス層６０８に常駐するサービスである。ＮＡＭＳ１００は、アプリケーション６１０から情報を受信して処理し、下層ネットワーク、例えば、図７で描写される下層ネットワーク７０２の要件を生成し、結果を下層ネットワーク７０２に伝え得る。ＮＡＭＳ７００は、下層ネットワークから情報を受信し、情報を処理し、情報をアプリケーションにパスすることもできる。参照点に行われ得る論理および動作に関するさらなる詳細が、以下で提示される。図示される参照点は、ｏｎｅＭ２Ｍ参照点であるが、ｏｎｅＭ２Ｍ参照点は、例の目的で提示され、ＮＡＭＳ１００は、所望に応じて、ｏｎｅＭ２Ｍに加えて他の参照点を使用して実装され得ることが理解されるであろう。

図示される実施形態によると、ＮＡＭＳ１００を促進する適応サービスが提案される。例示的適応サービスは、アプリケーション適応サービス７０６と、ネットワーク適応サービス７０８と、サービス適応７１０とを含む。アプリケーション適応サービス７０６は、アプリケーション６１０のためのコンタクトおよび集約点としての役割を果たし得る。ネットワーク適応サービス７０８は、下層ネットワーク７０２のためのコンタクトおよび集約点としての役割を果たし得る。サービス適応７１０は、２つ以上のサービス層エンティティ間のコンタクトおよび集約点としての役割を果たし得る。

例示的実施形態によると、適応サービスの使用は、ＮＡＭＳ１００に対して随意である。適応サービスは、ＮＡＭＳ１００と他のエンティティとの間の通信の効率を増加させ得る。代替として、例えば、サービス層６０８が上での適応サービスを含まない場合、ＮＡＭＳ１００は、種々のアプリケーション６１０、下層ネットワーク７０２、および他のサービス層と直接インターフェースをとる。例えば、図８で描写される例では、適応サービスは、ＮＡＭＳ１００の副機能である。図９で描写される代替例では、適応サービスは、ＮＡＭＳ１００とは別個である。

図８を参照して、図示される実施形態によると、ＮＡＭＳ１００は、適応副機能、例えば、アプリケーション適応副機能１０２と、ネットワークおよびアプリケーション管理副機能１０４と、ネットワーク適応副機能１０６と、サービス適応副機能１０８とを含む。したがって、ＮＡＭＳ１００は、（Ｍｃａを介して）アプリケーション６１０、（Ｍｃｎを介して）下層ネットワーク機能、および（Ｍｆｆを介して）同一のサービス層または（ＭｃｃもしくはＭｃｃ’を介して）異なるサービス層上の他のサービスと直接インターフェースをとる。

図９で描写される代替実施形態を参照すると、適応機能と称されることもできる適応サービスは、ＮＡＭＳ１００に加えて、他のサービス（例えば、他のＣＳＦ）を提供し得る一般的機能である。したがって、適応サービスは、ＮＡＭＳ１００の外側にある。図９に示されるように、ＮＡＭＳ１００は、Ｍｆｆを介して適応機能とインターフェースをとり得る。したがって、適応機能は、ＮＡＭＳ１００に関連する特徴を含むだけではなく、適応機能は、他のサービス、アプリケーション、および／または下層ネットワークによって使用され得る特徴（例えば、サービスディスパッチならびに統合）も含み得る。

ここで、ＮＡＭＳ１００の例示的副機能が説明される。上で説明されるように、副機能は、ＮＡＭＳ１００とは別個であるサービスとして実装されることもできる。したがって、以下の説明は、便宜上、ＮＡＭＳ１００の副機能を参照し得るが、副機能は、独立型サービスとして実装されることができることが理解されるであろう。同様に、以下の説明は、便宜上、ＮＡＭＳ１００と相互作用するサービスを参照し得るが、サービスは、ＮＡＭＳ１００内で副機能として実装されることができることが理解されるであろう。

例示的実施形態では、ネットワークおよびアプリケーション管理副機能１０４は、ＮＡＭＳ１００のための処理センタである。ネットワークおよびアプリケーション副機能１０４は、（アプリケーション適応機能１０２を介して）アプリケーションから収集される情報、（ネットワーク適応機能１０６を介した）下層ネットワークからの情報、および（サービス適応機能１０８を介した）他のサービスからの情報を有し得る。ある場合には、ＮＡＭＳ１００の主要機能は、アプリケーション、サービス、および下層ネットワークからの情報を分析し、通信を最適化することである。

ＮＡＭＳ１００は、収集された情報を分析することができるように、それが収集する情報の関連付けを構築し得る。例えば、ＮＡＭＳ１００は、アプリケーションを、アプリケーションが起動している下層ネットワークに関連付け得る。多くの場合、そのような情報は、アプリケーション登録情報に含まれない。したがって、例えば、アプリケーションを関与する下層ネットワークに関連付けるために、ＮＡＭＳ１００は、（例えば、「登録」サービスから）アプリケーションが登録されているサービス層を決定することができ、次いで、ＮＡＭＳ１００は、決定されたサービス層のための下層ネットワークを決定することができる。図８に図示されるように、ＮＡＭＳ１００は、同一のサービス層を伴う他のサービスへのインターフェース（Ｍｆｆ）を有する。異なるＮＡＭサービス（ＮＡＭＳ）が、Ｍｃｃ参照点を介して、それらの出力を互いに交換することができる。

ＮＡＭＳ１００は、そのポリシに基づいて、決定または推奨を行い、出力を生成し得る。ある場合には、ポリシは、構成可能であり、各ＮＡＭＳは、互いに異なる複数のポリシを保持することができる。例えば、ビジネス関係に応じて、ポリシは、サービスプロバイダによって、下層ネットワークのオペレータによって、またはアプリケーションによって、提供されることができる。異なるポリシが、異なる範囲に適用されることができる。一例として、所与のサービスプロバイダのポリシが、所与のサービスプロバイダによるサービス層に登録されている全てのアプリケーションに適用され得る。別の例として、所与のアプリケーションのポリシは、所与のアプリケーションとのトランザクションを有する他のアプリケーションのみに影響を及ぼし得る。ポリシは、ポリシが適用されるノードと、ある決定を行うための基準および論理とを定義することができる。例えば、例示的状況またはシナリオが与えられると、異なるポリシが、それらの独自の論理に基づいて、異なる解決策を生じることができる。ポリシリソース構造の例示的実施形態が、以下で説明される。

ＮＡＭＳ１００における例示的ポリシおよび関連動作が、以下で提示される。他のポリシが、所望に応じて、ＮＡＭＳ１００において実装されることができることが理解されるであろう。

例えば、アプリケーション帯域幅調整ポリシは、アプリケーションがＳＬに登録するときに、帯域幅要件をＳＬに提供し得る。ある場合には、ＳＬが常駐するノードが、下層ネットワークに接続するとき、下層ネットワークは、それがサポートする帯域幅をＳＬに提供する。例示的実施形態では、ＮＡＭＳ１００は、帯域幅要件およびサポートされた帯域幅の両方へのアクセスを有する。さらに、ＮＡＭＳ１００は、起動アプリケーションによって要求される集約された帯域幅が下層ネットワークによってサポートされる帯域幅を超えることを決定し得、ポリシに基づいて、ＮＡＭＳ１００は、アクションをとり得る。例えば、ＮＡＭＳ１００は、レートを低減させるように選択アプリケーションに命令し得る、または伝送レートを増加させるように下層ネットワークに命令し得る。そうすることによって、ＮＡＭＳ１００は、アプリケーションがネットワーク帯域幅限界により準最適性能で起動する、状況を防止することができる。

集約ネットワーク負荷指示ポリシは、異なるノード上のＳＬにおけるＮＡＭＳ１００において実装されることができる。ＮＡＭＳは、ネットワークの異なるセグメント、例えば、ＷｉＦｉ、ＺｉｇＢｅｅ（登録商標）、およびセルラーネットワークから、下層ネットワーク負荷状態を取得し得る。ＮＡＭＳは、異なるアプリケーションに対して、ネットワーク負荷状態に関連付けられた異なる閾値を有し得る。一例として、８０％の負荷は、スマート計測アプリケーションのために中程度であるが、ホームセキュリティアプリケーションのために高くあり得る。ＮＡＭＳ１００は、そのような情報をアプリケーションにパスすることができ、したがって、アプリケーションは、その動作について、より高度な決定を行うことができる。例えば、ネットワークのあるセグメントが高負荷状態であること、例えば、過負荷状態であることをＮＡＭＳ１００が決定した後、アプリケーションは、そのトランザクションを遅延させ得る。本明細書で使用される場合、ネットワークに関連付けられた負荷状態またはステータスは、ネットワークの輻輳ステータスとも称され得る。

概して、適応機能は、異なるノードまたはエンティティ間のインターフェースの複雑性を低減させる。例えば、ＮＡＭＳ１００が、そのポリシに基づいて入力を生成するとき、入力は、複数のアプリケーション、ネットワーク、または他のサービスに適用されることができる。したがって、適応機能は、入力をそれぞれのノードにディスパッチすることができる。ある場合には、ＮＡＭＳ１００への複数の入力があるとき、適応機能は、入力をＮＡＭＳ１００に送信する前に、入力を統合し得る。代替として、入力は、構成に基づいて、直接、ＮＡＭＳ１００まで通過し得る。例えば、インフラストラクチャノードにおけるＮＡＭＳは、中間ノードにおけるＮＡＭＳから入力を受信し得る。インフラストラクチャノードにおけるＮＡＭＳは、その構成メッセージで、入力がある期間にわたって統合されることを望むことを示すことができる。

図７および８に示されるように、サービス適応機能１０８およびサービス適応サービス７１０は、ＮＡＭＳ１００とサービス層における他のサービスとの間で相互作用する。他のサービスは、同一のノードの中の同一のサービス層エンティティ内に、または異なるノードにおける異なるサービス層に常駐し得る。ＮＡＭＳ１００は、１つまたは複数のサービスのための入力を送信し得、サービス適応機能１０８またはサービス適応サービス７１０は、ＮＡＭＳ１００から異なるサービスに入力をディスパッチすることができる。

アプリケーション適応サービス７０６は、サービス適応７１０と類似する役割を成し得る。アプリケーション適応サービス７０６は、アプリケーションおよびサービス層におけるＮＡＭＳと相互作用し得る。１つのノードにおけるＮＡＭＳは、複数のアプリケーションと相互作用し得る。ＮＡＭＳ１００は、複数のアプリケーションに適用される入力を生成し得、アプリケーション適応サービス７０６は、ＮＡＭＳ１００から異なるアプリケーションに入力をディスパッチすることができる。ある場合には、異なるアプリケーションからＮＡＭＳ１００への複数のレポートがあるとき、アプリケーション適応サービス７０６は、統合レポートをＮＡＭＳ１００に送信する前にレポートを統合し得る。ネットワーク適応サービス７０８は、下層ネットワークおよびサービス層におけるＮＡＭＳ１００と相互作用する。ネットワーク適応サービス７０８は、１つまたは複数の下層ネットワークからＮＡＭＳ１００への入力を統合し、それは、ＮＡＭＳ１００から異なる下層ネットワークに入力をディスパッチすることができる。

図１０および１１も参照すると、上での動作がさらに図示されている。明確にするため、かつ便宜上、図１０は、アプリケーション６１０からネットワーク７０２へ（第１の方向）の動作を描写し、図１１は、ネットワーク７０２からアプリケーション６１０へ（第２の方向）の動作を描写するが、第１および第２の方向への動作が同時に起こり得、互いに並行して動作し得ることが理解されるであろう。示されるように、ＮＡＭＳ１００は、第１および第２の方向の両方に出力を受信ならびに送信する。下層ネットワーク情報は、種々のネットワーク上に常駐する、異なるサービス層によって交換されることができる。示されるように、そのような情報は、サービス層間参照点を経由してネットワーク管理機能とサービス適応機能との間で交換される。さらに、サービス適応機能の動作は、機能が図１０および１１で両方向に動作するので、「入力」ならびに「出力」に分割される。「入力」は、サービス適応からネットワーク管理への転送を指し、「出力」は、サービス適応から他のＳＬへの転送を指す。

以下の表１は、上で説明されるアーキテクチャおよびＮＡＭＳ１００機能に基づいて、異なる参照点を経由して交換され得る情報要素を列挙する。メッセージ名は、便宜上提示されるので、メッセージは、所望に応じて、任意の他の名称によって識別され得ることが理解されるであろうことに留意されたい。以下で定義されるメッセージは、いかなる特定のプロトコルのいかなる構文にも特定ではなく、したがって、メッセージは、種々のプロトコルによって実現されることができる。例えば、メッセージは、ＲＥＳＴｆｕｌ方法（例えば、ＨＴＴＰまたはＣｏＡＰ）を使用するＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、ＭＱＴＴを使用するＳｕｂｓｃｒｉｂｅ／Ｐｕｂｌｉｓｈ、Ｄｉａｍｅｔｅｒを使用するＲｅｑｕｅｓｔ／Ａｎｓｗｅｒ等によって実現されることができる。

メッセージは、イベントによってトリガされることができ、および／またはメッセージは、周期的にトリガされることができる。イベントをトリガすることの例は、表１に提示されるが、他のイベントが、所望に応じてメッセージをトリガし得ることが理解されるであろう。

表１で提示されるメッセージは、動作の３つの段階に分類され得る。いくつかのメッセージが、「構成」段階に分類され得る。例示的構成段階中に、ＮＡＭＳは、どのような情報をＮＡＭＳが収集することを望むかについて、ネットワーク、サービス、およびアプリケーションが知らされるように、下層ネットワーク、他のサービス、およびアプリケーションを構成することができる。例示的構成段階が、図１２に示されている。さらに、下層ネットワーク、サービス、およびアプリケーションは、どのような入力をそれらの各々がＮＡＭＳから受信することを望むかをＮＡＭＳに示すことができる。図１２を参照すると、例示的構成メッセージは、明確にするために、Ａ、Ｂ、およびＣにグループ化される。図示される実施形態によると、「Ａ」グループ内のステップは、ＮＡＭＳと下層ネットワークとの間の構成のためであり、「Ｂ」グループ内のステップは、ＮＡＭＳと他のサービスとの間の構成のためであり、「Ｃ」グループ内のステップは、ＮＡＭＳとアプリケーションとの間の構成のためである。反復を低減させるため、かつ明確にするために、ステップＡ７、Ｂ７、およびＣ７は、プロシージャとして示される。

例示的実施形態では、情報報告および収集段階が、構成段階の後に続く。図１３を参照して、図示される実施形態によると、構成後、ＮＡＭＳ１００は、所望に応じて、下層ネットワーク、他のサービス、およびアプリケーションから情報を収集することができる。示されるように、メッセージは、それぞれ、ネットワーク、サービス、およびアプリケーションのためのＡ、Ｂ、およびＣグループにグループ化される。図１３は、レポートを入手するために、ＮＡＭＳ１００から送信されるクエリメッセージを示すが、ネットワーク７０２、サービス、またはアプリケーション６１０は、加えて、もしくは代替として、例えば、構成に基づいて、それらのレポートをＮＡＭＳ１００にプッシュ配信できることが理解されるであろう。

例えば、表１および図１２−１４の概要として、ＮＡＭＳは、装置またはノード上で実装されることができ、本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用されるように、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、別様に規定されない限り、同義的に使用され得る。

したがって、ＮＡＭＳは、プロセッサと、メモリと、通信回路とを含む、装置またはノード上に実装されることができる。装置は、その通信回路を介して通信ネットワークに接続され得、装置はさらに、装置のプロセッサによって実行されると、装置にアクションをとらせる、装置のメモリに記憶されたコンピュータ実行可能命令を含み得る。例えば、装置は、ネットワーク上の第１のノードから通信ネットワークを介して、ネットワークに関連付けられた少なくとも１つのステータス更新を示す第１のメッセージ（例えば、「ＮＷ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージ）を受信し得る。装置は、ネットワークに関連付けられた少なくとも１つのステータス更新を記憶し得、少なくとも１つの更新がアプリケーションまたはサービスに影響を及ぼすかどうかを決定し得る。少なくとも１つの更新がアプリケーションまたはサービスに影響を及ぼす場合、装置は、アプリケーションまたはサービスが少なくとも１つのステータス更新に基づいてアクションをとることができるように、少なくとも１つのステータス更新を示す第２のメッセージ（例えば、「ＳＬ ｔｏ Ａｐｐ Ｉｎｐｕｔ」）を、アプリケーションまたはサービスをホストする第２のノードに送信し得る。表１に示されるように、第２のメッセージはさらに、例えば、限定ではないが、アプリケーションもしくはサービスの伝送レートの変化、アプリケーションもしくはサービスの伝送持続時間の変化、アプリケーションもしくはサービスに関連付けられたデータの量の変化、アプリケーションもしくはサービスに関連付けられた分解能の変化、所定の時間量後に伝送するための命令、ネットワークを切り替えるための命令、またはアプリケーションもしくはサービスが切り替わることができる第２のネットワークのうちの少なくとも１つを示し得る。表１にさらに示されるように、少なくとも１つのステータス更新は、例えば、限定ではないが、ネットワークに関連付けられたデータレート、ネットワークによって提供されるサービスの品質、ネットワークに関連付けられた輻輳ステータス、ネットワークに関連付けられたパケットサイズ、ネットワーク伝送間隔、時間単位あたりの最大データ、ネットワークによってサポートされる１つ以上のデバイス、下層ネットワークによってサポートされる１つ以上のサービス、またはネットワークの地理的対象範囲のうちの少なくとも１つを示し得る。

例示的実施形態では、装置（例えば、ＮＡＭＳ）は、アプリケーションまたはサービスから第１のクエリ（例えば、「Ａｐｐ ｔｏ ＳＬ Ｑｕｅｒｙ」メッセージ）を受信し得、第１のメッセージは、第１のクエリに基づき得る。装置は、アプリケーションまたはサービスから第１のクエリメッセージを受信することに応答して、第２のクエリメッセージ（例えば、「ＮＷ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージ）を第１のノードに送信し得、第２のクエリメッセージは、ネットワークに関連付けられた情報に対する要求を含み得る。代替として、または加えて、装置は、第１のメッセージが第２のクエリメッセージに応答して受信されるように、第２のクエリメッセージを第１のノードに送信し得る。したがって、装置（例えば、ＮＡＭＳ）は、ネットワーク関連情報について、所望に応じて任意の時間に、ネットワークにクエリを行い得る。例えば、ＮＡＭＳは、ネットワークに関連付けられた情報に対する要求を含むクエリを送信し得、クエリは、１つ以上のサービスがサービス層に追加されること、もしくはそこから削除されることに応答して送信され得る。別の例では、クエリは、ネットワークに接続された１つ以上のアプリケーションの変化に基づいて送信され得る。

表１および図１２−１４のさらなる概要として、ＮＡＭＳは、装置上に実装されることができ、装置は、ネットワーク上のアプリケーションから通信ネットワークを介して、アプリケーションに関連付けられた少なくとも１つの更新を示す第１のメッセージ（例えば、「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージ）を受信し得る。装置は、アプリケーションに関連付けられた少なくとも１つの更新を記憶し得る。装置は、第１のノードが少なくとも１つの更新に基づいてアクションをとることができるように、少なくとも１つの更新を示す第２のメッセージ（例えば、「ＳＬ ｔｏ ＮＷ Ｉｎｐｕｔ」メッセージ）を、ネットワーク上の第１のノードに送信し得る。さらに、装置は、例えば、限定ではないが、アプリケーションの帯域幅要件、アプリケーションのサービス品質要件、またはアプリケーションのトランザクション特性のうちの少なくとも１つを示す第２のメッセージ（例えば、「ＳＬ ｔｏ ＮＷ Ｉｎｐｕｔ」メッセージ）をネットワーク上の第１のノードに送信し得る。少なくとも１つの更新は、例えば、限定ではないが、アプリケーションに関連付けられたステータス、アプリケーションに関連付けられた伝送レート、アプリケーションに関連付けられたデータの量、アプリケーションに関連付けられた伝送間隔、アプリケーションによってとられるアクションのうちの少なくとも１つを示し得る。装置は、第１のノードから第１のクエリメッセージ（例えば、「ＮＷ ｔｏ ＳＬ Ｑｕｅｒｙ」メッセージ）を受信し得、第１のメッセージは、第１のクエリメッセージに基づく。例では、装置は、第１のノードから第１のクエリメッセージを受信することに応答して、第２のクエリメッセージ（例えば、「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージ）をアプリケーションに送信する。第２のクエリメッセージは、アプリケーションに関連付けられた情報に対する要求を含み得る。別の例では、装置は、第１のメッセージが第２のクエリメッセージに応答して受信されるように、第２のクエリメッセージ（例えば、「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージ）をアプリケーションに送信する。さらに別の例では、装置は、サービス層を含み、第１のクエリメッセージは、ネットワークに関連付けられたコネクティビティ問題に基づいて送信される。

ここで、図１４および表１を参照すると、ＮＡＭＳ１００が情報を処理し、入力を生成する、第３の段階が描写されている。図１４は、ＮＡＭＳ１００がその入力で応答する前に、クエリメッセージがＮＡＭＳ１００に送信され得ることを示すが、ＮＡＭＳ１００は、クエリメッセージを伴わずに、その入力をプッシュ配信し得ることが理解されるであろう。図示される例によると、１では、ＮＡＭＳ１００が、収集された情報を分析し（例えば、図１３参照）、ポリシに基づき得る結果を生成する。Ａ１では、第１のネットワークのネットワークサービスエンティティ（ＮＳＥ）と称されることができる第１のネットワークノードが、ＮＷ ｔｏ ＳＬ Ｑｕｅｒｙメッセージをネットワーク適応サービス７０８に送信する。Ａ２では、別のネットワークのＮＳＥと称されることもできる別のネットワークノードが、ＮＷ ｔｏ ＳＬ Ｑｕｅｒｙメッセージをネットワーク適応サービス７０８に送信する。Ａ３では、図示される例によると、ネットワーク適応サービス７０８が、クエリメッセージを統合する。Ａ４では、ネットワーク適応サービス７０８が、統合クエリ（ＮＷ ｔｏ ＳＬ Ｑｕｅｒｙメッセージ）をＮＡＭＳ１００に送信する。Ａ５では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＮＷ ｉｎｐｕｔメッセージをネットワーク適応サービス７０８に送信する。Ａ６では、ＮＡＭＳ１００が、入力をディスパッチする。例えば、Ａ７では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＮＷ Ｉｎｐｕｔメッセージを第１のネットワークに送信し、Ａ８では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＮＷ Ｉｎｐｕｔメッセージを他方のネットワークに送信する。

同様に、図１４および表１を続けて参照して、図示される例によると、Ｂ１では、第１のサービスを含む第１のノードが、ＳＬ Ｑｕｅｒｙメッセージをサービス適応サービス７１０に送信する。Ｂ２では、別のサービスを含む別のノードが、ＳＬ Ｑｕｅｒｙメッセージをサービス適応サービス７１０に送信する。Ｂ３では、図示される例によると、サービス適応サービス７１０が、ＳＬクエリメッセージを統合する。Ｂ４では、サービス適応サービス７１０が、統合クエリ（ＳＬ Ｑｕｅｒｙメッセージ）をＮＡＭＳ１００に送信する。Ｂ５では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＳＬ Ｅｘｃｈａｎｇｅメッセージをサービス適応サービス７１０に送信する。Ｂ６では、ＮＡＭＳ１００が、入力をディスパッチする。例えば、Ｂ７では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＳＬ Ｅｘｃｈａｎｇｅメッセージを第１のサービスに送信し、Ｂ８では、ＮＡＭＳ１００が、ＳＬ ｔｏ ＳＬ Ｅｘｃｈａｎｇｅメッセージを他方のサービスに送信する。

表１および図１４の図示される例を依然として参照すると、Ｃ１では、第１のアプリケーションが、Ａｐｐ ｔｏ ＳＬ Ｑｕｅｒｙメッセージをアプリケーション適応サービス７０６に送信する。Ｃ２では、別のアプリケーションが、Ａｐｐ ｔｏ ＳＬ Ｑｕｅｒｙメッセージをアプリケーション適応サービス７０６に送信する。Ｃ３では、図示される例によると、アプリケーション適応サービス７０６が、Ａｐｐ ｔｏ ＳＬ Ｑｕｅｒｙメッセージを統合する。Ｃ４では、アプリケーション適応サービス７０６が、統合クエリ（Ａｐｐ ｔｏ ＳＬ Ｑｕｅｒｙメッセージ）をＮＡＭＳ１００に送信する。Ｃ５では、ＮＡＭＳ１００が、ＳＬ ｔｏ Ａｐｐ ｉｎｐｕｔメッセージをアプリケーション適応サービス７０６に送信する。Ｃ６では、ＮＡＭＳ１００が、入力をディスパッチする。例えば、Ｃ７では、ＮＡＭＳ１００が、ＳＬ ｔｏ Ａｐｐ Ｉｎｐｕｔメッセージを第１のアプリケーションに送信し、Ｃ８では、ＮＡＭＳ１００が、ＳＬ ｔｏ Ａｐｐ Ｉｎｐｕｔメッセージを他方のアプリケーションに送信する。

ここで、ＮＡＭＳを使用する例示的使用事例を参照すると、ＮＡＭＳ１００は、ネットワーク最適化およびアプリケーション最適化を可能にすることができる。第１の例示的使用事例が、例示的サービス層支援ネットワーク最適化を図示する、図１５で描写されている。

図１５を参照して、図示される例によると、２つのアプリケーション、すなわち、デバイス１上で起動するアプリケーション１およびデバイス２上で起動するアプリケーション２が、ネットワークノード内のサービス層に登録される。示されるように、ネットワークノード上のサービス層によって提供される、サービス層機能とも称されることもできる、他のサービスは、登録サービス１５０２と、場所サービス１５０４と、ネットワークエクスポージャサービス１５０６と、データ管理およびレポジトリ１５０８とを含む。ネットワークノード内のＮＡＭＳ１００は、アプリケーションおよび他のサービスから情報を収集し、例えば、通信を最適化するために、そのポリシに基づいて、デバイス１およびデバイス２を、ピアツーピア（Ｐ２Ｐ）通信モードとも称されることができるデバイスツーデバイス（Ｄ２Ｄ）に切り替えるための推奨を行う。

依然として図１５を参照して、図示される例示的使用事例によると、１では、アプリケーション２が、登録サービス１５０２を使用して、ネットワークノード内のサービス層に登録する。２では、アプリケーション１が、ネットワークノード内のサービス層に登録する。したがって、アプリケーションは、現在のサービス層ですでに定義されているように、場所サービス１５０４ならびにデータ管理およびレポジトリサービス１５０８を含む、図示されるサービス等のサービス層における他の既存のサービスを使用し得る。３では、ＮＡＭＳ１００が、「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージを使用して、アプリケーション１に関連付けられた情報を読み出す。４では、ＮＡＭＳ１００が、「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージを使用して、アプリケーション２に関連付けられた情報を読み出す。読み出される情報は、例えば、アプリケーションのタイプ、トランザクションの持続時間等の種々のアプリケーション関連情報を含み得る。ＮＡＭＳ１００は、簡単にするために図１５に示されていない、「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージを使用して、そのような情報をプル配信し得ることが理解されるであろう。例示的Ａｐｐ Ｓｔａｔｕｓ ＵｐｄａｔｅおよびＡｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙメッセージは、前述の表１で説明される。アプリケーションに関連付けられた情報に基づいて、図示される例によると、ＮＡＭＳ１００は、アプリケーション１とアプリケーション２との間のトランザクションが長い持続時間を有し、大量のデータを含むことを決定する。６および７では、ＮＡＭＳ１００が、登録サービス１５０２からサービス層登録情報を受信する。例えば、示されるように、ＮＡＭＳ１００は、アプリケーション１がデバイス１上にあり、アプリケーション２がデバイス２上にあり、アプリケーション１および２が同一のサービス層に登録されていることを示す登録情報を受信する。８および９では、ＮＡＭＳ１００は、ネットワークエクスポージャサービス１５０６から、デバイス１およびデバイス２が接続されるネットワークが、トラフィック過負荷問題を経験していることを決定する。図示される例によると、１０および１１では、ＮＡＭＳ１００が、サービス層における場所サービス１５０４から情報を取得することによって、デバイス１およびデバイス２の場所、したがって、アプリケーション１およびアプリケーション２の場所を決定し得る。したがって、ＮＡＭＳ１００は、２つ以上のデバイス、例えば、デバイス１およびデバイス２が、互いに近接していることを決定し得る。

図１５を続けて参照して、１２および１３では、図示される例によると、ＮＡＭＳ１００が、データ管理およびレポジトリサービス１５０８からトランザクション記録を読み出すことができる。記録に基づいて、例えば、ＮＡＭＳ１００は、アプリケーション１およびアプリケーション２が互いに通信することを決定し得る。１４では、例えば、上で説明される読み出された情報に基づいて、ＮＡＭＳ１００が、その内部ポリシに基づいて、それ自身の意思決定論理をトリガし得る。したがって、ＮＡＭＳ１００は、デバイス１およびデバイス２がＤ２Ｄ接続モードに切り替わることが可能であることを決定することができる。１５では、図示される例によると、ＮＡＭＳ１００が、それが生成する結果をネットワークエクスポージャサービス１５０６に送信し得る。ネットワーク結果は、Ｄ２Ｄが、前の接続モード、例えば、下層ネットワークを介して互いに接続されているデバイス１およびデバイス２と比較して、デバイス１およびデバイス２のためのより最適化された接続モードであることを示し得る。サービス層は、例えば、そのような情報がエクスポーズされることを許される場合、意思決定に関連する情報を下層ネットワークにパスすることを選定し得る。ネットワークエクスポージャサービス１５０６は、Ｍｃｎ参照点を介して、情報を下層ネットワークにパスし得る。１６では、図示される例によると、下層ネットワークが、サービス層から推奨を受信する。ネットワークは、デバイス１およびデバイス２のサブスクライバ契約、ネットワーク統計等のそれ自身の情報をさらにチェックし得る。推奨に基づいて、および／またはネットワークの独自の情報に基づいて、ネットワークは、デバイス（例えば、デバイス１およびデバイス２）をＤ２Ｄモードに切り替えるかどうかを決定し得る。下層ネットワークは、デバイスのモードを切り替えるためのそれ自身のプロシージャをトリガし得る。

サービス層上のＮＡＭＳ１００から取得されるアプリケーション関連情報を使用するサービス層支援ネットワーク最適化の別の例示的使用事例シナリオでは、所与のネットワークが、アプリケーションを異なるアクセスネットワークにオフロードすることができる。一例として、ＮＡＭＳ１００は、同一の下層ネットワークを経由して起動する多数のアプリケーションがあり、アプリケーションが大量のデータを伝送していることを決定し得る。ＮＡＭＳ１００は、別のサービス（例えば、ネットワークエクスポージャサービス１５０６）から、利用可能な下層ネットワークおよびそれらに関連付けられたネットワーク負荷（例えば、輻輳）情報を決定し得る。ある場合には、ＮＡＭＳ１００は、１つ以上のアプリケーションが、１つ以上のアプリケーションが現在起動しているネットワークと同じネットワークオペレータを有し得る異なる下層ネットワーク上で起動するべきであるという推奨を行う。ＮＡＭＳ１００は、入力（推奨）を１つ以上のアプリケーションおよび／もしくは下層ネットワークに送信し得る。アプリケーションまたはネットワークのいずれかは、アプリケーションが起動するネットワークを移動するアクションを開始し得る。

サービス層を介して受信される他のネットワークからの情報を使用する、サービス層支援ネットワーク最適化のさらなる例示的使用事例シナリオでは、所与のネットワークが、例えば、電力制御目的で、その対象範囲を調節することができる。一例として、２つの中間ノード（例えば、無線ゲートウェイ）が、２つの異なるエリアネットワーク上に常駐すると仮定されたい。各中間ノード内のサービス層から取得される電力または信号強度情報を使用して、ＮＡＭＳ１００は、中間ノードがその伝送電力を低減させることを望み得ることを示すための出力を生成することができる。ＮＡＭＳ１００は、Ｍｃｎを介して、そのような情報をネットワークスタックにパスすることができる。少なくとも部分的に、ＮＡＭＳ１００から受信される情報に基づいて、所与のネットワークが、その電力を調節することを選定し得る。

ここで図１６を参照すると、例示的サービス層支援アプリケーション最適化を図示する例示的使用事例が示されている。図示される例では、１で、第１のネットワーク（ＮＷ１）に接続される第１のデバイス（デバイス１）上の第１のアプリケーション（アプリケーション１）が、第１のサービス層（サービス層１）に登録する。３では、第２のネットワーク（ＮＷ２）に接続される第２のデバイス（デバイス２）上の第２のアプリケーション（アプリケーション２）が、第２のサービス層（サービス層２）に登録する。２および４では、それぞれのデバイス上の第１および第２のサービス層も、それぞれ、インフラストラクチャノード１６０２におけるサービス層に登録する。サービス層の各々は、ＮＡＭＳ１００を含む。図示される例によると、５および６では、アプリケーション１および２が、「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージを使用して、それぞれ、それらの情報をサービス層１およびサービス層２に報告する。したがって、アプリケーションは、それらが登録されているサービス層に情報を報告し得る。報告された情報は、例えば、限定ではないが、アプリケーションのタイプ、アプリケーションが伝送するデータの量等を含み得る。ＳＬ、具体的には、ＮＡＭＳ１００は、簡単にするために図１６に示されていない「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージを使用して、そのような情報をプル配信し得ることが理解されるであろう。７および８では、デバイス１におけるサービス層１およびデバイス２におけるサービス層２はさらに、例えば、「ＳＬ Ｅｘｃｈａｎｇｅ」メッセージを使用して、そのような情報をインフラストラクチャノード１６０２におけるＳＬに報告することができる。したがって、９では、インフラストラクチャノード１６０２におけるサービス層が、アプリケーション１およびアプリケーション２に関連付けられた情報を取得する。

依然として図１６を参照すると、１０では、サービス層１、具体的には、サービス層１（ＳＬ１）におけるＮＡＭＳ１００が、ネットワークエクスポージャサービス１５０６を介して、下層ネットワーク１（ＮＷ１）に関連付けられた統計を取得する。同様に、１１では、サービス層２、具体的には、サービス層２（ＳＬ２）におけるＮＡＭＳ１００が、ネットワークエクスポージャサービス１５０６を介して、下層ネットワーク２（ＮＷ２）に関連付けられた統計を取得する。１２および１３では、デバイス１およびデバイス２上のサービス層が、インフラストラクチャノード１６０２におけるサービス層に登録されているので、インフラストラクチャノード１６０２におけるサービス層が、「ＳＬ Ｅｘｃｈａｎｇｅ」メッセージを介して統計を受信する。したがって、１４では、ＮＷ１およびＮＷ２に関連付けられた統計が、インフラストラクチャノード１６０２におけるＳＬによって取得される。１５では、図示される例によると、インフラストラクチャノード１６０２におけるＮＡＭＳ１００が、収集された情報を分析し、ＮＡＭＳ１００のポリシに基づいて決定を行う。一例として、インフラストラクチャノード１６０２におけるＮＡＭＳ１００は、アプリケーション１および２が、より低い帯域幅を配分されるべきであるという指示を提供することができる。別の例として、インフラストラクチャノード１６０２におけるＮＡＭＳ１００は、例えば、所与のネットワークコネクティビティ問題が一時的である場合、アプリケーションが伝送を遅延させることを示し得る。示されるように、そのような指示は、１６および１７において、「ＳＬ Ｅｘｃｈａｎｇｅ」メッセージを介して、デバイス１およびデバイス２におけるＮＡＭＳ１００に送信され得、デバイスにおけるＮＡＭＳは、１８および１９において、「ＳＬ ｔｏ Ａｐｐ Ｉｎｐｕｔ」メッセージを介して、指示をそれぞれのアプリケーションに送信し得る。例示的ＳＬ ＥｘｃｈａｎｇｅメッセージおよびＳＬ ｔｏ Ａｐｐ Ｉｎｐｕｔメッセージは、表１において上で説明される。

サービス層支援アプリケーション最適化の別の例示的使用事例シナリオでは、ＮＡＭＳ１００は、２つ以上のアプリケーション間の管理を促進することができる。例えば、アプリケーション（管理者アプリケーション）が、１つ以上の他のアプリケーションを管理することができる。管理者アプリケーションは、例えば、所定の閾値（条件）が満たされるとき、特定の下層ネットワークに切り替わるように１つ以上のアプリケーションをトリガするために、そのポリシをＮＡＭＳ１００にパスすることができる。ＮＡＭＳ１００は、要求された入力を収集することができ、条件が満たされたとき、ＮＡＭＳ１００は、管理者アプリケーションの代わりに、トリガを１つ以上のアプリケーションに送信し得る。

ここで図１７を参照すると、上で説明されるように、サービス層におけるＮＡＭＳ１００は、独立して稼働することができる、またはそのような機構を補完するように、既存のネットワーク管理機構と一緒に稼働し得る。図１７は、例示的層のプロトコルスタック１７００を示す。ＳＮＭＰは、アプリケーションプロトコル層１７０２で使用される例示的プロトコルである。アプリケーションプロトコル層１７０２の上方で、ネットワークは、概して、ネットワーク管理層１７０４と称されることもできるネットワーク管理機能を有し得る。示されるように、サービス層１７０６は、アプリケーション１７０８の直下で、アプリケーションプロトコル層１７０２およびネットワーク層１７０４の上方に常駐する。サービス層１７０６は、メッセージに含まれる情報および上で説明されるＭｃｎを経由した情報交換等の下層ネットワーク情報を取得するために、ネットワーク管理層１７０４と相互作用し得る。例えば、ＴＣＰ等のいくつかのトランスポートプロトコルも、それらの伝送レートを適応させる能力を有する。そのようなプロトコルは、反応性であるが、本明細書で説明されるＮＡＭＳ１００は、種々の状況を防止し、したがって、既存のプロトコルと比較して、全体的性能を増大させることができる。

サービス層１７０６は、ＳＮＭＰから情報を受信し得、ＳＮＭＰは、サービス層１７０６と相互作用するために、Ｍｃｎ参照点に対して使用されることができる。ＳＮＭＰは、依然として、例えば、ネットワークデバイス管理等のその既存の機能を果たすことができる。

上でのように、ＮＡＭＳ１００は、それ自身の集約情報およびポリシに基づいて、下層ネットワークへの入力を生成することができる。したがって、下層ネットワークは、例えば、ＮＡＭＳ１００および既存のネットワーク管理機能等の異なる入力源に基づいてアクションをとり得る。

例示的実施形態によると、図１８を参照して、ＮＡＭＳ１００および上での適応機能は、ｏｎｅＭ２Ｍ ＲｏＡアーキテクチャに適合する。図示される実施形態によると、ＮＡＭＳ１００は、新しい共通サービス機能（ＣＳＦ）である。示されるように、ネットワーク適応サービス７０８は、ＮＳＳＥ ＣＳＦの一部であることができる。さらに示されるように、アプリケーション適応サービス７０６およびサービス適応７１０は、任意のＣＳＦの外部にある。代替実施形態では、ＮＡＭＳ１００は、ＮＳＳＥの一部であり得る。

ここで、図１９Ａおよび１９Ｂを参照すると、２つの例示的代替リソース構造が、本明細書に説明されるＮＡＭＳ機能をサポートするために示されている。リソース構造は、アプリケーション、下層ネットワーク、および他のサービス層からの入力を含む。ＮＡＭＳ１００は、情報を処理し、出力を生成するために、入力を使用することができる。上での表１に説明される例示的情報交換（ＩＥ）メッセージは、図１９Ａおよび１９Ｂに図示されるリソースに記憶されることができる。例えば、ＮＡＭＳ１００は、ローカルポリシまたは外部ポリシへのリンクを＜ｐｏｌｉｃｙ＞リソースに記憶することができる。ポリシは、＜ｐｏｌｉｃｙ＞リソースを操作することによって、追加、削除、または更新されることができる。以下の表２は、例示的実施形態による、＜ｐｏｌｉｃｙ＞構造が定義されることができる方法の例を示す。

表２および図１９Ａ−Ｂを参照すると、ＳＬにおけるＮＡＭＳ１００は、それがどのような情報をアプリケーション、ネットワーク、および他のサービスに送信することができるかを決定し得る。例では、表１に説明される情報の一部が、＜ｔｏＡｐｐ＞、＜ｔｏＮｗ＞、および＜ｔｏＳＬ＞の下に記憶されることができる。例えば、メッセージ「ＳＬ ｔｏ ＮＷ Ｉｎｐｕｔ」内の情報交換（ＩＥ）は、＜ｔｏＮｗ＞の下に記憶されることができる。

例では、アプリケーション、ネットワーク、および他のサービスからの入力は、それぞれ、＜ｆｒｏｍＡｐｐ＞、＜ｆｒｏｍＮｗ＞、および＜ｆｒｏｍＳＬ＞の下に記憶される。いずれの情報が各リソースの下に記憶され得るかは、ＮＡＭＳ１００の構成に基づき、例えば、表１に説明される「ｃｏｎｆｉｇ」メッセージを使用する、ＮＡＭＳ１００と他のノードとの間のネゴシエーションに基づくことができる。例えば、メッセージ「ＮＷ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」の中で交換される情報は、＜ｆｒｏｍＮｗ＞の下に記憶されることができる。各ネットワークは、各ネットワークに関連付けられた固有のＩＤによって、互いに区別されることができる。

ここで図２０を参照すると、ＨＴＴＰプロトコルおよび図１９Ａに示されるリソース構造を使用する例示的コールフローが示されている。以下でさらに説明されるように、１から３では、図２０は、表１で定義される「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」が、ＨＴＴＰプロトコルを使用して行われることができる方法の例を図示する。ステップ４からステップ８は、例示的「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」動作を示す。

依然として図２０を参照して、図示される実施形態によると、１では、アプリケーションエンティティ（ＡＥ１）が、ＨＴＴＰ ＰＯＳＴ要求を開始することによって、限定ではないが、共通サービスエンティティ（ＣＳＥ）と称されることもできる、サービス層内のＮＡＭＳ１００に「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」メッセージを送信する。図示されるＣＳＥは、ＣＳＥ１と称されることもできる。要求では、ＡＥ１は、そのリソースが作成されるべき宛先ＵＲＩを示す。この例では、それは、ｈｔｔｐ：／／ｃｓｅ１．ｍ２ｍ．ｓｐ１．ｃｏｍ／ｃｓｅ１／ｎａｍｓ／ａｐｐＩｎｆｏ／ｆｒｏｍＡｐｐ／の下に記憶される。ＡＥ１は、リソースタイプが「ａｐｐＩｎｆｏ」リソースであるべきこと、および、リソース名がａｅ１Ｓｔａｔｕｓであることも示す。図示される例は、リソースを構造化する１つの方法を示すが、リソースは、代替として、所望に応じて構造化されることができることが理解されるであろう。図示される例では、異なるＡＥステータスのためのリソースは、＜ａｐｐＩｎｆｏ＞の直下に記憶される。代替例では、ＣＳＥ１は、集合として＜ｆｒｏｍＡｐｐ＞を使用し、／ａｐｐＩｎｆｏ／ｆｒｏｍＡｐｐの下に全てのＡＥステータスリソースを記憶することができる。示されるように、ＡＥ１は、メッセージに要求ＩＤ ０００１を含み、メッセージの中でコンテンツフォーマットおよびコンテンツ長を示す。ペイロードでは、ＡＥ１は、ＡＥステータス更新のためのリソース表現を含み得る。２では、要求を受信することに応じて、ＣＳＥ１が、作成者のアクセス権を検証し、リソースを作成することを可能にされた場合、ＣＳＥ１が、ＡＥ１ステータスのためのリソースを作成する。３では、図示される例によると、リソースを正常に作成した後、ＣＳＥが、リソースのＵＲＩおよび動作のステータスを含むＨＴＴＰ応答メッセージを送信する。

図２０を続けて参照すると、４では、ＣＳＥ１におけるＮＡＭＳ１００が、アプリケーションステータスのクエリを行うことを決定する。これは、先行ステップの直後に起こる必要はなく、図示される動作中のある時間に起こり得る。５では、ＣＳＥが、ＨＴＴＰ ＧＥＴ要求を使用して、「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」メッセージをＡＥ１に送信する。この動作は、ＡＥがＨＴＴＰサーバであることができることを示し、ＡＥが読み出すためにそれ自身のステータスをローカルに記憶することを要求することに留意されたい。６では、ＡＥ１が、そのステータスをＣＳＥ１に返すことを決定する。７では、ＡＥ１が、＜ａｐｐＩｎｆｏ＞のリソース表現の中でそのステータスを返す。８では、ＣＳＥ１が、そのリソース構造内の場所の下に読み出されたＡＥ１ステータスを記憶する。

ここで図２１を参照すると、本明細書に説明されるＮＡＭＳ１００の機能がｏｎｅＭ２Ｍ ＳｏＡアーキテクチャに適用されることができる方法の例が、示されている。例では、ＮＡＭＳ１００は、図２１に示されるように、独立した新しいサービスとして定義されることができる。ボックス１、２、および３として示される適応機能は、既存のサービスエクスポージャコンポーネントの一部であることができる。Ｍｆｆ’参照点を経由したサービス間の相互作用は、Ｍｓｃ参照点によって達成されることができる。上で説明されるメッセージおよび情報交換は、ＳｏＡアーキテクチャにも適用できることが理解されるであろう。

図２２を参照すると、上で説明されるメッセージを達成するためにＭＱＴＴプロトコルを使用する例示的コールフローが示されている。図示されるコールフローは、「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」および「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」をサポートするためにＭＱＴＴが使用されることができる方法の例を図示する。図２２は、外部サーバであることができるか、またはサービス層エンティティに組み込まれることができるＭＱＴＴサーバ２２０２を示す。図示される例では、ＭＱＴＴサーバ２２０２は、明確にするために外部エンティティとして示されている。図示されるＡＥ２２０４およびＣＳＥ２２０６は、ＭＱＴＴクライアントである。１ａ−１ｄを参照すると、サービス層関連動作に先立って、ＡＥ２２０４およびＣＳＥ２２０６は、ＭＱＴＴ ＣＯＮＮＥＣＴメッセージを使用して、ＭＱＴＴサーバ２２０２に接続する。ＭＱＴＴサーバ２２０２は、それに接続されるＡＥおよびＣＳＥの識別子ならびにアドレスを取得する。２ａおよび２ｂでは、図示される例によると、サービス層におけるＮＡＭＳ１００が、ＭＱＴＴ ＳＵＢＳＣＲＩＢＥメッセージをトリガする。メッセージでは、ＮＡＭＳ１００は、それが「Ａｐｐ Ｓｔａｔｕｓ Ｕｐｄａｔｅ」のＭＱＴＴトピックに関心があることを含む。ＮＡＭＳ１００は、それが関心を持っているＡＥの特定の識別子を示すことができる。これは、表１で説明される「Ａｐｐ Ｓｔａｔｕｓ Ｑｕｅｒｙ」と同等であり得る。３ａ−３ｃでは、図示される例によると、ＡＥ２２０４が、ＭＱＴＴ ＰＵＢＬＩＳＨメッセージを使用して、それ自身のステータス更新をパブリッシュする。メッセージは、メッセージペイロードにステータス更新情報を含む。メッセージを受信すると、ＭＱＴＴサーバ２２０２は、そのトピックリストに情報を記憶し得る。アプリケーションステータスに関連付けられた情報が、表１に説明されている。４ａ−４ｂでは、ＮＡＭＳ１００がＡＥ１ステータス更新のトピックをサブスクライブしたので、ＭＱＴＴサーバ２２０２は、ＭＱＴＴ ＰＵＢＬＩＳＨメッセージを使用することによって、通知をＮＡＭＳ１００に送信するであろう。ＭＱＴＴサーバ２２０２は、それがＣＳＥ２２０６におけるＮＡＭＳ１００に送信するＰＵＢＬＩＳＨメッセージのペイロードに、ＡＥ２２０４ステータス更新を入れ得る。

ここで下層ネットワークとインターフェースをとることに関して、Ｍｃｎ参照点を経由したＮＡＭＳメッセージを含む例示的実施形態が、ここで説明される。ＮＳＥのブロック図である図２３を参照すると、ＣＳＥへのそのインターフェースと、下層ネットワークに向かう可能ないくつかの例示的インターフェースとが示されている。Ｍｃｎ参照点は、サービス、例えば、以下の表３に列挙されるサービスにアクセスするために、ｏｎｅＭ２Ｍ定義ＡＰＩをＣＳＥに提供する。サポートされるサービスは、各デバイスによって使用されている下層アクセスネットワークによってサポートされるもの、ＣＳＥ所有者とネットワークオペレータとの間のビジネス合意、およびＮＳＥの能力に依存し得る。

例では、ＮＳＥは、種々の目的でＣＳＥおよびＮＳＥによって使用される、ベースＡＰＩの組を提供する。例えば、ＣＳＥは、ＣＳＥ識別子、アプリケーション識別子、およびアクセスネットワーク識別子の間のマッピングをＮＳＥに提供するために、ベースＡＰＩの組を使用し得る。ある場合には、ＮＳＥは、ベースＡＰＩがＮＳＥ内でこの情報をプロビジョニングするために使用されない場合、ＣＳＥまたはアプリケーション識別子を認識しないであろう。ＮＳＥは、ＮＳＥ内でプロビジョニングされていないアクセスネットワーク識別子を認識し得る。アプリケーション識別子またはＣＳＥ識別子が、アクセスネットワーク識別子へのマッピングを有していない場合、識別子がＮＳＥへの値（もしくは意味）を有し得ないことに留意されたい。ＣＳＥは、いずれのサービスが各デバイス、ＣＳＥ、およびアプリケーションのために利用可能であるかをチェックするために、ベースＡＰＩの組を利用し得る。ＣＳＥは、デバイス、ＣＳＥ、およびアプリケーションのためにサービスを可能にするためにも、ベースＡＰＩの組を使用し得る。

例では、ｏｎｅＡＰＩゲートウェイへのインターフェースが、音声、ＳＭＳ、ＩＰメッセージング、ファイル共有、ビデオストリーミング、顧客認証、場所、課金、および存在等のサービスをエクスポーズするために使用され得る。これらのサービスは、表３に列挙されるサービスをサポートするためにＮＳＥに利用可能である。

別の例示的実施形態では、３ＧＰＰインターフェースが使用される。例えば、ＮＳＥは、Ｍｃｎインターフェース上のコマンドをサウスバンドインターフェースを経由した動作にマップする内部論理を有し得る。以下では、ＮＳＥが３ＧＰＰネットワーク内でサポートされることができる方法の例が説明される。一例では、ＮＳＥは、分散型であり、情報は、情報が生成される場所にかかわらず、３ＧＰＰネットワーク内の異なるエンティティにおいて収集される。情報は、例えば、Ｔｓｐ、Ｒｘ、Ｍｈ等の複数の参照点によって送信される。

表４（以下）は、表３に列挙されるサービスに適応するために要求され得る、３ＧＰＰインターフェースを列挙する。ＴｓｐおよびＲｘ参照点は、３ＧＰＰによって定義されるが、本明細書では、新しいコマンド（またはパラメータ）が、表３に列挙されるＭ２Ｍサービスをサポートするように、これらのインターフェースに追加されることができることが認識されることに留意されたい。

本明細書では、Ｍｈ、Ｍｆ、およびＭｏ参照点は、完全には３ＧＰＰによって定義されていないことが認識される。これらの参照点は、ＭＯＳＡＰ作業項目の下で作成された３ＧＰＰ ＴＲで紹介されている。３ＧＰＰ ＴＲ ２３．８６２「ＥＰＣ Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｓｕｐｐｏｒｔ Ｉｎｔｅｒｗｏｒｋｉｎｇ ｗｉｔｈ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｖｉｄｅｒｓ（ＭＯＳＡＰ）」（その開示は、本明細書でその全体において記載される場合のように参照することによって組み込まれる）は、Ｍｈ、Ｍｆ、およびＭｏ参照点が、それぞれ、Ｓｈ、Ｒｏ、およびＲｆ参照点に基づき得ることを規定する。本明細書では、新しいコマンド（またはパラメータ）が、表３に列挙されるＭ２Ｍサービスをサポートするように、これらのインターフェースに追加され得ることが認識される。

ここで図２４を参照すると、図２４は、ＮＳＥが３ＧＰＰネットワークによってサポートされることができる、集中型モデルを示す。ＮＡＭＳ１００は、３ＧＰＰ間接およびハイブリッドモデルでは、ＳＣＳの一部である。一例では、ＭＴＣ−ＩＷＦは、例えば、ＨＳＳ、ＭＳＣ、ＭＭＥ、およびＳＧＳＮ等の他の３ＧＰＰノードからネットワーク関連制御プレーン情報を収集することができるＮＳＥ機能を有する。別の例では、トラフィックおよびユーザプレーン情報が収集されることができるＧＧＳＮ／Ｐ−ＧＷにおけるＮＳＥもあり得る。したがって、Ｍｃｎは、ＴｓｐインターフェースおよびＧｉ／ＳＧｉインターフェースの両方によって実現され得る。ＳＣＳ内のネットワーク適応サービスは、ネットワーク情報を統合し得る。ＳＣＳから３ＧＰＰネットワークへのメッセージは、ＭＴＣ−ＩＷＦへの制御プレーンおよびＧＧＳＮ／Ｐ−ＧＷへのユーザプレーンによって分割される。図２４は、本明細書に説明されるＮＡＭＳ１００および参照点を経由したメッセージが、３ＧＰＰ ＭＴＣインターワーキングモデルでサポートされることができる方法の例を示す。さらに、ＮＡＭＳ１００機能性を含む、ＵＥ上のサービス層が存在することができる。

ここで図２６を参照すると、ネットワークおよびアプリケーション／サービス管理に関連するパラメータを表示および／または構成するように、デバイス、ゲートウェイ、ならびに／もしくはサーバ等のＭ２Ｍ／ＷｏＴ／ＩｏＴエンティティによってサポートされ得る、例示的ＮＡＭＳグラフィカルユーザインターフェース（ＧＵＩ）画面２６００が示されている。図２６の例では、設定２６０２は、例示的アプリケーションに関連付けられた情報に関連し、設定２６０４は、ＮＡＭＳ１００がアプリケーションに提供することができる通知に対応する。示されるように、例示的通知は、下層ネットワークに関連付けられたイベント（ステータス更新）に対応する。設定２６０４は、ユーザが、種々のネットワークイベントに基づいて、アプリケーションがとるための適切なアクションを選択し得るように、ユーザに表示されることができる。同様に、設定２６０２は、ユーザがアプリケーションの要件を入力し得るように、ユーザに提示されることができる。実践では、他の設定およびパラメータが、所望に応じて、選択されて表示されることができる。本明細書に説明されるネットワークおよびアプリケーション管理サービスは、ＧＵＩを介して、いくつかの方法でユーザによって観察され、制御され得ることが理解されるであろう。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、または適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用される場合、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、同義的に使用され得る。

図２５Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。図５−１６、１８−２２、または２４のうちのいずれかに図示されるクライアント、プロキシ、もしくはサーバデバイスのうちのいずれかは、図２５Ａ−Ｄに図示されるもの等の通信システムのノードを備え得る。

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

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

図２５Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等の種々の方法で実装され得る。

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

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

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

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

さらに、本明細書に説明される方法および機能性は、例えば、上でのネットワークおよびアプリケーション管理サービス等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。

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

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはノード３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に結合され得る、送受信機３４に結合され得る。図２５Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに統合され得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のノード３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、ＮＡＭＳ、具体的には、ＮＡＭＳと通信する下層ネットワーク、アプリケーション、または他のサービスのステータスを反映するために、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御するように構成され得る。プロセッサ３２は、電源４８から電力を受容し得、ノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

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

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

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

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

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

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

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

さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図２５Ａおよび図２５Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含み得る。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、（例えば、図５−１６、１８−２２、および２４で）本明細書ならびに請求項に説明される、伝送および受信するステップを行うために使用され得る。

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

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

以下は、上での説明の中で出現し得る、サービスレベル技術に関する頭字語のリストである。
ＡＥ アプリケーションエンティティ
ＡＳ アプリケーションサーバ
ＡＳＮ アプリケーションサービスノード
ＣＳＥ 共通サービスエンティティ
ＣＳＦ 共通サービス機能
Ｄ２Ｄ デバイスツーデバイス通信
ＩＥ 情報要素
ＩＮ−ＣＳＥ インフラストラクチャＣＳＥ
ＭＩＢ 管理情報ベース
ＭＴＣ−ＩＷＦ マシンタイプ通信インターワーキング機能
ＮＡＭＳ ネットワークおよびアプリケーション管理サービス
ＮＳＥ （下層）ネットワークサービスエンティティ
ＮＳＳＥ ネットワークサービスエクスポージャ、サービス実行、およびトリガ
ＮＷ （下層）ネットワーク
ＯＳＩ オープンシステム相互接続モデル
ＲｏＡ リソース指向アーキテクチャ
ＳＣＳ サービス能力サーバ
ＳＬ サービス層
ＳＮＭＰ シンプルネットワークマネージメントプロトコル
ＳｏＡ サービス指向アーキテクチャ
本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの用語と異ならない構造要素を有する場合、または請求項の文字通りの用語からごくわずかな差異を伴う同等の構造要素を含む場合、請求項の範囲内であることを意図している。

Claims (26)

1. プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介して通信ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
   前記ネットワーク上の第１のノードから前記通信ネットワークを介して、前記ネットワークに関連付けられた少なくとも１つの更新を示す第１のメッセージを受信することと、
   前記ネットワークに関連付けられた前記少なくとも１つのステータス更新を記憶することと、
   前記少なくとも１つのステータス更新がアプリケーションまたはサービスに影響を及ぼすかどうかを決定することと、
   前記少なくとも１つのステータス更新が前記アプリケーションまたは前記サービスに影響を及ぼす場合、前記アプリケーションまたはサービスが前記少なくとも１つのステータス更新に基づいてアクションをとることができるように、前記少なくとも１つのステータス更新を示す第２のメッセージを、前記アプリケーションまたは前記サービスをホストする第２のノードに送信することと
   を前記装置に行わせる、装置。
2. 前記第２のメッセージは、前記アプリケーションまたはサービスの伝送レートの変化、前記アプリケーションまたはサービスの伝送持続時間の変化、前記アプリケーションまたはサービスに関連付けられたデータの量の変化、前記アプリケーションまたはサービスに関連付けられた分解能の変化、所定の時間量後に伝送するための命令、ネットワークを切り替えるための命令、もしくは前記アプリケーションまたはサービスが切り替わることができる第２のネットワークのうちの少なくとも１つをさらに示す、請求項１に記載の装置。
3. 前記少なくとも１つのステータス更新は、前記ネットワークに関連付けられたデータレート、前記ネットワークによって提供されるサービスの品質、前記ネットワークに関連付けられた輻輳ステータス、前記ネットワークに関連付けられたパケットサイズ、ネットワーク伝送間隔、時間単位あたりの最大データ、前記ネットワークによってサポートされる１つ以上のデバイス、前記ネットワークによってサポートされる１つ以上のサービス、もしくは前記ネットワークの地理的対象範囲のうちの少なくとも１つを示す、請求項１に記載の装置。
4. 前記コンピュータ実行可能命令は、
   前記アプリケーションまたはサービスから第１のクエリを受信することを前記装置にさらに行わせ、前記第１のメッセージは、前記第１のクエリに基づく、請求項１〜３のいずれか１項に記載の装置。
5. 前記コンピュータ実行可能命令は、
   前記アプリケーションまたはサービスから前記第１のクエリを受信することに応答して、第２のクエリを前記装置に送信することを前記装置にさらに行わせ、前記第２のクエリは、前記ネットワークに関連付けられた情報に対する要求を含む、請求項４に記載の装置。
6. 前記コンピュータ実行可能命令は、
   前記第１のメッセージが前記第２のクエリに応答して受信されるように、第２のクエリを前記第１のノードに送信することを前記装置にさらに行わせ、前記第２のクエリは、前記ネットワークに関連付けられた情報に対する要求を含む、請求項４に記載の装置。
7. 前記コンピュータ実行可能命令は、
   前記第１のメッセージがクエリに応答して受信されるように、前記クエリを前記第１のノードに送信することを前記装置にさらに行わせ、前記クエリは、前記ネットワークに関連付けられた情報に対する要求を含む、請求項１〜３のいずれか１項に記載の装置。
8. 前記装置は、サービス層を含み、前記クエリは、１つ以上のサービスが前記サービス層に追加されること、またはそこから削除されることに応答して送信される、請求項７に記載の装置。
9. 前記クエリは、前記ネットワークに接続された１つ以上のアプリケーションの変化に基づいて送信される、請求項７に記載の装置。
10. プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介して通信ネットワークに接続されており、前記装置は、前記装置の前記メモリに記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
    前記ネットワーク上のアプリケーションから前記通信ネットワークを介して、前記アプリケーションに関連付けられた少なくとも１つの更新を示す第１のメッセージを受信することと、
    前記アプリケーションに関連付けられた前記少なくとも１つの更新を記憶さすることと
    を前記装置に行わせる、装置。
11. 前記コンピュータ実行可能命令は、
    第２のノードが前記少なくとも１つの更新に基づいてアクションをとることができるように、前記少なくとも１つの更新を示す第２のメッセージを前記ネットワーク上の前記ノードに送信することを前記装置にさらに行わせる、請求項１０に記載の装置。
12. 前記コンピュータ実行可能命令は、
    前記アプリケーションの帯域幅要件、前記アプリケーションのサービス品質要件、または前記アプリケーションのトランザクション特性のうちの少なくとも１つを示す第２のメッセージを前記ネットワーク上のノードに送信することを前記装置にさらに行わせる、請求項１０に記載の装置。
13. 前記少なくとも１つの更新は、前記アプリケーションに関連付けられたステータス、前記アプリケーションに関連付けられた伝送レート、前記アプリケーションに関連付けられたデータの量、前記アプリケーションに関連付けられた伝送間隔、または前記アプリケーションによってとられるアクションのうちの少なくとも１つを示す、請求項１０〜１２のいずれか１項に記載の装置。
14. 前記コンピュータ実行可能命令は、
    前記ノードから第１のクエリメッセージを受信することを前記装置にさらに行わせ、前記第１のメッセージは、前記第１のクエリメッセージに基づく、請求項１０〜１３のいずれかに記載の装置。
15. 前記コンピュータ実行可能命令は、
    前記ノードから前記第１のクエリメッセージを受信することに応答して、第２のクエリメッセージを前記アプリケーションに送信することを前記装置にさらに行わせ、前記第２のクエリメッセージは、前記アプリケーションに関連付けられた情報に対する要求を含む、請求項１４に記載の装置。
16. 前記コンピュータ実行可能命令は、
    前記第１のメッセージが第２のクエリメッセージに応答して受信されるように、前記第２のクエリメッセージを前記アプリケーションに送信することを前記装置にさらに行わせ、前記第２のクエリメッセージは、前記アプリケーションに関連付けられた情報に対する要求を含む、請求項１４に記載の装置。
17. 前記装置は、サービス層を含み、前記第１のクエリメッセージは、前記ネットワークに関連付けられたコネクティビティ問題に基づいて送信される、請求項１４〜１６のいずれか１項に記載の装置。
18. 通信ネットワーク内のノードを管理する方法であって、前記方法は、前記ネットワークを経由して通信するサービス層をホストする装置によって行われ、前記方法は、
    前記ネットワーク上の第１のノードから前記ネットワークを介して、前記ネットワークに関連付けられた少なくとも１つのステータス更新を示す第１のメッセージを受信することと、
    更新前記ネットワークに関連付けられた前記少なくとも１つのステータス更新を記憶することと、
    前記少なくとも１つのステータス更新がアプリケーションまたはサービスに影響を及ぼすかどうかを決定することと、
    前記少なくとも１つのステータス更新が前記アプリケーションまたは前記サービスに影響を及ぼす場合、前記アプリケーションまたはサービスが前記少なくとも１つのステータス更新に基づいてアクションをとることができるように、前記少なくとも１つのステータス更新を示す第２のメッセージを、前記アプリケーションまたは前記サービスをホストする前記ネットワーク上の第２のノードに送信することと
    を含む、方法。
19. 前記第２のメッセージは、前記アプリケーションまたはサービスの伝送レートの変化、前記アプリケーションまたはサービスの伝送持続時間の変化、前記アプリケーションまたはサービスに関連付けられたデータの量の変化、前記アプリケーションまたはサービスに関連付けられた分解能の変化、所定の時間量後に伝送するための命令、ネットワークを切り替えるための命令、もしくは前記アプリケーションまたはサービスが切り替わることができる第２のネットワークのうちの少なくとも１つをさらに示す、請求項１８に記載の方法。
20. 前記少なくとも１つのステータス更新は、前記ネットワークに関連付けられたデータレート、前記ネットワークによって提供されるサービスの品質、前記ネットワークに関連付けられた輻輳ステータス、前記ネットワークに関連付けられたパケットサイズ、ネットワーク伝送間隔、時間単位あたりの最大データ、前記ネットワークによってサポートされる１つ以上のデバイス、前記ネットワークによってサポートされる１つ以上のサービス、もしくは前記ネットワークの地理的対象範囲のうちの少なくとも１つを示す、請求項１８に記載の方法。
21. 前記方法は、
    前記アプリケーションまたはサービスから第１のクエリメッセージを受信することをさらに含み、前記第１のメッセージは、前記第１のクエリメッセージに基づく、請求項１８〜２０のいずれか１項に記載の方法。
22. 前記方法は、
    前記アプリケーションまたはサービスから前記第１のクエリメッセージを受信することに応答して、第２のクエリメッセージを前記第１のノードに送信することをさらに含み、前記第２のクエリメッセージは、前記ネットワークに関連付けられた情報に対する要求を含む、請求項２１に記載の方法。
23. 前記方法は、
    前記第１のメッセージが第２のクエリメッセージに応答して受信されるように、前記第２のクエリメッセージを前記第１のノードに送信することをさらに含み、前記第２のクエリメッセージは、前記ネットワークに関連付けられた情報に対する要求を含む、請求項２１に記載の方法。
24. 前記方法は、
    前記第１のメッセージがクエリに応答して受信されるように、前記クエリを前記第１のノードに送信することをさらに含み、前記クエリは、前記ネットワークに関連付けられた情報に対する要求を含む、
    請求項１８〜２０のいずれか１項に記載の方法。
25. 前記クエリは、１つ以上のサービスが前記サービス層に追加されること、またはそこから削除されることに応答して送信される、請求項２４に記載の方法。
26. 前記クエリは、前記ネットワークに接続された１つ以上のアプリケーションの変化に基づいて送信される、請求項２４に記載の方法。