特許 5792836 電力しきい値を使用したモバイル通信端末のためのスマート電力マネージメントの方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5792836

(24)【登録日】2015年8月14日

(45)【発行日】2015年10月14日

(54)【発明の名称】電力しきい値を使用したモバイル通信端末のためのスマート電力マネージメントの方法および装置

(51)【国際特許分類】

   H04M 1/73 20060101AFI20150928BHJP

   H04W 52/02 20090101ALI20150928BHJP

【ＦＩ】

   H04M1/73

   H04W52/02 130

【請求項の数】9

【全頁数】36

(21)【出願番号】特願2013-553452(P2013-553452)

(86)(22)【出願日】2012年1月24日

(65)【公表番号】特表2014-513877(P2014-513877A)

(43)【公表日】2014年6月5日

(86)【国際出願番号】US2012022335

(87)【国際公開番号】WO2012109007

(87)【国際公開日】20120816

【審査請求日】2013年9月27日

(31)【優先権主張番号】13/024,728

(32)【優先日】2011年2月10日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(74)【代理人】

【識別番号】100128657

【弁理士】

【氏名又は名称】三山 勝巳

(74)【代理人】

【識別番号】100170601

【弁理士】

【氏名又は名称】川崎 孝

(72)【発明者】

【氏名】デ リンド ファン ヴァインハーデン，エイドリアン，ジェー．

(72)【発明者】

【氏名】ニティ，ナチ，ケー．

【審査官】 岩田 淳

(56)【参考文献】

【文献】 特開２００３−００８７３８（ＪＰ，Ａ）

【文献】 特開２００９−１３０８６０（ＪＰ，Ａ）

【文献】 特開２００５−２４２６３１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６

９／４８

９／５０−９／５２

９／５４

Ｈ０４Ｂ ７／２４−７／２６

Ｈ０４Ｍ １／００

１／２４−１／８２

９９／００

Ｈ０４Ｗ ４／００−８／２４

８／２６−１６／３２

２４／００−２８／００

２８／０２−７２／０２

７２／０４−７４／０２

７４／０４−７４／０６

７４／０８−８４／１０

８４／１２−８８／０６

８８／０８−９９／００

(57)【特許請求の範囲】

【請求項1】

それぞれのアプリケーションが、１つまたは複数のタスクを行うことによって実行される、複数のアプリケーションをサポートするように構成されているモバイル通信端末において、
（ａ）アプリケーションからのスケジューリング要求に応答して、前記タスクのうちの少なくとも１つの要求されているランタイムにおける電源状態の表示を得るステップであって、前記表示される電源状態が、残っている放電容量の推定を含む、ステップと、
（ｂ）前記要求されているランタイムにおける前記タスクによるエネルギー使用の度合いの予測を得るステップと、
（ｃ）エネルギー使用の前記予測された度合いから、前記タスクを完了させるために必要とされるエネルギーの総量を推定するステップと、
（ｄ）前記タスクに関するスケジューリングの決定を行うステップであって、前記スケジューリングの決定が、前記タスクに関する複数の代替処理からなるグループから選択を行うことを含み、前記選択が、前記ランタイムの電源状態を、前記タスクによるエネルギー使用の前記予測された度合いに、および前記タスクを完了させるために必要とされる総エネルギーの前記推定に関連付ける選択基準に従って行われ、前記選択基準は、前記推定された残っている放電容量が、前記タスクを完了させるために必要とされる前記推定された総エネルギーを少なくともあるしきい値量だけ超えているかどうかに基づく、ステップと、
（ｅ）前記タスクが進行中である間に、エネルギー使用の前記予測された度合い、および前記タスクを完了させるために必要とされる総エネルギーの前記推定を繰り返し更新するステップと、
（ｆ）前記タスクが進行中である間に、前記推定された残っている放電容量、および前記しきい値量を繰り返し更新するステップと、
（ｇ）前記更新された度合いの予測およびエネルギーの推定に、ならびに残っている放電容量の、および前記しきい値量の前記更新された推定に基づいて、前記タスクに関するさらなるスケジューリングの決定を行うステップと
を含む方法。

【請求項2】

前記タスクを完了させるために必要とされる前記推定された総エネルギーが、データベース内に格納されているアプリケーション・プロファイルから取り出された情報に少なくとも部分的に基づく、請求項１に記載の方法。

【請求項3】

少なくともいくつかのアプリケーションが、別々のそれぞれの優先順位レベルを有し、前記しきい値量が、前記タスクが属する前記アプリケーションの前記優先順位レベルに依存する、請求項１に記載の方法。

【請求項4】

スケジューリング要求を行っている前記アプリケーションが、クリティカルな優先順位レベルを有しているかどうかを判定するステップをさらに含み、
電源状態の表示を得る前記ステップ、エネルギー使用の度合いの予測を得る前記ステップ、およびスケジューリングの決定を行う前記ステップが、前記優先順位レベルがクリティカルではないという条件で実行され、
前記優先順位レベルがクリティカルである場合には、前記タスクが、無条件にスケジュールされる、
請求項１に記載の方法。

【請求項5】

スケジューリングの決定が、複数のタスクに関して行われ、少なくとも１つの優先順位レベルに関しては、タスクが、前記ランタイムの電源状態を前記タスクによるエネルギー使用の前記予測された度合いに関連付けるいかなる基準にもかかわらずに実行されるようにスケジュールされる、請求項１に記載の方法。

【請求項6】

前記優先順位レベルが、前記タスクがクリティカルである旨の表示、およびユーザによって構成されたオーバーライド表示のうちの少なくとも１つである場合には、タスクが、いかなる前記基準にもかかわらずに実行されるようにスケジュールされる、請求項５に記載の方法。

【請求項7】

バッテリと、
前記バッテリの状態に関する情報のソースと、
タスクをスケジュールしたいというアプリケーションからの要求に応答して前記バッテリ情報ソースから前記バッテリ状態の表示を得るように構成されている第１のモジュールであって、前記表示されるバッテリ状態が、残っている放電容量の推定を含む、第１のモジュールと、
１つまたは複数のアプリケーションに関連付けられているタスクによるエネルギー使用の度合いに関するエネルギー使用情報ソースと、
前記タスクに関する要求されているランタイムにおける前記タスクによるエネルギー使用の度合いの予測を前記エネルギー使用情報ソースから得るように構成され、前記タスクが進行中である間に前記予測を繰り返し更新するようにさらに構成され、前記タスクを完了させるために必要とされるエネルギーの総量を推定するように、および前記タスクが進行中である間に前記推定を繰り返し更新するようにさらに構成されている第２のモジュールと、
前記タスクに関する複数の代替処理からなるグループから選択を行うように構成されているタスク・スケジューリング・モジュールであって、前記選択が、前記ランタイムのバッテリ状態を、前記タスクによるエネルギー使用の前記予測された度合いに、および前記タスクを完了させるために必要とされる総エネルギーの前記推定に関連付ける選択基準に従って行われ、前記選択基準は、前記推定された残っている放電容量が、前記タスクを完了させるために必要とされる前記推定された総エネルギーを少なくともあるしきい値量だけ超えているかどうかに基づく、タスク・スケジューリング・モジュールと
を備えるモバイル通信端末。

【請求項8】

デジタル・メモリ内に格納されているアプリケーション・プロファイル・データベースをさらに含み、エネルギー使用予測モデルが、前記タスクを完了させるために必要とされる総エネルギーの前記推定が基づく情報を前記アプリケーション・プロファイル・データベースから取り出すように構成されている、請求項７に記載のモバイル通信端末。

【請求項9】

前記アプリケーション・プロファイル・データベースが、別々のアプリケーションごとに別々の優先順位レベルの表示を含む、請求項８に記載のモバイル通信端末。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モバイル通信端末における電力マネージメントに関する。

【背景技術】

【0002】

モバイル端末は、カメラを有するシンプルな電話から、強力なプロセッサ、大容量のメモリ、高解像度のカメラ、複数のセンサ、および大型のタッチセンシティブな特殊ディスプレイが備わった強力な多機能デバイスへと急速に進化している。同時に、モバイル端末は、小さな形態という要素を有しており、それによって、バッテリのサイズおよび形状に制限がかけられている。現在のモバイル端末は、強力なバッテリを有しているとは言うものの、オンライン・ゲームならびにストリーミング・ビデオおよびオーディオなどのリアルタイム・アプリケーションを含むさまざまなアプリケーションを同時に実行することができるというその性能によって、充電なしでモバイル端末が機能し続けることができる時間の量に相当な制約が課されている。

【0003】

過去においては、モバイル電話のパフォーマンスは、バッテリ充電と、次のバッテリ充電との間の「通話時間」および「スタンバイ」時間という点から評価されており、「通話時間」という尺度は、通話を行うためにモバイル電話が使用されている間にバッテリがそのモバイル電話に電力供給することができる総時間を示し、「スタンバイ」時間とは、バッテリが電話を機能できる状態に保持することができる総時間を指す。現在、アプリケーションごとの電力消費における差を考慮に入れるために、さらなるパフォーマンス・パラメータ、たとえば「インターネット使用時間」、「ビデオ再生時間」、および「オーディオ再生時間」が導入されている。

【0004】

しかし、複数のサービスが同時に使用される場合には、バッテリ電力は、急速に枯渇する可能性があり、それによって、どれぐらい早くモバイル端末が電力を使い果たすことになるかを単に予測することが困難になる。バッテリ電力が少ない場合には、ユーザは、特定のアプリケーションを避けること、または短時間しか使用しないことによって、電力消費を減らすよう試みる場合がある。しかし、多くのアプリケーションに関して、モバイル端末の電力消費を推定してコントロールすることは、ユーザにとって困難である場合があり、また、いくつかのアプリケーションおよびサービスは、バックグラウンドで機能する場合があり、それによって、それらのアプリケーションおよびサービスは、ユーザにとってさらにいっそう見えにくくなる。バッテリ内に残っている実際の電力を知らずにアプリケーションを始動させると、モバイル端末は、あまり電力が残っていないときに、電力消費量の多いアプリケーションを起動してしまう場合があり、ひいては、残っている電力が早く枯渇し、端末は、充電されるまで、機能できないままとなる。

【0005】

モバイル端末は、高度に集積された低電力のチップセットを使用している。チップセットにおける、とりわけプロセッサにおける電力消費は、主として、供給電圧Ｖ、クロック周波数ｆ、アクティブに切り替えられるゲートの割合（ｔｈｅ ｆｒａｃｔｉｏｎ ｏｆ ｇａｔｅｓ ａｃｔｉｖｅｌｙ ｓｗｉｔｃｈｅｄ）ａ、およびリーク電流Ｉ_ｌによって決定される。プロセッサの全体的な電力消費Ｐは、動的電力の項と、静的電力損失の項との和であり、一般にＰ＝ａＣＶ^２ｆ＋ＶＩ_ｌによってモデル化され、この場合、Ｃは、ロジック・ゲートのキャパシタンス負荷を示す。

【0006】

モバイル端末内で使用されるプロセッサは、通常、静的電力損失が非常に少ない。内部のモジュールが使用されていないときにコンポーネントがそれらのモジュールをオフに切り替えることができる場合に、大きな電力節減を得ることができる。プロセッサは、動的な周波数スケーリングをサポートするように設計することができ、それによって、動的電力の項の一次低減（ｌｉｎｅａｒ ｒｅｄｕｃｔｉｏｎ）がもたらされる。供給電圧が動的に調整可能である場合に、二次低減（ｑｕａｄｒａｔｉｃ ｒｅｄｕｃｔｉｏｎ）を得ることができる。これは、ダイナミック・ボルテージ・スケーリング（ＤＶＳ）と呼ばれており、電力最適化のための最も初期のアプローチのうちの１つである。供給電圧を低くすると、通常、達成可能な最大のクロック周波数が減り、したがって、電圧およびクロック周波数の両方を同時に小さくして、計算スピードと引き換えに大幅な電力節減を達成することができる。

【0007】

モバイル端末は、電力消費を制限するためのさまざまなエネルギー節減戦略、たとえば、スリープ・モード、および特定の時間にわたってディスプレイがアクティブでない場合にディスプレイを低い輝度のモードに切り替えるタイマーを採用している。いくつかのモバイル端末は、アプリケーションが低い輝度のディスプレイのためのタイマーを調整できるようにするインターフェースを提供することができる。モバイル端末は、通常、残っている電力およびワイヤレス接続の品質の表象をユーザに知らせるためにバッテリ充電ステータス・インジケータおよび受信品質インジケータを使用し、通常、事前に設定された特定の持続時間にわたって何のアクティビティも行われない場合にシステムの一部をオフに切り替えるさまざまなスリープ・モードを組み込んでいる。

【0008】

ラップトップおよびノートブックなどの比較的大型のモバイル端末は、通常、電力が少ない場合にユーザに警告する電力マネージメント機能を有する。電力マネージメント機能は、システムの秩序正しいシャットダウンを達成できるようにデータを保存するためのステップを踏むことができる。電力マネージメント機能は、スリープ・モードにおいてエネルギーを節約するために何らかの機能をオフに切り替えることもできる。

【0009】

電力マネージメント機能は、通常、オペレーティング・システムによって提供される。ラップトップ・オペレーティング・システムは、通常、２つのさらなる機能、すなわちワイヤレス接続と、ユーザによってコントロールされる電力節減機能とを備えたデスクトップ・オペレーティング・システムである。モバイル・オペレーティング・システム、特にマルチタスク・スマート・フォンにおいて使用されるオペレーティング・システムは、ラップトップにおいて通ｊｙ法見受けられるオペレーティング・システムから得られる場合が多い。

【0010】

オペレーティング・システムは、（１つまたは複数の）プロセッサの利用度を最大限に高めるために、タスク・スケジューリングを使用する。この文脈においては、タスクは、オペレーティング・システムによって実行するためにスケジュールされる最小の単位であると定義される。プロセスとは、指定されたジョブを行うために実行されるプログラムのインスタンスである。１つのプロセスは、任意の直列順序および／または並列順序で実行することができる１つまたは複数のタスクを含むことができる。いくつかのオペレーティング・システムにおいては、タスクは、スレッドまたはライトウェイト・プロセスとして実現される。

【0011】

