JP6241887B2 - 制限チャネル上でのピアツーピア通信 - Google Patents

Description

［関連技術に関する説明］
本出願の主題は、以下の同時係属中の米国非仮特許出願の主題に関連する：（ａ）「Ｓｅｌｅｃｔｉｏｎ ｏｆ ａ Ｍａｓｔｅｒ ｉｎ ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔ」［ＡＰＬ−Ｐ１６１７６ＵＳ１］と題され、２０１２年９月２４日に出願された、出願第１３／６２５，７５２号、（ｂ）「Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｏｆ Ｄｅｖｉｃｅｓ ｉｎ ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔ」［ＡＰＬ−Ｐ１６１７６ＵＳ２］と題され、２０１２年９月２４日に出願された、出願第１３／６２５，７６６号、（ｃ）「Ｓｅｌｅｃｔｉｏｎ ｏｆ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｔａｔｉｏｎｓ ｉｎ ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔ」［ＡＰＬ−Ｐ１６１７６ＵＳＸ１］と題され、２０１２年１０月２２日に出願された、出願第１３／６５７，７０７号、（ｄ）「Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎ Ｗｉｔｈｉｎ ａ Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｈｉｅｒａｒｃｈｙ ｏｆ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｄｅｖｉｃｅｓ」［ＡＰＬ−Ｐ１６１７６ＵＳＸ２］と題され、２０１３年１月８日に出願された、出願第１３／７３６，７２５号、及び（ｅ）「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｃｏｏｐｅｒａｔｉｖｅ Ｃｈａｎｎｅｌ Ｓｗｉｔｃｈｉｎｇ」［ＡＰＬ−Ｐ１９５５７ＵＳ１］と題され、２０１３年６月７日に出願された、出願第１３／９１３，２７８号。

本開示は、データ通信の分野に関する。より詳細には、制限された通信チャネル上でピアツーピア通信を行うための、方法及び装置が提供される。

無線通信は、データ及び音声に関して多くの利益を有するが、制限がないわけではない。例えば、合衆国では、５．２５〜５．３５ＧＨｚ及び５．４７〜５．７２５ＧＨｚの無線周波数範囲の民生使用は、特定のタイプのレーダーシステム（例えば、ドップラ気象レーダー）に干渉することが認められていない。保護されたレーダーシステムを示す信号が検出されると、制限された範囲を使用するように構成された、あらゆる装置、又は、そのように構成可能なあらゆる装置は、自動的かつ迅速に、干渉することのないチャネルに切り替えなければならない。

周波数の変更を容易にするために、多くの場合、動的周波数選択（ＤＦＳ）アルゴリズムが使用される。制限されていない周波数帯域であっても、通常は他のチャネル上での干渉又は輻輳を回避するために、ＤＦＳを使用して、無線装置（例えば、無線アクセスポイント）が複数の周波数チャネルのうちの１つを自動的に選択することを可能にする。

しかしながら、チャネル制限を順守するために、ピアツーピア通信環境内でＤＦＳを適用することは、通信中のピアが異なるアクセスポイントに接続されている場合、不可能であるか、又は少なくとも困難であった。例えば、２つのピア装置が直接通信しており、それらの一方が、その現在の（制限された）チャネルを離脱して変更するように、そのアクセスポイントによって要求される場合、特に、その変更が、その装置に関して既にスケジュールされていた一連のチャネル変更と競合する場合には、そのピアツーピア通信が中断される恐れがある。

一部の実施形態では、少なくとも一方が制限チャネルである、２つ以上の無線チャネル間で、チャネルホッピングを行いつつ、ピアツーピア通信を行うための、方法及び装置が提供される。これらの実施形態では、制限チャネルは、優先的な信号源又は優先的なタイプの信号に対して遅延処理されることが必要となるチャネルである。例示的な制限チャネルは、レーダー回避のための、又は何らかの他のタイプの信号と干渉することを回避するための、ＤＦＳ（動的周波数選択）若しくは同様のスキームの使用を必要とするものである。

一部の実施形態では、通信中のピアは、複数のチャネル間で同期的にホップし、それらの制限チャネルへのホップを、それらのチャネル上で動作しているアクセスポイント又はＤＦＳマスターのＴＢＴＴ（目標ビーコン送信時間）に整合させる。例えば、各チャネルホッピングシーケンスは、制限チャネル上で開始することができ、それらのピアは、ＴＢＴＴの極めて近くで（例えば、数ミリ秒前に）、そのチャネルに同調することができる。次いで、それらのピアは、不正に送信することを回避するために、かつビーコンの検出を容易にするために、沈黙する。それらのピアはまた、その制限チャネル上で既に通信していた場合には（すなわち、そのチャネルにホップしたばかりではなく）、ＴＢＴＴの少し前に休止することもできる。

そのチャネルが解放されていることをビーコンが示す場合には、それらのピアは、それらの通信を直ちに開始又は再開することができる。そうではない場合には、それらのピアは、それらが検出する、あらゆるチャネル切り替え告知又は他の指令を順守する。このＴＢＴＴの前後の静穏期間により、ピアツーピアフレームがビーコンの送信と衝突することも、又はビーコンの送信を遅延させることもないことが保証される。それゆえ、ピアツーピア通信は、チャネル回避の告知を受信及び順守する、ピア装置の能力を低下させることがない。

通信中のピア装置は、別のアクセスポイントとのコンタクトを維持するために、又は他のピア装置の集合との同期を維持するために、それらのピア装置が同調する複数の制限チャネル及び／又は何らかの他のチャネル（例えば、別のインフラストラクチャのチャネル、ソーシャルチャネル）のビーコンに、それらのピア装置のチャネルホップを整合させることができる。様々なチャネル上のビーコン間隔に応じて、ピア装置は、チャネルホッピングシーケンス周期の開始時に「ベース」チャネル（例えば、制限チャネル）に戻るためばかりではなく、ビーコンを捕捉する（又はピアがビーコンを発行することを許容する）ためにも、特定のチャネル上に滞留する時間の長さを動的に決定しなければならない場合がある。

一部の実施形態に係る、クラスタの装置間での同期を達成して維持するための、発見ビーコンの使用を示す。 一部の実施形態に係る、無線通信環境内のピアのクラスタ内部での、装置の同期及び動作を示す流れ図である。 一部の実施形態に係る、ピア装置間の帯域外交換を示す図である。 一部の実施形態に係る、装置がデータ転送動作を行いつつ、競合する通信需要を満足させるために同調する、チャネルのシーケンスを示す。 一部の実施形態に係る、装置がデータ転送動作を行いつつ、競合する通信需要を満足させるために同調する、チャネルのシーケンスを示す。 一部の実施形態に係る、通信中のピア装置間で共有される、チャネル切り替えのスケジュールを示す。 一部の実施形態に係る、２つの無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。 一部の実施形態に係る、一方が制限チャネルである２つの無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。 一部の実施形態に係る、２つの制限無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。 一部の実施形態に係る、ソーシャルチャネル及び１つ以上の制限チャネル間での、ピアツーピアチャネルホッピング通信を示す。 一部の実施形態に係る、ピア通信装置のブロック図である。

以下の説明は、開示される実施形態を、あらゆる当業者が実施及び使用することを可能にするために提示され、１つ以上の特定の用途及びその要件の文脈で提供される。開示される実施形態に対する様々な修正は、当業者には容易に明らかとなるものであり、本明細書で定義される一般原理は、開示される実施形態及び用途の範囲から逸脱することなく、他の実施形態及び用途に適用することができる。それゆえ、本開示は、示される実施形態に限定されることを意図するものではなく、むしろ、以下の説明と矛盾しない最も広い範囲が与えられることを意図するものである。

一部の実施形態では、制限チャネル上でピアツーピア無線通信を実行するための、方法及び装置が提供される。説明される実施形態は、免許不要全米情報基盤に割り当てられる周波数範囲（Ｕ−ＮＩＩ−２、Ｕ−ＮＩＩ−２ｅ、及びＵ−ＮＩＩ−３）などの、５ＧＨｚ無線周波数帯域の制限部分の範囲内での使用に好適であり、装置は、所定の信号（例えば、気象レーダーの識別サイン）の検出時に、それらの無線周波数帯域の制限部分から退出するように要求される。

具体的には、説明される実施形態は、レーダー回避要件を順守するための１つの技術である、ＤＦＳ（動的周波数選択）に適合する。以下の論考から、他の動作環境及び制限に関する他の実施形態を、容易に開発することができる。

これらの実施形態では、複数のピア装置は、複数のチャネル間で同期的にホップし、それらのチャネルのうちの少なくなくとも１つは、（例えば、保護された信号又はエミッタとの干渉を回避するようにＤＦＳに要求することによって）制限されている。それらの装置は、他のピア装置とランデブーし、インフラストラクチャのノードとの通信を維持し、様々なビーコン及び／又は他の管理フレームを捕捉することなどを可能とするために、種々のチャネル上でのそれらの装置の滞留時間を動的に計算して（又は、固定長のタイムスロットを使用して）、それらのホップを時間設定することができる。

前書
ピアツーピア無線通信環境は、スマートフォン、タブレット、無線携帯情報端末、ラップトップコンピュータ及びデスクトップコンピュータ、（例えば、マルチメディアコンテンツをストリーミングするための）メディア装置などの、同じタイプ及び／又は異なるタイプの任意数の装置によって特徴付けることができる。異なる装置は、異なる特徴を有し、異なるアプリケーションを実行することができ、異なる電力レベル（例えば、バッテリー充電）、異なる通信ニーズ、異なる負荷（例えば、プロセッサに対して、アンテナに対して）を有し得るものであり、様々な信号強度で、他の装置によって聴取される（又は、他の装置を聴取する）ことなどができる。更には、通信環境は流動的なものであり、装置は、継続的に、その環境を包含する空間領域内に入り、その中を通って移動し、出て行くことができる。

本明細書で開示される一部の実施形態は、そのような環境内の装置が互いを発見して、直接的に、ピアツーピアで通信することを可能にする。これらの実施形態は、装置及びサービスを容易に発見可能としながらも、低消費電力を促進し、他の通信技術（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標））と共存し、多帯域動作（例えば、２．４ＧＨｚ及び５ＧＨｚ）をサポートし、インフラストラクチャベースの技術との適合性を維持しつつも、ネットワークインフラストラクチャ（例えば、アクセスポイント）で通常遭遇する、スループット及びレイテンシの劣化を回避し、マスターとして機能している装置が、その環境から出て行く場合には、容易かつ迅速に回復し、多くの装置を有する高密度の環境に適応するように拡張可能であり、他の装置の集合との干渉を回避する。これらの特徴及び利点、並びに他の特徴及び利点を、以下で説明する。

一部の実施形態では、特定の環境内の装置の集合は、所定のチャネル上で、所定の時間にランデブーするように、同期化される。同期化された装置の集合は、クラスタと命名することができる。単一のクラスタの装置がランデブーする期間は、可用性窓と命名され、そのクラスタ内部の全てのマスター装置は、同じ可用性窓のスケジュールをアドバタイズする。可用性窓の間に、ピアは、マルチキャストデータ通信及び／又はユニキャストデータ通信を交換して、そのクラスタの管理又は動作を促進し、他の装置及びサービスを発見することができる。

今後の１つ以上の可用性窓のパラメータ（例えば、チャネル、開始時間、及び持続時間）が、１つ以上のソーシャルチャネル上に一斉配信される発見ビーコンを介して通信される。種々の実装では、ビーコンに遭遇するための種々の方策を適用することができる。例えば、装置は、所定のソーシャルチャネル上で、少なくとも１つの発見ビーコンを聴取するために十分な連続的期間にわたってリッスンすることができ、短い期間の周期的なリッスンにすることができる、などである。

それゆえ、装置が、ピア装置の環境内で起動するか、オンラインになるか、又はそのピア装置の環境内に移動する場合、その装置は、所定のソーシャルチャネルに同調して、いつどこで他の装置とランデブーすることができるかを素早く探知する。装置が発見ビーコンを聴取しない場合には、その装置は、マスターとして機能するべきであると想定して、その装置自体の発見ビーコンの発行を開始することにより、存在し得るか又は後に出現し得る他の装置との同期を促進することができる。

同期パラメータ（例えば、今後の可用性窓のスケジュール）もまた、一部の実装では、可用性窓の間に告知することができ、これにより、装置がパラメータを受信するために、それらの装置の無線機をソーシャルチャネルに切り替える労力が削減される。装置は更に、発見ビーコンをリッスンしていないとき、可用性窓に関与していないとき、ピアと直接通信していないとき、又は何らかの他の目的のために使用していないとき、その装置の無線の電源を切ることができる。

クラスタに関与している装置は、それゆえ、インフラストラクチャ接続又はＢｌｕｅｔｏｏｔｈ（登録商標）リンクなどの、複数の装置の機能との間で、無線機、アンテナ、及び／又は他の通信リソースを共有することができる。しかしながら、発見ビーコンを受信するために周期的にソーシャルチャネルに同調すること、ランデブーチャネル上で可用性窓に参加すること、及び通信チャネルの制限を順守することなどの、同期化されたピアツーピア環境の通信要件は、それらのリソースに対する他の需要と競合する恐れがある。

ピア装置のコミュニティ内部では、いずれの装置がマスターになり、他の装置を同期化する責任を負うことになるかを決定するために、選択手順が適用される。選択されるマスター装置の数は、存在するピア装置の数、それらのピア装置の信号強度、信号伝播パターン、動作パラメータなどに応じて決定することができる。

通信環境内の装置は、インフラストラクチャ要件の負担を有することなくピアツーピア通信に従事するが、マスターの選択は、そのクラスタの装置を、同期を目的とする階層へと論理的に編成することになる。この階層内部で、「アンカーマスター」（又は「最上位マスター」）は、そのアンカーマスターが一斉配信する発見ビーコンによって伝達される同期パラメータを介して、そのクラスタの全体的な同期に関与する。同期マスターと呼ばれる各下位マスターは、アンカーマスター又は介在する同期マスターと同期して、そのアンカーマスターの同期パラメータを再送信するか、若しくはそれ自体の発見ビーコン内部に再パッケージ化することにより、全体的な同期の範囲を拡張する。その階層に関与している他の装置は、非マスター装置になる。

単一の無線装置（例えば、アンカーマスター）の無線範囲は限定されており、このことにより、通常は、その装置が局所的な領域を越えて装置を編成することが妨げられる。その装置の同期パラメータを再び一斉配信するように、下位マスターに要求することにより、その単一の無線装置は、より広い区域にわたって拡散する装置の集合を同期化することが可能となる。そのクラスタ全体が、結果的に生じる利益（例えば、サービス及び他の装置の即時の発見、より少ない電力消費）を享受する。

インフラストラクチャ要件を有する（例えば、アクセスポイントを介した協調を必要とする）環境とは異なり、マスターの主要タスクは、ランデブー／同期パラメータを単純に配布することであるため、マスター装置の喪失は、容易に是正される。例えば、欠落したアンカーマスター装置によって公表されたランデブーのスケジュールは、後継のアンカーマスターが選択される間も、そのクラスタの同期マスターによって単純に維持されることになるため、全ての装置が同期化されたまま保たれる。また、その後継のアンカーマスターは、一般的に、その同じスケジュールを維持することになる。

マスターを選択するための種々のアルゴリズムは、種々の時間に、及び／又は種々の環境内で適用することができるが、全般的には、以下の目的のうちのいずれか、又は全てを促進するために役立つ：環境全体にわたる、マスターの均一な空間分布、環境内のマスターの調節可能な密度、及び、環境を構成する地理的区域のサイズの制御。

一部の実施形態では、マスターを選択又は特定するためのアルゴリズムは、装置の様々なメトリック又は属性に基づいて、最も適切な装置がマスターとして機能することを保証するように、定期的に実行される。この選択プロセスはまた、幾つのマスターが区域内に既に存在しているか、所定のピア装置が幾つのマスターを聴取することができるか、それらのマスターが（例えば、信号強度、又は何らかの他の距離の尺度に基づいて）どの程度遠く離れているかなども、考慮することができる。

