JP6470770B2 - 過去の履歴データに基づくネットワークノード可用性推定 - Google Patents

Description

図１は、サービス層１０２をサポートする例示的プロトコルスタック１００を図示する略図である。プロトコルスタックの視点から、サービス層１０２は、典型的には、アプリケーションプロトコル層１０４の上部に層化され、付加価値サービスをクライアントアプリケーションに提供する。故に、サービス層１０２は、多くの場合、「ミドルウェア」サービスとして分類される。

Ｍ２Ｍ／ＩｏＴサービス層は、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションを特に標的とする、あるタイプのサービス層の例である。図２は、ネットワーク内のＭ２Ｍ／ＩｏＴサービス層インスタンスの例示的展開シナリオを図示する略図である。この例では、サービス層インスタンス２０２は、サービス層の実現であり、いくつかのサービス層インスタンスが、種々のネットワークノード（ゲートウェイおよびサーバ）上に展開される。サービス層インスタンスは、付加価値サービスをネットワークアプリケーション、デバイスアプリケーション、ならびにネットワークノード自体に提供する。

最近、いくつかの産業標準化団体（例えば、ｏｎｅＭ２Ｍ）が、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開の中へのＭ２Ｍ／ＩｏＴタイプのデバイスおよびアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍ／ＩｏＴサービス層を開発している。Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ中央能力の集合体へのアプリケーションおよびデバイスアクセスを提供することができる。そのような能力のいくつかの例として、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続管理が挙げられる。これらの能力は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。

ｏｎｅＭ２Ｍの目的および目標は、種々のハードウェアおよびソフトウェア内に容易に埋め込まれ、分野内の様々なデバイスを世界中のＭ２Ｍアプリケーションサーバと接続するために頼りにされることができる共通Ｍ２Ｍサービス層の必要性に対処する技術的仕様を開発することである。

図３は、共通サービス機能のセット（ＣＳＦ）（すなわち、サービス能力）をサポートするｏｎｅＭ２Ｍ共通サービス層３０２を示す略図である。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、共通サービスエンティティ（ＣＳＥ）３０４と称され、それは、異なるタイプのネットワークノード、例えば、インフラストラクチャノード（ＩＮ）、中間ノード（ＭＮ）、および特定用途向けノード（ＡＳＮ）上でホストされることができる。ＣＳＥは、ＩＮ−ＣＳＥ、ＭＮ−ＣＳＥ、およびＡＳＮ−ＣＳＥによって呼ばれる。

図４は、リソース指向アーキテクチャ（ＲｏＡ）設計原理に準拠するｏｎｅＭ２Ｍサービス層を示す略図である。ｏｎｅＭ２Ｍ ＲｏＡ ＲＥＳＴｆｕｌアーキテクチャ（図４に示される）内では、ＣＳＦは、「リソース」のセットとして表される。リソースは、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作可能な表現を有する、アーキテクチャ内の一意にアドレス可能な要素である。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用して、アドレス可能にされる。リソースは、子リソースおよび属性を含み得る。子リソースは、親リソースとの包含関係を有するリソースである。親リソース表現は、その子リソースへの参照を含む。子リソースの寿命は、親のリソース寿命によって限定される。各リソースは、リソースの情報を記憶する「属性」のセットをサポートする。

図５は、ＲＥＳＴｆｕｌベースではない、旧来の展開のためのＭ２Ｍサービス構成要素アーキテクチャを示す。このＭ２Ｍサービス構成要素アーキテクチャは、主に、ＣＳＥ５０２がサービス構成要素のセットとして見られるインフラストラクチャドメインに好適である。サービス層内において、それは、種々のＭ２Ｍサービスを含み、複数のサービスが、サービス構成要素の中にグループ化されることができる。既存の参照点に加え、それは、サービス間参照点Ｍｓｃ５０４を導入している。Ｍ２Ｍサービス構成要素間の通信（Ｍｓｃ参照点５０４を通過する）は、サービス指向アーキテクチャ（ＳｏＡ）ベースのソフトウェアシステムを構築するための最も一般的技術であるウェブサービスアプローチを利用する。

多くのＭ２Ｍ／ＩｏＴデバイスは、限定されたバッテリ電力、小メモリ専有面積、および低スループットリンクのある組み合わせを有することが知られている。故に、これらのデバイスの多くは、「スリーピー」であり、時々、エネルギー節約のために、スリープモードに入る。これは、大部分の従来研究においてノードが非可用性と見なされることにつながる主要な問題である。

ワイヤレスセンサネットワーク（ＷＳＮ）は、感知およびコンピューティング能力を伴ういくつかの低電力デバイスから成る典型的Ｍ２Ｍエリアネットワークである。多くのセンサネットワークシステムでは、ネットワークノードのための電力供給源は、通常、バッテリ等の消耗性電源である。センサネットワークの寿命を増やすために、ある電力管理スキームは、各ネットワークノードが、周期的に、ウェイクアップし、無線チャネルをリッスンすることを要求する。例えば、Ｓ−ＭＡＣは、ワイヤレスセンサネットワークのために設計された有名な媒体アクセス制御（ＭＡＣ）プロトコルである。Ｓ−ＭＡＣの場合、各ノードはある時間の間、スリープし、次いで、任意の他のノードがそれにトークすることを欲しているかどうかを把握するためにウェイクアップし、リッスンする。スリープの間、ノードは、その無線をオフにし、後にそれをアウェイクするためにタイマを設定する。リッスンおよびスリープのための持続時間は、異なるアプリケーションシナリオに従って選択されることができ、ノードは、同期のために、全てのその直近隣にブロードキャストすることによって、それらのスケジュールを交換する。アウェイク状態の間、複数の近隣がノードにトークすることを欲する場合、それらは、搬送波感知多重アクセスアクセススキームを使用して、媒体のために競争する必要がある。

電力管理スキームの別のアプローチは、ノードがスリープモードに入ると、低電力スタンバイハードウェア構成要素を使用して、環境を見張ることである。例えば、ノードは、ノードがスリープしているとき、スタンバイ無線送受信機サブシステムを使用して、無線チャネルをリッスンすることができる。スタンバイ無線送受信機が無線信号を受信すると、ノードをウェイクアップする。そうでなければ、ノードは、スリープしたままである。

Ｍ２Ｍ／ＩｏＴ使用例（例えば、スマートオブジェクトをインターネットに接続する）に関する既存のインターネットプロトコルに関する欠点および問題が、識別されている。例えば、現在のインターネットプロトコルの主要な欠点は、それらがスリーピーノードのためのサポートを欠くことである。言い換えると、多くの場合、ネットワークノードは、常時、完全に給電されたままであると仮定されるが、これは、残念ながら、多くのＭ２Ｍ／ＩｏＴタイプデバイス（性質上リソースが制約される、バッテリ給電式である、および大部分の時間の間スリープする）に当てはまらない。故に、最近は、Ｍ２Ｍ／ＩｏＴネットワークをサポートするためのインターネットのアーキテクチャおよびプロトコルを拡張することに多くの焦点および注意が集まっている。例えば、従来のシステムは、ルータが、ＩＰｖ６スリーピーノードを制御し、パケットを外部ネットワークから／へ配信することができるスリープモード制御の機構について説明しており、スリーピーノードサポートを伴う６ＬｏＷＰＡＮ近隣発見（ＮＤ）プロトコルの拡張について説明している。

ＩＥＴＦ制約アプリケーションプロトコル（ＣｏＡＰ）は、スマートホームのために展開されるワイヤレスセンサネットワーク等の制約ノード／ネットワーク専用の最近開発されたアプリケーションプロトコルである。それは、ますます多くの注意を集めており、ＩｏＴシステムのための将来性のあるメッセージングプロトコルである。特に、ある研究は、スリーピーノードをサポートするためのＣｏＡＰプロトコルを拡張するために行われている。

前述のようなＣｏＡＰプロトコル拡張以外に、ＩＥＴＦ制約ＲＥＳＴｆｕｌ環境（ＣｏＲＥ）ワーキンググループ内でスリーピーノードをサポートするために、他の試みも行われている。例えば、そのような考えの１つは、リソースディレクトリ（ＲＤ）機構を採用することであり、スリーピーノードは、リソースのそのリスト（ならびにそのスリープ関連ステータス）を中央（非スリーピー）ＲＤサーバに登録／更新することができる。これは、クライアントが、スリーピーノードに関してＲＤからリソースのリストを発見し、標的リソースがスリーピーノード上に位置するかどうか、スリーピーノードが現在スリープモードにあるかどうか、またはスリーピーノードが再びアウェイク状態となるときを決定することを可能にする。別の例は、スリーピーノードがＭＳリソースツリー内にリソースを作成することを可能にするウェブサーバであるミラーサーバ（ＭＳ）に関連する。特に、エネルギー効率のために、スリープノードは、クライアント専用エンドポイントであり、故に、それ自体がコンテンツをサービス提供することはできない。言い換えると、ＭＳは、スリーピーノードとクライアントとの間のメールボックスとしての役割を果たす。

図６は、ｏｎｅＭ２Ｍ機能アーキテクチャ仕様から＜ｓｃｈｅｄｕｌｅ＞６０２と呼ばれるリソースを示す略図である。＜ｓｃｈｅｄｕｌｅ＞リソース６０２は、その親リソースとの関連でスケジューリング情報を表す。＜ｓｃｈｅｄｕｌｅ＞６０２が＜ｎｏｄｅ＞リソースの子であるとき、サービス層が、ノードがスリープしていることを認識し得るように、＜ｓｃｈｅｄｕｌｅＥｌｅｍｅｎｔ＞リソース６０４内に記憶されるスリープスケジュール情報を表すことができる。

前述を背景情報として、本願は、ノード可用性推定サービスを可能にするための新しい方法およびシステムを開示する。

実施形態は、ノード可用性推定をサポートする、サービス層における新しいサービスを含む。いくつかの新しい付加価値サービスは、このノード可用性情報を活用し、Ｍ２Ｍ／ＩｏＴシステムのための動作知能、サービスの品質、通信オーバーヘッド、ならびにエネルギー効率を改善することができる。

一実施形態では、サービス層におけるノード可用性推定（ＮＡＥ）サービスは、３つの主要な構成要素、すなわち、リアルタイムデータ収集構成要素（ＤＣ）と、ノード可用性を推定するためのデータ処理構成要素（ＤＰ）と、ノード可用性サービスプロビジョニング構成要素（ＳＰ）とを有する。

ＤＣは、サービス層（例えば、他の既存のＣＳＦ）における入力ソースからリアルタイムデータを収集することができる。ＤＣは、データ収集関係およびポリシー確立ならびに関連する新しいメッセージ構造のためのプロシージャと、データ収集および報告ならびに関連する新しいメッセージ構造のためのプロシージャと、データ収集関係およびポリシー更新のためのプロシージャとを使用することができる。

ＤＰは、ＤＣによって収集されたデータに基づいて、ノード可用性を推定するためのデータ処理を実行することができる。ＤＰの機能アーキテクチャは、情報推測、情報融合、入力フォーマット解析、ノード可用性推定器構築、ノード可用性推定、推定器評価およびデータ収集ストラテジー決定、ならびに出力生成およびフィードバック収集を含む、いくつかのモジュールを含むことができる。

ＳＰは、ＤＰからの推定されるノード可用性結果を記憶し、「ノード可用性推定サービス」の観点から、それらをサービスクライアントにエクスポーズすることができる。ＳＰは、サービスプロビジョニングポータルであることができる。

複数のＤＣ、ＤＰ、およびＳＰは、データ収集に関する２つのＤＰ間の協働とサービスプロビジョニングおよび推定結果共有に関する２つのＤＰと２つのＳＰとの間の協働とを含む協働およびデータ共有のために、互いに相互作用することができる。

ノード可用性認識セッション確立、知的蓄積／転送方式リソースプリフェッチング、およびサービス層によってサポートされる先を見越したノードトリガを含む、いくつかの新しい付加価値サービスが、提供されることができる。

実施形態は、ｏｎｅＭ２Ｍ機能アーキテクチャ実施形態、ｏｎｅＭ２Ｍサービス構成要素アーキテクチャ実施形態、ｏｎｅＭ２Ｍサービス層内の入力ソースからのデータ収集に関する実施形態、ＤＰの情報推測モジュールおよび情報融合モジュールで実行されるデータ処理に関する実施形態、ならびに新しいリソースを定義することによるノード可用性推定サービスプロビジョニングのｏｎｅＭ２Ｍ実施形態を含むことができる。