マルチタスク・オペレーティング・システムにおいては、タスクは、スケジューリングのための優先順位を割り当てられる。より優先順位の高いタスクに対応するために、いくつかのタスクを予め阻止することができる。マルチタスク・オペレーティング・システムにおけるタスク・スケジューリングの目的は、（１つまたは複数の）プロセッサの利用度を最大限に高めることである。さまざまなパフォーマンス基準を達成するために、さまざまなスケジューリング・アルゴリズムが、オペレーティング・システム内で実施されている。プロセッサの利用度に加えて、その他の重要な基準としては、公平性、スループット、ターンアラウンド・タイム、待ち時間、および応答時間が含まれる。

【0012】

電力消費が決定的に重要であるバッテリ駆動型のデバイスおよびコンピュータにおいては、電力消費をさらなる最適化基準とみなすことが有利である。

【発明の概要】

【発明が解決しようとする課題】

【0013】

アプリケーションによるエネルギー使用を減らすためのパワーアウェア・アルゴリズム（ｐｏｗｅｒ−ａｗａｒｅ ａｌｇｏｒｉｔｈｍ）が、モバイル端末において使用するために提案されている。しかし、実際の電力ニーズおよび必要とされる電力を供給するための実際の能力をさらにいっそう認識することが依然として必要とされている。

【課題を解決するための手段】

【0014】

例示的な実施形態においては、モバイル端末において使用されるタスク・スケジューリング・アルゴリズムが、アプリケーションの実際の電力消費を考慮に入れるように修正される。これは、バッテリ内に残っている電力、所与のタスクを完了させるために必要とされる電力の量、タスクのクリティカル性、および端末のロケーションなどのさらなる基準を使用することによって行われる。そのような修正から生じ得る利点の一部としては、下記のものが含まれる。

【0015】

ユーザによって始動されたアプリケーション、またはデバイスによって開始されたサービスが、残っているバッテリ電力で必ず完了まで実行されることが可能であるかどうかをモバイル端末が判定できるようになること、
モバイル端末が、認証、バンキング、緊急警報、救急呼び出し、および特定のロケーションベースのサービスなどの重要な機能を長時間にわたって提供することができることを保証し、それによってユーザは、それらのクリティカルなアプリケーションを必要なときに実行する上でモバイル端末を信頼できるようになること、
ネットワークまたはアプリケーション・サーバが、電力レベルが非常に低い場合にモバイル端末におけるエネルギー消費を減らすことを支援できるようになること、ならびに
とりわけ、クリティカルなアプリケーションおよびサービスが実行されるときに、よりよいユーザ経験を提供するために、モバイル端末のオペレーティング・システムが、端末のエネルギー消費をコントロールおよび管理するための手段を提供すること。

【0016】

したがって、一実施形態においては、モバイル通信端末は、複数のアプリケーションをサポートするように構成されており、それぞれのアプリケーションは、１つまたは複数のタスクを行うことによって実行される。アプリケーションからのスケジューリング要求に応答して、モバイル端末内のオペレーティング・システムは、タスクのうちの少なくとも１つの要求されているランタイムにおける電源状態の表示を得る。オペレーティング・システムは、要求されているランタイムにおけるタスクによるエネルギー使用の度合いの予測を得て、エネルギー使用の予測された度合いから、タスクを完了させるために必要とされるエネルギーの総量の推定を得る。オペレーティング・システムは、タスクに関するスケジューリングの決定を行う。スケジューリングの決定は、タスクに関する複数の代替処理からなるグループから選択を行うことを含む。その選択は、ランタイムの電源状態を、タスクによるエネルギー使用の予測された度合いに、およびタスクを完了させるために必要とされる総エネルギーの推定に関連付ける基準に従って行われる。

【0017】

別の実施形態においては、モバイル通信端末は、バッテリと、そのバッテリの状態に関する情報のソースと、タスクをスケジュールしたいというアプリケーションからの要求に応答してバッテリ情報ソースからバッテリ状態の表示を得るように構成されているモジュールと、１つまたは複数のアプリケーションに関連付けられているタスクによるエネルギー使用の度合いに関する情報のソースと、タスクに関する要求されているランタイムにおけるタスクによるエネルギー使用の度合いの予測をエネルギー使用情報ソースから得るように構成されており、またさらに、タスクを完了させるために必要とされるエネルギーの総量を推定するように構成されているモジュールと、タスクに関する複数の代替処理からなるグループから選択を行うように構成されているタスク・スケジューリング・モジュールとを含む。タスクに関する処理の選択は、ランタイムのバッテリ状態を、タスクによるエネルギー使用の予測された度合いに、およびタスクを完了させるために必要とされる総エネルギーの推定に関連付ける基準に従って行われる。

【0018】

いくつかの実施形態においては、オペレーティング・システムは、少なくともタスクがクリティカルではない場合の要求されているランタイムにおけるタスクによるエネルギー使用の度合いの予測を得るが、予測された度合いに基づいてスケジューリングの決定を行う機能は、タスクがクリティカルである場合には、有効にされない。すなわち、オペレーティング・システムは、タスクに関するスケジューリングの決定を行う。タスクがクリティカルではない場合には、スケジューリングの決定は、ランタイムの電源状態をタスクによるエネルギー使用の予測された度合いに関連付ける基準を含む。しかし、タスクがクリティカルである場合には、そのような基準は適用されない。

【0019】

別の実施形態においては、アプリケーションからのスケジューリング要求に応答して、オペレーティング・システムは、タスクのうちの少なくとも１つの要求されているランタイムにおけるバッテリの残っている有用な放電容量の表示を得て、タスクがクリティカルであるか否かの表示を得て、タスクに関するスケジューリングの決定を行うまたは得る。スケジューリングの決定を行うことは、タスクが却下される結果となる少なくとも１つの処理と、タスクが実行される結果となる少なくとも１つの処理とを含む、タスクに関する複数の代替処理からなるグループから選択を行うことを含む。選択を行うステップは、残っている有用な放電容量が指定の範囲内であるという表示に関して、タスクが実行される結果となる処理が、タスクがクリティカルであると表示された場合には利用可能となるが、タスクがクリティカルではないと表示された場合には利用不能となるように、実行される。

【図面の簡単な説明】

【0020】

【図1】例示的なパワーアウェア・マネージメント・スキームの一実施形態が実施されている例示的なワイヤレス通信システムの概略図である。

【図2】例示的な端末ベースの電力マネージャに関する詳細なアーキテクチャを示す概略ブロック図である。

【図3】仮想のバッテリに関するバッテリ容量対時間のプロットであり、モバイル端末において使用される典型的なバッテリに関する放電パターンの概括的な形を示している。とりわけ、この図は、いくつかの種類のアプリケーションが開始および終了される場合の典型的な放電挙動を示している。

【図4】例示的なパワーアウェア・マネージメント・スキームの一実施形態によるモバイル端末内の電力システムの機能ブロック図である。

【図5】例示的なパワーアウェア・マネージメント・スキームの一実施形態によるアプリケーション・プロファイラおよびその環境の機能ブロック図である。

【図6】例示的なパワーアウェア・タスク・モニタの流れ図である。

【図7】パワーアウェア・タスク・スケジューラを実装するための例示的なアーキテクチャの機能ブロック図である。

【図8A】タスクに関する電力しきい値に基づくスケジューリングまたは承認の決定を示すハイレベルな流れ図である。

【図8B】電力関連データ・フィールドを含めるように修正された例示的なプロセス・コントロール・ブロックに関するフォーマット図である。

【図9A】例示的な一実施形態における図７のパワーアウェア・タスク・スケジューリング・サブシステム７００内の機能のオペレーションを示す流れ図であり、より具体的には、図７の承認モジュール７１０のオペレーションに関する。

【図9B】例示的な一実施形態における図７のパワーアウェア・タスク・スケジューリング・サブシステム７００内の機能のオペレーションを示す流れ図であり、より具体的には、図７のパワーアウェア・スケジューリング・モジュール７６０のオペレーションに関する。

【発明を実施するための形態】

【0021】

いくつかのモバイル端末は、エネルギー節減機能を有する知られているハードウェア・コンポーネント、たとえば、重要な情報をハードウェアおよびモバイル端末のオペレーティング・システム（ＯＳ）に提供する「スマート」バッテリ、明るさを調整できるディスプレイ、ならびに、エネルギー節減機能を有するワイヤレス・トランシーバを組み込んでいる。これらのコンポーネントは、典型的には、モバイル端末のＯＳによってコントロールされ、これらのコンポーネントのうちのいくつかは、（１人もしくは複数の）ユーザまたはユーザ・アプリケーションにとって利用可能にされる。

【0022】

ＯＳベースの電力マネージメント・アーキテクチャの主要な目的は、エネルギーを効率よく使用し、バッテリの有用な寿命を延ばし、充電と、次の充電との間のデバイス使用時間を長くする戦略を実施することである。

【0023】

効果的なモバイル端末電力マネージメントに関する最も重要な要件のうちの１つは、バッテリの実際の状態を認識することである。モバイル端末は、典型的には、充電可能なバッテリのパックを備えている。システムおよび電力マネージメント・チップと、システムの残りの部分との間の通信を容易にするための知られている機構がある。たとえば、スマート・バッテリ・システム（ＳＢＳ）標準において指定されているスマート・バス・インターフェースは、その利点によって、定常状態のバッテリのパラメータを正確に測定するための標準として受け入れられている。

【0024】

スマート・バッテリ・モニタリング・システムは、スマート・バッテリ、システム・マネージメント・バス・インターフェース、およびスマート充電器を含む。「スマート・バッテリ」という用語は、たとえば独自仕様のバッテリ・モデルを使用してバッテリ・パラメータを収集、計算、および予測し、計算されたパラメータを、ソフトウェア・コントロールを介してホスト・システムに提供するマイクロチップ回路を備えた充電可能なバッテリのパックを指す。スマート・バッテリは、ＳＭＢｕｓを介して充電器およびホスト・システムと通信するための内蔵インターフェースを有する。

【0025】

ＳＭＢｕｓとは、スマート・バッテリと、ホスト・システムと、スマート充電器との間において情報をやり取りするためのツーワイヤ通信インターフェース仕様である。

【0026】

スマート充電器は、充電時間に対するさらに正確なコントロールのためにバッテリの現在の充電ステータスを取り出す目的でスマート・バッテリと通信する。スマート・バッテリは、典型的には、バッテリの状態を表すいくつかのパラメータ、とりわけ、充電状態（ＳｏＣ：ｓｔａｔｅ ｏｆ ｃｈａｒｇｅ）および劣化状態（ＳｏＨ：ｓｔａｔｅ ｏｆ ｈｅａｌｔｈ）のパラメータを提供する。ＳｏＣとは、バッテリの総容量に対するパーセンテージとして測定されたバッテリの現在の充電レベルである。ＳｏＨとは、指定された出力電力を供給するための、同じタイプの新しいバッテリと比較した、バッテリの能力の測定値である。

【0027】

ＳＭＢｕｓインターフェース機能の呼び出しを介して、ホスト・システムは、バッテリのモデル、タイプ、ＳｏＣ、ＳｏＨ、温度、およびその他の使用統計、たとえば、充電／放電サイクルの数、バッテリの使用年数、放電し切るまでの時間、および充電に要する時間などを得ることができる。ＳＭＢｕｓを通じて得られたデータは、ホスト・システムにおける電力マネージメント・アプリケーションを作成するために使用することができる。

【0028】

ＳＭＢｕｓインターフェースは、この文脈において役立つことができるさまざまな可能なインターフェースのうちの１つであるということに留意されたい。

【0029】

モバイル・オペレーティング・システムにおける電力マネージメントは、ＯＳ側のコンポーネント、および任意選択でユーザ側のアドオン・アプリケーションから構成される。カーネル側での電力マネージメントの実施態様は、典型的には、バッテリ充電ステータスおよびその他のバッテリ関連パラメータを読み取るまたは測定するためのインターフェースを使用し、また典型的には、さまざまなハードウェア・サブシステム・コンポーネントへの電力供給をコントロールするための内蔵された機能を使用する。

【0030】

オペレーティング・システムは、（１つまたは複数の）プロセッサをコントロールすることに加えて、さまざまなハードウェア・サブシステム、たとえば、液晶ディスプレイ（ＬＣＤ）、キーボード、ディスク・ドライブ、メモリ・モジュール、通信モジュール、センサ、カメラ、オーディオ・デバイスなどへの電力をコントロールする。バッテリ・ステータスをモニタするために、オペレーティング・システムは、バッテリ・モデルおよび放電プロファイルを実装することができ、バッテリ・パラメータを読み取るためにＳＭＢｕｓインターフェースを利用することができる。

【0031】

内蔵されたＯＳ側の電力マネージメント機能は、典型的にはハンドル（ｈａｎｄｌｅ）を提供し、それらのハンドルを通じて、デバイス・ドライバおよびアプリケーションは、バッテリのステータスが変わったときに通知を受ける。バッテリ・ステータスの通知に加えて、デバイス・ドライバは、さまざまな電力節約モード（たとえば、オフ・モード、アイドル・モード、スリープ・モード、低電力モード、またはアクティブ・モード）へいつ切り替えるかを決めるためにタイマーをセットすることができる。

【0032】

ユーザ側では、その他のユーザ向けアプリケーションによって、およびハードウェア・サブシステム・コンポーネントによって使用される電力に対するコントロールをユーザに与えるために、ハイレベルなアドオン・アプリケーションを展開することができる。そのようなアドオン・アプリケーションのうちのいくつかによって提供されるコントロールは、完全に手動であるが、その他のアドオン・アプリケーションは、プロファイルベースのスケジューリングを提供し、そのもとでは、ユーザ定義のプロファイルにおいて指定されている事態が生じたときにアプリケーションをオンまたはオフにすることができる。電力消費に敏感な様式でアプリケーション・プロファイルを定義することによって、ユーザは、電力消費に対する何らかの自動的なコントロールを間接的に提供することができる。

【0033】

