(57)【要約】【課題】パケット・ネットワークにおいて、フレーム集約を使用して所与の量のユーザ・データを送信するために使用する物理層フレームの数を削減する方法を提供すること。【解決手段】パケット・ネットワークは、１つまたは複数のＩＥＥＥ  ８０２．１１標準に従って動作する無線ローカル・エリア・ネットワーク（ＷＬＡＮ）の物理（ＰＨＹ）層およびメディア・アクセス制御（ＭＡＣ）層を使用することができる。フレーム集約は、ユーザ・データを含むいくつかの個別の上位層フレームを１つのＰＨＹ層フレームに結合し、送信されるＰＨＹ層フレームあたりのユーザ・データの量を増やす。フレーム集約により、ＰＨＹ層オーバヘッドとＭＡＣ層オーバヘッドのどちらもが削減されることで効率が向上する。【選択図】図２
2005184839.tif 000002
【特許請求の範囲】
【請求項１】
集約データのフレームを生成する方法であって、
（ａ）第１の層に従って１つまたは複数のユーザ・データ・フレームを集約ユーザ・データに関連づける工程と、
（ｂ）集約層で、前記集約ユーザ・データに少なくとも１つのヘッダを追加することによって、前記集約ユーザ・データから各々第２の層に従うフォーマットを有する１つまたは複数のサブフレームを生成する工程と、
（ｃ）第３の層に従って前記１つまたは複数のサブフレームから集約フレームを形成する工程と
を含む方法。
【請求項２】
工程（ａ）が、前記１つまたは複数のユーザ・データ・フレームを前記集約ユーザ・データとしてのダミー・フレームにグループ化する工程を含み、工程（ｂ）が、前記第２の層に従って前記ダミー・フレームに前記ヘッダを追加してサブフレームを生成する工程を含む、請求項１に記載の発明。
【請求項３】
工程（ｂ）が、（ｂ１）前記第２の層に従って各対応するユーザ・データ・フレームにサブフレーム・ヘッダを追加することによって、前記１つまたは複数のユーザ・データ・フレームから１つまたは複数のサブフレームを形成する工程と、（ｂ２）前記１つまたは複数のサブフレームをダミー・フレームにグループ化する工程と、（ｂ３）前記第２の層に従って前記ダミー・フレームにダミー・ヘッダを追加する工程とを含む、請求項１に記載の発明。
【請求項４】
工程（ｂ）が、前記第２の層に従って各対応するユーザ・データ・フレームにサブフレーム・ヘッダを追加することによって、前記１つまたは複数のユーザ・データ・フレームから１つまたは複数のサブフレームを形成する工程を含み、工程（ｃ）が、（ｃ１）既定の順序で１つまたは複数のサブフレームをグループ化する工程と、（ｃ２）前記第３の層に従って各サブフレームにヘッダを追加する工程とを含む、請求項１に記載の発明。
【請求項５】
工程（ｂ）が、（ｂ１）前記第２の層に従って各対応するユーザ・データ・フレームにサブフレーム・ヘッダを追加することによって、前記１つまたは複数のユーザ・データ・フレームから１つまたは複数のサブフレームを形成する工程と、（ｂ２）送信特性に基づく既定の順序で、前記１つまたは複数のサブフレームをグループ化する工程と、（ｂ３）前記グループ化されたサブフレームへの記述子とを含む、請求項１に記載の発明。
【請求項６】
工程（ｂ３）の前記記述子が、フレームのタイプを示す集約フレーム・ヘッダと、ＡＤＵのサブフレームの個数と、前記２つ以上のサブフレームの少なくとも１つのサブフレーム記述子とを含む集約フレーム記述子である、請求項５に記載の発明。
【請求項７】
工程（ｂ３）の前記集約フレーム・ヘッダが、フレームのタイプが集約フレームであることを示すフレーム制御フィールドを含む、請求項６に記載の発明。
【請求項８】
工程（ｂ３）の各サブフレーム記述子が、前記関連づけられたサブフレームを受信する装置に対応するアドレスと、前記関連づけられたサブフレームの位置を識別する位置情報とを含む、請求項６に記載の発明。
【請求項９】
工程（ｂ２）が、前記１つまたは複数のサブフレームをあるユーザ・データ・レートに各々が対応しているサブグループにグループ化する、請求項６に記載の発明。
【請求項１０】
工程（ｂ２）の前記送信特性が、ユーザ・データ・レートと宛先アドレスとの少なくとも一方である、請求項６に記載の発明。
【請求項１１】
集約データのフレームを生成する方法であって、
（ａ）複数の集約フォーマットのうちの１つに基づき、１つまたは複数のユーザ・データ・フレームを集約ユーザ・データに関連づける工程と、
（ｂ）集約層で、前記集約ユーザ・データに少なくとも１つのヘッダを追加することによって、前記集約ユーザ・データから１つまたは複数のサブフレームを生成する工程と、
（ｃ）前記１つまたは複数のサブフレームから集約フレームを形成する工程と
を含む方法。
【請求項１２】
工程（ａ）が、ｉ）受信機アドレスと、ｉｉ）前記１つまたは複数の各ユーザ・データ・フレームのデータ・レートとのうちの少なくとも一方に従って前記１つまたは複数のユーザ・データ・フレームを集約ユーザ・データに関連づける、請求項１１に記載の発明。
【請求項１３】
工程（ａ）が、同一の受信機アドレスを有する前記１つまたは複数のユーザ・データ・フレームを前記集約データに関連づけ、さらに前記方法が、（ｄ）アップリンク・チャネルを介して前記集約フレームを送信する工程を含む、請求項１２に記載の発明。
【請求項１４】
工程（ｄ）の前記アップリンク・チャネルが、モバイル送信機からアクセス・ポイントの受信機への通信チャネルである、請求項１３に記載の発明。
【請求項１５】
工程（ａ）が、少なくとも２つの異なる受信機アドレスを用いて２つ以上のユーザ・データ・フレームを前記集約データに関連づけ、さらに前記方法が、（ｄ）ダウンリンク・チャネルを介して前記集約フレームを送信する工程を含む、請求項１２に記載の発明。
【請求項１６】
工程（ｄ）の前記ダウンリンク・チャネルが、アクセス・ポイントの送信機から１つまたは複数のモバイル受信機への通信チャネルである、請求項１５に記載の発明。
【請求項１７】
工程（ａ）が、同一の受信機アドレスおよび同一のデータ・レートを有する前記１つまたは複数のユーザ・データ・フレームを選択する工程を含む、請求項１２に記載の発明。
【請求項１８】
工程（ａ）が、同一のデータ・レートを有する前記１つまたは複数のユーザ・データ・フレームを選択する工程を含む、請求項１２に記載の発明。
【請求項１９】
工程（ａ）が、同一の受信機アドレスを有する前記１つまたは複数のユーザ・データ・フレームを選択する工程を含む、請求項１２に記載の発明。
【請求項２０】
工程（ａ）が、前記１つまたは複数のユーザ・データ・フレームを選択する工程を含み、各データ・フレームが、複数の受信機アドレスのうちの１つに対応するアドレス、および複数のデータ・レートのうちの１つに対応するデータ・レートを有する、請求項１２に記載の発明。
【請求項２１】
工程（ａ）の前記データ・レートが、対応するデータ・フレームの物理層データ・レートである、請求項１２に記載の発明。
【請求項２２】
工程（ｂ）が、ｉ）集約フレームを識別するための集約フレーム・ヘッダと、ｉｉ）サブフレームの個数を含むフィールドと、ｉｉｉ）対応するデータ・フレームを受信する装置のアドレスを含む少なくとも１つの記述子とを追加する工程を含む、請求項１１に記載の発明。
【請求項２３】
工程（ｂ）が、集約層で前記１つまたは複数のサブフレームを生成し、工程（ｃ）が、物理層で前記１つまたは複数のサブフレームから前記集約フレームを形成する、請求項１１に記載の発明。
【請求項２４】
前記集約層がＭＡＣ層内にある、請求項２３に記載の発明。
【請求項２５】
前記集約層が物理層内にある、請求項２３に記載の発明。
【請求項２６】
前記集約層がＭＡＣ層と物理層の間にある、請求項２３に記載の発明。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信システムに関し、より詳細には、パケットベース・ネットワークにおけるデータ・フレームの集約に関する。
【背景技術】
【０００２】
本出願は、代理人整理番号Ｇｉｅｓｂｅｒｔｓ  ２−３  ＰＲＯＶとして２００３年１２月２３日に出願された米国特許仮出願第６０／５３２３２５号の出願日の利益を主張する。
【０００３】
本出願は、代理人整理番号Ｈｉｄｄｉｎｋ  ５−２−１として２００３年１２月２４日に出願された同時係属中の米国特許出願第１０／７４６１５３号の一部継続出願であり、その教示を参照により本明細書に組み込む。
【０００４】
本出願は、代理人整理番号Ｇｉｅｓｂｅｒｔｓ  ３−５として２００４年９月３０日に出願された米国特許出願第１０／９５５９４７号の関連出願であり、その教示を参照により本明細書に組み込む。
【０００５】
無線ローカル・エリア・ネットワーク（ＷＬＡＮ）は、一般に使用できるＷＬＡＮ  ＰＣカードを備えた携帯電話、ノートブック（ラップトップ）・コンピュータ、ハンドヘルド・コンピュータなど、１つまたは複数の固定／非固定位置のステーション（モバイル端末などのＳＴＡ）を含む。ＷＬＡＮ  ＰＣカードは、各ＳＴＡが、同一のサービス・エリア内にあるときだけではなく、異なるサービス・エリアにあるときにはネットワーク・サーバを介して相互に通信することを可能にする。ネットワーク・サーバは、異なるアクセス・ポイント（ＡＰ）によってサポートされる、異なるサービス・エリア内のＳＴＡ間の通信をサポートする。ＡＰは他のネットワークまたはサービス・エリアへの接続を提供する端末、またはその他の装置であり、固定とすることも非固定とすることもできる。基本サービス・セット（ＢＳＳ）は、ＳＴＡ間で、および／またはＡＰと１つまたは複数のＳＴＡの間で形成される。このようなＷＬＡＮネットワークを用いると、各ＳＴＡは特定のサービス・エリア内の各モバイル端末との間の物理的な接続を意識せずに、そのサービス・エリア内を移動することができる。
【０００６】
ＷＬＡＮネットワークの例には、ＩＥＥＥ（米国電気電子学会）８０２．１１委員会によって策定され提案された標準に準拠するネットワーク（本明細書では、１つまたは複数の版のＩＥＥＥ  ８０２．１１標準に従って動作するネットワークと呼ぶ）がある。一般に、このようなＷＬＡＮネットワークにおける同一サービス・エリア内のモバイル端末（すなわち、同一ＡＰに関連する端末）間で送信されるすべてのメッセージは、直接モバイル端末間で送信されるのではなく、アクセス・ポイント（ＡＰ）に送信される。このような集中化された無線通信は、通信リンクの単純化だけではなく、省電力化にも大きな利益をもたらす。
【０００７】
ほとんどのネットワークは一連の階層として組織化されており（階層ネットワーク・アーキテクチャ）、各層はその先行層の上に構築される。各層の目的は、上位層にサービスを提供するとともに、下位層の実装の詳細から上位層を遮断することである。隣接層の各ペアの間にはこれらのサービスを定義するインタフェースが存在する。最下位の各層は、データ・リンク層と物理層である。データ・リンク層の機能は、入力データをデータ・フレームに分割し、そのフレームを物理層を介して順に送信することである。各データ・フレームは、そのフレームの制御情報および順序情報を含むヘッダを有する。最下位である物理層の機能は、通信メディアを介してビット列を送信することである。
【０００８】
図１は、８０２．１１準拠のＷＬＡＮによるユーザ・データのための従来技術によるフレーミング・シーケンスを示す。図１に示したように、アプリケーション層１５０、伝送制御プロトコル（ＴＣＰ）層１５１、インターネット・プロトコル（ＩＰ）層１５２、論理リンク制御（ＬＬＣ）層１５３（データ・リンク層のサブ・レイヤ）、メディア・アクセス制御（ＭＡＣ）層１５４（これもまたデータ・リンク層のサブ・レイヤ）、および物理（ＰＨＹ）層１５５（物理層）として、６つのプロトコル階層が示されている。ユーザ・データ１０１はアプリケーション層１５０に提供され、アプリケーション層でアプリケーション層ヘッダ１１０が追加されてアプリケーション・データ１０２が生成される。アプリケーション・データ１０２はＴＣＰ層１５１に提供され、ＴＣＰ層でアプリケーション・データ１０２にＴＣＰ・ヘッダ１１１が追加されてＴＣＰセグメント１０３が形成される。ＩＰ層１５２ではＴＣＰセグメント１０３にＩＰヘッダ１１２が追加されてＩＰフレーム１０４が形成される。ＩＰフレーム１０４は代表的なＴＣＰ／ＩＰパケットであり、必ずしも８０２．１１に準拠しないものも含め、多くのデータ・ネットワーク・アプリケーションで共通に使用されている。
【０００９】
ＬＬＣ層１５３は、ＭＡＣ層１５４と上位層の間に統一されたインタフェースを提供して、ＴＣＰ／ＩＰパケットを送信するために使用されるＷＬＡＮのタイプの透過性を提供する。ＬＬＣ層１５３は、ＩＰフレーム１０４にＬＬＣヘッダ１１３としてこのインタフェース情報を追加してＬＬＣフレーム１０５を形成する。
【００１０】
８０２．１１準拠のＷＬＡＮでは、物理デバイスは無線機であり物理通信媒体は自由空間である。ＭＡＣデバイスおよびＰＨＹ層信号制御デバイスは、２つのネットワーク・ステーションが正しいフレーム・フォーマットおよびプロトコルで通信することを保証する。ＷＬＡＮの８０２．１１標準は、２つ（またはそれ以上の）ピアのＰＨＹデバイス間および関連するＭＡＣデバイス間の通信プロトコルを定義する。８０２．１１ＷＬＡＮデータ通信プロトコルによれば、ＭＡＣデバイスとＰＨＹデバイスの間で送信される各パケット・フレームは、ＰＨＹヘッダ、ＭＡＣヘッダ、ＭＡＣデータ、およびエラー・チェック・フィールドを有する。８０２．１１準拠ＷＬＡＮシステムのＭＡＣ層フレームの代表的フォーマットでは、ＬＬＣフレーム１０５にＭＡＣヘッダ１１４およびフレーム・チェック・シーケンス（ＦＣＳ）１１５を追加してＭＡＣフレーム１０６を形成する。ＭＡＣヘッダ１１４は、フレーム制御、継続時間識別番号（ＩＤ）、送信元（すなわちＭＡＣ層）および宛先アドレス、ならびにデータ・シーケンス制御（番号）の各フィールドを含む。ユーザ・データは大きなユーザ・データ・ストリームの一部なので、データ・シーケンス制御フィールドがシーケンス番号情報を提供して、受信機がデータ・シーケンス順序を再構築することを可能にする。
【００１１】
ＰＨＹ層１５５は、ＭＡＣフレーム１０６にＰＨＹヘッダを追加することによって物理層パケット・フレーム１０７を形成する。ＰＨＹヘッダ１１８は、プリアンブル１１６およびＰＬＣＰ（physical-layer convergence protocol）ヘッダ１１７を含む。ＰＬＣＰヘッダ１１７は、例えばＰＨＹ層のデータ・レートやデータ長を識別する。また、プリアンブル１１６は、ｉ）着信フレームを検出／同期し、ｉｉ）送信機と受信機の間のチャネル特性を推定するために受信装置によって使用される。
【００１２】
８０２．１１標準によるデバイス間の典型的な通信では、各ＭＡＣ層フレームは、最初の物理層フレームが送信された後のＳＩＦＳ（short interframe space）期間に送信されるＡＣＫメッセージ（またはＡＣＫフレーム）によって確認される。８０２．１１ｅ標準仕様では、確認応答メッセージがまったく送信されない「Ｎｏ−ＡＣＫ」など、いくつかの代替確認応答方法が指定されている。可能な他の方法には、１つのブロックＡＣＫメッセージで複数のデータ・フレームを確認できるブロックＡＣＫの変形形態がある。このブロックＡＣＫメッセージは、ブロックＡＣＫ要求の直後（即時ブロックＡＣＫ）または別のコンテンション期間の後（遅延ブロックＡＣＫ）に送信される。
【００１３】
所与の層で、８０２．１１ＷＬＡＮシステムの達成可能な最大スループットに影響を与える１つの要素は、（例えば、ユーザ・データ１０１などの）ペイロードを運ぶフレームの長さである。比較的良いチャネル品質の場合は、フレーム・サイズの増加に伴いスループット効率も向上する。スループット効率の向上は、その層のオーバヘッド（例えば、ヘッダ、チェックサムなど）が固定サイズであることに関連する。その理由は、フレーム・サイズが増加するに伴い、オーバヘッドとデータの比が低下するからである。従来技術の８０２．１１準拠のＷＬＡＮのなかには、各送信されるＰＨＹ層パケット・フレームがただ１つのＭＡＣフレームだけを含むものもある。ＭＡＣフレームは、プローブ要求フレームや確認応答フレームなどの制御または管理フレームであってもよい。他のＭＡＣフレームとしては、上位層ユーザ・データのただ１つのパケットだけを含むデータ・フレームであってもよい。ＭＡＣヘッダ・フィールドやＦＣＳフィールドはパケット・オーバヘッドに含まれる。
【特許文献１】米国特許仮出願第６０／５３２３２５号
【特許文献２】米国特許出願第１０／７４６１５３号
【特許文献３】米国特許出願第１０／９５５９４７号
【発明の開示】
【発明が解決しようとする課題】
【００１４】
ＩＥＥＥ  ８０２．１１プロトコルの効率は、高い物理層データ・レートが使用されたときに低下する。このことは、例えばプリアンブル、ＩＦＳ（inter-frame space）タイミング、ヘッダ情報など、ＰＨＹ層およびＭＡＣ層レベルのいくつかのオーバヘッド源によって引き起こされ、また確認応答パケットによっても引き起こされる。ＩＥＥＥ  ８０２．１１では、バースト・パケット送信やブロックＡＣＫメッセージングなど、効率を向上するためのいくつかの方法が提案されている。しかし、これらの方法を使用しても、１６２Ｍｂｉｔ／ｓ以上のＰＨＹ層レートの使用を効率的にすることはできない。
【００１５】
ＰＨＹ層において、オーバヘッドはＰＨＹフレーム・プリアンブルおよびＰＬＣＰヘッダによってもたらされるが、どちらも各ＭＡＣデータ・フレームに対して一定のサイズである。したがって、パケットあたりに運ばれるデータ量がより大きい場合には、メディアはより有効に使用されることになる。また、ＰＨＹ層フレーム・オーバヘッドは一般にサイズ（すなわち、バイト数）ではなく時間が一定なので、ＰＨＹ層フレーム・オーバヘッドはより高いデータ・ビット・レートとともに変化しない。送信される所与の量のユーザ・データに対するＰＨＹフレームの数を削減することで、大きな効率の向上がもたらされる。ＰＨＹ層オーバヘッドは、ユーザ・データの送信には直接関係しない（例えば、プローブ要求フレーム、ＲＴＳ／ＣＴＳフレーム、確認応答フレームなどの）ＭＡＣフレームを含む、送信される各ＭＡＣフレームごとに含まれるので、個別に送信されるＭＡＣフレームの数を削減することによって効率が向上する。ＰＨＹフレームの数を削減することはまた、ＭＡＣコンテンション・オーバヘッドを削減することにもなる。
【課題を解決するための手段】
【００１６】
本発明の実施形態によれば、パケット・ネットワークは、フレーム集約を使用して所与の量のユーザ・データを送信するために使用される物理層フレームの数を削減する。このパケット・ネットワークは、１つまたは複数の８０２．１１標準に従って動作する無線ローカル・エリア・ネットワーク（ＷＬＡＮ）の物理（ＰＨＹ）層とメディア・アクセス制御（ＭＡＣ）層を使用する。フレーム集約は、いくつかの個別の上位層フレームとユーザ・データや管理／制御データなどのデータとを１つのＰＨＹ層フレームに結合し、送信されるＰＨＹ層フレームあたりのユーザ・データの量を増やす。フレーム集約により、（例えば、プリアンブルおよびＰＬＣＰヘッダ・オーバヘッドなどの）ＰＨＹ層オーバヘッドおよび（例えば、コンテンション・オーバヘッドなどの）ＭＡＣオーバヘッドの両方が削減されることによって効率が向上する。
【００１７】
本発明の一例示的実施形態によると、集約データのフレームは（ａ）第１の層に従って１つまたは複数のユーザ・データ・フレームを集約ユーザ・データに結合し、（ｂ）集約層で、集約ユーザ・データに少なくとも１つのヘッダを追加することによって、集約ユーザ・データから各々が第２の層に従うフォーマットを有する１つまたは複数のサブフレームを生成し、（ｃ）第３の層に従って１つまたは複数のサブフレームから集約フレームを形成することによって生成される。
【００１８】
本発明の他の例示的実施形態によると、集約データのフレームは（ａ）複数の集約フォーマットのうちの１つに基づいて、１つまたは複数のユーザ・データ・フレームを集約ユーザ・データに結合し、（ｂ）集約層で、集約ユーザ・データに少なくとも１つのヘッダを追加することによって、集約ユーザ・データから１つまたは複数のサブフレームを生成し、（ｃ）１つまたは複数のサブフレームから集約フレームを形成することによって生成される。
本発明の他の態様、特徴、および利点は、以下の詳細な説明、別添の特許請求の範囲、および添付の図面からより完全に明らかになるであろう。
【発明を実施するための最良の形態】
【００１９】
本発明の例示的実施形態によると、フレーム集約によって、例えば所与の量のユーザ・データを送信するために使用される物理層フレームの数が削減される。本明細書で説明する例示的実施形態は、１つまたは複数のＩＥＥＥ  ８０２．１１標準によるシステムに関する。この標準は、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）の物理（ＰＨＹ）層およびメディア・アクセス制御（ＭＡＣ）層を定義するものである。しかし、当業者なら本明細書の教示を他のパケットベース通信ネットワークに適用できるはずである。本明細書に記載のように、論理リンク制御（ＬＬＣ）層、インターネット・プロトコル（ＩＰ）層、および伝送制御プロトコル／ユーザ・データグラム・プロトコル（ＴＣＰ／ＵＤＰ）層などの上位層は（例えば８０２．１１などの）下位層標準の制御の外に置くことができる。したがって本発明の例示的実施形態では、フレーム集約を使用してユーザ・データを含む個別の上位層フレームのいくつかを１つのＰＨＹレベル・フレームに結合することによって、送信するＰＨＹフレームあたりのユーザ・データ量を増加させる。フレーム集約では、（例えば、プリアンブルやＰＬＣＰヘッダのオーバヘッドなどの）ＰＨＹオーバヘッドおよび（例えば、コンテンション・オーバヘッドなどの）ＭＡＣオーバヘッドの両方を削減することによって効率を向上させる。
【００２０】
本発明の例示的実施形態によるフレーム集約では、以下のＡ）〜Ｃ）に対していくつかのフレームを集約することができる。すなわち、Ａ）同一の宛先アドレスを有し同一のＰＨＹ層データ・レートを有するフレーム、Ｂ）１つまたは複数の宛先アドレスを有し同一のＰＨＹ層データ・レートを有するフレーム、およびＣ）１つまたは複数の宛先アドレスを有し、それぞれのフレームがいくつかの可能なＰＨＹ層データ・レートのうちの１つを有するフレーム。
【００２１】
同一の宛先アドレスを有し、かつ同一のＰＨＹ層データ・レートを有するフレームを集約する場合を、本明細書では「ケースＡ」と呼ぶ。「ケースＡ」は、従来技術のＭＡＣ層およびＰＨＹ層の動作の変更を、ほとんどまたはまったく必要としないものであり、好ましくは、多数のフレームが同一の宛先アドレスを指定するときに使用できる。例えば、基本サービス・セット（ＢＳＳ）のアップリンク通信（トラフィック）には、一般にケースＡによるフレーム集約を使用することができる。
【００２２】
異なる宛先アドレスを有し、かつ同一のＰＨＹ層データ・レートを有するフレームを集約する場合を本明細書では「ケースＢ」と呼ぶ。「ケースＢ」は一般に、ステーション（ＳＴＡ）、または異なる宛先のＳＴＡにデータを送信するアクセス・ポイント（ＡＰ）によって使用される。しかし、フレームが１つのデータ・レートで送信されるので、好ましくは、異なる宛先ＳＴＡは同一のチャネル条件を有する。ケースＢでは、スケジューリング方法によって集約すべきフレームを選択し、送信をスケジュールする。このスケジューリング方法は、実施形態によっては異なる送信優先度を有するパケットを考慮することができる。
【００２３】
１つまたは複数の宛先アドレスを有し、かつ各々がいくつかの可能なＰＨＹ層データ・レートのうちの１つを有するフレームを集約する場合を、本明細書では「ケースＣ」と呼ぶ。「ケースＣ」は、より大きな柔軟性を提供し、一般にケースＡやケースＢのフレーム集約と比べて無線メディアのより高い使用効率を提供する。無線メディアのより高い使用効率は、すべてのフレームが随時最適のデータ・レートで送信できることによってもたらされる。
【００２４】
本発明の例示的実施形態によると、ＰＨＹ層およびＭＡＣ層に関してフレーム集約を論理的に配置することができる。第１にフレーム集約は、例えばＬＬＣ層とＭＡＣ層の間など、ＭＡＣ層の上位で（すなわち、ＭＡＣ層の動作の前に）実施することができる。第２にフレーム集約は、例えばＭＡＣ層とＰＨＹ層の間、またはＰＨＹ層内など、ＭＡＣ層の下位で実施することができる。第３にフレーム集約は、ＭＡＣ層自体の中で実施することができる。
【００２５】
ＭＡＣ層の上位でのフレーム集約はＭＡＣ層およびＰＨＹ層の動作の小変更をともなうが、例えば、ネットワーク装置に現在存在するソフトウェア・ドライバを更新することによって実現できる。既存のネットワーク装置に中間層を論理的に実装してフレーム集約を実施させることによって、ＭＡＣ層やＬＬＣ層の動作にほとんど、またはまったく変更を加えないようにすることもできる。例えば図２に示したように、ＬＬＣ層２１０のＬＬＣフレーム２０１（１）〜２０１（Ｎ）を、中間集約層２０３によってダミーＬＬＣフレーム２０２に結合することができる。ただし、Ｎは正の整数である。ダミーＬＬＣフレーム２０２はＭＡＣ層２０４に渡され、ＭＡＣ層でＭＡＣヘッダ２０５とＭＡＣ層ＦＣＳ２０６が追加されてＭＡＣフレーム２０７が形成される。ＰＨＹ層２０８では、ＭＡＣフレーム２０７にプリアンブル２０９およびＰＬＣＰヘッダ２１０が追加されてＰＨＹパケット２１１が形成される。
【００２６】
ＭＡＣ層の下位でのフレーム集約では、いくつかのＭＡＣフレームが１つのダミーＭＡＣフレームに形成され、次いでそれがＰＨＹ層によってパケット化される。ＭＡＣ層の下位のフレーム集約を用いると、各ＭＡＣフレームにフレーム・チェックサムなどのエラー検出情報が含まれるので他のフレームとは独立に各ＬＬＣフレームを検証することができる。フレーム・チェックサムは、ＬＬＣフレームに追加された、例えばＦＣＳフィールドなどのエラー制御フィールド中に置かれる。現在の８０２．１１準拠のＷＬＡＮシステムでは、ＭＡＣレベルでのエラー検出はサポートされるが、必ずしもエラー訂正まではサポートされない。しかし、当業者なら、単純なエラー検出の代わりに、当技術分野で既知のいくつかのエラー訂正方法のいずれかを使用することができるはずである。したがって本明細書に記載の例示的実施形態では、ｉ）エラー検出機能が使用されているのか、ｉｉ）エラー検出および訂正機能が使用されているのかを識別するために「エラー訂正／検出」という用語を使用する。また、個別のＭＡＣフレームは各々のヘッダおよび宛先アドレス情報付きで送信されるので、ＭＡＣフレームを別々の宛先に送信することもできる。図３は、本発明の第２の例示的実施形態によるＭＡＣ層の下位でのフレーム集約を示す。
【００２７】
ＬＬＣ層３０２のＬＬＣフレーム３０１（１）〜３０１（Ｍ）がＭＡＣ層３０５に渡される。ただし、Ｍは正の整数である。各ＬＬＣフレーム３０１（ｎ）は、ＭＡＣヘッダ３０３（ｎ）およびＭＡＣ  ＦＣＳ３０４（ｎ）が追加されてＭＡＣサブフレーム３１６（ｎ）の形に形成される。ＭＡＣサブフレーム３１６（１）〜３１６（Ｍ）は、ダミーＭＡＣフレーム３０６の形に結合される。次いで中間集約層３０７は、ダミーＭＡＣフレーム３０６にオプションの、ｉ）ダミー・ヘッダ３０８、および／またはｉｉ）転送エラー訂正／検出（ＦＥＣ）フィールド３０９を追加して集約ＭＡＣフレーム３１０を形成する。ＰＨＹ層３１１では、集約ＭＡＣフレーム３１０にプリアンブル３１３およびＰＬＣＰヘッダ３１４が追加されてＰＨＹパケット３１２が形成される。
【００２８】
図３には、オプションのダミー・ヘッダ３０８およびＦＥＣフィールド３０９が示されている。ダミー・ヘッダ３０８を使用して、ダミーＭＡＣフレーム３０６に含まれるＭＡＣサブフレーム３１６（１）〜３１６（Ｍ）の数（例えば、Ｍ）やサイズ（すなわち、長さ）を示すことができる。ＦＥＣフィールド３０９を使用して、受信機でビット・エラーを訂正することによってＭＡＣサブフレーム３１６（１）〜３１６（Ｍ）を正しく受信する確率を高めることもできる。あるいは、複数のＦＥＣフィールドを使用して、ダミーＭＡＣフレーム３０６の最後または各ＭＡＣフレーム３１６（１）〜３１６（Ｍ）の内部に追加することもできる。各ＭＡＣサブフレームが異なる宛先を有するときは、（例えば、遅延ＡＣＫ（delayed-ACK）メッセージ交換などの）修正された応答確認方法が使用される。
【００２９】
図４は、本発明の第２の例示的実施形態の代替実施形態によるＰＨＹ層内でのフレーム集約を示す。ＬＬＣ層４０２のＬＬＣフレーム４０１（１）〜４０１（Ｍ）がＭＡＣ層４０５に渡される。ＭＡＣ層４０５は、ＭＡＣヘッダ４０３（ｎ）およびＭＡＣ  ＦＣＳ４０４（ｎ）をＬＬＣフレーム４０１に追加してＭＡＣサブフレーム４０６（ｎ）を形成する。次いで、ＭＡＣサブフレーム４０６（１）〜４０６（Ｍ）がＰＨＹ層４０７に渡される。ＰＨＹ層４０７は、ＰＬＣＰヘッダ４０９（ｎ）を各対応するＭＡＣサブフレーム４０６（ｎ）に追加してＰＨＹサブフレーム４１０（ｎ）を形成する。ＰＨＹサブフレーム４１０（１）〜４１０（Ｍ）は連結され、連結されたＰＨＹサブフレームにプリアンブル４０８が追加されてＰＨＹパケット４１１が形成される。
【００３０】
図４に示したように、複数のＰＨＹフレームがプリアンブルを除いて連結されるので、個々のＭＡＣフレームを異なるデータ・レートで送信し、各ＭＡＣフレームを個別に受信することが可能になる。図４の実施形態のある実装では、比較的性能の劣るチャネル状況のＳＴＡが低いデータ・レートを正しく受信できるように、含まれるＭＡＣフレームをデータ・レートの昇順に並べることができる。
【００３１】
ＭＡＣ層内のフレーム集約は、本発明のフレーム集約と既存のＭＡＣ層動作を統合し、比較的大きな柔軟性を提供する。ＭＡＣ層内のフレーム集約によって、個別のＭＡＣフレームの検出も可能になる。ＭＡＣ層内のフレーム集約は、本発明によるＭＡＣ集約フレーム・フォーマットを含むことができる。このＭＡＣ集約フレーム・フォーマットは、いくつかの上位層データ・フレームをそれぞれ独立に受信しデコードすることができるような形に組み込んだものであり、このフォーマットを用いることで各上位層データ・フレームを異なる宛先の受信機に送信することが可能になる。さらに、ＭＡＣ層はＰＨＹ層の動作を制御するので、集約フレームの各部分を異なるＰＨＹデータ・レートで送信して、各フレームを所望のデータ・レートで送信することも可能にする。
【００３２】
図５は、本発明の第３の例示的実施形態によるＭＡＣ層内でのフレーム集約を示す。ＬＬＣ層５０２でＬＬＣフレーム５０１（１）〜５０１（Ｎ）が生成され、それがＭＡＣ層５０３に渡される。ＭＡＣ層５０３は、２つの動作を含む。すなわち、第１の動作では、ＬＬＣフレーム５０１（１）〜５０１（Ｎ）からＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）が生成される。第２の動作では、ＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）からＭＡＣフレーム５０７が生成される。ＭＡＣサブフレーム５０６（ｎ）は、１つまたは複数のＩＥＥＥ  ８０２．１１標準に従って、対応するＭＡＣヘッダ５０４（ｎ）およびＭＡＣ  ＦＣＳ５０５（ｎ）を追加することによって生成される。
【００３３】
ＭＡＣフレーム５０７は、ＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）をデータ・レートに従ってグループ化し、次いで先頭にＭＡＣ記述子５０８を追加することによって形成することができる。ＭＡＣ記述子５０８は、ＭＡＣフレーム５０７の残りの部分のインデックス情報を提供するフィールドである。ＭＡＣ記述子５０８はまた、ＭＡＣフレーム５０７内部の１つまたは複数のＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）の位置、長さ、および宛先を指定することもできる。含まれるＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）すべての宛先アドレスはＭＡＣフレーム５０７の先頭に配置されるので、受信機はＭＡＣ記述子５０８をデコードすることによって、含まれるＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）の１つまたは複数がその受信機に宛てられたものかどうかを判断することができる。受信機はこの情報を使用して、ＭＡＣサブフレームが見込めないときにはリスニング・モードを中断し、（例えば、使用電力を節約するなど）より効率的な動作をもたらすこともできる。
【００３４】
ＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）はデータ・レートごとにグループ化され、ＭＡＣフレーム部５０９、５１０、および５１１に連結される。図４に示した実施形態と同様に、悪いチャネル状況にある受信機が、低いデータ・レートのＭＡＣサブフレームを正しく受信できるように、ＭＡＣサブフレーム５０６（１）〜５０６（Ｎ）はデータ・レートの昇順に並べられる。したがって、好ましくは、ＭＡＣ記述子５０８は含まれる最も低いデータ・レートで送信される。図５の場合は、データ・レートＸ＜データ・レートＹ＜データ・レートＺである。
【００３５】
ＭＡＣフレーム５０７はＰＨＹ層５１２に渡され、そこでＰＨＹパケット５１８が形成される。ＰＨＹ層５１２は、ＭＡＣ記述子５０８とＭＡＣフレーム部５０９をグループにしてＰＨＹデータ・レートＸ部５１５を形成することによってＰＨＹパケット５１８を形成する。ＭＡＣフレーム部５１０および５１１はそれぞれ直接ＰＨＹデータ・レートＹ部５１６およびＺ部５１７にマップされる。ＰＨＹデータ・レートＸ部５１５、Ｙ部５１６、Ｚ部５１７は連結され、プリアンブル５１３およびＰＬＣＰヘッダ５１４が追加されてＰＨＹパケット５１８が生成される。
【００３６】
集約フレームが複数のデータ・レートで送信される場合、すなわち１つまたは複数のＭＡＣフレーム部が他と異なるデータ・レートで送信される場合は、フレームのどの部分にどのデータ・レートを使用すべきかについての情報をＰＬＣＰヘッダ５１４で運ぶことができる。ＰＬＣＰヘッダ５１４はＭＡＣフレーム５１８の前方（すなわち、プリアンブルの直後）に配置されるように示されているが、代替実施形態ではＰＬＣＰヘッダ・フィールドをそのＰＬＣＰヘッダ・フィールドに記載されたＭＡＣサブフレーム部の前、例えば各ＰＨＹデータ・レートＸ部５１５、Ｙ部５１６、およびＺ部５１７の直前に配置することもできる。
【００３７】
図２〜５の例示的実施形態の動作はコンピュータによってシミュレートすることが可能であり、メディア効率として測定された例示的実施形態の性能が様々な条件で示される。メディア効率は、ポイントツーポイント・リンクでの比較的理想的な条件下における達成可能な最大スループットを比較することによって図６〜８に示される。このシミュレーションに使用される条件は、ｉ）各交換シーケンスが、１つの集約フレームとその後に続く（ブロックＡＣＫではない）通常のＡＣＫフレームからなること、ｉｉ）１つの集約フレームに含まれる全てのデータ・フレームが同一のデータ・レート（例えば、５４−、２１６−、および３２４−Ｍｂｉｔ／ｓ）で送信され、全てのデータ・フレームが１５００ｂｙｔｅの大きさであること、ｉｉｉ）ＡＣＫフレームが５４Ｍｂｉｔ／ｓで送信され、正規の８０２．１１ａプリアンブルおよびＰＬＣＰヘッダを有し、かつ８０２．１１ａに定められた値と等価なタイミング（ＳＩＦＳ（short interframe space）、ＤＩＦＳ（distributed interframe space）、およびスロット・タイム）を使用すること、ｉｖ）コンテンションが、各フレーム交換ごとのあるスロットの「最適」値になるように選択されること、およびｖ）衝突およびビット／パケット・エラーがないことである。
【００３８】
図６、７、および８はそれぞれ、５４−Ｍｂｉｔ／ｓ、２１６−Ｍｂｉｔ／ｓ、および３２４−Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートに対する最大スループット対集約されたフレーム数を示す。図６、７、および８はそれぞれ、（塗りつぶしたひし形でＭＡＣ層集約が示される）図３、（塗りつぶした四角でＰＨＹ層集約が示される）図４、および（塗りつぶした三角でＭＡＣ（フレーム）記述子付きのＭＡＣ層集約が示される）図５に示された実施形態での最大スループットを示す。
【００３９】
図３のＭＡＣ層集約は、含まれるＭＡＣサブフレームをすべて追加の保護フィールド、フレーム記述子、またはＰＬＣＰヘッダなしで順次連結する。このシミュレーションでは、ダミー・ヘッダおよびＦＥＣフィールドは使用しない。使用した集約フォーマットは、ケースＡの単一宛先フレーム集約の場合を表す。図４のＰＨＹ層集約は、含まれるＭＡＣサブフレームがすべて各々のデータ・レートで送信されるので、このシミュレーションはケースＣの複数データ・レートの場合のフレーム集約を表す。図６〜８ではそれぞれ、ただ１つのデータ・レートだけが実際に使用される。フレーム記述子を使用する図５のＭＡＣ層集約は、ケースＢで、ただ１つのデータ・レートおよび（したがって、必然的に同一のデータ・レートを使用する）複数の宛先を使用する場合の集約を表す。図６〜８の各シミュレーションでは、ただ１つの宛先だけが使用される。
【００４０】
図６、７、および８に示されたシミュレーション結果は、より上位層のフレームが１つの集約フレームに結合されるほど最大スループットが高くなることを示す。また、集約できる上位層フレームの数が少ない場合には、特により高いＰＨＹ層データ・レートの場合に、最大スループットがかなり低下する。
【００４１】
宛先ステーションが異なるフレームを集約できる集約方法は、集約に使用できるフレームが増える可能性が高まるので、所望のスループットに達する可能性がより高くなる。送信されるフレームの各部分が異なるデータ・レートを有する集約方法により、高いメディア効率に達する可能性が高まる。その理由は、この方法により、集約されたフレームをまったく異なるチャネル条件を有するステーションに送信することが可能になり、したがって集約に多数のフレームを使用できる可能性が高まるからである。
【００４２】
達成可能な最大スループットは、集約に使用できるフレームの数に依存する。複数の宛先フレームを有するフレーム集約を用いると集約に使用できるフレームの数が増える。しかし、８０２．１１  ＷＬＡＮでは、一般にＢＳＳのＡＰは複数のＳＴＡに向けて送信するが、ＳＴＡは１つまたは２つのＡＰにだけ送信する。したがって、複数の宛先を用いるこのタイプのフレーム集約は、一般に複数のＳＴＡに向けて送信するＡＰ用として使用される。
【００４３】
したがって、ＳＴＡから各ＡＰへのアップリンク・トラフィックには、比較的簡単なフレーム集約の方法を使用できるので、１つの宛先（結果的に１つのＰＨＹ層データ・レート）を有するフレームだけを１つのフレームに集約することが可能になる。
【００４４】
図９〜１２は、数台のアクティブなＳＴＡを用いてシミュレートしたＢＳＳにおいて、いくつかの異なる構成に対する最大スループットを示したものである。図９〜１２のシミュレーション結果では、各ＳＴＡは異なるチャネル条件領域で動作し、したがって各ＳＴＡは異なるデータ・レートで動作する。ＡＰは、１５００バイトのデータ・フレームを各アクティブなＳＴＡに送信する。各ステーションはいくつかのダウンリンク接続を有しており、ＡＰは各接続ごとに、各交換シーケンスあたり一定数のフレームを提供する。各データ・フレームおよび各ＭＡＣ層確認応答は８０２．１１ａのＰＨＹ層フレーム・フォーマットに類似したフォーマットで送信されるが、拡張プリアンブル（＋１０μｓ）と拡張ＰＬＣＰヘッダ（＋４μｓ）を使用する。各シーケンスは、コンテンション用に３つのバックオフ・スロットを使用する。各ステーションは、各シーケンスごとにコンテンションあたり１つのＴＣＰ確認応答（６０バイト・サイズ）で応答（アップリンク）する。ビット／パケット・エラーおよび／または衝突は考慮されない。即時ＡＣＫフレームが送信されるデータ・レートは、対応するデータ・フレームの１／２．２５倍である。ブロックＡＣＫメッセージおよびブロックＡＣＫ要求メッセージは対応するデータ・フレームと同一のデータ・レートで送信される。
図９〜１２では、以下の７つの方法がシミュレートされ比較される。
【００４５】
第１の方法は、現在の８０２．１１標準に従うもので、集約を使用しない（すなわち、各ＰＨＹ層パケット・フレームは単一のＭＡＣフレームを含む）。この方法は、アップリンクおよびダウンリンク送信のどちらにも標準の即時ＡＣＫメッセージを使用する。このＡＣＫメッセージは、各データ・フレームの後、ＳＩＦＳ期間の経過後に送信される。
【００４６】
第２の方法は、集約即時ＡＣＫ（aggregated immediate ACK）を用いた単一宛先の集約を使用する。この集約即時ＡＣＫは、標準の即時ＡＣＫメッセージの拡張バージョンである。第２の方法では、ＡＰは、単一のステーション宛てのすべてのデータ・フレームを１つの集約フレームに結合する。ＳＴＡはＳＩＦＳ期間の後に集約即時ＡＣＫで応答する。アップリンク・チャネル（ＴＣＰ−ＡＣＫ）では集約無しのデータ・フレームを使用し、ＡＰは標準の即時ＡＣＫメッセージで応答する。
【００４７】
第３の方法は単一宛先の集約を使用するが、アップリンクおよびダウンリンクのどちらの送信方向にもブロックＡＣＫメッセージを使用する。ブロックＡＣＫメッセージおよびブロックＡＣＫ要求メッセージは、８０２．１１ｅに指定されているように、アップリンク方向およびダウンリンク方向のどちらの場合も集約フレームに含まれる。
【００４８】
第４の方法は、単一ＰＨＹデータ・レートの集約を使用する。この場合、アップリンクは集約即時ＡＣＫメッセージを使用し、ダウンリンクはブロックＡＣＫメッセージを使用する。第４の方法では、ＡＰは、同一ＰＨＹ層データ・レートを有するＳＴＡのすべてのデータ・フレームを（複数の宛先を有する）１つの集約フレームに結合する。
【００４９】
第５の方法は、第４の方法に類似した単一レートの集約を使用するが、アップリンクおよびダウンリンクのどちらの送信方向にも遅延ブロックＡＣＫ（delayed Block-ACK）メッセージを使用する。どちらの方向についても、ブロックＡＣＫ要求メッセージおよびブロックＡＣＫメッセージは集約フレームに含まれる。
【００５０】
第６の方法はマルチレート集約を使用する。この場合、アップリンク・チャネルは集約即時ＡＣＫメッセージを使用し、ダウンリンク・チャネルはブロックＡＣＫメッセージを使用する。第６の方法では、ＡＰは、図５のフォーマットを使用して、すべてのＰＨＹ層データ・レートに対するフレームを１つの集約フレームに結合する。各データ・レートごとに追加のＰＬＣＰヘッダが含まれるので、データ・レートの切換が可能になる（ＰＬＣＰヘッダは、各フレームごとではなく、各レートごとにのみ含まれる）。
【００５１】
第７の方法は、第６の方法に類似したマルチレート集約を使用する。ただし、アップリンクおよびダウンリンク・チャネル方向のどちらにも遅延ブロックＡＣＫメッセージを使用する。
【００５２】
図９は、データ・フレームが３２４Ｍｂｉｔ／ｓ、即時ＡＣＫメッセージ・フレームが１４４Ｍｂｉｔ／ｓの同一ＰＨＹ層データ・レートでそれぞれ動作する３台のＳＴＡを用いたＢＳＳのシミュレーション結果を示す。各ＳＴＡは１つのＴＣＰ接続を有し、各接続ごとに各集約フレームあたり３フレームを含む（すなわち、ＡＰは各サイクルの間に各ステーションに３フレームを送信する）。各ＳＴＡは、各サイクルごとに１つのＴＣＰ  ＡＣＫメッセージ・フレーム（すなわち、３つのダウンリンク・フレームごとに１つのＡＣＫ）で応答する。
【００５３】
図１０は、各ＳＴＡが異なるＰＨＹ層データ・レートで動作すること以外は図９の構成と同じ場合のシミュレーション結果を示す。すなわち、１台のＳＴＡが３２４Ｍｂｉｔ／ｓ（１４４Ｍｂｉｔ／ｓのＡＣＫメッセージ・レート）で動作し、１台のＳＴＡが２１６Ｍｂｉｔ／ｓ（９６Ｍｂｉｔ／ｓのＡＣＫメッセージ・レート）で動作し、１台のＳＴＡが１０８Ｍｂｉｔ／ｓ（４８Ｍｂｉｔ／ｓのＡＣＫメッセージ・レート）で動作する場合である。
【００５４】
図１１は、各ＰＨＹ層データ・レートごとに３台のＳＴＡが動作し、計９台のＳＴＡが存在することを除けば、図１０と同じ構成の場合のシミュレーション結果を示す。
図１２は、各ＳＴＡが３つの接続をサポートすること、従ってＡＰが各サイクルごとに各ステーションあたり９つのフレームを送ることを除けば、図１１と同じ構成の場合のシミュレーション結果を示す。
図９〜１２に示したように、フレーム集約により、変化するチャネル条件下でのシステム性能に中程度から大幅な改善がもたらされる。
【００５５】
本発明に従って、次に例示的集約フレーム・フォーマットを説明する。この集約フレーム・フォーマットを用いると、複数の宛先に対して複数のフレームを集約することが可能になる。この例示的集約フレーム・フォーマットは同一のＰＨＹ層データ・レートを有するフレームに対して説明されるが、当業者なら本明細書の教示を、例えば図５に示した例示的な第３の実施形態など、複数のデータ・レートを含む複数の宛先用のフレーム集約フォーマットに拡張できるはずである。
【００５６】
本明細書で説明する例示的集約フレーム・フォーマットは、例えばフレーム集約を使用する装置とネットワークで共存する８０２．１１準拠の装置との相互運用が可能である。本明細書で説明するＰＨＹ層データ・レートは５４−Ｍｂｉｔ／ｓよりも高いが、例示的集約フレーム・フォーマットは低いレート（例えば、８０２．１１ａ標準または８０２．１１ｇ標準のデータ・レート）でも使用可能であり、したがって既存のＭＡＣ層実装と互換にできる。
【００５７】
可能な最高のメディア効率を達成するために、この例示的集約フレーム・フォーマットを用いると、例えば異なる宛先へのデータ・フレーム、（ブロック）ＡＣＫフレーム、管理用フレームなどあらゆるタイプのＭＡＣフレームを１つのＰＨＹフレームに集約することが可能になる。省電力動作は、ＭＡＣフレームの宛先アドレスがすべてＰＨＹフレームの先頭に（すなわち、ＰＬＣＰヘッダに隣接して）配置されるときに達成できる。受信装置（例えば、ＳＴＡ）によるトータルのリスニング時間を削減するために、最も多くのフレームが含まれる宛先アドレスがフレームの最後に来るように宛先アドレスが並べられる。
【００５８】
集約フレーム（少なくともその一部）を正しく検出する可能性を高めるために、（例えば、ＭＡＣサブフレームの長さを示すフィールドなど）集約フレーム中にオフセットを提供する、集約フレーム中のフィールドの数は比較的少ない。さらに、好ましくは、ビット・エラーまたはパケット・エラーによる弊害は、含まれるＭＡＣサブフレームの数が増えてもあるいはフレームのトータル長が長くなっても増加しない。
【００５９】
図１３はＰＨＹ層パケット１３０１の例示的集約フレーム・フォーマットである。パケット１３０１は、プリアンブル１３０２、ＰＬＣＰヘッダ１３０３、集約データ・ユニット（ＡＤＵ）１３０４、テイル（tail）・フィールド１３０５、およびオプションのパッド・ビット１３０６を含む。集約データ・ユニット（ＡＤＵ）１３０４はまた、ＰＬＣＰサービス・データ・ユニット（ＰＳＤＵ）とも呼ばれる。図１３の集約フレーム・フォーマットは、図５の第３の例示的実施形態に従って生成されるＰＨＹ層パケットに使用することもできる。プリアンブル１３０２は、例えば８０２．１１標準に基づくパケット検出に使用されるパターンである。プリアンブル１３０２を同期用に使用して、無線ゲインを決定し、クリアなチャネル・アセスメントを確立することができる。テイル・フィールド１３０５はＰＨＹ層パケット１３０１の終了を示す６ビットのパターンであり、このパターンを使用して受信機のViterbiデコーダをリセットすることができる。オプションのパッド・ビット１３０６は、ＰＨＹ層パケット１３０１の長さを送信の既定値に合わせるために使用することができる。
【００６０】
ＰＬＣＰヘッダ１３０３は、信号フィールド１３４０、サービス・フィールド１３４１、およびオプションの予約フィールド１３４２を含む。信号フィールド１３４０は、レート・フィールド１３４３、オプションの予約フィールド１３４４、長さフィールド１３４５、パリティ・フィールド１３４６、およびテイル１３４７を含む。レート・フィールド１３４３はペイロードが送信されるレートを指定するために使用される。信号フィールド１３４０中の予約フィールド１３４４は、集約フレーム記述子１３１０（後述）に追加して、あるいはそれとは別に集約フレームの使用を指示するために使用できる。ただし、他の用途にも使用できる。長さフィールド１３４５は、（ビットの形で）次のペイロードの長さを指定する。パリティ・フィールド１３４６はＰＬＣＰヘッダ１３０３のビットを検証するために使用される（例えば、パリティ・チェック値などの）エラー訂正／検出値を含む。テイル・フィールド１３４７は信号フィールドの終わりを示す。また、このフィールドを使用して受信機のViterbiデコーダをリセットすることもできる。サービス・フィールド１３４１は現在予約されたフィールドであり、このフィールドを使用して８０２．１１標準の送信機のスクランブラをリセットすることができる。オプションの予約フィールド１３４２は、例えば追加のＰＬＣＰ情報および／または追加のプリアンブル構造など、追加のＴＧｎ情報のために予約されている（ＴＧｎすなわちタスク・グループｎとは、そのグループのメンバが８０２．１１ｎシステムの仕様を検討し採用するグループのことである）。
【００６１】
ＡＤＵ１３０４は、集約フレーム記述子１３１０および集約ＭＡＣサブフレーム１３１１（１）〜１３１１（Ｎ）、およびオプションの集約ＦＣＳ１３１２を含む。ＭＡＣサブフレーム１３１１（ｎ）は、ＭＡＣデータ１３１５（ｎ）に追加されたＭＡＣ（フレーム）ヘッダ１３１４（ｎ）およびＭＡＣ  ＦＣＳ１３１６（ｎ）を含む。この場合、ＭＡＣデータ１３１５（ｎ）はＬＬＣ層から集約されたｎ番目のＩＰフレームとすることもできる。ＭＡＣヘッダ１３１４（ｎ）およびＭＡＣ  ＦＣＳ１３１６（ｎ）は、１つまたは複数の８０２．１１標準に従って生成されたＭＡＣヘッダおよびＭＡＣフレーム・チェックサムとすることもできる。ＭＡＣサブフレーム１３１１（１）〜１３１１（Ｎ）はＰＨＹ層データ・レートの昇順に、あるいは選択されたデータ・レートに対応するグループの形で配置することができ、またデータレート・グループそのものはＰＨＹデータ・レートの昇順に並べることができる。
【００６２】
集約フレーム記述子１３１０は、ＭＡＣ（集約フレーム）ヘッダ１３１７、フレーム個数フィールド１３１８、（集約フレーム）ＦＣＳ１３１９、および記述子１３２０（１）〜１３２０（Ｎ）を含む。集約フレーム記述子１３１０は、通常ＡＤＵ１３０４の前部に配置され、ＭＡＣヘッダ１３１７によって、ＰＨＹ層パケット１３０１が集約フレームであることを示す。
【００６３】
ＭＡＣヘッダ１３１７はフレーム制御フィールド１３３０、継続時間１３３１、アドレス・フィールド１（ＡＤＤＲ１）１３３２、アドレス・フィールド２（ＡＤＤＲ２）１３３３、アドレス・フィールド３（ＡＤＤＲ３）１３３４、およびシーケンス制御フィールド１３３５を含む。図１４は、図１３の例示的集約フレーム・フォーマットによって使用されるＭＡＣヘッダ１３１７を示す。図１４に示したようにフレーム制御フィールド１３３０は、プロトコル・バージョン・フィールド１４０１、タイプ・フィールド１４０２、サブタイプ・フィールド１４０３、ＴｏＤＳフィールド１４０４、ＦｒｏｍＤＳフィールド１４０５、ＭｏｒｅＦｒａｇフィールド１４０６、Ｒｅｔｒｙフィールド１４０７、Ｐｗｒ  Ｍｇｔフィールド１４０８、Ｍｏｒｅ  Ｄａｔａフィールド１４０９、ＷＥＰフィールド１４１０、およびＯｒｄｒフィールド１４１１を含む。
【００６４】
プロトコル・バージョン・フィールド１４０１は、２ビット長であり、ＰＨＹ層パケット１３０１に使用される８０２．１１標準のバージョンを示す。タイプ・フィールド１４０２およびサブタイプ・フィールド１４０３は、それぞれ２および４ビット長であり、集約フレーム１３０４のタイプを指定するために使用される。この指示は、（例えば、０１など）プロトコル・バージョンの新しい値、または（例えば、タイプ００（管理フレームを示す）でサブタイプ１１１１（集約フレーム記述子を示す）、またはタイプ１１でサブタイプ００００など）新しい（サブ）フレーム・タイプとして実装できる。あるいは、この指示は既存のプロトコル・バージョンおよびフレーム・タイプとしても実装できるが、（例えば、マルチキャスト・アドレスなど）特別の宛先アドレスを使用すること、またはフレーム記述子の宛先アドレスをフレームの発信元のアドレスに設定することができる。
【００６５】
残りのＴｏＤＳフィールド１４０４、ＦｒｏｍＤＳフィールド１４０５、ＭｏｒｅＦｒａｇフィールド１４０６、Ｒｅｔｒｙフィールド１４０７、Ｐｗｒ  Ｍｇｔフィールド１４０８、Ｍｏｒｅ  Ｄａｔａフィールド１４０９、ＷＥＰフィールド１４１０、およびＯｒｄｒ（順序）フィールド１４１１はすべて１ビット長である。ＴｏＤＳフィールド１４０４およびＦｒｏｍＤＳフィールド１４０５は分散システム（ＤＳ）との通信を指示する。Ｍｏｒｅ  Ｆｒａｇフィールド１４０６は現在のＡＤＵ１３０４の後続のフラグメントを示すもので、好ましい実施形態では０に設定される。Ｒｅｔｒｙフィールド１４０７は再送を示しており、好ましい実施形態では０に設定される。ＰｗｒＭｇｔ（パワー・マネージメント）フィールド１４０８は、ＳＴＡが省電力モード（１に設定）なのかアクティブ・モード（０に設定）なのかを示す。Ｍｏｒｅ  Ｄａｔａフィールド１４０９は、いずれかのＡＤＵがこのステーションにバッファされる場合に１に設定される。ＷＥＰ（Wired equivalent privacy）フィールド１４１０は、フレーム本体の情報が８０２．１１標準に指定されているＷＥＰアルゴリズムで処理されている場合に１に設定される。Ｏｒｄｒ（順序）フィールド１４１１は、送信された順序を維持するためにフレームを厳密に順序通り並べなければならない場合に１に設定され、上位レベルに渡される。
【００６６】
図１３に戻って、継続時間フィールド１３３１は２バイト長であり、各フィールドの継続時間値、ＮＡＶ設定、およびその送信ステーションに関する識別情報を含む。アドレス・フィールドＡＤＤＲ１（１３３２）、ＡＤＤＲ２（１３３３）、およびＡＤＤＲ３（１３３４）はそれぞれ６バイト長であり、ＢＳＳ、宛先アドレス、送信元アドレス、ならびに受信機および送信機アドレスを識別する。シーケンス制御フィールド１３３５は２バイト長であり、２つのサブフィールド（図１３には図示せず）、すなわちフラグメント・ナンバーおよびシーケンス・ナンバーに分割されている。フラグメント・ナンバーは４ビット長であり、ＡＤＵがいくつのフラグメントに分割されたかを示す。シーケンス・ナンバー・フィールドは１２ビット長であり、ＡＤＵのシーケンス・ナンバーを指示する。シーケンス制御フィールド１３３５は例示的集約フレーム・フォーマットに従って制限されており、シーケンス・ナンバー・フィールドおよびフラグメント・ナンバー・フィールドはどちらもゼロに設定されている。ナンバー・フィールド１３１８は、集約フレーム中のＭＡＣサブフレーム１３１１（１）〜１３１１（Ｎ）の個数Ｎを識別する。また、ＦＣＳフィールド１３１９の値は、（例えば、最初の２４＋２バイト分のチェックサムなど）集約フレーム記述子１３１０のチェックサム値である。
【００６７】
ＦＣＳフィールド１３１９の後に記述子フィールド１３２０（１）〜１３２０（Ｎ）が続き、このフィールドはそれぞれＭＡＣサブフレーム１３１１（１）〜１３１１（Ｎ）の１つに関連している。記述子フィールド１３２０（ｎ）は、ＭＡＣサブフレーム１３１１（ｎ）が宛てられた受信装置を識別するための宛先ＭＡＣ（Ｄｅｓｔ  Ａｄｄｒ）フィールド１３３６（ｎ）、ＡＤＵ１３０４におけるＭＡＣサブフレーム１３１１（ｎ）のスタート位置を識別するためのフレーム開始（ｓｔａｒｔ  ｆｒｍ）フィールド１３３７、ＭＡＣサブフレーム１３１１（ｎ）の長さを識別するためのフレーム長さ（ｌｅｎｇｔｈ  ｆｒｍ）フィールド１３３８（ｎ）、および記述子フィールド１３２０（ｎ）のＣＲＣ値であるＦＣＳフィールド１３３９（ｎ）を含む。フレーム長さフィールド１３３８（ｎ）の例示的フォーマットを図１５に示す。１２ビットの長さ（ｌｅｎｇｔｈ）フィールド１５０１はＭＡＣサブフレームの長さを示し、予約（ｒｓｖｄ）フィールド１５０２は将来の使用のために予約された４ビットの位置を含む。各記述子フィールドおよび各ＭＡＣサブフレームは各々のＦＣＳフィールドを有するので、ＭＡＣパケット・エラーの可能性は集約されたフレームの数には関係しない。
【００６８】
ＭＡＣサブフレーム１３１１（ｎ）はＭＡＣヘッダ１３１４（ｎ）、ＭＡＣデータ１３１５（ｎ）、およびＭＡＣ  ＦＣＳ１３１６（ｎ）を含む。ＭＡＣヘッダ１３１４（ｎ）は、継続時間フィールド（図１３には示さず）の値を集約フレーム記述子１３１０の継続時間フィールドの値と同じ値に設定することを除いて、フレーム集約なしの８０２．１１標準によるＭＡＣヘッダとすることができる。また、実施形態によっては、（例えば、即時ＡＣＫを求める要求が認められないなど）ＱｏＳ（サービス品質）ヘッダ拡張が制限されることがある。ＭＡＣデータ１３１５（ｎ）は、例えばＩＰパケットやＬＬＣフレームなど、ＭＡＣサブフレーム１３１１（ｎ）のペイロードであり、ＭＡＣ  ＦＣＳ１３１６（ｎ）は、ＭＡＣサブフレーム１３１１（ｎ）のＭＡＣヘッダ１３１４（ｎ）からＭＡＣデータ１３１５（ｎ）全体にわたって計算されたＣＲＣ値である。
【００６９】
オプションの集約ＦＣＳフィールド１３１２は、ＡＤＵ１３０４全体のチェックサム値を含む。後方互換性（backward-compatibility）が必要な場合には、オプションの集約ＦＣＳフィールド１３１２を含めることができる。集約フォーマットをサポートしない装置は、オプションの集約ＦＣＳフィールド１３１２を使用して着信ＡＤＵのエラーを検出し、可能ならば訂正することができる。集約フレーム・フォーマットをサポートする装置は、集約ＦＣＳフィールドを捨てなければならない。
【００７０】
例示的集約フォーマットを有するパケットを形成した後、送信装置（例えば、ＡＰまたはＳＴＡ）は無線メディアを介してＰＨＹ層パケットを送信し、このＰＨＹ層パケットは受信装置（例えば、ＡＰまたはＳＴＡ）によって検出される。ｉ）この受信装置がフレーム集約の実施形態をサポートしていない可能性があり、ｉｉ）この受信装置が所期の宛先ではない可能性があり、またｉｉｉ）受信したＰＨＹ層パケットには１つまたは複数のエラーが含まれている可能性があるので、集約フレーム・フォーマットを含むパケットの検出に際して、受信装置は１つまたは複数の以下の動作を実施することができる。
【００７１】
図１６は、受信装置がフレーム集約をサポートしている場合の例示的な受信方法を示す。ステップ１６０１で、受信装置は、ｉ）プリアンブルを検出し、ｉｉ）ＰＬＣＰヘッダをデコードし、ｉｉｉ）集約フレーム記述子のフレーム制御フィールドがフレーム集約タイプを指示していることを判断する。ステップ１６０２で、ソース・アドレス（Ａｄｄｒ２）および継続時間フィールドの値が後での使用のために格納される。実施形態によっては、ステップ１６０２で集約フレーム記述子のシーケンス番号を捨てることもできる。ステップ１６０３で、Ａｄｄｒ３フィールドのＢＳＳＩＤの値がこの受信装置のＢＳＳＩＤの値と比較される。
【００７２】
ステップ１６０３で、Ａｄｄｒ３フィールドのＢＳＳＩＤの値がこの受信装置のものとマッチしないと判断された場合は、ステップ１６０４で、集約フレームの第１の部分のＦＣＳフィールドがフレームのＣＲＣと照合され検証される。ステップ１６０４で、ＦＣＳフィールドが検証された場合は、ステップ１６０５でＮＡＶ（Network Allocation Vector）の値を継続時間フィールドの値に設定し、ステップ１６０６に進む。ステップ１６０４でＦＣＳフィールドが検証されなかった場合は、ステップ１６０９でＥＩＦＳ（extended interframe space）が設定され、ステップ１６０６に進む。ステップ１６０６で、集約フレームの残りの部分が捨てられる。
【００７３】
ステップ１６０３で、Ａｄｄｒ３フィールドのＢＳＳＩＤの値がこの受信装置のものとマッチしていると判断された場合は、ステップ１６０７で、フレーム本体のこの２バイトを使用してフレーム記述子の宛先アドレスの数を取り出す。ステップ１６０８で、集約フレームの最初の部分のＦＣＳフィールドがフレームのＣＲＣと照合され検証される。ステップ１６０８で、集約フレーム記述子の最初の部分のＦＣＳフィールドが検証されなかった場合には、ステップ１６０９でＥＩＦＳが設定される。ステップ１６０６で、集約フレームの残りの部分が捨てられる。ステップ１６０７で、集約フレーム記述子の最初の部分のＦＣＳフィールドが検証された場合は、ステップ１６１０で、ＮＡＶが継続時間フィールドの格納値に設定される。
【００７４】
ステップ１６１１で、個別の（ＭＡＣ）記述子フィールドが、後で図１７に関して説明する方法で順に処理される。ステップ１６１１で、対応するＦＣＳフィールドの検証によってＭＡＣサブフレームのエラーの有無が検査され、必要な場合にはＭＡＣサブフレームのエラー検出／訂正が処理される。受信装置が、集約フレーム・フォーマットを有するパケットの受信中にエラーを検出したとき、いくつかの異なる動作を行うことができる。プリアンブルまたはＰＬＣＰヘッダ内でエラーが検出された場合は、全体の集約フレームを捨てることができる。フレーム記述子の最初の部分に１つまたは複数のビット・エラーが発生した場合は、全体の集約フレームを捨てることができる。一方、集約フレーム記述子の最初の部分が有効な場合には、他のすべてのサブフレームが個別に処理される（すなわち、記述子フィールドの１つまたはＭＡＣサブフレームの１つに、１つまたは複数のビット・エラーが発生した場合には、破損したＭＡＣサブフレームだけが失われる）。
【００７５】
ステップ１６１２で、この受信装置が集約フレーム中のフレームの少なくとも１つの宛先になっているかどうかが、集約フレーム記述子中で検出された宛先アドレスから判断される。ステップ１６１２で、この受信装置が所期の宛先ではないと判断された場合は、ステップ１６０６に進む。ステップ１６０６の後で、この受信装置は継続中の送信の残りの時間に（着信するＭＡＣサブアドレスの検出およびデコードをせずに）省電力モードに入ることもできる。
【００７６】
ステップ１６１２で、この受信装置が所期の宛先であると判断された場合は、ステップ１６１３で、受信装置は各ＭＡＣサブフレームの開始バイトおよび長さを格納する。
ステップ１６１４で、最初のサブフレーム位置が取り出される。ステップ１６１５で、そのサブフレーム位置のＭＡＣサブフレームが取り出され、ＭＡＣサブフレームのデコードが開始される。例えば、第１および第２のＭＡＣサブフレームがこの受信装置に送信された場合、受信装置はフレーム記述子の終了（すなわち、最後の記述子フィールドの終了）まで待ち、第１のフレームのデコードを開始する。このＭＡＣサブフレームの最初のバイトの位置はまた、図１３および１４の例示的集約フレーム・フォーマットに関して先に説明したように、関連する記述子フィールドの開始フィールドによって指示することもできる。
【００７７】
ステップ１６１６で、ＭＡＣサブフレームのＦＣＳが正しいかどうかが検証される。ステップ１６１６でＭＡＣサブフレームのＦＣＳが正しいと判断された場合には、ステップ１６１７でＭＡＣサブフレーム・データ（ペイロードまたはＬＬＣフレーム）がＬＬＣ層に渡される。ステップ１６１６で、ＭＡＣサブフレームのＦＣＳが正しくない（すなわち、ＣＲＣチェックの失敗によって正しくない）と判断された場合は、ステップ１６１８でこのＭＡＣサブフレームは捨てられる。ステップ１６１９で、受信装置は他のＭＡＣサブフレームが処理可能かどうかを判断する。ステップ１６１９で、他のＭＡＣサブフレームが使用可能であると判断された場合には、ステップ１６２０で受信装置は、次のＭＡＣサブフレームのＭＡＣ記述子のなかの関連する開始フィールドを使用して、パケット中の次のＭＡＣサブフレームの位置を見つけて取り出す。ステップ１６２０から、この方法はステップ１６１５に戻る。
【００７８】
ステップ１６１９で、これ以上使用可能なＭＡＣサブフレームがないと判断された場合は、この受信装置に宛てられた最後のＭＡＣサブフレームが処理されたのでステップ１６２１で終了する。この受信装置は、継続中の送信の残りの期間に、（例えば、残りの着信ＭＡＣサブフレームの検出およびデコードをせずに）何らかの形の省電力モードに入ることを決定することもできる。
【００７９】
図１７は、図１６のステップ１６１１で記述子フィールドを処理する例示的方法である。ステップ１７０１で始まり、個別の（ＭＡＣ記述子）フィールドが順に処理される。ステップ１７０１で、最初の記述子フィールドが取り出される。ステップ１７０２で、取り出された記述子フィールド（例えば、記述子フィールド１３２０（ｎ））に対して、そのサブフレームのＦＣＳフィールド（例えば、ＦＣＳフィールド１３３９（ｎ））が、取り出された記述子全体にわたるＣＲＣと照合され検証される。
【００８０】
受信装置が集約フレーム・フォーマットを有するパケットの受信中にエラーを検出したとき、いくつかの異なる動作が行われる。エラーがプリアンブル内またはＰＬＣＰヘッダ内で検出された場合は、集約フレームの全体を捨てることができる。フレーム記述子の最初の部分（すなわち、フレーム記述子のヘッダ、２バイトの「フレーム数」フィールド、または最初のＦＣＳフィールド）で１つまたは複数のエラーが発生した場合は、集約フレームの全体を捨てることができる。エラーが個別の記述子フィールド内で発生した場合は、その記述子を捨てることができる。エラーがＭＡＣサブフレーム内で発生した場合は、そのサブフレームを捨てることができる。
【００８１】
ステップ１７０２でサブフレームのＦＣＳフィールドが正しいと検証された場合には、ステップ１７０３で受信装置はその記述子内の情報（例えば、宛先アドレスやサブフレームの長さ）を使用できる。ステップ１７０２でＦＣＳが正しいと検証されなかった場合には、ステップ１７０４でその記述子フィールドの内容を捨てることができる。受信装置が引き続きエラーのないサブフレームを受信する可能性があるので、関連するサブフレームは必ずしも捨てる必要はない。ステップ１７０３および１７０４からステップ１７０５に進む。
【００８２】
ステップ１７０５で最後の記述子フィールドが処理されたかどうかが判断される。ステップ１７０５で最後の記述子フィールドがまだ処理されていないと判断されると、ステップ１７０６で次の記述子フィールドが取り出され、ステップ１７０２に戻る。ステップ１７０５で最後の記述子フィールドが処理されたと判断された場合は、図１６のステップ１６１２に進む。
【００８３】
ＡＰまたはＳＴＡ装置が、本発明の実施形態によるフレーム集約に従うフレーム・フォーマットのパケットを受信したが、そのＡＰまたはＳＴＡ装置がフレーム集約をサポートしていない場合には、受信装置はそのフレームを捨てることができる。例えば、受信装置がエラーなしでプリアンブルを検出しＰＬＣＰヘッダをデコードした場合、受信装置はＭＡＣフレームの先頭でフレーム記述子を検出する。受信装置は、（プロトコル・バージョンまたは（サブ）タイプ・フィールドから）このパケットのフレーム・タイプをサポートしていないことを判断する。実装に応じて、（受信機がＦＣＳフィールド値を検証している場合には）受信装置は継続時間（duration）フィールドを読み出し、それに応じて受信機のＮＡＶ（Network Allocation Vector）値を設定することができる。ＮＡＶはＣＣＡ（clear channel assessment）方法の一部であり、仮想チャネル・アセスメント（virtual channel assessment）を実装するために使用される。仮想チャネル・アセスメントを用いると、装置は（例えば、送信の間で）実際には無線メディアを占有していない場合でも占有していると主張することができ、それにより衝突の回数および影響を低減するのに役立つ。
【００８４】
本発明の例示的実施形態を方法またはブロック図に関して説明してきたが、本発明の機能は、回路としてのハードウェアの形でも、状態マシンの形でも、あるいはソフトウェア・プログラムの処理ステップとしてのデジタルドメインの形でも実装することができる。このようなソフトウェアは、例えば、デジタル・シグナル・プロセッサ、マイクロコントローラ、または汎用コンピュータで使用できる。
【００８５】
本発明は、上記の方法を実施するための方法または装置の形で実施できる。本発明はまた、フロッピ・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、または他のマシン可読の記憶メディアなど有形のメディア上で実施されたプログラム・コードの形でも実施できる。このプログラム・コードがコンピュータなどのマシンにロードされ実行されるとき、そのマシンは本発明を実施するための装置になる。本発明はまた、例えば、記憶メディアに格納されているか、それとも電気ワイヤもしくはケーブル、光ファイバ、または電磁放射など何らかの伝送メディアを介して送信され、マシンによってロードされかつ／または実行されるプログラム・コードの形でも実施できる。このプログラム・コードがコンピュータなどのマシンにロードされ実行されるとき、そのマシンは本発明を実施するための装置になる。汎用のプロセッサに実装されたときには、このプログラム・コード・セグメントは、そのプロセッサと結合して特定の論理回路と同様に動作する固有の装置を提供する。
【００８６】
本発明の特性を説明するために記載され図示された各要素の詳細、材料、および構成に関し、別添の特許請求の範囲に示された本発明の原理および範囲を逸脱することなく、当業者によって様々な変更がなし得ることがさらに理解されよう。
【図面の簡単な説明】
【００８７】
【図１】８０２．１１無線ローカル・エリア・ネットワーク（ＷＬＡＮ）標準に従うユーザ・データの、従来技術によるフレーミング・シーケンスを示す図である。
【図２】第１の例示的実施形態による、メディア・アクセス制御（ＭＡＣ）層より上位のフレーム集約を示す図である。
【図３】第２の例示的実施形態による、ＭＡＣ層より下位のフレーム集約を示す図である。
【図４】第２の例示的実施形態の代替実施形態によるＭＡＣ層より下位のフレーム集約を示す図である。
【図５】第３の例示的実施形態によるＭＡＣ層内でのフレーム集約を示す図である。
【図６】５４−Ｍｂｉｔ／ｓ物理（ＰＨＹ）層データ・レートにおける最大スループット対集約されたフレーム数を示す図である。
【図７】２１６−Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートでの最大スループット対集約されたフレーム数を示す図である。
【図８】３２４−Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートでの最大スループット対集約されたフレーム数を示す図である。
【図９】３２４−Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートで動作する３台のステーション（ＳＴＡ）を用いてシミュレートされた基本サービスセット（ＢＳＳ）の様々な集約方法に対する最大スループットを示す図である。
【図１０】それぞれ３２４−、２１６−、１０８−Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートで動作する３台のＳＴＡを用いてシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。
【図１１】３２４Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートで動作する３台のＳＴＡ、２１６Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートで動作する３台のＳＴＡ、および１０８Ｍｂｉｔ／ｓ  ＰＨＹ層データ・レートで動作する３台のＳＴＡを用いてシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。
【図１２】ＳＴＡあたり３接続とした以外は図１１に示されたと同様にシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。
【図１３】記載の実施形態による例示的な集約フレーム・フォーマットを示す図である。
【図１４】図１３の例示的な集約フレーム記述子によって使用されるＭＡＣヘッダ・フォーマットを示す図である。
【図１５】図１３のＭＡＣ層長さフィールドの例示的フォーマットを示す図である。
【図１６】受信装置がフレーム集約をサポートしている場合の、例示的な受信の方法を示す図である。
【図１７】図１６のステップ１６１１で、記述子フィールドを処理する例示的な方法を示す図である。
【図１】
2005184839.tif 000003
【図２】
2005184839.tif 000004
【図３】
2005184839.tif 000005
【図４】
2005184839.tif 000006
【図５】
2005184839.tif 000007
【図６】
2005184839.tif 000008
【図７】
2005184839.tif 000009
【図８】
2005184839.tif 000010
【図９】
2005184839.tif 000011
【図１０】
2005184839.tif 000012
【図１１】
2005184839.tif 000013
【図１２】
2005184839.tif 000014
【図１３】
2005184839.tif 000015
【図１４】
2005184839.tif 000016
【図１５】
2005184839.tif 000017
【図１６】
2005184839.tif 000018
【図１７】
2005184839.tif 000019