この概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。この概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、また、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサおよびメモリを備えているノードであって、前記ノードは、前記ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記ノードの前記プロセッサによって実行されると、
マシンツーマシン（Ｍ２Ｍ）ネットワークの別のノードに関する過去の履歴データを受信することと、
前記過去の履歴データを使用して、前記別のノードがある時間にアップしているか、またはダウンしているかを推定することと
を前記ノードに行わせる、ノード。
（項目２）
前記受信および使用するステップは、データ処理モジュールで行われる、項目１に記載のノード。
（項目３）
前記過去の履歴データは、データ収集モジュールによって収集され、前記データ処理モジュールに送信される、項目２に記載のノード。
（項目４）
前記推定は、ノード可用性サービスプロビジョニングモジュールに提供される、項目２に記載のノード。
（項目５）
推定器モデルが、前記ノードがある時間においてアップしているか、またはダウンしているかを推定するために生成される、項目１に記載のノード。
（項目６）
前記推定器モデルは、正確度を評価される、項目５に記載のノード。
（項目７）
前記評価は、新しいデータ収集ストラテジーを作成するために使用される、項目６に記載のノード。
（項目８）
前記別のノードは、物理ノードである、項目１に記載のノード。
（項目９）
前記別のノードは、論理ノードである、項目１に記載のノード。
（項目９）
プロセッサおよびメモリを備えている中間ノードであって、前記中間ノードは、前記中間ノードの前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記中間ノードの前記プロセッサによって実行されると、
インフラストラクチャノードと通信することと、
別のノードに関連する過去の履歴データを使用して、前記別のノードがある時間においてアップしているか、またはダウンしているかを推定することと
を前記中間ノードに行わせる、中間ノード。
（項目１０）
前記中間ノードは、前記インフラストラクチャノード内のノード可用性推定サービスから独立したノード可用性推定サービスを有する、項目９に記載の中間ノード。
（項目１１）
前記中間ノードは、前記インフラストラクチャノード内のノード可用性推定サービスの構成要素と相互作用する、ノード可用性推定サービスの構成要素を有する、項目９に記載の中間ノード。
（項目１２）
ノードによる使用のための方法であって、前記ノードは、プロセッサおよびメモリを備え、前記ノードは、前記メモリ内に記憶されているコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
マシンツーマシン（Ｍ２Ｍ）ネットワークの別のノードに関する過去の履歴データを受信することと、
過去の履歴データを使用して、前記別のノードがある時間にアップしているか、またはダウンしているかを推定することと
を含む方法の機能を果たす、方法。
（項目１３）
前記受信および使用するステップは、データ処理モジュールで行われる、項目１２に記載の方法。
（項目１４）
前記過去の履歴データは、データ収集モジュールによって収集され、前記データ処理モジュールに送信される、項目１３に記載の方法。
（項目１５）
前記推定は、ノード可用性サービスプロビジョニングモジュールに提供される、項目１３に記載の方法。
（項目１６）
推定器モデルが、前記別のノードがある時間においてアップしているか、またはダウンしているかを推定するために生成される、項目１２に記載の方法。
（項目１７）
前記推定器モデルは、正確度を評価される、項目１６に記載の方法。
（項目１８）
前記評価は、新しいデータ収集ストラテジーを作成するために使用される、項目１７に記載の方法。
（項目１９）
前記別のノードは、物理ノードである、項目１２に記載の方法。
（項目２０）
前記別のノードは、論理ノードである、項目１２に記載の方法。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。
図１は、サービス層をサポートする例示的プロトコルスタックを図示する略図である。 図２は、ネットワーク内のＭ２Ｍ／ＩｏＴサービス層インスタンスの例示的展開シナリオを図示する略図である。 図３は、共通サービス機能（ＣＳＦ）のセットをサポートするｏｎｅＭ２Ｍ共通サービス層を示す略図である。 図４は、リソース指向アーキテクチャ（ＲｏＡ）設計原理に準拠するｏｎｅＭ２Ｍサービス層を示す略図である。 図５は、ＲＥＳＴｆｕｌベースではない旧来の展開を考慮するために開発されたＭ２Ｍサービス構成要素アーキテクチャを示す。 図６は、ｏｎｅＭ２Ｍ機能アーキテクチャ仕様からの＜ｓｃｈｅｄｕｌｅ＞と呼ばれるリソースを示す略図である。 図７は、異なるノード非可用性例を伴う、Ｍ２Ｍ／ＩｏＴシステムを図示する略図である。 図８は、ノード可用性情報を伴わない、非効率的リソース読み出し動作を用いた使用例を図示する略図である。 図８は、ノード可用性情報を伴わない、非効率的リソース読み出し動作を用いた使用例を図示する略図である。 図９Ａは、ＮＡＥがサービス層の中に適合する方法の一実施形態を示す略図である。 図９Ｂは、ＮＡＥの機能アーキテクチャを図示する略図である。 図１０は、ＮＡＥおよび論理および物理ノードに関連する専門用語を図示する略図である。 図１１は、データ収集関係およびポリシー確立のための例示的プロシージャを図示するフロー図である。 図１２は、ＤＣから送信される要求のための例示的一般的メッセージ構造を図示する略図である。 図１３は、データ収集および報告のための例示的プロシージャを図示するフロー図である。 図１４は、データ報告メッセージのための一般的メッセージ構造を図示する略図である。 図１５は、データ収集関係およびポリシー更新のための例示的プロシージャを図示するフロー図である。 図１６は、ＤＰの例示的一般的アーキテクチャを図示する略図である。 図１７は、構成されたノード可用性推定器機能の単純実施例を図示する略図である。 図１８は、ＳＰにおけるサービスプロビジョニングの方法を図示するフロー図である。 図１９は、ＤＣからクライアントへの例示的応答メッセージを図示する略図である。 図２０は、ノード可用性認識セッション確立のためのプロシージャを図示するフロー図である。 図２１は、知的蓄積／転送方式プリフェッチングのためのプロシージャを図示するフロー図である。 図２１は、知的蓄積／転送方式プリフェッチングのためのプロシージャを図示するフロー図である。 図２２は、先を見越したノードトリガのための例示的プロシージャを図示するフロー図である。 図２２は、先を見越したノードトリガのための例示的プロシージャを図示するフロー図である。 図２３は、複数のＤＣ、ＤＰ、およびＳＰ間の相互作を図示する略図である。 図２４は、データ収集プロセスに関して協働する２つのＤＰを図示するフロー図である。 図２５は、サービスプロビジョニングプロセスに関して協働する２つのＤＰおよび相互間で情報を共有する２つのＳＰを図示するフロー図である。 図２６Ａ−Ｂは、既存のｏｎｅＭ２Ｍ機能アーキテクチャを拡張し、ＮＡＥサービスをサポートするための例示的実施形態を図示する略図である。 図２６Ａ−Ｂは、既存のｏｎｅＭ２Ｍ機能アーキテクチャを拡張し、ＮＡＥサービスをサポートするための例示的実施形態を図示する略図である。 図２７は、ｏｎｅＭ２Ｍサービス構成要素アーキテクチャ内のＮＡＥの実装アーキテクチャを図示する略図である。 図２８は、ｏｎｅＭ２Ｍサービス層におけるＮＡＥの例示的データ収集、処理、およびノード可用性サービスプロビジョニング実施形態を図示する略図である。 図２９は、ｏｎｅＭ２Ｍサービス層における例示的データ処理実施形態を図示する略図である。 図３０Ａおよび３０Ｂは、実施形態において使用され得る例示的リソースを図示する略図である。 図３０Ａおよび３０Ｂは、実施形態において使用され得る例示的リソースを図示する略図である。 図３１は、一実施形態のグラフィカルユーザインターフェースの略図である。 図３２Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムを図示する略図である。 図３２Ｂは、１つ以上の開示される実施形態が実装され得る、例示的Ｍ２Ｍサービス層を図示する略図である。 図３２Ｃは、ＵＥまたは他のデバイス等の例示的デバイスを図示する略図である。 図３２Ｄは、開示される実施形態のノードまたは論理エンティティのいずれかを実装するために使用され得る、例示的コンピュータシステムまたはサーバを図示する略図である。

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

大部分の従来のシステムは、主に、リソース制約デバイスのためのエネルギー効率設計原理によって生じる物理ノードスリープ問題に焦点を当てている。スリーピーノードに限定される代わりに、実施形態は、ノード概念が、物理ノードだけではなく、実際は、物理デバイス上で起動するソフトウェアモジュールであり得る論理ノード、例えば、サービス層インスタンスまたはアプリケーションインスタンス（例えば、それぞれ、ｏｎｅＭ２Ｍドメイン内のＣＳＥまたはＡＥ）も参照することによって拡張され得るという意味において、「ノード可用性」に関する。

所与の（物理／論理）ノードに対して、以下の原因は、その非可用性につながり得る。
・ デバイス７０２が、物理ノード自体が利用不可能であるようなスリープ状態に入る（ＰＨＹ層において）。これは、前のセクションで論じられた旧知の例である。
・ 下層ネットワークが、ノードが隔離され、他のピアと相互作用されることができない（すなわち、ネットワーク層で利用不可能）ように、ルーチン動作を有するか（例えば、リソースを解放するためのセルラーネットワーク内の通常接続切断動作）、またはネットワーク問題（例えば、ネットワークトラフィック輻輳）を有する。
・ デバイス７０４が、上層起動ソフトウェアが無線インターフェースから受信される任意の情報に応答することができないように、そのコンピューティングリソース（例えば、ＣＰＵ、ＲＡＭ等）を使い果たしている。同様に、デバイス上の特定のソフトウェアモジュールがクラッシュしているか（例えば、ソフトウェアエラー）、またはオペレーションシステムによって無効にされていることもある。前述の２つの例に対して（すなわち、サービスおよびアプリケーション層において利用不可能である）、ソフトウェアがサービス層インスタンス（例えば、ＣＳＥ）に関連する場合、このＣＳＥは、利用不可能であろう。比較として、ソフトウェアが、アプリケーションインスタンス（例えば、ＡＥ）に関連する場合、このＡＥのみ、利用不可能となるであろう。

サービス層の視点から、本明細書で検討されるノード概念は、物理デバイスまたは論理ノード（例えば、ｏｎｅＭ２Ｍ文脈では、ＣＳＥまたはＡＥ）のいずれかであり得る。故に、「ノードが利用可能である」とは、ノードが他のピアと相互作用および通信することが可能であることを意味する。「ノード」の拡張概念に起因して、エネルギー効率目的のための物理ノード（例えば、センサ）スリープ等の旧知の理由以外に、いくつかの新しい要因が、ノード非可用性につながり得る。

ノード可用性情報は、Ｍ２Ｍ／ＩｏＴシステム内のサービス層における効率的エンドツーエンド通信のために非常に重要である。例えば、ＣＳＥ（例えば、ＣＳＥ−１）が、ＣＳＥ−２が長時間利用可能でないと分かる場合、ＣＳＥ−２にコンタクトを試み、失敗した接続確立動作で終わる代わりに、ＣＳＥ−２への通信接続要求を開始しないことを知的に選定することができる。特に、ノード可用性知識は、多くの場合、直ちに明らかにならないか、または事前に既知ではない（例えば、物理ノードが固定スリープスケジュールを有していない場合があり、論理ノードが、ランタイム問題、例えば、ソフトウェアオーバーロードまたはエラーに起因して、時々、利用不可能となる場合もある）。故に、そのようなノード可用性情報がサービス層にない場合、基本的問題は、ノード可用性を推定する方法である。既存のサービス層は、ノード可用性を推定するためのそのような能力を欠いており、そのような特有の特徴を提供するためにサービス層を拡張する方法に対処する先行研究は、存在しない。

