(57)【要約】超広帯域ネットワーク容量の使用を改善する方法を提供する。ネットワークは複数のチャネルを含み、ネットワークは複数のデバイスをさらに含み、各デバイスは第１チャネル上に各ビーコン群を形成し、各ビーコン群は複数のデバイスに少なくとも１つの他のデバイスを含む。本方法は、ビーコン群の第２デバイスが第１チャネルを用いてデータを送信する間に、第１チャネル以外のチャネルを用いてビーコン群の第１デバイスからデータを送信する工程を含む。
2010527551.tif 000002
【特許請求の範囲】
【請求項１】
超広帯域ネットワーク容量の使用を改善する方法であって、前記ネットワークは複数のチャネルを含み、前記ネットワークは複数のデバイスをさらに含み、各デバイスは第１の前記チャネル上に各ビーコン群を形成し、各ビーコン群は前記複数のデバイスに少なくとも１つの他のデバイスを含み；前記方法は：
ビーコン群の第２デバイスが前記第１チャネルを用いてデータを送信する間に、前記第１チャネル以外のチャネルを用いて前記ビーコン群内の第１デバイスからデータを送信する工程を含む方法。
【請求項２】
前記第１デバイスが、前記第１及び第２デバイスの各ビーコン群にあるデバイスにデータを送信する請求項１に記載の方法。
【請求項３】
前記第１デバイスが、前記第２デバイスの前記ビーコン群にないデバイスにデータを送信する請求項１に記載の方法。
【請求項４】
前記第２デバイスが、前記第１及び第２デバイスの各ビーコン群にあるデバイスにデータを送信する請求項１、請求項２、又は請求項３に記載の方法。
【請求項５】
前記第２デバイスが、前記第１デバイスの前記ビーコン群にないデバイスにデータを送信する請求項１、請求項２、又は請求項３に記載の方法。
【請求項６】
前記ネットワークが、複数の隣接スーパーフレームにさらに分割され、前記方法が、前記第１スーパーフレームの開始時に、前記デバイスに対する送信スキームを決定する工程をさらに含み、前記送信スキームが、前記第１スーパーフレームでデータを送信又は受信するのに各デバイスを用いる前記複数のチャネルのチャネル（単数又は複数）を示す請求項１〜５のいずれか１項に記載の方法。
【請求項７】
送信スキームを決定する前記工程が、前記第１スーパーフレームで１つ以上のタイムスロットを示す予約要求と、使用される前記複数のチャネルで１つ以上のチャネルとを同報通信する各デバイスを含む請求項６に記載の方法。
【請求項８】
各デバイスが、前記第１スーパーフレーム開始時のビーコンピリオド中に前記予約要求を同報通信する請求項７に記載の方法。
【請求項９】
前記予約要求が、前記複数のチャネルの２つ以上のチャネル上で、前記第１スーパーフレームの非同時性タイムスロットに対する要求を含むことができる請求項７又は請求項８に記載の方法。
【請求項１０】
前記予約要求が情報要素に含まれる請求項７〜９のいずれか１項に記載の方法。
【請求項１１】
前記情報要素が、前記第１スーパーフレームでタイムスロットの可用性を示すマップを含む請求項１０に記載の方法。
【請求項１２】
前記マップが、前記第１チャネル及び少なくとも１つの前記他のチャネル上でタイムスロットの可用性を示す請求項１１に記載の方法。
【請求項１３】
前記マップ内の各チャネルを表すのに用いられるビット数が変化し、前記第１チャネルに関する前記マップの一部が、少なくとも１つの前記他のチャネルに関する前記マップの一部よりも多いビット数で表わされる請求項１２に記載の方法。
【請求項１４】
前記マップが、前記第１チャネル及び前記他のチャネルのサブセット上でタイムスロットの可用性を示す請求項１１に記載の方法。
【請求項１５】
前記マップが、前記第１チャネル及び前記他のチャネルのサブセット上でタイムスロットの可用性を示し、前記第１チャネルに関する前記マップの一部が、前記サブセット内の少なくとも１つの前記チャネルに関する前記マップの一部よりも多いビット数で表わされる請求項１２に記載の方法。
【請求項１６】
超広帯域ネットワークに使用されるデバイスであって、前記ネットワークは、複数のチャネルを含み、前記デバイスは、第１の前記チャネル上で少なくとも１つの他のデバイスとビーコン群を形成するようになっており、前記デバイスはさらに、前記ビーコン群の前記少なくとも１つの他のデバイスが前記第１チャネルを用いてデータを送信する場合、前記第１チャネル以外のチャネルを用いて第２デバイスにデータを送信するようになっているデバイス。
【請求項１７】
前記チャネルが、複数の隣接スーパーフレームに分割され、前記デバイスがさらに、前記第１スーパーフレーム内の１つ以上のタイムスロットと、使用される前記複数のチャネルのチャネル（単数又は複数）とを示す予約要求を同報通信するようになっている請求項１６に記載のデバイス。
【請求項１８】
前記デバイスが、前記第１スーパーフレーム開始時のビーコンピリオド中に前記予約要求を同報通信するようになっている請求項１７に記載のデバイス。
【請求項１９】
前記予約要求が、前記複数のチャネル内の２つ以上のチャネル上で、前記第１スーパーフレームの非同時性タイムスロットに対する要求を含むことができる請求項１７又は請求項１８に記載のデバイス。
【請求項２０】
前記デバイスが、情報要素に前記予約要求を含むようになっている請求項１７〜１９のいずれか１項に記載のデバイス。
【請求項２１】
前記情報要素が、前記第１スーパーフレームでタイムスロットの可用性を示すマップを含む請求項２０に記載のデバイス。
【請求項２２】
前記マップが、前記第１チャネル及び少なくとも１つの前記他のチャネル上でタイムスロットの可用性を示す請求項２１に記載のデバイス。
【請求項２３】
前記マップの各チャネルを表すのに用いられるビット数が変化し、前記第１チャネルに関する前記マップの一部が、少なくとも１つの前記他のチャネルに関する前記マップの一部よりも多いビット数で表わされる請求項２２に記載のデバイス。
【請求項２４】
前記マップが、前記第１チャネル及び前記他のチャネルのサブセット上でタイムスロットの可用性を示す請求項２１に記載のデバイス。
【請求項２５】
前記マップが、前記第１チャネル及び前記他のチャネルのサブセット上でタイムスロットの可用性を示し、前記第１チャネルに関する前記マップの一部が、前記サブセットの少なくとも１つの前記チャネルに関する前記マップの一部よりも多いビット数で表わされる請求項２２に記載のデバイス。
【請求項２６】
複数のデバイスを含み、少なくとも１つのデバイスが、請求項１６〜２５のいずれか１項に記載のものである超広帯域ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークの利用可能容量の使用を改善する方法及び装置に関し、特に、超広帯域ネットワークの利用可能容量の使用改善に関する。
【背景技術】
【０００２】
超広帯域は、３．１〜１０．６ＧＨｚの非常に広い周波数範囲にわたってデジタルデータを送信する無線技術である。広帯域幅にわたってＲＦエネルギーを拡散することで、送信信号は、従来の周波数選択性ＲＦ技術では実質的に検出不可能である。しかしながら、低い送信電力は、通信距離を一般に１０〜１５メートル未満に制限する。
【０００３】
ＵＷＢには２つの手法がある。即ち、ＵＷＢ特性をもつパルス波形から信号を構築する時間領域手法と、従来の、多重（周波数）バンドによるＦＦＴベースの直交波周波数分割多重（ＯＦＤＭ）を用いて、ＭＢ−ＯＦＤＭを行う周波数領域変調手法とである。両方のＵＷＢ手法は、周波数スペクトルにおいて非常に広い帯域幅を網羅するスペクトル成分を生じ、そのため超広帯域という用語が使用され、それにより、帯域幅は、中心周波数の２０パーセント以上を占め、一般に少なくとも５００ＭＨｚである。
【０００４】
非常に広い帯域幅と組み合わせた超広帯域のこれらの特性は、ＵＷＢが家庭又はオフィス環境で高速無線通信を提供するための理想的な技術であることを意味し、それにより、通信デバイスは互いに１０〜１５ｍの範囲内となる。
【０００５】
図１は、超広帯域通信用のマルチバンド直交波周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数バンドの配置を示す。ＭＢ−ＯＦＤＭシステムは、各々が５２８ＭＨｚの１４個のサブバンドを備え、アクセス方式としてサブバンド間で３１２ｎｓごとにホップする周波数を用いる。各サブバンド内で、ＯＦＤＭ及びＱＰＳＫ又はＤＣＭコーディングをデータ送信に用いる。約５ＧＨｚ、現在、５．１〜５．８ＧＨｚのサブバンドは、例えば、８０２．１１ａＷＬＡＮシステム、安全保障局の通信システム、又は航空産業の既存の狭帯域システムとの混信を避けるため空白のままであることに留意されたい。
【０００６】
１４個のサブバンドは５つのバンド群に構成され：４つは５２８ＭＨｚのサブバンドを３つ有し、１つは５２８ＭＨｚのサブバンドを２つ有している。図１に示すように、第１のバンド群は、サブバンド１と、サブバンド２と、サブバンド３とを備える。例示のＵＷＢシステムは、第１のデータシンボルをバンド群の第１の周波数サブバンドにおいて第１の３１２．５ｎｓ長の間隔で送信し、第２のデータシンボルをバンド群の第２の周波数サブバンドにおいて第２の３１２．５ｎｓ長の間隔で送信し、尚且つ、第３のデータシンボルをバンド群の第３の周波数サブバンドにおいて第３の３１２．５ｎｓ長の間隔で送信するように、バンド群のサブバンド間をホップする周波数を用いる。従って、各間隔の間、データシンボルは、５２８ＭＨｚの帯域幅をもつそれぞれのサブバンド、例えば、３９６０ＭＨｚを中央にした５２８ＭＨｚのベースバンド信号をもつサブバンド２に送信される。
【０００７】
各データシンボルが送信される３つの周波数のシーケンスは、時間周波数コード（ＴＦＣ）チャネルを表わす。第１のＴＦＣチャネルは、１、２、３、１、２、３のシーケンスに従うことができる。ここで、１は第１のサブバンド、２は第２のサブバンド、３は第３のサブバンドである。第２及び第３のＴＦＣチャネルは、それぞれ、１、３、２、１、３、２、及び、１、１、２、２、３、３のシーケンスに従うことができる。ＥＣＭＡ−３６８仕様に従って、７つのＴＦＣチャネルを第１の４つのバンド群ごとに定義し、２つのＴＦＣチャネルを第５のバンド群に定義する。５つのバンド群におけるＴＦＣチャネルごとのシーケンスを図２（ａ）〜図２（ｅ）に示す。
【０００８】
超広帯域の技術的特性は、データ通信領域における用途に展開されることを意味する。例えば、以下の環境においてケーブル交換を目的とする広範囲の用途が存在する：
−ＰＣと、周辺機器、即ち、ハードディスク・ドライブ、ＣＤライター、プリンター、スキャナーなどの外部デバイスとの間の通信。
−無線手段、無線スピーカー等によって接続されるテレビやデバイスなどの家庭用娯楽機器。
−例えば、携帯電話とＰＤＡ、デジタルカメラとＭＰ３プレーヤー等の携帯端末とＰＣとの間の通信。
【０００９】
ＵＷＢネットワークなどの無線ネットワークでは、１つ以上のデバイスは、ビーコンピリオド中にビーコンフレームを周期的に送信する。ビーコンフレームの主目的は、媒体上にタイミング構造を提供すること、即ち、時間をいわゆるスーパーフレームに分割することであり、尚且つ、ネットワークデバイスを隣接デバイスと同期化させることである。
【００１０】
ＵＷＢシステムの基本的なタイミング構造は、図３に示すようなスーパーフレームである。欧州電子計算機工業会規格（ＥＣＭＡ）、ＥＣＭＡ−３６８第２版によるスーパーフレームは、２５６個の媒体アクセススロット（ＭＡＳ）からなり、各ＭＡＳは規定の持続時間、例えば、２５６マイクロ秒を有する。各スーパーフレームはビーコンピリオドから開始され、１つ以上の隣接ＭＡＳまで継続し、その間、デバイスはビーコンフレームを送信することができる。ビーコンピリオドにおける第１のＭＡＳの開始は、ビーコンピリオド開始時間（ＢＰＳＴ）として知られている。特定のデバイスのビーコン群は、特定のデバイスと共有のビーコンピリオド開始時間（±１マイクロ秒）を有し、尚且つ、特定のデバイスの送信距離内であるデバイスグループとして定義される。
【００１１】
ＥＣＭＡ−３６８では、通信デバイスからのデータ送信は、単一に割り当てられた時間周波数コード（ＴＦＣ）チャネルにわたって媒体アクセススロット（ＭＡＳ）の明示グループに運ばれる。デバイス間のマッピングと使用されるＭＡＳ（即ち、どのデバイスペアが通信しているのか、どの媒体アクセススロット（単数又は複数）かの表示）は、各スーパーフレームの開始時にビーコンピリオドで各デバイスにより通信される。ＭＡＳがハードＤＲＰ予約ではない場合、若しくは、ハードＤＲＰ又はプライベート予約ＭＡＳが放棄される場合、デバイスは、未予約のＭＡＳでデータを交換することもできる。
【００１２】
現行のＥＣＭＡ−３６８標準によれば、個々のデバイスは、適切なＴＦＣチャネルに入り、他に指示がない限り、この単一チャネルで適宜に送信／受信する。デバイス（単数又は複数）により使用されるＴＦＣチャネルの変更は、上位層により管理され、現在のスーパーフレームの完了が必要となる。
【００１３】
ＴＦＣチャネルを切り替える機能が限定されている結果、いくつかの利用可能なＴＦＣチャネルを有効としない、又は、デバイスペアと関連付けないことができる。
【００１４】
従って、ＵＷＢシステムの容量の大半は、特定のスーパーフレーム中に未使用のままにすることができる。
【００１５】
上記欠点を解消するため動的チャネル切り替えを可能にする２つのスキームがＩＥＥＥ８０２．１１に対して提案されている。
【００１６】
前者は、共通制御チャネル（Ｍａｔｈｉｌｄｅ  Ｂｅｎｖｅｎｉｓｔｅ、ＩＥＥＥ  Ｐ８０２．１１、ｄｏｃ．ＩＥＥＥ８０２．１１−０５／０６６６ｒ３、１２ｔｈ、２００５年９月によるＣＣＣ  ＭＭＡＣプロトコルに記載されている）と呼ばれている。これは、特定のスロットがいつ予約されるか他のデバイスに通知されるよう、デバイスがチャネル予約を行い、共通制御チャネル上でこれを同報通信する必要がある。しかしながら、このプロトコルを実施することは、各デバイスが、共通制御チャネルを常時監視するため第２の無線インタフェースを持たなければならないことを意味する。
【００１７】
第２のスキームは、Ｊｕｎｇｍｉｎ  Ｓｏ及びＮｉｔｉｎ  Ｖａｉｄｙａによる「Ｍｕｌｔｉ−Ｃｈａｎｎｅｌ  ＭＡＣ  ｆｏｒ  Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋｓ：Ｈａｎｄｌｉｎｇ  Ｍｕｌｔｉ−ｃｈａｎｎｅｌ  Ｈｉｄｄｅｎ  Ｔｅｒｍｉｎａｌｓ  Ｕｓｉｎｇ  Ａ  Ｓｉｎｇｌｅ  Ｔｒａｎｓｃｅｉｖｅｒ」、ＭｏｂｉＨｏｃ’０４の会報、２００４年５月２４〜２６日、日本に記載されている。このスキームでは、デバイス間の同期化が必要であるが（恐らく、８０２．１１タイミング同期機能（ＴＳＦ）を用いて）、マルチホップ接続に対しては同期化が失敗する場合がある。チャネルは、アドホックトラフィックインデケーションマップ（ＡＴＩＭ）ウィンドウ中に予約され、ウィンドウの大きさは動的に可変である。ＡＴＩＭウィンドウ中に、デバイスは、使用されるチャネルについてのみ承諾する。次いで、デバイスは、スーパーフレームの期間（ＭＡＳの期間よりもかなり大きい）中にチャネルを使用する。このスキームの結果の１つは、ロードバランシングの問題を生じるため、ネットワークのスループットが実際には改善されない場合がある。
【００１８】
従って、通信ネットワークの利用可能容量の使用改善が可能であり、上記のスキームの欠点を解消する方法及び装置が必要とされている。
【発明の概要】
【００１９】
本発明の第１の態様によれば、超広帯域ネットワーク容量の使用を改善する方法を提供する。ネットワークは複数のチャネルを含み、ネットワークは複数のデバイスをさらに含み、各デバイスは第１チャネル上に各々のビーコン群を形成し、各ビーコン群は複数のデバイスに少なくとも１つの他のデバイスを含む。本方法は、ビーコン群の第２デバイスが第１チャネルを用いてデータを送信する間に、第１チャネル以外のチャネルを用いてビーコン群の第１デバイスからデータを送信する工程を含む。
【００２０】
本発明の第２の態様によれば、超広帯域ネットワークに使用されるデバイスを提供する。ネットワークは、複数のチャネルを含み、デバイスは、第１チャネル上で少なくとも１つの他のデバイスとビーコン群を形成するようになっており、デバイスはさらに、ビーコン群の少なくとも１つの他のデバイスが第１チャネルを用いてデータを送信する場合、第１チャネル以外のチャネルを用いて第２デバイスにデータを送信するようになっている。
【００２１】
本発明の第３の態様によれば、複数のデバイスを含み、少なくとも１つのデバイスが上述のものである超広帯域ネットワークを提供する。
【００２２】
添付図面を参照しながら、単なる例として本発明を詳細に説明する。
【図面の簡単な説明】
【００２３】
【図１】超広帯域通信のマルチバンド直交波周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数帯の配置構成を示す。
【図２（ａ）】５つのバンド群各々のＴＦＣチャネルのシーケンス定義を示す。
【図２（ｂ）】５つのバンド群各々のＴＦＣチャネルのシーケンス定義を示す。
【図２（ｃ）】５つのバンド群各々のＴＦＣチャネルのシーケンス定義を示す。
【図２（ｄ）】５つのバンド群各々のＴＦＣチャネルのシーケンス定義を示す。
【図２（ｅ）】５つのバンド群各々のＴＦＣチャネルのシーケンス定義を示す。
【図３】ＵＷＢシステムにおけるスーパーフレームの基本的なタイミング構造を示す。
【図４】連続する２つのスーパーフレーム上の７つのＴＦＣチャネルのタイミング構造を示す。
【図５】ネットワークを形成するデバイスグループの一例を示す。
【図６】従来技術による図５のネットワークでデバイス間のデータ送信を示す図である。
【図７】本発明の実施形態による図５のネットワークでデバイス間のデータ送信を示す図である。
【図８】本発明によるデバイスの起動方法を示すフローチャートである。
【図９（ａ）】本発明によるネットワークで４台のデバイス間のデータ送信スキームの一例を示す。
【図９（ｂ）】本発明によるネットワークで４台のデバイス間のデータ送信スキームの一例を示す。
【図１０（ａ）】本発明によるネットワークで６台のデバイス間のデータ送信スキームの一例を示す。
【図１０（ｂ）】本発明によるネットワークで６台のデバイス間のデータ送信スキームの一例を示す。
【図１１】本発明の実施形態によるチャネル制御オクテットの形式を示す。
【図１２】本発明の実施形態による可用性情報要素の形式を示す。
【図１３】本発明の実施形態による別の可用性情報要素の形式を示す。
【図１４】本発明の実施形態によるさらに別の可用性情報要素の形式を示す。
【図１５】本発明の実施形態による情報要素の形式を示す。
【図１６】本発明の実施形態によるＤＲＰ割り当てフィールドの形式を示す。
【発明を実施するための形態】
【００２４】
超広帯域通信ネットワークを参照しながら本発明について説明するが、本発明は、他種類の通信ネットワークにも適用可能であることを理解されたい。
【００２５】
図４は、スーパーフレームの媒体アクセススロット数により測定される、連続する２つのスーパーフレームにわたる７つのＴＦＣチャネルの構造を示す。第１スーパーフレームのビーコンピリオドは、多くても、第１の３３個の媒体アクセススロットの間にＴＦＣｘ１で送信され（ビーコンピリオドの長さは可変であることを理解されたい）、データ期間（ＤＰ）は、以下の２２３個以上の媒体アクセススロットにわたって提供される。
【００２６】
図４を参照しながら、標準ＥＣＭＡ−３６８仕様に従って、２台のデバイスが、その間にデータフローを確立している状況を考えてみる。これらのデバイスは、第１チャネルであるＴＦＣｘ１を用いて、データを運ぶ。スーパーフレーム開始時のビーコンピリオド（ＢＰ）のコンテンツは、データ期間（ＤＰ）でどのスロット（ＭＡＳ）が送信されたデータを保持しているかを示す。２台のデバイスの近傍内で他のデバイスが残りの６つのチャネル（ＴＦＣｘ２〜ＴＦＣｘ７）のいずれも利用していないものと仮定すると、これらのチャネルの各々と関連付けられたデータ期間（ＤＰ）は使用されていないことは明らかである。
【００２７】
ネットワークで複数のデバイスにおいても同様の状況が存在する。ネットワークの一例を図５に示す。これは、４台のデバイスである、第１デバイス１、第２デバイス２、第３デバイス３、および第４デバイス４を含む。デバイス間の矢印は、ネットワークで様々なデバイスペア間でデータが送信される方向を示す。以下、全てのデバイスが互いに送信距離内にあり、共有のビーコンピリオド開始時間（±１マイクロ秒）を有しているものとする。従って、各デバイスのビーコン群は、他の３台のデバイスの各々を含む。
【００２８】
以下、説明を簡単にするために、各データ期間が同サイズの７つのＭＡＳ「セット」に分割され、各データフロー又は要求（即ち、シンボルの特定数）が送信されるこれらのスロットセットを２つ必要とすることに留意されたい。
【００２９】
図６は、これら３つのデータフローが従来のＥＣＭＡ−３６８標準システムでどのように処理されるかを示す。ビーコンピリオド中、４台のデバイス１、２、３、及び４の各々は、次のデータ期間で他のデバイスに送信する必要があるデータの詳細又はそのリソース予約要求を送信し、データ期間における７つの「スロット」の使用は、それに応じて決められる。
【００３０】
そのため、従来のシステムでは、第２デバイス２が、データ期間の最初の２つのスロットで第４デバイス４にそのデータを送信し、第１デバイス１が、データ期間の第３及び第４スロットで第２デバイス２にそのデータを送信し、第３デバイス３が、データ期間の第５及び第６スロットで第４デバイス４にそのデータを送信する。従って、使用できるＴＦＣチャネルが１つだけであるため、別々の３つのデータ送信は連続的に行われる。
【００３１】
ここでも、４台のデバイスの近傍内に他のデバイスがなく、他のデバイスが残りの６つのチャネル（ＴＦＣｘ２〜ＴＦＣｘ７）のいずれも利用していないものと仮定すると、これらのチャネルの各々と関連付けられたデータ期間（ＤＰ）は使用されていないことは明らかである。
【００３２】
本発明によれば、仮想マルチチャネル動作（ＶＭＣＯ）と暫定的に称するスキームを提供する。ここで、これらの空きチャネル及びこれらのデータ期間は、最初に利用されたチャネルと現在関連付けられているデバイス間でデータ（追加又はその他）を運ぶのに使用することができる。
【００３３】
これらのさもなくば空きのチャネルが、データを運ぶのに使用されるため、ビット毎秒で利用可能な全容量やスーパーフレーム当たりの利用可能なデータ期間スロットの数は増加し、遅延が減少し、スループットが改善される。この利点の１つは、トラフィックフローのピークを処理する効率が向上するのみならず、サポートできるアクティブノードペア数が増加する。
【００３４】
図７は、図５のネットワークの３つのデータフローが本発明によるＶＭＣＯスキームでどのように処理できるのかを示す。ＴＦＣチャネルの１つ、図７ではＴＦＣｒ上のビーコンピリオド中、４台のデバイス１、２、３、及び４の各々は、次のデータ期間で他のデバイスに送信する必要があるデータの詳細又はそのリソース予約要求を送信し、従来のものと同様に、スーパーフレームの送信用スロットを予約する。しかしながら、他のＴＦＣチャネル（図７で「ＴＦＣｘ」及び「ＴＦＣｙ」と表示）のデータ期間が未使用になるかどうか判断する。未使用である場合、最適なチャネル使用をするために、デバイスに対し送信スキームを決定する。従って、デバイスは、スーパーフレームでいくつか又は全部のデータを送信するため、他のチャネル（以下、「仮想」チャネルとして知られる）上でスロットを予約することができる。いつどこでチャネルを切り替えるかについての第３デバイス３及び第４デバイス４に関する情報は、本願明細書で後述するように、ＴＦＣｒのビーコンピリオドで送信される情報要素に含まれるのが好ましい。
【００３５】
従って、図７に示すように、従来のシステムと同様、第２デバイス２が、ＴＦＣｒにおいてデータ期間の最初の２つのスロットで第４デバイス４にそのデータを送信し、第１デバイス１が、ＴＦＣｒにおいてデータ期間の第３及び第４スロットで第２デバイス２にそのデータを送信する。しかしながら、第３デバイス３及び第４デバイス４は、ＴＦＣｒ上の第３及び第４スロットで行う送信と無関係であるため、第３デバイス３及び第４デバイス４は、さもなくば空きのチャネル（「仮想」チャネル）、この場合、ＴＦＣｘを使用することができる。従って、第３デバイス３が、ＴＦＣｘのデータ期間の第３及び第４スロットで第４デバイス４にそのデータを送信する。従って、多数のＴＦＣを使用できるので、別々の３つのデータ送信のうちの２つを同時に行う、その結果、３つの送信は、図６に示す従来のシステムよりも短時間で完了する。
【００３６】
第３デバイス３及び第４デバイス４がデータを送信後、デバイス３、４は、その後の予約されていない通信、及び／又は、次のビーコンピリオドのため、共通チャネル（ＴＦＣｒ）に切り替わる。
【００３７】
実質的に、本発明により、非アクティブであるが、送信スロットを待っているデバイスペアは、スーパーフレームでチャネルを切り替え、さもなくば未使用となる別のチャネル上のスロットでデータを送信することが可能となる。デバイスは、スーパーフレームの各タイムスロット（ＭＡＳ）でチャネルを切り替えることができることに留意されたい。
【００３８】
いつどこで個々のデバイスが切り替わるのかに関する情報は、デバイスに共通のチャネル上のビーコンピリオド中に送信される情報要素（ＩＥ）に含まれるのが好ましい。すなわち、デバイス間のＶＭＣＯスキームを実行することができるのは、特定ビーコン群のデバイスである。他のチャネル上のビーコンピリオドに信号が無い又は欠如していることは、これらのチャネル上の現在のスーパーフレームのデータ期間が空であることを示すことができる。従って、このスキームを用いて、各デバイスは、共通のＴＦＣ（図７ではＴＦＣｒ）と関連付けられるが、ビーコンピリオドで提供された情報に従って、さもなければ空の他のＴＦＣ（図７ではＴＦＣｘ）を通じてデータを受信又は送信することができる。
【００３９】
一実施形態では、各デバイスは、ネットワークの多重チャネルに対するリソース予約要求として情報要素を用いる。
【００４０】
超広帯域通信システムの既存の物理層（ＰＨＹ）の仕様は、タイミングや同期化／アラインメントの問題という点において、ＥＣＭＡ−３６８標準デバイスは、デバイスハードウェアを実質的に変えることなくＶＭＣＯスキームを実行できるように、チャネル切り替えやアラインメント／同期化を十分に早く行うことができることを示している。ＶＭＣＯスキームを用いる全てのデバイスは、共通チャネルのビーコンピリオドにより同期化され、配列されるため、同じ共通の時間表現を共有する。他のチャネルのデータ期間は、ビーコン群が使用するチャネルの仮想データ期間として、或いは、時間及び周波数次元の両方で整理されるデータ期間としても考えられる。
【００４１】
ＶＭＣＯデバイスは、種々の方法で他のＶＭＣＯ対応デバイスを検出することができる。これを達成する方法の１つは、デバイスがＥＣＭＡ−３６８標準により提供されるＭＡＣ機能のＩＥ（ＭＡＣ  Ｃａｐａｂｉｌｉｔｉｅｓ  ＩＥ）を使用することであり：ＭＡＣ機能ビットマップの可用ビットの１つ（ＥＣＭＡ−３６８仕様の図８１に示されるように）を用いて、ＶＭＣＯ機能をフラグすることができる。
【００４２】
別の方法としては、特定用途向けＩＥを使用することである。特定用途向けＩＥは、供給業者により使用され、特定用途向けの機能を提供することができ、形式は、供給業者自身により提供される。従って、供給業者は、そのようなＩＥを用いてＶＭＣＯ機能を示すことができる。
【００４３】
図８は、本発明によるデバイスの起動方法を示す。ステップ１０１で、デバイスに電源を投入する。ステップ１０３で、デバイスがＶＭＣＯスキームを使用したい場合、デバイスは、１スーパーフレームのビーコンピリオドでＶＭＣＯビーコンフレームに利用可能なチャネルをリッスンする。一実施形態では、デバイスは、ビーコンピリオドのＶＭＣＯ情報要素（ＩＥ）をリッスンする。別の実施形態では、デバイスは、ＭＡＣヘッダフィールド内の予約ビットをリッスンし、これは、送信しているデバイスがＶＭＣＯ可能であることを示すものである。
【００４４】
デバイスがビーコンフレームを何も検出しない場合、デバイスは、フリー又は使用可能なものとしてチャネルをマークする。デバイスが特定のＴＦＣチャネル上でビーコンフレームを検出し、ビーコンフレームヘッダが有効なフレームチェックシーケンス（ＦＣＳ）により検出される場合、デバイスは、そのＴＦＣチャネルを用いて他のデバイスからビーコン信号を受信することができ、チャネルは使用中とマークされる。このチャネルは、従来のデバイス又はＶＭＣＯ対応デバイスにより使用中であり得ることに留意されたい。デバイスが特定のＴＦＣチャネル上のビーコンフレームを検出し、これが、無効なフレームチェックシーケンス（ＦＣＳ）によるビーコンフレームヘッダを有する場合、デバイスは、別のスーパーフレームのＴＦＣチャネル上でリッスンを継続する。有効なＦＣＳをその後に受信する場合、デバイスは上記のように動作する。しかしながら、有効なＦＣＳをその後に受信しない場合、デバイスは、チャネルのアクティビティを検出できるが、チャネルに関するさらなる情報を入手することはできない。そのため、デバイスは、チャネルを使用中とマークする。
【００４５】
１つのＴＦＣチャネルをスキャニング又はモニタリングした後、デバイスは、次又は別のＴＦＣチャネルに切り替え、全てのＴＦＣチャネルがモニタリングされるまで、上述の処理を繰り返す。
【００４６】
ステップ１０５で、デバイスは、適当な、又はいくつかの、ＶＭＣＯビーコン群信号が見つかったかどうかを判断する。そうである場合、デバイスは、例えば、ＥＣＭＡ−３６８仕様のセクション１７．２に記載されている従来の方法で、ＶＭＣＯビーコン群に入る（ステップ１０７）。従って、デバイスは、次のビーコンピリオドの可用スロットでビーコン信号を送信する。加入手順における任意のコリジョンが解決されると、デバイスは、ネットワークで他のデバイスとの通信を開始することができる。
【００４７】
ビーコン群又は適当なビーコン群が見つからない場合、デバイスは、チャネルを選択し、ビーコンフレームを送信することで新たなビーコン群を生成し、これは、上記のようにＶＭＣＯが可能であることを示すいくつかのシグナル伝達を含む（ステップ１０９）。例えば、デバイスは、ＭＡＣヘッダフィールドの予約ビット又は情報要素（ＩＥ）のビットを使用することができる。ＶＭＣＯビーコン群は、共通チャネル（従って、共通ビーコンピリオド）及び一連の関連ＶＭＣＯチャネル（即ち、現行のスーパーフレームで未使用であるチャネル）と関連付けられた多数のＶＭＣＯデバイスを含む。
【００４８】
以下に示す図では、デバイスに共通で、尚且つ、ＶＭＣＯ情報要素（好ましい実施形態で）を含むチャネルは、「ランデブーチャネル」と以下で呼び、ＴＦＣｒと表示される。関連した空きチャネルは、ＴＦＣｘ及びＴＦＣｙと表示される。以下の説明のために、全てのデバイスは、ＶＭＣＯ対応デバイスであるものとし、ＶＭＣＯビーコン群が構築されており、安定であるものとする。
【００４９】
図９（ａ）及び図（ｂ）は、本発明によるネットワークで４台のデバイス間のデータ送信に対するスキームの一例を示す。図９（ａ）では、４台のデバイスを含むネットワークを示し、上記のように、デバイス間の矢印は、ネットワークで様々なデバイスペア間でデータが送信される方向を示す。従って、送信される６つのデータフローが存在する。デバイスのビーコン群は、ネットワークの他のデバイスを全て含むことも分かる。
【００５０】
図９（ｂ）は、様々なデバイスが、ＶＭＣＯスキームに従ってデータを送信する場合を示す。従って、第２デバイス２は、ランデブーチャネルであるＴＦＣｒ上でデータ期間の最初の２つのスロットで第４デバイス４にデータを送信する。同時に、第３デバイス３は、第１空き／仮想チャネルであるＴＦＣｘ上で第１デバイス１にデータを送信する。データ期間の次の２スロットでは、第１デバイス１が、ランデブーチャネルであるＴＦＣｒを用いて第２デバイス２にデータを送信し、（第１デバイス１は、第２及び第３スロット間でチャネルを切り替える）、第３デバイスは、第１空きチャネルであるＴＦＣｘを用いて第４チャネルにデータを送信する。第５及び第６スロットでは、第３デバイス３は、ランデブーチャネルであるＴＦＣｒを用いて第２デバイス２にデータを送信し、第４デバイス４は、第１空きチャネルであるＴＦＣｘを用いて第１デバイス１にデータを送信する。
【００５１】
図１０（ａ）及び図（ｂ）は、６台のデバイス１、２、３、４、５、及び６を含むネットワークでＶＭＣＯスキームを用いる効果を示す。この例では、第２空きチャネルであるＴＦＣｙもデータ送信に使用される。従って、データ期間の第３及び第４スロットでは、３つの別々の送信が、３つの異なるチャネル、ランデブーチャネルであるＴＦＣｒと２つの仮想チャネルであるＴＦＣｘ及びＴＦＣｙ上で行われる。
【００５２】
この例では、共通ビーコン群（即ち、デバイスのビーコン群は、ネットワークの他のデバイスを全て含む）のデバイスを示しているが、いくつかの実施形態では、各デバイスは、ネットワークにおける他のデバイス各々のビーコン群の一部である必要は必ずしもないことを理解されたい。
【００５３】
しかしながら、データ送信に仮想チャネルを使用することができるのは、共通ビーコン群にあるデバイスだけではない。再び、図１０（ａ）及び図１０（ｂ）を参照し、デバイス３及びデバイス５の両方はデバイス６のビーコン群であるが、デバイス間の距離、及び／又は、それぞれのＢＰＳＴの開始間のオフセットにより、デバイス５はデバイス３のビーコン群ではないものとする（逆もまた同様）。この場合、デバイス６が、ＴＦＣｒ上でデバイス５（デバイス６のビーコン群である）にそのデータを送信する間、デバイス３は、ＴＦＣｘ上でデバイス４（デバイス３のビーコン群である）にそのデータを送信することができる。従って、デバイス６の立場から言えば、デバイス３は、仮想チャネルを用いて、デバイス６のビーコン群の外側にあるデバイスにデータを送信する。
【００５４】
上記のＶＭＣＯスキームは、従来のシステムを上回る多くの利点を提供する。提案した方法でチャネルを切り替え可能なデバイスは、２つ以上のチャネルからスロットにアクセスし；可用ビット毎秒及びスーパーフレームにつきのスロットを増やすことで、エアーインタフェースリソースの利用を向上させる。これにより、よりアクティブなデバイスペアリングをサポートする機能を提供するとともに、遅延を減少し、スループットを改善する。デバイスが２つ以上の異なるチャネル上で同時に送信又は受信することができない制約を条件として、潜在的な追加の利用可能容量は、「空き」チャネル数のオーダである。
【００５５】
単一バンド群（図１に示すように）内の空き／仮想チャネルの使用を参照しながら本発明について説明したが、当業者であれば、デバイスは仮想チャネルとして他のバンド群から１つ以上のＴＦＣチャネルを識別し、使用できることが分かるであろう。
【００５６】
スーパーフレーム内のチャネルを切り替える機能により、フルチャネル切り替えを起動する必要が無くなり、かかる大規模な変化が引き起こす混乱も回避される。かかる「オンザフライ」のチャネル切り替え機能により、データフローの動的な小規模の変化を管理することができ、より詳細には、高スループットのバーストモードトラフィックの管理を支援することができる。
【００５７】
多数のＶＭＣＯ群は共存でき、ネットワークの利用可能な空きチャネル数によって制限されるだけである。
【００５８】
ＶＭＣＯスキームでは、デバイスが単一の無線インタフェースを有することを要するだけである。これにより、実行コストが低くなる。
【００５９】
最後に、ＶＭＣＯスキームにより、個々のデバイスが多数のデバイスと通信する必要がある場合、例えば、ユーザがいくつかの相互接続されたデバイスにわたってゲームをプレイしたい場合の高密度相互接続環境への超広帯域ネットワークの適用性が改善される。
【００６０】
上記の利点を提供することに加え、ＶＭＣＯ非対応デバイスはランデブーチャネル上のビーコンピリオドにおいてＶＭＣＯ特定情報要素を無視する（又は検出不能である）ため、本発明によるＶＭＣＯスキームは、これらのデバイスと完全な下位互換性がある。しかしながら、これらのデバイスは、標準ＥＣＭＡ−３６８に従って既存のビーコン群に入ることができる。
【００６１】
従来のデバイスは、さもなければ、ＶＭＣＯ群により「仮想」チャネルとして使用される「空き」チャネル上でビーコン群に入る又は確立することができる。これは、ＶＭＣＯ非対応デバイスがそのチャネル上のビーコンピリオド中にそれらの存在を単にアサート又は確立することを意味するため、「仮想」チャネルを使用しようとする又は使用するつもりのＶＭＣＯデバイスとのコリジョンを引き起こす。これらのＶＭＣＯデバイスは、バックオフし、ＶＭＣＯ群が別のチャネルを見つけるよう、及び／又は、これらのスロットを別の「空き」チャネルに再割り当てるようにする。ネットワークにおける従来のデバイス、又は、ＶＭＣＯスキームに適用しないデバイスの存在下で、システムの動作は、標準ＥＣＭＡ−３６８のものにデフォルトすることを意味する。
【００６２】
ネットワーク容量の使用改善は、以下のように表わすことができる。１４台のデバイスを組み合わせ、７つの同時に独立接続（デバイス／ノードペア）を形成する例を考えてみる。７つの媒体アクセススロットを有する単一チャネルが利用可能であり、全ての接続が媒体上で同一の時間を必要とする場合、各接続は、スーパーフレームにつき１つのＭＡＳが与えられる。しかしながら、６つの他の空きチャネルが利用可能な場合、各デバイスペアは、それぞれ、別々のチャネルを使用することができる。これは、データスループットが７倍増加することを意味する。
【００６３】
以下の演算では、スーパーフレーム中の利用可能な送信時間について考えてみる。全ての場合において、媒体の実効スループットは、ＭＩＦＳ（最小インターフレームスペーシング）、ＡＩＦＳ（任意インターフレームスペーシング）、ＳＩＦＳ（ショートインターフレームスペーシング）、及びガード時間などのインターフレームスペーシングの挿入により、一般に見積もったデータ転送速度未満である。多重チャネル間のデバイス切り替えを可能にすることで、スループットに影響を及ぼす追加の減衰因子はない。
【００６４】
超広帯域仕様によれば、各スーパーフレームは、６５．５３６ｍｓ（２５６ＭＡＳｓ）間継続する。１つのチャネル上で利用可能な送信時間は、６５．５３６×Ｒｍｓに等しく、ここで、Ｒは、ＥＣＭＡ３６８標準のスーパーフレーム構造で導入される減衰因子である。
Ｒ＝（データ期間長）／（ビーコンピリオド長＋データ期間長）。
【００６５】
ビーコンピリオドが最大数のデバイス（９６）によって占められる場合、Ｒは、最小値の８７％を有する。
【００６６】
しかしながら、２つ以上のチャネルが利用可能であるため、データ送信に利用可能な時間は、使用されているチャネル切り替えスキーム及びＭＡＳ割り当てスキームに参加している利用可能なチャネル数の関数である。しかしながら、媒体上の利用可能な最大の総送信時間（但し、チャネル及びデータスロットの最適な割り当てポリシーが、デバイス間のトラフィック要求に対して可能であるとする）は：
６５．５３６×Ｒ×７ｍｓ／スーパーフレームである。
【００６７】
ＶＭＣＯ動作に利用できないチャネル数は、ＭＡＳごとにチャネルを切り替える機能を持たない従来のデバイスの数による。従来のデバイスが存在しない場合、同一のビーコン群におけるデバイスの送信時間の可用性に対する向上は、最大で：
（６５．５３６×７−６５．５３６）／６５．５３６＝６００％である。
【００６８】
２チャネルのみが切り替えに利用可能な場合、改善は最大で１００％に減少する。いずれにしても、少ないチャネル数の共有化であっても利用可能容量を著しく増大できることが分かる。
【００６９】
以上のように、情報要素は、ランデブーチャネルのビーコンピリオドでデバイスにより送信され、ランデブーチャネルのタイムスロットと、関連した空きチャネルのタイムスロットとのリソース予約要求を含む。これらのリソース予約要求は、分散リソースプロトコル（ＤＲＰ）に従うことができる。
【００７０】
ＥＣＭＡ３６８標準は、ＤＲＰ予約に関する２つの情報要素を定義する。それは、ＤＲＰ可用性ＩＥ及びＤＲＰ  ＩＥである。
【００７１】
ＤＲＰ可用性ＩＥを用いて、スーパーフレーム内に作られたＤＲＰ予約のデバイスのカレントビューを送信する。ＤＲＰ可用性ＩＥは、予約される、或いは、他のデバイスによりすでに予約されたスーパーフレームでＭＡＳを示すＤＲＰ可用性ビットマップを含む。スーパーフレームの使用済セクションのマップのみを送信する必要があるため、ＤＲＰ可用性ＩＥのビットマップ部分は、０〜３２バイトの可変長を有する。従って、スーパーフレームの末端のＭＡＳが未使用の場合、ビットマップのデータ量は減少する。ＤＲＰ可用性ビットマップはまた、要素ＩＤと、ビットマップの長さを示す１バイトとを含む。
【００７２】
しかしながら、チャネル及びタイムスロット予約を多重チャネルにわたって行う必要があるため、上記ＩＥは前述のＶＭＣＯ技術と組み合わせて使用するのに適さず、追加の空きチャネルに必要な対応ビットマップサイズは、ＩＥの送信に利用可能な時間を超えることがある。そのため、よりコンパクトな表現が必要になる。
【００７３】
そのため、本発明の実施形態によれば、デバイスが空きチャネル用のＤＲＰ予約も含むよう修正ＤＲＰ可用性ＩＥを提供する。
【００７４】
ＤＲＰ可用性ＩＥは、空きチャネル内のカレントアクティビティビューをデバイスに提供しなければならない。従って、可用性ＩＥは、利用可能なチャネル数（別々のビーコン群又はブラックリスティングの存在に基づいて変わり得るため）及びこれらのチャネルの可用性ビットマップの送信命令を送信する機構を必要とする。
【００７５】
この機能性を提供するために、可用性ＩＥは、図１１に示すオクテットを含む。このオクテットは、チャネル制御と呼ばれている。ビット０〜６は、ＴＦＣチャネル１〜７が、ビット７を予約した状態で、それぞれ、ＶＭＣＯビーコン群により使用可能であるかどうかを示す。ＴＦＣチャネルが利用不可（即ち、適性な位置で０）であると示される場合、そのチャネルのビットマップは、可用性ＩＥに含まれないことを示す。完全のため、ランデブーＴＦＣチャネルは１に設定され、これは、データ伝送能力を有することを示す。しかしながら、このチャネルのビットマップは、ＶＭＣＯ非対応デバイスとの後方互換性を維持するため別々のＩＥで送信されるので、追加のＤＲＰ可用性ビットマップは追加されない。
【００７６】
可用性ビットマップを提供するための３つの方法が、確認されている。これらの方法は以下の通りである。
【００７７】
第１の方法は、各連続チャネルに対する可用性ビットマップの細分性の減少に基づいている。この方法で可用性ＩＥの形式を図１２に示す。このように、可用性ＩＥは、要素ＩＤを示す第１オクテット、次いで、利用可能な空きチャネル数により変化する可用性ＩＥの長さを示すオクテット、次いで、チャネル制御を含む。長さは、（６３−Ｍ）＋１で与えられ、ここで、Ｍは、特定のチャネルが利用できない場合に省かれるオクテット数を示す。長さフィールドでは、要素ＩＤと長さフィールド自体の長さは考慮していない。
【００７８】
各仮想チャネルの可用性ビットマップを次に提供する。この方法によれば、各ビットマップの細分性は連続仮想チャネルごとに減少する。従って、第１仮想チャネルのビットマップは３２オクテットで表され、第２仮想チャネルのビットマップは１６オクテットで表され、第３仮想チャネルのビットマップは８オクテットで表され、第４仮想チャネルのビットマップは４オクテットで表され、第５仮想チャネルのビットマップは２オクテットで表され、第６仮想チャネルのビットマップは１オクテットで表される。第１、第２、第３、第４、第５、及び第６仮想チャネルは、任意の望ましいシーケンスで取られる図１１のチャネル制御オクテットで利用可能と示されたＴＦＣチャネルであってもよい。上述のように、ランデブーチャネルのビットマップは、別々のＩＥで提供される。
【００７９】
この方法は、低細分性でチャネルにマッピングする多数の隣接タイムスロットを必要とするトラフィックに有用であることを意味する。
【００８０】
可用性ビットマップを提供する第２の方法は、空き／仮想チャネルに送信する必要がある情報量を低減することである。これは、可用性ビットマップが所与のスーパーフレームのビーコンピリオド内に送信される空きチャネルを交互にすることで行われる。従って、例えば、第１可用性ＩＥでは、第１、第２、及び第３空きチャネルの可用性ビットマップを送信することができ、次のスーパーフレームの第２可用性ＩＥでは、第４、第５、及び第６空きチャネルの可用性ビットマップを送信することができる。図１３は、この方法による可用性ＩＥを示す。空きチャネルは、隣接スーパーフレーム間で任意の適切な方法で分割することができ、チャネルを図示のグループに分割する必要はないことを理解されたい。
【００８１】
従って、可用性ＩＥは、要素ＩＤを示す第１オクテット、次いで、利用可能な空きチャネル数により変化する、可用性ＩＥの長さを示すオクテット、次いで、チャネル制御を含む。長さは、Ｃ＋１で与えられ、ここで、Ｃは、チャネル制御フィールド×３２の高ビット数を示す。次に、３つの選択された仮想チャネル（３２オクテットを含む）の各々の可用性ビットマップを提供する。
【００８２】
この方法は、空きチャネルに対するこの情報をスーパーフレーム１つおきに受信することを犠牲にして、フルチャネルの可用性ビットマップを各仮想チャネルに送信することができるという利点がある。
【００８３】
空き／仮想チャネルＤＲＰ可用性ビットマップを提供する第３の方法は、上述の２つの方法のハイブリッド組み合わせである。この方法は、必要な情報コンテンツを減らすためグラニュラー法及びテンポラル法の両方を用いる。ハイブリッド可用性ＩＥの形式を図１４に示す。
【００８４】
このように、可用性ＩＥは、要素ＩＤを示す第１オクテット、次いで、利用可能な空きチャネル数により変化する可用性ＩＥの長さを示すオクテット、次いで、チャネル制御を含む。可用性ＩＥの長さは、（５６−Ｍ）＋１で与えられ、ここで、Ｍは、特定のチャネルが利用できない場合に省かれるオクテット数を示す。長さフィールドでは、要素ＩＤと長さフィールド自体の長さはＩＥに常に含まれるため、これらは考慮されていない。
【００８５】
３つの空きチャネルの可用性ビットマップを次に提供する。この方法によれば、各ビットマップの細分性は連続仮想チャネルごとに減少する。従って、第２又は第５仮想チャネルのビットマップは３２オクテットで表され、第３又は第６仮想チャネルのビットマップは１６オクテットで表され、第４又は第７仮想チャネルのビットマップは８オクテットで表される。ここでも、空きチャネルは、隣接スーパーフレーム間で任意の適切な方法で分割できることを理解されたい。
【００８６】
以下のセクションでは、空きチャネル上で実際の予約を行う方法について示す。以上のように提供された可用性ビットマップがデバイスで使用され、空きチャネル内のＭＡＳの現在の状態に関する情報を入手する。次に、ＤＲＰ  ＩＥがデバイスで使用され、これらの空きチャネル内にＭＡＳを予約する。
【００８７】
空き／仮想チャネル情報は、デバイスが予約を行いたいチャネルの特定に使用されるＤＲＰ割り当てフィールド形式に追加のオクテットを加えることで、新規ＩＥ内に含まれる。ＤＲＰ  ＩＥの形式を図１５に示す。
【００８８】
ＩＥは、ＤＲＰ割り当てフィールドがデバイスが、予約を行いたいＴＦＣチャネルを特定する追加のオクテットを有する以外は、標準ＤＲＰ  ＩＥと全く同一の形式を有する。そのため、ＩＥは、要素ＩＤを示す第１オクテット、次いで、行われた予約要求の数により変化する、ＩＥの長さを示すオクテット、次いで、ＤＲＰ制御フィールド（予約が成功したか、或いは、他のデバイスと衝突したか、予約の種類に関する所与情報としてＥＣＭＡ−３６８仕様のセクション１６．８に定義される）を表す２つのオクテット、次いで、ターゲット（即ち、データ送信先）及びデバイスアドレスを表す２つのオクテットを含む。次いで、ＩＥは、実行される空き／仮想チャネル予約ごとに５つのオクテットを含む（仮想チャネルＤＲＰ割り当て１〜Ｎ）。
【００８９】
仮想チャネルＤＲＰ割り当てフィールドの形式を図１６に示す。このように、フィールドは、タイムスロットが予約される仮想チャネルを示すオクテットと、ゾーンビットマップを示す２つのオクテットと、ＭＡＳビットマップを示す２つのオクテットとを含む。
【００９０】
本明細書に記載のＶＭＣＯスキームの範囲内において、空きチャネルＤＲＰ割り当てで上述したＩＥにより、ネットワーク状態のデバイスカレントビューの送信機構を提供し、デバイスはＩＥ送信時間を最小限にしてネットワーク内で予約を行うことが可能となる（可用性ＩＥの送信に必要な時間は、空きチャネルの可用性ＩＥにより、標準ＥＣＭＡ−３６８動作と比べて長くなるが、上記の技術は、これを行うのに必要な時間を最小にする）。これにより、高帯域幅及び遅延感受性トラフィックの両方を必要とするデバイスは、これらのトラフィックタイプに固有の空きチャネル内に予約を行うことができる。これにより、よりアクティブなデバイスペアリング及びそれらの特定トラフィック要件をサポートする機能が改善する。
【００９１】
上記の情報要素は、ＶＭＣＯスキームの特定ニーズに合うように開発されたが、チャネル予約情報をサポート又は伝播するのに利用可能なリソースが限定される場合に、単一又は多重チャネルのどちらでも、他のビーコンベースプロトコルに適用できることを理解されたい。
【００９２】
さらに、以上のように、ＶＭＣＯ固有のＩＥへの別のインプリメンテーションは、特定用途向けのＩＥである。
【００９３】
従って、通信ネットワークの利用可能容量の使用改善が可能であり、従来のスキームの欠点を解消する方法及び装置を提供する。
【図１】
2010527551.tif 000003
【図２（ａ）】
2010527551.tif 000004
【図２（ｂ）】
2010527551.tif 000005
【図２（ｃ）】
2010527551.tif 000006
【図２（ｄ）】
2010527551.tif 000007
【図２（ｅ）】
2010527551.tif 000008
【図３】
2010527551.tif 000009
【図４】
2010527551.tif 000010
【図５】
2010527551.tif 000011
【図６】
2010527551.tif 000012
【図７】
2010527551.tif 000013
【図８】
2010527551.tif 000014
【図９（ａ）】
2010527551.tif 000015
【図９（ｂ）】
2010527551.tif 000016
【図１０（ａ）】
2010527551.tif 000017
【図１０（ｂ）】
2010527551.tif 000018
【図１１】
2010527551.tif 000019
【図１２】
2010527551.tif 000020
【図１３】
2010527551.tif 000021
【図１４】
2010527551.tif 000022
【図１５】
2010527551.tif 000023
【図１６】
2010527551.tif 000024
【国際調査報告】
2010527551.tif 000025
2010527551.tif 000026
2010527551.tif 000027