特許 5677573 マルチホップ無線ホームネットワークにおける帯域幅認識ルーティングとチャネル選択およびチャネル切り替えとの組み合わせ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5677573

(24)【登録日】2015年1月9日

(45)【発行日】2015年2月25日

(54)【発明の名称】マルチホップ無線ホームネットワークにおける帯域幅認識ルーティングとチャネル選択およびチャネル切り替えとの組み合わせ

(51)【国際特許分類】

   H04W 40/02 20090101AFI20150205BHJP

   H04W 72/08 20090101ALI20150205BHJP

   H04W 4/06 20090101ALI20150205BHJP

【ＦＩ】

   H04W40/02 130

   H04W72/08 110

   H04W4/06 171

【請求項の数】6

【全頁数】20

(21)【出願番号】特願2013-524068(P2013-524068)

(86)(22)【出願日】2010年8月11日

(65)【公表番号】特表2013-535929(P2013-535929A)

(43)【公表日】2013年9月12日

(86)【国際出願番号】US2010045146

(87)【国際公開番号】WO2012021132

(87)【国際公開日】20120216

【審査請求日】2013年8月12日

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ウー ミンクワン

(72)【発明者】

【氏名】ハン リュウ

(72)【発明者】

【氏名】ソラブ マートゥル

【審査官】 桑江 晃

(56)【参考文献】

【文献】 特表２００８−５２０１６９（ＪＰ，Ａ）

【文献】 特表２００７−５２０１２４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

方法であって、前記方法は、
ゲートウェイにより、帯域幅認識ルーティングプロトコルおよび第１のチャネルを使用してソースノードと宛先ノードとの間の第１のルートを選択するステップであって、当該選択するステップは、前記帯域幅認識ルーティングプロトコルに従って、無線ネットワーク内の隣接ノード間で使用可能な帯域幅を推定するステップを含み、前記第１のルートは、前記推定された使用可能な帯域幅に基づいて選択される、ステップと、
前記ゲートウェイにより、前記選択された第１のルートが、前記第１のルートの前記推定された使用可能な帯域幅に基づいて、前記ソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定するステップと、
前記ゲートウェイにより、前記アプリケーションの前記帯域幅要件が前記選択された第１のルートによって満たされていない場合、バックアップチャネルのリストから選択された第２のチャネルへの切り替えを開始するステップと、
前記ゲートウェイにより、前記帯域幅認識ルーティングプロトコルを使用して、前記第２のチャネルを通じた第２のルートを選択するステップであって、当該選択するステップは、前記帯域幅認識ルーティングプロトコルに従って、無線ネットワーク内の隣接ノード間で使用可能な帯域幅を推定するステップを含み、前記第２のルートは、前記推定された使用可能な帯域幅に基づいて選択される、ステップと、
前記ゲートウェイにより、前記第２のチャネルを通じた前記選択された第２のルートが、前記第２のルートの前記推定された使用可能な帯域幅に基づいて、前記ソースノードの前記アプリケーションの前記帯域幅要件を満たすかどうかを決定するステップと、
前記選択された第１のルートが前記アプリケーションの前記帯域幅要件を満たす場合は前記第１のチャネルを通じて、または、前記選択された第２のルートが前記アプリケーションの前記帯域幅要件を満たす場合は前記第２のチャネルを通じて、前記ソースノードから前記宛先ノードまでデータをストリームするステップと、
を含む、前記方法。

【請求項2】

前記選択された第１のルート、または、前記選択された第２のルートの帯域幅情報を定期的に更新するステップと、
前記更新された帯域幅情報を使用して、前記アプリケーションの前記帯域幅要件が満たされ続けているかどうかを決定するステップと、
前記アプリケーションの前記帯域幅要件がもはや満たされていない場合、第３のルートを選択するステップと、
見つけられる、前記帯域幅要件を満たすルートがない場合、前記ソースノードの前記アプリケーションに通知するステップと、
前記アプリケーションの前記帯域幅要件が満たされ続けている場合、または、前記選択された第３のルートが前記アプリケーションの前記帯域幅要件を満たす場合、データをストリームし続けるステップと、
をさらに含む、請求項１に記載の方法。

【請求項3】

拡張サービスセット識別子、ならびに、負荷情報および使用可能な帯域幅情報のうちの１つを受信するステップと、
合計平均負荷または使用可能な帯域幅に従って、バックアップチャネルリストのための複数のバックアップチャネルを選択するステップと、
前記バックアップチャネルリストをブロードキャストするステップと、
をさらに含む、請求項２に記載の方法。

【請求項4】

装置であって、
帯域幅認識ルーティングプロトコルおよび第１のチャネルを使用して、ソースノードと宛先ノードとの間の第１のルートを選択する手段であって、当該手段は、前記帯域幅認識ルーティングプロトコルに従って、無線ネットワーク内の隣接ノード間で使用可能な帯域幅を推定するように構成され、前記第１のルートは、前記推定された使用可能な帯域幅に基づいて選択される、手段と、
前記選択された第１のルートが、前記第１のルートの前記推定された使用可能な帯域幅に基づいて、前記ソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定する手段と、
前記アプリケーションの前記帯域幅要件が前記選択されたルートによって満たされていない場合、バックアップチャネルのリストから選択された第２のチャネルへの切り替えを開始する手段と、
前記帯域幅認識ルーティングプロトコルを使用して、前記第２のチャネルを通じた第２のルートを選択する手段であって、当該手段は、前記帯域幅認識ルーティングプロトコルに従って、無線ネットワーク内の隣接ノード間で使用可能な帯域幅を推定するように構成され、前記第２のルートは、前記推定された使用可能な帯域幅に基づいて選択される、手段と、
前記第２のチャネルを通じた前記選択された第２のルートが、前記第２のルートの前記推定された使用可能な帯域幅に基づいて、前記ソースノードの前記アプリケーションの前記帯域幅要件を満たすかどうかを決定する手段と、
前記選択された第１のルートが前記アプリケーションの前記帯域幅要件を満たす場合は前記第１のチャネルを通じて、または、前記選択された第２のルートが前記アプリケーションの前記帯域幅要件を満たす場合は前記第２のチャネルを通じて、前記ソースノードから前記宛先ノードまでデータをストリームする手段と、を含み、前記装置はゲートウェイである、前記装置。

【請求項5】

前記選択された第１のルート、または、前記選択された第２のルートの帯域幅情報を定期的に更新する手段と、
前記更新された帯域幅情報を使用して、前記アプリケーションの前記帯域幅要件が満たされ続けているかどうかを決定する手段と、
前記アプリケーションの前記帯域幅要件がもはや満たされていない場合、第３のルートを選択する手段と、
見つけられる、前記帯域幅要件を満たすルートがない場合、前記ソースノードの前記アプリケーションに通知する手段と、
前記アプリケーションの前記帯域幅要件が満たされ続けている場合、または、前記選択された第３のルートが前記アプリケーションの前記帯域幅要件が満たされる場合、データをストリームし続ける手段と、
をさらに含む、請求項４に記載の装置。

【請求項6】