クロスプロトコルスタックノード可用性。ノード可用性は、プロトコルスタックを横断してサポートされることが可能であるが（但し、次に述べられるような反応的様式において）、低層からノード可用性を推定する観点から、ノード可用性に先を見越して対処する方法は、任意の既存の研究の範囲内ではない。例えば、ＭＡＣ層は、エネルギー節約のためのスリーピーノードサポートを可能にすることができるが、例えば、ＣＳＥインスタンスに対するソフトウェアエラーに起因するサービス層におけるＣＳＥ非可用性イベントを認識または理解することができない。特に、ＭＡＣ層は、多くの場合、タイマを有し、タイマによって示される待機期間後、より高い層からの応答を得ない場合、無線リソース（ＰＨＹおよびＭＡＣ）を解放し得るという意味において、上層における非可用性問題に反応的に対処する。同様に、ネットワーク層における既存の研究は、スリープノードサポートを用いたＩＰｖ６近隣発見に焦点を当てるが、高層におけるＣＳＥ非可用性イベントは、やはりその範囲内ではない。ＭＡＣ層を用いることで、ＩＰ層は、タイマを使用して、タイムアウト後、リソースを解放することによって、上層における非可用性問題に反応的にのみ対処することができる。一方、サービス層は、スリープがサービス層において構成されない場合、スリーピーノードの可用性に対して低層にクエリし得ることは事実である。しかしながら、デバイスが、事前に定義された／明確なスリープスケジュールを伴わないイベント駆動様式で動作される場合（Ｍ２Ｍ／ＩｏＴシナリオの大部分における場合である）、低層は、現在の時間に関するノード可用性（すなわち、現在起こっているもの）のみを提供し得、推定される可用性パターンまたはスケジュールを提供することは不可能である。概して、サービス層（それらの接続イニシエータにより近傍である）がノード可用性を推定する能力を有することが望ましく、サービス層は、ノード可用性を推定する能力を用いて、可能なノード非可用性に起因する低成功確率を有するそれらの要求のための接続確立プロセスを先を見越して終了するか、または開始さえしないことが可能であろう。このようにして、サービス層は、接続が確立されることができることを反応的に把握するために低層に頼る必要はない。

サービス層ノード可用性は、サービス層自体を水平に検証し、現在、ノード可用性推定をサポートしていない。垂直ネットワークスタックを検証することによって、ノード可用性推定がサービス層において行われる場合、有益であろうが、残念ながら、既存のサービス層は、そのようなサービスをサポートしない。＜ｓｃｈｅｄｕｌｅ＞リソースが、ノードスリープスケジュールを表すためにｏｎｅＭ２Ｍサービス層内に定義されていることは事実であるが、しかしながら、この情報が得られる方法は、完全に調査されていない。これまで、多くの場合、ノードスリープスケジュールは、ノードによって報告され、事前に把握されている（すなわち、すでに使用の準備ができている）と仮定されるが、特に、ＣＳＥがランタイムソフトウェアエラーに起因して利用不可能となる場合、明らかに当てはまらない。それ以上に、前述のようなより困難かつ一般的例は、ノードが、明確または事前に定義されたスケジュールを全く有していないこともあることである。そのような場合、ノード可用性推定は、サービス層において可能にされるべきである。加えて、特有の位置におけるサービス層をノード可用性推定のための良好な候補とする多くのリアルタイムデータ（直接、ノード可用性を反映しないが、ノード可用性を推定するためのデータソースとして非常に有用であり得る）を提供する多くの既存のエンティティがサービス層（下層ネットワークおよび低層と相互作用する）に存在する。

既存のサービス層は、ノード可用性によって影響され得る、付加価値サービスを促進することができない。サービス層における多くの既存の動作は、ノード可用性問題に対処するときに、十分に知的ではない場合がある。このセクションは、図８に示されるような代表的例を簡単にのみ提示する。

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

インフラストラクチャドメイン内のＣＳＥ（すなわち、ＩＮ−ＣＳＥ８０４）上のＡＥ−１８０２は、そのアプリケーション動作要件に従って、エリアネットワーク内の１０の異なるデバイス（例えば、デバイス−１からデバイス−１０）上の１０のＣＳＥ（例えば、ＣＳＥ−１からＣＳＥ−１０）からリソース（例えば、データ−１からデータ−１０）を読み出すために要求される。ＣＳＥ−１からＣＳＥ−９は、そのリソースをＭＮ−ＣＳＥ８０６に報告したばかりであると仮定すると、ＡＥ−１８０２は、直接、ＭＮ−ＣＳＥ８０６から、それらのリソース（すなわち、データ−１からデータ−９）を容易に得ることができる。しかしながら、ＭＮ−ＣＳＥ８０６上に現在記憶されているデータ−１０が、すでに古い場合、ＭＮ−ＣＳＥ８０６は、再び、ＣＳＥ−１０から、データ−１０を読み出す必要があり得る。しかし、デバイス−１０が、長時間、すでにスリープに入っており、そのスリープスケジュールが、事前に定義され、サービス層に報告されていない場合（例えば、ＭＮ−ＣＳＥ内の＜ｓｃｈｅｄｕｌｅ＞リソースに記憶される）、そのようなリソース読み出し動作は、低層機構がこの例を支援することができない場合、成功しないこともある。例えば、プロキシまたはミラーサーバが、スリープノードをサポートするためのＩＥＴＦ ＣｏＲＥワーキンググループによってアプリケーションプロトコル層に実装されているが、ＡＥ−１は、ミラーサーバまたはプロキシ内に記憶されているリソースも古くなってきている場合、依然として、デバイス−１０にコンタクトする必要があり得る。したがって、デバイス−１０に関する動作失敗は、全ての以前の試み（すなわち、ＣＳＥ−１からＣＳＥ−９からのデータ−１からデータ−９の成功した読み出し）を無効にし、ＡＥ−１のための動作全体の失敗につながるであろう。それ以外に、以前の動作によって消費されたネットワークリソースが全て、任意の利益をもたらさずに、無駄にされる。実際、サービス層が、ノード可用性を何らかの方法で推定し得る場合、前述の動作は、本質的に、改良されることができ、動作要件認識リソース読み出し動作（付加価値サービスとして）が、可能にされることができる。概して、既存の研究は、ノード可用性問題に対処する場合、どんな付加価値サービスがサービス層によって可能にされ得るかを具体的に調査していない。

以下の計算のうちのいくつかに対する理論的背景として、標的変数ｙ（時間ｔの関数である）が与えられると、その現在および将来の値は、過去の時間単位における履歴値に基づいて推定されることができる。

公式上、所与の着目ノードｉに対して、ブール変数ｙ_ｉ（ｔ）は、時間単位ｔ（現在の時間単位は、ｔ_ｃであると仮定する）におけるノードｉの可用性を示すために定義される。例えば、ｙ_ｉ（ｔ）＝１は、ノードｉが時間単位ｔにおいて利用可能であることを示す一方、ｙ_ｉ（ｔ）＝０は、ノードｉが利用不可能であることを意味する。ノードｉの可用性を推定するために、推定器を構築する必要がある。実際、ｙ_ｉ（ｔ）の推定器は、時間単位ｔ（ｆ_ｉ（ｔ）によって示される）の関数として公式化されることができ、以下によって与えられる。

ｆ_ｉ（ｔ）は、多項式、線形、または非線形等であり得るｔの関数であり得、いくつかのパラメータ、すなわち、ａ_ｎ、ａ_ｎ−１、・・・ａ_１、ａ_０を含むことが分かる。最初に、それらのパラメータは、どんな具体的な値も有していない。特に、「推定器構築プロセス」は、以前の時間単位におけるｙ_ｉ（ｔ）の履歴データ（例えば、ｙ_ｉ（ｔ_ｃ−１）、ｙ_ｉ（ｔ_ｃ−２），・・・ｙ_ｉ（ｔ_ｃ−ｋ））を使用して、曲線適合、時系列分析等の異なる技術に基づいて、それらのパラメータに対する値を決定することである。具体的なｆ_ｉ（ｔ）が成形されると（すなわち、全てのパラメータａ_ｎ、ａ_ｎ−１、・・・ａ_１、ａ_０が具体的な数値を有すると）、それは、推定器として使用され、ｔ_ｃおよびｔ_ｃ後の将来の時間単位に対するノードｉの可用性を推定することができる。これは、時間単位ｔ’≧ｔ_ｃが与えられると、推定器ｆ_ｉが、一致するｙ（ｔ’）を出力し、ｙ（ｔ’）が時間単位ｔ’において推定されるノード可用性と見なされ得るからである。

単なる単純な例として、ノードｉは、過去の２０時間単位中、４時間単位の間スリープし、次いで、再びスリープに入る前に、別の６時間単位の間、ウェイクしていたという履歴可用性スケジュールを有すると仮定される。それらの情報に基づいて、推定器が、構築され、以下の具体的な表現を有することができる（すなわち、方程式全体は、任意の未決定パラメータを有していない。注記：ＭＯＤは、モジュロ演算を示す）：

故に、任意の現在のまたは将来の時間単位ｔを方程式（２）の中に入力することによって、それは、その時間単位におけるノードｉの推定されるノード可用性である、０または１値を出力するであろう。

ノード可用性推定（ＮＡＥ）サービスは、その構成要素の各々が個々の機能性を有するという意味において、疎に結合された様式で実装されることができる。図９Ａは、ＮＡＥがサービス層の中に適合する方法の一実施形態を示す略図である。図９Ａおよび以下の図の多くは、ｏｎｅＭ２Ｍサービス層を実施例として使用するであろう。本明細書は、ｏｎｅＭ２Ｍ実施例に焦点を当てるが、説明される実施形態は、ｏｎｅＭ２Ｍに限定されず、任意のサービス層に一般化されることができる。

図９Ａの実施例では、ＮＡＥ９０２は、ＣＳＦと見なされ得る。ＮＡＥ９０２は、既存のＣＳＦ（例えば、セッション管理ＣＳＦ、通信管理配信ハンドリングＣＭＤＨ ＣＳＦ等）と相互作用することによって、ノード可用性推定を遂行することができる。ＮＡＥ９０２が展開される方法（例えば、集中方法または分散方法）に応じて、異なる参照点（例えば、ｍａｃ、ｍｃｃ、ｍｃｃ’またはｍｃｎ）が、影響されるであろう。

図９Ｂは、ＮＡＥ９０２の機能アーキテクチャを図示する略図である。図９Ｂの実施例では、ＮＡＥ９０２は、３つの構成要素を有する。

データ収集（ＤＣ）９０４。ノード可用性を導出または推定するために、ＮＡＥ９０２は、ＤＣ９０４を使用して、リアルタイムデータを入力ソース（例えば、ｏｎｅＭ２Ｍサービス層における、例えば、既存のＣＳＦであり得る）から収集することができる。ＤＣ９０４とＤＰ９０６との間の相互作用は、一方で、ＤＣ９０４が、収集されたデータをデータ処理（ＤＰ）９０６構成要素に入力し、収集されたデータは、異なるノードの可用性を推定するために処理され、他方で、ＤＰ９０６はまた、ノード可用性推定結果の正確度または信頼性を評価することによって、ＤＣ９０４にデータ収集ストラテジーについて動的に知らせ得る。言い換えると、ＤＣ９０４は、ＤＰ９０６によって提供されるデータ収集ストラテジーに従うことによって、データを入力ソースから収集することができる。

データ処理（ＤＰ）９０６。ＤＰ９０６は、いくつかの処理ステップ（データ解釈、情報推測、情報融合、ノード可用性推定器の構築等）を実行することができ、ＤＣ９０４から収集されたデータに基づいて、ノード可用性に関する推定される結果をもたらすことができる。加えて、ＤＰ９０６は、推定される結果の正確度を評価することができ、次いで、ＤＣ９０４のための動作ガイドラインであるデータ収集ストラテジーを動的に調節することができる。

サービスプロビジョニング（ＳＰ）９０８。ＤＰ９０６は、クライアントがノード可用性情報をクエリするためにＮＡＥ９０２と相互作用し得るポータルであるＳＰ９０８に、ノード可用性推定結果を出力することができる。特に、ＤＰ９０６は、それらの推定されるノード可用性情報をサービスクライアントに「ノード可用性推定サービス」として提供する。

図９Ｂの実施例では、入力ソースまたはサービスクライアント間に相互作用ループが、存在する。特に、一方で、ＤＣ９０４と相互作用するとき、入力ソース９１０（例えば、ＮＡＥに属さない、ｏｎｅＭ２Ｍサービス層内の既存のＣＳＦ）は、性能、構成、イベントログ、エラー報告、統計等に関連するデータ等の種々のリアルタイムデータをＤＣ９０４に提供する。他方で、ＳＰ９０８によって提供されるノード可用性推定サービスにアクセスするとき、それらのＣＳＦはまた、ＮＡＥ９０２のサービスクライアント９１０でもある。

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

