JP2012522435A - 通信システムにおいて、ヘッダ情報を減少させるための方法およびシステム - Google Patents

Abstract

通信システムにおいて、オーバーヘッドを減少させるためのシステムおよび方法を開示する。異なるフレームが、単一の予約期間内での送信に適しているという決定に応答して、異なるフレームタイプを拡張集約フレーム中に集約する。
【選択図】 図１１

Description

関連出願への相互参照

本特許出願は、“ワイヤレス通信システムにおいて、ヘッダ情報を減少させるための方法およびシステム”と題し、２００９年３月２７日に出願され、本発明の譲受人に譲渡され、ここでの参照により明確にここに組み込まれている米国仮出願番号第６１／１６４，３１７号に対して優先権を主張する。

分野

本開示は、一般的に、通信ネットワークおよびシステムに関連している。さらに詳細には、本開示は、通信ネットワークおよびシステムにおいて、フレームまたはパケットに対するオーバーヘッドデータを減少させるためのシステムならびに方法に関連している。

背景

これらには限定されないが、音声と、ビデオと、マルチメディアと、パケットデータとを含む、さまざまな形態のデータを送信するために、多くの形態のワイヤレス通信システムおよびネットワークを使用する。このようなデータは、一般的に、ワイヤレス通信システムおよびネットワーク中の送信のために、“データフレーム”に分割される。例えば、送信機から受信機に送るデータファイルを複数のフレームに分割してもよい。その後、送信機から受信機にフレームを送信してもよい。いったん受信機がフレームのすべてを受信すると、受信機は、フレームを組み合わせてデータファイルを再構築してもよい。

さらに、通信システムおよびネットワークは、送信機と受信機との間の通信を維持および管理することを助ける、コマンド情報および／または制御情報を必要とするかもしれない。このようなコマンド情報および／または制御情報はまた、フレーム中に情報を置くことによって、送信および受信されてもよい。コマンド情報を含むフレームは、一般的に、“コマンドフレーム”として呼ばれる。“コマンドフレーム”という用語は、広く解釈すべきであり、これには限定されないが、デバイス間の通信を確立および維持するために使用するフレームを含むべきである。制御情報を含むフレームは、一般的に、“制御フレーム”として呼ばれる。“制御フレーム”という用語は、広く解釈すべきであり、これには限定されないが、デバイス間のデータフレームの配信を援助するフレームを含むべきである。一般的に、コマンドフレームおよび／または制御フレームは、長さにおいてデータフレームよりも短いことが多く、データフレームよりも小さいペイロードを有することが多い。

フレームの各タイプは、これらには限定されないが、プリアンブルと、ヘッダ情報と、誤り検査情報と、パディング情報とを有するフレーミング情報を含んでもよく、フレーム間スペーシングを必要としてもよい。フレームを送信、受信、デコード、および組み合わせるために、通信システムにより、このフレーミング情報を使用してもよい。コマンドフレームおよび／または制御フレームを別々のフレーム中で送信してもよい。フレームを送信することに関係する最小限のオーバーヘッドが存在することから、オーバーヘッドの量は、実際のコマンド情報または制御情報自体の量よりも大きいことがある。これにより、結果として、コマンドフレームおよび／または制御フレームを送信するときに、オーバーヘッドが無駄になることがある。したがって、コマンドフレームおよび／または制御フレームを送信するときのフレーミングオーバーヘッドを減少させることが望ましい。

概要

１つの実施形態では、開示は、通信システム中で情報を通信する方法を提供する。情報は、複数のフレームを含んでいてもよい。複数のフレーム中の各フレームは、ヘッダと本体とを含んでいてもよい。複数のフレームは、トランシーバすなわち送信機により送信されるように構成されていてもよい。方法は、トランシーバすなわち送信機により送信されるように構成されている異なるタイプの少なくとも２つのフレームを識別することを含む。方法は、第１の時間量内でトランシーバにより送信されることになる、少なくとも２つのフレームのそれぞれの少なくとも一部分を含む第１の集約フレームの可能性を決定することと、第１の集約フレームが、第１の時間量内での送信に適していると決定した場合に、トランシーバによる送信のために第１の集約フレームをフォーマットすることとをさらに含む。

別の実施形態では、方法は、集約フレームに集約ヘッダを置くことをさらに含む。別の実施形態では、方法は、異なるタイプの少なくとも２つのフレームの少なくとも一部分のそれぞれに、変更されたヘッダを置くことをさらに含む。別の実施形態では、変更されたヘッダは、短くしたヘッダである。また別の実施形態では、短くしたヘッダは、オリジナルヘッダよりも少ないビットを有する。また別の実施形態では、複数のフレームは、音声、ビデオ、および／または、物理的な物体または物質を表すデータを表す。別の実施形態では、複数のフレームはまた、データフレームに加えて、コマンドおよび／制御フレームを含む。

別の実施形態では、第１の集約フレームが、第１の時間量内での送信に適していない場合、方法は、第１の時間量よりも長い第２の時間量を規定することと、トランシーバによる第２の時間量内での送信のために第１の集約フレームをフォーマットすることとをさらに含み、集約フレームは、第２の時間量内での送信に適している。

別の実施形態では、複数のフレームの各フレームは、初めから、別々の時間量における送信のために構成されている。別の実施形態では、変更されたヘッダは、フレーム制御情報と、シーケンス制御情報と、セキュリティ情報とのうちの少なくとも１つを含む。

また別の実施形態では、異なるタイプの少なくとも２つのフレームのうちの第１のフレームは、データフレーム、コマンドフレーム、または制御フレームのうちの１つを含み、異なるタイプの少なくとも２つのフレームのうちの第２のフレームは、データフレーム、コマンドフレーム、または制御フレームのうちの異なる１つを含む。別の実施形態では、異なるフレームは、任意の順序で構成されていてもよい。

別の実施形態では、第１の時間量内で送信されることになる第１の集約フレームの可能性を決定することは、第１の集約フレームのヘッダの長さを決定することと、第１の集約フレームの本体の長さを決定することと、ヘッダの長さと本体の長さとを第１の時間量のサイズと相関させることとを含む。

また別の実施形態では、方法は、第１の時間量内でトランシーバにより送信されることになる、異なるタイプの少なくとも２つのフレームの可能性を決定することを含む。異なるタイプの少なくとも２つのフレームが、第１の時間量内の送信に適している場合、トランシーバによる第１の時間量内での送信のために、異なるタイプの少なくとも２つのフレームをフォーマットする。

別の実施形態では、異なるタイプの少なくとも２つのフレームが、第１の時間量内の送信に適していない場合、方法は、第１の時間量よりも長い第２の時間量内で送信されることになる、異なるタイプの少なくとも２つのフレームの可能性を決定することをさらに含む。異なるタイプの少なくとも２つのフレームが、第２の時間量内の送信に適している場合、方法は、トランシーバによる第２の時間量内での送信のために、異なるタイプの少なくとも２つのフレームをフォーマットすることをさらに含む。

図１Ａは、第１の例示的なワイヤレス通信ネットワーク１００を図示している。 図１Ｂは、第２の例示的なワイヤレス通信ネットワーク２００を図示している。 図２は、図１中に示されている例示的なワイヤレス通信デバイス１０６の機能ブロックダイヤグラムである。 図３は、図１中に示されている例示的なマクロノード１０２の機能ブロックダイヤグラムである。 図４は、ＥＣＭＡ−３６８標準規格に準拠する例示的なフレーム構造を図示している。 図５は、例示的なＭＡＣヘッダフォーマットを図示している。 図６は、図５中に示されているようなフレーム制御フィールドの例示的なフォーマットを図示している。 図７Ａは、データフレームとコマンドフレームとを送信する送信機すなわちトランシーバを図示している。 図７Ｂは、データフレームが、コマンドフレームとともに集約フレーム内に集約されている実施形態を図示している。 図７Ｃは、データフレームと制御フレームとを送信する送信機すなわちトランシーバを図示している。 図７Ｄは、データフレームが、制御フレームとともに集約フレーム中に集約されている実施形態を図示している。 図７Ｅは、データフレームと制御フレームとコマンドフレームとを送信する送信機すなわちトランシーバを図示している。 図７Ｆは、データフレームが、制御フレームとコマンドフレームとともに集約フレーム中に集約されている別の実施形態を図示している。 図７Ｇは、データフレームと制御フレームが、単一の予約内で送信されることがある実施形態を図示している。 図７Ｈは、データフレームが、制御フレームとともに集約フレーム中に集約されている実施形態を図示している。 図７Ｉは、データフレームとコマンドフレームが、単一の予約内で送信されることがある実施形態を図示している。 図７Ｊは、データフレームが、コマンドフレームとともに集約フレーム中に集約されている実施形態を図示している。 図７Ｋは、データフレームとコマンドフレームとコマンドフレームが、単一の予約内で送信されることがある実施形態を図示している。 図７Ｌは、データフレームが、コマンドフレームと制御フレームとともに集約フレーム中で集約されている実施形態を図示している。 図８は、１つの実施形態にしたがった、例示的な拡張集約ＥＣＭＡ−３６８フレーム構造を図示している。 図９は、ある実施形態にしたがった、図８の集約フレームのヘッダを図示している。 図１０は、１つの実施形態にしたがった、集約ＰＨＹフレーム中の短ＭＡＣヘッダを図示している。 図１１は、１つの実施形態にしたがった、異なるタイプのフレームを集約するための方法を図示しているフローチャートである。 図１２は、予約期間を拡張して、拡張した時間期間内に集約フレームを収めることができるようにするための方法を図示しているフローチャートである。 図１３は、高いサービスの品質（ＱｏＳ）をフレームが必要とするか否かを決定する別の実施形態を図示しているフローチャートである。 図１４は、ネットワークに、軽く負荷がかかっているか、または、重く負荷がかかっているかを決定する別の実施形態を図示しているフローチャートである。 図１５は、ＡＣＫを集約フレームが必要とするか否かを決定する別の実施形態を図示しているフローチャートである。 図１６は、集約することなく、フレームを予約期間内で送信することができるか否かを決定する別の実施形態を図示しているフローチャートである。

詳細な説明

“例示的な”という用語は、ここでは、“例として、インスタンスとして、または例証として機能すること”を意味するように使用している。“例示的な”としてここで記述した何らかの実施形態は、必ずしも、他の実施形態より好ましい、または、効果的であるとして解釈すべきではない。ここに記述した技術は、コード分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（ＯＦＤＭＡ）ネットワーク、単一搬送波ＦＤＭＡ（ＳＣ−ＦＤＭＡ）ネットワーク等のような、さまざまなワイヤレス通信ネットワークに対して使用できる。“ネットワーク”および“システム”という用語は、交換可能に使用することが多い。ＣＤＭＡネットワークは、ユニバーサル地上波無線アクセス（ＵＴＲＡ）、ｃｄｍａ２０００等のような、無線技術を実現してもよい。ＵＴＲＡは、広帯域−ＣＤＭＡ（Ｗ−ＣＤＭＡ）および低チップレート（ＬＣＲ）を含む。ＣＤＭＡ２０００は、ＩＳ−２０００、ＩＳ−９５、およびＩＳ−８５６の標準規格をカバーしている。ＴＤＭＡネットワークは、グローバルシステムフォーモバイルコミュニケーション（ＧＳＭ（登録商標））のような無線技術を実現してもよい。ＯＦＤＭＡネットワークは、進化ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、フラッシュ−ＯＦＤＭＡ等のような、無線技術を実現してもよい。ＵＴＲＡ、Ｅ−ＵＴＲＡ、およびＧＳＭは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）の一部である。ロングタームエボリューション（ＬＴＥ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳの次に出るリリースである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＧＳＭ、ＵＭＴＳ、およびＬＴＥは、“第３世代パートナーズシッププロジェクト”（３ＧＰＰ）という名称の機関からの文書中に記載されている。ＣＤＭＡ２０００は、“第３世代パートナーズシッププロジェクト２”（３ＧＰＰ２）という名称の機関からの文書中に記載されている。これらのさまざまな無線技術および標準規格は、技術的に知られている。

単一搬送波周波数分割多元接続（ＳＣ−ＦＤＭＡ）は、単一搬送波変調と周波数ドメイン等化技術とを利用する。ＳＣ−ＦＤＭＡは、ＯＦＤＭＡシステムと類似した性能および複雑性を有するが、その固有の単一搬送波構造のために、より低いピーク対平均電力比（ＰＡＰＲ）も有する。ＳＣ−ＦＤＭＡは、より低いＰＡＰＲが、送信電力効率の点で、移動体端末の大きな利益となるアップリンク通信エリアにおいて、特に、大きな関心を得ている。さらに、ＳＣ−ＦＤＭＡは、一般的に、３ＧＰＰロングタームエボリューション（ＬＴＥ）または進化ＵＴＲＡにおける、アップリンク多元接続スキームに対して実現する。