拡張サービスセット識別子、ならびに、負荷情報および使用可能な帯域幅情報のうちの１つを受信する手段と、
合計平均負荷、または、使用可能な帯域幅に従って、バックアップチャネルリストのための複数のバックアップチャネルを選択する手段と、
前記バックアップチャネルリストをブロードキャストする手段と、
をさらに含む、請求項５に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は一般に、ホームネットワーキングに関し、具体的には、帯域幅認識ルーティングとチャネル選択およびチャネル切り替えとを組み合わせるマルチホップ無線ホームネットワーキングに関する。

【背景技術】

【0002】

マルチキャストおよびブロードキャストアプリケーションにおいて、データは、サーバから有線および／または無線ネットワークを介して複数のレシーバに送信される。本明細書で使用されるマルチキャストシステムは、サーバが、複数のレシーバに同じデータを同時に送信するシステムであり、ここでは複数のレシーバは、すべてのレシーバまでを含むサブセットを形成する。ブロードキャストシステムは、サーバが、すべてのレシーバに同じデータを同時に送信するシステムである。つまり、マルチキャストシステムは、当然ながらブロードキャストシステムを含むことができる。

【0003】

無線ネットワークは、それらを展開するコストが低く、柔軟性もあることから、有線ネットワークの最後のホップ拡張(the last hop extension)とする使用が増えている。直交周波数分割多重方式（ＯＦＤＭ）および複数入力複数出力方式（ＭＩＭＯ）などの新たな技術によって、無線チャネルの帯域幅が効率良く大幅に増加した。これらの技術の潜在的用途は、無線リンクを介してビデオコンテンツをホーム環境に分散することである。ビデオストリーミングなどによるビデオコンテンツの分散は、帯域幅要求(bandwidth demanding)である。ほとんどの住宅では、ネットワークアクセス用には１ホップの無線ローカルエリアネットワーク（ＷＬＡＮ）で十分である。再生デバイス（ＴＶまたはコンピュータ）が、アクセスポイント（ＡＰ）および／またはゲートウェイから遠く離れている場合、マルチホップ無線ネットワークは、一定レベル（品質）の視聴体験に必要とされ得る。マルチホップ無線ネットワークは、ソースから宛先までの最適パス（ルート）を選択するルーティングプロトコルを使用する。自動オンディマンド距離ベクトル（ＡＯＤＶ）などのいくつかのプロトコルは、最短パス（ルート）を見つける。２００５年１１月２日に出願された先願特許ＰＣＴ／ＵＳ０５／０３９５９７号は、ＡＯＤＶが帯域幅を考慮に入れていることを示している。いくつかの事例では、無線デバイスに１つまたは複数の干渉がある場合、最適ルートでさえビデオ分散に十分な帯域幅を提供することができず、干渉がより小さいチャネルに切り替えることによって問題を解決する場合もある。

【0004】

多くの研究が、パケットスケジューリングとルーティングおよびチャネル選択とを組み合わせて、マルチ無線・マルチチャネルの無線アドホックまたはメッシュネットワークをサポートすることをテーマにしており、例えば、Kyasanur and Vaidya, “Routing and Link-layer Protocols for Multi-Channel Multi-Interface Ad Hoc Wireless Networks, ”SIGMOBILE Mobile Computing and Communication Review, vol.10, no.1, pp.31-43, January 2006、およびAlicherry et al “Joint Channel Assignment and Routing for Throughput Optimization in Multi-radio Wireless Mesh Networks,” in ACM Mobicom, Cologne, Germany, August 2005、およびBahl et al, “SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless Networks,” In Proceedings of ACM Mobicom, Philadelphia, PA, September 2004などがある。しかし、これらの研究は、現在のＩＥＥＥ８０２．１１ＭＡＣ層の修正を提案しており、無線ネットワークのすべてのデバイスが同期され、かつチャネル切り替えが１パケットベースで実行されると仮定している。“Centralized Algorithms for Multi-channel Wireless Mesh networks”, in ACM Mobile Computing and Communication Review, April 2004, Raniwala et. alは、マルチ無線メッシュネットワーク用の比較的長期間のチャネル割り当てスキームを提案しており、その目的は、メッシュワークの全容量を増加することである。Ｒａｎｉｗａｌａ ｅｔ．ａｌは、ルーティングとチャネル割り当てプロトコルとを組み合わせていない。他の提案では、例えば、Nelson and Kleinrock, “Spatial TDMA: A Collision Free Multihop Channel Access Protocol,” IEEE transactions on communications, vlo.com-33, No.9, pp.934-944, September 1985、およびCidon, Moshe Sidi, “Distributed Assignment Algorithms for Multihop Packet Radio Networks,” IEEE transactions on computer, vol.38, no.10, pp.1353-1361, October, 1989は、無線チャネルの空間再利用を高めるのにＴＤＭＡ ＭＡＣ層の使用を提唱している。これらの提案は、再度、ＩＥＥＥ８０２．１１ＭＡＣ層の修正を要求している。２００５年１１月２日に出願された先願特許ＰＣＴ／ＵＳ０５／０３９５９７号において、最短ホップの代わりに最適帯域幅を有するパスを選択する、帯域幅認識ルーティングプロトコルを提案している。この提案は、帯域幅要求である、ビデオストリーミングにとって有利である。しかし、近隣のデバイスに１または複数の干渉がある場合、このプロトコルでもビデオストリーミングの要件を満たすことができるパスを見つけ損なう場合もある。チャネル干渉の事例では、干渉がより小さいチャネルに切り替えることによって問題を解決する場合もある。

【0005】

帯域幅認識ルーティングプロトコルは、無線ネットワーク内のノードと隣接ノードとの間で使用可能な帯域幅についての情報を必要とする。使用可能な帯域幅は、ＩＥＥＥ８０２．１１ｋからの情報を使用して推定されてよいが、現在のＩＥＥＥ８０２．１１ｋは、無線カードにほとんど実装されていない。Shah et al “Available Bandwidth Estimation in IEEE 802.11-based Wireless Networks,” In Proceedings of 1^st ISMA/CAIDA workshop on Bandwidth Estimation (BEst 2003)において、ＭＡＣ層で使用可能な帯域幅推定方法が提案されている。アドホックまたはメッシュ無線ネットワークにおいて、各ノードは、複数の隣接ノードを有し得る。Ｓｈａｈ ｅｔ ａｌの方法では、隣接ノードの状態を維持するのにＭＡＣ層を必要とする。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】ＰＣＴ／ＵＳ０５／０３９５９７号明細書

【非特許文献】

【0007】

【非特許文献1】Kyasanur and Vaidya, “Routing and Link-layer Protocols for Multi-Channel Multi-Interface Ad Hoc Wireless Networks, ”SIGMOBILE Mobile Computing and Communication Review, vol.10, no.1, pp.31-43, January 2006

【非特許文献2】Alicherry et al “Joint Channel Assignment and Routing for Throughput Optimization in Multi-radio Wireless Mesh Networks,” in ACM Mobicom, Cologne, Germany, August 2005

【非特許文献3】Bahl et al, “SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless Networks,” In Proceedings of ACM Mobicom, Philadelphia, PA, September 2004

【非特許文献4】”Centralized Algorithms for Multi-channel Wireless Mesh networks”, in ACM Mobile Computing and Communication Review, April 2004, Raniwala et. al

【非特許文献5】Nelson and Kleinrock, “Spatial TDMA: A Collision Free Multihop Channel Access Protocol,” IEEE transactions on communications, vlo.com-33, No.9, pp.934-944, September 1985

