縮小拡大可能なヘッダー拡張
ヘッダーフィールドを拡張するためのシステムおよび方法が示される。ヘッダーフィールドは、ヘッダーの現在のサイズを変更せずに拡張され得る。確保されるビットは、拡張ヘッダーの使用を示すために使用され得て、また、拡張ヘッダーは、フレームのペイロードあるいはパッドビットを含むフレーム内のさまざまな位置に格納され得る。
【発明の詳細な説明】
【技術分野】
【０００１】
米国特許法第１１９条の下での優先権主張
この特許出願は、２００９年３月３日に出願され、譲受人にこれについて譲渡された「ＰＳＤＵ内の縮小拡大可能なヘッダー拡張（ＳＣＡＬＡＢＬＥ ＨＥＡＤＥＲ ＥＸＴＥＮＳＩＯＮ ＷＩＴＨＩＮ ＰＳＤＵ）」とタイトルをつけられ、明らかに参照によってここに組み込まれる米国仮出願第６１／１５７，１２６号に対する優先権を主張する。
【０００２】
本出願は、一般的には無線通信に関係し、より具体的には、無線通信でのパケットヘッダーを拡張する方法およびシステムに関係する。
【背景技術】
【０００３】
無線通信システムは、複数のユーザにさまざまなタイプの通信（例えば、音声、データ、マルチメディアサービスなど）を供給するために広く展開される。高レートおよびマルチメディアのデータサービスの需要が急速に増大するとともに、向上させられた実行を備えた効率的で強健な通信システムをインプリメントするという挑戦がある。
【発明の概要】
【０００４】
実施例において、無線通信システムにおける少なくとも１つの第１のパケットを送信するための通信デバイスは提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを含む。通信デバイスは、第１の拡張ヘッダーを格納するように構成されたメモリを含む。デバイスは、さらに、メモリと通信し、また、少なくとも１ビットが送信のための第１の拡張ヘッダーにおいて利用可能かどうか決定するように構成されたたプロセッサを有する。１ビットは、ヘッダーフィールドを占める複数のビットに追加可能である。デバイスは、さらに、プロセッサおよびメモリと通信し、ヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示し、第１のパケットのペイロードフィールドおよびパッディングフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成されるメッセージフォーマッタを備える。
【０００５】
別の実施例において、無線通信システムにおける少なくとも１つの第１のパケットを送信するための通信デバイスが提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを備える。通信デバイスは、第１の拡張ヘッダーを格納するための手段を備える。デバイスは、さらに、少なくとも１ビットが送信のための第１の拡張ヘッダーにおいて利用可能かどうか決定するための手段を備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加可能であり、また、決定するための手段は、格納するための手段と通信状態にある。デバイスは、ヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示すための、および第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入するための手段をさらに備える。示すためのおよび挿入するための手段は、格納するための手段または決定するための手段と通信し得る。
【０００６】
別の実施例において、無線通信システムにおける少なくとも１つの第１のパケットを通信する方法が提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを備える。方法は、第１の拡張ヘッダーを格納すること、および少なくとも１ビットが送信用の第１の拡張ヘッダーにおいて利用可能かどうか決定することを備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加的である。方法は、第１のパケットのヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示し、第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入することをさらに備える。
【０００７】
別の実施例において、少なくとも１つのコンピュータ可読媒体を含むコンピュータ可読製品が提供される。少なくとも１ビットが送信用の第１の拡張ヘッダーにおいて利用可能な場合、コンピュータ可読製品は、コンピュータに少なくとも部分的に決定させるためのコードを備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加的である。コンピュータ可読製品は、さらに、コンピュータに第１のパケットのヘッダーフィールドにおける第１の拡張ヘッダーの存在を示させ、第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入させるためのコード（例えば、実行可能命令）を備える。
【図面の簡単な説明】
【０００８】
【図１Ａ】図１Ａは、第１の例の無線通信ネットワークを例示する。
【図１Ｂ】図１Ｂは、別の例の無線通信ネットワークを例示する。
【図２】図２は、図１Ａおよび図１Ｂの無線通信ネットワークで使用される例の無線通信デバイスの機能ブロック図である。
【図３】図３は、図１の無線通信ネットワークで使用される例のマクロノードの機能ブロック図である。
【図４】図４は、ＥＣＭＡ−３６８標準に対応する例のフレーム構造構成を例示する。
【図５】図５は、図４のフレーム構成のための物理層ビット割り当てを例示する。
【図６】図６は、実例となる実施例にしたがう例の拡張可能なヘッダー拡張構造である。
【図７】図７は、図６の拡張可能なヘッダー拡張構造に従った例の修正されるＥＣＭＡ−３６８フレーム構成を例示する。
【図８】図８は、第１の実施例に従う例の拡張されたＰＬＣＰヘッダー構造である。
【図９】図９は、図８の拡張されたＰＬＣＰヘッダー構造の拡張ヘッダー情報フィールドのための例のコーディングテーブルを例示する。
【図１０】図１０は、第２の実施例に従う例の拡張されたＰＬＣＰヘッダー構造である。
【図１１】図１１は、第３の実施例に従う拡張されたＰＬＣＰヘッダー構造である。
【図１２】図１２は、１つの実施例に従うＰＬＣＰヘッダーを拡張する方法である。
【詳細な説明】
【０００９】
「典型的である（ｅｘｅｍｐｌｙ）」という単語は、「例（ｅｘａｍｐｌｅ）、事例（ｉｎｓｔａｎｃｅ）、あるいは実例（ｉｌｌｕｓｔｒａｔｉｏｎ）として役立つ」ことを意味するためにここに使用される。「典型的である」とここに記載れたどんな実施例も、好まれるか、他の実施例上に有利として解釈されるべきでない。ここに記述された技術は、符号分割多重アクセス（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＣＤＭＡ）ネットワーク、時分割多元接続方式（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＴＤＭＡ）ネットワーク、周波数分割多重アクセス（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ ＦＤＭＡ：ＯＦＤＭＡ）ネットワーク、シングルキャリヤＦＤＭＡ（Ｓｉｎｇｌｅ−Ｃａｅｅｉｅｒ：ＳＣ−ＦＤＭＡ）ネットワークなどのような様々な無線通信ネットワークに使用され得る。「ネットワーク」および「システム」という用語は、しばしば交換的に使用される。ＣＤＭＡネットワークは、ユニバーサル・テレステアル・ラジオアクセス（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ：ＵＴＲＡ）、ＣＤＭＡ２０００などのようなラジオ技術をインプリメントし得る。ＵＴＲＡは広域ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−ＣＤＭＡ：Ｗ−ＣＤＭＡ）および低チップレート（Ｌｏｗ Ｃｈｉｐ Ｒａｔｅ：ＬＣＲ）を含む。ＣＤＭＡ２０００は、ＩＳ−２０００、ＩＳ−９５、およびＩＳ−８５６標準をカバーする。ＴＤＭＡネットワークは、モービル通信のためのグローバルシステム（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：ＧＳＭ（登録商標））のようなラジオ技術をインプリメントし得る。ＯＦＤＭＡネットワークは、発展型ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＴＲＡ：Ｅ−ＵＴＲＡ）、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、フラッシュ−ＯＦＤＭＡ：Ｆｌａｓｈ−ＯＦＤＭＡ）などのようなラジオ技術をインプリメントし得る。ＵＴＲＡ、Ｅ−ＵＴＲＡおよびＧＳＭ（登録商標）は、ユニバーサル・モバイル・テレコミュニケーションシステム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：ＵＭＴＳ）の一部である。ロングタームエボルーション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳの来たるリリースである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＧＳＭ（登録商標）、ＵＭＴＳおよびＬＴＥは「第３世代パートナーシッププロジェクト（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ」：３ＧＰＰ）という名の組織からの文献に記述されティル。ＣＤＭＡ２０００は、「第３世代パートナーシッププロジェクト２」（（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２：３ＧＰＰ２）という名の組織からも文献に記述されている。これらのさまざまなラジオ技術および標準は、当該技術において知られている。
【００１０】
単一のキャリア変調および周波数領域等化を利用するシングルキャリヤ周波数分割多重アクセス（Ｓｉｎｇｌｅ−Ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ：ＳＣ−ＦＤＭＡ）は、技術である。ＳＣ−ＦＤＭＡは、同様の実行、および本質的にＯＦＤＭＡシステムのものと同じ実行および本質的に同じ全面的な複雑さを有している。ＳＣ−ＦＤＭＡ信号は、その固有の単一のキャリア構造のために、より低いピーク対平均電力の比率（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ：ＰＡＰＲ）を持っている。ＳＣ−ＦＤＭＡは、より低いＰＡＰＲが送信電力効率の点からモバイル端末に非常に役立つアップリンク通信において特に大きな注意を引き寄せる。それは、現在、３ＧＰＰロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）、または、発展型ＵＴＲＡにおいてアップリンク多重アクセススキームのために作用する仮定である。
【００１１】
いくつかの態様において、ここでの示唆は、マクロ規模のカバー範囲（例えば、典型的には、マクロセルネットワークとして言われている第３世代（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ：３Ｇ）ネットワークのような大規模エリアセルラーネットワーク）およびより書規模なカバー範囲（住宅ベースまたはビルディングベースのネットワーク環境）を含むネットワークにおいて使用され得る。無線通信デバイスがそのようなネットワークを通って移動するとので、無線通信デバイスは、マクロのカバー範囲を提供するアクセスノードによってある一でサービスされ得る一方、無線通信デバイスは、より小規模のカバー範囲を提供するアクセスノードによって他の位置でサービスされ得る。いくつかの態様において、より小さなカバー範囲のノードは、増加する容量の増大、ビルディング内のカバー範囲、および異なるサービスを（例えばより多くの強固なユーザ経験のために）提供するために使用されてもよい。ここでの議論において、比較的広いエリアにわたるカバー範囲を提供するノードは、マクロノードと呼ばれ得る。
【００１２】
図１Ａは、第１の例の無線通信ネットワーク１００を例示する。例示される無線通信ネットワークは、マクロノード１０２、セル１０４、無線通信デバイス１０６、および無線通信デバイス１０８を含む。無線通信ネットワーク１００は、多くのユーザ間の通信を支援するように構成される。無線通信ネットワーク１００は、たった１つのセル１０４を含んでいるように例示されるが、無線通信ネットワークはどんな数のセルを含み得る。セル１０４の通信のカバー範囲は、マクロノード１０２によって提供され、それは、例えば基地局を備え得る。マクロのノード２０３は複数の無線通信デバイス、例えば、無線通信デバイス１０６および１０８と対話し得る。
【００１３】
無線通信デバイスの各々は、与えられた瞬間でフォワードリンク（ｆｏｒｗａｒｄ ｌｉｎｋ：ＦＬ）および／またはリバースリンク（ｒｅｖｅｒｓｅ ｌｉｎｋ：ＲＬ）上のマクロノード１０２と通信し得る。ＦＬは、マクロノードから無線通信デバイスまで通信リンクである。ＲＬは、無線通信デバイスからマクロノードまで通信リンクである。マクロノード１０２は、例えば、適切な有線あるいは無線のインタフェースによって、他のセル（この図の中で示されない）のマクロノードに例えば相互連結され得る。従って、マクロノード１０２は、他のセル（この図の中で示されない）の無線通信デバイスと通信し得る。
【００１４】
図１Ａへの継続的な参照で、セル１０４は、田舎の環境における数マイル平方あるいは近傍の内のほんの少数のブロックをカバーし得る。各セルは、さらに、１つ以上のセクター（この図の中で示されない）へ分割され得る。追加のセルを含んでいることによって、技術において有名なように、無線通信ネットワーク１００は大きな地理的な地域上のサービスを提供してもよい。
【００１５】
無線通信デバイス（例えば、１０６）は、通信ネットワークを通して音声あるいはデータを送信し受信するためにユーザによって使用される無線通信デバイス（例えば、携帯電話、ルータ、パーソナルコンピュータ、サーバーなど）であり得る。アクセスターミナル（ＡＴ）もユーザ設備（ＵＥ）、移動局（ＭＳ）、あるいは端末デバイスとここに呼ばれてもよいとともに、無線通信デバイスは引用されてもよい。示されるように、無線通信デバイス１０６および１０８は、携帯電話を備え得る。しかしながら、無線通信デバイスは、どんな適切な通信デバイスも含み得る。
【００１６】
無線通信デバイス１０８あるいは別のセルにおける無線通信デバイス（この図の中で示されない）のような別の無線通信デバイスに情報を送信し、そこから情報を受信することは、無線通信デバイス１０８あるいは別の無線通信デバイスは送信情報に無線通信デバイス（例えば１０６）には望ましいことであり得る。無線通信デバイス１０６は、無線リンクによってマクロのノード１０２と最初に通信することにより、これを遂行してもよい。例えば、無線通信デバイス１０６は、マクロノード１０２へのメッセージを生成し送信し得る。そして、マクロノード１０２は、無線通信デバイス１０８のような別の無線通信デバイスへメッセージを生成し送信し得る。メッセージは、様々なタイプの通信（例えば、音声、データ、マルチメディアサービスなど）と関係する情報を備え、図４−１３に関して詳細に以下で議論されるように、１つ以上の拡張ヘッダーがあるパケットを含み得る。
【００１７】
図１Ｂは、別の例の無線通信ネットワーク２００を例示する。例示された無線通信ネットワーク２００は、無線通信デバイス１０６、第２の無線通信デバイス２１０、第３の無線通信デバイス２２０、および第４の無線通信デバイス２３０を含む。無線通信ネットワーク２００は、無線通信デバイス１０６、２１０、２２０および２３０のような多くのデバイスの間の通信を支援するように構成され得る。無線通信デバイス（例えば、２１０と２２０）は、例えば、パーソナルコンピュータ、ＰＤＡ、音楽プレーヤー、ビデオプレーヤー、マルチメディアプレーヤー、テレビ、電子ゲームシステム、ディジタルカメラ、ビデオカムコーダー（ｃａｍｃｏｒｄｅｒ）、時計、リモートコントロール、ヘッドセット、などを備え得る。無線通信デバイス１０６は、両方の図１および２に例証されるが、無線通信デバイス１０６は、図１Ａの無線通信ネットワーク１００および無線通信ネットワーク２００と同時に通信する必要がない。
【００１８】
図１Ｂへの継続的な参照で、無線通信デバイス１０６は、さまざまな通信チャンネル上に他の無線通信デバイス（例えば２１０と２２０）と通信し得る。通信チャンネルは、技術において知られティルように、ウルトラ広域帯域（Ｕｌｔｒａ−Ｗｉｄｅ Ｂａｎｄ：ＵＷＢ）チャネル、ブルーツース（Ｂｌｕｅｔｏｏｔｈ（登録商標））チャネル、８０２．１１のチャネル（例えば８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ）、赤外線（ＩＲ）チャネル、ジッグビー（ＺｉｇＢｅｅ）（８０２．１５）チャネルあるいは、様々な他のチャネルを含み得る。１つの実施例では、チャネルは、ＥＣＭＡ−３６８標準に一致するＵＷＢチャネルであり得る。
【００１９】
無線通信ネットワーク２００は、家庭、オフィス、あるいは一グループのビルディングのように、物理的なエリアをカバーする無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＬＡＮ）を含み得る。ＷＬＡＮは、８０２．１１基準（例えば８０２．１１ｇ）、および／または無線通信のための他の基準のような基準を使用し得る。ＷＬＡＮは、無線通信デバイスが互いと直接通信するピアツーピア通信を使用し得る。無線通信ネットワーク２００は、さらに、例えば、数メーターのエリアをまたがる、無線パーソナルネットワーク（ｗｉｒｅｌｅｓｓ ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＰＡＮ）を含み得る。ＷＰＡＮは、赤外線、ブルーツース（Ｂｌｕｅｔｏｏｔｈ（登録商標））、ウィメディア（ＷｉＭｅｄｉａ）ベースのＵＷＢ標準（例えば、ＥＣＭＡ−３６８）、ジッグビー（ＺｉｇＢｅｅ）標準、および／または無線通信の他の標準のような基準を使用し得る。ＷＰＡＮは、無線通信デバイスが互いと直接通信するピアツーピア通信を使用し得る。無線通信ネットワーク２００が、無線通信デバイス１０６のようなデバイスを通して、無線通信ネットワーク１００またはインターネットのような他のネットワークに接続し得る。
【００２０】
無線通信ネットワーク２００を横切って送信されたメッセージは、さまざまなタイプの通信（例えば音声、データ、マルチメディアサービスなど）と関係する情報を備え、図４−１２に関して詳細に以下に議論されるように、１つ以上の拡張ヘッダーを有するパケットを含み得る。
【００２１】
次の実施例は、図１Ｂおよび特にＥＣＭＡ−３６８標準を参照し得る、それらは、また、図１Ａにおいて示される通信システム１００および他の通信標準に適用可能であり得る。例えば、１つの実施例はＵＭＴＳ通信システムにおいて適用可能であり得る。別の実施例は、ＯＦＤＭＡ通信システムにおいて適用可能であり得る。いくつかの実施例は、ある無線通信デバイスから別の無線通信デバイスにデータを送信する場合、パディングビットを使用するあらゆる通信システムに適用され得る。一般に、パディングビットは、ある長さにフレームを「詰めこむ（ｐａｄ）」ために使用される、フレーム（例えば、通信システムによって使用されるデータの１単位）内のビットである。例えば、通信システム２００は、無線通信デバイス（例えば１０６と２２０）間で送られたフレームがすべて長さ２５６ビットであることを必要とし得る。無線通信デバイス１０６が１フレームにおいて送るために単に１２８ビットのデータを持っている場合に、無線通信デバイス１０６は、フレームの合計長さが２５６のビット長の必要を満たすようにフレームの残りを満たすために１２８のパディングビットを使用し得る。
【００２２】
ＥＣＭＡ−３６８標準は、ウルトラ広帯域（ＵＷＢ）通信システムのための物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ：ＰＨＹ）および媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ：ＭＡＣ）副層を特定する。例えば、ＥＣＭＡ−３６８標準は高速短距離無線ネットワークにおいて使用され得る。ＥＣＭＡ−３６８標準は、３１００〜１０，６００ＭＨｚの間の周波数スペクトルのすべてあるいは部分を使用し得て、また４８０Ｍｂ／ｓまでのデータレートをサポートし得る。ＥＣＭＡ−３６８標準は、各々５２８ＭＨｚの帯域幅でスペクトルを１４の帯域に分割する。ＥＣＭＡ−３６８標準は、送信情報にマルチバンド直交周波数分割変調（ＭＢ−ＯＦＤＭ）スキームを使用し得る。周波数領域拡張、時間領域拡張、および順方向誤り修正（ｆｏｒｗｏｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ：ＦＥＣ）符号化は、さまざまなチャネル条件の下で最適な実行に提供される。
【００２３】
ＥＣＭＡ−３６８標準のＭＡＣ副層は、他のグループに合併したり他のグループから別れたりしながら、グループのデバイスに継続的な通信を可能にし得る。このＭＡＣの機能性は、多数のデバイスに分配され得るこれらの機能は、チャネルの適切な使用によって異なるグループのデバイスの間での干渉を避けるための分配された調整およびサービスの質を保証するための分配された媒体の確保を含む。ＥＣＭＡ−３６８のＭＡＣ副層は、等時性のデータ転送および非同期のデータ転送ための優先的にされたスキームを提供し得る。これをするために、ＥＣＭＡ３６８標準は、キャリヤーセンス多重アクセス（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＣＳＭＡ）あるいは時分割多元接続方式（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＴＤＭＡ）のうちの１つを使用してもよい。ＥＣＭＡ−３６８標準のＭＡＣ副層は、帯域幅の公正な共有を保証し得る。
【００２４】
図２は、図１Ａと１Ｂの中で示される例の無線通信デバイス１０６の機能ブロック図である。上に議論されるように、無線通信デバイス１０６は携帯電話であり得る。無線通信デバイス１０６は、記憶、送信、および／または無線通信デバイス１０６の他のコンポーネントのコントロールのための情報を処理するように構成されたプロセッサ２００を含み得る。プロセッサ２００は、さらに、メモリ２０４にさらにつながれ得る。プロセッサは、メモリ２０４から情報を読み出しあるいはメモリ２０４に情報を書み得る。メモリ２０４は、処理の前に、処理中に、あるいは処理後後にメッセージを格納するように構成され得る。メモリ２０４は、さらに、拡張ヘッダーデータおよび／または図６−１２を参照して、さらに詳細に以下に議論されるとともに拡張ヘッダーを有する１つ以上のパケットを格納し得る。プロセッサ２００、また、無線ネットワークインターフェース２０８につながれ得る。無線ネットワークインターフェース２０８は、内部行きの無線メッセージを受け取り、またマクロノード（例えば１０２）および／または別の無線通信デバイス（例えば２２０）に外部行きの無線電信を送信するように構成され得る。内部行きの無線メッセージは、処理用のプロセッサ２００に渡され得る。プロセッサ２００は、１つ以上の拡張ヘッダーを有するパケットを処理し得る。
【００２５】
プロセッサ２００は、外部行きの無線メッセージの送信のための無線ネットワークインターフェース２０８へ渡す外部行きの無線メッセージを処理し得る。さらに、プロセッサ２００は、図１２に関して詳細に下に議論されるように、送るための拡張ヘッダーを識別し、メッセージにそれらを含み得る。プロセッサ２００は、また、メッセージインタプリタ２０６につながれ得る。マクロのノード１０２および／または別の無線通信デバイス（例えば２２０）から無線ネットワークインターフェース２０８で受信された内部行きの無線メッセージは、プロセッサ２００に渡され、追加の処理のためのメッセージインタプリタ２０６へのプロセッサ２００によって渡され得る。メッセージインタプリタ２０６は、メッセージ解釈での使用を、情報を格納するか検索するためにメモリ２０４につながれ得る。メッセージインタプリタ２０６は、１つ以上の拡張ヘッダーを有するパケットを解釈してもよい。図９および１２に関して下記に述べられた１つの実施例では、メッセージインタプリタ２０６は、１つ以上の分解された拡張ヘッダーを処理し得る。
【００２６】
プロセッサ２００は、また、メッセージフォーマッタ２０２につながれ得る。メッセージフォーマッタ２０２は、ワイヤレスネットワークインターフェース２０８によって送信される外部行きの無線メッセージを生成しあるいはフォーマットし得る。無線の外部行きのメッセージは、マクロノード（例えば１０２）および／または別の無線通信デバイス（例えば２２０）への無線ネットワークインターフェース２０８による送信のためのプロセッサ２００へメッセージフォーマッタ２０２によって渡され得る。メッセージフォーマッタ２０２は、メッセージフォーマットでの使用に対して情報を格納するか検索するためにメモリ２０４に直接つながれ得る。図６−１２に関して詳細に以下に記述されるように、メッセージフォーマッタ２０２は、拡張ヘッダーあるいは拡張ヘッダーフレームチェックシーケンス、１つ以上のパケットの中へティルビットあるいはパッドビットを挿入し得る。
【００２７】
無線ネットワークインターフェース２０８は、アンテナとトランシーバを含み得る。トランシーバは、マクロのノード１０２および／または別の無線通信デバイス（例えば２２０）に行くかそれから来る外部行きの／内部行きの無線メッセージを変調／復調するように構成され得る。アンテナは、外部行きの／内部行きの無線メッセージを送信／受信し得る。アンテナは、１つ以上のチャネル上のマクロノード１０２と通信するように構成され得る。外部行きの／内部行きの無線メッセージは、音声および／またはデータのみの情報（ひとまとめにして、ここで「データ」と呼ばれる）を備え得る。ワイヤレスネットワークインターフェース２０８は、受信されるデータを復調し得る。無線ネットワークインターフェース２０８は、無線ネットワークインターフェース２０８経由で無線通信デバイス１０６から送信されるデータを変調し得る。プロセッサ２００は、送信されるデータを提供し得る。
【００２８】
メモリ２０４は、異なるレベルが異なる容量およびアクセス速度を持っている多重レベルの階層的なキャッシュを含むプロセッサキャッシュを備え得る。メモリ２０４は、さらにランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ＲＡＭ）、他の揮発性記憶デバイスあるいは不揮発性記憶素子を含み得る。記憶装置は、ハードドライブ、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ：ＣＤ）あるいはディジタルビデオディスク（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｃ：ＤＶＤ）のような光ディスク、フラッシュメモリ、フロッピー（登録商標）ディスク、磁気テープおよびジップ・ドライブを含み得る。
【００２９】
別々に記述されたが、無線通信デバイス１０６に関して記述された機能的ブロックが、個別の構造エレメントである必要がないことは認識されるべきである。例えば、プロセッサ２００およびメモリ２０４は、シングルチップで具体化されてもよい。プロセッサ２００は、さらに、あるいは代わりに、プロセッサレジスタのようなメモリをみ得る。同様に、機能ブロックの１つ以上またはさまざまなブロックの一部は、シングルチップで具体化され得る。あるいは、特定のブロックの機能性は、２つ以上のチップ上でインプリメントされてもよい。
【００３０】
プロセッサ２００、メッセージインタプリタ２０６およびメッセージフォーマッタ２０２のような無線通信デバイス１０６に関して記述された機能的ブロックの１つ以上の機能的ブロックおよび／または１つ以上の組合せの１つ以上は、汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、特定用途向けＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：ＦＰＧＡ）あるいは他のプログラマブルロジックデバイス、個別のゲートかトランジスターロジック、個別のハードウェアコンポーネントあるいはここに記述された機能を実行することを設計されるそれの任意の適切な組合せとして具体化され得る。無線通信デバイス１０６に関して記述された機能ブロックの１つ以上および／または機能的ブロックの１つ以上の組合せの１つ以上は、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰ通信と協力する１個以上のマイクロプロセッサ、あるいは他のそのような構成としてインプリメントされ得る。
【００３１】
図３は、図１Ａの中で示される例のマクロノード１０２の機能ブロック図である。図１Ａに関して上に議論されるように、マクロノード１０２は基地局であり得る。マクロのノード１０２は、内部行きの無線メッセージを受信し、無線通信デバイス１０６のような１つ以上の無線通信デバイスに外部行きの無線メッセージを送信するように構成された無線ネットワークインターフェース３０８を備え得る。無線ネットワークインターフェース３１０は、プロセッサ３００につながれ得る。プロセッサ３００は、ンターフェース３１０経由で無線通信デバイス１０６から来るまた行く内部行き・外部行きの無線メッセージを処理するように構成され得る。プロセッサ３００は、１つ以上の拡張ヘッダーを有するパケットを処理し得る。
【００３２】
プロセッサ３００は、また、マクロノード１０２の他のコンポーネントをコントロールするように構成され得る。プロセッサ３００は、さらに、有線ネットワークインターフェース３０８につながれ得る。有線ネットワークインターフェース３０８は、内部行きの有線メッセージを受信し、また他の目的地（例えば他のマクロのノードおよび／または無線通信デバイスへの外部行きの有線メッセージを送信するように構成され得る。有線ネットワークインターフェース３０８は、内部行きの有線メッセージを受信し、内部行きの有線メッセージを処理用のプロセッサ３００へ渡し得る。プロセッサ３００は、外部行きの有線メッセージを処理し、外部行きの有線メッセージを送信のために有線ネットワークインターフェース３０８へ渡し得る。
【００３３】
プロセッサ３００は、さらにメモリ３０４に、１つ以上のバスによってつながれ得る。プロセッサ３００は、メモリ３０４から情報を読み出し、あるいはメモリ３０４に情報を書き込み得る。メモリ３０４は、内部行きあるいは外部行きの有線あるいは無線のメッセージを処理することにおける使用のために情報を格納するように構成され得る。メモリ３０４はさらに、図６−１２に関して一層に詳細に下に議論されるように、拡張ヘッダーデータ拡張ヘッダーを有する１つ以上のパケットを格納し得る。プロセッサ３００は、また、メッセージインタプリタ３０６につながれ得る。プロセッサは、処理のためにメッセージインタプリタ３０６へ内部行きの有線および無線のメッセージを渡し得る。メッセージインタプリタ３０６は、１つ以上の拡張ヘッダーを有するパケットを解釈し得る。図９および１２に関して下記に述べられた１つの実施例では、メッセージインタプリタ３０６は、１つ以上の分離された拡張ヘッダーを処理し得る。
【００３４】
メッセージインタプリタ３０６は、無線ネットワークインターフェース３１０で受信された内部行きの無線メッセージから情報を抽出するように構成され得る。例えば、無線通信デバイスから受信される内部行きの無線メッセージは、パッケージ拡張ヘッダーを含み得る。メッセージインタプリタ３０６は、無線通信デバイスによって提供される内部行きの無線メッセージからパッケージ拡張ヘッダーを抽出し得る。メッセージインタプリタ３０６は、追加の処理用のプロセッサ３００へこの識別情報を渡し得る。別の例において、メッセージインタプリタ３０６は、内部行きの無線メッセージを処理し、かつ追加情報を要求することにより内部行きの無線メッセージに応答するための情報をプロセッサに３００を供給するように構成され得る。メッセージインタプリタ３０６は、また、メッセージ解釈での使用についての情報を格納するか検索するためにメモリ３０４に直接つながれ得る。
【００３５】
プロセッサ３００は、また、メッセージフォーマッタ３０２につながれ得る。メッセージフォーマッタ３０２は、外部行きの有線または無線のメッセージを生成するように構成され得る。メッセージフォーマッタ３０２は、さらに、生成された外部行きの有線あるいは無線のメッセージをプロセッサ３００へ渡すように構成され得る。図６−１２に関して詳細に以下に記述されるように、メッセージフォーマッタ２０２は、１つ以上のパケットへ、拡張ヘッダーあるいは拡張ヘッダーフレームチェックシーケンス、ティルビットあるいはパッドビットを挿入し得る。
【００３６】
プロセッサ３００は、送信のための有線ネットワークインターフェース３０８あるいは無線ネットワークインターフェース３１０へ外部行きの有線あるいは無線のメッセージを渡し得る。さらに、プロセッサ３００は、図１２に関して詳細に下に議論されるように、送るために拡張ヘッダーを識別し、メッセージにそれらを含み得る。有線ネットワークインターフェース３０８は、別のマクロノードへの外部行きの有線メッセージを送信し得る。メッセージフォーマッタ３０２は、プロセッサ３００へ外部行きの無線メッセージを渡し得る。プロセッサ３００は、無線通信デバイス１０６への送信のための無線ネットワークインターフェース３１０への外部行きの無線メッセージを渡し得る。メッセージフォーマッタ３０２は、また、メッセージフォーマットでの使用に対する情報を格納するか検索するためにメモリ３０４に直接つながれ得る。
【００３７】
無線ネットワークインターフェース３１０は、アンテナとトランシーバを含み得る。トランシーバは、無線通信デバイスに行くかそこから来る外部行きの／内部行きの無線メッセージを変調／復調するように構成され得る。アンテナは、内部行きの／外部行きの無線メッセージを送信／受信し得る。アンテナは、１つ以上のチャネル上のマクロノード１０２から外部行きの／内部行きの無線メッセージを送信しおよび／または受信するように構成され得る。外部行きの／内部行きの無線メッセージは、音声および／またはデータのみの情報／（まとめてここに「データ」と呼ばれる）を含み、拡張ヘッダーがある１つ以上のパケットを含み得る。無線ネットワークインターフェース３１０は、受信されるデータを復調し得る。無線ネットワークインターフェース３１０は、無線ネットワークインターフェース３１０経由でマクロノード１０２から送信されるデータを変調し得る。プロセッサ３００は、送信されるデータを提供し得る。
【００３８】
有線ネットワークインターフェース３０８は、モデムを含み得る。モデムは、別のマクロのノードのような別の目的地／リソースへ行くかそこから来る外部行きの／内部行きの有線メッセージを変調／復調するように構成され得る。有線ネットワークインターフェース３０８は、技術において既知の方法を使用する１つ以上の有線の標準に従って受信されるデータを復調し得る。復調されるデータは、プロセッサ３００に送信され得る。有線ネットワークインターフェース３０８は、技術において既知の方法を使用する１つ以上の有線の標準に従って有線ネットワークインターフェース３０８経由でマクロノード１０２から送信されるデータを変調し得る。プロセッサ３００は、送信されるデータを提供し得る。
【００３９】
メモリ３０４は、異なるレベルが異なる容量およびアクセス速度を持っている多重レベル階層的キャッシュを含むプロセッサキャッシュを備え得る。メモリ３０４は、さらにランダムアクセスメモリ（ＲＡＭ）、他の揮発性記憶デバイスあるいは不揮発性記憶素子を含み得る。記憶装置は、ハードドライブ、コンパクトディスク（ＣＤ）あるいはディジタルビデオディスク（ＤＶＤ）のような光ディスク、フラッシュメモリ、フロッピー（登録商標）ディスク、磁気テープ、およびジップ・ドライブを含み得る。
【００４０】
別々に記述されたが、マクロノード１０２に関して記述された機能的ブロックが個別の構造エレメントである必要がないことは認識されるべきである。例えば、プロセッサ３００およびメモリ３０４は、シングルチップで具体化され得る。プロセッサ３００は、さらに、あるいは代わりに、プロセッサレジスタのようなメモリを含み得る。同様に、１つ以上の機能ブロックあるいはさまざまなブロックの機能性の部分は、シングルチップで具体化されてもよい。代わりに、特有のブロックの機能性は２つ以上のチップ上でインプリメントされ得る。
【００４１】
１つ以上の機能的ブロックおよび／またはプロセッサ３００、プロセッサ３００、メッセージインタプリタ３０６およびメッセージフォーマッタ３０２のようなマクロのノード１０２に関して記述された機能的ブロックの１つ以上の組合せは、メインプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）あるいは他のプログラマブルロジックデバイス、個別のゲートかトランジスターロジック、個別のハードウェアコンポーネントあるいはここに記述された機能を実行するよう設計されるそれらの任意の適切な組合せとして具体化され得る。１つ以上の機能的ブロックおよび／またはマクロノード１０２に関して記述された機能的ブロックの組合せは、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰ通信に協働する１個以上のマイクロプロセッサあるいは他のそのような構成としてインプリメントされ得る。
【００４２】
図２−３のモジュールの機能性は、示唆と一致するさまざまな方法でここにインプリメントされ得る。いくつかの態様において、これらのモジュールの機能性は１つ以上の電気コンポーネントとしてインプリメントされ得る。いくつかの態様において、これらのブロックの機能性は１つ以上のプロセッサコンポーネントを含む処理システムとしてインプリメントされ得る。いくつかの態様において、これらのモジュールの機能性は、例えば、１つ以上の集積回路（例えばＡＳＩＣ）の少なくとも１つの部分を使用してインプリメントされ得る。ここに議論されるように、集積回路は、プロセッサ、ソフトウェア、他の関連するコンポーネント、あるいはそれのある組合せを含み得る。これらのモジュールの機能性は、さらに、ここで示唆されるような他のある方法でインプリメントされ得る。ここに記述された機能性（例えば、１つ以上の添付の図に関して）は、いくつかの態様において、添付された請求項における同様に指定された「のための手段」という機能性に一致し得る。図１−３を参照すると、マクロノード１０２および無線通信デバイス１０６は、一連の相互関係がある機能モジュールとして表わされる。
【００４３】
図４は、ＥＣＭＡ−３６８標準に一致する例のフレーム構造を例示する。物理層収束プロトコル（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ：ＰＬＣＰ）のプロトコルデータ単位あるいはＰＰＤＵあるいはフレーム構造４００は、ＰＬＣＰプリアンブル４０２、ＰＬＣＰヘッダー４０４、および物理層サービスデータ単位、あるいはＰＳＤＵ ４０６を備える。ＥＣＭＡ−３６８標準は、無線通信ネットワーク（例えば１００）をサポートするために超広帯域の物理（ｐｈｙｓｉｃａｌ：ＰＨＹ）層および媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ：ＭＡＣ）副層を定義する。したがって、１つの実施例では、無線通信デバイス（例えば１０６）は、内部行きの無線メッセージを受信し、また、ＥＣＭＡ−３６８標準を使用して、１つ以上の他の無線通信デバイス（例えば２１０、２２０、および２３０）に外部行きの無線メッセージを送信するように構成された例えば、無線ネットワークインターフェース（例えば、２０８）および／またはプロセッサ（例えば、２００）を有し得る。ＰＳＤＵ４０６は、無線通信デバイス（例えば１０６）および別の無線通信デバイス（例えば２２０）から遅れるパケットに含まれていたさまざまなタイプの通信（例えば音声、データ、マルチメディアサービスなど）と関係するデータのビットを含み得る。無線通信ネットワーク２００はＥＣＭＡ−３６８標準を利用し得るが、この選択が単に実例であり、また図６−１３に関して下記に述べられた実施例は、さまざまな標準を利用する通信ネットワークに適用可能であることが理解されるだろう。
【００４４】
図４に例証されるように、ＰＳＤＵ４０６はフレームペイロード４１０、フレームチェックシーケンス、ティルビットおよびパッドビット４１２を含む。フレームペイロード４１０は、無線通信デバイス（例えば、１０６）へまたはその無線通信デバイスから他の無線通信デバイス（例えば、２２０）に送られるパケットに含まれティルさまざまなタイプの通信（例えば、音声、データ、マルチメディアサービスなど）と関係するデータのビットを備え得る。フレームチェックシーケンスは、フレームが誤り検出修正を援助するためにチェックサム文字を提供する。無線ネットワークインターフェース（例えば、２０８または３０８）が畳込み復号器を含んでいる実施例では、ティルビットは、それをその初期状態にリセットし、かつ誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ＥＣＭＡ−３６８標準は、ビット・ストリームがバースト誤りに対する頑強性を提供するために変調に先立ってインターリーブされることを規定した。従って、標準は、パッドビット４１２がＰＳＤＵ４０６がインタリーバの境界上で整列することを保証することを規定する。
【００４５】
図４への持続的な参照で、ＰＬＣＰプリアンブル４０２はタイミング同期、キャリアに相殺された回復およびチャネル推定で無線ネットワークインターフェース（例えば２０８または３０８）を援助し得る。ＥＣＭＡ−３６８標準におけるＰＬＣＰプリアンブル４０２は、チャネル推定シーケンスが後続するパケット／フレーム同期シーケンスから成る。
【００４６】
ＰＬＣＰヘッダー４０４はＰＳＤＵ４０６のデコードで使用するために無線ネットワークインターフェース（例えば２０８または３０８）へ情報を伝えてもよい。図４に例示されるように、ＰＬＣＰヘッダー４０４は、ティルビットのＰＨＹヘッダー４０８、ＭＡＣヘッダー、ヘッダーチェックシーケンス、リード−ソロモンパリティバイトおよび３つのフィールドを含む。ＰＨＹヘッダー４０８は、図５に関して詳細に下に議論されるだろう。ヘッダーチェックシーケンスおよびリード−ソロモンパリティバイトはＰＬＣＰヘッダー４０４に対して改善された誤り検出訂正を提供する。さらに、無線ネットワークインターフェースが畳込み復号器を含んでいる実施例では、ティルビットはそれをその初期状態にリセットし、かつ誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ＥＣＭＡ−３６８標準では、ＭＡＣヘッダーは、伝送エラーの可能性を減少させるために送信に先立ってヘッダーチェックシーケンスでスクランブルがかけられる。
【００４７】
図５は、図４のフレーム構成のためのＰＨＹヘッダービット割り当てを例示する。ＰＨＹヘッダー４０８は、長さフィールド５０６を含み、それは、フレームチェックサム、ティルビットあるいはパッドビットを含まない、フレームペイロード（例えば４１０）の長さを示す。ＰＨＹヘッダー４０８はさらに確保されるビットを含んでいる。これらのビットは、ＥＣＭＡ−３６８標準中で将来の使用のために確保され、現在の標準中で０にセットされる。実例のみの目的のために、ＰＨＹヘッダー４０８は最初の予約のフィールド５０２および別の予約のフィールド５０４を含んでいる。
【００４８】
下記に述べられるように、第１の確保されるフィールド５０２および第２の確保されるフィールド５０４は１つ以上の実施例の中で使用され得る。１つの実施例において、図６−１３に詳細に下記に述べられるように、第１の確保されるフィールド５０２は１つ以上の拡張ヘッダーの存在および内容を示すために使用される。別の実施例において、第２の確保されるフィールド５０４は、送信器（例えば、２０８または３０８）および受信機（例えば、２０８または３０８）をＣＳＩに関して同期するよう維持するために使用される。特に、ＰＬＣＰヘッダー４０４の第２の確保されるフィールド５０４の中で現在のＰＳＤＵ送信に使用されティル拡張ヘッダーのバージョン番号があり得る。連続のフィードバックの間隔は、バージョン番号が８つのフィードバックの後に折り返す場合に問題がないだろうということを保証する。上に記述された実施例は第１の確保されるフィールド５０２および第２の確保されるフィールド５０４のコンテキスト中で例示されるが、記述された実施例は予約のビットのうちのどれにも適用可能である。
【００４９】
図４のＰＬＣＰヘッダー４０４はＰＨＹとＭＡＣヘッダーの両方を含んでいる。図６−１３に関して下記に述べられた実施例は、ＥＣＭＡ−３６８およびＥＣＭＡ−３８７標準におけるように共通のＰＨＹヘッダーおよびＭＡＣヘッダーを有するフレーム構成に適用可能であるが、実施例は、また、ＰＨＹヘッダー拡張に利用可能な限られた数の確保されるビットを備えたものを含むさまざまなフレーム構造に適用可能である。別の実施例は、さらに通信システムおよび／または個別のＰＨＹおよびＭＡＣヘッダー（例えば８０２．１１の標準）を備えた標準に適用可能かもしれない。
【００５０】
ある通信システムでは、次世代設備設計のためのより多くのフィールドのために提供するべきＰＨＹヘッダー４０８およびＭＡＣヘッダーを拡張することは望ましいことであり得る。そのような次世代設備は、典型的には既存か前任者の設備より多くのヘッダーデータを要求するだろう。さらに、それは、零か最小のオーバヘッドを招く制御チャネルを提供することは拡張ヘッダーに望ましいことであり得る。例えば、ＥＣＭＡ−３６８における制御情報は３つの方法、ビーコンとして、またはコマンドフレームあるいはコントロールフレームとして、あるいは他のトラヒックに便乗して、のうちの１つで送られ得る。ビーコンは、必要とされるより頻繁でないかもしれないＥＣＭＡ−３６８標準において６５．５３６ミリ秒ごとに一度送られ得る。他方では、コントロールとコマンドフレームは個別の分散確保プロトコル（Ｄｉｓｔｒｉｂｕｔｅｄ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＤＲＰ）確保を要求し、個別のプリアンブル、ヘッダーおよび構造間間隔を備えたより多くのオーバヘッドという結果になる。各ペアの送信器および受信機がそれらのフレームを送るために個別のＤＲＰ確保を要求するので、この方法はデバイスの数で良く縮小しない。したがって、零か最小のオーバヘッドを招く制御チャネルを提供するＰＨＹヘッダー４０８およびＭＡＣヘッダーを拡張する必要がある。別の実施例では、優先的にされた競合アクセス（ｐｒｉｏｒｔｉｚｅｄ ｃｏｎｔｅｎｔｉｏｎ ａｃｃｅｓｓ：ＰＣＡ）はコマンド、制御情報および／またはフレームを送るために使用され得る。ＰＣＡを使用するシステムにおいて、異なるデバイス（例えば無線通信デバイス１０６および２２０）は、一定時間周期の間にフレーム（例えば、コマンド、制御フレーム）を送信するために、互いと競合し得る。いくつかのタイプのフレーム（例えばデータパケット）は、より高い優先事項を与えられ得る。最優先の１つのフレームおよび／または複数のフレームは、競われた期間に送信され得る。
【００５１】
一般にそこに恐らく、利用可能か、既存のヘッダー中で保存された制限のあるビット数、しかし、そのような予約のビットはヘッダー拡張用に提供するのには十分ではないかもしれない。確保されるビット（例えばヘッダーフィールドへヘッダービットを加算する）を越えてヘッダーフィールドを自体拡張することは、レガシーデバイスが新しいヘッダーをデコードすることができ、ヘッダーチェックシーケンスを確認することができ得ないように、ヘッダーをレガシーデバイスと互換性をもつようにし得ない。従って、さらに、レガシーデバイスと互換性をもつ確保されるビットを越えたヘッダー拡張を考慮に入れる縮小拡大可能なヘッダー拡張構造は望ましいかもしれない。ある実施例に従う縮小拡大可能なヘッダー拡張構造は、拡張ヘッダーがフレームの期間を増加させずに、送信されかつ／または受信されることを可能にし得る。フレーム持続期間を増加させずに、ヘッダー拡張を送信することは、レガシーデバイスとの互換性を促進するのを支援し得る。別の実施例は、拡張ヘッダー（ｓ）が、拡張ヘッダーデータ／情報を送信するために付加時間スロット（例えば、確保持続期間を拡張しおよび／または追加のフレームとして拡張ヘッダーを送信することなしで）を必要とせずに送信されることを可能にし得る。１つの実施例において、個別のプリアンブル、ヘッダーおよびフレーム間間隔のようなオーバヘッドは縮小され得る。これは、システムの使用での効率を増加させ得る。別の実施例において、パディングビット（ある長さにフレームを「詰める（ｐａｄ）」ために単に使用されるビット）は使用され得る。これらのパディングビットの使用は、一般に非有用なビットがヘッダー拡張データのような送信データに使用されることを可能にし得る。以前に非有用なビットが送信データに使用され得るように、これはさらにシステムの使用での効率を増加させ得る。
【００５２】
図６は実例となる実施例によって例の縮小拡大可能なヘッダー拡張構造である。典型的な縮小拡大可能なヘッダー拡張構造６００は、ＰＬＣＰヘッダー４０４、第１の拡張ヘッダー６０６、第２の拡張ヘッダー６１０、第Ｎの拡張ヘッダー６１４および、実際のフレームペイロード４１０を含む。拡張ヘッダーは、それぞれ１つ以上の指標ビットの使用により他の拡張ヘッダーあるいは実際のフレームペイロード４１０を指し得る。
【００５３】
ＰＬＣＰヘッダー４０４における確保されるビットの制限される数にもかかわらず、上に議論されるように、無線通信デバイス（例えば１０６）は、必要な場合に実際のフレームペイロード４１０の前の１つ以上の拡張ヘッダーを挿入することにより、縮小拡大可能なヘッダー拡張構造６００を作り得る。プロセッサ（例えば、２００または３００）は縮小拡大可能なヘッダー拡張構造６００を作り得る。拡張ヘッダーは、詳細に下に議論されるとともに、無線通信ネットワーク（例えば１００）を越えて様々なタイプの情報あるいはコンテンツを送るために使用され得る。情報またはコンテンツは無線通信デバイス（例えば１０６）へおよび／またはそこから他の無線通信デバイス（例えば２１０、２２０、あるいは２３０）まで送られ得る。
【００５４】
拡張ヘッダーは、さまざまなタイプの情報あるいはコンテンツを送るために使用され得る。例えば、拡張ヘッダーの１つ以上は現在のＰＳＤＵを復号するためには必要とされない情報、あるいはそれ自身のＰＬＣＰヘッダーの頑強性を必要としない非重大なコンテンツを送るために使用され得る。１つの実施例では、拡張ヘッダーは、ＰＳＤＵに十分な余地がない場合、最善の努力ベースで任意に送られる情報を含む。別の実施例において、拡張ヘッダーは、複数フレームに関して無線ネットワークインターフェース（例えば２０８または３０８）によって受信されるコンテンツを含んでいる。無線通信デバイス（例えば１０６）の記憶は外、拡張ヘッダーを格納し得る。
【００５５】
拡張ヘッダーは、また、制御情報を送るために使用され得る。例えば、情報は、無線ネットワークインターフェース（例えば２０８または３０８）によってリソースの適応の割り当てためのチャネル状態情報（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ：ＣＳＩ）フィードバックを備えることができた。特に、情報は、送信電力、データレート、変調あるいは復号に向けられたコンテンツを含んでいる。１つの実施例において、拡張ヘッダーは、ローカルのリンクスケジューリング情報を含む。別の実施例において、拡張ヘッダーは、帯域外制御情報を含む。あるタイプのコンテンツを送るために使用される拡張ヘッダーは、参照されたが、拡張ヘッダーは上にリストされない他の制御情報を含む任意のタイプの情報を送るために使用され得る。
【００５６】
図６への継続的な参照で、１つの実施例において、第１の拡張ヘッダー６０６の存在は、ＰＬＣＰヘッダー４０４中の確保されるビットによって示される。例えば、図５の参照で、第１の拡張ヘッダー６０６が存在するかどうか示すためにＰＨＹヘッダー４０８の第１の確保されたフィールド５０２が使用されることができるだろう。表示に使用されたビットは、ＰＨＹヘッダー４０８の確保されるビットのうちのどれでも含む他の１つ以上のビットを含み得る。１つの実施例において、表１に関して下記に述べられるように、表示に使用されるビットは、第１の拡張ヘッダー６０６の存在およびコンテンツを示す。表示に使用されたビットは、プロセッサ（例えば２００または３００）あるいはメッセージフォーマッタ（例えば２０２または３０２）によって挿入され得る。
【表１】
【００５７】
表１は、次の拡張ヘッダーの存在およびコンテンツを示す１つの可能な符号化スキームを例示する。例えば、第１の拡張ヘッダー６０６の存在は、上に記述されるようなＰＬＣＰヘッダー４０４の確保される１つ以上のビットによって示され得る。３ビットを使用する例示される符号化スキームにおいて、符号化されるビットの値は、第１の拡張ヘッダー６０６の存在およびコンテンツを決定するために使用され得る。例えば、ビットの符号化された値が１だった場合、これは第１の拡張ヘッダー６０６がＣＳＩの内容を含むことを示し得る。同様に、ビットの符号化された値が０だった場合、これは、第１の拡張ヘッダー６０６が存在せず、実際のフレームペイロード４１０が直ちにＰＬＣＰヘッダー４０４に続くことを示し得る。
【００５８】
図６および表１への継続的な参照で、第２の拡張ヘッダー６１０の存在を示すビットは、１つ以上のビットの第１の拡張ヘッダー６０６を含み得る。第２の拡張ヘッダー６１０を示すために使用されたビットは表１に記述される符号化されたスキームを使用して符号化され得る。したがって、第２の拡張ヘッダー６１０に対応する指標ビットの符号化された値が、２だった場合、これは第２の拡張ヘッダー６１０がリンクスケジューリングコンテンツを含むことを示し得る。同様に、ビットの符号化された値が０だった場合、これは、第２の拡張ヘッダー６１０が存在せず、実際のフレームペイロード４１０が直ちに最初の拡張ヘッダー６０６に続くことを示し得る。第Ｎの拡張ヘッダー６１４の存在を示すビットは、表１の符号化スキームを使用して同様のやり方でインプリメントされ得る。
【００５９】
上に記述された縮小拡大可能なヘッダー拡張構造６００は、拡張ヘッダーのデイジーチェーンに相当する。ＰＬＣＰヘッダー４０４における１つ以上の指標ビットは、第１の矢印６０４によって、抽象的に示されるように、第１の拡張ヘッダー６０６を指し得る。同様に、第１の拡張ヘッダー６０６における１つ以上の指標ビットは、第２の矢印６０８によって、抽象的に示されるように、第２の拡張ヘッダー６１０を指し得る。同様に、第３の矢印６１２および第４の矢印６１６は、さらに、抽象的に、拡張ヘッダーのデイジーチェーンを表すために使用され得る。デイジーチェーンのほかの他の縮小拡大可能なヘッダー拡張構造は、可能である。例えば、ＰＬＣＰヘッダー４０４における１つ以上の確保されるビットが、拡張ヘッダーが存在するかどうかおよび／または存在する拡張ヘッダーの数を示し得る。１つの実施例において、ビットが１つ以上の拡張ヘッダーの存在を示す場合、ヘッダー拡張指標フィールドの列を含んでいるフィールドはＰＬＣＰヘッダー４０４の後に置かれ得る。
【００６０】
図７は、図６の縮小拡大可能なヘッダー拡張構造に従った例の修正されるＥＣＭＡ−３６８フレーム構成を例示する。修正されるフレーム構造７００は、ＰＬＣＰプリアンブル４０２、ＰＬＣＰヘッダー４０４、拡張されるＰＬＣＰヘッダー７０２、およびＰＳＤＵ４０６を備える。ＥＣＭＡ−３６８標準（例えば４００）によって定義されたフレーム構造とは対照的に、修正されるフレーム構造７００は、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードへ挿入される拡張されるＰＬＣＰヘッダー７０２を含む。ＰＬＣＰヘッダー７０２は、図６に関して上に記述されるような拡張ヘッダーのデイジーチェーンの使用により挿入され得る。
【００６１】
ＥＣＭＡ−３６８標準において、最大のＰＳＤＵの長さは、図５に例示された１２ビットの長さのフィールド５０６の最大値に対応して、４０９５バイトである。１つの実施例において、拡張されるＰＬＣＰヘッダー７０２は、実際のフレームペイロード４１０の前にＰＳＤＵ４０６のペイロードに挿入され、また、長さフィールド５０６は、拡張されるＰＬＣＰヘッダーの長さと実際のフレームペイロードの長さを示す。メッセージフォーマッタ（例えば、２０２または３０２）および／または、プロセッサ（例えば２００または３００）は、この挿入を行なうことができた。
【００６２】
例示される拡張ＰＬＣＰヘッダー７０２は、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードへ挿入されるように示されるが、拡張されるＰＬＣＰヘッダー７０２は、さまざまな方法で挿入され得る。例えば、１つの実施例において、下に議論されるように、拡張されるＰＣＬＰヘッダー７０２は、パッドビット４１２に挿入される。
【００６３】
現在のＥＣＭＡ−３６８システムにおいて、パディングビットは、記号インタリーバの境界上のデータストリームを整列させるために挿入され得る。例えば、ＥＣＭＡ−３６８は、データストリームが６つの直交周波数分割変調（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｏｄｕｌａｔｉｏｎ：ＯＦＤＭ）記号境界上で整列するように、パッドビットが挿入されると規定する。１つの実施例において、１つ以上の拡張ヘッダーが、ＰＳＤＵ４０６のパッドビット４１２に送られる。
【００６４】
例示目的だけのために、パッドビット４１２における拡張ヘッダーを送る次の見込みのモデルを考慮することは有用である。モデルの追加の詳細は、Ｄａｓ等のＩＣＵＷＢ２００９のＰＳＤＵ内の縮小拡大可能なＰＬＣＰヘッダー拡張において見出され、これは、全体の参照によってここに組込まれる。与えられた構造中のパッドビット４１２の数をｘにし、およびパッドビット４１２に挿入されることが望まれる拡張ヘッダー要素の合計長さをＡビットにしてください。このモデルのために、ｘは、一様の確率分布としてモデル化され得る。
【００６５】
したがって、ｘは０からＰ−１まで変化し、そこでは、Ｐは、フレームペイロードが送信され、与えられるＰＨＹデータレートで６つのＯＦＤＭシンボルの中の情報ビットの数に相当する。６つのＯＦＤＭシンボルの中の情報ビットの数は、ＥＣＭＡ−３６８標準によって定義され、また、表２に下に示されるように、その情報ビットはデータレートに応じて変わる。
【表２】
【００６６】
Ａ＜Ｐの場合に、我々はｘの範囲を２つの部分に分割し得る。第１の部分において、ｘ＜Ａで拡張ヘッダーは、パッドビット４１２に合わない。拡張ヘッダーがパッドビット４１２に挿入される場合、追加のパディングビットは、ＥＣＭＡ−３６８標準によって要求されるような６つのＯＦＤＭシンボル境界上のデータストリームを整列させるために必要とされるだろう。第２の部分において、ｘ≧Ａであり、拡張ヘッダーはパッドビット４１２に合うだろう。したがって、
【数１】
【００６７】
は、拡張ヘッダーが、ＰＳＤＵ４０６を拡張する必要なしに、パッドビット４１２に合わない確率である。１つの実施例において、
【数２】
【００６８】
が小さい場合に、拡張ヘッダーは、パッドビット４１２に無条件に置かれる。送信のごく一部分の中でＰＳＤＵ４０６が拡張されなければならないが、図１３に関して下記に述べられるとともに、ＰＬＣＰプリアンブルおよびＰＬＣＰヘッダーのオーバヘッドが償却される。別の実施例では、その後、拡張ヘッダーがパッドビット４１２に合う場合に限り、拡張ヘッダーはパッドビット４１２に置かれる。まだ別の実施例の中で、拡張ヘッダーが詰込みに利用可能なフィールドに入らない場合、図９に関して下記に述べられるように、パッドビット４１２においてふさわしい拡張ヘッダーフラグメントが送られる。
【００６９】
Ａ≧Ｐの場合に、ＰＳＤＵ持続期間が拡張されなければならない。特に、ＰＳＤＵは６個のシンボル持続期間の
【数３】
【００７０】
の数によって拡張されなければならなく、ｍｏｄ（Ａ，Ｐ）≦ｘ＜Ｐの場合にｙ＝０であり、そして０≦ｘ＜ｍｏｄ（Ａ，Ｐ）の場合にｙ＝１であろ。そして、この場合、我々は常に追加の６つのシンボルの持続時間の
【数４】
【００７１】
の数を招き、また、
【数５】
【００７２】
の蓋然性で、我々は追加の６つの記号持続期間を招く。１つの実施例では、拡張ヘッダーは、パッドビット４１２にＰＳＤＵの期間を無条件に拡張することという結論にし得る利用可能なパディングビットに合わなくてもよい。ＰＳＤＵ ４０６は、１つ以上の追加の６つの記号の持続時間によって拡張されなければならないが、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダー、およびフレーム間間隔のオーバヘッドが償却され得る。
【００７３】
パッドビット４１２に拡張されるＰＣＬＰヘッダー７０２を挿入することは、特有のモデルに関して上に記述されたが、これは説明の目的だけのためにあり、任意の方法に上に記述された実施例を限定するようには意図されなかった。
【００７４】
図８は第１の実施例に従う例の拡張されるＰＬＣＰヘッダー構造７０２である。例示の拡張されるＰＬＣＰヘッダー７０２は、第１の拡張ヘッダー指標８０２、第１の拡張長さ８０４、および第１の拡張情報８０６を有する第１の拡張ヘッダーを含む。拡張されるＰＬＣＰヘッダー７０２は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０および第２の拡張情報８１２を有する第２の拡張ヘッダーを含み得る。拡張されるＰＬＣＰヘッダー８１４は、すべての拡張ヘッダーの後に位置して、さらにパッドビット８１４を含む。例示されるＰＬＣＰヘッダー７０２は少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造は、どんな数の拡張ヘッダーも含むことができた。例えば、１つの実施例において、ＰＬＣＰヘッダー７０２は、１つ、２つ、あるいは３つの拡張ヘッダーを含み得る。別の実施例において、ＰＬＣＰヘッダー構造は、拡張ヘッダーを含んでいなくてもよくない。
【００７５】
例示される拡張されるＰＬＣＰヘッダー７０２は、図６−７に関して上に記述された実施例の中において使用され得る。図６および表１に関して上に記述されるように、第１の拡張ヘッダー指標８０２がインプリメントされ得る。拡張ヘッダー指標（例えば、８０２または８０４）は、特に上に記述されるような後の拡張ヘッダーの存在およびコンテンツを示し得る。ＰＬＣＰヘッダー（例えば、４０４）の中の確保されるビットは、第１の拡張ヘッダーの存在を示してもよい。他の拡張ヘッダー指標（例えば８０６）は前の拡張ヘッダーにあり得る。
【００７６】
例示される拡張されるＰＬＣＰヘッダー７０２は、第１の拡張の長さ８０４および第２の拡張長さ８０６を含んでいる。第１の拡張の長さ８０４は、第１の拡張情報８０６の長さを示し得る。同様に、第２の拡張長さ８１０は、第２の拡張情報８１２の長さを示し得る。１つの実施例において、拡張長さは１０ビットで、ビットにおける拡張ヘッダー情報の長さを示す。
【００７７】
図８への継続的な参照で、例示される拡張されるＰＬＣＰヘッダー７０２はパッドビット８１４を含んでいる。パッドビット８１４は、バイトが１つ以上の拡張ヘッダーを整列させるのに使用される。ある実施例では、パッドビット８１４は必要ではないかもしれない。例えば、拡張長さがバイトにおいて拡張ヘッダーの長さを示す場合、拡張ヘッダーは自動的に整列されたバイトである。
【００７８】
１つの実施例において、拡張長さフィールドは、時間アップで感知可能な処理を促進するためにメッセージインタプリタ（例えば２０６または３０６）および／またはプロセッサ（例えば２００または３００）によって使用される。特に、拡張長さフィールドは、必要とされるような拡張ヘッダーエレメントオフラインを処理する柔軟性を提供する。ペイロード、メッセージインタプリタ（例えば２０６または３０６）および／またはプロセッサ（例えば２００または３００）のスタートを位置づけることは、実際のフレームペイロードのスタートに達する拡張ヘッダー情報をスキップするために長さフィールドを使用し得る。
【００７９】
図９は、図８の拡張されるＰＬＣＰヘッダー構造の拡張ヘッダー情報フィールド用の例のコーディング表を例示する。例示された拡張ヘッダー情報９００は、バージョンフィールド、フラグメントフィールド、およびペイロードフィールドを含む。拡張ヘッダー情報９００は、拡張情報（例えば、８０６または８１２）のための多くの可能なフォーマットのうちの１つを例示する。
【００８０】
バージョンフィールドは、送信機及び受信機が拡張ヘッダー情報で更新に関して同期されることを維持するために使用され得る。例えば、拡張ヘッダーがＣＳＩを通信するために使用されティル場合、バージョンフィールドはＣＳＩの特定のバージョンを示し得る。１つの実施例において、バージョンフィールドは３ビットである。
【００８１】
図９への継続的な参照で、拡張ヘッダー全体が、現在のＰＳＤＵに合わない場合、フラグメント数フィールドは使用され得る。例えば、図７に関して上に記述されるように、最大のＰＳＤＵ長さは、ＥＣＭＡ−３６８標準において４０９５バイトである。従って、いくつかの拡張ヘッダーは、ＰＬＣＰヘッダーにおける長さフィールドが一般に拡張ヘッダーの長さとペイロードの長さ足したものを示すので、与えられたＰＳＤＵに入れるのに大きすぎ得る。フラグメント数は、拡張ヘッダーが１つを超えるＰＳＤＵの中で送られることを可能にし得る。さらに、図７に関して上に記述されるように、いくつかの実施例では、１つ以上の拡張ヘッダーがパッドビット４１２に置かれ得る。拡張ヘッダーが、パッドビット４１２に入らない場合、フラグメント数フィールドを有する拡張ヘッダーフラグメントはパッドビット４１２に挿入され、代わりに送られ得る。
【００８２】
ペイロードフィールドは、拡張ヘッダーの情報またはコンテンツを含み得る。この情報は、ＣＳＩ、リンクスケジューリング、帯域外制御、あるいは図６に関して上に記述されるような様々な他のタイプのコンテンツを含み得る。１つの実施例では、ペイロードフィールドの長さはヘッダー拡張タイプに特有である。例えば、表１への参照で、ペイロードフィールドの長さは、拡張ヘッダーがＣＳＩ、リンクスケジュール、帯域外制御コンテンツを含むかどうかに依存して、変わり得る。
【００８３】
図１０は、第２の実施例にしたがう例の拡張されるＰＬＣＰヘッダー構造である。絵入りの拡張ＰＬＣＰヘッダー１０００は、第１の拡張ヘッダー指標８０２、第１の拡張の長さ８０４および第１の拡張情報８０６がある第１の拡張ヘッダーを含む。例示される拡張されるＰＬＣＰヘッダー１０００は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０および第２の拡張情報８１２を有する第２の拡張ヘッダーを含む。拡張されるＰＬＣＰヘッダー８１４は、拡張ヘッダーの後に位置して、フレームチェックシーケンス１００２、ティルビット１００４、およびパッドビット８１４をさらに含む。例示されるＰＬＣＰヘッダー１０００は、少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造は拡張ヘッダーのどんな数の拡張ヘッダーも含むことができた。
【００８４】
図８の拡張されるＰＬＣＰヘッダー７０２と比較して、例示の拡張されるＰＬＣＰヘッダー１０００は、改善された誤り検出および修正を提示し得る。拡張されるＰＬＣＰヘッダーへのフレームチェックシーケンス１００２およびティルビット１００４の追加は、拡張ヘッダーにおける誤りから実際のフレームペイロードにおける誤りを分断し得る。
【００８５】
フレームチェックシーケンス１００２は、誤り検出修正を改善するために拡張ＰＬＣＰヘッダー１０００に特有の検査合計特徴を提供する。１つの実施例において、フレームチェックシーケンス１００２は３２ビットである。無線ネットワークインターフェース（例えば、２０８または３０８）が畳込み復号器を含んでいる場合、ティルビット１００４はそれをその初期状態にリセットし、かつ、誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ティルビット１００４の追加は、特に拡張ヘッダーにおける誤りからの実際のフレームペイロードにおける誤りを分断し、大きなフレームペイロードの前に付け加えられた時特に有益である。
【００８６】
図１１は第３の実施例に従う例の拡張されるＰＬＣＰヘッダー構造である。例示される拡張されるＰＬＣＰヘッダー１１００は、第１の拡張ヘッダー指標８０２、第１の拡張の長さ８０４、第１の拡張情報８０６、第１のフレームチェックシーケンス１１０２、および第１のティルビット１１０４を有する第１の拡張ヘッダーを含み得る。拡張ＰＬＣＰヘッダー１１００は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０、第２の拡張情報８１２、第２のフレームチェックシーケンス１１０６および第２のティルビット１１０８がある第２の拡張ヘッダーを含んでいる。拡張ＰＬＣＰヘッダー８１４は、拡張ヘッダーの後に位置して、さらにパッドビット８１４を含む。例示されるＰＬＣＰヘッダー１１００は、少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造はどんな数の拡張ヘッダーも含むことができた。
【００８７】
図８の拡張ＰＬＣＰヘッダー７０２および図１０の拡張ＰＬＣＰヘッダー１０００の両方と比較されるように例示される拡張されるＰＬＣＰヘッダー１１００は改善された誤り検出修正を提示してもよい。フレームチェックシーケンスおよび各拡張ヘッダーへのティルビットの追加は、特に拡張ヘッダーにおける誤りからの実際のフレームペイロードにおける誤りを分断してもよい。最初のフレームチェックシーケンス１１０２、第１のティルビット１１０４、第２のフレームチェックシーケンス１１０６および第２のティルビット１１０８だけは例示されるが、ＰＬＣＰヘッダー１１００へのより多くの拡張ヘッダーの追加は、より多くのフレームチェックシーケンスおよびティルビットの追加という結論になり得る。
【００８８】
図１２は、１つの実施例によってＰＣＬＰヘッダーを拡張する方法である。例示されるステップのすべてが必要だとは限らなく、この方法が発明の趣旨および範囲から外れずに修正されてもよいことが理解されるだろう。さらに、この方法は、さらに詳細に下に記述されるように、１台以上のプロセッサ、フォーマッタ、インタプリタ、メモリおよび／または他のデバイスを使用してインプリメントされ得る。送信デバイス（例えば１０２または１０６）の視点から見て描かれた例示された方法１２００は、１２００から開始する。続いて起こるステップ１２０２において、送信デバイスは、受信デバイス（例えば１０２または１０６）に送るために拡張ヘッダーを識別する。プロセッサ（例えば２００または３００）はこの識別を実行し得、また、識別された拡張ヘッダーは、メモリ（例えば２０４または３０４）の中にあってもよいかあるいは、有線ネットワークインターフェース（例えば３０８）のような別のソースからから来ることができる。
【００８９】
続いて起こる決定ステップ１２０６で、送信デバイス（例えば１０２または１０６）は、少なくとも１つの拡張ヘッダーを送らなければならないかどうか決定する。プロセッサ（例えば２００または３００）はこの決定を行ない得る。決定ステップへの答えがいいえである場合、方法１２００は詳細にさらに下に記述されるために決定ステップ１２２０に進む。
【００９０】
決定ステップ１２０６で質問への答えがはいである場合、方法１２００は、送信デバイス（例えば１０２または１０６）は次の拡張ヘッダーの長さを計算する１ステップ１２０８に移る。１つの実施例では、それがバイトでもたらされる別の実施例にいる間、この計算はビットで行われる。プロセッサ（例えば２００または３００）はこの計算を行ない得る。続いて起こる決定ステップ１２１０で、送信デバイスは、拡張ヘッダーが条件付きで送られるかどうか決定する。プロセッサ（例えば２００または３００）はメモリ（例えば２０４または３０４）を使用して、この決定を行ない得る。
【００９１】
決定ステップ１２１０で質問への答えがいいえである場合、方法１２００は１ステップ１２１２に移り、そこで、送信デバイス（例えば１０２または１０６）は構造に拡張ヘッダーを入れる。例えばプロセッサ（例えば２００または３００）および（または）メッセージフォーマッタ（例えば２０２または３０２）によって構造に拡張ヘッダーを入れることができるだろう。さらに、様々な位置でフレームに拡張ヘッダーを入れることができるだろう。例えば、図７に関して、ＰＳＤＵ４０６のパッドビット４１２に拡張ヘッダーを挿入することができるだろう。別の実施例において、拡張ヘッダーは、図６に関して上に記述されるように、拡張ヘッダーのデイジーチェーンを使用して、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードに入れられる。ステップ１２１２が終わった後、方法１２００は決定ステップ１２０６に返り、それは上に記述された。
【００９２】
決定ステップ１２１０で質問への答えがはいである場合、方法１２００は、送信デバイス（例えば１０２または１０６）は利用可能なパディングビット（例えば４１２）を計算する１ステップ１２１４に移る。プロセッサ（例えば２００または３００）はこの計算を行ない得る。
【００９３】
続いて起こる決定ステップ１２１６において、送信デバイスは、拡張ヘッダーの長さが利用可能なパディングビットより大きいかどうか決定する。送信デバイスは、この決定をなすためにプロセッサ（例えば２００または３００）あるいは様々な他のモジュールを使用し得る。質問への答えがいいえである場合、方法１２００はステップ１２１２に移り、それは上に記述された。
【００９４】
決定ステップ１２１６で質問への答えがはいである場合、方法１２００は、送信デバイスは拡張ヘッダーがフラグメント化されるかどうか決定する決定ステップ１２１８に移る。プロセッサ（例えば２００または３００）はメモリ（例えば２０４または３０４）を使用して、この決定を行ない得る。１つ以上の拡張ヘッダーをフラグメント化する過程は、図９に関して上に記述された。質問への答えがいいえである場合、方法１２００は詳細に後の下に記述されるように、決定ステップ１２２０に進む。
【００９５】
決定ステップ１２１８で質問への答えがはいである場合、方法１２００は、ステップ１２２２に進み、そこで、送信デバイスは、フレーム内に拡張ヘッダーのフラグメントをフレーム内に置く。プロセッサ（例えば２００または３００）および（または）メッセージフォーマッタ（例えば２０２または３０２）は、フレームに拡張ヘッダーのフラグメントを入れることができた。図７に関して上に記述されるように、拡張ヘッダーのフラグメントは、ＰＳＤＵ４０６のパッドビット４１２に挿入されることができるだろう。
【００９６】
ステップ１２２２を終えた後に、方法１２００は、保証ステップ１２２４に進み、そこで、送信デバイスはＦＣＳ（例えば１００２）、ティルビット（例えば１００４）、およびパッドビット（例えば１００６）を１つ以上の拡張ヘッダーのためにフレームに入れる。別の実施例では、拡張ヘッダー用のＦＣＳ、ティルビットおよび（または）パッドビットは、フレームに入れられなくてもよい。例えば、もし方法１２００が図８に例示されるヘッダー拡張構造を使用すれば、ＦＣＳとティルビットは挿入されないだろう。
【００９７】
更に、プロセッサ（例えば２００または３００）および／またはメッセージフォーマッタ（例えば２０２または３０２）は、構造にＦＣＳ、ティルビットおよびパッドビットを入れることができた。さらに、拡張ヘッダーおよびここでの拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットは、さまざまな位置でフレームに入れられることができるだろう。例えば、図７に関して、ＰＳＤＵ ４０６のパッドビット４１２に拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットに加えた拡張ヘッダーを挿入することができるかもしれない。別の実施例では、拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットは、図６に関して上に記述されるように、デイジーチェーン構造を使用して、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードに入れられてもよい。
【００９８】
ステップ１２２４が終わった後、方法１２００は、ＰＰＤＵあるいはフレーム構成（例えば４００）へ送信デバイスはどんな拡張ヘッダーも含むフレームペイロードを入れ、続いて起こるステップ１２２６に移る。実施例では、送信デバイスは、ＰＰＤＵおよび／またはフレーム構成（例えば４００）にＰＳＤＵのためのＦＣＳ、ティルビットおよびパッドビットを入れてもよい。フレームペイロードは、プロセッサ（例えば２００または３００）を使用して、および／またはメッセージフォーマッタ（例えば２０２または３０２）によってフレーム構成に入れられてもよい。ステップ１２２４を終えた後に、方法１２００は終了するステップ１２２８に移る。
【００９９】
決定ステップ１２２０で、送信デバイスは、少なくとも１つの拡張ヘッダーがフレームの中にあるかどうか決定する。プロセッサ（例えば２００または３００）はこの決定を行なってもよい。決定ステップへの答えがはいである場合、方法１２００はステップ１２２４に移る。それは上に記述された。決定ステップへの答えがいいえである場合、方法１２００はステップ１２２６に移る。それも上に記述された。
【０１００】
１つの実施例では、より短い媒体アクセス持続期間は通信システム２００に達成されてもよい。１つの実施例で、上に議論されるように、ＰＳＤＵ持続期間が拡張されてもよい場合、拡張ヘッダー要素の合計長さにＡが相当する場所は、挿入されることを望んだ。また、Ｐは与えられたＰＨＹデータレートで６つのＯＦＤＭシンボルの中の情報ビットの数に相当する。例えば、拡張ヘッダーを送信するための３つのシナリオ、拡張ヘッダーがＦＣＳなしで送信されるケースＡ、拡張ヘッダーが個別のＦＣＳおよびティルビットで送信されるケースＢ、および拡張ヘッダーが個別のＰＳＤＵとして送信されるケースＣがあり得る。Ｔは拡張ヘッダーのために最少アクセス持続期間を指す。この実施例では、Ｔ６ＳＹＭは、１．８７５ｕｓであり得る６つのＯＦＤＭシンボルの期間を指す。ケースＡおよびＢについては、期待される最少のアクセス持続期間は、方程式Ｅ（Ｔ）＝（Ｎ＋ｑ）＊Ｔ６ＳＹＭによって示され得て、ここで、Ｎは、拡張ヘッダーを送信するために必要だろう追加の６つのＯＦＤＭシンボル持続期間の数で、ｑは追加の６つのＯＦＤＭシンボル持続期間が必要とされる確率である。
【０１０１】
ケースＣについて、拡張ヘッダーが個別のＰＳＤＵのペイロードの中で送信されるので、短い相互フレームスペース（ｓｈｏｒｔ ｉｎｔｅｒ−ｆｒａｍｅ ｓｐａｃｅ：ＳＩＦＳ）は使用され得る。さらに、個別のＰＳＤＵは、さらに個別のプリアンブルおよび個別のヘッダーを使用し得る。したがって、個別のＰＳＤＵの中の拡張ヘッダーを送信する時間は方程式Ｔ＝ＴＳＩＦＳ＋ＴＰＲＥＡＭＢＬＥ＋ＴＰＬＣＰＨＥＡＤＥＲ＋ＴＰＡＹＬＯＡＤによって示され得て、ここで、ＴＳＩＦＳは、ＳＩＦＳのために時間を指し、ＴＰＲＥＡＭＢＬＥはプリアンブルを送信する時間を指す、ＴＰＬＣＰＨＥＡＤＥＲは、ＰＬＣＰヘッダーを送信する時間を指し、ＴＰＡＹＬＯＡＤは、ペイロードを送信する時間を指す。この実施例において、ＴＳＩＦＳ＝１０ｕｓ、ＴＰＲＥＡＭＢＬＥ＝９．３７５ｕｓおよびＴＰＬＣＰＨＥＡＤＥＲ＝３．７５ｕｓである。さらに、ＴＰＡＹＬＯＡＤ＝（Ｎ＋ｚ）＊Ｔ６ＳＹＭであり、Ａ ｍｏｄ Ｐが０である場合、ｚが０であり、そうでない場合ｚが１である（Ａは拡張ヘッダーの合計長さでありまた、Ｐは、与えられたデータレートであるＰＨＹレートための６つのＯＦＤＭシンボルの中の情報ビットの数である）。
【０１０２】
ケースＢおよびＣのための予期された媒体アクセス持続間の違いは、方程式ΔＴ＝ＴＳＩＦＳ＋ＴＰＲＥＡＭＢＬＥ＋ＴＰＬＣＰＨＥＡＤＥＲ＋（ｚ−ｑ）＊Ｔ６ＳＹＭによって示され得る。
【０１０３】
上に示されるように、ケースＡおよびＢのための媒体アクセス持続時間はケースＣのための媒体アクセス持続時間未満である。ケースＣにおいて、余分のオーバヘッドは、個別のＰＳＤＵのペイロード中の拡張ヘッダーデータの送信の結果として引き起こされ得る。しかしながら、ケースＡおよびＢにおいて、拡張ヘッダーデータは以前のパケットのパディングビットかペイロード内で適合し得る。したがって、個別のＰＳＤＵは、必然的に、ケースＡおよびＢのためのより短い媒体アクセス持続時間という結果にならないかもしれない。１つの実施例において、すべての場合のための媒体アクセス持続期間は、通信レートの１００のデータレートが増加するにつれて減少し得る。静的なオーバヘッドの無および／またはペイロードにおけるパッディングエリアの効率的な使用は、通信システム１００の媒体アクセス継続期間（例えば、効率を増加させる）を減少させ得る。
【０１０４】
「第１」、「第２」などのような指示をここに使用するエレメントへのどんな言及も、それらのエレメントの量や順番を一般的に限定しないことは理解されるに違いない。むしろ、これらの指示は、２つ以上のエレメントあるいはエレメントのインスタンスを識別する便利な方法としてここに使用され得る。したがって、第１と第２エレメントへの言及は、２つのエレメントだけがそこに使用されてもよいか、第１エレメントがある方法において第２のエレメントに先行するに違いないことを意味しない。また、そうでないと述べられない限り、１組のエレメントが１つ以上のエレメントを含み得る。説明または請求項において使用される「Ａ、Ｂ、またはＣの少なくとも１つ」は、「Ａ、またはＢまたはＣ、またはそれらのエレメントの組み合わせ」を意味する。
【０１０５】
実施例はここに示した実施例と他の実施例は、添付された付録にさらにより非常に詳しく記述される。明細書が本発明の特別の例について記述される一方、当業者は、発明概念から外れずに、本発明の変更を考案し得る。例えば、ここの教えは、回路切り換えネットワークエレメントを参照するが、パケット切り換え領域ネットワークエレメントに等しく適用可能である。
【０１０６】
当業者は、情報と信号が様々な異なる技術およびテクニックのうちのどれでも使用して表わされ得ると理解するだろう。例えば、上記の記述の全体にわたって参考され得るデータ、命令、コマンド、情報、信号、ビット、記号およびチップは、電圧、流れ、電磁波、磁界か、粒子、光学のフィールドあるいは光学粒子、または、それの任意の組合せによって表わされ得る。
【０１０７】
当業者は、ここで開示された例に関係して記載された、さまざまな例示の論理ブロックモジュール、回路、方法、アルゴリズムが、電子ハードウェア、コンピュータソフトウェアあるいは組合せとしてここにインプリメントされ得ことをさらに認識するだろう。ハードウェアおよびソフトウェアのこの交換性を明らかに示すために、様々な例示のコンポーネント、ブロック、モジュール、回路、方法およびアルゴリズムのこの互換性は、一般的にそれらの機能性という観点において、一般的に記載された。そのような機能性は、ハードウェアまたはソフトウェアとしてインプリメントされるかどうかは、全体のシステムに課された特定用途と設計制約に依存する。熟練技術者は。各特定用途の方法を変えることにおける記述された機能性をインプリメントしてもよい。しかし、そのようなインプリメンテーションの決定は本発明の範囲からの離れことを引き起こすと解釈されるべきでない。
【０１０８】
ここに示された例に関して記述された様々な実例となる論理ブロック、モジュール、および回路は、メインプロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、特定用途向けＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：ＦＰＧＡ）あるいは他のプログラマブル論理デバイス、個別のゲートかトランジスターロジック、個別のハードウェア構成機器あるいはそれのここに記述された機能を行なうことを目指した任意の組合せを用いてインプリメントされ、あるいは、実行され得る。汎用プロセッサは、マイクロプロセッサであり得るが、代わりに、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラあるいはステートマシンであり得る。プロセッサ、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと協動する１個以上のマイクロプロセッサあるいは他のそのような構成の組合せとしてインプリメントされ得る。
【０１０９】
ここに開示された例に関して記述された方法またはアルゴリズムは、ハードウェア、プロセッサによって実行されたソフトウェアモジュール、あるいは２つの組合せで直接具体化され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭ、あるいは当該技術において既知の記憶媒体の他の形式に存在し得る。記憶媒体は、プロセッサが記憶媒体から情報を読み、その記憶媒体に情報を書き込みし得るようにプロセッサにつながれ得る。代わりに、記憶媒体は、プロセッサに不可欠であり得る。プロセッサと記憶媒体はＡＳＩＣに存在し得る。
【０１１０】
１つ以上の典型的な実施例において、記述された機能は、ハードウェア、ソフトウェア、ファームウェアあるいはそれの任意の組合せにおいてインプリメントされ得る。もしソフトウェア中でインプリメントされる場合、機能は、１つ以上の命令あるいはコードとしてコンピュータ可読媒体上に記憶されあるいはそれを越えて送信され得る。コンピュータ可読媒体は、コンピュータ記憶媒体、およびある場所から別の場所へコンピュータプログラムの転送を促進するあらゆる媒体を含む通信媒体の両方を含む。記憶媒体はコンピュータによってアクセスされ得るあらゆる利用可能な媒体であり得る。制限ではなく例によって、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光学ディスク記憶装置、磁気ディスク記憶装置あるいは他の磁気記憶装置、あるいは、希望のプログラムコードを命令あるいはデータ構造の形式で格納するために使用され、コンピュータによってアクセスされ得る他の媒体を含み得る。さらに、接続はコンピュータ可読媒体を送信しかつ／または受信するために使用され得る。例えば、ソフトウェアは、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）あるいは赤外線、ラジオおよびマイクロ波のような無線技術を使用して、ウェブサイト、サーバーあるいは他の遠隔のソースから送信され得る。ここで使用されるようなディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、ディスク（ｄｉｓｋ）が通常磁気的にデータを再生する一方、ディスク（ｄｉｓｃ）がレーザーでデータを光学上再生する、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ：ＣＤ）、レーザーディスク（登録商標）、光ディスク、ディジタル・バーサタイル・ディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｄｃ：ＤＶＤ）、フロッピー（登録商標）ディスクおよびブルーレイディスクを含む。上記のものの組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【０１１１】
開示された例の以前の記載はどんな当業者も本発明を作るかあるいは使用することを可能にするために提供される。これらの例への様々な修正は、当業者に容易に明白になるだろう、また、ここに定義された総括的な原理は、発明の趣旨または範囲から外れずに、他の例に適用され得る。したがって、本発明は、ここに示された例に制限されたようには意図されないが、ここに示された原理と新規な特徴と一致する最も広い範囲を与えられることになっている。
【技術分野】
【０００１】
米国特許法第１１９条の下での優先権主張
この特許出願は、２００９年３月３日に出願され、譲受人にこれについて譲渡された「ＰＳＤＵ内の縮小拡大可能なヘッダー拡張（ＳＣＡＬＡＢＬＥ ＨＥＡＤＥＲ ＥＸＴＥＮＳＩＯＮ ＷＩＴＨＩＮ ＰＳＤＵ）」とタイトルをつけられ、明らかに参照によってここに組み込まれる米国仮出願第６１／１５７，１２６号に対する優先権を主張する。
【０００２】
本出願は、一般的には無線通信に関係し、より具体的には、無線通信でのパケットヘッダーを拡張する方法およびシステムに関係する。
【背景技術】
【０００３】
無線通信システムは、複数のユーザにさまざまなタイプの通信（例えば、音声、データ、マルチメディアサービスなど）を供給するために広く展開される。高レートおよびマルチメディアのデータサービスの需要が急速に増大するとともに、向上させられた実行を備えた効率的で強健な通信システムをインプリメントするという挑戦がある。
【発明の概要】
【０００４】
実施例において、無線通信システムにおける少なくとも１つの第１のパケットを送信するための通信デバイスは提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを含む。通信デバイスは、第１の拡張ヘッダーを格納するように構成されたメモリを含む。デバイスは、さらに、メモリと通信し、また、少なくとも１ビットが送信のための第１の拡張ヘッダーにおいて利用可能かどうか決定するように構成されたたプロセッサを有する。１ビットは、ヘッダーフィールドを占める複数のビットに追加可能である。デバイスは、さらに、プロセッサおよびメモリと通信し、ヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示し、第１のパケットのペイロードフィールドおよびパッディングフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成されるメッセージフォーマッタを備える。
【０００５】
別の実施例において、無線通信システムにおける少なくとも１つの第１のパケットを送信するための通信デバイスが提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを備える。通信デバイスは、第１の拡張ヘッダーを格納するための手段を備える。デバイスは、さらに、少なくとも１ビットが送信のための第１の拡張ヘッダーにおいて利用可能かどうか決定するための手段を備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加可能であり、また、決定するための手段は、格納するための手段と通信状態にある。デバイスは、ヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示すための、および第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入するための手段をさらに備える。示すためのおよび挿入するための手段は、格納するための手段または決定するための手段と通信し得る。
【０００６】
別の実施例において、無線通信システムにおける少なくとも１つの第１のパケットを通信する方法が提供される。第１のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを備える。方法は、第１の拡張ヘッダーを格納すること、および少なくとも１ビットが送信用の第１の拡張ヘッダーにおいて利用可能かどうか決定することを備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加的である。方法は、第１のパケットのヘッダーフィールドにおいて第１の拡張ヘッダーの存在を示し、第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入することをさらに備える。
【０００７】
別の実施例において、少なくとも１つのコンピュータ可読媒体を含むコンピュータ可読製品が提供される。少なくとも１ビットが送信用の第１の拡張ヘッダーにおいて利用可能な場合、コンピュータ可読製品は、コンピュータに少なくとも部分的に決定させるためのコードを備える。１ビットは、ヘッダーフィールドを占める複数のビットに追加的である。コンピュータ可読製品は、さらに、コンピュータに第１のパケットのヘッダーフィールドにおける第１の拡張ヘッダーの存在を示させ、第１のパケットのパッディングフィールドおよびペイロードフィールドの少なくとも１つに第１の拡張ヘッダーの少なくとも１つの部分を挿入させるためのコード（例えば、実行可能命令）を備える。
【図面の簡単な説明】
【０００８】
【図１Ａ】図１Ａは、第１の例の無線通信ネットワークを例示する。
【図１Ｂ】図１Ｂは、別の例の無線通信ネットワークを例示する。
【図２】図２は、図１Ａおよび図１Ｂの無線通信ネットワークで使用される例の無線通信デバイスの機能ブロック図である。
【図３】図３は、図１の無線通信ネットワークで使用される例のマクロノードの機能ブロック図である。
【図４】図４は、ＥＣＭＡ−３６８標準に対応する例のフレーム構造構成を例示する。
【図５】図５は、図４のフレーム構成のための物理層ビット割り当てを例示する。
【図６】図６は、実例となる実施例にしたがう例の拡張可能なヘッダー拡張構造である。
【図７】図７は、図６の拡張可能なヘッダー拡張構造に従った例の修正されるＥＣＭＡ−３６８フレーム構成を例示する。
【図８】図８は、第１の実施例に従う例の拡張されたＰＬＣＰヘッダー構造である。
【図９】図９は、図８の拡張されたＰＬＣＰヘッダー構造の拡張ヘッダー情報フィールドのための例のコーディングテーブルを例示する。
【図１０】図１０は、第２の実施例に従う例の拡張されたＰＬＣＰヘッダー構造である。
【図１１】図１１は、第３の実施例に従う拡張されたＰＬＣＰヘッダー構造である。
【図１２】図１２は、１つの実施例に従うＰＬＣＰヘッダーを拡張する方法である。
【詳細な説明】
【０００９】
「典型的である（ｅｘｅｍｐｌｙ）」という単語は、「例（ｅｘａｍｐｌｅ）、事例（ｉｎｓｔａｎｃｅ）、あるいは実例（ｉｌｌｕｓｔｒａｔｉｏｎ）として役立つ」ことを意味するためにここに使用される。「典型的である」とここに記載れたどんな実施例も、好まれるか、他の実施例上に有利として解釈されるべきでない。ここに記述された技術は、符号分割多重アクセス（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＣＤＭＡ）ネットワーク、時分割多元接続方式（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＴＤＭＡ）ネットワーク、周波数分割多重アクセス（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＦＤＭＡ）ネットワーク、直交ＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ ＦＤＭＡ：ＯＦＤＭＡ）ネットワーク、シングルキャリヤＦＤＭＡ（Ｓｉｎｇｌｅ−Ｃａｅｅｉｅｒ：ＳＣ−ＦＤＭＡ）ネットワークなどのような様々な無線通信ネットワークに使用され得る。「ネットワーク」および「システム」という用語は、しばしば交換的に使用される。ＣＤＭＡネットワークは、ユニバーサル・テレステアル・ラジオアクセス（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ：ＵＴＲＡ）、ＣＤＭＡ２０００などのようなラジオ技術をインプリメントし得る。ＵＴＲＡは広域ＣＤＭＡ（Ｗｉｄｅｂａｎｄ−ＣＤＭＡ：Ｗ−ＣＤＭＡ）および低チップレート（Ｌｏｗ Ｃｈｉｐ Ｒａｔｅ：ＬＣＲ）を含む。ＣＤＭＡ２０００は、ＩＳ−２０００、ＩＳ−９５、およびＩＳ−８５６標準をカバーする。ＴＤＭＡネットワークは、モービル通信のためのグローバルシステム（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：ＧＳＭ（登録商標））のようなラジオ技術をインプリメントし得る。ＯＦＤＭＡネットワークは、発展型ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＴＲＡ：Ｅ−ＵＴＲＡ）、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、フラッシュ−ＯＦＤＭＡ：Ｆｌａｓｈ−ＯＦＤＭＡ）などのようなラジオ技術をインプリメントし得る。ＵＴＲＡ、Ｅ−ＵＴＲＡおよびＧＳＭ（登録商標）は、ユニバーサル・モバイル・テレコミュニケーションシステム（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：ＵＭＴＳ）の一部である。ロングタームエボルーション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳの来たるリリースである。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＧＳＭ（登録商標）、ＵＭＴＳおよびＬＴＥは「第３世代パートナーシッププロジェクト（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ」：３ＧＰＰ）という名の組織からの文献に記述されティル。ＣＤＭＡ２０００は、「第３世代パートナーシッププロジェクト２」（（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ ２：３ＧＰＰ２）という名の組織からも文献に記述されている。これらのさまざまなラジオ技術および標準は、当該技術において知られている。
【００１０】
単一のキャリア変調および周波数領域等化を利用するシングルキャリヤ周波数分割多重アクセス（Ｓｉｎｇｌｅ−Ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ：ＳＣ−ＦＤＭＡ）は、技術である。ＳＣ−ＦＤＭＡは、同様の実行、および本質的にＯＦＤＭＡシステムのものと同じ実行および本質的に同じ全面的な複雑さを有している。ＳＣ−ＦＤＭＡ信号は、その固有の単一のキャリア構造のために、より低いピーク対平均電力の比率（ｐｅａｋ−ｔｏ−ａｖｅｒａｇｅ：ＰＡＰＲ）を持っている。ＳＣ−ＦＤＭＡは、より低いＰＡＰＲが送信電力効率の点からモバイル端末に非常に役立つアップリンク通信において特に大きな注意を引き寄せる。それは、現在、３ＧＰＰロングタームエボリューション（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：ＬＴＥ）、または、発展型ＵＴＲＡにおいてアップリンク多重アクセススキームのために作用する仮定である。
【００１１】
いくつかの態様において、ここでの示唆は、マクロ規模のカバー範囲（例えば、典型的には、マクロセルネットワークとして言われている第３世代（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ：３Ｇ）ネットワークのような大規模エリアセルラーネットワーク）およびより書規模なカバー範囲（住宅ベースまたはビルディングベースのネットワーク環境）を含むネットワークにおいて使用され得る。無線通信デバイスがそのようなネットワークを通って移動するとので、無線通信デバイスは、マクロのカバー範囲を提供するアクセスノードによってある一でサービスされ得る一方、無線通信デバイスは、より小規模のカバー範囲を提供するアクセスノードによって他の位置でサービスされ得る。いくつかの態様において、より小さなカバー範囲のノードは、増加する容量の増大、ビルディング内のカバー範囲、および異なるサービスを（例えばより多くの強固なユーザ経験のために）提供するために使用されてもよい。ここでの議論において、比較的広いエリアにわたるカバー範囲を提供するノードは、マクロノードと呼ばれ得る。
【００１２】
図１Ａは、第１の例の無線通信ネットワーク１００を例示する。例示される無線通信ネットワークは、マクロノード１０２、セル１０４、無線通信デバイス１０６、および無線通信デバイス１０８を含む。無線通信ネットワーク１００は、多くのユーザ間の通信を支援するように構成される。無線通信ネットワーク１００は、たった１つのセル１０４を含んでいるように例示されるが、無線通信ネットワークはどんな数のセルを含み得る。セル１０４の通信のカバー範囲は、マクロノード１０２によって提供され、それは、例えば基地局を備え得る。マクロのノード２０３は複数の無線通信デバイス、例えば、無線通信デバイス１０６および１０８と対話し得る。
【００１３】
無線通信デバイスの各々は、与えられた瞬間でフォワードリンク（ｆｏｒｗａｒｄ ｌｉｎｋ：ＦＬ）および／またはリバースリンク（ｒｅｖｅｒｓｅ ｌｉｎｋ：ＲＬ）上のマクロノード１０２と通信し得る。ＦＬは、マクロノードから無線通信デバイスまで通信リンクである。ＲＬは、無線通信デバイスからマクロノードまで通信リンクである。マクロノード１０２は、例えば、適切な有線あるいは無線のインタフェースによって、他のセル（この図の中で示されない）のマクロノードに例えば相互連結され得る。従って、マクロノード１０２は、他のセル（この図の中で示されない）の無線通信デバイスと通信し得る。
【００１４】
図１Ａへの継続的な参照で、セル１０４は、田舎の環境における数マイル平方あるいは近傍の内のほんの少数のブロックをカバーし得る。各セルは、さらに、１つ以上のセクター（この図の中で示されない）へ分割され得る。追加のセルを含んでいることによって、技術において有名なように、無線通信ネットワーク１００は大きな地理的な地域上のサービスを提供してもよい。
【００１５】
無線通信デバイス（例えば、１０６）は、通信ネットワークを通して音声あるいはデータを送信し受信するためにユーザによって使用される無線通信デバイス（例えば、携帯電話、ルータ、パーソナルコンピュータ、サーバーなど）であり得る。アクセスターミナル（ＡＴ）もユーザ設備（ＵＥ）、移動局（ＭＳ）、あるいは端末デバイスとここに呼ばれてもよいとともに、無線通信デバイスは引用されてもよい。示されるように、無線通信デバイス１０６および１０８は、携帯電話を備え得る。しかしながら、無線通信デバイスは、どんな適切な通信デバイスも含み得る。
【００１６】
無線通信デバイス１０８あるいは別のセルにおける無線通信デバイス（この図の中で示されない）のような別の無線通信デバイスに情報を送信し、そこから情報を受信することは、無線通信デバイス１０８あるいは別の無線通信デバイスは送信情報に無線通信デバイス（例えば１０６）には望ましいことであり得る。無線通信デバイス１０６は、無線リンクによってマクロのノード１０２と最初に通信することにより、これを遂行してもよい。例えば、無線通信デバイス１０６は、マクロノード１０２へのメッセージを生成し送信し得る。そして、マクロノード１０２は、無線通信デバイス１０８のような別の無線通信デバイスへメッセージを生成し送信し得る。メッセージは、様々なタイプの通信（例えば、音声、データ、マルチメディアサービスなど）と関係する情報を備え、図４−１３に関して詳細に以下で議論されるように、１つ以上の拡張ヘッダーがあるパケットを含み得る。
【００１７】
図１Ｂは、別の例の無線通信ネットワーク２００を例示する。例示された無線通信ネットワーク２００は、無線通信デバイス１０６、第２の無線通信デバイス２１０、第３の無線通信デバイス２２０、および第４の無線通信デバイス２３０を含む。無線通信ネットワーク２００は、無線通信デバイス１０６、２１０、２２０および２３０のような多くのデバイスの間の通信を支援するように構成され得る。無線通信デバイス（例えば、２１０と２２０）は、例えば、パーソナルコンピュータ、ＰＤＡ、音楽プレーヤー、ビデオプレーヤー、マルチメディアプレーヤー、テレビ、電子ゲームシステム、ディジタルカメラ、ビデオカムコーダー（ｃａｍｃｏｒｄｅｒ）、時計、リモートコントロール、ヘッドセット、などを備え得る。無線通信デバイス１０６は、両方の図１および２に例証されるが、無線通信デバイス１０６は、図１Ａの無線通信ネットワーク１００および無線通信ネットワーク２００と同時に通信する必要がない。
【００１８】
図１Ｂへの継続的な参照で、無線通信デバイス１０６は、さまざまな通信チャンネル上に他の無線通信デバイス（例えば２１０と２２０）と通信し得る。通信チャンネルは、技術において知られティルように、ウルトラ広域帯域（Ｕｌｔｒａ−Ｗｉｄｅ Ｂａｎｄ：ＵＷＢ）チャネル、ブルーツース（Ｂｌｕｅｔｏｏｔｈ（登録商標））チャネル、８０２．１１のチャネル（例えば８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ）、赤外線（ＩＲ）チャネル、ジッグビー（ＺｉｇＢｅｅ）（８０２．１５）チャネルあるいは、様々な他のチャネルを含み得る。１つの実施例では、チャネルは、ＥＣＭＡ−３６８標準に一致するＵＷＢチャネルであり得る。
【００１９】
無線通信ネットワーク２００は、家庭、オフィス、あるいは一グループのビルディングのように、物理的なエリアをカバーする無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＬＡＮ）を含み得る。ＷＬＡＮは、８０２．１１基準（例えば８０２．１１ｇ）、および／または無線通信のための他の基準のような基準を使用し得る。ＷＬＡＮは、無線通信デバイスが互いと直接通信するピアツーピア通信を使用し得る。無線通信ネットワーク２００は、さらに、例えば、数メーターのエリアをまたがる、無線パーソナルネットワーク（ｗｉｒｅｌｅｓｓ ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ：ＷＰＡＮ）を含み得る。ＷＰＡＮは、赤外線、ブルーツース（Ｂｌｕｅｔｏｏｔｈ（登録商標））、ウィメディア（ＷｉＭｅｄｉａ）ベースのＵＷＢ標準（例えば、ＥＣＭＡ−３６８）、ジッグビー（ＺｉｇＢｅｅ）標準、および／または無線通信の他の標準のような基準を使用し得る。ＷＰＡＮは、無線通信デバイスが互いと直接通信するピアツーピア通信を使用し得る。無線通信ネットワーク２００が、無線通信デバイス１０６のようなデバイスを通して、無線通信ネットワーク１００またはインターネットのような他のネットワークに接続し得る。
【００２０】
無線通信ネットワーク２００を横切って送信されたメッセージは、さまざまなタイプの通信（例えば音声、データ、マルチメディアサービスなど）と関係する情報を備え、図４−１２に関して詳細に以下に議論されるように、１つ以上の拡張ヘッダーを有するパケットを含み得る。
【００２１】
次の実施例は、図１Ｂおよび特にＥＣＭＡ−３６８標準を参照し得る、それらは、また、図１Ａにおいて示される通信システム１００および他の通信標準に適用可能であり得る。例えば、１つの実施例はＵＭＴＳ通信システムにおいて適用可能であり得る。別の実施例は、ＯＦＤＭＡ通信システムにおいて適用可能であり得る。いくつかの実施例は、ある無線通信デバイスから別の無線通信デバイスにデータを送信する場合、パディングビットを使用するあらゆる通信システムに適用され得る。一般に、パディングビットは、ある長さにフレームを「詰めこむ（ｐａｄ）」ために使用される、フレーム（例えば、通信システムによって使用されるデータの１単位）内のビットである。例えば、通信システム２００は、無線通信デバイス（例えば１０６と２２０）間で送られたフレームがすべて長さ２５６ビットであることを必要とし得る。無線通信デバイス１０６が１フレームにおいて送るために単に１２８ビットのデータを持っている場合に、無線通信デバイス１０６は、フレームの合計長さが２５６のビット長の必要を満たすようにフレームの残りを満たすために１２８のパディングビットを使用し得る。
【００２２】
ＥＣＭＡ−３６８標準は、ウルトラ広帯域（ＵＷＢ）通信システムのための物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ：ＰＨＹ）および媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ：ＭＡＣ）副層を特定する。例えば、ＥＣＭＡ−３６８標準は高速短距離無線ネットワークにおいて使用され得る。ＥＣＭＡ−３６８標準は、３１００〜１０，６００ＭＨｚの間の周波数スペクトルのすべてあるいは部分を使用し得て、また４８０Ｍｂ／ｓまでのデータレートをサポートし得る。ＥＣＭＡ−３６８標準は、各々５２８ＭＨｚの帯域幅でスペクトルを１４の帯域に分割する。ＥＣＭＡ−３６８標準は、送信情報にマルチバンド直交周波数分割変調（ＭＢ−ＯＦＤＭ）スキームを使用し得る。周波数領域拡張、時間領域拡張、および順方向誤り修正（ｆｏｒｗｏｒｄ ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ：ＦＥＣ）符号化は、さまざまなチャネル条件の下で最適な実行に提供される。
【００２３】
ＥＣＭＡ−３６８標準のＭＡＣ副層は、他のグループに合併したり他のグループから別れたりしながら、グループのデバイスに継続的な通信を可能にし得る。このＭＡＣの機能性は、多数のデバイスに分配され得るこれらの機能は、チャネルの適切な使用によって異なるグループのデバイスの間での干渉を避けるための分配された調整およびサービスの質を保証するための分配された媒体の確保を含む。ＥＣＭＡ−３６８のＭＡＣ副層は、等時性のデータ転送および非同期のデータ転送ための優先的にされたスキームを提供し得る。これをするために、ＥＣＭＡ３６８標準は、キャリヤーセンス多重アクセス（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＣＳＭＡ）あるいは時分割多元接続方式（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：ＴＤＭＡ）のうちの１つを使用してもよい。ＥＣＭＡ−３６８標準のＭＡＣ副層は、帯域幅の公正な共有を保証し得る。
【００２４】
図２は、図１Ａと１Ｂの中で示される例の無線通信デバイス１０６の機能ブロック図である。上に議論されるように、無線通信デバイス１０６は携帯電話であり得る。無線通信デバイス１０６は、記憶、送信、および／または無線通信デバイス１０６の他のコンポーネントのコントロールのための情報を処理するように構成されたプロセッサ２００を含み得る。プロセッサ２００は、さらに、メモリ２０４にさらにつながれ得る。プロセッサは、メモリ２０４から情報を読み出しあるいはメモリ２０４に情報を書み得る。メモリ２０４は、処理の前に、処理中に、あるいは処理後後にメッセージを格納するように構成され得る。メモリ２０４は、さらに、拡張ヘッダーデータおよび／または図６−１２を参照して、さらに詳細に以下に議論されるとともに拡張ヘッダーを有する１つ以上のパケットを格納し得る。プロセッサ２００、また、無線ネットワークインターフェース２０８につながれ得る。無線ネットワークインターフェース２０８は、内部行きの無線メッセージを受け取り、またマクロノード（例えば１０２）および／または別の無線通信デバイス（例えば２２０）に外部行きの無線電信を送信するように構成され得る。内部行きの無線メッセージは、処理用のプロセッサ２００に渡され得る。プロセッサ２００は、１つ以上の拡張ヘッダーを有するパケットを処理し得る。
【００２５】
プロセッサ２００は、外部行きの無線メッセージの送信のための無線ネットワークインターフェース２０８へ渡す外部行きの無線メッセージを処理し得る。さらに、プロセッサ２００は、図１２に関して詳細に下に議論されるように、送るための拡張ヘッダーを識別し、メッセージにそれらを含み得る。プロセッサ２００は、また、メッセージインタプリタ２０６につながれ得る。マクロのノード１０２および／または別の無線通信デバイス（例えば２２０）から無線ネットワークインターフェース２０８で受信された内部行きの無線メッセージは、プロセッサ２００に渡され、追加の処理のためのメッセージインタプリタ２０６へのプロセッサ２００によって渡され得る。メッセージインタプリタ２０６は、メッセージ解釈での使用を、情報を格納するか検索するためにメモリ２０４につながれ得る。メッセージインタプリタ２０６は、１つ以上の拡張ヘッダーを有するパケットを解釈してもよい。図９および１２に関して下記に述べられた１つの実施例では、メッセージインタプリタ２０６は、１つ以上の分解された拡張ヘッダーを処理し得る。
【００２６】
プロセッサ２００は、また、メッセージフォーマッタ２０２につながれ得る。メッセージフォーマッタ２０２は、ワイヤレスネットワークインターフェース２０８によって送信される外部行きの無線メッセージを生成しあるいはフォーマットし得る。無線の外部行きのメッセージは、マクロノード（例えば１０２）および／または別の無線通信デバイス（例えば２２０）への無線ネットワークインターフェース２０８による送信のためのプロセッサ２００へメッセージフォーマッタ２０２によって渡され得る。メッセージフォーマッタ２０２は、メッセージフォーマットでの使用に対して情報を格納するか検索するためにメモリ２０４に直接つながれ得る。図６−１２に関して詳細に以下に記述されるように、メッセージフォーマッタ２０２は、拡張ヘッダーあるいは拡張ヘッダーフレームチェックシーケンス、１つ以上のパケットの中へティルビットあるいはパッドビットを挿入し得る。
【００２７】
無線ネットワークインターフェース２０８は、アンテナとトランシーバを含み得る。トランシーバは、マクロのノード１０２および／または別の無線通信デバイス（例えば２２０）に行くかそれから来る外部行きの／内部行きの無線メッセージを変調／復調するように構成され得る。アンテナは、外部行きの／内部行きの無線メッセージを送信／受信し得る。アンテナは、１つ以上のチャネル上のマクロノード１０２と通信するように構成され得る。外部行きの／内部行きの無線メッセージは、音声および／またはデータのみの情報（ひとまとめにして、ここで「データ」と呼ばれる）を備え得る。ワイヤレスネットワークインターフェース２０８は、受信されるデータを復調し得る。無線ネットワークインターフェース２０８は、無線ネットワークインターフェース２０８経由で無線通信デバイス１０６から送信されるデータを変調し得る。プロセッサ２００は、送信されるデータを提供し得る。
【００２８】
メモリ２０４は、異なるレベルが異なる容量およびアクセス速度を持っている多重レベルの階層的なキャッシュを含むプロセッサキャッシュを備え得る。メモリ２０４は、さらにランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ＲＡＭ）、他の揮発性記憶デバイスあるいは不揮発性記憶素子を含み得る。記憶装置は、ハードドライブ、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ：ＣＤ）あるいはディジタルビデオディスク（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｃ：ＤＶＤ）のような光ディスク、フラッシュメモリ、フロッピー（登録商標）ディスク、磁気テープおよびジップ・ドライブを含み得る。
【００２９】
別々に記述されたが、無線通信デバイス１０６に関して記述された機能的ブロックが、個別の構造エレメントである必要がないことは認識されるべきである。例えば、プロセッサ２００およびメモリ２０４は、シングルチップで具体化されてもよい。プロセッサ２００は、さらに、あるいは代わりに、プロセッサレジスタのようなメモリをみ得る。同様に、機能ブロックの１つ以上またはさまざまなブロックの一部は、シングルチップで具体化され得る。あるいは、特定のブロックの機能性は、２つ以上のチップ上でインプリメントされてもよい。
【００３０】
プロセッサ２００、メッセージインタプリタ２０６およびメッセージフォーマッタ２０２のような無線通信デバイス１０６に関して記述された機能的ブロックの１つ以上の機能的ブロックおよび／または１つ以上の組合せの１つ以上は、汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、特定用途向けＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：ＦＰＧＡ）あるいは他のプログラマブルロジックデバイス、個別のゲートかトランジスターロジック、個別のハードウェアコンポーネントあるいはここに記述された機能を実行することを設計されるそれの任意の適切な組合せとして具体化され得る。無線通信デバイス１０６に関して記述された機能ブロックの１つ以上および／または機能的ブロックの１つ以上の組合せの１つ以上は、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰ通信と協力する１個以上のマイクロプロセッサ、あるいは他のそのような構成としてインプリメントされ得る。
【００３１】
図３は、図１Ａの中で示される例のマクロノード１０２の機能ブロック図である。図１Ａに関して上に議論されるように、マクロノード１０２は基地局であり得る。マクロのノード１０２は、内部行きの無線メッセージを受信し、無線通信デバイス１０６のような１つ以上の無線通信デバイスに外部行きの無線メッセージを送信するように構成された無線ネットワークインターフェース３０８を備え得る。無線ネットワークインターフェース３１０は、プロセッサ３００につながれ得る。プロセッサ３００は、ンターフェース３１０経由で無線通信デバイス１０６から来るまた行く内部行き・外部行きの無線メッセージを処理するように構成され得る。プロセッサ３００は、１つ以上の拡張ヘッダーを有するパケットを処理し得る。
【００３２】
プロセッサ３００は、また、マクロノード１０２の他のコンポーネントをコントロールするように構成され得る。プロセッサ３００は、さらに、有線ネットワークインターフェース３０８につながれ得る。有線ネットワークインターフェース３０８は、内部行きの有線メッセージを受信し、また他の目的地（例えば他のマクロのノードおよび／または無線通信デバイスへの外部行きの有線メッセージを送信するように構成され得る。有線ネットワークインターフェース３０８は、内部行きの有線メッセージを受信し、内部行きの有線メッセージを処理用のプロセッサ３００へ渡し得る。プロセッサ３００は、外部行きの有線メッセージを処理し、外部行きの有線メッセージを送信のために有線ネットワークインターフェース３０８へ渡し得る。
【００３３】
プロセッサ３００は、さらにメモリ３０４に、１つ以上のバスによってつながれ得る。プロセッサ３００は、メモリ３０４から情報を読み出し、あるいはメモリ３０４に情報を書き込み得る。メモリ３０４は、内部行きあるいは外部行きの有線あるいは無線のメッセージを処理することにおける使用のために情報を格納するように構成され得る。メモリ３０４はさらに、図６−１２に関して一層に詳細に下に議論されるように、拡張ヘッダーデータ拡張ヘッダーを有する１つ以上のパケットを格納し得る。プロセッサ３００は、また、メッセージインタプリタ３０６につながれ得る。プロセッサは、処理のためにメッセージインタプリタ３０６へ内部行きの有線および無線のメッセージを渡し得る。メッセージインタプリタ３０６は、１つ以上の拡張ヘッダーを有するパケットを解釈し得る。図９および１２に関して下記に述べられた１つの実施例では、メッセージインタプリタ３０６は、１つ以上の分離された拡張ヘッダーを処理し得る。
【００３４】
メッセージインタプリタ３０６は、無線ネットワークインターフェース３１０で受信された内部行きの無線メッセージから情報を抽出するように構成され得る。例えば、無線通信デバイスから受信される内部行きの無線メッセージは、パッケージ拡張ヘッダーを含み得る。メッセージインタプリタ３０６は、無線通信デバイスによって提供される内部行きの無線メッセージからパッケージ拡張ヘッダーを抽出し得る。メッセージインタプリタ３０６は、追加の処理用のプロセッサ３００へこの識別情報を渡し得る。別の例において、メッセージインタプリタ３０６は、内部行きの無線メッセージを処理し、かつ追加情報を要求することにより内部行きの無線メッセージに応答するための情報をプロセッサに３００を供給するように構成され得る。メッセージインタプリタ３０６は、また、メッセージ解釈での使用についての情報を格納するか検索するためにメモリ３０４に直接つながれ得る。
【００３５】
プロセッサ３００は、また、メッセージフォーマッタ３０２につながれ得る。メッセージフォーマッタ３０２は、外部行きの有線または無線のメッセージを生成するように構成され得る。メッセージフォーマッタ３０２は、さらに、生成された外部行きの有線あるいは無線のメッセージをプロセッサ３００へ渡すように構成され得る。図６−１２に関して詳細に以下に記述されるように、メッセージフォーマッタ２０２は、１つ以上のパケットへ、拡張ヘッダーあるいは拡張ヘッダーフレームチェックシーケンス、ティルビットあるいはパッドビットを挿入し得る。
【００３６】
プロセッサ３００は、送信のための有線ネットワークインターフェース３０８あるいは無線ネットワークインターフェース３１０へ外部行きの有線あるいは無線のメッセージを渡し得る。さらに、プロセッサ３００は、図１２に関して詳細に下に議論されるように、送るために拡張ヘッダーを識別し、メッセージにそれらを含み得る。有線ネットワークインターフェース３０８は、別のマクロノードへの外部行きの有線メッセージを送信し得る。メッセージフォーマッタ３０２は、プロセッサ３００へ外部行きの無線メッセージを渡し得る。プロセッサ３００は、無線通信デバイス１０６への送信のための無線ネットワークインターフェース３１０への外部行きの無線メッセージを渡し得る。メッセージフォーマッタ３０２は、また、メッセージフォーマットでの使用に対する情報を格納するか検索するためにメモリ３０４に直接つながれ得る。
【００３７】
無線ネットワークインターフェース３１０は、アンテナとトランシーバを含み得る。トランシーバは、無線通信デバイスに行くかそこから来る外部行きの／内部行きの無線メッセージを変調／復調するように構成され得る。アンテナは、内部行きの／外部行きの無線メッセージを送信／受信し得る。アンテナは、１つ以上のチャネル上のマクロノード１０２から外部行きの／内部行きの無線メッセージを送信しおよび／または受信するように構成され得る。外部行きの／内部行きの無線メッセージは、音声および／またはデータのみの情報／（まとめてここに「データ」と呼ばれる）を含み、拡張ヘッダーがある１つ以上のパケットを含み得る。無線ネットワークインターフェース３１０は、受信されるデータを復調し得る。無線ネットワークインターフェース３１０は、無線ネットワークインターフェース３１０経由でマクロノード１０２から送信されるデータを変調し得る。プロセッサ３００は、送信されるデータを提供し得る。
【００３８】
有線ネットワークインターフェース３０８は、モデムを含み得る。モデムは、別のマクロのノードのような別の目的地／リソースへ行くかそこから来る外部行きの／内部行きの有線メッセージを変調／復調するように構成され得る。有線ネットワークインターフェース３０８は、技術において既知の方法を使用する１つ以上の有線の標準に従って受信されるデータを復調し得る。復調されるデータは、プロセッサ３００に送信され得る。有線ネットワークインターフェース３０８は、技術において既知の方法を使用する１つ以上の有線の標準に従って有線ネットワークインターフェース３０８経由でマクロノード１０２から送信されるデータを変調し得る。プロセッサ３００は、送信されるデータを提供し得る。
【００３９】
メモリ３０４は、異なるレベルが異なる容量およびアクセス速度を持っている多重レベル階層的キャッシュを含むプロセッサキャッシュを備え得る。メモリ３０４は、さらにランダムアクセスメモリ（ＲＡＭ）、他の揮発性記憶デバイスあるいは不揮発性記憶素子を含み得る。記憶装置は、ハードドライブ、コンパクトディスク（ＣＤ）あるいはディジタルビデオディスク（ＤＶＤ）のような光ディスク、フラッシュメモリ、フロッピー（登録商標）ディスク、磁気テープ、およびジップ・ドライブを含み得る。
【００４０】
別々に記述されたが、マクロノード１０２に関して記述された機能的ブロックが個別の構造エレメントである必要がないことは認識されるべきである。例えば、プロセッサ３００およびメモリ３０４は、シングルチップで具体化され得る。プロセッサ３００は、さらに、あるいは代わりに、プロセッサレジスタのようなメモリを含み得る。同様に、１つ以上の機能ブロックあるいはさまざまなブロックの機能性の部分は、シングルチップで具体化されてもよい。代わりに、特有のブロックの機能性は２つ以上のチップ上でインプリメントされ得る。
【００４１】
１つ以上の機能的ブロックおよび／またはプロセッサ３００、プロセッサ３００、メッセージインタプリタ３０６およびメッセージフォーマッタ３０２のようなマクロのノード１０２に関して記述された機能的ブロックの１つ以上の組合せは、メインプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）あるいは他のプログラマブルロジックデバイス、個別のゲートかトランジスターロジック、個別のハードウェアコンポーネントあるいはここに記述された機能を実行するよう設計されるそれらの任意の適切な組合せとして具体化され得る。１つ以上の機能的ブロックおよび／またはマクロノード１０２に関して記述された機能的ブロックの組合せは、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰ通信に協働する１個以上のマイクロプロセッサあるいは他のそのような構成としてインプリメントされ得る。
【００４２】
図２−３のモジュールの機能性は、示唆と一致するさまざまな方法でここにインプリメントされ得る。いくつかの態様において、これらのモジュールの機能性は１つ以上の電気コンポーネントとしてインプリメントされ得る。いくつかの態様において、これらのブロックの機能性は１つ以上のプロセッサコンポーネントを含む処理システムとしてインプリメントされ得る。いくつかの態様において、これらのモジュールの機能性は、例えば、１つ以上の集積回路（例えばＡＳＩＣ）の少なくとも１つの部分を使用してインプリメントされ得る。ここに議論されるように、集積回路は、プロセッサ、ソフトウェア、他の関連するコンポーネント、あるいはそれのある組合せを含み得る。これらのモジュールの機能性は、さらに、ここで示唆されるような他のある方法でインプリメントされ得る。ここに記述された機能性（例えば、１つ以上の添付の図に関して）は、いくつかの態様において、添付された請求項における同様に指定された「のための手段」という機能性に一致し得る。図１−３を参照すると、マクロノード１０２および無線通信デバイス１０６は、一連の相互関係がある機能モジュールとして表わされる。
【００４３】
図４は、ＥＣＭＡ−３６８標準に一致する例のフレーム構造を例示する。物理層収束プロトコル（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ：ＰＬＣＰ）のプロトコルデータ単位あるいはＰＰＤＵあるいはフレーム構造４００は、ＰＬＣＰプリアンブル４０２、ＰＬＣＰヘッダー４０４、および物理層サービスデータ単位、あるいはＰＳＤＵ ４０６を備える。ＥＣＭＡ−３６８標準は、無線通信ネットワーク（例えば１００）をサポートするために超広帯域の物理（ｐｈｙｓｉｃａｌ：ＰＨＹ）層および媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ：ＭＡＣ）副層を定義する。したがって、１つの実施例では、無線通信デバイス（例えば１０６）は、内部行きの無線メッセージを受信し、また、ＥＣＭＡ−３６８標準を使用して、１つ以上の他の無線通信デバイス（例えば２１０、２２０、および２３０）に外部行きの無線メッセージを送信するように構成された例えば、無線ネットワークインターフェース（例えば、２０８）および／またはプロセッサ（例えば、２００）を有し得る。ＰＳＤＵ４０６は、無線通信デバイス（例えば１０６）および別の無線通信デバイス（例えば２２０）から遅れるパケットに含まれていたさまざまなタイプの通信（例えば音声、データ、マルチメディアサービスなど）と関係するデータのビットを含み得る。無線通信ネットワーク２００はＥＣＭＡ−３６８標準を利用し得るが、この選択が単に実例であり、また図６−１３に関して下記に述べられた実施例は、さまざまな標準を利用する通信ネットワークに適用可能であることが理解されるだろう。
【００４４】
図４に例証されるように、ＰＳＤＵ４０６はフレームペイロード４１０、フレームチェックシーケンス、ティルビットおよびパッドビット４１２を含む。フレームペイロード４１０は、無線通信デバイス（例えば、１０６）へまたはその無線通信デバイスから他の無線通信デバイス（例えば、２２０）に送られるパケットに含まれティルさまざまなタイプの通信（例えば、音声、データ、マルチメディアサービスなど）と関係するデータのビットを備え得る。フレームチェックシーケンスは、フレームが誤り検出修正を援助するためにチェックサム文字を提供する。無線ネットワークインターフェース（例えば、２０８または３０８）が畳込み復号器を含んでいる実施例では、ティルビットは、それをその初期状態にリセットし、かつ誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ＥＣＭＡ−３６８標準は、ビット・ストリームがバースト誤りに対する頑強性を提供するために変調に先立ってインターリーブされることを規定した。従って、標準は、パッドビット４１２がＰＳＤＵ４０６がインタリーバの境界上で整列することを保証することを規定する。
【００４５】
図４への持続的な参照で、ＰＬＣＰプリアンブル４０２はタイミング同期、キャリアに相殺された回復およびチャネル推定で無線ネットワークインターフェース（例えば２０８または３０８）を援助し得る。ＥＣＭＡ−３６８標準におけるＰＬＣＰプリアンブル４０２は、チャネル推定シーケンスが後続するパケット／フレーム同期シーケンスから成る。
【００４６】
ＰＬＣＰヘッダー４０４はＰＳＤＵ４０６のデコードで使用するために無線ネットワークインターフェース（例えば２０８または３０８）へ情報を伝えてもよい。図４に例示されるように、ＰＬＣＰヘッダー４０４は、ティルビットのＰＨＹヘッダー４０８、ＭＡＣヘッダー、ヘッダーチェックシーケンス、リード−ソロモンパリティバイトおよび３つのフィールドを含む。ＰＨＹヘッダー４０８は、図５に関して詳細に下に議論されるだろう。ヘッダーチェックシーケンスおよびリード−ソロモンパリティバイトはＰＬＣＰヘッダー４０４に対して改善された誤り検出訂正を提供する。さらに、無線ネットワークインターフェースが畳込み復号器を含んでいる実施例では、ティルビットはそれをその初期状態にリセットし、かつ誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ＥＣＭＡ−３６８標準では、ＭＡＣヘッダーは、伝送エラーの可能性を減少させるために送信に先立ってヘッダーチェックシーケンスでスクランブルがかけられる。
【００４７】
図５は、図４のフレーム構成のためのＰＨＹヘッダービット割り当てを例示する。ＰＨＹヘッダー４０８は、長さフィールド５０６を含み、それは、フレームチェックサム、ティルビットあるいはパッドビットを含まない、フレームペイロード（例えば４１０）の長さを示す。ＰＨＹヘッダー４０８はさらに確保されるビットを含んでいる。これらのビットは、ＥＣＭＡ−３６８標準中で将来の使用のために確保され、現在の標準中で０にセットされる。実例のみの目的のために、ＰＨＹヘッダー４０８は最初の予約のフィールド５０２および別の予約のフィールド５０４を含んでいる。
【００４８】
下記に述べられるように、第１の確保されるフィールド５０２および第２の確保されるフィールド５０４は１つ以上の実施例の中で使用され得る。１つの実施例において、図６−１３に詳細に下記に述べられるように、第１の確保されるフィールド５０２は１つ以上の拡張ヘッダーの存在および内容を示すために使用される。別の実施例において、第２の確保されるフィールド５０４は、送信器（例えば、２０８または３０８）および受信機（例えば、２０８または３０８）をＣＳＩに関して同期するよう維持するために使用される。特に、ＰＬＣＰヘッダー４０４の第２の確保されるフィールド５０４の中で現在のＰＳＤＵ送信に使用されティル拡張ヘッダーのバージョン番号があり得る。連続のフィードバックの間隔は、バージョン番号が８つのフィードバックの後に折り返す場合に問題がないだろうということを保証する。上に記述された実施例は第１の確保されるフィールド５０２および第２の確保されるフィールド５０４のコンテキスト中で例示されるが、記述された実施例は予約のビットのうちのどれにも適用可能である。
【００４９】
図４のＰＬＣＰヘッダー４０４はＰＨＹとＭＡＣヘッダーの両方を含んでいる。図６−１３に関して下記に述べられた実施例は、ＥＣＭＡ−３６８およびＥＣＭＡ−３８７標準におけるように共通のＰＨＹヘッダーおよびＭＡＣヘッダーを有するフレーム構成に適用可能であるが、実施例は、また、ＰＨＹヘッダー拡張に利用可能な限られた数の確保されるビットを備えたものを含むさまざまなフレーム構造に適用可能である。別の実施例は、さらに通信システムおよび／または個別のＰＨＹおよびＭＡＣヘッダー（例えば８０２．１１の標準）を備えた標準に適用可能かもしれない。
【００５０】
ある通信システムでは、次世代設備設計のためのより多くのフィールドのために提供するべきＰＨＹヘッダー４０８およびＭＡＣヘッダーを拡張することは望ましいことであり得る。そのような次世代設備は、典型的には既存か前任者の設備より多くのヘッダーデータを要求するだろう。さらに、それは、零か最小のオーバヘッドを招く制御チャネルを提供することは拡張ヘッダーに望ましいことであり得る。例えば、ＥＣＭＡ−３６８における制御情報は３つの方法、ビーコンとして、またはコマンドフレームあるいはコントロールフレームとして、あるいは他のトラヒックに便乗して、のうちの１つで送られ得る。ビーコンは、必要とされるより頻繁でないかもしれないＥＣＭＡ−３６８標準において６５．５３６ミリ秒ごとに一度送られ得る。他方では、コントロールとコマンドフレームは個別の分散確保プロトコル（Ｄｉｓｔｒｉｂｕｔｅｄ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＤＲＰ）確保を要求し、個別のプリアンブル、ヘッダーおよび構造間間隔を備えたより多くのオーバヘッドという結果になる。各ペアの送信器および受信機がそれらのフレームを送るために個別のＤＲＰ確保を要求するので、この方法はデバイスの数で良く縮小しない。したがって、零か最小のオーバヘッドを招く制御チャネルを提供するＰＨＹヘッダー４０８およびＭＡＣヘッダーを拡張する必要がある。別の実施例では、優先的にされた競合アクセス（ｐｒｉｏｒｔｉｚｅｄ ｃｏｎｔｅｎｔｉｏｎ ａｃｃｅｓｓ：ＰＣＡ）はコマンド、制御情報および／またはフレームを送るために使用され得る。ＰＣＡを使用するシステムにおいて、異なるデバイス（例えば無線通信デバイス１０６および２２０）は、一定時間周期の間にフレーム（例えば、コマンド、制御フレーム）を送信するために、互いと競合し得る。いくつかのタイプのフレーム（例えばデータパケット）は、より高い優先事項を与えられ得る。最優先の１つのフレームおよび／または複数のフレームは、競われた期間に送信され得る。
【００５１】
一般にそこに恐らく、利用可能か、既存のヘッダー中で保存された制限のあるビット数、しかし、そのような予約のビットはヘッダー拡張用に提供するのには十分ではないかもしれない。確保されるビット（例えばヘッダーフィールドへヘッダービットを加算する）を越えてヘッダーフィールドを自体拡張することは、レガシーデバイスが新しいヘッダーをデコードすることができ、ヘッダーチェックシーケンスを確認することができ得ないように、ヘッダーをレガシーデバイスと互換性をもつようにし得ない。従って、さらに、レガシーデバイスと互換性をもつ確保されるビットを越えたヘッダー拡張を考慮に入れる縮小拡大可能なヘッダー拡張構造は望ましいかもしれない。ある実施例に従う縮小拡大可能なヘッダー拡張構造は、拡張ヘッダーがフレームの期間を増加させずに、送信されかつ／または受信されることを可能にし得る。フレーム持続期間を増加させずに、ヘッダー拡張を送信することは、レガシーデバイスとの互換性を促進するのを支援し得る。別の実施例は、拡張ヘッダー（ｓ）が、拡張ヘッダーデータ／情報を送信するために付加時間スロット（例えば、確保持続期間を拡張しおよび／または追加のフレームとして拡張ヘッダーを送信することなしで）を必要とせずに送信されることを可能にし得る。１つの実施例において、個別のプリアンブル、ヘッダーおよびフレーム間間隔のようなオーバヘッドは縮小され得る。これは、システムの使用での効率を増加させ得る。別の実施例において、パディングビット（ある長さにフレームを「詰める（ｐａｄ）」ために単に使用されるビット）は使用され得る。これらのパディングビットの使用は、一般に非有用なビットがヘッダー拡張データのような送信データに使用されることを可能にし得る。以前に非有用なビットが送信データに使用され得るように、これはさらにシステムの使用での効率を増加させ得る。
【００５２】
図６は実例となる実施例によって例の縮小拡大可能なヘッダー拡張構造である。典型的な縮小拡大可能なヘッダー拡張構造６００は、ＰＬＣＰヘッダー４０４、第１の拡張ヘッダー６０６、第２の拡張ヘッダー６１０、第Ｎの拡張ヘッダー６１４および、実際のフレームペイロード４１０を含む。拡張ヘッダーは、それぞれ１つ以上の指標ビットの使用により他の拡張ヘッダーあるいは実際のフレームペイロード４１０を指し得る。
【００５３】
ＰＬＣＰヘッダー４０４における確保されるビットの制限される数にもかかわらず、上に議論されるように、無線通信デバイス（例えば１０６）は、必要な場合に実際のフレームペイロード４１０の前の１つ以上の拡張ヘッダーを挿入することにより、縮小拡大可能なヘッダー拡張構造６００を作り得る。プロセッサ（例えば、２００または３００）は縮小拡大可能なヘッダー拡張構造６００を作り得る。拡張ヘッダーは、詳細に下に議論されるとともに、無線通信ネットワーク（例えば１００）を越えて様々なタイプの情報あるいはコンテンツを送るために使用され得る。情報またはコンテンツは無線通信デバイス（例えば１０６）へおよび／またはそこから他の無線通信デバイス（例えば２１０、２２０、あるいは２３０）まで送られ得る。
【００５４】
拡張ヘッダーは、さまざまなタイプの情報あるいはコンテンツを送るために使用され得る。例えば、拡張ヘッダーの１つ以上は現在のＰＳＤＵを復号するためには必要とされない情報、あるいはそれ自身のＰＬＣＰヘッダーの頑強性を必要としない非重大なコンテンツを送るために使用され得る。１つの実施例では、拡張ヘッダーは、ＰＳＤＵに十分な余地がない場合、最善の努力ベースで任意に送られる情報を含む。別の実施例において、拡張ヘッダーは、複数フレームに関して無線ネットワークインターフェース（例えば２０８または３０８）によって受信されるコンテンツを含んでいる。無線通信デバイス（例えば１０６）の記憶は外、拡張ヘッダーを格納し得る。
【００５５】
拡張ヘッダーは、また、制御情報を送るために使用され得る。例えば、情報は、無線ネットワークインターフェース（例えば２０８または３０８）によってリソースの適応の割り当てためのチャネル状態情報（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ：ＣＳＩ）フィードバックを備えることができた。特に、情報は、送信電力、データレート、変調あるいは復号に向けられたコンテンツを含んでいる。１つの実施例において、拡張ヘッダーは、ローカルのリンクスケジューリング情報を含む。別の実施例において、拡張ヘッダーは、帯域外制御情報を含む。あるタイプのコンテンツを送るために使用される拡張ヘッダーは、参照されたが、拡張ヘッダーは上にリストされない他の制御情報を含む任意のタイプの情報を送るために使用され得る。
【００５６】
図６への継続的な参照で、１つの実施例において、第１の拡張ヘッダー６０６の存在は、ＰＬＣＰヘッダー４０４中の確保されるビットによって示される。例えば、図５の参照で、第１の拡張ヘッダー６０６が存在するかどうか示すためにＰＨＹヘッダー４０８の第１の確保されたフィールド５０２が使用されることができるだろう。表示に使用されたビットは、ＰＨＹヘッダー４０８の確保されるビットのうちのどれでも含む他の１つ以上のビットを含み得る。１つの実施例において、表１に関して下記に述べられるように、表示に使用されるビットは、第１の拡張ヘッダー６０６の存在およびコンテンツを示す。表示に使用されたビットは、プロセッサ（例えば２００または３００）あるいはメッセージフォーマッタ（例えば２０２または３０２）によって挿入され得る。
【表１】
【００５７】
表１は、次の拡張ヘッダーの存在およびコンテンツを示す１つの可能な符号化スキームを例示する。例えば、第１の拡張ヘッダー６０６の存在は、上に記述されるようなＰＬＣＰヘッダー４０４の確保される１つ以上のビットによって示され得る。３ビットを使用する例示される符号化スキームにおいて、符号化されるビットの値は、第１の拡張ヘッダー６０６の存在およびコンテンツを決定するために使用され得る。例えば、ビットの符号化された値が１だった場合、これは第１の拡張ヘッダー６０６がＣＳＩの内容を含むことを示し得る。同様に、ビットの符号化された値が０だった場合、これは、第１の拡張ヘッダー６０６が存在せず、実際のフレームペイロード４１０が直ちにＰＬＣＰヘッダー４０４に続くことを示し得る。
【００５８】
図６および表１への継続的な参照で、第２の拡張ヘッダー６１０の存在を示すビットは、１つ以上のビットの第１の拡張ヘッダー６０６を含み得る。第２の拡張ヘッダー６１０を示すために使用されたビットは表１に記述される符号化されたスキームを使用して符号化され得る。したがって、第２の拡張ヘッダー６１０に対応する指標ビットの符号化された値が、２だった場合、これは第２の拡張ヘッダー６１０がリンクスケジューリングコンテンツを含むことを示し得る。同様に、ビットの符号化された値が０だった場合、これは、第２の拡張ヘッダー６１０が存在せず、実際のフレームペイロード４１０が直ちに最初の拡張ヘッダー６０６に続くことを示し得る。第Ｎの拡張ヘッダー６１４の存在を示すビットは、表１の符号化スキームを使用して同様のやり方でインプリメントされ得る。
【００５９】
上に記述された縮小拡大可能なヘッダー拡張構造６００は、拡張ヘッダーのデイジーチェーンに相当する。ＰＬＣＰヘッダー４０４における１つ以上の指標ビットは、第１の矢印６０４によって、抽象的に示されるように、第１の拡張ヘッダー６０６を指し得る。同様に、第１の拡張ヘッダー６０６における１つ以上の指標ビットは、第２の矢印６０８によって、抽象的に示されるように、第２の拡張ヘッダー６１０を指し得る。同様に、第３の矢印６１２および第４の矢印６１６は、さらに、抽象的に、拡張ヘッダーのデイジーチェーンを表すために使用され得る。デイジーチェーンのほかの他の縮小拡大可能なヘッダー拡張構造は、可能である。例えば、ＰＬＣＰヘッダー４０４における１つ以上の確保されるビットが、拡張ヘッダーが存在するかどうかおよび／または存在する拡張ヘッダーの数を示し得る。１つの実施例において、ビットが１つ以上の拡張ヘッダーの存在を示す場合、ヘッダー拡張指標フィールドの列を含んでいるフィールドはＰＬＣＰヘッダー４０４の後に置かれ得る。
【００６０】
図７は、図６の縮小拡大可能なヘッダー拡張構造に従った例の修正されるＥＣＭＡ−３６８フレーム構成を例示する。修正されるフレーム構造７００は、ＰＬＣＰプリアンブル４０２、ＰＬＣＰヘッダー４０４、拡張されるＰＬＣＰヘッダー７０２、およびＰＳＤＵ４０６を備える。ＥＣＭＡ−３６８標準（例えば４００）によって定義されたフレーム構造とは対照的に、修正されるフレーム構造７００は、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードへ挿入される拡張されるＰＬＣＰヘッダー７０２を含む。ＰＬＣＰヘッダー７０２は、図６に関して上に記述されるような拡張ヘッダーのデイジーチェーンの使用により挿入され得る。
【００６１】
ＥＣＭＡ−３６８標準において、最大のＰＳＤＵの長さは、図５に例示された１２ビットの長さのフィールド５０６の最大値に対応して、４０９５バイトである。１つの実施例において、拡張されるＰＬＣＰヘッダー７０２は、実際のフレームペイロード４１０の前にＰＳＤＵ４０６のペイロードに挿入され、また、長さフィールド５０６は、拡張されるＰＬＣＰヘッダーの長さと実際のフレームペイロードの長さを示す。メッセージフォーマッタ（例えば、２０２または３０２）および／または、プロセッサ（例えば２００または３００）は、この挿入を行なうことができた。
【００６２】
例示される拡張ＰＬＣＰヘッダー７０２は、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードへ挿入されるように示されるが、拡張されるＰＬＣＰヘッダー７０２は、さまざまな方法で挿入され得る。例えば、１つの実施例において、下に議論されるように、拡張されるＰＣＬＰヘッダー７０２は、パッドビット４１２に挿入される。
【００６３】
現在のＥＣＭＡ−３６８システムにおいて、パディングビットは、記号インタリーバの境界上のデータストリームを整列させるために挿入され得る。例えば、ＥＣＭＡ−３６８は、データストリームが６つの直交周波数分割変調（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｏｄｕｌａｔｉｏｎ：ＯＦＤＭ）記号境界上で整列するように、パッドビットが挿入されると規定する。１つの実施例において、１つ以上の拡張ヘッダーが、ＰＳＤＵ４０６のパッドビット４１２に送られる。
【００６４】
例示目的だけのために、パッドビット４１２における拡張ヘッダーを送る次の見込みのモデルを考慮することは有用である。モデルの追加の詳細は、Ｄａｓ等のＩＣＵＷＢ２００９のＰＳＤＵ内の縮小拡大可能なＰＬＣＰヘッダー拡張において見出され、これは、全体の参照によってここに組込まれる。与えられた構造中のパッドビット４１２の数をｘにし、およびパッドビット４１２に挿入されることが望まれる拡張ヘッダー要素の合計長さをＡビットにしてください。このモデルのために、ｘは、一様の確率分布としてモデル化され得る。
【００６５】
したがって、ｘは０からＰ−１まで変化し、そこでは、Ｐは、フレームペイロードが送信され、与えられるＰＨＹデータレートで６つのＯＦＤＭシンボルの中の情報ビットの数に相当する。６つのＯＦＤＭシンボルの中の情報ビットの数は、ＥＣＭＡ−３６８標準によって定義され、また、表２に下に示されるように、その情報ビットはデータレートに応じて変わる。
【表２】
【００６６】
Ａ＜Ｐの場合に、我々はｘの範囲を２つの部分に分割し得る。第１の部分において、ｘ＜Ａで拡張ヘッダーは、パッドビット４１２に合わない。拡張ヘッダーがパッドビット４１２に挿入される場合、追加のパディングビットは、ＥＣＭＡ−３６８標準によって要求されるような６つのＯＦＤＭシンボル境界上のデータストリームを整列させるために必要とされるだろう。第２の部分において、ｘ≧Ａであり、拡張ヘッダーはパッドビット４１２に合うだろう。したがって、
【数１】
【００６７】
は、拡張ヘッダーが、ＰＳＤＵ４０６を拡張する必要なしに、パッドビット４１２に合わない確率である。１つの実施例において、
【数２】
【００６８】
が小さい場合に、拡張ヘッダーは、パッドビット４１２に無条件に置かれる。送信のごく一部分の中でＰＳＤＵ４０６が拡張されなければならないが、図１３に関して下記に述べられるとともに、ＰＬＣＰプリアンブルおよびＰＬＣＰヘッダーのオーバヘッドが償却される。別の実施例では、その後、拡張ヘッダーがパッドビット４１２に合う場合に限り、拡張ヘッダーはパッドビット４１２に置かれる。まだ別の実施例の中で、拡張ヘッダーが詰込みに利用可能なフィールドに入らない場合、図９に関して下記に述べられるように、パッドビット４１２においてふさわしい拡張ヘッダーフラグメントが送られる。
【００６９】
Ａ≧Ｐの場合に、ＰＳＤＵ持続期間が拡張されなければならない。特に、ＰＳＤＵは６個のシンボル持続期間の
【数３】
【００７０】
の数によって拡張されなければならなく、ｍｏｄ（Ａ，Ｐ）≦ｘ＜Ｐの場合にｙ＝０であり、そして０≦ｘ＜ｍｏｄ（Ａ，Ｐ）の場合にｙ＝１であろ。そして、この場合、我々は常に追加の６つのシンボルの持続時間の
【数４】
【００７１】
の数を招き、また、
【数５】
【００７２】
の蓋然性で、我々は追加の６つの記号持続期間を招く。１つの実施例では、拡張ヘッダーは、パッドビット４１２にＰＳＤＵの期間を無条件に拡張することという結論にし得る利用可能なパディングビットに合わなくてもよい。ＰＳＤＵ ４０６は、１つ以上の追加の６つの記号の持続時間によって拡張されなければならないが、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダー、およびフレーム間間隔のオーバヘッドが償却され得る。
【００７３】
パッドビット４１２に拡張されるＰＣＬＰヘッダー７０２を挿入することは、特有のモデルに関して上に記述されたが、これは説明の目的だけのためにあり、任意の方法に上に記述された実施例を限定するようには意図されなかった。
【００７４】
図８は第１の実施例に従う例の拡張されるＰＬＣＰヘッダー構造７０２である。例示の拡張されるＰＬＣＰヘッダー７０２は、第１の拡張ヘッダー指標８０２、第１の拡張長さ８０４、および第１の拡張情報８０６を有する第１の拡張ヘッダーを含む。拡張されるＰＬＣＰヘッダー７０２は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０および第２の拡張情報８１２を有する第２の拡張ヘッダーを含み得る。拡張されるＰＬＣＰヘッダー８１４は、すべての拡張ヘッダーの後に位置して、さらにパッドビット８１４を含む。例示されるＰＬＣＰヘッダー７０２は少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造は、どんな数の拡張ヘッダーも含むことができた。例えば、１つの実施例において、ＰＬＣＰヘッダー７０２は、１つ、２つ、あるいは３つの拡張ヘッダーを含み得る。別の実施例において、ＰＬＣＰヘッダー構造は、拡張ヘッダーを含んでいなくてもよくない。
【００７５】
例示される拡張されるＰＬＣＰヘッダー７０２は、図６−７に関して上に記述された実施例の中において使用され得る。図６および表１に関して上に記述されるように、第１の拡張ヘッダー指標８０２がインプリメントされ得る。拡張ヘッダー指標（例えば、８０２または８０４）は、特に上に記述されるような後の拡張ヘッダーの存在およびコンテンツを示し得る。ＰＬＣＰヘッダー（例えば、４０４）の中の確保されるビットは、第１の拡張ヘッダーの存在を示してもよい。他の拡張ヘッダー指標（例えば８０６）は前の拡張ヘッダーにあり得る。
【００７６】
例示される拡張されるＰＬＣＰヘッダー７０２は、第１の拡張の長さ８０４および第２の拡張長さ８０６を含んでいる。第１の拡張の長さ８０４は、第１の拡張情報８０６の長さを示し得る。同様に、第２の拡張長さ８１０は、第２の拡張情報８１２の長さを示し得る。１つの実施例において、拡張長さは１０ビットで、ビットにおける拡張ヘッダー情報の長さを示す。
【００７７】
図８への継続的な参照で、例示される拡張されるＰＬＣＰヘッダー７０２はパッドビット８１４を含んでいる。パッドビット８１４は、バイトが１つ以上の拡張ヘッダーを整列させるのに使用される。ある実施例では、パッドビット８１４は必要ではないかもしれない。例えば、拡張長さがバイトにおいて拡張ヘッダーの長さを示す場合、拡張ヘッダーは自動的に整列されたバイトである。
【００７８】
１つの実施例において、拡張長さフィールドは、時間アップで感知可能な処理を促進するためにメッセージインタプリタ（例えば２０６または３０６）および／またはプロセッサ（例えば２００または３００）によって使用される。特に、拡張長さフィールドは、必要とされるような拡張ヘッダーエレメントオフラインを処理する柔軟性を提供する。ペイロード、メッセージインタプリタ（例えば２０６または３０６）および／またはプロセッサ（例えば２００または３００）のスタートを位置づけることは、実際のフレームペイロードのスタートに達する拡張ヘッダー情報をスキップするために長さフィールドを使用し得る。
【００７９】
図９は、図８の拡張されるＰＬＣＰヘッダー構造の拡張ヘッダー情報フィールド用の例のコーディング表を例示する。例示された拡張ヘッダー情報９００は、バージョンフィールド、フラグメントフィールド、およびペイロードフィールドを含む。拡張ヘッダー情報９００は、拡張情報（例えば、８０６または８１２）のための多くの可能なフォーマットのうちの１つを例示する。
【００８０】
バージョンフィールドは、送信機及び受信機が拡張ヘッダー情報で更新に関して同期されることを維持するために使用され得る。例えば、拡張ヘッダーがＣＳＩを通信するために使用されティル場合、バージョンフィールドはＣＳＩの特定のバージョンを示し得る。１つの実施例において、バージョンフィールドは３ビットである。
【００８１】
図９への継続的な参照で、拡張ヘッダー全体が、現在のＰＳＤＵに合わない場合、フラグメント数フィールドは使用され得る。例えば、図７に関して上に記述されるように、最大のＰＳＤＵ長さは、ＥＣＭＡ−３６８標準において４０９５バイトである。従って、いくつかの拡張ヘッダーは、ＰＬＣＰヘッダーにおける長さフィールドが一般に拡張ヘッダーの長さとペイロードの長さ足したものを示すので、与えられたＰＳＤＵに入れるのに大きすぎ得る。フラグメント数は、拡張ヘッダーが１つを超えるＰＳＤＵの中で送られることを可能にし得る。さらに、図７に関して上に記述されるように、いくつかの実施例では、１つ以上の拡張ヘッダーがパッドビット４１２に置かれ得る。拡張ヘッダーが、パッドビット４１２に入らない場合、フラグメント数フィールドを有する拡張ヘッダーフラグメントはパッドビット４１２に挿入され、代わりに送られ得る。
【００８２】
ペイロードフィールドは、拡張ヘッダーの情報またはコンテンツを含み得る。この情報は、ＣＳＩ、リンクスケジューリング、帯域外制御、あるいは図６に関して上に記述されるような様々な他のタイプのコンテンツを含み得る。１つの実施例では、ペイロードフィールドの長さはヘッダー拡張タイプに特有である。例えば、表１への参照で、ペイロードフィールドの長さは、拡張ヘッダーがＣＳＩ、リンクスケジュール、帯域外制御コンテンツを含むかどうかに依存して、変わり得る。
【００８３】
図１０は、第２の実施例にしたがう例の拡張されるＰＬＣＰヘッダー構造である。絵入りの拡張ＰＬＣＰヘッダー１０００は、第１の拡張ヘッダー指標８０２、第１の拡張の長さ８０４および第１の拡張情報８０６がある第１の拡張ヘッダーを含む。例示される拡張されるＰＬＣＰヘッダー１０００は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０および第２の拡張情報８１２を有する第２の拡張ヘッダーを含む。拡張されるＰＬＣＰヘッダー８１４は、拡張ヘッダーの後に位置して、フレームチェックシーケンス１００２、ティルビット１００４、およびパッドビット８１４をさらに含む。例示されるＰＬＣＰヘッダー１０００は、少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造は拡張ヘッダーのどんな数の拡張ヘッダーも含むことができた。
【００８４】
図８の拡張されるＰＬＣＰヘッダー７０２と比較して、例示の拡張されるＰＬＣＰヘッダー１０００は、改善された誤り検出および修正を提示し得る。拡張されるＰＬＣＰヘッダーへのフレームチェックシーケンス１００２およびティルビット１００４の追加は、拡張ヘッダーにおける誤りから実際のフレームペイロードにおける誤りを分断し得る。
【００８５】
フレームチェックシーケンス１００２は、誤り検出修正を改善するために拡張ＰＬＣＰヘッダー１０００に特有の検査合計特徴を提供する。１つの実施例において、フレームチェックシーケンス１００２は３２ビットである。無線ネットワークインターフェース（例えば、２０８または３０８）が畳込み復号器を含んでいる場合、ティルビット１００４はそれをその初期状態にリセットし、かつ、誤り確率を改善するように復号器をフラッシュアウトするために付け加えられ得る。ティルビット１００４の追加は、特に拡張ヘッダーにおける誤りからの実際のフレームペイロードにおける誤りを分断し、大きなフレームペイロードの前に付け加えられた時特に有益である。
【００８６】
図１１は第３の実施例に従う例の拡張されるＰＬＣＰヘッダー構造である。例示される拡張されるＰＬＣＰヘッダー１１００は、第１の拡張ヘッダー指標８０２、第１の拡張の長さ８０４、第１の拡張情報８０６、第１のフレームチェックシーケンス１１０２、および第１のティルビット１１０４を有する第１の拡張ヘッダーを含み得る。拡張ＰＬＣＰヘッダー１１００は、さらに第２の拡張ヘッダー指標８０８、第２の拡張長さ８１０、第２の拡張情報８１２、第２のフレームチェックシーケンス１１０６および第２のティルビット１１０８がある第２の拡張ヘッダーを含んでいる。拡張ＰＬＣＰヘッダー８１４は、拡張ヘッダーの後に位置して、さらにパッドビット８１４を含む。例示されるＰＬＣＰヘッダー１１００は、少なくとも２つの拡張ヘッダーを含んでいるが、ＰＬＣＰヘッダー構造はどんな数の拡張ヘッダーも含むことができた。
【００８７】
図８の拡張ＰＬＣＰヘッダー７０２および図１０の拡張ＰＬＣＰヘッダー１０００の両方と比較されるように例示される拡張されるＰＬＣＰヘッダー１１００は改善された誤り検出修正を提示してもよい。フレームチェックシーケンスおよび各拡張ヘッダーへのティルビットの追加は、特に拡張ヘッダーにおける誤りからの実際のフレームペイロードにおける誤りを分断してもよい。最初のフレームチェックシーケンス１１０２、第１のティルビット１１０４、第２のフレームチェックシーケンス１１０６および第２のティルビット１１０８だけは例示されるが、ＰＬＣＰヘッダー１１００へのより多くの拡張ヘッダーの追加は、より多くのフレームチェックシーケンスおよびティルビットの追加という結論になり得る。
【００８８】
図１２は、１つの実施例によってＰＣＬＰヘッダーを拡張する方法である。例示されるステップのすべてが必要だとは限らなく、この方法が発明の趣旨および範囲から外れずに修正されてもよいことが理解されるだろう。さらに、この方法は、さらに詳細に下に記述されるように、１台以上のプロセッサ、フォーマッタ、インタプリタ、メモリおよび／または他のデバイスを使用してインプリメントされ得る。送信デバイス（例えば１０２または１０６）の視点から見て描かれた例示された方法１２００は、１２００から開始する。続いて起こるステップ１２０２において、送信デバイスは、受信デバイス（例えば１０２または１０６）に送るために拡張ヘッダーを識別する。プロセッサ（例えば２００または３００）はこの識別を実行し得、また、識別された拡張ヘッダーは、メモリ（例えば２０４または３０４）の中にあってもよいかあるいは、有線ネットワークインターフェース（例えば３０８）のような別のソースからから来ることができる。
【００８９】
続いて起こる決定ステップ１２０６で、送信デバイス（例えば１０２または１０６）は、少なくとも１つの拡張ヘッダーを送らなければならないかどうか決定する。プロセッサ（例えば２００または３００）はこの決定を行ない得る。決定ステップへの答えがいいえである場合、方法１２００は詳細にさらに下に記述されるために決定ステップ１２２０に進む。
【００９０】
決定ステップ１２０６で質問への答えがはいである場合、方法１２００は、送信デバイス（例えば１０２または１０６）は次の拡張ヘッダーの長さを計算する１ステップ１２０８に移る。１つの実施例では、それがバイトでもたらされる別の実施例にいる間、この計算はビットで行われる。プロセッサ（例えば２００または３００）はこの計算を行ない得る。続いて起こる決定ステップ１２１０で、送信デバイスは、拡張ヘッダーが条件付きで送られるかどうか決定する。プロセッサ（例えば２００または３００）はメモリ（例えば２０４または３０４）を使用して、この決定を行ない得る。
【００９１】
決定ステップ１２１０で質問への答えがいいえである場合、方法１２００は１ステップ１２１２に移り、そこで、送信デバイス（例えば１０２または１０６）は構造に拡張ヘッダーを入れる。例えばプロセッサ（例えば２００または３００）および（または）メッセージフォーマッタ（例えば２０２または３０２）によって構造に拡張ヘッダーを入れることができるだろう。さらに、様々な位置でフレームに拡張ヘッダーを入れることができるだろう。例えば、図７に関して、ＰＳＤＵ４０６のパッドビット４１２に拡張ヘッダーを挿入することができるだろう。別の実施例において、拡張ヘッダーは、図６に関して上に記述されるように、拡張ヘッダーのデイジーチェーンを使用して、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードに入れられる。ステップ１２１２が終わった後、方法１２００は決定ステップ１２０６に返り、それは上に記述された。
【００９２】
決定ステップ１２１０で質問への答えがはいである場合、方法１２００は、送信デバイス（例えば１０２または１０６）は利用可能なパディングビット（例えば４１２）を計算する１ステップ１２１４に移る。プロセッサ（例えば２００または３００）はこの計算を行ない得る。
【００９３】
続いて起こる決定ステップ１２１６において、送信デバイスは、拡張ヘッダーの長さが利用可能なパディングビットより大きいかどうか決定する。送信デバイスは、この決定をなすためにプロセッサ（例えば２００または３００）あるいは様々な他のモジュールを使用し得る。質問への答えがいいえである場合、方法１２００はステップ１２１２に移り、それは上に記述された。
【００９４】
決定ステップ１２１６で質問への答えがはいである場合、方法１２００は、送信デバイスは拡張ヘッダーがフラグメント化されるかどうか決定する決定ステップ１２１８に移る。プロセッサ（例えば２００または３００）はメモリ（例えば２０４または３０４）を使用して、この決定を行ない得る。１つ以上の拡張ヘッダーをフラグメント化する過程は、図９に関して上に記述された。質問への答えがいいえである場合、方法１２００は詳細に後の下に記述されるように、決定ステップ１２２０に進む。
【００９５】
決定ステップ１２１８で質問への答えがはいである場合、方法１２００は、ステップ１２２２に進み、そこで、送信デバイスは、フレーム内に拡張ヘッダーのフラグメントをフレーム内に置く。プロセッサ（例えば２００または３００）および（または）メッセージフォーマッタ（例えば２０２または３０２）は、フレームに拡張ヘッダーのフラグメントを入れることができた。図７に関して上に記述されるように、拡張ヘッダーのフラグメントは、ＰＳＤＵ４０６のパッドビット４１２に挿入されることができるだろう。
【００９６】
ステップ１２２２を終えた後に、方法１２００は、保証ステップ１２２４に進み、そこで、送信デバイスはＦＣＳ（例えば１００２）、ティルビット（例えば１００４）、およびパッドビット（例えば１００６）を１つ以上の拡張ヘッダーのためにフレームに入れる。別の実施例では、拡張ヘッダー用のＦＣＳ、ティルビットおよび（または）パッドビットは、フレームに入れられなくてもよい。例えば、もし方法１２００が図８に例示されるヘッダー拡張構造を使用すれば、ＦＣＳとティルビットは挿入されないだろう。
【００９７】
更に、プロセッサ（例えば２００または３００）および／またはメッセージフォーマッタ（例えば２０２または３０２）は、構造にＦＣＳ、ティルビットおよびパッドビットを入れることができた。さらに、拡張ヘッダーおよびここでの拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットは、さまざまな位置でフレームに入れられることができるだろう。例えば、図７に関して、ＰＳＤＵ ４０６のパッドビット４１２に拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットに加えた拡張ヘッダーを挿入することができるかもしれない。別の実施例では、拡張ヘッダーのＦＣＳ、ティルビットおよびパッドビットは、図６に関して上に記述されるように、デイジーチェーン構造を使用して、ＰＬＣＰヘッダー４０４と実際のフレームペイロード４１０の間のＰＳＤＵ４０６のペイロードに入れられてもよい。
【００９８】
ステップ１２２４が終わった後、方法１２００は、ＰＰＤＵあるいはフレーム構成（例えば４００）へ送信デバイスはどんな拡張ヘッダーも含むフレームペイロードを入れ、続いて起こるステップ１２２６に移る。実施例では、送信デバイスは、ＰＰＤＵおよび／またはフレーム構成（例えば４００）にＰＳＤＵのためのＦＣＳ、ティルビットおよびパッドビットを入れてもよい。フレームペイロードは、プロセッサ（例えば２００または３００）を使用して、および／またはメッセージフォーマッタ（例えば２０２または３０２）によってフレーム構成に入れられてもよい。ステップ１２２４を終えた後に、方法１２００は終了するステップ１２２８に移る。
【００９９】
決定ステップ１２２０で、送信デバイスは、少なくとも１つの拡張ヘッダーがフレームの中にあるかどうか決定する。プロセッサ（例えば２００または３００）はこの決定を行なってもよい。決定ステップへの答えがはいである場合、方法１２００はステップ１２２４に移る。それは上に記述された。決定ステップへの答えがいいえである場合、方法１２００はステップ１２２６に移る。それも上に記述された。
【０１００】
１つの実施例では、より短い媒体アクセス持続期間は通信システム２００に達成されてもよい。１つの実施例で、上に議論されるように、ＰＳＤＵ持続期間が拡張されてもよい場合、拡張ヘッダー要素の合計長さにＡが相当する場所は、挿入されることを望んだ。また、Ｐは与えられたＰＨＹデータレートで６つのＯＦＤＭシンボルの中の情報ビットの数に相当する。例えば、拡張ヘッダーを送信するための３つのシナリオ、拡張ヘッダーがＦＣＳなしで送信されるケースＡ、拡張ヘッダーが個別のＦＣＳおよびティルビットで送信されるケースＢ、および拡張ヘッダーが個別のＰＳＤＵとして送信されるケースＣがあり得る。Ｔは拡張ヘッダーのために最少アクセス持続期間を指す。この実施例では、Ｔ６ＳＹＭは、１．８７５ｕｓであり得る６つのＯＦＤＭシンボルの期間を指す。ケースＡおよびＢについては、期待される最少のアクセス持続期間は、方程式Ｅ（Ｔ）＝（Ｎ＋ｑ）＊Ｔ６ＳＹＭによって示され得て、ここで、Ｎは、拡張ヘッダーを送信するために必要だろう追加の６つのＯＦＤＭシンボル持続期間の数で、ｑは追加の６つのＯＦＤＭシンボル持続期間が必要とされる確率である。
【０１０１】
ケースＣについて、拡張ヘッダーが個別のＰＳＤＵのペイロードの中で送信されるので、短い相互フレームスペース（ｓｈｏｒｔ ｉｎｔｅｒ−ｆｒａｍｅ ｓｐａｃｅ：ＳＩＦＳ）は使用され得る。さらに、個別のＰＳＤＵは、さらに個別のプリアンブルおよび個別のヘッダーを使用し得る。したがって、個別のＰＳＤＵの中の拡張ヘッダーを送信する時間は方程式Ｔ＝ＴＳＩＦＳ＋ＴＰＲＥＡＭＢＬＥ＋ＴＰＬＣＰＨＥＡＤＥＲ＋ＴＰＡＹＬＯＡＤによって示され得て、ここで、ＴＳＩＦＳは、ＳＩＦＳのために時間を指し、ＴＰＲＥＡＭＢＬＥはプリアンブルを送信する時間を指す、ＴＰＬＣＰＨＥＡＤＥＲは、ＰＬＣＰヘッダーを送信する時間を指し、ＴＰＡＹＬＯＡＤは、ペイロードを送信する時間を指す。この実施例において、ＴＳＩＦＳ＝１０ｕｓ、ＴＰＲＥＡＭＢＬＥ＝９．３７５ｕｓおよびＴＰＬＣＰＨＥＡＤＥＲ＝３．７５ｕｓである。さらに、ＴＰＡＹＬＯＡＤ＝（Ｎ＋ｚ）＊Ｔ６ＳＹＭであり、Ａ ｍｏｄ Ｐが０である場合、ｚが０であり、そうでない場合ｚが１である（Ａは拡張ヘッダーの合計長さでありまた、Ｐは、与えられたデータレートであるＰＨＹレートための６つのＯＦＤＭシンボルの中の情報ビットの数である）。
【０１０２】
ケースＢおよびＣのための予期された媒体アクセス持続間の違いは、方程式ΔＴ＝ＴＳＩＦＳ＋ＴＰＲＥＡＭＢＬＥ＋ＴＰＬＣＰＨＥＡＤＥＲ＋（ｚ−ｑ）＊Ｔ６ＳＹＭによって示され得る。
【０１０３】
上に示されるように、ケースＡおよびＢのための媒体アクセス持続時間はケースＣのための媒体アクセス持続時間未満である。ケースＣにおいて、余分のオーバヘッドは、個別のＰＳＤＵのペイロード中の拡張ヘッダーデータの送信の結果として引き起こされ得る。しかしながら、ケースＡおよびＢにおいて、拡張ヘッダーデータは以前のパケットのパディングビットかペイロード内で適合し得る。したがって、個別のＰＳＤＵは、必然的に、ケースＡおよびＢのためのより短い媒体アクセス持続時間という結果にならないかもしれない。１つの実施例において、すべての場合のための媒体アクセス持続期間は、通信レートの１００のデータレートが増加するにつれて減少し得る。静的なオーバヘッドの無および／またはペイロードにおけるパッディングエリアの効率的な使用は、通信システム１００の媒体アクセス継続期間（例えば、効率を増加させる）を減少させ得る。
【０１０４】
「第１」、「第２」などのような指示をここに使用するエレメントへのどんな言及も、それらのエレメントの量や順番を一般的に限定しないことは理解されるに違いない。むしろ、これらの指示は、２つ以上のエレメントあるいはエレメントのインスタンスを識別する便利な方法としてここに使用され得る。したがって、第１と第２エレメントへの言及は、２つのエレメントだけがそこに使用されてもよいか、第１エレメントがある方法において第２のエレメントに先行するに違いないことを意味しない。また、そうでないと述べられない限り、１組のエレメントが１つ以上のエレメントを含み得る。説明または請求項において使用される「Ａ、Ｂ、またはＣの少なくとも１つ」は、「Ａ、またはＢまたはＣ、またはそれらのエレメントの組み合わせ」を意味する。
【０１０５】
実施例はここに示した実施例と他の実施例は、添付された付録にさらにより非常に詳しく記述される。明細書が本発明の特別の例について記述される一方、当業者は、発明概念から外れずに、本発明の変更を考案し得る。例えば、ここの教えは、回路切り換えネットワークエレメントを参照するが、パケット切り換え領域ネットワークエレメントに等しく適用可能である。
【０１０６】
当業者は、情報と信号が様々な異なる技術およびテクニックのうちのどれでも使用して表わされ得ると理解するだろう。例えば、上記の記述の全体にわたって参考され得るデータ、命令、コマンド、情報、信号、ビット、記号およびチップは、電圧、流れ、電磁波、磁界か、粒子、光学のフィールドあるいは光学粒子、または、それの任意の組合せによって表わされ得る。
【０１０７】
当業者は、ここで開示された例に関係して記載された、さまざまな例示の論理ブロックモジュール、回路、方法、アルゴリズムが、電子ハードウェア、コンピュータソフトウェアあるいは組合せとしてここにインプリメントされ得ことをさらに認識するだろう。ハードウェアおよびソフトウェアのこの交換性を明らかに示すために、様々な例示のコンポーネント、ブロック、モジュール、回路、方法およびアルゴリズムのこの互換性は、一般的にそれらの機能性という観点において、一般的に記載された。そのような機能性は、ハードウェアまたはソフトウェアとしてインプリメントされるかどうかは、全体のシステムに課された特定用途と設計制約に依存する。熟練技術者は。各特定用途の方法を変えることにおける記述された機能性をインプリメントしてもよい。しかし、そのようなインプリメンテーションの決定は本発明の範囲からの離れことを引き起こすと解釈されるべきでない。
【０１０８】
ここに示された例に関して記述された様々な実例となる論理ブロック、モジュール、および回路は、メインプロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、特定用途向けＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：ＦＰＧＡ）あるいは他のプログラマブル論理デバイス、個別のゲートかトランジスターロジック、個別のハードウェア構成機器あるいはそれのここに記述された機能を行なうことを目指した任意の組合せを用いてインプリメントされ、あるいは、実行され得る。汎用プロセッサは、マイクロプロセッサであり得るが、代わりに、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラあるいはステートマシンであり得る。プロセッサ、また、コンピューティングデバイス、例えばＤＳＰとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと協動する１個以上のマイクロプロセッサあるいは他のそのような構成の組合せとしてインプリメントされ得る。
【０１０９】
ここに開示された例に関して記述された方法またはアルゴリズムは、ハードウェア、プロセッサによって実行されたソフトウェアモジュール、あるいは２つの組合せで直接具体化され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭ、あるいは当該技術において既知の記憶媒体の他の形式に存在し得る。記憶媒体は、プロセッサが記憶媒体から情報を読み、その記憶媒体に情報を書き込みし得るようにプロセッサにつながれ得る。代わりに、記憶媒体は、プロセッサに不可欠であり得る。プロセッサと記憶媒体はＡＳＩＣに存在し得る。
【０１１０】
１つ以上の典型的な実施例において、記述された機能は、ハードウェア、ソフトウェア、ファームウェアあるいはそれの任意の組合せにおいてインプリメントされ得る。もしソフトウェア中でインプリメントされる場合、機能は、１つ以上の命令あるいはコードとしてコンピュータ可読媒体上に記憶されあるいはそれを越えて送信され得る。コンピュータ可読媒体は、コンピュータ記憶媒体、およびある場所から別の場所へコンピュータプログラムの転送を促進するあらゆる媒体を含む通信媒体の両方を含む。記憶媒体はコンピュータによってアクセスされ得るあらゆる利用可能な媒体であり得る。制限ではなく例によって、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光学ディスク記憶装置、磁気ディスク記憶装置あるいは他の磁気記憶装置、あるいは、希望のプログラムコードを命令あるいはデータ構造の形式で格納するために使用され、コンピュータによってアクセスされ得る他の媒体を含み得る。さらに、接続はコンピュータ可読媒体を送信しかつ／または受信するために使用され得る。例えば、ソフトウェアは、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）あるいは赤外線、ラジオおよびマイクロ波のような無線技術を使用して、ウェブサイト、サーバーあるいは他の遠隔のソースから送信され得る。ここで使用されるようなディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、ディスク（ｄｉｓｋ）が通常磁気的にデータを再生する一方、ディスク（ｄｉｓｃ）がレーザーでデータを光学上再生する、コンパクトディスク（ｃｏｍｐａｃｔ ｄｉｓｃ：ＣＤ）、レーザーディスク（登録商標）、光ディスク、ディジタル・バーサタイル・ディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｄｃ：ＤＶＤ）、フロッピー（登録商標）ディスクおよびブルーレイディスクを含む。上記のものの組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
【０１１１】
開示された例の以前の記載はどんな当業者も本発明を作るかあるいは使用することを可能にするために提供される。これらの例への様々な修正は、当業者に容易に明白になるだろう、また、ここに定義された総括的な原理は、発明の趣旨または範囲から外れずに、他の例に適用され得る。したがって、本発明は、ここに示された例に制限されたようには意図されないが、ここに示された原理と新規な特徴と一致する最も広い範囲を与えられることになっている。
【特許請求の範囲】
【請求項１】
無線通信システムにおいて少なくとも１つの第１のパケットを送信するための通信デバイスであって、前記少なくとも１つの第１のパケットは、ヘッダーフィード、ペイロードフィールド、およびパッディングフィールドを備える通信デバイスであって、
第１の拡張ヘッダーを格納するように構成されたメモリと、
前記メモリと通信するプロセッサであって、少なくとも１ビットが、送信のために前記第１の拡張ヘッダーにおいて利用可能であるかどうかを決定するように構成されるプロセッサであって、ここで前記少なくとも１つのビットはヘッダーフィールドを占める複数のビットに付加的である、プロセッサと、
前記プロセッサと前記メモリの少なくとも１つと通信するメッセージフォーマッタであって、ヘッダーフィールドにおいて、前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入するように構成されたメッセージフォーマッタと
を備えた通信デバイス。
【請求項２】
前記メモリは、さらに、第２の拡張ヘッダーを記憶するように構成され、前記プロセッサは、さらに、少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能かどうかを決定するように構成され、前記少なくとも１つのビットは、前記ヘッダーフィールドを占める複数のビットに付加的であり、前記メッセージフォーマッタは、前記第１の拡張ヘッダーフィールドにおいて前記第２の拡張ヘッダーの存在を表し、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成される、請求項１の通信デバイス。
【請求項３】
前記第１のパケットおよび第２のパケットを送信するように構成された送信機を備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよび、パッディングフィールドを含み、前記第２の拡張ヘッダーは第１の部分および第２の部分を含み、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満あるいは等しい、請求項２の通信デバイス。
【請求項４】
前記プロセッサは、前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定するよう構成される、請求項１の通信デバイス。
【請求項５】
前記メッセージフォーマッタは、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、プログラマブルロジックデバイス、個別のゲートロジック、トランジスターロジック、および個別のハードウェアコンポーネントの少なくとも１つを備える、請求項１の通信デバイス。
【請求項６】
前記メッセージフォーマッタは、前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入するように構成される、請求項１の通信デバイス。
【請求項７】
前記メッセージフォーマッタは、少なくとも部分的に、前記第１の拡張ヘッダーの少なくとも一部分の長さに基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正するよう構成される、請求項６の通信デバイス。
【請求項８】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項１の通信デバイス。
【請求項９】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを含む、請求項１の通信デバイス。
【請求項１０】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを備える、請求項１の通信デバイス。
【請求項１１】
前記第１の拡張ヘッダーの長さが前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満か等しい場合に、前記メッセージフォーマッタは、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入するように構成される、請求項１の通信デバイス。
【請求項１２】
前記第１のパケットおよび第２のパケットを送信するように構成され送信機をさらに備え、そこで、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを備え、また、前記第１の拡張ヘッダーは、第１の部分および第２の部分を備え、また、前記メッセージフォーマッタは、さらに、第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第２の部分を挿入するよう構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満または等しい、請求項２の通信デバイス。
【請求項１３】
無線通信システムにおいて、少なくとも１つの第１のパケットを送信するための通信デバイスであって、前記少なくとも１つの第１のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備える通信デバイスであって、
第１の拡張ヘッダーを格納するための手段と、
少なくとも１ビットが送信のための前記第１の拡張ヘッダーにおいて利用可能かどうかを決定するための手段であって、前記少なくとも１ビットがヘッダーフィールドを占める複数のビットに付加的であり、前記決定するための手段が格納するための手段と通信する、決定するための手段と、
前記ヘッダーフィールドにおいて前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つにおいて前記第１の拡張ヘッダーの少なくとも１つの部分を挿入する手段であって、示しおよび挿入するための手段は格納するための手段または決定するための手段と通信する、示しおよび挿入するための手段と
を備える通信デバイス。
【請求項１４】
前記格納するための手段は、さらに、第２の拡張ヘッダーを格納するように構成され、前記決定のための手段は、さらに、少なくとも１ビットが、送信のために前記第２の拡張ヘッダーにおいて利用可能かどうかを決定するように構成され、前記少なくとも１ビットが、前記ヘッダーフィールドを占める複数のビットに付加的であり、示すための手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの前記少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入する、請求項１３の通信デバイス。
【請求項１５】
前記第１のパケットおよび第２のパケットを送信するための手段をさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを備え、前記第２の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタは、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さが前記第１のパケットの前記パッディングフィールドの長さ未満または等しい、請求項１４の通信デバイス。
【請求項１６】
決定のための前記手段は前記ヘッダーフィールドを占める前記複数のビットと適合しない少なくとも１ビットを決定するようにさらに構成される請求項１３の通信デバイス。
【請求項１７】
示すための前記手段は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、プログラマブルロジックデバイス、個別のゲートロジック、トランジスターロジックおよび個別のハードウェアコンポーネントの少なくとも１つを備える請求項１３の通信デバイス。
【請求項１８】
示すための前記手段は、さらに、前記第１のパケットの前記ペイロードフィールドの始め部分において前記第１の拡張ヘッダーの少なくとも１つの部分を挿入するように構成される、請求項１３の通信デバイス。
【請求項１９】
示すための前記手段は、さらに、前記第１の拡張ヘッダーの少なくとも１部分に部分的に基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正するように構成される、請求項１８の通信デバイス。
【請求項２０】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項１３の通信デバイス。
【請求項２１】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを備える、請求項１３の通信デバイス。
【請求項２２】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの少なくとも１つの部分の長さを示す長さフィールドを備える、請求項１３の通信デバイス。
【請求項２３】
示すための前記手段は、さらに、前記第１の拡張ヘッダーの長さが前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満かあるいは等しい場合、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入するように構成される、請求項１３の通信デバイス。
【請求項２４】
前記第１パケットおよび第２のパケットを送信するための手段を備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第１の拡張ヘッダーは第１の部分および第２の部分を含み、また、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、第１のパケットのパッディングフィールドの長さ未満かあるいはそれに等しい、請求項１４の通信デバイス。
【請求項２５】
少なくとも１つの第１のパケットを無線通信システムにおいて通信する方法であって、
少なくとも１つの第１のパケットはヘッダーフィールド、ペイロードフィールド、およびパッディングフィール含む、方法であって、
前記第１の拡張ヘッダーを格納することと、
少なくとも１ビットが、送信のために、前記第１の拡張ヘッダーにおいて利用可能かどうか決定することであって、前記少なくとも１ビットが、前記ヘッダーフィールドを占める複数のビットに付加的である、決定することと、
前記第１のパケットの前記ヘッダーフィールドにおいて、前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの前記少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入すること
を備える、方法。
【請求項２６】
第２の拡張ヘッダーを格納することと、および少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能なかどうかを決定することをさらに備え、前記少なくとも１ビットは、前記ヘッダーフィールドを占める複数のビットに付加的であり、示すための前記手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、また前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するように構成される、請求項２５の方法。
【請求項２７】
前記第１のパケットおよび第２のパケットを送信することをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第２の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタが、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットにおける前記パッディングフィールドの長さ未満かあるいは等しい、請求項２６の方法。
【請求項２８】
前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定することを備える、請求項２５の方法。
【請求項２９】
前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入することをさらに備える、請求項２５の方法。
【請求項３０】
少なくとも部分的に、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さに基づいた前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正することをさらに備える、請求項２９の方法。
【請求項３１】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項２５の方法。
【請求項３２】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを含む、請求項２５の方法。
【請求項３３】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを含む、請求項２５の方法。
【請求項３４】
前記第１の拡張ヘッダーの長さが、前記第１の拡張ヘッダーのパッディングフィールドの長さ未満または等しい場合に、前記第１のパケットのパッディングフィールドに前記第１の拡張ヘッダーを挿入することをさらに備える、請求項２５の方法。
【請求項３５】
前記第１のパケットおよび第２のパケットを送信することをさらに備え、前記第２のパケットはヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第１の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタが、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいは等しい、請求項２６の方法。
【請求項３６】
コンピュータに少なくとも１ビットがヘッダーフィールドを占める複数のビットに付加的である、前記少なくとも１ビットが送信のために第１の拡張ヘッダーにおいて利用可能などうかを決定させるためのコードと、
コンピュータに、前記第１のパケットの前記ヘッダーフィールドにおいて前記第１の拡張ヘッダーの存在を示させコンピュータに示させ、前記第１のパケットのペイロードフィールドおよびパッディングフィールドの少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入させるためにコードと
を備えたコンピュータ可読媒体を備える、コンピュータ可読製品。
【請求項３７】
コンピュータに前記第２の拡張ヘッダーを格納させ、前記ヘッダーフィールドを占める複数のビットに付加的である前記少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能かどうか決定させるためのコードをさらに備え、示すための前記手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成される、請求項３６のコンピュータ可読製品。
【請求項３８】
コンピュータに前記第１のパケットおよび第２のパケットを送信させるための含むコードをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを含み、また、前記第２の拡張ヘッダーは、第１の部分および第２の部分を含み、また、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいは等しい、請求項３７のコンピュータ可読製品。
【請求項３９】
コンピュータに前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４０】
をコンピュータに前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４１】
コンピュータに少なくとも部分的に、前記第１のパケットのヘッダーフィールドの長さに基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４２】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分はコンテンツフィールドを備える、請求項３６のコンピュータ可読製品。
【請求項４３】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを備える、請求項３６のコンピュータ可読製品。
【請求項４４】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを備える、請求項３６のコンピュータ可読製品。
【請求項４５】
前記第１の拡張ヘッダーの長さが、前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満または等しい場合に、コンピュータに、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４６】
コンピュータに、前記第１のパケットおよび第２のパケットを送信させるためのコードをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、第１の拡張ヘッダーは第１の部分および第２の部分を備え、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、また、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいはそれに等しい、請求項３７のコンピュータ可読製品。
【請求項１】
無線通信システムにおいて少なくとも１つの第１のパケットを送信するための通信デバイスであって、前記少なくとも１つの第１のパケットは、ヘッダーフィード、ペイロードフィールド、およびパッディングフィールドを備える通信デバイスであって、
第１の拡張ヘッダーを格納するように構成されたメモリと、
前記メモリと通信するプロセッサであって、少なくとも１ビットが、送信のために前記第１の拡張ヘッダーにおいて利用可能であるかどうかを決定するように構成されるプロセッサであって、ここで前記少なくとも１つのビットはヘッダーフィールドを占める複数のビットに付加的である、プロセッサと、
前記プロセッサと前記メモリの少なくとも１つと通信するメッセージフォーマッタであって、ヘッダーフィールドにおいて、前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入するように構成されたメッセージフォーマッタと
を備えた通信デバイス。
【請求項２】
前記メモリは、さらに、第２の拡張ヘッダーを記憶するように構成され、前記プロセッサは、さらに、少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能かどうかを決定するように構成され、前記少なくとも１つのビットは、前記ヘッダーフィールドを占める複数のビットに付加的であり、前記メッセージフォーマッタは、前記第１の拡張ヘッダーフィールドにおいて前記第２の拡張ヘッダーの存在を表し、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成される、請求項１の通信デバイス。
【請求項３】
前記第１のパケットおよび第２のパケットを送信するように構成された送信機を備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよび、パッディングフィールドを含み、前記第２の拡張ヘッダーは第１の部分および第２の部分を含み、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドと前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満あるいは等しい、請求項２の通信デバイス。
【請求項４】
前記プロセッサは、前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定するよう構成される、請求項１の通信デバイス。
【請求項５】
前記メッセージフォーマッタは、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、プログラマブルロジックデバイス、個別のゲートロジック、トランジスターロジック、および個別のハードウェアコンポーネントの少なくとも１つを備える、請求項１の通信デバイス。
【請求項６】
前記メッセージフォーマッタは、前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入するように構成される、請求項１の通信デバイス。
【請求項７】
前記メッセージフォーマッタは、少なくとも部分的に、前記第１の拡張ヘッダーの少なくとも一部分の長さに基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正するよう構成される、請求項６の通信デバイス。
【請求項８】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項１の通信デバイス。
【請求項９】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを含む、請求項１の通信デバイス。
【請求項１０】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを備える、請求項１の通信デバイス。
【請求項１１】
前記第１の拡張ヘッダーの長さが前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満か等しい場合に、前記メッセージフォーマッタは、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入するように構成される、請求項１の通信デバイス。
【請求項１２】
前記第１のパケットおよび第２のパケットを送信するように構成され送信機をさらに備え、そこで、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを備え、また、前記第１の拡張ヘッダーは、第１の部分および第２の部分を備え、また、前記メッセージフォーマッタは、さらに、第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第２の部分を挿入するよう構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満または等しい、請求項２の通信デバイス。
【請求項１３】
無線通信システムにおいて、少なくとも１つの第１のパケットを送信するための通信デバイスであって、前記少なくとも１つの第１のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備える通信デバイスであって、
第１の拡張ヘッダーを格納するための手段と、
少なくとも１ビットが送信のための前記第１の拡張ヘッダーにおいて利用可能かどうかを決定するための手段であって、前記少なくとも１ビットがヘッダーフィールドを占める複数のビットに付加的であり、前記決定するための手段が格納するための手段と通信する、決定するための手段と、
前記ヘッダーフィールドにおいて前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つにおいて前記第１の拡張ヘッダーの少なくとも１つの部分を挿入する手段であって、示しおよび挿入するための手段は格納するための手段または決定するための手段と通信する、示しおよび挿入するための手段と
を備える通信デバイス。
【請求項１４】
前記格納するための手段は、さらに、第２の拡張ヘッダーを格納するように構成され、前記決定のための手段は、さらに、少なくとも１ビットが、送信のために前記第２の拡張ヘッダーにおいて利用可能かどうかを決定するように構成され、前記少なくとも１ビットが、前記ヘッダーフィールドを占める複数のビットに付加的であり、示すための手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの前記少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入する、請求項１３の通信デバイス。
【請求項１５】
前記第１のパケットおよび第２のパケットを送信するための手段をさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールドおよびパッディングフィールドを備え、前記第２の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタは、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さが前記第１のパケットの前記パッディングフィールドの長さ未満または等しい、請求項１４の通信デバイス。
【請求項１６】
決定のための前記手段は前記ヘッダーフィールドを占める前記複数のビットと適合しない少なくとも１ビットを決定するようにさらに構成される請求項１３の通信デバイス。
【請求項１７】
示すための前記手段は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、プログラマブルロジックデバイス、個別のゲートロジック、トランジスターロジックおよび個別のハードウェアコンポーネントの少なくとも１つを備える請求項１３の通信デバイス。
【請求項１８】
示すための前記手段は、さらに、前記第１のパケットの前記ペイロードフィールドの始め部分において前記第１の拡張ヘッダーの少なくとも１つの部分を挿入するように構成される、請求項１３の通信デバイス。
【請求項１９】
示すための前記手段は、さらに、前記第１の拡張ヘッダーの少なくとも１部分に部分的に基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正するように構成される、請求項１８の通信デバイス。
【請求項２０】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項１３の通信デバイス。
【請求項２１】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを備える、請求項１３の通信デバイス。
【請求項２２】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの少なくとも１つの部分の長さを示す長さフィールドを備える、請求項１３の通信デバイス。
【請求項２３】
示すための前記手段は、さらに、前記第１の拡張ヘッダーの長さが前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満かあるいは等しい場合、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入するように構成される、請求項１３の通信デバイス。
【請求項２４】
前記第１パケットおよび第２のパケットを送信するための手段を備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第１の拡張ヘッダーは第１の部分および第２の部分を含み、また、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、第１のパケットのパッディングフィールドの長さ未満かあるいはそれに等しい、請求項１４の通信デバイス。
【請求項２５】
少なくとも１つの第１のパケットを無線通信システムにおいて通信する方法であって、
少なくとも１つの第１のパケットはヘッダーフィールド、ペイロードフィールド、およびパッディングフィール含む、方法であって、
前記第１の拡張ヘッダーを格納することと、
少なくとも１ビットが、送信のために、前記第１の拡張ヘッダーにおいて利用可能かどうか決定することであって、前記少なくとも１ビットが、前記ヘッダーフィールドを占める複数のビットに付加的である、決定することと、
前記第１のパケットの前記ヘッダーフィールドにおいて、前記第１の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの前記少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入すること
を備える、方法。
【請求項２６】
第２の拡張ヘッダーを格納することと、および少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能なかどうかを決定することをさらに備え、前記少なくとも１ビットは、前記ヘッダーフィールドを占める複数のビットに付加的であり、示すための前記手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、また前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するように構成される、請求項２５の方法。
【請求項２７】
前記第１のパケットおよび第２のパケットを送信することをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第２の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタが、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットにおける前記パッディングフィールドの長さ未満かあるいは等しい、請求項２６の方法。
【請求項２８】
前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定することを備える、請求項２５の方法。
【請求項２９】
前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入することをさらに備える、請求項２５の方法。
【請求項３０】
少なくとも部分的に、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さに基づいた前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正することをさらに備える、請求項２９の方法。
【請求項３１】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、コンテンツフィールドを備える、請求項２５の方法。
【請求項３２】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを含む、請求項２５の方法。
【請求項３３】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを含む、請求項２５の方法。
【請求項３４】
前記第１の拡張ヘッダーの長さが、前記第１の拡張ヘッダーのパッディングフィールドの長さ未満または等しい場合に、前記第１のパケットのパッディングフィールドに前記第１の拡張ヘッダーを挿入することをさらに備える、請求項２５の方法。
【請求項３５】
前記第１のパケットおよび第２のパケットを送信することをさらに備え、前記第２のパケットはヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、前記第１の拡張ヘッダーは、第１の部分および第２の部分を備え、前記メッセージフォーマッタが、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいは等しい、請求項２６の方法。
【請求項３６】
コンピュータに少なくとも１ビットがヘッダーフィールドを占める複数のビットに付加的である、前記少なくとも１ビットが送信のために第１の拡張ヘッダーにおいて利用可能などうかを決定させるためのコードと、
コンピュータに、前記第１のパケットの前記ヘッダーフィールドにおいて前記第１の拡張ヘッダーの存在を示させコンピュータに示させ、前記第１のパケットのペイロードフィールドおよびパッディングフィールドの少なくとも１つに前記第１の拡張ヘッダーの少なくとも１つの部分を挿入させるためにコードと
を備えたコンピュータ可読媒体を備える、コンピュータ可読製品。
【請求項３７】
コンピュータに前記第２の拡張ヘッダーを格納させ、前記ヘッダーフィールドを占める複数のビットに付加的である前記少なくとも１ビットが送信のために前記第２の拡張ヘッダーにおいて利用可能かどうか決定させるためのコードをさらに備え、示すための前記手段は、さらに、前記第１の拡張ヘッダーのフィールドにおいて前記第２の拡張ヘッダーの存在を示し、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の拡張ヘッダーの少なくとも１つの部分を挿入するよう構成される、請求項３６のコンピュータ可読製品。
【請求項３８】
コンピュータに前記第１のパケットおよび第２のパケットを送信させるための含むコードをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、パッディングフィールドを含み、また、前記第２の拡張ヘッダーは、第１の部分および第２の部分を含み、また、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドに前記第２の部分を挿入するように構成され、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいは等しい、請求項３７のコンピュータ可読製品。
【請求項３９】
コンピュータに前記ヘッダーフィールドを占める複数のビットと適合しない少なくとも１ビットを決定させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４０】
をコンピュータに前記第１のパケットの前記ペイロードフィールドの始め部分に前記第１の拡張ヘッダーの前記少なくとも１つの部分を挿入させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４１】
コンピュータに少なくとも部分的に、前記第１のパケットのヘッダーフィールドの長さに基づいて前記第１のパケットの前記ヘッダーフィールドの長さフィールドを修正させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４２】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分はコンテンツフィールドを備える、請求項３６のコンピュータ可読製品。
【請求項４３】
挿入された前記第１の拡張ヘッダーの前記少なくとも１つの部分は、フレームチェックシーケンスとティルビットを備える、請求項３６のコンピュータ可読製品。
【請求項４４】
前記第１の拡張ヘッダーの前記少なくとも１つの部分は、前記第１の拡張ヘッダーの前記少なくとも１つの部分の長さを示す長さフィールドを備える、請求項３６のコンピュータ可読製品。
【請求項４５】
前記第１の拡張ヘッダーの長さが、前記第１の拡張ヘッダーの前記パッディングフィールドの長さ未満または等しい場合に、コンピュータに、前記第１のパケットの前記パッディングフィールドに前記第１の拡張ヘッダーを挿入させるためのコードをさらに備える、請求項３６のコンピュータ可読製品。
【請求項４６】
コンピュータに、前記第１のパケットおよび第２のパケットを送信させるためのコードをさらに備え、前記第２のパケットは、ヘッダーフィールド、ペイロードフィールド、およびパッディングフィールドを備え、第１の拡張ヘッダーは第１の部分および第２の部分を備え、前記メッセージフォーマッタは、さらに、前記第１のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに第１の部分を、前記第２のパケットの前記ペイロードフィールドおよび前記パッディングフィールドの少なくとも１つに前記第２の部分を挿入するように構成され、また、前記第１の部分の長さは、前記第１のパケットの前記パッディングフィールドの長さ未満かあるいはそれに等しい、請求項３７のコンピュータ可読製品。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１２−５２００２０（Ｐ２０１２−５２００２０Ａ）
【公表日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願番号】特願２０１１−５５３０９３（Ｐ２０１１−５５３０９３）
【出願日】平成２２年３月３日（２０１０．３．３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２６１１６
【国際公開番号】ＷＯ２０１０／１０２０５５
【国際公開日】平成２２年９月１０日（２０１０．９．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＺＩＧＢＥＥ
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公表日】平成２４年８月３０日（２０１２．８．３０）
【国際特許分類】
【出願日】平成２２年３月３日（２０１０．３．３）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０２６１１６
【国際公開番号】ＷＯ２０１０／１０２０５５
【国際公開日】平成２２年９月１０日（２０１０．９．１０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＺＩＧＢＥＥ
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]