JP2010165350A

JP2010165350A - 電力管理のための下流デバイスのサービス待ち時間報告

Info

Publication number: JP2010165350A
Application number: JP2009293551A
Authority: JP
Inventors: Jaya Jeyaseelan; ジェヤシーラン、ジャヤ; Jim Walsh; ワルシュ、ジム; Robert Gough; ゴフ、ロバート; Barnes Cooper; クーパー、バーンズ; Neil Songer; ソンガー、ニール
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2008-12-31
Filing date: 2009-12-24
Publication date: 2010-07-29
Anticipated expiration: 2029-12-24
Also published as: KR20100080395A; US20170177539A1; US10182398B2; US20140095908A1; TWI439863B; US20100169684A1; US9838967B2; KR101162156B1; DE102009060269B4; DE102009060269A1; US20150257101A1; US8601296B2; JP5385124B2; CN101853065A; CN101853065B; TW201040729A

Abstract

【課題】電池式のモバイルデバイスおよびシステムの電力管理により拡張動作を可能とする。
【解決手段】パーソナルコンピュータでは、第１の状態から第２の状態への下流デバイスの少なくとも一部の遷移を特定することができる。第１の状態および第２の状態は、下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応していてよい。特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、サービス待ち時間に少なくとも部分的に基づく電力管理を１以上の上流デバイスに行わせることができる。
【選択図】図１

Description

開示する実施形態は、概して電力管理に係る。

多くのデバイスおよびシステムで、電力効率を向上させるために電力管理が行われており、消費電力および／または放熱量の低減の一助となっている。電池式のモバイルデバイスおよびシステムでは、電力管理により拡張動作が可能となる。

プラットフォームレベルの電力管理は、プラットフォームで収集された発見およびオペレーティングシステムからのガイダンスに基づいてきた。プロセッサ利用率は、プラットフォームアクティビティの概算として利用することができる。しかしながら、入出力（Ｉ／Ｏ）アクティビティが重く、プロセッサ利用率が軽い場合には、プラットフォームは低電力状態となり、Ｉ／Ｏ性能に影響が出る。実際のところ、プラットフォームが深い電力状態に入ると、直接メモリアクセス（ＤＭＡ）アクセスおよび中断等のイベントを起こす際の応答待ち時間が増加する。多くのＩ／Ｏデバイスは、プラットフォームからの幾らかの固定最小応答待ち時間を許容するように設計されてはいるものの、これによって、プラットフォームが入ることのできる電力状態の深さには効果的に制限が加わりうる。プラットフォームが、その応答待ち時間がＩ／Ｏデバイスが許容可能な固定最小値よりも増加した深い電力状態に入ると、プラットフォームの機能および／または性能は危険に曝される。

実施形態を例示として示し、添付図面による限定は意図されないが、添付図面において、同様の参照符号は同様の部材を示す。

一実施形態において、１以上の下流デバイスからのサービス待ち時間報告に少なくとも部分的に基づいて電力管理を行う例示的なシステムのブロック図を示す。

一実施形態において、上流デバイスへサービス待ち時間を報告する下流デバイスの例示的なブロック図を示す。

一実施形態において、下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第１の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。

一実施形態において、第１の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第２の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。

一実施形態において、第２の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第２の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。

一実施形態において、第３の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。

一実施形態において、第３の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第３の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。

一実施形態において、第４の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第５の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。

一実施形態において、第５の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第６の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスのブロック図を示す。

一実施形態において、第６の技術に応じて下流デバイスが上流デバイスへサービス待ち時間を報告する際の例示的なフロー図を示す。

一実施形態において、第６の技術に応じて上流デバイスへサービス待ち時間を報告する下流デバイスの例示的な図を示す。

図面は、必ずしも実寸に即して描かれていない場合がある。

以下の詳細な記載は、電力管理のための下流デバイスのサービス待ち時間報告に関する装置、方法、およびシステムの例示的な実施形態に関する。例えば構造、機能、および／または特性等の特徴は、便宜上、一実施形態に関して示されているが、記載された特徴のうち適切な１以上のものを利用して様々な実施形態を実装することができる。

図１は、１以上のプロセッサ１１０と、プロセッサ１１０に連結されたプラットフォーム制御ロジック１２０とを含む例示的なシステム１００を示す。一実施形態のプロセッサ１１０は、１以上のプロセッサ電力管理コントローラ（ＰＰＭＣ）１１２を含み、プロセッサ１１０の電力効率を高めることができる。一実施形態のプラットフォーム制御ロジック１２０は、プラットフォームコントローラ電力管理コントローラ（ＰＣＰＭＣ）１２２を含み、システム１００の電力効率を高めることができる。例えば一実施形態のＰＣＰＭＣ１２２は、システム１００の１以上のコンポーネントを、コンポーネントがあまりアクティブではないとき、またはアイドルのとき、複数の低電力状態またはスリープ状態のうち１つに移行させるよう管理する。

一実施形態のＰＣＰＭＣ１２２は、システム１００のコンポーネントの電力管理を調整して、電力効率を高めることができる。一実施形態のＰＣＰＭＣ１２２は、例えば、１位以上のＰＰＭＣ１１２の間の調整を行い、これらＰＰＭＣ１１２およびＰＣＰＭＣ１２２に、１以上のコンポーネントに関して、機能および／または性能の低下に対する懸念なく他の１以上のコンポーネントに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。

