JP2010119111A - 無線ネットワークに関するサービス品質スケジューラ - Google Patents

Abstract

【課題】無線ネットワークにおけるサービス品質（ＱｏＳ）スケジューリングを提供する。
【解決手段】複数の遠隔デバイスとともに動作可能であり、更に、複数の時間と該複数の時間の各々におけるゼロ以上の遠隔デバイスのための容量予約を具備する受付プロフィールとともに動作可能な、通信デバイスは、該複数の時間の各々の時間中において、複数のデータ伝送指標の各々に関して、該データ伝送指標に対応する遠隔デバイスが該受付プロフィール内において容量予約を有するかどうかを決定するためと、該データ伝送指標に従って容量を割り当てるための、スケジューラを具備する。
【選択図】図１

Description

本発明は、一般的には、通信に関するものである。本発明は、より具体的には、無線ネットワークのためのサービス品質スケジューリングに関するものである。

無線通信システムは、音声及びデータ等の様々な型の通信を提供することを目的として広範囲にわたって構成されている。典型的無線データシステム(又は、ネットワーク)は、１つ以上の共有資源へのアクセスを多数のユーザーに提供する。システムは、周波数分割多重（ＦＤＭ）、時分割多重（ＴＤＭ）、符号分割多重（ＣＤＭ）、等の様々な多重接続方式を使用することができる。

無線ネットワーク例は、セルラー方式のデータシステムを含む。いくつかのこれらの例は次のとおりである。即ち、（１）デュアルモード広帯域拡散スペクトルセルラーシステムに関するＴＩＡ／ＥＩＡ−９５−Ｂ移動局−基地局適合性規格（ＩＳ−９５規格）、（２）「第三世代パートナーシッププロジェクト」（３ＧＰＰ）と呼ばれるコンソーシアムによって提供され、文書番号３Ｇ ＴＳ ２５．２１１，３Ｇ ＴＳ ２５．２１２， ３Ｇ ＴＳ ２５．２１３，及び３Ｇ ＴＳ ２５．２１４を含む一組の文書において具体化されている規格（Ｗ−ＣＤＭＡ規格）、（３）「第三世代パートナーシッププロジェクト２」（３ＧＰＰ２）と呼ばれるコンソーシアムによって提供され、「ｃｄｍａ２０００拡散スペクトルシステムに関するＴＲ−４５．５物理レイヤ規格」において具体化されている規格（ＩＳ−２０００規格）、及び（４）ＴＩＡ／ＥＩＡ／ＩＳ−８５６規格（ＩＳ−８５６規格）に準拠する高データ速度（ＨＤＲ）システム。

その他の無線システム例は、ＩＥＥＥ ８０２．１１規格（即ち、８０２．１１（ａ）、（ｂ）、又は（ｇ））等の無線ローカルエリアネットワーク（ＷＬＡＮ）を含む。これらのネットワークの改良は、直交周波数分割多重（ＯＦＤＭ）変調方式を具備する多重入力多重出力（ＭＩＭＯ）ＷＬＡＮを構成する際に達成させることができる。

無線システム設計の進歩に伴い、より速いデータ速度が利用可能になってきている。データ速度の高速化は、高度なアプリケーション（特に、音声、映像、高速データ転送、及びその他の様々なアプリケーション）を可能にしている。しかしながら、様々なアプリケーションごとに各々のデータ転送に関する要求事項が異なる。多くの型のデータは、レーテンシー及びスループットに関する要求を有しているか、又はある程度のサービス品質（ＱｏＳ）保証を必要とする。現在のシステムは、ベストエフォート（ｂｅｓｔ ｅｆｆｏｒｔ）に基く要求スケジューリングを提供するが、実際上は、共有資源へのアドホック（ａｄ ｈｏｃ）アクセスが規範になっている（即ち、搬送波感知多重アクセス（ＣＳＭＡ）。このため、システム管理を行わないとシステム容量が低下することがあり、さらにはシステムが効率的に動作しないことがある。更に、すべてのトラフィックがまったく同じに処理される場合は（アドホックアクセス又はベストエフォートを含む）、幾つかのアプリケーションが制限されるか又はまったく機能しない可能性がある（即ち、バースト性の、レーテンシーが相対的に低い映像ストリーム）。

従って、無線ネットワークにおけるＱｏＳスケジューリングを行う必要がある。

本発明の一側面においては、複数の遠隔デバイスとともに動作可能であり、更に、複数の時間と該時間の各々におけるゼロ以上の遠隔デバイスのための容量予約とを具備する受付プロフィールとともに動作可能な、通信デバイスは、該複数の時間の各々の時間中において、複数のデータ伝送指標の各々に関して、該データ伝送指標に対応する遠隔デバイスが該受付プロフィール内において容量予約を有するかどうかを決定するためと該データ伝送指標に従って容量を割り当てるためのスケジューラを具備する。もう１つの側面においては、データ指標は、１つ以上のサービスレベルに対応する。さらにもう１つの側面においては、割当ては、別のサービスレベルの前に１つのサービスレベルに関して行われる。残りの容量は、データ伝送要求のサイズが小さい順に割り当てられる。さらにもう１つの側面においては、利用可能なシステム容量に従って（流れ（flow）パラメータによって特性が示される）新たな流れを受け入れるために受付プロフィールが更新される。更に、その他の様々な側面も示されている。

通信システムの実施形態例を示した図である。 通信デバイス（即ち、アクセスポイント又はユーザー端末）の実施形態例を示した図である。 複数のユーザー端末／アプリケーションに関する３つのクラスのデータに関するスケジューリングを示した図である。 受付制御例を示した図である。 受付制御装置例の流れ図である。 スケジューラ方法の一般化された実施形態の流れ図である。 ＱｏＳスケジューリング後に残りの容量を割り当てるための代替方法を示した図である。 データクラスに関する何らかの情報が既知であるときにＱｏＳスケジューリング後に残りの容量を割り当てるための代替方法を示した図である。

本明細書において用いられている「典型的な」という表現は、「1つの例、事例、又は実例」を示すことを目的とするものである。このため、本明細書において「典型的な」実施形態として説明されているいずれの実施形態も、その他の実施形態よりも好ましい又は有利であるとは必ずしも解釈すべきではない。

図１は、通信システム例１００を示した図である。システム１００は、アクセスポイント（ＡＰ）１１０とユーザー端末（ＵＴ）１３０Ａ乃至１３０Ｎと、を具備する無線ローカルエリアネットワーク（ＷＬＡＮ）１９０を含む。アクセスポイント１２０は、特に、スケジューラ１２０と、受付制御装置１２５と、を含む（その他の構成要素は図示されていない）。受付制御装置１２５は、受付の制御を行い、スケジューラ１２０は、データトラフィックのスケジューリングを行う。以下では、様々な実施形態が説明されている。アクセスポイント１２０は、外部ネットワーク（即ち、インターネット、企業イントラネット、等）、又はその他のデータ接続に接続される。該実施形態例においては、ネットワーク１４０は、インターネットプロトコル（ＩＰ）に準拠しており、従ってネットワーク上のトラフィック通信は、ＩＰパケットを具備する。本明細書において開示されている原理は、開示されている範囲に限定されるものではなく、あらゆるデータネットワークとともに展開できることを当業者は認識することになる。一例として、外部ネットワーク１４０に接続された状態のアプリケーション１５０が示されている。一般的には、アプリケーション１５０は、サーバー上、又は１つ以上のユーザー端末１３０とのデータ接続の確立を時々試みることができるその他のデバイス（別のユーザー端末を含む）上に常駐する。該接続は、本明細書においてはデータ流又はより単純に流れ(flowフロー)と呼ばれており、ＡＰ１１０を通じて確立され、該流れは、エアインタフェース１８０を通じて、各々のＵＴと、その内部に埋め込まれたアプリケーションに転送される。同様に、ユーザー端末上で動作しているアプリケーション（即ち、ＵＴ１３０Ａ上のアプリケーション１６０Ａ乃至１６０Ｎ）は、別のユーザー端末内のデバイス及び／又はアプリケーション又はネットワーク１４０に接続されたデバイス及び／又はアプリケーションとの接続を確立させることを試みる。この場合も、該接続は、ＡＰ１１０を通じて確立される。

アクセスポイント１１０内におけるスケジューラ１２０及び受付制御装置１２５の所在場所は、例として示されているにすぎない。代替実施形態においては、これらのスケジューラ１２０及び受付制御装置１２５は、同じ場所に共在する必要がない。一代替実施形態においては、１つ以上のＵＴは、１つのスケジューラ及び／又は受付制御装置を含む。１つ以上のＵＴは、シグナリングを通じて、指定されたＵＴがスケジューリング及び／又は受付制御を行うようにすることができる。この場合は、指定されたＵＴが事実上のアクセスポイントである。指定されたＵＴは、経時で交替することができる。１つ以上のＵＴは、外部ネットワーク１４０への接続を有することができる。代替として、ＷＬＡＮ１９０から外部ネットワークへの接続が存在しないことがある。更に、管理されたピア・ツー・ピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）接続も企図されている。例えば、アクセスポイント（又は指定されたＵＴ）は、その他の２つのユーザー端末間における受付制御及び／又はスケジューリングを管理する。この方式では、データ伝送が直接ピア間で発生し、制御シグナリング（要求及び許可、等）のみが、管理を担当するアクセスポイント（又は指定ＵＴ）に伝送されるか又は該アクセスポイントから受け取られる。本明細書において示されている教義に鑑みて、これらのオプション及びその他を含む数多くのコンフィギュレーションが当業者によって容易に適合化されることになる。本明細書においては、星形に接続されたアクセスポイント及び１つ以上のユーザー端末を具備する実施形態例がしばしば使用されている。該実施形態例は、本発明の様々な側面について説明する上で便利な例であるが、本発明は、該実施形態例に限定されるものではない。

