JP5948497B2 - コンテンツ中心かつロードバランシング認識型の動的なデータアグリゲーション - Google Patents

Description

ここに開示される実施形態は、通信網内のデータ通信に関する。

新興のマシン・トゥ・マシンの（Ｍ２Ｍ）アプリケーション（例えば、スマートグリッドおよびスマートシティのようなインテリジェントシステム）では、多数の無線センサノードのような小型でスマートなデバイスが展開するであろうことが予想される。これらのノードが、関心のあるオブジェクトを観察／監視するための、データの継続的なセンシングおよび収集を容易にすると期待される。それから、適応決定を可能にすると共にシステム自動化を実現するために、収集された情報をコントロールセンターになんとかして渡す必要がある。マルチホップルート（すなわち、ソースノードと宛先ノードとの間の１つ以上の中間ノードを含むルート）上では、データ転送の需要増がある、ということになる。

マルチホップ無線リンク上での生データの転送は、リソースならびに時間の両方の面から高コストであり得る。マルチホップルート上で転送されるトラヒックの総量は、特に相関情報の前処理により、ネットワーク内処理およびデータアグリゲーションを用いて相当に削減することができる。例えば、エネルギー効率のよいデータアグリゲーションおよび融合方式は、ネットワーク内のデータを前処理し、そのオリジナルのサイズと比較して、はるかに少ないデータ量を備えた処理結果だけを送ることができる。したがって、これらの方式は、将来の無線ネットワークのために、冗長なトラヒックを減ずると共にデータ過負荷を回避できる。しかしながら、効率的にデータを計算および中継するために、適切なデータ転送方式が、前提条件として必要である。

第１の実施形態によれば、ｉ）候補ノード毎に、当該候補ノードにおいて通信データをアグリゲートすることを通じて得られる通信データ削減の大きさを含む限界処理利得を判定することと、ｉｉ）通信リンクを形成するために候補ノードのうちの１つを選択することとを含み、選択は、候補ノード毎に判定された限界処理利得に少なくとも部分的に基づいている、第１の通信ノードから複数の隣接候補ノードのうちのいずれか１つに通信データを送るための通信リンクを決定する方法が提供される。

いくつかの実施形態では、通信データ削減の大きさは正規化される。

いくつかの実施形態では、候補ノードの限界処理利得は、当該候補ノードに通信データを割り当てた場合の処理利得の大きさと当該候補ノードに当該通信データを割り当てないとした場合の処理利得の大きさとの間の差分を含む。

いくつかの実施形態では、限界処理利得は、ローカル寿命利得を含む目的関数の一部であり、ローカル寿命利得は、候補ノードに通信データを割り当てることにより達成される１つ以上の隣接候補ノードの寿命の変化を定義する。方法は、通信リンクのために選択されることになるノードを決定するために候補ノード毎に前記目的関数を評価することを含んでもよい。

いくつかの実施形態では、所与の候補ノードについて前記目的関数を評価することは、通信データが所与の候補ノードに割り当てられた場合の、隣接候補ノードの１つ１つの寿命を推定することと、通信データが所与の候補ノードに割り当てられない場合の、隣接候補ノードの１つ１つの寿命を推定することとを含み、それぞれの場合に、ローカル寿命は、隣接候補ノードの中で最短の推定寿命を持つノードの寿命として定義され、所与の候補ノードについてのローカル寿命は、通信データが当該候補ノードに割り当てられた場合のローカル寿命と通信データが当該候補ノードに割り当てられない場合のローカル寿命との間の差分に基づいて判定される。

いくつかの実施形態では、ローカル寿命利得の大きさは、通信データが候補ノードに割り当てられる場合について推定されたローカル寿命によって正規化される。

いくつかの実施形態では、目的関数は、処理利得の大きさおよびローカル寿命利得の大きさの重み付き和を含む。重み付き和は、重み係数に依存してもよく、重み係数は、目的関数において、ネットワーク寿命に対する感度に関して、処理利得の大きさおよびローカル寿命利得の大きさの影響の平衡を保つように操作可能である。

いくつかの実施形態では、隣接候補ノードの寿命は、当該隣接候補ノードのエネルギー消費を推定することによって推定される。

いくつかの実施形態では、各隣接候補ノードのエネルギー消費は、第１の通信ノードとそれぞれの隣接候補ノードとの間のリンク品質パラメータを定義することによって推定され、リンク品質パラメータは、データの送達の成功を保証するために第１の通信ノードと隣接候補ノードとの間で当該データが２回以上送信される必要がある尤度を反映する。リンク品質パラメータは、第１の通信ノードからそれぞれの隣接候補ノードへとビットデータが首尾良く送達されるために送信される必要がある平均回数を定義してもよい。

いくつかの実施形態では、候補ノード毎に、当該候補ノードに通信データを割り当てる場合のローカル寿命利得を判定する際に、第１の通信ノードの寿命が考慮に入れられる。

いくつかの実施形態では、通信データは複数のデータタイプを含み、方法は、データタイプ毎に、ステップｉ）およびｉｉ）を実行することを含む。各データタイプは、データを中継するために必要とされるビット数を削減するために、ノードで実行する機能または関数によりアグリゲートすることのできるデータを含んでもよい。各データタイプは、環境の様々なパラメータを反映するセンサ信号を含んでもよい。

いくつかの実施形態では、データタイプ毎に、限界処理利得は、ローカル寿命利得の大きさをさらに含む目的関数の一部であって、ローカル寿命利得は、候補ノードに特定のタイプの通信データを割り当てる場合の、１つ以上の隣接候補ノードの寿命の変化を定義する。方法は、特定のタイプの通信データの通信リンクのために選択されることになるノードを決定するために候補ノード毎に目的関数を評価することを含んでもよい。

いくつかの実施形態では、データタイプ毎に、目的関数は報酬パラメータを含み、報酬パラメータは、特定のタイプのデータをアグリゲートする能力を持つノードへと候補ノードの選択にバイアスをかける。

いくつかの実施形態では、目的関数は、いくつかのインターバルで実行される。インターバルのサイズは、第１の通信ノードに到着するデータタイプの変動の量に基づいて決められてよい。方法は、いくつかのインターバルそれぞれに第１の通信ノードに到着する様々なデータタイプの数を監視することと、インターバル毎に、前のインターバルと比較しての、到着したデータタイプの数の変化を判定することと、変化に基づいて、目的関数が実行されるべき確率を決定することと、確率が閾値より上にあることが発見される場合に、目的関数を実行することとを含んでもよい。

いくつかの実施形態では、閾値は乱数発生器から得られる。

いくつかの実施形態では、通信データは、通信進展因子をさらに含むデータパケットの中に含まれている。通信進展因子は、意図された受側ノードへのネットワーク内の順通信のために候補ノードの選択を支配するために使用されてもよい。

いくつかの実施形態では、通信進展因子は、第１の通信ノードが位置するネットワークのレイヤの表示を含む。通信リンクのために候補ノードを選択する場合に、もし受側ノードからさらに離れたレイヤに位置する全ての隣接ノードが第１の通信ノードによって送信されているデータタイプにデータアグリゲーションを行なう能力を持たなければ、第１の通信ノードは、当該隣接ノードを候補ノードとしての考慮から除外してもよい。

いくつかの実施形態では、通信進展因子は、第１の通信ノードが位置するネットワークのレイヤの表示と、カウンタとを含み、カウンタの値は、第１の通信ノードのレイヤと同じまたは受側ノードからさらに離れたレイヤの中のノードへと通信データが送信されるごとにインクリメントされる。カウンタの値が閾値に達する場合に、第１の通信ノードは、通信データを転送するための候補ノードとして、受側ノードのより近くに位置するノードだけを考慮してもよい。

別の実施形態によれば、通信装置のネットワークにおいて動作可能な通信装置であって、装置は、当該装置から複数の候補隣接装置のいずれかへの通信のための通信リンクを決定するように動作可能であり、装置は、候補ノード毎に、当該候補ノードで通信データをアグリゲートすることを通じて得られる通信データ削減の大きさを含む限界処理利得を判定するように動作可能な処理利得判定器と、通信リンクを形成するために候補ノードのうちの１つを選択するように動作可能な通信リンク選択器とを含む。選択は、候補ノード毎に判定された限界処理利得に少なくとも部分的に基づいている、通信装置が提供される。

別の実施形態によれば、コンピュータ化された通信装置による実行時に、当該装置に第１の実施形態に従う方法を行わせるコンピュータ実行可能命令を含むコンピュータプログラムプロダクトが提供される。

