JP5933703B2 - スケジューリング概念 - Google Patents

Description

本発明の実施形態は、通信ネットワークに関し、排他的にではなくより具体的には、モバイル通信ネットワークでのパケット・データ伝送に関する。

モバイル・サービスに関するより高いデータ・レートの需要は、着実に高まりつつある。同時に、第３世代システム（省略形として３Ｇ）および第４世代システム（省略形として４Ｇ）などの現代のモバイル通信システムは、より高いスペクトル効率を可能にし、より高いデータ・レートおよびセル容量を可能にする強化された技術を提供する。現在のハンドヘルド機のユーザは、満足させるのがよりむずかしくなっている。古いフィーチャー・ホンは、データ・トラフィックまたは音声トラフィックだけを生成したが、現在のスマートホン、タブレット、およびネットブックは、お互いに基本的に異なる可能性があるさまざまなアプリケーションを並列に走行させる。フィーチャー・ホンと比較して、このアプリケーション混合物は、複数の新しい特性につながる。たとえば、非常に動的な負荷統計が生じる。現代のハンドヘルド機は、バースト性のトラフィックを生成するさまざまなアプリケーションをサポートし、Ｇ．Ｍａｉｅｒ、Ｆ．Ｓｃｈｎｅｉｄｅｒ、Ａ．Ｆｅｌｄｍａｎｎ、「Ａ Ｆｉｒｓｔ Ｌｏｏｋ ａｔ Ｍｏｂｉｌｅ Ｈａｎｄ−ｈｅｌｄ Ｄｅｖｉｃｅ Ｔｒａｆｆｉｃ」、Ｉｎ Ｐｒｏｃ．Ｉｎｔ．Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐａｓｓｉｖｅ ａｎｄ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ｍｅａｓｕｒｅｍｅｎｔ（ＰＡＭ ’１０）、２０１０年４月を参照されたい。さらに悪いことに、マルチタスキング・オペレーション・システムを用いると、これらのアプリケーションの多くは、並列に走行し、ユーザは、アクティブ・アプリケーションのこの混合物を任意の瞬間に変更することができる。その結果、生成される負荷は、すばやく変化する可能性があり、高いピークが、いつでも現れる可能性がある。

さらに、負荷統計は、非常に多様になる可能性がある。アプリケーション混合物が静的なままである場合であっても、要求される負荷は、アプリケーションの間で基本的に異なる可能性がある。その結果、現在、フィーチャー・ホンより大きい、満足すべき負荷要求のスペクトルがある。さらに、制約の動力学が増加した。各アプリケーションは、誤り率および遅延において異なる要件を有する可能性があり、この要件は、アプリケーションがインアクティブになる時またはアプリケーション混合物が変化する時に変化する可能性がある。その結果、ＵＥ（３ＧＰＰ用語と一致するＵｓｅｒ Ｅｑｕｉｐｍｅｎｔの省略形として。３ＧＰＰは、３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔの省略形である）に与えられる保証は、すぐに古くなる可能性がある。

これらのトラフィック特性は、サービス品質（省略形としてＱｏＳ）を保ちながら現代のＵＥに無線チャネル・リスースを効率的に割り振ることを困難にする。第１に、負荷統計は、現在、不安定で特性を表すことおよび予測することがむずかしく、Ｆ．Ｓｃｈｎｅｉｄｅｒ、Ｓ．Ａｇａｒｗａｌ、Ｔ．Ａｌｐｃａｎ、Ａ．Ｆｅｌｄｍａｎｎ、「Ｔｈｅ Ｎｅｗ Ｗｅｂ： Ｃｈａｒａｃｔｅｒｉｚｉｎｇ ＡＪＡＸ Ｔｒａｆｆｉｃ」、Ｉｎ Ｐｒｏｃ．Ｉｎｔ．Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐａｓｓｉｖｅ ａｎｄ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ｍｅａｓｕｒｅｍｅｎｔ、２００８年４月を参照されたい。第２に、その下でリソースが割り当てられる制約は、非常に多様であり、任意の時に変化する可能性がある。最後に、アプリケーションＱｏＳ需要は、ユーザの現在の環境（たとえば、その位置、速度、および他のユーザへの距離）に依存する可能性がある。

Ｇ．Ｂｉａｎｃｈｉ他、「Ａ Ｐｒｏｇｒａｍｍａｂｌｅ ＭＡＣ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｕｔｉｌｉｔｙ−Ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｓｕｐｐｏｒｔ」、ＩＥＥＥ ＪＯＵＲＮＡＬ ＯＮ ＳＥＬＥＣＴＥＤ ＡＲＥＡＳ ＩＮ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ、ＶＯＬ．１８、ＮＯ．２、２０００年２月は、ハイブリッド集中／分散データ・リンク・コントローラに基づくプログラマブル媒体アクセス制御フレームワークの設計および評価を開示するものである。プログラマブル・フレームワークおよびそれに関連するアルゴリズムは、アプリケーション固有適合の必要を考慮に入れた公平で効率的な形で時間変動し帯域幅制約されるネットワーク（たとえば、無線ネットワーク）上の適合的なリアルタイム・アプリケーションをサポートすることができる。フレームワークは、柔軟であり、拡張可能であり、新しい適合的なサービスのオンデマンドでの動的導入をサポートする。サービス作成プロセスの一部として、アプリケーションンは、分散適合ハンドラのセットと相互作用して、集中適合コントローラを更新する必要なしにサービスをプログラムする。この手法は、アプリケーションがそこから選択するデータ・リンクでの「ハードワイヤード」サービスの固定されたセットを提供する技法とは対照的である。適合的なアプリケーションの間での使用可能な帯域幅の公平な割振りの責任を負う集中化された適合コントローラは、アプリケーション固有特定帯域幅効用曲線によって駆動される。分散適合ハンドラのセットは、アプリケーションが効用曲線、適合時間スケール、および適合ポリシに関する適合の要求をプログラムすることを可能にするために、集中コントローラと相互作用するエッジ・デバイスで実行される。集中コントローラは、適合的なリアルタイム・サービスを構築するためにハンドラ使用を分散する、「プロファイル」と呼ばれる単純なメタサービスのセットを提供する。

Ｇ．Ｍａｉｅｒ、Ｆ．Ｓｃｈｎｅｉｄｅｒ、Ａ．Ｆｅｌｄｍａｎｎ、「Ａ Ｆｉｒｓｔ Ｌｏｏｋ ａｔ Ｍｏｂｉｌｅ Ｈａｎｄ−ｈｅｌｄ Ｄｅｖｉｃｅ Ｔｒａｆｆｉｃ」、Ｉｎ Ｐｒｏｃ．Ｉｎｔ．Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐａｓｓｉｖｅ ａｎｄ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ｍｅａｓｕｒｅｍｅｎｔ（ＰＡＭ ’１０）、２０１０年４月 Ｆ．Ｓｃｈｎｅｉｄｅｒ、Ｓ．Ａｇａｒｗａｌ、Ｔ．Ａｌｐｃａｎ、Ａ．Ｆｅｌｄｍａｎｎ、「Ｔｈｅ Ｎｅｗ Ｗｅｂ： Ｃｈａｒａｃｔｅｒｉｚｉｎｇ ＡＪＡＸ Ｔｒａｆｆｉｃ」、Ｉｎ Ｐｒｏｃ．Ｉｎｔ．Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐａｓｓｉｖｅ ａｎｄ Ａｃｔｉｖｅ Ｎｅｔｗｏｒｋ Ｍｅａｓｕｒｅｍｅｎｔ、２００８年４月 Ｇ．Ｂｉａｎｃｈｉ他、「Ａ Ｐｒｏｇｒａｍｍａｂｌｅ ＭＡＣ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｕｔｉｌｉｔｙ−Ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｓｕｐｐｏｒｔ」、ＩＥＥＥ ＪＯＵＲＮＡＬ ＯＮ ＳＥＬＥＣＴＥＤ ＡＲＥＡＳ ＩＮ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ、ＶＯＬ．１８、ＮＯ．２、２０００年２月 Ｊ．Ｈｕａｎｇ、Ｖ．Ｇ．Ｓｕｂｒａｍａｎｉａｎ、Ｒ．Ａｇｒａｗａｌ、およびＲ．Ａ．Ｂｅｒｒｙ、「Ｄｏｗｎｌｉｎｋ Ｓｃｈｅｄｕｌｉｎｇ ａｎｄ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＯＦＤＭ Ｓｙｓｔｅｍｓ」、ＩＥＥＥ Ｔｒａｎｓ． Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．８、２８８〜２９６頁、２００９年 Ｗｅｎ−Ｈｓｉｎｇ ＫｕｏおよびＷａｎｊｉｕｎ Ｌｉａｏ、「Ｕｔｉｌｉｔｙ−ｂａｓｅｄ ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＱｏＳ ｔｒａｆｆｉｃ ｉｎ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ」、ＩＥＥＥ Ｔｒａｎｓ． Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．７、２７１４〜２７２２頁、２００８年 Ｓ．ＳｈａｋｋｏｔｔａｉおよびＡ．Ｌ．Ｓｔｏｌｙａｒ、「Ｓｃｈｅｄｕｌｉｎｇ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ ａ Ｍｉｘｔｕｒｅ ｏｆ Ｒｅａｌ−Ｔｉｍｅ ａｎｄ Ｎｏｎ−Ｒｅａｌ−Ｔｉｍｅ Ｄａｔａ ｉｎ ＨＤＲ」、Ｐｒｏｃ．Ｉｎｔ．Ｔｅｌｅｔｒａｆｆｉｃ Ｃｏｎｇｒｅｓｓ（ＩＴＣ−１７）、２００１年 Ｆ．Ｋｅｌｌｙ、「Ｃｈａｒｇｉｎｇ ａｎｄ ｒａｔｅ ｃｏｎｔｒｏｌ ｆｏｒ ｅｌａｓｔｉｃ ｔｒａｆｆｉｃ」、Ｅｕｒｏ．Ｔｒａｎｓ．Ｔｅｌｅｃｏｍｍｓ．、ｖｏｌ．８、３３〜３７頁、１９９７年 ＮＧＭＮ Ａｌｌｉａｎｃｅ、「Ｒａｄｉｏ ａｃｃｅｓｓ ｐｅｒｆｏｒｍａｎｃｅ ｅｖａｌｕａｔｉｏｎ ｍｅｔｈｏｄｏｌｏｇｙ」、ｈｔｔｐ：／／ｗｗｗ．ｎｇｍｎ．ｏｒｇ／でオンラインで入手可能、２００７年６月 Ｊ．Ｎｉｅｌｓｅｎ、「Ｗｅｂｓｉｔｅ ｒｅｓｐｏｎｓｅ ｔｉｍｅｓ」、ｈｔｔｐ：／／ｗｗｗ．ｕｓｅｉｔ．ｃｏｍ／ａｌｅｒｔｂｏｘ／ｒｅｓｐｏｎｓｅ−ｔｉｍｅｓ．ｈｔｍｌ、２０１０年

諸実施形態は、アプリケーションＱｏＳ需要が、ユーザの現在の環境、たとえばその位置、速度、および他のユーザへの距離に依存する可能性があるという発見に基づく。諸実施形態は、アプリケーションおよびアプリケーショ状態固有メトリックを考慮に入れるより高度なスケジューリング概念の必要があるという発見に基づく。言い替えると、諸実施形態は、現代のＵＥに関して、ユーザのサービス品質（ＱｏＳ）が、その現在走行中のアプリケーションだけではなく、そのコンテキストにも依存するという発見に基づく。そのような条件の下であってもチャネル・リソースを効率的に割り振るために、諸実施形態は、無線ラジオ・リソース管理（省略形としてＲＲＭ）に関するコンテキスト情報を利用することができる。

諸実施形態は、さらに、コンテキスト情報に効率的にアクセスし、格納し、転送するために、トランザクションベースのアーキテクチャおよびデータ構造を介してコンテキスト情報を入手し、シグナリングすることができるという発見に基づくものとすることができる。さらに、諸実施形態は、無線リソースをユーザのコンテキストに従って割り振ることができるという発見に基づくものとすることができる。諸実施形態は、現在のアプリケーション混合物およびさらなるコンテキスト情報を考慮に入れながら、ＵＥにリソースを効率的に割り当てるためにスケジューリング概念を提供することができる。したがって、諸実施形態は、コンテキスト対応無線ネットワーク内でリソースにアクセスし、シグナリングし、割り振るのに完全にまたは部分的に使用できるリソース割当フレームワークを提供することができる。したがって、諸実施形態は、リソース割当、すなわちスケジューリングがユーザのコンテキストを知っている時に、より効率的なラジオ・リソース管理をモバイル通信システム内で達成できるという発見に基づくものとすることもできる。そのようなコンテキストを、ユーザの環境から抽出された情報およびそのような情報の組み合わせと定義することができる。