ＷＬＡＮ１９０は、様々な型のトラフィック（例えば、音声、オンデマンド映像、マルチキャストビデオ、ゲーム用アプリケーション、標準ＴＣＰ／ＩＰブラウジング、等のリアルタイムサービスを含む）を処理することができる。データアプリケーションの流れの特性は、各々異なる。例えば、様々な流れは、レーテンシー及び／又は誤差許容範囲に関する要求事項がそれぞれ異なる。音声データは、一般的には、聞く人が感知可能な遅延を回避するために低レーテンシーを要求するとみなされている。しかしながら、当業においては、音声データが「損失のある状態で」伝送されるのを許容する（即ち、音声の品質が一貫した低レベルのフレーム誤差率によって大きな影響を受けない）様々な音声符号化方式が知られている。他方、例えばファイルのダウンロードは、レーテンシーの影響を音声と同じようには受けない。しかしながら、ファイルが誤りなしで受け取られるようにすることが必須である。一連の予想されるアプリケーションに対して受入可能な性能を提供するため、スケジューラ１２０は、サービス品質（ＱｏＳ）管理を提供する。

一実施形態例においては、トラフィックは、ＱｏＳに敏感なトラフィック及びベストエフォートトラヒック（Ｂｅｓｔ Ｅｆｆｏｒｔ Ｔｒａｆｆｉｃ）（ＢＥＴ）の2つのグループに分類される。遅延及び／又は帯域幅が厳格に制限されるトラフィックは、ＱｏＳ敏感トラフィックグループに分類される。その他のトラフィックは、ベストエフォートトラヒックグループに分類される。スケジューラ１２０は、以下においてさらに詳細に説明されている帯域幅確保方式を用いて、ＱｏＳ敏感トラフィックを管理する。受付制御装置１２５は、提案された流れの特性及び利用可能な資源量に基づいて該流れを受け入れるか又は拒否する受付制御を採用している。ベストエフォートトラフィックは、単純なラウンドロビン待ち行列方式を用いて管理される。以下では、これらの実施形態及び代替実施形態がさらに詳細に説明される。

該実施形態例においては、エアインタフェース１８０は、直交周波数分割多重（ＯＦＤＭ）を用いた多重入力多重出力（ＭＩＭＯ）ＷＬＡＮである。代替として、ＦＤＭ、ＣＤＭ、ＴＤＭを含むその他の様々なエアインタフェース方式を使用することができる。更に、多数のユーザーが１つ以上の共通インタフェースにアクセスすることを許容するために、空間ダイバーシティ等のその他の技術を使用することができる。エアインタフェースに関する様々な規格及び設計は、共有通信資源における送受信に関する１つ以上のチャネル型を定義している。一般的には、１つ以上の制御チャネル及び１つ以上のデータチャネルが規定されている。又、２カ所以上の行先に同時にシグナリングするための放送チャネルが定義されることがしばしばある（例えば、順方向リンクにおけるメッセージ）。更に、デバイス（例えば、逆方向リンクにおいて通信を開始するＵＴ）がネットワークへのアクセスを得るためのランダムアクセスチャネルが構成されることがしばしばある。データ及び／又は制御チャネルのあらゆるコンフィギュレーションを本発明の適用範囲内において構成することができる。いずれのチャネルであるか又はいずれのチャネル型であるかにかかわらず、ユーザー（即ち、ネットワーク１４０を通じて接続されたアプリケーション１５０、またはユーザー端末１３０）は、共有資源へのアクセス要求を行う。スケジューラは、後述されている技術のうちの１つ以上を用いて該共有資源を割り当てる。これで、１つ以上のユーザーは、該共有資源へのアクセスが許可される。当業者は、本明細書において開示されている原理を様々な通信システムに合わせて容易に適合化するであろう。

図２は、通信デバイス例（例えば、ユーザー端末１３０又はアクセスポイント１１０）のブロック図である。この実施形態例において描かれているブロックは、一般的には、ユーザー端末１３０又はアクセスポイント１１０のいずれかに含まれている構成要素の部分組になる。当業者は、図２に示されている実施形態を、あらゆる数のアクセスポイントコンフィギュレーション又はユーザー端末コンフィギュレーションにおいて使用できるように容易に適合化するであろう。順方向リンク及び逆方向リンクという表現は、説明のみを目的として用いられていることに注意すること。アクセスポイント１１０が基地局と同様に機能し、ユーザー端末が典型的星形形状において相互に対話する場合は、順方向リンク及び逆方向リンクという表現が適している。しかしながら、上述されているように、本発明の適用範囲は、アドホックネットワーク（幾つかのユーザー端末１３０のうちのいずれの１つも事実上のアクセスポイント１１０としてセットアップされる）、管理されたピア・ツー・ピア接続、等を含む。これらの表現の使用は、本発明の適用範囲を制限するものではなく、これらの表現が使用されている文脈に適した慣例として用いられていることを当業者は認識するであろう。

信号は、アンテナ２１０において受け取られて受信機２２０に送られる。アンテナ２１０は、１本以上のアンテナを具備することができる。受信機２２０は、ＷＬＡＮ１９０システムに従って処理を行い、ＷＬＡＮ１９０システムは、１つ以上の無線システム規格（例えば、上記規格）に一致させることができる。受信機２２０は、様々な処理（無線周波数（ＲＦ）−ベースバンド変換、増幅、アナログ−デジタル変換、フィルタリング、等）を行う。当業においては、様々な受信技術が知られている。受信機２２０は、順方向リンク又は逆方向リンクのチャネル品質を測定するために使用することができるが、説明を明確化するために別個のチャネル品質推定器２３５が示されている。チャネル品質推定器２３５は、チャネルの品質を決定するため、従ってサポート可能なデータ速度を推定するために、使用することができる。伝送しなければならないデータ量（又は、要求されるデータ伝送継続時間）、及びサポート可能なデータ速度を通信デバイスが既知であれば、通信デバイスは、必要な資源量を決定して適宜要求を行うことができる。本実施形態例においては、通信デバイスは、伝送する必要があるＯＦＤＭ記号数を決定する。当業者は、既知の量のデータを可変チャネルを通じて伝送するために必要な共有資源量を決定するために構成可能な代替実施形態が数多く存在することを認識することになる。一代替として、伝送要求は、データ量とチャネル品質指標を含むことができる。スケジューラは、許可すべきＯＦＤＭ記号量の決定をこれらの要因に基づいて行うことができる。

受信機２２０からの信号は、復調器２２５内において１つ以上の通信設計又は通信規格に従って復調される。一実施形態例においては、ＭＩＭＯ ＯＦＤＭ信号を復調することができる復調器が構成される。代替実施形態においては、代替規格をサポートすることができ、いくつかの実施形態は、複数の通信フォーマットをサポートすることができる。復調器２３０は、ＲＡＫＥ受信、等化、結合、デインターリービング、復号、及び、受信信号のフォーマットによって要求されるその他の様々な機能を果たすことができる。当業においては、様々な復調技術が知られている。アクセスポイント１１０においては、復調器２２５は、逆方向リンクに従って復調する。ユーザー端末においては、復調器２２５は、順方向リンクに従って復調する。本明細書において説明されているデータチャネル及び制御チャネルの両チャネルは、受信機２２０において受信されて、復調器２２５において復調されるチャネル例である。順方向データチャネルの復調は、上述されているように、制御チャネルにおけるシグナリングに従って行われる。

メッセージ復号器２３０は、復調されたデータを受け取り、順方向リンク又は逆方向リンクでユーザー端末１３０又はアクセスポイント１１０に向けられた信号又はメッセージを抽出する。メッセージ復号器２３０は、システムにおけるデータセッションのセットアップ、維持及び削除において用いられた様々なメッセージを復号する。メッセージは、伝送要求、伝送許可、又はあらゆる数の制御チャネルメッセージを含む。当業においてはその他の様々なメッセージの型が既知であり、サポートされている様々な通信規格又は設計において指定することができる。これらのメッセージは、後続して処理する際に使用するためにプロセッサ２５０に引き渡される。メッセージ復号器２３０の機能の一部又は全部は、プロセッサ２５０において実施することができるが、説明を明確化するために１つの個別のブロックが示されている。代替として、復調器２２５は、一定の情報を復号して直接プロセッサ２５０に送ることができる（例えば、ＡＣＫ／ＮＡＫ等の単一ビットメッセージ又は電力制御アップ／ダウンコマンド、等）。

チャネル品質推定器２３５は、受信機２２０に接続されており、本明細書において説明されている手順において使用すること及び通信の際に用いられるその他の様々な処理（復調、等）において使用すること目的とした様々な電力レベルの推定を行うために使用される。チャネル品質推定器２３５は、説明を明確化することのみを目的として個別のブロックとして示されている。当該ブロックは、別のブロック（受信機２２０または復調器２２５、等）の中に組み入れられるのが一般的である。いずれの信号又はいずれのシステム型が推定対象であるかに依存して、様々な型の信号強度推定を行うことができる。特に、ＭＩＭＯチャネル（Ｍ本の送信アンテナ及びＮ本の受信アンテナ）の場合は、チャネル推定は、ＭｘＮマトリクスになる。一般的には、本発明の適用範囲内において、あらゆる型のチャネル品質評価基準推定ブロックをチャネル品質推定器２３５の代わりに構成することができる。