一実施形態のＰＣＰＭＣ１２２は、例えばデバイス１３２等の１以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のＰＣＰＭＣ１２２は、受信データに少なくとも部分的に基づいて（故に、対応するサービス待ち時間に少なくとも部分的に基づいて）電力管理を行うことができる。一実施形態のサービス待ち時間は、そのデバイスのサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、そのデバイスがデバイスの機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイスの少なくとも一部のアクティビティに関するレベルに対応していてよい。従って一実施形態のＰＣＰＭＣ１２２は、経時的に、デバイスの少なくとも一部のアクティビティレベルに少なくとも部分的に基づいて、デバイスから異なるサービス待ち時間を受信してよい。一実施形態のＰＣＰＭＣ１２２は、システム１００の１以上のコンポーネントに関して、機能および／または性能の低下に対する懸念なくデバイスに対して応答する能力を維持できるような低電力状態の深さをより適切に特定することができる。

一実施形態の１以上のＰＰＭＣ１１２は、ＰＣＰＭＣ１２２との間で調整を行い、下流デバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を行ってよい。一実施形態のＰＣＰＭＣ１２２は、デバイスのサービス待ち時間に対応して受信したデータを、１以上のＰＰＭＣ１１２に送り、これらＰＰＭＣ１１２に、このサービス待ち時間に少なくとも部分的に基づいて電力管理を行わせてよい。一実施形態の１以上のＰＰＭＣ１１２は、このサービス待ち時間に少なくとも部分的に基づいてＰＣＰＭＣ１２２がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。

一実施形態のプラットフォーム制御ロジック１２０は、例えばデバイス１３２および１３４等の１以上のデバイスと通信する１以上のインタフェースコントローラ１２４を含むことができる。このインタフェースコントローラ１２４は、任意の適切な方法で１以上のデバイスとインタフェースする任意の適切なロジックを含んでよい。一実施形態の１以上のインタフェースコントローラ１２４は、例えば任意のユニバーサルシリアルバス（ＵＳＢ）仕様（例えば、ＵＳＢ仕様改訂版２．０、２０００年４月２７日、ＵＳＢ２．０リンク電力管理補足エンジニアリング変更報告、２００７年７月１６日、ＵＳＢ３．０仕様改訂版１．０、２００８年１１月１２日）および／または任意の適切なＰＣＩ（Peripheral Component Interface）またはＰＣＩエクスプレス（ＰＣＩｅ）仕様（例えば、ＰＣＩエクスプレスベース仕様改訂版１．０、２００２年７月２２日、ＰＣＩエクスプレスベース仕様改訂版２．０、２００７年１月１５日）等であるがこれらに限定されない任意の適切な１以上の標準的な仕様と互換性を有してよい。

一実施形態の１以上のインタフェースコントローラ１２４は、１以上の下流デバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、このデータをＰＣＰＭＣ１２２に送信してよい。一実施形態の１以上のインタフェースコントローラ１２４は、インタフェースコントローラ電力管理コントローラ（ＩＣＰＭＣ）１２６を含み、インタフェースコントローラ１２４および／または１以上のデバイスへの接続またはリンクのための電力効率を上げることができる。一実施形態の１以上のＩＣＰＭＣ１２６は、１以上のデバイスから、そのデバイスのサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、電力を管理してよい。一実施形態のＰＣＰＭＣ１２２は、このサービス待ち時間に少なくとも部分的に基づいてＩＣＰＭＣ１２６がどのように電力管理を行うか、に少なくとも部分的に基づくデバイスのサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。

一実施形態のインタフェースコントローラ１２４は、例えばデバイス１３４等の別のデバイスの下流の例えばデバイス１３６等のデバイスのサービス待ち時間に対応するデータを受信してよい。一実施形態のデバイス１３４は、デバイス１３６から、デバイス１３６のサービス待ち時間に対応するデータを受信して、このデータをインタフェースコントローラ１２４へ送信してよい。一実施形態のデバイス１３４は、デバイス１３６から、デバイス１３６のサービス待ち時間に対応するデータを受信して、この受信データに少なくとも部分的に基づいて、故にこれに対応するサービス待ち時間に少なくとも部分的に基づいて、デバイス１３４の電力を管理してよい。一実施形態の対応するＩＣＰＭＣ１２６は、このサービス待ち時間に少なくとも部分的に基づいてデバイス１３４がどのように電力管理を行うか、に少なくとも部分的に基づくデバイス１３６のサービス待ち時間に少なくとも部分的に基づいて電力管理を間接的に行ってよい。

一実施形態では、システム１００における電力管理は、次の文献に記載されるデバイスのサービス待ち時間に少なくとも部分的に基づいて行われてよいが、文献は、「LATENCY BASED PLATFORM COORDINATION」なる名称で、２００７年１２月３１日に出願された米国特許出願第12/006,251号、「PLATFORM POWER MANAGEMENT BASED ON LATENCY GUIDANCE」なる名称で、２００８年３月３１日に出願された米国特許出願第12/059,992、および／または、「COORDINATED LINK POWER MANAGEMENT」なる名称で、２００８年６月２６日に出願された米国特許出願第12/146,873号である。

図１に示すように、一実施形態のシステム１００は、さらに、１以上の入力デバイス１４０、１以上のディスプレイ１５０、揮発性メモリ１６０、１以上の不揮発性メモリおよび／または記憶デバイス１７０、および１以上の通信インタフェース１８０を有してよい。

一実施形態のプロセッサ１１０は、揮発性メモリ１６０にインタフェースを提供する１以上のメモリコントローラを含んでよい。揮発性メモリ１６０は、例えばシステム１００にデータおよび／または命令をロードおよび格納するのに利用されてよい。揮発性メモリ１６０は、適切なダイナミックＲＡＭ（ＤＲＡＭ）等の任意の適切な揮発性メモリを含んでよい。一実施形態のプロセッサ１１０は、ＰＰＭＣ１１２を利用して揮発性メモリ１６０の電力管理を助けてよい。