以下の説明で取り上げられる幾つかのエンティティは、他の文脈では異なる用語で知られる場合があるため、網羅的であることを意図するものではないが、幾つかの代替的専門用語を特定するために、以下の対応付けが提供される。例えば、総称のマスター装置は、「同期局」と呼ばれる場合がある。アンカーマスターとして機能する装置はまた、「ルート」、「ルートマスター」、「ルート同期局」、又は「最上位マスター」として知られる場合もある。アンカーマスター以外の同期マスターはまた、「ブランチ同期局」、「ブランチ」マスター、又は下位マスターとして知られる場合もある。非マスター装置はまた、「リーフ」装置又は「スレーブ」と命名される場合もある。発見ビーコンは、代替的に「周期的同期フレーム」（又はＰＳＦ）と称される場合があり、可用性窓は、「発見窓」と呼ばれる場合がある。装置のクラスタは、代替的に、ツリー、同期ツリー、又は階層と呼ばれる場合がある。以下で紹介される他の用語としては、「マスター指示フレーム」（又はＭＩＦ）としても知られる場合がある、「同期ビーコン」が挙げられる。

以下のセクションは、一部の実施形態に係る、クラスタを形成するための、ピアツーピア環境内での装置の同期と、協働的なピアツーピア通信と、制限された環境内でのピアツーピア通信の行うことと、例示的なピア装置とを論じるものである。

装置の同期
上述のように、一部の実施形態に係る、無線通信環境内での装置の同期は、それらの装置が、容易に互いを発見し、利用可能なサービスを特定し、直接的なピアツーピア通信（ユニキャスト及び／又はマルチキャスト）に従事しつつも、電力リソースを節約し、他の通信プロセスと共存することを可能にする。

クラスタを形成するための同期は、装置が、適合するプロトコルで動作している少なくとも１つの他の装置の範囲内でオンラインになるか、又はその範囲内に移動すると、直ちに開始され、それらの同期化された装置を包含する空間的区域内部で、その装置がオンラインである間は（例えば、その装置がマスター装置の範囲内に存在する間は）維持することができる。

同期及びマスター選択のプロセスを通じて、装置は、自動的に階層的クラスタへと編成され、この階層的クラスタ内では、階層の各レベル（又は層）のマスターは、区域内の装置間の同期を達成して維持するために、同期パラメータを周期的に一斉配信する。発見ビーコン（ＤＢ）は、同期パラメータを配布するための１つの機構であり、同期化される全ての装置によって消費される。

発見ビーコンは、限定するものではないが、装置のクロックを同期化するための情報、クラスタの装置がその間にランデブーすることが可能な１つ以上の今後の可用性窓の説明、並びにそのＤＢを送信したアンカーマスター及び同期マスターのメトリック（又は属性）などの、情報を伝達するために役立つ。他の実施形態では、ＤＢは、異なる情報の集合を含み得るが、通常は、少なくとも１つの可用性窓を特定する判定基準を含むものである。

クラスタの形成、及びそのクラスタ内部の装置の同期は、限定するものではないが、そのクラスタの最大深さ又は層、発見ビーコンの周期性、マスター装置の（例えば、全体の、及び／又は所定の装置の範囲内の）数、マスターを選択するために使用される選択アルゴリズム、その選択アルゴリズムによって考慮される、装置のメトリック又は属性などの、構成パラメータあるいは動作パラメータによって影響される場合がある。種々の実施形態では、種々のパラメータを適用することができる。「Ｇｒｏｕｐ Ｆｏｒｍａｔｉｏｎ ｗｉｔｈｉｎ ａ Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｈｉｅｒａｒｃｈｙ ｏｆ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｄｅｖｉｃｅｓ」と題され、２０１２年１０月２２日に出願された、米国特許出願第１３／７３６，７２５号は、ピアツーピアネットワーク内でマスターを選択する方法、及びプライベートグループを形成する方法を開示しており、参照により本明細書に組み込まれる。

図１は、一部の実施形態に係る、２つ以上の装置の間で同期を達成して維持するための、発見ビーコンの使用を示す。

これらの実施形態では、発見ビーコン１１０（例えば、ビーコン１１０ａ、１１０ｂ、１１０ｎ）は、１つ以上のソーシャルチャネル１２０（例えば、チャネルＡ１２０ａ、チャネルＢ１２０ｂ、チャネルＮ１２０ｎ）上に、定期的に送信される。

異なるマスター装置は、同じソーシャルチャネル又は異なるソーシャルチャネル上に発見ビーコンを送信することができ、いずれの所定のマスターも、１つ以上のソーシャルチャネル（及び／又は他のチャネル）を使用して、そのＤＢを伝達することができる。単一のクラスタ内の異なるマスターは、恐らくは、互いに干渉することを回避するために、異なるソーシャルチャネルを使用することができるが、これは、１つのマスターによって使用されるソーシャルチャネルが、異なる目的（例えば、インフラストラクチャ接続）のために、及び／又は何らかの他の理由のために、異なるマスターによって使用中となる場合があるためである。可用性窓は、ソーシャルチャネル上で行われる場合もあれば、行われない場合もある。

図１では複数のソーシャルチャネル１２０が示されるが、一部の実装では、１つのクラスタ内の全てのマスター装置は、同じソーシャルチャネルを使用して、同じ可用性窓のスケジュールをアドバタイズすることができる。本明細書で論じられるソーシャルチャネル及び／又は他のチャネルは、制限を有するか、又は有さない、ＩＥＥＥ ８０２．１１無線チャネルとすることができる。例えば、ビーコンを送信するため、又はピア装置間で通信するために使用される、ソーシャルチャネル若しくは他のタイプのチャネルは、ＤＦＳ（動的周波数選択）の対象となり得るものであり、その使用に対する制限を伴い得る。後続のセクションで取り上げられる、１つのそのような制限は、特定のタイプの信号（例えば、気象レーダーパルス）が検出されるとき、チャネルから退出するように装置に要求する。後続のセクションで論じられるように、このことにより、ピア装置の通常の通信に対する修正が必要となる場合がある。

ソーシャルチャネル１２０ａ、１２０ｂ、１２０ｎ上には、対応する発見ビーコン１１０ａ、１１０ｂ、１１０ｎが、関与するマスターによって、周期的に一斉配信される。単一のチャネル上に単一のマスターによって一斉配信されるＤＢ（例えば、ビーコン１１０ａ）のそれぞれは、同一である場合もあれば、幾分異なる場合もある。

図１では、各チャネルの発見ビーコンの周期（Ｐ_A、Ｐ_B、Ｐ_N）は異なるが、複数のソーシャルチャネルが採用される、一部の実施形態では、２つ以上のチャネルのビーコン周期を同一にすることができる。１つのチャネル上でのＤＢ間の例示的な周期は、約１００ミリ秒とすることができるが、厳密に１００ｍｓではない場合もある。異なるマスターは、同じＤＢ周期、又は異なるＤＢ周期を使用することができる。一部の実装では、発見ビーコン周期の長さ又は持続時間は、ＤＢを一斉配信するマスターの全体数（又は一斉配信している特定領域内のマスターの数）に反比例させることができる。

本明細書でミリ秒（ｍｓ）として表される期間は、同じ大きさ又は同等の大きさの時間単位（ＴＵ）によって、代替的に実施することができる点に留意されたい。ＩＥＥＥ ８０２．１１標準規格で指定される場合、時間単位は１，０２４マイクロ秒に等しい。それゆえ、本明細書で言及される１００ｍｓの期間を、１００時間単位として、又は同等の数の時間単位（例えば、約９８ＴＵ）として、代わりに実施することができ、１０２．４ｍｓを１００ＴＵとして実施することなども可能である。

一部の実施形態では、ＤＢ周期は、各ソーシャルチャネル上で異なるものとなるが、しかしながら、それらのＤＢを発行するマスターによって実施される可用性窓周期は、同じものにすることができる。それゆえ、１つのクラスタ内部では、複数のＤＢ周期及び単一の可用性窓周期を実施することができる。

ＤＢを送信する場合、発行マスターは、単に、その無線機を正しいチャネルに同調させ、ビーコンを送信するために十分な長さで無線の電源をオンにすることのみを必要とする。そのマスターは、ＤＢを発行した後は、そのチャネル上に留まる必要がなく、むしろ、その無線機をオフにして電力を節約するか、その無線機を異なるソーシャルチャネルに（例えば、異なるチャネル上にＤＢを送信する準備のために）切り替えるか、又は、可用性窓に（以下で説明するように）参加すること、インフラストラクチャ通信を処理すること、別の装置とデータを交換することなどの、何らかの他の目的のために、その無線機を使用することができる。

一部の実施形態では、発見ビーコンは、厳密な周期的スケジューリングを順守する必要はない。その代わりに、ビーコンは、可能な限り定期的に送信されるが、保証されているような他の装置の動作に対しては、遅延処理される場合がある。一部の実装では、発見ビーコンは、新たなピア装置が、ある程度の確率で、又はある程度の限定された時間の長さの範囲内で、装置のクラスタを発見することが可能となる、最小限の平均的な周期性を少なくとも生じさせるために、十分に頻繁に発行されることのみが必要とされる。

図１のＤＢ１１０ｘは、一部の実施形態でマスターによって一斉配信される、例示的なビーコンである。他の実施形態では、発見ビーコンは、その例示的なエレメントの部分集合又は上位集合を含み得る。例えば、ＤＢは、本明細書では主として、マスターによって発行されているように説明されるが、非マスター装置もまた、発見ビーコン又は他のタイプのビーコン若しくはフレームを発行することができ、しかしながら、これらの非マスタービーコン又はフレームは、ＤＢ１１０ｘによって伝達される情報エレメントの部分集合のみを含み得るものであり、より長い周期で発行することができる。

図示の実施形態では、チャネル１３０、時間１３２、及び周期１３４（及び恐らくは、持続時間１３６）の情報エレメントは、「同期パラメータ」又は「可用性窓パラメータ」と総称される場合があるが、これは、それらの情報エレメントにより、リッスンする装置は、そのＤＢを発行したマスターによって（又は上位マスター）によって課されている可用性窓のシーケンスを探知することが可能となるためである。チャネル１３０は、全ての可用性窓（又は、少なくとも次回の可用性窓）が発生するチャネル（例えば、８０２．１１無線チャネル）を特定し、時間１３２は、その窓がいつ発生するかを特定し、周期１３４は、その可用性窓周期を特定し、これにより、リッスンする装置は、継続的な可用性窓の開始時間を計算することが可能となる。持続時間１３６は、その可用性窓の持続時間を特定する。

異なるチャネル上での可用性窓のシーケンスをアドバタイズするためか、１つのシーケンスから別のシーケンスへの変更を他の装置に報告するためか、又は何らかの他の理由のために、同期パラメータの複数のセットをＤＢ内に含めることができる。

例示的な発見ビーコン１１０ｘの同期パラメータの時間エレメント１３２は、絶対的開始時間（例えば、同期クロック、ＵＴＣ（協定世界時）、又は何らかの他の共通基準に基づく）及び／又は相対的時間を特定することができる。一部の実装では、タイムスタンプのフィールドが、ＤＢ１１０ｘを発行した局のＴＳＦ（時刻同期機能）を伝達する。

一部の実施形態では、時間１３２は、ピア装置が次回の可用性窓の開始時間を計算するために使用する、複数の値を含む。例えば、時間１３２は、ＤＢ１１０ｘが発行マスター内部で形成され、送信のための待ち行列に登録されたとき（例えば、ＤＢが送信バッファ内に置かれたとき）を示すように構成された「目標の」タイムスタンプ、及び、そのＤＢがマスターのアンテナを介して実際に発信されたときを示すように構成された「実際の」タイムスタンプを含み得る。

例示的には、ＤＢは、マスターによって「マスターオフセット」パラメータが算出される時点で、形成されたと見なされる。このマスターオフセット値もまた、時間１３２の一部、又は異なる情報エレメントとして、ＤＢ１１０ｘ内部に含められるものであり、そのＤＢを発行マスターが解放する時間から測定される、次の可用性窓の開始に対する発行マスターの内部オフセットを表す。それゆえ、マスターオフセットは、その発見ビーコンを発行した局によって算出されるような、目標のタイムスタンプから可用性窓の開始までの期間を測定するものである。

これらの値を使用して、ＤＢ１１０ｘを消費するピア装置は、以下のように、可用性窓の開始時間に対するオフセットを計算することができる。
オフセット＝マスターオフセット−（実際のタイムスタンプ−目標のタイムスタンプ）

具体的には、ピア装置は、マスターオフセットを受信し、目標及び実際のタイムスタンプから、そのマスターオフセットの期間のうちの経過時間を測定することができ、次いで、マスターオフセットから、その経過した期間を差し引いて、可用性窓までの残りの時間量を決定する。

周期１３４は、発行マスターによって行われる可用性窓の周期を特定する。ピア装置のクラスタ全体が、そのクラスタのアンカーマスターによって例示的に設定される、同じ周期及び同じ可用性窓のスケジュールを適用することができる。

ＤＢ１１０ｘの持続時間１３６は、一部の実装では任意選択的であるが、提供される場合、ＤＢ１１０ｘを発行した装置がリッスンし、かつ通信のために利用可能となる、可用性窓の間の最小時間量を指示する。この持続時間はまた、ビーコン１１０ｘを消費する同期化される装置にも適用することができ、すなわち、その窓に参加する装置は、その窓の開始から測定される、少なくともその期間にわたって、利用可能となることが要求される場合がある。

一部の実施形態では、マスターは、少なくとも１つの局がその窓の間にマスターと通信している間は、その可用性窓を（例えば、持続時間１３６に一致する増分で、又は何らかの他の持続時間で）自動的に延長することができる。それゆえ、複数の局がマスター装置と通信することを望む場合であっても、その窓が延長されることになるため、それらの局は、別の可用性窓を待つことなく通信することが可能になり得る。

同様に、可用性窓に参加するピア装置は、そのピアのうちの少なくとも１つが通信に従事する間は、そのピア装置の窓を延長することができる。それゆえ、別のピアと通信することを望む１つのピアは、可用性窓の間に、パケット、データグラム、メッセージ、又は他の通信のユニットの第１のセットを、その別のピアに、単純に発行することができる。次いで、双方のピアは、アクティブな通信により、それらの窓を自動的に延長することになる。有利には、このことにより、可用性窓の間に帯域幅を飽和させるか又は独占することもなく、可用性窓の延長の間の広範なピアツーピア通信が可能となる。

それゆえ、可用性窓の間の、マスターの存在の最大持続時間は、ＤＢ１１０ｘ内で指定することができ、かつ／又は可用性窓の間に告知することもできる。例示的には、マスターは、異なるチャネル上にＤＢを発行するために、別の通信機能用にその無線機を使用するために、又は何らかの他の理由のために、その窓から撤退することが必要とされる場合がある。個々の装置に関しては、その窓内の一部の期間中に、それらの装置が通信するべきことを有さない場合、及び、その装置と通信する他の装置が存在しない場合には、それらの装置は、可用性窓から撤退することができる。

他の実施形態では、発見ビーコンの可用性窓パラメータは、単に１つの可用性窓を特定して周期を提供するのではなく、１つ以上の可用性窓を明示的に特定することができる。これらの実施形態は、マスター装置及び／又は他のピア装置が、可用性窓の定期的な周期的スケジュールに関与することができない環境で、実施することができる。更に他の実施形態では、周期的スケジュールを適用することができるが、そのスケジュールに１つ以上の可用性窓を明示的に追加することができ、又は１つ以上の周期的窓の発生を取り消すこともできる。

それゆえ、ＤＢの同期パラメータ又はデータは、任意数（例えば、１つ以上）の可用性窓を特定することができる。同じソーシャルチャネル又は異なるソーシャルチャネル上に、異なるマスターによって送信される、異なるＤＢは、同じ可用性窓、又は異なる可用性窓を特定することができる。しかしながら、典型的には、アンカーマスターによって設定される（可用性窓のスケジュール又はシーケンスを含む）同期パラメータは、そのクラスタの全体にわたって適用される。それゆえ、これらの実施形態では、クラスタの全体にわたって一斉配信される全ての発見ビーコンは、同じ可用性窓のスケジュールを報告する。

一部の実施形態では、可用性窓は番号付けされ、繰り返しシーケンスとして行われる。例えば、１つのシーケンスで行われるｎ個の可用性窓は、０〜ｎ−１で番号付けすることができる。１回の反復の後、この可用性窓シーケンス番号（すなわち、０〜ｎ−１）が繰り返される。ＤＢ１１０ｘの後に発生する次回の可用性窓のシーケンス番号は、ビーコン内で（例えば、図１には示されない情報エレメント内で）明示的に特定することができ、可用性窓の間に決定することができ、又は何らかの他の方法で探知することができる。