図１（ａ）は、記述された実施形態の分野でのルーティングアプローチを示す。図１（ｂ）は、記述された実施形態の分野でのさらなるルーティングアプローチを示す。図１（ｃ）は、記述された実施形態の分野でのさらなるルーティングアプローチを示す。 図２は、ここに記述された実施形態を例証する、通信ノードのネットワークを示す図である。 図３（ａ）は、図２のネットワークにおけるルーティングの例を示す。図３（ｂ）は、図２のネットワークにおけるルーティングのさらなる例を示す。 図４（ａ）は、図２のネットワークにおけるルーティングの例を示す。図４（ｂ）は、図２のネットワークにおけるルーティングのさらなる例を示す。 図５は、ルーティング決定を下す際に、図２のネットワークのノードによって行なわれる方法のフロー図を示す。 図６は、図２のネットワークにおけるルーティングのさらなる例を示す。 図７は、上述の実施形態において用いられる重み係数の変動に対するネットワーク寿命の性能を示すグラフを示す。 図８は、ここに記述される実施形態を用いるサイズに対するネットワークの性能のグラフを示す。 図９は、記述された実施形態の一例のエネルギー消費を従来技術と比較して示す。 図１０は、従来技術に関して、ここに記述される実施形態のノードの残存エネルギーレベルの変動の係数のグラフを示す。 図１１は、ここに記述された実施形態のトラヒックマップを示す。 図１２は、従来技術の一例のトラヒックマップを示す。 図１３は、ここに記述された実施形態の残存エネルギーマップを示す。 図１４は、背景技術の一例の残存エネルギーマップを示す。 図１５は、様々な要因を考慮に入れる場合に、ネットワークにおいて用いられ得る様々なルーティングトポロジを示す。 図１６は、ここに記述された実施形態においてノード間で交換されるメッセージ信号の系列を示す。 図１７は、ネットワーク中のノードで受信されるトラヒックコンテンツのタイプが時間と共にどのように変わり得るかを示す。 図１８は、ここに記述された実施形態に従って、ノードが、データ中継のための隣接ノードについての当該ノードの選択を再評価するかどうかを判定する処理を示す。 図１９は、ここに記述された実施形態に従って、データを処理する能力を持つノードにデータを優先的に転送するために、報酬パラメータがどのように用いられ得るかを示す。 図２０は、従来のループ回避方式を使用するネットワークにおけるトラヒックの取るパスと、ここに記述された実施形態に従う方法を実装するネットワークにおけるトラヒックの取るパスとの比較を示す。 図２１は、ここに記述された実施形態において、Ｔｉｍｅ−Ｔｏ−Ｇｏ−Ｆｏｒｗａｒｄ（ＴＴＧＦ）プロトコルがどのように実装されるかの一例を示す。 図２２は、従来のアプローチによって得られるネットワーク寿命を、ここに記述された実施形態を用いて得られるネットワーク寿命と比較するシミュレーションの結果を示す。 図２３は、従来のアプローチにおいて１ラウンドあたりの再送信に費やされる平均エネルギー消費を、ここに記述された実施形態において１ラウンドあたりの再送信に費やされる平均エネルギー消費と比較するシミュレーションの結果を示す。 図２４は、ここに記述された２つの異なる実施形態を用いて達成されるネットワークトラヒックの比較を示す。 図２５は、ここに記述された実施形態に従うループ回避方式を用いることにより、ネットワーク寿命がどのように増加され得るかの一例を示す。 図２６は、ここに記述された実施形態の方法を行なうのに適した通信ノードを実装できる装置を示す。

図１ａは、ネットワーク内処理が行われない場合に、この分野において遭遇するかもしれない問題を図示する。この場合に、通信は、ソースノード（Ｓ１−Ｓ６で表される）からＵ１で表されるシンクノードへと、互いに関係なしにマルチホップ経路上で送られる。図示されるように、通信は、ノードＳ４、Ｓ５およびＳ６で一体化（アグリゲート）し、通信における以降のホップは十分な通信路容量を必要とし、そうでなければ、通信の遅延、失敗、またはその他の他の有害な結果が生じる。

一般的な原理として、ここに記述された実施形態は、分散処理を利用することにより動作する。コンテンツ中心かつロードバランシング認識型の分散型データルーティングソリューションが、大規模なマルチホップＭ２Ｍ無線ネットワークのために提示される。独立したルーティング決定が、ローカル情報だけを用いて各ノードによって下される。従って、このアプローチは、動的な環境に非常に適応性がある。

一実施形態において、２つの主要部分を含む、ルート選択用のハイブリッド目的関数が記述される。
１． 同様のタイプのデータをアグリゲートし、これにより処理利得を増加させることによって、通信トラヒックを削減する。
２． より長期のローカルネットワーク寿命を達成できるように、隣接のノードの中のエネルギー消費の平衡を保つ。

結局、ある実施形態では、ボトルネックノードについてのロードバランシング問題の解決によりネットワーク寿命全体も延長することができる。

慣習的に、典型的なデータ収集シナリオでは、ノードによって収集された情報は、中心的なゲートウェイノード（シンク）に最初に送られる。それから、この情報は詳しい分析のために処理される。しかしながら、多くの場合に、様々なノードから収集されたデータは大いに相互に関連するので、シンクへと転送する間に合体させたり共同で処理したりすることができる。例えば、アプリケーションの監視のためＡＶＥＲＡＧＥまたはＭＡＸの表示度数のデータ・レポートを含むデータストリームに関して、または、すべて同じ物理イベントを感知する多数のセンサのためのセンサ表示度数を含むデータストリームに関して、相当な相関性があるかもしれない。

ネットワーク内処理は、高コストな無線通信リンク上で送信されるメッセージの総量を削減するために、ネットワーク内の情報のこの種の分散処理に対処する。これは、全体的なネットワーク効率ばかりでなくエネルギー消費に相当の影響を及ぼす。しかしながら、この領域の主な問題の一つは、様々なシステム側面（例えば、多数の共存するアプリケーション（異なるアプリケーションのために生成されたデータは相互に関連しないかもしれない）、不均一なノードエネルギーレベル、およびロードバランシング問題（いくつかのボトルネックノードが、多い作業量または低い残存エネルギーにより全ネットワークの性能に影響するかもしれない）など）を考慮することによって、データがどのように処理および中継されるかである。

リソースを制約されたネットワークにおける効率的なデータの収集およびアグリゲーションが、過去に考慮されてきた。図１ｂは、クラスタリングを図示する。クラスタリングは、単純であるが効果的な階層的データ収集ソリューションである。そして、クラスタリングでは、クラスタヘッド（ＣＨ）が、ローカルエリアにおけるノードの間でゴシッピングをするメッセージを介してポーリングされ、一旦選択されると、それらはネットワーク動作のローカルコントローラの役割を果たす。したがって、図１ｂで例証されるように、ノードＳ４は適切なクラスタヘッド（ＣＨ）であると確認されており、これは、長距離ホップ（１で表される）またはノードＳ５を介したマルチホップ経路（２で表される）を通じてのアグリゲートされた通信の伝送の前に、ノードＳ１、Ｓ２、Ｓ３、Ｓ５およびＳ６から伝送を収集する。クラスタが形成されている場合には、同じクラスタの中のパケットはすべてＣＨに直接送られ、それからサマリーメッセージが生成されてシンクへと送信される。

しかしながら、ロードバランシングの目的のためにはネットワーク構造の周期的な再構築（再クラスタリング）が必要とされる。これは、通信オーバーヘッドによる追加の遅延および追加のエネルギー消費を招く。さらに、これらのアルゴリズムは動的なネットワーク状態の下では脆弱であるし、均質なトラヒックパターンが通常仮定される（すなわち、ネットワーク中の全ノードが同じタイプのメッセージを定期的に報告する）。

クラスタリングベースのアルゴリズムと同様に、ツリーベースのアプローチ（図１ｃ）は、適切なツリー構造を様々な要求に基づいて最初に構築する必要があり、それゆえソースからシンク（ツリーの根）へのトラヒックフローは、ツリーの好ましい方向に基づいてルーティングされる。２つ以上のメッセージが処理ノードに一旦到着すれば、データアグリゲーションが行なわれ、それらの集合体を計算してから次のホップへと転送することができる。

やはり、ツリーベース方式の欠点はクラスタリングベースアルゴリズムの欠点と同様である。アプリケーションのトラヒックが変わるごとに、または、新しいアプリケーションが出現するごとに、最適化されたツリー構造を新しい要求に基づいて再形成する必要がある。

従って、多数のアプリケーションが共存する動的な環境では、異なるデータタイプの効率的な配信および不均一なトラヒックフローのより良好な組織化のために、様々なデータアグリゲーションパスが必要とされる。あらかじめ最適化された静的な構造は、この動的な要求を満たすことができない。他方、グローバルネットワークトポロジを頻繁に再建したり、多数のオーバーレイされたツリーを計算および構築したりすることは、計算的に効率的ではない。故に、このアプローチを維持することは高コストになるであろう。

ここに記述された実施形態は、例えば、コンテンツ中心ルーティングおよび処理、ロードバランシング、通信信頼度およびネットワーク力学などのいくつかのむずかしい問題を考慮に入れる点で、従来のアグリゲーション・アプローチとは異なる。処理効率、ネットワーク寿命延長および場合によっては通信信頼度を考慮して各ノード上で目的関数を処理することにより分散型意思決定アプローチが用いられる。更に、実施形態は、そのコンテンツによってネットワークトラヒックを区別するコンテンツ中心技法を実装する。故に、メッセージのコンテンツタイプに基づいて、ノードはそれぞれ目的関数を実行することによって異なるルーティングテーブルを構築するかもしれない。そのようにすることによって、トラヒックの総量はそれらが処理され得るノードへの関連データをアグリゲートすることで削減することができる。結果として、これはエネルギー効率を改善し、ネットワーク寿命を延長する。故に、実施形態は、異なるトラヒックタイプの効率的な配信および不均一なトラヒックフローのより良好な組織化のための代替データアグリゲーションパスを生成できる。

ここに記述された実施形態は、動的かつ不均一なトラヒックパターンを備えるネットワークに対する分散処理およびロードバランシング技術の統合による効率的なルーティングソリューションを提供する。

図２に例証されるように、実施形態は、次に、ネットワークの視点から記述されるであろう。ネットワークは、Ｎ個のノードＶ＝｛ｖ１，ｖ２，．．．，Ｖ_Ｎ｝によって形成される。ゲートウェイｖ_０は、ネットワークの中心に位置する。ノードは電池式であり、各ノードはそれぞれ有限かつ非補給のエネルギー供給Ｅ（ｉ）を持つ。不均一な、初期ノードエネルギーレベルが仮定される。多くの実用的なシステムにあるように、ゲートウェイｖ_０はより強力なノードとして見なされ、他のノードよりはるかに高い初期エネルギーレベルを持つと仮定され、または、無制限の電源に接続される。簡単にするために、送信電力制御は不可能とする。従って、ノードはすべて固定の通信距離を持ち、それらはマルチホップリンクを介して接続される。従って、波のような通信リングトポロジが形成できる。各リング（レイヤ）の中のノードは、シンク（図２）に到着するのに必要とされるホップの最小数を表わすレイヤＩＤを割り当てられる。