プロセッサ１１０に常駐するとして記載されているが、一実施形態の１以上のメモリコントローラは、プラットフォーム制御ロジック１２０に常駐することで、プラットフォーム制御ロジック１２０に、揮発性メモリ１６０と直接通信させてもよい。

一実施形態のプラットフォーム制御ロジック１２０は、インタフェースコントローラ１２４を含む任意の適切なインタフェースコントローラを含むことで、プロセッサ１１０に、および／または、プラットフォーム制御ロジック１２０と通信する任意の適切なデバイスまたはコンポーネントに、任意の適切な通信リンクを提供してよい。一実施形態のプラットフォーム制御ロジック１２０は、ＰＣＰＭＣ１２２を利用することで、プラットフォーム制御ロジック１２０と通信する任意の適切な１以上のデバイスおよび／またはコンポーネントの電力管理を助けてよい。

一実施形態のプラットフォーム制御ロジック１２０は、ディスプレイ１５０にインタフェースを提供する１以上のグラフィックコントローラを含んでよい。例えば、ディスプレイ１５０は、陰極線管（ＣＲＴ）または液晶ディスプレイ（ＬＣＤ）等の任意の適切なディスプレイを含みうる。一実施形態の１以上のグラフィックコントローラは、プラットフォーム制御ロジック１２０の外にあってもよい。

一実施形態のプラットフォーム制御ロジック１２０は、１以上の入出力（Ｉ／Ｏ）コントローラを含むことで、入力デバイス１４０、不揮発性メモリおよび／または記憶デバイス１７０、および通信インタフェース１８０へインタフェースを提供してよい。

入力デバイス１４０は、キーボード、マウス、および／または任意の他の適切なカーソル制御デバイス等の任意の適切な入力デバイスを含みうる。

不揮発性メモリおよび／または記憶デバイス１７０は、例えばデータおよび／または命令を記憶するのに利用されてよい。不揮発性メモリおよび／または記憶デバイス１７０は、例えばフラッシュメモリ等の任意の適切な不揮発性メモリを含んでよく、および／または、例えば１以上のハードディスクドライブ（ＨＤＤ）、１以上のコンパクトディスク（ＣＤ）ドライブ、および／または、１以上のＤＶＤ（デジタル多用途ディスク）ドライブ等の任意の適切な不揮発性記憶デバイスを含んでよい。

通信インタフェース１８０は、１以上のネットワーク上で、および／または、任意の他の適切なデバイスと通信するインタフェースをシステム１００に提供してよい。通信インタフェース１８０は、任意の適切なハードウェアおよび／またはファームウェアを含んでよい。一実施形態の通信インタフェース１８０は、例えば、ネットワークアダプタ、無線ネットワークアダプタ、電話モデム、および／または、無線モデムを含んでよい。無線通信のために、一実施形態の通信インタフェース１８０は、１以上のアンテナ１８２を利用してよい。

一実施形態の下流デバイス１３２、１３４、および１３６は、プラットフォーム制御ロジック１２０に連結されてよい任意の適切なデバイスであってよい（例えば適切な入力デバイス１４０、適切な不揮発性メモリまたは記憶デバイス１７０、適切な通信インタフェース１８０、または任意の他の適切なＩ／Ｏデバイス等を含むがこれらに限定されない）。下流デバイスの例には、カーソル制御デバイス、記憶ドライブ、記憶デバイス、ハブデバイス、ネットワークルータまたはスイッチ、充電デバイス、プリンタ、スキャナ、カムコーダ、カメラ、メディアプレーヤ、セルラー式電話機、スマートフォン、モバイルインターネットデバイス、およびデスクトップ、ノートブック、ネットブック等のコンピュータシステム、またはその他のコンピュータシステムが含まれうるが、これらに限定されない。

プラットフォーム制御ロジック１２０に常駐するとして記載したが、１以上のインタフェースコントローラ１２４を含むプラットフォーム制御ロジック１２０の１以上のコントローラは、一実施形態では、１以上のプロセッサ１１０に常駐することで、プロセッサ１１０を、１以上のデバイスまたはコンポーネントと直接通信させることができる。１以上のインタフェースコントローラ１２４を含むプラットフォーム制御ロジック１２０の１以上のコントローラは、一実施形態では、単一のダイの上で、１以上のプロセッサ１１０の少なくとも一部とともに集積されてもよい。１以上のインタフェースコントローラ１２４を含むプラットフォーム制御ロジック１２０の１以上のコントローラは、一実施形態では、１以上のプロセッサ１１０とともにパッケージされてもよい。＜サービス待ち時間の報告＞

図２は、一実施形態における、１以上の上流デバイスのサービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいて電力を管理するデバイス２００を示す。一実施形態のデバイス２００は、例えば図１の下流デバイス１３２または１３４に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてシステム１００に電力を管理させる。一実施形態のデバイス２００は、例えば図１の下流デバイス１３６に対応しており、サービス待ち時間を報告して、サービス待ち時間に少なくとも部分的に基づいてデバイス１３４および／またはシステム１００に電力を管理させる。

図２に示すように、一実施形態のデバイス２００は、デバイス制御ロジック２０２、インタフェース制御ロジック２０４、遷移特定ロジック２０６、およびサービス待ち時間報告ロジック２０８を含んでよい。デバイス制御ロジック２０２、インタフェース制御ロジック２０４、遷移特定ロジック２０６、およびサービス待ち時間報告ロジック２０８は、それぞれ、例えば任意の適切なハードウェア、任意の適切なファームウェアを実行する任意の適切なハードウェア、任意の適切なソフトウェアを実行する任意の適切なハードウェア、または、このような実装の任意の適切な組み合わせを利用して、任意の適切な方法で実装することができる。一実施形態では、上述した任意のファームウェアおよび／またはソフトウェアが、デバイス２００の任意の適切なコンピュータ可読記憶媒体（１または複数）に記憶されてよい。一実施形態のデバイス２００は、さらに、デバイス２００の任意の適切な機能を実装する他の適切なロジック、回路、および／または、１以上のコンポーネントを有してよい。