図１の例示的な発見ビーコン１１０ｘはまた、１つ以上の優先度値（あるいは、マスターランク、マスター優先度値、又は選択値と命名される）も報告する。優先度値は、マスターとなるための装置の、好適性若しくは優先度を特定するために使用される値（例えば、整数）である。装置の優先度値は、対応する装置の様々なメトリック、属性、又は特性、また恐らくは、通信環境又は装置のクラスタの特性を使用して算出される。装置の優先度値を算出するための例示的メトリックとしては、その装置の利用可能な電力リソース（例えば、バッテリー強度又は充電、ＡＣ電源への接続）、プロセッサ負荷、信号強度、その装置の名称及び／又はアドレス（例えば、ＭＡＣアドレス）、その装置のアンカーマスターの名称又はアドレス、タイムスタンプ、その装置のクラスタ内部でのレベル又は層（例えば、アンカーマスターからのホップ数）、その装置の発見ビーコンの周期性（又は平均周期性）、その局によって使用されるソーシャルチャネル、その局が周期的に同調しなければならないインフラストラクチャのチャネル、他の装置義務（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）共存、インフラストラクチャ接続）などが挙げられる。

同期化される装置の優先度値を、選択プロセスの一部として比較することにより、１つのクラスタ内部で、いずれの装置をマスターとするべきかを決定することができる。このプロセスは、毎回の可用性窓のシーケンスの間、又はそのシーケンスの後、固定スケジュールで、などのように、定期的に実行することができる。

ＤＢ１１０ｘ内で、同期マスター優先度値１４０は、発見ビーコン１１０ｘを一斉配信する同期マスターのマスター優先度値であり、そのクラスタ内部でマスターとなるための、その装置の好適性又は優先度を示す。その優先度値をアドバタイズすることによって、そのマスターの範囲内の全ての装置は、選択プロセスを正確に適用して、例えば、それらの装置が、マスターとなることに、より良好に適しているか否かを判定することができる。

同様に、アンカーマスター優先度値１４２は、ビーコン１１０ｘが一斉配信されたクラスタに関するアンカーマスターのマスター優先度値であり、マスターとなるための、その装置の好適性又は優先度を示す。例示的には、クラスタ全体にわたってアンカーマスター優先度値１４２を伝播させることによって、そのクラスタの周辺部の装置、又は複数の別個のクラスタに重複する区域内の装置は、いずれのクラスタに加入するべきかを決定することができる。更には、１つのクラスタ内の全ての装置は、それらの装置が、アンカーマスターとなることに、より良好に適しているか否かを判定することができる。

ＤＢ１１０ｘが、クラスタのアンカーマスターによって発行される場合、優先度値１４０、１４２は一致することになる。あるいは、それらの優先度値のフィールドの一方を省略することも可能である。

一部の実装では、発見ビーコンは、図１のＤＢ１１０ｘ内に示すもの以外の情報エレメントを含み得る。例えば、ビーコンは、マスターを選択するためのアルゴリズムを特定することができ、マスターに対する制約（例えば、互いの範囲内に存在することができる数）を指定することができ、その装置のクラスタに関する最大深さをアドバタイズすることができ、そのクラスタから装置が撤退中であるという通知を提供することなどができる。

マスターは、上述のように、発見ビーコンの発行までに規定の周期を有し得るが、その周期は柔軟性があり、変形態様に関して高い許容度が存在し得る。所定のＤＢは、そのマスター装置の無線機に対する他の需要のために、通信チャネル上での競合のために、若しくは何らかの他の理由のために、時間が先行又は遅延される場合がある。一部の実装では、ＤＢは、１００ミリ秒ごとに約＋／−２０ミリ秒で変動し得る。一部の他の実装では、変動は、発見ビーコンの長期間の平均周期性が約１００ｍｓとなる限り、＋／−１００ミリ秒の大きさとすることができる。

発見ビーコンは、日和見的に送信することができ、このことは、マスターの無線が、通常はソーシャルチャネル上にＤＢを発行する時間に、異なるチャネルに同調されている場合には、そのマスターは、その現在のチャネル上に、代わりにビーコンを発行することができることを意味する。発見ビーコンの一斉配信は、可能なときに、ソーシャルチャネル上での、それらの通常のスケジュールに復帰することになる。

今後の可用性窓を特定するために、ＤＢが非ソーシャルチャネル上に送信される、このタイプの状況は、装置の局所的なクラスタに有用であり得る。そのような装置は、同じ（非ソーシャル）チャネル上で、同じインフラストラクチャネットワークに関連付けられる可能性が高い。このチャネル上にＤＢを送信することにより、これらの装置の、チャネルの切り替え（すなわち、ソーシャルチャネルへの切り替え）のコストが節減され、それらの装置のインフラストラクチャ通信と干渉することが回避される。

最悪の場合には、マスターの通常のソーシャルチャネルに同調される新たな装置は、そのマスターが異なるチャネル上でビジーである場合には、限定数の発見ビーコンを取り逃す恐れがある。しかしながら、マスターは、共通に使用される周波数（例えば、上述のような、特定の用途のために必要とされるインフラストラクチャのチャネル）に同調させることができ、それゆえ、その同じ装置に異なる時間に到達することができる。

ＤＢ内に含めることが可能な他の情報の中には、発見ビーコンを送信するための発行マスターの（平均）周期、及び、そのビーコンが一斉配信されるチャネルがある。このことにより、ピア装置は、ＤＢを聴取して可用性窓のスケジュールを探知するために、そのピア装置が特定のソーシャルチャネル上でリッスンすることが必要となり得る時間量を、決定することが可能となる。

マスターによってスケジュールされる可用性窓は、定期的な周期で発生する場合もあれば、そうではない場合もあり、そのマスターのＤＢと同期化される場合もあれば、そうではない場合もある。換言すれば、可用性窓は、発見ビーコンから同一のオフセットで発生する必要はない。可用性窓の全シーケンスが占める例示的な持続時間は、約数秒とすることができるが、一実施形態の特定の実装は、より短い持続時間、又はより長い持続時間を採用することができる。

一部の実施形態では、発見ビーコン周期に関して存在するものよりも小さい、可用性窓周期に関する許容誤差が存在し、恐らくは、（ＤＢに関する毎秒＋／−２００ミリ秒と比較して）毎秒約＋／−１００マイクロ秒である。ＤＢは、極めて短い（例えば、１ミリ秒未満である）が、頻繁に発行される一方で、可用性窓は、比較的長く、行われる頻度が低い。例えば、可用性窓は、１６ｍｓ、５０ｍｓ、又はそれよりも長く持続し得る。発見ビーコンは、その短い持続時間のために、日和見的にスケジュールすることができるが、可用性窓は、装置の発見及び通信のために構成されるため、一般的には、自発的又は日和見的に行うことができない。

比較的頻度は低いが、可用性窓は、有意な期間にわたって無線インターフェースを独占し得るものであり、このことにより、厳密なスケジュールの順守は、特に、他の無線技術（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標））が存在する場合には有利である。また、他の（同期化される）装置も、発見及び／又はピア通信に関して、アドバタイズされた窓のスケジュールに依存しており、変形態様に関して残される余地はより少ない。

それゆえ、一部の実施形態では、発見ビーコン周期が、変形態様に関して比較的高い許容度を有する一方で、可用性窓周期は、変形態様に関して比較的低い許容度を有することになる。この方策の１つの利点は、毎回の発見ビーコンの送信で発生する、Ｗｉ−Ｆｉ競合が考慮される点である。発見ビーコンの送信は、選択されたソーシャルチャネルが使用中でない場合にのみ可能であり、そのチャネル又は無線機に関する競合が、ＤＢの発行を遅延させる場合もあれば、遅延させない場合もある。それゆえ、全てのＤＢ送信の厳密なスケジューリングは、達成することが困難である。

ピア装置が、最初にマスター装置と同期して、可用性窓に参加することを開始すると、その第１の窓（及び／又は全ての装置が参加することを要求される第１の窓）内に、そのピア装置は、そのピア装置自体を特定し、その優先度値を特定し、その選択メトリックを提供し、そのサービスなどをアドバタイズする、メッセージを発行することができる。次いで、そのピア装置と通信することを望むいずれの装置も、コンタクトを取ることができる。

可用性窓は、ピア装置が、互いを発見し、かつ提供されるサービスを発見するための、主要機構として提供されるが、装置（マスターを含む）は、シーケンス内の１つ以上の窓をスキップする場合がある。例えば、ピア装置が、可用性窓と時折重複する定期的な間隔で、その無線機を何らかの他の目的のために使用する必要がある場合には、そのピア装置は、競合する可用性窓に全く参加しないことが可能であり、遅れて到着することも可能であり、又は早期に退去することも可能である。その装置は、マスター又は他の装置に、その不在を（例えば、マルチキャストメッセージを介して）報告する場合もあれば、報告しない場合もある。

一部の実施形態では、装置は、その装置自体に関する「存在モード」を設定し、その装置のマスター（すなわち、その装置が同期しているマスター）及び／又は他のピアに、この値をアドバタイズすることにより、その装置が、アドバタイズされた可用性窓に同調又は参加する頻度を、示すことができる。一部の実装では、存在モード（又はＰＭ）は、１、２、４などの整数値である。この装置のＰＭの逆数は、その装置がシーケンス内の幾つの可用性窓に参加するかを示す、分数である。例えば、装置のＰＭが１に等しい場合には、その装置は、全ての可用性窓に参加し、２のＰＭの場合には、その装置は、２の倍数のシーケンス番号を有する全ての窓（すなわち、それらの窓の１／２）に参加し、その装置のＰＭが４に等しい場合には、その装置は、シーケンス番号が４の倍数である全ての窓（すなわち、それらの窓の１／４）に参加することになる。

より高い存在モード値は、装置が、より多くの窓をスキップして、その無線機をオフにすることにより、電力を節約することを可能にする。最終的には、シーケンス内の可用性窓の数に等しい存在モードは、１回のシーケンスにつき、装置が１つのみの可用性窓に参加することを意味する。ゼロのＰＭ値は、装置が常に（すなわち、単に可用性窓の間のみではなく）利用可能であることを示し得る。

一部の実施形態では、同期化される全ての装置は、その装置のマスターによってアドバタイズされる、シーケンス内の少なくとも１つの可用性窓に参加しなければならない。例えば、装置は、各シーケンスの可用性窓０に参加することを要求される場合がある。それゆえ、この場合には、可用性窓シーケンスの長さに等しいＰＭ値は、シーケンス番号０を有する可用性窓の間にのみ、その装置が存在することになることを示す。

可用性窓シーケンスの長さは、一般的に、２の累乗（例えば、８、３２、２５６）である。一部の実装では、マスターによって行われる可用性窓のシーケンス番号は、ゼロで開始して、長さ−１の値（例えば、７、３１、２５５）に到達するまで１つずつ増大し、その後それらの番号が繰り返される。同期マスターは、そのマスター（すなわち、より高レベルの同期マスター又はアンカーマスター）の現在のシーケンス番号を採用して、（それらのビーコン内で）繰り返すことを要求される。それゆえ、１つのアンカーマスターの下で同期化される全ての装置（すなわち、１つのクラスタ内部の全てのピア装置）は、いずれの可用性窓がシーケンス番号０を有するかについて合意することになる。

一部の実施形態では、異なるマスターによってアドバタイズされる可用性窓のシーケンスは、異なる長さのものとなる場合がある。しかしながら、全てのシーケンスは、特定の存在モード値を有する全ての装置が同じ窓に参加するように、整合される。換言すれば、全ての装置は、いずれの特定の窓が所定の番号の倍数であるかについて合意することになる。

例えば、長さ８、１６、及び６４の可用性窓シーケンスが、異なる装置（例えば、異なるマスターと同期化された装置）のセット間で使用中である、クラスタを考察する。８つの窓のシーケンスを実施する装置の間では、８つごとの窓が、可用性窓シーケンス番号０として知られることになる。それらの装置に関してシーケンス番号０を有する全ての可用性窓は、１６個の窓の長さのシーケンスを有する装置に関しては、シーケンス番号０又は８を有する可用性窓となり、また、それらのシーケンス内に６４個の可用性窓を有する装置に関しては、シーケンス番号０、８、１６、２４、３２、４０、４８、又は５６を有する可用性窓となる。

装置は、そのＰＭが示すよりも多くの可用性窓に参加する場合があるが、その存在モード値を（例えば、可用性窓シーケンス番号０内のマルチキャストメッセージを介して）告知することによって、他の装置は、その装置といつ相互作用することができるかを知ることになる。また、前述のように、１つのピア装置が、装置への通信を、その受信装置によって参加される窓の間に送る間は、その装置は、可能な場合には、その通信を行うために、そのチャネル上でのその存在を延長することになり、更に他のピアが、その装置にコンタクトを取ることも可能になる。

更には、一部の実施形態では、１（又は何らかの他の閾値）よりも大きい存在モードを有するピア装置が通信を受信する場合は常に、そのピア装置は、所望の通信を促進するために、その存在モードを、１（又は、より低い何らかの他の値）に自動的に設定することができる。また更には、低い存在モード（例えば、ゼロ又は１）を有する装置は、１つの可用性窓内でマルチキャストフレームを受信した後、１つ以上の後続の窓内で、そのフレームを繰り返すことにより、その装置のピアにそのフレームを届けることを支援することができる。

マスターは、任意のＰＭ値を有し得るものであり、周期的な間隔で（恐らくは、可用性窓の間でさえ）発見ビーコンを送信するが、ビーコンを送信していないときの可用性窓の間は、その無線機を遮断するか、又は他の通信要件のために、その無線機若しくはアンテナを使用することができる。

一部の実施形態では、比較的長期間の（例えば、ファイル転送のため、ゲーム又は他のアプリケーションに従事するための）通信を行うことを望む２つ以上のピア装置は、データ交換の目的のために、全体的な同期と並行して、ただし、スケジュールされた可用性窓の外で、又はスケジュールされた可用性窓に加えて、それら自体の同期を確立することができる。これらの実施形態では、２つ以上の装置のうちの１つは、非選択マスターの役割を担うことができ、これは、その装置が、正規のマスター選択プロセスには関与しないが、他の装置が又は他の装置と（例えば、ファイル転送を行うため、ゲームをプレイするために）同期するために利用可能であることを意味する。非選択マスターと同期化される装置は、独立基本サービスセット（ＩＢＳＳ）を形成することができる。

非選択マスターは、その非選択マスターが通信することになる他のピア装置が、その非選択マスターと同期するために使用する、ビーコンを発行することができるが、クラスタ内の他の装置は、そのビーコンを無視する。例示的には、これらのビーコンは、可用性窓の間に、かつ／又は合意されたチャネル上に、送信することができる。非選択マスターのビーコンにより、その装置が非選択マスターであることを指定することができるため、その装置と直接通信することを必要としない装置は、その装置と同期するべきではないことを知ることになる。非選択マスターとの通信に従事していた装置が、その通信を終了する場合、その装置は、（例えば、その非選択マスターとの同期により、その装置がクラスタとの同期を喪失していた場合には）正規のマスターと再同期して、そのマスターのクラスタに再加入することができる。

ピアのクラスタと同期するか又は同期を維持することを望む装置は、そうすることができない場合があるが、これは恐らくは、その装置が、そのクラスタのソーシャルチャネルを監視することができないためか、スケジュールされた可用性窓の間に他のコミットメントを有するためか、又は何らかの他の理由のためである。この状況では、その装置は、非選択マスターとなり（かつ、その装置がいつ利用可能であるかを特定し）、他の装置がその装置を発見することを支援することができる。あるいは、その装置は、その装置に適応するように、そのクラスタの可用性窓のスケジュールに対する変更をリクエストすることができ、又は、その装置の選択優先度値が、マスターになるべきであることを示す場合には、マスターになることができる。マスターとして、特にアンカーマスターとして、その装置は、可用性窓のスケジュールを変更することが可能である。

一部の実施形態では、ランデブーチャネル上での可用性窓の間に、マスター又は他の装置（例えば、非選択マスター）は、同期ビーコン（ＳＢ）と呼ばれる、異なるタイプのビーコンを一斉配信することができる。これらの実施形態では、同期ビーコンは、例えば、定期的なＤＢを発行するマスターとの同期、又はデータを直接交換するために装置が同期することができる非選択マスターとの同期のいずれかを、ピア装置が達成又は維持することを支援する情報を提供する。同期ビーコンは、可用性窓の間に送信することができるが、一般的には、例えば、ソーシャルチャネル上に発生している可用性窓の間に送信される場合を除いて、ソーシャルチャネル上に送信されることはない。