本明細書で説明される原理は、スマート電力マネージメントと呼ばれるアプローチへと結合することができる。スマート電力マネージメントとは、少なくともモバイル端末における電力モニタリング・アクティビティおよびタスク・スケジューリング・アクティビティを統合するパワーアウェア・タスク・マネージメント・スキームである。いくつかの実施態様においては、スマート電力マネージメントは、ネットワーク・ノードにおける電力モニタリング・アクティビティおよびタスク・スケジューリング・アクティビティの統合も行う包括的なネットワークワイドなスキームとすることができる。このようなスキームは、既存の電力マネージメント・スキームに取って代わることができ、または別法として、モバイル・オペレーティング・システムにおける電力マネージメントを拡張するための補完的なアプローチとして実施することもできる。

【0034】

本手法の利点のうちの１つは、厳密なデッドラインを伴うリアルタイムのアプリケーションに限定される必要がないということである。少なくともいくつかの電力マネージメント・スキームにとって、これは、著しい制限であった。なぜなら、スマート・フォンのタスクは、周期的なものではなく、定期的な間隔で到来するものでもないためである。さらに、マルチタスク・スマート・フォンは、さまざまなタイプのアプリケーションをホストすることができるため、タスクは、予測不可能な到来時間を有する場合があり、いくつかのアプリケーションに関しては、どれぐらい長くセッションが続くかを予測することが困難な場合がある。たとえばユーザが、インターネットを介してビデオ・ゲームをプレイする場合、またはライブ・ストリーミング・ショーを開始する場合には、セッションは、予測不可能な持続時間にわたって長くなることがある。

【0035】

本手法の別の利点は、コンピューティング・リソースを最適化するために使用する場合に、バッテリ電力を唯一の制約として使用することに限定される必要がないということである。実際に、スマート・フォンにおけるタスク・スケジューリングは、バッテリ電力だけでなく、無線リソース（利用可能な帯域幅）およびジョブのクリティカル性などのその他の制約も考慮することが望ましい。スマート・フォンは、救急呼び出しなどの命に関わる用途、および銀行取引などのサービスをサポートすることを期待されているということにも留意されたい。したがって、モバイル端末内のタスク・スケジューラは、これらの制約を考慮に入れることが好ましいであろう。

【0036】

モバイル・ハンドセットにおいては、無線リンクのハードウェア・コンポーネント（無線モデム）が、典型的には、その他のハードウェア・コンポーネントよりもはるかに多くの電力を消費する。信頼できるリンクを保持するために費やされる電力の量は、ハンドセットのロケーションによって、さらに影響を受ける。たとえば、中継塔（ｃｅｌｌ ｔｏｗｅｒ）からより遠く離れているハンドセットは、典型的には、中継塔のすぐ近くにあるハンドセットよりも高い送信電力を使用しなければならない。加えて、ローミング・ゾーン内にあるハンドセットは、頻繁に信号を探すことによってリンクを確立しようと試みることがあり、これによって、電力が急速に枯渇する場合がある。それゆえに、ハンドセットのロケーションは、アプリケーションが消費することができる電力の量に、ひいては、それらのタスクのパワーアウェア・スケジューリングに影響を及ぼすことがある。したがって、ハンドセットのロケーションを考慮することができるスケジューリング・アルゴリズムを提供することが有利であろう。

【0037】

スケジューリング・アルゴリズムに関する別の有利な特徴は、別々の種類の電源間の切り替えに適合できることであろう。従来、バッテリなどの枯渇しうる電源が使用されているか、またはそうでなければ、枯渇しない電源、たとえば充電器もしくは壁コンセントが使用されていると想定することが通常である。しかし実際には、モバイル端末は、バッテリと、充電器または壁コンセントとの間において頻繁に切り替えられる。タスク・スケジューリング・アルゴリズムが、電源間の切り替えを認識し、それに応じて自分のスケジューリング戦略を適合させることが望ましい。これに関連して、注目に値することとして、マイクロダイナモおよび太陽電池など、より新しいタイプの電源の使用は、パワーアウェアな様式で管理されることが有利である。なぜなら、そのような電源は、たとえば、クリティカルな呼び出しを行うのにちょうど十分な電力を提供することができるためである。

【0038】

スケジューリング・アルゴリズムに関する別の有利な特徴は、それぞれのタスクが、演繹的にわかっている一定の量の電流を消費することになるという通常の前提が存在しないことである。少なくともいくつかのケースにおいては、タスクの持続時間が予測不可能であるために、そのタスクが消費することになる総電流を予測することが実現可能でない場合がある。

【0039】

典型的なモバイル・オペレーティング・システムは、さまざまなハードウェア・サブシステムへの電力がデバイス・ドライバを介して選択的にコントロールされることを可能にする。タスクがハードウェア・システムのうちのすべてを常に使用することはめったにないため、消費される実際の電力がタスクの実行全体の中の別々の時点で再計算されれば、有利である。したがって、タスク・スケジューリング・アルゴリズムが、それぞれのスケジューリング・フェーズ中に電力消費を再計算することによって電力消費の変動性を考慮に入れると、有利であろう。

【0040】

したがって、例示的なパワーアウェア・マネージメント・スキームは、アプリケーションをそれらのアプリケーションの電力ニーズに従って管理するモバイル端末内のパワーアウェア・タスク・マネージャを使用する。好ましい実施形態においては、この例示的なスキームはまた、クリティカルなサービスを必ず利用可能にするために、電力の予備を実施する、すなわち、指定された量の放電容量に対して、クリティカルではないアプリケーションによる使用を差し控える。モバイル端末における電力消費を減らす上で役立つように、ネットワークベースおよびアプリケーションベースの電力マネージャを使用することができる。同様の原理は、残っている放電容量が少ない場合に、クリティカルではないシステム・タスクの実行も延期するために使用することもできる。これに関連して、オペレーティング・システムは、特定のシステム・タスク、すなわち、オペレーションがプロセッサに限定されているタスクを「クリティカル」として取り扱うことができるということが理解できるであろう。しかし、別段の記載がない限り、以降の論考において言及する「クリティカル性」は、システム・タスクではなく、ユーザ・アプリケーションに当てはまる。

【0041】

図１は、例示的なパワーアウェア・マネージメント・スキームの一実施形態が実施されているワイヤレス通信システム１００の概略図である。この図においては、モバイル端末内だけではなく、その他のネットワーク・ノードにおいても、パワーアウェア要素を含んでいる。モバイル端末の外でパワーアウェア要素を使用することは、本発明の必須要素とみなされるべきではないが、本発明のいくつかの実施形態においては有利であろう。図１におけるそのような要素は、限定するためではなく、本発明のアプローチの広がりおよび柔軟性を示すために含まれている。

【0042】

この図において示されているように、モバイル端末１１０は、バッテリ電源１２０、端末ベースの電力マネージャ（ＴＰＭ：ｔｅｒｍｉｎａｌ−ｂａｓｅｄ ｐｏｗｅｒ ｍａｎａｇｅｒ）１３０、およびトランシーバ・ユニット１４０を含む。アクセス・ノード１５０は、ネットワークベースの電力マネージャ（ＮＰＭ：ｎｅｔｗｏｒｋ−ｂａｓｅｄ ｐｏｗｅｒ ｍａｎａｇｅｒ）１６０、およびトランシーバ・ユニット１７０を含む。ネットワーク内のその他の場所では、アプリケーション・サーバ１８０は、アプリケーションベースの電力マネージャ（ＡＰＭ：ａｐｐｌｉｃａｔｉｏｎ−ｂａｓｅｄ ｐｏｗｅｒ ｍａｎａｇｅｒ）１９０を含む。アプリケーション・サーバ１８０は、典型的には、ワイヤレス・ネットワークの外に存在するが、そのワイヤレス・ネットワークと通信状態にある。ＮＰＭは、ネットワークワイドなパワーアウェア・スケジューリング・アクティビティをサポートするために、モバイル端末内のＴＰＭと協力して機能することができる。ＡＰＭは、モバイル端末内のバッテリ電力が少ない旨の表示があると、通常はモバイル端末内で実行されるアプリケーション処理のうちの一部を引き継ぐことができる。そのような戦略は、たとえば、非常に計算量の多いアプリケーションに関して、特に有用である場合がある。そのようなケースにおいては、計算の負荷をネットワーク・エンティティへシフトすることによって節約されるエネルギーは、モバイル端末と、ネットワーク・エンティティとの間の通信において費やされる余分なエネルギーを大幅に超える場合がある。

【0043】

以降でわかるように、モバイル端末内の例示的なＴＰＭモジュールは、実際の電力供給能力を推定するためのパワーアウェア・モニタリング・モジュールを含む。このＴＰＭモジュールはまた、それぞれのタスクにとって必要な電力消費を推定するための、およびその後に、それぞれのタスクをスケジュールすること、モニタすること、一時停止すること、または終了することによって、それぞれのタスクを処理するためのパワーアウェア・タスク・スケジューラを含む。例示的なＴＰＭモジュールに関する詳細なアーキテクチャが、図２の概略ブロック図において示されている。

【0044】

図２において示されているようなＴＰＭモジュールは、モバイル端末のオペレーティング・システムの一部とすることが有利である。図２のＴＰＭモジュール（この図においては、パワーアウェア・タスク・マネージメント・システムとして識別されている）は、下記のコンポーネントを含む。

【0045】

バッテリ電力モニタ２１０は、所与のタスクを実行するために必要とされる推定された電力を供給するためのバッテリ２０５の能力を、そのバッテリの現在の劣化状態（ＳｏＨ）、およびそのバッテリの充電レベルに基づいて計算する。モニタ２１０は、スマート電力モニタであることが有利であり、バッテリ２０５は、（この図において示されているように）スマート・バッテリであることが有利である。

【0046】

アプリケーション・プロファイラ２２０は、それぞれのアプリケーションに関する、または少なくともアプリケーションのカテゴリに関するプロファイルを含む。アプリケーション・プロファイル内のデータは、たとえば、アプリケーションのタイプ、アプリケーションの優先順位クラス、アプリケーションの典型的な実行時間、アプリケーションの使用履歴、およびアプリケーションの長期的な使用パターンを含むことができる。優先順位クラスは、たとえば、「クリティカルな」または「クリティカルではない」という、ユーザによって指定された分類とすることができる。その他の優先順位分類は、アプリケーションの相対的な重要度に応じて、複数の異なるレベルの階層を定義することができる。

【0047】

理解できるであろうが、利用可能な電力が少ない場合のオペレーションに関する選択基準は、「クリティカルではない」タスクおよびアプリケーションに対してよりも、「クリティカルな」タスクおよびアプリケーションに対して、より寛大なものとすることができる。同様に、アプリケーション・プロファイルは、少なくともいくつかのパワーアウェアな選択基準をオーバーライドするための、ユーザによって構成された表示を含むことができる。

【0048】

通信リソース・モニタ２３０は、通信リンク・ステータスおよび関連したメトリックをモニタする。

【0049】

パワーアウェア・タスク・モニタ２４０は、長く実行されているアプリケーションをモニタする。タスク・モニタ２４０は、長く実行されているアプリケーションによる電力使用の測定値を更新し、（以降で説明する）パワーアウェア・タスク・スケジューラによって使用するためのさまざまなしきい値パラメータを計算する。タスク・モニタ２４０はまた、アプリケーションおよびそれらのアプリケーションの使用パターンに関する統計値を収集する。

【0050】

パワーアウェア・タスク・スケジューラ２５０は、タスクをスケジュールする。それぞれのタスクは、そのタスクを完了するために必要とされる推定された電力、そのタスクのプロファイル、ならびに通信リソースおよびその他の必要とされるリソースの可用性に基づいてスケジュールされる。

【0051】

５つのコンポーネント２１０〜２５０は、たとえば、モバイル・オペレーティング・システム内のソフトウェア・モジュールとして実行される。パワーアウェア・タスク・モニタおよびパワーアウェア・タスク・スケジューラは、既存のタスク・スケジューリング・モジュールに対する機能強化として、またはさらなるスケジューリング・モジュールとして実装することができる。

【0052】

バッテリ電力モニタは、たとえば、スマート・バッテリからの入力を受信して、その入力を処理することによって、スマート・バッテリＡＰＩを利用するさらなるソフトウェア・モジュールとして実装することができる。スマート・バッテリがない場合には、適切なバッテリ・モデルをこのモジュールの一部として実装することが有利である。

【0053】

通信リソース・モニタ・モジュールは、ソフトウェア・モジュールとして実装することができる。このモジュールは、信号強度、チャネル品質、および帯域幅などの入力を得るために通信ハードウェアと対話しなければならない場合がある。このモジュールは、ワイヤレス・ネットワークのカバレッジ・エリアを特定するために使用することができるロケーション情報を得るためにＧＰＳ受信機またはその他のソフトウェア・モジュールと対話することができる。

【0054】

アプリケーション・プロファイラ・モジュールは、自分自身のアプリケーション・プロファイル・データベースを有するソフトウェア・モジュールとして実装することができる。

【0055】

ここで論じているさまざまなソフトウェア・モジュールはすべて、たとえば、モバイル端末の計算の中核を形成している中央デジタル・プロセッサ上で、またはその中央プロセッサとともに機能する補助プロセッサ上で実行することができる。以降で論じるように、ソフトウェア・モジュールによって必要とされるデータを格納するために、デジタル・メモリ・デバイスを使用することができる。

【0056】

モニタリング・コンポーネント２１０〜２４０は、１つまたは複数の独立したシステム・プロセスとして実行することができる。したがって、モニタリング・コンポーネント２１０〜２４０は、バックグラウンドで実行されることになる。モニタリング・コンポーネント２１０〜２４０は、適切なパラメータを定期的に得て、それらのパラメータを、スケジューラ２５０によってアクセスすることが可能な、パワーアウェア・モジュールのオペレーションにおいて使用されるそれぞれのパラメータに関連付けられているメモリ・ロケーションに書き込む。

【0057】

５つのコンポーネント２１０〜２５０について、以降でさらに詳細に論じる。

【0058】

バッテリ電力モニタは、モバイル端末のバッテリ・ステータスを追跡把握し、バッテリ寿命を最大化する上で役に立つ。バッテリの寿命を最大化することは、モバイル・ハンドセットに関する重要な設計基準である。すなわち、バッテリは、個々の放電サイクル中に非線形挙動を示す。非線形挙動は、バッテリの寿命サイクルを通じた蓄電効率においても見受けられる。バッテリは、不可逆的な物理的変化および化学的変化に起因して、後続のそれぞれの充電サイクルの後に充電の堅牢性が低下する傾向がある。

【0059】