一実施形態のデバイス制御ロジック２０２は、デバイス２００の機能の制御を助けてよく、インタフェース制御ロジック２０４を利用して１以上の上流デバイスを通信してこれらデバイスの１以上のコンポーネントに機能を提供してよい。

インタフェース制御ロジック２０４は、デバイス制御ロジック２０２に連結されて、任意の適切な方法でデバイス２００に対してデータを送受信してよい。一実施形態のインタフェース制御ロジック２０４は、例えば任意のユニバーサルシリアルバス（ＵＳＢ）仕様および／または任意の適切なＰＣＩ（Peripheral Component Interface）またはＰＣＩエクスプレス（ＰＣＩｅ）仕様等であるがこれらに限定されない任意の適切な１以上の標準的な仕様と互換性を有してよい。

一実施形態の遷移特定ロジック２０６は、デバイス２００の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態でこれらの状態は、デバイス２００の少なくとも一部のアクティビティに関するそれぞれ異なるレベルに対応していてよい。一実施形態の遷移特定ロジック２０６は、デバイス制御ロジック２０２の少なくとも一部の、ある状態から別の異なる状態への遷移を任意の適切な方法で特定してよい。一実施形態の遷移特定ロジック２０６は、デバイス２００の少なくとも一部が、ある状態から別の異なる状態へ遷移しようとしていることを特定することができる。一実施形態の遷移特定ロジック２０６は、デバイス２００の少なくとも一部が、既にある状態から別の異なる状態へ遷移したことを特定することができる。

一実施形態のサービス待ち時間報告ロジック２０８は、遷移特定ロジック２０６による遷移の特定に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック２０８は、任意の適切な方法で遷移特定ロジック２０６から状態遷移の特定を受信するよう連結されてよい。一実施形態のサービス待ち時間報告ロジック２０８は、インタフェース制御ロジック２０４を用いて任意の適切な方法でサービス待ち時間に対応するデータを送信するよう連結されてよい。

一実施形態のサービス待ち時間報告ロジック２０８は、任意の適切な方法でサービス待ち時間を特定してよい。一実施形態のサービス待ち時間は、デバイス２００のサービス待ち時間の許容範囲であってもよい。一実施形態のサービス待ち時間は、デバイス２００がデバイス２００の機能または性能に悪影響を与えずに許容できる最大待ち時間に少なくとも部分的に基づいていてよい。一実施形態のサービス待ち時間は、デバイス２００の少なくとも一部の新たな状態に対応していてもよい。

一実施形態のサービス待ち時間報告ロジック２０８は、前のまたは現在のサービス待ち時間および状態遷移の特定に少なくとも部分的に基づいて、新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、新たな状態に少なくとも部分的に基づいて新たなサービス待ち時間を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、前のまたは現在の状態に少なくとも部分的に基づいて新たな状態を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、任意の適切な方法で遷移特定ロジック２０６から新たな状態の特定を受信してよい。

デバイス２００の少なくとも一部が状態間の遷移を続ける間、一実施形態のサービス待ち時間報告ロジック２０８は、新たなサービス待ち時間の特定をし続け、これらサービス待ち時間に対応するデータの送信を続けてよい。一実施形態のサービス待ち時間報告ロジック２０８は、オプションとして、新たなサービス待ち時間に対応するデータを送信しなくてもよい（例えば、新たなサービス待ち時間が、前のまたは現在のサービス待ち時間と同じである場合等）。一実施形態のサービス待ち時間報告ロジック２０８は、状態間の１以上であるが全てではなくてよい遷移に呼応して、新たなサービス待ち時間に対応するデータを送信してよい。

図３は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図３００を示す。図３に示すように、デバイス２００の少なくとも一部が、ブロック３０２の第１の状態にあってよい。ブロック３０４で、サービス待ち時間報告ロジック２０８は、第１の状態に対応する第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック３０６で、デバイス２００の少なくとも一部が、第２の異なる状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック３０８で、サービス待ち時間報告ロジック２０８は、第２の状態に対応する第２のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック３１０で、デバイス２００の少なくとも一部が、第１の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック３０４で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック３０４から３１０の動作を繰り返してよい。

第１および第２の状態に対応する第１および第２のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック２０８は、２を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。＜アクティビティレベルに少なくとも部分的に基づくサービス待ち時間＞

一実施形態の遷移特定ロジック２０６は、互いに異なるアクティビティレベルに対応する状態間の、デバイス２００の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、より高いアクティビティレベルに対応する状態に遷移するより低いサービス待ち時間に対応するデータを送信してよく、より低いアクティビティレベルに対応する状態に遷移するより高いサービス待ち時間に対応するデータを送信してよい。一実施形態の遷移特定ロジック２０６は、デバイス２００が上流デバイスとの間でデータ通信するアクティブ状態と、デバイス２００が上流デバイスとの間でデータ通信しないアイドル状態との間の、デバイス２００の少なくとも一部の遷移を特定することができる。

一実施形態のデバイス２００の少なくとも一部は、たまに頻繁に、異なる状態間を遷移することができる。一例としては、一実施形態のデバイス２００の少なくとも一部が、アクティビティバーストを有しているがために、たまに頻繁に、低アクティビティまたはアイドル状態に入退出することができる。一実施形態のサービス待ち時間報告ロジック２０８は、状態遷移が特定されてから、サービス待ち時間に対応するデータを送信するまで所定の期間を待つことにより、デバイス２００の少なくとも一部が新たな状態に留まる可能性が高いか否かを特定する助けをしてよい。このようにして、一実施形態のサービス待ち時間報告ロジック２０８は、さもなくば１以上の上流デバイスの電力管理の効果を低減させうる、異なるサービス待ち時間に対応するデータの頻繁な送信を避けることができる。