信号は、アンテナ２１０を通じて送信され、アンテナ２１０は、複数のアンテナを含む。送信信号は、送信機２７０内において、１つ以上の無線システム規格又は設計（例えば上述の規格又は設計）に従ってフォーマット化される。送信機２７０内に含めることができる構成要素例は、増幅器、フィルタ、デジタル−アナログ（Ｄ／Ａ）変換器、無線周波数（ＲＦ）変換器、等である。伝送用データは、変調器２６５によって送信機２７０に提供される。データチャネル及び制御チャネルは、様々なフォーマットに従って伝送用にフォーマット化することができる。順方向データチャネルで伝送するデータは、変調器２６５において、Ｃ／Ｉ又はその他のチャネル品質測定値に従ってスケジューリングアルゴリズムによって示された伝送速度及び変調フォーマットに従ってフォーマット化される。変調器２６５内に組み入れることができる構成要素例は、符号化器、インターリーバー、スプレッダ、及び各種変調器を含む。

メッセージ生成器２６０は、本明細書において説明されているように、様々な型のメッセージを生成するために使用することができる。例えば、伝送を目的するエアインタフェースへのアクセスを要求するための要求メッセージが生成される。更に、要求メッセージに対応する許可メッセージが生成され、これらの許可メッセージは、例えば要求を行っているユーザー端末が利用可能な共有資源の割当てを含む。更に、アクセスポイント１１０又はユーザー端末１３０のいずれかにおいて様々な型の制御メッセージが生成される。

復調器２２５において受け取られて復調されたデータは、データ通信の際に使用するためにプロセッサ２５０に引き渡すこと、及びその他の様々な構成要素に引き渡すことができる。同様に、伝送用データは、プロセッサ２５０から変調器２６５又は送信機２７０に向かわせることができる。例えば、プロセッサ２５０内、又は、通信デバイス１１０又は１３０（図示されていない）に含まれている別のプロセッサ内には、様々なデータアプリケーションが存在することができる。アクセスポイント１１０は、ネットワークインタフェース２８０を通じて、１つ以上の外部ネットワーク（インターネット、ネットワーク１４０、等）に接続することができる。ユーザー端末１３０又はアクセスポイント１１０は、ラップトップ型コンピュータ（図示されていない）、等の外部デバイスへのリンクを含むことができる。

上述されているスケジューラ（例えば、スケジューラ１２０、等）は、プロセッサ２５０内に常駐することができる。受付制御装置１２５は、プロセッサ２５０内に常駐することができる。以下では、これらの様々な実施形態がさらに詳細に説明されている。

プロセッサ２５０は、汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、又は専用プロセッサであることができる。プロセッサ２５０は、受信機２２０、復調器２２５、メッセージ復号器２３０、チャネル品質推定器２３５、メッセージ生成器２６０、変調器２６５、送信機２７０、又はネットワークインタフェース２８０の機能の一部又は全部、及び通信デバイスによって要求されるその他のすべての処理を実施することができる。プロセッサ２５０は、これらのタスクを援助するために（図示されていない）専用ハードウェアと接続することができる。データアプリケーション又は音声アプリケーションは、外部（例えば、外部接続されたラップトップコンピュータ又はネットワークへの接続、等）にすること、通信デバイス１１０又は１３０（図示されていない）内の追加プロセッサ上において動作すること、又はプロセッサ２５０自体において動作することができる。プロセッサ２５０は、メモリ２５５と接続され、メモリ２５５は、データと、本明細書において説明されている様々な手順及び方法を実施するための命令と、を保存するために使用される。メモリ２５５は、様々な型の１つ以上のメモリ構成要素を具備でき、これらの構成要素は、全部又は一部をプロセッサ２５０内に埋め込むことができることを、当業者は認識することになる。メモリ２５０は、本明細書において説明されているように、１つ以上の待ち行列を構成するために使用することができる。メモリ２５５は、以下においてさらに詳細に説明されているように、１つ以上の受付プロフィールを保存するために適している。

本実施形態例においては、１つのＵＴ当たりの多数の流れに加えて多数のＵＴ流をサポートすることができる単一のメディアアクセス制御（ＭＡＣ）フレームが構成される。更に、複数のＭＡＣフレームを具備するスーパーフレームが定義される。この例においては、１つのスーパーフレーム内のＭＡＣフレーム数は１６である。

本実施形態例においては、現行のＭＡＣフレームの順方向リンクセグメント及び逆方向リンクセグメントの両セグメントにおけるすべてのアクティブな流れに関するスケジューリング情報を含む各ＭＡＣフレームの開始時に制御チャネル（ＣＣＨ）が伝送される。順方向リンクスケジューリングは、ＵＴからのリンクデータ速度情報フィードバックを用いることによって容易化される。逆方向リンクスケジューリングは、ＵＴによって提供された待ち行列状態情報及び暗黙リンク伝送速度情報を用いることによって容易化される（例えば、要求された容量は、データ要求量及びリンク品質の両方と相互に関連づけられる）。ドーマント状態のＵＴは、ランダムアクセスチャネル（ＲＣＨ）を用いてシステム資源を要求することができる。更に、アクセスポイントは、１つのオプションとして、ユーザー端末をポーリングすることもできる。管理されているピア・ツー・ピア接続の場合は、すべての伝送がピアＵＴ間における伝送であり、更に、スケジューラの観点では、逆方向リンクスケジューリングの一部として処理される点に注目すること。

一般的には、リンク状態情報がアクセスポイントにおいて受け取られる時と、その結果生じたスケジューリング情報がＣＣＨにおいてＵＴに伝送される時と、の間の遅延を最小にすることが望ましい。過度の遅延は、結果的に生じた伝送が行われる前に無線周波（ＲＦ）チャネルが変化した場合は、所定のＭＡＣフレーム内で割り当てられた伝送速度が古すぎる伝送速度になってしまう可能性がある。本実施形態例においては、遅延を１つのＭＡＣフレーム（約２ｍｓ）にすることが１つの目標となっている。

本実施形態例においては、複数のＵＴに関する順方向リンクデータが、アクセスポイントの待ち行列内に格納される。これらの待ち行列は、データクラス型によって識別される場合とされない場合がある。代替として、各々の待ち行列は、ネットワーク１４０を通じて接続されたアプリケーション内において維持することができる。この例においては、各々のユーザー端末における待ち行列内に逆方向リンクデータが格納される。逆方向リンク及び順方向リンクという表現の使用は、ピア・ツー・ピア接続（データがピア間で流れ、アクセスポイント又は管理担当ＵＴへはデータが流れず、更に、アクセスポイント又は管理担当ＵＴからはデータが流れない接続）の使用、及び、本明細書において開示されているその他のあらゆる代替実施形態の使用、を排除するものではないことに注意すること。共有通信資源へのアクセス要求は、該要求の対象となるデータの型を特定することができ、又は、多数のクラスに対応する単なる単一の要求であることができる。本実施形態例においては、幾つかのＯＦＤＭ記号に関する要求が行われる。代替実施形態においては、共有資源のあらゆる部分（即ち、タイムスロット、チャネル、電力、等）に関する要求を行うことができる。要求は、要求者が、絶えず変化するチャネル状態に起因してデータ量及びサポート可能なビットレートに基づいて要求規模を調整済みであることを反映させることができる。この型の要求の１つの利点は、スケジューラが、管理されたピア・ツー・ピア状況においてピア間におけるチャネル測定値にアクセスする必要がないこと、及び、（順方向リンク及び逆方向リンクが必ずしも対称的でない状況において）逆方向リンクチャネルの品質を明示で決定する必要がないことである。代替として、要求は、希望される資源量を指定することができないが、データ量及び何らかのチャネル品質指標を指定することができる。いずれの型の要求であっても、又は要求の型のいずれの組合わせであっても、スケジューラによって対応することができる。

説明を明確化するため、様々なユーザー端末は固定端末であると想定することができる。但し、本発明の適用範囲は、該想定事項に限定されるものではない。更に、説明を明確化するため、移動ＵＴによる複数のアクセスポイント間でのハンドオフについては説明されない。移動式であるかどうかにかかわらず、ＵＴとＡＰとの間における無線チャネルは、様々な干渉原因に起因して時間とともに変化する。従って、いずれのＵＴの場合も、ＵＴに関する順方向リンク及び／又は逆方向リンクの容量は変動する。

上述されているように、ＵＴ流は、ベストエフォート及びＱｏＳ敏感の２種類に分類される。ベストエフォートサービスは、レーテンシーに敏感でない流れに関して提供される。ＱｏＳ敏感流に関しては、受付制御と結合された帯域幅予約が使用される。更に、独立したレーテンシー制御がスケジューラ１２０によって容易化される。ＱｏＳ敏感流は、１つのＭＡＣフレームに基づいて、又は、スーパーフレーム（即ち、１６のＭＡＣフレーム）において分散する形で、資源の公称の一定部分が割り当てられる。該公称割当ては、平均速度、最高速度、バースト性、最長レーテンシー、等を含む一組のパラメータによって統計的に表されるソースのトラフィックプロフィールの関数である。受付制御装置１２５は、これらのパラメータ及びその他のパラメータを用いて、流れのＱｏＳ上の要求を満たすために必要な公称速度とスケジュールを決定する。

以下においてさらに詳述されるように、スケジューリングタスクは、ソースの瞬間的データ速度及びチャネルによってサポートされたビットレートの両方が変化可能であるため複雑化している。多くのデータアプリケーションは、バースト性のトラフィックプロフィールを有する。例えば、ＭＰＥＧ（動画エキスパートグループ−国際標準化機構／国際電気技術委員会）符号化映像は、１０：１に近いピーク・平均比を示すことが可能である。無線チャネルの信号・雑音比（ＳＮＲ）は、（ＵＴが移動式又は固定式のいずれであるかにかかわらず）シャドーイング及び干渉に起因して大幅に変化することがあり、従って、リンクのサポート可能なデータ速度も大幅に変動する。

