JP6529658B2 - Ｍ２ｍクラスタ化管理 - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１８９，８１４号（２０１５年７月８日出願、名称「Ｍ２Ｍ Ｃｌｕｓｔｅｒｉｎｇ Ｍａｎａｇｅｍｅｎｔ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

（ＷＳＮにおけるクラスタ化）
無線センサネットワーク（ＷＳＮ）は、共通タスクを遂行するように協働し、展開面積にわたって短距離無線通信が可能である、多数の空間的に分散された、通常、低コストかつ低電力のセンサから成る。従来の通信システムと比較して、ＷＳＮは、以下、すなわち、高展開密度（モバイルおよびアドホックネットワーク（ＭＡＮＥＴ）より数桁上回る）、低電力ノード（通常、バッテリによって給電され、過酷かつ有害環境においても展開され得る）、無グローバル識別（多数のセンサノードに起因して）、比較的厳密なエネルギー制約、厳密な計算制約、および厳密な記憶制約、ならびにトポロジ変更を要求することを特徴とし得る。概して、Ｊ．Ｚｈｅｎｇ，Ａ．Ｊａｍａｌｉｐｏｕｒ，“Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ：Ａ Ｎｅｔｗｏｒｋｉｎｇ Ｐｅｒｓｐｅｃｔｉｖｅ”，Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ，２００９（以降、Ｚｈｅｎｇ）（参照することによってその全体として組み込まれる）を参照されたい。

図１は、例示的センサネットワークアーキテクチャ１００を図示する。センサ１０１（ノード）は、ゲートウェイを介して、感知されたデータを伝送し、１つ以上のシンク１０２もしくは基地局（ＢＳ）を介して、それをインターネット１０３等のより広いネットワークに利用可能にするために協働する。センサノードの能力制約（限定されたメモリ、処理電力、エネルギー供給、および帯域幅）は、多数のノードから成る典型的展開と組み合わせて、スケーラビリティおよびエネルギー消費等の多くの課題をそのようなネットワークの設計および管理に呈する。この具体的用途を標的化するソリューションが、プロトコルスタックの異なる層におけるエネルギー認知を含め、ルーティングおよびトポロジ等のいくつかのＷＳＮ側面に影響を及ぼすように開発されている。

いくつかのＷＳＮ特有最適化は、グローバルアドレス指定スキームに基づく割り当ておよび更新が、特に、モバイル環境において、動的かつ予測不能なトポロジ変化に伴って、大規模ＷＳＮに重いオーバーヘッドを課すことを考慮して、インターネットプロトコル（ＩＰ）の使用から逸脱している。最適化はまた、ＷＳＮの時間が制約された用途におけるタイムリーな配信のための機構を提供しながら、データ冗長性の高い可能性を考慮する。追加の考慮点は、多くのＷＳＮにおいて、通信負担が、依然として双方向性を要求しながら、マルチキャストまたはピアツーピアではなく、複数のソースから１つの特定のシンクへ著しく指向性であり得ることである。

非ＩＰ ＷＳＨ展開は、フラットまたは階層トポロジを採用し得る。フラットトポロジは、全てのノードが類似プロパティおよび機能を有し、類似タスクをネットワークレベルで行うことを特徴とする。この場合、全てのノードは、ピアである。グローバルアドレス指定スキームを用いない場合、データ収集は、通常、フラッディングを介して、全てのノードへのクエリを通して遂行される。

図２Ａおよび図２Ｂは、フラットならびにクラスタベースの階層ＷＳＮトポロジを図示する。後者では、トポロジノードは、異なるネットワーキングタスクを行い、典型的には、具体的要件またはメトリックに従ってクラスタにグループ化される。クラスタベースのトポロジでは、通信は、グループ内にカプセル化され、クラスタヘッド（ＣＨ）にアドレス指定される。

より低いエネルギーレベルまたはより制約されたリソースを伴うノードは、感知タスクを行い得、結果として生じるデータは、ＣＨ１０５を介してルーティングされ、シンクまたは基地局（ＢＳ）１０６で収集される。ＢＳ１０６は、ＷＳＮ内のゲートウェイとして作用し、典型的には、Ｍ２Ｍサーバと通信する。クラスタ内では、ＢＳ１０６の役割は、主に、通信役割であり、しかしながら、ＢＳ１０６自体が、ＣＨ１０５であり得（エンドノードと直接通信する）、ＣＨ１０５（データシンクとなる）とのみまたは両方と通信し得る。ＣＨ１０５に属するクラスタグループ内では、いくつかのノードは、他のサブクラスタを協調させるＣＨ１０５であり得る。図３は、ＣＨ、ＢＳ、およびノード（例えば、センサ等）等の要素を含む、別の例示的クラスタを図示する。

クラスタは、データ集約または融合、スケーラビリティ、負荷低減、またはエネルギー節約のサポートに役立ち得る。クラスタベースのプロトコルは、これらの一意の特性を利用し、フラットストラテジに優る有意な利点を提供する。環境および自然現象監視、セキュリティ制御および交通量推定、軍事用途のための監視および追跡等のＷＳＮの多くの用途は、ネットワークスケーラビリティを増加し、その寿命を延長させるために、クラスタ化技術に依拠する。

（ＷＳＮにおけるクラスタ化アルゴリズム）
参考文献に説明される従来のクラスタ化アルゴリズムは、ＣＨ選択を決定および最適化し、同時に、ルーティングを決定および最適化するためのクラスタベースのトポロジ管理のために設計されている。クラスタプロトコルは、本明細書に議論されるように、クラスタ化アルゴリズムの特定の実装であり得る。それらは、ＷＳＮ内のスケーラビリティおよび効率的通信専用に設計されており、１つまたは複数のホップ通信を伴い得る。クラスタ化は、ルーティングに影響を及ぼし得る（例えば、より高いエネルギーのノードがルーティングのために使用される一方、低エネルギーノードが感知のために使用されるとき）。クラスタベースのルーティング利点は、より高いスケーラビリティ、データ集約／融合の採用、より低い負荷、およびより低いエネルギー消費を含み得る。

クラスタ化プロトコル設計に取り組み、ＷＳＮ内の通信プロトコル、特に、クラスタ化プロトコルの最適化の必要性を実証する、広範な研究事業および文献が存在する。相当な数の新規スキームが、提案、比較、調査されている。以下は、複数の例を含む、参考文献である。１）Ａｔｕｌ Ｐｒａｔａｐ Ｓｉｎｇｈ，Ｎｉｓｈｕ Ｓｈａｒｍａ；“Ｔｈｅ Ｃｏｍｐａｒａｔｉｖｅ Ｓｔｕｄｙ Ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ Ｏｒ Ｃｌｕｓｔｅｒ Ｂａｓｅｄ Ｒｏｕｔｉｎｇ Ｐｒｏｔｏｃｏｌ Ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋ”，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｅｎｇｉｎｅｅｒｉｎｇ Ｒｅｓｅａｒｃｈ ＆ Ｔｅｃｈｎｏｌｏｇｙ （ＩＪＥＲＴ），Ｖｏｌ．２ Ｉｓｓｕｅ ６，Ｊｕｎｅ−２０１３（以降、Ｓｉｎｇｈ）、２）Ｌｉｌｉａｎａ Ｍ．Ａｒｂｏｌｅｄａ Ｃ．ａｎｄ Ｎｉｄａｌ Ｎａｓｓｅｒ：“Ｃｏｍｐａｒｉｓｏｎ ｏｆ ｃｌｕｓｔｅｒｉｎｇ ａｌｇｏｒｉｔｈｍｓ ａｎｄ ｐｒｏｔｏｃｏｌｓ ｆｏｒ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ”（以降、Ａｒｂｏｌｅｄａ）、３）Ａｍｅｅｒ Ａｈｍｅｄ Ａｂｂａｓｉ，Ｍｏｈａｍｅｄ Ｙｏｕｎｉｓ，“Ａ ｓｕｒｖｅｙ ｏｎ ｃｌｕｓｔｅｒｉｎｇ ａｌｇｏｒｉｔｈｍｓ ｆｏｒ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ”，Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ３０（２００７）２８２６−２８４１（以降、Ａｂｂａｓｉ）、および４）Ｘｕｘｕｎ Ｌｉｕ，“Ａ Ｓｕｒｖｅｙ ｏｎ Ｃｌｕｓｔｅｒｉｎｇ Ｒｏｕｔｉｎｇ Ｐｒｏｔｏｃｏｌｓ ｉｎ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ”，Ｓｅｎｓｏｒｓ ２０１２（以降、Ｌｉｕ）。例は、参照することによってその全体として組み込まれる。

多様性は、提案される問題および分析ならびにモデル化のためのフレームワークにおける広範囲のアプローチならびに相当な変形例を反映する。各クラスタ化アルゴリズムは、ネットワークモデルによって、クラスタ化プロセス属性によって、および具体的最適化目的を用いて作成される具体的コンテキストに基づいて、最適化する。

クラスタ化アルゴリズムを選択するときに考慮されるネットワークモデルは、所与のネットワークおよびその個々のノードの特性を反映する。例えば、考慮点は、以下を含み得る。
・ ノード能力（種々のレベル：ＢＳ、ＣＨ、エンドノードにおける）
ｏ モビリティ：定常／移動性／再測位可能（レベル：ＢＳ／ＣＨ／センサによって異なり得る）
ｏ リソース（例えば、計算、メモリ等）：制約付きまたは豊富
ｏ 役割：中継／シンク／データ集約／感知等
ｏ 多様性：同種対異種（全体的ネットワークまたはＣＨレベル専用）
・ クラスタ化属性：
ｏ クラスタカウント：プリセット／変数
ｏ クラスタサイズ：プリセット／変数
ｏ トポロジ：固定／適応
ｏ ＣＨ／ＢＳコネクティビティ：プロビジョニング／仮定
ｏ ルーティング能力：シングルまたはマルチホップ。
ｏ 再クラスタ化方法論：周期的／イベントベース／等
クラスタ化プロセス属性は、主に、以下等のアルゴリズムのプロシージャ側面に関連する。
・ 先見性：先見的／反応的／ハイブリッド
・ クラスタ化方法論：分散／集中／ハイブリッド
・ ＣＨ選択：ランダム／適応／決定的
・ アルゴリズム複雑性
・ 収束時間：固定／変数
・ 実行タイプ：確率的／反復的
・ クラスタ重複：無し／低／高
前述の特性の多くは、緊密に結び付けられ、したがって、属性の区画化は、静的であることを意図するものではなく、参照される文献において確実に変動することに留意されたい。例えば、ＣＨ選択プロセスの適応、決定的、またはランダム性質は、全体的ノード特性、特に、ＣＨの特性ならびに所与のネットワーク内に存在する異質性のレベルに強く関連する。同様に、クラスタ重複は、ネットワークモデルによって記述され、アルゴリズム選択において施行され得る、プロセス属性である。

個々のクラスタ化アルゴリズムの最適化目的（例えば、目標）は、エネルギー効率、負荷バランシング、フォールトトレランス、コネクティビティの増加および遅延の低減、最小限のクラスタカウント、最大ネットワーク寿命、最大残留エネルギー、およびサービスの品質を含み得る。

クラスタ化アルゴリズム設計は、Ｌｉｕに提供されるように、シングルまたはマルチホップネットワークにおいて、フラットルーティングに優る種々の利点をもたらす。例は、とりわけ、より短い待ち時間およびエネルギー消費、衝突回避、データ集約／融合、ロバスト性およびネットワーク寿命の増加、フォールトトレランス、より優れたコネクティビティの保証、およびエネルギーホール回避を含み得る。これらの利点は、最適化目的にいくつかの定質的改良を追加し、これは、常時、具体的アルゴリズムの選択肢の背後にある目標ではない場合がある。

本明細書では、用語「最適化目的」の使用は、ネットワーク最適化目的が達成されるかどうかを決定するための具体的方法が存在する、アルゴリズムの特徴を指す。例えば、ＬＥＡＣＨは、短通信距離を用いたランダムに位置付けられるセンサのネットワークモデルのための最小伝送ルーティング（ＭＴＥ）システムと比較して、グローバルエネルギー使用を最小限にする最適化目的を達成し、ノード間のＣＨのランダム化が可能であると決定されている。概して、Ｗ．Ｈｅｉｎｚｅｌｍａｎ，Ａ．Ｃｈａｎｄｒａｋａｓａｎ ａｎｄ Ｈ．Ｂａｌａｋｒｉｓｈｎａｎ，“Ｅｎｅｒｇｙ−ｅｆｆｉｃｉｅｎｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ ｆｏｒ ｗｉｒｅｌｅｓｓ ｍｉｃｒｏｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ”，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ３３ｒｄ Ａｎｎｕａｌ Ｈａｗａｉｉ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅｏｎ Ｓｙｓｔｅｍ Ｓｃｉｅｎｃｅｓ，２０００，ｎｏ．１０，ｖｏｌ．２，Ｊａｎ．２０００（以降、Ｈｅｉｎｚｅｌｍａｎ）（参照することによってその全体として組み込まれる）を参照されたい。この決定を行うために、消散されたエネルギー、システム寿命、およびある回数の反復後に有効であるノードの数等の「最適化メトリック」が、定量化および評価されている。定質的最適化目的は、感知された情報を具体的クエリフォーマットで得る能力を含み得るが、最終的に、そのような要件は全て、システム改良を提供するための定量化方法を提供する。用語「従来のアルゴリズムメトリック」は、本明細書で使用されるように、ＬＥＡＣＨに関する受信された電力およびノード独自のエネルギーレベル等の動作するための従来のクラスタ化アルゴリズムによって使用される属性を指す。

以下の表は、専門家によって編成され、調査または比較文献に提示されている。表１−３の情報は、各精査されたアルゴリズムによって提示される特性、利点、および不利点の簡単な概要を提供する。

本明細書では、用語「従来のクラスタ化機能性」は、従来クラスタ化動作（例えば、ＣＨ割り当て／再割り当て、ルーティング、またはトポロジ管理）を遂行する、全てのより低い層機能性を包含するために使用される。

ＷＳＮプロトコルスタックの異なる視点が存在する。従来、最も一般的には、従来のプロトコルスタック内の層化モデルに従い、アプリケーション、トランスポート、ネットワーク、データリンク、および物理層から成る。ＷＳＮ特有性は、図４に示されるように、タスク、接続、および電力管理を提供することに焦点が当てられたバーティカル／機能プレーンの描写に反映される。

他のＷＳＮ特有の最適化は、統合Ｃｒｏｓｓ−Ｌａｙｅｒ Ｍｏｄｕｌｅ ＸＬＭ等の提案をもたらした。概して、Ｉ．Ｆ．Ａｋｙｌｄｉｚ，Ｉ．Ｆ．，ＭＣ．Ｃ．Ｖｕｒａｎ ａｎｄ Ｏ．Ｂ．Ａｋａｎ．"Ａ ｃｒｏｓｓ ｌａｙｅｒ ｐｒｏｔｏｃｏｌ ｆｏｒ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ．"Ｐｒｏｃ．Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ ａｎｄ Ｓｙｓｔｅｍｓ（ＣＩＳＳ’０６）（２００６）：１１０２−１１０７（以降、Ａｋｙｌｄｉｚ）（参照することによってその全体として組み込まれる）を参照されたい。図５は、ＸＬＭクロス層モジュール対ＷＳＮ層化モデルを図示する。ＸＬＭクロス層モジュールは、ＷＳＮにおける全体的エネルギー支出を最適化し、効率的かつ信頼性のあるイベント通信を達成するように設計される。リソース制約センサノードのための単一クロス層モジュールは、動作を分散化および適応させたまま保ちながら、従来のプロトコル層エンティティをマージする。本コンテキストにおける従来のクラスタ化アルゴリズムは、ＸＬＭクロス層モジュール内に実装される。

図６Ａ−図６Ｃは、ＴＣＰ／ＩＰ、ＷＳＮ、およびＷＳＮクロス層モデルのための従来のクラスタ化機能性のプロトコルスタックモデルおよびマッピングの例示的例証である。図４のＷＳＮプロトコルモデルに基づいて、本明細書に開示されるような従来のクラスタ化機能性は、図６Ｂに描写されるように、トランスポート、ネットワーク、データリンク、および物理層にマップし、図４における接続管理プレーンにマップされ得る。描写されるＷＳＮプロトコルモデルは、文献において広く認識されているが、「管理プレーン」は、著作者に応じて異なる傾向にあり、標準化されていない。それらは、ＷＳＮ特有のタスクの反映であり、これは、実際、本ドメインにおける最適化の試みを駆動させる。

