JP2009530902A - アドホックネットワークのための分散型無線メディアアクセス制御プロトコル - Google Patents

Abstract

分散型の無線メディアアクセス制御プロトコルを開示する。開示する無線メディアアクセス制御プロトコルによると、メディアアクセスタイムを等しい大きさのスロットに分割し、所定の数のスロットがスーパーフレームを形成する。このプロトコルでは、ビーコニングデバイスとパッシブデバイスとを定義する。ビーコニングデバイスのそれぞれは、スーパーフレーム内のスロットの１つを自身のビーコンメディアアクセススロットとして指定し、そのビーコンメディアアクセススロットにおいて、そのビーコニングデバイスの無線範囲内の別のデバイスにビーコンフレームをブロードキャストする。ビーコンフレームの衝突を検出および解決する手順と、デバイス間で通信するためのアクセスタイムを予約する手順も開示する。
【選択図】 図１８

Description

本発明は、無線ネットワークに関し、詳細には、アドホックネットワークのための分散型無線メディアアクセス制御プロトコルに関する。

ネットワークにおいて、メディアアクセス制御によって、複数のデバイスが通信用メディアを共有することが可能になる。このことは、複数のデバイスが無線ネットワークを形成する無線通信メディアにおいても当てはまる。無線ネットワークのメディアアクセス制御方式は、膨大な種類が存在している。一般的には、これらメディアアクセス制御方式のほとんどは、３つの広いカテゴリ、すなわち周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）、および符号分割多元接続（ＣＤＭＡ）に分類することができる。

ＦＤＭＡは、周波数スペクトルを周波数チャネルに分割し、それら周波数チャネルをユーザに割り当てる方式である。ＦＤＭＡでは、特定の周波数チャネルが、常に一人のみのユーザに割り当てられる。図１は、ＦＤＭＡにおいて、周波数スペクトルをＮ個の周波数チャネル（例：周波数チャネル１０１、１０２、１０３）に分割する方式を示している。

ＦＤＭＡとは対照的に、ＴＤＭＡ方式では、メディアアクセスタイムをタイムスロットに分割する。各ユーザが、短時間ずつ、周波数スペクトル全体にアクセスできることにより、スペクトル容量（spectrum capacity）が高まる。異なるユーザが、周波数スペクトル内の同じ周波数を異なるタイムスロットにおいて共有する。図２は、ＴＤＭＡにおいて、メディアアクセスタイムをＮ個のタイムスロット（例：スロット２０１、２０２、２０３）に分割する方式を示している。

ＣＤＭＡでは、全てのユーザが全ての周波数チャネルを同時に占有できることにより、スペクトル容量が増す。各ユーザの送信に、他のユーザの送信と区別するための一意の符号を割り当てる。図３は、ＣＤＭＡにおいて、ユーザが常に周波数スペクトル全体を同時に占有でき、異なる送信に異なる符号（例：符号３０１、３０２、３０３）が割り当てられる状況を示している。

実際の無線ネットワークにおいては、通常、ＦＤＭＡ、ＴＤＭＡ、ＣＤＭＡの内の、何らかの組合せを使用する。無線ネットワーク内のデバイスの物理（ＰＨＹ）層においては、通常ではＦＤＭＡおよびＣＤＭＡを使用するのに対し、物理層より上のメディアアクセス制御（ＭＡＣ）層においては、通常ではＴＤＭＡを使用する。

様々なＴＤＭＡ ＭＡＣプロトコルが存在する。最も初期に開発されたＴＤＭＡ ＭＡＣプロトコルの１つが、Ａｌｏｈａプロトコルである。Ａｌｏｈａプロトコルでは、データを送信しようとするソースデバイスは、単純に送信し、デスティネーションデバイスからのＡＣＫを待機する。別の送信との衝突のために、データが正常に受信されなかった場合、ソースデバイスは、単純にそのデータを後から再送信する。

Ａｌｏｈａプロトコルの改良は、スロット型Ａｌｏｈａプロトコル（Slotted Aloha protocol）として知られている。このプロトコルでは、メディアアクセスタイムを固定間隔のスロットに分割する。ソースデバイスは、送信時、最も早いスロット間隔において送信し、（通常の）Ａｌｏｈａプロトコルの場合と同様にＡＣＫを待機する。この場合にも、別の送信との衝突のためにデータが正常に送信されなかった場合、ソースデバイスは、そのデータをもう一度後から再送信する。しかしながら、デバイスはスロット間隔においてのみ送信することが要求されるため、送信の衝突が完全なパケット衝突のみに限定され、これにより、（通常の）Ａｌｏｈａプロトコルの使用時に、しばしば起こる部分的なパケット衝突が排除される。

別のＭＡＣ層ＴＤＭＡプロトコルは、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）の無線ローカルエリアネットワーク（ＷＬＡＮ）規格８０２．１１のプロトコルである。このＩＥＥＥ ８０２．１１ ＭＡＣ規格では、メディアアクセスタイムを、ＴＢＴＴ（Target Beacon Transmission Time：ターゲットビーコン送信タイム）と呼ばれる定期的なタイム間隔に分割する。図４は、メディアアクセスタイムと、ＴＢＴＴ ４０１、４０２、４０３、４０４を示している。各ＴＢＴＴにおいて、または各ＴＢＴＴに続けて、ビーコンフレームと呼ばれる特殊なパケットをブロードキャストする。図４は、ビーコンフレーム、例えば、それぞれＴＢＴＴ ４０１および４０２において、または続けて送信されるビーコンフレーム４１１および４１２も示している。なお、ＩＥＥＥ ８０２．１１によると、ＭＡＣ規格ではビーコンフレーム４１１および４１２をブロードキャストするのにコンテンション方式を使用するため、ＴＢＴＴ時に既存の送信が存在するとビーコンフレームが遅延する。ビーコンフレームは、ネットワーク内のすべのデバイスを同期させる目的と、ネットワークの他の重要な制御情報を提供する目的に使用する。

ビーコンフレームをブロードキャストするデバイスは、ＩＥＥＥ ８０２．１１ ＭＡＣ規格を実施するモードに応じて異なっていてもよい。ＩＥＥＥ ８０２．１１規格のインフラストラクチャモード（中央集中型モード）においては、アクセスポイント（ＡＰ）デバイスのみが、各ＴＢＴＴ時にビーコンフレームをブロードキャストする。ＩＢＳＳ（独立基本サービスセット：Independent Basic Service Set）モード（「アドホックモード」としても知られている）においては、ネットワーク内の各デバイスが各ＴＢＴＴ時にビーコンフレームのブロードキャストを試みる。しかしながら、コンテンションにより、各ＴＢＴＴにおいて、１つのデバイスのみがビーコンフレームを正常に送ることができる。ＴＢＴＴ以外のタイムの間は、デバイスは、「分散型調整機能（Distributed Coordination Function）」（ＤＣＦ）または「ポイント調整機能（Point Coordination Function）」（ＰＣＦ）のいずれかを使用してメディアアクセスタイムを共有する。ＤＣＦでは、一般に知られているＣＳＭＡ／ＣＡ（搬送波感知多重アクセス／衝突回避：Carrier Sense Multiple Access with Collision Avoidance）手法を使用する。優先度方式のメディアアクセスを提供するため、ＩＥＥＥ ８０２．１１規格では、メディアアクセスを競合するために必要なバックオフを実行するまでの遅延として使用する、さまざまな時間長の「フレーム間隔（Interframe Space）」（ＩＦＳ）を提供する。４種類のＩＦＳは、「ＳＩＦＳ（Short Interframe Space：短フレーム間隔）」、「ＰＩＦＳ（PCF Interfame Space：ＰＣＦフレーム間隔）」、「ＤＩＦＳ（DCF Interframe Space：ＤＣＦフレーム間隔）」、「ＥＩＦＳ（Extended Interframe Space：拡張フレーム間隔）」である。図５は、ＩＥＥＥ ８０２．１１規格に従ってのＤＣＦを使用してのメディアアクセスと、ＳＩＦＳ、ＰＩＦＳ、ＤＩＦＳの間の関係とを示している。