諸実施形態を、コンテキスト対応リソース割当（省略形としてＣＡＲＡ）と称することもでき、これらは、複数のコンポーネントを有するシステムを含むことができる。

諸実施形態は、モバイル通信システムまたはネットワーク内のモバイル・トランシーバのための装置を提供することができる。用語モバイル通信システムおよびモバイル通信ネットワークは、次では同義に使用される。そのような装置を、ＵＥまたはモバイル・トランシーバでコンテキスト情報を観察するコンテキスト抽出モジュールとして実施することができる。コンテキスト情報を、その後、トランザクションに基づいてトランスポートすることができ、このトランザクションは、走行中のアプリケーションごとに、単一のプロトコル・データ・ユニット内でデータ、トラフィック要件、および関連するシグナリング情報を組み合わせる。さらに、諸実施形態は、システム内のすべてのアプリケーションにまたがるリソース割振り問題を効率的に解決する対応するトランザクションベースのスケジューラを含むことができる、基地局トランシーバの装置を提供することができる。

諸実施形態は、ユーザのコンテキストを知っているスケジューリング概念を使用することによって、効率的なラジオ・リソース管理を可能にすることができる。諸実施形態は、アプリケーションの需要へのスケジューリングおよびリソース割振りの正確な調整を可能にすることができる。諸実施形態は、アプリケーションがその需要を変更する時またはこれらの需要を満足できない時の、スケジューラのすばやい反応を可能にすることができる。さらに、諸実施形態は、スケジューラ固有モデルまたはトラフィック・モデルとは独立の既存のＲＲＭ方式にコンテキスト・アウェアネスを統合することを可能にすることができる。

より具体的には、諸実施形態はモバイル通信システム内のモバイル・トランシーバのための装置を提供する、すなわち、諸実施形態は、モバイル・トランシーバによって操作されるかこれに含まれる前記装置を提供することができる。次では、この装置を、モバイル中継局トランシーバ装置とも称する。モバイル通信システムは、さらに、基地局トランシーバを含む。モバイル通信システムは、たとえば、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎの省略形として）、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄの省略形として）、ＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓの省略形として。ＵＭＴＳは、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍの省略形である）、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＴＲＡＮの省略形として）、ＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋの省略形として。ＧＳＭはＧｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎの省略形であり、ＥＤＧＥはＥｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎの省略形である）、一般にＯＦＤＭＡ（直交周波数分割多元接続（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）の省略形である）ネットワークなどの３ＧＰＰ標準化されたモバイル通信ネットワークのうちの１つに対応することができる。

モバイル・トランシーバ装置は、モバイル・トランシーバ上で走行するアプリケーションから、モバイル・トランシーバ上で走行するオペレーション・システムから、またはモバイル・トランシーバのハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出する手段であって、コンテキスト情報は、アプリケーションの状態に関する情報および／またはモバイル・トランシーバの状態に関する情報を含む、抽出する手段を含む。言い替えると、コンテキスト情報は、アプリケーションに関する情報を含むことができ、たとえば、ユーザ・フォーカスすなわちアプリケーションが現在フォアグラウンドまたはバックグラウンドのどちらに表示されているのかに関する情報、アプリケーションのタイプすなわちウェブ・ブラウジング、対話型、ストリーミング、会話型、その他に関する情報、要求のタイプすなわち要求されるデータがプリフェッチされるのみなのか即座に表示されるのかに関する情報、ある種の遅延またはＱＯＳ要件に関する情報、その他を含むことができる。

言い替えると、コンテキスト情報を、アプリケーションごとに提供することができる。たとえば、２つのストリーミング・アプリケーションが、モバイル・トランシーバ上で並列に走行しつつある。従来技術によれば、両方のアプリケーションのデータは、より下のレイヤでストリーミング・トランスポート・チャネルにマッピングされるはずである。したがって、従来技術によれば、２つのアプリケーションからのデータは、スケジューラによって区別されないはずである。諸実施形態によれば、コンテキスト情報を、アプリケーションについて別々に使用可能とすることができる。たとえば、一方のアプリケーションのコンテキスト情報は、そのアプリケーションがフォアグラウンドで表示されることを示すことができ、他方のアプリケーションのコンテキスト情報は、そのアプリケーションがバックグラウンドにあることを示すことができる。したがって、諸実施形態は、この２つのアプリケーションおよびそのデータを、スケジューラによって区別でき、フォアグラウンドで走行するアプリケーションに優先権を与えることができるという利益を提供することができる。コンテキスト情報を、オペレーション・システムから抽出することもできる。というのは、アプリケーションが、それがフォアグラウンドまたはバックグラウンドのどちらにあるのかに関する情報を有しない場合があるからである。この情報は、アプリケーションの状態をも決定し、モバイル・トランシーバのオペレーション・システムのウィンドウ・マネージャから抽出され得る。

さらに、モバイル・トランシーバ装置は、アプリケーションに関連するデータ・パケットを基地局トランシーバを介してデータ・サーバと通信する手段を含むことができる。言い替えると、モバイル・トランシーバは、データ・パケットを使用してデータ・サーバと通信するのに基地局トランシーバを使用する。これらのデータ・パケットを、両方向で、モバイル・トランシーバから基地局トランシーバへすなわちアップリンクでおよび基地局トランシーバからモバイル・トランシーバへすなわちダウンリンクで、送信し受信することができる。データ・スケジューリングに関して、ダウンリンク方向は、より人気があり、次の実施形態は、ダウンリンクに焦点を合わせて説明される。しかし、諸実施形態は、たとえばＥ−ＤＣＨ（Ｅｎｈａｎｃｅｄ−Ｄｅｄｉｃａｔｅｄ Ｃｈａｎｎｅｌの省略形として。Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓの省略形であるＨＳＵＰＡとも称する）を使用するＵＴＲＡＮのように、アップリンク・スケジューリングに関するコンテキスト・アウェアネスを提供することもできる。データ交換が、モバイル・トランシーバとデータ・サーバとの間で、モバイル通信ネットワークを介して実行されると仮定されることに留意されたい。したがって、データ・サーバは、たとえばデータ・ストレージ、パーソナル・コンピュータ、別のモバイル・トランシーバ、タブレット・コンピュータ、その他としての、任意の他の通信機器に対応することができる。基地局トランシーバとデータ・サーバとの間の無線インターフェースが、伝送チェーン内のボトルネックである可能性が高いので、無線インターフェースのスケジューリングは、全体的な伝送にとってクリティカルであり、したがって、ユーザ満足と、ＱＯＳ要件がそれぞれのサービスについて満足されるかどうかとを決定する。

さらに、モバイル・トランシーバ装置は、コンテキスト情報を基地局トランシーバに提供する手段を含む。コンテキスト情報を提供する手段を、基地局トランシーバへのシグナリング接続を使用してコンテキスト情報を提供するように適合させることができ、コンテキスト情報を提供する手段は、ダウンリンク送信に関するコンテキスト情報をアップリンク送信に含め、かつ、その逆を行うこともできる。諸実施形態では、コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ上で走行するアプリケーションのプロセッサ使用に関する情報、モバイル・トランシーバの現在位置、速度、方位、および／または別のモバイル・トランシーバへのモバイル・トランシーバの距離に関する情報を含むことができる。

データ・パケットのユニティは、たとえば複数のデータ・パケットが一緒に属することを示す情報を指すことができ、アプリケーションは、アプリケーションを表示するイメージに対応することができ、イメージ・データは、複数のデータ・パケットに含まれる。コンテキスト情報は、何個のデータ・パケットが１つのイメージを参照するのかを示すことができる。この情報を、スケジューラによって考慮に入れることができる。言い替えると、コンテキスト情報から、スケジューラは、データ・パケットの間のある種の関係を判定することができ、たとえば、ユーザは、イメージ全体が表示される場合に限って満足される可能性があり、したがって、そのイメージを参照するすべてのパケットが、穏当な時間間隔にモバイル・トランシーバに送信されなければならない。これを用いて、スケジューラが前もって計画することを可能にすることができる。

諸実施形態では、抽出する手段を、モバイル・トランシーバのオペレーション・システムからまたはモバイル・トランシーバ上で走行しつつあるアプリケーションから、コンテキスト情報を抽出するように適合させることができる。言い替えると、モバイル・トランシーバのオペレーション・システムは、たとえばアプリケーションの状態情報（フォアグラウンド／バックグラウンド、アクティブ／サスペンデッド、スタンバイ、その他）としてコンテキスト情報を提供することができる。もう１つのオプションは、アプリケーション自体がコンテキスト情報を提供することである。諸実施形態では、モバイル・トランシーバ装置は、さらに、トランザクション・データ・パケットを構成する手段をさらに含むことができ、トランザクション・データ・パケットは、アプリケーションからのデータ・パケットおよびコンテキスト情報を含むことができる。言い替えると、諸実施形態は、ペイロード・セクション内に複数のデータ・パケットを、制御セクション内にコンテキスト情報を有するプロトコルを使用することができる。

さらに、諸実施形態は、モバイル通信システム内の基地局トランシーバのための装置を提供することができる、すなわち、諸実施形態は、基地局トランシーバによって操作されまたはこれに含まれる前記装置を提供することができる。次では、この装置を、基地局トランシーバ装置とも称する。基地局トランシーバ装置は、モバイル・トランシーバ上で走行するアプリケーションに関連するデータ・パケットを受信する手段を含み、アプリケーションに関連するデータ・パケットに関するコンテキスト情報を入手する手段を含む。さらに、基地局トランシーバ装置は、コンテキスト情報に基づいてデータ・パケットの送信のためにモバイル・トランシーバをスケジューリングする手段を含む。上で説明したように、スケジューラまたはスケジューリングする手段は、コンテキスト情報を考慮に入れ、したがって、コンテキスト対応スケジューリングを実行する。

基地局トランシーバ装置の実施形態は、異なる形でコンテキスト情報を入手することができる。３つの例は、コンテキスト情報がモバイル・トランシーバから受信される、コンテキスト情報がデータ・サーバから受信される、またはコンテキスト情報がモバイル・トランシーバとデータ・サーバとの間で交換されるデータ・パケットをバイパスすることから、たとえば、データ・パケットをスニッフしまたは盗聴しまたはインスペクトすることによって判定される、である。言い替えると、諸実施形態では、入手する手段を、データ・パケットをインスペクトすることによって、モバイル・トランシーバからコンテキスト情報を受信することによって、および／またはデータ・サーバからコンテキスト情報を受信することによって、コンテキスト情報を入手するように適合させることができる。上で説明したように、コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ上で走行するアプリケーションのプロセッサ使用に関する情報、モバイル・トランシーバの現在位置、速度、方位、および／または別のモバイル・トランシーバへのモバイル・トランシーバの距離に関する情報を含むことができる。

さらに、スケジューリングする手段を、ユニティに関する情報が参照する複数のデータ・パケットのサービス品質要件が満足されるように、送信のためにモバイル・トランシーバをスケジューリングするように適合させることができる。言い替えると、スケジューラは、ユニティのすべてのデータ・パケットが間に合って送達され、したがって前もって計画される時に限って、ユーザ満足を達成できることを考慮に入れることができる。スケジューリングする手段を、複数のトランザクションの送信シーケンスを決定するように適合させることができ、トランザクションは、コンテキスト情報がそれに関するユニティを示す複数のデータ・パケットであり、複数のトランザクションは、１つまたは複数のモバイル・トランシーバによって走行される複数のアプリケーションを参照する。言い替えると、同一のアプリケーションから発する、すなわち、たとえばあるウェブ・ページのすべてのオブジェクトと同一の状態および要件を共有するデータ・パケットを、いわゆるトランザクションを形成する追加のコンテキスト情報と一緒に収集することができる。その後、トランザクションは、スケジューリング・クラスを決定するように働くことができる。すなわち、スケジューリングを、アプリケーションまたはトランザクションを基礎とするのではなく、ユーザを基礎として、たとえば、バッファ状態に基づいて実行することができる。その後、トランザクションを、ユーザ・レベルでのみ区別するのではなく、スケジューラによって区別することができる。ユーザまたはモバイル・トランシーバは、複数のアプリケーションについて複数のトランザクションを利用することができ、コンテキスト情報は、トランザクションごとに別々に入手され得る。

