(57)【要約】【課題】高速メディアアクセス制御に関するメモリ管理【解決手段】    本明細書において開示される側面は、高速メディアアクセス制御に関するメモリ管理の必要性に対処するものである。パケットバッファは、パケット長と、シーケンス番号と、第２のデータ構造を指し示すポインタと、を具備する第１のデータ構造を有するパケットを格納することができる。パケットデータは、１つ以上の第２のデータ構造から成る連結リストに格納することができる。送信待ち行列及び受信待ち行列は、前記第１のデータ構造の連結リスト又はアレイを用いて形成することができる。第１及び第２のデータ構造を格納するためのメモリ場所を、各々のデータ構造型に関するフリーな格納場所を示すリスト内において保管することができる。２つの構成を選択することができる柔軟なメモリアーキテクチャが開示される。第１の構成においては、第１のメモリは、複数のフローに関するフロー別パラメータを具備し、第２のメモリは、パケットバッファを具備する。第２の構成においては、前記第１のメモリは、前記第２のメモリ内のフロー別パラメータを指し示すフロー別ポインタを具備する。前記パケットバッファは、第３のメモリ内に常駐する。様々なその他の側面も提示される。【選択図】        図１
2009532954.tif 000002
【特許請求の範囲】
【請求項１】
パケットバッファ内の第１のデータ構造内に、第１のパケットの長さ、前記パケットのシーケンス番号、及び前記パケットバッファ内の第２のデータ構造の第２のパケットバッファ格納場所を格納することと、
前記第１のパケットからのデータを前記格納された第２のパケットバッファ格納場所によって識別された前記第２のデータ構造内に格納すること、とを具備する、方法。
【請求項２】
前記パケットバッファ内の第３のデータ構造内に、第２のパケットの長さ、前記第２のパケットのシーケンス番号、及び前記パケットバッファ内の第４のデータ構造の第４のパケットバッファ格納場所を格納することと、
前記第２のパケットからのデータを前記格納された第４のパケットバッファ格納場所によって識別された前記第４のデータ構造内に格納することと、
前記第３のデータ構造の前記格納場所を前記第１のデータ構造内に格納すること、とを具備する請求項１に記載の方法。
【請求項３】
複数の第１のデータ構造から成る連結リストを格納することによってパケット待ち行列を形成することであって、各々の第１のデータ構造は、複数のパケットのうちの１つと関連づけられること、をさらに具備する請求項１に記載の方法。
【請求項４】
第１のデータ構造のアレイを形成することであって、各々の第１のデータ構造は、複数のパケットのうちの１つと関連づけられること、をさらに具備する請求項１に記載の方法。
【請求項５】
フリーな第１のデータ構造ポインタリストを形成することであって、前記フリーな第１のデータ構造ポインタリストは、第１のデータ構造と関連づけるための１つ以上の第１のデータ構造ポインタを具備すること、をさらに具備する請求項１に記載の方法。
【請求項６】
前記フリーの第１のデータ構造ポインタリストから第１のデータ構造ポインタを取り出すことと、
前記取り出された第１のデータ構造ポインタを前記フリーな第１のデータ構造ポインタリストから取り除くこと、
前記取り出された第１のデータ構造ポインタによって識別された前記パケットバッファ内の格納場所に前記第１のデータ構造を格納すること、とをさらに具備する請求項５に記載の方法。
【請求項７】
以前に取り除かれた第１のデータ構造ポインタを前記フリーな第１のデータ構造ポインタリストに追加して前記第１のデータ構造を前記パケットバッファから取り除くことをさらに具備する請求項５に記載の方法。
【請求項８】
フリーな第２のデータ構造ポインタリストを形成することであって、前記フリーな第２のデータ構造ポインタリストは、第２のデータ構造と関連づけるための１つ以上のポインタを具備することをさらに具備する請求項１に記載の方法。
【請求項９】
前記フリーな第２のデータ構造ポインタリストから第２のデータ構造ポインタを取り出すことと、
前記取り出された第２のデータ構造ポインタを前記フリーな第２のデータ構造ポインタリストから取り除くこと、
前記取り出された第２のデータ構造ポインタを前記第１のデータ構造の前記第２のパケットバッファ格納場所に格納すること、とをさらに具備する請求項８に記載の方法。
【請求項１０】
前記取り出された第２のデータ構造ポインタによって識別された前記パケットバッファ内の格納場所に前記第２のデータ構造を格納することをさらに具備する請求項９に記載の方法。
【請求項１１】
以前に取り除かれた第２のデータ構造ポインタを前記フリーな第２のデータ構造ポインタリストに追加して前記第２のデータ構造を前記パケットバッファから取り除くことをさらに具備する請求項８に記載の方法。
【請求項１２】
前記パケットバッファ内の前記第２のデータ構造の前記第２のパケットバッファ格納場所は、前記第１のデータ構造の第２のデータ構造ポインタフィールドに格納され、前記パケットバッファから第２のデータ構造を取り出すことであって、前記第２のデータ構造は、前記第１のデータ構造の前記第２のデータ構造ポインタフィールドによって識別されること、をさらに具備する請求項１１に記載の方法。
【請求項１３】
装置であって、
パケットバッファ内の第１のデータ構造内に、第１のパケットの長さ、前記パケットのシーケンス番号、及び前記パケットバッファ内の第２のデータ構造の第２のパケットバッファ格納場所を格納するための手段と、
前記第１のパケットからのデータを前記格納された第２のパケットバッファ格納場所によって識別された前記第２のデータ構造内に格納するための手段と、を具備する、装置。
【請求項１４】
前記パケットバッファ内の第３のデータ構造内に、第２のパケットの長さ、前記第２のパケットのシーケンス番号、及び前記パケットバッファ内の第４のデータ構造の第４のパケットバッファ格納場所を格納するための手段と、
前記第２のパケットからのデータを前記格納された第４のパケットバッファ格納場所によって識別された前記第４のデータ構造内に格納するための手段と、
前記第３のデータ構造の前記格納場所を前記第１のデータ構造内に格納するための手段と、を具備する請求項１３に記載の装置。
【請求項１５】
複数の第１のデータ構造から成る連結リストを格納することによってパケット待ち行列を形成するための手段であって、各々の第１のデータ構造は、複数のパケットのうちの１つと関連づけられている手段、をさらに具備する請求項１３に記載の装置。
【請求項１６】
第１のデータ構造のアレイを形成するための手段であって、各々の第１のデータ構造は、複数のパケットのうちの１つと関連づけられる手段、をさらに具備する請求項１３に記載の装置。
【請求項１７】
装置であって、
複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて構成され、
前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて構成される第１のメモリであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す第１のメモリと、
前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて構成され、
前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて構成される第２のメモリであって、１つ以上のパラメータから成る各々の組は、前記各々の通信フローと関連づけられた前記ポインタによって示される前記格納場所において格納される第２のメモリと、
前記複数の通信フローの各々に関するパケットを格納するために動作可能なように前記第２のモードにおいて構成された、第３のメモリとともに動作可能なメモリインタフェースと、
選択されたモードを前記第１のモード又は前記第２のモードとして選択し、前記選択されたモードに従って前記第１のメモリを構成し、前記選択されたモードに従って前記第２のメモリを構成し、前記選択されたモードに従って前記メモリインタフェースを構成するプロセッサと、を具備する、装置。
【請求項１８】
前記第２のメモリは、前記第１のモードにおいて構成されたときには、パケットバッファを具備し、前記パケットバッファは、
パケットと関連づけられた第１のデータ構造と、
前記関連づけられたパケットからのデータを具備する第２のデータ構造と、を具備し、前記第１のデータ構造は、
前記関連づけられたパケットの長さを示す長さフィールドと、
前記関連づけられたパケットの前記シーケンス番号を示すシーケンス番号フィールドと、
前記第２のデータ構造の前記パケットバッファ内における前記格納場所を示すシーケンス番号フィールドと、
前記第２のデータ構造の前記パケットバッファ内における前記格納場所を示す第２のデータ構造ポインタフィールドと、を具備する請求項１７に記載の装置。
【請求項１９】
前記メモリインタフェースは、前記第２のモードにおいて構成されたときには、パケットバッファ内のパケットを前記第３のメモリに格納するために動作可能であり、  
前記メモリインタフェースは、
パケットと関連づけられた第１のデータ構造と、
前記関連づけられたパケットからのデータを具備する第２のデータ構造と、を格納し、
前記第１のデータ構造は、
前記関連づけられたパケットの前記長さを示す長さフィールドと、
前記関連づけられたパケットの前記シーケンス番号を示すシーケンス番号フィールドと、
前記第２のデータ構造の前記パケットバッファ内の前記格納場所を示す第２のデータ構造ポインタフィールドと、を具備する請求項１８に記載の装置。
【請求項２０】
無線通信デバイスであって、
第１の集積回路であって、
複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて構成され、
前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて構成された第１のメモリであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す第１のメモリと、
前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて構成され、
前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて構成された第２のメモリであって、１つ以上のパラメータから成る各々の組は、前記各々の通信フローと関連づけられた前記ポインタによって示される前記格納場所において格納される第２のメモリと、
前記複数の通信フローの各々に関するパケットを格納するために動作可能なように前記第２のモードにおいて構成された、第３のメモリとともに動作可能なメモリインタフェースと、
選択されたモードを前記第１のモード又は前記第２のモードとして選択し、前記選択されたモードに従って前記第１のメモリを構成し、前記選択されたモードに従って前記第２のメモリを構成し、前記選択されたモードに従って前記メモリインタフェースを構成するプロセッサと、を具備する、第１の集積回路と、
前記第１の集積回路の前記メモリインタフェースと結合され、前記複数の通信フローの各々に関するパケットを格納する第３のメモリを具備する第２の集積回路と、を具備する、無線通信デバイス。
【請求項２１】
無線通信デバイスであって、
複数の通信フローの各々に関する１つ以上のパラメータを格納する第１のメモリと、
前記複数の通信フローの各々に関するパケットを格納する第２のメモリであって、パケットと関連づけられた第１のデータ構造と、  
前記関連づけられたパケットからのデータを具備する第２のデータ構造と、を具備する第２のメモリと、を具備し、
前記第１のデータ構造は、
前記関連づけられたパケットの長さを示す長さフィールドと、
前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、
前記第２のデータ構造の前記第２のメモリ内における前記格納場所を示す第２のデータ構造ポインタフィールドと、を具備する、無線通信デバイス。
【請求項２２】
前記第１のデータ構造は、第２の第１のデータ構造の前記第２のメモリ内における前記格納場所を示す次の第１のデータポインタフィールドをさらに具備する請求項２１に記載の無線通信デバイス。
【請求項２３】
複数のパケットから成るパケット待ち行列であって、複数の第１のデータ構造の連結リストによって形成される待ち行列をさらに具備し、各々の第１のデータ構造は、前記複数のパケットのうちの１つと関連づけられ、前記待ち行列の順序は、各々の第１のデータ構造の次の第１のデータポインタフィールドに従って前記連結リスト内の前記複数の第１のデータ構造の各々をリンクすることによって決定される請求項２２に記載の無線通信デバイス。
【請求項２４】
命令を含むコンピュータによって読み取り可能な媒体であって、前記命令は、
第１又は第２のモードを選択するための命令と、
複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて第１のメモリを構成するための命令と、
前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて前記第１のメモリを構成するための命令であって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す命令と、
前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて第２のメモリを構成するための命令と、
前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて前記第２のメモリを構成するための命令であって、１つ以上のパラメータから成る各々の組は、前記各々の通信フローと関連づけられた前記ポインタによって示される前記格納場所内に格納される命令と、
前記複数の通信フローの各々に関するパケットを格納するために動作可能であるように前記第２のモードにおいて第３のメモリとともに動作可能なメモリインタフェースを構成するための命令と、を具備する、コンピュータによって読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
３５Ｕ．Ｓ．Ｃ．§１１９に基づく優先権の主張  
本特許出願は、“High Speed Media Access Control”（高速メディアアクセス制御）という題名を有し、本特許出願の譲受人に対して譲渡されており、本明細書において参照されることによって明示で本明細書に組み入れられている仮特許出願番号６０／７８７，９１５（出願日：２００６年３月３１日）に対する優先権を主張するものである。
【０００２】
本発明は、一般的には、無線通信に関するものである。本発明は、高速メディアアクセス制御に関するものである。
【背景技術】
【０００３】
無線通信システムは、音声及びデータ等の様々な型の通信を提供することを目的として広範囲にわたって採用されている。典型的無線データシステム、又はネットワークは、１つ以上の共有資源へのアクセスを多数のユーザーに提供する。システムは、周波数分割多重（ＦＤＭ）、時分割多重（ＴＤＭ）、符号分割多重（ＣＤＭ）、直交周波数分割多重（ＯＦＤＭ）、等の様々な多元接続技術を用いることができる。
【０００４】
無線ネットワーク例は、セルラー方式のデータシステムを含む。いくつかのこれらの例は次のとおりである。すなわち、（１）デュアルモード広帯域拡散スペクトルセルラーシステムに関するＴＩＡ／ＥＩＡ−９５−Ｂ移動局−基地局適合性基準（ＩＳ−９５基準）、（２）“第三世代パートナーシッププロジェクト”（３ＧＰＰ）と呼ばれるコンソーシアムによって提供され、文書番号３Ｇ  ＴＳ  ２５．２１１，３Ｇ  ＴＳ  ２５．２１２，  ３Ｇ  ＴＳ  ２５．２１３，及び３Ｇ  ＴＳ  ２５．２１４を含む一組の文書において具体化されている基準（Ｗ−ＣＤＭＡ基準）、（３）“第三世代パートナーシッププロジェクト２”（３ＧＰＰ２）と呼ばれるコンソーシアムによって提供され、“ｃｄｍａ２０００拡散スペクトルシステムに関するＴＲ−４５．５物理レイヤ基準”において具体化されている基準（ＩＳ−２０００基準）、及び（４）ＴＩＡ／ＥＩＡ／ＩＳ−８５６基準（ＩＳ−８５６基準）に準拠する高データ速度（ＨＤＲ）システム。
【０００５】
その他の無線システム例は、ＩＥＥＥ  ８０２．１１基準（すなわち、８０２．１１（ａ）、（ｂ）、又は（ｇ））等の無線ローカルエリアネットワーク（ＷＬＡＮ）を含む。これらのネットワークの改良は、直交周波数分割多重（ＯＦＤＭ）変調技術を具備する多入力多出力（ＭＩＭＯ）ＷＬＡＮを採用する際に達成させることができる。以前の８０２．１１基準のサービスの質（ＱｏＳ）上の欠点を改良することを目的としたＩＥＥＥ８０２．１１（ｅ）が導入されている。
【０００６】
現在は、高速無線ネットワーク及びこれらのネットワークとともに動作するためのＭＡＣプロトコルを定義する８０２．１１（ｎ）仕様を導入中である。以前の８０２．１１基準は、主にデータ転送、ブラウジング及び電子メール型のアプリケーションに関するものである。８０２．１１（ｎ）は、高いスループット、性能の強固さ及びサービスの質を要求するマルチメディア配信アプリケーションを対象とすることが意図されている。これらの要求に伴い、サービスの質および高速での動作性を提供するための効率的な実装及び技術が必要である。従って、効率的な高速メディアアクセス制御が必要である。
【発明の開示】
【発明の概要】
【０００７】
本明細書において開示される側面は、効率的な高速メディアアクセス制御の必要性に対処するものである。
【０００８】
一側面により、パケットと関連づけられた第１のデータ構造と、前記関連づけられたパケットからのデータを具備する第２のデータ構造と、を含む装置が説明され、前記第１のデータ構造は、前記関連づけられたパケットの長さを示す長さフィールドと、前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、前記第２のデータ構造のパケットバッファ内における格納場所を示す第２のデータ構造ポインタフィールドと、を具備する。
【０００９】
他の側面により、関連づけられたパケットからのデータを具備する第２のデータ構造とともに動作可能であり、前記関連づけられたパケットの長さを示す長さフィールドと、前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、前記第２のデータ構造のメモリ内における格納場所を格納するポインタフィールドと、を含む第１のデータ構造が説明される。
【００１０】
他の側面により、パケットバッファ内の第１のデータ構造において、第１のパケットの長さ、前記パケットのシーケンス番号、及び前記パケットバッファ内の第２のデータ構造の第２のパケットバッファ格納場所を格納し、前記第１のパケットからのデータを前記格納された第２のパケットバッファ格納場所によって識別された前記第２のデータ構造内に格納するための方法が開示される。
【００１１】
他の側面により、複数のパケットをパケットバッファ内に格納するための方法が開示され、各パケットは、関連づけられた第１のデータ構造及び１つ以上の関連づけられた第２のデータ構造とともに格納され、前記１つ以上の第２のデータ構造は、連結リスト内において形成され、各第１のデータ構造は、前記関連づけられたパケットの長さを示す長さフィールドと、前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、前記１つ以上の第２のデータ構造のうちの最初のデータ構造のパケットバッファ内における格納場所を示す第２のデータ構造ポインタフィールドと、を具備し、各第２のデータ構造は、前記関連づけられたパケットからのデータと、存在する場合に前記各々の連結リスト内における次の第２の構造を示す次の第２のデータ構造ポインタフィールドと、を具備する。
【００１２】
他の側面により、パケットバッファ内の第１のデータ構造において、第１のパケットの長さ、前記パケットのシーケンス番号、及び前記パケットバッファ内における第２のデータ構造の第２のパケットバッファ格納場所を格納するための手段と、前記第１のパケットからのデータを前記格納された第２のパケットバッファ格納場所によって識別される前記第２のデータ構造内に格納するための手段と、を含む装置が説明される。
【００１３】
他の側面により、パケットと関連づけられた第１のデータ構造と、前記関連づけられたパケットからのデータを具備する１つ以上の第２のデータ構造と、前記第２のデータ構造のうちの１つ以上の中に前記パケットを格納するための手段と、を含む装置が説明され、前記第１のデータ構造は、前記関連づけられたパケットの長さを示す長さフィールドと、前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、前記第２のデータ構造のうちの１つのデータ構造のパケットバッファ内における格納場所を示す第２のデータ構造ポインタフィールドと、を具備する。
【００１４】
他の側面により、複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて構成され、前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて構成された第１のメモリであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す第１のメモリと、前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて構成され、前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて構成される第２のメモリであって、１つ以上のパラメータから成る各組は、前記各々の通信フローと関連づけられた前記ポインタによって示された前記格納場所において格納される第２のメモリと、前記複数の通信フローの各々に関するパケットを格納するために動作可能であるように前記第２のモードにおいて構成された、第３のメモリとともに動作可能なメモリインタフェースと、選択されたモードを前記第１のモード又は前記第２のモードとして選択し、前記第１のメモリを前記選択されたモードに従って構成し、前記第２のメモリを前記選択されたモードに従って構成し、前記メモリインタフェースを前記選択されたモード従って構成するプロセッサと、を含む装置が説明される。
【００１５】
他の側面により、複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて構成され、前記複数の通信フローの各々に関するポインタを格納するように第２のモードに構成された第１のメモリであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す第１のメモリと、前記複数の通信フローの各々に関するパケットを格納するように第１のモードにおいて構成され、前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて構成された第２のメモリであって、１つ以上のパラメータから成る各組は、前記各々の通信フローと関連づけられた前記ポインタによって示された前記格納場所内に格納される第２のメモリと、前記複数の通信フローの各々に関するパケットを格納するために動作可能であるように前記第２のモードにおいて構成された、第３のメモリとともに動作可能なメモリインタフェースと、選択されたモードを前記第１のモード又は前記第２のモードとして選択し、前記第１のメモリを前記選択されたモードに従って構成し、前記第２のメモリを前記選択されたモードに従って構成し、前記メモリインタフェースを前記選択されたモード従って構成するプロセッサと、を具備する第１の集積回路と、前記複数の通信フローの各々に関するパケットを格納するための第３のメモリを具備し、前記第１の集積回路の前記メモリインタフェースと結合された第２の集積回路と、を含む無線通信デバイスが説明される。
【００１６】
他の側面により、複数の通信フローの各々に関する１つ以上のパラメータを格納する第１のメモリと、前記複数の通信フローの各々に関するパケットを格納し、パケットと関連づけられた第１のデータ構造を具備する第２のメモリと、前記関連づけられたパケットからのデータを具備する第２のデータ構造と、を含む無線通信デバイスが説明され、前記第１のデータ構造は、前記関連づけられたパケットの長さを示す長さフィールドと、前記関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールドと、前記第２のデータ構造の前記第２のメモリ内における格納場所を示す第２のデータ構造ポインタフィールドと、を具備する。
【００１７】
他の側面により、複数の通信フローの各々に関するポインタを格納する第１のメモリであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す第１のメモリと、前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納する第２のメモリであって、１つ以上のパラメータから成る各組は、前記各々の通信フローと関連づけられた前記ポインタによって示される前記格納場所に格納される第２のメモリと、前記複数の通信フローの各々に関するパケットを格納する第３のメモリと、を含む無線通信デバイスが説明される。
【００１８】
他の側面により、第１又は第２のモードを選択するための手段と、複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて第１のメモリを構成するための手段と、前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて前記第１のメモリを構成するための手段であって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示す手段と、前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて第２のメモリを構成するための手段と、前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて前記第２のメモリを構成するための手段であって、１つ以上のパラメータから成る各組は、前記各々の通信フローと関連づけられた前記ポインタによって示される前記格納場所に格納される手段と、前記複数の通信フローの各々に関するパケットを格納するために動作可能であるように前記第２のモードにおいて第３のメモリとともに動作可能なメモリインタフェースを構成するための手段と、を含む装置が説明される。
【００１９】
他の側面により、第１又は第２のモードを選択することと、複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて第１のメモリを構成することと、前記複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて前記第１のメモリを構成することであって、各ポインタは、前記各々の通信フローと関連づけられた格納場所を示すことと、
前記複数の通信フローの各々に関するパケットを格納するように前記第１のモードにおいて第２のメモリを構成することと、前記複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように前記第２のモードにおいて前記第２のメモリを構成することであって、１つ以上のパラメータから成る前記各々の組は、前記各々通信フローと関連づけられた前記ポインタによって示される前記格納場所に格納されることと、前記複数の通信フローの各々に関するパケットを格納するために動作可能であるように前記第２のモードにおいて第３のメモリとともに動作可能なメモリインタフェースを構成すること、とを実行するために動作可能であるコンピュータによって読み取り可能な媒体が説明される。
【発明を実施するための最良の形態】
【００２０】
様々な側面が以下において詳細に説明され、これらの側面のうちの１つ以上を所定の実施形態において結合させることができる。本明細書において開示される側面は、超高ビットレートＷＬＡＮ物理層（又は新しく出現しつつある送信技術を用いる同様のアプリケーション）によって非常に効率的な動作をサポートする。ＷＬＡＮ例は、２つの周波数帯域モード２０ＭＨｚ及び４０ＭＨｚにおいて動作可能である。ＷＬＡＮ例は、１００Ｍｂｐｓ（１００万ビット／秒）を超えるビットレートをサポートし、２０ＭＨｚのチャネル帯域幅における最大で３００Ｍｂｐｓ、及び４０ＭＨｚのチャネル帯域幅における最大で６００Ｍｂｐｓを含む。様々な代替ＷＬＡＮもサポートされ、２つ以上の周波数帯域モード、及びあらゆる数のサポートされたビットレートを有する代替ＷＬＡＮを含む。
【００２１】
様々な側面は、レガシーＷＬＡＮシステムの分散型調整動作の単純さ及び強固さを保持し、該システムの例が８０２．１１（ａ−ｇ）に示される。様々な実施形態の利点は、該レガシーシステムとの後方互換性を維持しながら達成させることができる。（以下の説明においては、８０２．１１システムは、レガシーシステム例として説明することができる点に注目すること。当業者は、改良点が代替システム及び基準とも適合可能であることを認識するであろう。）
本明細書において説明される１つ以上の典型的側面は、無線データ通信システムを対象として詳述される。この範囲内における使用が有利である一方で、異なる環境又は構成においては開示の異なる実施形態を組み入れることができる。一般的には、本明細書において説明される様々なシステムは、ソフトウェアによって制御されるプロセッサ、集積回路、又は個別論理を用いて形成することができる。アプリケーション全体を通じて言及されることがあるデータ、命令、コマンド、情報、信号、シンボル、及びチップは、有利なことに、電圧、電流、電磁波、磁界、磁粒子、光学界、光学粒子、又はそのあらゆる組合せによって表される。さらに、各ブロック図において示されるブロックは、ハードウェア又は方法上のステップを表すことができる。方法上のステップは、本開示の適用範囲から逸脱せずに互換可能である。「典型的な」という表現は、本明細書においては、“１つの例、事例、又は実例”を意味するために用いられる。本明細書において“典型的な”実施形態として説明されているいずれの実施形態も、その他の実施形態よりも好ましい又は有利であるとは必ずしも解釈すべきではない。
【００２２】
図１は、１つ以上のユーザー端末（ＵＴ）１０６Ａ乃至Ｎに接続されたアクセスポイント（ＡＰ）１０４を具備するシステム１００の典型的実施形態を示す。８０２．１１用語により、本明細書においては、ＡＰ及びＵＴは、局又はＳＴＡとも呼ばれる。本明細書において説明される技術及び側面は、その他の型のシステムに対しても適用可能である（例は、上記において詳述されるセルラー基準を含む）。基地局という用語は、アクセスポイントという用語とし互換的に用いることができる。ユーザー端末という用語は、ユーザー装置（ＵＥ）、加入者ユニット、加入者局、アクセス端末、遠隔端末、移動局、又は当業において知られるその他の対応する用語と互換的に用いることができる。移動局という用語は、固定された無線アプリケーションを包含する。
【００２３】
ユーザー端末１０６は、互いに直接通信することができる点にも注目すること。８０２．１１（ｅ）によって導入されたダイレクトリンクプロトコル（ＤＬＰ）は、ＳＴＡが（同じＡＰによって制御される）ベーシックサービスセット（ＢＳＳ）内の他の宛先ＳＴＡに直接フレームを転送するのを可能にする。様々な実施形態においては、当業において知られるように、アクセスポイントは要求されない。例えば、独立ＢＳＳ（ＩＢＳＳ）は、ＳＴＡのあらゆる組合せによって形成することができる。当業において知られる夥しい数の通信フォーマットのうちのいずれかを用いて無線ネットワーク１２０を介して互いに通信するユーザー端末のアドホックネットワークを形成することができる。
【００２４】
ＡＰ及びＵＴは、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）１２０を介して通信する。以下において詳述される実施形態においては、ＷＬＡＮ１２０は、高速ＭＩＭＯ  ＯＦＤＭシステムである。しかしながら、ＷＬＡＮ１２０は、あらゆる無線ＬＡＮであることができる。オプションとして、アクセスポイント１０４は、ネットワーク１０２を介してあらゆる数の外部デバイス又はプロセスと通信する。ネットワーク１０２は、インターネット、イントラネット、又はその他の何らかの有線、無線、又は光学のネットワークであることができる。接続１１０は、ネットワークからアクセスポイント１０４に物理層信号を搬送する。デバイス又はプロセスは、ネットワーク１０２に接続するか又はＷＬＡＮ１２０においてＵＴとして（又はＵＴとの接続を介して）接続することができる。ネットワーク１０２又はＷＬＡＮ１２０のいずれかに接続することができるデバイス例は、電話、パーソナルデジタルアシスタント（ＰＤＡ）、様々な型のコンピュータ（あらゆる型のラップトップ、パソコン、ワークステーション、端末）、ビデオ装置、例えばカメラ、カムコーダー、ウェブカム、及び実質的にその他のあらゆる型のデータデバイスを含む。プロセスは、音声、映像、データ通信、等を含むことができる。様々なデータストリームは、様々なサービスの質（ＱｏＳ）技術を用いることによって対処することができる様々な送信要求を有することができる。
【００２５】
システム１００は、集中型ＡＰ  １０４とともに採用することができる。一実施形態においてはすべてのＵＴ  １０６がＡＰと通信する。代替実施形態においては、当業者にとって明らかになるように、システムを修正することによって２つのＵＴ間における直接ピアツーピア通信を受け入れることができ、その幾つかの例が以下に示される。指定されたアクセスポイントをサポートする実施形態においては、いずれの局も指定ＡＰとしてセットアップすることができる。アクセスは、ＡＰ、又はアドホックによって（すなわち、コンテンションに基づいて）管理することができる。
【００２６】
一実施形態においては、ＡＰ  １０４は、イーサネット（登録商標）適合化を提供する。この場合は、ネットワーク１０２への接続を提供するためにＡＰに加えてＩＰルーターを採用することができる（詳細は示されていない）。イーサネットフレームは、ＷＬＡＮサブネットワーク（以下において詳述）を通じてルーターとＵＴとの間で転送することができる。イーサネット適合化及び接続性は、当業においてよく知られる。
【００２７】
代替実施形態においては、ＡＰ  １０４は、ＩＰ適合化を提供する。この場合は、ＡＰは、接続されたＵＴの組に関するゲートウェイルーターとして行動する（詳細は示されない）。この場合は、ＩＰデータグラムをＡＰ  １０４によってＵＴ １０６へ又はＵＴ １０６からルーティングすることができる。ＩＰ適合化及び接続性は、当業においてよく知られる。
【００２８】
図２は、アクセスポイント１０４又はユーザー端末１０６として構成することができる無線通信デバイスの側面を示す。無線通信デバイスは、システム１００における採用に適するＳＴＡ例である。
【００２９】
プロセッサ２１０は、通信を実行するためのタスクを含む無線通信デバイスに関する様々なタスクを実行するために採用される。この例においては、プロセッサ２１０は、本明細書においては“ファームウェア”タスクと呼ばれるタスクを実行する。説明を単純化するため、以下において詳述される実施形態においては、ファームウェアへの言及は、プロセッサ２１０によって実行される該タスクと、その他の様々な構成要素又はブロックと関連して実行されるタスクと、を含む。プロセッサ２１０は、汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、又は特殊目的のプロセッサであることができる。プロセッサ２１０は、様々なタスクにおいて援助するために特殊目的のハードウェアと接続することができる（詳細は示されない）。様々なアプリケーションは、外部接続されたプロセッサ、例えば外部接続されたコンピュータ、において又はネットワーク接続を通じて実行することができ、無線通信デバイス１０４又は１０６（示されていない）内の追加のプロセッサにおいて実行することができ、又はプロセッサ２１０自体において実行することができる。
【００３０】
プロセッサ２１０は、データ及び本明細書において説明される様々な手順及び方法、又はその他の数多くの手順又は方法を実行するための命令を格納するために用いることができるメモリ２２０と接続された状態が示される。メモリ２２０は、全体又は一部をプロセッサ２２０内に埋め込むことができる様々な型の１つ以上のメモリ構成要素を具備できることを当業者は認識するであろう。Ｉ／Ｏ２３０は、プロセッサ２１０に接続された状態で示され、１つ以上の入力及び／又は出力機能を具備することができ、その例は、当業においてよく知られる。
【００３１】
メディアアクセス制御（ＭＡＣ）プロセッサ２４０は、プロセッサ２１０に接続される。以下において詳述される実施形態の多くにおいては、ＭＡＣプロセッサ２４０は、ライン速度でのパケットの高速処理を行う。一般的には、より低いレートでの処理、すなわち“ファームウェア”タスクが、典型的にはＭＡＣプロセッサ２４０によって取り扱われる“ライン速度”処理と関連させてプロセッサ２１０によって実行される。ＭＡＣプロセッサ２４０は、送信用データをＷＬＡＮ１２０における送信のために物理層（ＰＨＹ）２６０に引き渡し、ＷＬＡＮ１２０において受信されたＰＨＹ２６０からのデータを処理する。プロセッサ２１０は、物理層データを受信して処理し、（一般的には以下において詳述される例においてＭＡＣプロセッサ２４０と関連して）発信フローに関するパケットを形成することもできる。ＰＨＹ２６０に又はＰＨＹ２６０から引き渡されるデータのフォーマットは、無線通信デバイス１０４又は１０６によってサポートされる通信システム又は複数の通信システムの仕様に準拠する。
【００３２】
ＭＡＣプロセッサ２４０は、ネットワーク１０２の物理層に関する要求事項に従って接続１１０を介してデータを受信及び送信する。オプションのネットワークプロセッサ２８０は、オプションのネットワーク接続１１０においてネットワーク１０２の物理層に従って受信及び送信するために採用することができる。ネットワークプロセッサは、データを受信し、いずれかの型のデータフォーマットを用いてＭＡＣプロセッサ２４０にデータを引き渡すことができる。データパケット例が以下においてさらに詳細に説明される（これらの及び代替のデータフォーマットは、当業者によく知られることになるであろう）。これらのデータは、本明細書においてはフローと呼ぶことができる。フローは、異なる特徴を有することができ、フローと関連づけられたアプリケーションの型に基づいて異なる処理を要求することができる。例えば、映像又は音声は、低レーテンシーフローの特徴を有するとみなすことができる（映像は、一般的には、スループットに関して音声よりも厳しい要求を有する）。多くのデータアプリケーションは、映像の場合よりもレーテンシーの影響を受けにくいが、データ完全性に関してはより厳しい要求を有することがある（すなわち、音声は、ある程度のパケット損失に耐えることができ、ファイル転送は、一般的にはパケット損失は許容されない）。
【００３３】
ＭＡＣプロセッサ２４０は、フローデータを受信し、そのプロセスは、入力（ｉｎｇｒｅｓｓ）と呼ばれ、フローデータパケットをパケットバッファ２５０に格納する。ＭＡＣプロセッサ２４０は、送信又はＴＸと呼ばれるＷＬＡＮ１２０での送信のためにパケットを取り出し、これらのパケットをＰＨＹ２６０に引き渡す。ＷＬＡＮ１２０において受信又はＲＸと呼ばれる受信が行われたパケットは、ＰＨＹ２６０からＭＡＣプロセッサ２４０に引き渡され、ＭＡＣプロセッサ２４０は、これらのパケットをパケットバッファ２５０に格納する。ＭＡＣプロセッサ２４０は、ネットワーク接続１１０（又はオプションのネットワークプロセッサ２８０）における引き渡しのためにＲＸパケットをパケットバッファ２５０から取り出し、このプロセスは、出力（ｅｇｒｅｓｓ）と呼ばれる。パケットバッファ２５０の実施形態例が以下において詳述される。以下において詳述される様々な実施形態は、入力、送信、受信、及び出力に関して高速パケット処理を実行するための側面を識別する。
【００３４】
示されている例においては、入力及び出力はネットワーク１１０に関して識別され、ＲＸ及びＴＸはＷＬＡＮ１２０に関して識別される一方で、ＭＡＣプロセッサ２４０は、出力又は入力機能、及びあらゆる型の受信又は送信機能とともに動作するために適切に展開することができる。フロー分類をドライバによって行うことができ、該ドライバは、当業においてよく知られるように、プロセッサ２１０又はネットワークプロセッサ２８０において、又はその他の適切な構成要素において含めることができる。様々なデータ型、フォーマット、フロークラス等のＭＡＣ処理を許容するために様々なドライバを採用することができる。
【００３５】
ＷＬＡＮに関連する制御及びシグナリング（すなわち、８０２．１１又はその他の基準）は、ＡＰと様々なＵＴとの間でも通信することができる。物理層（ＰＨＹ）プロトコルデータユニット（ＰＰＤＵ）においてカプセル化されたＭＡＣプロトコルデータユニット（ＭＰＤＵ）が、ＰＨＹ２６０に引き渡される又はＰＨＹ２６０から受け取られる。ＭＰＤＵは、フレームと呼ばれることもある。単一のＭＰＤＵが単一のＰＰＤＵにおいてカプセル化されるときには、ＰＰＤＵはフレームと呼ばれることもある。代替実施形態は、いずれかの変換技術を採用することができ、代替実施形態においては用語が異なることがある。様々なＭＡＣ  ＩＤに対応するフィードバックを様々な目的でＰＨＹ２６０から戻すことができる。フィードバックは、あらゆる物理層情報を具備することができ、チャネル（ユニキャストトラフィック／パケットに加えてマルチキャストを含む）に関するサポート可能なレート、変調フォーマット、及び様々なその他のパラメータを含む。
【００３６】
ＰＨＹ２６０は、いずれかの型のトランシーバであることができる（及び受信機及び送信機の両方を含むことができるが、代替実施形態においてはいずれも採用することができる）。一実施形態においては、ＰＨＹ２６０は、多入力多出力（ＭＩＭＯ）又は多入力単出力（ＭＩＳＯ）インタフェースとともに動作可能な直交周波数分割多重（ＯＦＤＭ）トランシーバを含む。
【００３７】
ＭＩＭＯ、及びＭＩＳＯは、当業者には既知である。“FREQUENCY-INDEPENDENT SPATIAL-PROCESSING FOR WIDEBAND MISO AND MIMO SYSTEMS”（広帯域ＭＩＳＯ及びＭＩＭＯシステムに関する周波数から独立した空間処理）という題名を有し、本特許出願の譲受人に譲渡されており、本明細書において参照されることによって本明細書に組み入れられている同時係属米国特許出願一連番号１０／６５０，２９５（出願日：２００３年８月２７日）においてＯＦＤＭ、ＭＩＭＯ及びＭＩＳＯの様々なトランシーバ例が詳述される。代替実施形態は、単入力多出力（ＳＩＭＯ）又は単入力単出力（ＳＩＳＯ）システムを含むことができる。
【００３８】
ＰＨＹ２６０は、アンテナ２７０Ａ乃至Ｎと接続された状態が示される。様々な実施形態においてあらゆる数のアンテナをサポートすることができる。アンテナ２７０は、ＷＬＡＮ１２０において送信及び受信するために用いることができる。
【００３９】
ＰＨＹ２６０は、１つ以上のアンテナ２７０の各々と通信する空間プロセッサを具備することができる。空間プロセッサは、各アンテナに関して独立して送信のためにデータを処理すること又は全アンテナにおける受信信号をまとめて処理することができる。独立した処理の例は、チャネル推定値、ＵＴからのフィードバック、チャネル反転、又は当業において知られる様々なその他の技術に基づくことができる。処理は、様々な空間処理技術のうちのいずれかを用いて実行される。この型の様々なトランシーバは、所定のユーザー端末への又は所定のユーザー端末からのスループットを向上させるためにビーム形成技術、ビーム操作技術、固有操作技術、又はその他の空間技術を利用して送信することができる。ＯＦＤＭシンボルが送信される幾つかの実施形態においては、空間プロセッサは、各々のＯＦＤＭ副搬送波（トーンとも呼ばれる）、又はビンを処理するための副空間プロセッサを具備することができる。
【００４０】
システム例においては、ＡＰ（又はＵＴ等のあらゆるＳＴＡ）は、Ｎのアンテナを有することができ、ＵＴ例はＭのアンテナを有することができる。従って、ＡＰとＵＴとのアンテナ間にはＭ×Ｎの経路が存在する。当業においては、これらの複数の経路を用いてスループットを向上させる様々な空間技術が知られる。空間時間送信ダイバーシティ（ＳＴＴＤ）システム（“ダイバーシティ”とも呼ばれる）においては、送信データがフォーマット化及び符号化され、単一のデータストリームとして全アンテナを通じて送信される。Ｍの送信アンテナ及びＮの受信アンテナが存在することで、形成可能なＭＩＮ（Ｍ，Ｎ）の独立したチャネルが存在することができる。空間多重化は、これらの独立した経路を利用し、送信速度を上昇させるために独立した経路の各々において異なるデータを送信することができる。
【００４１】
ＡＰとＵＴとの間におけるチャネルの特性を学ぶための又は前記特性に合わせて適合化するための様々な技術が知られる。各送信アンテナからは一意のパイロットを送信することができる。この場合においては、パイロットは、各受信アンテナにおいて受信及び測定される。次に、送信の際に用いるためにチャネル状態情報フィードバックを送信デバイスに戻すことができる。測定されたチャネル行列の固有分解を行ってチャネル固有モードを決定することができる。受信機におけるチャネル行列の固有の分解を回避する代替技術は、パイロット及びデータの固有操作を用いて受信機における空間処理を単純化することである。
【００４２】
従って、現在のチャネル状態に依存し、システム全体の様々なユーザー端末に送信するために様々なデータレートを利用可能である。ＰＨＹ ２６０は、ＡＰとＵＴとの間における物理的リンクに関していずれの空間処理が用いられているかに基づいてサポート可能なレートを決定することができる。この情報は、ＭＡＣ処理において用いるためにフィードバックすることができる。
【００４３】
一側面においては、アクセスポイント及びユーザー端末の両方を含む無線通信デバイスにおけるＭＡＣ処理をサポートするための単一のＡＳＩＣ特定用途向け集積回路（ＡＳＩＣ）が提供される。図３及び４は、ユーザー端末１０６及びアクセスポイント１０４において用いるために構成された該ＡＳＩＣ ３１０を概念的にそれぞれ示す。
【００４４】
図３においては、ＭＡＣプロセッサＡＳＩＣ ３１０は、ユーザー端末１０６に関する構成例が示される。この構成においては、上述されるＭＡＣプロセッサ２４０は、ハードウェアテーブル３２０に接続される。ハードウェアテーブル３２０は、とりわけ、局内においてアクティブである各フローに関するパラメータを含む。従って、以下において例が詳述される様々なＭＡＣ処理機能中に、ＭＡＣプロセッサ２４０は、ハードウェアテーブル３２０にアクセスしてフローごとのパラメータ３２５を取り出す。ＭＡＣプロセッサ２４０は、ＳＲＡＭ３３０にも接続される。この構成においては、ＳＲＡＭ３３０は、パケットバッファ２５０の機能を実行するように適合化される。ＭＡＣプロセッサＡＳＩＣ ３１０は、様々なその他の構成要素を具備することができ、その例が以下において詳述される。この実施形態においては、パケットバッファ２５０はＭＡＣプロセッサ３１０内に常駐することが注目される。ハードウェアテーブル３２０は、分類することのみを目的として別個のブロックとして示されることに注目すること。様々な実施形態においては、ハードウェアテーブル３２０及びＳＲＡＭ３３０は、両方とも、ＭＡＣプロセッサ３２０内に含めることができる。
【００４５】
図４は、アクセスポイントとして用いるように構成されたＭＡＣプロセッサＡＳＩＣ３１０を描く。この構成は、より多いフロー数及び／又はより高いスループットをサポートできる局、いわゆるスーパーステーション、に関しても用いることができる。以下において詳述される例においては、スーパーステーションとアクセスポイントの構成は、単純にアクセスポイント又はアクセスポイント構成と呼ぶことができる。この実施形態においては、ＭＡＣプロセッサＡＳＩＣ  ３１０は、図３に示されるように、ＭＡＣプロセッサ２４０と、ハードウェアテーブル３２０と、ＳＲＡＭ３３０と、を具備する。繰り返すと、これらの構成要素は、例示することのみを目的として別々に示されており、これらの構成要素のうちの１つ以上をＭＡＣプロセッサ２４０内に含めることができる。この構成においては、ハードウェアテーブル３２０は、ＭＡＣ処理に関して用いられるフロー別パラメータをすべて含んでいるわけではない。この場合は、フロー別ポインタ３３５がハードウェアテーブル３２０に含まれ、各々のポインタは、ＳＲＡＭ３３０に格納される各々の関連づけられたフロー別パラメータ３２５を指し示す。希望される場合は、幾つかのフロー別パラメータをハードウェアテーブル３２０に格納できることに注目すること。示される同じハードウェア構成要素を具備する同じプロセッサＡＳＩＣ３１０を、異なる要求をサポートするためにいずれかの構成に合わせて適合化できることに注目すること。この例においては、ＳＲＡＭ３３０は、ＳＴＡモードにおけるパケットバッファ２５０であることからアクセスポイントモードにおけるフロー別パラメータ３２５のレポジトリであることに目的が変更される。従って、ＭＡＣプロセッサ２４０は、パラメータに関してハードウェアテーブル３２０にアクセスし、構成に依存して、これらのパラメータを取り出すか又はあるインダイレクション（ｉｎｄｉｒｅｃｔｉｏｎ）レベルに従ってＳＲＡＭ３３０からこれらのパラメータを取り出す。（例えばプロセッサ２１０によって実行される）ファームウェアは、ＭＡＣプロセッサＡＳＩＣ３１０の様々な構成要素が第１のモード（局モード）又は第２のモード（アクセスポイントモード）において実行するように構成することができる。モードを選択するための様々な技術は、当業においてよく知られる。例えば、現在の構成を１つ以上の構成要素に示すためにレジスタ設定、モード選択信号、等を用いることができる。さらに、ファームウェアは、選択された構成に依存して、ハードウェアテーブル３２０及びＳＲＡＭ３３０に異なる形で入れることができる。
【００４６】
引き続き図４において、パケットバッファ２５０の機能を実行するために外部メモリ、この例においてはＳＤＲＡＭ３４０、が含まれていることがわかる。従って、アクセスポイントモードにおいては、フロー別パラメータを格納するためにＳＲＡＭ３３０を用いることによってより多くの数のフローをサポートすることができ、従って（ハードウェアテーブル３２０はＳＲＡＭ３３０よりも小さいと仮定した場合に）ハードウェアテーブル３２０のみを用いてサポート可能である。ＳＲＡＭ３３０のサイズは、局モードにおける無線通信デバイスに関するパケットバッファの要求を受け入れるようなサイズを選択することができる。一実施形態においては、このサイズは、アクセスポイントによってサポートされるフロー数に関して必要なすべてのフロー別パラメータを格納するのにも適する。代替実施形態においては、ＳＲＡＭ３３０は、本来であればパケットバッファに関して必要になるよりも大きいＳＲＡＭのサイズを要求するより多いフロー数をサポートするようなサイズにすることができる。ＳＤＲＡＭ３４０は、アクセスポイントによってサポートされるフロー数を受け入れるようなＳＤＲＡＭを選択することができる。当業者は、ハードウェアテーブル３２０、ＳＲＡＭ３３０、及びＳＤＲＡＭ３４０に関して適切なサイズをどのようにして選択するかを認識するであろう。
【００４７】
従って、単一のＭＡＣプロセッサＡＳＩＣ  ３１０は、複数のモードをサポートするように設計することができる。ハードウェア構成要素は、異なる機能を提供するために各モードにおいて再使用することができる。ハードウェアテーブル及びパケットバッファの使用に関するより詳細な例が以下に示される。図３に示されるように構成可能な単一のＭＡＣプロセッサＡＳＩＣ３１０を採用することは、より小さいサイズ及びより低いコストを考慮するものである。外部のＳＤＲＡＭ３４０を追加し、ＭＡＣプロセッサＡＳＩＣ３１０を再構成することによって、同じＭＡＣプロセッサＡＳＩＣ３１０を、より高い性能のデバイス、例えばアクセスポイント又はスーパーステーション、において用いることもできる。所定の構成の性能上のニーズに依存して様々な異なるサイズのＳＤＲＡＭ３４０を選択することができる。
【００４８】
図５は、ＳＴＡ１０４又はＡＰ１０６等の無線通信デバイスのより詳細な実施形態例を示す。この例においては、非常に様々なパケット特長例に関するＭＡＣ処理が、１つのＭＡＣプロセッサを用いて説明される（おおまかに説明される）。代替実施形態においては、異なる型のパケットに関するＭＡＣ処理機能は、２つ以上のＭＡＣプロセッサに分割することができる（以下において代替実施形態例が図４８及び４９に関して詳述される）。
【００４９】
上述されるように、プロセッサ２１０は、ファームウェアタスクを実行するために配置される。該配置において典型的であることができる一組のサポート機能例が示される。様々な代替実施形態が当業者にとって明確になるであろう。プロセッサ２１０は、命令バス５０６を介して命令ＳＲＡＭ５０２及びブートＲＯＭ５０４と通信する。これらのメモリは、プロセッサ２１０におけるファームウェア処理において用いるためのよく知られた命令の格納及び取り出しを行うために用いることができる。Ｉ／Ｏ機能例及びサポート機能例がバス５１４に接続された構成要素によって示される。この例においては、様々なタイミング機能を実行するためのタイマー５０８を採用することができる。世界非同期受信機送信機（ＵＡＲＴ）５１０を採用することができる。他のＩ／Ｏ例は、１２Ｃインタフェース５１２である。この例においては、様々な補助構成要素が、バス５１４を介して、プロセッサ２１０に接続されたベクトル割り込みコントローラ（ＶＩＣ）５１６に接続される。従って、タイミング割り込み、Ｉ／Ｏ割り込み、及び関連する処理を、採用された関連機能に従ってプロセッサ２１０によって実行することができる。当業においては、様々な型のプロセッサと接続するための様々な代替機能がよく知られており、当業者によって知られるであろう。ブリッジ５１８は、バス５１４に取り付けられた構成要素をバス５２０に接続されたその他の構成要素と接続する。従って、バス５２０に接続された様々な構成要素は、プロセッサ２１０を含み、これらの各々の構成要素に引き渡すこと又はこれらの各々の構成要素から受信することを目的としてバス５１４上においてデータを通信することができる。この例においては、バス５２０ＤＭＡコントローラへのアクセスを制御するためのバスアービター５２２が採用され、バス５２６に取り付けられた追加構成要素は、ダイレクトメモリアクセス（ＤＭＡ）コントローラ５２４と、データＳＲＡＭ５２６と、バススレーブインタフェース５２８と、を含む。バススレーブインタフェース５２８は、以下においてさらに詳細に説明される、バス５２０とフォーマット化論理及びｍｕｘ５７０との間における導路を提供する。説明される構成要素は、図２に関して上述される様々な構成要素、例えばプロセッサ２１０、メモリ２２０、及びＩ／Ｏ２３０、と概念的に識別することができる。
【００５０】
ＳＤＲＡＭ３４０を除く図５の構成要素は、図３及び４において上述されるようなＭＡＣプロセッサＡＳＩＣ ３１０の１つの実施形態例の一部分を形成する。これらの構成要素は、図３において詳述されるＳＴＡ  １０６構成として又は図４において詳述されるアクセスポイント又はスーパーステーション構成として用いるために構成することができる。前説明に鑑みて、図５において詳述される様々な構成要素は、ＭＡＣプロセッサ２４０及びハードウェアテーブル３２０の一部分を形成することができることがわかる。説明される様々な構成要素は、異なる機能を果たすように異なるモードで構成することができる。プロセッサ２１０及び補助構成要素例５０２乃至５２８等の様々な構成要素は、ＭＡＣプロセッサＡＳＩＣ  ３１０の実施形態例において組み入れることができる場合とできない場合がある。
【００５１】
プロセッサ２１０、及び示されている様々なその他の構成要素は、バス５２０を介してＭＡＣプロセッサの構成要素と通信できることに注目すること。この例においては、ＭＡＣプロセッサは、下位ＭＡＣコア（ｌｏｗｅｒ  ＭＡＣ  ｃｏｒｅ）５４０及びＨ２Ｗプロセッサ５３０として示されるホスト−ＷＬＡＮサブシステムを含む２つの主要機能を具備する。これらの構成要素の実施形態例が以下においてさらに詳細に説明される。このように構成要素を様々な部分に分離することは、ほんの一例であり、当業者は、本明細書における教義に照らして明確になるように、代替実施形態において説明される様々なプロセス及び機能を容易に採用するであろう。
【００５２】
ＳＲＡＭ５６０は、ＭＵＸ  ５５４に接続されるＳＲＡＭインタフェース５５８を介してアクセスすることができる。Ｍｕｘ５５４は、メモリアービター５５６への接続又はメモリアービター５５２への接続をＳＲＡＭインタフェース５５８への入力として選択する。メモリアービター５５２は、要求を受け取り、バス５２０、及びバス５５０における構成要素を含む様々なソースからのＳＲＡＭ５６０へのアクセスに関して仲裁する。この例においては、バス５５０は、低位ＭＡＣコア５４０とメモリ（ＳＲＡＭ）５６０との間における直接結合を提供する。これらの構成要素の間にもバス５２０を介しての経路が存在することに注目すること。この例においては、時間の影響を受けやすいデータを下位ＭＡＣコア５４０から取り出すか又は下位ＭＡＣコア５４０に格納するためにＳＲＡＭ５６０によってアクセス性能を保証するための追加バス５５０が提供される。図３及び４において説明されるように、ＳＲＡＭ５６０は、一構成においてはパケットバッファとして及び他の構成においてはフロー別パラメータのレポジトリとして働くことができる点に注目すること。
【００５３】
下位ＭＡＣコア５４０は、ＰＨＹ２６０への送信のためにパケットを引き渡すために及びＰＨＹ２６０からの受信されたパケットを処理するために用いることができるＭＡＣ／ＰＨＹインタフェース５４５に接続される。下位ＭＡＣコア５４０内の構成要素の実施形態例が以下においてさらに詳細に説明される。
【００５４】
Ｈ２Ｗプロセッサ５３０は、入力パケットを処理し、以下において実施形態例がさらに詳細に説明される。一実施形態においては、入力は、着信パケットの処理から切り離すことができる。この場合は、入力パケットは、ライン速度で（すなわち、入力速度で）パケットバッファ内に書き込むことができる。これらのパケットの処理は、のちにパケットバッファから読み出すことによって行うことができる。この分離は、処理速度が入力ライン速度と異なることを可能にする。この手法の欠点は、パケットが読み出されて処理され、パケットバッファ内に戻されて送信待ち状態にしなければならないため、パケットバッファに対する余分の読み出し及び書き込みが存在することである。このメモリ帯域幅に関する犠牲は、一定の実施形態においては受け入れ可能である。下例において示される代替実施形態は、入力パケットのインライン処理に備えるものである。これらの実施形態例においては、ＭＡＣ処理は、各入力パケットがライン速度で送信するためにフォーマット化され、パケットバッファへの書き込みが１回である（その後に、パケット送信時間に達したときに読み出しが行われる）ことを考慮する。第２の場合においては、メモリ帯域幅に対する負担が第１の場合よりも軽減される。当業者は、様々な実施形態において、いずれの手法も本明細書において教義される様々な側面と容易に適合化するであろう。
【００５５】
ＳＤＲＡＭ３４０は、この実施形態においてはＭＡＣプロセッサＡＳＩＣ  ３１０への外部構成要素として示される。このことは、上図３及び４の説明に合わせるものであり、より多いフロー数をサポートする必要があり（その結果、アクセスポイント又はスーパーステーション等のパケットバッファスペースを増大させる必要性がより高くなる）無線通信デバイスを、単一のより低コストのＭＡＣプロセッサＡＳＩＣ  ３１０及びオプションの外部メモリ、例えばＳＲＡＭ  ３４０、によって受け入れることができる。ＳＤＲＡＭ３４０は、メモリアービター５５６に結合されるＳＤＲＡＭインタフェース５６２を介してアクセスことができる。代替実施形態においては、ＳＤＲＡＭ３４０は、ＭＡＣプロセッサＡＳＩＣ  ３１０内に組み入れることができる。図５に示されるような構成要素の割り当ては、１つの例であるにすぎない。示されるいずれの構成要素も、各ＡＳＩＣのエリア上の要求事項及び希望される性能に依存して、単一のＡＳＩＣにおいて組み入れることができ又は１つ以上の外部デバイスに組み入れることができる。
【００５６】
この例においては、パケットの入力及び出力は、２つの外部インタフェース例のうちの１つを通じて行われる。当業者は、代替インタフェースをこれらのインタフェースに加えて又はこれらのインタフェースの代わりに採用できることを認識するであろう。この例においては、これらのインタフェースのうちの１つ以上と通信中の外部（又は内部）デバイスへのパケットを受信してハンドオフするためのＳＤＩＯインタフェース５８２及びＰＣＩインタフェース５８４が採用される。ＳＤＩＯインタフェース５８２及びＰＣＩインタフェース５８４は、ＭＵＸ５８０を介して選択される。
【００５７】
様々な速度のインタフェースを受け入れること、及び着信パケット及び発信パケットの格納及び処理に関する要求が様々であることに備えることを目的として、ＳＲＡＭ  ５６０及びＳＤＲＡＭ  ５４０等のメモリにアクセスする際の混雑を緩和するためのレートマッチングと待ち行列、及びＨ２Ｗプロセッサ５３０及び下位ＭＡＣコア５４０等のＭＡＣ処理機能を実行するためのＦＩＦＯ、ｍｕｘ、及びフォーマット化論理を採用することができる。例えば、入力インタフェース及び出力インタフェースは、ＷＬＡＮのスループット能力と比較してより高速で動作することができる。着信フローは、バースト性でさらに高速の場合がある。プロセッサ２１０又はバス５２６に接続されたその他の構成要素から受信された情報は、さらに他の速度で到着する場合がある。以下においてさらに説明されるように、Ｈ２Ｗプロセッサ５３０及び下位ＭＡＣコア５４０は、アクセス要求を生成し、様々なタスクに関する処理が完了されるのに応じてこれらの要求の結果得られたデータを取り出す又は格納する。従って、この例においては、ＦＩＦＯ５７２は、フォーマット化論理とｍｕｘ５７０との間に及びフォーマット化論理とｍｕｘ５７４の間に配置することができる。一例においては、入力機能及び出力機能（例えば、ＳＤＩＯインタフェース５８２又はＰＣＩインタフェース５８４）へのインタフェースのために一組のＦＩＦＯ５７２、フォーマット化論理及びｍｕｘ５７０からフォーマット化論理及びｍｕｘ５７４へのデータをバッファリングするためのＦＩＦＯ５７２、及び反対方向のデータをバッファリングするための他のＦＩＦＯ５７２を採用することができる。Ｈ２Ｗプロセッサ５３０への又はＨ２Ｗプロセッサ５３０からのデータをサポートするために他の一組のＦＩＦＯ５７２、各方向に１つ、を採用することができる。下位ＭＡＣコア５４０と関連して用いるために他の同様の組を採用することができる。バス／スレーブインタフェース５２８を介してアクセスされる、バス５２０上の構成要素間におけるインタフェースのためにさらに他の同様の組を採用することができる。当業者は、この構成は一例にすぎないことを認識するであろう。様々な代替実施形態を採用することが可能であり、このことは、本明細書における教義に照らして当業者に明確になるであろう。以上のように、図５に示される無線通信デバイス１０４又は１０６の実施形態例は、様々な構成要素の１つの可能な相互接続を例示する役割を果たし、その詳細が以下において説明される。これらの構成要素及び／又は追加の構成要素（示されない）の部分組を用いた非常に多数の代替構成を同じ適用範囲内において採用することができる。
【００５８】
パケットバッファ及びメモリ管理
図６は、パケットバッファ２５０の実施形態例を示す。本明細書において詳述される様々な実施形態例においては、パケットバッファ２５０は、図６に示されるように、ＭＡＣプロセッサ２４０内におけるパケット処理に関する様々な機能を実行するために役立つデータ構造及び関連する連結リストを示す。本明細書において詳述される様々な実施形態は、該構造を要求せず、さらに代替パケットバッファを代替実施形態において採用できる一方で、本明細書全体を通じて詳述される実施形態は、これらの様々な機能におけるこれらの連結リスト及びデータ構造の使用について例示するためにこれらの連結リスト及びデータ構造を利用する。さらに、パケットバッファ、例えば図６において説明されるパケットバッファ、を、本明細書において詳述される機能に加えて様々な代替機能において用いるために採用することができる。当業者は、相対的に高速のパケット処理が希望される実施形態を含む様々な実施形態においてこのパケットバッファ及び構成要素及びその副構成要素を容易に適合化するであろう。パケットバッファ例２５０は、図６に示されない追加のデータ構造を含むことができ、これらの追加データ構造は、後述される図７においてさらに詳細に説明される。
【００５９】
この例においては、各パケットは、本明細書においてはノード６１０と呼ばれる第１のデータ構造及び本明細書においてはチャンク６２０と呼ばれる第２のデータ構造の２つの型のデータ構造を用いてパケットバッファ２５０内に格納される。各パケット、又はパケットフラグメント（８０２．１１（ｇ）及び（ｅ）において説明されるようなフラグメンテーションが採用される場合）は、１つのノード６１０と、１つ以上のチャンク６２０と、を含む。パケットデータを格納するために要求されるチャンク数は、パケット又はフラグメントのサイズに依存して異なる。従って、パケットは、第１のチャンクを指し示すノードを具備する連結リスト構造としてパケットバッファ２５０内に常駐し、追加チャンクが要求されるときには、連結リストは、追加チャンクを具備し、各チャンクは、後続チャンク（最終チャンクを除く）を指し示す。
【００６０】
ノードとチャンクとの間における該セグメンテ−ションの１つの利点は、制御決定に関して非常に重要な情報をノード内に保存することができ、データ自体は相対的により大きいチャンク内に保存されることである。このことは、パケット全体のアクセスを要求せずに制御処理において各々のパケットを代表するノードが用いられることを考慮するものである。
【００６１】
さらに、着信中の入力パケット、及び出力待ちのパケットは、一般的には、１つ以上のフローと関連づけられる。示されているノード及びチャンク構造は、パケットバッファ内におけるパケットの待ち行列の効率的な形成も容易にし、各待ち行列は、各々のフローと関連づけられる。この一般的構造は、図６において示され、様々なノード及びチャンクを具備する単一の待ち行列の例を有する。この例においては、ノード６１０Ａ−Ｎは、フローに関する待ち行列と関連づけられた連結リストを形成する。該待ち行列は、待ち行列先頭ポインタ６３０によって識別される先頭を有し、待ち行列末尾ポインタ６４０は、待ち行列内の最後のノードを識別する。この例においては、待ち行列内にはＮのパケットが存在し、各々のパケットは、該ノードと関連づけられたノード６１０を有する。各ノード６１０は、例示されるような一連のチャンク６２０Ａ乃至Ｍを具備する。あらゆる数のチャンクを単一のノードと関連づけることができる。この図に示される残りのチャンクは、単にラベルが付される６２０。当業者は、様々なサイズのチャンクと同様に様々なサイズのノードを採用できること認識するであろう。実施形態例においては、チャンクは５１２バイトである。従って、パケット例は通常は２キロバイト未満であるため、各パケットに関して多くて４つのチャンク（典型的にはこれよりも少ない）が必要になり、パケットヘッダー及び関連づけられたその他の情報を含む。代替実施形態においては、あらゆるパケットサイズを受け入れるチャンクサイズを採用することができる。
【００６２】
この実施形態例においては、メモリ内では制御及びデータが分離される。送信及び受信目的のために、制御構造に関して幾つかの処理が必要になる場合がある。しかしながら、データペイロードに関して、（ＷＬＡＮからの入力又は受信時点において）メモリ内への１回のみの書き込みが行われ、（ＷＬＡＮにおける送信時点又は外部インタフェースを介しての出力時点に）そのメモリからの１回の読み出しが行われる。このように、メモリ内への及びメモリからの転送が相対的に効率的であるため、メモリ帯域幅に関する要求を軽減させることができる。
【００６３】
ノード例６１０が図６に示される。ノード６１０は、待ち行列内の後続ノードにリンクするために用いられる次ノードポインタ６１２を具備する。長さフィールド６１４及びシーケンス番号６１６が含められる。これらのフィールドは、以下においてさらに説明されるようにパケットを処理時に有用であり、チャンク６２０に含まれているデータにアクセスするか又は該データを移動させずにＭＡＣ処理が実行されることを考慮する。例えば、長さフィールドは、ＴＸＯＰにおいてパケットを統合するときの統合に関して有用である。シーケンス番号は、ブロックＡＣＫ要求を送信時に有用である。一般的には、処理に関して有用なあらゆるパケット情報を代替ノード実施形態に加えることができる。ノード６１０は、パケットデータを含む第１のチャンクを指し示すチャンクポインタ６１８も含む。
【００６４】
この構造は、あらゆる長さの待ち行列を生成する柔軟性を可能にし、メモリパケットバッファの全体的なサイズのみによって制限される。従って、様々な異なるフロー型をサポートすることができ、サポートされるフロー数を固定する必要がない。例えば、少ない数のパケットを要求する幾つかのフローは、より多い数のパケットを要求するフローとともに格納域を割り当てることができ、従って、所定の数のフローをサポートするためにより小さいパケットバッファサイズを採用することができる。代替として、所定のメモリサイズに関して様々な数のフローを受け入れることができる。理解できるように、待ち行列は、独立して拡大又は縮小することができ、さらに、ノード及びチャンクはフロー又はパケットによってそれぞれ再使用できるため、構造は、高い柔軟性を有して非常に効率的なメモリ管理が可能である。
【００６５】
チャンク例６２０も同様に示される。チャンクデータ６２２は、パケットを具備し、ヘッダフィールド、フレーム検査シーケンス、等を含む。連結リスト内に次のチャンクが存在する場合は該次のチャンクを指し示すための次チャンクポインタ６２４が含められる。
【００６６】
一実施形態においては、チャンクは固定サイズである。この固定サイズは、パケットバッファメモリがチャンクに割り当てられた固定のメモリ部分を具備することを考慮するものである。連結リスト構造は、あらゆるチャンクをあらゆるパケット連結リストにおいて用いることを可能にする。パケットは到着して出て行くため、追加のメモリ管理オーバーヘッド（例えば、サイズが異なるパケットに関するスペースの再割り振り、等）が要求されずに簡単にチャンクを再度用いることができる。この構造は、一般的にはチャンクは１回だけパケットバッファに書き込むことができ、さらにこれらのチャンクはＷＬＡＮにおける送信又は出力先へのハンドオフのための準備が完了するまでとどまるという点で効率的な処理を考慮するものである。パケットは、単純にポインタを書き換える（すなわち、連結リストを変更する）ことによって待ち行列内において移動させること又は新しい待ち行列に移動させることも可能である。このことは、パケットを再送信のために処理するときに有用である。これらの構造の使用は、以下においてさらに詳細に説明されるような追加の効率に備えるものである。各連結リストは、待ち行列内の最後のノード又はパケット内の最後のチャンクに関して様々なリスト終了子（ｔｅｒｍｉｎａｔｏｒ）のうちのいずれかを用いることができる。実施形態例においては、連結リスト内の第１の及び最後のノードは、ヘッダー及び末尾ポインタによって示され、チャンクポインタは、パケット内の最後のチャンクを示すようにスレッドされる。代替実施形態においては、パケット長及びパケットシーケンス番号とともにチャンク数をノードヘッダー内において加えることが望ましい場合がある。可変のチャンクサイズを含む代替実施形態も構想されている。
【００６７】
図７は、パケットバッファ例２５０をさらに示す。メモリの隣接するチャンクを様々なデータ構造型に割り当てることができるが、この割り当ては必須事項ではない。上述されるように、セグメント７３０の一部分をノードに関して割り当てることができ、セグメント７４０は、チャンクに関して割り当てることができる。実施形態例においては、上述されるように、これらのセグメントの各々は、あらゆるパケット及び／又はフローに関して再度用いることが可能な隣接するメモリスペースであり、サイズが固定されたノード及びチャンクを含む。さらに、フリーノードポインタリスト７１０及びフリーチャンクポインタリスト７２０が維持される。当業者にとって明らかになるように、フリーポインタリストに関する様々なデータ構造を採用することができる。一例においては、ノードポインタ及びチャンクポインタを各々のポインタリスト７１０又は７２０にプッシュ及びポップすることができる。これらのリストは、例えば、環状バッファであることができる。ポインタがポップされて新しいノード又はチャンクが形成された時点で、そのポインタは、ノード又はチャンクが解放されるまで使用状態になり、解放された時点で、ポインタを将来用いるためにプッシュバック（ｐｕｓｈ  ｂａｃｋ）することができる。
【００６８】
図８は、例えば本明細書において詳述される実施形態例の場合のように、ＭＡＣプロセッサ内において採用することができる追加の構成要素を示す。これらの構成要素は必須ではないが、使用中のメモリの型が有する特性に起因して一定の状況において利点を提供することができる。例えば、一般的にはＳＤＲＡＭアクセスと関連するレーテンシーが存在する。さらに、小規模な転送を行うときに（すなわち、単一のノード又はチャンクポインタを取り出すか又は格納する際に）非効率的になる場合がある。ローアクセス、カラムアクセス、等を組み入れるときに一定の型のＳＤＲＡＭを用いることで、オーバーヘッドサイクルが実際のデータ転送サイクルを圧倒する可能性がある。長い遅延を防止するため、幾つかのポインタをＭＡＣ処理において用いるために一度に取り出すための様々なキャッシュを採用することができる。図８は、これらのキャッシュのうちの幾つかに関する例を示す。これらのキャッシュの一部又は全部は、様々な代替実施形態において採用することができる。本明細書において詳述される実施形態において用いられるキャッシュ例は、ＴＸフリーノードポインタキャッシュ８１０と、ＴＸフリーチャンクポインタキャッシュ８２０と、ＲＸフリーノードポインタキャッシュ８３０と、ＲＸフリーチャンクポインタキャッシュ８４０と、を含む。パケットに関して上述されるデータ構造は、受信パケットとともに用いるために単純化することができ、その実施形態例が以下において図３３に関してさらに詳細に説明される。一般的には、これらのキャッシュ８１０乃至８４０の各々は、効率的にするためにパケットバッファ２５０内の各々のノードポインタリストから１つ以上のポインタを受け取る。パケットバッファから複数の各々のポインタを一度に取り出すことができる。この例においては、複数のポインタを各々のリストからポップすることができる。これらのポインタは、各々のキャッシュ内に入れられ、様々なＭＡＣ処理構成要素において用いるために各々のキャッシュから単一のポインタをポップすることができる。以下において詳述される様々な実施形態例を通じてポインタ及びその各々のキャッシュの使用がさらに示される。
【００６９】
図９は、パケットバッファ内にパケットを書き込んで待ち行列を生成するための方法９００の実施形態例を示す。待ち行列は、データ構造、この例においては連結リスト、を用いて形成することができる。待ち行列は、アレイとして形成することもできる（以下において詳述されるように、一例がノードアレイ３３３０として示される）。この方法は、上記の図６及び７において説明されるようなパケットバッファと関連させて採用するのに適する。方法９００は、入力パケットをパケットバッファに書き込むために用いることができる技術例を示す。出力に関するハンドオフ処理を待つために受信パケットをパケットバッファに書き込むために同様の技術を用いることができる。ハンドオフに関する実施形態例が以下においてさらに詳細に説明される。オプションとして、ポインタキャッシュ（すなわち、図８において説明されるような８１０乃至８４０）も採用することができ、さらに新しいポインタに関する主ソースになることもできる。当業者にとって明らかになるように、キャッシュを有する又は有さない様々な実施形態を採用することができ、この方法は、あらゆる該構成とともに用いることができる。
【００７０】
９１０において、パケットが受け取られる。決定ブロック９１２において、パケットと関連づけるためにノードをポップする。決定ブロック９１４において、このパケットが各々の待ち行列における最初のパケットである場合は、９１６に進み、新しいパケットと関連づけられたノードを指し示すように先頭待ち行列ポインタを更新する（例えば、図６に示される待ち行列先頭ポインタ６３０）。次に、９１８に進む。決定ブロック９１４において、このパケットが各々の待ち行列における最初のパケットでない場合は、９１８に進む。
【００７１】
９１８において、チャンクポインタをポップする。繰り返すと、ノード及びチャンクをポップする（各々のポインタをポップすることの省略表現）ことは、パケットバッファから直接、そして特にフリーノードポインタリスト又はフリーチャンクポインタリストからそれぞれ直接行うことができる。実施形態例においては、ポインタは、（枯渇するのに応じて補給することが必要になる）送信フリーノードポインタキャッシュ８１０及び送信フリーチャンクポインタキャッシュ８２０からポップされる。９２０において、パケットのシーケンス番号及び長さをノードに入れ、９１８において取り出されたチャンクポインタを（例えば、図６に示されるノード６１０等のノードフォーマットを用いて）ノードのチャンクポインタフィールドに挿入する。９２２において、チャンクにパケットデータを充填する。一例においては図６に示されるようなチャンク６２０を採用することができる。
【００７２】
決定ブロック９２４において、パケットが第１のチャンク内において適合する大きさよりも大きいため他のチャンクが必要である場合は、９２６に進む。大きくない場合は、９３２に進む。９２６において、新しいチャンクポインタをポップする。９２８において、新しいチャンクポインタを前のチャンクの次チャンクポインタフィールド内に書き込む。９３０において、新しいチャンクにパケットデータを充填する。実施形態例においては、パケットデータは、一連のチャンク内に順次書き込まれる。次に、決定ブロック９２４に戻り、さらに他のチャンクが必要になるかどうかを決定する。このループは、パケットが１つ以上のチャンク内に完全に書き込まれるまで繰り返すことができる。
【００７３】
９３２において、パケットを書き込むプロセスが完了される。パケットと関連づけられたノードをスレッドして適切な待ち行列に入れる。例えば、このことは、末尾ノードの次ノードポインタ内にノードアドレス、すなわち９１２において取り出されたポインタ、を書き込むことによって達成させることができる。この例においては、末尾ノードは、待ち行列末尾ポインタ（例えば、図６に示される待ち行列末尾ポインタ６４０）によって識別される。９３４において、末尾モードになる現在のノードを指し示すように末尾ポインタを更新する。
【００７４】
決定９３６において、他のパケットが受け取られた場合は、９１２に戻り、プロセスは繰り返すことができる。他のパケットがパケットバッファ内に書き込む準備が整っていない場合は、プロセスは停止することができる。説明を明確化するため、該当する待ち行列及びその関連づけられた先頭ポインタと末尾ポインタが導き出される関連フローとパケットを関連づけることに関する詳細は省略される。パケットをフローと関連づける実施形態例が以下においてさらに詳細に示される。
【００７５】
Ｈ２Ｗプロセッサ及び入力ポリシング
図１０は、Ｈ２Ｗプロセッサ５３０等のホスト−ＷＬＡＮサブシステムの実施形態例を示す。パケットは、様々なソースから受け取ることができる。この例においては、２つのソースが例示される。この実施形態例は、Ｈ２Ｗプロセッサ５３０内に含めることができる構成要素の部分組を示す。図１０に示される構成要素の一部は、Ｈ２Ｗプロセッサ５３０に含まれていない図５の構成要素に対応することができ、説明を明確するために示されている。示されている構成要素及びそのパーティションは、例示することのみを目的とするものであることを当業者は認識するであろう。この例における典型的入力パケットは、図５に示されるＳＤＩＯインタフェース５８２又はＰＣＩインタフェース５８４等の外部インタフェースから来る。他の入力されるパケット例は、図５に示されるように、プロセッサ２１０又はバス５２０に接続されたその他の構成要素から来ることができる。外部インタフェースパケットは、外部インタフェース１００６を介してＨ２Ｗプロセッサ５３０に到着する。例えばバス５２０からのパケットは、プロセッサインタフェース１００２を介して到着することができる。１つ以上のパケットを処理目的で保持するためにＦＩＦＯを採用することができる。例えば、ＦＩＦＯ１００４及び１００８は、プロセッインタフェース１００２又は外部インタフェース１００６からそれぞれ受け取られたパケットを保持するために採用することができる。ブロック１００４は、ＷＬＡＮにおいて送信する必要があるプロセッサからの管理パケット及び制御パケットを保持するために採用することができる。以下において図４８に関して詳述される代替実施形態においては、レガシーパケット及び（例えば）その他のより低いスループットのパケットはプロセッサ２１０（又は他の代替ＭＡＣプロセッサ）において処理され、従ってプロセッサインタフェース１００２は必要ないため、該インタフェース及びその関連構成要素は省略することができる。
【００７６】
この例においては、トラフィックストリーム識別子（ＴＳＩＤ）と関連する行先ＭＡＣアドレスがフローを一意で識別するために用いられる。代替実施形態においては、フローマッピングのためにその他のメカニズムを採用することができる。上述されるように、典型的には、ファームウェア又はその他の何らかの外部プロセッサにおいて実行中であることができるフローの分類を行うためのドライバが存在する。ドライバは、行先アドレス（ＤＡ）、ＴＳＩＤ、及びソースアドレスを有するＭＡＣアドレスを生成することができる。
【００７７】
この例においては、ＤＡ及びＴＳＩＤは、フローを識別するために用いることができる。ＤＭＡＣ−ＴＳＩＤは、ＤＭＡＣ−ＴＳＩＤに対応してフローマッピングブロック１０２０に引き渡され、フローマッピングブロック１０２０からフローＩＤが戻される。
【００７８】
フローマッピングブロック１０２０の実施形態例は、所定の識別情報からフローＩＤを決定するためにあらゆる型のルックアップ又はその他の機能を用いることができる。一例が図１０Ｂに示される。
【００７９】
実施形態例においては、上述されるように、ファームウェア対話（ｉｎｔｅｒａｃｔｉｏｎ）をライン速度処理から切り離すことが望ましい。しかしながら、ファームウェアは、フローマッピング用テーブルを生成するのに非常に適する場合がある。ファームウェア対話を切り離すために、２つのシャドーフローテーブル、テーブル１  １０９２及びテーブル２  １０９６、が採用される。Ｈ２Ｗプロセッサ５３０は、スイッチ１０９０によって選択された一方のシャドーテーブルを利用し、ファームウェアは、スイッチ１０９９によって選択された他方のシャドーテーブルを更新する。従って、ファームウェアが一方のテーブルを更新して他方のテーブルがＭＡＣ処理に関して用いられるピンポン技術を採用することができる。各シャドーフローテーブル１０９２又は１０９６は、対応するフローＩＤを有するＤＭＡＣ−ＴＳＩＤエントリのリストを具備する。シャドーフローテーブル１  １０９２は、フローＩＤ  １０９４Ａ−Ｎと関連づけられたＤＭＡＣ−ＴＳＩＤ  １０９３Ａ−Ｎを具備する。シャドーフローテーブル２  １０９６は、関連づけられたフローＩＤ  １０９８Ａ−Ｎを有するＤＭＡＣ−ＴＳＩＤ  １０９７Ａ−Ｎを具備する。従って、フローマッピングブロック１０２０は、アクティブに選択されたシャドーフローテーブルにＤＭＡＣ−ＴＳＩＤを引き渡し、フローＩＤが戻される。実施形態例においては、フローＩＤの高速探索を行うために、２進数探索が行われる。ファームウェアは、２進数探索を容易にするためにＤＭＡＣ−ＴＳＩＤフィールドを順に整列させるのに非常に適する。当業者は、代替実施形態において代わりに用いることができる代替フローマッピング手順を認識するであろう。
【００８０】
次に図１０Ａに戻り、フローＩＤがＴＸフロー状態テーブル１０３０に引き渡され、その実施形態例が以下において図１１に関して詳細に説明される。ＴＸフロー状態テーブル１０３０は、各フローに関する様々なパラメータを具備する。ＴＸフロー状態テーブル１０３０の物理的位置は、図３及び４に関して上述されるように変化することができる。例えば、一構成においては、ＴＸフロー状態テーブルは、Ｈ２Ｗプロセッサ５３０におけるハードウェアテーブル内に保管することができる。代替実施形態においては、ハードウェアテーブルは、詳細が示されていない下位ＭＡＣコア５４０に常駐することができ、両ブロック５３０及び５４０は、同じハードウェアテーブルを共有することができる。又は、各ブロック５３０及び５４０は、図３及び４において概念的に示されるようなハードウェアテーブルの一部分を維持することができる。引き渡されたフローＩＤから、フローＩＤに対応するＴＸフロー状態テーブル１０３０の部分を選択して様々なパラメータを取り出すことができる。これらの実施形態全体においてパラメータ例が説明される。
【００８１】
幾つかのパラメータは、ポリシングユニット１０１０に引き渡すことができる。以下においてポリシングユニット実施形態例がさらに詳細に説明される。暗号化が可能な状態になった場合は、暗号化ブロック、この例においてはメッセージ完全性符号（ＭＩＣ）１０２５、は、暗号化の際に用いるために引き渡されたキーを有することができる。
【００８２】
ＭＩＣブロック１０２５において、供給されたキー及びパケットのペイロード部分内のデータから、ＭＩＣ計算を生成することができる。この実施形態においては、ペイロードの暗号化を行うための別個の構成要素が用いられる（以下において詳述されるレガシープロトコルエンジン２２１０を参照）。代替符号化技術は、当業においてよく知られており、代わりに用いることができる。
【００８３】
ヘッダーを生成するためにその他のパラメータをヘッダーアタッチ１０３５に引き渡すことができる。生成されたヘッダーは、パケットヘッダー自体において用いるためのフィールド、及びパケットがＭＡＣ処理機能を横断する間に用いるための制御値を含むことができる。これらの制御値は、パケットが送信のために引き渡される前に取り除くことができる。この技術は、ＭＡＣ処理が実行される間パケットに関する状態情報を維持するための一技術例である。当業者は、様々なＭＡＣ機能を実行する間パケットの状態を維持するための代替技術を認識するであろう。
【００８４】
ポリシングユニット１０１０は、フロー状態テーブル１０３０から引き渡されたパラメータと関連して、パケットを拒否することができ、その場合は、暗号化機能、例えばＭＩＣ計算、は実行されず、ＦＩＦＯからパケットを取り除くことができる。入力ポリシング実施形態例が以下においてさらに詳細に説明される。ポリシングユニット１０１０がパケットを許容する場合は、ペイロードが、ＭＩＣ１０２５において生成されたＭＩＣ部分とともにイネーブルにされ、適切なヘッダーがＦＩＦＯ１０５０における格納のために引き渡される。
【００８５】
図１１は、ＴＸフロー状態テーブル１０３０の内容の実施形態例を示す。パラメータの組が各フローに関して維持される。単一のフローのパラメータが示される。パケット型１１０２は、いずれの型のパケットを受け取り中であるかを指定する。例えば、パケットは、８０２．１１（ｇ）、（ｅ）、又は（ｎ）パケットであることができる。その他のパケット型をサポートすることができ、パケット型１１０２フィールドにおいて示すことができる。
【００８６】
セキュリティポリシー１１０４は、セキュリティ技術（例えば暗号化）が用いられるかどうかを示す。実施形態例は、ＡＥＳ−ＣＣＭＰ（高度暗号化基準−カウンターモード暗号ブロック連鎖メッセージ認証ＭＡＣプロトコル）及びＲＣ４−ＴＫＩＰ（Ｒｉｖｅｓｔ’ｓ  Ｃｉｐｈｅｒ−４−テンポラルキーインテグレーションプロトコル）をサポートする。受信機アドレス１１０６は、パケットの行先である受信機のＭＡＣアドレスを示す。シーケンス番号１１０８は、パケットシーケンス番号を示す。ＭＩＣキー１１１０は、ＴＫＩＰがイネーブルにされた場合のＭＩＣキーを識別する。フレーム制御１１１２は、適切なヘッダーを構築するための情報を含む。
【００８７】
サービスの質（ＱｏＳ）制御１１１４は、ＱｏＳレベルを示すために用いることができる。実施形態例においては、４つのＱｏＳレベルが維持される。以下において異なるＱｏＳ値に関する待ち行列処理例がさらに詳細に説明される。
【００８８】
寿命フィールド１１１６は、パケットがバッファ内にどの程度の期間とどまることができるかを示すために用いることができる。例えば、寿命値が経過した時点で、パケットをフラッシングすることができる。実施形態例においては、入力ポリシングの際には、例えばポリシングユニット１０１０においては、最大バッファ占有率１１１８、フロー当たり最大パケット１１２０、及びフロー当たり累積パケット１１２２が用いられ、その例が以下において図１２及び１３に関してさらに詳細に説明される。グローバル変数現バッファ占有率をこれらの３つのパラメータとともに用いて様々な入力ポリシング技術を実行できることに注目すること。末尾待ち行列ポインタ１１２４は、上述されるように、図６及び９に関する末尾ノードを識別するために用いられる。
【００８９】
これらのＴＸフロー状態テーブル変数又はパラメータは、例示することのみを目的とするものである。当業者は、追加の変数又はパラメータがフロー別に維持する上で有用であって含めることが可能であることを認識するであろう。さらに、すべての特長をすべての実施形態においてサポートする必要があるわけではなく、これらのパラメータの部分組を採用することができる。
【００９０】
図１２は、入力ポリシングを実行するための方法１２００の実施形態例を示す。以下において、出力ハンドオフ及び全体的ＷＬＡＮ  ＱｏＳを対象とした、入力ポリシングの利点に関するより一般化された説明が以下において図３４を参照して示される。図１１におけるＴＸフロー状態テーブル例１０３０に関して上述されるように、様々なパラメータを各フローに関して維持することができる。これらのパラメータは、ポリシング機能によってパケットをより簡単に受け付けること又は拒否することができるようにＱｏＳレベルに基づいて個別適合化することができる。
【００９１】
この技術は、ＷＬＡＮ ＱｏＳに関連する一方で、（バースト性である可能性があり及び高低のＱｏＳフローの組合せを具備する可能性がある）高速入力とインタフェース時には、ＷＬＡＮ自体における混雑とは別個のボトルネックがＭＡＣ処理ユニットにおいて形成される可能性があるということを認識する追加技術である。例えば、ＭＡＣ処理機能により低いＱｏＳのパケットを充填することが可能である。適切なポリシングが行われない場合は、混雑度が相対的に低い間により低いＱｏＳのパケットがパイプライン内に導入されるおそれがあり、さらにＷＬＡＮにおける状態が劣化してスループットが低下した場合にボトルネックが形成されるおそれがある。従って、ポリシングユニット１０１０は、より高いＱｏＳのパケットが相対的混雑時間中に自己の優先度を維持するのを可能にするように構成することができ、さらに、混雑度が低下したときにより低いＱｏＳのパケットを処理することをより自由に可能にすることができる。８０２．１１基準（例えば、ｂ、ｇ、ｅ及びｎ）は、ＷＬＡＮにおけるＱｏＳ制御に注意を払っているが、入力に対しては十分な注意を払っていない。従って、ＱｏＳが低いアプリケーションが局内の全バッファを占めた場合は、優先度が高いパケットがシステムへのアクセスを得ることができない。本明細書において説明される入力ポリシングは、該シナリオを防止し、ＷＬＡＮ  ＱｏＳだけでなくエンドツーエンドＱｏＳを提供することができる。当業者は、本明細書における教義に鑑みてポリシング機能に関する様々な代替実施形態を認識するであろう。
【００９２】
図１２に戻り、１２１０において、パケットが送信のために受信される。例えば、パケットは、Ｈ２Ｗプロセッサ５３０に導入することができ、ポリシングユニット１０１０は、さらなるＭＡＣ処理のためにパケットを受け入れるべきか又は拒否するべきかを決定することができる。１２２０において、受信されたパケットのＩＤを決定する。例えば、フローマッピングブロック１０２０を用いることができる。１２３０において、フローＩＤと関連づけられたポリシングパラメータ及び／又はポリシング機能にアクセスする。一実施形態例においては、これらのパラメータは、ＴＸフロー状態テーブル１０３０に格納することができ、最大バッファ占有率１１１８、フロー当たり最大パケット１１２０、及びフロー当たり累積パケット１１２２を含むことができる。図１１のＴＸフロー状態テーブル例１０３０には、複数のポリシング機能（及びおそらくそれに関連づけられた代替パラメータ）が指定され、異なるフローに関して異なるポリシング機能が用いられる可能性があることが示されていない。決定ブロック１２４０において、フロー専用パラメータ及び現在の混雑又はその他のシステム状態に関連するグローバル変数に従い、受信されたパケットを受け入れることがフローに関して指定された適切なポリシング機能を満たす場合は、１２５０に進んでパケットを受け付ける。満たさない場合は、１２６０に進んでパケットを拒否する。これで、プロセスは停止することができる。
【００９３】
図１３は、図１２におけるステップ１２４０として採用するのに適したポリシング機能の方法１３００の一実施形態例を示す。上述されるように、パラメータ最大バッファ占有率及びフロー当たり最大パケットは、個々のフローに関して個別適合化することができる。これらは、フローのＱｏＳレベルと関連づけることができる。実施形態例においては、４つのＱｏＳレベルが採用される。しかしながら、これらのパラメータは、予め定義されたＱｏＳレベルよりも大きい変動を受け入れるようなサイズであることができる。従って、幾つかの実施形態においては、ポリシング機能は、ＱｏＳ設定例よりも細かい粒度で実装することができる。この例においては、決定ブロック１２４０は、図１２において示されるように展開されたときに１２３０から到着することができ、パケットを受け付けるかどうかを決定し、（図１２において示されるように展開されたときにはブロック１２５０又は１２６０にそれぞれ進む）。
【００９４】
決定ブロック１２４０における試験例は、２つの条件（ｔｅｒｍ）を具備する。いずれかの条件を満たすことは、パケットが受け入れられることを可能にする。両条件が満たされない場合は、パケットは拒否される。
【００９５】
第１の条件は、ＭＡＣ処理ユニット内における混雑を示す指標であると考えることができる。ＭＡＣ処理ユニットの混雑度が相対的に低いときには、第１の条件は、優先度がより低いパケットに関する場合でも、より高い可能性を持って真になり、従ってパケットが受け付けられる可能性が高くなる。示される例においては、第１の条件は、現在のバッファ占有率が最大バッファ占有率よりも低いときに真である。ここで、現バッファ占有率は、プロセスが利用可能なグローバル変数であり、パケットバッファの全体的占有率を示す。最大バッファ占有率は、異なるフローに関して異なる形で個別に適合化し、それによって、ＯＲステートメントの第１の条件を希望に応じてより厳しく又はより緩くすることができる。例えば、ＱｏＳが高いフローはより高い最大バッファ占有率設定を有することができ、それによって受付の可能性がより高い。対照的に、より低い最大バッファ占有率設定は、受付けの可能性を低くする。換言すると、最大バッファ占有率は、フロー型に基づいた場合の混雑がどのような意味であるかについての概念が異なることを考慮してフローごとに指定することができる。
【００９６】
第２の条件は、一般的には、相対的混雑が存在するときに適用される。この場合は、フロー別情報が中心になる。示される例においては、第２の条件は、所定のフローに関するフロー当たりの現在のパケットがフロー当たりの指定された最大パケットよりも少ない場合に真である。具体的には、フロー当たりの最大パケットは、優先度がより高いフローはより高い値が割り当てられて優先度がより低いフローはより低い値が割り当てられるような形でフローに関して設定することができる。従って、現バッファ占有率が相対的に混雑している（従って第１の条件は真にならない）ときには、より多いフロー当たり最大パケットを有するより高い優先度のパケットのほうが受け付けられる可能性が高くなる。優先度がより低いフローに関するフロー当たり最大パケットは、より低くなるように調整することができる。従って、これらのパケットを実際に完全に制限することを除き、より低い優先度のパケットのうちの相対的に非常に少ない数のパケットが受け付けられる。代替実施形態においては、フロー当たり累積パケットは、時間値（該時間値は、フローごとに変化することがある）を用いて計算してフローに関するパケットレートを生成することができる。次に、フロー当たり最大パケットは、同様にフロー当たりパケットレートに設定することができる。様々な代替パラメータ及びパケットを受け付けるか又は拒否するための関連条件が構想されており、本明細書における教義に照らして当業者に明確になるであろう。
【００９７】
これらのパラメータは、静的である必要がなく、システムのその他の条件（例えば、ＰＨＹからのレートフィードバックにおいて示されるようなリンク品質と関連レート）に基づいて更新することができる。当業者は、各々の変数に関する夥しい数の設定値を認識することになり、さらにこれらの設定値は変化するシステム状態に応じて様々な方法で変更可能であることを認識するであろう。
【００９８】
正味の結果は、フロー別パラメータをＴＸフロー状態テーブル１０３０から単に取り出すことによって有効なポリシング機能をライン速度で効率的に展開できることであり、各着信パケットに関して素早く決定を行うことができる。入力ポリシング機能に従ってパケットを受け付けるか又は拒否することは、あらゆるフロー制御技術と結合させることができ、その例は当業においてよく知られており、従って、可変のパケット処理レートをパケット損失なしに実現させることができる。一実施形態においては、パターン全体を外部インタフェースにおいて受信する前にフロー識別子を受信して入力ポリシング決定を可能にし、それによって、パケットが拒否されたときに該パケットを受信するためにインタフェース帯域幅を用いることを回避することができる。
【００９９】
要約すると、この例は、ポリシングに関する幾つかのオプションを強調する。高負荷下においては、単一のフロー（優先度が高いフローも含む）は、優先度がより高いフローにより大きいアクセスを許容する一方で、資源を支配しないように防止することができる。より軽い負荷下においては、その時点においては資源が消費中でないため、制限がより緩い決定が優先度の低いフローによる該資源の利用を可能にすることができる。入力ポリシングは、説明される４つの変数のいずれかの関数であることができ（及び代替実施形態は、その他の変数又はパラメータを利用することができる）。ポリシングは、公平性の確保のために用いることができ、どのような程度が希望されるかにかかわらずその他のフロー型が優先される場合でもすべてのフロー型に対して少なくとも何らかのアクセスを許容するようにすることができる。ポリシングは、低いリンク品質を管理するのにも用いることができる。リンク品質又は混雑の個別適合化のいずれが希望されるかにかかわらず、又はこれらの２つの組合せが希望されるかにかかわらず、同じ（又は同様の）パラメータを用いることができる。
【０１００】
図１０Ａに戻り、ＦＩＦＯ１０５０の出力がフラグメントブロック１０６０に引き渡される。ＦＩＦＯ１０５０は、受け入れられている１つ以上のパケットを、該当する場合は各々のヘッダー及びＭＩＣ計算とともに含むことができるのを思い出すこと。フラグメンテーションは、パケット型に依存して行うことができる。例えば、フラグメンテーションは、８０２．１１（ｅ）又は（ｇ）、又はフラグメンテーションが希望されるその他のパケット型に関してイネーブルにすることができる。実施形態例においては、グローバル変数、フラグメンテーションしきい値（ＦＴ）は、ＡＰ管理機能を通じて設定される（ＦＴは、ビーコンフレーム内において設定される能力要素である）。フラグメンテーションしきい値は、一般的には、短期間では変化しない。ファームウェアは、レジスタ内のフラグメンテーションしきい値を設定することができる。パケットがフラグメンテーションしきい値を超える場合は、潜在的な残存する部分的フラグメントを有するＦＴサイズのフラグメントにパケットを分割する。
【０１０１】
フラグメンテーションは要求事項ではないことに注目すること。代替実施形態においては、フラグメント１０６０及びすべての関連機能を省略することができる。以下において図４８に関してさらに詳細に説明される他の代替実施形態においては、２つ以上のＭＡＣ処理ブロックを採用することができる。該実施形態においては、１つのＭＡＣ処理ブロックは、フラグメンテーションを行うために備えることができ、他のＭＡＣ処理ブロックは、フラグメンテーションを行うことを目的として備えられない。一状況においては、高速パケットは、フラグメンテーションを要求しないか又はサポートしない場合があり、フラグメントブロック１０６０なしでＨ２Ｗプロセッサ５３０において処理することができ、フラグメンテーションを含むその他のパケット型（例えば、レガシー８０２．１１パケット）に関するサポートを追加のＭＡＣプロセッサ、例えば以下において詳述されるＭＡＣプロセッサ４８１０等、において提供することができる。様々なパケット型の全機能を処理する能力を有する単一のプロセッサを含む実施形態及び２つ以上のＭＡＣプロセッサを具備する他の実施形態であって、各々があらゆる部分組の機能を提供する能力を有する実施形態、を採用時における相反性を容易に理解するであろう。当然のことであるが、単一の組の機能を要求するパケットを処理することができる単一のＭＡＣプロセッサも採用可能である。
【０１０２】
フラグメントブロック１０６０は、フラグメンテーションしきい値及びパケットの長さに基づいてフラグメント数を決定する。フラグメント数は、リスト機能ブロック１０６５に引き渡され、リスト機能ブロック１０６５は、フラグメントブロック１０６０にポインタを戻す。フラグメンテーションがイネーブルされないか又はフラグメンテーションしきい値を超えない時には、フラグメント数は１になり、単一のノードポインタ及びその関連づけられた１つ以上のチャンクポインタが戻される。リスト機能ブロック１０６５は、（例えば、上図６において説明されるような）採用されたメモリ構造に関して適用可能な様々な連結リスト手順を実行する。示されるように、一例としてノードポインタキャッシュ８１０及びチャンクポインタキャッシュ８２０は、リスト機能ブロック内に常駐することに注目すること。従って、利用可能なポインタのプールを各キャッシュ内の利用可能なプールから取り出すことができる。これらのキャッシュをリフレッシュ及び補給する方法の詳細は示されていないが、当業者にとっては本明細書における教義に照らして明確になるであろう。概念的には、図１０Ａに示されるように、幾つかのフラグメントをリスト機能１０６５に送信することができ、その数のフラグメントに関する１つのグループのポイントを戻すことができる。フラグメンテーションが存在しない場合は、フラグメント数は１つであり、単一のノードポインタ及びその関連づけられたチャンクポインタ又は複数のポインタを戻すことができる。代替実施形態においては、同様の機能をフラグメントブロック１０６０によって実行することができ、パケット全体がフラグメンテーションされるまでリスト機能１０６５への繰り返しの呼が各フラグメントに関して行われる。各ポインタが戻されるのに応じて、グローバル変数バッファ占有率が、チャンク数又はパケット数に従って増大される。バッファ占有率は、実施形態例において測定可能であり、代替実施形態は、代替尺度を用いることができる。
【０１０３】
図１４は、ＦＩＦＯ １０５０の実施形態例を示す。ＦＩＦＯ １０５０は、１つ以上のＭＡＣサービスデータユニット（ＭＳＤＵ）１４１０Ａ乃至Ｎを含む。上述されるように、各ＭＳＤＵは、ヘッダー１４３０と、ペイロード１４４０と、ＭＩＣ計算１４５０（ＴＫＩＰが用いられる場合）と、を具備する。一実施形態においては、上述されるように、ＦＩＦＯ １０５０内の各ＭＳＤＵに制御データを加えることができ、フラグメントブロック１０６０からフィードバックすることができる。代替実施形態においては、制御情報はＦＩＦＯ  １０５０においては維持されない。Ｈ２Ｗプロセッサ５３０において用いるために追加された制御情報は、パケットバッファメモリ内にパケットを書き込む前に削除される。
【０１０４】
フラグメンテーションが必要ない場合は、ＭＳＤＵは、バッファ１０６２内に直接格納することができる。ＭＳＤＵは、リスト機能１０６５から取り出されたノードポインタ及びチャンクポインタとともに格納することができる。リスト機能は、各パケットに関する番号及びチャンクアドレスを与え、パケットペイロード（従ってチャンクペイロード）がメモリ内の対応するアドレスに書き込まれる。フラグメンテーションが希望される場合は、生成される各フラグメントもバッファ１０６２内に格納される。
【０１０５】
バッファ１０６２の内容は、メモリ書き込み１０７０に引き渡される。メモリ書き込み１０７０は、メモリアービター１０８０とインタフェースし、メモリアービター１０８０は、パケット及び／又はフラグメントをパケットバッファ内に実際に入れるためにパケットバッファメモリへのアクセスに関して競争する。メモリアービター１０８０は、ＭＡＣプロセッサＡＳＩＣ３１０の構成に依存して、図５に示されるようなメモリアービター５５６又は５５２のうちの１つとして実装できることに注目すること。
【０１０６】
メモリアービター１０８０は、メモリ書き込み１０７０からの要求を受け取るメモリアービターが示され、パケットバッファメモリへのアクセスに関して競争中のその他の構成要素からのその他の要求を受け取ることができる。アクセスが許可されると、メモリ書き込み１０７０に許可が戻され、パケット及び／又はフラグメントがパケットバッファメモリ内に書き込まれる。メモリ書き込みを行うために図９に示される方法と同様の方法を用いることができる。例えば、ノードが生成され、説明されるような長さ及びチャンクポインタ等を含む現在のデータが充填される。次に、実施形態例においては、各々の５１２バイトのチャンクが充填されるまで６４バイトのアクセスにおいてチャンクが書き込まれる。メモリ書き込み１０７０は、フラグメントが存在する場合はすべてのフラグメントを含むパケット全体がＲＡＭ内に書き込まれるまで要求を行い続ける。パケットを適切な待ち行列内にスレッドするために用いられるポインタは、パケットに関するノードポインタ（又は各フラグメントに関するノードポインタ）及び待ち行列内の最後のノード（後続する新しいパケット及び／又はフラグメントが添付される場所）を識別するための末尾待ち行列ポインタとして取り出される。
【０１０７】
一実施形態においては、メモリアービターは、入力状態マシン、ＷＬＡＮ  Ｔｘ状態マシン、ＷＬＡＮ  Ｒｘ状態マシン及び出力状態マシンからの要求を受け取る。メモリアービターは、優先度を用いてこれらの要求を仲裁することができ、一例は、次の優先順位である。すなわち、ＷＬＡＮ  Ｒｘ、ＷＬＡＮ  Ｔｘ、出力及び入力。状態マシンは、パケット全体が読み取られるか又は書き込まれる必要がある。その他の時においては、状態マシンは、スケジューリング及びその他の機能を実行するためにノードポインタ、チャンクポインタ、及び／又はその他の制御情報を探しているだけの場合がある。ＷＬＡＮ  Ｒｘ／Ｔｘ及び出力／入力目的で制御及びパケットの読み取り及び書き込みを網羅する優先度システムを構築することができる。
【０１０８】
フローは、フローの指定（すなわち、ＴＳＰＥＣ）が局によって行われたときにセットアップされる。その時点で、ファームウェアは、すべてのフロー関連テーブル内においてエントリをセットアップすることができる。さらに、ファームウェアは、そのフローに関する先頭ポインタ（従って最初のパケット）を入れることもできる。当業者は、新しい待ち行列を追跡するための及び関連づけられた先頭待ち行列ポインタを更新するためのその他の様々な方法を認識するであろう。
【０１０９】
実施形態例においては、メモリアービターは、その他の構成要素によるパケットバッファメモリへの公平なアクセスを許容するためにメモリアクセスを限られたバイト数（すなわち、６４）に制限する。一実施形態例においては、入力書き込み要求、ＷＬＡＮ  ＲＸ書き込み、及びＷＬＡＮ  ＴＸ出力の間にラウンドロビン方式のアクセスがメモリに与えられる（すなわち、以下において詳述されるハンドオフ）。例えば、１５００バイトのＭＰＤＵは、ＭＰＤＵ全体が割り込まれたストリーム内に書き込まれた場合にアクセス待ちのその他に長いレーテンシーを導入する。スケジュール、例えばラウンドロビン、が、その他のプロセスにおける行き詰まりを防止する。
【０１１０】
図１５は、ＭＳＤＵ１４１０を１つ以上のフラグメント（各々はフラグメンテーションしきい値に従ってサイズが決められる）、及び可能な残存フラグメントに分割するプロセスを示す。この例においては、制御１４２０は省略される。１つの代替実施形態においては、制御１４２０は、示されるように、単に第１のヘッダー１５１０の先頭に添付することができる。制御情報は、ポインタ、又は各ヘッダー１５１０の先頭に添付することができてメモリ書き込みを完了する前に取り除くことができるその他の制御情報を含むことができる。図１５においては、各フラグメント１５３０Ａ乃至Ｎは、ヘッダー１５１０が先頭に添付され、各フラグメントは、ＭＳＤＵからのペイロード１４４０の一部分であるペイロード１５２０として識別される。各ヘッダー１５１０は、パケットのシーケンス番号であるシーケンス番号１５４０と、各々の個々のフラグメントと関連づけられた番号であるフラグメント番号１５５０と、を含む。
【０１１１】
実施形態例においては、フラグメンテーションが行われた後は、各フラグメントはパケットとして取り扱われる。このことは、本明細書において詳述される様々なＭＡＣ処理技術を通じてのパケット及びフラグメントの効率的な処理を考慮するものである。代替実施形態は、この要求を共有する必要がない。最終的なフラグメント１５３０Ｎは、ＴＫＩＰが用いられる場合はＭＩＣ１４５０を含む。実施形態例においては、ＭＩＣは、ＭＩＣ１０２５によるフラグメンテーション前にパケット全体にわたって計算されたことを思い出すこと。
【０１１２】
図１６は、２つ以上のメモリ書き込み１６１０Ａ乃至１６１０Ｎと関連したアービター５５６の概念的構成を示す。メモリ書き込み１６１０は、直前において説明されたメモリ書き込み１０７０、又は後述されるその他の様々なメモリ書き込みのうちの１つであることができる。各メモリ書き込みブロックは、要求１６３０をアービター５５６に送信する。アービター５５６は、メモリ書き込みがいつ開始するかを示す許可ライン１６４０を各メモリ書き込みブロックに送信する。アービター５５６は、ＳＤＲＡＭコントローラ１６５０への引き渡しを目的として許可されたメモリ書き込み構成要素の出力を選択するようにＭＵＸ１６２０を制御することもできる。例えば、ＳＤＲＡＭコントローラ１６５０は、図５に示される例においてはＳＤＲＡＭインタフェース５６２であることができ、又はＳＤＲＡＭ３４０に結合されたその他のいずれかの構成要素を含むことができる。選択された構成モードに従ってパケットメモリにパケットを書き込むためにメモリアービター５５２に関して同様の仲裁方式を採用できることに注目すること。当業においては様々なメモリ仲裁方式がよく知られており、これらのうちのいずれかを本明細書における様々な実施形態において採用することができる。一実施形態例においては、一般的には、コントローラは、インタフェースによって後続される。コントローラは、メモリへの読み書きの論理を制御することができ、インタフェースは、物理的接続を提供する。図１６は、１つの説明例である。
【０１１３】
送信処理
前節においては、入力パケッの効率的なＭＡＣ処理に関する側面を例示する様々な実施形態が説明され、最終的には、送信を待つために様々なデータ構造を利用してパケットが処理されてパケットバッファ内に入れられた。送信処理に関する本節においては、上記のデータ構造の使用によって得られるさらなる効率が明らかになるであろう。さらに、高速ＭＡＣ処理に関する効率を向上させるその他の側面が紹介される。
【０１１４】
一般的には、複数のＳＴＡに関する数多くのフローをサポートすることができるアクセスポイントは、１６のフローをサポートする相対的に単純なＳＴＡよりも複雑な解析を提供する。従って、後述される実施形態の多くにおいては、より複雑なアクセスポイントが基準として用いられる。必要なときには、ＳＴＡとアクセスポイントとの間における相違が強調される。一般的には、送信処理の際には、多くの数のフローを受け入れ、その一方で送信機会が利用可能になったときには素早く反応できることが望ましい。さらに、レガシー送信仕様のサポートが重要になることがある。回路面積の減少、より効率的な回路の使用、設計の単純化、及び／又はレガシープロトコル及び構成要素とのインタフェース能力に起因して幾つかの側面が強調される。
【０１１５】
送信機会が生じたときに即座に対応する必要があることを示す一例は、不定期自動節電引き渡し（ＵＡＰＳＤ）プロトコルを含む。他の例は、即時ブロックａｃｋである。以下において詳述される実施形態は、素早い対応が可能なように１つの部分組のパケットを維持することによって効率的な複数のフローのサポートを提供する。この提供は、ＵＡＰＳＤに関するサポート、即時ブロックａｃｋ、及びＴＸＯＰが入手されたときの即座の引き渡しを可能にする。このことは、ほとんどの場合において、これまでに用いられている帯域幅保存技術、例えばＣＴＳを自己に送信する、等、を不要にする。一例においては、メモリへのアクセスの際における混雑がより大きい統合物を準備するのを妨げる場合は、小さい一組のパケットをＴＸＯＰ中に素早く送信することができる。その組のパケットに関してａｃｋが受信された時点で、ＴＸＯＰ内に残りの容量が存在する場合は、追加のパケットを送信することができる。上述されるように、パケット処理の高速部分からファームウェアを取り除くことは、効率を向上させる。実施形態例においては、ファームウェア処理（及びその相対的に低い速度）をＭＡＣ処理から切り離すために様々なキャッシュ及び待ち行列を採用することができる。以下では、これらの及びその他の側面が様々な実施形態において例示される。
【０１１６】
以下において詳述される実施形態例においては、幾つかの側面が例示される。一側面においては、複数のキャッシュが採用され、各キャッシュは、フローのパケットと関連づけられた要素を格納するために用いられる。これらのキャッシュ（以下ではノードキャッシュ１８１０によって示される）は、様々なアプリケーションにおける低レーテンシー応答時間を考慮するものである。低レーテンシー応答は、局又はＡＰが様々な型の送信機会、例えば反対方向許可、ＵＡＰＳＤ及び同様の要求、の効率的な使用を可能にし、さらに、送信に引き続いて残りの送信機会を取得することを可能にする。低レーテンシー応答は、衝突の回避を容易にする（例えば、初期の送信機会における成功裏の即座の応答は、のちの応答試みにおいて生じるコンテンションに起因する衝突を回避することができる。低レーテンシー応答は、節電を容易にすることができる。
【０１１７】
他の側面においては、シャドー待ち行列（以下では、ピンポン待ち行列と呼ばれ、待機中待ち行列及びサービス中待ち行列によって定義される）は、（他のフローが送信のために処理中である間においても）送信機会前にフローの要素を待ち行列内に入れることを考慮するものである。従って、フローは、処理準備が整った状態で待機中である。このことは、処理を可能な限り繰り延べることを容易にする。繰り延べは、フローに関するレート決定を繰り延べるのを可能にするためにしばしば望ましい。その理由は、レート決定は可能な限り直近でさらに新しいものであり、スループットを最大にする及び／又は誤りを最少にするような適切なレートが選択されるのを考慮するためである。
【０１１８】
他の側面においては、フローに関するパケットと関連づけられた要素を待ち行列（以下に示される待ち行列１８４２、１８５０及び１８５５）に充填することは、（繰り延べられたレート決定に関して有用である）パケットを形成するための素早い長さ決定を容易し、さらに即座のパケット統合を容易にする。統合一般に加えて、例示される側面は、（すなわち、受信されたブロック確認応答に応答した）再送信を容易にする。これらの側面は、多くの状況においては別々に望ましく、さらに結合させることも可能である。
【０１１９】
レガシー８０２．１１システムにおいては、典型的には４つのＥＤＣＡ待ち行列に関するサポートが提供される。ＥＤＣＡ待ち行列は、メディア上においてスケジューリングされていない期間中はアクセスを求めて競争し、ＴＸＯＰがいったん入手された時点で、可能な限り多くのデータを、規定された最大のＴＸＯＰまで、送信する。競争中のＥＤＣＡ待ち行列を受け入れるために、競争中のＥＤＣＡ待ち行列によってＴＸＯＰを入手する試みが連続的に同時に行われるのを防止するための様々なバックオフ方式が採用される。従って、各ＥＤＣＡ待ち行列は、チャネルと関連づけることができ、そのために様々なタイマーが維持され、明確なチャネル評価（ＣＡＡ）が行われ、アクセスを得るためのその他の手順が実行される。これらの機能の一部は、チャネル間で又は待ち行列間で共有することができ、幾つかは異なることができる。数多くのフロー（すなわち、実施形態例における２５６のフロー）を同時にサポートするのを希望するアクセスポイント等の無線通信デバイスにおいては、バックオフタイマーを維持すること及び大量のフローの各々に関してＴＸＯＰを入手することに関連する様々なオーバーヘッドを行うことは望ましくないことがある。チャネル型の様々なパラメータに関して異なる設定を行うことは、異なるサービス質レベルを提供することになる可能性がある。
【０１２０】
図１７は、より小さい、固定された一組の標準的ＥＤＣＡ待ち行列１７３０を用いて相対的に大きい複数のＥＤＣＡ待ち行列１７１０をサポートするように構成された無線通信デバイスの一部分の実施形態例を示す。一アプリケーションにおいては、各々が異なるサービス質レベルを提供する複数のＥＤＣＡ待ち行列を採用することができる。この例においては、複数のＮの局別ＥＤＣＡ待ち行列１７７０Ａ乃至Ｎが維持される。実施形態例においては、サポートされる２５６のフローの各々に関する２５６の該待ち行列を維持することができる。ラウンドロビンセレクタ１７２０は、局別ＥＤＣＡ待ち行列間における仲裁を行い、４つの標準的ＥＣＤＡ待ち行列１７３０Ａ乃至Ｄのうちの１つにおいて待ち行列状態にすべきデータを選択する。代替実施形態においては、ラウンドロビンに加えての代替スケジューリングアルゴリズムをセレクタ１７２０において実行することができる。セレクタは、様々な方法で配置することができ、その一例が以下の図１８において詳述される。実施形態例においては、ファームウェアは、標準的ＥＤＣＡ待ち行列のうちの１つを用いて局別ＥＤＣＡ待ち行列を引き渡しのために選択するための選択基準を提供するスケジューリング機能を含む。代替実施形態においては、当然のことであるが、あらゆる数のＥＤＣＡ待ち行列をサポートすることができる。１つの実施形態においては、必要なタイマー及び共有チャネルへのアクセスを求めて競争して該アクセスを入手する上で要求されるチャネル評価構成要素を有する既存のレガシー処理構成要素の利用可能性に起因して４つの待ち行列が採用される。当業者は、本明細書における様々な実施形態において含めることができるか又は希望される追加の特長をサポートするように改修ことができる複数のレガシー８０２．１１コア及び構成要素を容易に見つけるであろう。本明細書において開示される原則に従ってレガシーコア及び／又は構成要素を利用する実施形態例が以下においてさらに詳細に説明される。ＥＤＣＡ待ち行列１７３０Ａ乃至Ｄにおいてスケジューリングされたパケットは、標準的なＥＤＣＡ手順を用いて送信することができる。ファームウェアスケジューラは、ＥＤＣＡ以外の追加スケジューリング、例えばポーリングされたＴＸＯＰ（一例がＨＣＣＡプロトコルにおいて既知である）、を実行することができる。当業者にとって明らかになるように、スケジューラを適合化することができる様々なその他のプロトコルを採用可能である。標準待ち行列を用いて送信するためにＥＤＣＡ待ち行列１７１０をラウンドロビン方式で選択することに加えて、一般的には、各ＳＴＡに関するパケットを統合してその局からの全パケットに関して固有操作（ｅｉｇｅｎｓｔｅｅｒｉｎｇ）（又はその他の空間処理）を行うほうが効率的である。固有操作は、送信が特定の局（又は同様に位置する局のグループ）に操作されたときに最大の利益を提供する。従って所定の局に向けられた全パケットを１つのバッファ内に入れてこれらのパケットを統合してその局に送信できるようにすることが合理的な場合がある。代替実施形態においては、全ＥＤＣＡパケットに関して単一のバッファを有することが可能である。しかしながら、この場合は、パケットが（その他の固有値を有する）その他の局のパケットとインターリービングされるときには、統合を行うことは困難又は不可能なことがある。
【０１２１】
ＥＤＣＡ待ち行列の使用は、例示することのみを目的とするものである。一般的には、様々な型のチャネルと関連づけられた一組の待ち行列を採用することができる。チャネル型は、サービスの質レベル及び／又は送信型、例えばスケジューリングされた又はコンテンションに基づくアクセス、に基づいて変わることができる。
【０１２２】
図１８は、下位ＭＡＣコア５４０の様々な構成要素を示した実施形態例である。パケット処理速度からファームウェアを切り離すためにパケット処理用ノード、待ち行列及びキャッシュを用いる効率を提供する様々な側面、及びその他の側面が次の例において示される。当業者は、追加の構成要素（示されていない）を採用できること、及び特定の実施形態においてはその他の側面又は特長を利用するために例示されるすべての側面又は特長が要求されるわけではないことを認識するであろう。図１８の詳細は、フローのスケジューリング及び最終的送信に関してスケジューリングされた様々なパケットの識別を示す。最終的には、スケジューリングされたパケットと関連づけられた識別子、関連づけられたパラメータ、及び各チャネル型に関するレディ信号が送信（ＴＸ）エンジン１８８０に引き渡される。上述されるように、この実施形態においては、パケット識別は、ノードを用いて行われる。この例においては、レガシー８０２．１１型チャネルは、例示することを目的として用いられる。当業者は、図１８において詳述される同様の構成要素を用いてあらゆるチャネル型を受け入れ可能であることを認識するであろう。この例においては、４つのＥＤＣＡ待ち行列、ＥＤＣＡ  ０−３  １８５０Ａが維持される。ブロードキャスト制御チャネル１８６０とともにＨＣＣＡ待ち行列１８５５も同様に採用される。ＥＤＣＡ０の構造がさらに詳細に説明され、その他のチャネルに関しては、様々な実施形態において同じ又は同様であることができるため詳細は省略される。
【０１２３】
送信スケジューリングは、ファームウェアが各チャネル（例えば１８５０又は１８５５）と関連づけられた１つ以上のコマンドリスト１８１５を満たすことから開始する。コマンドリストは、スケジューリングすべきフローＩＤが充填される。コマンドリストは、フローＩＤをＴＸＯＰとともに含むことができる。ＥＤＣＡ待ち行列に関して、ＴＸＯＰを入手するための競争が行われ、従って送信時間は事前に知ることはできない。しかしながら、最大ＴＸＯＰサイズをフローＩＤとともに含めることができる。ＨＣＣＡスケジューリングに関しては、スケジューリングされた引き渡し時間と同様にＴＸＯＰサイズを知っていることができ、このＴＸＯＰ情報は、関連づけられたコマンドリスト１８１５においてフローＩＤとともに含めることができる。各チャネルに関して、アレイコントローラ１８４０は、チャネルに関するパケットのスケジューリングを制御することができる。アレイコントローラは、コマンドリスト１８１５からフローＩＤをポップし、送信に関する次のスケジューリングされたフローを決定する。これらのコマンドリストのうちの一部を維持することは、ファームウェアスケジューラがひとまとまりの決定を一回で行って各々リストに入れることを可能にし、このことは、経時で行うことができる。このことは、様々なアレイコントローラ１８４０がリストからのフローＩＤを処理してファームウェアによる対話の必要性を低減させるのを可能にする。このことは、上述されるように、ファームウェアへの割り込みを低減又は排除するのを可能にし、ファームウェアスケジューリングをＭＡＣ処理から切り離す。ＥＤＣＡ型コンテンションに基づくチャネル又はＨＣＣＡ型のポーリングされた又はスケジューリングされたチャネルを含む、サポートされた一組のチャネルにおけるサービスに関するフローをスケジューリングするための代替技術は、当業者によって容易に適合化されるであろう。
【０１２４】
この例においては、サポートされる複数のフローの各々に関してＴＸノードキャッシュ１８１０が維持される。ＴＸノードキャッシュ１８１０は、一般的なフロー別キャッシュの例として役立ち、上記の待ち行列１７１０として採用するのに適する、実施形態例においては、２５６の該フローが維持される。各フローキャッシュは、（フローに関する各々のパケットを代表する）複数のノードに関するスペースを具備する。実施形態例においては、各フローに関する４つのノードが各ＴＸノードキャッシュ１８１０において維持される。従って、少なくとも４つのパケットが、２５６のフローの各々に関して送信されるべき次のパケットとして識別される。これらのフローに関して要求される即時送信は、少なくともこれらの４つのノードによって満たすことができる。代替実施形態においては、希望される場合は、追加ノードをサポートすることができる。
【０１２５】
この実施形態例においては、ノードは１つの側面を例示するために用いられる一方で、採用可能な同等の技術が幾つか存在する。例えば、代替データ構造をキャッシングすることができる。他の例においては、パケット自体をキャッシング可能である。一般的には、複数のキャッシュ１８１０として示されるキャッシュは、キャッシングされた要素の処理後に各々の１つ以上のパケットを識別して取り出すことができる１つ以上の要素を格納するために用いられる。
【０１２６】
ＴＸノードキャッシュリフレッシュ１８３５は、キャッシュ１８１０と対話して該キャッシュが充填された状態及び更新された状態を維持する。ＴＸノードキャッシュリフレッシュ１８３５は、メモリアービター、例えば上記において詳述されるメモリアービター１０８０、と対話することができる。一実施形態においては、フローに関する１つ以上のノードを取り出すための要求が行われ、パケットバッファにアクセスが許可されたときに、取り出されたノードを各々のＴＸノードキャッシュ１８１０に入れることができる。ＴＸノードキャッシュリフレッシュは、図１８に示される処理の残りの部分から相対的に自主的に動作させることができる。
【０１２７】
各チャネルに関するアレイコントローラ１８４０は、コマンドリスト１８１５からの送信に関する次のフローＩＤを決定する。フローＩＤに関して、アレイコントローラ１８４０は、ＴＸアレイ状態テーブル１８３０にアクセスして様々なパラメータを取り出す及び／又はそのフローＩＤと関連づけられた状態を格納する。従って、ＴＸアレイ状態１８３０は、サポートされたフローに関するフローごとの状態情報を維持する。（代替実施形態においては、ＴＸアレイ状態テーブル１８３０は、その他のフロー別状態テーブル、例えば上述されるＴＸフロー状態テーブル１０３０と結合させることができる点に注目すること。）ＴＸノードキャッシュリフレッシュ１８３５は、ＴＸアレイ状態テーブル１８３０と対話して後述されるキャッシュリフレッシュと関連づけられた一定のパラメータを更新することに注目すること。例えば、ＴＸノードキャッシュリフレッシュ１８３５は、各々のノードの送信待ち行列に基づいてフローに関するノードを取り出す。
【０１２８】
アレイコントローラ１８４０は、スケジューリングされたフローに関するフローごとの状態を利用して各々のＴＸノードアレイ１８４２に充填する（待ち行列の例示）。ＴＸノードアレイ１８４２は、ＴＸエンジン１８８０への引き渡しのために送信順に順序が設定されたフローに関するノードのアレイである。示されるように、コマンドリスト１８１５によって識別された、現在のスケジューリングされたフローに関するＴＸノードキャッシュ１８１０内に格納されたノードの組が、フローの送信がスケジューリングされるチャネルに関するＴＸノードアレイ１８４２に引き渡される。このことは、送信が利用可能になったときに直ちに一組の既知のノードのスケジューリングを行うことを考慮するものである。実施形態例においては、各フローをＴＸノードアレイ１８４２内に入れるために４つのノードを利用可能である。ＴＸノードアレイ１８４２の残りの部分は、フローに関する追加ノードを充填することができる。一実施形態例においては、ＴＸノードアレイ１８４２は、ＴＸエンジン１８８０を通じてのスケジューリングされた引き渡しのための時間において６４のパケット識別子、すなわちノード、を保持する。最初の４つは、フローのＴＸノードキャッシュから取り出され、残りのパケットはパケットバッファメモリから取り出される。その他のパケットバッファメモリアクセスと同様の方法で、パケットバッファメモリからフローに関するノードの取り出し要求を行うことができる（詳細は示されていない）。代替実施形態においては、ノードアレイは、最初にキャッシュ１８１０等のキャッシュから要素を取り出さずにパケットバッファから直接充填することができる。さらに他の実施形態においては、キャッシュ１８１０は、まったく採用する必要がなく、ノードアレイ１８４２によって示される側面を依然として享受することができる。
【０１２９】
アレイ制御１８４０、コマンドリスト１８１５、及び関連構成要素は、複数のキャッシュ（すなわち、１８１０）から要素を選択して複数の待ち行列のうちの１つ（例えば、待ち行列１８４２及びＥＤＣＡ及びＨＣＣＡ待ち行列１８５０及び１８６０によってそれぞ例示される待ち行列）に格納するためのセレクタ（例えば、図１７に関して上述されるセレクタ）内に含めることができる構成要素の例である。一般的には、あらゆる数のフロー別キャッシュ又はフロー別待ち行列（すなわち、パケットバッファ内の送信待ち行列）を、希望される要因（例えば、サービスの質、チャネル型、等）に基づいて、ノードアレイ１８４２等の待ち行列内又は複数の該待ち行列のうちの１つ内に要素を格納するためにセレクタによって選択することができる。
【０１３０】
実施形態例においては、上述されるように、ＴＸエンジン１８８０への引き渡しのためにＴＸノードアレイ１８４２に充填する様々なアレイコントローラ１８４０とは別個の、ＴＸノードキャッシュリフレッシュ１８３５の自主的動作が望まれる。しかしながら、アレイコントローラ１８４０がパケットバッファメモリからの各々のフローに関する待ち行列からのパケットにアクセス中であるのとほぼ同じ時点において該フローに関するＴＸノードキャッシュがリフレッシングを必要とする場合が時々ある。従って、アレイコントローラ１８４０又はＴＸノードキャッシュリフレッシュ１８３５のいずれかが送信待ち行列を壊すのを防止し、その待ち行列からパケットが複製されるか又は取り除かれるのを防止するためのインターロック機能を定義することができる。様々なインターロック技術が当業者にとって明らかになるであろう。以下において一実施形態例が図２０に関してさらに詳細に説明される。
【０１３１】
様々なチャネル、例えば、ＥＤＣＡチャネル１８５０、ＨＣＣＡチャネル１８５５又はブロードキャスト制御チャネル１８６０、の中に追加の側面を組み入れることができる。実施形態例においては、ＴＸノードアレイ１８４２は、２つのシャドーノードアレイとして実装される。従って、第１のシャドーＴＸノーアレイは、スケジューリングされたフローに関するノードを充填することができ、レディ信号をＴＸエンジン１８８０にアサートすることができる。これで、アレイコントローラ１８４０は、次のフローＩＤをそのコマンドリスト１８１５からポップし、次のフローに関するパケットを第２のシャドーＴＸノードアレイにローディングするのに必要な処理を行う。この方法により、他方のＴＸノードに充填している間に一方のＴＸノードアレイを送信に関して処理することができ、それによって、新しいノードアレイ充填プロセスを開始する前に送信が完了するのを待つことと関連する起こりうるレーテンシーを低減することができる。リンクＩＤ１８４４は、ＴＸノードアレイ１８４２と関連づけられ、従って、ＴＸエンジン１８８０は、２つの局間での実際の物理的リンクにおいてフローを送信する際に用いるために適切なリンクパラメータ及び状態を取り出すことができる。直前において説明されるようにピンポン又はシャドーキャッシュが採用されたときには、リンクＩＤ１８４４は、１つのシャドーＴＸノードアレイ内に含まれているフローに関するリンクＩＤ  Ａを格納し、リンクＩＤ  Ｂは、第２のシャドーＴＸノードアレイ内のフローに関するリンクＩＤを含む。代替実施形態においては、その他のパラメータを、各々のフローと関連づけて、１８４４においてリンクＩＤとともに格納することもできる。
【０１３２】
２つのシャドーノードアレイは、シャドー又はピンポン待ち行列の一般的側面を例示するものである。一般的には、待ち行列は、特定の型のチャネル、例えばＥＤＣＡ又はＨＣＣＡチャネル、に対応することができる。各チャネルは、複数のサービス質レベルから選択された、関連するサービス質レベルを有することができる。この例における待ち行列は、２つのシャドー待ち行列を具備する。待ち行列は、サービス中待ち行列及び待機中待ち行列を具備すると説明することもできる。物理的シャドー待ち行列は、サービス中待ち行列として割り当てられることと待機中待ち行列として割り当てられることを交互する。従って、上述されるように、待機中待ち行列は、サービス中待ち行列の処理と干渉せずに充填することができる。サービス中待ち行列が処理を終了時に、その対応するシャドー待ち行列を待機中待ち行列として再選択することができ、いずれの時点においても他のフローを充填するのを開始することができる。次に、待機中待ち行列であったシャドー待ち行列がサービス中待ち行列として再選択され、送信のための処理が開始することができる。この方法により、様々なサービス質レベルと関連づけることができる相対的に多い数のフローを、（サービス質レベルに従って、及びスケジューリングされた又はコンテンションに基づくアクセス、等に従って）該当する待ち行列内に格納するために選択することができる。選択は、上述されるように、ラウンドロビン方式であるか又はその他の型の選択基準であることができる。
【０１３３】
キャッシュ１８１０に関して上述されるように、この実施形態例においては１つの側面を例示するためにノードが用いられる一方で、採用することができる同等の技術が幾つか存在する。例えば、代替データ構造を、１８４２（又は１８５０及び１８５５）等の待ち行列内に格納可能である。他の例においては、パケット自体を格納することができる。一般的には、待ち行列１８４２として例示される待ち行列は、待ち行列内の要素の処理に引き続いて各々の１つ以上のパケットが識別されて取り出される１つ以上の要素を格納するために用いられる。
【０１３４】
例えばノードアレイキャッシュ１８１０からの４つのノードを“ピンポン”バッファ１８４２の片側に充填している間に、送信中にそのアレイの充填を続けるための時間が存在することができる。最初の４つのパケットを即時使用するＵ−ＡＰＳＤモードが既述されさらに以下においてさらに詳細に説明される。Ｕ−ＡＰＳＤにおいては、“さらなる”ビット等のインジケータを最初の４つのパケットとともに送ることができる。（要求されるフレーム間スペースを有する状態で）パケットを送信して最初の４つのパケットの確認応答を待機後、送信機は、追加送信の準備を完了している必要がある。この間に、採用された実施形態により適宜、ＴＸノードキャッシュ又はパケットバッファから、フローからの追加ノードにアクセスすることができる。その他の送信型の場合は、利用可能な送信機会によって提供される全パケットの送信のためにＴＸノードアレイを一杯の状態に保つための同様の機会が存在することができる。
【０１３５】
ブロードキャスト制御１８６０は、所定の実施形態においてアレイコントローラ１８４０と同様の機能を有する状態で配置することができる。しかしながら、縮小された又は代替の一組の機能を要求することがある。この例においては、ビーコンパケットを指し示すポインタ１８６３を具備するビーコンブロック１８６２が採用される。ファームウェアは、当業においてよく知られるように、ヘッダー情報、希望されるパラメータ、等を含むビーコンパケットを生成することができる。ビーコン１８６２は、生成されたパケットを該当時間における送信のために取り出すことができる。例えば、ファームウェアスケジューラは、生成されているビーコンに関するタイムスタンプ値を生成してこの値をビーコンブロック１８６２に引き渡すことができる。従って、ビーコンは、該当期間（すなわち、８０２．１１実施形態においてはＴＢＴＴ）において又はその近くにおいて送信することができる。該例においては、ビーコン１８６２は、ブロードキャスト制御１８６０を通じて、ＴＸエンジン１８８０へのレディ信号を生成する。メディアに関するコンテンションが実行され、ビーコンは、該当する時間に送信され、チャネルがクリアされるのを待ちことに関連づけられた遅延に関して調整される。当業者は、本明細書における教義に照らして、ビーコン又はその他のシステムシグナリングメッセージを受け入れるように図１８を簡単に適合化するであろう。代替実施形態においては、ビーコン１８６２は、インダイレクション（ｉｎｄｉｒｅｃｔｉｏｎ）ポインタ１８６３を用いるのではなく、実際には直接ビーコンパケットを格納することができる。
【０１３６】
同様の方法で、ブロードキャストチャネル又はマルチキャストチャネルも同様に生成することができる。ブロードキャスト及び／又はマルチキャストチャネルは、基本的には特殊目的のフローＩＤである。ブロードキャストチャネルは、上述されるコマンドリスト１８１５等の複数のＩＤを用いてスケジューリングする必要がない。しかしながら、複数のブロードキャストチャネル及び／又は様々なマルチキャストチャネルが希望される場合は、同様のスケジューリング手順も採用することができる（詳細は示されていない）。ブロードキャストパケット又はマルチキャストパケットは、（ブロードキャスト制御１８６０を介して）ＴＸエンジン１８８０において送信するためにブロードキャストマルチキャストブロック１８６４においてポインタ１８６５によって識別することができる。代替として、パケットは、それ自体を１８６４において格納することができる。図１８を説明する際に用いられているように、図６に関して上述されるようなパケットバッファメモリ方式が採用されるときには、パケットへの言及はノードへの言及に読み替えることが可能であることが明らかになる点に注目すること。上記から理解できるように、パケットを格納するためにノード及びチャンクが用いられるときには、パケットバッファメモリ自体内において待ち行列を維持することが効率的でさらに容易である。さらに、図１８において例示されるような様々なフローをスケジューリングするためのキャッシュは、（パケットをノードとともに移動させるのではなく）単にノードを取り出して格納することによって維持することができる。以下においてさらに詳細に説明されるように、実際のパケットデータがパケットバッファから取り除かれる唯一の時点は、パケットの送信時点である。他方、パケットの処理及びスケジューリングは、単にノードを用いることによって達成される。ノードの利益を例示する追加の側面が、以下においてＴＸエンジン１８８０について説明される際にさらに詳細に説明される。受信処理側においても同じように同様の利益が享受される。
【０１３７】
以下において図４８及び４９に関してさらに詳細に説明されるように、代替実施形態においては、パケットバッファ以外のソースから着信した、ＴＸエンジンにおける引き渡しのためのパケットが存在することができる。例えば、レガシーパケット又は低スループットパケットを、ファームウェアＭＡＣプロセッサを用いてプロセッサ内においてフォーマット化することができ、これらのパケットを送信用に提供することができる。上記において詳述される構造は、該実施形態に合わせて適合化できることに注目すること。例えば、コマンドリスト１８１５は、代替ソースからの送信をスケジューリングするためにも用いることができる。例えば、フローＩＤ、送信すべきパケット数、及びパケットが高スループット又は低スループットのいずれであるかを記すインジケータ（より一般的には、パケットバッファ又は外部パケットソースからの送信）。低スループットパケットがスケジューリングされる場合は、後述されるように、送信プロセッサメモリＦＩＦＯ（すなわち、４９５０）、又は代替として（例えばＤＭＡを通じて）プロセッサメモリから取り出すことができる。該実施形態においては、ブロードキャスト制御１８６０に関して生成されたメッセージ、例えば、ビーコン及びあらゆるブロードキャスト又はマルチキャストメッセージは、代替としてファームウェア内においても同様に形成可能であることに注目すること。従って、構成要素１８６２、１８６４及び１８６０は、省略可能である。
【０１３８】
図１９は、下位ＭＡＣコアプロセッサ５４０の１つのセクションの詳細な実施形態の例を示す。図１９に示されるように、セレクタ１９３０は、コマンドリスト１８１５から取り出されたフローＩＤを引き渡す。この説明は、いずれの型のチャネルにアクセス中であるかは任意であるという点で概念的説明である。あらゆる数のコマンドリストを選択してＴＸアレイ状態１８３０に結合させることができる。選択されたチャネルからのフローＩＤがＴＸアレイ状態１８３０に提示されるときには、関連づけられたフロー別アレイ状態１９０２が取り出され、その状態の様々な成分を必要とする１つ以上の構成要素に引き渡される。セレクタ１９３０は、（すなわち、アレイ状態１９０２に格納された）フロー別パラメータをフロー識別子に基づいて選択的に取り出すセレクタを示す例である。一般的には、フロー状態テーブル（又はその他の組のフロー別パラメータ）は、フロー識別子によって取り出すことができ、又はフロー識別子に従ってフローインデックスを選択し、そのフローインデックスを用いて（おそらく１つ以上のメモリに格納されている）フロー別パラメータを探し出すことによってインダイレクションを介して取り出すことができる。本明細書において示される例は、これらの技術のうちのいずれかを用いて格納及び／又はアクセスすることができる様々な受信及び送信フロー別パラメータを示す。図３及び４において一般的に示されるように、いずれのモードで構成されるかに依存していずれかの型のフロー別パラメータを用いる集積回路（例）を採用することができる。この採用は、大小にかかわらず、利用可能なメモリ内の可変数のフローを効率的にサポートする能力を容易にする。
【０１３９】
フロー別アレイ状態例１９０２が示される。関連づけられたフローに関してパケットバッファからノードを取り出すときには、取り出すべきノード数は、ウィンドーサイズ及び利用可能なパケットの最小である。従って、利用可能な総パケット数又は送信ウィンドーサイズ１９１０のいずれに関しても、（実施形態例における）一連の最大で６４のノードをＴＸノードアレイ内に充填することができる。上述されるように、各々のフローのＴＸ待ち行列内の次の後続ノードは、フローに関して利用可能なパケットが枯渇するまで又はウィンドーが満たされるまで、各ノード内の次の待ち行列ポインタを読み取り、次のノードを取り出し、該ノードをＴＸアレイ内に入れる等によって決定される。
【０１４０】
先頭待ち行列ポインタ１９１２は、各々のフローの送信待ち行列（例えば、連結リストデータ構造）に関する待ち行列の先頭にあるノードを指し示すポインタを示す。先頭待ち行列ポインタは、フローからのパケットが送信されるときに順に取り出される第１のノードである。待ち行列内のパケット数は、フィールド１９１４に格納される。この数は、入力パケットがフローに関して受信されたときには増加され、これらの入力パケットが送信されたときには減らされる。フィールド１９１６に格納された場合のキャッシュ内のパケット数は、ＴＸノードキャッシュ１８１０を補給するためにＴＸノードキャッシュリフレッシュ１８３５と関連して及びＴＸノードアレイ１８４２にノードを入れるために用いることができる。リンクＩＤ１９１８が所定のフローに関して取り出され、リンク専用状態及び／又はパラメータを取り出すために送信機において用いるためにリンクＩＤ１８４４に格納することができる。幾つかの実施形態においては、連結ノードリストは、多数のパケットから成ることができる。ウィンドーサイズは、ウィンドー内のパケットのみが送信に関して処理されるようにするために用いることができる。ウィンドーエンドポインタ１９２０をウィンドー管理のために用いることができる。代替実施形態は、追加のフィールドを含むことができ、説明されるフィールドのうちの一部を省略することができる。追加フィールド例は、ＡＭＰＤＵ密度フィールドと、送信待ち行列末尾ポインタと、を含む。
【０１４１】
図２０は、図１８において示されるように用いるために採用することができるインターロック例を示す。この例においては、ＴＸノードキャッシュリフレッシュ１８３５は、パケットバッファメモリから情報を取り出し中であるときにビジー信号を生成する。この間に、更新中であるＴＸノードキャッシュのフローＩＤも示す。これで、アレイコントローラ１８４０は、処理中のフローＩＤがパケットバッファからアクセスされたノードを有するかどうかを知っている（幾つかのアレイコントローラ１８４０が存在することができ、各アレイコントローラは、これらの信号を各チャネルに関して１つ受信することに注目すること）。これで、そのフローＩＤからの幾つかのパケットはノードアレイキャッシュへ移行中であるため、アレイコントローラ１８４０は、そのフローＩＤに関するパケットバッファＲＡＭへのアクセスを繰り延べることができる。このことは、アレイコントローラ１８４０がフローに関するＴＸノードキャッシュリフレッシュ動作と干渉するのを防止する。
【０１４２】
さらに、ＴＸノードキャッシュリフレッシュからフローＩＤを受信するために幾つかの比較ブロック２０１０が採用される。各比較ブロックは、各々のチャネルのアレイコントローラ１８４０が各々のＴＸノードアレイ１８４２内の追加スペースに充填するためのノードを取り出すことを目的としてパケットバッファにアクセス中であることを示すフローＩＤをチャネルから受け取る（すなわち、ＥＤＣＡ ０乃至３  １８５０Ａ乃至Ｄであり、詳細は示されない）。これらのフローＩＤのうちのいずれかがマッチする場合は、各々のラインがアサートされる。ＯＲゲート２０２０は、全比較出力の論理的ＯＲを提供し、ビジー信号を生成する。ＴＸノードキャッシュリフレッシュ１８３５は、ビジー信号が消えるまで更新継続を待つことができる。又は、異なるフローのキャッシュの更新を試みるためにフローＩＤを変更することができる。フローＩＤを変更することがビジー信号をデアサートする場合は、ＴＸノードキャッシュリフレッシュ１８３５は、いずれのアレイコントローラ１８４０の動作とも干渉しないことを知っている。当業者は、このインターロック方式、及び本明細書における教義の適用範囲内おいて採用することができるその他のインターロック方式の様々な修正を認識するであろう。
【０１４３】
代替実施形態（詳細は示されない）においては、上述されるように、４パケットノードキャッシュ（ＦＰＮＣ）１８１０が各フローに関して維持される。各キャッシュは、ノードポインタ（１２バイト）を含む。上述されるように、これらは、各々のフローが送信機会を得たときにＷＬＡＮにおいて送信される最初の４つのパケットである。この実施形態においては、パケットが入口において受信されると、ＳＤＲＡＭ内に入れられ、（ＴＸノードキャッシュリフレッシュ１８３５と同様であることができるか又はＴＸノードキャッシュリフレッシュ１８３５の代わりに採用することができる）ノードキャッシュ有限状態マシン（ＦＳＭ）がシグナリングされる。受信されたパケットに対応する４ノードパケットキャッシュ内に余地が存在する場合は、ノード情報が各々のキャッシュメモリに追加される。ノード情報が連結リストに入れるためにＳＤＲＡＭに送られるときには、ＦＰＮＣにも送られる。ＦＰＮＣ内に余地が存在する場合で、（各々のフローに関するＷＬＡＮ  Ｔｘ  Ｏｐ中に）ＦＰＮＣが使用中でない場合は、ノード情報がＦＰＮＣに入れられる。フローがサービス中であることをＦＳＭに示すようにサービス中ビットをアレイコントローラ１８４０によって設定することができる。この設定は、有効性の点では上記において詳述されるインターロックと同様である。
【０１４４】
ＦＰＮＣ状態マシンは、ＦＰＮＣを更新するために先入れ先出し方式で動作する。ＦＰＮＣは、以下において詳述されるＵ−ＡＰＳＤによってイネーブルにされる局に関するパケットを提供するのに特に有用である。トリガーが受信されると、下位ＭＡＣコア５４０は、トリガーについて確認応答し、上述されるように、最大で４つのパケットの統合物によって直ちに応答することができる。ＦＰＮＣ状態マシンは、ＦＰＮＣがＴｘ  Ｏｐに起因して枯渇後に補給する必要がある。ＦＰＮＣ状態マシンは、補給する必要があるフローを識別する待ち行列を利用して動作することができる。待ち行列は、ＦＰＮＣによるサービスに関して優先順にあるフローから成ることができ、優先度は，局がＵ−ＡＰＳＤモードにあるか、フローがＨＣＣＡ又はＥＤＣＡに基づくフローであるか、等の考慮事項によって決定される。
【０１４５】
この代替実施形態の効果は、上記において詳述されるインターロックを用いるＴＸノードキャッシュリフレッシュブロック１８３５と同様であることができる。一般的には、入口からのトリガー及び／又は定期的リフレッシュに基づいてノードアレイキャッシュを更新することが必要になる場合がある。音声等の時間が極めて重要なアプリケーションに関しては入口からの瞬間的（又はほぼ瞬間的な）トリガーが望ましい場合がある。定期的リフレッシュは、（すなわち、フローに関するパケットのうちの１つ以上が送信のために送られており、ノードキャッシュ１８１０内に存在しなくなった後に）パケットバッファ内のパケットをＴＸノードキャッシュに補給するために用いることができる。（例えば、パケットが入口に到着し、ノードキャッシュが一杯であり、このためパケットは単にパケットバッファ内に入るだけである場合は、一般的に希望される結果は、キャッシュを一杯の状態に保つことである）。定期的リフレッシュは、実施形態例においては自主的に動作するバックグラウンドプロセスであることができる。当業者は、ノードキャッシュを一杯の状態に保つために、及び着信中の入力パケット及び発信中の送信パケットによって生み出されるニーズに応じてノードキャッシュを一杯にするために状態マシン、サービス中ビット、インターロック、及び様々なその他の技術を用いることができることを認識するであろう。
【０１４６】
図２１は、図１８に関して上記において詳述されるリンクＩＤ  １８４４の実施形態例を示す。示されるように、ＴＸノードアレイ１８４２に組み込まれたシャドーＴＸノードアレイのうちの１つにおいてフローを有するリンクＩＤを識別するリンクＩＤ  Ａ  ２１１０が格納される。フィールド２１２０は、そのリンクＩＤとともに含まれているパケット（すなわち、ノード）数を識別する。この実施形態においては、リンクＩＤは物理層パラメータ（ＰＨＹレート等）及びセキュリティキーを識別するために用いられるため、統合は依然としてフローＩＤに基づく。このテーブルへのインデックスは、フローＩＤである。
【０１４７】
同様に、リンクＩＤ  Ｂ  ２１３０は、ＴＸノードアレイ１８４２内に組み入れられたその他のシャドーＴＸノードアレイ内のフローのリンクＩＤを識別するために格納される。そのリンクＩＤと関連づけられたパケット数は、フィールド２１４０に格納される。これらに加えてその他の様々なパラメータ及び／又は状態変数を、希望される場合に代替実施形態において用いるために、各々のフローと関連づけて格納できることに注目すること。
【０１４８】
図２２は、下位ＭＡＣコア５４０の実施形態例の追加構成要素を示す。図１８に関して上述されるように、複数のチャネルをＴＸエンジン１８８０に接続することができ、各々のチャネルは、１つ以上のパケットの送信準備が完了していることをＴＸエンジン１８００に知らせるためのレディインジケータをアサートする。パケットを識別するノードは、ＴＸノードアレイ１８４２において待機していることになり、これらのパケットに関する関連づけられたリンクＩＤが格納される。各チャネルに関して一組のこれらの構成要素の各々が存在することができる。図２２は、これらのパケットが送信チェーン内を下流に移動するのに応じたこれらのパケットのさらなる処理を示す。
【０１４９】
ＴＸエンジン１８８０は、様々なレディ信号を受信し、様々なプロセス及びタスクの実行に関してこれらのレディ信号間で仲裁する。ＴＸエンジン１８８０が送信のためにパケットを準備する態勢が整っているときには、共有メディアを用いるために利用可能な時間の長さを示すＴＸＯＰのサイズを知っている。しかしながら、データレートはリンク状態に基づいて可変であるため、ＴＸＯＰ内における送信すべきパケット数も変化する。実施形態例においては、特定のパケットが用いるＯＦＤＭシンボル数を決定する際に用いるためにレート有限状態マシン（ＦＳＭ）２２１０が採用される。ＴＸエンジン１８８０が（ノードの長さフィールド内に好都合に配置された）単位がバイトのパケットの長さを示すＴＸ長さをレートＦＳＭ２２１０に引き渡す。リンクＩＤが（リンクＩＤ１８４４）から引き渡され、レートＦＳＭ２２１０がそのプロセスを開始するように指示するための開始信号が引き渡される。レートＦＳＭ２２１０は、パケットが用いるシンボル数を戻す。この情報は、以下においてさらに詳細に説明される統合を実行時に累積することができる各パケットに関するシンボル数を決定するために用いることができる。シンボル数、レート、等を決定するための様々な代替技術を採用可能であることに注目すること。パケットごとのシンボル計算を行う外部ＦＳＭの使用は、採用に適する多く例のうちの１つであるにすぎない。レートＦＳＭ２２１０の実施形態例が以下において詳述される。
【０１５０】
ＴＸエンジン１８８０は、メモリアービター、例えば上述されるメモリアービター１０８０、にも結合される。送信準備が完了している各々のパケットに関して、ＴＸエンジン１８８０は、各々のノード内の情報に従ってパケットバッファからチャンクをフェッチし、次チャンクポインタによって識別されたあらゆるリンクされたチャンクをフェッチする。チャンクデータは、ＴＸエンジン１８８０に戻され、ＴＸエンジン１８８０において１つ以上のＦＩＦＯ２２２０に引き渡される。この例においては、ＦＩＦＯ２２２０は、レガシープロトコルエンジン２２１０に内蔵される。１つ以上のＦＩＦＯへのデータの書き込みは、ＦＩＦＯレディ信号、又はその他のフロー制御メカニズムによって規制できることに注目すること。上述されるように、及び以下において図４８及び４９に関してさらに詳細に説明されるように、代替実施形態においては、２つ以上のＭＡＣプロセッサとのインタフェースのためのＴＸエンジン１８８０への追加入力が存在することができる。代替実施形態例においては、プロセッサ２１０及びファームウェアは、低スループットパケットを処理するためのＭＡＣプロセッサを実装する。これらのパケットは、プロセッサメモリＦＩＦＯ４９５０から（又は、代替実施形態においてはプロセッサメモリから直接）ＴＸエンジン１８８０に引き渡すことができる。
【０１５１】
上述されるように、８０２．１１ＭＡＣ処理をサポートするために既存のレガシープロトコル構成要素を用いて様々な機能を実行するのが好都合になる場合がある。その他の標準化されたプロトコルエンジンも採用可能であり、レガシープロトコルエンジン２２１０を改修して希望される様々な特長を提供することができる。レガシープロトコルエンジンの実施形態例においては、４つのＥＤＣＡ待ち行列の各々に関して１つずつ、４つのＦＩＦＯ２２２０  Ａ乃至Ｄが存在する。ＨＣＣＡチャネルに関する追加のＦＩＦＯ２２２０Ｅが存在し、ＦＩＦＯ２２２０ Ｆ乃至Ｇは、ビーコン及びブロードキャスト／マルチキャストチャネルに関して採用することができる。ＦＩＦＯは、単一のバッファとして（すなちわ、ビーコン信号を格納するために）採用できることに注目すること。送信用にパケットを受信するためにあらゆる数のＦＩＦＯ又はその他のバッファ型を採用することができる。
【０１５２】
レディアサーションを受信した時点で、ＴＸエンジン１８８０は、第１のノードにおける指定に従って第１のパケットチャンクを適切なコアＦＩＦＯに入れる。直前において説明されたように、このことは、追加チャンクが存在する場合は第１のパケットが完了するまで継続することができる。同時に、送信することができる総パケット数は、レートＦＳＭ２２１０を用いて決定することができる。ＦＩＦＯレディをモニタリングする一方で、ＴＸエンジン１８８０は、手順を継続して残りのパケットを各々のＦＩＦＯに入れることができる。実施形態例においては、ＦＩＦＯ内にパケットを入れることは、レガシープロトコルエンジン２２１０を駆動してアクセス（ＥＤＣＡ型アクセス）求めて競争させ、（アクセスが入手されたとき、又はスケジューリングされたＴＸＯＰ中に）送信を開始させる。
【０１５３】
図２３は、レートＦＳＭ２２１０の実施形態例を示す。受信されたリンクＩＤは、レートテーブル２３１０内へのインデックスとして用いられる。テーブル２３１０は、リンクＩＤに基づいて格納され、リンクと関連づけられた１つ以上のレートと、タイムスタンプ値（ＴＳＶ）２３１１と、を具備する。レートテーブル２３１０は、様々な方法のうちのいずれかによって更新することができる。ファームウェアは、更新されたレートを提供することができる。受信されたデータレートベクトルフィードバックパケットは、レート情報を含むことができ、様々なレートを更新するために用いることができる。ＴＳＶ  ２３１１は、レートフィードバックが入っているパケットが受信されたときのタイムスタンプを示すために、従ってレート情報が新しいか又は古いかの表示を提供するために用いることができる。例えば、ある時間においてレートが更新されていない場合は、控えめな手法は、介在する時間枠においてチャネルが劣化している場合にレートを引き下げることである。ファームウェアは、時効が存在するかどうか及びレートをバックオフすべきかどうかを決定し、レートテーブルを更新することができる。実施形態例においては、４本のアンテナの各々に対応する４つのレートＲ１乃至Ｒ４  ２３１２乃至２３１５が存在する。その他の情報、例えば固有操作モード又は他の拡散モードのいずれが用いられるか、をレート計算の際にも用いることができる。テーブル２３１０からのレート情報は、レート計算ＦＳＭ２３２０に送られる。
【０１５４】
各レートに関して、レート選択テーブル２３３０は、各々のレートに関して利用可能なシンボル当たりのバイト数を用いてファームウェアによって更新されるテーブルを具備する。一実施形態例においては、Ｎ＝１６レート２３３２が存在し、各々のレートは、シンボル当たりの対応するバイト数を有し、従って各レート選択値は４ビットである。シンボル当たりのバイト数は、加算器２３３５に引き渡され、加算器２３３５の出力は、統合レート累積器２３４０に向かう。
【０１５５】
統合レート累積器２３４０は、統合レートを累積するために用いられ、出力は、加算器２３３５にフィードバックされる。累積器２３４０は、レート計算ＦＳＭ  ２３２０からのクリア信号によってクリアすることができる。利用可能なレートの各々に関して、シンボル当たりのバイト数が加算されて総統合レートが累積され、該総統合レートから、一定数のシンボルＮＳ  ２３６０を用いてストリーム数を示すことができる。ＮＳ  ２３６０は、ストリーム数を示すために用いることができる。２３４５においてＮＳ  ２３６０が減じられて統合レートが提供される。ＮＳ  ２３６０は、ファームウェアによって更新することができる。実施形態例においてバイト単位で引き渡されたパケットの長さが、２３５０において定数２３６５（同じくファームウェアによって更新可能）に加えられて真の長さが生成される。ＣＯＮＳＴ  ２３６５は、オプションの制約事項を示すことができる。例えば、連続するＭＰＤＵヘッダー間における最低限の分離を提供するＡＭＰＤＵ密度を採用することができる。除算器２３５５において、真の長さＡが統合レートによって除算され、ＮＳに関して正規化され、商及び余りが生成される。商は、加算器２３７５に引き渡されてシーリング関数が概念的に生成され、該シーリング関数において、２３７０内に何らかの余りが存在する場合は１つの追加シンボルを用いなければならない（すなわち、シンボルの一部分に充填され、このため、シンボル全体を採用しなければならない）。レジスタＮ  ＳＹＭ  ２３７５は、レート計算ＦＳＭ  ２３２０によってイネーブルにされ、その結果得られたシンボル数がＴＸエンジン１８８０による引き渡し及び使用を目的として格納される。
【０１５６】
図２４は、概念的レガシープロトコルエンジン２２１０を示す。プロトコルエンジンが機能する様々なモードのうちの１つを示すためにモード選択信号を用いることができる。一般的には、ＭＰＤＵが、送信が開始すべきであることを示すためのレディ信号とともに引き渡される。レガシープロトコルエンジンは、入力されたＭＰＤＵから暗号化された出力を生成することができる。実施形態例においては、（一般的には、典型的な８０２．１１コア内に存在する）レガシープロトコルエンジンの暗号化機能が利用される。代替実施形態においては、当業においてよく知られるように、あらゆる型の暗号化装置を含めることができる。図２４には、暗号化されない出力ＭＰＤＵを生成するためにレガシープロトコルエンジン２２１０に引き渡される（例えば、ＷＬＡＮ１２０から受信された）暗号化された入力も示される。
【０１５７】
図２５は、ＰＨＹ２６０への概念的リンクと接続された典型的なレガシープロトコルエンジンを示す。示されるように、ＲＸベクトルが、受信されたデータ及びクリアチャネルアセスメント（ＣＣＡ）信号とともにＰＨＹ２６０からレガシープロトコルエンジン２２１０に引き渡される。ＲＸベクトルは、様々な情報、例えば変調型、受信データの長さ、及びその他のパラメータ、を具備することができる。特に、例えば上述されるレートＦＳＭ２２１０におけるレート決定に役立つデータレートフィードバックを戻すことができる。クリアチャネル評価は、コンテンションに基づくプロトコル（例えば、ＥＤＣＡ）を使用時にメディアへのアクセスに関して競争するために、様々なチャネルと関連づけられたタイマー２５１０とともに用いることができる。暗号化及び暗号解読は、ブロック２５２０において行うことができる。ＦＩＦＯ２２２０は、上述されるＦＩＦＯと同様であることができる。ＨＣＣＡに関しては、当然のことであるが、送信がスケジューリングされ、予め決められた時間に開始することができる。符号化されたデータは、送信が開始すべきであることを示すＴＸ要求とともにＰＨＹ２６０に送られる。ＰＨＹ２６０に引き渡されるＴＸベクトルは、レガシー機能の結果得られた様々なパラメータを示す。実施形態例においては、レガシーモードで動作時には、レガシープロトコルエンジンの出力はＰＨＹ２６０における送信に関して十分であることに注目すること。
【０１５８】
図２６は、送信パケットのＭＡＣ処理のさらなる詳細を説明した実施形態例を示す。実施形態例においては、レガシープロトコルエンジン、ＭＰＤＵ（該当時は暗号化される）が統合モジュール２６１０に引き渡される。図２５において詳述される実施形態とは対照的に、レガシープロトコルエンジン２２１０から出力された暗号化されたデータは、直接ＰＨＹには引き渡されない。実施形態例においては、暗号化されたＭＰＤＵのタイミングが設定された安定したストリームが統合モジュールに引き渡され、次に引き渡しを目的としてＰＨＹに引き渡されるようにレガシープロトコルエンジン２２１０の改修を行うことができる。改修は、フレーム間スペース（例えば、ＳＩＦＳ）又は統合されたフレームを生成するために要求されないＭＰＤＵのその他の特長に対して行うことができる。様々な実施形態においては、統合されたフレームは、様々な形態であることができ、様々な型のパケット又はＭＰＤＵを具備することができる。パケットのタイミングを設定する、例えばタイムスタンプ、アクセスに関するコンテンション、等に関する様々な技術が上記において詳述されており、当業においてよく知られる。
【０１５９】
統合対象となるパケット数は、ＴＸエンジン１８８０において計算することができる。レートＦＳＭ２２１０への呼は、各パケットに関して行うことができ、パケットごとに戻されるシンボル数に関して、ＴＸＯＰをそのシンボル数だけ減らすことができる。ＴＸＯＰ内に適合する総パケット数が決定されるまで各統合パケットに関する統合パケットカウントを増やすことができる。この情報は、統合モジュール２６１０に引き渡すことができる。
【０１６０】
あらゆる数の統合フォーマット及び／又は方式を様々な実施形態において採用することができる。実施形態例においては、統合ＭＰＤＵ（Ａ−ＭＰＤＵ）が統合モジュール２６１０から出力される。Ａ−ＭＰＤＵ ２７１０のフォーマットは、図２７に示される。示されるように、ＭＰＤＵデリミッタ２７２０が、統合ＭＰＤＵ ２７１０内の各ＭＰＤＵ ２７２２間に配置される。Ａ−ＭＰＤＵのサブフレームの長さが４バイトの倍数であるようにするために、１つ以上のパッドシンボル２７２４をＭＰＤＵ ２７２２の最後に挿入することができる。各ＭＰＤＵ ２７２２は、ＭＰＤＵヘッダー２７３２と、ＭＰＤＵペイロード２７３４と、フレーム検査シーケンス２７３６と、を具備する。この例においては、ＭＰＤＵデリミッタ２７２０は、ゼロに設定された予約ビットを具備する長さＣＲＣフィールド、ＭＰＤＵの長さ、予約ビット及び長さのＣＲＣ、及びＭＰＤＵを走査及び検出するために用いることができる一意のパターンである。一実施形態例においては、一意のパターンは、文字“Ｎ”に関するＡＳＣＩＩ値に設定される。
【０１６１】
今度は図２６に戻り、統合ＭＰＤＵをレートマッチングＦＩＦＯ２６２０内に格納することができる（代替実施形態においては、レートマッチングＦＩＦＯは、採用されたＰＨＹの型及びその特徴に依存して必要でないことがある）。レートマッチングＦＩＦＯ２６２０は、ＰＨＹ２６０における送信のための最終的なパケット引き渡しに関してＭＡＣ／ＰＨＹインタフェース５４５に結合される。
【０１６２】
受信処理
図２８は、下位ＭＡＣコア５４０の受信構成要素を例示する実施形態例を示す。下位ＭＡＣコア５４０において説明される受信構成要素、又はそれらから成る部分組は、図４９に示される代替実施形態に関して後述される受信エンジンの一部分を具備することができる。ＷＬＡＮ１２０から受信されたパケットを含む情報データは、ＭＡＣ／ＰＨＹインタフェース５４５に到着し、分割ユニット２８０２に引き渡される。上述されるように、図２６及び２７における統合に関して、Ａ−ＭＰＤＵ例は、分割ユニット２８０２において着信データストリームをコンポーネントパケットに分離するために用いることができるＭＰＤＵデリミッタ２７２０を具備する。
【０１６３】
その結果得られるＭＰＤＵストリームは、ＦＣＳ及びフィルタリングブロック２８０４に引き渡される。このブロックにおいては、フィルタリング機能は、ブロードキャストパケット又はマルチキャストパケットを含む受信パケットのうちのいずれかがインスタントデバイスに関してアドレッシングされるかどうかを決定する。フレーム検査シーケンスも同様に検査される。次に、受信機に関してアドレッシングされ、フレーム検査に合格したパケットがＦＩＦＯ２８１２に引き渡される。
【０１６４】
実施形態例においては、パケットは、適宜アドレッシングされた良好なパケットであるとする仮定の下で、受信されるのに応じてＦＩＦＯ内に格納される。これで、パケットは、無効パケットであるか又は現在の受信機に関してアドレッシングされていないことが判明した場合はＦＩＦＯから簡単にフラッシングすることができる。（１つの単純な制御メカニズムは、前ＦＩＦＯポインタを保持すること、及び最近格納されたパケットがフラッシングされる場合にそのポインタを復元することである。）ＦＩＦＯ２８１２からの（フラッシングされない）パケットは、コアインタフェース２８６０に引き渡される。
【０１６５】
ＲＸコントローラＦＳＭ ２８０６は、図２８において詳述される様々なブロックのうちのいずれかを制御するために採用される。特に、ＲＸコントローラＦＳＭ ２８０６は、パケットが受信された時点で処理を開始し、パケットが受信チェーンを通過するのに従って即時の結果をイネーブルにする及び格納するための様々な制御信号を提供することができる。
【０１６６】
この例においては、ヘッダーが受信されて処理のためにパケットパース２８１０に引き渡される。パケットのヘッダーから、送信長が知られ、さらに、パケットが開始する場所及びパケット内においてデータ及び／又は制御バイトを見つけることができる場所が知られる。ヘッダーは、パケット型（すなわち、８０２．１１（ａ）（ｂ）（ｇ）（ｅ）（ｎ）、又はその他のサポートされるパケット型）も示す。
【０１６７】
パケットパース２８１０は、パケットがフローＩＤからのポール型アクセス（例えば、コンテンションのないポール）から受信されたかどうかを知っている。これで、パケットパース２８１０は、予め決められた期間内（例えば、ＳＩＦＳ内）に応答が要求されるときに応答を開始するための信号を送信機に送る。パケットパース２８１０は、送信機が応答するのを可能にするためのフローＩＤ及びＴＸＯＰ情報を引き渡すことができる。ブロックａｃｋ要求が受信されたときには、受信されたビットマップは、要求された場合に予め決められた時間枠内においてブロック確認応答（例えば、即時ブロックａｃｋ）を行うために送信機に引き渡すこともできる。ブロックａｃｋ、及びその他の即座応答処理、例えばＵ−ＡＰＳＤ、が以下においてさらに詳細に説明される。
【０１６８】
パケットパース２８１０は、着信パケットを格納するために必要なチャンクポインタ数を決定するチャンクポインタＦＳＭ ２８５０にチャンク長を引き渡す。チャンクポインタＦＳＭは、上記において導入されたＲＸチャンクポインタキャッシュ８４０からチャンクポインタを取り出す。この実施形態例においては、チャンクは、上述されるチャンクと同一であるが、受信パケットは、真の連結リスト待ち行列の複雑さ及び余分のメモリに関する要求事項を要求しない。むしろ、より単純化されたアレイを採用することができる。この実施形態は、以下において図３３に関してさらに詳細に説明される。代替実施形態においては、ＲＸパケットは、希望される場合に送信処理の際に用いられる連結リスト構造と同一の連結リスト構造を用いることもできる。チャンクポインタＦＳＭ ２８５０は、パケットとともに用いるために追加チャンクを取り出す必要があるときに又はＲＸチャンクポインタキャッシュ２８４０を更新時に（メモリアービター１０８０を通じて）パケットバッファ２５０とインタフェースする。実施形態例においては、選択されたチャンクサイズ及び典型的パケット長が与えられた場合に１つのパケット当たり最大で４つのチャンクポインタが必要になる場合がある。これらのチャンクポインタは、受信処理チェーンの残りの部分を横断するのに従ってパケットのヘッダー内に格納され、パケットバッファ内への最終的なパケットの書き込みに用いられる。
【０１６９】
コアインタフェース２８６０は、拡大ＲＸベクトルに含まれているチャンクポインタ及びパラメータを（ハードウェアテーブル２８２０から）取り出し、ＦＩＦＯ ２８１２から受信されたパケットのヘッダーに加える。次に、上述されるように、主に実施形態例における暗号解読に関して用いられるレガシープロトコルエンジン２２１０に対してパケットが引き渡される。実施形態例においては、及び利用可能な典型的レガシープロトコルエンジンにおいては、ヘッダーは無視されることに注目すること。従って、この例において説明されるように制御情報をヘッダー内に格納することによって様々な制御メカニズムを実行することができる。レガシープロトコルエンジン２２１０からの暗号解読されたパケットは、ＲＸ  ＦＩＦＯ２８７０に引き渡される。実施形態例においては、ＲＸ  ＦＩＦＯ ２８７０は、共有することができ又は図５に示される同等のＦＩＦＯ ５７２と同一であることができる。
【０１７０】
ハンドオフ及び出力（ｅｇｒｅｓｓ）が以下においてさらに詳細に説明される一方で、その基本構造が図２８に示される。この構造の一側面は、ハンドオフ決定が実際のハンドオフプロセス自体から切り離され、その他のパケットが出力ハンドオフを待っているときに発生する可能性があるボトルネックを待たずにパケットが受信及び処理されるのを可能にすることである。ボトルネックは、順序どおりのパケット引き渡しが規定されおり、１つ以上のパケットに関して再送信が要求されるときに発生する可能性がある。この点が以下においてさらに詳細に説明される。
【０１７１】
ＲＸ  ＦＩＦＯ２８７０からのパケットは、上述されるように、メモリアービター１０８０を介してパケットバッファメモリ２５０へのアクセス要求を行うメモリ書き込み２８７５に引き渡される。パケットがパケットバッファに書き込まれるのを待っている間に、そのパケットに関するパラメータがハンドオフ決定ブロック２８８０に引き渡されてハンドオフ決定を開始する。パケットがパケットバッファ内に完全に書き込まれる前に急速ハンドオフ手順が生じるのを防止するために、メモリ書き込み２８７５からハンドオフ決定２８８０に書き込み完了信号が送信される。
【０１７２】
ハンドオフエンジン２８９０がハンドオフ決定２８８０に接続される。ハンドオフ決定２８８０とハンドオフ２８９０との間における対話に関する様々な信号例が示されており、以下においてさらに詳細に説明される。ハンドオフエンジン２８９０は、メモリアービター１０８０を介してパケットバッファからパケットを取り出し、パケットを出力のために最終的に引き渡す。ハンドオフエンジン２８９０は、パケット型に依存して、デフラグブロック２８９２を用いて、例えばパケットフラグメントからヘッダーを取り除き、フラグメンテーションされていないパケットをパケット出力時における引き渡しのために再形成することができる。以下において図４８に関して詳細に説明されるように、フラグメンテーションはオプションであることができ、関連する構成要素を省略することができる。時々、１つ以上のパケットを取り除くべき状況が生じることがある。フラッシュブロック２８９４は、これらのタスクを実行するためにハンドオフエンジン２８９０に接続される。待ち行列、ポインタ、ノード、及びチャンクに関する連結リスト構造を維持することに関連づけられた様々なその他のメモリ管理機能もこれらのブロックにおいて取り扱うことができる。
【０１７３】
ＲＸサーチコントローラ２８１４は、ＦＩＦＯ２８１２に入るパケットをモニタリングする。ＲＸサーチコントローラは、パケットに関するフローＩＤを決定する。実施形態例においては、上記の図１０におけるような入力パケット処理に関して説明されるように、ＴＡ及びＴＩＤ探索テーブルを採用することができる。ハードウェアテーブル２８２０は、フロー及びチャンクの両方に関する状態及びパラメータを維持するために採用される。以下においてハードウェアテーブル２８２０がさらに詳細に説明され、図３及び４に関して上述される２つの構成に関する実施形態例を含む。その関係においては、ハードウェアテーブル２８２０は、ハードウェアテーブル３２０の構成要素であることができる。
【０１７４】
一実施形態においては、入力及び出力（そして可能な場合は送信処理）に関して別個のハードウェアテーブルが維持される。代替実施形態においては、１つ以上の機能がハードウェアテーブルを共有することができる。その場合は、ハードウェアテーブル２８２０は、図３及び４において詳述されるようにハードウェアテーブル３２０と実質的に同一であることができる。テーブルを共有することは、複数の要求に関する仲裁と関連する複雑さを発生させること、及び要求されるアクセス数に関する十分な帯域幅の確保が必要になることを当業者は認識するであろう。他方、テーブルを共有することは、全体的な面積を縮小することができ、複数のテーブルにわたって両方に共通するパラメータの更新数を減らすことができる。例えば、結合された受信及び入力ハードウェアテーブルを有するＡＰについて検討する。ＴＳＩＤ及びＴＩＤは、ＡＰが以前に送信した先であるＳＴＡからＡＰが受信中であるときには同じである。行先ＭＡＣアドレス及び送信ＭＡＣアドレスが同じであるということは常に真であるわけではないが（行先には追加の結合されたデバイスが存在する可能性がある）、同じである状況が存在する。これらの状況においては、テーブルを共有することに益がある。従って、結合テーブルは、アドレスが同じでない場合にいずれかのテーブルが単独で受け入れることになる場合よりも大きくすることができる。しかしながら、共有することは、面積上の利点を生み出すことができる。
【０１７５】
上述されるように、実施形態例においては、ファームウェアが更新中にリストの順序を再設定するのを可能にするピンポンキャッシュ、及びシャドーリストからのサーチコントローラに関する同時アクセスを採用することができる。ハードウェアテーブル２８２０をインデキシングするために用いられるフローＩＤを入手するためにバイナリ探索が行われる。
【０１７６】
図２９は、ＳＴＡとして構成されるハードウェアテーブル２９２０の実施形態例を示し、図３に関して上述される配置と類似する。従って、この場合は、ＳＴＡは（この例においては）１６のフローしかサポートしないため、フロー及びリンクと関連づけられたすべての様々なパラメータはハードウェアテーブル内において維持される。ハードウェアテーブル２８２０には、各々のサポートされるフローに関する送信アドレス２９１２、ＴＩＤ２９１４、及びフローＩＤ  ２９１６のリストが存在する。従って、フローＩＤは、ＴＡ＋ＴＩＤから取り出すことができ、該当するＲＸフロー状態テーブル２９２０に関するインデックスとして用いることができる。実施形態例においては、ファームウェアは、順序が設定されたテーブルを作成し、１つの又は他のテーブルに関して作業するようにＨＷに指示する。バイナリ探索は、ＨＷにおいて現在のテーブルを対象として行われる。新しいフローを追加する必要があるときには、ファームウェアは、該フローを待機テーブルに追加し、順序を設定し、ハードウェアの現在のテーブルを待機テーブルに切り換える。これで、原テーブルが新しい待機テーブルになる。ＲＸフロー状態テーブル例２９２０が以下において図３１に関して説明される。
【０１７７】
ハードウェアテーブル２９２０には追加のリンク専用パラメータを含めることもできる。これらのパラメータは、Ｒｘハードウェアテーブル２９２０に格納することができるリンクＩＤによってアドレッシングすることができる。例は、レート決定に関して用いるために上述されるデータレートベクトルフィードバック２９３０と、レート決定と、パケット形成と、統合と、を含む。受信プロセッサは、遠隔デバイスから引き渡されたメッセージからのこの情報へのアクセスを有することができ、この情報をハードウェアテーブル２９２０に格納することができる。上述されるように、リンク別セキュリティキー２９４０を様々な型の暗号化に関して用いることができる。様々な暗号化プロトコルをサポートするために様々なセキュリティキーの型を格納することができる。レガシー複製検出ブロック２９５０は、正確に受信された最後のパケットのシーケンス番号を格納し、複製検出目的で現在のパケットのシーケンス番号をこの値と比較することができる。
【０１７８】
図３０は、上記において図４に関して詳述されるように、アクセスポイント又はスーパーステーションにおいて用いるように構成されたハードウェアテーブル２８２０の実施形態例を示す。この例においては、様々なポインタ３００２は、ハードウェアテーブル２８２０内のＭＡＣインデックス３００４と関連づけられる。この例においては、リンクＩＤ  ３００６も各ＭＡＣ  ＩＤとともに格納されることに注目すること。リンクＩＤ  ３００６は、代替として、例えばＳＲＡＭ  ３３０等の代替格納場所においてその他のパラメータとともに格納することが可能であることに注目すること。（リンク及びフローに関する様々なパラメータがハードウェアテーブルに格納された）図２９に示されるハードウェアテーブル２８２０とは対照的に、リンクＩＤ３００６以外のすべてのパラメータが代替メモリ、例えばＳＲＡＭ  ３３０に格納される。
【０１７９】
ＳＲＡＭ ３３０は、共通レートテーブル３０１０Ａ乃至Ｎを具備し、これらのテーブルの各々は、各ＭＡＣアドレス（すなわち、最大で１６のフローをサポートすることができるリンク）に関するポインタを具備する。フローインデックス３０２０によって指し示されたパラメータテーブル内に様々なフローに関するパラメータが格納される。この格納は、実際のパラメータに関する１つのレベルのインダイレクションを提供する。実施形態例においては、ＳＲＡＭ  ３３０は、ＲＸ状態テーブル２９２０等のテーブルを格納するためにも用いられ、その一例が以下においてさらに詳細に説明される。従って、共通レートテーブル３０１０に示されるように、各リンクに関して、最大数のフローに関するサポートがインデキシング方式内に含まれている。しかしながら、フローが追加されるのに従ってメモリ使用量が増大する可能性がある。メモリは、フローがアクティブになる前にパラメータを格納するために割り当てる必要がない。従って、所定のリンクに関して、１つ又は２つのみのフローがアクティブである場合は、１つ又は２つのＲＸフロー状態テーブル２９２０のみを作成して充填する必要がある。
【０１８０】
図３０には、単にセキュリティキー３０４４及びビットマップ３０４６のみを含む代替テーブル３０４２も示される。この例は、８０２．１１（ｇ）パケットとともに用いるのに適した縮小パラメータセットを示す。該代替実施形態においては、縮小された状態テーブルを用いることは、追加のメモリアクセスと関連するメモリ及び時間を節約することができる。しかしながら、一実施形態においてはすべてのパケット型に関して共通の構造を用いることもできる。
【０１８１】
以下では、ＲＸフロー状態テーブル例２９２０の詳細が図３１に関して説明される。しかしながら、ここでは１つの構成要素であるビットマップ３１３０が例示される。ビットマップポインタ３０５０は、ビットマップ３１３０を指し示した状態が示される。ビットマップ３１３０は、実施形態例においては、ＳＲＡＭ  ３３０にも格納される。このレベルのインダイレクションは、要求可能な最大メモリの再割り振りとは対照的に、メモリ使用量がニーズに応じて増大するのを許容する一方で、単純な共通するビットマップアクセスフォーマットを可能にする。従って、ＲＸフロー状態テーブルを必要に応じて増大させる能力と同様の方法で、メモリを再割り振りする必要なしに様々な型のビットマップをサポートすることができる。例えば、フラグメンテーションがサポートされるときには、ビットマップは、各々が１６のフラグメントを有する６４のパケットを具備することができる。このビットマップは、６４パケットウィンドーにおいて各パケットに関して単一のビットを有する単純なブロックａｃｋビットマップによって要求されることになる場合よりもはるかに大きいビットマップである。従って、フラグメンテーションを要求するフローに関しては、より大きいブロックａｃｋビットマップを作成することができ、他方、より少ないメモリを要求するブロックａｃｋビットマップは、より小さいビットマップを用いて作成することができる。
【０１８２】
この図は、向上された柔軟性及びより効率的なメモリの使用に備えることを含む様々なメモリ構成上の側面を示す。以下では、追加ブロックａｃｋ処理上の側面がさらに詳細に説明される。
【０１８３】
図３１は、ＲＸフロー状態テーブル２９２０の実施形態例を示す。様々なフィールドが例示される。代替実施形態においては、追加フィールドを導入することができ、又は示されるフィールドの一部を省略することができる。一般的には、当業者にとって明確になるように、ＲＸフロー状態テーブル２９２０、フロー別アレイ状態１９０２、ＴＸフロー状態テーブル１０３０、及び同様のフロー別テーブルを含む本明細書のフロー状態テーブルのうちのいずれかを結合させるか又は分離させてあらゆる数のフロー別テーブルにすることができる点に注目すること。
【０１８４】
開始シーケンス番号３１０２は、ブロック送信における開始パケットのシーケンス番号を示すために用いることができる。開始シーケンス番号は、送信されたパケットが受信されたときに更新することができる（すなわち、ウィンドーが前方に移動する）。一実施形態においては、既存の開始シーケンス番号及びウィンドーサイズ３１０４は、予想される着信パケットのシーケンス番号を決定することができる。しかしながら、送信機は、このシーケンス番号限度を超えるパケットを送信することが許容され、その場合は、受信された最大シーケンス番号を取り出して（ウィンドーサイズ−１）を減じることによって計算することができる。開始シーケンス番号は、着信したＢＡＲ（Ｂｌｏｃｋ＿Ａｃｋ要求）によって明示で更新することもできる。以下では様々なブロック確認応答処理技術がさらに詳細に説明される。一例においては、ウィンドーサイズは、受信機において所定の送信機に割り当てられた（単位がパケットの）バッファを意味することができる。その場合は、送信機は、受信機においてウィンドーサイズを超える確認応答されないパケットを送信すべきでない。
【０１８５】
即時ブロックａｃｋフィールド３１０６は、送信機が即時の又は遅延されたブロック確認応答を予想しているかどうかを受信機に示すために用いることができる。即時ブロック確認応答のサポートは、現在の８０２．１１ｎ基準草案においては必須になっている。
【０１８６】
ビットマップ３１３０は、図２９に関して上述されるように、ハードウェアテーブル２８２０がＳＴＡとして構成されるときに実際のブロックａｃｋビットマップであることができる。代替構成においては、ビットマップ３１３０は、図３０に関して上述されるように、実際のビットマップを指し示すポインタであることができる。イーサネットヘッダー３１３２は、パケットの出力準備時にＭＡＣヘッダーを該当するイーサネットヘッダーと交換するために格納される。ＷＩＮポインタ３１３４は、受信機によって格納されて最終的にはより高い層にハンドオフする必要があるパケットの物理的アドレスを保持するデータ構造を指し示すポインタである（以下においてさらに詳細に説明されるハンドオフ技術例を参照すること）。一例においては、これらのパケットは、より高い層に順にハンドオフされるためにバッファ内に格納される。このデータ構造の先頭に穴（パケット損失）が存在する場合は、Ｒｘは、より高い層に整然と順序通りにパケットをハンドオフするためにこの穴が充填されるまで待たなければならない。以下において詳述されるウィンドーポインタ３３２０は、このフィールドにおいて用いるのに適したポインタの一例であることに注目すること。
【０１８７】
一例においては、旧開始シーケンス番号３１３８を、最初に開始シーケンス番号に等しく設定することができる。着信パケットが開始シーケンス番号を変更させるときには、受信機は、旧開始シーケンス番号から現在の開始シーケンス番号までの全パケットをより高い層に渡すことができる。この動作が実行された後に、旧開始シーケンス番号を現在の開始シーケンスに等しく設定することができる。リンクＩＤ  １３４０は、フローと関連づけられたリンクを示す。このことは、ＷＬＡＮ １２０において受信又は送信する際に用いるためのリンク専用パラメータを取り出すために用いることができる。上記では様々な例が詳述されている。受信すべきフラグメントがそれ以上存在しないことを示すフィールド３１３６を採用することができる。フラグメンテーションが実施されない様々な実施形態においては、又は代替ＭＡＣ処理ユニットにおいて実施されるときには、このフィールドは省略することができる。
【０１８８】
図３２は、ハードウェアテーブル及びメモリを様々な構成で構成するための方法の実施形態例を示す。図２９乃至３１に関して論じられている技術は、その他のハードウェアテーブル、例えば上記において詳述される送信フロー状態テーブル１０３０、とともに同様に適用可能であることに注目すること。送信テーブルを構成する詳細は、説明を簡潔にするために省略される。ハードウェアテーブルは、様々な構成要素（例えば、受信、送信、入力、出力、等）をサポートするために結合できることを思い出すこと。受信ハードウェア、フロー状態テーブル、ＲＡＭ、及び／又はパケットバッファに関するインダイレクションレベルによって識別される原則は、本明細書において説明されるその他の状態テーブル、又はその組合せに対しても同様の効力を持って適用可能である。
【０１８９】
一般的プロセス３２００は、図３２において説明される。この例においては、第１、第２の及び第３のメモリが説明される。本明細書において詳述されるように、様々な型のあらゆる数のメモリを採用可能であることに注目すること。一実施形態例においては、メモリ１は、ハードウェアテーブル、例えばハードウェアテーブル２８２０又は３２０である。メモリ２は、より大きいメモリ、例えばＳＲＡＭ  ３３０である。メモリ３は、この場合は外部メモリであるが、内部の第３のメモリも予想される。この例においては、メモリ３は、ＳＤＲＡＭ３４０であることができる。
【０１９０】
決定ブロック３２１０において、第３のメモリがパケットバッファに関して用いられる場合は、３２１６に進み、無線通信デバイスの様々な構成要素を第１のモードにおいて構成する（すなわち、ＭＡＣプロセッサ３１０ＡＳＩＣ  ３１０における構成要素又は様々なその他の構成要素）。実施形態例においては、第１のモードは、外部ＲＡＭ、例えばＳＤＲＡＭ３４０、に格納された外部パケットバッファを利用する。
【０１９１】
決定ブロック３２１０において、第３のメモリがパケットバッファに関して用いられない場合は、３２１２に進み、無線通信デバイスの様々な構成要素を第２のモードで構成する。実施形態例においては、第２のモードは、上述されるＳＴＡ型モードであり（ここで、ＳＲＡＭはパケットバッファに関して用いられる）、パラメータはハードウェアテーブルに格納される。
【０１９２】
３２１６において、第２のメモリ内のデータ構造を指し示すＭＡＣアドレッシングされたポインタを有する第１のメモリ（ハードウェアテーブルであることができる）を構成する。３２１８において、データ構造を有する第２のメモリをセットアップする。これらのデータ構造は、例えば図３０に関して上述されるような様々な追加のインダイレクションレベルを含むことができる。例えば、第１のデータ構造は、ＭＡＣアドレスと関連づけられたフローを識別することができる。フローＩＤは、ＲＸフロー状態テーブル又はＴＸフロー状態テーブル等の追加テーブルをインデキシングするために用いることができる。さらに、１つ以上のテーブル、例えばＲＸフロー状態テーブル、は、フローと関連づけられた追加のデータ構造を指し示すポインタ（例えば、ブロックａｃｋビットマップの格納場所を指し示すビットマップポインタ）を有することができる。３２３０においては、第３のメモリにおいてパケットバッファを構成する。一例においては、パケットバッファを構成することは、様々なフリーポインタリスト（例えば、フリーノードポインタリスト７１０及びフリーチャンクポインタリスト７２０）をセットアップすることと、ノード７２０及びチャンク７４０用のスペースを割り振ること、とを含む。さらに、関連づけられたフリーウィンドーポインタリストを有するアレイを割り振ることができる（例えば、パケットの受信処理のために用いられるアレイ）。
【０１９３】
ファームウェアは、適切なデータ構造を有する様々なメモリをフォーマット化するために要求されるステップのうちの多くを実行することができる。必要な場合は、デバイス内の構成要素にモードを示すために様々なレジスタ設定又はその他の様々な変数設定技術を用いることができる。これらの技術は、当業者によく知られるであろう。以上のように、第１のモードが構成され、プロセスは停止することができる。
【０１９４】
３２１２において、直前において説明されたような様々なデータ構造を有する第１のメモリを構成する。この場合は、メモリ１は、ハードウェアテーブルであることができ、データ構造は、必ずしも間接的にアクセスされないが、図２９において説明されるとおりであることができる（例えば、ハードウェアテーブル内のフローごとにインデキシングされたＲＸフロー状態テーブル）。３２１４において、３２２０においてメモリ３に関して上述されるとまったく同じやり方で第２のメモリをパケットバッファとして構成する。このようにして、第２のモードが構成される。これで、プロセスは停止することができる。本明細書において詳述されるＭＡＣ処理は、継続することができる。
【０１９５】
図３３は、ＲＸパケットアレイをサポートするように構成されたパケットバッファ２５０の一部分に関する代替実施形態を示す。この実施形態は、図６において示されたパケットバッファ２５０と同様である。しかしながら、この構成においては、図６の連結リスト待ち行列のデータ構造は、ノードアレイ３３３０によって置き換えられる。アレイデータ構造の使用は、幾つかの単純化を可能にする。この例においては、ノードアレイ内のノードは隣接しており、このため、次ノードポインタ６１２は要求されない。従って、ノード６１０は、縮小ノード３３１０に置き換えられる。ノード３３１０内に残っているフィールド、長さ６１４、シーケンス番号６１６、及びチャンクポインタ６１８は、図６に関して説明されるとおりである。より小さいノードは、メモリ使用量を低減させる。
【０１９６】
上述のように、チャンク６２０は、様々な長さのパケットを格納するために用いられる。１つの相違点は、アレイ構造は待ち行列を形成するためのノードのスレッディングを要求しないことである。従って、直前において述べられたように、ノードの所在を指し示すための次ノードポインタが要求されない。待ち行列末尾ポインタ６４０及び待ち行列先頭ポインタ６３０は、希望されるノードアレイ３３３０がパケットバッファ内のどの場所に所在するかを識別する単一のポインタ、ウィンドーポインタ３３２０、に置き換えられる。この修正されたノード／チャンク構造の使用は、本明細書における教義に照らして当業者にとって明確になるであろう。繰り返すと、図６の構造は、その状況に関しても完全に適するため、直前において説明されるアレイ構造は、ＲＸ処理のために要求されない。しかしながら、ノードアレイ３３３０は、図３３において示されるように採用されたときには、最大で、パケットアドレス格納場所に値する１つのウィンドー全体を格納することができる。ノードアレイ３３３０は、ウィンドーオフセットによって現在の開始シーケンス番号に合わせてインデキシングすることができる。この場合は、ノードアレイ３３３０は、パケット格納場所の環状バッファとして用いることができる。
【０１９７】
ハンドオフ処理
この節においては、ハンドオフ処理がより詳細に説明される。ハンドオフ決定２８８０及びハンドオフエンジン２８９０は、関連づけられた信号及びその他の相互に接続されたブロックとともに、図２８に関して紹介された。以下ではハンドオフに関連する幾つかの側面が例示される。
【０１９８】
一側面においては、ハンドオフ決定は、ハンドオフプロセス自体から分離される。決定プロセスは、ライン速度で行うことができ、ハンドオフエンジンは、バックグラウンドにおいて自主的に動作する。この側面が有用であることができる１つの状況例は、ブロックＡＣＫに関するサポートによって示される。８０２．１１（ｇ）又は（ｂ）等の初期の無線パケットシステムにおいては、ブロックＡＣＫに関するサポートは存在しなかった。パケットが到着したときには、確認応答されるか又は確認応答されない。パケットが確認応答される場合は、ハンドオフされ、後続パケットの送信が再開する。パケットが確認応答されない場合は、送信機は、正確に受信されるまでパケットを再送信する（又は、プロセスが予め定義された限度を超えることに起因して捨てられる）。従って、パケットは、本質的には、到着するのに従って順にハンドオフされる。
【０１９９】
ブロックＡＣＫをサポートするシステムにおいては、順序が乱れているパケットを受信する可能性がある。パケットが正確に受信されたときには、関連づけられたビットがウィンドービットマップにおいて設定される。確認応答されないパケットの場合は、関連づけられたビットをゼロに設定することができる。将来においてパケットの再送信を試みることができる。その間に、後続するパケットを受信してハンドオフのために格納することができる。パケットが順にハンドオフされることが意図されているシステムにおいては、確認応答されないパケットは穴を生成し、確認応答されないパケットが正確に受信されるのを待っている間に後続して受信されるパケットのハンドオフを立ち往生させる。再送信後に単一のパケットを受信することができ、該パケットが穴を満たすことになり、幾つかのパケットが後続して受信された時点で１つのグループのパケットをハンドオフのために直ちに利用可能になる。このことは、ハンドオフ待ちのパケットのバックログを生み出す可能性があり、ハンドオフレーテンシーが発生することがある。ハンドオフ決定をハンドオフエンジン処理から分離することは、ハンドオフ決定ブロックがライン速度で動作するのを可能にし、その一方で、パケットのバックオフがハンドオフに関して処理される。ハンドオフエンジンは、自主的に動作することができ、ハンドオフメモリへのインタフェースは受信速度と比較して高速であると仮定した場合は、ハンドオフエンジンが追いつくことができる。この方法により、パケットバックログは、受信機の全体的スループットを制限しない。
【０２００】
他の側面においては、ハンドオフ決定と処理を分離することは、フローハンドオフ優先順位設定を考慮するものである。例えば、音声、映像又はその他の優先データ等の遅延の影響を受けやすい情報は、優先度がより低いデータとは異なる形で取り扱うことができる。
【０２０１】
図３４は、無線ネットワークに関するエンドツーエンド優先度方式を示し、入力ポリシング及び優先度に基づくハンドオフを含む。図３４においては、システム１００は、入力パケットを受信するための入力ポリシング機能３４１０を含む。上記において詳述されるように、様々な入力ポリシング機能は、着信する出力パケットの優先順位設定を考慮する。無線通信ＬＡＮ１２０は、入力ポリシングブロック３４１０を優先度に基づくハンドオフブロック３４２０と結合させる。（当業においてよく知られる）ＱｏＳＷＬＡＮは、識別されたパケット及び／又はフローがその他の型のパケット又はフローよりも優先されることを考慮する。しかしながら、先行技術であるＱｏＳ処理は、ＷＬＡＮ１２０における受信機及び送信機からのポイントツーポイント通信のみにおいて生じる。優先度に基づくハンドオフブロック３４２０は、優先度を組み入れたハンドオフ決定を行う。この場合は、パケットは、おそらく優先度又はＱｏＳに従って既に送信されて受信されている。優先度に基づくハンドオフは、ＷＬＡＮ１２０等のＷＬＡＮにおけるＱｏＳ概念に加えるものである。従って、より高い優先度を有するパケットは、より低い優先度を有するパケットよりも早期に出力のためにハンドオフすることができる。
【０２０２】
この方法により、ＱｏＳは、送信機側における入力から全体を通じて受信機における受信後の出力に至るまで維持することができる。入力ポリシング３４１０は、入力側を通じてパケットの優先順位を設定することができ、ＱｏＳ  ＷＬＡＮ１２０において優先度を有する状態で送信され（ＱｏＳがサポートされる場合）、受信機においてハンドオフ遅延が存在する場合は、より高い優先度のパケットに第１の優先度を与えることができる。入力ポリシング及び優先度に基づくハンドオフのいずれも、ＱｏＳ  ＷＬＡＮを有する状態で又は有さない状態で展開できることに注目すること。従って、優先度に基づくハンドオフは、１つ以上のその他のＱｏＳ技術を有する方式において用いることができる。これらの側面は、ホストプロセッサに依存しないアプリケーションにおいても同様に望ましいことがある。例えば、より高い層のアプリケーションは、パケットがＭＡＣプロセッサに引き渡される順序を決定するための何らかの優先順位設定能力を有することができる。より多くのデバイス、例えばカメラ、デジタル音楽デバイス、及びその他、が無線接続に移行するのに従い、該デバイスは、限られたホスト処理を有する（又はまったく有さない）場合がある。従って、入力ポリシングは、効率的な多フローの送信及び受信を可能にするために有用に採用することができる。
【０２０３】
本明細書において詳述されるような入力ポリシング及び優先度に基づくハンドオフは、有利なことに、（すなわち、ノード、チャンク、及び待ち行列に関する連結リストを用いて）パケットの管理に関して連結リスト構造と結合させることができるが、所定の実施形態においては両方の結合は要求されない。特に、パケットが（入口を介して又は磁気を通じて）到着するに従ってパケットを動的に割り当てることは、高優先度パケット又はフローと低優先度パケット又はフローとの間において柔軟にメモリを割り当てることを可能にする。
【０２０４】
連結リスト構造は、より高い優先度のパケットにサービスを提供する必要があることが混雑レベルによって要求されるときにサービス順序を効率的に変更し、さらに混雑が収拾されたとき全パケットクラスにまったく同じ容易さでサービスを提供する柔軟性を考慮する。
【０２０５】
図３５は、ハンドオフ決定２８８０及びハンドオフエンジン２８９０の動作を例示する方法３５００の実施形態例を示す。３５１０において、ハンドオフ決定２８８０は、パケットが受信されていることを示すトリガーを受信する。実施形態例においては、書き込み完了信号は、一部分が書き込まれたパケットが偶発的にハンドオフされるのを回避するために、パケットがどの時点でパケットバッファ内に完全に書き込まれたかを示す。以下においてさらに詳細に説明されるように、ハンドオフ決定を行うために必要な情報が、ＲＸ  ＦＩＦＯ ２８７０からハンドオフ決定２８８０に引き渡される。
【０２０６】
３５２０において、ハンドオフ決定２８８０は、パケットをハンドオフに関して利用可能であるかどうかを決定する。一般的には、ハンドオフに関してパケットの優先順位を設定するためのあらゆる方法又は技術を用いることができる。一例においては、上述されるように、フローに割り当てられた優先度は、到着順だけでなく優先度にも従ったフローハンドオフに基づく順序の再設定を考慮する。優先順位設定は要求されないことに注目すること。フローは、パケットが利用可能になるのに応じて順にハンドオフすることができる。
【０２０７】
３５３０において、パケットがハンドオフのために利用可能である場合は、ハンドオフに関して利用可能な１つ以上のパケットと関連づけられたフローＩＤを示すためにハンドオフ待ち行列が更新される。３５４０において、ハンドオフエンジン２８９０は、利用可能なパケットを自主的にハンドオフし、ハンドオフ決定２８８０が次の受信されたパケットを待ってそのパケットに関するハンドオフ決定を行うのを可能にする。
【０２０８】
上述される一般的概念は、次の実施形態例によってより明確に理解することができる。次の例においては、ハンドオフ決定２８８０は、ハンドオフ決定を行い、ハンドオフ用のパケットと関連づけられた待ち行列を更新し、ハンドオフを自主的に処理するための指令をハンドオフエンジン２８９０に発行する。図２８において例示されるように、ハンドオフ決定２８８０は、ハンドオフを開始するためのフローＩＤ及び関連パラメータを引き渡す。実施形態例においては、ハンドオフに関して利用可能なパケット数を示すハンドオフカウント、これらのパケットと関連づけられたフローＩＤ、及びフロー型が、ハンドオフ決定２８８０からハンドオフエンジン２８９０に引き渡される。
【０２０９】
さらに、割り込み信号を採用することができる。このオプションの割り込みは、より高い優先度のパケットが受信されていて、ハンドオフ決定２８８０がより高い優先度のパケット及びそのフローを現在ハンドオフ中のパケットの先頭に移行させたいときに用いることができる。割り込み技術は、当業においてよく知られており、採用されるハンドオフ決定及びハンドオフエンジンの型に依存して、ポーリング型割り込み、ベクトル駆動割り込み、及びその他の様々な割り込みを含むことができる。当業者は、ハンドオフ決定ブロック２８８０及び／又はハンドオフエンジン２８９０の両方ともが状態マシン、ソフトウェア又はファームウェアのプロセス、一般的又は専用のプロセッサ、専用ハードウェア、又はそのあらゆる組合せを用いて採用できることを認識するであろう。この例においては、ハンドオフエンジン２８９０は、ハンドオフが実施されていることを示すハンドオフ完了信号を、ハンドオフされたパケット数とともに戻す。この実施形態例が以下においてさらに詳細に説明される。
【０２１０】
ハンドオフ決定ブロック２８８０とハンドオフエンジン２８９０との間でのタスクの分離が上記において概説されており、フロー優先順位設定及び潜在的ボトルネックの管理を含む利益の一部が説明されている。この実施形態例においては、ハンドオフ決定とハンドオフエンジンとの間における一般的インタフェースは、各フローに関するハンドオフカウントパラメータを維持することである。ハンドオフ決定ブロックは、基本的には、ハンドオフカウントを増やすことによってフローのハンドオフの必要性を示す。ハンドオフエンジンは、パケットのハンドオフを実施するのに従って、ハンドオフカウントを減らす。従って、このパラメータは、一般的には、所定のハンドオフエンジンを有するハンドオフ決定実施形態間において用いることができる。
【０２１１】
この技術は、ＦＩＦＯの代替使用と対照的であることに注目すること。ＦＩＦＯは、本明細書において詳述される様々な実施形態と関連してハンドオフに関して採用することも可能である。しかしながら、ハンドオフ待ちであるパケット数の可変性が高いことに起因して、一定の事情下においては、ＦＩＦＯは、かなり深くする必要がある。さらに、ＦＩＦＯの複雑さを増大させずに、優先度を受け入れるためにパケットの順序を再設定するのは困難であることにも注目すること。実施形態例においては、複数の優先度レベルの各々に関して先入れ先出し式待ち行列が維持される。実施形態例においては、４つの優先度がサポートされる。当業者は、あらゆる数の待ち行列及び／又は優先度をサポートできることを認識するであろう。
【０２１２】
代替実施形態においては、ハンドオフ決定ブロック２８８０は、ハンドオフ決定を行い、待ち行列の状態及び該待ち行列においてハンドオフ待ちのパケットを示すために１つ以上の待ち行列及び／又は状態テーブルに入れることができる。示されるように、ハンドオフ決定２８８０からの明示のトリガリングを要求せず、むしろ、ハンドオフに関していずれのパケットを利用可能であるかを決定するため及びこれらのパケットがハンドオフされる順序の優先順位を設定するために様々な待ち行列の状態及び状態テーブルを自主的にモニタリングするハンドオフエンジン２８９０を採用することができる。当業者は、これらの実施形態及びその他の代替実施形態を本明細書における教義の適用範囲内において容易に採用するであろう。この代替実施形態の詳細は省略される。
【０２１３】
図３６は、上述されるように、ハンドオフ決定ブロック２８８０において採用するのに適した、ハンドオフ決定を行うための方法３６００の実施形態例を示す。３６１０において、パケットが受信されたときに、３６２０に進んで受信されたパケットに関するフローを処理する。以下において一プロセス例がさらに詳細に説明される。一般的には、ブロック確認応答をサポート時に、パケットを処理することは、穴が充填されている（すなわち、より高いシーケンス番号の１つ以上のパケットが正確に受信されており、前シーケンス番号を有するパケットが再送信後に受信されるまでハンドオフを待っている）かどうかを決定することを含む。当然のことであるが、順に正確に受信されたパケットは、穴を充填せずにハンドオフに関して利用可能である（すなわち、ハンドオフを待っている後続番号のパケットが存在しない）。パケットを受信することは、１つ以上のパケットをハンドオフに関して利用可能であることをトリガーすることができ、又はパケット自体が、ハンドオフ準備の整った唯一のパケットであることができる。受信されたパケットが既存の穴を充填しない場合は、そのフローに関して利用可能なハンドオフが存在することができない。プロセスは、決定ブロック３６１０に戻る。
【０２１４】
この例においては、フローは、パケットプロセスブロック３６３０と待ち行列プロセスブロック３６３０との間で交互する（以下においてさらに詳細に説明される）。方法３６００は、ハンドオフ待ち行列の処理に関するプロセス及びパケットが着信時における受信ためのプロセスの２つの同時プロセスを示す。当業者は、該並行処理を実行するための非常に多くの技術を認識するであろう。実施形態例は、１つの例示であるにすぎない。
【０２１５】
図３７は、上述されるように、ブロック３６２０として採用するのに適した、受信パケット処理方法の実施形態例を示す。３７１０において、パケットが受信されている。そのパケットと関連づけられたフローが決定状態テーブルに記入されているかどうかを決定する。決定状態テーブル例が図４０に示される。図４０に示された決定状態テーブル例４０００においては、いずれかの１つの時点においてＮのサポートされるフローＩＤが存在する。実施形態例においては、最大で２５６のフローをサポートすることができる。決定状態テーブル４０００は、各フローＩＤに関して、一組のパラメータ４０１０を含む。実施形態例においては、決定状態テーブル４０００は、各フローＩＤに関して、決定オフセット４０１２と、ハンドオフカウント４０１４と、次ポインタフィールド４０１６と、待ち行列内ビット４０１８と、優先度フィールド４０２０と、を含む。
【０２１６】
図３７に戻り、３７１０において、決定状態テーブル４０００内にフローが存在しない場合は、３７１５に進んで決定状態テーブルにフローを追加する。フローが決定状態テーブル内に存在することが決定された場合は、３７２０に進み、パケットがハンドオフ用に利用可能であるかどうかを決定する。決定オフセットフィールド４０１２は、ハンドオフすることができるフロー内の次の可能なパケットを決定するために用いられる。この情報を維持するために様々な技術を用いることができる。例えば、ウィンドー内の各パケット及び／又はフラグメントに関する関連づけられたビットを有するビットマップを採用することができる。パケットが正確に受信されたときには、パケットの成功裏の受信を示すためにビットマップが更新される。従って、この例において、決定オフセットフィールドによって示される位置と関連づけられたパケットが（例えば１に）設定される場合は、パケットをハンドオフに関して利用可能である。ビットマップにおけるその位置がデアサートされる（すなわち、ゼロに設定される）場合は、穴が示され、このフロー（存在する場合）に関する後続するパケットのいずれもハンドオフに関して利用可能でない。
【０２１７】
この例においては、ハンドオフ決定プロセス３６００は、反復的な繰り返しを継続する。ハンドオフに関してパケットが利用可能である場合は、決定ブロック３７３０に進み、ハンドオフ待ち行列内にフローＩＤが含まれているかどうかを決定する。ハンドオフ待ち行列の一実施形態例は、図４１において例示されるＱアレイ状態テーブル４１００として示される。この例においては、待ち行列は、最大でＭの優先度に関して維持され、各々の待ち行列は、Ｑのアレイ状態テーブル４１００においてエントリ４１１０を有する。この例においては、エントリ４１１０は、Ｑカウント変数４１１２と、先頭ポインタ４１１４と、末尾ポインタ４１１６と、を含む。待ち行列は、連結リスト構造を用いて維持される。代替実施形態においては、その他の型の待ち行列を採用することができる。実施形態例においては、Ｍは４に設定され、従って４つの優先度レベルがサポートされる。フローに関する優先度レベルは、決定状態テーブル４０００の優先度フィールド４０２０から決定することができる。待ち行列内ビット４０１８は、Ｑアレイ状態テーブル内にフローが挿入されているかどうかを決定するために用いることができる。代替実施形態においては、ハンドオフカウント４０１４は、所定のフローがハンドオフ待ちのパケットを既に有しているかどうか又は待ち行列に追加する必要があるかどうかを決定論理が決定するのを援助するために用いることができる。ハンドオフカウントは、ゼロ以外であることができるが、既にゼロ以外であったかどうか又はゼロ以外になったばかりであるかどうかは不明なことがある。この例においては、パケットは、１度に１つずつ処理中であることができる。様々な実施形態においては、このビットは必要ない場合があり又は便宜上用いることができる。
【０２１８】
フローＩＤがハンドオフ待ち行列内にない場合は、３７３５に進み、フローを追加する。図４１に示されるように、各優先待ち行列に関して、先頭ポインタ４１１４及び末尾ポインタ４１１６が維持される。先頭ポインタ４１１４は、待ち行列内における最初のフローを決定するためにインデキシングして決定状態テーブル４０００に入れるために用いることができるフローＩＤを含む。この例においては、優先度内において、先入れ先出し方式でフローがサービングされる。従って、先頭ポインタ４１１４は、待ち行列内においてサービングされる最初のフローに関するフローＩＤへのインデックスである。先頭ポインタ４１１４によって示されるフローＩＤにアクセスされた時点で、その待ち行列内の次のフロー（存在する場合）が次ポインタフィールド４０１６によって示されることに注目すること。Ｑアレイ状態テーブル４１００内の末尾ポインタ４１１６は、優先待ち行列内の最後のフローを示す。新しいフローをハンドオフ待ち行列に追加時には、プロセスは、末尾ポインタ４１１６によって識別されたフローＩＤに関する次ポインタフィールドを更新することによって実行することができる。このフィールドは、追加中のフローを指し示すポインタによって置き換えられる。引き続き、新しく到着したフローを指し示すように末尾ポインタフィールド４１１６が更新され、新しく到着したフローが待ち行列の新しい末尾（すなわち、ライン上の最後）になる。さらに、待ち行列カウントフィールド４１１２は、優先待ち行列内の総フロー数を維持する。従って、優先度レベルに関する待ち行列カウント値を読み取ることによって、ハンドオフ待ち状態であるその優先度のパケットが存在するかどうかを素早く決定することができる。この手順に従ってＭの優先待ち行列の各々に関する待ち行列が維持され、Ｑアレイ状態テーブル４１００において容易に状態が維持される。
【０２１９】
フローがハンドオフ待ち行列内にある又は既に追加されていることが決定された時点で、３７４０進んでハンドオフカウント４０１４を増やす。ハンドオフカウントは、特定のフローに関するハンドオフを待っているパケット数を決定するために用いられるパラメータであり、決定状態テーブル４０００において維持されることを思い出すこと。３７５０において、フローに関してハンドオフすべき追加パケットが存在するかどうかを決定する。第１のパケットがハンドオフ準備が整っていると決定され、ハンドオフカウントが増やされているときに、決定オフセットは、ビットマップ内において前方に移動することができる（すなわち、決定オフセット＋＋）。更新された決定オフセットもハンドオフに関して利用可能なパケットを示す場合は、３７４０に戻り、ハンドオフカウントを増やし、ウィンドー内の全パケットが試験済みになるか又は穴に到達するまでプロセスを継続する。これで、決定オフセットが次の穴を指し示すことに注目すること。方法３６２０の後続する繰り返しにおいて、各フローは、そのフローに関するパケットが到着するのに応じて利用可能なハンドオフパケットの有無を確認するための試験が行われる。
【０２２０】
穴に到達し、ハンドオフすべき追加パケットがなくなった時点で、３７６０に進む。決定ブロック３７６０は、採用可能な割り込み手順のオプション例を示す。当業者は、あらゆる数の割り込み手順を容易に採用するであろう。３７６０において、ハンドオフが現在進行中であるかどうかを決定する。ハンドオフが進行中でない場合は、プロセスは停止することができる。ハンドオフが進行中である場合で、このオプションの優先順位再設定が採用される場合は、３７７０に進む。３７７０において、新しく到着中のパケットのフローがより高い優先度を有しており、現在ハンドオフ中のあらゆるパケットの前に移動すべきであるかどうかを決定することができる。ハンドオフエンジン２８９０によって現在処理中のフローの優先度を用いて現在のフローの優先度を試験する。現在のフローの優先度が処理中のフローの優先度よりも高い場合は、３７７５に進み、割り込みフラグを設定する。この例においては、割り込みフラグは、上のブロック３６３０において識別され、以下においてさらに詳細に説明されるハンドオフ待ち行列処理中に認識される。現在のフローの優先度がハンドオフエンジン２８９０によって現在処理中のフローの優先度よりも低い場合は、プリエンプションする必要がなく、プロセスは停止することができる。
【０２２１】
図３８は、上記において例示されるブロック３６３０として採用するのに適した、１つ以上のハンドオフ待ち行列を処理するための方法の実施形態例を示す。プロセスは、決定ブロック３８１０において開始する。ハンドオフエンジン２８９０によって処理されたハンドオフが現在進行中である（すなわち、方法３６３０の前回の繰り返しが該ハンドオフを開始させた）場合は、決定３８１５に進み、そのハンドオフが完了しているかどうかを決定する。そのハンドオフが完了している場合は、３８２０において、ハンドオフカウントを更新する。実施形態例においては、ハンドオフされたパケット数がハンドオフエンジン２８９０によって戻され、ハンドオフカウントから減じることができる。図２８に示されるハンドオフ完了信号は、ハンドオフが完了しているかどうかを決定するために用いることができる。ハンドオフカウントがゼロになった時点で、図４１に示されるフィールドを用いて、フローＩＤを各々の優先待ち行列から取り除くことができる。さらに、フローが待ち行列から取り除かれたときに、各々のＱカウントも減らされる。３８２５において、ハンドオフを実施中であるかどうかを決定するために用いられる待機フラグがリセットされる。このフラグは、決定ブロック３８１０においてハンドオフが未完了状態であるかどうかを決定するのに有用であり、さらに、上述されるように決定ブロック３７６０においてパケット処理に関して用いることもできる。
【０２２２】
決定ブロック３８１５における決定により、ハンドオフが完了しておらず、さらに上述されるように割り込み機能が採用される場合は、決定ブロック３８３０に進んで割り込みフラグが設定されているかどうかを決定する。例えば、該フラグは、上述されるブロック３７７５において説明されるように設定することができる。割り込みフラグが設定されていない場合は、プロセスは停止することができる。ハンドオフエンジン２８９０は、現在のハンドオフ動作を継続することができ、図３６のプロセスの流れは、決定ブロック３６１０に戻って追加パケットの受信又はハンドオフ待ち行列処理状態の変化を待つことができる。決定ブロック３８３０において、割り込みフラグが設定されている場合は、ブロック３８３５においてハンドオフエンジンへの割り込みをアサートする。ハンドオフエンジンによる割り込み信号の処理の一実施形態例が以下においてさらに詳細に説明される。
【０２２３】
決定ブロック３８４０において、ハンドオフエンジンがすべての以前の処理を完了しており、追加ハンドオフ命令を生成することができる。決定ブロック３８４０において、ハンドオフ待ち行列内においてハンドオフに関するフローが利用可能であるかどうかを決定する。一実施形態が以下においてさらに詳細に説明される。利用可能でない場合は、プロセスは停止して上述されるとおりに繰り返すことができる。フローが利用可能である場合は、３８４５において、ハンドオフエンジンへのハンドオフを開始する。上述されるように、フローＩＤ及び関連パラメータをハンドオフエンジンに引き渡すことができる。実施形態例においては、ハンドオフカウントはあらゆる数であることができる。ハンドオフカウントが１よりも多い場合は、ハンドオフエンジンは、割り込みがある場合を除き、終了するまで各パケットをハンドオフすることができる。代替実施形態においては、ハンドオフエンジンは、ハンドオフが開始されるごとに１つのパケットを処理することができる。この代替実施形態においては、割り込みが不要であることができる。３８５０において、待機フラグは、ハンドオフプロセスが未完状態であることを示すように設定される。これで、プロセスの現在の繰り返しが停止することができる。
【０２２４】
図３９は、上述されるブロック３８４０として採用するのに適する、ハンドオフに関して利用可能なフローを決定する方法の一実施形態例を示す。この例は、より高い優先度のフローにより小さい優先度値が割り当てられると仮定することに注目すること。従って、優先度０が最高の優先度である。当業者は、本明細書における教義の適用範囲内においてあらゆる優先度方式を容易に適合化するであろう。３９１０において、優先度インデックスを０に設定する。この優先度は、最初に試験すべき最高優先度である。決定ブロック３９２０において、優先度インデックスによって識別される待ち行列内にフローが存在する（すなわち、Ｑカウントが０よりも大きい）場合は、方法３８４０から出てフローを戻す。繰り返すと、実施形態例においては、識別された優先度を有する（先頭ポインタによって識別される）待ち行列内の第１のフローがハンドオフされる。
【０２２５】
識別された優先待ち行列にいずれのフローも入っていない場合は、３９３０において優先度を高くする。３９４０において、優先度インデックスがサポートされる優先度数であるＮ（実施形態例においてはＮ＝４）よりも大きい場合は、試験すべき追加待ち行列は存在しない。この場合は、全待ち行列が空である。試験すべき追加待ち行列が存在する（すなわち、優先度インデックスがＮよりも小さい）場合は、戻って３９２０において次の待ち行列を試験する。プロセスは、フローが見つかるか又は待ち行列が空になるまで継続する。
【０２２６】
繰り返しになるが、あらゆる型のフロー選択技術を方法３８４０の代わりに用いることができる。
【０２２７】
図４２は、ハンドオフエンジン２８９０内において採用するのに適する、ハンドオフを実行するための方法４２００の実施形態例を示す。この実施形態例においては、ハンドオフ決定ブロック２８８０は、ハンドオフするためのパケット数、ハンドオフカウント、フロー型（例えば８０２．１１（ｂ）、（ｇ）、（ｎ）、等のように複数のパケット型に関するサポートが採用される場合に用いることができる）、及び割り込みをハンドオフエンジン２８９０に引き渡す。ハンドオフエンジンは、出力のためのパケットを引き渡し、これらのパケットは、図２８に関して上述されるように、メモリアービター６８０を介してパケットバッファからフェッチされる。上述されるように、ハンドオフされたパケット数は、ハンドオフ完了信号とともに、処理のために決定２８８０に戻される。
【０２２８】
４２１０において、ハンドオフエンジン２８９０は、１つ以上のノードを、最大でハンドオフカウントによって示される数だけ、パケットバッファから取り出す。ノードは、パケットバッファ内において、フローＩＤに対応して設定されるウィンドーポインタ及びハンドオフオフセットによって識別される格納場所に配置される。受信パケットバッファ例は、図３３において例示されるとおりであり、ノードアレイ３３３０は、ノード３３１０を具備し、各々は、パケットに対応し、アレイフォーマットにおいてリンクされ、関連づけられたパケットデータが入ったチャンクの連結リストを有することを思い出すこと。パケットバッファをインデキシングするために用いられる変数は、図４３に示されるハンドオフ状態テーブル４３００内においてハンドオフエンジンに関して維持される。繰り返すと、ＮのフローＩＤがサポートされ、各フローＩＤに関して、エントリ４３１０がハンドオフ状態テーブル４３００において維持される。実施形態例においては、最大で２５６のフローがサポートされる。ファームウェアは、各フローに関するパケットバッファ内においてノードアレイ格納場所を維持する。このノードアレイ格納場所は、ハンドオフ状態テーブル４３００においてｗｉｎ（ウィン）ポインタによって識別される。フローに関するウィンドーのサイズは、ｗｉｎサイズ４３１６によって示される。ハンドオフオフセット４３１２は、ハンドオフすべき次のパケットが見つかるかどうかを決定するためにハンドオフエンジンによって状態が維持される。従って、上述されるように、ハンドオフ用のパケットに対応するノードは、ハンドオフオフセット４３１２をｗｉｎポインタ４３１４に追加することによって識別される。より効率的なＳＤＲＡＭアクセスを行うためには、１度に２つ以上のノードを取り出すことが望ましいが、必須ではない。
【０２２９】
ｗｉｎサイズ４３１６を開始シーケンス番号及びハンドオフオフセットとともに用いて、ハンドオフ用に処理する必要があるパケットにハンドオフエンジンを位置決めすることができる。この例においては、ハンドオフオフセットは、ウィンドーデータ構造（すなわち、ノードアレイ）内の開始シーケンス番号を指し示し、ハンドオフされるべきシーケンス番号は、開始シーケンス番号に関して識別される。
【０２３０】
４２１５において、ハンドオフオフセット４３１２に対応する第１のノードを選択する。４２２０において、そのノードに対応するチャンクをパケットバッファから取り出す。４２２５において、必要な場合は、フロー型に基づいてパケットをデフラグメンテーションする。このことは、幾つかのフラグメントをパケットバッファから取り出すことと、フラグメントヘッダーを各フラグメントから取り除くことと、チャンクをコンパクトにして単一のパケットにすることと、適切なヘッダーを生成すること、とを含むことができる。このことは、図２８に示される関連するデフラグブロック２８９２において行うことができる。フロー型は、フラグメンテーションが必要なときを示すために用いることができる。例えば、幾つかの実施形態においては、８０２．１１（ｅ）及び（ｇ）パケットをサポートすることができ、フラグメンテーションを用いることができる。以下においてさらに詳細に説明される代替実施形態においては、複雑さを軽減するために、フラグメンテーションを要するパケット型がファームウェアにおいて処理される。該実施形態においては、デフラグロック２８９２は採用する必要がない。
【０２３１】
４２３０において、パケットと関連づけられたチャンクの各々が取り出され、パケットが再構築され（要求されるデフラグメンテーションを含む）、該パケットが出力のために引き渡される。上述されるように、出力は、様々なインタフェースのうちのいずれかを通じて行うことができ、その例が上記において示される
パケット（又は一組のフラグメント）がハンドオフされた時点で、ハンドオフ用の次のパケットを識別するためにハンドオフオフセット４３１２が更新される。４２４０において、ハンドオフされたパケット数を追跡するための変数＃ｈａｎｄｅｄ  ｏｆｆが適宜増やされる。４２４５において、割り込みがサポートされる場合で、割り込みが発行されている場合は、４２５５に進む。４２５５において、ハンドオフが停止し、ハンドオフ完了がアサートされ、ハンドオフされたパケット数が戻される。この実施形態においては、割り込みは、各パケットが完全にハンドオフされた後に作動される。代替の割り込み方式を採用することができ、当業者にとって明確になるであろう。割り込まれた時点で、ハンドオフプロセスが停止する。この例においては、ハンドオフ決定ブロック２８８０は、のちに、割り込まれたフローに関するパケットのハンドオフを継続するために新しいハンドオフコマンドをハンドオフエンジン２８９０に発行することができる。４２４５において、割り込みが受信されなかった場合は、決定ブロック４２５０に進む。４２５０において、ハンドオフすべき追加パケットが存在しない場合は、ハンドオフが完了しており、ハンドオフすべき追加パケットが存在しないことは、ハンドオフされたパケット数をハンドオフカウントと比較することによって決定することができる。４２５５に進み、ハンドオフ完了をアサートし、ハンドオフされたパケット数を戻す。
【０２３２】
ハンドオフすべき追加パケットが存在する場合は、４２６０に進む。次のノードを処理し、４２２０に戻り、そのノードに対応するチャンクを取り出し、直前において説明されたプロセスを再開する。
【０２３３】
図２８に示されるように、フラッシュブロック２８９４がハンドオフエンジン２８９０に接続される。フラッシュブロック２８９４は、最終的にパケットをフラッシング（ｆｕｓｈｉｎｇ）するために用いることができる再送信限度、時間切れ、等を追跡するために用いることができる。このことは、穴が充填される前にハンドオフエンジンが進行することを可能にする。次にハンドオフが生じ、必要な場合は、パケットの送信及び後続する再送信は、より高い層を通じて処理される。
【０２３４】
フラッシュブロック２８９４は、ＡＲＱウィンドーが移動されたときに様々な機能を実行する。例えば、部分的にフラグメンテーションされたパケットがフラッシングされる。完成されたパケットは、穴が存在するかどうかにかかわらずハンドオフされる。バッファが解放され、従ってチャンクポインタがフリーチャンクポインタリストに戻されてウィンドーが移動される。
【０２３５】
当業者は、代替実施形態において様々な回路、構成要素及び技術を容易に適合化するであろう。１つの一般化された（後述される、図４９に示される代替実施形態４９００と適合可能な）実施形態の例においては、入力状態マシン（ＩＳＭ）は、着信パケットを処理し、制御状態マシン（ＣＳＭ）によって用いられた情報を更新する。これらの更新は、メモリ内のパケット数を増加させ、さらにＦｌｏｗ＿ＩＤをＣＳＭによって処理する必要がある順序を更新することもできる。ＣＳＭは、上述されるように、送信機内の４パケットノードキャッシュを更新することができる。この状態マシンは、Ｆｌｏｗ＿Ｐａｃｋｅｔ＿Ｔａｂｌｅ内の情報に基づいて動作する。テーブル内の先頭ポインタと末尾ポインタ及び次フローポインタは、ＣＳＭが処理すべき次のＦｌｏｗ＿ＩＤを選択するのを可能にする。（Ｆｌｏｗ＿ＩＤごとに）このＦｌｏｗ＿ＩＤからのパケットが現在送信中であるかどうかをＣＳＭに知らせるサービス中ビットがテーブル内に存在することができる。このビットは、送信開始前にＴｘエンジンによって１に設定することができ、送信が完了後に０に設定される。送信状態マシンは、コマンド待ち行列からの情報を用いて（図１８に関して上述されるのと類似の）ＷＬＡＮにおいてパケットを送出する。フラッシュ状態マシン（ＦＳＭ）は、フラッシュブロック２８９４として用いることができ、各々の受信機によって正確に受信されて確認応答されたＳＤＲＡＭパケットからフラッシングする。次に、ＦＳＭは、Ｆｌｏｗ＿Ｐａｃｋｅｔ＿Ｔａｂｌｅにおいてメモリカウント内のパケットを減らす。
【０２３６】
Ｆｌｏｗ＿Ｐａｃｋｅｔ＿Ｔａｂｌｅは、次のエントリ、すなわち、Ｆｌｏｗ＿ＩＤ（１バイト）、メモリ内のパケット数（２バイト）、キャッシュ内パケット（２ビット）、サービス中ビット（１ビット）、Ｎｅｘｔ＿ｆｌｏｗ＿ＩＤ（１バイト）、及び２ビットの優先度フィールドのうちの１つ以上を有することができる。パケットが入口に着信すると、ＩＳＭは、メモリ内のパケットを更新し、Ｎｅｘｔ＿Ｆｌｏｗ＿ＩＤ及びＴａｉｌ＿Ｐｏｉｎｔｅｒを更新する。送信状態マシンは、特定のＦｌｏｗ＿ＩＤからパケットを送信中であるときには、対応するサービス中ビットを設定する。対応するするサービス中ビットが設定されているときには、ＣＳＭは、４パケットノードキャッシュを更新しない。パケットが送信された後は、Ｔｘ状態マシンは、キャッシュ内のパケット数を更新し、さらにサービス中ビットをリセットする。ＣＳＭは、サービス中ビットがリセットされているときのみに動作する。ＣＳＭがＦｌｏｗ＿ＩＤを処理する順序は、Ｎｅｘｔ＿Ｆｌｏｗ＿ＩＤによって決定される。希望される場合は、２ビット優先度ビットをテーブルに追加することができる。この場合は、ＣＳＭは、最初に最高の優先度に属するフローを処理し、次に、２番目に最高の優先度に属するフローを処理し、以下同様である。このテーブルのサイズ例はフロー数のほぼ４バイト倍であり、２５６のフローに関しては約１キロバイトである。ＣＳＭは、Ｆｌｏｗ＿ＩＤ（Ｌｉｎｋｅｄ＿ｌｉｓｔ内の最初のパケット）のヘッダーポインタを用いて、４パケットノードキャッシュ内に含める必要があるパケットのノードアドレスを推定する。
【０２３７】
以上のように、一実施形態例においては、フラッシュエンジン例又はフラッシュブロック２８９４は、成功裏に受信されて確認応答された全パケットをパケットバッファから取り除くことができる。ブロック確認応答ビットマップが受信されたときに、Ｔｘ状態マシンは、最初にそのビットマップを処理し、一定の非確認応答パケットに対処するための即時再送信を行うことができる。（以下においてブロック確認応答がさらに詳細に説明される。）次に、ビットマップは、フラッシュエンジン内のフラッシュエンジン状態マシン又はフラッシュブロック２８９４に渡され、対応するＦｌｏｗ＿ＩＤに関する連結リストデータ構造のＨｅａｄ＿Ｐｏｉｎｔｅｒを取り出す−Ｈｅａｄ＿Ｐｔｒがフロー状態ＲＡＭにおいて利用可能である。Ｈｅａｄ＿Ｐｔｒは、所定のＦｌｏｗ＿ＩＤに関する最初のパケットのノードアドレス及びこのパケットのシーケンス番号を含む。フラッシュエンジン状態マシンは、ビットマップを処理し、順に確認応答されているパケットをフラッシングするために待ち行列に入れる。この論理は、出力状態マシンによって用いられる論理と同様であることができ、順に受信されたパケットがホストに渡される。フラッシュエンジン状態マシンがフラッシングすべきパケット数及びそのシーケンス番号を識別した時点で、フラッシングのための待ち行列に入れることができる。Ｈｅａｄ＿Ｐｔｒは、連結リスト内の最初のパケットのノードアドレスを生み出す。フラッシングすべきパケットのノードアドレスは、連結リストからの対応するパケットのノードアドレスにアクセスすることによって入手される。実施形態例においては、十分なパケット格納場所、チャンク、及びノードを提供するためのメモリが割り当てられる。従って、一般的にはこのタスクに関する厳しい時間上の要求は存在しないため、フラッシングはバックグラウンドで行うことができる。メモリアービターは、優先度が低いタスクとしてのフラッシング機能に関するアクセスを提供することができる。
【０２３８】
ブロック確認応答
上記において詳述される実施形態例によって示される様々な側面は、高速メディアアクセス制御に関するブロック確認応答を実行するのに非常に適する。典型的なブロック確認応答プロトコルにおいては、送信機は、パケットの確認応答を必ずしも受け取らずにある期間にわたって受信機にパケットを送信する。次に、以前に送信されたパケットのうちのいずれのパケットが正確に受信されたかを示すブロック確認応答が受信機から送信機に戻される。ブロック確認応答は、ブロックａｃｋ要求に応じて送信することができ、又は代替のスケジューリングメカニズム、例えば予め決められた数のパケットが受信された後に応答する、を採用することができる。ブロック確認応答要求は、ブロック確認応答が希望されることを示すために送信された特定のメッセージであることができ、又はブロック確認応答は、他の型の信号又はメッセージにおける固有の確認応答であることができる。
【０２３９】
図３０及び３１に関して上述されるように、確認応答された又は確認応答されないパケットの状態を維持するための一メカニズムは、各ビット位置がパケット又はパケットフラグメントに対応するビットマップを保持することである。ビットマップ例３１３０は、既に上述されている。
【０２４０】
高スループットシステムにおいては、トリガーイベントに引き続く相対的に短時間にブロックＡＣＫ要求、例えば明示の又は固有のブロックＡＣＫ要求、又はその他のブロックＡＣＫ要求インジケータ、を戻すことが望ましい場合がある。８０２．１１の一実施形態例においては、ブロックＡＣＫ要求（すなわち、即時ブロックＡＣＫ）に引き続くＳＩＦＳ期間内にブロックＡＣＫ要求を戻すことが要求される場合がある。従って、複数のフローに関する状態情報を維持し、現在の未完了状態のフローのうちのいずれかに関する、及び再送信を必要とするパケットを再送信するためのブロックａｃｋ要求に引き続くブロック確認応答を処理することに関する即座のブロックＡＣＫ応答を可能にすることが望ましい。幾つかの型のブロック確認応答をサポートすることができる。例えば、部分的又は全体的状態確認応答を希望することができる。一般的には、部分的状態確認応答のほうが計算上の集約度が低いか又は要求される遅延がより短い。本明細書において説明される実施形態例は、部分的又は全体的状態ブロック確認応答、又はその組合せに関して容易に適合化することができる。以下では、実施形態例を用いて諸側面がさらに説明される。
【０２４１】
受信機におけるブロックＡＣＫ
一実施形態例においては、パケットが受信され、該パケットは、統合パケットであることができる。受信機においてパケットが受信されるのに応じて、パケットが正確に受信されているかどうかを決定するために試験され、例えばフレーム検査シーケンス等を用いることができる。パケットの正確な受信を決定する方法にかかわらず、各パケット（又は、該当する場合はフラグメント）に関するインジケータを格納することができる。実施形態例においては、これらの確認応答インジケータは、各フローに関して関連づけられたビットマップ内に格納される。フローに関するビットマップを格納するための様々な技術が上記において図３０に関して詳細に説明される。
【０２４２】
図４４は、即時ブロックａｃｋ要求に応答するための方法４４０の一実施形態例である。この方法は、ブロックａｃｋ要求に即座に応答するのに適する。
【０２４３】
４４１０において、ブロックＡＣＫを生成することが必要になるあらゆるフローに関してパケットヘッダー情報が維持される。このヘッダー情報は、あらゆるフォーマットで維持することができ、その例は当業者においてよく知られる。ヘッダー情報（又は、代替実施形態においては、ブロック確認応答を準備する際に用いるために予め決定することができるいずれかの情報）が、潜在的なブロックＡＣＫ送信前にパケットを構築するために格納される。換言すると、パケットは、（事前に確定することができる）送信のためのすべての値を用いて適切にフォーマット化された、何らかの形態のメモリ内にある。存在していないものは、個々のパケット又はフラグメントの実際の確認応答又は非確認応答を示すビットマップ情報（及びそれよりも前に確定することができないその他の情報）である。ビットマップ（及びあらゆる残りの情報）は、待機中のパケット内に単に挿入されて送信される。
【０２４４】
上述される実施形態例においては、様々なレベルのインダイレクションに備えて３つのレベルのメモリを採用できることを思い出すこと。一例においては、第１のレベルのメモリは、ハードウェアテーブル、例えばハードウェアテーブル２８２０、である。第２のレベルのメモリは、ＳＲＡＭ３３０を含むことができる。オプションの構成においては、ＳＤＲＡＭ３４０等の第３のレベルを採用することができる。パケットヘッダー情報は、適切なアクセス先であるとみなされあらゆるメモリ層内に格納することができる。
【０２４５】
４４２０において、暗黙又は明示であることができるブロックａｃｋ要求が受信される。４４３０において、フローと関連づけられたビットマップが取り出される。ビットマップを取り出すためにあらゆるフロー識別子を用いることができる。例えば、図３０において上述されるように、関連づけられたポインタ３００２を有するリンクＩＤ３００６を識別するためにＭＡＣインデックス３００４が用いられる。ポインタ３００２は、ビットマップ３０４６を直接含むテーブル３０４２を直接指し示すことができ、又はポインタ３００２は、送信ＩＤ３０２０に基づいてＲＸ状態テーブル２９２０を指し示すレートテーブル３０１０を指し示すことができる。上述されるように、状態テーブル２９２０は、実際のビットマップ３１３０を指し示すビットマップポインタ３０５０を含むことができる。当業者は、あらゆる型のインダイレクション又はビットマップの直接格納を採用できることを認識するであろう。用いられる技術により、ブロックａｃｋ要求を有するフローＩＤと関連づけられた適切なビットマップが取り出される。
【０２４６】
４４４０において、取り出されたビットマップは、維持されるパケット内に入れられ、４４５０において、今構築されたブロックＡＣＫが送信される。このように、この実施形態においては、ブロックａｃｋパケットのうちの可能な限り多くの部分が予め構築される。ビットマップ情報、又は代替実施形態におけるその他の確認応答データは、即座の取り出しのために容易にアクセス可能なメモリ部分において維持される。次に、即時ブロックａｃｋ要求に応じて部分的又は全体的状態即時ブロックａｃｋを提供するためにこれらの２つの組合せが即座に送信される。
【０２４７】
上記の実施形態は、即時の全体的状態ブロック確認応答又は部分的状態ブロック確認応答をサポートする。一実施形態例においては、部分的状態、完全状態、又はあらゆる組合せに関するサポートを採用することができる。しかしながら、その他の実施形態は、８０２．１１（ｎ）に関する基準になることが見込まれるように、部分的状態ブロック確認応答をサポートすることだけが必要になると思われる。この場合は、受信された統合パケットのみに応じてブロック確認応答が送信され、受信されたパケットのみに関する状態を送信する。
【０２４８】
部分的状態ブロックＡＣＫに関しては、単一のメモリのみを受信機において維持する必要がある。完全な状態（すなわち、２５６のフローに関するメモリ）を含める必要はない。受信機において維持される部分的ビットマップ状態は、異なる送信元からの送信が受信された場合にオーバーライトすることができる。状態が誤ってオーバーライトされた場合は、のちのブロック確認応答要求は可能でないことに注目すること。一例においては、この場合はすべてがゼロのビットマップを送信することができる。希望される場合は、最低量よりも多い状態量を維持するための所定の実施形態を採用することができる。
【０２４９】
送信機におけるブロックＡＣＫ
上述されるように、送信機は、幾つかのパケットを送信し、その後に明示又は暗黙のブロック確認応答要求を介して受信状態を要求することができる。高いスループットを維持するために、対応するブロック確認応答が受信されたときに送信機が送信を継続するか又は必要に応じて即座に再送信する準備を整えておくことが望ましい。様々な実施形態は、ブロック確認応答に応じた効率的で即座の再送信を可能にするために本明細書において詳述される様々な側面を利用するように容易に適合化可能である。
【０２５０】
図４５は、ブロック確認応答に応答するための方法４５００の実施形態例を示す。この方法は、上記において詳述されるノードアレイキャッシュ１８１０に格納されるようなノードアレイを採用する実施形態に関して非常に適する。さらに、上述される待ち行列は、連結ノードリストによって変更及び維持することができ、方法４５００に合わせて適合化するのにも非常に適する。
【０２５１】
手順を要約すると、ブロック確認応答は、ウィンドーサイズ（実施形態例においては最大サイズは６４）に対応することを思い出すこと。開始シーケンス番号は、ウィンドー（概念的にはウィンドーの左端点）によって表される最低のシーケンス番号に設定される。送信機は、どれだけの数のパケットが送信されているかを知っており、従って、最後のパケットがウィンドー内のどの場所に存在するかを知っている。送信機は、最後に送信されたパケットから開始し、ビットマップ全体にわたってパケットごとに、直近に送信されたパケットから最も初期に送信されたパケットまで進むことができる。非確認応答（実施形態例においてはゼロ）が識別された場合は、そのパケットに関するノードポインタが（パケットを再送信するために再度待ち行列に入れる）送信待ち行列に再リンクされる。送信機は、ビットマップ全体にわたって進み、（前開始シーケンスによって識別される）ビットマップの始めに達するまで連結リスト送信待ち行列を再構築する。方法４５００は、採用可能な１つの該技術であるが、要求される再送信パラメータを決定するためのあらゆる技術を本明細書において詳述される実施形態と関連して用いることができる。
【０２５２】
以下の例は、ブロックＡＣＫビットマップを用いてパケットバッファ内の送信待ち行列を処理することを例示するものである。ブロックＡＣＫに応じて低レーテンシー再送信を提供することにも同じ又は同様の技術を等しく適用可能である。例えば、待ち行列、例えばノードアレイ１８４２は、上述されるように、フローのノードをローディングすることができ、次に該ノードが送信される。これらのノードは、ブロックＡＣＫが受信されて処理されるまでとどまることができる。ブロックＡＣＫビットマップは、いずれのノードを再送信する必要があるかを示すために用いることができる。一実施形態においては、ノードアレイ内におけるノードの位置は、ブロックＡＣＫビットフィールド内における位置と対応することになる。ブロックＡＣＫが受信された時点で、（送信機会が利用可能であると仮定した場合に）上記において詳述される統合技術を用いて確認応答されなかったパケットを即座に統合して再送信することができる。この技術は、残りの送信機会を効率的に利用することを可能にする低レーテンシー応答技術の一例である。ノードアレイ内のノードは、後述されるのと同様の方法で、ウィンドーが移動するのに応じて移動させることができる。ブロックＡＣＫ処理及び再送信に関してノードアレイ又は送信バッファを用いるかどうかにかかわらず、上記において詳述されるノード及びチャンク等のデータ構造を用いてパケットバッファ内にパケットが格納されるときには、パケットバッファ内のパケットデータを移動させる必要がまったくない。パケットデータは、パケットが成功裏に受信されるか又は予め決められた限度を超えてフラッシングされるまでは最初の送信及び後続する再送信を通じて１つの場所にとどまることができる（ただし、各送信中に再アクセスすることができる）。
【０２５３】
４５１０において、ブロック確認応答が受信される。４５１５において、開始シーケンス番号が最初の送信されないパケットを指し示すように設定される。従って、送信された全パケットが正確に受信されたことを示すブロックＡＣＫが受信される例においては、ウィンドーが移動される。次に送信されるパケットは、新しいウィンドー内の最初のパケットであり、従って、開始シーケンス番号は、そのパケットと関連づけられるべきである。以下のステップは、必要な再送信が必要である場合にこれらの再送信を受け入れるために、開始シーケンス番号を修正する方法及び送信待ち行列を更新する方法について詳述する。プロセスが終了された時点では、開始シーケンス番号が適切な位置に自動的に更新されてウィンドーを前方に移動させていることになる。送信及び再送信が直ちに開始することを考慮して、送信待ち行列が更新される。
【０２５４】
４５２０において、直近に送信されたパケットから初めてブロックＡＣＫビットマップを検討する。４５２５においてゼロが検出された（又は代替実施形態においては非確認応答インジケータが検出された）場合は、そのパケットを再送信する必要がある。４５３０に進み、次の送信に関するポインタをそのビットマップ位置と関連づけられたパケットにリンクする。例えば、図６に関して上述されるように送信待ち行列が採用されたときには、ゼロが検出されたパケットと関連づけられたノードを指し示すように待ち行列先頭ポインタ６３０に指示することができる。次に、そのノードに含まれている次ノードポインタフィールド６１２を、前先頭ポインタを指し示すように更新することができる。代替実施形態においては、送信待ち行列を更新するために代替技術を用いることができる。
【０２５５】
４５３５において、開始シーケンス番号が現在のパケットを指し示すように更新される。従って、受信された各ゼロに関して、開始シーケンス番号が前の格納場所に移動される。上述されるように、全パケットが正確に受信された場合は、ウィンドーは、送信待ちの次のパケットに移動していることになる。しかしながら、その前方移動は、最も初期の検出されたゼロまで戻される。方法４５００プロセス全体に引き続き、ブロック確認応答内の開始シーケンス番号と関連づけられたパケットが正確に受信されなかった場合は、当然のことであるが、ウィンドーは前方にまったく移動されない。
【０２５６】
４５４０において、ビットマップ内を横断して次の前パケットに戻る。４５４５において、検査すべきビットマップ位置がさらに存在する場合は、次の確認応答に関する決定ブロック４５２５に戻る。４５２５において、ゼロが検出されない場合は、プロセスは、４５４０を通じて流れ、ビットマップ内を横断してビットマップが完了しているかどうかを確認する。ビットマップ内の全パケットが試験済みである場合は、４５５０に進み、送信された送信待ち行列を用いて送信を開始する。４５６０において、確認応答されているパケットをフラッシングすることができ、その関連するポインタを後続して用いるためにリサイクルさせることができる。このステップは、示されるように並行して（又はバックグラウンドで）動作することができる。これで、プロセスは停止することができる。
【０２５７】
要約すると、ブロックＡＣＫに関してビットマップが受信されたときに、ビットマップ内のゼロが既存の送信待ち行列と再リンクされて新しい送信待ち行列が形成される。これらのパケットに関する関連づけられたノードポインタがメモリ内に再度書き込まれる。しかしながら、（チャンクポインタによって識別されてチャンク６２０内に含まれている）パケット自体は絶対に移動しないことに注目すること。パケットが成功裏に送信されて確認応答されるか（又は時間切れ等の他のイベントが発生した）ときのみに、ノード及びチャンクがフラッシングされ、ポインタがフリーポインタリストに戻される。このメモリ管理プロセスは、並行して実行することができ、ブロックＡＣＫ処理を遅延させることができ、バックグラウンドで実行することができる、等である。例えば送信機がＴＸＯＰ内に残り時間を有する状況においては、再送信待ち行列が素早く生成され、送信は、残りのＴＸＯＰを利用することに進むことができる。送信機が直ちに再送信する許可を受けていない（すなわち、それ以上の残りのＴＸＯＰが存在しない）場合は、同じ方法を実行することができるが、再送信は直ちに生じる必要はない。
【０２５８】
図１８に関して上述されるように、進行中の送信に干渉せずにノードアレイ１８４２を更新可能にするためにピンポン型キャッシュを採用できることを思い出すこと。この技術は、ブロック確認応答再送信方式においても同様に採用することができる。図４６は、再送信プロセスにおいてピンポンノードアレイキャッシュを利用するために採用することができる方法４６００の実施形態例を示す。例えば、方法４６００は、上述されるブロック４５５０内に組み入れることができる。４６１０において、ブロック確認応答要求内の再送信情報に応じて更新可能な送信待ち行列からのノードポインタを用いて第１のピンポンノードアレイ１８４２をセットアップする。上記において詳述されるように、１８４４においてリンクＩＤが適宜更新される。４６２０において、この第１のノードアレイに切り換えて送信が進行するのを可能にする。４６３０において、メモリ構造を必要に応じてクリーニングすることができる（すなわち、パケットのフラッシング、ポインタのリサイクル、等）。
【０２５９】
多ＴＩＤブロック確認応答
所定の局において、様々なフロー（例えば、最大で１６のフロー）をサポートすることが可能であり、各フローは、トラフィック識別子（ＴＩＤ）に対応する。ＴＩＤは、局からのフローをマッピングすることを思い出すこと。１つの統合パケットにおいては、複数のＴＩＤに対応するパケットを見つけることが可能であり、例えばリンクごとのパケットの統合である。従って、複数のＴＩＤに対応するブロックＡＣＫ（又は、多ＴＩＤブロックＡＣＫ）を戻すことができる。一実施形態においては、多ＴＩＤブロックＡＣＫは、ＴＩＤ、次に、ビットマップ、次に他のＴＩＤ、次に他のビットマップ、等を具備する。統合パケット内のパケットは（再送信に起因して）必ずしも連続順でないという点で１つの問題が生じる。従って、所定のＴＩＤに関して、ブロックＡＣＫは、そのＴＩＤに関するその統合パケット内において受信された最低のシーケンス番号を指定する開始シーケンス番号から開始する。次に、開始シーケンス番号からのオフセットとしてＴＩＤビットマップが提供される。多ＴＩＤブロックＡＣＫを準備するための幾つかの実施形態が以下において詳述される。
【０２６０】
一実施形態においては、パケットが到着するのに応じて、各シーケンス番号を比較して最低のシーケンス番号を保管する。プロセスは、各ＴＩＤに関する最初の受信されたシーケンス番号を保存することによって開始することができる。次に、各パケットが到着するのに応じて、ＴＩＤに関する保存されたシーケンス番号を新しいパケットのシーケンス番号と比較し、最低のシーケンス番号を保管する。統合パケットの最後においては、各ＴＩＤに関する最低の開始シーケンス番号を有することになる。表示された最低のシーケンス番号を見つけた後は、（到着するのに応じて保存することができる）応答中の各パケットのシーケンス番号からそのシーケンス番号を減じて、ビットマップ内におけるそのパケットのオフセットを見つけ出す。最低の開始シーケンス番号は、ＴＩＤに関する開始シーケンス番号である。ライン速度において、パケットが有効であってライン速度で生じることができるかどうかを決定し、ＡＣＫ又はＮＡＫに関する各ビットを絶対シーケンス番号とともに単に保存する。統合パケットの最後において、保存されたパケットシーケンス番号シリーズ全体を横断し、減じられた値をオフセットとして用いるか又はインデキシングしてビットマップに入れ、保存されたＡＣＫ又はＮＡＫをビットマップに入れる。
【０２６１】
代替実施形態においては、現在受信されている最低のシーケンス番号に関するビットマップを格納する。次に、（格納順に依存して）左又は右シフトを行って格納場所を更新する。例えば、ビットマップを格納している間に、着信パケットのシーケンス番号が現在の最低のシーケンス番号よりも大きい場合は、（最低の受信されたシーケンス番号と現在受信されているシーケンス番号との間の差によって決定された）適切な場所において確認応答ビットを単にマーキングする。着信シーケンス番号が最低の前に受信されたシーケンス番号よりも小さい場合は、ビットマップをシフトし（新しいＡＣＫ又はＮＡＫを最低の場所に入れる）。シフトは、旧開始シーケンス番号（すなわち、最低の前に受信された開始シーケンス番号）と新しい開始シーケンス番号（すなわち、現在受信されているパケットの番号であって新しい最低の番号になる番号）との間の差として決定することができる。保存されたシーケンス番号全体の横断が行われた上述の第１の実施形態と対照的に、この実施形態においては、ビットマップ及び最低の開始シーケンス番号を保存する必要があるだけである。ビットマップ内のその他のいずれのシーケンス番号も保持する必要がない。
【０２６２】
上記の実施形態に関する説明は、即時部分的状態ブロック確認応答に適用される。完全な状態に拡大するときには、最初に単に各フローに関する格納された履歴を取り出して追加するだけである。いずれの実施形態も、単一ＴＩＤ状況に関して採用可能であり、多ＴＩＤをサポートするために各ＴＩＤに関して繰り返すことができる。
【０２６３】
不定期Ｕ−ＡＰＳＤ
本明細書において詳述される実施形態例は、不定期自動節電引き渡し（Ｕ−ＡＰＳＤ）を提供するように適合化するのにも非常に適する。Ｕ−ＡＰＳＤは、電力を保存するために用いられる技術である。スケジューリングされた技術及びスケジューリングされない技術を含む数多くの変形が存在する。図４７は、スケジューリングされない不定期自動節電引き渡しを実行するための方法４７００の実施形態例を示す。４７１０において、典型的Ｕ−ＡＰＳＤ方式では、ユーザー端末は自主的にウェークアップする。４７２０において、ユーザー端末は、トリガーパケットをアクセスポイントに送信する。４７３０において、アクセスポイントは、受信されたパケットからフローＩＤを決定する。決定ブロック４７４０において、フローＩＤと関連づけられたユーザー端末への送信待ちのパケットが存在する場合は、４７５０に進む。存在しない場合は、４７９０に進み、送信のためのパケットが存在しないことを示すインジケータ“さらなるパケットを送信”がデアサートされる（例えば、サービス期間終了（ＥＯＳＰ）ビット）。４７９５において、ユーザー端末は、スリープに戻ることができ、プロセスは停止することができる。決定ブロック４７４０において、ユーザー端末への送信用のパケットが存在する場合は、４７５０に進む。
【０２６４】
４７５０において、ＴＸノードアレイキャッシュから１つ以上のパケットを直ちに送信する。例えば、上記の図１８において説明されるようなＴＸノードアレイキャッシュ１８１０にアクセスすることができる。図１８において例示される技術を用いて、送信機は、ウェークアップされたユーザー端末に直ちに応答することができる。このことは、ユーザー端末をウェーク状態に保つための代替技術を採用する必要性、例えばデータなしのパケットを送信する、を排除する。このことは、ユーザー端末がウェーク状態を必要以上に長い時間維持する必要がないため、電力と同様に帯域幅の浪費を回避する。上述されるように、パケットは待ち行列に入っていて容易にアクセス可能であるため、この技術を用いることで、データを含むユーザー端末への応答を行うことができる。幾つかのシステム例、例えば典型的なボイス・オーバー・インターネット・プロトコル（ＶＯＩＰ）システム、においては、音声通信をサポートするために単一の又は２つのパケットのみが必要になることに注目すること。このように、Ｕ−ＡＰＳＤを採用するユーザー端末は、スケジューリングされない形でウェークアップし、相対的に小さい遅延を有するパケット又は２つのパケットを素早く取り出し、節電のためにスリープ状態に戻ることができる。
【０２６５】
決定ブロック４７６０において、４７５０において送信された応答パケットに含まれているパケットに加えて送信すべきパケットが存在する場合は、４７７０に進む。４７７０において、“さらなるパケットの送信”インジケータをアサートし、該インジケータは、ユーザー端末に送信されるパケットに含めることができる。この“さらなるパケットの送信”アサーションは、追加パケットを受信するためにアウェーク状態であるようにユーザー端末に示す。４７８０において、上述されるように、追加ノードをフェッチして関連づけられた追加パケットを送信する。４７６０に戻り、送信すべき追加パケットが存在するかどうかを決定する。４７９０において、上述されるように、このユーザー端末に関して指定された全パケットが送信された時点で、“さらなるパケットの送信”がデアサートされ、４７９５において、ユーザー端末は、スリープに戻ることができる。
【０２６６】
上記において詳述されるＵ−ＡＰＳＤ実施形態例においては、最大で４つのパケットをノードアレイキャッシュ内において入手可能であるため、これらのパケットを直ちにユーザー端末に送信することができる。これらの４つのパケットは、即座に送信することができ、さらなるパケットが後続する場合は、インジケータを設定することができる。引き続き、ＳＩＦＳ、ブロックＡＣＫ、等の後に、追加パケットの送信準備が完了することになる。この例においては、ＵＴがアウェーク又はスリープ状態であるかどうかをＡＰに示すための変数がＴＸフロー状態テーブル（例えば、１０３０）において維持される。この実施形態は、図１８において示される送信機において例示されるようなキャッシングを用いることを説明する（ノードアレイキャッシュ１８１０）。特定のフローに関して記憶容量の増大が希望される場合は、代替のキャッシング量を用いるか又は異なる形でパーティショニングすることができる（すなわち、応答して５つ以上のパケットを考慮した再パーティショニングである）
パワーセーブマルチポール（ＰＳＭＰ）
パワーセーブマルチポール（ＰＳＭＰ）は、上記において詳述されるノードキャッシング方式が利益を提供する他の分野である。スケジューリングされないＰＳＭＰ及びスケジューリングされたＰＳＭＰの２種類のＰＳＭＰが存在する。
【０２６７】
スケジューリングされない不定期ＰＳＭＰ（Ｕ−ＰＳＭＰ）は、スケジューリングされない不定期ＡＰＳＤに類似する。局がウェークアップしたときには、ＥＤＣＡ手順を用いてトリガーメッセージを送信し、トリガーメッセージは、（セットアップメッセージを介して）トリガーイルーブルドになるように構成されているアクセスクラスに関するＱｏＳ＿Ｄａｔａ又はＱｏＳ＿Ｎｕｌｌメッセージのいずれかであることができる。このパケットを受信した時点で、ＡＰは、この局に関して格納されているパケットを送信し、これらのパケットは、有利な形でノードアレイキャッシュ１８１０内に格納される。最後のパケットにおいて、ＡＰは、ＥＯＳＰを１に設定し、それ以上のパケットが存在しないことを示す。このパケットを受信後は、局はスリープに戻る。局が特定のアクセスクラスに関してＵ−ＰＳＭＰイネーブルドされるように構成されるときには、対応するフローは、ＴＡ／ＴＩＤ−フローマッピングテーブルにおいてＵ−ＰＳＭＰイネーブルドであることが示される（例えば１０３０）。さらに、ＴＡ／ＴＩＤ−フローマッピングテーブルでは、フローがスリープモード又はアクティブモードのいずれであるかを示す状態変数も維持される。
【０２６８】
以上のように、上記の実施形態は、Ｕ−ＰＳＭＰをサポートするのに非常に適する。一実施形態例においては、上述されるように、フローがＰＳＭＰフローであるかどうかを示す第１の変数、及び特定の局がアウェークであるか又はスリープであるかを示す第２の変数を維持し、その他の変数に加えることができる。受信データ（又はトリガー）の後に、ＡＰは、このトリガーが（第１の変数に従った）合法的なＵ−ＰＳＭＰフローであるかどうかを検査し、第２の変数を“スリープ状態”から“ウェーク状態”に設定する。ＡＰは、そのＳＴＡに関して格納されていて簡単に入手可能なパケットを送出し、局をスリープにし、第２の変数を“スリープ”に戻す。アウェークビットは、残りのＴＸＯＰが存在する場合も用いることができる。該場合には、アウェークビットが検査され、ＴＸＯＰはアウェーク状態にあるＳＴＡに関してしか用いられない。ＡＰは、送信を行う、等のために局をアウェーク状態に維持する裁量を有する。変数は、ＴＸアレイ状態テーブル１８３０に追加することができる。
【０２６９】
スケジューリングされたＰＳＭＰ（Ｓ−ＰＳＭＰ）においては、テンプレートが開発されてアップリンク及びダウンリンクスケジュールが発行される（例えば、ＡＰ内のファームウェアは、この機能、及びその他のあらゆるデバイスを実行することが可能である）。ＷＬＡＮ内の無線通信デバイスは、新しい呼が追加されるか又は呼がなくなるまで同じテンプレートを用いることができる。次に、新しいテンプレートを生成することができる。
【０２７０】
一実施形態においては、ＡＰは、スケジューリングされたＰＳＭＰを制御する。一方法は次のように実行することができる。すなわち、１）ＡＰがメディアをクリアするためのＣｌｅａｒ  ｔｏ  Ｓｅｎｄ（ＣＴＳ）（送信可）を自分に送信する。ＣＴＳは、ＮＡＶ継続時間をダウンストリーム＋アップストリーム送信機会に等しく設定する。２）ＡＰが、アップリンク及びダウンリンクスケジュールを（局ごとにマイクロ秒まで）詳述するＰＳＭＰフレームを送信する。３）これで、ダウンリンク送信が開始する。４）アップリンク送信がダウンリンク送信に従う。５）このフォーマットが詳細にスケジューリングされ、ＡＰは、ジッターを除去するために、スケジューリングされた終了時間を越えるのを回避する。このことは、ＮＡＶ継続時間の終了間近におけるメディアへのアクセスを制限することによって完遂することができる。ユーザー端末が自己の状態を確認するためのウェークアップをせず、ジッターによって導入されたオフセットに起因してメッセージを見逃し、スリープ状態に戻って送信機会を失うことがないようにジッターを回避することが重要である。
【０２７１】
一実施形態例においては、スケジュールを生成するために用いられるデータ構造は、上述されるように、ピンポンデータ構造内に保管される。データ構造は、スケジューリングされたＰＳＭＰに関して用いられるアップリンク及びダウンリンクスケジュールに関して用いられるテンプレートを具備する。現在のスケジュールは、ピンポンデータ構造の１／２内において保管される。このスケジュールは、ＷＬＡＮにおいて局に送信することができる。ＡＰは、ピンポンデータ構造の他方の１／２におけるテンプレートの変更を行うことができる。第１のテンプレートと第２のテンプレートとの間を交互するためのセレクタを採用することができる。ＡＰは、アクティブ中のテンプレートと干渉せずにアクティブでないいずれのテンプレートに関しても自由に作業することができる。この技術は、ノードアレイ１８４２、又はシャドーフローテーブル（１０９２及び１０９６）の使用と類似する。
【０２７２】
代替実施形態：分岐された高低スループット
図１０Ａに関して上述されるように、高速パケット処理に関しては、様々な機能、例えばフラグメンテーション、は要求されない場合があり、他方、その他のパケット型又はレガシー８０２．１１パケットに関するサポートは依然として希望される場合がある。図４８は、２つ以上のＭＡＣプロセッサを採用する代替実施形態を示す。高速ＭＡＣプロセッサ、例えば詳述されるＨ２Ｗプロセッサ５３０及び下位のＭＡＣ５４０（上記において詳述される、２４０等のＭＡＣプロセッサにおいて採用）、は、効率的な高速処理のために（おそらく単純化された機能を有する状態で）採用することができ、代替ＭＡＣプロセッサ４８１０は、その他のパケット型（又はレガシーパケット、例えば様々な型の８０２．１１パケット）を処理するために並行して採用される。
【０２７３】
一実施形態例においては、より低いスループットのＭＡＣプロセッサ４８１０がプロセッサ２１０において具体化され（さらに希望される場合は、その他の構成要素、例えばレガシーパケット処理に関して採用された構成要素、を含むこともできる）。実施形態例におけるプロセッサ２１０は、低スループットパケット及びレガシーパケットを処理する十分な電力を有しており、Ｈ２Ｗプロセッサ５３０等のより高いスループットの構成要素が高スループットパケットを効率的にサポートできるように設計することを可能にする。その他の実施形態は、後述されるように、追加のＭＡＣプロセッサを含むことができる。
【０２７４】
この例においては、８０２．１１（ｎ）は、フラグメンテーションをサポートしないため、上述される実施形態は、フラグメンテーションサポートをハードウェアから取り除いてファームウェア内に実装することによって単純化することができる。様々な単純化例が上記において説明される。（フラグメンテーションしきい値はチャンクサイズと異なることができるため）全レガシーパケットをファームウェアに処理させることは、フラグメンテーションサポートを取り除くことを可能にし、送信エンジン及び受信エンジンを単純化し、ノード及びチャンク管理を単純化する。当業者は、いずれの特長がサポートされるかに依存して様々な処理ブロックを含むか又は省略するように本明細書において詳述される実施形態を容易に適合化するであろう。
【０２７５】
当業者は、様々なパケット型の全機能を処理する能力を有する単一のプロセッサを含む実施形態と各々が部分組の機能を提供する能力を有する２つ以上のＭＡＣプロセッサを具備する他の実施形態との間において犠牲になる事柄を容易に理解するであろう。当然ながら、単一の組の機能を要求するパケットを処理する能力を有するＭＡＣプロセッサも採用可能である。
【０２７６】
分岐された高低スループットは、複数のＭＡＣプロセッサ間において機能をパーティショニングする一例であるにすぎない。一般的には、あらゆる組の機能を異なるＭＡＣプロセッサにおいて採用することができる。例えば、異なるパケット型に関する処理上の要求が構成要素を共有することによって効率を達成させる上で十分な類似性を共有しないとき又は回路設計上の考慮事項が様々なパケット型をサポートするための設計間において十分に類似していない場合に２つの等しい高速の（又はいずれかの速度の）パケット型を別個のプロセッサにおいて処理することが望ましい場合がある。
【０２７７】
図４９は、上述される第１のＭＡＣプロセッサと、マイクロプロセッサ内において具体化された第２のＭＡＣプロセッサと、を含む２つのＭＡＣプロセッサを含む無線通信デバイス４９００（例えば、アクセスポイント１０４又はユーザーデバイス１０６）の実施形態例を示す。この例は、図４８の一般化された実施形態と類似するより詳細な例である。
【０２７８】
当業者は、上図５において示される実施形態を図４９に示される代替実施形態に合わせて容易に適合化するであろう。この例においては、入力パケット及び出力パケットがバス４９８０において外部インタフェースから到着及び出発する。外部インタフェース例は、ＳＤＩＯ  Ｉ／Ｆ  ５８２、ＰＣＩ  Ｉ／Ｆ  ５８４、ＵＳＢインタフェース、又はその他の型のインタフェースを含む。インタフェースは、１つ以上のインタフェース間で仲裁する及び／又は多重化するための回路を含むことができる。着信パケットは、入力ブロック４９１０によって処理され、上述される入力及びメモリ管理技術を用いて、メモリインタフェース４９４０を介してメモリ内に格納される。メモリインタフェース４９２０は、例えば、メモリアービター５５２及び／又は５５６、ｍｕｘ５５４、ＳＲＡＭインタフェース５５８、ＳＤＲＡＭインタフェース５６２、又は様々なその他の構成要素を含むことができる。当業者は、その他のメモリインタフェースも同様に適合化するであろう。
【０２７９】
図５の実施形態とは対照的に、一定のパケット型がプロセッサ（例えばプロセッサ２１０）において処理される。この例においては、プロセッサによってフォーマット化されることになる入力パケットは、メモリインタフェース４９２０からプロセッサバス５２０を介してプロセッサに引き渡される（様々なその他の構成要素もプロセッサバス５２０に取り付けることができ、その例が図５に示される）。プロセッサインタフェースは、メモリインタフェース４９２０とバス５２０との間に配置することができる。この例においては、１つ以上のプロセッサメモリＦＩＦＯ４９５０が配置される（受信されたパケットを引き渡すためのその他のインタフェース）。このことは、パケット（及びノード、チャンク等のデータ構造）をプロセッサ２１０用に格納することを可能にする。受信された低スループットパケットもプロセッサ２１０によって処理され、プロセッサメモリＦＩＦＯ４９５０を介してメモリインタフェース４９２０からプロセッサバス５２０に転送することができる。
【０２８０】
代替実施形態においては、プロセッサメモリＦＩＦＯは、プロセッサメモリへの直接接続に代えることができる。例えば、ＤＭＡを用いて、低速パケットをプロセッサ２１０による処理のためにメモリ内に入れることができる。一実施形態においては、メモリインタフェース４９２０は、低速パケットを高速パケットＲＡＭ内に格納せずに低速パケットを（ＦＩＦＯではなく）直接プロセッサメモリ４９５０内に書き込むことができる。
【０２８１】
この例においては、パケットは、プロセッサ２１０によって（メモリインタフェース４９２０を介して）メモリに格納することもできる。例えば、プロセッサは、受信されたパケットを外部インタフェースにおいて送出せずにＷＬＡＮにおいて再ルーティングして戻すことができる。本明細書において詳述される全実施形態は、受信されたパケットを送信のために再ルーティングして戻すように適合化できることに注目すること。バス５２０に引き渡されたパケットは、上述される技術のうちのいずれかを用いてフォーマット化することができる。
【０２８２】
実施形態例においては、８０２．１１（ｂ）、（ｇ）及び（ｅ）パケットは、フォーマット化（該当すると思われるあらゆるフラグメンテーションを含む）のためにプロセッサにルーティングされる。その他のパケット型もプロセッサによるフォーマット化に適することができる。例えば、８０２．１１（ｎ）は、同じくプロセッサによって適切にフォーマット化される統合ＭＡＣサービスデータユニット（Ａ−ＭＳＤＵ）を規定する。様々な再ルーティング技術を採用することができる。この例においては、パケットがプロセッサによるフォーマット化のために受信されたときには、パケットはメモリに格納され、送信用のフォーマット化を開始するための割り込みがプロセッサに与えられる（詳細は示されない）。
【０２８３】
フォーマット化された低スループットパケット又はレガシーパケットは、プロセッサ２１０による処理後に、プロセッサＷＬＡＮ送信ＦＩＦＯ４９６０における送信のために格納することができる。レディ信号、スロットル制御を提供するための信号、等のフィードバックをプロセッサＷＬＡＮ  ＦＩＦＯ４９６０に対して行うことができる。これらのパケットは、待ち行列に入れるため及び（例えばレガシープロトコルエンジン２２１０による）可能なさらなる処理のために及び究極的にはＰＨＹ２６０での送信のためにＴＸエンジン１８８０に引き渡すこともできる。これらのパケットは、直接ＴＸエンジン１８８０に引き渡すことができ、又はアレイ制御１８４０によって管理される待ち行列１８５０（図１８において説明）に組み入れることができる、等である。実施形態例においては、統合モジュール２６１０はレガシーパケット及びＡ−ＭＳＤＵパケットに関しては迂回できることに注目すること。
【０２８４】
高速パケット、例えば８０２．１１（ｎ）統合Ｍａｃプロトコルデータユニット（Ａ−ＭＰＤＵ）、は、同じく入力ブロック４９１０によって受信されてメモリインタフェース４９２０を介してメモリに格納される。この場合は、パケットは、上記において（例えば図１８に関して）詳述される技術を用いてＴＸエンジン１８８０によって送信される。この例においては、高速パケットのハードウェア処理は、高速送信を考慮し、上述されるレガシーパケット等のより低速のパケットは、スループットのボトルネックを発生させずにプロセッサ２１０のファームウェアにおいて実行することができる。このことは、様々なレガシーパケットの詳細が高速ＭＡＣ処理ハードウェアから置き去りにされることを考慮し、より効率的に設計され、その一方で依然としてファームウェア実装ＭＡＣプロセッサを通じてレガシーサポートを提供することを可能にする。高速パケットは、究極的には、ＰＨＹを介してＷＬＡＮにおいて送信される。高速又は低速の物理的送信を示すためのヘッダーを用いることができる。
【０２８５】
ＷＬＡＮから受信されたパケットは、結合されたＲＸエンジン４９７０に引き渡され、究極的にはメモリインタフェース４９２０を介してメモリに格納される。低速パケットは、処理を目的としてプロセッサ２１０に渡すことができる（すなわち、レガシーパケット、又は、ハードウェアＭＡＣプロセッサにおいてサポートされない特長を用いるパケット、例えばフラグメンテーション）。代替実施形態においては、パケットは、（メモリに格納されずに）直接プロセッサ２１０に進むことができ又はその他の代替ＭＡＣプロセッサに接続することができる（あらゆる数の組のパケットの特長をサポートするためにあらゆる数のＭＡＣプロセッサを採用できることを思い出すこと）。この例においては、低スループットパケット又はレガシーパケットは、上述されるように、プロセッサメモリＦＩＦＯ４９５０を介してメモリインタフェース４９２０からプロセッサに引き渡される。これらのパケットは、レガシープロトコルエンジン２２１０によって部分的に処理することができる場合とできない場合がある。分割ユニット２８０２は、統合されていないデータユニット（例えばレガシーパケット）に関しては迂回できることに注目すること。
【０２８６】
ＲＸエンジン４９７０（及び採用された場合のその他の構成要素、例えばレガシーエンジン２２１０）は、下位ＭＡＣコア５４０において上述される分割パケットを処理する。この例においては、ハードウェアＭＡＣプロセッサにおいて処理されるパケットは高速パケットだけであるが、代替実施形態においては、あらゆる型のパケットを処理することができる。
【０２８７】
ＲＸエンジン４９７０は、上記において詳述されるように、レガシーエンジン２２１０を用いていずれのパケット型も解読することができる。受信されたパケットは、パケット型を示すためのＭＡＣ／ＰＨＹインタフェース（例えば、上記において詳述されるＭＡＣ／ＰＨＹインタフェース５４５）によってタグを付すことができる点に注目すること。例えば、パケットは、８０１．１１（ａ）、（ｂ）、（ｅ）、（ｇ）、（ｎ）、等として識別することができる。パケットは、Ａ−ＭＳＤＵ又はＡ−ＭＰＤＵとして識別することができる。一般的には、あらゆる数のＭＡＣプロセッサのうちの１つへのパケットのルーティングを示すためのタグを用いることができる。
【０２８８】
直前において説明される実施形態例においては、統合及び分割は、高速パケットのみに適用される点に注目すること（上述されるように、統合は、高速パケットに関してはオプションである）。低速パケットは、統合ブロック及び分割ブロックを通じて渡される。フラグメンテーションは、レガシーパケット及び低速パケットのみに関してサポートされ、高速パケットに関してはサポートされない。プロセッサ（すなわち、２１０）は、第１のＭＡＣプロセッサであり、第２のＭＡＣプロセッサは、上記において詳述される様々な構成要素を具備する（すなわち、図５）。上述されるように、これらは例であるにすぎない。一般的には、第１のＭＡＣプロセッサにおいてはあらゆる特長組をサポートすることができ、第２のＭＡＣプロセッサにおいては同じ組の又は異なる組の特長をサポートすることができる（これらのうちのいずれかはプロセッサ２１０等のプロセッサを用いて実行することができ、又はいずれも実行することができない）。
【０２８９】
出力ブロック４９３０は、メモリインタフェース４９２０を介して高速パケットをパケットバッファから受信してハンドオフすることができる。出力ブロック４９３０は、プロセッサ出力ＦＩＦＯ ４９４０から引き渡された低速パケットと高速パケットとの間で仲裁することもできる。実施形態例においては、プロセッサは、優先度順でのハンドオフの準備が整っている処理済みパケットをプロセッサ出力ＦＩＦＯ ４９４０に引き渡す。代替実施形態においては、代替メモリは、出力ブロック４９３０が希望される場合は出力ブロック４９３０内における優先順位設定のためにパケットを選択するのを可能にするためにプロセッサ出力ＦＩＦＯ ４９４０を交換することが可能である。さらに他の代替実施形態においては、プロセッサ出力ＦＩＦＯ ４９４０は取り除くことが可能であり、出力ブロック４９３０は、（例えばＤＭＡ又はその他のアクセス方法を用いて）プロセッサメモリへの直接アクセスを介して低速パケットをハンドオフすることができる。さらに他の実施形態においては、プロセッサ出力ＦＩＦＯ ４９４０は、出力ブロック４９３０が優先度方式を実装するために選択することができる複数の優先待ち行列を有することができる。
【０２９０】
当業者は、無線通信デバイス４９００において具体化された教義の非常に数多くの代替構成を認識するであろう。
【０２９１】
図５０は、多フローパケットバッファリング及び待ち行列化の側面を示す。図５０は、パケットバッファ５０３０内の第１のデータ構造５０４０内に、第１のパケット５０５０の長さ、パケット５０６０のシーケンス番号、及びパケットバッファ内の第２のデータ構造５０８０の第２のパケットバッファ格納場所５０７０を格納するための手段５０１０と、第１のパケットからのデータ５０２０を、格納された第２のパケットバッファ格納場所５０７０によって識別される第２のデータ構造５０８０内に格納するための手段５０２０と、を具備する。
【０２９２】
図５１は、多フローパケットバッファリング及び待ち行列化の側面を示す。図５１は、パケットと関連づけられた第１のデータ構造５１４０と、関連づけられたパケットからのデータを具備する１つ以上の第２のデータ構造５１８０と、を具備し、関連づけられたパケットの長さを示す長さフィールド５１５０を具備する第１のデータ構造、関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールド５１６０、及びパケットバッファ５１３０内における第２のデータ構造５１８０のうちの１つの場所を示す第２のデータ構造ポインタフィールド５１７０を示し、第２のデータ構造５１８０のうちの１つ以上のデータ構造内にパケットを格納するのための手段５１２０を示す。
【０２９３】
図５２は、高速メディアアクセス制御に関するメモリ管理の側面を示す。図５２は、第１又は第２のモードを選択するための手段５２９０と、複数の通信フローの各々に関する１つ以上のパラメータを格納するように第１のモードにおいて第１のメモリ５２３０を構成するための手段５２１０と、複数の通信フローの各々に関するポインタを格納するように第２のモードにおいて第１のメモリを構成するための手段５２６０であって、各ポインタは、各々の通信フローと関連づけられた格納場所を示す手段５２６０と、複数の通信フローの各々に関するパケットを格納するように第１のモードにおいて第２のメモリ５２４０を構成するための手段５２２０と、複数の通信フローの各々に関する１つ以上のパラメータから成る複数の組を格納するように第２のモードにおいて第２のメモリを構成するための手段５２７０であって、１つ以上のパラメータから成る各組は、各々の通信フローと関連づけられたポインタによって示される格納場所に格納される手段５２７０と、複数の通信フローの各々に関するパケットを格納するために動作可能になるように第２のモードにおいて第３のメモリとともに動作可能なメモリインタフェース５２５０を構成するための手段５２８０と、を具備する。
【０２９４】
図５３は、多フローメディアアクセス制御の側面を示す。図５３は、複数のフロー識別子インデックス値のうちの１つへのフロー識別子インデックスを設定するための手段５３２０であって、各フロー識別子インデックスは、複数のフローのうち各々の１つと関連づけられた手段５３２０と、第１のメモリ５３３０内の複数の第１のメモリ場所に複数のパラメータ組５３４０を格納するための手段５３１０であって、各パラメータ組は、複数のフローの各々の１つに関する１つ以上のパラメータを具備し、各パラメータ組に関する第１のメモリ場所は、フロー識別子インデックス内において設定された各々のフロー識別子インデックス値によって識別される手段５３１０と、複数のパラメータ組のうちの１つの組のパラメータのうちの１つ以上をフロー識別子インデックスに従って第１のメモリから取り出すための手段５３５０と、を具備する。
【０２９５】
図５４は、多フローメディアアクセス制御の側面を示す。図５４は、複数のパラメータ組５４２０を第１のメモリ５４３０に格納するための手段５４１０であって、各パラメータ組は、複数のパラメータ組格納場所のうちの各々の１つにおいて格納され、各パラメータ組は、複数のフローの各々の１つに関する１つ以上のパラメータを具備し、複数のフローの各々は、複数のフロー識別子のうちの１つによって識別される手段５４１０と、複数のパラメータ組ポインタ５４５０を第２のメモリに格納するための手段５４４０であって、各パラメータ組ポインタは、第１のメモリ内における複数のパラメータ組格納場所のうちの１つを識別し、各パラメータ組ポインタは、複数のフローのうちの１つと関連づけられた手段５４４０と、フロー識別子に従って第２のメモリからパラメータ組ポインタを取り出すための手段５４７０と、取り出されたパラメータ組ポインタに従ってパラメータ組にアクセスすることによって第１のメモリから１つ以上のパラメータを取り出すための手段５４８０と、を具備する。
【０２９６】
図５５は、高速メディアアクセス制御に関する多フロー多重化の側面を示す。図５５は、第２の複数の待ち行列５５３０の各々における複数のフローのうちの１つと関連づけられた１つ以上のパケット要素５５２０を格納するための手段５５１０と、第２の複数の待ち行列のうちの１つから要素を選択するための手段５５４０と、第１の複数の待ち行列５５７０のうちの１つに選択された要素５５６０を格納するための手段５５５０であって、各待ち行列は、複数のチャネルのうちの１つと関連づけられる手段５５５０と、を具備する。
【０２９７】
図５６は、高速通信システムにおける統合の側面を示す。図５６は、１つ以上の第１のデータ構造５６２０を待ち行列５６３０内に格納するための手段５６１０であって、各々の第１のデータ構造は、各々の関連づけられたパケットの長さフィールド５６３５と、第２のデータ構造５６５０へのポインタ５６４０と、を具備し、第２のデータ構造は、各々の関連づけられたパケットデータの少なくとも一部分を具備する手段５６１０と、送信データ量を決定するための手段５６６０と、待ち行列内の第１のデータ構造のうちの１つ以上の第１のデータ構造の長さフィールドから１つ以上の長さ値を取り出すための手段５６７０と、一組の１つ以上の第１のデータ構造からの取り出された長さ値の合計が送信データ量よりも小さいか又は同じであるような形で前記第１のデータ構造の組を選択するための手段５６８０と、統合プロトコルデータユニット内のパケットを統合するための手段５６９０であって、各々の統合されたパケットは、選択された第１のデータ構造の組内の第２のデータ構造を指し示すポインタによって識別される手段５６９０と、を具備する。
【０２９８】
図５７は、サービス中待ち行列及び待機中待ち行列として働くシャドーキャッシュの側面を示す。図５７は、第１の待ち行列５７１０をサービス中待ち行列として選択するための手段５７２０と、第２の待ち行列５７３０を待機中待ち行列として選択するための手段５７４０と、第１のフローをスケジューリングするための手段５７５０と、第２のフローをスケジューリングするための手段５７６０と、サービス中待ち行列内の第１のスケジューリングされたフローと関連づけられた１つ以上の要素を格納するための手段５７７０と、第１の送信機会中における送信のためにサービス中待ち行列を処理するための手段５７８０と、待機中待ち行列内の第２のスケジューリングされたフローと関連づけられた１つ以上の要素を格納するための手段５７９０であって、格納することは、サービス中待ち行列の処理と同時に生じることができる手段５７９０と、を具備する。
【０２９９】
図５８は、入力ポリシングの側面を示す。図５８は、複数のフローのうちの１つに関するパケットと関連づけられたフロー識別子を受信するための手段５８１０と、フロー識別子と関連づけられた１つ以上のパラメータを取り出すための手段５８２０と、予め決められた条件がフロー識別子と関連づけられた１つ以上の取り出されたパラメータに従って満たされるときにパケットを受け付けるための手段５８３０と、予め決められた条件がフロー識別子と関連づけられた１つ以上の取り出されたパラメータに従って満たされていないときにはパケットを拒否するための手段５８４０と、を具備する。
【０３００】
図５９は、入力ポリシングの側面を示す。図５９は、複数のフローのうちの１つに関するパケットと関連づけられたフロー識別子を受信するための手段５９１０と、現在のパケットバッファ占有率を取り出すための手段５９２０と、フロー識別子と関連づけられた最大バッファ占有率を取り出すための手段５９３０と、フロー識別子と関連づけられた累積パケットを取り出すための手段５９４０と、フロー識別子と関連づけられた最大パケットを取り出すための手段５９５０と、現在のパケットバッファ占有率がフロー識別子と関連づけられた最大バッファ占有率よりも小さいか又はフロー識別子と関連づけられた累積パケットがフロー識別子と関連づけられた最大パケットよりも少ないときにはパケットを受け付けるための手段５９６０と、を具備する。
【０３０１】
図６０は、入力ポリシングの側面を示す。図６０は、パケットバッファ６０１０と、複数のフローのうちの１つに関する１つ以上のパラメータを取り出すための手段６０２０と、１つ以上の取り出されたパラメータに従ってパケットバッファ内に複数のフローのうちの１つと関連づけられたパケットを条件付きで格納するための手段６０３０と、を具備する。
【０３０２】
図６１は、低レーテンシー応答に関するメディアアクセス制御の側面を示す。図６１は、１つ以上の第１のデータ構造６１２０を待ち行列６１３０内に格納するための手段６１１０であって、各々の第１のデータ構造は、各々の関連づけられたパケットの長さフィールド６１３５と、第２のデータ構造６１５０を指し示すポインタ６１４０と、を具備し、第２のデータ構造は、各々の関連づけられたパケットデータの少なくとも一部分を具備する手段６１１０と、予め決められた時間間隔内における応答送信を要求する送信機会に応じて待ち行列内の第１のデータ構造のうちの１つ以上のデータ構造の長さフィールドから１つ以上の長さ値を取り出すための手段６１６０と、予め決められた時間間隔内において応答プロトコルデータユニットを形成するための手段６１７０であって、プロトコルデータユニットは、予め決められた時間間隔内において少なくとも１つの長さ値に従って決定されたプロトコルデータユニット長さ値を具備する手段６１７０と、を具備する。
【０３０３】
情報及び信号は、様々な種類の技術及び技法のうちのいずれかを用いて表すことができることを当業者は理解するであろう。例えば、上記の説明全体を通じて言及されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界、磁粒子、光学界、光学粒子、又はそのあらゆる組合せによって表すことができる。
【０３０４】
本明細書において開示される実施形態に関係させて説明される様々な例示的論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェアとして、コンピュータソフトウェアとして、又は両方の組合せとして実装できることを当業者はさらに理解であろう。ハードウェアとソフトウェアのこの互換性を明確に例示するため、上記においては、様々な例示的構成要素、ブロック、モジュール、回路、及びステップが、各々の機能の観点で一般的に説明されている。これらの機能がハードウェアとして又はソフトウェアとして実装されるかは、全体的システムに対する特定の用途上の及び設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、該実装決定は、本開示の適用範囲からの逸脱を生じさせるものであるとは解釈すべきではない。  
本明細書において開示される実施形態に関して説明される様々な例示的な論理ブロック、モジュール、及び回路は、本明細書において説明されている機能を果たすように設計された汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、その他のプログラミング可能な論理デバイス、ディスクリートゲートロジック、ディスクリートトランジスタロジック、ディスクリートハードウェア構成品、又はそのあらゆる組合せ、とともに実装又は実行することができる。汎用プロセッサはマイクロプロセッサであることができるが、代替策として、従来のどのようなプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってもよい。さらに、プロセッサは、計算装置の組合せ、例えば、ＤＳＰと、１つのマイクロプロセッサとの組合せ、複数のマイクロプロセッサとの組合せ、ＤＳＰコアと関連する1つ以上のマイクロプロセッサとの組合せ、又はその他のあらゆる該コンフィギュレーションとの組合せ、として実装することもできる。
【０３０５】
本明細書において開示される実施形態に関して説明される方法又はアルゴリズムのステップは、ハードウェア内において直接具体化させること、プロセッサによって実行されるソフトウェアモジュール内において具体化させること、又はこれらの２つの組合せにおいて具体化させることができる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能なディスク、ＣＤ−ＲＯＭ、又は当業において既知であるその他のあらゆる形態の記憶媒体に常駐することができる。１つの典型的な記憶媒体をプロセッサに結合させ、プロセッサが記憶媒体から情報を読み出すようにすること及び記憶媒体に情報を書き込むようにすることができる。代替として、記憶媒体は、プロセッサと一体化させることができる。プロセッサ及び記憶媒体は、ＡＳＩＣ内に常駐することができる。ＡＳＩＣは、ユーザー端末内に常駐することができる。代替として、プロセッサ及び記憶媒体は、ユーザー端末内において個別構成要素として常駐することができる。
【０３０６】
開示されている実施形態に関する上記の説明は、当業者が本開示を製造又は使用できるようにすることを目的とするものである。実施形態に対する様々な修正は、当業者にとって容易に明確になるであろう。さらに、本明細書において定められている一般原理は、本開示の精神及び適用範囲を逸脱しない形でその他の実施形態に対しても適用することができる。以上のように、本開示は、本明細書において示される実施形態に限定することを意図するものではなく、本明細書において開示されている原理及び斬新な特長に一致する限りにおいて最も広範な適用範囲が認められるべきである。
【図面の簡単な説明】
【０３０７】
【図１】複数のユーザーをサポートすることができる無線通信システムの一般的ブロック図である。
【図２】アクセスポイント又はユーザー端末として構成することができる無線通信デバイスの側面を示した図である。
【図３】ユーザー端末に関して構成されたＭＡＣプロセッサの実施形態を示した図である。
【図４】アクセスポイントに関して構成されたＭＡＣプロセッサの実施形態を示した図である。
【図５】無線通信デバイスのより詳細な実施形態例を示した図である。
【図６】パケットバッファの実施形態例を示した図である。
【図７】パケットバッファ例をさらに示した図である。
【図８】ＭＡＣプロセッサ内において採用することができる追加構成要素を示した図である。
【図９】パケットをパケットバッファ内に書き込み、待ち行列を生成するための方法の実施形態例を示した図である。
【図１０】ＷＬＡＮサブシステムのホストの実施形態例を示した図である。
【図１１】ＴＸフロー状態テーブルの内容の実施形態例を示した図である。
【図１２】入力ポリシングを行うための方法の実施形態例を示した図である。
【図１３】入力ポリシングの方法の実施形態例を示した図である。
【図１４】ＦＩＦＯの実施形態例を示した図である。
【図１５】ＭＳＤＵを１つ以上のフラグメントに細分するプロセス例を示した図である。
【図１６】２つ以上のメモリ書き込みと関連するアービターの概念的構成を示した図である。
【図１７】より小さい、固定された一組の標準的ＥＤＣＡ待ち行列を用いて相対的に大きい複数のＥＤＣＡ待ち行列をサポートするように構成された無線通信デバイスの一部分の実施形態例を示した図である。
【図１８】下位ＭＡＣコアの様々な構成要素を示す実施形態例を示した図である。
【図１９】下位ＭＡＣコアプロセッサのセクションの詳細な実施形態例を示した図である。
【図２０】インターロック例を示した図である。
【図２１】リンクＩＤの実施形態例を示した図である。
【図２２】下位ＭＡＣコアの実施形態例の追加構成要素を示した図である。
【図２３】レートＦＳＭの実施形態例を示した図である。
【図２４】レガシープロトコルエンジン例を示した図である。
【図２５】ＰＨＹへの概念的リンクと接続されたレガシープロトコルエンジン例を示した図である。
【図２６】送信パケットのＭＡＣ処理をさらに詳細に説明する実施形態例を示した図である。
【図２７】Ａ−ＭＰＤＵのフォーマット例を示した図である。
【図２８】下位ＭＡＣコアの受信構成要素を例示する実施形態例を示した図である。
【図２９】ユーザー端末に関して構成されたハードウェアテーブルの実施形態例を示した図である。
【図３０】アクセスポイント又はスーパーステーションにおいて用いるために構成されたハードウェアテーブルの実施形態例を示した図である。
【図３１】ＲＸフロー状態テーブルの実施形態例を描いた図である。
【図３２】ハードウェアテーブル及びメモリを様々な構成で構成するための方法の実施形態例を示した図である。
【図３３】ＲＸパケットアレイをサポートするように構成されたパケットバッファの一部分に関する代替構成を示した図である。
【図３４】入力ポリシング及び優先度に基づくハンドオフを含む無線ネットワークに関するエンドツーエンド優先度方式例を示した図である。
【図３５】ハンドオフ決定ブロック及びハンドオフエンジンの動作を例示する方法の実施形態例を示した図である。
【図３６】ハンドオフ決定を行うための方法の実施形態例を示した図である。
【図３７】受信されたパケットを処理するための方法の実施形態例を示した図である。
【図３８】１つ以上のハンドオフ待ち行列を処理するための方法の実施形態例を示した図である。
【図３９】ハンドオフに関して利用可能なフローを決定する方法の実施形態例を示した図である。
【図４０】決定状態テーブル例を示した図である。
【図４１】ハンドオフ待ち行列の実施形態例を示した図である。
【図４２】ハンドオフを行うための方法の実施形態例を示した図である。
【図４３】ハンドオフ状態テーブルにおけるパケットバッファのインデキシングに関して用いられる変数例を示した図である。
【図４４】即時ブロック確認応答要求に応答するための方法の実施形態例を示した図である。
【図４５】ブロック確認応答に応答するための方法の実施形態例を示した図である。
【図４６】再送信プロセスにおいてピンポンノードアレイキャッシュを利用するための方法の実施形態例を示した図である。
【図４７】不定期自動節電引き渡しを行うための方法の実施形態例を示した図である。
【図４８】２つ以上のＭＡＣプロセッサを採用する代替実施形態を示した図である。
【図４９】マイクロプロセッサにおいて具体化された第１のＭＡＣプロセッサ及び第２のＭＡＣプロセッサを含む２つのＭＡＣプロセッサを含む無線通信デバイスの実施形態例を示した図である。
【図５０】多フローパケットのバッファリング及び待ち行列化の側面を示した図である。
【図５１】多フローパケットのバッファリング及び待ち行列化の側面を示した図である。
【図５２】高速メディアアクセス制御に関するメモリ管理の側面を示した図である。
【図５３】多フローメディアアクセス制御の側面を示した図である。
【図５４】多フローメディアアクセス制御の側面を示した図である。
【図５５】高速メディアアクセス制御に関する多フロー多重化の側面を示した図である。
【図５６】高速通信システムにおける統合の側面を示した図である。
【図５７】サービス中待ち行列及び待機中待ち行列としてサービングするシャドーキャッシュの側面を示した図である。
【図５８】入力ポリシングの側面を示した図である。
【図５９】入力ポリシングの側面を示した図である。
【図６０】入力ポリシングの側面を示した図である。
【図６１】低レーテンシー応答に関するメディアアクセス制御の側面を示した図である。
【図１】
2009532954.tif 000003
【図２】
2009532954.tif 000004
【図３】
2009532954.tif 000005
【図４】
2009532954.tif 000006
【図５】
2009532954.tif 000007
【図６】
2009532954.tif 000008
【図７】
2009532954.tif 000009
【図８】
2009532954.tif 000010
【図９】
2009532954.tif 000011
【図１０Ａ】
2009532954.tif 000012
【図１０Ｂ】
2009532954.tif 000013
【図１１】
2009532954.tif 000014
【図１２】
2009532954.tif 000015
【図１３】
2009532954.tif 000016
【図１４】
2009532954.tif 000017
【図１５】
2009532954.tif 000018
【図１６】
2009532954.tif 000019
【図１７】
2009532954.tif 000020
【図１８】
2009532954.tif 000021
【図１９】
2009532954.tif 000022
【図２０】
2009532954.tif 000023
【図２１】
2009532954.tif 000024
【図２２】
2009532954.tif 000025
【図２３】
2009532954.tif 000026
【図２４】
2009532954.tif 000027
【図２５】
2009532954.tif 000028
【図２６】
2009532954.tif 000029
【図２７】
2009532954.tif 000030
【図２８】
2009532954.tif 000031
【図２９】
2009532954.tif 000032
【図３０】
2009532954.tif 000033
【図３１】
2009532954.tif 000034
【図３２】
2009532954.tif 000035
【図３３】
2009532954.tif 000036
【図３４】
2009532954.tif 000037
【図３５】
2009532954.tif 000038
【図３６】
2009532954.tif 000039
【図３７】
2009532954.tif 000040
【図３８】
2009532954.tif 000041
【図３９】
2009532954.tif 000042
【図４０】
2009532954.tif 000043
【図４１】
2009532954.tif 000044
【図４２】
2009532954.tif 000045
【図４３】
2009532954.tif 000046
【図４４】
2009532954.tif 000047
【図４５】
2009532954.tif 000048
【図４６】
2009532954.tif 000049
【図４７】
2009532954.tif 000050
【図４８】
2009532954.tif 000051
【図４９】
2009532954.tif 000052
【図５０】
2009532954.tif 000053
【図５１】
2009532954.tif 000054
【図５２】
2009532954.tif 000055
【図５３】
2009532954.tif 000056
【図５４】
2009532954.tif 000057
【図５５】
2009532954.tif 000058
【図５６】
2009532954.tif 000059
【図５７】
2009532954.tif 000060
【図５８】
2009532954.tif 000061
【図５９】
2009532954.tif 000062
【図６０】
2009532954.tif 000063
【図６１】
2009532954.tif 000064
【国際調査報告】
2009532954.tif 000065
2009532954.tif 000066
2009532954.tif 000067
2009532954.tif 000068
2009532954.tif 000069