図６は、ＩＥＥＥ ８０２．１１規格に従って、ＰＣＦを使用したメディアアクセスを示している。ＰＣＦは、コンテンションのない転送プロトコルであり、アクセスポイント（ＡＰ）において動作しているポイントコーディネータ（ＰＣ）によって制御されるポーリング方式に基づく。ポイントコーディネータは、コンテンションフリー期間（ＣＦＰ）の最初にメディアの制御を取得し、送信間隔として、ＤＣＦアクセス手順を使用する別のデバイスよりも短い時間だけ待機することによって、ＣＦＰ全体にわたり制御を維持するように試みる。

ＩＥＥＥは、ＩＥＥＥ ８０２．１１ ＷＬＡＮ規格以外に、無線パーソナルエリアネットワーク（ＷＰＡＮ）の規格も定義している。そのようなＷＰＡＮ規格の１つは、ＩＥＥＥ ８０２．１５．３高速ＷＰＡＮ規格である。このＩＥＥＥ ８０２．１５．３ ＷＰＡＮ規格でも、ＭＡＣ層においてＴＤＭＡが使用される。メディアアクセスタイムを、周期的なスーパーフレームに分割する。ＩＥＥＥ ８０２．１５．３ ＷＰＡＮ規格では、そのネットワークトポロジとして中央集中制御型トポロジを定義している。デバイスは、一般的に、通常動作デバイス（ＤＥＶ）として分類することができ、あるいは、デバイスはピコネットコーディネータ（ＰＮＣ）の役割を果たすことができる。ピコネットコーディネータは、スーパーフレームごとに１回、ビーコンフレームをブロードキャストする。ビーコンフレームを受信したＤＥＶは、そのピコネットコーディネータのネットワーク（ピコネットと呼ばれる）に参加することを選ぶことができ、従って、そのピコネットコーディネータを中心とする中央集中制御型ネットワークが形成される。図７は、ピコネットコーディネータ７０１と、そのピコネットコーディネータの無線受信範囲内のＤＥＶ ７０２〜７０５とを示している。従って、ＤＥＶ ７０２〜７０５は、ピコネットコーディネータ７０１によってブロードキャストされるビーコンフレームを受信することができ、すべてのデバイス７０１〜７０５がピコネット内でデータを交換することができる。

図８に示したように、ＩＥＥＥ ８０２．１５．３規格によって定義されているスーパーフレームは、ビーコンスロットと、コンテンションアクセス期間（ＣＡＰ：Contention Access Period）と、チャネルタイム割り当て期間（ＣＴＡＰ：Channel Time Allocation Period）とにさらに分割されている。ビーコンスロットは、ビーコンフレームをコンテンションなしにブロードキャストする目的でピコネットコーディネータが使用する。ＣＡＰは、ピコネットコーディネータおよび１つ以上のＤＥＶが、コマンド／応答の送信またはコンテンションベースのトラフィックを目的として使用する。ＣＴＡＰ内のメディアアクセスタイムは、コンテンションのないＤＥＶからの通信を目的としてピコネットコーディネータが予約する複数のスロットに分割されている。

ＩＥＥＥは、低速デバイスを対象とするＷＰＡＮの規格をさらに定義している。この規格がＩＥＥＥ ８０２．１５．４低速ＷＰＡＮ規格である。この規格では、２種類のデバイス、すなわちＦＦＤ（Full Function Device：フル機能デバイス）およびＲＦＤ（Reduced Function Device：限定機能デバイス）が定義されている。この規格は、アプリケーションの必要条件に応じて、２つのトポロジ、すなわちスター型トポロジまたはピアツーピア型トポロジのいずれかにおいて運用することができる。図９は、ＩＥＥＥ ８０２．１５．４低速ＷＰＡＮ規格のスター型トポロジおよびピアツーピア型トポロジと、これらのトポロジにおけるパーソナルエリアネットワーク（ＰＡＮ）コーディネータの位置と、デバイス間の通信の流れとを示している。

このＩＥＥＥ ８０２．１５．４低速ＷＰＡＮ規格では、ＩＥＥＥ ８０２．１５．３高速ＷＰＡＮ規格と同様に、ＭＡＣ層においてＴＤＭＡを使用する。ＩＥＥＥ ８０２．１５．４規格では、デバイスは、単純なＣＳＭＡ／ＣＡ手法を使用してメディアアクセスタイムを共有することができる。オプションとして、スーパーフレーム構造を使用することができる。スーパーフレームのフォーマットは、コーディネータによって定義される。図１０に示したように、スーパーフレームは１６個の等しい大きさのスロットに分割される。スーパーフレームは、コーディネータによって送られるネットワークビーコンを境界とする。

低レイテンシのアプリケーション、あるいは特定のデータ帯域幅を必要とするアプリケーションの場合、コーディネータは、アクティブなスーパーフレームの一部を、それらのアプリケーションを実行するデバイス専用に割り当てることができる。そのような専用部分はＧＴＳ（Guaranteed Time Slot：保証タイムスロット）と呼ばれる。ＧＴＳはＣＦＰを形成する。図１１に示したように、ＣＦＰは、アクティブなスーパーフレームの必ず最後に現れ、ＣＡＰの直後のスロットから始まる。

さらに別の高速ＷＰＡＮプロトコルは、ＭＢＯＡ（Multi-Band OFDM Alliance）グループによって定義されたプロトコルである。ＷＰＡＮ内のすべてのデバイスが自身のネットワークを形成できるようにするため、デバイスそれぞれが分散方式でビーコンフレームをブロードキャストするように要求される。ＭＢＯＡ ＭＡＣ ｖ０．９３規格では、持続時間が６５５３６μｓであるように、デバイスのスーパーフレームを定義している。図１２は、ＭＢＯＡ ＭＡＣ ｖ０．９３規格によるスーパーフレームを示している。このスーパーフレームは、２５６個のメディアアクセススロット（ＭＡＳ：Media Access Slot）から成り、各ＭＡＳの持続時間は２５６μｓである。スーパーフレームの最初の部分は、ビーコンフレームをブロードキャストする目的に予約されている。ビーコンフレームをブロードキャストするのに実際に使用されるＭＡＳの数は、ビーコン期間（ＢＰ）として定義されている。ビーコン期間は、ビーコンスロット（ＢＳ）に細分割される。スーパーフレーム内の残りのＭＡＳはデータ伝送に使用され、この場合のデータ伝送は、優先度方式のコンテンションベース方法（優先度方式チャネルアクセス（ＰＣＡ：Prioritized Channel Access）と呼ばれる）、またはデータ予約方式（分散型予約プロトコル（ＤＲＰ：Distributed Reservation Protocol）と呼ばれる）のいずれかを使用する。ビーコン期間は、その長さが動的であり、動的な数のビーコンスロットから成る。ビーコン期間は、新しいデバイスがビーコングループ（ＢＧ）に参加すると拡張され、デバイスがビーコングループから離れると短縮される。ビーコングループとは、それぞれのビーコンフレームの送信をＭＡＳの同じグループ内で同期させ、これらのＭＡＳをそれぞれのビーコン期間として識別するデバイスのグループとして定義される。２つ以上のビーコングループが互いの範囲内に入るときには、デバイスは、１つのビーコン期間に併合して１つのビーコングループにまとめることが要求される。この場合、別のビーコングループから参加する別のデバイスのビーコンフレームが収容されるように、１つのビーコングループのビーコン期間を拡張する。

実際に使用する状況においては、無線メディアアクセス制御に関する問題が数多く存在する。そのような問題の１つは、モビリティの問題である。ネットワークのトポロジは、アプリケーションと、無線ネットワーク内のデバイスの特性とに依存して、静的なトポロジであるか、あるいは、デバイスがネットワークに頻繁に出入りする動的なトポロジである。動的なトポロジの場合、ネットワーク内のデバイスのモビリティのため、ある程度のアドホック接続をメディアアクセス制御によってサポートしなければならない。さらに、デバイスのモビリティのため、ソースデバイスからの送信（ビーコンフレームのブロードキャストまたはデータフレームの送信のいずれかである）と、ネットワーク内の別のデバイスの送信とが衝突する確率が高いことがある。同期のためと、制御情報をブロードキャストするためにビーコンフレームを使用するＭＡＣでは、モビリティに起因して、２つ以上のデバイスによるビーコンフレームのブロードキャストが衝突することがある。