【非特許文献6】Cidon, Moshe Sidi, “Distributed Assignment Algorithms for Multihop Packet Radio Networks,” IEEE transactions on computer, vol.38, no.10, pp.1353-1361, October, 1989

【非特許文献7】Shah et al “Available Bandwidth Estimation in IEEE 802.11-based Wireless Networks,” In Proceedings of 1st ISMA/CAIDA workshop on Bandwidth Estimation (BEst 2003)

【発明の概要】

【発明が解決しようとする課題】

【0008】

マルチホップ無線ホームネットワーク内でビデオ分散するために帯域幅認識ルーティングとチャネル選択とを組み合わせる方法が有用であろう。隣接ノードの状態を維持する必要がない無線ネットワーク内の隣接ノード間で使用可能な帯域幅を推定するための新しいアプリケーション層方法も有用であろう。

【課題を解決するための手段】

【0009】

本明細書では、マルチホップ無線ホームネットワーク内でビデオ分散するために帯域幅認識ルーティングとチャネル選択とを組み合わせる方法および装置について説明する。ＡＯＤＶは、本発明の方法を説明するルーティングプロトコルとして本明細書で使用される。本発明の方法はまた、他のマルチホップ無線ルーティングプロトコルと組み合わせることもできる。使用可能な帯域幅を推定するための２つの新しいアプリケーション層方法も本明細書で説明される。

【0010】

本明細書で使用される際、ノードは、コンピュータ、ラップトップ、モバイル端末、モバイルデバイス、クライアント、クライアントデバイス、エンドデバイス、パーソナルデジタルアシスタント（ＰＤＡ）、デュアルモードスマートフォンまたは任意の同等のデバイスを含む、無線マルチホップネットワークに接続される任意のデバイスを含む。

【0011】

方法および装置は、帯域幅認識ルーティングプロトコルを使用してソースノードと宛先ノードとの間の第１のルートを選択すること、選択された第１のルートがソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定すること、ソースノードのアプリケーションの帯域幅要件が、選択された第１のルートによって満たされていない場合、バックアップチャネルリストから選択された新しいチャネルへの切り替えを開始すること、帯域幅認識ルーティングプロトコルを使用して新しいチャネルを通じた第２のルートを選択すること、新しいチャネルを通じた選択された第２のルートがソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定すること、および、選択された第１のルートがソースノードのアプリケーションの帯域幅要件を満たす場合、または、新しいチャネルを通じた選択された第２のルートがソースノードのアプリケーションの帯域幅要件を満たす場合、ソースノードから宛先ノードまでデータをストリームすること、を含んで説明される。また、ノードによってチャネルをスキャンして、チャネルを使用したノードの各隣接ノードのためのチャネル情報ならびに拡張サービスセット識別子(extended service set identifiers)および負荷情報を取得すること、ビーコンメッセージにおいてノードの拡張サービスセット識別子およびそのノードの隣接ノードの拡張サービスセット識別子をブロードキャストすること、および、バックアップチャネルリストを更新する情報を受信すること、を含む方法および装置についても説明する。

【図面の簡単な説明】

【0012】

本発明は以下の詳細な説明が添付図面と併せて読まれる場合に最も理解されよう。図面は簡潔に記載された以下の図を含む。

【図1】本発明が実施する例示的システムの概略図である。

【図2】本発明の原理に従う、帯域幅推定方法の例示的実施形態のフローチャートである。

【図3】本発明の原理に従う、帯域幅推定方法の代替的実施形態のフローチャートである。

【図4A】本発明の原理に従う、ゲートウェイの観点からのバックアップチャネル選択方法の例示的実施形態のフローチャートである。

【図4B】本発明の原理に従う、ノードの観点からのバックアップチャネル選択方法の例示的実施形態のフローチャートである。

【図5】本発明の原理に従う、新しいビデオストリーミングアプリケーションのためのチャネル選択とチャネル切り替えとを組み合わせた帯域幅認識ルーティング方法の例示的実施形態のフローチャートである。

【図6】本発明の原理に従う、既存のビデオストリーミングアプリケーションのためのチャネル選択とチャネル切り替えとを組み合わせた帯域幅認識ルーティング方法の例示的実施形態のフローチャートである。

【図7】無線デバイスのための本発明の例示的実現のブロック図である。

【発明を実施するための形態】

【0013】

本発明のアプリケーションシナリオが最初に与えられる。マルチホップ無線ホームネットワークの例は図１に示してある。無線ホームゲートウェイは、ケーブルモデムまたは電話機のデジタル加入者線（ＤＳＬ）を通じてインターネットに接続される。モバイルデバイスは、位置１に最初に配置され、これは、無線ゲートウェイの近くにあり、かつ、ゲートウェイに直接ワイヤレスで接続されている。モバイルデバイスはその後、位置２に移動され、これはゲートウェイからさらに離れている。モバイルデバイスがなおもゲートウェイに直接接続されている場合、モバイルデバイスが得るビットレートは、かなり低下する。この時点で、帯域幅認識ルーティングプロトコルは、モバイルデバイスをメッシュルータまたは中継ノードを通じてゲートウェイに接続する有利なルートを見つける。その後、同じ無線チャネルを通じて（使用して）通信する隣接ＡＰはオンラインになり、例示したマルチホップ無線ネットワークと干渉する。モバイルデバイスが得ることができるビットレートは、再度低下する。このとき、ルーティングプロトコルは、ビデオ分散用に要求されたビットレートを実現する有利なルートを見つけることができないだろう。しかし、本発明を使用して、モバイルデバイスは、使用可能な干渉がないチャネルを見つけて、そのチャネルに切り替える。モバイルデバイスのサービス品質はそれによって向上する。

【0014】

本発明の方法の説明において、マルチホップ無線ネットワーク内のすべてのデバイスは、１つの無線インタフェースのみを有し、それらはすべて同じ無線チャネル上で機能すると見なされる。しかし、本発明の方法は、デバイスが複数の無線インタフェースを有し、異なる無線チャネル上で機能するシナリオに拡張することができる。

【0015】

帯域幅認識ルーティングプロトコルについて、隣接ノードの各ペア間で使用可能な帯域幅を推定する必要がある。従って、隣接ノード間で使用可能な帯域幅を推定する２つの新しい方法について説明する。

【0016】

第１の使用可能な帯域幅推定方法において、無線メッシュネットワーク内の各ノードは、その負荷情報を（チャネル利用、即ち、ノード（デバイス、モバイルデバイス）がチャネルを使用する時間の断片として）ビーコンメッセージでブロードキャストする。無線メッシュネットワーク内の各ノードは、ビーコンメッセージから確認して、拡張サービスセット識別子（ＥＳＳＩＤ）を記録し、そして、その隣接ノードのそれぞれの情報をロードする。各ノードは、記録されたＥＳＳＩＤを定期的にブロードキャストして、その隣接ノードの情報をロードする（オーバーヘッドを減らすために、これは、ルーティングプロトコルのビーコンまたはハローメッセージに含むこともできる）。ノードａとノードｂは、マルチホップ無線ネットワーク内の２つの隣接ノードであると仮定する。Ｎ_ａとＮ_ｂは、それぞれノードａとノードｂの隣接ノードのセットである。μ_ｉは、ノードｉの負荷を表すものとし、チャネルがノードａとノードｂとの間で使用されていない時間の断片は、次のようになる。

