JP5676468B2 - 柔軟な無線ネットワークにおけるチャネル予約 - Google Patents

Description

本願は、２００８年１２月２３日に出願された米国仮出願シリアル番号第６１／１４０、０９７号による優先権利益を請求する。

本発明は一般に、無線通信ネットワークに関し、より詳細には斯かるネットワークにおけるチャネル予約に関する。

無線ネットワークに関する媒体アクセス制御（ＭＡＣ）プロトコルは通常、分散型又は中央化されたＭＡＣプロトコルである。分散ＭＡＣプロトコルが利用されているとき、単一のデバイスが無線媒体にわたり絶対的な制御権を持つことはない。この場合、デバイスは、分散された態様で、例えば、搬送波検知多重アクセス（ＣＳＭＡ）を用いて、チャネルを争う。例えば分散予約プロトコル（ＤＲＰ）といったいくつかの分散ＭＡＣプロトコルは、デバイスペアに基づくチャネル予約を可能にする。即ち、デバイスは、競合ベースのプロトコルを使用することができるか、又はデバイスがチャネル（又は媒体）にアクセスすることができる媒体アクセス時間スロットのためのチャネル予約を要求するため、周期的にビーコンを送信することができる。ビーコンが利用されるとき、効率的なデバイス発見と分散型チャネル予約とを可能にするため、全てのデバイスがビーコンを送信することを要求される。分散ＭＡＣプロトコルは、ピアツーピア・アプリケーションをサポートする際に効率的である。

中央化された動作モードにおいて、単一のコーディネータデバイス（クラスタヘッド、マスター又はアクセスポイントとも呼ばれる）は、デバイス間でのチャネルへのアクセスを制御する。コーディネータデバイスは、チャネル予約を承諾し、ネットワークにおける他のデバイスに関する送信機会をスケジュール化する。コーディネータデバイスは通常、例えばチャネル選択、共存及びインカムベントの保護といった他の作業の制御に関して責任を負う。中央化されたＭＡＣに関する例は、「Amendment to Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Quality of Services Enhancements」P802.11e/D.13.0、Jan. 2005において、ＩＥＥＥ８０２．１１作業グループにより定められるＨＣＣＡモードである。

コーディネータデバイスがトラフィックを分散及び管理する必要があるとき、又は周期的な制御情報がネットワークにおける全てのデバイスにより送信される必要はないとき、中央化されたＭＡＣプロトコルが通常利用される。例えば、ホームネットワークにおけるビデオ配信は通常、例えばセットトップボックス又はアクセスポイントといったサービスプロバイダの装置により制御される。

柔軟なＭＡＣ（フレックスＭＡＣ）プロトコルは、関連技術においても述べられており、中央化された及び分散されたモードをサポートし、１つの動作モードからの別のモードへの円滑な移行を可能にするよう主に設計される。即ち柔軟なＭＡＣは通常、デバイスが、進行中の接続を中断することなしに分散型モードから中央化された動作モードへと（又はその逆に）切り替わることを可能にする。

フレックスＭＡＣは、図１に表される柔軟なスーパーフレーム１００に基づかれる。スーパーフレーム１００は、ビーコン期間（ＢＰ）１１０、データ／検出／スリープ期間（ＤＳＳＰ）１２０及びシグナリングウインドウ（ＳＷ）１３０を含む。ＳＷ１３０及びＢＰ１１０の時間期間は、調節可能であり、制御情報をブロードキャストする／交換するのに使用される。すべてのデバイスは、ネットワークにおけるあらゆるデバイスに適用されることができるすべての制御／管理情報を捕捉するために、ＢＰ１１０及びシグナリングウインドウ１３０の間、起動し続けるべきである。デバイスは、データを交換することができるか、チャネルをモニタすることができるか（コグニティブネットワークにおいて必要とされる）、又は、ＤＳＳＰ１２０の間、スリープモードに入ることができる。

チャネル予約は、無線スペクトルを共有する無線システムにおいて、特に無許可の帯域を利用するネットワークにおいてＱｏＳを保証するため、ＭＡＣ層における基本的な要素である。既存のチャネル予約プロトコルは、中央化された又は分散されたモードのいずれかにおいて作動するネットワークに対して設計される。更に、斯かる予約プロトコルは、静的動作モードに基づかれ、中央化された及び分散されたモードの間でシームレスに交替することができない。こうして、任意のチャネル予約プロトコルは、フレックスＭＡＣアーキテクチャに効率的に適用されることができない。