満足できるユーザ経験を提供するためには、モバイル・オペレーティング・システムが、ユーザ・アプリケーションおよびサービスのスケジューリングにおいてバッテリの非線形挙動を考慮に入れることが望ましい。個々のアプリケーション（およびサービス）の開始時間およびランタイムは、予め特定することが不可能である場合が多いため、タスク・スケジューリング・アルゴリズムが、少なくともバッテリ・ステータスを考慮に入れることが有利である。スマート・フォンにおけるスケジューリングの問題は、さらにいっそう複雑である。なぜなら、そのような電話は、デスクトップ・コンピュータのマルチタスク環境と同様の真のマルチタスク環境をサポートしている場合が多いためである。

【0060】

バッテリの非線形挙動はまた、パワーアウェアなアプリケーションおよびサービスの設計に影響を与えることになる。なぜなら、すべてがバッテリ電力ステータスに関して最適化されることが望ましいためである。

【0061】

図３は、仮想のバッテリに関するバッテリ容量対時間のプロットであり、モバイル端末において使用される典型的なバッテリに関する放電パターンの一般的な形を示している。縦軸は、利用に供することができるバッテリ上の残っている充電を、はじめに利用できる使用可能な充電のパーセンテージとして表している。これは、バッテリの劣化状態（ＳｏＨ）の１つの側面である。プロットにおいてさらに示されているのは、残っている容量の２０％のレベルを示す横線、および残っている容量の１０％のレベルを示す第２の横線である。バッテリを使い果たすしきい値を表すさらなる横線も、非常に低いレベルで、たとえば、残っている容量の３％で示されている。参照番号１〜１０は、放電パターンにとって意味を持つさまざまなイベントを示している。

【0062】

図３を参照すると、完全に充電されたバッテリが、はじめの時点からイベント１におけるアプリケーションの終了まで実行されるアプリケーションに起因する典型的な放電を経験していることが見て取れるであろう。

【0063】

しばらくのアクティブでない期間の後に、第２のアプリケーション、おそらくはビデオ・アプリケーションが、イベント２において始動される。３と示されているイベントを通り越して延びる破線は、パワーアウェア・タスク・マネージャによって特定された、そのタスクを完了するために必要とされる電力の推定を表している。スケジューラは、この場合には、予想される最大持続時間の後でも十分な電力が見込めるため、そのタスクをスケジューリング用に承認することができると判定する。第２のアプリケーションは、イベント３において終了するまで実行される。

【0064】

さらにしばらくアクティブでなかった後に、第３のアプリケーションが、イベント４において始動される。はじめにパワーアウェア・タスク・スケジューラは、十分な電力が見込め、したがってタスクをスケジュールすることができると再び判定する。しかしスマート電力モニタは、チャネルの状態が悪化しているため、電力消費がはるかに多くなることにすぐに気づく。たとえば、モバイル端末は、部分的な無線の陰（ｐａｒｔｉａｌ ｒａｄｉｏ ｓｈａｄｏｗ）へと移動した可能性があり、そこでは、十分な帯域幅が依然として利用可能であるが、ただし、はるかに多くの電力が費やされる。

【0065】

イベント５においては、電力消費の度合いが非常に高くなったので、パワーアウェア・タスク・スケジューラは、アプリケーションを終了または一時停止するようユーザに警告するメッセージを発行している。

【0066】

イベント５と、イベント６との間では、電力消費がより少ないアプリケーションが、実行を承認および許可されており、その後に、イベント６からイベント７までのアクティブでない期間が続く。イベント７までに、残っている容量は、２０％のしきい値未満に低下している。以降で論じるように、そのようなしきい値は、選ばれたアプリケーションのみがスケジューリング用に承認される領域を示すために使用することができる。例としては、非常にわずかなエネルギーしか消費しないアプリケーション、およびセミクリティカルなアプリケーションを含むことができる。この図において示されているように、あるアプリケーションが、イベント７において承認されている。なぜなら、このアプリケーションは、予想される持続時間が非常に短く、それによって、タスクは、バッテリを使い果たすことなく完了するように実行されると予想されるためである。アクティブでない短い期間の後に、持続時間が短い別のタスクが、イベント８において承認され、イベント９まで実行されている。

【0067】

これに関連して、アクティブでない期間中でも、ユーザ端末の電源がオンになっている場合には、いくらかの電力が失われるということに留意されたい。アクティブでない間には、電力損失は、典型的には、バッテリが完全に充電されたときに最大になる。バッテリ残量が少ないときには、エネルギーを節約するために、電力を消費しているバックグラウンド・タスクのうちのいくつかを、およびシステム・タスクのうちのいくつかさえ減らすことが、少なくともいくつかのケースにおいては有利である場合がある。そのようなプロセスを少なくとも部分的に導くために、パワーアウェア・モジュールを使用することができる。

【0068】

イベント９のすぐ後に、アクティブでない期間中に、残っている容量は、１０％のしきい値未満に低下する。このしきい値未満では、クリティカルなアプリケーションのみが、実行を許可される。そのようなアプリケーションが、イベント１０において始動される。任意選択で、バッテリを使い果たすしきい値未満では、新たなアプリケーションを拒否することができ、アクティブであるクリティカルなアプリケーションを潔く終了することができる。

【0069】

バッテリの非線形の特徴、およびそれらのバッテリの放電プロファイルの形を考慮に入れる知られているバッテリ・モデリング・アルゴリズムが存在する。そのようなアルゴリズムは、バッテリの挙動をシミュレートするために、電気化学的プロセスの分析モデルまたは詳細な物理的モデルを使用することができる。いくつかの知られているアルゴリズムは、回復挿入期間（ｒｅｃｏｖｅｒｙ ｉｎｓｅｒｔｉｏｎ ｐｅｒｉｏｄ）、負荷プロファイル、ユーザによって実施される予測不可能な停止期間（ｕｎｐｒｅｄｉｃｔａｂｌｅ ｕｓｅｒ−ｅｎｆｏｒｃｅｄ ｒｅｓｔ ｐｅｒｉｏｄ）、充電に要する時間（ｒｅｃｈａｒｇｉｎｇ ｄｕｒａｔｉｏｎ）、およびタスクの細かさなどのさらなるヒューリスティックを使用して、バッテリ・サイクルを調整する。

【0070】

この図は、利用可能な電力の２０％および１０％という例示的なしきい値で選択基準がタスクに適用されていることを示している。実際には、タスク、アプリケーション、またはタスクもしくはアプリケーションのクラスごとに、別々のしきい値を確立することができる。加えてユーザは、電力が低下している旨を示された時点での、またはもっと早い時点でのオーバーライド・フラグを構成することができる。後述するように、オーバーライドは、パワーアウェア機能が無効にされているモードでモバイル端末が始動するように構成することさえできる。「無効にされている」とは、パワーアウェア機能が有効ではない、または呼び出されていない任意の状態を意味する。その他のさまざまな中間の構成も、もちろん可能であり、除外されるものではない。

【0071】

オーバーライド・フラグは、自分が適用されるタスクが、利用可能な電力レベルにかかわらずに実行されるようにスケジュールされるよう取り計らうことができる。あるいは、オーバーライド・フラグは、スケジューリングが低電力しきい値の影響を受けることを許可することができるが、スケジューリングの決定を、タスクの予想される電力消費のいかなる考慮からも切り離すことができる。

【0072】

利用可能な電力に基づく選択基準は、新たに到来したタスクと、既に承認されていて処理ループの２回目の反復またはその後の反復内に存在する可能性があるタスクとの両方に適用することができるということに留意されたい。したがって、進行中のタスクは、関連する選択基準が満たされなくなった任意の時点で終了することができる。

【0073】

図４は、一実施形態によるモバイル端末内の電力システムの機能ブロック図である。この図において示されているように、スマート電力モニタ・モジュール４１０は、スマート・バッテリ４３０のＳＭＢｕｓバッテリＡＰＩ４２０とのインターフェースを取るハイレベルなアプリケーション・プログラミング・インターフェース（ＡＰＩ）層である。モジュール４１０は、下記のことを含む情報を抽出する。

【0074】

バッテリのタイプおよびモデル。これは、電力コントロール・アルゴリズムを特定のバッテリ・モデル用に微調整する上で有用である。

【0075】

電源。これは、電力がバッテリから直接引き出されているか、または充電器、トランス、壁コンセント、もしくはユニバーサル・シリアル・バス（ＵＳＢ）などの別の電源から引き出されているかを識別する。

【0076】

ステータス情報。これは、例として、充電レベル、バッテリの劣化状態、および電力供給時間を含むことができるが、それらには限定されない。これらのパラメータについて、以降で論じる。

【0077】

バッテリの使用年数、および現時点までの充電サイクルの累積回数などの使用パラメータ。

【0078】

ステータス情報の具体例は、下記のとおりである。

【0079】

充電レベル、すなわち、バッテリの現在の充電レベルを示す充電状態（ＳｏＣ）。充電レベルは、典型的には、ミリアンペア時（ｍＡ−ｈ）、ミリワット時（ｍＷ−ｈ）、または同等の単位で、たとえばｍＡまたはｍＷで表される放電の想定される一定度合いとともに記載される。

【0080】

バッテリの劣化状態（ＳｏＨ）。および
バッテリが所与の度合いで電流および／または電力をどれぐらい長く供給することになるかを示す電力供給時間。電力供給時間は、たとえば分で表すことができる。

【0081】

スマート電力モニタ・モジュールは、ハイ・レベル・プログラミング言語インターフェースとして（たとえば、Ｃで、またはＪａｖａで）、場合によっては、パラメータ値への必要なアクセスを提供するためのハードウェア・モジュールの助けを借りて実装することができる。

【0082】

モバイル端末のバッテリがＳＭＢｕｓインターフェースを有していない場合には、ＳｏＣ、ＳｏＨ、およびバッテリ関連パラメータの計算は、バッテリ・モデルおよびエスティメータの助けを借りて達成することができる。その上、いくつかのスマート・バッテリは、すべてのＳＭＢｕｓ機能をサポートしているとは限らない場合がある。したがって、ＳＭＢｕｓインターフェースがない場合には、パワーアウェア・タスク・スケジューリング・アルゴリズムをサポートするために、適切なバッテリ・モデルを実装することが必要とされる。しかし、バッテリ・モデルは必ずしもモバイル端末内に実装されるとは限らないということに留意されたい。バッテリ・モデルは、ネットワーク内のその他の場所に実装することができ、モバイル端末とのワイヤレス通信のために容易に利用可能にすることができる。

【0083】

バッテリ・モデルが組み込まれる場合には、スマート電力モニタは、バッテリのタイプ、バッテリの使用年数、そのバッテリがこれまでに充電された回数、およびその他のパラメータなどの情報を格納するためのデータベースも含むことになる。エスティメータは、利用可能な情報を入力として受け取り、任意のバッテリ充電状態でのバッテリの能力を判定する。したがって、たとえばエスティメータは、残っている電力の推定値とともに劣化状態パラメータを計算することができる。

【0084】

バッテリは、限られた容量を有しており、非線形のシステム・ダイナミクスを示す。したがって、必要とされる時間にわたって所与のアプリケーションにとって十分な負荷電流をバッテリが供給することができるかどうかを予測することは、簡単な問題ではない。バッテリ容量の有用な推定を提供できるようにするためには、ＳｏＣ値だけでなく、ＳｏＨ値も利用可能にすることが非常に望ましい。

【0085】

ＳｏＣは、測定された値であり、バッテリのＳＭＢｕｓから直接、またはバッテリ・モデルを使用することによって得ることができる。スマート・バッテリ・インターフェースがない場合には、ＳｏＣ値は、たとえば２つのステップからなるプロセスによって得ることができる。はじめに、電圧、電流、および温度などの関連するパラメータが測定される。次いで、収集されたパラメータから、履歴データから、および以前に確立されたモデルから、ＳｏＣ値が推定される。

【0086】

しかし、ＳｏＣだけに頼ることは不利である。すなわち、バッテリのＳｏＣ測定は、バッテリの総充電量を示す際に有用であるにすぎず、使用可能なエネルギーがバッテリ内にどれぐらい残っているかは明らかにしない。言い換えれば、ＳｏＣ値は、必要とされる負荷をバッテリがどれぐらい長くサポートすることになるかを反映していない。

【0087】

しかしＳｏＨは、直接の測定には利用しにくく、その理由から、特定のバッテリ・テクノロジーに関連するモデルを使用して予測されなければならない。数年にわたって、バッテリのＳｏＨを正確に予測するための、およびバッテリのＳｏＣを特定するためのいくつかの異なるモデルが提案され、広く研究されている。これらのモデルは、放電率、充電／放電サイクルの履歴、および使用温度などの多くの要因によって影響を受ける値を有するパラメータに基づく。これらのモデルは、４つのカテゴリへと大まかに分類することができる。

【0088】

物理的モデルは、バッテリ内で生じる物理的なプロセスをシミュレートする。

【0089】

経験的モデルは、実験データに合致するようにパラメータをモデル方程式に適合させる。

【0090】

抽象的モデルは、バッテリを電気回路、離散時間等価物（ｄｉｓｃｒｅｔｅ−ｔｉｍｅ ｅｑｕｉｖａｌｅｎｔ）、および確率過程として表す。

【0091】

混合モデルは、経験的なパラメータを使用することによって物理的なプロセスを単純化するよう試みる。

【0092】

物理的モデルは、最大の正確さを提供するが、物理的なモデリングは、計算量が多く、モバイル・ハンドセット内で実施するのは困難である。経験的モデルは、計算の面ではシンプルなものにすることができるが、十分な正確さを欠く場合もある。したがって、現時点で確信しているのは、分析モデルが、モバイル・ハンドセット内で実施するのに最適であるということである。言及したように、計算能力の制約がより少ない、ネットワークのその他の部分においては、より計算量の多いモデルを有効に展開することができる。

【0093】

これに関連して役立つことができる１つの分析モデルが、キネティック・バッテリ・モデル（ＫｉＢａＭ：ｋｉｎｅｔｉｃ ｂａｔｔｅｒｙ ｍｏｄｅｌ）である。このようなモデルは、たとえばモバイル・オペレーティング・システムにおいて実施することができる。このモデルは、関連する電力パラメータを推定するために、およびソフトウェア・モジュールを用いてハンドセット・バッテリに関する履歴データを収集することによって、実施されるモデルの正確さをさらに高めるために、使用することができる。ハンドセット固有のバッテリ・データを使用することによって、正確さを高めるためにモデル・パラメータを再較正することが可能になる。