いくつかの態様では、マクロスケールカバレッジ（例えば、典型的にマクロセルネットワークと呼ばれる、第３世代（３Ｇ）ネットワークのような大きいエリアのセルラネットワーク）と、より小さいスケールカバレッジ（例えば、住宅ベースまたはビルディングベースのネットワーク環境）とを含むネットワーク中で、ここでの教示を用いてもよい。ワイヤレス通信デバイスがこのようなネットワークを通して移動するときに、ワイヤレス通信デバイスは、マクロカバレッジを提供するアクセスノードにより、あるロケーションにおいて担当されてもよい一方で、ワイヤレス通信デバイスは、より小さいスケールカバレッジを提供するアクセスノードにより、他のロケーションにおいて担当されてもよい。いくつかの態様では、インクリメントな容量の増加と、ビルディング内カバレッジと、異なるサービス（例えば、よりロバーストなユーザ経験）とを提供するために、より小さいカバレッジノードを使用してもよい。ここでの議論では、相対的に大きい地理的なエリアにわたるカバレッジを提供するノードを、マクロノードとして呼んでもよい。

フレーミングオーバーヘッドを償却して（例えば、減少させて、または、緩和させて）、メディアアクセス制御（“ＭＡＣ”）効率を増加させるために、ＭＡＣレイヤにおけるフレーム集約（例えば、別々フレームを集約フレームに組み合わせること）を使用してもよい。ある通信標準規格は、複数のＭＡＣサービスデータユニット（“ＭＳＤＵ”）を集約データフレーム中にパックする、データフレーム集約の方法を提供する。フレーミングオーバーヘッドを減少させて、ＭＡＣ効率性を増加させるための別の方法は、複数のデータＭＡＣプロトコルデータユニット（“ＭＰＤＵ”）を集約ＭＰＤＵ中にパックすることを含む。ここに記述したさまざまな実施形態および例は、数多くの通信システムまたはネットワークに適用可能であることを正しく認識するだろう。フレーム集約は、広く解釈すべきであり、これらには限定されないが、送信のための何らかの方法において、フレームを互いに隣接させて配置すること、フレームをインターリーブすること、フレームを組み合わせること、フレームを短くすること、または、フレームを修正することを含む。

一般的に、複数のＭＳＤＵまたはＭＰＤＵを集約するためのここで提示する方法は、フレームが、同じ送信機（例えば、発信元）アドレスと受信機（例えば、宛先）アドレスとの対間で送信されることになるときに適用可能である。しかしながら、送信機または受信機を使用することの代わりに、発信元と受信機との双方において、トランシーバを使用してもよい。したがって、下記において、送信機または受信機を述べるときはいつでも、トランシーバを交換可能に使用してもよいことを思い描くことになる。各ＭＰＤＵは、個々に肯定応答され、再送信されることがあるから、上述した第２の方法は、第１の方法に比べて利益を有するかもしれない。各連続したＭＰＤＵが、フレッシュな畳み込みデコーダ状態を持つフレッシュなインターリーバ境界上で開始する場合、ＭＰＤＵ中の誤りは分離されるかもしれない。高ビットレートを持つチャネルに対して、第１の方法におけるパケット誤りレートは、物理レイヤサービスデータユニット（“ＰＳＤＵ”）の長さとともに増加するかもしれない。ここでは、ＰＳＤＵにつき、１つのフレーム検査シーケンス（“ＦＣＳ”）のみが存在する。１つの例では、データフレームと、コマンドフレームと、制御フレームは、例えば、送信機すなわちトランシーバ上で、あるいは、送信機すなわちトランシーバにより動作するような、単一のアプリケーションから生じてもよい。別の例では、データフレームと、コマンドフレームと、制御フレームは、複数のアプリケーションから生じてもよい。

ある通信システムでは、上述した集約のための方法は、データフレームのみに適用する。これらのタイプの通信システムでは、上述した方法は、データフレームよりも短いことが多い、制御フレームまたはコマンドフレームに対する高いフレーミングオーバーヘッドの償却を取り扱わないかもしれない。フレーミングオーバーヘッドは、プリアンブルと、物理レイヤ収束プロトコル（“ＰＬＣＰ”）ヘッダと、フレーム間スペーシングとの何らかの組み合わせを含んでいてもよい。他の通信システム（例えば、８０２．１１ｎを使用する通信システム）では、異なるタイプのフレームを集約できるが、完全なＭＡＣヘッダが必要である。

ワイメディアＭＡＣ（例えば、ワイメディアにより規定されるＭＡＣレイヤ）を使用する通信システムにおいて、アクセスメカニズムのうちの１つは、分散予約プロトコル（“ＤＲＰ”）である。ＤＲＰにより、送信機すなわちトランシーバが、フレームを送信するための１つ以上のメディアアクセススロット（“ＭＡＳ”）を予約することを可能にしてもよい。例えば、いくつかの通信システムでは、１つのＭＡＳは２５６μｓである。これらの通信システムでは、コマンドフレームおよび／または制御フレームを送るために、別々の予約期間を使用してもよい。他の通信システムでは、データフレームと、コマンド／制御フレームとの双方を送信するために、単一の予約を使用してもよい。コマンドおよび／または制御フレームを交換するために、少なくとも１つのＭＡＳ（例えば、２５６μｓ）が予約されているそれらの通信システムでは、コマンドフレームおよび／または制御フレームは、一般的に、時間量において１つのＭＡＳもより短いので、スロット時間の少なくとも一部分は、未使用のままである。優先順位の付きコンテンション接続（“ＰＣＡ”）として知られているアクセスメカニズムは、未使用のスロット時間による無駄のうちのいくつかを減少させることができる。したがって、コマンドフレームおよび／または制御フレームに対する独立したＭＡＳの使用によって、結果として、高フレーミングオーバーヘッドと未使用のＭＡＳ時間とによりＭＡＣ容量が著しく無駄になるかもしれない。

ここに記述した機能は、ハードウェアで、ソフトウェアで、ファームウェアで、または、これらの任意の組み合わせで実現することができる。ソフトウェアで実現された場合、機能を、１つ以上の命令またはコードとして、コンピュータ読取可能媒体上に記憶させることができ、あるいは、コンピュータ読取可能媒体上で送信することができる。コンピュータ読取可能媒体は、１つの場所から別の場所へのコンピュータプログラムの転送を促進する何らかの媒体を含む、コンピュータ記憶媒体および通信媒体の双方を含む。記憶媒体は、汎用コンピュータまたは特殊用途コンピュータによりアクセスできる何らかの利用可能な媒体であってもよい。例として、これらに限定されないが、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭおよび他の光ディスク記憶装置、磁気ディスク記憶装置および他の磁気記憶デバイス、ならびに、特定用途向け集積回路（“ＡＳＩＣ”）のような、汎用または特定用途コンピュータ、もしくは、汎用または特定用途プロセッサによりアクセスでき、命令またはデータ構造の形態で所望のプログラムコード手段を伝送または記憶するために使用できる他の何らかの媒体を含む。また、任意の接続は、適切にコンピュータ読取可能媒体と呼ばれる。例えば、ソフトウェアが、同軸ケーブルや、光ファイバケーブルや、撚り対や、デジタル加入者線（“ＤＳＬ”）や、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバ、または他の遠隔ソースから送信された場合、同軸ケーブルや、光ファイバケーブルや、撚り対や、ＤＳＬや、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。ここで使用したようなディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（“ＣＤ”）、レーザディスク（登録商標）、光ディスク、デジタル汎用ディスク（“ＤＶＤ”）、フロッピー（登録商標）ディスク、ブルーレイディスク（登録商標）を含むが、一般的に、ディスク（ｄｉｓｋ）は、データを磁気的に再生する一方で、ディスク（ｄｉｓｃ）は、データをレーザによって光学的に再生する。上記のものの組み合わせも、コンピュータ読取可能媒体の範囲内に含めるべきである。

ある実施形態では、少なくとも１つの制御フレームおよび／またはコマンドフレームを、データフレームとともに集約してもよい。別の実施形態では、１つ以上の制御フレームを、１つ以上のコマンドフレームとともに集約してもよい。例えば、同じ送信機すなわちトランシーバと、受信機すなわち第２のトランシーバとのアドレス対が、制御フレームと、コマンドフレームと、データフレームとを交換するとき、対は、異なるフレームタイプにわたってＭＰＤＵを集約する利益を得ることができる。別の実施形態では、異なるフレームタイプにわたってＭＰＤＵを集約するために、ＰＬＣＰヘッダ内のＭＡＣヘッダのフレーム制御における、フレームタイプフィールドエンコーディングを修正してもよい。

さらに、フレームを集約すべきか否かを決定するために、フレームの他の態様を分析してもよい。１つの実施形態では、フレームが、待ち時間に関する高いサービスの品質（ＱｏＳ）を必要とする、すなわち、時間敏感である場合に、送信機すなわちトランシーバは、できるだけ素早くフレームをフラッシュアウトする必要性があるので、フレームを集約しない。別の実施形態では、集約フレームを送った後に、肯定応答（“ＡＣＫ”）が要求され、ＡＣＫに対応するための十分な時間が予約時間量内に存在しない場合、送信機すなわちトランシーバは集約フレームを送らないかもしれない。また別の実施形態では、ネットワークに軽く負荷がかかっている場合、無駄になったＭＡＳは何らかの悪影響がないことから、送信機すなわちトランシーバは、フレームを集約しないかもしれない。

図１Ａは、例示的なワイヤレス通信ネットワーク１００を図示している。図示されているワイヤレス通信ネットワークは、マクロノード１０２と、セル１０４と、ワイヤレス通信デバイス１０６と、別のワイヤレス通信デバイス１０８とを備えている。ワイヤレス通信ネットワーク１００は、多くのユーザ間での通信をサポートするように構成されている。ワイヤレス通信ネットワーク１００は１つのセル１０４のみを備えているように図示されているが、ワイヤレス通信ネットワークは、任意の数のセルを備えていてもよい。セル１０４中の通信カバレッジは、マクロノード１０２により提供されてもよく、マクロノード１０２は、例えば、基地局を含んでいてもよい。マクロノード１０２は、例えば、ワイヤレス通信デバイス１０６および１０８のような、複数のワイヤレス通信デバイスと対話してもよい。

ワイヤレス通信デバイスのそれぞれは、何らかの所定の瞬間において、フォワードリンク（“ＦＬ”）上で、および／または、リバースリンク（“ＲＬ”）上で、マクロノード１０２と通信してもよい。ＦＬは、マクロノードからワイヤレス通信デバイスへの通信リンクである。ＲＬは、ワイヤレス通信デバイスからマクロノードへの通信リンクである。マクロノード１０２は、例えば、適切なワイヤードまたはワイヤレスインターフェースにより、他のセル（この図面中では示されていない）中のマクロノードに相互接続してもよい。したがって、マクロノード１０２は、他のセル（この図面中では示されていない）中のワイヤレス通信デバイスと通信してもよい。

図１を継続して参照すると、近隣内のほんのいくつかのブロックのみにわたるサービスカバレッジ、または、地方環境における数平方マイルにわたるサービスカバレッジを、セル１０４は提供してもよい。各セルは、１つ以上のセクタ（この図面中には示していない）中にさらに分割されていてもよい。追加的なセルを含むことにより、ワイヤレス通信ネットワーク１００は、技術的によく知られているような大きな地理的領域にわたるサービスを提供してもよい。

ワイヤレス通信デバイス（例えば、１０６）は、通信ネットワークにわたって、音声またはデータを送受信するためにユーザによって使用する、何らかのワイヤレス通信デバイス（例えば、移動体電話機、ルータ、パーソナルコンピュータ、サーバ等）であってもよい。ワイヤレス通信デバイスは、アクセス端末（“ＡＴ”）として呼ばれることがあり、あるいは、ここでは、ユーザ機器（“ＵＥ”）として、移動局（“ＭＳ”）として、または、端末デバイスとして呼ばれることがある。示されているように、ワイヤレス通信デバイス１０６および１０８は、移動体電話機を含む。しかしながら、ワイヤレス通信デバイスは、何らかの適切な通信デバイスを含んでいてもよい。

ワイヤレス通信デバイス（例えば、１０６）にとって、ワイヤレス通信デバイス１０８、または、別のセル（この図面中には示していない）中のワイヤレス通信デバイスのような別のワイヤレス通信デバイスに情報を送信し、別のワイヤレス通信デバイスから情報を受信することが望ましいかもしれない。ワイヤレス通信デバイス１０６は、ワイヤレスリンクを通してマクロノード１０２と最初に通信することにより、これを達成してもよい。例えば、ワイヤレス通信デバイス１０６は、メッセージを発生させて、メッセージをマクロノード１０２に送信してもよい。マクロノード１０２は、その後、メッセージを発生させて、ワイヤレス通信デバイス１０８のような別のワイヤレス通信デバイスにメッセージを送信してもよい。メッセージは、さまざまなタイプの通信に関連する情報（例えば、音声、データ、マルチメディアサービス等）を含んでいてもよく、図４〜１５に参照して下記に詳細に議論する、１つ以上の集約フレームを含んでいてもよい。

図１Ｂは、第２の例示的なワイヤレス通信ネットワーク２００を図示している。図示したワイヤレス通信ネットワーク２００は、ワイヤレス通信デバイス１０６と、第２のワイヤレス通信デバイス２１０と、第３のワイヤレス通信デバイス２２０と、第４のワイヤレス通信デバイス２３０とを含む。ワイヤレス通信ネットワーク２００は、ワイヤレス通信デバイス１０６、２１０、２２０、および２３０のような、複数のデバイス間での通信をサポートするように構成されていてもよい。ワイヤレス通信デバイス（例えば、２１０、２２０）は、例えば、パーソナルコンピュータ、ＰＤＡ、音楽プレーヤー、ビデオプレーヤー、マルチメディアプレーヤー、テレビジョン、電子ゲームシステム、デジタルカメラ、ビデオカムコーダー、ウォッチ、遠隔制御装置、ヘッドセット等を含んでいてもよい。ワイヤレス通信デバイス１０６は、図１および２の双方中に図示されているが、ワイヤレス通信デバイス１０６は、ワイヤレス通信ネットワーク２００と、図１Ａのワイヤレス通信ネットワーク１００とに同時に通信する必要はない。

