無線ネットワークでのデータパケット送信を制御するデバイスであって、1つより多くの受信データパケットへの応答を1つの応答バッチに集約するように適合された制御ユニットを有し、データオーバーヘッドを低減するために、冗長なヘッダが前記応答バッチで省略されるデバイス。前記デバイスは、ノード及び/又はデータ収集ノード及び/又はコントロールセンタに追加されるように適合され、及び/又は前記無線ネットワークは、メッシュ型ネットワークであり、及び/又は前記無線ネットワークのノードは、固定されており、及び/又は前記無線ネットワークのノードの位置は知られている、請求項1に記載のデバイス。前記受信データパケットは、1つより多くの受信側ノードに送信されたマルチキャスト又はブロードキャストデータパケット及び/又はデータ配信の要求であり、及び/又は前記応答は、タイムクリティカルでないデータパケット及び/又は前記受信データパケットの送達確認である、請求項1又は2に記載のデバイス。前記制御ユニットは、タイムクリティカルのデータパケットとタイムクリティカルでないデータパケットとを区別するように適合される、請求項1ないし3のうちいずれか1項に記載のデバイス。前記制御ユニットは、受信データパケットに応答する応答を送信するための判定された応答間隔内でタイムスロットをランダムに選択するように適合される、請求項1ないし4のうちいずれか1項に記載のデバイス。前記応答間隔は、前記受信データパケットに特有であり、及び/又は前記応答間隔は、前記応答の宛先ノードの数及び/又は前記受信データパケットの受信側ノードの数及び/又はネットワーク能力及び/又はタイムスタンプ及び/又は前記受信データパケットに含まれる情報及び/又は所定の期限及び/又は現在のネットワーク負荷及び/又は予想ネットワーク負荷及び/又は格納されたスケジュールに基づいて判定される、請求項5に記載のデバイス。データパケットの送信は、前記ネットワーク内の前記デバイスの位置及び/又はデータ収集ノードへの前記デバイスのホップ距離及び/又はネットワークアドレスに基づいてスケジューリングされる、請求項1ないし6のうちいずれか1項に記載のデバイス。データ収集ノードへの低いホップ距離を備えたエリアのデータパケットの送信は、前記データ収集ノードへの高いホップ距離を備えたエリアのデータパケットの送信より前にスケジューリングされる、請求項7に記載のデバイス。前記制御ユニットは、前記デバイスとデータ収集ノードとの間の空間距離及び/又はデータ収集ノードへの前記デバイスのホップ距離及び/又は前記ネットワーク内の前記デバイスの位置及び/又はネットワークアドレスに基づいてバックオフ遅延を設定するように適合される、請求項1ないし8のうちいずれか1項に記載のデバイス。前記制御ユニットは、前記応答が各応答間隔内に送信されるように、前記応答バッチに集約する前記受信データパケットへの前記応答を延期させるように適合される、請求項1ないし9のうちいずれか1項に記載のデバイス。前記制御ユニットは、個々のノードへの応答を集約し、及び/又は所定のグループのノードへの応答を集約するように適合される、請求項1ないし10のうちいずれか1項に記載のデバイス。前記所定のグループへの応答の集約について、前記制御ユニットは、前記ノードの間の距離に基づいてノードの前記グループを判定するように適合される、請求項11に記載のデバイス。前記デバイスは、照明器具ノードのスイッチオン/オフ及び/又は調光パターンの制御のための照明システムのテレマネジメントで使用される、請求項1ないし12のうちいずれか1項に記載のデバイス。無線ネットワークでデータパケット送信を制御するシステムであって、複数のノードと、少なくとも1つのデータ収集ノードとを有し、前記ノードのうち少なくとも1つ及び/又は前記データ収集ノードは、請求項1ないし13のうちいずれか1項に記載のデバイスを有し、前記データ収集ノードは、前記データ収集ノードへの前記ノードのホップ距離及び/又は前記ノードが位置するネットワークエリアに基づいてデータパケット送信のために前記ノードのうち少なくとも1つにポーリングするように適合され、及び/又は前記データ収集ノードは、データ要求メッセージを前記ノードのうち少なくともいくつかにマルチキャストするように適合され、前記ノードは、前記データ要求メッセージを受信した後にノード特有の遅延で応答するシステム。無線ネットワークでデータパケット送信を制御する方法であって、1つより多くの受信データパケットへの応答を1つの応答バッチに集約するステップを有し、データオーバーヘッドを低減するために、冗長なヘッダが前記応答バッチで省略される方法。このように、無線メッシュ型ネットワークのほとんどの送信は、マルチホップモードで実行される。その後で、各データパケット又はメッセージは転送のため複数回送信され、全体のネットワークスループットを低減する。また、無線メッシュ型ネットワークのネットワークスケーラビリティは非常に限られている。また、データパケットの衝突が生じやすくなり、全体の性能を更に低下させる。特に、ノードにより開始されたデータトラヒック例えば、統計レポートデータ又は他のタイムクリティカル時間重視でないデータがほぼ同じ時刻を選択して複数のノードによりデータ収集ノード又はコントロールセンタに送信される場合、過負荷の問題が生じ、データの衝突及びロスを生じる。更に、RFネットワークのような信頼性の低いネットワークでは、データパケットはまた、衝突以外の他の理由で例えば、ネットワークの過負荷又は低下したリンク品質のため送信中に失われる可能性がある。再送信はその可能性を低減できるが、決して送信の成功を保証できない。パケットが複数のホップを移動しなければならない場合、パケットロスの可能性が増加する。大規模のマルチホップネットワークでは、データパケットが移動しなければならないホップ数は比較的大きい。例えば、数千のノードを有する大規模なRFテレマネジメントシステムでは、20~40のホップが生じる可能性がある。従って、各ホップでデータパケットが失われる可能性が存在するため、個々のデータパケットの配信機会はそのホップ距離と共に減少する。更に、ルーティングレベルでの輻輳及び一時的なエラーにより、マルチホップの場合のパケットロスの可能性が更に増加する。このことは、配信の保証がアプリケーションにより要求される場合、トランスポート又はアプリケーションレイヤでのデータ送達確認を必要とする。しかし、送達確認モードの欠点は、データ送達確認がネットワークのデータ負荷を増加させ、特にデータパケットがトランスポート又はアプリケーションレイヤで再送信される必要がある場合、受ける遅延がかなり増加する点にある。更に、マルチキャスト又はブロードキャストデータパケットが短期間内に多数又は全ての受信側ノードにより応答送達確認される場合、いわゆる送達確認ストームacknowledgementstormが生じ、送信側ノードの周辺で過負荷の問題を生じ、従ってデータの衝突及びロスを生じる可能性がある。これは、各ノードが送信用の固定した個々のタイムスロットを有するグローバルにスケジューリングされたネットワークで回避され得る。しかし、このグローバルなスケジュールは、グローバルな協調及び設定を必要とするため、煩雑な設定手順を含む。更に、グローバルなスケジュールでの送信及び全てのノードについてグローバルなスケジュールを生成することは、それぞれ高いデータオーバーヘッド及び管理オーバーヘッドを生じる。更に、スロットがまれにしか使用されない場合、これは可能な帯域幅をかなり減少させる。従って、この手法も大規模ネットワークに適していない。従って、一般的な無線ネットワークでの大きな欠点は、一方では退屈な配置及び設定で構成され、他方では非常に限られたネットワークスケーラビリティにより構成される。特に、RFテレマネジメントネットワークは、トポロジ及びサイズのため、特に局所的なレベルでかなりの過負荷を受ける。このことはスケーラビリティを制限する。これは、ネットワークトポロジを考慮することなく、メッセージが通信スタックのレイヤにより生成されて送信される理由で生じる。従って、送信の成功及び信頼性を改善することが、多数の照明器具ノードを備えた街路照明システムのような大規模ネットワークでは重要になる。この理由は、典型的には通信スタックの高いレイヤで生じるエンドツーエンドでの再送信が、かなり高コスト及び遅延集約的であるためである。従って、データパケットの衝突及びそれによるデータロスを最小化し、必要なスループットと応答時間とロバスト性とを実現するために、大規模無線ネットワークのための効率的なルーティングプロトコルが必要とされる。US20060187836A1は、仮想的なボトルネックキューを導入することにより、タイムクリティカルのトラヒックの前に時間に厳しくないトラヒックを遅延又は破棄する通信デバイスを記載している。Whettin他IEEENetworkvol14no1pages3747XP001195288は、RMTPIIReliableMulticastTransportProtocolIIを記載している。受信側ノードは、TRACK階層的ACKパケットをその親ノードにユニキャストすることにより、受信したパケット又は受信していないパケットについてその親ノードに定期的に通知する。各親ノードは、その子ノードからTRACKを集約し、単一の集約されたTRACKをその親上位ノードにユニキャストする。上位ノードは、その子ノードからTRACKを集約し、単一のTRACKを送信側ノードにユニキャストする。US2010246600A1は、通信システムでオーバーヘッドを低減するシステムを記載している。異なるフレームが単一の予約期間内の送信に適しているという判定に応じて、異なるフレーム種別は、拡張された集約フレームに集約される。フレームが時間に厳しい場合、送信機又は受信機は、できるだけ早くフレームを送出する必要があるため、フレームを集約しない。US2008137624A1アドホックネットワークの遠隔監視、資産制御及び動作管理のためのグローバルな無線センサネットワークアーキテクチャ及びプロトコルを記載している。この技術の用途は、集中型地域運営センタからの照明システムの遠隔制御及び監視である。従来技術における前述の欠点及び問題を鑑みて、各ネットワークノードで高い処理能力を必要とせずに、過負荷の問題を解決し、高レベルのスケーラビリティ及び送信信頼性を提供する、無線ネットワークでデータパケット送信するデバイス、システム及び方法を提供することが、本発明の目的である。上記の目的は、独立項の特徴により解決される。本発明は、データ収集ノードへ及び/又はデータ収集ノードからのメッセージフローが時間及び/又はネットワーク領域を通じて送信負荷のバランスを取るようにスケジューリング及び/又はシェーピングされるという概念に基づく。好ましくは、このことは、例えばクロスレイヤレイヤ間通信を用いて、ネットワークコンポーネント及びプロトコルが相互から利用可能な情報を利用できるクロスレイヤ手法で実現され、これにより、データ収集ノード又はコントロールセンタの周辺のデータ負荷を軽減し、ネットワークスケーラビリティを増加させる。本発明の一態様では、無線ネットワークでデータパケット送信を制御するデバイスが提供される。このデバイスは、1つより多くのデータパケットが受信された場合、応答データパケットを1つの応答バッチに集約するように構成された制御ユニットを有する。このような手段により、本発明によるデバイスは、データパケット応答を最適化するように適合される。従って、冗長なヘッダが省略され、データオーバーヘッドが低減され得る。これにより、送信のペイロードが増加するため、ネットワークリソースを節約することができる。従って、本発明によるデバイスは、時間及びネットワーク領域を通じて送信負荷のバランスを取るために、受信データパケットに応答するときにデータトラヒックをスケジューリング及び/又はシェーピングする。1つの応答バッチに集約されるために、受信データパケットへの応答は、それぞれ延期されてもよい。好ましくは、判定された応答間隔は、応答バッチが判定された応答間隔内に送信されるように検討される。受信データパケットが単一の送信機から受信されたことが判定された場合、応答バッチは、1つの送信機にユニキャストされる。同様に、受信データパケットが複数の送信機から受信されたことが判定された場合、応答バッチは、複数の送信側ノードのうち1つより多くにマルチキャスト又はブロードキャストされてもよい。従って、本発明の一実施例では、制御ユニットは、不要なデータオーバーヘッドを回避するために、個々のノード及び/又は所定のグループのノードの応答データパケットを集約してもよい。特に、応答データパケットが、ほとんどペイロードを含まないが、依然として全体のネットワークレイヤ及びMACレイヤのヘッダを必要とする送達確認に対応する場合、送信のデータオーバーヘッドはかなり低減され、ネットワークリソースが節約される。所定のグループの応答バッチを形成する場合、ノードのグループは、例えばネットワーク効率又は各ノードの間の距離に基づいて適切に判定されてもよい。しかし、ネットワーク内の位置又はネットワークアドレス等に基づいてノードのグループを判定することも可能である。別法として、複数の適切なグループが予め定められ、各ノードに格納されてもよい。好ましくは、デバイスは、ネットワークノードとデータ収集ノードとコントロールセンタとの少なくとも1つに追加又は結合されてもよい。従って、デバイスは、データ収集ノードでもよいネットワークノードに関連付けられる。データ収集ノードは、ネットワークのコントロールセンタと通信するように構成された如何なるノードでもよく、一種のゲートウェイとして機能してもよい。例えば、デバイスは、既存の回路基板に挿入されるように適合されてもよく、ノードの既存のコントローラに接続されるように適合されてもよい。特に、デバイスが既存のネットワークコンポーネントに追加される場合、街路照明システムとしての既存の無線ネットワークは、本発明の概念にアップグレードされ得る。制御ユニットに加えて、デバイスは、メモリ及び/又はデータパケットを受信及び送信する送受信ユニットを更に有してもよい。無線ネットワークは、メッシュ型トポロジを有してもよい。更に、無線ネットワークのノードは固定されてもよく、無線ネットワーク内でのノードの位置は知られていてもよい。このネットワークで、データパケット送信は、ホップ毎に送達確認を備えたホップ毎送達確認モード又はエンドツーエンド送達確認モードでマルチホップ送信として実行されてもよい。これにより、成功したデータパケット送信が確認され、不要なデータパケットの再送信が回避される。好ましい実施例では、受信データパケットは、1つより多くの受信機に送信されるマルチキャスト又はブロードキャストデータパケット例えば、データ配信の要求である。応答は、タイムクリティカルでない応答データパケット及び/又は受信データパケットの送達確認でもよい。従って、本発明によるデバイスは、複数の送達確認を1つの応答バッチに集約することにより、データパケットの送達確認を最適化するように適合されてもよい。このように、大きいデータオーバーヘッドを生成することなく、又は更なる数のデータの衝突を生じることなく、かなり効率的な送達確認モードが実現され得る。一実施例では、デバイスの制御ユニットは、タイムクリティカルのデータパケットとタイムクリティカルでないデータパケットとを区別してもよい。例えば、制御ユニットは、応答データパケットがタイムクリティカルのデータパケットであるかタイムクリティカルでないデータパケットであるかを判定するために分析ステップを実行する。このような手段により、タイムクリティカルのデータパケットが遅延なしに送信されること、又はタイムクリティカルでないデータパケットに関して優先されることが保証され得る。更に、タイムクリティカルでないデータパケットは、タイムクリティカルのデータパケットの送信を妨げない。更に好ましい実施例では、制御ユニットは、応答データパケットを受信データパケットの送信機送信側に送信するための判定された応答間隔内で、タイムスロットをランダムに選択するように構成される。特に、受信データパケットがマルチキャスト又はブロードキャストデータパケットである場合、このことは、マルチキャスト又はブロードキャストデータパケットを受信した受信機受信側の一部又は全部が非常に短いタイムラグで応答した場合に送信機でのデータパケットの衝突を回避するのに役立つ。例えば、受信データパケットは、データ配信の要求でもよく、これにより、受信機は要求されたデータを応答として送信する。受信機及び送信機は、それぞれコントロールセンタ、データ収集ノード又はノードの如何なるものでもよい。応答間隔の判定は、デバイスの制御ユニットにより実行されることが好ましい。応答間隔は、受信データパケットに特有でもよい。例えば、応答データパケットがタイムクリティカルでないデータパケットである場合、応答間隔は、タイムクリティカルのデータパケットの応答間隔より長くなるように判定されてもよい。受信データパケットがマルチキャスト又はブロードキャストデータパケットである場合、応答間隔の判定はまた、受信データパケットの受信機の数に基づいてもよい。更に又は別法として、応答間隔の判定は、応答データパケットの受信機の数すなわち、データパケットが送信されたノードの数に基づいてもよい。更に、応答間隔は、ネットワーク能力、ネットワークトポロジ、現在のネットワーク負荷及び予想ネットワーク負荷のようなネットワーク特性に基づいて判定されてもよい。更に、応答間隔は、ネットワーク能力、ネットワークトポロジ、現在のネットワーク負荷及び予想ネットワーク負荷のようなネットワーク特性に基づいて判定されてもよい。場合によっては、スケジュールはデバイスに格納され、制御ユニットは、このスケジュールを用いて応答間隔を判定してもよい。応答間隔を判定するための更なる基準又は別の基準は、受信データパケットに含まれる情報例えば、送信機により判定又は推定されたネットワーク負荷、送信機により判定された期限、送信機がデータパケットを生成又は送信した時刻を示すタイムスタンプ等でもよい。送信機が、応答データパケットが送信される必要がある期限を定めた場合、送信機は、遅くともいつ応答が予想される必要があるかを判定する。このことにより、送信機は再送信タイマを適切に調整することが可能になる。期限は、データパケットを受信して応答データパケットを送信するために通常必要な時間より長い応答間隔を定めるべきである。マルチキャストデータパケットに応答する必要がある場合、送信機でのデータの衝突及びそれによるデータロスの可能性は、応答間隔が長くなると減少する。更に、制御ユニットは、各ノードのホップ距離、ネットワークエリア及びネットワークアドレスのうち少なくとも1つに基づいてデータ要求メッセージへのネットワークノードからの応答をスケジューリングすることにより、ネットワーク負荷を異なるネットワーク領域に分散するように適合されてもよい。好ましい実施例では、デバイスがデータ収集ノードへの低いホップ距離を有するノードに関連する場合、デバイスの制御ユニットは、データ収集ノードへの高いホップ距離を有するネットワークエリア内のデバイスのデータパケット送信より前に、データパケット送信をスケジューリングしてもよい。従って、デバイスは、ネットワークトポロジを考慮してデータトラヒックをシェーピングshapeしてもよい。このように、低いホップ距離のエリアにおいてノードにより送信されるデータパケットが積み上がらず、このため、低いホップ距離のエリアのノードが高いホップ距離を有するエリアのノードからのデータパケットを転送するルータとして機能し得ることが確保される。従って、低いホップ距離のエリアのノードの負荷が低減される。更に、制御ユニットは、デバイスとデータ収集ノードとの間の空間的又は地理的距離、データ収集ノードへのデバイスのホップ距離、ネットワーク内のデバイスの位置、デバイスに関連するネットワークアドレス又はこれらの組み合わせのようなネットワークトポロジに基づいてバックオフ遅延を設定可能でもよい。バックオフ遅延は、MACレイヤ又はネットワークレイヤにより導入されたデータ再送信のバックオフ遅延を示してもよい。好ましくは、データ収集ノードに近いデバイスのバックオフ遅延は、データ収集ノードから離れたデバイスのバックオフ遅延より短い。本発明の好ましい実施例では、デバイスは、照明システム例えば、街路照明システムのテレマネジメントのための制御ネットワークで使用される。このようなテレマネジメントシステムを用いることにより、照明器具ノードが容易にスイッチオン/オフされてもよく、及び/又はその調光パターンが、日時、季節、天候、周囲の明るさ、交通事故の発生、道路工事の存在等のようなパラメータに基づいて制御されてもよい。これらのパラメータは、照明器具ノードに備えられるセンサにより判定され、次にコントロールセンタに報告されてもよい。本発明の更なる態様では、無線ネットワークでデータパケット送信を制御するシステムが提供される。このシステムは、コントロールセンタと複数のノードとを有する。コントロールセンタ及び/又はノードのうち少なくとも1つは、前述の実施例のうち1つによるデバイスを有する。好ましくは、データパケット送信は、無線ネットワークでマルチホップ送信を介して実行される。一実施例では、ノードは、室外照明システムの照明器具に関連する。更に、ノードからデータ収集ノード又はコントロールセンタへのデータパケット送信は、ネットワーク内のノードの位置と、ノードのネットワークアドレスと、データ収集ノード又はコントロールセンタへのノードのホップ距離とのうち少なくとも1つに基づいてスケジューリングされてもよい。好ましくは、スケジューリングは、ノードがノード特有の遅延でコントロールセンタ又はデータ収集ノードによりマルチキャストされたデータ要求メッセージに対して報告し得るように、ノード内に存在するデバイスにより実行される。更に又は別法として、ネットワークのノードは、そのネットワーク位置及び/又はデータ収集ノード又はコントロールセンタへのホップ距離に基づいて、コントロールセンタ又はデータ収集ノードによりポーリングされてもよい。ポーリングは、コントロールセンタ又はデータ収集ノードのネットワークレイヤ、トランスポートレイヤ又はアプリケーションレイヤで実行されてもよく、この中に含まれるデバイスにより実行されてもよい。次に、ポーリングの後に、ノードは、異なる時刻に報告し、これにより、データパケットの衝突を回避する。本発明の他の態様では、無線ネットワークでデータパケット送信を制御する方法が提供される。好ましくは、1つより多くの受信データパケットへの応答データパケットは、1つの応答バッチに集約される。このような手段により、無線ネットワークのデータトラヒックは、ネットワーク負荷及びデータロスを回避するために、送信時間及びネットワーク領域に関してスケジューリング及び/又はシェーピングされてもよい。本発明の好ましい用途は、室外照明システム例えば、街路、駐車場及び公共区域のためのもの及び一般的なエリアの照明のための室内照明システム例えば、モール、アリーナ、駐車場、駅、トンネル等のためのもののような、アクチュエータネットワーク、センサネットワーク又は照明システムである。以下では、街路照明のための室外照明システムの例を使用して、本発明について更に説明する。しかし、本発明はこの用途に限定されない。照明制御の分野では、無線周波数ネットワーク技術を介した室外照明器具のテレマネジメントは、特に200より多い照明器具のセグメントを備えた大規模設備への適用性を備えた対策について更なる関心を受けている。図1Aに、メッシュ型トポロジを備えた典型的なネットワークが示されている。複数のノード10Nは、無線通信パス40により相互に接続される。ノード10のうちいくつかは、データ収集ノード50NDCとして機能する。データ収集ノード50NDCは、単一ホップ又は複数ホップの送信を介して周辺ノード10からデータパケットを受信し、これらをコントロールセンタ60に送信し、逆も同様に行う。従って、データ収集ノード50は、ノード10とコントロールセンタ60との間のゲートウェイのように動作してもよい。ノード10とデータ収集ノード50との間の無線通信パス40は、RF送信により構成されてもよく、データ収集ノード50とコントロールセンタ60との間の接続70はインターネット、移動通信ネットワーク、無線システム又は他の有線若しくは無線データ伝送システムを利用してもよい。室外照明制御のためのテレマネジメントシステムでは、通信は非常に非対称的である。ほとんどのトラヒックは、例えばその状態、その調光プロファイル、センサ値又は電力使用をコントロールセンタ60に報告するノード10により生成される。他のトラヒックは、例えば、調光パターンの調整又はランプのスイッチオン/オフを行うためのコントロールセンタ60から異なるノード10への制御コマンドで構成される。従って、ほとんどのトラヒックは、N1のトラヒックユニキャストにより構成されるが、コントロールセンタ60からノード10へのトラヒックはユニキャスト、マルチキャスト又はブロードキャストモードの1Nのトラヒックで構成される。更に、照明器具ノード10の数は、街路照明システムのような室外照明システムでは極めて多い。従って、ネットワークのサイズは、特に、典型的には200未満のノードを含む一般的な無線メッシュ型ネットワークに比べて非常に大きくなる。更に、典型的には、ノード10は、コストの考慮のため限られた処理能力を有し、このため、照明器具ノード10の処理及びメモリリソースは限られる。従って、単一のノード10の間でデータパケットを送信する通信プロトコルは、効率的且つ高速なデータパケット送信のために限られたリソースを考慮すべきである。更に、他のいわゆるアドホックメッシュ型ネットワークに比べて、室外照明制御ネットワークのためのテレマネジメントシステムは固定されている。すなわち、ノード10は移動しない。また、全てのノード10は、主電源に接続されてもよい。従って、ネットワークの変更は、主に変化する環境例えば、トラヒックによるものである。ノード10が固定されている場合、ノード10の物理的位置例えば、GPS座標はシステム内で知られてもよく、地理又は位置に基づくルーティングが可能になる。更に、室外照明システムのテレマネジメントは、高いデータレートを必要としない。これは、データトラヒックの大部分がタイムクリティカルでないデータパケット例えば、状態報告データ、統計データ、センサデータ等から構成されることを意味する。しかし、特定の種類のメッセージ又はデータパケットタイムクリティカルのデータパケットのために低い応答時間が必要になる場合が存在する。例えば、交通事故が検出された場合、対応するエリアのノード10は、全出力に直ちに切り替えるように制御されてもよい。図1Bに、本発明によるデバイス100が示されている。デバイス100は、無線マルチホップメッシュ型ネットワークのノード10、データ収集ノード50又はコントロールセンタ60に関連してもよい。デバイス100は、制御ユニット200を有する。更に、それぞれノード10、データ収集ノード50又はコントロールセンタ60或いはデバイス100は、無線通信パス40を介して例えば、RF送信を介してデータパケットを送信又は受信する送受信ユニット300を有する。RF送信は高い送信電力を必要とせず、実装及び配置が容易であるため、デバイスを使用してネットワークを設定して動作させるコストが低減され得る。これは大規模RFネットワーク例えば、照明システムのためのRFテレマネジメントネットワークには特に重要である。しかし、別法として、データパケット送信は、赤外線通信、自由空間可視光通信又は電力線通信を使用してもよい。図2に示すように、送信機Aから複数のネットワークノード10のうち複数の特定の受信機Bへのデータパケット送信は、マルチキャストとして実行されてもよい矢印。送信機A又は少なくとも1つの受信機Bはまた、データ収集ノード50又はコントロールセンタ60を示してもよい。しかし、好ましくは、データ収集ノード50から各照明器具ノード10へのデータパケット送信は、フラッディングにより実行される。ここでは、全てのデータパケットがネットワークの全ての照明器具ノード10により転送される。データパケットは、送信機A及び1つ以上の宛先ノード10又は受信機Bについての情報を少なくとも含む。データパケットは、少なくとも1つの宛先ノード10により復号化される。照明器具ノード10からデータ収集ノード50へのデータパケット送信について、ルーティングに基づく対策が好ましい。好ましくは、プロアクティブ方式ルーティング構成が使用される。この理由は、データ収集ノード50へのルートが規則的に使用されるからである。プロアクティブ方式ルーティング構成では、どの周辺ノード10がデータ収集ノード50への接続として動作し得るかを示すルーティングテーブルが各ノード10に格納される。従って、データパケットは、非常に効率的且つ高速な方法で最も近いデータ収集ノード50に送信されてもよい。有利には、各ノード10は、信頼性を向上させるために、複数の下りリンク周辺ノード10についての情報を代替ルートとして保持する。強い干渉又は完全な障害のため1つの周辺ノードに到達できない場合、ルーティングプロトコルは、データパケットをデータ収集ノード50にルーティングする更なる選択肢を有する。従って、無線ネットワークでは、複数のノード10グループ又は全てのノード10への同じデータパケットの送信は、データパケットをブロードキャスト又はマルチキャストすることにより効率的に実現され得る図2参照。しかし、送信の成功を確認するために配信の保証が必要である場合、ブロードキャスト又はマルチキャスト送信が送達確認モードで実行される。すなわち、データパケットを受信した受信機Bは、送達確認ACKを送信機Aに送信することにより、送信の成功を確認する。しかし、送達確認モードの1つの大きな欠点は、送達確認データパケットが、ほとんどペイロードを含まないが、依然として全体のネットワークレイヤ及びMACレイヤのヘッダを必要とし、ネットワーク負荷に寄与する点にある。このことは、送達確認データパケットのオーバーヘッドが他のデータパケットに比べて非常に高く、このため、多くの場合に送達確認の送信がかなりの量の利用可能なペイロードを埋めることを意味する。従って、本発明の一実施例によれば、複数の独立した送達確認は、図3に示すように、1つの応答バッチに集約されてもよい。図3Aに、送達確認が同じ送信機Aから受信したデータパケットに対応する場合について、複数の送達確認を集約する実施例が示されている。受信機Bが送信機Aからデータパケットを受信した場合S300、受信機Bは、更にデータパケットが受信されるとしてもされないとしても、所定の時間待機するS301。このことは、集約が行われる可能性を高くする。従って、受信機Bは、この所定の期間中に受信したデータパケットへの送達確認を延期し、それぞれの送達確認を格納するS302。所定の時間が経過した後に、受信機Bは、複数のデータパケットが所定の時間間隔内に同じ送信機Aから受信されたか否かを判定する。複数のデータパケットが所定の時間間隔内に同じ送信機Aから受信された場合S303、S304において、これらのデータパケットの送達確認は1つの応答バッチ又は送達確認バッチACKバッチに集約される。ACKバッチは、1つの送信機Aに送信又はユニキャストされるS305。図3Bに、複数のデータパケットが異なる送信機Aから受信される場合について同様の処理が示されている。データパケットを受信した後にS300、受信機Bは、更にデータパケットが受信されるとしてもされないとしても、所定の時間間隔待機しS301、この時間の間に受信した送達確認を延期し、格納するS302。複数のデータパケットが所定の時間間隔内に異なる送信機Aから受信されたことが判定された場合S313、受信機Bは、送信機の1つ以上の適切なグループを判定してもよいS314。これは、受信データパケットに基づいてもよく、送信される応答に基づいてもよく、ネットワーク内の送信機Aの位置に基づいてもよく、受信機Bへの送信機Aのホップ距離に基づいてもよく、送信機Aのネットワークアドレスに基づいてもよい。しかし、例えば、送信機Aのグループが予め定められ、受信機Bに格納されている場合、適切なグループを判定するステップS314は省略されてもよい。最後に、1つの適切なグループの送信機Aの受信データパケットへの送達確認は、1つの応答バッチ又はACKバッチに集約されS315、ACKバッチがこのグループの全ての送信機Aに送信又はマルチキャストされるS316。従って、受信機Bは、受信データパケットの送信機Aをグループ化又はソートする。これは、コントロールセンタ60又はデータ収集ノード50が複数のノード10から送信される複数のデータパケットを送達確認する必要がある場合に、特に有用である。従って、基礎となる通信プロトコルに応じて、このような応答バッチをネットワーク効率の良いマルチキャストグループにマッピングすることが可能である。場合によって、必ずしも受信データパケットの全ての送信機Aが、送信機の適切なグループのうち1つに割り当てられなくてもよい。この場合、この送達確認は別々に送信されてもよい。更に、受信データパケットの送信機Aが必ずしも送信機の同じ適切なグループに割り当てられ得ないことが生じ得る。この場合、送信機のグループ毎に1つずつ、複数のACKバッチが送信されてもよい。前述の実施例の変形では、受信データパケットがタイムクリティカルの応答を含むか否かが更に判定される。応答データパケットがタイムクリティカルでない場合、応答の集約の可能性が増加するように、更に大きい待機期間が選択されてもよい。従って、所定の待機時間は、要求された応答時間に基づいて調整されてもよい。複数の受信データパケットについて異なる応答間隔が定められた場合、最も短い応答間隔が選択されてもよい。このような手段により、ネットワークリソースが更に効率的に節約され得る。前述の実施例並びに図3A及び3Bに示す実施例は、送達確認の集約に限定されない。複数の応答データパケットを1つの応答バッチに集約することにより、他のデータパケットを送信するときにヘッダも節約されてもよい。応答バッチ及び送達確認バッチは、それぞれ複数の独立した応答又は送達確認を有する。このように、ネットワークリソースが節約され、データトラヒックが低減され得る。送達確認モードでのマルチキャスト又はブロードキャストの場合に生じる更なる問題は、送信機Aで生じ、データの衝突及びロスを生じ得る、いわゆる送達確認ストームにある。従って、本発明の他の実施例によれば、データ送達確認は、図4に示すように各受信機Bによりランダムに更にスケジューリングされる。図4に、送達確認の送信について、本発明の他の実施例による最適化されたデータ送信が例示的に示されている。受信機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は、いつ最後の応答データパケットが遅くとも予想される必要があるかを自分で判定するため、再送信タイマの調整を更に最適化することができる。当然に、図4に示す処理はデータ送達確認に限定されない。これに対して、この処理は、マルチキャスト又はブロードキャストデータパケットへの何れかの応答例えば、マルチキャストデータ要求メッセージへの応答をスケジューリングするために適合されてもよい。このような手段により、受信マルチキャストデータパケットに応答するためのランダムなスケジュールが、アドホック的に各受信機Bでローカルに生成されるため、例えば送信機Aにおけるネットワークでのデータの衝突の確率を最小化する。本発明の更なる実施例では、データパケット特にタイムクリティカルでないデータパケットの送信は、データの衝突及びそれによるデータパケットロスを最小化するために、更にネットワークトポロジを考慮してスケジューリングされる。送信スケジュールは、N1又は1Nの通信パターン例えば、データ収集ノード50から複数のノード10への通信リンク又は複数のノード10からデータ収集ノード50への通信リンクに適用されてもよい。しかし、ノード10からデータ収集ノード50又はコントロールセンタ60への通信が反対方向より効率的であったとしても、依然として改良の余地及び必要性が存在する。この理由は、RFテレマネジメントシステムで通信される最大量の情報は、ノード10からの統計データ又は状態報告情報であるからである。従って、この実施例は、ノード10からデータ収集ノード50又はコントロールセンタ60へのN1通信に採用されることが好ましく、従って、この例を使用して説明する。送信スケジュールは、ネットワーク内の送信機Aの位置と、データ収集ノード50への送信機Aのホップ距離と、送信機Aのネットワークアドレスとのうち少なくとも1つに基づいてもよい。送信スケジュールがネットワーク内の送信機Aの位置に基づく場合、異なるエリアのノード10から通信リンク40が相互に干渉しないような異なるエリアが定められてもよい。このことは、特にデータ収集ノード50の周辺において、ネットワークの特定のボトルネックのエリアの過負荷を回避する。送信側ノード10は、そのネットワークアドレス又はMACアドレスを問い合わせることにより、その位置について検出してもよい。送信スケジュールは、コントロールセンタ60又はデータ収集ノード50により確立されて配信されてもよく、いつ異なるネットワークエリアのノード10がそのデータをコントロールセンタ60又はデータ収集ノード50に報告する予定であるかを示してもよい。別法として、コントロールセンタ60又はデータ収集ノード50は、ネットワークの位置に基づいてノード10にポーリングしてもよい。図5Aに、照明器具ノード10が街路に沿って配置されている街路照明システムが示されている。従って、照明器具ノード10がその統計データ例えば、電力状態、調光状態、周辺の明るさ等をデータ収集ノード50に報告する場合、データ送信は、空間的又は地理的グループに基づいてスケジューリングされてもよい。別法として、道路網に基づいて照明器具ノード10をグループ化することが有利になり得る。すなわち、同じ街路の照明器具ノード10はそのデータを同時に報告する。好ましくは、データ収集ノード50から離れた照明器具ノード10は、データ収集ノード50に近い照明器具ノード10より後の時点にそのデータパケットを送信する。前述の実施例の変形では、送信スケジューリングは、照明器具ノード10からデータ収集ノード50へのホップ距離に基づく。図5Bに示すように、複数ホップ送信を使用した無線メッシュ型ネットワークにおける照明器具ノード10は、データ収集ノード50へのホップ距離により分類されてもよい。ホップ距離は、データパケットを送信側ノード10からデータ収集ノード50に送信するために必要なホップ数に関係する。例えば、半径502と半径501との間の照明器具ノード10は、そのデータパケットを2つのホップで送信するが、半経501内の照明器具ノード10は、そのデータパケットを1つのホップで送信することができる。ホップ距離又はホップカウント情報は、照明器具ノード10のネットワークレイヤで利用可能になってもよい。1つの例示の実施例では、データパケットは、ホップ距離により定められたエリアからデータ収集ノード50にプログレッシブに順次に送信される。好ましくは、低いホップ距離のエリア例えば、半径501内は、最初に報告するようにスケジュールされる、或いは単にデータ収集ノード50により最初にポーリングされる。このような手段により、低いホップ距離のエリアの照明器具ノード10がそのデータパケットを報告すると、これらは高いホップ距離のエリアの照明器具ノード10からのデータパケットを転送するルータとしてのみ動作する。このような手段により、通常ではネットワークトポロジのため過負荷になる可能性が非常に高い低いホップ距離のエリアの照明器具ノード10が軽減される。場合によって、ネットワーク内の送信機Aの位置と、データ収集ノード50又はネットワークコントローラ60への送信機Aのホップ距離と、送信機Aのネットワークアドレスとのうち少なくとも1つに基づくデータパケット送信の空間的スケジューリングは、応答間隔内のタイムスロットのランダムな選択による時間的スケジューリング又は応答を1つの応答バッチに集約することによる時間的スケジューリングと組み合わされる。このような手段により、時間及び異なるネットワーク領域でネットワーク負荷のバランスを取ることが可能になる。前述の実施例の更なる変形では、送信スケジュールは、照明器具ノード10のネットワークアドレスに基づく。従って、照明器具ノード10は、例えばコントロールセンタ60又はデータ収集ノード50によりブロードキャスト又はマルチキャストされた報告要求メッセージを受信した後に、異なる時刻に応答データパケットを送信してもよい。ブロードキャスト又はマルチキャストメッセージは、全ての報告する照明器具ノード10の共通の基準としての役目をするタイムスタンプを含んでもよい。この基準時間と、ノード特有又はネットワークアドレス特有の遅延とに基づいて、各照明器具ノード10は、その個々の送信時間を判定してもよい。このことは、全ての照明器具ノード10からのデータパケットが比較的短い期間内に受信される一方で、衝突のリスクを更に最小化させる。これは、照明器具ノード10が状態データ等をN1の通信パターンでデータ収集ノード50又はコントロールセンタ60に報告する場合に特に有利である。ネットワークアドレスが動的に分配される場合、各ネットワークアドレスについて指定された遅延を備えたスケジュールテーブルが、各照明器具ノード10に格納されてもよい。ネットワークアドレスは、現在の要件に基づいて照明器具ノード10に動的に割り当てられ、これにより、個々の送信時間を判定してもよい。本発明の更なる実施例では、送信スケジューリングの実施例と同様に、データパケットの再送信のためにバックオフ遅延がMACレイヤ又はネットワークレイヤにより導入される。バックオフ遅延は、次の送信試行の間の遅延を示す。例えば、送信が失敗した場合、送信側ノードAは、バックオフ遅延だけデータパケットの再送信を遅延させてもよい。これにより、他のノードがその送信を完了してもよく、その結果、衝突の可能性を低減する。従って、バックオフ遅延は、媒体アクセス試行のためのバックオフ時間を含んでもよい。ここで、媒体アクセス試行は、キャリア検知及びその後の媒体が自由になると評価されたときのデータパケットの送信又は再送信の処理に関係する。従って、媒体アクセス試行のためのバックオフ時間は、次の媒体アクセス試行の間の時間間隔を示す。バックオフ遅延は、ネットワーク内のノード10の位置と、ノード10とデータ収集ノード50との間のホップ距離と、ノード10のネットワークアドレスとのうち少なくとも1つに基づいて設定される。好ましくは、MACレイヤ及びネットワークレイヤのバックオフ遅延のうち少なくとも1つは、ノード10とデータ収集ノード50との間の距離に依存する。特に、MACレイヤのバックオフ遅延及びネットワークレイヤのバックオフ遅延のうち少なくとも1つは、更なる遠隔のノード10の場合に長くなる。この場合、データ収集ノード50から離れたノード10は、データ収集ノード50に近いノード10よりデータパケットを散在させるようにさせてもよい。このような手段により、遠隔ノード10は、データ収集ノード50の近くにあるノード10において過負荷を生じさせない。従って、ネットワークノード10のデータトラヒックの生成は、データ収集ノード50の近くで輻輳を回避するようにシェーピングされる。有利には、この実施例は、前述の実施例のうち少なくとも1つと共に使用される。好ましくは、データパケット送信の遅延を含む前述の実施例は、ネットワークを通じて通信遅延の均一性に厳密な要件を有さないデータ送信及び/又はタイムクリティカルでないデータに適用される。例えば、このようなタイムクリティカルでないデータは、消費エネルギー、燃焼時間、動作状態、現在又は平均の調光パターン、検知された周囲の明るさ等のように、定期的な時間間隔でネットワークノード10により報告される統計データ又は状態情報を示してもよい。これに対して、タイムクリティカルの情報は、緊急の際にネットワークノード10に送信された制御メッセージの送達確認を示してもよい。前述の実施例は様々な方法で組み合わされてもよいことが明らかである。前述の応答を応答バッチに集約する手段を用いて、ローカル及びグローバルなネットワーク負荷が低減され、データパケットの衝突及びそれによるデータロスが回避され得る。従って、かなり効率的且つ信頼性の高いデータ送信を可能にし、高いスケーラビリティ及び高速且つ容易な設定を提供し、自己設定及び自己回復が可能な無線メッシュ型ネットワークのルーティング手段が提供される。