JP2017521905A - 送信機における電力節約および性能バランシングのための方法および機構 - Google Patents

Abstract

ブルートゥースプロトコルを使用する例は、ハンドシェイク衝突およびクレジット処理の確率を低減するための動的なＭＴＵ調整を含み得る。これはまた、Ｔｘ ＭＴＵを遠隔Ｒｘクレジットの数の非倍数にすることと、Ｔｘ ＭＴＵを、クレジットの前後に重複なしにＣＯＮＴＩＮＵＥが来るような値に調整することと、アンダーフロー状態を防ぐこととを含み得る。別の例は、たとえアンダーフロー状態の間でも優先度の低いトラフィックを定期的にペーシングして、それによって速度のバランスを取ることを含み得る。別の例は、周波数速度のバランスを取り得、それによって望ましくない待機状態の間にプロセッサ負荷を制御することによって電力のバランスを取り、優先度の低いトラフィック条件に対して起こり得る望ましくないマルチプロセッサ周波数ジャンプ決定を間接的に制御する。

Description

関連出願の相互参照
[0001]本特許出願は、本明細書の譲受人に譲渡され、参照によりその全体が本明細書に明確に組み込まれる２０１４年５月２７日に出願された「ＭＥＴＨＯＤＳ ＡＮＤ ＭＥＣＨＡＮＩＳＭＳ ＦＯＲ ＰＯＷＥＲ ＳＡＶＩＮＧ ＡＮＤ ＰＥＲＦＲＯＭＡＮＣＥ ＢＡＬＡＮＣＩＮＧ ＩＮ Ａ ＴＲＡＮＳＭＩＴＴＥＲ」と題する、米国仮出願第６２／００３，２４９号の利益を主張する。

[0002]本開示は、一般に、２つのデバイス間の性能改善に関し、より詳細には、排他的ではないが、送信機と受信機との間の電力節約および性能バランシングに関する。

[0003]従来、デバイス間通信であるワイヤードまたはワイヤレスの任意の通信プロトコル（たとえば、ブルートゥース（登録商標）プロトコル）では、受信デバイスが低バッファを有する場合、および／または送信デバイスが、長時間のデータ送信中にプロトコルフロー制御制限（低速遠隔デバイスのために流入する）に起因する処理遅延を経験している場合、（本質的には、後で説明するプラットフォーム設計制約下で、所与の時間内に倍増する可能性がある）高い消費電力がある。要するに、遠隔側でより低いＲｘバッファを使用するデバイス間データ転送、またはローカル側での処理遅延は、送信側で高い電力消費を引き起こす。システム全体がより高い電力漏れ状態で、および優先度の低い抑制されたトラフィック条件のために待機することは良くない。

[0004]したがって、本明細書で提供される改善された方法および装置を含む従来の方法を改善する方法への長年にわたる産業ニーズがある。

[0005]本教示に特有のものである発明の特徴は、さらなる特徴および利点とともに、詳細な説明および添付の図面からよりよく理解される。図の各々は、例示および記述のみを目的に提供されるものであり、本教示を制限するものではない。

[0006]以下は、本明細書で開示される装置および方法に関連付けられる１つまたは複数の態様および／または例に関する簡略化された概要を提示する。したがって、以下の概要は、すべての企図される態様および／または例に関連する広範な概要と見なされるべきではなく、また、以下の要約は、すべての企図される態様および／または例に関連する主要または重要な要素を特定するための、または任意の特定の態様および／または例に関連付けられる範囲を描くものと見なされるべきではない。したがって、以下の概要は、本明細書で開示される装置および方法に関連する１つまたは複数の態様および／あるいは例に関連する特定の概念を、以下に提示される詳細な説明に先立って簡略化した形で提示するための唯一の目的を有する。

[0007]本開示のいくつかの例は、低速であり、抑制され、または制限されたＲｘバッファ遠隔受信機に対する高性能送信機の動的な電力節約および性能バランシングのためのシステム、装置、および方法を対象とする。

[0008]本開示のいくつかの例では、システム、装置、および方法は、特にブルートゥースデータ転送リンクなどの例で、電力節約（半減以上など（たとえば、本発明の場合、３００＋ｍＡから１５０ｍＡに節約される）（これは、抑制されたときにシステムが様々なスレッドをどのように見るかに依存する設計であり、たとえば、スレッドのいくつかは、フローが停止した状態で依然として不必要に消費する可能性がある）と、性能向上（適用可能な通信規格および仕様に違反していないが、それらのいくつかの改良を提案しているシーケンシングにおけるいくつかの変更のために、２００Ｋビット／秒を超えて増加した速度など）をもたらす。

[0009]本開示のいくつかの例では、システム、装置、および方法は、ａ）制御ＰＤＵが同時に来て、何らかの処理影響を与えないように、実行時にバッファを検出および調整することと、ｂ）特に遠隔が、アプリケーションレベルまでより速い送信デバイスの速度にマッチさせることができず、ＣＰＵ利用（消費電力）が特定のシナリオの制御下にあるようにアプリケーションデータをペースアップまたはダウンさせるために、Ｌｏｃａｌ ＴＸ ＦＵＬＬイベントのような待機ポイント上の停止を検出することと、ｃ）たとえ（ハードウェアコントローラの）アンダーフロー状態であっても制限されたデータの制御された送信によって良好な速度と電力消費とのバランスを取り、それによって低速遠隔からの遅いフロー制御を予期することとを含む。これらのステップはさらに、そのような遅れを予期することを可能にし、次いで、たとえ送信条件が良好でなくても速度を調整する。低速遠隔からのフロー遅延のバランシングと予期は、速度と性能のバランスを取るために良い位置に速い送信機を置くことができる。これは、プロトコル転送（ワイヤードまたはワイヤレス）の様々な速度を有する他の多くの技術、特により多くの電力を消費するモジュールに適用され得、これは実に良好な電力節約形態を生成する。

[0010]本開示のいくつかの例では、システム、装置、および方法は、断続的な間隔でトラフィックのアンダーフローにつながる条件と、アンダーフローが停止してフローが開始するときに突発的なトラフィックの発生を含む。

[0011]本開示のいくつかの例では、システム、装置、および方法は、高性能デバイス、または高性能モードのデバイスのためのシステム電力（バッテリなど）を動的に低減することを含む。

[0012]本開示のいくつかの例では、システム、装置、および方法は、未使用のＡＩＲチャネル（誘導されたアンダーフロー中など）を利用することによって、高速化することと、高速および高電力条件でトランザクションを終了することとを含む。

[0013]本開示のいくつかの例では、システム、装置、および方法は、一定の低速および低電力の安定したトラフィックの代わりにオオツメクサトラフィックを引き起こすプロセスのプロセス間フローおよびデバイス間フロー制御を含む。

[0014]本開示のいくつかの例では、システム、装置、および方法は、データパケットを生成するためのデータアプリケーションモジュールと、データパケットを送信フローレートで遠隔デバイスに送信するためのプロトコルスタックコンポーネントと、プロトコルスタックがデータアプリケーションモジュールに通信可能に結合される、フロー制御メッセージを送信するためのＯＢＥＸコンポーネントと、ＯＢＥＸコンポーネントが、フロー制御メッセージをデータアプリケーションモジュールおよびプロトコルスタックコンポーネントに送信するために、データアプリケーションモジュールおよびプロトコルスタックコンポーネントに通信可能に結合される、データアプリケーションモジュール、プロトコルスタックコンポーネント、およびＯＢＥＸコンポーネントのプロセスフローを制御するためのプロセッサと、プロセッサのプロセッサ速度を制御するためのガバナとを有するモバイルデバイスを含み、ここにおいて、ＯＢＥＸコンポーネントは、遠隔デバイスから受信した遠隔送信クレジットの基づく数に、生成されたデータパケットのサイズを制御するために、データサイズフロー制御メッセージをデータアプリケーションモジュールに送信する。

