(57)【特許請求の範囲】
【請求項１】
チャネルアグリゲーションを実行するノードの方法であって、前記方法は、
複数の集約されたチャネルのプライマリーチャネル上で第１のフレームを受信することと、
前記複数の集約されたチャネルの非プライマリーチャネル上で第２のフレームを受信することであって、前記第１のフレームは、前記第２のフレーム以内に終了する、ことと、
前記第１のフレームに応答して前記プライマリーチャネル上で第１のアクナリッジメント（ＡＣＫ）フレームを、および前記第２のフレームに応答して前記非プライマリーチャネル上で第２のＡＣＫフレームを実質的に同時に送信することと
を備える方法。
【請求項２】
第３のフレームを受信することと、
前記第３のフレームに応答して第３のＡＣＫフレームを送信することであって、前記第３のフレームが前記プライマリーチャネル上で受信されたという条件で、前記第３のＡＣＫフレームは、短フレーム間隔（ＳＩＦＳ）期間の後、前記プライマリーチャネル上で送信され、前記第３のフレームが前記非プライマリーチャネル上で受信されたという条件で、前記第３のＡＣＫフレームは、前記プライマリーチャネル上の送信が終わった後、ＳＩＦＳ期間の後、前記非プライマリーチャネル上で送信される、ことと
をさらに備える、請求項１の方法。
【請求項３】
前記第１のＡＣＫフレームは、前記第１のフレームが受信された後、短フレーム間隔（ＳＩＦＳ）期間の後、送信される、請求項１の方法。
【請求項４】
前記第２のＡＣＫフレームは、前記プライマリーチャネルが短フレーム間隔（ＳＩＦＳ）期間の間アイドルだった後、送信される、請求項１の方法。
【請求項５】
前記集約されたチャネルのそれぞれのチャネルステータスを判定するために前記集約されたチャネル上でキャリア感知多重アクセス（ＣＳＭＡ）を実行することと、
前記チャネルステータスに基づいてフレームヘッダにデュレーションフィールドを設定することと
をさらに備える、請求項１の方法。
【請求項６】
前記集約されたチャネル上でＣＳＭＡを実行することは、論理ＡＮＤ演算を前記集約されたチャネル上で実行することを備える、請求項５の方法。
【請求項７】
最長の送信の終了時間、短フレーム間隔（ＳＩＦＳ）期間、およびＡＣＫフレームに関連付けられた送信時間に基づいてフレームヘッダにデュレーションフィールドを設定することをさらに備える、請求項１の方法。
【請求項８】
前記プライマリーチャネルにおける失敗したパケット送信を検出することと、
現在の送信機会を終了することと、
バックオフプロシージャを開始することと
をさらに備える、請求項１の方法。
【請求項９】
前記プライマリーチャネルにおける失敗したパケット送信を検出し、かつ前記失敗したパケットを前記非プライマリーチャネルに関連付けられたバッファに移動することと、
前記非プライマリーチャネルにおける失敗したパケット送信を検出し、かつ前記失敗したパケットを前記プライマリーチャネルに関連付けられたバッファに移動することと
の少なくとも一つを実行することをさらに備える、請求項１の方法。
【請求項１０】
ＡＩＦＳ（arbitration interframe space）時間待機し、かつ前記プライマリーチャネル上でバックオフを実行した後、ＲＴＳ（request to send）メッセージを受信することと、
短フレーム間隔（ＳＩＦＳ）期間待機した後、ＣＴＳ（clear to send）メッセージを送信することと、
前記プライマリーチャネルおよび前記少なくとも一つの非プライマリーチャネルのそれぞれの上でプロトコルデータユニット（ＰＤＵ）を送信することと、
肯定的なアクナリッジメント（ＡＣＫ）メッセージを前記プライマリーチャネルおよび前記非プライマリーチャネルのそれぞれの上で受信することと
をさらに備える、請求項１の方法。
【請求項１１】
前記プライマリーチャネルおよび前記非プライマリーチャネルのどちらが新しいチャネルに切り替えられているのかを示す切り替えチャネルフィールド、前記新しいチャネルの周波数を示す新たなチャネル番号フィールド、および前記新しいチャネルのプロパティを示すチャネル特徴フィールドを含むＣＳＡ（channel switch announcement）メッセージを送信することをさらに備える、請求項１の方法。
【請求項１２】
前記プライマリーチャネル上の、および前記非プライマリーチャネル上の送信のそれぞれのデュレーションを実質的に等しくなるように構成することをさらに備える、請求項１の方法。
【請求項１３】
送信のフレームサイズを前記送信のチャネルのサービス品質（ＱｏＳ）に基づいて構成することをさらに備える、請求項１２の方法。
【請求項１４】
チャネルアグリゲーションを実行するネットワークノードであって、前記ノードは、
複数の集約されたチャネルのプライマリーチャネル上で第１のフレームを受信し、
前記複数の集約されたチャネルの非プライマリーチャネル上で第２のフレームを受信し、前記第１のフレームは、前記第２のフレーム以内に終了し、
前記第１のフレームに応答して前記プライマリーチャネル上で第１のアクナリッジメント（ＡＣＫ）フレームを、および前記第２のフレームに応答して前記非プライマリーチャネル上で第２のＡＣＫフレームを実質的に同時に送信する
プロセッサを備えたネットワークノード。
【請求項１５】
前記プロセッサは、
第３のフレームを受信し、
前記第３のフレームに応答して第３のＡＣＫフレームを送信し、前記第３のフレームが前記プライマリーチャネル上で受信されたという条件で、前記第３のＡＣＫフレームは、短フレーム間隔（ＳＩＦＳ）期間の後、前記プライマリーチャネル上で送信され、前記第３のフレームが前記非プライマリーチャネル上で受信されたという条件で、前記第３のＡＣＫフレームは、前記プライマリーチャネル上の送信が終わった後、ＳＩＦＳ期間の後、前記非プライマリーチャネル上で送信される、請求項１４のネットワークノード。
【請求項１６】
前記第１のＡＣＫフレームは、前記第１のフレームが受信された後、短フレーム間隔（ＳＩＦＳ）期間の後、送信される、請求項１４のネットワークノード。
【請求項１７】
前記第２のＡＣＫフレームは、前記プライマリーチャネルが短フレーム間隔（ＳＩＦＳ）期間の間アイドルだった後、送信される、請求項１４のネットワークノード。
【請求項１８】
前記プロセッサは、
前記集約されたチャネルのそれぞれのチャネルステータスを判定するために前記集約されたチャネル上でキャリア感知多重アクセス（ＣＳＭＡ）を実行し、
前記チャネルステータスに基づいてフレームヘッダにデュレーションフィールドを設定する、
請求項１４のネットワークノード。
【請求項１９】
前記集約されたチャネル上でＣＳＭＡを実行することは、論理ＡＮＤ演算を前記集約されたチャネル上で実行することを備える、請求項１８のネットワークノード。
【請求項２０】
前記プロセッサは、最長の送信の終了時間、短フレーム間隔（ＳＩＦＳ）期間、およびＡＣＫフレームに関連付けられた送信時間に基づいてフレームヘッダにデュレーションフィールドを設定する、請求項１４のネットワークノード。
【請求項２１】
前記プロセッサは、前記集約されたチャネルのそれぞれの上でプロトコルデータユニット（ＰＤＵ）を少なくとも一つの無線送受信ユニット（ＷＴＲＵ）に送信し、前記ＰＤＵは、データＰＤＵまたはマネージメントＰＤＵであり、
前記ＰＤＵを送信したことに応答してＡＣＫフレームを受信する、
請求項１４のネットワークノード。
【請求項２２】
前記プロセッサは、
前記プライマリーチャネルにおける失敗したパケット送信を検出し、
現在の送信機会を終了し、
バックオフプロシージャを開始する、
請求項１４のネットワークノード。
【請求項２３】
前記プロセッサは、
前記プライマリーチャネルにおける失敗したパケット送信を検出し、かつ前記失敗したパケットを前記非プライマリーチャネルに関連付けられたバッファに移動することと、
前記非プライマリーチャネルにおける失敗したパケット送信を検出し、かつ前記失敗したパケットを前記プライマリーチャネルに関連付けられたバッファに移動することと
の少なくとも一つを実行する、請求項１４のネットワークノード。
【請求項２４】
前記プロセッサは、
ＡＩＦＳ（arbitration interframe space）時間待機し、かつ前記プライマリーチャネル上でバックオフを実行した後、ＲＴＳ（request to send）メッセージを受信し、
短フレーム間隔（ＳＩＦＳ）期間待機した後、ＣＴＳ（clear to send）メッセージを送信し、
前記プライマリーチャネルおよび前記少なくとも一つの非プライマリーチャネルのそれぞれの上でプロトコルデータユニット（ＰＤＵ）を送信し、
肯定的なアクナリッジメント（ＡＣＫ）メッセージを前記プライマリーチャネルおよび前記非プライマリーチャネルのそれぞれの上で受信する、
請求項１４のネットワークノード。
【請求項２５】
前記プロセッサは、
前記プライマリーチャネルおよび前記非プライマリーチャネルのどちらが新しいチャネルに切り替えられているのかを示す切り替えチャネルフィールド、前記新しいチャネルの周波数を示す新たなチャネル番号フィールド、および前記新しいチャネルのプロパティを示すチャネル特徴フィールドを含むＣＳＡ（channel switch announcement）メッセージを送信する、請求項１４のネットワークノード。
【請求項２６】
前記プロセッサは、前記プライマリーチャネル上の、および前記非プライマリーチャネル上の送信のそれぞれのデュレーションを実質的に等しくなるように構成する、請求項１４のネットワークノード。
【請求項２７】
前記プロセッサは、送信のフレームサイズを前記送信のチャネルのサービス品質（ＱｏＳ）に基づいてさらに構成する、請求項２６のネットワークノード。
【請求項２８】
前記プロセッサを備えるアクセスポイント（ＡＰ）または前記プロセッサを備えるｅＮＢ（evolved Node-B）の少なくとも一つを備える、請求項１４のネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、チャネルアグリゲーションおよび媒体アクセス制御再送信に関する。
【背景技術】
【０００２】
ＬＡＮ（local wireless network）は、ますます帯域幅を要求するワイヤレスアプリケーションが家庭においてまたはオフィスにおいて展開されるにつれて、制約を受ける帯域幅において動作する場合がある。これを解決するために、ＴＶＷＳ（television white space）などの新興のスペクトルにおけるＷＴＲＵ（wireless transmit/receive unit）のオペレーションが必要となる場合がある。しかし、そのようなスペクトルにおいて動作するＷＴＲＵによって使用されうる許容可能なチャネルは、スペクトルの不連続なチャンクである場合が多い。現在のワイヤレス技術は、不連続なスペクトル割り当てにわたって、集約された方法では動作しない。
【０００３】
システムまたはユーザによって使用可能な帯域幅を最大にするために、スペクトルの不連続なチャンクを同時に使用することが、必要とされるＱｏＳ（quality of service）を達成する上で決定的に重要になる場合がある。複数の不連続なチャネルにわたって動作すること、および秩序立った堅牢な方式でチャネルにアクセスすることは、複雑なプロセスとなる場合がある。ＷＴＲＵは、ＷＴＲＵのうちの全てが、メディアにアクセスする際に公平な機会を得て、それによってコリジョンの可能性が最小になるように、機能しなければならない場合がある。
【０００４】
動的なスペクトル割り当てを容易にして、ＬＡＮの堅牢性を確かなものにするために、様々なマネージメント／制御メッセージは、ＬＡＮ内のアクセスポイント（ＡＰ）によって送信される必要がある。これらのメッセージは、全てのＷＴＲＵ間におけるコーディネーションを保持し、およびそれらのＷＴＲＵが効率よく動作するのを補助することが可能である。加えて、複数のチャネルにわたるＭＡＣ（medium access control）層キャリアアグリゲーションを実行することにより、より多くのデータの送信が可能となり、それによってシステムスループットが高まる。
【発明の概要】
【０００５】
プライマリーチャネルおよび少なくとも１つの非プライマリーチャネル（例えば、セカンダリーチャネル、ターシャリーチャネル（tertiary channel）、またはクォータナリーチャネル（quaternary channel））を含む複数の集約されたチャネルを使用してＴＶＷＳなどの不連続なスペクトル上で通信するためのチャネルアグリゲーションを実行する方法および装置について記載する。ＣＳＭＡ（carrier sense multiple access）がプライマリーチャネル上で実行され、プライマリーチャネルへのアクセスを得ることができる。ＡＩＦＳ（arbitration interframe space）にわたって待機し、場合によってはプライマリーチャネル上でバックオフを実行した後に、集約されたチャネルが送信のために使用されることができる。バッファコントローラは、複数のＡＣ（access class）のそれぞれごとに、チャネルのうちの各々のためのロジックバッファを生成するために使用されうる。フレームコントローラは、Ａ−ＭＰＤＵ（aggregated MAC(medium access control) protocol data unit）フレーム情報をバッファコントローラに提供し、アグリゲーションプロセスおよびフラグメンテーションプロセスを制御するために使用されうる。
【図面の簡単な説明】
【０００６】
添付図面と共に例として与えられる以降の説明から詳細な理解を得ることができる。
【図１Ａ】１つまたは複数の開示される実施形態を実施することができる例示的な通信システムのシステム図である。
【図１Ｂ】図１Ａにおいて示される通信システム内で使用されうる例示的なＷＴＲＵのシステム図である。
【図１Ｃ】図１Ａにおいて示される通信システム内で使用されうる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図２】ＩＥＥＥ８０２．１１ｎシステムにおけるプライマリーチャネルの一例を示す図である。
【図３】ＩＥＥＥ８０２．１１ａｃシステムにおけるプライマリーチャネルの一例を示す図である。
【図４】ＤＳＭシステム動作チャネルにおける制御およびデータによる複数の集約されたチャネルのタイムシェアリングの一例を示す図である。
【図５】プライマリーチャネル上でのＭＡＣ層のＣＳＭＡの一例を示す図である。
【図６】延期５／１０／１５／２０メカニズムの一例を示す図である。
【図７】プライマリーチャネル上でのＲＴＳ／ＣＴＳメッセージングの一例を示す図である。
【図８】マルチユーザシナリオにおけるＲＴＳ／ＣＴＳメッセージングの一例を示す図である。
【図９】修正されたＲＴＳメッセージングフレームフォーマットの一例を示す図である。
【図１０】専用の制御チャネルとしてのプライマリーチャネルの一例を示す図である。
【図１１】ＮＡＶ、およびＡＰへの送信の一例を示す図である。
【図１２】ＲＴＳのフレームフォーマットの一例を示す図である。
【図１３】ＣＴＳメッセージングのフレームフォーマットの一例を示す図である。
【図１４】ＡＮＤロジックが結合されたＣＳＭＡの一例を示す図である。
【図１５】ＣＳＡメッセージの一例を示す図である。
【図１６】集約された制御チャネルの実施態様において使用される修正されたＣＳＡメッセージの一例を示す図である。
【図１７】ＩＥＥＥ８０２．１１における測定レポートメッセージの一例を示す図である。
【図１８】ＩＥＥＥ８０２．１１における測定タイプフィールドの一例を示す図である。
【図１９】測定タイプ４の一例を示す図である。
【図２０】ＤＳＭシステムのＣＭＦが、失敗したチャネルに取って代わるための他の利用可能なチャネルを既に有していた第１のシナリオの流れ図である。
【図２１】ＤＳＭシステムのＣＭＦが、失敗したチャネルに取って代わるための利用可能なチャネルを有していない第２のシナリオの流れ図である。
【図２２】プライマリーチャネルの失敗の一例を示す図である。
【図２３】非プライマリーチャネルの失敗の一例を示す図である。
【図２４】制御メッセージおよびそれらの優先度の一例を提供するテーブルである。
【図２５】基本的な要求に関するＩＥＥＥ８０２．１１測定要求フィールドフォーマットの一例を示す図である。
【図２６】図２５のＩＥＥＥ８０２．１１測定要求フィールド内の修正されたチャネル番号フィールドの一例を示す図である。
【図２７】イベントトリガーを伴うノード（例えば、ＡＰまたはｅＮＢ）による高優先度制御メッセージの送信の一例を示す図である。
【図２８】ＭＡＣ層集約ユニットの一例を示す図である。
【図２９】肯定ＡＣＫの同期化を伴わずにＭＡＣ集約において送信と受信とを同時に行うことを示す図である。
【図３０】ＡＣＫ手順の一例を示す図である。
【図３１】フラグメント化されていないまたは単一のフラグメントパケット送信およびＴＸＯＰの最後の送信におけるデュレーションフィールドの例を示す図である。
【図３２】フラグメント化されたパケット送信、またはＴＸＯＰの最後以外の送信におけるデュレーションフィールドの例を示す図である。
【図３３】継続中のＴＸＯＰを継続中でないＴＸＯＰから区別するデュレーションフィールドの例を示す図である。
【図３４】ＤＳＭシステムの例示的なアーキテクチャを示す図である。
【図３５】ＤＳＭエンジンの例示的なアーキテクチャを示す図である。
【図３６】プライマリーＣＳＭＡの例示的な図である。
【図３７Ａ】拡張ＭＡＣアーキテクチャの一例を示す図である。
【図３７Ｂ】拡張ＭＡＣアーキテクチャの一例を示す図である。
【図３８】空のバッファに起因するパケット並べ替えの例を示す図である。
【図３９】空のバッファに起因するパケット並べ替えの例を示す図である。
【図４０】利用不能なチャネルに起因するパケット並べ替えの例を示す図である。
【図４１】利用不能なチャネルに起因するパケット並べ替えの例を示す図である。
【図４２】ＱｏＳ要件に起因するパケット並べ替えの例を示す図である。
【図４３】ＱｏＳ要件に起因するパケット並べ替えの例を示す図である。
【図４４】ＢＣ（buffer controller）の例示的なコールフローを示す図である。
【図４５】受信側における拡張ＭＡＣ層アーキテクチャの一例を示す図である。
【図４６】ｎｏｎ−ＨＴ  ＰＰＤＵデータフォーマットを示す図である。
【図４７】ＭＡＣヘッダの一般的なフォーマットを示す図である。
【図４８】ＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマットを示す図である。
【図４９】ＨＴ−ｍｉｘｅｄ  ＰＰＤＵまたはＨＴ−Ｇｒｅｅｎｆｉｅｌｄ  ＰＰＤＵのＭＡＣヘッダの一般的なフォーマットを示す図である。
【図５０】ＨＴ−Ｇｒｅｅｎｆｉｅｌｄ  ＰＰＤＵデータフォーマットを示す図である。
【図５１】フレームコントローラのための例示的なコールフロー手順を示す図である。
【図５２】ｎｏｎ−ＨＴ  ＰＰＤＵに関するＭＣＳパラメータを示す図である。
【図５３】ＨＴ  ＰＰＤＵに関するＭＣＳパラメータを示す図である。
【図５４】Ａ−ＭＰＤＵの構成を示す図である。
【図５５Ａ】簡略化されたバッファスキームに基づく送信側における拡張ＭＡＣアーキテクチャの代替実施形態を示す図である。
【図５５Ｂ】簡略化されたバッファスキームに基づく送信側における拡張ＭＡＣアーキテクチャの代替実施形態を示す図である。
【図５６】バッファリング機能ブロック図である。
【図５７Ａ】それぞれのＡＣごとの別々のバッファを示すブロック図である。
【図５７Ｂ】それぞれのＡＣごとの別々のバッファを示すブロック図である。
【図５８】プライマリーチャネルにおいて送信が失敗した場合の再送信の例を示す図である。
【図５９】クォータナリーチャネルにおいて送信が失敗した場合の再送信の例を示す図である。
【発明を実施するための形態】
【０００７】
本明細書では、「ＷＴＲＵ（wireless transmit/receive unit）」という用語は、ＵＥ（user equipment）、ＳＴＡ（station）、移動局、固定式または移動式のサブスクライバユニット、ページャー、セルラー電話、ＰＤＡ（personal digital assistant）、非ＡＰステーション、コンピュータ、または、ワイヤレス環境において動作可能な他の任意のタイプのユーザデバイスを含むが、それらには限定されない。ＷＴＲＵとは、非インフラストラクチャー型のノード（non-infrastructure node）であると言える。
【０００８】
また、「ＡＰ（access point）」という用語は、Ｎｏｄｅ−Ｂ、サイトコントローラ、基地局、または、ワイヤレス環境において動作可能な他の任意のタイプのインターフェーシングデバイスを含むが、それらには限定されない。また、「ネットワークノード」、「ネットワーク要素」および「ネットワークコンポーネント」という用語は、通信ネットワークに接続されてデータを送信および／または受信することができる任意の電子デバイスを指すが、それらには限定されない。
【０００９】
図１Ａは、１つまたは複数の開示される実施形態を実施することができる例示的な通信システム１００を示す。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数のワイヤレスユーザに提供する多重アクセスシステムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。通信システム１００は、１つまたは複数のチャネルアクセス方法、例えば、ＣＤＭＡ（code division multiple access）、ＴＤＭＡ（time division multiple access）、ＦＤＭＡ（frequency division multiple access）、ＯＦＤＭＡ（orthogonal FDMA）、ＳＣ−ＦＤＭＡ（single-carrier FDMA）などを採用することができる。
【００１０】
図１Ａにおいて示されるように、通信システム１００は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ（radio access network）１０４、コアネットワーク１０６、ＰＳＴＮ（public switched telephone network）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示される実施形態では、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素が考えられるということが分かるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、ワイヤレス環境において動作し、および／または通信するように構成される任意のタイプのデバイスとすることができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されることができ、およびＵＥ、移動局、固定式または移動式のサブスクライバユニット、ページャー、セルラー電話、ＰＤＡ、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家庭用電化製品などを含むことができる。
【００１１】
通信システム１００は、基地局１１４ａおよび基地局１１４ｂを含むこともできる。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つとワイヤレスにインターフェースを取るように構成される任意のタイプのデバイスとすることができる。例えば、基地局１１４ａ、１１４ｂは、ＢＴＳ（base transceiver station）、Ｎｏｄｅ−Ｂ、ｅＮＢ（evolved Node-B）、ＨＮＢ（Home Node-B）、ＨｅＮＢ（Home eNB）、サイトコントローラ、ＡＰ、ワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含みうるということが分かるであろう。
【００１２】
基地局１１４ａは、ＲＡＮ１０４の一部とすることができ、ＲＡＮ１０４は、他の基地局および／またはネットワーク要素（図示せず）、例えば、ＢＳＣ（base station controller）、ＲＮＣ（radio network controller）、中継ノードなどを含むこともできる。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内でワイヤレス信号を送信および／または受信するように構成されることができ、この地理的領域は、セル（図示せず）と呼ばれることもある。セルは、複数のセルセクタへとさらに分割することができる。例えば、基地局１１４ａに関連付けられるセルは、３つのセクタへと分割することができる。したがって一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのそれぞれのセクタごとに１つのトランシーバを含むことができる。別の実施形態においては、基地局１１４ａは、ＭＩＭＯ（multiple-input multiple-output）技術を採用することができ、したがって、セルのそれぞれのセクタごとに複数のトランシーバを利用することができる。
【００１３】
基地局１１４ａ、１１４ｂは、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信することができ、エアインターフェース１１６は、任意の適切なワイヤレス通信リンク（例えば、ＲＦ（radio frequency）、マイクロ波、ＩＲ（infrared）、ＵＶ（ultraviolet）、可視光など）とすることができる。エアインターフェース１１６は、任意の適切なＲＡＴ（radio access technology）を使用して確立されうる。
【００１４】
具体的には上述したように、通信システム１００は、多重アクセスシステムとすることができ、１つまたは複数のチャネルアクセス方式、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどを採用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＴＲＡ（UMTS(universal mobile telecommunications system)terrestrial radio access）などの無線技術を実施することができ、この無線技術は、Ｗ−ＣＤＭＡ（登録商標）（wideband CDMA）を使用してエアインターフェース１１６を確立することができる。Ｗ−ＣＤＭＡは、ＨＳＰＡ（high-speed packet access）および／またはＨＳＰＡ＋（evolved HSPA）などの通信プロトコルを含むことができる。ＨＳＰＡは、ＨＳＤＰＡ（high-speed downlink packet access）および／またはＨＳＵＰＡ（high-speed uplink packet access）を含むことができる。
【００１５】
別の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅ−ＵＴＲＡ（evolved UTRA）などの無線技術を実施することができ、この無線技術は、ＬＴＥ（long term evolution）および／またはＬＴＥ−Ａ（LTE-Advanced）を使用してエアインターフェース１１６を確立することができる。
【００１６】
他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無線技術、例えば、ＩＥＥＥ  ８０２．１６（すなわち、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、ＩＳ−２０００（Interim Standard 2000）、ＩＳ−９５（Interim Standard 95）、ＩＳ−８５６（Interim Standard 856）、ＧＳＭ（登録商標）（global system for mobile communications）、ＥＤＧＥ（enhanced data rates for GSM evolution）、ＧＥＲＡＮ（GSM/EDGE RAN）などを実施することができる。
【００１７】
図１Ａにおける基地局１１４ｂは、例えば、ワイヤレスルータ、ＨＮＢ、ＨｅＮＢまたはＡＰとすることができ、局所的なエリア、例えば、事業所、家庭、乗り物、キャンパスなどにおけるワイヤレス接続を容易にするために、任意の適切なＲＡＴを利用することができる。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＬＡＮ（wireless local area network）を確立するために、ＩＥＥＥ８０２．１１などの無線技術を実施することができる。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＷＰＡＮ（wireless personal area network）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実施することができる。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ピコセルまたはフェムトセルを確立するために、セルラーベースのＲＡＴ（例えば、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有しうる。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることを不要とすることができる。
【００１８】
ＲＡＮ１０４は、コアネットワーク１０６と通信状態にあることが可能であり、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはＶｏＩＰ（voice over Internet protocol）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成される任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、コール制御、課金サービス、モバイル位置情報サービス、プリペイドコーリング、インターネット接続、ビデオ配信などを提供し、および／またはユーザ認証などのハイレベルセキュリティー機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと直接または間接の通信状態にあることが可能であるということが分かるであろう。例えば、コアネットワーク１０６は、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０４に接続されていることに加えて、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信状態にあることも可能である。
【００１９】
コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能することもできる。ＰＳＴＮ１０８は、ＰＯＴＳ（plain old telephone service）を提供する回線交換電話ネットワークを含みうる。インターネット１１０は、ＴＣＰ／ＩＰスイートにおけるＴＣＰ、ＵＤＰおよびＩＰなど、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスからなるグローバルシステムを含むことができる。他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている有線または無線の通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用可能な１つまたは複数のＲＡＮに接続されている別のコアネットワークを含むことができる。
【００２０】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、別々のワイヤレスリンク上で別々のワイヤレスネットワークと通信するために複数のトランシーバを含むことができる。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用しうる基地局１１４ａ、およびＩＥＥＥ８０２無線技術を採用しうる基地局１１４ｂと通信するように構成されうる。
【００２１】
図１Ｂは、図１Ａに示される通信システム１００内で使用可能な例示的なＷＴＲＵ１０２を示す。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素（例えば、アンテナ）１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、ＧＰＳ（global positioning system）チップセット１３６および周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、上述の要素どうしの任意のサブコンビネーションを含むことができるということが分かるであろう。
【００２２】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ＤＳＰ（digital signal processor）、マイクロプロセッサ、ＤＳＰコアと関連付けられている１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（application specific integrated circuit）、ＦＰＧＡ（field programmable gate array）回路、ＩＣ（integrated circuit）、状態マシンなどとすることができる。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２を無線環境内で動作できるようにする他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合することができ、トランシーバ１２０は、送信／受信要素１２２に結合することができる。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別々のコンポーネントとして示しているが、プロセッサ１１８とトランシーバ１２０は、１つの電子パッケージまたはチップ内に統合することができる。
【００２３】
送信／受信要素１２２は、エアインターフェース１１６上で、基地局（例えば、基地局１１４ａ）に信号を送信するように、または基地局（例えば、基地局１１４ａ）から信号を受信するように構成されることができる。例えば、一実施形態においては、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されるアンテナとすることができる。別の実施形態においては、送信／受信要素１２２は、例えば、ＩＲ信号、ＵＶ信号、または可視光信号を送信および／または受信するように構成されるエミッタ／検知器とすることができる。さらに別の実施形態においては、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成されることができる。送信／受信要素１２２は、ワイヤレス信号の任意の組合せを送信および／または受信するように構成されることができる。
【００２４】
また、送信／受信要素１２２は、図１Ｂにおいては単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。具体的には、ＷＴＲＵ１０２はＭＩＭＯ技術を採用することができる。従って、一実施形態においては、ＷＴＲＵ１０２は、エアインターフェース１１６上で無線信号を送信および受信するために、複数の送信／受信要素１２２（例えば、複数のアンテナ）を含むことができる。
【００２５】
トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調するように、また、送信／受信要素１２２によって受信される信号を復調するように構成されることができる。上述したように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがってトランシーバ１２０は、ＷＴＲＵ１０２が、ＵＴＲＡおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信できるようにするために複数のトランシーバを含むことができる。
【００２６】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６および／またはディスプレイ／タッチパッド１２８（例えば、ＬＣＤ（liquid crystal display）ディスプレイユニットまたはＯＬＥＤ（organic light-emitting diode）ディスプレイユニット）に結合することができ、そこからユーザ入力データを受け取ることができる。プロセッサ１１８は、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６および／またはディスプレイ／タッチパッド１２８へ出力することもできる。また、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスし、およびそれらのメモリにデータを格納することができる。非リムーバブルメモリ１３０は、ＲＡＭ、ＲＯＭ、ハードディスク、または他の任意のタイプのメモリストレージデバイスを含むことができる。リムーバブルメモリ１３２は、ＳＩＭ（subscriber identity module）カード、メモリスティック、ＳＤ（secure digital）メモリカードなどを含むことができる。他の実施形態においては、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリからの情報にアクセスし、およびそのメモリにデータを格納することができる。
【００２７】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、また、ＷＴＲＵ１０２内の他のコンポーネントへの電力を分配および／または制御するように構成されることができる。電源１３４は、ＷＴＲＵ１０２に電力供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ＮｉＣｄ（nickel-cadmium）、ＮｉＺｎ（nickel-zinc）、ＮｉＭＨ（nickel metal hydride）、Ｌｉ−ｉｏｎ（lithium-ion）など）、太陽電池、燃料電池などを含むことができる。
【００２８】
プロセッサ１１８は、ＧＰＳチップセット１３６に結合することもでき、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成されることができる。ＧＰＳチップセット１３６からの情報に加えて、またはその情報の代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６上で位置情報を受信すること、および／または複数の近隣の基地局から受信される信号のタイミングに基づいて自分の位置を特定することができる。ＷＴＲＵ１０２は、一実施形態との整合性を保持しながら、任意の適切な位置特定方法を通じて位置情報を得ることができる。
【００２９】
プロセッサ１１８は、他の周辺機器１３８にさらに結合することができ、他の周辺機器１３８は、さらなる特徴、機能、および／または有線接続若しくは無線接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅ−コンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ＵＳＢポート、振動デバイス、テレビジョントランシーバ、ハンドフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（frequency modulated）ラジオユニット、デジタルミュージックプレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含むことができる。
【００３０】
図１Ｃは、図１Ａに示される通信システム１００内で使用可能な例示的なＲＡＮ１０４およびコアネットワーク１０６を示す。ＲＡＮ１０４は、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＩＥＥＥ８０２．１６無線技術を採用するＡＳＮ（access service network）とすることができる。
【００３１】
図１Ｃに示されるように、ＲＡＮ１０４は、基地局１４０ａ、１４０ｂ、１４０ｃ、およびＡＳＮゲートウェイ１４２を含むことができるが、ＲＡＮ１０４は、一実施形態との整合性を保持しながら、任意の数の基地局およびＡＳＮゲートウェイを含むことができるということが分かるであろう。基地局１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０４内の特定のセル（図示せず）に関連付けることができ、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために１つまたは複数のトランシーバを含むことができる。一実施形態においては、基地局１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実施することができる。したがって、基地局１４０ａは、例えば、ＷＴＲＵ１０２ａに無線信号を送信するために、およびＷＴＲＵ１０２ａから無線信号を受信するために、複数のアンテナを使用することができる。基地局１４０ａ、１４０ｂ、１４０ｃは、モビリティーマネージメント機能、例えば、ハンドオフのトリガリング、トンネルの確立、無線リソースマネージメント、トラフィックの分類、ＱｏＳポリシーの実施などを提供することもできる。ＡＳＮゲートウェイ１４２は、トラフィック集約ポイントとして機能することができ、ページング、サブスクライバプロフィールのキャッシング、コアネットワーク１０６へのルーティングなどを担当することができる。
【００３２】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＲＡＮ１０４との間のエアインターフェース１１６は、ＩＥＥＥ８０２．１６仕様を実施することができる。また、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々は、コアネットワーク１０６との論理インターフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、コアネットワーク１０６との間における論理インターフェースは、認証、許可、ＩＰホスト構成マネージメント、および／またはモビリティーマネージメントのために使用されうる。
【００３３】
基地局１４０ａ、１４０ｂ、１４０ｃの各々の間における通信リンクは、ＷＴＲＵのハンドオーバ、および基地局同士の間におけるデータの転送を容易にするためのプロトコルを含むことができる。基地局１４０ａ、１４０ｂ、１４０ｃと、ＡＳＮゲートウェイ１４２との間における通信リンクは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの各々に関連付けられているモビリティーイベントに基づいてモビリティーマネージメントを容易にするためのプロトコルを含むことができる。
【００３４】
図１Ｃに示されるように、ＲＡＮ１０４は、コアネットワーク１０６に接続されうる。ＲＡＮ１０４と、コアネットワーク１０６との間における通信リンクは、例えば、データ転送およびモビリティーマネージメント機能を容易にするためのプロトコルを含みうる。コアネットワーク１０６は、ＭＩＰ−ＨＡ（mobile IP home agent）１４４、ＡＡＡ（authentication, authorization, accounting）サーバ１４６およびゲートウェイ１４８を含みうる。上述の要素の各々は、コアネットワーク１０６の一部として示されているが、これらの要素のいずれかが、コアネットワークオペレータ以外のエンティティによって所有および／または運営されることも可能であるということが分かるであろう。
【００３５】
ＭＩＰ−ＨＡは、ＩＰアドレスマネージメントを担当することができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、別々のＡＳＮおよび／または別々のコアネットワークの間でローミングすることを可能にすることができる。ＭＩＰ−ＨＡ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、ＩＰ対応デバイスとの間における通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。ＡＡＡサーバ１４６は、ユーザ認証と、ユーザサービスをサポートすることとを担当することができる。ゲートウェイ１４８は、他のネットワークと相互作用することを容易にしうる。例えば、ゲートウェイ１４８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと、従来の固定電話通信デバイスとの間における通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。また、ゲートウェイ１４８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができ、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営されている他の有線または無線のネットワークを含むことができる。
【００３６】
図１Ｃには示されていないが、ＲＡＮ１０４は他のＡＳＮに接続することができ、コアネットワーク１０６は他のコアネットワークに接続することができるということが分かるであろう。ＲＡＮ１０４と、他のＡＳＮとの間における通信リンクは、ＲＡＮ１０４と、他のＡＳＮとの間においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティーをコーオーディネートする（coordinate）ためのプロトコルを含むことができる。コアネットワーク１０６と、他のコアネットワークとの間における通信リンクは、ホームコアネットワークと、訪問先コアネットワークとの間における相互作用を容易にするためのプロトコルを含むことができる。
【００３７】
例えば、ＩＥＥＥ８０２．１１システムなどのローカルワイヤレスネットワークシステムは、ＩＳＭ（industrial, scientific and medical）帯域などの事前に定義されたスペクトルにおいて動作することができる。ＩＥＥＥ８０２．１１システムは、連続したスペクトルチャネルにおいて動作することができる。
【００３８】
米国においては、５４ＭＨｚから８０６ＭＨｚまでのスペクトルの４０８ＭＨｚが、ＴＶ（television）のために割り当てられている。現在、そのスペクトルのうちの１０８ＭＨｚが、オークションを通じた商業オペレーション向けに、および公安用途向けに再開発されている。この主要な電波スペクトルのうちの残りの３００ＭＨｚは、引き続きＯＴＡ（over-the-air）ＴＶオペレーション専用とすることができる。しかし、全米にわたって、その３００ＭＨｚのリソースのうちの複数の部分が未使用のままである。未使用のスペクトルの量および厳密な周波数は、場所ごとに異なる場合がある。スペクトルのうちのこれらの未使用の部分は、ＴＶＷＳと呼ばれている。ＦＣＣ（Federal Communications Commission）は、これらの未使用のＴＶＷＳ周波数を、ライセンス供与されていない様々な使用のために開放することを検討している。トップの大都市エリアの外側では、配置されているＴＶ局が少なくなるため、占有されていないＴＶＷＳスペクトルのほとんどは、ＤＳＬ（digital subscriber line）またはケーブルなど、他のブロードバンドオプションを十分に提供されていない傾向がある人口密度の低いまたは田舎のエリアにおいて利用可能である。
【００３９】
それぞれの利用可能なＴＶチャネルは、ブロードバンド接続のために使用可能なスペクトル容量のうちの６ＭＨｚを提供することができる。ＴＶＷＳは、これらの周波数における長距離の信号伝搬に起因して、はるかに大きなカバレッジエリアを有することができる。例えば、ＴＶＷＳにおいて動作するＷＬＡＮ  ＡＰロケーションは、２〜３平方マイルのエリアにわたるカバレッジを提供することができる。一方、例えば、現在ＩＥＥＥ８０２．１１ｂ／ｇ／ｎシステムにおいて動作するワイヤレス機器は、１５０平方フィートの平均カバレッジエリアを有することができる。
【００４０】
図２は、ＩＥＥＥ８０２．１１ｎシステムにおける２０ＭＨｚのプライマリーチャネル２０５および２０ＭＨｚのセカンダリーチャネル２１０の一例を示す。プライマリーチャネル２０５は、ＢＳＳ（basic service set）のメンバーである全てのＷＴＲＵ（すなわち、ＳＴＡ）のためのオペレーションの共通チャネルである。全てのマネージメントトラフィック（ビーコン）は、プライマリーチャネル２０５上で送信されることができる。セカンダリーチャネル２１０は、４０ＭＨｚのチャネルを生成する目的で、プライマリーチャネル２０５と関連付けて、ＨＴ（high-throughput）  ＷＴＲＵによって使用することができる。送信側デバイスが送信の際にセカンダリーチャネル２１０の状態を考慮することは、まったく不要とすることができる。
【００４１】
図２に示されるように、４０ＭＨｚのチャネルペア２０５／２１０へのアクセスは、ＰＣＳＭＡ（primary carrier sensing multiple access）を実行すること（すなわち、プライマリーチャネル２０５上でのみＣＳＭＡを実行すること）によって制御されうる。ＷＴＲＵが送信の前にセカンダリーチャネル２１０の搬送波感知状態を考慮する必要がないため、セカンダリーチャネル２１０上でのコリジョンの可能性が大幅に高まる。
【００４２】
図２に示されるように、ＣＳＭＡバックオフ手順は、プライマリーチャネル２０５上で実行されうる。送信の前に、ＷＴＲＵの全ては、プライマリーチャネル２０５が、ＡＩＦＳ時間にわたって、且つバックオフに入るために（ＡＩＦＳ＋バックオフ期間２１５）アイドルであることを確実にすることができる。自分のバックオフが最初に期限切れになったＷＴＲＵが、コンテンションに勝ち、プライマリーチャネル２０５上で送信へのアクセスを得る。セカンダリーチャネル２１０は、ＰＩＦＳ（PCF(point coordination function)inter-frame space）期間２２０にわたって感知されることが可能であり、このＰＩＦＳ期間は、ＡＩＦＳ＋バックオフ期間２１５よりもはるかに短い。
【００４３】
ＩＥＥＥ８０２．１１ｎシステムは、連続したスペクトルにおいて動作し、２つの異なる延期モードで動作することができる。延期／２０／４０モードにおいては、ＷＴＲＵは、プライマリーチャネル２０５およびセカンダリーチャネル２１０の両方がアイドルである場合には４０ＭＨｚで送信を行い、若しくはプライマリーチャネル２０５がアイドルである場合には２０ＭＨｚで送信を行い、またはプライマリーチャネル２０５がビジーである場合には送信を延期する。延期／４０モードにおいては、ＷＴＲＵは、プライマリーチャネル２０５およびセカンダリーチャネル２１０の両方がアイドルである場合に４０ＭＨｚで送信を行うか、または送信を延期する。しかし、実施態様の制約に起因して、ＷＴＲＵのほとんどは、延期／４０モードを使用することができる。
【００４４】
図３は、ＩＥＥＥ８０２．１１ａｃシステムにおけるプライマリーチャネル３０５の一例を示す。ＩＥＥＥ８０２．１１ａｃシステムは、８０ＭＨｚまたは１６０ＭＨｚの帯域幅上で動作するＨＴシステムであるため、プライマリーチャネル３０５と、複数の非プライマリーチャネル（例えば、セカンダリーチャネル３１０、ターシャリーチャネル３１５、またはクォータナリーチャネル３２０）とを含む複数の連続した２０ＭＨｚのチャネルを使用することができる。ＷＴＲＵまたはノード（例えば、ＡＰまたはｅＮＢ）は、転送すべき制御／データを有するたびに、プライマリーチャネル３０５上でＣＳＭＡ（ＡＩＦＳ＋バックオフ）を実行することができ、その他の非プライマリーチャネル３１０、３１５および３２０は、プライマリーチャネル３０５と同じチャネルステータスを有すると想定することができる（すなわち、プライマリーチャネル３０５上のＣＳＭＡが、ビジーのステータスを返した場合には、チャネル３０５、３１０、３１５および３２０の全てがビジーであり、ひいてはビジーのステータスを返すように設定されていると想定することができる）。ＷＴＲＵまたはノードは、プライマリーチャネル３０５へのアクセスを得ると、次いで、送信前のＰＩＦＳ期間中に非プライマリーチャネル３１０、３１５、および３２０をチェックして、それらのチャネルの全てが実際に空いていることを確かめる上で役立つことができる。ＩＥＥＥ８０２．１１ａｃシステムは、８０ＭＨｚの帯域幅のシナリオに関して延期／２０／４０／８０モードを使用することができる。
【００４５】
上述のコンセプトは、「チャネルボンディング」として知られている。ＩＥＥＥ８０２．１１ｎシステムにおける２つのチャネルを伴う４０ＭＨｚの帯域幅と、ＩＥＥＥ８０２．１１ａｃシステムにおける８０ＭＨｚのスペクトルとからなる大きなチャンクは、物理層の視点から１つの大きなチャネルとして使用されることができ、すなわち、この巨大な帯域幅上で送信される１つのＰＰＤＵ（physical layer protocol data unit）または１つのＡ−ＰＰＤＵ（aggregated PPDU）だけが存在する。
【００４６】
図４は、ＤＳＭ（dynamic spectrum management）システム動作チャネルにおける制御およびデータによる複数の集約されたチャネルのタイムシェアリングの一例を示す。これらのチャネルは、連続または不連続とすることができる。これらの集約されたチャネルは、ＤＳＭエンジンとＤＳＭクライアントとの間においてデータパケットおよび制御／マネージメントパケットを送信するために使用されることができる。
【００４７】
ライセンス供与されていないスペクトルまたはオポチュニスティックな（opportunistic）スペクトル（すなわち、プライマリーユーザまたは高い優先度のユーザが、そのスペクトル上に存在しない限り、ライセンス供与されていないデバイスによって使用可能なスペクトル）における集約されたチャネルは、ライセンス供与されているユーザが優先権を有しているため、常に利用できるとは限らない場合がある。したがって、プライマリーユーザが現れると、当該チャネルは使用できなくなる場合がある。例えば、それぞれのチャネルが、５ＭＨｚの帯域幅を有する場合があり、したがって、それらのチャネルを集約すれば、合計で２０ＭＨｚの帯域幅を提供することができる。
【００４８】
複数の集約されたチャネルに基づく集約されたチャネルアクセスの様々な例について、ここで説明する。任意の数（ｘ）の集約されたチャネルを使用することができ、その場合には、いかなる周波数帯域においても、ｘ＞１であることを当業者なら理解するはずである。ここでは具体的にＡＰに言及するが、ここで説明する特徴は、ＬＴＥに関して使用されるｅＮＢなど、他のタイプのノードに適用することもできるということを当業者なら理解するはずである。
【００４９】
ＭＡＣ層のＣＳＭＡは、プライマリーチャネル上で実行されうる。プライマリーチャネルは、不連続なスペクトル上で複数のＭＰＤＵ（MAC protocol data unit）を送信する目的でＭＡＣ層においてチャネルアグリゲーションを実行するために使用されうる。例えば、４つの集約されたチャネルを使用するシナリオにおいては、４つのチャネルのうちの１つは、ＡＰによってプライマリーチャネルとして割り当てられうる。ＷＴＲＵまたはＡＰは、転送すべき制御／マネージメントパケットまたはデータを有するたびに、事前に割り当てられたプライマリーチャネル上でＣＳＭＡを実行することができ、他の３つのチャネルは、プライマリーチャネルと同じチャネルステータスを有すると想定することができる（すなわち、プライマリーチャネル上のＣＳＭＡが、ビジーのステータスを返した場合には、４つのチャネル全てがビジーであると想定することができる）。ＷＴＲＵまたはＡＰは、プライマリーチャネルへのアクセスを得ると、集約されたチャネルのセット全体へのアクセスを得ることもできる。次いでＷＴＲＵおよびＡＰは、送信前のＰＩＦＳ期間中に非プライマリー（すなわち、セカンダリー、ターシャリー、およびクォータナリー）チャネルをチェックして、４つのチャネル全てが実際に空いていることを確かめる上で役立つことができる。
【００５０】
集約されたチャネルは、ＰＨＹにおいて帯域幅の１つの結合されたチャンクとみなされることはできない。その代わりに、別々のＰＤＵまたは（マネージメント／制御パケットのための）マネージメントＰＤＵが、送信側デバイスによってそれぞれのチャネル上で送信される。それらのＰＤＵは１つまたは複数のＷＴＲＵへ向けられうる。受信側のＷＴＲＵは、（必要な場合には、）自分が受信するそれぞれのＰＤＵごとに別々に肯定ＡＣＫ（acknowledgement）メッセージを送信することができる。例えば、ＷＴＲＵは、集約されたチャネルの全ての上で同時のＰＤＵを正しく受信した場合には、集約されたチャネルのそれぞれの上でＡＣＫを送信することができる。
【００５１】
図５は、プライマリーチャネル上のＭＡＣ層のＣＳＭＡの一例を示す。図５に示されるように、プライマリーチャネル上でのＣＳＭＡコンテンションに勝ったデバイスが、集約されたチャネルの全てへのアクセスを得る。ＰＩＦＳ期間中にＣＣＡ（clear channel assessment）インジケーションが受信され、非プライマリーチャネル上でビジーステータスが返された場合には、ビジーな非プライマリー（例えば、セカンダリー）チャネルは使用されることはできず、送信は、依然として残りのチャネル上で行うことができる。プライマリーチャネルがビジーである場合には、送信全体はその後の送信機会まで延期されることができる。
【００５２】
それぞれの動作チャネルが約５ＭＨｚの帯域幅であると想定すると、この手順は、可用性に応じて、集約されたチャネルの１つまたは複数の上で送信するオプションを可能にするため、延期５／１０／１５／２０手順と呼ばれる場合がある。延期５／１０／１５／２０手順は、チャネルの動的な選択を可能にし、全てのチャネルがアイドルである場合にはデバイスが全て２０ＭＨｚを使用することを可能にするか、または、図６に示されるように、望ましくない干渉源によって１つまたは複数の非プライマリーチャネルが占有されている場合（すなわち、それらの非プライマリーチャネルが、非プライマリーチャネルに適用されるＣＣＡによって、ビジーであると判明した場合）には、延期１５／１０／５手順を使用することができる。
【００５３】
さらに、別々の帯域幅を有するチャネル同士を集約することができる。例えば、チャネル１は、１０ＭＨｚの帯域幅上で機能することができ（２つの連続したビデオチャネル上で機能し）、その一方で、残りのチャネル（２、３、および４）は、それぞれ５ＭＨｚの帯域幅上で機能することができる。プライマリーチャネルの選択は、このことを考慮に入れることができる。
【００５４】
加えて、ＭＡＣバッファ内のデータの量に応じて、送信側デバイスは、送信するための別々のＰＤＵを有する必要がない場合がある。このシナリオにおいては、デバイスは、下記のオペレーションのうちの１つまたは複数を実行することができる。
【００５５】
１）セグメント化：デバイスは、ＰＤＵをさらに小さなＰＤＵへとセグメント化することができる。デバイスは、チャネルの浪費をもたらす非常に大きなＭＡＣ／ＰＨＹオーバーヘッドが生じるような形でＰＤＵがセグメント化されることが決してないようにすることができる。
【００５６】
２）繰り返し：デバイスは、システムの堅牢性を高めるために、複数のチャネル上で同じＰＤＵを同時に送信することができる。例えば、ターシャリーチャネルおよびクォータナリーチャネルが、より低いリンク品質を有しており、デバイスが、送信すべき３つのＰＤＵを有している場合には、デバイスは、ターシャリーチャネルおよびクォータナリーチャネルの両方の上でＰＤＵを３回繰り返すことができる。
【００５７】
３）ヌル送信：デバイスは、送信のために必要とされていないチャネルにおいてヌルフレームを送信することを選択することができる。例えば、デバイスは、３つのＰＤＵを送信しなければならない場合には、ＰＤＵ１、ＰＤＵ２、およびＰＤＵ３をプライマリーチャネル、セカンダリーチャネル、およびターシャリーチャネル上で、並びにヌルフレームをクォータナリーチャネル上で送信することができる。ヌルの送信は、そのチャネルが引き続きビジーであることを確かにするために（すなわち、他の外部のＡＰまたはコーオーディネートされていないデバイスが自分の送信をそのチャネル上で開始することが決してないようにするために）必要とされる。
【００５８】
４）いくつかの非プライマリーチャネル上では送信を行わない：非プライマリーチャネル上ではＣＳＭＡが行われないため、１つまたは複数の非プライマリーチャネル上でＰＤＵをまったく送信しないことが可能な場合がある。
【００５９】
デバイスは、チャネルにアクセスするためにＲＴＳ（request to send）メッセージおよびＣＴＳ（clear to send）メッセージを使用することもできる。しかし、ＲＴＳ／ＣＴＳ手順は、不連続なスペクトル上で動作する集約されたチャネル上で動作するように適合されなければならない。通常のＲＴＳ／ＣＴＳ手順は、送信側デバイスが、意図されている受信側デバイスへＲＴＳメッセージを送信したときに開始する。受信側デバイスは、応答可能である場合には、ＳＩＦＳ（short interframe space）期間にわたって待機した後に、ＣＴＳメッセージを用いて応答することができる。次いで送信側デバイスは、ＳＩＦＳ期間にわたって待機した後に、データパケットを送信することができる。そしてデータパケットの後には、やはりＳＩＦＳ期間にわたる待機の後に、受信側デバイスからのＡＣＫが続くことができる。ＲＴＳメッセージは、ＭＡＣヘッダ内にデュレーションフィールドを含むことができ、このフィールドは、このデータ送信のためにチャネルを確保することができる時間（ＡＣＫが受信されるまでの時間）について全てのデバイスに知らせる。これは、他のデバイスのＮＡＶ（network allocation vector）をしかるべく設定することによって、その他のデバイスが、この保護された期間中に送信を行うことが決してないようにする。
【００６０】
図７に示されるように、送信側デバイスは、集約されたチャネルを求めてプライマリーチャネル上で競合することができる（すなわち、プライマリーチャネル上でＡＩＦＳにわたって待機してバックオフを実行することができる）。送信側デバイスは、チャネルへのアクセスを得ると、ＲＴＳメッセージを送り出すことができる。このＲＴＳメッセージを受信すると、受信側デバイスは、データ送信のための保護された期間を確立するためにＣＴＳメッセージを用いて応答することができる。ＳＩＦＳ期間にわたる待機の後に、集約されたチャネルの全ての上でデータを送信することができ、その後には、集約されたチャネルの全ての上でＡＣＫが続く。
【００６１】
ＲＴＳメッセージ内のデュレーションフィールドは、ＳＩＦＳ＋ＣＴＳ送信時間＋ＳＩＦＳ＋集約されたチャネル上での最長のパケットの送信時間＋ＳＩＦＳ＋ＡＣＫ送信時間に設定されうる。同様に、ＣＴＳパケット内のデュレーションフィールドは、ＳＩＦＳ＋集約されたチャネル上での最長のパケットの送信時間＋ＳＩＦＳ＋ＡＣＫに設定されうる。最長のパケットの送信時間は、チャネルのいずれか１つの上に送信が存在する限り、チャネルの全てが引き続きビジーであるように使用されることができる。
【００６２】
あるいは、ＲＴＳ／ＣＴＳメッセージは、堅牢性を高めるために、複数のチャネル上で、または集約されたチャネルの全ての上で送信することができる。このケースにおいては、非プライマリーチャネル上で送信されるＲＴＳメッセージは、ＰＩＦＳ期間中にチャネルを感知した後に送信されることができる。
【００６３】
デバイス（例えば、ＡＰ）は、複数のユーザへ同時に送信を行うためのチャネルを確保するためにＲＴＳ／ＣＴＳメッセージを使用することもできる。ソースＷＴＲＵは、複数の宛先アドレスを用いてプライマリーチャネル上でＲＴＳメッセージを送信することができる。宛先ＷＴＲＵは、ＲＴＳメッセージ内で指定されるように複数のチャネル上でＳＩＦＳ期間にわたって待機した後にＣＴＳメッセージを用いて応答することができる。次いでソースＷＴＲＵは、別々のチャネル上で別々の宛先ＷＴＲＵに宛てられている複数のＰＤＵを同時に送信することができる。宛先ＷＴＲＵは、自分がその送信を受信した同じチャネル上でＡＣＫメッセージを送信することができる。ＡＣＫの全ては、ＳＩＦＳ期間にわたって待機した後に、および集約されたチャネル上での最長のＰＤＵの終わりの後に、宛先ＷＴＲＵによって同時に送信されることができる。
【００６４】
図８に示されるように、最長のＰＤＵ送信がいつ終了するかをデバイスの全てが必ず分かるようにするために、最長の送信はプライマリーチャネルにおいて行われるように強制することができ、また、どのチャネルの送信が最も長く続くかを示すために、最長チャネルインジケータをＭＡＣヘッダ内に設定することができる。
【００６５】
図９は、フレーム制御フィールド９０５、デュレーションフィールド９１０、受信アドレスフィールド９１５、送信アドレスフィールド９２０、ＣＴＳチャネルフィールド９２５、送信チャネルフィールド９３０、およびＦＣＳ（frame check sequence）フィールド９３５を含むＲＴＳメッセージ９００のフレーム構造を示す。受信アドレス（１．．．Ｎ）フィールドは、ＲＴＳメッセージ９００が導かれる先の意図されている宛先ＷＴＲＵのアドレスを含む。フィールド９１５内のアドレスの最大数はＮであり、これは、チャネルの数を超えることはできない（例えば、図８に示されるシナリオでは、Ｎ＝４である）。ＣＴＳチャネル（１．．．Ｎ）フィールド９２５は、指定されたチャネル上でＣＴＳメッセージを送信するようにそれぞれの宛先ＷＴＲＵに指示する。例えば、図８に示されるシナリオにおいては、ＣＴＳチャネル１は、プライマリーチャネルに設定されており、ＣＴＳチャネル２は、ターシャリーチャネルに設定されている。送信チャネル（１．．．Ｎ）フィールド９３０は、データが送信されることになるチャネルについて宛先ＷＴＲＵに知らせる。例えば、図８に示されるシナリオにおいては、送信チャネル１は、プライマリーチャネルおよびセカンダリーチャネルに設定されており、送信チャネル２は、ターシャリーチャネルおよびクォータナリーチャネルとして指定されている。
【００６６】
ＲＴＳ／ＣＴＳメッセージは、システムの堅牢性を高めるために複数のチャネル上で送信されることができる。プライマリーチャネルは、専用の制御チャネルとして使用されることもできる。全てのＷＴＲＵは、プライマリーチャネル上で制御情報を受信および送信することができ、また、プライマリーチャネル上ではデータ送信を行うことができない。ビーコン、アソシエーション要求／応答、チャネル切り替えメッセージ、ＲＴＳ／ＣＴＳ、および他の全ての制御／マネージメントメッセージは、ＣＳＭＡを使用してプライマリーチャネル上で送信されることができる。データ送信に関しては、他の全てのチャネルは、プライマリーチャネルを使用してＡＰによって使用され、およびコーオーディネートされることができる。
【００６７】
ＷＴＲＵは、データチャネルへのアクセスを得るためにＲＴＳメッセージを送信することができる。ＲＴＳメッセージは、ＡＰに宛てることができ、本質的には、データ送信のためにチャネルを割り当てるようＡＰに求める要求である。ＡＰは、使用すべきチャネルと、それらのチャネルがＡＰに割り当てられているデュレーションとをＷＴＲＵに知らせるＣＴＳメッセージを用いて応答することができる。次いでＡＰは、それらのチャネル上でＰＤＵを送信することができ、同じチャネル上で宛先ＷＴＲＵからＡＣＫを受信することができる。ＷＴＲＵは、プライマリーチャネルを求めて競合するためにＣＳＭＡを実行する必要があるため、プライマリーチャネルに関するＮＡＶを保持することができ、その一方で、データチャネルに関しては、ＷＴＲＵは、送信を行うことができるチャネルを示すＣＴＳメッセージをＡＰから受信するまで、送信を行うことはできない。
【００６８】
図１０は、専用の制御チャネルとして動作するプライマリーチャネルの一例を示す。図１０に示されるように、第１のＷＴＲＵ（ＷＴＲＵ１）は、第２のＷＴＲＵ（ＷＴＲＵ２）へデータを転送するための帯域幅をＡＰに要求する。ＡＰは、ＳＩＦＳ期間にわたって待機した後にセカンダリーチャネルおよびターシャリーチャネルを使用することができることをＷＴＲＵ１に知らせるＣＴＳメッセージを用いて応答する。ＷＴＲＵ１が、セカンダリーチャネルおよびターシャリーチャネル上でパケットを送信している間に、第３のＷＴＲＵ（ＷＴＲＵ３）が、プライマリーチャネル上でのコンテンションに勝ち、パケットを第４のＷＴＲＵ（ＷＴＲＵ４）へ送信するためにＲＴＳメッセージをＡＰへ送信する。ＡＰは、ＳＩＦＳ期間にわたって待機した後にクォータナリーチャネルを使用するようＷＴＲＵ３に知らせるＣＴＳメッセージを用いて応答する。
【００６９】
チャネルの全てがビジーであり、ＡＰが、割り当てるためのチャネルをまったく有していないケースにおいては、ＡＰは、割り当てられたチャネル上で送信を行う前に特定の時間にわたって待機するようＷＴＲＵに求めることができ、またはＡＰは、失敗フラグとともにＣＴＳメッセージを送信することができる。後者のケースにおいては、ＷＴＲＵは、しばらくしてから再びＲＴＳを送信しなければならない場合がある。
【００７０】
図１１に示されるように、ＷＴＲＵがデータをＡＰへ送信しなければならないケースにおいては、そのデータをＣＴＳメッセージ内に含めて送信するために、それらのＷＴＲＵにプライマリーチャネルを割り当てることができる。これは、ＡＰが、ＷＴＲＵからデータを受信している間に、とにもかくにもビジーであり続ける場合があるためである。図１１に示されるように、ＮＡＶは、プライマリーチャネルにのみ基づく。
【００７１】
集約されたチャネルの全てが、単一の無線機（例えば、ＤＳＭシステム内の無線機）に属する場合には、ＷＴＲＵは、一方のチャネル上で受信を行っている間に、他方のチャネル上で同時に送信を行うことができない場合がある。これは、別々のチャネルの間における自己干渉をもたらす可能性がある。この問題を回避するために、ＷＴＲＵは、他のチャネル上でデータを送信している間に、プライマリーチャネルをリッスンすることができない。ＷＴＲＵが複数の無線機を有する場合には、ＷＴＲＵ内の無線機の１つが別のチャネル上でデータを送信している間に、プライマリーチャネル上で送信／受信を行うために、ＷＴＲＵ内の別の無線機を使用することができる。
【００７２】
図１２は、専用の制御チャネル手順のためにプライマリーチャネルにおいて使用されるＲＴＳメッセージ１２００のフレームフォーマットを示す。ＲＴＳメッセージ１２００は、フレーム制御フィールド１２０５、デュレーションフィールド１２１０、受信側アドレスフィールド１２１５、宛先アドレスフィールド１２２０、送信アドレスフィールド１２２５、要求チャネルフィールド（channel requested field）１２３０、およびＦＣＳフィールド１２３５を含むことができる。宛先アドレスフィールド１２２０は、データパケットを受信することになるＷＴＲＵのアドレスを含むことができる。受信側アドレスフィールド１２１５は、ＲＴＳメッセージ１２００を受信して、（通常は、ＡＰまたはネットワークコントローラによって送信される）ＣＴＳメッセージを用いて応答するＷＴＲＵのアドレスを含むことができる。データがＡＰへ宛てられている場合には、受信側アドレスフィールド１２１５および宛先アドレスフィールド１２２０は同じとすることができる。要求チャネルフィールド１２３０は、データを送信するためにソースＷＴＲＵによって必要とされるチャネルの数を示すことができる。
【００７３】
図１３は、専用の制御チャネル手順のためにプライマリーチャネルにおいて使用されるＣＴＳメッセージ１３００のフレームフォーマットを示す。このＣＴＳメッセージは、フレーム制御フィールド１３０５、デュレーションフィールド１３１０、受信側アドレスフィールド１３１５、待機時間フィールド１３２０、許可チャネルフィールド（channel granted field）１３２５、およびＦＣＳフィールド１３３０を含むことができる。待機時間フィールド１３２０は、ＷＴＲＵが、許可されたチャネル上でデータを送信できるようになる前に待機しなければならない場合がある（ＳＩＦＳ期間にわたって待機した後の）デュレーションを示すことができる。待機時間がゼロである場合には、ＷＴＲＵは、ＳＩＦＳ期間にわたって待機した後にデータ転送を開始することができる。許可チャネルフィールド１３２５は、ＷＴＲＵがデータを送信することを許可されているチャネルのチャネル番号または識別情報（ＩＤ）についてＷＴＲＵに知らせることができる。ＡＰは、その数の要求された利用可能なチャネルを有していない場合には、より少ないチャネルをソースＷＴＲＵに対して許可することができる。
【００７４】
結合されたＣＳＭＡは、集約されたチャネルにアクセスするための別の代替技術である。結合されたＣＳＭＡは、単にプライマリーチャネル上でのみＣＳＭＡを実行する代わりに、全てのチャネル上でＣＳＭＡを実行することができる。結合されたＣＳＭＡは、チャネルの全てにともにアクセスするために、全てのチャネル上で「ＡＮＤ」ロジックを使用することができる。したがって、結合されたＣＳＭＡは、延期５／１０／１５／２０オプションの使用を許可することができないか、またはさもなければ、集約されたチャネルのうちのいずれかがビジーである場合には、メディアは完全にブロックされることになる。
【００７５】
図１４は、ＡＮＤロジックの結合されたＣＳＭＡの一例を示す。結合されたＣＳＭＡは、どのチャネルがプライマリーチャネルであるかをトラッキングする必要性をなくすことができるが、全てのチャネル上でＣＳＭＡを実行すると、より多くの電力が消費され、より複雑になる場合がある。結合されたＣＳＭＡの利点は、最長の送信をプライマリーチャネル内に置いておく必要性がなくなることである。
【００７６】
チャネルアクセス手順を実施するＤＳＭシステムの堅牢なオペレーションをサポートするための様々な制御／マネージメントメッセージおよび手順について、以下で説明する。
【００７７】
図１５は、ＩＥ（information element）として、または別個のＭＡＣアクションフレームとしてビーコン内に含めて送信されうるＣＳＡ（channel switch announcement）メッセージ１５００を示す。ＣＳＡメッセージ１５００は、新たなチャネルに関する情報を含むこと、およびその新たなチャネルへ切り替えるための時間を示すことが可能である。ＣＳＡメッセージ１５００は、要素ＩＤフィールド１５０５、長さフィールド１５１０、チャネル切り替えモードフィールド１５１５、新たなチャネル番号フィールド１５２０およびチャネル切り替えカウントフィールド１５２５を含むことができる。
【００７８】
図１６は、集約された制御チャネルの実施態様において使用される修正されたＣＳＡメッセージ１６００の一例を示す。ＣＳＡメッセージ１６００は、複数の動作チャネルが存在すること、および複数のチャネルを新たな周波数へ同時に切り替えなければならない場合があることを考慮に入れることができる。図１６に示されるように、ＣＳＡメッセージ１６００のアクションフレームは、チャネルのうちのどれ（プライマリー、セカンダリー、ターシャリーまたはクォータナリー）が切り替えられているかを示す切り替えチャネルフィールド１６０５を含むことができる。切り替えチャネルフィールド１６０５は、複数のビットを含むことができ、当該ビットの各々は、集約されたチャネルの１つを表す。ビットは、１に設定されている場合には、その特定のチャネルが新たな周波数へ切り替えられていることを示すことができる。複数のチャネルが同時に切り替えられているケースにおいては、複数のビットを１に設定することができる（すなわち、００１１という値は、ターシャリーチャネルおよびクォータナリーチャネルが切り替えられていることを示している）。ＣＳＡメッセージ１６００は、新たなチャネルの周波数を示す新たなチャネル番号［１．．．Ｎ］フィールド１６１０を含むこともできる。新たなチャネル番号［１．．．Ｎ］フィールド１６１０は、Ｎ個までの新たなチャネル周波数を含むことができ、それらの新たなチャネル周波数は、切り替えられている（Ｎ個のうちの）各々のチャネルに対応し、例えば、Ｎ＝４である。ＣＳＡメッセージ１６００は、チャネル特徴フィールド１６１５をさらに含むことができ、チャネル特徴フィールド１６１５は、新たなチャネルの特性を示す。すなわち、そのチャネルが、モードＩＩデバイスによりデータのクエリーを行うことによって得られたものかどうか、または、そのチャネルが、感知専用デバイスにより、ライセンス供与されていないスペクトル若しくはオポチュニスティックなスペクトルを感知することによって得られたものかどうかを示す。チャネル特徴フィールド１６１５は、それぞれの新たなチャネルごとに３つの値（すなわち、値０：チャネルの特徴に関する利用可能な情報はない。値１：モードＩＩデバイスから得られたチャネル。値２：感知専用デバイスから得られたチャネル）を有することができる。
【００７９】
ＣＳＡメッセージ１６００は、チャネル切り替えまでの送信上の全ての制約を示すチャネル切り替えモードフィールド１６２０をさらに含むことができる。１に設定されているチャネル切り替えモードは、その要素を含むフレームが宛てられている先のネットワーク内のＷＴＲＵが、スケジュールされたチャネル切り替えまでにさらなるフレームを送信することができないということを示すことができる。０に設定されているチャネル切り替えモードは、受信側クライアントにいかなる要件も課すことはできない。
【００８０】
ＣＳＡメッセージ１６００は、ＷＴＲＵがＣＳＡ要素切り替えを新たなチャネルへ送信するまでのＴＢＴＴ（target beacon transmission time）の回数に設定可能なチャネル切り替えカウントフィールド１６２５をさらに含むことができる。値１は、次のＴＢＴＴの直前に切り替えを行うことができるということを示すことができる。値０は、その要素を含むフレームが送信された後の任意の時点で切り替えを行うことができるということを示すことができる。
【００８１】
ＣＳＡメッセージ１６００は、要素ＩＤフィールド１６３０および長さフィールド１６３５をさらに含むことができる。ＣＳＡメッセージ１６００は、全てのチャネル上でアクションフレームとして送信されうる（すなわち、ＣＳＡメッセージ１６００は、４つのチャネル全ての上で同時に繰り返されうる）。これによって、ＷＴＲＵがこのメッセージを必ず受信できるようにすることができる。また、このメッセージは、ビーコンの一部として送信される場合には、同じ理由で複数のセグメント上で繰り返されうる。
【００８２】
プライマリーチャネルの失敗および非プライマリーチャネルの失敗に関する下記の手順は、パワーセーブモードで動作しているデバイスがなく、また、４つの集約されたチャネル全てをリッスンしているデバイスもないということを前提としている。加えて、チャネルの失敗後の回復を容易にするために、ビーコンは、プライマリーチャネルの失敗のケースにおいてどのチャネルがプライマリーチャネルを引き継ぐかを順序付けたリストと、集約されたチャネル全体の失敗のための、４つの集約されたチャネルのうちの１つではないバックアップチャネルとを含むことができるということが前提とされる。全てのＷＴＲＵは、この情報を格納することができ、情報を最新に保つことを担当することができる。
【００８３】
図１７は、失敗を示す測定レポートメッセージ１７００の一例を示す。測定レポートメッセージ１７００は、測定トークンフィールド１７０５を含むことができる。測定トークンフィールド１７０５は、０に設定されている場合には、測定レポートメッセージ１７００が、自律的な測定レポートであり、測定要求メッセージに応答したものではないということを示すことができる。測定レポートメッセージ１７００は、測定タイプフィールド１７１０、測定レポートフィールド１７１５、要素ＩＤフィールド１７２０、長さフィールド１７２５、および測定レポートモードフィールド１７３０を含むこともできる。
【００８４】
図１８は、測定レポートメッセージ１７００の測定タイプフィールド１７１０によって示されるＩＥＥＥ８０２．１１測定タイプの一例を示す。図１８に示されるように、失敗のケースにおいては、予備タイプ４というインジケーションが使用されうる。測定レポートメッセージ１７００は、いかなる測定値も報告せずにチャネルの失敗を示すだけであるため、測定レポートメッセージ１７００内の測定レポートフィールド１７１５は、ゼロに等しいことが可能である。
【００８５】
図１９は、予備の「測定タイプ４」のフォーマットを示す。図１９に示されるように、「測定タイプ４」は、８ビットフィールドとすることができ、それぞれのビットは、失敗したチャネルを表す。ビットを１に設定すると、そのビットに関連付けられる特定のチャネルが使用可能ではないということを示すことができる。例えば、図１９に示されるビット０および２を１に設定すると、プライマリーチャネルおよびターシャリーチャネルの失敗を示すことができる。全てのチャネルが失敗したケースにおいては、失敗表示メッセージを、利用可能な場合には、バックアッププライマリーチャネル上で、１に設定されている全てのビットとともに送信することができる。さもなければ、そのメッセージは、全てのチャネルの上で非常に低い変調およびコーディングレートで首尾よく送信されうる。
【００８６】
ＤＳＭエンジン内のＳＰ（sensing processor）エンティティが、ネットワーク内のノードから感知結果を収集することによってプライマリーチャネルの失敗を検知した場合には、プライマリーチャネルにおける高い干渉の存在または（ＴＶＷＳデータベースからの）プライマリーユーザの予定されたエントリが判定される。ＣＭＦ（channel management function）は、そのチャネルを断念すべきか否かを判定することができる。この判定は、既に利用可能な感知結果に基づくことができ、またはＣＭＦは、サイレント期間にわたってさらなる結果を必要とする場合がある。
【００８７】
ＷＴＲＵは、ＣＱＩ（channel quality indicator）が変動することがあるため、プライマリーチャネルが失敗したことを認識することができる。これらのＣＱＩは、指定されたしきい値よりも上／下のレベルへと増大／低減させることによって、再送信の回数、エネルギーレベル、ＲＳＳＩ（received signal strength indication）、再送信、スループットなどに基づくことができる。ＷＴＲＵは、チャネルにアクセスする連続した試みが失敗したこと（例えば、ＣＳＭＡが所定の回数失敗したこと）、およびＷＴＲＵが周期的なメッセージ（すなわち、ビーコン）を受信していないことに基づいて、失敗を疑うこともできる。
【００８８】
いずれのＷＴＲＵも、高い干渉を示す、チャネル品質における何らかの変化を検知した場合には、失敗表示メッセージを送信することによって、ＤＳＭシステムに失敗を示すことができる。プライマリーチャネルの品質が、ＷＴＲＵへのアクセスを不可能にするほどに劣化した場合には、ＷＴＲＵは、「バックアップリスト」ビーコンＩＥ内で指定されているようにプライマリーバックアップチャネルへ切り替えること、およびそのチャネル上でプライマリーＣＳＭＡを実行することが可能である。これによって、プライマリーチャネルプロトコルから逸脱することになるかもしれない。しかし、非プライマリーチャネル上で送信を行うと、結果として他のＷＴＲＵの送信とのコリジョンが生じる可能性があるが、これは、ＤＳＭシステムと通信するための唯一の方法であり、ＷＴＲＵは、失敗表示が首尾よく送信されるまで、再送信を行うことができる。
【００８９】
図２０は、ＤＳＭシステム２００５のＣＭＦが、失敗したチャネルに取って代わるための他の利用可能なチャネルを既に有していた第１のシナリオの流れ図を示す。ＤＳＭシステム２００５は、ＣＭＦ２０１０およびＡＰ２０１５を含むことができる。ＷＴＲＵ２０２０は、ＤＳＭシステム２００５と通信する。ＡＰ２０１５は、ＷＴＲＵ２０２０から失敗表示メッセージ２０２５を受信した場合には、このメッセージをＢＡ（bandwidth allocation）再構成要求２０３０としてＣＭＦ２０１０へ転送することができる。ＣＭＦ２０１０は、自身が、失敗したチャネルに取って代わるための他の利用可能なチャネルを既に有しているかどうかに応じて、この要求に応答することができる（２０３５）。ＣＭＦ２０１０が、新たなチャネルを示すＢＡ再構成応答２０４０を送信した場合には、ＡＰ２０１５は、自分のチャネルリストを更新し（２０４５）、およびＣＳＡメッセージ２０５０をＷＴＲＵへ送信することができる。ＷＴＲＵ２０２０は、４つのチャネル全ての上で動作することができる（２０５５）。プライマリーチャネルの失敗のケースにおいては、新たなプライマリーチャネルは、上述のように「バックアップリスト」情報要素内の第１の利用可能なチャネルとすることができる。
【００９０】
図２１は、ＤＳＭシステムのＣＭＦが、失敗したチャネルに取って代わるための利用可能なチャネルを有していない第２のシナリオの流れ図を示す。ＡＰ２０１５は、ＷＴＲＵ２０２０から失敗表示メッセージ２０２５を受信した場合には、このメッセージをＢＡ再構成要求２０３０としてＣＭＦ２０１０へ転送することができる。ＣＭＦ２０１０は、利用可能なチャネルをまったく有していない場合には（２１５０）、ＡＰ２０１５が現在のチャネルから「退避する」（すなわち、現在のチャネルを断念する）ことができることを示すＢＡ再構成応答を用いてすぐに応答することができ（２１５５）、その一方で、ＣＭＦ２０１０は、新たな利用可能なチャネルを探す。ＡＰ２０１５は、このメッセージを、ＷＴＲＵ２０２０が残りのチャネル上で動作することができることを示すＣＳＡメッセージ２１６０としてＷＴＲＵ２０２０へ転送することができる（２１６５）。プライマリーチャネルの失敗が生じた場合には、新たなプライマリーチャネルを「バックアップリスト」ＩＥから選ぶことができる。ＣＭＦ２０１０は、新たなチャネルを見つけた場合には（２１７０）、別のＢＡ再構成応答２１７５を新たなチャネルでＡＰ２０１５へ送信することができ、この別のＢＡ再構成応答２１７５は、別のＣＳＡメッセージ２１８０としてＷＴＲＵ２０２０へ転送され、ＷＴＲＵ２０２０は、ＣＳＡメッセージ２１８０内で指定されるように４つのチャネル全ての上で動作できるようになる（２１８５）。
【００９１】
加えて、プライマリーチャネルの失敗に関するチャネルタイムラインが、図２２に示されており、非プライマリーチャネルの失敗に関するチャネルタイムラインが、図２３に示されている。プライマリーチャネルの失敗のケースでは、新たなプライマリーチャネルが、図２２に示されるように「バックアップリスト」ＩＥから選択される（図２２では、セカンダリーチャネルが、新たなプライマリーチャネルになっている）。非プライマリーチャネル上でチャネルの失敗が生じた場合には、プライマリーＣＳＭＡは、図２３に示されるように、失敗が生じる前と同じプライマリーチャネルを引き続き使用する。
【００９２】
プライマリーＣＳＭＡアプローチのコンテキストにおいては、ＨＰ（high priority）制御メッセージが配信されうる。制御メッセージおよびデータは、同じチャネルにおいて送信される場合があり、そのため互いに競合する場合がある。したがって、高い堅牢性および最小限の遅延で制御メッセージを配信することが望ましい。参考のために、ＩＥＥＥ８０２．１１ｎにおいては提供されない様々なタイプの制御メッセージ、およびそれらの優先度が、図２４に提示されている。高優先度制御メッセージは、ビーコン（すなわち、ＷＴＲＵからＤＳＭシステムへの感知レポート）を伴う／伴わない周期的な配信、およびイベントトリガー（すなわち、ＣＳＡメッセージ）による独立した送信によって送信されることができる。
【００９３】
コリジョンを回避するために、いくつかの高優先度制御メッセージ（すなわち、周期的感知結果、直近のチャネルバックアップ）は、４つのチャネルにおいて周期的に配信されるビーコン情報内にアタッチされうる。しかし、高優先度制御メッセージの堅牢性を高めるために、このタイプの制御メッセージは、４つの物理チャネルにおいて、（図２４に示されるような）４つのセグメント化されたビーコンの予備フィールド内に繰り返し埋め込まれる。ビーコン時間の直前に何らかのイベントが発生した場合には、関連メッセージがビーコンメッセージ内に埋め込まれうる。例えば、チャネルの切り替えが行われる場合には、そのアナウンスメントがビーコン内に含めて送信されうる。
【００９４】
何らかの緊急事態（すなわち、チャネルの失敗、チャネルの切り替え、輻輳レポートなど）が生じており、また、次なるビーコンがすぐには到来しない可能性がある（すなわち、直近のビーコン送信とイベントとの間における間隔が、新たに定義されたパラメータであるｄｏｃ１１ＭｉｎＧａｐよりも大きい）か、または、制御メッセージを配信する送信側デバイスがＡＰではない場合には、そのメッセージはＡＰまたはＷＴＲＵによって最小限の遅延で配信される必要がある。これらのタイプのメッセージのうちの全ては、堅牢な変調モードおよびコーディングレート（すなわち、最も低い変調モードおよびコーディングレート）で配信されることができる。
【００９５】
４つのＡＣ（access category）が、ＩＥＥＥ８０２．１１において定義されている。図２４に示されるように、ＷＴＲＵは、最も高いＡＣを有するメッセージをＡＣバッファのフロントエンド内に置くための通知をバッファコントローラへ送信することができる。このタイプの制御メッセージは、データフレームとして配信されうる。例えば、ＷＴＲＵからＡＰへの輻輳レポートまたはチャネル失敗レポートは、測定要求のフレームフォーマットを有することができる。
【００９６】
集約されたチャネルの実施態様においては、図２５に示されるように、チャネル番号フィールド２５０５と、測定開始時間フィールド２５１０と、測定デュレーションフィールド２５１５とを含む測定要求メッセージ２５００を使用することができる。チャネル番号フィールド２５０５において使用されるビットの数は、２ビットまで減らされうる。例えば、セカンダリーチャネルにおいて輻輳または高い干渉があるのではないかとＷＴＲＵが疑っている場合には、チャネル番号フィールド２５０５は、０１として示されうる。
【００９７】
図２６は、図２５のＩＥＥＥ８０２．１１測定要求メッセージ２５００内のチャネル番号フィールド２５０５の一例を示す。より低いＡＣ内に埋め込まれていて、ＷＴＲＵによって送信された高優先度制御メッセージがチャネルアクセスを勝ち取らない場合には、そのチャネルアクセスを勝ち取るのは、同じ送信機からの他のＡＣである。（ＭＰＤＵとしてパックされる）このタイプの制御メッセージを、コンテンションに勝つそのＡＣのバッファ内に加えることができる。この制御メッセージは、高優先度メッセージがチャネルアクセスを勝ち取らないケースにおいては、他のメッセージとともに配信されうる。
【００９８】
ＡＰによって配信される高優先度メッセージは、よりシステマチックであることが可能である（すなわち、ＣＳＡメッセージなら、遅延を伴わずに配信する上で、より良好であろう）ため、このタイプのメッセージは、バックオフ、および最も堅牢なＭＣＳ（modulation and coding scheme）セット（すなわち、最も低い変調モードおよびコーディングレート）を伴わずに送信されうる。プライマリーチャネルがＡＩＦＳの間にアイドルであり、非プライマリーチャネルがＰＩＦＳの間にアイドルである限り、ＷＴＲＵは、バックオフを実行せずに、すぐにこの制御メッセージを送信することができる。このタイプの送信に関するＡＩＦＳも、減らすことができる。例えば、（ＡＣＩ（adjacent channel interference）／ＡＩＦＳＮフィールドにおいて）ＡＩＦＳＮ＝１であり、これは、ＡＩＦＳの合計値＝１スロット時間＋ＳＩＦＳであることを示している。図２７に示されるように、堅牢性を高めるために、このタイプの制御メッセージは、４つの物理チャネルの上で繰り返されることができる。
【００９９】
ライセンス供与されていない帯域またはライセンス供与されている帯域（例えば、ＴＶＷＳ）において利用可能な複数のチャネルが存在する場合には、これらのチャネル上でＭＡＣ層アグリゲーションを実行することは、これらの利用可能なチャネルを活用するための効果的なソリューションを提供することができる。複数のチャネルを使用することは、より多くのデータが送信され、それによってシステムスループットが高まることを可能にすることができる。
【０１００】
図２８は、ＭＡＣ層アグリゲーションユニット２８００の一例を示す。図２８に示されるように、集約されたデータストリーム２８０５が、複数の利用可能なＭＡＣ層２８１０、および集約された物理チャネル２８１５に分割されることができ、これらのチャネル上で独立して送信されることができる。したがって、ＭＡＣ層アグリゲーションは、ＭＡＣ層アグリゲーションユニット２８００が、これらのチャネル上で同時に、互いに干渉することなく、動作できることを必要とする場合がある。しかし、半二重デバイスは、別々のチャネル上であっても、送信と受信とを同時に行うことはできない。このことは、ワイヤレス通信、例えば、ＩＥＥＥ８０２．１１通信において同期化の問題をもたらす可能性があり、それによって、パケットを首尾よく受信した際に肯定ＡＣＫ（acknowledgement）が必要となる場合がある。ＩＥＥＥ８０２．１１では、肯定応答を求めるフレームを首尾よく受信した後に、ＡＣＫフレームの送信を、ＳＩＦＳ期間の後に、メディアのビジー／アイドル状態にかかわらずに開始できることが必要とされる場合がある。
【０１０１】
時間の経過に伴うチャネルの変動、および集約されたチャネル同士の別々の品質に起因して、これらのチャネル上のそれぞれの送信がまったく同じ時間に終了するのを保証することが困難になる場合がある。従って、別々のチャネル上でフレームを首尾よく受信したことによってトリガーされたＡＣＫの送信は、図２９に示されるように、受信（１つのチャネルにおいてフレームを受信すること）と、送信（他のチャネルにおいてＡＣＫを送信すること）とを同時に行う結果になる場合がある。また、それぞれのチャネル上での送信における差が大きくなればなるほど、これらのチャネルのうちの１つまたは複数の上での全体的なアイドルタイムが増えるため、これらのチャネルを使用する効率は低くなる。
【０１０２】
送信と受信とを同時に行うことは、自己干渉をもたらす可能性があるため、半二重デバイスにおいては実行不可能である場合がある。例えば、フレームの受信は、送信機からの帯域外の放射に起因して、干渉を受ける可能性がある。このことによって、集約されたチャネル上で受信機によって実行される肯定応答手順を同期化するためのアルゴリズムを使用することが必要となる場合がある。ＡＣＫ同士を同期化すると、結果として、データの送信と、ＡＣＫの送信との間におけるＳＩＦＳ期間よりも長いアイドルタイムが生じる場合がある。この問題に対処するために、それらのアルゴリズムはまた、この時間中に他のデバイスがそのチャネルにアクセスすることを防止しなければならない場合がある。
【０１０３】
上述の同期化の問題を解決するために、ＭＡＣアグリゲーションを使用した場合のチャネル送信に対して、様々なルール、例えば、集約されたチャネルにおける送信同士が同時に終了するよう強制することなどを適用することができる。しかし、１つまたは複数のチャネルにおいて失敗した送信に起因してパケットが再送信される必要があるケースにおいては、その再送信は、同期化を確実にするために実施されるルールを破ることができる。また、混合した送信（すなわち、初回の送信および再送信）に関するコンテンションウィンドウが、単一チャネルの送信においては、例えば、ＩＥＥＥ８０２．１１においては対処する必要のない別の問題かもしれない。従って、ＭＡＣ再送信ソリューションは、同期化の基準を満たすことができるようにＭＡＣ層アグリゲーションにおける再送信のために使用されることができる。
【０１０４】
以降の説明では、不連続なスペクトル上で動作する４つの物理チャネルが使用されていると想定する。しかし、以降で説明するアルゴリズムは、任意の数の物理チャネル上でのＭＡＣ層アグリゲーションに適用されうるということが分かるであろう。ＭＡＣ層アグリゲーションのためにプライマリーＣＳＭＡが実施されていると想定することもできる。
【０１０５】
集約されたチャネル上で肯定応答の送信同士を同期化するために、プライマリーチャネル最終終了手順（primary channel ending last procedure）および共通仮想感知手順（common virtual sensing procedure）を実施することによって、集約されたチャネル同士の間におけるコーオーディネーションを取り扱うことができる。
【０１０６】
プライマリーチャネル最終終了手順は、ＭＡＣ層アグリゲーションにおいてプライマリーＣＳＭＡを実施する。このシナリオにおいては、肯定応答の同期化を確実にするための１つのアプローチは、プライマリーチャネル上での送信が常に、最後に、またはセカンダリーチャネル上での送信とほぼ同時に終了するよう強制することかもしれない。図３０は、コリジョンを回避するためにＡＣＫの送信を同期化するための手順を示す。
【０１０７】
コリジョンを回避する目的でＡＣＫの送信を同期化するために、下記のルール、またはそれらのルールの任意の組合せを使用することができる。第１に、別々のチャネル上での送信が同時に終了することは不要とすることができるが、プライマリーチャネル上でのデータ送信は最後に終了するものとすることができる。第２に、プライマリーチャネル上でデータ／マネージメントフレームが受信される場合のＡＣＫ手順は、ＩＥＥＥ８０２．１１において使用される手順と同じとすることができる。例えば、肯定応答を求めるフレームを首尾よく受信した後に、ＡＣＫフレームの送信を、ＳＩＦＳ期間の後に、メディアのビジー／アイドル状態にかかわらずに開始することができる。第３に、データ／マネージメントフレームが、セカンダリーチャネル、ターシャリーチャネル、およびクォータナリーチャネル上で受信された場合には、ＡＣＫ手順は、肯定応答を求めるフレームを首尾よく受信した後に、ＡＣＫフレームの送信を、ＳＩＦＳ期間にわたってプライマリーチャネルがアイドルであった後に、開始することができるものとすることができる。第４に、プライマリーチャネル上で送信されたデータ／マネージメントフレームは、送信が終了してから「ＳＩＦＳ＋ＡＣＫ送信時間」内にＡＣＫがあると予期することができる。しかし、セカンダリーチャネル、ターシャリーチャネル、およびクォータナリーチャネル上で送信されたデータ／マネージメントフレームは、プライマリーチャネルが送信を終了してから「ＳＩＦＳ＋ＡＣＫ送信時間」内に各自のＡＣＫがあると予期することができる。
【０１０８】
代替として、または追加として、集約されたチャネルにおける肯定応答の送信を同期化するために、プライマリーチャネルの送信が最後に終了しなくてもよいように、全てのチャネルにおいて共通仮想感知ＮＡＶ値を使用することができる。下記の内容は、プライマリーＣＳＭＡに焦点を合わせているが、共通仮想感知は、他の任意のＣＳＭＡアルゴリズム、例えば、結合されたＣＳＭＡに関して実施することもでき、その場合には、プライマリーチャネルを定義することはできず、感知は、全ての集約されたチャネル上で実行されることができる。
【０１０９】
これは、フレームヘッダ内のデュレーションフィールドがどのように設定されるかに影響を与える場合がある。ＩＥＥＥ８０２．１１においては、メディアがアイドルであることを、物理的な搬送波感知メカニズムと、仮想の搬送波感知メカニズムとの両方が示す場合にのみ、そのメディアはアイドルであると判定されることができる。仮想の搬送波感知メカニズムは、ＮＡＶと呼ばれる場合がある。ＮＡＶは、メディアのビジーステータスのデュレーションを告知するＭＡＣヘッダのデュレーションフィールド内に含めて搬送することができる。
【０１１０】
デュレーションフィールドを設定するための現在のルールは、チャネルのコンテンションアクセスに続いてＣＡＰ（controlled access phase）外でＱｏＳ（quality of service）ＷＴＲＵによってＣＰ（contention period）において送信された全てのデータまたはマネージメントフレーム内では、デュレーション／ＩＤフィールドを下記の値のうちの１つに設定されうることを必要とする場合がある。第１に、ＱｏＳデータサブフィールドがゼロに設定されているマネージメントフレーム、およびＡＣＫポリシーサブフィールドが通常のＡＣＫに設定されているユニキャストデータフレームに関しては、そのフレームが、ＴＸＯＰ（transmission opportunity）の最後のフラグメントである場合には、１つのＡＣＫフレームの送信のために必要とされる時間（適切なＩＦＳ（interframe space）値を含む）、または、１つのＡＣＫフレームの送信のために必要とされる時間に、後続のＭＰＤＵと、必要な場合にはその応答との送信のために必要とされる時間をプラスした値（適切なＩＦＳ値を含む）。第２に、ＡＣＫポリシーサブフィールドが「ｎｏ  ＡＣＫ」または「ｂｌｏｃｋ  ＡＣＫ」に設定されているユニキャストデータフレームに関しては、およびマルチキャスト／ブロードキャストフレームに関しては、そのフレームが、ＴＸＯＰの最後のフラグメントである場合には、または、後続のＭＰＤＵと、必要な場合にはその応答フレームとの送信のために必要とされる時間（適切なＩＦＳ値を含む）である場合には、デュレーション／ＩＤフィールドをゼロに設定することができる。第３に、デュレーション／ＩＤフィールドを、そのＡＣ（access class）の保留中のＭＰＤＵと、存在する場合には、関連付けられているＡＣＫとの送信のために必要とされる時間の最小値、および適用可能なＳＩＦＳ期間、並びに、そのＡＣに関するＭＩＢ（management information base）によって課されている時間制限からＴＸＯＰ内の既に使用された時間を差し引いた値に設定することができる。
【０１１１】
ＷＴＲＵおよびコーオーディネートされていないＡＰからのコリジョンを効果的に回避するために、最長の送信が終了する時間に基づいてデュレーションフィールドの値が得られる。送信タイプ（フラグメント化されたパケット送信、継続中のＴＸＯＰか否か、など）に応じて、それぞれのデュレーションフィールドは、ＳＩＦＳ＋最長の送信を伴うチャネルに関連付けられているＡＣＫ送信時間＋差分に基づくことができる。差分は、最長の送信時間と、その特定のチャネルの送信時間との間における差とすることができる。
【０１１２】
デュレーションフィールドは、フィールド内の値が３２，７６８未満である場合には、マイクロ秒（μｓ）のデュレーションとして解釈されることができる。そうでない場合には、デュレーションフィールドは、フィールドが関連付け識別子として解釈されるべきであることを示すことができる。
【０１１３】
送信機は、いかなるフレームを送信する前にも、どのフレームが送信に最も長い時間を要することになるかを判定することができる。これは、フレームのサイズの要因であるだけでなく、それぞれのチャネル上で使用される変調およびコーディングスキームでもある場合がある。ポリシーサブフィールドが通常のＡＣＫに設定されているユニキャストデータフレームに関しては、それぞれのフレームの送信時間を計算することができる。この計算は、下記のとおり実行することができる。
packet_xmit_time=80μs+(262+size_of_data)/data_rate              方程式（１）
【０１１４】
ここでは、８０μｓは、ＰＬＣＰ（physical layer convergence protocol）ヘッダを占めており、２６２は、ＭＡＣフレームの他のフィールド内のビットの数であり、ｓｉｚｅ＿ｏｆ＿ｄａｔａは、データフィールド内に含まれることになるビットの数であり、ｄａｔａ＿ｒａｔｅは、チャネルの使用可能な送信スピードである。
【０１１５】
別々の長さまたは変調スキームを有する４つのパケットの送信に関しては、それぞれのパケットは、次のような別々のデュレーションフィールド値を有することができる：ＤＣＦ（distributed coordination function）を使用するフラグメント化されていないパケット送信、またはＨＣＦ（hybrid coordination function）ＥＤＣＡ（contention-based channel access）におけるＴＸＯＰ内の最後のパケット送信、またはＤＣＦにおける最後のフラグメント送信。最大送信時間（ＭＡＸ＿ＸＭＩＴ＿ＴＩＭＥ）を有するフレームに関しては、この値を、ＳＩＦＳ時間と、より低いＭＣＳ（modulation and coding scheme）を有するチャネル内のＡＣＫパケットの送信時間とをプラスした値に、次式のように設定することができる。
duration_field=SIFS_time+ACK_TX_TIME(pre-defined MCS)            方程式（２）
【０１１６】
その他のフレームに関しては、デュレーションフィールドは、ＳＩＦＳ時間にＡＣＫパケットの送信時間をプラスして、パケットが送信されている時間と、最大送信時間との間における送信時間の差を加えた値を含むことができる。したがって、この値は、次のとおり設定することができる。
duration_field=(MAX_XMIT_TIME-packet_xmit_time)+SIFS_time+ACK_TX_TIME(pre-defined MCS)                                                          方程式（３）
【０１１７】
ここでは、packet_xmit_timeは、パケットが送信されている時間に相当する。失敗したパケットの再送信に関しては、そのパケットの保存されているコピーにおけるデュレーションフィールドの値を、そのパケットとともに送信されているその他のパケットに合うように更新することができる。
【０１１８】
図３１は、フラグメント化されていないまたは単一のフラグメントパケット送信およびＴＸＯＰの最後の送信におけるデュレーションフィールドの例を示す。図３１は、最大送信時間（MAX_XMIT_TIME）がセカンダリーチャネル上で生じうることを示す。したがって、セカンダリーチャネルに関するデュレーションフィールドは、最も短くすることができる。デュレーションフィールドの長さは、その他のパケットに関しては異なることが可能であり、パケット送信の終わりからＡＣＫの終わりまでとすることができる。ターシャリーチャネルの送信が、上述の説明の好例かもしれない。
【０１１９】
デュレーションフィールドの値は、フラグメンテーションのケースにおける最後以外のフラグメント送信、またはＥＤＣＡにおけるＴＸＯＰ内の最後以外のパケット送信に従って求めることもできる。このケースにおいては、デュレーションフィールドは、もう１つのＳＩＦＳ時間と、追加の別の（ＳＩＦＳ時間＋ＡＣＫ時間）と、次の送信における４つのパケットのうちの最長の送信時間（NEXT_MAX_XMIT_TIME）とを含むことができる。例えば、次式のようになる。
duration_field=(MAX_XMIT_TIME-packet_xmit_time)+SIFS_time+2×(ACK_TX_TIME(pre-defined MCS)+SIFS_time)+NEXT_MAX_XMIT_TIME                          方程式（４）
【０１２０】
ここでは、packet_xmit_timeは、そのチャネルにおいて現在のパケットが送信されている送信時間に相当することができ、MAX_XMIT_TIMEは、４つの物理チャネルのうちの最長の送信を表すことができ、NEXT_MAX_XMIT_TIMEは、４つの物理チャネルのうちの次の送信のために必要とされる最長の時間に相当することができる。図３２は、フラグメント化されたパケット送信またはＴＸＯＰの最後以外の送信におけるデュレーションフィールドの例を示す。MAX_XMIT_TIMEおよびNEXT_MAX_XMIT_TIMEは、別々のチャネル内に存在しうる。
【０１２１】
受信機の受信局ロジック（receiving station logic）は、送信機によって使用される共通仮想感知技術によって影響を受ける場合もある。対処すべき重要なケースは、受信機が、１つのチャネル上で１つのパケット全体を受信し終わっても、他のチャネル上で引き続きビジーである場合かもしれない。このケースにおいては、受信機は、全てのさらなるパケット送信が他のチャネル上で終了するのを待つか否か、または、それらの他の送信を断念する前にどれぐらい長く待つかを決めることができる。デュレーションフィールドと、PHY-RXSTART.インジケーションとを組み合わせて使用することは、他のチャネル上での受信をいつやめるかを決める上で役立つことができる。
【０１２２】
RXSTART.インジケーションは、有効なスタートフレームデリミタおよびＰＬＣＰヘッダをＭＡＣが受信していることをＭＡＣに通知するためにＰＨＹ（physical layer）によって提供されることができる。ＭＡＣは、自分がそれぞれのチャネル上でこのインジケーションを受信した時間を記録して、それらの時間を、自分がプライマリーチャネル上でこのインジケーションを受信した時間と比較することによって、これを使用することができる場合がある。これらが、他のチャネル同士に関して同時に生じた場合には、ＭＡＣは、それらが干渉ではないこと、および、ＳＩＦＳ期間を開始する前にそれらが完了するのを待つべきであることを知ることができる。さもなければ、このインジケーションが、他のチャネル上で同時に受信されない場合には、ＭＡＣは、このチャネル上での送信が完了するのを待たなくてもよい。このインジケーションが受信された後に干渉されるようになるパケットを待つことを防止するために、タイムアウトを初期設定することができる。これは、最も低いＭＣＳ上での最長の可能なＭＡＣデータフレームの送信時間に設定することができる。このタイムアウトは、第１のパケットが首尾よく受信されると、キャンセルまたは変更することができる。
【０１２３】
送信セットのうちの第１のパケットが受信されると、ＷＴＲＵは、フレームヘッダからデュレーションフィールドを抽出することができる。この値は、ゼロ（ブロードキャストパケット用）またはＳＩＦＳの最小値、およびＡＣＫパケットの送信時間を含むことができる。受信されたフレームがＡＣＫを必要とし、デュレーションフィールドが、ＳＩＦＳ時間＋ＡＣＫ送信時間に設定されている場合には、ＳＩＦＳ期間は、すぐに開始することができる。これは、受信されたフレームが、送信された最長のフレームであったこと、または他のフレームの送信も現時点で終了したことに起因して生じる場合がある。受信機は、ＳＩＦＳがいつ開始することになるかが正確に分かるようになったため、RXSTART.インジケーションに起因して設定されたタイムアウトは、キャンセルすることができる。
【０１２４】
そうでない場合には、時間の量は、送信機が現在、継続中のＴＸＯＰ内にあるか否かに応じて、２つのことのうちの１つを表すことができる。第１に、送信機が現在、継続中のＴＸＯＰ内にない場合、例えば、それがＴＸＯＰ内の最後のパケットである場合には、デュレーションフィールドは、最長の継続中の送信内に残っている時間と、ＳＩＦＳおよびＡＣＫパケットの送信時間とをプラスした値を表すことができる。第２に、ＴＸＯＰが継続されることになる場合（ＴＸＯＰ内の最初のまたは真ん中のパケットの場合）には、デュレーションフィールドは、少なくとも、上述のような時間の量と、別のＳＩＦＳと、パケットのうちの次のセットにおける最長の送信時間と、別の（ＳＩＦＳ＋ＡＣＫのために必要とされる送信時間）とをプラスした合計とすることができる。
【０１２５】
デュレーションフィールドが、ＳＩＦＳ＋ＡＣＫ送信時間＋ＳＩＦＳ＋ＰＬＣＰヘッダ未満である場合には、送信機は、ＴＸＯＰを継続していない可能性がある。したがって、受信機は、受信されたパケットの終わりのｔマイクロ秒（μｓ）後にＳＩＦＳ期間が開始するようにスケジュールすることができる。
t=duration_field-SIFS_time-ACK_TX_TIME                            方程式（５）
【０１２６】
ＷＴＲＵは、この時点で、自分の受信機が他のチャネル上で依然としてビジーであるかどうかにかかわらずに、自分のＳＩＦＳバックオフ期間を開始することができる。これは、これらの他のチャネルが干渉を経験しているであろうことに起因する場合がある。図３３は、継続中のＴＸＯＰを継続中でないＴＸＯＰから区別するデュレーションフィールドの例の図を示す。
【０１２７】
デュレーションフィールドが、時間のその量以上である場合には、ＴＸＯＰは、継続する可能性があり、RXSTART.インジケーションの時間に設定されたタイムアウトは、受信パケットの終わりのｔマイクロ秒（μｓ）後に調整することができる。受信機は、プライマリーチャネルと同じ時点でRXSTART.インジケーションを受信したチャネル上でパケットが完了するのを待つことができる。
【０１２８】
図３４は、例示的なＤＳＭ（dynamic spectrum management）システム３４００を示しており、ＤＳＭシステム３４００は、家庭または小規模オフィスなどの局所的なエリアにおいて動作することができる。ＤＳＭシステム３４００は、ＤＳＭエンジン３４０５と、複数のＤＳＭクライアント３４１０とを含むことができる。
【０１２９】
ＤＳＭエンジン３４０５は、２．４ＧＨｚおよび５ＧＨｚのＩＳＭ帯域、ＴＶＷＳ帯域、並びに６０ＧＨｚ帯域など、ライセンス供与されていないまたはオポチュニスティックな帯域において動作する局所的なエリアにおいて行われるワイヤレス通信を管理することができる。ＤＳＭエンジン３４０５は、ライセンス供与されている帯域およびライセンス供与されていない帯域にわたって帯域幅を集約することもできる。図３４に示されるように、ＤＳＭエンジン３４０５は、ＷＷＡＮ（wireless wide area network）または有線リンクを通じて、ＤＳＭクライアント（すなわち、ＷＴＲＵ）３４１０に、並びに、セルラーコアネットワーク３４１５、ＴＶＷＳデータベース３４２０、およびＩＰネットワーク３４２５などの外部ネットワークに相互接続することができる。
【０１３０】
ＤＳＭエンジン３４０５は、ＴＶＷＳデータベースへのアクセスを有することができ、ジオロケーション動作を有することができるため、ＴＶＷＳ帯域においてモードＩＩデバイスとして動作することができる。ＤＳＭエンジン３４０５は、感知専用モードで動作することもでき、それによって、ＤＳＭシステム３４００は、ＴＶＷＳデータベース３４２０が許可することができるよりも大きなチャネルサブセットにおいて動作できるようになることが可能である。
【０１３１】
ＤＳＭクライアント３４１０は、直接ＤＳＭエンジン３４０５と通信リンクを確立することができるコグニティブ無線対応クライアントデバイスとすることができる。ＤＳＭエンジン３４０５と、ＤＳＭクライアント３４１０との間における通信リンクは、ＤＳＭリンク３４３０と呼ばれ、拡張制御プレーンおよびユーザプレーン動作を提供することができる。ＤＳＭリンク３４３０は、不連続なスペクトルを介して動作することができる拡張ＩＥＥＥ８０２．１１ＲＡＴ（radio access technology）に基づくことができる。
【０１３２】
ＤＳＭリンク３４３０は、ＬＴＥなどの他のＲＡＴに基づくこともできる。ＤＳＭクライアント３４１０は、ＴＶＷＳデータベース３４２０へのアクセスを有することができず、どのチャネルを使用することができるかを示すのにＤＳＭエンジン３４０５に依存することができる。ＤＳＭクライアント３４１０は、感知専用モードで動作することもできる。感知専用モードにおいては、ＤＳＭクライアント３４１０は、ＤＳＭエンジン３４０５によって感知専用モードチャネルとして識別されたチャネルをプライマリーユーザが占有していないことを周期的に確認して、これらのチャネルにおける送信を可能にすることができる。ＤＳＭエンジン３４０５は、ＤＳＭクライアント３４１０においてこれらのチャネル上での適切なスペクトル感知を可能にするためにサイレント期間をスケジュールすることができる。感知専用動作を有するＤＳＭクライアント３４１０は、モードＩデバイスとしてチャネルのサブセット上で動作することができる。プライマリーユーザ検知のための手順は、感知専用チャネルとして識別されたチャネル上で実施することが必要になる場合がある。ＤＳＭクライアント３４１０同士は、ダイレクトリンク３４３５を通じて互いに直接通信することができる。ダイレクトリンク３４３５のために使用される無線リソースおよびＲＡＴ（radio access technology）は、ＤＳＭエンジン３４０５によって制御することができる。
【０１３３】
図３５は、ＤＳＭエンジン３４０５の例示的なアーキテクチャを示す。ＤＳＭエンジン３４０５は、ＣＭＦ（channel management function）３５０５、ＭＮＣ（multi-network connection）サーバ３５１０、ＤＳＭポリシーエンジン３５１５、ＡＰ機能３５２０、ＳＰ（sensing processor）３５２５、集中型ＷＴＲＵデータベース３５３０、およびＨＮＢ（home Node-B）機能３５３５を含むことができる。
【０１３４】
ＣＭＦ３５０５は、中央のリソースコントローラであり、無線リソースを管理すること、並びに、それらの無線リソースをＷＴＲＵおよびＡＰのそれぞれに効率よく割り当てることを担当することができる。
【０１３５】
ＡＰ機能３５２０は、ネットワークに加わるＷＴＲＵ（すなわち、ＤＳＭクライアント）のための主要な接続機能を提供することができる。その主要な接続機能は、ＣＭＦ３５０５によって選択されたチャネルに基づいて集約を管理するコーオーディネーション機能を含むことができる。ＡＰ機能３５２０の担当は、基本的なＩＥＥＥ８０２．１１ＭＡＣ／ＰＨＹ機能（または、ＬＴＥベースのＤＳＭリンクのケースにおいては、ＬＴＥ機能）を実行すること、新たな制御チャネルスキームをサポートすること、ＣＭＦ３５０５によって判定されたチャネルの連続したおよび不連続なスペクトルの集約を実行すること、ネイバー／ノードディスカバリーおよびチャネルサウンディングをサポートすること、ＩＥＥＥ８０２．１１ベースのＤＳＭリンク３４３０に関する制御チャネルおよび共通データチャネルセットアップ手順をサポートすること、ＬＴＥベースのＤＳＭリンクに関する制御チャネルの堅牢性およびチャネル切り替え手順をサポートすること、並びに、ダイレクトリンクの構成、セットアップ、ティアダウン、およびメンテナンスをサポートすることを含むことができる。
【０１３６】
ライセンス供与されていないまたはオポチュニスティックな帯域のプライマリーユーザが、あるチャネル上で送信を開始した場合には、ＦＣＣルールによれば、図３５に示されるＤＳＭエンジン３４０５は、特定の時間内にそのチャネルを明け渡すことが必要になる場合がある。プライマリーユーザの検知は、ＳＰ（sensing processor）３５２５に依存することができる。ＳＰ３５２５は、プライマリーユーザを検知すると、ＤＳＭエンジン３４０５内のＣＭＦ３５０５に知らせることができる。
【０１３７】
ＤＳＭエンジン３４０５および関連付けられているＷＴＲＵは、ＰＣＳＭＡを使用してコンテンションを通じて、集約されたチャネルへのアクセスを得ることができる。ＷＴＲＵは、送信を行う必要がある場合は常に、チャネルの全てを使用することができ、従って、チャネルの全てが空いていることを確認することが必要となる場合がある。１つの方法は、１つのチャネルをプライマリーチャネルとして割り当てること、およびそのプライマリーチャネル上でＣＳＭＡを実行することを含む。ＷＴＲＵまたはＤＳＭエンジン３４０５は、転送すべき制御データまたは通信データを有している場合には、事前に割り当てられたプライマリーチャネル上でＣＳＭＡを実行することができる。他の３つのチャネルは、プライマリーチャネルと同じチャネルステータスを有していると想定することができる。例えば、プライマリーチャネル上でのＣＳＭＡがビジーのステータスを返した場合には、チャネルの全てがビジーであると想定することができる。ＷＴＲＵまたはＤＳＭエンジン３４０５は、プライマリーチャネルへのアクセスを得ると、プライマリーチャネルおよび非プライマリーチャネルへのアクセスを得たことになる。プライマリーチャネルへのアクセスを得るとすぐに、ＷＴＲＵまたはＤＳＭエンジン３４０５は、チャネルの全てが空いていることを確かめる上で役立つように、送信の前にＰＩＦＳ（PCF(point coordination function)inter-frame space）のＰＩＦＳ期間にわたって非プライマリーチャネルをチェックすることができる。図３６は、プライマリーチャネル上でのＣＳＭＡの一例を示す。
【０１３８】
デバイスは、別々のチャネル上であっても、送信と受信を同時に行うことはできない。したがって、受信機による肯定応答手順は、集約されたチャネルを介して、同期化された様式で行うことができる。例えば、デバイスは、所与のチャネル上で肯定応答を受信しながら別のチャネルを介して送信を行うことはできない。送信および受信のコーオーディネーションを取り扱うための２つの技術が、「プライマリーチャネル最終終了」および「共通仮想感知」である。プライマリーチャネル最終終了は、プライマリーチャネルが、最後に、またはセカンダリーチャネルを介した送信とほぼ同じ時間に終了することを確実にすることによって、肯定応答の同期化を実施することができる。共通仮想感知は、全てのチャネルにおいて共通仮想感知（ＮＡＶ値）を使用することができ、これは、プライマリーチャネルの送信が最後に終了することを不要とすることができる。
【０１３９】
ＦＣＣルールによれば、セカンダリーユーザは、プライマリーユーザがＴＶＷＳチャネル上で検知されると、そのＴＶＷＳチャネルを明け渡すよう求められる可能性がある。プライマリーユーザを検知するために、ＤＳＭエンジン３４０５は、ＴＶＷＳデータベース３４２０に問合せを行うこと、またはスペクトル感知を実行することが可能である。スペクトル感知を使用してプライマリーユーザを検知するために、ＡＰおよびその関連付けられているＷＴＲＵは、特定の時間においてサイレントであることが必要となる場合がある。サイレント期間のデュレーションおよび頻度は、ＦＣＣルールに準拠しつつもスペクトル感知アルゴリズムに依存することができる。ＦＣＣルールによれば、インサービスモニタリングは、６０秒未満であることが必要とされる場合がある。また、サイレント期間情報は、ＡＰに関連付けられているＷＴＲＵのうちの全てにブロードキャストすることができる。したがって、ＩＥＥＥ８０２．１１ＭＡＣ層アーキテクチャ（または、ＤＳＭシステムのためのＬＴＥ  ＲＡＴのケースにおいては、ＬＴＥアーキテクチャ）は、サイレント期間、サイレント期間の判定、およびＡＰとＷＴＲＵとの間におけるサイレント期間の同期化の最中には送信を停止することをサポートするように調整することができる。
【０１４０】
セカンダリーユーザとして動作しているＩＥＥＥ８０２．１１  ＡＰまたはＷＴＲＵは、プライマリーユーザの存在に応じて、動作チャネルを切り替えることができる。ＷＴＲＵを新たな動作チャネルへ導くために、ＡＰは、チャネル再割り当て情報をＷＴＲＵへブロードキャストすることができる。この情報は、高い優先度を有することができ、その送信は、通常のデータ送信に影響を与えることができる。したがって、ＩＥＥＥ８０２．１１ＭＡＣ層アーキテクチャは、チャネル再割り当て情報の送信を組み込むように修正することができる。
【０１４１】
典型的なチャネル帯域幅は、６ＭＨｚとすることができ、典型的なＷｉＦｉチャネル帯域幅は、２０ＭＨｚとすることができる。したがって、チャネル同士は、ＷｉＦｉチャネルの帯域幅をサポートするように集約することができる。ＡＰまたはＷＴＲＵは、複数の連続したまたは不連続な並列のＰＨＹチャネル上で動作することができる。したがって、ＩＥＥＥ８０２．１１ＭＡＣ層アーキテクチャは、これらのＰＨＹチャネルにわたるフレームの分配をサポートするように修正することができる。そのようなフレームの分配は、ＰＨＹチャネルの信頼性の欠如に起因して動的であることが可能である。例えば、チャネルのうちの１つが、プライマリーユーザに起因して利用不能になった場合には、このチャネルに割り当てられているフレームは、別のチャネルに再割り当てすることができる。
【０１４２】
チャネル再割り当て情報、およびＰＨＹチャネルのうちの１つまたは複数の上でのスペクトル感知のためのサイレント期間同期化情報の送信は、フレームの並べ替えにつながる場合がある。その結果として、これらのチャネルに割り当てられているフレームは、他のチャネルに再割り当てすることができる。
【０１４３】
帯域外の放射に起因して、ＡＰまたはＷＴＲＵは、別々のチャネル上で送信と受信とを同時に行うべきではない。なぜなら、自己混雑に陥る（self-jam）可能性があるためである。具体的には、ＡＰまたはＷＴＲＵが、１つのＴＶＷＳチャネル上で送信を行い、その一方で、別のＴＶＷＳチャネル上で受信を行った場合には、送信された信号が、後者のチャネルにおいて受信される可能性があり、それによって、受信エラーが生じる可能性がある。全てのチャネルを効率よく使用するために、ＡＰまたはＷＴＲＵは、それらのチャネルにわたって送信デュレーションを同期化することができる。したがって、１つのソリューションは、同時に開始する送信が、やはり同時に、またはほぼ同時に終了することができるように送信をアレンジすることかもしれない。この目的を達成するために、別々のＰＨＹチャネル上で送信されることになるフレーム同士は、無線送信のデュレーションがほぼ同じになるように適切にサイズ設定することができる。ＭＣＳ（modulation and coding scheme）は、別々の状況を経験しているＰＨＹチャネルごとに異なるものとすることができる。したがって、別々のチャネル上で送信されることになるフレーム同士は、別々のサイズを有することができる。より良好なチャネル上で送信されることになるフレームは、より大きなサイズにすることができ、より劣悪なチャネル上で送信されることになるフレームは、より小さなサイズにすることができる。所望の長さのフレームを生成するために、ＩＥＥＥ８０２．１１ＭＡＣを修正することが必要となる場合がある。
【０１４４】
図３７Ａおよび図３７Ｂは、ＱｏＳをサポートする例示的なＭＡＣ層アーキテクチャ３７００を示す。ＣＭＦ３５０５を除いて、ＭＡＣ層アーキテクチャ３７００は、ＤＳＭエンジン３４０５のＡＰ機能３５２０内に組み込むことができる。図３７Ａに示されるように、例示的なＭＡＣ層アーキテクチャ３７００は、搬送波集約機能とともに、通常のＭＡＣ層アーキテクチャを、ライセンス供与されていないまたはオポチュニスティックな帯域上でのＩＥＥＥ８０２．１１オペレーションをサポートするように強化するために、バッファコントローラ３７１０と、フレームコントローラ３７１５と、ＱｏＳコントローラ３７２０と、サイレント期間スケジューラ３７２５と、チャネルモニタ３７３０とを含むＭＡＣ層コーディネータ３７０５を含む。
【０１４５】
図３７Ｂに示されるように、ＭＡＣ層アーキテクチャ３７００は、複数のＡＣ３７４５1〜３７４５Nのそれぞれの中に生成することができる複数のロジックバッファ３７４０1〜３７４０4を使用して、複数の並列のＰＨＹチャネル３７３５にわたってフレームを分配することができる。それぞれのロジックバッファ３７４０は、特定のＰＨＹチャネル３７３５を介して送信されることになるフレームを格納することができる。
【０１４６】
図３７Ａおよび図３７Ｂに示されるように、ＭＡＣ層アーキテクチャ３７００は、ＡＣマッピングユニット３７５５と、複数のＡ−ＭＳＤＵ（aggregated MAC service data unit）集約ユニット３７６０1〜３７６０Nと、フラグメンテーションユニット３７６５1〜３７６５Nと、ＭＰＤＵヘッダおよびＣＲＣユニット３７７０1〜３７７０Nと、複数のＡ−ＭＰＤＵ（aggregated MAC protocol data unit）集約ユニット３７７５1〜３７７５Nと、複数のＥＤＣＡＦ（enhanced distributed channel access function）３７８０1〜３７８０Nと、スイッチ３７８５と、デジタルトランシーバ３７９０とをさらに含むことができる。
【０１４７】
上位層からのＭＳＤＵ（MAC service data unit）フレームが受信されると、ＭＡＣ層は、フレームのＵＰ（user priority）を検査することができる。一例においては、８つのＵＰを４つのＡＣ（access category）値にマップすることができる。それらの４つのＡＣタイプとしては、優先度の高いものから低いものへと列挙すると、ＡＣ＿ＶＯ（voice）、ＡＣ＿ＶＩ（video）、ＡＣ＿ＢＥ（best effort）およびＡＣ＿ＢＫ（background）を含むことができる。この例は、４つのＡＣタイプを含むが、その他の実施形態は、任意の数のＡＣタイプを含むことができる。マッピングは、ＡＣマッピングユニット３７５５において実行することができる。ＡＣマッピングユニット３７５５の後には、４つの分岐があり、それらの１つひとつは、それぞれのＡＣ３７４５に対応している。Ａ−ＭＳＤＵ集約ユニット３７６０は、複数のＭＳＤＵフレームを集約して、ＭＡＣ層のオーバーヘッドを減らし、ひいては、データスループットを高めることができる。それぞれのＡ−ＭＳＤＵ（aggregated MSDU）フレームは、シーケンス番号を割り当てられることが可能であり、インテグリティー保護を有することができる。次いで、ＭＳＤＵフレームは、フラグメンテーションユニット３７６５によってフラグメント化することができる。フラグメンテーションは、Ａ−ＭＳＤＵフレーム上では実行することができない。
【０１４８】
次に、フラグメント化されたフレームは、ロジックバッファ３７４０内に保存することができ、それによって、メディアリソースのコンテンションをトリガーすることができる。コンテンションは、ＥＤＣＡＦ３７８０によって実行することができる。それぞれのＡＣ３７４５は、自分自身のＥＤＣＡＦ３７８０を有することができ、これらのＥＤＣＡＦ３７８０は、別々のパラメータを適用することができ、それによって、より高い優先度のＡＣ３７４５に関連付けられているＥＤＣＡＦ３７８０は、より高い可能性でコンテンションに勝つことができる。ＥＤＣＡＦ３７８０は、メディアリソースを得ると、自分のバッファ内のフレームを送信することを開始することができる。ＭＰＤＵヘッダおよびＣＲＣユニット３７７０を使用して、ＭＰＤＵヘッダおよびＣＲＣ（cyclic redundancy check）を、セグメント化されたフレームに付加することによって、ＭＰＤＵを構築することができる。複数のＭＰＤＵを集約して単一のＡ−ＭＰＤＵフレームにして、ＰＨＹ層へ送信することもできる。
【０１４９】
フレームコントローラ３７１５は、Ａ−ＭＳＤＵ集約ユニット３７６０、フラグメンテーションユニット３７６５、およびＡ−ＭＰＤＵ集約ユニット３７７５を制御するように構成することができ、それによって、それぞれのＡ−ＭＰＤＵ出力は、特定のＰＨＹチャネル３７３５上で送信するように設計することができ、それぞれのＰＨＹチャネル３７３５を介したＡ−ＭＰＤＵの送信デュレーションは、ほぼ同じとすることができる。
【０１５０】
フレームコントローラ３７１５は、はじめに４つのＰＨＹチャネル３７３５全てに関するＭＣＳ情報を受信することができる。次いでフレームコントローラ３７１５は、４つのＰＨＹチャネル３７３５のＭＣＳ値に基づいて無線デュレーションを事前に指定することができる。次いでフレームコントローラ３７１５は、同様の無線デュレーションを有するためにそれぞれのＰＨＹチャネル３７３５用に設計されたＡ−ＭＰＤＵを生成するように、Ａ−ＭＳＤＵ集約ユニット３７６０、フラグメンテーションユニット３７６５、およびＡ−ＭＰＤＵ集約ユニット３７７５を制御することができる。フレームコントローラ３７１５は、任意のＰＨＹチャネル３７３５のためのフレームの生成レートを制御することもできる。このオペレーションは、バッファバランスを、次いで４つのＰＨＹチャネル３７３５の間におけるロードバランスを確かなものにすることができる。はじめに、フレームコントローラ３７１５は、全てのＰＨＹチャネル３７３５のための等しい生成レートをラウンドロビン様式で適用することができる。バッファコントローラ３７１０からバッファステータス情報を受信すると、フレームコントローラ３７１５は、それに応じて、自分のフレーム生成スタイルを調整することができる。
【０１５１】
ロジックバッファ３７４０の生成およびメンテナンスは、バッファコントローラ３７１０によって実行することができる。ＰＨＹチャネル３７３５を効率よく使用するために、バッファコントローラ３７１０は、ロジックバッファ３７４０同士の間においてフレームの分散および並べ替えを行って、ロジックバッファ３７４０のバランスを取ることができる。
【０１５２】
帯域外の放射は、１つのＰＨＹチャネル上で送信を行いながら同じＷＴＲＵ上の別のＰＨＹチャネル上で受信を行うことを防止することができる。その結果として、一実施形態においては、これらのチャネル上での送信は、ほぼ同じ時間に開始および終了する。これは、チャネル状況に従ってフレームサイズを調整することによって、達成することができる。例えば、より良好なチャネルを介して送信されることになるフレームは、より劣悪なチャネルを介して送信されることになるフレームよりも大きくすることができる。フレームサイズの正確な計算は、図３７のＭＡＣ層アーキテクチャ３７００内のフレームコントローラ３７１５によって実行することができる。フレームコントローラ３７１５は、所望のサイズを有するフレームを生成するように、Ａ−ＭＳＤＵ集約ユニット３７６０、Ａ−ＭＰＤＵ集約ユニット３７７５、およびフラグメンテーションユニット３７６５を制御することができる。
【０１５３】
セカンダリーユーザは、チャネル上でのプライマリーユーザの検知に続いて、そのチャネル上での送信をやめることが必要となる場合がある。プライマリーユーザを検知するための１つの方法は、スペクトル感知を経ることである。スペクトル感知の一実施態様は、全てのセカンダリーユーザが感知デュレーションにわたってサイレントであることを必要とする場合がある。サイレント期間スケジューラブロックは、サイレント期間の頻度およびデュレーションを決定すること、およびそのサイレント期間の決定を、関連付けられているＷＴＲＵの全てとの間で同期化することが可能である。
【０１５４】
あるいは、ＡＰまたはＷＴＲＵは、チャネル状況または送信状況が特定のしきい値未満に劣化したことを観測したときに、プライマリーユーザの検知をトリガーすることができる。これは、イベントによってトリガーされたプライマリーユーザの検知と呼ばれる。ＡＰまたはＷＴＲＵは、図３７のＭＡＣ層アーキテクチャ３７００内のＣＭＦ（channel management function）３５０５への報告を行うことを必要とする場合がある。チャネルモニタ３７３０は、それぞれのチャネル上でＭＣＳ情報などのＰＨＹチャネル情報を収集することができる。チャネルモニタ３７３０は、そのような情報をバッファコントローラ３７１０またはフレームコントローラ３７１５に提供することができる。チャネルモニタ３７３０は、ロジックバッファ３７４０内のフレームフローに基づいてチャネルレポートをバッファコントローラ３７１０からＣＭＦ３５０５へ転送すること、およびチャネル更新情報をＣＭＦ３５０５からバッファコントローラ３７１０へ転送することも可能である。ＣＭＦ３５０５は、プライマリーユーザに伴って、チャネルに対応するバッファを空にするようバッファコントローラ３７１０に知らせることもできる。
【０１５５】
ＭＡＣデータプレーンアーキテクチャにおいては、４つのＡＣバッファ３７４５が存在すること（すなわち、Ｎ＝４であること）が可能であり、それぞれのＡＣ３７４５ごとに、そのカテゴリーのフレームが首尾よく配信される前に（すなわち、そのフレーム送信に関するＡＣＫを受信することができる前に）それらのフレームを格納しておくためのロジックバッファ３７４０が１つ存在することが可能である。また、それぞれのＡＣは、メディアリソースコンテンションのためのバックオフ手順を保持するために、自分自身のＥＤＣＡＦ３７８０に関連付けられることが可能である。コンテンションに成功すると、ＡＣのＥＤＣＡＦ３７８０には、このカテゴリーのフレームの送信のためのＥＤＣＡ  ＴＸＯＰ（transmission opportunity）を許可することができる。別々のＡＣに関するコンテンションウィンドウサイズおよび最大ＴＸＯＰデュレーションは、別々のものとすることができる。これによって、より高い優先度のＡＣは、より高い可能性を伴ってメディアにアクセスすることができる。
【０１５６】
ＰＨＹチャネル３７３５が１つしかないならば、ＥＤＣＡＦ３７８０は、そのＡＣのバッファ内にもはやフレームがない場合、送信の失敗がある場合、すなわち（予期されたＡＣＫ（若しくはＢｌｏｃｋ  ＡＣＫ）フレームが受信されない場合）、または最大ＴＸＯＰデュレーションに達した場合には、ＴＸＯＰを断念して、バックオフ手順を呼び出すことができる。
【０１５７】
ＡＣ内に保留中の複数のフレームがある場合には、１つのＥＤＣＡ  ＴＸＯＰにおいて複数のフレームを送信することができる。しかし、他のＡＣ内で保留中のフレームを、このＥＤＣＡ  ＴＸＯＰにおいて送信することはできない。直前のフレーム交換シーケンスの完了後に、ＷＴＲＵは、送信のデュレーションと、そのフレームに関する任意の予期されたＡＣＫとをプラスした値が、残りのメディア占有タイマー値未満である場合には、新たなフレームの送信を開始することができる。
【０１５８】
送信の失敗がある場合には、対応するチャネルアクセス機能は、ＮＡＶ設定が期限切れになる前に回復することができる。さらに、送信の失敗に伴って、ＷＴＲＵは、事前に指定されたＮＡＶタイマーが切れる前の境目でメディアがアイドルであることを搬送波感知メカニズムが示した後に、送信を継続することができる。
【０１５９】
ＡＣに関する最大ＴＸＯＰデュレーションは、ＡＰによって決定して、ビーコンおよびプローブ応答フレームを通じてＷＴＲＵの全てにブロードキャストすることができる。
【０１６０】
４つの並列のＰＨＹチャネルを使用する場合には、送信レートは、単一のＰＨＹチャネルの送信レートの約４倍になることが可能である。４つの並列のＰＨＹチャネル内では、それらのＰＨＹチャネルの１つをプライマリーチャネルとして選択することができる。送信の前に４つのＰＨＹチャネル全てを感知する代わりに、ＷＴＲＵは、ＡＩＦＳのデュレーションと、バックオフ期間とをプラスした時間にわたってプライマリーチャネルを感知することができる。他の３つのチャネル上でのメディア感知は、ＰＩＦＳ期間のデュレーションに伴って実行することができる。プライマリーチャネルおよび他のチャネルの送信デュレーションにわたる２つの可能なスキームが、「プライマリーチャネル最終終了」および「共通仮想感知」である。前者のスキームにおいては、プライマリーチャネル上での送信は、常に最後に終了して、チャネルリソースの確保を確かなものにすることができる。後者のスキームは、チャネルリソースの確保のためにＮＡＶを適用する。
【０１６１】
ＥＤＣＡＦ３７８０は、ＥＤＣＡ  ＴＸＯＰを許可されると、複数のフレームを送信することができる。ＥＤＣＡＦ３７８０は、そのＡＣのバッファ内にもはやフレームがない場合、プライマリーＰＨＹチャネル上で送信の失敗がある場合、または最大ＴＸＯＰデュレーションに達した場合には、ＴＸＯＰを断念して、バックオフ手順を呼び出すことができる。
【０１６２】
そのＡＣのバッファ内にもはやフレームがない場合には、ＩＥＥＥ８０２．１１ｎ標準において指定されているのと同様の手順に従うことができる（すなわち、別々のＡＣからの複数のフレームを１つのＥＤＣＡ  ＴＸＯＰ内で送信することはできない）。
【０１６３】
単一のＰＨＹチャネルのケースにおいては、送信の失敗は、潜在的なコリジョンを回避するためにＴＸＯＰを終了することができる。複数のＰＨＹチャネルのケースにおいては、ＰＨＹ非プライマリーチャネル上での送信の失敗は、現在のＴＸＯＰデュレーション中にこのチャネル上での送信を終了することができる。あるいは、送信は、このＴＸＯＰデュレーション中にその他の利用可能なＰＨＹチャネル上で継続することができる。プライマリーＰＨＹチャネル上で送信の失敗が生じない限り、対応するチャネルアクセス機能は、ＮＡＶ設定が期限切れになる前に回復することができる。
【０１６４】
最大ＴＸＯＰデュレーションが同じままである場合には、それぞれのＡＣのバッファサイズは、単一のＰＨＹチャネル用のバッファのサイズのわずか１／４とすることができる。その一方で、バッファサイズを同じままにすることもでき、ただしＡＰは、最大ＴＸＯＰデュレーションを減らすことができる。
【０１６５】
図３７のＭＡＣ層アーキテクチャ３７００において示されているバッファコントローラ３７１０は、バッファの生成（すなわち、ＰＨＹチャネルのためのそれぞれのＡＣ内のバッファを生成すること）、フレームの挿入（すなわち、入力フレーム（例えば、Ａ−ＭＰＤＵフレーム）を適切なバッファへ分配すること）、フレームの削除（すなわち、フレームをバッファから削除すること）、フレームの並べ替え（すなわち、バッファ同士の間においてフレームを置き換えること、またはバッファ内の別の場所へフレームを置き換えること）、バッファのバランスを取ること（すなわち、それぞれのＡＣ内のバッファ同士の負荷が必ず均等になるようにすること）、チャネル状況を報告すること（すなわち、ＰＨＹチャネルが適切に機能していないケースを報告すること）、およびバッファの削除（すなわち、ＰＨＹチャネルが利用不能である場合にバッファを削除すること）を実施することができる。
【０１６６】
バッファコントローラ３７１０は、図３７のＭＡＣ層アーキテクチャ３７００において示されているフレームコントローラ３７１５とともに、ＰＨＹチャネル３７３５を介して送信されるフレームが要するデュレーションを必ずほぼ同じにするよう試みることができる。ＰＨＹチャネル３７３５が準静的であることを１つの前提とすることができ、これは、それぞれのチャネルのＭＣＳ値が頻繁に変わることはできないということを意味する。
【０１６７】
下記の例は全て、全てのフレームが単一の宛先へ送信されることになるケースに関するものである。しかし、図３７のＭＡＣ層アーキテクチャ３７００は、複数の宛先に適用することもできる。
【０１６８】
４つの並列のＰＨＹチャネル３７３５という前提のもとで、バッファコントローラ３７１０は、はじめにチャネルモニタ３７３０からチャネルＭＣＳ情報を受信することができる。次いで、バッファコントローラ３７１０は、それぞれのＡＣ３７４５ごとに４つのロジックバッファ３７４０を割り当てることができる。それぞれのロジックバッファ３７４０は、ＰＨＹチャネル３７３５に対応することができる。このケースにおいては、同じロジックバッファ３７４０内のフレーム同士は、同じＰＨＹチャネル３７３５上で送信されうる。それぞれのフレームごとにインジケータを使用して、どの論理バッファにフレームが割り当てられているかを示すことができる。
【０１６９】
準静的なチャネルという前提によれば、共通のバッファ内のフレーム同士は、同様の長さを有することができ、それによって、無線でのこれらのフレームのデュレーションは、同様となる。しかし、別々のＰＨＹチャネルは、別々のＭＣＳ値を有するため、１つのＡＣ内の別々のバッファからのフレーム同士は、別々の長さであることが可能である。次いで、別々のＰＨＹチャネルに対応するバッファ同士は、別々のサイズを有することができる。
【０１７０】
Ａ−ＭＰＤＵ集約ブロックの出力同士は、別々の長さのＡ−ＭＰＤＵフレームであることが可能である。それぞれのＡ−ＭＰＤＵは、特定のＰＨＹチャネルに割り当てることができる。Ａ−ＭＰＤＵの長さは、そのＡ−ＭＰＤＵがそのＡ−ＭＰＤＵの割り当てられているＰＨＹチャネルを介して送信される場合に、そのＡ−ＭＰＤＵの無線デュレーションが他のフレームとほぼ同じになることが可能であるように、設計することができる。バッファコントローラ３７１０は、フレームの長さおよびＰＨＹチャネルのＭＣＳ情報に基づいて、入力フレームを適切なバッファに割り当てることができる。フレーム同士は、その設計されたＰＨＹチャネルを介したパケットの送信が必ずほぼ同じデュレーションにわたって続くように分配することができる。例えば、フレームが長い場合には、そのフレームは、良好なチャネル状況（これは、高いＭＣＳ値を意味する）を伴うＰＨＹチャネルに対応するバッファに割り当てることができる。
【０１７１】
別の実施形態は、どのＰＨＹチャネルを介して入力フレームが送信されることになるかという情報を含んだ入力フレームを含む。フレームが送り出されてＡＣＫが受信された場合には、バッファコントローラ３７１０は、そのフレームをバッファから削除することができる。ＡＣＫが受信されない場合には、そのフレームは、再送信の最大回数に達するまで、またはフレームの有効期限が切れるまで、バッファ内に保持することができる。
【０１７２】
送信に失敗するたびに、フレームに関する再送信の回数のカウンタを１ずつ増やすことができる。１つのフレームには、２つの有効期限が存在することができる。バッファが満杯である場合には、このバッファに割り当てられるいかなる入力フレームも削除することができる。
【０１７３】
１つのＡＣ内のバッファのうちのいずれも空でない場合には、ＡＣに関連付けられているＥＤＣＡＦ３７８０が、ＥＤＣＡ  ＴＸＯＰを求めて競合することができる。これは、バックオフ手順を呼び出すことができる。ＴＸＯＰ中は、バッファ内のフレームを送信することができる。送信のＡＣＫが受信された場合には、フレームをバッファから削除することができる。ＡＣＫを必要としないマルチキャストフレームまたはブロードキャストフレームは、送信された時点で自動的にバッファから削除することができる。そうでない場合には、フレームは、再送信の最大回数に達するなど、いくつかの制約が破られるまで、再送信のためにバッファ内に保持することができる。
【０１７４】
バッファコントローラ３７１０が、１つのバッファから別のバッファへ、またはバッファ内の１つの場所から別の場所へパケットを転送することができるいくつかの状況がある。ＴＸＯＰにおいては、いくつかのバッファは空であり、その一方、他のバッファは空ではない。ＰＨＹチャネルは、プライマリーユーザまたは強い干渉の到来に起因して利用不能になる場合があり、これは、チャネルモニタ３７３０からのメッセージによってトリガーする場合がある。フレームは、そのフレームの最大の許容可能な配信時間よりも長くバッファ内に留まることができ、特定のＰＨＹチャネル上でのスケジュールされたサイレント期間は、これらのチャネルに割り当てられるフレームの送信を延期することができる。
【０１７５】
パケット転送は、同じＡＣ内のバッファ同士の間において行うことができる。プライマリーチャネル上での送信が必ず最後に終了するようにするために、ブロックＡＣＫメカニズムを適用することができる。フレーム並べ替えプロセスは、論理バッファに起因して容易に実施することができる。
【０１７６】
パケット並べ替えプロセスに関する下記の論考は、プライマリーＣＳＭＡの前提に基づいているが、通常のＣＳＭＡのケースに適用することもできる。
【０１７７】
１つのバッファがＴＸＯＰ中に空である場合には、少なくとも下記の３つのシナリオがある。
【０１７８】
（１）複数のフレームを伴うバッファがちょうど１つある場合には、バッファコントローラ３７１０は、そのバッファから空のバッファへフレームを転送することができる。
【０１７９】
（２）複数のフレームを伴う複数のバッファがある場合には、バッファコントローラ３７１０は、候補バッファのリストから１つのバッファを選択することができ、それによって、その選択されたバッファからのフレームを空のバッファへ転送することができる。バッファコントローラ３７１０は、候補バッファに対応するチャネルの状況をチェックすること、および空のバッファに対応するチャネルの状況に最も近いＭＣＳ値を有するチャネルを判定することが可能である。２つのＭＣＳ値の間における隔たりは、２つのコーディングおよび変調レートの間における差の絶対値とすることができる。例えば、ＱＰＳＫ（quadrature phase-shift keying）変調およびレート３／４チャネルのコードに関しては、全体的なレートは、２×３／４＝３／２である。２つのＭＣＳ値の近似性を判定するための代替方法は、ＭＣＳインデックス同士の間における差による方法である。このバッファ選択スキームは、別々のチャネルを介したフレーム送信同士のデュレーションがほぼ同様になることを確実にすることができる。
【０１８０】
バッファコントローラ３７１０は、適切な空のバッファを判定した後に、バッファの最前部から２番目のフレームをその空のバッファへ転送することができる。これは、そのバッファ内の第１のフレームが依然として同じチャネル上で送信されている可能性があるためである。
【０１８１】
（３）複数のフレームを伴うバッファが他にないならば、フレーム並べ替えプロセスは、空のバッファがプライマリーチャネルに対応しない場合には実行することができない。あるいは、フレームを１つのバッファから空のバッファへコピーすることができる。コピーされるフレームは、空のバッファのＭＣＳ値に最も近い対応するＭＣＳ値を有するバッファからのフレームとすることができる。このコピーオペレーションの結果、送信が繰り返される場合がある。あるいは、空のバッファがプライマリーチャネルに対応する場合には、空でないバッファからフレームを転送することができる。これによって、プライマリーチャネル上での送信を確かなものにすることができる。あるいは、バッファの有するフレームの数が特定の数を下回ると、フレームの並べ替えを開始することができる。
【０１８２】
図３８および図３９は、ＴＸＯＰ内の空のバッファに起因するパケット並べ替えの一例を示す。図３８は、ＴＸＯＰ中に、ロジックバッファ３７４０1が空であること、ロジックバッファ３７４０2が１つのフレームを含んでいること、ロジックバッファ３７４０3が３つのフレームを含んでいること、およびロジックバッファ３７４０4が４つのフレームを含んでいることを示す。さらに、ＰＨＹチャネル３７３５3は、ＰＨＹチャネル３７３５1に最も近いＭＣＳ値を有している。上述のパケット並べ替えスキームによって、バッファコントローラ３７１０は、第２のフレームをロジックバッファ３７４０3からロジックバッファ３７４０1へ転送する。このケースにおいては、４つのＰＨＹチャネル３７３５全てが利用されている。
【０１８３】
図３９は、ロジックバッファ３７４０1および３７４０2が空であること、ロジックバッファ３７４０3が１つのフレームを有していること、およびロジックバッファ３７４０4が３つのフレームを有していることを示す。上述のパケット並べ替えスキームによって、バッファコントローラ３７１０は、１つのフレームをロジックバッファ３７４０4からロジックバッファ３７４０1へ転送し、別のフレームをロジックバッファ３７４０4からロジックバッファ３７４０2へ転送する。これは、４つのＰＨＹチャネル３７３５のうちのいずれも無駄にならないことを確実にし、その一方、４つのＰＨＹチャネル３７３５上での送信同士は、別々の時間に終了することができる。
【０１８４】
バッファコントローラ３７１０は、プライマリーユーザによって使用されるチャネルに対応するバッファから別のバッファへフレームを転送することができる。宛先バッファの選択は、やはり、対応するチャネルのＭＣＳ値の近似性に依存することができる。宛先バッファが決定されると、バッファコントローラ３７１０は、失われたチャネルに対応するバッファから宛先バッファへフレームを順に転送することができる。古いバッファの最前部にあるフレームは、やはり宛先バッファの最前部にあることが可能である。転送されたフレームは、プライマリーユーザの存在に起因していくらかの遅延を既に経験している可能性があるため、これらのフレームは、宛先バッファの最前部に挿入することができる。しかし、これらのフレームを宛先バッファ内の第１のフレームの前に挿入することはできない。なぜなら、第１のフレームは再送信中である可能性があるためである。フレームのシーケンス番号またはＱｏＳ要件に応じて、それらのフレームを宛先バッファ内の適切な場所へ転送するために、さらなる手順を適用することができる。
【０１８５】
利用不能なチャネルに起因するパケット並べ替えは、バルクフレーム転送（bulk frame transfer）を含む場合がある。これは、宛先バッファにおけるオーバーフローにつながる可能性がある。このケースにおいては、バッファコントローラ３７１０は、残りのフレームを転送するために別のバッファを選択することができる。選択基準は、同じとすることができる。さらに、バッファコントローラ３７１０は、最新のバッファステータスをフレームコントローラ３７１５に知らせることができる。
【０１８６】
図４０および図４１は、利用不能なチャネルに起因するパケット並べ替えの一例を示す。この例においては、いずれかの時点で、バッファコントローラ３７１０が、チャネルモニタ３７３０からメッセージを受信し、そのメッセージは、プライマリーユーザに起因してＰＨＹチャネル３７３５2が利用不能であるという情報を含む、と想定することができる。その結果として、バッファコントローラ３７１０は、ロジックバッファ３７４０2を空にすることができる。ＭＣＳの比較の後に、バッファコントローラ３７１０は、ロジックバッファ３７４０2からロジックバッファ３７４０4へフレームを転送することを決定することができる。しかし、ロジックバッファ３７４０4は、ロジックバッファ３７４０2からのフレームの一部分を保持することしかできない。次いで、バッファコントローラ３７１０は、ロジックバッファ３７４０2からの残りのフレームを格納するためにロジックバッファ３７４０1を選択することができる。バッファコントローラ３７１０は、フレームコントローラ３７１５にバッファステータスについて知らせることもできる。
【０１８７】
ＱｏＳコントローラ３７２０からのＱｏＳ要件、またはＣＭＦ３５０５からの制御メッセージＱｏＳ要件をバッファコントローラ３７１０へ送信して、フレームの最大遅延を知らせることができる。バッファコントローラ３７１０は、全てのＡＣ３７４５におけるバッファ内のフレームをチェックして、いくつかのフレームが送信時間制限を潜在的に破る可能性があるかどうかを確認することができる。バッファコントローラ３７１０は、そのようなフレームを検知した場合には、それらのフレームをそれらのフレームの送信時間制限内に送信するために、パケット並べ替えプロセスを実行することができる。それらのフレームは、同様のＭＣＳ値に対応するバッファ同士の間において転送することができ、それらの転送されたフレームは、新たなバッファの最前部に挿入することができる。
【０１８８】
図４２および図４３は、ＱｏＳ要件に起因するパケット並べ替えの一例を示す。ＱｏＳコントローラ３７２０からＱｏＳ要件を受信すると、バッファコントローラ３７１０は、ロジックバッファ３７４０をチェックすることができる。この例においては、バッファコントローラ３７１０は、ロジックバッファ３７４０2内の２つのフレームが自分のＱｏＳ要件を満たしていない可能性があるということを検知している。次に、バッファコントローラ３７１０は、それらのフレームを別のロジックバッファ３７４０へ転送することを試みることができる。チャネル３７３５3およびチャネル３７３５2は、同様のＭＣＳ値を有しているため、バッファコントローラ３７１０は、それらの２つのフレームをロジックバッファ３７４０2からロジックバッファ３７４０3の最前部へ転送することができる。
【０１８９】
感知オペレーションは、プライマリーユーザの検知を実行することができるように、デバイスがサイレントであることを必要とする場合がある。動作チャネルのサブセットに関して、それぞれのサイレント期間がスケジュールされた場合には、それらのチャネルに割り当てられるフレームは、サイレント期間中には送信が許可されない場合があるため、遅延を経験する可能性がある。したがって、バッファコントローラ３７１０は、当初それらのチャネルに割り当てられたフレームを並べ替えることができる。詳細なフレーム並べ替えオペレーションは、利用不能なチャネルのケースと同様とすることができる。
【０１９０】
送信の前に、フレーム同士を、４つのロジックバッファ３７４０にわたって均等に分配することができる。しかし、別々のチャネルからの別々のパケット送信レートに伴って、いくつかのバッファは重くなる可能性があり、その一方で、他のバッファは軽くなる可能性がある。ＰＨＹチャネル３７３５の効率的な使用のために、バッファコントローラ３７１０は、それぞれのロジックバッファ３７４０内のフレームの数を相対的に均等に保持することができる。これは、いくつかのバッファがほとんど満杯である一方でいくつかのバッファがほとんど空であり、それに続いて、特定のチャネルを介して送信されるフレームが皆無になる可能性が生じる一方で他のチャネルを介して送信されるフレームが多くなりすぎる可能性が生じる、という状況を回避する。複数のバッファにわたってフレームを均等に分配するために、バッファコントローラ３７１０は、あるＰＨＹチャネルの対応するバッファが、より少ないフレームを有している場合には、そのＰＨＹチャネルに関するフレームをより多く生成するようフレームコントローラ３７１５に知らせることができる。バッファコントローラ３７１０は、あるＰＨＹチャネルの対応するバッファが、多くのフレームを有している場合には、そのＰＨＹチャネルに関するフレームをより少なく生成するようフレームコントローラ３７１５に知らせることもできる。
【０１９１】
ロジックバッファ３７４０が満杯であるか、または特定のしきい値を上回っている場合には、バッファコントローラ３７１０は、対応するＰＨＹチャネル３７３５上での送信用に設計されたフレームをより少なく生成するようフレームコントローラ３７１５に知らせることができる。ロジックバッファ３７４０が空であるか、または特定のしきい値を下回っている場合には、バッファコントローラ３７１０は、対応するＰＨＹチャネル３７３５上での送信用に設計されたフレームをより多く生成するようフレームコントローラ３７１５に知らせることができる。それらのしきい値は、フレーム生成レートまたはその他の要因に伴って変動することができ、また、固定することもできる。
【０１９２】
バッファコントローラ３７１０からフレームコントローラ３７１５へ送信されるメッセージは、ＡＣ  ＩＤ、チャネルＩＤ、およびフレーム生成レートの上昇または低下を示すインジケータを含むことができる。メッセージトリガーは、バッファ内のフレームの数が、しきい値よりも高くなること、または低くなることとすることができる。
【０１９３】
バッファコントローラ３７１０は、バッファステータスの観点からチャネル状況をチャネルモニタ３７３０に報告することが必要となる場合がある。そのような報告は、プライマリーユーザを早く検知する上で役立つことができる。なぜなら、チャネルレポートは、非同期式のスペクトル感知をトリガーすることができるためである。バッファコントローラ３７１０は、チャネル状況を報告すべきかどうか、およびいつ報告すべきかを判定することができる。バッファコントローラ３７１０が適用することができるいくつかの基準は、チャネル上での再送信の回数が何らかのしきい値を上回る可能性があること、チャネル上での再送信レートが何らかのしきい値を上回る可能性があること、または、チャネル上でのフレームロスレートが何らかのしきい値を上回る可能性があることである。それらのしきい値は、別々のＡＣごとに別々のものとすることができる。
【０１９４】
いずれかのＰＨＹチャネル３７３５が利用不能になっている旨のメッセージをチャネルモニタ３７３０から受信した場合には、バッファコントローラ３７１０は、対応するロジックバッファ３７４０を空にすることができる。新たなＰＨＹチャネル３７３５が利用可能になっていることを示すメッセージをチャネルモニタ３７３０から受信した場合には、バッファコントローラ３７１０は、このＰＨＹチャネル３７３５に対応するロジックバッファを生成することができる。
【０１９５】
ＱｏＳコントローラ３７２０およびＣＭＦ３５０５は、ＱｏＳ関連情報をバッファコントローラ３７１０に提供することができる。そのような情報は、関連メッセージの配信が特定の要件を満たすことを意味することができる。対応するメッセージは、フレームＩＤ、ソースアドレス、および宛先アドレスなどのフレーム情報、フレームの最大遅延、およびこのメッセージタイプのフレームの最小レートを含むことができる。
【０１９６】
サイレント期間スケジューラ３７２５は、特定の期間にわたって特定のチャネル上での送信をやめるようにバッファコントローラ３７１０に知らせることができる。このサイレント期間は、プライマリーユーザを検知するためのスペクトル感知オペレーションのためのものとすることができる。メッセージコンテンツとしては、来たるべきサイレント期間のデュレーションと、サイレントにさせるＰＨＹチャネル３７３５のリストと、サイレント期間の開始時間とを含むことができる。
【０１９７】
チャネルモニタ３７３０からバッファコントローラ３７１０への少なくとも２つのタイプのメッセージが存在することができる。第１のメッセージタイプは、チャネルＭＣＳ情報を含むことができる。具体的には、第１のメッセージは、宛先アドレスと、４つまでのチャネルＩＤおよび／またはそれらのチャネルの周波数と、それらのチャネルのＭＣＳインデックスとを含むことができる。第２のメッセージタイプは、チャネル構成情報を含むことができる。第２のメッセージは、古いチャネルＩＤと、古いチャネルの周波数レンジなどの古いチャネル定義と、新たなチャネルＩＤと、新たなチャネルの周波数レンジなどの新たなチャネル定義と、そのチャネルがプライマリーチャネルであるか否かを示すことができるプライマリーチャネルインジケータとを含むことができる。
【０１９８】
図４４は、バッファコントローラ３７１０によって実行される例示的なコールフロー手順４４００を示す。この例においては、バッファコントローラ３７１０は、はじめにＰＨＹチャネルの全てに関するＭＣＳ情報４４０５をチャネルモニタ３７３０から受信することができる。次いでバッファコントローラ３７１０は、それに従ってロジックバッファを生成することができる（４４１０）。バッファコントローラ３７１０は、フレームコントローラ３７１５からＡ−ＭＰＤＵフレーム情報４４１５出力を受信すると、フレーム長さおよびチャネルＭＣＳ情報に基づいて適切なロジックバッファへのＡ−ＭＰＤＵフレームの分配を監督する（４４２０）。コンテンションが成功すると、バッファコントローラ３７１０は、フレーム送信およびフレーム並べ替えプロセスをスケジュールする（４４２５）。バッファコントローラ３７１０はまた、バッファステータスをフレームコントローラ３７１５に知らせること（４４３０）、および、さらなるフレーム（Ａ−ＭＰＤＵ）を受信すること（４４３５）（これは、バッファのバランスを取るために意図される場合がある）が可能である。バッファコントローラ３７１０は、ＱｏＳコントローラ３７２０からのＱｏＳ情報４４４０、またはＣＭＦ３５０５からの制御メッセージＱｏＳ情報４４４５、またはサイレント期間スケジューラ３７２５からのサイレント期間情報４４５０を受信すると、それに従ってフレーム並べ替えおよびフレーム送信をスケジュールすることができる（４４５５）。バッファコントローラ３７１０は、低いスループットを経験しているいくつかのチャネルを検知した場合には、チャネルモニタ３７３０にチャネル状況を報告すること（劣悪チャネルレポート）４４６０が可能である。チャネル更新情報４４６５を受信した後に、バッファコントローラ３７１０は、フレーム並べ替えオペレーション、バッファ削除オペレーション、およびバッファ生成オペレーション（バッファの再編成）を実行することができる（４４７０）。
【０１９９】
上述のバッファリングスキームによれば、フレーム同士を、それらのフレームがＭＡＣ層において受信され処理される順に送信することはできない。これは、フレーム同士が同様の無線デュレーションを有するという設計要件を満たすためのものであると言える。図４５に示されるように、フレームが順序どおりになっていない配信の主な影響によって、受信機側における大きなバッファという結果に至る可能性がある。なぜなら、受信機は、ＭＳＤＵフラグメントを処理する前にそれらのＭＳＤＵフラグメントの全てを受信することが必要となる場合があるためである。
【０２００】
送信機側においては、フレームの再送信の最大回数に達した場合、ＭＡＣ層におけるフレームの有効期限に達した場合、または第１の送信の後にフレームの有効期限に達した場合に、そのフレームをバッファから削除することができる。同様のオペレーションを受信機側において適用することもできる。これによって、受信機側におけるバッファ要件を軽減することができる。さらに、ＱｏＳ要件に起因するフレーム並べ替えは、フレームが特定の時間内に必ず配信されるようにすることができ、受信機のバッファサイズの問題を緩和することができる。
【０２０１】
受信機のバッファサイズの問題を緩和するためのさらなるスキームは、さらなるフレーム並べ替えトリガー（frame reordering trigger）を追加することを含む。バッファ内のフレームが１つまたは複数の所定の条件を満たす場合に、フレーム並べ替えオペレーションをトリガーすることができる。様々なパラメータを調整することによって、帯域幅の効率と、受信機のバッファサイズとの間におけるトレードオフを調整することができる。
【０２０２】
ＩＥＥＥ８０２．１１ｎにおいては、ｎｏｎ−ＨＴ（high throughput）、ＨＴ−ｍｉｘｅｄ、およびＨＴ−ｇｒｅｅｎｆｉｅｌｄという３つのタイプのＰＰＤＵ（physical layer protocol data unit）フレームがある。５ＭＨｚの帯域幅およびＯＦＤＭ変調を前提とし、これは、それぞれのＯＦＤＭシンボルが１６μｓにわたって続くことを意味する。さらに、簡単にするために、３．２μｓのガード間隔を前提とする。
【０２０３】
図４６は、ＰＬＣＰヘッダ４６０２を含むｎｏｎ−ＨＴ  ＰＰＤＵデータフォーマット４６００を示す。ＰＬＣＰヘッダは、Ｌ−ＳＴＦ（legacy short training field）４６０５、Ｌ−ＬＴＦ（legacy long training field）４６１０、およびＬ−ＳＩＧ（legacy signal）フィールド４６１５を含むことができる。Ｌ−ＳＴＦ４６０５のデュレーションは、３２μｓとすることができ、１０個のショートプリアンブルを含むことができる。Ｌ−ＬＴＦ４６１０は、２つのロングプリアンブルと、１つのガード間隔とを含むことができる。Ｌ−ＬＴＦ４６１０のデュレーションも、３２μｓとすることができる。Ｌ−ＳＩＧフィールド４６１５は、レートおよびＴＸＶＥＣＴＯＲの長さフィールドを含むことができる。Ｌ−ＳＩＧフィールド４６１５のデュレーションは、１６μｓとすることができる。
【０２０４】
ｎｏｎ−ＨＴ  ＰＰＤＵデータフォーマット４６００は、データフィールド４６２０をさらに含むことができ、データフィールド４６２０は、サービスビット４６２５、ＭＰＤＵ４６３０、テールビット４６３５、およびパッドビット４６４０を含むことができる。サービスビット４６２５は、１６ビットの長さを有することができ、テールビット４６３５は、６ビットの長さを有することができる。パッドビット４６４０は、ＯＦＤＭシンボルごとに０からデータビットの数まで変わることができる。これらのパッドビット４６４０は、データフィールド全体が必ずＯＦＤＭシンボルの整数倍になるようにするために適用することができる。ＭＰＤＵ４６３０は、ＭＡＣヘッダ４６４５、ＭＳＤＵ４６５０、およびＦＣＳフィールド４６５５を含むことができる。ＭＳＤＵペイロードは、暗号化およびインテグリティーを伴わずに１８４３２ビットを超えることはできない。ＭＡＣヘッダ４６４５は、２０８ビットの長さを有することができ、ＦＣＳフィールド４６５５は、３２ビットの長さを有することができる。
【０２０５】
ＭＡＣヘッダ４６４５の一般的なフォーマットが図４７に示されている。ＭＡＣヘッダ４６４５は、長さ１６ビットのフレーム制御フィールド４７０５を含むことができ、フレーム制御フィールド４７０５は、プロトコルバージョン、タイプ、サブタイプ、ＤＳ（distribution stream）へ、ＤＳから、さらなるフラグメント、再試行、パワーマネージメント、さらなるデータ、保護されたフレーム、および順序という各サブフィールドから構成することができる。
【０２０６】
ＭＡＣヘッダ４６４５は、デュレーション／ＩＤフィールド４７１０を含むことができ、デュレーション／ＩＤフィールド４７１０は、１６ビットの長さとすることができる。そのコンテンツは、フレームのタイプおよびサブタイプに伴って、様々なものとすることができる。
【０２０７】
ＭＡＣヘッダ４６４５は、複数のアドレスフィールド４７１５を含むことができ、アドレスフィールド４７１５は、ＢＳＳＩＤ（basic service set identification）、ＳＡ（source address）、ＤＡ（destination address）、並びにＴＡ（transmitting STA address）およびＲＡ（receiving WTRU address）を示すために使用することができる。それぞれのアドレスフィールド４７１５は、４８ビットの長さとすることができる。ＭＡＣヘッダ４６４５は、シーケンス制御フィールド４７２０を含むことができ、シーケンス制御フィールド４７２０は、１６ビットの長さとすることができ、シーケンス番号およびフラグメント番号という少なくとも２つのサブフィールドを含む。ＭＡＣヘッダ４６４５は、ＱｏＳ制御フィールド４７２５（１６ビットのフィールドとすることができ、フレームが属するＴＣ（traffic category）またはＴＳ（traffic stream）を識別する）と、フレームに関する様々な他のＱｏＳ関連情報（フレームのタイプおよびサブタイプによって、様々なものとすることができる）とを含むことができる。
【０２０８】
アドレスフィールド４７１５4は、ＡＰ同士の通信のケースにおいて使用することしかできない。いくつかの実施形態においては、アドレスフィールド４７１５4を使用することはできない。ＱｏＳ制御フィールド４７２５は、データフレームに関して使用することができるが、マネージメントフレームに関して使用することはできない。従って、要約すると、ＭＡＣヘッダ４６４５は、データフレームに関しては２０８ビットの長さとすることができ、マネージメントフレームに関しては１９２ビットの長さとすることができる。
【０２０９】
図４８は、ＰＬＣＰヘッダ４８０２を含むＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマット４８００を示しており、ＰＬＣＰヘッダ４８０２は、Ｌ−ＳＴＦ４８０５、Ｌ−ＬＴＦ４８１０、およびＬ−ＳＩＧフィールド４８１５を含む。ＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマット４８００のＰＬＣＰヘッダ４８０２は、ＨＴ−ＳＩＧフィールド４８２０、ＨＴ−ＳＴＦフィールド４８２５、および複数のＨＴ−ＬＴＦ４８３０1〜４８３０Nをさらに含むことができる。ＨＴ−ＳＩＧフィールド４８２０は、ＨＴパケットフォーマットを解釈する上で必要とされる情報を搬送するために使用することができる。ＨＴ−ＳＩＧフィールド４８２０のデュレーションは、３２μｓとすることができる。ＨＴ−ＳＴＦ４８２５の１つの目的は、ＭＩＭＯシステムにおけるオートマチックゲイン制御の推定を改善することであると言える。ＨＴ−ＳＴＦフィールド４８２５のデュレーションは、１６μｓとすることができる。ＨＴ−ＬＴＦフィールド４８３０は、ＱＡＭ（quadrature amplitude modulation）マッパ出力のセットと、受信チェーンとの間におけるＭＩＭＯチャネルを受信機が推定するための手段を提供することができる。ＨＴ−ＤＬＴＦ（データ  ＨＴ−ＬＴＦ）およびＨＴ−ＥＬＴＦ（extension HT-LTF）という少なくとも２つのタイプのＨＴ−ＬＴＦフィールド４８３０が存在することができる。ＨＴ−ＤＬＴＦは、受信機がフレームのデータ部分を復調することを可能にするチャネル推定を受信機が形成するための必要な参照を提供するためにＨＴ  ＰＰＤＵ内に含めることができる。ＨＴ−ＤＬＴＦの数は、フレーム内に含まれて送信されている空間／時間ストリーム（space-time streams）の数に応じて、１、２、または４とすることができる。ＨＴ−ＥＬＴＦは、フレームのデータ部分によって使用される容量を超えるチャネルのさらなる容量の推定を受信機が形成することができるようにサウンディングＰＰＤＵ内にさらなる参照を提供することができる。ＨＴ−ＥＬＴＦの数は、０、１、２、または４とすることができる。一実施形態においては、ＨＴ−ＤＬＴＦの数は、１とすることができ、ＨＴ−ＥＬＴＦの数は、０とすることができる。
【０２１０】
ＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマット４８００は、データフィールド４８３５をさらに含むことができ、データフィールド４８３５は、サービスビット４８４０、Ａ−ＭＰＤＵ４８４５、テールビット４８５０、およびパッドビット４８５５を含むことができる。Ａ−ＭＰＤＵ４８４５は、ＭＡＣヘッダ４８６０、Ａ−ＭＳＤＵ４８６５、およびＦＣＳフィールド４８７０を含むことができる。
【０２１１】
ＭＡＣヘッダ４８６０の一般的なフォーマットが図４９に示されている。ＭＡＣヘッダ４８６０は、長さ１６ビットのフレーム制御フィールド４９０５を含むことができ、フレーム制御フィールド４９０５は、プロトコルバージョン、タイプ、サブタイプ、ＤＳ（distribution stream）へ、ＤＳから、さらなるフラグメント、再試行、パワーマネージメント、さらなるデータ、保護されたフレーム、および順序という各サブフィールドから構成することができる。
【０２１２】
ＭＡＣヘッダ４８６０は、デュレーション／ＩＤフィールド４９１０を含むことができ、デュレーション／ＩＤフィールド４９１０は、１６ビットの長さとすることができる。そのコンテンツは、フレームのタイプおよびサブタイプに伴って、様々なものとすることができる。
【０２１３】
ＭＡＣヘッダ４８６０は、複数のアドレスフィールド４９１５を含むことができ、アドレスフィールド４９１５は、ＢＳＳＩＤ（basic service set identification）、ＳＡ（source address）、ＤＡ（destination address）、並びにＴＡ（transmitting STA address）およびＲＡ（receiving WTRU address）を示すために使用されうる。それぞれのアドレスフィールド４９１５は、４８ビットの長さとすることができる。ＭＡＣヘッダ４８６０は、シーケンス制御フィールド４９２０を含むことができ、シーケンス制御フィールド４９２０は、１６ビットの長さとすることができ、シーケンス番号およびフラグメント番号という少なくとも２つのサブフィールドを含む。ＭＡＣヘッダ４８６０は、ＱｏＳ制御フィールド４９２５（１６ビットのフィールドとすることができ、フレームが属するＴＣ（traffic category）またはＴＳ（traffic stream）を識別する）と、フレームに関する様々な他のＱｏＳ関連情報（フレームのタイプおよびサブタイプによって、様々なものとすることができる）とを含むことができる。
【０２１４】
アドレスフィールド４９１５4は、ＡＰ同士の通信のケースにおいて使用することしかできない。ある実施形態においては、アドレスフィールド４９１５4を使用することはできない。ＱｏＳ制御フィールド４９２５は、データフレームに関して使用することができるが、マネージメントフレームに関して使用することはできない。したがって、要約すると、ＭＡＣヘッダ４８６０は、データフレームに関しては２０８ビットの長さとすることができ、マネージメントフレームに関しては１９２ビットの長さとすることができる。
【０２１５】
ＨＴ  ＰＰＤＵに関するＭＡＣヘッダ４８６０は、ＨＴ制御フィールド４９３０を有することができ、ＨＴ制御フィールド４９３０は、３２ビットの長さとすることができ、特定のＨＴ関連情報を指定するために使用することができる。要約すると、ＭＡＣヘッダ４８６０は、データフレームに関しては２４０ビットの長さ、およびマネージメントフレームに関しては２２４ビットの長さとすることができる。
【０２１６】
ＨＴ−ｇｒｅｅｎｆｉｅｌｄ  ＰＰＤＵデータフォーマット５０００が、図５０に示されている。ＨＴ−ＧＦ−ＳＴＦ（HT-greenfield short training field）５００５は、ｎｏｎ−ＨＴ  ＰＰＤＵフォーマット４６００およびＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマット４８００におけるＬ−ＳＴＦの代わりとして適用することができる。そのデュレーションは、３２μｓとすることができる。ＨＴ−ＬＴＦ１（first HT long training）フィールド５０１０は、ｎｏｎ−ＨＴ  ＰＰＤＵフォーマットおよびＨＴ−ｍｉｘｅｄ  ＰＰＤＵフォーマットにおけるＬ−ＬＴＦの代わりとして適用することができる。ＨＴ−ｇｒｅｅｎｆｉｅｌｄ  ＰＰＤＵデータフォーマットにおける他のフィールドは、ＨＴ−ｍｉｘｅｄ  ＰＰＤＵデータフォーマットにおける対応するフィールドと同様とすることができる。
【０２１７】
図５１は、フレームコントローラ３７１５のための例示的なコールフロー手順５１００を示す。この例では、フレームコントローラ３７１５は、はじめにチャネルモニタ３７３０からチャネルＭＣＳ情報５１０５を受信する。これらのＭＣＳ値に基づいて、フレームコントローラ３７１５は、全てのフレームの無線デュレーションを決定することができる（５１１０）。この無線デュレーションの決定は、アプリケーションの平均フレーム長さなど、アプリケーションに依存することもできる。より良好な状況を伴うチャネルは、より高いＭＣＳ値を、ひいては、より短い無線デュレーションを有することができる。
【０２１８】
無線デュレーションの決定の後に、フレームコントローラ３７１５は、バッファコントローラ３７１０からバッファステータス情報５１１５を受信することができる。はじめは全てのバッファが空である可能性があるため、フレームコントローラ３７１５は、ラウンドロビン様式で別々のＰＨＹチャネル３７３５のためのフレームを生成することを決定することができる。一例においては、フレームコントローラ３７１５は、ＰＨＹチャネル３７３５1のためのフレームを生成することを決定することができる（５１２０）。ＰＨＹチャネル３７３５1の無線デュレーションおよびＭＣＳ値に基づいて、フレームコントローラ３７１５は、結果として得られるＰＰＤＵフレームがＰＨＹチャネル３７３５1上で送信された場合に送信デュレーションが無線デュレーションと一致するようにペイロードの長さを計算することができる（５１２５）。ペイロードの長さを求めた後に、フレームコントローラ３７１５は、その長さのフレームを生成するためにＡ−ＭＳＤＵ集約ユニット３７６０、フラグメンテーションユニット３７６５、およびＡ−ＭＰＤＵ集約ユニット３７７５を制御することを試みることができる（５１３０）。一実施形態においては、しばらくたってから、フレームコントローラ３７１５が、Ａ−ＭＰＤＵ情報をバッファコントローラへ送信したこと（５１３５）に応答して、更新されたバッファステータス情報をバッファコントローラ３７１０から受信した場合には（５１４０）、フレームコントローラ３７１５は再び、別々のＰＨＹチャネル３７３５のためのフレームを生成することを決定し（５１４５）、ペイロードの長さを計算し（５１５０）、その長さのフレームを生成するためにＡ−ＭＳＤＵ集約ユニット３７６０、フラグメンテーションユニット３７６５、およびＡ−ＭＰＤＵ集約ユニット３７７５を制御することができる（５１５５）。
【０２１９】
ペイロードとは、特定のＰＨＹチャネル３７３５上での特定の無線デュレーションを達成するためのペイロードの長さの下記の計算におけるＭＳＤＵの長さを指す。事前に指定された無線デュレーションはＴμｓであると想定することができる。
【０２２０】
ＭＣＳ情報を用いて、フレームコントローラ３７１５は、はじめにＯＦＤＭシンボルごとの対応するデータビットを見つけ出すことができる。図５２は、変調およびコーディングレートからＯＦＤＭシンボルごとのデータビットへのマッピング、並びにＯＦＤＭシンボルごとのコーディングされたビット、およびｎｏｎ−ＨＴ  ＰＰＤＵフレームに関するデータレートを示している。
【０２２１】
第１の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、ＱＰＳＫ変調および３／４のコーディングレートを適用すると想定することができる。図４６に示されるように、ＰＬＣＰヘッダ４６０２は、８０μｓを要し、サービスビット４６２５と、（データフレーム用の）ＭＡＣヘッダ４６４５と、ＦＣＳフィールド４６５５と、テールビット４６３５との合計は、２６２ビットであるとさらに想定することができる。図５２から、ＯＦＤＭシンボルごとのデータビットは、７２である。シンボルデュレーションが５ＭＨｚの帯域幅で１６μｓであると想定すると、無線デュレーションＴは、下記のとおりとなる。
【０２２２】
【数１】
0005986244.tif 000002
【０２２３】
ここでは、ｘは、ペイロードの長さである。
【０２２４】
第２の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、１６−ＱＡＭ変調および１／２のコーディングレートを適用すると想定することができる。図５２から、ＯＦＤＭシンボルごとのデータビットは、９６である。したがって、無線デュレーションＴは、ペイロードの長さｘを使用して、下記のとおり計算される。
【０２２５】
【数２】
0005986244.tif 000003
【０２２６】
方程式（６）および（７）における計算は、ｎｏｎ−ＨＴ  ＰＰＤＵフレームに関するものである。ＨＴ−ｍｉｘｅｄ  ＰＰＤＵフレームおよびＨＴ−ｇｒｅｅｎｆｉｅｌｄ  ＰＰＤＵフレームに関しては、変調およびコーディングレートからＯＦＤＭシンボルごとのデータビットへのマッピング、並びにＯＦＤＭシンボルごとのコーディングされたビット、およびｎｏｎ−ＨＴ  ＰＰＤＵフレームに関するデータレートは、別のものとすることができる。マッピング案が、図５３において提示されている。
【０２２７】
第３の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、ＱＰＳＫ変調および３／４のコーディングレートを適用すると想定することができる。図４８に示されるように、ＰＬＣＰヘッダ４８０２は、１４４μｓを要し、サービスビット４８４０と、（データフレーム用の）ＭＡＣヘッダ４８６０と、ＦＣＳフィールド４８７０と、テールビット４８５０との合計は、２９４ビットであるとさらに想定することができる。図５３から、ＯＦＤＭシンボルごとのデータビットは、７８である。シンボルデュレーションが５ＭＨｚの帯域幅で１６μｓであると想定すると、無線デュレーションＴは、下記のとおりとなる。
【０２２８】
【数３】
0005986244.tif 000004
【０２２９】
第４の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、６４−ＱＡＭ変調および３／４のコーディングレートを適用すると想定することができる。図５３から、ＯＦＤＭシンボルごとのデータビットは、２３４である。したがって、無線デュレーションＴは、ペイロードの長さを使用して、下記のとおり計算することができる。
【０２３０】
【数４】
0005986244.tif 000005
【０２３１】
ＩＥＥＥ８０２．１１ｎは、ＭＡＣオーバーヘッドを減らして生データレートを高めるためにＭＳＤＵ集約およびＭＰＤＵ集約をサポートする。ＰＰＤＵのＡ−ＭＰＤＵ５４００の構成が、図５４に示されている。Ａ−ＭＰＤＵ５４００は、複数のＡ−ＭＰＤＵサブフレーム５４０５1、５４０５2、．．．、５４０５nを含むことができる。それぞれのＡ−ＭＰＤＵサブフレーム５４０５は、ＭＰＤＵデリミタ５４１０、ＭＰＤＵ５４１５、およびパディングビット５４２０を含むことができる。ＭＰＤＵデリミタ５４１０は、２バイトの長さとすることができ、パディングビット５４２０は、０から３バイトまでで変わることができる。
【０２３２】
ＭＰＤＵ５４１５は、３０バイトのＭＡＣヘッダ５４２５と、複数のＡ−ＭＳＤＵサブフレーム５４３０1〜５４３０mと、４バイトのＦＣＳフィールド５４３５とを含むことができる。それぞれのＡ−ＭＳＤＵサブフレーム５４３０は、６バイトのＤＡ５４４０と、６バイトのＳＡ５４４５と、２バイトの長さフィールド５４５０と、ＭＳＤＵ５４５５と、パディングバイト５４６０とを含むことができる。パディングバイト５４６０は、Ａ−ＭＳＤＵサブフレーム５４３０が４バイトの倍数になることができるようなものとすることができる。したがって、パディングバイト５４６０は、０バイトから３バイトまでで変わることができる。ＭＳＤＵ５４５５は、２３０４バイト未満とすることができるため、Ａ−ＭＳＤＵサブフレーム５４３０は、２３２０バイト未満とすることができる。ＭＰＤＵ５４１５は、暗号化およびインテグリティーを伴わずに４０９５バイト未満とすることができる。３０バイトのＭＡＣヘッダ５４２５および４バイトのＦＣＳフィールド５４３５を伴って、ＭＰＤＵ５４１５内のＡ−ＭＳＤＵサブフレーム５４３０の全長は、４０６１バイト未満とすることができる。ＭＰＤＵ５４１５は、４０９５バイト未満とすることができるため、Ａ−ＭＰＤＵサブフレーム５４０５の最大の長さは、４１００バイト未満とすることができる。その結果として、Ａ−ＭＰＤＵ５４００の全長は、６５５３５バイト未満とすることができる。
【０２３３】
第５の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、ＱＰＳＫ変調および３／４のコーディングレートを適用すると想定することができる。ＭＳＤＵ同士は、等しい長さであり、４バイトの倍数である。フレームコントローラ３７１５がＭＰＤＵを集約している間に、Ａ−ＭＳＤＵオペレーションを行うことはできない。
【０２３４】
図５４に示される例においては、ＭＡＣヘッダ５４２５、ＭＰＤＵデリミタ５４１０、およびＦＣＳフィールド５４３５のビットの合計は、２８８ビットに等しい。この例においては、無線デュレーションＴは、下記のとおりである。
【０２３５】
【数５】
0005986244.tif 000006
【０２３６】
第６の例として、フレームコントローラ３７１５は、データフレームとともに動作しており、ある特定のチャネルが、６４−ＱＡＭ変調および３／４のコーディングレートを適用すると想定することができる。サービスビット＋テールビットは、長さ２２ビットであり、ＭＡＣヘッダ５４２５、ＭＰＤＵデリミタ５４１０、およびＦＣＳフィールド５４３５のビットの合計は、２８８ビットに等しいと想定することができる。図５３から、ＯＦＤＭシンボルごとのデータビットは、２３４である。したがって、無線デュレーションＴは、下記のとおりとなる。
【０２３７】
【数６】
0005986244.tif 000007
【０２３８】
図５５Ａおよび図５５Ｂに示される代替実施形態においては、アクセスカテゴリー内のそれぞれの物理チャネルと個別のバッファとの関連付けを取り除くことができる。代わりに、送信されることになるフレーム同士を別々の長さのグループへと分けるために、バッファのセットを使用することができる。記載の実施形態においては、アクセスカテゴリーごとに３つのバッファが使用されているが、異なる数のバッファを可能とすることもできる。
【０２３９】
この実施形態では、機能ブロック図のうちの残りの部分は、図５５Ｂに示されるように、スケジューラ５５００が付加されること以外は、図３７と同様のままとすることができる。この代替設計においては、バッファコントローラ３７１０は、ロジックバッファ３７４０内の送信されることになるフレームの数を前の設計の場合と相対的に同じに保持するために、アクセスカテゴリーのうちのそれぞれにおけるロジックバッファ３７４０を管理することができる。このケースにおいては、ロジックバッファ３７４０は、フレームの長さのサブセットに対応することができる。ロジックバッファ３７４０1は、全てのショートフレームを含むことができ、ロジックバッファ３７４０2は、全てのミディアムサイズフレームを含むことができ、ロジックバッファ３７４０3は、全てのロングフレームを含むことができる。スケジューラ５５００の役割は、それぞれの個々のＴＸＯＰ中にそれぞれの物理チャネル上で送信するために、適切にサイズ設定されたフレームを選択することであると言える。この選択は、フレームが選択される元となるバッファ、および特定の時間におけるチャネル品質に基づくことができる。この方法においては、（限られた数のバッファの使用によって）チャネル使用の効率の損失を小さくしながら、ほぼ等しい長さの送信という前提を保持することができる。とはいえ、ほぼ等しい長さの送信は、送信チェーン内でスケジューラ５５００の後に配置されるＭＰＤＵ集約ブロックによって、確かなものにすることができる。例えば、スケジューラ５５００は、基準のセットを使用して、それぞれの送信時間中に３つのバッファから４つのフレームを選択することができる。
【０２４０】
特定の送信時間において、スケジューラ５５００は、それぞれのバッファの最前部におけるフレームを検査することと、最短の「存続時間」を有するフレームを選択することによって開始することとが可能である。この選択は、ＱｏＳに関する考慮事項とともに実行することができ、当該考慮事項は、ＱｏＳコントローラ３７２０から受信することができる。より高い優先度のフレームを代わりに送信する必要があるケースにおいては、ロジックバッファ３７４０の最前部におけるフレームは、次の送信機会を待つことができる。
【０２４１】
選択されたフレームは、そのフレームのための正しい送信の可能性を最大にするために、再送信および遅延の統計など、最近のチャネル品質情報に基づいて、チャネルにマップすることができる。
【０２４２】
残りのチャネルには、全てのチャネル上でほぼ等しい送信時間を有するような方法でフレームを割り当てることができる。これは、チャネル状況のうちのそれぞれに合うように適切なロジックバッファ３７４０からフレームを選択することを通じて実行することができる。このフレーム割り当て中には、プライマリーＣＳＭＡルールを依然として考慮に入れることができる。
【０２４３】
バッファコントローラ３７１０は、並べ替えを除いて、自分の上述のタスクの実行を継続することができ、並べ替えは、より高い優先度のフレームをそれぞれのバッファの最前部へ同じバッファ内で移動させることにのみ適用することができる。１つのバッファから別のバッファへフレームを並べ替える必要性をなくすことができる。加えて、ＰＨＹチャネルに明確に結び付けられていない可能性がある別の数のフレームの存在を考慮に入れるように、バッファの生成を修正することができる。
【０２４４】
この実施形態は、１つのバッファから別のバッファへパケットを並べ替える必要性をなくすことができる。なぜなら、スケジューラ５５００は、それぞれのＴＸＯＰにおいてそれぞれのＰＨＹチャネルを介して送信されることになるパケットを動的に選択することができるためである。
【０２４５】
この実施形態は、パケットの並べ替え中に生じるチャネルの非効率をなくすことができる。別のＰＨＹチャネルに合わせられている可能性のある長さを伴って生成されたパケットは、結果として、並べ替える際の非効率につながる場合がある。図５５Ｂにおけるスケジューラ５５００は、ほぼ等しい長さの送信を達成するためにパケットを動的に選択することができるため、効率は、全てのＴＸＯＰ上で同じとすることができる。
【０２４６】
この実施形態は、特定のＰＨＹチャネルに伴う問題に迅速に対応することができる。詳細には、あるＰＨＹチャネルが、複数の再送信またはエラーなどの問題を有している場合に、スケジューラ５５００は、問題のあるＰＨＹチャネルに起因する遅延を既に被っているフレームのための送信時間を短縮するために、そのフレームを別のＰＨＹチャネルへ送信できることを確実にすることができる。したがってスケジューラ５５００は、ＴＸＯＰベースでフレームのためのＰＨＹチャネルを動的に変更することによって、ある形態のチャネルダイバーシティーを可能にすることができる。
【０２４７】
上位層（例えば、ＩＰ）における受信機バッファのサイズは、小さくすることができる。なぜなら、スケジューラ５５００は、ＩＰフラグメントからのフレームが、全体的な遅延を最小限にした状態で送信されることを可能にすることができるためである。これによって、結果として、エンドツーエンドの遅延を低減することができる。さらに、所与の時点におけるチャネルから独立した長さを伴ってフレームが生成されるため、チャネル応答における変化に対処することができる。
【０２４８】
送信エラーは、プライマリーＣＳＭＡアプローチを使用する集約されたチャネルのコンテキストにおいて取り扱うことができる。再送信は、例えば、次の３つの方法で実行することができる：１）単一のＭＰＤＵ再送信、この場合には、ＭＰＤＵは、１つのチャネルにおいて再送信することができる；２）複数のチャネル上でのＭＰＤＵ、この場合には、ＭＰＤＵは、全ての集約されたチャネル上で繰り返し送信することができる；および／または３）複数のチャネルにわたって再フラグメント化される。最後のオプションに関しては、失敗したＭＰＤＵを分割することができ、フラグメントの部分および失敗したＭＰＤＵを示すために、さらなるＭＡＣヘッダを付加することができる。受信機は、分断されたフラグメントの全てを再び組み立てることが必要となる場合がある。これらのオプションのそれぞれによって、余分な複雑さが持ち込まれる場合がある。加えて、これは、データメッセージとオーバーヘッドとの比率の観点から効率的ではない場合がある。以降の説明においては、ＡＣＫを要求することができる送信に焦点を合わせている。ＡＣＫが要求されない場合には、再送信が必要とされることもない。
【０２４９】
４つの集約されたチャネル上で同時に送信された全てのパケットが、同じＡＣに属していると想定することができる。したがって、以降で説明するアルゴリズムは、集約されたチャネル上で同時に送信された別々のＡＣを伴う複数のパケットをサポートすることはできない。それぞれのＡＣは、自分自身のバッファを有していると想定することができる。また、それぞれのＡＣは、メディアの競合のためのバックオフ手順を保持するために、自分のＥＤＣＡＦに関連付けられることが可能である。コンテンションが成功すると、ＡＣのＥＤＣＡＦには、このカテゴリーのＭＰＤＵの送信のためのＥＤＣＡ  ＴＸＯＰを許可することができる。別々のＡＣに関するコンテンションウィンドウサイズおよび最大ＴＸＯＰデュレーションは、別々のものとすることができる。
【０２５０】
２つの異なるバッファリングオプションが存在することができる。図５６に示されるように、第１のバッファリングオプションは、それぞれのチャネルが、単一のインスタントバッファ（instant buffer）に関連付けられていると想定することができる。それぞれのＡＣに、バッファは１つだけ存在することができる。チャネル使用の効率を高めるために、上述のプライマリーチャネル最終終了技術が、この実施態様において使用される場合には、非プライマリーチャネルにおけるフレーム同士の送信時間は、同様となることが可能である。プライマリーチャネルにおいて送信が終了する前に、非プライマリーチャネルにおいてアイドル期間が長くなりすぎないようにすることができる。非プライマリーチャネルにおける送信時間と、プライマリーチャネルにおける送信時間との間の最大のギャップは、特定の値よりも小さくすることができ、例えば、ｌａｒｇｅｓｔ＿ｇａｐ＜ＡＩＦＳ（ＡＣ）である。上述のように共通仮想感知技術が実施される場合には、フレームの割り当てが実行される際にプライマリーチャネルが最後に終了するのを保証することを不要とすることができる。
【０２５１】
バッファは、対応するチャネル上で送信されるようにスケジュールされているフレームを、それらのフレームが首尾よく配信される前に格納しておくことができる。送信されることになるフレームは、物理チャネルに割り当てられる前に、完全なＭＰＤＵを生成するためにＭＡＣヘッダおよびＣＲＣを付加されることが可能であり、また、インスタントバッファ内に留まることができ、インスタントバッファは、それぞれのチャネルにおいて次に送信するためのＭＰＤＵを格納しておくことしかできない。
【０２５２】
図５７Ａおよび図５７Ｂに示されるように、第２のバッファリングオプションを実施することができ、それによって、それぞれのＡＣは、それぞれのチャネルに割り当てられた別々のフレームを伴う個別のバッファを有することができる。それぞれのＡＣにおいては、４つのチャネルそれぞれに対応する４つのロジックバッファが存在することができる。両方のバッファ実施態様に関する再送信技術は、同様のものとすることができ、それらの再送信技術について、ここで説明する。
【０２５３】
高優先度制御メッセージの再送信は、データメッセージまたは中〜低優先度の制御メッセージとは異なるものとすることができる。高優先度制御メッセージ、例えば、チャネル切り替えなどは、初回の送信においてはバッファ内のキューに入れることはできない。高優先度制御メッセージの送信は、堅牢性を高めるために、４つのチャネルを介して繰り返し行うことができる。したがって、高優先度制御メッセージの再送信の可能性は、低くすることができる。４つのチャネル上で受信されたＡＣＫがない場合には、高優先度制御メッセージを再送信することができる。そのようなケースにおいては、バックオフウィンドウを再送信のために増大させることができる。高優先度制御メッセージの配信のために使用される送信アプローチが異なれば、再送信スキームも異なることになる場合がある。例えば、ＷＴＲＵによって配信されるメッセージに関しては：１）最も高いＡＣにおいて送信されるメッセージの場合、失敗したＭＰＤＵは、バッファのフロントエンド内に留まることができ、再びＴＸＯＰを得ると、再送信されることが可能であり；ＩＥＥＥ８０２．１１において示されるように、コンテンションウィンドウを倍にすることができ；および／または２）より低いＡＣにおいて送信されるメッセージの場合、そのメッセージを最も高いＡＣのフロントエンドに移動させて、再送信の際には最も高いＡＣを通じて送信することができる。
【０２５４】
別の例として、ＡＰによって配信されるメッセージに関しては、第１の再送信に関するコンテンションウィンドウＣＷをＣＷｍｉｎとして設定することができ、第２の再送信に関するコンテンションウィンドウＣＷを倍にすることができる。それぞれの再送信のたびに、コンテンションウィンドウがＣＷｍａｘに達するまで、ＩＥＥＥ８０２．１１におけるようにコンテンションウィンドウを倍にすることができる。例えば、ＣＷｍｉｎおよびＣＷｍａｘを、最も高いＡＣのための値として設定することができ、この場合には、ＣＷｍｉｎを７（スロット時間）とすることができ、ＣＷｍａｘを１５（スロット時間）とすることができる。
【０２５５】
中優先度および低優先度の制御メッセージの再送信に関しては、ＥＤＣＡが呼び出された場合には、中優先度および低優先度の制御メッセージを１つのＡＣにおいて送信することができる。プライマリーチャネルにおいてＭＰＤＵの送信に失敗した場合には、下記のように、様々なオプションを実施することができる。第１のオプションにおいては、ＴＸＯＰの送信を終了することができ、バックオフ手順を呼び出すことができる。フレームのうちの全ては、元のフレームとして留まることができる。
【０２５６】
代替として、または追加として、第２のオプションにおいては、第１のオプションが使用される場合に、その第１のオプションは、プライマリーチャネルのインスタントバッファ内に留まって、現在のＴＸＯＰが終了するまで、このパケットを宛先へ送信することを繰り返すことができる。次いで、受信機のプライマリーチャネルは、フレームの全てが非プライマリーチャネルに割り当てられていることを確認するために、この情報に関するフィードバックをバッファコントローラ３７１０に提供することが必要となる場合がある。プライマリーチャネル最終終了技術が実施される場合には、プライマリーチャネルにおける送信が最後に終了することを確認するために、失敗したＭＰＤＵを、より良好なチャネル状況を伴う非プライマリーチャネルのうちの１つへ移動させることができる。プライマリーチャネル最終終了技術が実施されない場合には、失敗したＭＰＤＵを、非プライマリーチャネルのうちの任意のチャネル、例えば、クォータナリーチャネルへ移動させることができる。新たなＭＰＤＵをプライマリーチャネルのためにパックすることはできない。この失敗した送信が、このＴＸＯＰにおける最後の送信である場合には、その失敗したＭＰＤＵは、プライマリーチャネルのインスタントバッファ内に留まることができ、次のＴＸＯＰ中にこのＥＤＣＡＦが再びチャネルを得たときに送信することができる。図５８は、プライマリーチャネルにおいて送信が失敗した場合の再送信の例を示す。
【０２５７】
非プライマリーチャネルにおいてＭＰＤＵの送信が失敗した場合には、２つのシナリオが生じる可能性がある。第１に、全てのチャネルに新たなフレームをいっさい割り当てることができない。一例においては、非プライマリーチャネルにおける１つの送信のみが失敗していることがある。ＴＸＯＰが終了していない場合には、再送信ＭＰＤＵをプライマリーチャネルのバッファへ移動させて、プライマリーチャネル上で送信することができる。このＴＸＯＰが終了している場合には、再送信パケットは、同じインスタントバッファ内に留まることができ、次のＴＸＯＰにおいて送信することができる。図５９は、クォータナリーチャネルにおいて送信が失敗した場合の再送信の例を示している。
【０２５８】
別の例においては、非プライマリーチャネルにおける少なくとも２つの送信が失敗している。ＴＸＯＰが終了していない場合には、再送信ＭＰＤＵのうちの１つをプライマリーチャネルへ移動させることができ、他の再送信ＭＰＤＵは、同じバッファ内に残ることができる。プライマリーチャネルにおいて送信が終了している場合には、再送信されるＭＰＤＵを移動させることができる。これは、他のチャネルよりもプライマリーチャネルにおいて、より多くの送信時間を必要とする場合がある。あるいは、再送信ＭＰＤＵのうちの全てをプライマリーチャネル内に置くこともできる。共通仮想感知技術が実施される場合には、失敗したＭＰＤＵのうちのいずれか１つをプライマリーチャネルへ移動させて、プライマリーチャネル上で再送信することができる。ＴＸＯＰが終了している場合には、再送信ＭＰＤＵのうちの全てが、インスタントバッファ内に残ることができ、次のＴＸＯＰまで同じチャネルにおいて送信することができる。
【０２５９】
ＴＸＯＰが終了しているプライマリーチャネルにフレームが割り当てられた場合には、再送信ＭＰＤＵは、次のＴＸＯＰまで、自分の有効期限が切れるまで、または再試行回数の制限に達するまで、自分の元の位置（インスタントバッファ、または非プライマリーチャネルのロジックバッファ）に残ることができる。ＴＸＯＰが終了していない場合には、同じチャネルにおいて送信を継続することができる。失敗したＭＰＤＵは、同じチャネル上で再送信することができる。上述のＡＣＫ手順が実施される場合には、より長いフレームをプライマリーチャネル上で送信することが必要となることがあり、プライマリーチャネル上での送信が最後に終了するように保証することが必要となることがある。上述のＡＣＫ手順が実施されない場合には、より長いフレームをプライマリーチャネルにおいて送信させることは不要とすることができる。
【０２６０】
あるいは、失敗した（１つまたは複数の）チャネルにおける送信を終了することができる。このＴＸＯＰ内で、再送信されるＭＰＤＵを別のインスタントバッファまたはロジックバッファへ移動させて、同様のチャネル状況を伴うチャネルにおいて送信することができる。
【０２６１】
あるいは、再送信されるＭＰＤＵは、次のＴＸＯＰまで元のインスタントバッファまたはロジックバッファ内に留まることができる。このＭＰＤＵは、特定の時間よりも長くバッファ内に留まる場合には、同様のチャネル状況を伴う別のチャネルへ移動させることができる。
【０２６２】
集約されたチャネルの送信においては、送信のためのコンテンションウィンドウは、次のように実施することができる：プライマリーチャネルが失敗した場合には、コンテンションウィンドウは、倍になることができる。非プライマリーチャネルが失敗した場合、および少なくとも１つのチャネル内に存在する少なくとも１つの再送信ＭＰＤＵがある場合には、この送信のためのコンテンションウィンドウを倍にすることができる。非プライマリーチャネルのうちの全てが再送信である場合には、コンテンションウィンドウを倍にすることができる。複数のチャネル内に複数の再送信されるＭＰＤＵが存在する場合には、この送信のためのコンテンションウィンドウを倍にすることができる。
【０２６３】
PHY-TXend.confirmにおいて開始する、SIFSTime+SlotTime+PHY-RX-START-Delayの値を伴って、ＳＴＡがACKTimeout間隔にわたって待機することができるように、修正されたACKTimeOut間隔を使用することができる。集約されたチャネルの実施態様においては、ACKTimeOut間隔を修正することが必要となる場合がある。プライマリーチャネル最終終了技術が実施される場合には、それぞれのチャネルごとのACKTimeOut間隔の値を、(XMIT_TIME_PRIMARY-packet_xmit_time)+SIFSTime+SlotTime+PHY-RX-START-Delayとして修正することができ、ここでは、XMIT_TIME_PRIMARYは、プライマリーチャネルにおけるＭＰＤＵ送信時間とすることができ、packet_xmit_timeは、そのチャネルにおけるＭＰＤＵ送信時間である。
【０２６４】
共通仮想感知技術が実施される場合には、それぞれのチャネルごとの修正されたACKTimeOut間隔の値は、(MAX_XMIT_TIME-packet_xmit_time)+SIFSTime+SlotTime+PHY-RX-START-Delayとすることができ、ここでは、MAX_XMIT_TIMEは、集約されたチャネルにおける最長の送信時間とすることができる。
【０２６５】
実施形態
１．プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルを含む複数の集約されたチャネルを使用して不連続なスペクトルを介して通信を行うためのチャネルアグリゲーションを実行するノードの方法であって、
プライマリーチャネル上でＣＳＭＡを実行し、プライマリーチャネルへのアクセスを得て、プライマリーチャネルのチャネルステータスを判定するステップと、
プライマリーチャネルのチャネルステータスに基づいて少なくとも１つの非プライマリーチャネルのチャネルステータスを設定するステップと
を含むことを特徴とする方法。
【０２６６】
２．ノードは、ＡＰまたはｅＮＢであることを特徴とする実施形態１に記載の方法。
【０２６７】
３．ノード内の回路が、集約されたチャネルのそれぞれの上でＰＤＵを少なくとも１つのＷＴＲＵへ送信するステップをさらに含み、ＰＤＵは、データＰＤＵまたはマネージメントＰＤＵであることを特徴とする実施形態１〜２のいずれか１つに記載の方法。
【０２６８】
４．プライマリーチャネル上でのデータ送信は、少なくとも１つの非プライマリーチャネル上でのデータ送信の後に終了することを特徴とする実施形態１〜３のいずれか１つに記載の方法。
【０２６９】
５．ＮＡＶが、集約されたチャネルを介して送信されるパケットのデュレーションフィールド内に含まれており、チャネル上での最長の送信時間、およびその最長の送信時間と、チャネルのうちの特定の１つのチャネル上での送信時間との間における差を示すことを特徴とする実施形態１〜４のいずれか１つに記載の方法。
【０２７０】
６．ノード内の回路が、プライマリーチャネルにおける失敗したパケット送信を検知するステップと、
ノード内の回路が、現在の送信機会を終了するステップと、
ノード内の回路が、バックオフ手順を開始するステップと
をさらに含むことを特徴とする実施形態１〜５のいずれか１つに記載の方法。
【０２７１】
７．ノード内の回路が、プライマリーチャネルにおける失敗したパケット送信を検知するステップと、
ノード内の回路が、失敗したパケットを、非プライマリーチャネルに関連付けられているバッファへ移動させるステップと
をさらに含むことを特徴とする実施形態１〜６のいずれか１つに記載の方法。
【０２７２】
８．ノード内の回路が、非プライマリーチャネルにおける失敗したパケット送信を検知するステップと、
ノード内の回路が、失敗したパケットを、プライマリーチャネルに関連付けられているバッファへ移動させるステップと
をさらに含むことを特徴とする実施形態１〜７のいずれか１つに記載の方法。
【０２７３】
９．プライマリーチャネルがビジーチャネルステータスを有している状況においては、少なくとも１つの非プライマリーチャネルは、ビジーチャネルステータスを有していると想定されることを特徴とする実施形態１〜８のいずれか１つに記載の方法。
【０２７４】
１０．プライマリーチャネルがビジーチャネルステータスを有している状況においては、送信は、その後のＴＸＯＰに延期されることを特徴とする実施形態１〜９のいずれか１つに記載の方法。
【０２７５】
１１．ノードは、プライマリーチャネルへのアクセスを得るとすぐに、少なくとも１つの非プライマリーチャネルへのアクセスを得ることを特徴とする実施形態１〜１０のいずれか１つに記載の方法。
【０２７６】
１２．ノード内の回路が、ＡＩＦＳにわたって待機してから、プライマリーチャネル上でバックオフを実行するステップと、
ノード内の回路が、ＰＩＦＳ（PCF(point coordination function) inter-frame space）期間にわたって少なくとも１つの非プライマリーチャネルのチャネルステータスをチェックするステップと、
ノード内の回路が、プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルのそれぞれの上でＰＤＵを送信したことに応答して、プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルのそれぞれの上で肯定ＡＣＫメッセージを受信するステップと
をさらに含むことを特徴とする実施形態１〜１１のいずれか１つに記載の方法。
【０２７７】
１３．プライマリーチャネルは、少なくとも１つの非プライマリーチャネルよりも大きな帯域幅にわたって動作するように構成されることを特徴とする実施形態１〜１２のいずれか１つに記載の方法。
【０２７８】
１４．ノード内の回路が、ＡＩＦＳ時間にわたって待機した後にＲＴＳメッセージを送信し、前記プライマリーチャネル上でバックオフを実行するステップと、
ノード内の回路が、ＳＩＦＳ期間にわたって待機した後にＣＴＳメッセージを受信するステップと、
ノード内の回路が、プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルのうちのそれぞれの上でＰＤＵを送信するステップと、
ノード内の回路が、プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルのうちのそれぞれの上で肯定ＡＣＫメッセージを受信するステップと
をさらに含むことを特徴とする実施形態１〜１３のいずれか１つに記載の方法。
【０２７９】
１５．ノード内の回路が、プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルのうちのどれが新たなチャネルへ切り替えられているかを示す切り替えチャネルフィールド、新たなチャネルの周波数を示す新たなチャネル番号フィールド、並びに新たなチャネルの特性を示すチャネル特徴フィールドを含むＣＳＡメッセージを送信するステップをさらに含むことを特徴とする実施形態１〜１４のいずれか１つに記載の方法。
【０２８０】
１６．ノード内のバッファコントローラが、集約されたチャネルに関するチャネルＭＣＳ情報を受信するステップと、
バッファコントローラが、複数のＡＣのそれぞれに、集約されたチャネルのうちのそれぞれのためのロジックバッファを生成するステップと、
バッファコントローラが、ノード内のフレームコントローラからＡ−ＭＰＤＵフレーム情報を受信するステップと、
フレームコントローラが、Ａ−ＭＰＤＵフレームの集約およびフラグメンテーションを制御するステップと
をさらに含むことを特徴とする実施形態１〜１５のいずれか１つに記載の方法。
【０２８１】
１７．バッファコントローラが、ＱｏＳ情報およびサイレント期間情報を受信するステップと、
バッファコントローラが、フレームの並べ替えおよびフレームの送信をスケジュールするステップと
をさらに含むことを特徴とする実施形態１６に記載の方法。
【０２８２】
１８．ノード内のスケジューラが、それぞれのフレームが選択される元となるバッファ、および特定の時間におけるチャネル品質に基づいて、それぞれの送信機会の間に複数の物理チャネルのそれぞれの上で送信するためのフレームを選択するステップと、
スケジューラが、それぞれの選択されたフレームをそれぞれのチャネルにマップするステップと
をさらに含むことを特徴とする実施形態１〜１７のいずれか１つに記載の方法。
【０２８３】
１９．マップするステップは最近のチャネル品質情報に基づいており、選択されたフレームのための正しい送信の可能性を最大にすることを特徴とする実施形態１８に記載の方法。
【０２８４】
２０．プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルを含む複数の集約されたチャネルに関するチャネルＭＣＳ情報を受信し、複数のＡＣのそれぞれに、集約されたチャネルのうちのそれぞれのためのロジックバッファを生成するように構成されているバッファコントローラと、
Ａ−ＭＰＤＵフレーム情報を前記バッファコントローラに提供し、Ａ−ＭＳＤＵフレームの集約およびフラグメンテーションを制御するように構成されているフレームコントローラと
を含むことを特徴とするノード。
【０２８５】
２１．フレームコントローラは、Ａ−ＭＰＤＵの集約を制御するようにさらに構成されていることを特徴とする実施形態２０に記載のノード。
【０２８６】
２２．ロジックバッファは、フラグメント化されたＡ−ＭＳＤＵフレームを格納することを特徴とする実施形態２０〜２１のいずれか１つに記載のノード。
【０２８７】
２３．ＡＰまたはｅＮＢであることを特徴とする実施形態２０〜２２のいずれか１つに記載のノード。
【０２８８】
２４．プライマリーチャネルおよび少なくとも１つの非プライマリーチャネルを含む複数の集約されたチャネルを使用して不連続なスペクトルを介して通信を行うように構成されているトランシーバと、
集約されたチャネルに関するチャネルＭＣＳ情報を受信し、複数のＡＣのそれぞれに、集約されたチャネルのうちのそれぞれのためのロジックバッファを生成するように構成されているバッファコントローラと、
フレームを選択し、それぞれのフレームが選択される元となるバッファ、および特定の時間におけるチャネル品質に基づいて、それぞれの送信機会の間に複数の物理チャネルのそれぞれの上で送信し、それぞれの選択されたフレームをそれぞれのチャネルにマップするように構成されているスケジューラと
を含むことを特徴とするノード。
【０２８９】
２５．ＡＰまたはｅＮＢであることを特徴とする実施形態２４に記載のノード。
【０２９０】
上記では特徴および要素について特定の組合せで説明しているが、それぞれの特徴または要素は、単独で、またはその他の特徴および要素のうちの任意のものとの組合せで使用することができるということを当業者なら理解するであろう。また、本明細書に記載されている実施形態は、コンピュータまたはプロセッサによって実行するためにコンピュータ可読メディア内に組み込まれているコンピュータプログラム、ソフトウェア、またはファームウェアで実装することができる。コンピュータ可読媒体の例としては、（有線接続または無線接続を介して伝送される）電子信号、およびコンピュータ可読ストレージメディアが含まれる。コンピュータ可読ストレージメディアの例としては、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気メディア（例えば、内蔵ハードディスクまたはリムーバブルディスク）、光磁気メディア、並びにＣＤまたはＤＶＤなどの光メディアが含まれるが、それらには限定されない。ソフトウェアと関連付けられているプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、Ｎｏｄｅ−Ｂ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、ワイヤレスルータ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用することができる。
【図１Ａ】
0005986244.tif 000008
【図１Ｂ】
0005986244.tif 000009
【図１Ｃ】
0005986244.tif 000010
【図２】
0005986244.tif 000011
【図３】
0005986244.tif 000012
【図４】
0005986244.tif 000013
【図５】
0005986244.tif 000014
【図６】
0005986244.tif 000015
【図７】
0005986244.tif 000016
【図８】
0005986244.tif 000017
【図９】
0005986244.tif 000018
【図１０】
0005986244.tif 000019
【図１１】
0005986244.tif 000020
【図１２】
0005986244.tif 000021
【図１３】
0005986244.tif 000022
【図１４】
0005986244.tif 000023
【図１５】
0005986244.tif 000024
【図１６】
0005986244.tif 000025
【図１７】
0005986244.tif 000026
【図１８】
0005986244.tif 000027
【図１９】
0005986244.tif 000028
【図２０】
0005986244.tif 000029
【図２１】
0005986244.tif 000030
【図２２】
0005986244.tif 000031
【図２３】
0005986244.tif 000032
【図２４】
0005986244.tif 000033
【図２５】
0005986244.tif 000034
【図２６】
0005986244.tif 000035
【図２７】
0005986244.tif 000036
【図２８】
0005986244.tif 000037
【図２９】
0005986244.tif 000038
【図３０】
0005986244.tif 000039
【図３１】
0005986244.tif 000040
【図３２】
0005986244.tif 000041
【図３３】
0005986244.tif 000042
【図３４】
0005986244.tif 000043
【図３５】
0005986244.tif 000044
【図３６】
0005986244.tif 000045
【図３７Ａ】
0005986244.tif 000046
【図３７Ｂ】
0005986244.tif 000047
【図３８】
0005986244.tif 000048
【図３９】
0005986244.tif 000049
【図４０】
0005986244.tif 000050
【図４１】
0005986244.tif 000051
【図４２】
0005986244.tif 000052
【図４３】
0005986244.tif 000053
【図４４】
0005986244.tif 000054
【図４５】
0005986244.tif 000055
【図４６】
0005986244.tif 000056
【図４７】
0005986244.tif 000057
【図４８】
0005986244.tif 000058
【図４９】
0005986244.tif 000059
【図５０】
0005986244.tif 000060
【図５１】
0005986244.tif 000061
【図５２】
0005986244.tif 000062
【図５３】
0005986244.tif 000063
【図５４】
0005986244.tif 000064
【図５５Ａ】
0005986244.tif 000065
【図５５Ｂ】
0005986244.tif 000066
【図５６】
0005986244.tif 000067
【図５７Ａ】
0005986244.tif 000068
【図５７Ｂ】
0005986244.tif 000069
【図５８】
0005986244.tif 000070
【図５９】
0005986244.tif 000071