ネットワーク中で実行するアプリケーションの視点からすると、アプリケーションＡ＝｛ａ_１，ａ_２，ａ_３，．．．｝が、確率Ｐ_ａｐｐおよび寿命存続時間Ｔ＝｛ｔ_１，ｔ_２，ｔ_３，．．．｝を備えて、無作為にゲートウェイに出現する。アプリケーション毎に、初期データを生成するいくらかのソースノードが必要とされる。ソースノードは、アプリケーション要求（例えば、特別のエリアを監視すること）に基づいて、または、無作為にゲートウェイによって選ばれることで、あらかじめ選択され得る。

時間はラウンドと呼ばれる期間に分割される、トラヒックは同じアプリケーションのすべてのソースノードについてラウンド毎パケット毎にｒビットの一様な速度で生成されると仮定されているが、異なるトラヒック速度（Ｒ＝｛ｒ_１，ｒ_２，ｒ_３，．．．｝）が異なるアプリケーションのために生成され得る。

アプリケーション寿命Ｔが一旦満了になれば、対応するソースノードはそのアプリケーションのためのデータの生成および送信を停止するだろう。前のアプリケーションが一旦終了しても同一のアプリケーションが確率Ｐ_ａｐｐでネットワーク内に再び出現し得るし、多数の異なるアプリケーションがネットワーク内で共存し得る。

図３ａおよび３ｂは、Ｖ１からＶ４までの４つのネットワークノードに対する、この実施形態において採用されたアプローチの具体例を図示する。この実施形態の実行において、ネットワーク（図３ａ）内のすべてのノード上で例えばＳＵＭ、ＭＡＸ、ＭＩＮ、ＡＶＥＲＡＧＥなどのデータアグリゲーション関数を行なうことができると仮定されている。図３ａに図示された第１の例において、３つのデータソースノードＶ_１、Ｖ_２およびＶ３は、それぞれ温度監視アプリケーションを起動している。そして、ノードｖ_ｉ（この場合はＶ４）は、それ自身のメッセージ（ｖ_ｉもまたソースノードであるならば）と一緒に多数の入力メッセージを単一の出力メッセージへとアグリゲートできる。

但し、同じアプリケーションからのメッセージだけがアグリゲート可能であると仮定されている。図３ｂに示されるように、ソースノードのうちの１つＶ３が今度は湿度監視アプリケーションを起動している。様々な理由で、異なるデータタイプはたやすく処理されないかもしれない、または、場合によってはそのようにすることができないかもしれない。例えば、温度表示度数を含むデータセットと湿度表示度数との平均値を計算することは意味がない。

記述された実施形態を達成する際に、実行の鍵は各ノードに目的関数を埋め込むことである。確率ｐに依存して、目的関数は異なるアプリケーショントラヒックの転送のための次ホップノードをランク付けて選択するために実行される。故に、独立したルーティング決定が、ローカル情報のみを用いて各ノードによって下される。データタイプｋ毎に、次ホップノードｊが、数式１で記述される目的関数Ｆによって選ばれる

ここで、第１項ｇ_ｊ’―ｇ_ｊ’’は、アグリゲーションによる、正規化された通信データ削減量を算定する、限界処理利得である。第２項（Ｌ_ｊ’―Ｌ_ｊ’’）／Ｌ_ｊ’は、正規化されたローカル寿命利得として定義される。βは、２つのパラメータ間の重みを提供する、調整パラメータである。

以下では、各項がさらに掘り下げて記述されるだろう。

限界処理利得
上記式では、限界処理利得はｇ_ｊ’―ｇ_ｊ’’として与えられ、ここで、ｇ_ｊ’はトラヒックｋをノードｊに割り当てることによる処理利得であり、ｇ_ｊ’’はトラヒックｋをノードｊに割り当てないとした場合の処理利得である。

ここで、処理利得ｇは次のように計算される。

ここで、Σ_ｋＲ_ｉｎ ^ｋ _ｊはノードｊを介して中継される全アプリケーションｋについての入トラヒックの総量であり、Σ_ｋＲ_ｏｕｔ ^ｋ _ｊは合計の出トラヒックである。

従って、数式２の分子に示された部分は、ｊでのアグリゲーション処理によって削減されたトラヒックの総量であり、そしてこの値は入トラヒックの合計で割られる。

この論理的根拠に関して２つの主な理由がある。

１）それをローカル寿命利得（数式（１）に示される第２項）と数的に比較可能とするのは正規化処理である。故に、ハイブリッド利得が計算可能となる。

２）ロードバランシングの目的のため：同じ処理利得を提供（同じデータ量を削減）できるが、既に割り当てられているトラヒックがより少ないノードへとトラヒックを中継することが好ましい。従って、トラヒック削減量が同じであるとして、ノードが持つ入トラヒックが多くなるほど、当該ノードが得ることのできる処理利得は小さくなる。

上記アプローチの動作例が、図４ａおよび図４ｂに図示される。これらの例の各々では、２つのアプリケーション（Ｔ１およびＴ２）が、６つのノードによって形成されたネットワークの中でデータを収集している。ノード１、２、３、４はＴ１のソースノードであり、ノード４だけがアプリケーションＴ２のための情報を提供している。

ここでは、ノード３は、どのノードがそのトラヒックを転送すべきかを判定するために目的関数を実行している。

図４ａに示される配置は、ノード５を介してノード３からのトラヒックを中継することを示している。その一方で、図４ｂに示される配置は、ノード４を介してノード３からのトラヒックを中継することを示している。状況に上記公式化を適用すると、次の計算が生じる。

シナリオａ
ノード３からノード５までトラヒックタイプＴ１を中継する限界処理利得は次のとおりである。
ｇ’’＝（３０００−１０００）／３０００＝２／３
ｇ’＝（４０００−１０００）／４０００＝３／４
限界処理利得＝ｇ’−ｇ’’＝１／１２
シナリオｂ
ノード３からノード４までトラヒックタイプＴ１を中継する限界処理利得は次のとおりである。
ｇ’’＝（２０００−２０００）／２０００＝０
ｇ’＝（３０００−２０００）／３０００＝１／３
限界処理利得＝ｇ’−ｇ’’＝１／３
明らかに、この例では、ノード４（シナリオｂ）がより良好な処理利得を持つので、それが選択されるであろう。この決定は、両方の場合の通信リンクの各々についてのトラヒックを直接観察することによりさらに評価することができる。それらは各リンク上にちょうど同じ量の通信トラヒックを持つが、シナリオａにおけるノード５は、それがＴ１のためのほとんどのトラヒックを受信および処理する必要があるから、ボトルネックノードである。対照的に、シナリオｂはよりバランスのとれたソリューションを提供する。

しかしながら、ノードがより多くのエネルギーを備え付けている場合には、原則として、当該ノードは内蔵のエネルギーが少ないノードと比較してより多くの情報を中継および処理できる。しかし、処理利得関数中のロードバランシング関数は、不均一なノードエネルギーレベルを反映できない。故に、ローカル寿命利得として知られる別のパラメータが、数式（１）において述べられた目的関数へ加えられる。

ローカル寿命利得
上で言及されるように、ローカルの寿命利得は（Ｌ_ｊ’―Ｌ_ｊ’’）／Ｌ_ｊ’として表現され、ここで、Ｌ_ｊ’はトラヒックｋをノードｊに割り当てることによるローカル寿命であり、Ｌ_ｊ’’はトラヒックｋをノードｊに割り当てないとした場合のローカル寿命である。
ここで、ローカル寿命Ｌは、次式によって計算される。

ここで、Ｅ_ｊはノードｊの残存バッテリーエネルギーである。ｅ_ｊは、データを送受信することのコストに加えて、データアグリゲーションのコスト、フラッシュに情報を読み書きすることのコストを含むノードｊの総エネルギー消費量である。Ｎは、次ホップノードが選ばれる候補ノードの数である。

したがって、ノードｊがローカル領域において最短の寿命を持つボトルネックノードである場合に、そのノードにより多くのトラヒックをさらに割り当てることは、全体的なネットワーク寿命にも影響するローカルネットワーク寿命を必然的に減少させる。従って、この場合に、ローカル寿命利得関数によって目的関数にペナルティが加えられる。他方、いくつかのメッセージがボトルネックノードから離れて転送される場合には、報酬が与えられる。従って、ロードバランシングは、動的なトラヒックフローの分布だけでなくネットワーク内の不均一なバッテリーエネルギーレベルを考慮することによって達成される。

多数のアプリケーションのために集中型のオーバーレイされたツリー構造を構築したり、ネットワーク状態が一旦変化すれば各ルーティングトポロジを再構築したりするよりも寧ろ、よりロバストな方法は、ローカル情報に基づいて次のホップ中継を各ノードが決定する分散型意思決定アプローチを持つことである。

この実施形態の動作が図５で述べられる。アプリケーションがゲートウェイに一旦出現すれば（Ｓ５１）、あらかじめ最適化された、若しくは、デフォルトの、ルーティング構造がデータを収集するために用いられる（Ｓ５２）。但し、ノードｊは、それぞれ、目的関数Ｆの実行によりその次のホップ中継を改善する確率ｐを持つ（Ｓ５３）。ローカルの問合せメッセージが、そのレイヤＩＤを備えたローカル領域でブロードキャストされ（Ｓ５４）、同じ若しくはより低いレイヤＩＤを持つ、その１ホップ隣の候補だけが、ノードバッテリーエネルギーレベルと共にその入トラヒックおよび出トラヒック情報からなる報告メッセージで問い合わせに返答するであろう。トラヒックタイプ毎に、候補ノードはＦによってランク付けられ、最高の順位を持つものが対応するトラヒックを中継するために選択される（Ｓ５５）。

Ｆを実行する頻度は、確率ｐによって決まる。但し、ノードｊで生成されるデータがない場合、または、ノードｊによって中継されるデータがない場合には、ｐは０となる。しかしながら、新しいトラヒックがノードｊに出現する場合には、この処理は続行される。

通信ループは、例えば、トラヒック輻輳、パケット損失（Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ満了による）、ループメッセージの繰り返し処理および伝送による追加のエネルギー消費のなどの多くの問題をマルチホップＭ２Ｍネットワークに引き起こす可能性がある。故に、この問題を解決するために、資格のある隣接ノードだけがこの問い合わせに答えることができるよう、返答制約がローカルの問合せメッセージに加えられ得る。

