JP5177995B2

JP5177995B2 - フレーム集約

Info

Publication number: JP5177995B2
Application number: JP2006298599A
Authority: JP
Inventors: エス．ギースバーツピーター−ポール; エム．ヴァンリーウェンリチャード
Original assignee: Agere Systems LLC
Current assignee: Agere Systems LLC
Priority date: 2003-12-23
Filing date: 2006-11-02
Publication date: 2013-04-10
Anticipated expiration: 2024-12-20
Also published as: EP2408175A3; KR101154829B1; US20050152358A1; US20090141723A1; KR20050065387A; KR20060126862A; EP1548990A1; JP2007037196A; US8396064B2; JP2005184839A; EP2408175B1; KR101093084B1; JP4917750B2; EP2408175A2; US7489688B2

Description

本発明は通信システムに関し、より詳細には、パケットベース・ネットワークにおけるデータ・フレームの集約に関する。

本出願は、代理人整理番号Ｇｉｅｓｂｅｒｔｓ２−３ＰＲＯＶとして２００３年１２月２３日に出願された米国特許仮出願第６０／５３２３２５号の出願日の利益を主張する。

本出願は、代理人整理番号Ｈｉｄｄｉｎｋ５−２−１として２００３年１２月２４日に出願された同時係属中の米国特許出願第１０／７４６１５３号の一部継続出願であり、その教示を参照により本明細書に組み込む。

本出願は、代理人整理番号Ｇｉｅｓｂｅｒｔｓ３−５として２００４年９月３０日に出願された米国特許出願第１０／９５５９４７号の関連出願であり、その教示を参照により本明細書に組み込む。

無線ローカル・エリア・ネットワーク（ＷＬＡＮ）は、一般に使用できるＷＬＡＮＰＣカードを備えた携帯電話、ノートブック（ラップトップ）・コンピュータ、ハンドヘルド・コンピュータなど、１つまたは複数の固定／非固定位置のステーション（モバイル端末などのＳＴＡ）を含む。ＷＬＡＮＰＣカードは、各ＳＴＡが、同一のサービス・エリア内にあるときだけではなく、異なるサービス・エリアにあるときにはネットワーク・サーバを介して相互に通信することを可能にする。ネットワーク・サーバは、異なるアクセス・ポイント（ＡＰ）によってサポートされる、異なるサービス・エリア内のＳＴＡ間の通信をサポートする。ＡＰは他のネットワークまたはサービス・エリアへの接続を提供する端末、またはその他の装置であり、固定とすることも非固定とすることもできる。基本サービス・セット（ＢＳＳ）は、ＳＴＡ間で、および／またはＡＰと１つまたは複数のＳＴＡの間で形成される。このようなＷＬＡＮネットワークを用いると、各ＳＴＡは特定のサービス・エリア内の各モバイル端末との間の物理的な接続を意識せずに、そのサービス・エリア内を移動することができる。

ＷＬＡＮネットワークの例には、ＩＥＥＥ（米国電気電子学会）８０２．１１委員会によって策定され提案された標準に準拠するネットワーク（本明細書では、１つまたは複数の版のＩＥＥＥ８０２．１１標準に従って動作するネットワークと呼ぶ）がある。一般に、このようなＷＬＡＮネットワークにおける同一サービス・エリア内のモバイル端末（すなわち、同一ＡＰに関連する端末）間で送信されるすべてのメッセージは、直接モバイル端末間で送信されるのではなく、アクセス・ポイント（ＡＰ）に送信される。このような集中化された無線通信は、通信リンクの単純化だけではなく、省電力化にも大きな利益をもたらす。

ほとんどのネットワークは一連の階層として組織化されており（階層ネットワーク・アーキテクチャ）、各層はその先行層の上に構築される。各層の目的は、上位層にサービスを提供するとともに、下位層の実装の詳細から上位層を遮断することである。隣接層の各ペアの間にはこれらのサービスを定義するインタフェースが存在する。最下位の各層は、データ・リンク層と物理層である。データ・リンク層の機能は、入力データをデータ・フレームに分割し、そのフレームを物理層を介して順に送信することである。各データ・フレームは、そのフレームの制御情報および順序情報を含むヘッダを有する。最下位である物理層の機能は、通信メディアを介してビット列を送信することである。

