JP2010506270A - 無線機器におけるリソース管理のための方法及び装置 - Google Patents

Abstract

無線機器におけるリソースを管理するための技術が記述される。一態様において、無線機器はリソース要求及び利用可能リソースに基づいてアプリケーションを制御する。アプリケーションによる処理要求が監視され、処理要求及びアプリケーションを実行する処理ユニットの最大処理容量に基づいて少なくとも１つのアプリケーションが制御されてよい。高い処理要求が検出されるときにアプリケーションによって交換されるデータ量を削減することによりデータアプリケーションは制御されてよく、逆も同様である。別の態様において、無線機器はリソース要求を満たすためにリソース容量を変更してよい。処理ユニットの処理容量は、処理要求に基づいて調整されてよい。処理要求が高閾値を超えるときにより高いクロック周波数が処理ユニットに関して選択されてよく、処理要求が低閾値の下に落ちるときにより低いクロック周波数が選択されてよい。

Description

（関連出願の相互参照）
本願は、「ミップス（MIPS）要求がチップセットの構造的性能を超過するときにアプリケーション性能を優美に（gracefully）低減させる」と題され、２００６年９月２９日に出願され、譲受人に譲渡され、参照によって本願明細書に組み込まれる米国仮出願番号No.60/827,678に対する優先権を主張する。

本開示は、一般にはエレクトロニクスに関し、より具体的には無線機器におけるリソース管理のための技術に関する。

無線通信ネットワークは、例えば音声、ビデオ、パケットデータ、メッセージング、放送などの様々な通信サービスを提供するために広く配備されている。これら無線ネットワークは、利用可能なネットワークリソースを共有することにより複数ユーザをサポート可能な多元接続ネットワークであるかもしれない。そのような多元接続ネットワークの例は、符号分割多元接続（CDMA）ネットワーク、時分割多元接続（TDMA）ネットワーク、周波数分割多元接続（FDMA）ネットワーク、直交周波数分割多元接続（OFDMA）ネットワーク、シングルキャリア周波数分割多元接続（SC-FDMA）ネットワークなどを含む。

無線機器（例えば、携帯電話機）は、１または複数のサービス（例えば音声及び／またはパケットデータ）のために無線ネットワークと活発に通信するかもしれない。無線機器は、無線ネットワークと通信するために、データ処理のための処理リソースを浪費するかもしれない。無線機器は、当該無線機器で作動中のその他のアプリケーションも持つかもしれない。各アプリケーションは任意の時間で開始または終了するかもしれず、作動中であるときに一定量の処理リソースを消費するかもしれない。無線機器における処理要求は、時間とともに大きく変動するかもしれないし、無線機器で作動中の特定のアプリケーションだけでなく無線ネットワークと交換されるデータ量に左右されるかもしれない。処理要求が無線機器の処理容量を超過するならば、ある不都合な作用がおこるかもしれず、貧弱な（poor）ユーザ・エクスペリエンスを引き起こすかもしれない。例えば、無線機器における処理容量の不足によりパケットが脱落し、及び／または、アプリケーションが正常に機能しないかもしれない。

故に、技術分野において、無線機器における処理容量を超える処理要求による不都合な作用を軽減するための技術への要求がある。

無線機器におけるリソースを管理するための方法が本願明細書において記述される。一態様において、無線機器はリソース要求及び利用可能リソースに基づいてアプリケーションを制御する。アプリケーションは、最大の処理容量を備える処理ユニットによって実行されてよい。アプリケーションによる処理要求は、監視されてよい。少なくとも１つのアプリケーションが処理要求及び処理ユニットの最大の処理要求に基づいて制御されてよい。例えば、アプリケーションは、(i)高い処理要求が検出されるときに基地局と交換されるデータ量を削減すること、または、(ii)低い処理要求が検出されるときに基地局と交換されるデータ量を増加させることにより、制御されてよい。基地局と交換されるデータ量は、例えばデータアプリケーションにより交換される確認されていないパケットの数を規制するウィンドウサイズを調整することにより、変更されてよい。

別の態様において、無線機器は好ましい性能を達成するために無線機器における異なるリソースを管理する。無線機器は、アプリケーションによる割り当て可能な処理リソース、バスリソース、メモリリソース、キャッシュリソース及び／またはその他のリソースに関しての処理要求、バス要求、メモリ要求、キャッシュ要求及び／またはその他のリソース要求を夫々監視してよい。無線機器は、アプリケーションによる要求に基づいて少なくとも１つのアプリケーションを制御してよい。無線機器は、アプリケーションの優先度、各アプリケーションが制御可能か制御可能でないかの表示などに基づいて少なくとも１つのアプリケーションを選択してよい。

更なる別の態様において、無線機器はリソース要求を満たすためにリソース容量を変更してよい。アプリケーションは、設定可能な処理容量を備える処理ユニットによって実行されてよい。アプリケーションによる処理要求は、監視されてよい。処理ユニットの処理容量は、処理要求に基づいて調整されてよい。例えば、処理要求が高閾値を超えるときにより高いクロック周波数が処理ユニットに関して選択され、処理要求が低閾値より下に落ちるときにより低いクロック周波数が選択されてよい。

本開示の各種態様及び特徴は、以下に更に詳しく記述される。

図１は、無線機器及び基地局のブロック図を示す。 図２は、リソース管理システムの図を示す。 図３は、ＣＰＵ使用に基づくＣＰＵクロック周波数の調整を示す。 図４は、リソース管理システムにおけるモジュール間の相互作用を示す。 図５は、２つの閾値を備えたＣＰＵ負荷レポートを示す。 図６は、ＣＰＵ負荷に基づくウィンドウサイズの調整を示す。 図７は、リソース要求に基づいてアプリケーションを制御するための処理を示す。 図８は、基地局によって行われる処理を示す。 図９は、無線機器において異なるリソースを管理するための処理を示す。 図１０は、要求をマッチさせるべくリソース容量を変更するための処理を示す。

図１は、無線通信ネットワーク内の無線機器１００及び基地局１５０の設計(design)のブロック図を示す。基地局１５０は、NB(Node B)、eNB(evolved Node B)、アクセスポイント、基地送受信局（BTS）などとしても参照されてよい。図１に示される設計において、基地局１５０は、無線機器との無線通信をサポートする送信器／受信器（TMTR/RCVR）１５２、無線機器との通信のための様々な機能を実行するコントローラ／プロセッサ１６０、基地局１５０のためのプログラムコード及びデータを保存するメモリ１６２、及びその他のネットワークエンティティーとの通信をサポートする通信（Comm）部１６４を含む。一般に、基地局は、任意の数のコントローラ、プロセッサ、メモリ、送信器、受信器などを含んでよい。

無線機器１００は、ユーザ装置（UE）、移動局、端末、アクセス端末、モバイル装置、加入者局、局などとしても参照されてよい。無線機器１００は、携帯電話機、パーソナル・デジタル・アシスタント（PDA）、無線モデム、携帯用デバイス、ラップトップコンピュータなどであってもよい。

受信経路上では、アンテナ１１２が基地局１５０、その他の基地局、衛星などによって送信される信号を受信し、受信信号を受信器（RCVR）１１４に与える。受信器１１４は、受信信号を処理（例えば、フィルタ、増幅、周波数ダウンコンバート、デジタル化）し、更なる処理のためにサンプルをデジタル部１２０に与える。送信経路上では、デジタル部１２０は、送信されるデータを処理し、データチップ(chip)を送信器（TMTR）１１６に与える。送信器１１６は、データチップを処理し（例えば、アナログに変換、フィルタ、増幅、周波数アップコンバート）、アンテナ１１２を介して送信される変調信号を生成する。

デジタル部１２０は、１または複数の無線通信ネットワークとの通信だけでなくその他のアプリケーションをサポートするための様々な処理、メモリ及びインタフェース部を含んでよい。図１に示される設計において、デジタル部１２０は、中央処理ユニット（CPU）１３０、コントローラ／プロセッサ１３２、メモリ１３４、キャッシュ１３６、外部インタフェース１３８を含み、それら全てがバス１４０に結合されている。ＣＰＵ１３０は、任意の数のデジタル信号プロセッサ（DSPs）、縮小命令セットコンピュータ（RISC）プロセッサ、汎用プロセッサなどを包含してよい。ＣＰＵ１３０は、データ送信（例えば、符号化及び変調）のための処理、データ受信（例えば、復調及び復号）のための処理、及び無線ネットワークと交換されたデータのための上位レイヤ処理を行ってよい。ＣＰＵ１３０は、その他のアプリケーションための処理を行ってもよい。コントローラ／プロセッサ１３２は、無線機器１００における動作を指図し、及び／または、その他の機能を行ってよい。メモリ１３４は、デジタル部１２０内の様々なユニットのためのデータ及び／または命令を保存してよい。キャッシュ１３６は、データ及び／または命令のための一次記憶を提供してよい。インタフェース部１３８は、例えばメインメモリ１４２、入出力（I/O）機器などのその他のユニットのインタフェースとなってよい。デジタル部１２０は、１または複数の特定用途集積回路（ASICs）及び／または何らかのその他の種類の集積回路（ICs）で実装されてよい。