図６Ａ−図６Ｃはまた、ＴＣＰ／ＩＰとＷＳＮプロトコルモデルとの間の類似点を描写する。ＷＳＮスタックは、クラスタ内通信のために使用され、したがって、センサ、ＣＨ、ＢＳ、および他のノードによってサポートされる。通常、ＷＳＮは、図１に示されるように、インターネット等のより大きいネットワークに接続される。ＷＳＮの一部であるが、同時に、ゲートウェイ機能性（例えば、ＢＳ、ＣＨ）を提供する、ノードは、デュアルスタックをサポートし、これは、インターネットプロトコルファミリを使用して、ＷＳＮとネットワークを統合する。

本明細書に列挙され、参考文献資料に説明される、従来のクラスタ化アルゴリズム（例えば、表１−表３）は、いくつかの共通属性を有する。第１の属性は、従来のクラスタ化アルゴリズムが、クラスタベースのトポロジ管理のために設計され、ＣＨ選択を決定および最適化し、同時に、ルーティングを決定および最適化することである。各アルゴリズムの最適化部分は、再クラスタ化を提供する。いくつかのアルゴリズムは、集約および融合等のクラスタベースのネットワーク内データ処理を規定する。

第２の属性は、従来のクラスタ化アルゴリズムがその所与の最適化目標内で適応性であることである。例えば、ＤＷＥＨＣでは、ＣＨは、ノード間の距離の関数と考えられる、予期される残留エネルギーに関するメトリックを使用して選定される。例えば、非通信タスクに拡張されたエネルギーがより有意であるため本スキームが非効率的であることが証明される場合、アルゴリズムは、能力グレード等の抽象メトリックに基づいて変更されることができない。概して、Ｐ．Ｄｉｎｇ，Ｊ．Ｈｏｌｌｉｄａｙ ａｎｄ Ａ．Ｃｅｌｉｋ，“Ｄｉｓｔｒｉｂｕｔｅｄ Ｅｎｅｒｇｙ Ｅｆｆｉｃｉｅｎｔ Ｈｉｅｒａｒｃｈｉｃａｌ Ｃｌｕｓｔｅｒｉｎｇ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ”，Ｐｒｏｃ．Ｔｈｅ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ ｉｎ Ｓｅｎｓｏｒ Ｓｙｓｔｅｍｓ ２００５，Ｍａｒｉｎａ Ｄｅｌ Ｒｅｙ，ＣＡ，（２００５），ｐｐ．３２２−３３９（以降、Ｄｉｎｇ）（参照することによってその全体として組み込まれる）を参照されたい。「能力グレード」は、Ｃ４ＳＤ等のアルゴリズムによって使用される属性であり、デバイスハードウェアおよびファームウェア能力等のノード特性に基づく。概して、Ｒ．Ｓ．Ｍａｒｉｎ−Ｐｅｒｉａｎｕ，Ｊ．Ｓｃｈｏｌｔｅｎ，Ｐ．Ｊ．Ｍ．Ｈａｖｉｎｇａ ａｎｄ Ｐ．Ｈ．Ｈａｒｔｅｌ，“Ｃｌｕｓｔｅｒ−ｂａｓｅｄ ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｆｏｒ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ”，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｐａｒａｌｌｅｌ，Ｅｍｅｒｇｅｎｔ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ，２００８（以降、Ｍａｒｉｎ−Ｐｅｒｉａｎｕ）（参照することによってその全体として組み込まれる）を参照されたい。

第３の属性は、従来のクラスタ化アルゴリズムがアプリケーション層の下方に実装されるように設計されることである。いくつかのプロトコル設計は、ＷＳＮが図６Ｂに示されるように、区別されたアプリケーションプロトコルおよびサービス層を提示するように適合している。アプリケーションプロトコル層は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）または制約付きアプリケーションプロトコル（ＣｏＡＰ）等のプロトコルを使用し得、メッセージングおよび輻輳制御等の機能を有し得る。サービス層（ＳＬ）は、サービスとしてアプリケーション層に提供される、データ収集、デバイス管理、セキュリティ等の機能をサポートし得る。他のモデル化方法論（例えば、ＸＬＭクロス層モジュール（Ａｋｙｌｄｉｚ））は、図６Ｃに示されるように、クロス層設計において２つ以上の層からの機能性を組み合わせる。

第４の属性は、従来のクラスタ化アルゴリズムが最適化のためにアプリケーション層の下方で利用可能な情報を使用し、したがって、サービス層（ＳＬ）情報が利用不可能であることである。層化モデルの機能性を保存するために、これらの従来のクラスタ化アルゴリズムは、通常、ネットワーク／ルーティング層である、その独自の層内で利用可能な情報を使用するように設計されている。クロス層設計においてさえ、クラスタ化最適化のために使用される情報は、アプリケーション層の下方で利用可能なものである。

（Ｍ２Ｍ通信におけるサービス層）
開発中のｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１（参照することによってその全体として組み込まれる））は、図７に図示されるように、共通サービスエンティティ（ＣＳＥ）と呼ばれるサービス層を定義する。Ｍｃａ参照点１１１は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ参照点１１３は、同一サービスプロバイダドメイン内の別のＣＳＥ１１５とインターフェースをとり、Ｍｃｃ’参照点１１６は、異なるサービスプロバイダドメイン１１７内の別のＣＳＥ（図示せず）とインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）１１９とインターフェースをとる。ＮＳＥ１１９は、下層ネットワークサービスを、デバイス管理、場所サービス、およびデバイストリガリング等のＣＳＥに提供する。ＣＳＥは、「発見」または「データ管理およびレポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。

Ｍ２Ｍ通信では、サービス層（ＳＬ）は、Ｍ２Ｍデバイスと顧客アプリケーションとの間のセキュアなエンドツーエンドデータ／制御交換をサポートすることによって、第三者付加価値サービスおよびアプリケーションの配信のためのプラットフォームをイネーブルにし、遠隔プロビジョニングおよびアクティブ化、認証、暗号化、コネクティビティ設定、バッファリング、同期、集約、およびデバイス管理のための能力を提供することを目的とする。ＳＬは、下層ネットワークへのインターフェースを提供し、例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）を通して、第三者コンテンツプロバイダを通してアクセスされるサービスプロバイダ（ＳＰ）によって所有されるサーバを使用して、能力をイネーブルにし得る。

Ｍ２Ｍ／ＩｏＴサービス層は、具体的には、Ｍ２Ｍ／ＩｏＴタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを標的化される。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍ等の標準化団体は、センサおよびデバイスネットワークを具体的に標的化するＭ２Ｍサービス層を開発している。デバイス管理（ＤＭ）は、付加価値サービスの中でもとりわけ、ファームウェアおよびソフトウェア管理、セキュリティおよびアクセス制御、デバイス監視、およびロギング等の問題のためのソリューションを提供するために、大部分のＳＬプラットフォームによって標的化される。

ｏｎｅＭ２Ｍアーキテクチャは、ネットワーク内の異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）に基づく。

ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャ（リソース指向アーキテクチャまたはＲｏＡとしても知られる）内では、ＣＳＥは、図８に示されるように、共通サービス機能（ＣＳＦ）の組のインスタンス化をサポートする。ＣＳＦ機能性は、作成、読み出し、更新、および削除等のＲＥＳＴｆｕｌ方法を介して操作されることができる表現を有する一意にアドレス指定可能なエンティティである、リソースを介して実装される。これらのリソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用してアドレス指定可能である。リソースは、リソースについての関連情報を記憶する、属性の組をサポートし、子リソースと称される他のリソースへの参照を含み得る。子リソースは、親リソースと包含関係を有し、その寿命が親のリソース寿命によって限定される、リソースである。

ｏｎｅＭ２Ｍは、導入されるＲｏＡアーキテクチャに加え、サービス指向アーキテクチャ（ＳｏＡ）アプローチを使用する、仕様を提供している。概して、Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ”ｏｎｅＭ２Ｍ−ＴＳ−０００７，ｏｎｅＭ２Ｍ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｎｅｎｔ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−０．６．０（参照することによってその全体として組み込まれる）を参照されたい。ＳｏＡアーキテクチャ概念は、構築ブロックとして、明確に異なるソフトウェアモジュールによって提供され、サービスとして知られる機能性の考慮に基づく。サービスは、ベンダ、製品、または技術から独立する、規定されたインターフェースを介して、アプリケーションに提供される。ｏｎｅＭ２ＭにおけるＣＳＥ１２１のＳｏＡ表現は、図９に示される。

展開の観点から、図１０は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を描写する。ｏｎｅＭ２Ｍアーキテクチャは、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、ミドルノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）をイネーブルにする。ＡＳＮは、１つのＣＳＥを含み、少なくとも１つのＡＥを含む、ノードである。物理的マッピングの例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。ＡＤＮは、少なくとも１つのＡＥを含み、ＣＳＥを含まない、ノードである。物理的マッピングの例は、制約付きＭ２Ｍデバイス内に常駐するＡＤＮである。ＭＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含む、ノードである。ＭＮのための物理的マッピングの例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。ＩＮは、１つのＣＳＥを含み、ゼロ以上のＡＥを含む、ノードである。ＩＮのための物理的マッピングの例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。また、ｏｎｅＭ２Ｍエンティティ（ＡＥまたはＣＳＥのいずれでもない）を含まないノードである、非ｏｎｅＭ２Ｍノードが存在し得る。そのようなノードは、管理を含むインタワーキング目的のためにｏｎｅＭ２Ｍシステムにアタッチされたデバイスを表す。

（ＷＳＮにおける再プログラミング）
センサネットワーク展開は、各個々のノードに物理的に到達する必要なくソフトウェアおよびファームウェア保守を行う能力を伴って設計されるべきである。近年のモバイルデバイスの広範な採用は、モバイルデバイス管理（ＤＭ）の分野における著しい進歩につながっている。多くのＤＭ方法は、携帯電話等のリソース豊富デバイスに対処するが、ＬＷＭ２Ｍ（Ｍａｒｉｎ−Ｐｅｒｉａｎｕ参照）等のいくつかのプロトコルおよび方法は、制約付きデバイスのためのソリューションを提供する。関連問題は、他の標準化団体において積極的評価段階にある。概して、Ｍ．Ｅｒｓｕｅ，Ｄ．Ｒｏｍａｓｃａｎｕ，Ｊ．Ｓｃｈoｎｗaｌｄｅｒ，“Ｍａｎａｇｅｍｅｎｔ ｏｆ Ｎｅｔｗｏｒｋｓ ｗｉｔｈ Ｃｏｎｓｔｒａｉｎｅｄ Ｄｅｖｉｃｅｓ：Ｐｒｏｂｌｅｍ Ｓｔａｔｅｍｅｎｔ ａｎｄ Ｒｅｑｕｉｒｅｍｅｎｔｓ”ＩＥＴＦ Ｄｒａｆｔ，ＵＲＬ：ｈｔｔｐｓ：／／ｄａｔａｔｒａｃｋｅｒ．ｉｅｔｆ．ｏｒｇ／ｄｏｃ／ｄｒａｆｔ−ｅｒｓｕｅ−ｏｐｓａｗｇ−ｃｏｍａｎ−ｐｒｏｂｓｔａｔｅ−ｒｅｑｓ／（参照することによってその全体として組み込まれる）を参照されたい。研究組織はまた、マルチホップコード分散システム無線センサネットワークに標的化される方法に特に関心を持って、そのような方法に対処している。概して、１）Ｂ．Ｈｅｍａｐｐａ，Ｂ．Ｔ．Ｓｈｙｌａｊａ，Ｄ．Ｈ．Ｍａｎｊａｉａｈ，Ｂ．Ｒａｂｉｎｄｒａｎａｔｈ，“Ａｎ Ｅｎｅｒｇｙ Ｅｆｆｉｃｉｅｎｔ Ｒｅｍｏｔｅ Ｄａｔａ Ｃｏｌｌｅｃｔｉｏｎ ａｎｄ Ｒｅｐｒｏｇｒａｍｍｉｎｇ ｏｆ Ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒｓ Ｎｅｔｗｏｒｋｓ” Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔｅｒ Ｔｒｅｎｄｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ，ｖｏｌｕｍｅ ３，Ｉｓｓｕｅ ３，２０１２（以降、Ｈｅｍａｐｐａ）、および２）Ｔ．Ｓｔａｔｈｏｐｏｕｌｏｓ，Ｊ．Ｈｅｉｄｅｍａｎｎ，Ｄ．Ｅｓｔｒｉｎ，“Ａ Ｒｅｍｏｔｅ Ｃｏｄｅ Ｕｐｄａｔｅ Ｍｅｃｈａｎｉｓｍ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ” ＣＥＮＳ Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＃３０，Ｃｅｎｔｅｒ ｆｏｒ Ｅｍｂｅｄｄｅｄ Ｎｅｔｗｏｒｋｅｄ Ｓｅｎｓｉｎｇ，ＵＣＬＡ，Ｌｏｓ Ａｎｇｅｌｅｓ，ＣＡ，ＵＳＡ，２００３（以降、Ｓｔａｔｈｏｐｏｕｌｏｓ）を参照されたい。ＨｅｍａｐｐａおよびＳｔａｔｈｏｐｏｕｌｌｏｓは、参照することによってその全体として組み込まれる。

無線センサネットワーク（ＷＳＮ）内のクラスタベースのトポロジは、クラスタヘッド（ＣＨ）を介して、シンクまたは基地局（ＢＳ）に通信するセンサのグループを使用し、とりわけ、ＣＨ再割り当て、ルーティング、またはトポロジ管理のために、従来のクラスタ化アルゴリズムに基づく。

従来のクラスタ化プロトコルは、通常、展開時に、ネットワークモデルおよび最適化目的を含む、初期コンテキストに基づいて選定および構成されるように設計される。しかしながら、センサネットワークは、通常、大規模かつ長寿命であり、したがって、変化するネットワーク使用、目的、トポロジ、ノード構成等に伴って、動的コンテキストを有する。従来のクラスタ化アルゴリズムは、ネットワーク再編成を提供するが、それらは、静的である具体的初期構成（最適化目標、ネットワークモデル等）に基づいて最適化するように選定される。結果は、論文および表１から表３に要約される例に示されるように、多くの性能利得が、ネットワークモデル、クラスタ化プロセス属性、および具体的最適化目的等の具体的コンテキスト内でのみ各クラスタ化アルゴリズムによって完全に達成され得ることを実証するように考慮され得る。コンテキストが変化すると、他のアルゴリズムが、展開または用途の需要を満たすようにより良好に好適にされ得る。

本明細書に開示されるのは、それを通してサービス層（ＳＬ）が、ＳＬ分析に基づき得る、従来のクラスタ化アルゴリズム再選択および性能最適化を介して、Ｍ２Ｍ／ＩｏＴ ＳＬプラットフォーム内のＷＳＮのためのクラスタ化管理能力を提供し得る、例示的方法、システム、および装置である。クラスタ化機能性は、各従来のクラスタ化アルゴリズムによって採用される個々のネットワークモデルおよび最適化目標内において適合され得るだけではなく、従来のクラスタ化アルゴリズム自体も、ＳＬ機能性を使用して変更または再構成され得る。これらの再構成は、ＷＳＮ性能が準最適であり、メッセージあたりベースにおける動的ルーティング決定と比較して、有意に大きい時間スケール内で生じ得ることを示す、分析に基づき得る。

例では、クラスタ情報（例えば、トポロジ）を維持し、それとサービス指向情報を関連付けるために、クラスタプロファイルレジストリ（ＣＰＲ）内にクラスタプロファイルが存在し得る。また、クラスタプロファイルの一部としてクラスタ管理ポリシおよび特別なメトリック（クラスタ化管理および性能最適化専用）が存在し得る。

例では、ＣＰＲとＳＬベースの分析および論理を併用して、従来のクラスタ化を拡張させるための拡張クラスタ管理機能（ＥＣＭＦ）が存在し得る。

例では、単一クラスタのための従来のクラスタ化アルゴリズムを拡張させ得る、ＥＣＭＦのためのクラスタ内最適化方法が存在し得る。第１の方法は、クラスタプロファイルまたはＣＰＲ等の情報を介して、クラスタ関連情報を要求し、ＳＬ内に維持するために使用され得る。第２の方法は、自動的に、またはＳＰもしくは他のプロンプトに基づいて、従来のクラスタ化アルゴリズム再選択または最適化をトリガするために使用され得る。第３の方法は、サービスメトリック（例えば、コスト、有用性、サービス冗長性）またはサービス特性（例えば、クエリタイプ、パラメータ等）に基づいて、従来のクラスタ化アルゴリズム選択を適合させるために使用され得る。第４の方法は、所与または新しい最適化目標に基づいて、従来のクラスタ化アルゴリズムパラメータ（例えば、タイマまたは閾値）を適合させるために使用され得る。