図１０は、ＮＡＥと論理および物理ノードとに関連する用語を図示する略図である。以下に論じられるように、標的ノードは、ｏｎｅＭ２Ｍサービス層内のＣＳＥ等の論理ノードであることができる一方、ＣＳＥは、１つ以上の特定のタイプのＣＳＦのセットを実装するインスタンスである。ＮＡＥは、別のＣＳＦ（例えば、ＣＳＦ−１）と相互作用することができ、これは、２つのＣＳＥ（それぞれ、ＮＡＥおよびＣＳＦ−１を実装する）間の通信を伴い得る。「ノードの推定される可用性」について論じるとき、これは、概して、物理ノードまたは論理ノード（ＡＥまたはＣＳＥのような）を指す。しかしながら、例えば、リアルタイムデータが収集され得る方法および推定される結果がプロビジョニングされる方法に関連するＮＡＥの設計詳細について論じるとき、議論は、提示を容易にするために、ＣＳＦの文脈を有し得る。

ＤＣ９０４は、ＤＰによって作成されるデータ収集ストラテジーに従うことによって、データを入力ソースから収集することができる。典型的には、データ収集ストラテジーにおけるアイテムの１つは、以下の情報を含み得る（限定ではない）。
−ソース、例えば、データを収集するためにＤＣ９０４が意図する入力ソース（例えば、ｏｎｅＭ２Ｍサービス層内のセッション管理ＣＳＦ）。
−着目ノード、例えば、その可用性を推定するためにＮＡＥ９０２によって着目されるノード。
−着目データ、例えば、前述のセッション管理ＣＳＦから収集され得る（ソースとして）、ソースから収集するためにＤＣ９０４が意図する着目ノードのデータのタイプ、例えば、ＣＳＥ−１（すなわち、着目ノード）のセッションログデータ。
−メッセージフォーマット、すなわち、データ交換のために使用されるべきフォーマット。
−望ましいデータ報告頻度、持続時間、優先順位、および初期ポリシー内の望ましい値が満たされることができない場合の最小許容ＱｏＳ要件に関するポリシー。

データ収集ストラテジーにおける各アイテムに対して、ＤＣ９０４は、対応する入力ソースと相互作用することができる。特に、３つのプロシージャが、データ収集プロセスの間、伴われ得る（以下に論じられる）。

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

ＤＣ９０４が、前述のように、データ収集ストラテジーにおけるアイテムに従って、データを入力ソースから収集する必要があるとき、ソースと関係するデータ収集が、開始されることができる。図１１は、データ収集関係およびポリシー確立のための例示的プロシージャを図示するフロー図である。

図１１のステップ１では、ＤＰ９０６は、新しいデータ収集ストラテジーを決定する。データストラテジーは、データベーステーブルのようなものであり、各アイテムは、ソース、着目ノード、着目データ、データ交換フォーマット、およびデータ収集ポリシー等のいくつかの属性によって定義されたデータ収集要求を含むことが想像され得る。実践的データ交換フォーマットは、種々の実装選択肢に依存する。

図１１のステップ２では、ＤＰ９０６は、ＤＣ９０４に、ＤＣ９０４が任意のデータ収集動作を実行するためのトリガまたはガイドラインである、データ収集ストラテジーについて知らせる。言い換えると、ＤＣ９０４は、データ収集に関して、その独自の決定を行わず、単に、ＤＰ９０６からのデータストラテジーに従う（そのような機能性区画設計原理は、疎結合システムの構築に有益である）。

図１１のステップ３では、データ収集ストラテジーを受信後、ＤＣ９０４は、それをアイテム毎にチェックし、行われるべき必要動作を決定する。データ収集ストラテジーにおける各具体的なアイテムをハンドリングするとき、２つの場合が存在し得る：１）ＤＣ９０４は、このアイテムにおいて示される要求を満たすために、新しいデータ収集関係を開始する必要がある場合（このセクションにおいて論じられるように）、２）ＤＣ９０４が、アイテムによって示される要求を満たすために、既存のデータ収集関係を更新することのみ必要とする場合。

図１１のステップ４では、ＤＣ９０４は、新しいデータ収集関係を確立することに対する要求をソースに送信する。図１２は、このステップにおいて使用される要求のための例示的一般的メッセージ構造を示す略図であり、それは、主に、データ収集ストラテジーの各アイテムの属性を運ぶ。特に、受信機ＩＤ１２０２は、メッセージ受信機を示すことができる。ｏｎｅＭ２Ｍサービス層を例として取り上げると、これは、特定のＣＳＦをサポートするＣＳＥインスタンス（すなわち、ソースとして）のＣＳＥ−ＩＤであり得る。タイプドメイン１２０４は、この要求メッセージが、データ収集関係およびポリシー確立に対するＮＡＥ９０２からのものであることを示すことができる。ペイロード部分１２０６は、サブメッセージ（それらの各々は、例１に属するアイテムに対応し、全てのそれらの対応するアイテムは、同一ソースを有する（受信機ＩＤによって示されるように））のリストを運ぶ。サブメッセージ（図１２の下に示される）の各々は、以下の情報を含む。１）ノードＩＤは、どれが着目ノードであるかを示し、２）このノードに関して収集される必要があるデータ（‘Ｄ’ドメインは、続くフィールドが、着目データが収集されるべき数ｎを記述するために使用されることを示す）、３）‘Ｔ’ドメインは、続く１つのフィールドがデータ収集プロセスの持続時間を記述することを示し、４）このデータ収集関係についてのポリシーは、‘Ｐ’ドメイン後のｍ個のフィールドによって記述される。

図１１のステップ５では、所与のデータ収集関係に対して、ポリシー内に示されるようなＱｏＳ要件がソースによって満たされる／充足されることができないことが可能である。故に、各データ収集関係に対して、ＤＣ９０４とソースとの間に数回のネゴシエーションプロセスが、存在し得る。言い換えると、ＤＣ９０４は、最初に、望ましいＱｏＳ要件およびポリシーを初期要求メッセージ内に含むであろうが、ＤＣ９０４は、ＤＣ９０４およびソースの両方がＱｏＳ要件およびポリシーに関する一貫した合意を達成するまで満たされることができない場合、妥協し得る。しかしながら、最小許容ＱｏＳでさえ満たされることができない場合、ＤＣ９０４は、そのようなデータ収集関係の確立を諦めることができる。

図１１のステップ６では、一貫したＱｏＳ要件合意を達成すると、ソースは、関連リアルタイムデータをＤＣ９０４に適切に報告するために、新しい確立されたデータ収集関係をサポートするための新しいトリガを定義することができる。

図１１のステップ７では、新しいトリガがソースによって設定されると、ソースは、確認をＤＣ９０４に返信し、データ収集関係の確立が成功し、将来の参照のために「データ収集関係ＩＤ」に関連付けられるたことを示すことができる。

図１１のステップ８では、初期データ収集ストラテジーは、ＤＰ９０６によって決定され、ＱｏＳ要件は、ソースとのネゴシエーション時にＤＣ９０４によって修正され得るので、ＤＣ９０４は、ＤＰ９０６の認識のために、確認をＤＰ９０６に返信することもできる。

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

図１３は、データ収集および報告のための例示的プロシージャを図示するフロー図である。データ収集関係が確立されると、ＤＣ９０４は、データ報告をソースから受信することができる。

図１３のステップ１では、先のセクションに記載されたように、いくつかのトリガ（例えば、ＤＣによって着目される特定のデータが報告された場合）が、ソースの内側に定義されることができる（図１１のステップ７参照）。故に、ＤＣによって着目される新しいデータが記録されると、それは、データ報告動作をトリガすることができる。

図１３のステップ２では、新しいデータが、ソースからＤＣに送信される。図１４は、このステップにおいて使用されるデータ報告メッセージのための一般的メッセージ構造を図示する略図である。特に、送信機ＩＤ１４０２は、データが生じた場所を示すことができる。ペイロード部分１４０４はまた、サブメッセージ（それらの各々は、進行中のデータ収集関係に対するデータ報告記録に対応する）のリストを運ぶ。各サブメッセージ（図１４の下に示される）に対して、以下の情報を含む：１）データ収集関係ＩＤは、データが関連する既存のデータ関係を示し、２）ノードＩＤは、データがどのノードに関連するかを示し、３）‘Ｄ’ドメイン後のフィールドは、着目データの数ｎである。ｏｎｅＭ２Ｍサービス層における既存のＣＳＦからデータを収集する方法を例証するサブメッセージの具体的実施形態は、以下に論じられる。代替として、図１４に示されるように、種々の着目ノードに関連するデータを１つのメッセージに入れる代わりに、ソースは、各着目ノードに対するデータを集約することができ、各メッセージは、１つのノードに関連するデータのみを含む。

図１３のステップ３では、新しいデータをソースから受信後、ＤＣ９０４は、最初に、データ完全性をチェックし、次いで、有用情報を取り出すことによって、データを解釈することができる。

図１３のステップ４では、ＤＣ９０４は、データ受信動作成功に対する確認をソースに返信する。

図１３のステップ５では、ＤＣ９０４はまた、さらなる処理のために、データをＤＰ９０６に転送する。

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

図１５は、データ収集関係およびポリシー更新のための例示的プロシージャを図示するフロー図である。ＤＣ９０４は、ソースとすでに進行中のデータ収集関係を有し得るが、必要修正が、新しく受信されたデータ収集ストラテジーを充足するために必要とされる。そのような場合、ＤＣ９０４は、更新要求のみを送信する必要がある。このセクションは、データ収集関係およびポリシー更新のための対応するプロシージャを提示する。

図１５のステップ１−３は、図１１のステップ１−３と同一である。

図１５のステップ４では、既存のデータ収集関係に更新を行うことが要求されると（すなわち、図１１のステップ３で論じられるような例２）、ＤＣ９０４は、更新要求をソースに送信するであろう。一方、全情報を送信する代わりに、ＤＣ９０４は、要求される変更に関連付けられたデータ収集関係ＩＤのみを送信する必要がある。ｏｎｅＭ２Ｍサービス層からの例を取り上げると、ＤＣ９０４は、セッション管理ＣＳＦに、それが着目ノード（例えば、ＣＳＥ−１）に対するデータ収集持続時間を延長する必要があることを示し得る。それに加え、データ収集更新は、より多くのデータ要素を収集すること、データ報告頻度、優先順位を修正すること、または現在のデータ収集関係を終了することを要求し得る。加えて、更新要求のメッセージフォーマットは、図１２に示されるものと非常に類似し得（データ収集関係ＩＤを含むためのサブメッセージ内のフィールドを追加する必要のみある）、したがって、簡潔な提示のために、ここでは示されない。

図１５のステップ５では、ソースが更新要求を承認すると、対応するトリガにも修正を行い、そのような変更を反映させる。更新要求に対して、一貫したサービスの品質（ＱｏＳ）要件合意を達成する前に、（図１１と同一）ＤＣ９０４とソースとの間にネゴシエーションプロセスが存在し得ることが可能であることに留意されたい。図１５は、このプロセスを反映しない。

図１５のステップ６では、更新要求に基づいて、トリガの再構成が成功すると、ソースは、確認をＤＣ９０４に返信するであろう。

図１５のステップ７では、ＤＣ９０４はまた、その認識のために、確認をＤＰ９０８に返信するであろう。

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

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

この例示的アーキテクチャは、異なるサブ機能性を有する、いくつかのモジュールを有する。ＤＰ９０６は、入力ソースから収集されたデータに基づいて、ノード可用性を推定することができる。図１６はまた、異なるモジュール間の情報フロー（矢印として示される）を示す。それらは全て、本紙によって提案される新規概念である。加えて、後続セクションは、モジュールの各々の実施形態の設計詳細を紹介し、ノード可用性が推定され得る方法をステップ毎に例証する。特に、各モジュールの詳細を紹介するために、具体的技術（例えば、推定器を構築するための多項式モデル等を使用して、データを事前に処理する方法）が、実施例として使用されるが、任意の技術またはアプローチが、ＤＰ９０６のモジュールの各々を実装するために使用され得、一般的アプローチは存在しないことは、着目に値する。