一般に、無線機器１００は、図１に示されるものに比べてより少なく、より多く及びまたは異なる処理、メモリ及びインタフェース部を含んでよい。デジタル部１２０に含まれる処理部の数及び処理部の種類は、無線機器１００によってサポートされる通信ネットワーク及びアプリケーション、コスト及びパワー考察などの様々な要素に左右されてよい。

無線機器１００は、無線広域ネットワーク（WWANs）、無線ローカルエリアネットワーク（WLANs）、無線パーソナルエリアネットワーク（WPANs）、放送ネットワークなどとの通信をサポートしてよい。「ネットワーク（network）」及び「システム（system）」という文言は、しばしば置き換え可能に使用される。WWANは、CDMA、TDMA、FDMA、OFDMA、SC-FDMA及び／またはその他の無線ネットワークであってよい。CDMAネットワークは、UTRA(Universal Terrestrial Radio Access）、cdma2000などの無線技術を実行してよい。UTRAは、広帯域CDMA(W-CDMA)及び時分割同期CDMA(TD-CDMA)を含む。cdma2000は、IS-2000、IS-95及びIS-856標準をカバーする。TDMAネットワークは、GSM(Global System for Mobile Communications)などの無線技術を実行してよい。OFDMAネットワークは、E-UTRA(Evolved UTRA)、IEEE 802.16、IEEE 802.20、Flash-OFDM（登録商標）などの無線技術を実行してよい。UTRA、E-UTRAは、UMTS(Universal Mobile Telecommunication System)の一部である。UTRA、E-UTRA、UMTS及びGSMは、「3GPP(3rd Generation Partnership Project)」という名称の団体からの文書に記述されている。cdma2000は、「3GPP2(3rd Generation Partnership Project 2)」という名称の団体からの文書に記述されている。WLANは、例えばIEEE 802.11、Hiperlanなどの無線技術を実行してよい。WPANは、例えばBluetooth（登録商標）などの無線技術を実行してよい。放送ネットワークは、DVB-H(Digital Video Broadcasting for Handhelds)、ISDB-T(Integrated Services Digital Broadcasting for Terrestrial Television Broadcasting)、メディアフロー(Media FLO)などの無線技術を実行してよい。これら各種ネットワーク、無線技術、及び標準は技術分野において既知である。

明確にするために、以下の説明は、無線機器１００がUMTSをサポートすることを仮定する。3GPP Release 5及びそれ以降は、高速ダウンリンクパケットアクセス（HSDPA）をサポートする。3GPP Release 6及びそれ以降は、高速アップリンクパケットアクセス（HSUPA）をサポートする。HSDPA及びHSUPAは、夫々ダウンリンク及びアップリンク上での高速パケットデータ送信を可能にするチャネル及び手続の組である
無線機器１００は、様々なアプリケーションをサポートしてもよい。アプリケーションは、特定の機能を実行するソフトウェア及び／またはファームウェアモジュールであってよい。異なるアプリケーションが、異なる無線技術、所定の無線技術の異なる特徴などのために使用されてよい。例えば、無線機器１００は、HSDPA、HSUPA、WLAN、Bluetooth、MediaFLO、音声、ビデオ、テレビ電話通信、ウェブブラウザ、ｅメール、テキストエディタのためのアプリケーション、グラフィックアプリケーション（例えばビデオゲーム、A-GPS(assisted Global Positioning System)など）などをサポートしてよい。

無線機器１００は、無線機器上で作動中のアプリケーションの全てをサポートするために使用され得る、様々な種類のリソースを持っていてよい。無線機器１００におけるリソースは、次のように分類されてよい。
・処理リソース−アプリケーションに関する処理を行うためのリソース、例えばＣＰＵ１３０。
・メモリリソース−アプリケーションに関するデータを保存するためのリソース、例えばメモリ１３４。
・キャッシュリソース−アプリケーションに関する一次データ記憶のためのリソース、例えばキャッシュ１３６。
・バスリソース−アプリケーションに関するデータを転送するためのリソース、例えばバス１４０。

無線機器１００におけるリソースは、設定可能であってよい。例えば、無線機器１００の処理容量はＣＰＵ１３０のクロック周波数の調整によって変更されてよく、バス容量はバス１４０のクロック周波数の調整によって変更されてよい。ＣＰＵ及びバス周波数が高くなるほど、より多くの処理及びバスリソースが提供されるかもしれないが、無線機器１００のバッテリ寿命を短くし得る、より高い電力消費をももたらすかもしれない。一般に、電力消費を最小化できるように、全ての動作中のアプリケーションの要求を満たすために十分な処理及びバスリソースを提供可能な最小のＣＰＵ及びバスクロック周波数で動作することが望ましいかもしれない。メモリ及びキャッシュリソースに関して、利用可能なリソースの量は設計によって定められるかもしれないが、これらのリソースは動作中のアプリケーションに対して異なる方法で割り当てられ得る。例えば、メモリ集中型（memory intensive）なアプリケーションは、メモリ集中型でないアプリケーションに比べて、より多くのキャッシュ及び／またはメモリリソースが割り当てられてよい。

一般に、任意の数のアプリケーション及び任意の種類のアプリケーションが、任意の特定時間に無線機器上で動作中であってよい。各動作中アプリケーションは、特定のリソース要求または必要性（requirement）を持つかもしれない。無線機器１００において利用可能なリソースは、例えばＣＰＵ及びバスクロック周波数の調整により、全ての動作中アプリケーションのリソース要求を満たすように設定される。一部の場合において、無線機器１００によってサポートされる最高のＣＰＵ及びバスクロック周波数でさえも、全ての作動中アプリケーションの要求を満たすために十分なリソースを提供できないかもしれない。このような場合には、１または複数の作動中アプリケーションは、利用可能なリソースに合わせてリソース要求を縮小するように制御されるかもしれない。

図２は、無線機器１００のためのリソース管理システム２００の設計（design）の図を示す。この設計において、システム２００は、リソースコントローラ２１０、リソースモニタ２１２及びハードウェアマネージャ２１４を含む。モジュール２１０、２１２及び２１４は、各々、無線機器１００上で作動中のソフトウェア及び／またはファームウェア、無線機器１００内で実装されているハードウェア、または両方の組み合わせで実装されてよい。

リソースモニタ２１２は、動作中アプリケーションによるリソース使用を判定してよい。

処理リソースに関して、リソースモニタ２１２は測定間隔内でのＣＰＵ１３０についての有効クロックサイクルの数をカウントしてよい。リソースモニタ２１２は、測定間隔内での有効クロックサイクルの数及び／または遊休（idle）クロックサイクルの数に基づいて、動作中アプリケーションによって使用される処理リソースの量を確かめてよい。リソースモニタ２１２は、測定間隔内でＣＰＵ１３０が使用される時間比率であるＣＰＵ負荷を判定してよい。ＣＰＵ負荷は、測定間隔内のクロックサイクルの総数に対する有効クロックサイクルの数の比率に基づいて計算されてよい。測定間隔は、リソース使用のレポートを得ることにおける遅延を低減するためだけでなく十分なアベレージング（averaging）を提供するために選択されてよい。測定間隔は、１００ミリ秒(ms)、２００msなどであってよい。リソースモニタ２１２は、例えばバスリソース、メモリリソース、キャッシュリソースなどのその他のリソースの使用を判定してもよい。リソースモニタ２１２は、各作動中アプリケーション、制御され得る各作動中アプリケーション、共に制御され得る作動中アプリケーションの各組、全ての作動中アプリケーションなどによるリソース使用を判定してよい。

ハードウェアマネージャ２１４は、無線機器１００における様々な種類のリソースの設定を制御してよい。ハードウェアマネージャ２１４は、処理リソースに関しての要求に基づいてＣＰＵ１３０のクロック周波数を変更し、及び／または、バスリソースに関しての要求に基づいてバス１４０のクロック周波数を変更してよい。ハードウェアマネージャ２１４は、メモリ及びキャッシュリソースに関しての要求に基づいて、メモリ１３４及びキャッシュ１３６を夫々割り当て／再度割り当ててもよい。ハードウェアマネージャ２１４は、リソースコントローラ２１０からのコマンド、指示(directions)、要求及び／またはその他の情報を受信し、様々な種類のリソースを適宜設定してよい。

リソースコントローラ２１０は、動作中アプリケーションのリソース要求を無線機器１００上で利用可能なリソースに適合させるよう試みてよい。リソースコントローラ２１０は、例えばいつアプリケーションが起動したかなどの、各動作中アプリケーションについての関連情報を得る。各アプリケーションに関しての情報は、次のものを含んでよい。
・アプリケーションはリソース使用を削減するために制御可能であるか否かの表示。
・アプリケーションのピーク及び／または最小のリソース要求。
・リソース管理に関して有用な、アプリケーションの優先度及び／またはその他の特徴。

リソース要求が利用可能なリソースを超過するときに、所定のアプリケーションはリソース使用を低減するよう制御されるかもしれないし、されないかもしれない。アプリケーションが制御され得るか否かは、例えばアプリケーションの優先度、アプリケーションによる期待リソース使用などの様々な要素に左右されてよい。アプリケーションが制御され得るならば、利用可能なリソースによってリソース要求が満たされるように、アプリケーションの動作が調整され、及び／または、アプリケーションに割り当てられるリソース量が変更されてよい。

所定のアプリケーションのリソース要求は、例えばＣＰＵ／バスクロック周波数、単位時間当たりのＣＰＵ／バスサイクル数などの様々なパラメータによって与えられてよい。明確にするために、処理及びバスリソースは、以下の説明においてＣＰＵ／バスクロック周波数によって定量化される。長期間持続される必要のない集中的な（bursty）リソース要求を備えたアプリケーション（例えば、ファイルダウンロード）のためにピークリソース要求が使用されるかもしれない。長期間持続されなければならないかもしれない特定のリソース要求を備えたアプリケーション（例えば、音声通信）のために最小のリソース要求が使用されるかもしれない。

アプリケーションの優先度及び／またはその他の特徴は、リソース要求を削減するためにアプリケーションをいつどのように制御するかを決定するために使用されてよい。リソース要求が利用可能なリソースを超過するときに、低い優先度のアプリケーションは最初に制御されてよく、高い優先度のアプリケーションは最後に制御されてよい。後述されるように、異なるアプリケーションは異なる方法で制御されてよい。

リソースコントローラ２１０は、動作中のアプリケーションによるリアルタイムのリソース使用を伝達し得るリソース使用レポートを受信してよい。リソースコントローラ２１０は、リソース使用に基づいてハードウェア設定を変更するか否かを決定してよい。例えば、リソースコントローラ２１０は、利用可能なリソースが概して不十分に利用されているときに、より低いＣＰＵ／バスクロック周波数を使用するようハードウェアマネージャ２１４に命令してよい。リソースコントローラ２１０は、利用可能なリソースがリソース要求を満たすに十分でないときに、より高いＣＰＵ／バスクロック周波数を使用するようハードウェアマネージャ２１４に命令してよい。リソースコントローラ２１０は、利用可能なリソースが、たとえ最高のＣＰＵ／バスクロック周波数でも、リソース要求を満たすに十分でないならば、リソース要求を削減するために１または複数のアプリケーションを制御してもよい。リソースコントローラ２１０は、リソース要求をリソース供給に適合させるためにリソース要求だけでなく利用可能なリソースを制御してよい。

Ｎ個のアプリケーション２２０ａ乃至２２０ｎが、作動中であるかもしれない（一般にＮは０または１以上の任意の整数値）。図２に示される例において、アプリケーション２２０ａは診断（diagnostic）アプリケーションであってよく、アプリケーション２２０ｂはHSDPAのためのものでよく、アプリケーション２２０ｃはHSUPAのためのものでよく、アプリケーション２２０ｄはテレビ電話通信のためのものでよく、アプリケーション２２０ｎはバックグラウンドダウンロードのためのものでよい。各アプリケーション２２０は起動時にリソースコントローラ２１０に登録されてよく、上述したような関連情報を提供してよい。制御され得る各動作中アプリケーションは、リソース使用を削減すべく、適時に、その動作を調整するためにコントローラ２１０からコマンドを受信してよい。一般に、アプリケーション２２０は、任意の種類のリソースに関して制御され得る。明確にするため、以下の説明の大部分は、処理リソース（ＣＰＵリソースとしても参照される）に関するものである。

ＣＰＵ１３０は、基地局１５０との通信をサポートするアプリケーションだけでなく無線機器１００上で作動中のその他のアプリケーションも実行してよい。リソースコントローラ２１０は、望ましい性能を達成するために、ＣＰＵ１３０の動作、その他のリソース、及び／または作動中のアプリケーションを制御してよい。

一態様において、無線機器１００上で利用可能なリソースは、作動中のアプリケーションによる処理要求に基づいて調整されてよい。例えば、ＣＰＵ負荷はリアルタイムで監視されてよく、ＣＰＵクロック周波数はＣＰＵ負荷に基づいて調整されてよい。一設計において、ＣＰＵ負荷は高閾値及び低閾値と対照して比較されてよい。ＣＰＵ負荷が高閾値を超過するならばより高いＣＰＵクロック周波数が（利用可能ならば）選択されてよい。ＣＰＵ負荷が低閾値を下回るならばより低いＣＰＵクロック周波数が（利用可能ならば）選択されてよい。

別の態様において、作動中のアプリケーションは、必要ならば、無線機器１００上で利用可能なリソースによってリソース要求が満たされ得るように、制御されてよい。リソース要求は、リアルタイムの監視を通じて確かめられてよい。利用可能なリソースは、リソース要求に基づいて、例えば異なるクロック周波数を選択することにより、増加または減少されてよい。しかしながら、利用可能なリソースが最大の容量に到達するとき、作動中のアプリケーションは、利用可能なリソースを下回るようリソース要求を削減するために制御されてよい。

例えば、ＣＰＵ１３０が高閾値を上回るＣＰＵ負荷で動作するならば、リソースコントローラ２１０はこの状態を補正するための措置を講じてよい。リソースコントローラ２１０は、ＣＰＵ負荷に基づいて基地局１５０からのダウンリンク送信及び／または無線機器１００からのアップリンク送信を調整／抑圧してよい。代替してまたは追加的に、リソースコントローラ２１０は無線機器１００上で作動中のその他の１または複数のアプリケーションの性能の低減を命令してよい。例えば、リソースコントローラ２１０は、ＣＰＵ要求を低減してより高い優先度のアプリケーション（例えば音声通信）のためにＣＰＵリソースを解放するべく、バックグラウンドアプリケーション（例えばダウンロードプログラム）により低速で動作するよう命令してよい。或いは、リソースコントローラ２１０は、バックグラウンドアプリケーションを一時的に停止または終了してよい。いずれの場合においても、バックグラウンドアプリケーションを制御することは、より高い優先度のアプリケーションのサービス品質（QoS）を損なわないかもしれない。

図３は、作動中アプリケーションによるＣＰＵ要求に基づくＣＰＵクロック周波数の調整例を示す。この例において、３つのＣＰＵクロック周波数ｆ1、ｆ2、ｆ3がサポートされている（ｆ1＜ｆ2＜ｆ3）。最大のＣＰＵ容量は、最高のクロック周波数ｆ3で達成される。

ＣＰＵ１３０は、Ａにおいて最低のクロック周波数ｆ1で最初に動作する。ＣＰＵ負荷は、作動中アプリケーションによるより高い要求によって増加し、Ｂにおいて高閾値に到達する。ＣにおいてＣＰＵクロック周波数はｆ1からｆ2に切り替えられ、ＤにおいてＣＰＵ負荷はより高いクロック周波数ｆ2でのより多くのＣＰＵ容量によって減少する。ＣＰＵ負荷は、より高い要求により再度増加し、Ｅにおいて高閾値に達する。ＦにおいてＣＰＵクロック周波数はｆ2からｆ3に切り替えられ、ＧにおいてＣＰＵ負荷はより高いクロック周波数ｆ3でのより多くのＣＰＵ容量によって減少する。ＣＰＵ負荷はより高い要求によって再度増加し、Ｈにおいて高閾値に達する。

最高のＣＰＵクロック周波数ｆ3は既に選択されているので、リソースコントローラ２１０はリソース要求を削減するために作動中アプリケーションの制御を開始する。ＣＰＵ負荷は、作動中アプリケーションの制御に応じて減少する。リソースコントローラ２１０は、ＩにおいてＣＰＵ負荷が容認可能なレベルに達するときアプリケーションの制御を停止する。ＣＰＵ負荷は、その後より高い要求により再度増加し、Ｊにおいて高閾値に達する。リソースコントローラ２１０は作動中アプリケーションの制御を開始し、ＣＰＵ負荷はそれに応じて減少する。リソースコントローラ２１０は、ＫにおいてＣＰＵ負荷が容認可能なレベルに達するときアプリケーションの制御を停止する。

ＣＰＵ負荷は、その後作動中アプリケーションによるより低い要求によって減少し、Ｌにおいて低閾値に達する。要求が低閾値以下である所定時間の後、ＭにおいてＣＰＵクロック周波数はｆ3からｆ2へ切り替えられる。Ｎにおいてより低いクロック周波数ｆ2でのより低いＣＰＵ容量によってＣＰＵ負荷は増加する。ＣＰＵ負荷はより低い要求により再度減少し、Ｏにおいて低閾値に達する。所定時間の後、ＰにおいてＣＰＵクロック周波数はｆ2からｆ1に切り替えられ、Ｑにおいてより低いクロック周波数ｆ1でのより低いＣＰＵ容量によってＣＰＵ負荷は増加する。

図３に示される設計（design）において、ＣＰＵクロック周波数を調整し、作動中アプリケーションを制御するために２つの閾値が使用されている。同様の高及び低閾値は、図３に示すように、全てのＣＰＵクロック周波数のために使用されてよい。或いは、異なる高及び低閾値の組が、各ＣＰＵクロック周波数のために使用されてよいし、クロック周波数に対してのＣＰＵ容量に基づいて選択されてよい。別の設計において、３以上の閾値がＣＰＵクロック周波数の調整及び／または作動中アプリケーションの制御のために使用されてよい。同様の閾値は、全ての作動中アプリケーションのために使用されてよい。或いは、異なる作動中アプリケーションは、異なる閾値の組を持っていてもよい。各作動中アプリケーションは、アプリケーションのための閾値の組との比較上のＣＰＵ負荷に基づいて制御されてよい。

図３は、ＣＰＵ要求に基づいてＣＰＵ容量を変更するためのＣＰＵクロック周波数調整を示している。例えばバスリソースなどのその他のリソースは、同様の方法で制御されてよい。

図４は、図２におけるリソースコントローラ２１０、リソースモニタ２１２、ハードウェアマネージャ２１４及びアプリケーション２２０ａ乃至２２０ｎの相互作用を示す。リソースコントローラ２１０は、リソースモニタ２１２からリソース使用レポートを受信してよい。各リソース使用レポートは、ＣＰＵ負荷及び／または無線機器１００におけるその他のリソースの使用を表示してよい。リソースコントローラ２１０は、利用可能なリソースが作動中アプリケーションのリソース要求を満たすに十分であるか否かを判定してよい。リソースコントローラ２１０は、ハードウェアコマンド（例えば、より低いまたはより高いクロック周波数のための）をハードウェアマネージャ２１４に送ってよく、ハードウェアマネージャ２１４はリソース容量を変更するためにハードウェア設定を整えてよい。リソースコントローラ２１０は、必要に応じ、アプリケーションによるリソース要求を制御するために、各個別の作動中アプリケーション２２０に制御コマンドを送信してもよい。

リソースコントローラ２１０は、制御のための作動中アプリケーションを様々な方法で選択してよい。一設計において、リソースコントローラ２１０は、優先度だけでなくアプリケーションが制御され得るか否かの表示にも基づいて、制御のための作動中アプリケーションを選択する。リソースコントローラ２１０は、最低の優先度を備えたアプリケーションを最初に、２番目に低い優先度を備えたアプリケーションをその次に、そして最高の優先度を備えたアプリケーションを最後に、選択及び制御してよい。例えば、リソースコントローラ２１０は、次の順序でアプリケーションを選択してよい。
・受信されているいずれのサービスとも関連しない診断及びその他のアプリケーション。
・バックグラウンド及び遅延耐性のあるアプリケーション（例えばデータダウンロード）。
・インタラクティブ及び遅延に敏感な(delay-sensitive)アプリケーション（例えば、ビデオ電話通信）。

一部の事例では、単に診断アプリケーションだけを制御することが、十分な量のリソース要求を削減するかもしれない。診断アプリケーションを制御することが十分でないならば、次にバックグラウンドアプリケーションが制御されてよく、最後の手段としてインタラクティブアプリケーションが制御されてよい。この順序は、ユーザ・エクスペリエンスに対する影響を低減することになるだろう。

別の設計において、リソースコントローラ２１０は、もしあれば、QoS要求に基づいて制御のための作動中アプリケーションを選択する。リソースコントローラ２１０は、QoS要求のないアプリケーションを最初に、あまり厳格でないQoS要求を備えたアプリケーションを次に、そしてより厳格なQoS要求を備えたアプリケーションを最後に選択してよい。リソースコントローラ２１０は、QoS要求を満たすために、各作動中アプリケーションに十分なリソースを割り当ててよい。リソースコントローラ２１０は、リソース要求が利用可能リソースを超過すると、少しもQoS要求のない作動中アプリケーションに最小のリソースを割り当ててもよいし、全くリソースを割り当てなくてもよい。

UMTSにおいて、呼は、トラヒックデータを転送する１または複数のRAB(radio access bearer)及びシグナリングを転送する１または複数のSRB(signaling radio bearer)を持つかもしれない。各RABは、特定の特徴を備える分割(separate)データフローとみなされてよい。各RABは、例えば会話、ストリーミング、インタラクティブ、またはバックグラウンドなどの特定のクラスのためにトラヒックデータを運ぶ。一設計において、SRBは制御されない。インタラクティブ及びバックグラウンドクラスを運ぶRABが（例えばこれらRABの中で等しく）最初に制御されてよい。会話及びストリーミングクラスを運ぶRABが（例えばこれらRABの中で等しく）次に制御されてよい。この設計は、データフローがそれらのトラヒッククラスによって判断される優先度に基づく順序で制御されることを確実にする。一般に、より低い優先度のデータフローは最初に制御されてよく、より高い優先度のデータフローは次に（例えば、より低い優先度のデータフローが十分に制御されたのち）制御されてよい。

リソースコントローラ２１０は、異なる方法で異なるアプリケーションを制御してよい。診断アプリケーションに関して、リソースコントローラ２１０はアプリケーションによるレポートのためのメッセージ及び／またはイベントの種類を制御してもよいし、アプリケーションを無効にしてもよい。バックグラウンドアプリケーションに関して、リソースコントローラ２１０はこれらアプリケーションに割り当てられるリソース量（例えば、CPU速度）を削減したり、ダウンリンク及び／またはアップリンク上でのデータレートを低減させたり、アプリケーションを一時的に停止したりなどしてよい。インタラクティブアプリケーションに関して、リソースコントローラ２１０はデータレート、フレームレートなどを低減させてよい。

リソースコントローラ２１０は、制御のための作動中アプリケーションを選択し、及び／または、選択されたアプリケーションを制御するために、条件付き規則を適用してもよい。条件付き規則は、１または複数の所定の条件が発生したときに適用される規則である。例えば、リソースコントローラ２１０は、HSUPAのためのアップリンクデータレートと同じ方法でHSDPAのためのダウンリンクデータレートを変更してよい。

一設計において、リソースモニタ２１２は、CPU負荷（例えば、各測定間隔において定期的に）を判定し、CPU負荷を閾値の組と比較し、CPU負荷が閾値を越えるたびにリソースコントローラ２１０へレポートを送る。この設計は、リソースモニタ２１２によってリソースコントローラ２１０へ送られるレポートの数を削減できるかもしれない。

図５は、２つの閾値（高閾値及び低閾値）を備えたCPU負荷レポートに関する設計を示す。CPU負荷は、３つの可能(possible)範囲のうち１つの中にあるだろう。
・低(off)範囲−０％負荷から低閾値までにわたる。
・中間範囲−低閾値から高閾値までにわたる。
・高範囲−高閾値から１００％負荷までにわたる。
３つの範囲は、CPU状態としても参照されるかもしれない。リソースモニタ２１２は、CPU負荷が低範囲に遷移するたびに低CPU負荷レポートを送り、CPU負荷が中間範囲に遷移するたびに中間CPU負荷レポートを送り、CPU負荷が高範囲に遷移するたびに高CPU負荷レポートを送る。

一設計において、同様の高及び低閾値が全ての作動中アプリケーションのために使用されてよい。この設計では、リソースコントローラ２１０は、リソースモニタ２１２から低、中間及び高CPU負荷レポートを受信し、必要に応じて作動中アプリケーションを制御してよい。別の設計において、異なる高及び低閾値の組が、各作動中アプリケーションのために使用されてよい。この設計では、リソースモニタ２１２は、アプリケーションのための閾値の組に基づいて各アプリケーションに関して低、中間及び高CPU負荷レポートを生成してよい。リソースコントローラ２１０は、アプリケーションに関して受信した低、中間及び高CPU負荷レポートに基づいて各アプリケーションを制御してよい。高閾値は、９０％及び１００％の間の値に設定されてよい。低閾値は、８０％及び９０％の間の値に設定されてよい。高及び低閾値は、異なる値に設定されてもよい。

各アプリケーションは、アプリケーションに適した方法で制御されてよい。例えばHSDPA及びHSUPAなどのデータアプリケーションは、後述するように、様々な方法で制御されてよい。

HSDPAに関して、基地局１５０は各２msの伝送時間間隔（TTI）において高速ダウンリンク共有チャネル（HS-DSCH）上で１または複数のユーザにデータを送るかもしれない。HS-DSCHは、時間及び符号分割多重を介して全てのユーザによって共有される。各ユーザは、ユーザによって観測されるダウンリンクチャネル品質を伝えるチャネル品質表示（CQI）を定期的に送信する。基地局１５０は、CQIを全てのユーザから受信して、(i)次のTTIにおけるダウンリンク送信のための１または複数のユーザを選択し、かつ、(ii)各スケジュールされたユーザのためのデータレートを選択するために、CQI情報を使用する。一般に、高いダウンリンクチャネル品質を観測しているユーザにより多くのデータが送られるだろう。

HSDPAに関して、基地局１５０はリンク層で無線リンクプロトコル（RLC）を用いるプロトコルデータユニット（PDU）でデータを送信する。RLC PDUは、以下の説明においてPDUまたはパケットとしても参照されるかもしれない。各PDUは、４０バイト、８０バイトなどであってよい。RLCに関して、送信側はPDUを受信側に送り、各PDUは新たなPDUが送られるたびにインクリメントされるシーケンス番号によって識別される。受信側は、各受信PDUを復号化し、PDUが正しく復号化されるならばアクナリッジメント（ACK）を送信する。スループット改善のため、送信側は以前に送ったPDUに関してのACKを待機することなく新たなPDUを送ってよい。RLCウィンドウは、送信側から見た、ACKのない未解決のPDUの最大数を定める。Ｎは最も高く番号付けされたアクナリッジメントのない（確認されていない）PDUを表示しRLCウィンドウの始まりであり、ＷはRLCウィンドウサイズを表示しており、送信され得る最も高いシーケンス番号はＮ＋Ｗに等しい。送信側は、RLCウィンドウの始まりより前に送信した全てのPDUに関してACKが受信されない限り新たなPDUを送信できない。RLCウィンドウはサイズにおいて変化してもよく、１乃至２０４７個のPDUをカバーし得る。HSDPAに関してRLCウィンドウサイズは、無線機器１００がウィンドウコマンドを基地局１５０に送ることにより制御され得る。無線機器１００は、適切なRLCウィンドウサイズを選択することとこのウィンドウサイズを基地局に送信することとにより、基地局１５０によって無線機器１００に送信されるデータ量を制御してよい。RLCウィンドウを縮小することにより、より小さなRLCウィンドウは基地局１５０に新たなPDUを送信する前に従前のPDUに関してのACKを待機させることになるので、データ量は相応して削減されるだろう。HSUPAにおけるアップリンク送信に関して、基地局１５０は無線機器によって送信されるデータ量を制御するために、無線機器１００にコマンドを送信してよい。

一設計において、データアプリケーションは、データアプリケーションに関してのウィンドウサイズを調整することにより制御される。ウィンドウサイズはアプリケーションによって送信／受信されるデータ量を削減するために減じられてよく、これはアプリケーションによるリソース要求を削減することになるだろう。逆に、ウィンドウサイズはアプリケーションによって送信／受信されるデータ量を拡張するために増加されてよく、これはアプリケーションによるリソース利用を増大させることになるだろう。ウィンドウサイズの調整は、ダウンリンク送信（例えば、HSDPAによる）だけでなくアップリンク送信（例えば、HSUPAによる）のために使用され得る。ダウンリンクに関して、選択されたウィンドウサイズは、基地局１５０に送信される。アップリンクに関して、送信側は無線機器１００にあり、ウィンドウサイズは、基地局１５０に任意のコマンドを送信することなく、直接的に制御され得る。

データアプリケーションに関するウィンドウサイズは、様々な方法でＣＰＵ要求に基づいて制御されてよい。一設計において、ウィンドウサイズは、最小値及び最大値の間で変更され、様々な要素に基づいて選択されてよい。高ＣＰＵ負荷レポートが受信されるとき、ウィンドウサイズは最小値まで唐突に縮小されてよい。ウィンドウサイズのこの唐突な縮小は、高い優先度のアプリケーションは遅延耐性がないかもしれないし可能な限り素早く供給されるほうがよいので、可能な限り素早くリソースを解放するだろう。この唐突な縮小は、高閾値が１００％近くに設定されることを可能にするかもしれず、これはＣＰＵリソースのより高い利用を可能にすることになるだろう。ＣＰＵ要求が減少すると、ウィンドウサイズは歩調を整えて段階的に拡大されてよい。段階的な増加は、高及び低CPU負荷レポートが交互に生じることによるピンポン(ping-pong)効果（例えば、ウィンドウサイズが最大値及び最小値間で切り替えられる）を回避するかもしれない。ウィンドウが最大値未満である間に、ウィンドウサイズはCPU負荷レポートに基づいて歩調を整えて拡大され、または、減らされてよい。ウィンドウが最大値に達すると次に高CPU負荷レポートが受信されるときに、ウィンドウサイズは最小値まで唐突に縮小されてよい。

データアプリケーションが現在制御されているか否かを表示するためにフラグが使用されてよい。フラグは最初にオフに設定されていてよく、高CPU負荷レポートが受信されフラグがオフであるときに、オフからオンに切り替えられ、ウィンドウサイズが最大値に設定されフラグがオンであるときにオンからオフに切り替えられる。データアプリケーションに関するウィンドウサイズは、高CPU負荷レポートが受信されフラグがオフに設定されているときに、最小値にまで縮小されてよい。高CPUレポートが受信されるときにフラグがオンに設定されているならば、ウィンドウサイズは最小値が達成されるまで、各更新間隔において定期的にダウンステップだけ縮小されてよい。低CPU負荷レポートが受信されるとき、ウィンドウサイズは最大値が達成されるまで定期的にアップステップだけ拡大されてよい。中間CPU負荷レポートが受信されるとき、ウィンドウサイズは現在の値で維持されてよい。

図６は、データアプリケーションに関するウィンドウサイズの調整例を示す。この例は、CPU負荷のための高及び低閾値と、低、中間及び高CPU負荷レポートを備えた図５において示される設計に関するものである。時刻T0において、フラグはオフであり、ウィンドウサイズは最大値に設定されている。時刻T1において高CPU負荷レポートが受信され、データアプリケーションの制御が開始し、フラグはオンに設定され、ウィンドウサイズは最小値まで縮小される。時刻T2において低CPU負荷レポートが受信され、ウィンドウサイズはアップステップだけ拡大される。各更新間隔の後に、時刻T3及びT4において、ウィンドウサイズはアップステップだけ拡大される。

時刻T5において中間CPU負荷レポートが受信され、ウィンドウサイズは維持される。時刻T6において高CPU負荷レポートが受信され、フラグがオンなのでウィンドウサイズはダウンステップだけ縮小される。更新間隔の後に、時刻T7においてウィンドウサイズは、ダウンステップだけ縮小される。時刻T8において中間CPU負荷レポートが受信され、ウィンドウサイズは維持される。時刻T9において低CPU負荷レポートが受信され、ウィンドウサイズはアップステップだけ拡大される。各更新間隔の後に、時刻T10及びT11にいてウィンドウサイズはアップステップだけ拡大される。時刻T1においてウィンドウサイズは最大値に達し、フラグはオフに設定され、アプリケーションの制御は終了する。

フラグがオンであるときにウィンドウサイズを拡大または縮小するためにタイマが使用されてよい。タイマは、ウィンドウサイズ調整がなされたあと起動され、更新間隔をカウントダウンしてよい。タイマが満了(expire)するとき、別のウィンドウサイズ調整がなされてよく、タイマは再度起動されてよい。タイマは、中間CPU負荷レポートが受信されるときに中断されてよく、低または高CPU負荷レポートが受信されるときに中断された値から再開され、または、再起動されてよい。

例えば最小及び最大ウィンドウサイズ、アップ及びダウンステップサイズ、更新間隔などのパラメータは、所望の性能を達成するために適切な値が設定されてよい。最小ウィンドウサイズは、データアプリケーションに関しての最小の性能を達成するためだけでなくその他のプロトコルに関する悪影響を回避するために選択されてよい。例えば、伝送制御プロトコル（TCP）は、再伝送タイムアウト（RTO）内にTCPパケットが全く送信されず、確認され(acknowledged)なければタイムアウトするだろう。タイムアウトが発生するたびに、TCPは混雑(congestion)制御を行って、データフローを減少させるが、これは回復に長い時間を要し、結果として性能を劣化させることになるだろう。最小ウィンドウサイズは、TCPタイムアウトが発生する前に少なくとも１つのTCPパケットが送信され確認され得ることを確保するために十分に大きな値が設定されてよい。一設計において、最小ウィンドウサイズは８０PDUに設定されてよく、これはTCPタイムアウトを回避する。最大ウィンドウサイズは、２０４７の下または呼のセットアップまたは再構成の間に得られる値に設定されてよい。アップ及びダウンステップサイズは、図６に示されるように、ウィンドウサイズが４つの更新間隔で最大値まで拡大され得るよう、最大値の１／４に設定されてよい。その他のアップ及びダウンステップサイズも使用されてよい。更新間隔は、２００ｍｓまたは何らかのその他の継続期間に設定されてよい。

ダウンリンクデータアプリケーション（例えば、HSDPA）に関して、ウィンドウサイズが変化するたびに新しいウィンドウサイズを備えたウィンドウコマンドが基地局１５０に送られてよい。基地局１５０がウィンドウコマンドに関してのACKを送らないならば、信頼性を向上させるためにウィンドウコマンドが複数回送られてよい。アップリンクデータアプリケーション（例えば、HSUPA）に関して、新たなウィンドウサイズは無線機器１００において適用されてよい。

データアプリケーションは、１または複数のデータフローを持つかもしれず、各データフローは異なるRABに対応するかもしれない。単一のウィンドウが、全てのデータフローに関して維持されてよい。或いは、個別のウィンドウが各データフローに関して維持されてよく、データフローに関するパラメータの組に基づいて調整されてよい。

図６は、データアプリケーションの制御のための具体的な設計を示す。データアプリケーションはその他の方法で制御されてもよい。別の設計において、ウィンドウサイズは、フラグがオンであるかオフであるかに関わらず、高CPU負荷が受信されるたびに最小値まで唐突に縮小される。更なる別の設計において、３以上の閾値がCPU負荷をレポートするために使用されてよく、４以上の異なるCPU負荷がデータアプリケーションを制御するために使用されてよい。この設計において、ステップサイズはCPU負荷レポートによって決まってよい。

更なる別の設計において、データアプリケーションはデータソースによって生成されるデータ量を規制することにより制御されてよい。例えば、アップリンクデータアプリケーションのためのデータが無線機器１００にUSB(Universal Serial Bus)を介して接続されるラップトップコンピュータから到来するならば、無線機器１００によって受信されるデータ量を制限するためにラップトップコンピュータ及び／またはUSBが制御されてよい。別の例において、アップリンク伝送のためのデータが無線機器１００におけるプロトコルスタック内のTCPエンティティーから到来するならば、下層レイヤに渡されるデータ量を制限するためにTCPエンティティーが制御されてよい。

更なる別の設計において、データアプリケーションはCQIフィードバックに基づいて制御されてよい。無線機器１００は、ダウンリンクチャネル品質を定期的に測定し、測定されたチャネル品質を表示するCQIを送ってよい。基地局１５０は、無線機器１００に対するダウンリンク伝送のためのデータレートを選択するために、報告されたCQIを使用してよい。CPU負荷が高くない、または、ダウンリンクデータアプリケーションが制御されていないときに、無線機器１００は測定されたCQIを送ってよい。CPU負荷が高いならば、無線機器１００は測定されたCQIよりも低いCQIを送ってよく、これにより基地局１００がより低いデータレートを選択し、より少ないデータを無線機器１００に送るという結果になるだろう。無線機器１００は、基地局１５０から送られるデータ量を制御するために適切なCQIを上に述べたように送ってよい。

更なる別の設計において、データアプリケーションはCQIフィードバック及びブロック誤り率（BLER）に基づいて制御される。基地局１５０は、無線機器１００にPDUを送ってよい。無線機器１００は、各受信PDUの復号化を試み、PDUが正しく復号化されるならばACKを、或いは、PDUが誤って復号化されるならばネガティブ・アクナリッジメント（NAK）を返信してよい。基地局１５０は、ダウンリンク伝送のBLERを判定してよく、これは送信されたPDUの総数に対する誤って復号化されたPDUの数の割合である。基地局１５０は、無線機器１００によって報告されるCQI及び基地局１５０によって維持(maintain)されるBLERの両方に基づいてダウンリンク伝送のためのデータレートを選択してよい。BLERが低い（例えば目標BLERの下）ならば、基地局１５０は報告されるCQIにオフセットを加算してよく、調整されたCQIに基づいてデータレートを選択してよい。基地局１５０は、目標BLERを達成するためにCQIオフセットを上下に調整してよい。基地局１５０によって加算されるCQIオフセットは、無線機器１００によるCQI減少によって相殺されるかもしれない。基地局１５０によって加算されるオフセットに対抗するために、基地局１５０において測定されるBLERが目標BLERに近づき、基地局１５０によって加算されるCQIオフセットが小さく或いは零になるよう、無線機器１００は定期的にNAKを送ってよい。

データアプリケーションは、その他の機構を利用したその他の方法で制御されてもよい。上述した設計の組み合わせもデータアプリケーションのために使用されてよい。例えば、CQIフィードバックに基づく制御が最初と所定時間分の間実行され、ウィンドウサイズに基づく制御が上記所定時間分の後に起動されてよい。別の例として、CQIフィードバック及びウィンドウサイズ調整の両方に基づく制御が同時に行われてよい。

図７は、リソース要求に基づいてアプリケーションを制御するために無線機器によって行われる処理７００の設計を示す。無線機器上で作動中のアプリケーションは、最大の処理容量を備える処理ユニットによって実行されてよい（ブロック７１２）。処理ユニットは、１または複数のCPU、DSP、汎用プロセッサなど、或いは、それらの任意の組み合わせを包含する。アプリケーションによる処理要求は、コントローラ（無線機器上のソフトウェア及び／またはハードウェアであってよい）によって監視されてよい（ブロック７１４）。少なくとも１つのアプリケーションが、処理要求及び処理ユニットの最大処理容量に基づいて制御されてよい（ブロック７１６）。

少なくとも１つのアプリケーションは、無線機器上で作動中のアプリケーションの中からこれらアプリケーションの優先度に基づいて制御のために選択されてよい。低い優先度のアプリケーションは最初に制御されてよく、高い優先度のアプリケーションは低い優先度のアプリケーションが十分に制御された後に制御されてよい。

制御される少なくとも１つのアプリケーションは、データアプリケーションを含むかもしれない。このデータアプリケーションは、(i)高い処理要求が検出されるときに基地局と交換（に送信／から受信）されるデータ量を削減すること、または(ii)低い処理要求が検出されるときに基地局と交換されるデータ量を増加させることにより制御されてよい。高い処理要求は高閾値を越える処理要求に対応してよく、低い処理要求は低閾値よりも下に落ちている処理要求に対応してよい。

データアプリケーションは、処理要求及び最大処理容量に基づくウィンドウサイズの調整により制御されてよい。ウィンドウサイズは、データアプリケーションによって交換される確認されていない（unacknowledged）パケットの数を規制する。ウィンドウサイズは最大値及び最小値の間で調整されてよく、最小値はTCP及び／またはその他のプロトコルによるタイムアウトを回避すべく選択されてよい。高い処理要求が検出されるとき、ウィンドウサイズは、(i)データアプリケーションが未だ制御されていないならば最小値まで唐突に、または(ii)データアプリケーションが制御中ならば歩調を整えて、縮小されてよい。低い処理要求が検出されるとき、ウィンドウサイズは歩調を整えて拡大されてよい（例えば、最大値に至るまで、各更新区間において１アップステップ）。中間の処理要求が検出されるとき、ウィンドウサイズは維持されてよい。ダウンリンクに関して、信頼性向上のためにウィンドウサイズは基地局に１回或いは複数回送られてよい。ウィンドウサイズは、HSDPAにおけるRLCによって使用されてよい。

データアプリケーションは、CQIフィードバックに基づいて制御されてもよい。CQIは、基地局について無線機器において測定されるダウンリンクチャネル品質に基づいて得られるだろう。高い処理要求が検出されるとき、CQIは低減されてよく、低減されたCQIが基地局に送信されてよい。高い処理要求が検出されるとき、たとえパケットが正しく復号化されているとしても、基地局からの受信パケットの所定割合に関してNAKが送信されてもよい。データアプリケーションは、伝送ブロックサイズを変更すること、ネットワークに送信されるバッファステータスレポートを変更することなどにより制御されてもよい。バッファステータスレポートは、ネットワークリソース（スケジューリング情報及びトラヒック量測定値）が無駄にならないように変更されてよい。

図８は、基地局によって行われる処理８００の設計を示す。無線機器において処理要求及び最大処理容量に基づいて判断される情報は、基地局によって受信される（ブロック８１２）。無線機器と交換されるデータ量は、受信情報に基づいて制御されてよい（ブロック８１４）。データは、データ交換のために生じる制御に基づいて無線機器と交換されてよい（ブロック８１６）。情報は、確認されていない(unacknowledged)パケットの数を規制するウィンドウサイズ（例えば、HSDPAのためにRLCによって使用されるウィンドウサイズ）を包含してよい。パケットは、ウィンドウサイズに従って無線機器に送られる。情報はCQIを包含してよく、データレートはCQIに基づいて無線機器への伝送に関して選択されてよい。情報はCQI及びNAKを包含してもよく、データレートはCQI及びNAKに基づいて無線機器への伝送に関して選択されてよい。いずれの場合にも、パケットは選択されてデータレートに従って無線機器に送られてよい。

図９は、異なるリソースを管理するために無線機器によって行われる処理９００の設計を示す。無線機器における割り当て可能リソースに関してのアプリケーションによる処理要求は、監視されてよい（ブロック９１２）。少なくとも１つのアプリケーションが処理要求に基づいて制御されてよい（ブロック９１４）。割り当て可能バスリソースに関してのアプリケーションによるバス要求は、監視されてよい（ブロック９１６）。少なくとも１つのアプリケーションは、バス要求に基づいて制御されてよい（ブロック９１８）。割り当て可能メモリリソースに関してのアプリケーションによるメモリ要求は、監視されてよい（ブロック９２０）。少なくとも１つのアプリケーションは、メモリ要求に基づいて制御されてよい（ブロック９２２）。割り当て可能キャッシュに関してのアプリケーションによるキャッシュ要求は、監視されてよい（ブロック９２４）。少なくとも１つのアプリケーションは、キャッシュ要求に基づいて制御されてよい（ブロック９２６）。無線機器上で作動中のアプリケーションの優先度、各アプリケーションが制御可能か制御可能でないか、に関する情報及び／またはその他の情報は、例えばアプリケーションから受信されてよい。少なくとも１つのアプリケーションは、受信情報に基づいて制御のために選択されてよい。

図１０は、リソース要求を満たすためにリソース容量を変更するために無線機器によって行われる処理１０００の設計を示す。無線機器上で作動中のアプリケーションは、設定可能処理容量を備えた処理ユニットによって実行されてよい（ブロック１０１２）。アプリケーションによる処理要求は、監視されてよい（ブロック１０１４）。処理ユニットの処理容量は、処理要求に基づいて調整されてよい（ブロック１０１６）。例えば、処理要求を調整するために処理ユニットのクロック周波数が変更されてよい。処理要求が高閾値を超えるときにより高いクロック周波数が処理ユニットに関して選択されてよい。処理要求が低閾値より下に落ちるときにより低いクロック周波数が処理ユニットに関して選択されてよい。アプリケーションによるバス要求は監視されてよい（ブロック１０１８）。バス容量はバス要求に基づいて調整されてよい（ブロック１０２０）。例えば、バス容量を調整するために、バスのクロック周波数が変更されてよい。

本願明細書において記述される技術は、様々な方法によって実装されてよい。例えば、これら技術はハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせにおいて実装されてよい。ハードウェア実装に関して、エンティティー（例えば無線機器または基地局）において技術を実行するために使用される処理ユニットは、１または複数の特定用途集積回路（ASIC）、デジタルシグナルプロセッサ（DSP）、デジタル信号処理デバイス（DSDP）、プログラム可能論理回路（PLD）、フィールドプログラマブルゲートアレイ、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子機器、本願明細書において記述される機能を行うよう設計されたその他の電子ユニット、コンピュータ、またはそれらの組み合わせの内部で実装されてよい。

ファームウェア及び／またはソフトウェアに関して、技術は、本願明細書において記述される機能を実行するモジュール（例えば、手続、機能）で実装されてよい。ファームウェア及び／またはソフトウェア命令は、メモリ（例えば、図１におけるメモリ１３４または１６２）内に保存されてよく、プロセッサ（プロセッサ１３２または１６０）によって実行されてよい。メモリは、プロセッサ内またはプロセッサ外部に実装されてよい。ファームウェア及び／またはソフトウェア命令は、例えばランダムアクセスメモリ（RAM）、リードオンリーメモリ（ROM）、不揮発性ランダムアクセスメモリ（NVRAM）、プログラマブルリードオンリーメモリ（PROM）電気的消去可能PROM（EEPROM）、FLASHメモリ、コンパクトディスク（CD）、磁気または光データ記憶装置などのその他のプロセッサ読み取り可能な媒体内に保存されてもよい。

本願明細書において記述される技術を実装する装置は、独立のユニットであってもよいし、機器の一部であってもよい。機器は、(i)独立の集積回路（IC）、(ii)データ及び／または命令を保存するためのメモリICを含み得る１または複数のICの組、(iii)例えば移動局モデム(MSM)などのASIC、(iv)他の機器内部に組み込まれ得るモジュール、(v)携帯電話機、無線機器、ハンドセット、またはモバイルユニット、(vi)その他であってよい。

本開示における前の説明は、技術分野における任意の当業者に本開示をなしまたは使用することを可能とするために提供される。本開示に対する様々な変更は、技術分野における当業者にとって容易に明らかとなるであろうし、本願明細書において明らかにされる包括的な原則は本開示の精神及び範囲から離れることなくその他の変形例に適用されるかもしれない。従って、本開示は、本願明細書において記述される実施例または設計に限定されることを意図されておらず、本願明細書において開示される原則及び新規な特徴に調和する最も広い範囲に一致する。

Claims (52)

1. 基地局と無線通信可能な機器において、
   最大の処理容量を備え、前記機器上で作動中のアプリケーションを実行する処理ユニットと、
   前記アプリケーションによる処理要求を監視し、前記処理要求及び前記最大の処理容量に基づいて少なくとも１つのアプリケーションを制御するコントローラと
   を具備する機器。
2. 前記コントローラは、前記アプリケーションの優先度に基づいて、前記機器上で作動中のアプリケーションの中から制御のための前記少なくとも１つのアプリケーションを選択する請求項１記載の機器。
3. 前記コントローラは、低い優先度のアプリケーションを最初に制御し、前記低い優先度のアプリケーションが十分に制御された後に高い優先度のアプリケーションを制御する請求項２記載の機器。
4. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
   前記コントローラは、高い処理要求が検出されるときに前記データアプリケーションによって前記基地局と交換されるデータ量を削減し、低い処理要求が検出されるときに前記データアプリケーションによって前記基地局と交換されるデータ量を増加させる
   請求項１記載の機器。
5. 前記処理要求が高閾値を超えるときに高い処理要求が検出され、前記処理要求が低閾値より下に落ちるときに低い処理要求が検出される請求項４記載の機器。
6. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
   前記コントローラは、前記処理要求及び前記最大の処理容量に基づいて、前記データアプリケーションに関するウィンドウサイズを調整し、
   前記ウィンドウサイズは前記データアプリケーションによって交換される確認されていないパケットの数を規制する
   請求項１記載の機器。
7. 前記コントローラは、最大値及び最小値の間で前記ウィンドウサイズを調整し、
   前記最小値は、伝送制御プロトコル（ＴＣＰ）によるタイムアウトを回避するために選択されている
   請求項６記載の機器。
8. 前記コントローラは、高い処理要求が検出されるときに前記ウィンドウサイズを縮小する請求項６記載の機器。
9. 前記コントローラは、高い処理要求が検出されるときに前記ウィンドウサイズを最大値から最小値に縮小する請求項６記載の機器。
10. 前記コントローラは、高い処理要求が検出され前記データアプリケーションが未だ制御されていないときに前記ウィンドウサイズを最大値から最小値に縮小し、高い処理要求が検出され前記データアプリケーションが制御されているときに前記ウィンドウサイズを歩調を整えて縮小する請求項６記載の機器。
11. 前記コントローラは、低い処理要求が検出されるときに前記ウィンドウサイズを、最大値に至るまで、歩調を整えて拡大する請求項６記載の機器。
12. 前記コントローラは、低い処理要求が検出されるときに前記ウィンドウサイズを、最大値に至るまで、各更新間隔においてアップステップだけ拡大する請求項６記載の機器。
13. 前記コントローラは、中間の処理要求が検出されるときに前記ウィンドウサイズを維持する請求項６記載の機器。
14. 前記コントローラは、前記基地局に前記ウィンドウサイズを送る請求項６記載の機器。
15. 前記コントローラは、信頼性向上のために前記基地局に前記ウィンドウサイズを複数回送る請求項６記載の機器。
16. 前記コントローラは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）のための無線リンクプロトコル（ＲＬＣ）によって送られる確認されていないプロトコルデータユニット（ＰＤＵ）の数を規制するウィンドウサイズを高い処理要求が検出されるときに縮小し、前記ウィンドウサイズを前記基地局に送る請求項１記載の機器。
17. 前記コントローラは、前記基地局について前記機器において測定されるチャネル品質に基づいてチャネル品質表示（ＣＱＩ）を取得し、高い処理要求が検出されるときに前記ＣＱＩを低減させ、前記基地局に低減されたＣＱＩを送る請求項１記載の機器。
18. 前記コントローラは、高い処理要求が検出されるときに、前記基地局から受信されるパケットが正しく復号化されているとしても、前記パケットの所定割合に関してネガティブアクナリッジメント（ＮＡＫ）を送る請求項１７記載の機器。
19. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記コントローラは前記処理要求に基づいて前記データアプリケーションのための伝送ブロックサイズに作用する
    請求項１記載の機器。
20. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記コントローラは前記処理要求に基づいて前記データアプリケーションに関してのバッファステータスレポートを生成し、前記バッファステータスレポートを前記基地局に送る
    請求項１記載の機器。
21. 無線機器上で作動中のアプリケーションによる、最大の処理容量を備えた処理ユニットに関する処理要求を監視することと、
    前記処理要求及び前記最大の処理容量に基づいて少なくとも１つのアプリケーションを制御することと
    を具備する方法。
22. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記少なくとも１つのアプリケーションを制御することは、
    高い処理要求が検出されるときに、前記データアプリケーションによって基地局と交換されるデータ量を削減することと、
    低い処理要求が検出されるときに、前記データアプリケーションによって前記基地局と交換されるデータ量を増加させることと
    を具備する
    請求項２１記載の方法。
23. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記少なくとも１つのアプリケーションを制御することは、前記処理要求及び前記最大の処理容量に基づいて前記データアプリケーションに関してのウィンドウサイズを調整することを具備し、
    前記ウィンドウサイズは前記データアプリケーションによって交換される確認されていないパケットの数を規制する
    請求項２１記載の方法。
24. 前記データアプリケーションに関しての前記ウィンドウサイズを調整することは、
    高い処理要求が検出されるときに前記ウィンドウサイズを縮小することと、
    低い処理要求が検出されるときに前記ウィンドウサイズを拡大することと
    を具備する請求項２３記載の方法。
25. 無線機器上で作動中のアプリケーションによる、最大の処理容量を備えた処理ユニットに関する処理要求を監視するための手段と、
    前記処理要求及び前記最大の処理容量に基づいて少なくとも１つのアプリケーションを制御するための手段と
    を具備する装置。
26. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記少なくとも１つのアプリケーションを制御するための手段は、
    高い処理要求が検出されるときに、前記データアプリケーションによって基地局と交換されるデータ量を削減するための手段と、
    低い処理要求が検出されるときに、前記データアプリケーションによって前記基地局と交換されるデータ量を増加させるための手段と
    を具備する
    請求項２５記載の装置。
27. 前記少なくとも１つのアプリケーションはデータアプリケーションを包含し、
    前記少なくとも１つのアプリケーションを制御するための手段は、前記処理要求及び前記最大の処理容量に基づいて前記データアプリケーションに関するウィンドウサイズを調整するための手段を具備し、
    前記ウィンドウサイズは前記データアプリケーションによって交換される確認されていないパケットの数を規制する
    請求項２５記載の装置。
28. 無線機器上で作動中のアプリケーションによる、最大の処理容量を備えた処理ユニットに関する処理要求を監視し、
    前記処理要求及び前記最大の処理容量に基づいて少なくとも１つのアプリケーションを制御する
    ための命令を保存するためのプロセッサ読み取り可能な媒体。
29. 高い処理要求が検出されるときに、制御されている前記少なくとも１つのアプリケーションの１つであるデータアプリケーションによって基地局と交換されるデータ量を削減し、
    低い処理要求が検出されるときに、前記データアプリケーションによって前記基地局と交換されるデータ量を増加させる
    ための命令を更に保存するための請求項２８記載のプロセッサ読み取り可能な媒体。
30. 制御されている前記少なくとも１つのアプリケーションの１つであるデータアプリケーションに関し前記データアプリケーションによって交換される確認されていないパケットの数を規制するウィンドウサイズを、前記処理要求及び最大の処理容量に基づいて調整するための命令を更に保存するための請求項２８記載のプロセッサ読み取り可能な媒体。
31. 無線機器と無線通信可能な装置において、
    処理要求及び前記無線機器における最大の処理容量に基づいて判断される情報を受信し、受信された情報に基づいて前記無線機器と交換するデータ量を制御するコントローラと、
    前記コントローラからの制御に基づいて前記無線機器とデータを交換するプロセッサと
    を具備する装置。
32. 前記情報は、確認されていないパケットの数を規制するウィンドウサイズを包含し、
    前記プロセッサは、前記ウィンドウサイズに従って前記無線機器にパケットを送る
    請求項３１記載の装置。
33. 前記情報は、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）のための無線リンクプロトコル（ＲＬＣ）によって送られる確認されていないプロトコルデータユニット（ＰＤＵ）の数を規制するウィンドウサイズを包含し、
    前記プロセッサは前記ウィンドウサイズに従って前記無線機器にＰＤＵを送る
    請求項３１記載の装置。
34. 前記情報は、チャネル品質表示（ＣＱＩ）を包含し、
    前記コントローラは、前記ＣＱＩに基づいて前記無線機器への伝送のためのデータレートを選択し、
    前記プロセッサは、選択されたデータレートに従って前記無線機器にパケットを送る
    請求項３１記載の装置。
35. 処理要求及び無線機器における最大の処理容量に基づいて判断される情報を受信することと、
    受信された情報に基づいて前記無線機器と交換するデータ量を制御することと
    を具備する方法。
36. 前記情報は、確認されていないパケットの数を規制するウィンドウサイズを包含し、
    前記無線機器と交換するデータ量は前記ウィンドウサイズに基づいて制御される
    請求項３５記載の方法。
37. 基地局と無線通信可能な機器において、
    前記機器上で作動中のアプリケーションに割り当て可能な処理リソースと、
    前記割り当て可能な処理リソースに関しての前記アプリケーションによる処理要求を監視し、前記処理要求に基づいて少なくとも１つのアプリケーションを制御するコントローラと
    を具備する機器。
38. 前記機器上で作動中のアプリケーションに割り当て可能なバスリソースを更に具備し、
    前記コントローラは、前記割り当て可能なバスリソースに関しての前記アプリケーションによるバス要求を監視し、前記バス要求に基づいて前記少なくとも１つのアプリケーションを制御する
    請求項３７記載の機器。
39. 前記機器上で作動中のアプリケーションに割り当て可能なメモリリソースを更に具備し、
    前記コントローラは、前記割り当て可能なメモリリソースに関しての前記アプリケーションによるメモリ要求を監視し、前記メモリ要求に基づいて前記少なくとも１つのアプリケーションを制御する
    請求項３７記載の機器。
40. 前記機器上で作動中のアプリケーションに割り当て可能なキャッシュリソースを更に具備し、
    前記コントローラは、前記割り当て可能なキャッシュリソースに関しての前記アプリケーションによるキャッシュ要求を監視し、前記キャッシュ要求に基づいて前記少なくとも１つのアプリケーションを制御する
    請求項３７記載の機器。
41. 前記コントローラは、前記機器上で作動中の各アプリケーションが制御可能であるか制御可能でないかを表示する情報を受信し、受信された情報に基づいて制御のための前記少なくとも１つのアプリケーションを選択する請求項３７記載の機器。
42. 前記コントローラは、前記機器上で作動中のアプリケーションの優先度を表示する情報を受信し、受信された情報に基づいて制御のための前記少なくとも１つのアプリケーションを選択する請求項３７記載の機器。
43. 無線機器における割り当て可能な処理リソースに関しての前記無線機器上で作動中のアプリケーションによる処理要求を監視することと、
    前記処理要求に基づいて少なくとも１つの前記アプリケーションを制御することと
    を具備する方法。
44. 前記無線機器における割り当て可能なバスリソースに関しての前記アプリケーションによる処理要求を監視することと、
    前記バス要求に基づいて前記少なくとも１つのアプリケーションを制御することと
    を更に具備する請求項４３記載の方法。
45. 基地局と無線通信可能な機器において、
    設定可能な処理容量を備え、前記機器上で作動中のアプリケーションを実行する処理ユニットと、
    前記アプリケーションによる処理要求を監視し、前記処理要求に基づいて前記処理ユニットの前記処理容量を調整するコントローラと
    を具備する機器。
46. 前記コントローラは、前記処理容量を調整するために前記処理ユニットのクロック周波数を変更する請求項４５記載の機器。
47. 前記コントローラは、前記処理要求が高閾値を超えるときに前記処理ユニットに関してより高いクロック周波数を選択し、前記処理要求が低閾値の下に落ちるときに前記処理ユニットに関してより低いクロック周波数を選択する請求項４５記載の機器。
48. 設定可能なバス容量を備えるバスを更に具備し、
    前記コントローラは前記アプリケーションによるバス要求を監視し、前記バス要求に基づいて前記バス容量を調整する
    請求項４５記載の機器。
49. 前記コントローラは、前記バス容量を調整するために前記バスのクロック周波数を変更する請求項４８記載の機器。
50. 設定可能な処理要求を備えた処理ユニットによって無線機器上で作動中のアプリケーションを実行することと、
    前記アプリケーションによる処理要求を監視することと、
    前記処理要求に基づいて前記処理ユニットの前記処理容量を調整することと
    を具備する方法。
51. 前記処理ユニットの前記処理容量を調整することは、
    前記処理要求が高閾値を超えるときに前記処理ユニットに関してより高いクロック周波数を選択することと、
    前記処理要求が低閾値の下に落ちるときに前記処理ユニットに関してより低いクロック周波数を選択することと
    を具備する請求項５０記載の方法。
52. 設定可能なバス容量を備えるバスに関しての前記アプリケーションによるバス要求を監視することと、
    前記バス要求に基づいて前記バス容量を調整することと
    を更に具備する請求項５０記載の方法。

Images