図１３は、この状況が起こりうるトポロジの例を示しており、デバイス１３０２および１３０４がビーコンフレームをブロードキャストする。デバイス１３０１、１３０３、１３０５、１３０６は、そのようなブロードキャストされるビーコンフレームを待ち受けする。デバイス１３０２および１３０４が同じタイムスロットを選択して、それぞれのビーコンフレームをブロードキャストし、かつ、これらのデバイス１３０２および１３０４が、デバイス１３０３などのデバイスがデバイス１３０２および１３０４の両方のブロードキャスト範囲内となるように位置しているならば、デバイス１３０２および１３０４からのビーコンフレームのブロードキャストが衝突する。一般には送信中に受信することはできないため、デバイス１３０２および１３０４のいずれも、この衝突を検出することはできない。デバイスが送信するときに同時に受信するためには、複数のアンテナを導入するなど、さらなる複雑さを採り入れる必要がある。この場合、ビーコンフレームはコンテンションなしで送られるものと想定し、なぜなら、コンテンションの結果として、コンテンションのバックオフに起因する遅延が生じ、それによりビーコンフレームの所定のタイミングが保証されないためである。特定のＭＡＣ設計では、デバイス１３０３がデバイス１３０２および１３０４のいずれのビーコンフレームも受信できないことを利用して、デバイス１３０２および１３０４のビーコンフレームが正しく受信されないことをこれらのデバイスに知らせる、すなわちビーコンフレームの衝突が存在しうることを示すフィードバックを提供する。その場合、デバイス１３０２および１３０４は、対策として別のタイムスロットに変更し、それぞれのビーコンフレームをブロードキャストする。

しかしながら、図１４に示したトポロジにおいて、ビーコンフレームをブロードキャストするデバイスがデバイス１４０２および１４０３である場合を考える。この場合、ビーコンフレームをブロードキャストするデバイス１４０２および１４０３の両方のブロードキャスト範囲内に別のデバイスは存在しない。ビーコンフレームをブロードキャストするデバイス１４０２および１４０３は、同じビーコニングスロットを使用して、それぞれのビーコンフレームをブロードキャストするため、ビーコンフレームの衝突を検出することができない。従って、デバイス１４０２および１４０３は互いに発見することができず、その結果として、これらのデバイスは無線範囲内にあるが互いに通信することができない。

無線メディアアクセス制御の別の一般的な問題は、同時動作ピコネット（ＳＯＰ：Simultaneous Operating Piconet）の問題である。このＳＯＰ問題は、中央集中型制御に基づくＭＡＣ設計において非常に頻繁に発生する。図１５は、それぞれのビーコンフレームをブロードキャストする３つのデバイス１５０３、１５０８、１５０９を含んでいる無線ネットワークトポロジを示している。これらのデバイス１５０３、１５０８、１５０９の無線範囲は、それぞれ、境界１５１２、１５１３、１５１４によって示してある。デバイス１５０３、１５０８、１５０９が中央コーディネータとして機能する中央集中型モデルにおいては、デバイス１５０４および１５０６は、互いの無線範囲内にあるが、それぞれ異なる中央コーディネータ１５０３および１５０８に接続されているため、互いに通信することができない。

ビーコンニングフレームをブロードキャストするデバイス１５０８および１５０９についても、別のＳＯＰ問題が存在する。デバイス１５０８および１５０９の場合のように、ビーコンフレームをブロードキャストする２つのデバイスが同じ無線空間内に存在しているとき、１つの可能な方法として、デバイス１５０８または１５０９の一方が別のネットワークに参加しなければならない。あるいは、そのようなデバイスが共存できるようにするための何らかの追加のプロトコルが必要である。

サービス品質（ＱｏＳ）も、無線メディアアクセス制御に関連する問題である。低レイテンシのアプリケーション、あるいは特定のデータ帯域幅を必要とするアプリケーションの場合、保証タイムアクセスを提供するための何らかの手段が必要である。ＱｏＳを提供するためには、コンテンションベースのメディアアクセスは、メディアアクセスが保証されないため適切ではない。なぜなら、コンテンションベースのメディアアクセスでは、メディアを感知するための遅延、ランダムなバックオフ、衝突が起こるためである。

上述したＡｌｏｈａプロトコルには、データパケットの衝突が非常に頻繁であるためにＱｏＳを提供できないという問題がある。

ＩＥＥＥ ８０２．１１ ＭＡＣ規格に関しては、インフラストラクチャモードではネットワークのモビリティがサポートされない。なぜならこの規格では静的なアクセスポイントが要求されるためである。アクセスポイントが無線ネットワークの外に移動する、またはオフに切り替わると、ネットワーク全体が崩壊する。ＩＢＳＳモードに関しては、モビリティはサポートされるが、ビーコンフレームはコンテンションベースで送信され、上述した理由により、この方式は時間遅延を伴う。別の弱点として、各スーパーフレームにおいて１つのビーコンフレームを１回送信できるのみである。このことは、多数のデバイスのネットワークにおいては、特定のデバイスを発見するまでに長い時間がかかりうることを意味し、デバイスが自身のビーコンフレームをブロードキャストするためのメディアを正常に競合できるかに影響する。

ＩＥＥＥ ８０２．１５．３高速ＷＰＡＮの場合、ＣＴＡＰの予約を通じてＱｏＳのサポートが提供されるが、このプロトコルも中央集中型制御に基づいている。ＩＥＥＥ ８０２．１１規格のインフラストラクチャモードに似て、ピコネットコーディネータが無線ネットワークの外に移動する、または突然に電源がオフされると、ネットワークは一時的に機能しなくなる。しかしながら、ＩＥＥＥ ８０２．１５．３規格においては、別のデバイスがピコネットコーディネータの役割を果たすことができ、従ってネットワークが機能を続けるための手段が提供される。ＩＥＥＥ ８０２．１５．３規格に関連する主たる問題は、図１５を参照しながら説明したＳＯＰの問題である。

ＩＥＥＥ ８０２．１５．４規格に関しては、この規格による無線ネットワークには、図１３および図１４を参照しながら説明したビーコンフレーム衝突の問題が存在する。さらに、この規格では、複数のデバイスが同じ無線空間内でビーコンフレームをブロードキャストするための方策が存在しない。

ＭＢＯＡ ＭＡＣ ｖ０．９３規格による無線ネットワークおいても、ビーコンフレーム衝突の問題が生じる。実際には、ＭＢＯＡ ＭＡＣ ｖ０．９３規格の場合、ネットワークのデバイスそれぞれがビーコンフレームをブロードキャストすることが要求されるため、この問題はさらに大きくなりうる。このことは、特にバッテリ駆動型のスレーブデバイスの場合（この解決策ではスレーブデバイスは追加の電力を消費する）、あるいは、デバイスがパッシブモードのままでいることを選択する場合、望ましくない。さらには、ビーコン期間の動的な短縮、拡張、およびマージ手順がさらに必要となることにより、複雑さが増し、電力消費量が増大する。

さまざまなＭＡＣプロトコルに関連する問題から明らかであるように、複雑さの程度が比較的小さく、モビリティ、ＳＯＰ、およびＱｏＳを提供するメディアアクセスプロトコルが依然として必要とされている。

本発明の目的は、既存の規格／方策の１つ以上の欠点を実質的に克服する、または少なくとも改善することである。

本発明の第１の側面によると、無線ネットワークにおいてメディアアクセスを制御する方法であって、
メディアアクセスタイムを等しい大きさのスロットに分割するステップであって、所定の数のスロットがスーパーフレームを形成する、ステップと、
スーパーフレームそれぞれの中で、無線ネットワーク内のビーコニングデバイスに対して、スロットのうちの１つをビーコニングデバイスのためのビーコンメディアアクセススロットとして指定するステップと、
ビーコンメディアアクセススロットにおいて、ビーコニングデバイスによって、ビーコニングデバイスの無線範囲内の別のデバイスにビーコンフレームをブロードキャストするステップと、
を含む方法、が提供される。

本発明の別の側面によると、上述した方法を実施する、無線ネットワークを形成するデバイスが提供される。

本発明の別の側面についても、以下に開示してある。

以下では、先行技術のいくつかの側面と、本発明の１つ以上の実施形態について、図面を参照しながら説明する。

デバイスがアドホック方式でネットワークに参加することのできる無線メディアアクセス制御（ＭＡＣ）プロトコルについて説明する。開示するＭＡＣプロトコルを実施するソフトウェアは、デバイスの制御／タイミングセクションに属する。