【0017】

【数1】

【0018】

ノードａとノードｂとの間の伝送レートは、ｒ_ｔであると仮定し（これは、受信信号強化インジケータ（ＲＳＳＩ）から推定することができる）、次にノードａとノードｂとの間で使用可能な帯域幅をｒ_ｔμと推定することができる。

【0019】

第２の（代替として）使用可能な帯域幅推定方法において、使用可能な帯域幅は、Ｓ／（ｔ_ｑ＋ｔ_ｘ）と定義され、ここで、Ｓはプローブパケットサイズ、ｔ_ｑはキュー時間、ｔ_ｘは伝送時間である。ｔ_ｑ＋ｔ_ｘを推定するには、あるノード（モバイルデバイス）がプローブパケットをその隣接ノードに送信し、そして隣接ノードのペア間の平均往復時間（ｒｔｔ）である、ｒｔｔ＝２（ｔ_ｐ＋ｔ_ｑ＋ｔ_ｘ）を測定する。ここで、ｔ_ｐは（ユーザ空間からカーネル空間までのデータパケットをコピーするなどの）パケット処理時間であり、一定であると見なされる。ｔ_ｐを推定するには、同じサイズのデータパケットを、有線イーサネット（登録商標）によって直接接続された２つのコンピュータ間で送信し、そしてｒｔｔを測定することができる。他のトラフィックがないので、ｔ_ｑを０、ｔ_ｘ＝Ｓ／ｒ_ｔと仮定することができ、ここではｒ_ｔは伝送レートであり、周知である。上記の式を使用して、ｔ_ｐを計算することができる。コンピュータのペアが有線または無線リンクによって接続されている場合、ｔ_ｐは変更しないと仮定する。ひとたびｒｔｔが計算されると、使用可能な帯域幅であるｔ_ｑ＋ｔ_ｘ＝（ｒｔｔ／２）−ｔ_ｐを推定することができる。

【0020】

使用可能な帯域幅は、パケットサイズＳにも関連し、これは、ひとたびノードがチャンネル使用を取得し、そのノードがより大きいビットを送信すれば、より高いスループットを実現するという理由であることに留意されたい。従って、トラフィック（データ）パターンが周知である場合、トラフィック（データ）の平均サイズを推定することができ、そのサイズのプローブパケットを使用して、使用可能な帯域幅を推定することができる。

【0021】

ＡＯＤＶルーティングプロトコルにおいて、各ノードは、ハローメッセージを定期的にブロードキャストするので、各ノードは、その隣接ノードが分かる。チャネル測定プローブのオーバーヘッドを減らすために、隣接ノードの各ペアに対し、１つのノードしかプローブパケットを送信しないので、本発明では、最小のＩＰアドレスを有するノードが、より大きいＩＰアドレスを有する隣接ノードにプローブパケットを定期的に送信する。プローブパケットを送出するノードを選択するその他の適したスキームが使用され得ることに留意されたい。Ｙ_ｔを時間ｔにおいて一回推定される使用可能な帯域幅とする。使用可能な帯域幅の平均Ｂ_ｔは、Ｂ_ｔ＝αＹ_ｔ＋（１−α）Ｂ_ｔ−１である。帯域幅推定を開始するノードはその後、推定結果をより大きいＩＰアドレスを有する隣接ノードに送信する。

【0022】

典型的な無線ホームネットワークにおいて、ほとんどのトラフィック（データ）は、無線ゲートウェイを通過する（トラバースする）。ＩＥＥＥ８０２．１１ｓ標準において、ゲートウェイは、ネットワーク内の他のデバイスがゲートウェイへのルートを確認できるように、その所在を定期的にブロードキャストする。従って、ゲートウェイのルートは、ネットワーク内のすべてのデバイスに知られていると見なすことは妥当である。

【0023】

現在機能しているチャネルに加え、各ネットワークデバイスは、バックアップチャネルのリストを保持する。本発明において、すべてのデバイスは、同じチャネルを介して通信している（同じチャネル上で機能している）ので、すべてのデバイスのバックアップチャネルリストは、同じであると見なす。ゲートウェイが最初に起動すると、現在機能しているチャネルは、工場出荷時のチャネルまたは最小限にロードされたチャネルになり得る。

【0024】

バックアップチャネルのリストを選択するのに２つの手段がある。バックアップチャネルリストを生成する１つの手段は、それぞれのチャネルのネットワークの干渉域内の総平均負荷(average total load)に従って、リストを作ることである。各無線デバイス（ゲートウェイを含む）は、チャネル情報を得るのにすべてのチャネルを定期的にスキャンし、その情報は、ＥＳＳＩＤおよびそのチャネル上の各ＥＳＳＩＤの負荷を含む。各デバイスは、その後、チャネル情報をゲートウェイにユニキャストする。ゲートウェイは、すべてのデバイスからチャネル情報レポートを収集して、バックアップチャネルリストを計算する。各チャネルに対し、ゲートウェイは、そのチャネル上で機能している異なるデバイスの負荷を集計する。同じデバイスが複数のチャネル情報レポートに出てくることもあるので、ＭＡＣアドレスを有するＡＰ（基本サービスシステム（ＢＳＳ）において、ＡＰのみが、そのＥＳＳＩＤおよび負荷情報をビーコンでブロードキャストする）を一度だけの接続にしなければならないことに留意されたい。現在機能しているチャネルに対し、ゲートウェイは、他の無線ネットワーク内のデバイスのみをカウントする。ゲートウェイは、その後、最小の総平均負荷を有する第１のＭチャネルを含むバックアップチャネルリストを作成する。通常、Ｍは、あまり大きくする必要はなく、例えば、３つのバックアップチャネルで十分である。バックアップチャネルリストを生成する代替手段は、各ノードに対して各チャネル上で使用可能な帯域幅を推定することであり、各ノードは、その後、各チャネル上で使用可能な帯域幅をゲートウェイに定期的に送信する。各チャネル上で使用可能な帯域幅は、ネットワーク内のすべてのデバイスの中で使用可能な最小の帯域幅になる。ゲートウェイは、その後、使用可能な帯域幅の最大平均を有する第１のＭチャネルを含むバックアップチャネルリストを作成する。前と同じように、Ｍは、あまり大きくする必要はなく、例えば、３つのバックアップチャネルで十分である。

【0025】

バックアップチャネルリストを生成する上記の２つの方法のいずれかを使用して、ゲートウェイは、その後、有効期間（ＴＴＬ）をゲートウェイから離れているデバイスの最大ホップ数に設定して、バックアップチャネルリストを無線ネットワークにブロードキャストする。ホームネットワークにおいて、ＴＴＬの設定は、３つで十分である。各デバイスは、バックアップチャネルリストを受信すると、肯定応答パケット（ＡＣＫ）をゲートウェイに送り返す。所定の時間が過ぎてもゲートウェイが、デバイスからＡＣＫを受信しない場合、ゲートウェイは、そのデバイスにバックアップチャネルリストのコピーをユニキャストする。このようにして各デバイスは、同じバックアップチャネルリストを有する。

【0026】

