JP2016508297A - チャネル・アウェアなジョブ・スケジューリング - Google Patents

Abstract

方法及びシステムは、アプリケーションに関連付けられたジョブのサービス品質（ＱｏＳ）情報を決定することと、モバイル・プラットフォームの無線チャネルの状態予測を決定することと、を提供し得る。さらに、前記ジョブは、前記ＱｏＳ情報及び前記状態予測に少なくとも部分的に基づいて、前記無線チャネルを介した通信のために、スケジュールされ得る。一例において、前記ジョブをスケジュールすることは、前記無線チャネルのスループットが閾値以下であると前記状態予測が示し、且つ遅延が前記ＱｏＳ情報のレイテンシ制約に従う場合、前記通信において前記遅延を課すことを含む。

Description

実施形態は、一般に、コンピューティング・プラットフォームにおける電力管理に関する。より詳細には、実施形態は、エネルギ効率を向上させるためのチャネル・アウェアなジョブ・スケジューリングに関する。

無線環境において、多くのファクタが、無線チャネルの状態に寄与し得る。例えば、同一チャネル干渉、隣接プラットフォーム間のチャネル・アクセス競合、及びユーザの動き（mobility）に起因するチャネル・フェージングは、全て、無線チャネル状態に影響を及ぼし得る。チャネル状態が劣化すると、所与のプラットフォームのネットワーク・インタフェース・コントローラ（ＮＩＣ）は、悪い状態を補償するために、より高い伝送パワーで動作し得る。より高い伝送パワーでも、ＮＩＣは、より低いスループット及び頻繁に生じる再送信に悩まされることがあり、これが、今度は、プラットフォーム上で実行されているアプリケーションが通信関連ジョブを完了させるのにかなり長い時間をかけさせ得る。ジョブ完了時間及びアプリケーション実行時間が長くなると、プラットフォーム及び／又はＮＩＣの低電力状態への移行を遅延させ得る。遅延された移行は、最終的に、より高いプラットフォームのエネルギ消費をもたらす。

本発明の実施形態の様々な利点が、以下の明細書及び添付の特許請求の範囲を読み図面を参照することにより、当業者に明らかになるであろう。
一実施形態に従ったジョブ・スケジューリング・アーキテクチャの一例のブロック図。 一実施形態に従った、ジョブをスケジュールする方法の一例のフローチャート。 一実施形態に従ったモバイル・プラットフォームの一例のブロック図。

図１は、アプリケーション・レイヤ１２が、ネットワーク・インタフェース・コントローラ（ＮＩＣ）１６を経由する無線チャネルを介した通信を伴うジョブ１４を発生させるジョブ・スケジューリング・アーキテクチャ１０を示している。アプリケーション・レイヤ１２は、例えば、ファイル同期アプリケーション、バックアップ・アプリケーション、定期的電子メール更新アプリケーション等を含み得る。ジョブ１４は、したがって、データ、コマンド等の送信及び／又は受信を含み得る。ジョブ・スケジューラ１８を使用して、無線チャネルを介した通信のために、ジョブ１４をスケジュールすることができる。図示した例において、アプリケーション・インタフェース２０は、ジョブ１４のサービス品質（ＱｏＳ）情報２２を決定し、予測モジュール２４は、当該の無線チャネルの状態予測２６を決定する。一般に、スケジュール１８は、ＱｏＳ情報２２及び状態予測２６に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブ１４をスケジュールすることができる。ジョブ１４のスケジューリングは、スケジューリング決定（scheduling decision）２８をアプリケーション・レイヤ１２及び／又はプラットフォームに関連付けられたオペレーティング・システム（ＯＳ）３０に発することにより達成され得る。

以下でより詳細に説明するように、状態予測２６を使用してスケジューリング決定２８を発することにより、ジョブ・スケジューラ１８は、チャネル状態が比較的良好なときにジョブ１４を完了させることができるように、遅延を選択的に課すことが可能となり得る。チャネル状態が比較的良好になるまでジョブ１４を遅延させることが、ジョブ１４をより迅速に完了させることを可能にし得、これが、今度は、より深いスリープ状態、より優れた電力保存、及びより長いバッテリ寿命を可能にし得ることは、特に注目すべきことである。図示した例において、予測モジュール２４は、ＮＩＣ１６から信号情報３２を受信し、１以上のセンサ３６から動き情報３４を受信する。状態予測２６は、動き情報３４及び信号情報３２に基づいて決定される。