同期ビーコンは、発見ビーコンが含み得る任意のデータ、及び／又は他の情報を含み得る。例えば、ＳＢは、マスターによって、そのマスターがＤＢを送信するために異なるソーシャルチャネルの使用を開始することを報告するために送信される場合があり、非選択マスターによって、その非選択マスターが特定の時間に特定のチャネル上で可用性の窓を有することを報告するために送信される場合があり、別の装置によって、その装置が何らかの他のマスターから聴取した同期データを報告するために、又はその装置の可用性をアドバタイズするために送信される場合などがある。

可用性窓が、ＤＢが通常（すなわち、発行マスターのＤＢ周期に従って）送信される時間と重複する場合、その定期的な発見ビーコンは、可用性窓が行われるチャネル上に（かつ、その可用性窓がソーシャルチャネル上で行われていないと想定すると、ソーシャルチャネル上にではなく）送信することができる。マスターのＤＢ周期の満了と重複しない可用性窓の間であっても、マスターは、そのマスターと同期化される装置が、定期的なＤＢのためにソーシャルチャネルに同調する必要なく、必要な同期データを有することを保証するために、同期ビーコンを送信することができる。しかしながら、装置は、他のマスターを聞知するために、かつ／又は他の理由のために、依然として、１つ以上のソーシャルチャネル上で周期的にリッスンすることができる。

１よりも大きい存在モード値を有するピア装置は、全ての可用性窓に参加し得るものではないが、シーケンス番号０を有する可用性窓の間に存在することを要求され得るため、マスターは、デフォルトで、それらの窓の間にＤＢ又はＳＦを常に一斉配信することができる。ＤＢは、短いが頻繁である一方で、ＳＢは、より長く、より低頻度であり、拡張されたサービス及び装置能力のペイロードをパックすることができる。

発見ビーコンは、非同期装置がそれらのピアと同期することを支援するために、頻繁に、通常は可用性窓の外で送信される点を、繰り返す価値があるであろう。装置のクラスタが同期化された後、それらの装置は、特に、その無線機の使用をより少なくすることによって電力を節約するように、その存在モードを調節している装置は、比較的まばらな可用性窓の間にのみ（又は主として）出会うことができる。同期を維持するために、これらの装置は、可用性窓の間に送信される同期ビーコンに依存することができる。

一部の実施形態では、装置は、一部の（又は全ての）可用性窓の開始時に保護期間を実施することを要求され、この保護期間の間、それらの装置はリッスンして、通信を受信することはできるが、送信は行わない。種々の実施形態では、この制限は、定期的なＤＢを発行するマスターには常に適用される場合もあり、必ずしも適用されない場合もあるが、一般的には、非選択マスターには常に適用される。

図２は、一部の実施形態に係る、無線通信環境内のピアのクラスタ内部での、装置の同期及び動作を示す流れ図である。

動作２０２では、装置は、電源をオンにするか、又はクラスタの環境内に入り、発見ビーコン（ＤＢ）のために、１つ以上の所定のソーシャルチャネル上でリッスンを開始する。その装置には、ＤＢのデフォルトの周期性又は可能な周期性に関する情報をプログラムすることができ、それゆえ、所定のソーシャルチャネル上にマスターによって一斉配信されるＤＢを傍受するためには、限定数（例えば、１つ、２つ）のそれらの周期にわたって、その所定のソーシャルチャネル上でリッスンすることのみが必要とされる場合がある。

動作２０４では、装置は、１つ以上のＤＢを聴取して、提供される同期データを抽出する。図示の実施形態では、同じ装置クラスタ内部のマスターによって発行される全てのＤＢは、同じ可用性窓のシーケンス又はスケジュールをアドバタイズする。それらのマスターは、同じソーシャルチャネル又は異なるソーシャルチャネル上に、それらのＤＢを送信することができ、同じ非ソーシャルチャネル上で可用性窓を行うことができる。

装置が、いずれの発見ビーコンも聴取しなかった場合には、その装置は、範囲内にはマスターが存在しないと想定することができる。それゆえ、その装置は、ルートマスターの役割を担い、範囲内の他の装置を同期化するために、それ自体のＤＢの発行を開始することができる。

動作２０６では、装置は、その無線が別のアプリケーション又はサービスによって先に占有されていないと想定すると、その無線機を指定のチャネルに同調させ、次回の可用性窓に参加する。参加することができない場合には、その装置は、参加が可能な次の可用性窓に参加することになるが、次の同期データのセットを受信し、ランデブーチャネル及び開始時間を特定するために、再びソーシャルチャネル上でリッスンすることが必要とされる場合がある。装置は、次回の窓のシーケンスの開始まで、可用性窓に参加することを延期することにより、必要とされる次回の窓（通常は、シーケンス番号０を有する窓）に同調することができる。

動作２０８では、可用性窓の間に、その装置が現在同期化されているマスターによって、同期データを含むビーコン（例えば、ＤＢ又はＳＢ）が一斉配信される。このことにより、１つ以上のソーシャルチャネルを走査する必要性から装置を解放することができる。このビーコンは、例示的には、可用性窓の開始時の初期保護期間又は静穏期間の間に送信することができ、その期間中は、非マスター装置は送信することができない。

動作２１０では、装置は、必要な場合又は望ましい場合には（例えば、その装置が、可用性窓の全シーケンスには参加することができない場合には）、その装置の存在モードを設定する。少なくとも、その装置が参加する第１の可用性窓、及び／又はシーケンス番号０を有する第１の可用性窓の間に、その装置は、同期化される全ての装置に一斉配信されるメッセージ内で、その装置自体（例えば、アドレス、名称、サービス情報）を特定する。同時に、その装置は、その存在モードをアドバタイズすることができる。

任意選択的動作２１２では、装置は、可用性窓の間に、かつ／若しくは帯域外で、その同期化されたピアのうちの１つ以上と直接通信することができ、又はそれらのピアが、その装置と通信することもできる。上述のように、装置は、通信を促進するために、窓でのその装置の参加を１回以上延長することができ、その装置が（例えば、その無線機を何らかの他の目的で使用するために）その通常の終了の前に窓から退去しなければならない場合には、その装置のアクティブなピアにアドバタイズすることになり、また、１つ以上のピアとの（同じチャネル又は異なるチャネル上での）別個のランデブーを準備することができる。

一部の実施形態では、通信の輻輳及び衝突を低減するために、トラフィックの削減若しくは制限の処置を、一部又は全ての可用性窓の間に実施することができる。例示的には、可用性窓シーケンスを制御するマスターは、処置をどの時点に置くかを指定することができる。一部の実装では、トラフィック削減の処置は、可用性窓の間にのみ適用され、可用性窓の延長の間には適用されない。必須の可用性窓（すなわち、シーケンス番号０を有する可用性窓）内では、トラフィック削減の処置は、必須のものとすることができる。

例として、トラフィック削減の処置は、装置が１つの可用性窓の間に送信することができるマルチキャストフレームの数（例えば、約３つ）に関して、装置を制限するために役立ち得る。ユニキャストフレームの送信もまた、制限することができる。

例えば、ユニキャスト送信は、未知の存在モード値又は１（又は何らかの他の閾値）よりも大きい値を有する装置に対して（及び／又は、それらの装置から）のみ、許容することができる。ユニキャストフレーム又はマルチキャストフレームの送信に対する制限は、ファイル転送などの限定された目的のために、それら自体の間で（例えば、非選択マスターと）同期している装置には、適用することができない。

動作２１４では、装置は、ソーシャルチャネル上でＤＢをリッスンする必要がない場合、又は可用性窓に参加する必要がない場合、その無線機の電源をオフにすることができる。

図２に示す方法は、単なる例示であり、他の実施形態に係る方法を限定するものではない。

上述のように、２つ以上のピアは、いずれかの可用性窓の外で、又は可用性窓に加えて、それら自体の同期に従事することができる。例えば、それらのピアのうちの１つは、非選択マスターの役割を担い、可用性窓の間に、同期ビーコン又は他の発見ビーコンを発行して、その非選択マスターのピアに、それらのピアが、その非選択マスターといつどこで同期することができるか（すなわち、時間及びチャネル）について、報告することができる。

しかしながら、１つのピアが、同期することなく、別のピアとの短い通信の交換を望む場合がある。例えば、１つのクラスタ内部で同期化された装置が、異なる（例えば、近隣の）クラスタ内部で同期化されたピアによって提供されるサービスを発見することを望む場合があり、クラスタ装置が、近隣のピアにポーリングすることを望む場合があり、又は何らかの情報をそのマスターに通信することを望む場合などがある。少なくとも最初は、それらの装置は、重要な（例えば、ファイル転送と同様の）データ交換に従事することを目的とはしない。一部の実施形態は、帯域外の問い合わせ及び応答の形態で、この能力を提供する。

図３は、一部の実施形態に係る、ピア装置間の帯域外交換を示す図である。上述の発見ビーコンのタイミングと同様に、送信装置は、送信のための問い合わせを解放又は調製する時間と、その問い合わせが実際に送信される時間との間の、その装置自体の内部で生じる遅延を考慮しなければならない。

問い合わせタイムライン３１０は、問い合わせ装置でのアクティビティを反映し、その一方で、応答タイムライン３３０は、応答ピア装置でのアクティビティを反映する。問い合わせを発行する場合、問い合わせ装置は、応答装置が、その問い合わせを受信し、処理し、反応するための時間を有するように、好適な問い合わせ有効期間３５０を選択しなければならない。

この例示的な問い合わせ及び応答では、問い合わせは、目標送信時間３１２での問い合わせ装置からの送信のために、待ち行列に登録される。アンテナ又は媒体に対する競合、及び／又は他の遅延（図３では、競合３１４として一括して表される）のために、この問い合わせは、実際の送信時間３１６まで、物理的に送信されない。

滞留時間３１８は、その問い合わせ有効期間の残部であり、この間に、応答ピア装置は、問い合わせを受信し、その応答を生成して送信しなければならない。滞留時間３１８の持続時間は、問い合わせ装置によって設定された問い合わせ有効期間、及び競合３１４の持続時間に応じて決定される。応答機器もまた、その機器の目標送信時間４３２と実際の送信時間４３６との間の、応答の遅延を経験し得るものであり、この遅延は、競合４３４として表される。

問い合わせは、（帯域外の問い合わせでは）関連する時間パラメータ（例えば、問い合わせ有効期間、目標送信時間、実際の送信時間、競合）のうちの、いずれか又は全てを特定することができ、それにより、応答機器は、その問い合わせが満了する前に応答することが可能であるか否かを、判定することができる。可能ではない場合には、その装置は、問い合わせを取り下げるか、又はその応答を中止することができる。問い合わせ機器が、問い合わせ有効期間中に応答を受信しない場合には、その機器は、再試行するか（例えば、より長い有効期間で）、問い合わせを破棄するか、又は他の処置を取ることができる。

本発明の幾つかの実施形態では、ピア機器は、そのピア機器が聴取することはできるが、同期化されていない同期局に対して、その同期局及びその局に同期化されている機器によって提供されるサービスを特定するために、帯域外の問い合わせを発行することができる。一部の実装では、その装置は、その装置のマスター及び／又は同期化されたピアに対して、それらの可用性窓のうちの１つ以上の間などに、他のマスター（又は、別のクラスタ）に関する情報を中継することができる。明らかにすることが可能な、別のマスター、装置、又はクラスタについての情報としては、使用するソーシャルチャネル、その可用性窓のスケジュール（例えば、時間、チャネル、周期）、（平均の）発見ビーコン周期、マスターオフセット、提供するサービス、アドレスなどのものを挙げることができる。それゆえ、帯域外の問い合わせは、１つの装置と別の装置との同期を促進することが可能な点で、準ＤＢ又は準ＳＢとして機能することができる。

一部の非同期マスター（例えば、ピア装置が同期していない、マスター）は、低電力の動作モードを採用することができる。この低電力の動作モードは、その局の発見ビーコン内で示すことができ、あるいは、可用性窓のシーケンス若しくはスケジュール、及び／又は発見ビーコン内でアドバタイズされる存在モードによって、推定することができる。

１つのそのような動作モードでは、非同期マスターは、依然として発見ビーコンを送信することができるが、長い周期（例えば、複数秒）を有する短い可用性窓を提供する。この可用性窓の、短い、まばらな性質により、非同期マスターによって提供されるサービスをピアが発見するためには、ある程度の時間を要する場合がある。

一部の実施形態に係る、通信環境内でのピアの同期の間に、クラスタ内部のピア装置が同期ツリーへと編成される際、非マスター装置は、範囲内の同期マスターと同期し、それらの同期マスター（及び恐らくは、他の非マスター装置）は、より高位の同期マスターと同期する、などとなり、そのツリーの最上位の１つのアンカーマスターが、その環境全体に同期情報を提供する。非マスター装置は、アンカーマスターが範囲内に存在する場合には、そのアンカーマスターと直接同期することができる。

装置の動作パラメータは、そのクラスタの同期ツリーの最大深さを指定することができ、この最大深さは、マスターのレベル又は層の数として定義することができる。アンカーマスターの位置は、層ゼロとして定義され、同期マスターは、１〜Ｄで番号付けられた層内に存在することになり、Ｄは、マスターが存在することができる最大の層である。ツリーの深さは、Ｄとして（又は、非マスター装置を考慮するためにＤ＋１として）定義することができ、アンカーマスターと非マスター（例えば、リーフ）装置との間の最大ホップ数は、Ｄ＋１である。

デフォルトでは、クラスタが編成されている間、ピア装置は、非マスターとしての位置に落ち着くまで、発見ビーコンを発行することができ、その時点で、そのピア装置は、ビーコンの送信を停止する場合もあれば、停止しない場合もある。装置は、適用可能な選択アルゴリズムにより、通常であればその装置がマスターとなることが可能な場合であっても、その装置の範囲内にマスターが存在しない場合を除いて、非マスター装置となることを選択することができる。範囲内にマスターが存在しない場合には、その装置は、その役割を担わなければならない。

全てのマスターは、それらの区域内部の同期を維持するために、継続してＤＢを発行し、クラスタ内部でのそのマスターのレベルの関数、すなわち層の関数である周期性で、ＤＢを発行することができる。例えば、層０のアンカーマスターは、約１００ミリ秒ごとにＤＢを発行することができ、層１の同期マスターは、約１５０ｍｓごとにＤＢを発行することができ、層２の同期マスターは、５００ｍｓごとにＤＢを発行することができる、などである。これらの値は単なる例示であり、ＤＢ周期の持続時間を、決して限定又は制限するものではなく、異なる層内のマスターが、同じ周期を採用する場合もあり、同じ層内のマスターが、異なる周期を採用する場合もある。

マスターの層は、通常は、そのＤＢ内で報告される。この情報により、リッスンする装置は、そのクラスタのその装置の区域内部での、クラスタの深さを決定することが可能となる。その深さ及び／又は他の情報（例えば、ＤＢを発行しているマスターを、その装置が幾つ聴取することができるか、最大クラスタ深さ）に応じて、その装置は、その装置が非マスターとなるべきであるか、又は、継続してＤＢを発行して、マスターのまま留まるべきであるかを、決定することができる。

クラスタの最大深さパラメータは、装置内にプログラムすることができ、かつ／又は、発見ビーコン及び／若しくは他のビーコン内部でアドバタイズすることもできる。マスターの最大数、マスターは（例えば、特定の範囲内で、特定の層で、全体で）閾値数以下の他のマスターを聴取することができる間のみ、その役割を継続するという要件などの、他の制限も課すことができる。

例えば、クラスタの最大深さがＤである場合、層Ｓ≧１（すなわち、アンカーマスターの層を除く全ての層）に位置するマスターは、層Ｓ内でＤ−Ｓの他のマスターが動作していることを、聴取することのみが可能であり、（それらの他のマスターが、より高い又はより良好なマスター優先度値を有すると想定して）依然としてマスターとしての役割を果たし続けることができる。この規定は、アンカーマスターの近傍での、より高レベルの同期マスターの集中、及び、より遠く離れた同期マスターの拡散を可能にし得る。

一部の実施形態では、マスター選択アルゴリズム又はプロセスは、通常であれば優先度を与えられる別の装置よりも、現任のマスターを保持することを選択する場合があるが、ただし、その別の装置の選択優先度値が、現任の選択優先度値を閾値で超過する場合を除く。このことは、マスターのスラッシング又は過度の切り替えを回避するために役立ち得る。しかしながら、マスターの主要タスクは、単純に同期データを一斉配信することであるため、マスターの切り替えは、そのクラスタ又は個々の装置に対して、高いトランザクションコストを課すものではない。