モジュールＡ１６０２は、情報推測モジュールである。モジュールＡ１６０２は、種々のリアルタイムデータをＤＣ９０４から受信することができる。このデータは、推定器を構築するために使用され得る、正規化された値（例えば、ノード可用性を示すためのブール値「０」または「１」）に変換されることができる。着目ノードｉに関連する所与のデータｊに対して、ｙ_ｉ，ｊ（ｔ）（ブール変数）は、時間単位ｔ≦ｔ_ｃ（ｔ_ｃは、現在の時間として示される）におけるノード可用性として定義され、それは、情報をデータｊから取り出すことによって具体的に推測される。ｙ_ｉ，ｊ（ｔ）に対する値を決定するために、推測プロセスが、データｊ内の情報に基づいて、ｙ_ｉ，ｊ（ｔ）に関して「０」を設定するか、または「１」を設定するかを推論するために必要とされる。ｏｎｅＭ２Ｍサービス層における例を取り上げると、データｊ（セッション管理ＣＳＦから収集される）が、ＡＥ１が、［０、ｔ_１］の間、ＡＥ２と通信していたことを示す場合、［０、ｔ_１］の間の各時間に対して「１」をｙ_ｉ，ｊ（ｔ）に設定することによって、ＡＥ１が［０、ｔ_１］の間利用可能であることが推測され得る。そのような推測プロセスは、ベストエフォート方法で実行されることができ、したがって、実際のステータスが特定のデータのみに基づいて、正しく推測され得ないことが可能である。したがって、対応するデータ融合プロセスが、情報忠実性を改善するために使用されることができ、これは、次のセクションにおいて論じられる。

データｊ内に含まれる情報に基づいて、ノードｉに対する変数ｙ_ｉ，ｊ（ｔ）の「０」または「１」値を推測した後、モジュールＡ １６０２内のさらなる推測ステップは、ノードｉに直接関連する所与のデータが他のノードの可用性を間接的に反映し得るという意味において、データ再使用に関連する。例えば、物理ノードデバイス−１が、［０、ｔ_１］の間のスリープに起因して利用可能ではないと推測される場合、ＣＳＥ−１およびＡＥ−１も、その両方がデバイス−１上で起動中である場合、利用可能ではない場合があると推測されることができる。その結果、デバイス−１に関連するあるデータは、論理ノードＣＳＥ−１およびＡＥ−１の可用性を推定するためにも使用されることができる。

モジュールＢ １６０４は、情報融合モジュールである。モジュールＢ １６０４の焦点は、依然として、ある特定の時間単位ｔ≦ｔ_ｃにおけるノードｉの履歴可用性である。実際、所与の時間単位ｔ≦ｔ_ｃに対して、ノードｉの可用性に関連する多くのデータ（例えば、Ｗ）が、存在し得る。その結果、それは、そのようなデータの各々から、対応するｙ_ｉ，ｊ（ｔ）を有し、そのようなｙ_ｉ，ｊ（ｔ）のセットは、リストＹ_ｉ（ｔ）によって示されることができ、これは、以下によって与えられる。

Ｙ_ｉ（ｔ）に対して、モジュールＢ １６０４は、リストＹ_ｉ（ｔ）を最終的にｙ_ｉ（ｔ）の値として見なされるであろう単一ブール値に変換することによって、データ融合動作（任意の既存の高度なプラグイン技術を活用し得る）を実行するであろう。例えば、Ｙ_ｉ（ｔ）が、時間単位ｔ≦ｔ_ｃにおいてノードｉの可用性に関連する１３個のデータに基づいて得られる方程式（４）に示される内容を有すると仮定する。

データ融合プロセス後、Ｙ_ｉ（ｔ）は、その大部分がノードｉが時間単位ｔにおいて利用可能ではないことを示すので、ｙ_ｉ（ｔ）に割り当てられる、単一「０」に融合されるであろう。

モジュールＣ １６０６は、ノード可用性推定器を構築するために使用されるアルゴリズムのための入力フォーマット解析モジュールである。所与のノードｉに対して、先のセクションに示されるようなプロセスを繰り返すことによって、いくつかのｙ_ｉ（ｔ）が、モジュールＢ内で異なる以前の時間単位（すなわち、ｔ_ｃ−１、ｔ_ｃ−２・・・ｔ_ｃ−ｋ）に対して決定されることができる。ｙ_ｉ（ｔ）のそれらの履歴値は、順序付けられたリストＬ_ｉ（ｔ_ｃ、ｋ）として定義されることができ、それは、以下によって与えられる。

Ｌ_ｉ（ｔ_ｃ、ｋ）は、ここでは、推定器モデル化アルゴリズムのための準備がほぼできた入力である。履歴時間単位のいくつかに対して、ｙ_ｉ（ｔ）の値は、例えば、関連リアルタイムデータがＤＣ９０４から収集されることができないため、決定されることができないことが可能であることに留意されたい。一方、推定器を構築するために、モジュールＤ １６０８内で使用されるアルゴリズムの入力フォーマット要件に応じて、モジュールＣは、Ｌ_ｉ（ｔ、ｋ）を要求されるフォーマットに対して解析する必要がある。例えば、Ｌ_ｉ（ｔ、ｋ）は、ストリング、テーブル、または２−タプルリスト等として、アルゴリズムの中に直接入力され得る。

モジュールＤ １６０８は、ノード可用性推定器構築モジュールである。モジュールＤ １６０８の仕事は、いくつかの履歴可用性情報（すなわち、以前のセクションにおいて論じられるようなＬ_ｉ（ｔ、ｋ））を前提として、モジュールＤ １６０８が、関数ｆ_ｉ（ｔ）のパラメータ（すなわち、ａ_ｎ、ａ_ｎ−１、・・・ａ_１、ａ_０）に対する値を決定するという意味において、ノード可用性推定器（すなわち、方程式（１）に定義されるようなノードｉに対する関数ｆ_ｉ（ｔ））を構築することである。

ここで、以前の例を再使用して、推定器を構築する方法を例証するために、単純な例のみを示す。ノードｉが、過去の２０時間単位中、４時間単位の間、スリープし、次いで、再びスリープに入る前に、別の６時間単位の間、ウェイクしていたという履歴可用性スケジュールを有することが観察されている。言い換えると、方程式（５）において定義されるような順序化されたリストＬ_ｉ（ｔ_ｃ、ｋ）は、以下の内容を有する。

推定器を構築するために、最初に、候補／プロトタイプ関数が、選択される必要があり、主要な考慮点は、プロトタイプ関数は、履歴データのものと概ね似た傾向を有するべきであるということである。例えば、履歴データが線形傾向を反映する場合、プロトタイプ関数も、線形表現を有するべきである。我々の実施例では、ノード履歴可用性スケジュールは、ある周期性を反映し、ｙ_ｉ（ｔ）は、ブール値関数であるので、方程式（７）に示される以下のプロトタイプ関数が選択されることができる（実際、プロトタイプ関数を選定する方法は、ドメイン知識／経験に大きく依存する）。

方程式（７）におけるプロトタイプ関数内のパラメータは、この時点において決定されておらず、ＭＯＤは、方程式（２）に論じられるようなモジュロ演算であることを思い出されたい。次に、履歴データを利用することによって、ある量のアルゴリズム反復が、方程式（７）における全パラメータに対する値、すなわち、ａ_０、ａ_１，・・・ａ_５を決定するために実行されるであろう（この反復プロセスは、多くの場合、既製のソフトウェア、例えば、Ｍａｔｌａｂ（登録商標）等によって起動される）。特に、値選択原理は、反復プロセスの間、それらのパラメータに対する最適値を検索しているとき、特定の関数曲線がどのように履歴データに適合するかを評価することができることである。例えば、特定のパラメータ設定を有する候補関数に対して、候補関数によって出力される履歴時間単位（すなわち、ｔ_ｃ−１、ｔ_ｃ−２・・・ｔ_ｃ−ｋ）の間の計算されるノード可用性（ｙ_ｉ〜（ｔ_ｃ−１）、ｙ_ｉ〜（ｔ_ｃ−２）・・・ｙ_ｉ〜（ｔ_ｃ−ｋ）によって示される）と、履歴ノード可用性の実値、すなわち、方程式（６）に示されるようなｙ_ｉ（ｔ_ｃ−１）、ｙｉ（ｔ_ｃ−２）・・・ｙ_ｉ（ｔ_ｃ−ｋ）との間の偏差を測定する必要がある。最終的に、あるパラメータ設定は、方程式（８）に示される全履歴時間単位に対して最小総和偏差を有するという意味において、望ましいものとなるであろう（簡単に言うと、この関数は、履歴データに対して最良適合結果を有するものである）。

パラメータの値が決定された後、プロトタイプ関数は、推定器（方程式（９）の右部分に示されるように、方程式（７）に現れる全パラメータは、数値を有する）になるであろう。

実際、そのような推定器構築プロセスは、時間がかかり、正確な推定器ｆ_ｉ（ｔ）の観点から望ましい結果を得るために、有意なコンピューティングリソースを要求し得る。したがって、推定器構築プロセスを加速するために、漸増構築アプローチが、常時、提案される。より精密にするために、スタートラインから開始することによってｆ_ｉ（ｔ）のパラメータの値を決定する代わりに、既存の推定器ｆ’_ｉ（ｔ）（存在する場合、より古い履歴データに基づいて構築される）が、基礎となり得、ｆ’_ｉ（ｔ）におけるパラメータの値は、ＤＣ９０４から新しく受信されたデータを組み合わせることによって、較正され、最後に、ｆ’_ｉ（ｔ）を新しい推定器ｆ_ｉ（ｔ）に更新し得る。加えて、推定器構築の間、アルゴリズム反復の各回は、有意な時間を要し得、したがって、モジュール Ｄ１６０８は、必要であるときのみ、新しい推定器構築プロセスを開始するのみであろう。

モジュールＥ １６１０は、ノード可用性推定モジュールである。モジュールＤ １６０８がノードｉに対する推定器ｆ_ｉ（ｔ）をもたらした後、モジュールＥ １６１０は、推定器を使用して、ｔ≧ｔ_ｃに対するノードｉの可用性を推定するであろう（ｔ_ｃは、現在の時間単位であることを思い出されたい）。方程式（１）において定義されるようなｙ＝ｆ_ｉ（ｔ）は、ｔの具体的な関数であり、ｙは、ノード可用性を示すためのブール変数であるので、ｔを入力することによって、ｆ_ｉ（ｔ）の出力は、その時間単位におけるノードｉの推定される可用性であろう。

モジュールＤ １６０８およびＥ １６１０の主要な概念を図示するために、図１７は、所与のノードｉに対する対応するプロセスを説明する単純な例を示す。図に示されるように、過去の時間単位における履歴可用性データ（青色スポットによって示される）のリスト（モジュールＣ １６０６から得られる）に基づいて、推定器が、構築されることができ、これは、図１７に実線曲線として示される。一方、破線赤色曲線は、将来の時間単位を入力することによって、実線部分から拡大解釈され、すなわち、赤色曲線上の緑色スポットは、将来の時間単位に対する推定される可用性である（実際には、推定器は、次の１つまたはいくつかの時間単位に対して可用性を推定することに対してのみ正確であり得る）。

モジュールＦ １６１２は、推定器評価およびデータ収集ストラテジー決定モジュールである。ノード可用性推定の正確度に影響を及ぼし得るいくつかの要因が存在することに留意されたい。第１に、モジュール Ｄ１６０８が、十分な履歴ノード可用性入力を欠いている（例えば、多くのノード可用性データが多くの過去の時間単位に対して欠いている）場合、推定器は、不正確度の観点から、本質的欠陥を伴って構築され得る。第２に、所与のノードｉおよび所与の時間単位ｔに対して、ＤＣ９０４によって収集された異なるデータは、ノード可用性に対して異なる意見を有し得、モジュールＢ １６０４は、それらの異なる意見を融合するように設計されるので、種々の雑音またはバイアス等に起因して、履歴ノード可用性を推測するとき、エラーが存在し得る可能性が非常に高い。最後に、全履歴可用性データが正確であり、十分であると仮定する場合でも、これは、必ずしも、対応する推定器ｆ_ｉ（ｔ）（モジュールＤ １６０８によって構築される）が、依然として、将来の時間単位に対してノード可用性を推定するために正確であることを意味するわけではない。なぜなら、それが、推定器を構築するために使用されるアルゴリズムまたはアプローチの性能に大きく依存するからである。