第５の方法は、クラスタ化ポリシおよびメトリックを使用して、従来のクラスタ化アルゴリズムのための新しいまたは別個のクラスタ化最適化目標を導入する方法を提供するために使用され得る。例えば、サービスプロバイダは、競合目標をもたらす、エネルギー効率とともに通信信頼性等の高度要件を有し得る。ユーザインターフェースの高度化のレベルに応じて、高度要件は、伝送遅延、最小および最大データ再伝送等のいくつかのメトリックに変換され得る。これらのメトリックの各組み合わせは、ひいては、異なる候補の従来のクラスタ化アルゴリズムをもたらし得る。第６の方法は、新しいクラスタ形成を含む、クラスタ再構成をトリガするために使用され得る。

例では、グローバル、ＳＬ特有情報、および追加の分析を使用して、複数のＳＬイネーブル化クラスタの性能を拡張させる、ＥＣＭＦのためのクラスタ間最適化方法が存在し得る。これらの方法はまた、ＢＳ間のクラスタ転送のためのプロシージャを最適化するために使用され得る。これらの方法はさらに、同一ＳＬ内の他のクラスタおよびクラスタタイプとの統合のための統合されたクロス層ベースのプラットフォームを使用して、クラスタによって使用され得る。

例では、説明される方法またはその拡張に基づいて、ＳＬ内の他のエンティティおよびユーザ（例えば、エンドユーザまたはサービスプロバイダのデバイス）に利用可能にされ、さらに、インフラストラクチャドメイン上のアプリケーションをイネーブルにし、ユーザ相互作用をサポートする、ＡＰＩが存在し得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に制約されない。
例えば、本願は以下の項目を提供する。
（項目１）
クラスタ化を管理するための装置であって、前記装置は、
プロセッサと、
前記プロセッサと結合されているメモリと
を備え、
前記メモリは、実行可能命令を備え、前記命令は、前記プロセッサによって実行されると、
クラスタプロファイルレジストリを伴うクラスタ管理をイネーブルにするパラメータのリストを受信することと、
前記パラメータに基づいて、前記装置に関連付けられたデバイスのクラスタのプロファイルを作成することであって、前記デバイスのクラスタは、現在のクラスタ化アルゴリズムに基づいて通信する、ことと、
前記デバイスのクラスタの前記プロファイルを前記クラスタプロファイルレジストリに登録することと
を含む動作を前記プロセッサに達成させる、装置。
（項目２）
さらなる動作が、
最適化目的が満たされていないことを決定することと、
前記最適化目的が満たされていないことを決定することに応答して、前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと
を含む、項目１に記載の装置。
（項目３）
さらなる動作が、
前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
前記最適化目的が満たされていないことを決定することに応答して、前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと
を含み、
前記最適化目的は、前記デバイスのクラスタのための通信コストを含む、項目１に記載の装置。
（項目４）
さらなる動作が、
前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと、
前記性能を評価することに基づいて、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することと、
前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することに応答して、前記デバイスのクラスタを前記候補クラスタ化アルゴリズムに再構成するための命令を提供することと
を含む、項目１に記載の装置。
（項目５）
さらなる動作が、
最適化目的が満たされていないことを決定することと、
最適化目的が満たされていないことを決定することに応答して、前記クラスタ化アルゴリズムを再構成するための命令を提供することと
を含む、項目１に記載の装置。
（項目６）
前記デバイスのクラスタは、無線デバイスを含む、項目１に記載の装置。
（項目７）
さらなる動作が、前記プロファイルに関連付けられたパラメータの閾値変化に基づいて、前記プロファイルを更新することを含み、前記パラメータは、通信コストまたは配信遅延を含む、項目１に記載の装置。
（項目８）
さらなる動作が、クラスタトポロジ再構成をトリガすることを含む、項目１に記載の装置。
（項目９）
さらなる動作が、前記プロファイルを新しい最適化目的で更新することを含む、項目１に記載の装置。
（項目１０）
前記装置は、クラスタヘッドまたは基地局である、項目１に記載の装置。
（項目１１）
クラスタ化を管理する方法であって、前記方法は、
装置によって、クラスタプロファイルレジストリを伴うクラスタ管理をイネーブルにするパラメータのリストを受信することと、
前記パラメータに基づいて、前記装置に関連付けられたデバイスのクラスタのプロファイルを作成することであって、前記デバイスのクラスタは、現在のクラスタ化アルゴリズムに基づいて通信する、ことと、
前記デバイスのクラスタのプロファイルを前記クラスタプロファイルレジストリに登録することと
を含む、方法。
（項目１２）
前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
前記最適化目的が満たされていないことを決定することに応答して、前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと
をさらに含む、項目１１に記載の方法。
（項目１３）
前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
前記最適化目的が満たされていないことを決定することに応答して、前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと
をさらに含み、
前記最適化目的は、前記デバイスのクラスタのための通信コストを含む、項目１１に記載の方法。
（項目１４）
前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと、
前記性能を評価することに基づいて、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することと、
前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することに応答して、前記デバイスのクラスタを前記候補クラスタ化アルゴリズムに再構成するための命令を提供することと
をさらに含む、項目１１に記載の方法。
（項目１５）
前記プロファイルに関連付けられたパラメータの閾値変化に基づいて、前記プロファイルを更新することをさらに含み、前記パラメータは、配信遅延を含む、項目１１に記載の方法。
（項目１６）
最適化目的が満たされていないことを決定することと、
最適化目的が満たされていないことを決定することに応答して、前記クラスタ化アルゴリズムを再構成するための命令を提供することと
をさらに含む、項目１１に記載の方法。
（項目１７）
クラスタトポロジ再構成をトリガすることをさらに含む、項目１１に記載の方法。
（項目１８）
前記プロファイルを新しい最適化目的で更新することをさらに含む、項目１１に記載の方法。
（項目１９）
２つ以上のデバイスクラスタを管理する方法であって、前記方法は、
最適化目的を満たすための前記２つ以上のデバイスのクラスタ内のクラスタ化アルゴリズムの性能を評価することと、
前記性能を評価することに基づいて、前記クラスタ化アルゴリズムのうちの第１のクラスタ化アルゴリズムの性能が満たされていないことを決定することと、
前記クラスタ化アルゴリズムのうちの前記第１のクラスタ化アルゴリズムの性能が満たされていないことを決定することに応答して、前記２つ以上のデバイスクラスタのうちの少なくとも１つのデバイスのクラスタを再構成するための命令を提供することと
を含む、方法。
（項目２０）
前記２つ以上のデバイスクラスタは、基地局を介して接続されている、項目１９に記載の方法。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、例示的センサネットワークアーキテクチャを図示する。 図２Ａは、フラットおよびクラスタベースの階層ＷＳＮトポロジを図示する。図２Ｂは、フラットおよびクラスタベースの階層ＷＳＮトポロジを図示する。 図３は、ＣＨ、ＢＳ、およびノード等の要素を含む、別の例示的クラスタを図示する。 図４は、タスク、接続、および電力管理を提供することに焦点が当てられたバーティカル／機能プレーンの描写を図示する。 図５は、ＸＬＭクロス層モジュール対ＷＳＮ層化モデルを図示する。 図６Ａは、図６Ｂおよび図６Ｃと併せて、ＴＣＰ／ＩＰ、ＷＳＮ、およびＷＳＮクロス層モデルのための従来のクラスタ化機能性のプロトコルスタックモデルおよびマッピングを図示する。図６Ｂは、図６Ａおよび図６Ｃと併せて、ＴＣＰ／ＩＰ、ＷＳＮ、およびＷＳＮクロス層モデルのための従来のクラスタ化機能性のプロトコルスタックモデルおよびマッピングを図示する。図６Ｃは、図６Ａおよび図６Ｂと併せて、ＴＣＰ／ＩＰ、ＷＳＮ、およびＷＳＮクロス層モデルのための従来のクラスタ化機能性のプロトコルスタックモデルおよびマッピングを図示する。 図７は、共通サービスエンティティと呼ばれるサービス層を定義する、ｏｎｅＭ２Ｍ規格を図示する。 図８は、ｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌアーキテクチャを図示する。 図９は、ｏｎｅＭ２ＭにおけるＣＳＥのＳｏＡ表現を図示する。 図１０は、ｏｎｅＭ２Ｍアーキテクチャによってサポートされる構成を図示する。 図１１は、例示的クラスタベースのセンサネットワークを図示する。 図１２は、拡張クラスタ化機能性を伴う例示的無線センサネットワーク（ＷＳＮ）を図示する。 図１３Ａは、サービス層と併せて実装され得る、ＥＣＭＦの例を図示する。図１３Ｂは、サービス層と併せて実装され得る、ＥＣＭＦの例を図示する。

図１４は、ＥＣＭＦおよびＣＰＲならびに他のＳＬ間の例示的論理相互作用を図示する。 図１５は、クラスタプロファイル登録のための例示的メッセージフローを図示する。 図１６は、ＣＰＲにクエリするための例示的メッセージフローを図示する。 図１７は、ＣＰＲからの情報のクエリのための例示的メッセージフローを図示する。 図１８は、ＥＳとの相互作用のための例示的メッセージフローを図示する。 図１９は、関連付けられたＣＰＲ相互作用を示す、ＳＬとの例示的ＥＣＭＦ相互作用を図示する。 図２０は、例示的クラスタ内管理プロシージャを図示する。 図２１は、例示的クラスタ間管理プロシージャを図示する。 図２２は、ｏｎｅＭ２Ｍ機能アーキテクチャ内のＥＣＭＦおよびＣＰＲ機能の例示的位置を図示する。 図２３は、ｏｎｅＭ２Ｍ機能アーキテクチャ内のＥＣＭＦおよびＣＰＲ機能の例示的位置を図示する。 図２４は、現在のｏｎｅＭ２ＭＲｏＡアーキテクチャに基づく開示されるクラスタ化管理を実装するための一例を図示する。 図２５は、クラスタプロファイルを記述するためにｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌ内で使用され得る、リソースを図示する。 図２６は、現在のｏｎｅＭ２ＭＳｏＡアーキテクチャに基づく例示的クラスタ管理を図示する。 図２７は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。 図２８は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。 図２９Ａは、開示される主題が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムを図示する。 図２９Ｂは、図２９Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャを図示する。 図２９Ｃは、図２９Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスを図示する。 図２９Ｄは、図２９Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムを図示する。

表１、表２、および表３におけるアルゴリズムは、従来のクラスタ化アルゴリズムであり、Ｚｈｅｎｇ、Ｓｉｎｇｈ、Ａｒｂｏｌｅｄａ、およびＡｂｂａｓｉによって引用される参考文献に説明されている。本明細書で参照される具体的例は、とりわけ、ＬＥＡＣＨ、ＴＥＥＮ、およびＡＰＴＥＥＮである。本開示は、各個々のアルゴリズムの詳細ではなく、表１、表２、および表３に詳述される比較結果を取り上げる。最新技術を前提として、本開示は、好適な再プログラミング方法がＷＳＮを統合するＭ２Ｍサービスプラットフォームのコンテキストにおいて利用可能であると仮定する。これらの方法は、ＣＨおよびＢＳだけではなく、ＷＳＮリソース制約付きノードに適用され得る。

Ｍ２Ｍサービス層プラットフォーム方法によって提供されるデバイス管理（ＤＭ）サービスはまた、「再プログラミング」と称されるファームウェア／ソフトウェア更新方法のためのソリューションを提供する。再プログラミングのために使用されるいくつかの高度方法は、他の管理機能によって使用されるものと同一または類似し得、したがって、ＷＳＮにおけるファームウェア更新のコンテキストでは、専門用語「ＤＭ」および「再プログラミング」方法は、同義的に使用され得る。しかしながら、ＢＳ等のＳＬイネーブル化ノードにおいて使用される更新方法は、ＬＷＭ２Ｍサーバによって提供され得るが、リソース制約付きノードの再プログラミングは、ＢＳによって、ＣＨを介して、本明細書に参照されるもの等の遠隔コード更新機構を介して提供され得る。Ｓｔａｔｈｏｐｏｕｌｏｓを参照されたい。遠隔コード更新機構の例は、Ｓｔａｔｈｏｐｏｕｌｏｓに見出されるクロスボウネットワークプログラミング（ＸＮＰ）およびマルチホップ無線経由プログラミング（ＭＯＡＰ）ならびにＤｅｌｕｇｅおよびＣＯＲＤを含む。

従来のクラスタ化プロトコルは、通常、展開時に、ネットワークモデルおよび最適化目的を含む初期コンテキストに基づいて、選定および構成されるように設計される。センサネットワークは、大規模かつ長寿命であり、したがって、変化するネットワーク使用または目的、トポロジ、ノード構成等に伴って動的コンテキストを有し得る。従来のクラスタ化アルゴリズムは、ネットワーク再編成を提供するが、それらは、静的である具体的初期構成（最適化目標、ネットワークモデル等）に基づいて最適化するように選定される。本明細書に開示されるのは、とりわけ、クラスタ化アルゴリズムおよび性能最適化の再選択ならびに後続実装のための方法、システム、および装置である。

注記：以下の使用例に関して、一般に、本紙全体を通して、用語「ユーザおよびユーザ／ＳＰ」は、改良されたクラスタ化性能を達成することに関心がある任意の利害関係者に関して同義的に使用される。導入される機能とのその相互作用は、サービス層内の特別なＡＰＩを通して提供される。任意のマルチユーザアクセスは、ＳＬ内で仲裁され、本紙の範囲内ではないと仮定される。

以下は、開示される主題に関するさらなるコンテキストを与える、シナリオである。図１１は、例示的クラスタベースのセンサネットワークを図示する。工場構内の周囲のセンサが図１１内のゾーン１４０を形成し、ネットワークは、最初に、周期的ユーザクエリに応答する（例えば、周囲温度平均のみを追跡する）ように設定する、シナリオを検討する。システムは、最初に、先見的アプローチとして知られるものに基づいて構成される。例えば、ゾーン１４０のセンサノードは、周期的に、スイッチをオンにし、環境を感知し、事前に定義されたデータの組を、定期的に、ユーザのデバイスがクエリし得る、ＢＳ１３４のＣＰＲ１３６に送信する。周期的クエリ構成から生じる測定報告要件に基づいて、ノードは、最初に、先見的従来のクラスタ化プロトコル（例えば、ＬＥＡＣＨ）を用いて構成され、クラスタベースのセンサネットワークをもたらす。追加のコンテキストに関して、ＷＳＮが電力効率的であるという根本的期待がある（そうでなければ、全てが常時となり得る）ことを理解されたい。

初期構成（時間Ｔ１において）後、環境条件が新しい加工プロセスに有意に影響を及ぼすことが決定され得、したがって、１）あるウイング内の温度が第１の閾値を下回る場合、アラームを送信する、２）直近３時間にわたるある象限内の平均温度を読み出す、３）以降の３時間にわたって、温度が閾値Ｂを上回る場合、報告する、または４）過去３時間における閾値Ａと閾値Ｂとの間の温度を有していた面積を報告する等の新しい動作要件または他の使用が、クエリに関して工場において開発される。

時間Ｔ１では、ＬＥＡＣＨに基づくオリジナルの先見的設定は、データが頻繁に伝送され（変化しない条件下でも）、重要な情報がＢＳ１３４のＣＰＲ１３６から抽出される必要があるので、有意にあまり効率的ではなくなる。反応的アプローチが時間Ｔ１において使用される場合、センサは、感知される属性の値における急激な変化を検出するように構成されるであろう（プリセット閾値に基づいて）が、時間制約データに関するクエリに対して容認不可能な遅延が存在し得る。ＡＰＴＥＥＮ等のハイブリッドの従来のクラスタ化プロトコルは、おそらく、時間Ｔ１後、より良好に機能するであろう。ＡＰＴＥＥＮに関しては、概して、Ａ．Ｍａｎｊｅｓｈｗａｒ ａｎｄ Ｄ．Ｐ．Ａｇｒａｗａｌ．"ＡＰＴＥＥＮ：ａ ｈｙｂｒｉｄ ｐｒｏｔｏｃｏｌ ｆｏｒ ｅｆｆｉｃｉｅｎｔ ｒｏｕｔｉｎｇ ａｎｄ ｃｏｍｐｒｅｈｅｎｓｉｖｅ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｔｒｉｅｖａｌ ｉｎ ｗｉｒｅｌｅｓｓ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ．"Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｐａｒａｌｌｅｌ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｉｓｓｕｅｓ ｉｎ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋｓ ａｎｄ Ｍｏｂｉｌｅ ｃｏｍｐｕｔｉｎｇ（２００２）：４８（以降、Ｍａｎｊｅｓｈｗａｒ）（参照することによってその全体として組み込まれる）を参照されたい。この場合、データ分析が、従来のクラスタ化プロトコルを変更するために使用され得る。データ分析は、閾値およびタイマ等のアルゴリズムパラメータならびにセンサネットワークの完全再構成のための最良設定を決定することに役立ち得る。通常、分析および再構成は、最適化を提供するために相互作用しない、明確に異なる機能として実装される。