[0015]本開示のいくつかの例では、システム、装置、および方法は、データパケットを受信機に送信するための送信機と、送信機と通信するデータ送信ガバナと、データ送信ガバナが送信機の送信速度を制御するように構成される、送信機と通信するデータフローコンポーネントと、データフローコンポーネントが、生成されたデータパケットを送信のために送信機に送信および通信するためのデータパケットを生成するように構成される、を有する送信機を含む。

[0016]本開示のいくつかの例では、システム、装置、および方法は、ローカルデバイスと遠隔デバイスとの間の通信の方法を含み、本方法は、コントローラのアンダーフロー状態に基づいてローカルデバイスのマイクロプロセッサ周波数ジャンプ決定コンポーネントを制御することと、ローカルデバイスの送信機が遠隔デバイスからのハンドシェイクメッセージを待っているときにローカルデバイスのプロセッサ負荷を制御することと、実行時にコントローラのアンダーフロー状態を検出することと、ハンドシェイクの衝突およびクレジット処理の確率を低減するためにローカルデバイスの最大送信ユニットを調整することとを含む。

[0017]本開示のいくつかの例では、システム、装置、および方法は、ローカルデバイスと遠隔デバイスとの間の通信を制御することを行うためのプログラムコードを有するコンピュータ可読記憶媒体を有する製造物品を含み、本プログラムコードは、プロセッサによって実行されると、プロセッサに、コントローラのアンダーフロー状態に基づいてローカルデバイスのマイクロプロセッサ周波数ジャンプ決定コンポーネントを制御することと、ローカルデバイスの送信機が遠隔デバイスからのハンドシェイクメッセージを待っているときにローカルデバイスのプロセッサ負荷を制御することと、実行時にコントローラのアンダーフロー状態を検出することと、ハンドシェイクの衝突およびクレジット処理の確率を低減するためにローカルデバイスの最大送信ユニットを調整することとを備える動作を実行させる命令を備える。

[0018]本明細書で開示される装置および方法に関連付けられる他の特徴および利点は、添付の図面および詳細な説明に基づいて当業者には明らかであろう。

[0019]添付の図面は、本発明の教示の例を説明するために提示されており、限定するものではない。添付の図面は、本開示の実施例の説明を補助するために提示され、また実施例の説明のためのみに提供され、本発明の限定ではない。

[0020]本開示の態様およびそれに付随する利点の多くのより完全な理解は、単に説明のために提示され、本開示の限定ではない、添付の図面に関連して考慮される場合、以下の詳細な説明を参照することによってそれらがよりよく理解されるにつれて、より容易に得られる。

[0021]本開示のいくつかの例による、例示的なプロセッサを示す図。 [0022]本開示のいくつかの例による、例示的なユーザ機器（ＵＥ）を示す図。 [0023]ブルートゥースプロトコルを使用する例示的なロングファイル転送を示す図。 [0024]ＲＦＣＯＭＭを介する例示的なブルートゥース転送を示す図。 [0025]ボトルネックを強調する例示的なシーケンスを示す図。 [0026]例示的なＰｕｔ（最終）、Ｃｏｎｔｉｎｕｅ、およびＲＦＣＯＭＭクレジットを示す図。 [0027]例示的なＣｏｎｔｉｎｕｅおよびＲＦＣＯＭＭクレジットを示す図。 [0028]例示的なＯＢＥＸならびにＲＦＣＯＭＭ ＴｘおよびＲｘを示す図。 [0029]ＣＸレール（接続性ＢＴライン電流）上の例示的な電流を示す図。 [0030]ＣＸレール（接続性ＢＴライン電流）上の例示的な電圧を示す図。 [0031]ハンドシェイク信号の並列処理を回避するような例示的なＭＴＵ調整を示す図。 [0032]例示的なローカルＭＴＵ調整を示す図。 [0033]本開示のいくつかの例による、例示的なシーケンスの例（パイロット例として行われるブルートゥースフロー制御）を示す図。

[0034]一般的な慣習に従って、図面によって示された特徴は、縮尺に合わせて描かれていない場合がある。したがって、示された特徴の寸法は、明瞭さのために任意に拡張または縮小され得る。一般的な慣習に従って、図面の一部は明瞭さのために簡素化されている。したがって、図面は、特定の装置または方法のすべてのコンポーネントを示しているとは限らない場合がある。さらに、同様の参照番号は、明細書および図の全体にわたって同様の特徴を示している。

[0035]送信機と受信機との間の電力節約および性能バランシングのための方法、装置、およびシステムが提供される。本明細書に開示された例示的な方法、装置、およびシステムは、長年にわたる産業ニーズならびに他の以前には識別されていないニーズに有利に対処し、従来の方法、装置、およびシステムの欠点を緩和する。たとえば、本明細書に開示された方法、装置、およびシステムによって提供される利点は、デバイス間送信の電力対性能要求の改善である。

[0036]本開示に関連する特定の例を示すために、以下の説明および関連する図面において様々な態様が開示される。代替実施例は、本開示を読めば当業者には明らかであり、本開示の範囲または趣旨から逸脱することなしに構築および実施され得る。さらに、よく知られている要素は、本明細書に開示された態様および実施例の関連する詳細を不明瞭にしないために詳細に説明されず、または省略されてもよい。

[0037]「例示的（ｅｘｅｍｐｌａｒｙ）」という用語は、本明細書では、「例、事例、または例示としての役割を果たす（ｓｅｒｖｉｎｇ ａｓ ａｎ ｅｘｍｐｌｅ，ｉｎｓｔａｎｃｅ，ｏｒ ｉｌｌｕｓｔｒａｔｉｏｎ）」ことを意味するために使用される。本明細書において「例示的」と記載されているあらゆる詳細は、必ずしも他の実施例よりも好ましいまたは有利であると解釈されるべきではない。同様に、「例（ｅｘａｍｐｌｅｓ）」という用語は、すべての例が論議された特徴、利点、または動作モードを含むことを必要としない。「一例では（ｉｎ ｏｎｅ ｅｘａｍｐｌｅ）」、「例（ａｎ ｅｘａｍｐｌｅ）」、「１つの特徴では（ｉｎ ｏｎｅ ｆｅａｔｕｒｅ）」、および／または「特徴（ａ ｆｅａｔｕｒｅ）」という用語の使用は、本明細書では、必ずしも同じ特徴および／または例を指しているとは限らない。さらに、特定の特徴および／または構造は、１つまたは複数の他の特徴および／または構造と組み合わせられ得る。さらに、本明細書に記述された装置の少なくとも一部は、本明細書に記述された方法の少なくとも一部を実行するように構成され得る。

[0038]本明細書で使用される用語は、特定の実施例を説明するためのものにすぎず、本開示の実施例を限定することが意図されるものではない。本明細書で使用されるように、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈がそうでないことを明確に示さない限り、複数形も含むことが意図される。本明細書で使用する場合、「備える（ｃｏｍｐｒｉｓｅｓ）」、「備えている（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、および／または「含んでいる（ｉｎｃｌｕｄｉｎｇ）」という用語は、記載された特徴、整数、ステップ、動作、要素、および／または構成要素の存在を特定するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、および／またはそれらのグループの存在または追加を排除するものではないことがさらに理解されよう。