【0094】

よりシンプルに、バッテリ・モデルは、関連するタイプのバッテリに関する、さまざまな使用年数における、およびそのバッテリの放電サイクルのさまざまな時点における、平均の、予想される状態を特徴付けるデータのテーブルとすることができる。計算の類の、または単にテーブルの類の有用なバッテリ・モデルは、ローカルに、またはリモートのデジタル・メモリにさえ格納することができる。

【0095】

バッテリ・モデルは、測定から得られるデータ、およびたとえばスマート電力モニタによって提供されるデータを使用して、ときどき更新することができる。たとえば、計算型のバッテリ・モデルのパラメータは、実際の測定されたバッテリ挙動に合うようにモデルの予測を軌道修正するために、上述のように、ときどき修正することができる。

【0096】

アプリケーション・プロファイラは、アプリケーションを特徴付けるさまざまなパラメータのためのローカル・ストレージを提供する。アプリケーション・プロファイラおよびその環境の機能ブロック図が、図５において提供されている。この図において示されているように、アプリケーション・プロファイラ５１０は、ローカル・データベース５２０を使用する。このデータベースは、アプリケーションに関する下記の情報を含む。

【0097】

アプリケーション・プロファイルは、アプリケーションのタイプ、アプリケーションの相対的な優先順位レベル（たとえば、そのアプリケーションがクリティカルであるかどうかを含む）、そのアプリケーションを実行するために、どんなハードウェア・サブシステムおよびリソースが必要とされるか、予想されるランタイムおよび（もしあれば）必要とされる帯域幅の最初の推定値、ならびに、ベンダーまたは開発者によって供給されるアプリケーションの実行プロファイルを示す。

【0098】

アプリケーション・プロファイルは、アプリケーション電力しきい値（ＡＰＴ：ａｐｐｌｉｃａｔｉｏｎ ｐｏｗｅｒ ｔｈｒｅｓｈｏｌｄ）を含むこともでき、ここでは、ＡＰＴを、はじめから所与のアプリケーションを完了させるまでに必要とされる推定された電力に、クリティカルなアプリケーションのために必要とされる最小の電力をプラスした値と定義する。以降で詳細に説明するように、ＡＰＴは、タスク・アドミッション・コントロール（ｔａｓｋ ａｄｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ）およびタスク・スケジューリングにおいて使用することができる。ＡＰＴおよびその他のしきい値は、パワーアウェア・タスク・モニタによって提供され、更新される。ＡＰＴおよびその他のしきい値は、アプリケーション・プロファイル・データベース内に格納することができ、パワーアウェア・タスク・スケジューラによって直接アクセス可能なメモリ内へコピーすることによって利用可能にすることができる。

【0099】

アプリケーションのそれぞれの優先順位レベルは、それぞれが１つまたは複数のアプリケーションを含む複数の優先順位クラスを定義することによって、アプリケーション・プロファイル内で指定することもできる。それぞれの優先順位レベルは、残っているバッテリ充電量に関する別の要件に関連付けることができ、その要件に満たなければ、その優先順位レベルのアプリケーションは、一時停止または終了されることになる。したがって、相対的な優先順位レベルは（個々のアプリケーションのか、または優先順位クラスのかを問わず）、たとえば同時に実行されているタスクの全体が、残っているバッテリ充電量を求めて競合し始めたときに、効果を発揮することができ、残っているバッテリ充電量が低下し続ける場合には、最も低い優先順位のアプリケーションが、最初に停止される。

【0100】

クリティカルと示されているアプリケーションに関しては、それらのアプリケーションのタスクは、選択プロセスをオーバーライドすることを許可されることが可能であり、それによって、それらのタスクは、バッテリの残っている放電容量を問わずに実行されることが許可される。したがって、たとえば残っている有効な充電量が、最初の容量の２０％などのしきい値未満に低下した場合に、または残っている充電量が、次に予想されるバッテリの充電の前にそのようなしきい値未満に低下することが予測される場合に、モバイル端末は、クリティカルなタスクのみが実行を許可されるモードに入ることができる。任意選択で、非常に低いしきい値（たとえば、最初の容量の１％から５％に設定されるしきい値）を、バッテリを使い果たすしきい値として指定することができる。バッテリは、このしきい値未満に低下した場合には、まさに切れつつあるとみなされる。したがって、いかなるアプリケーションも、クリティカルなアプリケーションでさえ、スケジューリング用に承認されず、その一方で、アクティブであるクリティカルなアプリケーションは、潔く終了される。使い果たすしきい値に達すると、ＯＳは、すべてのクリティカルなアプリケーションがまさに機能しなくなりつつあることをユーザに知らせるための可聴式のまたは視覚的な警告を生成することができる。

【0101】

アプリケーション使用統計値は、アプリケーションの現在の状態、トータル・ランタイム、完了までに残っている時間、使用パターン、および履歴データを含む。

【0102】

アプリケーション固有のハードウェア使用プロファイルは、そのアプリケーションを実行するために必要とされるハードウェア・サブシステムのタイプを識別する。たとえば、プロファイルは、プロセッサのタイプおよびスピード、メモリおよびストレージのタイプおよびサイズ、ディスプレイのサイズおよびタイプを含むことができる。このプロファイルは、センサ、カメラ、およびキー・パッドが存在すること、およびアクティブであることを示すことができる。このプロファイルは、トランシーバおよび電力の増幅について示す情報を含むことができる。

【0103】

このデータベースはまた、ＡＰＩを提供し、そのＡＰＩを通じて、パワーアウェア・タスク・モニタは、それぞれのアプリケーションごとに、必要とされる総電力およびランタイムの推定値を得ることができる。アプリケーション・プロファイル・データベースは、パワーアウェア・タスク・モニタおよびパワーアウェア・タスク・スケジューラのためのキー・パラメータを提供する。

【0104】

ＡＰＩは、たとえば、データベースから情報を取り出すためにアプリケーションおよびオペレーティング・システム・モジュールによって呼び出すことができるすぐに使えるハイレベルな機能のセットを含むことができる。これは、個々のアプリケーションが、クエリーをデータベースに直接出すためのさらなるコードを追加する必要がなくなるため、有利である。

【0105】

通信リソース・モニタは、ワイヤレス・リンクのチャネル品質を測定するために使用されるモジュールである。このモジュールについては、ここでは図２を参照して説明し、図２では、このモジュールは、機能要素２３０によって表されている。チャネル品質の測定値は、通信しきい値パラメータを設定するための基礎として使用される。したがって、たとえば電力モニタは、たとえばアップリンクおよびダウンリンクの帯域幅、信号対干渉雑音比（ＳＩＮＲ：ｓｉｇｎａｌ−ｔｏ−ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−ｎｏｉｓｅ ｒａｔｉｏ）、ならびにロケーションの点からチャネル品質を測定するために通信リソース・モニタを定期的に呼び出すことができる。ロケーション情報は、モバイル端末と、最も近い中継塔（または最も近いアクセス・ポイント・ノード）との間の距離を推定するために、および現在のロケーションが、受信カバレッジの乏しい（または受信カバレッジのない）エリア内にあるかどうかを判定するために、使用することができる。

【0106】

モバイル端末のロケーションは、たとえば、一体化されているＧＰＳを使用して、または中継塔からのネットワークベースの測定によって、得ることができる。パワーアウェア・タスク・モニタは、必要とされる送信電力レベルを設定するために、ロケーション情報を使用する。モバイル端末が、カバレッジのないエリア内に位置している場合には、パワーアウェア・タスク・モニタは、どれぐらい頻繁にネットワーク接続を探すよう試みるべきかを決めるために、ロケーション情報を使用することができる。ユーザ・モビリティの適切なモデルが提供され、それによって、たとえばモバイル端末に関してターゲット・ロケーションを予測することができる場合には、モバイル端末のロケーションとともにモバイル端末の速度の知識を使用することによって、そのような決定を改善することが可能になることがある。

【0107】

パワーアウェア・タスク・モニタについても、図２をさらに参照すれば、より容易に理解され、図２では、このモジュールは、機能要素２４０として示されている。図２を参照すると、パワーアウェア・タスク・モニタは、パワーアウェア・タスク・スケジューラへの入力として必要とされるさまざまなパラメータを推定するために使用される。パワーアウェア・タスク・モニタは、電力および通信しきい値パラメータならびにアプリケーション・プロファイルを更新するために定期的に実行される。パラメータ推定値を作成するために、パワーアウェア・タスク・モニタは、アプリケーション・プロファイル・データベースから情報を得て、スマート電力モニタおよび通信リソース・モニタを呼び出す。

【0108】

パワーアウェア・タスク・モニタはまた、タスクがどれぐらい長く実行されているか、タスクによって既に使用されている電力の量、タスクを完了させるために必要とされる電力、およびアプリケーション使用統計値を含む情報を用いて、アプリケーション・プロファイル・データベースを更新する。パワーアウェア・タスク・モニタは、電力を消費している機能から情報を収集することもできる。たとえば、パワーアウェア・タスク・モニタは、測定値を得ることができ、それらの測定値を使用して、プロセッサ・アクティビティのレベル、ディスプレイの使用量、およびその他のハードウェア・コンポーネントの使用量を示すパラメータ値を設定することができる。この情報は、数ある理由の中でもとりわけ、これらのレベルの使用が予測と合っているかどうかをチェックするために、およびアプリケーション・プロファイルを更新するために、有用である。この情報は、たとえば、電力消費が予想よりもはるかに高い場合に、およびバッテリ状態がアプリケーションのさらなる実行をサポートしない場合に、措置を講じるために使用することもできる。

【0109】

アプリケーションを実行して完了させるために必要とされる電力の量をランタイム中に推定するためのさまざまな方法がある。たとえば、エネルギーアウェアなアプリケーションを開発することができるプログラミング・インターフェースを提供する知られているフレームワーク、すなわちプログラミング環境がある。そのようなプログラミング・インターフェースを通じて、ユーザは、別々の実行パスを識別すること、それぞれのパスに関連付けられているエネルギー消費を計算すること、およびそれぞれのエネルギー消費に従って実行パスを選択することを可能にすることができる。（平均の）エネルギー消費の最初の推定のために、テスト中に識別されたアプリケーションの実行プロファイルを使用することができる。しかし、そのようなアプローチは、トータル・ランタイムを容易に推定することができないインタラクティブなビデオ・ゲームおよびその他のアプリケーションに関しては、限られた効用しかない場合があるということが理解できるであろう。

【0110】

これに関連して役立つ別の推定技術が、ポータブル・ワイヤレス・デバイス上で実行されるアプリケーションのエネルギー・コストを推定するために提案されている。そのようなアプローチによれば、デバイスは、通信コンポーネントおよび計算コンポーネントへと分けられる。それぞれのコンポーネントは、エネルギー・コストを計算する目的で、有限状態マシンとしてモデル化される。このモデルのもとでは、それぞれの状態は、平均電流使用（ａｖｅｒａｇｅ ｃｕｒｒｅｎｔ ｕｓａｇｅ）、および実行の持続時間を有する。アプリケーションの総エネルギー・コストは、すべての状態遷移と、それらのそれぞれの推定されたエネルギー使用とを結合することによって計算される。アプリケーション開発者は、アプリケーションによって消費される総エネルギーの推定値を提供するために、そのようなモデルを使用することができる。

【0111】

パワーアウェア・タスク・モニタは、あまりにも頻繁に実行されることを許可されるならば、プロセッサを過剰利用する危険をもたらす可能性があるということに留意されたい。したがって、パワーアウェア・タスク・モニタを、パワーアウェア・タスク・スケジューラよりも低い頻度で実行されるように制限することが有利である場合がある。たとえば、パワーアウェア・タスク・モニタは、最後の更新以降に実行されたタスクに関してのみアプリケーション・プロファイル・パラメータを更新するように設定されることが可能である。パワーアウェア・タスク・モニタはさらに、スマート電力モニタおよび通信リソース・モニタを別々の間隔で呼び出すように設定されることが可能である。パワーアウェア・タスク・モニタは、タスクの最初の承認を決定する目的で、および長く実行されているタスクをコントロールする目的で使用するためのパワーアウェア・タスク・スケジューラ用のしきい値設定をパワーアウェア・タスク・スケジューラに提供することができる。

【0112】

パワーアウェア・タスク・モニタは、より低い優先順位で実行されることも可能であり、それによってプロセッサ能力は、アプリケーションを実行するために必要とされているときに悪影響を受けることがなくなる。

【0113】

モバイル端末の全体的な電力消費を追跡把握するために、タスク・モニタは、バッテリ状態、プロセッサ・アクティビティ、メモリ・アクティビティ、および最後のモニタリング・フェーズ以降に送信および受信されたデータの量などの電力関連パラメータを読み取り、それらのパラメータを、パワーアウェア・タスク・スケジューラによってアクセス可能なメモリ・ロケーションに書き込む。タスク・モニタは、関連するパラメータを調整して、タスクを承認または継続すべきかどうかを迅速に評価する上で有用な形式にすることもできる。すなわち、タスクを承認すべきかどうかの決定を行うたびに長時間の評価プロセスに頼ることは不利である。それよりむしろ、モバイルの現在の状態、アプリケーションの現在の状態、およびアクティブなタスクの電力消費を反映するパラメータが容易に提供される場合には、それらに基づいて迅速な決定を行えることが好ましい。

【0114】

図２の機能ブロック２４０に対応する例示的なパワーアウェア・タスク・モニタの流れ図が、図６において示されている。図６および図２を併せて読めば、以降の論考の理解に役立つであろう。パワーアウェア・タスク・スケジューラは、スケジュールされるのを待っているタスクのセットを取り上げ、それぞれのそのようなタスクごとに、そのタスクを実行するようにスケジュールするか、そのタスクを却下するか、またはそのタスクを一時停止するかを決定するためにパワーアウェア・タスク・スケジューラによって使用されるパラメータを得る。この図におけるブロックによって示されているそれぞれの処理ステップは、図２において示されているアクティブなタスクのキューから得られる承認されたタスクのバッチ上で実行される。パワーアウェア・タスク・モニタは、例示的な実施態様においては、システム・デーモンなどの常に実行されているバックグラウンド・プロセスとして実行される。モニタされるタスクは、新たなタスクと、処理の別のラウンドのためにパワーアウェア・タスク・マネージメント・システムに戻ってきたタスクとの両方を含む。

