(57)【要約】【課題】媒体アクセス制御のための方法、装置およびシステム【解決手段】高スループットシステムの効率的な使用のためのＭＡＣ処理に対応する実施形態が開示されている。一態様では、装置は１つまたは複数のデータフローから１個または複数のパケットを受信するため、及び該１個または複数のパケットから１つまたは複数の第１層プロトコルデータユニット（ＰＤＵ）を生成するための第１の層を備える。別の態様では、該１個または複数のＭＡＣ層ＰＤＵに基づいて１つまたは複数のＭＡＣフレームを生成するために第２の層が配備されている。更に別の態様では、ＭＡＣフレームは１個または複数のＭＡＣ層ＰＤＵを生成するために配備されている。ＭＡＣフレームは、ＭＡＣフレームは１つまたは複数の割り当てを送信するために制御チャネルを備えてよい。ＭＡＣフレームは割り当てに従って１つまたは複数のトラフィックセグメントを備えてよい。【選択図】図３
2010200363.tif 000002
【特許請求の範囲】
【請求項１】
各々が１個または複数のパケットを備える１つまたは複数のフローを受信し、前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成するための、第１の層と、
各ＭＡＣフレームが、１つまたは複数の媒体割り当てを送信するための制御チャネルと、
各々が媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備え、前記１つまたは複数のＭＡＣ層ＰＤＵｓに基づいて１つまたは複数のＭＡＣフレームを生成するための、第２の層と、
を具備する装置。
【請求項２】
記ＭＡＣフレームは、前記ＭＡＣフレームのパラメータを送信するための放送チャネルをさらに具備する請求項１記載の装置。
【請求項３】
前記ＭＡＣフレームは、ＭＡＣフレーム境界を示すビーコンをさらに具備する請求項１記載の装置。
【請求項４】
前記制御チャネルは複数のサブチャネルを備え、前記サブチャネルの各々が１つまたは複数の割り当てを備え、各サブチャネルが複数の伝送フォーマットの１つで送信される請求項１記載の装置。
【請求項５】
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の順方向トラフィックセグメントを具備する請求項１記載の装置。
【請求項６】
前記１つまたは複数の順方向トラフィックセグメントは、第１の装置から第２の装置へＭＡＣ ＰＤＵの伝送を備える請求項５記載の装置。
【請求項７】
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の逆方向トラフィックセグメントを具備する請求項１記載の装置。
【請求項８】
前記１つまたは複数の逆方向トラフィックセグメントは、第２の装置から第１の装置へＭＡＣ ＰＤＵの伝送を備える請求項７記載の装置。
【請求項９】
前記１つまたは複数のトラフィックセグメントは、１つまたは複数のピアーピアトラフィックセグメントを具備する請求項１記載の装置。
【請求項１０】
前記１つまたは複数のピアーピアトラフィックセグメントは、特定の伝送を備える請求項９記載の装置。
【請求項１１】
前記１つまたは複数のピアーピアトラフィックセグメントは、予定された伝送を備える請求項９記載の装置。
【請求項１２】
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の競合をベースにしたトラフィックセグメントを備える請求項１記載の装置。
【請求項１３】
前記１つまたは複数のトラフィックセグメントは、１つまたは複数のランダムアクセストラフィックセグメントを備える請求項１記載の装置。
【請求項１４】
前記第１の層は、適応層ＰＤＵを生成するための適応層を備える請求項１記載の装置。
【請求項１５】
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのセグメンテーションを実行する請求項１４記載の装置。
【請求項１６】
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのリアセンブリを実行する請求項１４記載の装置。
【請求項１７】
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのフロー分類を実行する請求項１４記載の装置。
【請求項１８】
前記フロー分類は、サービスの質（ＱｏＳ）に従って実行される請求項１７記載の装置。
【請求項１９】
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのためのマルチキャストマッピングを実行する請求項１４記載の装置。
【請求項２０】
前記ＭＡＣ層は、前記適応層ＰＤＵからデータリンク層ＰＤＵを生成するためのデータリンク層を備える請求項１４記載の装置。
【請求項２１】
前記ＭＡＣ層は、ＭＡＣ層ＰＤＵを形成するために１つまたは複数のフローに対応する１つまたは複数のデータリンク層ＰＤＵを統合する共通のＭＡＣ層を備える請求項２０記載の装置。
【請求項２２】
第１の層で各々が１個または複数のパケットを備える１つまたは複数のフローを受信し、
前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成し、
１つまたは複数の媒体割り当てを送信するための制御チャネルと、媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備えるＭＡＣフレームを形成する
ことを具備する方法。
【請求項２３】
媒体割り当てに従ってトラフィックセグメントでＭＡＣ層ＰＤＵを送信することをさらに備える請求項２２記載の方法。
【請求項２４】
媒体割り当てに従ってトラフィックセグメントでＭＡＣ層ＰＤＵを受信することをさらに備える請求項２２記載の方法。
【請求項２５】
前記制御チャネルを送信することをさらに備える請求項２２記載の方法。
【請求項２６】
前記制御チャネルは複数のサブチャネルを備え、前記サブチャネルの各々が１つまたは複数の割り当てを備え、各サブチャネルが複数の伝送フォーマットの１つで送信される請求項２５記載の方法。
【請求項２７】
前記１つまたは複数のフローからの１個または複数のパケットから適応層ＰＤＵｓを生成するために、適応層処理を実行することをさらに備える、請求項２２記載の方法。
【請求項２８】
前記適応層ＰＤＵｓからデータリンク層ＰＤＵｓを生成するためにデータリンク層処理を実行することをさらに備える請求項２７記載の方法。
【請求項２９】
ＭＡＣ層ＰＤＵを形成するために、１つまたは複数の適応層ＰＤＵｓを統合するために共通のＭＡＣ処理を実行することをさらに備える請求項２７記載の方法。
【請求項３０】
順方向トラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
【請求項３１】
逆方向トラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
【請求項３２】
ピアーピアトラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
【請求項３３】
ランダムアクセストラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
【請求項３４】
各フローが１個または複数のパケットを備え、前記１つまたは複数のフローからの１個または複数のパケットから１つまたは複数のＭＡＣ層ＰＤＵｓを生成する、前記１つまたは複数のフローを受信するための手段と、
１つまたは複数のＭＡＣ層ＰＤＵｓに基づいてＭＡＣフレームを生成するための手段とを具備し、
前記ＭＡＣフレームは、１つまたは複数の媒体割り当てを送信するための制御チャネルと、それぞれが媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵ）を送信するための、１つまたは複数のトラフィックセグメントとを備える、
装置。
【請求項３５】
トラフィックセグメントでＭＡＣ層ＰＤＵを送信するための手段をさらに備える請求項３４記載の装置。
【請求項３６】
トラフィックセグメントでＭＡＣ層を受信するための手段をさらに備える請求項３４記載の装置。
【請求項３７】
各々が１個または複数のパケットを備える１つまたは複数のフローを第１の層で受信するステップと、
前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成するステップと、
１つまたは複数の媒体割り当てを送信するための制御チャネルと、各々が媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備えるＭＡＣフレームを形成するステップと、
を実行するために動作可能なコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（米国特許法合衆国法典第３５巻第１１９条の優先権の主張）
特許のための本出願は、すべてがこの譲受人に譲渡され、これにより参照することにより本書に明示的に含まれる、以下の米国仮特許出願に対する優先権を主張する。
【０００２】
２００３年１０月１５日に出願された「無線通信システムにおける相互運用性及び下位互換性を提供するための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ａｎｄ Ｂａｃｋｗａｒｄ Ｃｏｍｐａｔｉｂｉｌｉｔｙ ｉｎ Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍｓ）」と題される仮出願第６０／５１１，７５０号
２００３年１０月１５日に出願された「高性能無線ＬＡＮ環境における媒体アクセス制御のための方法、装置及びシステム（Ｍｅｔｈｏｄ，Ａｐｐａｒａｔｕｓ，ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ ｉｎ ａ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｗｉｒｅｌｅｓｓ ＬＡＮ Ｅｎｖｉｒｏｎｍｅｎｔ）」と題される仮出願第６０／５１１，９０４号
２００３年１０月２１日に出願された「ＭＩＭＯ ＷＬＡＮシステムにおけるピアツーピア接続（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｃｏｎｎｅｃｔｉｏｎｓ ｉｎ ＭＩＭＯ ＷＬＡＮ Ｓｙｓｔｅｍ）」と題される仮出願第６０／５１３，２３９号
２００３年１２月１日に出願された「超高速無線ＬＡＮ用サブネットワークプロトコルスタックのための方法、装置及びシステム（Ｍｅｔｈｏｄ，Ａｐｐａｒａｔｕｓ，ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｓｕｂ−Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ ｆｏｒ Ｖｅｒｙ Ｈｉｇｈ Ｓｐｅｅｄ Ｗｉｒｅｌｅｓｓ ＬＡＮ）」と題される仮出願第６０／５２６，３４７号
２００３年１２月１日に出願された「高性能無線ＬＡＮ環境においてプロトコルデータユニットを多重化するための方法、装置及びシステム（Ｍｅｔｈｏｄ，Ａｐｐａｒａｔｕｓ，ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔｓ ｉｎ ａ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｗｉｒｅｌｅｓｓ ＬＡＮ Ｅｎｖｉｒｏｎｍｅｎｔ）」と題される仮出願第６０／５２６，３５６号
２００３年１２月２３日に出願された「無線通信媒体アクセス制御（ＭＡＣ）機能拡張（Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ （ＭＡＣ） Ｅｎｈａｎｃｅｍｅｎｔｓ）」と題される仮出願第６０／５３２，７９１号
２００４年２月１８日に出願された「適応調整関数（Ａｄａｐｔｉｖｅ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）（ＡＣＦ）」と題される仮出願第６０／５４５，９６３号
２００４年６月２日に出願された「ロバストな無線ネットワークのための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｒｏｂｕｓｔ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋ）」と題される仮出願第６０／５７６，５４５号
２００４年７月８日に出願された「複数ユーザの間の分散通信リソースのための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅｓ Ａｍｏｎｇ Ｍｕｌｔｉｐｌｅ Ｕｓｅｒｓ）」と題される仮出願第６０／５８６，８４１号、及び
２００４年８月１１日に出願された「無線通信のための方法、装置及びシステム（Ｍｅｔｈｏｄ，Ａｐｐａｒａｔｕｓ，ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）」と題される仮出願第６０／６００，９６０号
本発明は概して通信に関し、さらに詳細には無線ＬＡＮプロトコルスタックに関する。
【背景技術】
【０００３】
無線通信システムは、音声とデータ等の多様な種類の通信を提供するために幅広く配備されている。典型的な無線データシステム、つまりネットワークは１つまたは複数の共用資源に対して複数のユーザアクセスを提供する。システムは、周波数分割多重化（ＦＤＭ）、時分割多重化（ＴＤＭ）、符号分割多重化（ＣＤＭ）等の種々の多元接続技法を使用してよい。
【０００４】
例の無線ネットワークはセルラーベースのデータシステムを含む。以下は複数のこのような例である。（１）「デュアルモード広帯域スペクトル拡散セルラーシステム用ＴＩＡ／ＥＩＡ−９５Ｂ移動局−基地局互換性規格（ＴＩＡ／ＥＩＡ−９５−Ｂ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ−Ｂａｓｅ Ｓｔａｔｉｏｎ Ｃｏｍｐａｔｉｂｉｌｉｔｙ Ｓｔａｎｄａｒｄ ｆｏｒ Ｄｕａｌ−Ｍｏｄｅ Ｗｉｄｅｂａｎｄ Ｓｐｒｅａｄ Ｓｐｅｃｔｒｕｍ Ｃｅｌｌｕｌａｒ Ｓｙｓｔｅｍ）」（ＩＳ−９５規格）、（２）「スリージーピーピー（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）」（３ＧＰＰ）という名称のコンソーシアムによって提供され、文書番号第３Ｇ ＴＳ ２５．２１１号、第３Ｇ ＴＳ ２５．２１２号、第３Ｇ ＴＳ ２５．２１３号及び第３Ｇ ＴＳ ２５．２１４号（Ｗ−ＣＤＭＡ規格）を含む一式の文書の中で具現化されている規格、（３）「スリージーピーピーツー（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２）」（３ＧＰＰ２）という名称のコンソーシアムにより提供され、「ｃｄｍａ２０００スペクトル拡散システム用ＴＲ−４５．５物理層規格（ＴＲ−４５．５ Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｓｔａｎａｒｄ ｆｏｒ ｃｄｍａ２０００ Ｓｐｒｅａｄ Ｓｐｅｃｔｒｕｍ Ｓｙｔｅｍｓ）」に具現化される規格（ＩＳ−２０００規格）、及び（４）ＴＩＡ／ＥＩＡ／ＩＳ−８５６規格（ＩＳ−８５６規格）に準拠する高データレート（ＨＤＲ）システム。
【０００５】
無線システムの他の例は、ＩＥＥＥ ８０２．１１規格（つまり、８０２．１１（ａ）、（ｂ）または（ｇ））等の無線ローカルエリアネットワーク（ＷＬＡＮ）を含む。これらのネットワークの改善策は直交周波数分割多重（ＯＦＤＭ）変調技法を備える多入力多出力（ＭＩＭＯ）ＷＬＡＮを配備する上で達成されてよい。
【０００６】
無線システム設計が進化するにつれて、さらに高速のデータレートが使用可能になってきた。より高速のデータレートは、音声用途、ビデオ用途、高速データ転送及び多様な他の用途等の高度な用途の可能性を開いた。しかしながら、多様な用途はそれらのそれぞれのデータ転送のための異なる要件を有する場合がある。多くの種類のデータは待ち時間とスループットの要件を有してよい、あるいはなんらかのサービスの質（ＱｏＳ）保証を必要としてよい。資源管理を行わない場合、システムの容量は削減され、システムは効率的に動作しない可能性がある。
【０００７】
媒体アクセス制御（ＭＡＣ）プロトコルは、一般的には多くのユーザ間で共用通信資源を割り当てるために使用される。ＭＡＣプロトコルは、一般的にはデータを送受するために使用される物理層にさらに高い層を接続する。データレートの加速の恩恵を受けるために、ＭＡＣプロトコルは共用資源を効率的に活用するように設計されなければならない。
【０００８】
開発されている高性能システムは、物理リンク特性に基づいて幅広く変化してよい複数の速度をサポートする。さまざまなデータアプリケーションタイプの変化する需要、及びシステム内に位置する異なるユーザ端末に対するサポート可能なデータレートの大きな不一致を考慮すると、多様なトラフィックタイプを待ち行列に入れる方法、及び多くの場合本質的に異なる多様な物理リンクでそれらを送信する方法における進化も開発される必要がある。したがって、技術には高スループットシステムの効率的な使用のためのＭＡＣ処理に対するニーズがある。
【発明の開示】
【０００９】
[発明の概要]
ここに開示されている実施形態は高スループットシステムの効率的な使用のためのＭＡＣ処理のための技術のニーズに対処する。一態様では、装置は１つまたは複数のデータフローから１個または複数個のパケットを受信するため、及び該１つまたは複数のパケットから１つまたは複数の第１層プロトコルデータユニット（ＰＤＵ）を生成するための第１の層を備える。別の態様では、第２の層は該１つまたは複数のＭＡＣ層ＰＤＵに基づいて１個または複数個のＭＡＣフレームを生成するために配備される。別の態様では、ＭＡＣフレームは１つまたは複数のＭＡＣ層ＰＤＵを送信するために配備される。ＭＡＣフレームは１つまたは複数の割り当てを送信するための制御チャネルを備えてよい。ＭＡＣフレームは割り当てに従って１つまたは複数のトラフィックセグメントを備えてよい。
【００１０】
多様な他の態様及び実施形態も提示されている。これらの態様は効率的な媒体アクセス制御を提供する利点を有し、低データレートだけではなく高データレートを備える物理層とともに有利に使用される。
【発明を実施するための最良の形態】
【００１１】
無線ＬＡＮ（または新興の伝送技法を使用する類似した応用例）のための超高速ビットレート物理層とともにきわめて効率的で低待ち時間、高スループット動作をサポートするサブネットワークプロトコルスタックがここに開示されている。例のＷＬＡＮは２０ＭＨｚという帯域幅で１００Ｍｂｐｓ（毎秒１００万ビット）を超えるビットレートをサポートする。
【００１２】
プロトコルスタックとともに説明されているのは複数のユーザデータストリームとサブネットワーク制御エンティティ（ＭＵＸ ＰＤＵ）から単一のバイトストリームにプロトコルデータユニット（ＰＤＵ）を多重化するための方法である。バイトストリームはＭＡＣプロトコルデータユニット（ＭＡＣ ＰＤＵ）にフォーマットされ、そのそれぞれが単一のＭＡＣフレームの中に含まれるバーストで送信されてよい。これは、超高速ビットレート物理層とともに、効率的で低待ち時間の高スループット動作のために高性能無線ＬＡＮサブネットワークをサポートする。
【００１３】
サブネットワークプロトコルスタックは、一般的には、ＯＦＤＭ変調、単一搬送波変調技法、超高帯域幅効率動作のための、複数の送信アンテナと複数の受信アンテナ（多入力単一出力（ＭＩＳＯ）システムを含む多入力多出力（ＭＩＭＯ）システム）を使用するシステム、同じ時間間隔の間に複数のユーザ端末にまたは複数のユーザ端末からデータを送信するための空間多重化技法とともに複数の送信アンテナと受信アンテナを使用するシステム、及び複数のユーザのための伝送を同時に可能にするために符号分割多元接続（ＣＤＭＡ）技法を使用するシステムに基づく機構を含むが、これらに限定されない、概して高速データレート、高帯域幅物理層のトランスポート機構をサポートする。
【００１４】
ここに説明されている１つまたは複数の例示的な実施形態は無線データ通信システムの関連で述べられている。この関連での使用は有利であるが、本発明のさまざまな実施形態がさまざまな環境または構成に取り込まれてよい。一般的には、ここに説明されている多様なシステムはソフトウェア制御のプロセッサ、集積回路または個別論理を使用して形成されてよい。応用例全体で参照されてよいデータ、命令、コマンド、情報、信号、記号及びチップは電圧、電流、電磁波、磁場、または磁性粉、または光学場または光学粒子、あるいはその組み合わせによって有利に表される。加えて、各ブロック図に示されるブロックはハードウェアまたは方法ステップを表してよい。方法ステップは、本発明の範囲から逸脱することなく交換できる。単語「例示的な」はここでは「例、インスタンスまたは図解として役立つ」を意味するために使用される。ここに「例示的」として記述される実施形態は、他の実施形態に優って必ずや好ましいまたは有利と解釈される必要されるべきではない。
【００１５】
図１は、１つまたは複数のユーザ端末（ＵＴ）１０６ＡからＮに接続されているアクセスポイント（ＡＰ）１０４を備えるシステム１００の例の実施形態である。該ＡＰとＵＴは無線ローカルエリアネットワーク（ＷＬＡＮ）１２０を通して通信する。例の実施形態では、ＷＬＡＰ１２０は高速ＭＩＭＯ ＯＦＤＭシステムである。しかしながら、ＷＬＡＮ１２０は任意の無線ＬＡＮであってよい。アクセスポイント１０４はネットワーク１０２を介して任意の数の外部装置またはプロセスと通信する。ネットワーク１０２はインターネット、イントラネットまたは任意の他の有線ネットワーク、無線ネットワークまたは光学ネットワークであってよい。接続１１０はネットワークからアクセスポイント１０４に物理層信号を搬送する。装置またはプロセスはＷＬＡＮ１２０でネットワーク１０２に、またはＵＴとして（またはそれとの接続を介して）接続されてよい。ネットワーク１０２またはＷＬＡＮ１２０のどちらかに接続されてよい装置の例は電話、パーソナルデジタルアシスタント（ＰＤＡ）、多様なタイプのコンピュータ（ラップトップ、パーソナルコンピュータ、ワークステーション、任意のタイプの端末）、カメラ、カムコーダ、ウェブカメラ等のビデオデバイス、及び実質的には任意の他のタイプのデータデバイスを含む。プロセスは音声、ビデオ、データ通信等を含んでよい。多様なデータストリームは、変化するサービスの質（ＱｏＳ）技法を使用することによって対処されてよい変化する伝送要件を有してよい。
【００１６】
システム１００は、集中ＡＰ１０４とともに配備される。すべてのＵＴ１０６は例の実施形態でＡＰと通信する。代替実施形態では、当業者に明らかとなるように、システムに対する修正により２つのＵＴ間の直接ピアツーピア通信が対処されてよい。説明を明確にするために、例の実施形態では、物理層トランスポート機構へのアクセスはＡＰによって制御されている。
【００１７】
一実施形態では、ＡＰ１０４はイーサネット（登録商標）適応を提供し、その一例は図２４に示されている。この場合、ＩＰルータ２４１０はネットワーク１０２に（イーサネット接続１１０を介して）接続を提供するためにＡＰ１０４とともに配備されてよい。例えば携帯電話１０６Ａ、パーソナルデジタルアシスタント（ＰＤＡ）１０６Ｂ、ラップトップ１０６Ｃ、ワークステーション１０６Ｄ、パーソナルコンピュータ１０６Ｅ、ビデオカムコーダ１０６Ｆ、及びビデオプロジェクタ１０６Ｇ等の例示的な例ＵＴ１０６が示されている。イーサネットフレームは、（後述される）ＷＬＡＮサブネットワーク１２０上でルータとＵＴ１０６の間を転送されてよい。
【００１８】
イーサネットの適応及び接続性はこの分野で周知である。図２６は、さらに詳しく後述される例の層と統合されるような、例えばそれぞれＵＴ１０６とＡＰ１０４用のイーサネット適応プロトコルスタック２６４０と２６５０を示す。ＵＴプロトコルストック２６４０は上位層２６１０、ＩＰ層２６１５、イーサネットＭＡＣ層２６２０Ａ、適応層３１０Ａ、データリンク層３２０Ａ、及び物理層（ＰＨＹ）２４０Ａを備える。ＡＰプロトコルスタック２６５０は（ＲＦリンク１２０を介してＵＴ ＰＨＹ２４０Ａに接続されている）ＰＨＹ２４０Ｂ、データリンク層３２０Ｂ、及び適応層３１０Ｂを備える。イーサネットＭＡＣ２６２０Ｂは、有線ネットワーク１０２と接続される１１０でイーサネットＰＨＹ２６２５に適応層３１０Ｂを接続する。
【００１９】
代替実施形態では、ＡＰ１０４はＩＰ適応を提供し、例は図２５に示されている。この場合、ＡＰ１０４は（図２４に関して説明されるように）接続されているＵＴの集合のためのゲートウェイルータとして働く。この場合、ＩＰデータグラムは、ＡＰ１０４によってＵＴ１０６に及びＵＴ１０６から送られてよい。
【００２０】
ＩＰ適応及び接続性はこの分野で周知である。図２７は、さらに詳しく後述されるような例の層と統合されるような、例えばそれぞれＵＴ１０６とＡＰ１０４用のＩＰ適応プロトコルスタック２７４０と２７５０を示す。ＵＴプロトコルスタック２７４０は上位層２７１０、ＩＰ層２７２０Ａ、適応層３１０Ａ、データリンク層３２０Ａ、及び物理層（ＰＨＹ）２４０Ａを備える。ＡＰプロトコルスタック２７５０は（ＲＦリンク１２０を介してＵＴ ＰＨＹ２４０Ａに接続されている）ＰＨＹ ２４０Ｂ、データリンク層３２０Ｂ及び適応層３１０Ａを備える。ＩＰ層２７２０Ｂは、イーサネットＰＨＹ２７３０に接続されているイーサネットＭＡＣ２７２５に適応層３１０Ｂを接続する。イーサネットＰＨＹ２７３０は１１０で有線ネットワーク１０２と接続されている。
【００２１】
図２は、アクセスポイント１０４またはユーザ端末１０６として構成されてよい無線通信装置の例の実施形態を描く。アクセスポイント１０４の構成は図２に示されている。トランシーバ２１０はネットワーク１０２の物理層要件に従って接続１１０で受信、送信する。ネットワーク１０２に接続されている装置またはアプリケーションから、または装置またはアプリケーションへのデータはＭＡＣプロセッサ２２０に配信される。これらのデータはここではフロー２６０と呼ばれている。フローはさまざまな特性を有してよく、フローと関連付けられる用途のタイプに基づいて異なる処理を要求してよい。例えば、ビデオまたは音声は低待ち時間フロー（ビデオは通常音声より高いスループット要件を有する）として特徴付けられてよい。多くのデータアプリケーションは待ち時間には感度が低いが、さらに高いデータ完全性要件を有してよい（つまり、音声はいくつかのパケット損失に耐えてよく、ファイル転送は通常パケット損失に耐えない）。
【００２２】
ＭＡＣプロセッサ２２０はフロー２６０を受け取り、物理層での伝送のためにそれらを処理する。ＭＡＣプロセッサ２２０は物理層データも受け取り、出フロー２６０のためのパケットを形成するために該データを処理する。内部制御及びシグナリングもＡＰとＵＴの間で通信される。ＭＡＣプロトコルデータユニット（ＭＡＣ ＰＤＵ）は接続２７０上で無線ＬＡＮトランシーバ２４０に配信され、無線ＬＡＮトランシーバ２４０から受信される。フローとコマンドのＭＡＣ ＰＤＵへの変換及びその逆は以下に詳説される。多様なＭＡＣ ＩＤに対応するフィードバック２８０が、さらに詳しく後述される多様な目的のために物理層（ＰＨＹ）２４０からＭＡＣプロセッサ２２０に返される。フィードバック２８０は、（ユニキャストチャネルだけではなくマルチキャストも含む）チャネルについてサポート可能な速度、変調フォーマット及び多様な他のパラメータを含む任意の物理層情報を備えてよい。
【００２３】
例の実施形態では、適応層（ＡＤＡＰ）とデータリンク制御層（ＤＬＣ）はＭＡＣプロセッサ２２０で実行される。物理層（ＰＨＹ）は無線ＬＡＮトランシーバ２４０で実行される。当業者は多様な関数のセグメンテーションが種々の構成のどれかで行われてよいことを認識するであろう。ＭＡＣプロセッサ２２９は、物理層のための処理のいくつかまたはすべてを実行してよい。無線ＬＡＮトランシーバはＭＡＣ処理またはその下位区分を実行するためのプロセッサを含んでよい。任意の数のプロセッサ、特殊目的ハードウェアまたはその組み合わせが配備されてよい。
【００２４】
ＭＡＣプロセッサ２２０は汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、または特殊目的プロセッサであってよい。ＭＡＣプロセッサ２２０は多様なタスク（詳細は図示せず）を支援するために特殊目的ハードウェアと接続されてよい。多様なアプリケーションは、外部で接続されているコンピュータ等の外部で接続されているプロセッサで、あるいはネットワーク接続上で実行されてよいか、アクセスポイント１０４（図示しない）内の追加のプロセッサで実行してよいか、あるいはＭＡＣプロセッサ２２０自体で実行してよい。ＭＡＣプロセッサ２２０は、ここに説明されている多様な手順と方法を実行するための命令だけではなくデータも記憶するために使用されてよい、メモリ２５５と接続されて示されている。当業者は、メモリ２５５が、ＭＡＣプロセッサ２２０内に全体でまたは部分的に埋め込まれてよい多様な種類の１つまたは複数のメモリ構成要素から構成されてよいことを認識するであろう。
【００２５】
ここに説明されている関数を実行するための命令とデータを記憶することに加えて、メモリ２５５は（詳しく後述される）多様な待ち行列と関連付けられたデータを記憶するために使用されてもよい。メモリ２５５は（後述される）ＵＴプロキシ待ち行列を含んでよい。
【００２６】
無線ＬＡＮトランシーバ２４０は任意のタイプのトランシーバであってよい。例の実施形態では、無線ＬＡＮトランシーバ２４０は、ＭＩＭＯまたはＭＩＳＯインタフェースと動作されてよいＯＦＤＭトランシーバである。ＯＦＤＭ、ＭＩＭＯ、及びＭＩＳＯは当業者にとって公知である。多様な例のＯＦＤＭトランシーバ、ＭＩＭＯトランシーバ、及びＭＩＳＯトランシーバは、本発明の譲受人に譲渡されている２００３年８月２７日に出願された「広帯域ＭＩＳＯシステムとＭＩＭＯシステムのための周波数に無関係の空間処理（ＦＲＥＱＵＥＮＣＹ−ＩＮＤＥＰＥＮＤＥＮＴ ＳＰＡＴＩＡＬ−ＰＲＯＣＥＳＳＩＮＧ ＦＯＲ ＷＩＤＥＢＡＮＤ ＭＩＳＯ ＡＮＤ ＭＩＭＯＳＹＳＴＥＭＳ）」と題される同時係属米国特許出願第１０／６５０，２９５号に詳説されている。
【００２７】
無線ＬＡＮトランシーバ２４０はアンテナ２５０ＡからＮと接続して示されている。任意の数のアンテナが多様な実施形態でサポートされてよい。アンテナ２５０は、ＷＬＡＮ１２０で送受するために使用される。
【００２８】
無線ＬＡＮトランシーバ２４０は該１本または複数本のアンテナのそれぞれに接続されている空間プロセッサを備えてよい。空間プロセッサは、アンテナごとに独立して伝送のためのデータを処理してよい。独立処理の例はチャネル推定値、ＵＴからのフィードバック、チャネル逆転またはこの分野で公知の種々の他の技法に基づいてよい。処理は種々の空間処理技法のどれかを使用して実行される。この種の多様なトランシーバはビーム形成、ビームステアリング、固有ステアリング、または既定のユーザ端末へ及び既定のユーザ端末からスループットを高めるための他の空間技法を使用してよい。ＯＦＤＭシンボルが送信される例の実施形態では、空間プロセッサはＯＦＤＭサブチャネルまたはビンのそれぞれを処理するためのサブ空間（ｓｕｂ−ｓｐａｔｉａｌ）プロセッサを備えてよい。
【００２９】
例のシステムでは、ＡＰはＮ本のアンテナを有してよく、例のＵＴはＭ本のアンテナを有してよい。このようにしてＡＰとＵＴのアンテナの間にはＭｘＮの経路がある。これらの複数の経路を使用してスループットを改善するための種々の空間技法がこの分野で公知である。空間時間送信ダイバーシティ（ＳＴＴＤ）システム（ここでは「ダイバーシティ」とも呼ばれる）では、伝送データはデータの単一のストリームとしてすべてのアンテナを横切ってフォーマットされ、符号化され、送られる。Ｍ送信アンテナとＮ受信アンテナを用いると、形成されてよいＭＩＮ（Ｍ、Ｎ）独立チャネルがあってよい。空間多重化はこれらの独立した経路を利用し、伝送速度を加速するために独立した経路のそれぞれで異なるデータを送信してよい。
【００３０】
ＡＰとＵＴ間のチャネルの特性を学習する、または特性に適応するための多様な技法が公知である。一意のパイロットが各送信アンテナから送信されてよい。パイロットは各受信アンテナで受信され、測定される。チャネルフィードバックは次に伝送で使用するために送信装置に返されてよい。チャネル反転層は、計算上集約的であってよいが、前処理と伝送を可能にする１つの技法である。固有分解は実行されてよく、ループバックテーブルが速度を決定するために利用されてよい。チャネル分解を回避するための代替技法は、空間処理を簡略化するためにパイロットの固有ステアリングを使用することである。受信機での処理の簡略化のために、先行ひずみ技法も公知である。
【００３１】
このようにして、現在のチャネルの状態に応じて、変化するデータ速度はシステム全体で多様なユーザ端末への伝送に使用可能である。特にＡＰと各ＵＴ間の特定のリンクは複数のＵＴにより共用されてよいリンクより高性能となる可能性がある。この例は詳しく後述される。無線ＬＡＮトランシーバ２４０はＡＴとＵＴの間の物理リンクのためにどちらの空間処理が使用されているのかに基づいてサポート可能な速度を決定してよい。この情報は詳しく後述されるＭＡＣ処理での使用のために接続２８０でフィードバックされてよい。
【００３２】
アンテナの数は、ＵＴのデータニーズに応じて配備されてよい。例えば、ＰＤＡは２本で満足する可能性があるが、高精細度ビデオディスプレイは、例えばその高い帯域幅要件のために４本のアンテナを備えてよい。例のアクセスポイントは４本のアンテナを有してよい。
【００３３】
ユーザ端末１０６は図２に描かれているアクセスポイント１０４に類似した様式で配備されてよい。（ＵＴは、有線または無線どちらかのこのようなトランシーバを有する可能性があるが）フロー２６０をＬＡＮトランシーバに接続させる代わりに、フロー２６０は、通常、ＵＴまたはそれと接続されている装置上で動作している１つまたは複数のアプリケーションまたはプロセスから受信される、またはそれらに配信される。ＡＰ１０４またはＵＴ１０６のどちらかに接続されているさらに高いレベルは任意の型であってよい。ここに説明されている層は例示的にすぎない。
【００３４】
プロトコルスタック
図３は例のサブネットワークプロトコルスタック３００を描く。サブネットワークプロトコルスタック３００は超高ビットレート無線ＬＡＮ物理層と、イーサネットＭＡＣ層またはＴＣＰ／ＩＰネットワーク層等のなんらかの他のネットワークのネットワーク層またはＭＡＣ層の間でインタフェースとしての機能を果たしてよい。プロトコルスタック３００の多様な機能が超高性能無線ＬＡＮ物理層を最大限に利用するために配備されてよい。例のプロトコルスタックは多様な利点を提供するように設計されてよく、例は（ａ）プロトコルにより消費されるスループットオーバヘッドの量を最小限に抑えること、（ｂ）サブネットデータユニットを物理層フレームに圧縮する効率を最大限にすること、（ｃ）ＴＣＰ等の遅延に敏感なトランスポート機構の終端間往復遅延に対する待ち時間の寄与を最小限に抑えること、（ｄ）サブネットユニットのきわめて信頼性の高い順序正しい配信を提供すること、（ｅ）既存のネットワーク層とアプリケーションにサポートと、将来のネットワークとアプリケーションに対処するための十分な柔軟性を提供することと、（ｆ）既存のネットワーク技術と透明に統合することを含む。
【００３５】
プロトコルスタック３００は複数の薄い副層、複数のオペレーティングモード及び複数の外部ネットワークに対するインタフェースをサポートするための機構を有する。図３は適応層３１０、データリンク制御層３２０、及び物理層２４０を描く。層マネージャ３８０は詳しく後述される多様な関数のための通信と制御を提供するために各副層と相互接続する。
【００３６】
図３では、プロトコルスタック３００の例の構成が描かれている。破線は、前述されたようにＭＡＣプロセッサ２２０に配備されてよい構成要素の例の構成を示す。適応層３１０、データリンク制御層３２０、及び層マネージャ３８０が含まれている。この構成では、物理層２４０は、前述されたように接続２７０でＭＡＣプロトコルデータユニット（ＰＤＵ）を受信、送信する。フィードバック接続２８０は、詳しく後述される多様な関数で使用するために物理層情報を提供するために層マネージャ３８０に向けられる。この例は例示的に過ぎない。当業者は、その部分集合を含む説明されたスタック関数の任意の組み合わせを包含するように構成される任意の数の構成要素が、本発明の範囲内に配備されてよいことを認識する。
【００３７】
適応層３１０はさらに高い層への接点を提供する。例えば、適応層は（ＩＰ適応のための）ＩＰスタック、（イーサネット適応のための）イーサネットＭＡＣ、または多様な他のネットワーク層と接続してよい。フロー２６０は物理層２４０でのＭＡＣ処理及び伝送のために１つまたは複数のさらに高い層から受け取られる。フロー２６０は物理層を介して受け取られ、処理され、１つまたは複数のさらに高い層への配信のためにリアセンブルされる。
【００３８】
適応層３１０は、セグメンテーションとリアセンブリ３１２、フロー分類３１４、及びマルチキャストマッピング３１６の関数を備える。フロー分類関数３１４は（１つまたは複数のフロー２６０からの）さらに高い層から受け取られるヘッダパケットを調べ、ユーザ端末またはマルチキャストグループＭＡＣ識別子（ＭＡＣ ＩＤ）に各パケットをマッピングし、適切なサービスの質（ＱｏＳ）処理のためにパケットを分類する。マルチキャストマッピング関数３１６は、マルチキャストユーザデータが（「ＭＡＣ層マルチキャスト」と呼ばれる）マルチキャストＭＡＣ ＩＤを使用して、あるいは（「適応層マルチキャスト」と呼ばれる）複数のユニキャストＭＡＣ ＩＤを通して移送されるべきかどうかを判断し、例は後述される。セグメンテーションとリアセンブリ（ＳＡＲ）関数３１２は、論理リンク（ＬＬ）モードに適切なプロトコルデータユニット（ＰＤＵ）サイズにそれぞれのさらに高い層パケットを適応する。ＳＡＲ関数３１２は、ＭＡＣ ＩＤごとに別個に実行される。フロー分類関数３１４は共通である。
【００３９】
データリンク制御層３２０は論理リンク（ＬＬ）層３３０、ラジオリンク制御（ＲＬＣ）層３４０、システム構成制御３５０、ＭＵＸ関数３６０及び共通ＭＡＣ関数３７０を備える。これらの層のそれぞれのための多様なサブブロックは図３に描かれ、詳しく後述される。示されているブロックは例示的に過ぎない。追加の関数だけではなくこれらの関数の部分集合も多様な代替実施形態で配備されてよい。
【００４０】
物理層２４０は任意のタイプの物理層であってよく、例は前記に詳述されている。例の実施形態はＭＩＭＯ ＯＦＤＭ物理層を使用する。この実施形態の例のパラメータは以下の説明に含まれている。
【００４１】
層マネージャ（ＬＭ）３８０は、ＱｏＳ（サービスの質）、流入制御、及び物理層送信機と受信機のパラメータの制御のために適応層３１０、データリンク制御層３２０、及び物理層２４０に接続する。物理層からのフィードバック２８０がここに説明されている多様な関数を実行する上で使用されてよいことに注意する。例えば、多様なＵＴのためのサポート可能な速度はマルチキャストマッピング３１６またはセグメンテーションとリアセンブリ３１２で使用されてよい。
【００４２】
適応層
フロー分類（ＦＬＣＬ）関数３１４は、入信パケットのパケットヘッダフィールドを、それらをフローの中にマッピングするために調べる。ＩＰ適応が実行される例の実施形態では、以下のフィールドがフロー分類に使用されてよい。（ａ）ＩＰソースアドレスとＩＰ宛先アドレス、（ｂ）ＩＰソースポートとＩＰ宛先ポート、（ｃ）ＩＰ ＤｉｆｆＳｅｒｖコードポイント（ＤＳＣＰ）、（ｄ）リソース予約プロトコル（ＲＳＶＰ）メッセージ、及び（ｅ）リアルタイムトランスポート制御プロトコル（ＲＴＣＰ）メッセージとリアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダ。イーサネット適応が実行される代替実施形態では、フロー分類が８０２．１ｐヘッダフィールドと８０２．１ｑヘッダフィールドを使用してよい。これは層違反になるであろうが、イーサネット適応はＩＰフロー分類を使用することもできる。当業者は代わりに多様な他のタイプのフロー分類が配備されてよいことを理解するであろう。
【００４３】
ＦＬＣＬ３１４は、識別されたフロー２６０が既存のＭＡＣ ＩＤ、論理リンク（ＬＬ）モード及びストリームＩＤ（詳しく後述される）にマッピングするかどうかを判断する。入信パケットが既存のフローにマッピングすると、ＦＬＣＬは追加の処理のためにパケットをセグメンテーションとリアセンブリ（ＳＡＲ）関数３１２に転送する。新しいＭＡＣ ＩＤが必要とされる場合、ラジオリンク制御（ＲＬＣ）３４０内の関連制御関数３４４に要求が転送される。
【００４４】
新しいフローが既存のＭＡＣ ＩＤについて識別される場合、層マネージャ３８０のＱｏＳマネージャ関数３８２が該フローに必要とされる論理リンクモードのタイプを決定する。新しいＬＬモードが初期化されなければならない場合、要求はモード交渉を処理するためにＭＡＣ ＩＤに対応するＬＬＣ関数３３８に転送される。新しいストリームが既存のＬＬモード内で確立される場合、ＬＬＣ関数３３８に要求が転送される。ＱｏＳ待ち行列を維持するための一実施形態は、本発明の譲受人に譲渡されている２００３年１１月２６日に出願された「無線ネットワーク用のサービスの質スケジューラ（ＱＵＡＬＩＴＹ ＯＦ ＳＥＲＶＩＣＥ ＳＣＨＥＤＵＬＥＲ ＦＯＲ Ａ ＷＩＲＥＬＥＳＳ ＮＥＴＷＯＲＫ）」と題される同時係属米国特許出願第１０／７２３，３４６号に詳説されている。
【００４５】
ＩＰまたはイーサネットマルチキャストの例では、マルチキャストマッピング関数３１６が、パケットがマルチキャストＭＡＣ ＩＤにマッピングすることによって、ＭＡＣ層マルチキャストを使用して処理されるべきかどうか、あるいはパケットがここで「適応層マルチキャスト」と呼ばれている複数のユニキャスト伝送として処理されるべきかどうかを判断する。後者のケースでは、マルチキャストマッピング関数３１６は、それが送信されなければならないユニキャストＭＡＣ ＩＤごとに１つ、パケットの複数のコピーを作成し、パケットをセグメンテーションとリアセンブリ（ＳＡＲ）関数３１２に転送する。この態様は図１５から図１６に関してさらに詳しく後述される。
【００４６】
ちょうど説明されたように、フロー分類関数３１４は、存在する場合、ＭＡＣ ＩＤ、ＬＬモード及びストリームＩＤにパケットをマッピングする。セグメンテーションとリアセンブリ関数３１２は上位層パケット（つまり、ＩＰデータグラムまたはイーサネットフレーム）を論理リンクモードでのトランスポートに適したセグメントに分割する。この態様の例の実施形態は、図１７から図１８に関してさらに後述される。この例では、セグメントごとに１バイトの適応層ヘッダが加えられ、受信機内で対応するＳＡＲ関数にセグメントが順序正しく配信されるときにリアセンブリを可能にする。適応層プロトコルデータユニット（ＰＤＵ）は次に分類パラメータ、つまりＭＡＣ ＩＤ、ＬＬモード及びストリームＩＤとともに処理のためにデータリンク制御層３２０に渡される。
【００４７】
データリンク制御層
図４は、多様な層を横断するときのユーザデータパケット４１０（つまりＩＰデータグラム、イーサネットフレーム、または他のパケット）を示す。フィールドの例のサイズとタイプがこの図で説明されている。当業者は、多様な他のサイズ、タイプ及び構成が本発明の範囲内で意図されることを認識するであろう。
【００４８】
図示されているように、データパケット４１０は適応層３１０で分割される。各適応副層ＰＤＵ４３０はこれらのセグメント４２０の１つを搬送する。この例では、データパケット４１０はＮ個のセグメント４２０Ａ−Ｎに分割されている。適応副層ＰＤＵ４３０はそれぞれのセグメント４２０を含むペイロード４３４を備える。タイプフィールド４３２（この例では１バイト）は適応副層ＰＤＵ４３０に付けられている。
【００４９】
論理リンク（ＬＬ）層３３０では、ＬＬヘッダ４４２（この例では４バイト）が、適応層ＰＤＵ４３０を備えるペイロード４４４に付けられる。ＬＬヘッダ４４２の例の情報はストリーム識別子、制御情報、及びシーケンス番号を含む。ＣＲＣ４４６はヘッダ４４２とペイロード４４４で計算され、論理リンク副層ＰＤＵ（ＬＬ ＰＤＵ）４４０を形成するために付加される。論理リンク制御（ＬＬＣ）３３８とラジオリンク制御（ＲＬＣ）３４０は、さらに後述されるように、ＬＬＵ ＰＤＵとＲＬＣ ＰＤＵを同様に形成する。ＬＬＣ ＰＤＵとＲＬＣ ＰＤＵだけではなくＬＬ ＰＤＵ４４０も、ＭＵＸ関数３６０によるサービスのために待ち行列（つまり、高いＱｏＳ待ち行列３６２、最善努力待ち行列３６４、または制御メッセージ待ち行列３６６）に入れられる。
【００５０】
ＭＵＸ関数３６０は、ＭＵＸヘッダ４５２を各ＬＬ ＰＤＵ４４０に付ける。例のＭＵＸヘッダ４５２は長さとタイプを備えてよい（ヘッダ４５２はこの例では２バイトである）。類似したヘッダは制御ＰＤＵ（つまり、ＬＬＣとＲＬＣ ＰＤＵ）ごとに形成されてよい。ＬＬ ＰＤＵ４４０（またはＬＬＣまたはＲＬＣ ＰＤＵ）はペイロード４５４を形成する。ヘッダ４５２とペイロード４５４はＭＵＸ副層ＰＤＵ（ＭＰＤＵ）４５０を形成する（ここではＭＵＸ副層ＰＤＵもＭＵＸ ＰＤＵと呼ばれる。）
共用媒体上での通信資源は一連のＭＡＣフレームでＭＡＣプロトコルによって割り当てられる。ＭＡＣスケジューラ３７６は、ＭＡＣフレームｆとして示されている各ＭＡＣフレーム内の１つまたは複数のＭＡＣ ＩＤに割り当てられる物理層バーストのサイズを決定し、ｆはある特定のＭＡＣフレームを示す。特定のＭＡＣフレーム内で、送信されるデータを備えるあらゆるＭＡＣ ＩＤに必ずしもスペースが割り当てられるわけではないことに注意する。アクセス制御またはスケジューリング方式は本発明の範囲内で配備されてよい。ＭＡＣ ＩＤについて割り当てが行われると、そのＭＡＣ ＩＤのためのそれぞれのＭＵＸ関数３６０が、ＭＡＣフレームｆでの包含のための１つまたは複数のＭＵＸ ＰＤＵ４５０を含むＭＡＣ ＰＤＵ４６０を形成する。１つまたは複数の割り当てられたＭＡＣ ＩＤのための１つまたは複数のＭＵＸ ＰＤＵ４６０がＭＡＣフレーム（つまり図５に関して以下に詳述されるＭＡＣフレーム５００）に含まれる。
【００５１】
例の実施形態では、一態様が部分的なＭＰＤＵ４５０を送信できるようにし、ＭＡＣ ＰＤＵ４６０における効率的な圧縮を可能にする。この態様は以下に詳述される。この例では、ＭＵＸ関数３６０は、部分的なＭＰＤＵ４６４により識別された過去の伝送から残されたあらゆる部分的なＭＰＤＵ４５０の未送信バイトのカウントを維持する。これらのバイト４６４はカレントフレームであらゆる新しいＰＤＵ４６６（つまりＬＬ ＰＤＵまたは制御ＰＤＵ）に先行して送信される。ヘッダ４６２（この例では２バイト）は、カレントフレームで送信される第１の新しいＭＰＤＵ（この例ではＭＰＤＵ４６６Ａ）の始まりを指すＭＵＸポインタを含む。ヘッダ４６２はＭＡＣアドレスも含んでよい。
【００５２】
ＭＡＣ ＰＤＵ４６０は、ＭＵＸポインタ４６２、ゼロまたは１つ以上の完全なＭＵＸ ＰＤＵ４６６Ａ−Ｎが後に続く（過去の割り当てから残された）開始時に考えられる部分的なＭＵＸ ＰＤＵ ４６４、及び物理層バーストの割り当てられた部分を充填するための（現在の割り当てからの）考えられる部分的なＭＵＸ ＰＤＵ４６８または他のパディングを備える。ＭＡＣ ＰＤＵ４６０はＭＡＣ ＩＤに割り当てられた物理層バーストで搬送される。
【００５３】
共通ＭＡＣ、ＭＡＣフレーム及びトランスポートチャネル
例のＭＡＣフレーム５００が図５に示されている。共通ＭＡＣ関数３７０は、以下のトランスポートチャネルセグメントの間でのＭＡＣフレーム５００の割り当てを管理する。つまり、放送、制御、（それぞれダウンリンクフェーズとアップリンクフェーズと呼ばれる）順方向トラフィックと逆方向トラフィック、及びランダムアクセスである。ＭＡＣフレーミング関数３７２は、さらに後述される多様な構成要素を使用してフレームを形成してよい。トランスポートチャネルの例の関数、コード化、及び持続時間は後述される。
【００５４】
例の実施形態では、ＭＡＣフレームは、２ｍｓの時間間隔で時分割二重化（ＴＤＤ）される。ＭＡＣフレーム５００は、示されている順序で表示される５個のトランスポートチャネルセグメント５１０から５５０に分割される。代替順序及び異なるフレームサイズは代替実施形態で展開されてよい。ＭＡＣフレーム５００での割り当ての持続時間はいくつかの小さな共通時間間隔に量子化される。例の実施形態では、ＭＡＣフレームでの割り当ての持続時間は（以下に詳説される、短いＯＦＤＭシンボルまたは長いＯＦＤＭシンボルのどちらかの周期的な接頭辞の持続時間でもある）８００ｎｓの倍数に量子化される。短いＯＦＤＭシンボルは４．０μｓつまり５かける８００ｎｓである。
【００５５】
例のＭＡＣは、ＭＡＣフレーム内で以下の５つのトランスポートチャネルを提供する。（ａ）放送制御チャネル（ＢＣＣＨ）を搬送する放送チャネル（ＢＣＨ）５１０、（ｂ）フレーム制御チャネル（ＦＣＣＨ）とランダムアクセスフィードバックチャネル（ＲＦＣＨ）を順方向リンクで搬送する制御チャネル（ＣＣＨ）５２０、（ｃ）ユーザデータと制御情報を搬送し、（ｉ）順方向リンク上の順方向トラフィックチャネル（Ｆ−ＴＣＨ）５３０と（ｉｉ）逆方向リンク上の逆方向トラフィックチャネル（Ｒ−ＴＣＨ）５４０に再分割されるトラフィックチャネル（ＴＣＨ）、及び（ｄ）（ＵＴアクセス要求のための）アクセス要求チャネル（ＡＲＣＨ）を搬送するランダムアクセスチャネル（ＲＣＨ）５５０。パイロットビーコンもセグメント５１０で送信される。
【００５６】
フレーム５００のダウンリンクフェーズはセグメント５１０から５３０を備える。アップリンクフェーズはセグメント５４０から５５０を備える。セグメント５６０は以後のＭＡＣフレームの開始を示す。
【００５７】
放送チャネル（ＢＣＨ）
放送チャネル（ＢＣＨ）とビーコン５１０はＡＰにより送信される。ＢＣＨ５１０の第１の部分は、タイミングと周波数取得パイロットを含む、パイロット信号等の共通物理層オーバヘッドを含む。例の実施形態では、ビーコンは、チャネルを推定するためにＵＴによって使用される共通ＭＩＭＯパイロットの８個のＯＦＤＭシンボルが後に続く、ＵＴによる周波数とタイミング取得のために使用される２個の短いＯＦＤＭシンボルからなる。
【００５８】
ＢＣＨ５１０の第２の部分はデータ部分である。ＢＣＨデータ部分は、トランスポートチャネルセグメント、つまりＣＣＨ５２０、Ｆ−ＴＣＨ５３０、Ｒ−ＴＣＨ５４０及びＲＣＨ５５０に関してＭＡＣフレームの割り当てを定義し、サブチャネルに関してＣＣＨの構成も定義する。この例では、ＢＣＨ５１０は無線ＬＡＮ１２０のカバレージを定義するため、使用できるもっともロバストなデータ伝送モードで送信される。ＢＣＨ全体の長さは固定されている。例の実施形態では、ＢＣＨはＭＩＭＯ−ＷＬＡＮのカバレージを定義し、レート１／４コード化二進移相変調（ＢＰＳＫ）を使用して空間時間送信ダイバーシティ（ＳＴＴＤ）モードで送信される。この例では、ＢＣＨの長さは１０個の短いＯＦＤＭシンボルで固定される。
【００５９】
制御チャネル（ＣＣＨ）
ＡＰにより送信される制御チャネル（ＣＣＨ）５２０は、ＭＡＣフレームの残りの構成を定義する。共通ＭＡＣ３７０の制御チャネル関数３７４はＣＣＨを生成する。ＣＣＨの例の実施形態はさらに詳しく後述される。ＣＣＨ５２０は、各サブチャネルが異なるデータレートとなる複数のサブチャネルでのきわめてロバストな伝送モードを使用して送信される。第１のサブチャネルはもっともロバストであり、すべてのＵＴによって復号可能であると予想されている。例の実施形態では、レート１／４コード化ＢＰＳＫは第１のＣＣＨサブチャネルに使用される。ロバストネスが減少した（そして効率が上がった）複数の他のサブチャネルも使用できる。例の実施形態では、３個までの追加のサブチャネルが使用される。各ＵＴは、復号が失敗するまで順序正しくすべてのサブチャネルを復号しようとする。各フレームのＣＣＨトランスポートチャネルセグメントは可変長であり、該長さは各サブチャネル内のＣＣＨメッセージの数に依存する。逆方向リンクランダムアクセスバーストのための肯定応答は、ＣＣＨのもっともロバストな（第１の）サブチャネルで搬送される。
【００６０】
ＣＣＨは順方向リンクと逆方向リンクでの物理層バーストの割り当てを含む。割り当ては順方向リンクまたは逆方向リンクでのデータの転送のためであってよい。一般的には物理層バーストを割り当ては以下を備える。（ａ）ＭＡＣ ＩＤ、（ｂ）フレーム内での割り当ての開始時間を示す値（Ｆ−ＴＣＨまたはＲ−ＴＣＨ）、（ｃ）割り当ての長さ、（ｄ）専用物理層オーバヘッドの長さ、（ｅ）伝送モード、及び（ｆ）物理層バーストに使用されるコード化と変調の方式。ＭＡＣ ＩＤはユニキャスト伝送のための単一のＵＴ、あるいはマルチキャスト伝送のためのＵＴのセットを識別する。例の実施形態では、一意の放送ＭＡＣ ＩＤもすべてのＵＴへの伝送のために割り当てられる。例の実施形態では、物理層オーバヘッドは、０．４シンボル、つまり８個の短いＯＦＤＭシンボルから構成される専用ＭＩＭＯパイロットを含む。この例では伝送モードは代わりにＳＴＴＤまたは空間多重化である。
【００６１】
ＣＣＨ上での割り当ての他の例のタイプは、ＵＴからの専用パイロットの伝送のための逆方向リンクでの割り当てまたはＵＴからのバッファとリンクステータス情報の伝送のための逆方向リンクでの割り当てを含む。ＣＣＨは未使用のまま残されなければならないフレームの部分も定義してよい。フレームのこれらの未使用の部分は、近隣システムビーコンを測定するためだけではなく、ノイズフロア（及び干渉）を推定するためにもＵＴによって使用されてよい。制御チャネルの例の実施形態はさらに後述されている。
【００６２】
ランダムアクセスチャネル（ＲＣＨ）
ランダムアクセスチャネル（ＲＣＨ）５５０は、ＵＴがランダムアクセスバースを送信してよい逆方向リンクチャネルである。ＲＣＨの可変長はＢＣＨ内のフレームごとに指定される。例の実施形態では、ランダムアクセスバーストがレート４／１コード化ＢＰＳＫとともに主要な固有モードを使用して送信される。
【００６３】
例の実施形態では２種類のランダムアクセスバーストが定義される。長いバーストは、スライド相関器（ｓｌｉｄｉｎｇ ｃｏｒｒｅｌａｔｏｒ）を使用してアクセスの開始を検出しなければならないときに初期アクセスのためにＵＴにより使用される。ＵＴがいったんＡＰで登録されると、リンクの２つの端部がタイミング調整手順を完了する。タイミング調整後、ＵＴはＲＣＨでのスロットタイミングと同期されたそのランダムアクセスバーストを送信してよい。それは次にランダムアクセスのために短いバーストを使用してよい。例の実施形態では、長いバーストは４個の短いＯＦＤＭシンボルであり、短いバーストは２個の短いＯＦＤＭシンボルである。
【００６４】
順方向トラフィックチャネル（Ｆ−ＴＣＨ）
順方向トラフィックチャネル（Ｆ−ＴＣＨ）５３０は、ＡＰ１０４から送信される１つまたは複数の物理層バーストを備える。各バーストはＣＣＨ割り当てに示されるように特定のＭＡＣ ＩＤに向けられる。各バーストは、（存在する場合）パイロット信号及び伝送モードに従って送信されるＭＡＣ ＰＤＵ、及びＣＣＨ割り当てに示されるコード化及び変調方式等の専用の物理層オーバヘッドを備える。Ｆ−ＴＣＨは可変長である。例の実施形態では、専用物理層オーバヘッドが専用ＭＩＭＯパイロットを含んでよい。
【００６５】
例の実施形態では、ＳＴＴＤモードで、その効率が短いＯＦＤＭシンボルあたり１２ビット（４８トーンでのレート１／２コード化ＢＰＳＫ）と長いＯＦＤＭシンボルあたり１３４４ビット（１９２トーンでのレート７／８コード化２５６ＱＡＭ）の間で変化することがある１つの同等な空間ダイバーシティチャネルがある。これは、ピーク物理層データレート（つまりこの例では３から９９Ｍｂｐｓ）の範囲で３３という因数になる。
【００６６】
この例では、最高４つの平行空間チャネルの空間多重化モードが使用されてよい。各空間チャネルは、その効率が短いＯＦＤＭシンボルあたり１２ビットと長いＯＦＤＭシンボルあたり１３４４ビットの間である適切なコード化及び変調方式を使用する。したがって、空間多重化モードのピーク物理層データレートの範囲は３Ｍｂｐｓと３９５Ｍｂｐｓの間である。空間処理の制約のために、すべての平行空間チャネルが最高の効率で動作できるわけではないため、ピーク物理層データレートに対するより実際的な制限は２４０Ｍｂｐｓ、つまりこの例では最低のレートと最高のレートの間の８０という因数であってよい。
【００６７】
逆方向トラフィックチャネル（Ｒ−ＴＣＨ）
逆方向トラフィックチャネル（Ｒ−ＴＣＨ）５４０は１つまたは複数のＵＴ１０６からの物理層バースト伝送を備える。各バーストはＣＣＨ割り当てで示されるように特定のＵＴによって送信される。各バーストは（存在する場合）専用のパイロットプリアンブルと伝送モードに従って送信されるＭＡＣ ＰＤＵと、ＣＣＨ割り当てに示されているコード化及び変調方式を備えてよい。Ｒ−ＴＣＨは可変長である。例の実施形態では、Ｆ−ＴＣＨにおいてのように、ＳＴＴＤモードでのデータレートの範囲は３Ｍｂｐｓから９８Ｍｂｐｓであり、空間多重化モードでは３Ｍｂｓから３９５Ｍｂｐｓであり、２４０Ｍｂｐｓがおそらくより実際的な制限である。
【００６８】
例の実施形態では、Ｆ−ＴＣＨ５３０、Ｒ−ＴＣＨ５４０または双方が、さまざまなＵＴと関連付けられているＭＡＣ ＰＤＵの同時伝送を可能にするために、空間多重化または符号分割多元接続技法を使用してよい。ＭＡＣ ＰＤＵが関連付けられているＭＡＣ ＩＤを含むフィールド（つまり、アップリンクでの送信者、またはダウンリンクでの対象とする受取人）は、ＭＡＣ ＰＤＵヘッダに含まれてよい。これは空間多重化またはＣＤＭＡが使用されるときに発生する可能性のあるアドレス指定の不明瞭さを解決するために使用されてよい。代替実施形態では、多重化が厳密に時分割技法に基づいているとき、アドレス指定情報はＭＡＣフレーム内の既定の時間スロットを特定のＭＡＣ ＩＤに割り当てるＣＣＨメッセージに含まれるため、ＭＡＣ ＩＤはＭＡＣ ＰＤＵヘッダで必要とされない。空間多重化、符号分割多重化、時分割多重化及び技術で公知の他の技法の任意の組み合わせが展開されてよい。
【００６９】
各アクティブＵＴには初期登録中にＭＡＣ ＩＤが割り当てられる。ＭＡＣ ＩＤ割り当てはＲＬＣ３４０の関連制御（ＡＣ）関数３４４により処理される。ユニークなＭＡＣ ＩＤは順方向リンクでの放送伝送のために割り当てられる。放送伝送は順方向トランスポートチャネル（Ｆ−ＴＣＨ）の一部であり、ユニークな放送ＭＡＣ ＩＤを使用して制御チャネル（ＣＣＨ）を使用して割り当てられる。この例では、システム識別メッセージは、放送ＭＡＣ ＩＤ割り当てを使用して１６フレームごとに一度放送される。放送ＭＡＣ ＩＤはユーザデータ放送のために使用されてもよい。
【００７０】
１つまたは複数のＭＡＣ ＩＤのセットは順方向リンクでのマルチキャスト伝送のために割り当てられてよい。マルチキャスト伝送はＦ−ＴＣＨの一部であり、特定のマルチキャストグループに割り当てられる特定のマルチキャストＭＡＣ ＩＤを使用してＣＣＨで割り当てられる。マルチキャストＭＡＣ ＩＤのＵＴのグループへの割り当てはＲＬＣ３４０の関連制御（ＡＣ）関数３４４により処理される。
【００７１】
ここで図３に描かれている共通ＭＡＣ３７０の説明に戻る。ＡＰでのランダムアクセス制御関数３７８はＵＴからのアクセスバーストのための肯定応答を処理する。肯定応答とともに、ＡＰはＵＴからバッファステータス情報を得るためにＲ−ＴＣＨで即時割り当てを行わなければならない。この要求はスケジューラ３７６に転送される。
【００７２】
ＵＴでは、ランダムアクセスマネージャが、その既存の割り当てだけではなくそのＭＵＸ待ち行列でのデータに基づいていつアクセスバーストを送信するのかを決定する。ＵＴが既存のＬＬ接続のために周期的な割り当てを有するとき、バッファステータス情報は既存のＲ−ＴＣＨ割り当てを使用して提供されてよい。
【００７３】
バッファに含まれている情報及びＵＴから受信されるリンクステータスメッセージに基づいて、ＡＰでの対応するＭＵＸ関数３６０がＵＴプロキシを更新する。ＵＴプロキシは、ＵＴで、Ｒ−ＴＣＨ割り当てを行うためにスケジューラ３７６によって使用されるＭＵＸ関数バッファのステータスを維持する。ＵＴプロキシは、ＡＰがＦ−ＴＣＨでのＵＴに送信してよい最大速度も維持する。
【００７４】
ＡＰでの共通ＭＡＣ関数３７０は、各ＭＡＣフレームを効率的に活用する一方でＵＴ間の割り当てを調停するためにスケジューラ３７６を実現する。オーバヘッドを制限するために、すべてのアクティブなＵＴに各フレームで物理層が割り当てられるわけではない。
【００７５】
以下の情報は、各ＭＡＣフレームで割り当てを行うためにスケジューラ３７６によって使用されてよい。
【００７６】
１．各ＭＡＣ ＩＤに対する名目上の割り当て。アクティブなＵＴの部分集合だけに任意のフレームの名目上の割り当てが割り当てられてよい。例えば、いくつかのＵＴは１つおきのフレーム、または４フレームごとにだけ名目上の割り当てを与えられてよい等である。名目上の割り当ては層マネージャ３８０の流入制御関数３８４により決定される。例の実施形態では、名目上の割り当てはＯＦＤＭシンボルの数に関して行われる。
【００７７】
２．パイロット信号等の専用物理層オーバヘッドのための割り当て。ＲＬＣ３４０の中のラジオ資源制御（ＲＲＣ）３４２が、専用物理層オーバヘッドの必要とされる長さと周期性を決定する。例の実施形態では、物理層オーバヘッドは専用ＭＩＭＯパイロットを含む。
【００７８】
３．伝送モード及び伝送速度。これは、Ｒ−ＴＣＨについてＲＲＣ３４２により決定され、スケジューラ３７６に提供される。Ｆ−ＴＣＨの場合、この情報はリンク内のＵＴ及びバッファステータスメッセージから取得され、ＵＴプロキシで維持される。
【００７９】
４．ＭＡＣ ＩＤごとのデータバックログ。この情報は順方向リンクの場合ＭＡＣ ＩＤごとにＭＵＸ関数３６０から及び逆方向リンクの場合ＵＴプロキシからスケジューラ３７６が使用できる。
【００８０】
さらに、スケジューラはＲＣＨの持続時間を割り当て、ＣＣＨの持続時間を決定する。ＣＣＨでの各割り当ては（ＵＴに対するチャネル品質に基づいた）４つのコード化方式の１つを使用して送信される。したがって、ＣＣＨの持続時間は割り当ての数と、各割り当てを送信するために使用されるコード化方式の関数である。
【００８１】
スケジューラによって決定される割り当てに基づいて、ＡＰでのＭＡＣエンティティは割り当てがＢＣＨとＣＣＨを構築するためのパラメータを投入する。ＢＣＨはＭＡＣフレームの割り当てを、トランスポートチャネルセグメント、つまりＣＣＨ、Ｆ−ＴＣＨ、Ｒ−ＴＣＨ、及びＲＣＨに関して定義し、図５に関して前述されたようにサブチャネル（またはサブセグメント）に関してＣＣＨの構成も定義する。例のＣＣＨが詳しく後述される。
【００８２】
例の実施形態では、ＣＣＨでの各割り当ては、それぞれが（ＵＴに対するチャネル品質に基づいて）異なるコード化及び変調方式を使用する、１つから最高４つのサブチャネル（またはサブセグメント）で送信される。マルチキャスト割り当てと放送割り当ては、もっともロバストなコード化方式を使用して送信される（第１のサブチャネルまたはサブセグメント）。ＵＴでのＭＡＣエンティティは、そのフレームについて順方向リンク及び逆方向リンクでのその割り当てを決定するためにＣＣＨを読み取る。
【００８３】
送信機では、ＭＡＣ関数が、（ＡＰでの）Ｆ−ＴＣＨまたは（ＵＴでの）Ｒ−ＴＣＨでそのＭＡＣ ＩＤに割り当てられる物理層バーストでの特定のＭＡＣ ＩＤに関連付けられたＭＡＣ ＰＤＵを送信する。受信機では、ＭＡＣ関数は、ＣＣＨ割り当てに基づいてＭＡＣ ＩＤに対応するＭＡＣ ＰＤＵを抽出し、それをそのＭＡＣ ＩＤのためのＭＵＸ関数に渡す。
【００８４】
ＭＵＸ
ＭＵＸ関数３６０は、図１９から図２３に関してさらに詳しく後述されている。受信機で、ＭＵＸ関数は、連続ＭＡＣ ＰＤＵからなるバイトストリームからＰＤＵを抽出し、それらを、それが属するＬＬ、ＬＬＣ、またはＲＬＣエンティティに送る。ルーティングはＭＵＸ ＰＤＵヘッダに含まれるタイプ（論理チャネル）フィールドに基づいている。
【００８５】
ラジオリンク制御（ＲＬＣ）
システム初期化中、システム識別制御関数３４６からなる放送ラジオリンク制御（ＲＬＣ）３４０関数は初期化される。ＵＴが初期にアクセスプールからＭＡＣ ＩＤを使用してシステムにアクセスすると、ＲＬＣ関数が新しいユニキャストＭＡＣ ＩＤをＵＴに割り当てる。以後、ＵＴがマルチキャストグループに加わると、それは追加のマルチキャストＭＡＣ ＩＤを割り当てられてよい。
【００８６】
新しいユニキャストＭＡＣ ＩＤがＵＴに割り当てられると、ＲＬＣは以下の関数のそれぞれの１つのインスタンスを初期化する。関連制御（ＡＣ）３４４、ラジオ資源制御（ＲＲＣ）３４２及び論理リンク制御（ＬＬＣ）３３８。新しいマルチキャストＭＡＣ ＩＤが割り当てられると、ＲＬＣは新しいＡＣインスタンスとＬＬＣをＬＬマルチキャストモードのために初期化する。
【００８７】
例の実施形態では、システム識別パラメータメッセージは、放送ＭＡＣ ＩＤを使用して１６ＭＡＣフレームごとに一度ＡＰにより送信される。システム識別パラメータメッセージは、プロトコル改定番号だけではなくネットワークＩＤとＡＰ ＩＤも含む。さらに、それはシステムへの初期アクセスのためにＵＴによって使用するためのアクセスＭＡＣ ＩＤのリストも含む。
【００８８】
ＡＣ関数３４４は、（ａ）ＵＴ認証を提供し、（ｂ）ＵＴのために登録（アタッチ／タスク消去）関数を管理し（マルチキャストＭＡＣ ＩＤのケースでは、ＡＣ関数はマルチキャストグループに対するアタッチ／タスク消去を管理する）、（ｃ）ＬＬのための暗号化のための鍵交換。
【００８９】
１つのＲＲＣインスタンス３４２が各ＵＴで初期化される。アクティブＵＴごとに１つのＲＲＣインスタンスがＡＰで初期化される。ＡＰとＵＴでのＲＲＣ関数は（必要な場合）順方向リンクチャネル測定値と逆方向リンクチャネル測定値を共用してよい。
【００９０】
ＲＲＣは、（ａ）ＡＰとＵＴで送信チェーンと受信チェーンの校正を管理し（この校正は、空間多重化伝送モードに必要とされる可能性がある）、（ｂ）ＵＴへの伝送のために伝送モードと速度制御を決定し、それをＭＡＣスケジューラ３７６に提供し、（ｃ）Ｒ−ＴＣＨで、及びＦ−ＴＣＨでの物理層バースト伝送で必要とされる専用パイロット等の専用物理層オーバヘッドの周期性と長さを決定し、（ｄ）ＵＴへ及びＵＴからの伝送のために電力制御を管理し、それをＰＨＹマネージャに提供し、（ｅ）ＵＴからＲ−ＴＣＨ伝送のためのタイミング調整を決定する。
【００９１】
論理リンク（ＬＬ）
ユーザデータセグメントからなる適応層ＰＤＵは、存在する場合関連付けられたＭＡＣ ＩＤ、ＬＬモード及びストリームＩＤとともにＤＬＣ層３２０に提供される。ＬＬモード関数３３０はＬＬヘッダとＬＬ ＰＤＵ全体で計算された３バイトのＣＲＣを追加する。例の実施形態でサポートされている複数のモードがある。肯定応答された３３６、及び応答されていない３３４関数が展開されてよい。トランスペアレントな放送／マルチキャスト／ユニキャスト関数３３２も展開されてよい。以下は説明のための４つのＬＬモードである（ＭＵＸ ＰＤＵ内でのそれらのフォーマットの詳細は図２３に詳説されている）。
【００９２】
１．コネクションレス未応答モード（モード０）。このケースのＬＬヘッダはヌルである。このモードは適応層ＰＤＵのトランスペアレント転送のために使用されてよい。ＬＬモード０は管理（ｐｏｌｉｃｉｎｇ）を実現してよい。コネクションレス未応答（トランスペアレント）モードだけが放送及びマルチキャストＭＡＣ ＩＤに使用できる。
【００９３】
２．コネクションレス肯定応答モード（モード１）。このモードは、ＬＬモード３接続確立と関連付けられたオーバヘッド及び遅延を必要とすることなく、適応層ＰＤＵの肯定応答された伝送のために使用される。ＬＬモード１ヘッダは、送信されたＬＬ ＰＤＵのシーケンス番号または肯定応答されているＰＤＵのシーケンス番号を含む。物理層チャネルはランダムＬＬ ＰＤＵ損失の低い確率で、及び低い往復遅延で動作すると予想されるため、単純なＧｏ−Ｂａｃｋ−Ｎ ＡＲＱ方式が使用される。
【００９４】
３．接続指向未応答モード（モード２）。ＬＬ接続指向未応答モードは、ストリームＩＤの使用により複数のフローの多重化を可能にする。ＬＬモード２は、ストリームＩＤあたりの管理（ｐｏｌｉｃｉｎｇ）を実現してよい。ＬＬモード２ヘッダはストリームＩＤと１２ビットのシーケンス番号を含む。
【００９５】
４．接続指向肯定応答モード（モード３）。ＬＬ指向肯定応答モードは、ストリームＩＤを使用することによる複数のフローの多重化を可能にする。ＬＬモード３はストリームＩＤあたりの管理（ｐｏｌｉｃｉｎｇ）を実現してよい。ＬＬモード３ヘッダは信頼できる接続で移送される複数のフローを識別するためにストリームＩＤからなる。１２ビットのシーケンス番号はＬＬ ＰＤＵを識別し、ＡＣＫフィールドは肯定応答されている最高の受信シーケンス番号を示す。ＬＬモード１について説明されたように、物理層チャネルはランダムＬＬ ＰＤＵ損失の低い確率と低往復遅延で動作することが期待されているので、単純なＧｏ−Ｂａｃｋ−Ｎ ＡＲＱ方式が使用される。しかしながら、選択反復ＡＲＱ方式も使用されてよい。
【００９６】
論理リンク制御（ＬＬＣ）関数３３８は論理リンクモード制御を管理する。新しいＬＬモードが確立されなければならないとき、ＬＬＣ関数は以下を含むモード交渉を提供する。（ａ）ＱｏＳ：保証されたレート、（ｂ）モードセットアップ、（ｃ）モード分解、（ｅ）モードリセット、及び（ｆ）ＬＬモード２と３でのストリームＩＤの割り当て。ＬＬモードへの終端間フローのマッピングは層マネージャ３８０におけるＱｏＳマネージャ関数３８２により決定される。新しいＬＬモードを初期化すること、あるいは既存のＬＬモードにストリームを追加することの要求は、前述されたように適応層３１０から出される。
【００９７】
システム構成制御３５０は、ビーコンとＢＣＨのコンテンツ及びＲＣＨの長さを含むＴＤＤ ＭＡＣフレームの構成を管理する。
【００９８】
層マネージャ
ＱｏＳマネージャ３８２は、ＲＳＶＰとＲＴＣＰを含むネットワークＱｏＳプロトコルを解釈する。ＱｏＳがＩＰヘッダのフロー分類に基づいているとき、ＱｏＳマネージャは、さまざまなサービスに対応するフローの識別のためにどのフロー分類子（つまり、ＩＰソースアドレスと宛先アドレス、ＩＰソースポートと宛先ポート）を使用するのかを決定する。ＱｏＳマネージャはＬＬモードにフローをマッピングすることによって適応層を補助する。
【００９９】
流入制御関数（admission control function）３８４は、速度要件付きの新しいフローを認めることに対する要求をＬＬＣから受け取る。流入制御関数は認められた名目上の割り当てのデータベースと規則と閾値のセットを維持する。閾値と規則に基づいて、流入制御は、フローが認められてよいかどうかを判断し、（ｍ個のＭＡＣフレームごとに割り当てられる伝送時間の量に関して）フローに対する名目上の割り当てを決定し、この情報を共通ＭＡＣでスケジューラに提供する。
【０１００】
物理層マネージャは物理層で送信機パラメータと受信機パラメータを制御するためにＡＰとＵＴで収集される物理層測定値を使用する。遠隔測定値はＲＲＣメッセージを通して得られてよい。
【０１０１】
例示的な手順
いま説明された層エンティティに基づいて、複数の手順がＷＬＡＮ１２０の動作を説明するために使用されてよい。これらの手順は網羅的ではないが、ここに説明されている多様な関数と構成要素を説明するために役立つ。
【０１０２】
図６は、ＡＰから順方向リンクメッセージ転送を送信するための例の方法６００を描く。ブロック６１０では、ＡＰでのＲＬＣ関数（関連制御、ラジオ資源制御または論理リンク制御）がメッセージ（ＲＬＣ ＰＤＵ）を制御メッセージ待ち行列に入れる。あるいは、ＡＰでのＬＬモードはＬＬ ＰＤＵを高ＱｏＳまたは最善努力待ち行列に入れる。
【０１０３】
ブロック６２０では、スケジューラが３つのＭＵＸ待ち行列の中でのＰＤＵの伝送のためにＦ−ＴＣＨで資源を割り当てる。ブロック６４０では、割り当てはＭＡＣによってＣＣＨで示される。ブロック６５０では、ＡＰでのＭＡＣが割り当てられた物理層バーストでＭＡＣ ＰＤＵのメッセージを送信する。
【０１０４】
図７は、ＵＴで順方向リンクメッセージ転送を受信するための例の方法７００を描く。ブロック７１０では、ＵＴはＣＣＨを監視する。ＵＴはＵＴに向けられた割り当てられたバーストを識別する。ブロック７２０ではＵＴはＣＣＨで識別されるようにＭＡＣ ＰＤＵを取り出す。ブロック７３０では、ＵＴは、ＭＡＣ ＰＤＵで取り出され、ＭＡＣプロセッサで処理されたセグメントを備えるフローパケットをリアセンブルする。
【０１０５】
図８は、ＵＴから逆方向リンクメッセージ転送を送信するための例の方法８００を描く。ブロック８１０では、ＵＴでのＲＬＣ関数（関連制御、ラジオ資源制御または論理リンク制御）が制御メッセージ待ち行列にメッセージ（ＲＬＣ ＰＤＵ）を入れる。あるいはＵＴでのＬＬモードが高ＱｏＳまたは最善の努力待ち行列にＬＬ ＰＤＵを入れる。決定ブロック８２０では、ＵＴが既存のＲ−ＴＣＨ割り当てを有する場合、ブロック８７０に進む。有さない場合はブロック８３０に進む。
【０１０６】
ブロック８３０では、ＵＴは短いアクセスバーストをＲＣＨで送信する。ブロック８４０では、ＵＴはＲＣＨアクセスバーストとアクセス許可割り当ての肯定応答をＣＣＨで受信する。ブロック８５０では、ＵＴはリンクとバッファステータスメッセージをＡＰに送信する。ブロック８６０ではＵＴはＲ−ＴＣＨ許可割り当てがないかＣＣＨを監視する。ブロック８７０では割り当てが受信される（あるいは決定ブロック８２０にすでに存在していた）。ＵＴはＭＵＸ ＰＤＵをＭＡＣ ＰＤＵの中にいれ、割り当てられた物理層バーストでＭＡＣ ＰＤＵを送信する。
【０１０７】
図９は、ＡＰで逆方向リンクメッセージ転送を受け取るための例の方法９００を描く。ブロック９１０では、ＡＰはＲＣＨを受信し、監視する。ブロック９２０では、ＡＰはＵＴからの短いアクセスバーストを識別する。ブロック９３０では、スケジューラがアクセス許可を割り当てる。ブロック９４０では、ＡＰはＣＣＨで肯定応答をとアクセス許可を送信する。ブロック９５０では、アクセス許可に応えて、ＡＰがＲ−ＴＣＨでリンクとバッファステータスメッセージを受信する。ブロック９６０では、ＡＰはバッファステータスでＵＴプロキシを更新する。スケジューラはこの情報にアクセスできる。ブロック９７０では、スケジューラは資源をＲ−ＴＣＨで割り当てる。ブロック９８０では、ＡＰが行われた割り当てに応じてＭＡＣ ＰＤＵを受信する。ブロック９９０では、ＡＰは１つまたは複数の受信されたＭＡＣ ＰＤＵに応えてフローパケットのリアセンブリを実行する。
【０１０８】
図１０は、初期アクセスと登録をＵＴで実行するための例の方法１０００を描く。ブロック１０１０では、ＵＴはＢＣＨ上で周波数とタイミングを周波数獲得パイロットから獲得する。ブロック１０２０では、ＵＴはＲＬＣ放送メッセージからシステム識別情報を受信する。ブロック１０３０では、ＵＴはＢＣＨから長いバーストを使用して（スロットが付けられていない（ｕｎｓｌｏｔｔｅｄ））ランダムアクセスのためのＲＣＨ割り当てを決定する。ブロック１０４０では、ＵＴは初期のＭＡＣ ＩＤのセットから無作為にＭＡＣ ＩＤを選択する。ブロック１０５０では、ＵＴは初期のＭＡＣ ＩＤを使用してＲＣＨで長いランダムアクセスバーストを送信する。ブロック１０６０では、ＵＴは肯定応答、ＭＡＣ ＩＤ割り当て、及びタイミング調整を以後のＭＡＣフレームで受信する。ブロック１０７０では、ＵＴ関連制御関数が、ＡＰ関連制御関数を用いて認証シーケンスと鍵交換シーケンスを競争する。順方向リンク及び逆方向リンクでの制御メッセージ伝送は、図６から図９に関して前述された低レベルメッセージ転送手順に従う。
【０１０９】
図１１は、初期アクセス及び登録をＡＰで実行するための例の方法１１００を描く。ブロック１１１０では、ＡＰはＲＣＨ上でＵＴから長いランダムアクセスバーストを受信する。ブロック１１２０では、ＡＰはＵＴにＭＡＣ ＩＤを割り当てる。ＭＡＣ ＩＤプールは無線リンク制御関数により管理される。ブロック１１３０では、ＡＰはＵＴにタイミング調整を割り当てる。ブロック１１４０では、ＡＰは肯定応答、ＭＡＣ ＩＤ及びタイミング調整をＣＣＨで送信する。ブロック１１５０では、ＡＰ関連制御関数が、ＵＴ関連制御関数を用いて認証シーケンスと鍵交換シーケンスを競争する。順方向リンクと逆方向リンクでの制御メッセージ伝送は、図６から図９に関して前述された低レベルメッセージ転送手順に従う。
【０１１０】
図１２は、ＡＰでのユーザデータフローのための例の方法１２００を描く。ブロック１２１０では、層マネージャの中のＱｏＳマネージャがフロー分類関数の中にフロー分類パラメータを投入する。パラメータと値の特定の組み合わせは新しいフローの到着を示してよい。これらのパラメータは、ＩＰ ＤＩｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ（ＤＳＣＰ）またはＩＰソースアドレスまたはＩＰポートを含んでよい。イーサネットパラメータは、８０２．１Ｑ ＶＬＡＮ ＩＤまたは８０２．１ｐ優先順位表示を含んでよい。特定のＩＰポート値は、ＱｏＳマネージャに転送されなければならない制御プロトコルメッセージ（例えばＲＳＶＰまたはＲＴＣＰ）を示してよい。
【０１１１】
ブロック１２１５では、ＡＰが流入パラメータ(admission parameters)を決定する。パケットがＡＰ適応層に到達し、フロー分類によって新しいフローであると判断されると、フロー分類はＱｏＳクラス（高ＱｏＳまたは最善の努力）、ＬＬモード、及びフローに割り当てられる名目速度を含む流入パラメータを決定するためにＱｏＳマネージャと協力する。決定ブロック１２２０では、流入パラメータに基づいて層マネージャ内の流入制御は、フローを認めることができるかどうかを判断する。認めることができない場合には、プロセスは停止してよい。それ以外の場合、ブロック１２２５に進む。
【０１１２】
ブロック１２２５では、フロー分類がＬＬＣに新しいストリームを確立するように要求する。この説明では、高ＱｏＳ、ＬＬモード３接続のケースを考える。ブロック１２３０では、ＡＰでのＬＬＣは接続（あるいは、適切な接続がすでに存在する場合には新しいストリームＩＤ）を確立するためにＵＴでのＬＬＣと通信する。この例では、ＬＬＣはＬＬモード３接続（あるいはＬＬモード３接続がすでに存在する場合には新しいストリームＩＤ）を確立しようとする。ブロック１２３５ではフローに割り当てられる名目レートがスケジューラに通信される。ＬＬモード３のケースでは、名目割り当ては順方向チャネルと逆方向チャネルの両方で行われる。
【０１１３】
ブロック１２４０では、フロー分類がフローのためのパケットを分類し、ＭＡＣ ＩＤ、ＬＬモード及びストリームＩＤを識別し、フロー管理（ｐｏｌｉｃｉｎｇ）を行い、ＳＡＲ関数に対応するパケットを転送する。ブロック１２４５では、ＳＡＲがパケットを分割し、ＬＬモードとストリームＩＤとともにＭＡＣ ＩＤのために適応層ＰＤＵをＬＬ関数に転送する。ブロック１２５０では、ＬＬ関数はＬＬヘッダとＣＲＣをアタッチし、ＬＬ ＰＤＵを適切な待ち行列の中に入れる。この例では、ＬＬモード３関数はＬＬヘッダとＣＲＣをアタッチし、ＬＬ ＰＤＵをＭＵＸの高ＱｏＳ待ち行列に入れる。
【０１１４】
ブロック１２５５では、ＭＵＸはＬＬモードと長さを識別するＭＵＸヘッダをアタッチすることによりＭＵＸ ＰＤＵを作成する。ＭＵＸは、第１の新しいＭＵＸ ＰＤＵの始まりまでのバイト数を示すＭＵＸポインタを作成する。
【０１１５】
ブロック１２６０では、スケジューラがＭＡＣ ＩＤについてＦ−ＴＣＨ（物理層バースト）割り当てを決定する。スケジューラは（ＵＴプロキシから）（ＲＲＣからの）伝送モードと使用されるレートを知る。逆方向リンク割り当ても含まれてよいことに注意する。ブロック１２６５では、割り当てはＣＣＨで送信される。
【０１１６】
ブロック１２７０では、ＭＡＣはＭＡＣ ＰＤＵを送信する。ＭＡＣ ＰＤＵはＭＵＸポインタからなり、その後に、考えられる部分的なＭＵＸ ＰＤＵが開始時に続き、ゼロまたは１つ以上の完全なＭＵＸ ＰＤＵが続き、最後に物理層バーストの最後にある考えられる部分的なＭＵＸ ＰＤＵが続く。
【０１１７】
図１３は、ＵＴでのユーザデータフローのための例の方法１３００を描く。ブロック１３１０では、ＵＴはＣＣＨでの割り当てを受信する。ブロック１３２０では、ＵＴは割り当てに従ってＭＡＣ ＰＤＵを受信する。ブロック１３３０では、ＵＴでのＭＵＸが、ＭＵＸポインタとＭＵＸヘッダ内の長さフィールドを使用することによりＭＵＸ ＰＤＵを抽出し、ＬＬ ＰＤＵを作成する。ブロック１３４０では、ＭＵＸヘッダのタイプフィールドに基づいて、ＭＵＸは適切なＬＬ関数、この例ではＬＬモード３にＬＬ ＰＤＵを送信する。ブロック１３５０では、ＬＬモード３がＡＲＱ受信機を実行し、各ＬＬ ＰＤＵにＣＲＣを計算する。ブロック１３６０では、ＵＴでのＬＬモード３がＡＰでＬＬモード３ ＡＲＱにＡＣＫ／ＮＡＫを送信しなければならない。ＡＣＫ／ＮＡＫはＵＴ ＭＵＸで高ＱｏＳ待ち行列に入れられる。他のＬＬモードが前述されたように肯定応答を含まない可能性があることに注意する。
【０１１８】
ブロック１３７０では、ＡＰは割り当てに従ってＡＣＫ／ＮＡＫをＲ−ＴＣＨで送信する。スケジューラが逆方向リンクのための名目割り当てに基づいてＭＡＣ ＩＤのためにＲ−ＴＣＨリソースを割り当てることに注意する。ＡＣＫ／ＮＡＫメッセージは、ＵＴから逆方向リンク物理層バーストでＭＡＣ ＰＤＵ内で送信される。ブロック１３８０では、ＵＴは残りの割り当てで他の待ち行列に入れられた逆方向リンクを送信してよい。
【０１１９】
再び図３に戻ると、前述されたように、フロー２６０はＡＰ ＭＡＣプロセッサ２２０で受信され、それぞれのデータとシグナリングはＵＴへの伝送のために適応層３１０、データリンク制御層３２０及び物理層を通って下方に移動する。ＵＴでの物理層２４０はＭＡＣ ＰＤＵとそれぞれのデータを受信し、シグナリングはＵＴ ＭＡＣプロセッサ２２０でデータリンク制御層３２０と適応層３１０、１つまたは複数のさらに高いレベルの層へ（つまり、データ、音声、ビデオ等を含む多様なプロセスへ）の配信のためにリアセンブルされたフローを通って上方に移動する。類似したプロセスはＵＴで発し、ＡＰに送信されるフローのために逆に起こる。
【０１２０】
ＡＴとＵＴの両方において、それぞれの層マネージャ３８０は、多様なＭＡＣ副層を情報がどのようにして上下に流れるのかを制御するために展開されてよい。広く述べられるように、物理層２４０からの任意のタイプのフィードバック２８０は、多様な副層関数を実行するための層マネージャ３８０で使用されてよい。物理層マネージャ３８６は物理層２４０を接続する。フィードバックは層マネージャ内の任意の関数が使用できる。例は流入制御関す３８４とＱｏＳマネージャ３８２を含む。これらの関数は同様に前述された副層関数のどれかと対話してよい。
【０１２１】
ここに説明されている原則は、複数の伝送フォーマットをサポートする物理層指定で展開されてよい。例えば、多くの物理層フォーマットは複数の伝送レートを可能にする。既定の物理層のためにスループットは、使用可能な電力、チャネル上での干渉、及びサポート可能な変調フォーマット等により決定されてよい。例のシステムは、ＭＩＭＯ技法を利用してよいＯＦＤＭシステムとＣＤＭＡシステムの両方を含む。これらのシステムでは、速度とフォーマットを決定するために閉ループ技法が使用される。閉ループはチャネル測定、サポート可能なレート等を示すために多様なメッセージまたは信号を利用してよい。当業者は、ここに説明されている技法を展開するためにこれらのシステム及び他のシステムを容易に適応するであろう。
【０１２２】
物理層フィードバックは適応層３１０で使用されてよい。例えば、速度情報はセグメンテーションとリアセンブリ、フロー分類、及びマルチキャストマッピングで使用されてよい。図１４は、物理層フィードバックを適応層関数に組み込むための例の方法１４００を描く。この方法はアクセスポイントに関して説明されているが、ユーザ端末と類似した様式で適用できる。プロセスは、フローパケットが１台または複数台のユーザ端末への伝送のために受信されるブロック１４１０で開始する。ブロック１４２０では、適応層関数はそれぞれのユーザ端末のための物理層フィードバックに応えて実行される。この態様をさらに説明するために、例のマルチキャストマッピングとセグメンテーションの実施形態が後述される。ブロック１４４０では、物理層フィードバックは１台または複数台のユーザ端末について監視されている。プロセスは更新された物理層フィードバックに応えて追加の受信されたフローパケットについて繰り返すためにブロック１４１０に戻ってよい。
【０１２３】
代替実施形態では、他の物理層フィードバックの速度情報は、流入制御決定を下す上で使用されてよい。例えば、高ＱｏＳフローは、ターゲットＭＡＣ ＩＤ物理リンクが十分な効率レベルの伝送レートをサポートできない限り承認を与えられない可能性がある。このレベルは、既存のフローに対する名目割り当て、登録済みのＵＴの数等を含む、システムの負荷に基づいて適応されてよい。例えば、相対的に高品質のリンクを備えたＵＴは、低い質のリンクと関連付けられたＭＡＣ ＩＤより高いＱｏＳのフローを割り当てられる可能性が高い。システムが軽く負荷をかけられているとき、閾値要件は削減されてよい。
【０１２４】
適応層マルチキャスト
図１５は、適応層マルチキャストを実行するための例の方法１５００を描く。適応層マルチキャストは適応層関数に物理層フィードバックを組み込むための方法１４００の例である。マルチキャスト伝送の１つの方法、つまりＭＡＣ層マルチキャストがユーザ端末ＭＡＣ ＩＤのどれかから区別される共通つまりマルチキャストＭＡＣ ＩＤであるユーザ端末のリストに対応する共通ＭＡＣ ＩＤを提供することに注意する。したがって、ＵＴは１つまたは複数のマルチキャストグループに割り当てられるとき、その個々のＭＡＣ ＩＤに向けられる伝送のためだけではなく、ＵＴが関連付けられている１つまたは複数のマルチキャストＭＡＣ ＩＤに向けられる伝送のためのＣＣＨも監視する。このようにして、マルチキャストＭＡＣ ＩＤは、複数のユーザ端末への単一のフローの伝達を可能にするために、１つまたは複数のさらに高い層のフローに関連付けられてよい。
【０１２５】
適応層マルチキャストでは、マルチキャストリストの中のすべてのユーザ端末による受け入れのために単一の伝送を実行する代わりに、マルチキャストデータの１つまたは複数の追加の伝送がユーザ端末の１つまたは複数に行われてよい。実施形態では、適応層マルチキャストはマルチキャストグループ内の各ユーザ端末に対するユニキャスト伝送を行う。別の実施形態では、適応層マルチキャストは、マルチキャストグループの部分集合に関連付けられる１つまたは複数のＭＡＣ ＩＤを使用して１つまたは複数のＭＡＣ層マルチキャスト伝送を行ってよい。ユニキャスト伝送はサブグループの１つに含まれないユーザ端末に向けられてよい。前記の任意の組み合わせが展開されてよい。ブロック１５１０では、ユーザ端末のリストに向けられるマルチキャストフローが受信される。一実施形態では、ＭＡＣ ＩＤはユーザ端末のリストと関連付けられている。
【０１２６】
決定ブロック１５２０では、ユニキャスト伝送が、リスト中のユーザ端末へのマルチキャスト伝送（つまり、複数のユーザにより受信される単一伝送）より効率的であるかどうかの決定が下される。効率的である場合には、ブロック１５３０で、マルチキャストフローは２つまたは３つ以上のチャネルで送信される。該２つまたは３つ以上のチャネルはユニキャストチャネル、他のマルチキャストチャネル、あるいは両方の組み合わせを含んでよい。決定ブロック１５０２では、マルチキャストチャネルがより効率的である場合には、マルチキャストデータはマルチキャストＭＡＣ ＩＤを使用して単一伝送でマルチキャストグループのメンバーに放送される。
【０１２７】
一般的には、マルチキャスト伝送はマルチキャストグループ内のユーザ端末の物理リンクのグループの中で最も弱い物理リンクでの伝送に適したフォーマットを使用しなければならない。いくつかのシステムでは、それにも関わらず最低品質の物理リンクを備えるユーザ端末に到達するには最小公約数の伝送が行われなければならないため、よりよい位置に置かれるユーザ端末の方がより速い速度とより大きなスループットの恩恵を受けることができるという事実はシステムスループットを達成しない。しかしながら、他の状況では、これは当てはまらない可能性がある。例えば、ＭＩＭＯシステムでの空間処理の使用を考える。マルチキャストグループのメンバーはカバレージエリア全体で分散されてよく、２人または３人以上のメンバーが非常に異なるチャネル特性を有することがある。２台のユーザ端末を備えるマルチキャストの例示的な例を考える。ユーザ端末ごとに伝送フォーマットを合わせることによって、それぞれに対するユニキャスト伝送について高スループットが達成されてよい。しかしながら、各物理リンクのための２つのチャネル環境はきわめて異なるため、単一のマルチキャストメッセージで各ユーザ端末に到達するために適した伝送フォーマットはユニキャストチャネルのどちらよりも低いスループットとなる可能性がある。マルチキャストチャネルとユニキャストチャネルのスループットの差異が十分に大きいときには、システムは両方が受信可能な単一のメッセージを送信することによりマルチキャストデータの２つの独立した伝送を行うことによってより少ない資源を使用してよい。
【０１２８】
図１６は、適応層マルチキャストを使用するのか、またはＭＡＣ層マルチキャストを使用するのかを決定するための決定ブロック１５２０での展開に適した例の方法を示す。ブロック１６１０では、マルチキャストリストの中のユーザ端末ごとのリンクパラメータを受信する。一実施形態では、速度パラメータが使用されてよい。ブロック１６２０では、マルチキャストリストの中のユーザ端末への伝送に適したマルチキャストチャネルのためのリンクパラメータを受信する。マルチキャストチャネルのためのリンクパラメータはマルチキャストグループの中のユーザ端末のために個々のチャネルのどれか及びすべてのためのリンクパラメータと異なっていてよい。ブロック１６３０では、マルチキャストチャネルでの伝送（つまり単一の伝送にマルチキャストＭＡＣ ＩＤを使用する）のためのシステム資源要件を、個々のユニキャスト伝送の合計のためのシステム資源要件と比較するより効率的な選択を決定するには、最低のシステム資源要件が使用されてよい。
【０１２９】
代替実施形態では、ブロック１６１０はマルチキャストグループユーザ端末のサブグループを備えるリンクパラメータＭＡＣ層マルチキャストチャネルを含むように修正されてよい。マルチキャストとユニキャストの組み合わせは純粋なＭＡＣ層マルチキャストと比較されてよい。これらの及び他の修正は当業者に明らかとなるであろう。
【０１３０】
物理層フィードバックセグメンテーション
図１７は、物理層フィードバックに応えてセグメンテーションを実行するための例の方法１７００を描く。これは適応層関数の中に物理層フィードバックを組み込むための方法１４００の別の例として役立つ。このプロセスは、層マネージャ３８０によって提供される物理層フィードバックに応えて適応層３１０でセグメンテーションとリアセンブリ関数３１２で実施されてよい。
【０１３１】
ブロック１７１０では、フローのためのパケットが対応するＭＡＣ ＩＤへの伝送のために受信される。ブロック１７２０では、該それぞれのＭＡＣ ＩＤのための伝送速度情報を取り出す。ブロック１７３０では、該ＭＡＣ ＩＤ速度に応えてパケットを分割する。例の実施形態では、このセグメンテーションは、図４に関して前述されたように、適応副層ＰＤＵ ４３０を生じさせるために使用されるセグメント４２０を生じさせる。
【０１３２】
図１８は、伝送速度に応えて分割することを描く方法の例の実施形態を描く。この方法は、ちょうど説明されたブロック１７３０内での展開に適している。プロセスは決定ブロック１８１０で開始する。速度変化があった場合、決定ブロック１８２０に進む。速度変化がなかった場合、プロセスは停止してよく、セグメンテーションサイズは変更されないままであってよい。
【０１３３】
決定ブロック１８２０では、速度変化が速度加速であった場合には、セグメントサイズを拡大することに関連付けられる利得があってよい。例えば、図４に前述されたように、各セグメントがプロトコルスタックを横断するときのオーバヘッドの層を受信する。セグメント数を削減すると、必要とされるオーバヘッドの量が削減される。さらに、より高速の速度は通常より高品質のチャネルを示す。チャネルが経時的に、きわめて劇的に変化する一方で、概してチャネルは時間の特定のセグメントの間相対的に一定のままとなる。セグメントサイズが対応して拡大される速度の加速は、より小さい速度のより小さいセグメントとほぼ同じ量の時間でのセグメントの伝送を可能にしてよい。この時間量が、チャネルが相対的に安定したままとなる傾向がある時間に正比例する（つまりサポート可能な速度が変化しなかった）場合には、セグメントサイズを拡大することは、セグメントサイズ拡大のマイナス影響が起こりそうにない効率の改善を可能にすることがある。
【０１３４】
セグメントサイズを選択するための別の考慮事項は物理層速度の変化が発生したときである。速度変化はセグメントサイズを変更する必要性をトリガする可能性があり、その結果、最も短い遅延制約要件のサービスの遅延抑制、つまり制御メッセージ待ち行列は、図１９から図２３に関してさらに詳しく後述されるＭＵＸ関数のノンプリエンプティブ優先順位により満たされる。
【０１３５】
セグメントサイズを選択するための多様な技法は本発明の範囲内で組み込まれてよい。図１８に戻ると、例の実施形態では、速度変化が決定ブロック１８２０で発生すると、適応副層ＰＤＵサイズを拡大するためにブロック１８３０に進む。決定ブロック１８２０では、速度変化が速度減速であった場合には、ちょうど説明された技法のどれかに従って適応副層ＰＤＵサイズを縮小するためにブロック１８４０に進む。
【０１３６】
図１８の方法は、おもに物理層速度とセグメンテーションサイズの関係性を使用するセグメンテーションのための１つの考えられる機構を示すために役立つ。代替実施形態では、セグメンテーションサイズの表が作成されてよく、各セグメンテーションサイズは速度、つまり速度の範囲に関連している。さらに別の実施形態では、１つのオペランドが速度である関数が展開されてよく、該関数の出力がセグメンテーションサイズを生じさせる。ここの教示を鑑みて無数の他の可能性が当業者に明らかになるであろう。セグメンテーションが、物理層フィードバックに応えて実行される任意の他の適応層関数だけではなく、ちょうど説明されたように図１４から図１６に関して前述されたようなマルチキャストマッピング技法と結合されてよいことに注意する。
【０１３７】
多重化
無線ネットワーク１２０等の例の高性能無線ＬＡＮサブネットワークでは、すべての通信はＡＰ１０４と１台または複数台のＵＴ１０６の間で発生してよい。前述されたように、これらの通信は本来ユニキャストまたはマルチキャストのどちらかであってよい。ユニキャスト通信では、ユーザデータまたは制御データはＡＰから単一のＵＴに、あるいはＵＴからＡＰに送信される。各ＵＴは一意のＭＡＣ ＩＤを有するので、ＵＴとＡＰの間のすべてのユニキャスト通信はその一意のＭＡＣ ＩＤと関連付けられている。マルチキャスト通信では、ユーザデータまたは制御データはＡＰから複数のＵＴに送信される。マルチキャストアドレスとして使用するために取り除けられているＭＡＣ ＩＤのプールがある。アクセスポイントと関連付けられている、定義されている１つまたは複数のマルチキャストグループがあってよく、これらのグループのそれぞれには一意のマルチキャストＭＡＣ ＩＤが割り当てられている。各ＵＴはこれらのマルチキャストグループの１つまたは複数（あるいはどれにも）属し（属さず）、それが属する各マルチキャストグループと関連付けられた伝送を受信する。多重化の説明のために、適応層マルチキャスト（ｍｕｌｔｉｃａｓｔｉｎｇ）はユニキャストしている（ｕｎｉｃａｓｔｉｎｇ）とみなされる。この例ではＵＴはマルチキャストデータを送信しない。
【０１３８】
アクセスポイントは、そのカバレージエリア内でＵＴにアドレス指定されている外部ネットワーク（つまり、ネットワーク１０２）から、及び他の装置に向けられているそのカバレージエリア内のＵＴからユーザデータを受信し、ＵＴはカバレージエリア内にあるか、ネットワーク１０２を通して取り付けられているかのどちらかである。アクセスポイントは、他のエンティティだけではなく無線リンク制御（ＲＬＣ）関数３４０、論理リンク制御（ＬＬＣ）関数３３０からのカバレージエリア内の個々のまたは複数のＵＴ向けの制御データを生成してもよい。単一のＵＴにアドレス指定されるユーザデータは、Ｑｏｓ考慮事項または前述されたように、ソースアプリケーション等の他の考慮事項に基づいて複数のストリームにさらに分離されてよい。
【０１３９】
前記に詳述されるように、アクセスポイントは単一のＭＡＣ ＩＤ向けのすべてのソースからのすべてのデータを最終的に、次にそれぞれが単一のＭＡＣフレームで送信されるＭＡＣ ＰＤＵにフォーマットされる単一のバイトストリームに集計する。アクセスポイントは、単一のＭＡＣフレームの中の（つまり順方向リンクで）１つまたは複数のＭＡＣ ＩＤのためにＭＡＣ ＰＤＵを送信してよい。
【０１４０】
同様に、ＵＴは複数のストリームに分離されてよい送信するためのユーザデータを有することがある。ＵＴはＲＬＣ３４０、ＬＬＣ３３０または他のエンティティと関連付けられている制御情報も生成してよい。ＵＴはユーザデータと制御データを、次にそれぞれが単一のＭＡＣフレーム内のＡＰに送信されるＭＡＣ ＰＤＵにフォーマットされる１つのバイトストリームに集計する。１台または複数台のＵＴは単一のＭＡＣフレーム内で（つまり逆方向リンクで）ＭＡＣ ＰＤＵを送信してよい。
【０１４１】
ＭＵＸ関数３６０はＡＰでＭＡＣ ＩＤごとに実現される。各ＵＴはユニキャスト伝送のために初期に１つのＭＡＣ ＩＤを割り当てられる。追加のＭＡＣ ＩＤは、ＵＴが１つまたは複数のマルチキャストグループに属する場合に割り当てられてよい。ＭＵＸ関数は（ａ）バイトストリームとして処理されるＭＡＣ ＩＤへの連続物理層バースト割り当てと、（ｂ）１つまたは複数のＬＬまたはＲＬＣエンティティからＭＡＣのバイトストリームへのＰＤＵの多重化を可能にする。
【０１４２】
図１９は、複数のフローとコマンドを単一のＭＡＣフレームに送信するための例の方法１９００を描く。この方法はアクセスポイントまたはユーザ端末どちらかでの配備に適している。プロセスは決定ブロック１９１０で開始する。ＭＡＣ ＩＤ宛ての１つまたは複数のフローからの１個または複数個のパケットが受け取られる場合、それぞれの１つまたは複数のフローのためにＭＡＣ ＩＤと関連付けられているＭＵＸ ＰＤＵを作成するためにブロック１９２０に進む。例の実施形態では、ＭＵＸ ＰＤＵは上記に詳説されたＭＡＣプロトコルに従って作成されるが、代替ＭＡＣプロトコルは本発明の範囲内で配備されてよい。ＭＵＸ ＰＤＵは適切な待ち行列（この例の実施形態では、高ＱｏＳまたは最善の努力）に入れられてよい。決定ブロック１９１０でＭＡＣ ＩＤのためにフローが受信されない場合あるいはＭＵＸ ＰＤＵがブロック１９２０で作成された後に、決定ブロック１９３０に進む。
【０１４３】
決定ブロック１９３０では、１つまたは複数のコマンドが例えばＲＬＣ３４０またはＬＬ３３０からＭＡＣ ＩＤに関連付けられているＵＴに送信されなければならない場合、ブロック１９４０に進み、コマンドＰＤＵごとにＭＵＸ ＰＤＵを作成する。ＭＡＣ ＩＤに何のコマンドも宛てられない場合、あるいはいったんＭＵＸ ＰＤＵがブロック１９４０で作成された場合、決定ブロック１９５０に進む。
【０１４４】
決定ブロック１９５０は、ＭＡＣ ＩＤ宛てのフローを絶えず監視するための反復プロセスを示す。代替実施形態は全体的なアクセスポイントまたはユーザ端末プロセスの他の部分にルーピング特徴を入れてよい。代替実施形態では、プロセス１９００は繰り返して反復する、あるいは別の反復プロセスに含まれる。例示のためだけに、このプロセスは単一ＭＡＣ ＩＤのために説明されている。アクセスポイントでは、複数のＭＡＣ ＩＤが並列処理されてよいことが明らかになるであろう。これらの変型及び他の変型は当業者に明らかになるであろう。
【０１４５】
コマンドまたはフローが処理のために準備完了していないとき、この例では、プロセスはループを反復するために決定ブロック１９１０に一巡して戻る。ユーザ端末では、前述されたように、ＭＡＣフレーム割り当てを開始するためにアクセスポイントに要求を行う必要がある場合がある。任意のこのような技法が展開されてよい。詳細は図１９に含まれていない。明らかに、コマンドまたはフローが伝送を待機していない場合、要求を行う必要はなく、したがってＭＡＣフレーム割り当ては到達しない。コマンドまたはフローが伝送を待機しているとき、スケジューラは前述されたように任意の時点でＭＡＣフレーム割り当てを行ってよい。例の実施形態では、アクセスポイントスケジューラ３７６は、前述されたように、特定のＭＵＣ関数３６０内のＭＡＣ ＩＤ待ち行列に応えて順方向リンクＭＡＣフレーム割り当てを、ＲＣＨプロキシ待ち行列またはＵＴプロキシ待ち行列での要求に応えて逆方向リンクＭＡＣフレーム割り当てを行う。いずれにせよ、方法１９００を実行する通信装置は決定ブロック１９５０でＭＡＣフレーム割り当てを待機する。
【０１４６】
ＭＡＣフレーム割り当てが決定ブロック１９５０で行われるとき、１つまたは複数のＭＵＸ ＰＤＵがブロック１９６０で単一のＭＡＣ ＰＤＵに入れられる。ＭＡＣ ＰＤＵは、過去のＭＡＣフレームから残っている部分的なＭＵＸ ＰＤＵ、１つまたは複数のフローからＭＵＸ ＰＤＵ、１つまたは複数のコマンドＭＵＸ ＰＤＵ、またはこれらの組み合わせを含んでよい。部分的なＭＵＸ ＰＤＵは、割り当てられた空間が未使用のまま残る場合にＭＡＣフレームに挿入されてよい（あるいは任意のタイプのパディングが割り当てられたＭＡＣフレームを充填するために挿入されてよい）。
【０１４７】
ブロック１９７０では、ＭＡＣ ＰＤＵが割り当てにより示される位置にある物理リンクで送信される。ＭＡＣ ＰＤＵが１つまたは複数のフローまたはコマンドＰＤＵの任意の組み合わせからＭＵＸ ＰＤＵを備えてよいことに注意する。
【０１４８】
前述されたように、例の実施形態では、ＭＡＣ ＰＤＵは、Ｆ−ＴＣＨまたはＲ−ＴＣＨのどちらかでＭＡＣ ＩＤに割り当てられる物理層バーストに適合する伝送装置である。図２０は例のシナリオを示す。ＭＡＣ ＰＤＵ４６０は、ゼロまたは１つ以上の完全なＭＵＸ ＰＤＵ４６６が後に続き、開始時に考えられる部分的なＭＵＸ ＰＤＵ４６４が後に続くＭＡＣヘッダ４６２と、最終的には物理層バーストの最後の考えられる物理的なＭＵＸ ＰＤＵ４６８とを備える。それぞれの部分２つの連続するＭＡＣフレーム４６０Ａと４６０Ｂが示されていることに注意する。フレームｆの間に送信されるＭＡＣフレーム４６０の下位区分は付加された「Ａ」で識別される。フレームｆ＋１の間に送信されるＭＡＣフレーム４６０Ｂの下位区分は付加された「Ｂ」で識別される。ＭＵＸ ＰＤＵがＭＡＣ ＰＤＵ内で連結されるとき、割り当てを完全に活用するために、部分的なＭＵＸ ＰＤＵはＭＡＣ ＰＤＵの最後で送信されてよく、その場合ＭＵＸ ＰＤＵの残りは次のＭＡＣフレームで送信されるＭＡＣ ＰＤＵの始まりで送信される。これは、ＭＡＣ ＦＲＡＭＥ４６０Ａで送信される部分的なＭＵＸ ＰＤＵ４６８Ａによって図２０に示されている。そのＭＵＸ ＰＤＵ４６４Ｂの残りは次のＭＡＣ ＦＲＡＭＥ４６０Ｂの間に送信される。
【０１４９】
ＭＡＣヘッダはＭＵＸポインタ２０２０と、おそらくＭＡＣ ＰＤＵと関連付けられたＭＡＣ ＩＤ２０１０からなる。ＭＡＣ ＩＤは空間多重化が使用されているときに必要とされてよく、同時に送信される複数のＭＡＣ ＰＤＵがあってよい。当業者は、オプションであることを示すために陰影を付けて示されているＭＡＣ ＩＤ２０１０がいつ展開されなければならないのかを認識するであろう。
【０１５０】
例の実施形態では、（図２０でＭＵＸポインタ２０２０からＭＵＸ ＰＤＵ４６６Ａへの矢印で示されるように）ＭＡＣ ＰＤＵごとに２バイトのＭＵＸポインタ２０２０がＭＡＣ ＦＲＡＭＥで送信されるあらゆるＭＵＸ ＰＤＵの場所を識別するために展開される。ＭＵＸポインタ２０２０はＭＡＣ ＰＤＵごとに使用されている。ＭＵＸポインタは、ＭＡＣ ＰＤＵ内で第１のＭＵＸ ＰＤＵの開始を指す。各ＭＵＸ ＰＤＵヘッダに含まれる長さフィールドとともにＭＵＸポインタは、受信側ＭＵＸ層がＭＡＣ ＩＤに割り当てられている連続物理層バーストからなるバイトストリームからＬＬ ＰＤＵとＲＬＣ ＰＤＵを抽出できるようにする。当業者は本発明の範囲内でポインタを配備するための多様な代替手段を認識するであろう。例えば、ＭＡＣフレームは前述された例から代替順序で圧縮されてよい。残りの部分的なＭＵＸ ＰＤＵはＭＡＣフレーム割り当ての最後に置かれてよく、ポインタは新しいＭＵＸ ＰＤＵよりむしろ残りの開始を指す。したがって、存在する場合、新しいＰＤＵは始まりに配置される。任意の数のポインタ技法が展開されてよい（つまり、バイトを識別する指数値、時間値、オフセットが加えられたベース値、あるいは当業者に明らかとなるであろう任意の多数の変形）。
【０１５１】
例の実施形態では、ＭＵＸポインタ２０２０は、値がフレームで開始する第１のＭＵＸ ＰＤＵの始まりの、バイト単位でのＭＵＸポインタの最後からのオフセットを加えられた値である単一１６ビットフィールドを備える。値がゼロである場合、ＭＵＸ ＰＤＵはフレーム内で開始しない。値が１である場合、ＭＵＸ ＰＤＵはＭＵＸポインタに続いて即座に開始する。値がｎ＞１である場合、ＭＡＣ ＰＤＵ内の第１のｎ−１バイトは、過去のフレームで開始したＭＵＸ ＰＤＵの最後である。この情報は、受信機ＭＵＸ（つまりＭＵＸ関数３６０）が、ＭＵＸ ＰＤＵ境界との同期を失う結果となる過去のフレームのエラーから回復するのに役立ち、例は後述されている。当業者は、任意の数の代替指標付け技法が配備されてよいことを認識するであろう。
【０１５２】
タイプ（論理チャネル）フィールドと長さフィールドを備えるＭＵＸヘッダは、ＭＵＸに提供されるあらゆるＬＬまたはＲＬＬ ＰＤＵに取り付けられている。タイプ（論理チャネル）フィールドは、ＰＤＵが属するＬＬまたはＲＬＣエンティティを識別する。長さフィールドは、受信側ＭＵＸ層が、ＭＡＣ ＩＤに割り当てられている連続物理層バーストからなるバイトストリームからＬＬ ＰＤＵまたはＲＬＣ ＰＤＵを抽出できるようにするために、前述されたＭＵＸポインタとともに使用される。
【０１５３】
前述されたように、ＭＵＸ関数３６０は、データが送信されるために３つの待ち行列を維持する。高ＱｏＳ待ち行列３６２は、流入制御３８４によって保証速度を割り当てられた交渉済みのサービスと関連付けられるＬＬ ＰＤＵを含んでよい。最善の努力待ち行列３６４は、速度保証と関連付けられていないＬＬ ＰＤＵを含んでよい。制御メッセージ待ち行列３６６はＲＬＣ ＰＤＵまたはＬＬＣ ＰＤＵを含んでよい。
【０１５４】
代替実施形態は複数のＱｏＳ待ち行列を含んでよい。しかしながら、高速ＷＬＡＮの効率的な使用は、ここに詳説されるように、単一のＱｏＳ待ち行列が非常に優れたＱｏＳ性能を達成できるようにする。多くのケースでは、ＭＡＣプロトコルが使用可能なチャネル帯域幅を効率的に使用することにより、追加の待ち行列、及びそれにまつわる複雑さが不必要になる。
【０１５５】
ＡＰでは、これらの待ち行列のバックログは共通ＭＡＣ関数３７０のスケジューラ３７６が使用できるようになる。ＵＴでのこれらの待ち行列でのバックログは共通ＭＡＣ関数３６０でのＵＴプロキシ内のＡＰで維持される。ＵＴプロキシ待ち行列は、明確にするために図３に独立して識別されていないことに注意する。待ち行列３６２、３６４、及び３３６は、待ち行列が共用されるハードウェアまたは別々の構成要素で配備されるかどうかに関係なく、ＭＡＣ ＩＤごとに順方向リンク待ち行列と逆方向リンク待ち行列（つまり、ＵＴプロキシ待ち行列）の両方を備えるとしてみなされてよい。順方向リンクと逆方向リンクにサポートされている待ち行列の数とタイプが同一である必要がないことにさらに注意する。ＵＴプロキシ待ち行列もＵＴ待ち行列と同一に一致する必要はない。例えば、ＵＴは他の高いＱｏＳ ＰＤＵで特定の時間に敏感なコマンドに優先順位を付けるためにコマンド待ち行列を維持してよい。ＡＰでは、単一の高ＱｏＳは両方のタイプのＵＴトラフィックに対する要求を示すために使用されてよい。したがって、ＵＴに対して行われる割り当てはＵＴで決定される優先順位で満たされてよい。別の例としては、変化するＱｏＳ待ち行列は、それぞれＡＰまたはＵＴで維持されていないＵＴまたはＡＰのどちらかで維持されてよい。
【０１５６】
スケジューラ３７６は、すべてのＭＡＣ ＩＤからの競合する要件の中で調停し、１つまたは複数の選択されたＭＡＣ ＩＤにＦ−ＴＣＨまたはＲ−ＴＣＨ上の物理層バーストを割り当てる。割り当てに応えて、対応するＭＵＸ関数３６０はＬＬ ＰＤＵとＲＬＣ ＰＤＵを前述されたようにＭＡＣ ＰＤＵに圧縮する。例の実施形態では、各ＭＵＸ関数３６０は以下のノンプリエンプティブ優先順位順序で（網羅的に）制御メッセージ待ち行列３６６、高ＱｏＳ待ち行列３６２、及び最善の努力待ち行列３６４からＰＤＵを供給する。（たとえそれが低い方の優先順位待ち行列からであったとしても）高い方の優先順位待ち行列からの新しいＰＤＵが供給される前に、最初に過去のＭＡＣ ＰＤＵから部分的なＰＤＵが完了される。代替実施形態では、当業者に明らかになるように、先取りは１つまたは複数のレベルで展開されてよい。
【０１５７】
受信機では、ＭＵＸ関数は連続ＭＡＣ ＰＤＵからなるバイトストリームからＰＤＵを抽出し、それらをそれが属するＬＬエンティティまたはＲＬＣエンティティに送る。ルーティングはＭＵＸ ＰＤＵヘッダに含まれているタイプ（論理チャネル）フィールドに基づいている。
【０１５８】
例の実施形態では、ＭＵＸ関数の設計に従って、いったんＭＵＸ ＰＤＵの伝送が開始されると、それは別のＭＵＸ ＰＤＵが開始される前に完了される。このようにして、最善の努力待ち行列からのＭＵＸ ＰＤＵの伝送がＭＡＣフレームで開始されると、それは、制御メッセージ待ち行列または高ＱｏＳ待ち行列からの別のＭＵＸ ＰＤＵが送信される前に以後のＭＡＣフレーム（または複数のフレーム）で完了される。すなわち、通常の動作では、高い方のクラスの待ち行列がノンプリエンプティブ優先順位を有する。
【０１５９】
代替実施形態では、または例の実施形態の特定のケースでは、先取りが所望されてよい。例えば、物理層データレートが変化した場合、至急制御メッセージを送信することが必要となり、伝送での最善の努力または高いＱｏＳ ＭＵＸ ＰＤＵに優る先取り優先順位を必要とする場合がある。これが可能になる。不完全に送信されたＭＵＸ ＰＤＵは詳しく後述される受信ＭＵＸにより検出され、廃棄される。
【０１６０】
さらに、プリエンプティブなイベント（すなわち、物理層速度の変化）はそのＵＴのために使われるように、セグメントサイズを変更する必要性をトリガする可能性がある。ＵＴのセグメントサイズは、遅延抑制または制御メッセージ待ち行列が最短であるサービスの遅延制約がＭＵＸ関数のノンプリエンプティブ優先順位により満たされるように選ばれてよい。これらの技法は前記図１７から図１８に関して前述されたセグメンテーションのための技法と組み合わされてよい。
【０１６１】
図２１は、ＭＵＸポインタを使用してＭＡＣフレームを作成するための例の方法２１００を示す。この方法はＡＰまたはＵＴのどちらかで展開されてよい。当業者は、ここの教示を鑑みて例示的な例を無数の実施形態、ＡＰまたはＵＴに容易に適応するであろう。プロセスはブロック２１１０で開始し、割り当てはＭＡＣ ＰＤＵについて受け取られる。
【０１６２】
決定ブロック２１２０では、部分的なＭＵＸ ＰＤＵが過去のＭＡＣフレーム伝送から残る場合、決定ブロック２１３０に進む。部分的なＭＵＸ ＰＤＵが残らない場合には、ブロック２１５０に進む。
【０１６３】
決定ブロック２１３０では、先取りが所望される場合、部分的なＭＵＸ ＰＤＵは送信されない。ブロック２１５０に進む。例の実施形態では、先取りは時間に敏感なコマンドＭＵＸ ＰＤＵを転送するために特定のケースで使用されてよい。先取りの他の例は前記に詳説されている。任意の先取り状態は、ＭＵＸ ＰＤＵの残りを送信するのを差し控えることが所望されるときに使用されてよい。ＭＡＣフレームの受信機はＭＵＸ ＰＤＵの前の部分を単に廃棄するだけでよい。例の受信機関数は以下に詳説される。代替実施形態では、先取りは、先取られた部分的なＭＵＸ ＰＤＵを後に送信できるようにするために定義されてよい。代替実施形態は決定ブロック２１３０での使用のために任意の数の先取り規則を配備してよい。先取りが所望されない場合にはブロック２１４０に進む。
【０１６４】
ブロック２１４０では、最初に部分的なＭＵＸ ＰＤＵをＭＡＣ ＰＤＵに入れる。割り当てが部分的なＭＵＸ ＰＤＵより小さい場合、割り当ては所望されるのと同じくらい多くのＭＵＸ ＰＤＵで充填されてよく、残りは以後のＭＡＣフレーム割り当てでの伝送のために保存されてよい。
【０１６５】
ブロック２１５０では、あらゆる新しいＭＵＸ ＰＤＵがＭＡＣ ＰＤＵに入れられてよい。ＭＵＸ関数は使用可能な待ち行列のどれかからＭＵＸ ＰＤＵを置く優先順位を決定してよい。任意の優先順位方式が展開されてよいが、例の優先順位方式が前述された。
【０１６６】
ブロック２１６０では、ＭＵＸポインタは第１の新しいＭＵＸ ＰＤＵの場所に設定される。例の実施形態では、ゼロというＭＵＸポインタ値は、ＭＵＸ ＰＤＵが割り当てに含まれていないことを示す。１というＭＵＸポインタ値はＭＡＣヘッダに続く第１のバイトが次の新しいＭＵＸ ＰＤＵの始まりである（つまりＭＡＣ ＰＤＵの始まりに部分的なＭＵＸ ＰＤＵがない）ことを示している。他のＭＵＸポインタ値は残りの部分的なＭＵＸ ＰＤＵとあらゆる新しいＭＵＸ ＰＤＵの開始の間の適切な境界を示す。代替実施形態では、他の特殊なＭＵＸポインタ値が定義されてよい、あるいは他のポインタ方式が展開されてよい。
【０１６７】
ブロック２１７０では、割り当てられたＭＡＣ ＰＤＵに空間が残っている場合、部分的なＭＵＸ ＰＤＵは残り配置されてよい。代わりに、任意の種類のパディングが残りの空間に挿入されてよい。部分的に配置されたＭＵＸ ＰＤＵの残りは以後のフレーム割り当てでの伝送のために保存されてよい。
【０１６８】
図２２は、ＭＵＸポインタを備えるＭＡＣフレームを受信するための例の方法２２００を示す。この方法はＡＰまたはＵＴのどちらかで展開されてよい。当業者はここの教示を鑑みてこの例示的な例を無数の実施形態、ＡＰまたはＵＴに容易に適応するであろう。
【０１６９】
プロセスは、ＭＡＣ ＰＤＵが受信されるブロック２２１０で開始する。ブロック２２１５では、ＭＵＸポインタはＭＡＣ ＰＤＵから抽出される。決定ブロック２２２０では、ＭＵＸポインタが１より大きい場合、ブロック２２２５に進む。例の実施形態では、ＭＵＸポインタが０または１である場合、ＭＡＣフレームの始まりに部分的なＭＵＸ ＰＤＵはない。０というＭＵＸポインタは、まったくＭＵＸ ＰＤＵがないことを示す。いずれのケースでも、決定ブロック２２３０に進む。
【０１７０】
決定ブロック２２３０では、過去のＭＡＣフレームから記憶されていた部分的なＭＵＸ ＰＤＵがある場合、ブロック２２３５に進み、該記憶されていた過去のフレームを廃棄する。この例では、記憶されていたフレームの残りは先取りされている。代替実施形態は記憶されていたフレームの残りの以後の伝送を可能にしてよく、その場合前の部分的なＭＵＸ ＰＤＵは保存されてよい（詳細は例示的な例の方法２２００に示されていない）。部分的なＭＵＸ ＰＤＵが記憶されていなかった場合、決定ブロック２３３０、あるいは以後の処理で、記憶されていた前の部分的なＭＵＸ ＰＤＵを処理する際にはブロック２２４０に進む。
【０１７１】
ブロック２２４０では、存在する場合は、ＭＵＸポインタによって示される場所で開始する新しいＭＵＸ ＰＤＵを取り出す。例の実施形態では、ゼロというＭＵＸポインタ値がＭＡＣ ＰＤＵ内に新しいＭＵＸ ＰＤＵがないことを示していることに注意されたい。新しい部分的なＭＵＸ ＰＤＵを含む新しいＭＵＸ ＰＤＵは取り出されてよい。前述されたように、ＭＵＸ ＰＤＵヘッダの長さフィールドはＭＵＸ ＰＤＵの境界を定めるために使用されてよい。
【０１７２】
決定ブロック２２４５では、部分的なＭＵＸ ＰＤＵがＭＡＣ ＰＤＵに含まれていた場合、部分的なＭＵＸ ＰＤＵを記憶するためにブロック２２５０に進む。記憶された部分的なＭＵＸ ＰＤＵは（部分的なＭＵＸ ＰＤＵが前述されたように破棄されなければならないと後に判断されない限り）将来のＭＡＣ ＰＤＵからの残りと結合されてよい。決定ブロック２２４５では、ＭＡＣ ＰＤＵに含まれる新しい部分的なＭＵＸ ＰＤＵはなかった、あるいは部分的なＭＵＸ ＰＤＵがブロック２２５０に記憶されていた場合にはブロック２２５５に進む。
【０１７３】
ブロック２２５５では、任意の完全なＭＵＸ ＰＤＵが、前記に詳説されるように、適宜にプロトコルスタックにおけるリアセンブリを含む追加の処理のために配信されてよい。
【０１７４】
前述されたように、ＭＵＸ関数は、ＭＡＣフレーム上に画定されているトラフィックチャネルセグメント（Ｆ−ＴＣＨとＲ−ＴＣＨ）の中での論理チャネルの多重化を可能にする。例の実施形態では、ＭＵＸ関数により多重化される論理チャネルはＭＵＸヘッダ内の４ビットメッセージタイプフィールドにより識別され、例は表１に詳説される。
【表１】
2010200363.tif 000003
【０１７５】
図２３は、表１に示されているＭＵＸタイプのいくつかについて例のＭＵＸ ＰＤＵを示す。ユーザデータチャネルＰＤＵ、ＵＤＣＨ０ ２３１０、ＵＤＣＨ１ ２３２０、ＵＤＣＨ２ ２３３０、ＵＤＣＨ３ ２３４０がユーザデータを送信し、受信するために使用されてよい。ＰＤＵは図４に関して前記に詳説されるように形成されてよい。各ＰＤＵはタイプと長さフィールドのあるＭＵＸヘッダを備える。ＭＵＸヘッダの後に続くのは、ＬＬヘッダ、１バイトのＡＬヘッダ、４０８７バイトまでのデータ、及び３バイトのＣＲＣである。ＵＤＣＨ０ ２３１０の場合、ＬＬヘッダは１バイトである。ＵＤＣＨ１ ２３２０の場合、ＬＬヘッダは２バイトである。ＵＤＣＨ２ ２３３０の場合、ＬＬヘッダは３バイトである。ＵＤＣＨ３ ２３４０の場合、ＬＬヘッダは４バイトである。これらのＬＬ ＰＤＵタイプを処理するための論理層関数は前述されている。
【０１７６】
やはり図２３に示されているのは多様な制御メッセージＰＤＵ２３５０から２３７０である。各ＰＤＵがタイプフィールド、予約フィールド、及び長さフィールドを含むＭＵＸヘッダを備える。ＭＵＸヘッダの後には、４バイトと２５５バイトの間であってよい可変長のデータフィールドが続き、ＲＬＣメッセージペイロードを含む。ラジオリンク放送チャネル（ＲＢＣＨ）ＰＤＵ２３５０、専用制御チャネルＰＤＵ（ＤＣＣＨ）ＰＤＵ２３６０及び論理リンク制御チャネル（ＬＬＣＨ）ＰＤＵ２３７０は図２３に描かれている。ユーザ放送チャネル（ＵＢＣＨ）ＰＤＵとユーザマルチキャストチャネル（ＵＭＣＨ）ＰＤＵのためのフォーマットはＵＤＣＨ０ ＰＤＵ２３１０に同一である。ＵＢＣＨのためのタイプフィールドは０１１１に設定される。ＵＭＣＨのためのタイプフィールドは１０００に設定される。
【０１７７】
当業者は、これらのＰＤＵが例示的に過ぎないことを認識するであろう。図示されているものの部分集合だけではなく、多様な追加のＰＤＵもサポートされてよい。代替実施形態では、図示されているフィールドのそれぞれが代替の幅を有してよい。他のＰＤＵは追加のフィールドも含んでよい。
【０１７８】
例のラジオリンク制御（ＲＬＣ）
ラジオリンク制御３４０は前述され、例の実施形態は本項にさらに詳説される。例のＲＬＣメッセージのセットは表２に述べられている。説明されている例のメッセージは例示的に過ぎず、追加のメッセージだけではなくこのメッセージの部分集合も代替の実施形態で展開されてよい。各メッセージのフィールドとフィールドのサイズも例である。当業者は、ここの教示を鑑みて無数の代替メッセージフォーマットを容易に適応するであろう。
【表２】
2010200363.tif 000004
【０１７９】
この例では、すべてのＲＬＣメッセージは、複数のトランスポートチャネルの１つで搬送されてよいが、共通した構造を有している。ＲＬＣ ＰＤＵ構造は特定のＲＬＣメッセージ、０から２５１バイトのペイロード及び３バイトのＣＲＣフィールドを識別する８ビットのタイプフィールドを備える。表３は、ＲＬＣメッセージの特定のクラスを示すためにタイプフィールドのビット位置の使用を示している。最上位ビット（ＭＳＢ）は、それぞれ順方向リンクメッセージまたは逆方向リンクメッセージ、０または１を示す。第２のＭＳＢが設定されていると、メッセージは未応答（ＮＡＣＫ）または拒絶メッセージではない。
【表３】
2010200363.tif 000005
【０１８０】
システム初期化中、システム識別制御３４６関数からなる放送ＲＬＣ関数が初期化されてよい。ＵＴは最初にアクセスプールからＭＡＣ−ＩＤを使用してシステムにアクセスすると、ＲＬＣ関数は新しいユニキャストＭＡＣ−ＩＤをＵＴに割り当てる。以後、ＵＴがマルチキャストグループに加わると、それには追加のマルチキャストＭＡＣ−ＩＤが割り当てられてよい。新しいユニキャストＭＡＣ−ＩＤがＵＴに割り当てられると、ＲＬＣは前述されたようにＡＣ ３４４、ＲＲＣ ３４２及びＬＬＣ３３８という関数のそれぞれの１つのインスタンスを初期化する。新しいマルチキャストＭＡＣ−ＩＤが割り当てられると、ＲＬＣは新しいＡＣインスタンスとＬＬＣをＬＬマルチキャストモードのために初期化する。
【０１８１】
表４に示されているシステム識別パラメータメッセージは、放送ＭＡＣ−ＩＤを使用して１６ＭＡＣフレームあたりに１回ＡＰにより送信される。システム識別パラメータメッセージは、プロトコル改定番号だけではなくネットワークＩＤとＡＰ ＩＤも含む。さらに、それはシステムへの初期アクセスのためにＵＴが使用するためにアクセスＭＡＣ−ＩＤのリストを含む。他の例のパラメータは表４に示されている。
【表４】
2010200363.tif 000006
【０１８２】
関連制御（ＡＣ）関数はＵＴ認証を行う。ＡＣ関数はＵＴの登録（つまり、アタッチ／タスク消去）関数を管理する。マルチキャストＭＡＣ−ＩＤのケースでは、ＡＣ関数はマルチキャストグループへのＵＴのアタッチ／タスク消去を管理する。ＡＣ関数はＬＬ制御のための暗号化のための鍵交換も管理する。
【０１８３】
表５に描かれている登録課題メッセージは、ＵＴから逆方向リンクで送信される。ＵＴは、ＡＰが、同時にアクセスし、同じＭＡＣ−ＩＤを選んだ可能性のある複数のＵＴの間で区別できるようにするために２４ビットの乱数を含む。
【表５】
2010200363.tif 000007
【０１８４】
表６に描かれている登録課題肯定応答メッセージは、登録課題メッセージに応えてＡＰによって送信される。ＡＰはＵＴによって送信されたランダムＩＤを含む。これによりアクセスのために同じＭＡＣ−ＩＤとスロットを選んだＵＴ間の衝突解決が可能になる。
【表６】
2010200363.tif 000008
【０１８５】
表７に描かれている登録課題拒絶メッセージは、例えば２台または３台以上のＵＴが同じ仮ＭＡＣ ＩＤを無作為に選択するときに仮ＭＡＣ ＩＤの割り当てを拒絶するためにＡＰによってＵＴに送信される。
【表７】
2010200363.tif 000009
【０１８６】
表８に描かれているハードウェアＩＤ要求メッセージは、ＵＴからハードウェアＩＤを得るためにＡＰによって送信される。
【表８】
2010200363.tif 000010
【０１８７】
表９に描かれているハードウェアＩＤ要求肯定応答メッセージは、ハードウェアＩＤ要求メッセージに応えてＵＴによって送信され、ＵＴの４８ビットのハードウェアＩＤを含む（特に、ＵＴの４８ビットのＩＥＥＥ ＭＡＣアドレスが使用されてよい）。
【表９】
2010200363.tif 000011
【０１８８】
表１０に描かれているシステム機能メッセージは、ＵＴにＡＰ機能を示すために新規に登録されたＵＴに送信される。
【表１０】
2010200363.tif 000012
【０１８９】
表１１に描かれているシステム機能肯定応答メッセージは、ＡＰにＵＴの機能を示すためにシステム機能メッセージに応えてＵＴによって送信される。
【表１１】
2010200363.tif 000013
【０１９０】
１つのラジオ資源制御ＲＲＣインスタンスは各ＵＴで初期化される。アクティブなＵＴごとの１つのＲＲＣインスタンスがＡＰで初期化される。ＡＰとＵＴでのＲＲＣ関数は（必要に応じて）順方向リンクチャネル測定値と逆方向リンクチャネル測定値を共用してよい。ＲＲＣは、ＡＰとＵＴでの送信チェーンと受信チェーンの校正を管理する。この例では、校正は空間多重化伝送モードに有効である。
【０１９１】
ＲＲＣはＵＴへの伝送のための伝送モードと速度制御を決定し、ＭＡＣスケジューラにそれを提供する。ＲＲＣは、Ｒ−ＴＣＨで、及び（必要な場合）Ｆ−ＴＣＨで物理層（ＰＨＹ）バースト伝送で必要とされる専用ＭＩＭＯパイロットの周期性と長さを決定する。ＲＲＣは、ＵＴへの及びＵＴからの空間時間送信ダイバーシティ（ＳＴＴＤ）モードでの伝送のために電力制御を管理し、それをＰＨＹマネージャに提供する。ＲＲＣはＵＴからＲ−ＴＣＨ伝送のためのタイミング調整を決定する。
【０１９２】
表１２に描かれている校正要求メッセージはＵＴとの校正を要求するためにＡＰによって送信される。ＣａｌＴｙｐｅフィールドは、校正手順に使用される校正トーンのセットとアンテナあたりの校正シンボルの数を示す。
【表１２】
2010200363.tif 000014
【０１９３】
校正タイプ（ＣａｌＴｙｐｅ）値は表１３に示されている。各校正タイプは校正に必要とされるＯＦＤＭトーンのセットとアンテナあたりの校正シンボルの数に対応する。校正パイロットシンボルは、Ｔｘアンテナ全体での直交性を確立するためにウォルシュシーケンスを使用する。
【表１３】
2010200363.tif 000015
【０１９４】
表１４に描かれている校正要求拒絶メッセージは、ＡＰからの校正要求を拒絶するためにＵＴによって送信される。
【表１４】
2010200363.tif 000016
【０１９５】
表１５に描かれている校正測定要求は、ＵＴによってＡＰに送信される。それはＵＴとＡＰの間のチャネルを測定するためにＡＰによって使用される校正パイロットシンボルを含む。
【表１５】
2010200363.tif 000017
【０１９６】
表１６に描かれている校正測定結果メッセージは、校正要求メッセージの中でＵＴによって送信された校正シンボルに関してＡＰによって完了されたチャネル測定の結果を、ＵＴに提供するためにＡＰによって送信される。
【０１９７】
この例では、各校正測定結果メッセージは４×４チャネルの４トーンのチャネル応答値、２×４チャネルの場合最高８トーン、または１×４チャネルの場合最高１６トーンを搬送する。５２トーンが測定された４×４チャネルのためのすべての測定データを搬送するには最高１３のこのようなメッセージが必要とされるため、シーケンス番号もこのようなメッセージのシーケンスを追跡調査するために利用される。データフィールド全体を充填するほど十分なデータがないケースでは、データフィールドの未使用の部分がすべてゼロに設定される。
【表１６】
2010200363.tif 000018
【０１９８】
表１７に描かれている校正測定結果肯定応答メッセージは、校正測定結果メッセージのフラグメントを肯定応答するために送信される。
【表１７】
2010200363.tif 000019
【０１９９】
同様に、校正測定結果メッセージは肯定応答されないことがあり、そのケースでは表１８に示されている校正測定結果ＮＡＣＫメッセージが、校正測定結果メッセージのフラグメントを否定的に肯定応答（ＮＡＣＫ）するために逆方向リンクで送信されてよい。
【表１８】
2010200363.tif 000020
【０２００】
校正測定結果メッセージは、ｇｏ−ｂａｃｋ−Ｎベースで、あるいは選択−繰り返しベースのどちらかでＮＡＣＫできる。ＳＥＱフィールドは、それぞれがメッセージシーケンス番号を表す４個の連続４ビットセグメントからなる。ｇｏ−ｂａｃｋ−Ｎモードの場合、モードビットは０に設定され、ＳＥＱフィールドの第１のセグメントが、繰り返される必要があるシーケンスの第１のメッセージのシーケンス番号を示す。このケースでは、ＳＥＱフィールドの残りの１２ビットはゼロに設定され、無視される。選択−繰り返しモードでは、モードビットは１に設定され、ＳＥＱフィールドは、繰り返される必要がある最高４つのメッセージのシーケンス数にも当てはまる。繰り返しされる必要のあるメッセージが４未満である場合、非ゼロ値を含むセグメントだけが意味を持つ。あらゆるゼロセグメントは無視される。
【０２０１】
表１９に描かれているＵＴリンクステータスメッセージは、ＵＴにフィードバックを提供するように要求するためにＡＰによって送信される。この例では、ＵＴはリンク品質（ＭＩＭＯと制御チャネルについて持続できる順方向リンクレート）だけではなくバッファステータス（バックログされたデータの量とＱｏＳクラス）に関するフィードバックを提供しなければならない。
【表１９】
2010200363.tif 000021
【０２０２】
ＵＴ＿ＢＵＦ＿ＳＴＡＴは、４バイト増分のＵＴラジオリンクバッファのサイズを示す。０×ＦＦＦＦの値は２６２，１４０バイト以上のバッファサイズを示す。ＦＬ＿ＲＡＴＥ＿ＳＴＡＴは、モードあたり４ビットで、モードあたりの最大順方向リンク速度を示す。ダイバーシティモードの場合、４個の最上位ビットだけが使用される。残りの１２ビットは０に設定される。ＱＯＳ＿ＦＬＡＧは、ＲＬバッファが高優先順位データを含んでいるかどうかを示す。ＱＯＳ＿ＦＬＡＧ値は表２０に定められている。
【表２０】
2010200363.tif 000022
【０２０３】
ＵＴでは、ＵＴリンクステータスメッセージがＲＲＣによって作成される。ＡＰでは、それは、ＵＴプロキシに値を提供するＲＲＣに転送される。
【０２０４】
本項に説明されている例のＲＲＣ実施形態は、本明細書全体で詳説される実施形態とともに展開されてよい。当業者は、この例の実施形態が図解としてだけ役立ち、ここでの教示に鑑みて無数の代替実施形態が明らかになることを認識するであろう。以下の項では、ここに詳説されている多様な実施形態とともに配備に適している制御チャネルの例の実施形態が説明されている。
【０２０５】
例の制御チャネル（ＣＣＨ）
前述されたように、資源のＭＡＣフレームと割り当てに対するアクセスは、スケジューラからの命令に基づいてＦ−ＴＣＨとＲ−ＴＣＨ上でＭＡＣ ＩＤに資源を割り当てる制御チャネル（ＣＣＨ）で制御される。これらの資源許可は特定のＭＡＣ ＩＤと関連付けられているＡＰでの１つまたは複数の待ち行列の公知の状態、あるいはそれぞれのＵＴプロキシ内の情報によって反射されるようにＭＡＣ ＩＤと関連付けられているＵＴで１つまたは複数の待ち行列の公知の状態に対する応答であってよい。資源許可もアクセス要求チャネル（ＡＲＣＨ）で受信されるアクセス要求に対する応答、またはスケジューラが使用可能な何らかの他の刺激または情報である可能性がある。ＣＣＨの例の実施形態は以下に詳説される。この例のＣＣＨは前述されたように高性能ＷＬＡＮで配備されてよい多様な制御機構の説明図としての役割を果たす。代替実施形態は後述される関数の部分集合だけではなく追加の機能性も含んでよい。後述されるフィールド名、フィールド幅、パラメータ値等は例示的に過ぎない。当業者は、本発明の範囲内の無数の代替実施態様に説明される原則に容易に適応するであろう。
【０２０６】
例のＣＣＨは、それぞれが表２１に示されるように異なったデータレートで動作する４つの別々のサブチャネルから構成されている。表２１で使用されている用語は技術で周知である（やはり周知であるように（ＳＮＲ）は信号対雑音比の略語であり、ＦＥＲは順方向誤り率の略語である）。ＣＣＨは、ＳＴＴＤと組み合わされて短いＯＦＤＭシンボルを使用する。これは論理チャネルのそれぞれが偶数の短いＯＦＤＭシンボルから構成されていることを暗示している。ランダムアクセスフィードバックチャネル（ＲＦＣＨ）とフレーム制御チャネル（ＦＣＣＨ）で送信されるメッセージは、情報要素（ＩＥ）にフォーマットされ、ＣＣＨサブチャネルの１つで送信される。
【表２１】
2010200363.tif 000023
【０２０７】
ＢＣＣＨはＣＣＨ＿ＭＡＳＫパラメータの中での既定のＣＣＨサブチャネルの存在または不在を示す。各ＣＣＨサブチャネル（Ｎはサブチャネル接尾辞０から３を示す）のフォーマットは以下の表２２に示されている。フォーマットは、ＩＥの数を示すフィールド、ＩＥ自体、ＣＲＣ、必要な場合ゼロパディング、及びテールビットを示すフィールドを備える。ＡＰは、ＩＥごとにどのサブチャネルを使用するのかに関する決定を下す。ユーザ端末（ＵＴ）に特定であるＩＥタイプは、そのＵＴのための伝送効率を最大限にするＣＣＨサブチャネルで送信される。ＡＰが既定のＵＴと関連付けられた速度を正確に決定できない場合、ＣＣＨ＿０が使用されてよい。放送／マルチキャストＩＥタイプはＣＣＨ＿０で送信される。
【表２２】
2010200363.tif 000024
【０２０８】
ＣＣＨは最低速度から最高速度の順に送信される。ＣＲＣはＣＣＨサブチャネルごとに提供される。すべてのＵＴは最低速度ＣＣＨで開始する各送信済みＣＣＨの復調を試みる。ＣＣＨ＿Ｎを正しく復号できないと、さらに速い速度のＣＣＨが誤って復号されることが暗示される。各ＣＣＨサブチャネルは最高３２個のＩＥを送信できる。
【０２０９】
ＣＣＨトランスポートチャネルは２つの論理チャネルにマッピングされる。ＲＦＣＨは、ＲＣＨで受信されるアクセス試行に対する肯定応答を備える。ＦＣＣＨは資源割り当て（つまり、Ｆ−ＴＣＨとＲ−ＴＣＨでの物理層フレーム割り当て）、Ｆ−ＴＣＨとＲ−ＴＣＨでの物理層データレート制御を含む物理層制御関数、Ｒ−ＴＣＨ専用パイロット挿入、Ｒ−ＴＣＨタイミング及びＲ−ＴＣＨ電力制御を備える。ＦＣＣＨは、ＵＴからバッファとリンクのステータス更新を要求するためにＲ−ＴＣＨ割り当ても備える。
【０２１０】
一般的には、この実施形態では、ＣＣＨで送信される情報はタイムクリティカルであり、カレントＭＡＣフレーム内で受け取り人により利用される。
【０２１１】
表２３は、そのそれぞれのタイプの値とともにＣＣＨ情報要素タイプを一覧表示する。情報要素フォーマットは以下にさらに詳説される。次の表では、すべてのオフセット値は８００ナノ秒という単位で示されている。
【表２３】
2010200363.tif 000025
【０２１２】
（表２３ではＲｅｇｉｓｔｒａｔｉｏｎＲｅｑＡＣＫ（登録要求ACK）と呼ばれている）登録要求肯定応答ＩＥ（ＲＦＣＨ）のフォーマットは表２４に示されている。登録要求肯定応答は、ＲＣＨで受信されるＵＴから登録要求に応えるために使用される。該フォーマットは、ＩＥタイプ、スロットＩＤ、ＵＴによって選択され、その登録要求に含まれたアクセスＩＤ、ＵＴに割り当てられているＭＡＣ ＩＤ及びタイミング前進値を含む。
【表２４】
2010200363.tif 000026
【０２１３】
（表２３ではＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎ（順方向ダイバーシテイモード割り当て）と呼ばれている）Ｆ−ＴＣＨダイバーシティモード割り当てＩＥ（ＦＣＣＨ）のフォーマットは表２５に示されている。Ｆ−ＴＣＨダイバーシティモード割り当ては、ＭＡＣ ＰＤＵがダイバーシティモードを使用してＦ−ＴＣＨで送信されることを示すために使用される。ダイバーシティはＳＴＴＤを含む別の期間（ｔｅｒｍ）である。フォーマットはＩＥタイプ、ＭＡＣ ＩＤ、ＭＡＣフレーム内のＭＡＣ ＰＤＵの場所を識別するＦ−ＴＣＨオフセット、使用されている速度、パケットの中のＯＦＤＭシンボル数、プリアンブルタイプ（以下にさらに詳説される）、及びパケットの中の短いＯＦＤＭシンボルの数を含む。
【表２５】
2010200363.tif 000027
【０２１４】
（表２３ではＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎＳｔａｔ（順方向ダイバーシテイモード割り当てステータス）と呼ばれている）Ｒ−ＴＣＨステータスＩＥ（ＦＣＣＨ）付きのＦ−ＴＣＨダイバーシティモード割り当てのフォーマットは表２６に示されている。このＩＥは、ＭＡＣ ＰＤＵがダイバーシティモードを使用してＦ−ＴＣＨで送信されることを示し、ステータス要求に応じるようにＲ−ＴＣＨで空間を割り当てるために使用される。フォーマットはＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎのフィールドを含む。さらに、それはＵＴがＲ−ＴＣＨでのそのバッファステータスを報告するために割り当てオフセットを含む。Ｒ−ＴＣＨでのリンクステータスメッセージの割り当ては、Ｒ−ＴＣＨプリアンブルタイプ及び速度、タイミング調整、ステータスメッセージ要求ビット及びリンクステータスパケットの中の長いＯＦＤＭシンボルと短いＯＦＤＭシンボルの数を含む逆方向のパラメータを指定する。
【表２６】
2010200363.tif 000028
【０２１５】
ＦＷＤ＿ＰＲＥＡＭＢＬＥフィールドとＲＥＶ＿ＰＲＥＡＭＢＬＥフィールドは、順方向リンクで使用されるプリアンブルの長さ、及び逆方向リンクで送信されるステータスメッセージをそれぞれ示す。プリアンブルは、主要な固有モードだけのために導かれる（ｓｔｅｅｒｅｄ）基準を搬送する表２７に示される短いＯＦＤＭシンボルの数からなる。
【表２７】
2010200363.tif 000029
【０２１６】
（表２３ではＦｗｄＳｐａＭｏｄｅＡｓｓｉｇｎ（順方向空間モード割り当て）と呼ばれている）Ｆ−ＴＣＨ空間多重化モード割り当てＩＥ（ＦＣＣＨ）のフォーマットは表２８が示されている。このＩＥのためのフィールドは、ダイバーシティの代わりに空間多重化が使用される点を除き、ＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎのためのフィールドに類似している。
【表２８】
2010200363.tif 000030
【０２１７】
（表２３ではＦｗｄＳｐａＭｏｄｅＡｓｓｉｇｎＳｔａｔ（順方向空間モード割り当てステータス）と呼ばれている）Ｒ−ＴＣＨステータスＩＥ（ＦＣＣＨ）付きのＦ−ＴＣＨ空間多重化モード割り当てのフォーマットが表２９に示されている。このＩＥのためのフィールドは、ダイバーシティの代わりに空間多重化が使用される点を除き、ＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎＳｔａｔのためのフィールドに類似している。
【表２９】
2010200363.tif 000031
【０２１８】
（表２３ではＲｅｖＤｉｖＭｏｄｅＡｓｓｉｇｎ（逆方向ダイバーシテイモード割り当て）と呼ばれている）Ｒ−ＴＣＨダイバーシティモード割り当てＩＥ（ＦＣＣＨ）のフォーマットが表３０に示されている。このＩＥは、ＭＡＣ ＰＤＵに対するＲ−ＴＣＨの割り当てをダイバーシティモードを使用して信号で知らせるために使用される。このＩＥは前記のようにタイプとＭＡＣ ＩＤフィールドを含む。それは前述されたようなステータス要求メッセージに含まれている逆方向リンクフィールド（ＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎＳｔａｔとＦｗｄＳｐａＭｏｄｅＡｓｓｉｇｎＳｔａｔ）も含む。それはさらに逆方向送信電力調整フィールドをさらに備える。
【表３０】
2010200363.tif 000032
【０２１９】
（表２３ではＲｅｖＳｐａＭｏｄｅＡｓｓｉｇｎ（逆方向空間モード割り当て）と呼ばれている）Ｒ−ＴＣＨ空間多重化モード割り当てＩＥ（ＦＣＣＨ）のフォーマットが表３１に示されている。このＩＥのフィールドは、ダイバーシティの代わりに空間多重化が使用される点を除きＲｅｖＤｉｖＭｏｄｅＡｓｓｉｇｎのためのフィールドに類似している。
【表３１】
2010200363.tif 000033
【０２２０】
（表２３ではＤｉｖＭｏｄｅＡｓｓｉｇｎ（ダイバーシテイモード割り当て）と呼ばれている）ＴＣＨ分割モード割り当てＩＥ（ＦＣＣＨ）のフォーマットが図３２に示されている。このＩＥは順方向リンクと逆方向リンクＭＡＣ ＰＤＣを割り当てるために使用される。このＩＥのためのフィールドはＦｗｄＤｉｖＭｏｄｅＡｓｓｉｇｎとＲｅｖＤｉｖＭｏｄｅＡｓｓｉｇｎのためのフィールドの組み合わせである。
【表３２】
2010200363.tif 000034
【０２２１】
（表２３でＳｐａＭｏｄｅＡｓｓｉｇｎ（空間モード割り当て）と呼ばれている）ＴＣＨ空間Ｍｕｘモード割り当てＩＥのフォーマットが表３３に示されている。このＩＥはダイバーシティの代わりに空間多重化が使用される点を除きＤｉｖＭｏｄｅＡｓｓｉｇｎに類似している。
【表３３】
2010200363.tif 000035
【０２２２】
（表２３でＬｉｎｋＳｔａｔｕｓＲｅｑ（リンクステータス要求）と呼ばれている）バッファ及びリンクステータス要求ＩＥ（ＲＦＣＨまたはＦＣＣＨ）のフォーマットが表３４に示されている。このＩＥはＵＴからカレントバッファステータス及びそのＵＴでの物理リンクの現在の状態を要求するためにＡＰによって使用される。逆方向リンク割り当ては、応答を提供するようにという要求とともに行われる。タイプフィールドとＭＡＣ ＩＤフィールドに加えて、前述された逆方向リンク割り当てと同様に逆方向リンク割り当てフィールドが含まれている。
【表３４】
2010200363.tif 000036
【０２２３】
（表２３でＣａｌＲｅｑｕｅｓｔＡｃｋ（校正要求Ack）と呼ばれている）校正要求肯定応答ＩＥ（ＦＣＣＨ）のフォーマットが表３５に示されている。このＩＥは校正に対するＵＴ要求を肯定応答するために送信される。校正は、通常、登録の直後に実行され、それ以後ときには実行されてよい。ＴＤＤ無線チャネルは対称的であるが、ＡＴとＵＴでの送信チェーンと受信チェーンは同等ではない利得と位相を有する可能性がある。校正はこの非対称性を排除するために実行される。このＩＥはタイプフィールド、（ＵＴに割り当てられる仮のＭＡＣ ＩＤを含む）ＭＡＣ ＩＤフィールド、ＵＴアンテナ数、及び要求されている校正タイプの肯定応答を含む。４ビットの校正タイプフィールドは、校正のために使用されるトーンの組み合わせ及び校正のために送信されるトレーニングシンボルの数を指定する。
【表３５】
2010200363.tif 000037
【０２２４】
（表２３でＣａｌＲｅｑｕｅｓｔＲｅｊ（校正要求拒絶）と呼ばれている）校正要求拒絶ＩＥ（ＦＣＣＨ）のフォーマットが表３６に示されている。このＩＥはＵＴからの校正要求を拒絶する。このＩＥは、ＣａｌＲｅｑｕｅｓｔＡｃｋの場合と同様にタイプフィールド、ＭＡＣ ＩＤフィールド、及び校正要求タイプフィールドを含む。さらに、校正要求がなぜ拒絶されるのかを指定するために理由フィールドが提供される。
【表３６】
2010200363.tif 000038
【０２２５】
校正要求の理由は理由値により参照される。理由とその値は表３７に詳説されている。
【表３７】
2010200363.tif 000039
【０２２６】
要求メッセージ（ＡＲＣＨ）のフォーマットは表３８に示されている。初期アクセス時、要求メッセージは登録要求として処理される。アクセス側ＵＴは、初期アクセスのために取り除けられ、ＢＣＣＨメッセージで公表されていたＩＤのセットから無作為にアクセスＩＤを選ぶ。要求メッセージが連続して受信されると、ＡＰはＲＦＣＨで登録要求肯定応答ＩＥを使用して、ＵＴに仮のＭＡＣ ＩＤを割り当ててそれを肯定応答する。
【０２２７】
登録されたＵＴは、ＡＲＣＨで同じメッセージを使用するが、サービスを要求するために、その割り当てられたＭＡＣ ＩＤをアクセスＩＤフィールドで使用する。要求メッセージが連続して受信される場合、ＡＰはＵＴにより所望される割り当てのタイプとサイズに関する情報を取得するためにＲ−ＴＣＨリンクステータス要求ＩＥを送信する。
【表３８】
2010200363.tif 000040
【０２２８】
当業者は、情報と信号が種々の異なる技術と技法のどれかを使用して表現されてよいことを理解するであろう。例えば、前記説明全体で参照される可能性があるデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは電圧、電流、電磁波、磁場または磁性粒子、光学場または光学粒子あるいはその任意の組み合わせにより表現されてよい。
【０２２９】
当業者は、ここに開示されている実施形態に関連して説明されている多様な例示的な論理ブロック、モジュール、回路及びアルゴリズムステップが電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせによって実現されることを認識するであろう。ハードウェアとソフトウェアのこの互換性を明確に説明するために、多様な構成要素、ブロック、モジュール、回路及びステップが概してそれらの機能性という点で前述された。このような機能性がハードウェアとして実現されるのか、あるいはソフトウェアとして実現されるのかは特定の応用例と全体的なシステムに課される設計の制約に依存している。当業者は、特定の応用例ごとに変化する方法で該説明された機能性を実現してよいが、このような実現の決定は本発明の範囲からの逸脱を引き起こすとして解釈されるべきではない。
【０２３０】
ここに開示されている実施形態と関連して説明されている多様な例示的な論理ブロック、モジュール及び回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブルロジックデバイス、離散ゲートまたはトランジスタ論理、離散ハードウェア構成要素、あるいはここに説明された機能を実行するように設計されたその任意の組み合わせを用いて実現または実行されてよい。汎用プロセッサはマイクロプロセッサであってよいが、代替策では、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラまたは状態機械であってよい。プロセッサは、例えばＤＳＰとマイクロプロセッサの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアとともの１台または複数のマイクロプロセッサ等の計算装置の組み合わせ、あるいは任意の他のこのような構成として実現されてもよい。
【０２３１】
ここに開示されている実施形態とともに説明されている方法またはアルゴリズムのステップは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、あるいは該２つの組み合わせでじかに具現化されてよい。ソフトウェアモジュールはＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭまたは技術で公知の他の形式の記憶媒体に常駐してよい。例示的な記憶媒体は、プロセッサが該記憶媒体から情報を読み取り、該記憶媒体に情報を書き込むことができるようにプロセッサに結合されている。代替策では、記憶媒体はプロセッサに一体化してよい。プロセッサと記憶媒体はＡＳＩＣに常駐してよい。ＡＳＩＣはユーザ端末に常駐してよい。代替策では、プロセッサと記憶媒体はユーザ端末内にディスクレートコンポーネントとして存在してよい。
【０２３２】
見出しは参考のために、及び多様なセクションの位置を突き止める際に役立てるためにここに含まれている。見出しはそれに関して説明されている概念の範囲を制限することを目的としていない。このような概念は明細書全体を通して適用性があってよい。
【０２３３】
開示されている実施形態の前記説明は、当業者が本発明を作るあるいは使用することができるようにするために提供される。これらの実施形態に対する多様な修正は、当業者にとって容易に明らかになり、ここに定義されている一般的な原則は本発明の精神または範囲から逸脱することなく他の実施形態に適用されてよい。したがって、本発明はここに示されている実施形態に制限されることを目的とするのではなく、ここに開示されている原則と新規特徴と一貫した最も広い範囲を与えられるべきである。
【図面の簡単な説明】
【０２３４】
【図１】高速ＷＬＡＮを含むシステムの例の実施形態である。
【図２】アクセスポイントまたはユーザ端末として構成されてよい無線通信装置の例の実施形態を描く図である。
【図３】例のサブネットワークプロトコルスタックを描く図である。
【図４】プロトコルスタックの層を横断する際のユーザデータパケットを示す図である。
【図５】例のＭＡＣフレームを示す図である。
【図６】順方向リンクメッセージ転送を送信するための例の方法を描く図である。
【図７】順方向リンクメッセージ転送を受信するための例の方法を描く図である。
【図８】逆方向リンクメッセージ転送を送信するための例の方法を描く図である。
【図９】逆方向リンクメッセージ転送を受信するための例の方法を描く図である。
【図１０】初期アクセスと登録をＵＴで実行するための例の方法を描く図である。
【図１１】初期アクセスと登録をＡＰで実行するための例の方法を描く図である。
【図１２】ＡＰでユーザデータフローのための例の方法１２００を描く図である。
【図１３】ＵＴでユーザデータフローのための例の方法１３００を描く図である。
【図１４】物理層フィードバックを適応層機能に組み込むための例の方法を描く図である。
【図１５】適応層マルチキャストを実行するための例の方法を描く図である。
【図１６】適応層マルチキャストを使用するのか、それともＭＡＣ層マルチキャストを使用するのかを決定するための例の方法を示す図である。
【図１７】物理層フィードバックに応じてセグメンテーションを実行するための例の方法を描く図である。
【図１８】伝送速度に応じてセグメントに分けることを示す図である。
【図１９】単一のＭＡＣフレームで複数のフローとコマンドを送信するための例の方法を描く図である。
【図２０】多様な部分的なＭＵＸ ＰＤＵｓを送信する例を含む順次ＭＡＣフレームを示す図である。
【図２１】ＭＵＸポインタを使用してＭＡＣフレームを作成するための例の方法を示す図である。
【図２２】ＭＵＸポインタを備えるＭＡＣフレームを受信するための例の方法を示す図である。
【図２３】例のＭＵＸ ＰＤＵフォーマットを示す図である。
【図２４】イーサネット適応のために構成される例のシステムを示す図である。
【図２５】ＩＰ適応のために構成される例のシステムを示す図である。
【図２６】例のイーサネットプロトコルスタックを示す図である。
【図２７】例のＩＰプロトコルパケットを示す図である。
【符号の説明】
【０２３５】
１００  システム、１０２  ネットワーク、１０４  アクセスポイント、１０６Ａ, １０６Ｎ  ユーザ端末、２１０  トランシーバ、２２０  ＭＡＣプロセッサ、２４０  無線ＬＡＮトランシーバ、２５５  メモリ、２６０  フロー、３００  サブネットワークプロトコルスタック、３１０  適応層、３１２  セグメンテーション及びリアセンブリ、３１４  フロー分類、３１６  マルチキャストマッピング、３２０  データリンク制御層、３３０  論理リンク（ＬＬ）、３３２  トランスペアレント放送／マルチキャスト／ユニキャスト、３３４  未応答、３３６  肯定応答済み、３３８  論理リンク制御、３４０  ラジオリンク制御（ＲＬＣ）、３４２  ラジオ資源制御（ＲＲＣ）、３４４  関連制御（ＡＣ）、３４６  システム識別制御、３５０  システム構成制御、３６２  高サービスの質待ち行列、３６４  最善努力待ち行列、３６６  制御メッセージ待ち行列、３７０  共通ＭＡＣ、３７２  ＭＡＣフレーミング、３７４  制御チャネル、３７６  スケジューラ、３７８  アクセス制御、３８２  サービスの質マネージャ、３８０  層マネージャ、３８４  流入制御、３８６  ＰＨＹマネージャ、４１０  ＩＰデータグラム／イーサネットセグメント、
【図１】
2010200363.tif 000041
【図２】
2010200363.tif 000042
【図３】
2010200363.tif 000043
【図４】
2010200363.tif 000044
【図５】
2010200363.tif 000045
【図６】
2010200363.tif 000046
【図７】
2010200363.tif 000047
【図８】
2010200363.tif 000048
【図９】
2010200363.tif 000049
【図１０】
2010200363.tif 000050
【図１１】
2010200363.tif 000051
【図１２】
2010200363.tif 000052
【図１３】
2010200363.tif 000053
【図１４】
2010200363.tif 000054
【図１５】
2010200363.tif 000055
【図１６】
2010200363.tif 000056
【図１７】
2010200363.tif 000057
【図１８】
2010200363.tif 000058
【図１９】
2010200363.tif 000059
【図２０】
2010200363.tif 000060
【図２１】
2010200363.tif 000061
【図２２】
2010200363.tif 000062
【図２３】
2010200363.tif 000063
【図２４】
2010200363.tif 000064
【図２５】
2010200363.tif 000065
【図２６】
2010200363.tif 000066
【図２７】
2010200363.tif 000067
【手続補正書】
【提出日】平成22年6月7日(2010.6.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
各々が１個または複数のパケットを備える１つまたは複数のフローを受信し、前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成するための、第１の層と、
各ＭＡＣフレームが、１つまたは複数の媒体割り当てを送信するための制御チャネルと、
各々が媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備え、前記１つまたは複数のＭＡＣ層ＰＤＵｓに基づいて１つまたは複数のＭＡＣフレームを生成するための、第２の層と、
を具備する装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０２３３
【補正方法】変更
【補正の内容】
【０２３３】
開示されている実施形態の前記説明は、当業者が本発明を作るあるいは使用することができるようにするために提供される。これらの実施形態に対する多様な修正は、当業者にとって容易に明らかになり、ここに定義されている一般的な原則は本発明の精神または範囲から逸脱することなく他の実施形態に適用されてよい。したがって、本発明はここに示されている実施形態に制限されることを目的とするのではなく、ここに開示されている原則と新規特徴と一貫した最も広い範囲を与えられるべきである。
＜付記＞  
［出願当初の特許請求の範囲］
［請求項１］
各々が１個または複数のパケットを備える１つまたは複数のフローを受信し、前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成するための、第１の層と、
各ＭＡＣフレームが、１つまたは複数の媒体割り当てを送信するための制御チャネルと、
各々が媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備え、前記１つまたは複数のＭＡＣ層ＰＤＵｓに基づいて１つまたは複数のＭＡＣフレームを生成するための、第２の層と、
を具備する装置。
［請求項２］
記ＭＡＣフレームは、前記ＭＡＣフレームのパラメータを送信するための放送チャネルをさらに具備する請求項１記載の装置。
［請求項３］
前記ＭＡＣフレームは、ＭＡＣフレーム境界を示すビーコンをさらに具備する請求項１記載の装置。
［請求項４］
前記制御チャネルは複数のサブチャネルを備え、前記サブチャネルの各々が１つまたは複数の割り当てを備え、各サブチャネルが複数の伝送フォーマットの１つで送信される請求項１記載の装置。
［請求項５］
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の順方向トラフィックセグメントを具備する請求項１記載の装置。
［請求項６］
前記１つまたは複数の順方向トラフィックセグメントは、第１の装置から第２の装置へＭＡＣ ＰＤＵの伝送を備える請求項５記載の装置。
［請求項７］
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の逆方向トラフィックセグメントを具備する請求項１記載の装置。
［請求項８］
前記１つまたは複数の逆方向トラフィックセグメントは、第２の装置から第１の装置へＭＡＣ ＰＤＵの伝送を備える請求項７記載の装置。
［請求項９］
前記１つまたは複数のトラフィックセグメントは、１つまたは複数のピアーピアトラフィックセグメントを具備する請求項１記載の装置。
［請求項１０］
前記１つまたは複数のピアーピアトラフィックセグメントは、特定の伝送を備える請求項９記載の装置。
［請求項１１］
前記１つまたは複数のピアーピアトラフィックセグメントは、予定された伝送を備える請求項９記載の装置。
［請求項１２］
前記１つまたは複数のトラフィックセグメントは、１つまたは複数の競合をベースにしたトラフィックセグメントを備える請求項１記載の装置。
［請求項１３］
前記１つまたは複数のトラフィックセグメントは、１つまたは複数のランダムアクセストラフィックセグメントを備える請求項１記載の装置。
［請求項１４］
前記第１の層は、適応層ＰＤＵを生成するための適応層を備える請求項１記載の装置。
［請求項１５］
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのセグメンテーションを実行する請求項１４記載の装置。
［請求項１６］
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのリアセンブリを実行する請求項１４記載の装置。
［請求項１７］
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのフロー分類を実行する請求項１４記載の装置。
［請求項１８］
前記フロー分類は、サービスの質（ＱｏＳ）に従って実行される請求項１７記載の装置。
［請求項１９］
前記適応層は、前記１つまたは複数のフローから１個または複数のパケットのためのマルチキャストマッピングを実行する請求項１４記載の装置。
［請求項２０］
前記ＭＡＣ層は、前記適応層ＰＤＵからデータリンク層ＰＤＵを生成するためのデータリンク層を備える請求項１４記載の装置。
［請求項２１］
前記ＭＡＣ層は、ＭＡＣ層ＰＤＵを形成するために１つまたは複数のフローに対応する１つまたは複数のデータリンク層ＰＤＵを統合する共通のＭＡＣ層を備える請求項２０記載の装置。
［請求項２２］
第１の層で各々が１個または複数のパケットを備える１つまたは複数のフローを受信し、
前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成し、
１つまたは複数の媒体割り当てを送信するための制御チャネルと、媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備えるＭＡＣフレームを形成する
ことを具備する方法。
［請求項２３］
媒体割り当てに従ってトラフィックセグメントでＭＡＣ層ＰＤＵを送信することをさらに備える請求項２２記載の方法。
［請求項２４］
媒体割り当てに従ってトラフィックセグメントでＭＡＣ層ＰＤＵを受信することをさらに備える請求項２２記載の方法。
［請求項２５］
前記制御チャネルを送信することをさらに備える請求項２２記載の方法。
［請求項２６］
前記制御チャネルは複数のサブチャネルを備え、前記サブチャネルの各々が１つまたは複数の割り当てを備え、各サブチャネルが複数の伝送フォーマットの１つで送信される請求項２５記載の方法。
［請求項２７］
前記１つまたは複数のフローからの１個または複数のパケットから適応層ＰＤＵｓを生成するために、適応層処理を実行することをさらに備える、請求項２２記載の方法。
［請求項２８］
前記適応層ＰＤＵｓからデータリンク層ＰＤＵｓを生成するためにデータリンク層処理を実行することをさらに備える請求項２７記載の方法。
［請求項２９］
ＭＡＣ層ＰＤＵを形成するために、１つまたは複数の適応層ＰＤＵｓを統合するために共通のＭＡＣ処理を実行することをさらに備える請求項２７記載の方法。
［請求項３０］
順方向トラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
［請求項３１］
逆方向トラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
［請求項３２］
ピアーピアトラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
［請求項３３］
ランダムアクセストラフィックセグメントを送信することをさらに備える請求項２２記載の方法。
［請求項３４］
各フローが１個または複数のパケットを備え、前記１つまたは複数のフローからの１個または複数のパケットから１つまたは複数のＭＡＣ層ＰＤＵｓを生成する、前記１つまたは複数のフローを受信するための手段と、
１つまたは複数のＭＡＣ層ＰＤＵｓに基づいてＭＡＣフレームを生成するための手段とを具備し、
前記ＭＡＣフレームは、１つまたは複数の媒体割り当てを送信するための制御チャネルと、それぞれが媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵ）を送信するための、１つまたは複数のトラフィックセグメントとを備える、
装置。
［請求項３５］
トラフィックセグメントでＭＡＣ層ＰＤＵを送信するための手段をさらに備える請求項３４記載の装置。
［請求項３６］
トラフィックセグメントでＭＡＣ層を受信するための手段をさらに備える請求項３４記載の装置。
［請求項３７］
各々が１個または複数のパケットを備える１つまたは複数のフローを第１の層で受信するステップと、
前記１つまたは複数のフローから前記１個または複数のパケットに基づいて１つまたは複数の媒体アクセス制御（ＭＡＣ）層プロトコルデータユニット（ＰＤＵｓ）を生成するステップと、
１つまたは複数の媒体割り当てを送信するための制御チャネルと、各々が媒体割り当てに従って１つまたは複数のＭＡＣ層プロトコルデータユニット（ＰＤＵｓ）を送信するための１つまたは複数のトラフィックセグメントとを備えるＭＡＣフレームを形成するステップと、
を実行するために動作可能なコンピュータ読み取り可能媒体。
【外国語明細書】
2010200363000001.pdf