JP5992421B2 - 無線ネットワークでデータパケットを負荷分散するデバイス及び方法 - Google Patents

Description

本発明は、無線ネットワークでデータパケット送信を制御するデバイス、システム及び方法に関する。

近年、無線メッシュ型ネットワークは、例えば、照明システムの遠隔制御、ビルディングの自動化、監視用途、センサシステム及び医療用途のため、ますます注目されている。特に、室外照明器具の遠隔制御（いわゆるテレマネジメント（telemanagement））がますます重要になっている。一方、テレマネジメントシステムは、例えば時間、天候条件及び季節の関数のような異なる調光パターンの使用を可能にし、室外照明システムの更にエネルギー効率の良い使用を可能にするため、このことは環境問題により推進されている。他方、更なるエネルギー効率は運用コストをも低減するため、このことはまた経済的理由によっても推進されている。更に、システムは、電力使用を遠隔で監視し、ランプ障害を検出することができる。このことは、照明器具の修理又はランプの交換のための最も良い時間を判定することを可能にする。

現在の無線周波数（RF：radio-frequency）に基づく無線の対策は、スター型ネットワークトポロジ又はメッシュ型ネットワークトポロジを使用する。スター型ネットワークでは、コントローラは、ネットワークの各ノードに直接の通信パスを有する。しかし、典型的には、これは、高電力／高感度の基地局のようなコントローラが高い位置（例えばビルの上）に配置されることを必要とする。このことは、この対策を展開するのに煩雑にし、高コストにする。メッシュ型ネットワークでは、一般的には、複数のノードはコントローラと直接通信しないが、いわゆるマルチホップ通信を介して通信する。マルチホップ通信では、データパケットは、１つ以上の中間ノードを介して送信側ノードから宛先ノードに送信される。ノードは、データパケットを周辺ノードから到達するには遠すぎるノードにデータパケットを単一ホップで送信するためのルータとして動作する。その結果、より大きい距離に及ぶことができるネットワークを生じる。長距離を一連の短いホップに区切ることにより、信号強度が維持される。その結果、ルーティングは、メッシュ型ネットワークの全てのノードにより、どの周辺ノードにデータパケットが送信されるべきかを判断して実行される。従って、メッシュ型ネットワークは、高い接続性と、これによる高い冗長性及び信頼性とを備えた非常にロバスト且つ安定的なネットワークである。

従来技術では、メッシュ型ネットワーク送信技術は、２つのグループ（フラッディングに基づく（flooding-based）メッシュ型ネットワーク及びルーティングに基づくメッシュ型ネットワーク）に分割され得る。フラッディングに基づくメッシュ型ネットワークでは、全てのデータパケットは、ネットワークの全てのノードにより転送される。従って、ノードは、複雑なルーティング判定を行う必要はなく、単にデータパケットをブロードキャストする。このような手段により、この技術は非常にロバストである。しかし、大規模ネットワークでは、転送によるデータのオーバーヘッドが全体のデータレートに影響を及ぼす。更に、データパケットの衝突が生じやすくなり、更に全体の性能を低減する。従って、この対策の主な問題は、スケーラビリティである。ルーティングに基づくメッシュ型ネットワークは、プロアクティブ(proactive)方式とリアクティブ（reactive）方式とに更に分割され得る。プロアクティブ方式のルーティングに基づくメッシュ型ネットワークでは、全ての必要なネットワークパスが各ノードのルーティングテーブルに格納される。ルーティングテーブルは、例えば、効率的なルーティングパスを発見するために定期的なビーコンメッセージを周辺ノードに送信することにより、最新に保持される。このような種類のネットワークではデータ送信は非常に効率的であるが、依然としてスケーラビリティが低い。この理由は、大規模ネットワークでは、ルーティングテーブルのプロアクティブな更新は、ネットワークリソースの大きい部分を消費するからである。更に、ルーティングテーブルは、ネットワークの規模と共に増大する。更に、ネットワークの設定は、ルーティングテーブルを構築するために時間及びリソースを必要とする。これに対して、リアクティブ方式は、必要に応じてルートを発見することにより、恒久的なオーバーヘッド及び大きいルーティングテーブルを回避する。これは、ネットワークパスを発見し、アクティブなルート又はノードをキャッシュするためにフラッディング（flooding）を使用する。ルートが単一のデータパケットにまれにしか使用されない場合、ルート発見を実行する代わりにデータパケットをフラッディングすることが効率的になり得る。ルートが頻繁なルーティングを回避するのに十分に長く保持される場合、リアクティブ方式はプロアクティブ方式に劣る。リアクティブ方式のルーティングに基づくメッシュ型ネットワークの例は、ZigBeeで使用されている。しかし、このプロトコル方式の主な問題は、依然としてネットワークのスケーラビリティである。

このように、無線メッシュ型ネットワークのほとんどの送信は、マルチホップモードで実行される。その後で、各データパケット又はメッセージは転送のため複数回送信され、全体のネットワークスループットを低減する。また、無線メッシュ型ネットワークのネットワークスケーラビリティは非常に限られている。また、データパケットの衝突が生じやすくなり、全体の性能を更に低下させる。特に、ノードにより開始されたデータトラヒック（例えば、統計レポートデータ又は他のタイムクリティカル（時間重視）でないデータ）がほぼ同じ時刻を選択して複数のノードによりデータ収集ノード又はコントロールセンタに送信される場合、過負荷の問題が生じ、データの衝突及びロスを生じる。

