JP4607968B2 - 無線通信システムにおいてチャネル評価を実行するための方法及び装置 - Google Patents

Description

本発明は、共通に譲渡された係属中の米国特許出願番号第１０／２１６，０８２号、２００２年８月８日出願、名称“無線通信システムにおける二重モード無線通信のための方法及び装置（Method and Apparatus for a Dual-Mode Radio in a Wireless Communication System）”、共通に譲渡された係属中の米国特許出願番号第１０／２３５，０９０号、２００２年９月３日出願、名称“無線通信システムにおいてオーバーレイ適応周波数ホッピング・カーネルを実行する方法及び装置（Method and Apparatus Implementing an Overlay Adaptive Frequency Hopping Kernel in a Wireless Communication System）”、及び共通に譲渡された係属中の米国特許仮出願番号第６０／５３８，１３８号、２００４年１月２０日出願、名称“８０２．１１／ブルートゥース（登録商標）併設デバイスにおいて８０２．１１に支援されたチャネル評価を実行するための方法及び装置（Method and Apparatus for Performing 802.11-Assisted Channel Assessment in an 802.11/Bluetooth（登録商標） Collocated Device）”に関係し、それら全部は、その全体が引用によってここに取り込まれ、そして以降“関連出願”と呼ばれる。

本発明は、無線通信システムの分野に係り、そしてより詳しくは、無線通信システムにおけるチャネル評価（ＣＡ）を実行する分野に関する。

無線データ通信技術において周知のように、通信システムの設計において共通のトレードオフは、性能に対する帯域幅である。すなわち、通信性能の様々な態様は、無線通信周波数（ＲＦ：radio frequency）帯域幅の拡大という犠牲を払って改善することが可能である。通信システムの性能に寄与する１つの非常に重要な要因は、システムにおいて使用するデータ・チャネルの“品質”である。周知のように、データ受信エラーは、チャネルをわたるデータ伝送の間にノイズ及び干渉を持ち込むことによって引き起こされることがある。信号干渉は、チャネルを経由した伝送の間に信号及びそれに付随するデータを歪ませる。そのようなノイズ及び干渉のソースは、マルチパス・フェーディング、多元アクセス干渉、及び悪意の通信妨害のような無線通信周波数干渉（ＲＦＩ：radio-frequency interference）である。チャネル品質は、チャネルの信号レベルの強度に対して相対的にチャネル上に存在するノイズ及び干渉の大きさに大きく依存する。信号の強度に対して相対的に小さな大きさのノイズを有するチャネルは、高いチャネル品質を有する。逆に、信号レベルに対して相対的に大きな大きさのノイズを有するチャネルは、低いチャネル品質を有する。チャネル品質は、一般的にチャネルの信号対ノイズ（ＳＮＲ）すなわちＥｓ／Ｎｏ（すなわち、ノイズ・エネルギーに対する信号エネルギーの比）によって測定される。

無線通信システムは、様々なタイプのノイズ及び無線通信周波数干渉の存在下で信頼性良く動作するように適正に設計されることが可能である。例えば、非常に大きなＲＦ帯域幅を有する信号は、適応周波数ホッピング（ＡＦＨ：adaptive frequency hopping）として知られる方法を使用して発生されることがあり、ＡＦＨでは、ディジタル通信信号のキャリア周波数は、周波数の広い範囲にわたり適応するように変更される、すなわち、“ホップ”される。そのようなＡＦＨディジタル通信システムの１つが、ブルートゥース（登録商標）（Bluetooth^TM）プロトコル・システムであり、それは複数のブルートゥース・デバイス間のデータの伝達を容易にする。ブルートゥース技術は、ブルートゥース・スペシャル・インタレスト・グループ（ＳＩＧ：Special Interest Group）によって発行された仕様書、名称“ブルートゥース・システムの仕様書、１．２版”、中により詳細に記載されており、<http: //www.Bluetooth.com>で周知のインターネットを介して公衆に電子的に使用可能であり、２００３年１１月５日に発行され、“ブルートゥース仕様書”として本明細書中では呼ばれ、そしてブルートゥース・フロー制御、信号、デバイス、及び通信プロトコルと通信方式についての教示に関してその全体が引用によって本明細書中に組み込まれている。本明細書中で使用されるように、“ブルートゥース・デバイス”、“ブルートゥース通信システム”、又はそれらのいずれかの変形は、ブルートゥース・プロトコルにしたがって動作するデバイス又はシステムを呼ぶ。

上記に組み込まれている関連出願に、そして組み込まれたブルートゥース仕様書にさらに詳細に記述されるように、ブルートゥース通信システムは、マスタ・デバイスとスレーブ・デバイスとの間で通信するときに、周波数ホッピング・スペクトル拡散（ＦＨＳＳ：frequency-hopping spread spectrum）方式を使用する。この周波数ホッピング・スペクトル拡散方式にしたがって、周波数は、データ伝送の間に切り替えられる。周波数ホッピングは、指定された周波数ホッピング・アルゴリズムにしたがって実行され、その結果、デバイスは、正しい周波数ホッピング系列（すなわち、周波数の順番に並べられたリスト、時には、“ホップ・セット”と呼ばれる）を独立に決定することが可能である。１つの例では、擬似ランダムＦＨ系列は、スレーブ・デバイスに関連するマスタ・デバイス・アドレス及びクロック情報を使用してスレーブ・デバイスによって独立に決定される。

各ブルートゥース・マスタ・デバイスに関連するＦＨ系列はただ１つであるけれども、近接する範囲内で動作しているピコネットは、ブルートゥース・デバイスによって使用される比較的少ない数の独立したチャネルのために互いに干渉することがある。その上、チャネル・ノイズ及び干渉は、ブルートゥース・デバイスに近接する範囲内で動作している複数の非ブルートゥース・デバイスによって引き起こされることがある。例えば、上記に組み込まれている関連出願に記述されるように、ブルートゥース・デバイスに近接して動作している８０２．１１プロトコル・デバイスは、使用できないブルートゥース・デバイスのホップ・セット中の１又はそれより多くのチャネルをレンダリング（rendering）する望ましくないＲＦ干渉を引き起こすことがある。周知のように、様々なＩＥＥＥ８０２．１１通信プロトコル（以降“８０２．１１”と呼ばれる）は、２．４ＧＨｚ無線周波数で動作する無線通信に関する世界的な規格である。１つの具体例の良く知られた８０２．１１通信プロトコルは、ＩＥＥＥ８０２．１１ｂプロトコルである（以降“８０２．１１ｂ”と呼ばれる）。８０２．１１ｂプロトコルは、８０２．１１ｂデバイス（すなわち、８０２．１１ｂ規格に準拠するもの）が高データ伝送レート（例えば、１１Ｍｂｐｓ）で動作することを可能にする。８０２．１１ｂプロトコルは、無線ローカル・エリア・ネットワーク（ＷＬＡＮ：Wireless Local Area Network）を実行させる際に特に有用である。８０２．１１ｂ規格に準拠するデバイスは、ＩＥＥＥ８０２ワーキング・グループによって作られた規格、名称“ＩＥＥＥ規格 ８０２．１１ｂ−１９９９”にさらに詳細に記載されており、<http: //standards.ieee.org>で周知のインターネットを介して公衆に電子的に使用可能であり、本明細書中では“８０２．１１ｂ仕様書”と呼ばれ、そして８０２．１１ｂフロー制御、信号、デバイス、及び通信プロトコルと通信方式についてのその教示に関してその全体が引用によって本明細書中に組み込まれている。別の１つのＩＥＥＥ８０２．１１通信プロトコルは、新たに現れようとしているＩＥＥＥ８０２．１１ｇである。

上記のように、干渉の問題を解決する際に使用されることができる１つの技術は、ＡＦＨである。ＡＦＨの目的は、ブルートゥース・デバイスが工業的な、科学的な、そして医学的な（ＩＳＭ：Industrial, Scientific, and Medical）２．４ＧＨｚ帯域において他のデバイスに干渉を生じさせることを回避することを可能にしつつ、ブルートゥース・デバイスが干渉に対するそれらの安全性を改善することを可能にすることである。基本的な原理は、ブルートゥース・チャネルが使用済み及び未使用の２つのカテゴリーへとクラス分けされることであり、ここで、使用済みチャネルは、ホッピング系列の一部であり、そして未使用チャネルは、ホッピング系列中で擬似ランダムな方法で使用済みチャネルよって置き換えられる。このクラス分けの機構は、組み込まれたブルートゥース仕様書中で必要とされる７９又はそれより少ないチャネルをブルートゥース・デバイスが使用することを可能にする。米国においては、ＦＣＣがその規則を変更した２００２年までは少なくとも７５チャネル（ＭＨｚ）が必要とされたことに注意する。少なくとも２０チャネルを必要とする（ヨーロッパのような）別の場所があるが、米国における現在のチャネルの最小数は、１５である。それゆえ、組み込まれたブルートゥース仕様書によって認められるチャネルの最小数、Ｎ_ＭＩＮ、は、２０である。

具体例のＡＦＨホッピング系列は、次の通りである。一例として、ブルートゥースが１０チャネル（０から９）を使用すると仮定する。もし全てのチャネルが“良い”ならば、ホッピング・パターンは、次のようになるはずである：
４６１７５３９３４１２１６５３８６１０３８４０２
ここで、もしチャネル６及び７が“悪い”と決定されるならば、ホッピング・パターンは、次のように現れるはずである：
４ｘ１ｘ５３９３４１２１ｘ５３８ｘ１０３８４０２
各々のケースにおいて、“ｘ”の値は、他の８つの有効なチャネル（０−５及び８−９）から擬似ランダムに選択されるはずである。そういうわけで、新たなホッピング系列は、置き換えた後で、次のように現れるはずである：
４５１９５３９３４１２１１５３８０１０３８４０２
組み込まれているブルートゥース仕様書は、相互運用可能性を保証するために必要であるＡＦＨの複数の態様を規定する。これは、ホッピング・カーネル、ベースバンド特性（behavior）、リンク・マネージャ・プロトコル（ＬＭＰ：Link Manager Protocol）命令、及びホスト・コントローラ・インターフェース（ＨＣＩ：Host Controller Interface）命令並びにホッピング系列を変更するためそして設定するために必要なイベント（event）を含む。ブルートゥース仕様書は、同様に、スレーブがチャネル・クラス分け情報をマスタに報告することを可能にする機構も規定する。しかしながら、ブルートゥース仕様書は、チャネル評価機構のいずれかの具体的な必要事項を規定していない又は記述していない。チャネル評価は、様々なチップセットの革新そして最終製品製造者に残されている。

上に述べられたように、“チャネル評価”は、ブルートゥース・デバイスによって使用されるアルゴリズムとして与えられることができ、２．４ＧＨｚ ＩＳＭ帯域の範囲内でどのチャネルが良く、どれが悪いかについてのチャネル・マップを決定する。このチャネル・マップは、その後、適応周波数ホッピング（ＡＦＨ）のために使用されることができる、又はチャネル取り消し（avoidance）のような専用の共存技術のために使用されることができる。例えば、チャネル・マップは、どのチャネルが“使用済み”（すなわち、チャネル・マップから“良い”チャネル）であるか、そして“未使用”（すなわち、チャネル・マップから“悪い”チャネル）であるかを決定するために使用されることができる。