スケジューリングする手段は、効用関数に基づいてトランザクションのシーケンスの順序を判定することができ、効用関数は、コンテキスト情報に基づいて判定されるトランザクションの完了時刻に依存する。言い替えると、コンテキスト情報を、効用関数を使用して評価することができる。効用関数は、ユーザ満足の尺度とすることができ、したがって、トランザクションの完了時間に依存するものとすることができ、たとえば、ウェブ・ブラウジング・アプリケーションが要求したウェブ・ページのデータ・パケットを含むトランザクションについて、完了時間を、たとえば２ｓとすることができる。言い替えると、完全なユーザ満足は、ウェブ・ページのすべての内容が２ｓ未満で送信される時に達成することができる。そうでなければ、ユーザ満足およびそれに伴う効用関数は、劣化する。トランザクションのシーケンスを、諸実施形態で異なる形で判定することができる。いくつかの実施形態では、送信シーケンスは、トランザクションの複数の異なるシーケンスの反復から判定される。複数の異なるシーケンスは、複数のトランザクションの異なる置換に対応することができる。スケジューリングする手段を、複数の異なるシーケンスのそれぞれについて効用関数を判定するように適合させることができ、最大の効用関数に対応する複数の異なるシーケンスからの送信シーケンスを選択するようにさらに適合させることができる。言い替えると、諸実施形態では、スケジューリング判断を、最適化されたユーザ満足または効用関数に基づいて決定することができ、ここで、最適化を、シーケンスの制限されたセットに基づくものとすることができる。

いくつかの実施形態では、実際の送信シーケンスまたはスケジューリング判断を、さらに、特定のユーザのラジオ条件に基づくものとすることができ、たとえば、スケジューリングする手段を、トランザクションごとのサポート可能なデータ・レートに基づいて送信シーケンスをさらに変更するように適合させることができる。他の実施形態では、他の公平さ判断基準またはレートまたはスループット判断基準を考慮することができる。

さらに、諸実施形態は、データ・サーバのための装置を提供することができる、すなわち、諸実施形態は、データ・サーバによって操作されまたはこれに含まれる前記装置を提供することができる。次では、この装置を、データ・サーバ装置とも称する。データ・サーバは、モバイル・トランシーバ上で走行するアプリケーションに関連するデータ・パケットをモバイル通信システムを介してモバイル・トランシーバに通信することができる。データ・サーバ装置は、データ・パケットのコンテキスト情報を導出する手段と、データ・パケットと一緒にコンテキスト情報をモバイル通信システムに送信する手段とを含むことができる。言い替えると、データ・サーバ上のアプリケーションまたはオペレーション・システムを、モバイル・トランシーバ上のアプリケーションまたはオペレーション・システムへのコンテキスト情報提供に関する対の片方とすることができる。やはり、コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ上で走行するアプリケーションのプロセッサ使用に関する情報、などを含むことができる。導出する手段を、データ・サーバのオペレーション・システムからまたはデータ・サーバ上で走行するアプリケーションからコンテキスト情報を抽出するように適合させることができる。

諸実施形態では、データ・サーバ装置は、アプリケーションからのデータ・パケットおよびコンテキスト情報を含むデータ・パケットを構成する手段をさらに含むことができる。すなわち、データ・サーバは、トランザクション・プロトコルを終了することができる。したがって、データ・サーバ装置は、アプリケーションからのデータ・パケットおよびコンテキスト情報を含むことができるトランザクション・データ・パケットを構成する手段をさらに含むことができる。

諸実施形態は、対応する方法をさらに提供することができる。諸実施形態は、基地局トランシーバをさらに含むモバイル通信システム内のモバイル・トランシーバのための方法を提供することができる。この方法は、モバイル・トランシーバ上で走行するアプリケーションから、モバイル・トランシーバ上で走行するオペレーション・システムから、またはモバイル・トランシーバのハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出するステップであって、コンテキスト情報は、アプリケーションの状態に関する情報および／またはモバイル・トランシーバの状態に関する情報を含む、ステップを含む。この方法は、アプリケーションに関連するデータ・パケットを基地局トランシーバを介してデータ・サーバと通信するステップと、コンテキスト情報を基地局トランシーバに提供するステップとをさらに含む。

さらに、諸実施形態は、モバイル・トランシーバをさらに含むモバイル通信システム内の基地局トランシーバのための方法を提供することができる。この方法は、モバイル・トランシーバ上で走行するアプリケーションに関連するデータ・パケットを受信するステップと、アプリケーションに関連するデータ・パケットに関するコンテキスト情報を入手するステップとを含む。この方法は、コンテキスト情報に基づいてデータ・パケットの送信のためにモバイル・トランシーバをスケジューリングするステップをさらに含む。

さらに、諸実施形態は、データ・サーバの方法を提供することができる。データ・サーバは、モバイル・トランシーバ上で走行するアプリケーションに関連するデータ・パケットをモバイル通信システムを介してモバイル・トランシーバに通信する。この方法は、データ・パケットのコンテキスト情報を導出するステップと、データ・パケットと一緒にコンテキスト情報をモバイル通信システムに送信するステップとを含む。

諸実施形態は、上記のモバイル・トランシーバ装置を含むモバイル・トランシーバ、上記の基地局トランシーバ装置を含む基地局トランシーバ、上記のデータ・サーバ装置を含むデータ・サーバ、ならびに／またはモバイル・トランシーバ、基地局トランシーバ、および／もしくはデータ・サーバを含む通信システムをさらに提供することができる。

諸実施形態は、コンピュータ・プログラムがコンピュータまたはプロセッサ上で実行される時に上で説明した方法のうちの１つを実行するプログラム・コードを有するコンピュータ・プログラムをさらに含むことができる。

諸実施形態が、将来のトランザクションのチャネル品質またはサポート可能なデータ・レートを判定するチャネル推定手段またはチャネル予測手段を使用することができることに留意されたい。チャネル推定手段および／またはチャネル予測手段を、チャネル推定および／またはチャネル予測を現在のチャネル推定値、チャネル推定ヒストリすなわち以前のチャネル推定値、既知の伝搬条件または伝搬損失、ラジオ・チャネルに関する統計的知識、その他に基づくものにするように適合させることができる。

諸実施形態は、チャネル・リソースがアプリケーションによって必要とされない時にそのチャネル・リソースを解放することまたは要求される時に限ってアプリケーションに優先順位を付けることを可能にするラジオ・リソース管理を可能にするという利益を提供することができ、これは、チャネル・リソースが使用される効率を改善することができる。シミュレーションは、諸実施形態が、ＰＦ（Ｐｒｏｐｏｒｔｉｏｎａｌ Ｆａｉｒの省略形としての）制約の下または最小平均遅延制約（すなわち、Ｅａｒｌｉｅｓｔ Ｄｅａｄｌｉｎｅ Ｆｉｒｓｔの省略形としてのＥＤＦ）の下の現在のスケジューリング・ポリシより効率的にラジオ・リソースを利用できることを示した。ＰＦと比較して、７５％だけより高い負荷を、等しいＱｏＳでサポートすることができる。ＥＤＦと比較して、４６％だけより多くをサポートすることができる。

さらに、諸実施形態は、ＲＲＭおよびアプリケーションの柔軟性を高めることができる。現在のＲＲＭ方式とは異なって、遅延を、データ・レートとトレードオフすることができ、アプリケーションに、ＲＲＭ状況について知らせることができる。これは、ユーザの需要またはオペレータの需要に合わせてリソース使用量を調整することを可能にするだけではない可能性がある。これは、ＲＲＭおよびアプリケーションが、変化した条件（チャネル、負荷、トラフィック要件、ＵＥ能力）に反応することをも可能にすることができ、したがってＲＲＭおよびアプリケーション設計のより効率的な道を開くことができる。

いくつかの他の特徴または態様は、例としてのみ、添付図面を参照する、装置および／または方法および／またはコンピュータ・プログラムの次の非限定的な実施形態を使用して説明される。

諸実施形態を用いる通信システムを示す図である。 ＲＲＭシステムの基本構造を示す図である。 モバイル・トランシーバのための装置の実施形態および基地局トランシーバのための装置の実施形態を示すブロック図である。 モバイル・トランシーバのための装置の実施形態を示すブロック図である。 モバイル・トランシーバのための装置のもう１つの実施形態を示すブロック図である。 諸実施形態によって使用されるトランザクションを示す図である。 基地局トランシーバのための装置の実施形態を示すブロック図である。 一実施形態のスケジューリングの手段を示す図である。 異なる実施形態のシーケンス・ペナルティの相違を示すビュー・グラフを示す図である。 例示的な効用関数を示す図である。 総効用の変化の計算を示す図である。 平均和効用対トラフィック負荷のシミュレーション結果を示す図である。 平均セル・スループット対トラフィック負荷のシミュレーション結果を示す図である。 異なる回数の反復に関する平均トランザクション効用対トラフィック負荷のシミュレーション性能を示す図である。 データ・サーバのための装置の一実施形態を示すブロック図である。 モバイル・トランシーバの方法の一実施形態を示す流れ図である。 基地局トランシーバの方法の一実施形態を示す流れ図である。 データ・サーバの方法の一実施形態を示す流れ図である。

図１に、「トランザクション・マネージャ」としてもラベルを付けられたモバイル・トランシーバ装置１０と、モバイル・トランシーバ１００上で実行されつつある複数のアプリケーション１１とを含むモバイル・トランシーバ１００の実施形態を有する通信システム５００を示す。さらに、図１に、「ＣＡＲＡスケジューラ」としてもラベルを付けられた基地局トランシーバ装置２０と、データ・バッファまたはデータ・プロキシ２１とを有する基地局トランシーバ２００を示す。基地局トランシーバ２００は、インターネット４００への接続を有し、インターネット４００は、データ・サーバ装置３０を有するデータ・サーバ３００に接続する。図１に示されているように、データ伝送は、モバイル・トランシーバ１００とデータ・サーバ３００との間で、基地局トランシーバ２００およびインターネット４００を介して実行される。さらに、コンテキスト情報シグナリングが、モバイル・トランシーバ１００と基地局トランシーバ２００との間で確立される。一実施形態では、コンテキスト情報は、アプリケーション１１によってモバイル・トランシーバ装置１０に供給される。通信システム５００のコンポーネントに関するさらなる詳細を提供する前に、スケジューリングまたはＲＲＭシステムに関するいくつかの基本的な定義および概念を示す。

ＲＲＭシステム６００の基本的な構造を、図２に示す。図２に示されているように、このシステムは、リソース割振りコンポーネント６０２、重み計算コンポーネント６０４、およびスケジューリング・コンポーネント６０６を含む。セルラ・ネットワークまたはモバイル通信システム５００では、リソース割振りは、各基地局トランシーバ２００（省略形としてＢＳ）で実行される。ラジオ・リソースは、実際のデータが前記割り当てられたまたは割り振られたラジオ・リソースを使用して送信される前に、データ伝送のためにモバイル・トランシーバ１００に割り当てられる。基地局トランシーバ２００は、ｓ＝１，…，Ｓのサブセットを割り当て、ここで、Ｓは、ラジオ・リソースまたは物理リソース・ブロック（省略形としてＰＲＢ）のフル・セットを表し、各アクティブＵＥ ｊ＝１，…，Ｊまたは移動局トランシーバ１００にＰＲＢを割り当てる。その後、スケジューラ６０２は、現在の時間フレーム内で働くべきＵＥのサブセットを選択する。これらの割当およびスケジューリング判断を行うために、ＲＲＭシステムは、複数の要因を考慮に入れることができる。たとえば、各任意のＵＥ １００ ｊおよび各任意のＰＲＢ ｓのＣｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ（省略形としてＣＱＩ）によって反映される瞬間チャネル状態γ_ｊ，ｓを、モバイル・トランシーバ１００から基地局トランシーバ２００へリソース割振り６０２のために提供することができる。もう１つの要因は、グローバル公正さパラメータα、効用関数Ｕ_ｊ（．）、およびＱｏＳ重みｃ_ｊ、たとえば図２の重み計算６０４によって反映される、いわゆる公正さである。スケジューラ６０６は、その後、重みに基づいて実際の割振りを決定する。