Ｔｉｍｅ−Ｔｏ−Ｇｏ−Ｆｏｒｗａｒｄ（ＴＴＧＦ）量が定義される。これは、意図されたシンクへのネットワークの外側のレイヤからの通信の全体的な進展を強いるカウントを表わす整数値である。以下のアプローチにおけるこの量の使用は、ＴＴＧＦがどのようにこの進展に影響するかを例証するだろう。

この実施形態では、問合せメッセージを生成する目的ノードに対して３つの規則が規定される。

１． もし他の資格のある候補を見つけることができれば、目的ノードにいかなるアプリケーショントラヒックを送ったいかなる親ノードも、対応するトラヒックについての候補になりえない。

２． もし他の資格のある候補が見つけることができれば、目的のノードと比較して上位のレイヤＩＤを備えたいかなるノードも、候補として選択できない。

３． Ｔｉｍｅ−Ｔｏ−Ｇｏ−Ｆｏｒｗａｒｄ（ＴＴＧＦ）カウントが経過した時には、もし見つけることのできた他の資格のある候補があるならば、下位レイヤＩＤを備えたノードだけが次ホップ候補であり得る。

読者によって理解されるように、ＴＴＧＦ量の使用法は、Ｔｉｍｅ ｔｏ Ｌｉｖｅ（ＴＴＬ）（問合せメッセージのヘッダに加えられるビット）の概念に似ている。要するに、送信側が受信側と同じ若しくは受信側よりも下位のレイヤＩＤを持っている場合には、ＴＴＧＦカウントは１だけ減じられる。異なるＴＴＧＦ値を備えた多数のメッセージが単一のメッセージへとアグリゲートされる場合には、最小のＴＴＧＦ値がデータアグリゲーション後に使用される。成功した転送中継伝送（上位レイヤ→下位レイヤー）がなされた場合に、ＴＴＧＦ値はデフォルトに（しばしば正整数として）セットされる。

第１のノード（１の印が付けられている）が様々な他のノード（２〜６の印が付けられている）およびそこから基地局またはゲートウェイへと通信している、上記アプローチの動作例が図６（それはネットワークの一部を示す）に図示される。

３つのイベントがイベント（ａ），（ｂ）および（ｃ）として認定される。イベント（ａ）は、ノード１からノード４までの通信、そしてどのノードを前方への伝送に使用するべきかに関しての決定を含む。イベント（ａ）は、レイヤ３からレイヤ２までの伝送を表わす。示されるように、次のホップはノード２、３、５および６のうちのいずれへの通信も含むことができる。

故に、ＴＴＧＦは、デフォルト（この場合、デフォルト＝１）に設定され、同じまたは下位のレイヤ内のすべての１ホップ隣接ノードが次ホップ候補となり得る。

イベント（ｂ）は、ノード２からノード４までの通信を含む。この場合には、ＴＴＧＦ値が目的ノードで１だけ減じられた後も、それは０より大きい。したがって、同じレイヤの中の隣接ノードは、次のホップ選択に対してまだ資格がある。故に、ノード２（それはイベント（ｂ）の親ノードである）とは別に、ノード３、５および６が次のホップ中継となるために競合するだろう。

最後に、イベント（ｃ）は、ＴＴＧＦが１に設定されており、ノード３からノード４までのホップを含む。ケース（ｃ）のＴＴＧＦはノード４で０になるので、下位レイヤＩＤを備えたノード（ノード５および６）だけが、候補選択および問合せメッセージを中継することの資格がある。

したがって、ＴＴＧＦを用いることによって、特定のホップにおいて、シンクへのいかなる「クローザー」へも転送されていないメッセージも、次ホップ候補として下位レイヤノードを選択することでそのようにすることを強いられる。その間に、ループメッセージを廃棄できるように例えばＴＴＬなどの他のメカニズムも使用することができる。

ここに記述される実施形態は、分散コンピューティングおよびロードバランシング技術の統合によってネットワーク寿命を改善する可能性を提示する。

分散処理とデータアグリゲーションにより、通信メッセージの総数は相当に削減され、そして制限のあるエネルギー資源を節約する。さらに、動的なトラヒックフローおよび残存ノードエネルギーレベルを考慮することによる、バランスのとれたルーティング決定は、ボトルネックノードへの大量のトラヒックの転送を回避できる。したがって、より長いネットワーク寿命を達成することができる。

独立したルーティング決定が、ゴシッピングをするローカルメッセージを使用して、各ノードによって下される。したがって、それはネットワーク力学に対してロバストであり、大規模ネットワークへ拡張可能でもある。

上に記述された実施形態（これは、「コンテンツ中心かつロードバランシング認識型の動的なデータアグリゲーション」（ＣＬＡＤＡ）と以下では呼ばれる）は、シミュレーションを介して評価できると共に、あらかじめ最適化されているが静的なツリートポロジ（ＳＴｒｅｅ）および従来の集中処理方法（Ｃｅｎｔｒａｌ）（ここでは、シンクだけがデータを処理する）と比較できる。

重み係数βの影響が、これから論じられるだろう。図７は、記述された実施形態に従って動作する典型的なネットワークについて、ネットワーク寿命に対するβの影響を示すグラフを図示する。図に示すように、βのより大きな値は目的関数を計算する際にローカルの寿命利得により大きな重みを適用する。これは、結果的にボトルネックノードに対する目的関数の出力のより小さな値をもたらす。故に、これは、ボトルネックノードへの通信のさらなる割り当ての回避に向かう傾向を生み出すであろうし、さもなければローカルの寿命を短くするだろう。但し、観察できるように、βの値のある限界の上では、βを増加させるインパクトは著しく小さくなる。

図８は様々なネットワーク規模に対してネットワーク寿命を延長する際のアルゴリズムの性能を示す。ノード密度は同じ（０．００２５のノード／ｍ^２）である。ネットワーク幅が１００メートルまで増加する場合、これは最も遠い領域の中のノードにとってシンクに到着するのに約３―４個のホップを必要とする。ＣＬＡＤＡが、ＳＴｒｅｅと比較して約３０％のネットワーク寿命改善を得ていて、かつ、Ｃｅｎｔｒａｌアプローチより４倍以上良好であることが観察され得る。ネットワークのサイズがさらに増加する場合、これらの性能ギャップはさらに大きくなる。

図９では、処理、フラッシュにおけるデータの読み書き、通信および総コストの、ラウンドあたりの総エネルギー消費量が図示される。ネットワーク幅は、同じノード密度で２００メートルに設定される。通信部分が総エネルギー消費量を左右することが注目されるだろう。故に、分散処理を利用して通信データ量を削減することによって、ＣＬＡＤＡおよびＳＴｒｅｅは、Ｃｅｎｔｒａｌ法と比較して、通信に費やされるエネルギー消費量のほぼ７５％を節約する。更に、処理コストは小さすぎるので、差を知らせることができない。ラウンドあたりの処理コストが以下に列挙され、ここではＣＬＡＤＡおよびＳＴｒｅｅが分散処理のために９２．１μＪおよび９２．５μＪをそれぞれ費やしており、その一方でＣｅｎｔｒａｌアプローチは、ＣＬＡＤＡとＳＴｒｅｅと比較してわずかに半分の処理コスト（４２．１μＪ）に関わる、はるかに少数の計算イベントを持つ。しかしながら、処理の差は通信部分と比較して無視できる。

図１０は、ノード残存エネルギーレベルの変動係数を示す。より大きな値は、より貧弱なロードバランシングを暗示する、ノード残存エネルギーレベルのより大きな変動を表わす。記述されたＣＬＡＤＡが、ＳＴｒｅｅおよびＣｅｎｔｒａｌの両方に比べてロードバランシングの点でより良好なパフォーマンスを持つことを観察することができる。さらに、シミュレーション時間が進むと、ソースノードから生成される生データは変化し（例えば、新たなアプリケーションの出現または古いアプリケーションの終了）、トラヒックフローの力学をもたらす。ＣＬＡＤＡを使用するノードは、ローカルトラヒックパターンの監視することでそのルーティングを改善することができるので、通信トラヒックに相当な変化が起こった場合に、当該ノードは後の段階でＳＴｒｅｅに対してより良好なパフォーマンスを示す。

図１１〜図１４では、ＣＬＡＤＡおよびＣｅｎｔｒａｌのトラヒックマップおよび残存エネルギーマップについて視覚化された比較が提供される。図１１および図１２のトラヒックマップにおける線幅はそのリンクを介してどれだけのデータが流れているか表わし、その一方で図１３および図１４のエネルギーマップにおけるドット・サイズは対応するノードバッテリーエネルギーレベルを示す。ＣＬＡＤＡと比較して、Ｃｅｎｔｒａｌアプローチにはるかに大量の通信トラヒックがあることが理解できる。さらに、シンクにより近いエリアの中のノードが外側の領域にあるノードのために情報を中継する必要があるので、Ｃｅｎｔｒａｌ法のネットワークの中心に大きなトラヒックレベルを観察することができる。これは、ホットスポット問題を容易く引き起こす可能性がある。対照的に、ＣＬＡＤＡは、アグリゲーション後に、はるかに少ない通信データ量を持つ。更に、残存エネルギーマップを観察することによって、ＣＬＡＤＡが、より多くのエネルギーを節約し、かつ、よりバランスのとれたエネルギー消費にすることを、さらに観察できる。

ＣＬＡＤＡは、関連データをアグリゲートし、そして処理利得を増加させることによって、通信トラヒックを削減するために、使用することができる。ＣＬＡＤＡは、不均一のノード残存エネルギーレベルを考慮に入れて隣接のノードの間でのエネルギー消費のバランスをとるのを支援してもよく、これはホットスポットノードの早期のエネルギー枯渇を回避する。但し、ＣＬＡＤＡは、通信リンク品質を考慮せず、完全なチャンネル状態を仮定する。いくつかの状況では、貧弱な通信リンク上でパケットを送ることは、パケット損失による追加の再送信でエネルギーを浪費するかもしれない。故に、通信信頼度もさらに考慮に入れることが望ましいかもしれない。もちろん、マルチホップ無線Ｍ２Ｍネットワークにおける、エネルギー効率および通信信頼度は、それら自身相反する目的を提示するかもしれない。すなわち、無線伝送でのエネルギーを節約するために最も大きなトラヒック削減量を提供するルートは、通信信頼度の目的のための理想的な候補ではないかもしれない。