本シナリオでは、従来のクラスタ化アルゴリズムは、センサネットワーク内の変化、用途の必要性、または外部条件に伴って準最適と成り得ることが分かる。従来のソリューションでは、クラスタ最適化をイネーブルにし、最初に構成されたものと異なるアルゴリズム（またはパラメータ）を使用するための効率的方法が欠けている。

図１１を参照してシナリオを継続すると、後の時間（Ｔ２）において、隣接する工業団地は、ゾーン１４６内にセンサネットワークを有し、これは、ゾーン１４０によって使用される同一ＳＬプラットフォームと統合される。ゾーン１４０およびゾーン１４６は、いくつかの類似センサ（例えば、大気圧センサ）を含み得る。従来のクラスタ化アルゴリズム選択に関して、個々のクラスタが最適化される場合でも、大気圧センサ間の情報冗長性は、不必要な報告を低減させるために利用され得ない。ゾーン１４１およびゾーン１４６を含む、統合されたネットワーク全体のさらなる最適化のための機会が存在する。本明細書に議論されるように、サービス層（ＳＬ）は、センサネットワーク関連情報を収集および分析し、分析を採用し、クラスタ内の最適機能を決定するために位置付けられる。本明細書で議論される方法は、ＳＬの使用をイネーブルにし、例えば、協調された様式で複数のクラスタの機能性を最適化する。

開示されるのは、従来のクラスタ化機能性を補助する、サービス層拡張クラスタ化（ＳＬＥＣ）機能性である。ＳＬＥＣ機能性は、インフラストラクチャノード上で必要または可能な拡張が、例えば、別のデバイス上の実装のために必要または可能な拡張と異なり得るので、実装されるノードに基づいて区別され得る。

また、開示されるのは、従来のプロトコルスタックのより下位の層において従来のクラスタ化アルゴリズムによって提供される論理に加え、クラスタおよびサブクラスタの管理におけるＳＬ論理を提供し得る、拡張クラスタ管理機能（ＥＣＭＦ）である。ＥＣＭＦ機能性は、クラスタ内管理またはクラスタ間管理のために提供され得る。加えて、本明細書に開示されるのは、非サービス関連情報（例えば、デバイス特性、トポロジ等）に加え、クラスタ内で管理されるセンサネットワークのサービス関連コンテキストを記述する、クラスタプロファイルである。開示されるようなクラスタプロファイルレジストリ（ＣＰＲ）は、クラスタプロファイルを管理する、Ｍ２Ｍサービス層内の論理機能であり得る。

図１２は、拡張クラスタ化機能性を伴う、例示的無線センサネットワーク（ＷＳＮ）を図示する。図１２では、インフラストラクチャノード（ＩＮ）１３１は、ＥＣＭＦ１３２と、ＣＰＲ１３３とを含む。ＩＮ１３１は、ＢＳ１３４およびＢＳ１３７と通信可能に接続される。ＢＳ１３４は、ＥＣＭＦ１３５と、ＣＰＲ１３６とを含む。ＢＳ１３４はまた、ゾーン１４０と通信可能に接続され、これは、ＣＨ１４１およびＣＨ１４３との接続を含む。ＣＨ１４１は、ＥＣＭＦ１４２を含み、ノード１４５等の複数のノードと通信可能に接続される。ＣＨ１４３は、ＥＣＭＦ１４４を含み、ノード１５０およびＣＨ１５４等の複数のノードと通信可能に接続される。ＢＳ１３７は、ＥＣＭＦ１３８と、ＣＰＲ１３９とを含む。ＢＳ１３７は、ゾーン１４６と通信可能に接続され、これは、ＣＨ１４８およびＣＨ１４９との接続を含む。ＣＨ１４８は、ＥＣＭＦ１５５を含み、ＣＨ１４７は、ＥＣＭＦ１５６を含む。

ＥＣＭＦ（例えば、ＥＣＭＦ１３２、ＥＣＭＦ１４４等）は、より下層（例えば、図４または図６Ａに示されるように、アプリケーション層またはＳＬの下方の層）において従来のクラスタ化アルゴリズム（例えば、表１のアルゴリズム等）によって提供される従来の論理に加え、クラスタ（例えば、ゾーン１４０）およびサブクラスタ（例えば、クラスタ１５２またはクラスタ１５３）を管理する。本明細書により詳細に議論されるように、ＥＣＭＦ１４４は、例えば、クラスタ１５３をＣＰＲ１３６に登録し、登録の結果、ＣＰＲ１３６内で作成されたクラスタ１５３に関連付けられたクラスタプロファイル（図示せず）に関するアクセス制御情報を提供するために使用され得る。別の例では、ＥＣＭＦ１４４は、クラスタ１５３に関連付けられたクラスタプロファイルのパラメータを更新するために使用され得る。

図１３Ａおよび図１３Ｂは、サービス層と併せて実装され得る、ＥＣＭＦの例を図示する。図１３Ａおよび図１３Ｂはまた、ＥＣＭＦと従来のクラスタ化アルゴリズムの可能な相互作用を図示する。図１３Ａでは、ＥＣＭＦ１３５は、従来のプロトコルスタック層化モデルに従って、ＳＬの機能として実装される。したがって、ＥＭＣＦ１３５は、下方の層を使用して、サービスを上方の層（アプリケーション）に提供する。図１３Ａでは、ＥＣＭＦ１３５は、より下位の層を再プログラムし、従来のクラスタ化機能性を最適化するための命令を提供するが、より下位の層は、ＥＣＭＦ１３５から独立して機能する。例えば、従来のクラスタ化アルゴリズム（例えば、表１−表３またはまだ開発されていない類似アルゴリズム）が、この場合、修正を伴わずに、より下位の層内に実装され得る。

図１３Ｂでは、ＥＣＭＦ１４４は、クロス層実装専用のプラットフォーム上のより下位の層内に実装される従来のクラスタ化機能性と統合される。概して、Ｊ．Ｍａｒｒｏ’ｎ，ｅｔ ａｌ．，"ＴｉｎｙＣｕｂｕｓ：ａ ｆｌｅｘｉｂｌｅ ａｎｄ ａｄａｐｔｉｖｅ ｆｒａｍｅｗｏｒｋ ｓｅｎｓｏｒ ｎｅｔｗｏｒｋｓ．"Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｓｅｃｏｎｄ Ｅｕｒｏｐｅａｎ Ｗｏｒｋｓｈｏｐ ｏｎ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ （２００５）：２７８−２８９（以降、Ｍａｒｒｏ’ｎ）（参照することによってその全体として組み込まれる）を参照されたい。Ｍａｒｒｏ’ｎは、層を統合し、最大最適化を提供し得る概念をサポートする。したがって、ホリゾンタルのより下位の層（例えば、物理、ＭＡＣ、トランスポート）はもはや存在しないが、１つのみのクロス層モジュールが、代わりに、存在する。これは、従来のアルゴリズムのうちの１つがＥＣＭＦ機能性を用いて拡張される、または全体的に新しいアルゴリズムが従来のクラスタ化機能性（ＣＨ選択／再選択、ルーティング、トポロジ管理）およびＥＣＭＦ機能性の両方を提供するように設計される場合に当てはまり得る。これは、より下位の層およびＳＬレベル機能性を含む、事実上新しいクロス層アルゴリズムを作成する。層間のクラスタ化管理関連データ交換は、種々の方法、すなわち、ローカル機能コール、再構成、統合プロトコル等において実装され得る。

ＥＣＭＦ（例えば、ＥＣＭＦ１３２、ＥＣＭＦ１４４、ＥＣＭＦ１５６等）が、クラスタ内管理ならびにクラスタ間管理のために提供され得る。クラスタ内管理に関して、ＥＣＭＦ１３５が、ＣＨまたはＢＳ等のクラスタ協調役割を伴うノード上に実装され得る。例では、図１２を参照すると、ＥＣＭＦ１４２およびＥＣＭＦ１４４は、ＣＨ役割を伴うノード内に常駐し、クラスタ内管理を提供し得る。ＥＣＭＦ１４２およびＥＣＭＦ１４４は、例えば、時間Ｔ１において（図１１に関して議論されるように）、ゾーン１４０内のクラスタ１５２およびクラスタ１５３によって使用される従来のクラスタ化アルゴリズムが、１つ以上の最適化目標（例えば、全体として、閾値通信遅延、閾値メモリ使用量、閾値処理性能メトリック等を考慮するときのデバイスのクラスタによる閾値エネルギー支出）に照らして、性能を最適化するために再構成されるように、それぞれのクラスタ１５２およびクラスタ１５３についての関連情報を維持することを任される。この機能性をイネーブルにする方法についてのさらなる詳細は、以下に挙げられる。ＥＣＭＦ機能性は、通常、計算機能レベル（例えば、要求されるエネルギー、通信、メモリ、または処理において）の増加をサポートすることができる、ノード上に実装される。

クラスタ間管理を提供するために、ＥＣＭＦは、ＢＳノード（例えば、ＢＳ１３４）上のＳＬに常駐し得る、またはクラスタ外の別個のノード（図示せず）上に常駐し得、クラスタ間管理機能性は、独立型機能またはクラスタ内管理機能性の拡張として実装され得る。説明を容易にするために、以下のＥＣＭＦの参照は、展開によって要求される具体的レベルの機能性を有すると仮定される。図１２を継続して参照すると、それぞれ、ＢＳ１３４およびＢＳ１３７上に常駐するＥＣＭＦ１３５およびＥＣＭＦ１３８は、それらがそれぞれ協調させるクラスタについての関連情報を維持することを任され得る。ＣＰＲ１３３は、集中化され、ＩＮ１３３内に位置することが検討され得るが、示されるように、ＢＳ１３４およびＢＳ１３７は、ローカルＣＰＲ（例えば、ＣＰＲ１３６およびＣＰＲ１３９）と、ローカル関連プロファイルとを含み得る。いくつかのメトリックおよびトポロジ更新が、ＣＰＲ１３３（中央ＣＰＲ）に、周期的に、例えば、スナップショット、平均等として送信され得る。例では、ＩＮ１３１内のＥＣＭＦ１３２は、時間Ｔ２後（図１１に関連して議論されるように）は、センサスケジューリングが改変され得る（例えば、冗長センサからの報告は、交互にスケジュールされる）ように、ゾーン１４０およびゾーン１４６から得られる冗長測定を検出し得る。

本明細書により詳細に議論されるように、ＣＰＲ（例えば、ＣＰＲ１３３、ＣＰＲ１３６等）は、クラスタプロファイルおよび他のサービスとリソースの関連付けられたマッピングを管理する、論理機能である。実装に応じて、サービスプロバイダ（ＳＰ）のネットワークは、例えば、１つ以上のＣＰＲをそのドメイン内で使用し得る、ＣＰＲは、ＳＰ間で共有され得る、またはＣＰＲ機能性は、ノード間で分散化される、もしくは他の論理機能と統合され得る。例えば、ＣＨ１４１は、ＥＣＭＦ１４２がクラスタ内管理のみを提供する、ノードであり得る。ＣＰＲ１３６は、ＥＣＭＦ１３５によってアクセス可能なＢＳ１３４にローカルであり得、協調されたクラスタ１４０のプロファイルのみを含むように実装され得る。異なる実装では、ＣＰＲ１３６の一部のみが、ＥＣＭＦ１３５にローカルであり、残りは、異なるエンティティ（例えば、ＩＮ１３１）上に位置し、必要に応じて、ＥＣＭＦ１３５によってアクセスされ得る。

図１４は、ＥＣＭＦおよびＣＰＲならびに他のＳＬ（例えば、イネーブリングサービス）間の例示的論理相互作用を図示する。イネーブリングサービス（ＥＳ）は、ＳＬにアクセス可能であり、プラットフォーム内の任意の場所に位置し得る。本開示のために、用語「イネーブリングサービス」（ＥＳ）は、ＳＬ内のクラスタ化拡張のために活用され得る、デバイス管理等の場所、セマンティクス、分析、または機能性等のサービスのための用語である。

表４は、ＣＰＲ（例えば、ＣＰＲ１３３）によって提供され得、クラスタプロファイル内で考慮され得る、例示的情報を図示する。ＣＰＲ１３３は、とりわけ、以下の一般的カテゴリ（例えば、表５）すなわち、説明、ポリシ、強化、トポロジ、およびメトリックにおける情報を提供し得る。本明細書に提供される例におけるパラメータのうちのいくつかは、単一エントリではなく、全体的リスト、データベース、または外部リソースへのリンクを反映する。全体的リスト（いくつかのパラメータのリスト）の例は、トポロジを表すために、順序付けられたリストのリストであり得る（サブリストを含む）。各サブリストは、クラスタ内にノードを含み得、第１のエントリは、ＣＨである。外部リソースへのリンクの例は、各エントリが、場所、セマンティクス等についての情報を含む、１つを上回るサーバへのリンクである場合であり得る。パラメータおよびプロファイルサブタイプのカテゴリは、説明を容易にするために分離されており、カテゴリ化は、必須ではない。パラメータの使用は、実装選択肢に基づき得る。各カテゴリについての追加の詳細は、以下に見出される。

説明カテゴリに関して、概して、クラスタを定義および識別するパラメータを含む。構成を除き、大部分の説明パラメータは、クラスタ化プロセスの初期段階で利用可能である、または設定され、ＣＰＲ１３３との登録時に利用可能であるべきである。いくつかは、再構成（所有者、名称等）のために利用可能であり得るが、大部分は、むしろ静的である傾向にある。このカテゴリは、ノードによってもたらされるセキュリティパラメータ（例えば、アクセス制御リスト−ＡＣＬ）またはサービスを含み得るが、それらは、ポリシカテゴリ内で考慮され得る。クラスタプロファイルは、通常、センサネットワークを維持または最適化する際の利害関係者である、ユーザによって構成される。パラメータは、クラスタの寿命全体を通して構成および再構成され得るが、むしろ静的である傾向にある。表５は、クラスタ説明カテゴリに関する例示的パラメータを提供する。

ポリシカテゴリに関して、クラスタが使用または構成されるべき方法を説明し得る、パラメータを含む。表６は、ポリシカテゴリに関する例示的パラメータを提供する。クラスタ化アルゴリズムの選択肢を説明または決定する重要なパラメータの多くは、アルゴリズム選択（例えば、モビリティ、データレート、および制約）において考慮されるべきクラスタ化アルゴリズム最適化目標またはノード特性等、このカテゴリ内に含まれる。これらのパラメータは、ユーザによって構成され得る。パラメータは、クラスタの寿命全体を通して構成および再構成され得るが、通常、他のパラメータ（例えば、トポロジ）ほど動的ではない。本明細書において他のカテゴリに関して適用可能であるように、ポリシは、とりわけ、類似ＷＳＮ、日時、およびセンサのタイプ等の履歴情報に基づいて、自動的に設定され得る。

アルゴリズム選択の目的のために、ＣＨの役割が割り当てられる方法は、固定ＣＨ役割、ＣＨのリスト内の設定された交替、ＣＨのランダム選択等の具体的カテゴリに限定され得る。例えば、図１２におけるＣＨの一部または全部は、バッテリ給電されるのではなく、プラグに差し込まれるノードであり得る。したがって、クラスタ構成では、それらは、サポートする通信の電力および量が問題となり得ないので、ＣＨノードとして固定されるように割り当てられる。したがって、電力は、より一般的には（例えば、残りのバッテリ寿命または推定されるバッテリ寿命）は、ＣＨを選定する際の要因となり得る。ＣＨ役割は、通信負担を拡散させるために、ランダムに割り当てられ得る（最小基準が満たされる場合）。図１２では、ランダム選択を使用する、ＬＥＡＣＨが使用される場合、最小基準を満たす任意のノードが、ＣＨとなり得る。