更に、RFネットワークのような信頼性の低いネットワークでは、データパケットはまた、衝突以外の他の理由で（例えば、ネットワークの過負荷又は低下したリンク品質のため）送信中に失われる可能性がある。再送信はその可能性を低減できるが、決して送信の成功を保証できない。パケットが複数のホップを移動しなければならない場合、パケットロスの可能性が増加する。大規模のマルチホップネットワークでは、データパケットが移動しなければならないホップ数は比較的大きい。例えば、数千のノードを有する大規模なRFテレマネジメントシステムでは、20〜40のホップが生じる可能性がある。従って、各ホップでデータパケットが失われる可能性が存在するため、個々のデータパケットの配信機会はそのホップ距離と共に減少する。更に、ルーティングレベルでの輻輳及び一時的なエラーにより、マルチホップの場合のパケットロスの可能性が更に増加する。このことは、配信の保証がアプリケーションにより要求される場合、トランスポート又はアプリケーションレイヤでのデータ送達確認を必要とする。しかし、送達確認モードの欠点は、データ送達確認がネットワークのデータ負荷を増加させ、特にデータパケットがトランスポート又はアプリケーションレイヤで再送信される必要がある場合、受ける遅延がかなり増加する点にある。更に、マルチキャスト又はブロードキャストデータパケットが短期間内に多数又は全ての受信側ノードにより応答（送達確認）される場合、いわゆる送達確認ストーム（acknowledgement storm）が生じ、送信側ノードの周辺で過負荷の問題を生じ、従ってデータの衝突及びロスを生じる可能性がある。これは、各ノードが送信用の固定した個々のタイムスロットを有するグローバルにスケジューリングされたネットワークで回避され得る。しかし、このグローバルなスケジュールは、グローバルな協調及び設定を必要とするため、煩雑な設定手順を含む。更に、グローバルなスケジュールでの送信及び全てのノードについてグローバルなスケジュールを生成することは、それぞれ高いデータオーバーヘッド及び管理オーバーヘッドを生じる。更に、スロットがまれにしか使用されない場合、これは可能な帯域幅をかなり減少させる。従って、この手法も大規模ネットワークに適していない。

従って、一般的な無線ネットワークでの大きな欠点は、一方では退屈な配置及び設定で構成され、他方では非常に限られたネットワークスケーラビリティにより構成される。特に、RFテレマネジメントネットワークは、トポロジ及びサイズのため、特に局所的なレベルでかなりの過負荷を受ける。このことはスケーラビリティを制限する。これは、ネットワークトポロジを考慮することなく、メッセージが通信スタックのレイヤにより生成されて送信される理由で生じる。従って、送信の成功及び信頼性を改善することが、多数の照明器具ノードを備えた街路照明システムのような大規模ネットワークでは重要になる。この理由は、典型的には通信スタックの高いレイヤで生じるエンドツーエンドでの再送信が、かなり高コスト及び遅延集約的であるためである。従って、データパケットの衝突及びそれによるデータロスを最小化し、必要なスループットと応答時間とロバスト性とを実現するために、大規模無線ネットワークのための効率的なルーティングプロトコルが必要とされる。

US2006/0187836A1は、仮想的なボトルネックキューを導入することにより、タイムクリティカルのトラヒックの前に時間に厳しくないトラヒックを遅延又は破棄する通信デバイスを記載している。

Whettin他（IEEE Network, vol. 14, no. 1, pages 37-47, XP001195288）は、RMTP-II（Reliable Multicast Transport Protocol II）を記載している。受信側ノードは、TRACK（階層的ACK）パケットをその親ノードにユニキャストすることにより、受信したパケット又は受信していないパケットについてその親ノードに定期的に通知する。各親ノードは、その子ノードからTRACKを集約し、単一の集約されたTRACKをその親（上位）ノードにユニキャストする。上位ノードは、その子ノードからTRACKを集約し、単一のTRACKを送信側ノードにユニキャストする。

US2010/246600A1は、通信システムでオーバーヘッドを低減するシステムを記載している。異なるフレームが単一の予約期間内の送信に適しているという判定に応じて、異なるフレーム種別は、拡張された集約フレームに集約される。フレームが時間に厳しい場合、送信機又は受信機は、できるだけ早くフレームを送出する必要があるため、フレームを集約しない。

US2008/137624A1アドホックネットワークの遠隔監視、資産制御及び動作管理のためのグローバルな無線センサネットワークアーキテクチャ及びプロトコルを記載している。この技術の用途は、集中型地域運営センタからの照明システムの遠隔制御及び監視である。

従来技術における前述の欠点及び問題を鑑みて、各ネットワークノードで高い処理能力を必要とせずに、過負荷の問題を解決し、高レベルのスケーラビリティ及び送信信頼性を提供する、無線ネットワークでデータパケット送信するデバイス、システム及び方法を提供することが、本発明の目的である。

上記の目的は、独立項の特徴により解決される。

本発明は、データ収集ノードへ及び／又はデータ収集ノードからのメッセージフローが時間及び／又はネットワーク領域を通じて送信負荷のバランスを取るようにスケジューリング及び／又はシェーピングされるという概念に基づく。好ましくは、このことは、例えばクロスレイヤ（レイヤ間）通信を用いて、ネットワークコンポーネント及びプロトコルが相互から利用可能な情報を利用できるクロスレイヤ手法で実現され、これにより、データ収集ノード又はコントロールセンタの周辺のデータ負荷を軽減し、ネットワークスケーラビリティを増加させる。

本発明の一態様では、無線ネットワークでデータパケット送信を制御するデバイスが提供される。このデバイスは、１つより多くのデータパケットが受信された場合、応答データパケットを１つの応答バッチに集約するように構成された制御ユニットを有する。このような手段により、本発明によるデバイスは、データパケット応答を最適化するように適合される。従って、冗長なヘッダが省略され、データオーバーヘッドが低減され得る。これにより、送信のペイロードが増加するため、ネットワークリソースを節約することができる。従って、本発明によるデバイスは、時間及びネットワーク領域を通じて送信負荷のバランスを取るために、受信データパケットに応答するときにデータトラヒックをスケジューリング及び／又はシェーピングする。

１つの応答バッチに集約されるために、受信データパケットへの応答は、それぞれ延期されてもよい。好ましくは、判定された応答間隔は、応答バッチが判定された応答間隔内に送信されるように検討される。受信データパケットが単一の送信機から受信されたことが判定された場合、応答バッチは、１つの送信機にユニキャストされる。同様に、受信データパケットが複数の送信機から受信されたことが判定された場合、応答バッチは、複数の送信側ノードのうち１つより多くにマルチキャスト又はブロードキャストされてもよい。従って、本発明の一実施例では、制御ユニットは、不要なデータオーバーヘッドを回避するために、個々のノード及び／又は所定のグループのノードの応答データパケットを集約してもよい。特に、応答データパケットが、ほとんどペイロードを含まないが、依然として全体のネットワークレイヤ及びMACレイヤのヘッダを必要とする送達確認に対応する場合、送信のデータオーバーヘッドはかなり低減され、ネットワークリソースが節約される。所定のグループの応答バッチを形成する場合、ノードのグループは、例えばネットワーク効率又は各ノードの間の距離に基づいて適切に判定されてもよい。しかし、ネットワーク内の位置又はネットワークアドレス等に基づいてノードのグループを判定することも可能である。別法として、複数の適切なグループが予め定められ、各ノードに格納されてもよい。