現在のところ、チャネル評価アルゴリズムは、チャネル・マップを発生する際にアクティブ測定値（例えば、ビット・エラー・レート、又はパケット・エラー・レート）又はパッシブ測定値（例えば、受信信号強度指示値（ＲＳＳＩ：Received Signal Strength Indication）のいずれかを使用している。不都合なことに、パッシブ測定値又はアクティブ測定値のいずれかを使用するとき、測定値の精度は、干渉物（interferer）のデューティ周期、干渉物の数、使用するサンプルの数、等を含む複数の要因に依存する。一般に、これらの技術は、干渉の正確な推定を提供するように設計されている。しかしながら、結局は、結果は、干渉のプロフィールが実際にどのように見えるかを推測するだけである。したがって、これらの技術を使用すると、干渉プロフィールは、決して１００％正確ではないであろう。

それゆえ、データ・チャネルにおけるＲＦ干渉の存在を推定しそして検出する方法及び装置に対する必要性が存在する。データ・チャネルは、“不許可”である（すなわち、悪いチャネル状態を表している）とＡＦＨ方式によって以前に決定されてしまっていることがある、又は周波数ホップ・セット内のチャネルであり得る。干渉検出装置及び方法は、間歇的な干渉の存在が検出される必要がある任意の通信システムにおける使用に対して敏感なはずである。

［発明のサマリー］
本発明は、周波数ホッピング無線通信システムにおいてチャネルをクラス分けするためのシステム及び方法を提供する。一般に、本システムは、データ収集エンジン及びデータ解析エンジンを含む。データ収集エンジンは、無線通信システムによって使用される各チャネルに対する干渉のレベルを示しているチャネル・メトリック（metric）を得るために動作する。データ解析エンジンは、適応周波数ホッピング（ＡＦＨ）のためのチャネル・マップ及び／又はチャネル取り消しのためのチャネル・マップを提供するために動作する。より具体的に、データ解析エンジンは、最初に周波数ホップ干渉を示すチャネル・メトリックを除去するために該チャネル・メトリックをフィルタするために動作し、その結果周波数スタティックな（frequency static：周波数で変わらない）干渉を示すチャネル・メトリックだけが残る。次に、チャネルは、多数のチャネル・ブロックへと分割され、各々は少なくとも２つの隣接するチャネルを含む。各チャネル・ブロックについて、チャネル・ブロック内の複数のチャネルのチャネル・メトリックは、メトリック合計を与えるために統合される。データ解析エンジンは、その後、チャネル・ブロックの各々に対するメトリック合計に基づいて各チャネルを使用可能である又は使用不可能であるとクラス分けするために動作する。

ＡＦＨのためのチャネル・マップを与えるために、データ解析エンジンは、最初に、チャネル・ブロックに対するメトリック合計に基づいて最悪の干渉を有するチャネル・ブロックを見つける。１つの実施形態では、データ解析エンジンは、最悪のＭＡＸ＿ＡＦＨチャネル・ブロックを見つける、ここで、ＭＡＸ＿ＡＦＨは、ＡＦＨのために使用不可能であるとしてクラス分けされることができるチャネルの最大数に対応するブロックの数である。一旦、最悪の干渉を有するチャネル・ブロックが見つけられると、データ解析エンジンは、これらのチャネル・ブロックの各々に対するメトリック合計をしきい値と比較する。メトリック合計がしきい値を超える場合、チャネル・ブロックに対するハングオーバー・タイマは、予め決められた最大値に設定され、そしてチャネル・ブロック内の複数のチャネルは、使用不可能であるとクラス分けされる。一旦、ハングオーバー・タイマが設定されると、対応するチャネルは、ハングオーバー・タイマが終了するまで使用可能であるとしてクラス分けされることができない。その上、関係する無線デバイス又はスレーブ・デバイスのようなデバイスからの遠隔メトリックは、チャネルをさらにクラス分けするために使用されることができる。

チャネル取り消しのためのチャネル・マップを与えるために、データ解析エンジンは、最初に、チャネル・ブロックに対するメトリック合計に基づいて、そしてオプションとしてチャネル・ブロックに対するメトリック合計の最新のピーク値に基づいて、最悪の干渉を有するチャネル・ブロックを見つける。一旦、最悪の干渉を有するチャネル・ブロックが見つけられると、メトリック合計、又はオプションとしてメトリック合計ピーク値は、周波数スタティックな干渉の中心周波数に対応するチャネルを見つけるためにフィルタされる。その後で、中心周波数に対応するチャネル及び中心周波数の周りの予め決められた帯域幅内の複数のチャネルは、使用不可能であるとしてクラス分けされる。その上、関係する無線デバイス又はスレーブ・デバイスのようなデバイスからの遠隔メトリックは、チャネルをさらにクラス分けするために使用されることができる。

当業者は、そして添付される図面とともに好ましい実施形態の下記の詳細な説明を読んだ後で、本発明のスコープを評価するであろう、そしてそのさらなる態様を理解するであろう。

［好ましい実施形態の詳細な説明］
本明細書に取り込まれそして一部を形成する添付した図面は、本発明の複数の態様を説明し、そして詳細な説明とともに本発明の原理を説明するために機能する。

以下に述べられる実施形態は、当業者が本発明を実行することを可能にするために必要な情報を提供し、そして本発明を実行する最良の方式を説明する。添付されている図面に照らして以下の説明を読むと、当業者は、本発明の概念を理解するであろう、そして本明細書中で特に向けられていないこれらの概念のアプリケーションを認識するであろう。これらの概念及びアプリケーションが本明細書及び添付された特許請求の範囲内になることが理解されるはずである。

図１は、ブルートゥース・デバイス１２、８０２．１１ｂ規格又は８０２．１１ｇ規格のいずれかにしたがって動作する無線デバイス１４、及びホスト１６を含んでいる具体例のシステム１０を図示する。一般に、ブルートゥース・デバイス１２及び無線デバイス１４は、ハードウェア・インターフェース１８を介して通信して、優先順位情報及びチャネル情報のような情報を交換する。ホスト１６は、パーソナル・コンピュータ、移動電話機、個人ディジタル補助装置（ＰＤＡ：personal digital assistants）、又はその他であり得る、そして無線デバイス１４との通信を可能にするドライバ２０を含む。ホスト１６は、同様に、ソフトウェア・インターフェース２２を介してブルートゥース・デバイス１２と通信でき、チャネル情報のような情報を提供できる。システム１０は、単に具体例であることに注意すべきである。ブルートゥース・デバイス１２は、無線デバイス１４及びホスト１６のうちの１つだけとの組み合わせで動作できる、又はブルートゥース・デバイス１２は、無線デバイス１４及びホスト１６なしで独立に動作できる。

この実施形態では、ブルートゥース・デバイス１２は、３つのタイプの共存（coexistence）：チャネル取り消し（channel avoidance）、適応周波数ホッピング（ＡＦＨ：adaptive frequency hopping）、及び優先伝送、を実行できる。したがって、ブルートゥース・デバイス１２は、チャネル取消しシステム２４、ＡＦＨシステム２６、及び優先伝送システム２８を含む。ブルートゥース・デバイス１２は、ブルートゥース１．１デバイスと通信しているか又はブルートゥース１．２デバイスと通信しているかどうかに応じて、チャネル取り消し又はＡＦＨのいずれかを使用するように構成されることができる。

本発明は、チャネル取消しシステム２４及びＡＦＨシステム２６のうちの１つ又は両方にチャネル・マップを与えるためのシステム及び方法を提供する。より具体的に、チャネル評価（すなわち、チャネル“クラス分け”）は、２つの論理的なステップ、データ収集、及びデータ解析、で実行される。図１に図示されているように、これらのステップは、データ収集エンジン３０及びデータ解析エンジン３２によって実行される。１つの実施形態では、ブルートゥース・デバイス１２は、ブルートゥース・マスタ・デバイスであり、そしてデータ解析エンジン３２の出力は、チャネル取消しシステム２４又はＡＦＨシステム２６によって使用される使用済みチャネル及び未使用チャネルのセット、又はチャネル・マップである。データ解析エンジン３２の出力は、チャネル取消しシステム２４のための第１のチャネル・マップ及びＡＦＨシステム２６のための第２のチャネル・マップのどちらか１つであり得る。別の１つの実施形態では、ブルートゥース・デバイス１２は、ブルートゥース・スレーブ・デバイスであり、そしてデータ解析エンジン３２の出力は、チャネル取消しシステム２４によって使用される使用済みチャネル及び未使用チャネルの同じセットである。その上、スレーブ・デバイスとしてイネーブルされるとき、チャネル・マップは、マスタ・ブルートゥース・デバイスに報告されることができる。

データ収集
具体例の実施形態では、データ収集エンジン３０は、無線通信システム中のあらゆるチャネルについての複数のメトリック（metric）を定期的に集める。各チャネルについて収集されるメトリックの数は、変更可能であり得る。その上、しきい値レベル及びメトリック収集期間を含む他のパラメータは、変更可能であり得る。本発明の具体例の実施形態では、データ収集エンジン３０は、２つのタイプの情報又はメトリック：受信信号強度情報（ＲＳＳＩ：received signal strength information）及びパケット・エラー・レート情報（ＰＥＲ：packet error rate）、を収集する。

データ収集エンジン３０は、動作の２つのモードのうちの１つ：パーソナル・コンピュータ（ＰＣ：Personal Computer）モード及びセル電話機モード、で動作する。動作の２つの異なるモードは、異なる電力消費必要量を有する。セル電話機モードの動作は、同様に、個人ディジタル補助装置（ＰＤＡ）のような他の類似の電力を消費するプラットフォーム、及び限られたバッテリー容量を有しそして類似の電力消費特性を有する別のデバイスにおいて使用されることができる。

ＰＣモードの動作では、データ収集エンジン３０は、干渉情報を集めることによって、そして受動的チャネル評価方式又は能動的チャネル評価方式のいずれかを使用して各チャネルに対するチャネル・メトリックを決定することによって、チャネル評価を定期的に実行する。より詳しくは、干渉情報が集められ、そしてアクティブな接続の間に、そして決められた収集期間（本明細書中では“チャネル・クラス分けインターバル”と呼ばれる）の間にチャネル・メトリックが決定される。１つの具体例の実施形態では、収集期間は、干渉情報が集められる時間とチャネル・メトリックが決定される時間との間のインターバル（秒で）である。１つの実施形態では、収集期間のデフォルト値は、２秒である。アイドル・モードの間に、干渉情報が集められ、そしてチャネル・メトリックは、別々に規定されたアイドル・モード収集期間（ここでは、“アイドル・モード・チャネル・クラス分けインターバル”と呼ばれる）の間に決定される。１つの具体例の実施形態では、アイドル・モード収集期間は、アイドル・モードの間に干渉情報が集められる時間とチャネル・メトリックが決定される時間との間のインターバル（秒で）である。１つの実施形態では、アイドル・モード収集期間のデフォルト値は、６０秒である。２つの収集期間は、互いに異なることがあり、そして固有のアプリケーションの速度要求及び電力消費要求を適応させるために変更されることができる。

セル電話機モードの動作では、チャネル評価は、オーディオ・リンクにおいて顕著な劣化があるときにだけ実行される。これは、チャネル評価機能に関係する電流消費量を最小にするために行われる。１つの具体例の実施形態では、パケット・エラー・レート（ＰＥＲ）は、各々の受信パケットに対して決定される。ＰＥＲが予め決められたしきい値を超えるときに、チャネル評価は実行される。より詳しくは、干渉情報が集められ、そしてＰＥＲが予め決められたしきい値を超えたときにだけ、チャネル・メトリックは決定される。そのようにして、セル電話機モードでは、チャネル評価は、定期的というよりはむしろ必要なときに実行されるだけであり、それによって電力消費量を減少させる。チャネル評価がセル電話機モードに対して一旦トリガされると、チャネル評価は、正にＰＣモードの動作のように進行し、ＰＣモードであるときにはチャネル評価が定期的に実行されるが、セル電話機モードであるときには必要なときに実行されることだけが違いであることに、注意すべきである。