エネルギー効率のレベル、ネットワーク寿命、残留エネルギー等の最適化目標（例えば、パラメータａｖａｉｌａｂｌｅＯｐｔｉｍｉｚａｔｉｏｎＧｏａｌｓ）が、規定され得る。これらのパラメータは、クラスタを定義する他のパラメータと共に使用され得る。例えば、性能を測定するために使用され、これは、ひいては、ＣＨを選択する、またはアルゴリズムを選択するために使用される。ＣＨを選択するために使用される手段（アルゴリズム内で）は、アルゴリズムを選択するための手段と異なり得ることに留意されたい。例えば、ＣＨは、単に、閾値残留エネルギーに到達すると、最高残留エネルギーを伴うノードに移行し得る。アルゴリズムは、ネットワーク寿命が最適化されておらず、あまりに多くのノードがあまりに急激に無効になるときに変化し得る。クラスタを定義する他のパラメータ、すなわち、（サブ）クラスタあたりのノードの数、最大メッセージ遅延等のパラメータさえ、場所等の「強化」カテゴリを形成する。例えば、あるポリシ（最適化目標を含む）は、クラスタの場所に依存し得る。

ポリシカテゴリのパラメータは、ＳＬ拡張クラスタ管理のイネーブル化を可能にし、ＥＣＭＦによってローカルに、または中央もしくは分散化されたＣＰＲ内に記憶され得る。パラメータの例は、以下に続く。エネルギー効率は、メッセージあたりの最大エネルギー、時間単位あたりのノードあたりで消費される最大エネルギー、時間単位あたりのクラスタあたりで消費される最大エネルギー等、いくつかの方法において閾値によって定義され得る。ネットワーク寿命は、第１のノードが無効になるまでの最短時間、ある数のノードが近隣を全く伴わずに隔離された状態になるまでの最短時間等によって定義され得る。残留エネルギーは、ノードがクラスタヘッドであるための最小残留エネルギー、ＣＨの最小／最大数、遅延等、同時に使用されるべきある数の組をもたらすものとして定義され得る。別の側面では、残留エネルギーは、再構成をトリガするためのノードあたりの最小残留エネルギーの単一閾値または再構成をトリガするための全ノード内の最小残留エネルギーの単一閾値であり得る。

強化カテゴリを参照すると、クラスタに関連付けられた情報を強化する、パラメータを含み、ローカルで記憶され得る、またはＥＳ（例えば、場所、セマンティクス、または分析サーバ）として外部から提供され得る。表７は、強化カテゴリに関して例示的パラメータを提供する。関連付けられたＥＳへのリンク（例えば、リソースへのＵＲＩまたは他の参照）が、クラスタプロファイルの構成の一部として提供され得る。強化カテゴリのパラメータは、直接ＥＳによって、クラスタの寿命全体を通して更新され得る。これらのパラメータは、ユーザによって構成され得る。強化関連付けパラメータは、クラスタの寿命全体を通して構成および再構成され得るが、他のプロファイルパラメータ（例えば、トポロジプロファイルパラメータ）ほど動的ではない傾向にある。

トポロジカテゴリを参照すると、クラスタの階層構造を記述するために使用され得、通常、選定されるクラスタ化アルゴリズムによって影響され得る、パラメータを含む。表８は、トポロジカテゴリに関する例示的パラメータを提供する。種々のレベルの詳細が、クラスタトポロジを記述することにおいて採用され得る。例えば、ＣＨによるノードのグラフ表現もしくはリストが、与えられ得る、またはトポロジは、全エンドノードを含む、もしくはＣＨレベルにおいてのみ記述され得る。場所情報が、利用可能である、もしくは関連し得る、またはしない場合もある、もしくは代わりに、ＥＳ上に位置し得る。

トポロジ関連パラメータ（例えば、ｃｌｕｓｔｅｒＮｏｆＭｅｍｂｅｒｓ、ｃｕｒｒｅｎｔＣｌｕｓｔｅｒｉｎｇＡｌｇｏｒｉｔｈｍ）が、最初に、ユーザによって構成され得る。しかしながら、これらのパラメータは、ＥＣＭＦ（例えば、ＥＣＭＦ１４２）における最適化論理の結果として更新されることが予期される。例えば、新しい従来のクラスタ化アルゴリズム（例えば、ＬＥＡＣＨの代わりに、ＡＰＴＥＥＮ）の選択に応じて、ｃｕｒｒｅｎｔＣｌｕｓｔｅｒｉｎｇＡｌｇｏｒｉｔｈｍが、ｃｕｒｒｅｎｔＯｐｔｉｍｉｚａｔｉｏｎＧｏａｌ，ｃａｎｄｉｄａｔｅＡｌｇｏｒｉｔｈｍＬｉｓｔおよびａｌｇｏｒｉｔｈｍＲａｎｋｉｎｇＬｉｓｔとともに変更を反映するために更新される。再プログラミングによるクラスタ再構成後、トポロジのノードは、変化する可能性が高く、したがって、ＥＣＭＦ１４２は、ｓｕｂＣｌｕｓｔｅｒＬｉｓｔ、ｐａｒｅｎｔＣｌｕｓｔｅｒＩＤ等を更新し、新しい構成およびトポロジに対応し得る。トポロジ関連パラメータは、より下位またはより上位の層において定義または使用され得る属性に基づく。例えば、本明細書に議論されるように、トポロジ関連パラメータは、ＳＬレベルであり得、これは、ＳＬ拡張クラスタ化機能性をイネーブルにすることができる。

メトリックカテゴリ内のパラメータを参照すると、クラスタ、ＥＳから得られる、またはクラスタ化アルゴリズムの起動の間に導出される、パラメータを含む。表９は、メトリックカテゴリ内の例示的パラメータを提供する。メトリックパラメータは、通常、アルゴリズムの効率または必要とされる任意の最適化を決定する際の決定論理のために使用される。メトリックパラメータは、クラスタノードからの、またはそれについての情報を反映する、動的パラメータと考えられ得る。メトリックパラメータは、ＥＣＭＦによって採用される最適化のための未加工データを提供する。これらのパラメータは、クラスタステータスの全体像を把握するために、ＥＳによって提供される外部のものとともに、この論理内で使用され得る。

クラスタプロファイル（例えば、表４−ＩＤ１行）は、展開使用例シナリオに基づいて、本明細書に説明されるパラメータ（例えば、表４から表９）の全部または一部を含み得る。パラメータの異なるカテゴリの使用における変動を前提として、プロファイルの一部は、ＳＬを横断して異なるエンティティ内に記憶され得る。

例では、クラスタ（例えば、クラスタ１５２）のプロファイルのトポロジおよびメトリックパラメータは、特に、情報の大部分がセンサノードから収集され得るとき、ＣＨ１４１内のＥＣＭＦ１４２と共存し得る。動的ではない場合がある、ポリシおよび強化に関連付けられたパラメータは、特に、クラスタ間協調のために、ＢＳ１３４またはＩＮ１３１内に常駐し得る。分散化された場合では、情報の相関が、一意のｃｌｕｓｔｅｒＩＤおよびｃｌｕｓｔｅｒＮａｍｅ等のパラメータ、プロファイル内のパラメータへのリンクを介して、エンティティを横断して行われることができる。

ＣＰＲ１３３は、単一または複数のクラスタプロファイルを作成または記憶し得る。ＣＰＲ１３３は、プロファイルまたはプロファイルの一部をノードを横断して分散させ得る。ＣＰＲ１３３およびＥＣＭＦ１３２の機能は、１つのデバイスの中に統合される、または１つを上回るデバイス間に分散され得る。初期登録の間に提供される情報は、説明およびトポロジに関連付けられたパラメータを含み得る。表１０は、クラスタプロファイルに関する１つ以上の登録メッセージ内に含まれ得る、例示的パラメータを提供する。表１０に説明される全パラメータが、ＣＨ（例えば、ＣＨ１４１）もしくはクラスタに関連付けられた他のノードによって提供されなくてもよい、またはＣＨは、追加のプロファイルパラメータ（例えば、初期構成において提供される場合、デバイス管理（ＤＭ）サーバへのリンク）を提供し得る。ＣＰＲによってサポートされるプロファイルパラメータは、クラスタプロファイルのための登録メッセージ内に含まれ得る。

クラスタレベル（例えば、クラスタ１５２等の複数のノードを伴うクラスタ）では、登録情報は、とりわけ、所有権、メンバシップ情報（ノード）、関連付けられたセマンティクス、分析または場所サーバ、アルゴリズム目標、閾値、およびパラメータを含む、管理情報、トポロジ、モビリティ特性、ならびにＣＨおよびＢＳ特性等の情報を含み得る。各クラスタ内のノードレベル（例えば、ノード１４５）では、登録情報は、とりわけ、個々の能力、提供されるサービスのリスト、および場所を含み得る。クラスタまたはノードあたりの考慮点では、登録は、小サブセットの可能なパラメータのみを含み得、これは、クラスタの初期記述のみを作成し、後に、クラスタの寿命にわたって強化される、またはクラスタの発端から非常に詳述され得る。ノードおよびクラスタあたりは、情報のタイプに関するコンテキストを提供するためだけに区別される。メンバシップ情報は、クラスタに関して有効である一方、他のものは、ノードあたりベースで有効にされ得る。これは、与えられる情報のタイプを構造化する方法である。加えて、登録に関して、登録は、非常に基本的であり得る。例えば、登録はノードＡ−Ｚから成るクラスタｉｄのみであり得、他の情報は、殆ど把握されない。したがって、デバイス管理コマンドを介して、例えば、ノードの実体についての情報は、後で追加され得る。必要とされるパラメータに依存する他の方法も存在する。

図１５−図１９に図示されるステップを行うエンティティは、図２９Ｃまたは図２９Ｄに図示されるもの等のデバイス、サーバ、またはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る、論理的エンティティであることを理解されたい。すなわち、図１５−図１９に図示される方法は、図２９Ｃまたは図２９Ｄに図示されるデバイスまたはコンピュータシステム等のコンピューティングデバイスのメモリ内に記憶される、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、コンピュータシステムのプロセッサによって実行されると、図１５−図１９に図示されるステップを行う。ある例では、Ｍ２Ｍデバイスの相互作用に関して以下にさらなる詳細を伴うが、図１２および図１５のＥＣＭＦ１４２は、図２９ＡのＭ２Ｍ端末デバイス１８上に常駐し得る一方、図１２および図１５のＣＰＲ１３３およびＥＣＭＦ１３２は、図２９ＡのＭ２Ｍゲートウェイデバイス１４上に常駐し得る。

図１５は、クラスタプロファイル登録のための例示的メッセージフローを図示する。ステップ１６１では、デバイス１６０は、ＥＣＭＦ１４２と初期通信を行う。初期通信は、とりわけ、ＤＭまたはブートストラップを介した構成であり得る。ステップ１６２では、ＥＣＭＦ１４２は、登録のためにメッセージをＣＰＲ１３６に送信する。ステップ１６２のメッセージは、表１０の情報を含み得る。プロファイル登録メッセージ（ステップ１６２）は、ＥＣＭＦ１４２から生じ得るが、全てのこれらのパラメータが、ＥＣＭＦによって提供されない、または把握されなくてもよい。これは、構成設定に依存し、これは、ＳＰによって行われ得る。例えば、より多いまたはより少ないパラメータが、最初の登録の際に提供され得る。ステップ１６３では、ＥＣＭＦ１４２が、ステップ１６２のメッセージからの情報（例えば、表４から表１０の１つまたは複数のパラメータ）に基づいて、応答確認登録を受信する。ステップ１６４では、ＥＣＭＦ１４２が、クラスタを更新するためのメッセージを受信する。更新は、本明細書で議論されるカテゴリ（例えば、説明、トポロジ等）のいずれかからのパラメータであり得る。例では、ステップ１６４において、新しいＡＣＬが、ＥＣＭＦ１４２によって受信される。ステップ１６５では、ＥＣＭＦ１４２が、ステップ１６４のクラスタ更新命令（新しいＡＣＬを含み得る）をＣＰＲ１３６に送信し得る。ステップ１６６では、ＥＣＭＦ１４２が、メッセージをＣＰＲ１３６から受信し得、メッセージは、情報の受信またはステップ１６５の命令の実装の確認を含み得る。図１５および図１２を参照すると、ＥＣＭＦ１４２が、ＢＳ１３４と通信し、ＣＰＲ１３６に登録し得、ＥＣＭＦ１４２を含むクラスタ１５２のプロファイルが、構築および記憶される。図１５はまた、初期登録（例えば、ステップ１６４においてアクセス制御リスト（ＡＣＬ）を提供する）後、クラスタの初期登録に含まれなかったプロファイル更新を導入する相互作用を図示する。

図１６は、ＣＰＲにクエリするための例示的メッセージフローを図示する。ステップ１７１では、ＥＣＭＦ１４２が、利用可能なＣＰＲ機能性のためのクエリを送信し得る。ステップ１７２では、ＥＣＭＦ１４２が、応答をＣＰＲ１３６から受信し得る。示されるように、ＣＰＲ１３６は、ステップ１７１への応答として、様々な実装およびレジストリ機能性をイネーブルにし得る、利用可能なパラメータおよび機能能力のリストを提供し得る。例えば、ステップ１７１におけるような外部要求が、ＣＰＲ１３６が発見される度に使用され得、プロファイルパラメータのクエリが行われる前に行われ得る。クラスタプロファイル内に含まれる全てのパラメータは、関連付けられた機能性とともに含まれ得る。例えば、ＣＰＲ１３６からのステップ１７２における応答は、ＣＰＲ１３６がノード能力あたりの場所記憶を有するかどうか、または分析データベースへの直接インターフェースを提供するかどうかを示し得る。例では、ＳＬは、ステップ１７２のメッセージをアナウンスメントとして提供され得、これは、必ずしも、クエリに応答しない。リソースアナウンスメントは、リソース発見を促進することができ、（この場合）ＣＰＲ１３６によって開始されるプロセスである。ステップ１７２におけるメッセージは、ステップ１７１への応答であり得るが、ＣＰＲ１３６によって周期的にブロードキャストされる、または他の方法で提供され得る。以下は、パラメータおよび機能能力についての簡単な議論である。図１６のこの場合、ＳＬは、ＣＰＲにおいて利用可能な能力を把握することを所望する。データベースが存在するので、これの大部分がデータベース内でサポートされるパラメータに示されるのは尤もである（登録のためだけではなく）。例えば、パラメータは、本ＣＰＲがポリシについて、またはメトリックついてのみの情報を保持するかどうかを示す。しかし、あるＣＰＲが、場所に関するフィールド／パラメータを有していないが、ローカルで記憶されていないものの、場所サーバに進み、必要に応じて、それに関して尋ねる能力を有し得るので、機能能力は、パラメータ以上である場合がある。

図１７は、ＣＰＲからの情報のクエリのための例示的メッセージフローを図示する。特定のクラスタ（例えば、クラスタ１５３）に関連付けられた情報に関するクエリは、ＥＣＭＦ１４２によって使用され得る、または他のＳＬエンティティによって行われ得る。ステップ１７４では、ＥＣＭＦ１４２が、特定のクラスタ情報をＣＰＲ１３６から読み出すことを要求し得る。例えば、クラスタ情報は、サービスの場所およびタイプを含み得る。ステップ１７５では、ＥＣＭＦ１４２が、ＣＰＲ１３６からであることを示す応答を受信し得る。応答は、要求される情報を含み得る。図１７の方法は、クラスタに関連付けられた情報を追加、修正、または削除する要求をサービシングすることを可能にする。

図１８は、ＥＳとの相互作用のための例示的メッセージフローを図示する。ステップ１７８では、ＥＣＭＦ１４２が、要求を場所サーバ１７７（例えば、イネーブリングサービス）に送信する。ステップ１７８の要求は、クラスタ内のノード（例えば、クラスタ１５３内のノード１５０）に関する場所を読み出すことであり得る。ステップ１７９では、ＥＣＭＦ１４２が、場所サーバ１７７からであることを示す応答を受信し得る。ステップ１７９の応答は、ステップ１７８において要求される場所（例えば、ＧＰＳに基づくＣＨの地理的場所）を含み得る。図１８は、ＳＬ実装によってサポートされる機能性（例えば、サブスクリプション、通知、クエリ等）を使用して、拡張サービスを提供するためのＥＣＭＦ１４２の例である。ＥＣＭＦ１４２は、通知を提供する、または他のＳＬエンティティからのクエリに応答するように構成され得る。

図１１および図１２ならびに付随の議論を参照すると、時間Ｔ２後に最適化を提供するために、ＥＣＭＦ１４２は、地理的エリアにおける各ゾーン（例えば、ゾーン１４０およびゾーン１４６）内のセンサによって監視される大気圧を得てもよい。利用可能なＥＳは、本明細書に詳述されるように、クラスタ強化（例えば、表７）に関連付けられたパラメータに規定され得、これに対処するプロシージャの例は、図２１を参照して与えられる。より大きいプロシージャ内では、ＥＳ（この例では、場所サーバ１７７）との相互作用が、図１８に表される。