統計的多重化と結合させた適切な受付方針を用いることによって、QoS保証を満たすこと及び優れたシステム効率を達成させることができる。ある１つの流れが公称割当てによる資源を要求時には、追加資源が利用可能であることを条件としてこれらの追加資源を割り当てることができる。大量の流れがサポートされているときには、統計的多重化利得が大きくなり、その結果優れたシステム効率が達成される。

受付制御及びスケジューリングに関する様々な実施形態が以下において詳述されている。１つの実施形態例の要約は次のとおりである。即ち、ＭＡＣフレーム内の未使用資源がその他の流れに提供される。瞬間的な要求が公称割当てを超えるＱｏＳ敏感流が最初に対応される。未使用資源は、ＱｏＳ要求を満たしている流れ数を最大にする形で配分される。ＱｏＳ敏感流に対応後に残りの資源が存在する場合は、ベストエフォート流が次に対応される。未使用資源は、ラウンドロビン方式でベストエフォート流の間で配分することができる。オプションとして、公平性に関する方針を適用することができる。

図３は、複数のユーザー端末／アプリケーションに関する３つのクラスのデータについてのスケジューリングを示した図である。一実施形態例においては、トラフィックは、スケジューラによって３つのグループに分類される。各グループ内での優先順位設定は、異なった方法で処理される。この例においては、各ＵＴは、各トラフィッククラスに関する別個の待ち行列を管理する。ＵＴは、各トラフィッククラス内に複数の流れを有することができる。本実施形態例においては、待ち行列は、バイト指向バッファとして管理される。待ち行列内のバイトは、スケジューラによって先入れ先出し（ＦＩＦＯ）方式で対応される。代替実施形態においては、あらゆる型の待ち行列及びアクセス順を展開させることができる。

第１のクラスのトラフィックである無線リンク制御（ＲＬＣ）トラフィックは、ＵＴの無線リンク接続の管理と関連づけられており、一般的には時間の影響をかなり受けやすい。従って、この例においては、ＲＬＣトラフィックの優先度が全トラフィッククラスの中で最も高い。スケジューラは、最初に、待機状態のＲＬＣトラフィックを有するＵＴに資源を割り当てる。ＲＬＣトラフィックは、一般的には、全資源の小さい部分を構成する。従って、説明を明確化するため、以下の実施形態は、注記がないかぎり、次の２つのトラフィッククラスに関して説明されている。当業者は、第３のトラフィッククラス（ＲＬＣ、等）に対応するために、本明細書において説明されているあらゆる実施形態を容易に適合化することになる。

第２のクラスのトラフィックであるサービス品質（ＱｏＳ）敏感流は、最長レーテンシー及び／又はバースト性データ搬送容量、等のニーズを満たすために、より厳しい引き渡しパラメータを要求する。ＱｏＳ敏感流には、受付制御装置を通じて全資源のうちの公称部分を割り当てることができる。ＱｏＳトラフィックは、第３のクラスのトラフィックであるベストエフォートトラフィック（ＢＥＴ）よりも優先度が高い。公称割当てよりも実質的に多くの資源を要求する流れは、劣化したサービスを受ける可能性がより高い。ＱｏＳトラフィックは、システムの管理方法に依存して、全資源のうちの実質的な部分を構成する。

第３のクラスのトラフィックであるＢＥＴは、優先度が最も低い。以下では、様々なＢＥＴ処理技術について説明されている。

図３において、複数の待ち行列３１０Ａ乃至３１０Ｎが、複数のユーザー端末ＵＴ Ａ乃至ＵＴ Ｎに関して維持されている。これらの待ち行列は、順方向リンク伝送のために、アクセスポイント１００において維持できることに注目すること。この場合には、アクセスポイントは、どの待ち行列がどのクラスのデータを含むかを正確に知ることになる。類似の待ち行列は、ユーザー端末１３０Ａ乃至１３０Ｎの各々において維持することができる。ユーザー端末は、どのクラス（複数のクラスを含む）のデータが伝送要求内に含まれているかを、該伝送要求内においてアクセスポイントに示す場合と示さない場合がある。以下では、両方の状況及び両方の状況の組み合わせを含む様々な実施形態例が詳述されている。一般的には、当業者は、本明細書の教義に鑑みて、順方向リンク又は逆方向リンクのいずれか、又は両リンクをスケジューリングするためのスケジューラを構成させることができる。

ＲＬＣスケジューリング機能３２０は、各ＲＬＣ待ち行列の各々からの待ち行列状態のＲＬＣデータをスケジューリングする。ＱｏＳスケジューリング機能３３０は、各々のＱｏＳ待ち行列をスケジューリングする。同様に、ＢＥＴスケジューリング機能３４０は、優先度が最も低いＢＥＴ待ち行列をスケジューリングする。これらのスケジューリングの結果としてのＵＴ Ａ乃至ＵＴ Ｎに関する伝送が図の最下部に示されている。例示上の例外として、ＱｏＳ待ち行列３１０Ｂの一部分は、ＱｏＳ部分とは対照的に、該ＵＴに関するＢＥＴ部分においてスケジューリングされる点に注意すること。このことは、公称のＱｏＳ割当てを超える１つの要求例を示したものである。この場合には、該ＢＥＴ割当ては、残りのＱｏＳトラフィック上のニーズを満たす上で十分なものであり、ＱｏＳ低下は発生しない。図３は、スケジューリング及びデータクラスの一例であるにすぎない。以下では、様々な実施形態がさらに詳細に説明されている。

次に、受付制御及びパケットスケジューリングの２つの基本的側面について詳述する。一システム例は、ＱｏＳ敏感トラフィックに関するサービスの受け入れ又は拒否を制御するために受付制御装置を採用する。スケジューラは、受け付けられた流れを追跡すること、及び交渉されたサービス速度の維持を試みることができる。

受付制御
希望される場合は、最大数のスロット（即ち、ＯＦＤＭ記号）Ｆ_ＲをＱｏＳ敏感トラフィックに関して予約することができる。（Ｆ_Ｒは、利用可能な総スロット数に設定することもできる。）残りのスロットＦ_Ｂ（存在する場合）は、ベストエフォートトラフィック用に予約される。利用可能な総資源（上述されているように、ＲＬＣ及び類似の制御クラストラフィックは含まない）はＦ_Ａによって与えられる。

Ｆ_Ｒは、指定されたＱｏＳを要求している流れに資源を確約すべきかどうかを決定するために受付制御装置が使用する。受付制御装置は、流れを受け付けるどうかを決定するための様々な１つの流れごとの変数を採用することができる。幾つかの例が以下に示されているが、当業者にとってはその他の例も明確である。

ソースの特性を示す様々な変数を指定することができる。例えば、帯域幅予約要求a_r（i）を流れiに関して指定することができ、この要求は、単位がビット／秒の伝送速度要求であり、該流れと関連づけられたＱｏＳパラメータに基づいて計算される。ソース、即ち、平均持続可能速度、ピーク速度、及びバースト性について説明時には、リーキーバケットモデル(ｌｅａｋｙ ｂｕｃｋｅｔ ｍｏｄｅｌ)を想定することができる。更に、流れの効率的なスケジューリング方法を導き出すために、ソースの最長レーテンシーｄ_max（i）を指定することもできる。

更に、リンクの特性を示す様々な変数を指定することもできる。例えば、リンク上において観察される平均達成可能伝送速度

を（別個の変数が順方向リンク及び逆方向リンクに関して維持された状態で）識別することができる。r(i) ^＊は、各端末に関する物理レイヤと関連する達成可能速度の平均値であり、登録／校正中に決定することができる。この値は、リンク状態（フェージング、パス損、干渉、等）に基づいて時間とともに変動する可能性がある。

この例においては、ＱｏＳシステム内の流れは、これらのパラメータに基づいた公称スロット割当てが受付制御装置によって割り当てられる。該公称割当ては、所定の時間間隔において一定数のスロットが割り当てられることを保証するものである。これらのパラメータに依存して、公称割当ての結果、１つのＭＡＣフレーム当たり一定数のスロットが割り当てられるか、又は、１つのスーパーフレーム（即ち、１６のＭＡＣフレーム）当たり一定数のスロットが割り当てられることになる。

ソース伝送速度が交渉速度を上回るか又はリンクデータ速度が交渉速度を下回る場合は、流れは、要求を満たすために追加のスロットを要求する。これらの場合には、統計的多重化が、１つの流れ当たりの不足分を補うための適切な流れマージンを提供する。統計的多重化の効率は、資源を共有するユーザー数に比例する。一般的には、ユーザーが多いほど効率が高くなる。

この例においては、流れiに対して割り当てられる公称割当ては次式によって与えられる。

φ_maxは、単一の流れに関して許容される最大割当てに関する上限であることに注意すること。当業者は、幾つかの実施形態においては、φ_maxを小さくするほどシステム効率が高くなることを認識することになる。しかしながら、一定の事情下においては、φ_maxを制限することは、より高速のサービスに関するカバレッジエリアを制限する可能性がある。当業者は、様々な実施形態を構成する際には、この二者択一に従ってφ_maxを適合させることになる。

総割当ては、ＱｏＳグループＮａ内の各流れに関する全割当ての和である。

所定の流れに関する要求は次式によって与えられる。

ここで、b_r(i)は、ソースの瞬間ビットレートであり、r(i)は、は、リンク上で観察されたデータ速度である。総要求は次式によって与えられる。