【0115】

初期化６０１は、モバイル端末の電源がオンにされたときに、またはシステム機能を復元する必要が生じたその他の時点で行われる。初期化中には、最初のしきい値およびフラグ（たとえば、オーバーライド・フラグなど）が、アプリケーションおよび／またはタスクのうちのそれぞれに関して設定される。少なくともいくつかの実施態様においては、電力充電器がオンであると（たとえば、ブロック６０２において）判定されて、枯渇しない電源が現在使用されていることが示された場合には、またはパワーアウェア機能が無効にされているモードで操作することをユーザが望む場合には、すべてのタスクに関してオーバーライド・フラグを設定することが有利であることがある。少なくともいくつかの実施態様においては、すべてのタスクに関してオーバーライド・フラグを設定すると、予想されるエネルギー使用と、残っているバッテリ容量との比較を行わずに、またはそうした比較にかかわらずに、すべてのスケジューリング決定が行われるようになる。

【0116】

したがって、いくつかの実施態様は、従来のモードで始動させるか、またはパワーアウェア・モードで始動させるかのどちらかの選択をユーザに提供することができる。ユーザが従来のモードを指定した場合には、ＯＳは、たとえば、すべてのオーバーライド・フラグをアクティブにすることができ、それによって、どのスケジューリングも、パワーアウェアなスケジューリングの決定に基づかなくなる。対照的に、パワーアウェア・モードが指定された場合には、ＯＳは、パワーアウェア・タスク・スケジューラおよびその他のパワーアウェア・モジュールを有効にすることができる。

【0117】

充電器がオンではない場合（たとえば、オフである場合、または接続されていない場合）には、タスク・モニタは、ブロック６０３において、ＳｏＣ、ＳｏＨ、およびその他のバッテリ情報をバッテリ電力モニタ２１０から得る。ブロック６０４において、タスク・モニタは、それぞれのタスクごとに電力使用パラメータを特定する。バッテリの残っている放電容量が少ない場合には、相対的に多くの量の電力を所与のタスクが使用することが予想されるということを示す電力使用パラメータは、そのタスクをすぐに終了するための根拠を提供することができるということに留意されたい。

【0118】

ブロック６０４の後に、タスク・モニタは、ブロック６０５へ進み、ブロック６０５では、更新された通信リソース・パラメータが、通信リソース・モニタ２３０から得られる。同様に、タスク・モニタは、充電器がオンであるとブロック６０２において判定した場合には、ブロック６０５へ進む。

【0119】

ブロック６０６において、タスク・モニタは、モバイル端末のオペレーションに影響を与えるさまざまなリソースに関連する更新されたパラメータを得る。これらは、たとえば、電力の使用に影響を与える入力／出力（Ｉ／Ｏ）リソースおよびその他の要因を示すパラメータを含むことができる。

【0120】

ブロック６０７において、タスク・モニタは、パワーアウェアな選択基準を適用するために使用されるしきい値を更新し、たとえば、特定のタスクもしくはタスクのクラスまたはアプリケーションに関してその選択基準をオーバーライドすべきであることを示すためのフラグを更新する。これに関連して、バッテリ状態、所与のタスクの予想されるエネルギー使用、および何らかのオーバーライド・フラグの存在を示す相対的に少ない数のパラメータをパワーアウェア・タスク・スケジューラに提供することによって、タスク・モニタは、スケジューラが、シンプルなしきい値の比較に基づいて非常に迅速な決定を行えるようにするということに留意されたい。

【0121】

ブロック６０８において、タスク・モニタは、更新されたアプリケーション・プロファイル・パラメータをアプリケーション・プロファイラ２２０から得る。

【0122】

それぞれブロック６０５〜６０８によって表されている更新オペレーションのうちのそれぞれは、自分の関連付けられているパラメータを別々の頻度で更新することができる。たとえば、各更新オペレーションのそれぞれは、カウンタに関連付けることができ、そのカウンタは、更新オペレーションをトリガーし、この図において示されているコントロール・ループ６０２〜６０９の指定された回数の反復の後にリセットする。そのような指定された回数の反復は、固定することができ、または、たとえば適合アルゴリズムによって設定される動的な値とすることができる。

【0123】

ブロック６０５〜６０８に関して示されている特定の順序は、例示的なものにすぎず、限定するものではないということに留意されたい。その他の可能な構成は、当業者にとって明らかであろう。

【0124】

ブロック６０９は、さまざまなパラメータに関する更新頻度をコントロールするためにコントロールされることが可能である待機時間を表している。それぞれの実施態様は、有利なことに、高い計算負荷につながる高い更新頻度と、エネルギー使用の不正確なコントロールにつながる可能性がある低い更新頻度との間の適切なトレードオフを確立することになる。これに関連して、タスク・スケジューラは、典型的には、１ミリ秒または数ミリ秒の範囲のサイクル時間で機能するが、パワーアウェア・タスク・モニタは、典型的には、はるかに長いサイクル時間で機能し、そのサイクル時間の範囲は、たとえば数秒、または数十秒でさえ、またはそれ以上でさえあることが可能であるということに留意されたい。

【0125】

次いで、パワーアウェア・タスク・スケジューラのさらに詳細な論考に移る。パワーアウェア・タスク・スケジューラ（図２においては、要素２５０として示されている）は、タスクを完了させるのに必要とされるリソースを特定するために、およびバッテリ寿命に対する影響を予想するために、アプリケーション・プロファイル、チャネル品質、予想されるタスク持続時間、およびその他の要因を考慮に入れる。モバイル端末内のパワーアウェア・タスク・スケジューラは、救急呼び出し、健康状態のモニタリング（ｈｅａｌｔｈ ｍｏｎｉｔｏｒｉｎｇ）、認証、ならびに支払いおよびバンキング用途などのクリティカルなサービスのために電力を取っておくことができる。

【0126】

以降の論考から明らかになるように、パワーアウェア・タスク・スケジューラは、典型的には、タスクを完了させるために必要とされる総エネルギーの推定値に基づいてスケジューリングの決定を行うことになる。しかし、たとえば、予想されるタスク持続時間とともにエネルギー消費の度合いを考慮に入れる場合には、総エネルギー要件の明確な推定値を計算することは不要とすることができる。したがって、エネルギー消費度合いを、たとえば１つまたは複数のしきい値と比較することができ、それらのしきい値は、タスク持続時間などのその他の変数に依存することができる。

【0127】

消費度合いおよび総消費の推定値は、さまざまな種類の推定値とすることができ、ピーク値、平均値、および確率的な推定の推定値を含むが、それらには限定されないということにも留意されたい。

【0128】

パワーアウェア・タスク・スケジューラは、残っているバッテリ電力がしきい値未満に低下した場合には、少なくともいくつかのアプリケーションへの承認を拒否することによって、電力の予備を実施することができる。代替として、または追加として、パワーアウェア・タスク・スケジューラは、残っているバッテリ電力が、次の充電の予想時刻よりも前にしきい値未満に低下することが予想される場合には、そのような承認を拒否することによって、電力の予備を実施することができる。これに関連して、充電と、次の充電との間の予想される時間は、たとえば、２０時間などのデフォルト値に予め設定されることが可能であり、またはユーザによって構成されること、もしくは適合するように決定されることが可能である。

【0129】

したがって、たとえば、残っているバッテリ電力が２０％未満である場合には、長時間のビデオ送信を拒否することができ、残っているバッテリ電力が１０％未満に低下した場合には、必須ではないアプリケーションを拒否することができ、残っているバッテリ電力が５％未満に低下した場合には、通常の音声通話を拒否することができる。

【0130】

パワーアウェア・タスク・スケジューラは、モバイル端末内のその他のモジュールによって提供される情報だけでなく、ワイヤレス・ネットワーク内のエンティティによって提供される情報も利用することができる。たとえば、ネットワーク内の１つまたは複数のサーバは、モバイル端末のバッテリ電力およびアプリケーション・プロファイルに関する情報をパワーアウェア・タスク・スケジューラに提供することができる（とりわけ、バッテリ・モデルは、ネットワーク内のそのようなサーバにおいて実施することができる）。その方法においては、ネットワークは、電力消費量の多いアプリケーションをいつどのようにしてサポートすべきかを決定する上で役立つことができる。ネットワークは、ロケーションベースのカバレッジ情報をモバイル端末に提供することもできる。たとえば、ネットワークは、ユーザが現在（たとえば、建物または地下道に起因する）無線の陰にいることを認識できるようにすることができる。適切なモビリティ・モデルが提供される場合には、たとえば、ネットワークは、モバイル端末がそのまま自分の現在のパス上にいれば、すぐによりよいカバレッジのエリアに入ることになるということをモバイル端末に通知できるようにすることができる。

【0131】

そのような情報に基づいて、モバイル端末およびネットワークは、モバイル端末における通信および処理のために必要とされる電力を減らすように通信戦略を調整することができる。

【0132】

調整することができる１つの通信戦略は、メディアの選択である。たとえば、完全なビデオ送信を行う代わりに、オーディオのみを送信することを選択することができる。別の調整可能な戦略は、たとえばオーディオまたはビデオ信号の品質の選択である。別の調整可能な戦略は、送信のタイミングである。現在のワイヤレス・チャネル品質が貧弱である場合には、チャネル品質が改善するまでアップリンク送信を遅延させることによって、電力を節約することができる。

【0133】

送信を遅延させる戦略は、少なくとも２つの点で電力を節約することができ、許容可能なスループットによって、チャネル状態が良好である場合には、および良好なチャネル状態のもとでは、必要とする送信電力および処理能力が、より少なくてすみ、アップリンク無線リソースを獲得しようと繰り返し試みることに起因するモバイル端末のバッテリ上での枯渇が、より少なくてすむ。

【0134】

パワーアウェア・タスク・スケジューラは、いくつかの現在のモバイル端末において実施されている種類のローレベルな電力マネージメント・コントロール機能（ｌｏｗ−ｌｅｖｅｌ ｐｏｗｅｒ ｍａｎａｇｅｍｅｎｔ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）に勝るさらに良好なコントロールを可能にする機能を含むこともできる。そのようなコントロール機能の例としては、ディスプレイを低電力モードに切り替える減光機能、ならびに、端末のアクティブでないコンポーネントをオフに切り替えることができ、送信機および受信機などのその他のコンポーネントを間欠的なスリープ・モードに置くことができる電力節減機能がある。さらに別のコントロール機能は、プロセッサ自体のダイナミック・ボルテージ・スケーリングとすることができる。

【0135】

特定のアプリケーションを完了させるのに十分な容量が残っているかどうかの判定は、当該アプリケーションの推定された電力要件および持続時間だけでなく、既存のタスクおよびプロセスの全体のエネルギー消費度合いにも基づくことができるということに留意されたい。そのような判定は、スケジューリング用のタスクの承認、ならびにそのタスクに関するスケジューリングの決定に影響を与えることができる。

【0136】

電力要件に関しては、アプリケーション電力しきい値（ＡＰＴ：ａｐｐｌｉｃａｔｉｏｎ ｐｏｗｅｒ ｔｈｒｅｓｈｏｌｄ）は、はじめから所与のアプリケーションを完了させるまでに必要とされる推定された電力に、クリティカルなアプリケーションのために必要とされる最小の電力をプラスした値であると前述の論考において定義したことが思い出されるであろう。これによって、クリティカルなアプリケーションを実行するための予備として取っておくための電力の量を指定することが可能になる。

【0137】

ＡＰＴは、バッテリ内における利用可能な電力のパーセンテージとして定義することもできる。アプリケーションおよびサービスの別々のクラスごとにＡＰＴの別々の値を設定することができる。したがって、別々の相対的な優先順位を有するアプリケーション同士には、区別した取り扱いを与えることができ、それによって、たとえば、バッテリ残量が少ないが、クリティカルに少ないわけではない場合には、高い優先順位のアプリケーションをスケジュールすることができ、その一方で、より低い優先順位のアプリケーションを却下することができる。タスクが却下される（または一時停止される）ことになる場合には、オペレーティング・システムは、ユーザへの対応するメッセージを生成するための特別なソフトウェア・トラップを実行することができ、次いでそのタスクをスケジューラから出すことができる。

【0138】

新たなタスクに関しては、ＡＰＴは、アプリケーション全体を完了させるために必要とされる推定された電力に、クリティカルなアプリケーションのために必要とされる最小の電力をプラスした値となる。戻ってくるタスクに関しては、対照的に、ＡＰＴは、アプリケーションの残っている部分を完了させるために必要とされる推定された電力に、クリティカルなアプリケーションのために必要とされる最小の電力、およびその他の承認されたアプリケーションの予想された電力消耗（ｐｏｗｅｒ ｄｉｓｓｉｐａｔｉｏｎ）をプラスした値となる。タスクが実行されるようにスケジュールされている場合には、そのタスクは、完了まで実行されてシステムから出るか、またはスケジューリングの次なるサイクルのために戻ってくる。パワーアウェア・タスク・スケジューラの実際の実施態様については、数ある考慮事項の中でもとりわけ、特定のホスト・オペレーティング・システムのプロパティによって指示することができるということに留意されたい。

【0139】

スケジューラは、たとえば、バッテリ電力が最小のしきい値未満であるために、または通信リソースが所要のしきい値未満であるために、タスクを実行することが勧められないと判定した場合には、ユーザに警告メッセージを送信することができる。次いでユーザは、スケジューラのパワーアウェアな部分を迂回して、モバイルにタスクを実行させることを決めることができる。

【0140】

図７は、パワーアウェア・タスク・スケジューラを実装するための１つの可能なアーキテクチャの機能ブロック図を提供する。図７については、以降でさらに詳細に論じる。その一方で、図８Ａは、図７と併せて読めば、最も容易に理解される。

【0141】