好ましくは、デバイスは、ネットワークノードとデータ収集ノードとコントロールセンタとの少なくとも１つに追加又は結合されてもよい。従って、デバイスは、データ収集ノードでもよいネットワークノードに関連付けられる。データ収集ノードは、ネットワークのコントロールセンタと通信するように構成された如何なるノードでもよく、一種のゲートウェイとして機能してもよい。例えば、デバイスは、既存の回路基板に挿入されるように適合されてもよく、ノードの既存のコントローラに接続されるように適合されてもよい。特に、デバイスが既存のネットワークコンポーネントに追加される場合、街路照明システムとしての既存の無線ネットワークは、本発明の概念にアップグレードされ得る。制御ユニットに加えて、デバイスは、メモリ及び／又はデータパケットを受信及び送信する送受信ユニットを更に有してもよい。

無線ネットワークは、メッシュ型トポロジを有してもよい。更に、無線ネットワークのノードは固定されてもよく、無線ネットワーク内でのノードの位置は知られていてもよい。このネットワークで、データパケット送信は、ホップ毎に送達確認を備えたホップ毎送達確認モード又はエンドツーエンド送達確認モードでマルチホップ送信として実行されてもよい。これにより、成功したデータパケット送信が確認され、不要なデータパケットの再送信が回避される。

好ましい実施例では、受信データパケットは、１つより多くの受信機に送信されるマルチキャスト又はブロードキャストデータパケット（例えば、データ配信の要求）である。応答は、タイムクリティカルでない応答データパケット及び／又は受信データパケットの送達確認でもよい。従って、本発明によるデバイスは、複数の送達確認を１つの応答バッチに集約することにより、データパケットの送達確認を最適化するように適合されてもよい。このように、大きいデータオーバーヘッドを生成することなく、又は更なる数のデータの衝突を生じることなく、かなり効率的な送達確認モードが実現され得る。

一実施例では、デバイスの制御ユニットは、タイムクリティカルのデータパケットとタイムクリティカルでないデータパケットとを区別してもよい。例えば、制御ユニットは、応答データパケットがタイムクリティカルのデータパケットであるかタイムクリティカルでないデータパケットであるかを判定するために分析ステップを実行する。このような手段により、タイムクリティカルのデータパケットが遅延なしに送信されること、又はタイムクリティカルでないデータパケットに関して優先されることが保証され得る。更に、タイムクリティカルでないデータパケットは、タイムクリティカルのデータパケットの送信を妨げない。

更に好ましい実施例では、制御ユニットは、応答データパケットを受信データパケットの送信機（送信側）に送信するための判定された応答間隔内で、タイムスロットをランダムに選択するように構成される。特に、受信データパケットがマルチキャスト又はブロードキャストデータパケットである場合、このことは、マルチキャスト又はブロードキャストデータパケットを受信した受信機（受信側）の一部又は全部が非常に短いタイムラグで応答した場合に送信機でのデータパケットの衝突を回避するのに役立つ。例えば、受信データパケットは、データ配信の要求でもよく、これにより、受信機は要求されたデータを応答として送信する。受信機及び送信機は、それぞれコントロールセンタ、データ収集ノード又はノードの如何なるものでもよい。応答間隔の判定は、デバイスの制御ユニットにより実行されることが好ましい。応答間隔は、受信データパケットに特有でもよい。例えば、応答データパケットがタイムクリティカルでないデータパケットである場合、応答間隔は、タイムクリティカルのデータパケットの応答間隔より長くなるように判定されてもよい。受信データパケットがマルチキャスト又はブロードキャストデータパケットである場合、応答間隔の判定はまた、受信データパケットの受信機の数に基づいてもよい。更に又は別法として、応答間隔の判定は、応答データパケットの受信機の数（すなわち、データパケットが送信されたノードの数）に基づいてもよい。更に、応答間隔は、ネットワーク能力、ネットワークトポロジ、現在のネットワーク負荷及び予想ネットワーク負荷のようなネットワーク特性に基づいて判定されてもよい。更に、応答間隔は、ネットワーク能力、ネットワークトポロジ、現在のネットワーク負荷及び予想ネットワーク負荷のようなネットワーク特性に基づいて判定されてもよい。場合によっては、スケジュールはデバイスに格納され、制御ユニットは、このスケジュールを用いて応答間隔を判定してもよい。応答間隔を判定するための更なる基準又は別の基準は、受信データパケットに含まれる情報（例えば、送信機により判定又は推定されたネットワーク負荷、送信機により判定された期限、送信機がデータパケットを生成又は送信した時刻を示すタイムスタンプ等）でもよい。送信機が、応答データパケットが送信される必要がある期限を定めた場合、送信機は、遅くともいつ応答が予想される必要があるかを判定する。このことにより、送信機は再送信タイマを適切に調整することが可能になる。期限は、データパケットを受信して応答データパケットを送信するために通常必要な時間より長い応答間隔を定めるべきである。マルチキャストデータパケットに応答する必要がある場合、送信機でのデータの衝突及びそれによるデータロスの可能性は、応答間隔が長くなると減少する。

更に、制御ユニットは、各ノードのホップ距離、ネットワークエリア及びネットワークアドレスのうち少なくとも１つに基づいてデータ要求メッセージへのネットワークノードからの応答をスケジューリングすることにより、ネットワーク負荷を異なるネットワーク領域に分散するように適合されてもよい。好ましい実施例では、デバイスがデータ収集ノードへの低いホップ距離を有するノードに関連する場合、デバイスの制御ユニットは、データ収集ノードへの高いホップ距離を有するネットワークエリア内のデバイスのデータパケット送信より前に、データパケット送信をスケジューリングしてもよい。従って、デバイスは、ネットワークトポロジを考慮してデータトラヒックをシェーピング（shape）してもよい。このように、低いホップ距離のエリアにおいてノードにより送信されるデータパケットが積み上がらず、このため、低いホップ距離のエリアのノードが高いホップ距離を有するエリアのノードからのデータパケットを転送するルータとして機能し得ることが確保される。従って、低いホップ距離のエリアのノードの負荷が低減される。