ＰＣモードの動作及びセル電話機モードの動作の両方で使用されるチャネル評価機構は、以下により詳細に説明される。多くの技術が、干渉を検出するために使用されることができる。本明細書中で説明される１つのそのような技術は、ＲＳＳＩメトリックを使用する受動的な方式を使用する。この技術は、非常に敏感であり、そして非常に低いレベルの干渉（ブルートゥース受信機に干渉を生じさせるものよりも十分に低いレベル）を検出する。電力消費量に非常に敏感でありそしてブルートゥース性能を保護するために必要であるだけの（すなわち、“良き隣り合うもの”である必要がない）アプリケーションに関して、受動的な測定値は、要求されるときにだけ使用される。これらのケースでは、パケット・エラー・レート（ＰＥＲ）又はパケット紛失レート（ＰＬＲ：packet loss rate）は、“悪い”チャネルを決定するために使用されることができる。メトリック収集プロセスの詳細は、次の節で示される。

受動的チャネル評価
受動的チャネル評価は、一般的にブルートゥース・システムにおける他のイベントよりも低い優先度のタスクである。しかしながら、理想的にはＡＦＨが上手く働くことを確実にするためにチャネル評価に対して保証された最小の長さの時間であるはずである。チャネル評価のために割り当てられた時間の長さが必要な長さよりも短い場合に、チャネル評価は、遅くなる又は干渉を取り消すことが不可能になるであろう。ＰＣモードの動作では、収集期間（チャネル・クラス分けインターバル）は、接続の間の全てのチャネルの受動的チャネル評価間の時間を規定し、そしてアイドル・モード収集期間（アイドル・モード・クラス分けインターバル）は、アイドル・モードの間の全てのチャネルの受動的チャネル評価間の時間を規定する。セル電話機モードの動作では、受動的チャネル評価は、能動的チャネル評価の間に検出される受信パケットのパケット・エラー・レートが規定されたしきい値を超えるときにだけトリガされる。受動的チャネル評価が実行されるときはいつでも、動作のモードに拘らず、チャネルの許容可能な推定値を得るために（すなわち、チャネルに関する高品質の統計値が得られるであろうことを確実にするために）、サンプルの最少数（ここでは、“必要なサンプル”と呼ばれる）が、各チャネルに対して得られるはずである。１つの実施形態では、期間当りチャネル当りの必要とされるサンプルの数（“必要なサンプル”）についてのデフォルト値は、２０である。１つの具体例の実施形態では、これは、サンプルの総数が期間当りチャネル当りの必要なサンプルとブルートゥース・チャネルの総数との積（必要なサンプル×７９）に等しいか又はそれを超えるであろう、ここで、７９は、ブルートゥース・チャネルの総数である。したがって、例えば、期間当りの各チャネルに対して必要とされるサンプルの数が１０である場合に、得られるであろうサンプルの総数は、７９０である。設計のトレードオフは、チャネル評価のために使用される通信時間（air time）とチャネル・クラス分けの速度、品質及び精度との間に存在する。

図２は、受動的チャネル評価を実行するときのデータ収集エンジン３０の具体例の動作を説明するフローチャートである。受動的チャネル評価は、各チャネルに対するチャネル・メトリックをゼロのようなあるデフォルト値に初期化することによって始まる（ステップ２００）。次に、干渉情報が最初のチャネルに対して収集される（ステップ２０２）。この実施形態では、干渉情報は、ＲＳＳＩである。次に、最初のチャネルについてのＲＳＳＩは、一連のしきい値と比較され、そして一連のしきい値を超えるもののうちの最大のものに対応する値が、チャネル評価メトリック・アレイ中の最初のチャネルに対するチャネル・メトリックに加算される（ステップ２０４）。ＲＳＳＩを一連のしきい値と比較することによって、チャネル・メトリックに加算される値がＲＳＳＩの関数であることを注意することは、重要である。次に、ＲＳＳＩが予め規定されたしきい値を超える場合に、チャネルに対する悪いメトリックの数に対応する記憶された値が、１だけ増加される（ステップ２０６）。ＲＳＳＩの次の測定値のためのチャネル番号が計算される（ステップ２０８）。もしチャネル評価がアクティブな接続の間に生じるのであれば、次のチャネル番号は、ホッピング系列中の次のチャネルであり得る。もしチャネル評価がアイドル時間の間に生じるのであれば、次のチャネルは、予め決められたホッピング系列中の次のチャネルであり得る又は単純に次のチャネル（現在のチャネル＋１）であり得る。次に、十分な数のサンプルが得られているかどうかについての決定がなされる（ステップ２１０）。上に述べられたように、各チャネルに対して１以上のサンプルを得ることが望ましい。そのように、もし７９チャネルがあり、そして各チャネルに対して１０サンプルが望まれるのであれば、ステップ２０２−２０８は、７９０回繰り返して実行される。所望の数のサンプルが一旦得られると、プロセスは終了する。

１つの具体例の実施形態では、決定論的なホッピング系列がＲＳＳＩを測定するために要求され、その結果、各チャネルは同じ回数サンプリングされる。１つの実施形態では、ホッピング系列は、可変スキップ・レートを有するように設計される。ＲＳＳＩが得られる各回で、それは一連のしきい値と比較される。例えば、一連のしきい値は、−７５ｄＢｍを超える３ｄＢ毎であり得る。サンプリングされたＲＳＳＩ値が最小のしきい値を超えるとき、ある種の干渉がチャネル上に存在し、そしてエラーが記録される。エラーの程度は、しきい値アレイのどの要素がＲＳＳＩ値と比較されようとしているかに基づく。ＲＳＳＩしきい値に関する単純なブール・アプローチを使用すること（すなわち、ＲＳＳＩ値がしきい値を上回るか下回るかのどちらであるかどうかを決定すること）が、よくない結果を生み出すことを、本発明者は見出した。その代わりに、上記のように、本発明の方法及び装置は、各チャネルについてチャネル・メトリックに加算する値の大きさをＲＳＳＩの関数として決定するために重み付け値解析を使用する。これは、干渉の中心を決定する際に著しく手助けになる。同様に、どのチャネルが特に厄介でありそして排除されるべきであるかを識別する際に手助けになる。例えば、もし２０チャネルだけが排除され得るが、４０チャネルが“悪い”として検出されるのであれば、特定の厄介なチャネル（すなわち、最悪の干渉特性を示しているもの）を識別することは重要である。

チャネル評価は、チャネル評価フレームを使用してマスタ・デバイスにおいて実行されることができる。図３に図示されたように、１つの実施形態では、チャネル評価フレームは、信号の存在又は無いことを決定するために使用する２つのバック・ツー・バック・タイムスロットを備える。これらのフレームは、優先権方式を使用するシステムにおいて別のフレームのスケジューリングに対して同様にスケジュールされるはずである。

１つの実施形態では、これらの測定のタイミングは、（期間が６２５マイクロ秒の）１ブルートゥース・タイムスロット内で複数のＩＤパケットを受け取るために使用されるタイミングと同様であり得る。図３に示されているように、チャネル評価フレーム中の２つのタイムスロットは、全く同じに構成される。最初に、周波数が計算され、そしてシンセサイザに書き込まれる。ハードウェアは、それからＲＳＳＩを測定するために必要な期間のあいだ受信するように設定される。第２の周波数が計算され、そしてシンセサイザに書き込まれ、そして２番目の受信は、後半の半スロット（すなわち、６２５マイクロ秒タイムスロットの最後の３１２．５マイクロ秒）において実行される。

可能なときはいつでも、ブルートゥース・デバイス１２は、未使用のタイムスロットの間に受動的チャネル評価イベントを実行する。多くのケースでは、特に同時接続のケースでは、これは結果としてスループットの低下にはならないであろう。しかしながら、全スループットを使用しようと試みるアプリケーションは、チャネル評価に起因するスループットの低下の影響を受けることがあるケースであり得る。しかしながら、大部分のケースでは、その影響は、小さく、チャネル評価のための収集期間にわたって分散されるであろう、そしてスループットの低下を気が付かないであろう。

ある複数の実施形態では、ブルートゥース・デバイス１２がマスタ・デバイスであるときに、チャネル評価フレーム（２つのタイムスロット）は、別のブルートゥース・イベントと同様にスケジュールされることができる。しかしながら、スレーブ・デバイスは、マスタ・デバイスによってアドレスを指定されていないフレームを使用するだけであり得る。スレーブについてのチャネル評価は、スレーブがマスタに対して使用可能な時間の長さを削減しない。ある複数の実施形態では、特に集める期間のメトリックをスケジューリングする目的のために（例えば、“アブセンス・マスク（Absence Mask）”フィーチャを使用して）無いことをスケジュールすることが、可能である。

能動的なチャネル評価
ある複数の実施形態では、能動的なチャネル評価は、全ての受信パケットについて実行される。パケット・エラー・レート（ＰＥＲ）統計値（すなわち、巡回冗長コード（ＣＲＣ：Cyclic Redundancy Code）不良の割合）及びパケット紛失レート（ＰＬＲ）統計値（すなわち、アクセス・コードが無くなることに起因するパケット紛失又はパケット・ヘッダ・エラーの割合）は、チャネル当りのベースでパケットについて収集される。ＰＥＲ／ＰＬＲ統計値は、定期的に評価される。ＰＥＲ／ＰＬＲ統計値の各評価の間のインターバルは、ここではＰＥＲインターバルとして定義される。１つの実施形態では、ＰＥＲインターバルのデフォルト値は、１０秒である。この実施形態にしたがって、アクセス・コード、パケット・ヘッダ及びＣＲＣは、各パケット受信の後で評価される。イベントの総数、及び無くなったアクセス・コード、悪いパケット・ヘッダ及び悪いＣＲＣの数が、記憶される。

能動的なチャネル評価技術が通常のパケット伝送を使用するという理由で、ＰＥＲ／ＰＬＲが規定されたしきい値を超えない限りは追加の電力消費がない。セル電話機モードの動作に関して上に述べられたように、ＰＥＲ／ＰＬＲが規定されたしきい値を超えるときには、上記の受動的チャネル評価がトリガされる。追加の電力消費量は、したがって単位時間当たりの受動的チャネル評価の平均数に基づく。大部分のケースでは、追加の電力消費量は、ほぼゼロである。

データ解析及びチャネル・クラス分け
ＰＣモードの動作又はセル電話機モードの動作のいずれにおいても、受動的チャネル評価が実行された後で、各チャネルに対するチャネル・メトリックは、データ解析エンジン３２（図１）に与えられる。データ解析エンジン３２は、チャネル・メトリックに基づいてどのチャネルが良好でありそしてどのチャネルが悪いかを決定するように動作し、それによってＡＦＨ及び／又はチャネル取り消しのために使用されるべき１又はそれより多くのチャネル・マップを生成する。本発明にしたがって、チャネル・メトリックは、マルチ・ステージ・プロセスを使用して解析される。本発明のマルチ・ステージ・データ解析及びチャネル・クラス分けプロセス４００は、データ解析エンジン３２によって実行され、そして図４の単純化されたブロック図に図示される。