図１Ｂを継続して参照すると、ワイヤレス通信デバイス１０６は、さまざまな通信チャネルにわたって、他のワイヤレス通信デバイス（例えば、２１０、２２０）と通信してもよい。通信チャネルは、超広帯域（ＵＷＢ）チャネル、ブルートゥース（登録商標）チャネル、８０２．１１チャネル（例えば、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ）、赤外線（ＩＲ）チャネル、ＺｉｇＢｅｅ（登録商標）（８０２．１５）チャネル、または、技術的によく知られているような他のさまざまなチャネルを含んでいてもよい。１つの実施形態では、チャネルは、ＥＣＭＡ−３６８標準規格に準拠するＵＷＢチャネルであってもよい。

ワイヤレス通信ネットワーク２００は、ホーム、オフィス、またはビルディングのグループのような物理的エリアをカバーするワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を含んでいてもよい。ＷＬＡＮは、８０２．１１標準規格（例えば、８０２．１１ｇ）のような標準規格、および／または、ワイヤレス通信のための他の標準規格を使用してもよい。ＷＬＡＮは、ワイヤレス通信デバイスが互いに直接的に通信するピアツーピア通信を使用してもよい。ワイヤレス通信ネットワーク２００はまた、例えば、数メートルのエリアにまたがるワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を含んでいてもよい。ＷＰＡＮは、赤外線、ブルートゥース、ワイメディアベースのＵＷＢ標準規格（例えば、ＥＣＭＡ−３６８）、およびＺｉｇＢｅｅ標準規格、ならびに／あるいは、ワイヤレス通信のための他の標準規格を使用してもよい。ＷＰＡＮは、ワイヤレス通信デバイスが互いに直接的に通信するピアツーピア通信を使用してもよい。ワイヤレス通信ネットワーク２００は、ワイヤレス通信デバイス１０６のようなデバイスを通して、ワイヤレス通信ネットワーク１００またはインターネットのような別のネットワークと通信してもよい。

ワイヤレス通信ネットワーク２００を通して送られたメッセージは、さまざまなタイプの通信に関連する情報（例えば、音声、データ、マルチメディアサービス等）を含んでいてもよく、図４〜１５を参照して下記に詳細に議論する、集約フレームを含んでいてもよい。

下記の実施形態は、図１Ｂと、特に、ＥＣＭＡ−３６８標準規格とに言及するかもしれないが、これらはまた、図１Ａ中に示した通信システム１００と、他の通信標準規格とに適用可能であってもよい。例えば、１つの実施形態は、ＵＭＴＳ通信システム中で適用可能であってもよい。別の実施形態は、ＯＦＤＭＡ通信システム中で適用可能であってもよい。

ＥＣＭＡ−３６８標準規格は、超広帯域（ＵＷＢ）通信システムに対する、物理レイヤ（ＰＨＹ）と、メディアアクセス制御（ＭＡＣ）サブレイヤとを規定する。例えば、ＥＣＭＡ−３６８標準規格は、高速短距離ワイヤレスネットワーク中で使用してもよい。ＥＣＭＡ−３６８標準規格は、３１００〜１０，６００ＭＨｚ間の周波数スペクトルのすべて、または、一部を使用してもよく、４８０Ｍｂ／ｓまでのデータレート、または、むしろより高いデータレートをサポートしてもよい。ＥＣＭＡ−３６８標準規格は、スペクトルを１４帯域に分割する。それぞれの帯域は５２８ＭＨｚの帯域幅を持つ。ＥＣＭＡ−３６８標準規格は、マルチバンド直交周波数分割変調（ＭＢ−ＯＦＤＭ）スキームを使用して、情報を送信してもよい。さまざまなチャネル条件の下での最適な性能のために、周波数ドメイン拡散と、時間ドメイン拡散と、順方向誤り訂正（ＦＥＣ）コーディングとを提供する。

ＥＣＭＡ−３６８標準規格のＭＡＣサブレイヤは、デバイスのグループが、デバイスの他のグループにマージする間に、または、デバイスの他のグループから分かれる間に通信を続けることを可能にするかもしれない。このＭＡＣの機能性を、複数のデバイスの間に分散してもよい。これらの機能は、サービスの品質を保証する、チャネルと分散された媒体予約との適切な使用によって、デバイスの異なるグループ間での干渉を避ける分散調整を含む。ＥＣＭＡ−３６８のＭＡＣサブレイヤは、自己同期および非同期データ転送に対する、優先順位の付いたスキームを提供してもよい。搬送波感知多元接続（ＣＳＭＡ）と分割多元接続（ＴＤＭＡ）は、ＥＣＭＡ−３６８中でサポートされる２つの異なるアクセスメカニズムである。これらは、組み合わされていないとはいえ、ＣＳＭＡおよびＴＤＭＡの双方をサポートすることができる。ＥＣＭＡ−３６８標準規格のＭＡＣサブレイヤは、帯域幅の平等な共有を確実にしてもよい。

図２は、図１Ａおよび１Ｂ中に示した例示的なワイヤレス通信デバイス１０６の機能ブロックダイヤグラムである。上記で議論したように、ワイヤレス通信デバイス１０６は、移動体電話機であってもよい。ワイヤレス通信デバイス１０６は、記憶や送信のための情報、および／または、ワイヤレス通信デバイス１０６の他のコンポーネントの制御のための情報を処理するように構成されているプロセッサ２００を備えていてもよい。プロセッサ２００はさらに、メモリ２０４に結合されていてもよい。プロセッサは、メモリ２０４から情報を読み取り、または、メモリ２０４へ情報を書き込んでもよい。メモリ２０４は、処理の前に、処理の間に、または、処理の後に、メッセージを記憶するように構成されていてもよい。メモリ２０４はまた、図７〜１０を参照して下記にさらに詳細に議論するような、集約フレームを記憶してもよい。プロセッサ２００はまた、ワイヤレスネットワークインターフェース２０８に結合されていてもよい。ワイヤレスネットワークインターフェース２０８は、マクロノード（例えば、１０２）からインバウンドワイヤレスメッセージを受信し、マクロノードにアウトバウンドワイヤレスメッセージを送信するように構成されていてもよい。インバウンドワイヤレスメッセージは、処理のためにプロセッサ２００にパスされてもよい。プロセッサ２００は、１つ以上の集約フレームを処理してもよい。

プロセッサ２００は、アウトバンドワイヤレスメッセージを処理して、送信のために、アウトバンドワイヤレスメッセージをワイヤレスネットワークインターフェース２０８にパスしてもよい。加えて、図７〜１５を参照して下記に詳細に議論するように、プロセッサ２００は、集約するフレームを識別してもよく、それらを集約してもよい。プロセッサ２００はまた、メッセージインタープリタ２０６に結合されていてもよい。ワイヤレスネットワークインターフェース２０８において、マクロノード１０２から受信したインバンドワイヤレスメッセージは、プロセッサ２００にパスされて、その後、さらなる処理のために、プロセッサ２００によってメッセージインタープリタ２０６にパスされてもよい。メッセージインタープリタ２０６はまた、メッセージ解釈において使用するための情報を記憶させる、または、取り出すために、メモリ２０４に結合されていてもよい。メッセージインタープリタ２０６は、集約フレームを解釈してもよい。

プロセッサ２００はまた、メッセージフォーマッタ２０２に結合されていてもよい。メッセージフォーマッタ２０２は、ワイヤレスネットワークインターフェース２０８により送信されることになるアウトバウンドワイヤレスメッセージを発生させてもよく、または、フォーマットしてもよい。ワイヤレスネットワークインターフェース２０８によるマクロノード（例えば、１０２）への送信のために、ワイヤレスアウトバウンドメッセージは、メッセージフォーマッタ２０２によりプロセッサ２００にパスされてもよい。メッセージフォーマッタ２０２は、メッセージフォーマッティングにおいて使用するための情報を記憶させる、または、取り出すために、メモリ２０４に直接的に結合されていてもよい。図７〜１５を参照して下記に詳細に記述するように、メッセージフォーマッタ２０２は、既存のフレームから集約フレームを編成してもよく、および／または、集約フレームの一部である各フレームに、修正されたヘッダを挿入してもよい。

ワイヤレスネットワークインターフェース２０８は、アンテナ２０８ａとトランシーバ２０８ｂとを備えている。ワイヤレスネットワークインターフェース２０８はまた、畳み込みデコーダを備えていてもよい。トランシーバ２０８ｂは、マクロノード１０２に向かうアウトバウンド／インバウンドワイヤレスメッセージ、または、マクロノード１０２から来るアウトバウンド／インバウンドワイヤレスメッセージを変調／復調するように構成されていてもよい。アンテナ２０８ａは、アウトバウンド／インバウンドワイヤレスメッセージを送信／受信してもよい。アンテナ２０８ａは、１つ以上のチャネルを介して、マクロノード１０２と通信するように構成されていてもよい。アウトバウンド／インバウンドワイヤレスメッセージは、音声のみおよび／またはデータのみの情報（ここでは集合的に“データ”として呼ばれる）を含んでいてもよい。ワイヤレスネットワークインターフェース２０８は、受信したデータを復調してもよい。ワイヤレスネットワークインターフェース２０８は、ワイヤレスネットワークインターフェース２０８を通してワイヤレス通信デバイス１０６から送ることになるデータを変調してもよい。プロセッサ２００は、送信することになるデータを提供する。

メモリ２０４は、異なるレベルが、異なる容量およびアクセススピードを有するマルチレベル階層キャッシュを含む、プロセッサキャッシュを含んでいてもよい。メモリ２０４はまた、ランダムアクセスメモリ（“ＲＡＭ”）、他の揮発性記憶デバイス、または不揮発性記憶デバイスを含んでいてもよい。メモリ２０４を含む記憶デバイスは、ハードデバイスと、ＣＤまたはＤＶＤのような光ディスクと、フラッシュメモリと、フロッピーディスクと、磁気テープと、Ｚｉｐドライブとを含んでもよい。

別々に記述したが、ワイヤレス通信デバイス１０６に関して記述した機能ブロックは、別々の構造的エレメントである必要はないことを正しく認識するだろう。例えば、プロセッサ２００およびメモリ２０４は、単一のチップ中で具現化してもよい。プロセッサ２００は、加えて、または、代替実施形態において、プロセッサレジスタのようなメモリを備えていてもよい。同様に、機能ブロックの１つ以上のもの、または、さまざまなブロックの機能性の部分は、単一のチップ中で具現化してもよい。代替的に、特定のブロックの機能性は、２つ以上のチップ上で実現してもよい。

プロセッサ２００、メッセージインタープリタ２０６、およびメッセージフォーマッタ２０２のような、ワイヤレス通信デバイス１０６に関して記述した、機能ブロックの１つ以上のもの、および／または、機能ブロックの１つ以上の組み合わせは、汎用プロセッサ、デジタル信号プロセッサ（“ＤＳＰ”）、特定用途向け集積回路（“ＡＳＩＣ”）、現場プログラム可能ゲートアレイ（“ＦＰＧＡ”）または他のプログラム可能論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここに記述した機能を実行するように設計されているこれらの任意の適切な組み合わせとして、具現化してもよい。ワイヤレス通信デバイス１０６に関して記述した、機能ブロックの１つ以上のもの、および／または、機能ブロックの１つ以上の組み合わせはまた、例えば、ＤＳＰおよびマイクロプロセッサを組み合わせたものや、複数のマイクロプロセッサや、ＤＳＰ通信を伴う１つ以上のマイクロプロセッサや、その他の任意のこのようなコンフィギュレーションのような、コンピューティングデバイスの組み合わせたものとして実現してもよい。

図３は、図１中に示した例示的なマクロノード１０２の機能ブロックダイヤグラムである。図１に関して上述したように、マクロノード１０２は、基地局であってもよい。ワイヤレス通信デバイス１０６のような１つ以上のワイヤレス通信デバイスからインバウンドワイヤレスメッセージを受信し、ワイヤレス通信デバイス１０６のような１つ以上のワイヤレス通信デバイスにアウトバウンドワイヤレスメッセージを送信するように構成されているワイヤレスネットワークインターフェース３１０を、マクロノード１０２は備えていてもよい。ワイヤレスネットワークインターフェース３１０は、プロセッサ３００に結合されていてもよい。プロセッサ３００は、ワイヤレス通信デバイス１０６から来るアウトバウンドおよびインバウンドワイヤレスメッセージ、または、ワイヤレス通信デバイス１０６に向かうアウトバウンドおよびインバウンドワイヤレスメッセージを、ワイヤレスネットワークインターフェース３１０を通して処理するように構成されていてもよい。

