(57)【要約】【課題】  従来の帯域要求システムでは、過大な帯域幅を割当てられているといった問題があった。【解決手段】  監視用のモニタ３は、ユーザ端末１と通信装置２とのそれぞれから性能情報を抽出し、それぞれが要求する帯域を割り出したあと性能情報値を通信装置２に返す。モニタ３は、ソフトウェア性能リスト8を有しており、アプリケーションや要求帯域、ＯＳから提示されるハードウェアパラメータなどを格納する。モニタ３は、さらに、ハードウェア性能リスト9を有しており、ＯＳから提示されるハードウェアパラメータやバス幅、通信装置の規格値などを格納している。要求帯域計算器６は、上記ソフトウェア性能リスト４及びハードウェア性能リスト５から、それぞれソフトウェア性能及びハードウェア性能を受け取り、これらを比較して要求する帯域値を決定し、通信装置２に対して要求帯域値を渡す。また、モニタ３は上記パラメータの値を常時観測しており、常に要求する帯域をシステムに適した値に動的に補正する。【選択図】  図１
2005328508.tif 000002
【特許請求の範囲】
【請求項１】
帯域の割り当て、管理を行う管理サーバ(以下「管理サーバ」と称する。)を有するコンピュータ・ネットワーク(以下「ネットワーク」と称する。)に対して、通信に使用する帯域幅(以下、「要求帯域幅」と称する。)の割当てを要求する手段と、前記要求帯域幅を算出する要求帯域幅算出手段と、を備えた情報処理装置であって、
前記要求帯域幅算出手段は、前記情報処理装置のデータ処理能力をパラメータとして前記要求帯域幅を算出することを特徴とする情報処理装置。
【請求項２】
前記情報処理装置のハードウェアの実効データ処理能力(bit/s：以下「bps」とする。)を前記データ処理能力の算出パラメータに含めることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ハードウェアの実行データ処理能力は、前記情報処理装置内のCPU、ROM、RAMのいずれかを含むハードウェアの性能(bps)に基づいて算出されることを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記ハードウェアの実行データ処理能力(bps)の算出規則を、前記情報処理装置に搭載されたハードウェア構成の変化に応じて変更することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
さらに、前記ハードウェアに関するデータを記録するハードウェア情報記録装置を有していることを特徴とする請求項１から４までのいずれか１項に記載の情報処理装置。
【請求項６】
管理サーバを有するネットワークに対して、要求帯域幅の割当てを要求する手段と、前記要求帯域幅を算出する要求帯域幅算出手段と、を備えた情報処理装置であって、
該情報処理装置内で動作するソフトウェアの動作時の実効データ処理能力(bps)を前記情報処理装置のデータ処理能力の算出パラメータに含めることを特徴とする情報処理装置。
【請求項７】
前記ソフトウェアの実行データ処理能力は、前記要求帯域幅に対するユーザの要求値と、前記ソフトウェアにおいて定められている値と、前記情報処理装置のオペレーションシステム（以下、「ＯＳ」）が提示するハードウェアパラメータと、一時的にデータを蓄積できるバッファ容量と、の少なくともいずれかにより算出されることを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記情報処理装置のソフトウェアの実効データ処理能力(bps)の算出規則を、処理対象となる情報の種類に応じて変更することを特徴とする請求項５又は６に記載の情報処理装置。
【請求項９】
前記ソフトウェアの実効データ処理能力(bps)は、前記ソフトウェアのCPUの使用率(%)と、前記ソフトウェア以外のプロセスが使用するCPUの使用率(%)の合計値の増減に応じて算出することを特徴とする請求項５から７までのいずれか1項に記載の情報処理装置。
【請求項１０】
さらに、前記ソフトウェアに関するデータを記録するソフトウェア情報記録装置を有していることを特徴とする請求項６から９までのいずれか１項に記載の情報処理装置。
【請求項１１】
前記ソフトウェア情報記録装置には、アプリケーションの動作に基づいて得られた値を記録することを特徴とする請求項１０に記載の情報処理装置。
【請求項１２】
さらに、前記ハードウェア情報記録装置又はソフトウェア情報記録装置には、今回の算出の比較対象として前回値を記録していることを特徴とする請求項５又は１０、１１に記載の情報処理装置。
【請求項１３】
管理サーバを有するネットワークに対して、通信に使用する帯域幅(以下、「要求帯域幅」と称する。)の割当てを要求する手段と、前記要求帯域幅を算出する要求帯域幅算出手段と、を備えた情報処理装置であって、
前記要求帯域幅算出手段は、実際の処理能力に基づいて前記要求帯域幅を算出することを特徴とする情報処理装置。
【請求項１４】
ネットワークに対して、要求帯域幅の割当てを要求する手段と、前記要求帯域幅を算出する要求帯域幅算出手段と、を備えた情報処理装置であって、
前記情報処理装置と前記ネットワークとの間における通信を行う通信装置の実効データ処理能力を前記情報処理装置のデータ処理能力の算出パラメータとすることを特徴とする情報処理装置。
【請求項１５】
前記通信装置の実行データ処理能力は、前記通信装置の規格上最大の帯域幅と、前記情報処理装置のＯＳが提示するハードウェアパラメータと、の少なくともいずれかにより算出されることを特徴とする請求項１４に記載の情報処理装置。
【請求項１６】
前記通信装置の実効データ処理能力の算出規則を、前記通信装置の規格上の通信方式に応じて変更することを特徴とする請求項１４又は１５に記載の情報処理装置。
【請求項１７】
前記要求帯域幅算出手段は、リアルタイムに検出された前記パラメータ値に基づいて算出することを特徴とする請求項１から１６までのいずれか１項に記載の情報処理装置。
【請求項１８】
ある時間毎に前記パラメータ値をサンプリングするサンプリング手段を有することを特徴とする請求項１から１６までのいずれか１項に記載の情報処理装置。
【請求項１９】
前記要求帯域幅算出手段は、処理開始前の初期値と、処理中における前記パラメータのサンプリング値とから算出されることを特徴とする請求項１７又は１８に記載の情報処理装置。
【請求項２０】
前記データ処理能力の変化をモニタリングする手段と、
前記情報処理装置のデータ処理能力を所定時間観測した後、前記ネットワーク側に要求する帯域幅の大きさを自動的に変更する要求帯域幅変更手段と
を備えたことを特徴とする請求項１から１９までのいずれか１項に記載の情報処理装置。
【請求項２１】
前記データ処理能力の変化をモニタリングする手段と、
前記情報処理装置のデータ処理能力が所定の量以上増減した場合、前記ネットワーク側に要求する帯域幅の大きさを自動的に変更する要求帯域幅変更手段と
を備えたことを特徴とする請求項１から１９までのいずれか１項に記載の情報処理装置。
【請求項２２】
管理サーバを有するネットワークに対して、通信に使用する帯域幅(要求帯域幅)の割当てを要求するステップと、前記要求帯域幅を算出する要求帯域幅算出するステップと、を備えた通信方法において、
前記要求帯域幅算出するステップは、情報処理装置のデータ処理能力をパラメータとして、要求帯域幅を算出するステップを備えたことを特徴とする通信方法。
【請求項２３】
管理サーバを有するネットワークに対して、通信に使用する帯域幅(要求帯域幅)の割当てを要求するステップと、前記要求帯域幅を算出する要求帯域幅算出するステップと、を備えた通信方法において、
通信に関連するソフトウェア又はハードウェアの実効データ処理性能(bps)を前記データ処理能力の算出パラメータとするステップを備えたことを特徴とする通信方法。
【請求項２４】
前記実効データ処理能力の変化をモニタリングする手順と、通信方法のデータ処理能力を所定の時間観測した後、通信ネットワーク側に要求する帯域幅の大きさを自動的に変更する要求帯域幅変更するステップと、通信方法のデータ処理能力が所定の量以上増減した場合、通信ネットワーク側に要求する帯域幅の大きさを自動的に変更する要求帯域幅変更するステップと、を備えたことを特徴とする前記請求項２２又は２３に記載の通信方法。
【請求項２５】
管理サーバを有するネットワーク全体の帯域幅と、前記情報処理装置の前記要求帯域幅を比較し、前期要求帯域が一番低いときのみネットワーク側に前記要求帯域を要求することを特徴とする、請求項１から２１までのいずれか１項に記載の情報処理装置。
【請求項２６】
管理サーバを有するネットワーク全体の帯域幅と、前記情報処理装置の前記要求帯域幅を比較し、前期要求帯域が一番低いときのみネットワーク側に前記要求帯域を要求することを特徴とする、請求項２２から２４までのいずれか１項に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関し、特に、通信機能を有する情報処理端末がネットワークへ接続する際に要求する帯域を制御する技術に関する。
【背景技術】
【０００２】
従来から音声や動画像は、音声・動画像専用回線を用いたテレビ・ラジオにより受信されてきた。近年、大容量ネットワークの構築が進み、ネットワーク経由で音声や動画像を配信するサービスが盛んになってきている。しかしながら、ネットワークは経路状況や接続するユーザ数などに応じて、１ユーザが使用できる帯域は刻々と変わる。そのため、突発的に大量のデータがネットワーク内に流れ込むと、ユーザの利用可能な帯域が著しく狭まり音声や動画像が途切れてしまうという問題が発生する。これが、音声や動画像等をネットワークにより伝送する際における不安定要因ともなっていた。
【０００３】
上記問題点に対しては、ユーザの使用する情報端末(以下「ユーザ端末」と称する。)をネットワークに接続する際に、ユーザ端末が管理サーバに対して、予め必要な伝送帯域を要求することによりデータの伝送に必要な帯域を確保するシステムが提案されている。このような、「予め必要な伝送帯域を要求することで、データ伝送に必要な帯域を確保するシステム」において、その要求帯域の大きさに関しては音声・静止画そして動画等の伝送情報の種類や、システムとしての規格とその伝送容量は考慮するものの、ユーザの感覚で比較的大まかに設定されているのが一般的であった。
【０００４】
しかしながら上記の方法では、図９（ａ）に示すように、ユーザの要求帯域５１がそのままユーザの使用するユーザ端末の要求帯域５２となる場合には、ユーザとしては十分な帯域を要求しようとするため要求帯域に比較して実際にユーザ端末が使用する帯域が小さくなる傾向があり、無駄に大きな帯域を要求してしまい、結果的にネットワークの利用効率を低下させるという問題がある。
【０００５】
そこで、図９（ｂ）に示すように、「ユーザがネットワークから動画配信を受ける時、有線ネットワークでは１００Ｍｂｓ、無線ネットワークでは１１Ｍｂｐｓなど通信装置の性能６２と、ユーザの希望する動画品質から算出した要求帯域６１と、ネットワーク経路の帯域幅６４とを比較し、一番低い帯域値を割当てる（６５）方法。」のように、ＬＡＮアダプタや無線ＬＡＮカードなどの、通信装置の性能やユーザの希望する値から算出した値を要求することで、回線利用効率を向上させる方法が提案されている（例えば、特許文献１参照）。
【０００６】
【特許文献１】特開２００２−２７１３８３号公報：発明の名称「コンテンツ配信制御装置及び方法」
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献１に記載の方法でも、図９（ｂ）に示すように、要求する帯域の値６３は、システムの規格上の数値６２やユーザの要求６１、ネットワーク性能６４は考慮に入れているものの、ユーザ端末や通信装置自体の実際の処理能力を考慮して設定されているわけではないため、ユーザの要求が、ユーザ端末や通信装置が実際に処理可能な値より過大となり、要求帯域分の帯域幅を確保できたとしても処理しきれない場合もあり、必ずしも、回線利用効率を向上させる上で効果的とは言えなかった。すなわち、この特開２００２−２７１３８３号公報の方式では、動画配信時にユーザの要求帯域６１である３０Ｍｂｐｓと通信装置の規格値６２である１００Ｍｂｐｓを比較して３０Ｍｂｐｓを要求し、ネットワーク経路の帯域幅６４が５０Ｍｂｐｓであるために、ユーザの要求帯域６１値を割当て帯域幅６５と算出する。しかしながら、ユーザ端末が１０Ｍｂｐｓしか処理できない性能であった場合、２０Ｍｂｐｓが余分に割当てられていることになる。すなわち、ユーザ端末や通信装置の帯域処理性能がネットワーク全体の帯域処理性能より低い場合、通信装置の性能と、ユーザの希望する動画品質から算出した要求帯域と、ネットワーク経路の帯域幅６４とを比較し、一番低い帯域値を割当てたとしても、効率的でない場合が生じる。
【０００８】
本発明は、通信機能を有する情報処理装置がネットワークに対して帯域要求を行う際において、回線利用効率のより一層の向上を目的とする。
【課題を解決するための手段】
【０００９】
本発明では、通信機能を備えた情報処理装置において、システムの規格上の数値やユーザの要求及びネットワーク性能に加え、ユーザ端末や通信装置自体の実際の処理能力を算定するための要素とする。これにより、帯域の値として適切に要求帯域値を求めることができる。
【００１０】
また、本発明では、ユーザ端末や通信装置におけるハードウェアとソフトウェアとの両方の処理能力をそれぞれ考慮し、さらに、帯域又はチャネルの占有に関する時間的な変動をも考慮するために、ハードウェアとソフトウェアとの両方の処理能力を動的にモニタリングする。これにより、それぞれの時点で適切な帯域を要求することができる。
【発明の効果】
【００１１】
本発明によれば、情報処理装置において、ユーザが使用するアプリケーションやユーザ端末、通信装置の実際の性能を考慮して要求する帯域を決定することにより、効率的な帯域を要求することができる。さらに、ソフトウェアやハードウェアの処理能力の状況をモニタリングした結果を反映させることで、要求する帯域を最適化することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態について説明を行う。本発明は、ネットワーク上に存在する管理サーバやルータやスイッチングハブ等の中継装置と、ワークステーションやデスクトップＰＣ、ノートＰＣやＰＤＡ等の携帯端末などを含むユーザ端末と、ユーザ端末のハードウェアの実効データ処理能力(以下「ハードウェア性能」と称する。)及びソフトウェアの実効データ処理能力(以下「ソフトウェア性能」と称する。)を監視するモニタ、処理内容等を表示する表示装置、有線ＬＡＮアダプタや無線ＬＡＮ用ＰＣカードなどの通信装置と、を有する。
【００１３】
また、説明の便宜上、本実施の形態においては、ユーザ端末（情報処理端末）と通信装置とが一体の場合を前提として説明するが、ユーザ端末と通信装置とは別々のハードウェアとして構成されていても良い。また、ユーザ端末と表示装置とが別々のハードウェア構成である場合を前提として説明するが、一体の場合でも良い。また、本実施の形態では、帯域監視を行うモニタをソフトウェアにより実現し、ユーザ端末内に設けられたＲＯＭ内に記憶されているものとして説明するが、実際にはユーザ端末と別のハードウェアにより構成しても良い。ユーザ端末と通信装置とを合わせてユーザシステムと称する。また、ユーザ端末のＣＰＵからユーザ端末の通信装置のインターフェイスまでのデータ転送経路をバスと称する。
【００１４】
尚、本発明は、例えばＡＲＩＢ ＳＴＤ-Ｔ７０のＨｉＳＷＡＮ（Ｈｉｇｈ Ｓｐｅｅｄ Ｗｉｒｅｌｅｓｓ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）のような帯域制御が可能な無線ＬＡＮシステムや、ＡＴＭなどの帯域保証機能のある有線ネットワークに適応することを目的とする。
【００１５】
また、本発明は、ユーザ端末がルータなどの中継装置を経由して管理サーバと通信を行うが、中継装置には一切の改造を加えない為、Ｄｉｆｆｓｅｒｖ等、ルータ等の中継装置で帯域制御を行うシステムにも適応可能である。
【００１６】
まず、ユーザシステムがネットワークに帯域を要求する直前に、モニタがユーザシステムを走査し、ユーザの使用するアプリケーションと各種ハードウェアパラメータ(詳しくは後述)を抽出し、上記アプリケーションとユーザシステムのハードウェア全体の実際の処理性能を計算してソフトウェア性能リストとハードウェア性能リスト(後述する図２(a−１)、（a−２）、(b)参照)を作成する。尚、ネットワークには、例えば、ネットワークの帯域を管理する機能を備えた管理サーバが設けられ、情報処理装置は、通信装置を介してこのネットワーク上で帯域管理を行う管理サーバに対して帯域要求を行うものとする。ＬＡＮネットワークを構築した場合には、例えばルータ機能などを備えた基地局が管理サーバに該当する。また、ユーザ端末と管理サーバを直結してもよいし、ネットワーク上にルータやスイッチングハブ等の中継装置が間に１台以上存在してもよい。
【００１７】
図１は、本発明の実施の形態による通信機能を有する情報処理装置の構成例、および、情報処理装置が接続するネットワークの構成例を示す図である。図１（ａ）はユーザ端末を含むユーザシステムの概要を示す図である。図１（ａ）に示すように、本実施の形態による情報処理装置（以下「ユーザ端末」と称する。）１は、オペレーティングシステムＯＳ１−２による動作などを制御するＣＰＵ１−１と、ＯＳ１−２と、ＯＳ１−２上で動作するアプリケーション（アプリ）１−３とを含むソフトウェアと、通信装置２へのインターフェイス２−１と、ＯＳ１−２などのプログラムを格納するＲＯＭ１−５と、ＣＰＵの命令データ等を一時格納するＲＡＭ１−４と、蓄積したユーザデータやプログラム等を格納するハードディスクに代表されるストレージデバイス１−６と、表示装置へ画像を送るグラフィクスカード１−７と、監視モニタ３と、これらを接続するバスラインＢＬ（以下「バス」と称する。）と、を有している。ユーザ端末１は、通信装置２を介してネットワーク５と接続可能になっている。ネットワーク５には複数の中継装置６と管理サーバ７が存在する。便宜上本実施例では中継装置６、管理サーバ７は共に１つとする。また、便宜上本実施例ではユーザ端末１は中継装置６を経由して管理サーバ７に接続するものとするが、直接管理サーバ７と接続しても良い。ＲＯＭ１−５やストレージデバイス１−６には、ＯＳなどの他、通信に使用するアプリケーションソフトウェアが格納されている。グラフィクスカード１−７はアプリケーションやＯＳから受け取ったデータを表示装置４へ送る。ユーザ端末１内に設けられた監視用のモニタ３は、ユーザ端末１と通信装置２とのそれぞれから性能情報を抽出し、それぞれが要求する帯域を割り出したあと性能情報値を通信装置２に返す。
【００１８】
図１（ｂ）は、監視用のモニタ３の詳細な構成例を示す図である。図１（ｂ）に示すように、モニタ３は、ソフトウェア性能リスト８を有しており、アプリケーションや要求帯域、ＯＳから提示されるハードウェアパラメータなどを格納する。モニタ３は、さらに、ハードウェア性能リスト９を有しており、ＯＳから提示されるハードウェアパラメータやバス幅、通信装置の規格値などを格納している。要求帯域計算器（比較器）１０は、上記ソフトウェア性能リスト８及びハードウェア性能リスト９から、それぞれソフトウェア性能及びハードウェア性能を受け取り、これらの比較に基づいて、ネットワークに要求する帯域値を決定し、通信装置２に対して要求帯域値を渡す。
【００１９】
図２は、図１に示すモニタ３に格納されているソフトウェア性能リスト８と、ハードウェア性能９と、の構成例を示す図である。図２（ａ−１）及び（ａ−２）はソフトウェア性能リストの構成例を示す図であり、具体的には、アプリケーション１０と、要求帯域(bps)１１と、ＩＯサイズ(byte)１２と、累計ＩＯサイズ(byte)１３と、総バッファサイズ(byte)１４と、累計バッファサイズ(byte)１５と、通信前のアプリケーションのＣＰＵ使用率(%)１６と、通信中のアプリケーションのＣＰＵ使用率(%)１７と、通信前のその他のＣＰＵ使用率(%)１８と、通信中のその他のＣＰＵ使用率(%)１９と、処理時間(s)２０と、処理帯域(bps)２１（括弧の中は前回の値）と、サンプリング周期(s)２２と、を格納している。
【００２０】
図２（ｂ）は、ハードウェア性能リストの構成例を示す図である。具体的には、通信装置３０と、バス幅(bps)３１と、規格帯域(bps)３２と、送受信（データ）サイズ(byte)３３と、累計送受信サイズ(byte)３４と、通信時間(s)３５と、NIC帯域(bps)３６（括弧の中は前回の値）と、サンプリング時間(s)３７と、を格納している。各パラメータの説明は後述する。
【００２１】
図３〜図７までは本実施の形態による情報処理装置における帯域要求処理の流れを示すフローチャート図である。図３は、ソフトウェア性能の測定処理の流れを示すフローチャート図である。図４はハードウェア性能測定の際におけるユーザ端末ハードウェア性能の測定処理の流れを示すフローチャート図である。図５は、ハードウェア性能測定の際における情報処理装置のハードウェア性能の測定処理の流れを示すフローチャート図である。
【００２２】
図６は、監視モニタがネットワークへ要求する帯域を情報処理装置へ渡す処理の流れを示すフローチャート図である。図７はアプリケーションの処理帯域を算出する方法の詳細を示すフローチャート図である。上記５つのフローチャート図の詳細については後述する。
【００２３】
図８は本実施例の一般的な動作例を示した図である。ＣＰＵ、アプリケーション（図では便宜上「アプリ」と記す）、バス、通信装置及びモニタは図１と同様のものである。また、ＲＯＭ・ＲＡＭ・ストレージデバイス・グラフィクスカード・表示装置・中継装置は省略する。
【００２４】
図８（ａ）は通信開始時にユーザ端末が管理サーバへ帯域を要求する動作を示した図である。図１と同様にユーザ端末はＣＰＵ４０−１を持ち、ＯＳ４０−２と、ＯＳ４０−２上で動作するアプリケーション４０−３を有する。通信装置４１はバスＢＬを介してＣＰＵ４０−１と接続している。モニタ４２は各種パラメータを観測する。また管理サーバ４３はユーザ端末に対して帯域４４の割り当てを行う。
【００２５】
図８（ｂ）は通信中にユーザ端末が帯域の削減を管理サーバへ要求する動作を示した図である。４５はアプリケーションが占有するバス帯域幅（ｂｐｓ）であり、４６はＣＰＵの使用率をグラフ化したものである。
【００２６】
図８（ｃ）は通信中にユーザ端末が帯域の増加を管理サーバへ要求する動作を示した図である。上記図８の詳細については後述する。
【００２７】
図９（ａ）から（ｃ）までは、従来例と本発明の実施の形態による技術との差異を示した図である。図９（ａ）は一般的な従来技術による方式を示す図であり、より具体的には、アプリケーション５０と、ユーザの要求帯域(bps)５１と、ユーザ端末の要求帯域(bps)５２と、割当て帯域(bps)５３と、ネットワーク経路(bps)５４と、を有している。図７（ｂ）は、上述の特開２００２−２７１３８３号公報の方式を示す図であり、具体的には、アプリケーション６０と、ユーザの要求帯域(bps)６１と、通信装置(bps)６２と、ユーザ端末の要求帯域(bps)６３と、ネットワーク経路(bps)６４と、割当て帯域(bps)６５と、ユーザ端末の実効性能(bps)６６と、を含んでいる。図７（ｃ）は、本実施の形態による方式を示す図であり、具体的には、アプリケーション７０と、ユーザの要求帯域(bps)７１と、通信装置(bps)７２と、ユーザ端末の実効性能(bps)７３と、ユーザ端末の要求帯域(bps)７４と、ネットワーク経路(bps)７５と、割当て帯域(bps)７６と、を有している。以下、上記ハードウェア性能リスト、ソフトウェア性能リストのパラメータと、ソフトウェア処理性能、ハードウェア処理性能の算出方法を説明する。
【００２８】
（ａ）ソフトウェア性能(bps)の算出方法
アプリケーションの処理性能は、単純に記述言語や記述の仕方、或いはコンパイラ等のソフトウェア要素だけでは決定できない。処理を実行するＣＰＵの性能や、プログラムをＲＯＭ又はＲＡＭから読み出す際のスピード、ストレージデバイスへのデータの退避速度、グラフィクスカードへの表示データの転送速度など、ハードウェア要素も密接に絡んでいる場合が多い。また、アプリケーションの種類によってはＲＡＭやストレージデバイス上に特別なバッファを構築し、アプリケーション本体は動いていなくともネットワークからのデータを一時格納することが可能であるものも存在する。
【００２９】
しかしながら、ＣＰＵやＲＯＭ、ＲＡＭ、ストレージデバイス、グラフィクスカード等のハードウェアの実効性能を直接測るためには、本実施の形態による技術を適応する度にユーザ端末のハードウェアに対して直接に改造を施さなければならないが、これは煩雑であり現実的ではない。そこで、ユーザ端末搭載のＯＳが提示するハードウェアパラメータの中から以下の項目を抽出し、アプリケーションおよびハードウェアの処理性能を求める材料とする。
１）アプリケーション毎のＩＯデバイスへの書き込み・読み込みサイズ(byte：以下総ＩＯサイズとする)。
２）アプリケーションのＣＰＵ使用率(％)
３）上記アプリケーション以外のプロセスが使用するＣＰＵの使用率（％、以下「その他のＣＰＵ使用率」と称する。）
４）アプリケーションの要求する帯域(bps、初期値：以下「要求帯域」と称する。)
５）総バッファ量(ｂｙｔｅ)
【００３０】
上記１）〜５）までのパラメータのうち、ユーザの使用するアプリケーションに割当てられているそれぞれの値を抽出し、ソフトウェア性能リストに書き加える。
【００３１】
これらを抽出することで、ＣＰＵやＲＯＭ、ＲＡＭ、ストレージデバイス、グラフィクスカード等の実効速度が分からなくても、アプリケーション本体とＩＯデバイス(本実施の形態における情報処理装置)がどれだけの速度でデータをやり取りできるかを知ることができる。加えてバッファがどれだけのデータを処理できるかを考慮することで、アプリケーション全体の処理性能が分かる。尚、上記総ＩＯサイズ及び総バッファ量はアプリケーション起動時から現在までのデータ量を合計した値である。
【００３２】
まず通信開始前の初期値は、アプリケーション全体の処理性能として要求帯域を採用する。これはアプリケーション全体が処理するデータによって異なる。例えばユーザが１２８Ｋｂｐｓの音楽を視聴したいのであれば、アプリケーションは１２８Ｋｂｐｓを要求帯域とし、１Ｍｂｐｓの動画を再生したいのであれば１Ｍｂｐｓを要求帯域とする。また、アプリケーションによっては予めユーザが手動で帯域値を設定できる場合がある。この場合はその値を要求帯域とする。
【００３３】
しかしながら、上記初期値は、理論値や或いは希望値であるため、前述の通り過大な値であることが考えられる。そこで上記１）〜５）のパラメータを用いて実際の性能を測る。また、実際の性能は時々刻々変化することから、あるタイミングで上記パラメータをサンプリングすることにより、状況に応じた適切な帯域を要求する。そのサンプリング期間(s)をソフトウェア性能リストへ書き込む。
【００３４】
初めに、通信前のアプリケーションのＣＰＵ使用率（１）を抽出しておく。次に通信開始時の総ＩＯサイズを累計ＩＯサイズとしてソフトウェア性能リストへ追加し、現在のアプリケーションのＣＰＵ使用率（２）を随時モニタリングしておく。ここで、通信前のアプリケーションのＣＰＵ使用率（１）＜現在のアプリケーションのＣＰＵ使用率（３）となっている区間がアプリケーションがデータ処理を行っている時間であり、通信前のアプリケーションのＣＰＵ使用率（１）＝現在のアプリケーションのＣＰＵ使用率（２）となる時がアプリケーションのデータ処理が終わった時である。この時点での総ＩＯサイズと通信開始時のＩＯサイズ、すなわち累計ＩＯサイズとの差分が、今回の通信でアプリケーションが処理したデータサイズであり、総バッファ量と累計バッファ量の差分が、今回の通信でバッファとして蓄えることが可能であったデータサイズである。
【００３５】
そして通信前のアプリケーションのＣＰＵ使用率（１）＜現在のアプリケーションのＣＰＵ使用率（２）となっている期間を処理時間(s)とすると、通信中のアプリケーション本体の処理性能(ｂｐｓ)は次式で与えられる。
((総ＩＯサイズ)―(累計ＩＯサイズ) )÷(処理時間)  (以下「アプリケーション処理帯域」に関する式と称する。)
【００３６】
また、通信中のバッファの処理性能（ｂｐｓ）は次式で与えられる。
（総バッファ量）―（累計バッファ量）÷（処理時間）  （以下「バッファ処理帯域」に関する式と称する。）アプリケーション全体の処理性能（ｂｐｓ）は次式で与えられる。
（アプリケーション処理帯域）＋（バッファ処理帯域）  （以下「処理帯域」に関する式と称する。）
【００３７】
通信装置が通信を行う時間とアプリケーションが通信を行う時間は必ずしも一致しない。例えば、通信が終わった後もアプリケーションが処理しつづけていることも考えられるため、単純に情報処理装置が動いているか否かを観測すればよいのではない。通信開始から情報処理装置のＣＰＵ使用率を監視することで、アプリケーションが送受信を処理する時間が判明する。
【００３８】
初期値をモニタへ渡して通信が開始された後、サンプリング時間中パラメータの値を測定している。サンプリング時間が経過して再計算の時間がきたら上記処理帯域に関する式に基づいて計算を行い、掲載された処理帯域をソフトウェア性能リスト８（図１）に書き込む。そして、最終的に要求すべきアプリケーションの処理性能は、「(要求帯域)或いは(処理帯域)のうち小さい方」となる。以後、通信期間中は、サンプリング時間が来る度に処理帯域を再計算する。
【００３９】
２回目は、まず直前の処理帯域と今回の処理帯域とを比べる。直前の処理帯域とは、つまり通信前の要求帯域である。今回の処理帯域とはサンプリング時間が来て計算した処理帯域である。この二つの値のうち、小さいほうをアプリケーションの処理性能とし、ソフトウェア性能リストへ書き込む。
【００４０】
３回目以降は前回のアプリケーションの処理性能と今回のアプリケーションの処理性能を比較し、小さいほうを次の帯域要求の為のアプリケーションの処理性能とする。
そして帯域を要求するたびに、総ＩＯサイズ及び総バッファ量を累計ＩＯサイズ及び累計バッファ量としてソフトウェア性能リストへ書き出し、次のサンプリング時間までデータ処理を再開する。
【００４１】
また、もしＣＰＵの負担が重くなったなどの事情により、アプリケーションの処理できるデータ量が下がり、帯域の要求を少なくしないと処理できない場合には、次回の処理帯域は低くなる。この場合はそのまま今回の処理帯域をアプリケーションの処理性能とすればよい。
【００４２】
逆にＣＰＵの処理能力に余力ができ、アプリケーションがもっと多くのデータを処理できる可能性が出てきた場合、データ処理可能な増分を考慮して次回の処理帯域とする必要がある。この場合に備え、予め現在のその他のＣＰＵ使用率（３）も随時モニタリングしておく。この値が１００（％）ではないということはＣＰＵの処理性能をまだアプリケーションに割り当ることができることを意味する。
【００４３】
したがって、サンプリング時間が経過して再計算の時間がきたら、現在のアプリケーションのＣＰＵ使用率（２）＋現在のその他のＣＰＵ使用率（３）＝１００（％）となるようにアプリケーションの処理能力を上げる。パーセンテージからどれだけ処理帯域を増やしてもよいか計算できる。そして、最終的にはこの値と要求帯域のうち低い方がアプリケーションの処理性能となる。
【００４４】
（ｂ）ユーザ端末ハードウェア性能(bps)の算出方法
次にハードウェアの処理性能を求める。便宜上ユーザ端末と通信装置とのそれぞれに分けて説明する。まずユーザ端末ハードウェア性能に関しては、ユーザ端末搭載のＣＰＵやＲＯＭ、ＲＡＭ、ハードディスクへのアクセス速度やグラフィクスカードの処理性能等の性能は、上記（ａ）の算出方法の際に考慮されているため、ユーザ端末ハードウェア性能は、バス帯域幅(bps：以下「バス幅」と称する)となる。これをハードウェア性能リスト(図２（ｂ）参照)に加える。また、前述のようにサンプリング時間毎に再測定を行う。
【００４５】
（ｃ）情報処理装置ハードウェア性能(bps)の算出方法
上記（ａ）の説明と同じように、本実施の形態を適用する度に情報処理装置のハードウェアを改造し直に実行速度を測るのは現実的ではない。そこで、情報処理装置のハードウェアパラメータも、ＯＳから提示されている以下のパラメータを抽出し、ハードウェア性能リストへ書き加える。
１）NIC(Network Interface Card)の送受信サイズ(byte：以下「総送受信サイズ」とする。)
２）通信方式の規格上の理論値(bps、初期値：以下規格帯域とする)
尚、上記総送受信サイズは起動時からの累計の値をとる。
【００４６】
まず通信開始前の初期値は通信装置の処理性能として規格帯域を採用する。これは通信方式や通信装置の規格によって決まる。例えば１００Ｍｂｐｓの有線ネットワークであれば１００Ｍｂｐｓを規格帯域とし、１１Ｍｂｐｓの無線ネットワークであれば１１Ｍｂｐｓを規格帯域とする。また、通信装置によっては、予めユーザが手動で帯域値を設定できる場合がある。この場合はその値を規格帯域とする。
【００４７】
次にソフトウェア性能の計算と同様に、サンプリング時間になると実際の処理性能を求める。そのためには、ある時間、送受信サイズを観測する必要がある。まず通信開始前の送受信サイズを累計送受信サイズとし、ハードウェア性能リストへ書き加える。ある一定期間観測した後の総送受信サイズと累計送受信サイズとの差分が、今回の通信で通信装置が処理したデータサイズである。観測時間は、通信装置がユーザ端末とデータの送受信している時間、つまりバスをデータが流れている時間とすればよいため、これを通信時間(s)とすると、観測時間は、
((総送受信サイズ)―(累計送受信サイズ) )÷(通信時間)  (以下「NIC帯域」と称する。)
で表わされる。この値をハードウェア性能リスト（図１）に書き加える。そして、最終的に要求すべき通信装置ハードウェア性能は、「(規格帯域)或いは(NIC帯域)のうち小さい方」となる。
【００４８】
以後、通信中はサンプリング時間が来る度にNIC帯域を再計算するが、２回目以降は直前のNIC帯域と今回のNIC帯域とを比べて高い方を規格帯域との比較対象とする。例えば、今回のNIC帯域が前回の値より低いということは、再計算してみたところ通信装置に負荷がかかったり、ネットワークに障害が発生したなどの事情により通信装置の処理できるデータ量が下がり、より少ない帯域を要求する必要が生じたということである。今回のNIC帯域が前回の値より高いということは、再計算してみたところ通信装置に負荷が少なくなったり、ネットワークの処理が軽くなったなどの事情により通信装置の処理できるデータ量が上がり、より多い帯域を要求することができるようになったことを意味する。
【００４９】
上記のように（ａ）〜（ｃ）の値のうちから、モニタはボトルネックの割り出しを行う。上記３つの値のうち一番低い値がユーザシステムにおけるボトルネックであり、これ以上の値を要求しても、ソフトウェアやハードウェアの性能限界からユーザシステム全体としては処理しきれない。従って、モニタはこの値を通信装置へ渡し、通信装置はネットワークへ帯域を要求する際に、この値に基づいて帯域要求を行う。以上のようにしてユーザシステムに適した帯域をネットワークに要求する。これによって、ユーザ端末や通信装置がネットワーク全体の帯域処理性能より低い場合、ネットワークの帯域を効率的にユーザ端末に割り当てることが可能になる。
【００５０】
また、本実施例ではネットワーク上での帯域制御に関しては述べていないが、上記の通りに決定した要求帯域値が、ユーザ端末から管理サーバまでの経路上のネットワーク全体で最も低い帯域値よりも低い場合にのみ、ネットワークへ要求すればよい帯域値であることは明白である。つまり、ネットワーク全体の帯域幅よりも大きな帯域を要求しても無駄だからである。
【００５１】
尚、一度得られた処理帯域やＮＩＣ帯域は、次の接続機会においてもソフトウェア、ハードウェアの状況が変わらなければ、最初の通信時に初期値のみを要求する帯域とするのではなく、既にソフトウェア性能、ハードウェア性能リストに記載してある値と初期値とを比較することで、最初の通信時から適切な帯域を要求できる。
【００５２】
また、例えば前回までは動画再生のアプリケーションと１００Ｍｂｐｓの有線ネットワークの通信装置を使用していたとして、今回はアプリケーションが変わらないが無線ＬＡＮの通信装置を使おうとした場合、最初の帯域要求の際、ソフトウェア性能には前回使用した動画再生アプリケーションの処理帯域を用いることができる。すなわち、ソフトウェアとハードウェアとのそれぞれに関して独立して値を使用することができる。このように、通信中もソフトウェア及びハードウェアの性能を測定することにより、通信以外にユーザ端末が何らかの処理を行って各パラメータが変動しても、その都度適切な値を補正することができる。
【００５３】
また、上記リストは、ユーザ端末のハードウェア構成や使用アプリケーション、通信装置が変更された場合には、上記パラメータを抽出し直すことで、新たにリストに書き加えて使用可能である。
【００５４】
次に、本発明の実施の形態による情報処理装置に関する動作の説明を図面を参照しつつ説明する。
【００５５】
（ａ）ソフトウェア性能測定フロー
図３は、ソフトウェアの性能を測定する処理の流れを示すフローチャート図である。図３に示すように、本実施の形態によるシステムは、通信準備があるまで待機する(ステップＳ１０１)。通信準備段階に入ると、まずユーザ端末からアプリケーションとその要求帯域、サンプリング時間を抽出し、さらにユーザ端末のＯＳが提示するハードウェアパラメータの中から、総ＩＯサイズ、通信前のアプリケーションのＣＰＵ使用率、通信前のＣＰＵ全体の使用率を抽出し、ソフトウェア性能リストを作成する(ステップＳ１０２)。
【００５６】
以前に上記アプリケーションを使用して通信を行っており、処理帯域を計算しているかどうかを判断(ステップＳ１０３)し、処理帯域がソフトウェア性能リストに記載されていない場合は通信中か否かを判断する(ステップＳ１０４)。以前に、上記アプリケーションを使用していて、処理帯域が記載されている場合にはステップＳ１１１に進む。まだ通信していない場合には、要求帯域をモニタに渡し(ステップＳ１０５)、通信開始を待つ(ステップＳ１０６)。通信中であれば、通信中のアプリケーションのＣＰＵの使用率とその他のＣＰＵ全体の使用率を常に測定し、ソフトウェア性能リストに追加してこの値を随時更新する(ステップＳ１０７)。  通信開始時からサンプリング時間の時間が経ち、ソフトウェア性能の再計算時刻となると(ステップＳ１０８)、上記通信中のアプリケーションのＣＰＵ使用率と通信前のアプリケーションのＣＰＵ使用率とから、処理時間を算出してリストに追加し(ステップＳ１０９)、その他のＣＰＵ使用率とアプリケーションのＣＰＵ使用率を考慮に入れて処理帯域を算出 (ステップＳ１１０、詳細は後に述べる。)した後、その処理帯域と処理帯域との前回値を比較し、大きい方と要求帯域とを比較して、小さい方の値をソフトウェアの処理性能としてモニタに渡す(ステップＳ１１１)。そして、総ＩＯサイズ、総バッファサイズの前回値を累計ＩＯサイズ、累計バッファサイズとしてソフトウェア性能リストに追加する(ステップＳ１１２)。サンプリング時間が経過する前に通信が終了した場合(ステップＳ１１３)、ソフトウェア性能の測定を終える（ｅｎｄ）。
【００５７】
（ｂ）ユーザ端末ハードウェア性能の測定フロー
図４は、ユーザ端末ハードウェア性能の測定処理の流れを示すフローチャート図である。図４に示すように、システムは、通信準備があるまで待機している(ステップＳ２０１)。通信準備段階に入ると、ユーザ端末からバス幅を抽出し、ハードウェア性能リストに追加し(ステップＳ２０２)、バス幅をモニタに渡す（ステップＳ２０３）。次いで、現在通信中であるか否かを判定し（ステップＳ２０４）、現在通信していない場合には、通信開始を待つ(ステップＳ２０５)。通信開始からサンプリング時間分時間が経過し、ユーザ端末のハードウェア性能の再計算時間となったか否かを判断し(ステップＳ２０６)、再計算時間になった場合には、バス幅を再度測り直した後に(ステップＳ２０７)、バス幅をモニタに渡す（ステップＳ２０３）。ステップＳ２０８においてサンプリング時間が経つ前に通信が終了した場合には、ユーザ端末ハードウェア性能の測定を終える（ｅｎｄ）。
【００５８】
（ｃ）通信装置のハードウェア性能の測定フロー
図５は、本実施の形態による通信装置におけるハードウェア性能の測定処理の流れを示すフローチャート図である。図５に示すように、システムは通信準備があるまで待機している(ステップＳ３０１)。通信準備段階に入ると（Ｙ）、まずユーザ端末から送受信サイズとサンプリング時間を、通信装置から規格帯域を抽出し、ハードウェア性能リストに追加する(ステップＳ３０２)。次いで、以前に上記通信装置を使用して通信を行っており、ＮＩＣ帯域を計算済みか否かを判断し(ステップＳ３０３)、もし以前に上記通信装置を使用しており、ＮＩＣ帯域が記載されている場合には、ステップＳ３１１に進む。ＮＩＣ帯域がハードウェア性能リストに記載されていない場合には、通信中か否かを判断する(ステップＳ３０４)。まだ通信していない場合には、規格帯域をモニタに渡し(ステップＳ３０５)、通信開始を待つ(ステップＳ３０６)。通信中には通信時間を常に測定している(ステップＳ３０７)。
【００５９】
通信開始時からサンプリング時間分の時間が経ったか否かを判断し（ステップＳ３０８）、通信装置のハードウェア性能の再計算時刻となっていれば（Ｙ）、通信時間をリストに追加(ステップＳ３０９)し、ＮＩＣ帯域を算出(ステップＳ３１０)した後、そのＮＩＣ帯域とＮＩＣ帯域の前回値とを比較し、大きい方と規格帯域とを比較し(ステップＳ３１１)、小さい方の値を通信装置ハードウェア性能としてモニタに渡す(ステップＳ３１２)。そして、送受信サイズの今までの値を累計送受信サイズとしてハードウェア性能リストに追加する。(ステップＳ３１２)。ステップＳ３０８において再計算時間になっていなければ、ステップＳ３１３に進む。サンプリング時間分の時間が経つ前に通信が終了した場合(ステップＳ３１３)は、ソフトウェア性能の測定を終える（ｅｎｄ）。ステップＳ３１３において通信終了でなければ（Ｎ）、ステップＳ３０７に戻る。
【００６０】
（ｄ）モニタ処理フロー
図６は、モニタ処理の流れを示すフローチャート図である。図６に示すように、システムは通信準備があるまで待つ(ステップＳ４０１)。通信準備が整ったら、ソフトウェア、ユーザ端末、通信装置から渡された帯域を比較し、その中から一番小さい値をネットワークに要求する帯域として通信装置に通知する(ステップＳ４０３)。通信中は、サンプリング時間分だけ待って、要求する帯域を再び計算する時刻となったら、ソフトウェア、ユーザ端末、通信装置から渡された帯域を比較し、一番小さい値をネットワークに要求する帯域として通信装置に通知する(ステップＳ４０６)。すなわち、ステップＳ４０３からステップＳ４０４に進み、再計算時間になったか否かを判断し、再計算時間になった場合には、ステップＳ４０５に進む、ステップＳ４０２と同様の処理を行い、ステップＳ４０６に進む。そして、ステップＳ４０６において通信装置に要求する帯域値を通知し、また、ステップＳ４０４で再計算時間になっていなければ（Ｎ）、いずれの場合も、サンプリング時間分の時間が経つ前に通信が終了したか否かをステップＳ４０７において判断し、通信を終了していれば（Ｙ）ソフトウェア性能の測定を終える（ｅｎｄ）。通信終了していなければ（Ｎ）、ステップＳ４０４に進み再計算時間になったか否かを判断する。これにより、通信におけるボトルネックとなる値を調査することができる。
【００６１】
（ｅ）処理帯域の算出フロー
図７は、ソフトウェア性能測定の際の処理帯域の算出フローである。図３のステップＳ１０９の処理後に、（総ＩＯサイズ−累計ＩＯサイズ）÷（処理時間）をアプリケーション処理帯域１）として計算する（ステップＳ５０１）。次に現在のアプリケーションのＣＰＵ使用率（％）とその他のＣＰＵ使用率（％）を測定し、合計した値が１００（％）に達していなければ（ステップＳ５０２）（Ｙ）、次回のアプリケーション使用率を（現在のアプリケーションのＣＰＵの使用率）＋（現在のその他のＣＰＵ使用率）＝１００％隣るように次回のアプリケーションＣＰＵ使用率を計算し（ステップＳ５０３）、このＣＰＵ使用率の増加分を考慮して、上記１）のアプリケーション処理帯域を（アプリケーション処理帯域）×（次回のアプリケーションのＣＰＵ使用率）÷（現在のアプリケーションのＣＰＵ使用率）の値に変更して再計算する（ステップＳ５０４）。再計算後、或いは合計した値が１００（％）に達していれば（Ｙ）、バッファがあるかどうか調査する（ステップＳ５０５）。バッファがある場合は（Ｙ）、（総バッファサイズ−累計ＩＯバッファサイズ）÷（処理時間）をバッファ処理帯域として計算し（ステップＳ５０６）、バッファがない場合は（Ｎ）バッファ処理帯域を０にする（ステップＳ５０７）。最後に処理帯域を（アプリケーションの処理帯域）＋（バッファ処理帯域）として計算して（ステップＳ５０８）その値を図３のステップＳ１１１へ渡す。
【００６２】
次に、本発明の実施の形態による情報処理装置に関する一般的な動作の概要を図８を参照しつつ説明する。図８（ａ）に示すように、まず通信開始前にモニタがユーザ端末を走査し、要求する帯域を決定する。アプリケーションは４Ｍｂｐｓの動画再生を要求している。この時、バス帯域の空きが１６Ｍｂｐｓと余裕があり、通信装置の規格値も１１Ｍｂｐｓと要求の４Ｍｂｐｓより大きい為、モニタ４２は４Ｍｂｐｓの帯域を要求帯域として決定し、この値を管理サーバ４３に送信する（４Ｍｂｐｓの動画再生を要求する）。そして管理サーバ４３は、上記ユーザ端末へ４Ｍｂｐｓを割り当てる。ここで、ユーザ端末にはＣＰＵ４０−１と、ソフトウェア（アプリ４０−３、ＯＳ４０−２）が設けられている。  ところが図８（ｂ）に示す通り、実際にある程度サンプリング期間を観測してみたところ、アプリケーション４０−２は１．５Ｍｂｐｓしか処理できていなかったとする。これはＣＰＵ４０−１が上記アプリケーション４０−２以外にも処理をしていて使用率が１００％に達してしまい、これ以上アプリケーションの処理能力が上がらなかったことが原因と考えられる。この状況をモニタ４２が検出し、割り当てられた４Ｍｂｐｓの帯域を使い切れていないことを判断して管理サーバ４３に帯域を要求する。このとき通信装置の実効値が４Ｍｂｐｓ、バス帯域の空きが１２Ｍｂｐｓであるため、要求する帯域値は１．５Ｍｂｐｓとなる。
【００６３】
次に、図８（ｃ）のようにＣＰＵ４０−１の性能に余裕が出てきてアプリケーション４０−３の処理能力が上がる場合には、モニタ４２はアプリケーション４０−３のＣＰＵ４０−１の使用率とその他のＣＰＵ使用率を考慮し、帯域の増加の要求を管理サーバ４３に行う。図８（ｃ）の場合では、ＣＰＵ４０−１はアプリケーション４０−３へあと２０％分（いままでの２０％と合わせて計４０％）の性能を割り当ることが出来る。つまり、１．５Ｍｂｐｓだった処理能力を２倍にすることが可能になる。したがって、モニタ４２は３Ｍｐｂｓの帯域を管理サーバ４３に要求する。以上、図８（ａ）〜（ｃ）のように管理サーバ４３はユーザ端末へ帯域を動的に割り当て、効率のよい帯域管理を行う。
【００６４】
次に、本実施の形態による通信装置における応用例について説明を行う。まず、第１応用例について説明する。ユーザ端末の構成によっては、上記のアプリケーションの管理するバッファとは別にＦＩＦＯやキャッシュ等、送受信するデータを一時格納する領域を持つ装置がある。これを、以下において便宜上、キャッシュ(byte)と呼ぶ。このキャッシュを持つことにより、ユーザの使用するアプリケーションやユーザシステムの処理能力が低い場合でも、キャッシュ分だけ大きな帯域を要求して処理を行うことができる。このキャッシュを有するシステムを、上記の状況で本実施の形態による通信装置に適用した場合は、ユーザ端末におけるハードウェア処理能力の計算式を以下のように表すことができる。
(バス幅)＋(キャッシュ)÷(通信時間)
【００６５】
また、このとき、バッファにデータを格納している間はアプリケーションが全く動作しない場合がある。この場合はアプリケーションの処理帯域が０となってしまうが、実際は通信を続ける必要がある。このような機能を利用できる場合、ハードウェア性能リストに追加フィールドを設け、例えばここに‘１’を記載した時はアプリケーションの処理帯域を無視して帯域計算をする、などのようにすればよい。
【００６６】
尚、キャッシュは、専用のハードウェア機構により実現しても良いし、仮想メモリのように上記アプリケーション或いはＯＳ等ソフトウェアにより管理してもよい。
【００６７】
次に本実施の形態による情報処理装置の第２応用例について説明する。今回は便宜上ユーザの要求帯域以上の帯域は要求しないこととしていたが、強力なＣＰＵを搭載していたりしてアプリケーションの性能がボトルネックにならない場合、例えばＦＴＰ(File Transfer Protocol)ソフトなどは割り当てられた帯域が多ければ多いほどより多くのデータを処理できる場合がある。それをユーザが知らずに要求帯域を設定していることも考えられる為、その場合にはユーザの要求帯域を無視して処理帯域をアプリケーションの処理性能としてもよい。
【００６８】
次に本実施の形態による情報処理装置の第３応用例について説明する。本実施の形態においては、説明の便宜上、サンプリング時間をソフトウェア、ハードウェアとも同じ値にしたが、個別の値でもよい。例えばＣＰＵがアプリケーションを処理する時間が長い期間にわたってあまり変化しないが、情報処理装置のデータをやり取りする時間が間欠的な場合などは、ソフトウェアのサンプリング時間を長めに取り、ハードウェアのサンプリング時間を短めに取るなど、変化の度合いに応じて変化が大きい方のサンプリング時間を短めにすることにより、変化へ追従させつつ、無駄なサンプリングを行わないようにすることができる。
【００６９】
次に、第４応用例について説明する。本発明の実施の形態おいては、サンプリング時間が経過したら各種処理能力を再計算し、その都度帯域幅をネットワークに再要求しているが、その第３応用例として、要求帯域幅がある量以上変化した場合のみネットワークに再要求するようにしてもよい。この場合には、(今回の要求帯域)÷(前回の要求帯域)の式に基づいて計算を行い、これを係数ａとし、例えばａの値がある許容範囲として決められている０．７＜ａ＜１．３の範囲を超えた場合に、要求帯域幅を再要求する、というようにすればよい。第３応用例は、ユーザシステムの実効性能がある量以上増減した場合にのみ帯域を要求するものであり、ユーザシステムの微細な性能変化に関してはある程度又は完全に考慮対象外におくものである。この応用例は、例えば帯域の割当てを切り替える際に通信が一時途切れてしまう情報処理システムの場合に、ユーザシステムの実効性能が多少上下したとしても一度割当てられた帯域を保持しつづける方が都合がよい場合などに有効である。
【００７０】
以上、本実施の形態による情報処理技術によれば、ユーザが使用するアプリケーションやユーザ端末及び通信装置の実際の性能を考慮して要求する帯域を決定することにより、図７（ｃ）に示すように、ユーザの要求や規格などにより決められた帯域値が、実状に比べて無駄に大きい値になってしまう場合に、より効率的な帯域を要求することができるという利点がある。また、ソフトウェアやハードウェアの状況を適宜モニタリングして帯域値に反映させることにより、図７（ｃ）のように要求する帯域を最適化することができる。
【産業上の利用可能性】
【００７１】
本発明は、通信機能を有する情報処理装置、携帯端末、携帯電話機に適用することができる。また、本発明の方法をコンピュータに実行させるためのプログラムも本発明の範疇に入る。
【図面の簡単な説明】
【００７２】
【図１】図１（ａ）は、本発明の実施の形態による情報処理装置とネットワークとを含む通信システムの構成例を示すブロック図であり、図１（ｂ）は、情報処理装置内のモニタの詳細な構成例を示すブロック図である。
【図２】本発明の実施の形態によるユーザシステムの性能リストであり、図２（ａ）はソフトウェア性能リスト、（ｂ）はハードウェア性能リストである。
【図３】本発明の実施の形態によるユーザシステムにおけるソフトウェア処理性能の一般的な測定処理の流れを示すフローチャート図である。
【図４】本発明の実施の形態によるユーザシステムにおけるユーザ端末のハードウェア処理性能の測定処理の流れを示すフローチャート図である。
【図５】本発明の実施の形態によるユーザシステムにおける情報処理装置のハードウェア処理性能の測定処理の流れを示すフローチャート図である。
【図６】本発明の実施の形態によるユーザシステムにおける要求帯域決定処理の流れを示すフローチャート図である。
【図７】本発明の実施の形態によるユーザシステムにおけるＣＰＵの使用率の測定処理の流れを示すフローチャートである。
【図８】本発明の実施の形態による一般的な動作例を示す図である。
【図９】従来技術（一般的な従来技術と特許文献１に記載の技術）と本実施の形態による技術との各種パラメータの対比図である。
【符号の説明】
【００７３】
１…ユーザ端末、２…情報処理装置、３…モニタ、4…表示装置、５…中継装置、６…管理サーバ、７…ソフトウェア性能リスト、８…ハードウェア性能リスト、９…要求帯域計算器、１０…アプリケーション、１１…要求帯域(bps)、１２…総ＩＯサイズ(byte)、１３…累計ＩＯサイズ(byte)、１４…総バッファサイズ(byte)、１５…累計バッファサイズ(byte)、１６…通信前のアプリケーションのＣＰＵ使用率（％）、１７…通信中のアプリケーションのＣＰＵ使用率(%)、１8…通信前のその他のＣＰＵ使用率（％）、１９…通信中のその他のＣＰＵ使用率(%)、２０…処理時間(s)、２１…処理帯域(bps)  括弧の中は前回の値である、２２…サンプリング時間(s)、３０…通信装置、３１…バス幅(bps)、３２…規格帯域(bps)、３３…送受信サイズ(byte)、３４…累計送受信サイズ(byte)、３５…通信時間(s)、３６…NIC帯域(bps)、  括弧の中は前回の値、３７…サンプリング時間(s)。
【図１】
2005328508.tif 000003
【図２】
2005328508.tif 000004
【図３】
2005328508.tif 000005
【図４】
2005328508.tif 000006
【図５】
2005328508.tif 000007
【図６】
2005328508.tif 000008
【図７】
2005328508.tif 000009
【図８】
2005328508.tif 000010
【図９】
2005328508.tif 000011