ひとたび隣接ノードの各ペア間で使用可能な帯域幅が推定されると、２００５年１１月２日に出願された先願特許ＰＣＴ／ＵＳ０５／０３９５９７号明細書に記載の帯域幅認識ルーティングプロトコルを使用して、使用可能な最大帯域幅を有するパス（ルート）を選択することができ、そのルート（パス）の帯域幅も推定することができる。

【0027】

新しいビデオストリーミングアプリケーションでは、帯域幅認識ルーティングプロトコルを使用して、ソースから宛先にストリームするルートが見つかる。推定されたルートの帯域幅がビデオストリーミングアプリケーションの要件を満たさない場合、ソースノードは、チャネル切り替え要求を開始し得る。

【0028】

既存のビデオストリーミングアプリケーションでは、ソースノードは、既存のルートの使用可能な帯域幅の更新も受信する。既存のルートの使用可能な帯域幅が所定の閾値未満であり、かつビデオストリーミングの要件を満たす使用可能な帯域幅を有する新しいルートがある場合、ソースノードは、新しいルートに切り替える。ビデオストリーミングの要件を満たす新しいルートがない場合、ソースノードは、チャネル変更要求を開始する。

【0029】

ノードがチャネル変更を望む場合、ノードは、チャネル変更要求をゲートウェイに送信する（ほとんどの時間、ゲートウェイは、チャネル変更イニシエータである）。ゲートウェイは、その後、チャネル変更要求を無線ネットワークにブロードキャストする。各ノードは、チャネル変更要求の受信を示すＡＣＫをゲートウェイに送り返す。ゲートウェイがすべてのノードからＡＣＫを受信した後、ゲートウェイは、チャネル切り替えメッセージをブロードキャストして、無線ネットワーク内のすべてのノードは、バックアップチャネルリストの第１のチャネルに切り替える。

【0030】

ノードがチャネル切り替えメッセージを受信しなかった場合も考えられる。この事例では、ネットワーク内の他のノードが新しいチャネルに切り替えた場合、それらのノードは、隣接ノードとの接続がなくなる。一定の時間遅延の後、ノードは、その隣接ノードが新しいチャネルに切り替えたと見なして、そのノード自体は、バックアップチャネルリストの第１のチャネルに切り替える。

【0031】

図２は、本発明の原理に従う、帯域幅推定方法の例示的な実施形態のフローチャートである。２０２において、無線ネットワーク内の各ノードは、そのＥＳＳＩＤおよびその負荷情報（チャネル利用）をビーコンメッセージで定期的にブロードキャストする。各ノードは、ビーコンメッセージから確認して、その隣接ノードのそれぞれに対する拡張サービスセット識別子（ＥＳＳＩＤ）および負荷情報を記録する。２０５において、各ノードは、その隣接ノードの記録されたＥＳＳＩＤおよび負荷情報を定期的にブロードキャストする（オーバーヘッドを減らすために、この情報を、ルーティングプロトコルのビーコンまたはハローメッセージに含むこともできる）。２１５において、各ノードは、その隣接ノードのそれぞれの間でチャネルが使用されていない時間の断片を定期的に推定する。２２０において、各ノードは、その隣接ノードのそれぞれの間の伝送レートを定期的に推定する。２２５において、各ノードは、その隣接ノードのそれぞれの間で使用可能な帯域幅を定期的に推定する。

【0032】

図３は、本発明の原理に従う、帯域幅推定方法の代替的実施形態のフローチャートである。３０５において、各ノードは、パケット処理時間（ユーザ空間からカーネル空間までのデータパケットをコピーする時間）を定期的に推定する。３１０において、各ノードは、そのノードとその隣接ノードのそれぞれとの間で移動するデータパケットの往復時間を定期的に推定する。３１５において、各ノードは、キュー時間および伝送時間を定期的に推定する。３２０において、各ノードは、そのノードとその隣接ノードのそれぞれとの間で使用可能な帯域幅を定期的に推定する。

【0033】

使用可能な帯域幅は、パケットサイズＳにも関連し、これは、ひとたびノードがチャンネル使用を取得し、そのノードがより大きいビットを送信すれば、より高いスループットを実現するという理由であることに留意されたい。従って、トラフィック（データ）パターンが周知である場合、トラフィック（データ）の平均サイズを推定することができ、そのサイズのプローブパケットを使用して、使用可能な帯域幅を推定することができる。プローブパケットのサイズは、設計パラメータである。一定の時間期間にわたる実データパケットの平均サイズをプローブパケットのサイズとして使用することができる。

【0034】

ＡＯＤＶルーティングプロトコルにおいて、各ノードは、ハローメッセージを定期的にブロードキャストするので、各ノードは、その隣接ノードが分かる。任意には、チャネル測定プローブのオーバーヘッドを減らすために、隣接ノードの各ペアに対し、１つのノードしかプローブパケットを送信しないので、本発明では、最小のＩＰアドレスを有するノードが、より大きいＩＰアドレスを有する隣接ノードにプローブパケットを定期的に送信する。プローブパケットを送出するノードを選択するその他の適したスキームが使用され得ることに留意されたい。Ｙ_ｔを時間ｔにおいて一回推定される使用可能な帯域幅とする。使用可能な帯域幅の平均Ｂ_ｔは、Ｂ_ｔ＝αＹ_ｔ＋（１−α）Ｂ_ｔ−１である。帯域幅推定を開始するノードはその後、推定結果をより大きいＩＰアドレスを有する隣接ノードに送信する。

【0035】

図４Ａは、本発明の原理に従う、ゲートウェイの観点からのバックアップチャネル選択方法の例示的な実施形態のフローチャートである。４０５において、ゲートウェイは、各チャネルに対するＥＳＳＩＤおよび負荷情報を各ノードから定期的に受信する。４１０において、ゲートウェイは、ネットワークの干渉域または使用可能な帯域幅における合計（総）平均負荷に基づいてチャネルをバックアップチャネルリスト用に選択し、その平均負荷は、ゲートウェイがノードから受信した情報に基づいて、さらにゲートウェイ自身のチャネルの定期的スキャニングに基づいてゲートウェイが計算する。ゲートウェイは、ノードと同じ手段でチャネルをスキャンする。ゲートウェイは、選択されたチャネルからバックアップリストを生成する。ゲートウェイは、その後、最小の総平均負荷を有する第１のＭチャネルを含むバックアップチャネルリストを作成する。通常、Ｍは、あまり大きくする必要はなく、例えば、３つのバックアップチャネルで十分である。各チャネル上で使用可能な帯域幅は、ネットワーク内のすべてのデバイスの中で使用可能な最小の帯域幅になる。４１５において、ゲートウェイは、それが生成したバックアップチャネルリストをノードに定期的にブロードキャストする。ゲートウェイは、有効期間（ＴＴＬ）をゲートウェイから離れているデバイスの最大ホップ数に設定して、バックアップチャネルリストを無線ネットワークにブロードキャストすることに留意されたい。ホームネットワークにおいて、ＴＴＬの設定は、３つで十分である。各デバイスは、バックアップチャネルリストを受信すると、肯定応答パケット（ＡＣＫ）をゲートウェイに送り返す。所定の時間が過ぎてもゲートウェイが、デバイスからＡＣＫを受信しない場合、ゲートウェイは、そのデバイスにバックアップチャネルリストのコピーをユニキャストする。このようにして各デバイスは、同じバックアップチャネルリストを有する。この機能は、図４Ａに示していない。