[0039]「接続された（ｃｏｎｎｅｃｔｅｄ）」、「結合された（ｃｏｕｐｌｅｄ）」、またはその変形の用語は、要素間における、直接的または間接的のいずれかの任意の接続または結合を意味するものであり、中間要素を介して「接続された」または「結合された」２つの要素の間において中間要素の存在を包含する場合があることに注意するべきである。要素間の結合および／または接続は、物理的、論理的、またはそれらの組合せの場合がある。本明細書で用いる場合、要素は、たとえば、１つまたは複数のワイヤ、ケーブル、および／または印刷された電気接続を使用することによってだけでなく、電磁エネルギーを使用することによって「接続される」または「結合される」ことができる。電磁エネルギーは、無線周波数領域の波長、マイクロ波領域、および／またはオプティカル（可視と非可視の両方）領域を持つことができる。これらは、複数の限定を目的としない、非網羅的な例である。

[0040]「信号（ｓｉｇｎａｌ）」という用語は、データ信号、オーディオ信号、ビデオ信号、マルチメディア信号、アナログ信号、および／またはデジタル信号など任意の信号を含むことができることを理解するべきである。情報および信号は、様々な異なる技術および手法のいずれかを使用して表され得る。たとえば、本明細書に記載するデータ、命令、処理ステップ、コマンド、情報、信号、ビット、および／またはシンボルは、電圧、電流、電磁波、磁場および／または磁粒子、光学場および／または光粒子、ならびにそれらの任意の組合せによって表され得る。

[0041]本明細書において「第１の（ｆｉｒｓｔ）」、「第２の（ｓｅｃｏｎｄ）」などの指示を使用する要素を言及する場合、それらの要素の数および／または順序を制限するものではない。むしろ、これらの指示は、２つ以上の要素および／または要素のインスタンスを区別する便利な方法として使用される。したがって、第１の要素および第２の要素という言及は、２つの要素だけが用いられ得ること、または第１の要素は、必ず第２の要素に先行しなければならないことを意味するものではない。また、そうでないことが明記されていない限り、要素の組は、１つまたは複数の要素を備えることができる。さらに、本明細書または特許請求の範囲で使用される「Ａ、Ｂ、またはＣの少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ： Ａ，Ｂ，ｏｒＣ）」という形式の用語は、「ＡまたはＢまたはＣ、あるいはこれらの要素の任意の組合せ（ＡｏｒＢｏｒＣｏｒ ａｎｙ ｃｏｍｂｉｎａｔｉｏｎ ｏｆ ｔｈｅｓｅ ｅｌｅｍｅｎｔｓ）」と解釈され得る。

[0042]さらに、多くの例が、たとえばコンピューティングデバイスの要素によって実行されるべき一連の動作に関して記述されている。本明細書に記載される様々な動作は、特定の回路（たとえば、特定用途向け集積回路（ＡＳＩＣ））によって、１つまたは複数のプロセッサによって実行されるプログラム命令によって、あるいはその両方の組合せによって実行され得ることが認識されるであろう。さらに、本明細書に記載されるこれらの一連の動作は、実行時に関連するプロセッサに本明細書に記載の機能性を実行させるコンピュータ命令の対応するセットを記憶したコンピュータ可読記憶媒体の任意の形態内に完全に具体化されていると考えられ得る。したがって、本開示の様々な態様は、多数の異なる形態で具体化され得、そのすべてが特許請求される主題の範囲内にあると考えられている。さらに、本明細書に記載される各例について、任意のそのような例の対応する形態は、たとえば、記載された動作を実行する「ように構成された論理（ｌｏｇｉｃ ｃｏｎｆｉｇｕｒｅｄ ｔｏ）」として本明細書に記載され得る。

[0043]本明細書では、特定の用語は、特定の特徴を記述するために使用される。「モバイルデバイス（ｍｏｂｉｌｅ ｄｅｖｉｃｅ）」という用語は、限定ではないが、モバイル電話、モバイル通信デバイス、ページャ、携帯情報端末、個人情報マネージャ、モバイルハンドヘルドコンピュータ、ラップトップコンピュータ、ワイヤレスデバイス、ワイヤレスモデム、および／または、典型的には人によって通常運ばれる、および／または通信機能（たとえば、ワイヤレス、セルラ、赤外線、近距離無線等）を有する他のタイプの携帯電子デバイスを記述し得る。さらに、「ユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）」（ＵＥ）、「モバイル端末（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｌ）」、「モバイルデバイス（ｍｏｂｉｌｅ ｄｅｖｉｃｅ）」、および「ワイヤレスデバイス（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）」という用語は、入れ替えて使うことができる。

[0044]図１は、ＡＳＩＣ２０８（以下参照）などの例示的なプロセッサ１０の機能ブロック図を示す。プロセッサ１０は、制御ロジック１４に従って命令実行パイプライン１２内の命令を実行する。制御ロジック１４は、プログラムカウンタ（ＰＣ）１５を維持し、たとえば現在の命令セット動作モード、算術演算結果および論理比較に関する情報（０、繰上げ、等しい、等しくない）などを示すために、１つまたは複数のステータスレジスタ１６内のビットを設定および消去する。いくつかの例では、パイプライン１２は、複数の並列パイプラインを有するスーパースカラー設計であり得る。パイプライン１２はまた、実行ユニットと呼ばれ得る。汎用レジスタ（ＧＰＲ）ファイル２０は、パイプライン１２によってアクセス可能であり、メモリ階層の最上部を備える汎用レジスタ２４のリストを提供する。

[0045]異なる命令セット動作モードで少なくとも２つの命令セットからの命令を実行するプロセッサ１０は、各命令の実行時に、少なくともあらかじめ定められた目標命令セット動作モードを現在の命令セット動作モードと比較し、２つの間の一致の表示を提供するように動作するデバッグ回路１８をさらに含む。

[0046]パイプライン１２は、命令キャッシュ（Ｉ−キャッシュ）２６から命令をフェッチし、命令側変換索引バッファ（ＩＴＬＢ）２８によって管理されるメモリアドレス変換および許可を有する。データは、メイン変換索引バッファ（ＴＬＢ）３２によって管理されるメモリアドス変換および許可を用いてデータキャッシュ（Ｄ−キャッシュ）３０からアクセスされる。様々な実施形態において、ＩＴＬＢ２８は、ＴＬＢ３２の部分のコピーを備え得る。あるいは、ＩＴＬＢ２８とＴＬＢ３２は統合され得る。同様に、プロセッサ１０の様々な例において、Ｉ−キャッシュ２６およびＤ−キャッシュ３０は、統合されてもよく、一体化されてもよい。さらに、Ｉ−キャッシュ２６およびＤ−キャッシュ３０は、Ｌ１キャッシュであり得る。Ｉ−キャッシュ２６および／またはＤ−キャッシュ３０におけるミスは、メモリインターフェース３４によるメイン（オフチップ）メモリ３８、４０へのアクセスを生じさせる。メモリインターフェース３４は、本開示のいくつかの実施例による改善されたデータ復元を組み込み得る１つまたは複数のメモリデバイス３８、４０への共有バスを実装するバス相互接続４２へのマスタ入力であり得る。追加のマスタデバイス（図示せず）は、バス相互接続４２にさらに接続し得る。