次いで図８Ａを参照すると、タスクに関する電力しきい値に基づくスケジューリングまたは承認の決定を示すハイレベルな流れ図が示されている。これは、承認モジュールにおいて、ならびにパワーアウェア・タスク・スケジューラにおいて実施することができる１つの機能である。上述のように、電力しきい値は、タスク全般に適用することもでき、アプリケーションまたはタスクの別々のクラスごとに別々のものとすることもでき、または個々のタスクまたはアプリケーションごとに特別に構成することもできる。電力しきい値を実施する１つの利点は、そのような実施によって、クリティカルと指定されているタスクのための予備として電力を取っておくことができることである。したがって、クリティカルなタスクは、いかなるしきい値も課すことなく承認および実行することができ、または、たとえば非常に低いしきい値を課すことができ、それによって、バッテリを完全に使い果たすときが差し迫っている場合にのみ、それらのクリティカルなタスクが却下されることになる。

【0142】

この図において見て取れるように、ブロック８０１において、受信タスク・キュー７３０またはレディ・キュー７４０（これらの両方については、図７において示されており、以降で論じる）などのキューからタスクが選択される。ブロック８０２において、承認モジュールまたはスケジューリング・モジュールは、利用可能なバッテリ電力が、適用可能なしきい値よりも多いかどうかを判定する。利用可能な電力が十分にある場合には、ブロック８０３によって示されているように、タスクは、実行されるように承認またはスケジュールされる。利用可能な電力が十分にない場合には、承認モジュールがタスクを却下するか、またはスケジューリング・モジュールが、ブロック８０４において示されているように、警告を発行するか、またはタスクを一時停止もしくは却下する。

【0143】

図８Ｂは、例示的なプロセス・コントロール・ブロック８１０に関するフォーマット図である。当業者によく知られているように、プロセス・コントロール・ブロックは、タスク・スケジューリングのためにオペレーティング・システムが必要とするタスク固有の情報をオペレーティング・システムに提供する。プロセス・コントロール・ブロックは、承認モジュールおよびパワーアウェア・スケジューリング・モジュール（これらについては、それぞれ以降で図９Ａおよび図９Ｂに関連して論じる）において処理される情報の基本的なユニットである。

【0144】

図８Ｂのプロセス・コントロール・ブロックは、より従来型のプロセス・コントロール・ブロックと比較して、電力関連データ・フィールドを含むように修正されている。すなわち、この図において示されている電力コントロール・ブロックは、識別子、状態、優先順位、プログラム・カウンタ、メモリ・ポインタ、コンテキスト・データ、Ｉ／Ｏステータス情報、およびアカウンティング情報などの従来のプロセス要素を含む。しかし、この電力コントロール・ブロックは、電力関連フラグおよび電力関連情報などのさらなるプロセス要素も含む。電力関連フラグは、たとえば上述のオーバーライド・フラグを含むことができる。電力関連情報は、上述の電力しきい値、ならびに、たとえば図２のパワーアウェア・タスク・モニタ２４０によって提供されるその他のアプリケーション・プロファイル・パラメータを含むことができる。

【0145】

次いで図９Ａおよび図９Ｂを参照する。図９Ａおよび図９Ｂは、例示的なパワーアウェア・タスク・スケジューリング・サブシステム内の機能のオペレーションを示す流れ図である。スケジューリング・サブシステムは、図９Ａによって示されているオペレーションを有する承認モジュールと、図９Ｂによって示されているオペレーションを有するパワーアウェア・スケジューリング・モジュールとを含む。図９Ａおよび図９Ｂは、図７のブロック図と併せれば、最もよく理解され、図７では、パワーアウェア・タスク・スケジューリング・サブシステム７００は、パワーアウェア承認モジュール７１０およびパワーアウェア・タスク・スケジューラ７２０を含むものとして示されている。そしてタスク・スケジューラは、タスク・セレクタ７５０、およびパワーアウェア・スケジューリング・モジュール７６０を含む。図７のさらなる詳細については、以降で論じる。

【0146】

次いで図９Ａを参照すると、承認モジュールは、はじめに図７の受信タスク・キュー７３０などのキューからタスクを選択する（９２０）。承認モジュールは、タスクが電力関連判定ポイントを迂回することを許可されている旨を示すタスク・バイパス・フラグ（ＴＢＦ：ｔａｓｋ ｂｙｐａｓｓ ｆｌａｇ）が設定されているかどうかをチェックする（９２１）。ＴＢＦは、たとえばシステム・タスク用に、ならびにその他の指定されたタスク用に事前に構成することができるフラグである。これに関連して、ここで言及するさまざまなフラグは、個々のバイナリ値パラメータとして取り扱うことができ、または１つもしくは複数の複数値パラメータへとグループ化することができるということに留意されたい。

【0147】

ＴＢＦが設定されている場合には、承認モジュールは、モバイル端末におけるリソースおよび通信リソースなど、タスクが実行される上で必要とされるすべてのリソースが利用可能であるかどうかをチェックする（９２２）。タスクが実行される上で必要とされるすべてのリソースが利用可能である場合には、タスクは承認される（９２３）。タスクが実行される上で必要とされるすべてのリソースが利用可能というわけではない場合には、タスクは却下される（９２９）。

【0148】

判定ポイント９２１に戻ると、電力関連判定ポイントを迂回するためのフラグがタスクに設定されていない場合には、承認モジュールは、そのタスクの優先順位またはクリティカル性レベルをチェックする（９２４）。優先順位またはクリティカル性レベルが、電力関連判定ポイントを迂回するほど十分に高い場合には、承認モジュールは、判定ポイント９２２におけるリソース・チェックへ進む。優先順位またはクリティカル性レベルが、電力関連判定ポイントを迂回するほど十分に高くない場合には、承認モジュールは、ユーザ・オーバーライド・フラグ（ＵＯＦ：ｕｓｅｒ ｏｖｅｒｒｉｄｅ ｆｌａｇ）が設定されているかどうかをチェックする（９２５）。典型的には、ユーザは、以降で説明するように、パワーアウェア・タスク・スケジューラによって発行された警告に応答してＵＯＦを設定することになる。

【0149】

ＵＯＦが設定されている場合には、承認モジュールは、判定ポイント９２２へ進む。ＵＯＦが設定されていない場合には、承認モジュールは、電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っているかどうかをチェックする（９２６）。電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っている場合には、承認モジュールは、判定ポイント９２２へ進む。電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っていない場合には、承認モジュールは、要求オーバーライド（ＲＱＯ：ｒｅｑｕｅｓｔ−ｏｖｅｒｒｉｄｅ）フラグが設定されているかどうかをチェックする（９２７）。ＲＱＯが設定されているときに（たとえば、バイナリ値ＲＱＯ＝１を有するときに）、ユーザは、パワーアウェア・タスク・スケジューラによる警告を受けた場合には、タスクの承認に続いて、ＵＯＦを手動で設定することによって、タスクの実行を強行することを許可される。ＲＱＯが設定されている場合には、承認モジュールは、判定ポイント９２２へ進む。ＲＱＯが設定されていない場合には、タスクは却下される（９２９）。

【0150】

次いで図９Ｂを参照すると、図７のスケジューラ７６０などのスケジューラが、はじめに、承認されたタスクをレディ・キュー７４０などのキューから選択する。図７において示されているように、これは、タスク・セレクタ７５０の助けを借りて行うことができる。スケジューラは、ＴＢＦが設定されているかどうか、すなわち、電力関連判定ポイントを迂回するためのフラグがそのタスクに設定されているかどうかをチェックする（９３１）。ＴＢＦが設定されている場合には、スケジューラは、タスクの実行のために必要とされるすべてのリソースが利用可能であるかどうかをチェックする（９３２）。タスクの実行のために必要とされるすべてのリソースが利用可能である場合には、タスクは、実行されるようにスケジュールされ、実行される（９３８）。タスクの実行のために必要とされるすべてのリソースが利用可能というわけではない場合には、スケジューラは、判定ポイント９３６へ進み、判定ポイント９３６については、以降で論じる。ここでは、判定ポイント９３６の生じ得る結果は、タスクの却下もしくは一時停止、またはユーザへの警告の発行であるということに言及しておく。警告９３９Ｃの結果については、以降でさらに詳細に論じる。

【0151】

判定ポイント９３１へ戻ると、ＴＢＦが設定されていない、すなわち、電力関連判定ポイントを迂回するためのフラグがタスクに設定されていないとスケジューラが判定した場合には、スケジューラは、判定ポイント９３３へ進み、判定ポイント９３３では、スケジューラは、タスクの優先順位またはクリティカル性レベルをチェックする。優先順位またはクリティカル性レベルが、電力関連判定ポイントを迂回するほど十分に高い場合には、スケジューラは、判定ポイント９３２におけるリソース・チェックへ進む。優先順位またはクリティカル性レベルが、電力関連判定ポイントを迂回するほど十分に高くない場合には、スケジューラは、ユーザによって構成されたオーバーライド・フラグＵＯＦが設定されているかどうかをチェックする（９３４）。ＵＯＦが設定されている場合には、スケジューラは、判定ポイント９３２へ進む。ＵＯＦが設定されていない場合には、スケジューラは、電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っているかどうかをチェックする（９３５）。電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っている場合には、スケジューラは、判定ポイント９３２へ進む。電力しきい値に基づく選択基準のうちのすべてを満たすのに十分な放電容量がバッテリに残っていない場合には、スケジューラは、判定ポイント９３６へ進む。

【0152】

上述のように、スケジューラは、判定ポイント９３２から、ならびに判定ポイント９３５から、判定ポイント９３６に入ることができる。判定ポイント９３６に達すると、スケジューラは、ＲＱＯが設定されているかどうかをチェックする。ＲＱＯが設定されている場合には、スケジューラは、低電力警告をユーザに発行すること、およびユーザから手動入力を受け取ることが可能になり、その結果、タスクの実行を強行したいという希望をユーザが示した場合には、ＵＯＦが設定される（すなわち、ＵＯＦ＝１に設定される）。この図においては明示的に示されていないが、警告はもちろん、タスクがまさに一時停止または却下されつつある場合に発行することもできる。

【0153】

したがって、ＲＱＯが設定されている場合には、スケジューラは、警告を発行させる（９３９Ｃ）。この図においては明示的に示されていないが、スケジューラはまた、図９Ａの承認モジュールに関するウェイト・キュー内にタスクを置く。承認処理の次なるサイクルにおいて、およびユーザによって構成されたＲＱＯの値を含むフラグ値に関する報告をタスク・モニタが行った後に、承認モジュールは、判定ポイント９２７においてＲＱＯを読み取り、その結果は、上で説明したようになる。

【0154】

ＲＱＯが設定されていない場合には、スケジューラは、タスクを一時停止することができるかどうかを判定するためにチェックを行う（９３７）。タスクを一時停止することができる場合には、スケジューラは、タスクを一時停止させる（９３９Ｂ）。タスクを一時停止することができない場合には、スケジューラは、タスクを却下させる（９３９Ａ）。これに関連して、一時停止されたタスクは、別のスケジューリングの試みのためのキューに自動的に戻ることができ、その一方で、却下されたタスクは、キューから永久に除去されるということに留意されたい。たとえば、利用可能な電力およびその他の状態が、（たとえば、定期的なチェックの結果として電力モニタによって示された際に）選択基準を満たすレベルに戻った場合には、一時停止されたタスクがまだタイムアウトしていないならば、それらのタスクを自動的に再アクティブ化することができる。

【0155】

スケジューラによって処理されるタスクは、新たに承認されたタスク、ならびに処理のさらなるラウンドのために戻ってきたタスクを含むということにも留意されたい。それぞれのタスクを、パワーアウェアなスケジューリングの決定のために考慮することができるようにレディ・キューから選択することは、たとえば従来のスケジューリング・アルゴリズムの機能を使用して行うことができる。

【0156】

次いで、パワーアウェアなタスク・スケジューリングをマルチタスク・モバイル・オペレーティング・システムにおいてどのようにして実施することができるかについてのさらなる詳細を提供する。

【0157】

マルチタスク・モバイル・オペレーティング・システム内のパワーアウェア・タスク・スケジューラの１つの例示的なアーキテクチャが、図７の機能ブロック図において示されている。示されているアーキテクチャにおいては、パワーアウェア・タスクスケジューリング・サブシステム７００は、パワーアウェア・タスク承認モジュール７１０およびパワーアウェア・タスク・スケジューラ７２０を含む。スケジューラ機能ブロック７２０は、図２のスケジューラ機能ブロック２５０に対応する。

【0158】

パワーアウェア・タスク承認モジュールは、ゲートキーパとして機能し、すなわち事実上、アプリケーションをそれらのアプリケーションのクリティカル性および電力要件に基づいて承認する長期的なスケジューラである。このモジュールは、新たなタスクが、ユーザによって、またはオペレーティング・システムによって開始されるときに常に呼び出される。このモジュールは、前述のような電力消費基準を含むさまざまな基準を使用することによって、どのタスクが実行を承認されるかを決定する。複数の新たなタスクが同時に入力へ到来した場合には、タスク承認モジュールは、たとえば、シンプルなＦＩＦＯ（ｆｉｒｓｔ−ｉｎ， ｆｉｒｓｔ−ｏｕｔ）スキームを採用して、承認の決定のためにタスクを選択することができる。受信キュー７３０からの受信タスクは、実行を承認された場合には、パワーアウェア・タスク・スケジューラ７２０によって、さらなるスケジューリングのためにレディ・キュー７４０内に置かれることになる。

【0159】

例示的なパワーアウェア・タスク・スケジューラは、従来の種類のタスク・セレクタ７５０を含み、そのタスク・セレクタ７５０に、パワーアウェア・スケジューリング・モジュール７６０が加えられる。モジュール７６０は、短期的なタスク・スケジューリングを提供し、その短期的なタスク・スケジューリングは、レディ・キュー内にあるタスクにプロセッサ時間を効率よく割り当てることを目的としている。レディ・キュー内にあるタスクは、新たに承認されるタスクだけでなく、入力／出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）オペレーション後に前のスケジュール・サイクルから戻ってきたタスク、クリティカル・セクションからのタスク、メイン・メモリへとスワップされるタスク、または割り込みからのタスクも含む。

【0160】