図１５は、これらの様々な考慮がルーティングトポロジにもたらし得るインパクトの例を提供する。図１５（ａ）はネットワーク機構を示しており、これは６つのノードおよび１つのゲートウェイノード（Ｇのラベルを付けられている）によって形成される。ここで、ソースノード１、２、３（Ｓの印が付けられている）からゲートウェイノード（Ｇ）へとトラヒックを送ることが意図される。ネットワーク中の各ノード・ペア間のラインは通信リンクを示す。破線として引かれたラインは、信頼性の低いリンクを表すために用いられる。これらのリンクは、例えば、それらのノード間の障害の存在により、または、他の干渉源により、信頼性が低いかもしれない。

図１５（ｂ）は、唯一の考慮が通信信頼度である場合に採用されるルーティングトポロジを示す。図１５（ｃ）は、唯一の考慮がトラヒック削減によるエネルギー節約である場合に採用されるルーティングトポロジを示す。図１５（ｄ）は、ルーティングトポロジを構築する際にエネルギー効率および通信信頼度の両方が考慮に入れられる例を示す。

図示されるように、図１５（ｂ）のルーティングトポロジは、図１５（ｃ）および図１５（ｄ）に示されるルーティングトポロジと比べて大きなトラヒック量を持つ。対照的に、効率的なデータアグリゲーションのおかげで、図１５（ｃ）に例証されるネットワークは最小のトラヒック量を持つ。

但し、この場合に、トラヒックは、２つの信頼性の低い通信リンク（すなわち、それぞれ、ノード１から５までおよびノード３から５まで）上で絶えず送られる。これは、例えばパケット損失などの問題、さらには、ノード１および３からノード５へとデータを再送信するための追加のエネルギーを消費する必要性をもたらすかもしれない。図１５（ｄ）は、データが信頼できるリンクを介して、当該データをアグリゲートできる適切なノードへと転送されるソリューションを示す。従って、エネルギー効率、処理効率および通信信頼度の間のバランスを見つけ出す、インテリジェントなアルゴリズムを提供することが望ましい、ということになる。

ルーティング決定を下す際にローカルネットワーク寿命を適切に推定するためにチャンネル／リンク品質が明示的に考慮される、さらなる実施形態がこれから述べられるだろう。この実施形態では、コンテンツ中心データアグリゲーションによるトラヒック削減利得を考慮するだけでなく、信頼できる通信リンク上に各通信単位（例えばパケット）をルーティングすることを目的とした、変形された目的関数が導入される。故に、低いパケットドロップ率および長期のネットワーク寿命を達成することができる。さらに、単純であるが効果的な通信ループ制御方式が、分散処理を促進し、かつ、トラヒック削減により通信で費やされるエネルギーを節約するために提案される。

本実施形態は、ネットワーク寿命を相当に延長できる、効率的なデータアグリゲーションおよび信頼できる配信方式を提供し、それによって、ネットワークメンテナンスの節約を提供すると共にノード再配備のコストを減らす。ここに記述されたアルゴリズムは、例えば、無線アドホック、センサネットワークなどのデータ収集の目的のための広範囲の無線ネットワークにおいて実装することができる。

現在記述された実施形態の主な目的は、信頼できる通信リンク上に、オーバーレイされたコンテンツ中心データアグリゲーショントポロジを構築し、損失のある無線ネットワークにおける様々なタイプのデータを効率的にルーティングおよび処理するために各コンテンツ情報フローおよび通信トポロジを最適化することである。

本実施形態は前に記述された実施形態の論理的な拡張であって、リンク品質認識型コンテンツ中心データアグリゲーション（ＬＡＣＤＡ）とここでは呼ばれる。以下に論じられるように、本実施形態は、リンク品質認識型のローカルの寿命推定、コンテンツおよびコンテキスト認識型の動的な目的関数実行確率、ならびに、通信ループを回避する次ホップ候補選択メカニズムを備えた、新しい目的関数を導入する。

ＬＡＣＤＡは分散型アプローチであって、その動作は以下のように説明される。アプリケーション要求がゲートウェイに一旦出現すれば、デフォルトルーティング構造（例えば、ＤＡＧトポロジを形成するＲＰＬ）がデータを収集するために最初に使用される。それから、各ノードは、目的関数Ｆを実行することによってその次のホップ中継を改善する動的な確率ｐを持つ。

図１６は、目的ノード（すなわち、目的関数Ｆを実行することを意図するノード）とそのそれぞれの隣接のノードとの間で交換されるメッセージ信号の系列の例を示す。ステップＳ１６１では、目的ノードは、その１ホップ隣のノードへと、ローカル問合せメッセージをブロードキャストする。問合せメッセージは、目的ノードの出トラヒックコンテンツタイプおよび対応するトラヒック量、ならびに、候補選択基準（例えば、後ほど記述されるＴＴＧＦビット）を含む。資格のある次ホップ候補は、それぞれのＡＣＫメッセージで目的ノードに応答する（ステップＳ１６２）。ＡＣＫメッセージはそれぞれ、例えば、応答機のＩＤ、指定のトラヒックがそのノードに送られる場合の応答機の推定ノード寿命などＦによって必要とされる情報を含んでいる。目的ノードは、隣接ノード毎に目的関数を計算するために、ＡＣＫメッセージで含まれる情報を使用できる。そのようにしている間に、目的ノードは、様々なノードの候補ランキングを制定し、対応するトラヒックを中継するために最高の順位を持つノードを選択する。ステップＳ１６３では、対応するトラヒックを中継するノードが選択されていて、目的ノードは、ルーティングテーブルを更新し、そのトラヒックコンテンツのための新たな次ホップノードＩＤを含むルーティング更新告知メッセージをブロードキャストする。以前の中継ノードはＬＥＡＶＥ ＡＣＫメッセージ送信し（ステップＳ１６４）、その一方で新たな次ホップノードはＪＯＩＮ ＡＣＫメッセージで返答する（ステップＳ１６５）。このように、多数のトラヒックコンテンツタイプのための、オーバーレイされたツリートポロジを動的に更新することができる。

動的なネットワーク環境では、ほとんどのルーティングプロトコルは、定期的にそれらのルーティング情報を更新し、ルーティングテーブルを最新にしておく。但し、そのようにすることは、追加の制御オーバーヘッドを招く。例えば低電力かつ損失のあるネットワークなどのリソースを制約されたネットワークでは、シグナリングメッセージは、制限のある内蔵ノードエネルギーを節約するために制御されるべきである。現在の実施形態において、時間ｔで目的関数を実行する頻度は、確率ｐ（ｔ）によって制御される。確率は、各ノード上で独立して計算され、ローカルまたはグローバルなネットワーク情報を必要としない。確率ｐ（ｔ）は以下の数式４で定義される。

ここで、Δ_ｋは、時間ラウンド（「ラウンド」は基本的な時間単位である）での各ノードのトラヒックコンテンツ変動である。ｔは現在の時間インターバルであって、ｔ_１はノードが目的関数を実行した最後の時間インターバルを示し、Ｐ_{ｄｅｆａｕｌｔ}はあらかじめ最適化された確率である。図１７は、Δ_ｋが様々な時間インターバルでどのよう計算され得るかの例を示す。

図１８は、どのように、目的ノードが所与の時間インターバルｔで目的関数を実行するかどうかを当該時間インターバルでのｐ（ｔ）の値がどのように決めるかを例証するフローチャートを示す。トラヒックコンテンツ変動によりΔ_ｋの大きな値がもたらされる場合に、目的関数を実行する確率は増加する。他方、ネットワークが安定し、かつ、Δ_ｋが小さい場合には、確率ｐは減少する。変化が生じない場合、確率ｐは０にまで達するかもしれない。それは、効果的に制御オーバーヘッドを削減する。ノードが十分に長期の期間にわたって目的関数を実行しないならば、小さなコンテンツ変動の蓄積もまた、時間と共にｐの値の増加をもたらし、いつかはノードが目的関数を実行するトリガとなることができる。これが一旦起これば、ｔ_１はｔに設定され、ｐ（ｔ）はｐ_{ｄｅｆａｕｌｔ}に再設定される。そのようにすることは、ゆっくり変わる環境においてさえも、ルーティングテーブルが絶えず最新にしておかれることを保証する。以上のように、目的関数を実行する確率は、安定したネットワークでは、動的に変化するネットワークと比較してはるかに低い。

本実施形態では、目的関数Ｆは、Ｎ個の隣接候補の中でトラヒックタイプ（コンテンツ）ｋ毎に最もふさわしい次ホップノードｊを見つけ出すために、目的ノードｉで実行される。トラヒックはそのコンテンツタイプによって区別されるので、目的ノードは目的関数を実行することによりコンテンツｋ毎に異なるルーティングテーブルを構築するかもしれない。

新しい目的関数Ｆが数式５で述べられている。それは、ＣＬＡＤＡの実施形態の数式１で示される関数に基づいている。

ＣＬＡＤＡの実施形態と同様に、第１項ｇ_ｊ’−ｇ_ｊ’’は先に定義された処理利得であり、βは重み付けパラメータである。この新しい目的関数について２つの主な差異がある。それは、リンク品質認識型のローカルネットワーク寿命推定および新たな報酬パラメータξ_ｊ ^ｋである。これらは、両方とも以下に詳細に論じられるだろう。

