(57)【特許請求の範囲】
【請求項１】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満となるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、
関係式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）
により前記保証帯域Ｒを見積もることを特徴とするアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項２】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、
最初の保証帯域Ｒの設定値では前記ＩＰネットワークに受け付けられなかった場合に、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、
前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲において  （Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ（ｎ＞０）  の刻み幅で減少させて見積もり、前記ＩＰネットワークとネゴシエーションすることを特徴とするアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項３】
請求項１記載のパラメータ決定方法によってアプリケーション開始時における前記保障帯域Ｒを見積り、
該保障帯域Ｒが前記ＩＰネットワークに受け付けられない場合に、請求項２記載のパラメータ決定方法によって前記保障帯域Ｒを見積り、前記ネゴシエーションにより、前記保障帯域Ｒを逐次変更して再設定する
ことを特徴とするアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項４】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、
前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ＊を測定し、該転送遅延時間Ｄ＊が前記要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｄ＊＞Ｄｒｅｑ）が  Ｐｒ（Ｄ＊＞Ｄｒｅｑ）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲で増減させて調整することを特徴とするアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項５】
請求項１〜３の何れかの項記載のパラメータ決定方法によって前記アプリケーション開始時における保障帯域Ｒを決定し、
前記アプリケーションを動作させながら、請求項４パラメータ決定方法によって前記保障帯域Ｒを調整する
ことを特徴とするアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項６】
前記アプリケーションの動作時にトラヒックを測定し、前記統計的トラヒック特性を表現するパラメータＸｋ  を、測定時点での設定値Ｘ０ｋと測定されたトラヒックのデータから算出される統計値Ｘ＊ｋをもとにして、  Ｘｋ＝（１−γｋ）Ｘ０ｋ＋γｋＸ＊ｋ（０≦γｋ≦１）  に更新して保持する手続きを前記アプリケーションが有することを特徴とする請求項１〜５の何れかの項記載のアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項７】
前記統計的トラヒック特性として漸近分散定数ｃ２  および規格化３次モーメントｍ３  を採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定される一般分布トラヒック入力のＧＩ／Ｄ／１待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴とする請求項１〜６の何れかの項記載のアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項８】
前記統計的トラヒック特性として分散平均比ａと自己相似性パラメータＨを採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定されるＦＢＭトラヒック入力の待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴とする請求項１〜６の何れかの項記載のアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法。
【請求項９】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満となるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、
関係式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により前記保証帯域Ｒを見積もる見積処理と
を前記端末内のコンピュータに実行させることを特徴とするＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【請求項１０】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、
最初の保証帯域Ｒの設定値が前記ＩＰネットワークに受け付けられなかったことを検出する要求受付判定処理と、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、
前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲において  （Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ（ｎ＞０）  の刻み幅で減少させて前記ＩＰネットワークとネゴシエーションする見積処理と
を前記端末内のコンピュータに実行させることを特徴とするＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【請求項１１】
請求項９記載の記録媒体に記録されたパラメータ決定プログラムに、
最初の保証帯域Ｒの設定値が前記ＩＰネットワークに受け付けられなかったことを検出する要求受付判定処理と、
前記ＩＰネットワークに要求する品質パラメータの保証帯域ＲをＲprob≦Ｒ≦Ｒbound の範囲において （Ｒbound−Ｒprob）／ｎ（ｎ＞０） の刻み幅で減少させて前記ＩＰネットワークとネゴシエーションする見積処理と
を加えたパラメータ決定プログラムを記録した記録媒体。
【請求項１２】
アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、
前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、
前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ＊を測定し、該転送遅延時間Ｄ＊が前記要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｄ＊＞Ｄｒｅｑ）が  Ｐｒ（Ｄ＊＞Ｄｒｅｑ）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲で増減させて調整する調整処理と
を前記端末内のコンピュータに実行させることを特徴とするＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【請求項１３】
請求項９〜１１の何れかの項記載の記録媒体に記録されたパラメータ決定プログラムに、
前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ*を測定し、該転送遅延時間Ｄ*が前記要求遅延Ｄreqを越える確率Ｐｒ（Ｄ*＞Ｄreq）がＰｒ（Ｄ*＞Ｄreq）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域ＲをＲprob≦Ｒ≦Ｒboundの範囲で増減させて調整する調整処理と
を加えたパラメータ決定プログラムを記録した記録媒体。
【請求項１４】
前記アプリケーションの動作時にトラヒックを測定するトラヒック測定処理と、
前記統計的トラヒック特性を表現するパラメータＸｋ  を、測定時点での設定値Ｘ０ｋと測定されたトラヒックのデータから算出される統計値Ｘ＊ｋをもとにして、Ｘｋ＝（１−γｋ）Ｘ０ｋ＋γｋＸ＊ｋ（０≦γｋ≦１）  に更新して前記アプリケーションに保持させる更新処理と
を前記端末内のコンピュータに実行させることを特徴とする請求項９〜１３の何れかの項記載のＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【請求項１５】
前記近似値算出処理は、
前記統計的トラヒック特性として漸近分散定数ｃ２  および規格化３次モーメントｍ３  を採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定される一般分布トラヒック入力のＧＩ／Ｄ／１待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出する
ことを特徴とする請求項９〜１４の何れかの項記載のＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【請求項１６】
前記近似値算出処理は、
前記統計的トラヒック特性として分散平均比ａと自己相似性パラメータＨを採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定されるＦＢＭトラヒック入力の待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴とする請求項９〜１４の何れかの項記載のＩＰ品質保証サービスのパラメータ決定プログラムを記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを経由して、相互につながっている端末間で動作するリアルタイムアプリケーションが、エンド−エンドのパケット転送遅延時間の保証を要求してＩＰ品質保証サービスを利用する際に、そのサービスを規定する品質パラメータである保証帯域の値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法に関するものである。
【０００２】
このパラメータ決定方法は、ユーザ自身が操作するＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）タイプのブラウザの１機能としての形態，ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の通信処理の１機能としての形態，アプリケーションプログラムの中に埋め込まれる形態，プログラミング言語のライブラリ関数の１機能などの形態で提供されることになる。
【０００３】
【従来の技術】
電話や放送，テレビ会議など、送信端末における入力デバイス（カメラやマイクなど）から連続的にサンプリングされるデータをネットワークを介して受信端末に転送して元の映像や音声に再生したり、送信端末上の記憶媒体からデータを周期的に読み取り、ネットワークを介して受信端末に転送して映像や音声に再生するようなエンド−エンドのパケット転送遅延時間の保証が必要なリアルタイムアプリケーションをインターネット上で利用することが検討されている。
【０００４】
しかし、現在のインターネットでは、品質を保証しないベストエフォートサービスしか提供していないので、パケットの転送経路上にふくそうルータがあると、損失や過大な遅延をもたらして再生情報が所定の品質を満たさない可能性があり、情報量の多い現在の放送メディアなみの品質は得られない。
Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）などでは、ルータにおけるパケット転送順序等を制御するパケットスケジューリングとして  Ｗｅｉｇｈｔｅｄ  Ｆａｉｒ  Ｑｕｅｕｅｉｎｇ（ＷＦＱ）などを採用し、アプリケーションフロー毎に帯域保証することにより、エンド−エンドのパケット転送遅延時間を保証するＩＰ品質保証サービスを提供することを検討している。
【０００５】
〔従来技術１〕
〈パケット転送遅延の上限を絶対保証する帯域（Ｒｂｏｕｎｄ）を算出する方法〉
ＩＰ品質保証サービスを規定している「インターネットドラフト」（Ｓ．Ｓｈｅｎｋｅｒ，Ｃ．Ｐａｒｔｒｉｄｇｅ  ａｎｄ  Ｒ．Ｇｕｅｒｉｎ、”Ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｏｆ  Ｇｕａｒａｎｔｅｅｄ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ，”Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ、  Ｆｅｂ．，１９９７．）では、送出トラヒックの上限を与えるトラヒックパラメータ（ＴＳｐｅｃ：平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）をもとにしたエンド−エンドパケット転送遅延時間の上限値Ｄｍａｘを与える式から、エンド−エンドの要求遅延Ｄｒｅｑを満足するよう経由ルータにおける保証帯域Ｒを見積もる方法が提案されている。アプリケーションは品質パラメータ（ＲＳｐｅｃ）として、この保証帯域Ｒを指定する。
【０００６】
これによると、経由するルータ（ｉ）におけるパケットスケジューリングによる遅延時間の上限値は、流体近似によって見積もられる項と、パケットサイズを考慮した場合に保証帯域（Ｒ）に依存して発生する項  （Ｃｉ／Ｒ）と、保証帯域に依存しない項  （Ｄｉ）に分けることができる。例えば、ルータのスケジューリングがＷＦＱならば、μ，ＭＴＵをそれぞれルータｉからの送出リンクの帯域，最大転送単位とすると、Ｃｉ＝Ｍ，Ｄｉ＝ＭＴＵ／μである。
【０００７】
複数ルータを経由する場合、フローの経由する全てのルータのＣｉ，Ｄｉの項をそれぞれ加算すれば、エンド−エンド端末間のパケット転送遅延時間の上限値を見積もることが可能である。ここで、フローの経由する全てのルータについて加算したＣｉ，ＤｉをそれぞれＣｔｏｔ，Ｄｔｏｔと表し、両者の組をＡｄｓｐｅｃと呼ぶ。
【０００８】
フローを設定する端末上のアプリケーションにこのＡｄｓｐｅｃが事前に通知されていれば、送出トラヒックの上限を与える  ＴＳｐｅｃを考慮して、エンド−エンド端末間のパケット転送遅延時間の上限値は、
【数１】
0003585700.tif 000002
の関係式から見積もることができる。逆に、アプリケーションの要求するエンド−エンド端末間のパケット転送遅延時間を要求遅延  Ｄｒｅｑとすると、これを絶対保証するために必要な帯域Ｒは、上式においてＤｍａｘ＝Ｄｒｅｑとすれば得られる。後述する方法で見積もった値と区別するために、この式で見積もった保証帯域ＲをＲｂｏｕｎｄ  と記述する。このＲｂｏｕｎｄは、ＴＳｐｅｃの制約のもとで最悪のトラヒックを想定した場合でも要求遅延時間を保証する帯域であり、保証帯域の上限値になる。
【０００９】
そして、インターネットドラフトで提唱されているパラメータ見積もり方法を実現するための実施形態は図１のようになる。すなわち、受信端末１に設けられた上限値Ｒｂｏｕｎｄ算出部２  は、アプリケーション本体３から要求遅延ＤｒｅｑとＴＳｐｅｃを受け取り、ネットワーク４からＣｔｏｔとＤｔｏｔを受け取る。そしてこれらをもとに、前述した算出式でＲ＝Ｒｂｏｕｎｄ  を算出し、結果をアプリケーション本体３に戻す。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの設定をネットワーク４に依頼する。フローが設定されれば送信端末５からデータが送信される。
【００１０】
〔従来技術２〕
〈パケット転送遅延を確率αで保証する帯域の近似値（Ｒｐｒｏｂ）を算出する方法〉ネットワークにおいて、アプリケーションフローが経由する各ルータで、そのアプリケーションのために一定の帯域が保証されていて、他のフローから完全に分離されている場合、ネットワーク部分は処理率が保証帯域の単一サーバで近似できる。そこで、何らかの入力トラヒックモデルを仮定すれば、保証帯域Ｒを使って、エンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑ  を越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）  を厳密にまたは近似的に解くことができる。これを利用して、ユーザやアプリケーションにとってそれよりも小さければ支障がない確率Ｐｒ（Ｗ＞Ｄｒｅｑ）の値をαとすれば、関係式Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αから必要帯域の近似値Ｒｐｒｏｂ＝Ｒを見積もることができる。
もっとも、仮定したトラヒックモデルが実際のトラヒックを表現できない場合や、モデルによっては近似解しか得られない場合があるので、ここで見積もった近似値Ｒｐｒｏｂにはある程度の誤差が含まれる。
【００１１】
ここで、トラヒックモデルとして一般的に利用されている２状態  Ｍａｒｋｏｖ  ｍｏｄｕｌａｔｅｄ  Ｐｏｉｓｓｏｎ  ｐｒｏｃｅｓｓ  （ＭＭＰＰ）を採用すると、そのモデルパラメータは高負荷／低負荷状態の各継続時間と各状態の負荷になる（例えば、Ｈ．Ｈｅｆｆｅｓ  ａｎｄ  Ｄ．Ｍ．Ｌｕｃａｎｔｏｎｉ，”Ａ  Ｍａｒｋｏｖ  Ｍｏｄｕｌａｔｅｄ  Ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ  ｏｆ  Ｐａｃｋｅｔｉｚｅｄ  Ｖｏｉｃｅ  ａｎｄ  Ｄａｔａ  Ｔｒａｆｆｉｃ  ａｎｄ  Ｒｅｌａｔｅｄ  Ｓｔａｔｉｓｔｉｃａｌ  Ｍｕｌｔｉｐｌｅｘｅｒ  Ｐｅｒｆｏｒｍａｎｃｅ，”ＩＥＥＥ  Ｊｏｕｒｎａｌ  ｏｎ  Ｓｅｌｅｃｔｅｄ  Ａｒｅａ  ｉｎ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、Ｖｏｌ．４、Ｎｏ．６、Ｓｅｐｔ．，１９８６．を参照）。これらのパラメータは、アプリケーションが直接測定できる統計量からは簡単には変換できない。また、このモデルを解く場合、ラプラス変換と反復計算の必要があり数値解の算出に時間がかかるという問題がある。
【００１２】
本方法によるパラメータ見積もり方法を実現するための実施形態は図２のようになる。なお、同図において図１と同じ構成要素には同一の符号を付してある。受信端末１に設けられた確率的値Ｒｐｒｏｂ算出部６は、アプリケーション本体３から要求遅延Ｄｒｅｑ  ，その超過を許容する確率α，ＴＳｐｅｃ  の平均レートｒをそれぞれ受け取る。そして、これらと自身で保持しているトラヒックの統計的性質をもとに、前述した算出式でＲ＝Ｒｐｒｏｂを算出し、結果をアプリケーション本体３に戻す。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの設定をネットワーク４に依頼する。フローが設定されれば送信端末５からデータが送信される。
【００１３】
【発明が解決しようとする課題】
〔課題１〕ＴＳｐｅｃから見積もったＲ＝Ｒｂｏｕｎｄでは過剰。
実際のアプリケーションは、申告したトラヒックパラメータ（ＴＳｐｅｃ）  で規定される最悪トラヒックを生成することはない、つまり、実際のトラヒックはＴＳｐｅｃ  よりも少ないので、要求遅延ＤｒｅｑからＴＳｐｅｃの最悪トラヒックを想定して算出した上限値Ｒｂｏｕｎｄを保証帯域Ｒとして採用すると、遅延時間が要求遅延Ｄｒｅｑよりも必要以上に小さくなることが想定される。言い換えると、保証帯域Ｒが大きく見積もられてしまうという問題がある。このことはネットワーク資源の無駄遣いというだけではなく、例えばネットワークの料金体系が帯域に比例して高くなる場合、コスト面でも無駄になる。
【００１４】
〔課題２〕トラヒックの統計量から見積もったＲ＝Ｒｐｒｏｂでは低精度。
トラヒックの統計量を利用して、要求遅延Ｄｒｅｑ  をαの確率で満たすように、近似式によって算出した近似値Ｒｐｒｏｂを保証帯域Ｒとして採用すると、実際のトラヒックと採用したトラヒックモデルとの近似の精度と、保証帯域算出式の近似の程度によって、得られる遅延時間の要求遅延Ｄｒｅｑからのずれが大きくなる。
【００１５】
〔課題３〕フロー設定パラメータをネゴシエーション（再申告）する場合、Ｒの選択指針がない。
フローが受け付けられなかった場合、ＲＳｐｅｃ  のパラメータをネットワークとネゴシエーションする必要があるが、通常、アプリケーションの採用するＲＳｐｅｃ  パラメータは一度決めると固定的であり、変更できるとしても変更可能な範囲や変更指針が何もないので、ユーザが試行錯誤で適当な値に変更するしかない。
【００１６】
〔課題４〕最初のフロー設定パラメータには見積もり誤差がある。
フロー設定の際のＲＳｐｅｃ  パラメータの見積もりには誤差がある上、ユーザの使用状況が変化する可能性もあり、最初に設定したパラメータが最適になるとは限らない。また、アプリケーション動作中にこのパラメータをできるだけ最適な値に修正したいという要求があるが、パラメータを変更できるとしても変更可能な範囲や変更指針が何もないので、ユーザが試行錯誤で適当な値に変更するしかない。
【００１７】
〔課題５〕トラヒックの統計的性質はユーザの使い方によって変動する。
近似値Ｒｐｒｏｂを見積もるためのトラヒックの統計的性質は、そのアプリケーションが使われる環境やユーザの使い方によって変動する。
【００１８】
〔課題６〕ＭＭＰＰのパラメータは測定可能な統計量ではない。
一般的に使われているＭＭＰＰをトラヒックモデルとして採用するとした場合、測定可能な統計量からそのモデルパラメータ（高負荷／低負荷状態の各継続時間と各状態の負荷）に変換する必要がある。また、これを解く場合、ラプラス変換と反復計算の必要があり数値解の算出に時間がかかるという問題がある。
【００１９】
〔課題７〕バーストに特徴的な長さがない場合に対処できない。
ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）トラヒックなどでは、バーストに特徴的な長さがなく（ないしはバースト長が非常に広い幅にわたって存在し）、時間単位を変えると、分散が時間単位の増加に対してべき関数的に増加するという統計的性質を有することが知られている。一方、バースト長が有限のＭＭＰＰなどでは、ある程度時間単位が増加すれば分散は一定値に収束することが知られている。したがって、ＭＭＰＰなどのトラヒックモデルでは上記のような統計的特性を表現できないという問題がある。そこで、バーストに特徴的な長さがないトラヒックの場合の対処が課題となる。
【００２０】
本発明は上記の点に鑑みてなされたものであり、その目的は、以下に述べるアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法を提供することにある。
１．  過大，過小な割り当てをなくすことで、資源量の無駄を省いて帯域の見積もり誤差による品質劣化を解消する。
２．  アプリケーションがフロー設定パラメータをネゴシエーションする際の保証帯域の変更基準を定式化する。
【００２１】
３．  アプリケーション動作中におけるフロー設定パラメータをできるだけ最適な値に修正できるようにする。
４．  アプリケーションの動作環境やユーザの使い方によって変動する実際の統計的特性に追従して、アプリケーションの統計的トラヒック特性パラメータを変更できるようにして、利用条件による見積もり誤差を解消する。
５．  測定可能な統計量をモデルパラメータとして含み、数値解が容易に算出可能なトラヒックモデルを用いてＩＰ品質保証サービスのパラメータを決定する。
６．  バーストに特徴的な長さがないトラヒック入力にも対処可能なＩＰ品質保証サービスのパラメータ決定方法を提供する。
【００２２】
【課題を解決するための手段】
以上の課題を解決するために、請求項１記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満となるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、  関係式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により前記保証帯域Ｒを見積もることを特徴としている。
【００２３】
また、請求項２記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、最初の保証帯域Ｒの設定値では前記ＩＰネットワークに受け付けられなかった場合に、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲において  （Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ（ｎ＞０）  の刻み幅で減少させて見積もり、前記ＩＰネットワークとネゴシエーションすることを特徴としている。
【００２４】
また、請求項３記載の発明は、請求項１記載のパラメータ決定方法によってアプリケーション開始時における前記保障帯域Ｒを見積り、該保障帯域Ｒが前記ＩＰネットワークに受付けられない場合に、請求項２記載のパラメータ決定方法における前記ネゴシエーションにより、前記保障帯域Ｒを逐次変更して再設定することを特徴としている。
【００２５】
また、請求項４記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するアプリケーションによるＩＰ品質保証サービスのパラメータ決定方法において、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  と、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが自身で保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から算出される帯域の近似値Ｒｐｒｏｂとに基づいて、前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ＊を測定し、該転送遅延時間Ｄ＊が前記要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｄ＊＞Ｄｒｅｑ）が  Ｐｒ（Ｄ＊＞Ｄｒｅｑ）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲で増減させて調整することを特徴としている。
【００２６】
また、請求項５記載の発明は、請求項１〜３の何れかの項記載のパラメータ決定方法によって前記アプリケーション開始時における保障帯域Ｒを決定し、前記アプリケーションを動作させながら、請求項４パラメータ決定方法によって前記保障帯域Ｒを調整することを特徴としている。また、請求項６記載の発明は、請求項１〜５の何れかの項記載の発明において、前記アプリケーションの動作時にトラヒックを測定し、前記統計的トラヒック特性を表現するパラメータＸk を、測定時点での設定値Ｘ0kと測定されたトラヒックのデータから算出される統計値Ｘ*kをもとにして、Ｘk＝（１−γk）Ｘ0k＋γkＸ*k（０≦γk≦１） に更新して保持する手続きを前記アプリケーションが有することを特徴としている。
【００２７】
また、請求項７記載の発明は、請求項１〜６の何れかの項記載の発明において、前記統計的トラヒック特性として漸近分散定数ｃ２  および規格化３次モーメントｍ３  を採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定される一般分布トラヒック入力のＧＩ／Ｄ／１待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴としている。
【００２８】
また、請求項８記載の発明は、請求項１〜６の何れかの項記載の発明において、前記統計的トラヒック特性として分散平均比ａと自己相似性パラメータＨを採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定されるＦＢＭトラヒック入力の待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴としている。
【００２９】
また、請求項９記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満となるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、関係式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により前記保証帯域Ｒを見積もる見積処理とを前記端末内のコンピュータに実行させることを特徴としている。
【００３０】
また、請求項１０記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、最初の保証帯域Ｒの設定値が前記ＩＰネットワークに受け付けられなかったことを検出する要求受付判定処理と、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲において  （Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ（ｎ＞０）  の刻み幅で減少させて前記ＩＰネットワークとネゴシエーションする見積処理とを前記端末内のコンピュータに実行させることを特徴としている。
【００３１】
また、請求項１１記載の発明は、請求項９記載の記録媒体に記録されたパラメータ決定プログラムに、最初の保証帯域Ｒの設定値が前記ＩＰネットワークに受け付けられなかったことを検出する要求受付判定処理と、前記ＩＰネットワークに要求する品質パラメータの保証帯域ＲをＲprob≦Ｒ≦Ｒboundの範囲において （Ｒbound−Ｒprob）／ｎ（ｎ＞０） の刻み幅で減少させて前記ＩＰネットワークとネゴシエーションする見積処理とを加えることを特徴としている。
【００３２】
また、請求項１２記載の発明は、アプリケーションフロー毎に帯域保証を可能とするスケジューリングメカニズムを有するルータが網的に接続されているＩＰネットワークを経由して、相互につながっている端末間で動作するアプリケーションが、トラヒックの上限を規定するトラヒックパラメータを申告し、エンド−エンドのパケット転送遅延時間として要求遅延Ｄｒｅｑ  の保証を要求してＩＰ品質保証サービスを利用する際に、該ＩＰ品質保証サービスを規定する品質パラメータである保証帯域Ｒの値を決定するＩＰ品質保証サービスのパラメータ決定プログラムにおいて、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記要求遅延Ｄｒｅｑ  のエンド−エンドのパケット転送遅延時間を保証するのに必要な帯域の上限値Ｒｂｏｕｎｄ  を算出する上限値算出処理と、前記トラヒックパラメータで制限されるトラヒックを想定した場合に、前記エンド−エンドのパケット転送遅延時間が前記要求遅延Ｄｒｅｑ  を越える確率が、ユーザ又は前記アプリケーションにとって支障がない値α未満になるように、前記アプリケーションが保持する統計的トラヒック特性および前記トラヒックパラメータで表現されるエンド−エンドパケット転送遅延時間分布の近似式から帯域の近似値Ｒｐｒｏｂを算出する近似値算出処理と、前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ＊を測定し、該転送遅延時間Ｄ＊が前記要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｄ＊＞Ｄｒｅｑ）が  Ｐｒ（Ｄ＊＞Ｄｒｅｑ）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲で増減させて調整する調整処理とを前記端末内のコンピュータに実行させることを特徴としている。
【００３３】
また、請求項１３記載の発明は、請求項９〜１１の何れかの項記載の記録媒体に記録されたパラメータ決定プログラムに、前記アプリケーションを動作させながらエンド−エンドのパケット転送遅延時間Ｄ*を測定し、該転送遅延時間Ｄ*が前記要求遅延Ｄreqを越える確率Ｐｒ（Ｄ*＞Ｄreq）がＰｒ（Ｄ*＞Ｄreq）＜αを満たす最も小さい値となるように、前記ＩＰネットワークに要求する品質パラメータの保証帯域ＲをＲprob≦Ｒ≦Ｒboundの範囲で増減させて調整する調整処理とを加えることを特徴としている。
【００３４】
また、請求項１５記載の発明は、請求項９〜１４の何れかの項記載の発明において、前記近似値算出処理は、前記統計的トラヒック特性として漸近分散定数ｃ２  および規格化３次モーメントｍ３  を採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定される一般分布トラヒック入力のＧＩ／Ｄ／１待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴としている。
また、請求項１６記載の発明は、請求項９〜１４の何れかの項記載の発明において、前記近似値算出処理は、前記統計的トラヒック特性として分散平均比ａと自己相似性パラメータＨを採用し、これらと前記トラヒックパラメータのうちの平均レートｒによって統計的に規定されるＦＢＭトラヒック入力の待ち行列システムを解析して得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して前記近似値Ｒｐｒｏｂを算出することを特徴としている。
【００３５】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。ここで、本発明は、端末上で動作するソフトウェアにより実現することが可能であり、当該ソフトウェアは端末内に設けられたプログラム制御のコンピュータ上で走行する。すなわち、本発明を実現するためのコンピュータプログラム（ＩＰ品質保証サービスのパラメータ決定プログラム）は様々な記録媒体に格納されて提供されるもので、これら記録媒体からコンピュータ上に読み込まれて当該コンピュータのハードウェアを制御することになる。
【００３６】
記録媒体としては例えば、フロッピーディスク，ハードディスク，磁気テープ，磁気カード，磁気ドラムなどの磁気記録媒体、メモリチップ，ＩＣ（集積回路）カードなどの半導体記録媒体、ＣＤ−ＲＯＭ（コンパクトディスク・リード・オンリー・メモリ），光ディスク，光カードなどの光学記録媒体、ＭＯ（光磁気）ディスクなど種々のものが考えられ、これら以外の各種の情報記憶メディアであって良い。
【００３７】
以下、端末上で動作するプログラムの指令に基づいて、端末内のコンピュータが行う処理手順について説明する。
〔手法１〕〈上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂの組み合わせによる保証帯域Ｒの決定方法〉
ＲＳｐｅｃの保証帯域ＲをＴＳｐｅｃ  から見積もった上限値Ｒｂｏｕｎｄとすると、エンド−エンド端末間で得られる遅延時間は必要以上に小さくなる。つまり、Ｒ＝Ｒｂｏｕｎｄ  は過剰な割り当てになるという問題がある（課題１）。また、アプリケーショントラヒックの統計量から近似を用いて確率的に見積もったＲ＝Ｒｐｒｏｂでは低精度であるという問題がある（課題２）。これらの問題を解決するために、上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを利用して保証帯域Ｒを見積もる方法を提案する。
【００３８】
エンド−エンド端末間でフローの経由するネットワークの状態Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）  をアプリケーションが事前に所有していて、アプリケーションが申告するＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）で制限されるトラヒックを想定した場合に、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値（Ｒｂｏｕｎｄ＝Ｒ）を
【数２】
0003585700.tif 000003
により算出する。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければＲｂｏｕｎｄ＝ｐとおく。
【００３９】
次に、アプリケーションの発生するトラヒックモデルを仮定すれば、エンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）は、ＴＳｐｅｃ  の平均レートｒと仮定したモデルの統計的特性を表すパラメータと保証レートＲを使って近似的に解くことができる。したがって、ＴＳｐｅｃ  以外の統計的トラヒック特性をアプリケーション自身が保持し、エンド−エンドパケット転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がユーザやアプリケーションにとって支障のない程度である確率をαとして、  Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αから、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を確率的に保証するために必要な帯域の近似値Ｒｐｒｏｂ＝Ｒが算出できる。
【００４０】
そして、帯域の上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせて、式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により保証帯域Ｒを見積もる。ただし、βの値は、アプリケーションに固定的に埋め込まれているか、ユーザ自身が経験に基づいて選択するか、後述する〔手法３〕の方法による保証帯域Ｒの最適値を利用して算出することになる。
以上のように、本手法によれば、過剰な見積もり値になることが想定されるＴＳｐｅｃに基づく上限値Ｒｂｏｕｎｄと、トラヒックの統計量から見積もった低精度の確率的近似値Ｒｐｒｏｂの間にＲＳｐｅｃ  の保証帯域Ｒを設定することで、過大または過小な割り当てをなくすことができる。これにより、資源量の無駄をなくして帯域の見積もり誤差による品質劣化を解消できる。
【００４１】
〔手法２〕〈フロー設定時のパラメータネゴシエーションにおける保証帯域Ｒの選択機構を含む方法〉
〔手法１〕によれば、ＲＳｐｅｃの保証帯域Ｒを上限値Ｒｂｏｕｎｄよりも小さく，低精度の確率的近似値Ｒｐｒｏｂよりも大きく見積もることで、資源量の無駄をなくし帯域の見積もり誤差による品質劣化を解消できる。しかし、最初に決定したパラメータでフローを設定した時に、そのパラメータ値ではフローが受け付けられなかった場合、再設定する際のパラメータ値の変え方は含まれていない。つまり、上限値Ｒｂｏｕｎｄ  または確率的近似値Ｒｐｒｏｂを単独で用いて保証帯域Ｒを見積もる場合の見積もり誤差の問題以外に、フロー設定パラメータをネゴシエーションする場合に保証帯域Ｒの変更可能範囲などのパラメータの選択指針がないという問題がある（課題３）。そこで、フローが受け付けられなかった場合に、ネットワークとネゴシエーションして再設定する際のパラメータ値の更新機構を含む方法を提案する。
【００４２】
エンド−エンド端末間でフローの経由するネットワークの状態  Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）  をアプリケーションが事前に所有していて、アプリケーションが申告するＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）で制限されるトラヒックを想定した場合に、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値（Ｒｂｏｕｎｄ＝Ｒ）を
【数３】
0003585700.tif 000004
により算出する。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければＲｂｏｕｎｄ＝ｐとおく。
【００４３】
次に、アプリケーションの発生するトラヒックモデルを仮定すれば、エンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）は、ＴＳｐｅｃ  の平均レートｒと仮定したモデルの統計的特性を表すパラメータと保証レートＲを使って近似的に解くことができる。したがって、ＴＳｐｅｃ  以外の統計的トラヒック特性をアプリケーション自身が保持し、エンド−エンドパケット転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がユーザやアプリケーションにとって支障のない程度である確率をαとして、  Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αから、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を確率的に保証するために必要な帯域の近似値Ｒｐｒｏｂ＝Ｒが算出できる。
【００４４】
そして、アプリケーションが申告するトラヒックパラメータ（ＴＳｐｅｃ）  で制限されるトラヒックを想定した場合に、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値（Ｒｂｏｕｎｄ）と、アプリケーションが自身で保持する統計的トラヒック特性を利用して、エンド−エンドパケット転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がユーザやアプリケーションにとって支障がない値（α）未満になるよう、ＴＳｐｅｃ  および統計的トラヒック特性を使って表現できるエンド−エンドパケット転送遅延時間分布の近似式から算出した帯域の近似値（Ｒｐｒｏｂ）とをもとにして、最初の設定値ではネットワークに受け付けられない場合に、ネットワークに要求するＲＳｐｅｃ  の保証帯域ＲをＲｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄの範囲で、（Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ（ｎ＞０）の刻み幅で減少させてネゴシエーションすることでパラメータを決定する。
【００４５】
なお、最初にネットワークに要求するＲＳｐｅｃ  の保証帯域Ｒを〔手法１〕に示すＲ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）で申告して、受け付けられない時に、上記の刻み幅で徐々に受け付けられる値に減少する方法もある。
以上のように、本手法では、フロー設定時のパラメータネゴシエーションにおける保証帯域Ｒの変更基準を上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを利用して定式化している。これにより、アプリケーションの採用するＲＳｐｅｃ  パラメータが一度決めると固定的であって、変更できるとしても変更可能な範囲や変更指針が何もなく、ユーザが試行錯誤で適当な値に変更するしかないという問題が解消される。
【００４６】
〔手法３〕〈パケット転送遅延Ｄ＊  測定に基づく更新手続きを含む保証帯域Ｒの決定方法〉
〔手法１〕によれば、ＲＳｐｅｃの保証帯域Ｒを、上限値Ｒｂｏｕｎｄよりも小さく，低精度の確率的近似値Ｒｐｒｏｂよりも大きく見積もることで、資源量の無駄をなくし帯域の見積もり誤差による品質劣化を解消できる。しかし、ユーザの使用状況の変化による変動があり、なおかつ確率的近似値Ｒｐｒｏｂの見積もり誤差があるために、〔手法１〕では最適な値になるとは限らない（課題４）。また、〔手法２〕ではネットワークとのネゴシエーションを含む方法を提案したが、この場合も同様に見積もり誤差が含まれ、最適な値とはならない。そこで、アプリケーション開始時に見積もった保証帯域Ｒの見積もり誤差を解消するために、アプリケーション動作中にトラヒックを測定することによりＲを最適な値に近づけるよう更新する機構を含む方法を提案する。
【００４７】
エンド−エンド端末間でフローの経由するネットワークの状態  Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）  をアプリケーションが事前に所有していて、アプリケーションが申告するＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）で制限されるトラヒックを想定した場合に、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値（Ｒｂｏｕｎｄ＝Ｒ）を
【数４】
0003585700.tif 000005
により算出する。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければＲｂｏｕｎｄ＝ｐとおく。
【００４８】
次に、アプリケーションの発生するトラヒックモデルを仮定すれば、エンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）は、ＴＳｐｅｃ  の平均レートｒと仮定したモデルの統計的特性を表すパラメータと保証レートＲを使って近似的に解くことができる。したがって、ＴＳｐｅｃ  以外の統計的トラヒック特性をアプリケーション自身が保持し、エンド−エンドパケット転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がユーザやアプリケーションにとって支障のない程度である確率をαとして、  Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αから、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を確率的に保証するために必要な帯域の近似値Ｒｐｒｏｂ＝Ｒが算出できる。
【００４９】
そして、アプリケーションが申告するトラヒックパラメータ（ＴＳｐｅｃ）  で制限されるトラヒックを想定した場合に、要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値（Ｒｂｏｕｎｄ）と、アプリケーションが自身で保持する統計的トラヒック特性を利用して、エンド−エンドパケット転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がユーザやアプリケーションにとって支障がない値（α）未満になるよう、ＴＳｐｅｃ  および統計的トラヒック特性を使って表現できるエンド−エンドパケット転送遅延時間分布の近似式から算出した帯域の近似値（Ｒｐｒｏｂ）とをもとにして、アプリケーションを動作させつつ、エンド−エンドパケット転送遅延時間Ｄ＊  を測定し、この転送遅延時間が要求遅延Ｄｒｅｑ  を越える確率がＰｒ（Ｄ＊＞Ｄｒｅｑ）＜αを満たす最も小さいものになるように、ネットワークに要求するＲＳｐｅｃの保証帯域Ｒを  Ｒｐｒｏｂ≦Ｒ≦Ｒｂｏｕｎｄ  の範囲で増減させて調整することにより最適なパラメータを決定する。
【００５０】
なお、この場合、増減幅を（Ｒｂｏｕｎｄ−Ｒｐｒｏｂ）／ｎ  （ｎ＞０）とすることも考えられる。
また、アプリケーションの開始時に、ネットワークに要求するＲＳｐｅｃ  の保証帯域Ｒを〔手法１〕に示すＲ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）で申告して、アプリケーション動作時に転送遅延時間Ｄ＊  を測定しつつ、上記の刻み幅で徐々に適切な値に変更する方法もある。
さらに、Ｒの算出式に含まれるβを適切な値に更新するために、ここで見出したＲの最適値を利用して、これと「（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  」が等しいとして算出したβを、新たな値として採用する方法もある。
【００５１】
以上のように、本手法では、エンド−エンドパケット転送遅延時間Ｄ＊  を測定し、保証帯域Ｒが最適でない場合に、上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを使って定式化された変更幅の基準に従って保証帯域Ｒを変更している。これにより、アプリケーション動作中に、フロー設定の際のＲＳｐｅｃ  パラメータの見積もり誤差をできるだけ最適な値に修正する際に、パラメータを変更できるとしても変更可能な範囲や変更指針が何もなく、ユーザまたはアプリケーションが試行錯誤で適当な値に変更するしかなかったという問題が解消される。
【００５２】
〔手法４〕〈トラヒック測定によるアプリケーションの統計的トラヒック特性パラメータの更新を含む方法〉
〔手法１〕によれば、ＲＳｐｅｃの保証帯域Ｒを、上限値Ｒｂｏｕｎｄよりも小さく，低精度の確率的近似値Ｒｐｒｏｂよりも大きく見積もることで、資源量の無駄をなくし帯域の見積もり誤差による品質劣化を解消できる。しかし、ユーザの使用状況の変化による変動があり、なおかつ確率的近似値Ｒｐｒｏｂの見積もり誤差があるために、〔手法１〕では最適な値になるとは限らない。また、〔手法２〕ではネットワークとのネゴシエーションを含む方法を提案したが、この場合も同様に見積もり誤差が含まれ、最適な値とはならない。さらに〔手法３〕では、アプリケーション開始時に見積もった保証帯域Ｒの見積もり誤差を解消するために、アプリケーション動作中にトラヒックを測定しながら保証帯域Ｒを最適な値に近づけるように更新する機構を含む方法を提案した。
【００５３】
しかし、初期の見積もり誤差を小さくしておかなければ、この更新処理を効率的に実行することができない。そこで、初期の見積もり誤差をできるだけ小さくする（課題５）ために、この誤差の原因となる確率的近似値Ｒｐｒｏｂを算出するための統計的トラヒック特性をアプリケーションの動作環境に応じて柔軟に変更する処理を含む方法を提案する。
【００５４】
すなわち、アプリケーション動作時にトラヒックを測定し、アプリケーションが自身で保持する統計的トラヒック特性（これを表現するパラメータをＸｋ  とする）を、測定時点での設定値（Ｘ０ｋ）と測定データから算出された統計値（Ｘ＊ｋ）をもとに、Ｘｋ＝（１−γｋ）Ｘ０ｋ＋γｋＸ＊ｋ（０≦γｋ≦ｌ）に更新して保持する。そして、次のアプリケーション実行時に、更新したこのパラメータを使って確率的近似値Ｒｐｒｏｂを算出することにより保証帯域Ｒを見積もる。なお、本手法４は〔手法１〕〜〔手法３〕のそれぞれと組み合わせて利用することになる。
以上のように、本手法によれば、確率的近似値Ｒｐｒｏｂを見積もるためのアプリケーションの統計的トラヒック特性パラメータを測定に基づいて更新するようにいている。これにより、保証帯域Ｒが、アプリケーションの動作環境やユーザの使い方によって変動する実際の統計的特性に追従するようになって、利用条件による見積もり誤差を解消できる。
【００５５】
〔手法５〕〈統計的トラヒック特性としてＧＩ／Ｄ／１待ち行列システムを利用する方法〉
〔手法１〕〜〔手法４〕においては、確率的近似値Ｒｐｒｏｂを算出するために何らかのトラヒックモデルを仮定する必要がある。しかし、一般に利用されているＭＭＰＰでは、測定可能な統計量からモデルパラメータへの変換が容易ではなく、また、数値として解く場合時間がかかるという問題がある（課題６）。そこで、測定可能な統計量をモデルパラメータとして含み、数値解が容易に算出できるトラヒックモデルを利用して確率的近似値Ｒｐｒｏｂを算出し、これをもとに保証帯域Ｒを見積もる方法を提案する。
【００５６】
ここでは、トラヒックモデルとして平均レート（ｒ），漸近分散定数（ｃ２  ），規格化３次モーメント（ｍ３  ）で規定される一般分布入力モデルを採用する。ここで、平均レートはＴＳｐｅｃ  のものと同一であるので、アプリケーションが保持すべき統計的トラヒック特性は漸近分散定数ｃ２および規格化３次モーメントｍ３ということになる。これらの特性パラメータとＴＳｐｅｃ  の平均レートｒを用いてＧＩ／Ｄ／１待ち行列システムを解析すると、エンド−エンドパケット転送遅延時間分布の近似式は下式で表現される（  Ａ．Ｗ．Ｂｅｒｇｅｒ  ａｎｄ  Ｗ．Ｗｈｉｔｔ、”Ｍａｘｉｍｕｍ  Ｖａｌｕｅｓ  ｉｎ  Ｑｕｅｕｅｉｎｇ  Ｐｒｏｃｅｓｓｅｓ，”Ｐｒｏｂａｂｉｌｉｔｙ  ｉｎ  ｔｈｅ  Ｅｎｇｉｎｅｅｒｉｎｇ  ａｎｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｃｉｅｎｃｅｓ、Ｖｏｌ．９、１９９５．）。
【数５】
0003585700.tif 000006
ただし、
【数６】
0003585700.tif 000007
【００５７】
この近似式を利用して、Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αとなるように  Ｒｐｒｏｂ＝Ｒを算出する。この確率的近似値Ｒｐｒｏｂは、保証帯域Ｒを見積もるために〔手法１〕〜〔手法４〕のいずれかの中で利用される。特に、〔手法４〕と組み合わせた場合における統計的トラヒック特性の更新手続きは以下のようになる。
【００５８】
すなわち、ＧＩ／Ｄ／１待ち行列システムを利用する場合、アプリケーションが保持する統計的トラヒック特性として漸近分散定数ｃ２  と規格化３次モーメントｍ３  が存在する。アプリケーションは、開始時から時刻ｔまでの間にネットワークに入力するトラヒック量Ａ（ｔ）の平均ＥＡ（ｔ），分散ＶａｒＡ（ｔ），規格化３次モーメントｍ＊３をそれぞれ測定して、漸近分散定数を
【数７】
0003585700.tif 000008
により計算する。そして、測定時点での設定値ｃ０２，ｍ０３と測定データから算出された統計値ｃ＊２，ｍ＊３をもとに、ｃ２＝（１−γｃ２）ｃ０２＋γｃ２ｃ＊２，ｍ３＝（１−γｍ３）ｍ０３＋γｍ３ｍ＊３に更新して保持する。
【００５９】
以上のように、本手法では、測定可能な統計量をパラメータとするＧＩ／Ｄ／１待ち行列システムを採用し、これから得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して確率的近似値Ｒｐｒｏｂを見積もっている。これにより、ＭＭＰＰを採用して確率的近似値Ｒｐｒｏｂを見積もる場合のように、測定可能な統計量からそのモデルパラメータ（高負荷／低負荷状態の各継続時間と各状態の負荷）に変換する手間と、これを解く際にラプラス変換と反復計算の必要があって算出に時間がかかるという問題が解消される。
【００６０】
〔手法６〕〈統計的トラヒック特性としてＦｒａｃｔｉｏｎａｌ  Ｂｒｏｗｎｉａｎ  Ｍｏｔｉｏｎ（ＦＢＭトラヒックモデルを利用する方法〉
〔手法１〕〜〔手法４〕において、確率的近似値Ｒｐｒｏｂを算出するためには何らかのトラヒックモデルを仮定する必要がある。しかし、一般に利用されているＭＭＰＰでは、測定可能な統計量からモデルパラメータへの変換が容易ではなく、また数値として解く場合時間がかかるという問題がある（課題６）。
【００６１】
さらに、ＬＡＮトラヒックなどでは、バーストに特徴的な長さがなく（ないしは、バースト長が非常に広い幅にわたって存在し）、時間単位を変えると、分散が時間単位の増加に対してべき関数的に増加するという統計的性質を有することが知られている。アプリケーショントラヒックがこうした性質を有する場合、ＭＭＰＰや〔手法５〕で示したトラヒックモデルでは、このような統計的特性を表現できないという問題が生じる（課題７）。そこで、バーストに特徴的な長さがないトラヒックに対して、測定可能な統計量をモデルパラメータとして含み、数値解が容易に算出できるトラヒックモデルを利用して確率的近似値Ｒｐｒｏｂを算出し、これをもとに保証帯域Ｒを見積もる方法を提案する。
【００６２】
ここでは、アプリケーションが保持する統計的トラヒック特性として、分散平均比（ａ）と自己相似性パラメータ（Ｈ）を採用し、これらとＴＳｐｅｃ  の平均レート（ｒ）により統計的に規定されるＦＢＭトラヒックモデルを入力トラヒックとして採用する。本トラヒック入力の待ち行列システムを解析すると、エンド−エンドパケット転送遅延時間分布は、以下のように得られる（Ｉ．Ｎｏｒｒｏｓ、”Ａ  Ｓｔｏｒａｇｅ  Ｍｏｄｅｌ  ｗｉｔｈ  Ｓｅｌｆ−ｓｉｍｉｌａｒ  Ｉｎｐｕｔ，”Ｑｕｅｕｅｉｎｇ  Ｓｙｓｔｅｍｓ、Ｖｏｌ．１６、１９９４．）。
【数８】
0003585700.tif 000009
【００６３】
これを利用して、Ｐｒ（Ｗ＞Ｄｒｅｑ）＝αとなるように帯域の近似値  Ｒｐｒｏｂ＝Ｒを算出する。この確率的近似値Ｒｐｒｏｂは、保証帯域Ｒを見積もるために〔手法１〕〜〔手法４〕のいずれかの中で利用される。特に、〔手法４〕と組み合わせた場合における統計的トラヒック特性の更新手続きは以下のようになる。
【００６４】
すなわち、アプリケーションは、開始時から時刻ｔまでの間にネットワークに入力するトラヒック量Ａ（ｔ）の平均ＥＡ（ｔ），分散ＶａｒＡ（ｔ）をそれぞれ測定し、複数のｔにおける平均と分散を求める。そして、本モデルにおいて仮定される関係式：
【数９】
0003585700.tif 000010
を関係式：
【数１０】
0003585700.tif 000011
に変形し、いくつかのｔに対して測定した統計量をもとに、最小自乗近似などを利用してＨ＊＝Ｈ及びａ＊＝ａを算出する。そして、測定時点での設定値ａ０  ，Ｈ０と測定データから算出された統計値ａ＊，Ｈ＊をもとにして、ａ＝（１−γａ）ａ０＋γａａ＊，Ｈ＝（１−γＨ）Ｈ０＋γＨＨ＊に更新して保持する。
【００６５】
以上のように、本手法では、測定可能な統計量をパラメータとするＦＢＭトラヒックモデルを採用して、これから得られるエンド−エンドパケット転送遅延時間分布の近似式を利用して確率的近似値Ｒｐｒｏｂを見積もっている。これにより、ＭＭＰＰを採用して確率的近似値Ｒｐｒｏｂを見積もる場合のように、測定可能な統計量からそのモデルパラメータ（高負荷／低負荷状態の各継続時間と各状態の負荷）に変換する手間と、これを解く際にラプラス変換と反復計算の必要があって算出に時間がかかるという問題が解消される。
また、ＦＢＭトラヒックモデルは、時間単位を変えると分散が時間単位の増加に対してべき関数的に増加するという統計的性質を有するので、バーストに特徴的な長さがないトラヒック入力に対処できなかった問題も解消できる。
【００６６】
〔手法１の実施形態〕
〔手法１〕によるパラメータ見積もり方法を実現するための実施形態を図３に示す。なお、同図において図１〜図２と同じ構成要素には同一の符号を付してある。アプリケーションがフローを設定する際には、まず、  上限値Ｒｂｏｕｎｄ算出部２が、アプリケーション本体３から要求遅延Ｄｒｅｑ  とＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）を受け取り、エンド−エンド端末間でフローの経由するネットワークの状態Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）をネットワーク４から受け取る。そして、これをもとに〔手法１〕に示した算出式：
【数１１】
0003585700.tif 000012
で要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値Ｒｂｏｕｎｄ＝Ｒを算出し、結果をＲ算出部７に渡す。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければＲｂｏｕｎｄ＝ｐとおく。
【００６７】
同時に、確率的値Ｒｐｒｏｂ算出部６は、アプリケーション本体３から要求遅延Ｄｒｅｑとその超過を許容する確率αとＴＳｐｅｃの平均レートｒを受け取り、これらと自身で保持しているトラヒックの統計的性質をもとに、〔手法１〕に示したエンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）に関する関係式：Ｐｒ（Ｗ＞Ｄｒｅｑ）＝α  から確率的近似値Ｒｐｒｏｂ＝Ｒを算出し、結果をＲ算出部７に渡す。ここで、トラヒックモデルを仮定すれば、Ｐｒ（Ｗ＞Ｄｒｅｑ）  はそのモデルパラメータと、保証帯域ＲとＴＳｐｅｃ  の平均レートｒの関数である。特に、確率的値Ｒｐｒｏｂ算出部６が保持しているトラヒックの統計的性質は、ＧＩを仮定すれば漸近分散定数ｃ２と規格化３次モーメントｍ３であり、ＦＢＭを仮定すれば分散平均比ａと自己相似性パラメータＨである。
【００６８】
最後に、Ｒ算出部７では上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせて、〔手法１〕に示す関係式：Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により保証帯域Ｒを見積もり、アプリケーション本体３に戻す。ただし、βの値は、アプリケーションに固定的に埋め込まれているか、ユーザ自身が経験に基づいて選択するか、〔手法３〕の方法による保証帯域Ｒの最適値を利用して算出することになる。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの設定をネットワーク４に依頼する。フローが設定されれば送信端末５からデータが送信される。
【００６９】
〔手法３の実施形態〕
手法３によるパラメータ見積もり方法を実現するための実施形態を図４に示す。なお、同図において図１〜図３と同じ構成要素には同一の符号を付してある。アプリケーションがフローを設定する際には、まず、上限値Ｒｂｏｕｎｄ算出部２  が、アプリケーション本体３から要求遅延Ｄｒｅｑ  とＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）を受け取り、エンド−エンド端末間でフローの経由するネットワークの状態Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）をネットワーク４から受け取る。そして、これをもとに〔手法１〕に示した算出式：
【数１２】
0003585700.tif 000013
で要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値Ｒｂｏｕｎｄ＝Ｒ  を算出し、結果をＲ算出部１７に渡す。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければ、Ｒｂｏｕｎｄ＝ｐとおく。
【００７０】
同時に、確率的値Ｒｐｒｏｂ算出部６は、アプリケーション本体３から要求遅延Ｄｒｅｑとその超過を許容する確率αとＴＳｐｅｃの平均レートｒを受け取り、これらと自身で保持しているトラヒックの統計的性質をもとに、〔手法１〕に示したエンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）に関する関係式：Ｐｒ（Ｗ＞Ｄｒｅｑ）＝α  からＲｐｒｏｂ＝Ｒを算出し、結果をＲ算出部１７に渡す。ここで、トラヒックモデルを仮定すれば、  Ｐｒ（Ｗ＞Ｄｒｅｑ）  はそのモデルパラメータと、保証帯域ＲとＴＳｐｅｃの平均レートｒの関数である。特に、確率的値Ｒｐｒｏｂ算出部６が保持しているトラヒックの統計的性質は、ＧＩを仮定すれば漸近分散定数ｃ２と規格化３次モーメントｍ３であり、ＦＢＭを仮定すれば分散平均比ａと自己相似性パラメータＨである。
【００７１】
そして、Ｒ算出部１７では、上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせて〔手法１〕に示す関係式Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により保証帯域Ｒを見積もり、アプリケーション本体３に戻す。ただし、βの値は、アプリケーションに固定的に埋め込まれているか、ユーザ自身が経験に基づいて選択するか、〔手法３〕の方法による保証帯域Ｒの最適値（即ち、以下に示す保証帯域Ｒの再計算）を利用して算出することになる。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの設定をネットワーク４に依頼する。フローが設定されれば送信端末５からデータが送信される。
【００７２】
その後、トラヒック測定部８でパケットをモニタリングし、遅延時間Ｄ＊  算出部９でそのパケットを解析してエンド−エンド遅延時間Ｄ＊  を算出する。例えば、Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（ＲＴＰ）などを利用すれば、現在時間からパケットヘッダのタイムスタンプの時間を引いてそのパケットの遅延時間Ｄ＊  が算出できる。Ｒ算出部１７では、この遅延時間Ｄ＊  と要求遅延Ｄｒｅｑ  の差を考慮して〔手法３〕に示す方法で保証帯域Ｒを再計算して、結果をアプリケーション本体３に渡す。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの帯域変更をネットワーク４に依頼することになる。
【００７３】
〔手法４の実施形態〕
〔手法４〕によるパラメータ見積もり方法を実現するための実施形態を図５に示す。なお、同図において図１〜図４と同じ構成要素には同一の符号を付してある。アプリケーションがフローを設定する際には、まず、  上限値Ｒｂｏｕｎｄ算出部２  が、アプリケーション本体３から要求遅延ＤｒｅｑとＩＰ品質保証サービスのトラヒックパラメータＴＳｐｅｃ  （平均レートｒ，ピークレートｐ，バーストサイズｂ，最大パケットサイズＭ）を受け取り、エンド−エンド端末間でフローの経由するネットワークの状態Ａｄｓｐｅｃ（Ｃｔｏｔ，Ｄｔｏｔ）をネットワーク４から受け取る。そして、これをもとに〔手法１〕に示した算出式：
【数１３】
0003585700.tif 000014
で要求遅延Ｄｒｅｑ  のエンド−エンドパケット転送遅延時間を保証するために必要な帯域の上限値Ｒｂｏｕｎｄ＝Ｒ  を算出し、結果をＲ算出部７に渡す。一方、もしもＡｄｓｐｅｃがアプリケーションに通知されていなければＲｂｏｕｎｄ＝ｐとおく。
【００７４】
同時に、確率的値Ｒｐｒｏｂ算出部６は、アプリケーション本体３から要求遅延Ｄｒｅｑとその超過を許容する確率αとＴＳｐｅｃの平均レートｒを受け取り、これらと自身で保持しているトラヒックの統計的性質をもとに、〔手法１〕に示したエンド−エンドパケット転送遅延時間Ｗが要求遅延Ｄｒｅｑを越える確率Ｐｒ（Ｗ＞Ｄｒｅｑ）に関する関係式：Ｐｒ（Ｗ＞Ｄｒｅｑ）＝α  からＲｐｒｏｂ＝Ｒを算出し、結果をＲ算出部７に渡す。ここで、トラヒックモデルを仮定すれば  Ｐｒ（Ｗ＞Ｄｒｅｑ）は、そのモデルパラメータと、保証帯域ＲとＴＳｐｅｃ  の平均レートｒの関数である。特に、確率的値Ｒｐｒｏｂ算出部６が保持しているトラヒックの統計的性質は、ＧＩを仮定すれば漸近分散定数ｃ２と規格化３次モーメントｍ３であり、ＦＢＭを仮定すれば分散平均比ａと自己相似性パラメータＨである。
【００７５】
そして、Ｒ算出部７では上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせて〔手法１〕に示す関係式：Ｒ＝（１−β）Ｒｂｏｕｎｄ＋βＲｐｒｏｂ  （０≦β≦１）により保証帯域Ｒを見積もり、アプリケーション本体３に戻す。ただし、βの値は、アプリケーションに固定的に埋め込まれているか、ユーザ自身が経験に基づいて選択するか、〔手法３〕の方法による保証帯域Ｒの最適値を利用して算出することになる。アプリケーションはこの保証帯域ＲをＲＳｐｅｃ  として、フローの設定をネットワーク４に依頼する。フローが設定されれば送信端末５からデータが送信される。
【００７６】
その後、トラヒック測定部８でトラヒックを測定し、トラヒック統計量算出部１０で、測定したトラヒックの特性を表す統計量を〔手法４〕に示す方法で見積もり、これを用いて確率的値Ｒｐｒｏｂ算出部６により確率的近似値Ｒｐｒｏｂを算出する。Ｒ算出部７では、この統計量を次のフロー設定の際に利用するため保持しておく。
【００７７】
〔手法３と手法４を組み合わせた実施形態〕
〔手法３〕及び〔手法４〕によるパラメータ見積もり方法を組み合わせた実施形態を図６に示す。同図において図１〜図５と同じ構成要素には同一の符号を付してある。この場合の動作は上述した〔手法３の実施形態〕及び〔手法４の実施形態〕の説明から明らかであるため、ここではその説明を省略する。
【００７８】
〔実トラヒックへの適用例〕
現実のアプリケーショントラヒックに本発明を適用した場合の効果を評価するために、イーサネット上で測定したトラヒックデータを利用したシミュレーションを行う。ここで、送受信端末間が１ルータを経由して接続しているＩＰネットワークを想定し、そのルータからのパケット送出はＷＦＱスケジューリングに従うものとする。アプリケーションには、テレビ会議（Ｈ．２６１符号化）とインターネット電話（インテル版）をそれぞれ採用し、その背景にイーサネット上で測定した全トラヒック（ＬＡＮトラヒック）のデータを流すものとする。シミュレーションで用いる測定トラヒックデータは、パケットの発生時刻（単位は秒）とそのサイズ（単位はバイト）の組が発生順に並んでいるものである。なお、各アプリケーショントラヒックの測定データの統計量を図７に示す。
【００７９】
発生トラヒックの測定データから  ＴＳｐｅｃ（ｐ，ｒ，ｂ，Ｍ）を見積もる。また、ユーザはＤｒｅｑ  ≦１秒の遅延時間を要求しているとし、保証帯域の上限値Ｒｂｏｕｎｄ  は〔従来技術１〕に従って算出できる。また、確率的な保証帯域Ｒｐｒｏｂは、例えば、α≒１０−３の確率でＤｒｅｑ  ≒１秒程度になるように、〔従来技術２〕の方法に〔手法５〕又は〔手法６〕の方法を適用することで算出できる。なおここでは〔手法６〕を適用するものとする。また、悪条件のもとで評価するために、経由するルータから送出するリンク速度μは、着目するアプリケーショントラヒックの平均レートとＬＡＮトラヒックの平均レートの和よりも少し大きい程度に設定する。なお、実際のシミュレーションで使用したこれらの数値をそれぞれ図８に示す。
【００８０】
まず、テレビ会議のトラヒックに本パラメータ決定方法を適用した場合の効果を評価する。保証帯域Ｒ＝Ｒｂｏｕｎｄ  の場合，保証帯域Ｒ＝Ｒｐｒｏｂの場合，β＝０．９とした〔手法１〕の方法について、それぞれのエンド−エンド端末間のパケット転送遅延時間分布を図９に示す。なお、同図では参考のために帯域保証なしの場合も示している。
【００８１】
図から分かるように、上限値を保証帯域としたＲ＝Ｒｂｏｕｎｄ  の場合は、要求遅延を１秒としたにも関わらず、ほとんどのパケットが０．２秒以下の遅延時間になっている。一方、アプリケーショントラヒックの統計的特性をもとに確率的に算出した帯域を保証帯域としたＲ＝Ｒｐｒｏｂの場合は、５％程度のパケットが要求遅延の１秒を越えている。他方、上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせる〔手法１〕の方法では、両者の中間的な分布になっているので、過剰な帯域割り当てにならず、要求遅延時間を現実的な割合（今の場合１０−３以下）で満足している。
【００８２】
次に、インターネット電話のトラヒックに本発明を適用した場合の効果を評価する。ここで、保証帯域Ｒ＝Ｒｂｏｕｎｄ  の場合，保証帯域Ｒ＝Ｒｐｒｏｂの場合，β＝１．０とした〔手法１〕の方法について、それぞれのエンド−エンド端末間のパケット転送遅延時間分布を図１０に示す。なお、同図では参考のために帯域保証なしの場合も示している。
【００８３】
図から分かるように、上限値を保証帯域としたＲ＝Ｒｂｏｕｎｄ  の場合は、要求遅延を１秒としたにも関わらず、ほとんどのパケットは０．１秒以下の遅延時間になっている。また、アプリケーショントラヒックの統計的特性をもとに確率的に算出した帯域を保証帯域としたＲ＝Ｒｐｒｏｂの場合は、ほとんどのパケットの遅延時間は０．３秒以下となっている。一方、上限値Ｒｂｏｕｎｄ  と確率的近似値Ｒｐｒｏｂを組み合わせる〔手法１〕の方法では、β＝１としているのでＲ＝Ｒｐｒｏｂの場合と同じ分布になっており、Ｒ＝Ｒｂｏｕｎｄ  を選択した場合ほどは過剰な帯域割り当てになっていない。このように、確率的近似値Ｒｐｒｏｂの見積もり誤差が大きいこともあるので、〔手法１〕の方法だけでは、最初に決定される保証帯域Ｒが最適な値になるとは限らない。そこで、こうした場合は、最適値に近づけるために、〔手法３〕の測定に基づく保証帯域Ｒの更新手続きを採用する必要がある。
【００８４】
【発明の効果】
以上説明したように、請求項１又は９記載の発明によれば、ＩＰネットワークに要求する品質パラメータの保証帯域を、パケット転送遅延時間が要求遅延を越える確率がアプリケーション等にとって支障のない帯域の近似値と要求遅延の保証に必要な帯域の上限値との間で設定しているので、過大または過小な割り当てをなくすことができ、資源量の無駄を省いて帯域の見積もり誤差による品質劣化を解消できる効果がある。
【００８５】
また、請求項２又は１０記載の発明によれば、最初の保証帯域Ｒの設定がＩＰネットワークに受け付けられない場合に、ＩＰネットワークに要求する品質パラメータの保証帯域を、パケット転送遅延時間が要求遅延を越える確率がアプリケーション等にとって支障のない帯域の近似値と要求遅延の保証に必要な帯域の上限値との間において、これら近似値及び上限値の間をｎ等分した刻み幅で減少させるようにしたので、フロー設定時のパラメータネゴシエーションにおける保証帯域の変更基準を定式化することができる。したがって、アプリケーションの採用する品質パラメータが一度決めると固定的で、変更できるとしても変更可能な範囲や変更指針が何もなくユーザが試行錯誤で適当な値に変更するしかなかったという問題が解消される効果がある。
【００８６】
また、請求項４又は１２記載の発明によれば、アプリケーションを動作させながらパケット転送遅延時間Ｄ＊  を測定して、この値が要求遅延を越える確率がアプリケーション等にとって支障のない値α未満の最小値となるように、パケット転送遅延時間が要求遅延を越える確率がアプリケーション等にとって支障のない帯域の近似値と要求遅延の保証に必要な帯域の上限値との間で、ＩＰネットワークに要求する品質パラメータの保証帯域を増減させるようにしている。これにより、フロー設定の際の品質保証パラメータの見積もり誤差をアプリケーション動作中にできるだけ最適な値に修正することができる。したがって、こうしたパラメータを変更できるとしても変更可能な範囲や変更指針が何もなく、ユーザやアプリケーションが試行錯誤で適当な値に変更するしかなかったという問題が解消される効果がある。
【００８７】
また、請求項６又は１４記載の発明によれば、アプリケーションの動作時にトラヒックを測定し、測定されたトラヒックのデータから算出される統計値に基づいて、アプリケーションの統計的トラヒック特性を表現するパラメータを更新し、それ以降の帯域の近似値を算出するようにしたので、ＩＰネットワークに要求する品質保証パラメータの保証帯域が、アプリケーションの動作環境やユーザの使い方によって変動する実際の統計的特性に追従することになって、利用条件による見積もり誤差を解消できる効果がある。
【００８８】
また、請求項７又は１５記載の発明によれば、測定可能な統計量をパラメータとする一般分布トラヒック入力のＧＩ／Ｄ／１待ち行列システムを解析して得られるパケット転送遅延時間分布の近似式を利用して帯域の近似値を算出している。これにより、ＭＭＰＰを利用して帯域の近似値を見積もる場合のように、測定可能な統計量からＭＭＰＰのモデルパラメータに変換する手間と、これを解く際にラプラス変換と反復計算の必要があって算出に時間がかかるという問題が解消される効果がある。
【００８９】
また、請求項８又は１６記載の発明によれば、測定可能な統計量をパラメータとするＦＢＭトラヒック入力の待ち行列システムを解析して得られるパケット転送遅延時間分布の近似式を利用して帯域の近似値を算出している。これにより、ＭＭＰＰを利用して帯域の近似値を見積もる場合のように、測定可能な統計量からＭＭＰＰのモデルパラメータに変換する手間と、これを解く際にラプラス変換と反復計算の必要があって算出に時間がかかるという問題が解消される効果がある。また、ＦＢＭトラヒックモデルは、時間単位を変えると分散が時間単位の増加に対してべき関数的に増加するという統計的性質を有するので、バーストに特徴的な長さがないトラヒック入力の場合に対処できなかった問題が解消される効果もある。
【図面の簡単な説明】
【図１】インターネットドラフトで提唱されている従来のパラメータ見積もり方法を説明したブロック図である。
【図２】パケット転送遅延を確率的に保証する従来のパラメータ見積もり方法を説明したブロック図である。
【図３】本発明の一実施形態における〔手法１〕のパラメータ見積もり方法を説明したブロック図である。
【図４】同実施形態における〔手法３〕のパラメータ見積もり方法を説明したブロック図である。
【図５】同実施形態における〔手法４〕のパラメータ見積もり方法を説明したブロック図である。
【図６】同実施形態における〔手法３〕及び〔手法４〕を組み合わせた場合のパラメータ見積もり方法を説明したブロック図である。
【図７】本発明の効果を評価するためのシミュレーションで用いる各アプリケーショントラヒックの測定データの統計量を示す図表である。
【図８】同シミュレーションを行うにあたってのシミュレーション条件の数値を示す図表である。
【図９】テレビ会議のトラヒックに本発明を適用した場合におけるパケット転送遅延時間分布を示したグラフである。
【図１０】インターネット電話のトラヒックに本発明を適用した場合におけるパケット転送遅延時間分布を示したグラフである。
【符号の説明】
１  受信端末
２  上限値Ｒｂｏｕｎｄ算出部
３  アプリケーション本体
４  ネットワーク
５  送信端末
６  確率的値Ｒｐｒｏｂ算出部
７，１７  Ｒ算出部
８  トラヒック測定部
９  遅延時間Ｄ＊算出部
１０  トラヒック統計量算出部
【図１】
0003585700.tif 000015
【図２】
0003585700.tif 000016
【図３】
0003585700.tif 000017
【図４】
0003585700.tif 000018
【図５】
0003585700.tif 000019
【図６】
0003585700.tif 000020
【図７】
0003585700.tif 000021
【図８】
0003585700.tif 000022
【図９】
0003585700.tif 000023
【図１０】
0003585700.tif 000024