諸実施形態は、その主な操作単位がデータ・レートではない可能性があるという利益を提供することができる。目的関数およびデータ・レートにおける制約の例を、Ｊ．Ｈｕａｎｇ、Ｖ．Ｇ．Ｓｕｂｒａｍａｎｉａｎ、Ｒ．Ａｇｒａｗａｌ、およびＲ．Ａ．Ｂｅｒｒｙ、「Ｄｏｗｎｌｉｎｋ Ｓｃｈｅｄｕｌｉｎｇ ａｎｄ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＯＦＤＭ Ｓｙｓｔｅｍｓ」、ＩＥＥＥ Ｔｒａｎｓ． Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．８、２８８〜２９６頁、２００９年、Ｗｅｎ−Ｈｓｉｎｇ ＫｕｏおよびＷａｎｊｉｕｎ Ｌｉａｏ、「Ｕｔｉｌｉｔｙ−ｂａｓｅｄ ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＱｏＳ ｔｒａｆｆｉｃ ｉｎ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ」、ＩＥＥＥ Ｔｒａｎｓ． Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．７、２７１４〜２７２２頁、２００８年、Ｓ．ＳｈａｋｋｏｔｔａｉおよびＡ．Ｌ．Ｓｔｏｌｙａｒ、「Ｓｃｈｅｄｕｌｉｎｇ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ ａ Ｍｉｘｔｕｒｅ ｏｆ Ｒｅａｌ−Ｔｉｍｅ ａｎｄ Ｎｏｎ−Ｒｅａｌ−Ｔｉｍｅ Ｄａｔａ ｉｎ ＨＤＲ」、Ｐｒｏｃ．Ｉｎｔ．Ｔｅｌｅｔｒａｆｆｉｃ Ｃｏｎｇｒｅｓｓ（ＩＴＣ−１７）、２００１年、およびＦ．Ｋｅｌｌｙ、「Ｃｈａｒｇｉｎｇ ａｎｄ ｒａｔｅ ｃｏｎｔｒｏｌ ｆｏｒ ｅｌａｓｔｉｃ ｔｒａｆｆｉｃ」、Ｅｕｒｏ．Ｔｒａｎｓ．Ｔｅｌｅｃｏｍｍｓ．、ｖｏｌ．８、３３〜３７頁、１９９７年に見出すことができる。

目的関数および帯域幅における制約の例を、Ｇ．Ｂｉａｎｃｈｉ ａｎｄ Ａ．Ｔ．Ｃａｍｐｂｅｌｌ、「Ａ ｐｒｏｇｒａｍｍａｂｌｅ ＭＡＣ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｕｔｉｌｉｔｙ−ｂａｓｅｄ ａｄａｐｔｉｖｅ ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ ｓｕｐｐｏｒｔ」、ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎ．、ｖｏｌ．１８、２４４〜２５５頁、２０００年に見出すことができる。これらの目的関数および制約を、コンテキスト・アウェアネスに加えて諸実施形態で適用することができる。従来のリソース割振り方式は、ＵＥの遅延要件または誤り率要件を直接に考慮に入れていない場合がある。そのような要件は、平均データ・レートに人工的に変換することができ、この平均データ・レートは、バースト性のトラフィックに関して悪い統計的表現になる可能性がある。これは、ある種の遅延またはデータ・レートを保証するレートベースのリソース割振り方式を設計することをむずかしくする。

さらに、諸実施形態は、その例をＧ．ＢｉａｎｃｈｉおよびＡ．Ｔ．Ｃａｍｐｂｅｌｌ、「Ａ ｐｒｏｇｒａｍｍａｂｌｅ ＭＡＣ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｕｔｉｌｉｔｙ−ｂａｓｅｄ ａｄａｐｔｉｖｅ ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ ｓｕｐｐｏｒｔ」、ＩＥＥＥ Ｊｏｕｒｎａｌ ｏｎ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｏｍｍｕｎ．、ｖｏｌ．１８、２４４〜２５５頁、２０００年とＷｅｎ−Ｈｓｉｎｇ ＫｕｏおよびＷａｎｊｉｕｎ Ｌｉａｏ、「Ｕｔｉｌｉｔｙ−ｂａｓｅｄ ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＱｏＳ ｔｒａｆｆｉｃ ｉｎ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ」、ＩＥＥＥ Ｔｒａｎｓ．Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．７、２７１４〜２７２２頁、２００８年とに見出すことができる、効用関数を調整すること、またはたとえばＳ．ＳｈａｋｋｏｔｔａｉおよびＡ．Ｌ．Ｓｔｏｌｙａｒ、「Ｓｃｈｅｄｕｌｉｎｇ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ ａ Ｍｉｘｔｕｒｅ ｏｆ Ｒｅａｌ−Ｔｉｍｅ ａｎｄ Ｎｏｎ−Ｒｅａｌ−Ｔｉｍｅ Ｄａｔａ ｉｎ ＨＤＲ」、Ｐｒｏｃ．Ｉｎｔ．Ｔｅｌｅｔｒａｆｆｉｃ Ｃｏｎｇｒｅｓｓ（ＩＴＣ−１７）、２００１年に例示されている、特定のＵＥに関してＱｏＳ重みを調整することのいずれかによって、トラフィック要件をさらに考慮することができる。

アプリケーションではなくＵＥに優先権を与えることによって、これらの方式は、一時に１つのＵＥ１００のすべてのアプリケーションに優先順位を付けることだけができる。その結果、これらの方式は、単一のアプリケーションまたはアプリケーションのサブセットに別々に優先順位を付けることができない。ＵＥ１００がマルチタスキング・オペレーション・システムを走行させる時に、このＵＥは、その需要がお互いと基本的に異なる複数のアプリケーションを並列に走行させることができ、これは、従来のシステムでは考慮することができない。

さらに、従来のＲＲＭシステムは、コンテキスト対応ではない。諸実施形態は、たとえば、ＵＥ１００上で現在走行している各アプリケーションの負荷需要、ＵＥ１００上で現在走行している各アプリケーションの遅延制約もしくは誤り率制約、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ１００上で走行するアプリケーションのプロセッサ使用に関する情報、ならびに／またはＵＥの現在位置、速度、方位、および他のユーザへの距離など、追加のコンテキスト情報が考慮されるという利益を提供することができる。

このコンテキスト情報へのアクセスを有するので、諸実施形態のスケジューラは、ユーザの現在のコンテキストに対してリソース割振りを最適化することができる。諸実施形態は、コンテキスト対応手法を使用することができ、それと共に、従来の概念のＱｏＳより高いＱｏＳを提供し、諸実施形態は、これを達成し、リソースのより効率的な使用を可能にすることができる。

通常のスケジューリング手法は、ＰＨＹ（物理層またはレイヤ１の省略形としての）データ・レートの関数である効用関数Ｕ_ｊ（．）を最大化することを目指す。そのようなスケジューラは、図２に示され、主に、入力ＣＱＩ γ_ｊ，ｓ、ｃ_ｊ、およびαを有する。Ｊ×Ｓ ＣＱＩ行列Ｙ（Ｓは、チャネル・インデックスを表す）に基づいて、リソース割振り６０２は、ＰＲＢを割り当て、ＵＥごとすなわちモバイル・トランシーバごとの結果のＰＨＹレートｒ_ｊを重み計算コンポーネント６０４に提供する。これらのレートおよびＵＥ固有の重みｗ_ｊに基づいて、スケジューラ６０６は、Ｊ個すべてのユーザにまたがって荷重和レートを最大化することを目指す。最適の解決策は、凸最適化によって得ることができ、その例は、Ｊ．Ｈｕａｎｇ、Ｖ．Ｇ．Ｓｕｂｒａｍａｎｉａｎ、Ｒ．Ａｇｒａｗａｌ、およびＲ．Ａ．Ｂｅｒｒｙ、「Ｄｏｗｎｌｉｎｋ Ｓｃｈｅｄｕｌｉｎｇ ａｎｄ Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｉｏｎ ｆｏｒ ＯＦＤＭ Ｓｙｓｔｅｍｓ」、ＩＥＥＥ Ｔｒａｎｓ．Ｗｉｒｅｌｅｓｓ Ｃｏｍｍｕｎ．、ｖｏｌ．８、２８８〜２９６頁、２００９年に見出すことができ、実際には、ヒューリスティックが、制限された計算リソースを用いてこの最適化問題をすばやく解くのに使用される。その結果を、Ｊ個の２進項を有する割振りベクトルによって表すことができる。

ＵＥ固有重みｗ_ｊは、公正さ制約およびＱｏＳ制約を考慮することができ、これを、大域公正さパラメータαおよびＵＥ固有ＱｏＳ重みｃ_ｊに基づいて計算することができる。異なる公正さモードは、通常、たとえば、任意のユーザｊの平均ＰＨＹレート

に基づく

として、厳密に凹の効用関数によって反映される。ｒ_ｊでのこの効用関数の導関数Ｕ_ｊ’をとると、任意のユーザｊの重み

がもたらされる。

α＝１について、効用関数（１）が、最大レート・スケジューリングを表すことを示すことは簡単であり、α＝０が、広く使用されるｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒスケジューリング・ルールをもたらすことが、
Ｆ．Ｋｅｌｌｙ、「Ｃｈａｒｇｉｎｇ ａｎｄ ｒａｔｅ ｃｏｎｔｒｏｌ ｆｏｒ ｅｌａｓｔｉｃ ｔｒａｆｆｉｃ」、Ｅｕｒｏ．Ｔｒａｎｓ．Ｔｅｌｅｃｏｍｍｓ．、ｖｏｌ．８、３３〜３７頁、１９９７年によって証明された。スケジューリング拡張の第１実施形態は、ｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒｎｅｓｓに基づくので、この方式の基礎を、重み計算６０４から始めて、次で詳細に説明する。

ｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒスケジューリングは、その平均レート

に関する最大瞬間ＰＨＹレートｒ_ｊを有するユーザにチャネルを割り振る。このために、ユーザｊのｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒスケジューリング重みｗ_ｊは、

であり、ここで、

は、通常、指数移動平均

として計算され、βは、忘却因子であり、オペレータによって選択され収束率を決定する、０と１との間のパラメータである。

諸実施形態は、ＱｏＳを改善する、またはアプリケーションのＱｏＳ制約を保ちながらチャネル・リソースを効率的に割り振るのいずれかのために、コンテキスト情報（ＣＩ）を使用してコンテキスト対応リソース割振り（ＣＡＲＡ）を利用することができる。図３に、モバイル・トランシーバ１００のための装置１０の実施形態および基地局トランシーバ２００のための装置２０の実施形態のブロック図を示す。図３は、コンテキスト対応リソース割振り（ＣＡＲＡ）の主アーキテクチャを示す。図３は、モバイル・トランシーバ１００上で参照されるＪ個のＵＥを示す。諸実施形態では、複数のモバイル・トランシーバおよびアプリケーションを、基地局トランシーバ２００によるスケジューリングのために考慮することができる。モバイル・トランシーバ１００は、モバイル・トランシーバ装置１０の実施態様であるトランザクション・マネージャおよびコンテキスト抽出モジュール１０を含む。トランザクション・マネージャを使用して、コンテキスト情報（ＣＩ）を転送することができる。

さらに、図３は、モバイル・トランシーバ１００の、アプリケーション１１、オペレーション・システム１３、および他のハードウェア１５を示す。基地局トランシーバは、基地局トランシーバ２００の装置２０を含み、装置２０は、「ＣＡＲＡ ＲＲＭ」モジュール２０としてラベルを付けられ、データ・パケット用のキュー２１と相互作用する。さらに、図３は、より下の層のプロトコル２３すなわちリンク層コントロール（省略形はＬＬＣ）およびＰＨＹを示し、このより下の層のプロトコル２３は、ＣＱＩを装置２０に提供する。この実施形態では、トランザクションは、基地局トランシーバ（ＢＳ）２００のコンテキスト対応ラジオ・リソース管理（ＲＲＭ）方式２０にコンテキスト情報（ＣＩ）を提供するのに使用される。

ＵＥ１００では、コンテキスト抽出モジュール（ＣＥＭ）と称する場合もあるモバイル・トランシーバ装置１０が、ＣＩを収集し、処理し、そのＣＩが、その後あるトランザクション内でＢＳ２００に転送される。ＢＳ２００では、基地局トランシーバ装置２０によって実行されるＣＡＲＡ方式が、ＣＩおよびさらなる情報を使用して、リソースをユーザのアプリケーションに割り当てる。その後、制御チャネルを使用して、これらの割当をＵＥ１００にシグナリングすることができる。