開示する無線メディアアクセス制御プロトコルにおけるデバイスは、ビーコニングデバイス（ＢＤＥＶ）またはパッシブデバイス（ＰＤＥＶ）のいずれかとして分類される。ＢＤＥＶは、定期的なビーコニングを実行するデバイスである。ビーコニングによって、ビーコニングを実行するＢＤＥＶの範囲内にある別のデバイスが、そのＢＤＥＶを発見することができる。別のデバイスがＢＤＥＶを発見すると、そのデバイスはＢＤＥＶとの通信を開始することができる。ＢＤＥＶとしては、一般には、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）が挙げられる。これに対し、ＰＤＥＶは、ビーコニングを実行しない。従って、ＰＤＥＶは別のデバイスによって発見されない。しかしながら、ＰＤＥＶは、ＢＤＥＶとの通信を開始することができる。ＰＤＥＶは、一般には、バッテリで駆動される小型のデバイス（電力消費量が最大の優先事項である）であるか、あるいは、デジタルカメラなどのパッシブデバイスである。デバイスをＰＤＥＶからＢＤＥＶに、またはこの逆に切り替えることができる。

開示する無線メディアアクセス制御プロトコルでは、メディアアクセスタイムをスーパーフレームに分割する。スーパーフレームのそれぞれは所定の固定サイズを有する。図１６は、スーパーフレームに分割されているメディアアクセスタイムを図解しており、スーパーフレーム１６０１、１６０２、１６０３を示してある。

スーパーフレームそれぞれの中のメディアアクセスタイムは、メディアアクセススロット（ＭＡＳ）と呼ばれる、一定数の同じ大きさのスロットにさらに分割される。各スーパーフレーム中のＭＡＳの一定数は、８、１６、６４、２５６などとすることができる。図１７は、（Ｍ＋１）個のＭＡＳに分割されている１つのスーパーフレームを示している。範囲内に移動する２つ以上のデバイスの間でＭＡＳの境界を同期させる目的には、この技術分野において公知である任意のスロット同期方法を採用する。

スーパーフレームそれぞれにおいて、ＭＡＳのうちの１つをビーコンメディアアクセススロット（ＢＭＡＳ）として定義する。ＢＭＡＳは、複数のビーコンスロット（ＢＳ）と、コンテンションアクセス期間（ＣＡＰ）とから成る。ＢＭＡＳは、ＢＤＥＶがビーコンフレームをブロードキャストするためと、デバイス間のコンテンションベースのトラフィックのためのメディアアクセスタイムを提供するために使用される。ＢＤＥＶのそれぞれは、ビーコンスロットのうちの１つにおいてビーコンフレームをブロードキャストする。ＢＤＥＶが自身のビーコンフレームをブロードキャストするために使用する特定のビーコンスロットは、現在のスーパーフレームより前にランダムに選択する。特定のＢＤＥＶが自身のビーコンフレームをブロードキャストするために使用するビーコンスロットは、スーパーフレームごとに異なっていることができる。あるいは、ＢＤＥＶは、ビーコンスロットをいったん選択したら、別のビーコンスロットを選択して使用する前に、複数の連続するスーパーフレームについて同じビーコンスロットを使用することができる。

ＣＡＰは、任意のデバイスがデータパケットを送るために使用するメディアアクセスタイムを競合できるメディアアクセスタイム期間である。また、ＣＡＰは、ＢＤＥＶが制御パケットの送信に使用するメディアアクセスタイムを競合するときにも使用できる。制御パケットの送信のコンテンションは、データパケットの送信のコンテンションよりも優先度が高い。ＣＡＰにおいて使用するコンテンション方法は、ＣＳＭＡ／ＣＡ（搬送波感知多重アクセス／衝突回避）など、任意のコンテンション方法とすることができる。

開示する無線メディアアクセス制御プロトコルでは、ＢＭＡＳの中でのビーコンスロットおよびＣＡＰの配置編成については制限されない。この無線メディアアクセス制御プロトコルでは、唯一の制限として、採用する配置編成は一貫したものでなければならない。図１８および図１９は、ＢＭＡＳの中のビーコンスロットおよびＣＡＰの２つの可能な配置編成を示している。図１８に示した配置編成では、（Ｘ＋１）個のビーコンスロットの後に、ＢＭＡＳの残りを構成する１つのＣＡＰが続いている。図１９に示した配置編成も、（Ｘ＋１）個のビーコンスロットを含んでいるが、ビーコンスロットそれぞれの後ろにＣＡＰが続いている。

ＢＭＡＳとして定義されない残りのＭＡＳは、コンテンションフリーのデータトラフィック用に自由に予約することができる。すべてのデバイス、すなわちＰＤＥＶおよびＢＤＥＶの両方は、スーパーフレームのすべてのＢＭＡＳの間、ビーコンと、ＣＡＰにおいて送られる制御フレームまたはコンテンションベースデータを待ち受けすることが要求される。

近隣のＢＤＥＶおよびＰＤＥＶが、ＢＭＡＳとして定義されているＭＡＳを知ることができるように、すべてのＢＤＥＶは、そのような情報をそれぞれのビーコンフレームにおいてブロードキャストする。例えば、ＢＤＥＶは、それぞれのビーコンフレームにおいてＢＭＡＳビットマップを使用してこの情報をブロードキャストすることができる。同様に、コンテンションフリーのデータトラフィック用に予約されたＭＡＳブロックを、同じ方式でアナウンスする。

スーパーフレームのＭＡＳのうちの任意の１つをＢＭＡＳとして定義できることは、開示する無線メディアアクセス制御プロトコルがＳＯＰ（同時動作ピコネット）をサポートすることを意味する。１つのスーパーフレームに、複数の異なるＢＤＥＶによってそれぞれのＢＭＡＳとして定義されている複数のＭＡＳが存在することができる。データの予約は、必ずＢＤＥＶの方向に行われる。ソースデバイスはＰＤＥＶデバイスまたは別のＢＤＥＶデバイスのいずれでもよいが、デスティネーションデバイスは常にＢＤＥＶである。

本明細書では、説明を容易にするため以下の命名規則を定義する。要求デバイス（ＲＤＥＶ）は、データの予約を行うＰＤＥＶまたはＢＤＥＶ（ソースデバイス）である。要求ターゲットＢＤＥＶ（ＲＴ＿ＢＤＥＶ）は、ＲＤＥＶが予約要求を送る先のＢＤＥＶである。要求近隣ＢＤＥＶ（ＲＮ＿ＢＤＥＶ）は、１つのＲＴ＿ＢＤＥＶの近隣のＢＤＥＶである。図２０を参照すると、この命名規則をさらに説明する目的で、無線ネットワーク内の複数のデバイス２００１〜２００７を含んでいるトポロジを示している。デバイス２００１、２００２、２００４〜２００７はＢＤＥＶであり、デバイス２００３はＰＤＥＶである。デバイス２００１〜２００７の間の線は、近隣関係を示している。

いま、ＰＤＥＶ ２００３がＢＤＥＶ ２００６と通信するために予約を行おうとする場合を考える。この場合、ＰＤＥＶ ２００３（ソースデバイス）がＲＤＥＶである。データ予約手順は、３段階、すなわち要求段階、応答段階、および通知段階を含んでいる。要求段階では、ＲＤＥＶが、ＲＴ＿ＢＤＥＶのＣＡＰにおいて予約要求パケットを送る。この予約要求パケットは、予約要求のデスティネーションＢＤＥＶを少なくとも識別する。ＲＴ＿ＢＤＥＶとは、ＲＤＥＶのネイバーフッド（neighbourhood）内のすべてのＢＤＥＶによって予約要求が受信されるようにＲＤＥＶが予約要求を送らなければならないＢＤＥＶである。図２０に示したトポロジにおいては、ＲＴ＿ＢＤＥＶの１つの可能な選択は、デスティネーションＢＤＥＶ ２００６自体と、ＢＤＥＶ ２００１とで構成することができる。ＲＴ＿ＢＤＥＶのこの選択は、ＲＤＥＶ ２００３のネイバーフッド内のすべてのデバイスに予約要求を確実に受信させるのに十分である。この理由として、ＢＤＥＶ ２００２はＲＴ＿ＢＤＥＶ ２００１のＣＡＰを受信でき、ＢＤＥＶ ２００４および２００５はＲＴ＿ＢＤＥＶ ２００６のＣＡＰを受信できるためである。この場合、ＢＤＥＶ ２００２、２００４、および２００５がＲＮ＿ＢＤＥＶである。従って、ＲＮ＿ＢＤＥＶのそれぞれは、ＲＤＥＶと、少なくとも１つのＲＴ＿ＢＤＥＶの近隣である。