【0036】

図４Ｂは、本発明の原理に従う、ノードの観点からのバックアップチャネル選択方法の例示的な実施形態のフローチャートである。４２０において、各無線デバイスは、チャネル情報を得るのにすべてのチャネルを定期的にスキャンし、その情報は、ＥＳＳＩＤおよびそのチャネル上の各ＥＳＳＩＤの負荷を含む。４２５において、各デバイスは、ＥＳＳＩＤおよび負荷情報または使用可能な帯域幅をゲートウェイにユニキャストする。４３０において、各ノードは、ゲートウェイからバックアップチャネルリストを受信する時、そのノードのバックアップチャネルリストを更新する。各ノードは、新しいバックアップチャネルリストの肯定応答受信であるＡＣＫをゲートウェイに送信する。ゲートウェイが受信しなかったノードおよびＡＣＫは、ゲートウェイから再度ユニキャストでバックアップチャネルリストを受信できる。この特徴は、図４Ｂに示していない。

【0037】

図５は、本発明の原理に従う、新しいビデオストリーミングアプリケーションのためのチャネル選択とチャネル切り替えとを組み合わせた帯域幅認識ルーティング方法の例示的な実施形態のフローチャートである。５０５において、ゲートウェイは、ソースから宛先までの最適ルート（パス）を選択するのに帯域幅認識ルーティングプロトコルを使用する。ゲートウェイは、選択されたルート（パス）の帯域幅も推定する（図示せず）。５１０において、選択されたルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の要件を満たすかどうかを決定するテストが実行される。選択されたルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の要件を満たす場合、５２５において、ゲートウェイは、（ノード内の）アプリケーションに通知して、（ビデオの）ストリーミングを開始する。選択されたルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の帯域幅要件を満たさない場合、５１５において、ゲートウェイは、チャネルを切り替えようと決定し、そして切り替えるチャネルをバックアップチャネルリストから選択する。５２０において、アプリケーションの帯域幅要件を満たす新しいルート（パス）が見つかるかどうかを決定するテストが実行される。新しいルート（パス）は、最初にルートを選択するのに使用される、帯域幅認識ルーティングプロトコルを使用して選択される。アプリケーションの帯域幅要件を満たす新しいルート（パス）を見つけることができる場合、５２５において、ゲートウェイは、（ノード内の）アプリケーションにチャネル変更（切り替え）を通知して、（ビデオの）ストリーミングを開始する。ゲートウェイは、チャネル変更（切り替え）要求の通常のイニシエータであるので、ゲートウェイは、チャネル変更（切り替え）要求をネットワークにブロードキャストする（図示せず）。各ノードは、チャネル変更要求の受信を示すＡＣＫをゲートウェイに送り返す(図示せず)。ゲートウェイがすべてのノードからＡＣＫを受信した後、ゲートウェイは、チャネル切り替えメッセージをブロードキャストして、無線ネットワーク内のすべてのノードは、バックアップチャネルリストの第１のチャネルに切り替える(図示せず)。アプリケーションの帯域幅要件を満たす新しいルート（パス）を見つけることができない場合、５３０において、ゲートウェイは、アプリケーションの帯域幅要件を満たす新しいルート（パス）を見つけられないことを（ノード内の）アプリケーションに通知する。

【0038】

図６は、本発明の原理に従う、既存のビデオストリーミングアプリケーションのためのチャネル選択とチャネル切り替えとを組み合わせた帯域幅認識ルーティング方法の例示的な実施形態のフローチャートである。６０５において、ゲートウェイは、既存のルート（パス）が使用可能な帯域幅情報を定期的に更新する。ゲートウェイが、ノードから、およびゲートウェイ自身のスキャニング動作から定期的に受信する情報を用いてこの更新を行う。６１０において、既存のルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の要件を満たすかどうかを判定するテストがゲートウェイによって実行される。既存のルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の要件を満たす場合、６３０において、（ビデオ）ストリーミングを継続する。既存のルート（パス）の帯域幅が、アプリケーション（例えば、ビデオストリーミング）の要件をもはや満たさない場合、６１５において、（ノード内の）アプリケーションの帯域幅要件を満たす新しいルート（パス）が存在するかどうかを判定するテストがゲートウェイによって実行される。ゲートウェイは、既存のルート（パス）の帯域幅と所定の閾値とを比較する。（ノード内の）アプリケーションの帯域幅要件を満たす新しいルート（パス）が存在する場合、６３５において、ゲートウェイは、その新しいルートに変更する（切り替える）。アプリケーションの帯域幅要件を満たす新しいルート（パス）を見つけることができない場合、６２０において、ゲートウェイは、チャネルを切り替えようとする（変更しようとする）。６２５において、（ノード内の）アプリケーションの帯域幅要件を満たす新しいチャネルを見つけることができるかどうかを判定するテストが実行される。（ノード内の）アプリケーションの帯域幅要件を満たす新しいチャネルを見つけることができる場合、ゲートウェイは、チャネル変更（切り替え）要求をネットワークにブロードキャストする（図示せず）。各ノードは、チャネル変更要求の受信を示すＡＣＫをゲートウェイに送り返す(図示せず)。ゲートウェイがすべてのノードからＡＣＫを受信した後、ゲートウェイは、チャネル切り替えメッセージをブロードキャストして、無線ネットワーク内のすべてのノードは、バックアップチャネルリストの第１のチャネルに切り替える(図示せず)。（ノード内の）アプリケーションの帯域幅要件を満たす新しいチャネルを見つけることができない場合、６４０において、ゲートウェイは、アプリケーションの帯域幅要件を満たす新しいチャネルまたはルート（パス）を見つけられないことを（ノード内の）アプリケーションに通知する。

【0039】

図７は、無線デバイスのための本発明の例示的実現のブロック図である。無線デバイスはトランスミッタ、レシーバまたはトランシーバにすることができるので、単一のブロック図を使用して、これらのデバイスについて説明する。各デバイスは、ホストコンピューティングシステム、無線通信モジュールおよび有線通信モジュールを含む。ホスト処理システムを汎用コンピュータまたは専用コンピューティングシステムにすることができる。ホストコンピューティングシステムは、中央処理装置（ＣＰＵ）、メモリおよび入力／出力（Ｉ／Ｏ）インタフェースを含むことができる。無線通信モジュールは、ＭＡＣおよびベースバンドプロセッサ、無線トランスミッタ／レシーバ、ならびに、１または複数のアンテナを含むことができる。アンテナは、無線信号を送受信する。無線トランスミッタ／レシーバは、無線信号処理を実行する。無線トランスミッタ／レシーバは、トランシーバまたは別個のトランスミッタおよびレシーバであってよい。ＭＡＣおよびベースバンドプロセッサは、ＭＡＣ制御、ならびに、データフレーミング、変調／復調、送信／受信のコーディング／デコーディングを実行する。有線通信モジュールは、ＴＣＰ／ＩＰまたはＵＤＰプロトコルを使用して他のデバイスと通信するイーサネットインタフェースにすることができる。通常、無線デバイスは無線チャネルを通じて互いに通信し、ゲートウェイは、有線インタフェースを使用してバックホールに接続する。無線デバイスは、有線インタフェースを使用してコンピュータまたはＴＶなどの他のデバイスと通信することができる。