したがって、推定器ｆ_ｉ（ｔ）を用いることで、推定されるノード可用性結果は、０と１との間の１０進値であり得る信頼性値に関連付けられることができる。一方で、いくつかの推定される結果（例えば、ノードＣＳＥ−１についての可用性）が、非常に低信頼性値を有する場合、ＤＰ９０６内のモジュールＦ １６１２は、ＣＳＥ−１の推定される可用性の信頼性を改善するために、ＤＣ９０４に、ＣＳＥ−１に関連するより多くのデータを収集するように示唆するであろう（そのような要求を次のデータ収集ストラテジーにおいて示すことによって）。他方で、モジュールＦ １６１２は、サービスクライアントがその独自の目的のために推定されるノード可用性をクエリするＳＰ９０８から、フィードバックを収集することもできる。例えば、ＳＰ９０８は、現在多数のクライアントが、低信頼性に起因して、この情報から利益を得ていないので、ＣＳＥ−２の推定される可用性が改良される必要があることを報告し得る。代替として、ＳＰ９０８は、モジュールＦ１６１２に、クライアントが以前の時間間隔においてデバイス−１にアクセスを試みた（ＳＰ９０８によって提供される推定される可用性が、デバイス−１が利用可能であることを示したため）が、動作が最終的に失敗した（すなわち、推定される可用性は、不正確である）ことを報告し得る。概して、モジュールＦ １６１２は、データ収集ストラテジーを動的に調節し、それは、以前のセクションにおいて論じられるようなガイドラインとして、ＤＣ９０４に転送されるであろう。

モジュールＧ １６１４は、出力生成およびフィードバック収集モジュールである。モジュールＧ １６１４は、モジュールＦ １６１２から推定される結果をクライアントによって理解され得るフォーマットにラップするであろう。次いで、それらの結果は、ＳＰ９０８に転送されるであろう。例えば、時間単位１０と２０との間のＡＥ１（１２３２のＩＤを有する）の推定される可用性は、以下のフォーマットで記述され得る。
｛ノードＩＤ＝１２３２、ステータス：利用可能、間隔＝［ｔ＝１０、ｔ＝２０］、信頼性＝０．５５｝（１０）
加えて、モジュールＧ １６１２は、前述のように、ＳＰ９０８から収集されたフィードバック情報を解析することもできる。

ノード可用性推定結果をＤＰ９０４から受信後、ＳＰ９０８は、そのような情報をノード可用性推定サービスとしてクライアントに提供することができる。図１８は、図１８に示される、ＳＰ９０８におけるサービスプロビジョニングの方法を図示するフロー図である。

図１８のステップ１では、クライアントが、その独自の必要性のために、所与のノードに対する可用性情報を把握する必要があるとき、そのような情報が直ちに明白ではない場合、支援のために、ＮＡＥ９０２にコンタクトするであろう。

図１８のステップ２では、クライアントは、クエリ要求をＮＡＥ９０２に送信する。典型的には、クエリ要求内のメッセージ要素は、以下の情報を含み得る（限定ではない）。
−着目ノードＩＤ：ノードの識別子。
−着目時間間隔：クライアントが着目する期間。
−信頼性要件：例えば、推定される可用性情報に対する最小許容信頼性。

図１８のステップ３では、要求をクライアントから受信後、ＮＡＥ９０２は、そのリポジトリをチェックし、要求が満たされ得るかどうかを確認するであろう。要求は、例えば、１）ＳＰ９０８が、着目ノードに関連する任意の推定される可用性情報を有していない場合、または、２）推定される可用性の信頼性が、低くすぎて、クライアントの要件を充足できない場合、拒否されるであろう。

本実施例における代替使用例は、ステップ２の間、特定のノードの可用性をクエリする代わりに、クライアントが、ノードタイプに関するその必要性を規定のみし得ることである。言い換えると、そのタイプの任意のノードが、現在利用可能である限り、クライアントにサービス提供することができる。次いで、ステップ３では、ＮＡＥ９０２は、この要求をサービス提供するための特定の利用可能なノードを選択することに関与するであろう。

図１８のステップ４では、ＤＣ９０４は、要求が満たされ得る場合、要求される情報をクライアントに返信するか、または説明とともに、拒否通知を送信する。特に、応答メッセージは、図１９に示されるような構造を有し得、そのようなメッセージの実施形態は、方程式（１０）に示される実施例と類似情報を有し得る。

前述のプルベースのサービスプロビジョニングに加え、代替として、クライアントが、ＮＡＥ９０２への所与の着目ノードのための加入を確立し得、ＮＡＥ９０２が、周期的に、ノード可用性に関する任意の更新をクライアントに報告するであろうという意味において、プッシュベースのサービスプロビジョニングもまた、設計され得る。

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

サービス層における提案される新しいＮＡＥ９０２サービスに基づいて、いくつかの付加価値サービスが、ＮＡＥ９０２によって可能にされることができる。図２０は、ノード可用性認識セッション確立のためのプロシージャを図示するフロー図である。ＮＡＥ９０２がサービス層に実装されると、可用性認識セッション管理サービスをサポートすることができ、具体的実施例は、図２０に示され、関連プロシージャを図示する。図２０に示されるように、ＣＳＥ−１ ２００４上で起動するＡＥ−１ ２００２が、遠隔ＣＳＥ−２ ２００８上で起動する別のＡＥ−２ ２００６（これは、実際は、例えば、ソフトウェアクラッシュに起因して、利用可能ではない）と相互作用することを意図するとき、最初に、セッション確立要求をそのローカルＣＳＥ−１ ２００４に送信する。セッション確立プロセスを直ちに初期化する代わりに、ＣＳＥ−１ ２００４は、最初に、ＣＳＥ−２ ２００８（ＮＡＥ９０２サービスを実装する）におけるＡＥ−２ ２００６の推定される可用性をクエリすることによって、そのような動作に関する成功確率を評価する。ＮＡＥ９０２から、ＣＳＥ−１ ２００４は、ＡＥ−２ ２００６が利用可能ではないことが高確率であることを知らされ、それに基づいて、ＣＳＥ−１ ２００４は、続行しないことを決定するであろう。その結果、ＡＥ−１の要求は、直接、そのローカルＣＳＥ−１ ２００４から拒否されるであろう。

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

図２１は、知的蓄積／転送方式プリフェッチングのためのプロシージャを図示するフロー図である。サービス層における提案されるＮＡＥ９０２サービスを用いることで、より知的蓄積／転送方式リソースプリフェッチングが、サポートされることができる。具体的実施例は、図２１に示され、関連プロシージャを図示する。実際、所与の論理ノードＡＥ２１０２に対して、ＮＡＥ９０２は、その可用性を推定し得るだけではなく、ＤＣ９０４から収集されたデータに基づいて、そのアクティビティ挙動／パターンを推定することも可能である。図２１に示されるように、ＣＳＥ−１ ２１０４は、近い将来におけるＡＥ−１ ２１０２（ＣＳＥ−１上で起動する）の推定されるアクティビティをクエリすることによって、ＭＮ−ＣＳＥ２１０６上で起動するＮＡＥ９０２にコンタクトするであろう。ＮＡＥ９０２から返された推定される結果を用いて、ＣＳＥ２１０４は、ＡＥ−１ ２１０２が、おそらく、時間単位ｔ_１のころに、リソース−Ａを遠隔ＣＳＥ−２ ２１０６からフェッチする必要があることが分かる。続いて、ＣＳＥ−１ ２１０４はさらに、ＮＡＥ９０２にクエリし、ＣＳＥ−２ ２１０６が、おそらく、時間ｔ_１のころに、利用可能ではないであろうことが分かる。故に、ＣＳＥ−２ ２１０６の非可用性イベントに反応的に対処する代わりに、ＣＳＥ−１ ２１０４におけるキャッシングＣＳＦは、利用不可能となる前に、先を見越して、リソース−ＡをＣＳＥ−２ ２１０６から読み出すであろう。その結果、後に、ＡＥ−１ ２１０２がリソース読み出し要求をＣＳＥ−１ ２１０４に送信すると、ＣＳＥ−１ ２１０４は、直接、事前にフェッチされたコンテンツを使用して、ＡＥ−１の要求を満たし得る。そのような意味において、リソース−Ａは、ＣＳＥ−２ ２１０６が現在利用不可能である場合でも、ＡＥ−１ ２１０２に提供され、言い換えると、ＮＡＥ９０２の支援を用いて、ＣＳＥ−２ ２１０６の非可用性は、ＡＥ−１ ２１０２から隠される。図８に関して論じられるような前述の使用例の再検証に戻る場合、そのような付加価値サービスは、図８における問題（あるリソース読み出し動作の失敗（ＣＳＥ−１０上）が全ての以前の試み（ＣＳＥ−１からＣＳＥ−９までリソースを読み出す観点から）を無効にする）を解決するために使用されることができる。例えば、全要求されるリソースが、ＡＥ−１の動作要件によって要求されるように、ＡＥ−１による読み出しを成功し得るように、プリフェッチング動作が、ＣＳＥ−１０上におけるリソースを読み出すために実行され得る。代替として、図８における問題の別の解決策は、このセクションにおいて論じられるキャッシングおよびプリフェッチング機構に依拠しなくても、ＮＡＥ９０２を利用することのみによって、ＭＮ−ＣＳＥが、デバイス−１からデバイス−１０に関連する可用性情報をＡＥ−１に返し、ＡＥ−１に、１０のデバイス上の全リソースを読み出すための適切なスケジュールを決定させ得ることである。

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

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

サービス層における提案されるＮＡＥサービス９０２を用いることで、先を見越したノードトリガサービスが、可能にされることができ、具体的実施例は、図２２に示され、関連プロシージャを図示する。図２２に示されるように、最初の５つのステップは、図２１に示されるものに類似する。状況は、ＡＥ−１がそのアプリケーション要件に従って、頻繁に（固定作業スケジュールの観点から周期的にではなく）、特定タスクのために感知コマンドをデバイス−１ ２２０２にプッシュする必要があり、次のプッシュ時間が後の時間ｔであることが、ＣＳＥ−１がＮＡＥ９０２から分かるというものである。しかしながら、ＮＥＡは、デバイス−１ ２２０２が、おそらく、その時間のころに利用可能ではないことを示す。故に、時間ｔにおいてＡＥ−１のプッシュ要求を受信したときにウェイクアップするようにデバイス−１ ２２０２を反応的にトリガする（潜在的遅延につながり得る）代わりに、ＣＳＥ−１ ２２０４は、例えば、ｏｎｅＭ２Ｍサービス層内のネットワークサービスエクスポージャ、サービス実行、およびトリガ（ＮＳＳＥ）ＣＳＦを利用することによって、先を見越して、下層ネットワーク２２０８へのトリガメッセージを適切な時間単位にスケジュールすることを決定し得る（例えば、ｔ’は、ｔよりわずかに早い）。最終的に、下層ネットワークは、デバイス−１ ２２０２をウェイクアップさせるであろう。そのようなトリガを用いることで、デバイス−１ ２２０２は、時間ｔにおいて直ちに利用可能となり得、有意な利点は、デバイス−１ ２２０２が早期にウェイクアップさせられる必要はなく、不必要エネルギー消費につながることがないことである）。その結果、ＡＥ−１ ２２０６がファームウェアのデバイス−１ ２２０２へのプッシュに成功するだけではなく、エネルギー効率目的も達成される。