更に、制御ユニットは、デバイスとデータ収集ノードとの間の空間的又は地理的距離、データ収集ノードへのデバイスのホップ距離、ネットワーク内のデバイスの位置、デバイスに関連するネットワークアドレス又はこれらの組み合わせのようなネットワークトポロジに基づいてバックオフ遅延を設定可能でもよい。バックオフ遅延は、MACレイヤ又はネットワークレイヤにより導入されたデータ再送信のバックオフ遅延を示してもよい。好ましくは、データ収集ノードに近いデバイスのバックオフ遅延は、データ収集ノードから離れたデバイスのバックオフ遅延より短い。

本発明の好ましい実施例では、デバイスは、照明システム（例えば、街路照明システム）のテレマネジメントのための制御ネットワークで使用される。このようなテレマネジメントシステムを用いることにより、照明器具ノードが容易にスイッチオン／オフされてもよく、及び／又はその調光パターンが、日時、季節、天候、周囲の明るさ、交通事故の発生、道路工事の存在等のようなパラメータに基づいて制御されてもよい。これらのパラメータは、照明器具ノードに備えられるセンサにより判定され、次にコントロールセンタに報告されてもよい。

本発明の更なる態様では、無線ネットワークでデータパケット送信を制御するシステムが提供される。このシステムは、コントロールセンタと複数のノードとを有する。コントロールセンタ及び／又はノードのうち少なくとも１つは、前述の実施例のうち１つによるデバイスを有する。好ましくは、データパケット送信は、無線ネットワークでマルチホップ送信を介して実行される。一実施例では、ノードは、室外照明システムの照明器具に関連する。

更に、ノードからデータ収集ノード又はコントロールセンタへのデータパケット送信は、ネットワーク内のノードの位置と、ノードのネットワークアドレスと、データ収集ノード又はコントロールセンタへのノードのホップ距離とのうち少なくとも１つに基づいてスケジューリングされてもよい。好ましくは、スケジューリングは、ノードがノード特有の遅延でコントロールセンタ又はデータ収集ノードによりマルチキャストされたデータ要求メッセージに対して報告し得るように、ノード内に存在するデバイスにより実行される。更に又は別法として、ネットワークのノードは、そのネットワーク位置及び／又はデータ収集ノード又はコントロールセンタへのホップ距離に基づいて、コントロールセンタ又はデータ収集ノードによりポーリングされてもよい。ポーリングは、コントロールセンタ又はデータ収集ノードのネットワークレイヤ、トランスポートレイヤ又はアプリケーションレイヤで実行されてもよく、この中に含まれるデバイスにより実行されてもよい。次に、ポーリングの後に、ノードは、異なる時刻に報告し、これにより、データパケットの衝突を回避する。

本発明の他の態様では、無線ネットワークでデータパケット送信を制御する方法が提供される。好ましくは、１つより多くの受信データパケットへの応答データパケットは、１つの応答バッチに集約される。このような手段により、無線ネットワークのデータトラヒックは、ネットワーク負荷及びデータロスを回避するために、送信時間及びネットワーク領域に関してスケジューリング及び／又はシェーピングされてもよい。

無線メッシュ型ネットワークの例 本発明によるデバイスの概略図 マルチキャストを示す図 本発明の一実施例による最適化されたデータ送信のためのフローチャート 図３Ａに示す実施例の変形による最適化されたデータ送信のためのフローチャート 本発明の他の実施例による最適化されたデータ送信のためのフローチャート 室外照明テレマネジメントシステムのノードの空間的な分散 データ収集ノードへのノードのホップ距離を示す無線メッシュ型ネットワークの概略図

本発明の好ましい用途は、室外照明システム（例えば、街路、駐車場及び公共区域のためのもの）及び一般的なエリアの照明のための室内照明システム（例えば、モール、アリーナ、駐車場、駅、トンネル等のためのもの）のような、アクチュエータネットワーク、センサネットワーク又は照明システムである。以下では、街路照明のための室外照明システムの例を使用して、本発明について更に説明する。しかし、本発明はこの用途に限定されない。照明制御の分野では、無線周波数ネットワーク技術を介した室外照明器具のテレマネジメントは、特に200より多い照明器具のセグメントを備えた大規模設備への適用性を備えた対策について更なる関心を受けている。

図１Ａに、メッシュ型トポロジを備えた典型的なネットワークが示されている。複数のノード10（N）は、無線通信パス40により相互に接続される。ノード10のうちいくつかは、データ収集ノード50（N/DC）として機能する。データ収集ノード50（N/DC）は、単一ホップ又は複数ホップの送信を介して周辺ノード10からデータパケットを受信し、これらをコントロールセンタ60に送信し、逆も同様に行う。従って、データ収集ノード50は、ノード10とコントロールセンタ60との間のゲートウェイのように動作してもよい。ノード10とデータ収集ノード50との間の無線通信パス40は、RF送信により構成されてもよく、データ収集ノード50とコントロールセンタ60との間の接続70はインターネット、移動通信ネットワーク、無線システム又は他の有線若しくは無線データ伝送システムを利用してもよい。

室外照明制御のためのテレマネジメントシステムでは、通信は非常に非対称的である。ほとんどのトラヒックは、例えばその状態、その調光プロファイル、センサ値又は電力使用をコントロールセンタ60に報告するノード10により生成される。他のトラヒックは、例えば、調光パターンの調整又はランプのスイッチオン／オフを行うためのコントロールセンタ60から異なるノード10への制御コマンドで構成される。従って、ほとんどのトラヒックは、N:1のトラヒック（ユニキャスト）により構成されるが、コントロールセンタ60からノード10へのトラヒックはユニキャスト、マルチキャスト又はブロードキャストモードの1:Nのトラヒックで構成される。更に、照明器具ノード10の数は、街路照明システムのような室外照明システムでは極めて多い。従って、ネットワークのサイズは、特に、典型的には200未満のノードを含む一般的な無線メッシュ型ネットワークに比べて非常に大きくなる。更に、典型的には、ノード10は、コストの考慮のため限られた処理能力を有し、このため、照明器具ノード10の処理及びメモリリソースは限られる。従って、単一のノード10の間でデータパケットを送信する通信プロトコルは、効率的且つ高速なデータパケット送信のために限られたリソースを考慮すべきである。更に、他のいわゆるアドホック・メッシュ型ネットワークに比べて、室外照明制御ネットワークのためのテレマネジメントシステムは固定されている。すなわち、ノード10は移動しない。また、全てのノード10は、主電源に接続されてもよい。従って、ネットワークの変更は、主に変化する環境（例えば、トラヒック）によるものである。ノード10が固定されている場合、ノード10の物理的位置（例えば、GPS座標）はシステム内で知られてもよく、地理又は位置に基づくルーティングが可能になる。更に、室外照明システムのテレマネジメントは、高いデータレートを必要としない。これは、データトラヒックの大部分がタイムクリティカルでないデータパケット（例えば、状態報告データ、統計データ、センサデータ等）から構成されることを意味する。しかし、特定の種類のメッセージ又はデータパケット（タイムクリティカルのデータパケット）のために低い応答時間が必要になる場合が存在する。例えば、交通事故が検出された場合、対応するエリアのノード10は、全出力に直ちに切り替えるように制御されてもよい。

