(57)【特許請求の範囲】
【請求項１】
周波数ホッピング・ベースのアドホック・ネットワークにおいて、装置照会遅延を低減する方法であって、
装置により実行される活動を周期的に中断し、別の装置からの照会メッセージを所定時間走査するステップと、
前記別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを、特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するステップと、
前記所定時間の満了時に、中断していた前記装置により実行される前記活動を継続するように復帰するステップと
を含む、方法。
【請求項２】
走査のための前記所定時間が、前記装置による前記別の装置からの所定数の照会メッセージの受信により低減される、請求項１記載の方法。
【請求項３】
中断される前記活動が装置照会である、請求項１記載の方法。
【請求項４】
前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、請求項１記載の方法。
【請求項５】
中断される前記活動が装置照会である、請求項４記載の方法。
【請求項６】
前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、請求項４記載の方法。
【請求項７】
前記別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、請求項６記載の方法。
【請求項８】
周波数ホッピング・ベースのアドホック・ネットワークにおいて使用される装置であって、
前記装置により実行される活動を周期的に中断し、別の装置からの照会メッセージを所定時間走査する手段と、
前記別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理する手段と、
前記所定時間の満了時に、中断していた前記装置により実行される前記活動を継続するように復帰する手段と
を含む、装置。
【請求項９】
走査のための前記所定時間が、前記装置による前記別の装置からの所定数の照会メッセージの受信により低減される、請求項８記載の装置。
【請求項１０】
中断される前記活動が装置照会である、請求項８記載の装置。
【請求項１１】
前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、請求項８記載の装置。
【請求項１２】
中断される前記活動が装置照会である、請求項１１記載の装置。
【請求項１３】
前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、請求項１１記載の装置。
【請求項１４】
別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、請求項１３記載の装置。
【請求項１５】
周波数ホッピング・ベースのアドホック・ネットワークの装置のためのコンピュータ・プログラムを記録する、コンピュータ可読媒体を組み込むコンピュータ・プログラムであって、
前記装置により実行される走査活動を周期的に中断し、別の装置からの照会メッセージを所定時間走査するコンピュータ・プログラム・コード手段と、
前記別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを、特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するコンピュータ・プログラム・コード手段と、
前記所定時間の満了時に、中断していた前記装置により実行される前記活動を継続するように復帰するコンピュータ・プログラム・コード手段と
を含む、コンピュータ・プログラム。
【請求項１６】
走査のための前記所定時間が、前記装置による前記別の装置からの所定数の照会メッセージの受信により低減される、請求項１５記載のコンピュータ・プログラム。
【請求項１７】
中断される前記活動が装置照会である、請求項１５記載のコンピュータ・プログラム。
【請求項１８】
前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、請求項１５記載のコンピュータ・プログラム。
【請求項１９】
中断される前記活動が装置照会である、請求項１８記載のコンピュータ・プログラム。
【請求項２０】
前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、請求項１８記載のコンピュータ・プログラム。
【請求項２１】
前記別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、請求項２０記載のコンピュータ・プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ワイヤレス装置が通信するためのBluetooth（商標）デファクト・スタンダードに従い実現されるような、周波数ホッピング・ベースのアドホック・ネットワークに関する。特に本発明は、装置発見のプロセス、並びにこうしたプロセスにおける遅延の低減に関する。
【０００２】
【従来の技術】
最近ワイヤレス通信において、通信及びコンピュータ装置（ＰＣ、ページャ、モバイル電話など）が、柔軟な操作性及びモダリティを有するように、固定のまたは加入ベースのセルラ・ネットワークから解放されるアドホック・ネットワークへの傾向が見られる。
【０００３】
Bluetooth（商標）ウェブ・サイト（http:＼＼bluetooth.com）上で掲載されるこうした例は、"three-in-one"であり、これは家庭内でコードレス電話として機能し、屋外ではモバイル（セルラ）電話として機能し、また双方向携帯用無線電話機（walkie talkie device）としても機能する。これは形成される無線リンクのアドホック特性を表す。
【０００４】
以下ではBluetooth（商標）を重点的に扱うが、本発明は他の形態の周波数ホッピング・ベースのアドホック・ネットワークにも一般に適用される。
【０００５】
（前記のウェブサイトから）Bluetooth（商標）コア仕様書（ボリューム１、バージョン１．０Ｂ）を参照することができる。
【０００６】
Bluetooth（商標）技術は、ピコネットと呼ばれるネットワークの形成、及びこうしたネットワークの相互接続（スキャタネットと呼ばれる）を、中央インフラストラクチャの関与無しにアドホックに可能にする。これは照会及びページングのための分散アルゴリズムを用いて可能になる。本明細書において、用語"装置発見（device discovery）"は、照会プロシージャを用いて、近隣装置のBluetooth（商標）アドレス及びクロックを獲得するプロセスを指し示す。
【０００７】
Bluetooth（商標）物理層は、２．４ＧＨｚのＩＳＭ帯域に対するＦＣＣ規制に適合する周波数ホッピングを使用し、各ホップが１ＭＨｚを占有する７９ホップ・システムを使用する。これらの制限は、装置発見プロセスに関して意味を持つ。すなわち、１つは、装置が照会メッセージを走査するためにウェイク・アップするとき、装置は固定の専用の周波数でウェイク・アップすることができない。代わりに、ウェイク・アップ周波数は照会ホッピング・シーケンスにおいて、３２個の周波数のいずれかである。使用される実際の周波数は、走査装置のクロックに依存し、これは照会側にはわからない。更に、新たな装置を見い出す責任は、意図的に照会側に課せられるので走査装置は連続走査を行わない。従って、照会プロシージャにおいて、走査装置が聴取（listen）する時刻及び周波数は不確かである。
【０００８】
Bluetooth（商標）バージョン１．０仕様のベースバンド仕様は、照会及び照会走査を用いる装置発見プロシージャ（以下、ＢＴアルゴリズムと呼ぶ）を規定する。そこでは照会側は、その周辺の装置のアドレス及びクロックに関する情報を有さない。同時照会が存在しない場合、プロシージャはうまく機能する。しかしながら、複数の同時照会が存在する場合には、性能を予測することは困難である。
【０００９】
前記要因により、照会プロシージャは、照会を実施する装置にとって、時間及びエネルギを消費することになる。エラーフリーのすなわちエラーのない環境でも、照会装置が全ての応答を収集するために１０．２４秒を要する。これらの遅延は、個々の接続及びアドホック・ネットワークをセット・アップする上でボトルネックとなる。Bluetooth（商標）において想定される多くのアプリケーションの状況が、重複する領域で動作する非常に多数の端末を要求する。こうした状況の下では、平均遅延さえも増加し、これらのアプリケーションのための技術の利用を妨げる。従って、これらの遅延を低減することにより、こうしたアプリケーションを使用可能にする、装置発見アルゴリズムの変更が必要とされる。
【００１０】
照会の間の幾つかの装置の対話により、遅延分散または平均遅延であっても、見い出すことは容易ではない。これらの遅延は、照会プロシージャに参加する装置の数、照会装置の数、照会のために予約される帯域幅、及び照会から要求される応答の数などに依存する。
【００１１】
【発明が解決しようとする課題】
本発明の目的は、複数の同時照会を有するシステムにおいて、性能を維持しながら、従来技術よりも速い照会応答の交換を可能にする装置発見プロシージャを提供することである。
【００１２】
【課題を解決するための手段】
本発明の第１の態様によれば、周波数ホッピング・ベースのアドホック・ネットワークにおいて、装置発見遅延を低減する方法が提供される。この方法は、装置により実行される活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査するステップと、別の装置からの照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するステップと、前記所定時間の満了時に、前記活動を継続するように復帰するステップとを含む。
【００１３】
本発明の別の態様によれば、周波数ホッピング・ベースのアドホック・ネットワークにおいて使用される装置が提供される。この装置は、該装置により実行される活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査する手段と、別の装置からの照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理する手段と、前記所定時間の満了時に、前記活動を継続するように復帰する手段とを含む。
【００１４】
更に本発明の別の態様によれば、周波数ホッピング・ベースのアドホック・ネットワークの装置のためのコンピュータ・プログラムを記録する、コンピュータ可読媒体を組み込むコンピュータ・プログラム製品が提供される。このコンピュータ・プログラム製品は、前記装置により実行される走査活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査するコンピュータ・プログラム・コード手段と、別の装置からの照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するコンピュータ・プログラム・コード手段と、前記所定時間の満了時に、前記活動を継続するように復帰するコンピュータ・プログラム・コード手段とを含む。
【００１５】
本発明の実施例によれば、周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現され、中断される活動が装置発見の１つである。他の装置からの照会メッセージを走査するために、周期的な中断が好適には毎２．５６秒に少なくとも１度発生し、受信照会メッセージを処理する前に、中断された活動を継続するためのランダム時間枠が、好適には１．２８秒以下である。
【００１６】
【発明の実施の形態】
定義：
照会プロシージャ：他の装置を発見するために、ある装置により実行されるプロシージャ。
【００１７】
照会走査プロシージャ：自身が発見されるように、装置により実行されるプロシージャ。
【００１８】
装置発見プロシージャ：分散形式で実行される、前記２つのプロシージャの組み合わせ。
【００１９】
ＧＩＡＣ：汎用照会アクセス・コード（ＧＩＡＣ：General Inquiry Access Code）は、全ての装置に共通な照会アクセス・コードである。照会に応答したい全ての装置は、ＧＩＡＣを含むＩＤパケットに応答する。
【００２０】
ＤＩＡＣ：専用照会アクセス・コード（ＤＩＡＣ：Dedicated Inquiry Access Code）は、共通の特性を共有するBluetooth（商標）ユニットの専用グループに共通である。
【００２１】
照会ホッピング・シーケンス：７９ＭＨｚに渡り、期間長３２で分散される３２個の特定のウェイクアップ周波数。ＧＩＡＣはこのシーケンスを導出するために使用される。
【００２２】
照会応答ホッピング・シーケンス：現照会ホッピング・シーケンスと１対１に対応する、３２個の応答周波数。ＧＩＡＣはこのシーケンスを導出するために使用される。
【００２３】
照会遅延：装置が照会プロシージャを開始してから、次の２つの事象の早い方、すなわちMax_responses（最大受信応答数）または照会タイムアウトまでの経過時間。
【００２４】
装置発見遅延：装置が任意の他の装置を発見するための、アドホック環境における平均遅延。アドホック環境内の装置は、既にネットワークの一部であるかもしれないし、そうでないかもしれない。'ｎ'個の装置が存在する環境における装置発見遅延は、次式で与えられる。
【数１】
0003714618.tif 000002
【００２５】
ここで、ｄabは、装置'ａ'が装置'ｂ'を発見するための平均遅延である。
【００２６】
非常に多数の同一の装置を有する環境では、装置発見遅延及び照会遅延の両方が、１単位時間当たりに受信される応答数に関連付けられる。ここで'ｎ'個の装置のこうした環境において、時間Ｔ内にＮ個の応答が存在し、各装置が照会を行うのに費やす時間を'ｆ'とする。この時、常に平均ｎｆ個の照会装置が存在する。照会タイムアウトが発生しない場合、平均照会遅延は（Max_responses）ｘ（Ｔｎｆ／Ｎ）であり、平均装置発見遅延は（Ｔｎｆ／Ｎ）ｘ（ｎ／２）である。従って、１単位時間当たりの応答数（Ｎ／Ｔ）の増加は、平均遅延の低減を保証するのに十分と言える。
【００２７】
ピコネット：マスタと最大７個のアクティブ・スレーブとの間の、１ポイント対複数ポイント接続。これはBluetooth（商標）における基本ネットワーク単位である。ピコネット内の全ての装置は、マスタ装置のクロックから導出されるチャネル・ホッピング・シーケンスと呼ばれる、同一のホッピング・シーケンスを使用する。
【００２８】
スキャタネット：ブリッジ装置により、２つ以上のピコネットを接続することにより形成されるピコネットのネットワーク。各ピコネットは異なるホッピング・シーケンスを使用する。
【００２９】
照会プロシージャで使用されるパラメータ：
Ｔwinqscan＝照会走査ウィンドウ＝１８スロット（１スロット＝６２５マイクロ秒）
Ｔinqscan＝連続照会走査ウィンドウの開始間の時間＝２．５６秒
inquiryＴＯ＝最大照会期間
inqrespＴＯ＝ユニットが照会応答モードである最大時間
【００３０】
Bluetooth（商標）（ＢＴ）照会プロシージャ：
Bluetooth（商標）において、装置発見のために使用される照会プロシージャについて、図１に関連して簡単に述べることにする。
【００３１】
上部のタイムラインは照会装置を示す。３２個の照会ホップ周波数は、各々が１６個の周波数を有する２つのトレインに分割される。トレイン内の周波数は、照会者のクロックにより決定される。第１のトレイン内の１６個の周波数は、第２のトレインが開始する前に２５６回繰り返される。毎偶数スロットでは、２個の周波数が送信され、毎奇数スロットでは、これらの周波数で走査する装置からの応答が待機される。
【００３２】
図１の上部のタイムラインからわかるように、トレインＢはトレインＡと完全に相補的ではない。なぜなら、２つの周波数のオーバラップが存在するからである。すなわち、Ａトレイン内の周波数が０乃至１５と列挙される場合、Ｂトレイン内の周波数は、１８乃至３１、０乃至１と列挙される。従って、周波数０及び１がオーバラップする。オーバラップの理由は、後述のように２つの連続照会走査の間で、走査周波数が２つ変化するからである。
【００３３】
第２のタイムラインは、走査装置を示す。時間的な不確実性δ及び周波数Ｘが存在し、これらは照会者にはわからない。走査装置は２．５６秒毎に、１８スロットのウィンドウを走査する。走査の間の照会ホッピング・シーケンスの位相がＣＬＫＮ16-12により、すなわち走査装置の固有クロックのビット１２乃至１６により決定される。これは１．２８秒毎に変化し、走査は２．５６秒毎に発生するので、走査装置は、図１においてＸ、Ｘ＋２、Ｘ＋４及びＸ＋６により示されるように、ホッピング・シーケンスにおいて、別の周波数で走査を行う。
【００３４】
エラーが存在しない場合、走査装置は第２の照会走査ウィンドウが終了する時刻までに照会パケットを受信する。しかしながら、走査装置は応答をすぐ次のスロットで送信せずに、前の状態（スタンバイまたは接続）に戻り、最大１０２３スロットのランダム期間待機し、照会走査に戻り、同一の周波数で聴取（listen）する。照会パケットが再度受信されると、走査装置はそのアドレス及びクロック情報を含むＦＨＳパケット、従って、装置をページングするために必要な周波数ホッピング・シーケンス（ＦＨＳ：Frequency Hopping Sequence）を獲得する手段を送信する。このプロシージャでは、たとえ環境がエラーフリーで、ＦＨＳパケットの衝突が無視されても、発見遅延は依然１０．２４秒程度である。しかしながら、２つ以上の照会装置が存在する場合、遅延は更に大きくなり予測することが困難である。
【００３５】
任意の２つの装置の最大装置発見遅延は、１照会者が存在するエラーフリー環境では、１０．２４秒程度である。複数の照会者が存在する環境では、問題は次のように悪化する。
１）'照会'状態の装置が、照会遅延期間の間、他の装置による発見のために使用不能になる。その結果、全ての照会装置にとって平均照会遅延が増加する。
２）２つの装置がお互いを発見する機会を有する場合、両方の装置間の接続セットアップ遅延が低減される。装置の一方が照会に移行すると、他方の装置によるこの装置の発見は、長い時間不可能になる。
３）照会を同時に行う装置は、それらの'照会'状態がオーバラップする限り、お互いを発見することができない。このことは装置発見遅延を増加させる。
【００３６】
前記指摘から、ＢＴアルゴリズムは２つ以上の照会者が存在する場合、あまりうまく機能しないことが明らかである。しかしながら、改善には次の要因が考慮されるべきである。すなわち、
１）２．４ＧＨｚのＩＳＭ帯域での周波数ホッピングに適用されるＦＣＣ規制。
２）アイドル・モード（スタンバイ）での装置のオン・デューティ・サイクルが増加されるべきでない。このことは、照会走査ウィンドウが１８スロットを超えて増加すべきでないことを意味する。従って、仕様により規定されるように、照会ホッピング・シーケンスが２つのトレインに分割されるべきである。
３）周波数ホッピング・カーネル、並びに周波数ホッピング・カーネル内で異なる状態に対して使用される制御ワードが、好適には不変であるべきである。平均遅延を低減するために、最大遅延が特定のケースにおいて無制限になるべきでない。例えば、１照会者が存在するエラーフリー環境での最大装置発見遅延は、１０．２４秒を上回るべきでない。
【００３７】
前記制約１）及び２）を考慮すると、最悪の場合の遅延は、照会プロシージャそのものを大幅に変更することなしには、容易には改善することができない。装置発見アルゴリズムの変更により、平均遅延を改善する手段が提案され、これは状態の切り替えにより性能改善を達成する。装置発見アルゴリズムは、リンク・マネージャで実行される。
【００３８】
遅延の低減のためのアルゴリズム：
アルゴリズムの基本原理は次のようである。すなわち、
１）装置発見に参加している全ての装置は、装置が照会走査の間にどの状態にあるかに拘わらず、毎２．５６秒に少なくとも１度、照会走査を実行すべきである。
２）１）の結果、照会状態の装置は照会を中断しなければならないかもしれない。なぜなら、照会状態は一般に２．５６秒以上継続するからである。
【００３９】
前記２）の背景にある動機付けは、前記列挙した問題に対処することである。元来のＢＴアルゴリズムでは、照会装置が長い時間発見のために使用不能となる。僅かの時間だけ照会走査を実行することにより、装置は発見される機会を与えられる。毎２．５６秒に１８スロットの間、照会を周期的に中断する単純な方式でも十分のように思われるが、前記の要因にもとづく幾つかの問題点が存在する。特に、同期の場合には、際限のない遅延が引き起こされるかもしれない。後述のように、１．２８秒の周期内にランダムな照会走査を実行する装置は、５．１２秒以内に１照会者から照会メッセージを受信することが保証される。
【００４０】
改善されたアルゴリズムのインプリメンテーションは、照会装置の変更を要求するだけである。すなわち、照会装置の発見遅延を低減するために、照会装置が通信する任意の他の装置に関連する変更は不要である。
【００４１】
このアルゴリズムについて考えると、装置発見に参加し、'照会'以外の状態にある全ての装置は、毎Ｔinqscan時間ごとにＴwinqscan時間枠、周期的に照会走査に移行する。
【００４２】
アルゴリズムの説明において、装置の固有クロックの現在値（スロット数により表現される）がNOWにより示され、unif（ａ、ｂ）は、インターバル［ａ、ｂ］内に均一に分散された整数を表す。変数'State'は、装置の現状態を表す。inquiryTOはスロットで規定される。SlotTimeはスロットの期間である。
【００４３】
照会を開始するコマンドは、Max_Responsesパラメータと共に、ホスト・コントローラ・インタフェース（ＨＣＩ）から到来する。提案されるアルゴリズムは、コマンドの受信時に開始する。すなわち、
１）HCI_inquiryコマンドの受信。
prev_state＝State
照会タイムアウト・タイマ（Ｔinq）を（NOW＋inquiryTO）にセット。
タイマＴ１を（NOW＋１．２８／SlotTime）にセット。
２）State＝照会走査に割当て。
ケース１：装置が１８スロット内に照会メッセージを受信。
３ａ）（まだスタートされていない場合、）照会応答タイマをタイムアウト＝inqrespTOにてスタートし、最大１０２３スロットまでランダム・バックオフを実行。バックオフの間、照会状態に移行。バックオフの後、Bluetooth（商標）ベースバンド仕様に記載の照会応答プロシージャに則する。照会応答タイマがタイムアウト後、State＝照会にセット。
ケース２：装置が１８スロット内に照会メッセージを受信しない。
３ｂ）State＝照会に割り当て。
【００４４】
Ｔ１のタイマ・ハンドラ（タイマＴ１がオフするときに呼び出される）。
i）タイマＴ１を再度（NOW＋１．２８／SlotTime）にオフするようにセット。
ii）照会応答プロシージャが現在実行されていない場合、タイマＴ２を（NOW＋unif（０、（（１．２８／SlotTime）−１８））にオフするようにセットし、アルゴリズムのステップ３ｂに移行。
タイマＴ２がオフするとき、装置は照会状態から抜け出す。照会応答プロシージャが現在実行されている場合、タイマＴ２はスケジュールされないが、タイマＴ１は１．２８秒後にオフするように、自己スケジュールする。
【００４５】
Ｔ２のタイマ・ハンドラ（タイマＴ２がオフするとき呼び出される）。
i）ステップ２に移行
タイマＴ２はタイマＴ１によりスケジュールされる。タイマＴ１は１．２８秒毎に自己スケジュールするので、タイマＴ２のハンドラの呼び出しが保証される。
【００４６】
Ｔinqのタイマ・ハンドラ（Ｔinqがオフするとき呼び出される）。
i）State＝prev_state
ii）アルゴリズムの終了。
【００４７】
前記ケース２のアルゴリズムが、図２に示される。スロットタイムは６２５マイクロ秒に設定される。HCI_inquiryコマンドの受信時に、装置は即時に照会状態には移行せず、１８スロットの間、照会走査状態に移行する。また、Δ＝１．２８秒後にタイマＴ１をオフするようにセットする。この期間中に装置に対する照会メッセージが受信されない場合、装置は照会状態に移行し、タイマＴ１がオフするまでその状態に留まる。装置は次に、０と（２０４７−１８）との間に均一に分散されるランダム整数'rand'を選択し、タイマＴ２を'rand'スロット後にオフするようにセットする。ここで、２０４７スロットは１．２８秒に対応し、１８スロットは１１．２５ミリ秒の照会走査ウィンドウに対応する。Ｔ２がオフするとき、状態は再度１８スロットの間、照会走査にセットされる。タイマＴ１は１．２８秒毎にオフする。
【００４８】
図３乃至図９は、本発明のアルゴリズムの実施例を使用するアドホック・システムを、仕様記述言語（ＳＤＬ：Specification and Description Language）にもとづきグラフィック表現で示すものである。図３乃至図９は完全な仕様を表すものではなく、単にアルゴリズムを説明することを目的とする。特に、ワイヤレス伝送媒体を表す中間（Medium）ブロック３０２のモデル化、及び照会メッセージ信号（ＩＮＱ）の生成は、示されていない。
【００４９】
図３は、システム・レベル・エージェント、アドホック・システムを示す。
【００５０】
図４は、システム・レベル・エージェント、アドホック・システムの信号及び信号リストの定義を示す。
【００５１】
図５は、Bluetooth（商標）装置をモデル化するＢＴ装置（BT_device）３０１、及びワイヤレス伝送媒体をモデル化する中間ブロック３０２を含むシステム・ブロックを示す。
【００５２】
図６は、BT_devプロセス３０５を含むＢＴ装置ブロック３０１の構造を示す。
【００５３】
図７乃至図９は、本発明のアルゴリズムの実施例であるBT_devプロセス３０５を示す。陰影付き背景のステートメントは、標準ＢＴアルゴリズムに対する変更を示す。BT_devプロセス３０５はメイン・ルーチンと、多数のタイマ・ハンドラ・ルーチンとを含む。
【００５４】
メイン・ルーチン：
図７乃至図９を参照すると、システムは、ステップ３１２でHCI_inquiryコマンドがホスト・コントローラ・インタフェースから受信されるまで、スタンバイ接続モードに留まる（ステップ３１０）。
【００５５】
ステップ３１４では、装置の現状態が記憶され、照会応答タイマ（inq_RespTO_timer）がリセットされ、照会タイムアウト・タイマ（inqTO_timer）が最大照会期間（inquiryTO）に従い初期化され、タイマＴ１が、提案されるランダム照会走査インターバルに相当する１．２８秒に初期化される。照会走査開始時刻が記憶され、照会走査タイマ（t3_timer）が、照会走査期間を表す１８スロットにセットされる。照会タイムアウト・タイマ（inqTO_timer）は照会プロシージャにおいて使用され、照会応答タイマ（inq_RespTO_timer）は照会応答プロシージャにおいて使用される。提案されるアルゴリズムは、照会装置がこれら２つのプロシージャ間をトグルすることを要求するので、２つのタイマは同時に走行できる。
【００５６】
次にステップ３１６で、装置は照会走査モードにセットされる。
【００５７】
ステップ３１８及び真下の３角状括弧内の条件は、遷移のための制約トリガをＳＤＬで表す。従って、装置が照会走査を実行しており（ステップ３１６）、照会メッセージが１８スロット内に受信される場合、処理はステップ３２０に進む。
【００５８】
ステップ３１９で、照会走査タイマ（t3_timer）がリセットされる。
【００５９】
バックオフ・フラグの状態がステップ３２０で判断される。バックオフ・フラグが偽の場合、０乃至１０２３の範囲のランダム変数がステップ３２２で生成される。
【００６０】
ステップ３２４では、バックオフ・タイマ（backoff_timer）が、ステップ３２２で生成されたランダム変数に従いバックオフ期間を計時するように初期化され、バックオフ・フラグが真にセットされる。更に、照会応答タイマ（inq_RespTO_timer）がまだセットされていない場合には、このタイマが、照会応答を受信するための最大期間（inqRespTimeout）を計時するように初期化される。
【００６１】
次にステップ３２６で、装置は照会モードにセットされる。
【００６２】
ステップ３２０で、バックオフ・フラグが真の場合、装置はステップ３２８で、そのアドレス及びクロック情報を含むＦＨＳパケットを送信する。
【００６３】
次にステップ３３０で、０乃至１０２３の範囲のランダム変数が生成される。
【００６４】
次にステップ３３２で、ステップ３３０で生成されたランダム値に従い、バックオフ・タイマ（backoff_timer）が初期化され、バックオフ・フラグが偽にクリアされる。
【００６５】
装置はステップ３３４で照会モードにセットされる。
【００６６】
タイマ・ハンドラ・ルーチンＴ１、ステップ３４０乃至３４９は、１．２８秒毎に満了するタイマＴ１のハンドラ・ルーチンを表す。タイマ・ハンドラはタイマＴ１の満了時に、ステップ３４０で呼び出される。
【００６７】
ステップ３４２で、タイマＴ１が１．２８秒に再初期化される。この値は、提案されるランダム照会走査のインターバルに相当する。
【００６８】
判定ステップ３４４で、バックオフ・フラグが偽の場合、０乃至（２０４７−１８）の間のランダム値が生成される。この値はステップ３４８でタイマＴ２を初期化するために使用される。ここで２０４７スロットは、照会走査ウィンドウの１１．２５ミリ秒に対応する。
【００６９】
ステップ３４９で、装置は照会モードにセットされる。
【００７０】
判定ステップ３４４で、バックオフ・フラグが真の場合には、ステップ３４６乃至ステップ３４９を実行することなく、Ｔ１タイマ・ハンドラ・ルーチンがステップ３４５で直接終了される。
【００７１】
Ｔ２タイマ・ハンドラ・ルーチン：
ステップ３５０乃至３５４は、タイマＴ２のタイマ・ハンドラ・ルーチンを表す。このルーチンはタイマＴ２が満了するとき、ステップ３５０で呼び出される。
【００７２】
次にステップ３５２で、照会走査開始時刻が記憶され、照会走査タイマ（t3_timer）が、照会走査期間を表す１８スロットにセットされる。
【００７３】
ステップ３５４で、装置が照会走査モードにセットされ、これは１８タイム・スロットの間、継続する。
【００７４】
バックオフ・タイマ・ハンドラ・ルーチン：
ステップ３６０乃至３６４は、バックオフ・タイマのタイマ・ハンドラ・ルーチンを表す。ルーチンは、バックオフ・タイマが満了するとき、ステップ３６０で呼び出される。
【００７５】
次にステップ３６２で、照会走査開始時刻が記憶され、照会走査タイマ（t3_timer）が、照会走査期間を表す１８スロットにセットされる。
【００７６】
ステップ３６４で、装置が照会走査モードにセットされる。
【００７７】
照会タイマ・ハンドラ・ルーチン：
ステップ３７０乃至３７４は、照会Ｔ０タイマのタイマ・ハンドラ・ルーチンを表す。このタイマ・ハンドラ・ルーチンは、照会タイマＴ０が満了するとき、ステップ３７０で呼び出される。
【００７８】
次にステップ３７２で、バックオフ・タイマ、照会応答Ｔ０タイマ、及びＴ１及びＴ２タイマがリセットされる。また、バックオフ・フラグも偽にクリアされる。
【００７９】
ステップ３７４で、処理が前の状態（ステップ３１４で記憶された状態）に戻る。
【００８０】
照会応答タイマ・ハンドラ・ルーチン：
ステップ３８０乃至３８４は、照会応答タイマＴ０のタイマ・ハンドラ・ルーチンを表す。このタイマ・ハンドラ・ルーチンは、照会応答タイマが満了するとき、ステップ３８０で呼び出される。
【００８１】
次にステップ３８２で、バックオフ・フラグが偽にクリアされる。
【００８２】
装置がステップ３８４で照会モードにセットされる。
【００８３】
照会走査タイマ・ハンドラ・ルーチン：
ステップ３８６乃至３８８は、照会走査タイマ（t3_timer）のタイマ・ハンドラ・ルーチンを表す。このタイマ・ハンドラ・ルーチンは、照会走査タイマが満了するとき、ステップ３８６で呼び出される。
【００８４】
装置が照会走査を実行しているときに、タイマが満了すると、装置はステップ３８８で照会モードにセットされる。
【００８５】
比較例：
次に、本発明のアルゴリズムと、従来のBluetooth（商標）アルゴリズムとの比較を示す。この例では、以下のものが存在する。すなわち、
装置の数：２乃至１４
最大応答（Max_responses）：１乃至１２
照会タイムアウト：１０．２４秒
照会応答タイムアウト：１秒
照会のために確保される帯域幅：１０％（装置が照会状態において費やす総時間の割合）
シミュレーション時間：１０乃至５０秒
【００８６】
仮定：
１）パケットのエラーフリー受信。
２）無視できる伝播遅延。
３）装置発見に参加する装置が毎２．５６秒に少なくとも１度、照会走査を行う。しかしながら、ＢＴアルゴリズムでは、照会状態が照会走査のために中断されない。
４）考慮される全ての装置が、お互いの有効範囲内にある。
５）全ての装置が照会を行うために、１０％の帯域幅を確保する。
【００８７】
性能メトリック：
１）装置の数が変化する状況での１単位時間当たりの有効応答数。装置は照会メッセージに何度も応答できるので、最初の（有効）応答だけがカウントされる。
２）照会遅延が、照会プロシージャが継続する平均時間である。照会タイムアウトが１０．２４秒に指定されるので、これがこの遅延の上限となる。
３）Max_responsesの数の応答が１０．２４秒以内に受信されないと、照会タイムアウトが発生する。
【００８８】
図１０、図１１及び図１２は、テスト時間がそれぞれ５０秒、３０秒、及び１０秒の場合の、'有効応答数'対'装置数'の関係（５０テスト・サイクルに渡る平均）を示す。
【００８９】
図１３は、タイムアウト回数及び照会遅延の両者を、最大応答の関数として示す（３４回の観測の平均）。但し、テスト時間は５０秒である。
【００９０】
結果は、提案されるアルゴリズムが同一の状況での有効応答の比率を、最大６０％増加することを示している。所与のMax_responsesの数において、照会遅延及びタイムアウト回数が５０％低減されることがわかる。従って、提案されるアルゴリズムは複雑さを増すことなく、装置発見遅延を改善する。全てのタイプのホッピング・シーケンスにおいて、周波数ホッピング・カーネルへの入力は不変である。このアルゴリズムはBluetooth（商標）ベースのシステムの事前接続オーバヘッドを低減し、より広い帯域幅を通信のために使用可能にする。
【００９１】
ランダム照会走査による装置発見のための必要条件：
次のセクションでは、照会メッセージが５．１２秒以内に受信されなければならない場合、照会走査のランダム化アルゴリズムが、最大でも１．２８秒の周期Ｐを有するべきことを示す。
【００９２】
図１４の時間対周波数の関係は、照会者が時刻＝５．１２秒まで送信する間の周波数を示す。走査周波数は１．２８秒毎に変化し（ＣＬＫＮ16-12が１．２８秒毎に変化する）、交互の遷移が照会装置のトレイン切り替えと同期するものと仮定する。図示のように、走査の周期Ｐは１．２８秒よりも大きい。時間は１６スロットのインターバルで離散化される。図示のインパルスは、周期Ｐ内の走査ウィンドウの位置を示す。図から、Ｐ＞１．２８秒であるこの特定のケースでは、装置が５．１２秒以上の間、お互いを発見しないことが明らかである。
【００９３】
従って、前述のランダム化アルゴリズムにおいて、５．１２秒以内に装置を突き止めるための必要条件は、Ｐ≦１．２８秒である。しかしながら、前述の例では、ＣＬＫＮ12刻時が照会者のトレイン切り替えと同期すると仮定した。以下では、この仮定が緩和され、任意の開始走査周波数において、５．１２秒以内の発見を保証するのに、Ｐ＝１．２８秒で十分であることが証明される。
【００９４】
図９は最も一般的なケースを示す。一般性を失うことなく、照会を行う装置は時刻ｔ＝０で開始し、最初のＡトレイン内の周波数は、０乃至１５と番号付けされる。別の装置は時刻ΔISに周期Ｐで、ランダム照会走査を開始する。ｔ＝０の後のこの装置の最初のＣＬＫＮ12刻時が、Δ12で発生する。
【００９５】
δ＝ΔIS−Δ12と表すと、全ての開始周波数ｆ0及び全てのδにおいて、走査装置はΔIS＋５．１２秒以内に発見される。
【００９６】
最初の４つの照会走査ｉ＝０、１、２、３が開始する瞬間は、次式で与えられる。
【数２】
Ｓi＝ΔIS＋ｉΔ＋ｔi  （Ａ１）
【００９７】
ここで、Δは１．２８秒で、ｔiはＰ＝Δウィンドウ内のランダム時刻、すなわちｔiのインターバルは［０、１．２８］秒である。任意の時刻ｔにおける走査周波数ｆIS（ｔ）は、次式で与えられる。
【数３】
0003714618.tif 000003
【００９８】
従って、走査が実際に発生する時刻Ｓi（ｉ＝０、１、２、３）における走査周波数ＦiISは、次式で与えられる。
【数４】
0003714618.tif 000004
【００９９】
照会トレインの開始周波数は、２．５６秒毎に変化し、次式で与えられる。
【数５】
Ｆinq（ｔ）＝２ｋ＋１６（ｋ mod ２）                      （Ａ４）
【０１００】
ここで、ｋは次のように示される。
【数６】
0003714618.tif 000005
【０１０１】
前記式でのｔ＝Ｓiの置換は、照会走査が開始する瞬間における開始照会者周波数Ｆiinq（ｉ＝０、１、２、３）を生成する。すなわち、
【数７】
Ｆ0inq＝０、ΔIS＋ｔ0＜２Δ、Ｆ0inq＝１８、ΔIS＋ｔ0＞２Δ（Ａ５．１）
Ｆ1inq＝０、ΔIS＋ｔ1＜Δ、Ｆ1inq＝１８、ΔIS＋ｔ1＞Δ    （Ａ５．２）
Ｆ2inq＝１８、ΔIS＋ｔ2＜２Δ、Ｆ2inq＝４、ΔIS＋ｔ2＞Δ  （Ａ５．３）
Ｆ3inq＝１８、ΔIS＋ｔ3＜Δ、Ｆ3inq＝４、ΔIS＋ｔ3＞Δ    （Ａ５．４）
【０１０２】
トレインは周波数Ｆiinq乃至（Ｆiinq＋１５）mod３２を含む。ＦiISがこの範囲内にあれば、走査装置は瞬間Ｓiに開始する走査の間に発見される。ここで前記式（Ａ３）及び（Ａ５）を用いることにより、ｆ0の全ての可能な値に対してＦiISがｉ＝０、１、２、３の少なくとも１つの値において、前記範囲内にあることを示すことにする。
【０１０３】
定義により、Ｐｒ（ｉ番目の走査での発見）＝ｐiである。
【０１０４】
ケース１：１≦ｆ0≦１４
式（Ａ３）から、ｉ＝０において、ＦiIS＝ｆ0またはｆ0＋１である。従って、この場合、０≦Ｆ0IS≦１５となる。もしΔIS＜Δならば、ΔIS＋ｔ0＜２Δなので、式（Ａ５．１）から、Ｆ0inq＝０及び（Ｆ0inq＋１５）＝１５である。Ｆ0ISはこの範囲内に入るので、ｐ0＝１である。
【０１０５】
式（Ａ３）から、ｉ＝３において、ＦiIS＝ｆ0＋３またはｆ0＋４である。従って、この場合、４≦Ｆ3IS≦１８となる。もしΔIS＞Δならば、ΔIS＋ｔ3＞Δなので、式（Ａ５．４）から、Ｆ3inq＝４及び（Ｆ3inq＋１５）＝１９である。Ｆ3ISはこの範囲内に入るので、ｐ3＝１である。
【０１０６】
ケース２：１７≦ｆ0≦３０
式（Ａ３）から、ｉ＝２において、ＦiIS＝ｆ0＋２またはｆ0＋３である。この場合、範囲Ｆ2ISは１９乃至３１、０乃至１である。もしΔIS＜Δならば、ΔIS＋ｔ2＜２Δなので、式（Ａ５．３）から、Ｆ2inq＝１８及び(Ｆ2inq＋１５)mod３２＝１である。Ｆ2ISはこの範囲内に入るので、ｐ2＝１である。
【０１０７】
式（Ａ３）から、ｉ＝１において、ＦiIS＝ｆ0＋１またはｆ0＋２である。この場合、範囲Ｆ1ISは１８乃至３１、及び０である。もしΔIS＞Δならば、ΔIS＋ｔ1＞Δなので、式（Ａ５．４）から、Ｆ1inq＝１８及び(Ｆ1inq＋１５)mod３２＝１である。Ｆ1ISはこの範囲内に入るので、ｐ3＝１である。
【０１０８】
ケース３：ｆ0＝０、３１、１６、１５
ｆ0＝０では、ｆ0及びｆ0＋１が、最初のＡトレインと最初のＢトレインとの間のオーバラップ周波数であり、従って、ｐ0＝１である。
【０１０９】
ｆ0＝３１では、（ｆ0＋１）mod３２及び（ｆ0＋２）mod３２が、最初のＡトレインと最初のＢトレインとの間のオーバラップ周波数であり、従って、ｐ1＝１である。
【０１１０】
ｆ0＝１６では、ｆ0＋２及びｆ0＋３が、最初のＢトレインと第２のＡトレインとの間のオーバラップ周波数であり、従って、ｐ2＝１である。
【０１１１】
実施：
図１６は、典型的なBluetooth（商標）装置１０３０のブロック図であり、下位ソフトウェア層を示す。ホスト・コントロール・インタフェース（ＨＣＩ）ファームウェア１０４０が、Bluetooth（商標）ホスト１０１０から、物理バス・ハードウェア及びファームウェア１０２０を介して、Bluetooth（商標）ベースバンド機能をアクセスする手段を提供する。本発明のアルゴリズムは、リンク・マネージャ・ファームウェア１０５０内で実現される。ホスト・コントローラ・インタフェース・ファームウェア１０４０は、本発明の実現のために変更を必要としない。
【０１１２】
以上、本発明の幾つかの構成及び実施例について述べてきたが、当業者であれば、本発明の趣旨及び範囲から逸れることなく、様々な変更及び変形が可能であることが理解できよう。
【０１１３】
まとめとして、本発明の構成に関して以下の事項を開示する。
【０１１４】
（１）周波数ホッピング・ベースのアドホック・ネットワークにおいて、装置発見遅延を低減する方法であって、
装置により実行される活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査するステップと、
別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを、特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するステップと、
前記所定時間の満了時に、前記活動を継続するように復帰するステップと
を含む、方法。
（２）走査のための前記所定時間が、前記装置による他の装置からの所定数の照会メッセージの受信により低減される、前記（１）記載の方法。
（３）中断される前記活動が装置発見の１つである、前記（１）記載の方法。
（４）前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、前記（１）記載の方法。
（５）中断される前記活動が装置発見の１つである、前記（４）記載の方法。
（６）前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、前記（４）記載の方法。
（７）別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、前記（６）記載の方法。
（８）周波数ホッピング・ベースのアドホック・ネットワークにおいて使用される装置であって、
前記装置により実行される活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査する手段と、
別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理する手段と、
前記所定時間の満了時に、前記活動を継続するように復帰する手段と
を含む、装置。
（９）走査のための前記所定時間が、前記装置による他の装置からの所定数の照会メッセージの受信により低減される、前記（８）記載の装置。
（１０）中断される前記活動が装置発見の１つである、前記（８）記載の装置。
（１１）前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、前記（８）記載の装置。
（１２）中断される前記活動が装置発見の１つである、前記（１１）記載の装置。
（１３）前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、前記（１１）記載の装置。
（１４）別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、前記（１３）記載の装置。
（１５）周波数ホッピング・ベースのアドホック・ネットワークの装置のためのコンピュータ・プログラムを記録する、コンピュータ可読媒体を組み込むコンピュータ・プログラム製品であって、
前記装置により実行される走査活動を周期的に中断し、他の装置からの照会メッセージを所定時間走査するコンピュータ・プログラム・コード手段と、
別の装置からの前記照会メッセージの受信に際して、前記活動をランダム時間枠継続するように復帰し、前記ランダム時間枠の満了時に、前記照会メッセージを、特定の周波数ホッピング・ベースのアドホック・ネットワークに適用可能な正規プロシージャに従い処理するコンピュータ・プログラム・コード手段と、
前記所定時間の満了時に、前記活動を継続するように復帰するコンピュータ・プログラム・コード手段と
を含む、コンピュータ・プログラム製品。
（１６）走査のための前記所定時間が、前記装置による他の装置からの所定数の照会メッセージの受信により低減される、前記（１５）記載のコンピュータ・プログラム製品。
（１７）中断される前記活動が装置発見の１つである、前記（１５）記載のコンピュータ・プログラム製品。
（１８）前記周波数ホッピング・ベースのアドホック・ネットワークが、Bluetooth（商標）デファクト・スタンダードに従い実現される、前記（１５）記載のコンピュータ・プログラム製品。
（１９）中断される前記活動が装置発見の１つである、前記（１８）記載のコンピュータ・プログラム製品。
（２０）前記活動の前記周期的な中断が、毎２．５６秒に少なくとも１度発生する、前記（１８）記載のコンピュータ・プログラム製品。
（２１）別の装置から受信される前記照会メッセージを処理する前に、中断された前記活動を継続する前記ランダム時間枠が、１．２８秒以下に制限される、前記（２０）記載のコンピュータ・プログラム製品。
【図面の簡単な説明】
【図１】  Bluetooth（商標）照会プロシージャに関連する時刻表を示す図である。
【図２】本発明によるアルゴリズムの効果を示す時刻表を示す図である。
【図３】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、システム・レベル・エージェント、'アドホック・システム'を示す図である。
【図４】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、システム・レベル・エージェント、アドホック・システムの信号及び信号リストの定義を示す図である。
【図５】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、Bluetooth（商標）装置をモデル化するＢＴ装置、及びワイヤレス伝送媒体をモデル化する中間ブロックを含むシステム・ブロックを示す図である。
【図６】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、BT_devプロセスを含むＢＴ装置ブロックの構造を示す図である。
【図７】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、本発明のアルゴリズムの実施例であるBT_devプロセスを示す図である。
【図８】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、本発明のアルゴリズムの実施例であるBT_devプロセスを示す図である。
【図９】本発明のアルゴリズムを使用するアドホック・システムの、仕様記述言語（ＳＤＬ）にもとづくグラフィック表現を示す図であり、具体的には、本発明のアルゴリズムの実施例であるBT_devプロセスを示す図である。
【図１０】テスト時間が５０秒の場合の、本発明のアルゴリズムと、標準Bluetooth（商標）アルゴリズムとのテスト比較結果を示す図である。
【図１１】テスト時間が３０秒の場合の、本発明のアルゴリズムと、標準Bluetooth（商標）アルゴリズムとのテスト比較結果を示す図である。
【図１２】テスト時間が１０秒の場合の、本発明のアルゴリズムと、標準Bluetooth（商標）アルゴリズムとのテスト比較結果を示す図である。
【図１３】テスト時間が５０秒の場合のタイムアウト回数及び照会遅延の両者を、最大応答の関数として示した、本発明のアルゴリズムと、標準Bluetooth（商標）アルゴリズムとのテスト比較結果を示す図である。
【図１４】走査の開始時刻が走査期間内でランダムに分散される場合、１．２８秒よりも大きい走査期間では、５．１２秒以内に装置の発見を保証するのに不十分であることを証明する、時間対周波数の関係を示す図である。
【図１５】走査の開始時刻が走査期間内でランダムに分散される場合、１．２８秒の走査期間が、任意の開始走査周波数において、５．１２秒以内に装置の発見を保証するのに十分であることを証明する、時間対周波数の関係を示す図である。
【図１６】本発明のアルゴリズムが実現されるBluetooth（商標）装置のブロック図である。
【符号の説明】
３０１  ＢＴ装置（BT_device）
３０２  中間ブロック
３０５  BT_devプロセス
１０１０  Bluetooth（商標）ホスト
１０２０  物理バス・ハードウェア及びファームウェア
１０３０  Bluetooth（商標）装置
１０４０  ホスト・コントロール・インタフェース（ＨＣＩ）ファームウェア
１０５０  リンク・マネージャ・ファームウェア
【図１】
0003714618.tif 000006
【図２】
0003714618.tif 000007
【図３】
0003714618.tif 000008
【図４】
0003714618.tif 000009
【図５】
0003714618.tif 000010
【図６】
0003714618.tif 000011
【図７】
0003714618.tif 000012
【図８】
0003714618.tif 000013
【図９】
0003714618.tif 000014
【図１０】
0003714618.tif 000015
【図１１】
0003714618.tif 000016
【図１２】
0003714618.tif 000017
【図１３】
0003714618.tif 000018
【図１４】
0003714618.tif 000019
【図１５】
0003714618.tif 000020
【図１６】
0003714618.tif 000021