図４に、モバイル・トランシーバ装置１０の実施形態のブロック図を示す。装置１０は、モバイル・トランシーバ１００上で走行しつつあるアプリケーション、モバイル・トランシーバ１００上で走行しつつあるオペレーション・システム、またはモバイル・トランシーバ１００のハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出する手段１２を含み、コンテキスト情報は、アプリケーションの状態に関する情報および／またはモバイル・トランシーバ１００の状態に関する情報を含む。装置１０は、さらに、アプリケーションに関連するデータ・パケットを、基地局トランシーバ２００を介してデータ・サーバ３００と通信する手段１４を含む。この装置は、さらに、基地局トランシーバ２００にコンテキスト情報を提供する手段１６を含む。コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ上で走行するアプリケーションのプロセッサ使用に関する情報、ならびに／またはモバイル・トランシーバ１００の現在位置、速度、方位、および／もしくは別のモバイル・トランシーバへのモバイル・トランシーバ１００の距離に関する情報を含むことができる。

モバイル・トランシーバ装置１０は、ＣＥＭとして実現することができるが、ＵＥ１００のオペレーション・システム（省略形はＯＳ）またはＵＥ１００上で走行するアプリケーションに統合され得る。言い替えると、抽出する手段１２を、モバイル・トランシーバ１００のオペレーション・システムからまたはモバイル・トランシーバ１００上で走行するアプリケーションからコンテキスト情報を抽出するように適合させることができる。ＯＳへのそのような抽出の統合を、ＯＳカーネルのモジュールとして実現することができる。そのような実装を、ハードウェア・ドライバのためにサポートすることもでき、そのような実装を、多数のＯＳおよび関連する開発フレームワークによってサポートすることができる。カーネル・モジュールとしてＣＥＭを実装する実施形態は、ＣＥＭが、システム呼出を介して、ＯＳスケジューラ、ウィンドウ・マネージャ、メモリ管理、およびネットワーク・スタックなどのカーネル機能または他のカーネル・モジュールと直接に通信できるという利益を提供することができる。

図５に、ＯＳカーネル１３からコンテキスト情報を抽出するモバイル・トランシーバ１００のための装置１０の実施形態のブロック図を示す。図５は、ＣＥＭとして実現された装置１０、プロセッサ・スケジューラ１３ａ、メモリ管理１３ｂ、およびネットワーク・スタック１３ｃを有するＯＳカーネル１３を示す。システム呼出を、プロセッサ・スケジューラ１３ａ、ＣＥＭ１０、およびメモリ管理１３ｂの間で交換することができる。さらなるシステム呼出を、ネットワーク・スタック１３ｃ、ＣＥＭ１０、およびメモリ管理１３ｂの間で交換することができる。すべてのＯＳコンポーネントは、ハードウェア１５と相互作用し、それぞれの割振りを割り当てることができる。ＣＥＭ１０は、システム呼出をアプリケーションと交換し、対応するコンテキスト情報を提供することができる。

システム呼出を、ＯＳごとに公開のデファクト・スタンダードである、すなわち、ＣＥＭ１０によってアクセス可能であり、したがって、ＣＥＭ１０によって使用可能であると仮定することができる。たとえば、ＣＥＭ１０すなわちモバイル・トランシーバ１００のための装置１０は、プロセッサ・スケジューラ１３ａおよびウィンドウ・マネージャからのシステム呼出を観察して、どのアプリケーションが、現在、処理サイクルを消費すると同時に、ＯＳ１３内でフォアグラウンドで走行しつつあるのかを抽出することができる。これによって、ＣＥＭ１０は、基地局トランシーバ２００でどのアプリケーションが現在ＱｏＳ優先権を必要とするのかを抽出する。

アプリケーション・レベルでのＣＥＭまたは装置１０の統合を、アプリケーション・プログラミング・インターフェース（省略形はＡＰＩ）を介して統一することができる。ほとんどのＯＳベンダは、そのようなＡＰＩを提供し、そのインターフェースを公表している。具体的には、ＣＥＭ１０を、そのソース・コードが未知である可能性があっても、ＡＰＩのプログラミング・ライブラリの一部とし、これによって、そのインターフェース（機能呼出またはメソッド呼出）の一部とすることができる。ソフトウェア実装では、ＣＥＭ１０のオブジェクト・コードを、静的にまたは動的にアプリケーションにリンクすることができる。これは、各アプリケーションの内部パラメータへのアクセスを単純化するはずであるが、他のアプリケーションまたはＯＳ機能の観察を複雑にする可能性がある。ＣＥＭ１０ライブラリにリンクされない機能またはアプリケーションを、間接的に観察することができる。これは、カーネル・モジュールとしてのＣＥＭ１０の実装を、追加の利点を有する実施形態にする。

諸実施形態では、モバイル・トランシーバ１００のための装置１０は、トランザクション・データ・パケットを構成する手段をさらに含み、トランザクション・データ・パケットは、アプリケーションからのデータ・パケットおよびコンテキスト情報を含む。言い替えると、トランザクションは、ＵＥ１００上のアプリケーション１１と、たとえば図１ではデータ・サーバ３００の実施態様である別のＵＥ３００上またはコンピューティング・センタ３００内で走行するアプリケーションまたはサーバ・プログラムとの間のすべての通信を含むプロトコル・データ・ユニットに対応することができる。トランザクション・データ・パケットは、アプリケーションの１つのサービス・プロセスのすべてのデータ・パケットを含むことができる。たとえば、単一のウェブ・ページに関係するすべてのパケットを、このウェブ・ページがそれからなるオブジェクトの個数に関わりなく含めることができる。トランザクション・データ・パケットは、１つのサービス・プロセスに関係するすべてのシグナリング情報を含むことができる。具体的には、トランザクション・データ・パケットは、サービス・プロセスを開始し、終了する、開始するメッセージを含むことができる。ＴＣＰ（伝送制御プログラムを省略）とは異なって、そのような開始は、アプリケーション・レベルで実行することができ、基礎になるＭＡＣまたはＰＨＹに固有の情報（たとえば、特定のＢＳ２００ベンダによってサポートされるＱｏＳクラス）を含むことができる。さらに、このメッセージは、ネットワーク・コンポーネントのＭＡＣおよびＰＨＹのインターフェースを含むことができる。たとえば、ＵＥ１００およびＢＳ２００は、トランザクション内の指定されたデータ・フィールドにアクセスして、たとえばアプリケーションの遅延制約またはトラフィック・プロファイルなど、アプリケーション情報を抽出することができる。

これによって、トランザクションまたはトランザクション・データ・パケットは、アプリケーションに透過的でありながらコンテキスト対応ＲＲＭを実行するためのインターフェースおよび情報を提供することができる。トランザクションの実施態様の例を、図６に示す。図６は、ＩＰレベルで実施される２つの例のトランザクションＴ_１およびＴ_２を示す。トランザクションＴ_１、Ｔ_２の例の実施態様は、２つのアプリケーションＡ_１、Ａ_２について示され、各トランザクションは、「Ｉｎｉｔ」パケットで始まり、任意の位置で送信できる任意の個数のデータ・パケットおよび「ＳＩＧ」（シグナリングの省略形としての）パケットを含む。トランザクションを、「Ｔｅｒｍ」パケットを用いて能動的に終了するか、タイムアウトによって受動的に終了することができる。各アプリケーションが、任意の個数のトランザクションを開始することができ、ＵＥ１００およびデータ・サーバ３００などのネットワーク・コンポーネントが、トランザクションにＳＩＧパケットおよびデータ・パケット「Ｄ」を追加できることに留意されたい。

図６は、縦座標上に２つの異なるアプリケーションＡ_１およびＡ_２、横座標上に時間を有するビュー・グラフを示す。２つのトランザクションのコンポーネントは、ラベルを付けられたブロックによって示される。アプリケーション・データ・ブロックは、「Ｄ_ｊ」のラベルを付けられ、インデックスは、データ・パケットのシーケンスのカウンタに対応する。各アプリケーションは、「Ｉｎｉｔ」シグナル、たとえば図６の対応するラベルを付けられたブロックによって示されるように、ＩＰパケット・フィールド内に「Ｉｎｉｔ」メッセージを有するＩＰパケットを送信することによって、トランザクションを開始することができる。トランザクションを、図６のトランザクションＴ_１の「Ｔｅｒｍ」というラベルを付けられたブロックによって示されるように「Ｔｅｒｍ」シグナルによって能動的に終了することができ、または、図６のＴ_２について仮定されるように、タイムアウトによって受動的に終了することができる。そのようなタイムアウトを、システム定数とすることができ、あるいは、トランザクションの「Ｉｎｉｔ」シグナルまたは「ＳＩＧ」シグナル内に含めることができる。他の制御情報およびＣＩを、対応してラベルを付けられた「Ｉｎｉｔ」シグナルまたは「ＳＩＧ」シグナル内に含めることができる。ＳＩＧシグナルは、いつでも現れることができ、トランザクションをサポートする各ネットワーク・デバイスによって追加され得る。たとえば、コンテキスト対応ＢＳ２００のＭＡＣ（媒体アクセス制御を省略）は、ＳＩＧを使用して、ＵＥ１００のアプリケーション１１に、そのデータ・レート需要を満足できないことを知らせることができる。その後、アプリケーション１１は、「Ｔｅｒｍ」を用いて答えるか、より低いデータ・レートでトランザクションを継続するために沈黙したままになることができる。

図７に、モバイル通信システム５００内のモバイル・トランシーバ２００の装置２０の実施形態のブロック図を示す。装置２０は、モバイル・トランシーバ１００上で走行しつつあるアプリケーションに関連するデータ・パケットを受信する手段２２と、アプリケーションに関連するデータ・パケットに関するコンテキスト情報を入手する手段２４とを含む。装置２０は、さらに、コンテキスト情報に基づいてデータ・パケットの送信のためにモバイル・トランシーバ１００をスケジューリングする手段２６を含む。入手する手段２４を、データ・パケットをインスペクトすることによって、モバイル・トランシーバ１００からコンテキスト情報を受信することによって、および／またはデータ・サーバ３００からコンテキスト情報を受信することによって、コンテキスト情報を入手するように適合させることができる。

やはり、前記コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ１００上で走行するアプリケーションのプロセッサ使用に関する情報、モバイル・トランシーバ１００の現在位置、速度、方位、および／もしくは別のモバイル・トランシーバへのモバイル・トランシーバ１００の距離に関する情報を含むことができる。さらに、スケジューリングする手段２６を、ユニティに関する情報が参照する複数のデータ・パケットのサービス品質要件が満足されるように、送信のためにモバイル・トランシーバ１００をスケジューリングするように適合させることができる。

スケジューリングする手段２６を、複数のトランザクションの送信シーケンスを判定するように適合させることができる。トランザクションは、コンテキスト情報がユニティを示す複数のデータ・パケットに対応することができ、複数のトランザクションが、１つまたは複数のモバイル・トランシーバ１００によって走行されつつある複数のアプリケーションを参照することができる。トランザクションのシーケンスの順序を、効用関数に基づくものとすることができる。効用関数は、コンテキスト情報に基づいて決定されるトランザクションの完了時刻に依存するものとすることができる。

言い替えると、諸実施形態では、コンテキスト対応ＲＲＭ方式は、各トランザクションに重みを割振り、最高の重みを有するトランザクションをスケジューリングすることができる。時間変動するチャネル需要およびアプリケーション需要に追随するために、重みおよびスケジュールが、周期的に、たとえば送信時間間隔（省略形はＴＴＩ）ごとに１回更新されると仮定することができる。それと共に、諸実施形態は、トランザクションに基づいてスケジューリングすることができ、データ・レートではなく時間で動作することができ、スケジューリングの前に有益なまたは改善されたスケジューリング・シーケンスを判定することができる。

図８に、一実施形態のスケジューリングの手段２６をより詳細に示す。Ｊ個のトランザクションのコンテキスト情報（ＣＩ）が、コンテキスト対応ＲＲＭのために使用される。これを、現在のＣＩに従って効用を最大化するシーケンスを判定する関数またはコンポーネント２６ｃと、関数に従って最終的なスケジューリング重みを計算するコンポーネントまたは関数２６ｄおよび／または従来の重みとに基づくものとすることができる。

図８は、スケジューリングする手段２６を示し、このスケジューリングする手段２６は、リソース割振りコンポーネント２６ａ、重み計算コンポーネント２６ｂ、ＣＡＲＡシーケンス判定コンポーネント２６ｃ、ＣＡＲＡ重み計算コンポーネント２６ｄ、およびスケジューリング・コンポーネント２６ｅを含む。図８で与えられるパラメータは、図２と同一の量を表す。図８に示され、図２と比較される時に、諸実施形態は、２つの追加のコンポーネント２６ｃおよび２６ｄまたは関数を追加することができる。第１のコンポーネント２６ｃは、ＣＡＲＡシーケンスとも呼ばれ、和効用関数を最大化することを目指す、トランザクションのシーケンスを判定する。第２の関数またはコンポーネント２６ｄは、ＣＡＲＡシーケンスおよび従来通りに計算されたスケジューリング重みに基づいて最終的なスケジューリング重みを計算する。結果の重みは、スケジューラ２６ｅに渡される。