プロセッサ３００はまた、マクロノード１０２の他のコンポーネントを制御するように構成されていてもよい。プロセッサ３００は、ワイヤードネットワークインターフェース３０８にさらに結合されていてもよい。ワイヤードネットワークインターフェース３０８は、他の宛先（例えば、他のマクロノード）からインバウンドワイヤードメッセージを受信し、他の宛先にアウトバウンドワイヤードメッセージを送信するように構成されていてもよい。ワイヤードネットワークインターフェース３０８は、インバウンドワイヤードメッセージを受信して、処理のために、インバウンドワイヤードメッセージをプロセッサ３００にパスしてもよい。プロセッサ３００は、アウトバウンドワイヤードメッセージを処理して、送信のために、アウトバウンドワイヤードメッセージをワイヤードネットワークインターフェース３０８にパスしてもよい。

プロセッサ３００は、１つ以上のバスを介して、メモリ３０４にさらに結合されていてもよい。プロセッサ３００は、メモリ３０４から情報を読み取ってもよく、または、メモリ３０４に情報を書き込んでもよい。メモリ３０４は、インバウンドまたはアウトバウンドの、ワイヤードまたはワイヤレスのメッセージを処理する際に使用するための情報を記憶するように構成されていてもよい。メモリ３０４は、異なるレベルが、異なる、容量およびアクセススピードを有するマルチレベル階層キャッシュを含む、プロセッサキャッシュを含んでいてもよい。メモリ３０２はまた、ランダムアクセスメモリ（“ＲＡＭ”）、他の揮発性記憶デバイス、または、不揮発性記憶デバイスを含んでいてもよい。記憶装置は、ハードデバイスと、コンパクトディスクＣＤまたはＤＶＤのような光ディスクと、フラッシュメモリと、フロッピーディスクと、磁気テープと、Ｚｉｐドライブとを含んでもよい。図７〜１０を参照して下記にさらに詳細に議論するように、メモリ３０４はまた、集約フレームを記憶してもよい。

プロセッサ３００はまた、メッセージインタープリタに結合されていてもよい。プロセッサは、処理のために、インバウンドのワイヤードおよびワイヤレスメッセージをメッセージインタープリタ３０６にパスしてもよい。メッセージインタープリタ３０６は、集約フレームを解釈してもよい。

メッセージインタープリタ３０６はまた、ワイヤレスネットワークインターフェース３１０において受信されたインバウンドワイヤレスメッセージから情報を導出するように構成されていてもよい。例えば、ワイヤレス通信デバイスから受信したインバウンドメッセージは、集約フレームを含んでいてもよい。メッセージインタープリタ３０６は、集約フレームからの識別情報を含む個々のフレームを導出してもよい。メッセージインタープリタ３０６は、さらなる処理のために、この識別情報をプロセッサ３００にパスしてもよい。別の例では、メッセージインタープリタ３０６は、インバウンドワイヤレスメッセージを処理して、インバウンドワイヤレスメッセージに応答するための情報をプロセッサ３００に提供するように構成されていてもよい。メッセージインタープリタ３０６はまた、メッセージ解釈において使用するための情報を記憶させる、または、取り出すために、メモリ３０４に直接的に結合されていてもよい。

プロセッサ３００はまた、メッセージフォーマッタ３０２に結合されていてもよい。メッセージフォーマッタ３０２は、アウトバウンドのワイヤードまたはワイヤレスメッセージを発生させるように構成されていてもよい。メッセージフォーマッタ３０２は、発生させたアウトバウンドのワイヤードまたはワイヤレスメッセージをプロセッサ３００にパスするようにさらに構成されていてもよい。図７〜１５を参照して下記に詳細に記述するように、メッセージフォーマッタ３０２は、既存のフレームから集約フレームを編成してもよく、および／または、集約フレームの一部である各フレームに、修正されたヘッダを挿入してもよい。

プロセッサ３００は、送信のために、ワイヤードネットワークインターフェース３０８またはワイヤレスネットワークインターフェース３１０に、アウトバンドのワイヤードまたはワイヤレスメッセージをパスしてもよい。加えて、図７〜１５を参照して下記に詳細に議論するように、プロセッサ３００は、集約するフレームを識別してもよく、これらを集約してもよい。

ワイヤードネットワークインターフェース３０８は、別のマクロノードにアウトバウンドワイヤードメッセージを送信してもよい。メッセージフォーマッタ３０２はまた、メッセージフォーマッティングにおいて使用するための情報を記憶させる、または、取り出すために、メモリ３０４に直接的に結合されていてもよい。

ワイヤレスネットワークインターフェース３１０は、アンテナ３１０ａおよびトランシーバ３１０ｂを備えていてもよい。トランシーバ３１０ｂは、ワイヤレス通信デバイスに向かうアウトバウンド／インバウンドワイヤレスメッセージ、または、ワイヤレス通信デバイスから来るアウトバウンド／インバウンドワイヤレスメッセージを変調／復調するように構成されていてもよい。アンテナ３１０ａは、アウトバウンド／インバウンドワイヤレスメッセージを送信／受信してもよい。アンテナ３１０ａは、マクロノード１０２からのアウトバウンド／インバウンドワイヤレスメッセージを、１つ以上のチャネルを介して送信および／または受信するように構成されていてもよい。アウトバウンド／インバウンドワイヤレスメッセージは、音声のみおよび／またはデータのみの情報（ここでは集合的に“データ”として呼ばれる）を含んでいてもよく、１つ以上の集約フレームを含んでいてもよい。

ワイヤードネットワークインターフェース３０８は、モデムを備えていてもよい。モデムは、別のマクロノードのような別の宛先／発信元に向かうアウトバウンド／インバウンドワイヤードメッセージ、または、別のマクロノードのような別の宛先／発信元から来るアウトバウンド／インバウンドワイヤードメッセージを変調／復調するように構成されていてもよい。ワイヤードネットワークインターフェース３０８は、技術的に知られている方法を使用する１つ以上のワイヤード標準規格にしたがって、受信したデータを復調してもよい。復調したデータをプロセッサ３００に送信してもよい。ワイヤードネットワークインターフェース３０８は、技術的に知られている方法を使用する１つ以上のワイヤード標準規格にしたがって、ワイヤードネットワークインターフェース３０８を通して、マクロノード１０２から送られることになるデータを復調してもよい。さらに、ワイヤードネットワークインターフェース３０８はまた、畳み込みデコーダを備えていてもよい。

別々に記述したが、マクロノード１０２に関して記述した機能ブロックは、別々の構造的エレメントである必要はないことを正しく認識するだろう。例えば、プロセッサ３００およびメモリ３０４は、単一のチップ中で具現化してもよい。プロセッサ３００は、加えて、または、代替実施形態において、プロセッサレジスタのようなメモリを備えていてもよい。同様に、機能ブロックの１つ以上のもの、または、さまざまなブロックの機能性の部分は、単一のチップ中で具現化してもよい。代替的に、特定のブロックの機能性は、２つ以上のチップ上で実現してよい。

プロセッサ３００、メッセージインタープリタ３０６、およびメッセージフォーマッタ３０２のような、マクロノード１０２に関して記述した、機能ブロックの１つ以上のもの、および／または、機能ブロックの１つ以上の組み合わせは、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、現場プログラム可能ゲートアレイまたは他のプログラム可能論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、あるいは、ここに記述した機能を実行するように設計されているこれらの任意の適切な組み合わせとして、具現化してもよい。マクロノード１０２に関して記述した、機能ブロックの１つ以上のもの、および／または、機能ブロックの１つ以上の組み合わせはまた、例えば、ＤＳＰおよびマイクロプロセッサを組み合わせたものや、複数のマイクロプロセッサや、ＤＳＰ通信を伴う１つ以上のマイクロプロセッサや、任意のその他のこのようなコンフィギュレーションのような、コンピューティングデバイスの組み合わせたものとして実現してもよい。

図１〜３のモジュールの機能性は、ここでの教示に一致するさまざまな方法で実現できる。いくつかの態様では、これらのモジュールの機能性は、１つ以上の電気コンポーネントとして実現してもよい。いくつかの態様では、これらのブロックの機能性は、１つ以上のプロセッサコンポーネントを含む処理システムとして実現してもよい。いくつかの態様では、これらのモジュールの機能性は、例えば、１つ以上の集積回路（例えば、ＡＳＩＣ）の少なくとも一部分を使用して実現してもよい。ここで議論したように、集積回路は、プロセッサ、ソフトウェア、他の関連コンポーネント、または、これらのいくつかの組み合わせを含んでいてもよい。これらのモジュールの機能性はまた、ここで教示したような他のいくつかの方法で実現してもよい。（例えば、付随する図面のうちの１つ以上のものに関連して）ここで記述した機能性は、いくつかの態様では、添付した特許請求の範囲中の類似して設計された“するための手段”機能性に対応していてもよい。図１〜３を参照すると、マクロノード１０２およびワイヤレス通信デバイス１０６は、一連の相互に関係する機能モジュールとして表されている。

図４は、ＰＨＹフレーム構造の例を図示している。ＰＬＣＰプロトコルデータユニット（“ＰＰＤＵ”）は、３つのコンポーネント：ＰＬＣＰプリアンブル４０２、ＰＬＣＰヘッダ４０４、ＰＳＤＵ４０６を含んでいてもよい。ＰＬＣＰヘッダ４０４は、受信機におけるＰＳＤＵ４０６のデコーディングを助けるための、ＰＨＹおよびＭＡＣの双方についての必要な情報を伝えてもよい。

図４中で示されているように、ＰＳＤＵ４０６は、フレームペイロードロード４１０と、フレーム検査シーケンスと、テールビットと、パッドビット４１２とを含んでいる。ワイヤレス通信デバイス（例えば、１０６）からマクロノード（例えば、１０２）に送られるパケット中に、または、マクロノードからワイヤレス通信デバイスに送られるパケット中に含まれるさまざまなタイプの通信（例えば、音声、データ、マルチメディアサービス等）に関連するデータのビットを、フレームペイロード４１０は含んでいてもよい。フレーム検査シーケンスは、誤り検出および訂正を助けるための、フレームに対するチェックサムキャラクタを提供する。ワイヤレスネットワークインターフェース（例えば、２０８または３０８）が畳み込みデコーダを備える実施形態では、デコーダをその初期状態にリセットするようにデコーダをフラッシュアウトして、誤り確率を改善するために、テールビットを付加してもよい。シンボルインターリーバの境界上にデータストリームを整列させるために、パッドビットを挿入してもよい。一般的に、パディングビットは、ある長さにフレームをパッドするために使用する、フレーム内のビット（例えば、通信システムにより使用するデータのユニット）である。例えば、図１Ｂを参照すると、通信システム２００は、ワイヤレス通信デバイス（例えば、１０６および２２０）間で送られるすべてのフレームが長さにおいて２５６ビットであることを必要とするかもしれない。ワイヤレス通信デバイス１０６が、フレーム中で送る１２８ビットのみのデータを有する場合、ワイヤレス通信デバイス１０６は、フレームの総長が、２５６ビット長要件を満たすように、１２８パディングビットを使用してフレームの残りを埋めてもよい。

図４を継続して参照すると、ＰＬＣＰプリアンブル４０２は、タイミング同期化、搬送波―オフセット復元、およびチャネル推定において、ワイヤレスネットワークインターフェース（例えば、２０８または３０８）を助けてもよい。

ＰＬＣＰヘッダ４０４は、ＰＳＤＵ４０６をデコードするのに使用する情報をワイヤレスネットワークインターフェース（例えば、２０８または３０８）に伝える。図４中に図示されているように、ＰＬＣＰヘッダ４０４は、ＰＨＹヘッダと、ＭＡＣヘッダ４０８と、ヘッダ検査シーケンスと、リードーソロモンパリティバイトと、３つのテールビットのフィールドとを含む。ＭＡＣヘッダ４０８は、図５を参照にして下記に詳細に議論する。ヘッダ検査シーケンスおよびリードーソロモンパリティバイトは、ＰＬＣＰヘッダ４０４に対して、改善した誤り検出および訂正を提供する。加えて、ワイヤレスネットワークインターフェースが畳み込みデコーダを備える実施形態では、デコーダをその初期状態にリセットするようにデコーダをフラッシュアウトして、誤り確率を改善するために、テールビットを付加してもよい。

ワイメディアＭＡＣフレームは、固定長ＭＡＣヘッダと、オプション的な可変長フレーム本体とを含んでいる。図５は、例示的なＭＡＣヘッダフォーマットを図示している。図５中に示されているように、ＭＡＣヘッダ４０８は、２オクテット（例えば、１６バイト）のフレーム情報５０２と、宛先アドレス５０４に対する２オクテットと、発信元アドレス５０６に対する２オクテットと、シーケンス制御情報５０８に対する２オクテットと、アクセス情報５１０に対する２オクテットとを含んでいてもよい。フレーム制御情報フィールド５０２と、宛先アドレスフィールド５０４と、発信元アドレスフィールド５０６と、制御情報フィールド５０８と、アクセス情報フィールド５１０とのサイズは、それぞれに対して２オクテットには限定されず、より多いオクテットまたはより少ないオクテットを含んでいてもよい。

図６は、図５に示したような、ＭＡＣヘッダ４０８のフレーム制御フィールド５０２の例示的なフォーマットを図示している。フレーム制御フィールド５０２は、予約ビット６０２と、リトライフラッグフィールド６０４と、フレームサブタイプ／配信ＩＤフィールド６０６と、フレームタイプフィールド６０８と、ＡＣＫポリシーフィールド６１０と、セキュリティ情報フィールド６１２と、プロトコルバージョンフィールド６１４とを含んでいてもよい。各フィールドのサイズは、フレームに依存して変化してもよく、図６中に示されているビット数には限定されない。