[0047]プロセッサ１０は、入力／出力（Ｉ／Ｏ）インターフェース４４がバス４６を介して様々な周辺デバイス４８、５０にアクセスし得る、周辺バス上のマスタデバイスであり得るＩ／Ｏインターフェース４４を含み得る。当業者は、プロセッサ１０の多数の変形が可能であることを認識するであろう。たとえば、プロセッサ１０は、Ｉ−キャッシュ２６およびＤ−キャッシュ３０のいずれかまたは両方に対する第２レベル（Ｌ２）キャッシュを含み得る。さらに、プロセッサ１０に示された機能ブロックのうちの１つまたは複数は、特定の例から省略され得る。ＪＴＡＧコントローラ、命令プリデコーダ、分岐宛先アドレスキャッシュなどの、プロセッサ１０内に存在し得る他の機能ブロックは、本開示の記述に密接な関係がなく、明瞭さのために省略されている。

[0048]図２を参照すると、コアネットワーク、インターネット、ならびに／または他の遠隔サーバおよびネットワークから最終的に得られる無線アクセスネットワーク（ＲＡＮ）から送信されたソフトウェアアプリケーション、データ、および／またはコマンドを受信して実行することができるプラットフォーム２０２を有するセルラ電話などのＵＥ２００（ここでは、ワイヤレスデバイス）を含むシステム１００。プラットフォーム２０２は、特定用途向け集積回路（「ＡＳＩＣ」２０８）、または他のプロセッサ、マイクロプロセッサ、論理回路、あるいは他のデータ処理デバイスに動作可能に結合されたトランシーバ２０６を含み得る。ＡＳＩＣ２０８または他のプロセッサは、ワイヤレスデバイスのメモリ２１２内の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェイス（「ＡＰＩ」）２１０層を実行する。メモリ２１２は、読出し専用またはランダムアクセスメモリ（ＲＡＭおよびＲＯＭ）、ＥＥＰＲＯＭ（登録商標）、フラッシュカード、あるいはコンピュータプラットフォームに共通の任意のメモリで構成され得る。プラットフォーム２０２はまた、メモリ２１２において積極的に使用されないアプリケーションを保持することができるローカルデータベース２１４を含み得る。ローカルデータベース２１４は、典型的にはフラッシュメモリセルであるが、磁気媒体、ＥＥＰＲＯＭ、光媒体、テープ、ソフトまたはハードディスクなどの当技術分野で知られている任意の二次ストレージデバイスであり得る。内部プラットフォーム２０２の構成要素はまた、当技術分野で知られているように、他の構成要素の中でも特に、アンテナ２２２、ディスプレイ２２４、プッシュツートークボタン２２８、およびキーパッド２２６などの外部デバイスに動作可能に結合され得る。

[0049]したがって、本開示の例は、本明細書に記載の機能を実行する能力を含むＵＥを含み得る。当業者には理解されるように、様々な論理要素は、本明細書に開示された機能を実現するために、ディスクリート要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアの任意の組合せで具体化され得る。たとえば、ＡＳＩＣ２０８、メモリ２１２、ＡＰＩ２１０、およびローカルデータベース２１４はすべて、本明細書に開示された様々な機能をロードし、記憶し、実行するために協調して使用され得、したがって、これらの機能を実行するためのロジックは様々な要素を介して分散され得る。あるいは、機能は１つの個別コンポーネントに組み込まれ得る。したがって、図２のＵＥ２００の特徴は単なる例示であると見なされるべきであり、本開示は例示された特徴または構成に限定されない。

[0050]ＵＥ２００とＲＡＮとの間のワイヤレス通信は、符号分割多元接続（ＣＤＭＡ），Ｗ−ＣＤＭＡ（登録商標）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多重（ＯＦＤＭ）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））、３ＧＰＰ（登録商標）ロングタームエボリューション（ＬＴＥ（登録商標））、またはワイヤレス通信ネットワークまたはデータ通信ネットワークで使用され得る他のプロトコルなどの異なる技術に基づき得る。

[0051]次に、本開示の例が、例としてブルートゥースロングファイル転送の文脈で説明される。本開示、および本明細書で開示された発明の概念は本質的に一般的であり、任意のワイヤレスまたはワイヤード技術に適用され得ることが理解されるべきである。本明細書に記載される概念は、特にプロトコルボトルネックのために生成されたＴｘアンダーフローによって電力と性能が低下する場合、特に遠隔装置が低速であり、多すぎる流量制御、抑制、性能サイクルの浪費および空中時間をもたらす状況において特に適している。この概念は上記の条件で適用され得、そのような状況では、優先度の低いトラフィック送信（低速のロングブルートゥースファイル転送など）で、システム電流が非常に大きくなる可能性がある。そのようなシナリオは、遠隔デバイスの受信速度は非常に遅いが送信機は非常に高速である、遠隔デバイスはより少ないＲｘバッファを有し、より多くのフロー制御ハンドシェイクを追加する、エアチャネルは良好ではなく、干渉／イントラプロトコルの共存の問題が発生した場合は特に、多すぎる再送／パケット損失をもたらす、ならびに遠隔が悪いＲｘを有するなど、いくつかの状況下での長時間の転送で見られ得る。

[0052]図３は、本開示の一例によるブルートゥースロングファイル送信を示す。図３において、ローカルデバイス３００は、ブルートゥースオープンソース実装を構成し得る様々な機能ブロックを含むが示される。以下に説明するブロック（モジュール、またはコンポーネント）に加えて、ローカルデバイス３００は、ブルートゥースインターフェース定義３５１、物理トランスポートドライバ（ＳＭＤ／ＵＡＲＴ／ＵＳＢ／ＳＤＩＯ等）３５２、ならびにＬＭＰ、ベースバンド、および無線層３５２を含み得る。他のブロック（モジュール、またはコンポーネント）は、以下を含む。

[0053]ブルートゥースアプリケーション３１０：ファイルシステムと会話し、デジタルデータを下位層に配信する。このコンポーネントは、ファイルシステムからデータを取得するという主な責任を有し得、次いで、合意されたパケットが完了すると、転送の進行状況をユーザに知らせる役割を担う。ブルートゥースアプリケーションはまた、ＯＢＥＸライブラリから受信したフロー制御をタップし、次いで、パケットの次のセットを最下層に提供し得る。

[0054]ＯＢＥＸライブラリ３２０：ＯＢＥＸライブラリ３２０は、ソケットインターフェース３３０を介して提供されるｒｆｃｏｍｍソケットから読み出され、ｒｆｃｏｍｍソケットに書き込まれるデータを扱うことができる。これは、必要なＯＢＥＸヘッダを追加してデータをＯＢＥＸ形式にパケット化し、遠隔端とネゴシエートされたＯＢＥＸのＭＴＵをフィッティングするためにＰＤＵをパケット化する役割を担う。このコンポーネントは、転送中にアプリケーション層とブルートゥースプロトコルスタックとの間のフロー制御機構を管理し得る。この層はまた、ＲＦＣＯＭＭベースの転送のためのフロー制御モードを有し得る点に留意されたい。それはＩＯ中に２つのパケットを使用する。１つは最終的なＰＵＴ ＰＤＵであり（これはフルファイルの点で最終的なものではないが、ＯＢＥＸ ＭＴＵを構成する長さのＰＤＵセット合計の最終的なものである）、もう１つは最後のＰＵＴの肯定応答としてのＣＯＮＴＩＮＵＥパケットである。一般に、最終的なプットパケットは、ＯＢＥＸ ＭＴＵサイズのバイトがＴｘ側から転送され、送信機がこの状態で受信機からＣＯＮＴＩＮＵＥを待機した後に送信される。進行中の最終的なプット中にＣＯＮＴＩＮＵＥが送信機に送信されない場合、送信機はその期間を「Ｏｂｅｘ Ｆｌｏｗ Ｓｔｏｐ」と見なし、たとえより多くのパケットが利用可能であり、ｒｆｃｏｍｍがパケットを送信するためのクレジットを有していても、ＯＢＥＸは次のパケット転送を開始し得ない。