第１の関数またはコンポーネント２６ｃを、スケジューラ設計とは独立とすることができ、下で説明する。第２の関数またはコンポーネント２６ｄについて、コンテキスト・アウェアネスをさまざまな既存のスケジューラに統合することができる２つの実施形態を説明する。上で既に述べたように、ＣＩを使用することによって和効用を最大化することを目指すトランザクションのシーケンスを判定することができる。言い替えると、トランザクション・シーケンスを、トランザクションの複数の異なるシーケンスの反復から判定することができ、複数の異なるシーケンスは、複数のトランザクションの異なる置換に対応する。スケジューリングする手段２６を、複数の異なるシーケンスのそれぞれについて効用関数を判定するように適合させることができ、さらに、最大の効用関数に対応する複数の異なるシーケンスからのトランザクション・シーケンスを選択するように適合させることができる。

より具体的には、実施形態で、あるトランザクションが必ず全体として処理されなければならないという制約を使用することができる。これは、可能な組み合わせの個数を実質的に減らし、したがって計算の複雑さを減らすことができる。図８のシーケンス判定コンポーネント２６ｃは、次のように動作することができる。

シーケンス判定コンポーネント２６ｃは、第１ステップで、任意のトランザクション・シーケンスＳ_１＝｛Ｔ_１１，Ｔ_１２，…｝から開始することができ、Ｔ_ｉｊは、シーケンスｉ内のインデックスｊのトランザクションである。Ｎは、トランザクションの総数である。ｒ_ｊ（ｔ）は、ビット単位の推定されたＰＨＹ容量であり、トランザクションｊは、タイム・スロットｔに送信することができ、Ｕ_ｊ（ｔ）は、トランザクションｊが、時刻ｔに終了する場合に達成する効用である。その後、第２ステップで、判定コンポーネント２６ｃは、次のようにＳ_１の総効用Ｕ_１を判定することができる。
Ｒ_ｊ ：＝ トランザクション_ｊの残りのビット
ｔ ：＝ 現在のタイム・スロット
ｊ ：＝ １
Ｕ ：＝ ０
＃ すべてのトランザクションについて
ｗｈｉｌｅ ｊ ＜＝ Ｎ ｄｏ
Ｒ_ｊ＝Ｒ_ｊ−ｒ_ｊ（ｔ）
＃ 送信すべきビットがもうない
ｉｆ Ｒ_ｊ ＜＝ ０ ｔｈｅｎ
Ｕ ＝ Ｕ ＋ Ｕ_ｊ（ｔ）
ｊ ＝ ｊ ＋ １
ｅｎｄ ｉｆ
ｔ ＝ ｔ ＋ ＴＴＩ
ｅｎｄ ｗｈｉｌｅ
ｒｅｔｕｒｎ Ｕ
すなわち、シーケンスごとの和効用を入手するためにシーケンス内のすべてのトランザクションのすべての効用を足し合わせることによって。次に、第３ステップで、シーケンスＳ_１を突然変異させて、次の関数を用いてシーケンスＳ_２を入手する。
２つの任意のインデックスｘおよびｙ∈｛１，…，Ｎ｝を選択する
Ｔ１ｘをシーケンスＳ２内のＴ２ｙに移動する
Ｓ１の（ｘ，ｙ］内のすべてのトランザクションをＳ２内のｘに向かってシフトする

さらに、Ｓ_２の総合計効用Ｕ_２を、第２ステップと同様に第４ステップで計算することができる。その後、第５ステップで、次のように反復の事前定義の回数ｋだけ、この手順を繰り返すことができる。
Ｓ_１を選択し、Ｕ_１を判定する
＃ ｋ回の反復について繰り返す
ｆｏｒ ｉ ＝ １ ｔｏ ｋ ｄｏ
Ｓ_２ ＝ 突然変異（Ｓ_１）
Ｕ_２を判定する
＃ 新しいシーケンスは、より高い効用を有する
ｉｆ Ｕ_２ ＞ Ｕ_１ ｔｈｅｎ
Ｓ_１ ＝ Ｓ_２
Ｕ_１ ＝ Ｕ_２
ｅｎｄ ｉｆ
ｅｎｄ ｆｏｒ
ｒｅｔｕｒｎ Ｓ_１， Ｕ_１

言い替えると、置換の中で最大の効用関数を有するシーケンスが、検索される。その結果は、トランザクションがこの順序でスケジューリングされる時に、最大の和効用に近い値に達する順序付けられたトランザクションのシーケンスＳ_１である。最大の効用（すなわち、最適値）には、実際には達しない。というのは、計算時間すなわち反復の回数ｋが制限されているからである。それでも、小さいｋでさえ、実質的な性能利益につながり、これを、この続きで、シミュレーション結果によって示す。さらに、諸実施形態は、すべてのトランザクションｊ∈｛１，…，Ｎ｝の推定されたＰＨＹ容量ｒ_ｊおよび残りのビットＲ_ｊがもはや一定または半静的と仮定できない場合に、上の手順を繰り返す。ｒ_ｊまたはＲ_ｊのいずれかが変化する場合に、諸実施形態で、上のステップを繰り返すことができる。

スケジューリングする手段２６を、トランザクションごとのサポート可能なデータ・レートに基づいて送信シーケンスをさらに変更するように適合させることができる。たとえば、ｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒスケジューリングを統合することができる。第１実施形態は、入手されたＣＡＲＡシーケンスをｐｒｏｐｏｒｔｉｏｎａｌ ｆａｉｒ（ＰＦ）スケジューリング概念と組み合わせ、これと共にＣＱＩ対応スケジューリングをサポートすることができ、このＣＱＩ対応スケジューリングは、ＵＥの間のＣＱＩ差を活用する。

ＰＦスケジューリング重みおよび移動平均を、たとえばそれぞれ（３）および（４）のように計算することができる。ＣＡＲＡシーケンスおよびＰＦスケジューリング重みを組み合わせるために、トランザクションは、各トランザクションにインデックスｊによってアクセスできるように、上で与えられるようにシーケンスＳ_１として順序付けられると仮定する。その後、実施形態は、次のように組み合わされた重みｖ_ｊを計算することができる。
＃ シーケンス内のすべてのトランザクションについて
ｆｏｒ ｊ ＝ １ ｔｏ Ｎ ｄｏ
ｖ_ｊ＝ｗ_ｊ−ｐ（ｊ−１）
ｅｎｄ ｆｏｒ
ここで、ｐは、いわゆるペナルティ係数である。この自由パラメータは、コンテキスト最適化されたＣＡＲＡシーケンス対ＣＱＩ最適化されたＰＦ重みのトレードオフを可能にする。ｐ＝０のペナルティ係数は、純粋なＰＦスケジューリングが使用されることを意味し、ｐ→∞は、ＣＡＲＡシーケンスを変更しない。最後に、最大の重みｖ_ｊを有するトランザクションがスケジューリングされる。諸実施形態は、これと共に、ＣＡＲＡとＰＦとの間または一般にＣＡＲＡと任意の他のスケジューリング概念との間で微調整が使用可能にされるというもう１つの利益を提供することができる。

図９に、異なる実施形態のシーケンス・ペナルティを示すビュー・グラフを示す、すなわち、異なるペナルティを有するＣＡＲＡヒューリスティックのシミュレーション結果が表示されている。最上部に平均効用、中央に秒単位の平均終了時間、最下部にビット／秒単位の和容量が、ペナルティ・パラメータｐによって影響されて示されている。次では、シミュレーション・シナリオを説明する。すべての評価は、２０ユーザのために働く単一のラジオ・セル内で実行される。ここでは、ダウンリンク方向だけを検討する。ユーザごとに、トランザクションを作成し、これを基地局トランシーバ２００でキューに入れる、別々のトラフィック・ジェネレータがある。基地局トランシーバ２００のスケジューラ２６は、全ユーザのデータをラジオ・リンク上でどのように多重化すべきかを判断しなければならない。ユーザごとに、ユーザ・データを受信する１つのＵＥがある。ラジオ・システムのモデルは、周波数分割多重を用いる通常の３ＧＰＰ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）システムに従って選択される。

現実的な干渉条件を有するために、干渉する基地局の１ティアが、評価されるセルの周囲に配置される。これらの基地局は、すべてのリソースで常に送信しつつあると仮定される。２０個のＵＥが、評価されるセルのサービング・エリアに均一に置かれる。基地局および移動局は、等方性アンテナを備える。すべての基地局が、すべてのリソースにまたがって等しく分布する一定の電力で送信する。リンクごとに、経路損は、すべてのシミュレーション中に固定され、これは、ハンドオーバの省略を可能にする。シャドウイングおよび高速フェージングは、秒の時間スケールでラジオ・チャネルの変動に似せるために固定された速度に従って変動する。ラジオ伝搬モデルの詳細は、次の表で与えられる。

スケジューラは、１ｍｓの間隔で動作する。単純さのために、スケジューラは、帯域幅全体を単一のユーザに割り振ることだけができる。周波数選択性の効果は、文献でよく理解され、したがって、ここでは重要視しない。リンク適合は、シャノンの式によって理想化され、ここでの焦点ではない。ＳＩＮＲ値は、理想的ではないよいチャネル条件を避けるために、２０ｄＢでクリッピングされる。トランスポート・プロトコル（たとえば、伝送制御プロトコル、ＴＣＰ）は、考慮されない。あるトランザクションのすべてのデータが、サーバによって送信された直後に基地局で使用可能であると仮定する。これは、基地局内にＴＣＰプロキシを備えるシステムの挙動を近似するものである。トラフィック・モデルは、ＮＧＭＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋｓを省略）トラフィック・モデルを基礎として構成され、ＮＧＭＮ Ａｌｌｉａｎｃｅ、「Ｒａｄｉｏ ａｃｃｅｓｓ ｐｅｒｆｏｒｍａｎｃｅ ｅｖａｌｕａｔｉｏｎ ｍｅｔｈｏｄｏｌｏｇｙ」、ｈｔｔｐ：／／ｗｗｗ．ｎｇｍｎ．ｏｒｇ／でオンラインで入手可能、２００７年６月を参照されたい。

さらに、通常はベスト・エフォート・ベアラ内でサービスされる２つのトラフィック・クラスすなわち、ウェブ・サーフィン（ハイパーテキスト転送プロトコルの省略形としてのＨＴＴＰ）およびファイル・ダウンロード（ファイル転送プロトコルを省略したＦＴＰ）が選択される。ＨＴＴＰモデルは、ウェブ・ページの構成を記述する。ウェブ・ページは、メイン・オブジェクト（ＨＴＭＬテキスト、ＨＴＭＬはハイパーテキストマークアップ言語を省略する）およびランダムな個数の埋め込みオブジェクト（ピクチャ、ｊａｖａ ｓｃｒｉｐｔなど）からなる。メイン・オブジェクトのサイズおよび埋め込みオブジェクトのサイズは、切り捨てられたｌｏｇｎｏｒｍａｌ分布に従う。１ページあたりの埋め込みオブジェクトの個数は、５．６４の平均値および５３の最大値を有する切り捨てられたパレート分布に従う（詳細については、上で参照した文献を参照されたい）。あるウェブ・ページのすべてのオブジェクトが、単一のトランザクションを構成する。

単純化のために、ウェブ・ページの総サイズが、計算され（メイン・オブジェクト・サイズとすべての埋め込みオブジェクト・サイズの和）、ページ全体が単一のオブジェクト内で送信されると仮定する。そうではないと述べられない限り、データ量の２０％および８０％に対応する９０％ＨＴＴＰおよび１０％ファイル転送プロトコル（ＦＴＰ）からなる集約トラフィックが使用される。

実施形態では、アプリケーション層からのコンテキスト情報は、スケジューリングに直接には活用されない可能性がある。ＣＡＲＡは、各トランザクションに効用関数を与えることによって使用可能にすることができる。効用は、トランザクションの要件と、これらの要件がどのように満足されるのかとに依存する可能性がある。効用関数のプロセス・フローは、次のようなものとすることができる。アプリケーションのフォアグラウンド／バックグラウンド状況またはアプリケーション・タイプなどのコンテキスト情報が、関連するトランザクションの要件を導出するのに使用される。これらの要件は、トランザクションの終了時刻または完了時刻に依存するトランザクションの値を考慮して効用関数を導出することを可能にすることができる。それぞれの効用関数の形状およびパラメータを考慮するこの導出を、ユーザ経験調査を用いて推論することができる。