一実施形態のサービス待ち時間報告ロジック２０８は、現在のサービス待ち時間よりも高いサービス待ち時間に対応する状態への遷移が特定されてから、現在のサービス待ち時間より低いサービス待ち時間に対応する状態への遷移が特定されるまでの所定の期間を待ってよい。一例としては、一実施形態のサービス待ち時間報告ロジック２０８は、低アクティビティまたはアイドル状態への遷移が特定されてから、より高いアクティビティ状態への遷移が特定されるまでの所定の期間を待ってよい。

図４に示すように、一実施形態のサービス待ち時間報告ロジック２０８は、新たな状態遷移の特定の後の待ち時間を特定するためにタイマ４０２を有してよい。一実施形態のサービス待ち時間報告ロジック２０８は、この待ち時間を所定の閾値と比較して、待ち時間が所定の閾値以上となるまで、新たな状態遷移のサービス待ち時間に対応するデータの送信を待ってよい。遷移特定ロジック２０６が所定の閾値に達する前に新たな状態遷移を特定すると、一実施形態のサービス待ち時間報告ロジック２０８は、この、より新しい遷移用にタイマ４０２をリセットしてよい。一実施形態のサービス待ち時間報告ロジック２０８は、この代わりに、例えばより新しい遷移の状態に少なくとも部分的に基づいて、タイマ４０２をリセットして、より新しい遷移のサービス待ち時間に対応するデータを送信してよい。

図５は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図５００を示す。図５に示すように、デバイス２００の少なくとも一部が、ブロック５０２の低アクティビティまたはアイドル状態にあってよい。ブロック５０４で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック５０６で、デバイス２００の少なくとも一部が、より高いアクティビティ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック５０８で、サービス待ち時間報告ロジック２０８は、第２のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック５１０で、デバイス２００の少なくとも一部が低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック５１２で、サービス待ち時間報告ロジック２０８は、所定の期間待ってよい。ブロック５１４でデバイス２００の少なくとも一部がまだ低アクティビティまたはアイドル状態である場合、ブロック５０４で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック５０４から５１４の動作を繰り返してよい。

低アクティビティ／アイドルおよびアクティブ状態に対応するアイドルおよびアクティブのサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック２０８は、例えば互いに異なるアクティビティレベルに対応する１以上の状態等の１以上のさらなる状態に対応するサービス待ち時間のデータを送信することもできる。＜デバイスバッファリングに少なくとも部分的に基づくサービス待ち時間＞

一実施形態のデバイス２００は、上流デバイスへの送信用に別のデバイスからデータを受信してよい。図６に示すように、一実施形態のデバイス制御ロジック２０２は、任意の適切な通信リンク（任意の適切な無線リンクを含む）を介して別のデバイスからデータを受信するバッファ６０２を含むことで、インタフェース制御ロジック２０４を利用してバッファ６０２から上流デバイスへデータを後で送信することができる。一実施形態のデバイス２００は、例えば、イーサネット（登録商標）ネットワークインタフェースコントローラ（ＮＩＣ）であってよい。

デバイス２００の少なくとも一部が低アクティビティまたはアイドル状態である一実施形態では、デバイス２００は、デバイス２００がデータを受信するためのバッファ６０２の利用可能な容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信する。このようにして、一実施形態の上流デバイスは、サービス待ち時間の間も対応可能である状態を維持して、バッファ６０２の利用可能な容量が満杯になる前にバッファ６０２からのデータ受信を開始することができる。サービス待ち時間がこれより高い場合には、上流デバイスは、より深く、より低い電力状態に入ることも考えられ、時を得た応答ができない可能性があり、これによりバッファ６０２はオーバフローして、性能が低下して、失われたデータを再送信しなければなくなる虞もある。

一実施形態の遷移特定ロジック２０６は、バッファ６０２にデータを受信して、バッファ６０２からデータを再送信すべく、低アクティビティまたはアイドル状態からアクティブ状態への遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、その後、より低いサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック２０８は、デバイス２００がデータを受信するためのバッファ６０２のリザーブ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。このようにして、デバイス２００は、データがバッファ６０２から上流デバイスへ送信され始めると、バッファ６０２へのデータの受信を続けることができる。

図７は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図７００を示す。図７に示すように、デバイス２００の少なくとも一部が、ブロック７０２の低アクティビティまたはアイドル状態にあってよい。ブロック７０４で、サービス待ち時間報告ロジック２０８は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック７０６で、デバイス２００の少なくとも一部が、別のデバイスからのデータを受信または再送信するアクティブ状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック７０８で、サービス待ち時間報告ロジック２０８は、リザーブバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック７１０で、デバイス２００の少なくとも一部が、低アクティビティまたはアイドル状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック７０４で、サービス待ち時間報告ロジック２０８は、利用可能なバッファ容量に少なくとも部分的に基づいて、サービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８は、オプションとして、ブロック７１０の状態遷移の特定の後、ブロック７０４のデータ送信まで、所定の期間待つことができる。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック７０４から７１０の動作を繰り返してよい。

一実施形態のサービス待ち時間報告ロジック２０８は、上流デバイスがデータを受信する際のデータレートおよび／または性能要件を説明して、ブロック７０４および７０８でサービス待ち時間を特定することができる。