図４に図示されたように、本発明のデータ解析エンジン３２によって実行される本発明のマルチ・ステージ・データ解析及びチャネル・クラス分けプロセス４００は、周波数ホップ干渉フィルタリング・ステージ４０２、干渉波形検出ステージ４０４、干渉対時間ステージ４０６、及びメトリック・コンバイナ・ステージ４０８を含む。１つの具体例の実施形態では、チャネル・メトリックがデータ解析エンジン３２によって処理された後で、それらはリセットされる。データ解析及びチャネル・クラス分けプロセス４００によって使用されるチャネル・メトリックが上に述べられたようにローカル・データ収集エンジン３０（図１）から得られるのであるが、ブルートゥース１．２デバイス（すなわち、上記に取り込まれているブルートゥース仕様書に適合するデバイス）は、同様に、別のソースから得られたメトリックを使用することができる。例えば、ブルートゥース１．２デバイスは、ソフトウェア・インターフェース２２を介してホスト・デバイス１６（図１）から、ハードウェア・インターフェース１８を介して無線デバイス１４から、又はそれらがブルートゥース１．２デバイスでありそしてチャネル・クラス分け情報を報告することをイネーブルされている場合にスレーブから得られる遠隔メトリックを考慮することができる。設定パラメータとともにこれらの遠隔メトリックは、本発明のデータ解析及びチャネル・クラス分けプロセス４００によって処理されることができる。図１に示されたように、プロセス４００は、ＡＦＨチャネル・マップを生成し、それはＡＦＨシステム２６への入力として使用される。プロセス４００は、同様に取り消しチャネル・マップを生成し、それはチャネル取消しシステム２４への入力として使用されることができる。上に述べられたように、プロセス４００は、ＡＦＨチャネル・マップ及び取り消しチャネル・マップを提供することができる。あるいは、プロセス４００は、ＡＦＨチャネル・マップだけ又は取り消しチャネル・マップだけを提供することができる。

１つの具体例の実施形態では、ローカル・チャネル評価機構がイネーブルされるとき、データ解析は、図４に示された処理ブロックにしたがって進行する。すなわち、ローカル・チャネル・メトリックは、最初に周波数ホップ干渉フィルタリング・ステージ４０２によって処理され、次に処理は干渉波形検出ステージ４０４、干渉対時間ステージ４０６、そしてメトリック・コンバイナ・ステージ４０８に続く。しかしながら、そこでは解析が図４に示された最初の３つの処理を飛ばす（すなわち、ブロック４０２，４０４、及び４０６が飛ばされる）ケースでは、ローカル・チャネル評価がディスエーブルされることがあり、そして処理は、メトリック・コンバイナ・ステージ４０８によってだけ実行される。本発明の方法及び装置の１つの実施形態では、ローカル・チャネル評価は、ブルートゥース・デバイス１２に伝達される予め規定されたコマンドを使用してイネーブルされることができる又はディスエーブルされることができる。一旦、ローカル・メトリックの全てがデータ解析及びチャネル・クラス分けプロセス４００に対して使用可能にされると、マルチ・ステージ処理は、干渉検出の信頼性及び品質を向上させるために使用される。各処理ステージは、ここにさらに詳細に説明される。

ステージ１：周波数ホップ干渉物（Interferer）フィルタ
処理の最初のステージにおいて、例えば、近くのブルートゥース・デバイスによって引き起こされる干渉、しかしこれに限定されない、のような周波数ホップ干渉は、周波数ホップ干渉フィルタリング・ステージ４０２によって取り除かれる。周波数ホップ干渉は、８０２．１１デバイス、コードレス電話機、ある種の電子レンジ及び類似のデバイスのようなソースからの周波数スタティックな干渉（frequency static interference）を明らかにするためにフィルタされる。本発明の方法及び装置の１つのゴールは、一定の（すなわち、“非周波数ホッピング”）干渉を検出しそして識別することである。したがって、さらなるデータ解析が実行される前に、周波数ホップ干渉を最初に除去することは重要である。

動作において、上に述べたように受動的チャネル評価を使用して、一旦、チャネル・メトリックがデータ収集エンジン３０（図１）によって得られると、１回目の処理は、複数のチャネル・メトリック全体に行われ、各チャネルが時間のある割合よりも長く干渉を受けているかどうかを決定する。周波数ホップ干渉がＮ個の周波数ホップ毎にほぼ１回生じるという理由で、ここでＮは周波数ホッピング系列において使用するチャネルの数である、７９のチャネルを使用する２つのデバイスは、両方のピコネットが全部アクティブでありそして単一スロット・パケットを使用しているのであれば、７９のパケット毎にほぼ１回互いに干渉するであろう。その領域におけるピコネットの数が増加するにつれて、この干渉は増加する。したがって、Ｍ個のピコネットがあるならば、エラーの確率は、≧Ｍ／Ｎである。予想される近くのピコネットの数よりも大きい最小ＲＳＳＩパーセントしきい値を選択することによって、近くのピコネットによって生成される干渉を除去することが可能である。例えば、もし、予想される近くのピコネットの数が５であれば、周波数ホップ干渉フィルタリング・ステージ４０２を設定するために使用する最小ＲＳＳＩパーセントしきい値は、５／７９すなわち６．３％に設定されるはずである。最小ＲＳＳＩパーセントしきい値は、設定パラメータとして周波数ホップ干渉フィルタリング・ステージ４０２に入力されることができる又はソフトウェア中にハード・コード化されることができる。

図５は、周波数ホップ干渉フィルタリング・ステージ４０２の１実施形態を説明するフローチャートである。図５を説明する前に、受動的チャネル評価が各チャネルに対して２つの値：チャネル・メトリック及び悪いメトリックの数に対応する値、を提供することを思い出すことは、利益をもたらすであろう。チャネル・メトリックは、チャネルの各サンプルに対して測定されたＲＳＳＩの関数として決定される値の合計である。悪いメトリックの数は、予め決められたしきい値を超えるチャネルに対するＲＳＳＩ測定値の総数である。

図５に示されたように、周波数ホップ干渉フィルタリング・ステージ４０２は、最初に各チャネルについて悪いメトリックの数をしきい値と比較する（ステップ５０２）。もし、所望のＲＳＳＩパーセントしきい値が５／７９すなわち６．３％であれば、しきい値は５である。各チャネルに関して、もし悪いメトリックの数がしきい値、それは例えば５であり得る、よりも少なければ、そのチャネルに対するチャネル・メトリックは、ゼロ又はある別の任意の数に設定される。そのようにして、周波数ホッピング干渉（非スタティック干渉）に対応するチャネル・メトリックは除去され、そしてスタティックな干渉に対応する複数のチャネル・メトリックだけが残る。

ステージ２：干渉波形検出
図６は、図４の干渉波形検出ステージ４０４の動作の１つの実施形態を説明するフローチャートである。従来技術は、干渉を有するとして検出されたどのチャネルも遮断する。しかしながら、ブルートゥース・デバイスと干渉する可能性があるチャネルの全てを必ずしも遮断する必要が無く、（８０２．１１デバイスのような）別の１つのデバイスに干渉を生じさせることがあるチャネルの全てを必ずしも遮断する必要も無いという理由で、これらの従来技術のアプローチは、不利である。したがって、どのチャネルが悪いかの正確な像を得ることは、素晴らしい価値を有する。本方法及び装置は、チャネルにおける干渉の存在を検出するのみならず、干渉の帯域幅（すなわち、“波形”）も識別する。

図示されたように、ハードウェア・インターフェースに関係するチャネル評価メトリックは、ゼロにされ（ステップ６００）、そしてソフトウェア・インターフェースに関係するチャネル評価メトリックは、ハングオーバー・タイマが適用されないようにゼロにされる（ステップ６０２）。そのようにすることで、ハングオーバー・タイマは、ハードウェア・インターフェース及びソフトウェア・インターフェースによって悪いとしてクラス分けされたチャネルに適用されない。以下にさらに詳細に述べられるように、ハングオーバー・タイマが未知の、急に起こる（bursty）干渉を検出することを助けるように設計されているために、ハードウェア・インターフェース、ソフトウェア・インターフェース、又は、オプションとして、スレーブ・デバイスから受け取られたチャネル・クラス分け報告によって決定されるような既知の悪いチャネルに適用されない。

次に、ブルートゥース・デバイス１２によって使用されるチャネルは、チャネルのブロックへとグループ分けされる、そこではブロックの数は４であり得る。より詳しくは、この実施形態では、チャネルの各ブロック中のチャネルに関する複数のチャネル・メトリックは、合計され、そしてメトリック合計アレイ（ｍｅｔｒｉｃ＿ｓｕｍ＿ａｒｒａｙ［］）に記憶される（ステップ６０４）。そのようにして、最初の４つのチャネルに対するチャネル・メトリックの合計は、メトリック合計アレイ中の１番目の要素として記憶され、２番目の４つのチャネルに対するチャネル・メトリックの合計は、メトリック合計アレイ中の２番目の要素として記憶される、等。次に、各ブロックについて、メトリック合計は、ピーク値と比較される（ステップ６０６）。この時点で、ピーク値は、ブロックに対する前のピーク・メトリック値である。各ブロックについて、もし、メトリック合計がピーク値よりも大きければ、ピーク値は、メトリック合計に等しく設定される（ステップ６０８）。もしメトリック合計がピーク値よりも大きくなければ、予め決められた減衰値（decay value）がピーク値から減算される、それによってピーク値を減衰させる（ステップ６０８）。この明細書に関して、ピーク値は、メトリック合計ピーク・アレイ（ｍｅｔｒｉｃ＿ｓｕｍ＿ｐｅａｋ［］）中に記憶される。その後、ブロックは、ピーク値に基づいて最大の干渉を有するブロックから最小の干渉を有するブロックへと減少する順番で記憶される（ステップ６１０）。その結果、メトリック合計ピーク・アレイが記憶される。その上、インデックス・アレイ（ｉｎｄｅｘ＿ａｒｒａｙ［］）が、生成され、そこでは、インデックス・アレイの１番目の要素は、最悪のブロック（最大メトリック合計ピーク値を有するブロック）に対応するブロック番号であり、インデックス・アレイの２番目の要素は、次に悪いブロック（２番目に大きいメトリック合計ピーク値を有するブロック）に対応するブロック番号であり、等である。ブロックは、代わりに増加する順番で記憶されることができることに、注意すべきである。ブロックを記憶させることによって、最悪のブロックに関係するチャネルは、容易に取り消されることができる。同様に、干渉が時間にわたり減少しているかどうかをメトリック合計ピーク・アレイが確実にすることは、注意されるべきであり、最新の最悪ケースのピークが真の最悪ブロックを決定するように追跡される。例えば、メトリック合計値が大きいＷＬＡＮアクセス・ポイントの近くにブルートゥース・デバイス１２が移動し、そのうえメトリック合計値が小さくなるＷＬＡＮアクセス・ポイントから遠ざかるときに、これは重要である。チャネル・メトリックが決定されるときにＷＬＡＮはアクティブではないはずであるので、ピーク値は、追跡されようとしている各ブロックに対する最新の最悪ケースの干渉を容認する。

このプロセスの具体例の擬似コード表示は、次のように示される：

//ステージ２ａ：ハードウェア・インターフェース・チャネル及びソフトウェア・インターフェース・チャネルをゼロにする
//（ステップ６００及び６０２）
//ハードウェア・インターフェース（チャネル“０”はチャネルがないことを示す）

//ソフトウェア・インターフェース

//ステージ２ｂ：（チャネル・ブロック中で）最悪のブルートゥース・チャネルを見つける
//（ステップ６０４）

//ｍｅｔｒｉｃ＿ｓｕｍが新たなピークであるかどうかを調べるために調査する。もしそうであれば、値を記憶する。

//もし違うならば、減衰値だけ値を減らす。

//ステップ６０６及び６０８

//バブル・ソートを使用して要素をソートする−これは任意の種類のソート・ルーチンであり得る。