データ予約手順の応答段階では、すべてのＲＴ＿ＢＤＥＶが、ＲＤＥＶによって送られた予約要求に対して、それぞれのＣＡＰにおいて承認または拒否の応答パケットを送ることによって応答する必要がある。さらに、ＲＮ＿ＢＤＥＶは、オプションとして、自身のＣＡＰにおいて異議パケットを送ることによって、予約要求に異議を唱えることができる。その後、ＲＤＥＶは、ＲＴ＿ＢＤＥＶからの応答のすべてと、ＲＮ＿ＢＤＥＶからの異議パケット（存在時）とを集める。

すべてのＲＴ＿ＢＤＥＶが予約要求を承認し、かつＲＮ＿ＢＤＥＶからの異議がない場合、その予約要求はＢＤＥＶそれぞれによって承認されたものとみなす。通知段階において、ＲＤＥＶは、予約要求の結果、すなわち、自身の近隣のＢＤＥＶすべてによって予約要求が承認されたかを、ＲＴ＿ＢＤＥＶのＣＡＰにおいてアナウンスする。すべてのＢＤＥＶによって予約要求が承認された場合、すべてのＢＤＥＶは、ＲＤＥＶによって予約されたＭＡＳをそれぞれのビーコンフレームにおいてアナウンスする。次いで、ＲＤＥＶ ２００３は、予約されたＭＡＳを使用して、ＢＤＥＶ ２００６へのコンテンションフリーパケットの送信を開始することができる。

ここまで、本開示の無線メディアアクセス制御プロトコルについて全般的に説明したが、以下では、このプロトコルの好ましい実施形態について説明する。図２１は、好ましい実施形態のＢＭＡＳの配置編成を示しており、この配置編成では、ＣＡＰによって隔てられている２つのビーコンスロットがＢＭＡＳの両端に位置している。説明を容易にするため、各スーパーフレームにおけるＭＡＳの数は、１６個のみとして選択されている。ビーコニングに使用するビーコンスロットは、スーパーフレームごとに変化する。スーパーフレームそれぞれにおいて、次のスーパーフレームにおいて使用するビーコンスロットをランダムに選択し、現在のスーパーフレーム中にブロードキャストする。

いま、図２２に示した、デバイス２２０１〜２２０９を含んでいるネットワークトポロジの例を考える。このトポロジの例においては、デバイス２２０２、２２０５、および２２０７がＢＤＥＶであり、デバイス２２０１、２２０３、２２０４、２２０６、２２０８、および２２０９がＰＤＥＶである。この場合も、デバイス２２０１〜２２０９の間の線は、デバイス２２０１〜２２０９の間の近隣関係を示している。図２３は、図２２に示した例のネットワークトポロジにおいて生じるメディアアクセススロット（ＭＡＳ）を示している。具体的には、それぞれＢＤＥＶ ２２０２、２２０５、および２２０７のスーパーフレーム２３０５、２３０６、および２３０７は、メディアアクセスタイムにおける状態として示してある。スーパーフレーム２３０５、２３０６、２３０７のそれぞれは、１６個のＭＡＳに分割されている。ブロック２３０２、２３０３、および２３０４は、それぞれＢＤＥＶ ２２０２、２２０５、および２２０７のＢＭＡＳを表しており、ブロック２３０１は、コンテンションフリートラフィック用に割り当てることのできる空のＭＡＳを表している。

図２２に示したＢＤＥＶ ２２０２、２２０５、および２２０７のそれぞれが、ＢＭＡＳとして予約したＭＡＳを近隣のデバイスにブロードキャストする目的で、図２４に示したＢＭＡＳビットマップを使用する。具体的には、２４０１、２４０２、および２４０３は、図２３に示したスーパーフレーム２３０５、２３０６、および２３０７をビットマップ形式で表している。影の付いたブロックは、スーパーフレーム２３０５、２３０６、および２３０７における、ＢＭＡＳとして予約されたＭＡＳに対応している。

右端のビットを最下位ビット（ＬＳＢ）として使用すると、スーパーフレーム２３０５、２３０６、および２３０７のＢＭＡＳビットマップは、それぞれ、０００００００１００００１００１、００１０００００００１００００１、および００００１００１０００００００１として計算される。同様に、スーパーフレーム２３０５、２３０６、および２３０７のＢＭＡＳビットマップは、１６進形式において、それぞれ、０１ ０９、２０ ２１、および０９ ０１と表すことができる。この例から明らかであるように、１６個のＭＡＳの実施形態の場合、ＢＭＡＳビットマップはそれぞれ２バイトを占有するのみである。さらに多数のＭＡＳにスーパーフレームを分割する実施形態の場合、ＢＭＡＳポジションのリストをブロードキャストすることは容易であり、なぜなら、ネットワークトポロジにおけるＢＤＥＶの数は通常ではＭＡＳの数よりもずっと少ないためである。

ＢＭＡＳとして予約されたＭＡＳをブロードキャストするためにＢＤＥＶ ２２０２、２２０５、および２２０８が使用するビットマップに類似するビットマップを使用して、データ送信用に予約されたＭＡＳをブロードキャストすることができる。図２４に示したＢＭＡＳビットマップに加えて、図２５も、データ送信用に予約されたＭＡＳに関連付けられるデータビットマップを示している。スーパーフレーム２５０１、２５０２、および２５０３は、図２３に示したスーパーフレーム２３０５、２３０６、および２３０７をビットマップ形式において表している。×印を付けたブロックは、スーパーフレーム２３０５、２３０６、および２３０７における、データ送信用に予約されたＭＡＳに対応している。

この場合も、右端のビットを最下位ビットとして使用すると、スーパーフレーム２５０５、２５０６、および２５０７のデータビットマップは、それぞれ、１１０００００００１１１００１０、０１０１１０００００００１１１０、および０１１１００１０１１００００００として計算される。同様に、スーパーフレーム２５０５、２５０６、および２５０７のデータビットマップは、１６進形式において、それぞれ、Ｃ０ ７２、５８ ０Ｅ、および７２ Ｃ０と表すことができる。

次に、開示する無線メディアアクセス制御プロトコルにおいて使用するビーコン衝突検出方法について説明する。ビーコンの衝突は、２つ以上のＢＤＥＶが、それぞれのＢＭＡＳとしてアクセスタイム内の同じＭＡＳ（それぞれのスーパーフレーム内では異なるＭＡＳであることがある）を選択し、その後、同じビーコンスロットを使用してそれぞれのビーコンフレームをブロードキャストするときに起こる。従って、ビーコンの衝突を回避するためには、２つのＢＤＥＶがそれぞれのＢＭＡＳとして同じＭＡＳを使用してはいけない。従って、２つ以上のＢＤＥＶがそれぞれのＢＭＡＳとして同じＭＡＳを使用しているかを検出するためのメカニズムを提供する。ここで、図１３に示したネットワークトポロジを考え、このトポロジでは、デバイス１３０３がＢＤＥＶ １３０２および１３０４の両方のブロードキャスト範囲内である。図２６は、ＢＭＡＳの衝突が検出および解決されるイベントシーケンスを表にまとめてある。いま、図２６の表において使用しているＡＤＥＶ−１およびＡＤＥＶ−２が、それぞれＢＤＥＶ １３０２および１３０４に対応しているとする。図２６は、４つの異なるスーパーフレームにおけるＡＤＥＶ−１およびＡＤＥＶ−２のビーコンの図と、ＡＤＥＶ−１およびＡＤＥＶ−２がそれぞれのＢＭＡＳとして使用するＭＡＳの各ポジション（ＭＡＳ）と、それぞれのビーコンフレームをブロードキャストするために使用される、ＢＭＡＳ内のスロットの各ポジション（ＣＢＳ）と、ビーコンフレームをブロードキャストするために使用される予定の、ＢＭＡＳ内の次のポジション（ＮＢＳ）と、スーパーフレームそれぞれにおけるステータスと、を示している。

スーパーフレーム１においては、ＡＤＥＶ−１およびＡＤＥＶ−２のいずれも、それぞれのＢＭＡＳとしてＭＡＳポジション３と、それぞれのビーコンフレームをブロードキャストするためのスロットポジション０とを選択している。従って、ＢＭＡＳの衝突とビーコンフレームの衝突とが起きている。従って、ＰＤＥＶ １３０３（図１３）は、同じビーコンスロットにおいてビーコンフレームをブロードキャストすることに起因する干渉のため、ビーコンフレームを正しく受信することができない。