低アクティビティ／アイドルおよびアクティブ状態に対応するサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック２０８は、１以上のさらなる状態に対応するサービス待ち時間のデータを送信してよい。一実施形態では、サービス待ち時間報告ロジック２０８は、デバイス２００が別のデバイスからデータを受信しうる異なる範囲のデータレートに対応する状態に対応するサービス待ち時間のデータを送信することができる。一実施形態では、サービス待ち時間報告ロジック２０８は、上流デバイスがデータを受信する際の異なる性能要件に対応する様々な状態に対応するサービス待ち時間のデータを送信することができる。

図８は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図８に示すように、バッファ６０２は８０２でネットワークデータを受信する。ネットワークデータ受信の前に、デバイス２００はアイドル状態にあり、バッファ６０２の利用可能な容量およびネットワークデータがバッファ６０２に受信されるレートに少なくとも部分的に基づいて５００マイクロ秒（μｓ）のＬＴＲ（latency tolerance report）に対応するデータを上流プラットフォームコンポーネントに送信している。デバイス２００が初めにネットワークデータを受信する際、デバイス２００は、アクティブ状態に遷移する、あるいは、遷移しようとしているところであり、８０２で、１００μｓのＬＴＲに対応するデータを上流プラットフォームコンポーネントに送信する。１００μｓのＬＴＲは、バッファ６０２のリザーブ容量およびネットワークデータがバッファ６０２に受信されるレートに少なくとも部分的に基づく。１００μｓのＬＴＲは、バッファ６０２がネットワークデータを受信する間である、前の５００μｓのＬＴＲ期間内に有効になる。

上流プラットフォームコンポーネントは、８０４、８０６、および８０８で、１００μｓのＬＴＲ内に応答して、バッファ６０２からデータを受信する。デバイス２００が８１０でのネットワークデータの受信を終了すると、デバイス２００はアイドル状態に遷移して、タイムアウトと示されている所定の時間の間、待ち、８１２で５００μｓのＬＴＲに対応するデータを上流プラットフォームコンポーネントに送信する。図８に示すように、上流プラットフォームコンポーネントは、バッファ６０２からのデータ受信の際のＬＴＲおよび応答に少なくとも部分的に基づいて様々な電力状態に入る。＜電力状態に少なくとも部分的に基づくサービス待ち時間＞

一実施形態の遷移特定ロジック２０６は、互いに異なる電力レベルに対応する状態間の、デバイス２００の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、より高い電力状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低い電力状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。

図９に示すように、一実施形態のデバイス制御ロジック２０２は、デバイス電力管理コントローラ（ＤＰＭＣ）９０２を含み、デバイス２００の電力効率を向上させることができる。一実施形態のＤＰＭＣ９０２は、例えば、あまりアクティブまたはアイドルでない場合、デバイス２００の少なくとも一部を、１以上のより低電力またはスリープ状態に入らせるよう管理することができる。

図１０は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図１０００を示す。図１０に示すように、デバイス２００の少なくとも一部が、ブロック１００２の低電力状態にあってよい。ブロック１００４で、サービス待ち時間報告ロジック２０８は、低電力状態に対応する第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１００６で、デバイス２００の少なくとも一部が、より高い電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック１００８で、サービス待ち時間報告ロジック２０８は、より高い電力状態に対応する第２のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１０１０で、デバイス２００の少なくとも一部が低電力状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック１００４で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック１００４から１０１０の動作を繰り返してよい。

より低い、および、より高い電力状態に対応する第１および第２のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック２０８は、２を超える数の電力状態に対応するサービス待ち時間のデータを送信することもできる。

図１１は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的な図を示す。図１１のデバイス２００は、例えば、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイスであってよい。図１１に示すように、ＤＰＭＣ９０２は、デバイス２００のラジオの電力管理を行い、１１０２で、低電力またはスリープ状態に入ってよい。一実施形態による図１１のデバイス２００は、電力管理特徴をサポートする無線プロトコルを利用して、デバイス２００に、アクセスポイントまたは基地局に対して、例えばデバイス２００が低電力状態に入ろうとしていることを示してよい。このようにすることで、低電力状態にある際にはデバイス２００にはデータが送信されない。

低電力状態に入る前に、デバイス２００は、より高い電力状態にあり、１１０４で１００マイクロ秒（μｓ）の待ち時間に対応するデータを上流デバイスに送信している。デバイス２００が低電力状態に遷移する場合、デバイス２００は、１１０６で１ミリ秒（ｍｓ）の待ち時間に対応するデータを上流デバイスに送信する。デバイス２００がデータを移動してより高い電力状態に遷移する準備が整っている場合、デバイス２００は１１０８で１００μｓの待ち時間に対応するデータを上流デバイスに送信する。＜タスク実行に少なくとも部分的に基づくサービス待ち時間＞

一実施形態の遷移特定ロジック２０６は、互いに異なるタスク実行レベルに対応する状態間の、デバイス２００の少なくとも一部の遷移を特定してよい。一実施形態のサービス待ち時間報告ロジック２０８は、より高いタスク実行状態への遷移用に、より低いサービス待ち時間に対応するデータを送信してよく、より低いタスク実行状態への遷移用に、より高いサービス待ち時間に対応するデータを送信してよい。一実施形態では、より高いタスク実行状態とは、例えば、１以上の係属中のタスクを有する状態に対応していてよい。一実施形態では、より低いタスク実行状態とは、例えば、係属中のタスクがない状態または１以上のタスクが完了した状態に対応していてよい。

一実施形態のデバイス制御ロジック２０２は、デバイス２００用に１以上のタスクを実行することができる。一実施形態のデバイス制御ロジック２０２は、自身で１以上のタスクの実行を開始することもできる。一実施形態のデバイス制御ロジック２０２は、別のデバイスの要求を受けて１以上のタスクを実行することもできる。一実施形態のデバイス制御ロジック２０２は、上流デバイスの要求を受けて１以上のタスクを実行することもできる。