従って、上述した既存のチャネル予約技術の不利な点を治癒するソリューションを提供することは有利である。

本発明の特定の実施形態は、柔軟な媒体アクセス制御（ＭＡＣ）プロトコルを使用する無線ネットワークにおいて、チャネルアクセス時間スロットを予約する方法を含む。この方法は、チャネル予約の少なくともタイプ及びモードを決定するステップと、予約要求フレームを生成するステップと、上記予約要求フレームを予約プロキシデバイスに送信するステップと、上記予約要求フレームに応じて、上記予約プロキシデバイスから予約レスポンスフレームを受信するステップと、チャネル予約要求が確定される場合、割り当てられた時間スロットの使用をアナウンスするステップとを有する。

本発明の特定の実施形態は更に、柔軟なＭＡＣプロトコルを使用する無線ネットワークにおいてチャネルアクセス時間スロットを予約するよう構成されるネットワークデバイスを含む。このネットワークデバイスは、上記チャネル予約の少なくともタイプ及びモードを決定する決定ユニットと、上記チャネル予約の決定されたタイプ及びモードに基づき、予約要求フレームを生成するフレーム生成器と、上記予約要求フレームを送信する送信機であって、チャネル予約要求が受信される予約レスポンスフレームにおいて確定される場合、上記送信機が更に、割り当てられた時間スロットの使用をアナウンスするメッセージを送信するよう構成される、送信機と、上記予約要求フレームに応じて、上記予約プロキシデバイスから予約レスポンスフレームを受信する受信機とを有する。

本発明の主題は、明細書の結論として請求項において特に指摘され、明示的に請求される。本発明の前述の及び他の特徴及び利点は、添付の図面と共に考慮される以下の詳細な説明から明らかとなるであろう。

フレックスＭＡＣスーパーフレームの構造を示す図である。 本発明の実施形態を説明するための無線ネットワークの図である。 本発明の実施形態によるチャネル予約処理を説明するためのフローチャートである。 本発明によるチャネル予約プロトコル情報要素（ＣＲＰ−ＩＥ）のフォーマットを示す図である。 柔軟なＭＡＣプロトコルを使用する無線ネットワークにおけるチャネルアクセス時間スロットを予約するよう構成されるネットワークデバイスのブロック図である。

本発明により開示される実施形態は、本書における革新的な教示の多くの有利な使用の例にすぎない点を理解されたい。一般に、本願の明細書においてなされる説明は、様々な請求項に記載の本発明のいずれかを制限するものではない。更に、いくつかの記載は、本発明のいくつかの特徴には当てはまるが、他の特徴には当てはまらない場合がある。一般に、特に明記しない限り、一般性を失うことなく、単一の要素は、複数とすることができる。逆もまた真である。図において、類似する数字は、複数の表示を介して同様な部分を参照する。

本発明の特定の実施形態によれば、柔軟なＭＡＣプロトコルを使用する無線ネットワークに関するチャネル予約プロトコル（ＣＲＰ）が、本願において開示される。ＣＲＰは、図１に示されるＤＳＳＰ１２０の間、チャネル（又は媒体）へのアクセス時間をネットワークにおけるデバイスが予約することを可能にする。

図２は、本発明の実施形態を説明するための、無線ネットワーク２００の例示的な図を示す。無線ネットワーク２００は、分散されたモード又は中央化されたモードにおいて作動することができる。無線ネットワーク２００は、デバイス２２０及び少なくとも１つのマスターデバイス２１０を含む。デバイス２２０又はマスターデバイス２１０の各々は、ビーコンデバイス、即ち、図１に示されるＢＰ１１０の間、ビーコンを送信するデバイスとすることができる。ＣＲＰは、予約オーナー（ＲＯ）、予約ターゲット（ＲＴ）及び予約プロキシ（ＲＰ）を含む２つ又はこれ以上のエンティティにより実行される。無線ネットワーク２００における各デバイスは、これらのエンティティのいずれかとして機能することができる。考察のため、デバイス２２０−ＲＯ、デバイス２２０−ＲＴ及びデバイス２２０−ＲＰはそれぞれ、予約オーナー、予約ターゲット及び予約プロキシに関して規定される機能を実行する。