これに関連して、「クリティカル・セクション」とは、共有されたメモリ・エリア、共通のファイル、共通の変数、またはその他の何らかの共通のリソースへのアクセスを有する、プログラムのセグメントである。クリティカル・セクションにおいて１つのタスクが実行されている場合には、その他のタスクは通常、そのクリティカル・セクションにおいて実行されることを許可されない。したがってオペレーティング・システムは、ゲートキーパとして機能して、所与の時点で１つのタスクのみがそのクリティカル・セクションへのアクセスを有することができるようにする。

【0161】

「スワッピング」とは、メイン・メモリの利用可能なスペースが限られている場合にオペレーティング・システム（ＯＳ）が実行することができるオペレーションである。したがってＯＳは、既存の（ただし実行されていない）プロセスをメイン・メモリから、ハード・ディスクなどのセカンダリー・ストレージ内へ、または拡張された低速ＲＡＭメモリへスワップして、新たに到来するプロセスのためにスペースを空けることができる。スワップ・インは、ＯＳが、スワップ・アウトされたプロセスを実行のさらなるラウンドのためにメモリ内へ戻す場合に生じる。

【0162】

タスクの選択は、ＦＩＦＳ（ｆｉｒｓｔ−ｉｎ−ｆｉｒｓｔ−ｓｅｒｖｅｄ）、ＳＪＦ（ｓｈｏｒｔｅｓｔ−ｊｏｂ ｆｉｒｓｔ）、ＳＲＴＦ（すなわち、ｓｈｏｒｔｅｓｔ−ｒｅｍａｉｎｉｎｇ ｔｉｍｅ−ｆｉｒｓｔ、プリエンプティブなＳＪＦアルゴリズムの異形）、ラウンド・ロビン、優先順位ベース、マルチレベル・キュー、マルチレベル・フィードバック・キュー、または任意の専用アルゴリズムなど、さまざまな知られているアルゴリズムのうちの任意のものを使用して、達成することができる。いくつかのオペレーティング・システムは、これらのアルゴリズムの組合せを採用している。

【0163】

パワーアウェア・スケジューリング・モジュールが、タスクの実行をスケジュールすることを決めた場合には、そのタスクは、ディスパッチャ７７０へ引き渡される。ディスパッチャの役割は、選択されたタスクに、クォンタムまたはタイム・スライスと呼ばれる指定された持続時間にわたるプロセッサのコントロールを提供することである。マルチタスク・オペレーティング・システムにおけるプロセッサ時間クォンタムは、通常は１０ミリ秒（１０ｍｓ）の倍数で設定される。たとえば、Ｌｉｎｕｘオペレーティング・システムにおける時間クォンタムは、１０ｍｓから２００ｍｓまで変わる。このクォンタム中に、タスクは、実行されて完了するか、またはそうでなければ、レディ・キューへ再び戻る前に待機状態へ移行する。

【0164】

タスク選択プロセスの終わりに、パワーアウェア・タスク・セレクタ７５０は、現在選択されているタスクが長時間にわたって実行されているかどうかをチェックする。この持続時間は、たとえば、アプリケーションがタスク・スケジューラ７２０内を循環した回数で指定することができる。実行持続時間のそのようなチェックは、たとえば、バッテリの消耗度合いについて、所与のアプリケーションだけでなく、実行されているその他のすべてのタスクも視野に入れて考慮することが望ましい場合に、有利であることがある。全体の消耗度合いが相対的に高くなった場合には、所与のアプリケーションが引き続き実行されることを許可されるべきかどうかを再査定することが望ましいことがある。そのような再査定は、所与のアプリケーションの優先順位レベルを考慮して、および実行されている可能性があるその他のアプリケーションの優先順位レベルを考慮して行うことができる。

【0165】

図７において示されているように、パワーアウェア・タスク・スケジューラ７２０は、従来のタスク・スケジューラの機能を、本明細書に記載されている新たなパワーアウェア機能と統合する。その他の実施態様においては、従来のタスク・スケジューラと、パワーアウェア・タスク・スケジューラは、たとえば並列構成または直列構成で、別々のエンティティとして機能することができる。

【0166】

１つの可能な並列構成（図示せず）においては、レディ・キュー７４０およびディスパッチャ７７０は、従来のスケジューラおよびパワーアウェア・スケジューラの両方にサービス提供し、タスク・セレクタ７５０は、別々のクラスのタスクを別々のスケジューラへ導くために使用される。たとえばタスク・セレクタは、ＯＳタスクを従来のスケジューラへ、そしてユーザ・タスクをパワーアウェア・スケジューラへ導くことができる。あるいは、各スケジューラのそれぞれは、自分自身のレディ・キューおよびタスク・セレクタを有することができる。

【0167】

１つの可能な直列構成（図示せず）においては、パワーアウェア・タスク・スケジューラは、シーケンス内の最初のスケジューラであり、その後に従来のタスク・スケジューラが続く。パワーアウェア・スケジューラは、たとえばユーザ・タスクに関してのみ機能し、ＯＳタスクについては、従来のスケジューラに渡すだけである。従来のスケジューラは、パワーアウェア・スケジューラによって一時停止または却下されたタスクに関しては機能せず、それらのタスクをディスパッチャに渡すだけである（ディスパッチャは、たとえば、従来のスケジューラのコンポーネントとして組み込むことができる）。対照的に、警告が発行されているタスクは、従来のスケジューラによって処理される。代替構成においては、パワーアウェア・タスク・スケジューラをシーケンス内の第２のスケジューラにして、その前に従来のタスク・スケジューラを置くことができる。

【0168】

タスクを実行するようにスケジュールするかどうかの決定は、アプリケーションのタイプによって識別されるタスクのクリティカル性、タスクの実行時間、タスクを完了させるために必要とされる電力の量、およびそのタスクに関する通信しきい値に基づく。たとえば実行時間の予測が困難である場合には、電力消費の度合いが重要になる場合もある。タスクをさらに実行するようにスケジュールすることができないケースにおいては、ＯＳは、そのタスクが一時停止または却下されていることをユーザに警告することができる。ＯＳは、ユーザが、たとえば前述のようにオーバーライド・フラグを設定することによって、パワーアウェアなスケジューリングの決定をオーバーライドすることを可能にすることができる。

【0169】

プロセッサにとっては、数ミリ秒ごとにタスク間の切り替えを行うことが典型的であるため、パワーアウェア・タスク・スケジューラは、毎秒数百回、またはさらに高い頻度で、戻ってくるタスクに関して複雑な再評価を行うために呼び出され得る可能性がある。したがって、そのような再評価に関して時間および電力が過度に浪費されることを回避するために、パワーアウェア・タスク・スケジューラを可能な限り最高の効率で機能させることが望ましい。パワーアウェア・スケジューラが決定を行う際に用いるプロセスが、パワーアウェア・タスク・モニタによって既に計算されているしきい値に関する少数の比較オペレーションに限定される場合に、パワーアウェア・スケジューラの効率を維持することができる。これに関連して、バッテリ充電レベルが非常に低いためにクリティカルなアプリケーションしか許可されない場合には、必須でないタスク・モニタリングおよびスケジューリング機能を減らすこと、またはオフに切り替えることさえ可能であることが有利であるということに留意されたい。

【0170】

図７をさらに参照すると、プロセッサ７８０におけるタスク処理は、さまざまな結果を有する可能性があるということが見て取れるであろう。タスクは、完了した場合には、この図において示されているように、処理ループから出ることになる。当技術分野においてよく知られているように、タスクは、完了に至ることなく自分の割り当てられた最大の処理時間に達した場合には、タイムアウトすることができる。そのような場合には、そのタスクは、典型的には、図示されているように、処理ループ内を循環して戻ることになる。いくつかのタスクは、さらなる処理のために必要な条件が満たされたことを示すトリガーが受信されるまで、待機状態に入ることが必要となる場合がある。

【0171】

複数のキューを確立することができ、それぞれのキューは、そのキューに特有のイベントを待っているタスクを表す。そのイベントが発生した場合には、そのキュー内で待機しているタスクは、レディ・キューに戻ることができる。この図において示されているのは、実際にはｎ個もの別々のキューが存在することができることを示すために「ＥＶＥＮＴ１−ｎ ＷＡＩＴ」と標示されている１つの代表的なキューである。言い換えれば、この図において示されているキューは、ｉ番目のキューであり、この場合、ｉ＝１、…、ｎである。トリガリング・イベントは、たとえばディスプレイのアクティブ化、またはワイヤレス接続の確立とすることができる。

【0172】

次いで、本明細書に記載されている原理を含む２つの特定のユース・ケースを参照する。第１のユース・ケースは、クリティカルなアプリケーションを保護し、第２のユース・ケースは、変動するネットワーク状態の存在下でネットワーク接続を保護する。

【0173】

ユース・ケース１：クリティカルな端末中心のサービス。アプリケーションは、ユーザまたはサービス・プロバイダによってクリティカルと指定される場合があり、またはたとえばクリティカルなアプリケーションとして政府によって指定される場合がある。モバイル端末は、認証およびセキュリティを含むクリティカルなアプリケーションを実行するためにますます使用されるようになると予想される。たとえば、拡張９１１サービスが、政府によって指定された救急サービスである場合に、それに使用する可能性のために電力の予備を確保することは、クリティカルな要件となることがある。さらなる例においては、専用のバイオメトリック・センサが、認証の目的で特定のハンドセット内に統合されており、そのような認証関連センサは、今後はハンドセットの標準的なコンポーネントになるであろうと予想される。

【0174】

上記では、アプリケーション電力しきい値（ＡＰＴ：ａｐｐｌｉｃａｔｉｏｎ ｐｏｗｅｒ ｔｈｒｅｓｈｏｌｄ）は、はじめから所与のアプリケーションを完了させるまでに必要とされる推定された電力に、クリティカルなアプリケーションのために必要とされる最小の電力をプラスした値であると定義した。その目的は、クリティカルなアプリケーションを実行するための予備として取っておくための電力の量を指定することであった。

【0175】

ここでは、ＴＰＭモジュールは、モバイル端末のバッテリ容量の一部分を取っておくように構成することができ、それによって、その部分は、数ある中でもとりわけ、拡張９１１サービス、およびバイオメトリック・センサに依存する認証機能を含むクリティカルな機能のために安心して利用することができるということにさらに言及しておく。ＴＰＭモジュールは、たとえば、指定されたしきい値を超えた場合には、必須でないアプリケーションをブロックまたは一時停止することによって、そのような電力の予備を達成することができる。そのようなブロックまたは一時停止は、典型的には、前述したＡＰＴに基づくアドミッション・コントロールに追加するものである。

【0176】

望ましくは、ＴＰＭモジュールの機能の一部は、クリティカルなトランザクションのために必要とされるすべてのコンポーネントが、必要とされているときに利用可能であり、かつ完全に機能していることを確実にすることである。したがって、たとえばＴＰＭは、必要な場合には、ディスプレイ・コントロールなどの電力節減機能をオーバーライドすることができるべきである。

【0177】

ユース・ケース２：クリティカルではないネットワーク中心のアプリケーション。モバイル端末のユーザは、たとえば、ポッドキャストを聴くこと、またはその他の何らかの目的でネットワークの中心のサーバからコンテンツをダウンロードすることを望む場合がある。加えて、モバイル端末自体は、たとえばローカル情報、マップ、広告、またはソフトウェア・パッチを更新するために、コンテンツをダウンロードすることを決める場合がある。コンテンツのうちのいくつかは、タイムクリティカルである場合があり、その一方で、その他のコンテンツは、タイムクリティカルでない場合がある。

【0178】

ユーザが移動している場合には、受信品質が著しく変わる可能性がある。たとえばモバイル端末は、高品質の受信エリアから低品質のエリアへ、およびその逆へ移動して、受信品質の絶え間ない変動を引き起こす場合がある。１つの結果として、アプリケーションは、頻繁な機能停止または劣悪な受信の期間を経験する場合がある。

【0179】

貧弱な受信に起因する高いエラー率は、典型的には、通信リンクのタイムアウトを引き起こすことになる。しかし、モバイル端末、ネットワーク、およびアプリケーション・サーバにおいてパワーアウェア・タスク・マネージャを使用することによって、そのようなタイムアウトの発生を回避することまたは少なくとも減らすことが可能である代替策を提供することができる。

【0180】

すなわち、貧弱なチャネル品質に起因するタイムアウトは、典型的には、よく知られているように、たとえばＴＣＰ／ＩＰ層に関しては、より低位のプロトコル層において宣言される。しかし、（より高位の）アプリケーション層においては、ネットワークおよびモバイル端末は、タイムアウトの頻度を減らす様式で貧弱なチャネル状態に適合することができる。たとえば、アプリケーションは、自分がデータをやり取りする度合いを減らすこと、またはその他の何らかの戦略を変えることが可能である。効果的であるためには、そのような適合的なアプローチは、モバイル端末におけるパワーアウェア・タスク・マネージャと、ネットワーク・レベルにおけるパワーアウェア・タスク・マネージャと、アプリケーション・サーバにおけるパワーアウェア・タスク・マネージャとの間のコラボレーションを必要とすることになる。

【0181】

ある例示的なシナリオにおいては、パワーアウェア・タスク・モニタは、現在のチャネル状態に従ってタスク関連パラメータを設定し、パワーアウェア・タスク・スケジューラは、リソースの可用性に基づいてタスクを一時停止および再開する。たとえば、パワーアウェア・タスク・モニタは、タスクの優先順位を変更して、そのタスクが間欠的に一時停止されるようにすること、またはそのタスクがより低い頻度の間隔でスケジュールされるようにすることが可能である。そのような様式で、そのタスクに関連付けられているスループットを貧弱な受信の期間中に低減させて、結果としてそのような期間中のタイムアウトを減らすことができる。

【0182】

とりわけ、受信品質が良好である期間中に高い度合いでダウンロードを実行し、その一方で、貧弱な受信品質の期間中には通信モジュールをセミスリープ・モードに置いて、アプリケーションのための電力消費を最小限に抑えることを可能にすることができる。

【0183】

チャネル品質を評価するためのさまざまな測定値が知られている。これらは、スループット、信号対干渉雑音比（ＳＩＮＲ：ｓｉｇｎａｌ−ｔｏ−ｉｎｔｅｒｆｅｒｅｎｃｅ−ａｎｄ−ｎｏｉｓｅ ｒａｔｉｏ）、フレーム・エラー率、および送信電力レベルの測定値を含む。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9A】

【図9B】