[0055]スタックインターフェース３４０：２つのインターフェースが示されており、１つはブルートゥースの他のプロファイルのそれぞれに対応し、もう１つはブルートゥースプロトコルスタックを備えた標準ＳＯＣＫＥＴ ＩＰＣ ３３０に対応する。ブルートゥーススタックインタフェースは、アプリケーションとＲＦＣＯＭＭの間で生成される標準Ｓｏｃｋｅｔパイプを取得するのに役立つインターフェースであり得る。スタックインターフェース３４０はミドルウェアインターフェースのように機能し、いくつかの例は、システム電源が切断されていると、遠隔低速／フロー抑制の検出に基づいてインラインで最適化する。

[0056]次に、転送中のインターフェースについて説明する。

[0057]ブルートゥースプロトコルスタックコンポーネント３５０：このコンポーネントは、ＲＦＣＯＭＭおよびＬ２ＣＡＰの２つのコンポーネントを含み得る。ＲＦＣＯＭＭは、Ｉ／Ｏ中にフロー制御機構のソフトウェアハンドシェイクを有するソフトウェア仮想モデムと一般に呼ばれる仮想シリアルポート上のシリアルモデムのモデムエミュレーションであり得る。ＲＦＣＯＭＭはまた、ＣＢＦＣまたはクレジットベースのフロー制御モードと呼ばれる、転送中に広く使用される１つ複数の機構を有し得る。ＣＢＦＣは、受信機のクレジットが接続時に知られている場合は特に、転送中に合意されたソフトウェアフロー制御機構と見なされ得る。Ｔｘ側は、受信機の最大クレジットと、遠隔ｒｆｃｏｍｍ（＝最大クレジット＊ｐｏｒｔ ｍｔｕ）サイズの深さでのバッファがどのくらい深いかを記録しなければならない場合がある。いったん達成され、遠隔からクレジット更新が受信されなければ、それは「フローストップ」状態と見なされ、たとえＯＢＥＸソケット上に利用可能なパケットを有していてもＲＦＣＯＭＭを介してデータを転送することはできない。

[0058]ＣＰＵガバナ：ＣＰＵガバナの役割は、全体的な電力および性能駆動モードにあり得る。ＣＰＵガバナは、４つのコア０−３のそれぞれについて計算を行う機密モジュールであり、次いで、それに応じて実行中のアプリケーションの処理要求を満たすために周波数ジャンプおよびＣＰＵジャンプを実行するモジュールであり得る。ガバナは、通常、アイドル時間またはスリープ時間中にユーザ入力が遅れることがないようにするために、ＣＰＵまたはプラットフォームによって提供される待ち時間に関して良好なユーザ体験を維持するためにＣＰＵ速度を上げる。ガバナ（例示的な構成）は、次のルールで使用し得る。

[0059]− ＣＰＵ速度のより高いモード、たとえば、シングルコアでは１．２ＧＨｚにジャンプし、最小周波数（たとえば、３００ＭＨｚ）の９０％が所与の時間に達成される。

[0060]− 上述の９０％は、指定された例だけを含むのではなく、その所与の時間におけるシステム上の全体的なＣＰＵ使用量の合計を含むことができ、たとえば同様に３００ＭＨｚの９０％に近いものであり得る。

[0061]− ジャンプのベースラインは、たとえば３００ＭＨｚの９０％である。

[0062]− これが実行中のアプリケーションによって達成されると、最良のユーザ経験を提供するために電圧および電流がバッテリで非常に高いターボモードにバンピングが行われる。バンプはシステムによって行われるので、ユーザには低速は見えないが、消費電力に悪影響を与える。

[0063]− 特に待ち状態の下での優先度の低いトラフィックに対しては、ターボモードへのそのようなバンプは回避されるべきである。

[0064]− ターボへのそのようなバンプは、重要なユーザ特有のシナリオでのみ発生し、任意のプロトコル上の巨大なファイル転送の場合のようなバックグラウンドの優先度の低いトラフィックでは起こるべきではない。

[0065]ＣＰＵガバナ対ユーザデータフローの停止：前に説明したように、高電力状態とユーザデータフローとの関係は、進行中のデータフロー中のトラフィックの突然のアンダーフローおよび再開により直接的である。低速でバースト的な遠隔トラフィックの間の高電力の根本的な原因は、アンダーフローの直後のトラフィックを最小周波数（たとえば、３００ＭＨｚ）のベースラインの９０％＋として検出するガバナである可能性がある。

[0066]プロトコルフロー制御：ローカルデバイス４００と遠隔デバイス４１０との間の通信のための、異なる層におけるブルートゥースプロトコルフロー制御機構が、図４に示される。

[0067]フロー制御：動作の電力モードおよび性能モードに直接影響を与える２つのフロー制御が存在し得る。ＲＦＣＯＭＭクレジット４２０（交渉されたＲｘ ｍａｘクレジット）送信機は、クレジットが遠隔から利用可能でない限り、いかなるパケットも送信しない。相手側へのデータの送信を待つべきであるＯＢＥＸ上のＣＯＮＴＩＮＵＥ４３０パケット。

[0068]図５は、特に遠隔が継続パケットを遅らせると速度を低下させるボトルネックを強調する例示的なシーケンスを示す。図からわかるように、最後の剰余バイトブロック５１０のＯＢＥＸ ＦＩＮＡＬ ＰＡＣＫＥＴ ＷＩＴＨ ＰＵＴと、ＮＥＸＴ ＯＢＥＸ ＰＡＣＫＥＴ ＡＦＴＥＲ ＯＮＥ ＦＵＬＬ ＭＴＵブロック５２０との間の速度低下／アンダーフローを引き起こすＣＯＮＴＩＮＵＥ５００当たり５８〜１１０ミリ秒の待ち時間がある。また、この待ち時間は、遠隔がＣＯＮＴＩＮＵＥまたはＲＦＣＯＭ ＣＲＥＤＩＴＳのいずれかにおいて遅延するたびに発生する。待ち時間は、以下を引き起こす。ａ）たとえＲＦＣＯＭＭがいくつかのより多くのパケットを送信するために利用可能なクレジットを有していても、ＯＢＥＸからＲＦＣＯＭＭに送信されないデータ、ｂ）速度低下（待ち時間はＣＯＮＴＩＮＵＥごとに、またはそれぞれのＭＴＵ送信後に５８〜１１０ミリ秒の調整までなので）およびｃ）不均一なビット数／秒−アンダーフロー後のＣＰＵ速度の急激な増加につながる。

[0069]図６は、フロー制御オフおよびオンのための例示的なＰｕｔ６００（ＰＤＵ Ｌｏｔの最終、１つのＯＢＥＸ ＭＴＵサイズに等しい）、Ｃｏｎｔｉｎｕｅ、およびＲＦＣＯＭＭクレジットを示す図７は、例示的なＣｏｎｔｉｎｕｅ７００およびＲＦＣＯＭＭクレジット７１０を示す。