総要求が総割当てを上回ると必ずサービス停止が発生する。一実施形態例においては、受付制御アルゴリズムは、Ｄ＞Ｆ_Ｒの確率に停止しきい値（例えば、０．１％）を超えさせるあらゆる流れへのサービスを拒否する。サービス停止は、必ずしもすべての流れに関する停止に至るわけではないことに注意すること。特定の流れに関連するサービス停止確率は、流れに関するその他の瞬間的要求に依存する。

１つの受付制御実施形態例においては、ＱｏＳ流を有する各ＵＴは、デューティファクター及びＭＡＣフレーム位相パラメータが割り当てられる。デューティファクターは、該流れに関するスケジューリング間隔と関連する周期性（例えば、１０のＭＡＣフレームごとに１つのスロット）を示す。位相パラメータは、該流れに関する伝送が生じるためのＭａｃフレームインデックス（例えば、０乃至１５）を示す。１つのＵＴ当たりにおいて複数のＱｏＳ流を処理時には、最高のデューティファクターを有する流れは、該ＵＴに関連するすべてのＱｏＳ流に関するスケジュールを指図することができる。

図４においてグラフで示されている次の例について検討する。即ち、ある１つの流れに関する速度要求によって、１つのスーパーフレーム（即ち、３２ｍｓ）当たり３７５のスロットが要求されることになると仮定する。この流れに関する速度パラメータを満たすために、１つのＭＡＣフレーム当たり平均２３．４３７５スロットが割り当てられる。更に、該流れの最長レーテンシーパラメータｄ_max（i）が 5ＭＡＣフレーム（即ち、１０ｍｓ）であると仮定する。以上の結果、許容される割当ては次のとおりである。

ＭＡＣ Ｆｒａｍｅ＃４ １１７スロット
ＭＡＣ Ｆｒａｍｅ＃９ １１７スロット
ＭＡＣ Ｆｒａｍｅ＃１４ １１７スロット
ＭＡＣ Ｆｒａｍｅ＃１５ ２４スロット
受付制御装置は、スーパーフレーム内の１６のＭＡＣフレームに関して割当てベクトルを構築する。

ＭＡＣフレーム０，１，．．．１５に関する総スロット割当てベクトルをＲ［i］とする。これで、受付制御装置は、後続する割当てのための利用可能性を確保するように設計されたＡ［i］の移相ｋ_Ａを決定することができる。図４は、１つのＲ［i］例と、Ａ［i］の移相ｋ_Ａの結果＝１５＋Ｒ［i］を示した図である。

当業者は、流れを受け入れるかどうかと受け入れた流れをどのようにして割り当てるかとを決定する際に採用できる様々な基準を認識することになる。例えば、フレームの容量は、ＱｏＳトラフィック及びＢＥＴトラフィックの両方に割り当てることができる。該割当ては、１フレームごとに固定することができ、又は、パッキング効率を向上させるために調整可能にすることができる。各割当てに関して、パッキング効率と追加の流れを受け入れる能力との間に二者択一が存在する。当業者は、様々な要因（例えば、ある所定の時間において予想される数のＱｏＳ流の統計上の特性、及び、流れの予想パラメータ（位相、デューティファクター、等）を含む）に基づいて割当て決定を行うように様々な実施形態を適合させることになる。

更に、当業者は、達成された効率とＱｏＳ維持との間にも二者択一の問題が存在する可能性があることを認識することになる。例えば、４つ目のＭＡＣフレームごとに１つのスロット中に適切に伝送させて８０％のパッキング効率を達成させることを許容する速度とレーテンシーを有する流れを仮定する。代替として、２つのＭＡＣフレームごとに１つのスロット中に流れを伝送してスロットパッキング効率を４０％にすることが可能である。システム効率の観点からは第１のスケジュールが好ましい。しかしながら、第２のスケジュールは、リンクデータ速度の低下を処理するための追加のリンクマージンを提供することができるため、ＱｏＳの観点からは第２のスケジュールのほうが優れている。受付制御装置は、流れスケジュールを設定する際に希望されるレベルの効率及び／又はＱｏＳ維持を均衡させることができるように構成することが可能である。

図５は、受付制御装置例５００の流れ図である。ブロック５１０において、アプリケーションが新しいＱｏＳ流に関する受付要求を行う。該要求は、該流れの予想特性に関するパラメータを含む。以下ではこれらの特性の例が説明されている。一般的には、受付制御装置は、予想パラメータ（即ち、平均値）に基づいて受付決定を行うことを思い出すこと。しかしながら、スケジューラは、実際のデータ量及び時間とともに変化する通信チャネルの現在の状態の関数であるリアルタイムのデータ伝送要求に基づいて容量を割り当てる。

ブロック５２０において、受付制御装置は、既に受け付けられている流れに関する予想データ要求を示す既存の受付プロフィールに基づいて、要求された新たな流れに関する容量の利用可能性についての評価を行う。要求された流れを組み入れる方法を既存のプロフィールに照らして決定する方法の一例が、図４を参照しつつ上述されている。決定ブロック５３０において、ＱｏＳ上の要求（デューティファクター及びレーテンシー上の要求、等）に加えてスループット上の要求に対処できる十分な容量が存在する場合は、ブロック５４０に進む。ブロック５４０において、新たな流れが受け付けられていることを示すメッセージを、要求を行っているアプリケーションに送る。要求を行っているアプリケーションは、該メッセージを受け取った時点で、新たな流れに関連するあらゆるプロセス（複数のプロセスを含む）を開始させる。

決定ブロック５３０において十分な容量が存在しない場合は、ブロック５７０に進む。ブロック５７０において、新たな流れを拒否するメッセージを、要求を行っているアプリケーションに送る。これで、該プロセスは停止する。

ブロック５５０において、新たな流れが受け付けられた後に、該新たな流れに関する確約（ｃｏｍｍｉｔｍｅｎｔ）を含めるために受付プロフィールを修正する。当業者は、本発明の適用範囲において非常に数多くの受付プロフィール表現方法が存在することを認識することになる。本実施形態例においては、容量は、ＯＦＤＭ記号に基づいて割り当てられる。また、１６のＭＡＣフレームから成るＭＡＣスーパーフレームが構成される。受付プロフィールは、各受け付けられた流れに割り当てられた各ＭＡＣフレーム内の幾つかのＯＦＤＭ記号に関する確約、又は契約を含む。代替実施形態においては、その他の単位の容量（例えば、ＴＤＭシステム内のタイムスロット、ＣＤＭシステム内の電力及び／又は符号、等）を割り当てることができる。受付プロフィールは、様々なレベルの時間粒度になることができ、周期長も可変である。更に、流れに関する確約は、特定フレームに固定する必要がない。例えば、流れには、受付プロフィール確約の一部として、１つのフレーム範囲内の一定数の記号を割り当てることができる。スケジューラは、契約上の最低数が指定範囲内において満たされているかぎり、流れに割り当てるフレームに関して柔軟性を有することができる。

ブロック５６０において、更新された受付プロフィールをスケジューラに提供する。スケジューラが受付プロフィールを利用可能にするためのどのような手段も、本発明の適用範囲内である。例えば、スケジューラは、単純に、受付制御装置と共有されているメモリ内の受付プロフィールにアクセスすることができる。代替実施形態においては、受付プロフィールは、スケジューラに対してシグナリングすること又はメッセージに入れて送ることができる。新たな流れの追加は、以前に受け付けられた流れと結合させて現在の受付プロフィールが形成されるため、受付プロフィール全体を伝送する必要がない。これでプロセスが停止することができる。該プロセスは、アプリケーションがスケジューラにおいて帯域幅を確保できるようにするために希望する回数だけ繰り返すことができる点に注目すること。

更に、当業者にとって直ちに明確になるように、流れは受付プロフィールから削除できることにも注目すること。図５には詳細は示されていない。アプリケーションは、流れがこれ以上必要ないことを示すメッセージを送ることができる。代替として、流れを修正する新たな要求を送ることができる。もう１つの選択肢として、スケジューラは、アプリケーションが契約されたパラメータに固執していない場合は流れを取り除くように受付制御装置に指示することができる。この場合には、流れが完全に遮断されるか又はベストエフォート分類に移される。この場合には、アプリケーションは、ＱｏＳ最低基準が満たされていない場合は、流れに関連するプロセスを終了するように強制される。該アプリケーションは、スケジューラとのＱｏｓ維持サービスを確立させるために、調整されたパラメータを用いて、流れに関する受付を再要求することができる（サービス再交渉）。

ＱｏＳスケジューリング
ＱｏＳスケジューリングを採用した基本的な実施形態においては、流れに関する伝送（即ちアクセス）要求が行われる。この要求は、伝送のためのトラフィックの型を特定する必要がなく、単に量を示すだけである。この状況においては、要求を行っているアプリケーションは、優先度（即ち、ＢＥＴよりもＱｏＳを優先）に従って待ち行列内の順序を設定する。スケジューラが１つ以上の待ち行列と共に配置されている実施形態においては（例えば、上述されているように、順方向リンクトラフィックに関する待ち行列を有するアクセスポイント内、又は、アクセスポイントとして動作するか又は１つ以上のピア・ツー・ピア接続を管理するＵＴ内）、これらの共に配置されている様々な待ち行列内のデータは伝送が必要であることを示しているため、伝送要求を行う必要がない。基本的な実施形態においては、待ち行列内のデータの型は不明の場合があり、この場合は、データを送るアプリケーションは、待ち行列に送られるデータの順序を優先度に従って決定すべきである。これらの基本シナリオにおいては、受付プロフィールにおいて示されている契約された確約を用いてＱｏＳスケジューリングに対応することができる。