図１は、８０２．１１準拠のＷＬＡＮによるユーザ・データのための従来技術によるフレーミング・シーケンスを示す。図１に示したように、アプリケーション層１５０、伝送制御プロトコル（ＴＣＰ）層１５１、インターネット・プロトコル（ＩＰ）層１５２、論理リンク制御（ＬＬＣ）層１５３（データ・リンク層のサブ・レイヤ）、メディア・アクセス制御（ＭＡＣ）層１５４（これもまたデータ・リンク層のサブ・レイヤ）、および物理（ＰＨＹ）層１５５（物理層）として、６つのプロトコル階層が示されている。ユーザ・データ１０１はアプリケーション層１５０に提供され、アプリケーション層でアプリケーション層ヘッダ１１０が追加されてアプリケーション・データ１０２が生成される。アプリケーション・データ１０２はＴＣＰ層１５１に提供され、ＴＣＰ層でアプリケーション・データ１０２にＴＣＰ・ヘッダ１１１が追加されてＴＣＰセグメント１０３が形成される。ＩＰ層１５２ではＴＣＰセグメント１０３にＩＰヘッダ１１２が追加されてＩＰフレーム１０４が形成される。ＩＰフレーム１０４は代表的なＴＣＰ／ＩＰパケットであり、必ずしも８０２．１１に準拠しないものも含め、多くのデータ・ネットワーク・アプリケーションで共通に使用されている。

ＬＬＣ層１５３は、ＭＡＣ層１５４と上位層の間に統一されたインタフェースを提供して、ＴＣＰ／ＩＰパケットを送信するために使用されるＷＬＡＮのタイプの透過性を提供する。ＬＬＣ層１５３は、ＩＰフレーム１０４にＬＬＣヘッダ１１３としてこのインタフェース情報を追加してＬＬＣフレーム１０５を形成する。

８０２．１１準拠のＷＬＡＮでは、物理デバイスは無線機であり物理通信媒体は自由空間である。ＭＡＣデバイスおよびＰＨＹ層信号制御デバイスは、２つのネットワーク・ステーションが正しいフレーム・フォーマットおよびプロトコルで通信することを保証する。ＷＬＡＮの８０２．１１標準は、２つ（またはそれ以上の）ピアのＰＨＹデバイス間および関連するＭＡＣデバイス間の通信プロトコルを定義する。８０２．１１ＷＬＡＮデータ通信プロトコルによれば、ＭＡＣデバイスとＰＨＹデバイスの間で送信される各パケット・フレームは、ＰＨＹヘッダ、ＭＡＣヘッダ、ＭＡＣデータ、およびエラー・チェック・フィールドを有する。８０２．１１準拠ＷＬＡＮシステムのＭＡＣ層フレームの代表的フォーマットでは、ＬＬＣフレーム１０５にＭＡＣヘッダ１１４およびフレーム・チェック・シーケンス（ＦＣＳ）１１５を追加してＭＡＣフレーム１０６を形成する。ＭＡＣヘッダ１１４は、フレーム制御、継続時間識別番号（ＩＤ）、送信元（すなわちＭＡＣ層）および宛先アドレス、ならびにデータ・シーケンス制御（番号）の各フィールドを含む。ユーザ・データは大きなユーザ・データ・ストリームの一部なので、データ・シーケンス制御フィールドがシーケンス番号情報を提供して、受信機がデータ・シーケンス順序を再構築することを可能にする。

ＰＨＹ層１５５は、ＭＡＣフレーム１０６にＰＨＹヘッダを追加することによって物理層パケット・フレーム１０７を形成する。ＰＨＹヘッダ１１８は、プリアンブル１１６およびＰＬＣＰ（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）を実装するために使用される。仮想チャネル・アセスメントを用いると、装置は（例えば、送信の間で）実際には無線メディアを占有していない場合でも占有していると主張することができ、それにより衝突の回数および影響を低減するのに役立つ。