デバイス２２０−ＲＯは通常、クオリティオブサービス（ＱｏＳ）を維持しつつ、新しいセッションを確立するために予約処理を開始するソースデバイスである。デバイス２２０−ＲＯは、デバイス２２０−ＲＴとのセッションを確立しようとする。このセッションは、アプリケーション層セッション又はリンク層セッションである。デバイス２２０−ＲＰは、予約を許可するビーコンデバイスである。ネットワークのタイプに基づき、デバイス２２０−ＲＰは、ターゲットデバイス２２０−ＲＴ、オーナーデバイス２２０−ＲＯ又はネットワークにおける他の任意のビーコンデバイスとすることができる。従って、媒体アクセススロットに関する交渉処理を開始する前に、デバイス２２０−ＲＯは、ネットワークにおけるどのデバイスがターゲットデバイス２２０−ＲＴ及びプロキシデバイス２２０−ＲＰとして機能すべきか、及び使用されることができる予約モードのタイプを決定する。後述するように、予約モードは、黙示的な予約又は明示的な予約とすることができる。

この決定は、所定の規則のセットに基づかれる。特に、デバイス２２０−ＲＯが分散されたモードで作動するビーコンデバイスであり、このデバイスが、デバイス２２０−ＲＴを分散されたモードで作動するビーコンデバイスとして特定する場合、交渉処理（又は予約タイプ）は、ピアツーピア（Ｐ２Ｐ）交渉となる。デバイス２２０−ＲＯが、ビーコンデバイスでもあるマスターデバイス（例えば、図２におけるデバイス２１０）又はスレーブデバイスであり、ターゲットデバイス２２０−ＲＴは、マスターデバイスの制御下にない状態で作動するビーコンデバイスであるときも、このタイプの交渉が適用可能である。即ち、デバイス２２０−ＲＴは、別のサブネット（又はグループする）からのビーコンデバイスである。このタイプの交渉において、デバイス２２０−ＲＯは、対応する予約に関する予約ターゲットとして、デバイス２２０−ＲＴをセットする。交渉モードは、黙示的又は明示的とすることができる。

デバイス２２０−ＲＯが、マスターデバイスの制御下で作動するスレーブデバイスであり、ターゲットデバイス２２０−ＲＴは、オーナーデバイス２２０−ＲＯのマスターデバイス又は同じマスターデバイスの制御下にある別のスレーブデバイスである場合、予約タイプは、スレーブイニシエーテッド交渉であると決定される。この場合、デバイス２２０−ＲＯは、予約に関するマスターデバイスとして、デバイス２２０−ＲＴをセットする。更に、デバイス２２０−ＲＯがビーコンデバイスでない場合、このデバイスは、明示的な予約モードだけを使用することができる。このデバイスがビーコンデバイスである場合、黙示的又は明示的なモードが使用されることができる。スレーブデバイスは通常、ビーコンを送信しない点に留意されたい。いくつかの実施形態において、スレーブデバイスは、マスターデバイスによりビーコンデバイスになるよう昇進されることができる。

別のタイプの予約処理は、マスターイニシエーテッド交渉である。デバイス２２０−ＲＯがマスターデバイスであり、ターゲットデバイス２２０−ＲＴはそのグループ（又はサブネット）におけるデバイスであるとき、このタイプは適用される。このタイプの交渉において、マスターデバイス２１０は、デバイス２２０−ＲＰとして機能する。従って、マスターデバイス２１０は、何らリクエスト（ＲＥＱ）を送信することなしに予約を開始することができる。本発明の実施形態によれば、マスターデバイス又はデバイス２２０−ＲＰは、デバイスのグループに対して予約を許可することができる。

上述される全てのタイプの交渉において、共存を容易にするため、予約レスポンス（Ｒ−ＲＳＰ）がビーコンにおいて搬送される。なぜなら、同じ又は異なるグループ（又はネットワーク）におけるデバイスが、このビーコンを受信し、確実に復号化することができ、これにより、予約に関する情報が得られるからである。Ｒ−ＲＳＰは、少なくとも予約タイプと、予約が、受け入れられるか、拒絶されるか、ペンディング中かどうか又は変更された予約が提案されたかどうかを示す。