ある実施形態では、同じ送信機―受信機対間で交換される、異なるフレームタイプのフレーム（例えば、データフレーム、制御フレーム、および／またはコマンドフレーム）の集約は、データフレーム、制御フレーム、および／またはコマンドフレームを送信することに関係するオーバーヘッドを償却してもよい。ある実施形態では、コマンド／制御をデータフレームとともに集約する（例えば、ピギーバックさせる）ときに、コマンド／制御フレームに対する、追加的な、プリアンブル、ＰＬＣＰヘッダ、短フレーム間スペース（“ＳＩＰＳ”）時間量等に関係するオーバーヘッドを減少させてもよく、または、なくしてもよい。例えば、データフレームとコマンド／制御フレームとのそれぞれに対して、別々の、プリアンブル、ＰＬＣＰヘッダ、ＳＩＦＳ時間量等を必要とする代わりに、データフレームとコマンド／制御フレームとを集約フレーム中で送信してもよい。集約フレームの１つの実施形態の詳細な例を、図８中に示し、下記に議論する。データと、コマンド／制御フレームとを持つ集約フレームを送ることは、コマンドフレーム／制御フレームのそれぞれに対して以前に必要とされた別々のフレーミングオーバーヘッドに対する必要性をなくすかもしれない。

図７Ａは、送信機７１０から受信機（示していない）に、予約Ａの間にデータフレーム７０４を、および、予約Ｂの間にコマンドフレーム７０５を送信する送信機７１０を図示している。ワイヤレス通信デバイス１０６に関して以前に記述したように、送信機７１０は、プロセッサ、メモリ、メッセージフォーマッタおよび／またはメッセージインタープリタ、アンテナ、ならびにトランシーバを備えていてもよい。ある実施形態では、送信機７１０は、ワイヤレス通信デバイス１０６またはマクロノード１０２である。以前に記述したような、ワイヤレスネットワークインターフェース（２０８、３１０）、プロセッサ（２００、３００）、メモリ（２０４、３０４）、メッセージフォーマッタ（２０２、３０２）、および／またはメッセージインタープリタ（２０６、３０６）のうちの１つ以上のものにより、送信機７１０により実行する機能を成し遂げてもよい。

図７Ａ中に示されている例では、データフレーム７０４およびコマンドフレーム７０５は、別々の予約を必要としている。コマンドフレーム７０５が、それ自体の、プリアンブル、ヘッダ情報、フレーム間スペーシング情報、およびパディング情報を必要とすることがあるので、コマンドフレーム７０５からの追加的なオーバーヘッドが存在する。さらに、コマンドフレームは、一般的に、データフレームをよりも小さく、したがって、データフレームに割り振られた予約の一部分のみを必要とする。コマンドフレームの送信に予約が割り振られているので、予約の未使用部分は無駄になるかもしれない。

図７Ｂは、データフレーム７０４が、集約フレーム内にコマンドフレーム７０５とともに集約されている実施形態を図示している。図７Ｂは、集約フレームの高レベルな表現であり、図８に関して下記に詳細に説明する。ある実施形態にしたがうと、送信機７１０（すなわち、発信元）は、上記で示したように、予約Ａ中でデータフレーム７０４を送り、予約Ｂ中でコマンドフレームを送ることよりむしろ、同じ予約（予約Ａ）内の集約フレームとして、データフレーム７０４とコマンドフレーム７０５との双方を送信してもよい。また、ＭＡＳの数に関して予約を記述してもよいことを正しく理解するだろう。別の実施形態では、送信機７１０は、送信機７１０が、コマンドフレーム７０５とデータフレーム７０４とを集約フレーム中に集約すべきか否かを決定してもよい。

例として、集約フレームの推定したサイズが、予約した時間量を超える場合、送信機７１０は、コマンドフレーム７０５をデータフレーム７０４とともに集約しないことを選んでもよい。別の実施形態では、集約フレームの推定したサイズが、予約Ａ中の時間量を超える場合、送信機７１０は、１つ以上のＭＡＳだけ、予約Ａを増加（増大）させることを選んでもよい。予約Ａを適切なサイズまで増大させると、送信機７１０はその後、集約フレームを構築してもよい。増加させた予約中に未使用スペースが存在する場合、増加させた予約中の未使用スペースを埋めるために、より多くの、データフレームおよびコマンド／制御フレームのような、追加的なフレームを集約フレームに追加してもよい。代替的に、未使用の予約時間を利用するために、追加的な、データフレーム、制御フレーム、またはコマンドフレームを別々のフレームとして送信でき、処理を反復させてもよい。

図７Ｃは、上述した７Ａに類似している。しかしながら、図７Ｃ中で示されているように、送信機７１０は、予約Ａ中でデータフレーム７０４を送り、予約Ｂ中でコマンドフレームを送ることよりむしろ、予約Ａ中でデータフレーム７０４を送り、予約Ｂ中で制御フレーム７０６を送ってもよい。

図７Ｄは、データフレーム７０４が、集約フレーム中で制御フレーム７０６とともに集約されている実施形態を描写している。図７Ｄは、集約フレームの高レベルな表現であり、図８に関して下記に詳細に説明する。図７Ｄ中に示されているように、送信機７１０は、予約Ａ中でデータフレーム７０４を送り、予約Ｂ中で制御フレーム７０６を送ることよりむしろ、データフレーム７０４と制御フレーム７０６との双方を集約フレームとして同じ予約（予約Ａ）内で送信してもよい。別の実施形態では、送信機７１０は、送信機７１０が制御フレーム７０６とデータフレーム７０４とを集約フレーム中に集約すべきか否かを決定してもよい。ある実施形態では、集約フレームの推定したサイズが、予約した時間量を超える場合、送信機７１０は、制御フレーム７０６をデータフレーム７０４とともに集約しないことを選んでもよい。別の実施形態では、集約フレームの推定したサイズが、予約Ａに割り振られた時間量を超える場合、送信機７１０は、１つ以上のＭＡＳだけ、予約Ａを増加（増大）させることを選ぶかもしれない。予約Ａを適切なサイズまで増大させると、送信機７１０はその後、集約フレームを構築してもよい。増加させた予約中に未使用スペースが存在する場合、追加的なフレームを集約フレームに追加してもよい。代替的に、未使用の予約時間を利用するために、追加的な、データフレーム、制御フレーム、またはコマンドフレームを別々のフレームとして送信でき、処理を反復させてもよい。

図７Ｅは、データフレーム７０４と、制御フレーム７０６と、コマンド７０５とを受信機（示していない）に送信する送信機７１０を図示している。

図７Ｅ中に示されている例にしたがうと、データフレーム７０４と、制御フレーム７０６と、コマンドフレーム７０５は、それぞれ別々の予約を必要としている。これにより、それぞれが、それら自体の、プリアンブル、ヘッダ情報、フレーム間スペーシング情報、およびパディング情報を必要とすることがあるので、制御フレームおよびコマンドフレームからのフレーミングオーバーヘッドが結果として生じることがある。さらに、制御フレームおよび／またはコマンドフレームは、一般的に、データフレームよりも小さく、一般的に、制御フレームおよび／またはコマンドフレームに割り振られた予約の一部分のみを必要とする。制御フレームおよび／またはコマンドフレームの送信に予約が割り振られているので、予約の未使用部分は無駄になるかもしれない。

図７Ｆは、データフレーム７０４が、集約フレーム中で、制御フレーム７０６とコマンドフレーム７０５とともに集約されている別の実施形態を図示している。図７Ｆは、集約フレームの高レベルな表現であり、図８に関して下記に詳細に説明する。ある実施形態にしたがうと、送信機７１０は、上記に示したように、予約Ａ中でデータフレーム７０４を送り、予約Ｂ中で制御フレーム７０６を送り、予約Ｃ中でコマンドフレーム７０５を送ることよりむしろ、３つすべてのフレームを集約フレームとして同じ予約内で送信してもよい。別の実施形態では、送信機７１０は、送信機７１０が、制御フレームとコマンドフレーム７０５とデータフレーム７０４とを集約フレーム中に集約すべきか否かを決定してもよい。別の実施形態では、集約フレームの推定したサイズが、予約Ａに割り当てられた時間量を超える場合、送信機７１０は、制御フレーム７０６とコマンドフレーム７０５とをデータフレーム７０４とともに集約しないことを選んでもよい。集約フレームは、予約Ａ内に収まるが、集約フレームはデータフレームとコマンドフレームと制御フレームの３つすべてを含むものではない場合に、送信機７１０は、データフレームとコマンド／制御フレームとを集約することを決定できる。別の実施形態では、集約フレームの推定したサイズが、予約Ａ中に予約された時間量を超える場合、送信機７１０は、１つ以上のＭＡＳだけ、予約Ａを増加（増大）させることを選んでもよい。予約Ａを適切なサイズまで増大させると、送信機７１０はその後、集約フレームを構築してもよい。さらに、増加させた予約中に未使用スペースが存在する場合、追加的なフレームを集約フレームに追加してもよい。代替的に、未使用の予約時間を利用するために、追加的な、データフレーム、制御フレーム、またはコマンドフレームを別々のフレームとして送信でき、処理を反復させてもよい。

図７Ｇは、データフレーム７０４と制御フレーム７０６とを、適切なフレーム間スペーシング７０８により、単一の予約（予約Ｃ）内で送信してもよい例を図示している。図７Ｇ中に示されているように、送信機７１０は、データフレーム７０４と制御フレーム７０６とを受信機（示されていない）に送信する。データフレーム７０４は、フレーミング情報７０４ａとデータペイロード７０４ｂとを含んでいる。制御フレーム７０６は、フレーミング情報７０６ａと制御ペイロード７０６ｂとを含んでいる。この例では、予約Ａは、必ずしもそうではないが、予約Ｂと同じサイズであってもよい（各予約は、１つ以上のＭＡＳを含んでいる）。ここで、予約Ｃは、予約Ａと予約Ｂとを組み合わせたものと同じサイズであるように描写されているが、いくつかの実施形態では、予約Ｃは、予約Ａおよび予約Ｂの組み合わせたものより大きくてもよく、または、予約Ａおよび予約Ｂの組み合わせたものより小さくてもよい。図７Ｇ中に示されているように、データフレーム７０４および制御フレーム７０６は、予約Ａ単独または予約Ｂ単独のどちらの内にも収まらない。したがって、送信機７１０は、データフレームと制御フレームとの双方を同じ予約内で送信するために、より大きな予約Ｃを生成させる必要があるかもしれない。図７Ｇ中に示されているように、必ずしもより大きな予約Ｃのすべてを利用しない。これにより、少なくとも１つのＭＡＳにより予約を拡張することができるときに、割り振り過ぎのために、送信機７１０に割り振られた予約の一部分が使用されないことがあるので、通信システムの容量が結果として無駄になることがある。

図７Ｈは、データフレームが、集約フレーム７０１中に制御フレーム７０６とともに集約されている実施形態を図示している。集約フレーム７０１は、フレーミング情報７０１ａと、集約ヘッダ７０１ｈと、データペイロード７０４ｂと、制御ペイロード７０６ｂとともに、各フレームに対する短くしたヘッダ（７０４ｓおよび７０６ｓ）とを含んでいる。集約フレームは、予約Ａ内に収まっている。ある実施形態では、送信機７１０は、データペイロード７０４ｂと、制御ペイロード７０６ｂと、コマンドペイロード７０５ｂとを含む集約フレーム７０３を受信機（示していない）に送信する。送信機７１０は、送信機７１０が、図７Ｇ中で示したような、制御フレーム７０６とデータフレーム７０４とを集約フレーム中に集約できるか否かを決定してもよい。送信機７１０が、データフレーム７０４と制御フレーム７０６とを集約すると決定した場合、単一の集約フレーム７０１中にこれらを組み合わせる。予約Ａ単独に割り当てられた時間内で、集約フレームを送信してもよい。したがって、この実施形態では、より大きな予約Ｃを生成させる必要はなく、それにより、チャネル容量が無駄になるのを避ける。図７Ｈ中に示されていないものはＳＩＦＳ時間量およびガード時間であり、これらは、ＡＣＫが必要とされない場合に、集約フレームの末端部と予約の末端部との間に配置されることがある。ＡＣＫが必要とされるイベントにおいて、さらなる詳細を下記に提供する。

図７Ｉは、コマンドフレーム７０５とデータフレーム７０４が、適切なフレーム間スペーシング７０８により送信されていることを除いて、図７Ｇに類似した例を図示している。

図７Ｊは、データフレーム７０４が、集約フレーム中でコマンドフレーム７０５とともに集約されている実施形態を図示している。ある実施形態では、送信機７１０は、データペイロードとコマンドペイロードとを含む集約フレーム７０２を受信機（示されていない）に送信する。集約フレームは、フレーミング情報７０２ａと、集約ヘッダ７０２ｈと、データペイロード７０４ｂと、コマンドペイロード７０５ｂとともに、各フレームに対する短くしたヘッダ（７０４ｓおよび７０５ｓ）とを含んでいる。集約フレームは、予約Ａ内に収まっている。送信機７１０は、送信機７１０が、コマンドフレーム７０５とデータフレーム７０４とを集約フレーム７０２中に集約できるか否かを決定してもよい。送信機７１０が、データフレーム７０４とコマンドフレーム７０５とを集約すると決定した場合、単一の集約フレーム７０２中にこれらを組み合わせる。予約Ａ単独に割り当てられた時間内で、集約フレーム７０２を送信してもよい。したがって、より大きな予約Ｃを生成させる必要はなく、それにより、チャネル容量が無駄になるのを避ける。図７Ｊ中に示されていないものはＳＩＦＳ時間量およびガード時間であり、これらは、ＡＣＫが必要とされない場合に、集約フレームの末端部と予約の末端部との間に配置されることがある。ＡＣＫが必要とされるイベントにおいて、さらなる詳細を下記に提供する。