待ち行列内のデータに関する追加情報が入手可能であるときには、追加の機能及び制御を利用することができる。例えば、スケジューラが様々な流れに関連する１つ以上の待ち行列と共に配置されており、これらの待ち行列が分離されているか又はデータクラス（即ち、ＱｏＳ又はＢＥＴ）を示している場合は、スケジューラは、伝送待機中のデータの量及び型を既知である。スケジューラは、このシナリオにおいて複数の異なった型のデータの優先順位を設定することができる。一実施形態例は、順方向リンク流に関する待ち行列を維持するアクセスポイントである。これらの流れを生み出すアプリケーションは、２つ以上のクラスのデータがソースからＵＴに向けられている場合にはデータのクラスを示す必要があることに注意すること。該シナリオにおいては、直前において説明されているように逆方向リンクスケジューリングが基本であり、他方、順方向リンクスケジューリングは、様々なデータクラスを対象にすることができる（後述）。

オプションとして、伝送要求は、データのクラスを示すことができる。２つ以上のクラスが（ＵＴからの）伝送待ちである場合は、要求は、各型のうちのどれだけが伝送待ちであるかを示すことができる。この場合は、スケジューラは、共に配置されている待ち行列の場合と同じようにデータのクラスを対象にすることができる。

要求の型及び待ち行列のあらゆる組合わせを実施形態内において構成させることができる。スケジューラは、特定の知識が入手可能になったときに単純に該知識を利用し、該情報が入手できないときには該情報なしで進行する。いずれかの実施形態においても、スケジューラは、上述されているように、様々なアプリケーション／流れと受付制御装置との間における契約に従って受付プロフィールを利用することによって、本明細書において説明されているＱｏＳスケジューリング上の便益を実現させることができる。

スケジューラ方法６００の一般化された実施形態の流れ図が図６に描かれている。方法６００は、上述されている基本シナリオに関して、データクラスに関してより高度な知識を入手可能なシナリオに関して、又はそのあらゆる組み合わせに関して、使用することができる。図７は、クラス型が不明時に使用するのに適したブロック６４０のオプションをさらに詳細に示した図である。図８は、クラス型が既知であるときに適しているブロック６４０のオプションをさらに詳細に示した図である。更に、図８は、本発明のその他の側面も示している。

方法６００は、ブロック６１０において開始し、受付制御装置からの更新された受付プロフィールが受け取られる。図５に関して上述されているように、受付プロフィールは、受付制御装置及びスケジューラがアクセスするために、単に共有メモリ内に格納することができる。代替実施形態においては、受付プロフィールの更新が伝送され、これらの更新は、スケジューラが利用可能な受付プロフィールの現在の状態内に組み入れられる。ＱｏＳ流の容量に関する確約は時間の経過とともに追加又は取り除くことができることに注目すること。

ブロック６２０において、スケジューラは、複数のユーザー端末及び／又はアプリケーションからの（ネットワーク１４０を通じて受け取られた）複数の伝送要求を受け取る。ブロック６３０において、受付プロフィール内において契約が存在する各要求中のＵＴ／アプリケーションに関して、契約量まで容量が割り当てられる。本実施形態例においては、各ＵＴ／アプリケーションは、契約された数のＯＦＤＭ記号が、現行フレーム内における伝送用に予約される（この点に関する一例が図４を参照しつつ上記されている）。このブロック６３０と関連する割当ては、要求された全データ量を満たさない場合があることに注意すること。その理由は、速度が可変であるデータソースは、契約のために使用されている平均量よりも多いデータを生成することがしばしばあるためである。更に、無線チャネルの質の低下は、希望される量のデータを伝送するための追加容量（即ち、ＯＦＤＭ記号、タイムスロット、電力、等）を要求することがある。

ブロック６４０において、割当て用の追加容量が残っている場合は、該追加容量は、残りの対応されていない要求間で分割することができる。後述されているように、ブロック６４０に関する代替実施形態が図７及び８に示されている。一実施形態においては、残りの容量は、あらゆる数のベストエフォート型戦略を用いて割り当てることができる。例えば、容量は、残っている要求間でラウンドロビン方式で割り当てられる。代替実施形態においては、契約されたＱｏＳ割当てをフレーム内に有するＵＴ／アプリケーションの場合は、ブロック６３０において割当てが行われていない自己の要求の残りの部分の一部又は全部は契約された割当てを上回ったＱｏＳデータになることができるという理論に基づき、残りのＢＥＴ割当てに関して優先権が与えられる。残りの部分の割当てに関しては、その他の公平性基準を採用することができる。又、ＢＥＴ割当てにおいて一部のＵＴ／アプリケーションがその他のＵＴ／アプリケーションよりも優先されるように追加のレベルの優先順位設定を構成することができる。更に、これらの技術のあらゆる組合わせを採用可能である。以下では、追加オプションについて説明される。

当業者は、本明細書において示されている教義を、追加のクラス、及びクラスの型の組合わせに簡単に拡大させることになる。例えば、説明を明確化するために、本明細書において説明されている様々な実施形態は、上述されているＲＬＣトラフィックに関する説明を省略している。一実施形態例においては、ＲＬＣトラフィックは、優先度が最も高いトラフィックであるが、全容量のうちの相対的に小さい量を要求する。従って、この第３の優先度が高いクラスのデータに対応する１つの方法は、ＲＬＣデータが要求の一部分である各々の要求中のＵＴに対して少量の容量を割り当てることである。残りの容量は、本明細書において説明されているように、ＱｏＳ又はＢＥＴスケジューリングに従って割り当てられる。明らかなことであるが、ＲＬＣが要求内において特定されている場合又はその他の形で既知である（即ち、共に配置された待ち行列内に含められている）場合は、直接的な方法で割当てを行うことができる。

図７は、ＱｏＳスケジューリング後に残りの容量を割り当てるためのブロック６４０の代替実施形態を示した図である。上述されている様々な方法の一代替方法として、図７に示されているブロック６４０の実施形態は、伝送要求が許可されているＵＴ／アプリケーション数を最大にすることを試みるように構成することができる。ブロック７１０において、上述されているブロック６３０で割当てが行われなかった又は一部の割当てしか行われなかった要求の順位が設定され、最高順位は、要求のサイズ（又は該要求のうちの残りの部分）に反比例する。ブロック７２０において、残りの容量は、順位が高い順に要求に割り当てられる。容量不足に起因して最終的な割当てを完全に行うことができない場合は、該要求に関しては部分的な割当てが行われる。従って、対応可能な最大数の要求がこの方法によって満たされる。この実施形態は、上述されている様々な技術と共に使用することができる。

上述されているように、スケジューラが要求に関連するデータの型又は待ち行列内のデータの型を既知であるときには、該情報をスケジューリング決定の中に組み入れることができる。この原理について説明するために次の例を検討する。即ち、スケジューラによって管理される各ＱｏＳ流に関してアクティブフラグが維持される。いずれの所定のフレームにおいても、このアクティブフラグは、（図４の例において示されているように）該フレーム内において公称のスロット割当てを有するすべての受け付けられたＱｏＳ流に関して設定される。アクティブフラグが設定されているすべてのＱｏＳ流は、現在のＭＡＣフレームにおいて最初にサービスが提供される。その他のＱｏＳ流は、未使用のＦ_Ｒ資源が存在するかどうかに依存して、現在のＭＡＣフレーム内においてサービスを受け取る場合と受け取らない場合がある。この例においては、Ｆ_Ｒは、上述されているように、ＱｏＳサービス用に確保された容量に関する制限であることができ、ＦＢは、ベストエフォートトラフィック用に確保される。希望される場合は、Ｆ_Ｒは全容量に設定できることが明確であろう。１つ以上の部分的に割り当てられた要求がＱｏＳデータを含むかどうかをスケジューラが既知である場合で、その他の要求がベストエフォートトラフィックに向けられる場合は、スケジューラは、残りのＱｏＳトラフィックを優先する。更に、Ｆ_Ｒの一部分が完全に割り当てられていないときに、将来の負荷を軽減するためにスケジューラが「先行して作業をする」ようにすることも望ましい。このオプションを用いて現在のＢＥＴ要求に先行することは、容量の限定された部分Ｆ_ＲがＱｏＳサービスに割り当てられるときに適切である。しかしながら、先行作業（後述）は、割り当てられていない容量が残存するときに常に行うことができる。

この例においては、アクティブなＱｏＳ敏感流は、正の流れマージンＤ^＋を有するグループと負の流れマージンＤ⁻を有するグループに区分される。

Ｄ^＋内の流れは、流れに関する要求が割当てよりも小さいか同じであるため停止しない。更に、正の流れマージンを有するＤ^＋内の流れは、その他のＱｏＳ流が優先度に従って利用可能になるようにすることができる未使用スロット群Ｍに貢献する。Ｄ⁻内の流れは、未使用資源が利用可能であるかどうかに依存して、要求物を受け取ることができる場合とできない場合がある。

Ｄ⁻が空でない場合は、最初にこのグループ内の流れが未使用スロットを利用できるようにする。Ｄ⁻内のアクティブＱｏＳ流への未使用スロットの割当てを処理する方法はいくつか存在する。この例における目標は、各々のＱｏＳ要求を満たしている流れ数を最大にすることである。このことは、Ｄ⁻内の流れの順位を流れマージンm_iに基づいて設定することによって達成される。即ち、最も小さい|m_i|を有する流れは、最高の順位を受け取る。Ｄ⁻に属するm_iは、m_iが負値であることを示している点に注意すること。