スーパーフレーム２においては、ＡＤＥＶ−１およびＡＤＥＶ−２は、それぞれのＢＭＡＳとして依然としてＭＡＳポジション３を使用している。ＡＤＥＶ−１およびＡＤＥＶ−２は、ビーコンフレームをブロードキャストするために使用するビーコンスロットを、各スーパーフレームにおいてランダムに選択する。ＡＤＥＶ−１およびＡＤＥＶ−２の両方は、それぞれのビーコンフレームをブロードキャストするためのスロットポジション１を使用する。この場合にも、ＢＭＡＳの衝突と、ビーコンフレームの衝突とが起きており、このため、ＰＤＥＶ １３０３はビーコンフレームを正しく受信することができない。従って、ＰＤＥＶ １３０３は、ＢＭＡＳの衝突が起きたことを推定することができ、制御パケットの優先度を使用して、この衝突をＣＡＰにおいてアナウンスする。ＢＤＥＶ １３０２および１３０４の両方は、それぞれのビーコンフレームをブロードキャストするために使用するビーコンスロットには関係なくこのＣＡＰを待ち受けするため、ＢＤＥＶ １３０２および１３０４の両方にＢＭＡＳの衝突が通知される。

スーパーフレーム３においては、ＡＤＥＶ−１およびＡＤＥＶ−２は、それぞれのＢＭＡＳとして依然としてＭＡＳポジション３を使用するが、それぞれのビーコンフレームをブロードキャストするための異なるスロットポジションをランダムに選択する。この場合、ＰＤＥＶ １３０３は、両方のビーコンフレームを受信できるが、ＢＭＡＳの衝突を依然として検出する。スーパーフレーム２の間にＰＤＥＶ １３０３によってアナウンスされた衝突に応答して、ＢＤＥＶ １３０２および１３０４は、それぞれのＢＭＡＳとして新しいＭＡＳをランダムに選択し、それぞれが、スーパーフレーム３においてＢＭＡＳの変更をアナウンスする。スーパーフレーム４においては、ＡＤＥＶ−１は自身のＢＭＡＳをＭＡＳポジション７に変更し、ＡＤＥＶ−２は自身のＢＭＡＳをＭＡＳポジション１１に変更し、これによってＢＭＡＳの衝突が解決し、従ってビーコンの衝突も解決する。

図１４は、最悪のシナリオとして、ＢＤＥＶ １４０２および１４０３のブロードキャスト範囲内に共通のＰＤＥＶが存在しないネットワークトポロジを示している。しかしながら、開示する無線メディアアクセス制御プロトコルでは、ＢＭＡＳの衝突を依然として検出することができ、以下ではこの理由について説明する。図２７は、図１４に示したトポロジにおけるＢＭＡＳの衝突が検出および解決されるイベントシーケンスを表にまとめてある。この場合、図２７の表において使用しているＡＤＥＶ−１およびＡＤＥＶ−２が、それぞれＢＤＥＶ １４０２および１４０３に対応しているとする。

スーパーフレーム１においては、ＡＤＥＶ−１およびＡＤＥＶ−２の両方が、それぞれのＢＭＡＳとしてＭＡＳポジション３と、それぞれのビーコンフレームをブロードキャストするためのスロットポジション０とを選択している。ＢＭＡＳの衝突およびビーコンフレームの衝突が起きても、これらの衝突は検出されないままであり、なぜなら、他のデバイス１４０１、１４０４、１４０５が、ＢＤＥＶ １４０２および１４０３のうちの一方のみのブロードキャスト範囲内にあるためである。

スーパーフレーム２においては、ＡＤＥＶ−１およびＡＤＥＶ−２は、それぞれのＢＭＡＳとして依然としてＭＡＳポジション３を使用するが、それぞれのビーコンフレームをブロードキャストするためのスロットポジション１をランダムに選択する。この場合も、ＢＭＡＳの衝突とビーコンフレームの衝突が起きても、これらの衝突は検出されないままである。

スーパーフレーム３においては、ＡＤＥＶ−１およびＡＤＥＶ−２は、それぞれのＢＭＡＳとして依然としてＭＡＳポジション３を使用しているが、それぞれのビーコンフレームをブロードキャストするための異なるスロットポジションをランダムに選択する。従って、依然としてＢＭＡＳの衝突が起こる。この場合、ＢＤＥＶ １４０２および１４０３自身がＢＭＡＳの衝突を検出することができ、なぜなら、自身がブロードキャストまたは送信していないアクセスタイム期間においてブロードキャストを待ち受けするためである。スーパーフレーム３においてＢＤＥＶ １４０２および１４０３によって検出される衝突に応答して、ＢＤＥＶ １４０２および１４０３は、それぞれのＢＭＡＳとして新しいＭＡＳをランダムに選択し、スーパーフレーム３においてＢＭＡＳの変更をアナウンスする。スーパーフレーム４において、ＡＤＥＶ−１は自身のＢＭＡＳをＭＡＳポジション１１に変更し、ＡＤＥＶ−２は自身のＢＭＡＳをＭＡＳポジション７に変更する。従って、ＢＤＥＶ １４０２および１４０３の両方のブロードキャスト範囲内にあるＰＤＥＶがたとえ存在しなくても、この場合にもＢＭＡＳの衝突が解決する。

図１５を参照しながら説明したＳＯＰ（同時動作ピコネット）の問題に関しては、開示する無線メディアアクセス制御プロトコルでは、ＢＭＡＳとして任意のＭＡＳを使用でき、デバイス１５０８および１５０９の共存が可能になる。デバイス１５０８および１５０９の両方は、それぞれのＢＭＡＳとして単純に２つの異なるＭＡＳを選択し、これにより、デバイス１５０８および１５０９は共有される無線範囲においてビーコンフレームをブロードキャストすることができる。２つ以上のＢＤＥＶ １５０３、１５０８、１５０９の無線範囲内にあるデバイス（例：デバイス１５０４、１５０５、１５０７）は、複数のビーコンフレームを受信することができ、なぜなら、異なるＢＭＡＳ内のビーコニングフレームは衝突しないためである。この結果として、デバイス１５０４、１５０５、１５０７は、特定の中央集中型ネットワークに制限されない。これにより、そのようなデバイス１５０４、１５０５、１５０７と複数のＢＤＥＶ １５０３、１５０８、１５０９との間でデータを交換することが可能になる。

開示する無線メディアアクセス制御プロトコルでは、データトラフィックに対してＭＡＳの予約がサポートされるため、データのＱｏＳ要件が満たされる。しかしながら、データトラフィックに対するＭＡＳを予約できるのは、ＢＤＥＶの方向のみである。すなわち、ＰＤＥＶがＢＤＥＶにデータを送るためのＭＡＳを予約する、または、ＢＤＥＶが別のＢＤＥＶにデータを送るためのＭＡＳを予約する。この制限により、古典的な隠れ端末の問題が回避され、なぜなら、ＰＤＥＶはビーコンフレームをブロードキャストせず、従って、予約できるＭＡＳが利用できることの指示情報を発することができないためである。このように制限することにより、２つのＰＤＥＶが無線範囲内にあることに起因する隠れ端末問題が排除される。ＰＤＥＶはビーコンフレームをブロードキャストしないため、２つのＰＤＥＶが無線範囲内にあるとき、これらは互いのデータの予約を認識しない。

図２８は、データ予約の４つの可能なシナリオ（場合）を示している。デバイス２８０１および２８０４はＢＤＥＶであるのに対し、デバイス２８０２および２８０３はＰＤＥＶである。データの予約をＢＤＥＶの方向にのみ可能であるように制限する場合、ケース２のみが可能であり、なぜなら、受信側デバイスにおいてデータパケットが衝突しないのはケース２のみであるためである。

予約が、無線範囲内の既存の予約と衝突あるいは重複しないようにするため、ＰＤＥＶは、最初に、自身が予約しようとするＭＡＳが、無線範囲内のいずれかのＢＤＥＶによって、ＢＭＡＳ用またはデータ用のいずれかとして使用されていると報告されていないことを確認する。さらに、予約は、すべてのＢＤＥＶが予約を承認する場合にのみ、成功とみなす。これを達成するため、ＰＤＥＶは、ＲＴ＿ＢＤＥＶに、それらのＣＡＰにおいて予約要求を送ることによって、予約を行う。