たとえば、ウェブをサーフィンする時に、ユーザは、高速ページ・ロードがあれば幸福であるが、ある程度の遅延を許容することもでき、Ｊ．Ｎｉｅｌｓｅｎ、「Ｗｅｂｓｉｔｅ ｒｅｓｐｏｎｓｅ ｔｉｍｅｓ」、ｈｔｔｐ：／／ｗｗｗ．ｕｓｅｉｔ．ｃｏｍ／ａｌｅｒｔｂｏｘ／ｒｅｓｐｏｎｓｅ−ｔｉｍｅｓ．ｈｔｍｌ、２０１０年、リンクは２０１１年２月３日に検証を参照されたい。これを、下で説明するように効用関数で表すことができる。効用関数は、トランザクションの待ち時間要件を表すことができる。これは、スケジューラが、どのトランザクションをいつスケジューリングすべきかを判断することを可能にすることができる。緩和された待ち時間要件を有するトランザクションを、時間においてシフトして、マルチユーザ・ダイバーシティおよびチャネル・アウェアネスを高めることができる。効用は、通常、データ・レートの関数として定義され、これを、実施形態によって拡張することができる。諸実施形態は、ユーザに関するトランザクションの値を表すことができる。ほとんどのトランザクション、たとえばウェブ・ページのダウンロードについて、これは、終了時刻だけに依存する。すべてのトランザクションの値を、０…１の範囲内になるように定義することができ、０は、値なし（遅延が無限）を意味し、１は最適値を意味する。

トランザクションが、期待より早くに終了する場合には、これは、その値をわずかに増やすことだけができる。はるかに遅くまで遅延される場合には、通常のユーザが待つのをやめる時に、値は、それより悪くなることはできない。というのは、ほとんどのユーザが、それ以上待たないからである。したがって、終了時刻に依存する値の関数は、Ｓ形状を有する。ロジスティック関数を、一実施形態で選択することができる。図１０に、次のパラメータを有する例示的な効用関数を示す。次の段落は、これらのパラメータの選択を論断するものである。

トランザクションが、時刻ｔ_{ｓｔａｒｔ}にスケジューラに到着すると仮定する。他のすべての時点は、ｔ_{ｓｔａｒｔ}に対する相対的な持続時間として定義される。ユーザによって期待される時間内に終了したトランザクションの効用を、ｕ_ｅｘｐと定義することができる。効用の小さい増加を可能にするために、ネットワークの性能がユーザの期待を越える場合に、ｕ_ｅｘｐは、１未満である。トランザクションの期待される終了時刻は、そのサイズ、アプリケーションのタイプ、およびユーザのコンテキストに依存する。ユーザが、彼のオペレータからあるデータ・レートｒ_ｍａｘを購入したと仮定する。ユーザは、彼の現在のラジオ・チャネルを知らず、したがって、このデータ・レートが常に使用可能であると期待する。期待されるデータ・レートは、購入されたデータ・レートに関して定義される。
ｒ_ｅｘｐ＝ｆ・ｒ_ｍａｘ

ユーザは、フォアグラウンド・トランザクションがフル・データ・レート（ｆ＝１）でサービスされることを要求する。バックグラウンド・トランザクションについて、この要件は、緩和され、ユーザは、レートの分数（ｆ＜１）で満足する。トランザクションの初めから期待される完了時刻までの持続時間は、

によって決定され、ここで、ｓは、ビット単位のトランザクションのサイズであり、ｒ_ｅｘｐは、ビット毎秒単位の期待されるデータ・レートである。開始からロジスティック曲線の変曲点までの持続時間（ｕ_{ｉｎｆｌｅｃｔｉｏｎ}＝０．５）を、期待される終了持続時間の倍数になるようにモデル化することができる。
ｄ_{ｉｎｆｌｅｃｔｉｏｎ}＝ｘ・ｄ_ｅｘｐ
結果の効用関数を、

によって与えることができ、ここで、
ｍ＝ｔ_{ｓｔａｒｔ}＋ｘ・ｄ_ｅｘｐ

である。

図９は、平均トランザクション効用、トランザクションが終了に必要とする平均持続時間、およびセルあたりのビット／秒単位の和容量に対する、ペナルティ・パラメータ変更の影響を例証するものである。この実施形態を、複数のトランザクションが同時にスケジューリングされる周波数選択的スケジューリングに拡張することが単純であることに留意されたい。ＰＨＹ容量ｒ_ｊ（ｔ）をタイム・スロットあたり１回だけ評価するのではなく、ｒ_ｊ（ｔ，ｆ）を使用することができ、ここで、ｆは、サブバンド・インデックスである。次に、各サブバンド上のｖ_ｊを判定することができ、複数のトランザクションを１つのＴＴＩ内でスケジューリングすることが可能になる。

さらなる実施形態は、効用ベースのリソース割振りを使用することができる。これらの実施形態は、固定されたシーケンスＳ_１の制約を除去することによって、判定されたＣＡＲＡシーケンスの全体的な効用Ｕ_１を最大化することを目指す。それを行うために、一実施形態では、シーケンスＳ_１内の最初のトランザクションとは異なるトランザクションｊ≠１をスケジューリングすることが有利であるかどうかを判定することができる。

これを、２つのトランザクションについて図１１に示す。図１１は、現在のＴＴＩのリソース割振りを切り替える時の総効用の変化の計算を示す。Ｓ_１に従って、トランザクション１がまずスケジューリングされると仮定する。表示された瞬間のトランザクション１または２のビット／秒単位の期待されるレート（ｒ_１およびｒ_３の現在のレートならびにｒ_２、ｒ_４、およびｒ_５）の将来のレートの推定値）を、ｒ_ｉによって表す。ここで、トランザクション１がスケジューリングされず、トランザクション２と呼ばれる異なるトランザクションがスケジューリングされる場合に、和効用がより大きいかどうかを判定する。それを行うために、トランザクション１の終了時刻に関する期待される変化

およびトランザクション２の終了時刻に関する期待される変化

を計算する。効用関数が、期待される終了時刻に線形化される時に、この切替動作に関する効用差を計算することができる。

次に、切替動作が総効用に関して有利であるかどうかを判断することができる。このために、すべてのトランザクションの効用利益ΔＵを比較し、最大の利益を有するトランザクションをスケジューリングすることができる。諸実施形態が、将来のトランザクションのチャネル品質またはサポート可能なデータ・レートを判定するためにチャネル推定手段またはチャネル予測手段を使用できることに留意されたい。チャネル推定手段および／またはチャネル予測手段を、チャネル推定値および／または現在のチャネル推定値に関する予測、チャネル推定値履歴すなわち以前のチャネル推定値、既知の伝搬条件または伝搬損、ラジオ・チャネルに関する統計的知識、その他に基づくように適合させることができる。

第１実施形態に関して、サブバンド・インデックスごとに別々にレートを評価することによって、この第２実施形態周波数選択スケジューリングを拡張することは、単純である。図１２〜１４に、提案されるスケジューリング手順の性能を示すシミュレーション結果を示す。ケース「ＰＦを用いるＣＡＲＡヒューリスティック」は、第１実施形態を表し、第２実施形態は、「厳密なＣＡＲＡシーケンス」と呼ばれる。両方の実施形態が、その詳細をＦ．Ｋｅｌｌｙ、「Ｃｈａｒｇｉｎｇ ａｎｄ ｒａｔｅ ｃｏｎｔｒｏｌ ｆｏｒ ｅｌａｓｔｉｃ ｔｒａｆｆｉｃ」、Ｅｕｒｏ．Ｔｒａｎｓ．Ｔｅｌｅｃｏｍｍｓ．、ｖｏｌ．８、３３〜３７頁、１９９７年に見出すことができる従来のＰＦスケジューリングおよび期限の過ぎた送信を最小化するための通常のスケジューリング・ポリシであるＥａｒｌｉｅｓｔ Ｄｅａｄｌｉｎｅ Ｆｉｒｓｔ（ＥＤＦ）と比較される。シミュレーションでは、２０ユーザが、セル内に配置され、新しいトランザクションが、ポアソン過程に従って到着する。そうではないと注記されない限り、ｋ＝４００回の反復が、上のアルゴリズムに関して許容された。

図１２に、平均和効用対トラフィック負荷の性能結果を示す。図１２は、両方のＣＡＲＡ ＲＲＭ実施形態を用いて達した効用を実証するものである。両方の実施形態が、トランザクション遅延の関数として効用を最大化することを目指す。高いトラフィック負荷に関して、両方の実施形態が、ＰＦより７５％高い負荷をサポートしながら同一の効用を達成する。ＥＤＦと比較して、６５％負荷利益が示される。これらの高い利益は、リソースをより効率的に消費できる（より高い負荷をサポートするために）か、トランザクション遅延を減らすことができるかのいずれかであることを示す。

図１３に、平均セル・スループット対トラフィック負荷のシミュレーション性能を示す。図１３は、図１２に示された効用利益がどこから来るのかを示す。両方の実施形態が、効用を改善するためにセル・データ・レートを費やすが、第１実施形態は、セル・レート対トランザクション遅延をトレードオフするためにｐを調整することができる。図１４に、異なる回数の反復に関する平均トランザクション効用対トラフィック負荷のシミュレーション性能を示す。図１４は、トランザクション遅延が、シーケンス判定のための上の反復アルゴリズムに関して費やされる計算時間に伴ってどのように改善されるのかを示す。ｋ＝４００回の反復が、通常のＭＡＣプロセッサにとって小さい値であることに留意されたい。

ここまでは、コンテキスト情報がモバイル・トランシーバ装置１０によって提供される実施形態を議論した。既に議論したように、コンテキスト情報を、基地局トランシーバ装置２０によって、たとえばパケット・インスペクションによって、または一致したデータ・サーバ装置３０によって入手することもできる。

図１５に、データ・サーバ３００のための装置３０の一実施形態のブロック図を示す。データ・サーバ３００は、モバイル・トランシーバ１００上で走行しつつあるアプリケーションに関連するデータ・パケットを、モバイル通信システム５００を介してモバイル・トランシーバ１００へ通信する。装置３０は、データ・パケットのコンテキスト情報を導出する手段３２と、データ・パケットと一緒にコンテキスト情報をモバイル通信システム５００に送信する手段３４とを含む。コンテキスト情報は、アプリケーションのサービス品質要件に関する情報、アプリケーションに関連するデータ・パケットの優先順位情報、アプリケーションの複数のデータ・パケットのユニティに関する情報、アプリケーションの負荷需要に関する情報、アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、モバイル・トランシーバ１００上で走行するアプリケーションのプロセッサ使用に関する情報、その他を含むことができる。導出する手段３２を、データ・サーバ３００のオペレーション・システムからまたはデータ・サーバ３００上で走行するアプリケーションからコンテキスト情報を抽出するように適合させることができる。装置３０は、さらに、データ・パケットを構成する手段を含み、データ・パケットは、アプリケーションからのデータ・パケットおよびコンテキスト情報を含む。さらなる実施形態では、装置３０は、さらに、トランザクション・データ・パケットを構成する手段を含み、トランザクション・データ・パケットは、アプリケーションからのデータ・パケットおよびコンテキスト情報を含む。

図１６に、モバイル通信システム５００内のモバイル・トランシーバ１００の方法の一実施形態の流れ図を示し、モバイル通信５００システムは、さらに、基地局トランシーバ２００を含む。この方法は、モバイル・トランシーバ１００上で走行するアプリケーションから、モバイル・トランシーバ１００上で走行するオペレーション・システムまたはモバイル・トランシーバ１００のハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出するステップ７１２を含み、コンテキスト情報は、アプリケーションの状態に関する情報および／またはモバイル・トランシーバ１００の状態に関する情報を含む。この方法は、さらに、アプリケーションに関連するデータ・パケットを基地局トランシーバ２００を介してデータ・サーバ３００と通信するステップ７１４と、コンテキスト情報を基地局トランシーバ２００に提供するステップ７１６とを含む。

図１７に、モバイル通信システム５００内の基地局トランシーバ２００の方法の一実施形態の流れ図を示し、モバイル通信システム５００は、さらに、モバイル・トランシーバ１００を含む。この方法は、モバイル・トランシーバ１００上で走行するアプリケーションに関連するデータ・パケットを受信するステップ７２２と、アプリケーションに関連するデータ・パケットに関するコンテキスト情報を入手するステップ７２４とを含む。この方法は、さらに、コンテキスト情報に基づいて、データ・パケットの送信のためにモバイル・トランシーバ１００をスケジューリングするステップ７２６を含む。