信号情報３２は、例えば、信号対雑音比（ＳＮＲ）情報、受信信号強度（ＲＳＳ）情報、輻輳レベル情報、変動レベル情報、及び実際のチャネル状態を示す他のデータを含み得る。例えば、比較的低いＳＮＲ及び／又はＲＳＳは、パケット損失をもたらし得る悪いチャネル状態を示し得る。同様に、比較的高い輻輳レベル（例えば、増大した数の、チャネルに関する送信機／受信機の競合）及び／又は変動レベル（例えば、チャネル・スループット及び／又はチャネル品質の増大した変動）は、悪いチャネル状態を示し得る。

さらに、動き情報３４は、例えば、加速度計データ、コンパス・データ、及びアーキテクチャ１０を含むプラットフォームの動きを示す他のデータを含み得る。そのような動きは、チャネル状態に影響を及ぼし得る（例えば、悪い影響又は良い影響を及ぼし得る）。したがって、信号情報３２は、過去のチャネル状態及び現在のチャネル状態の判定を円滑にし得るのに対し、動き情報３４は、将来のチャネル状態に関して推測を行うことを可能にし得る。予測モジュール２４はまた、平滑化技術を使用して、短期間の振動を除去することができ、平均に基づく状態予測２６を取得することができる。状態予測２６は、したがって、ジョブ・スケジューラ１８がチャネル・アウェアな決定を行うことを可能にする、無線チャネル状態のロバストな評価を構成することができる。

ＱｏＳ情報２２は、ジョブ・スケジューラ１８が、さらに、レイテンシ制約等の所定の制約が満たされることを確実にすることを可能にし得る。例えば、状態予測２６が、無線チャネルのスループットが特定の閾値以下であることを示す場合、遅延が、ジョブ１４に関連付けられた通信に対して課せられ得るが、課せられる遅延は、ＱｏＳレイテンシ制約に従うようになされる。実際、ジョブ１４が緊急である場合、状態予測２６は、そのジョブ１４が即座の処理のためにスケジュールされるよう、完全に無視され得る。ＱｏＳ情報２２はまた、ジョブ１４に関連付けられたアプリケーションのタイプに基づいて、以前の情報を組み込むことができる。例えば、バックアップ・サービス型アプリケーション又は定期的電子メール更新型アプリケーションは、ユーザ・エクスペリエンスを損なうことなく、比較的より高い遅延を許容することができ得るのに対し、オンライン・ストリーミング・アプリケーション又はウェブ・ブラウジング・アプリケーションは、時間の影響を受けやすくインタラクティブな性質に起因して、レイテンシにそれほど寛容ではないものであり得る。

図示したアーキテクチャ１０はまた、ＮＩＣ１６を経由する通信中に、無線チャネルのためのレート適応及び／又はパワー適応を行うよう構成された適応モジュール３８を含む。例えば、チャネル・アウェアなレート適応ソリューションは、無線カードにより収集される信号強度測定値を使用して、伝送レートを選択するのを支援することができる。さらに、ＲＴＳ／ＣＴＳ（request to send/clear to send）オーバヘッドを招くことなく、チャネル情報が、送信機に利用可能であるように、チャネル・レシプロシティ（channel reciprocity）を利用して、チャネル情報を取得することができる。さらに、パワー適応ソリューションは、各データ送信の前にＲＴＳ／ＣＴＳフレーム交換を実施し、次いで、ＰＨＹ（物理レイヤ）モードの最もエネルギ効率の良い組合せを選択して、エネルギを節約するために、後続のデータ・フレーム伝送のためのパワー・レベルを送信することができる。他のそのような「マイクロレベル」のレート適応技術及び／又はパワー適応技術がまた使用されてもよい。適応モジュール３８は、したがって、図示した予測モジュール２４及びジョブ・スケジューラ１８により提供されるエネルギ効率を超えるように、エネルギ効率をさらに向上させることができる。

図２は、ジョブをスケジュールする方法４０を示している。方法４０は、論理命令のセットとして実装され得る。論理命令のセットは、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、ファームウェア、フラッシュメモリ等のマシン読み取り可能記憶媒体若しくはコンピュータ読み取り可能記憶媒体、例えば、プログラマブル論理アレイ（ＰＬＡ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、コンプレックス・プログラマブル論理デバイス（ＣＰＬＤ）といった設定可能なロジック、例えば、特定用途向け集積回路（ＡＳＩＣ）、相補型金属酸化膜半導体（ＣＭＯＳ）、若しくはトランジスタ・トランジスタ・ロジック（ＴＴＬ）技術等の回路技術を用いた固定機能論理ハードウェア、又はそれらの任意の組合せに記憶される。例えば、方法４０に示すオペレーションを実行するコンピュータ・プログラム・コードは、１以上のプログラミング言語の任意の組合せで記述することができる。そのようなプログラミング言語は、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語等の従来の手続型プログラミング言語を含む。