[0070]次に、フローオフ／トラフィック再開とバッテリ電力との関係について説明する。これは、例としてＭＰ Ｄｅｃｉｓｉｏｎ結合を備えたＣＰＵ速度ガバナソフトウェアコードであり得る。電力への結合は、低速遠隔によるデータ送信の不規則なレートの観点からのものであり得る。ＷＣＮＳＳは、低速遠隔デバイスによって抑制されているため、ホストからより少ないデータを取得し得る。サンプリングされた電源トレースは、ＷＣＮＳＳのＰＯＷＥＲ Ｒａｉｌｓが非常に頻繁な間隔でアンダーフローを見て、次いでトラフィックが開始されると突然トラフィックが発生することを示す。この発生は、突然のＣＰＵ負荷変動につながる可能性があり、したがってガバナはこの負荷に対応するためにより高い周波数を試行する。ＡＰＰＳの現在の値は、ＷＣＮＳＳ上のアンダーフローが終了した瞬間に上昇し得、トラフィックが再開する。これにより、抑制されたネットワークで大きな電流が流れる可能性がある。

[0071]特定のシナリオでは、可変データレートは問題を引き起こす可能性がある。しかしながら、受信するためのより高いバッファを有し、転送中に発生する抑制がより少ない遠隔デバイスでは、アプリケーションプロセッサの電力がステップに入って（go in steps）いないために主電源に問題が発生する可能性はほとんどなく、より少ない電力数につながる。遠隔は十分に速く、遠隔受信機のバッファがより高いためビットレートまたは速度にアップダウンがそれほど多く見られないので、ＣＰＵは一貫した方法で動作する。それにより、一定期間にわたる平均電流は少し低い。

[0072]次に、インジェクトフローオフが電力数に影響を及ぼす例示的なシナリオについて説明する。たとえば、遠隔がより低いＲｘバッファを有し、また定期的に抑制する場合、アンダーフロー中にアイドル状態のスレッドのＣＰＵ使用率が低下した場合は特に、アプリケーションプロセッサのＣＰＵ使用率におけるアップダウンが非常に高くなり得る。

[0073]図８は、ＯＢＥＸ８００、ならびにＲＦＣＯＭＭ Ｔｘ８１０およびＲｘ８２０の相互作用を示す。

[0074]本開示のいくつかの例が電力およびバランス性能をどのように節約するかを示す様々な例示的なシナリオを以下に説明する。シナリオ１ − 転送中に変更できない、低速で可変な遠隔側の受信機。上述のように、特に次の３つの条件のいずれかを満たしている場合は、フローが常にオンになるとは限らない。

[0075]− 受信用の遠隔バッファが少なく（たとえば、５〜６パケット未満など）、送信機が非常に高速である
[0076]− 遠隔デバイスが低速である
[0077]− または、チャンネルが非常に悪く、アプリケーションプロセッサがアイドル状態の場合はブルートゥースベースバンドレベルで再送信している
[0078]そのようなシナリオの下では、図９および図１０のレール図に見られるように、検出せずに大量の電流が消費される可能性がある。図９は、ＣＸレール上の電流を示す。図１０は、ＣＸレール上の電圧を示す。

[0079]悪い場合はＶＣＸが１．１８ボルト（ターボモード）になり、良い場合はほとんど常にＶＣＸが１．０５ボルトのままである。

[0080]別のシナリオでは、優先度の低いトラフィックは、可変レートフローのためにシステム電力をより高く移動させる。この場合、トラフィックの優先順位は非常に高くはなく、長時間の転送のみが例１．４Ｍｂｐｓを超える速度で実行され（これは単なる例であり、プラットフォームに大きく依存する）長時間の転送の間に低下するべきではない。

[0081]別のシナリオでは、ＣＰＵガバナ調整は変更され得ず、ＭＰ決定は無効にされ得ない（これは、他の機密使用シナリオに対するシステムの反応性に逆効果があるためである）。ガバナとＭＰ決定は、目標ごとにモデル化され得、特定のサンプリング値とＣＰＵあたりのゆるやかなタイミングを有するように微調整であり得る。

[0082]そのような微調整のために、オーディオやタッチ／ゲームなどの優先度の高いユースケースでは、ユーザーエクスペリエンスが損なわれることなしに優先度の低いトラフィックに対してアルゴリズムを変更することは困難である。たとえば、ＭＰ決定とＣＰＵガバナは、以下の機能を有するように調整されている。

[0083]− 中間の高周波数。

[0084]− インタラクティブガバナには、中間高速を最高速度以下に設定するオプションがある。高速負荷が越えられるとすぐに周波数がこの速度にジャンプする。設定可能な遅延時間がある。

[0085]− この遅延後の負荷評価に基づいて、ＣＰＵ周波数におけるステップジャンプが発生する前に、あらかじめ定めされた待機時間がある。

[0086]− ブルートゥースまたはタッチを介してオーディオを微調整すること、あるいは、性能を向上させるためにあまり頻繁にスイッチを切り替えない、時間の掛かる重要なシナリオ
[0087]− タッチスクリーンブースト：異なるベンダからのＩｎｐｕｔイベントパッチは、１つのソリューションに統合されているように見える。

[0088]− その他：デフォルトの最小サンプル時間が約数ミリ秒に変更され、その後、それのソフトウェアによって評価された負荷が所与のしきい値を下回った場合にも同様にステップを下げることができる
[0089]− そのようなもののモデル化された値は、一般にハードワイヤードであり、システム全体の側面に影響を及ぼす可能性があるため変更されない。したがって、前述のシナリオの速度を低下させるために、システムポリシーを変更するよりも、スピードをモデル化する必要がある。

[0090]次に、ハンドシェイク衝突の可能性を低減するためのＭＴＵ調整とクレジット処理について説明する。図示されるタイムラインは実際には１１０ミリ秒を超えており、これは単なるハンドシェイクでありデータではないため、データ速度の点では無駄な時間である。図１１に示されるように、これは問題のあるケースである。速度は少し高いが、実際の問題は、１１パケットごとに、遠隔からの継続パケットと遠隔からのＲＦＣＯＭ ＣＲＥＤＩＴＳがほぼ同時に来ているため、大きな待機時間があるということである。これは６パケットごとに、遠隔がクレジットを送信するためである。ＯＢＥＸ ＰＤＵ Ｓｉｄｅは６５５３４バイトであり、一般に、たとえば６５×９９０バイト（ＲＦＣＯＭＭ ＭＴＵ）＋残りの１パケットに分割される。したがって、６６パケットごとにＤＵＴから遠隔に１プット（put）が送られ、同時に、処理中の遠隔からＤＵＴに６クレジットを与える必要がある。処理が必要なＰｕｔが送信され、ＣＯＮＴＩＮＵＥも送信される。次に、１１分の１（＝６６／６）のクレジット更新、ＰＵＴ、ＣＯＮＴＩＮＵＥ、ＣＲＥＤＩＴＳが処理されているため、その間により多くのＳＯＣアンダーフローが発生する。

[0091]上記のシナリオでは、ローカルのＭＴＵ調整が解決策につながる可能性がある。遠隔のＲＦＣＯＭＭクレジットは低い（この例では６クレジットのように低い）と仮定すると、それは遠隔が受信する６パケットごとに送信機にクレジットを与え、次いでＴｘ側がさらなる転送を行い得ることを意味する。現在の状況を改善するには、次の２つの方法のいずれかによって、クレジットと継続バイが交互に行われ得る。

