様々な側面が以下において詳細に説明され、これらの側面のうちの1つ以上を所定の実施形態において結合させることができる。本明細書において開示される側面は、超高ビットレートWLAN物理層(又は新しく出現しつつある送信技術を用いる同様のアプリケーション)によって非常に効率的な動作をサポートする。WLAN例は、2つの周波数帯域モード20MHz及び40MHzにおいて動作可能である。WLAN例は、100Mbps(100万ビット/秒)を超えるビットレートをサポートし、20MHzのチャネル帯域幅における最大で300Mbps、及び40MHzのチャネル帯域幅における最大で600Mbpsを含む。様々な代替WLANもサポートされ、2つ以上の周波数帯域モード、及びあらゆる数のサポートされたビットレートを有する代替WLANを含む。
様々な側面は、レガシーWLANシステムの分散型調整動作の単純さ及び強固さを保持し、該システムの例が802.11(a−g)に示される。様々な実施形態の利点は、該レガシーシステムとの後方互換性を維持しながら達成させることができる。(以下の説明においては、802.11システムは、レガシーシステム例として説明することができる点に注目すること。当業者は、改良点が代替システム及び基準とも適合可能であることを認識するであろう。)
本明細書において説明される1つ以上の典型的側面は、無線データ通信システムを対象として詳述される。この範囲内における使用が有利である一方で、異なる環境又は構成においては開示の異なる実施形態を組み入れることができる。一般的には、本明細書において説明される様々なシステムは、ソフトウェアによって制御されるプロセッサ、集積回路、又は個別論理を用いて形成することができる。アプリケーション全体を通じて言及されることがあるデータ、命令、コマンド、情報、信号、シンボル、及びチップは、有利なことに、電圧、電流、電磁波、磁界、磁粒子、光学界、光学粒子、又はそのあらゆる組合せによって表される。さらに、各ブロック図において示されるブロックは、ハードウェア又は方法上のステップを表すことができる。方法上のステップは、本開示の適用範囲から逸脱せずに互換可能である。「典型的な」という表現は、本明細書においては、“1つの例、事例、又は実例”を意味するために用いられる。本明細書において“典型的な”実施形態として説明されているいずれの実施形態も、その他の実施形態よりも好ましい又は有利であるとは必ずしも解釈すべきではない。
図1は、1つ以上のユーザー端末(UT)106A乃至Nに接続されたアクセスポイント(AP)104を具備するシステム100の典型的実施形態を示す。802.11用語により、本明細書においては、AP及びUTは、局又はSTAとも呼ばれる。本明細書において説明される技術及び側面は、その他の型のシステムに対しても適用可能である(例は、上記において詳述されるセルラー基準を含む)。基地局という用語は、アクセスポイントという用語とし互換的に用いることができる。ユーザー端末という用語は、ユーザー装置(UE)、加入者ユニット、加入者局、アクセス端末、遠隔端末、移動局、又は当業において知られるその他の対応する用語と互換的に用いることができる。移動局という用語は、固定された無線アプリケーションを包含する。
ユーザー端末106は、互いに直接通信することができる点にも注目すること。802.11(e)によって導入されたダイレクトリンクプロトコル(DLP)は、STAが(同じAPによって制御される)ベーシックサービスセット(BSS)内の他の宛先STAに直接フレームを転送するのを可能にする。様々な実施形態においては、当業において知られるように、アクセスポイントは要求されない。例えば、独立BSS(IBSS)は、STAのあらゆる組合せによって形成することができる。当業において知られる夥しい数の通信フォーマットのうちのいずれかを用いて無線ネットワーク120を介して互いに通信するユーザー端末のアドホックネットワークを形成することができる。
AP及びUTは、ワイヤレスローカルエリアネットワーク(WLAN)120を介して通信する。以下において詳述される実施形態においては、WLAN120は、高速MIMO OFDMシステムである。しかしながら、WLAN120は、あらゆる無線LANであることができる。オプションとして、アクセスポイント104は、ネットワーク102を介してあらゆる数の外部デバイス又はプロセスと通信する。ネットワーク102は、インターネット、イントラネット、又はその他の何らかの有線、無線、又は光学のネットワークであることができる。接続110は、ネットワークからアクセスポイント104に物理層信号を搬送する。デバイス又はプロセスは、ネットワーク102に接続するか又はWLAN120においてUTとして(又はUTとの接続を介して)接続することができる。ネットワーク102又はWLAN120のいずれかに接続することができるデバイス例は、電話、パーソナルデジタルアシスタント(PDA)、様々な型のコンピュータ(あらゆる型のラップトップ、パソコン、ワークステーション、端末)、ビデオ装置、例えばカメラ、カムコーダー、ウェブカム、及び実質的にその他のあらゆる型のデータデバイスを含む。プロセスは、音声、映像、データ通信、等を含むことができる。様々なデータストリームは、様々なサービスの質(QoS)技術を用いることによって対処することができる様々な送信要求を有することができる。
システム100は、集中型AP 104とともに採用することができる。一実施形態においてはすべてのUT 106がAPと通信する。代替実施形態においては、当業者にとって明らかになるように、システムを修正することによって2つのUT間における直接ピアツーピア通信を受け入れることができ、その幾つかの例が以下に示される。指定されたアクセスポイントをサポートする実施形態においては、いずれの局も指定APとしてセットアップすることができる。アクセスは、AP、又はアドホックによって(すなわち、コンテンションに基づいて)管理することができる。
一実施形態においては、AP 104は、イーサネット(登録商標)適合化を提供する。この場合は、ネットワーク102への接続を提供するためにAPに加えてIPルーターを採用することができる(詳細は示されていない)。イーサネットフレームは、WLANサブネットワーク(以下において詳述)を通じてルーターとUTとの間で転送することができる。イーサネット適合化及び接続性は、当業においてよく知られる。
代替実施形態においては、AP 104は、IP適合化を提供する。この場合は、APは、接続されたUTの組に関するゲートウェイルーターとして行動する(詳細は示されない)。この場合は、IPデータグラムをAP 104によってUT 106へ又はUT 106からルーティングすることができる。IP適合化及び接続性は、当業においてよく知られる。
図2は、アクセスポイント104又はユーザー端末106として構成することができる無線通信デバイスの側面を示す。無線通信デバイスは、システム100における採用に適するSTA例である。
プロセッサ210は、通信を実行するためのタスクを含む無線通信デバイスに関する様々なタスクを実行するために採用される。この例においては、プロセッサ210は、本明細書においては“ファームウェア”タスクと呼ばれるタスクを実行する。説明を単純化するため、以下において詳述される実施形態においては、ファームウェアへの言及は、プロセッサ210によって実行される該タスクと、その他の様々な構成要素又はブロックと関連して実行されるタスクと、を含む。プロセッサ210は、汎用マイクロプロセッサ、デジタル信号プロセッサ(DSP)、又は特殊目的のプロセッサであることができる。プロセッサ210は、様々なタスクにおいて援助するために特殊目的のハードウェアと接続することができる(詳細は示されない)。様々なアプリケーションは、外部接続されたプロセッサ、例えば外部接続されたコンピュータ、において又はネットワーク接続を通じて実行することができ、無線通信デバイス104又は106(示されていない)内の追加のプロセッサにおいて実行することができ、又はプロセッサ210自体において実行することができる。
プロセッサ210は、データ及び本明細書において説明される様々な手順及び方法、又はその他の数多くの手順又は方法を実行するための命令を格納するために用いることができるメモリ220と接続された状態が示される。メモリ220は、全体又は一部をプロセッサ220内に埋め込むことができる様々な型の1つ以上のメモリ構成要素を具備できることを当業者は認識するであろう。I/O230は、プロセッサ210に接続された状態で示され、1つ以上の入力及び/又は出力機能を具備することができ、その例は、当業においてよく知られる。
メディアアクセス制御(MAC)プロセッサ240は、プロセッサ210に接続される。以下において詳述される実施形態の多くにおいては、MACプロセッサ240は、ライン速度でのパケットの高速処理を行う。一般的には、より低いレートでの処理、すなわち“ファームウェア”タスクが、典型的にはMACプロセッサ240によって取り扱われる“ライン速度”処理と関連させてプロセッサ210によって実行される。MACプロセッサ240は、送信用データをWLAN120における送信のために物理層(PHY)260に引き渡し、WLAN120において受信されたPHY260からのデータを処理する。プロセッサ210は、物理層データを受信して処理し、(一般的には以下において詳述される例においてMACプロセッサ240と関連して)発信フローに関するパケットを形成することもできる。PHY260に又はPHY260から引き渡されるデータのフォーマットは、無線通信デバイス104又は106によってサポートされる通信システム又は複数の通信システムの仕様に準拠する。
MACプロセッサ240は、ネットワーク102の物理層に関する要求事項に従って接続110を介してデータを受信及び送信する。オプションのネットワークプロセッサ280は、オプションのネットワーク接続110においてネットワーク102の物理層に従って受信及び送信するために採用することができる。ネットワークプロセッサは、データを受信し、いずれかの型のデータフォーマットを用いてMACプロセッサ240にデータを引き渡すことができる。データパケット例が以下においてさらに詳細に説明される(これらの及び代替のデータフォーマットは、当業者によく知られることになるであろう)。これらのデータは、本明細書においてはフローと呼ぶことができる。フローは、異なる特徴を有することができ、フローと関連づけられたアプリケーションの型に基づいて異なる処理を要求することができる。例えば、映像又は音声は、低レーテンシーフローの特徴を有するとみなすことができる(映像は、一般的には、スループットに関して音声よりも厳しい要求を有する)。多くのデータアプリケーションは、映像の場合よりもレーテンシーの影響を受けにくいが、データ完全性に関してはより厳しい要求を有することがある(すなわち、音声は、ある程度のパケット損失に耐えることができ、ファイル転送は、一般的にはパケット損失は許容されない)。
MACプロセッサ240は、フローデータを受信し、そのプロセスは、入力(ingress)と呼ばれ、フローデータパケットをパケットバッファ250に格納する。MACプロセッサ240は、送信又はTXと呼ばれるWLAN120での送信のためにパケットを取り出し、これらのパケットをPHY260に引き渡す。WLAN120において受信又はRXと呼ばれる受信が行われたパケットは、PHY260からMACプロセッサ240に引き渡され、MACプロセッサ240は、これらのパケットをパケットバッファ250に格納する。MACプロセッサ240は、ネットワーク接続110(又はオプションのネットワークプロセッサ280)における引き渡しのためにRXパケットをパケットバッファ250から取り出し、このプロセスは、出力(egress)と呼ばれる。パケットバッファ250の実施形態例が以下において詳述される。以下において詳述される様々な実施形態は、入力、送信、受信、及び出力に関して高速パケット処理を実行するための側面を識別する。
示されている例においては、入力及び出力はネットワーク110に関して識別され、RX及びTXはWLAN120に関して識別される一方で、MACプロセッサ240は、出力又は入力機能、及びあらゆる型の受信又は送信機能とともに動作するために適切に展開することができる。フロー分類をドライバによって行うことができ、該ドライバは、当業においてよく知られるように、プロセッサ210又はネットワークプロセッサ280において、又はその他の適切な構成要素において含めることができる。様々なデータ型、フォーマット、フロークラス等のMAC処理を許容するために様々なドライバを採用することができる。
WLANに関連する制御及びシグナリング(すなわち、802.11又はその他の基準)は、APと様々なUTとの間でも通信することができる。物理層(PHY)プロトコルデータユニット(PPDU)においてカプセル化されたMACプロトコルデータユニット(MPDU)が、PHY260に引き渡される又はPHY260から受け取られる。MPDUは、フレームと呼ばれることもある。単一のMPDUが単一のPPDUにおいてカプセル化されるときには、PPDUはフレームと呼ばれることもある。代替実施形態は、いずれかの変換技術を採用することができ、代替実施形態においては用語が異なることがある。様々なMAC IDに対応するフィードバックを様々な目的でPHY260から戻すことができる。フィードバックは、あらゆる物理層情報を具備することができ、チャネル(ユニキャストトラフィック/パケットに加えてマルチキャストを含む)に関するサポート可能なレート、変調フォーマット、及び様々なその他のパラメータを含む。
PHY260は、いずれかの型のトランシーバであることができる(及び受信機及び送信機の両方を含むことができるが、代替実施形態においてはいずれも採用することができる)。一実施形態においては、PHY260は、多入力多出力(MIMO)又は多入力単出力(MISO)インタフェースとともに動作可能な直交周波数分割多重(OFDM)トランシーバを含む。
MIMO、及びMISOは、当業者には既知である。“FREQUENCY-INDEPENDENT SPATIAL-PROCESSING FOR WIDEBAND MISO AND MIMO SYSTEMS”(広帯域MISO及びMIMOシステムに関する周波数から独立した空間処理)という題名を有し、本特許出願の譲受人に譲渡されており、本明細書において参照されることによって本明細書に組み入れられている同時係属米国特許出願一連番号10/650,295(出願日:2003年8月27日)においてOFDM、MIMO及びMISOの様々なトランシーバ例が詳述される。代替実施形態は、単入力多出力(SIMO)又は単入力単出力(SISO)システムを含むことができる。
PHY260は、アンテナ270A乃至Nと接続された状態が示される。様々な実施形態においてあらゆる数のアンテナをサポートすることができる。アンテナ270は、WLAN120において送信及び受信するために用いることができる。
PHY260は、1つ以上のアンテナ270の各々と通信する空間プロセッサを具備することができる。空間プロセッサは、各アンテナに関して独立して送信のためにデータを処理すること又は全アンテナにおける受信信号をまとめて処理することができる。独立した処理の例は、チャネル推定値、UTからのフィードバック、チャネル反転、又は当業において知られる様々なその他の技術に基づくことができる。処理は、様々な空間処理技術のうちのいずれかを用いて実行される。この型の様々なトランシーバは、所定のユーザー端末への又は所定のユーザー端末からのスループットを向上させるためにビーム形成技術、ビーム操作技術、固有操作技術、又はその他の空間技術を利用して送信することができる。OFDMシンボルが送信される幾つかの実施形態においては、空間プロセッサは、各々のOFDM副搬送波(トーンとも呼ばれる)、又はビンを処理するための副空間プロセッサを具備することができる。
システム例においては、AP(又はUT等のあらゆるSTA)は、Nのアンテナを有することができ、UT例はMのアンテナを有することができる。従って、APとUTとのアンテナ間にはM×Nの経路が存在する。当業においては、これらの複数の経路を用いてスループットを向上させる様々な空間技術が知られる。空間時間送信ダイバーシティ(STTD)システム(“ダイバーシティ”とも呼ばれる)においては、送信データがフォーマット化及び符号化され、単一のデータストリームとして全アンテナを通じて送信される。Mの送信アンテナ及びNの受信アンテナが存在することで、形成可能なMIN(M,N)の独立したチャネルが存在することができる。空間多重化は、これらの独立した経路を利用し、送信速度を上昇させるために独立した経路の各々において異なるデータを送信することができる。
APとUTとの間におけるチャネルの特性を学ぶための又は前記特性に合わせて適合化するための様々な技術が知られる。各送信アンテナからは一意のパイロットを送信することができる。この場合においては、パイロットは、各受信アンテナにおいて受信及び測定される。次に、送信の際に用いるためにチャネル状態情報フィードバックを送信デバイスに戻すことができる。測定されたチャネル行列の固有分解を行ってチャネル固有モードを決定することができる。受信機におけるチャネル行列の固有の分解を回避する代替技術は、パイロット及びデータの固有操作を用いて受信機における空間処理を単純化することである。
従って、現在のチャネル状態に依存し、システム全体の様々なユーザー端末に送信するために様々なデータレートを利用可能である。PHY 260は、APとUTとの間における物理的リンクに関していずれの空間処理が用いられているかに基づいてサポート可能なレートを決定することができる。この情報は、MAC処理において用いるためにフィードバックすることができる。
一側面においては、アクセスポイント及びユーザー端末の両方を含む無線通信デバイスにおけるMAC処理をサポートするための単一のASIC特定用途向け集積回路(ASIC)が提供される。図3及び4は、ユーザー端末106及びアクセスポイント104において用いるために構成された該ASIC 310を概念的にそれぞれ示す。
図3においては、MACプロセッサASIC 310は、ユーザー端末106に関する構成例が示される。この構成においては、上述されるMACプロセッサ240は、ハードウェアテーブル320に接続される。ハードウェアテーブル320は、とりわけ、局内においてアクティブである各フローに関するパラメータを含む。従って、以下において例が詳述される様々なMAC処理機能中に、MACプロセッサ240は、ハードウェアテーブル320にアクセスしてフローごとのパラメータ325を取り出す。MACプロセッサ240は、SRAM330にも接続される。この構成においては、SRAM330は、パケットバッファ250の機能を実行するように適合化される。MACプロセッサASIC 310は、様々なその他の構成要素を具備することができ、その例が以下において詳述される。この実施形態においては、パケットバッファ250はMACプロセッサ310内に常駐することが注目される。ハードウェアテーブル320は、分類することのみを目的として別個のブロックとして示されることに注目すること。様々な実施形態においては、ハードウェアテーブル320及びSRAM330は、両方とも、MACプロセッサ320内に含めることができる。
図4は、アクセスポイントとして用いるように構成されたMACプロセッサASIC310を描く。この構成は、より多いフロー数及び/又はより高いスループットをサポートできる局、いわゆるスーパーステーション、に関しても用いることができる。以下において詳述される例においては、スーパーステーションとアクセスポイントの構成は、単純にアクセスポイント又はアクセスポイント構成と呼ぶことができる。この実施形態においては、MACプロセッサASIC 310は、図3に示されるように、MACプロセッサ240と、ハードウェアテーブル320と、SRAM330と、を具備する。繰り返すと、これらの構成要素は、例示することのみを目的として別々に示されており、これらの構成要素のうちの1つ以上をMACプロセッサ240内に含めることができる。この構成においては、ハードウェアテーブル320は、MAC処理に関して用いられるフロー別パラメータをすべて含んでいるわけではない。この場合は、フロー別ポインタ335がハードウェアテーブル320に含まれ、各々のポインタは、SRAM330に格納される各々の関連づけられたフロー別パラメータ325を指し示す。希望される場合は、幾つかのフロー別パラメータをハードウェアテーブル320に格納できることに注目すること。示される同じハードウェア構成要素を具備する同じプロセッサASIC310を、異なる要求をサポートするためにいずれかの構成に合わせて適合化できることに注目すること。この例においては、SRAM330は、STAモードにおけるパケットバッファ250であることからアクセスポイントモードにおけるフロー別パラメータ325のレポジトリであることに目的が変更される。従って、MACプロセッサ240は、パラメータに関してハードウェアテーブル320にアクセスし、構成に依存して、これらのパラメータを取り出すか又はあるインダイレクション(indirection)レベルに従ってSRAM330からこれらのパラメータを取り出す。(例えばプロセッサ210によって実行される)ファームウェアは、MACプロセッサASIC310の様々な構成要素が第1のモード(局モード)又は第2のモード(アクセスポイントモード)において実行するように構成することができる。モードを選択するための様々な技術は、当業においてよく知られる。例えば、現在の構成を1つ以上の構成要素に示すためにレジスタ設定、モード選択信号、等を用いることができる。さらに、ファームウェアは、選択された構成に依存して、ハードウェアテーブル320及びSRAM330に異なる形で入れることができる。
引き続き図4において、パケットバッファ250の機能を実行するために外部メモリ、この例においてはSDRAM340、が含まれていることがわかる。従って、アクセスポイントモードにおいては、フロー別パラメータを格納するためにSRAM330を用いることによってより多くの数のフローをサポートすることができ、従って(ハードウェアテーブル320はSRAM330よりも小さいと仮定した場合に)ハードウェアテーブル320のみを用いてサポート可能である。SRAM330のサイズは、局モードにおける無線通信デバイスに関するパケットバッファの要求を受け入れるようなサイズを選択することができる。一実施形態においては、このサイズは、アクセスポイントによってサポートされるフロー数に関して必要なすべてのフロー別パラメータを格納するのにも適する。代替実施形態においては、SRAM330は、本来であればパケットバッファに関して必要になるよりも大きいSRAMのサイズを要求するより多いフロー数をサポートするようなサイズにすることができる。SDRAM340は、アクセスポイントによってサポートされるフロー数を受け入れるようなSDRAMを選択することができる。当業者は、ハードウェアテーブル320、SRAM330、及びSDRAM340に関して適切なサイズをどのようにして選択するかを認識するであろう。
従って、単一のMACプロセッサASIC 310は、複数のモードをサポートするように設計することができる。ハードウェア構成要素は、異なる機能を提供するために各モードにおいて再使用することができる。ハードウェアテーブル及びパケットバッファの使用に関するより詳細な例が以下に示される。図3に示されるように構成可能な単一のMACプロセッサASIC310を採用することは、より小さいサイズ及びより低いコストを考慮するものである。外部のSDRAM340を追加し、MACプロセッサASIC310を再構成することによって、同じMACプロセッサASIC310を、より高い性能のデバイス、例えばアクセスポイント又はスーパーステーション、において用いることもできる。所定の構成の性能上のニーズに依存して様々な異なるサイズのSDRAM340を選択することができる。
図5は、STA104又はAP106等の無線通信デバイスのより詳細な実施形態例を示す。この例においては、非常に様々なパケット特長例に関するMAC処理が、1つのMACプロセッサを用いて説明される(おおまかに説明される)。代替実施形態においては、異なる型のパケットに関するMAC処理機能は、2つ以上のMACプロセッサに分割することができる(以下において代替実施形態例が図48及び49に関して詳述される)。
上述されるように、プロセッサ210は、ファームウェアタスクを実行するために配置される。該配置において典型的であることができる一組のサポート機能例が示される。様々な代替実施形態が当業者にとって明確になるであろう。プロセッサ210は、命令バス506を介して命令SRAM502及びブートROM504と通信する。これらのメモリは、プロセッサ210におけるファームウェア処理において用いるためのよく知られた命令の格納及び取り出しを行うために用いることができる。I/O機能例及びサポート機能例がバス514に接続された構成要素によって示される。この例においては、様々なタイミング機能を実行するためのタイマー508を採用することができる。世界非同期受信機送信機(UART)510を採用することができる。他のI/O例は、12Cインタフェース512である。この例においては、様々な補助構成要素が、バス514を介して、プロセッサ210に接続されたベクトル割り込みコントローラ(VIC)516に接続される。従って、タイミング割り込み、I/O割り込み、及び関連する処理を、採用された関連機能に従ってプロセッサ210によって実行することができる。当業においては、様々な型のプロセッサと接続するための様々な代替機能がよく知られており、当業者によって知られるであろう。ブリッジ518は、バス514に取り付けられた構成要素をバス520に接続されたその他の構成要素と接続する。従って、バス520に接続された様々な構成要素は、プロセッサ210を含み、これらの各々の構成要素に引き渡すこと又はこれらの各々の構成要素から受信することを目的としてバス514上においてデータを通信することができる。この例においては、バス520DMAコントローラへのアクセスを制御するためのバスアービター522が採用され、バス526に取り付けられた追加構成要素は、ダイレクトメモリアクセス(DMA)コントローラ524と、データSRAM526と、バススレーブインタフェース528と、を含む。バススレーブインタフェース528は、以下においてさらに詳細に説明される、バス520とフォーマット化論理及びmux570との間における導路を提供する。説明される構成要素は、図2に関して上述される様々な構成要素、例えばプロセッサ210、メモリ220、及びI/O230、と概念的に識別することができる。
SDRAM340を除く図5の構成要素は、図3及び4において上述されるようなMACプロセッサASIC 310の1つの実施形態例の一部分を形成する。これらの構成要素は、図3において詳述されるSTA 106構成として又は図4において詳述されるアクセスポイント又はスーパーステーション構成として用いるために構成することができる。前説明に鑑みて、図5において詳述される様々な構成要素は、MACプロセッサ240及びハードウェアテーブル320の一部分を形成することができることがわかる。説明される様々な構成要素は、異なる機能を果たすように異なるモードで構成することができる。プロセッサ210及び補助構成要素例502乃至528等の様々な構成要素は、MACプロセッサASIC 310の実施形態例において組み入れることができる場合とできない場合がある。
プロセッサ210、及び示されている様々なその他の構成要素は、バス520を介してMACプロセッサの構成要素と通信できることに注目すること。この例においては、MACプロセッサは、下位MACコア(lower MAC core)540及びH2Wプロセッサ530として示されるホスト−WLANサブシステムを含む2つの主要機能を具備する。これらの構成要素の実施形態例が以下においてさらに詳細に説明される。このように構成要素を様々な部分に分離することは、ほんの一例であり、当業者は、本明細書における教義に照らして明確になるように、代替実施形態において説明される様々なプロセス及び機能を容易に採用するであろう。
SRAM560は、MUX 554に接続されるSRAMインタフェース558を介してアクセスすることができる。Mux554は、メモリアービター556への接続又はメモリアービター552への接続をSRAMインタフェース558への入力として選択する。メモリアービター552は、要求を受け取り、バス520、及びバス550における構成要素を含む様々なソースからのSRAM560へのアクセスに関して仲裁する。この例においては、バス550は、低位MACコア540とメモリ(SRAM)560との間における直接結合を提供する。これらの構成要素の間にもバス520を介しての経路が存在することに注目すること。この例においては、時間の影響を受けやすいデータを下位MACコア540から取り出すか又は下位MACコア540に格納するためにSRAM560によってアクセス性能を保証するための追加バス550が提供される。図3及び4において説明されるように、SRAM560は、一構成においてはパケットバッファとして及び他の構成においてはフロー別パラメータのレポジトリとして働くことができる点に注目すること。
下位MACコア540は、PHY260への送信のためにパケットを引き渡すために及びPHY260からの受信されたパケットを処理するために用いることができるMAC/PHYインタフェース545に接続される。下位MACコア540内の構成要素の実施形態例が以下においてさらに詳細に説明される。
H2Wプロセッサ530は、入力パケットを処理し、以下において実施形態例がさらに詳細に説明される。一実施形態においては、入力は、着信パケットの処理から切り離すことができる。この場合は、入力パケットは、ライン速度で(すなわち、入力速度で)パケットバッファ内に書き込むことができる。これらのパケットの処理は、のちにパケットバッファから読み出すことによって行うことができる。この分離は、処理速度が入力ライン速度と異なることを可能にする。この手法の欠点は、パケットが読み出されて処理され、パケットバッファ内に戻されて送信待ち状態にしなければならないため、パケットバッファに対する余分の読み出し及び書き込みが存在することである。このメモリ帯域幅に関する犠牲は、一定の実施形態においては受け入れ可能である。下例において示される代替実施形態は、入力パケットのインライン処理に備えるものである。これらの実施形態例においては、MAC処理は、各入力パケットがライン速度で送信するためにフォーマット化され、パケットバッファへの書き込みが1回である(その後に、パケット送信時間に達したときに読み出しが行われる)ことを考慮する。第2の場合においては、メモリ帯域幅に対する負担が第1の場合よりも軽減される。当業者は、様々な実施形態において、いずれの手法も本明細書において教義される様々な側面と容易に適合化するであろう。
SDRAM340は、この実施形態においてはMACプロセッサASIC 310への外部構成要素として示される。このことは、上図3及び4の説明に合わせるものであり、より多いフロー数をサポートする必要があり(その結果、アクセスポイント又はスーパーステーション等のパケットバッファスペースを増大させる必要性がより高くなる)無線通信デバイスを、単一のより低コストのMACプロセッサASIC 310及びオプションの外部メモリ、例えばSRAM 340、によって受け入れることができる。SDRAM340は、メモリアービター556に結合されるSDRAMインタフェース562を介してアクセスことができる。代替実施形態においては、SDRAM340は、MACプロセッサASIC 310内に組み入れることができる。図5に示されるような構成要素の割り当ては、1つの例であるにすぎない。示されるいずれの構成要素も、各ASICのエリア上の要求事項及び希望される性能に依存して、単一のASICにおいて組み入れることができ又は1つ以上の外部デバイスに組み入れることができる。
この例においては、パケットの入力及び出力は、2つの外部インタフェース例のうちの1つを通じて行われる。当業者は、代替インタフェースをこれらのインタフェースに加えて又はこれらのインタフェースの代わりに採用できることを認識するであろう。この例においては、これらのインタフェースのうちの1つ以上と通信中の外部(又は内部)デバイスへのパケットを受信してハンドオフするためのSDIOインタフェース582及びPCIインタフェース584が採用される。SDIOインタフェース582及びPCIインタフェース584は、MUX580を介して選択される。
様々な速度のインタフェースを受け入れること、及び着信パケット及び発信パケットの格納及び処理に関する要求が様々であることに備えることを目的として、SRAM 560及びSDRAM 540等のメモリにアクセスする際の混雑を緩和するためのレートマッチングと待ち行列、及びH2Wプロセッサ530及び下位MACコア540等のMAC処理機能を実行するためのFIFO、mux、及びフォーマット化論理を採用することができる。例えば、入力インタフェース及び出力インタフェースは、WLANのスループット能力と比較してより高速で動作することができる。着信フローは、バースト性でさらに高速の場合がある。プロセッサ210又はバス526に接続されたその他の構成要素から受信された情報は、さらに他の速度で到着する場合がある。以下においてさらに説明されるように、H2Wプロセッサ530及び下位MACコア540は、アクセス要求を生成し、様々なタスクに関する処理が完了されるのに応じてこれらの要求の結果得られたデータを取り出す又は格納する。従って、この例においては、FIFO572は、フォーマット化論理とmux570との間に及びフォーマット化論理とmux574の間に配置することができる。一例においては、入力機能及び出力機能(例えば、SDIOインタフェース582又はPCIインタフェース584)へのインタフェースのために一組のFIFO572、フォーマット化論理及びmux570からフォーマット化論理及びmux574へのデータをバッファリングするためのFIFO572、及び反対方向のデータをバッファリングするための他のFIFO572を採用することができる。H2Wプロセッサ530への又はH2Wプロセッサ530からのデータをサポートするために他の一組のFIFO572、各方向に1つ、を採用することができる。下位MACコア540と関連して用いるために他の同様の組を採用することができる。バス/スレーブインタフェース528を介してアクセスされる、バス520上の構成要素間におけるインタフェースのためにさらに他の同様の組を採用することができる。当業者は、この構成は一例にすぎないことを認識するであろう。様々な代替実施形態を採用することが可能であり、このことは、本明細書における教義に照らして当業者に明確になるであろう。以上のように、図5に示される無線通信デバイス104又は106の実施形態例は、様々な構成要素の1つの可能な相互接続を例示する役割を果たし、その詳細が以下において説明される。これらの構成要素及び/又は追加の構成要素(示されない)の部分組を用いた非常に多数の代替構成を同じ適用範囲内において採用することができる。
パケットバッファ及びメモリ管理
図6は、パケットバッファ250の実施形態例を示す。本明細書において詳述される様々な実施形態例においては、パケットバッファ250は、図6に示されるように、MACプロセッサ240内におけるパケット処理に関する様々な機能を実行するために役立つデータ構造及び関連する連結リストを示す。本明細書において詳述される様々な実施形態は、該構造を要求せず、さらに代替パケットバッファを代替実施形態において採用できる一方で、本明細書全体を通じて詳述される実施形態は、これらの様々な機能におけるこれらの連結リスト及びデータ構造の使用について例示するためにこれらの連結リスト及びデータ構造を利用する。さらに、パケットバッファ、例えば図6において説明されるパケットバッファ、を、本明細書において詳述される機能に加えて様々な代替機能において用いるために採用することができる。当業者は、相対的に高速のパケット処理が希望される実施形態を含む様々な実施形態においてこのパケットバッファ及び構成要素及びその副構成要素を容易に適合化するであろう。パケットバッファ例250は、図6に示されない追加のデータ構造を含むことができ、これらの追加データ構造は、後述される図7においてさらに詳細に説明される。
この例においては、各パケットは、本明細書においてはノード610と呼ばれる第1のデータ構造及び本明細書においてはチャンク620と呼ばれる第2のデータ構造の2つの型のデータ構造を用いてパケットバッファ250内に格納される。各パケット、又はパケットフラグメント(802.11(g)及び(e)において説明されるようなフラグメンテーションが採用される場合)は、1つのノード610と、1つ以上のチャンク620と、を含む。パケットデータを格納するために要求されるチャンク数は、パケット又はフラグメントのサイズに依存して異なる。従って、パケットは、第1のチャンクを指し示すノードを具備する連結リスト構造としてパケットバッファ250内に常駐し、追加チャンクが要求されるときには、連結リストは、追加チャンクを具備し、各チャンクは、後続チャンク(最終チャンクを除く)を指し示す。
ノードとチャンクとの間における該セグメンテ−ションの1つの利点は、制御決定に関して非常に重要な情報をノード内に保存することができ、データ自体は相対的により大きいチャンク内に保存されることである。このことは、パケット全体のアクセスを要求せずに制御処理において各々のパケットを代表するノードが用いられることを考慮するものである。
さらに、着信中の入力パケット、及び出力待ちのパケットは、一般的には、1つ以上のフローと関連づけられる。示されているノード及びチャンク構造は、パケットバッファ内におけるパケットの待ち行列の効率的な形成も容易にし、各待ち行列は、各々のフローと関連づけられる。この一般的構造は、図6において示され、様々なノード及びチャンクを具備する単一の待ち行列の例を有する。この例においては、ノード610A−Nは、フローに関する待ち行列と関連づけられた連結リストを形成する。該待ち行列は、待ち行列先頭ポインタ630によって識別される先頭を有し、待ち行列末尾ポインタ640は、待ち行列内の最後のノードを識別する。この例においては、待ち行列内にはNのパケットが存在し、各々のパケットは、該ノードと関連づけられたノード610を有する。各ノード610は、例示されるような一連のチャンク620A乃至Mを具備する。あらゆる数のチャンクを単一のノードと関連づけることができる。この図に示される残りのチャンクは、単にラベルが付される620。当業者は、様々なサイズのチャンクと同様に様々なサイズのノードを採用できること認識するであろう。実施形態例においては、チャンクは512バイトである。従って、パケット例は通常は2キロバイト未満であるため、各パケットに関して多くて4つのチャンク(典型的にはこれよりも少ない)が必要になり、パケットヘッダー及び関連づけられたその他の情報を含む。代替実施形態においては、あらゆるパケットサイズを受け入れるチャンクサイズを採用することができる。
この実施形態例においては、メモリ内では制御及びデータが分離される。送信及び受信目的のために、制御構造に関して幾つかの処理が必要になる場合がある。しかしながら、データペイロードに関して、(WLANからの入力又は受信時点において)メモリ内への1回のみの書き込みが行われ、(WLANにおける送信時点又は外部インタフェースを介しての出力時点に)そのメモリからの1回の読み出しが行われる。このように、メモリ内への及びメモリからの転送が相対的に効率的であるため、メモリ帯域幅に関する要求を軽減させることができる。
ノード例610が図6に示される。ノード610は、待ち行列内の後続ノードにリンクするために用いられる次ノードポインタ612を具備する。長さフィールド614及びシーケンス番号616が含められる。これらのフィールドは、以下においてさらに説明されるようにパケットを処理時に有用であり、チャンク620に含まれているデータにアクセスするか又は該データを移動させずにMAC処理が実行されることを考慮する。例えば、長さフィールドは、TXOPにおいてパケットを統合するときの統合に関して有用である。シーケンス番号は、ブロックACK要求を送信時に有用である。一般的には、処理に関して有用なあらゆるパケット情報を代替ノード実施形態に加えることができる。ノード610は、パケットデータを含む第1のチャンクを指し示すチャンクポインタ618も含む。
この構造は、あらゆる長さの待ち行列を生成する柔軟性を可能にし、メモリパケットバッファの全体的なサイズのみによって制限される。従って、様々な異なるフロー型をサポートすることができ、サポートされるフロー数を固定する必要がない。例えば、少ない数のパケットを要求する幾つかのフローは、より多い数のパケットを要求するフローとともに格納域を割り当てることができ、従って、所定の数のフローをサポートするためにより小さいパケットバッファサイズを採用することができる。代替として、所定のメモリサイズに関して様々な数のフローを受け入れることができる。理解できるように、待ち行列は、独立して拡大又は縮小することができ、さらに、ノード及びチャンクはフロー又はパケットによってそれぞれ再使用できるため、構造は、高い柔軟性を有して非常に効率的なメモリ管理が可能である。
チャンク例620も同様に示される。チャンクデータ622は、パケットを具備し、ヘッダフィールド、フレーム検査シーケンス、等を含む。連結リスト内に次のチャンクが存在する場合は該次のチャンクを指し示すための次チャンクポインタ624が含められる。
一実施形態においては、チャンクは固定サイズである。この固定サイズは、パケットバッファメモリがチャンクに割り当てられた固定のメモリ部分を具備することを考慮するものである。連結リスト構造は、あらゆるチャンクをあらゆるパケット連結リストにおいて用いることを可能にする。パケットは到着して出て行くため、追加のメモリ管理オーバーヘッド(例えば、サイズが異なるパケットに関するスペースの再割り振り、等)が要求されずに簡単にチャンクを再度用いることができる。この構造は、一般的にはチャンクは1回だけパケットバッファに書き込むことができ、さらにこれらのチャンクはWLANにおける送信又は出力先へのハンドオフのための準備が完了するまでとどまるという点で効率的な処理を考慮するものである。パケットは、単純にポインタを書き換える(すなわち、連結リストを変更する)ことによって待ち行列内において移動させること又は新しい待ち行列に移動させることも可能である。このことは、パケットを再送信のために処理するときに有用である。これらの構造の使用は、以下においてさらに詳細に説明されるような追加の効率に備えるものである。各連結リストは、待ち行列内の最後のノード又はパケット内の最後のチャンクに関して様々なリスト終了子(terminator)のうちのいずれかを用いることができる。実施形態例においては、連結リスト内の第1の及び最後のノードは、ヘッダー及び末尾ポインタによって示され、チャンクポインタは、パケット内の最後のチャンクを示すようにスレッドされる。代替実施形態においては、パケット長及びパケットシーケンス番号とともにチャンク数をノードヘッダー内において加えることが望ましい場合がある。可変のチャンクサイズを含む代替実施形態も構想されている。
図7は、パケットバッファ例250をさらに示す。メモリの隣接するチャンクを様々なデータ構造型に割り当てることができるが、この割り当ては必須事項ではない。上述されるように、セグメント730の一部分をノードに関して割り当てることができ、セグメント740は、チャンクに関して割り当てることができる。実施形態例においては、上述されるように、これらのセグメントの各々は、あらゆるパケット及び/又はフローに関して再度用いることが可能な隣接するメモリスペースであり、サイズが固定されたノード及びチャンクを含む。さらに、フリーノードポインタリスト710及びフリーチャンクポインタリスト720が維持される。当業者にとって明らかになるように、フリーポインタリストに関する様々なデータ構造を採用することができる。一例においては、ノードポインタ及びチャンクポインタを各々のポインタリスト710又は720にプッシュ及びポップすることができる。これらのリストは、例えば、環状バッファであることができる。ポインタがポップされて新しいノード又はチャンクが形成された時点で、そのポインタは、ノード又はチャンクが解放されるまで使用状態になり、解放された時点で、ポインタを将来用いるためにプッシュバック(push back)することができる。
図8は、例えば本明細書において詳述される実施形態例の場合のように、MACプロセッサ内において採用することができる追加の構成要素を示す。これらの構成要素は必須ではないが、使用中のメモリの型が有する特性に起因して一定の状況において利点を提供することができる。例えば、一般的にはSDRAMアクセスと関連するレーテンシーが存在する。さらに、小規模な転送を行うときに(すなわち、単一のノード又はチャンクポインタを取り出すか又は格納する際に)非効率的になる場合がある。ローアクセス、カラムアクセス、等を組み入れるときに一定の型のSDRAMを用いることで、オーバーヘッドサイクルが実際のデータ転送サイクルを圧倒する可能性がある。長い遅延を防止するため、幾つかのポインタをMAC処理において用いるために一度に取り出すための様々なキャッシュを採用することができる。図8は、これらのキャッシュのうちの幾つかに関する例を示す。これらのキャッシュの一部又は全部は、様々な代替実施形態において採用することができる。本明細書において詳述される実施形態において用いられるキャッシュ例は、TXフリーノードポインタキャッシュ810と、TXフリーチャンクポインタキャッシュ820と、RXフリーノードポインタキャッシュ830と、RXフリーチャンクポインタキャッシュ840と、を含む。パケットに関して上述されるデータ構造は、受信パケットとともに用いるために単純化することができ、その実施形態例が以下において図33に関してさらに詳細に説明される。一般的には、これらのキャッシュ810乃至840の各々は、効率的にするためにパケットバッファ250内の各々のノードポインタリストから1つ以上のポインタを受け取る。パケットバッファから複数の各々のポインタを一度に取り出すことができる。この例においては、複数のポインタを各々のリストからポップすることができる。これらのポインタは、各々のキャッシュ内に入れられ、様々なMAC処理構成要素において用いるために各々のキャッシュから単一のポインタをポップすることができる。以下において詳述される様々な実施形態例を通じてポインタ及びその各々のキャッシュの使用がさらに示される。
図9は、パケットバッファ内にパケットを書き込んで待ち行列を生成するための方法900の実施形態例を示す。待ち行列は、データ構造、この例においては連結リスト、を用いて形成することができる。待ち行列は、アレイとして形成することもできる(以下において詳述されるように、一例がノードアレイ3330として示される)。この方法は、上記の図6及び7において説明されるようなパケットバッファと関連させて採用するのに適する。方法900は、入力パケットをパケットバッファに書き込むために用いることができる技術例を示す。出力に関するハンドオフ処理を待つために受信パケットをパケットバッファに書き込むために同様の技術を用いることができる。ハンドオフに関する実施形態例が以下においてさらに詳細に説明される。オプションとして、ポインタキャッシュ(すなわち、図8において説明されるような810乃至840)も採用することができ、さらに新しいポインタに関する主ソースになることもできる。当業者にとって明らかになるように、キャッシュを有する又は有さない様々な実施形態を採用することができ、この方法は、あらゆる該構成とともに用いることができる。
910において、パケットが受け取られる。決定ブロック912において、パケットと関連づけるためにノードをポップする。決定ブロック914において、このパケットが各々の待ち行列における最初のパケットである場合は、916に進み、新しいパケットと関連づけられたノードを指し示すように先頭待ち行列ポインタを更新する(例えば、図6に示される待ち行列先頭ポインタ630)。次に、918に進む。決定ブロック914において、このパケットが各々の待ち行列における最初のパケットでない場合は、918に進む。
918において、チャンクポインタをポップする。繰り返すと、ノード及びチャンクをポップする(各々のポインタをポップすることの省略表現)ことは、パケットバッファから直接、そして特にフリーノードポインタリスト又はフリーチャンクポインタリストからそれぞれ直接行うことができる。実施形態例においては、ポインタは、(枯渇するのに応じて補給することが必要になる)送信フリーノードポインタキャッシュ810及び送信フリーチャンクポインタキャッシュ820からポップされる。920において、パケットのシーケンス番号及び長さをノードに入れ、918において取り出されたチャンクポインタを(例えば、図6に示されるノード610等のノードフォーマットを用いて)ノードのチャンクポインタフィールドに挿入する。922において、チャンクにパケットデータを充填する。一例においては図6に示されるようなチャンク620を採用することができる。
決定ブロック924において、パケットが第1のチャンク内において適合する大きさよりも大きいため他のチャンクが必要である場合は、926に進む。大きくない場合は、932に進む。926において、新しいチャンクポインタをポップする。928において、新しいチャンクポインタを前のチャンクの次チャンクポインタフィールド内に書き込む。930において、新しいチャンクにパケットデータを充填する。実施形態例においては、パケットデータは、一連のチャンク内に順次書き込まれる。次に、決定ブロック924に戻り、さらに他のチャンクが必要になるかどうかを決定する。このループは、パケットが1つ以上のチャンク内に完全に書き込まれるまで繰り返すことができる。
932において、パケットを書き込むプロセスが完了される。パケットと関連づけられたノードをスレッドして適切な待ち行列に入れる。例えば、このことは、末尾ノードの次ノードポインタ内にノードアドレス、すなわち912において取り出されたポインタ、を書き込むことによって達成させることができる。この例においては、末尾ノードは、待ち行列末尾ポインタ(例えば、図6に示される待ち行列末尾ポインタ640)によって識別される。934において、末尾モードになる現在のノードを指し示すように末尾ポインタを更新する。
決定936において、他のパケットが受け取られた場合は、912に戻り、プロセスは繰り返すことができる。他のパケットがパケットバッファ内に書き込む準備が整っていない場合は、プロセスは停止することができる。説明を明確化するため、該当する待ち行列及びその関連づけられた先頭ポインタと末尾ポインタが導き出される関連フローとパケットを関連づけることに関する詳細は省略される。パケットをフローと関連づける実施形態例が以下においてさらに詳細に示される。
H2Wプロセッサ及び入力ポリシング
図10は、H2Wプロセッサ530等のホスト−WLANサブシステムの実施形態例を示す。パケットは、様々なソースから受け取ることができる。この例においては、2つのソースが例示される。この実施形態例は、H2Wプロセッサ530内に含めることができる構成要素の部分組を示す。図10に示される構成要素の一部は、H2Wプロセッサ530に含まれていない図5の構成要素に対応することができ、説明を明確するために示されている。示されている構成要素及びそのパーティションは、例示することのみを目的とするものであることを当業者は認識するであろう。この例における典型的入力パケットは、図5に示されるSDIOインタフェース582又はPCIインタフェース584等の外部インタフェースから来る。他の入力されるパケット例は、図5に示されるように、プロセッサ210又はバス520に接続されたその他の構成要素から来ることができる。外部インタフェースパケットは、外部インタフェース1006を介してH2Wプロセッサ530に到着する。例えばバス520からのパケットは、プロセッサインタフェース1002を介して到着することができる。1つ以上のパケットを処理目的で保持するためにFIFOを採用することができる。例えば、FIFO1004及び1008は、プロセッインタフェース1002又は外部インタフェース1006からそれぞれ受け取られたパケットを保持するために採用することができる。ブロック1004は、WLANにおいて送信する必要があるプロセッサからの管理パケット及び制御パケットを保持するために採用することができる。以下において図48に関して詳述される代替実施形態においては、レガシーパケット及び(例えば)その他のより低いスループットのパケットはプロセッサ210(又は他の代替MACプロセッサ)において処理され、従ってプロセッサインタフェース1002は必要ないため、該インタフェース及びその関連構成要素は省略することができる。
この例においては、トラフィックストリーム識別子(TSID)と関連する行先MACアドレスがフローを一意で識別するために用いられる。代替実施形態においては、フローマッピングのためにその他のメカニズムを採用することができる。上述されるように、典型的には、ファームウェア又はその他の何らかの外部プロセッサにおいて実行中であることができるフローの分類を行うためのドライバが存在する。ドライバは、行先アドレス(DA)、TSID、及びソースアドレスを有するMACアドレスを生成することができる。
この例においては、DA及びTSIDは、フローを識別するために用いることができる。DMAC−TSIDは、DMAC−TSIDに対応してフローマッピングブロック1020に引き渡され、フローマッピングブロック1020からフローIDが戻される。
フローマッピングブロック1020の実施形態例は、所定の識別情報からフローIDを決定するためにあらゆる型のルックアップ又はその他の機能を用いることができる。一例が図10Bに示される。
実施形態例においては、上述されるように、ファームウェア対話(interaction)をライン速度処理から切り離すことが望ましい。しかしながら、ファームウェアは、フローマッピング用テーブルを生成するのに非常に適する場合がある。ファームウェア対話を切り離すために、2つのシャドーフローテーブル、テーブル1 1092及びテーブル2 1096、が採用される。H2Wプロセッサ530は、スイッチ1090によって選択された一方のシャドーテーブルを利用し、ファームウェアは、スイッチ1099によって選択された他方のシャドーテーブルを更新する。従って、ファームウェアが一方のテーブルを更新して他方のテーブルがMAC処理に関して用いられるピンポン技術を採用することができる。各シャドーフローテーブル1092又は1096は、対応するフローIDを有するDMAC−TSIDエントリのリストを具備する。シャドーフローテーブル1 1092は、フローID 1094A−Nと関連づけられたDMAC−TSID 1093A−Nを具備する。シャドーフローテーブル2 1096は、関連づけられたフローID 1098A−Nを有するDMAC−TSID 1097A−Nを具備する。従って、フローマッピングブロック1020は、アクティブに選択されたシャドーフローテーブルにDMAC−TSIDを引き渡し、フローIDが戻される。実施形態例においては、フローIDの高速探索を行うために、2進数探索が行われる。ファームウェアは、2進数探索を容易にするためにDMAC−TSIDフィールドを順に整列させるのに非常に適する。当業者は、代替実施形態において代わりに用いることができる代替フローマッピング手順を認識するであろう。
次に図10Aに戻り、フローIDがTXフロー状態テーブル1030に引き渡され、その実施形態例が以下において図11に関して詳細に説明される。TXフロー状態テーブル1030は、各フローに関する様々なパラメータを具備する。TXフロー状態テーブル1030の物理的位置は、図3及び4に関して上述されるように変化することができる。例えば、一構成においては、TXフロー状態テーブルは、H2Wプロセッサ530におけるハードウェアテーブル内に保管することができる。代替実施形態においては、ハードウェアテーブルは、詳細が示されていない下位MACコア540に常駐することができ、両ブロック530及び540は、同じハードウェアテーブルを共有することができる。又は、各ブロック530及び540は、図3及び4において概念的に示されるようなハードウェアテーブルの一部分を維持することができる。引き渡されたフローIDから、フローIDに対応するTXフロー状態テーブル1030の部分を選択して様々なパラメータを取り出すことができる。これらの実施形態全体においてパラメータ例が説明される。
幾つかのパラメータは、ポリシングユニット1010に引き渡すことができる。以下においてポリシングユニット実施形態例がさらに詳細に説明される。暗号化が可能な状態になった場合は、暗号化ブロック、この例においてはメッセージ完全性符号(MIC)1025、は、暗号化の際に用いるために引き渡されたキーを有することができる。
MICブロック1025において、供給されたキー及びパケットのペイロード部分内のデータから、MIC計算を生成することができる。この実施形態においては、ペイロードの暗号化を行うための別個の構成要素が用いられる(以下において詳述されるレガシープロトコルエンジン2210を参照)。代替符号化技術は、当業においてよく知られており、代わりに用いることができる。
ヘッダーを生成するためにその他のパラメータをヘッダーアタッチ1035に引き渡すことができる。生成されたヘッダーは、パケットヘッダー自体において用いるためのフィールド、及びパケットがMAC処理機能を横断する間に用いるための制御値を含むことができる。これらの制御値は、パケットが送信のために引き渡される前に取り除くことができる。この技術は、MAC処理が実行される間パケットに関する状態情報を維持するための一技術例である。当業者は、様々なMAC機能を実行する間パケットの状態を維持するための代替技術を認識するであろう。
ポリシングユニット1010は、フロー状態テーブル1030から引き渡されたパラメータと関連して、パケットを拒否することができ、その場合は、暗号化機能、例えばMIC計算、は実行されず、FIFOからパケットを取り除くことができる。入力ポリシング実施形態例が以下においてさらに詳細に説明される。ポリシングユニット1010がパケットを許容する場合は、ペイロードが、MIC1025において生成されたMIC部分とともにイネーブルにされ、適切なヘッダーがFIFO1050における格納のために引き渡される。
図11は、TXフロー状態テーブル1030の内容の実施形態例を示す。パラメータの組が各フローに関して維持される。単一のフローのパラメータが示される。パケット型1102は、いずれの型のパケットを受け取り中であるかを指定する。例えば、パケットは、802.11(g)、(e)、又は(n)パケットであることができる。その他のパケット型をサポートすることができ、パケット型1102フィールドにおいて示すことができる。
セキュリティポリシー1104は、セキュリティ技術(例えば暗号化)が用いられるかどうかを示す。実施形態例は、AES−CCMP(高度暗号化基準−カウンターモード暗号ブロック連鎖メッセージ認証MACプロトコル)及びRC4−TKIP(Rivest’s Cipher−4−テンポラルキーインテグレーションプロトコル)をサポートする。受信機アドレス1106は、パケットの行先である受信機のMACアドレスを示す。シーケンス番号1108は、パケットシーケンス番号を示す。MICキー1110は、TKIPがイネーブルにされた場合のMICキーを識別する。フレーム制御1112は、適切なヘッダーを構築するための情報を含む。
サービスの質(QoS)制御1114は、QoSレベルを示すために用いることができる。実施形態例においては、4つのQoSレベルが維持される。以下において異なるQoS値に関する待ち行列処理例がさらに詳細に説明される。
寿命フィールド1116は、パケットがバッファ内にどの程度の期間とどまることができるかを示すために用いることができる。例えば、寿命値が経過した時点で、パケットをフラッシングすることができる。実施形態例においては、入力ポリシングの際には、例えばポリシングユニット1010においては、最大バッファ占有率1118、フロー当たり最大パケット1120、及びフロー当たり累積パケット1122が用いられ、その例が以下において図12及び13に関してさらに詳細に説明される。グローバル変数現バッファ占有率をこれらの3つのパラメータとともに用いて様々な入力ポリシング技術を実行できることに注目すること。末尾待ち行列ポインタ1124は、上述されるように、図6及び9に関する末尾ノードを識別するために用いられる。
これらのTXフロー状態テーブル変数又はパラメータは、例示することのみを目的とするものである。当業者は、追加の変数又はパラメータがフロー別に維持する上で有用であって含めることが可能であることを認識するであろう。さらに、すべての特長をすべての実施形態においてサポートする必要があるわけではなく、これらのパラメータの部分組を採用することができる。
図12は、入力ポリシングを実行するための方法1200の実施形態例を示す。以下において、出力ハンドオフ及び全体的WLAN QoSを対象とした、入力ポリシングの利点に関するより一般化された説明が以下において図34を参照して示される。図11におけるTXフロー状態テーブル例1030に関して上述されるように、様々なパラメータを各フローに関して維持することができる。これらのパラメータは、ポリシング機能によってパケットをより簡単に受け付けること又は拒否することができるようにQoSレベルに基づいて個別適合化することができる。
この技術は、WLAN QoSに関連する一方で、(バースト性である可能性があり及び高低のQoSフローの組合せを具備する可能性がある)高速入力とインタフェース時には、WLAN自体における混雑とは別個のボトルネックがMAC処理ユニットにおいて形成される可能性があるということを認識する追加技術である。例えば、MAC処理機能により低いQoSのパケットを充填することが可能である。適切なポリシングが行われない場合は、混雑度が相対的に低い間により低いQoSのパケットがパイプライン内に導入されるおそれがあり、さらにWLANにおける状態が劣化してスループットが低下した場合にボトルネックが形成されるおそれがある。従って、ポリシングユニット1010は、より高いQoSのパケットが相対的混雑時間中に自己の優先度を維持するのを可能にするように構成することができ、さらに、混雑度が低下したときにより低いQoSのパケットを処理することをより自由に可能にすることができる。802.11基準(例えば、b、g、e及びn)は、WLANにおけるQoS制御に注意を払っているが、入力に対しては十分な注意を払っていない。従って、QoSが低いアプリケーションが局内の全バッファを占めた場合は、優先度が高いパケットがシステムへのアクセスを得ることができない。本明細書において説明される入力ポリシングは、該シナリオを防止し、WLAN QoSだけでなくエンドツーエンドQoSを提供することができる。当業者は、本明細書における教義に鑑みてポリシング機能に関する様々な代替実施形態を認識するであろう。
図12に戻り、1210において、パケットが送信のために受信される。例えば、パケットは、H2Wプロセッサ530に導入することができ、ポリシングユニット1010は、さらなるMAC処理のためにパケットを受け入れるべきか又は拒否するべきかを決定することができる。1220において、受信されたパケットのIDを決定する。例えば、フローマッピングブロック1020を用いることができる。1230において、フローIDと関連づけられたポリシングパラメータ及び/又はポリシング機能にアクセスする。一実施形態例においては、これらのパラメータは、TXフロー状態テーブル1030に格納することができ、最大バッファ占有率1118、フロー当たり最大パケット1120、及びフロー当たり累積パケット1122を含むことができる。図11のTXフロー状態テーブル例1030には、複数のポリシング機能(及びおそらくそれに関連づけられた代替パラメータ)が指定され、異なるフローに関して異なるポリシング機能が用いられる可能性があることが示されていない。決定ブロック1240において、フロー専用パラメータ及び現在の混雑又はその他のシステム状態に関連するグローバル変数に従い、受信されたパケットを受け入れることがフローに関して指定された適切なポリシング機能を満たす場合は、1250に進んでパケットを受け付ける。満たさない場合は、1260に進んでパケットを拒否する。これで、プロセスは停止することができる。
図13は、図12におけるステップ1240として採用するのに適したポリシング機能の方法1300の一実施形態例を示す。上述されるように、パラメータ最大バッファ占有率及びフロー当たり最大パケットは、個々のフローに関して個別適合化することができる。これらは、フローのQoSレベルと関連づけることができる。実施形態例においては、4つのQoSレベルが採用される。しかしながら、これらのパラメータは、予め定義されたQoSレベルよりも大きい変動を受け入れるようなサイズであることができる。従って、幾つかの実施形態においては、ポリシング機能は、QoS設定例よりも細かい粒度で実装することができる。この例においては、決定ブロック1240は、図12において示されるように展開されたときに1230から到着することができ、パケットを受け付けるかどうかを決定し、(図12において示されるように展開されたときにはブロック1250又は1260にそれぞれ進む)。
決定ブロック1240における試験例は、2つの条件(term)を具備する。いずれかの条件を満たすことは、パケットが受け入れられることを可能にする。両条件が満たされない場合は、パケットは拒否される。
第1の条件は、MAC処理ユニット内における混雑を示す指標であると考えることができる。MAC処理ユニットの混雑度が相対的に低いときには、第1の条件は、優先度がより低いパケットに関する場合でも、より高い可能性を持って真になり、従ってパケットが受け付けられる可能性が高くなる。示される例においては、第1の条件は、現在のバッファ占有率が最大バッファ占有率よりも低いときに真である。ここで、現バッファ占有率は、プロセスが利用可能なグローバル変数であり、パケットバッファの全体的占有率を示す。最大バッファ占有率は、異なるフローに関して異なる形で個別に適合化し、それによって、ORステートメントの第1の条件を希望に応じてより厳しく又はより緩くすることができる。例えば、QoSが高いフローはより高い最大バッファ占有率設定を有することができ、それによって受付の可能性がより高い。対照的に、より低い最大バッファ占有率設定は、受付けの可能性を低くする。換言すると、最大バッファ占有率は、フロー型に基づいた場合の混雑がどのような意味であるかについての概念が異なることを考慮してフローごとに指定することができる。
第2の条件は、一般的には、相対的混雑が存在するときに適用される。この場合は、フロー別情報が中心になる。示される例においては、第2の条件は、所定のフローに関するフロー当たりの現在のパケットがフロー当たりの指定された最大パケットよりも少ない場合に真である。具体的には、フロー当たりの最大パケットは、優先度がより高いフローはより高い値が割り当てられて優先度がより低いフローはより低い値が割り当てられるような形でフローに関して設定することができる。従って、現バッファ占有率が相対的に混雑している(従って第1の条件は真にならない)ときには、より多いフロー当たり最大パケットを有するより高い優先度のパケットのほうが受け付けられる可能性が高くなる。優先度がより低いフローに関するフロー当たり最大パケットは、より低くなるように調整することができる。従って、これらのパケットを実際に完全に制限することを除き、より低い優先度のパケットのうちの相対的に非常に少ない数のパケットが受け付けられる。代替実施形態においては、フロー当たり累積パケットは、時間値(該時間値は、フローごとに変化することがある)を用いて計算してフローに関するパケットレートを生成することができる。次に、フロー当たり最大パケットは、同様にフロー当たりパケットレートに設定することができる。様々な代替パラメータ及びパケットを受け付けるか又は拒否するための関連条件が構想されており、本明細書における教義に照らして当業者に明確になるであろう。
これらのパラメータは、静的である必要がなく、システムのその他の条件(例えば、PHYからのレートフィードバックにおいて示されるようなリンク品質と関連レート)に基づいて更新することができる。当業者は、各々の変数に関する夥しい数の設定値を認識することになり、さらにこれらの設定値は変化するシステム状態に応じて様々な方法で変更可能であることを認識するであろう。
正味の結果は、フロー別パラメータをTXフロー状態テーブル1030から単に取り出すことによって有効なポリシング機能をライン速度で効率的に展開できることであり、各着信パケットに関して素早く決定を行うことができる。入力ポリシング機能に従ってパケットを受け付けるか又は拒否することは、あらゆるフロー制御技術と結合させることができ、その例は当業においてよく知られており、従って、可変のパケット処理レートをパケット損失なしに実現させることができる。一実施形態においては、パターン全体を外部インタフェースにおいて受信する前にフロー識別子を受信して入力ポリシング決定を可能にし、それによって、パケットが拒否されたときに該パケットを受信するためにインタフェース帯域幅を用いることを回避することができる。
要約すると、この例は、ポリシングに関する幾つかのオプションを強調する。高負荷下においては、単一のフロー(優先度が高いフローも含む)は、優先度がより高いフローにより大きいアクセスを許容する一方で、資源を支配しないように防止することができる。より軽い負荷下においては、その時点においては資源が消費中でないため、制限がより緩い決定が優先度の低いフローによる該資源の利用を可能にすることができる。入力ポリシングは、説明される4つの変数のいずれかの関数であることができ(及び代替実施形態は、その他の変数又はパラメータを利用することができる)。ポリシングは、公平性の確保のために用いることができ、どのような程度が希望されるかにかかわらずその他のフロー型が優先される場合でもすべてのフロー型に対して少なくとも何らかのアクセスを許容するようにすることができる。ポリシングは、低いリンク品質を管理するのにも用いることができる。リンク品質又は混雑の個別適合化のいずれが希望されるかにかかわらず、又はこれらの2つの組合せが希望されるかにかかわらず、同じ(又は同様の)パラメータを用いることができる。
図10Aに戻り、FIFO1050の出力がフラグメントブロック1060に引き渡される。FIFO1050は、受け入れられている1つ以上のパケットを、該当する場合は各々のヘッダー及びMIC計算とともに含むことができるのを思い出すこと。フラグメンテーションは、パケット型に依存して行うことができる。例えば、フラグメンテーションは、802.11(e)又は(g)、又はフラグメンテーションが希望されるその他のパケット型に関してイネーブルにすることができる。実施形態例においては、グローバル変数、フラグメンテーションしきい値(FT)は、AP管理機能を通じて設定される(FTは、ビーコンフレーム内において設定される能力要素である)。フラグメンテーションしきい値は、一般的には、短期間では変化しない。ファームウェアは、レジスタ内のフラグメンテーションしきい値を設定することができる。パケットがフラグメンテーションしきい値を超える場合は、潜在的な残存する部分的フラグメントを有するFTサイズのフラグメントにパケットを分割する。
フラグメンテーションは要求事項ではないことに注目すること。代替実施形態においては、フラグメント1060及びすべての関連機能を省略することができる。以下において図48に関してさらに詳細に説明される他の代替実施形態においては、2つ以上のMAC処理ブロックを採用することができる。該実施形態においては、1つのMAC処理ブロックは、フラグメンテーションを行うために備えることができ、他のMAC処理ブロックは、フラグメンテーションを行うことを目的として備えられない。一状況においては、高速パケットは、フラグメンテーションを要求しないか又はサポートしない場合があり、フラグメントブロック1060なしでH2Wプロセッサ530において処理することができ、フラグメンテーションを含むその他のパケット型(例えば、レガシー802.11パケット)に関するサポートを追加のMACプロセッサ、例えば以下において詳述されるMACプロセッサ4810等、において提供することができる。様々なパケット型の全機能を処理する能力を有する単一のプロセッサを含む実施形態及び2つ以上のMACプロセッサを具備する他の実施形態であって、各々があらゆる部分組の機能を提供する能力を有する実施形態、を採用時における相反性を容易に理解するであろう。当然のことであるが、単一の組の機能を要求するパケットを処理することができる単一のMACプロセッサも採用可能である。
フラグメントブロック1060は、フラグメンテーションしきい値及びパケットの長さに基づいてフラグメント数を決定する。フラグメント数は、リスト機能ブロック1065に引き渡され、リスト機能ブロック1065は、フラグメントブロック1060にポインタを戻す。フラグメンテーションがイネーブルされないか又はフラグメンテーションしきい値を超えない時には、フラグメント数は1になり、単一のノードポインタ及びその関連づけられた1つ以上のチャンクポインタが戻される。リスト機能ブロック1065は、(例えば、上図6において説明されるような)採用されたメモリ構造に関して適用可能な様々な連結リスト手順を実行する。示されるように、一例としてノードポインタキャッシュ810及びチャンクポインタキャッシュ820は、リスト機能ブロック内に常駐することに注目すること。従って、利用可能なポインタのプールを各キャッシュ内の利用可能なプールから取り出すことができる。これらのキャッシュをリフレッシュ及び補給する方法の詳細は示されていないが、当業者にとっては本明細書における教義に照らして明確になるであろう。概念的には、図10Aに示されるように、幾つかのフラグメントをリスト機能1065に送信することができ、その数のフラグメントに関する1つのグループのポイントを戻すことができる。フラグメンテーションが存在しない場合は、フラグメント数は1つであり、単一のノードポインタ及びその関連づけられたチャンクポインタ又は複数のポインタを戻すことができる。代替実施形態においては、同様の機能をフラグメントブロック1060によって実行することができ、パケット全体がフラグメンテーションされるまでリスト機能1065への繰り返しの呼が各フラグメントに関して行われる。各ポインタが戻されるのに応じて、グローバル変数バッファ占有率が、チャンク数又はパケット数に従って増大される。バッファ占有率は、実施形態例において測定可能であり、代替実施形態は、代替尺度を用いることができる。
図14は、FIFO 1050の実施形態例を示す。FIFO 1050は、1つ以上のMACサービスデータユニット(MSDU)1410A乃至Nを含む。上述されるように、各MSDUは、ヘッダー1430と、ペイロード1440と、MIC計算1450(TKIPが用いられる場合)と、を具備する。一実施形態においては、上述されるように、FIFO 1050内の各MSDUに制御データを加えることができ、フラグメントブロック1060からフィードバックすることができる。代替実施形態においては、制御情報はFIFO 1050においては維持されない。H2Wプロセッサ530において用いるために追加された制御情報は、パケットバッファメモリ内にパケットを書き込む前に削除される。
フラグメンテーションが必要ない場合は、MSDUは、バッファ1062内に直接格納することができる。MSDUは、リスト機能1065から取り出されたノードポインタ及びチャンクポインタとともに格納することができる。リスト機能は、各パケットに関する番号及びチャンクアドレスを与え、パケットペイロード(従ってチャンクペイロード)がメモリ内の対応するアドレスに書き込まれる。フラグメンテーションが希望される場合は、生成される各フラグメントもバッファ1062内に格納される。
バッファ1062の内容は、メモリ書き込み1070に引き渡される。メモリ書き込み1070は、メモリアービター1080とインタフェースし、メモリアービター1080は、パケット及び/又はフラグメントをパケットバッファ内に実際に入れるためにパケットバッファメモリへのアクセスに関して競争する。メモリアービター1080は、MACプロセッサASIC310の構成に依存して、図5に示されるようなメモリアービター556又は552のうちの1つとして実装できることに注目すること。
メモリアービター1080は、メモリ書き込み1070からの要求を受け取るメモリアービターが示され、パケットバッファメモリへのアクセスに関して競争中のその他の構成要素からのその他の要求を受け取ることができる。アクセスが許可されると、メモリ書き込み1070に許可が戻され、パケット及び/又はフラグメントがパケットバッファメモリ内に書き込まれる。メモリ書き込みを行うために図9に示される方法と同様の方法を用いることができる。例えば、ノードが生成され、説明されるような長さ及びチャンクポインタ等を含む現在のデータが充填される。次に、実施形態例においては、各々の512バイトのチャンクが充填されるまで64バイトのアクセスにおいてチャンクが書き込まれる。メモリ書き込み1070は、フラグメントが存在する場合はすべてのフラグメントを含むパケット全体がRAM内に書き込まれるまで要求を行い続ける。パケットを適切な待ち行列内にスレッドするために用いられるポインタは、パケットに関するノードポインタ(又は各フラグメントに関するノードポインタ)及び待ち行列内の最後のノード(後続する新しいパケット及び/又はフラグメントが添付される場所)を識別するための末尾待ち行列ポインタとして取り出される。
一実施形態においては、メモリアービターは、入力状態マシン、WLAN Tx状態マシン、WLAN Rx状態マシン及び出力状態マシンからの要求を受け取る。メモリアービターは、優先度を用いてこれらの要求を仲裁することができ、一例は、次の優先順位である。すなわち、WLAN Rx、WLAN Tx、出力及び入力。状態マシンは、パケット全体が読み取られるか又は書き込まれる必要がある。その他の時においては、状態マシンは、スケジューリング及びその他の機能を実行するためにノードポインタ、チャンクポインタ、及び/又はその他の制御情報を探しているだけの場合がある。WLAN Rx/Tx及び出力/入力目的で制御及びパケットの読み取り及び書き込みを網羅する優先度システムを構築することができる。
フローは、フローの指定(すなわち、TSPEC)が局によって行われたときにセットアップされる。その時点で、ファームウェアは、すべてのフロー関連テーブル内においてエントリをセットアップすることができる。さらに、ファームウェアは、そのフローに関する先頭ポインタ(従って最初のパケット)を入れることもできる。当業者は、新しい待ち行列を追跡するための及び関連づけられた先頭待ち行列ポインタを更新するためのその他の様々な方法を認識するであろう。
実施形態例においては、メモリアービターは、その他の構成要素によるパケットバッファメモリへの公平なアクセスを許容するためにメモリアクセスを限られたバイト数(すなわち、64)に制限する。一実施形態例においては、入力書き込み要求、WLAN RX書き込み、及びWLAN TX出力の間にラウンドロビン方式のアクセスがメモリに与えられる(すなわち、以下において詳述されるハンドオフ)。例えば、1500バイトのMPDUは、MPDU全体が割り込まれたストリーム内に書き込まれた場合にアクセス待ちのその他に長いレーテンシーを導入する。スケジュール、例えばラウンドロビン、が、その他のプロセスにおける行き詰まりを防止する。
図15は、MSDU1410を1つ以上のフラグメント(各々はフラグメンテーションしきい値に従ってサイズが決められる)、及び可能な残存フラグメントに分割するプロセスを示す。この例においては、制御1420は省略される。1つの代替実施形態においては、制御1420は、示されるように、単に第1のヘッダー1510の先頭に添付することができる。制御情報は、ポインタ、又は各ヘッダー1510の先頭に添付することができてメモリ書き込みを完了する前に取り除くことができるその他の制御情報を含むことができる。図15においては、各フラグメント1530A乃至Nは、ヘッダー1510が先頭に添付され、各フラグメントは、MSDUからのペイロード1440の一部分であるペイロード1520として識別される。各ヘッダー1510は、パケットのシーケンス番号であるシーケンス番号1540と、各々の個々のフラグメントと関連づけられた番号であるフラグメント番号1550と、を含む。
実施形態例においては、フラグメンテーションが行われた後は、各フラグメントはパケットとして取り扱われる。このことは、本明細書において詳述される様々なMAC処理技術を通じてのパケット及びフラグメントの効率的な処理を考慮するものである。代替実施形態は、この要求を共有する必要がない。最終的なフラグメント1530Nは、TKIPが用いられる場合はMIC1450を含む。実施形態例においては、MICは、MIC1025によるフラグメンテーション前にパケット全体にわたって計算されたことを思い出すこと。
図16は、2つ以上のメモリ書き込み1610A乃至1610Nと関連したアービター556の概念的構成を示す。メモリ書き込み1610は、直前において説明されたメモリ書き込み1070、又は後述されるその他の様々なメモリ書き込みのうちの1つであることができる。各メモリ書き込みブロックは、要求1630をアービター556に送信する。アービター556は、メモリ書き込みがいつ開始するかを示す許可ライン1640を各メモリ書き込みブロックに送信する。アービター556は、SDRAMコントローラ1650への引き渡しを目的として許可されたメモリ書き込み構成要素の出力を選択するようにMUX1620を制御することもできる。例えば、SDRAMコントローラ1650は、図5に示される例においてはSDRAMインタフェース562であることができ、又はSDRAM340に結合されたその他のいずれかの構成要素を含むことができる。選択された構成モードに従ってパケットメモリにパケットを書き込むためにメモリアービター552に関して同様の仲裁方式を採用できることに注目すること。当業においては様々なメモリ仲裁方式がよく知られており、これらのうちのいずれかを本明細書における様々な実施形態において採用することができる。一実施形態例においては、一般的には、コントローラは、インタフェースによって後続される。コントローラは、メモリへの読み書きの論理を制御することができ、インタフェースは、物理的接続を提供する。図16は、1つの説明例である。
送信処理
前節においては、入力パケッの効率的なMAC処理に関する側面を例示する様々な実施形態が説明され、最終的には、送信を待つために様々なデータ構造を利用してパケットが処理されてパケットバッファ内に入れられた。送信処理に関する本節においては、上記のデータ構造の使用によって得られるさらなる効率が明らかになるであろう。さらに、高速MAC処理に関する効率を向上させるその他の側面が紹介される。
一般的には、複数のSTAに関する数多くのフローをサポートすることができるアクセスポイントは、16のフローをサポートする相対的に単純なSTAよりも複雑な解析を提供する。従って、後述される実施形態の多くにおいては、より複雑なアクセスポイントが基準として用いられる。必要なときには、STAとアクセスポイントとの間における相違が強調される。一般的には、送信処理の際には、多くの数のフローを受け入れ、その一方で送信機会が利用可能になったときには素早く反応できることが望ましい。さらに、レガシー送信仕様のサポートが重要になることがある。回路面積の減少、より効率的な回路の使用、設計の単純化、及び/又はレガシープロトコル及び構成要素とのインタフェース能力に起因して幾つかの側面が強調される。
送信機会が生じたときに即座に対応する必要があることを示す一例は、不定期自動節電引き渡し(UAPSD)プロトコルを含む。他の例は、即時ブロックackである。以下において詳述される実施形態は、素早い対応が可能なように1つの部分組のパケットを維持することによって効率的な複数のフローのサポートを提供する。この提供は、UAPSDに関するサポート、即時ブロックack、及びTXOPが入手されたときの即座の引き渡しを可能にする。このことは、ほとんどの場合において、これまでに用いられている帯域幅保存技術、例えばCTSを自己に送信する、等、を不要にする。一例においては、メモリへのアクセスの際における混雑がより大きい統合物を準備するのを妨げる場合は、小さい一組のパケットをTXOP中に素早く送信することができる。その組のパケットに関してackが受信された時点で、TXOP内に残りの容量が存在する場合は、追加のパケットを送信することができる。上述されるように、パケット処理の高速部分からファームウェアを取り除くことは、効率を向上させる。実施形態例においては、ファームウェア処理(及びその相対的に低い速度)をMAC処理から切り離すために様々なキャッシュ及び待ち行列を採用することができる。以下では、これらの及びその他の側面が様々な実施形態において例示される。
以下において詳述される実施形態例においては、幾つかの側面が例示される。一側面においては、複数のキャッシュが採用され、各キャッシュは、フローのパケットと関連づけられた要素を格納するために用いられる。これらのキャッシュ(以下ではノードキャッシュ1810によって示される)は、様々なアプリケーションにおける低レーテンシー応答時間を考慮するものである。低レーテンシー応答は、局又はAPが様々な型の送信機会、例えば反対方向許可、UAPSD及び同様の要求、の効率的な使用を可能にし、さらに、送信に引き続いて残りの送信機会を取得することを可能にする。低レーテンシー応答は、衝突の回避を容易にする(例えば、初期の送信機会における成功裏の即座の応答は、のちの応答試みにおいて生じるコンテンションに起因する衝突を回避することができる。低レーテンシー応答は、節電を容易にすることができる。
他の側面においては、シャドー待ち行列(以下では、ピンポン待ち行列と呼ばれ、待機中待ち行列及びサービス中待ち行列によって定義される)は、(他のフローが送信のために処理中である間においても)送信機会前にフローの要素を待ち行列内に入れることを考慮するものである。従って、フローは、処理準備が整った状態で待機中である。このことは、処理を可能な限り繰り延べることを容易にする。繰り延べは、フローに関するレート決定を繰り延べるのを可能にするためにしばしば望ましい。その理由は、レート決定は可能な限り直近でさらに新しいものであり、スループットを最大にする及び/又は誤りを最少にするような適切なレートが選択されるのを考慮するためである。
他の側面においては、フローに関するパケットと関連づけられた要素を待ち行列(以下に示される待ち行列1842、1850及び1855)に充填することは、(繰り延べられたレート決定に関して有用である)パケットを形成するための素早い長さ決定を容易し、さらに即座のパケット統合を容易にする。統合一般に加えて、例示される側面は、(すなわち、受信されたブロック確認応答に応答した)再送信を容易にする。これらの側面は、多くの状況においては別々に望ましく、さらに結合させることも可能である。
レガシー802.11システムにおいては、典型的には4つのEDCA待ち行列に関するサポートが提供される。EDCA待ち行列は、メディア上においてスケジューリングされていない期間中はアクセスを求めて競争し、TXOPがいったん入手された時点で、可能な限り多くのデータを、規定された最大のTXOPまで、送信する。競争中のEDCA待ち行列を受け入れるために、競争中のEDCA待ち行列によってTXOPを入手する試みが連続的に同時に行われるのを防止するための様々なバックオフ方式が採用される。従って、各EDCA待ち行列は、チャネルと関連づけることができ、そのために様々なタイマーが維持され、明確なチャネル評価(CAA)が行われ、アクセスを得るためのその他の手順が実行される。これらの機能の一部は、チャネル間で又は待ち行列間で共有することができ、幾つかは異なることができる。数多くのフロー(すなわち、実施形態例における256のフロー)を同時にサポートするのを希望するアクセスポイント等の無線通信デバイスにおいては、バックオフタイマーを維持すること及び大量のフローの各々に関してTXOPを入手することに関連する様々なオーバーヘッドを行うことは望ましくないことがある。チャネル型の様々なパラメータに関して異なる設定を行うことは、異なるサービス質レベルを提供することになる可能性がある。
図17は、より小さい、固定された一組の標準的EDCA待ち行列1730を用いて相対的に大きい複数のEDCA待ち行列1710をサポートするように構成された無線通信デバイスの一部分の実施形態例を示す。一アプリケーションにおいては、各々が異なるサービス質レベルを提供する複数のEDCA待ち行列を採用することができる。この例においては、複数のNの局別EDCA待ち行列1770A乃至Nが維持される。実施形態例においては、サポートされる256のフローの各々に関する256の該待ち行列を維持することができる。ラウンドロビンセレクタ1720は、局別EDCA待ち行列間における仲裁を行い、4つの標準的ECDA待ち行列1730A乃至Dのうちの1つにおいて待ち行列状態にすべきデータを選択する。代替実施形態においては、ラウンドロビンに加えての代替スケジューリングアルゴリズムをセレクタ1720において実行することができる。セレクタは、様々な方法で配置することができ、その一例が以下の図18において詳述される。実施形態例においては、ファームウェアは、標準的EDCA待ち行列のうちの1つを用いて局別EDCA待ち行列を引き渡しのために選択するための選択基準を提供するスケジューリング機能を含む。代替実施形態においては、当然のことであるが、あらゆる数のEDCA待ち行列をサポートすることができる。1つの実施形態においては、必要なタイマー及び共有チャネルへのアクセスを求めて競争して該アクセスを入手する上で要求されるチャネル評価構成要素を有する既存のレガシー処理構成要素の利用可能性に起因して4つの待ち行列が採用される。当業者は、本明細書における様々な実施形態において含めることができるか又は希望される追加の特長をサポートするように改修ことができる複数のレガシー802.11コア及び構成要素を容易に見つけるであろう。本明細書において開示される原則に従ってレガシーコア及び/又は構成要素を利用する実施形態例が以下においてさらに詳細に説明される。EDCA待ち行列1730A乃至Dにおいてスケジューリングされたパケットは、標準的なEDCA手順を用いて送信することができる。ファームウェアスケジューラは、EDCA以外の追加スケジューリング、例えばポーリングされたTXOP(一例がHCCAプロトコルにおいて既知である)、を実行することができる。当業者にとって明らかになるように、スケジューラを適合化することができる様々なその他のプロトコルを採用可能である。標準待ち行列を用いて送信するためにEDCA待ち行列1710をラウンドロビン方式で選択することに加えて、一般的には、各STAに関するパケットを統合してその局からの全パケットに関して固有操作(eigensteering)(又はその他の空間処理)を行うほうが効率的である。固有操作は、送信が特定の局(又は同様に位置する局のグループ)に操作されたときに最大の利益を提供する。従って所定の局に向けられた全パケットを1つのバッファ内に入れてこれらのパケットを統合してその局に送信できるようにすることが合理的な場合がある。代替実施形態においては、全EDCAパケットに関して単一のバッファを有することが可能である。しかしながら、この場合は、パケットが(その他の固有値を有する)その他の局のパケットとインターリービングされるときには、統合を行うことは困難又は不可能なことがある。
EDCA待ち行列の使用は、例示することのみを目的とするものである。一般的には、様々な型のチャネルと関連づけられた一組の待ち行列を採用することができる。チャネル型は、サービスの質レベル及び/又は送信型、例えばスケジューリングされた又はコンテンションに基づくアクセス、に基づいて変わることができる。
図18は、下位MACコア540の様々な構成要素を示した実施形態例である。パケット処理速度からファームウェアを切り離すためにパケット処理用ノード、待ち行列及びキャッシュを用いる効率を提供する様々な側面、及びその他の側面が次の例において示される。当業者は、追加の構成要素(示されていない)を採用できること、及び特定の実施形態においてはその他の側面又は特長を利用するために例示されるすべての側面又は特長が要求されるわけではないことを認識するであろう。図18の詳細は、フローのスケジューリング及び最終的送信に関してスケジューリングされた様々なパケットの識別を示す。最終的には、スケジューリングされたパケットと関連づけられた識別子、関連づけられたパラメータ、及び各チャネル型に関するレディ信号が送信(TX)エンジン1880に引き渡される。上述されるように、この実施形態においては、パケット識別は、ノードを用いて行われる。この例においては、レガシー802.11型チャネルは、例示することを目的として用いられる。当業者は、図18において詳述される同様の構成要素を用いてあらゆるチャネル型を受け入れ可能であることを認識するであろう。この例においては、4つのEDCA待ち行列、EDCA 0−3 1850Aが維持される。ブロードキャスト制御チャネル1860とともにHCCA待ち行列1855も同様に採用される。EDCA0の構造がさらに詳細に説明され、その他のチャネルに関しては、様々な実施形態において同じ又は同様であることができるため詳細は省略される。
送信スケジューリングは、ファームウェアが各チャネル(例えば1850又は1855)と関連づけられた1つ以上のコマンドリスト1815を満たすことから開始する。コマンドリストは、スケジューリングすべきフローIDが充填される。コマンドリストは、フローIDをTXOPとともに含むことができる。EDCA待ち行列に関して、TXOPを入手するための競争が行われ、従って送信時間は事前に知ることはできない。しかしながら、最大TXOPサイズをフローIDとともに含めることができる。HCCAスケジューリングに関しては、スケジューリングされた引き渡し時間と同様にTXOPサイズを知っていることができ、このTXOP情報は、関連づけられたコマンドリスト1815においてフローIDとともに含めることができる。各チャネルに関して、アレイコントローラ1840は、チャネルに関するパケットのスケジューリングを制御することができる。アレイコントローラは、コマンドリスト1815からフローIDをポップし、送信に関する次のスケジューリングされたフローを決定する。これらのコマンドリストのうちの一部を維持することは、ファームウェアスケジューラがひとまとまりの決定を一回で行って各々リストに入れることを可能にし、このことは、経時で行うことができる。このことは、様々なアレイコントローラ1840がリストからのフローIDを処理してファームウェアによる対話の必要性を低減させるのを可能にする。このことは、上述されるように、ファームウェアへの割り込みを低減又は排除するのを可能にし、ファームウェアスケジューリングをMAC処理から切り離す。EDCA型コンテンションに基づくチャネル又はHCCA型のポーリングされた又はスケジューリングされたチャネルを含む、サポートされた一組のチャネルにおけるサービスに関するフローをスケジューリングするための代替技術は、当業者によって容易に適合化されるであろう。
この例においては、サポートされる複数のフローの各々に関してTXノードキャッシュ1810が維持される。TXノードキャッシュ1810は、一般的なフロー別キャッシュの例として役立ち、上記の待ち行列1710として採用するのに適する、実施形態例においては、256の該フローが維持される。各フローキャッシュは、(フローに関する各々のパケットを代表する)複数のノードに関するスペースを具備する。実施形態例においては、各フローに関する4つのノードが各TXノードキャッシュ1810において維持される。従って、少なくとも4つのパケットが、256のフローの各々に関して送信されるべき次のパケットとして識別される。これらのフローに関して要求される即時送信は、少なくともこれらの4つのノードによって満たすことができる。代替実施形態においては、希望される場合は、追加ノードをサポートすることができる。
この実施形態例においては、ノードは1つの側面を例示するために用いられる一方で、採用可能な同等の技術が幾つか存在する。例えば、代替データ構造をキャッシングすることができる。他の例においては、パケット自体をキャッシング可能である。一般的には、複数のキャッシュ1810として示されるキャッシュは、キャッシングされた要素の処理後に各々の1つ以上のパケットを識別して取り出すことができる1つ以上の要素を格納するために用いられる。
TXノードキャッシュリフレッシュ1835は、キャッシュ1810と対話して該キャッシュが充填された状態及び更新された状態を維持する。TXノードキャッシュリフレッシュ1835は、メモリアービター、例えば上記において詳述されるメモリアービター1080、と対話することができる。一実施形態においては、フローに関する1つ以上のノードを取り出すための要求が行われ、パケットバッファにアクセスが許可されたときに、取り出されたノードを各々のTXノードキャッシュ1810に入れることができる。TXノードキャッシュリフレッシュは、図18に示される処理の残りの部分から相対的に自主的に動作させることができる。
各チャネルに関するアレイコントローラ1840は、コマンドリスト1815からの送信に関する次のフローIDを決定する。フローIDに関して、アレイコントローラ1840は、TXアレイ状態テーブル1830にアクセスして様々なパラメータを取り出す及び/又はそのフローIDと関連づけられた状態を格納する。従って、TXアレイ状態1830は、サポートされたフローに関するフローごとの状態情報を維持する。(代替実施形態においては、TXアレイ状態テーブル1830は、その他のフロー別状態テーブル、例えば上述されるTXフロー状態テーブル1030と結合させることができる点に注目すること。)TXノードキャッシュリフレッシュ1835は、TXアレイ状態テーブル1830と対話して後述されるキャッシュリフレッシュと関連づけられた一定のパラメータを更新することに注目すること。例えば、TXノードキャッシュリフレッシュ1835は、各々のノードの送信待ち行列に基づいてフローに関するノードを取り出す。
アレイコントローラ1840は、スケジューリングされたフローに関するフローごとの状態を利用して各々のTXノードアレイ1842に充填する(待ち行列の例示)。TXノードアレイ1842は、TXエンジン1880への引き渡しのために送信順に順序が設定されたフローに関するノードのアレイである。示されるように、コマンドリスト1815によって識別された、現在のスケジューリングされたフローに関するTXノードキャッシュ1810内に格納されたノードの組が、フローの送信がスケジューリングされるチャネルに関するTXノードアレイ1842に引き渡される。このことは、送信が利用可能になったときに直ちに一組の既知のノードのスケジューリングを行うことを考慮するものである。実施形態例においては、各フローをTXノードアレイ1842内に入れるために4つのノードを利用可能である。TXノードアレイ1842の残りの部分は、フローに関する追加ノードを充填することができる。一実施形態例においては、TXノードアレイ1842は、TXエンジン1880を通じてのスケジューリングされた引き渡しのための時間において64のパケット識別子、すなわちノード、を保持する。最初の4つは、フローのTXノードキャッシュから取り出され、残りのパケットはパケットバッファメモリから取り出される。その他のパケットバッファメモリアクセスと同様の方法で、パケットバッファメモリからフローに関するノードの取り出し要求を行うことができる(詳細は示されていない)。代替実施形態においては、ノードアレイは、最初にキャッシュ1810等のキャッシュから要素を取り出さずにパケットバッファから直接充填することができる。さらに他の実施形態においては、キャッシュ1810は、まったく採用する必要がなく、ノードアレイ1842によって示される側面を依然として享受することができる。
アレイ制御1840、コマンドリスト1815、及び関連構成要素は、複数のキャッシュ(すなわち、1810)から要素を選択して複数の待ち行列のうちの1つ(例えば、待ち行列1842及びEDCA及びHCCA待ち行列1850及び1860によってそれぞ例示される待ち行列)に格納するためのセレクタ(例えば、図17に関して上述されるセレクタ)内に含めることができる構成要素の例である。一般的には、あらゆる数のフロー別キャッシュ又はフロー別待ち行列(すなわち、パケットバッファ内の送信待ち行列)を、希望される要因(例えば、サービスの質、チャネル型、等)に基づいて、ノードアレイ1842等の待ち行列内又は複数の該待ち行列のうちの1つ内に要素を格納するためにセレクタによって選択することができる。
実施形態例においては、上述されるように、TXエンジン1880への引き渡しのためにTXノードアレイ1842に充填する様々なアレイコントローラ1840とは別個の、TXノードキャッシュリフレッシュ1835の自主的動作が望まれる。しかしながら、アレイコントローラ1840がパケットバッファメモリからの各々のフローに関する待ち行列からのパケットにアクセス中であるのとほぼ同じ時点において該フローに関するTXノードキャッシュがリフレッシングを必要とする場合が時々ある。従って、アレイコントローラ1840又はTXノードキャッシュリフレッシュ1835のいずれかが送信待ち行列を壊すのを防止し、その待ち行列からパケットが複製されるか又は取り除かれるのを防止するためのインターロック機能を定義することができる。様々なインターロック技術が当業者にとって明らかになるであろう。以下において一実施形態例が図20に関してさらに詳細に説明される。
様々なチャネル、例えば、EDCAチャネル1850、HCCAチャネル1855又はブロードキャスト制御チャネル1860、の中に追加の側面を組み入れることができる。実施形態例においては、TXノードアレイ1842は、2つのシャドーノードアレイとして実装される。従って、第1のシャドーTXノーアレイは、スケジューリングされたフローに関するノードを充填することができ、レディ信号をTXエンジン1880にアサートすることができる。これで、アレイコントローラ1840は、次のフローIDをそのコマンドリスト1815からポップし、次のフローに関するパケットを第2のシャドーTXノードアレイにローディングするのに必要な処理を行う。この方法により、他方のTXノードに充填している間に一方のTXノードアレイを送信に関して処理することができ、それによって、新しいノードアレイ充填プロセスを開始する前に送信が完了するのを待つことと関連する起こりうるレーテンシーを低減することができる。リンクID1844は、TXノードアレイ1842と関連づけられ、従って、TXエンジン1880は、2つの局間での実際の物理的リンクにおいてフローを送信する際に用いるために適切なリンクパラメータ及び状態を取り出すことができる。直前において説明されるようにピンポン又はシャドーキャッシュが採用されたときには、リンクID1844は、1つのシャドーTXノードアレイ内に含まれているフローに関するリンクID Aを格納し、リンクID Bは、第2のシャドーTXノードアレイ内のフローに関するリンクIDを含む。代替実施形態においては、その他のパラメータを、各々のフローと関連づけて、1844においてリンクIDとともに格納することもできる。
2つのシャドーノードアレイは、シャドー又はピンポン待ち行列の一般的側面を例示するものである。一般的には、待ち行列は、特定の型のチャネル、例えばEDCA又はHCCAチャネル、に対応することができる。各チャネルは、複数のサービス質レベルから選択された、関連するサービス質レベルを有することができる。この例における待ち行列は、2つのシャドー待ち行列を具備する。待ち行列は、サービス中待ち行列及び待機中待ち行列を具備すると説明することもできる。物理的シャドー待ち行列は、サービス中待ち行列として割り当てられることと待機中待ち行列として割り当てられることを交互する。従って、上述されるように、待機中待ち行列は、サービス中待ち行列の処理と干渉せずに充填することができる。サービス中待ち行列が処理を終了時に、その対応するシャドー待ち行列を待機中待ち行列として再選択することができ、いずれの時点においても他のフローを充填するのを開始することができる。次に、待機中待ち行列であったシャドー待ち行列がサービス中待ち行列として再選択され、送信のための処理が開始することができる。この方法により、様々なサービス質レベルと関連づけることができる相対的に多い数のフローを、(サービス質レベルに従って、及びスケジューリングされた又はコンテンションに基づくアクセス、等に従って)該当する待ち行列内に格納するために選択することができる。選択は、上述されるように、ラウンドロビン方式であるか又はその他の型の選択基準であることができる。
キャッシュ1810に関して上述されるように、この実施形態例においては1つの側面を例示するためにノードが用いられる一方で、採用することができる同等の技術が幾つか存在する。例えば、代替データ構造を、1842(又は1850及び1855)等の待ち行列内に格納可能である。他の例においては、パケット自体を格納することができる。一般的には、待ち行列1842として例示される待ち行列は、待ち行列内の要素の処理に引き続いて各々の1つ以上のパケットが識別されて取り出される1つ以上の要素を格納するために用いられる。
例えばノードアレイキャッシュ1810からの4つのノードを“ピンポン”バッファ1842の片側に充填している間に、送信中にそのアレイの充填を続けるための時間が存在することができる。最初の4つのパケットを即時使用するU−APSDモードが既述されさらに以下においてさらに詳細に説明される。U−APSDにおいては、“さらなる”ビット等のインジケータを最初の4つのパケットとともに送ることができる。(要求されるフレーム間スペースを有する状態で)パケットを送信して最初の4つのパケットの確認応答を待機後、送信機は、追加送信の準備を完了している必要がある。この間に、採用された実施形態により適宜、TXノードキャッシュ又はパケットバッファから、フローからの追加ノードにアクセスすることができる。その他の送信型の場合は、利用可能な送信機会によって提供される全パケットの送信のためにTXノードアレイを一杯の状態に保つための同様の機会が存在することができる。
ブロードキャスト制御1860は、所定の実施形態においてアレイコントローラ1840と同様の機能を有する状態で配置することができる。しかしながら、縮小された又は代替の一組の機能を要求することがある。この例においては、ビーコンパケットを指し示すポインタ1863を具備するビーコンブロック1862が採用される。ファームウェアは、当業においてよく知られるように、ヘッダー情報、希望されるパラメータ、等を含むビーコンパケットを生成することができる。ビーコン1862は、生成されたパケットを該当時間における送信のために取り出すことができる。例えば、ファームウェアスケジューラは、生成されているビーコンに関するタイムスタンプ値を生成してこの値をビーコンブロック1862に引き渡すことができる。従って、ビーコンは、該当期間(すなわち、802.11実施形態においてはTBTT)において又はその近くにおいて送信することができる。該例においては、ビーコン1862は、ブロードキャスト制御1860を通じて、TXエンジン1880へのレディ信号を生成する。メディアに関するコンテンションが実行され、ビーコンは、該当する時間に送信され、チャネルがクリアされるのを待ちことに関連づけられた遅延に関して調整される。当業者は、本明細書における教義に照らして、ビーコン又はその他のシステムシグナリングメッセージを受け入れるように図18を簡単に適合化するであろう。代替実施形態においては、ビーコン1862は、インダイレクション(indirection)ポインタ1863を用いるのではなく、実際には直接ビーコンパケットを格納することができる。
同様の方法で、ブロードキャストチャネル又はマルチキャストチャネルも同様に生成することができる。ブロードキャスト及び/又はマルチキャストチャネルは、基本的には特殊目的のフローIDである。ブロードキャストチャネルは、上述されるコマンドリスト1815等の複数のIDを用いてスケジューリングする必要がない。しかしながら、複数のブロードキャストチャネル及び/又は様々なマルチキャストチャネルが希望される場合は、同様のスケジューリング手順も採用することができる(詳細は示されていない)。ブロードキャストパケット又はマルチキャストパケットは、(ブロードキャスト制御1860を介して)TXエンジン1880において送信するためにブロードキャストマルチキャストブロック1864においてポインタ1865によって識別することができる。代替として、パケットは、それ自体を1864において格納することができる。図18を説明する際に用いられているように、図6に関して上述されるようなパケットバッファメモリ方式が採用されるときには、パケットへの言及はノードへの言及に読み替えることが可能であることが明らかになる点に注目すること。上記から理解できるように、パケットを格納するためにノード及びチャンクが用いられるときには、パケットバッファメモリ自体内において待ち行列を維持することが効率的でさらに容易である。さらに、図18において例示されるような様々なフローをスケジューリングするためのキャッシュは、(パケットをノードとともに移動させるのではなく)単にノードを取り出して格納することによって維持することができる。以下においてさらに詳細に説明されるように、実際のパケットデータがパケットバッファから取り除かれる唯一の時点は、パケットの送信時点である。他方、パケットの処理及びスケジューリングは、単にノードを用いることによって達成される。ノードの利益を例示する追加の側面が、以下においてTXエンジン1880について説明される際にさらに詳細に説明される。受信処理側においても同じように同様の利益が享受される。
以下において図48及び49に関してさらに詳細に説明されるように、代替実施形態においては、パケットバッファ以外のソースから着信した、TXエンジンにおける引き渡しのためのパケットが存在することができる。例えば、レガシーパケット又は低スループットパケットを、ファームウェアMACプロセッサを用いてプロセッサ内においてフォーマット化することができ、これらのパケットを送信用に提供することができる。上記において詳述される構造は、該実施形態に合わせて適合化できることに注目すること。例えば、コマンドリスト1815は、代替ソースからの送信をスケジューリングするためにも用いることができる。例えば、フローID、送信すべきパケット数、及びパケットが高スループット又は低スループットのいずれであるかを記すインジケータ(より一般的には、パケットバッファ又は外部パケットソースからの送信)。低スループットパケットがスケジューリングされる場合は、後述されるように、送信プロセッサメモリFIFO(すなわち、4950)、又は代替として(例えばDMAを通じて)プロセッサメモリから取り出すことができる。該実施形態においては、ブロードキャスト制御1860に関して生成されたメッセージ、例えば、ビーコン及びあらゆるブロードキャスト又はマルチキャストメッセージは、代替としてファームウェア内においても同様に形成可能であることに注目すること。従って、構成要素1862、1864及び1860は、省略可能である。
図19は、下位MACコアプロセッサ540の1つのセクションの詳細な実施形態の例を示す。図19に示されるように、セレクタ1930は、コマンドリスト1815から取り出されたフローIDを引き渡す。この説明は、いずれの型のチャネルにアクセス中であるかは任意であるという点で概念的説明である。あらゆる数のコマンドリストを選択してTXアレイ状態1830に結合させることができる。選択されたチャネルからのフローIDがTXアレイ状態1830に提示されるときには、関連づけられたフロー別アレイ状態1902が取り出され、その状態の様々な成分を必要とする1つ以上の構成要素に引き渡される。セレクタ1930は、(すなわち、アレイ状態1902に格納された)フロー別パラメータをフロー識別子に基づいて選択的に取り出すセレクタを示す例である。一般的には、フロー状態テーブル(又はその他の組のフロー別パラメータ)は、フロー識別子によって取り出すことができ、又はフロー識別子に従ってフローインデックスを選択し、そのフローインデックスを用いて(おそらく1つ以上のメモリに格納されている)フロー別パラメータを探し出すことによってインダイレクションを介して取り出すことができる。本明細書において示される例は、これらの技術のうちのいずれかを用いて格納及び/又はアクセスすることができる様々な受信及び送信フロー別パラメータを示す。図3及び4において一般的に示されるように、いずれのモードで構成されるかに依存していずれかの型のフロー別パラメータを用いる集積回路(例)を採用することができる。この採用は、大小にかかわらず、利用可能なメモリ内の可変数のフローを効率的にサポートする能力を容易にする。
フロー別アレイ状態例1902が示される。関連づけられたフローに関してパケットバッファからノードを取り出すときには、取り出すべきノード数は、ウィンドーサイズ及び利用可能なパケットの最小である。従って、利用可能な総パケット数又は送信ウィンドーサイズ1910のいずれに関しても、(実施形態例における)一連の最大で64のノードをTXノードアレイ内に充填することができる。上述されるように、各々のフローのTX待ち行列内の次の後続ノードは、フローに関して利用可能なパケットが枯渇するまで又はウィンドーが満たされるまで、各ノード内の次の待ち行列ポインタを読み取り、次のノードを取り出し、該ノードをTXアレイ内に入れる等によって決定される。
先頭待ち行列ポインタ1912は、各々のフローの送信待ち行列(例えば、連結リストデータ構造)に関する待ち行列の先頭にあるノードを指し示すポインタを示す。先頭待ち行列ポインタは、フローからのパケットが送信されるときに順に取り出される第1のノードである。待ち行列内のパケット数は、フィールド1914に格納される。この数は、入力パケットがフローに関して受信されたときには増加され、これらの入力パケットが送信されたときには減らされる。フィールド1916に格納された場合のキャッシュ内のパケット数は、TXノードキャッシュ1810を補給するためにTXノードキャッシュリフレッシュ1835と関連して及びTXノードアレイ1842にノードを入れるために用いることができる。リンクID1918が所定のフローに関して取り出され、リンク専用状態及び/又はパラメータを取り出すために送信機において用いるためにリンクID1844に格納することができる。幾つかの実施形態においては、連結ノードリストは、多数のパケットから成ることができる。ウィンドーサイズは、ウィンドー内のパケットのみが送信に関して処理されるようにするために用いることができる。ウィンドーエンドポインタ1920をウィンドー管理のために用いることができる。代替実施形態は、追加のフィールドを含むことができ、説明されるフィールドのうちの一部を省略することができる。追加フィールド例は、AMPDU密度フィールドと、送信待ち行列末尾ポインタと、を含む。
図20は、図18において示されるように用いるために採用することができるインターロック例を示す。この例においては、TXノードキャッシュリフレッシュ1835は、パケットバッファメモリから情報を取り出し中であるときにビジー信号を生成する。この間に、更新中であるTXノードキャッシュのフローIDも示す。これで、アレイコントローラ1840は、処理中のフローIDがパケットバッファからアクセスされたノードを有するかどうかを知っている(幾つかのアレイコントローラ1840が存在することができ、各アレイコントローラは、これらの信号を各チャネルに関して1つ受信することに注目すること)。これで、そのフローIDからの幾つかのパケットはノードアレイキャッシュへ移行中であるため、アレイコントローラ1840は、そのフローIDに関するパケットバッファRAMへのアクセスを繰り延べることができる。このことは、アレイコントローラ1840がフローに関するTXノードキャッシュリフレッシュ動作と干渉するのを防止する。
さらに、TXノードキャッシュリフレッシュからフローIDを受信するために幾つかの比較ブロック2010が採用される。各比較ブロックは、各々のチャネルのアレイコントローラ1840が各々のTXノードアレイ1842内の追加スペースに充填するためのノードを取り出すことを目的としてパケットバッファにアクセス中であることを示すフローIDをチャネルから受け取る(すなわち、EDCA 0乃至3 1850A乃至Dであり、詳細は示されない)。これらのフローIDのうちのいずれかがマッチする場合は、各々のラインがアサートされる。ORゲート2020は、全比較出力の論理的ORを提供し、ビジー信号を生成する。TXノードキャッシュリフレッシュ1835は、ビジー信号が消えるまで更新継続を待つことができる。又は、異なるフローのキャッシュの更新を試みるためにフローIDを変更することができる。フローIDを変更することがビジー信号をデアサートする場合は、TXノードキャッシュリフレッシュ1835は、いずれのアレイコントローラ1840の動作とも干渉しないことを知っている。当業者は、このインターロック方式、及び本明細書における教義の適用範囲内おいて採用することができるその他のインターロック方式の様々な修正を認識するであろう。
代替実施形態(詳細は示されない)においては、上述されるように、4パケットノードキャッシュ(FPNC)1810が各フローに関して維持される。各キャッシュは、ノードポインタ(12バイト)を含む。上述されるように、これらは、各々のフローが送信機会を得たときにWLANにおいて送信される最初の4つのパケットである。この実施形態においては、パケットが入口において受信されると、SDRAM内に入れられ、(TXノードキャッシュリフレッシュ1835と同様であることができるか又はTXノードキャッシュリフレッシュ1835の代わりに採用することができる)ノードキャッシュ有限状態マシン(FSM)がシグナリングされる。受信されたパケットに対応する4ノードパケットキャッシュ内に余地が存在する場合は、ノード情報が各々のキャッシュメモリに追加される。ノード情報が連結リストに入れるためにSDRAMに送られるときには、FPNCにも送られる。FPNC内に余地が存在する場合で、(各々のフローに関するWLAN Tx Op中に)FPNCが使用中でない場合は、ノード情報がFPNCに入れられる。フローがサービス中であることをFSMに示すようにサービス中ビットをアレイコントローラ1840によって設定することができる。この設定は、有効性の点では上記において詳述されるインターロックと同様である。
FPNC状態マシンは、FPNCを更新するために先入れ先出し方式で動作する。FPNCは、以下において詳述されるU−APSDによってイネーブルにされる局に関するパケットを提供するのに特に有用である。トリガーが受信されると、下位MACコア540は、トリガーについて確認応答し、上述されるように、最大で4つのパケットの統合物によって直ちに応答することができる。FPNC状態マシンは、FPNCがTx Opに起因して枯渇後に補給する必要がある。FPNC状態マシンは、補給する必要があるフローを識別する待ち行列を利用して動作することができる。待ち行列は、FPNCによるサービスに関して優先順にあるフローから成ることができ、優先度は,局がU−APSDモードにあるか、フローがHCCA又はEDCAに基づくフローであるか、等の考慮事項によって決定される。
この代替実施形態の効果は、上記において詳述されるインターロックを用いるTXノードキャッシュリフレッシュブロック1835と同様であることができる。一般的には、入口からのトリガー及び/又は定期的リフレッシュに基づいてノードアレイキャッシュを更新することが必要になる場合がある。音声等の時間が極めて重要なアプリケーションに関しては入口からの瞬間的(又はほぼ瞬間的な)トリガーが望ましい場合がある。定期的リフレッシュは、(すなわち、フローに関するパケットのうちの1つ以上が送信のために送られており、ノードキャッシュ1810内に存在しなくなった後に)パケットバッファ内のパケットをTXノードキャッシュに補給するために用いることができる。(例えば、パケットが入口に到着し、ノードキャッシュが一杯であり、このためパケットは単にパケットバッファ内に入るだけである場合は、一般的に希望される結果は、キャッシュを一杯の状態に保つことである)。定期的リフレッシュは、実施形態例においては自主的に動作するバックグラウンドプロセスであることができる。当業者は、ノードキャッシュを一杯の状態に保つために、及び着信中の入力パケット及び発信中の送信パケットによって生み出されるニーズに応じてノードキャッシュを一杯にするために状態マシン、サービス中ビット、インターロック、及び様々なその他の技術を用いることができることを認識するであろう。
図21は、図18に関して上記において詳述されるリンクID 1844の実施形態例を示す。示されるように、TXノードアレイ1842に組み込まれたシャドーTXノードアレイのうちの1つにおいてフローを有するリンクIDを識別するリンクID A 2110が格納される。フィールド2120は、そのリンクIDとともに含まれているパケット(すなわち、ノード)数を識別する。この実施形態においては、リンクIDは物理層パラメータ(PHYレート等)及びセキュリティキーを識別するために用いられるため、統合は依然としてフローIDに基づく。このテーブルへのインデックスは、フローIDである。
同様に、リンクID B 2130は、TXノードアレイ1842内に組み入れられたその他のシャドーTXノードアレイ内のフローのリンクIDを識別するために格納される。そのリンクIDと関連づけられたパケット数は、フィールド2140に格納される。これらに加えてその他の様々なパラメータ及び/又は状態変数を、希望される場合に代替実施形態において用いるために、各々のフローと関連づけて格納できることに注目すること。
図22は、下位MACコア540の実施形態例の追加構成要素を示す。図18に関して上述されるように、複数のチャネルをTXエンジン1880に接続することができ、各々のチャネルは、1つ以上のパケットの送信準備が完了していることをTXエンジン1800に知らせるためのレディインジケータをアサートする。パケットを識別するノードは、TXノードアレイ1842において待機していることになり、これらのパケットに関する関連づけられたリンクIDが格納される。各チャネルに関して一組のこれらの構成要素の各々が存在することができる。図22は、これらのパケットが送信チェーン内を下流に移動するのに応じたこれらのパケットのさらなる処理を示す。
TXエンジン1880は、様々なレディ信号を受信し、様々なプロセス及びタスクの実行に関してこれらのレディ信号間で仲裁する。TXエンジン1880が送信のためにパケットを準備する態勢が整っているときには、共有メディアを用いるために利用可能な時間の長さを示すTXOPのサイズを知っている。しかしながら、データレートはリンク状態に基づいて可変であるため、TXOP内における送信すべきパケット数も変化する。実施形態例においては、特定のパケットが用いるOFDMシンボル数を決定する際に用いるためにレート有限状態マシン(FSM)2210が採用される。TXエンジン1880が(ノードの長さフィールド内に好都合に配置された)単位がバイトのパケットの長さを示すTX長さをレートFSM2210に引き渡す。リンクIDが(リンクID1844)から引き渡され、レートFSM2210がそのプロセスを開始するように指示するための開始信号が引き渡される。レートFSM2210は、パケットが用いるシンボル数を戻す。この情報は、以下においてさらに詳細に説明される統合を実行時に累積することができる各パケットに関するシンボル数を決定するために用いることができる。シンボル数、レート、等を決定するための様々な代替技術を採用可能であることに注目すること。パケットごとのシンボル計算を行う外部FSMの使用は、採用に適する多く例のうちの1つであるにすぎない。レートFSM2210の実施形態例が以下において詳述される。
TXエンジン1880は、メモリアービター、例えば上述されるメモリアービター1080、にも結合される。送信準備が完了している各々のパケットに関して、TXエンジン1880は、各々のノード内の情報に従ってパケットバッファからチャンクをフェッチし、次チャンクポインタによって識別されたあらゆるリンクされたチャンクをフェッチする。チャンクデータは、TXエンジン1880に戻され、TXエンジン1880において1つ以上のFIFO2220に引き渡される。この例においては、FIFO2220は、レガシープロトコルエンジン2210に内蔵される。1つ以上のFIFOへのデータの書き込みは、FIFOレディ信号、又はその他のフロー制御メカニズムによって規制できることに注目すること。上述されるように、及び以下において図48及び49に関してさらに詳細に説明されるように、代替実施形態においては、2つ以上のMACプロセッサとのインタフェースのためのTXエンジン1880への追加入力が存在することができる。代替実施形態例においては、プロセッサ210及びファームウェアは、低スループットパケットを処理するためのMACプロセッサを実装する。これらのパケットは、プロセッサメモリFIFO4950から(又は、代替実施形態においてはプロセッサメモリから直接)TXエンジン1880に引き渡すことができる。
上述されるように、802.11MAC処理をサポートするために既存のレガシープロトコル構成要素を用いて様々な機能を実行するのが好都合になる場合がある。その他の標準化されたプロトコルエンジンも採用可能であり、レガシープロトコルエンジン2210を改修して希望される様々な特長を提供することができる。レガシープロトコルエンジンの実施形態例においては、4つのEDCA待ち行列の各々に関して1つずつ、4つのFIFO2220 A乃至Dが存在する。HCCAチャネルに関する追加のFIFO2220Eが存在し、FIFO2220 F乃至Gは、ビーコン及びブロードキャスト/マルチキャストチャネルに関して採用することができる。FIFOは、単一のバッファとして(すなちわ、ビーコン信号を格納するために)採用できることに注目すること。送信用にパケットを受信するためにあらゆる数のFIFO又はその他のバッファ型を採用することができる。
レディアサーションを受信した時点で、TXエンジン1880は、第1のノードにおける指定に従って第1のパケットチャンクを適切なコアFIFOに入れる。直前において説明されたように、このことは、追加チャンクが存在する場合は第1のパケットが完了するまで継続することができる。同時に、送信することができる総パケット数は、レートFSM2210を用いて決定することができる。FIFOレディをモニタリングする一方で、TXエンジン1880は、手順を継続して残りのパケットを各々のFIFOに入れることができる。実施形態例においては、FIFO内にパケットを入れることは、レガシープロトコルエンジン2210を駆動してアクセス(EDCA型アクセス)求めて競争させ、(アクセスが入手されたとき、又はスケジューリングされたTXOP中に)送信を開始させる。
図23は、レートFSM2210の実施形態例を示す。受信されたリンクIDは、レートテーブル2310内へのインデックスとして用いられる。テーブル2310は、リンクIDに基づいて格納され、リンクと関連づけられた1つ以上のレートと、タイムスタンプ値(TSV)2311と、を具備する。レートテーブル2310は、様々な方法のうちのいずれかによって更新することができる。ファームウェアは、更新されたレートを提供することができる。受信されたデータレートベクトルフィードバックパケットは、レート情報を含むことができ、様々なレートを更新するために用いることができる。TSV 2311は、レートフィードバックが入っているパケットが受信されたときのタイムスタンプを示すために、従ってレート情報が新しいか又は古いかの表示を提供するために用いることができる。例えば、ある時間においてレートが更新されていない場合は、控えめな手法は、介在する時間枠においてチャネルが劣化している場合にレートを引き下げることである。ファームウェアは、時効が存在するかどうか及びレートをバックオフすべきかどうかを決定し、レートテーブルを更新することができる。実施形態例においては、4本のアンテナの各々に対応する4つのレートR1乃至R4 2312乃至2315が存在する。その他の情報、例えば固有操作モード又は他の拡散モードのいずれが用いられるか、をレート計算の際にも用いることができる。テーブル2310からのレート情報は、レート計算FSM2320に送られる。
各レートに関して、レート選択テーブル2330は、各々のレートに関して利用可能なシンボル当たりのバイト数を用いてファームウェアによって更新されるテーブルを具備する。一実施形態例においては、N=16レート2332が存在し、各々のレートは、シンボル当たりの対応するバイト数を有し、従って各レート選択値は4ビットである。シンボル当たりのバイト数は、加算器2335に引き渡され、加算器2335の出力は、統合レート累積器2340に向かう。
統合レート累積器2340は、統合レートを累積するために用いられ、出力は、加算器2335にフィードバックされる。累積器2340は、レート計算FSM 2320からのクリア信号によってクリアすることができる。利用可能なレートの各々に関して、シンボル当たりのバイト数が加算されて総統合レートが累積され、該総統合レートから、一定数のシンボルNS 2360を用いてストリーム数を示すことができる。NS 2360は、ストリーム数を示すために用いることができる。2345においてNS 2360が減じられて統合レートが提供される。NS 2360は、ファームウェアによって更新することができる。実施形態例においてバイト単位で引き渡されたパケットの長さが、2350において定数2365(同じくファームウェアによって更新可能)に加えられて真の長さが生成される。CONST 2365は、オプションの制約事項を示すことができる。例えば、連続するMPDUヘッダー間における最低限の分離を提供するAMPDU密度を採用することができる。除算器2355において、真の長さAが統合レートによって除算され、NSに関して正規化され、商及び余りが生成される。商は、加算器2375に引き渡されてシーリング関数が概念的に生成され、該シーリング関数において、2370内に何らかの余りが存在する場合は1つの追加シンボルを用いなければならない(すなわち、シンボルの一部分に充填され、このため、シンボル全体を採用しなければならない)。レジスタN SYM 2375は、レート計算FSM 2320によってイネーブルにされ、その結果得られたシンボル数がTXエンジン1880による引き渡し及び使用を目的として格納される。
図24は、概念的レガシープロトコルエンジン2210を示す。プロトコルエンジンが機能する様々なモードのうちの1つを示すためにモード選択信号を用いることができる。一般的には、MPDUが、送信が開始すべきであることを示すためのレディ信号とともに引き渡される。レガシープロトコルエンジンは、入力されたMPDUから暗号化された出力を生成することができる。実施形態例においては、(一般的には、典型的な802.11コア内に存在する)レガシープロトコルエンジンの暗号化機能が利用される。代替実施形態においては、当業においてよく知られるように、あらゆる型の暗号化装置を含めることができる。図24には、暗号化されない出力MPDUを生成するためにレガシープロトコルエンジン2210に引き渡される(例えば、WLAN120から受信された)暗号化された入力も示される。
図25は、PHY260への概念的リンクと接続された典型的なレガシープロトコルエンジンを示す。示されるように、RXベクトルが、受信されたデータ及びクリアチャネルアセスメント(CCA)信号とともにPHY260からレガシープロトコルエンジン2210に引き渡される。RXベクトルは、様々な情報、例えば変調型、受信データの長さ、及びその他のパラメータ、を具備することができる。特に、例えば上述されるレートFSM2210におけるレート決定に役立つデータレートフィードバックを戻すことができる。クリアチャネル評価は、コンテンションに基づくプロトコル(例えば、EDCA)を使用時にメディアへのアクセスに関して競争するために、様々なチャネルと関連づけられたタイマー2510とともに用いることができる。暗号化及び暗号解読は、ブロック2520において行うことができる。FIFO2220は、上述されるFIFOと同様であることができる。HCCAに関しては、当然のことであるが、送信がスケジューリングされ、予め決められた時間に開始することができる。符号化されたデータは、送信が開始すべきであることを示すTX要求とともにPHY260に送られる。PHY260に引き渡されるTXベクトルは、レガシー機能の結果得られた様々なパラメータを示す。実施形態例においては、レガシーモードで動作時には、レガシープロトコルエンジンの出力はPHY260における送信に関して十分であることに注目すること。
図26は、送信パケットのMAC処理のさらなる詳細を説明した実施形態例を示す。実施形態例においては、レガシープロトコルエンジン、MPDU(該当時は暗号化される)が統合モジュール2610に引き渡される。図25において詳述される実施形態とは対照的に、レガシープロトコルエンジン2210から出力された暗号化されたデータは、直接PHYには引き渡されない。実施形態例においては、暗号化されたMPDUのタイミングが設定された安定したストリームが統合モジュールに引き渡され、次に引き渡しを目的としてPHYに引き渡されるようにレガシープロトコルエンジン2210の改修を行うことができる。改修は、フレーム間スペース(例えば、SIFS)又は統合されたフレームを生成するために要求されないMPDUのその他の特長に対して行うことができる。様々な実施形態においては、統合されたフレームは、様々な形態であることができ、様々な型のパケット又はMPDUを具備することができる。パケットのタイミングを設定する、例えばタイムスタンプ、アクセスに関するコンテンション、等に関する様々な技術が上記において詳述されており、当業においてよく知られる。
統合対象となるパケット数は、TXエンジン1880において計算することができる。レートFSM2210への呼は、各パケットに関して行うことができ、パケットごとに戻されるシンボル数に関して、TXOPをそのシンボル数だけ減らすことができる。TXOP内に適合する総パケット数が決定されるまで各統合パケットに関する統合パケットカウントを増やすことができる。この情報は、統合モジュール2610に引き渡すことができる。
あらゆる数の統合フォーマット及び/又は方式を様々な実施形態において採用することができる。実施形態例においては、統合MPDU(A−MPDU)が統合モジュール2610から出力される。A−MPDU 2710のフォーマットは、図27に示される。示されるように、MPDUデリミッタ2720が、統合MPDU 2710内の各MPDU 2722間に配置される。A−MPDUのサブフレームの長さが4バイトの倍数であるようにするために、1つ以上のパッドシンボル2724をMPDU 2722の最後に挿入することができる。各MPDU 2722は、MPDUヘッダー2732と、MPDUペイロード2734と、フレーム検査シーケンス2736と、を具備する。この例においては、MPDUデリミッタ2720は、ゼロに設定された予約ビットを具備する長さCRCフィールド、MPDUの長さ、予約ビット及び長さのCRC、及びMPDUを走査及び検出するために用いることができる一意のパターンである。一実施形態例においては、一意のパターンは、文字“N”に関するASCII値に設定される。
今度は図26に戻り、統合MPDUをレートマッチングFIFO2620内に格納することができる(代替実施形態においては、レートマッチングFIFOは、採用されたPHYの型及びその特徴に依存して必要でないことがある)。レートマッチングFIFO2620は、PHY260における送信のための最終的なパケット引き渡しに関してMAC/PHYインタフェース545に結合される。
受信処理
図28は、下位MACコア540の受信構成要素を例示する実施形態例を示す。下位MACコア540において説明される受信構成要素、又はそれらから成る部分組は、図49に示される代替実施形態に関して後述される受信エンジンの一部分を具備することができる。WLAN120から受信されたパケットを含む情報データは、MAC/PHYインタフェース545に到着し、分割ユニット2802に引き渡される。上述されるように、図26及び27における統合に関して、A−MPDU例は、分割ユニット2802において着信データストリームをコンポーネントパケットに分離するために用いることができるMPDUデリミッタ2720を具備する。
その結果得られるMPDUストリームは、FCS及びフィルタリングブロック2804に引き渡される。このブロックにおいては、フィルタリング機能は、ブロードキャストパケット又はマルチキャストパケットを含む受信パケットのうちのいずれかがインスタントデバイスに関してアドレッシングされるかどうかを決定する。フレーム検査シーケンスも同様に検査される。次に、受信機に関してアドレッシングされ、フレーム検査に合格したパケットがFIFO2812に引き渡される。
実施形態例においては、パケットは、適宜アドレッシングされた良好なパケットであるとする仮定の下で、受信されるのに応じてFIFO内に格納される。これで、パケットは、無効パケットであるか又は現在の受信機に関してアドレッシングされていないことが判明した場合はFIFOから簡単にフラッシングすることができる。(1つの単純な制御メカニズムは、前FIFOポインタを保持すること、及び最近格納されたパケットがフラッシングされる場合にそのポインタを復元することである。)FIFO2812からの(フラッシングされない)パケットは、コアインタフェース2860に引き渡される。
RXコントローラFSM 2806は、図28において詳述される様々なブロックのうちのいずれかを制御するために採用される。特に、RXコントローラFSM 2806は、パケットが受信された時点で処理を開始し、パケットが受信チェーンを通過するのに従って即時の結果をイネーブルにする及び格納するための様々な制御信号を提供することができる。
この例においては、ヘッダーが受信されて処理のためにパケットパース2810に引き渡される。パケットのヘッダーから、送信長が知られ、さらに、パケットが開始する場所及びパケット内においてデータ及び/又は制御バイトを見つけることができる場所が知られる。ヘッダーは、パケット型(すなわち、802.11(a)(b)(g)(e)(n)、又はその他のサポートされるパケット型)も示す。
パケットパース2810は、パケットがフローIDからのポール型アクセス(例えば、コンテンションのないポール)から受信されたかどうかを知っている。これで、パケットパース2810は、予め決められた期間内(例えば、SIFS内)に応答が要求されるときに応答を開始するための信号を送信機に送る。パケットパース2810は、送信機が応答するのを可能にするためのフローID及びTXOP情報を引き渡すことができる。ブロックack要求が受信されたときには、受信されたビットマップは、要求された場合に予め決められた時間枠内においてブロック確認応答(例えば、即時ブロックack)を行うために送信機に引き渡すこともできる。ブロックack、及びその他の即座応答処理、例えばU−APSD、が以下においてさらに詳細に説明される。
パケットパース2810は、着信パケットを格納するために必要なチャンクポインタ数を決定するチャンクポインタFSM 2850にチャンク長を引き渡す。チャンクポインタFSMは、上記において導入されたRXチャンクポインタキャッシュ840からチャンクポインタを取り出す。この実施形態例においては、チャンクは、上述されるチャンクと同一であるが、受信パケットは、真の連結リスト待ち行列の複雑さ及び余分のメモリに関する要求事項を要求しない。むしろ、より単純化されたアレイを採用することができる。この実施形態は、以下において図33に関してさらに詳細に説明される。代替実施形態においては、RXパケットは、希望される場合に送信処理の際に用いられる連結リスト構造と同一の連結リスト構造を用いることもできる。チャンクポインタFSM 2850は、パケットとともに用いるために追加チャンクを取り出す必要があるときに又はRXチャンクポインタキャッシュ2840を更新時に(メモリアービター1080を通じて)パケットバッファ250とインタフェースする。実施形態例においては、選択されたチャンクサイズ及び典型的パケット長が与えられた場合に1つのパケット当たり最大で4つのチャンクポインタが必要になる場合がある。これらのチャンクポインタは、受信処理チェーンの残りの部分を横断するのに従ってパケットのヘッダー内に格納され、パケットバッファ内への最終的なパケットの書き込みに用いられる。
コアインタフェース2860は、拡大RXベクトルに含まれているチャンクポインタ及びパラメータを(ハードウェアテーブル2820から)取り出し、FIFO 2812から受信されたパケットのヘッダーに加える。次に、上述されるように、主に実施形態例における暗号解読に関して用いられるレガシープロトコルエンジン2210に対してパケットが引き渡される。実施形態例においては、及び利用可能な典型的レガシープロトコルエンジンにおいては、ヘッダーは無視されることに注目すること。従って、この例において説明されるように制御情報をヘッダー内に格納することによって様々な制御メカニズムを実行することができる。レガシープロトコルエンジン2210からの暗号解読されたパケットは、RX FIFO2870に引き渡される。実施形態例においては、RX FIFO 2870は、共有することができ又は図5に示される同等のFIFO 572と同一であることができる。
ハンドオフ及び出力(egress)が以下においてさらに詳細に説明される一方で、その基本構造が図28に示される。この構造の一側面は、ハンドオフ決定が実際のハンドオフプロセス自体から切り離され、その他のパケットが出力ハンドオフを待っているときに発生する可能性があるボトルネックを待たずにパケットが受信及び処理されるのを可能にすることである。ボトルネックは、順序どおりのパケット引き渡しが規定されおり、1つ以上のパケットに関して再送信が要求されるときに発生する可能性がある。この点が以下においてさらに詳細に説明される。
RX FIFO2870からのパケットは、上述されるように、メモリアービター1080を介してパケットバッファメモリ250へのアクセス要求を行うメモリ書き込み2875に引き渡される。パケットがパケットバッファに書き込まれるのを待っている間に、そのパケットに関するパラメータがハンドオフ決定ブロック2880に引き渡されてハンドオフ決定を開始する。パケットがパケットバッファ内に完全に書き込まれる前に急速ハンドオフ手順が生じるのを防止するために、メモリ書き込み2875からハンドオフ決定2880に書き込み完了信号が送信される。
ハンドオフエンジン2890がハンドオフ決定2880に接続される。ハンドオフ決定2880とハンドオフ2890との間における対話に関する様々な信号例が示されており、以下においてさらに詳細に説明される。ハンドオフエンジン2890は、メモリアービター1080を介してパケットバッファからパケットを取り出し、パケットを出力のために最終的に引き渡す。ハンドオフエンジン2890は、パケット型に依存して、デフラグブロック2892を用いて、例えばパケットフラグメントからヘッダーを取り除き、フラグメンテーションされていないパケットをパケット出力時における引き渡しのために再形成することができる。以下において図48に関して詳細に説明されるように、フラグメンテーションはオプションであることができ、関連する構成要素を省略することができる。時々、1つ以上のパケットを取り除くべき状況が生じることがある。フラッシュブロック2894は、これらのタスクを実行するためにハンドオフエンジン2890に接続される。待ち行列、ポインタ、ノード、及びチャンクに関する連結リスト構造を維持することに関連づけられた様々なその他のメモリ管理機能もこれらのブロックにおいて取り扱うことができる。
RXサーチコントローラ2814は、FIFO2812に入るパケットをモニタリングする。RXサーチコントローラは、パケットに関するフローIDを決定する。実施形態例においては、上記の図10におけるような入力パケット処理に関して説明されるように、TA及びTID探索テーブルを採用することができる。ハードウェアテーブル2820は、フロー及びチャンクの両方に関する状態及びパラメータを維持するために採用される。以下においてハードウェアテーブル2820がさらに詳細に説明され、図3及び4に関して上述される2つの構成に関する実施形態例を含む。その関係においては、ハードウェアテーブル2820は、ハードウェアテーブル320の構成要素であることができる。
一実施形態においては、入力及び出力(そして可能な場合は送信処理)に関して別個のハードウェアテーブルが維持される。代替実施形態においては、1つ以上の機能がハードウェアテーブルを共有することができる。その場合は、ハードウェアテーブル2820は、図3及び4において詳述されるようにハードウェアテーブル320と実質的に同一であることができる。テーブルを共有することは、複数の要求に関する仲裁と関連する複雑さを発生させること、及び要求されるアクセス数に関する十分な帯域幅の確保が必要になることを当業者は認識するであろう。他方、テーブルを共有することは、全体的な面積を縮小することができ、複数のテーブルにわたって両方に共通するパラメータの更新数を減らすことができる。例えば、結合された受信及び入力ハードウェアテーブルを有するAPについて検討する。TSID及びTIDは、APが以前に送信した先であるSTAからAPが受信中であるときには同じである。行先MACアドレス及び送信MACアドレスが同じであるということは常に真であるわけではないが(行先には追加の結合されたデバイスが存在する可能性がある)、同じである状況が存在する。これらの状況においては、テーブルを共有することに益がある。従って、結合テーブルは、アドレスが同じでない場合にいずれかのテーブルが単独で受け入れることになる場合よりも大きくすることができる。しかしながら、共有することは、面積上の利点を生み出すことができる。
上述されるように、実施形態例においては、ファームウェアが更新中にリストの順序を再設定するのを可能にするピンポンキャッシュ、及びシャドーリストからのサーチコントローラに関する同時アクセスを採用することができる。ハードウェアテーブル2820をインデキシングするために用いられるフローIDを入手するためにバイナリ探索が行われる。
図29は、STAとして構成されるハードウェアテーブル2920の実施形態例を示し、図3に関して上述される配置と類似する。従って、この場合は、STAは(この例においては)16のフローしかサポートしないため、フロー及びリンクと関連づけられたすべての様々なパラメータはハードウェアテーブル内において維持される。ハードウェアテーブル2820には、各々のサポートされるフローに関する送信アドレス2912、TID2914、及びフローID 2916のリストが存在する。従って、フローIDは、TA+TIDから取り出すことができ、該当するRXフロー状態テーブル2920に関するインデックスとして用いることができる。実施形態例においては、ファームウェアは、順序が設定されたテーブルを作成し、1つの又は他のテーブルに関して作業するようにHWに指示する。バイナリ探索は、HWにおいて現在のテーブルを対象として行われる。新しいフローを追加する必要があるときには、ファームウェアは、該フローを待機テーブルに追加し、順序を設定し、ハードウェアの現在のテーブルを待機テーブルに切り換える。これで、原テーブルが新しい待機テーブルになる。RXフロー状態テーブル例2920が以下において図31に関して説明される。
ハードウェアテーブル2920には追加のリンク専用パラメータを含めることもできる。これらのパラメータは、Rxハードウェアテーブル2920に格納することができるリンクIDによってアドレッシングすることができる。例は、レート決定に関して用いるために上述されるデータレートベクトルフィードバック2930と、レート決定と、パケット形成と、統合と、を含む。受信プロセッサは、遠隔デバイスから引き渡されたメッセージからのこの情報へのアクセスを有することができ、この情報をハードウェアテーブル2920に格納することができる。上述されるように、リンク別セキュリティキー2940を様々な型の暗号化に関して用いることができる。様々な暗号化プロトコルをサポートするために様々なセキュリティキーの型を格納することができる。レガシー複製検出ブロック2950は、正確に受信された最後のパケットのシーケンス番号を格納し、複製検出目的で現在のパケットのシーケンス番号をこの値と比較することができる。
図30は、上記において図4に関して詳述されるように、アクセスポイント又はスーパーステーションにおいて用いるように構成されたハードウェアテーブル2820の実施形態例を示す。この例においては、様々なポインタ3002は、ハードウェアテーブル2820内のMACインデックス3004と関連づけられる。この例においては、リンクID 3006も各MAC IDとともに格納されることに注目すること。リンクID 3006は、代替として、例えばSRAM 330等の代替格納場所においてその他のパラメータとともに格納することが可能であることに注目すること。(リンク及びフローに関する様々なパラメータがハードウェアテーブルに格納された)図29に示されるハードウェアテーブル2820とは対照的に、リンクID3006以外のすべてのパラメータが代替メモリ、例えばSRAM 330に格納される。
SRAM 330は、共通レートテーブル3010A乃至Nを具備し、これらのテーブルの各々は、各MACアドレス(すなわち、最大で16のフローをサポートすることができるリンク)に関するポインタを具備する。フローインデックス3020によって指し示されたパラメータテーブル内に様々なフローに関するパラメータが格納される。この格納は、実際のパラメータに関する1つのレベルのインダイレクションを提供する。実施形態例においては、SRAM 330は、RX状態テーブル2920等のテーブルを格納するためにも用いられ、その一例が以下においてさらに詳細に説明される。従って、共通レートテーブル3010に示されるように、各リンクに関して、最大数のフローに関するサポートがインデキシング方式内に含まれている。しかしながら、フローが追加されるのに従ってメモリ使用量が増大する可能性がある。メモリは、フローがアクティブになる前にパラメータを格納するために割り当てる必要がない。従って、所定のリンクに関して、1つ又は2つのみのフローがアクティブである場合は、1つ又は2つのRXフロー状態テーブル2920のみを作成して充填する必要がある。
図30には、単にセキュリティキー3044及びビットマップ3046のみを含む代替テーブル3042も示される。この例は、802.11(g)パケットとともに用いるのに適した縮小パラメータセットを示す。該代替実施形態においては、縮小された状態テーブルを用いることは、追加のメモリアクセスと関連するメモリ及び時間を節約することができる。しかしながら、一実施形態においてはすべてのパケット型に関して共通の構造を用いることもできる。
以下では、RXフロー状態テーブル例2920の詳細が図31に関して説明される。しかしながら、ここでは1つの構成要素であるビットマップ3130が例示される。ビットマップポインタ3050は、ビットマップ3130を指し示した状態が示される。ビットマップ3130は、実施形態例においては、SRAM 330にも格納される。このレベルのインダイレクションは、要求可能な最大メモリの再割り振りとは対照的に、メモリ使用量がニーズに応じて増大するのを許容する一方で、単純な共通するビットマップアクセスフォーマットを可能にする。従って、RXフロー状態テーブルを必要に応じて増大させる能力と同様の方法で、メモリを再割り振りする必要なしに様々な型のビットマップをサポートすることができる。例えば、フラグメンテーションがサポートされるときには、ビットマップは、各々が16のフラグメントを有する64のパケットを具備することができる。このビットマップは、64パケットウィンドーにおいて各パケットに関して単一のビットを有する単純なブロックackビットマップによって要求されることになる場合よりもはるかに大きいビットマップである。従って、フラグメンテーションを要求するフローに関しては、より大きいブロックackビットマップを作成することができ、他方、より少ないメモリを要求するブロックackビットマップは、より小さいビットマップを用いて作成することができる。
この図は、向上された柔軟性及びより効率的なメモリの使用に備えることを含む様々なメモリ構成上の側面を示す。以下では、追加ブロックack処理上の側面がさらに詳細に説明される。
図31は、RXフロー状態テーブル2920の実施形態例を示す。様々なフィールドが例示される。代替実施形態においては、追加フィールドを導入することができ、又は示されるフィールドの一部を省略することができる。一般的には、当業者にとって明確になるように、RXフロー状態テーブル2920、フロー別アレイ状態1902、TXフロー状態テーブル1030、及び同様のフロー別テーブルを含む本明細書のフロー状態テーブルのうちのいずれかを結合させるか又は分離させてあらゆる数のフロー別テーブルにすることができる点に注目すること。
開始シーケンス番号3102は、ブロック送信における開始パケットのシーケンス番号を示すために用いることができる。開始シーケンス番号は、送信されたパケットが受信されたときに更新することができる(すなわち、ウィンドーが前方に移動する)。一実施形態においては、既存の開始シーケンス番号及びウィンドーサイズ3104は、予想される着信パケットのシーケンス番号を決定することができる。しかしながら、送信機は、このシーケンス番号限度を超えるパケットを送信することが許容され、その場合は、受信された最大シーケンス番号を取り出して(ウィンドーサイズ−1)を減じることによって計算することができる。開始シーケンス番号は、着信したBAR(Block_Ack要求)によって明示で更新することもできる。以下では様々なブロック確認応答処理技術がさらに詳細に説明される。一例においては、ウィンドーサイズは、受信機において所定の送信機に割り当てられた(単位がパケットの)バッファを意味することができる。その場合は、送信機は、受信機においてウィンドーサイズを超える確認応答されないパケットを送信すべきでない。
即時ブロックackフィールド3106は、送信機が即時の又は遅延されたブロック確認応答を予想しているかどうかを受信機に示すために用いることができる。即時ブロック確認応答のサポートは、現在の802.11n基準草案においては必須になっている。
ビットマップ3130は、図29に関して上述されるように、ハードウェアテーブル2820がSTAとして構成されるときに実際のブロックackビットマップであることができる。代替構成においては、ビットマップ3130は、図30に関して上述されるように、実際のビットマップを指し示すポインタであることができる。イーサネットヘッダー3132は、パケットの出力準備時にMACヘッダーを該当するイーサネットヘッダーと交換するために格納される。WINポインタ3134は、受信機によって格納されて最終的にはより高い層にハンドオフする必要があるパケットの物理的アドレスを保持するデータ構造を指し示すポインタである(以下においてさらに詳細に説明されるハンドオフ技術例を参照すること)。一例においては、これらのパケットは、より高い層に順にハンドオフされるためにバッファ内に格納される。このデータ構造の先頭に穴(パケット損失)が存在する場合は、Rxは、より高い層に整然と順序通りにパケットをハンドオフするためにこの穴が充填されるまで待たなければならない。以下において詳述されるウィンドーポインタ3320は、このフィールドにおいて用いるのに適したポインタの一例であることに注目すること。
一例においては、旧開始シーケンス番号3138を、最初に開始シーケンス番号に等しく設定することができる。着信パケットが開始シーケンス番号を変更させるときには、受信機は、旧開始シーケンス番号から現在の開始シーケンス番号までの全パケットをより高い層に渡すことができる。この動作が実行された後に、旧開始シーケンス番号を現在の開始シーケンスに等しく設定することができる。リンクID 1340は、フローと関連づけられたリンクを示す。このことは、WLAN 120において受信又は送信する際に用いるためのリンク専用パラメータを取り出すために用いることができる。上記では様々な例が詳述されている。受信すべきフラグメントがそれ以上存在しないことを示すフィールド3136を採用することができる。フラグメンテーションが実施されない様々な実施形態においては、又は代替MAC処理ユニットにおいて実施されるときには、このフィールドは省略することができる。
図32は、ハードウェアテーブル及びメモリを様々な構成で構成するための方法の実施形態例を示す。図29乃至31に関して論じられている技術は、その他のハードウェアテーブル、例えば上記において詳述される送信フロー状態テーブル1030、とともに同様に適用可能であることに注目すること。送信テーブルを構成する詳細は、説明を簡潔にするために省略される。ハードウェアテーブルは、様々な構成要素(例えば、受信、送信、入力、出力、等)をサポートするために結合できることを思い出すこと。受信ハードウェア、フロー状態テーブル、RAM、及び/又はパケットバッファに関するインダイレクションレベルによって識別される原則は、本明細書において説明されるその他の状態テーブル、又はその組合せに対しても同様の効力を持って適用可能である。
一般的プロセス3200は、図32において説明される。この例においては、第1、第2の及び第3のメモリが説明される。本明細書において詳述されるように、様々な型のあらゆる数のメモリを採用可能であることに注目すること。一実施形態例においては、メモリ1は、ハードウェアテーブル、例えばハードウェアテーブル2820又は320である。メモリ2は、より大きいメモリ、例えばSRAM 330である。メモリ3は、この場合は外部メモリであるが、内部の第3のメモリも予想される。この例においては、メモリ3は、SDRAM340であることができる。
決定ブロック3210において、第3のメモリがパケットバッファに関して用いられる場合は、3216に進み、無線通信デバイスの様々な構成要素を第1のモードにおいて構成する(すなわち、MACプロセッサ310ASIC 310における構成要素又は様々なその他の構成要素)。実施形態例においては、第1のモードは、外部RAM、例えばSDRAM340、に格納された外部パケットバッファを利用する。
決定ブロック3210において、第3のメモリがパケットバッファに関して用いられない場合は、3212に進み、無線通信デバイスの様々な構成要素を第2のモードで構成する。実施形態例においては、第2のモードは、上述されるSTA型モードであり(ここで、SRAMはパケットバッファに関して用いられる)、パラメータはハードウェアテーブルに格納される。
3216において、第2のメモリ内のデータ構造を指し示すMACアドレッシングされたポインタを有する第1のメモリ(ハードウェアテーブルであることができる)を構成する。3218において、データ構造を有する第2のメモリをセットアップする。これらのデータ構造は、例えば図30に関して上述されるような様々な追加のインダイレクションレベルを含むことができる。例えば、第1のデータ構造は、MACアドレスと関連づけられたフローを識別することができる。フローIDは、RXフロー状態テーブル又はTXフロー状態テーブル等の追加テーブルをインデキシングするために用いることができる。さらに、1つ以上のテーブル、例えばRXフロー状態テーブル、は、フローと関連づけられた追加のデータ構造を指し示すポインタ(例えば、ブロックackビットマップの格納場所を指し示すビットマップポインタ)を有することができる。3230においては、第3のメモリにおいてパケットバッファを構成する。一例においては、パケットバッファを構成することは、様々なフリーポインタリスト(例えば、フリーノードポインタリスト710及びフリーチャンクポインタリスト720)をセットアップすることと、ノード720及びチャンク740用のスペースを割り振ること、とを含む。さらに、関連づけられたフリーウィンドーポインタリストを有するアレイを割り振ることができる(例えば、パケットの受信処理のために用いられるアレイ)。
ファームウェアは、適切なデータ構造を有する様々なメモリをフォーマット化するために要求されるステップのうちの多くを実行することができる。必要な場合は、デバイス内の構成要素にモードを示すために様々なレジスタ設定又はその他の様々な変数設定技術を用いることができる。これらの技術は、当業者によく知られるであろう。以上のように、第1のモードが構成され、プロセスは停止することができる。
3212において、直前において説明されたような様々なデータ構造を有する第1のメモリを構成する。この場合は、メモリ1は、ハードウェアテーブルであることができ、データ構造は、必ずしも間接的にアクセスされないが、図29において説明されるとおりであることができる(例えば、ハードウェアテーブル内のフローごとにインデキシングされたRXフロー状態テーブル)。3214において、3220においてメモリ3に関して上述されるとまったく同じやり方で第2のメモリをパケットバッファとして構成する。このようにして、第2のモードが構成される。これで、プロセスは停止することができる。本明細書において詳述されるMAC処理は、継続することができる。
図33は、RXパケットアレイをサポートするように構成されたパケットバッファ250の一部分に関する代替実施形態を示す。この実施形態は、図6において示されたパケットバッファ250と同様である。しかしながら、この構成においては、図6の連結リスト待ち行列のデータ構造は、ノードアレイ3330によって置き換えられる。アレイデータ構造の使用は、幾つかの単純化を可能にする。この例においては、ノードアレイ内のノードは隣接しており、このため、次ノードポインタ612は要求されない。従って、ノード610は、縮小ノード3310に置き換えられる。ノード3310内に残っているフィールド、長さ614、シーケンス番号616、及びチャンクポインタ618は、図6に関して説明されるとおりである。より小さいノードは、メモリ使用量を低減させる。
上述のように、チャンク620は、様々な長さのパケットを格納するために用いられる。1つの相違点は、アレイ構造は待ち行列を形成するためのノードのスレッディングを要求しないことである。従って、直前において述べられたように、ノードの所在を指し示すための次ノードポインタが要求されない。待ち行列末尾ポインタ640及び待ち行列先頭ポインタ630は、希望されるノードアレイ3330がパケットバッファ内のどの場所に所在するかを識別する単一のポインタ、ウィンドーポインタ3320、に置き換えられる。この修正されたノード/チャンク構造の使用は、本明細書における教義に照らして当業者にとって明確になるであろう。繰り返すと、図6の構造は、その状況に関しても完全に適するため、直前において説明されるアレイ構造は、RX処理のために要求されない。しかしながら、ノードアレイ3330は、図33において示されるように採用されたときには、最大で、パケットアドレス格納場所に値する1つのウィンドー全体を格納することができる。ノードアレイ3330は、ウィンドーオフセットによって現在の開始シーケンス番号に合わせてインデキシングすることができる。この場合は、ノードアレイ3330は、パケット格納場所の環状バッファとして用いることができる。
ハンドオフ処理
この節においては、ハンドオフ処理がより詳細に説明される。ハンドオフ決定2880及びハンドオフエンジン2890は、関連づけられた信号及びその他の相互に接続されたブロックとともに、図28に関して紹介された。以下ではハンドオフに関連する幾つかの側面が例示される。
一側面においては、ハンドオフ決定は、ハンドオフプロセス自体から分離される。決定プロセスは、ライン速度で行うことができ、ハンドオフエンジンは、バックグラウンドにおいて自主的に動作する。この側面が有用であることができる1つの状況例は、ブロックACKに関するサポートによって示される。802.11(g)又は(b)等の初期の無線パケットシステムにおいては、ブロックACKに関するサポートは存在しなかった。パケットが到着したときには、確認応答されるか又は確認応答されない。パケットが確認応答される場合は、ハンドオフされ、後続パケットの送信が再開する。パケットが確認応答されない場合は、送信機は、正確に受信されるまでパケットを再送信する(又は、プロセスが予め定義された限度を超えることに起因して捨てられる)。従って、パケットは、本質的には、到着するのに従って順にハンドオフされる。
ブロックACKをサポートするシステムにおいては、順序が乱れているパケットを受信する可能性がある。パケットが正確に受信されたときには、関連づけられたビットがウィンドービットマップにおいて設定される。確認応答されないパケットの場合は、関連づけられたビットをゼロに設定することができる。将来においてパケットの再送信を試みることができる。その間に、後続するパケットを受信してハンドオフのために格納することができる。パケットが順にハンドオフされることが意図されているシステムにおいては、確認応答されないパケットは穴を生成し、確認応答されないパケットが正確に受信されるのを待っている間に後続して受信されるパケットのハンドオフを立ち往生させる。再送信後に単一のパケットを受信することができ、該パケットが穴を満たすことになり、幾つかのパケットが後続して受信された時点で1つのグループのパケットをハンドオフのために直ちに利用可能になる。このことは、ハンドオフ待ちのパケットのバックログを生み出す可能性があり、ハンドオフレーテンシーが発生することがある。ハンドオフ決定をハンドオフエンジン処理から分離することは、ハンドオフ決定ブロックがライン速度で動作するのを可能にし、その一方で、パケットのバックオフがハンドオフに関して処理される。ハンドオフエンジンは、自主的に動作することができ、ハンドオフメモリへのインタフェースは受信速度と比較して高速であると仮定した場合は、ハンドオフエンジンが追いつくことができる。この方法により、パケットバックログは、受信機の全体的スループットを制限しない。
他の側面においては、ハンドオフ決定と処理を分離することは、フローハンドオフ優先順位設定を考慮するものである。例えば、音声、映像又はその他の優先データ等の遅延の影響を受けやすい情報は、優先度がより低いデータとは異なる形で取り扱うことができる。
図34は、無線ネットワークに関するエンドツーエンド優先度方式を示し、入力ポリシング及び優先度に基づくハンドオフを含む。図34においては、システム100は、入力パケットを受信するための入力ポリシング機能3410を含む。上記において詳述されるように、様々な入力ポリシング機能は、着信する出力パケットの優先順位設定を考慮する。無線通信LAN120は、入力ポリシングブロック3410を優先度に基づくハンドオフブロック3420と結合させる。(当業においてよく知られる)QoSWLANは、識別されたパケット及び/又はフローがその他の型のパケット又はフローよりも優先されることを考慮する。しかしながら、先行技術であるQoS処理は、WLAN120における受信機及び送信機からのポイントツーポイント通信のみにおいて生じる。優先度に基づくハンドオフブロック3420は、優先度を組み入れたハンドオフ決定を行う。この場合は、パケットは、おそらく優先度又はQoSに従って既に送信されて受信されている。優先度に基づくハンドオフは、WLAN120等のWLANにおけるQoS概念に加えるものである。従って、より高い優先度を有するパケットは、より低い優先度を有するパケットよりも早期に出力のためにハンドオフすることができる。
この方法により、QoSは、送信機側における入力から全体を通じて受信機における受信後の出力に至るまで維持することができる。入力ポリシング3410は、入力側を通じてパケットの優先順位を設定することができ、QoS WLAN120において優先度を有する状態で送信され(QoSがサポートされる場合)、受信機においてハンドオフ遅延が存在する場合は、より高い優先度のパケットに第1の優先度を与えることができる。入力ポリシング及び優先度に基づくハンドオフのいずれも、QoS WLANを有する状態で又は有さない状態で展開できることに注目すること。従って、優先度に基づくハンドオフは、1つ以上のその他のQoS技術を有する方式において用いることができる。これらの側面は、ホストプロセッサに依存しないアプリケーションにおいても同様に望ましいことがある。例えば、より高い層のアプリケーションは、パケットがMACプロセッサに引き渡される順序を決定するための何らかの優先順位設定能力を有することができる。より多くのデバイス、例えばカメラ、デジタル音楽デバイス、及びその他、が無線接続に移行するのに従い、該デバイスは、限られたホスト処理を有する(又はまったく有さない)場合がある。従って、入力ポリシングは、効率的な多フローの送信及び受信を可能にするために有用に採用することができる。
本明細書において詳述されるような入力ポリシング及び優先度に基づくハンドオフは、有利なことに、(すなわち、ノード、チャンク、及び待ち行列に関する連結リストを用いて)パケットの管理に関して連結リスト構造と結合させることができるが、所定の実施形態においては両方の結合は要求されない。特に、パケットが(入口を介して又は磁気を通じて)到着するに従ってパケットを動的に割り当てることは、高優先度パケット又はフローと低優先度パケット又はフローとの間において柔軟にメモリを割り当てることを可能にする。
連結リスト構造は、より高い優先度のパケットにサービスを提供する必要があることが混雑レベルによって要求されるときにサービス順序を効率的に変更し、さらに混雑が収拾されたとき全パケットクラスにまったく同じ容易さでサービスを提供する柔軟性を考慮する。
図35は、ハンドオフ決定2880及びハンドオフエンジン2890の動作を例示する方法3500の実施形態例を示す。3510において、ハンドオフ決定2880は、パケットが受信されていることを示すトリガーを受信する。実施形態例においては、書き込み完了信号は、一部分が書き込まれたパケットが偶発的にハンドオフされるのを回避するために、パケットがどの時点でパケットバッファ内に完全に書き込まれたかを示す。以下においてさらに詳細に説明されるように、ハンドオフ決定を行うために必要な情報が、RX FIFO 2870からハンドオフ決定2880に引き渡される。
3520において、ハンドオフ決定2880は、パケットをハンドオフに関して利用可能であるかどうかを決定する。一般的には、ハンドオフに関してパケットの優先順位を設定するためのあらゆる方法又は技術を用いることができる。一例においては、上述されるように、フローに割り当てられた優先度は、到着順だけでなく優先度にも従ったフローハンドオフに基づく順序の再設定を考慮する。優先順位設定は要求されないことに注目すること。フローは、パケットが利用可能になるのに応じて順にハンドオフすることができる。
3530において、パケットがハンドオフのために利用可能である場合は、ハンドオフに関して利用可能な1つ以上のパケットと関連づけられたフローIDを示すためにハンドオフ待ち行列が更新される。3540において、ハンドオフエンジン2890は、利用可能なパケットを自主的にハンドオフし、ハンドオフ決定2880が次の受信されたパケットを待ってそのパケットに関するハンドオフ決定を行うのを可能にする。
上述される一般的概念は、次の実施形態例によってより明確に理解することができる。次の例においては、ハンドオフ決定2880は、ハンドオフ決定を行い、ハンドオフ用のパケットと関連づけられた待ち行列を更新し、ハンドオフを自主的に処理するための指令をハンドオフエンジン2890に発行する。図28において例示されるように、ハンドオフ決定2880は、ハンドオフを開始するためのフローID及び関連パラメータを引き渡す。実施形態例においては、ハンドオフに関して利用可能なパケット数を示すハンドオフカウント、これらのパケットと関連づけられたフローID、及びフロー型が、ハンドオフ決定2880からハンドオフエンジン2890に引き渡される。
さらに、割り込み信号を採用することができる。このオプションの割り込みは、より高い優先度のパケットが受信されていて、ハンドオフ決定2880がより高い優先度のパケット及びそのフローを現在ハンドオフ中のパケットの先頭に移行させたいときに用いることができる。割り込み技術は、当業においてよく知られており、採用されるハンドオフ決定及びハンドオフエンジンの型に依存して、ポーリング型割り込み、ベクトル駆動割り込み、及びその他の様々な割り込みを含むことができる。当業者は、ハンドオフ決定ブロック2880及び/又はハンドオフエンジン2890の両方ともが状態マシン、ソフトウェア又はファームウェアのプロセス、一般的又は専用のプロセッサ、専用ハードウェア、又はそのあらゆる組合せを用いて採用できることを認識するであろう。この例においては、ハンドオフエンジン2890は、ハンドオフが実施されていることを示すハンドオフ完了信号を、ハンドオフされたパケット数とともに戻す。この実施形態例が以下においてさらに詳細に説明される。
ハンドオフ決定ブロック2880とハンドオフエンジン2890との間でのタスクの分離が上記において概説されており、フロー優先順位設定及び潜在的ボトルネックの管理を含む利益の一部が説明されている。この実施形態例においては、ハンドオフ決定とハンドオフエンジンとの間における一般的インタフェースは、各フローに関するハンドオフカウントパラメータを維持することである。ハンドオフ決定ブロックは、基本的には、ハンドオフカウントを増やすことによってフローのハンドオフの必要性を示す。ハンドオフエンジンは、パケットのハンドオフを実施するのに従って、ハンドオフカウントを減らす。従って、このパラメータは、一般的には、所定のハンドオフエンジンを有するハンドオフ決定実施形態間において用いることができる。
この技術は、FIFOの代替使用と対照的であることに注目すること。FIFOは、本明細書において詳述される様々な実施形態と関連してハンドオフに関して採用することも可能である。しかしながら、ハンドオフ待ちであるパケット数の可変性が高いことに起因して、一定の事情下においては、FIFOは、かなり深くする必要がある。さらに、FIFOの複雑さを増大させずに、優先度を受け入れるためにパケットの順序を再設定するのは困難であることにも注目すること。実施形態例においては、複数の優先度レベルの各々に関して先入れ先出し式待ち行列が維持される。実施形態例においては、4つの優先度がサポートされる。当業者は、あらゆる数の待ち行列及び/又は優先度をサポートできることを認識するであろう。
代替実施形態においては、ハンドオフ決定ブロック2880は、ハンドオフ決定を行い、待ち行列の状態及び該待ち行列においてハンドオフ待ちのパケットを示すために1つ以上の待ち行列及び/又は状態テーブルに入れることができる。示されるように、ハンドオフ決定2880からの明示のトリガリングを要求せず、むしろ、ハンドオフに関していずれのパケットを利用可能であるかを決定するため及びこれらのパケットがハンドオフされる順序の優先順位を設定するために様々な待ち行列の状態及び状態テーブルを自主的にモニタリングするハンドオフエンジン2890を採用することができる。当業者は、これらの実施形態及びその他の代替実施形態を本明細書における教義の適用範囲内において容易に採用するであろう。この代替実施形態の詳細は省略される。
図36は、上述されるように、ハンドオフ決定ブロック2880において採用するのに適した、ハンドオフ決定を行うための方法3600の実施形態例を示す。3610において、パケットが受信されたときに、3620に進んで受信されたパケットに関するフローを処理する。以下において一プロセス例がさらに詳細に説明される。一般的には、ブロック確認応答をサポート時に、パケットを処理することは、穴が充填されている(すなわち、より高いシーケンス番号の1つ以上のパケットが正確に受信されており、前シーケンス番号を有するパケットが再送信後に受信されるまでハンドオフを待っている)かどうかを決定することを含む。当然のことであるが、順に正確に受信されたパケットは、穴を充填せずにハンドオフに関して利用可能である(すなわち、ハンドオフを待っている後続番号のパケットが存在しない)。パケットを受信することは、1つ以上のパケットをハンドオフに関して利用可能であることをトリガーすることができ、又はパケット自体が、ハンドオフ準備の整った唯一のパケットであることができる。受信されたパケットが既存の穴を充填しない場合は、そのフローに関して利用可能なハンドオフが存在することができない。プロセスは、決定ブロック3610に戻る。
この例においては、フローは、パケットプロセスブロック3630と待ち行列プロセスブロック3630との間で交互する(以下においてさらに詳細に説明される)。方法3600は、ハンドオフ待ち行列の処理に関するプロセス及びパケットが着信時における受信ためのプロセスの2つの同時プロセスを示す。当業者は、該並行処理を実行するための非常に多くの技術を認識するであろう。実施形態例は、1つの例示であるにすぎない。
図37は、上述されるように、ブロック3620として採用するのに適した、受信パケット処理方法の実施形態例を示す。3710において、パケットが受信されている。そのパケットと関連づけられたフローが決定状態テーブルに記入されているかどうかを決定する。決定状態テーブル例が図40に示される。図40に示された決定状態テーブル例4000においては、いずれかの1つの時点においてNのサポートされるフローIDが存在する。実施形態例においては、最大で256のフローをサポートすることができる。決定状態テーブル4000は、各フローIDに関して、一組のパラメータ4010を含む。実施形態例においては、決定状態テーブル4000は、各フローIDに関して、決定オフセット4012と、ハンドオフカウント4014と、次ポインタフィールド4016と、待ち行列内ビット4018と、優先度フィールド4020と、を含む。
図37に戻り、3710において、決定状態テーブル4000内にフローが存在しない場合は、3715に進んで決定状態テーブルにフローを追加する。フローが決定状態テーブル内に存在することが決定された場合は、3720に進み、パケットがハンドオフ用に利用可能であるかどうかを決定する。決定オフセットフィールド4012は、ハンドオフすることができるフロー内の次の可能なパケットを決定するために用いられる。この情報を維持するために様々な技術を用いることができる。例えば、ウィンドー内の各パケット及び/又はフラグメントに関する関連づけられたビットを有するビットマップを採用することができる。パケットが正確に受信されたときには、パケットの成功裏の受信を示すためにビットマップが更新される。従って、この例において、決定オフセットフィールドによって示される位置と関連づけられたパケットが(例えば1に)設定される場合は、パケットをハンドオフに関して利用可能である。ビットマップにおけるその位置がデアサートされる(すなわち、ゼロに設定される)場合は、穴が示され、このフロー(存在する場合)に関する後続するパケットのいずれもハンドオフに関して利用可能でない。
この例においては、ハンドオフ決定プロセス3600は、反復的な繰り返しを継続する。ハンドオフに関してパケットが利用可能である場合は、決定ブロック3730に進み、ハンドオフ待ち行列内にフローIDが含まれているかどうかを決定する。ハンドオフ待ち行列の一実施形態例は、図41において例示されるQアレイ状態テーブル4100として示される。この例においては、待ち行列は、最大でMの優先度に関して維持され、各々の待ち行列は、Qのアレイ状態テーブル4100においてエントリ4110を有する。この例においては、エントリ4110は、Qカウント変数4112と、先頭ポインタ4114と、末尾ポインタ4116と、を含む。待ち行列は、連結リスト構造を用いて維持される。代替実施形態においては、その他の型の待ち行列を採用することができる。実施形態例においては、Mは4に設定され、従って4つの優先度レベルがサポートされる。フローに関する優先度レベルは、決定状態テーブル4000の優先度フィールド4020から決定することができる。待ち行列内ビット4018は、Qアレイ状態テーブル内にフローが挿入されているかどうかを決定するために用いることができる。代替実施形態においては、ハンドオフカウント4014は、所定のフローがハンドオフ待ちのパケットを既に有しているかどうか又は待ち行列に追加する必要があるかどうかを決定論理が決定するのを援助するために用いることができる。ハンドオフカウントは、ゼロ以外であることができるが、既にゼロ以外であったかどうか又はゼロ以外になったばかりであるかどうかは不明なことがある。この例においては、パケットは、1度に1つずつ処理中であることができる。様々な実施形態においては、このビットは必要ない場合があり又は便宜上用いることができる。
フローIDがハンドオフ待ち行列内にない場合は、3735に進み、フローを追加する。図41に示されるように、各優先待ち行列に関して、先頭ポインタ4114及び末尾ポインタ4116が維持される。先頭ポインタ4114は、待ち行列内における最初のフローを決定するためにインデキシングして決定状態テーブル4000に入れるために用いることができるフローIDを含む。この例においては、優先度内において、先入れ先出し方式でフローがサービングされる。従って、先頭ポインタ4114は、待ち行列内においてサービングされる最初のフローに関するフローIDへのインデックスである。先頭ポインタ4114によって示されるフローIDにアクセスされた時点で、その待ち行列内の次のフロー(存在する場合)が次ポインタフィールド4016によって示されることに注目すること。Qアレイ状態テーブル4100内の末尾ポインタ4116は、優先待ち行列内の最後のフローを示す。新しいフローをハンドオフ待ち行列に追加時には、プロセスは、末尾ポインタ4116によって識別されたフローIDに関する次ポインタフィールドを更新することによって実行することができる。このフィールドは、追加中のフローを指し示すポインタによって置き換えられる。引き続き、新しく到着したフローを指し示すように末尾ポインタフィールド4116が更新され、新しく到着したフローが待ち行列の新しい末尾(すなわち、ライン上の最後)になる。さらに、待ち行列カウントフィールド4112は、優先待ち行列内の総フロー数を維持する。従って、優先度レベルに関する待ち行列カウント値を読み取ることによって、ハンドオフ待ち状態であるその優先度のパケットが存在するかどうかを素早く決定することができる。この手順に従ってMの優先待ち行列の各々に関する待ち行列が維持され、Qアレイ状態テーブル4100において容易に状態が維持される。
フローがハンドオフ待ち行列内にある又は既に追加されていることが決定された時点で、3740進んでハンドオフカウント4014を増やす。ハンドオフカウントは、特定のフローに関するハンドオフを待っているパケット数を決定するために用いられるパラメータであり、決定状態テーブル4000において維持されることを思い出すこと。3750において、フローに関してハンドオフすべき追加パケットが存在するかどうかを決定する。第1のパケットがハンドオフ準備が整っていると決定され、ハンドオフカウントが増やされているときに、決定オフセットは、ビットマップ内において前方に移動することができる(すなわち、決定オフセット++)。更新された決定オフセットもハンドオフに関して利用可能なパケットを示す場合は、3740に戻り、ハンドオフカウントを増やし、ウィンドー内の全パケットが試験済みになるか又は穴に到達するまでプロセスを継続する。これで、決定オフセットが次の穴を指し示すことに注目すること。方法3620の後続する繰り返しにおいて、各フローは、そのフローに関するパケットが到着するのに応じて利用可能なハンドオフパケットの有無を確認するための試験が行われる。
穴に到達し、ハンドオフすべき追加パケットがなくなった時点で、3760に進む。決定ブロック3760は、採用可能な割り込み手順のオプション例を示す。当業者は、あらゆる数の割り込み手順を容易に採用するであろう。3760において、ハンドオフが現在進行中であるかどうかを決定する。ハンドオフが進行中でない場合は、プロセスは停止することができる。ハンドオフが進行中である場合で、このオプションの優先順位再設定が採用される場合は、3770に進む。3770において、新しく到着中のパケットのフローがより高い優先度を有しており、現在ハンドオフ中のあらゆるパケットの前に移動すべきであるかどうかを決定することができる。ハンドオフエンジン2890によって現在処理中のフローの優先度を用いて現在のフローの優先度を試験する。現在のフローの優先度が処理中のフローの優先度よりも高い場合は、3775に進み、割り込みフラグを設定する。この例においては、割り込みフラグは、上のブロック3630において識別され、以下においてさらに詳細に説明されるハンドオフ待ち行列処理中に認識される。現在のフローの優先度がハンドオフエンジン2890によって現在処理中のフローの優先度よりも低い場合は、プリエンプションする必要がなく、プロセスは停止することができる。
図38は、上記において例示されるブロック3630として採用するのに適した、1つ以上のハンドオフ待ち行列を処理するための方法の実施形態例を示す。プロセスは、決定ブロック3810において開始する。ハンドオフエンジン2890によって処理されたハンドオフが現在進行中である(すなわち、方法3630の前回の繰り返しが該ハンドオフを開始させた)場合は、決定3815に進み、そのハンドオフが完了しているかどうかを決定する。そのハンドオフが完了している場合は、3820において、ハンドオフカウントを更新する。実施形態例においては、ハンドオフされたパケット数がハンドオフエンジン2890によって戻され、ハンドオフカウントから減じることができる。図28に示されるハンドオフ完了信号は、ハンドオフが完了しているかどうかを決定するために用いることができる。ハンドオフカウントがゼロになった時点で、図41に示されるフィールドを用いて、フローIDを各々の優先待ち行列から取り除くことができる。さらに、フローが待ち行列から取り除かれたときに、各々のQカウントも減らされる。3825において、ハンドオフを実施中であるかどうかを決定するために用いられる待機フラグがリセットされる。このフラグは、決定ブロック3810においてハンドオフが未完了状態であるかどうかを決定するのに有用であり、さらに、上述されるように決定ブロック3760においてパケット処理に関して用いることもできる。
決定ブロック3815における決定により、ハンドオフが完了しておらず、さらに上述されるように割り込み機能が採用される場合は、決定ブロック3830に進んで割り込みフラグが設定されているかどうかを決定する。例えば、該フラグは、上述されるブロック3775において説明されるように設定することができる。割り込みフラグが設定されていない場合は、プロセスは停止することができる。ハンドオフエンジン2890は、現在のハンドオフ動作を継続することができ、図36のプロセスの流れは、決定ブロック3610に戻って追加パケットの受信又はハンドオフ待ち行列処理状態の変化を待つことができる。決定ブロック3830において、割り込みフラグが設定されている場合は、ブロック3835においてハンドオフエンジンへの割り込みをアサートする。ハンドオフエンジンによる割り込み信号の処理の一実施形態例が以下においてさらに詳細に説明される。
決定ブロック3840において、ハンドオフエンジンがすべての以前の処理を完了しており、追加ハンドオフ命令を生成することができる。決定ブロック3840において、ハンドオフ待ち行列内においてハンドオフに関するフローが利用可能であるかどうかを決定する。一実施形態が以下においてさらに詳細に説明される。利用可能でない場合は、プロセスは停止して上述されるとおりに繰り返すことができる。フローが利用可能である場合は、3845において、ハンドオフエンジンへのハンドオフを開始する。上述されるように、フローID及び関連パラメータをハンドオフエンジンに引き渡すことができる。実施形態例においては、ハンドオフカウントはあらゆる数であることができる。ハンドオフカウントが1よりも多い場合は、ハンドオフエンジンは、割り込みがある場合を除き、終了するまで各パケットをハンドオフすることができる。代替実施形態においては、ハンドオフエンジンは、ハンドオフが開始されるごとに1つのパケットを処理することができる。この代替実施形態においては、割り込みが不要であることができる。3850において、待機フラグは、ハンドオフプロセスが未完状態であることを示すように設定される。これで、プロセスの現在の繰り返しが停止することができる。
図39は、上述されるブロック3840として採用するのに適する、ハンドオフに関して利用可能なフローを決定する方法の一実施形態例を示す。この例は、より高い優先度のフローにより小さい優先度値が割り当てられると仮定することに注目すること。従って、優先度0が最高の優先度である。当業者は、本明細書における教義の適用範囲内においてあらゆる優先度方式を容易に適合化するであろう。3910において、優先度インデックスを0に設定する。この優先度は、最初に試験すべき最高優先度である。決定ブロック3920において、優先度インデックスによって識別される待ち行列内にフローが存在する(すなわち、Qカウントが0よりも大きい)場合は、方法3840から出てフローを戻す。繰り返すと、実施形態例においては、識別された優先度を有する(先頭ポインタによって識別される)待ち行列内の第1のフローがハンドオフされる。
識別された優先待ち行列にいずれのフローも入っていない場合は、3930において優先度を高くする。3940において、優先度インデックスがサポートされる優先度数であるN(実施形態例においてはN=4)よりも大きい場合は、試験すべき追加待ち行列は存在しない。この場合は、全待ち行列が空である。試験すべき追加待ち行列が存在する(すなわち、優先度インデックスがNよりも小さい)場合は、戻って3920において次の待ち行列を試験する。プロセスは、フローが見つかるか又は待ち行列が空になるまで継続する。
繰り返しになるが、あらゆる型のフロー選択技術を方法3840の代わりに用いることができる。
図42は、ハンドオフエンジン2890内において採用するのに適する、ハンドオフを実行するための方法4200の実施形態例を示す。この実施形態例においては、ハンドオフ決定ブロック2880は、ハンドオフするためのパケット数、ハンドオフカウント、フロー型(例えば802.11(b)、(g)、(n)、等のように複数のパケット型に関するサポートが採用される場合に用いることができる)、及び割り込みをハンドオフエンジン2890に引き渡す。ハンドオフエンジンは、出力のためのパケットを引き渡し、これらのパケットは、図28に関して上述されるように、メモリアービター680を介してパケットバッファからフェッチされる。上述されるように、ハンドオフされたパケット数は、ハンドオフ完了信号とともに、処理のために決定2880に戻される。
4210において、ハンドオフエンジン2890は、1つ以上のノードを、最大でハンドオフカウントによって示される数だけ、パケットバッファから取り出す。ノードは、パケットバッファ内において、フローIDに対応して設定されるウィンドーポインタ及びハンドオフオフセットによって識別される格納場所に配置される。受信パケットバッファ例は、図33において例示されるとおりであり、ノードアレイ3330は、ノード3310を具備し、各々は、パケットに対応し、アレイフォーマットにおいてリンクされ、関連づけられたパケットデータが入ったチャンクの連結リストを有することを思い出すこと。パケットバッファをインデキシングするために用いられる変数は、図43に示されるハンドオフ状態テーブル4300内においてハンドオフエンジンに関して維持される。繰り返すと、NのフローIDがサポートされ、各フローIDに関して、エントリ4310がハンドオフ状態テーブル4300において維持される。実施形態例においては、最大で256のフローがサポートされる。ファームウェアは、各フローに関するパケットバッファ内においてノードアレイ格納場所を維持する。このノードアレイ格納場所は、ハンドオフ状態テーブル4300においてwin(ウィン)ポインタによって識別される。フローに関するウィンドーのサイズは、winサイズ4316によって示される。ハンドオフオフセット4312は、ハンドオフすべき次のパケットが見つかるかどうかを決定するためにハンドオフエンジンによって状態が維持される。従って、上述されるように、ハンドオフ用のパケットに対応するノードは、ハンドオフオフセット4312をwinポインタ4314に追加することによって識別される。より効率的なSDRAMアクセスを行うためには、1度に2つ以上のノードを取り出すことが望ましいが、必須ではない。
winサイズ4316を開始シーケンス番号及びハンドオフオフセットとともに用いて、ハンドオフ用に処理する必要があるパケットにハンドオフエンジンを位置決めすることができる。この例においては、ハンドオフオフセットは、ウィンドーデータ構造(すなわち、ノードアレイ)内の開始シーケンス番号を指し示し、ハンドオフされるべきシーケンス番号は、開始シーケンス番号に関して識別される。
4215において、ハンドオフオフセット4312に対応する第1のノードを選択する。4220において、そのノードに対応するチャンクをパケットバッファから取り出す。4225において、必要な場合は、フロー型に基づいてパケットをデフラグメンテーションする。このことは、幾つかのフラグメントをパケットバッファから取り出すことと、フラグメントヘッダーを各フラグメントから取り除くことと、チャンクをコンパクトにして単一のパケットにすることと、適切なヘッダーを生成すること、とを含むことができる。このことは、図28に示される関連するデフラグブロック2892において行うことができる。フロー型は、フラグメンテーションが必要なときを示すために用いることができる。例えば、幾つかの実施形態においては、802.11(e)及び(g)パケットをサポートすることができ、フラグメンテーションを用いることができる。以下においてさらに詳細に説明される代替実施形態においては、複雑さを軽減するために、フラグメンテーションを要するパケット型がファームウェアにおいて処理される。該実施形態においては、デフラグロック2892は採用する必要がない。
4230において、パケットと関連づけられたチャンクの各々が取り出され、パケットが再構築され(要求されるデフラグメンテーションを含む)、該パケットが出力のために引き渡される。上述されるように、出力は、様々なインタフェースのうちのいずれかを通じて行うことができ、その例が上記において示される
パケット(又は一組のフラグメント)がハンドオフされた時点で、ハンドオフ用の次のパケットを識別するためにハンドオフオフセット4312が更新される。4240において、ハンドオフされたパケット数を追跡するための変数#handed offが適宜増やされる。4245において、割り込みがサポートされる場合で、割り込みが発行されている場合は、4255に進む。4255において、ハンドオフが停止し、ハンドオフ完了がアサートされ、ハンドオフされたパケット数が戻される。この実施形態においては、割り込みは、各パケットが完全にハンドオフされた後に作動される。代替の割り込み方式を採用することができ、当業者にとって明確になるであろう。割り込まれた時点で、ハンドオフプロセスが停止する。この例においては、ハンドオフ決定ブロック2880は、のちに、割り込まれたフローに関するパケットのハンドオフを継続するために新しいハンドオフコマンドをハンドオフエンジン2890に発行することができる。4245において、割り込みが受信されなかった場合は、決定ブロック4250に進む。4250において、ハンドオフすべき追加パケットが存在しない場合は、ハンドオフが完了しており、ハンドオフすべき追加パケットが存在しないことは、ハンドオフされたパケット数をハンドオフカウントと比較することによって決定することができる。4255に進み、ハンドオフ完了をアサートし、ハンドオフされたパケット数を戻す。
ハンドオフすべき追加パケットが存在する場合は、4260に進む。次のノードを処理し、4220に戻り、そのノードに対応するチャンクを取り出し、直前において説明されたプロセスを再開する。
図28に示されるように、フラッシュブロック2894がハンドオフエンジン2890に接続される。フラッシュブロック2894は、最終的にパケットをフラッシング(fushing)するために用いることができる再送信限度、時間切れ、等を追跡するために用いることができる。このことは、穴が充填される前にハンドオフエンジンが進行することを可能にする。次にハンドオフが生じ、必要な場合は、パケットの送信及び後続する再送信は、より高い層を通じて処理される。
フラッシュブロック2894は、ARQウィンドーが移動されたときに様々な機能を実行する。例えば、部分的にフラグメンテーションされたパケットがフラッシングされる。完成されたパケットは、穴が存在するかどうかにかかわらずハンドオフされる。バッファが解放され、従ってチャンクポインタがフリーチャンクポインタリストに戻されてウィンドーが移動される。
当業者は、代替実施形態において様々な回路、構成要素及び技術を容易に適合化するであろう。1つの一般化された(後述される、図49に示される代替実施形態4900と適合可能な)実施形態の例においては、入力状態マシン(ISM)は、着信パケットを処理し、制御状態マシン(CSM)によって用いられた情報を更新する。これらの更新は、メモリ内のパケット数を増加させ、さらにFlow_IDをCSMによって処理する必要がある順序を更新することもできる。CSMは、上述されるように、送信機内の4パケットノードキャッシュを更新することができる。この状態マシンは、Flow_Packet_Table内の情報に基づいて動作する。テーブル内の先頭ポインタと末尾ポインタ及び次フローポインタは、CSMが処理すべき次のFlow_IDを選択するのを可能にする。(Flow_IDごとに)このFlow_IDからのパケットが現在送信中であるかどうかをCSMに知らせるサービス中ビットがテーブル内に存在することができる。このビットは、送信開始前にTxエンジンによって1に設定することができ、送信が完了後に0に設定される。送信状態マシンは、コマンド待ち行列からの情報を用いて(図18に関して上述されるのと類似の)WLANにおいてパケットを送出する。フラッシュ状態マシン(FSM)は、フラッシュブロック2894として用いることができ、各々の受信機によって正確に受信されて確認応答されたSDRAMパケットからフラッシングする。次に、FSMは、Flow_Packet_Tableにおいてメモリカウント内のパケットを減らす。
Flow_Packet_Tableは、次のエントリ、すなわち、Flow_ID(1バイト)、メモリ内のパケット数(2バイト)、キャッシュ内パケット(2ビット)、サービス中ビット(1ビット)、Next_flow_ID(1バイト)、及び2ビットの優先度フィールドのうちの1つ以上を有することができる。パケットが入口に着信すると、ISMは、メモリ内のパケットを更新し、Next_Flow_ID及びTail_Pointerを更新する。送信状態マシンは、特定のFlow_IDからパケットを送信中であるときには、対応するサービス中ビットを設定する。対応するするサービス中ビットが設定されているときには、CSMは、4パケットノードキャッシュを更新しない。パケットが送信された後は、Tx状態マシンは、キャッシュ内のパケット数を更新し、さらにサービス中ビットをリセットする。CSMは、サービス中ビットがリセットされているときのみに動作する。CSMがFlow_IDを処理する順序は、Next_Flow_IDによって決定される。希望される場合は、2ビット優先度ビットをテーブルに追加することができる。この場合は、CSMは、最初に最高の優先度に属するフローを処理し、次に、2番目に最高の優先度に属するフローを処理し、以下同様である。このテーブルのサイズ例はフロー数のほぼ4バイト倍であり、256のフローに関しては約1キロバイトである。CSMは、Flow_ID(Linked_list内の最初のパケット)のヘッダーポインタを用いて、4パケットノードキャッシュ内に含める必要があるパケットのノードアドレスを推定する。
以上のように、一実施形態例においては、フラッシュエンジン例又はフラッシュブロック2894は、成功裏に受信されて確認応答された全パケットをパケットバッファから取り除くことができる。ブロック確認応答ビットマップが受信されたときに、Tx状態マシンは、最初にそのビットマップを処理し、一定の非確認応答パケットに対処するための即時再送信を行うことができる。(以下においてブロック確認応答がさらに詳細に説明される。)次に、ビットマップは、フラッシュエンジン内のフラッシュエンジン状態マシン又はフラッシュブロック2894に渡され、対応するFlow_IDに関する連結リストデータ構造のHead_Pointerを取り出す−Head_Ptrがフロー状態RAMにおいて利用可能である。Head_Ptrは、所定のFlow_IDに関する最初のパケットのノードアドレス及びこのパケットのシーケンス番号を含む。フラッシュエンジン状態マシンは、ビットマップを処理し、順に確認応答されているパケットをフラッシングするために待ち行列に入れる。この論理は、出力状態マシンによって用いられる論理と同様であることができ、順に受信されたパケットがホストに渡される。フラッシュエンジン状態マシンがフラッシングすべきパケット数及びそのシーケンス番号を識別した時点で、フラッシングのための待ち行列に入れることができる。Head_Ptrは、連結リスト内の最初のパケットのノードアドレスを生み出す。フラッシングすべきパケットのノードアドレスは、連結リストからの対応するパケットのノードアドレスにアクセスすることによって入手される。実施形態例においては、十分なパケット格納場所、チャンク、及びノードを提供するためのメモリが割り当てられる。従って、一般的にはこのタスクに関する厳しい時間上の要求は存在しないため、フラッシングはバックグラウンドで行うことができる。メモリアービターは、優先度が低いタスクとしてのフラッシング機能に関するアクセスを提供することができる。
ブロック確認応答
上記において詳述される実施形態例によって示される様々な側面は、高速メディアアクセス制御に関するブロック確認応答を実行するのに非常に適する。典型的なブロック確認応答プロトコルにおいては、送信機は、パケットの確認応答を必ずしも受け取らずにある期間にわたって受信機にパケットを送信する。次に、以前に送信されたパケットのうちのいずれのパケットが正確に受信されたかを示すブロック確認応答が受信機から送信機に戻される。ブロック確認応答は、ブロックack要求に応じて送信することができ、又は代替のスケジューリングメカニズム、例えば予め決められた数のパケットが受信された後に応答する、を採用することができる。ブロック確認応答要求は、ブロック確認応答が希望されることを示すために送信された特定のメッセージであることができ、又はブロック確認応答は、他の型の信号又はメッセージにおける固有の確認応答であることができる。
図30及び31に関して上述されるように、確認応答された又は確認応答されないパケットの状態を維持するための一メカニズムは、各ビット位置がパケット又はパケットフラグメントに対応するビットマップを保持することである。ビットマップ例3130は、既に上述されている。
高スループットシステムにおいては、トリガーイベントに引き続く相対的に短時間にブロックACK要求、例えば明示の又は固有のブロックACK要求、又はその他のブロックACK要求インジケータ、を戻すことが望ましい場合がある。802.11の一実施形態例においては、ブロックACK要求(すなわち、即時ブロックACK)に引き続くSIFS期間内にブロックACK要求を戻すことが要求される場合がある。従って、複数のフローに関する状態情報を維持し、現在の未完了状態のフローのうちのいずれかに関する、及び再送信を必要とするパケットを再送信するためのブロックack要求に引き続くブロック確認応答を処理することに関する即座のブロックACK応答を可能にすることが望ましい。幾つかの型のブロック確認応答をサポートすることができる。例えば、部分的又は全体的状態確認応答を希望することができる。一般的には、部分的状態確認応答のほうが計算上の集約度が低いか又は要求される遅延がより短い。本明細書において説明される実施形態例は、部分的又は全体的状態ブロック確認応答、又はその組合せに関して容易に適合化することができる。以下では、実施形態例を用いて諸側面がさらに説明される。
受信機におけるブロックACK
一実施形態例においては、パケットが受信され、該パケットは、統合パケットであることができる。受信機においてパケットが受信されるのに応じて、パケットが正確に受信されているかどうかを決定するために試験され、例えばフレーム検査シーケンス等を用いることができる。パケットの正確な受信を決定する方法にかかわらず、各パケット(又は、該当する場合はフラグメント)に関するインジケータを格納することができる。実施形態例においては、これらの確認応答インジケータは、各フローに関して関連づけられたビットマップ内に格納される。フローに関するビットマップを格納するための様々な技術が上記において図30に関して詳細に説明される。
図44は、即時ブロックack要求に応答するための方法440の一実施形態例である。この方法は、ブロックack要求に即座に応答するのに適する。
4410において、ブロックACKを生成することが必要になるあらゆるフローに関してパケットヘッダー情報が維持される。このヘッダー情報は、あらゆるフォーマットで維持することができ、その例は当業者においてよく知られる。ヘッダー情報(又は、代替実施形態においては、ブロック確認応答を準備する際に用いるために予め決定することができるいずれかの情報)が、潜在的なブロックACK送信前にパケットを構築するために格納される。換言すると、パケットは、(事前に確定することができる)送信のためのすべての値を用いて適切にフォーマット化された、何らかの形態のメモリ内にある。存在していないものは、個々のパケット又はフラグメントの実際の確認応答又は非確認応答を示すビットマップ情報(及びそれよりも前に確定することができないその他の情報)である。ビットマップ(及びあらゆる残りの情報)は、待機中のパケット内に単に挿入されて送信される。
上述される実施形態例においては、様々なレベルのインダイレクションに備えて3つのレベルのメモリを採用できることを思い出すこと。一例においては、第1のレベルのメモリは、ハードウェアテーブル、例えばハードウェアテーブル2820、である。第2のレベルのメモリは、SRAM330を含むことができる。オプションの構成においては、SDRAM340等の第3のレベルを採用することができる。パケットヘッダー情報は、適切なアクセス先であるとみなされあらゆるメモリ層内に格納することができる。
4420において、暗黙又は明示であることができるブロックack要求が受信される。4430において、フローと関連づけられたビットマップが取り出される。ビットマップを取り出すためにあらゆるフロー識別子を用いることができる。例えば、図30において上述されるように、関連づけられたポインタ3002を有するリンクID3006を識別するためにMACインデックス3004が用いられる。ポインタ3002は、ビットマップ3046を直接含むテーブル3042を直接指し示すことができ、又はポインタ3002は、送信ID3020に基づいてRX状態テーブル2920を指し示すレートテーブル3010を指し示すことができる。上述されるように、状態テーブル2920は、実際のビットマップ3130を指し示すビットマップポインタ3050を含むことができる。当業者は、あらゆる型のインダイレクション又はビットマップの直接格納を採用できることを認識するであろう。用いられる技術により、ブロックack要求を有するフローIDと関連づけられた適切なビットマップが取り出される。
4440において、取り出されたビットマップは、維持されるパケット内に入れられ、4450において、今構築されたブロックACKが送信される。このように、この実施形態においては、ブロックackパケットのうちの可能な限り多くの部分が予め構築される。ビットマップ情報、又は代替実施形態におけるその他の確認応答データは、即座の取り出しのために容易にアクセス可能なメモリ部分において維持される。次に、即時ブロックack要求に応じて部分的又は全体的状態即時ブロックackを提供するためにこれらの2つの組合せが即座に送信される。
上記の実施形態は、即時の全体的状態ブロック確認応答又は部分的状態ブロック確認応答をサポートする。一実施形態例においては、部分的状態、完全状態、又はあらゆる組合せに関するサポートを採用することができる。しかしながら、その他の実施形態は、802.11(n)に関する基準になることが見込まれるように、部分的状態ブロック確認応答をサポートすることだけが必要になると思われる。この場合は、受信された統合パケットのみに応じてブロック確認応答が送信され、受信されたパケットのみに関する状態を送信する。
部分的状態ブロックACKに関しては、単一のメモリのみを受信機において維持する必要がある。完全な状態(すなわち、256のフローに関するメモリ)を含める必要はない。受信機において維持される部分的ビットマップ状態は、異なる送信元からの送信が受信された場合にオーバーライトすることができる。状態が誤ってオーバーライトされた場合は、のちのブロック確認応答要求は可能でないことに注目すること。一例においては、この場合はすべてがゼロのビットマップを送信することができる。希望される場合は、最低量よりも多い状態量を維持するための所定の実施形態を採用することができる。
送信機におけるブロックACK
上述されるように、送信機は、幾つかのパケットを送信し、その後に明示又は暗黙のブロック確認応答要求を介して受信状態を要求することができる。高いスループットを維持するために、対応するブロック確認応答が受信されたときに送信機が送信を継続するか又は必要に応じて即座に再送信する準備を整えておくことが望ましい。様々な実施形態は、ブロック確認応答に応じた効率的で即座の再送信を可能にするために本明細書において詳述される様々な側面を利用するように容易に適合化可能である。
図45は、ブロック確認応答に応答するための方法4500の実施形態例を示す。この方法は、上記において詳述されるノードアレイキャッシュ1810に格納されるようなノードアレイを採用する実施形態に関して非常に適する。さらに、上述される待ち行列は、連結ノードリストによって変更及び維持することができ、方法4500に合わせて適合化するのにも非常に適する。
手順を要約すると、ブロック確認応答は、ウィンドーサイズ(実施形態例においては最大サイズは64)に対応することを思い出すこと。開始シーケンス番号は、ウィンドー(概念的にはウィンドーの左端点)によって表される最低のシーケンス番号に設定される。送信機は、どれだけの数のパケットが送信されているかを知っており、従って、最後のパケットがウィンドー内のどの場所に存在するかを知っている。送信機は、最後に送信されたパケットから開始し、ビットマップ全体にわたってパケットごとに、直近に送信されたパケットから最も初期に送信されたパケットまで進むことができる。非確認応答(実施形態例においてはゼロ)が識別された場合は、そのパケットに関するノードポインタが(パケットを再送信するために再度待ち行列に入れる)送信待ち行列に再リンクされる。送信機は、ビットマップ全体にわたって進み、(前開始シーケンスによって識別される)ビットマップの始めに達するまで連結リスト送信待ち行列を再構築する。方法4500は、採用可能な1つの該技術であるが、要求される再送信パラメータを決定するためのあらゆる技術を本明細書において詳述される実施形態と関連して用いることができる。
以下の例は、ブロックACKビットマップを用いてパケットバッファ内の送信待ち行列を処理することを例示するものである。ブロックACKに応じて低レーテンシー再送信を提供することにも同じ又は同様の技術を等しく適用可能である。例えば、待ち行列、例えばノードアレイ1842は、上述されるように、フローのノードをローディングすることができ、次に該ノードが送信される。これらのノードは、ブロックACKが受信されて処理されるまでとどまることができる。ブロックACKビットマップは、いずれのノードを再送信する必要があるかを示すために用いることができる。一実施形態においては、ノードアレイ内におけるノードの位置は、ブロックACKビットフィールド内における位置と対応することになる。ブロックACKが受信された時点で、(送信機会が利用可能であると仮定した場合に)上記において詳述される統合技術を用いて確認応答されなかったパケットを即座に統合して再送信することができる。この技術は、残りの送信機会を効率的に利用することを可能にする低レーテンシー応答技術の一例である。ノードアレイ内のノードは、後述されるのと同様の方法で、ウィンドーが移動するのに応じて移動させることができる。ブロックACK処理及び再送信に関してノードアレイ又は送信バッファを用いるかどうかにかかわらず、上記において詳述されるノード及びチャンク等のデータ構造を用いてパケットバッファ内にパケットが格納されるときには、パケットバッファ内のパケットデータを移動させる必要がまったくない。パケットデータは、パケットが成功裏に受信されるか又は予め決められた限度を超えてフラッシングされるまでは最初の送信及び後続する再送信を通じて1つの場所にとどまることができる(ただし、各送信中に再アクセスすることができる)。
4510において、ブロック確認応答が受信される。4515において、開始シーケンス番号が最初の送信されないパケットを指し示すように設定される。従って、送信された全パケットが正確に受信されたことを示すブロックACKが受信される例においては、ウィンドーが移動される。次に送信されるパケットは、新しいウィンドー内の最初のパケットであり、従って、開始シーケンス番号は、そのパケットと関連づけられるべきである。以下のステップは、必要な再送信が必要である場合にこれらの再送信を受け入れるために、開始シーケンス番号を修正する方法及び送信待ち行列を更新する方法について詳述する。プロセスが終了された時点では、開始シーケンス番号が適切な位置に自動的に更新されてウィンドーを前方に移動させていることになる。送信及び再送信が直ちに開始することを考慮して、送信待ち行列が更新される。
4520において、直近に送信されたパケットから初めてブロックACKビットマップを検討する。4525においてゼロが検出された(又は代替実施形態においては非確認応答インジケータが検出された)場合は、そのパケットを再送信する必要がある。4530に進み、次の送信に関するポインタをそのビットマップ位置と関連づけられたパケットにリンクする。例えば、図6に関して上述されるように送信待ち行列が採用されたときには、ゼロが検出されたパケットと関連づけられたノードを指し示すように待ち行列先頭ポインタ630に指示することができる。次に、そのノードに含まれている次ノードポインタフィールド612を、前先頭ポインタを指し示すように更新することができる。代替実施形態においては、送信待ち行列を更新するために代替技術を用いることができる。
4535において、開始シーケンス番号が現在のパケットを指し示すように更新される。従って、受信された各ゼロに関して、開始シーケンス番号が前の格納場所に移動される。上述されるように、全パケットが正確に受信された場合は、ウィンドーは、送信待ちの次のパケットに移動していることになる。しかしながら、その前方移動は、最も初期の検出されたゼロまで戻される。方法4500プロセス全体に引き続き、ブロック確認応答内の開始シーケンス番号と関連づけられたパケットが正確に受信されなかった場合は、当然のことであるが、ウィンドーは前方にまったく移動されない。
4540において、ビットマップ内を横断して次の前パケットに戻る。4545において、検査すべきビットマップ位置がさらに存在する場合は、次の確認応答に関する決定ブロック4525に戻る。4525において、ゼロが検出されない場合は、プロセスは、4540を通じて流れ、ビットマップ内を横断してビットマップが完了しているかどうかを確認する。ビットマップ内の全パケットが試験済みである場合は、4550に進み、送信された送信待ち行列を用いて送信を開始する。4560において、確認応答されているパケットをフラッシングすることができ、その関連するポインタを後続して用いるためにリサイクルさせることができる。このステップは、示されるように並行して(又はバックグラウンドで)動作することができる。これで、プロセスは停止することができる。
要約すると、ブロックACKに関してビットマップが受信されたときに、ビットマップ内のゼロが既存の送信待ち行列と再リンクされて新しい送信待ち行列が形成される。これらのパケットに関する関連づけられたノードポインタがメモリ内に再度書き込まれる。しかしながら、(チャンクポインタによって識別されてチャンク620内に含まれている)パケット自体は絶対に移動しないことに注目すること。パケットが成功裏に送信されて確認応答されるか(又は時間切れ等の他のイベントが発生した)ときのみに、ノード及びチャンクがフラッシングされ、ポインタがフリーポインタリストに戻される。このメモリ管理プロセスは、並行して実行することができ、ブロックACK処理を遅延させることができ、バックグラウンドで実行することができる、等である。例えば送信機がTXOP内に残り時間を有する状況においては、再送信待ち行列が素早く生成され、送信は、残りのTXOPを利用することに進むことができる。送信機が直ちに再送信する許可を受けていない(すなわち、それ以上の残りのTXOPが存在しない)場合は、同じ方法を実行することができるが、再送信は直ちに生じる必要はない。
図18に関して上述されるように、進行中の送信に干渉せずにノードアレイ1842を更新可能にするためにピンポン型キャッシュを採用できることを思い出すこと。この技術は、ブロック確認応答再送信方式においても同様に採用することができる。図46は、再送信プロセスにおいてピンポンノードアレイキャッシュを利用するために採用することができる方法4600の実施形態例を示す。例えば、方法4600は、上述されるブロック4550内に組み入れることができる。4610において、ブロック確認応答要求内の再送信情報に応じて更新可能な送信待ち行列からのノードポインタを用いて第1のピンポンノードアレイ1842をセットアップする。上記において詳述されるように、1844においてリンクIDが適宜更新される。4620において、この第1のノードアレイに切り換えて送信が進行するのを可能にする。4630において、メモリ構造を必要に応じてクリーニングすることができる(すなわち、パケットのフラッシング、ポインタのリサイクル、等)。
多TIDブロック確認応答
所定の局において、様々なフロー(例えば、最大で16のフロー)をサポートすることが可能であり、各フローは、トラフィック識別子(TID)に対応する。TIDは、局からのフローをマッピングすることを思い出すこと。1つの統合パケットにおいては、複数のTIDに対応するパケットを見つけることが可能であり、例えばリンクごとのパケットの統合である。従って、複数のTIDに対応するブロックACK(又は、多TIDブロックACK)を戻すことができる。一実施形態においては、多TIDブロックACKは、TID、次に、ビットマップ、次に他のTID、次に他のビットマップ、等を具備する。統合パケット内のパケットは(再送信に起因して)必ずしも連続順でないという点で1つの問題が生じる。従って、所定のTIDに関して、ブロックACKは、そのTIDに関するその統合パケット内において受信された最低のシーケンス番号を指定する開始シーケンス番号から開始する。次に、開始シーケンス番号からのオフセットとしてTIDビットマップが提供される。多TIDブロックACKを準備するための幾つかの実施形態が以下において詳述される。
一実施形態においては、パケットが到着するのに応じて、各シーケンス番号を比較して最低のシーケンス番号を保管する。プロセスは、各TIDに関する最初の受信されたシーケンス番号を保存することによって開始することができる。次に、各パケットが到着するのに応じて、TIDに関する保存されたシーケンス番号を新しいパケットのシーケンス番号と比較し、最低のシーケンス番号を保管する。統合パケットの最後においては、各TIDに関する最低の開始シーケンス番号を有することになる。表示された最低のシーケンス番号を見つけた後は、(到着するのに応じて保存することができる)応答中の各パケットのシーケンス番号からそのシーケンス番号を減じて、ビットマップ内におけるそのパケットのオフセットを見つけ出す。最低の開始シーケンス番号は、TIDに関する開始シーケンス番号である。ライン速度において、パケットが有効であってライン速度で生じることができるかどうかを決定し、ACK又はNAKに関する各ビットを絶対シーケンス番号とともに単に保存する。統合パケットの最後において、保存されたパケットシーケンス番号シリーズ全体を横断し、減じられた値をオフセットとして用いるか又はインデキシングしてビットマップに入れ、保存されたACK又はNAKをビットマップに入れる。
代替実施形態においては、現在受信されている最低のシーケンス番号に関するビットマップを格納する。次に、(格納順に依存して)左又は右シフトを行って格納場所を更新する。例えば、ビットマップを格納している間に、着信パケットのシーケンス番号が現在の最低のシーケンス番号よりも大きい場合は、(最低の受信されたシーケンス番号と現在受信されているシーケンス番号との間の差によって決定された)適切な場所において確認応答ビットを単にマーキングする。着信シーケンス番号が最低の前に受信されたシーケンス番号よりも小さい場合は、ビットマップをシフトし(新しいACK又はNAKを最低の場所に入れる)。シフトは、旧開始シーケンス番号(すなわち、最低の前に受信された開始シーケンス番号)と新しい開始シーケンス番号(すなわち、現在受信されているパケットの番号であって新しい最低の番号になる番号)との間の差として決定することができる。保存されたシーケンス番号全体の横断が行われた上述の第1の実施形態と対照的に、この実施形態においては、ビットマップ及び最低の開始シーケンス番号を保存する必要があるだけである。ビットマップ内のその他のいずれのシーケンス番号も保持する必要がない。
上記の実施形態に関する説明は、即時部分的状態ブロック確認応答に適用される。完全な状態に拡大するときには、最初に単に各フローに関する格納された履歴を取り出して追加するだけである。いずれの実施形態も、単一TID状況に関して採用可能であり、多TIDをサポートするために各TIDに関して繰り返すことができる。
不定期U−APSD
本明細書において詳述される実施形態例は、不定期自動節電引き渡し(U−APSD)を提供するように適合化するのにも非常に適する。U−APSDは、電力を保存するために用いられる技術である。スケジューリングされた技術及びスケジューリングされない技術を含む数多くの変形が存在する。図47は、スケジューリングされない不定期自動節電引き渡しを実行するための方法4700の実施形態例を示す。4710において、典型的U−APSD方式では、ユーザー端末は自主的にウェークアップする。4720において、ユーザー端末は、トリガーパケットをアクセスポイントに送信する。4730において、アクセスポイントは、受信されたパケットからフローIDを決定する。決定ブロック4740において、フローIDと関連づけられたユーザー端末への送信待ちのパケットが存在する場合は、4750に進む。存在しない場合は、4790に進み、送信のためのパケットが存在しないことを示すインジケータ“さらなるパケットを送信”がデアサートされる(例えば、サービス期間終了(EOSP)ビット)。4795において、ユーザー端末は、スリープに戻ることができ、プロセスは停止することができる。決定ブロック4740において、ユーザー端末への送信用のパケットが存在する場合は、4750に進む。
4750において、TXノードアレイキャッシュから1つ以上のパケットを直ちに送信する。例えば、上記の図18において説明されるようなTXノードアレイキャッシュ1810にアクセスすることができる。図18において例示される技術を用いて、送信機は、ウェークアップされたユーザー端末に直ちに応答することができる。このことは、ユーザー端末をウェーク状態に保つための代替技術を採用する必要性、例えばデータなしのパケットを送信する、を排除する。このことは、ユーザー端末がウェーク状態を必要以上に長い時間維持する必要がないため、電力と同様に帯域幅の浪費を回避する。上述されるように、パケットは待ち行列に入っていて容易にアクセス可能であるため、この技術を用いることで、データを含むユーザー端末への応答を行うことができる。幾つかのシステム例、例えば典型的なボイス・オーバー・インターネット・プロトコル(VOIP)システム、においては、音声通信をサポートするために単一の又は2つのパケットのみが必要になることに注目すること。このように、U−APSDを採用するユーザー端末は、スケジューリングされない形でウェークアップし、相対的に小さい遅延を有するパケット又は2つのパケットを素早く取り出し、節電のためにスリープ状態に戻ることができる。
決定ブロック4760において、4750において送信された応答パケットに含まれているパケットに加えて送信すべきパケットが存在する場合は、4770に進む。4770において、“さらなるパケットの送信”インジケータをアサートし、該インジケータは、ユーザー端末に送信されるパケットに含めることができる。この“さらなるパケットの送信”アサーションは、追加パケットを受信するためにアウェーク状態であるようにユーザー端末に示す。4780において、上述されるように、追加ノードをフェッチして関連づけられた追加パケットを送信する。4760に戻り、送信すべき追加パケットが存在するかどうかを決定する。4790において、上述されるように、このユーザー端末に関して指定された全パケットが送信された時点で、“さらなるパケットの送信”がデアサートされ、4795において、ユーザー端末は、スリープに戻ることができる。
上記において詳述されるU−APSD実施形態例においては、最大で4つのパケットをノードアレイキャッシュ内において入手可能であるため、これらのパケットを直ちにユーザー端末に送信することができる。これらの4つのパケットは、即座に送信することができ、さらなるパケットが後続する場合は、インジケータを設定することができる。引き続き、SIFS、ブロックACK、等の後に、追加パケットの送信準備が完了することになる。この例においては、UTがアウェーク又はスリープ状態であるかどうかをAPに示すための変数がTXフロー状態テーブル(例えば、1030)において維持される。この実施形態は、図18において示される送信機において例示されるようなキャッシングを用いることを説明する(ノードアレイキャッシュ1810)。特定のフローに関して記憶容量の増大が希望される場合は、代替のキャッシング量を用いるか又は異なる形でパーティショニングすることができる(すなわち、応答して5つ以上のパケットを考慮した再パーティショニングである)
パワーセーブマルチポール(PSMP)
パワーセーブマルチポール(PSMP)は、上記において詳述されるノードキャッシング方式が利益を提供する他の分野である。スケジューリングされないPSMP及びスケジューリングされたPSMPの2種類のPSMPが存在する。
スケジューリングされない不定期PSMP(U−PSMP)は、スケジューリングされない不定期APSDに類似する。局がウェークアップしたときには、EDCA手順を用いてトリガーメッセージを送信し、トリガーメッセージは、(セットアップメッセージを介して)トリガーイルーブルドになるように構成されているアクセスクラスに関するQoS_Data又はQoS_Nullメッセージのいずれかであることができる。このパケットを受信した時点で、APは、この局に関して格納されているパケットを送信し、これらのパケットは、有利な形でノードアレイキャッシュ1810内に格納される。最後のパケットにおいて、APは、EOSPを1に設定し、それ以上のパケットが存在しないことを示す。このパケットを受信後は、局はスリープに戻る。局が特定のアクセスクラスに関してU−PSMPイネーブルドされるように構成されるときには、対応するフローは、TA/TID−フローマッピングテーブルにおいてU−PSMPイネーブルドであることが示される(例えば1030)。さらに、TA/TID−フローマッピングテーブルでは、フローがスリープモード又はアクティブモードのいずれであるかを示す状態変数も維持される。
以上のように、上記の実施形態は、U−PSMPをサポートするのに非常に適する。一実施形態例においては、上述されるように、フローがPSMPフローであるかどうかを示す第1の変数、及び特定の局がアウェークであるか又はスリープであるかを示す第2の変数を維持し、その他の変数に加えることができる。受信データ(又はトリガー)の後に、APは、このトリガーが(第1の変数に従った)合法的なU−PSMPフローであるかどうかを検査し、第2の変数を“スリープ状態”から“ウェーク状態”に設定する。APは、そのSTAに関して格納されていて簡単に入手可能なパケットを送出し、局をスリープにし、第2の変数を“スリープ”に戻す。アウェークビットは、残りのTXOPが存在する場合も用いることができる。該場合には、アウェークビットが検査され、TXOPはアウェーク状態にあるSTAに関してしか用いられない。APは、送信を行う、等のために局をアウェーク状態に維持する裁量を有する。変数は、TXアレイ状態テーブル1830に追加することができる。
スケジューリングされたPSMP(S−PSMP)においては、テンプレートが開発されてアップリンク及びダウンリンクスケジュールが発行される(例えば、AP内のファームウェアは、この機能、及びその他のあらゆるデバイスを実行することが可能である)。WLAN内の無線通信デバイスは、新しい呼が追加されるか又は呼がなくなるまで同じテンプレートを用いることができる。次に、新しいテンプレートを生成することができる。
一実施形態においては、APは、スケジューリングされたPSMPを制御する。一方法は次のように実行することができる。すなわち、1)APがメディアをクリアするためのClear to Send(CTS)(送信可)を自分に送信する。CTSは、NAV継続時間をダウンストリーム+アップストリーム送信機会に等しく設定する。2)APが、アップリンク及びダウンリンクスケジュールを(局ごとにマイクロ秒まで)詳述するPSMPフレームを送信する。3)これで、ダウンリンク送信が開始する。4)アップリンク送信がダウンリンク送信に従う。5)このフォーマットが詳細にスケジューリングされ、APは、ジッターを除去するために、スケジューリングされた終了時間を越えるのを回避する。このことは、NAV継続時間の終了間近におけるメディアへのアクセスを制限することによって完遂することができる。ユーザー端末が自己の状態を確認するためのウェークアップをせず、ジッターによって導入されたオフセットに起因してメッセージを見逃し、スリープ状態に戻って送信機会を失うことがないようにジッターを回避することが重要である。
一実施形態例においては、スケジュールを生成するために用いられるデータ構造は、上述されるように、ピンポンデータ構造内に保管される。データ構造は、スケジューリングされたPSMPに関して用いられるアップリンク及びダウンリンクスケジュールに関して用いられるテンプレートを具備する。現在のスケジュールは、ピンポンデータ構造の1/2内において保管される。このスケジュールは、WLANにおいて局に送信することができる。APは、ピンポンデータ構造の他方の1/2におけるテンプレートの変更を行うことができる。第1のテンプレートと第2のテンプレートとの間を交互するためのセレクタを採用することができる。APは、アクティブ中のテンプレートと干渉せずにアクティブでないいずれのテンプレートに関しても自由に作業することができる。この技術は、ノードアレイ1842、又はシャドーフローテーブル(1092及び1096)の使用と類似する。
代替実施形態:分岐された高低スループット
図10Aに関して上述されるように、高速パケット処理に関しては、様々な機能、例えばフラグメンテーション、は要求されない場合があり、他方、その他のパケット型又はレガシー802.11パケットに関するサポートは依然として希望される場合がある。図48は、2つ以上のMACプロセッサを採用する代替実施形態を示す。高速MACプロセッサ、例えば詳述されるH2Wプロセッサ530及び下位のMAC540(上記において詳述される、240等のMACプロセッサにおいて採用)、は、効率的な高速処理のために(おそらく単純化された機能を有する状態で)採用することができ、代替MACプロセッサ4810は、その他のパケット型(又はレガシーパケット、例えば様々な型の802.11パケット)を処理するために並行して採用される。
一実施形態例においては、より低いスループットのMACプロセッサ4810がプロセッサ210において具体化され(さらに希望される場合は、その他の構成要素、例えばレガシーパケット処理に関して採用された構成要素、を含むこともできる)。実施形態例におけるプロセッサ210は、低スループットパケット及びレガシーパケットを処理する十分な電力を有しており、H2Wプロセッサ530等のより高いスループットの構成要素が高スループットパケットを効率的にサポートできるように設計することを可能にする。その他の実施形態は、後述されるように、追加のMACプロセッサを含むことができる。
この例においては、802.11(n)は、フラグメンテーションをサポートしないため、上述される実施形態は、フラグメンテーションサポートをハードウェアから取り除いてファームウェア内に実装することによって単純化することができる。様々な単純化例が上記において説明される。(フラグメンテーションしきい値はチャンクサイズと異なることができるため)全レガシーパケットをファームウェアに処理させることは、フラグメンテーションサポートを取り除くことを可能にし、送信エンジン及び受信エンジンを単純化し、ノード及びチャンク管理を単純化する。当業者は、いずれの特長がサポートされるかに依存して様々な処理ブロックを含むか又は省略するように本明細書において詳述される実施形態を容易に適合化するであろう。
当業者は、様々なパケット型の全機能を処理する能力を有する単一のプロセッサを含む実施形態と各々が部分組の機能を提供する能力を有する2つ以上のMACプロセッサを具備する他の実施形態との間において犠牲になる事柄を容易に理解するであろう。当然ながら、単一の組の機能を要求するパケットを処理する能力を有するMACプロセッサも採用可能である。
分岐された高低スループットは、複数のMACプロセッサ間において機能をパーティショニングする一例であるにすぎない。一般的には、あらゆる組の機能を異なるMACプロセッサにおいて採用することができる。例えば、異なるパケット型に関する処理上の要求が構成要素を共有することによって効率を達成させる上で十分な類似性を共有しないとき又は回路設計上の考慮事項が様々なパケット型をサポートするための設計間において十分に類似していない場合に2つの等しい高速の(又はいずれかの速度の)パケット型を別個のプロセッサにおいて処理することが望ましい場合がある。
図49は、上述される第1のMACプロセッサと、マイクロプロセッサ内において具体化された第2のMACプロセッサと、を含む2つのMACプロセッサを含む無線通信デバイス4900(例えば、アクセスポイント104又はユーザーデバイス106)の実施形態例を示す。この例は、図48の一般化された実施形態と類似するより詳細な例である。
当業者は、上図5において示される実施形態を図49に示される代替実施形態に合わせて容易に適合化するであろう。この例においては、入力パケット及び出力パケットがバス4980において外部インタフェースから到着及び出発する。外部インタフェース例は、SDIO I/F 582、PCI I/F 584、USBインタフェース、又はその他の型のインタフェースを含む。インタフェースは、1つ以上のインタフェース間で仲裁する及び/又は多重化するための回路を含むことができる。着信パケットは、入力ブロック4910によって処理され、上述される入力及びメモリ管理技術を用いて、メモリインタフェース4940を介してメモリ内に格納される。メモリインタフェース4920は、例えば、メモリアービター552及び/又は556、mux554、SRAMインタフェース558、SDRAMインタフェース562、又は様々なその他の構成要素を含むことができる。当業者は、その他のメモリインタフェースも同様に適合化するであろう。
図5の実施形態とは対照的に、一定のパケット型がプロセッサ(例えばプロセッサ210)において処理される。この例においては、プロセッサによってフォーマット化されることになる入力パケットは、メモリインタフェース4920からプロセッサバス520を介してプロセッサに引き渡される(様々なその他の構成要素もプロセッサバス520に取り付けることができ、その例が図5に示される)。プロセッサインタフェースは、メモリインタフェース4920とバス520との間に配置することができる。この例においては、1つ以上のプロセッサメモリFIFO4950が配置される(受信されたパケットを引き渡すためのその他のインタフェース)。このことは、パケット(及びノード、チャンク等のデータ構造)をプロセッサ210用に格納することを可能にする。受信された低スループットパケットもプロセッサ210によって処理され、プロセッサメモリFIFO4950を介してメモリインタフェース4920からプロセッサバス520に転送することができる。
代替実施形態においては、プロセッサメモリFIFOは、プロセッサメモリへの直接接続に代えることができる。例えば、DMAを用いて、低速パケットをプロセッサ210による処理のためにメモリ内に入れることができる。一実施形態においては、メモリインタフェース4920は、低速パケットを高速パケットRAM内に格納せずに低速パケットを(FIFOではなく)直接プロセッサメモリ4950内に書き込むことができる。
この例においては、パケットは、プロセッサ210によって(メモリインタフェース4920を介して)メモリに格納することもできる。例えば、プロセッサは、受信されたパケットを外部インタフェースにおいて送出せずにWLANにおいて再ルーティングして戻すことができる。本明細書において詳述される全実施形態は、受信されたパケットを送信のために再ルーティングして戻すように適合化できることに注目すること。バス520に引き渡されたパケットは、上述される技術のうちのいずれかを用いてフォーマット化することができる。
実施形態例においては、802.11(b)、(g)及び(e)パケットは、フォーマット化(該当すると思われるあらゆるフラグメンテーションを含む)のためにプロセッサにルーティングされる。その他のパケット型もプロセッサによるフォーマット化に適することができる。例えば、802.11(n)は、同じくプロセッサによって適切にフォーマット化される統合MACサービスデータユニット(A−MSDU)を規定する。様々な再ルーティング技術を採用することができる。この例においては、パケットがプロセッサによるフォーマット化のために受信されたときには、パケットはメモリに格納され、送信用のフォーマット化を開始するための割り込みがプロセッサに与えられる(詳細は示されない)。
フォーマット化された低スループットパケット又はレガシーパケットは、プロセッサ210による処理後に、プロセッサWLAN送信FIFO4960における送信のために格納することができる。レディ信号、スロットル制御を提供するための信号、等のフィードバックをプロセッサWLAN FIFO4960に対して行うことができる。これらのパケットは、待ち行列に入れるため及び(例えばレガシープロトコルエンジン2210による)可能なさらなる処理のために及び究極的にはPHY260での送信のためにTXエンジン1880に引き渡すこともできる。これらのパケットは、直接TXエンジン1880に引き渡すことができ、又はアレイ制御1840によって管理される待ち行列1850(図18において説明)に組み入れることができる、等である。実施形態例においては、統合モジュール2610はレガシーパケット及びA−MSDUパケットに関しては迂回できることに注目すること。
高速パケット、例えば802.11(n)統合Macプロトコルデータユニット(A−MPDU)、は、同じく入力ブロック4910によって受信されてメモリインタフェース4920を介してメモリに格納される。この場合は、パケットは、上記において(例えば図18に関して)詳述される技術を用いてTXエンジン1880によって送信される。この例においては、高速パケットのハードウェア処理は、高速送信を考慮し、上述されるレガシーパケット等のより低速のパケットは、スループットのボトルネックを発生させずにプロセッサ210のファームウェアにおいて実行することができる。このことは、様々なレガシーパケットの詳細が高速MAC処理ハードウェアから置き去りにされることを考慮し、より効率的に設計され、その一方で依然としてファームウェア実装MACプロセッサを通じてレガシーサポートを提供することを可能にする。高速パケットは、究極的には、PHYを介してWLANにおいて送信される。高速又は低速の物理的送信を示すためのヘッダーを用いることができる。
WLANから受信されたパケットは、結合されたRXエンジン4970に引き渡され、究極的にはメモリインタフェース4920を介してメモリに格納される。低速パケットは、処理を目的としてプロセッサ210に渡すことができる(すなわち、レガシーパケット、又は、ハードウェアMACプロセッサにおいてサポートされない特長を用いるパケット、例えばフラグメンテーション)。代替実施形態においては、パケットは、(メモリに格納されずに)直接プロセッサ210に進むことができ又はその他の代替MACプロセッサに接続することができる(あらゆる数の組のパケットの特長をサポートするためにあらゆる数のMACプロセッサを採用できることを思い出すこと)。この例においては、低スループットパケット又はレガシーパケットは、上述されるように、プロセッサメモリFIFO4950を介してメモリインタフェース4920からプロセッサに引き渡される。これらのパケットは、レガシープロトコルエンジン2210によって部分的に処理することができる場合とできない場合がある。分割ユニット2802は、統合されていないデータユニット(例えばレガシーパケット)に関しては迂回できることに注目すること。
RXエンジン4970(及び採用された場合のその他の構成要素、例えばレガシーエンジン2210)は、下位MACコア540において上述される分割パケットを処理する。この例においては、ハードウェアMACプロセッサにおいて処理されるパケットは高速パケットだけであるが、代替実施形態においては、あらゆる型のパケットを処理することができる。
RXエンジン4970は、上記において詳述されるように、レガシーエンジン2210を用いていずれのパケット型も解読することができる。受信されたパケットは、パケット型を示すためのMAC/PHYインタフェース(例えば、上記において詳述されるMAC/PHYインタフェース545)によってタグを付すことができる点に注目すること。例えば、パケットは、801.11(a)、(b)、(e)、(g)、(n)、等として識別することができる。パケットは、A−MSDU又はA−MPDUとして識別することができる。一般的には、あらゆる数のMACプロセッサのうちの1つへのパケットのルーティングを示すためのタグを用いることができる。
直前において説明される実施形態例においては、統合及び分割は、高速パケットのみに適用される点に注目すること(上述されるように、統合は、高速パケットに関してはオプションである)。低速パケットは、統合ブロック及び分割ブロックを通じて渡される。フラグメンテーションは、レガシーパケット及び低速パケットのみに関してサポートされ、高速パケットに関してはサポートされない。プロセッサ(すなわち、210)は、第1のMACプロセッサであり、第2のMACプロセッサは、上記において詳述される様々な構成要素を具備する(すなわち、図5)。上述されるように、これらは例であるにすぎない。一般的には、第1のMACプロセッサにおいてはあらゆる特長組をサポートすることができ、第2のMACプロセッサにおいては同じ組の又は異なる組の特長をサポートすることができる(これらのうちのいずれかはプロセッサ210等のプロセッサを用いて実行することができ、又はいずれも実行することができない)。
出力ブロック4930は、メモリインタフェース4920を介して高速パケットをパケットバッファから受信してハンドオフすることができる。出力ブロック4930は、プロセッサ出力FIFO 4940から引き渡された低速パケットと高速パケットとの間で仲裁することもできる。実施形態例においては、プロセッサは、優先度順でのハンドオフの準備が整っている処理済みパケットをプロセッサ出力FIFO 4940に引き渡す。代替実施形態においては、代替メモリは、出力ブロック4930が希望される場合は出力ブロック4930内における優先順位設定のためにパケットを選択するのを可能にするためにプロセッサ出力FIFO 4940を交換することが可能である。さらに他の代替実施形態においては、プロセッサ出力FIFO 4940は取り除くことが可能であり、出力ブロック4930は、(例えばDMA又はその他のアクセス方法を用いて)プロセッサメモリへの直接アクセスを介して低速パケットをハンドオフすることができる。さらに他の実施形態においては、プロセッサ出力FIFO 4940は、出力ブロック4930が優先度方式を実装するために選択することができる複数の優先待ち行列を有することができる。
当業者は、無線通信デバイス4900において具体化された教義の非常に数多くの代替構成を認識するであろう。
図50は、多フローパケットバッファリング及び待ち行列化の側面を示す。図50は、パケットバッファ5030内の第1のデータ構造5040内に、第1のパケット5050の長さ、パケット5060のシーケンス番号、及びパケットバッファ内の第2のデータ構造5080の第2のパケットバッファ格納場所5070を格納するための手段5010と、第1のパケットからのデータ5020を、格納された第2のパケットバッファ格納場所5070によって識別される第2のデータ構造5080内に格納するための手段5020と、を具備する。
図51は、多フローパケットバッファリング及び待ち行列化の側面を示す。図51は、パケットと関連づけられた第1のデータ構造5140と、関連づけられたパケットからのデータを具備する1つ以上の第2のデータ構造5180と、を具備し、関連づけられたパケットの長さを示す長さフィールド5150を具備する第1のデータ構造、関連づけられたパケットのシーケンス番号を示すシーケンス番号フィールド5160、及びパケットバッファ5130内における第2のデータ構造5180のうちの1つの場所を示す第2のデータ構造ポインタフィールド5170を示し、第2のデータ構造5180のうちの1つ以上のデータ構造内にパケットを格納するのための手段5120を示す。
図52は、高速メディアアクセス制御に関するメモリ管理の側面を示す。図52は、第1又は第2のモードを選択するための手段5290と、複数の通信フローの各々に関する1つ以上のパラメータを格納するように第1のモードにおいて第1のメモリ5230を構成するための手段5210と、複数の通信フローの各々に関するポインタを格納するように第2のモードにおいて第1のメモリを構成するための手段5260であって、各ポインタは、各々の通信フローと関連づけられた格納場所を示す手段5260と、複数の通信フローの各々に関するパケットを格納するように第1のモードにおいて第2のメモリ5240を構成するための手段5220と、複数の通信フローの各々に関する1つ以上のパラメータから成る複数の組を格納するように第2のモードにおいて第2のメモリを構成するための手段5270であって、1つ以上のパラメータから成る各組は、各々の通信フローと関連づけられたポインタによって示される格納場所に格納される手段5270と、複数の通信フローの各々に関するパケットを格納するために動作可能になるように第2のモードにおいて第3のメモリとともに動作可能なメモリインタフェース5250を構成するための手段5280と、を具備する。
図53は、多フローメディアアクセス制御の側面を示す。図53は、複数のフロー識別子インデックス値のうちの1つへのフロー識別子インデックスを設定するための手段5320であって、各フロー識別子インデックスは、複数のフローのうち各々の1つと関連づけられた手段5320と、第1のメモリ5330内の複数の第1のメモリ場所に複数のパラメータ組5340を格納するための手段5310であって、各パラメータ組は、複数のフローの各々の1つに関する1つ以上のパラメータを具備し、各パラメータ組に関する第1のメモリ場所は、フロー識別子インデックス内において設定された各々のフロー識別子インデックス値によって識別される手段5310と、複数のパラメータ組のうちの1つの組のパラメータのうちの1つ以上をフロー識別子インデックスに従って第1のメモリから取り出すための手段5350と、を具備する。
図54は、多フローメディアアクセス制御の側面を示す。図54は、複数のパラメータ組5420を第1のメモリ5430に格納するための手段5410であって、各パラメータ組は、複数のパラメータ組格納場所のうちの各々の1つにおいて格納され、各パラメータ組は、複数のフローの各々の1つに関する1つ以上のパラメータを具備し、複数のフローの各々は、複数のフロー識別子のうちの1つによって識別される手段5410と、複数のパラメータ組ポインタ5450を第2のメモリに格納するための手段5440であって、各パラメータ組ポインタは、第1のメモリ内における複数のパラメータ組格納場所のうちの1つを識別し、各パラメータ組ポインタは、複数のフローのうちの1つと関連づけられた手段5440と、フロー識別子に従って第2のメモリからパラメータ組ポインタを取り出すための手段5470と、取り出されたパラメータ組ポインタに従ってパラメータ組にアクセスすることによって第1のメモリから1つ以上のパラメータを取り出すための手段5480と、を具備する。
図55は、高速メディアアクセス制御に関する多フロー多重化の側面を示す。図55は、第2の複数の待ち行列5530の各々における複数のフローのうちの1つと関連づけられた1つ以上のパケット要素5520を格納するための手段5510と、第2の複数の待ち行列のうちの1つから要素を選択するための手段5540と、第1の複数の待ち行列5570のうちの1つに選択された要素5560を格納するための手段5550であって、各待ち行列は、複数のチャネルのうちの1つと関連づけられる手段5550と、を具備する。
図56は、高速通信システムにおける統合の側面を示す。図56は、1つ以上の第1のデータ構造5620を待ち行列5630内に格納するための手段5610であって、各々の第1のデータ構造は、各々の関連づけられたパケットの長さフィールド5635と、第2のデータ構造5650へのポインタ5640と、を具備し、第2のデータ構造は、各々の関連づけられたパケットデータの少なくとも一部分を具備する手段5610と、送信データ量を決定するための手段5660と、待ち行列内の第1のデータ構造のうちの1つ以上の第1のデータ構造の長さフィールドから1つ以上の長さ値を取り出すための手段5670と、一組の1つ以上の第1のデータ構造からの取り出された長さ値の合計が送信データ量よりも小さいか又は同じであるような形で前記第1のデータ構造の組を選択するための手段5680と、統合プロトコルデータユニット内のパケットを統合するための手段5690であって、各々の統合されたパケットは、選択された第1のデータ構造の組内の第2のデータ構造を指し示すポインタによって識別される手段5690と、を具備する。
図57は、サービス中待ち行列及び待機中待ち行列として働くシャドーキャッシュの側面を示す。図57は、第1の待ち行列5710をサービス中待ち行列として選択するための手段5720と、第2の待ち行列5730を待機中待ち行列として選択するための手段5740と、第1のフローをスケジューリングするための手段5750と、第2のフローをスケジューリングするための手段5760と、サービス中待ち行列内の第1のスケジューリングされたフローと関連づけられた1つ以上の要素を格納するための手段5770と、第1の送信機会中における送信のためにサービス中待ち行列を処理するための手段5780と、待機中待ち行列内の第2のスケジューリングされたフローと関連づけられた1つ以上の要素を格納するための手段5790であって、格納することは、サービス中待ち行列の処理と同時に生じることができる手段5790と、を具備する。
図58は、入力ポリシングの側面を示す。図58は、複数のフローのうちの1つに関するパケットと関連づけられたフロー識別子を受信するための手段5810と、フロー識別子と関連づけられた1つ以上のパラメータを取り出すための手段5820と、予め決められた条件がフロー識別子と関連づけられた1つ以上の取り出されたパラメータに従って満たされるときにパケットを受け付けるための手段5830と、予め決められた条件がフロー識別子と関連づけられた1つ以上の取り出されたパラメータに従って満たされていないときにはパケットを拒否するための手段5840と、を具備する。
図59は、入力ポリシングの側面を示す。図59は、複数のフローのうちの1つに関するパケットと関連づけられたフロー識別子を受信するための手段5910と、現在のパケットバッファ占有率を取り出すための手段5920と、フロー識別子と関連づけられた最大バッファ占有率を取り出すための手段5930と、フロー識別子と関連づけられた累積パケットを取り出すための手段5940と、フロー識別子と関連づけられた最大パケットを取り出すための手段5950と、現在のパケットバッファ占有率がフロー識別子と関連づけられた最大バッファ占有率よりも小さいか又はフロー識別子と関連づけられた累積パケットがフロー識別子と関連づけられた最大パケットよりも少ないときにはパケットを受け付けるための手段5960と、を具備する。
図60は、入力ポリシングの側面を示す。図60は、パケットバッファ6010と、複数のフローのうちの1つに関する1つ以上のパラメータを取り出すための手段6020と、1つ以上の取り出されたパラメータに従ってパケットバッファ内に複数のフローのうちの1つと関連づけられたパケットを条件付きで格納するための手段6030と、を具備する。
図61は、低レーテンシー応答に関するメディアアクセス制御の側面を示す。図61は、1つ以上の第1のデータ構造6120を待ち行列6130内に格納するための手段6110であって、各々の第1のデータ構造は、各々の関連づけられたパケットの長さフィールド6135と、第2のデータ構造6150を指し示すポインタ6140と、を具備し、第2のデータ構造は、各々の関連づけられたパケットデータの少なくとも一部分を具備する手段6110と、予め決められた時間間隔内における応答送信を要求する送信機会に応じて待ち行列内の第1のデータ構造のうちの1つ以上のデータ構造の長さフィールドから1つ以上の長さ値を取り出すための手段6160と、予め決められた時間間隔内において応答プロトコルデータユニットを形成するための手段6170であって、プロトコルデータユニットは、予め決められた時間間隔内において少なくとも1つの長さ値に従って決定されたプロトコルデータユニット長さ値を具備する手段6170と、を具備する。
情報及び信号は、様々な種類の技術及び技法のうちのいずれかを用いて表すことができることを当業者は理解するであろう。例えば、上記の説明全体を通じて言及されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、及びチップは、電圧、電流、電磁波、磁界、磁粒子、光学界、光学粒子、又はそのあらゆる組合せによって表すことができる。
本明細書において開示される実施形態に関係させて説明される様々な例示的論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェアとして、コンピュータソフトウェアとして、又は両方の組合せとして実装できることを当業者はさらに理解であろう。ハードウェアとソフトウェアのこの互換性を明確に例示するため、上記においては、様々な例示的構成要素、ブロック、モジュール、回路、及びステップが、各々の機能の観点で一般的に説明されている。これらの機能がハードウェアとして又はソフトウェアとして実装されるかは、全体的システムに対する特定の用途上の及び設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、該実装決定は、本開示の適用範囲からの逸脱を生じさせるものであるとは解釈すべきではない。
本明細書において開示される実施形態に関して説明される様々な例示的な論理ブロック、モジュール、及び回路は、本明細書において説明されている機能を果たすように設計された汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、その他のプログラミング可能な論理デバイス、ディスクリートゲートロジック、ディスクリートトランジスタロジック、ディスクリートハードウェア構成品、又はそのあらゆる組合せ、とともに実装又は実行することができる。汎用プロセッサはマイクロプロセッサであることができるが、代替策として、従来のどのようなプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってもよい。さらに、プロセッサは、計算装置の組合せ、例えば、DSPと、1つのマイクロプロセッサとの組合せ、複数のマイクロプロセッサとの組合せ、DSPコアと関連する1つ以上のマイクロプロセッサとの組合せ、又はその他のあらゆる該コンフィギュレーションとの組合せ、として実装することもできる。
本明細書において開示される実施形態に関して説明される方法又はアルゴリズムのステップは、ハードウェア内において直接具体化させること、プロセッサによって実行されるソフトウェアモジュール内において具体化させること、又はこれらの2つの組合せにおいて具体化させることができる。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、取り外し可能なディスク、CD−ROM、又は当業において既知であるその他のあらゆる形態の記憶媒体に常駐することができる。1つの典型的な記憶媒体をプロセッサに結合させ、プロセッサが記憶媒体から情報を読み出すようにすること及び記憶媒体に情報を書き込むようにすることができる。代替として、記憶媒体は、プロセッサと一体化させることができる。プロセッサ及び記憶媒体は、ASIC内に常駐することができる。ASICは、ユーザー端末内に常駐することができる。代替として、プロセッサ及び記憶媒体は、ユーザー端末内において個別構成要素として常駐することができる。
開示されている実施形態に関する上記の説明は、当業者が本開示を製造又は使用できるようにすることを目的とするものである。実施形態に対する様々な修正は、当業者にとって容易に明確になるであろう。さらに、本明細書において定められている一般原理は、本開示の精神及び適用範囲を逸脱しない形でその他の実施形態に対しても適用することができる。以上のように、本開示は、本明細書において示される実施形態に限定することを意図するものではなく、本明細書において開示されている原理及び斬新な特長に一致する限りにおいて最も広範な適用範囲が認められるべきである。