図１Ｂに、本発明によるデバイス100が示されている。デバイス100は、無線マルチホップメッシュ型ネットワークのノード10、データ収集ノード50又はコントロールセンタ60に関連してもよい。デバイス100は、制御ユニット200を有する。更に、それぞれノード10、データ収集ノード50又はコントロールセンタ60或いはデバイス100は、無線通信パス40を介して（例えば、RF送信を介して）データパケットを送信又は受信する送受信ユニット300を有する。RF送信は高い送信電力を必要とせず、実装及び配置が容易であるため、デバイスを使用してネットワークを設定して動作させるコストが低減され得る。これは大規模RFネットワーク（例えば、照明システムのためのRFテレマネジメントネットワーク）には特に重要である。しかし、別法として、データパケット送信は、赤外線通信、自由空間可視光通信又は電力線通信を使用してもよい。

図２に示すように、送信機Aから複数のネットワークノード10のうち複数の特定の受信機Bへのデータパケット送信は、マルチキャストとして実行されてもよい（矢印）。送信機A又は少なくとも１つの受信機Bはまた、データ収集ノード50又はコントロールセンタ60を示してもよい。しかし、好ましくは、データ収集ノード50から各照明器具ノード10へのデータパケット送信は、フラッディングにより実行される。ここでは、全てのデータパケットがネットワークの全ての照明器具ノード10により転送される。データパケットは、送信機A及び１つ以上の宛先ノード10又は受信機Bについての情報を少なくとも含む。データパケットは、少なくとも１つの宛先ノード10により復号化される。照明器具ノード10からデータ収集ノード50へのデータパケット送信について、ルーティングに基づく対策が好ましい。好ましくは、プロアクティブ方式ルーティング構成が使用される。この理由は、データ収集ノード50へのルートが規則的に使用されるからである。プロアクティブ方式ルーティング構成では、どの周辺ノード10がデータ収集ノード50への接続として動作し得るかを示すルーティングテーブルが各ノード10に格納される。従って、データパケットは、非常に効率的且つ高速な方法で最も近いデータ収集ノード50に送信されてもよい。有利には、各ノード10は、信頼性を向上させるために、複数の下りリンク周辺ノード10についての情報を代替ルートとして保持する。強い干渉又は完全な障害のため１つの周辺ノードに到達できない場合、ルーティングプロトコルは、データパケットをデータ収集ノード50にルーティングする更なる選択肢を有する。

従って、無線ネットワークでは、複数のノード10（グループ又は全てのノード10）への同じデータパケットの送信は、データパケットをブロードキャスト又はマルチキャストすることにより効率的に実現され得る（図２参照）。しかし、送信の成功を確認するために配信の保証が必要である場合、ブロードキャスト又はマルチキャスト送信が送達確認モードで実行される。すなわち、データパケットを受信した受信機Bは、送達確認（ACK）を送信機Aに送信することにより、送信の成功を確認する。しかし、送達確認モードの１つの大きな欠点は、送達確認データパケットが、ほとんどペイロードを含まないが、依然として全体のネットワークレイヤ及びMACレイヤのヘッダを必要とし、ネットワーク負荷に寄与する点にある。このことは、送達確認データパケットのオーバーヘッドが他のデータパケットに比べて非常に高く、このため、多くの場合に送達確認の送信がかなりの量の利用可能なペイロードを埋めることを意味する。従って、本発明の一実施例によれば、複数の独立した送達確認は、図３に示すように、１つの応答バッチに集約されてもよい。

図３Ａに、送達確認が同じ送信機Aから受信したデータパケットに対応する場合について、複数の送達確認を集約する実施例が示されている。受信機Bが送信機Aからデータパケットを受信した場合（S300）、受信機Bは、更にデータパケットが受信されるとしてもされないとしても、所定の時間待機する（S301）。このことは、集約が行われる可能性を高くする。従って、受信機Bは、この所定の期間中に受信したデータパケットへの送達確認を延期し、それぞれの送達確認を格納する（S302）。所定の時間が経過した後に、受信機Bは、複数のデータパケットが所定の時間間隔内に同じ送信機Aから受信されたか否かを判定する。複数のデータパケットが所定の時間間隔内に同じ送信機Aから受信された場合（S303）、S304において、これらのデータパケットの送達確認は１つの応答バッチ又は送達確認バッチ（ACKバッチ）に集約される。ACKバッチは、１つの送信機Aに送信又はユニキャストされる（S305）。

図３Ｂに、複数のデータパケットが異なる送信機Aから受信される場合について同様の処理が示されている。データパケットを受信した後に（S300）、受信機Bは、更にデータパケットが受信されるとしてもされないとしても、所定の時間間隔待機し（S301）、この時間の間に受信した送達確認を延期し、格納する（S302）。複数のデータパケットが所定の時間間隔内に異なる送信機Aから受信されたことが判定された場合（S313）、受信機Bは、送信機の１つ以上の適切なグループを判定してもよい（S314）。これは、受信データパケットに基づいてもよく、送信される応答に基づいてもよく、ネットワーク内の送信機Aの位置に基づいてもよく、受信機Bへの送信機Aのホップ距離に基づいてもよく、送信機Aのネットワークアドレスに基づいてもよい。しかし、例えば、送信機Aのグループが予め定められ、受信機Bに格納されている場合、適切なグループを判定するステップ（S314）は省略されてもよい。最後に、１つの適切なグループの送信機Aの受信データパケットへの送達確認は、１つの応答バッチ又はACKバッチに集約され（S315）、ACKバッチがこのグループの全ての送信機Aに送信又はマルチキャストされる（S316）。従って、受信機Bは、受信データパケットの送信機Aをグループ化又はソートする。これは、コントロールセンタ60又はデータ収集ノード50が複数のノード10から送信される複数のデータパケットを送達確認する必要がある場合に、特に有用である。従って、基礎となる通信プロトコルに応じて、このような応答バッチをネットワーク効率の良いマルチキャストグループにマッピングすることが可能である。場合によって、必ずしも受信データパケットの全ての送信機Aが、送信機の適切なグループのうち１つに割り当てられなくてもよい。この場合、この送達確認は別々に送信されてもよい。更に、受信データパケットの送信機Aが必ずしも送信機の同じ適切なグループに割り当てられ得ないことが生じ得る。この場合、送信機のグループ毎に１つずつ、複数のACKバッチが送信されてもよい。