図３は、本発明の実施形態によるチャネル予約処理を説明するための、例示的及び非限定的なフローチャート３００を示す。この処理は、フレックスＭＡＣプロトコルを使用するネットワークに適用されることができる。

ステップＳ３１０において、予約のタイプ及びモードが決定される。上記したように、予約モードは黙示的又は明示的とすることができる。一方、予約タイプは、ピアツーピア（Ｐ２Ｐ）交渉、スレーブイニシエーテッド交渉又はマスターイニシエーテッド交渉のいずれかとすることができる。ステップＳ３２０において、予約要求（Ｒ−ＲＥＱ）フレームが生成される。本発明の実施形態によれば、Ｒ−ＲＥＱは、図４にて図示されるように、ＣＲＰ情報要素（ＩＥ）４００として構築される。

図４のＣＲＰ−ＩＥ４００は、以下のフィールドを含む。情報要素のタイプを特定するための要素ＩＤ４１０、（例えば、バイト数の観点で）ＣＲＰ−ＩＥ４００の全長を示すための長さ４２０、ＣＲＰ制御４３０、オーナーデバイスアドレス（ＤｅｖＡｄｄｒ）４４０、予約プロキシ（ＲＰ）デバイスアドレス（ＤｅｖＡｄｄｒ）４５０、ターゲットデバイスアドレス（ＤｅｖＡｄｄｒ）４６０、及び４７０−１から４７０−ＮまでのＣＲＰアロケーションフィールドの数（Ｎ）である。アロケーションフィールドの整数Ｎは、デバイスが調査することができるチャネルアロケーションの数である。チャネルアロケーションは、単一のデバイスに対して予約されることができる同じスーパーフレームに含まれる一組の連続的な時間スロット及び複数の分離したアロケーションである。ＣＲＰ制御フィールド４３０は、少なくとも以下のサブフィールド（図示省略）を含む。予約タイプと、パケットスケジューリングの間に利用されるユーザ優先権を示すストリームインデックスと、予約の状態を示す理由コードであって、状態は即ち、confirmed、pending、又はapprovedである、理由コードと、Ｒ−ＲＥＱ又は予約レスポンス（Ｒ−ＲＳＰ）を示すリクエストであって、Ｒ−ＲＥＱオプションがオーナーデバイス２２０−ＲＯによりセットされる、リクエストと、予約タイプ及びトラフィックストリームの優先権に基づき選択される整数であるタイブレーク番号と、予約限界の何らかの過剰を示すアンセーフビットとである。ＣＲＰアロケーションフィールドは、デバイス２２０−ＲＯに関して割り当てられる媒体アクセススロットの数を含む。

図３に戻ると、ステップＳ３３０において、予約モードが黙示的な予約であるかがチェックされ、もし黙示的である場合、ステップＳ３４０で実行が続く。黙示的でない場合、このモードは明示的な予約であり、ステップＳ３５０へと実行が進む（一方又は両方のモードに関してチェックが実行されることができる）。ステップＳ３４０において、Ｒ−ＲＥＱフレームが、ビーコン期間（例えば、図１に示されるＢＰ１１０）内にプロキシデバイス２２０−ＲＰへ送信される。ステップＳ３４２において、タイマー（以下「予約タイマー」）が、交渉処理が完了される最大予想時間にセットされる。後述するように、予約タイマーは、合理的な時間期間内に予約が確定されない場合からの回復を可能にする。

ステップＳ３５０において、柔軟なスーパーフレームのシグナリングウインドウ（例えば、図１に示されるＳＷ１３０）の間、Ｒ−ＲＥＱフレームを送信することにより、明示的な予約が開始される。Ｒ−ＲＥＱは、ショートインターフレームスペース時間（ＳＩＦＳ）内に承認（ＡＣＫ）フレームで反応すべきプロキシデバイス２２０−ＲＰに送られる。ＡＣＫフレームは、Ｒ−ＲＥＱがデバイス２２０−ＲＰにより受信され、レスポンスが次のビーコン期間（ＢＰ）において続くことをデバイス２２０−ＲＯに示す。シグナリングウインドウは通常、柔軟なスーパーフレームの終わりにあるので、デバイス２２０−ＲＯ及び２２０−ＲＰの間の交渉は、一般に非常に短い時間間隔内に完了され、オーバーヘッドが小さい点に留意されたい。デバイス２２０−ＲＯがＲ−ＲＥＱに関するＡＣＫフレームを受信しない場合、送信は失敗し、Ｒ−ＲＥＱフレームが、ランダムなバックオフ手順の後再送信されることになる点に更に留意されたい。バックオフの手順は、シグナリングウインドウの間、使用されるアクセス機構により規定されることができる。ステップＳ３５２において、ＡＣＫフレームを受信すると、デバイス２２０−ＲＯは、上述したように予約タイマーをセットする。

