通信端末およびその制御方法並びにプログラム
【課題】ＣＰＵ過負荷に起因する処理遅延による通信切断を回避する通信端末を提供する。
【解決手段】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、ＣＰＵの使用率およびバッファの使用率に基づいて負荷状態を判定する負荷検出部と、負荷検出部の判定結果に基づいて通信レートを変更する負荷制御部とを具え、負荷検出部は、ＣＰＵの使用率が第１の閾値以上であってバッファの使用率が第２の閾値以上である場合に負荷状態を過負荷状態と判定するとともに、ＣＰＵの使用率が第３の閾値以下である場合に負荷状態を通常状態と判定する。
【解決手段】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、ＣＰＵの使用率およびバッファの使用率に基づいて負荷状態を判定する負荷検出部と、負荷検出部の判定結果に基づいて通信レートを変更する負荷制御部とを具え、負荷検出部は、ＣＰＵの使用率が第１の閾値以上であってバッファの使用率が第２の閾値以上である場合に負荷状態を過負荷状態と判定するとともに、ＣＰＵの使用率が第３の閾値以下である場合に負荷状態を通常状態と判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信端末に関し、特に、処理量を超えた高速データ通信を要求されて端末が過負荷状態になった場合に、通信の切断を回避する通信端末およびその制御方法並びにプログラムに関する。
【背景技術】
【０００２】
近年、特に携帯通信端末を用いたデータ通信における通信速度は飛躍的に高速化している。高速データ通信を実現するためには、携帯通信端末内でデータ通信に必要な処理を高速かつ大量に実行する必要がある。データ通信速度が高速になるほど、端末が所定時間内に実行すべき処理が増加する。通常、携帯通信端末は規格で定められた最大通信レートに対応すべく設計されるため、データ送信のみ、あるいはデータ受信のみの単独であれば最大スループットで処理できる。しかし、データの送受信が同時に行われると端末の処理能力を超過しＣＰＵ（Central Processing Unit）が過負荷状態になる可能性がある。この過負荷状態が続き、ＣＰＵの処理能力を越えた処理を要求され続けた場合、処理が滞りデータ通信に必要な処理を一定時間内に完了できず、通信が切断されてしまう恐れがある。
【０００３】
端末プロセッサの能力低下を判断して対処する技術として、以下のものがある。特許文献１では、プロセッサの使用率に基づき受信能力を検出し、受信能力が低下した場合にデータの再送要求を行うことが提案されている。特許文献２では、通信ノードへの総発信呼数、ＣＰＵ使用率、およびバッファ使用率を測定して発信呼輻輳判定を行い、輻輳発生時に発信呼を選択的に規制することが提案されている。特許文献３には、バッファ使用率とプロセッサ使用率に基づいて輻輳制御を行うことが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−０３６８８９号公報（第５−６ページ、図５等）
【特許文献２】特開２００４−１８００５１号公報（第６−７ページ、図２等）
【特許文献３】特開平０７−０３８６０９号公報（第３ページ、図１等）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明が解決しようとする問題点は、ＣＰＵの過負荷状態で高速データ処理要求が続くと、処理遅延により通信切断が発生してしまうことである。そこで本発明は、携帯通信端末内のＣＰＵ負荷状況等の情報に基づいて、ＣＰＵ過負荷に起因する処理遅延による通信切断を回避する、通信端末、制御方法並びに通信端末制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明にかかる通信端末は、ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、ＣＰＵの使用率およびバッファの使用率に基づいて負荷状態を判定する負荷検出部と、負荷検出部の判定結果に基づいて通信レートを変更する負荷制御部とを具え、負荷検出部は、ＣＰＵの使用率が所定期間第１の閾値以上であってバッファの使用率が第２の閾値以上である場合に負荷状態を過負荷状態と判定するとともに、ＣＰＵの使用率が第１の閾値より低い第３の閾値以下である場合に負荷状態を通常状態と判定することをもっとも主要な特徴とする。
【発明の効果】
【０００７】
本発明の通信端末は、ＣＰＵ使用率に加えバッファ使用率が所定値以上となった場合に過負荷状態と判断して、通信レートを低減させてＣＰＵ負荷制御を行う。したがって、負荷制御が必要ない場合にも通信レートを低減してしまうのを防ぐことができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態にかかる携帯通信端末の構成を示す概略ブロック図である。
【図２】本発明の方法における過負荷状態の判定処理を説明するためのフローチャートである。
【図３】本発明の方法における負荷制御処理を説明するためのフローチャートである。
【図４】記憶部３に登録される、ＣＰＵ負荷とＵＬ／ＤＬデータ通信レートとの相関テーブルの実施例を示す図である。
【図５】図２の過負荷状態の判定処理の別の例を説明するためのフローチャートである。
【発明を実施するための形態】
【０００９】
本発明の実施の形態を、添付の図面を参照しながら以下に詳細に説明する。なお、以下の説明では本発明の通信端末を携帯電話機として説明するが、本発明は、携帯電話機のみならず、ＰＨＳ（Personal Handyphone System）、ＰＤＡ（Personal Digital Assistants）、およびラップトップ型コンピュータ等の無線通信端末の他、デスクトップ型コンピュータやサーバコンピュータ等の有線でデータ通信を行う通信端末にも適用することができる。
【００１０】
図１は、本発明の一実施形態にかかる携帯電話端末１の構成を示す概略ブロック図である。本発明の携帯電話端末１は、端末が過負荷状態か通常状態かを判定する負荷検出部２と、記憶部３と、データ通信レートの変更を行う負荷制御部４と、無線通信部５と、ＣＰＵ６とを具えている。なお、携帯電話端末１は、これらの構成要素の他に携帯電話機として必要な様々な要素（例えば、入出力部等）を具えるが、以下では説明の簡単化のために本発明の特徴部分のみを図示して説明する。携帯電話端末１は、無線通信部５を介して、外部の基地局７とデータ通信を行う。ここで、携帯電話端末１と基地局７とは、例えば３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｔｏｃｏｌ（３ＧＰＰ）によって規定された所定の通信規格をサポートしているものとする。携帯電話端末１から基地局７へのデータ通信はアップリンクデータ通信（すなわち端末１からの送信。以下、「ＵＬデータ通信」）と呼ばれ、基地局７から携帯電話端末１へのデータ通信はダウンリンクデータ通信（すなわち端末１のデータ受信。以下、「ＤＬデータ通信」）と呼ばれる。
【００１１】
負荷検出部２は、携帯電話端末１に内蔵されたＣＰＵ６が過負荷状態に陥っていることを検出する。すなわち、負荷検出部２は、携帯電話端末１のＣＰＵ６が処理可能な能力以上の処理が発生したため過負荷状態に陥っており負荷制御が必要であるか、あるいは過負荷状態から脱却したため負荷制御を終了するかを判定する。この判定には、ＣＰＵ使用率と、記憶部３のバッファ使用率が用いられる。一般に、ＣＰＵ使用率が１００％であっても必ずしも過負荷状態であるとは限らない。しかしながら、ＣＰＵ使用率が１００％である状態が継続したために処理が滞り、その結果未処理のデータがバッファ内に溜まってしまった場合は過負荷状態に陥ったと判断できる。このため本発明では、ＣＰＵ使用率が第１の閾値以上かつバッファ使用率が第２の閾値以上である場合に過負荷状態と判断する。そして、ＣＰＵ使用率が（第１の閾値より低い）第３の閾値以下となった場合に過負荷状態から脱却したと判断する。この具体的な判断処理については、フローチャートを参照しながら以降に詳述する。
【００１２】
なお、バッファ使用率とは、全バッファの容量に対する、バッファの使用量の比である。通常、全バッファの容量は、システムとして既知である。バッファの使用量は、例えば、バッファとして使用されているメモリ・ブロックの個数と各メモリ・ブロックのサイズの積から求めることができる。バッファ使用率は、バッファの使用量を全バッファの容量で割ることによって求めることができる。あるいは、バッファ使用率は、バッファとして使用されているメモリ・ブロックの個数を、バッファとして使用可能なメモリ・ブロックの個数で割ることにより求めてもよい。
【００１３】
ＣＰＵ使用率は、ある時間中の、ＣＰＵ６が処理を行っている時間の比率である。たとえば、ＣＰＵ６が実行するプログラムが複数のタスクで構成され、ＣＰＵ６が実行すべき処理がないときに遷移する先のタスク（アイドル・タスク）が設けられている場合であれば、ＣＰＵ使用率は次のようにしても求めることができる。すなわち、アイドル・タスクに遷移した時刻と、アイドル・タスクを抜けた時刻との差から、ＣＰＵ６がアイドル状態にあった時間（アイドル時間）を求める。そして、ＣＰＵ使用率を、所定の期間に対するアイドル時間が占める割合として求める。ＣＰＵ６が実行するプログラムがタスクで構成されていない場合であっても、アイドル状態へ遷移した時刻からアイドル状態を脱した時刻までの時間をタイマ等で計測することによって、同様にＣＰＵ使用率を求めることができる。なお、通信端末１におけるＣＰＵ６の処理内容は特に限定されない。ただし、ＣＰＵ６の使用率は、通信レートに依存するものとする。すなわち、通信レートが高いほど、ＣＰＵ６の使用率は上昇し、通信レートが低いほど、ＣＰＵ６の使用率は低下する。したがって、ＣＰＵ６は、携帯電話端末１全体の制御を行うものであってもよい。ＣＰＵ６は、負荷検出部２、記憶部３、負荷制御部４、無線通信部５のいずれかの処理を行うものであってもよい。あるいは、ＣＰＵ６は、通信以外のアプリケーション等の処理を行うものであってもよい。この場合、ＣＰＵ６は、無線通信部５によって送受信されるデータの処理に、直接的または間接的に関与する。例えば、ＣＰＵ６は、アプリケーション処理として、無線通信部５によって送信されるデータの生成または送信されるデータの基になるデータの生成を行う。あるいは、ＣＰＵ６は、アプリケーション処理として、無線通信部５によって受信されたデータの処理または受信されたデータを基として生成されたデータの処理を行う。
【００１４】
負荷制御部４は、ＣＰＵ６が過負荷状態であると判断された場合に、通信レートを低減し、ＣＰＵ負荷を過負荷状態から通常状態へと戻す制御を行う手段である。ここで、通信レートの低減には、ＵＬデータ通信に対する制御と、ＤＬデータ通信に対する制御が考えられる。負荷制御部４は、後に詳述する制御により、ＵＬデータ通信とＤＬデータ通信をバランスよく低減させて最適な負荷制御を行う。なお、負荷検出部２および負荷制御部４は、端末１の電源投入時には常時動作するソフトウェアモジュールとして実現することができる。
【００１５】
記憶部３は、ＣＰＵ６の処理データを一次的に保存するバッファ３ａと、ＵＬデータ通信レートとＤＬデータ通信レートの組み合わせに対するＣＰＵ使用率の相関テーブル３ｂとを少なくとも具える。一般的に通信端末の処理能力は、ＣＰＵ性能や他のハードウェア構成、ソフトウェア構成等の様々な要因によって異なる。このため、通信端末に最適な負荷制御を実施すべく、予めＵＬデータ通信速度とＤＬデータ通信速度の組み合わせにおける端末のＣＰＵ使用率を測定あるいは予測し、図４に示すような相関テーブル３ｂに登録しておく。図４に示すように、相関テーブル３ｂでは、ＵＬデータ通信レートとＤＬデータ通信レートがそれぞれレベル分けされ（ａ〜ｆとＡ〜Ｆ）、あるレベル以上でＵＬデータ通信とＤＬデータ通信が同時に行われた場合にＣＰＵ使用率が１００％となることが分かる。このように、図４におけるレベルａ〜ｆ、Ａ〜Ｆは、それぞれ、ＵＬデータ通信レート、ＤＬデータ通信レートの範囲を表す。この相関テーブル３ｂは、携帯電話端末１の工場出荷時にテスト用データでＵＬ・ＤＬデータ通信を実施してＣＰＵ使用率を測定して登録してもよい。あるいは、出荷後の実際の高速データ通信時に端末内でスループットとＣＰＵ使用率を定期的にモニタリングして更新するように構成してもよい。
【００１６】
図２は、上記のように構成した携帯電話端末１における過負荷状態の判定処理を説明するためのフローチャートである。本発明では、ＣＰＵ使用率が所定期間第１の閾値を超えており、同時にバッファ使用率が第２の閾値を超えている場合に過負荷状態であるとして負荷制御を行うよう判断する。ここで、ＣＰＵ使用率に関する第１の閾値は１００％であってもよいし、それより低い数値であってもよい。また、過負荷状態であると判定するための、ＣＰＵ使用率が第１の閾値を超えている期間は、瞬間であってもよいし、所定の時間（例えば、数十秒等）であってもよい。図２の実施例では、ＣＰＵ使用率が一瞬でも第１の閾値を超え、且つバッファ使用率が第２の閾値を超えた場合に過負荷状態であると判定する例を説明する。
【００１７】
負荷検出部２は定期的に図２のフローを実行する。最初にＣＰＵ使用率を算出し（ステップＳ２０１）、記憶部３からバッファ使用率を取得する（ステップＳ２０２）。次に、負荷検出部２はＣＰＵ使用率が第１の閾値以上であって（ステップＳ２０３：Ｙ）、バッファ使用率が所定の第２の閾値以上である場合（ステップＳ２０４：Ｙ）に、ＣＰＵ負荷状態を「過負荷状態」と設定する（ステップＳ２０５）。この負荷状態は負荷検出部２で管理される。また、ＣＰＵ使用率が第１の閾値より低い第３の閾値以下であって（ステップＳ２０６）、ＣＰＵ負荷状態が過負荷状態に設定されていた場合に（ステップＳ２０７：Ｙ）、ＣＰＵ負荷状態を「通常状態」と設定し（ステップＳ２０８）、負荷制御を停止する必要があると判断する。これらの条件にかからない場合はＣＰＵ負荷状態を変更せず処理を終了する。ここで、ＣＰＵ負荷状態を「通常状態」と判断するための第３の閾値は第１の閾値より低ければよく、例えば第１の閾値が１００％であれば第３の閾値は９９％に設定することができる。
【００１８】
図３は、負荷検出部２がＣＰＵ過負荷状態と判断した場合の負荷制御処理を説明するためのフローチャートである。負荷制御部４は、定期的に負荷検出部２が管理するＣＰＵ負荷状態を確認するか、負荷検出部２がＣＰＵ負荷状態を変更した場合に通知を受けて、図３の処理を実行する。負荷制御部４は、負荷検出部２からＣＰＵ６の負荷状態を受け取り（ステップＳ３０１）、ＣＰＵ負荷状態が過負荷状態であるか否かを判定する（ステップＳ３０２）。
【００１９】
ＣＰＵ負荷状態が過負荷状態であった場合（ステップＳ３０２：Ｙ）、負荷状態を低減しなければ通信が切断されてしまう可能性があるため、負荷制御を実施する。この場合、負荷制御部４は、無線通信部５からその時点のＵＬ通信レートとＤＬ通信レートの情報を取得する（ステップＳ３０３）。そして、ＵＬ通信レートとＤＬ通信レートのスループット比率（ＵＬ／ＤＬ）を算出し、スループット比率が所定の上限閾値以上であるか否かを判定する（ステップＳ３０４）。スループット比率が所定の上限閾値以上である場合（ステップＳ３０４：Ｙ）、ＵＬ通信レートを低減する制御を行う（ステップＳ３０５）。この処理により、ＵＬデータ通信の割合がＤＬデータ通信に比べて有意に多い場合に、ＵＬデータ通信の単位時間当たりの送信量を制限する負荷制御が実現する。そして、負荷制御部４はステータスを負荷制御状態に設定し、その情報を保持しておく（ステップＳ３１０）。
【００２０】
一方、スループット比率が上限閾値より小さい場合（ステップＳ３０４：Ｎ）、所定の下限閾値以下であるか否かを判定する（ステップＳ３０６）。下限閾値以下である場合（ステップＳ３０６：Ｙ）、ＤＬ通信レートを低減する制御を行う（ステップＳ３０７）。そして、ステップＳ３１０の処理を実行する。
【００２１】
ステップＳ３０７における、ＤＬ通信レートを低減する処理は、無線通信部５を介して基地局７に単位時間あたりのＤＬデータ通信量を低減するよう依頼することにより実現可能である。基地局７へのＤＬ通信レート低減の依頼方法としては、３ＧＰＰをサポートする携帯電話機と基地局であれば、Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）ｐｒｏｔｏｃｏｌに規定されているウィンドウ制御におけるウィンドウサイズの縮小要求を利用することができる。ウィンドウサイズとは、送達確認なしに連続して送受信できるデータ量である。ＤＬデータ通信のウィンドウサイズを縮小すれば、より小さい単位データ量毎に端末１側の確認応答を待ってから次のセグメントが送信されるため、結果として単位時間あたりのデータ送信量が低減する。ＲＬＣ ｐｒｏｔｏｃｏｌにおけるウィンドウサイズの縮小要求は公知技術であるため、本明細書でのこれ以上の詳細な説明は省略する。他の通信システムでは、ＤＬ通信レートを低減する目的で、データ送信量の削減や伝送速度の低下などを要求するようにしてもよい。この処理により、ＤＬデータ通信の割合がＵＬデータ通信に比べて有意に多い場合に、ＤＬデータ通信の単位時間当たりの送信量を制限する負荷制御が実現する。
【００２２】
スループット比率が上限閾値と下限閾値の間にある場合（ステップＳ３０６：Ｎ）、負荷制御部４は、ＵＬ／ＤＬ通信レートをそれぞれ同程度低減させる（ステップＳ３０８）。この場合、ＵＬ／ＤＬ通信レートをそれぞれ同じ量だけ低減させてもよいし、スループット比率を維持したままＵＬ／ＤＬ通信レートをそれぞれ低減させてもよい。その後、負荷制御部４はステップＳ３１０の処理を実行する。なお、ここで「同程度」とは、実質的に同じとみなすことができる程度であることを意味する。ＵＬ／ＤＬスループットの削減量は、厳密に等しい必要はない。差があっても用途によって許容される程度であれば、同程度とみなすことができる。このようにして、スループットすなわちデータ通信レートを低減させて、端末１を過負荷状態から脱却させる。
【００２３】
負荷制御部４は、通信レートを削減する場合、記憶部３の相関テーブル３ｂを用いる。すなわち、例えばステップＳ３０５でＵＬスループットを削減する場合、その時点のＵＬ／ＤＬ通信レートのレベルを取得する。そして、図４の相関テーブルからＤＬデータ通信レートを落とさずにＣＰＵ負荷が１００％以下となるＵＬデータ通信レートのレベルを導出する。具体的には、その時点のＵＬ通信レートがレベル（ａ）でＤＬ通信レートがレベル（Ｃ）である場合、図４の相関テーブル３ｂから、ＤＬデータ通信レートのレベル（Ｃ）は落とさずに、この場合のＣＰＵ負荷率が９０％となるＵＬデータ通信レートのレベル（ｃ）を導出する。そして、ＵＬデータ通信レートをレベル（ｃ）まで低減する制御を実行する。同様に、ＵＬ／ＤＬ通信レートがともに１００％である場合は、ＵＬ／ＤＬデータ通信レートを同程度下げることとする（ステップＳ３０８）。そして、相関テーブル３ｂを参照してＣＰＵ負荷が９０％となるＵＬデータ通信レートをレベル（ｃ）、ＤＬデータ通信レートをレベル（Ｃ）に低減する。
【００２４】
このように、予め相関テーブル３ｂを作成することにより、例えばデータ通信レートを漸減させながらＣＰＵ負荷を継続的に測定し、ＣＰＵ負荷が１００％以下となるのを見極める処理を毎回行うよりも迅速かつ効率的に負荷制御を実施することができる。また、負荷制御を行う際にＵＬ通信レートとＤＬ通信レートを取得し、有意に高くなっているＵＬおよび／またはＤＬ通信レートを低減するようにすれば、ＵＬとＤＬの通信レートをバランスよく制御することができる。
【００２５】
また、ＣＰＵ負荷状態が過負荷状態でない場合（ステップＳ３０３：Ｎ）、その時点の負荷制御状態を判定する（ステップＳ３１１）。その時点の負荷制御状態が制御状態である場合（Ｓ３１１：Ｙ）、過負荷状態を脱出しておりこれ以上の負荷制御を行う必要がないため、負荷制御を停止して（ステップＳ３１２）負荷状態を「通常状態」に設定する（ステップＳ３１３）。ここで負荷制御の停止は、ＵＬ／ＤＬデータ通信レートの制限を撤廃することである。その時点の負荷制御状態が制御状態でない場合には（Ｓ３１１：Ｎ）、処理を終了する。
【００２６】
以上に説明したように、本発明によれば、基地局などのデータ通信相手からＣＰＵの処理性能以上の高速なＵＬデータ通信を要求されたり、高速なＤＬデータが送られたりしてＣＰＵ過負荷状態となった場合でも、通信端末内のＣＰＵ負荷状況の情報に基づいて最適なＵＬ／ＤＬデータ通信速度を導出する。そして、タイムリーにＣＰＵ負荷制御を実行することにより、ＣＰＵの過負荷に起因する通信切断を有効に回避することができる。
【００２７】
図５は、図２に示す過負荷状態判定処理の別の例を説明するためのフローチャートである。本例では、ＣＰＵ使用率が第１の閾値を超えたまま所定期間経過し、且つバッファ使用率が第２の閾値以上である場合に負荷制御を行う。すなわち、負荷検出部２はＣＰＵ使用率とバッファ使用率を取得する（ステップＳ２０１、Ｓ２０２）。そして、負荷検出部２は、ＣＰＵ使用率が第１の閾値以上であるか否かを判断する（ステップＳ２０３）。ＣＰＵ使用率が第1の閾値以上である場合（ステップＳ２０３：Ｙ）、その状態が一定時間（例えば１０秒）継続するか否かを判定する（ステップＳ２０３−１）。ＣＰＵ使用率が一定時間第１の閾値以上である場合（ステップＳ２０３−１：Ｙ）、バッファ使用率が第２の閾値以上であるか否かを判定する（ステップＳ２０４）。バッファ使用率が第２の閾値以上である場合に（ステップＳ２０４：Ｙ）、ＣＰＵ負荷状態を過負荷状態に設定する（ステップＳ２０５）。本例において、ステップＳ２０３−１を追加した以外は図２の実施例と同一であり、その後の過負荷制御処理も上記実施例と同一である。このように、過負荷状態に陥っているか否かの判定に時間の要素を追加することにより、ＣＰＵ過負荷状態をより正確に検出して適切な過負荷制御を実施することができる。
【００２８】
なお、上記の説明では、携帯電話端末と基地局間の通信を例としたため、通信の方向をアップリンク、ダウンリンクと表現している。しかし、本発明は端末間通信などの通信形態にも適用可能であり、通信の方向はアップリンク、ダウンリンクには限定されない。通信の方向は、対象となる通信装置がデータを受信する方向と送信する方向の２方向あればよい。そして、その２方向のそれぞれの通信レートを上記のように制御して最適化することができる。
【００２９】
また、上記の説明において本発明の通信端末の実施形態を携帯電話機として記載しているが、本発明はＰＨＳや小型ゲーム機等の通信機能を有する他の電子機器や、通信機能を有し有線でネットワーク接続されるパーソナルコンピュータやサーバコンピュータにも適用することができる。また、通信の種類の無線通信には限定されず、有線通信であってもよい。
【産業上の利用可能性】
【００３０】
本発明は電子機器製造業、特にデータ通信機能を有する携帯電話機やコンピュータ機器製造業において利用することができる。
【符号の説明】
【００３１】
１ 携帯電話端末
２ 負荷検出部
３ 記憶部
４ 負荷制御部
５ 無線通信部
６ ＣＰＵ
７ 基地局
【技術分野】
【０００１】
本発明は通信端末に関し、特に、処理量を超えた高速データ通信を要求されて端末が過負荷状態になった場合に、通信の切断を回避する通信端末およびその制御方法並びにプログラムに関する。
【背景技術】
【０００２】
近年、特に携帯通信端末を用いたデータ通信における通信速度は飛躍的に高速化している。高速データ通信を実現するためには、携帯通信端末内でデータ通信に必要な処理を高速かつ大量に実行する必要がある。データ通信速度が高速になるほど、端末が所定時間内に実行すべき処理が増加する。通常、携帯通信端末は規格で定められた最大通信レートに対応すべく設計されるため、データ送信のみ、あるいはデータ受信のみの単独であれば最大スループットで処理できる。しかし、データの送受信が同時に行われると端末の処理能力を超過しＣＰＵ（Central Processing Unit）が過負荷状態になる可能性がある。この過負荷状態が続き、ＣＰＵの処理能力を越えた処理を要求され続けた場合、処理が滞りデータ通信に必要な処理を一定時間内に完了できず、通信が切断されてしまう恐れがある。
【０００３】
端末プロセッサの能力低下を判断して対処する技術として、以下のものがある。特許文献１では、プロセッサの使用率に基づき受信能力を検出し、受信能力が低下した場合にデータの再送要求を行うことが提案されている。特許文献２では、通信ノードへの総発信呼数、ＣＰＵ使用率、およびバッファ使用率を測定して発信呼輻輳判定を行い、輻輳発生時に発信呼を選択的に規制することが提案されている。特許文献３には、バッファ使用率とプロセッサ使用率に基づいて輻輳制御を行うことが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−０３６８８９号公報（第５−６ページ、図５等）
【特許文献２】特開２００４−１８００５１号公報（第６−７ページ、図２等）
【特許文献３】特開平０７−０３８６０９号公報（第３ページ、図１等）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明が解決しようとする問題点は、ＣＰＵの過負荷状態で高速データ処理要求が続くと、処理遅延により通信切断が発生してしまうことである。そこで本発明は、携帯通信端末内のＣＰＵ負荷状況等の情報に基づいて、ＣＰＵ過負荷に起因する処理遅延による通信切断を回避する、通信端末、制御方法並びに通信端末制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明にかかる通信端末は、ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、ＣＰＵの使用率およびバッファの使用率に基づいて負荷状態を判定する負荷検出部と、負荷検出部の判定結果に基づいて通信レートを変更する負荷制御部とを具え、負荷検出部は、ＣＰＵの使用率が所定期間第１の閾値以上であってバッファの使用率が第２の閾値以上である場合に負荷状態を過負荷状態と判定するとともに、ＣＰＵの使用率が第１の閾値より低い第３の閾値以下である場合に負荷状態を通常状態と判定することをもっとも主要な特徴とする。
【発明の効果】
【０００７】
本発明の通信端末は、ＣＰＵ使用率に加えバッファ使用率が所定値以上となった場合に過負荷状態と判断して、通信レートを低減させてＣＰＵ負荷制御を行う。したがって、負荷制御が必要ない場合にも通信レートを低減してしまうのを防ぐことができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態にかかる携帯通信端末の構成を示す概略ブロック図である。
【図２】本発明の方法における過負荷状態の判定処理を説明するためのフローチャートである。
【図３】本発明の方法における負荷制御処理を説明するためのフローチャートである。
【図４】記憶部３に登録される、ＣＰＵ負荷とＵＬ／ＤＬデータ通信レートとの相関テーブルの実施例を示す図である。
【図５】図２の過負荷状態の判定処理の別の例を説明するためのフローチャートである。
【発明を実施するための形態】
【０００９】
本発明の実施の形態を、添付の図面を参照しながら以下に詳細に説明する。なお、以下の説明では本発明の通信端末を携帯電話機として説明するが、本発明は、携帯電話機のみならず、ＰＨＳ（Personal Handyphone System）、ＰＤＡ（Personal Digital Assistants）、およびラップトップ型コンピュータ等の無線通信端末の他、デスクトップ型コンピュータやサーバコンピュータ等の有線でデータ通信を行う通信端末にも適用することができる。
【００１０】
図１は、本発明の一実施形態にかかる携帯電話端末１の構成を示す概略ブロック図である。本発明の携帯電話端末１は、端末が過負荷状態か通常状態かを判定する負荷検出部２と、記憶部３と、データ通信レートの変更を行う負荷制御部４と、無線通信部５と、ＣＰＵ６とを具えている。なお、携帯電話端末１は、これらの構成要素の他に携帯電話機として必要な様々な要素（例えば、入出力部等）を具えるが、以下では説明の簡単化のために本発明の特徴部分のみを図示して説明する。携帯電話端末１は、無線通信部５を介して、外部の基地局７とデータ通信を行う。ここで、携帯電話端末１と基地局７とは、例えば３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｔｏｃｏｌ（３ＧＰＰ）によって規定された所定の通信規格をサポートしているものとする。携帯電話端末１から基地局７へのデータ通信はアップリンクデータ通信（すなわち端末１からの送信。以下、「ＵＬデータ通信」）と呼ばれ、基地局７から携帯電話端末１へのデータ通信はダウンリンクデータ通信（すなわち端末１のデータ受信。以下、「ＤＬデータ通信」）と呼ばれる。
【００１１】
負荷検出部２は、携帯電話端末１に内蔵されたＣＰＵ６が過負荷状態に陥っていることを検出する。すなわち、負荷検出部２は、携帯電話端末１のＣＰＵ６が処理可能な能力以上の処理が発生したため過負荷状態に陥っており負荷制御が必要であるか、あるいは過負荷状態から脱却したため負荷制御を終了するかを判定する。この判定には、ＣＰＵ使用率と、記憶部３のバッファ使用率が用いられる。一般に、ＣＰＵ使用率が１００％であっても必ずしも過負荷状態であるとは限らない。しかしながら、ＣＰＵ使用率が１００％である状態が継続したために処理が滞り、その結果未処理のデータがバッファ内に溜まってしまった場合は過負荷状態に陥ったと判断できる。このため本発明では、ＣＰＵ使用率が第１の閾値以上かつバッファ使用率が第２の閾値以上である場合に過負荷状態と判断する。そして、ＣＰＵ使用率が（第１の閾値より低い）第３の閾値以下となった場合に過負荷状態から脱却したと判断する。この具体的な判断処理については、フローチャートを参照しながら以降に詳述する。
【００１２】
なお、バッファ使用率とは、全バッファの容量に対する、バッファの使用量の比である。通常、全バッファの容量は、システムとして既知である。バッファの使用量は、例えば、バッファとして使用されているメモリ・ブロックの個数と各メモリ・ブロックのサイズの積から求めることができる。バッファ使用率は、バッファの使用量を全バッファの容量で割ることによって求めることができる。あるいは、バッファ使用率は、バッファとして使用されているメモリ・ブロックの個数を、バッファとして使用可能なメモリ・ブロックの個数で割ることにより求めてもよい。
【００１３】
ＣＰＵ使用率は、ある時間中の、ＣＰＵ６が処理を行っている時間の比率である。たとえば、ＣＰＵ６が実行するプログラムが複数のタスクで構成され、ＣＰＵ６が実行すべき処理がないときに遷移する先のタスク（アイドル・タスク）が設けられている場合であれば、ＣＰＵ使用率は次のようにしても求めることができる。すなわち、アイドル・タスクに遷移した時刻と、アイドル・タスクを抜けた時刻との差から、ＣＰＵ６がアイドル状態にあった時間（アイドル時間）を求める。そして、ＣＰＵ使用率を、所定の期間に対するアイドル時間が占める割合として求める。ＣＰＵ６が実行するプログラムがタスクで構成されていない場合であっても、アイドル状態へ遷移した時刻からアイドル状態を脱した時刻までの時間をタイマ等で計測することによって、同様にＣＰＵ使用率を求めることができる。なお、通信端末１におけるＣＰＵ６の処理内容は特に限定されない。ただし、ＣＰＵ６の使用率は、通信レートに依存するものとする。すなわち、通信レートが高いほど、ＣＰＵ６の使用率は上昇し、通信レートが低いほど、ＣＰＵ６の使用率は低下する。したがって、ＣＰＵ６は、携帯電話端末１全体の制御を行うものであってもよい。ＣＰＵ６は、負荷検出部２、記憶部３、負荷制御部４、無線通信部５のいずれかの処理を行うものであってもよい。あるいは、ＣＰＵ６は、通信以外のアプリケーション等の処理を行うものであってもよい。この場合、ＣＰＵ６は、無線通信部５によって送受信されるデータの処理に、直接的または間接的に関与する。例えば、ＣＰＵ６は、アプリケーション処理として、無線通信部５によって送信されるデータの生成または送信されるデータの基になるデータの生成を行う。あるいは、ＣＰＵ６は、アプリケーション処理として、無線通信部５によって受信されたデータの処理または受信されたデータを基として生成されたデータの処理を行う。
【００１４】
負荷制御部４は、ＣＰＵ６が過負荷状態であると判断された場合に、通信レートを低減し、ＣＰＵ負荷を過負荷状態から通常状態へと戻す制御を行う手段である。ここで、通信レートの低減には、ＵＬデータ通信に対する制御と、ＤＬデータ通信に対する制御が考えられる。負荷制御部４は、後に詳述する制御により、ＵＬデータ通信とＤＬデータ通信をバランスよく低減させて最適な負荷制御を行う。なお、負荷検出部２および負荷制御部４は、端末１の電源投入時には常時動作するソフトウェアモジュールとして実現することができる。
【００１５】
記憶部３は、ＣＰＵ６の処理データを一次的に保存するバッファ３ａと、ＵＬデータ通信レートとＤＬデータ通信レートの組み合わせに対するＣＰＵ使用率の相関テーブル３ｂとを少なくとも具える。一般的に通信端末の処理能力は、ＣＰＵ性能や他のハードウェア構成、ソフトウェア構成等の様々な要因によって異なる。このため、通信端末に最適な負荷制御を実施すべく、予めＵＬデータ通信速度とＤＬデータ通信速度の組み合わせにおける端末のＣＰＵ使用率を測定あるいは予測し、図４に示すような相関テーブル３ｂに登録しておく。図４に示すように、相関テーブル３ｂでは、ＵＬデータ通信レートとＤＬデータ通信レートがそれぞれレベル分けされ（ａ〜ｆとＡ〜Ｆ）、あるレベル以上でＵＬデータ通信とＤＬデータ通信が同時に行われた場合にＣＰＵ使用率が１００％となることが分かる。このように、図４におけるレベルａ〜ｆ、Ａ〜Ｆは、それぞれ、ＵＬデータ通信レート、ＤＬデータ通信レートの範囲を表す。この相関テーブル３ｂは、携帯電話端末１の工場出荷時にテスト用データでＵＬ・ＤＬデータ通信を実施してＣＰＵ使用率を測定して登録してもよい。あるいは、出荷後の実際の高速データ通信時に端末内でスループットとＣＰＵ使用率を定期的にモニタリングして更新するように構成してもよい。
【００１６】
図２は、上記のように構成した携帯電話端末１における過負荷状態の判定処理を説明するためのフローチャートである。本発明では、ＣＰＵ使用率が所定期間第１の閾値を超えており、同時にバッファ使用率が第２の閾値を超えている場合に過負荷状態であるとして負荷制御を行うよう判断する。ここで、ＣＰＵ使用率に関する第１の閾値は１００％であってもよいし、それより低い数値であってもよい。また、過負荷状態であると判定するための、ＣＰＵ使用率が第１の閾値を超えている期間は、瞬間であってもよいし、所定の時間（例えば、数十秒等）であってもよい。図２の実施例では、ＣＰＵ使用率が一瞬でも第１の閾値を超え、且つバッファ使用率が第２の閾値を超えた場合に過負荷状態であると判定する例を説明する。
【００１７】
負荷検出部２は定期的に図２のフローを実行する。最初にＣＰＵ使用率を算出し（ステップＳ２０１）、記憶部３からバッファ使用率を取得する（ステップＳ２０２）。次に、負荷検出部２はＣＰＵ使用率が第１の閾値以上であって（ステップＳ２０３：Ｙ）、バッファ使用率が所定の第２の閾値以上である場合（ステップＳ２０４：Ｙ）に、ＣＰＵ負荷状態を「過負荷状態」と設定する（ステップＳ２０５）。この負荷状態は負荷検出部２で管理される。また、ＣＰＵ使用率が第１の閾値より低い第３の閾値以下であって（ステップＳ２０６）、ＣＰＵ負荷状態が過負荷状態に設定されていた場合に（ステップＳ２０７：Ｙ）、ＣＰＵ負荷状態を「通常状態」と設定し（ステップＳ２０８）、負荷制御を停止する必要があると判断する。これらの条件にかからない場合はＣＰＵ負荷状態を変更せず処理を終了する。ここで、ＣＰＵ負荷状態を「通常状態」と判断するための第３の閾値は第１の閾値より低ければよく、例えば第１の閾値が１００％であれば第３の閾値は９９％に設定することができる。
【００１８】
図３は、負荷検出部２がＣＰＵ過負荷状態と判断した場合の負荷制御処理を説明するためのフローチャートである。負荷制御部４は、定期的に負荷検出部２が管理するＣＰＵ負荷状態を確認するか、負荷検出部２がＣＰＵ負荷状態を変更した場合に通知を受けて、図３の処理を実行する。負荷制御部４は、負荷検出部２からＣＰＵ６の負荷状態を受け取り（ステップＳ３０１）、ＣＰＵ負荷状態が過負荷状態であるか否かを判定する（ステップＳ３０２）。
【００１９】
ＣＰＵ負荷状態が過負荷状態であった場合（ステップＳ３０２：Ｙ）、負荷状態を低減しなければ通信が切断されてしまう可能性があるため、負荷制御を実施する。この場合、負荷制御部４は、無線通信部５からその時点のＵＬ通信レートとＤＬ通信レートの情報を取得する（ステップＳ３０３）。そして、ＵＬ通信レートとＤＬ通信レートのスループット比率（ＵＬ／ＤＬ）を算出し、スループット比率が所定の上限閾値以上であるか否かを判定する（ステップＳ３０４）。スループット比率が所定の上限閾値以上である場合（ステップＳ３０４：Ｙ）、ＵＬ通信レートを低減する制御を行う（ステップＳ３０５）。この処理により、ＵＬデータ通信の割合がＤＬデータ通信に比べて有意に多い場合に、ＵＬデータ通信の単位時間当たりの送信量を制限する負荷制御が実現する。そして、負荷制御部４はステータスを負荷制御状態に設定し、その情報を保持しておく（ステップＳ３１０）。
【００２０】
一方、スループット比率が上限閾値より小さい場合（ステップＳ３０４：Ｎ）、所定の下限閾値以下であるか否かを判定する（ステップＳ３０６）。下限閾値以下である場合（ステップＳ３０６：Ｙ）、ＤＬ通信レートを低減する制御を行う（ステップＳ３０７）。そして、ステップＳ３１０の処理を実行する。
【００２１】
ステップＳ３０７における、ＤＬ通信レートを低減する処理は、無線通信部５を介して基地局７に単位時間あたりのＤＬデータ通信量を低減するよう依頼することにより実現可能である。基地局７へのＤＬ通信レート低減の依頼方法としては、３ＧＰＰをサポートする携帯電話機と基地局であれば、Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）ｐｒｏｔｏｃｏｌに規定されているウィンドウ制御におけるウィンドウサイズの縮小要求を利用することができる。ウィンドウサイズとは、送達確認なしに連続して送受信できるデータ量である。ＤＬデータ通信のウィンドウサイズを縮小すれば、より小さい単位データ量毎に端末１側の確認応答を待ってから次のセグメントが送信されるため、結果として単位時間あたりのデータ送信量が低減する。ＲＬＣ ｐｒｏｔｏｃｏｌにおけるウィンドウサイズの縮小要求は公知技術であるため、本明細書でのこれ以上の詳細な説明は省略する。他の通信システムでは、ＤＬ通信レートを低減する目的で、データ送信量の削減や伝送速度の低下などを要求するようにしてもよい。この処理により、ＤＬデータ通信の割合がＵＬデータ通信に比べて有意に多い場合に、ＤＬデータ通信の単位時間当たりの送信量を制限する負荷制御が実現する。
【００２２】
スループット比率が上限閾値と下限閾値の間にある場合（ステップＳ３０６：Ｎ）、負荷制御部４は、ＵＬ／ＤＬ通信レートをそれぞれ同程度低減させる（ステップＳ３０８）。この場合、ＵＬ／ＤＬ通信レートをそれぞれ同じ量だけ低減させてもよいし、スループット比率を維持したままＵＬ／ＤＬ通信レートをそれぞれ低減させてもよい。その後、負荷制御部４はステップＳ３１０の処理を実行する。なお、ここで「同程度」とは、実質的に同じとみなすことができる程度であることを意味する。ＵＬ／ＤＬスループットの削減量は、厳密に等しい必要はない。差があっても用途によって許容される程度であれば、同程度とみなすことができる。このようにして、スループットすなわちデータ通信レートを低減させて、端末１を過負荷状態から脱却させる。
【００２３】
負荷制御部４は、通信レートを削減する場合、記憶部３の相関テーブル３ｂを用いる。すなわち、例えばステップＳ３０５でＵＬスループットを削減する場合、その時点のＵＬ／ＤＬ通信レートのレベルを取得する。そして、図４の相関テーブルからＤＬデータ通信レートを落とさずにＣＰＵ負荷が１００％以下となるＵＬデータ通信レートのレベルを導出する。具体的には、その時点のＵＬ通信レートがレベル（ａ）でＤＬ通信レートがレベル（Ｃ）である場合、図４の相関テーブル３ｂから、ＤＬデータ通信レートのレベル（Ｃ）は落とさずに、この場合のＣＰＵ負荷率が９０％となるＵＬデータ通信レートのレベル（ｃ）を導出する。そして、ＵＬデータ通信レートをレベル（ｃ）まで低減する制御を実行する。同様に、ＵＬ／ＤＬ通信レートがともに１００％である場合は、ＵＬ／ＤＬデータ通信レートを同程度下げることとする（ステップＳ３０８）。そして、相関テーブル３ｂを参照してＣＰＵ負荷が９０％となるＵＬデータ通信レートをレベル（ｃ）、ＤＬデータ通信レートをレベル（Ｃ）に低減する。
【００２４】
このように、予め相関テーブル３ｂを作成することにより、例えばデータ通信レートを漸減させながらＣＰＵ負荷を継続的に測定し、ＣＰＵ負荷が１００％以下となるのを見極める処理を毎回行うよりも迅速かつ効率的に負荷制御を実施することができる。また、負荷制御を行う際にＵＬ通信レートとＤＬ通信レートを取得し、有意に高くなっているＵＬおよび／またはＤＬ通信レートを低減するようにすれば、ＵＬとＤＬの通信レートをバランスよく制御することができる。
【００２５】
また、ＣＰＵ負荷状態が過負荷状態でない場合（ステップＳ３０３：Ｎ）、その時点の負荷制御状態を判定する（ステップＳ３１１）。その時点の負荷制御状態が制御状態である場合（Ｓ３１１：Ｙ）、過負荷状態を脱出しておりこれ以上の負荷制御を行う必要がないため、負荷制御を停止して（ステップＳ３１２）負荷状態を「通常状態」に設定する（ステップＳ３１３）。ここで負荷制御の停止は、ＵＬ／ＤＬデータ通信レートの制限を撤廃することである。その時点の負荷制御状態が制御状態でない場合には（Ｓ３１１：Ｎ）、処理を終了する。
【００２６】
以上に説明したように、本発明によれば、基地局などのデータ通信相手からＣＰＵの処理性能以上の高速なＵＬデータ通信を要求されたり、高速なＤＬデータが送られたりしてＣＰＵ過負荷状態となった場合でも、通信端末内のＣＰＵ負荷状況の情報に基づいて最適なＵＬ／ＤＬデータ通信速度を導出する。そして、タイムリーにＣＰＵ負荷制御を実行することにより、ＣＰＵの過負荷に起因する通信切断を有効に回避することができる。
【００２７】
図５は、図２に示す過負荷状態判定処理の別の例を説明するためのフローチャートである。本例では、ＣＰＵ使用率が第１の閾値を超えたまま所定期間経過し、且つバッファ使用率が第２の閾値以上である場合に負荷制御を行う。すなわち、負荷検出部２はＣＰＵ使用率とバッファ使用率を取得する（ステップＳ２０１、Ｓ２０２）。そして、負荷検出部２は、ＣＰＵ使用率が第１の閾値以上であるか否かを判断する（ステップＳ２０３）。ＣＰＵ使用率が第1の閾値以上である場合（ステップＳ２０３：Ｙ）、その状態が一定時間（例えば１０秒）継続するか否かを判定する（ステップＳ２０３−１）。ＣＰＵ使用率が一定時間第１の閾値以上である場合（ステップＳ２０３−１：Ｙ）、バッファ使用率が第２の閾値以上であるか否かを判定する（ステップＳ２０４）。バッファ使用率が第２の閾値以上である場合に（ステップＳ２０４：Ｙ）、ＣＰＵ負荷状態を過負荷状態に設定する（ステップＳ２０５）。本例において、ステップＳ２０３−１を追加した以外は図２の実施例と同一であり、その後の過負荷制御処理も上記実施例と同一である。このように、過負荷状態に陥っているか否かの判定に時間の要素を追加することにより、ＣＰＵ過負荷状態をより正確に検出して適切な過負荷制御を実施することができる。
【００２８】
なお、上記の説明では、携帯電話端末と基地局間の通信を例としたため、通信の方向をアップリンク、ダウンリンクと表現している。しかし、本発明は端末間通信などの通信形態にも適用可能であり、通信の方向はアップリンク、ダウンリンクには限定されない。通信の方向は、対象となる通信装置がデータを受信する方向と送信する方向の２方向あればよい。そして、その２方向のそれぞれの通信レートを上記のように制御して最適化することができる。
【００２９】
また、上記の説明において本発明の通信端末の実施形態を携帯電話機として記載しているが、本発明はＰＨＳや小型ゲーム機等の通信機能を有する他の電子機器や、通信機能を有し有線でネットワーク接続されるパーソナルコンピュータやサーバコンピュータにも適用することができる。また、通信の種類の無線通信には限定されず、有線通信であってもよい。
【産業上の利用可能性】
【００３０】
本発明は電子機器製造業、特にデータ通信機能を有する携帯電話機やコンピュータ機器製造業において利用することができる。
【符号の説明】
【００３１】
１ 携帯電話端末
２ 負荷検出部
３ 記憶部
４ 負荷制御部
５ 無線通信部
６ ＣＰＵ
７ 基地局
【特許請求の範囲】
【請求項１】
ＣＰＵと、
バッファを有する記憶部と、
変更可能な通信レートで通信を行う通信部と、
前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定する負荷検出部と、
前記負荷検出部の判定結果に基づいて、前記通信レートを変更する負荷制御部とを具え、
前記負荷検出部は、前記ＣＰＵの使用率が所定期間第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値以下である場合に前記負荷状態を通常状態と判定することを特徴とする通信端末。
【請求項２】
請求項１に記載の通信端末において、
前記記憶部がさらに、送信レートおよび受信レートの組み合わせと前記ＣＰＵの使用率とを対応させたテーブルを具えるとともに、
前記負荷制御部は、前記過負荷状態と判定された場合に前記テーブルを参照して、前記ＣＰＵの使用率が所定値以下となるレベルまで前記送信レートおよび／または受信レートを低減することを特徴とする通信端末。
【請求項３】
請求項１または２に記載の通信端末において、
前記負荷制御部は、前記過負荷状態と判定された場合に、その時点の送信レートおよび受信レートを取得し、
前記送信レートが受信レートに対して第１の割合以上である場合に前記送信レートを低減し、
前記送信レートが前記受信レートに対して前記第１の割合より小さい第２の割合以下である場合に前記受信レートを低減し、
前記送信レートが前記受信レートに対して前記第１の割合より小さく、前記第２の割合よりも大きいとき、前記送信レートおよび前記受信レートを実質的に等しい割合だけ低減することを特徴とする通信端末。
【請求項４】
請求項１乃至３のいずれか１項に記載の通信端末において、
前記ＣＰＵの使用率は、前記通信レートに依存することを特徴とする通信端末。
【請求項５】
請求項１乃至４のいずれか１項に記載の通信端末において、
前記負荷制御部は、データ送信元に対し単位時間当たりの送信データ量の削減を依頼することにより、前記受信レートを変更することを特徴とする通信端末。
【請求項６】
請求項１乃至４のいずれか１項に記載の通信端末において、
前記負荷制御部は、ウィンドウ制御を用いた前記通信を行うデータ送信元にウィンドウサイズの変更を要求することにより、前記受信レートを変更することを特徴とする通信端末。
【請求項７】
相互に通信を行う少なくとも２の通信装置を具える通信システムにおいて、前記通信装置の少なくとも１以上が、
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定する負荷検出部と、前記負荷検出部の判定結果に基づいて、前記通信レートを変更する負荷制御部とを具え、
前記負荷検出部は、前記ＣＰＵの使用率が所定期間第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値以下である場合に前記負荷状態を通常状態と判定することを特徴とする通信システム。
【請求項８】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部とを具える通信端末の制御方法であって、
前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定するステップと、前記判定の結果に応じて通信レートを変更するステップとを具え、前記負荷を判定するステップは、前記ＣＰＵの使用率が第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値未満である場合に前記負荷状態を通常状態と判定することを特徴とする方法。
【請求項９】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部とを具える通信端末の制御プログラムであって、前記ＣＰＵの使用率が第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値未満である場合に通常状態と判定する負荷判定ステップと、前記判定の結果に応じて通信レートを変更するステップとを前記通信端末に実行させることを特徴とするプログラム。
【請求項１】
ＣＰＵと、
バッファを有する記憶部と、
変更可能な通信レートで通信を行う通信部と、
前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定する負荷検出部と、
前記負荷検出部の判定結果に基づいて、前記通信レートを変更する負荷制御部とを具え、
前記負荷検出部は、前記ＣＰＵの使用率が所定期間第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値以下である場合に前記負荷状態を通常状態と判定することを特徴とする通信端末。
【請求項２】
請求項１に記載の通信端末において、
前記記憶部がさらに、送信レートおよび受信レートの組み合わせと前記ＣＰＵの使用率とを対応させたテーブルを具えるとともに、
前記負荷制御部は、前記過負荷状態と判定された場合に前記テーブルを参照して、前記ＣＰＵの使用率が所定値以下となるレベルまで前記送信レートおよび／または受信レートを低減することを特徴とする通信端末。
【請求項３】
請求項１または２に記載の通信端末において、
前記負荷制御部は、前記過負荷状態と判定された場合に、その時点の送信レートおよび受信レートを取得し、
前記送信レートが受信レートに対して第１の割合以上である場合に前記送信レートを低減し、
前記送信レートが前記受信レートに対して前記第１の割合より小さい第２の割合以下である場合に前記受信レートを低減し、
前記送信レートが前記受信レートに対して前記第１の割合より小さく、前記第２の割合よりも大きいとき、前記送信レートおよび前記受信レートを実質的に等しい割合だけ低減することを特徴とする通信端末。
【請求項４】
請求項１乃至３のいずれか１項に記載の通信端末において、
前記ＣＰＵの使用率は、前記通信レートに依存することを特徴とする通信端末。
【請求項５】
請求項１乃至４のいずれか１項に記載の通信端末において、
前記負荷制御部は、データ送信元に対し単位時間当たりの送信データ量の削減を依頼することにより、前記受信レートを変更することを特徴とする通信端末。
【請求項６】
請求項１乃至４のいずれか１項に記載の通信端末において、
前記負荷制御部は、ウィンドウ制御を用いた前記通信を行うデータ送信元にウィンドウサイズの変更を要求することにより、前記受信レートを変更することを特徴とする通信端末。
【請求項７】
相互に通信を行う少なくとも２の通信装置を具える通信システムにおいて、前記通信装置の少なくとも１以上が、
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部と、前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定する負荷検出部と、前記負荷検出部の判定結果に基づいて、前記通信レートを変更する負荷制御部とを具え、
前記負荷検出部は、前記ＣＰＵの使用率が所定期間第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値以下である場合に前記負荷状態を通常状態と判定することを特徴とする通信システム。
【請求項８】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部とを具える通信端末の制御方法であって、
前記ＣＰＵの使用率および前記バッファの使用率に基づいて負荷状態を判定するステップと、前記判定の結果に応じて通信レートを変更するステップとを具え、前記負荷を判定するステップは、前記ＣＰＵの使用率が第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に前記負荷状態を過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値未満である場合に前記負荷状態を通常状態と判定することを特徴とする方法。
【請求項９】
ＣＰＵと、バッファを有する記憶部と、変更可能な通信レートで通信を行う通信部とを具える通信端末の制御プログラムであって、前記ＣＰＵの使用率が第１の閾値以上であって前記バッファの使用率が第２の閾値以上である場合に過負荷状態と判定するとともに、前記ＣＰＵの使用率が前記第１の閾値より低い第３の閾値未満である場合に通常状態と判定する負荷判定ステップと、前記判定の結果に応じて通信レートを変更するステップとを前記通信端末に実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１１−１６６６３６（Ｐ２０１１−１６６６３６Ａ）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願番号】特願２０１０−２９６３９（Ｐ２０１０−２９６３９）
【出願日】平成２２年２月１５日（２０１０．２．１５）
【出願人】（５０７１１０８３３）アドコアテック株式会社 (10)
【Ｆターム（参考）】
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願日】平成２２年２月１５日（２０１０．２．１５）
【出願人】（５０７１１０８３３）アドコアテック株式会社 (10)
【Ｆターム（参考）】
[ Back to top ]