前述の実施例の変形では、受信データパケットがタイムクリティカルの応答を含むか否かが更に判定される。応答データパケットがタイムクリティカルでない場合、応答の集約の可能性が増加するように、更に大きい待機期間が選択されてもよい。従って、所定の待機時間は、要求された応答時間に基づいて調整されてもよい。複数の受信データパケットについて異なる応答間隔が定められた場合、最も短い応答間隔が選択されてもよい。このような手段により、ネットワークリソースが更に効率的に節約され得る。

前述の実施例並びに図３Ａ及び３Ｂに示す実施例は、送達確認の集約に限定されない。複数の応答データパケットを１つの応答バッチに集約することにより、他のデータパケットを送信するときにヘッダも節約されてもよい。応答バッチ及び送達確認バッチは、それぞれ複数の独立した応答又は送達確認を有する。このように、ネットワークリソースが節約され、データトラヒックが低減され得る。

送達確認モードでのマルチキャスト又はブロードキャストの場合に生じる更なる問題は、送信機Aで生じ、データの衝突及びロスを生じ得る、いわゆる送達確認ストームにある。従って、本発明の他の実施例によれば、データ送達確認は、図４に示すように各受信機Bによりランダムに更にスケジューリングされる。

図４に、送達確認の送信について、本発明の他の実施例による最適化されたデータ送信が例示的に示されている。受信機Bが送信機Aからマルチキャスト又はブロードキャストデータパケットを受信した後に（S40）、各受信機Bは応答間隔を判定する（S41）。応答間隔を判定した後に（S41）、受信機Bは、応答間隔内でタイムスロットをランダムに選択し（S42）、選択されたタイムスロットで送達確認データパケットを送信機Aに送信し（S43）、受信データパケットの受信の成功を確認する。

応答間隔は、マルチキャスト又はブロードキャストデータパケットが送信された受信機Bの数に基づいて判定されてもよい。例えば、データパケットが多数の受信機Bに送信された場合、応答間隔は、数個の受信機Bにのみ送信されたデータパケットの場合より長くなるように判定されてもよい。受信機Bの数は、特定の種類のデータパケットでは予め決められてもよい。例えば、マルチキャストデータパケットのグループアドレスを使用する場合、グループアドレスは、所定の数のノード10を備えた受信機Bの所定のグループを示してもよい。特に、データ要求メッセージがデータ収集ノード50又はコントロールセンタ60によるマルチキャスト又はブロードキャストである場合、各受信側ノード10は、受信したデータ要求に応答する受信機Bの数を認識していてもよい。応答間隔はまた、受信データパケットに含まれる情報に基づいて判定されてもよい。従って、送信機Aは、グループの受信機Bの量を認識又は推定し、この情報をマルチキャスト又はブロードキャストデータパケットに追加してもよい。更に又は別法として、送信機Aは、現在のネットワーク負荷又は予想ネットワーク負荷を推定又は判定してもよい。場合によっては、応答間隔は、各受信機Bについて同様に判定されてもよい。しかし、各受信機Bは応答間隔からランダムにタイムスロットを選択し、選択されたタイムスロットでその応答データパケットを送信するため、送信側ノード10でのデータの衝突は、可能性が低くなる。当然に、応答間隔を長くするほど又は受信側ノードBの数を低くするほど、データの衝突が生じる可能性が低くなる。従って、データロスが低減され、再送信が回避され得る。更に、ステップS301の所定の時間は、S41で判定された応答間隔又は指定の期限内になるように定められてもよい。場合によって、S301の所定の待機時間は、応答間隔内でランダムに選択される。

更なる実施例では、送信機Aは、データパケットと共に、応答データパケット（例えば、送達確認）が遅くとも再送信される必要がある期限を送信する。応答間隔は、データパケットの受信時から所定の期限までの時間間隔として判定される。各受信機Bは、この応答間隔内で（すなわち、期限前に）ランダムにタイムスロットを選択し、その応答データパケットを選択されたタイムスロット内に送信する。別法として、受信データパケットは、タイムスタンプ（例えば、データパケットを完了する時間又は送信機Aによりデータパケットを送信した時間を示す）を有する。タイムスタンプは、応答間隔を判定するための基準として各受信機Bにより使用される。例えば、所定の時間間隔は、例えば受信データパケットの種類に応じて、各ノード10に格納されてもよい。これにより、タイムスタンプ及び所定の時間間隔を用いて、各受信機Bは、受信データパケットに対する応答データパケットが送信される必要がある期限を容易に判定することができる。従って、期限又はタイムスタンプをデータパケット内に含めることにより、期限及び応答間隔が判定されてもよく、送信機Aはデータトラヒックをシェーピングしてもよい。場合によって、送信機Aは、期限を設定する場合、現在のネットワーク負荷又は予想ネットワーク負荷を考慮する。期限を指定することにより、送信機Aは、いつ最後の応答データパケットが遅くとも予想される必要があるかを自分で判定するため、再送信タイマの調整を更に最適化することができる。

当然に、図４に示す処理はデータ送達確認に限定されない。これに対して、この処理は、マルチキャスト又はブロードキャストデータパケットへの何れかの応答（例えば、マルチキャストデータ要求メッセージへの応答）をスケジューリングするために適合されてもよい。このような手段により、受信マルチキャストデータパケットに応答するためのランダムなスケジュールが、アドホック的に各受信機Bでローカルに生成されるため、例えば送信機Aにおけるネットワークでのデータの衝突の確率を最小化する。