図１２は、一実施形態において、デバイス２００が上流デバイスにサービス待ち時間を報告する際の例示的なフロー図１２００を示す。図１２に示すように、デバイス２００の少なくとも一部が、ブロック１２０２のより低いタスク実行状態にあってよい。ブロック１２０４で、サービス待ち時間報告ロジック２０８は、より低いタスク実行状態に対応する第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１２０６で、デバイス２００の少なくとも一部が、より高いタスク実行状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック１２０８で、サービス待ち時間報告ロジック２０８は、より高いタスク実行状態に対応する第２のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１２１０で、デバイス２００の少なくとも一部が、より低いタスク実行状態に既に遷移したか、あるいは遷移しようとしているか、特定してよい。特定結果が肯定的である場合、ブロック１２０４で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック１２０４から１２１０の動作を繰り返してよい。

より低い、および、より高いタスク実行状態に対応する第１および第２のサービス待ち時間に関して記載してきたが、一実施形態のサービス待ち時間報告ロジック２０８は、それぞれ異なるタスク実行レベルに対応する２を越える数の状態に対応するサービス待ち時間のデータを送信することもできる。＜外部的に制御されるサービス待ち時間＞

一実施形態のサービス待ち時間報告ロジック２０８は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスに送信してよい。一実施形態のデバイス２００は、例えばデバイス２００が厳しくないサービス待ち時間を有していたり、あまり頻繁に変化しないサービス待ち時間を有したりしている場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態のデバイス２００は、例えばデバイス２００が、上流デバイスが予定する１以上のタスクを行う場合等に、上流デバイスが特定しうるサービス待ち時間を有してよい。一実施形態の上流デバイスは、タスクを予定する前にデバイス２００についてより低いサービス待ち時間を特定してよく、全ての予定されていたタスクが完了すると、デバイス２００についてより高いサービス待ち時間を特定してよい。

一実施形態の上流デバイスは、上流デバイスが特定するサービス待ち時間に対応するデータをデバイス２００へ送信してよい。一実施形態の上流デバイスは、デバイス２００のサービス待ち時間を特定すべくソフトウェアを実行してよい。一実施形態ではこのようなソフトウェアは、例えば、デバイス２００のドライバソフトウェアであってよい。

図１３に示すように、一実施形態のサービス待ち時間報告ロジック２０８は、サービス待ち時間に対応するデータを上流デバイスから受信するためのメモリ１３０２を含んでよい。一実施形態では、メモリ１３０２の少なくとも一部が、上流デバイスのメモリ空間にマッピングされてよい。一実施形態のメモリ１３０２は、１以上のレジスタを含んでよい。一実施形態のメモリ１３０２は、メモリマッピングされた入出力（ＭＭＩＯ）レジスタであってよい。

図１４は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図１４００を示す。図１４に示すように、ブロック１４０２でサービス待ち時間報告ロジック２０８は、上流デバイスが特定したサービス待ち時間に対応するデータを上流デバイスから受信してよい。一実施形態の上流デバイスは、このデータをソフトウェア実行の際に送信してよい。ブロック１４０４でサービス待ち時間報告ロジック２０８は、ブロック１４０２で受信したデータに少なくとも部分的に基づいてサービス待ち時間に対応するデータを上流デバイスへ送信してよい。一実施形態のサービス待ち時間報告ロジック２０８は、ブロック１４０４で、上流デバイスの電力管理コントローラへデータを送信してよい。＜定期的な遷移に少なくとも部分的に基づくサービス待ち時間＞

一実施形態のデバイス２００の少なくとも一部は、実質的に固定された時間間隔で、第１の状態から第２の異なる状態へと遷移することができる。一実施形態のデバイス２００の少なくとも一部は、実質的に固定された時間間隔で、低アクティビティまたはアイドル状態から、より高いアクティビティ状態へ遷移することができ、次の時間間隔の満了前に低アクティビティまたはアイドル状態へ戻ることができる。一例としては、デバイス２００は、実質的に固定された時間間隔で、上流デバイスと通信することができる。

図１５に示すように、一実施形態の遷移特定ロジック２０６は、第１の状態から第２の異なる状態へのデバイス２００の少なくとも一部の遷移を特定した後の、固定された時間間隔の満了を特定して、第１の状態から第２の状態へのデバイス２００の少なくとも一部の別の遷移を特定するためにタイマ１５０２を含んでよい。別の実施形態では、デバイス制御ロジック２０２は、第１の状態から第２の状態へのデバイス２００の少なくとも一部の遷移を制御するためにタイマを含んでよく、一実施形態の遷移特定ロジック２０６は、このようなデバイス２００の少なくとも一部の遷移を任意の適切な方法で特定することができる。

図１６は、一実施形態において、デバイス２００が上流デバイスへサービス待ち時間を報告する際の例示的なフロー図１６００を示す。図１６に示すように、デバイス２００の少なくとも一部が、ブロック１６０２の第１の状態にあってよい。ブロック１６０４で、サービス待ち時間報告ロジック２０８は、第１の状態に対応する第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１６０６で、デバイス２００の少なくとも一部が、第２の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック１６０８で、サービス待ち時間報告ロジック２０８は、第２の状態に対応する第２のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１６１０で、デバイス２００の少なくとも一部が、第１の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。特定結果が肯定的である場合、ブロック１６１２で、サービス待ち時間報告ロジック２０８は、第１のサービス待ち時間に対応するデータを送信してよい。遷移特定ロジック２０６は、ブロック１６１４で、デバイス２００の少なくとも一部が、第２の状態に既に遷移したか、あるいは遷移しようとしているところか、特定してよい。一実施形態では、このような特定は、前の第１の状態から第２の状態への遷移の特定の後の、固定された時間間隔の満了に少なくとも部分的に基づいてなされてよい。１６１４で特定結果が肯定的である場合、ブロック１６０８で、サービス待ち時間報告ロジック２０８は、第２のサービス待ち時間に対応するデータを送信してよい。一実施形態のサービス待ち時間報告ロジック２０８および遷移特定ロジック２０６は、このようにしてブロック１６０８から１６１４の動作を繰り返してよい。