図２９は、ＲＤＥＶがデータ予約要求を行うときに使用するアルゴリズム２９００の概略的なフローチャートを示している。上述したように、ＲＤＥＶは、最初に、自身が予約しようとするＭＡＳが使用中であると報告されていないことを確認する。従って、ＲＤＥＶは、ステップ２９１０において、使用されていないＭＡＳを選択し、ステップ２９２０において、ＲＴ＿ＢＤＥＶへの予約要求を、これらのＲＴ＿ＢＤＥＶのＣＡＰにおいて要求パケットを送ることにより行う。ＲＴ＿ＢＤＥＶは、応答において、図３０を参照しながら後述する方法によってこの予約要求を処理する。

ステップ２９３０において、ＲＤＥＶはＲＴ＿ＢＤＥＶからの応答と、もしあれば、ＲＮ＿ＢＤＥＶからの異議とを受信する。次いで、ＲＤＥＶは、ステップ２９４０において、すべてのＲＴ＿ＢＤＥＶが要求を承認したかを判定し、承認した場合、ステップ２９５０において、いずれかのＲＮ＿ＢＤＥＶが要求に異議を唱えていないかを判定する。ステップ２９５０において、要求に異議が唱えられていないと判定される場合、その予約は成功であり、ステップ２９６０において、ＲＤＥＶはＲＴ＿ＢＤＥＶのＣＡＰにおいて成功通知パケットを送る。後述するように、ＲＴ＿ＢＤＥＶおよびＲＮ＿ＢＤＥＶは、次のスーパーフレームにおける自身のビーコンフレームにおいて予約をアナウンスする。次いで、ＲＤＥＶは、予約されたＭＡＳを使用して、対象のＢＤＥＶへのコンテンションフリーデータの送信を開始することができる。

ステップ２９４０において、いずれかのＲＴ＿ＢＤＥＶが要求を拒否したと判定される場合、または、ステップ２９５０において、いずれかのＲＮ＿ＢＤＥＶが要求に異議を唱えたことが判定される場合、その要求は失敗であり、ステップ２９７０において、ＲＤＥＶは、ＲＴ＿ＢＤＥＶのＣＡＰにおいて失敗通知パケットを送る。

図３０は、ステップ３０１０においてＲＤＥＶからのデータ予約要求を受信した時点でＲＴ＿ＢＤＥＶのそれぞれによって実行されるアルゴリズム３０００の概略的なフローチャートを示している。ＲＴ＿ＢＤＥＶは、ステップ３０２０において、受信した予約要求が既存の要求と衝突するかを判定する。衝突が存在しないと判定される場合、ＲＴ＿ＢＤＥＶは、ステップ３０３０において、自身のＣＡＰにおいて承認応答パケットを送る。あるいは、衝突が存在すると判定される場合、ＲＴ＿ＢＤＥＶは、ステップ３０４０において、自身のＣＡＰにおいて拒否応答パケットを送る。次いで、ＲＴ＿ＢＤＥＶは、ＲＤＥＶからの通知を待機する。

ＲＤＥＶから通知を受信すると、ＲＴ＿ＢＤＥＶは、ステップ３０５０において、その通知が予約の成功を示しているのかそうでないのかを判定する。通知が成功を示している場合、ＲＴ＿ＢＤＥＶは、ステップ３０６０において、次のスーパーフレームにおける自身のビーコンフレームにおいて予約をアナウンスする。あるいは、通知が予約の失敗を示す場合、ＲＴ＿ＢＤＥＶは何も行わない。

図３１は、ステップ３１１０においてＲＤＥＶからのデータ予約要求を受信した時点でＲＮ＿ＢＤＥＶのそれぞれによって実行されるアルゴリズム３１００の概略的なフローチャートを示している。ＲＮ＿ＢＤＥＶは、ステップ３１２０において、その要求に起因して、いずれかのＢＭＡＳ、または既存のデータ予約との衝突が起こるかを判定する。通常の状況では、予約は、ＲＮ＿ＢＤＥＶが確認する既存の予約と衝突することはなく、なぜなら、ＲＤＥＶが、要求するＭＡＳが使用されていると報告されていないことを最初に確認するためである。しかしながら、特殊な状況として、別のＲＤＥＶが、同じＭＡＳまたは重複するＭＡＳを使用して、そのＲＮ＿ＢＤＥＶへの予約要求を同時に行うことが起こりうる。そのような場合、ＲＮ＿ＢＤＥＶは、ステップ３１３０において、自身のＣＡＰにおいて異議パケットを送ることによってその予約に異議を唱える。ステップ３１２０において、その要求に起因して、ＢＭＡＳあるいは既存のデータ予約との衝突が起こらないと判定される場合、ＲＮ＿ＢＤＥＶは、要求の成功に関するＲＤＥＶからの通知を待機するのみである。通知を受信した時点で、ＲＮ＿ＢＤＥＶは、ステップ３１４０において、その通知が成功を示すかを判定する。通知が予約の失敗を示す場合、アルゴリズム３１００は終了する。あるいは、通知が成功を示す場合、ＲＮ＿ＢＤＥＶは、ステップ３１５０において、次のスーパーフレームにおける自身のビーコンフレームにおいて予約をアナウンスする。

予約の終了は、ターゲットＢＤＥＶまたはＲＤＥＶのいずれかが、ＲＴ＿ＢＤＥＶのＣＡＰにおいて予約終了パケットを送ることによって開始することができる。その後、すべてのＢＤＥＶ（ＲＴ＿ＢＤＥＶおよびＲＮ＿ＢＤＥＶ）は、それぞれのビーコンフレームにおける予約アナウンスのブロードキャストを停止する。

ここまでの説明から明らかであるように、ＢＤＥＶは、自身のビーコンフレームと、制御パケットまたはコンテンションベースのデータトラフィックとをブロードキャストするために使用するＢＭＡＳとして、スーパーフレーム内の任意のＭＡＳを利用できる。デバイスは、対象のネットワークのスーパーフレームの構造を変化させることなく、無線ネットワークに出入りすることができる。従って、アドホック接続が達成される。さらに、ビーコンの衝突を検出するうえで複数のＢＤＥＶに対する共通のデバイスも必要ない。デバイスは、それぞれの無線範囲内の複数のＢＤＥＶと通信することができる。ＢＤＥＶが自身のＢＭＡＳとして使用する（異なる）ＭＡＳをスーパーフレームの中でランダムに選択することにより、複数のＢＤＥＶがビーコンフレームをブロードキャストすることが可能になる。

上記は、本発明のいくつかの実施形態を説明しているにすぎない。本発明の範囲および概念から逸脱することなく、本発明に修正／変更を行うことができる。実施形態は説明を目的としており、本発明を制限するものではない。