本発明の更なる実施例では、データパケット（特にタイムクリティカルでないデータパケット）の送信は、データの衝突及びそれによるデータパケットロスを最小化するために、更にネットワークトポロジを考慮してスケジューリングされる。送信スケジュールは、N:1又は1:Nの通信パターン（例えば、データ収集ノード50から複数のノード10への通信リンク又は複数のノード10からデータ収集ノード50への通信リンク）に適用されてもよい。しかし、ノード10からデータ収集ノード50又はコントロールセンタ60への通信が反対方向より効率的であったとしても、依然として改良の余地及び必要性が存在する。この理由は、RFテレマネジメントシステムで通信される最大量の情報は、ノード10からの統計データ又は状態報告情報であるからである。従って、この実施例は、ノード10からデータ収集ノード50又はコントロールセンタ60へのN:1通信に採用されることが好ましく、従って、この例を使用して説明する。送信スケジュールは、ネットワーク内の送信機Aの位置と、データ収集ノード50への送信機Aのホップ距離と、送信機Aのネットワークアドレスとのうち少なくとも１つに基づいてもよい。

送信スケジュールがネットワーク内の送信機Aの位置に基づく場合、異なるエリアのノード10から通信リンク40が相互に干渉しないような異なるエリアが定められてもよい。このことは、特にデータ収集ノード50の周辺において、ネットワークの特定のボトルネックのエリアの過負荷を回避する。送信側ノード10は、そのネットワークアドレス又はMACアドレスを問い合わせることにより、その位置について検出してもよい。送信スケジュールは、コントロールセンタ60又はデータ収集ノード50により確立されて配信されてもよく、いつ異なるネットワークエリアのノード10がそのデータをコントロールセンタ60又はデータ収集ノード50に報告する予定であるかを示してもよい。別法として、コントロールセンタ60又はデータ収集ノード50は、ネットワークの位置に基づいてノード10にポーリングしてもよい。

図５Ａに、照明器具ノード10が街路に沿って配置されている街路照明システムが示されている。従って、照明器具ノード10がその統計データ（例えば、電力状態、調光状態、周辺の明るさ等）をデータ収集ノード50に報告する場合、データ送信は、空間的又は地理的グループに基づいてスケジューリングされてもよい。別法として、道路網に基づいて照明器具ノード10をグループ化することが有利になり得る。すなわち、同じ街路の照明器具ノード10はそのデータを同時に報告する。好ましくは、データ収集ノード50から離れた照明器具ノード10は、データ収集ノード50に近い照明器具ノード10より後の時点にそのデータパケットを送信する。

前述の実施例の変形では、送信スケジューリングは、照明器具ノード10からデータ収集ノード50へのホップ距離に基づく。図５Ｂに示すように、複数ホップ送信を使用した無線メッシュ型ネットワークにおける照明器具ノード10は、データ収集ノード50へのホップ距離により分類されてもよい。ホップ距離は、データパケットを送信側ノード10からデータ収集ノード50に送信するために必要なホップ数に関係する。例えば、半径502と半径501との間の照明器具ノード10は、そのデータパケットを２つのホップで送信するが、半経501内の照明器具ノード10は、そのデータパケットを１つのホップで送信することができる。ホップ距離又はホップカウント情報は、照明器具ノード10のネットワークレイヤで利用可能になってもよい。１つの例示の実施例では、データパケットは、ホップ距離により定められたエリアからデータ収集ノード50にプログレッシブに（順次に）送信される。好ましくは、低いホップ距離のエリア（例えば、半径501内）は、最初に報告するようにスケジュールされる、或いは単にデータ収集ノード50により最初にポーリングされる。このような手段により、低いホップ距離のエリアの照明器具ノード10がそのデータパケットを報告すると、これらは高いホップ距離のエリアの照明器具ノード10からのデータパケットを転送するルータとしてのみ動作する。このような手段により、通常ではネットワークトポロジのため過負荷になる可能性が非常に高い低いホップ距離のエリアの照明器具ノード10が軽減される。

場合によって、ネットワーク内の送信機Aの位置と、データ収集ノード50（又はネットワークコントローラ60）への送信機Aのホップ距離と、送信機Aのネットワークアドレスとのうち少なくとも１つに基づくデータパケット送信の空間的スケジューリングは、応答間隔内のタイムスロットのランダムな選択による時間的スケジューリング又は応答を１つの応答バッチに集約することによる時間的スケジューリングと組み合わされる。このような手段により、時間及び異なるネットワーク領域でネットワーク負荷のバランスを取ることが可能になる。

前述の実施例の更なる変形では、送信スケジュールは、照明器具ノード10のネットワークアドレスに基づく。従って、照明器具ノード10は、例えばコントロールセンタ60又はデータ収集ノード50によりブロードキャスト又はマルチキャストされた報告要求メッセージを受信した後に、異なる時刻に応答データパケットを送信してもよい。ブロードキャスト又はマルチキャストメッセージは、全ての報告する照明器具ノード10の共通の基準としての役目をするタイムスタンプを含んでもよい。この基準時間と、ノード特有又はネットワークアドレス特有の遅延とに基づいて、各照明器具ノード10は、その個々の送信時間を判定してもよい。このことは、全ての照明器具ノード10からのデータパケットが比較的短い期間内に受信される一方で、衝突のリスクを更に最小化させる。これは、照明器具ノード10が状態データ等をN:1の通信パターンでデータ収集ノード50又はコントロールセンタ60に報告する場合に特に有利である。ネットワークアドレスが動的に分配される場合、各ネットワークアドレスについて指定された遅延を備えたスケジュールテーブルが、各照明器具ノード10に格納されてもよい。ネットワークアドレスは、現在の要件に基づいて照明器具ノード10に動的に割り当てられ、これにより、個々の送信時間を判定してもよい。

本発明の更なる実施例では、送信スケジューリングの実施例と同様に、データパケットの再送信のためにバックオフ遅延がMACレイヤ又はネットワークレイヤにより導入される。バックオフ遅延は、次の送信試行の間の遅延を示す。例えば、送信が失敗した場合、送信側ノードAは、バックオフ遅延だけデータパケットの再送信を遅延させてもよい。これにより、他のノードがその送信を完了してもよく、その結果、衝突の可能性を低減する。従って、バックオフ遅延は、媒体アクセス試行のためのバックオフ時間を含んでもよい。ここで、媒体アクセス試行は、キャリア検知及びその後の媒体が自由になると評価されたときのデータパケットの送信又は再送信の処理に関係する。従って、媒体アクセス試行のためのバックオフ時間は、次の媒体アクセス試行の間の時間間隔を示す。バックオフ遅延は、ネットワーク内のノード10の位置と、ノード10とデータ収集ノード50との間のホップ距離と、ノード10のネットワークアドレスとのうち少なくとも１つに基づいて設定される。好ましくは、MACレイヤ及びネットワークレイヤのバックオフ遅延のうち少なくとも１つは、ノード10とデータ収集ノード50との間の距離に依存する。特に、MACレイヤのバックオフ遅延及びネットワークレイヤのバックオフ遅延のうち少なくとも１つは、更なる遠隔のノード10の場合に長くなる。この場合、データ収集ノード50から離れたノード10は、データ収集ノード50に近いノード10よりデータパケットを散在させるようにさせてもよい。このような手段により、遠隔ノード10は、データ収集ノード50の近くにあるノード10において過負荷を生じさせない。従って、ネットワークノード10のデータトラヒックの生成は、データ収集ノード50の近くで輻輳を回避するようにシェーピングされる。有利には、この実施例は、前述の実施例のうち少なくとも１つと共に使用される。