図１７は、一実施形態において、上流デバイスへサービス待ち時間を報告するデバイス２００の例示的な図を示す。図１７のデバイス２００は、実質的に固定された時間間隔でアイドル状態からより高いアクティビティ状態へ遷移してよく、次の時間間隔の満了前にアイドル状態へ戻ることができる。図１７のデバイス２００は、例えば、ＶＯＩＰ（voice over internet protocol）デバイスであってよい。

図１７に示すように、１７０２でデバイス２００は、より高いアクティビティ状態（デバイス２００と上流デバイスとの間のデータ転送が表す）からアイドル状態へ遷移して、１ミリ秒（ｍｓ）のサービス待ち時間に対応するデータを上流デバイスに送信してよい。１７０４でデバイス２００は、デバイス２００が再度より高いアクティビティ状態に入ろうとしている場合２０マイクロ秒（μｓ）のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。デバイス２００が略２０ｍｓの時間間隔で、より高いアクティビティ状態に入るとき、デバイス２００は、略２０ｍｓの時間間隔で２０マイクロ秒（μｓ）のサービス待ち時間に対応するデータを上流デバイスへ送信してよい。

前述の記載では例示的な実施形態を示した。これら実施形態には様々な変形例および変更例が、添付請求項の範囲を逸脱しない範囲で可能である。故に、記載および図面は、例示的な意味合いで捉えられるべきであり、限定的に捉えられるべきものではない。

Claims

装置であって、
第１の状態から第２の状態への下流デバイスの少なくとも一部の遷移を特定する第１のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を１以上の上流デバイスに行わせる第２のロジックとを備え、
前記第１の状態および前記第２の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している装置。
前記第２のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項１に記載の装置。
前記第２の状態はアイドル状態である請求項２に記載の装置。
前記第２の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項１に記載の装置。
前記第２の状態はアクティブ状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファのリザーブ容量に少なくとも部分的に基づく請求項１に記載の装置。
前記第２の状態は、前記第１の状態より低い電力状態である請求項１に記載の装置。
前記第１の状態は前記下流デバイスによる１以上のタスクの実行に対応しており、前記第２の状態は前記下流デバイスによる１以上のタスクの完了に対応している請求項１に記載の装置。
前記第２のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項１に記載の装置。
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第１の状態から前記第２の状態へ遷移する請求項１に記載の装置。
前記第１のロジックは、前記下流デバイスの少なくとも一部が前記第１の状態から前記第２の状態へ遷移しようとしていることを特定する請求項１に記載の装置。
前記第１のロジックは、前記下流デバイスの少なくとも一部が前記第１の状態から前記第２の状態へ遷移したことを特定する請求項１に記載の装置。
方法であって、
第１の状態から、第２の状態への下流デバイスの少なくとも一部の遷移を特定する段階と、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を１以上の上流デバイスに行わせる段階とを備え、
前記第１の状態および前記第２の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している方法。
前記遷移の特定の後に、前記データの送信まで所定の時間待つ段階を備える請求項１２に記載の方法。
前記第２の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項１２に記載の方法。
前記第２の状態は、前記第１の状態より低い電力状態である請求項１２に記載の方法。
前記第１の状態は前記下流デバイスによる１以上のタスクの実行に対応しており、前記第２の状態は前記下流デバイスによる１以上のタスクの完了に対応している請求項１２に記載の方法。
前記送信する段階は、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する段階を有する請求項１２に記載の方法。
実質的に固定された時間間隔で前記下流デバイスの少なくとも一部が前記第１の状態から前記第２の状態へ遷移する段階を備える請求項１２に記載の方法。
下流デバイスであって、
第１の状態から第２の状態への前記下流デバイスの少なくとも一部の遷移を特定する第１のロジックと、
前記特定された遷移に呼応して、サービス待ち時間に対応するデータを上流デバイスへ送信して、前記サービス待ち時間に少なくとも部分的に基づく電力管理を１以上の上流デバイスに行わせる第２のロジックと、
前記下流デバイスの機能の制御を助ける第３のロジックとを備え、
前記第１の状態および前記第２の状態は、前記下流デバイスの少なくとも一部のアクティビティに関する互いに異なるレベルに対応している下流デバイス。
前記第２のロジックは、前記遷移の特定の後に、前記データの送信まで所定の時間待つ請求項１９に記載の下流デバイス。
前記第２の状態はアイドル状態であり、前記サービス待ち時間は、前記下流デバイスがデータを受信するためのバッファの利用可能な容量に少なくとも部分的に基づく請求項１９に記載の下流デバイス。
前記第２の状態は、前記第１の状態より低い電力状態である請求項１９に記載の下流デバイス。
前記第１の状態は前記下流デバイスによる１以上のタスクの実行に対応しており、前記第２の状態は前記下流デバイスによる１以上のタスクの完了に対応している請求項１９に記載の下流デバイス。
前記第２のロジックは、上流デバイスが特定したサービス待ち時間に対応するデータを前記上流デバイスに送信する請求項１９に記載の下流デバイス。
前記下流デバイスの少なくとも一部は、実質的に固定された時間間隔で前記第１の状態から前記第２の状態へ遷移する請求項１９に記載の下流デバイス。