//最悪のブロックは、ＮＵＭ＿ＢＬＯＣＫＳ−１で終わり、
//２番目は//ＮＵＭ＿ＢＬＯＣＫ−２で、等々。

//ステップ６１０

ステージ３：干渉対時間
図４に示されたように、干渉波形検出ステージ４０４の後で、検出された干渉は、干渉対時間処理ステージ４０６に入力される。干渉対時間処理ステージ４０６は、時間のある期間にわたって検出された干渉を解析する。この処理ブロックは、チャネルの最悪ブロックから中心周波数のチャネルへと干渉の中心の推定値をさらに正確にし、そしてより正確な干渉推定値へと導く。これは、チャネルが貴重でありそして高度な処理能力で遮断される必要があるアプリケーションにおいて特に価値がある。

早いアタック−遅い減衰
時間のある期間にわたり検出された干渉を解析することは、干渉のデューティ周期が低く、そして干渉が急に生ずる複数の期間の間に測定されたメトリックの品質を高める。多くの“スタティックな”干渉物は、常にオンであるとは限らない。むしろ、多くのスタティックな干渉物は、トラフィックに基づいてパルス的にオンになったりオフになったりする。８０１．１１ネットワークでは、例えば、デバイスは、しばしばアイドルである。これは、特に干渉物がインターネットをサーフィングするために使用される場合、そのケースである。ユーザがウェブ・ページをクリックするとき、又はネットワークへ又はそこからファイルを移動させようと試みるときに、アクティビティのバーストが生じる。ネットワーク・トラフィックがそこにおいて急に増加するこれらのアプリケーションでは、チャネル評価プロセスが著しく遅延させないことは、重要である。したがって、１つの実施形態では、本発明の方法は、干渉物を迅速に固定し、そして干渉物が消え去った後でさえ、又は非常に低いデューティ周期に低下してしまった後でさえも、これらのチャネルを取り消す。チャネル評価アルゴリズムは、迅速に悪いチャネルを取り去り、そしてそれから干渉がチャネル上で最後に検出された後で時間のある期間のあいだチャネルを追跡する。これは、ここでは“早いアタック”及び“遅い減衰”と呼ばれる。この特徴は、それが必ずしも常にチャネル上に存在しないときでさえも、干渉全体の正確な像を維持する際に著しく手助けになる。

上記のように、データ解析エンジン３２がＡＦＨのためのチャネル・マップを与えるために使用されるとき、ＡＦＨを使用しているデバイスがまだ全スループットを得ることができるという理由で、チャネルを迅速に再使用することは特に重要ではない。しかしながら、デバイスがチャネル取り消しを使用するときには、干渉が検出されている時間の期間のあいだスループットが低下している。したがって、このケースでは、“悪い”チャネルをより早く使用することをレジュームすることが望まれる。しかしながら、８０２．１１バーストが生じるときはいつでも全てのチャネルが使用されていて、チャネルの再使用は、それ程早くないはずである。

一般に、チャネル・ブロックに対するメトリック合計が規定されたしきい値を超えるとき、チャネル・ブロックは、悪くなると決定され、そしてタイマは、選択されたハングオーバー値（ハングオーバー・スロット）を用いて始められる。１つの実施形態では、選択されたハングオーバー値は、ブルートゥース・タイムスロット（期間が６２５マイクロ秒）の数であり、それは前にクラス分けされた“悪い”チャネルが“良い”として再クラス分けされる（すなわち、再導入される）ことがある前に生じる必要がある。１つの実施形態では、タイマは、カウントダウン・タイマを備える。１つの実施形態では、タイマを割り出すために使用される各構成要素は、チャネル・ブロックに対応する。ハングオーバー値は、８０２．１１チャネルが取り消しにされる時間の長さを決定する。１つの実施形態では、ハングオーバー値は、設定可能である。しかしながら、８０２．１１チャネルが取り消しにされる時間の長さをこの値が決定するという理由で、この値がＡＦＨのあいだチャネル・マップを安定に保つために十分に大きいことが望まれる。しかしながら、ハングオーバー値は、同様に、チャネル取り消しのあいだ帯域幅を大きく保つように十分に小さくなる（すなわち、結果として十分に短い時間インターバルになる）はずである。

１つの具体例の実施形態では、“ハングオーバー”タイマは、チャネル上の低デューティ周期干渉物を検出する際に（例えば、インターネットを“サーフィング”するために使用される８０２．１１デバイスのような低デューティ周期干渉物を検出する際に）現在のチャネル評価方法及び装置の信頼性を向上させるために使用される。ハングオーバー・タイマは、チャネル・マップ中へと（良いチャネルとして）チャネルを再導入する前に、プロセスが待機するチャネル上で干渉を検出した後の時間の期間を決定する。言い換えると、ハングオーバー・タイマは、チャネルが再び“良い”（すなわち、使用のために使用可能である）と宣言されることを認められる前に、以前に得られたチャネル・メトリックがチャネルに対してどれだけ長く維持されるかを規定する。もし、十分な数のサンプルが前の測定期間のあいだに得られているのであれば、ハングオーバー・タイマは、チャネルの盲目的な再導入を防止するために少なくとも１つのチャネル・クラス分けインターバルだけ延長されるはずである。まだ終了していないいずれかのＡＦＨ又は取り消しハングオーバー・タイマは、延長される。

図７Ａは、ＡＦＨのためのチャネル・ブロックを評価する際に干渉対時間処理ステージ４０４（図４）の動作を説明する具体例のフローチャートである。最初に、ＡＦＨのために取り消されたブロックの総数に対応する値（ｂｌｏｃｋｓ＿ａｖｏｉｄｅｄ＿ＡＦＨ）及びブロック・インデックス値（ｂｌｏｃｋｓ）は、ゼロに初期化される（ステップ７００Ａ）。組み込まれたブルートゥース仕様書は、世界的な規制要求に順応するためにＡＦＨチャネル・マップに入るようになる少なくとも２０チャネルを必要とする。チャネルの総数が７９である場合に、ＡＦＨチャネル・マップ中で“悪い”として印を付けられることがあるチャネルの絶対的な最大数は、したがって５９である。そのように、もしチャネルが隣接するチャネルの４つのブロックにグループ分けされるのであれば、ＡＦＨのために取り消すチャネル・ブロックの絶対的な最大数は、１５である。ＡＦＨのために取り消されるチャネル・ブロックの最大数（ＭＡＸ＿ＡＦＨ）は、ＡＦＨのために取り消すチャネル・ブロックの絶対的な最大数よりも少ない、またはそれに等しい。

ステップ７０２Ａ−７１０Ａは、ＭＡＸ＿ＡＦＨの最悪のブロックに対して繰り返される、ここでＭＡＸ＿ＡＦＨは、ＡＦＨのために取り消すチャネル・ブロックの最大数である。より具体的に、最初の繰り返しに関して、もしインデックス値（ｂｌｏｃｋｓ）がＡＦＨ（ＭＡＸ＿ＡＦＨ）のために取り消す最大ブロック数よりも大きい又はそれに等しければ、プロセスは終了する（ステップ７０２Ａ）。もしインデックス値（ｂｌｏｃｋｓ）がＡＦＨ（ＭＡＸ＿ＡＦＨ）のために取り消す最大ブロック数よりも少なければ、最悪のチャネル・ブロックに対応するメトリック合計（ｍｅｔｒｉｃ ｓｕｍ［ＮＵＭ＿ＢＬＯＣＫＳ−ｂｌｏｃｋｓ−１］、ここで、ｂｌｏｃｋｓ＝０）は、メトリック合計しきい値と比較される（ステップ７０４Ａ）。もし、メトリック合計がメトリック合計しきい値よりも小さければ、ブロック・インデックス値は、増加され、そしてプロセスはステップ７０２Ａに戻る。もし、メトリック合計がメトリック合計しきい値よりも大きい又はそれに等しければ、現在取り消されているブロックの数は、ＡＦＨのために取り消すブロックの最大数と比較される（ステップ７０６Ａ）。もし、ＡＦＨのために取り消されたブロックの現在の数（ｂｌｏｃｋｓ＿ａｖｏｉｄｅｄ＿ＡＦＨ）がＡＦＨのために取り消すブロックの最大数（ＭＡＸ＿ＡＦＨ）よりも大きければ、ブロック・インデックス（ｂｌｏｃｋ）は、増加され、そしてプロセスは、ステップ７０２Ａに戻る、又はその代わりに終了する。もし、ＡＦＨのために現在取り消されたブロック数（ｂｌｏｃｋｓ＿ａｖｏｉｄｅｄ＿ＡＦＨ）がＡＦＨのために取り消すブロックの最大数（ＭＡＸ＿ＡＦＨ）よりも小さければ、ＡＦＨのために取り消されたブロック数（ｂｌｏｃｋｓ＿ａｖｏｉｄｅｄ＿ＡＦＨ）及びブロック・インデックス値（ｂｌｏｃｋｓ）は増加され（ステップ７０８Ａ）、最悪のブロックに対応するハングオーバー・タイマは、最大値に設定され（ステップ７１０Ａ）、そしてプロセスは、ステップ７０２Ａに戻る。ハングオーバー・タイマの最大値は、チャネルが“悪い”とクラス分けされた時間からそれが“良い”とクラス分けされることができるまでに終了する必要がある時間の所望の長さに対応する。ステップ７０２Ａ−７１０Ａは、ＭＡＸ＿ＡＦＨ最悪ブロック（ｍｅｔｒｉｃ＿ｓｕｍ［ＮＵＭ＿ＢＬＯＣＫＳ−ｂｌｏｃｋｓ−１］、ここでｂｌｏｃｋｓ＝０．．．ＭＡＸ＿ＡＦＨ−１である）に対して繰り返される。

本質において、図７Ａに示されたプロセスは、最悪のＭＡＸ＿ＡＦＨチャネル・ブロックのメトリック合計をメトリック合計しきい値と比較する。もし、メトリック合計がメトリック合計しきい値よりも大きい又はそれに等しければ、ＡＦＨのための対応するハングオーバー・タイマは増加される。もし、メトリック合計がメトリック合計しきい値よりも小さければ、メトリック合計は無視される。

図７Ｂは、チャネル取り消しのためにチャネル・ブロックを評価する際の干渉対時間ステージ４０４（図４）の動作を説明する具体例のフローチャートである。図７Ｂは、本質的に図７Ａと同じである。しかしながら、ステップ７０２Ｂにおいて、ブロック・インデックス値（ｂｌｏｃｋｓ）は、チャネル取り消しのために取り消すブロックの最大数（ＭＡＸ＿ＡＶＯＩＤ）と比較される。チャネル取り消しのケースでは、取り除かれる全てのチャネルが最大ブルートゥース・スループットを減少させるという理由で、より少ない数のチャネルが、遮断される。１つの実施形態では、チャネル取り消しアルゴリズムによって遮断されるブロックの最大数は、２４である。もし、各ブロックが４つのチャネルを含むのであれば、チャネル取り消しのために取り消される絶対的なブロックの最大数は、６である。チャネル取り消しのために取り消されるチャネルの最大数（ＭＡＸ＿ＡＶＯＩＤ）は、チャネル取り消しのために取り消される絶対的なブロックの最大数よりも少ない又はそれに等しい。

本質において、図７Ｂに示されたプロセスは、最悪のＭＡＸ＿ＡＶＯＩＤチャネル・ブロックのメトリック合計をメトリック合計しきい値と比較する、ここでＭＡＸ＿ＡＶＯＩＤは、チャネル取り消しのために取り消すブロックの最大数である。メトリック合計しきい値は、ＡＦＨ及びチャネル取り消しに対して同じであり得るし、同じでないこともあり得る。もし、メトリック合計がメトリック合計しきい値よりも大きい又はそれに等しければ、チャネル取り消しのための対応するハングオーバー・タイマは増加される。もし、メトリック合計がメトリック合計しきい値よりも小さければ、メトリック合計は無視される。