図７Ｋは、データフレーム７０４と、コマンドフレーム７０５と、制御フレーム７０６が、適切なフレーム間スペーシング７０８および７０９により送信されていることを除いて、図７Ｇおよび７Ｉに類似した例を図示している。

図７Ｌは、データフレームが、集約フレーム７０３中でコマンドフレーム７０５と制御フレーム７０６とともに集約されている実施形態を図示している。集約フレームは、フレーミング情報７０３ａと、集約ヘッダ７０３ｈと、データペイロード７０４ｂと、コマンドペイロード７０５ｂと、制御ペイロード７０６ｂとともに、各フレームに対する短くしたヘッダ（７０４ｓ、７０５ｓ、および７０６ｓ）とを含んでいる。集約フレーム７０３は、予約Ａ内に収まっている。ある実施形態では、送信機７１０は、データペイロード７０４ｂと、制御ペイロード７０６ｂと、コマンドペイロード７０５ｂとを含む集約フレーム７０３を受信機（示していない）に送信する。送信機７１０は、送信機７１０が、図７Ｋ中で示したような、データフレーム７０４と制御フレーム７０６とコマンドフレーム７０５とを集約フレーム７０３中に集約できるか否かを決定してもよい。送信機７１０が、データフレーム７０４と制御フレーム７０６とコマンドフレーム７０５とを集約すると決定した場合、単一の集約フレーム７０３中にこれらを組み合わせる。予約Ａ単独に割り当てられた時間内で、集約フレーム７０３を送信してもよい。したがって、より大きな予約Ｃを生成させる必要はなく、それにより、チャネル容量が無駄になるのを避ける。

別の実施形態では、集約フレーム中の、データフレーム、コマンドフレーム、または制御フレームの任意の組み合わせが存在する。例えば、集約フレームは、２つのデータフレームと、２つのコマンドフレームと、２つの制御フレームを含んでいてもよい。別の例では、集約フレームは、１つのデータフレームと２つの制御フレーム、または、１つの制御フレームと１つのコマンドフレームを含んでいてもよい。したがって、本発明の実施形態は、任意の順序で集約フレーム中に組み合わされる、任意の数のデータフレームと、任意の数のコマンドフレームおよび／または制御フレームとの組み合わせを提供する。この実施形態はまた、データフレームと、制御フレームと、コマンドフレームとのそれぞれのうちの１つを集約フレーム中に集約することを可能にしてもよい。

ある実施形態では、異なるタイプのフレームの集約は、都合のよい機会に行われることがある。例えば、予約内にスペースがある場合にのみ、集約フレームを生成させてもよい。

別の実施形態では、ある量だけ予約を増加させることができ、予約が集約フレームを収容できる場合にのみ、集約フレームを生成させてもよい。別の実施形態では、トランシーバすなわち送信機は、異なるタイプのフレームを集約すべきか否かの決定を行い、その後、フレームを集約すべきと決定した場合に集約を実行してもよい。この決定において、これらには限定されないが、予約サイズと、データフレームサイズと、コマンドフレームサイズと、制御フレームサイズと、待ち時間考慮事項や、ネットワークトラフィックの量や、ＡＣＫ要件を含むサービスの品質（ＱｏＳ）要件とを含む、さまざまな要因を使用してもよい。さらに、増加させた予約中に未使用のスペースが存在する場合、集約フレームに追加的なフレームを追加してもよい。代替的には、未使用の予約時間を利用するために、追加的な、データフレーム、制御フレーム、またはコマンドフレームを別々のフレームとして送ることができる。

表１は、図６中に示したようなフレームタイプフィールド６０８に対する例示的な識別値を図示している。表１中に示されている識別値は、フレームタイプフィールド６０８を満たすだろう２進法値の１０進法の等価なものである。１つの実施形態では、異なるタイプのフレームの集約に適応するように、新たなフレームタイプ“拡張集約フレーム”を規定してもよい。

実施形態は、拡張集約フレームタイプ中の、データフレームと、制御フレームまたはコマンドフレームとのそれぞれに対して、別々のフレーム制御フィールドを提供する。また、拡張集約フレーム中の各フレームに対して、別々のシーケンス制御情報を有する必要があるかもしれない。さらに、拡張集約フレーム中の各フレームに対して、セキュリティヘッダ情報に対する必要性があるかもしれない。一般的に、拡張集約フレーム中のタイプにわたるすべてのフレームに対して、宛先アドレスと発信元アドレスとアクセス情報は、同じままであるかもしれないので、それらを複製する必要はないかもしれない。

図８は、１つの実施形態にしたがった、拡張集約ＰＨＹフレーム８０１の例を図示しており、集約が、異なるタイプ（例えば、データ、コマンド、制御など）のフレームを含んでいる。ある実施形態では、集約フレーム８０１は、プリアンブル８０２と、ＰＬＣＰヘッダ８０３と、集約ヘッダ８０４（図９を参照してさらに詳細に説明する）と、集約フレーム中の各フレームに対する短ＭＡＣヘッダ（８０５、８０９）（図１０を参照して下記にさらに詳細に説明する）と、集約フレーム中の各フレームに対するペイロード（８０６、８１０）と、集約フレーム中の各フレームに対する、ＦＣＳビット（８０７、８１１）およびテールビット（８０８、８１２）と、パッドビット８１３とを含んでいる。

ある実施形態では、プリアンブル８０２およびＰＬＣＰヘッダ８０３は、ワイメディア仕様中に予め規定されている。ＰＬＣＰヘッダのＭＡＣヘッダ中の、宛先アドレスと、発信元アドレスと、アクセス情報は、すべての集約フレームに対して共通であってもよい。拡張集約フレームに対するＭＡＣヘッダのシーケンス制御フィールド（例えば、フレームタイプが５である）は、デフォルト予約値（例えば、０）に設定されていてもよい。

別の実施形態では、シーケンス制御フィールドは、拡張集約フレーム中の第１のＭＰＤＵの第１の短ＭＡＣヘッダ中のものと同じものであってもよい。また、拡張集約フレーム中では、ＰＬＣＰヘッダのＭＡＣヘッダのフレーム制御中の（フレームタイプおよびプロトコルバージョンを除く）すべてのフィールドは予約されている。例えば、すべて０に設定されている。

図９は、図８で示したような集約ヘッダ８０４の１つの実施形態を図示している。１つの実施形態にしたがうと、集約ヘッダ８０４は、ワイメディアフレームペイロードの冒頭をマーク付けする。１つの実施形態では、集約ヘッダ８０４は、フレームカウントフィールド９０２と、それぞれ個々のフレームに対するＭＰＤＵの長さフィールド（例えば、９０３、９０４、９０５）と、ＦＣＳフィールド９０６と、テールビットフィールド９０７と、パッドビットフィールド９０８とを含んでいる。

フレームカウントフィールド９０２は、集約フレーム内で見つかるフレームの数に関する１以上のオクテットの情報を含んでいてもよい。ＭＰＤＵの長さフィールド（９０３、９０４、９０５）は、それぞれ個々のフレーム、すなわち、ペイロードおよび短ＭＡＣヘッダ、あるいはペイロードだけの長さまたはサイズに関する複数のオクテットの情報を含んでいてもよい。別の実施形態では、長さフィールドは、図８中に示したようなＭＰＤＵの短ＭＡＣヘッダの一部として含まれていてもよく、図１０を参照して下記に議論する。ＦＣＳフィールド９０６は、誤り検査のための情報を含んでいる一方、テールビットフィールド９０７は、畳み込みデコーダをその初期状態にリセットするように畳み込みデコーダをフラッシュアウトして、それにより、集約フレームの異なるフレーム中の誤りを分離するための情報を含んでいてもよい。パッドビットフィールド９０８は、複数オクテットの情報を含んでいてもよく、シンボルインターリーバの境界上にデータストリームを整列させるために、挿入してもよい。

図１０は、１つの実施形態にしたがった、集約ＰＨＹフレーム中の短ＭＡＣヘッダ（例えば、図８中に示した８０５または８０９）を図示している。集約フレーム内の各フレームに対して、標準ＭＡＣヘッダを使用してもよいが、これはフレームにつき６オクテットを無駄にすることがある。図１０中に示されているような短ＭＡＣヘッダ８０５、８０９により、集約フレームに対して必要であるかもしれない情報量が減少する。１つの実施形態では、短ＭＡＣヘッダは、フレーム制御フィールド１００２とシーケンス制御フィールド１００３とを含んでいてもよい。別の実施形態では、各ＭＰＤＵは、デコーダを０状態に導くための、それ自体のＦＣＳとテールビットとを有していてもよく、各ＭＰＤＵは、インターリーブシンボル境界とともに整列するようにパディングされてもよい。図１０中に示してはいないが、短ＭＡＣヘッダ８０５、８０９は、セキュリティヘッダ情報および／または長さフィールドを追加的に含んでいてもよい。望まれるとき、または、必要とされるとき、短ＭＡＣヘッダに対する追加的な情報を追加してもよい。

これから、図７Ｉ、図７Ｊ、および図８〜１０を参照して、１つの実施形態の例を与える。この実施形態では、図７Ｉで示したような、データフレーム７０４とコマンドフレーム７０５とが集約されている。この実施形態では、集約フレーム７０２はまた、拡張集約ＰＨＹフレーム８０１としても表されるかもしれない。この実施形態の集約フレーム８０１は、プリアンブルと、ＰＬＣＰヘッダと、集約ヘッダと、２つの短ＭＡＣヘッダと、２つのフレームペイロードと、集約フレーム中のフレームのそれぞれに対してとともに、集約ヘッダ自体に対する、ＦＣＳおよびテールビットのフィールドと、集約フレーム中のフレームのそれぞれに対してとともに、集約ヘッダ自体に対する、パッドビットとを含む。

この実施形態の集約ヘッダは、フレームカウントフィールドと、２つのペイロードに対する２つのＭＰＤＵの長さフィールドと、ＦＣＳフィールドと、テールビットフィールドと、パッドビットフィールドとを含む。この実施形態では、１つのデータフレームと、１つのコマンドフレームとが存在するので、フレームカウントは２であるだろう。この実施形態では、データフレームペイロード７０４の長さが、ＭＰＤＵ１の長さフィールド９０３中に挿入され、コマンドフレームペイロード７０５の長さが、ＭＰＤＵ２の長さフィールド９０４中に挿入される。ＦＣＳフィールドと、テールビットフィールドと、パッドビットフィールドも、必要なように埋めてもよい。

この実施形態では、短ＭＡＣヘッダ１フィールド８０５は、データフレーム７０４に特有な情報を含み、短ＭＡＣヘッダＮフィールド８０９は、コマンドフレーム７０５に特有な情報を含む。この実施形態では、各短ＭＡＣヘッダは、フレーム制御、シーケンス制御に関する情報、または、そのそれぞれのペイロードに関連する他の情報を含んでいてもよい。

この実施形態では、ペイロード１フィールド８０６は、データフレームペイロード７０４ｂ中に見つかる情報を含む。ペイロードＮフィールド８１０は、コマンドフレームペイロード７０５ｂ中に見つかる情報を含む。さらに、各ペイロードは、デコーダをリセットすることと、誤り検出とのための、ＦＣＳフィールドおよびテールビットフィールドと、シンボルインターリーバの境界上にデータストリームを整列されるためのパッドビットフィールドとを有していてもよい。他の実施形態では、集約フレーム内の整列のために、集約フレーム中のそれぞれ個々のフレームに対するパッドビットフィールドが存在していてもよい。

図１１は、ある実施形態にしたがった、異なるタイプのフレームを集約するための例示的な方法を図示しているフローチャートである。必ずしも、図示されているステップのすべてを必要としないことと、この方法は、本発明の精神および範囲から逸脱することなく、修正してもよいこととを理解するだろう。さらに、下記にさらに詳細に記述するように、１つ以上の、プロセッサ、フォーマッタ、インタープリタ、メモリ、および／または、他のデバイスを使用して、この方法を実現してもよい。送信デバイス（例えば、１０２、１０６）のそれぞれから描写される方法１０００は、１１０１において開始する。ブロック１１０２において、方法は、トランシーバ（例えば、２０８ｂ、３１０ｂ）すなわち送信機により送信されるように構成されている、異なるタイプ（例えば、データ、コマンド、制御等）の少なくとも２つのフレームを識別する。異なるタイプの少なくとも２つのフレームは、集約フレーム中に集約されていてもよい。ある実施形態では、プロセッサ（例えば、２００、３００）または類似したデバイスが、この識別を実行してもよい。集約フレームは、異なるタイプの少なくとも２つのフレームのそれぞれの少なくとも一部分を含む。集約フレームはまた、集約ヘッダと、少なくとも２つのフレームの各部の短ＭＡＣヘッダとを含んでいてもよい。

ブロック１１０３において、集約フレームのヘッダの長さを決定する。ブロック１１０４において、集約フレームの本体の長さを決定する。これらの決定は、例えば、上述したような、プロセッサまたは類似したデバイスにより達成してもよい。