図１９は、関連付けられたＣＰＲ相互作用を示す、ＳＬとの例示的ＥＣＭＦ相互作用を図示する。図１９および付随の議論は、他のＳＬエンティティとの相互作用におけるＣＰＲの役割を抽象化することを理解されたい。ＥＣＭＦ１４２が、ＡＰＩを介して、インターフェースをＳＬエンティティ（例えば、ＥＳ）またはユーザのデバイスに提供するとき、関連付けられたＣＰＲ相互作用が、続いて起こり得、場所情報の読み出しの後に、関連付けられたプロファイル（例えば、クラスタプロファイルの全部または一部）の更新が続くことが珍しくないであろう。

図１９を継続して参照すると、ステップ１８５では、ＥＣＭＦ１４２が、通知をＳＬエンティティ１５１から受信し得る。ステップ１８５の通知は、表１０において議論されるようなｐｅｒｉｏｄｉｃＥｖａｌｕａｔｉｏｎＰａｒａｍｓを含み得る。ステップ１８６では、ＥＣＭＦ１４２が、ＣＰＲ１３６を更新するためのメッセージを提供する。ステップ１８６のメッセージは、ステップ１８５において受信されたｐｅｒｉｏｄｉｃＥｖａｌｕａｔｉｏｎＰａｒａｍｓを含み得る。ＣＰＲ１３６は、次いで、後の使用のために、そのプロファイルを更新し得る。ステップ１８７では、更新の確認が、ＥＣＭＦ１４２に送信される。ステップ１８８では、応答は、ＣＰＲ１３６の更新を確認する。

図１９を継続して参照すると、表現を容易にするために、ＣＰＲ１３６とのいくつかの相互作用は、表されておらず、ＥＣＭＦ１４２は、単なる情報の消費者または提供者として示され得る。とりわけ、ＥＣＭＦ、ＣＰＲ、およびＳＬエンティティは、図に図示されないが、相互作用に関わり得ることを理解されたい。図１９は、他の図および付随の議論に照らして、図１５におけるクラスタ更新（例えば、ステップ１６５）または図１７における読み出し（例えば、クエリのためのステップ１７４）等の動作が、実際には、異なるＳＬエンティティからの別の動作の結果であり得ることを伝える。

ユーザのデバイスとの相互作用は、ＳＬ内の特別なＡＰＩを通して提供され得、本明細書に詳述されるように、クラスタのプロファイルの部分的もしくは完全更新またはクラスタ再構成のトリガをもたらし得る。マルチユーザアクセスは、ＳＬ内で仲裁され得ると仮定される。クラスタプロファイル更新は、ＥＣＭＦ１４２によって、ＡＰＩを通してユーザのデバイス（例えば、図２９ＣのＭ２Ｍデバイス３０）に利用可能になり得る。また、クラスタプロファイルの更新は、プロファイル登録、更新およびクエリ、ならびにＣＰＲ機能性クエリのための本明細書（例えば、図１５−図１９）に説明されるＣＰＲ方法と同一またはその延長であり得る。クラスタプロファイルを更新する方法は、内部ＥＣＭＦ１４２処理をトリガし得、また、ＣＰＲ１３６に転送され得る。ＥＣＭＦ１４２は、クラスタ１５２（例えば、管理されるクラスタ）内の各個々のノードを再構成し得る。各ノードを再構成するために使用される方法は、本明細書（例えば、表６）に議論されるように、ポリシカテゴリ内のパラメータの考慮点を用いて、ユーザのデバイスによって規定され得る。

要するに、１つ以上のＥＣＭＦは、より下位の層における従来のクラスタ化アルゴリズムの使用を用いて、クラスタ（例えば、ゾーン１４０）またはサブクラスタ（ゾーン１４０のクラスタ１５２）を管理することに役立ち得る。例では、ＥＣＭＦ１４２は、ＣＰＲ１３６において利用可能なクラスタプロファイル、他のＳＬエンティティ（例えば、ＳＬ１５１）との相互作用、ならびにＣＨ１４１において利用可能であり、使用される従来のクラスタ化アルゴリズムから導出される任意の情報を使用し得る。

図２０は、とりわけ、図１１から図１３のシステムを参照して、例示的クラスタ内管理プロシージャを図示する。ステップ２０１では、ＢＳ１３４におけるＥＣＭＦ１３５が、利用可能な機能性およびパラメータに関して関連付けられたＣＰＲ１３６にクエリする。例えば、図１６のステップ１７１．ステップ２０２では、ＥＣＭＦ１３５が、そのクラスタ（例えば、ゾーン１４０）に関するクラスタプロファイルを作成する。説明、ポリシ、および強化パラメータが、事前プロビジョニングを介して、またはユーザ（例えば、デバイス１６０またはＭ２Ｍデバイス１８）とのＳＬ相互作用を介して、構成され得る。クラスタプロファイルの作成または更新は、新しいデバイス１６０を対応するプロファイルパラメータに登録することに関連付けられた情報を含み得る。例えば、図１５のステップ１６１。ステップ２０３では、ステップ２０２のクラスタプロファイルが、ＣＰＲ１３６に登録され、ＥＣＭＦ１３５が設定段階を開始する。例えば、図１５のステップ１６２およびステップ１６３。

設定段階の一部と考えられ得る、ステップ２０４では、ＥＣＭＦ１３５が、強化プロファイルに基づいて、ＳＬエンティティ１５１と相互作用する。強化プロファイルは、１つ以上の強化パラメータ（例えば、表７）のコンパイル化と考えられ得る。ＥＣＭＦ１３５は、例えば、場所更新通知を構成し、関連メトリックプロファイルを更新し得る（例えば、１つ以上のメトリックパラメータのコンパイル化−表９参照）。ＥＣＭＦ１３５は、トポロジ等のローカルで利用可能な情報に基づいて、クラスタ（例えば、ゾーン１４０）のプロファイルの一部または全部の更新を設定し得る。ＥＣＭＦ１３５はまた、カスタム分析を設定し、追加のメトリックパラメータをＳＬ１５１情報から抽出し得る（例えば、着信クエリに基づく重大な情報配信遅延に関する測定）。また、ＥＣＭＦ１３５は、クラスタ候補アルゴリズムリスト（表８参照）を構成し、関連付けられたパラメータの収集ならびに行われるべき分析を構成し得る。例えば、図１８のステップ１７８およびステップ１７９。ステップ２０５では、設定段階は、査定トリガ閾値内に設定された具体的基準が満たされるときに終了し得る（例えば、ゾーン１４０のクラスタプロファイル内の重要なパラメータのリストが構成される等）。例では、初期設定後、ＥＳ通知が構成されるとすぐに、設定は、終了され得る。後に、再構成後、タイマのみが設定され得る。

ステップ２０６では、査定段階（ステップ２０６−２０７）が開始する。査定段階は、情報がトポロジおよびメトリックプロファイル内に蓄積され、情報がＥＣＭＦ１３５によって処理される、ＥＣＭＦフローの比較的に長寿命段階と考えられ得る。長寿命段階は、数秒を上回る（例えば、通常、ＩＰルーティング変更より長い）と考えられ得、数時間、数日、数週間、数ヶ月等の情報蓄積および査定であり得る。本蓄積された情報は、従来のクラスタ化アルゴリズム（例えば、ＬＥＡＣＨ）の反復全体を通して得られ、適宜、更新される。クラスタ機能に関連するＳＬ１５１からのＳＬ情報は、ＳＬ１５１またはＥＣＭＦ１３５による周期的クエリからのＳＬ通知に基づいて、ＣＰＲ１３６において更新され得る。ステップ２０７では、この時間の間、ＥＣＭＦ１３５は、タイマ、ＳＬ通知等の評価のための潜在的トリガを常に処理し得る。

ステップ２０８では、ポリシプロファイルが、ＥＣＭＦ１３５によって、新しい動作要件およびトリガに基づいて更新され得る。例では、最適化メトリックおよび関連閾値が、更新されている。評価段階のためのトリガが、ポリシ更新を伴わずに規則的ベースで、またはＣＰＲ１３６の他のタイプの更新に基づいて生じるように設定され得る。デバイス１６０からの情報は、ステップ２０４において設定段階の間に作成された構成が更新される必要がある場合、例えば、分析またはセマンティクスに基づく通知が再構成される必要があるとき、設定段階（ステップ２０４）へのジャンプ等の他の遷移をもたらし得る。ステップ２０９では、入力も、ＥＣＭＦ評価の使用を伴わずにクラスタのための新しい構成を決定するために十分な情報が存在する場合、直接、再構成段階への遷移をもたらし得る（ステップ２１５）。この場合、Ｔ１更新において、正に従来のクラスタ化アルゴリズムが使用されるべきこと（例えば、ＡＰＴＥＥＮ）等を規定し得る。

評価段階（ステップ２１０−２１４）を開始する、ステップ２１０では、ＥＣＭＦ１３５が、利用可能な情報を処理し、最適化目的が達成されたかどうかを決定する。例えば、重大な情報に関する配信遅延閾値が、ＬＥＡＣＨを使用する準最適機能性に関するアラートをトリガする配信遅延の蓄積されたメトリックと比較される。ステップ２１１では、最適化目的が満たされた場合、プロファイルへの任意の更新が必要とされるかどうかチェックされ得る（例えば、評価がユーザ／ＳＰ更新によってトリガされる場合、計算された値も同様に更新する必要があり得る）、そうでなければ、査定段階が再開される。

ステップ２１３では、目的が満たされていない場合、現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の比較が、行われる。評価を行う際、ＥＣＭＦ１３５は、最適化メトリックによって提供され、最適化目的を満たす際に従来のクラスタ化アルゴリズム性能に結び付けられるもの以外の情報または論理を使用し得る。例えば、ＥＣＭＦ１３５は、モデル化の正確度に基づいて、候補置換アルゴリズムの仮定される性能を計測し得る。別の計測が、導入され、利用可能な再構成方法に応じて、ノードの再構成のコスト（例えば、エネルギー、動作ダウンタイム等）を考慮し得る。ステップ２１４では、（例えば）評価がクラスタ機能が準最適であり、より優れた構成が見出されたと結論付けたと仮定して、再構成段階がトリガされる。そうでなければ、任意の必要プロファイル更新を行った後、査定段階が再開される。

ステップ２１５では、再構成段階（２１５−２１６）が、開始し、ＥＣＭＦ１３５が、利用可能なノード再構成方法（ポリシプロファイル内のａｖａｉｌａｂｌｂｅＲｅｃｏｎｆｉｇＯｐｔｉｏｎｓ参照）を使用し、クラスタ内のノードにおいて使用される従来のクラスタ化アルゴリズムを更新する。ステップ２１６では、この段階は、クラスタ内のノードが再構成されると完了し、クラスタは、新しく選択された従来のクラスタ化アルゴリズムに基づいて動作する。この段階は、例えば、ＥＣＭＦ１３５がやがて起こるＤＭ動作を認知すると（強化プロファイル内で規定された関連付けられたＤＭイネーブリングサービスから）、再構成／再プログラミングとそれを同期させ得る、計算された遅延を含み得る。ステップ２１２では、再構成応答に基づいて、ＥＣＭＦ１３５が、関連付けられたＣＰＲ１３６においてクラスタプロファイルを更新し、そのように構成される場合、クラスタ化変更のＳＬ通知を送信し、次いで、ＥＣＭＦ１３５は、新しい設定段階を開始し得る。例では、新しい設定段階の再構成のトリガは、タイマのみに基づき得るが、ａｓｓｅｓｍｅｎｔＴｒｉｇｇｅｒＴｈｒｅｓｈｏｌｄｓに基づく他のタイプのトリガが、適用され得る。設定段階の終了は、新しい査定段階をトリガし、プロセスは、ステップ２０４から継続する。

図２０のフローおよびプロシージャステップは、図１２に関して説明される使用例のＥＣＭＦ機能性の１つの使用を図示する。クラスタ内ＥＣＭＦによってイネーブルにされた機能性の追加の例は、以下に議論される。第１の例では、所与または新しい最適化目標に基づく、従来のクラスタ化アルゴリズムパラメータ（例えば、タイマ、閾値）の適合が存在し得る。多くの従来のクラスタ化アルゴリズム（例えば、ＡＰＴＥＥＮ）は、アルゴリズム内で固定される、タイマおよび閾値等のパラメータに依拠するが、実装に応じて、再構成可能であり得、例えば、これらのパラメータのためにダウンロードされる小規模テーブルが、ファームウェア変更の代わりに可能性として考えられ得る。この情報は、ａｖａｉｌａｂｌｂｅＲｅｃｏｎｆｉｇＯｐｔｉｏｎｓ設定を介して提供され、再構成ステップが行われる方法における代替を提供し得る。

第２の例では、新しいまたは別個のクラスタ化最適化目標を導入する方法が、クラスタ化ポリシおよびメトリックを使用して、従来のクラスタ化アルゴリズムのために提供され得る。以前に議論されたものは、クラスタ化アルゴリズムをＬＥＡＣＨからＡＰＴＥＥＮに修正するための重大な情報に関する配信遅延閾値を含む、単純エネルギー消費最小限化からの最適化目標（ａｖａｉｌａｂｌｅＯｐｔｉｍｉｚａｔｉｏｎＧｏａｌｓ）の変更であった。ＥＣＭＦ機能性は、同時に、ｃｌｕｓｔｅｒｉｎｇＰｏｌｉｃｙＬｉｓｔを使用して、サービス層のより大きいコンテキスト内でクラスタ化最適化目標を考慮する。ｃｌｕｓｔｅｒｉｎｇＰｏｌｉｃｙＬｉｓｔが、サービス最適化がクラスタ化最適化より高い目標であって（例えば、より高く重み付けされる）、新しい従来のクラスタ化アルゴリズムがやがてより低いサービス格付けにつながる（例えば、ユーザから）と規定するが、メトリックに基づいて、ｃｕｒｒｅｎｔＯｐｔｉｍｉｚａｔｉｏｎＧｏａｌが満たされている、または超えている、例を検討する。ＥＣＭＦ１３５は、本ポリシを使用して、そうでなければ従来のクラスタ化アルゴリズムに利用不可能なクラスタ再構成を行ってもよい。サービス最適化は、大部分のクラスタ化アルゴリズム（ＳＬより下位の層で機能する）がそれらを測定することができないという点において、クラスタ化最適化と異なり得ることを理解されたい。サービス最適化目標の別の例は、ある時間量にわたって互いに追跡する近似場所および測定に基づいて決定される、読み取りの冗長性を低減させることであり得る。これは、センサがＧＰＳを有していないので、サービス層においてのみ評価され得、この場合、場所は、ＣＨまたはＢＳ場所（より多くのエネルギーを有し、ＧＰＳをサポートし得る）のみに基づく。ネットワーク寿命のクラスタ化目標は、常時満たされ得るもよいが、ＳＬにおいてのみ検出され得る、冗長測定となり得、クラスタ化は、それに基づいて改良され得る。

第３の例では、新しいクラスタ形成を含み得る、クラスタ再構成のトリガが存在し得る。加えて、予測分析（例えば、ある期間にわたって予期されるバッテリ寿命）の使用が、ノード間通信において数回分を排除するために使用され得る。査定段階を終了するトリガは、本質的に、評価段階をスキップし、直接、再構成段階につながり得ることが以前に議論されている。本特徴は、新しい構成がすでに評価されているとき、または新しいクラスタ形成をトリガすることが望ましいときに使用され得る。本質的に、従来のクラスタ化アルゴリズム（例えば、Ｈｅｉｎｚｅｌｍａｎ）は、定常状態段階に先立って、編成の設定段階を有し、そこで、設定段階は、編成のための通信オーバーヘッドを要求する。ある場合には、ＳＬを介して利用可能なツールおよび情報（例えば、面積内の可能な干渉、非クラスタノードモビリティ、より効率的エネルギー消費モデル等）は、ＥＣＭＦ１３５が最適化された定常状態トポロジのより優れた推定を行うことを可能にし得、これは、再編成段階を短縮し得る。

第４の例では、完全分析を再度行うことなく、規則的ベースで従来のアルゴリズム変更のトリガが存在し得る（再構成またはパラメータ変更を使用して）。センサ使用は、多くの場合、情報が使用される方法においてだけではなく、また、センサおよびクラスタが位置付けられ、通信する方法においても、変化するが、周期的である傾向にあって、パターンは、昼／夜、毎週、高温時／低温時、休日等を形成し得る。ＥＣＭＦ１３５は、これらのパターンをその論理において使用して、完全分析が毎回要求されることなく（例えば、計算オーバーヘッドを伴わずに、または完全データセットがＢＳ１３４およびＣＨ１４１においてローカルで要求されることなく）、周期的従来のクラスタ化アルゴリズム変更を生じさせることが可能となり得る。