一部の実施形態では、装置は、その装置が聴取可能な最良のマスター（すなわち、最も高い優先度値を有するマスター）、又は、その装置が所定の範囲内で聴取可能な最良の（例えば、特定の閾値を上回る信号強度を有する）マスターと同期することになる。

装置が環境内でオンラインになり、発見ビーコンをリッスンするとき、その装置が、クラスタの最深又は最大許容層の同期マスターからのみ聴取する場合には、その装置は、その局に非マスターとして同期することができる。しかしながら、その装置がまた、（例えば、発見ビーコン内でアドバタイズされるアンカーマスターの属性によって決定されるような）異なるクラスタ内の別のマスターも聴取することができる場合には、その装置は、その別のマスターが、最大の深さ若しくは層に存在しない場合、又は、その別のマスターが、より良好なマスター優先度値を有する場合には、そのクラスタに加入することを優先する場合がある。

クラスタ内の比較的深い（例えば、高い層の値の）他の装置を聴取することのみが可能な装置は、その装置が同期環境の周辺部に存在していると判定することが可能になり得る。他の装置の殆ど又は全てが、既に最大深さに存在している場合には、特に、高い優先度値を有する装置が現れる場合には、新たなクラスタが生成される可能性がある。

新たな環境／クラスタはまた、既存の１つが、過度に大きい空間的区域に広がる場合にも、生成される可能性がある。例えば、クラスタの深さの組み合わせ、どの程度ピア装置が近接しているかの尺度、及び／又は他の因子が、新たなクラスタを生成する原因となり得る。ピア間で検出される信号強度は、ピアの近接性を判定する１つの方法であり得る。

比較的近接するマスターとのみ同期するようにピアに要求することにより、そのクラスタを比較的コンパクトにさせることができる。対照的に、ツリーの最大深さに対する高い限定は、そのクラスタがより大きい区域を有効範囲とすることを可能にし得る。これら（及び／又は他のパラメータ）を調節することによって、好適なクラスタを形成することができる。

クラスタを構成するための種々のパラメータは、装置の密度、通信負荷、及び／又は他の因子に応じて、種々の環境に適合される。例えば、負荷が比較的軽い（例えば、装置が低電力センサである）場合には、隠れ端末問題に関連する欠点が限定されるはずであり、比較的深い（例えば、約１０〜１５のレベルの）クラスタを実施することができる。また、まばらな環境内では、マスターを選択するためのプロセスは、より迅速に解決される。

隠れ端末問題とは、互いの範囲内に存在しない複数の装置が、共通のピアと通信することを試みる場合のシナリオを指す。それらの装置は、互いの送信を聴取することができないため、それらの送信を回避することができず、それらの装置の、共通のピアに対する通信が衝突する恐れがある。このことは、比較的短い期間の間に（例えば、可用性窓の内部で）通信する必要性によって激化する場合があるが、軽負荷は、この問題を軽減する助けとなり、より重い負荷を有するより高密度の環境内で可能なクラスタよりも、深いクラスタを可能にし得る。

本明細書で説明される同期の方法を使用しない場合には、環境内の全ての装置を検出するために必要な、発見ビーコン又はフレームの総数は、装置の数の２乗に近づく可能性がある（すなわち、各装置は、他の全ての装置に、少なくとも１つのフレームを送信することが必要となる場合がある）。これらのフレームは、不規則な時間に、任意のチャネル上に送信される。

対照的に、一部の実施形態によって提供される集団同期は、装置（すなわち、マスター）の選択セットからの定期的な送信に基づく同期を可能にし、かつ良好に拡張される。完全な同期環境内では、全ての装置が互いを発見するために必要なフレームの数は、装置の数に比例する。シーケンス番号０を有する可用性窓の間に一斉配信される、１つの発見ビーコンは、範囲内の全ての他の装置に到達することになる。

協働的チャネル切り替え
一部の実施形態では、ピア装置は、データ転送又はデータ交換の動作を含む複数の競合する需要に基づいて、無線機を同調させるべきチャネルのシーケンスを計画又は調整する。例えば、前述のように、同期化されたピアツーピアネットワークの一部として、装置は、ランデブーチャネル上で１つ以上の可用性窓に参加するように要求される場合があり、１つ以上のソーシャルチャネル上で発見ビーコン（ＤＢ）を一斉配信又は受信することが必要とされる場合がある。他の装置機能もまた、アクセスポイントとの接続を維持するため、現在のチャネル以外の１つ以上のチャネルを走査するため、Ｂｌｕｅｔｏｏｔｈ（登録商標）動作をサポートするためなどに、共用アンテナの使用を必要とする場合がある。

共有の通信リソースに対する複数の需要に適応する伝統的方法は、通常、１つの機能から別の機能へと連続してリソースを認可することを伴う。これらの方法では、例えば、装置の、（例えば、データ転送のための）別の装置とのピアツーピア通信セッションは、別のエンティティとコンタクトを取るためのＢｌｕｅｔｏｏｔｈ（登録商標）要件に適応するために、中断される場合があり、次いで、そのピアツーピアセッションは、再開することが可能となるが、結果的に、発見ビーコンを捕捉するためにソーシャルチャネルに同調するための要件によって中断されることになり、次いで、データ転送動作に復帰して、次いで、周波数を変更してチャネル走査を行う、などとなる。

装置の無線機に関して競合する需要に適応する、これらの伝統的方法の１つの問題点は、装置によって行われているデータ転送動作のスループットが、損失を被ることになる点である。具体的には、無線機が通信相手から同調を離脱しなければならない場合は毎回、ある程度の期間にわたってデータ通信を休止しなければならない。

それゆえ、一部の実施形態では、ピア装置がその無線機を同調させることになるチャネルのシーケンスは、その装置が、１つ以上の競合する通信需要を満足させつつ、進行中のデータ交換又は他の通信を促進するように設計される。これらの実施形態では、１つ以上のピアとのデータ転送に従事しつつ、複数の機能又は動作間で通信リソース（例えば、無線、アンテナ）を共有しなければならない装置は、それらの需要に適応する周波数変更のシーケンスを考案して、それらのピアにスケジュールを報告し、その変更のシーケンスの間、可能な限りデータの交換を継続することになる。

各周波数変更は、所定の持続時間（例えば、６０ｍｓ、１００ｍｓ）を有し得るものであり、装置は、特定のチャネルへの（例えば、能動的又は受動的走査を行うため、ビーコン又は他の信号を発行するため、ビーコンを補足するための）同調に必要とされる作業負荷を満足させるために、その時間の一部分のみを必要とし得るものであり、そのチャネルへの同調に費やされた時間の残部に関しては、その装置は、周波数変更の一部又は全てに適応することが可能なピアと、データの転送を継続することができる。

一部の実施形態では、ピア装置のペアは、ファイルを転送するため、ゲームをプレイするため、サービスを発見するため、かつ／又は他の理由のために、データを交換するように講じることができる。このデータ交換をサポートするために、種々の実装では、その装置のペアは、それらの装置が同期化されたクラスタ内部で、プライベートグループを形成することができ、それらの装置の一方は、非選択マスターになることができ、その場合には、その非選択マスターに他方が同期することになり、それらの装置は、帯域外通信に従事することができ、又は何らかの他の形態の協働を行うことができる。

一部の実施形態を説明する目的のために、装置が同期化され、すなわち、一方が他方に同期しているか、又は、それらの装置の双方が、同じ階層クラスタ内部の１つ以上の同期局と同期化されているものと想定する。それらの装置は、グループ、又はグループの一部とすることができ、一方を非選択マスターとすることができ、又は、それらの装置は、何らかの他の形態の１対１の同期を実施しているものとすることができる。

それらの装置は、１つの階層の一部であるため、そのクラスタとの同期を維持するための共通のコミットメントを有し、このコミットメントは、これらの例示的実施形態では、指定されたチャネルに同調して、ＤＢを受信し、かつ／又は可用性窓に参加するように、それらの装置に要求する。例示の目的のため、それらの装置のそれぞれはまた、異なるアクセスポイント又は他のインフラストラクチャ装置に定期的にコンタクトを取るための、別個の要件も有する。

図４Ａは、一部の実施形態に係る、本明細書で説明されるピアツーピアネットワーク環境内での、データの転送に従事する２つのピア装置に関するチャネルシーケンスを示す。

この例示的シナリオでは、モデルシーケンス４１０は、１回の動作サイクル内で、装置がその無線通信リソースを専用に割り当てる機能のシーケンスを示す、テンプレートである。このシナリオでは、全サイクルは９６０ｍｓ持続し、それぞれが６０ｍｓの長さの、１６個のタイムスロットに分割される。それらの機能は、以下のように略される。

装置Ａ及び装置Ｂは、同じ階層内で（又は、互いに）同期化されているため、それらの装置は、同じソーシャルチャネル「Ｓ１」及び「Ｓ２」（チャネル６及びチャネル１１２）を使用する。上述のように、ソーシャルチャネルは、１つ以上のマスター局が発見ビーコンを一斉配信するチャネルである。それゆえ、ピア装置は、ＤＢを受信するためにソーシャルチャネルに同調することになる。例示的には、２つのソーシャルチャネルのうちの一方（例えば、Ｓ１）は、２．４ＧＨｚ帯域にあり、他方（例えば、Ｓ２）は、５ＧＨｚ帯域にあるものとすることができる。装置Ａ及び装置Ｂは、デュアルバンド装置であり、それゆえ、双方のチャネルを監視することができる。

データチャネル「Ｄ」は、装置Ａ及び装置Ｂが、それらのデータ交換を行うために使用するように、選択されたチャネルである。特定のチャネル（例えば、チャネル１５７）は、使用を試みるための、所定のチャネルのリストのうちの１つである場合があり、２つの装置のうちの一方が、そのチャネルを指定又はリクエストしている場合があり、そのチャネルは、ＤＢ若しくはＳＢ内で特定される場合があり、又は、何らかの他の方式で、選択若しくは指定されている場合がある。

インフラストラクチャチャネル「Ｉ」は、装置Ａ及び装置Ｂによって、それらの対応するアクセスポイント又は何らかの他のインフラストラクチャ構成要素とのコンタクトを維持するために使用される。モデルシーケンス４１０に示すように、各装置は、インフラストラクチャ接続をサポートするために、その無線機を周期的に使用しなければならない。それらの装置は、別個の基本サービスセット（ＢＳＳ）に関与していると想定されるため、各装置は、異なるインフラストラクチャコミットメント（すなわち、装置Ａに関してはチャネル３６、及び装置Ｂに関してはチャネル５）を有する。

チャネルシーケンス４３０、４５０は、それぞれ、装置Ａ及び装置Ｂによって実施される、チャネル切り換えのシーケンスを示し、モデルシーケンス４１０に従って構成されている。これらの装置は、同じスロットに関してデータチャネルの使用をスケジュールしており、それらのスロットを使用して、それらの装置のデータ交換を行うことになる点に留意されたい。

一部の実施形態では、チャネルシーケンス４３０、４５０は、マスターによって発行される可用性窓のスケジュールに適合する。例えば、チャネル１５７上でのデータ交換に関してスケジュールされたタイムスロットの一部又は全ては、そのチャネル上にスケジュールされた可用性窓に一致し得る。前述のセクションで説明されたように、可用性窓のシーケンスは、比較的長いもの（例えば、複数秒）にすることができ、装置は、全ての可用性窓に参加する必要はない。それゆえ、チャネルシーケンス４３０、４５０は、可用性窓と合致する、１つ以上のタイムスロットを含み得る。

一部の実施形態では、各装置は、そのピアの、チャネルシーケンスに関するスケジュールを知るものである。それゆえ、装置Ａ、Ｂのそれぞれは、他方の装置が、通信サイクルの第１、第３、第９、及び第１１のタイムスロットの間に、同じソーシャルチャネルに同調されることを知っている。更には、装置Ａ、Ｂのそれぞれは、他方の装置の存在モード値を知っているため、それらの装置は、いずれの可用性窓に他方の装置が参加するかを知っている。

一部の実装では、ＤＢの捕捉を許容することが意図されるタイムスロットの間、それらの装置は、ビーコンを受信した後、それらの装置のデータ交換を続行することができ、又は、これらのスロットの間、それらの装置のデータ交換を通常通り行って、ＤＢを送信するべきマスターが、そのチャネルの使用に関して、それらのピアと競合することを可能にし得る。しかしながら、更に他の実装では、ソーシャルチャネルタイムスロットの間は、それらのタイムスロット全体を、発見ビーコンの受信、及び／又は可用性窓への参加のために、専用に割り当てることができる。

図４Ａに示す通信動作のシーケンスでは、チャネル切り替えが必要とされるが、異なる通信機能間には、限定された競合のみが生じる。具体的には、各装置は、インフラストラクチャ接続を維持するためのコミットメントを有するが、これらの接続は、異なるチャネル上にあるため、日和見的なデータ交換を許容しない。しかしながら、これらのインフラストラクチャ要件は、同じタイムスロットの間にスケジュールされるため、双方の装置は、それらの要件を並行して満足させる。

各装置はまた、ピアツーピア通信環境にも関与するものであり、このことは、周期的にビーコンを捕捉し、かつ／又は他の行動を取る（例えば、可用性窓に参加する）ことを、それらの装置に要求する。最終的には、それらの装置は、インフラストラクチャ接続要件と直接衝突するデータ交換動作に従事し、この接続要件はまた、ピアツーピア同期要件とも衝突し得る。具体的には、ピアツーピアネットワークの同期要件は、日和見的データ交換を可能にし得るが、インフラストラクチャ要件は、日和見的データ交換を可能にし得ない。

図４Ｂは、装置の動作に対する更なる変更を示し、この場合、装置Ａは、複数の異なるチャネル、すなわちチャネル１、７、及びチャネル１１上で、走査を行う要件を有する。例示の目的のため、各走査は、１つのタイムスロット内で完了することができると想定される。これらの装置が、協働して、日和見的にそれらのデータ交換を継続しつつ、それらの装置の一方がチャネル走査を行う方式はまた、一方又は双方の装置が、その装置の複数の機能間で共有される通信リソースに関する、異なるタイプの需要を満足させなければならない場合にも、適用することができる。

伝統的なピアツーピア通信スキームでは、装置Ａ、Ｂ間のデータ交換は、装置Ａがチャネル１、７、及びチャネル１１に同調して、必要な走査を行う間は、一時停止される。図示の実装では、このことにより、データ交換のスループットが２５％削減される。それらの装置は、図４Ａのサイクルの１６個のタイムスロットのうちの１２個の間に、データを交換していたが、この場合、それらの１２個のタイムスロットのうちの３つは、不適合な機能のために使用される。

しかしながら、一部の実施形態によれば、装置Ａは、装置Ａの新たなチャネルシーケンス４７０を、その実施に先立って、装置Ｂに報告することになる。例えば、装置Ａは、シーケンス４７０を説明して（又は、シーケンス４３０からの、そのデルタを単に説明して）、いつそれが実施されるかを（例えば、次回の通信サイクルの開始時に）示すことができる。装置Ａは、装置Ｂに、それらの装置のデータ交換の過程で、この情報を伝達することができ、帯域外通信を行うことができ、可用性窓の間に、その新たなチャネルシーケンスを告知することができ、同期ビーコン（ＳＢ）を発行することなどができる。

この通知に応答して、装置Ｂは、そのチャネル切り替えの一部又は全てに適応することができるか否かを、判定することになる。可能な限り、装置Ｂは適応することになり、それらの装置は、それらのタイムスロットの間、その新たなチャネル上で、それらの装置のデータ交換を継続することになる。

一部の実施形態では、装置Ａは、共有される通信リソースに対する、競合する需要を満足させることによって引き起こされる、データ交換動作の中断を、図４Ｂに示すような単に１回のサイクルではなく、複数の通信サイクルにわたって、その需要を満足させることによって、最小限に抑えるように試みる。例えば、３つ全てのチャネル走査を、シーケンス４７０内に入れるのではなく、装置Ａは、その代わりに、３回の別個の通信サイクルのそれぞれの間に、３つの指定チャネル（すなわち、チャネル１、７、１１）のうちの１つで走査を行うことが可能であり、その３回の別個の通信サイクルは、連続的である場合もあれば、そうではない場合もある。このことは、チャネル走査の完了を遅延させることになるが、データ交換の中断を引き起こすことがより少ない。