決定ブロック１１０５において、第１の時間量すなわち予約期間内で送信することになる集約フレームの適性を決定する。例えば、サイズと長さとフォーマッティング特性とのうちの何らかまたはすべてを含むその特性が、送信に適していると考えられる場合に、集約フレームは、送信に適している。送信に対するその適性を決定するために、集約フレームの他の特性とともに、さまざまな技術を使用することができることを正しく認識するだろう。ある実施形態では、例えば、予約期間内で集約フレームを送信するための十分な時間が、時間量すなわち予約期間内に存在するか否かを決定する。別の実施形態では、集約フレームのヘッダの長さと、集約フレームの本体の長さとを、予約期間のサイズと相関させてもよい。ここで、予約期間のサイズはまた、予約期間の、長さや、時間量や、ＭＡＳの数を意味するようにも理解される。プロセッサ、または類似したデバイス（例えば、２００、３００）が、この決定を実行してもよい。決定の結果がいいえである場合、方法は、ブロック１１０６に移り、フレームを集約しないための命令を生成させる。フレームを別々の予約期間中で独立的に送信するために、追加的な命令を発生させてもよい。

ブロック１１０５における決定がはいである場合、トランシーバすなわち送信機による送信のために、ブロック１１０７において、集約フレームをフォーマットする。したがって、例えば、送信デバイスにおいて、または、メッセージフォーマッタによって、集約フレームの本体に集約ヘッダを置くことにより、ならびに、異なるタイプの少なくとも２つのフレームの各部分に短ＭＡＣヘッダを置くことにより、あるいは、送信のために既にアセンブリされた集約フレームを準備することにより、集約フレームをフォーマットしてもよい。例えば、ブロック１１０８の後に、送信機すなわちトランシーバにより集約フレームを送信してもよい（示していない）。

さらに、方法１１００内で、集約フレームに追加的なフレームを集約する類似したステップを実行してもよい。例えば、トランシーバにより送信されるように構成されている第３のフレームを識別してもよい。また、第１の時間量内でトランシーバにより送信されることなる第２の集約フレームの可能性を決定してもよい。第２の集約フレームは、第１の集約フレームの一部であった、最初の２つのフレームの少なくとも一部分と、第３のフレームの少なくとも一部分とを含むだろう。第２の集約フレームが、第１の予約期間内の送信に適していると決定した場合、トランシーバによる送信のために第２の集約フレームをフォーマットするだろう。第２の集約フレームのフォーマッティングは、第１の集約フレームに関して以前に記述したものと類似した方法で達成できるだろう。第２の集約フレームは、第１の予約期間内で送信してもよい。

集約フレームが、第１の予約期間内での、または、上述したような拡張予約期間内での送信に適していないと決定するまで、３つのフレームに追加的なフレームを集約することができるだろう。上述したように、集約フレームが、予約期間内での、または、拡張予約期間内での送信に適している限り、送信のために、フレームのできるだけ多くの部分により、集約フレームをフォーマットしてもよい。フォーマットした集約フレームをその後送信してもよい。

図１２〜１５中に図示されているように、さらなる決定および機能を、単独で、または、図１１中に記述したそれらとの組み合わせで、実行してもよい。これらの決定および機能を、図１１中で示したそれらと同時に、または、図１１中で示したそれらとシリアルに実行してもよく、互いに組み合わせてもよい。

図１２は、予約期間を拡張して、拡張した時間期間内に集約フレームを収めることを可能にするための方法１２００を図示しているフローチャートである。方法１２００は、ブロック１２０１を含み、ここで、予約期間すなわち時間量を拡張する。ブロック１２０１は、図１１のブロック１１０６の場所に挿入してもよい。このコンフィギュレーションでは、集約フレーム、すなわち、少なくとも２つ以上のフレームが、時間量すなわち予約期間内の送信に適していないという、ブロック１１０５における決定に応答して、ブロック１２０１の方法を実行する。集約フレームが送信に適するように、ブロック１２０１において、予約期間すなわち時間量を拡張した後、方法は、ブロック１２０２に移り、上述したように、集約フレームをフォーマットする。

図１３は、フレームが高いサービスの品質（ＱｏＳ）を必要とするか否か、すなわち、フレームが、遅延敏感であるアプリケーションレイヤフローに属しているか否かを決定する、別の実施形態を図示しているフローチャートである。いくつかのインスタンスでは、フレームは、重要または時間敏感であると考えられ、フレームを集約することは、それらの品質を減少させるだろう。このようなインスタンスでは、たとえフレームが予約期間内に収まるだろうと決定した場合でも、フレームを集約しないことが好ましいかもしれない。決定ブロック１３０１では、方法は、あるフレームが高いＱｏＳを必要とするか否か、または、他の理由のために、フレームを集約しないことが好ましい否かを決定する。ブロック１３０１において、方法が、フレームのうちの１つを集約すべきではない、または、フレームを集約しないことが好ましいと決定した場合、方法１３００は、ブロック１３０２に移り、ここで、方法は、フレームを集約せず、別々の予約期間中での独立的な送信のためにフレームをフォーマットする命令を発生させる。フレームを、それらのそれぞれの予約期間中で送信するために、追加的な命令を発生させることできる。フレームが高い品質サービスを必要としない、または、フレームを集約してもよいと決定した場合、方法１３００は、ブロック１３０３に移り、フレームを集約し、または、上述したように、集約フレームをフォーマットする。

１つの実施形態では、決定ブロック１３０１を、図１１のブロック１１０１と１１０２との間に挿入してもよい。この実施形態では、決定ブロック１３０１において行われる決定の結果に依存して、方法は、上述したように、ブロック１１０６またはブロック１１０７のいずれかに移る。代替的に、方法１３００は、方法１１００と同時に、または、方法１１００の後に実行してもよい。

図１４は、ネットワークに軽い負荷または重い負荷がかかっているかを決定する別の実施形態を図示しているフローチャートである。いくつかのインスタンスでは、ネットワークに軽い負荷がかかっているとき、フレームを集約することは、効率を向上しないかもしれず、プロセッサのリソースを無駄にするかもしれず、すなわち、好ましくないかもしれない。このようなインスタンスでは、たとえフレームが予約期間内の送信に適していると決定した場合でも、フレームを集約しないことが好ましいかもしれない。決定ブロック１４０１は、ネットワークに重い負荷がかかっているか否か、または、相当な負荷がかかっているか否かの、方法による決定を図示している。ネットワークに重い負荷がかかっていないことを決定した場合、方法は、ブロック１４０３に移り、ここで、フレームを集約せず、別々の予約期間中での独立的な送信のためにフレームをフォーマットする命令を発生させる。フレームを、それらのそれぞれの予約期間中で送信するために、追加的な命令を発生させることできる。ネットワークに重い負荷がかかっていることを決定した場合、方法１４００は、ブロック１４０２に移り、フレームを集約し、または、上述したように、集約フレームをフォーマットする。

１つの実施形態では、決定ブロック１４０１を、図１１のブロック１１０１と１１０２との間に挿入してもよい。この実施形態では、決定ブロック１４０１において行われる決定の結果に依存して、方法は、上述したように、ブロック１１０６またはブロック１１０７のいずれかに移る。代替的に、方法１４００は、方法１１００と同時に、または、方法１１００の後に実行してもよい。

図１５は、集約フレームが肯定応答（“ＡＣＫ”）を要求するか否かを決定する別の実施形態を図示しているフローチャートである。いくつかのデータフレームにおいて、送信デバイスは、追加的なフレームを送信する前に、何らかの形態の応答メッセージを必要とする。現行システムでは、応答メッセージは、一般的にＡＣＫの形態のものである。しかしながら、開示は、ＡＣＫに限定されず、フレームに応答して送られる何らかのタイプのメッセージをカバーする。現行システムでは、送信したフレームと同じ予約期間の間に、ＡＣＫ（または複数のＡＣＫ）を受信する必要があるかもしれない。このようなインスタンスでは、ＡＣＫまたは他のいくつかの応答メッセージを含めるための十分な時間が時間期間中に存在しない場合には、たとえフレームが予約期間内に収まると決定した場合でも、フレームを集約しないことが好ましいかもしれない。決定ブロック１５０１は、あるフレームがＡＣＫ（または複数のＡＣＫ）を必要とするか否かの決定を図示している。決定ブロック１５０１において、方法が、１つ以上のフレームがＡＣＫを必要とすることを決定した場合、方法は、決定ブロック１５０２に移り、予約期間内で送信されることになるＡＣＫ（必要であれば、複数のＡＣＫ）の可能性とともに、何らかの追加的なフレームスペーシングを決定する。ＡＣＫ（または複数のＡＣＫ）を含めるための十分な利用可能な時間が予約期間中に存在しない、または、予約期間内の送信にＡＣＫが適していないと決定した場合、方法は、ブロック１５０４に移り、フレームを集約せず、別々の予約期間中でフレームを独立的に送信するための命令を発生させる。しかしながら、決定ブロック１５０２において、方法が、ＡＣＫおよび何らかの追加的なフレーム間スペーシングが、予約期間内の送信に適していると決定した場合、方法１５００は、ブロック１５０３に移り、集約フレームを生成させるための、または、上記で議論したように、集約フレームをフォーマットするための命令を発生させる。決定ブロック１５０１に戻って参照すると、方法が、ＡＣＫが必要ないと決定した場合、方法は、ブロック１５０３に移り、フレームを集約するための、または、上記で議論したように、集約フレームをフォーマットするための命令を発生させる。

１つの実施形態では、決定ブロック１５０１および１５０２は、図１１のブロック１１０５と１１０７との間に挿入してもよい。この実施形態では、決定ブロック１５０１および１５０２において行われる決定の結果に依存して、方法は、上述したように、ブロック１１０６またはブロック１１０７のいずれかに移る。代替的に、方法１５００は、方法１１００と同時に、または、方法１１００の後に実行してもよい。

図１６は、フレームを、集約することなく、予約期間内で送信することができるか否かを決定する別の実施形態を図示しているフローチャートである。いくつかのインスタンスでは、集約なしで、異なるタイプの２つのフレームを送信するための十分なスペースが、単一の予約期間内に存在することがある。このようなインスタンスでは、集約フレームを規定するよりむしろ、フレームを単一の予約期間中で別々に送信することがより効率的であるかもしれない。決定ブロック１６０１は、集約フレームを規定することなく、予約期間内で送信されることになる異なるタイプのフレームの可能性の、方法による決定を図示している。何らかの必要なフレーム間スペーシング等を持って、異なるタイプのフレームが、予約期間内の送信に適していると決定した場合、方法は、ブロック１６０３に移り、ここで、フレームを集約せず、予約期間内の送信のためにフレームをフォーマットする命令を発生させる。フレームを、集約なしで、予約期間内で送信できないと決定した場合、方法１６００は、ブロック１６０２に移り、フレームを集約し、または、上記で議論したように、集約フレームをフォーマットする。

１つの実施形態では、決定ブロック１６０１は、図１１のブロック１１０５と１１０７との間に挿入してもよい。この実施形態では、決定ブロック１６０１において行われる決定の結果に依存して、方法は、上述したように、ブロック１１０６またはブロック１１０７のいずれかに移る。別の実施形態では、決定ブロック１６０１は、図１１のブロック１１０４と１１０５の間に、または、適切と考えられる他の何らかのロケーションに置いてもよい。代替的に、方法１６００は、方法１１００の前に、方法１１００の後に、方法１１００と同時に、または、方法１１００の場所で実行してもよい。

上述した方法は、例えば、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープ、メモリカード、ディスクを記憶するための何らかの種類の記録デバイスを含むコンピュータ読取可能記録媒体上で記憶させるプログラムフォーマットで実現してもよく、また、搬送波フォーマット（例えば、インターネット送信またはブルートゥース送信）で実現してもよい。

特定の、ブロック、セクション、デバイス、機能、およびモジュールを上述してきたかもしれないが、システムを提供する多くの方法が存在することと、上記にリストアップしたそれらの代わりに代用してもよい、多くの、パーツ、コンポーネント、モジュール、または機能が存在することとを正しく認識するだろう。さらに、上記で参照した図１１〜１５中で記述したブロックは、異なる順序で実行してもよく、同時に実行してもよく、ステップのうちのいくつかを省いてもよい。

上記の詳細な説明は、さまざまな実施形態に適応する際の本発明の新規な特徴を示し、記述し、指し示してきたが、図示したデバイスまたはプロセスの、形態および詳細における、さまざまな、省略、代用、および変更を、本発明の精神から逸脱することなく、当業者により行うことができることを理解するだろう。特許請求の範囲に等しい、意図および範囲内に生じるすべての変更は、それらの範囲内に含められるべきである。

Claims (46)

1. 通信システム中で情報を通信する方法において、
   前記情報は、トランシーバによる送信のために構成されている複数のフレームを含み、
   前記方法は、
   異なるタイプの少なくとも２つのフレームを識別することと、
   前記少なくとも２つのフレームのそれぞれの少なくとも一部分を含む第１の集約フレームの、第１の時間量内でのトランシーバによる送信に対する適性を決定することと、
   前記第１の集約フレームが、前記第１の時間量内での送信に適していると決定した場合に、前記トランシーバによる送信のために前記第１の集約フレームをフォーマットすることとを含み、
   前記異なるタイプの少なくとも２つのフレームのそれぞれは、前記トランシーバによる送信のために構成されている方法。
