(57)【特許請求の範囲】
【請求項１】
ネットワークにおいて通信する方法であって、
第２のノードにより複数のチャネル各々において複数の第１のノードの各々から通信を受信するステップと、
前記複数の第１のノードの各々から正常に受信された各通信に対する応答を含む送信を前記第２のノードにより送出するステップと
を含み、
前記複数の第１のノードの各々に対する前記応答は、前記第２のノードにより送出される単一メッセージの一部であり、
前記単一メッセージ内の前記応答の少なくとも１つは、前記ネットワークにおける前記第１のノードの動作の設定を変更するために、前記第１のノードの少なくとも１つにより使用可能な情報を含み、
前記第１のノードは、少なくとも２つのグループに分割され、
第１のグループにおいて前記第２のノードに隣接する第１のノードは、前記第２のノードと直接通信し、
第２のグループにおいて前記第２のノードに隣接する第１のノードは、他の第１のノードと通信し、
前記第１のグループが前記第２のノードとの通信を完了すると、前記第２のグループにおいて前記第２のノードに隣接する第１のノードは、前記第２のノードと直接通信し、前記第１のグループにおいて前記第２のノードに隣接する第１のノードは、他の第１のノードと通信し、
前記通信は、前記第１のノードの少なくとも１つにより送出された要求を含み、
前記応答は、別のノードに前記要求を送出するように前記少なくとも１つの第１のノードに命令するコマンドを含む
ことを特徴とする方法。
【請求項２】
前記複数の第１のノードの各々から前記第２のノードへの前記通信は、送信元及び送信先の識別ヘッダを有するデータパケットを含む
ことを特徴とする請求項１記載の方法。
【請求項３】
前記第２のノードから前記複数の第１のノードへの各応答は、肯定応答を含む
ことを特徴とする請求項１記載の方法。
【請求項４】
前記第２のノードにより送出される前記メッセージは、前記第２のノードにより正常に受信された前記複数の第１のノードの各々の通信にそれぞれ対応する識別子を含む
ことを特徴とする請求項１記載の方法。
【請求項５】
各識別子は、８バイトＭＡＣアドレスを含む
ことを特徴とする請求項４記載の方法。
【請求項６】
各識別子は、８バイトＭＡＣアドレスよりも短いアドレスを含む
ことを特徴とする請求項４記載の方法。
【請求項７】
前記識別子は、前記第１のノードからの前記通信が受信された順番に基づく順番で前記メッセージ内に配列される
ことを特徴とする請求項４記載の方法。
【請求項８】
前記識別子は、各識別子の数値に基づく順番で前記メッセージ内に配列される
ことを特徴とする請求項４記載の方法。
【請求項９】
前記識別子は、前記複数の第１のノードの各々からの前記通信に関連付けられる内容に基づく優先順位に従って前記メッセージ内に配列される
ことを特徴とする請求項４記載の方法。
【請求項１０】
前記識別子は、前記複数の第１のノードの各々からの前記通信の送出元に基づく優先順位に従って前記メッセージ内に配列される
ことを特徴とする請求項４記載の方法。
【請求項１１】
前記第２のノードから前記複数の第１のノードへの各応答は、
正常に受信されたパケットを送出した前記複数の第１のノードの各々に対応するＭＡＣアドレスよりも短い事前割り当てアドレスに基づいて前記送信において順番付けられる
ことを特徴とする請求項１記載の方法。
【請求項１２】
前記事前割り当てアドレスは、
正常に受信されたパケットを送出した前記複数の第１のノードの各々に対応する前記ＭＡＣアドレスの所定のバイトである
ことを特徴とする請求項１１記載の方法。
【請求項１３】
前記事前割り当てアドレスは、
正常に受信されたパケットを送出した前記複数の第１のノードの各々に対応する前記ＭＡＣアドレスのハッシュである
ことを特徴とする請求項１１記載の方法。
【請求項１４】
前記第２のノードから前記複数の第１のノードへの各応答は、
受信パケットに関連付けられる優先順位に基づいて前記送信において順番付けられる
ことを特徴とする請求項１記載の方法。
【請求項１５】
前記第２のノードから前記複数の第１のノードへの各応答は、
前記受信パケットの内容に関連付けられる優先順位に基づいて前記送信において順番付けられる
ことを特徴とする請求項１４記載の方法。
【請求項１６】
前記第２のノードから前記複数の第１のノードへの各応答は、
前記受信パケットが受信された前記ノードに関連付けられる優先順位に基づいて前記送信において順番付けられる
ことを特徴とする請求項１４記載の方法。
【請求項１７】
前記第２のノードから前記複数の第１のノードへの各応答は、
前記ネットワークにおける周波数ホッピングパターンに関する情報に基づいて前記送信において順番付けられる
ことを特徴とする請求項１記載の方法。
【請求項１８】
前記応答は、種類−長さ−値（ＴＬＶ）形式でデータパケットに含まれる
ことを特徴とする請求項１記載の方法。
【請求項１９】
前記コマンドは、種類−長さ−値（ＴＬＶ）形式でデータパケットに含まれる
ことを特徴とする請求項１記載の方法。
【請求項２０】
前記要求は、ノードの実行可能なコードイメージの更新に対するものである
ことを特徴とする請求項１記載の方法。
【請求項２１】
前記要求は、ノードルーティングテーブル情報に対するものである
ことを特徴とする請求項１記載の方法。
【請求項２２】
前記要求は、セキュリティ警告情報に対するものである
ことを特徴とする請求項１記載の方法。
【請求項２３】
前記要求は、タイミング情報に対するものである
ことを特徴とする請求項１記載の方法。
【請求項２４】
前記複数の第１のノードの各々による前記通信の送出及び前記第２のノードによる前記送信の送出は、所定のタイムスロットの間に行われる
ことを特徴とする請求項１記載の方法。
【請求項２５】
前記複数の第１のノードの各々による前記通信の送出は、前記所定のタイムスロットの第１の部分の間に行われる
ことを特徴とする請求項２４記載の方法。
【請求項２６】
少なくともいくつかの通信の時間的重複が前記複数の第１のノードの各々による複数のチャネルにおける前記送出の間に存在する
ことを特徴とする請求項２４記載の方法。
【請求項２７】
前記第２のノードによる前記送信の送出は、前記所定のタイムスロットの第２の部分の間に行われる
ことを特徴とする請求項２５記載の方法。
【請求項２８】
前記所定のタイムスロットに関する情報は、ビーコンパケットで前記第１のノードに送出される
ことを特徴とする請求項２４記載の方法。
【請求項２９】
前記ビーコンパケットは、タイミング同期情報、タイミングシーケンス情報及びチャネル情報の少なくとも１つを含む
ことを特徴とする請求項２８記載の方法。
【請求項３０】
ネットワークにおいて通信する方法であって、
第１のノードにより所定の時間に所定のチャネルを監視するステップと、
データが前記所定の時間に前記所定のチャネルにおいて受信されたかを前記第１のノードにより判定するステップと、
データが受信された場合に単一チャネル受信側ノード又はマルチチャネル受信側ノードに受信データを転送するかを前記第１のノードにより判定するステップと、
前記データが前記マルチチャネル受信側ノードに送出されると判定された場合に前記第１のノードにより前記マルチチャネル受信側ノードに前記受信データを送信するステップと、
前記データが前記マルチチャネル受信側ノードへ送信されると、前記第１のノードにより所定の応答チャネルを監視するステップと、
前記所定の応答チャネルを監視することにより、前記第１のノードが前記マルチチャネル受信側ノードにより送信された送信データに対する応答を受信したかを前記第１のノードにより判定するステップと、
前記第１のノードが前記マルチチャネル受信側ノードから応答を受信していないと判定された場合、前記第１のノードにより前記マルチチャネル受信側ノードへ前記データを再送信するステップと
を含み、
前記第１のノードは、少なくとも２つのグループに分割される複数の第１のノードの１つであり、
第１のグループにおいて前記マルチチャネル受信側ノードに隣接する第１のノードは、前記マルチチャネル受信側ノードと直接通信し、
第２のグループにおいて前記マルチチャネル受信側ノードに隣接する第１のノードは、他の第１のノードと通信し、
前記第１のグループが前記マルチチャネル受信側ノードとの通信を完了すると、前記第２のグループにおいて前記マルチチャネル受信側ノードに隣接する第１のノードは、前記マルチチャネル受信側ノードと直接通信し、前記第１のグループにおいて前記マルチチャネル受信側ノードに隣接する第１のノードは、他の第１のノードと通信する
ことを特徴とする方法。
【請求項３１】
前記所定のチャネル、前記所定の時間及び前記所定の応答チャネルの少なくとも１つは、ビーコンパケットにより前記第１のノードに提供される
ことを特徴とする請求項３０記載の方法。
【請求項３２】
前記情報は、ネットワークタイミング情報を含む
ことを特徴とする請求項１記載の方法。
【請求項３３】
前記情報は、ネットワークプロトコルのレイヤ２／レイヤ３の少なくともいずれかにおける、前記少なくとも１つの第１のノードの動作に関する少なくとも１つの変数を含む
ことを特徴とする請求項１記載の方法。
【請求項３４】
前記情報は、前記少なくとも１つの第１のノードに対するコマンドを含み、
前記コマンドは、該コマンドにより示される特定の動作を実行するように前記少なくとも１つの第１のノードに命令する
ことを特徴とする請求項１記載の方法。
【請求項３５】
前記特定の動作は、前記少なくとも１つの第１のノードに前記第２のノード以外の異なるノードへ前記通信を再送出させる動作である
ことを特徴とする請求項３４記載の方法。
【請求項３６】
前記情報は、前記単一メッセージの応答内の種類−長さ−値（ＴＬＶ）要素の少なくとも１つの中に符号化されている
ことを特徴とする請求項３１記載の方法。
【請求項３７】
前記ＴＬＶ要素の各々は、それぞれの前記第１のノードのうちの１つに対応する
ことを特徴とする請求項３６記載の方法。
【請求項３８】
ＴＬＶ要素の各々の種類フィールドは、当該ＴＬＶ要素が対応するそれぞれの前記第１のノードのうちの１つを示す
ことを特徴とする請求項３７記載の方法。
【請求項３９】
ネットワークにおいて通信する方法であって、
第２のノードにより複数のチャネル各々において複数の第１のノードの各々から通信を受信するステップと、
前記複数の第１のノードの各々から正常に受信された各通信に対する応答を含む送信を前記第２のノードにより送出するステップと
を含み、
前記複数の第１のノードの各々に対する前記応答は、前記第２のノードにより送出される単一メッセージの一部であり、
前記単一メッセージ内の前記応答の順番は、
前記複数の第１のノード各々から前記第２のノードにより受信された前記通信に関連付けられる優先順位に対応しており、
前記第１のノードは、少なくとも２つのグループに分割され、
第１のグループにおいて前記第２のノードに隣接する第１のノードは、前記第２のノードと直接通信し、
第２のグループにおいて前記第２のノードに隣接する第１のノードは、他の第１のノードと通信し、
前記第１のグループが前記第２のノードとの通信を完了すると、前記第２のグループにおいて前記第２のノードに隣接する第１のノードは、前記第２のノードと直接通信し、前記第１のグループにおいて前記第２のノードに隣接する第１のノードは、他の第１のノードと通信する
ことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、通信ネットワークの分野に関し、特に、無線メッシュネットワークに関する。
【背景技術】
【０００２】
例えば、無線周波数（ＲＦ）スペクトルにおける別個の周波数である複数の媒体を使用する大規模なメッシュネットワークにおいて、一般に、一部のノードが他のノードより大幅に混雑するため、メッシュにおいて障害が発生する。これらのノードの例としては、メッシュ内のエンドポイントを制御中であるか又は種々のノードから情報を受信中であるアクセスポイント（ＡＰ）又はゲートウェイを含む。
【０００３】
障害の問題に対する可能な解決策としては、ＡＰの数を増加することが挙げられるが、そのような手法には制限がある。例えば、
１）ＡＰの数にほぼ比例してコストが増加する。
２）物理法則による制限が近接して配置される送信機と受信機との間に存在する。
３）相互干渉を排除するため、無許可スペクトルにおける規制は無許可ノード間の協同を制限する。
【０００４】
この後者の点に関して、米国連邦通信委員会（ＦＣＣ：U.S.Federal Communications Commission）により公布された４７ ＣＦＲ １５．２４７に準拠する周波数ホッピングスペクトラム拡散（ＦＨＳＳ：Frequency Hopping Spread Spectrum）装置（及びより一般的には、世界中の準拠する無許可装置）に対する制限は、無線を平等に使用する方法でＲＦスペクトルの無許可部分を共有する機会を提供するように設計される。電力制限、チャネル占有率（累積ドウェル時間）、帯域幅等の全ては、相互互換性のある装置を共存させるために特定の制限を有する。
【０００５】
これらの無線のいくつかのアプリケーションは、従来の２点間通信を含む。例えば、ＩＥＥＥ規格８０２．１１「ＷｉＦｉ」は、デジタル情報の短距離転送のための相互運用機器を提供するために開発された。より広い範囲を必要とするアプリケーションは、送信元から送信先に移動するためのルーティングと呼ばれる処理において通信がノード間をホップするネットワークを形成するため、複数の無線を１つに組み合わせようとした。このメッシュにおけるネットワーク動作は、ピアツーピア形式で実行される。この場合、ネットワークの効率的且つ頑強な通信を維持するため、ネットワーク保守及びオーバーヘッドトラフィックは隣接する全ノード間で送出される。
【０００６】
メッシュネットワークは、極めて正常に動作することが判っており、地理的に分布する大きなネットワークの多くの例が存在する。通常、これらのネットワークのアーキテクチャは、メッシュネットワークへの入口及び出口を提供するアクセスポイント（ＡＰ）として知られる少数のノードのみが存在する処理制御モデルをサポートする。メッシュネットワーク内の種々の終端ノードは、これらのアクセスポイントエントリノードからアクセス可能である。要求及びコマンドは、ＡＰを介して送出され、応答及び肯定応答はＡＰを介して返される。多くの終端ノードと通信することが望まれる場合、ＡＰにおけるトラフィックの集中によりメッシュネットワークにおいてトラフィック障害が発生する場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述した制限を解決するために、いくつかの方式が使用されている。それらの方式の一部は、以下のうちの少なくとも１つのようなデータ量又はデータの送信方法に関する。
・データ圧縮（ＡＰにおいて必要とされる帯域幅を縮小するため、データのバイト数を減少して送出する）
・自律的メッセージ通信（一方向のみにデータを送出する）
・時間（一時的）及び優先順位付け（待ち行列作成技術）の双方によるデータトラフィックの調整又はスケジューリング
【０００８】
他の方式は、輻輳の問題を解決するためのメッシュネットワークのインフラストラクチャに関し、例えば、無線ネットワークの範囲内に、より多くのＡＰを配置する。例えば、複数のＡＰが特定の場所で並行動作しても良い。しかし、この手法はコストが比例して増加し、場合によっては非常に高額になる。
【０００９】
並行動作する多くの送受信機（送信機／受信機の対）を使用するのではなく、本明細書中で開示される好適な方法及びシステムは、複数の並行チャネルを有するＡＰを利用し、１つ以上の受信パケット送信元に対する単一パケットに、例えば、複数の肯定応答（ＡＣＫ）を送信する送信応答の通信を集約又はスタックする。
【課題を解決するための手段】
【００１０】
一実施形態において、ネットワークにおいて通信する方法は、複数の第１のノードの各々により複数のチャネルにおいて第２のノードに通信を送出するステップと、第２のノードにより複数のチャネルにおいて複数の第１のノードの各々から通信を受信するステップと、複数の第１のノードの各々から正常に受信された各通信に対する応答を含む送信を第２のノードにより送出するステップとを含む。複数の第１のノードの各々に対する応答は、第２のノードにより送出される単一メッセージの一部である。
【００１１】
別の実施形態において、ネットワークにおいて通信する方法は、第１のノードにより所定の時間に所定のチャネルを監視するステップと、データが所定の時間に所定のチャネルにおいて受信されたかを第１のノードにより判定するステップと、データが受信された場合に単一チャネル受信側ノード又はマルチチャネル受信側ノードに受信データを転送するかを第１のノードにより判定するステップと、データがマルチチャネル受信側ノードに送出されると判定された場合に第１のノードによりマルチチャネル受信側ノードへ受信データを送信するステップと、データがマルチチャネル受信側ノードへ送信された後に第１のノードにより所定の応答チャネルを監視するステップと、所定の応答チャネルを監視することにより第１のノードがマルチチャネル受信側ノードにより送信された送信データに対する応答を受信したかを第１のノードにより判定するステップと、第１のノードがマルチチャネル受信側ノードから応答を受信していないと判定する場合に第１のノードによりマルチチャネル受信側ノードへデータを再送信するステップとを含む。
【図面の簡単な説明】
【００１２】
【図１】ＲＦメッシュネットワーク内のゲートウェイを含むシステムにおける通信を概略的に示す図である。
【図２】ＲＦメッシュネットワークにおけるマルチチャネル通信を概略的に示す図である。
【図３Ａ】ノードにおける入力パケット及び応答パケットの応答形式の例を示す図である。
【図３Ｂ】ノードにおける入力パケット及び応答パケットの応答形式の例を示す図である。
【図３Ｃ】ノードにおける入力パケット及び応答パケットの応答形式の例を示す図である。
【図３Ｄ】ノードにおける入力パケット及び応答パケットの応答形式の例を示す図である。
【図４Ａ】マルチチャネルゲートウェイにおける受信機及び送信機の好適な実施形態を示すブロック図である。
【図４Ｂ】マルチチャネルゲートウェイにおける受信機及び送信機の好適な実施形態を示すブロック図である。
【図５】一実施形態に係るマルチチャネルアクセスポイントのタイミングシーケンスの一例を示す図である。
【図６Ａ】パケット出力サイクルのタイミングを示す図である。
【図６Ｂ】パケット出力サイクルのタイミングを示す図である。
【図７】マルチチャネルアクセスポイントを有するメッシュネットワークの処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１３】
理解されるように、異なる実施形態が可能であり、本明細書中で開示される詳細は、請求の範囲の範囲から逸脱することなく種々の面において変更可能である。従って、図面及び説明は例証するものであって制限するものではないと考えられるべきである。同様の図中符号は同様の要素を示すために使用される。
【００１４】
本明細書中で説明される方法及びシステムは、一般に、双方向通信が送出側ノード又は送信元ノードと受信側ノード又は送信先ノードとの間で行われるメッシュネットワークに関する。双方向通信の一例は、送信元ノードが送信先ノードにデータパケットを送出し、データパケットが正常に受信されたことを送信元ノードに通知するために送信先ノードが肯定応答パケット、すなわち「ＡＣＫ」パケットを用いて応答する場合に行われる。一般的なネットワークプロトコルに従って、データパケット送出後のある特定の時間内に送信元ノードがＡＣＫパケットを受信しない場合、送信元ノードは、ＡＣＫパケットを受信するか又はタイムアウト条件が発生するまで、定期的な間隔でデータパケットを再送出しても良い。
【００１５】
双方向通信の他の例も、一般的なネットワークにおいて通常行われている。例えば、送信元ノードは、ネットワークの動作に関する特定の種類の情報に対する要求をゲートウェイ又はアクセスポイント等の送信先ノードに送出しても良い。この情報は、ルーティングテーブル、保守の更新、ＩＰアドレス等であっても良い。そのような各要求に応答して、送信先ノードは、要求に応答する情報又は要求に応じられないことを示すエラーメッセージの形式を返す。
【００１６】
従来、送信元ノードと送信先ノードとの間の双方向通信は一対一で行われていた。すなわち、送信先ノードで受信された例えばパケットであるメッセージ毎に、送信先ノードは送信元ノードにユニキャスト返答を送出していた。本明細書中で開示される好適な方法及びシステムに従って、障害の問題を軽減するために一対多形式が返答の送信に採用されても良い。方法及びシステムが基づく原理の理解を容易にするため、送信先ノードによる応答送信として肯定応答を参照して、好適な実施形態を以下に説明する。しかし、これらの原理は、送信先ノードから送信元ノードに返される他の種類の応答送信にも同様に適用可能であることが理解されるであろう。
【００１７】
図１は、標準的な無線周波数（ＲＦ）メッシュネットワーク１００を概略的に示す図である。図１に示すネットワークは、少なくとも１つのアクセスポイントを含む。アクセスポイントは、メッシュネットワーク１００と、例えば、ワイドエリアネットワーク（不図示）である別のネットワークとの間のインタフェースとして機能するゲートウェイＧＷであっても良い。ゲートウェイＧＷは、送信機と、少なくとも１つの周波数で送信された信号及びより好ましくは複数の周波数で送信された信号を受信できる受信機とを含む。送信機により、ゲートウェイは適切な信号伝播範囲内の他の何らかの送受信機と通信できる。一実施形態において、ゲートウェイは、図１中で記号「Ｔｘ」により識別される標準的な単一送信機／単一受信機の送受信機の「海（sea）」により包囲されても良い。例えば、送受信機ＴＸは、ユーティリティネットワーク内のメータノードを表しても良く、例えば、ゲートウェイＧＷは、ユーティリティネットワーク内のメータノードに関連付けられる種々のバックオフィス機能へのアクセスを提供しても良い。
【００１８】
図１に示すように、ゲートウェイと通信する複数の送受信機が存在しても良い。本実施形態において、送受信機は一度に１つずつゲートウェイへ送信する。これらの送信及びその順番を図１の番号付きの矢印線で示す。実線は、送受信機からゲートウェイへの送信又は互いに中継器として動作する送受信機ノード間の送信のいずれかである正常に受信された送信を示す。正常な各送信の後、ゲートウェイは肯定応答を用いて送出側送受信機に即座に応答する。従って、データパケットがタイムスロット１において受信される場合、ゲートウェイはＡＣＫパケットを用いて応答する。その後、別のデータパケットがタイムスロット２において受信される場合、ゲートウェイは当該パケットを送信した送受信機にＡＣＫパケットを送出する。ＡＣＫパケットは、パケットが送信された個々の送信元ノードに一度に１つずつ送出される。
【００１９】
図１の破線は失敗を示す。密集して相互接続されたメッシュネットワークにおいて、失敗の原因は２つ考えられる。すなわち、パケットの衝突及び指定受信機が使用不能であることである。パケットの衝突は、２つ以上のノードが同一周波数でほぼ同時に送信したため、それらの各パケットが重複し、いずれの送信も指定受信機で正常に受信されない結果発生しても良い。タイムスロット４において共にゲートウェイに向う破線でこの状態を示す。
【００２０】
受信機が使用不能であることによる失敗は、指定受信機がパケットを受信するのに必要な時間中に送信周波数において信号を受信できない場合に発生しても良い。この状況は、指定受信機が、例えば、周波数ホッピングプロトコルを採用するネットワーク内の別のノードからパケットを受信するために異なる周波数上に存在する場合に発生しても良い。別の例として、図１中のタイムスロット１を表す線は、ゲートウェイへの正常な（実線）送信及びゲートウェイへの通信中は、オフチャネルである同一受信機に向けた失敗した（破線）送信を示す。
【００２１】
これらのアクセス失敗状態は、スケジューリングを介して緩和されても良く、これは、データトラフィックが決定論的である場合に有効であっても良い。データトラフィックが予測不能である場合、例えば、データトラフィックが自律的又は反応的に発生される場合、スケジューリングの効果は低い。
【００２２】
また、図１に示すように、タイムスロット２において複数の正常な送信が存在しても良い。本明細書中で一実施形態を開示する周波数可変メッシュネットワークにおいて、隣接しないノードは、同一周波数を同時に占有しても良いため、必然的に周波数再利用機能を形成し且つ有する。
【００２３】
図示するように、ゲートウェイに送出されるパケットに通し番号を付与することにより、ＲＦメッシュネットワークにおいて障害を発生させる場合がある。ゲートウェイへの直接リンクを有する各送受信機は、正常に受信されるためにスケジュールされたか又は他と衝突しない一意の時間にメッセージを送出する必要がある。各メッセージの受信後、ゲートウェイは、次のメッセージに移動する前に応答する。一般に、ゲートウェイは、ＲＦメッシュネットワークへの入口及び出口を提供しても良いという点でアーキテクチャがほぼ一意であっても良い。従って、ゲートウェイの受信機及び送信機による制限は、ＲＦメッシュネットワークの性能に影響を及ぼす場合がある。
【００２４】
この問題を解決するため、図２は、マルチチャネルノードの好適な一実施形態における送信を示す。本実施形態において、例えば、ゲートウェイであるノードは、ＲＦメッシュネットワークにおいて同時に複数のチャネルで受信するように構成される。パケットは、時間領域で重複する場合であっても周波数領域で衝突しないように、異なる周波数で送出されても良い。図２に示すように、種々のメッセージがタイムスロット１においてゲートウェイで受信されている。
【００２５】
非マルチチャネル装置（例えば、図２に示す送受信機ノードＴｘ）は、送信及び受信を同時に行えない。従って、同時に送信しているノードに向けられた送信は失敗する場合がある。
【００２６】
入力データパケットを異なる周波数で同時に受信することは周波数スペクトルの衝突防止に有用である。しかし、これにより何らかの可能なＡＣＫ（送出側ノードに返される）が時間的に衝突する状況になる場合がある。図１の実施形態において、ＡＣＫは関連するデータパケットの受信後に即座に送信されるのが理想的である。しかし、図２のマルチチャネルノードの場合、ゲートウェイが受信中に送信できず且つ送信中に受信できないため、データパケットの受信後に即座にＡＣＫを送信できない場合がある。
【００２７】
図３Ａは、ノードにおけるパケットの受信及び肯定応答の一般的なシーケンスを示す。送出側ノードは、パケットがアドレス指定される受信側ノードのアドレス及び送信側ノードのアドレス、並びに送信されるデータを含むデータパケットを送信する。パケットがアドレス指定される例えばゲートウェイであるノードは、送出側のアドレスと受信側のアドレスとを入れ替え且つ肯定応答インディケータを追加することによりＡＣＫパケットを作成する。その後、受信側ノードは元の送出側ノードへＡＣＫパケットを送信する。
【００２８】
複数のパケットが同一タイムスロットにおいて異なる周波数で受信される場合、受信側ノードはこの方法でＡＣＫパケットを作成して即座に返せない場合がある。この状況を解決するため、ＡＣＫは集約又はスタックされ、受信側ノードにより送信される単一応答パケットの一部として一斉に送出される。図３Ｂは、スタックＡＣＫパケットの概念を示す。一実施形態において、送出側ノードは、例えば、図３Ａに示す場合と同一のデータパケット形式を使用しても良い。しかし、図３Ｂの例において、ゲートウェイは、図２の実施形態と同様に、送出側ノードにより複数のチャネルにおいて同時に送信されたパケットを受信するように構成されても良い。図３Ｂは、Ｎ個のデータパケットがゲートウェイで受信される例を示す。これに応答して、単一ＡＣＫパケットが作成される。このパケットは、全ノードにより認識される同報通信アドレス及び受信側ノードのアドレスを含む。パケットは、データパケットが正常に受信された送出側ノード１〜Ｎの各々に対する識別子を更に含む。そのような同報通信パケットの受信に応答して、各ノードはパケット内で自身の識別子を探し、識別子を見つけた場合、パケットをＡＣＫパケットとして処理する。
【００２９】
図３Ｃは、スタックＡＣＫパケットのフレーム構造の好適な一実施形態を示す。本実施形態において、フレームは、同報通信アドレス及び応答側ノードのアドレスの後ろに、このパケットの種類をＡＣＫとして識別するフィールドを含む。しかし、このフレームの種類のフィールドは不要であっても良い。例えば、送出側ノードは、特定の時間内に送信先ノードから受信した自身の識別子を含む何らかの同報通信フレームがＡＣＫパケットを構成すると認識しても良い。
【００３０】
「メタＡＣＫ（meta-ACK）」として以下に示す応答パケットにＡＣＫをスタックするいくつかの限定しない方法が存在しても良い。種々の例を以下に示す。
ｉ．メタＡＣＫは、データパケットの受信順で挿入された全受信データパケットの送信元の完全な８バイトＭＡＣアドレスを含んでも良い。
ｉｉ．メタＡＣＫは、受信順で挿入された各データパケットの送信元の予め決められた単一バイト又はショートアドレスを有しても良い。ショートアドレスは、ユニキャストパケットに使用される８バイトＭＡＣアドレスよりはるかに短い事前割り当てアドレスであっても良い。例えば、ショートアドレスは、完全なＭＡＣアドレスの最後のバイト又はＭＡＣアドレスのハッシュであっても良い。このアドレスの省略の結果、メタＡＣＫのサイズは半分又は１／４になっても良い。
ｉｉｉ．アドレスは、受信順を使用するのではなく、受信パケットに関連付けられる優先順位に基づく優先順に配置されても良い。例えば、優先順位は、障害報告等の送出側ノードが送信している内容の性質又は送出側ノードのシャットダウン前の「最後の」送信に基づいても良い。あるいは、順番は特定の送出側ノードに関連付けられる優先順位に基づいても良い。
ｉｖ．アドレスは、送信元ノードの周波数ホッピングパターンの予見等の他の基準を反映した順番で配置可能である。
ｖ．アドレスは、自身のデータが受信されたかをリスニングノードがメタＡＣＫにおいて早い段階で判定できるように数値順で配置可能である。例えば、リスニングノードがショートアドレス５を割り当てられ且つアドレス２、３、７等を受信する場合、リスニングノードは自身のＡＣＫがメタＡＣＫ内に存在しないと判定しても良い。アドレス７を受信した時点で、ノードは自身に対するＡＣＫが存在しないため、自身のデータパケットが受信されなかったと判定できる。
【００３１】
いくつかの例において、入力される要求に対する応答を実行するのに相当な時間がかかる場合があり、これは、そのような要求を受信する使用中のＡＰにおいて障害が発生する一因となる。そのような要求の例は、ノードの実行可能なコードイメージの更新に対する要求、ノードルーティングテーブル情報に対する要求、セキュリティ警告（例えば、認証を確認できないノードの識別）、タイミング情報（ドリフト率及び絶対時間又は周波数）に対する要求等を含む。一実施形態において、これらの種類の要求は、それらを処理する能力がより高い異なるノードに委ねられても良い。異なるノードに委ねるため、要求を受信したマルチチャネルＡＰは、応答を用意する際に、要求を実行するために異なるノードへ進むように送信元ノードに命令するコマンドをスタック応答のセットに含めても良い。このコマンドを受信した場合、送信元ノードは、コマンドにおいて識別された他のノードをアドレス指定した要求を再送出する。
【００３２】
要求を転送される他のノードは、終端ノードの異なるクラスを処理するために確立される別のマルチチャネル受信側ノードであっても良い。これは、例えば、ユーティリティネットワーム内の配電自動化（ＤＡ：Distribution Automation）ノードをサポートするために別個のインフラストラクチャが配置される場合に当てはまっても良い。ＤＡノードが電源回路網の接続性を切り替え且つ制御するノードであるため、それらは消費を監視するメータと関連付けられるノードよりユーティリティに対する優先順位が高い。従って、ＤＡインフラストラクチャは、それらＤＡノードに対するより高速、高信頼又は高セキュリティの通信を提供するように設計されたポリシーを実行するために部分的に「分離状態」であるように維持可能である。
【００３３】
要求が特定の送信元ノードを意図するデータを含むため、上述のコマンド機能等のＡＣＫ以外のスタック応答は異なるフレーム形式を必要とする。一実施形態において、この種類のスタック応答は、種類−長さ−値（ＴＬＶ）要素を含むデータパケットを介して実現されても良い。データ通信プロトコルにおいて、オプションの情報がＴＬＶ要素としてプロトコル内に埋め込まれても良い。各ＴＬＶ要素は以下のフィールドを含む。
種類：メッセージのこの要素がコマンド等を示すフィールドの種類を示す数値コード。
長さ：値フィールドのサイズ（通常は、バイト単位）。
値：コマンド自体等、メッセージのこのＴＬＶ要素に対するデータを含むサイズ変更可能なバイトのセット。
種類フィールド及び長さフィールドのサイズは固定されても良い（通常は、１〜４バイト）。一方、送信されるデータを収容するため、値フィールドのサイズは可変である。
【００３４】
ＴＬＶ要素を採用するスタック応答フレームの形式の例を図３Ｄに示す。図３ＣのスタックＡＣＫフレームと同様に、最初の３つのフィールドは、同報通信アドレス、応答を送出する例えばゲートウェイであるマルチチャネルノードのアドレス及び本実施形態では「ＴＬＶ」であるフレームの種類を含む。フレームのペイロード部分は、例えば、ショートアドレスである要求側ノードの一連の識別子Ｓ１、Ｓ２、．．．ＳＮを含み、各識別子の直後に対応するノードに対するＴＬＶを含む。この種類のフレームを構文解析する場合、ノードは、それが自身のものであるかを判定するために最初の識別子を確認する。自身のものではない場合、ノードは、識別子に後続し且つ連続する次の識別子に対するオフセットを提供するＴＬＶの長さフィールドを調べる。この処理は、ノードが自身の特定の識別子を認識するか又はフレームの終端に到達するまで続行される。自身の識別子に一致する識別子を見つけると、ノードは、その識別子に後続するＴＬＶ要素全体を調べ、スタックフレームでそれに送出された応答を取得する。
【００３５】
一実施形態において、ゲートウェイは、何らかの種類のネットワーク構成情報を含むＴＬＶのセットを送出できる。この情報は、例えば、ゲートウェイの広域にルーティング可能なＩＰｖ６接頭辞、ゲートウェイのＭＡＣアドレス、ＤＮＳサーバアドレス、ルーティングの更新、ネットワークタイミング情報及びＯＳＩモデルのレイヤ２／レイヤ３のルーティングに関する他の何らかの変数を含んでも良い。
【００３６】
なお、メタＡＣＫとビーコンパケットとの間には違いが存在する場合がある。例えば、従来の同報通信に含まれる情報は、通常は、特定のノードを宛先としない。すなわち、情報は、送信側ノードに関するものであり、範囲内のあらゆる受信機に配布される。例として、ビーコンのフレーム形式を以下に示す。
0005587888.tif 000002
【００３７】
ビーコンメッセージと同様に、メタＡＣＫは同報通信送信先アドレスを有する。あるいは、より効率的に、同報通信の種類が黙示的であるがフレームの種類がＡＣＫである場合、メタＡＣＫは送信先アドレスを有さない。本実施形態において、（１）メタＡＣＫの周波数をリスニングしており且つ（２）データを最近送信したノードは、このメタＡＣＫに関心を持つ。従って、メタＡＣＫ内のデータは、送信側ノードではなく、データ送出元に関する。
【００３８】
マルチチャネルノードは、種々の方法で実現可能である。例えば、マルチチャネルノードは、単一の送信機及び複数の受信機から構成されても良い。それらの受信機の各々は、通信が受信されても良い異なる周波数に同調される。ハードウェアの使用量が少ないためより安価である別の手法は、同時に受信される複数の信号を区別するためにデジタル信号プロセッサ（ＤＳＰ）を採用できる。図４Ａ及び図４Ｂは、上記の後者の実現に基づくマルチチャネルノードのシステムの一例を示す図である。
【００３９】
マルチチャネルゲートウェイの受信部の一例を示す図４Ａを参照すると、ノードにより異なるチャネル、すなわち、異なる搬送周波数で同時に送信される複数のＲＦ信号はアンテナ１０で受信され、不要な信号及び他のノイズから所望の周波数の信号を分離するために適切な増幅１１、並びにフィルタリング１２、１３及び１４が実行される。一実施形態において、アンテナ１０は９００ＭＨｚ周辺の無許可帯域のＲＦ信号を受信するように構成されても良い。その後、フィルタリングされた信号は、Ａ／Ｄコンバータ１５においてデジタル信号に変換され、その結果得られたデジタル信号はＤＳＰ１６に供給される。ＤＳＰ１６への入力は、異なるチャネルにおいて同時に受信された全ての送信信号の組み合わせを含んでも良い。ＤＳＰは、この組み合わせを個別の信号に分離するように動作する。ＤＳＰエンジンの出力は、正常な状態に戻されたバイナリデータであり、これらは隣接するプロセッサ（不図示）のプロトコルプロセッサに提示するためにインデックス及び通し番号を付与されても良い。市販のＤＳＰの一例としては、カリフォルニア州のＳａｎ ＪｏｓｅのＸｉｌｉｎｘ社により製造されるＳＰＡＲＴＡＮシリーズのフィールドプログラマブルゲートアレイＤＳＰが挙げられる。
【００４０】
一実施形態において、図４Ａに示すマルチチャネルシステムの例が、ＤＳＰエンジンを用いて処理するため、ベースバンドに対する相対的に大きな（マルチチャネル）スペクトルを処理できる。ＤＳＰ１４は、高速フーリエ変換（ＦＦＴ：Fast Fourier Transform）技術を使用して、逓減されたスペクトル内の多くのチャネルの各々に対するＦＦＴビン（bin）を作成する。一実施形態において、最大で２４０個のチャネルが存在しても良い。９００ＭＨｚ周辺の搬送周波数を使用する一実施形態において、約８３個のチャネルが存在しても良い。実際は、これらのビンは、各チャネルに対する別個の受信機として動作しても良い。各チャネルにおける受信データは、それが正常に受信されたパケットを構成するかを判定するために別個に処理される。受信データが正常に受信されたパケットを構成する場合、ＡＣＫ又は他の適切な応答が同時に受信された他のパケットに対する応答と共に累積するために用意され、メタＡＣＫ又はスタック応答を含む他の同様のパケットで返される。
【００４１】
図４Ｂは、マルチチャネルゲートウェイのマルチチャネル送信部の一例を示す。図４Ａの受信部で使用されたのと同様の構成要素は、送信部において同様に使用可能である。更に、受信ＤＳＰにおいて使用されたデジタル処理ソフトウェアは送信ＤＳＰにおいて使用されても良い。例えば、受信ＤＳＰは、ＦＦＴソフトウェアを使用しても良く、送信ＤＳＰは逆ＦＦＴソフトウェアを使用しても良い。
【００４２】
送信部の例において、複数の送信信号は、ＤＳＰにおいてフーリエ係数を構成することにより作成されても良い。これは、デジタル信号処理の当業者には既知である。例えば、振幅係数が０に設定される場合、エネルギーはそのチャネル又は周波数において出力されない。振幅係数が０．２５に設定され且つ３つの他の係数が同様に０．２５に設定される場合、長さの等しい４つの信号が生成されても良い。振幅係数は、特定のチャネルにおいて宛先とされるノードまでの所定の信号パスを充分に範囲に含むために必要であると推定される信号エネルギーに基づいて確立されても良い。
【００４３】
図５は、一実施形態に係るマルチチャネルアクセスポイントに対するタイミングシーケンスの一例を示す図である。メッシュネットワークの一例において、データは、例えば、１００ｋｂｐｓで送信されても良く、これは約１０バイト／ｍｓである。この対応を適用すると、本実施形態においては、５００バイトのような大きいデータパケットの送信には５０ｍｓが必要であり、例えば、１５００バイトのようなより大きいパケットの送信には１５０ｍｓが必要である。
【００４４】
図５に示すように、メッシュネットワークの一例における１秒、すなわち、１０００ｍｓは、例えば、２００ｍｓのスロットに分割されても良く、それらは、アクセスポイントへのインバウンドデータのための１５０ｍｓのサブスロット及びアクセスポイントからのアウトバウンドデータのための５０ｍｓのサブスロットに更に分割されても良い。
【００４５】
従って、図５に示すタイミングシーケンスの構成例は、各秒が５つのマルチノード交換スロットを含んでも良いことを示す。例えば、ノード１〜４は、２００ｍｓスロットのうちの１５０ｍｓのインバウンドサブスロットの間にアクセスポイントに別個の周波数で同時に通信しても良い。アクセスポイントは、５０ｍｓのアウトバウンドサブスロットの間にノード１〜４から正常に受信された各通信に対する応答を送信しても良い。本実施形態において示すように、マルチチャネルアクセスポイントからノード１〜４の各々への応答は、アクセスポイントにより送出される単一メッセージの一部であっても良い。同様のシーケンスは、他の２００ｍｓのスロットの間に続行しても良い。本実施形態において、例えば、アクセスポイントであるマルチチャネルノードは、２００ｍｓ毎に応答パケットを送信する。このパケットは、２００ｍｓのスロットのインバウンドサブスロットの間に正常に受信された全てのインバウンドパケットに対する例えばＡＣＫであるスタック応答を含む。
【００４６】
いくつかのノードは、マルチチャネルアクセスポイントにデータを出力中であっても良く、データを受信中の他のノードは、アクセスポイントへ送信できない。そのため、ノードは、データを交互に出力した後に更なるデータを周期的に受信する２つのグループを自然と形成すると考えられる。図６Ａ及び図６Ｂは、これらのパケット出力サイクルの例を示す。
【００４７】
図６Ａを参照すると、フレーム１は、ＡＰに隣接する「２」で示すデータ保持ノードによりＡＰに出力されるパケットの一例を示す。ＡＰに隣接するノードは、ＡＰと直接通信できても良い。これらのデータ出力側ノードはグループＡの一部である。ＡＰに隣接するが転送するデータを有さない「３」で示す他のノードは、例えば、ＡＰに隣接せずメッシュネットワーク内で更に遠くに存在するノード４からデータを受信する。ノード３及び４はグループＢの一部である。
【００４８】
フレーム２は、データパケットを出力したノードに送出される肯定応答を示す。本実施形態において、グループＡに対して、ＡＰは、ＡＰにデータを送出した１つ又は複数のノード２にＡＣＫ又はスタックＡＣＫを送出する。グループＢに対して、ＡＣＫは、データを受信したノード３により送出側ノード４に送出されても良い。
【００４９】
フレーム３は、グループＢのノードからのデータがＡＰに出力され、よりリモートのグループＡのノード１からのデータがＡＰに隣接するノード２に出力される一例を示す。
【００５０】
フレーム４は、フレーム２と同様のＡＣＫ処理を示す。しかし、本実施形態において、ＡＰはグループＢの隣接ノード３にＡＣＫ又はスタックＡＣＫを送出し、グループＡに対して、ＡＣＫはＡＰに隣接するノード２により送出されても良い。
【００５１】
図６Ｂは、図５に示したのと同様のタイミングシーケンスにおけるグループＡ及びグループＢのパケット出力サイクルの一例を示す。図６Ｂは、インバウンドデータ用タイムサブスロットの間にＡＰにおいて複数のチャネルで受信されるグループＡのノードからのデータ及びアウトバウンドデータ用タイムサブスロットの間の後続のＡＣＫ又はスタックＡＣＫの送信を示す。グループＡのタイムスロットの後、同様の処理がグループＢのノードに対して行われる。
【００５２】
一実施形態において、上述のタイミングシーケンスに対するタイミング同期を伝達するため、ビーコンパケットが使用されても良い。ビーコンパケットは、データパケットを受信可能な時間及びチャネル、並びに対応するＡＣＫが送出される時間及びチャネルを示すためにマルチチャネルノードにより送出されても良い。これらのビーコンパケットは事前に指定された時間に送出されても良く、例えば、マルチチャネルノードに直ぐ隣接するノードであるマルチチャネル受信側ノードの直接範囲内の全てのノードにより利用可能であっても良い。
【００５３】
元のデータパケットの送出元がＡＣＫを受信しない場合、以下の理由のいずれかが考えられる。
１）最初からマルチチャネル受信側ノードがデータパケットを受信しなかった。
２）ＡＣＫが元のデータの送出元により正常に受信されなかった。
いずれの場合も、元のデータパケットの送出元は、別の時間及び別のチャネルにおいてデータを再送出しても良い。そのような動作は、後続のデータ送信の成功可能性を向上するために行われても良い。
【００５４】
要求の送出元がＡＣＫの受信に失敗した場合、要求が再送出されても良い。この追加の要求は、マルチチャネル受信側ノードがＡＣＫを再送出するが、宛先ノードに再送出パケット内の要求を転送しないことにより管理されても良い。あるいは、宛先ノードは、マルチチャネル受信側ノードにより転送された際に重複する要求を削除するように動作しても良い。
【００５５】
図７は、マルチチャネルアクセスポイントを有するメッシュネットワークの処理の一例を示すフローチャートである。ステップＳ１において、ノードは、例えば、ビーコンパケットによりノードに伝達されたシーケンスに従って、所定の時間に所定のチャネルをリスニングする。
【００５６】
ステップＳ２において、データが受信されない場合、ノードは、所定のチャネル及びタイミングシーケンスに従う動作に戻る。
【００５７】
データを受信した場合、ステップＳ３へ進む。ステップＳ３において、ノードは、単一チャネルノード又はマルチチャネルノードに受信データを転送するかを判定する。マルチチャネルノードにデータを転送しないと判定される場合、データは、例えば、標準的な半二重ＭＡＣプロトコルを使用して送出されても良い。
【００５８】
ステップＳ４において、データがマルチチャネルノードに送出される場合、データの送信後、送出側ノードは、その特定のＡＣＫを待つために所定のスタックＡＣＫチャネルに移動しても良い。上述のように、スタックＡＣＫを受信するためのチャネル及びタイミングはビーコンパケットにより伝達されても良い。
【００５９】
ステップＳ５において、元の送出側ノードは、ＡＣＫが特定のデータ送信に対して受信されたかを判定する。ＡＣＫが受信された場合はステップＳ１に戻り、上述のように処理を進めても良い。ＡＣＫが受信されない場合はステップＳ３に戻り、ノードはマルチチャネルノードにデータを再送出しても良く、その後、ＡＣＫをリスニングするためにステップＳ４へ進んでも良い。
【００６０】
一実施形態において、４７ ＣＦＲ １５．２４７に対する認証基準を満たすため、ＡＰは一度に１つのパケットのみを送出しても良いが、ＡＰが同時に受信できるパケット数は限定されなくても良い。従って、一実施形態において、どのノードもＡＰが受信してもできる可能性のあるいずれかのチャネルでパケットを送出しても良い。別の実施形態において、これは特定のシステムにおいて使用可能な全チャネルである。従って、例えば、センサ又は他の処理制御装置である多くのエンドポイントを有するメッシュネットワークにおいて、本明細書中で説明される好適な実施形態は、例えば、パケットを受信するためのインバウンド方向のハードウェア／ソフトウェアの利用可能性である既知のシステムの制限の影響を軽減しても良い。
【００６１】
ＡＰは、無線伝播範囲内のパケットを受信し、その正当性を確認し、応答パケットであるＡＣＫを作成しても良い。一実施形態において、肯定応答されないことが明示的に要求されない限り、受信されたパケットは肯定応答される。別の実施形態は、何らかの優先順位、あるいは順番により情報を伝達するか又は効率を向上する他の方式による肯定応答データの順番付けを含んでも良い。このメタパケットは、既知のスロット、すなわち周波数／時間の組み合わせで送出されても良く、標準的なパケット交換のマルチパケットハンドシェイクを完了するために使用されても良い。
【００６２】
上記の説明は、当業者が本明細書中で説明されるシステム及び方法を実行及び使用できるようにするために提示され、特定の用途及びその要件において行われる。実施形態に対する種々の変更は当業者には容易に明らかとなるであろう。本明細書中で定義される一般的な原理は、請求の範囲の趣旨の範囲から逸脱することなく他の実施形態及び用途に適用されても良い。従って、図示された実施形態に限定されることを意図せず、本明細書中で開示された原理及び特徴と一致するように広範に解釈されるべきである。
【図１】
0005587888.tif 000003
【図２】
0005587888.tif 000004
【図３Ａ】
0005587888.tif 000005
【図３Ｂ】
0005587888.tif 000006
【図３Ｃ】
0005587888.tif 000007
【図３Ｄ】
0005587888.tif 000008
【図４Ａ】
0005587888.tif 000009
【図４Ｂ】
0005587888.tif 000010
【図５】
0005587888.tif 000011
【図６Ａ】
0005587888.tif 000012
【図６Ｂ】
0005587888.tif 000013
【図７】
0005587888.tif 000014