これらの実施形態では、装置Ａは、３つのシーケンスの変更の全てを、事前に装置Ｂに通知するか、又は、一度に１つの変更を、装置Ｂに通知することが可能である。いずれの場合にも、装置Ｂは、装置Ａに随伴して、指定の時間に目標のチャネルに同調し、装置Ａがその走査を実行する間に、それらの装置のデータ交換を継続することができる。

同様に、装置Ａが、２つの連続的タイムスロットを必要とする受動的走査などの走査のために、２つ以上のタイムスロットを必要とする場合には、その装置Ａは、変更されたチャネルシーケンスをスケジュールして、装置Ｂに通知することになる。装置Ｂがその変更に適応することが可能な限り、装置Ｂは適応することになり、データ交換が継続することになる。

一部の実装では、ピア装置（例えば、装置Ａ）によって発行される発見ビーコン又は同期ビーコンは、例えば、他の装置が、その装置と通信する必要がある場合に、指定されたチャネルのシーケンス上で、その装置に加入するように他の装置を勧誘するために役立つ、「勧誘」フィールドを含み得る。この勧誘フィールドは、その発行ピア装置に加入するように勧誘される、１つ以上の特定のピア装置を特定することができ、又は、全てのピア装置への全般的な勧誘とすることもできる。

図５は、一部の実施形態に係る、チャネル交換のスケジュールを共有するピア装置のペアを示す。これらの実施形態では、双方の装置が、上述のように、インフラストラクチャ接続を維持し、かつ周期的にソーシャルチャネルに参加しなければならない。

しかしながら、これらの実施形態では、それらの装置のデータ交換を行うために、別個のチャネル（データチャネル）上で出会うのではなく、それらの装置は、それらのインフラストラクチャ要件に適応しつつデータを交換するために、それらの対応するインフラストラクチャのチャネル間を交互に行き来する。それゆえ、チャネルシーケンス５２０及びチャネルシーケンス５３０は同等であり、前述のような２つの異なるソーシャルチャネル、及びインフラストラクチャチャネル切り替えの交互パターンを伴う。

装置Ａ及び装置Ｂは、同じクラスタの一部である場合があり、この場合、それらの装置は、それらのデータ交換とは関わりなく、周期的にソーシャルチャネル１及びソーシャルチャネル２に同調する。あるいは、それらの装置のうちの一方のみが、それらのソーシャルチャネルを使用するクラスタの一部である場合があり、他方の装置は、その通信相手との日和見的データ交換を行うために、その同じチャネルに同調することができる。

図５に示す環境内では、データ転送は、インフラストラクチャ要件に適応するために一時停止しなければならないのではなく、１６スロットのスケジュールのうちの、１６個全てのタイムスロットの間に、データ転送を行うことができる。有利には、１つ以上の更なる装置が、このデータ交換に関与することが可能であり、それらの装置のそれぞれは、参加するべき更に異なるインフラストラクチャのチャネルを有し、それらのチャネルを、共通のスケジュールに組み込むことが可能である。

制限チャネル上でのピアツーピア通信
一部の実施形態では、１つ以上の制限チャネルを、（例えば、発見ビーコンを発行及び消費するための）ソーシャルチャネル、（例えば、可用性窓を行うための）ランデブーチャネル、（例えば、ピアツーピアデータ交換を行うための）データチャネル、及び／又は（例えば、アクセスポイントとのインフラストラクチャ接続を維持するための）インフラストラクチャチャネルとして採用することができる。チャネルの使用は、規制当局（例えば、連邦通信委員会、すなわちＦＣＣ）、無線周波数（ＲＦ）スペクトルの一部分を管理若しくは制御する機関によって、又は何らかの他のエンティティによって、制限される場合がある。

一部の実装では、制限チャネルは、優先的な若しくは特権的な信号エミッタ又は送受信機（例えば、気象レーダーシステム）をホストするものであり、そのチャネルの使用は、その優先的なソースに対して遅延処理されなければならない。例えば、装置は、優先的なソースによる制限チャネルの使用を検出した直後に、そのチャネルから退出するか、又は、少なくともそのチャネル上にある間は静穏状態に留まることを要求される場合があり、そのソースの検出を容易にするように（又は、少なくとも、そのソースを検出する能力を低下させないように）その装置の使用法を構成することを要求される場合がある。

ＤＦＳ（動的周波数選択）は、無線通信チャネルを選択及び変更するための１つのスキームであり、一部の状況で（例えば、一部のレーダーシステムによって使用される５ＧＨｚ周波数帯域の諸部分に関して）必要とされる。本セクションで説明されるピアツーピア通信方法の実施形態は、ＤＦＳを使用して、（例えば、レーダー回避のための）チャネルの制限を順守しつつ、ピア装置の通信要件を満足させるように構成される。

これらの実施形態では、２つのピア装置は、異なるインフラストラクチャ構成要素（例えば、アクセスポイント）に接続され、ファイル転送を行うか、メディアをストリーミングするか、ゲームをプレイするか、又は長期間の相互作用を必要とする何らかの他のアクティビティを実行するために、通信している（又は通信するように準備している）。それらのピア装置はまた、それらのインフラストラクチャチャネルも周期的に巡回しなければならない。

前述のセクションで説明されたように、ピア装置は、インフラストラクチャ要件を満足させ、発見のためにソーシャルチャネルを周期的に巡回しつつ、恐らくは日和見的協働を使用して、複数の異なるチャネル間でホップすることによって、それらのピア装置の通信を行うことができる。一般的には、固定長のタイムスロットが前述の説明で採用されており、このことは、装置が異なるチャネルにホップした場合は毎回、それらの装置が、固定長の期間にわたってそのチャネルに留まったことを意味する。しかしながら、ここでは、それらの装置はまた、１つ以上のチャネル上での制限にも適応しなければならず、このことにより、それらの装置の計画されたスケジュールが中断される可能性が高い。

一部の実施形態では、ピア装置のアクセスポイントの一方又は双方は、制限チャネルに同調された場合に、優先的な又は特権的な無線周波数信号（例えば、保護されたレーダーシステムの識別サイン）を検出することが可能な、ＤＦＳマスターであり、（そのピアなどの）ＤＦＳスレーブ装置に、そのチャネルから退出するか、又は静止状態となるように指令することになる。そのような指令を検出するピア装置は、その発行アクセスポイントが、そのピア装置の関連アクセスポイントではない場合であっても、その指令を順守することになる。双方のピア装置（又は、３つ以上が互いに通信している場合には、全ての装置）は、双方の（又は全ての）アクセスポイントの送信を聴取することが可能であり、それらのアクセスポイントから聴取する、いずれのチャネル切り替え告知にも黙従することになる。それゆえ、ピア装置は、その装置が関連付けされていないアクセスポイントによって執行される制限に従うように、要求される場合がある。

更には、本セクションで説明される実施形態は、制限チャネル上で優先的なＲＦ信号を検出する装置の確率、又は、制限チャネルから退出するか若しくは制限チャネルの使用を辞退する指令を検出する装置の確率が、対応するピアツーピア通信の方法を実施しない場合と同様に良好になることを保証する。ピアツーピア通信は、本質的に、ＤＦＳマスターとは無関係に（かつＤＦＳマスターによって知られることなく）実施されるため、ＤＦＳマスターは、それらの通信に影響を及ぼすことも、それらの通信を形成することもできない。それゆえ、ピアツーピア通信が既存のＤＦＳ回避手順に干渉しないように保証することが、重要になり得る。以下で論じられるように、このことは、チャネルのホップのインテリジェントなスケジューリング、及び、制限ＤＦＳチャネル上の特定の時間での静穏期間の実施を伴い得る。

図６は、一部の実施形態に係る、２つの無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。これらの実施形態は、非制限チャネル上で、どのようにピアツーピア通信を行うことができるかを示すものであり、次いで、１つ以上の制限チャネル上でピア通信を行う方法が説明され、その制限に対して遅延処理されるように、どのようにピアツーピア通信スキームを修正することができるかを例示する。

図６に反映される実施形態では、２つ以上のピア装置が、チャネルホッピングを行いつつ通信している。例示的には、これらの装置の一方は、スマートフォン（例えば、ｉＰｈｏｎｅ（登録商標））とすることができ、他方は、メディア装置（例えば、Ａｐｐｌｅ ＴＶ（登録商標））とすることができ、このメディア装置は、ＡｉｒＰｌａｙ（登録商標）、又はピアツーピア通信プロトコルに適合する何らかの他のメディアストリーミングプログラムを使用して、スマートフォンに（又は、スマートフォンから）メディアをストリーミングしている。これらの装置のチャネルホッピングは、図６では２つのチャネルに限定されるが、説明される方法は、３つ以上のチャネル間でのホッピングに関して容易に修正される。

図６では、チャネル１及びチャネル２は、別個の異なる基本サービスセット（ＢＳＳ）のマスターであるアクセスポイント（ＡＰ）によって占有される。具体的には、アクセスポイント１（すなわちＡＰ１）は、チャネル１上で動作し、ピア装置の一方を含む第１のＢＳＳのマスターであり、アクセスポイント２（すなわちＡＰ２）は、チャネル２上で動作し、他方の装置（又は、３つ以上のピア装置が通信している場合には、他の装置のうちの１つ）を含む第２のＢＳＳのマスターである。

双方のアクセスポイントは、ほぼ１００ｍｓの持続時間であるが整合しない定期的な間隔で、ビーコンフレーム（又はビーコン）を発行する。例えば、ＡＰ１のビーコン間隔は、約１０２．４ｍｓとすることができ、その一方で、ＡＰ２のビーコン間隔は、約１０４ｍｓとすることができる。それゆえ、ビーコンフレームは、２つのチャネル上で同期されない。

前述のように、ピア装置は、チャネル１とチャネル２との間で同期的にホップして、それらのインフラストラクチャ接続要件を満足させつつ、通信を継続することができる。図６では、これらの装置は、２つの等しいサイズのタイムスロット（１２８ｍｓ）に分割される、２５６ｍｓのチャネルホッピングシーケンスを採用し、このシーケンスの間に、それらの装置は、その２つの別個のチャネル上に滞留する。これらのタイムスロットは、いずれのアクセスポイントのビーコン間隔とも同期せず、それゆえ、ＡＰの目標ビーコン送信時間（ＴＢＴＴ）から可変オフセットで発生することになる。

ピア装置のうちの１つが、非選択マスターとして（又は、通信中のピアを包含するプライベートグループのマスターとして）機能していると想定すると、その装置は、その装置のＡＰのビーコン、又はその装置が同期化されている正規のクラスタマスター（例えば、アンカーマスター、ブランチマスター）のビーコンと同期するように試みることができるが、他のピア装置は、必然的に、その１つのピア装置に同期することになる。

チャネル１又はチャネル２のいずれも制限されていないため、ピア装置は、それらのデータ転送を行う必要がある間は、固定長のタイムスロットで、それらのピア装置の固定スケジュールのチャネルホッピングを継続することができる。それらのピア装置は、各チャネルに順序正しく切り換えるため、最小限のレイテンシで、直ちにそれらの転送を開始又は再開することができ、他方のチャネルに切り換える時間になるまで、その転送を継続することができる。現在のチャネルのＡＰによって発行されるビーコンは、それらの短い長さにより、そのチャネルをめぐって容易に競合することができ、ピアがＡＰのビーコンに踏み込む可能性があるが、ビーコン又は装置のデータ転送のいずれも、互いを考慮することに依存することも、又は必要とすることもない。

しかしながら、ピアツーピア通信のためにピア装置によって採用されるチャネルの一方が、ＤＦＳチャネルである場合、又は双方がＤＦＳチャネルである場合には、図６のチャネルホッピングスキームは、制限に違反する危険性がある。例えば、チャネル１がＤＦＳチャネルであり、ピア装置がチャネル２に同調されている間に、（ＤＦＳマスターとして機能する）ＡＰ１が、チャネル切り替え告知エレメントを有するビーコンを発行した場合には、それらのピアは、そのチャネル切り替え告知を受信することなく、チャネル１に戻ると直ちに、それらのデータ転送を再開することになる。このことは、それらのピアが従うことを要求されるチャネル切り替え告知が、ＤＦＳマスターによってチャネル１上に発行された後も、それらのピアが、チャネル１上でデータフレームを送信することになるため、ＤＦＳ要件／制限に違反することになる。

更には、制限チャネル上で継続するピアツーピアデータ転送により、ピア装置は、チャネル切り替え告知を報告する１つ以上のビーコンを取り逃す恐れがある。具体的には、それらのピアツーピア通信は、チャネル切り替え告知と衝突するか、又は遅延させる恐れがある。それゆえ、第１のチャネル切り替え告知が実施されたとき、それらのピア装置がチャネル１に同調されていた（かつ、ピアツーピア通信に従事していた）場合であっても、それらのピア装置は、その告知を取り逃がして、保護された信号に対して遅延処理することができない恐れがある。

それゆえ、１つ以上のＤＦＳチャネルが、ピアツーピア通信のために装置によって使用されるチャネルホッピングシーケンス内に含まれる、一部の実施形態では、１つ以上の予防措置が実施される。

１つの予防措置は、ピア装置がＤＦＳチャネルに切り替わる場合に、そのチャネルに関連付けられるＡＰ又はＤＦＳマスターからのビーコン、あるいは、そのチャネルが制限を免除されているか否かを示す、何らかの他の好適な管理フレーム又はアクションフレームを受信するまで、静止状態に留まるように、ピア装置に要求する。それらの装置はまた、ビーコンとの衝突を回避するために、ＡＰのＴＢＴＴの前後も、恐らくは合計５〜１０ｍｓにわたって、静穏状態となる。

これらの装置によって受信されたビーコン又は他のフレームが、そのチャネルに制限がないことを示す（例えば、チャネル切り替え告知エレメントを含まない）場合、又はＴＢＴＴの時間近くでビーコンが受信されない場合、また装置のピアツーピア通信が、チャネル切り替え告知を首尾よく受信する確率を低下させないことを保証するための予防措置（例えば、ＴＢＴＴの前後の静穏期間）が整っている場合には、それらの装置は、それらのピアツーピアデータ転送を開始又は再開することができる。

このスキームを補完するために、ピア装置が、それらのチャネルホッピングシーケンス内に、制限ＤＦＳチャネルを含む場合、それらのピア装置は、そのＤＦＳチャネルに関連付けられたＡＰのＴＢＴＴに、そのシーケンスを整合させることができる。複数のＤＦＳチャネルが使用される場合には、それらのピア装置は、全てのチャネル上のＴＢＴＴと整合する（又は、整合するように試みる）ことができる。論じられるように、異なるＡＰのＴＢＴＴは互いにずれ込むため、このことは、図６に示すような固定サイズのタイムスロットの代わりに、動的にサイズ決定される通信タイムスロットを必要とし得る。

図７Ａは、一部の実施形態に係る、一方が制限チャネルである２つの無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。これらの実施形態では、チャネル１は、制限ＤＦＳチャネルであり、それゆえ、ピア装置は、それらのチャネルシーケンス周期を、アクセスポイント１（ＡＰ１）のビーコン間隔の倍数に整合させる。この実施例では、チャネルシーケンス周期は、ビーコン間隔の長さの３倍、すなわち、３０７．２ｍｓ（又は、３００ＴＵ）である。他の実装では、他の倍数（例えば、包括的に１〜４）を使用することができる。種々の倍数により、種々のＴＢＴＴ、又は複数のチャネル上の種々のＴＢＴＴの組み合わせと整合するための、ピアの必要性を容易にすることができる。

ＡＰ１のビーコン間隔とＡＰ２のビーコン間隔とは同期していないため、ピア装置のチャネルシーケンス周期、及び、それらのピア装置がチャネル２上で費やすタイムスロットは、ＡＰ２のＴＢＴＴと整合することがない。しかしながら、チャネル２は制限チャネルではないため、それらの装置は、そのチャネル上の別の信号源に対して遅延処理される必要がなく、その代わりに、それらの装置がチャネル２に切り替わると、それらのデータ転送を直ちに開始／再開することができる。

しかしながら、スケジュールされたビーコンフレームの時間近くでチャネル１に切り替わる場合は毎回、それらの装置は、ビーコンを捕捉するために、約５〜１０ｍｓの静穏期間を順守する。一部の実装では、チャネルホッピングシーケンスは、それらの装置が、ＡＰ１のＴＢＴＴの少し（例えば、１〜３ｍｓ）前に、その制限チャネルに切り替わるように構成される。