図示した処理ブロック４２は、ジョブ・リクエストを受信することを提供する。ブロック４４において、ジョブ・リクエストに関するＱｏＳ情報が取得され得る。前述したように、ジョブ・リクエストは、アプリケーションに関する無線通信（例えば、送信及び／又は受信）を伴い得る。そのようなアプリケーションとして、ファイル同期アプリケーション、バックアップ・アプリケーション、定期的電子メール更新アプリケーション、又はユーザ・エクスペリエンスに悪影響を及ぼすことなく遅延を許容することができる他の「バックグラウンド」アプリケーションがある。ブロック４６において、ＱｏＳ情報が、ジョブ・リクエストが緊急であることを示すかどうかに関する判定がなされ得る。そうである場合、ブロック４８において、無線チャネルを介した通信のために、ジョブが直ちにスケジュールされ得る。これはまた、前述したように、マイクロレベルでのレート適応及び／又はパワー適応を提供し得る。そうでない場合、図示したブロック５０は、ＱｏＳタイマをセットし、チャネル状態予測を取得する。前述したように、チャネル状態予測は、多様なファクタを考慮に入れ得る。そのようなファクタとして、例えば、プラットフォームの動き、ＳＮＲ、ＲＳＳ、輻輳レベル情報、変動レベル情報等がある。

ブロック５２において、チャネル状態が比較的良好であるかどうかに関する判定がなされ得る（例えば、無線チャネルのスループットが特定の閾値を超えているか）。そうである場合、ブロック４８において、無線チャネルを介した通信のために、ジョブがスケジュールされ得る。そうでない場合、図示したブロック５４は、ＱｏＳタイマが満了したかどうかを判定する。ＱｏＳタイマが満了した場合、ブロック４８において、無線チャネルを介した通信のために、ジョブがスケジュールされ得る。ＱｏＳタイマが満了していない場合、ブロック５６において、ジョブ関連通信において遅延が課され得る。明示していないが、チャネル状態が劣化していると判定された場合、通信は、（例えば、送信及び／又は受信の途中で）中断されてもよい。チャネル状態が改善したとき、通信は再スタートされ得る。さらに、図示したソリューションは、状況（例えば、周波数ホッピング）に応じて、１以上の無線チャネルに適用されてもよい。

次に図３に移ると、モバイル・プラットフォーム６０が示されている。プラットフォーム６０は、コンピューティング機能を有するモバイル・デバイス（例えば、携帯情報端末／ＰＤＡ、ラップトップ、スマート・タブレット）、通信機能を有するモバイル・デバイス（例えば、無線スマートフォン）、イメージング機能を有するモバイル・デバイス、メディア再生機能を有するモバイル・デバイス（例えば、スマート・テレビジョン／ＴＶ）、又はそれらの任意の組合せ（例えば、モバイル・インターネット・デバイス／ＭＩＤ）の一部とすることができる。図示した例において、プラットフォーム６０は、バッテリ６２、プロセッサ６４、集積メモリ・コントローラ（ＩＭＣ）６６、入力出力（ＩＯ）モジュール６８、システム・メモリ７０、ネットワーク・コントローラ（例えば、ネットワーク・インタフェース・コントローラ／ＮＩＣ）７２、オーディオＩＯデバイス７４、１以上の動きセンサ（例えば、加速度計、ジャイロスコープ、コンパス）７６、及びソリッド・ステート・ディスク（ＳＳＤ）７８を含む。１以上のプロセッサ・コア８０を有するコア領域を含み得るプロセッサ６４は、電力管理ユニット（ＰＭＵ）８１を使用して、パフォーマンス及び／又は電力管理上の関連事項（concern）に基づいて、コア８０及び他のプラットフォーム・コンポーネントを、１以上のアクティブ状態及び／又はスリープ（例えば、低電力）状態に移すことができる。