[0092]− Ｔｘ ＭＴＵを遠隔Ｒｘクレジットの数の非倍数にする（ＲＦＣＯＭＭ ＷＭ ＭＡＸ−ＭＩＮの遠隔側の差）
[0093]− Ｔｘ ＭＴＵを、クレジットの前後にＣＯＮＴＩＮＵＥを来させる（オーバーラップしない）ような値に調整する
[0094]第１の目標は、図１２に示されるようなふらつき（staggering）を有するためのものであり得る。このことは、実行時ＭＴＵ調整のための提案された手法では、時間空間を介してハンドシェイクをふらつきがないように（un-stagger）し、実行時にＰＤＵのセットごとに行われる調整によって図１１において報告された問題を克服することを示しており、１００ミリ秒以上を節約し、したがって多くの電力に影響を与えることなしに速度を上げ）、図１２に示されるように、１１回のクレジット更新ごとに５５ミリ秒以上の遅延の節約が達成され得る。

[0095]次にたとえ、アンダーフロー中であっても優先度の低いトラフィックを定期的にペーシングすることについて説明する。データ転送速度（ビット／秒）が一定ではないため、Ｔｘアクティビティの急激な低下が断続的にあり、ＣＰＵガバナがランダムに起動し、周波数と電圧を低下させようとする。しかしながら、実際の問題は、データが突然利用可能になり、ガバナがＣＰＵ負荷を評価しようとした後に起こる。ＣＰＵ使用率の急激な上昇があり得、ガバナがＣＰＵをより高い周波数にジャンプさせ、したがってより高い消費電力に戻る。これにより、システムは非常に優先度が高い、または高いトラフィック条件を有することなしに、ターボモードに移行することにつながり得る。

[0096]次に、最大周波数を制限し、ＭＰ決定を無効にすることについて説明する。システム上のマイクロプロセッサ周波数スイッチ決定を無効にし、１．２Ｇｈｚの最高速度に切り替えるのではなく、ＭＡＸ ＣＰＵ速度を例示的な６００Ｍｈｚに制限することによって、電源数が許容可能になり、範囲内になり得る。マイクロプロセッサ周波数スイッチ決定が停止され、最大周波数が例示的な６００ＭＨｚに制限されると、電流にスパイクや急激な増加はない。

[0097]本開示のいくつかの例は、低電力目標を達成すること、高い性能目標を達成すること、および優先度の低いトラフィックのバランシングの３つの構成要素によって上記の問題を解決する。

[0098]低電力目標：
[0099]− 上で説明したような、他の処理の衝突を招かないＯＢＥＸ ＭＴＵ（すべてのハンドシェイクとＰＤＵがほぼ同じ時間フレームに入る）を提供する。

[00100]− ガバナがデータ転送速度におけるあまりにも多くの変動に気付かないような方法で転送をペースアウト（pace out）する。この状態では、ガバナは一定の中速度を見ており、ランプを越えてジャンプすることはないので、最大電力節約があり得る。第２に、転送が遅すぎる場合には速度ペナルティがあり、フローオフの状況は無視される。

[00101]したがって、実行時のＭＴＵ調整は、時間の経過とともにいくつかのハンドシェイクをふらつかせるような方法で、すべてのスレッドを合理化するのに実に役立ち、また多くのアンダーフローが頻繁に発生することは可能にしない。

[00102]前述したような問題の根本的な原因は、各アンダーフロー状態の後に突然高いＣＰＵ使用率が見られるＣＰＵ周波数ガバナコードにある。

[00103]各アンダーフロー状態の後、ＣＸ電流において突然のスパイクがステップで発生する。これらのステップスパイクは、ＣＰＵガバナがＣＰＵの突然の使用を見ているが、ＣＰＵ使用率の％が徐々に上昇していることから見られる。電力数を減少させる本開示のいくつかの例は、速度がたとえば約１５％以上低下するという欠点を有し得る。

[00104]高性能目標：ＯＢＥＸ Ｔｘの速度はＵＮＤＥＲＦＬＯＷＳによって妨げられ、パケットはアンダーフローの回復の後に突然高速でポンピングされる。性能の向上は、遠隔継続遅延の間にいくつかのデータパケット（最大の遠隔クレジットの下で）がポンピングされる場合に発生し得る。前に説明したように、アンダーフローには２つの欠点があり、１つは送信速度のビット／秒を低下することであり、もう１つは低下している間にガバナを起動してＣＰＵ周波数をより低いレベルに下げようとすることである。しかしながら、ブルートゥースでは、特に単一のリンクが考慮されている場合、アンダーフローは長期間ではない。このアンダーフローは、長すぎるとＣＰＵ周波数を低下させ（約１００ミリ秒以上に及ぶ場合がある）が、その後トラフィックが開始されると、コアの周波数の急激な上昇が発生し、これは電力を節約するために回避され得る。

[00105]低電力目標は、ｒｆｃｏｍｍからのトラフィックのペースが、ＣＰＵガバナコードが次のフローオフに達するまでわずかな増加と見るような方法で制御されている場合に達成され得る。

[00106]次に、アンダーフローの状況、および低電力目標と結合し、電力と性能のトレードオフを有するためにシナリオをどのように活用するかについて説明する。継続遅延中にトラフィックを利用するには、アンダーフローは、速度を上げ、継続後にトラフィックをペースアウトするために使用され得、これにより、速度と消費電力のバランスが良好になる場合がある。

[00107]アンダーフロー領域は、システムがＣＯＮＴＩＮＵＥを待っているが、ｒｆｃｏｍｍクレジットが利用可能な場合に、依然として有効であり得る。そのような場合、アンダーフロー中の１つまたは２つのパケットを差し引いた合意クレジット（agreed credits）がプッシュされる。これは、アンダーフロー（速度増加）を利用することを可能にし得るだけでなく、アンダーフロー直後のパケットのペースアウトを可能にする。

[00108]図１３は、図３に示されるパケット化スキームの変更を有する開示のいくつかの例示的な例を示す。図からわかるように、最後の剰余バイトブロックのＯＢＥＸ ＦＩＮＡＬ ＰＡＣＫＥＴ ＷＩＴＨ ＰＵＴとＮＥＸＴ ＯＢＥＸ ＰＡＣＫＥＴ ＡＦＴＥＲ ＯＮＥ ＦＵＬＬ ＭＴＵブロックとの間の速度低下／アンダーフローを引き起こすＣＯＮＴＩＮＵＥ当たり５８〜１１０ミリ秒の待ち時間がある。また、この待ち時間は、遠隔がＣＯＮＴＩＮＵＥまたはＲＦＣＯＭ ＣＲＥＤＩＴＳのいずれかにおいて遅延するたびに発生する。待ち時間は、以下を引き起こす。ａ）たとえＲＦＣＯＭＭがいくつかのより多くのパケットを送信するために利用可能なクレジットを有していても、ＯＢＥＸからＲＦＣＯＭＭに送信されないデータ、ｂ）速度低下（待ち時間はＣＯＮＴＩＮＵＥごとに、またはそれぞれのＭＴＵ送信後に５８〜１１０ミリ秒の調整までなので）およびｃ）不均一なビット数／秒 − アンダーフロー後のＣＰＵ速度の急激な増加につながる。たとえば：
[00109]− ＯＢＥＸ ＭＴＵをある量だけ減少させる（約、最大受信機ＯＢＥＸ ＭＴＵ−５パケットの最大、２つのＲｘ−Ｃｒｅｄｉｔフレーム間で６パケットと仮定）
[00110]− アンダーフロー状態であっても６に達した場合にクレジット更新された場合、衝突事例にヒット（hit）しないように言及された５つのパケット
[00111]− これは、遠隔が低速であり、しばらくの間にハンドシェイクが戻ってくると予想しているという評価に基づく。