図７Ａに示す同期的チャネルホッピングは、全てのデータ転送タイムスロットが、チャネルホッピング基準周期の２分の１にほぼ等しくなるように構成される。しかしながら、他の実装では、これらのタイムスロットは、異なるサイズのものにすることができる。

例えば、通信は、チャネル２上でより効率的であり得るため、チャネル１上のタイムスロットを、チャネル２上のタイムスロットよりも短くすることができる。ＡＰ１のビーコン間隔の３倍のチャネルホッピング周期の場合であっても、それらの装置が、スケジュールに従ってチャネル１に戻る限りは、チャネル１上のタイムスロットを、ビーコン間隔よりも小さくすることができる。反対に、チャネル１が、チャネル２よりも輻輳が少ない場合には、例えば、チャネル１上のタイムスロットを、チャネル２上のタイムスロットよりも顕著に長くすることができる。

上記で示したように、ピア装置は、ＡＰ１のＴＢＴＴの時間近くでチャネル１に切り替わる場合にのみ休止するのではなく、それらのピア装置がチャネル１上にあり（かつアクティブに通信中であり）、ＴＢＴＴが近づく場合も常に、休止することになる。ビーコン又は他のフレームが、そのチャネルに制限がないことを示す場合、又はビーコンが受信されない場合には、データ転送を再開することができる。そのチャネルに制限がある場合には、それらのピア装置は、チャネル１上で、それらの転送を再開することができない。この場合、それらのピア装置は、より多くの時間をチャネル２上で費やすように、チャネルホッピングシーケンスを変更することができるが、周期的（例えば、３つごとのＴＢＴＴ）にチャネル１に戻り、そのチャネルが解放状態になっているか否かを判定するか、又は、チャネル１が利用可能になるときを検出することが可能な状態なまま、それらのデータ転送を継続するように、他の措置を取る。

図７Ｂは、一部の実施形態に係る、２つの制限無線チャネル上での、ピアツーピアチャネルホッピング通信を示す。これらの実施形態では、ピア装置は、それらのホップをチャネル２に整合させて、ＡＰ２の目標ビーコン送信時間と合致させることにより、チャネル切り替え告知（及び／又は他の制限メッセージ）は、双方のチャネル上で捕捉されることになり、不正な送信を回避することができる。

図７Ｂに反映される実施形態では、全てのチャネル切り替えは、行き先チャネルのＴＢＴＴと整合され、静穏期間は、全てのＴＢＴＴの前後で順守される。それゆえ、制限メッセージ（例えば、チャネル切り替え告知を有するビーコン）を検出する可能性は、これらのチャネル上で、それらの装置がピアツーピアで通信していない場合の可能性に劣るものではない。

これらの実施形態では、異なるビーコン間隔に適応するためだけではなく、ＡＰ間でのずれ込みを考慮するためにも、切り替え時間の計算は動的である。最小滞留時間が、一方のチャネル、双方のチャネルで実施される場合があり、又はいずれのチャネルでも実施されない場合がある（例えば、ほぼ１つのビーコン間隔）。チャネルホッピング基準周期は、ＡＰ１のビーコン間隔の３倍（すなわち、図７Ａ及び図７Ｂでは、Ｎ＝３）であるため、また双方のビーコン間隔は、持続時間が極めて近いため、これらの装置は、各チャネル上で、少なくともビーコン間隔の全体にわたって滞留することができ、それゆえ、各チャネルホッピング周期の間に、各チャネル上で少なくとも１つのビーコンを、ほぼ確実に捕捉することになる。

図７Ｂの実施形態で、いつ他方のチャネルに切り替えるべきかを決定するために、ピア装置は、各チャネル上で捕捉される最新のビーコンの時間を記録し、その時間を使用して、その同じチャネル上での今後のＴＢＴＴを計算する。これらの値は、そのチャネルを離脱して切り替わった後に、いつそのチャネルに切り替わって戻るべきかを決定するために、使用されることになる。このことの一実施例を、図７Ｂを参照して説明する。

ピア装置は、既にチャネル１のＴＢＴＴを追跡しているため、それらのピア装置は、各チャネルホッピング周期が、いつ開始／終了するか、及び、それらのピア装置が、いつ（例えば、時間ｔ₂に）チャネル１に切り替わって戻らなければならないかを知っている。その一方で、チャネル２上での先行のタイムスロットの間に、それらの装置は、チャネル２上にビーコンが発行される時間ｔ₁に注目する。それらの装置は、チャネル２のビーコン間隔（すなわち、１０４ｍｓ）を知っているため、それらの装置は、それゆえ、１つ以上の今後の（例えば、次の２つ又は３つの）ＡＰ２のＴＢＴＴを計算することができる。

これらの時間は、時間ｔ₂と共に考察される場合、それらの装置が、チャネル２に戻るべき正確又は適切な時間ｔ₃を特定することを可能にする。例示的には、それらの装置は、チャネル２に戻るべき時間として、ｔ₂に続くデフォルト又は最小の期間の後に発生する、最初のＴＢＴＴを選択することができ、そのため、それらの装置は、少なくとも１つのＴＢＴＴを捕捉するための十分な期間にわたって、チャネル１上に滞留することになる。例示的には、この期間は、そのチャネルのビーコン間隔、１００ｍｓなどの固定値などによって、決定することができる。上述のように、チャネル切り替えは、実際には、行き先チャネルのＴＢＴＴの若干前に発生し得る。

それらのチャネルホップの順序及び持続時間とは関わりなく、図８のデータ転送に関与するピア装置は、２〜３秒又は数秒ごとに、ＡＰ１及びＡＰ２のそれぞれから、少なくとも１つのビーコンを受信することを保証するために十分な時間を、チャネル１及びチャネル２上で費やす。典型的な装置（例えば、Ｗｉ−Ｆｉ（登録商標）及び／又はＢｌｕｅｔｏｏｔｈ（登録商標）能力を有する装置）に関するクロックは、それらの公称値から約＋／−２０ｐｐｍの精度を特徴とするため、アクセスポイントのビーコン送信クロックを追跡すること、及び、数百マイクロ秒の範囲内の精度で、今後のＴＢＴＴを確実に予測することは、それらの装置にとっては非常に容易である。

制限ＤＦＳチャネル上でのデータ転送周期は、図７Ａ及び図７Ｂでは、中断されないボックスとして示されるが、ＡＰ又はＤＦＳマスターのＴＢＴＴを含む各周期の間に実施されるデータ転送は、説明されているように、ＴＢＴＴの前後で一時停止することになる点が、理解されるであろう。

一部の実施形態では、１つ以上の制限通信チャネル上でピアツーピア通信を行う、一部又は全ての装置は、ソーシャルチャネル（例えば、それらのピア装置を含むクラスタを同期化するために使用されている別個のチャネル）上で時間を費やすことも要求される場合がある。例示的には、装置は、発見ビーコン（又は同期ビーコン）を送信又は受信するために、あるいは（可用性窓がソーシャルチャネル上で行われると想定して）可用性窓に参加するために、ソーシャルチャネルに同調することが必要となる場合がある。可用性窓がソーシャルチャネル上で行われない場合には、装置はまた、少なくとも、その装置の存在値によって示されるものと同数の可用性窓に参加するために、周期的にランデブーチャネルに同調することを要求される場合もある。

これらの要件に応対することは、装置の直接的なピアツーピア通信スキームから、膨大な時間を奪うものではない。例えば、定期的にスケジュールされた発見ビーコンを捕捉することは、１５０ｍｓごとに約５〜１５ｍｓを必要とし得るが、その一方で、可用性窓に参加することは、１秒又は２秒ごとに約１００〜１２０ｍｓを必要とし得る。

現在論じられている実施形態では、ソーシャルチャネルは、決して制限チャネルではない。それゆえ、ピア装置は、任意の時間にソーシャルチャネルに同調することができ、このことは、ソーシャルチャネルへの参加が、何らかの他のチャネル（例えば、その装置がピアツーピア通信を行っている制限ＤＦＳチャネル）上のアクセスポイントのビーコン間隔と同期化され得ることを意味する。しかしながら、装置がソーシャルチャネルを撤退すると、その装置は、制限チャネルに同調する可能性があり、その場合には、その切り替えの時間は任意ではない（すなわち、その切り替えが、制限チャネルのＴＢＴＴに整合される場合があるため）。

図８は、一部の実施形態に係る、ソーシャルチャネル及び１つ以上の制限チャネル間での、ピアツーピアチャネルホッピング通信を示す。

これらの実施形態は、基準チャネルホッピング周期が、制限チャネルのアクセスポイントのビーコン間隔から計算される点で、図７Ｂに示す実施形態と同様であると見なすことができる。図８では、図７Ｂと同様に、基準チャネルホッピング周期は、ＡＰ１のビーコン間隔の３倍であるが、他の実施形態では、他の基準周期を採用することもできる。ピア装置のうちの１つとすることができるクラスタマスター（例えば、アンカーマスター、ブランチマスター）は、約１５０ｍｓの平均周期で、ソーシャルチャネル上に発見ビーコン（又は、他のビーコン）を発行する。

ピア装置は、各周期の開始時にチャネル１に戻ること、全ての制限チャネルへのホップを、それらのチャネル上のＴＢＴＴと同期化すること、それらのピア装置の存在値に従って可用性窓に参加すること（ピア装置は、同じ優先度値を採用して、それらのピア装置が全てのチャネル切り替えを同期化することを支援することができる）、及びソーシャルチャネル上で可能な限り多くのビーコンを発行／捕獲することを含めた、様々な目的を満足させるために、各タイムスロットの長さを動的に計算することになる。

それゆえ、各タイムスロットの間に、それらの装置は、１つ以上の今後のチャネル切り替えを計算することができ、上記に列挙した（及び／又は他の）目的のうちのいずれの優先度も、チャネル選択に影響を及ぼし得る。ソーシャルチャネルを離脱するあらゆる切り替えは、（図８の実施形態では）制限チャネルに対するものとなるため、ソーシャルチャネル上のタイムスロットの終了は、任意ではない。

一部の実施形態では、可用性窓に参加すること、又は、少なくとも各可用性窓シーケンスの可用性窓番号０での参加は、殆どの他の目的、又は更に全ての他の目的よりも優先度を有し得る。前述のセクションで説明されたように、全ての同期化されたピア装置は、この可用性窓に参加しなければならず、そうすることによって、それらのピア装置は、同期を維持し、現在のスケジューリング情報を取得することができる。

これらの実施形態では、チャネル切り替えは、それらのピアが、少なくとも、それらの優先度値によって命じられる、それらの可用性窓に参加することを保証するように、スケジュールされることになる。有利には、図８のチャネルホッピングデータ転送に関与するピアのうちの１つが、可用性窓のスケジュールの設定に関与するアンカーマスターである場合には、その装置は、その可用性窓を、１つ以上の他の目的で同期させることができる。

図８では、チャネル１上でのデータ転送８１０ａは、それらの装置が、ソーシャルチャネルに同調し、ビーコンを発行／受信し、次いでＡＰ２のＴＢＴＴの直前にチャネル２に切り替わることが可能となるように選択された時間に終了する。チャネル２上でのデータ転送８２０ａは、次回のソーシャルチャネルのビーコンの直前に終了するように時間設定されることにより、それらの装置は、そのビーコンのためにソーシャルチャネルに切り替えることができ、次いで、次のチャネルホッピングシーケンスの開始時に、データ転送８１０ｂのためにチャネル１に戻ることができる。

データ転送８１０ｂの後、それらの装置は、ソーシャルチャネルに同調して可用性窓８３０ａに参加し、その間に、同期ビーコンを（例えば、発見ビーコンの代わりに）送信することができる。可用性窓の後、それらの装置は、次の周期のためにチャネル１に戻り、その周期は、データ転送８１０ｃで開始して、その後に別のソーシャルチャネルビーコンへと続き、次いで、別のデータ転送スロットのためにチャネル２に切り替わる。

前述のセクションで論じられたように、ソーシャルチャネル上に発行される発見ビーコンは、厳格な周期的スケジュールを順守する必要はない。それゆえ、図８でソーシャルチャネル上に発行されるビーコンが、データ転送に関与しているピアのうちの１つによって送信されている場合には、それらのビーコンは、少なくとも閾値密度を提供するように、柔軟かつ動的にスケジュールすることができる。例えば、チャネルホッピングシーケンスは、図８のように、新たなチャネルホッピングシーケンスのそれぞれの前に（すなわち、チャネル１に戻る直前に）、ソーシャルチャネル上に発見ビーコンを送信するように設計することができる。更なる発見ビーコンを、チャネル２へのホップ、又はチャネル２からのホップの時間近くで発生するように、日和見的にスケジュールすることができる。

一部の実施形態では、ソーシャルチャネルのビーコンに適応するようにスケジュールされる（かつ、可用性窓に適応するのではない）、ソーシャルチャネル上のタイムスロットは、ビーコンの時間の数ミリ秒前にチャネルに同調して、ビーコンを送信又は受信し、数ミリ秒以上滞留して、次いで退出するために十分な長さである、約１０ｍｓとすることができる。可用性窓に適応するようにスケジュールされる、ソーシャルチャネルのタイムスロットは、より長いものであり、それらの装置が可用性窓に参加しなければならない最小時間量、及び／又は他の因子に応じて決定され、約１５０ｍｓ〜２００ｍｓとすることができる。

チャネル２が制限チャネルではない場合には、チャネル２へのホップは、ＡＰ２のＴＢＴＴに同期化される必要がなく、任意にスケジュールすることが可能である。チャネルホッピングシーケンス内に、非制限（かつ非ソーシャル）チャネルを有することにより、一部の状況で、装置のデータ転送の効率又はスループットを向上させることができる。例えば、ＡＰ１及びＡＰ２のＴＢＴＴは、それらの異なるビーコン間隔により、完全に同期化することはできないが、それらが互いに近い時間で発生し、かつソーシャルチャネルのビーコンが、それら２つのＡＰのビーコン間隔の中間点付近で発生するようにスケジュールされる、時間が存在する。

図８の実施形態（すなわち、双方のデータチャネルが制限されている場合）では、このシナリオは、ソーシャルチャネルのビーコンをスキップすることを要求する場合があるが、これは、それらの装置が、そのビーコンのためにソーシャルチャネルに同調した場合には、次のＴＢＴＴまで、数十ミリ秒にわたり、切り替わって戻ることができないためである。しかしながら、非制限チャネルの場合には、それらの装置は、ビーコンのためにソーシャルチャネルに切り替わり、次いで、非制限チャネルに切り替えて、それらのデータ転送を継続することが可能である。あるいは、当然ながら、それらのピア装置は、ＴＢＴＴの時間近くで制限チャネルに戻ることが可能になるまで、ソーシャルチャネル上で日和見的データ転送を実行することも可能である。

ピア装置
図９は、一部の実施形態に係る、ピア通信装置のブロック図である。２つの主要なプロトコル層又は演算層である、論理リンク層及びデータリンク層が、装置９００内部に示される。論理リンク層の上位で、１つ以上のアプリケーション及び／又はユーティリティ（例えば、ｍＤＮＳ、Ｂｏｎｊｏｕｒ（登録商標））が動作することができ、データリンク層の下位には、物理層が存在して、伝送媒体を介したフレームの送信、及び伝送媒体からのフレームの受信に関与する。

一部の実施形態では、論理リンク層及びデータリンク層は、別個のプロセッサによって、又は単一の構成要素上に存在する集積回路によって、物理的に実装することができる。とりわけ、プロセッサ、メモリ、ディスプレイ、アンテナ、及び通信ポートの構成要素などの、装置９００の一部の構成要素は、明瞭性のために省略されている。

データリンク層内部で、同期フレーム（例えば、発見ビーコン、すなわちＤＢ、同期ビーコン、すなわちＳＢ）が、同期ステートマシン９１０によって発行され、かつ／又は受信される。着信した同期フレームは、マスターデータベース９２０にルーティングされ、次いで、論理リンク層へと上方に伝達される。データフレームは、パケット待ち行列９２２によって処理される。

同期ステートマシン９１０は、マスター及び非マスターの、２つのモードを有し、一部の実装では継続的に動作する。前述のように、マスター装置は、装置の同期を促進するために発見ビーコンを発行する装置であり、その一方で、非マスター装置は、何らかのタイプのビーコンを発行することができ、その装置と同期するように他の装置に請求する場合もあれば、請求しない場合もある。

