特許 5785273 モバイル通信端末のためのスマート電力管理の方法および装置

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

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

(11)【特許番号】5785273

(24)【登録日】2015年7月31日

(45)【発行日】2015年9月24日

(54)【発明の名称】モバイル通信端末のためのスマート電力管理の方法および装置

(51)【国際特許分類】

   H04M 1/73 20060101AFI20150907BHJP

   H04W 88/02 20090101ALI20150907BHJP

   H04W 52/02 20090101ALI20150907BHJP

【ＦＩ】

   H04M1/73

   H04W88/02 131

   H04W52/02 130

【請求項の数】10

【全頁数】34

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

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

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

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

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

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

(87)【国際公開日】20120816

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

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

(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】

前記第１のモジュール、前記第２のモジュール、および前記タスク・スケジューリング・モジュールが使用可能である第１のモードにおいて、または少なくとも前記第２のモジュールが使用不可であり、スケジューリング決定が前記基準を参照することなく行われる第２のモードにおいて、前記モバイル端末が起動するように構成可能である、
請求項８に記載のモバイル通信端末。

【請求項10】

前記タスクを前記タスク・スケジューリング・モジュールに転送するかどうかを決定するように構成されたタスク・アドミッション・モジュールであって、前記転送決定がバッテリ状態の前記表示に依存する、タスク・アドミッション・モジュールをさらに備える、請求項８に記載のモバイル通信端末。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モバイル通信端末における電力管理に関する。

【背景技術】

【0002】

モバイル端末は、カメラ付きの単純な電話から、強力なプロセッサ、大量のメモリ、高解像度カメラ、複数のセンサ、および接触感知専用の大きなディスプレイを備える、強力な多機能デバイスに急速に進化している。同時に、モバイル端末は、小さなフォーム・ファクタを有し、このことが、バッテリのサイズおよび形状に制約を課す。現在のモバイル端末は、強力なバッテリを有するものの、オンライン・ゲームならびにストリーミング・ビデオおよびオーディオなどのリアルタイム・アプリケーションを含む、様々なアプリケーションを同時に実行するモバイル端末の能力が、モバイル端末が再充電することなく動作し続けることができる時間に、厳しい制約を課す。

【0003】

これまでは、モバイルフォンの性能は、バッテリ再充電の間の「連続通話時間」および「スタンバイ」時間の観点で測定され、最初の尺度は、モバイルフォンが通話で使用される場合にバッテリがモバイルフォンに給電できる総時間を示し、後者は、バッテリが電話を動作可能にしておける総時間のことである。現在では、アプリケーション毎の電力消費の違いを考慮して、例えば、「インターネット使用時間」、「ビデオ再生時間」、および「オーディオ再生時間」など、さらなる性能パラメータが導入されている。

【0004】

しかし、複数のサービスが同時に使用される場合、バッテリは、急速に枯渇しやすく、そのため、モバイル端末がどれだけ速やかに電力を使い果たすかを正確に予測することが難しくなる。バッテリ電力が低下している場合、ユーザは、あるアプリケーションを使用しない、または短時間しか使用しないことによって、電力消費を削減しようと試みることができる。しかし、多くのアプリケーションについては、ユーザがモバイル端末の電力消費を推定し、制御するのは難しいことがあり、いくつかのアプリケーションおよびサービスは、バックグランドで動作することがあり、そのことによって、ユーザからいくつかのアプリケーションおよびサービスをかなり見えにくくする。バッテリに実際に残っている電力を知らずにアプリケーションを開始すると、電力が多く残っていないときに、電力を大量消費するアプリケーションをモバイル端末に起動させて、残存電力を速やかに枯渇させ、再充電されるまで端末を動作できなくすることがある。

【0005】

モバイル端末は、高集積、低電力チップセットを使用する。チップセット、特にプロセッサにおける電力消費は、供給電圧Ｖ、クロック周波数ｆ、アクティブに切り換えられたゲートの割合ａ、および漏れ電流Ｉ_ｌによって、大部分が決定される。プロセッサの全電力消費Ｐは、動的電力項と静的電力損失項の和であり、一般に、Ｐ＝ａＣＶ^２ｆ＋ＶＩ_ｌによってモデル化され、ここで、Ｃは、論理ゲートのキャパシタンス負荷を表す。

【0006】

モバイル端末で使用されるプロセッサは、一般に、静的電力損失が非常に低い。内部モジュールが使用されていないときに、コンポーネントが内部モジュールをオフに切り換えることができる場合、電力を大きく節約することができる。プロセッサは、動的周波数スケーリングをサポートするように設計することができ、動的周波数スケーリングは、動的電力項を線形に低減することを可能にする。供給電圧が動的に調整可能である場合、２次の低減を実現することができる。これは、動的電圧スケーリング（ＤＶＳ：ｄｙｎａｍｉｃ ｖｏｌｔａｇｅ ｓｃａｌｉｎｇ）と呼ばれ、電力最適化のための最古の手法の１つである。一般に、供給電圧を低下させると、達成可能な最大クロック周波数が低減されるので、電圧とクロック周波数の両方を、同時にスケールダウンすることができ、計算スピードと引き換えに、大幅な電力節約が達成される。

【0007】

モバイル端末は、例えば、ディスプレイが一定の時間にわたって非アクティブである場合に、ディスプレイを低輝度モードに切り換える、スリープ・モードおよびタイマなど、多種多様なエネルギー節約戦略を利用して、電力消費を制限する。いくつかのモバイル端末は、アプリケーションが低輝度表示用のタイマを調整することを可能にするインタフェースを提供することができる。一般に、モバイル端末は、残存電力およびワイヤレス接続品質をユーザに通知するために、バッテリ充電ステータス・インジケータおよび受信品質インジケータを使用し、一般に、モバイル端末は、事前に定められた一定の期間にわたって活動がない場合に、システムの一部をオフに切り換える、様々なスリープ・モードを含む。

【0008】

一般に、ラップトップおよびノートブックなどのより大型のモバイル端末は、電力が低下したときにユーザに警告を発する電力管理機能を有する。電力管理機能は、システムの秩序立ったシャットダウンを達成できるように、手順を踏んでデータをセーブすることができる。電力管理機能は、スリープ・モード中にエネルギーを保存するために、いくつかの機能をオフに切り換えることもできる。

【0009】

一般に、電力管理機能は、オペレーティング・システムによって提供される。一般に、ラップトップのオペレーティング・システムは、ワイヤレス接続機能とユーザ制御の電力節約機能の２つの機能が追加された、デスクトップのオペレーティング・システムである。特にマルチタスク・スマートフォンで使用されるオペレーティング・システムである、モバイル・オペレーティング・システムは、一般にラップトップ内に見出されるオペレーティング・システムから派生したものであることが多い。

【0010】

オペレーティング・システムは、プロセッサの使用率を最大化するために、タスク・スケジューリングを使用する。この文脈では、タスクとは、オペレーティング・システムが実行をスケジュールする際の最小単位であると定義される。プロセスとは、指定されたジョブを実行するために実行される、プログラムのインスタンスである。プロセスは、逐次的および／または並列的いずれの順序でも実行できる、１つまたは複数のタスクを含むことができる。いくつかのオペレーティング・システムでは、タスクは、スレッドまたは軽量プロセスとして実現される。

【0011】

マルチタスキング・オペレーティング・システムでは、タスクには、スケジューリングのためのプライオリティが割り当てられる。いくつかのタスクは、よりプライオリティが高いタスクを受け入れるために、一時的に中断されることがある。マルチタスキング・オペレーティング・システムにおけるタスク・スケジューリングの目標は、プロセッサの使用率を最大化することである。様々な性能基準を満たすために、多種多様なスケジューリング・アルゴリズムが、オペレーティング・システムにおいて実施されている。プロセッサ使用率の他に、他の重要な基準として、公平性、スループット、ターンアラウンド・タイム、待ち時間、および応答時間などが挙げられる。

【0012】

電力消費がきわめて重要な意味をもつバッテリ給電式のデバイスおよびコンピュータでは、さらなる最適化基準として電力消費を考慮するのが有利である。

【0013】

モバイル端末で使用するために、アプリケーションによるエネルギー使用を低減するための電力認識アルゴリズム（ｐｏｗｅｒ−ａｗａｒｅ ａｌｇｏｒｉｔｈｍ）が提案された。しかし、実際に必要な電力と、その必要な電力を供給できる実際の容量とを、さらに詳しく認識することが必要とされている。

【発明の概要】

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

【0014】

説明的な実施形態では、モバイル端末で使用されるタスク・スケジューリング・アルゴリズムは、アプリケーションの実際の電力消費を考慮するように変更される。これは、バッテリに残っている電力、与えられたタスクを完了するのに必要な電力量、タスクの重要度（ｃｒｉｔｉｃａｌｉｔｙ）、および端末のロケーションなど、追加的な基準を使用することによって行われる。そのような変更がもたらし得る利点のいくつかとして、以下のことが挙げられる。

【0015】

ユーザによって開始されたアプリケーション、またはデバイスによって開始されたサービスを、残存バッテリ電力を用いて、最後まで確実に実行できるかどうかを、モバイル端末が決定できるようになる。

【0016】

認証、バンキング、緊急警報、緊急通話、およびある種のロケーション・ベースのサービスなどの重要な機能を、これまでよりも長い期間にわたってモバイル端末が提供できることが保証され、ユーザは、必要な場合に、モバイル端末に頼って、これらの重要度が高い（ｃｒｉｔｉｃａｌ）アプリケーションを実行することができる。

【0017】

電力レベルが非常に低下しているときに、モバイル端末におけるエネルギー消費を低減するための支援を、ネットワークまたはアプリケーション・サーバが行えるようになる。

【0018】

特に、重要度が高いアプリケーションおよびサービスが実行されているときに、より良いユーザ・エクスペリエンスが提供されるように、端末のエネルギー消費を制御および管理するための手段が、モバイル端末のオペレーティング・システムに提供される。

【0019】

したがって、一実施形態ではモバイル通信端末は、複数のアプリケーションをサポートするように構成され、各アプリケーションは、１つまたは複数のタスクを実施することによって実行される。アプリケーションからのスケジューリング要求に応答して、モバイル端末内のオペレーティング・システムは、タスクのうちの少なくとも１つの要求された実行時間における、電力供給状態の表示を獲得する。オペレーティング・システムは、要求された実行時間における、タスクによるエネルギー使用の速度の予測を獲得する。オペレーティング・システムは、タスクについてのスケジューリング決定を行い、スケジューリング決定は、タスクについての２つ以上の代替処理（ａｌｔｅｒｎａｔｉｖｅ ｄｉｓｐｏｓｉｔｉｏｎ）からなるグループから選択を行うことを含み、選択は、実行時間中の電力供給状態をタスクによるエネルギー使用の予測速度に関連付ける基準に従って行われる。

【0020】

別の実施形態では、モバイル通信端末は、バッテリと、バッテリの状態についての情報のソースと、タスクをスケジュールするよう求めるアプリケーションからの要求に応答して、バッテリ情報ソースから、バッテリ状態の表示を獲得するように構成されたモジュールと、１つまたは複数のアプリケーションに関連付けられたタスクによるエネルギー使用の速度についての情報のソースと、エネルギー使用情報ソースから、タスクの要求された実行時間における、タスクによるエネルギー使用の速度の予測を獲得するように構成されたモジュールと、タスクについての２つ以上の代替処理からなるグループから選択を行うように構成されたタスク・スケジューリング・モジュールとを備える。タスクに対する処理の選択は、実行時間中のバッテリ状態をタスクによるエネルギー使用の予測速度に関連付ける基準に従って行われる。

【0021】

いくつかの実施形態では、オペレーティング・システムは、少なくとも、タスクの重要度が高くない（ｎｏｎ−ｃｒｉｔｉｃａｌ）場合には、要求された実行時間における、タスクによるエネルギー使用の速度の予測を獲得するが、タスクの重要度が高い場合には、予測速度に基づいてスケジューリング決定を行う機能は、使用可能ではない。すなわち、オペレーティング・システムは、タスクについてのスケジューリング決定を行う。タスクの重要度が高くない場合には、スケジューリング決定には、実行時間中の電力供給状態をタスクによるエネルギー使用の予測速度に関連付ける基準が関与する。しかし、タスクの重要度が高い場合には、そのような基準は適用されない。

【0022】

いくつかの実施形態では、オペレーティング・システムは、従来モードまたは電力認識モードで起動するように構成可能である。電力認識モードでは、オペレーティング・システムは、要求された実行時間における、タスクによるエネルギー使用の速度の予測を獲得し、実行時間中の電力供給状態をタスクによるエネルギー使用の予測速度に関連付ける基準を使用して、スケジューリング決定を行う。しかし、従来モードでは、タスクによるエネルギー使用の速度の予測を獲得する機能は、使用不可とすることができ、スケジューリング決定には、実行時間中の電力供給状態をタスクによるエネルギー使用の予測速度に関連付ける基準が関与しない。

【図面の簡単な説明】

【0023】

【図1】例示的な電力認識管理方式の一実施形態が実施された、説明的なワイヤレス通信システムの概略図である。

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

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

【図4】例示的な電力認識管理方式の一実施形態による、モバイル端末内の電力システムの機能ブロック図である。

【図5】例示的な電力認識管理方式の一実施形態による、アプリケーション・プロファイラおよびその環境の機能ブロック図である。

【図6】例示的な電力認識タスク・モニタのフロー図である。

【図7】電力認識タスク・スケジューラを実施するための例示的なアーキテクチャの機能ブロック図である。

【図8A】タスクについての電力閾値に基づいたスケジューリングまたはアドミッション決定を示す高水準フロー図である。

【図8B】電力関連のデータ・フィールドを含むように変更された例示的なプロセス制御ブロックについてのフォーマット図である。

【図9A】説明的な実施形態における図７の電力認識タスク・スケジューリング・サブシステム７００内の機能の動作を示すフロー図である。より詳細には、図７のアドミッション・モジュール７１０の動作に関する。

【図9B】説明的な実施形態における図７の電力認識タスク・スケジューリング・サブシステム７００内の機能の動作を示すフロー図である。より詳細には、図７の電力認識スケジューリング・モジュール７６０の動作に関する。

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

【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】

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

【0184】

すなわち、貧弱なチャネル品質に起因するタイムアウトは、例えば、ＴＣＰ／ＩＰレイヤに関して、よく知られているように、一般に、より低位のプロトコル・レイヤにおいて宣言される。しかし、（より高位の）アプリケーション・レイヤでは、ネットワークおよびモバイル端末は、タイムアウトの頻度を低減する方法で、貧弱なチャネル状態に適応することができる。例えば、アプリケーションは、そのデータ交換速度を低減することができ、または他の何らかの戦略を変更することができる。有効であるために、そのような適応的手法は、モバイル端末、ネットワーク・レベル、およびアプリケーション・サーバにおける電力認識タスク・マネージャ間での協力を必要とする。

【0185】

説明的なシナリオでは、電力認識タスク・モニタが、現在のチャネル状態に従って、タスク関連のパラメータを設定し、電力認識タスク・スケジューラが、リソースの利用可能性に基づいて、タスクを一時中止し、再開する。例えば、電力認識タスク・モニタは、タスクのプライオリティを変更して、タスクが断続的に一時中止されるようにすること、またはタスクがより低頻度の間隔でスケジュールされるようにすることができる。そのような方法では、タスクに関連するスループットを、貧弱な受信の期間中は低下させることができ、そのような期間中のタイムアウトをより僅かにする。

【0186】

特に、受信品質が良好である期間中は、高速でダウンロードを実行し、受信品質が貧弱な期間中は、アプリケーションの電力消費を最小化するために、通信モジュールを半スリープ・モードに入れることが可能なことがある。

【0187】

チャネル品質を評価するための様々な方策が知られている。これらには、スループット、信号対干渉および雑音比（ＳＩＮＲ）、フレーム誤り率、および送信電力レベルの測定が含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9A】

【図9B】