ステップＳ３６０において、Ｒ−ＲＳＰフレームがデバイス２２０−ＲＰから受信されたかどうかを決定するためチェックが実行される。Ｒ−ＲＳＰは、ビーコン期間の間にビーコンにおいて送信され、ＣＲＰ−ＩＥ４００としてフォーマットされることができる。Ｒ−ＲＳＰがＣＲＰ−ＩＥ４００として構築されるとき、制御フィールド４３０におけるリクエストサブフィールドは、「０」にセットされる。これは、ＣＲＰ−ＩＥ４００がレスポンスであることを示す。更に、予約状態サブフィールドは、予約の状態、即ち、pending、confirmed、又はmodifiedを示すようセットされる。ＣＲＰアロケーションフィールド４７０は、デバイス２２０−ＲＯに関して割り当てられる媒体アクセススロットを含む。デバイス２２０−ＲＰが予約を確定するべきかどうかをまだ決めていなかった場合であっても、デバイス２２０−ＲＰは、次のビーコン期間においてＲ−ＲＳＰフレームを含む。確定されない予約は、pendingとして示される。

ステップＳ３６０が否定的な答えを生じさせる場合、即ち、デバイス２２０−ＲＯが、デバイス２２０−ＲＰからＲ−ＲＳＰフレームを受信しなかった場合、実行は、ステップＳ３７０に続き、そこでは、デバイス２２０−ＲＯが、次のシグナリングウインドウ又はビーコン期間においてＲ−ＲＥＱを再送信する。再送信は、所定数の試みに関して実行されることができる。その後で、交渉処理は、failedと決定され、実行は終わる。

Ｒ−ＲＳＰフレームがビーコン期間の間に受信された場合、処理はステップＳ３８０に到達し、予約要求が確定されたかどうかがチェックされる。即ち、デバイス２２０−ＲＰが、デバイス２２０−ＲＯに対して１つ又は複数の媒体アクセス時間スロットを許可するかどうかがチェックされる。確定された場合、ステップＳ３８２において、少なくともデバイス２２０−ＲＯは、次の柔軟なスーパーフレームの間、割り当てられた時間スロットをアナウンス及び使用する。予約が確定されて、アナウンスされる態様は、交渉処理のタイプに依存する。各タイプに関連付けられる手順の詳細は、以下に与えられる。Ｒ−ＲＥＱがまだpendingである場合、ステップＳ３８４において、予約タイマーが期限切れになったかどうかがチェックされ、期限切れの場合、処理はステップＳ３９０に続く。そこでは、リクエストが取り下げられる又は再送信される。期限切れではない場合、処理は、ステップＳ３６０に戻り、そこでは、デバイス２２０−ＲＯが、確定された予約指示で別のＲ−ＲＳＰを待つ。Ｒ−ＲＥＱが取り下げられるとき、デバイス２２０−ＲＯは、新しいＲ−ＲＥＱを開始する前にランダムなバックオフ手順を実行する点に留意されたい。本発明の実施形態によれば、バックオフ手順は、間隔［０、ＢａｃｋｏｆｆＷｉｎｄｏｗ−１］に含まれるスーパーフレームのランダムな整数Ｍを選択することを含む。ＢａｃｋｏｆｆＷｉｎｄｏｗは、ランダムなバックアップ手順により使用される可変パラメータである。デバイス２２０−ＲＯは、Ｎ個のスーパーフレームの間任意の予約要求を送信すべきではない。