好ましくは、データパケット送信の遅延を含む前述の実施例は、ネットワークを通じて通信遅延の均一性に厳密な要件を有さないデータ送信及び／又はタイムクリティカルでないデータに適用される。例えば、このようなタイムクリティカルでないデータは、消費エネルギー、燃焼時間、動作状態、現在又は平均の調光パターン、検知された周囲の明るさ等のように、定期的な時間間隔でネットワークノード10により報告される統計データ又は状態情報を示してもよい。これに対して、タイムクリティカルの情報は、緊急の際にネットワークノード10に送信された制御メッセージの送達確認を示してもよい。

前述の実施例は様々な方法で組み合わされてもよいことが明らかである。前述の応答を応答バッチに集約する手段を用いて、ローカル及びグローバルなネットワーク負荷が低減され、データパケットの衝突及びそれによるデータロスが回避され得る。従って、かなり効率的且つ信頼性の高いデータ送信を可能にし、高いスケーラビリティ及び高速且つ容易な設定を提供し、自己設定及び自己回復が可能な無線メッシュ型ネットワークのルーティング手段が提供される。

Claims (16)

1. 無線ネットワークでのデータパケット送信を制御するデバイスであって、
   １つより多くの受信データパケットのそれぞれに対する複数の応答データパケットを１つの応答バッチに集約するように適合された制御ユニットを有し、
   データオーバーヘッドを低減するために、冗長なヘッダが前記応答バッチで省略され、
   前記応答バッチのデータパケット送信は、前記無線ネットワーク内の前記デバイスの位置に基づいてスケジューリングされる、
   デバイス。
2. 前記無線ネットワークは、ノード、データ収集ノード、及びコントロールセンタのコンポーネント群のうちの少なくともいくつかを含み、前記デバイスは、当該いくつかのコンポーネントの少なくとも１つに追加されるように適合される、
   請求項１に記載のデバイス。
3. 前記受信データパケットは、１つより多くの受信側ノードに送信されたマルチキャストデータパケットであり、
   前記応答データパケットは、前記受信データパケットのタイムクリティカルでない送達確認である、請求項１又は２に記載のデバイス。
4. 前記制御ユニットは、タイムクリティカルのデータパケットとタイムクリティカルでないデータパケットとを区別するように適合される、請求項１ないし３のうちいずれか１項に記載のデバイス。
5. データパケットの送信は、データ収集ノードへの前記デバイスのホップ距離に基づいてスケジューリングされ、前記データ収集ノードへの低いホップ距離を備えたエリアにおける前記データパケットの送信は、前記データ収集ノードへの高いホップ距離を備えたエリアにおける前記データパケットの送信より前にスケジューリングされる、請求項１に記載のデバイス。
6. 前記制御ユニットは、前記ネットワーク内の前記デバイスの位置に基づいて前記応答データパケットの再送信のためのバックオフ遅延を設定するように適合される、請求項１ないし５のうちいずれか１項に記載のデバイス。
7. 前記制御ユニットは、前記応答データパケットが各応答間隔内に送信されるように、前記応答バッチに集約する前記受信データパケットへの前記応答データパケットを延期させるように適合される、請求項１ないし６のうちいずれか１項に記載のデバイス。
8. 前記制御ユニットは、個々のノードへの応答データパケットを集約するように適合される、請求項１ないし７のうちいずれか１項に記載のデバイス。
9. 前記制御ユニットは、ノードの所定のグループへの応答データパケットを集約するように適合され、前記制御ユニットは、前記ノードの間の距離に基づいてノードの前記所定のグループを判定するように適合される、請求項８に記載のデバイス。
10. 前記デバイスは、照明器具ノードの照明制御のための照明システムのテレマネジメントで使用される、請求項１ないし９のうちいずれか１項に記載のデバイス。
11. 無線ネットワークでデータパケット送信を制御するシステムであって、
    複数のノードと、
    少なくとも１つのデータ収集ノードと
    を有し、
    前記複数のノードのうち少なくとも１つは、請求項１に記載のデバイスを有し、
    前記データ収集ノードは、データ要求メッセージを前記複数のノードのうち少なくともいくつかにマルチキャストするように適合され、前記いくつかのノードは、前記データ要求メッセージを受信した後にノード特有の遅延を伴って前記データ要求メッセージに応答するシステム。
12. 無線ネットワークでデータパケット送信を制御する方法であって、
    １つより多くの受信データパケットのそれぞれに対する複数の応答データパケットを１つの応答バッチに集約するステップを有し、
    データオーバーヘッドを低減するために、冗長なヘッダが前記応答バッチで省略され、
    前記応答バッチのデータパケットの送信は、前記無線ネットワーク内の前記デバイスの位置に基づいてスケジューリングされる、
    方法。
13. 前記受信データパケットは、データ配信要求であり、
    前記応答データパケットは、タイムクリティカルでないデータパケットである、
    請求項１に記載のデバイス。
14. データパケットの送信は、ネットワークアドレスに基づいてスケジューリングされる、請求項１に記載のデバイス。
15. 少なくとも１つの前記データ収集ノードは、請求項１に記載された前記デバイスを有し、
    前記少なくとも１つのデータ収集ノードは、ノードの位置に基づいてデータパケット送信のための前記複数のノードのうちの少なくとも１つをポーリングするように適合される、
    請求項１１に記載のシステム。
16. 少なくとも１つの前記データ収集ノードは、請求項１に記載された前記デバイスを有し、
    前記少なくとも１つのデータ収集ノードは、当該データ収集ノードへのノードのホップ距離に基づいてデータパケット送信のための前記複数のノードのうちの少なくとも１つをポーリングするように適合される、
    請求項１１に記載のシステム。
    

Images