ＦＤＭＡにおいて、周波数スペクトルをＮ個の周波数チャネルに分割する方式を示している。 ＴＤＭＡにおいて、メディアアクセスタイムをＮ個のタイムスロットに分割する方式を示している。 ＣＤＭＡにおいて、異なる送信に異なる符号を割り当てる方式を示している。 ＩＥＥＥ ８０２．１１規格によるビーコンフレームの送信を示している。 ＩＥＥＥ ８０２．１１規格による分散型調整機能を使用してのメディアアクセスを示している。 ＩＥＥＥ ８０２．１１規格によるポイント調整機能を使用してのメディアアクセスを示している。 ピコネットコーディネータと複数の通常動作デバイスとを含んでいるピコネットを示している。 ＩＥＥＥ ８０２．１５．３規格によって定義されているスーパーフレームの分割を示している。 ＩＥＥＥ ８０２．１５．４低速ＷＰＡＮ規格のスター型トポロジおよびピアツーピア型トポロジを示している。 コンテンションフリー期間が存在しない、ＩＥＥＥ ８０２．１５．４規格によって定義されているスーパーフレームの構造を示している。 コンテンションフリー期間が存在する、ＩＥＥＥ ８０２．１５．４規格によって定義されているスーパーフレームの構造を示している。 ＭＢＯＡ ＭＡＣ ｖ０．９３規格によるスーパーフレームの構造を示している。 共通するデバイスが存在する、ビーコンフレーム衝突のシナリオを示している。 共通するデバイスが存在しない、ビーコンフレーム衝突のシナリオを示している。 ＳＯＰ（同時動作ピコネット）問題を説明するための無線ネットワークトポロジを示している。 本開示による、メディアアクセスタイムをスーパーフレームに分割する方式を示している。 （Ｍ＋１）個のメディアアクセススロットに分割された１つのスーパーフレームを示している。 ビーコンメディアアクセススロット（ＢＭＡＳ）の中のビーコンスロットおよびコンテンションアクセス期間の２つの可能な配置編成を示している。 ビーコンメディアアクセススロット（ＢＭＡＳ）の中のビーコンスロットおよびコンテンションアクセス期間の２つの可能な配置編成を示している。 無線ネットワーク内の複数のデバイスを含んでいるネットワークトポロジの例を示している。 好ましい実施形態のビーコンメディアアクセススロットの配置編成を示している。 ネットワークトポロジの別の例を示している。 図２２に示したネットワークトポロジの例において生じるメディアアクセススロットを示している。 ビーコンメディアアクセススロットに使用されるメディアアクセススロットをビットマップを使用してアナウンスする方法を示している。 コンテンションの少ないデータ伝送のため、予約されたメディアアクセススロットをビットマップを使用してアナウンスする方法を示している。 ＢＭＡＳの衝突が検出および解決されるイベントシーケンスを表にまとめてある。 図１４に示したトポロジにおけるＢＭＡＳの衝突が検出および解決されるイベントシーケンスを表にまとめてある。 データ予約の４つの可能なシナリオ（場合）を示している。 ＲＤＥＶがデータ予約要求を行うときに使用するアルゴリズムの概略的なフローチャートを示している。 ＲＤＥＶからのデータ予約要求を受信した時点でＲＴ＿ＢＤＥＶのそれぞれによって実行されるアルゴリズムの概略的なフローチャートを示している。 ＲＤＥＶからのデータ予約要求を受信した時点でＲＮ＿ＢＤＥＶのそれぞれによって実行されるアルゴリズム３１００の概略的なフローチャートを示している。

Claims (18)

1. 無線ネットワークにおいてメディアアクセスを制御する方法であって、
   メディアアクセスタイムを等しい大きさのスロットに分割するステップであって、所定の数の前記スロットがスーパーフレームを形成する、前記ステップと、
   スーパーフレームそれぞれの中で、前記無線ネットワーク内のビーコニングデバイスに対して、前記スロットのうちの１つを前記ビーコニングデバイスのためのビーコンメディアアクセススロットとして指定するステップと、
   前記ビーコニングデバイスによって、前記ビーコニングデバイスの無線範囲内の別のデバイスに、前記ビーコンメディアアクセススロットにおいてビーコンフレームをブロードキャストするステップと、
   を含む方法。
2. 前記ビーコンメディアアクセススロットがランダムに指定される、請求項１に記載の方法。
3. 前記ビーコンメディアアクセススロットにおける前記アクセスタイムが、複数のビーコンスロットと、前記ビーコニングデバイスの無線範囲内のデバイス間の少なくともコンテンションベースのトラフィック用の１つ以上のスロットと、に分割されており、前記複数のビーコンスロットのうちの１つが、前記ビーコニングデバイスによって自身のビーコンフレームをブロードキャストするために選択される、
   請求項１記載の方法。
4. 前記ビーコンフレームをブロードキャストするための前記１つのビーコンスロットが、前記ビーコニングデバイスによってランダムに選択される、
   請求項３記載の方法。
5. 前記ビーコンフレームをブロードキャストするための前記１つのビーコンスロットが、各スーパーフレームに対して１回選択される、
   請求項３記載の方法。
6. 複数のスーパーフレームにおいて、前記ビーコンメディアアクセススロットの中の同じビーコンスロットが使用される、
   請求項３記載の方法。
7. 前記ビーコニングデバイスの無線範囲内のデバイス間の少なくともコンテンションベースのトラフィック用の前記１つ以上のスロットが、データパケットを送るために前記デバイスによって使用されるメディアアクセスタイムを競合するために、１つ以上の前記デバイスによって使用される、
   請求項３記載の方法。
8. 前記ビーコニングデバイスの無線範囲内のデバイス間の少なくともコンテンションベースのトラフィック用の前記１つ以上のスロットが、制御パケットを送るために前記ビーコニングデバイスによって使用されるメディアアクセスタイムを競合するために、１つ以上の前記ビーコニングデバイスによって使用される、
   請求項３記載の方法。
9. 制御パケット用のメディアアクセスタイムのコンテンションが、データパケットを送るためのメディアアクセスタイムのコンテンションよりも高い優先度を有する、
   請求項８記載の方法。
10. ビーコンメディアアクセススロットとして指定されていないスロットが、前記無線ネットワーク内のデバイス間のコンテンションフリーのデータトラフィック用の予約に利用可能である、
    請求項１記載の方法。
11. 前記無線ネットワーク内のビーコニングデバイスが、ビーコニングデバイスのビーコンメディアアクセススロットとして指定されているスロットを識別する情報を、それぞれのビーコンフレームにおいてブロードキャストする、
    請求項１記載の方法。
12. 前記無線ネットワーク内のビーコニングデバイスが、前記無線ネットワーク内のデバイス間のコンテンションフリーのトラフィック用に予約されているスロットを識別する情報を、それぞれのビーコンフレームにおいてさらにブロードキャストする、
    請求項１１記載の方法。
13. ２つ以上のビーコニングデバイスがそれら自身のビーコンメディアアクセススロットとして同じスロットを指定したことを、受信側デバイスによって識別するステップと、
    前記衝突を前記受信側デバイスによってアナウンスするステップと、
    自身のビーコンメディアアクセススロットとして同じスロットを指定した前記２つ以上のビーコニングデバイスのそれぞれによって、自身のビーコンメディアアクセススロットとして別のスロットを指定するステップと、
    前記２つ以上のビーコニングデバイスのそれぞれによって、そのビーコニングデバイスによって自身のビーコンメディアアクセススロットとして指定された前記スロットをアナウンスするステップと、
    をさらに含んでいる、
    請求項１記載の方法。
14. 複数のビーコニングデバイスがそれら自身のビーコンメディアアクセススロットとして同じスロットを指定したことを、前記複数のビーコニングデバイスによって識別するステップと、
    自身のビーコンメディアアクセススロットとして同じスロットを指定した前記２つ以上のビーコニングデバイスのそれぞれによって、自身のビーコンメディアアクセススロットとして異なるスロットを指定するステップと、
    前記２つ以上のビーコニングデバイスのそれぞれによって、そのビーコニングデバイスによって自身のビーコンメディアアクセススロットとして指定された前記スロットをアナウンスするステップと、
    をさらに含んでいる、
    請求項１記載の方法。
15. 前記識別するステップが、前記同じスロットにおけるビーコンフレームを受信するステップ、を含む請求項１３に記載の方法。
16. データパケットの送信に使用するためのメディアアクセスタイムを競合する前記ステップが、
    要求側デバイスによって予約要求パケットを１つ以上のビーコニングデバイスに送るステップであって、前記予約要求が１つ以上の使用されていないスロットを識別する、前記ステップと、
    前記１つ以上のビーコニングデバイスによって、前記予約要求への応答を送るステップと、
    前記要求側デバイスによって前記応答を集めるステップと、
    前記応答のすべてが、前記予約要求の承認を示しているかを判定するステップと、
    前記応答のすべてが前記予約要求の承認を示していることを、前記要求側デバイスによってアナウンスするステップと、
    前記アナウンスが、前記応答のすべてが承認を示したことを示している場合、データパケットを送信するために前記要求側デバイスによって予約された前記スロットをビーコニングデバイスのそれぞれによってアナウンスするステップと、
    を含む請求項７記載の方法。
17. 前記予約要求が送られた先の前記１つ以上のビーコニングデバイス以外の１つ以上のビーコニングデバイスによって、前記予約要求への異議を送るステップと、
    前記異議を前記要求側デバイスによって集めるステップと、
    をさらに含んでおり、
    前記判定するステップが、前記応答のすべてが前記予約要求の承認を示しているか否か、かつ、異議が受信されたか否かを判定する、
    請求項１６記載の方法。
18. 複数のデバイスを含んでいる無線ネットワークであって、
    前記無線ネットワーク内のアクセスが、請求項１〜１７のいずれか１項に記載の方法によって制御される、無線ネットワーク。
    

Images