上記したように、交渉処理を終結するために、予約はデバイス２２０−ＲＰにより、又は、デバイス２２０−ＲＯ及びデバイス２２０−ＲＰの両方により確定されなるべきである。これは、交渉処理のタイプに基づきいくつかのケースにおいてターゲットであってもよい。特に、Ｐ２Ｐ交渉において、デバイス２２０−ＲＯ及びデバイス２２０−ＲＰ（又はデバイス２２０−ＲＴ）は、交渉処理の終結に関し同意し、予約された時間スロットにおける送信の前に、アクティブな予約をアナウンスするべきである。従って、Ｒ−ＲＥＱに応答してＲ−ＲＳＰフレームを送信するとき、デバイス２２０−ＲＰは、予約がアクティブであることを示す。これは、例えば、制御フィールド４３０に予約状態サブフィールドをセットすることにより実行されることができる。デバイス２２０−ＲＯが、予約状態サブフィールド・ビットが「１」にセットされたＲ−ＲＳＰを受信するとき、このデバイスは、新しいＣＲＰ−ＩＥを含むその次のビーコンにおいて予約をアナウンスすることになる。デバイス２２０−ＲＯは、予約が受け入れられ、他の予約との衝突がデバイス２２０−ＲＯにより検出されなかったことを示すため、新しいＣＲＰ−ＩＥにおける状態サブフィールドもセットする。

スレーブイニシエーテッド及びマスターイニシエーテッド交渉タイプにおいて、デバイス２２０−ＲＰ又はマスターデバイスだけが、そのビーコンにおいて、この処理の結論及び予約がアクティブであるときを広告することに関して責任を負う。新しい予約が許可されたとき、デバイス２２０−ＲＰ（又はマスターデバイス）は、予約が受け入れられたという指示を備えるＲ−ＲＳＰを送信する。更に、制御フィールド４３０における予約状態サブフィールドが、１にセットされる。予約が許可されるとき、デバイス２２０−ＲＯ及びデバイス２２０−ＲＴは次のスーパーフレームにおいてこの予約を使用して開始することができる。

要求された予約がデバイス２２０−ＲＰにより変更される場合、デバイス２２０−ＲＯは新しい予約を受け入れること又は新しい予約処理を始めることを決定することができる。

Ｐ２Ｐ予約が確定されるとき、予約がアクティブである限り、デバイス２２０−ＲＯ及び２２０−ＲＴは、それらのビーコンにおいて予約をアナウンスする。予約がスレーブイニシエーテッド又はマスターイニシエーテッドであるとき、予約が確定される場合、デバイス２２０−ＲＰは、このデバイスが許可したすべてのアクティブ予約をそのビーコンにおいてアナウンスする。

本発明の特定の実施形態によれば、デバイス２２０−ＲＯ、２２０−ＲＴ及び２２０−ＲＰのエンティティは、例えば複数のデバイスが同じ時間スロットを予約するとき起こりうる予約競合を解決及び検出することができる。競合は、予約がアクティブになる前又は後に発生する可能性があり、予約がビーコンにおいてアナウンスされるとき、検出されることができる。予約競合が検出されて、解決される態様は、交渉処理のタイプに依存する。特に、Ｐ２Ｐ交渉処理に関して、デバイス２２０−ＲＯは、同じ時間スロットを予約することができた他のデバイスとの任意の競合を解決する。他方、スレーブイニシエーテッド及びマスターイニシエーテッド交渉処理においては、すべてのデバイスが、競合を検出することについて協力することができるものの、デバイス２２０−ＲＰが、任意の競合を解決することに関して責任を負う。