下記の擬似コードは、図７Ａ及び図７Ｂのプロセスの具体例の実行を示す。

//ステージ３ａ：各Ｎ個のチャネル・ブロックを検査し、そしてそれがしきい値を上回るかどうかを判断する。

//もしそうであれば、ハングオーバー・タイマを延長し、チャネルを悪いとして遮断する。

本発明の１つの実施形態では、干渉対時間ステージ４０６（図４）は、同様に、中心周波数を正確に識別するために最大メトリック合計ピーク値を有するチャネル・ブロックをフィルタする。干渉波形検出ステージ４０４の間に、中心周波数の推定値、そしてそれゆえ干渉の波形は、最大メトリック合計ピークを有するチャネル・ブロックの位置を決めることによって決定される。しかしながら、干渉対時間ステージ４０６は、干渉の中心周波数を正確に識別するために最大メトリック合計ピーク値を有するチャネル・ブロックをフィルタする。ブルートゥース・デバイスとＡＦＨをサポートしないデバイスとの共存が要求されるアプリケーションにおいて、この実施形態は、特に有用である。これらのアプリケーションでは、チャネル取り消し方式を利用するブルートゥース・デバイスは、チャネル・クラス分けアルゴリズムによって未使用と印を付けられたチャネルの低優先度情報を伝送することを止めるはずである。オーディオ・パケットのための人とのインターフェース・デバイス（例えば、マウス、キーボード、等）への伝送のような高優先度情報、又はピコネット安定性を維持するための高優先度情報は、８０２．１１伝送と衝突する可能性があるにも拘らず伝送される。干渉の中心周波数に対応するチャネルを計算することによってチャネル評価中心周波数（ＣＡ＿ｃｅｎｔｅｒ＿ｃｈａｎ）を正確に決定するためのフィルタの１つの可能性のある実行を示す擬似コードは、次のように示される：
//ステージ３ｂ：８０２．１１の中心ローブの中心を見つけるためにピークｍｅｔｒｉｃ＿ｓｕｍ＿ｐｅａｋ［］値をフィルタする。

//このフィルタは、損失の多い積分器を使用する。

//下記の“４”を掛け算することは各チャネル・ブロックが４ＭＨｚ幅であるという理由であることに注意する。

//
//ＣＡ＿ｃｅｎｔｅｒ＿ｃｈａｎのユニットは、ブルートゥース・チャネル数内（例えば、０と７８との間）である

ＡＬＰＨＡ及びＢＥＴＡは、損失の多い積分器に対して予め決められたパラメータであることを、注意すべきである。１つの実施形態では、ＡＬＰＨＡは８であり、そしてＢＥＴＡは１である。損失の多い積分器が干渉の中心周波数を計算する具体例の方法であることを、注意すべきである。別の技術が、この明細書を読むと当業者に明白になるであろう。

ステージ４：メトリックを統合すること
本発明の方法及び装置の最後のステップは、メトリックを統合するステップである。このステップは、メトリック・コンバイナ・ステージ４０８として図４に示されている。１つの実施形態では、このステップを最後に実行することは重要である。良いチャネルと悪いチャネルのソフトウェア・リスト及びハードウェア・リストがステップ４０２−４０６の前に加えられ場合、それは真の干渉像をマスクするはずであり、そして誤った結果に導くはずである。したがって、外部情報のこの組み合わせが、処理ステップの最後に実行されることは、重要である。

マスタ・デバイスのメトリック・コンバイナ・ステージ４０８の出力は、ＡＦＨのためのチャネル・マップ及び／又はチャネル取り消しのためのチャネル・マップである。スレーブ・デバイスでは、出力は、関係するマスタ・デバイスに伝達され、そしてチャネル・クラス分けのためにマスタ・デバイスによって使用されるチャネル・クラス分けパラメータ（遠隔メトリック）である。チャネル・クラス分けは、マスタ・デバイスに使用可能な情報の全てを評価することによって実現される。この情報は、次の１又はそれより多くを含む：ＡＦＨ及び／又はチャネル取り消しのためのチャネル・ブロックに対するハングオーバー・タイマ、ソフトウェア・インターフェース２２を介したホスト１６からのチャネル情報、１又はそれより多くのスレーブ・デバイスからのチャネル・クラス分けパラメータ、及びハードウェア・インターフェース１８を介した無線デバイス１４からのチャネル情報である。

ある複数の実施形態では、ホスト１６は、ブルートゥース・チャネルが“悪い”か“未知である”かどうかをブルートゥース・デバイス１２に通知する。１つの実施形態では、ホスト１６は、“未知の”状態に２０ブルートゥース・チャネルよりも少なく設定しないことができる。無線デバイス１４は、一緒に配置された８０２．１１デバイスであることができ、それは現在の８０２．１１チャネル番号を伝達する。悪いとして識別されるべきブルートゥース・チャネルの数は、８０１．１１チャネル番号に基づいてルックアップ・テーブルによって決定される。１つの具体例の実施形態では、スレーブ・デバイスは、ブルートゥース仕様書に記載されているＬＭＰ＿ｃｈａｎｎｅｌ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎパケット・データ・ユニット（ＰＤＵ：packet data unit）中のＡＦＨ＿Ｃｈａｎｎｅｌ＿Ｃｌａｓｓｉｆｉｃａｔｉｏｎパラメータを使用してマスタにチャネル・クラス分け結果を報告することができる。このＰＤＵにおいて、チャネルは、対でクラス分けされる（例えば、チャネル０と１は、一緒にクラス分けされ、チャネル２と３は、一緒にクラス分けされ、等々、チャネル７８まで（それは単独でクラス分けされる））。スレーブは、チャネルを“良い”、“悪い”又は“未知”としてクラス分けできる。

図８Ａは、ＡＦＨのためのメトリック・コンバイナ・ステージ４０８の動作を説明する。最初に、無線デバイス１４（図１）によって使用される８０２．１１チャネルに対応するブルートゥース・デバイス１２のチャネルは、“未使用”と印を付けられる（８００Ａ）。次に、ホスト１６からのチャネル情報中で“未使用”と分類されたチャネルは、“未使用”と印を付けられる（ステップ８０２Ａ）。ホスト１６及び無線デバイス１４がオプションのデバイスであるので、ステップ８００Ａ及び８０２Ａも同様にオプションであることに注意すべきである。次に、そのハングオーバー・タイマが終了していないチャネル・ブロックに関係するチャネルは、ＡＦＨのために“未使用”と印を付けられる（ステップ８０４Ａ））。最後に、マスタ・デバイスに報告している１又はそれより多くのスレーブ・デバイスがある場合に、スレーブ・チャネル・クラス分けにおいて悪いと印を付けられたチャネルは、“未使用”と印を付けられる（ステップ８０６Ａ）。

図８Ｂは、チャネル取り消しのためのメトリック・コンバイナ・ステージ４０８の動作を説明する。最初に、無線デバイス１４（図１）によって使用される８０２．１１チャネルに対応するブルートゥース・デバイス１２のチャネルは、“未使用”と印を付けられる（８００Ｂ）。次に、ホスト１６からのチャネル情報中で“未使用”と分類されたチャネルは、“未使用”と印を付けられる（ステップ８０２Ｂ）。ホスト１６及び無線デバイス１４がオプションのデバイスであるので、ステップ８００Ｂ及び８０２Ｂも同様にオプションであることに注意すべきである。次に、上で決められた干渉の中心周波数のプラス・マイナス予め決められた半値帯域幅（Ｎｂ）を超える周波数範囲内のチャネルは、ＡＦＨのために“未使用”と印を付けられる（ステップ８０４Ｂ））。それから、マスタ・デバイスに報告している１又はそれより多くのスレーブ・デバイスがある場合に、スレーブ・チャネル・クラス分けにおいて悪いと印を付けられたチャネルは、“未使用”と印を付けられる（ステップ８０６Ｂ）。オプションとして、より多くのチャネルが取り消されることができるのであれば、追加のチャネルが、図８Ａのステップ８０４Ａと同様の追加のステップにおいて“未使用”と印を付けられる。

下記の擬似コードは、図８Ａ及び図８Ｂのプロセスの具体例の実行を示す。下記の擬似コードに示されたように、マスタ・デバイス・チャネル・クラス分けプロセスは、７９チャネルにわたるループを含み、そしてローカル・クラス分け、ホスト・クラス分け、及びスレーブ・クラス分けから得られた結果を整理統合する。マスタ・デバイスは、少なくとも２０の使用済みチャネルを維持する。この具体例の実施形態では、２つの異なるチャネル・マップが作られる：ＡＦＨ＿ｃｈａｎｎｅｌ＿ｍａｐ［］及びａｖｏｉｄａｎｃｅ＿ｃｈａｎｎｅｌ＿ｍａｐ［］である。上記のように、ＡＦＨは、チャネル取り消し技術よりも数少ないブルートゥース・チャネルを使用することができ、その理由は、ＡＦＨがチャネルの数が減少しても帯域幅を失わないためである。

//ステージ４ａ：メトリック統合
//ＡＦＨ及び取り消しのために使用済みのチャネルの数を０に初期化する

//悪いと印を付けられたハードウェア及びソフトウェア・インターフェース・チャネルを遮断する

//使用する全てのチャネルをデフォルトにする

//もしチャネルがハードウェア・インターフェース又はホストによって悪いと印を付けられているのであれば、そのチャネルを未使用に設定する

//ローカル・メトリックはＡＦＨのためにクラス分けされる

//しきい値を超える各ブロックを悪いとしてチャネルに印を付ける

//ローカル・メトリックはＡｖｏｉｄａｎｃｅ（取り消し）のためにクラス分けされる

//ＣＡ＿ｃｅｎｔｅｒ＿ｃｈａｎ＋／−Ｎｂ内の各チャネルを悪いとしてチャネルに印を付ける

//最後に、もしデバイスがマスタであれば、ｕｎｕｓｅｄ＿ｃｏｕｎｔが大きくなり過ぎない限りスレーブ・メトリックはクラス分け結果の残りと統合される

１つの実施形態では、マスタ・デバイスに関して、チャネルのアレイ、すなわち、“ＡＦＨ＿ｃｈａｎｎｅｌ＿ｍａｐ［ｉ］”、は、Ｃｈａｎｎｅｌ＿Ｍａｐフォーマットへと変換される、それはブルートゥース仕様書に記載されている。スレーブ・デバイスに関して、チャネルのアレイＡＦＨ＿ｃｈａｎｎｅｌ＿ｍａｐ［ｉ］は、チャネル・クラス分け報告へと変換される。チャネル・クラス分け報告は、ＬＭＰ＿ｃｈａｎｎｅｌ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ ＰＤＵ中で伝送されることができる。マスタ及びスレーブの両者において、ａｖｏｉｄａｎｃｅ＿ｃｈａｎｎｅｌ＿ｍａｐ［］は、チャネル取り消しを実行する目的のためにだけ使用される。