図２１は、とりわけ、図１１から図１３のシステムを参照して、例示的クラスタ間管理プロシージャを図示する。従来のクラスタ化アルゴリズムによって提供される機能性は、複数のクラスタがＥＣＭＦによって管理されるとき、共同で最適化され得る。クラスタ間管理をイネーブルにするために、ＥＣＭＦ機能性は、複数のクラスタのために利用可能なＣＰＲ１３３を用いて、複数のクラスタのためのシンクとして作用するＢＳ内に、または複数のＢＳ（ＩＮ１３１等）によってアクセスされているＳＬエンティティ内に実装され得る。

ＥＣＭＦ１３２は、ローカルクラスタ関連情報をイネーブリングサービスによって提供されるもの等のサービス層内のいずれかで利用可能な情報とともに使用する能力を有する。例では、ＣＰＲ１３３は、場所およびセマンティクスサーバへのリンクを提供し、これは、センサ間の情報冗長性を決定することにおいて使用される。

図２１を参照すると、以下の方法は、ＥＣＭＦ１３２のクラスタ間管理機能性の例である。ステップ２２０では、共通ＳＰネットワークプラットフォーム内における統合後に仮定され得る、前提条件が存在する。ＩＮ１３１における中央ＣＰＲ１３３は、管理される全クラスタに関する完全クラスタプロファイルを含み得る。関連付けられたＥＳは、セマンティクスおよび場所情報がクエリおよび通知に基づいてＣＰＲ１３３内で更新されるように構成され得る。ＥＣＭＦ１３２は、クラスタ間最適化ポリシで事前プロビジョニングされ、分析が、ローカルで、または外部サービスを通して提供される。ＣＰＲ１３３は、ＢＳ１３４および１３７のためのＣＰＲを含み得、言い換えると、図１２に示されるようなＣＰＲ１３６およびＣＰＲ１３９が存在しないこともある。初期クラスタは、ＥＣＭＦ１３５およびＥＣＭＦ１３８によって、図１５（例えば、ステップ１６２およびステップ１６３）に示されるように、メッセージングを介して登録され得る。

ステップ２２１では、取得段階が存在する。これは、クラスタ関連情報がクラスタ間最適化ＥＣＭＦ１３２機能性によって処理され、導出されるデータが蓄積される、長寿命段階であり得る。本時間の間、ＥＣＭＦ１３２は、タイマ、ＳＬ通知等の評価のための潜在的トリガを常に処理し得る。

ステップ２２２では、タイマベースの最適化トリガが存在し得る。ステップ２２３では、分析段階が存在し得る。ここでは、ＥＣＭＦ１３２は、クラスタ間最適化ポリシに対する利用可能な情報を処理する。この場合、プラットフォームによって提供され、あるセマンティクスおよび場所情報で強化される、測定のリストを処理する。これは、ステップ１８５のメッセージ等の図１９のメッセージング、タイマ等によって行われ得る。この段階は、クエリを介して、ＢＳ ＥＣＭＦから導き出される追加の入力を含み得る。

ステップ２２４では、構成の評価が存在し得る。ここでは、ＥＣＭＦ１３２が、互いに規定された距離内にあって、かつ互いに規定された正確度内にある、同一測定タイプを提供する冗長センサを考慮する、クラスタ間最適化ポリシに基づいて、構成を準最適と見なす。利用可能な情報に応じて、分析はさらに、測定が互いに追跡するものを履歴的に観察することによって、本結論を検証し得る。

ステップ２２５では、この構成の評価の間、代替プロファイルが、ＥＣＭＦ１３２が修正された構成を使用して、それを実際に提案する前に、ある時間にわたって、試験構成を実際にモデル化し、分析することによって、ＣＰＲ１３３内に構築され得る。代替プロファイルは、試験の間、修正され、例えば、非常に長いデューティサイクルを伴ってバックアップとしてのみセンサを使用するのに対して、読み取りを交互することによって、より良好な結果が達成されるかどうかを分析し得る。センサエネルギー消費、サービスユーザ格付け、またはセンサ正確度等の他の情報も、考慮され得る。

ステップ２２６では、再構成オプションが見つからない場合、分析段階は、ある時間後、停止され、取得段階が再開され、そうでなければ、再構成オプションの送信に進んでもよい。ステップ２２７では、サービスベースの再構成オプションが存在し得る。クラスタ再構成オプションメッセージが、影響を受ける全クラスタのＥＣＭＦ、例えば、ＥＣＭＦ１３２からＥＣＭＦ１３５およびＥＣＭＦ１３８に送信される。これらのメッセージは、提案される代替クラスタプロファイルを含み、本明細書（例えば、以下の表１１−１２に関連付けられた議論）で議論されるクラスタ再構成オプション方法を使用することに関わるクラスタ間最適化ポリシのタイプを示し得る。ＥＣＭＦ１３２は、ＥＣＭＦ１３５および１３８からの再構成オプションの受諾を待つ。関わる全ＢＳ ＥＣＭＦからの受諾が得られない場合、再構成は、破棄され得る。

ステップ２２８では、クラスタ再構成オプションがステップ２２７において受諾されたと仮定して、再構成が生じるための協調情報（例えば、再構成のための期間等）および予期される関連付けられた肯定応答メッセージを含む、クラスタ再構成指示メッセージが、送信される（例えば、表１１−１２に関連付けられた本明細書で議論されるクラスタ再構成オプション方法参照）。ステップ２２９では、クラスタ再構成オプションが満場一致で受諾されたと仮定して、再構成が生じるための協調情報（例えば、再構成のための期間等）および予期される関連付けられた肯定応答メッセージを含む、クラスタ再構成指示メッセージが、送信される（例えば、ＥＣＭＦ１３２によってＥＣＭＦ１３５およびＥＣＭＦ１３８に）（本明細書で議論されるクラスタ再構成オプション方法参照）。ＥＣＭＦ１３５およびＥＣＭＦ１３８が、再構成オプションを受諾し、各クラスタ上で再構成を行うことを可能にされるかどうかは、ｃｌｕｓｔｅｒＥＣＭＦｉｄ属性を介して示され得る。ステップ２３０では、関連付けられた確認がＢＳ ＥＣＭＦから受信されると、ＣＰＲ１３３は、現在の構成で更新され、再構成が完了し、そうでなければ、再構成オプションメッセージを再送信する。

以下は、可能な再構成シナリオに関する追加の議論である。クラスタ再構成オプションは、構成変更をゾーン１４０を管理するＥＣＭＦ１３５に提案するために、ＥＣＭＦ１３２のクラスタ間機能によって使用され得る。ＥＣＭＦ１３２は、構成提案の受諾または否認を示し、合意または拒否を生じさせる、対応する応答メッセージを受信し得る。否認原因が、例えば、ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎＰａｒａｍｅｔｅｒｓのみを示す場合、クラスタ間ＥＣＭＦは、同一オプションを変更されたパラメータとともに再送信することを決定し得る。前述の再構成オプションに関連付けられたメッセージは、表１１に示されるパラメータのうちの１つ以上のものを含み得る。クラスタ間管理機能は、異なるクラスタ間で使用され、そのうちの１つは、ＥＣＭＦが機能をホストすることによって管理され、例えば、ＥＣＭＦ１３２は、ＥＣＭＦ１３５およびＥＣＭＦ１３５自体を管理するクラスタを再構成することを理解されたい。この場合、ＥＣＭＦ１３２の再構成は、実質的に内部であり、また、ＥＣＭＦ１３２からＥＣＭＦ１３５に送信されるメッセージも存在するであろう。

ＥＣＭＦ１３５からの合意の受信に続いて、メッセージが、ＥＣＭＦ１３２によって、ゾーン１４０を管理するためのＥＣＭＦ１３５における構成変更をトリガするために送信され得る。前述のトリガに関連付けられたメッセージは、表１２に示されるパラメータのうちの１つ以上のものを含み得る。ＥＣＭＦ１３２によって受信される対応する応答メッセージは、クラスタ再構成がＥＣＭＦ１３５によって完了されたときを示し得る。応答メッセージは、クラスタ間機能を異なる状態に遷移させるために使用され得る。

図２１に関連付けられたプロシージャステップは、図１２に関連して本明細書に説明される使用例のためのクラスタ間ＥＣＭＦ機能性の例示的使用のみを図示する。ＥＣＭＦ１３２（または他のＥＣＭＦ）のクラスタ間機能性はまた、基地局間のクラスタ転送のためのプロシージャを最適化するために使用され得る。負荷共有目的のためにＢＳを交替させるためのアルゴリズムが、提案されており、ＳＬ特有情報を使用することによって、クラスタ間ＥＣＭＦによって拡張され得る。Ｚｈａｎｇ，Ｆ．Ｉｎｇｅｌｒｅｓｔ，Ｇ．Ｂａｒｒｅｎｅｔｘｅａ，Ｐ．Ｔｈｉｒａｎ ａｎｄ Ｍ，Ｖｅｔｔｅｒｌｉ，“Ｔｈｅ Ｂｅａｕｔｙ ｏｆ ｔｈｅ Ｃｏｍｍｏｎｓ：Ｏｐｔｉｍａｌ Ｌｏａｄ Ｓｈａｒｉｎｇ ｂｙ Ｂａｓｅ Ｓｔａｔｉｏｎ Ｈｏｐｐｉｎｇ ｉｎ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ Ｎｅｔｗｏｒｋｓ”，ＣｏＲＲ，２０１４（以降、Ｚｈａｎｇ）（参照することによってその全体として組み込まれる）を参照されたい。上で開示されるクラスタ再構成メッセージおよびクラスタプロファイルは、新しいＢＳがクラスタのために選定されるとすぐに、各ＢＳ（例えば、ＢＳ１３４およびＢＳ１３６）にクラスタのための完全プロファイル情報を提供するためにＢＳ−ホッピングプロシージャにおいて使用され得る。例えば、ＢＳ１３４がオフラインになる間、ＢＳ１３７が、ゾーン１４６の代わりに、またはそれに加え、ゾーン１４０のために選定され得る。

クラスタ管理に関して本明細書で議論される相互作用は、従来のＳＬ実装（例えば、サブスクリプション、通知、クエリ等）によってサポートされる機能性とともに使用され、追加の能力を提供し得る。本明細書（例えば、図１１から図２７）で議論されるクラスタ化管理機能性は、本明細書に導入されるＣＰＲおよびＥＣＭＦ方法と同一のものを使用して、またはその延長としてＡＰＩに利用可能であり得る。これらのＡＰＩは、ひいては、インフラストラクチャドメイン上のアプリケーションをイネーブルにし、ディスプレイ（例えば、グラフィカルユーザインターフェース）または他の入力デバイス（例えば、図２９Ｃのディスプレイ４２）を介して、ユーザ相互作用を提供し得る。図２７は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。ディスプレイインターフェース１５５（例えば、タッチスクリーンディスプレイ）は、表４から表１２のパラメータ等、クラスタ化管理に関連付けられたブロック１５６内にテキストを提供し得る。別の例では、本明細書で議論されるステップのいずれかの進捗度（例えば、送信されるメッセージまたはステップの成功）は、ブロック１５６に表示され得る。加えて、グラフィカル出力１５７が、ディスプレイインターフェース１５５上に表示され得る。グラフィカル出力１５７は、クラスタ内のデバイスのトポロジ、明細書で議論される任意の方法またはシステムの進捗度のグラフィカル出力等であり得る。

追加の例が、クラスタ化管理に関連付けられた情報の受信および表示に関して以下に提供される。ディスプレイインターフェース１５５は、具体的クラスタに対応するクラスタプロファイルパラメータを導入するためのプロンプトを表示し得る。例では、説明、ポリシ、および強化プロファイル内に含まれるパラメータは、ディスプレイインターフェース１５５または別の入力デバイスを介して構成され得る。また、トポロジまたはメトリックプロファイル内のパラメータ、例えば、ｃｌｕｓｔｅｒＮｏｆＭｅｍｂｅｒｓ、ｃｕｒｒｅｎｔＯｐｔｉｍｉｚａｔｉｎＧｏａｌ、またはｓｅｒｖｉｃｅＲａｔｉｎｇが、ディスプレイインターフェース１５５または別の入力デバイスを介して提供され得る。プロファイル登録または更新方法が、ディスプレイインターフェース１５５を介して表示され得る、または提供される入力に基づいてＣＰＲを更新するために使用され得る。所与のクラスタのために利用可能な現在の情報（例えば、クラスタプロファイルの通常のスナップショットまたはその一部）が、ディスプレイインターフェース１５５を介して示され得る。所与のクラスタに関する状態情報（例えば、具体的閾値に到達する最適化メトリック）が、ディスプレイインターフェース１５５を介して示され得る。クラスタ管理のための専用ＳＰアプリケーションと共に使用されるとき、入力は、ローカルで処理され、値は、計算された値であり得るような方法で提供され得る。そのようなアプリケーションは、ＳＰが、最大データ配信遅延を含むようにｃｕｒｒｅｎｔＯｐｔｉｍｉｚａｔｉｎＧｏａｌを再構成するアプリケーションに基づいて、新しいクエリを設定する、上記の例で使用され得る（時間Ｔ１に設定されるクエリに関する上記を参照）。図２８は、本明細書で議論される方法およびシステムに基づいて生成され得る、例示的ディスプレイを図示する。ディスプレイインターフェース１５５は、具体的クラスタに対応するクラスタプロファイルパラメータを入力または表示するためのプロンプトを表示し、クラスタを構成または再構成するための能力を提供し得る。ディスプレイインターフェース１５５は、クラスタのための検索を入力または表示するためのプロンプトを表示し、クラスタプロファイルにおいて現在のステータスパラメータを表示する、またはステータス、例えば、アルゴリズム状態またはパラメータ変化、アラート等を持続的に監視し得る。

ＣＰＲに関して本明細書に議論されるようなクエリ方法は、状態情報のために使用され得、クエリをトリガする閾値が、専用ＳＰアプリケーションを介して設定され得る。別の例では、アラート（例えば、音またはグラフィカル）が、プロシージャの具体的状態に到達すると（例えば、ａｓｓｅｓｍｅｎｔＴｒｉｇｇｅｒＴｈｒｅｓｈｏｌｄｓに基づいて、査定段階が開始される、または評価段階の間、周期的に更新される）ディスプレイインターフェース１５５を介して発生される。ディスプレイインターフェース１５５または他の入力デバイスを介した相互作用は、本明細書に議論されるように、クラスタのプロファイルの部分的もしくは完全更新またはＥＣＭＦ処理のトリガをもたらし得る。概して、マルチユーザアクセスは、アプリケーションまたはＳＬ内で仲裁され得る。

従来のｏｎｅＭ２Ｍアーキテクチャを拡張させ、本開示に定義されたクラスタ管理機能性をサポートするためのいくつかの潜在的例が、以下に提示される。

図２２は、ｏｎｅＭ２Ｍ機能アーキテクチャ内のＥＣＭＦおよびＣＰＲ機能の例示的位置を図示する。ＩＮ−ＣＳＥノード２５２上に常駐するＩＣ−ＥＣＭＦ２５２は、ＥＣＭＦにクラスタ間管理機能性を提供し得、これは、クラスタ内管理機能性をホストするフィールドドメイン内のノード（例えば、ＥＣＭＦ２５１を伴うＣＳＥノード２５０）にアクセス可能である。図２２におけるＩＮ−ＣＳＥ２５５はまた、ＣＰＲ２５３をホストする。フィールドドメインでは、ＣＳＥ２５０は、ＣＨまたはＢＳとして作用するデバイスである可能性が高く、ＭＮまたはＡＳＮ ｏｎｅＭ２Ｍノードのいずれかとして実装され得る。

図２３は、ｏｎｅＭ２Ｍ機能アーキテクチャ内のＥＣＭＦおよびＣＰＲ機能の例示的位置を図示する。図２３のアーキテクチャは、長寿命であり、広範に拡散され、物理的にアクセスが困難である、環境監視システムの大規模展開に好適であり得る。地理的エリアにおける変化（例えば、地震）は、非常に異なる面積内のクラスタに影響を及ぼし得、これは、非常に異なる動作要件に基づいて、再構成される必要があるであろう（例えば、先見的水位測定システムから反応的洪水アラート等）。２つのシステムは、ＭＮ−ＣＳＥ（例えば、ＭＮ−ＣＳＥ２６３およびＭＮ−ＣＳＥ２６４）として実装される異なるＢＳノードを有し得るが、ＩＮ−ＣＳＥ２６０内の中央ＥＣＭＦ（例えば、ＩＣ−ＥＣＭＦ２６１）が、広範な面積のクラスタ間機能性のために使用され得る。分散化された機能性は、ローカル／部分的ＣＰＲ（例えば、ＣＰＲ２６６）を使用し得る、または中央ＣＰＲ（例えば、ＣＰＲ２６２）への連続アクセスを有し得る。同様に、いくつかのＥＣＭＦ（例えば、ＥＣＭＦ２６７）は、管理されるクラスタの完全プロファイルを含むローカルＣＰＲ（例えば、ＣＰＲ２６８）とともに実装され得る。ＥＣＭＦ２６７およびＣＰＲ２６８が、ＭＮ−ＣＳＥの代わりに、ＭＮ−ＡＥに関連付けられる事例も存在し得る。