以下に、予約競合を解決するのに利用される非制限的な規則のセットが与えられる。１）デバイス２２０−ＲＴが可能な競合を検出するとき、デバイス２２０−ＲＴがビーコンデバイスである場合、このデバイスは、その予約アナウンスにおいて競合を示す。この場合、デバイス２２０−ＲＴは、予約を使用することができない。２）デバイス予約がビーコン送信に関して予約される時間スロットと競合するとき、このデバイスはこの予約を使用するべきではない。しかし代わりに、このデバイスは予約を変更又は取り下げる（ビーコンスロットは、他の任意の予約を超えるより高い優先権を持つ）。３）アクティブでない予約との競合を検出するとき、アクティブ予約を持つデバイスは、それらの予約を維持することができる。４）まだアクティブでない予約を持つデバイスは、これらのデバイスがアクティブ予約との競合を検出する場合、この予約を取り下げる又は変更すべきである（即ち、アクティブ予約は、より高い優先権を持つ）。５）同じ状態にある予約を持つ２つのデバイスが競合を検出するとき、これらのデバイスは、斯かる状況を解決するため予約タイブレーク数（Ｎｔｂ）を使用すべきである。Ｎｔｂは、予約要求をするデバイスにより選択される乱数であり、予約が有効である限り、交渉処理の間、同じままである。すると、予約がより小さなＮｔｂを持つデバイスは、予約を取り下げる又は変更すべきである。Ｎｔｂ番号は、一様な分布を用いて間隔［０、ＴＢｒｅａｋＷｉｎｄｏｗ（ｉ）］内で選択されることができる。ここで、ＴｂｒｅａｋＷｉｎｄｏｗ（ｉ）は、予約のタイプ又はトラフィックストリームの優先度に依存する可変パラメータである。例えば、より厳しいＱｏＳ要件を持つトラフィックストリームは、ＴＢｒｅａｋＷｉｎｄｏｗに関してより高い値を使用することができる。

図５は、柔軟なＭＡＣプロトコルを使用する無線ネットワークにおいてチャネルアクセス時間スロットを予約するよう構成されるネットワークデバイス５００の非限定的なブロック図を示す。ネットワークデバイス５００は、決定ユニット５１０、フレーム生成器５２０、送信機５３０及び受信機５４０を含む。決定ユニット５１０は、少なくともチャネル予約のタイプ及びモードを決定する。更に、決定ユニット５２０は、チャネル予約要求がプロキシかターゲットデバイスにより確定されたかどうかを決定する。フレーム生成器５２０は、チャネル予約の決定されたタイプ及びモードに基づき予約要求フレームを生成する。送信機５３０は、確定されたチャネル予約要求に関して割り当てられた時間スロットの使用をアナウンスするため、予約要求フレーム及びメッセージを送信する。受信機５４０は、予約プロキシデバイスから予約レスポンスフレームを受信する。本発明のある実施形態によれば、ネットワークデバイス５００は、予約オーナーデバイス２２０−ＲＯとして機能する。

本書に開示されるＣＲＰ、交渉処理及び／又はＣＲＰ−ＩＥフォーマットの教示は、無線ネットワークにおいて実現されることができる。この無線ネットワークは、これらに限定されるものではないが、コグニティブ無線ネットワーク、超広帯域（ＵＷＢ）ベースのネットワーク、ＩＥＥＥ８０２．１１ベースのネットワーク及びＩＥＥＥ８０２．１５ベースのネットワークを含む。

前述の詳細な記載は、本発明が取ることができる多くの形式のうちの２、３について説明したものである。前述の詳細な記載は、本発明が取ることができるフォームのうち選択されたものを説明するものであり、本発明の規定に限定されるものとして理解されるものではない点に留意されたい。本発明の範囲を定めるのは、請求項のみであり、この請求項は、すべての均等の範囲を含む。

最も好ましくは、本発明の原理は、ハードウェア、ファームウェア及びソフトウェアの任意の組み合わせとして実現される。更に、ソフトウェアは好ましくは、プログラムストレージユニット又はコンピュータ可読媒体上に明白に表されるアプリケーションプログラムとして実現される。当業者であれば、「機械読取り可能な媒体」は、データを格納することができる媒体であり、デジタル回路、アナログ回路又はこれらの組み合わせの形式とすることができる点を理解されたい。アプリケーションプログラムは、任意の適切なアーキテクチャを有するマシンに対してアップロードされることができ、このマシンにより実行されることができる。好ましくは、このマシンは、例えば１つ又は複数の中央処理ユニット（「ＣＰＵ」）、メモリ及び入力／出力インタフェースといったハードウェアを持つコンピュータプラットフォーム上で実現される。コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含むこともできる。斯かるコンピュータ又はプロセッサが明示されていなくても、本書に説明される様々な処理及び機能は、ＣＰＵにより実行されることができるマイクロ命令コードの部分又はアプリケーションプログラムの部分又はこれらの任意の組み合わせとすることができる。更に、例えば追加的なデータストレージユニット及び印刷ユニットといった他の様々な周辺機器が、このコンピュータプラットフォームに接続されることができる。

Claims (15)