【0040】

具体的には、図７に示した装置は、無線ホームゲートウェイとして動作し得る。インターネット（または他のネットワーク）との通信において、無線ホームゲートウェイは、有線通信モジュールを使用できる（有線通信モジュールを経由して動作できる）。つまり、無線ホームゲートウェイは、インターネットまたはＴＶなどを接続するのに有線接続を使用できる。本発明の目的として、無線ホームデバイスと通信する無線ホームゲートウェイは、ホストコンピューティングシステム内および無線通信モジュール内で動作する。無線ホームゲートウェイのホストコンピューティングシステムは、ＣＰＵもしくは他の処理回路またはメモリを含み、それらは、帯域幅認識ルーティングプロトコルを使用してソースノードと宛先ノードとの間の第１のルートを選択する手段、選択された第１のルートがソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定する手段、選択されたルートがアプリケーションの帯域幅要件を満たさない場合、バックアップチャネルリストから選択された新しいチャネルへの切り替えを開始する手段、帯域幅認識ルーティングプロトコルを使用して新しいチャネルを通じた第２のルートを選択する手段、新しいチャネルを通じた選択された第２のルートがソースノードのアプリケーションの帯域幅要件を満たすかどうかを判定する手段として使用される。ホストコンピューティングシステムのＣＰＵおよびメモリは、選択された第１のルート、または、選択された第２のルートの帯域幅情報を定期的に更新する手段、更新された帯域幅情報を使用してアプリケーションの帯域幅要件を継続して満たしているかどうかを決定する手段、アプリケーションの帯域幅要件がもはや満たされない場合に第３のルートを選択する手段も含む。ホストコンピューティングシステムのＣＰＵおよびメモリは、合計平均負荷または使用可能な帯域幅に従って複数のバックアップチャネルをバックアップチャネルリスト用に選択する手段も含む。ホストコンピューティングシステムは、無線ホームデバイスとそのデバイスのＩ／Ｏインタフェースを経由して通信し、そしてインタフェースは、無線通信モジュールに接続される。従って、ホストコンピューティングシステムのＩ／Ｏインタフェースおよび有線通信モジュールは連結して、選択された第１のルートがアプリケーションの帯域幅要求を満たす場合、または、新しいチャネルを通じた選択された第２のルートがアプリケーションの帯域幅要求を満たす場合、ソースノードから宛先ノードまでデータをストリームする手段を含む。ホストコンピューティングシステムのＩ／Ｏインタフェースおよび有線通信モジュールは連結して、帯域幅要件を満たすルートを見つけられない場合、ソースノードのアプリケーションに通知する手段、アプリケーションの帯域幅要件を継続して満たしている場合、または、選択された第３のルートがアプリケーションの帯域幅要件を満たす場合、データをストリームするのを継続する手段、拡張サービスセット識別子、および負荷情報および使用可能な帯域幅情報のうちの１つを受信する手段、バックアップチャネルリストをブロードキャストする手段をさらに含む。

【0041】

具体的には、図７に示した装置が無線ホームゲートウェイに接続された無線ホームデバイス(ノード)として振る舞う場合、無線ホームデバイスは、ホストコンピューティングシステム内および無線通信モジュール内で動作する。無線ホームゲートウェイのホストコンピューティングシステムは、ＣＰＵまたは他の処理回路またはメモリを含み、それらは、チャネルが、そのチャネルを使用したノードの隣接ノードによって使用されていない時間の断片を推定する手段、ノードの隣接ノード間の伝送レートを推定する手段、ノードの隣接ノード間で使用可能な帯域幅を推定する手段として使用されてよい。無線ホームゲートウェイのホストコンピューティングシステムは、ＣＰＵまたは他の処理回路またはメモリを含み、それらは、データパケットの処理時間を推定する手段、ノードから各隣接ノードまでのデータパケットの往復時間を推定する手段、データパケットのキュー時間を推定する手段、ノードの各隣接ノードへのデータパケットの伝送時間を推定する手段、処理時間、キュー時間、往復時間および伝送時間を使用して、ノードとそのノードの各隣接ノードとの間で使用可能な帯域幅を推定する手段として代替的に使用されてよい。ホストコンピューティングシステムは、無線ホームデバイスとそのデバイスのＩ／Ｏインタフェースを経由して通信し、そしてインタフェースは、無線通信モジュールに接続される。従って、ホストコンピューティングシステムのＩ／Ｏインタフェースおよび有線通信モジュールは連結して、チャネルを使用したノードの各隣接ノードに対するチャネル情報および拡張サービスセット識別子および負荷情報を取得するのにノードによってチャネルをスキャンする手段、ノードの拡張サービスセット識別子およびそのノードの隣接ノードの拡張サービスセット識別子をビーコンメッセージでブロードキャストする手段、バックアップチャネルリストを更新する情報を受信する手段を含む。ホストコンピューティングシステムのＩ／Ｏインタフェースおよび有線通信モジュールは連結して、各隣接ノードの負荷情報をビーコンメッセージでブロードキャストする手段も含むことができる。ホストコンピューティングシステムのＩ／Ｏインタフェースおよび有線通信モジュールは連結して、各隣接ノードが使用可能な帯域をビーコンメッセージでブロードキャストする手段も含むことができる。

【0042】

本発明は、ハードウェア（例えば、ＡＳＩＣチップ）、ソフトウェア、ファームウェア、専用プロセッサ、または例えば、サーバ内のそれらの組み合わせ、中間デバイス（無線アクセスポイントまたは無線ルータなど）またはモバイルデバイスから成るさまざまな形式に実装されてよいことを理解されたい。好適には、本発明は、ハードウェアとソフトウェアとの組み合わせとして実装される。さらに、ソフトウェアは、好適には、プログラムストレージデバイス上で明示的に具体化されるアプリケーションプログラムとして実装される。アプリケーションプログラムは、適した任意のアーキテクチャを備えるマシンにアップロードされて、そのマシンによって実行されてよい。好適には、マシンは、１または複数の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）および入力／出力（Ｉ／Ｏ）インタフェース（複数）などの、ハードウェアを有するコンピュータプラットフォーム上で実施される。コンピュータプラットフォームは、オペレーティングシステムおよびマイクロ命令コードも含む。本明細書で説明したさまざまなプロセスおよび機能を、オペレーティングシステム経由で実行される、マイクロ命令コードの一部またはアプリケーションプログラムの一部（またはそれらの組み合わせ）のいずれかにできる。さらに、さまざまな他の周辺デバイスを、付加的なデータストレージデバイスおよび印刷デバイスなどの、コンピュータプラットフォームに接続できる。

【0043】

添付図面に示した一部の構成システムコンポーネントおよび方法ステップは、好適には、ソフトウェアに実装される理由により、システムコンポーネント（またはプロセスステップ）間の実際の接続は、本発明がプログラムされる方法に応じで異なる場合があることをさらに理解されたい。本明細書の教示を所与として、当業者は、本発明によるこれらおよび同様の実装または構成を企図することができるであろう。