図２４は、現在のｏｎｅＭ２Ｍ ＲｏＡアーキテクチャに基づいて開示されるクラスタ化管理を実装するための一例を図示する。この場合、ＥＣＭＦ２７１は、任意のローカルＣＰＲを組み込む、ＣＳＥ２７０内の独立型共通サービス機能（ＣＳＦ）として実装され得る。別の例（図示せず）では、ＥＣＭＦおよびＣＰＲ（図示せず）は、ＣＳＥ２７０のデバイス管理２７２機能性内に実装され得る、またはＣＰＲ機能性は、独立型ノード内に実装され得る。

図２５は、クラスタプロファイルを記述するためにｏｎｅＭ２Ｍ ＲＥＳＴｆｕｌ内で使用され得るリソースを図示する。＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅ＞リソース２７４は、ＥＣＭＦ（例えば、ＥＣＭＦ１４２）によって、クラスタを登録もしくは更新する、もしくは利用可能なクラスタ情報をクエリするために使用され得る、または代替クラスタプロファイル構成を提供するクラスタ再構成のためのクラスタ間プロシージャ内で使用され得る。＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅ＞リソースは、子リソースとして、以下、すなわち、説明プロファイル（例えば、＜ｃｌｕｓｔｅｒＤｅｆｉｎｔｉｏｎＰｒｏｆｉｌｅ＞リソース２７５）、ポリシプロファイル（例えば、＜ｃｌｕｓｔｅｒＰｏｌｉｃｙｐＰｒｏｆｉｌｅ＞リソース２７６）、強化プロファイル（例えば、＜ｃｌｕｓｔｅｒＥｎｒｉｃｈｍｅｎｔＰｒｏｆｉｌｅ＞リソース２７７）、トポロジプロファイル（例えば、＜ｃｌｕｓｔｅｒＴｏｐｏｌｏｇｙＰｒｏｆｉｌｅ＞リソース２７８）、およびプロファイルメトリック（例えば、＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅＭｅｔｒｉｃｓ＞リソース２７９）のそれぞれを表す、個々のリソースを有し得る。代替として、例示的５つの子リソースの個々の属性が、主要＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅ＞リソース２７４の属性であり得る。子リソースの属性の説明が、本明細書に提供される。

開示される機能のいずれかが、ＣＳＥの外側またはそれから独立して実装されるとき、＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅ＞リソースは、ｏｎｅＭ２Ｍ定義ＣＳＥリソースツリーから独立して（例えば、ネットワーク内のその独自のノード上の別個のリソースツリーとして）インスタンス化されることができる。ＣＳＥまたはＣＳＦ内の実装では、＜ｃｌｕｓｔｅｒＰｒｏｆｉｌｅ＞リソースは、ｏｎｅＭ２Ｍ ＣＳＥリソースツリー内の種々のレベルにおいて（例えば、＜ｎｏｄｅ＞またはＣＳＥの＜ｂａｓｅＵＲＩ＞もしくは＜ｒｅｍｏｔｅＣＳＥ＞リソース下に）インスタンス化されることができる。

図２６は、現在のｏｎｅＭ２Ｍ ＳｏＡアーキテクチャに基づく例示的クラスタ管理を図示する。この場合、ＥＣＭＦ２８２は、関連付けられたＣＰＲ２８３を含み得る、サービスコンポーネントとして実装され得る。本明細書に定義されたＥＣＭＦ２８２の論理機能は、ＥＣＭＦ２８２サービスのためのサービス能力である。ＥＣＭＦ２８２サービスコンポーネントは、Ｍｓｃ参照点２８４を通して他のサービスと、Ｍｃａ参照点２８５を介してアプリケーションと通信し得る。

本開示におけるデータ構造およびメッセージは、ＳＯＡアーキテクチャにも同様に適用され得る。本明細書に説明されるパラメータは、各サービス能力を呼び出すために使用されるサービスシグネチャと考えられ得る。サービスシグネチャは、サービスを呼び出すために、インターフェースを経由してエクスポーズされるパラメータから成り得る。

図２９Ａは、本明細書に開示されるようなＭ２Ｍクラスタ管理が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０を図示する。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であり得る。

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

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

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

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

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

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

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

本明細書に議論される場合、用語「サービス層」は、ネットワークサービスアーキテクチャ内の機能的層と考えられ得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイムイネーブル化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む、（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられた課題に対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはサービス能力層（ＳＣＬ）と称され得る、サービス層によってサポートされる前述の能力または機能性の集合もしくはセットへのアクセスを提供することができる。いくつかの例として、限定ではないが、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（例えば、そのような機能エンティティ間の機能インターフェース）である。

図２９Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図２９Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス３０は、開示される主題と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。Ｍ２Ｍデバイス３０（例えば、ＣＨ１４１、ＣＨ１４３、ＢＳ１３７、ＩＮ１３１、ノード１４５、およびその他）は、Ｍ２Ｍクラスタ化管理のための開示されるシステムおよび方法を行う、例示的実装であり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、本明細書に説明される例のうちのいくつかにおけるＬＭＳが成功もしくは不成功である（例えば、メトリックカテゴリに関連付けられた閾値）であるかどうかに応答して、ディスプレイもしくはインジケータ４２上の照明パターン、画像、または色を制御する、または別様にＥＣＭＦ、ＣＰＲ、およびＳＬ（例えば、ＥＣＭＦ１３２、ＣＰＲ１３３、およびＳＬ１５１）相互作用およびパラメータ（例えば、表４−表１２およびその他）のステータスを示すように構成され得る。ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色の制御は、図に図示される、もしくは本明細書で論じられる、方法フローもしくはコンポーネントのいずれかのステータス（例えば、図１５−図２１）を反映し得る。本明細書に開示されるのは、Ｍ２Ｍクラスタ化管理のメッセージおよびプロシージャである。メッセージおよびプロシージャは、ユーザが、入力源（例えば、スピーカ／マイクロホン３８、キーパッド４０、またはディスプレイ／タッチパッド４２）を介して、Ｍ２Ｍクラスタ化管理関連リソース（例えば、パラメータ）を要求し、とりわけ、ディスプレイ４２上に表示され得る、Ｍ２Ｍクラスタ化管理を要求、構成、またはクエリするためのインターフェース／ＡＰＩを提供するように拡張され得る。

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

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

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

図２９Ｄは、例えば、図２９Ａおよび図２９ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピューティングシステム９０（例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４）は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、ＳＬ、ＥＣＭＦ、またはＣＰＲ関連付けられたメッセージの受信等、Ｍ２Ｍクラスタ化管理のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理し得る。

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

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

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

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

さらに、コンピュータシステム９０は、図２９Ａおよび２９Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７を含み得る。

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

以下は、本明細書で議論される用語の説明である。アルゴリズムメトリックは、ノードの受信された電力またはエネルギーレベル等、動作するためにアルゴリズムによって使用される属性を示すための用語と考えられ得る。クラスタは、デバイスのグループ化を示すと考えられ得る。本明細書では、これは、指定されるクラスタヘッドと通信し得る、センサまたは他のデバイス（例えば、無線温度センサ）のグループを指し得る。本明細書に議論されるように、例では、クラスタのデバイスは、センサ情報の効率的配信をイネーブルにするクラスタ内通信のためのアルゴリズムを実装し得る。クラスタ化は、クラスタベースの階層ネットワークを形成および維持するプロセスと考えられ得る。プロセスは、ＣＨ割り当て、ルーティング、およびトポロジ管理を含み得る。配信遅延は、本明細書に議論されるように、パケットをソースから宛先に伝送するために要求される時間の量と考えられ得る。本遅延は、有線もしくは無線通信トランスポート、デバイスのプロセッサ、メモリ等に関連付けられ得る。

図で図示されるような本開示の主題の方法、システム、または装置は、好ましい例を説明する上で、明確にするために、Ｍ２Ｍクラスタ管理特有の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

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

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

方法、システム、および装置は、とりわけ、本明細書に説明されるように、デバイスクラスタ管理（例えば、Ｍ２Ｍクラスタ化管理）のための手段を提供し得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、クラスタプロファイルレジストリを用いてクラスタ管理を可能にする、パラメータのリストを受信するステップと、パラメータに基づいて、装置に関連付けられたデバイスのクラスタのプロファイルを作成するステップであって、デバイスのクラスタは、現在のクラスタ化アルゴリズムに基づいて通信する、ステップと、デバイスのクラスタのプロファイルをクラスタプロファイルレジストリに登録するステップとのための手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、プロファイルに基づいて、最適化目的が満たされていないことを決定するステップと、最適化目的が満たされていないことを決定することに応答して、現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価するステップとのための手段を有する。決定は、プロファイル以外、例えば、前述および後述の統計に基づいて行われ得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、プロファイルに基づいて、最適化目的が満たされていないことを決定するステップと、最適化目的が満たされていないことを決定することに応答して、現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価するステップであって、最適化目的は、デバイスのクラスタのための閾値エネルギー消費を含む、ステップとのための手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、プロファイルに基づいて、最適化目的が満たされていないことを決定するステップと、現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価するステップと、性能を評価することに基づいて、最適化目的を満たすための候補クラスタ化アルゴリズムの性能が、最適化目的を満たすための現在のクラスタ化アルゴリズムの性能を満たす、またはそれを超えることを決定するステップと、最適化目的を満たすための候補クラスタ化アルゴリズムの性能が、最適化目的を満たす現在のクラスタ化アルゴリズムの性能を満たす、またはそれを超えることの決定に応答して、デバイスのクラスタを候補クラスタ化アルゴリズムに再構成するための命令を提供するステップとのための手段を有する。候補の評価は、主要な１つが準最適となる（例えば、目的が満たされていない）前でも、初めから主要アルゴリズムと並行して進められ得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、プロファイルに関連付けられたパラメータの閾値変化に基づいて、プロファイルを更新するステップであって、パラメータは、通信コストを含む、ステップのための手段を有する。通信コストは、エネルギーのコスト、遅延等であり得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、プロファイルを新しい最適化目標で更新するステップのための手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、クラスタトポロジ再構成をトリガするステップのための手段を有する。デバイスのクラスタは、無線デバイスを含み得る。上方の装置は、クラスタヘッドまたは基地局であり得る。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、２つもしくはそれを上回るデバイスクラスタが最適化目的を満たすためのクラスタ化アルゴリズムの性能を評価するステップと、性能を評価することに基づいて、クラスタ化アルゴリズム最適化目的のうちの少なくとも１つの性能が満たされていないことを決定するステップと、クラスタ化アルゴリズムの性能が満たされていないことを決定することに応答して、少なくとも１つのデバイスのクラスタを再構成するための命令を提供するステップとのための手段を有する。方法、システム、コンピュータ読み取り可能な記憶媒体、または装置は、最適化目的が満たされていないことを決定するステップと、最適化目的が満たされていないことを決定することに応答して、クラスタ化アルゴリズムを再構成するための命令を提供するステップとのための手段を有する。この段落における全ての組み合わせ（ステップの除去または追加を含む）は、発明を実施するための形態の他の部分と一貫する様式で検討される。

Claims (14)

1. クラスタ化を管理するための装置であって、前記装置は、
   プロセッサと、
   前記プロセッサに結合されているメモリと
   を備え、
   前記メモリは、実行可能な命令を備え、前記命令は、前記プロセッサによって実行されると、
   クラスタプロファイルレジストリを伴うクラスタ管理をイネーブルにするパラメータのリストを受信することと、
   前記パラメータに基づいて、前記装置に関連付けられたデバイスのクラスタのプロファイルを作成することであって、前記デバイスのクラスタは、現在のクラスタ化アルゴリズムに基づいて通信する、ことと、
   前記デバイスのクラスタの前記プロファイルを前記クラスタプロファイルレジストリに登録することと、
   前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
   前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間で最適化目的を満たすための性能を評価することと、
   前記性能を評価することに基づいて、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することと、
   前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することに応答して、前記デバイスのクラスタを前記候補クラスタ化アルゴリズムに再構成するための命令を提供することと
   を含む動作を前記プロセッサに行わせる、装置。
2. 前記最適化目的は、前記デバイスのクラスタのための通信コストを含む、請求項１に記載の装置。
3. 前記デバイスのクラスタは、無線デバイスを含む、請求項１に記載の装置。
4. さらなる動作が、前記プロファイルに関連付けられたパラメータの閾値変化に基づいて、前記プロファイルを更新することを含み、前記パラメータは、通信コストまたは配信遅延を含む、請求項１に記載の装置。
5. さらなる動作が、クラスタトポロジ再構成をトリガすることを含む、請求項１に記載の装置。
6. さらなる動作が、前記プロファイルを新しい最適化目的で更新することを含む、請求項１に記載の装置。
7. 前記装置は、クラスタヘッドまたは基地局である、請求項１に記載の装置。
8. クラスタ化を管理する方法であって、前記方法は、プロセッサを含む装置において実行され、前記方法は、
   前記プロセッサが、クラスタプロファイルレジストリを伴うクラスタ管理をイネーブルにするパラメータのリストを受信することと、
   前記プロセッサが、前記パラメータに基づいて、前記装置に関連付けられたデバイスのクラスタのプロファイルを作成することであって、前記デバイスのクラスタは、現在のクラスタ化アルゴリズムに基づいて通信する、ことと、
   前記プロセッサが、前記デバイスのクラスタのプロファイルを前記クラスタプロファイルレジストリに登録することと、
   前記プロセッサが、前記プロファイルに基づいて、最適化目的が満たされていないことを決定することと、
   前記プロセッサが、前記現在のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間で最適化目的を満たすための性能を評価することと、
   前記プロセッサが、前記性能を評価することに基づいて、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することと、
   前記プロセッサが、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記現在のクラスタ化アルゴリズムの性能を超えていることを決定することに応答して、前記デバイスのクラスタを前記候補クラスタ化アルゴリズムに再構成するための命令を提供することと
   を含む、方法。
9. 前記最適化目的は、前記デバイスのクラスタのための通信コストを含む、請求項８に記載の方法。
10. 前記プロセッサが、前記プロファイルに関連付けられたパラメータの閾値変化に基づいて、前記プロファイルを更新することをさらに含み、前記パラメータは、配信遅延を含む、請求項８に記載の方法。
11. 前記プロセッサが、クラスタトポロジ再構成をトリガすることをさらに含む、請求項８に記載の方法。
12. 前記プロセッサが、前記プロファイルを新しい最適化目的で更新することをさらに含む、請求項８記載の方法。
13. ２つ以上のデバイスクラスタを管理する方法であって、前記方法は、プロセッサを含む装置において実行され、前記方法は、
    前記プロセッサが、最適化目的を満たすための前記２つ以上のデバイスのクラスタ内のクラスタ化アルゴリズムの性能を評価することと、
    前記プロセッサが、前記クラスタ化アルゴリズムの性能を評価することに基づいて、前記クラスタ化アルゴリズムのうちの第１のクラスタ化アルゴリズムの性能が満たされていないことを決定することと、
    前記プロセッサが、前記クラスタ化アルゴリズムのうちの前記第１のクラスタ化アルゴリズムの性能が満たされていないことを決定することに応答して、前記第１のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間の最適化目的を満たすための性能を評価することと、
    前記プロセッサが、前記第１のクラスタ化アルゴリズムと候補クラスタ化アルゴリズムとの間で最適化目的を満たすための性能を評価することに基づいて、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記第１のクラスタ化アルゴリズムの性能を越えていることを決定することと、
    前記プロセッサが、前記最適化目的を満たすための前記候補クラスタ化アルゴリズムの性能が前記最適化目的を満たすための前記第１のクラスタ化アルゴリズムの性能を超えていることを決定することに応答して、前記２つ以上のデバイスクラスタのうちの少なくとも１つのデバイスのクラスタを前記候補クラスタ化アルゴリズムに再構成するための命令を提供することと
    を含む、方法。
14. 前記２つ以上のデバイスクラスタは、基地局を介して接続されている、請求項１３に記載の方法。