1. 中央化された動作モードと分散された動作モードとを切り替え可能である柔軟な媒体アクセス制御プロトコルを使用する無線ネットワークにおいてチャネルアクセス時間スロットを予約する方法において、
   前記柔軟な媒体アクセス制御プロトコルの動作モードが、前記中央化された動作モードであるか前記分散された動作モードであるかに基づいて、前記チャネル予約の少なくとも予約タイプ及び予約モードを決定するステップと、
   前記チャネル予約の決定された予約タイプ及び予約モードに基づき、予約要求フレームを生成するステップと、
   前記予約要求フレームを予約プロキシデバイスに送信するステップと、
   前記予約要求フレームに応じて、前記予約プロキシデバイスから予約レスポンスフレームを受信するステップと、
   チャネル予約要求が、前記予約レスポンスフレームにおいて確定される場合、割り当てられた時間スロットの使用をアナウンスするステップとを有する、方法。
2. 前記チャネル予約の予約モードが、明示的な予約又は黙示的な予約である、請求項１に記載の方法。
3. 前記予約タイプが黙示的であるとき、前記予約要求フレームがビーコン期間の間に送られる、請求項２に記載の方法。
4. 前記予約タイプが明示的であるとき、前記予約要求フレームがシグナリングウインドウの間に送られる、請求項２に記載の方法。
5. 前記予約タイプが、ピアツーピア交渉、スレーブイニシエーテッド交渉、及びマスターイニシエーテッド交渉から選択される１つである、請求項３に記載の方法。
6. 前記予約レスポンスフレームが、前記予約要求フレームの送信に後続するビーコン期間において送信される、請求項４に記載の方法。
7. 前記予約レスポンスフレームが前記後続するビーコン期間の間に受信されない場合、前記予約要求フレームが、所定の回数再送信される、請求項６に記載の方法。
8. 前記予約レスポンスフレームが確定されず、所定の時間間隔が経過する場合、前記予約要求フレームが、取り下げられる、請求項１に記載の方法。
9. 前記予約レスポンスフレームが、前記予約プロキシデバイス、予約ターゲットデバイス及びマスターデバイスのうちの少なくとも１つにより確定される、請求項１に記載の方法。
10. 前記予約タイプがピアツーピア交渉であるとき、予約競合がオーナーデバイスにより解決される、請求項５に記載の方法。
11. 前記予約タイプがマスターイニシエーテッド交渉又はスレーブイニシエーテッド交渉であるとき、予約競合が前記予約プロキシデバイスにより解決される、請求項５に記載の方法。
12. 前記予約要求フレームが、チャネル予約プロトコル情報要素として構築され、前記チャネル予約プロトコル情報要素は、チャネル予約プロトコル制御、オーナーデバイスアドレス、予約プロキシデバイスアドレス、ターゲットデバイスアドレス、及び複数のアロケーションフィールドというフィールドを少なくとも含む、請求項１に記載の方法。
13. 前記チャネル予約プロトコル制御フィールドが、予約タイプ、ストリームインデックス、理由コード、リクエスト、タイブレーク番号及びアンセーフビットというサブフィールドを含む、請求項１２に記載の方法。
14. 前記リクエストサブフィールドが、前記チャネル予約プロトコル情報要素が予約レスポンスフレームであることを示す、請求項１３に記載の方法。
15. 中央化された動作モードと分散された動作モードとを切り替え可能である柔軟な媒体アクセス制御プロトコルを使用する無線ネットワークにおいてチャネルアクセス時間スロットを予約するよう構成されるネットワークデバイスであって、
    前記柔軟な媒体アクセス制御プロトコルの動作モードが、前記中央化された動作モードであるか前記分散された動作モードであるかに基づいて、前記チャネル予約の少なくとも予約タイプ及び予約モードを決定する決定ユニットと、
    前記チャネル予約の決定された予約タイプ及び予約モードに基づき、予約要求フレームを生成するフレーム生成器と、
    前記予約要求フレームを送信する送信機であって、受信される予約レスポンスフレームにおいてチャネル予約要求が確定される場合、前記送信機が更に、割り当てられた時間スロットの使用をアナウンスするメッセージを送信するよう構成される、送信機と、
    前記予約要求フレームに応じて、前記予約プロキシデバイスから予約レスポンスフレームを受信する受信機とを有する、ネットワークデバイス。

Images