報酬パラメータξ_ｊ ^ｋはノードの不均一な処理能力を調節するために導入される。あるノードは例えば、ハードウェアまたはソフトウェアの制約により、特定のタイプのコンテンツを処理することができるに過ぎないかもしれず、その一方で他のノードはいかなるタイプのデータも処理することができないかもしれない。そのような場合に、ノードは、単に、受信データを処理しない中継器の役割を果たす。報酬パラメータξ_ｊ ^ｋは対応するコンテンツｋを処理できるノードｊに追加の信用を与えるために用いられる。報酬パラメータの値は以下のように定義される。

ξ_ｊ ^ｋ＝０ （ノードｊがトラヒックコンテンツｋを処理することができない場合）
ξ_ｊ ^ｋ＝σ （ノードｊがトラヒックコンテンツｋを処理することができる場合（σは定数である））
コンテンツｋを処理できるノードｊへとトラヒックｋをルーティングすることがトラヒックｋの量を削減する場合には、Ｆにおける限界処理利得は当該ノードｊに信用を既に与えていると、当業者は理解するだろう。従って、報酬パラメータξ_ｊ ^ｋがない状態でさえ、トラヒックは、単にそれを中継することに加えてデータを処理することができるノードへと転送される可能性が高い。しかしながら、ノードｊがコンテンツｋを処理する能力を持っているもののｊを介してルーティングされた他のトラヒックｋが現在ない場合には、トラヒック削減がないので処理利得は０である。この場合に、報酬パラメータは、トラヒックが、それでもなおそのノードｊに転送されることを保証するのを支援することができる。

図１９は、そのようにすることによって達成された限界処理利得がそれほど大きくない場合にさえ、データが当該データを処理する能力を持つノードへと優先的に転送されることを報酬パラメータがどのように保証できるかの例を提供する。図１９（ａ）は、目的ノード３が１０００ビットのトラヒックコンテンツｋをゲートウェイノードＧへと送ることを望む状況を示す。目的ノードは、２つの中継ノード２および４のうちの１つを介してデータを送るという選択肢を持つ。これらのノードのうち１つであるノード２は、コンテンツｋを処理できる（すなわち、ノード２は、中継に必要な総ビット数を削減するために、そのタイプのトラヒックコンテンツを他のノードから受信された同様のコンテンツとアグリゲートできる）。この理由により、ノード２はパラメータξ＝０．０５を割り当てられる。対照的に、他のノード４は、トラヒックコンテンツｋを中継することができるだけであって、そのデータを他のノードから受信された類似データとアグリゲートする設備を持たない。従って、ノード４の報酬パラメータは０に設定される。図１９（ａ）に示されるように、ノード２は、目的ノードとは無関係に、別のノード１から１０００ビットのトラヒックコンテンツｋを現在受信している。

目的ノード３は、２つのノード２および４のどちらがゲートウェイノードへのトラヒックを中継するために使用されるべきかを判定するために目的関数を実行できる。数式５を用いて、目的ノードは、ノード２の関数Ｆ_２を以下のように計算するだろう。

（簡単にするために、上記例では、リンク品質認識型のローカルネットワーク寿命推定が考慮から省かれる点に注意されたい。）
同様に、ノード４の目的関数Ｆ_４は、以下のように決めることができる。

この例では、ノード２は、報酬パラメータがない状態でさえ、次ホップノードとしてそれでもなお選択されるだろう。

ノード２が他のノードからデータをもはや受信していないという例外を除いて図１９（ａ）と同様の状況を示す図１９（ｂ）に対して、同じ計算を行なうこともできる。この場合、目的関数Ｆ_２およびＦ_４は以下の値を返す。

この場合、報酬パラメータξがない状態では、Ｆ_２およびＦ_４の両方が０という同じ結果を返すだろう。ξという報酬パラメータをノード２に割り当てることによって、データｋが将来に処理またはアグリゲートされる可能性のある場合に、目的ノードがノード２にそれでもなお当該データｋを送ることを保証することが可能である。したがって、σの値はＦの中の他のパラメータと比較して相対的に小さくなり得るが、それはくだんの特定タイプのコンテンツを処理できるノードへとトラヒックを転送するためのバイアスを提供する。

リンク品質認識型のローカル寿命推定
無線通信リンクの動的な性質により、様々なリンク品質推定方法がある。例えば、ＥＴＸ（ｅｘｐｅｃｔｅｄ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｕｎｔ）は、例えばＲＰＬなどの多くのルーティングプロトコルにおいて用いられるポピュラーなリンク品質／信頼性パラメータである。本質的には、ＥＴＸは、宛先に首尾良くメッセージを送達するために送信側に必要とされる平均伝送回数を定義する。ＳＮＲがしきい値より高くさえあればパケット成功率は実際のＳＮＲ値にかかわらず高いままであろうこと、ならびに、ＳＮＲがしきい値より低ければパケット成功率は徹底的に低下するであろうことが、示される可能性がある。

リンクのＥＴＸ値は、当該リンクを介してのパケットあたりの伝送に費やされるエネルギーの平均量へとたやすく変換することができる。このように、ＥＴＸは通信リンク品質を評価するために使用することができ、そしてそれはローカルネットワーク寿命を推定するのを支援するために使用することができる。当業者は、本実施形態はその計算にＥＴＸを利用するものの、推定関数への単純な変形により他のリンク品質測定技法を適用することができることを認識するだろう。

以下に、数式５の中のローカル寿命利得パラメータ（ｌ＾_ｊ―ｌ_ｊ＊）／ｌ＾_ｊが説明される。ここで、ｌ_ｊ＊は、目的ノードｉおよびそのＮ個の次ホップ候補の間の現在のローカルネットワーク寿命であって、ｊ^＊は現在選択されている次ホップノードである。ｌ＾_ｊは、コンテンツトラヒックがｊ^＊ではなく新たな候補ｊへと転送されると仮定する、推定されたローカルネットワーク寿命である。

ローカルの寿命は、目的ノードｉおよびそのＮ個の資格のある隣接候補ノードの中の最短のノード寿命として定義される。故に、ｌ＾_ｊは次のように計算することができる。

ここで、Ｅ_ｉおよびＥ_ｊは、それぞれ目的ノードおよび候補ノードの現在のバッテリーエネルギーであって、ｅ＾_ｊとｅ＾_ｉはノードｊがトラヒックｋを中継する次ホップノードとして選択される場合の当該２つのノードの推定エネルギー消費量である。推定エネルギー消費量は、例えば、処理コストおよびデータの送受信コストの両方を考慮に入れてよい。

トラヒックｋを現在の次ホップノードｊ^＊から候補ノードｊへと切り替えることによって、目的ノードの新たな推定エネルギー消費量ｅ＾_ｉがその現在のエネルギーコストｅ_ｉ ^＊に基づいて計算することができる（数式６）。

ここで、ＥＴＸ_ｉ ^ｊ＊およびＥＴＸ_ｉ ^ｊは、ノードｉからノードｊ^＊までの現在のリンクおよびノードｉからノードｊまでの新しいリンクのＥＴＸ値をそれぞれ表わす。本実施形態は、分散型アプローチを用いて１ホップ隣だけを考慮するので、ＥＴＸ値もまた１ホップベースである。値Ｕは、トラヒックコンテンツタイプｋについてノードｉによって送られたデータの（ビット単位での）総量であって、ｅ_ｔは１ビットのデータを送信するエネルギー消費量である。

同様に、ｊ^＊を除いて各候補ノードの推定エネルギー消費量ｅ＾_ｊは、以下ように計算することができる。

ここで、ｅ_ｒおよびｅ_ｐは、それぞれ１ビットのデータの受信および処理に伴うエネルギー消費量である。Ｕ_ｐは、ノードｊがその次ホップノードへと送らなければならない、処理後の追加データ量である。ノードｊがコンテンツｋを処理できなければ、Ｕ_ｐ＝Ｕとなる。

候補選択およびループ回避
通信ループは、マルチホップネットワークにおいていくつかの問題（例えば、トラヒック輻輳、パケット損失（Ｔｉｍｅ ｔｏ Ｌｉｖｅ満了による）、ループするメッセージを繰り返し処理および伝送する際に消費される追加のエネルギーなど）を引き起こす場合がある。

ＲＰＬでは、通信ループを検知するためにメッセージヘッダが用いられる。本質的には、ＲＰＬは、メッセージが根へと「上方に」送ることになっているならば、当該メッセージを子ノードへと「下方に」ルーティングすることを許可しない。ループが検知された場合、メッセージは廃棄され、ローカル修復が行なわれる。しかしながら、そのようなループ回避方式は、次のホップ中継器として選択されることになる隣接ノードの数を制限する。従って、これは、分散処理を行う見込み、ならびに、ネットワークトラヒック量を削減する見込みを制限する。対照的に、ＴＴＧＦ許容範囲内でより高い処理利得を達成することができるならば、ＬＡＣＤＡアプローチは逆のトラヒックを許可する。

ＬＡＣＤＡアプローチと従来のＲＰＬ方式との間の差は、図２０（ａ）および２０（ｂ）を比較することによって理解できる。図２０（ａ）は、ＲＰＬにおいて用いられるループ回避方式を示す。それは、逆のトラヒックを許可しない。図２０（ａ）を参照すると、データがレイヤｉ＋１の中の第１のノード２から下位レイヤｉの中の第２のノード３へと一旦送信されれば、データは、オリジナルのレイヤｉ＋１の中の第３のノード１が所有し得るいかなる処理能力にもかかわらず、当該ノード１を介して中継することができない。図２０（ｂ）は、逆のトラヒックが許可されるかもしれない、ＬＡＣＤＡによって用いられるアプローチを示す。ここで、ノード１によってデータを処理することが全体的なトラヒック量を削減するであろうことが認識される。したがって、第２のレイヤｉの中のノード３は、上位レイヤｉ＋１の中のノード１を介してのデータを中継することを許可される。

本実施形態では、ローカル問合せメッセージに返答し、かつ、通信ループを回避する候補ノードとして適切な隣接ノードを選択するために、Ｔｉｍｅ−Ｔｏ−Ｇｏ−Ｆｏｒｗａｒｄ（ＴＴＧＦ）制約が再定義される。前に論じられたように、ＴＴＧＦは、データパケットのヘッダに加えることができるＴｉｍｅ ｔｏ Ｌｉｖｅ（ＴＴＬ）バイトと同様の概念である。