本発明の例示的実施形態を方法またはブロック図に関して説明してきたが、本発明の機能は、回路としてのハードウェアの形でも、状態マシンの形でも、あるいはソフトウェア・プログラムの処理ステップとしてのデジタルドメインの形でも実装することができる。このようなソフトウェアは、例えば、デジタル・シグナル・プロセッサ、マイクロコントローラ、または汎用コンピュータで使用できる。

本発明は、上記の方法を実施するための方法または装置の形で実施できる。本発明はまた、フロッピ・ディスケット、ＣＤ−ＲＯＭ、ハード・ドライブ、または他のマシン可読の記憶メディアなど有形のメディア上で実施されたプログラム・コードの形でも実施できる。このプログラム・コードがコンピュータなどのマシンにロードされ実行されるとき、そのマシンは本発明を実施するための装置になる。本発明はまた、例えば、記憶メディアに格納されているか、それとも電気ワイヤもしくはケーブル、光ファイバ、または電磁放射など何らかの伝送メディアを介して送信され、マシンによってロードされかつ／または実行されるプログラム・コードの形でも実施できる。このプログラム・コードがコンピュータなどのマシンにロードされ実行されるとき、そのマシンは本発明を実施するための装置になる。汎用のプロセッサに実装されたときには、このプログラム・コード・セグメントは、そのプロセッサと結合して特定の論理回路と同様に動作する固有の装置を提供する。

本発明の特性を説明するために記載され図示された各要素の詳細、材料、および構成に関し、別添の特許請求の範囲に示された本発明の原理および範囲を逸脱することなく、当業者によって様々な変更がなし得ることがさらに理解されよう。

８０２．１１無線ローカル・エリア・ネットワーク（ＷＬＡＮ）標準に従うユーザ・データの、従来技術によるフレーミング・シーケンスを示す図である。第１の例示的実施形態による、メディア・アクセス制御（ＭＡＣ）層より上位のフレーム集約を示す図である。第２の例示的実施形態による、ＭＡＣ層より下位のフレーム集約を示す図である。第２の例示的実施形態の代替実施形態によるＭＡＣ層より下位のフレーム集約を示す図である。第３の例示的実施形態によるＭＡＣ層内でのフレーム集約を示す図である。５４−Ｍｂｉｔ／ｓ物理（ＰＨＹ）層データ・レートにおける最大スループット対集約されたフレーム数を示す図である。２１６−Ｍｂｉｔ／ｓＰＨＹ層データ・レートでの最大スループット対集約されたフレーム数を示す図である。３２４−Ｍｂｉｔ／ｓＰＨＹ層データ・レートでの最大スループット対集約されたフレーム数を示す図である。３２４−Ｍｂｉｔ／ｓＰＨＹ層データ・レートで動作する３台のステーション（ＳＴＡ）を用いてシミュレートされた基本サービスセット（ＢＳＳ）の様々な集約方法に対する最大スループットを示す図である。それぞれ３２４−、２１６−、１０８−Ｍｂｉｔ／ｓＰＨＹ層データ・レートで動作する３台のＳＴＡを用いてシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。３２４Ｍｂｉｔ／ｓＰＨＹ層データ・レートで動作する３台のＳＴＡ、２１６Ｍｂｉｔ／ｓＰＨＹ層データ・レートで動作する３台のＳＴＡ、および１０８Ｍｂｉｔ／ｓＰＨＹ層データ・レートで動作する３台のＳＴＡを用いてシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。ＳＴＡあたり３接続とした以外は図１１に示されたと同様にシミュレートされたＢＳＳの様々な集約方法に対する最大スループットを示す図である。記載の実施形態による例示的な集約フレーム・フォーマットを示す図である。図１３の例示的な集約フレーム記述子によって使用されるＭＡＣヘッダ・フォーマットを示す図である。図１３のＭＡＣ層長さフィールドの例示的フォーマットを示す図である。受信装置がフレーム集約をサポートしている場合の、例示的な受信の方法を示す図である。図１６のステップ１６１１で、記述子フィールドを処理する例示的な方法を示す図である。