付記１．
方法であって、前記方法は、
帯域幅認識ルーティングプロトコルを使用してソースノードと宛先ノードとの間の第１のルートを選択するステップと、
前記選択された第１のルートが前記ソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定するステップと、
前記アプリケーションの前記帯域幅要件が前記選択されたルートによって満たされていない場合、バックアップチャネルリストから選択された新しいチャネルへの切り替えを開始するステップと、
前記帯域幅認識ルーティングプロトコルを使用して、前記新しいチャネルを通じた第２のルートを選択するステップと、
前記新しいチャネルを通じた前記選択された第２のルートが前記ソースノードの前記アプリケーションの前記帯域幅要件を満たすかどうかを決定するステップと、
前記選択された第１のルートが前記アプリケーションの前記帯域幅要件を満たす場合、または、前記新しいチャネルを通じた前記選択された第２のルートが前記アプリケーションの前記帯域幅要件を満たす場合、前記ソースノードから前記宛先ノードまでデータをストリームするステップと、
を含む、前記方法。
付記２．
前記選択された第１のルート、または、前記選択された第２のルートの帯域幅情報を定期的に更新するステップと、
前記更新された帯域幅情報を使用して、前記アプリケーションの前記帯域幅要件が満たされ続けているかどうかを決定するステップと、
前記アプリケーションの前記帯域幅要件がもはや満たされていない場合、第３のルートを選択するステップと、
前記帯域幅要件を満たすルートが見つけられない場合、前記ソースノードの前記アプリケーションに通知するステップと、
前記アプリケーションの前記帯域幅要件が満たされ続けていない場合、または、前記選択された第３のルートが前記アプリケーションの前記帯域幅要件を満たす場合、データをストリームし続けるステップと、
をさらに含む、付記１に記載の方法。
付記３．
拡張サービスセット識別子、ならびに、負荷情報および使用可能な帯域幅情報のうちの１つを受信するステップと、
合計平均負荷または使用可能な帯域幅に従って、をバックアップチャネルリストのための複数のバックアップチャネルを選択するステップと、
前記バックアップチャネルリストをブロードキャストするステップと、
をさらに含む、付記２に記載の方法。
付記４．
装置であって、
帯域幅認識ルーティングプロトコルを使用して、ソースノードと宛先ノードとの間の第１のルートを選択する手段と、
前記選択された第１のルートが前記ソースノードのアプリケーションの帯域幅要件を満たすかどうかを決定する手段と、
前記アプリケーションの前記帯域幅要件が前記選択されたルートによって満たされていない場合、バックアップチャネルリストから選択された新しいチャネルへの切り替えを開始する手段と、
前記帯域幅認識ルーティングプロトコルを使用して、前記新しいチャネルを通じた第２のルートを選択する手段と、
前記新しいチャネルを通じた前記選択された第２のルートが前記ソースノードの前記アプリケーションの前記帯域幅要件を満たすかどうかを決定する手段と、
前記選択された第１のルートが前記アプリケーションの前記帯域幅要件を満たす場合、または、前記新しいチャネルを通じた前記選択された第２のルートが前記アプリケーションの前記帯域幅要件を満たす場合、前記ソースノードから前記宛先ノードまでデータをストリームする手段と、
を含む、前記装置。
付記５．
前記選択された第１のルート、または、前記選択された第２のルートの帯域幅情報を定期的に更新する手段と、
前記更新された帯域幅情報を使用して、前記アプリケーションの前記帯域幅要件が満たされ続けているかどうかを決定する手段と、
前記アプリケーションの前記帯域幅要件がもはや満たさない場合、第３のルートを選択する手段と、
前記帯域幅要件を満たすルートを見つけられない場合、前記ソースノードの前記アプリケーションに通知する手段と、
前記アプリケーションの前記帯域幅要件が満たされ続けている場合、または、前記選択された第３のルートが前記アプリケーションの前記帯域幅要件を満たす場合、データをストリームし続ける手段と、
をさらに含む、付記４に記載の装置。
付記６．
拡張サービスセット識別子、ならびに、負荷情報および使用可能な帯域幅情報のうちの１つを受信する手段と、
合計平均負荷、または、使用可能な帯域幅に従って、バックアップチャネルリストのための複数のバックアップチャネルを選択する手段と、
前記バックアップチャネルリストをブロードキャストする手段と、
をさらに含む、付記５に記載の装置。
付記７．
ノードを動作するための方法であって、
チャネルをスキャンして、前記チャネルを使用した前記ノードの各隣接ノードに対し、
チャネル情報、ならびに、拡張サービスセット識別子および負荷情報を取得するステップと、
ビーコンメッセージにおいて、前記ノードの拡張サービスセット識別子および前記ノードの前記隣接ノードの拡張サービスセット識別子をブロードキャストするステップと、
バックアップチャネルリストを更新する情報を受信するステップと、
を含む、前記方法。
付記８．
前記チャネルが、前記チャネルを使用した前記ノードの隣接ノードによって使用されていない時間の断片を推定するステップと、
前記ノードの隣接ノード間の伝送レートを推定するステップと、
前記ノードの隣接ノード間で使用可能な帯域幅を推定するステップと、
ビーコンメッセージにおいて、各隣接ノードのための前記負荷情報をブロードキャストするステップと、
をさらに含む、付記７に記載の方法。
付記９．
データパケットのための処理時間を推定するステップと、
前記ノードから各隣接ノードまでの前記データパケットの往復時間を推定するステップと、
前記データパケットのキュー時間を推定するステップと、
前記ノードの各隣接ノードの前記データパケットの伝送時間を推定するステップと、
前記処理時間、前記キュー時間、前記往復時間、および、前記伝送時間を使用して、前記ノードと前記ノードの各隣接ノードとの間で使用可能な帯域幅を推定するステップと、
ビーコンメッセージにおいて、各隣接ノードのための前記使用可能な帯域幅をブロードキャストするステップと、
をさらに含む、付記７に記載の方法。
付記１０．
ノードであって、
チャネルをスキャンして、前記チャネルを使用した前記ノードの各隣接ノードに対し、
チャネル情報、ならびに、拡張サービスセット識別子および負荷情報を取得する手段と、
ビーコンメッセージにおいて、前記ノードの拡張サービスセット識別子、および、前記ノードの前記隣接ノードの拡張サービスセット識別子をブロードキャストする手段と、
バックアップチャネルリストを更新する情報を受信する手段と、
を含む、前記ノード。
付記１１．
前記チャネルが、前記チャネルを使用した前記ノードの隣接ノードによって使用されていない時間の断片を推定する手段と、
前記ノードの隣接ノード間の伝送レートを推定する手段と、
前記ノードの隣接ノード間で使用可能な帯域幅を推定する手段と、
ビーコンメッセージにおいて、各隣接ノードの前記負荷情報をブロードキャストする手段と、
をさらに含む、付記１０に記載のノード。
付記１２．
データパケットのための処理時間を推定する手段と、
前記ノードから各隣接ノードまでの前記データパケットの往復時間を推定する手段と、
前記データパケットのキュー時間を推定する手段と、
前記ノードの各隣接ノードの前記データパケットの伝送時間を推定する手段と、
前記処理時間、前記キュー時間、前記往復時間および前記伝送時間を使用して、前記ノードと前記ノードの各隣接ノードとの間で使用可能な帯域幅を推定する手段と、
ビーコンメッセージにおいて、各隣接ノードのための前記使用可能な帯域幅をブロードキャストする手段と、
をさらに含む、付記１０に記載のノード。

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6】

【図7】