同期ステートマシンは、ピア装置の、その現在のマスターへの同期に関与する。装置９００がマスターである場合には、ステートマシン９１０は、その装置の発見ビーコン及び／又は同期ビーコンの送信を管理し、また、その装置の可用性窓の存在も管理する。同期ステートマシン９１０はまた、装置９００が、別の装置とのデータ転送に従事しつつ、複数のチャネル間でホップしている場合などの、滞留時間及び切り替え時間の計算にも関与し得る。

走査ステートマシン９１２は、ビーコンに関してソーシャルチャネルを走査する。無線チャネルマネージャ９１４は、他のエンティティ（例えば、インフラストラクチャのモジュール）と共に、異なる無線機（例えば、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標））間で、無線リソース（例えば、共用アンテナ）を管理する。同期ステートマシン９１０は、無線チャネルマネージャ９１４と相互作用して、可用性窓、データ転送のために、ビーコンを捕捉するために、かつ／又は他の目的のために、その装置の無線機を、適切な時間に正しいチャネルに切り替える。走査ステートマシン９１２、及び／又は装置９００の他の構成要素は、他の目的（例えば、新たな装置に関してチャネルを走査すること）のために、無線チャネルマネージャと相互作用することができる。

ピアキャッシュ９１６は、ホストのピア装置９００が通信しているか、又は通信しようとしている、限定数の他の装置の、関連情報を記憶する。このキャッシュの使用は、一部のハードウェア／ファームウェア実装での、メモリの制限に関連する問題を軽減するために役立ち得る。例えば、データリンク層は、典型的には大きいメモリバンクへのアクセスを有さない、専用のＷｉ−Ｆｉチップセットによって実装される場合がある。ピアキャッシュ９１６内の情報は、ピアデータベース９３６内の情報と同期化される。

マスター選択コード９１８は、ピアデータベース９３６からの情報、及び／又は他の情報を使用して、マスター装置を選択又は特定するための選択プロセスを実行するために、周期的に実行される。例えば、このコードの実行により、マスターとなるための装置の好適性に基づいて、マスターデータベース９２０内に、装置のランク付けを生じさせることができる。

マスターデータベース９２０は、ピア装置９００が認識する全てのマスターに関するデータを記憶する。そのようなデータは、同期及び／又はマスター選択のために使用することができ、そのようなデータとしては、（例えば、最新のフレーム、複数のフレームの平均、最小、最大の）ＲＳＳＩ（受信信号強度表示）、マスター優先度値、マスター優先度値を算出するために使用される選択メトリック、クラスタのサイズ、及び同期パラメータを挙げることができるが、これらに限定されない。

一部の実施形態では、毎回の発見ビーコンの受信時に、マスターデータベース９２０には、データが追加投入されるか、又は更新され、マスター選択コード９１８が実行される。

データリンク層のパケット待ち行列９２２は、着信データフレーム及び／又は発信データフレームを記憶する。論理リンク層のパケット待ち行列９３２は、他の装置から着信するピアトラフィック、及び他の装置へと発信されるピアトラフィックを記憶する。

パケットスケジューラ９３０は、同期化された装置への、マルチキャスト、ブロードキャスト、及びユニキャストのトラフィック、並びに、そのピアが同期化されていないマスター（「非同期マスター」）及び非同期マスターと同期化されている装置への、帯域外の問い合わせ／応答をスケジュールする。このパケットスケジューラはまた、装置９００が（例えば、その装置の無線機に関して競合する需要を満足させるために、データ転送を行うために）切り替える、チャネルのシーケンスを選択することにも関与し得る。あるいは、任意選択的なチャネルシーケンス制御部９４０などの、別個の構成要素を実装して、その装置に関するチャネルのシーケンスを特定することもできる。

ピアデータベース９３６は、非同期マスターの可用性窓、存在モードに関する情報、及び他のタイミング関連の情報を記憶する。存在モードマネージャ９３４は、因子に基づいて、ピア装置の存在モードを制御し、それらの因子としては、同期化された装置への現在のアクティブなデータリンク、それらの装置への現在のデータレート、走査要件、要件、電力管理状態、Ｂｌｕｅｔｏｏｔｈ（登録商標）要件、他の無線要件などを挙げることができるが、これらに限定されない。

ピアデータベース９３６は、ピア装置９００に既知の、全ての装置を特定し、各装置に関する情報を記憶する。この情報としては、その装置の識別情報（例えば、ネットワークアドレス）、その装置のアンカーマスターの識別情報、マスター優先度値、能力（例えば、サポートされる周波数帯域、チャネル帯域幅、変調／データレート）、存在モード、その装置によってサポートされるサービス、未解決のブロックＡＣＫ合意などを挙げることができるが、これらに限定されない。ピアデータベース９３６は、それゆえ、優先度値及び／又は他の判定基準によって順序付けすることができる候補装置のリストを提供することによって、マスター選択プロセスを支援することができる。

アプリケーションインターフェース９３８は、より高位のシステム層及びモジュールに対するインターフェースを含み、より高位のシステム層及びモジュールとしては、構成及びネットワーク管理、ＧＵＩ（グラフィカルユーザインターフェース）、サービスアドバタイジング及び発見などを挙げることができるが、これらに限定されない。ＧＵＩは、装置のユーザに、周囲のピアのリスト、それらのピアの物理的近接性、範囲、若しくは信号強度、それらのピアのサービスのリスト、及び／又は他の情報を提示することができる。

図９に提示されるピア装置９００の構成は、例示的なものである。他の実施形態では、ピア装置の構成は、様々な程度で異なる場合がある。例えば、装置９００の構成要素の機能を、異なる方式で組み合わせることができ、単一の構成要素の機能を細分することができ、かつ／又は、複数の構成要素の機能を融合させることができる。

一部の実施形態では、ピア装置は、アプリケーション（例えば、装置９００内の高位層に存在するアプリケーション及びユーティリティ）をサポートするための、アプリケーションプロセッサを含む。このアプリケーションプロセッサは、それらのアプリケーションによって必要とされる、メモリ管理、グラフィック処理、及び／又は他の機能を提供する。一部の実施形態のピア装置はまた、無線通信を実行するための、ベースバンドプロセッサなどの無線インターフェース、並びに、その無線通信及び通信処理をサポートするための、対応するメモリ及び送受信機も含む。

無線インターフェースは、図９の論理リンク層及びデータリンク層内に示される構成要素、並びに、それらの構成要素と併せて説明される機能性の全てを含み得る。無線インターフェースはまた、通常は物理層に関連付けられる幾つかのタスク（例えば、チャネル符号化）も処理することができる。

それゆえ、一部の実施形態では、ピア装置の「通信モジュール」又は「無線通信モジュール」とは、直前に説明した堅牢な無線インターフェース構成要素を指す場合がある。一部の他の実施形態では、通信モジュールは、装置のアンテナを運用又は管理するための、ベースバンドプロセッサ及び対応する送受信機と、恐らくは、そのベースバンドプロセッサによって使用されるメモリとを包含し得る。更に他の実施形態では、通信モジュールは、装置９００の論理リンク層及びデータリンク層の構成要素と、ピア装置にデータを送信し、かつピア装置からデータを受信するために必要な、他の構成要素とを包含し得る。

上述の一部の実施形態が実行される環境は、汎用コンピュータ、又は、ハンドヘルドコンピュータ、スマートフォン、若しくは他のモバイル機器などの特殊目的装置を組み込むことができる。そのような装置の一部の詳細（例えば、プロセッサ、メモリ、データ記憶装置、ディスプレイ）は、明瞭性のために省略される場合がある。１つ以上のタスク若しくは機能が起因する、プロセッサ又はメモリなどの構成要素は、指定されたタスク若しくは機能を実行するように一時的に構成される、一般構成要素とすることができ、又は、そのタスク若しくは機能を実行するように製造される、特定構成要素とすることもできる。本明細書で使用するとき、用語「プロセッサ」は、データ及び／又はコンピュータプログラムコードを処理するように構成された、１つ以上の電子回路、装置、チップ、処理コア、並びに／あるいは他の構成要素を指す。

この「発明を実施するための形態」で説明されるデータ構造及びプログラムコードは、典型的には、永続的コンピュータ可読記憶媒体上に記憶され、この永続的コンピュータ可読記憶媒体は、コンピュータシステムによる使用のための、コード及び／又はデータを記憶することが可能な、任意の装置若しくは媒体とすることができる。コンピュータ可読記憶媒体には、揮発性メモリ、不揮発性メモリ、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（ディジタル多用途ディスク、若しくは、ディジタルビデオディスク）等の磁気光学記憶デバイス、又は現在公知とされるか、あるいは、今後開発されるコード、及び／又はデータを記憶可能とする他の媒体が含まれるが、これらに限定されるものではない。

「発明を実施するための形態」で説明される方法及びプロセスは、上述のような永続的コンピュータ可読記憶媒体内に記憶させることが可能な、コード及び／又はデータとして具体化することができる。プロセッサ又はコンピュータシステムが、コードを読み取り、実行して、媒体上に記憶されたデータを操作すると、そのプロセッサ又はコンピュータシステムは、コード及びデータ構造として具体化され、かつ媒体内部に記憶された、それらの方法及びプロセスを実行する。

更には、それらの方法及びプロセスは、限定するものではないが、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、及び、現在公知であるか若しくは今後開発される他のプログラム可能論理装置などの、ハードウェアモジュール内にプログラムすることができる。そのようなハードウェアモジュールが起動されると、そのハードウェアモジュールは、モジュール内部に含まれる方法及びプロセスを実行する。

前述の実施形態は、例示及び説明のみを目的として、提示されている。それらの実施形態は、網羅的であることも、又は開示される形態に本開示を限定することも、意図するものではない。したがって、多くの修正及び変形態様が、当業者には明らかとなるであろう。その範囲は、上述の開示によってではなく、添付の特許請求の範囲によって規定される。

Claims (15)

1. ピアツーピア通信を行うための装置であって、
   プロセッサと、
   制限チャネルを含む複数のチャネルの周波数の識別情報を含むメモリと、
   無線通信を行うための無線送受信機と、
   を備え、前記プロセッサ及び前記無線送受信機が、
   制限チャネル上での目標ビーコン送信時間（ＴＢＴＴ）を決定し、
   前記ＴＢＴＴの前に前記制限チャネルに同調し、
   前記制限チャネルに同調した後に、
   前記ＴＢＴＴを含む時間間隔の間の送信を辞退し、
   前記制限チャネルに制限がないことを示す、ビーコン又は管理フレームを受信するか、又は
   前記時間間隔の間にビーコン又は管理フレームを受信することができなかった後にのみ、
   前記制限チャネル上に送信し、
   前記ピアツーピア通信を行いつつ、前記複数のチャネル間を繰り返しシーケンスでホップし、前記繰り返しシーケンスが、前記制限チャネル上で動作する中央ノードのビーコン間隔の倍数に等しい周期を有する、
   ように構成される、
   装置。
2. ピアツーピア通信を行う方法であって、前記方法が、第１の通信装置で、
   前記ピアツーピア通信を行うための、通信チャネルのシーケンスを決定することであって、前記シーケンスが、第１のビーコン間隔を有するビーコンフレームを第１のマスター装置が発行する、第１の制限チャネルを含むことと、
   第１の目標ビーコン送信時間（ＴＢＴＴ１）の前に第１の制限チャネルに同調することと、
   前記第１のＴＢＴＴ１を包含する期間にわたって、前記第１の制限チャネルにおける送信を辞退することと、
   （ｉ）前記第１の制限チャネルが解放されていることを示すビーコンフレームが受信されるか、（ｉｉ）前記第１のＴＢＴＴ１を包含する期間の間にビーコンフレームが受信されなかったことに応答して、前記第１のＴＢＴＴ１を包含する期間の後に、前記第１の制限チャネルにおけるピアツーピア通信を送信することと、
   前記通信チャネルのシーケンス間でホップすることと、
   を含み、
   前記ホップすることは前記ホッピングシーケンスの周期を計算することを含み、前記ホッピングシーケンスの周期は前記第１のビーコン間隔の倍数に等しい、
   方法。
3. 前記ホップすることが、
   前記第１の制限チャネルから第２の非制限チャネルに同調する時間を計算することと、
   次のホッピング周期に関して前記第１の制限チャネルに同調することと、
   を更に含む、請求項２に記載の方法。
4. 次のホッピング周期に関して前記第１の制限チャネルに同調することが、ＴＢＴＴ１の１〜３ミリ秒前に前記制限チャネルに同調することを含む、請求項３に記載の方法。
5. 前記第１の制限チャネルから前記第２の非制限チャネルに同調する時間を計算することが、前記第１の制限チャネル及び前記第２の非制限チャネル上での前記ピアツーピア通信に関する、固定長のタイムスロットを計算することを含む、請求項３に記載の方法。
6. 前記通信チャネルのシーケンス間でホップすることを更に含み、前記ホップすることが、
   前記第１のビーコン間隔の倍数に等しい、前記ホッピングシーケンスの周期を計算することと、
   前記第１の制限チャネルから第２の制限チャネルに同調する時間を計算することと、
   次のホッピング周期に関して前記第１の制限チャネルに同調することと、
   を含む、請求項２に記載の方法。
7. 前記第１の制限チャネルから前記第２の制限チャネルに同調する時間を計算することが、
   第２のマスター装置が前記第２の制限チャネル上にビーコンフレームを発行する、第２のビーコン間隔を特定することと、
   前記第２のビーコン間隔に基づいて、１つ以上の第２の目標送信ビーコン時間（ＴＢＴＴ２）を計算することと、
   前記第２の制限チャネルに同調する前記時間として、ＴＢＴＴ２近傍時間を選択することと、
   を含む、請求項６に記載の方法。
8. 前記ＴＢＴＴ２近傍時間が、ＴＢＴＴ２の１〜３ミリ秒前である、請求項７に記載の方法。
9. ピアツーピア通信を行う方法であって、前記方法が、第１のピア装置で、
   前記ピアツーピア通信を行うための、２つ以上の通信チャネルを特定することであって、前記２つ以上の通信チャネルの第１のチャネルは制限チャネルを含むことと、
   前記２つ以上のチャネル間での複数のチャネルホッピングシーケンスを行うための期間を選択することであって、当該期間は第１のチャネルのビーコン間隔の倍数に等しいことと、
   目標ビーコン送信時間（ＴＢＴＴ）の前に第１のチャネルに同調することと、
   前記第１のチャネルが解放されていることを示す、第１の管理ノードからの通信が受信されるまで、前記第１のチャネル上への送信を延期することと、
   前記第１のチャネルへの次のホップの際に、前記第１の管理ノードから通信が受信されない、所定の持続時間の時間窓が経過するまで、前記第１のチャネル上への送信を延期することと、
   ソーシャルチャネルへの切り替えを、
   他のピア装置のクラスタとの同期を維持するための、前記ソーシャルチャネル上のピアツーピアビーコン、及び
   前記クラスタ内の他のピア装置を発見するための、前記ソーシャルチャネル上の可用性窓、
   のうちの、一方と合致させるように、時間設定することと、
   を含む、方法。
10. 前記第１のチャネル上への送信を延期した後に、
    前記ピアツーピア通信を再開することと、
    前記第１の管理ノードの、次の目標ビーコン送信時間（ＴＢＴＴ）の前に、前記延期を繰り返すことと、
    を更に含む、請求項９に記載の方法。
11. 第２のチャネルへの切り替えが、任意の時間に生じるように時間設定することと、
    前記第２のチャネルに切り替えると直ちに、前記ピアツーピア通信を再開することと、 を更に含む、請求項９に記載の方法。
12. 前記第１の管理ノードが、前記第１のピア装置以外の１つ以上のピア装置に関連付けられる、アクセスポイントであり、
    前記第１のピア装置が、第２のチャネル上で動作する第２の管理ノードに関連付けられ、
    前記方法が、
    前記第１の管理ノードによって発行されるチャネル切り替え告知を順守することを更に含む、
    請求項９に記載の方法。
13. 前記第１のピア装置が、前記クラスタのアンカーマスターである場合に、前記第１のチャネルとソーシャルチャネル上の可用性窓のスケジュールとを同期させることを更に含む、
    請求項９に記載の方法。
14. 前記所定の持続時間が、１０ｍｓである、請求項９に記載の方法。
15. ＤＦＳ（動的周波数選択）が、前記第１チャネル上で必要とされ、
    前記第１の管理ノードが、ＤＦＳマスターを含む、
    請求項９に記載の方法。

Images