Claims

各々がユーザ・データを含む複数のサブフレームについての集約フレームを生成する方法であって、
（ａ）２つもしくはそれより多くのサブフレームから集約データ・ユニット（ＡＤＵ）を形成するステップと、
（ｂ）集約フレームを生成するステップとを含み、
該集約フレームは、
（１）（i）フレームの種類を示す集約フレームヘッダと、（ii）該ＡＤＵのサブフレームの数を表す値と、（iii）該２つもしくはそれより多くのサブフレームの各々に関して、対応するサブフレームについての受信デバイスのアドレスを有するサブフレーム記述子とを含む集約フレーム記述子と、
（２）該ＡＤＵとを有し、
（i）該ＡＤＵの該２つもしくはそれより多くのサブフレームについての受信デバイスのアドレス及び（ii）該ＡＤＵの該２つもしくはそれより多くのサブフレームの各々の長さの指標は、該該集約フレーム内に、該２つもしくはそれより多くのサブフレームを有する該ＡＤＵの前方に配置されている、方法。
請求項１に記載の方法において、該集約フレームについてのエラー検出／訂正情報を有する集約エラー制御フィールドを、該ＡＤＵに対して追加するステップを、さらに含む方法。
請求項１に記載の方法において、
該ステップ（ａ）が、該サブフレームのデータ・レートに基づいて、該ＡＤＵ内の該サブフレームの各々の位置の順番を決めるステップを、さらに含む方法。
請求項１に記載の方法において、
該ステップ（ａ）について、各サブフレームが、サブフレーム・ヘッダおよびサブフレーム・データから成る方法。
請求項１に記載の方法において、
該ステップ（ａ）について、各サブフレームがサブフレームについてのエラー検出／訂正情報を有するサブフレーム・エラー制御フィールドをさらに含む方法。
請求項１に記載の方法において、
該ステップ（ｂ）について、
各サブフレーム記述子が、関連するサブフレームについての受信デバイスに対応するアドレスと、該集約フレーム内の関連するサブフレームの位置を識別する位置情報とから成り、および
各サブフレーム記述子が、該対応するサブフレームについてのエラー検出／訂正情報を有するエラー制御フィールドから成る、ものである方法。
受信デバイスによりパケットを処理する方法において、
（ａ）該パケットのフレーム・タイプを受信するステップと、
（ｂ）該フレーム・タイプが集約フレームである場合に、該パケットの２つもしくはそれより多くのサブフレームに対応する１つもしくはそれより多くの記述子を受信するステップであって、該１つもしくはそれより多くの記述子は、該２つまたはそれより多くのサブフレームの各々について、対応するサブフレームについての受信デバイスのアドレスを有する、ステップと、
（ｃ）各記述子について、該対応サブフレームが該受信デバイス用のものであるか否かを決定するステップと、
（ｄ）該受信デバイス用であると決定された各サブフレームについて、対応するデータフレームを抽出するステップと、を含み、
（i）該パケットの該２つもしくはそれより多くのサブフレームについての受信デバイスのアドレス及び（ii）該パケットの該２つもしくはそれより多くのサブフレームの各々の長さの指標は、該該集約フレーム内に、該２つもしくはそれより多くのサブフレームを有する該パケットの前方に配置されている、方法。
請求項７に記載の方法において、
該受信デバイス用であると決定された各サブフレームについて、該サブフレームに対応するエラー検出／訂正情報を確認するステップと、
該エラー検出／訂正情報に基づいて、１つもしくはそれより多くのエラーを訂正するステップと、をさらに含む方法。
請求項７に記載の方法において、
該ステップ（ｄ）が、該パケット中の該サブフレームの位置と長さを検出するステップから成る方法。
請求項１ないし９のうちのいずれか１項に記載される方法を遂行するよう働く装置。