しばしばサウスブリッジ又はチップセットのサウス・コンプレックスと呼ばれる図示したＩＯモジュール６８は、ホスト・コントローラとして機能し、ネットワーク・コントローラ７２と通信する。ネットワーク・コントローラ７２は、多様な目的のために、オフ・プラットフォーム通信機能を提供することができる。そのような目的として、例えば、セルラ電話（例えば、Ｗ−ＣＤＭＡ（登録商標）（ＵＭＴＳ）、ＣＤＭＡ２０００（ＩＳ−８５６／ＩＳ−２０００）等）、ＷｉＦｉ（登録商標）（例えば、ＩＥＥＥ８０２．１１−２００７、無線ＬＡＮ媒体アクセス制御（ＭＡＣ）及びＰＨＹ仕様）、４Ｇ ＬＴＥ（第４世代ロング・ターム・エボリューション）、Ｂｌｕｅｔｏｏｔｈ（登録商標）（例えば、ＩＥＥＥ８０２．１５．１−２００５、無線パーソナル・エリア・ネットワーク）、ＷｉＭａｘ（登録商標）（例えば、ＩＥＥＥ８０２．１６−２００４、ＬＡＮ／ＭＡＮ無線ブロードバンド無線ＬＡＮ）、グローバル・ポジショニング・システム（ＧＰＳ）、スペクトル拡散（例えば、９００ＭＨｚ）、及び他の無線周波数（ＲＦ）テレフォニの目的がある。ＩＯモジュール６８はまた、そのような機能をサポートする１以上の無線ハードウェア回路ブロックを含み得る。プロセッサ６４及びＩＯモジュール６８は、別々のブロックとして図示されているが、プロセッサ６４及びＩＯモジュール６８は、同一半導体ダイ上のシステム・オン・チップ（ＳｏＣ）として実装されてもよい。

プロセッサ６４の図示したコア８０は、プラットフォーム６０上で実行されるアプリケーションに関連付けられたジョブのＱｏＳ情報を決定し、プラットフォーム６０の無線チャネルの状態予測を決定し、ＱｏＳ情報及び状態予測に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブをスケジュールすることができるチャネル・アウェア・ロジック８２を実行するよう構成される。一例において、ジョブをスケジュールすることは、無線チャネルのスループットが閾値以下であると状態予測が示し、且つ遅延がＱｏＳ情報のレイテンシ制約に従う場合、通信において遅延を課すことを含む。したがって、チャネル・アウェア・ロジック８２は、ファイル同期アプリケーション、バックアップ・アプリケーション、定期的電子メール更新アプリケーション、及びユーザ・エクスペリエンスを損なうことなく遅延を許容することができる他のバックグラウンド・アプリケーション等のアプリケーションのためのジョブ・スケジューラ１８及び予測モジュール（図１）を実装することができる。

したがって、本明細書で説明した技術は、実行時にチャネル状態をモニタリング及び予測し、チャネル状態及びＱｏＳ制約の両方に基づいて、ファイル同期型アプリケーションをスケジュールすることができる。そのようなアプローチは、数ミリ秒以上の（例えば、マイクロレベルの適応時間期間より長い）持続型のチャネル状態に特に有用である。さらに、チャネル状態が比較的良好なときに日和見的に（opportunistically）ジョブをスケジュールすることにより、エネルギ節約を最大化することができ、それにより、ジョブを迅速に完了させ、プラットフォーム及び／又はネットワーク・コントローラがより深い低電力状態に移行することを可能にする。したがって、ユーザ・エクスペリエンスに悪影響を及ぼすことなく、プラットフォームのエネルギ効率を最適化することができる。このようなソリューションは、モバイル・プラットフォーム・ユーザが、クラウド・コンピューティング・インフラストラクチャ及び／又はローカル・ネットワークを介して、ビデオ、音楽、写真、又は他のコンテンツを記憶及び検索する環境において、特に効果的であり得る。

実施形態は、したがって、モバイル・プラットフォームに電力を供給するバッテリと、アプリケーションに関連付けられたジョブのＱｏＳ情報を決定するアプリケーション・インタフェースと、を有するモバイル・プラットフォームを含み得る。モバイル・プラットフォームはまた、モバイル・プラットフォームの無線チャネルの状態予測を決定する予測モジュールと、ＱｏＳ情報及び状態予測に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブをスケジュールするスケジューラと、を有し得る。

実施形態はまた、アプリケーションに関連付けられたジョブのＱｏＳ情報を決定するアプリケーション・インタフェースと、モバイル・プラットフォームの無線チャネルの状態予測を決定する予測モジュールと、を有する装置を含み得る。装置はまた、ＱｏＳ情報及び状態予測に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブをスケジュールするスケジューラを有し得る。

実施形態はまた、アプリケーションに関連付けられたジョブのＱｏＳ情報が決定され、モバイル・プラットフォームの無線チャネルの状態予測が決定される方法を含み得る。方法はまた、ＱｏＳ情報及び状態予測に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブをスケジュールすることを提供し得る。

実施形態はまた、少なくとも１つのプロセッサにより実行されたときに、モバイル・プラットフォームに、アプリケーションに関連付けられたジョブのＱｏＳ情報を決定させる命令のセットを含む少なくとも１つのマシン読み取り可能記憶媒体を含み得る。命令のセットはまた、実行されたときに、モバイル・プラットフォームに、ＱｏＳ情報及び状態予測に少なくとも部分的に基づいて、無線チャネルを介した通信のために、ジョブをスケジュールさせ得る。

本発明の実施形態は、全ての種類の半導体集積回路（「ＩＣ」）チップとともに使用するために適用可能である。これらのＩＣチップの例は、プロセッサ、コントローラ、チップセット・コンポーネント、プログラマブル論理アレイ（ＰＬＡ）、メモリ・チップ、ネットワーク・チップ、システム・オン・チップ（ＳｏＣ）、ＳＳＤ／ＮＡＮＤコントローラＡＳＩＣ等を含むが、これらに限定されるものではない。さらに、図面のうちのいくつかにおいて、信号導線が、線により表されている。いくつかは、より多くの構成信号路を示すために異なり得るものであり、いくつかは、複数の構成信号路を示すために番号ラベルを有し得るものであり、且つ／あるいは、いくつかは、主要な情報のフロー方向を示すために１以上の端部において矢印を有し得るものである。しかしながら、これは、限定的なものとして解釈すべきではない。そうではなく、そのようなさらなる詳細は、回路のより容易な理解を促すために、１以上の例示的な実施形態に関連して使用され得る。さらなる情報を有していようがいまいが、示された信号線のいずれも、実際には、複数の方向に伝搬し得る１以上の信号を含み得、差動ペア、光ファイバ回線、及び／又はシングル・エンド回線を用いて実装される任意の適切な種類の信号方式（例えば、デジタル回線又はアナログ回線）により実装され得る。

サイズ／モデル／値／範囲の例が提供されたかもしれないが、本発明の実施形態は、そのような例に限定されるものではない。製造技術（例えば、フォトリソグラフィ）が時間とともに成熟するにつれ、より小さなサイズのデバイスを製造できると予想される。さらに、例示及び説明の単純さのために、且つ本発明の実施形態の所定の態様を曖昧にしないようにするために、ＩＣチップ及び他のコンポーネントへの周知の電力／接地接続が、図面内に示されているかもしれないし、示されていないかもしれない。さらに、本発明の実施形態を曖昧にするのを避けるために、構成をブロック図の形態で示すことができ、そのようなブロック図の構成の実装に関する詳細が、実施形態が実装されるプラットフォームに大きく依存すること、すなわち、そのような詳細が、十分に当業者の視野内にあるべきであることも鑑みている。本発明の例示的な実施形態を説明するために、特定の詳細（例えば、回路）が記載される場合、本発明の実施形態は、そのような特定の詳細なしでも、あるいはそのような特定の詳細の変形を用いても実施できることが当業者には明らかなはずである。したがって、本説明は、限定ではなく例示としてみなされるべきである。

本明細書において、「接続される」という語は、問題となっているコンポーネント間の直接的又は間接的な任意の種類の関係を指すために使用することができ、電気的接続、機械的接続、流体接続、光学的接続、電磁的接続、電気機械的接続、又は他の接続に適用することができる。さらに、本明細書において、「第１の」、「第２の」等の語は、説明を容易にするためだけに使用され、別途示されない限り、特定の時間的又は経時的な意味を有さない。

当業者は、上記の説明から、本発明の実施形態の広義な技術が様々な形で実装され得ることを理解するであろう。したがって、本発明の実施形態が、その特定の例に関連して説明されているが、図面、明細書、及び特許請求の範囲を検討することで他の修正形態が当業者に明らかになることから、本発明の実施形態の真の範囲は、そのように限定されるべきではない。

Claims (28)

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. 前記命令のセットが実行されたとき、前記命令のセットは、前記モバイル・プラットフォームに、
    前記通信中に、前記無線チャネルのためのレート適応及びパワー適応のうちの１以上を行わせる、請求項２２乃至２７いずれか一項記載の少なくとも１つのマシン読み取り可能記憶媒体。

Images