クライアントは、ＮＡＥ９０２によって提供される推定されるノード可用性に完全に基づいてその動作決定を行う必要はなく、それのみに基づいてその動作決定を行う必要もない。ノード可用性推定は、低信頼性の観点から、十分に正確ではないことがあり、ある場合には、使用準備ができたそのような情報が存在しないこともある。そのような場合に現実的知的決定を行い、ＮＡＥ９０２の可能な推定不正確度を是正するために、以下を含むより多くの情報が、ノード可用性を総体的に評価するために考慮され得る。
１）低層からのクロス層情報報告も、特に、非常に低いデューティサイクル（大部分の時間、スリープ状態にあるという意味において）を有するそれらのデバイスに対して、有用性を有し得る。そのような場合、ＮＡＥ９０２によって提供されるそれらのノードの推定される可用性は、常時、利用不可能であることが可能である（実際、そうであった）。しかしながら、ＭＡＣ／ＰＨＹ層では、それらは、非常に短い時間スロット内で利用可能となり、他のピアとの通信に参加し得る（例えば、スケジュールされたチャネルポーリング技術を使用して）。
２）コンテキスト情報も、いくつかの場合には有用である。例えば、クライアントがわずかワンホップ範囲内にあるノードにコンタクトする必要があり、ＮＡＥ９０２がノードが利用可能ではないと推定した場合（但し、非常に低い信頼性を伴う）、クライアントは、ネットワークトラフィックが軽い場合、依然として、ノードにコンタクトを試み得る（多くのオーバーヘッドを誘発しないこともある）（ネットワークトラフィック状態を悪化させないこともある）。
３）最新のランタイム情報。ＮＡＥ９０２がデータを収集し、次いで、ノード可用性を推定するために常時時間がかかるので、それは、ある程度、時間のずれの影響を及ぼし得る。故に、クライアントが、最新の証拠を有する場合（例えば、標的ノードからのブロードキャストパケットをオーバーヒアしたばかりである場合）、それは、標的ノードがおそらく利用可能であると十分に結論付け得る。

概して、ノード可用性を決定するとき、ＮＡＥ９０２によって提供される推定結果だけでなく、前述のような他の種類の情報も、考慮される必要があることが推奨される。異なるシナリオおよびアプリケーションに応じて、クライアントは、前述の情報を利用するための異なるストラテジーを有するであろう（例えば、異なる優先順位で、異なる重みを有する等）。

図２３は、複数のＤＣ２３０２、２３０４、複数のＤＰ２３０６、２３０８、および複数のＳＰ２３１０、２３１２間の相互作用を図示する略図である。

図２３から、構成要素の全てが以前のセクションにおいて論じられるように一緒に協働しノード可用性推定機能を達成する場合、各構成要素は、複数のエンティティ（任意の３つの構成要素（１つのＤＣ、１つのＤＰ、および１つのＳＰの観点から）がＮＡＥと見なされ得るという意味において）と相互作用することができることが分かる。例えば、ＤＣ２２０２は、複数のＤＰ２３０６および２３０８に対してリアルタイムデータを収集することができる一方、ＤＰ２３０６は、推定結果を複数のＳＰ２３１０および２３１２に提供し得る。それらの相互作用（すなわち、ＤＣおよびＤＰ、ＤＰおよびＳＰ）のための関連プロシージャおよびメッセージ構造は、以前のセクションにおいて提案されるものと同一である。このセクションは、主に、２つのＤＰ２３０６および２３０８と２つのＳＰ２３１０および２３１２間の相互作用を検討するであろう。

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

図２４は、データ収集プロセスに関して協働する２つのＤＰ２３０６および２３０８を図示するフロー図である。図２４に示されるように、ＤＰ−１ ２３０６およびＤＰ−２ ２３０８が両方とも、新しいデータ収集ストラテジーを有するとき、それらのデータ収集ストラテジーをＤＣ２３０２および２３０４に直接送信する代わりに、２つのＤＰ２３０６および２３０８は、最初に、そのデータ収集ストラテジーを交換し、ネゴシエーションプロセスを行う。そのようなネゴシエーションプロセスの潜在的利点は、以下である：１）２つのＤＰ２３０２および２３０９は、同一データ収集タスクを有し得、それは、ネゴシエーションプロセスの間に検出され、マージされ得る。２）異なるＤＰは、異なる量の利用可能なコンピューティングリソースを有し得、したがって、ノード可用性推定タスクは、それらの間で平衡化され得る。３）同様に、異なるＤＣはまた、データ収集に関して異なる作業負荷を有し得るので、ＤＰはまた、そのデータ収集ストラテジーを調節することによって、異なるＤＣに関する作業負荷を平衡化し得る。４）２つのデータ収集ストラテジーが、同一着目ノードに関する異なるタイプのデータを収集することになる場合、それらのデータ収集タスクを一緒に組み合わせ、処理のために、全データを１つのＤＰ２３０６に送信することは、推定結果の正確度を有意に改善し得る。最後に、ステップ５に示されるように、ネゴシエーションプロセスに基づいて、ＤＰ−１ ２３０６およびＤＰ−２ ２３０８は、それぞれ、その調節されたデータ収集ストラテジーをＤＣ−１ ２３０２およびＤＣ−２ ２３０４に送信するであろう（これは、実施例にすぎない）。

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

図２５は、サービスプロビジョニングプロセスに関して協働する２つのＤＰ２３０６および２３０８と、相互間で情報を共有するＳＰ２３１０および２３１２とを図示するフロー図である。図２５に示されるように、ＤＰ−１ ２３０６およびＤＰ−２ ２３０８が、新しい推定結果を有するとき、直接、結果をＳＰ２３１０および２３１２に出力する代わりに、２つのＤＰ２３０６および２３０８は、最初に、ネゴシエーションプロセスを実行し、その間、例えば、異なるＳＰにおける負荷平衡化問題または他の要因を検討することによって、どの推定結果がどのＳＰ２３１０および２３１２に記憶されるかを決定するであろう。故に、ＤＰ−１ ２３０６およびＤＰ−２ ２３０８は、ネゴシエーションプロセスに基づいて、その結果を対応するＳＰ（例えば、図に示されるＳＰ−１ ２３１０およびＳＰ−２ ２３１２）に出力するであろう。異なるＳＰが異なるノード可用性情報を記憶し得るので、情報共有の観点から、異なるＳＰ２３１０と２３１２との間にも協働が存在することにも留意されたい。その結果、クライアントが、特定のノードに関する可用性クエリをＳＰ−２ ２３１２に送信する場合、ＳＰ−２ ２３１２がそのような情報を有していないが、ＳＰ−１ ２３１０は有し得ることが可能である。次いで、ＳＰ−２ ２３１２は、この要求をＳＰ−１ ２３１０に転送し、最終的に、ＳＰ−１ ２３１０は、クライアントによって要求される可用性情報を、この情報を共有することによって、ＳＰ−２ ２３１２に提供し得る。

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

図２６Ａ−Ｂは、既存のｏｎｅＭ２Ｍ機能アーキテクチャを拡張し、ＮＡＥサービスをサポートするための例示的実施形態を図示する略図である。図２６Ａ−Ｂに示されるように、ＮＡＥは、ＣＳＥ内の新しいＣＳＦであることができる。２つの選択肢が、ＮＡＥを展開するために説明される。

一方で、ＮＡＥ２６０２が、集中式に展開される場合（すなわち、ＤＣ２６０４、ＤＰ２６０６、およびＳＰ２６０８の観点における、ＮＡＥ２６０２の全３つの構成要素が、図２６Ａに示されるように、ＣＳＥ２６１０内の単一ノードに実装される場合）、ＣＳＥ２６１０は、ＭＮ−ＣＳＥまたはＩＮ−ＣＳＥのいずれかであり得る。特に、ＮＡＥ２６０２のＤＰ２６０６構成要素において実行されるノード可用性推定のために必要とされるコンピューティングリソースを考慮して、ＮＡＥ２６０２をＩＮ−ＣＳＥ内に入れることは、望ましい選択肢であり得る。ＮＡＥ２６０２内およびＮＡＥ２６０２間通信は、以下のように説明される。

ＮＡＥ（ＣＳＥ−１によって提供される）が、異なるＣＳＥ２６１２（例えば、ＣＳＥ−２）によって提供される別のＣＳＦと通信する必要があるとき、ｍｃｃインターフェースを経由するであろう。例えば、以下の例が挙げられ得る。

例−１：それが図１１に関して論じられるようなデータ収集関係およびポリシー確立のためのプロシージャに関連する場合、関わるオブジェクトは、ＤＣとデータソースとであり、それらの間で交換されるべきメッセージの構造は、図１２に示される。

例−２：それが図１３におけるデータ収集および報告のためのプロシージャに関連する場合、関わるオブジェクトはまた、ＤＣとデータソースとであり、それらの間で交換されるべきメッセージの構造は、図１４に示される。

例−３：それが図１５において論じられるようなデータ収集関係およびポリシー更新のためのプロシージャに関連する場合、関わるオブジェクトは、ＤＣとデータソースとであり、それらの間で交換されるべきメッセージの構造は、図１５のステップ４において論じられるようなｄａｔａｃｏｌｌｅｃｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐＩＤに加えて、図１２に示される。

例−４：それがセクション５．４の図１８において論じられるようなサービスプロビジョニングのためのプロシージャに関連する場合、関わるオブジェクトは、ＳＰとＣＳＥクライアントとであり、それらの間で交換されるべきメッセージの構造は、図１８のステップ２において論じられ（クエリメッセージに関連する）、構造は、図１９に定義される（応答メッセージに関連する）。

ＮＡＥ２６０６が、同一ＣＳＥ２６１０によって提供されるＣＳＦと通信する必要があるとき、またはＮＡＥ２６０２内の３つの構成要素が、互いに相互作用する必要があるとき、通信は、同一サービス層内の異なるサービス機能間の通信を指定する、ｍｆｆインターフェースを経由するであろう。

ＮＡＥ２６０２サービス（ＣＳＥ−１ ２６１０によって提供される）が、同一ＣＳＥ−１ ２６１０上にあるＡＥによってクエリされるとき、ｍａｃインターフェースを経由するであろう。これは、主に、図１８に関して論じられるようなサービスプロビジョニングのためのプロシージャに関連するが、関わるオブジェクトは、ＳＰとＡＥクライアントとである（前述の例−４におけるＣＳＥの代わりに）。それらの間で交換されるべきメッセージの構造は、例−４に示されるものと同一である。

他方で、ＮＡＥはまた、セクション５．６において論じられるように、その３つの不可欠な構成要素（ＤＣ、ＤＰ、およびＳＰ）が、異なるノード内に常駐し得、ＮＡＥが複数のＤＣ、ＤＰ、およびＳＰ間でも相互作用を有し得るという意味において、分散式にも展開され得る（図２６Ｂに示されるように）。例えば、ＤＣは、エンドノードを含む、全ノード上にあり得る一方、ＤＰおよびＳＰは、ＭＮ−ＣＳＥおよびＩｎ−ＣＳＥ上に展開され得る（理由は、前述のものと類似する）。ＮＡＥ内およびＮＡＥ間通信は、以下のように説明される。

ＤＣ２６２０（ＣＳＥ−１ ２６２２に展開される）が、異なるＣＳＥ（例えば、ＣＳＥ−２ ２６２４）によって提供される別のＣＳＦと通信する必要があるとき（ＮＡＥのＤＣにおけるデータ収集のため）、ｍｃｃインターフェースを経由するであろう。前述のような４つの例（例−１から例−４）は、関連オブジェクトおよび交換されるべきメッセージの構造にも適用される。

ＤＣ２６２０（ＣＳＥ−１ ２６２２に展開される）が、同一ＣＳＥによって提供される別のＣＳＦと通信する必要があるとき、ｍｆｆインターフェースを経由するであろう。前述のような４つの例（例−１から例−４）は、依然として、ｍｆｆインターフェースにも適用される。

ＳＰ２６２６（ＣＳＥ−１ ２６２２によって展開される）が、同一ＣＳＥ−１ ２６２２上にあるＡＥ２６２８によってクエリされるとき、ｍａｃインターフェースを経由するであろう。これは、主に、図１８に関して論じられるように、サービスプロビジョニングのためのプロシージャに関連し、関わるオブジェクトは、ＳＰ２６２６とＡＥ２６２８クライアントとである。それらの間で交換されるべきメッセージの構造は、例−４に示されるものと同一である。

ＳＰ２６２６（ＣＳＥ−１ ２６３２によって展開される）が、別のＣＳＥ−２ ２６２４上にあるＡＥ２６３０によってクエリされるとき、ｍｃｃおよびｍａｃインターフェースの両方を経由するであろう。再び、これは、サービスプロビジョニングに関連し、それらの間で交換されるべきメッセージの構造は、例−４に示されるものと同一である。