ＴＴＧＦはノードレイヤＩＤと共に機能する。それは、シンクへと到着するためにノード毎に必要とされる最小ホップ数を表わす。ＴＴＧＦは２つのパラメータ：（１）ＴＴＧＦレイヤＩＤおよび（２）ＴＴＧＦカウントを含む。ＴＴＧＦレイヤＩＤは、メッセージが到着した最低のノードレイヤＩＤを指し示すポインタである。シンクへより近づくようにメッセージを転送する場合に、ＴＴＧＦレイヤＩＤは更新される。成功の順伝送がなされる（すなわち、現在／受側ノードレイヤＩＤ＜ＴＴＧＦレイヤＩＤ）ならば、ＴＴＧＦレイヤＩＤの値は現在のノードレイヤＩＤを反映するように更新される。ＴＴＧＦカウントは、候補ノードの選択をシンクへより接近して位置するノードへとバイアスをかける「カウントダウン」パラメータとして機能する。メッセージがＴＴＧＦレイヤＩＤに比べて同じかより高いノードレイヤＩＤを持つ受側ノードに転送される場合に、ＴＴＧＦカウントは１だけ減じられる。ＴＴＧＦカウントが０に一旦達すれば、目的ノードのレイヤＩＤと比べて下位のレイヤＩＤを持つノードだけが、次ホップ候補として選ぶことができる。ＴＴＧＦレイヤＩＤが更新されるごとに、ＴＴＧＦカウントはデフォルトにリセットされる。

したがって、変形されたＴＴＧＦプロトコルは、データをアグリゲーストするために適切な処理ノードがデータが見つけられるように、ある許容値内で同じまたはさらに高い深度のネットワークレイヤの中のノードへとメッセージが中継されることを許可する。他方、いくらかの中継ホップの後に、メッセージがシンクへのいかなる「クローザー(closer)」にもまだなお来ていなければ、カウントダウンパラメータの減少が、目的ノードに次ホップ候補として下位レイヤの中のノードを選択することを強いる。

ＴＴＧＦプロトコルが実際にどのように動作し得るかの一例が図２１に示される。この図では、ネットワークはノード１〜６およびゲートウェイＧを含む。ノード１はネットワークのレイヤ３に位置し、ノード２、３および４はレイヤ２に位置し、ノード５および６はレイヤ１に位置する。図に示されるように、ノード１および２は、ネットワークのレイヤ２に位置しているノード４に、それぞれのメッセージａ、ｂを送信する。それぞれの場合において、ノード４は、その隣接ノードのうちどれがゲートウェイＧへのメッセージの中継のための最良の候補を提供するかを判定するために、目的関数を実行するだろう。

図に示すように、メッセージａについて、ＴＴＧＦレイヤＩＤは、ノード１がネットワークのレイヤ３に位置するという事実を反映して、最初に３に設定される。メッセージｂについて、ノード２がネットワークのレイヤ２に位置するので、ＴＴＧＦレイヤＩＤは最初に２に設定される。この例では、両方のメッセージについてＴＴＧＦカウントは、１に最初に設定される。

目的ノード４への到着時に、レイヤ３からレイヤ２に変化を反映して、メッセージａのＴＴＧＦレイヤＩＤが２に更新される。ＴＴＧＦレイヤＩＤが減じられるので、ＴＴＧＦカウントはデフォルトにリセットされる。それは、通常０より大きな正整数である。この場合では、１ホップ隣接ノード２、３、５および６のうちのいずれか１つが、ノード４の次ホップ候補として考慮され得る。

メッセージｂについて、ＴＴＧＦレイヤＩＤはノード２からノード４までの伝送では同じままである。故に、ＴＴＧＦカウントは、０まで１だけ減じられる。結果として、下位レイヤＩＤを備えたノード（ノード５および６）だけが、候補選択について資格を得て、目的ノード４によって送られた問合せメッセージに返答するだろう。

従来手法と共に提案されたアルゴリズムの性能を評価するために、シミュレーションが実行された。別段の定めがない限り、ノードは、０．００５ノード／ｍ^２のノード密度でネットワークエリア内に一様に分布させられた。ゲートウェイノードはネットワークエリアの中心に配置された。不均一なトラヒック速度を備えた３つのアプリケーションが仮定された。アプリケーションは、それぞれ同じ出現確率０．０５を持っているが、１００―２００ラウンド（ラウンドはシミュレーションに使用される基本的な時間単位である）の間で無作為に選ばれた動作存続時間を備えていた。ノードは、開始時間に４―６Ｊの範囲で一様でないエネルギーレベルを持つと仮定された。ＴＴＧＦカウントは２に設定され、制御パケットサイズは５００ビットであると仮定された。

これらのシミュレーションでは、提案されたアルゴリズムＬＡＣＤＡおよびＣＬＡＤＡの両方が、静的であるがあらかじめ最適化された最大寿命ツリートポロジ「Ｓｔａｔｉｃ Ｔｒｅｅ」および分散処理のない集中処理メカニズム「Ｃｅｎｔｒａｌ」と比較された。図２２は、ネットワーク寿命を延長するという点でのアルゴリズムの性能を示す。ネットワーク内のいくらかのノードがエネルギー備蓄量を減らし、リンク接続が分割して完全なネットワークカバレッジを提供しなくなり始めるまでの期間である、テストパラメータＮＰＬ（Ｎｅｔｗｏｒｋ Ｐａｒｔｉｔｉｏｎ Ｐａｒａｍｅｔｅｒ）が定義される。図２２に示されるように、ＣＬＡＤＡとＬＡＣＤＡの両方のアルゴリズムは、従来のＳｔａｔｉｃ ＴｒｅｅおよびＣｅｎｔｒａｌアルゴリズムと比較して、ネットワーク寿命に相当の増加を提供する。

図２３は、それぞれのアプローチの再送信でラウンドあたりに費やされたエネルギー消費量を示す。図に示すように、ＬＡＣＤＡアルゴリズム２３１は、再送信について最小の平均エネルギー消費量を持つので、最良のパフォーマンスを提供する。Ｓｔａｔｉｃ Ｔｒｅｅアプローチ２３３あるいはＣｅｎｔｒａｌアプローチ２３４のいずれかと比較すれば、ＣＬＡＤＡアルゴリズム２３２もまた再送信で費やされた平均エネルギーに相当の削減を提供する。すなわち、より信頼できるルーティングトポロジが形成される。

図２４は、ＣＬＡＤＡおよびＬＡＣＤＡアプローチの間の比較を提供する。図２４（ｂ）および２４（ｃ）は、図２４（ａ）に示される初期のトラヒックの程度と比べて、５０ラウンド時間の後のそれぞれのアプローチのネットワークトラヒックの程度を示す。図２４は、ＣＬＡＤＡとＬＡＣＤＡの両方が、初期のネットワークトラヒックと比較して、データアグリゲーションを通じてトラヒックに削減を達成することを実証する（とはいえ、ＬＡＣＤＡは、より少ない量のトラヒックが信頼性の低いリンクを介しての送られることをも保証するが）。

最後に、図２５のテーブルは、ＬＡＣＤＡ方式において計画的なループ回避メカニズムＴＴＧＦを使用する利益を示す。ＴＴＧＦが０に設定される場合に、目的のノードと比べて下位レイヤＩＤを備えたノードだけが次ホップ候補になり得る。それは、起こり得るデータアグリゲーションの見込みを相当に減じる。ＴＴＧＦ＝０についての著しい寿命減少が、テーブルに見られる。

上記実施形態がいかなるネットワークおよび係るネットワーク内の様々な通信装置に適用可能であることを読者は認識しているかもしれないが、ここに記述された実施形態を実施することのできる手段を提供する典型的な装置が図２６に示される。図示されるように、装置１００は、マスストレージ装置１２２に連結されワーキングメモリ１２４にアクセスするプロセッサ１２０を含む。図示されるように、ユーザアプリケーション１２６および通信コントローラ１２８はワーキングメモリ１２４に格納されたソフトウェアプロダクトとして表わされるが、ユーザアプリケーション１２６および通信コントローラ１２８の要素が、便宜上、マスストレージ装置１２２に格納されてもよいことが認識されるだろう。メモリ内へのソフトウェアのローディングおよびマスストレージ装置１２２のデータ記憶のために、通常の手順が適用される。プロセッサ１２０は、バス１３０を介して、ユーザ入力装置１３６およびユーザ出力装置１３８にもアクセスする。通信部１３２は、他の装置との無線または有線の通信を達成するように動作する。

プロセッサ１２０による通信コントローラソフトウェア１２８の実行は、ここに記述される実施形態を実装する。通信コントローラソフトウェア１２８は、オリジナルの装備に埋め込むことができるし、製造後に全体としてまたは部分的に提供することもできる。例えば、通信コントローラソフトウェア１２８は、コンピュータプログラムプロダクトとして、全体として導入することができる。それは、ダウンロードの形式であるかもしれないし、例えば光ディスクなどのコンピュータープログラム記録媒体を介しての導入されることになるかもしれない。あるいは、既存の通信コントローラ１２８への変形は、上記実施形態の特徴を提供する更新またはプラグインによってなされてよい。

ここに記述された実施形態は、例えば、無線センサネットワーク、アドホックネットワーク、ボディエリアネットワーク、ＡＭＩネットワーク、Ｗｉ−Ｆｉメッシュ、ＦｌａｓｈＡｉｒおよび他のＭ２Ｍネットワークなどの、マルチポイント・トゥ・ポイント・ルーティングの目的のための幅広い無線ネットワークのいずれにおいても、おそらく実装することができる。特に、リソースを制約されたＭ２Ｍネットワークにおけるデータ収集のために、多くの不均一なセンサノードが継続的なセンシングおよびデータ収集のために用いられる。効率的なデータアグリゲーションおよび配信方式は相当にネットワーク寿命を延長することができる。故に、ここに記述される実施形態は、ネットワークメンテナンスの相当の節約およびノード再配備コストを削減する可能性を提供する。