この例においては、スケジューラは、Ｄ⁻内の最高順位の流れが自己の要求ψ（i）を達成させるのを可能にするために、超過マージンプールから最低数のスロットを割り当てる。この手順は、超過マージンプールが枯渇するまで又はすべてのアクティブＱｏＳ流にサービスが提供されるまで繰り返される。最後に検討されたＱｏＳ流が完全に満たされていない場合は、部分的割当てが行われる。完全に満たされていない流れは、サービス低下が生じることがある。この例は、流れが割当てを受け取らない場合がある。このような場合には、バッファオーバーフローが発生するか又はパケットが失われる可能性がある。この点を防止するため、ある所定の流れに関するＱｏＳ待ち行列からのバッファオーバーフローを、ユーザーのベストフォート待ち行列の前に置くことができる。

すべてのアクティブ流に対応後に未使用スロットが存在する場合は、Ｆ_Ｒの残りの部分は、ＱｏＳ待ち行列内にデータを有しているが現在のフレームに関してアクティブフラグが設定されていないＱｏＳ流のグループに提供することができる。前述されているこの「先行作業」スケジューリング能力は、一般的には、将来伝送されるデータ（即ち、次のフレームにおいて伝送することが意図されているデータ）にスケジューラがアクセス時に実施される。一実施形態においては、アクセスポイントは、スケジューラを収容し更に順方向リンクデータに関する待ち行列を維持する。従って、スケジューラは、希望される場合は、適宜先行作業を行うことができる。逆方向リンクデータ要求が、（上述されている）受付プロフィールのみに基づいてＱｏＳに関してスケジューリングされる実施形態例においては、スケジューラは、ユーザー端末内の将来のデータについて知らないことがあり、このため、順方向リンクのみにおいて先行作業を行う。該逆方向リンクに関しては、スケジューラは、（受付プロフィールに従って）ＭＡＣフレーム内においてスケジューリングされているデータ以外のＱｏＳデータとＢＥＴデータを区別しない。即ち、ある所定の流れに関するＱｏＳトラフィックが、逆方向リンクセグメントにおいて要求物が与えられた時点で、該ＵＴのデータの残りの部分は、ＢＥＴトラフィックであるとスケジューラによってみなされる。当業者は、順方向リンク又は逆方向リンクに合わせて、及びスケジューラのあらゆる所在場所に関して、この原理を適合させる方法を認識することになる。特に、このスケジューラは、管理されたピア・ツー・ピア接続に関するスケジューリングを上述の手順に従って提供する指定ＵＴに所在することができる。更に、ＵＴの観点からは、この例においては、ＵＴ待ち行列内において希望されるあらゆる形でデータを配列することができる点に注目すること（例えば、先行作業ＱｏＳデータをＵＴのＢＥＴ待ち行列の前に置くことができる）。従って、ＵＴは、希望される場合は、スケジューラが先行作業をしないときでも先行して作業をすることができる。

非アクティブ順方向リンクＱｏＳ流への未使用スロット割当て（先行作業）は、次のように行われる。即ち、非アクティブ順方向リンクＱｏＳ流が、位相パラメータ順に優先順位を設定される。即ち、次のＭａｃフレームにおいてアクティブになる非アクティブ順方向リンク流に最高の優先順位が与えられる。この位相グループ内の流れは、（上述されているように）満たされる流れ数を最大にする形で優先順位が設定される。従って、待ち行列内におけるデータ量が最も少ない非アクティブ流が最初に対応される。スケジューラは、Ｆ_Ｒ内のすべてのスロットが占有されるまで、又はすべてのＱｏＳ待ち行列が空になるまで、これらの非アクティブＱｏＳ流に対して先行作業を提供し続ける。

図８は、伝送が要求された（又は待ち行列内において共に配置されている）データに関する何らかの情報が既知であるときにＱｏＳスケジューリング後の残りの容量を割り当てるためのブロック６４０の代替実施形態を示した図である。この実施形態は、前述されている正及び負の流れマージン例と適合可能であり、先行作業も同様にオプションで構成させることができる。

プロセスは、決定ブロック８１０において開始する。割り当てる容量が残っていない場合は、該プロセスは停止する。残りの容量が存在する場合は、ブロック８２０に進む。ブロック８２０において、ＱｏＳ要求の順位が設定される。様々な順位設定を企図することができる。本実施形態例においては、最も多くの要求に対応するために、これらの要求は、サイズが小さい要求のほうが順位が高くなる。

ブロック８３０において、順位が次に高い要求が選択される（最初の繰り返しにおける最高順位）。ブロック８４０において、残りの容量が該選択された要求に割り当てられる。該要求の残りの部分が該残りの容量よりも大きい場合は、該残りの容量の残りの部分が割り当てられる。決定ブロック８５０において、該残りの容量が使い尽くされている場合は、プロセスが停止する。容量が残っている場合は、決定ブロック８６０に進む。

決定ブロック８６０において、割当てが行われずに残っているさらなるＱｏＳ要求が存在する場合は、ブロック８３０に戻り、次に順位が高い要求を選択し、直前において説明されたプロセスを繰り返す。すべてのＱｏＳ要求が処理済みである場合は、ブロック８７０に進む。

ブロック８７０は、ダッシュ線によって描かれており、先行作業がオプションであることを示している。希望される場合は、スケジューラは、将来のＱｏＳフレームに先行して作業を行うことができる。該先行作業を行う方法例が以下において説明される。

ブロック８８０において、残りの容量がベストエフォートトラフィックに割り当てられる。あらゆるベストエフォート方法を採用することができる。一実施形態例においては、ベストエフォートトラフィックは、ラウンドロビンスケジューリング方法を用いて対応される。該手法は、複数の異なるユーザー端末間における、又は１つの所定のユーザーに関連する複数の流れにおける、ＱｏＳの差別化は備えていない。しかしながら、上述されているように、ユーザー端末は、希望するあらゆるＱｏＳ方式に対応するために待ち行列内のパケットの優先順位を自由に設定することができる。追加のレベルのユーザー間優先順位設定を希望する場合は、当業者が明確に理解できるように、スケジューラが該優先順位設定を援助できるようにシグナリングを構成させることができる。

上述されているすべての実施形態において、方法上の諸ステップは、本発明の適用範囲から逸脱せずに相互に交換可能であることに注目すべきである。本明細書において開示されている説明は、多くの場合は、ＭＩＭＯ ＯＦＤＭシステムに関連する信号、パラメータ、及び手順を参照しているが、本発明の適用範囲は、これらに限定されるものではない。当業者は、本明細書に示されている原理を、その他の様々な通信システムに容易に応用できることになる。これらの修正及びその他の修正は、当業者にとっては明確に理解できることである。

情報及び信号は、様々な種類の技術及び技法のうちのいずれかを用いて表すことができることを当業者は理解することになる。例えば、上記の説明全体を通じて言及されているデータ、命令、コマンド、情報、信号、ビット、記号、及びチップは、電圧、電流、電磁波、磁界、磁粒子、光学界、光学粒子、又はそのあらゆる組合わせによって表すことができる。

本明細書において開示されている実施形態に関係させて説明されている様々な例示的論理ブロック、モジュール、回路、及びアルゴリズムステップは、電子ハードウェアとして、コンピュータソフトウェアとして、又は両方の組合わせとして実装することができるということを当業者はさらに理解することになる。ハードウェアとソフトウェアのこの互換性を明確に例示するため、上記においては、様々な例示的構成要素、ブロック、モジュール、回路、及びステップが、各々の機能の観点で一般的に説明されている。これらの機能がハードウェアとして又はソフトウェアとして実装されるかどうかは、全体的システムに対する特定の用途上の及び設計上の制約事項に依存する。当業者は、説明されている機能を各々の特定の用途に合わせて様々な形で実装することができるが、これらの実装決定は、本発明の適用範囲からの逸脱を生じさせるものであるとは解釈すべきではない。
本明細書において開示されている実施形態に関して説明されている様々な例示的な論理ブロック、モジュール、及び回路は、本明細書において説明されている機能を果たすように設計された汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、その他のプログラミング可能な論理デバイス、ディスクリートゲートロジック、ディスクリートトランジスタロジック、ディスクリートハードウェア構成品、又はそのあらゆる組合せ、とともに実装又は実行することができる。汎用プロセッサはマイクロプロセッサであることができるが、代替策として、従来のどのようなプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってもよい。さらに、プロセッサは、計算装置の組合せ、例えば、ＤＳＰと、１つのマイクロプロセッサとの組合せ、複数のマイクロプロセッサとの組合せ、ＤＳＰコアと関連する1つ以上のマイクロプロセッサとの組合せ、又はその他のあらゆる該コンフィギュレーションとの組合せ、として実装することもできる。

本明細書において開示されている実施形態に関して説明されている方法又はアルゴリズムのステップは、ハードウェア内において直接具体化させること、プロセッサによって実行されるソフトウェアモジュール内において具体化させること、又はその両方の組合せにおいて具体化させることができる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能なディスク、ＣＤ−ＲＯＭ、又は当業において既知であるその他のあらゆる形態の記憶媒体に常駐させることができる。１つの典型的な記憶媒体をプロセッサに結合させ、該プロセッサが該記憶媒体から情報を読み出すようにすること及び該記憶媒体に情報を書き込むようにすることができる。代替として、該記憶媒体は、プロセッサと一体化させることができる。さらに、該プロセッサ及び該記憶媒体は、ＡＳＩＣ内に常駐させることができる。該ＡＳＩＣは、ユーザー端末内に常駐することができる。代替として、該プロセッサ及び記憶媒体は、ユーザー端末内において個別構成要素として常駐することができる。

開示されている実施形態に関する上記の説明は、当業者が本発明を製造又は使用できるようにすることを目的とするものである。又、これらの実施形態に対する様々な修正が加えられた場合には、当業者は、該修正を容易に理解することが可能である。さらに、本明細書において定められている一般原理は、本発明の精神及び適用範囲を逸脱しない形でその他の実施形態に対しても適用することができる。以上のように、本発明は、本明細書において示されている実施形態に限定することを意図するものではなく、本明細書において開示されている原理及び斬新な特長に一致する限りにおいて最も広範な適用範囲が認められることになることを意図するものである。