2. 前記第１の集約フレームが、前記第１の時間量内での送信に適していると決定した場合に、前記トランシーバを使用して、前記第１の集約フレームを送信することをさらに含む請求項１記載の方法。
3. 前記異なるタイプの少なくとも２つのフレームのそれぞれは、ヘッダと本体とを含む請求項１記載の方法。
4. 前記少なくとも２つのフレームのそれぞれの少なくとも一部分は、前記少なくとも２つのフレームのそれぞれの本体を含む請求項２記載の方法。
5. 前記集約フレームは、集約ヘッダをさらに含む請求項１記載の方法。
6. 前記集約フレームは、前記異なるタイプの少なくとも２つのフレームの少なくとも一部分のそれぞれに対する、変更されたヘッダをさらに含む請求項１記載の方法。
7. 前記変更されたヘッダのそれぞれは、フレーム制御情報と、シーケンス制御情報と、セキュリティ情報とのうちの少なくとも１つを含む請求項６記載の方法。
8. 前記異なるタイプの少なくとも２つのフレームは、別々の時間量の間での送信のために構成されている請求項１記載の方法。
9. 前記集約フレームが、前記第１の時間量内での送信に適していない場合に、
   前記方法は、
   前記第１の時間量よりも長い第２の時間量を規定することと、
   前記トランシーバによる送信のために前記第１の集約フレームをフォーマットすることとをさらに含み、
   前記集約フレームは、前記第２の時間量内での送信に適している請求項１記載の方法。
10. 前記異なるタイプの少なくとも２つのフレームのうちの第１のフレームは、データフレームと、コマンドフレームと、制御フレームとのうちの１つを含み、前記異なるタイプの少なくとも２つのフレームのうちの第２のフレームは、データフレームと、コマンドフレームと、制御フレームとのうちの異なる１つを含む請求項１記載の方法。
11. 前記異なるタイプの少なくとも２つのフレームのうちの、第１のフレームと、第２のフレームと、第３のフレームとは、データフレームと、コマンドフレームと、制御フレームとのうちの任意の１つを含む請求項１記載の方法。
12. 前記異なるタイプの少なくとも２つのフレームの少なくとも一部分のそれぞれに、セキュリティヘッダ情報と、長さ情報と、フレーム検査シーケンスと、テールビットと、パディングビットとのうちの少なくとも１つを置くことをさらに含む請求項１記載の方法。
13. 前記第１の時間量内での送信に対する前記集約フレームの適性を決定することは、
    前記第１の集約フレームのヘッダの長さを決定することと、
    前記第１の集約フレームの本体の長さを決定することと、
    前記ヘッダの長さと前記本体の長さとを前記第１の時間量のサイズと相関させることとを含む請求項１記載の方法。
14. 前記第１の集約フレームの本体は、前記変更されたヘッダを有する、前記異なるタイプの少なくとも２つのフレームを含む請求項１３記載の方法。
15. 前記異なるタイプの少なくとも２つのフレームのうちの１つが、集約を好まないタイプのものであるか否かを決定することと、
    前記異なるタイプの少なくとも２つのフレームのうちの１つが、集約を好まないタイプのものである場合に、前記異なるタイプの少なくとも２つのフレームを独立的に送信することをさらに含む請求項１記載の方法。
16. 前記異なるタイプの少なくとも２つのフレームが送信されることになるネットワークに相当な負荷がかかっているか否かを決定することと、
    前記異なるタイプの少なくとも２つのフレームが送信されることになるネットワークに相当な負荷がかかっていない場合に、前記異なるタイプの少なくとも２つのフレームを独立的に送信することとをさらに含む請求項１記載の方法。
17. 応答メッセージの、前記第１の時間量内での送信に対する適性を決定することと、
    前記応答メッセージが、前記第１の時間量内での送信に適していない場合に、前記異なるタイプの少なくとも２つのフレームを独立的に送信することとをさらに含む請求項１記載の方法。
18. 前記トランシーバによる送信のために構成されている第３のフレームを識別することと、
    前記少なくとも２つのフレームのそれぞれの少なくとも一部分と、前記第３のフレームの少なくとも一部分とを有する第２の集約フレームの、前記第１の時間量内でのトランシーバによる送信に対する適性を決定することと、
    前記第２の集約フレームが、前記第１の時間量内での送信に適している場合に、前記少なくとも２つのフレームの少なくとも一部分と、前記第３のフレームの少なくとも一部分とのそれぞれに、変更されたヘッダを置くことをさらに含む請求項１記載の方法。
19. 前記第３のフレームは、前記異なるタイプの少なくとも２つのフレームのタイプとは異なるタイプを有する請求項１３記載の方法。
20. 前記少なくとも２つのフレームは、音声と、ビデオと、物理的な物体または物質を表すデータとのうちの少なくとも１つを表す請求項１記載の方法。
21. 前記時間量は、少なくとも１つのメディアアクセススロットを含む請求項１記載の方法。
22. 前記通信方法は、ワイヤレス通信方法を含む請求項１記載の方法。
23. 前記複数のフレームは、ワイメディアＭＡＣフレームを含む請求項１記載の方法。
24. 情報を通信するように構成されている通信デバイスにおいて、
    複数のフレームの各フレームは、ヘッダと本体とを含み、複数のフレームは、異なるタイプの少なくとも２つのフレームを含み、送信機による送信のために構成されている複数のフレームと、
    第１の集約フレームの、第１の時間量内での送信に対する適性を決定するように構成されているプロセッサと、
    前記第１の集約フレームが、前記第１の時間量内での送信に適していると前記プロセッサが決定した場合に、送信するために前記第１の集約フレームをフォーマットするように構成されているメッセージフォーマッタとを具備し、
    前記第１の集約フレームは、ヘッダと、本体と、前記異なるタイプの少なくとも２つのフレームのそれぞれの少なくとも一部分とを含む通信デバイス。
25. 前記第１の集約フレームが、前記第１の時間量内での送信に適していないと前記プロセッサが決定した場合に、前記プロセッサは、前記第１の集約フレームの、前記第１の時間量よりも長い拡張時間量内での送信に対する適性を決定するように構成されており、
    前記第１の集約フレームが、前記拡張時間量内で送信するのに適していると前記プロセッサが決定した場合に、前記メッセージフォーマッタは、前記送信機による送信のために前記第１の集約フレームをフォーマットするようにさらに構成されている請求項２４記載のデバイス。
26. 前記送信機は、前記拡張時間量の間に、前記第１の集約フレームを送信するように構成されている請求項２４記載のデバイス。
27. 前記メッセージフォーマッタは、前記第１の集約フレーム中の、前記異なるタイプの少なくとも２つのフレームの少なくとも一部分のそれぞれに、変更されたヘッダを置くようにさらに構成されている請求項２４記載のデバイス。
28. 前記第１の集約フレームの本体は、前記変更されたヘッダを有する、前記異なるタイプの少なくとも２つのフレームのそれぞれの少なくとも一部分を含む請求項２８記載のデバイス。
29. 前記変更されたヘッダのそれぞれは、フレーム制御情報と、シーケンス制御情報と、セキュリティ情報とのうちの少なくとも１つを含む請求項２８記載のデバイス。
30. 前記異なるタイプの少なくとも２つのフレームのうちの第１のフレームは、データフレームと、コマンドフレームと、制御フレームとのうちの１つを含み、前記異なるタイプの少なくとも２つのフレームのうちの第２のフレームは、データフレームと、コマンドフレームと、制御フレームとのうちの異なる１つを含む請求項２４記載のデバイス。
31. 前記異なるタイプの少なくとも２つのフレームのうちの、第１のフレームと、第２のフレームと、第３のフレームとは、データフレームと、コマンドフレームと、制御フレームとのうちの任意の１つを含む請求項２４記載のデバイス。
32. 前記メッセージフォーマッタは、前記異なるタイプの少なくとも２つのフレームの少なくとも一部分のそれぞれに、セキュリティヘッダ情報と、長さ情報と、フレーム検査シーケンスと、テールビットと、パディングビットとのうちの少なくとも１つを置くように構成されている請求項２４記載のデバイス。
33. 前記プロセッサは、
    前記第１の時間期間内での送信に対する前記第１の集約フレームの適性を前記プロセッサが決定するときに、
    前記第１の集約フレームのヘッダの長さを決定し、
    前記第１の集約フレームの本体の長さを決定し、
    前記第１の集約フレームのヘッダの長さと、前記第１の集約フレームの本体の長さとを前記第１の時間量のサイズと相関させるように構成されている請求項２４記載のデバイス。
34. 前記プロセッサは、前記異なるタイプの少なくとも２つのフレームのうちの少なくとも１つが、集約を好まないタイプのものであるか否かを決定するようにさらに構成されており、
    前記異なるタイプの少なくとも２つのフレームのうちの少なくとも１つが、集約を好まないタイプのものであると前記プロセッサが決定した場合に、前記メッセージフォーマッタは、前記異なるタイプの少なくとも２つのフレームを、独立的な送信のためにフォーマットするようにさらに構成されている請求項２４記載のデバイス。
35. 前記プロセッサは、前記異なるタイプの少なくとも２つのフレームが送信されることになるネットワークに相当な負荷がかかっているか否かを決定するようにさらに構成されており、
    前記異なるタイプの少なくとも２つのフレームが送信されることになるネットワークに相当な負荷がかかっていないと前記プロセッサが決定した場合に、前記メッセージフォーマッタは、前記異なるタイプの少なくとも２つのフレームを、独立的な送信のためにフォーマットするようにさらに構成されている請求項２４記載のデバイス。
36. 前記プロセッサは、応答メッセージの、前記第１の時間量内での送信に対する適性を決定するようにさらに構成されており、
    前記応答メッセージを前記第１の時間量内で送信することができないと前記プロセッサが決定した場合に、前記メッセージフォーマッタは、前記異なるタイプの少なくとも２つのフレームを、独立的な送信のためにフォーマットするようにさらに構成されている請求項２４記載のデバイス。
37. 前記複数のフレームは、音声と、ビデオと、物理的な物体または物質を表すデータとのうちの少なくとも１つを表す請求項２４記載のデバイス。
38. 前記時間量は、少なくとも１つのメディアアクセススロットを含む請求項２４記載のデバイス。
39. 前記通信デバイスは、ワイヤレス通信デバイスを含む請求項２４記載のデバイス。
40. 前記複数のフレームは、ワイメディアＭＡＣフレームを含む請求項２４記載のデバイス。
41. 前記送信機は、前記第１の時間量の間に、前記第１の集約フレームを送信するように構成されている請求項２４記載のデバイス。
42. 前記異なるタイプの少なくとも２つのフレームは、異なる時間量の間の送信のために構成されている請求項２４記載のデバイス。
43. 通信システム中で情報を通信する方法において、
    前記情報は、複数のフレームを含み、
    前記方法は、
    異なるタイプの少なくとも２つのフレームの、第１の時間量内でのトランシーバによる送信に対する適性を決定することと、
    前記異なるタイプの少なくとも２つのフレームが、前記第１の時間量内での送信に適している場合に、前記第１の時間量内の前記トランシーバによる送信のために、前記異なるタイプの少なくとも２つのフレームをフォーマットすることとを含み、
    各フレームは、ヘッダと本体とを含む方法。
44. 前記方法は、
    前記少なくとも２つのフレームが、前記第１の時間量内での送信に適していない場合に、前記異なるタイプの少なくとも２つのフレームの、前記第１の時間量よりも長い第２の時間量内での送信に対する適性を決定することと、
    前記異なるタイプの少なくとも２つのフレームが、前記第２の時間量内での送信に適している場合に、前記第２の時間量内での前記トランシーバによる送信のために、前記異なるタイプの少なくとも２つのフレームをフォーマットすることとをさらに含む請求項４４記載の方法。
45. 通信システム中で情報を通信するためのコンピュータプログラムプロダクトにおいて、
    前記情報は、複数のフレームを含み、
    前記コンピュータプログラムプロダクトは、
    トランシーバにより送信するように構成されている、異なるタイプの少なくとも２つのフレームをコンピュータに識別させるためのコードと、
    第１の集約フレームの、第１の時間量内での前記トランシーバによる送信に対する適性を前記コンピュータに決定させるためのコードと、
    前記集約フレームが、前記第１の時間量内での送信に適していると決定した場合に、前記トランシーバによる送信のために、前記集約フレームを前記コンピュータにフォーマットさせるためのコードとを有するコンピュータ読取可能媒体を含み、
    各フレームは、ヘッダと本体とを有し、
    前記第１の集約フレームは、前記少なくとも２つのフレームのそれぞれの少なくとも一部分を有するコンピュータプログラムプロダクト。
46. 情報を通信するように構成されている通信デバイスにおいて、
    複数のフレームのうちの各フレームは、ヘッダと本体とを含み、前記複数のフレームは、異なるタイプの少なくとも２つのフレームを含み、
    前記複数のフレームを送信する手段と、
    前記異なるタイプの少なくとも２つのフレームのそれぞれの少なくとも一部分を含む集約フレームの、第１の時間量内での送信に対する適性を決定する手段と、
    前記第１の集約フレームが、前記第１の時間量内での送信に適していると決定した場合に、前記送信手段による送信のために前記第１の集約フレームをフォーマットする手段とを具備する通信デバイス。

Images