スレーブ・チャネル・クラス分けを報告すること
１つの実施形態では、チャネル・クラス分けを報告することがイネーブルされるときに、スレーブ・デバイスは、メトリック・コンバイナ・ステージ４０８の結果をＬＭＰ＿ｃｈａｎｎｅｌ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ ＰＤＵのフォーマットでチャネル・クラス分け報告へと統合する、ここで、ＬＭＰ＿ｃｈａｎｎｅｌ＿ｃｌａｓｓｉｆｉｃａｔｉｏｎ ＰＤＵのフォーマットは、ブルートゥース仕様書中に記載されている。１つの実施形態では、チャネルは、チャネル対へと統合される。チャネル対中のいずれかのチャネルが“悪い”と識別されるとき、その対は、“悪い”と印を付けられる。チャネル対中のいずれかのチャネルが“良い”と識別されるとき、その対は、“良い”と識別される、（この問い合わせは、“悪い”チャネルに対する問い合わせの後で実行されるはずである）。それ以外は、チャネル対は、“未知”として識別される。

スレーブ・デバイスによるチャネル・クラス分けを報告することの１つの具体例の実行が、以下の擬似コードで示される：
//ステージ４ｂ：スレーブ・クラス分けを報告すること
//全ての４０チャネル対全体をループする

ハングオーバー・タイマ終了
１つの具体例の実施形態では、ハングオーバー・タイマ（Ｔ＿ｈａｎｇｏｖｅｒ＿ａｆｈ［ｉ］又はＴ＿ｈａｎｇｏｖｅｒ＿ａｖｏｉｄａｎｃｅ［ｉ］）が時間切れになるとき、関係するチャネル・ブロックのために現在取り消されているチャネルは、使用のために利用可能なチャネルのプールに戻される。ハングオーバー・タイマ終了が上に述べられたチャネル・クラス分けの間に様々なステージにおいて実行され得ることが、注目されるべきである。１つの実施形態では、ハングオーバー・タイマ終了は、いずれかの周波数ホップ干渉フィルタリング・ステージ４０２又は干渉波形検出ブロック４０４の前のプロセスの始めに実行される。しかしながら、代わりの実施形態では、ハングオーバー・タイマの終了は、メトリック・コンバイナ・ブロック４０８の後でチャネル・クラス分けの終わりに実行されることがある。

ハングオーバー・タイマ終了の１つの具体例の実施形態は、下記の擬似コードで与えられる：
//ハングオーバー・タイマ終了

本発明の複数の実施形態が、述べられてきている。それにも係らず、様々な変形が本発明の範囲から逸脱することなく行われ得ることが理解されるであろう。例えば、本発明の方法は、ソフトウェア又はハードウェアで、若しくはハードウェア実施形態とソフトウェア実施形態との組み合わせで実行されることができる。別の１つの例として、１つのモジュールの一部として述べられた機能が、一般に別の１つのモジュールにおいて同等に実行され得ることが理解されるはずである。さらに別の一例では、特定のシーケンスで示された又は説明されたステップ又は動作が、ステップに関して特定の順番を含んでいる請求項で記載されたそれらの実施形態を除いて、別の順番で一般に実行されることができる。

その上、本発明の複数の例が、ブルートゥース・デバイスの関係で説明されてきているが、本発明は、点対点接続及び点対多点接続を使用するいずれかのデバイスを与えるために使用されることができる。

本発明の好ましい実施形態に対する改善及び変形を当業者は理解するであろう。そのような改善及び変更の全てが、本明細書中に開示された概念の範囲内として、そして特許請求の範囲の範囲内として考えられる。

図１は、本発明のチャネル評価システムを含んでいるシステムのブロック図である。 図２は、本発明の１実施形態にしたがってチャネル評価システムのデータ収集エンジンの動作を説明するフローチャートである。 図３は、本発明を用いて実行する際に使用する具体例のチャネル評価フレームを図示する。 図４は、本発明のチャネル評価システムのデータ解析エンジンのさらに詳細なブロック図である。 図５は、本発明の１実施形態にしたがって図４のデータ解析エンジンの周波数ホップ干渉フィルタの動作を説明するフローチャートである。 図６は、本発明の１実施形態にしたがって図４のデータ解析エンジンの干渉波形検出ブロックの動作を説明するフローチャートである。 図７Ａは、本発明の１実施形態にしたがって図４のデータ解析エンジンの干渉対時間ブロックの動作を説明するフローチャートである。 図７Ｂは、本発明の１実施形態にしたがって図４のデータ解析エンジンの干渉対時間ブロックの動作を説明するフローチャートである。 図８Ａは、本発明の１実施形態にしたがって図４のデータ解析エンジンのメトリック・コンバイナの動作を説明するフローチャートである。 図８Ｂは、本発明の１実施形態にしたがって図４のデータ解析エンジンのメトリック・コンバイナの動作を説明するフローチャートである。

符号の説明

１０…システム，１２…ブルートゥース・デバイス，１４…無線デバイス，４００…マルチ・ステージ・データ解析及びチャネル・クラス分けプロセス。

Claims (47)

1. 無線通信システムにおいてチャネルを評価する方法、該方法は下記を具備する：
   ａ）該無線通信システム内の複数のチャネルの各々に対するチャネル・メトリックを得ること、ここにおいて、該複数のチャネル・メトリックは該複数のチャネルにおける干渉信号を表す情報を含む；
   ｂ）フィルタされたチャネル・メトリックを与えるために、周波数ホップ干渉に関係するメトリックを除去するために該チャネル・メトリックをフィルタすること；
   ｃ）該フィルタされたチャネル・メトリックに基づいて周波数スタティックな干渉の波形を決定するために
   ｉ）該複数のチャネルを複数のチャネル・ブロックへと分割すること、ここにおいて各チャネル・ブロックは少なくとも２つの隣接するチャネルを備える；及び
   ｉｉ）該複数のチャネル・ブロックの各々について、該少なくとも２つの隣接するチャネルの該複数のチャネル・メトリックを統合すること、それによって該複数のチャネル・ブロックの各々に対して統合されたメトリックを与える；及び
   ｄ）該統合されたメトリックに基づいて該複数のチャネルの各々をクラス分けすること、それによって使用可能なチャネル及び使用不可能なチャネルを識別する。
2. 請求項１の方法、ここにおいて、該周波数スタティックな干渉の該波形を決定するために、該方法は下記をさらに備える：
   該複数のチャネル・ブロックの該統合されたメトリックに基づいて最悪の干渉を有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すこと、ここにおいて、Ｎは使用不可能としてクラス分けされるべきチャネル・ブロックの予め決められた最大数である。
3. 請求項２の方法、ここにおいて、最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出すことは、下記を備える：
   該複数のチャネル・ブロックの各々について：
   該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較すること；
   該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定すること；及び
   該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために該メトリック合計ピークの該前の値を予め決められた値だけ減少させること；及び
   該メトリック合計ピーク値のうちの最大の複数のものを有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことによって該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出すこと。
4. 請求項２の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、下記を備える：
   予め決められた統合されたメトリックしきい値と該多数（Ｎ個）の該複数のチャネル・ブロックの各々に対する該統合されたメトリックとを比較すること。
5. 請求項４の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、該多数（Ｎ個）の該複数のチャネル・ブロックの各々について、該チャネル・ブロックに対する該統合されたメトリックが該予め決められた統合されたメトリックしきい値よりも大きい場合に、対応するハングオーバー・タイマを予め決められたハングオーバー値に設定することをさらに備える。
6. 請求項５の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、該複数のチャネル・ブロックの各々に対する該対応するハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けすることを備える。
7. 請求項６の方法、ここにおいて、該対応するハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けすることは、下記を備える：
   該対応するハングオーバー・タイマが終了していない場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用不可能としてクラス分けすること；及び
   該対応するハングオーバー・タイマが終了している場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用可能としてクラス分けすること。
8. 請求項７の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、該多数（Ｎ個）の該複数のチャネル・ブロック以外の該複数のチャネル・ブロックのうちの複数のものの中のチャネルを使用可能としてクラス分けすることをさらに備える。
9. 請求項１の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、１又はそれより多くの外部デバイスからの遠隔メトリックにさらに基づく。
10. 請求項１の方法、ここにおいて、該周波数スタティックな干渉の波形を決定するために、該方法は下記をさらに具備する：
    該複数のチャネル・ブロックに対する該統合されたメトリックに基づいて該周波数スタティックな干渉の中心周波数に対応する該複数のチャネル・ブロックのうちの１つを見出すこと；及び
    該複数のチャネル・ブロックの各々をクラス分けすることは下記を備える：
    該中心周波数に対応する該複数のチャネルのうちの１つを決定するために、該周波数スタティックな干渉の該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを処理すること；及び
    該中心周波数に対応する該複数のチャネルのうちの該１つ及び該中心周波数に対応する該複数のチャネルのうちの該１つについて予め決められた帯域幅内の多数の該複数のチャネルを使用不可能としてクラス分けすること。
11. 請求項１０の方法、ここにおいて、該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを見出すことは、下記を備える：
    該複数のチャネル・ブロックの各々について：
    該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較すること；
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定すること；及び
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために、該メトリック合計ピークの該前の値を予め決められた値だけ減少させること；及び
    該メトリック合計ピークの最大のものを有する該複数のチャネル・ブロックのうちの１つを見出すことによって該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを見出すこと。
12. 請求項１１の方法、ここにおいて、該周波数スタティックな干渉の該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを処理することは、該中心周波数に対応する該複数のチャネルのうちの該１つを決定するために、該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つをフィルタすることを備える。
13. 請求項１０の方法、ここにおいて、該予め決められた帯域幅は、２２ＭＨｚにほぼ等しい。
14. 請求項１の方法、ここにおいて、該複数のチャネルの各々に対する該チャネル・メトリックを得ることは、下記を備える：
    該複数のチャネルの各々に対する該チャネル・メトリックを初期化すること；
    該複数のチャネルの各々に対する該干渉を表すデータを収集すること；
    該複数のチャネルの各々について、一連のしきい値と該データとを比較すること；
    該複数のチャネルの各々について、該チャネル・メトリックを与えるために、該チャネル・メトリックの前の値と該チャネルについての該データが超える該一連のしきい値のうちの最大のものに対応する値とを統合すること；及び
    予め決められた数の繰り返しが実行されるまで、該収集すること、比較すること、及び統合することのステップを繰り返すこと。
15. 請求項１の方法、該方法は、該チャネル・メトリックを得ることの該ステップを定期的に開始することをさらに具備する。
16. 請求項１の方法、ここにおいて、該チャネル・メトリックを得ることは、予め決められたエラーしきい値を上回るパケット・エラー・レートを検出すると開始される。
17. 無線通信システム、該システムは下記を具備する：
    該無線通信システム内の複数のチャネルの各々に対するチャネル・メトリックを得ることに適応したデータ収集エンジン、ここにおいて、該チャネル・メトリックは該複数のチャネルにおける干渉信号を表す情報を含む；及び
    下記を実行することに適応したデータ解析エンジン：
    ａ）フィルタされたチャネル・メトリックを与えるために、周波数ホップ干渉に関係するメトリックを除去するために該チャネル・メトリックをフィルタする；
    ｂ）該複数のチャネルを複数のチャネル・ブロックへと分割する、ここにおいて各チャネル・ブロックは少なくとも２つの隣接するチャネルを備える；
    ｃ）該複数のチャネル・ブロックの各々について、該複数のチャネル・ブロックの各々に対して統合されたメトリックを与えるために該少なくとも２つの隣接するチャネルの該複数のチャネル・メトリックを統合する；及び
    ｄ）該統合されたメトリックに基づいて該複数のチャネルの各々をクラス分けする、それによって使用可能なチャネル及び使用不可能なチャネルを識別する。