ＮＡＥの任意の２つの構成要素（すなわち、ＤＣ、ＤＰ、およびＳＰ）間の通信のために、同一ＣＳＥに展開される場合、ｍｆｆインターフェースを経由して、そうでなければ、ｍｃｃインターフェースを経由するであろう。例えば、ＤＣとＤＰとの間の相互作用のために、それらの間のメッセージの構造は、図１２に示されるものと類似し得（ＤＣが収集されたデータをＤＰに入力するときに使用される）、メッセージ要素は、ＤＰがデータ収集ストラテジーをＤＣに送信するときに使用される。

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

図２７は、ｏｎｅＭ２Ｍサービス構成要素アーキテクチャ内のＮＡＥ２７０２の実装アーキテクチャを図示する略図である。図に示されるように、ＮＡＥ２７０２は、‘Ｍｓｃ’参照点２７０４を経由して、他の構成要素と相互作用され得る、‘ノード可用性推定構成要素’２７０２と呼ばれる個々のサービス構成要素を挿入することによって実装され得る。

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

図２８は、ｏｎｅＭ２Ｍサービス層におけるＮＡＥ２７０２の例示的データ収集、処理、およびノード可用性サービスプロビジョニング実施形態を示す略図である。ＤＣは、リアルタイムデータを入力ソースから収集する。ｏｎｅＭ２Ｍドメインの文脈では、それらのエンティティは、既存のＣＳＦであり得る。特に、多くの既存のＣＳＦは、リソースとしてエクスポーズされる（ｅｘｐｏｓｅｄ）ので、図２８は、最新のｏｎｅＭ２Ｍ機能アーキテクチャ仕様に従って、リアルタイムデータを収集する特定のリソースＮＡＥを示す。特に、図２８は、ｏｎｅＭ２Ｍサービス層における既存のＣＳＦからデータを収集する方法を図示することによる、データ報告メッセージ（図１４に定義されるように）の具体的実施形態である。例えば、ＮＡＥが、データをＣＭＤＨ ＣＳＦ（ｏｎｅＭ２Ｍサービス層内の＜ｄｅｌｉｖｅｒｙ＞リソースとして表される）から収集する必要があるとき、ＣＳＥまたはＡＥに関するデータを収集することができる。着目データに関して、「ソース」および「標的」は、そのような＜ｄｅｌｉｖｅｒｙ＞リソースに関わるものを示し（明らかに、そのうちの１つは、着目ノードであるはずである）、「寿命」は、配信の持続時間を示し、「配信メタデータ」は、配信ステータス等を示す。同様に、ＮＡＥは、データを＜ｎｏｄｅ＞リソースから収集し得る。対応する着目ノードは、物理ノードであり得、着目データは、ノードの「メモリ使用」、「記憶」、「電力」、および「スリープスケジュール」（ＮＡＥがデータを収集し得る別のタイプのリソースである、＜ｓｃｈｅｄｕｌｅ＞リソースによって記述される）を含み得る。

図２９は、ｏｎｅＭ２Ｍサービス層における例示的データ処理実施形態を図示する略図である。ＤＰは、ＤＣからの収集されたデータに基づいて、ノード可用性を推定することができる。図２９は、１）ノード可用性情報を３つの異なるデータから推測する方法（ＤＰのモジュールＡにおいて行われる）と、２）３つのデータから取り出された情報を融合する方法（ＤＰのモジュールＢにおいて行われる）とに関する実施形態を示す。図２９に示されるように、ＤＣは、３つのデータを異なるソースから受信している。例えば、データ−１は、ＡＥ−１（すなわち、着目ノード）についてであり、サービス統計収集記録から収集される。データ−２は、ＣＳＥ−１（すなわち、着目ノード）についてであり、セッション管理機能から収集される。

着目ノードｉ（本実施例では、ＡＥ−１またはＣＳＥ−１であり得る）およびその関連データｊの各々（すなわち、ＡＥ−１に関するデータ−１、ＣＳＥ−１に関するデータ−２およびデータ−３）に対して、モジュールＡは、推測プロセスを実行し、各要素データは、データｊから取り出された情報にのみ基づいて、時間単位ｔにおけるノード_ｉの可用性を示すためのブール変数である、変数ｙ_ｉ，ｊ（ｔ）に対して「０」または「１」値のいずれかが推測されるであろう。推測結果は、図２９のセグメントＩ、ＩＩ、およびＩＩＩに示される。例えば、データ−１に基づいて、ｔ＝１とｔ＝１０との間の時間単位に対してｙ_{ＡＥ−１，Ｄａｔａ−１}（ｔ）＝１であることが推測される。データ−２に基づいて、ｔ＝７とｔ＝２０との間の時間単位に対してｙ_{ＣＳＥ−１，Ｄａｔａ−２}（ｔ）＝１であることが推測される。データ−３に基づいて、時間単位ｔ＝８に対してのみｙ_{ＣＳＥ−１，Ｄａｔａ−３}（ｔ）＝１であることが推測される。特に、ｙ_{ＡＥ−１，Ｄａｔａ−１}（ｔ）＝１から、モジュールＡは、さらに、ｔ＝１とｔ＝１０との間の時間単位に対してｙ_{ＣＳＥ−１，Ｄａｔａ−１}（ｔ）＝１であることを推測するであろう。これは、ノードｉに直接関連する所与の情報がまた、他の関連ノードの可用性を間接的に反映し得るという意味において、前述のデータ再使用プロセスである。例として、ＡＥ−１は、［ｔ＝１、ｔ＝１０］の間、利用可能であり、ＡＥ−１は、実際、ＣＳＥ−１によって保持されるので、したがって、ＣＳＥ−１もまた、［ｔ＝１、ｔ＝１０］の間、利用可能であることが推測されることができる（図２９におけるセグメントＩＶに示される）。

次に、差し当たり、ＣＳＥ−１にのみ焦点を当て、焦点時間単位は、ｔ＝８に対してのみである。時間単位ｔ＝８におけるＣＳＥ−１の可用性に関連する３つの推測結果が存在するので、それらの３つの推測結果は、ＤＰのモジュールＢにおいて融合され（すなわち、図２９におけるセグメントＶ）、融合されたノード可用性結果（すなわち、ｙ_ｉ（ｔ））は、セグメントＶＩに示される。

図３０Ａおよび３０Ｂは、実施形態において使用され得る、例示的リソースを図示する略図である。これらのリソースは、ＳＰにおけるプロビジョニングノード可用性推定サービスに読み出されることができ、図３０Ａは、リソース＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙ＞３００２を示し、図３０Ｂは、リソース＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙＥｌｅｍｅｎｔ＞３００４を示す。典型的には、＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙ＞３００２は、リソース＜ＣＳＥＢａｓｅ＞下にあり得る。一方、＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙ＞３００２自体は、いくつかの子＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙＥｌｅｍｅｎｔ＞３００４リソースを含み得る。特に、各＜ｅｓｔｉｍａｔｅｄＡｖａｉｌａｂｉｌｉｔｙＥｌｅｍｅｎｔ＞３００４リソースは、１つの推定されるノード可用性結果を表すためのものであり、このリソースの属性は、方程式（１０）にリスト化されるようなデータ要素に対応する。代替として、推定されるノード可用性結果も、新しい属性、例えば、信頼性等を追加することによって、既存の＜ｓｃｈｅｄｕｌｅ＞リソース内に記憶され得る。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースは、サービス層におけるノード可用性推定サービスに関係付けられる機能性を制御および／または構成するようにユーザを支援するために使用されることができる。図３１は、インターフェース３１０２を図示する略図である。インターフェース３１０２は、以下で説明される図３２Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

論じられるように、ＤＰ内側の一般的アーキテクチャである、モジュールＤは、図１６に示されるように、いくつかの履歴可用性情報（すなわち、以前のセクションにおいて論じられるようなＬ_ｉ（ｔ、ｋ））を前提として、モジュールＤが、関数ｆ_ｉ（ｔ）のそれらのパラメータ（すなわち、ａ_ｎ、ａ_ｎ-１、・・・ａ_１、ａ_０）に関する値を決定するためのものであるという意味において、ノード可用性推定器（すなわち、関数ｆ_ｉ（ｔ））を構築するために使用される。

任意の利用可能な解決策が、推定器を構築するためのプラグインとして使用されることができることは、着目に値する（言い換えると、本開示は、モジュールＤを実装するための任意の具体的アプローチに限定されない）。したがって、任意のプラグイン解決策に対して、ユーザは、推定器の構築を開始する前に、いくつかの構成を行う必要があり得る。したがって、ユーザが構成するために便利な方法、例えば、使用されるべき基この関数ｆ_ｉ（ｔ）および関数ｆ_ｉ（ｔ）のパラメータ（すなわち、ａ_ｎ、ａ_ｎ-１、・・・ａ_１、ａ_０）の初期値を設定する方法を提供するために、グラフィカルユーザインターフェース（ＧＵＩ）の観点からユーザ制御パネルが、提供され得る。図３１は、必要性に基づいて、容易に拡張され得る、ユーザが使用されるべき基本関数ｆ_ｉ（ｔ）ならびにそのパラメータの初期値を選定することを可能にする、例示的ＧＵＩ３１０２を示す。

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

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

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

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

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

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

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

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

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

一実施形態では、ノード可用性推定器９０２、ＤＣ９０４、ＤＰ９０６、および／またはＳＰ９０８等の論理エンティティならびにグラフィカルユーザインターフェース３１０２を生成するための論理エンティティは、図３２Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、ノード可用性推定器９０２、ＤＣ９０４、ＤＰ９０６、および／またはＳＰ９０８等の論理エンティティならびにグラフィカルユーザインターフェース３１０２を生成するための論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

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

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

さらに、ノード可用性推定器９０２、ＤＣ９０４、ＤＰ９０６、および／またはＳＰ９０８等の本願の論理エンティティならびにグラフィカルユーザインターフェース３１０２を生成するための論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用するＭ２Ｍネットワークの一部として実装されることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (14)

1. プロセッサおよびメモリを備えている装置であって、前記装置は、前記装置の前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記装置の前記プロセッサによって実行されると、
   マシンツーマシン（Ｍ２Ｍ）ネットワークのノードに関する過去の履歴データをデータ収集モジュールから受信することと、
   前記過去の履歴データを使用して、前記ノードがある時間にアップしているか、またはダウンしているかを推定することと、
   前記装置のノード可用性サービスプロビジョニングモジュールに前記推定を提供することであって、前記ノード可用性サービスプロビジョニングモジュールは、前記推定をノード可用性推定サービスとしてクライアントに提供するように構成されている、ことと
   を前記装置に行わせる、装置。
2. 前記受信、推定および提供する動作は、データ処理モジュールで行われる、請求項１に記載の装置。
3. 推定器モデルが、前記ノードがある時間においてアップしているか、またはダウンしているかを推定するために生成される、請求項１に記載の装置。
4. 前記推定器モデルは、正確度を評価される、請求項３に記載の装置。
5. 前記評価は、新しいデータ収集ストラテジーを作成するために使用される、請求項４に記載の装置。
6. 前記ノードは、物理ノードである、請求項１に記載の装置。
7. 前記ノードは、論理ノードである、請求項１に記載の装置。
8. 装置によって実行される方法であって、前記装置は、プロセッサおよびメモリを備え、前記装置は、前記メモリ内に記憶されているコンピュータ実行可能な命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
   マシンツーマシン（Ｍ２Ｍ）ネットワークのノードに関する過去の履歴データをデータ収集モジュールから受信することと、
   前記過去の履歴データを使用して、前記ノードがある時間にアップしているか、またはダウンしているかを推定することと、
   前記装置のノード可用性サービスプロビジョニングモジュールに前記推定を提供することであって、前記ノード可用性サービスプロビジョニングモジュールは、前記推定をノード可用性推定サービスとしてクライアントに提供するように構成されている、ことと
   を含む方法の機能を実行する、方法。
9. 前記受信、推定および提供する動作は、データ処理モジュールで行われる、請求項８に記載の方法。
10. 推定器モデルが、前記ノードがある時間においてアップしているか、またはダウンしているかを推定するために生成される、請求項８に記載の方法。
11. 前記推定器モデルは、正確度を評価される、請求項１０に記載の方法。
12. 前記評価は、新しいデータ収集ストラテジーを作成するために使用される、請求項１１に記載の方法。
13. 前記ノードは、物理ノードである、請求項８に記載の方法。
14. 前記ノードは、論理ノードである、請求項８に記載の方法。