Claims (37)

1. 通信システムにおいてデータ伝送をスケジューリングするスケジューラであって、
   １つ以上のデータ伝送指標に対応する１つ以上の遠隔デバイスの各々が、受付プロフィールにおいて容量予約を有するかどうかを決定する第１の論理と、
   容量予約が見つかったときにデータ伝送指標に従って容量を割り当てる第２の論理と、を具備するスケジューラ。
2. 前記第２のロジックは、前記容量予約に従って前記割当てを制限する、請求項１に記載のスケジューラ。
3. 前記第２の論理は、満たされていないデータ伝送指標に対応して、前記伝送指標の前記割り当てられていない部分のサイズが小さい順に、残りの容量（存在する場合）をさらに割り当てる、請求項２に記載のスケジューラ。
4. 複数のデータ伝送指標の各々は、複数のサービスレベルの１つと関連づけられている、請求項１に記載のスケジューラ。
5. 前記第２の論理は、前記受付プロフィールに従い、第１のグループのサービスレベルのうちの１つ以上と関連づけられた１つ以上の伝送指標に対応して容量を割り当て、更に、第２のグループのサービスレベルのうちの１つ以上と関連づけられた１つ以上の伝送指標に対応して残りの容量（存在する場合）を割り当てる、請求項４に記載のスケジューラ。
6. 前記第１のグループは、１つ以上のサービス品質が保証されたサービスレベルを具備する、請求項５に記載のスケジューラ。
7. 前記第２のグループは、１つ以上のベストエフォートサービスレベルを具備する、請求項５に記載のスケジューラ。
8. 複数の遠隔デバイスとともに動作可能であり、更に、複数の時間と、前記複数の時間の各々におけるゼロ以上の遠隔デバイスに関する容量予約と、を具備する受付プロフィール、とともに動作可能な、通信デバイスであって、
   前記複数の時間の各々の時間中に、複数のデータ伝送指標の各々に関して、前記データ伝送指標に対応する遠隔デバイスが前記受付プロフィールにおいて容量予約を有するかどうかを決定するためと、前記データ伝送指標に従って容量を割り当てるための、スケジューラ、を具備する通信デバイス。
9. 前記スケジューラは、前記容量予約に従って前記割当てを制限する、請求項８に記載の通信デバイス。
10. 前記スケジューラは、満たされていないデータ伝送指標に対応して、前記データ伝送指標の前記割り当てられていない部分のサイズが小さい順に、残りの容量（存在する場合）をさらに割り当てる、請求項９に記載の通信デバイス。
11. データ伝送指標を具備する要求メッセージを受け取るための受信機をさらに具備する、請求項８に記載の通信デバイス。
12. １つ以上のデータ待ち行列をさらに具備し、待ち行列内においてデータが存在する状態でデータ伝送指標が生成される、請求項８に記載の通信デバイス。
13. 前記割り当てられた容量を示す１つ以上の許可メッセージを送るための送信機をさらに具備する、請求項８に記載の通信デバイス。
14. データ流に対応する流れパラメータを具備する受付要求を遠隔デバイスから受け取るためと、前記受付プロフィールと結合された前記流れパラメータが前記システム容量を超えない場合は、条件付きで前記流れを受け付けるためと、受付時に前記受付プロフィールを修正して前記流れを組み入れるための、受付制御装置、をさらに具備する、請求項８に記載の通信デバイス。
15. 各遠隔デバイスは、複数のデータ伝送指標に対応することができ、各指標は、サービスレベルと関連づけられている、請求項８に記載の通信デバイス。
16. 前記スケジューラは、前記受付プロフィールに従い、第１のグループのサービスレベルの１つ以上と関連づけられた１つ以上の伝送指標に対応して容量を割り当て、更に、第２のグループのサービスレベルの１つ以上と関連づけられた１つ以上の伝送指標に対応して残りの容量（存在する場合）を割り当てる、請求項１５に記載の通信デバイス。
17. 前記第１のグループは、１つ以上のサービス品質が保証されたサービスレベルを具備する、請求項１６に記載の通信デバイス。
18. 前記第２のグループは、１つ以上のベストエフォートサービスレベルを具備する、請求項１６に記載の通信デバイス。
19. 前記スケジューラは、前記受付プロフィール内において容量予約を有する１つ以上の遠隔デバイスと関連づけられた１つ以上の伝送指標に対応して容量を割り当て、第１のサービスレベルと関連づけられた満たされていない伝送指標に対応して残りの容量（存在する場合）を割り当て、第２のサービスレベルと関連づけられた伝送指標に対応して残りの容量（存在する場合）を割り当て、各遠隔デバイスに関して割り当てられる前記容量は、各々の容量予約に制限される、請求項１５に記載の通信デバイス。
20. 前記スケジューラは、前記第２のサービスレベルと関連づけられた指標に対応した割当て前に、前記第１のサービスレベルと関連づけられた１つ以上の将来の時間においてデータ伝送指標に対応して残りの容量（存在する場合）をさらに割り当てる、請求項１９に記載の通信デバイス。
21. 満たされていない指標に対応する前記割当ては、前記データ伝送指標の前記割り当てられていない部分のサイズが小さい順に実施される、請求項１９に記載の通信デバイス。
22. 複数の遠隔デバイスと、
    複数の時間と、前記複数の時間の各々におけるゼロ以上の遠隔デバイスに関する容量予約と、を具備する受付プロフィールと、
    前記複数の時間の各々の時間中に、複数のデータ伝送指標の各々に関して、前記データ伝送指標に対応する遠隔デバイスが前記受付プロフィール内において容量予約を有するかどうかを決定するためと、前記データ伝送指標に従って容量を割り当てるための、スケジューラ、を具備する通信デバイスと、を具備する通信システム。
23. １つ以上の伝送指標を１つ以上の遠隔デバイスから受け取ることと、
    受付プロフィールに従って前記伝送要求のうちの１つ以上を許可すること、とを具備するスケジューリング方法。
24. データ流に対応する流れパラメータを具備する受付要求を遠隔デバイスから受け取ることと、前記受付プロフィールと結合された前記流れパラメータが、前記システム容量を超えない場合は、条件付きで前記流れを受け付けることと、受付時に前記受付プロフィールを修正して前記流れを組み入れること、とをさらに具備する、請求項２３に記載の方法。
25. 複数の時間の各々に関して、及び、複数のデータ伝送指標の各々に関して、前記データ伝送指標に対応する遠隔デバイスが受付プロフィール内において容量予約を有するかどうかを決定することと、
    前記受付プロフィール内に容量予約が存在するときには前記データ伝送指標に従って容量を割り当てること、とを具備するスケジューリング方法。
26. 前記データ伝送指標の１つ以上は、１つ以上の遠隔デバイスから受け取られる、請求項２５に記載の方法。
27. 前記データ伝送指標の１つ以上は、待ち行列内におけるデータの存在に対応して生成される、請求項２５に記載の方法。
28. 前記複数のデータ伝送指標の各々は、複数のサービスレベルの１つに対応する、請求項２５に記載の方法。
29. 最初に第１のサービスレベルに対応するデータ伝送指標に関して容量が割り当てられ、１つ以上の第２のサービスレベルに対応する伝送指標に残りの容量（存在する場合）が割り当てられる、請求項２８に記載の方法。
30. 複数の遠隔デバイスに対応する複数のデータ速度指標を受け取ることと、
    受付プロフィールにアクセスして、１つ以上の伝送指標が関連づけられた予約を前記受付プロフィール内に有するかどうかを決定することと、
    前記突き止められた予約に従って容量を割り当てることと、
    残りの容量を残りの伝送指標に割り当てることと、
    前記容量割当てに従って１つ以上の許可メッセージを伝送すること、とを具備する、スケジューリング方法。
31. １つ以上の伝送要求を１つ以上の遠隔デバイスから受け取る手段と、
    受付プロフィールに従って前記伝送要求の１つ以上を許可する手段と、を具備するデバイス。
32. 前記受付プロフィールは、複数のフレームと、フレーム当たり１つの遠隔デバイスと関連づけられたゼロ以上の容量値と、を具備する、請求項３１に記載のデバイス。
33. 前記受付プロフィールは、１つ以上のデータ流に関するデューティファクター及びフレーム位相に従って作成される、請求項３１に記載のデバイス。
34. データ流に対応する流れパラメータを具備する受付要求を遠隔デバイスから受け取る手段と、前記受付プロフィールと結合された前記流れパラメータが、前記システム容量を超えない場合は、条件付きで前記流れを受け付ける手段と、受付時に前記受付プロフィールを修正して前記流れを組み入れる手段と、をさらに具備する、請求項３１に記載のデバイス。
35. １つ以上の伝送要求を１つ以上の遠隔デバイスから受け取る手段と、
    受付プロフィールに従って前記伝送要求の１つ以上を許可する手段と、を具備する通信システム。
36. １つ以上の伝送要求を１つ以上の遠隔デバイスから受け取ることと、受付プロフィールに従って前記伝送要求の１つ以上を許可すること、とを具備する方法、を実施するために動作可能な、コンピュータによって読み取り可能な媒体。
37. データ流に対応する流れパラメータを具備する受付要求を遠隔デバイスから受け取ることと、前記受付プロフィールと結合された前記流れパラメータが、前記システム容量を超えない場合は、条件付きで前記流れを受け付けることと、受付時に前記受付プロフィールを修正して前記流れを組み入れること、とを実施するためにさらに動作することができる、請求項３６に記載の媒体。

Images