[00112]− 通常の方法で６０個のすべての奇数パケットを計画し、最終的なＰＵＴを通常の方法で送信する
[00113]− ｏｂｅｘレベルで継続を待たずに、アンダーフロー時の間にこれらの５つのパケットをｒｆｃｏｍｍキューに入れ、それによって、その間にＣＰＵガバナがマイクロプロセッサステップ変更決定をまだ行わないように転送レベルに置く。

[00114]− 遠隔からクレジットが受信されたときに、これらのパケットを無線で遠隔コントローラのバッファにポンピングできる。それにより、ＲＦＣＯＭＭクレジットとＣＯＮＴＩＮＵＥ待機時間の間の時間が節約される。

[00115]− ｒｆｃｏｍｍキューがクレジットを受信するとすぐに、これらが送信され、キューイングを開始するために継続を待つ必要がなくなり、それによってＣＰＵ周波数ジャンプを発生させずにＣＰＵの負荷が効果的に減少する。

[00116]− これは、アンダーフローが発生したときに、より多くのビット／秒を効果的に増加させ得る
[00117]− 速度に影響を与えるには、この変更が必要な場合がある
[00118]− 電力に影響を与えるためには、継続の前に待ち行列に入れられた余分なパケットの間の適切なバランスが実際に受信されることが必要な場合がある。

[00119]− したがって、ガバナがあまりにも頻繁に降下する（come down）ことはなく、その後、アンダーフローが終了した後に別のもう少しの数のパケットの間、ビット／秒を維持する必要がある
[00120]− これは、速度対電力の良好なトレードオフをもたらし得る。

[00121]本明細書に記載の方法、装置、およびシステムの例は、多くの用途に使用され得る。たとえば、記載した例は、複数のプロセッサにわたってデジタルトラフィックのバーストを生成するワイヤレスまたはワイヤードシステムで使用され得る。さらなる用途は、当業者には容易に明らかであるべきである。

[00122]本出願に記載または図示されているものはいずれも、コンポーネント、ステップ、機能、利点、または同等物が本書に記載されているかどうかにかかわらず、いかなるコンポーネント、ステップ、機能、利点、または同等物も一般に公開することが意図されるものではない。

[00123]当業者であれば、様々な異なる技術および技法のいずれかを使用して情報および信号が表され得ることができることを理解するであろう。たとえば、上記の説明を通して参照され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁粒子、光学場または光粒子、あるいはそれらの組合せによって表され得る。

[00124]さらに、当業者であれば、本明細書に開示された例に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得ることを理解するであろう。ハードウェアとソフトウェアとのこの互換性を明確に説明するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップを、それらの機能性の点で一般的に上述した。そのような機能性がハードウェアまたはソフトウェアとして実装されるかどうかは、システム全体に課される特定のアプリケーションおよび設計の制約に依存する。当業者は、特定のアプリケーションごとに様々な方法で説明した機能を実装することができるが、そのような実装の決定は本開示の範囲から逸脱させるものと解釈されるべきではない。

[00125]本明細書に開示された実施例に関連して説明された方法、シーケンスおよび／またはアルゴリズムは、ハードウェア、プロセッサによって実行されるソフトウェアモジュール、またはその２つの組合せに直接具体化され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当技術分野で知られている他の任意の形式の記憶媒体に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。あるいは、記憶媒体は、プロセッサに一体化され得る。

[00126]本明細書に開示された態様に関連して説明された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェアコンポーネント、あるいは本明細書に記載の機能を実行するように設計されたそれらの任意の組合せで実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替的に、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。また、プロセッサは、コンピューティングデバイスの組合せ（たとえば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成）として実現され得る。

[00127]いくつかの態様は、デバイスに関連して説明されているが、これらの態様はまた対応する方法の記述を構成することは言うまでもないので、デバイスのブロックまたは構成要素も、対応する方法ステップとして、または方法ステップの特徴として理解されるべきである。それに類似して、方法ステップに関連して、または方法ステップとして記載される態様はまた、対応するデバイスの対応するブロックまたは詳細または特徴の記述を構成する。方法ステップの一部または全部は、たとえば、マイクロプロセッサ、プログラマブルコンピュータまたは電子回路などのハードウェア装置によって（またはハードウェア装置を使用して）実行され得る。いくつかの例では、最も重要な方法ステップのいくつかまたは複数は、そのような装置によって実行され得る。

[00128]上述の例は、単に本開示の原理の説明を構成するにすぎない。言うまでもなく、本明細書に記載された構成および詳細の変更および変形は、当業者には明らかになるであろう。したがって、本開示は、本明細書の実施例の記述および説明に基づいて提示される特定の詳細ではなく、添付の特許請求の範囲の保護の範囲によってのみ制限されることが意図される。

[00129]上記の詳細な説明では、異なる特徴が実施例にまとめられていることがわかる。この開示の方法は、請求される例がそれぞれの請求項において明示的に言及されているよりも多くの特徴を必要とするという意図として理解されるべきではない。むしろ、発明されたコンテンツは、開示された個々の例のすべての特徴よりも少ない特徴に存在し得るという状況である。したがって、以下の特許請求の範囲は、本明細書に組み込まれると見なされるべきであり、各請求項はそれ自体が別個の例として存在することができる。各請求項はそれ自体が別個の例として存在することができるが、従属請求項は請求項において１つまたは複数の請求項との特定の組合せを指すことができるが、他の例もまた、前記従属請求項と任意の別の従属請求項の主題との組合せ、または任意の特徴と他の従属請求項および独立請求項との組合せを包含する、または含むことができる点に留意されたい。特定の組合せが意図されていないことが明示されていない限り、そのような組合せが本明細書において提案される。さらに、たとえ前記請求項が独立請求項に直接依存していないとしても、請求項の特徴は別の任意の独立請求項に含まれ得ることもまた意図される。

[00130]さらに、本明細書または特許請求の範囲に開示された方法は、この方法のそれぞれのステップまたは動作を実行するための手段を備えるデバイスによって実施され得る点に留意されたい。

[00131]さらに、いくつかの例では、個々のステップ／動作は、複数のサブステップに細分されてもよく、複数のサブステップを含んでもよい。そのようなサブステップは、個々のステップの開示に含まれてもよく、個々のステップの開示の一部であってもよい。

[00132]前述の開示は本開示の例示的な実施例を示すが、添付の特許請求の範囲によって定義される本開示の範囲から逸脱することなしに、本明細書において様々な変更および修正が行われ得る点に留意されたい。本明細書に記載された開示の例による方法クレームの機能、ステップ、および／または動作は、任意の特定の順序で実行される必要はない。さらに、本開示の要素は単数形で記載または請求され得るが、単数形への限定が明示的に述べられていない限り、複数形も考えられる。

Claims (30)

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. 前記マイクロプロセッサ周波数ジャンプ決定を制御することが、前記コントローラのアンダーフロー状態が終了した後に、前記減少されたプロセッサ速度を維持することを含む、請求項２９に記載の製造物品。

Images