(57)【特許請求の範囲】
【請求項１】
発出データの転送を管理する方法であって、
（ａ）第１の優先順位レベルに対応する発出データを記憶する第１のデータキューを送信方向に提供する工程と、
（ｂ）少なくとも１つの他の優先順位レベルに対応する発出データを記憶する少なくとも１つの他のデータキューを送信方向に提供する工程とを含み、前記少なくとも１つの他の優先順位レベルは前記第１の優先順位レベルよりも低いものであり、さらに、
（ｃ）前記少なくとも１つの他のデータキューに対応するデータ飢餓状態をチェックする工程と、
（ｄ）前記データ飢餓状態が検出されたときには、前記第１のデータキューをサービスする前に、前記少なくとも１つの他のデータキューのうちの１又はそれ以上のデータキューをサービスする工程と、
（ｅ）前記データ飢餓状態が検出されないときには、前記第１のデータキューと前記少なくとも１つの他のデータキューとを、最も高い優先順位レベルから最も低い優先順位レベルの順番でサービスする工程とを含むことを特徴とする方法。
【請求項２】
前記工程（ａ）乃至（ｅ）を実行する前に、
（１）入来データと発出データとの双方が転送のためにキューに入れられたかを判定する工程と、
（２）（ｉ）前記入来データと前記発出データとが転送のためにキューに入れられ、且つ、（ｉｉ）最近のデータ転送が受信方向である、ときには、次のデータ転送方向として送信方向を選択する工程と、
（３）（ｉ）前記入来データと前記発出データとが転送のためにキューに入れられ、且つ、（ｉｉ）最近のデータ転送が前記送信方向である、ときには、次のデータ転送方向として、前記受信方向を選択する工程と、
（４）前記選択された次のデータ転送方向に対応する、キューに入れられた前記データをサービスする工程とを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記少なくとも１つの他のデータキューは少なくとも２つのデータキューを含み、その各々は、前記第１のデータキューとは異なり、そして全ての他のデータキューとも異なる優先順位レベルに対応する発出データを記憶するものであり、
前記工程（ｃ）は、前記少なくとも２つのデータキューに対応するデータ飢餓状態をチェックする工程を含み、そして、
前記工程（ｄ）は、前記第１のデータキューをサービスする前に、前記飢餓状態に対応する前記少なくとも２つのデータキューのデータキューのみをサービスする工程を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記少なくとも１つの他のデータキューは、第２及び第３の優先順位レベルのそれぞれに対応するデータを記憶する少なくとも第２及び第３のデータキューを含み、前記第２の優先順位レベルは前記第１の優先順位レベルよりも低く、そして、前記第３の優先順位レベルは前記第２の優先順位レベルよりも低いものであり、さらに、
前記工程（ｄ）は、前記データ飢餓状態が検出されたときには、前記第１のデータキューをサービスする前に、前記第２のデータキューが前記第３のデータキューよりもより頻繁にサービスされるように、加重ラウンドロビン手法で少なくとも第２及び第３のデータキューをサービスする工程を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記少なくとも１つの他のデータキューは、第２及び第３の優先順位レベルのそれぞれに対応するデータを記憶する少なくとも第２及び第３のデータキューを含み、前記第２の優先順位レベルは前記第１の優先順位レベルよりも低く、そして、前記第３の優先順位レベルは前記第２の優先順位レベルよりも低いものであり、さらに、
前記第１の優先順位レベルは音声データに対応し、
前記第３の優先順位レベルはベスト・エフォートデータに対応し、そして、
前記第２の優先順位レベルは、前記ベスト・エフォートデータと前記音声データとの間の中間の優先順位レベルに対応することを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記工程（ｃ）は、
（ｃ１）送信のためにバッファされたメッセージの数を判定する工程と、
（ｃ２）前記送信のためにバッファされたメッセージの判定された数を特定のしきい値と比較する工程と、
（ｃ３）前記データ飢餓状態が前記比較に基づいて検出されたかどうかを判定する工程とを含むことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項７】
前記工程（ｃ）は、
（ｃ１）前記少なくとも１つの他のデータキューから前記発出データが転送される速度を判定する工程と、
（ｃ２）前記速度を特定の閾値と比較する工程と、
（ｃ３）前記比較に基づいて前記データ飢餓状態が検出されたかを判定する工程とを含むことを特徴とする請求項１に記載の方法。
【請求項８】
発出データの転送を管理する装置であって、
第１の優先順位レベルに対応する発出データを記憶する第１のデータキューを送信方向に提供する手段と、
少なくとも１つの他の優先順位レベルに対応する発出データを記憶する少なくとも１つの他のデータキューを送信方向に提供する手段とを含み、前記少なくとも１つの他の優先順位レベルは前記第１の優先順位レベルよりも低いものであり、さらに、
前記少なくとも１つの他のデータキューに対応するデータ飢餓状態をチェックする手段と、
前記データ飢餓状態が検出されたときには、前記第１のデータキューの前に、前記少なくとも１つの他のデータキューのうちの１又はそれ以上のデータキューをサービスする手段と、
前記データ飢餓状態が検出されないときには、前記第１のデータキューと前記少なくとも１つの他のデータキューとを、最も高い優先順位レベルから最も低い優先順位レベルの順番でサービスする手段とを含むことを特徴とする装置。
【請求項９】
入来データと発出データとの双方が転送のためにキューに入れられたかを判定する手段と、
（ｉ）入来データと発出データとの双方が転送のためにキューに入れられ、且つ、（ｉｉ）最近のデータ転送が受信方向である、ときには、次のデータ転送方向として送信方向を選択する手段と、
（ｉ）入来データと発出データとの双方が転送のためにキューに入れられ、且つ、（ｉｉ）最近のデータ転送が前記送信方向である、ときには、次のデータ転送方向として前記受信方向を選択する手段と、
前記選択された次のデータ転送方向に対応する、キューに入れられた前記データをサービスする手段とを含むことを特徴とする請求項８に記載の装置。
【請求項１０】
前記少なくとも１つの他のデータキューは少なくとも２つのデータキューを含み、その各々は、前記第１のデータキューとは異なり、そして全ての他のデータキューとも異なる優先順位レベルに対応する発出データを記憶するものであり、
前記少なくとも１つの他のデータキューに対応するデータ飢餓状態をチェックする手段は、前記少なくとも２つのデータキューに対応するデータ飢餓状態をチェックする手段を含み、そして、
前記選択された次のデータ転送方向に対応する、キューに入れられた前記データをサービスする手段は、前記第１のデータキューをサービスする前に、前記飢餓状態に対応する前記少なくとも２つのデータキューのデータキューのみをサービスする手段を含むことを特徴とする請求項８に記載の装置。
【請求項１１】
前記少なくとも１つの他のデータキューは、第２及び第３の優先順位レベルのそれぞれに対応するデータを記憶する少なくとも第２及び第３のデータキューを含み、前記第２の優先順位レベルは前記第１の優先順位レベルよりも低く、そして、前記第３の優先順位レベルは前記第２の優先順位レベルよりも低いものであり、さらに、
前記第１のデータキューの前に、前記少なくとも１つの他のデータキューのうちの１又はそれ以上のデータキューをサービスする前記手段は、前記データ飢餓状態が検出されたときには、前記第１のデータキューをサービスする前に、前記第２のデータキューが前記第３のデータキューよりもより頻繁にサービスされるように、加重ラウンド・ロビン方式で少なくとも第２及び第３のデータキューをサービスすることを特徴とする請求項８に記載の装置。
【請求項１２】
前記少なくとも１つの他のデータキューに対応するデータ飢餓状態をチェックする前記手段は、前記少なくとも１つの他のデータキューから前記発出データが転送される速度を判定し、前記速度を特定の閾値と比較し、前記比較に基づいて前記データ飢餓状態が検出されたかを判定することを特徴とする請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、そのすべてが参照により明示的に本明細書に組み込まれている、２００２年１１月１３日に出願した「Ｔｅｃｈｎｉｑｕｅｓ  Ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｐｒｉｏｒｉｔｙ  Ｑｕｅｕｅｓ  ａｎｄ  Ｅｓｃａｌａｔｉｏｎ  Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ  ｉｎ  Ｗｉｒｅｌｅｓｓ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍｓ」という名称の米国特許出願第６０／４２５，８９５号の優先権を主張するものである。
本発明は、ワイヤレス・ローカル・エリア・ネットワーク（ＬＡＮ）通信システムにおけるサービス品質（ＱｏＳ）機構に関する。より詳細には、本発明は、ワイヤレス通信システムにおいて、送信中の優先順位のより高いトラフィックの持続期間中に、優先順位のより低いトラフィックがメディアへのアクセスを妨げられないようにするための、複数の優先キューの管理に関する。
【背景技術】
【０００２】
背景技術による通信システムでは、「送信」パケットは、通常、システム・ドライバまたはソフトウェアによって指令される常駐のデータ移動エンジンまたはＤＭＡエンジンの制御下で、ホスト・メモリから内部送信（パケット）バッファに流れる。メディア・アクセス・コントローラ（ＭＡＣ）はこのパケット・バッファから送信データを取り出し、それを適切に組み立て（ｆｒａｍｅ）、物理ネットワーク・レイヤ装置に転送する。同様に、「受信」パケットはレシーバからＭＡＣに流れる。ＭＡＣはパケット・データをその前後のヘッダおよびＣＲＣから分離して抽出し、パケット管理ロジックは、ネットワーク・フロー制御およびパワー管理のために、各パケットを破棄すべきか、バッファに入れるべきか、あるいは単に復号すべきかを判定する。受信バッファに到達した各パケットは、やはりホスト・ドライバ制御下で動作するデータ移動エンジンを介してホスト・コンピュータに転送される。一般に、オンデバイス・バッファの機能の実装では、装置上に送ることができる物理データの量が制限される。すなわち、パケット・メモリは一般に、コストと領域の問題のために制限される。
【０００３】
背景技術によるこれらの通信システムでは、パケットは「ベスト・エフォート型」の方式で順次キューに入り、管理される。
【０００４】
図４は、優先順位に基づかない従来の管理方法を示す構成図である。
【０００５】
具体的には、図４に示すように、ＭＡＣ（メディア・アクセス制御レイヤ）１１０は、システム１２０とメディア１３０の間に配置されている。ＭＡＣ１１０は、送信パケット・バッファ１５０および関連するチャネル・アクセス・ルーチン１６０、ならびに受信パケット・バッファ１８０および関連するチャネル・アクセス・ルーチン１９０を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
単一のキュー構造のみを提供するシステムでは、送信方向において、複数のクラスの優先トラフィック・シナリオを確立したいシステム内の利用可能な（システム／ホスト）送信バッファで最小限のパケット・キューイング戦略を利用するようソフトウェアに求める境界条件が、実際にシステム・ソフトウェアまたはドライバに課せられる。（送信方向は、パケットがローカル・システム・メモリからシステムを介してメディア上に出る方向として定義する。受信方向は、メディアからの着信パケットが復調されシステム・メモリに入る方向として定義する。）こうした要件すなわち境界条件が通常システムに課せられるのは、優先順位の高いパケットがオペレーティング・システムからドライバに渡されるときに潜在的に大きな遅延状態が生じるのを回避するためである。こうした優先フレームは、主として、利用可能なバッファ・スペースが所有または消費されているかどうか不明である（例えば、すでに装置に解放されているかもしれない）ために、既存のキューに容易に「挿入」することができない。
【特許文献１】米国特許出願第６０／４２５，８９５号
【課題を解決するための手段】
【０００７】
本発明によれば、最新のデータ転送が受信方向であった場合、送信方向を優先方向として指定する。最新のデータ転送が送信方向であった場合は、受信方向を優先方向として指定する。優先方向に転送すべきデータがキューに入っている場合は、データは優先方向に転送される。
【０００８】
本発明の他の態様によれば、データをキューに入れる方法および機器は、送信方向の複数のデータ・キューを提供することを含む。各データ・キューの優先順位は、所定の複数の異なるレベルの優先順位の１つである。その複数のデータ・キューのうち優先順位の最も低いキューにおいてデータ飢餓状態であるかどうかチェックされる。データ飢餓状態が検出された場合は、その優先順位の最も低いデータ・キューがサービスされる。
【０００９】
本発明の他の態様によれば、データをキューに入れる方法は、それぞれの優先順位が所定の複数の異なるレベルの優先順位の１つである、送信方向の複数のデータ・キューを提供することを含む。複数のデータ・キューのそれぞれをサービスする所定の加重ラウンド・ロビン・スケジューリングが確立される。このスケジューリングでは、各サービス・ラウンドにおける複数のデータ・キューのうちの少なくとも２つのデータ・キューに対するサービスの回数が異なる。
【００１０】
以下の説明を図面を参照しながら読めば、本発明の特徴および利点が当業者に明らかになるであろう。
【発明を実施するための最良の形態】
【００１１】
本発明の原理によれば、簡単な制御機構と一緒に使用されるとき、複数の通信トラフィック・クラスならびに待ち時間および送信に関する異なる目的をそれぞれ異なる方法で扱えるようにする複数のデータ・キューが通信システムに追加される。
【００１２】
消費者が様々な体験を味わえるように、ワイヤレス・ローカル・エリア・ネットワーク通信システムにおいてサービス品質イニシアチブをサポートするために利用できる機構を考慮することは有益である。サービス品質（ＱｏＳ）は、異なるタイプの通信トラフィックをそれぞれ異なる方法で扱うことを意味する包括的な表現である。
【００１３】
遠隔通信システムでは、ＱｏＳは通常、電話を使うことに慣れているユーザが高音質の音声を期待する音声サービスおよびビデオ・サービスに関係付けられる。というのは、歴史的に音声は優先順位が高いとみなされていたからである。データ通信システムでは、ＱｏＳは通常マルチメディア・サービスに関係付けられる。あるいは、より一般には、データ・パケットがリアルタイムで何らかの理由で失われた場合にも「自動」優先順位または再送信を必要としないあらゆるタイプのデータ・ストリーム（「ストリーミング・サービス」）を扱うデータ・システムに関係している。
【００１４】
遠隔通信システムは本来ストリーム指向であり、データ・システムは本来「バーストな」性質である。遠隔通信システムの回線交換の世界では、「制御」はすべての問題に対するモデルとなる解決策である。
【００１５】
「制御」という解決策は、音声やビデオなど、将来のニーズの予測が容易である定速のアプリケーションには有効であるかもしれないが、データ通信を扱うとき、「制御」解決策では若干の効率が失われる。一方、データ・システムは複雑でありデータ・ソースとデータ・シンクの混合物（すなわちソフトウェア・アプリケーション）を含む。データ・ストリームをパケットに分割すると、数多くのデータ・ストリームを多重化することにより、数多くのソースを効率的に扱うことができるようになる。しかし、システム内で遅延が起こり、その価格は高くなる。一部のアプリケーションでは、この遅延成分を制限、または少なくとも最小限に抑えなければならないが、送信待ち時間の影響を受けにくい（ｉｍｍｕｎｅ）アプリケーション（本明細書では「ベスト・エフォート型」の送信として示す）もある。
【００１６】
ワイヤレス・システムでは、トラフィック・フローが予測不能であるという第２のレベルの不確かさ（したがって遅延の潜在的可能性）が追加される。こうした予測不能性は、ワイヤレス無線リンクならびに外部の干渉原因の予測不能性による部分も少なくない。
したがって、ワイヤレスＬＡＮにおけるトラフィック・クラスの厳密な管理制御は望ましくない。そうではなくて、管理ＷＬＡＮシステムの基本的な目標には、優先トラフィック・フローを維持するために、基本的な「衝突回避」手法を適応型フロー制御と共に堅持することを含めることが好ましい。
【００１７】
開示の実施形態では、このようにすると、メディアの負荷が増すにつれて、より低いサービス・クラスのサービス率が次第に低減する。さらに、そうしたシステムには、ローカル・サービス率の決定を、例えばサービス・クラスごとに行うのに使用されるメディアの負荷フィードバック、および関連するアプリケーションに新しい「接続」が可能であるか否かを伝えるためのドロップ率フィードバックの使用も含めることが好ましい。
【００１８】
Ｑｏｓ管理システムにおける重要な要件は、すべての装置が好ましくは所与のモデルおよびポリシーを実装することである。
【００１９】
優先順位によらない管理システムでは、一般に、システム・レベルでパケットをバッファに入れるために単一のキューイング構造が使用される。しかし、優先トラフィックが利用可能であるときにこの戦略を使用すると、送信（Ｔｘ）または受信（Ｒｘ）方向において、最小限のパケット・キューイング戦略を利用可能なバッファに適用するよう関連するルーチンに求める境界条件が、実際に装置ドライバに課される。この要件がシステムに課されるのは、優先順位の高いパケットがドライバに渡されるときに潜在的に大きな遅延状態が生じるのを回避するためである。基礎となる前提は、利用可能なバッファの所有権が装置に解放されているか否かが不明なので、そうした優先フレームを既存のキューに容易に「挿入」できないことである。
【００２０】
こうした恐れを矯正するために、別の１つまたは複数の優先順位の高いキューを用いると、優先順位のより低いパケットを、優先順位の高いトラフィック・キューとは独立にキューに入れることができるようになる。その後、優先順位の高いトラフィックが利用可能になったとき、優先キュー／バッファにデータが存在する場合、ベスト・エフォート型の（すなわち優先順位のより低い）キューをサービスする前にオンチップ・データ移動エンジンがその優先キュー／バッファからデータを取り出すことができるようにする機構がシステム内に存在する。
【００２１】
新しいシステムでは、待ち時間および送信に関して異なる目的を有する複数のトラフィック・クラスが考慮される。サービス品質（ＱｏＳ）は、異なるタイプの通信トラフィックをそれぞれ異なる方法で扱うことを意味する包括的な表現である。いくつかのトラフィック・クラスの待ち時間および送信に関する目的が与えられている場合、ある種のパケットは「ベスト・エフォート型」の方式で扱うことができなくなり、キュー管理などの追加の問題を考慮することが必要になる。
【００２２】
ＩＥＥＥ８０２．１１（ｅ）は現在、（優先順位の最も低いものから）以下の４つの優先順位クラスまたは層を考慮している。
ベスト・エフォート型
エクセレント・エフォート型
ビデオ（およびオーディオ）
音声
この分析では、優先順位の低い「ベスト・エフォート型」のトラフィック（すなわち、時間の影響を受けないトラフィック）、中位のまたは中間の優先順位クラスのトラフィック（待ち時間に関する若干の要求をもつトラフィック）、および非常に高い優先順位（例えば音声アプリケーション）に対処するための方法を提供する３クラス・システムについて考える。この３クラス・システムでは、便宜上、４クラス・システムのエクセレント・エフォート型トラフィック・クラスとビデオ・トラフィック・クラスを一緒のグループに分類した。これらの技術は、ソフトウェアまたはオンチップ・ハードウェアのどちらかによる方法によって対処することができるが、スループットおよび効率上の重要な利点は、ハードウェアに基づくリアルタイムのキューイングおよびエスカレーション機構を提供することによって実現することができる。したがって、ハードウェアに基づく技術については後で詳しく説明するが、本発明の範囲がそれだけに限らないことが当業者には理解されよう。
【００２３】
いくつかの「優先順位」レベルが考慮されている。１つのレベルでは、送受信パケットを管理する能力が考慮されている。第２の管理レベルは個々の方向またはサービス内で生じ、送信または受信のどちらかの方向で適用できる。この場合、追加の１つまたは複数のレジスタを設計に追加して、優先順位のより高い送信パケットをキューに入れ、「ベスト・エフォート型」の送信パケットとは独立したネットワークに送ることができるようにする。この要件を用いると、所与のバッファ構造にあるキューに入っている送信パケットの数を最小限に抑えることに対する確立された境界が取り除かれるので、ドライバから見て、システムの柔軟性を高めることができる。受信方向では、パケットが迅速に装置から離れてシステム・メモリに移動し、着信（受信）パケットの優先クラス管理が不要となることが想定されている。ただし、上述の送信方向を管理するための技術と同様の技術を受信レベルでも利用することができる。
【００２４】
図１に、本発明の好ましい実施形態による、ハードウェアに基づく優先順位管理方法を示す構成図を示す。
【００２５】
具体的には、図１に示すように、システム２２０とメディア２３０の間にＭＡＣ２１０が配置されている。ＭＡＣ２１０は、送信パス内に複数の異なる優先キュー２４０、スケジューラ／キュー・マネージャ２５０、およびチャネル・アクセサ２６０を含んでおり、受信パス内に複数の異なる優先キュー２７０、スケジューラ／キュー・マネージャ２８０、およびチャネル・アクセサ２９０を含んでいる。
【００２６】
本発明の好ましい実施形態では、音声トラフィック（優先順位の最も高い）など、優先順位の高いトラフィックから始まり、次にビデオ・トラフィックなど、さらに次に「ベスト・エフォート型」のトラフィック（優先順位の最も低い）と、優先順位が高い順に、データ・キュー２４０および２７０がサービスされる。ただし、重要なことには、優先順位の低いキューが持ち続けている場合、例えば「ベスト・エフォート型」のトラフィックが「飢餓状態」になっている場合、すなわち、優先順位の低い「ベスト・エフォート型」のトラフィックが最近十分にまたは本質的にまったく転送されていない場合、優先順位の低いキューに最初にアクセスすべきであることを示す特別のフラグまたはビットがセットされる。
【００２７】
本発明の他の好ましい実施形態では、音声トラフィックの優先順位は厳密であり、他のデータ・キューは加重ラウンド・ロビン方式でサービスされ、すなわち、それぞれのデータ・キューが順番にサービスされ、優先順位のより高い１つまたは複数のキューがより頻繁にサービスされる。
【００２８】
他の実施形態では、好ましくは、データ転送の二方向の間で優先順位を循環させることによって、送信キューと受信キューの間の競合を解決することができる。特に、送受信パケットの管理を考慮する必要があるとき、送信（Ｔｘ）状態と受信（Ｒｘ）状態の間の簡単な優先順位循環方式が好ましいことがある。これは、ある状態が他の状態よりも高い絶対的な優先順位を持たないような方式で考慮されるが、そうすると、「サービス」（ＴｘまたはＲｘとして定義される「サービス」）ごとに飢餓状態が生じる可能性がある。この方式では、オンチップ受信パケット・バッファが制限されている場合、可能な限り迅速かつ効率的に処理を行うために、パケットをオンチップ・ストレージ・レジスタからシステム・メモリに迅速にバーストすることに全般的な優先順位が与えられる。
【００２９】
図２は、本発明の原理による、送信方向と受信方向の間での全体的な優先順位管理の例を示す流れ図である。
【００３０】
具体的には、図２に示すように、コントローラが送信状態３２０または受信状態３３０を離れ、アイドル状態３１０に達するとき、状態マシンが、別の保留中の転送が必要とされているかどうかを調べる。必要な場合は、優先順位循環方式で送信セクションと受信セクションの間の仲裁を行う。
【００３１】
この制約は送信方向にも受信方向にも適用されることに留意されたい。さらに、こうした制約の結果、実際に、両方のイベントがアクティブである場合を明示的に扱うことを必要としない所望の自動優先順位循環方式が得られる。
【００３２】
受信方向または送信方向での優先順位循環方式について考えるとき、サービス（この場合、送信サービスまたは受信サービスを示すために使用）ごとに優先トラフィックを受け入れることができるかどうかを考慮する必要がある。送信サービス側を考えると、送信方向の優先トラフィックを受け入れる能力は単に、追加の専用優先バッファをサポートするだけでシステムに追加することができる（すなわち、「ベスト・エフォート型」よりも優れている）。この要件により、単一のバッファまたはキューがぶつかる前述のキューイング問題が解消され、優先順位の高いトラフィックに影響を与えることなく、優先順位のより低いパケット・キューイングが（それ自体の別々の異なるバッファ内で）行われるようになる。
【００３３】
好ましくは、優先順位規則は変わらないままであり、Ｔｘ状態とＲｘ状態の間の優先順位循環方式を維持しながら送信バッファとしての複数のキュー（例えば、事前に定義された例では３つのキュー）の間で固定した優先順位を提供するよう状態マシンに要求する。好ましくは、送信優先キューが、「ベスト・エフォート型」のキューなど、優先順位のより低いキューよりも高い絶対的な優先順位を得るか、または、普通のキューと「ベスト・エフォート型」のキューを同時にアクティブにすべきである。
【００３４】
図３は、本発明の好ましい実施形態による、３クラス・システムにおける送信キュー優先順位管理の例を示す流れ図である。
【００３５】
図３では、ある種のポリシー管理がなく、さらにすべてのトラフィック・クラス用のバッファが常に満杯であると想定すると、優先順位の低いデータが飢餓状態になる潜在的可能性が、優先順位のより高いキュー（例えば、ビデオ、ベスト・エフォート型、およびエクセレント・エフォート型のバッファ）の厳密な優先順位による処理によって生じる問題になることに留意されたい。
【００３６】
ビデオおよびベスト／エクセレント・エフォート型のバッファをある種の「加重ラウンド・ロビン」スケジューリングを用いて処理することは、データ飢餓状態が生じないようにするために利用できる１つの方法である。これは、例えばビデオ、ビデオ、普通、ビデオ、ビデオ、普通など、所与のシーケンスでキューをサービスすることによってかなり簡単に実施することができる。音声トラフィックはその性質上、やはり厳密な優先順位によってサービスすることができる。
【００３７】
本発明の他の実施形態では、前述の「加重ラウンド・ロビン」方式ほど厳密ではないが、「ベスト・エフォート型」の優先順位レベルのトラフィックが優先順位のより高いキューをサービスするエンジンによって「飢餓状態」にされないようにする手段が追加される。優先順位の最も低いキュー内のベスト・エフォート型のトラフィックの飢餓状態は、送信のためバッファに入っているデータ・メッセージの数が指定されたしきい値を超えたかどうかを識別することによってデータ速度を測定する、あるいは他の任意の手段など、当技術分野で周知の任意の適切な手段によって検出することができる。
【００３８】
これらの手段は、装置ファームウェアによって制御し、あるいはローカルの装置レジスタ内で（例えば、低優先順位エスカレーション（Ｌｏｗ  Ｐｒｉｏｒｉｔｙ  Ｅｓｃａｌａｔｉｏｎ）すなわち「Ｌｐｅｓｃ」と呼ばれる）事前に定義されたフラグまたはビットを使用するソフトウェアに基づくスケジューリング機構によって制御することが好ましい。Ｌｐｅｓｃビットは、保留中の（より）優先順位の高いデータ・パケットがその各データ・キュー／バッファ内で待っている場合でも、優先順位の低いデータ・バッファが飢餓状態にあり、次にまたは最初にそれをサービスすべきことを装置データ移動エンジンに示すために使用される。
【００３９】
次に図３を参照すると、ステップ４２０で、ＬＰｅｓｃビットがセットされているかどうか判定し、ＬＰｅｓｃビットがセットされている場合、方法はステップ４５０にジャンプする。ＬＰｅｓｃビットがセットされていない場合、方法はステップ４３０に進み、そこで優先順位の高い送信バッファをチェックする。ステップ４３０で、優先順位の高いデータが優先順位の高い送信バッファ内に存在することがわかった場合、ステップ４６０で、優先順位の高いデータを優先順位の高い送信バッファから読み取り、ステップ４１０でシステムはアイドル送信状態に戻る。ステップ４３０で、優先順位の高いデータが優先順位の高い送信バッファ内にないことがわかった場合、方法は進み、ステップ４４０で、中位の優先順位のデータが中位の優先順位の送信バッファ内にあるかどうかチェックし、中位の優先順位のデータがある場合はステップ４７０でそれを読み取り、システムはステップ４１０のアイドル送信状態に戻る。ステップ４４０で、中位の優先順位のデータが中位の優先順位の送信バッファ内で検出されない場合、方法は進み、ステップ４５０で優先順位の低い送信バッファをチェックし、優先順位の低いデータが優先順位の低い送信バッファ内にある場合はステップ４８０でそれを読み取り、システムはステップ４１０のアイドル送信状態に戻る。
【００４０】
本発明の他の実施形態によれば、ステップ４２０で、ＬＰｅｓｃビットがセットされているかどうか判定する。ＬＰｅｓｃビットがセットされている場合、方法は、加重ラウンド・ロビン・スケジューリング技術に切り替えて、優先順位の低い送信バッファをサービスする。ＬＰｅｓｃビットがセットされていない場合、図３に示すように、方法はステップ４３０に進む。ステップ４２０をさらに参照すると、ＬＰｅｓｃビットがセットされている場合、優先順位の最も低いキューがデータ飢餓状態にならないようにするために、加重ラウンド・ロビン・スケジューリング技術が使用される。優先順位の最も低いキューは、使用されているスケジューリング技術に従って送信の機会を与えられる。優先順位の最も低いキューは、次に利用可能な送信の機会に送信できないかもしれないが、最終的にはスケジューリング技術において提供される送信の機会が得られることになる。
【００４１】
本発明の興味深い特徴は、８０２．１１  ＭＡＣの変更を必ずしも必要とせず、したがって既存のシステム上に組み込めることである。明らかに、上述の優先順位規則および管理規則が遵守できることを考慮すると、複数のキューがＭＡＣ装置自体上で利用可能になる場合、様々なタイプの通信トラフィックを効率的にサポートする能力を実現することができる。
【００４２】
本発明は、新しい通信システムにおいて、そのシステム内で複数キュー管理のためのサポートを提供することによって、サービス品質問題を解決する方法を提供する。さらに、通信システムにおいて優先順位の低いクラスのデータ飢餓状態が問題になるときに、それを緩和するためのエスカレーション機構が提供される。
【００４３】
これらの複数キュー管理機構およびエスカレーション技術は既存のＷＬＡＮシステムによって利用することができる。キュー管理技術はハードウェアまたはソフトウェアで実装することができるが、複数キューおよびキュー管理、ならびにエスカレーション技術を所与の１つのハードウェア内で使用して、システムの全体的な効率を上げることができる。
【００４４】
本明細書に記述する解決策は、システムにおける複数キュー管理のためのサポートと、優先順位のより高いトラフィックの持続期間中に優先順位のより低いエンティティをエスカレートさせることができる能力を提供することによって、かなり簡単に既存のＷＬＡＮシステム内で実装することができる。この利点が重要であるのは、複数のトラフィック・クラスをサポートするための簡単なリアルタイムの方法を提供できることが、特にサービス品質（ＱｏＳ）に関する目的が大いに望まれる新しいアプリケーションではきわめて有益となるからである。さらに、こうした通信システムにおいて優先順位の低いクラスのデータ飢餓状態を緩和するためのエスカレーション機構があると、そうしたシステムの価値がさらに高まることになる。
【００４５】
本発明はさらに、現在のＩＥＥＥ８０２．１１  ＭＡＣおよび概念の実証済みの成功の上に構築され、既存の設計に組み込むことができる。さらに、本発明は、既存のトラフィック・モデルとうまく適合する適応型の堅固なＱｏＳ機能を追加する。基本的なワイヤレスＭＡＣの効率的なチャネルの充填は、空のサービス・レベルを「充填する」ことによって維持される。ＩＥＥＥ８０２．１１（ｅ）規格の今後のバージョンの予想される要件による複数のトラフィック・クラスに関するＱｏＳが、本発明の好ましい実施形態に従って実装することができる。
【００４６】
本発明をその例示的な実施形態を参照しながら説明してきたが、当業者は、本発明の正確な趣旨および範囲から逸脱することなく、本発明の上述の実施形態に様々な修正を行えるであろう。
【図面の簡単な説明】
【００４７】
【図１】本発明の好ましい実施形態による、ハードウェアに基づく優先順位管理方法を示す構成図である。
【図２】本発明の好ましい実施形態による、送信方向と受信方向の間での全体的な優先順位管理の例を示す流れ図である。
【図３】本発明の好ましい実施形態による送信キュー優先順位管理の例を示す流れ図である。
【図４】優先順位に基づかない従来の管理方法を示す構成図である。
【図１】
0004719001.tif 000002
【図２】
0004719001.tif 000003
【図３】
0004719001.tif 000004
【図４】
0004719001.tif 000005