いくつかの実施形態が記述されているが、これらの実施形態は例示のために提示されているに過ぎず、発明の範囲を制限するようには意図されない。確かに、ここに記述された新しい方法および装置は、様々な他の形式で具体化されるかもしれない。さらに、様々な省略、置換および変更が、発明の趣旨から外れることなく、ここに記述された方法および装置の形態になされてよい。添付するクレームおよびそれらの均等物は、そのような形態あるいは変形が発明の範囲および趣旨の内にあるようにカバーすることを意図される。

Claims (21)

1. 第１の通信ノードから複数の隣接候補ノードのうちのいずれか１つに通信データを送るための通信リンクを決定する方法であって、
   ｉ）候補ノード毎に、当該候補ノードにおいて通信データをアグリゲートすることを通じて得られる通信データ削減の大きさを含む限界処理利得を判定することと、
   ｉｉ）通信リンクを形成するために前記候補ノードのうちの１つを選択することと、
   ｉｉｉ）前記通信リンクのために選択されることになるノードを決定するために候補ノード毎に目的関数を評価することと
   を具備し、
   前記選択は、候補ノード毎に判定された限界処理利得に少なくとも部分的に基づいていて、
   前記限界処理利得は、ローカル寿命利得をさらに含む前記目的関数の一部であり、
   前記ローカル寿命利得は、前記候補ノードに前記通信データを割り当てることにより達成される１つ以上の隣接候補ノードの寿命の変化を定義し、
   所与の候補ノードについて前記目的関数を評価することは、
   前記通信データが前記所与の候補ノードに割り当てられた場合の、隣接候補ノードの１つ１つの寿命を推定することと、
   前記通信データが前記所与の候補ノードに割り当てられない場合の、隣接候補ノードの１つ１つの寿命を推定することと
   を含み、
   それぞれの場合に、ローカル寿命は、隣接候補ノードの中で最短の推定寿命を持つノードの寿命として定義され、
   前記所与の候補ノードについてのローカル寿命は、前記通信データが当該候補ノードに割り当てられた場合のローカル寿命と前記通信データが当該候補ノードに割り当てられない場合のローカル寿命との間の差分に基づいて判定され、
   隣接候補ノードの寿命は、当該隣接候補ノードのエネルギー消費を推定することによって推定され、
   各隣接候補ノードのエネルギー消費は、前記第１の通信ノードとそれぞれの隣接候補ノードとの間のリンク品質パラメータを定義することによって推定され、
   前記リンク品質パラメータは、データの送達の成功を保証するために前記第１の通信ノードと隣接候補ノードとの間で当該データが２回以上送信される必要がある尤度を反映する、
   方法。
2. 前記通信データ削減の大きさは正規化される、請求項１に記載の方法。
3. 候補ノードの限界処理利得は、当該候補ノードに前記通信データを割り当てた場合の処理利得の大きさと当該候補ノードに当該通信データを割り当てないとした場合の処理利得の大きさとの間の差分を含む、請求項１または請求項２に記載の方法。
4. 前記ローカル寿命利得の大きさは、前記通信データが前記候補ノードに割り当てられる場合について推定されたローカル寿命によって正規化される、請求項１に記載の方法。
5. 前記目的関数は、前記限界処理利得の大きさおよび前記ローカル寿命利得の大きさの重み付き和を含む、請求項１乃至請求項４のいずれか１項に記載の方法。
6. 前記重み付き和は、重み係数に依存し、
   前記重み係数は、前記目的関数において、ネットワーク寿命に対する感度に関して、前記限界処理利得の大きさおよび前記ローカル寿命利得の大きさの影響の平衡を保つように操作可能である、
   請求項５に記載の方法。
7. 前記リンク品質パラメータは、前記第１の通信ノードからそれぞれの隣接候補ノードへとビットデータが首尾良く送達されるために送信される必要がある平均回数を定義する、請求項１に記載の方法。
8. 候補ノード毎に、当該候補ノードに前記通信データを割り当てる場合のローカル寿命利得を判定する際に、前記第１の通信ノードの寿命が考慮に入れられる、請求項１または請求項７に記載の方法。
9. 前記通信データは複数のデータタイプを含み、
   前記方法は、データタイプ毎に、ステップｉ）およびｉｉ）を実行することを具備する、
   請求項１乃至請求項８のいずれか１項に記載の方法。
10. 各データタイプは、データを中継するために必要とされるビット数を削減するために、ノードで実行する機能または関数によりアグリゲートすることのできるデータを含む、請求項９に記載の方法。
11. 各データタイプは、環境の様々なパラメータを反映するセンサ信号を含む、請求項１０に記載の方法。
12. データタイプ毎に、前記限界処理利得は、ローカル寿命利得の大きさをさらに含む目的関数の一部であって、
    前記ローカル寿命利得は、候補ノードに特定のタイプの通信データを割り当てる場合の、１つ以上の隣接候補ノードの寿命の変化を定義し、
    前記方法は、前記特定のタイプの通信データの通信リンクのために選択されることになるノードを決定するために候補ノード毎に前記目的関数を評価することを具備する、
    請求項９乃至請求項１１のいずれか１項に記載の方法。
13. データタイプ毎に、前記目的関数は報酬パラメータを含み、
    前記報酬パラメータは、前記特定のタイプのデータをアグリゲートする能力を持つノードへと候補ノードの選択にバイアスをかける、
    請求項１２に記載の方法。
14. 前記目的関数は、いくつかのインターバルで実行され、
    前記インターバルのサイズは、前記第１の通信ノードに到着するデータタイプの変動の量に基づいて決められる、
    請求項１２または請求項１３に記載の方法。
15. いくつかのインターバルそれぞれに前記第１の通信ノードに到着する様々なデータタイプの数を監視することと、
    インターバル毎に、前のインターバルと比較しての、到着したデータタイプの数の変化を判定することと、
    前記変化に基づいて、前記目的関数が実行されるべき確率を決定することと、
    前記確率が閾値より上にあることが発見される場合に、前記目的関数を実行することと
    を具備する、請求項１４に記載の方法。
16. 前記閾値は乱数発生器から得られる、請求項１５に記載の方法。
17. 前記通信データは、通信進展因子をさらに含むデータパケットの中に含まれていて、
    前記通信進展因子は、意図された受側ノードへのネットワーク内の順通信のために候補ノードの選択を支配するために使用される、
    請求項１乃至請求項１６のいずれか１項に記載の方法。
18. 前記通信進展因子は、前記第１の通信ノードが位置するネットワークのレイヤの表示を含み、
    前記通信リンクのために候補ノードを選択する場合に、もし前記受側ノードからさらに離れたレイヤに位置する全ての隣接ノードが前記第１の通信ノードによって送信されているデータタイプにデータアグリゲーションを行なう能力を持たなければ、前記第１の通信ノードは、当該隣接ノードを候補ノードとしての考慮から除外する、
    請求項１７に記載の方法。
19. 前記通信進展因子は、前記第１の通信ノードが位置するネットワークのレイヤの表示と、カウンタとを含み、
    前記カウンタの値は、前記第１の通信ノードのレイヤと同じまたは前記受側ノードからさらに離れたレイヤの中のノードへと前記通信データが送信されるごとにインクリメントされ、
    前記カウンタの値が閾値に達する場合に、前記第１の通信ノードは、前記通信データを転送するための候補ノードとして、前記受側ノードのより近くに位置するノードだけを考慮することになる、
    請求項１７または請求項１８に記載の方法。
20. 通信装置のネットワークにおいて動作可能な通信装置であって、
    前記通信装置は、当該通信装置から複数の候補隣接装置のいずれかへの通信のための通信リンクを決定するように動作可能であり、
    前記通信装置は、
    候補ノード毎に、当該候補ノードで通信データをアグリゲートすることを通じて得られる通信データ削減の大きさを含む限界処理利得を判定するように動作可能な処理利得判定器と、
    前記通信リンクを形成するために候補ノードのうちの１つを選択するように動作可能な通信リンク選択器と、
    前記通信リンクのために選択されることになるノードを決定するために候補ノード毎に目的関数を評価する目的関数評価器と
    を具備し、
    前記選択は、候補ノード毎に判定された限界処理利得に少なくとも部分的に基づいていて、
    前記限界処理利得は、ローカル寿命利得をさらに含む前記目的関数の一部であり、
    前記ローカル寿命利得は、前記候補ノードに前記通信データを割り当てることにより達成される１つ以上の隣接候補ノードの寿命の変化を定義し、
    前記目的関数評価器が、所与の候補ノードについて前記目的関数を評価することは、
    前記目的関数評価器が、前記通信データが前記所与の候補ノードに割り当てられた場合の、隣接候補ノードの１つ１つの寿命を推定することと、
    前記目的関数評価器が、前記通信データが前記所与の候補ノードに割り当てられない場合の、隣接候補ノードの１つ１つの寿命を推定することと
    を含み、
    それぞれの場合に、ローカル寿命は、隣接候補ノードの中で最短の推定寿命を持つノードの寿命として定義され、
    前記所与の候補ノードについてのローカル寿命は、前記通信データが当該候補ノードに割り当てられた場合のローカル寿命と前記通信データが当該候補ノードに割り当てられない場合のローカル寿命との間の差分に基づいて判定され、
    隣接候補ノードの寿命は、当該隣接候補ノードのエネルギー消費を推定することによって推定され、
    各隣接候補ノードのエネルギー消費は、前記通信装置とそれぞれの隣接候補ノードとの間のリンク品質パラメータを定義することによって推定され、
    前記リンク品質パラメータは、データの送達の成功を保証するために前記通信装置と隣接候補ノードとの間で当該データが２回以上送信される必要がある尤度を反映する、
    通信装置。
21. コンピュータ化された通信装置による実行時に、当該通信装置に請求項１乃至請求項１９のいずれか１項に記載の方法を行わせるコンピュータ実行可能命令を含むコンピュータプログラム。