18. 請求項１７のシステム、ここにおいて、該データ解析エンジンは、該複数のチャネル・ブロックの該統合されたメトリックに基づいて最悪の干渉を有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことにさらに適応する、ここにおいて、Ｎは使用不可能としてクラス分けされるべきチャネル・ブロックの予め決められた最大数である。
19. 請求項１８のシステム、ここにおいて、最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを決定するために、該データ解析エンジンは下記を実行することにさらに適応する：
    該複数のチャネル・ブロックの各々について：
    該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較する；
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定する；及び
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために該メトリック合計ピークの該前の値を予め決められた値だけ減少させる；及び
    該メトリック合計ピーク値のうちの最大の複数のものを有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことによって該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出す。
20. 請求項１８のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、予め決められた統合されたメトリックしきい値と該多数（Ｎ個）の該複数のチャネル・ブロックの各々に対する該統合されたメトリックとを比較することにさらに適応する。
21. 請求項２０のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、該多数（Ｎ個）の該複数のチャネル・ブロックの各々について、該チャネル・ブロックに対する該統合されたメトリックが該予め決められた統合されたメトリックしきい値よりも大きい場合に、対応するハングオーバー・タイマを予め決められたハングオーバー値に設定することにさらに適応する。
22. 請求項２１のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、該複数のチャネル・ブロックの各々に対する該対応するハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けすることにさらに適応する。
23. 請求項２２のシステム、ここにおいて、該対応するハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは下記を実行することにさらに適応する：
    該対応するハングオーバー・タイマが終了していない場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用不可能としてクラス分けする；及び
    該対応するハングオーバー・タイマが終了している場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用可能としてクラス分けする。
24. 請求項２３のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、該多数（Ｎ個）の該複数のチャネル・ブロック以外の該複数のチャネル・ブロックのうちの複数のものの中のチャネルを使用可能としてクラス分けすることにさらに適応する。
25. 請求項１７のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、１又はそれより多くの外部デバイスからの遠隔メトリックに基づいて該複数のチャネルの各々をクラス分けすることにさらに適応する。
26. 請求項１７のシステム、ここにおいて、該データ解析エンジンは、該複数のチャネル・ブロックに対する該統合されたメトリックに基づいて周波数スタティックな干渉の中心周波数に対応する該複数のチャネル・ブロックのうちの１つを見出すことにさらに適応する。
27. 請求項２６のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは下記を実行することにさらに適応する：
    該中心周波数に対応する該複数のチャネルのうちの１つを決定するために、該周波数スタティックな干渉の該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを処理する；及び
    該中心周波数に対応する該複数のチャネルのうちの該１つ及び該中心周波数に対応する該複数のチャネルのうちの該１つについての予め決められた帯域幅内の多数の該複数のチャネルを使用不可能なチャネルとしてクラス分けすること。
28. 請求項２７のシステム、ここにおいて、該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを見出すために、該データ解析エンジンは下記を実行することにさらに適応する：
    該複数のチャネル・ブロックの各々について：
    該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較する；
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定する；及び
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために該メトリック合計ピークの該前の値を予め決められた値だけ減少させる；及び
    該メトリック合計ピークのうちの最大のものを有する該複数のチャネル・ブロックのうちの１つを見出すことによって該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを見出す。
29. 請求項２８のシステム、ここにおいて、該データ解析エンジンは、該中心周波数に対応する該複数のチャネルのうちの該１つを決定するために、該複数のチャネル・ブロックのうちの該１つをフィルタすることによって該周波数スタティックな干渉の該中心周波数に対応する該複数のチャネル・ブロックのうちの該１つを処理することに適応する。
30. 請求項２７のシステム、ここにおいて、該予め決められた帯域幅は、２２ＭＨｚにほぼ等しい。
31. 請求項１７のシステム、ここにおいて、該複数のチャネルの各々に対する該チャネル・メトリックを得るために、該データ収集エンジンは、下記を実行することにさらに適応する：
    該複数のチャネルの各々に対する該チャネル・メトリックを初期化する；そして
    予め決められた数の繰り返しが実行されるまで繰り返して、該複数のチャネルの各々に対する該干渉を表すデータを収集し、該複数のチャネルの各々に対する一連のしきい値と該複数のチャネルの各々に対する該データとを比較し、そして、該複数のチャネルの各々について、該チャネル・メトリックを与えるために、該チャネル・メトリックの前の値と該チャネルについての該データが超える該一連のしきい値のうちの最大のものに対応する値とを統合する。
32. 請求項１７のシステム、ここにおいて、該データ収集エンジンは、該チャネル・メトリックを得るために定期的にトリガされる。
33. 請求項１７のシステム、ここにおいて、該データ収集エンジンは、予め決められたエラーしきい値を上回るパケット・エラー・レートを検出すると該チャネル・メトリックを得るためにトリガされる。
34. 無線通信システムにおいてチャネルを評価する方法、該方法は下記を具備する：
    ａ）該無線通信システム内の複数のチャネルの各々に対するチャネル・メトリックを得ること、ここにおいて、該チャネル・メトリックは該複数のチャネルにおける干渉信号を表す情報を含む；
    ｂ）該複数のチャネルに対する該チャネル・メトリックの少なくとも１つに基づいてハングオーバー・タイマを該複数のチャネルの各々に対して予め決められたハングオーバー値に設定するかどうかを決定すること；及び
    ｃ）該複数のチャネルの各々に対する該ハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けすること、それによって使用可能なチャネル及び使用不可能なチャネルを識別する、
    ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各に々対して該予め決められたハングオーバー値に設定するかどうかを決定することは、フィルタされたチャネル・メトリックを与えるために、周波数ホップ干渉に関係するメトリックを除去するために該チャネル・メトリックをフィルタすることを備える、
    ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定することは、該フィルタされたチャネル・メトリックに基づいて該周波数スタティックな干渉の波形を決定することをさらに備える、ここにおいて、該周波数スタティックな干渉の波形を決定することは、下記を備える：
    該複数のチャネルを複数のチャネル・ブロックへと分割すること、ここにおいて、各チャネル・ブロックは少なくとも２つの隣接するチャネルを備える；及び
    該複数のチャネル・ブロックの各々について、該少なくとも２つの隣接するチャネルの該複数のチャネル・メトリックを統合すること、それによって該複数のチャネル・ブロックの各々に対して統合されたメトリックを与える。
35. 請求項３４の方法、ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定することは、該複数のチャネル・ブロックに対する該統合されたメトリックさらに基づく。
36. 請求項３４の方法、ここにおいて、該周波数スタティックな干渉の該波形を決定することは、下記をさらに備える：
    該複数のチャネル・ブロックの該統合されたメトリックに基づいて最悪の干渉を有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すこと、ここにおいて、Ｎは使用不可能としてクラス分けされるべきチャネル・ブロックの予め決められた最大数である。
37. 請求項３６の方法、ここにおいて、該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出すことは、下記を備える：
    該複数のチャネル・ブロックの各々について：
    該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較すること；
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定すること；及び
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために該メトリック合計ピークの該前の値を予め決められた値だけ減少させること；及び
    該メトリック合計ピーク値のうちの最大の複数のものを有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことによって該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出すこと。
38. 請求項３６の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、下記を備える：
    予め決められた統合されたメトリックしきい値と該多数（Ｎ個）の該複数のチャネル・ブロックの各々に対する該統合されたメトリックとを比較すること。
39. 請求項３８の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、該多数（Ｎ個）の該複数のチャネル・ブロックの各々について、該チャネル・ブロックに対する該統合されたメトリックが該予め決められた統合されたメトリックしきい値よりも大きい場合に、該ハングオーバー・タイマを該予め決められたハングオーバー値に設定することをさらに備える。
40. 請求項３９の方法、ここにおいて、該複数のチャネルの各々をクラス分けすることは、下記をさらに備える：
    該対応するハングオーバー・タイマが終了していない場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用不可能としてクラス分けすること；及び
    該対応するハングオーバー・タイマが終了している場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用可能としてクラス分けすること。
41. 無線通信システムにおいてチャネルを評価するためのシステム、該システムは下記を具備する：
    ａ）該無線通信システム内の複数のチャネルの各々に対するチャネル・メトリックを得ることに適応したデータ収集エンジン、ここにおいて、該チャネル・メトリックは該複数のチャネルにおける干渉信号を表す情報を含む；及び
    ｂ）下記を実行することに適応したデータ解析エンジン：
    該複数のチャネルに対する該チャネル・メトリックの少なくとも１つに基づいてハングオーバー・タイマを該複数のチャネルの各々に対して予め決められたハングオーバー値に設定するかどうかを決定する；そして
    該複数のチャネルの各々に対する該ハングオーバー・タイマに基づいて該複数のチャネルの各々をクラス分けする、それによって使用可能なチャネル及び使用不可能なチャネルを識別する、
    ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定するために、該データ解析エンジンは、フィルタされたチャネル・メトリックを与えるために、周波数ホップ干渉に関係するメトリックを除去するために該チャネル・メトリックをフィルタすることにさらに適応する、
    ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定するために、該データ解析エンジンは、下記を実行することにさらに適応する：
    該複数のチャネルを複数のチャネル・ブロックへと分割する、ここにおいて、各チャネル・ブロックは少なくとも２つの隣接するチャネルを備える；そして
    該複数のチャネル・ブロックの各々について、該少なくとも２つの隣接するチャネルの該複数のチャネル・メトリックを統合する、それによって該複数のチャネル・ブロックの各々に対して統合されたメトリックを与える。
42. 請求項４１のシステム、ここにおいて、該データ解析エンジンは、該複数のチャネル・ブロックに対する該統合されたメトリックに基づいて該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定することにさらに適応する。
43. 請求項４１のシステム、ここにおいて、該ハングオーバー・タイマを該複数のチャネルの各々に対して該予め決められたハングオーバー値に設定するかどうかを決定するために、該データ解析エンジンは、該複数のチャネル・ブロックの該統合されたメトリックに基づいて最悪の干渉を有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことにさらに適応する、ここにおいて、Ｎは使用不可能としてクラス分けされるべきチャネル・ブロックの予め決められた最大数である。
44. 請求項４３のシステム、ここにおいて、該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出すために、該データ解析エンジンは、下記を実行することにさらに適応する：
    該複数のチャネル・ブロックの各々について：
    該チャネル・ブロックに対するメトリック合計ピークの前の値と該統合されたメトリックとを比較する；
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも大きい場合に、該メトリック合計ピークを該統合されたメトリックに等しく設定する；そして
    該統合されたメトリックが該メトリック合計ピークの該前の値よりも小さい場合に、該メトリック合計ピークを与えるために該メトリック合計ピークの該前の値を予め決められた値だけ減少させる；そして
    該メトリック合計ピーク値のうちの最大の複数のものを有する多数（Ｎ個）の該複数のチャネル・ブロックを見出すことによって該最悪の干渉を有する該多数（Ｎ個）の該複数のチャネル・ブロックを見出す。
45. 請求項４３のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、予め決められた統合されたメトリックしきい値と該多数（Ｎ個）の該複数のチャネル・ブロックの各々に対する該統合されたメトリックとを比較することにさらに適応する。
46. 請求項４５のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、該多数（Ｎ個）の該複数のチャネル・ブロックの各々について、該チャネル・ブロックに対する該統合されたメトリックが該予め決められた統合されたメトリックしきい値よりも大きい場合に、該ハングオーバー・タイマを該予め決められたハングオーバー値に設定することにさらに適応する。
47. 請求項４６のシステム、ここにおいて、該複数のチャネルの各々をクラス分けするために、該データ解析エンジンは、下記を実行することにさらに適応する：
    該対応するハングオーバー・タイマが終了していない場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用不可能としてクラス分けする；そして
    該対応するハングオーバー・タイマが終了している場合に、該多数（Ｎ個）の該複数のチャネル・ブロックの各々の中のチャネルを使用可能としてクラス分けする。

Images