図１８に、モバイル・トランシーバ１００上で走行するアプリケーションに関連するデータ・パケットをモバイル通信システム５００を介してモバイル・トランシーバ１００に通信するデータ・サーバ３００の方法の一実施形態の流れ図を示す。この方法は、データ・パケットのコンテキスト情報を導出するステップ７３２と、データ・パケットと一緒にコンテキスト情報をモバイル通信システム５００に送信するステップ７３４とを含む。

さらに、諸実施形態は、コンピュータ・プログラムがコンピュータまたはプロセッサ上で実行される時に上の方法のうちの１つを実行するプログラム・コードを有するコンピュータ・プログラムを提供することができる。

当業者は、さまざまな上で説明した方法のステップを、プログラムされたコンピュータによって実行できることをたやすく認めるであろう。本明細書では、いくつかの実施形態は、プログラム・ストレージ・デバイス、たとえば、機械可読またはコンピュータ可読であり、機械実行可能な命令のプログラムまたはコンピュータ実行可能な命令のプログラムを符号化するディジタル・データ記憶媒体を包含することが意図されており、前記命令は、前記上で説明した方法のステップの一部またはすべてを実行する。プログラム・ストレージ・デバイスを、たとえば、ディジタル・メモリ、磁気ディスクおよび磁気テープ、ハード・ドライブなどの磁気記憶媒体、または光学的に読取可能なディジタル・データ記憶媒体とすることができる。諸実施形態は、上で説明した方法の前記ステップを実行するようにプログラムされたコンピュータを包含することも意図されている。

この説明および図面は、単に、本発明の原理を示す。したがって、当業者が、本明細書で明示的に説明されず、図示されていないが、本発明の原理を実施し、本発明の趣旨および範囲に含まれるさまざまな配置を考案できることを了解されたい。さらに、本明細書で列挙されるすべての例は、特に、当技術を促進するために本発明の原理および本発明人（１つまたは複数）によって寄与される概念を理解する際に読者を助けるという教育的目的だけのためのものであることが、原理的に意図され、またそのように具体的に列挙された例や条件に限定されないものと解釈されるべきである。さらに、本発明の原理、態様、および実施形態ならびにその特定の例を列挙する本明細書のすべての言説は、その同等物を包含することが意図されている。

「〜の手段」（ある機能を実行する）と表された機能ブロックは、それぞれある機能の実行のためにまたはこれを実行するように適合された回路網を含む機能ブロックと理解されなければならない。したがって、「あるもののための手段」を、「あるもののために適合されまたはこれに適する手段」と理解することもできる。したがって、ある機能を実行するために適合された手段は、そのような手段が必ず前記機能を（所与の瞬間に）実行しつつあることを暗示しない。

「手段」、「抽出する手段」、「通信する手段」、「提供する手段」、「構成する手段」、「受信する手段」、「入手する手段」、「スケジューリングする手段」、「導出する手段」、「送信する手段」、「制御する手段」などとしてラベルを付けられたすべての機能ブロックを含む、図に示されたさまざまな要素の機能を、「パフォーマ」、「エキストラクタ」、「コミュニケータ」、「プロバイダ」、「コンポーザ」、「受信器」、「オブテイナ」、「スケジューラ」、「デライバ」、「送信器」、「コントローラ」などの専用ハードウェアならびに適当なソフトウェアに関連してソフトウェアを実行することのできるハードウェアの使用を介して提供することができる。プロセッサによって提供される時に、機能を、単一の専用プロセッサによって、単一の共有されるプロセッサによって、またはいくつかが共有される可能性がある複数の個々のプロセッサによって、提供することができる。さらに、用語「プロセッサ」または「コントローラ」の明示的使用を、ソフトウェアを実行できるハードウェアを排他的に参照すると解釈してはならず、この明示的使用は、限定なしに、ディジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ソフトウェアを格納する読取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、および不揮発性ストレージを暗黙のうちに含むことができる。従来のおよび／またはカスタムの、他のハードウェアを含めることもできる。同様に、図に示されたすべてのスイッチは、概念的なものにすぎない。その機能を、プログラム論理の動作を介して、専用論理を介して、プログラム制御と専用論理との相互作用を介して、または手動でさえ実行することができ、特定の技法は、文脈からより具体的に理解されるように、実装者によって選択可能である。

当業者は、本明細書のすべてのブロック図が、本発明の原理を実施する例示的な回路網の概念的な図を表すことを了解するであろう。同様に、すべてのフロー・チャート、流れ図、状態遷移図、擬似コード、および類似物は、実質的にコンピュータ可読媒体内で表すことができ、したがってコンピュータまたはプロセッサが明示的に図示されているか否かに関わりなくそのようなコンピュータまたはプロセッサによって実行され得るさまざまなプロセスを表すことを了解されたい。

Claims (10)

1. モバイル通信システム（５００）内のモバイル・トランシーバ（１００）のための装置（１０）であって、前記モバイル通信システム（５００）は、基地局トランシーバ（２００）をさらに含み、前記装置（１０）は、
   前記モバイル・トランシーバ（１００）上で走行するアプリケーションからコンテキスト情報を、前記モバイル・トランシーバ（１００）上で走行するオペレーション・システムからコンテキスト情報を、または前記モバイル・トランシーバ（１００）のハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出する手段（１２）であって、前記コンテキスト情報は、前記アプリケーションの状態に関する情報および／または前記モバイル・トランシーバ（１００）の状態に関する情報を含み、前記コンテキスト情報は、前記アプリケーションが現在フォアグラウンドまたはバックグラウンドのどちらに表示されているのかに関する情報を含む、抽出する手段（１２）と、
   前記アプリケーションに関連するデータ・パケットを前記基地局トランシーバ（２００）を介してデータ・サーバ（３００）と通信する手段（１４）と、
   前記モバイル・トランシーバ（１００）へのデータ・パケットをスケジューリングするために前記コンテキスト情報を前記基地局トランシーバ（２００）に提供する手段（１６）と
   を含む、装置（１０）。
2. 前記コンテキスト情報は、前記アプリケーションのサービス品質要件に関する情報、前記アプリケーションに関連する前記データ・パケットの優先順位情報、前記アプリケーションの複数の前記データ・パケットのユニティに関する情報、前記アプリケーションの負荷需要に関する情報、前記アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、前記モバイル・トランシーバ（１００）上で走行する前記アプリケーションのプロセッサ使用に関する情報、前記モバイル・トランシーバ（１００）の現在位置、速度、方位、または別のモバイル・トランシーバへの前記モバイル・トランシーバ（１００）の距離に関する情報の群の１つまたは複数の要素を含む、請求項１に記載の装置（１０）。
3. トランザクション・データ・パケットを構成する手段をさらに含み、前記トランザクション・データ・パケットは、前記アプリケーションからのデータ・パケットおよび前記コンテキスト情報を含む、請求項１に記載の装置（１０）。
4. モバイル通信システム（５００）内の基地局トランシーバ（２００）のための装置（２０）であって、前記モバイル通信システム（５００）は、モバイル・トランシーバ（１００）をさらに含み、前記装置（２０）は、
   前記モバイル・トランシーバ（１００）上で走行するアプリケーションに関連するデータ・パケットを受信する手段（２２）と、
   前記アプリケーションに関連する前記データ・パケットに関するコンテキスト情報を入手する手段（２４）であって、前記コンテキスト情報は、前記アプリケーションが現在フォアグラウンドまたはバックグラウンドのどちらに表示されているのかに関する情報を含む、入手する手段（２４）と、
   前記コンテキスト情報に基づいて前記データ・パケットの送信のために前記モバイル・トランシーバ（１００）をスケジューリングする手段（２６）と
   を含む、装置（２０）。
5. 入手する前記手段（２４）は、前記データ・パケットをインスペクトすることによって、前記モバイル・トランシーバ（１００）からコンテキスト情報を受信することによって、またはデータ・サーバ（３００）から前記コンテキスト情報を受信することによって、前記コンテキスト情報を入手するように適合され、前記コンテキスト情報は、前記アプリケーションのサービス品質要件に関する情報、前記アプリケーションに関連する前記データ・パケットの優先順位情報、前記アプリケーションの複数の前記データ・パケットのユニティに関する情報、前記アプリケーションの負荷需要に関する情報、前記アプリケーションの遅延制約または誤り率制約に関する情報、ウィンドウ状態に関する情報、メモリ消費に関する情報、前記モバイル・トランシーバ（１００）上で走行する前記アプリケーションのプロセッサ使用に関する情報、前記モバイル・トランシーバ（１００）の現在位置、速度、方位、または別のモバイル・トランシーバへの前記モバイル・トランシーバ（１００）の距離に関する情報の群の１つまたは複数の要素を含み、スケジューリングする前記手段（２６）は、前記ユニティに関する情報が参照する前記複数のデータ・パケットの前記サービス品質要件が満足されるように、送信のために前記モバイル・トランシーバ（１００）をスケジューリングするように適合される、請求項４に記載の装置（２０）。
6. スケジューリングする前記手段（２６）は、複数のトランザクションの送信シーケンスを決定するように適合され、トランザクション・データ・パケットは、前記アプリケーションからのデータ・パケットおよび前記コンテキスト情報を含み、トランザクションは、前記コンテキスト情報がそれに関するユニティを示す複数のデータ・パケットであり、前記複数のトランザクションは、１つまたは複数のモバイル・トランシーバ（１００）によって走行される複数のアプリケーションを参照し、トランザクションの前記シーケンスの順序は、効用関数に基づき、前記効用関数は、前記コンテキスト情報に基づいて判定されるトランザクションの完了時刻に依存する、請求項４に記載の装置（２０）。
7. 前記送信シーケンスは、トランザクションの複数の異なるシーケンスの反復から判定され、前記複数の異なるシーケンスは、前記複数のトランザクションの異なる置換に対応し、スケジューリングする前記手段（２６）は、前記複数の異なるシーケンスのそれぞれについて前記効用関数を判定するように適合され、最大の効用関数に対応する前記複数の異なるシーケンスからの前記送信シーケンスを選択するようにさらに適合され、かつ／または、スケジューリングする前記手段（２６）は、トランザクションごとのサポート可能なデータ・レートに基づいて前記送信シーケンスをさらに変更するように適合される、請求項６に記載の装置（２０）。
8. モバイル通信システム（５００）内のモバイル・トランシーバ（１００）のための方法であって、前記モバイル通信システム（５００）は、基地局トランシーバ（２００）をさらに含み、前記方法は、
   前記モバイル・トランシーバ（１００）上で走行するアプリケーションからコンテキスト情報を、前記モバイル・トランシーバ（１００）上で走行するオペレーション・システムからコンテキスト情報を、または前記モバイル・トランシーバ（１００）のハードウェア・ドライバもしくはハードウェアからコンテキスト情報を抽出するステップ（７１２）であって、前記コンテキスト情報は、前記アプリケーションの状態に関する情報および／または前記モバイル・トランシーバ（１００）の状態に関する情報を含み、前記コンテキスト情報は、前記アプリケーションが現在フォアグラウンドまたはバックグラウンドのどちらに表示されているのかに関する情報を含む、ステップ（７１２）と、
   前記アプリケーションに関連するデータ・パケットを前記基地局トランシーバ（２００）を介してデータ・サーバ（３００）と通信するステップ（７１４）と、
   前記モバイル・トランシーバ（１００）へのデータ・パケットをスケジューリングするために前記コンテキスト情報を前記基地局トランシーバ（２００）に提供するステップ（７１６）と
   を含む、方法。
9. モバイル通信システム（５００）内の基地局トランシーバ（２００）のための方法であって、前記モバイル通信システム（５００）は、モバイル・トランシーバ（１００）をさらに含み、前記方法は、
   前記モバイル・トランシーバ（１００）上で走行するアプリケーションに関連するデータ・パケットを受信するステップ（７２２）と、
   前記アプリケーションに関連する前記データ・パケットに関するコンテキスト情報を入手するステップ（７２４）であって、前記コンテキスト情報は、前記アプリケーションが現在フォアグラウンドまたはバックグラウンドのどちらに表示されているのかに関する情報を含む、ステップ（７２４）と、
   前記コンテキスト情報に基づいて前記データ・パケットの送信のために前記モバイル・トランシーバ（１００）をスケジューリングするステップ（７２６）と
   を含む、方法。
10. コンピュータ・プログラムがコンピュータまたはプロセッサ上で実行される時に請求項８または９に記載の方法のうちの１つを実行するプログラム・コードを有する前記コンピュータ・プログラム。

Images