(57)【要約】【課題】ネットワーク品質の時間変動を考慮して呼接続可否の判定を行うことができるとともに、ユーザ側から見た品質に基づく正確な判定を行うことができるようにする。【解決手段】リアルタイム系アプリケーションサービスのための呼接続要求に応じて、その際得られた要求元アプリケーション端末３でのネットワーク品質に基づき、呼制御装置１で、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値を推定し、そのユーザ体感品質保証値に基づき呼接続の可否を判定する。【選択図】  図１
2005295304.tif 000002
【特許請求の範囲】
【請求項１】
パケット網を介してリアルタイム系アプリケーションサービスを利用するアプリケーション端末からの呼接続要求に応じて呼接続可否の判定を行う呼制御装置において、
要求元アプリケーション端末でのネットワーク品質値を取得するネットワーク品質取得手段と、
前記ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末でユーザが体感するユーザ体感品質保証値を推定するユーザ体感品質推定手段と、
前記ユーザ体感品質保証値に基づき前記呼接続可否を判定し、その判定結果に基づき呼制御を行う呼制御手段とを備えることを特徴とする呼制御装置。
【請求項２】
請求項１に記載の呼制御装置において、
前記ユーザ体感品質推定手段は、前記ネットワーク品質値に対する前記ユーザ体感品質保証値の推定ばらつきを示す上限値または下限値をさらに推定し、
前記呼制御手段は、前記ユーザ体感品質保証値からなる第１の品質値と、その上限値または下限値からなる第２の品質値とに基づき前記呼接続可否を判定することを特徴とする呼制御装置。
【請求項３】
請求項１に記載の呼制御装置において、
前記ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定手段をさらに備え、
前記呼制御手段は、前記ユーザ体感品質保証値からなる第１の品質値と、前記ネットワーク品質推定手段で推定されたネットワーク品質値の上限値または下限値から前記ユーザ体感品質推定手段で推定されたユーザ体感品質保証値の上限値または下限値からなる第２の品質値に基づき前記呼接続可否を判定することを特徴とする呼制御装置。
【請求項４】
請求項１に記載の呼制御装置において、
前記ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質のばらつきを示す、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定手段をさらに備え、
前記ユーザ体感品質推定手段は、前記ネットワーク品質値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第１の品質値として推定するとともに、前記ネットワーク品質推定手段で推定された上限値または下限値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第２の品質値として推定し、これら第１および第２の品質値を時間変動が考慮されたユーザ体感品質保証値として出力し、
前記呼制御手段は、前記ユーザ体感品質推定手段からユーザ体感品質保証値として出力された第１および第２の品質値に基づき前記呼接続可否を判定することを特徴とする呼制御装置。
【請求項５】
請求項２〜４のいずれか１つに記載の呼制御装置において、
前記呼制御手段は、前記第１および第２の品質値のうち低品質側の値が所定のしきい値を満足した場合は要求された呼接続を行うとともに、高品質側の値が前記しきい値を満足しない場合は要求された呼接続を拒否し、両値の間にしきい値が存在する場合は、要求元アプリケーション端末に対して品質低下の可能性を通知した後、要求された呼接続を行うことを特徴とする呼制御装置。
【請求項６】
請求項１に記載の呼制御装置において、
ネットワーク品質値とユーザ体感品質保証値との対応関係を示す体感品質特性情報を記憶する記憶部をさらに備え、
前記ユーザ体感品質推定手段は、前記ネットワーク品質値に基づき前記体感品質特性情報を参照して、前記ユーザ体感品質保証値を推定することを特徴とする呼制御装置。
【請求項７】
請求項６に記載の呼制御装置において、
前記ネットワーク品質取得手段により前記アプリケーション端末からネットワーク品質値を逐次取得するとともに、当該ネットワーク品質値について前記ユーザ体感品質推定手段でユーザ体感品質保証値を推定して、これらネットワーク品質値とユーザ体感品質保証値との対を前記記憶部のデータベースへ順次蓄積し、当該データベースに蓄積されている各対に基づき前記体感品質特性情報を算出する品質特性管理手段をさらに備えることを特徴とする呼制御装置。
【請求項８】
請求項７に記載の呼制御装置において、
前記品質特性管理手段は、所定の測定周期内に設けられた複数の測定タイミングについて、管理対象となる対象アプリケーションが利用中の場合は、当該対象アプリケーションのパケットを利用したパッシブ測定により測定された前記アプリケーション端末でのネットワーク品質を取得し、当該測定周期内における測定回数が規定回数に達しない場合は、対象アプリケーションを擬似する擬似パケットを用いたアクティブ測定により測定された前記アプリケーション端末でのネットワーク品質値を取得することを特徴とする呼制御装置。
【請求項９】
パケット網を介してリアルタイム系アプリケーションサービスを利用するアプリケーション端末からの呼接続要求に応じて、呼制御装置で呼接続可否の判定を行う呼制御方法において、
要求元アプリケーション端末でのネットワーク品質値を取得するネットワーク品質取得ステップと、
前記ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末でユーザが体感するユーザ体感品質保証値を推定するユーザ体感品質推定ステップと、
前記ユーザ体感品質保証値に基づき前記呼接続可否を判定し、その判定結果に基づき呼制御を行う呼制御ステップとを備えることを特徴とする呼制御方法。
【請求項１０】
請求項９に記載の呼制御方法において、
前記ユーザ体感品質推定ステップは、前記ネットワーク品質値に対する前記ユーザ体感品質保証値の推定ばらつきを示す上限値または下限値をさらに推定し、
前記呼制御ステップは、前記ユーザ体感品質保証値からなる第１の品質値と、その上限値または下限値からなる第２の品質値とに基づき前記呼接続可否を判定することを特徴とする呼制御方法。
【請求項１１】
請求項９に記載の呼制御方法において、
前記ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定ステップをさらに備え、
前記呼制御ステップは、前記ユーザ体感品質保証値からなる第１の品質値と、前記ネットワーク品質推定ステップで推定されたネットワーク品質値の上限値または下限値から前記ユーザ体感品質推定ステップで推定されたユーザ体感品質保証値の上限値または下限値からなる第２の品質値に基づき前記呼接続可否を判定することを特徴とする呼制御方法。
【請求項１２】
請求項９に記載の呼制御方法において、
前記ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定ステップをさらに備え、
前記ユーザ体感品質推定ステップは、前記ネットワーク品質値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第１の品質値として推定するとともに、前記ネットワーク品質推定ステップで推定された上限値または下限値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第２の品質値として推定し、これら第１および第２の品質値を時間変動が考慮されたユーザ体感品質保証値として出力し、
前記呼制御ステップは、前記ユーザ体感品質推定ステップからユーザ体感品質保証値として出力された第１および第２の品質値に基づき前記呼接続可否を判定することを特徴とする呼制御方法。
【請求項１３】
請求項１０〜１２のいずれか１つに記載の呼制御方法において、
前記呼制御ステップは、前記第１および第２の品質値のうち低品質側の値が所定のしきい値を満足した場合は要求された呼接続を行うとともに、高品質側の値が前記しきい値を満足しない場合は要求された呼接続を拒否し、両値の間にしきい値が存在する場合は、要求元アプリケーション端末に対して品質低下の可能性を通知した後、要求された呼接続を行うことを特徴とする呼制御方法。
【請求項１４】
請求項９に記載の呼制御方法において、
当該呼制御装置の記憶部で、ネットワーク品質値とユーザ体感品質保証値との対応関係を示す体感品質特性情報を記憶するステップをさらに備え、
前記ユーザ体感品質推定ステップは、前記ネットワーク品質値に基づき前記体感品質特性情報を参照して、前記ユーザ体感品質保証値を推定することを特徴とする呼制御方法。
【請求項１５】
請求項１４に記載の呼制御方法において、
前記ネットワーク品質取得ステップにより前記アプリケーション端末からネットワーク品質値を逐次取得するとともに、当該ネットワーク品質値について前記ユーザ体感品質推定ステップでユーザ体感品質保証値を推定して、これらネットワーク品質値とユーザ体感品質保証値との対を前記記憶部のデータベースへ順次蓄積し、当該データベースに蓄積されている各対に基づき前記体感品質特性情報を算出する品質特性管理ステップをさらに備えることを特徴とする呼制御方法。
【請求項１６】
請求項１５に記載の呼制御方法において、
前記品質特性管理ステップは、所定の測定周期内に設けられた複数の測定タイミングについて、管理対象となる対象アプリケーションが利用中の場合は、当該対象アプリケーションのパケットを利用したパッシブ測定により測定された前記アプリケーション端末でのネットワーク品質を取得し、当該測定周期内における測定回数が規定回数に達しない場合は、対象アプリケーションを擬似する擬似パケットを用いたアクティブ測定により測定された前記アプリケーション端末でのネットワーク品質値を取得することを特徴とする呼制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御技術に関し、特にパケット網を介して映像配信やＴＶ会議などのようなリアルタイム系アプリケーションサービスを実現する際の呼を制御する呼制御技術に関する。
【背景技術】
【０００２】
映像配信やＴＶ会議などのリアルタイム系アプリケーションサービスの普及に伴い、これらリアルタイム系アプリケーションサービスの品質が重要視されつつある。これらアプリケーションでは、映像や音声などのメディアデータをパケットにより転送しているが、ネットワーク側の振る舞いによってパケットの遅延や損失が発生し、所望の音声や映像に劣化が生ずる。したがって、サービス提供側では、リアルタイム系アプリケーションサービスにおいて、サービス品質を管理することが重要となる。
【０００３】
従来、このようなサービス品質の管理という観点から、リアルタイム系アプリケーションサービスを実現する呼を制御する際、その呼のサービス品質に基づき呼制御を行う技術が研究されつつある（例えば、非特許文献１など参照）。
この種の呼制御技術では、アプリケーション端末からの接続要求時に、当該呼のネットワーク品質状態（例えば、回線使用率など）をＭＩＢ（Management Information Base）情報や擬似パケットにより、パッシブ方法やアクティブ方法で測定し、呼制御装置で呼接続の可否を判断するもとなっていた。
【０００４】
また、負荷分散されたサーバの処理能力を同時接続数などで推定して、接続先サーバの決定や接続可否を判断するものであった。
あるいは、呼接続時のネットワーク品質状態によって、データ転送方式（例えば、送信データを減らすなど）を変更し、サービス品質を満足させようとする機能もあった。
【０００５】
なお、出願人は、本明細書に記載した先行技術文献情報で特定される先行技術文献以外には、本発明に関連する先行技術文献を出願時までに発見するには至らなかった。
【特許文献１】特開２００２−０６４５３９号公報
【非特許文献１】外山ほか、「ＶｏＩＰネットワークにおけるコンスタント測定型アドミッションコントロール」、2002年電子情報通信学会総合大会、B-11-20
【非特許文献２】川口ほか、「ＱｏＳ制御下の映像配信サービスの主観品質推定モデル」、2003年電子情報通信学会総合大会、SB-7-1
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このような映像配信やＴＶ会議などのリアルタイム系アプリケーションサービスは、一般電話網（ＰＳＴＮ）を用いた固定電話とは異なり、１回の利用にかかる通信継続時間が比較的長いという特徴がある。また、映像配信やＴＶ会議は、電話網とは異なり品質が保証されないＩＰ網などのパケット網を利用したサービスである。そのため、接続中にネットワーク品質が変動する可能性が高い。
また、リアルタイム系アプリケーションサービスでは、サービスを利用するユーザが実際に体感する品質と、当該呼からパケットに基づき測定したパケット損失率などのネットワーク品質とにズレがある。
【０００７】
しかしながら、従来の呼制御技術では、要求時に測定したネットワーク品質のみに基づき呼接続の可否を判断するもとなっているため、接続後にネットワーク品質が劣化し、所望のサービス品質が維持できない場合も生ずるという問題点があった。また、ネットワーク品質に基づき呼接続の可否を判定しているため、ユーザ側から見た品質に基づく正確な判定ができないという問題点もあった。
【０００８】
本発明はこのような課題を解決するためのものであり、ネットワーク品質の時間変動を考慮して呼接続可否判定を行うことができるとともに、ユーザ側から見た品質に基づく正確な判定を行うことができる呼制御装置および方法を提供することを目的としている。
【課題を解決するための手段】
【０００９】
このような目的を達成するために、本発明にかかる呼制御装置は、パケット網を介してリアルタイム系アプリケーションサービスを利用するアプリケーション端末からの呼接続要求に応じて呼接続可否の判定を行う呼制御装置において、要求元アプリケーション端末でのネットワーク品質値を取得するネットワーク品質取得手段と、ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末でユーザが体感するユーザ体感品質保証値を推定するユーザ体感品質推定手段と、ユーザ体感品質保証値に基づき呼接続可否を判定し、その判定結果に基づき呼制御を行う呼制御手段とを備えるものである。
【００１０】
呼接続可否を判定の具体例として、ユーザ体感品質推定手段で、ネットワーク品質値に対するユーザ体感品質保証値の推定ばらつきを示す上限値または下限値をさらに推定し、呼制御手段で、ユーザ体感品質保証値からなる第１の品質値と、その上限値または下限値からなる第２の品質値とに基づき呼接続可否を判定するようにしてもよい。
【００１１】
あるいは、ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定手段をさらに備え、呼制御手段で、ユーザ体感品質保証値からなる第１の品質値と、ネットワーク品質推定手段で推定されたネットワーク品質値の上限値または下限値からユーザ体感品質推定手段で推定されたユーザ体感品質保証値の上限値または下限値からなる第２の品質値に基づき呼接続可否を判定するようにしてもよい。
【００１２】
あるいは、ネットワーク品質取得手段で取得されたネットワーク品質値について、ネットワーク品質のばらつきを示す、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定手段をさらに備え、ユーザ体感品質推定手段で、ネットワーク品質値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第１の品質値として推定するとともに、ネットワーク品質推定手段で推定された上限値または下限値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第２の品質値として推定し、これら第１および第２の品質値を時間変動が考慮されたユーザ体感品質保証値として出力し、呼制御手段で、ユーザ体感品質推定手段からユーザ体感品質保証値として出力された第１および第２の品質値に基づき呼接続可否を判定するようにしてもよい。
【００１３】
この際、呼制御手段で、第１および第２の品質値のうち低品質側の値が所定のしきい値を満足した場合は要求された呼接続を行うとともに、高品質側の値がしきい値を満足しない場合は要求された呼接続を拒否し、両値の間にしきい値が存在する場合は、要求元アプリケーション端末に対して品質低下の可能性を通知した後、要求された呼接続を行うようにしてもよい。
【００１４】
また、ユーザ体感品質保証値を推定について、ネットワーク品質値とユーザ体感品質保証値との対応関係を示す体感品質特性情報を記憶する記憶部をさらに備え、ユーザ体感品質推定手段は、ネットワーク品質値に基づき体感品質特性情報を参照して、ユーザ体感品質保証値を推定するようにしてもよい。
【００１５】
この際、ネットワーク品質取得手段によりアプリケーション端末からネットワーク品質値を逐次取得するとともに、当該ネットワーク品質値についてユーザ体感品質推定手段でユーザ体感品質保証値を推定して、これらネットワーク品質値とユーザ体感品質保証値との対を記憶部のデータベースへ順次蓄積し、当該データベースに蓄積されている各対に基づき体感品質特性情報を算出する品質特性管理手段をさらに備えてもよい。
【００１６】
さらに、品質特性管理手段で、所定の測定周期内に設けられた複数の測定タイミングについて、管理対象となる対象アプリケーションが利用中の場合は、当該対象アプリケーションのパケットを利用したパッシブ測定により測定されたアプリケーション端末でのネットワーク品質を取得し、当該測定周期内における測定回数が規定回数に達しない場合は、対象アプリケーションを擬似する擬似パケットを用いたアクティブ測定により測定されたアプリケーション端末でのネットワーク品質値を取得するようにしてもよい。
【００１７】
また、本発明にかかる呼制御方法は、パケット網を介してリアルタイム系アプリケーションサービスを利用するアプリケーション端末からの呼接続要求に応じて、呼制御装置で呼接続可否の判定を行う呼制御方法において、要求元アプリケーション端末でのネットワーク品質値を取得するネットワーク品質取得ステップと、ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末でユーザが体感するユーザ体感品質保証値を推定するユーザ体感品質推定ステップと、ユーザ体感品質保証値に基づき呼接続可否を判定し、その判定結果に基づき呼制御を行う呼制御ステップとを備えるものである。
【００１８】
呼接続可否を判定の具体例として、ユーザ体感品質推定ステップで、ネットワーク品質値に対するユーザ体感品質保証値の推定ばらつきを示す上限値または下限値をさらに推定し、呼制御ステップで、ユーザ体感品質保証値からなる第１の品質値と、その上限値または下限値からなる第２の品質値とに基づき呼接続可否を判定するようにしてもよい。
【００１９】
あるいは、ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定ステップをさらに備え、呼制御ステップで、ユーザ体感品質保証値からなる第１の品質値と、ネットワーク品質推定ステップで推定されたネットワーク品質値の上限値または下限値からユーザ体感品質推定ステップで推定されたユーザ体感品質保証値の上限値または下限値からなる第２の品質値に基づき呼接続可否を判定するようにしてもよい。
【００２０】
あるいは、ネットワーク品質取得ステップで取得されたネットワーク品質値について、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値または下限値を推定するネットワーク品質推定ステップをさらに備え、ユーザ体感品質推定ステップで、ネットワーク品質値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第１の品質値として推定するとともに、ネットワーク品質推定ステップで推定された上限値または下限値からネットワーク品質の時間変動が考慮されていないユーザ体感品質値を第２の品質値として推定し、これら第１および第２の品質値を時間変動が考慮されたユーザ体感品質保証値として出力し、呼制御ステップで、ユーザ体感品質推定ステップからユーザ体感品質保証値として出力された第１および第２の品質値に基づき呼接続可否を判定するようにしてもよい。
【００２１】
この際、呼制御ステップで、第１および第２の品質値のうち低品質側の値が所定のしきい値を満足した場合は要求された呼接続を行うとともに、高品質側の値がしきい値を満足しない場合は要求された呼接続を拒否し、両値の間にしきい値が存在する場合は、要求元アプリケーション端末に対して品質低下の可能性を通知した後、要求された呼接続を行うようにしてもよい。
【００２２】
また、ユーザ体感品質保証値を推定について、当該呼制御装置の記憶部で、ネットワーク品質値とユーザ体感品質保証値との対応関係を示す体感品質特性情報を記憶するステップをさらに備え、ユーザ体感品質推定ステップで、ネットワーク品質値に基づき体感品質特性情報を参照して、ユーザ体感品質保証値を推定するようにしてもよい。
【００２３】
この際、ネットワーク品質取得ステップによりアプリケーション端末からネットワーク品質値を逐次取得するとともに、当該ネットワーク品質値についてユーザ体感品質推定ステップでユーザ体感品質保証値を推定して、これらネットワーク品質値とユーザ体感品質保証値との対を記憶部のデータベースへ順次蓄積し、当該データベースに蓄積されている各対に基づき体感品質特性情報を算出する品質特性管理ステップをさらに備えてもよい。
【００２４】
さらに、品質特性管理ステップで、所定の測定周期内に設けられた複数の測定タイミングについて、管理対象となる対象アプリケーションが利用中の場合は、当該対象アプリケーションのパケットを利用したパッシブ測定により測定されたアプリケーション端末でのネットワーク品質を取得し、当該測定周期内における測定回数が規定回数に達しない場合は、対象アプリケーションを擬似する擬似パケットを用いたアクティブ測定により測定されたアプリケーション端末でのネットワーク品質値を取得するようにしてもよい。
【発明の効果】
【００２５】
本発明によれば、要求元アプリケーション端末でのネットワーク品質について、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末でユーザが体感するユーザ体感品質保証値が推定されて、そのユーザ体感品質保証値に基づき呼接続可否が判定されることから、ネットワーク品質の時間変動を考慮した呼接続可否判定を実現でき、呼接続された後にネットワーク品質が変動した場合でも、所望のサービス品質を維持することができる。
また、要求元アプリケーション端末で実際にユーザが体感する品質を示すユーザ体感品質保証値を用いて呼接続可否を判定するようにしたので、要求元アプリケーション端末で測定されたネットワーク品質とユーザの主観的な品質とのズレが判定から除外され、ユーザ側から見た品質に基づく正確な判定を行うことができる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明の実施の形態について図面を参照して説明する。
［第１の実施の形態］
まず、図１を参照して、本発明の第１の実施の形態にかかる呼制御システムについて説明する。図１は本発明の第１の実施の形態にかかる呼制御装置が適用される呼制御システムの構成例である。
【００２７】
この呼制御システムは、パケット網５に接続されたリアルタイム系アプリケーションサービスを利用する任意のアプリケーション端末３（３Ａ〜３Ｄ）からの呼接続要求について、呼制御装置１で、当該アプリケーション端末３でのネットワーク品質の時間変動を考慮したユーザ体感品質保証値に基づき呼接続可否を判断するシステムである。
【００２８】
この品質推定システムは、各アプリケーション端末３ごとに設けられて、当該アプリケーション端末３でのリアルタイム系アプリケーションサービスに関するネットワーク品質値を測定するネットワーク品質測定装置２（２Ａ〜２Ｄ）と、ネットワーク品質測定装置２で得られたネットワーク品質値に基づき、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値を推定し、その推定結果に基づき呼接続要求元アプリケーション端末３の呼接続可否を判断する呼制御装置１とから構成されている。
【００２９】
アプリケーション端末３は、全体としてコンピュータからなり、各種アプリケーション（ソフトウェア）をコンピュータで実行することにより、各種コミュニケーション機能を実現する。この際、アプリケーションとしてリアルタイム系アプリケーションを実行することにより、パケット網５を介して他のアプリケーション端末３とパケット通信を行い、映像配信やＴＶ会議などのコミュニケーションを実現する。
ネットワーク品質測定装置２は、コンピュータを利用して、所定の経路得を流れるパケットをキャプチャし、対応するアプリケーション端末３での任意のアプリケーションに関するネットワーク品質を測定する装置である。
【００３０】
［呼制御装置］
次に、図２を参照して、本発明の第１の実施の形態にかかる呼制御装置について説明する。図２は本発明の第１の実施の形態にかかる呼制御装置の構成を示すブロック図である。
呼制御装置１は、パケット網５に接続されて、リアルタイム系アプリケーションを利用するアプリケーション端末３（３Ａ〜３Ｄ）からの呼接続要求に応じて、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値に基づき呼接続可否を判定する装置である。
【００３１】
この呼制御装置１は、全体としてコンピュータを有するサーバ装置などの情報処理装置からなり、通信インターフェース部（以下、通信Ｉ／Ｆ部という）１１、記憶部１２、制御部１３が設けられている。
通信Ｉ／Ｆ部１１は、パケット網５を介して他の装置とパケット通信を行う回路部である。
【００３２】
記憶部１２は、メモリやハードディスクなどの記憶装置からなり、制御部１３での処理に用いる各種情報やプログラムを記憶する。記憶部１２で記憶される各種情報としては、データベース１２Ａ、体感品質特性情報１２Ｂ、ネットワーク品質特性情報１２Ｃがある。
データベース１２Ａは、過去に得られたネットワーク品質とユーザ体感品質とを対として蓄積する情報である。
【００３３】
体感品質特性情報１２Ｂは、アプリケーション端末３でのネットワーク品質値と、ネットワーク品質の時間変動を考慮した、当該アプリケーション端末３でユーザが体感する品質を示すユーザ体感品質保証値との対応関係を示す情報である。
ネットワーク品質特性情報１２Ｃは、アプリケーション端末３でのネットワーク品質値と、そのネットワーク品質値の時間変動との対応関係を示す情報である。
【００３４】
制御部１３は、ＣＰＵなどのマイクロプロセッサとその周辺回路からなり、記憶部１２のプログラムを読み込んで実行することにより、上記ハードウェアとプログラムとを協働させて各種機能手段を実現する機能部である。
制御部１３で実現される機能手段としては、ネットワーク品質取得手段１３Ａ、ユーザ体感品質推定手段１３Ｂ、呼制御手段１３Ｃ、ネットワーク品質推定手段１３Ｄ、および品質特性管理手段１３Ｅがある。
【００３５】
ネットワーク品質取得手段１３Ａは、ネットワーク品質測定装置２との間で通信Ｉ／Ｆ部１１およびパケット網５を介して制御パケットを送受信することにより、各アプリケーション端末３での任意の呼に関する各種ネットワーク品質情報を取得する機能手段である。
なお、各呼から取得されるネットワーク品質としては、例えば、パケットの損失率、遅延量、遅延揺らぎ等、ネットワークの物理的（回線速度等）要因や背景負荷（他のトラヒックの利用状況）によって生じるものがある。
【００３６】
ユーザ体感品質推定手段１３Ｂは、ネットワーク品質取得手段１３Ａでネットワーク品質測定装置２から取得したネットワーク品質値に基づき、記憶部１２の体感品質特性情報１２Ｂを参照して、そのネットワーク品質の時間的変動が考慮された、呼接続要求元のアプリケーション端末３で当該呼からユーザが体感するユーザ体感品質保証値を推定する機能手段である。
このユーザ体感品質保証値は、アプリケーション接続期間に相当する所定期間におけるネットワーク品質の時間変動を考慮して推定された、当該期間内におけるユーザ体感品質の変動を保証する値である。
【００３７】
呼制御手段１３Ｃは、ユーザ体感品質推定手段１３Ｂで推定されたユーザ体感品質保証値に基づき、呼接続要求元のアプリケーション端末３に対する呼接続可否を判定し、呼接続可の判定結果に応じて呼接続要求元のアプリケーション端末３と所望の相手先アプリケーション端末３との間の呼接続を行う機能手段である。
ネットワーク品質推定手段１３Ｄは、ネットワーク品質取得手段１３Ａでネットワーク品質測定装置２から取得したネットワーク品質値に基づき、記憶部１２のネットワーク品質特性情報１２Ｃを参照して、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の上限値ＤHおよび下限値ＤLを推定する機能手段である。
【００３８】
品質特性管理手段１３Ｅは、ネットワーク品質取得手段１３Ａでネットワーク品質測定装置２から取得したネットワーク品質値に基づき、記憶部１２の体感品質特性情報１２Ｂさらにはネットワーク品質特性情報１２Ｃを生成し更新する機能手段である。
【００３９】
［第１の実施の形態の動作］
次に、図３を参照して、本実施の形態にかかる呼制御装置１の動作について説明する。図３は、本実施の形態にかかる呼制御装置１での呼制御処理を示すフローチャートである。
呼制御装置１の制御部１３は、パケット網５および通信Ｉ／Ｆ部１１を介してアプリケーション端末３から通知されたリアルタイム系アプリケーションサービスのための呼接続要求を受信し、図３の呼制御処理を開始する。
【００４０】
まず、制御部１３は、ネットワーク品質取得手段１３Ａにより、通信Ｉ／Ｆ部１１およびパケット網５を介して当該リアルタイム系アプリケーションサービスを利用するアプリケーション端末３について、そのネットワーク品質測定装置２で測定されたネットワーク品質値を取得する（ステップ１００）。
【００４１】
次に、制御部１３は、ユーザ体感品質推定手段１３Ｂにより、上記ネットワーク品質値に基づき、記憶部１２の体感品質特性情報１２Ｂを参照して、ネットワーク品質の時間変動が考慮された、呼接続要求元のアプリケーション端末３でユーザが体感するユーザ体感品質保証値を推定する（ステップ１０１）。
このユーザ体感品質保証値は、アプリケーション接続期間に相当する所定期間におけるネットワーク品質の時間変動を考慮して推定された、当該期間内におけるユーザ体感品質の変動を保証する値からなり、例えば非特許文献２などの公知の技術により求めることができる。
【００４２】
非特許文献２を用いる場合、平均品質、劣化重み、品質変動量、および劣化発生位置などのパラメータが必要とされる。
このうち、平均品質は、短時間における品質とされるため、ネットワーク品質尺度により、短時間の平均品質を推定可能な手法で算出する。具体的には、アプリケーション接続中のメディアデータから、例えば数秒から１分程度の短時間ごとにネットワーク品質値を取得し、ネットワーク品質の時間変動が考慮されていないユーザ体感品質値を各ネットワーク品質値ごとに推定し、これを平均化すれば上記平均品質を推定できる。
【００４３】
なお、上記ユーザ体感品質値については、ネットワーク品質とユーザ体感品質値との対応関係を示す推定モデルを参照して、当該呼でのネットワーク品質の測定結果に対応するユーザ体感品質値を推定できる（例えば、特許文献１など参照）。
劣化重みは、リアルタイム系アプリケーションサービスを構成するそれぞれの呼あるいは区間が持つ、ユーザ体感品質に対する影響度を示すものであり、各サービスごとに予め設定しておく。一般的には、各区間のうち低品質区間の影響がユーザ体感品質において支配的と考えられている。
【００４４】
品質変動量は、アプリケーション接続中の品質変動、例えば上記平均品質を算出する際の分散や標準偏差、あるいは９５％信頼区間などによって決定すればよい。
劣化発生位置は、アプリケーション接続期間内における劣化の発生時間位置であり、ＭＩＢ（Management Information Base）情報などで取得される。ユーザ体感品質に対する劣化発生の影響度は、その発生時間位置により大きく変化するため、劣化発生位置に基づきユーザ体感品質が補正される。一般には、アプリケーション接続期間の終了時点に近いほどその影響度が大きいと考えられている。
【００４５】
図４は、体感品質特性情報１２Ｂの一例を示すグラフである。図４において、各ドットはデータベース１２Ａに蓄積されている過去のデータであり、これらデータに含まれるネットワーク品質値（例えば、パケット損失率）とユーザ体感品質保証値との対が各ドットとしてグラフにプロットされている。
特性２００は、これらドットの分布から推定された回帰曲線などの推定モデル、すなわち任意のネットワーク品質値に対応するユーザ品質体感保証値を示す曲線である。特性２０１，２０２は、例えば９５％などの所定信頼区間における上限および下限を示す曲線であり、任意のネットワーク品質に対するユーザ体感品質保証値の推定ばらつきを示している。
【００４６】
制御部１３は、このようにして、ユーザ体感品質推定手段１３Ｂにより、図３のステップ１０１で、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値を推定した後、呼制御手段１３Ｃにより、上記ユーザ体感品質の平均値と所定の品質目標値を示すしきい値とを比較する（ステップ１０２）。
ここで、平均値がしきい値を満たす場合は（ステップ１０３：ＹＥＳ）、リアルタイム系アプリケーションサービスのための呼を接続した後のサービス品質が目標値を満たすと予想されることから、要求された当該呼接続を実行し（ステップ１０４）、一連の呼制御処理を終了する。
【００４７】
また、平均値がしきい値を満たさない場合は（ステップ１０３：ＮＯ）、リアルタイム系アプリケーションサービスのための呼を接続した後のサービス品質が目標値を満たさない可能性が高いことから、要求された当該呼接続を拒否し（ステップ１０５）、一連の呼制御処理を終了する。
【００４８】
したがって、図４の例では、取得したネットワーク品質がＤ1の場合、このＤ1から特性２００により推定されたユーザ体感品質保証値ＳA1としきい値ＳTHとが図３のステップ１０２で比較され、この場合はＳA1≧ＳTHであることから、ステップ１０３：ＹＥＳを経てステップ１０４で呼接続が行われる。
一方、取得したネットワーク品質がＤ2の場合、このＤ2から特性２００により推定されたユーザ体感品質保証値ＳA2はＳA2＜ＳTHとなり、ステップ１０３：ＮＯを経てステップ１０５で呼接続要求が拒否される。
【００４９】
このように、リアルタイム系アプリケーションサービスのための呼接続要求に応じて、その際得られた要求元アプリケーション端末でのネットワーク品質に基づき、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値を推定し、そのユーザ体感品質保証値に基づき呼接続の可否を判定するようにしたので、ネットワーク品質の時間変動を考慮して呼接続可否判定を行うことができ、この判定に基づき呼接続された後にネットワーク品質が変動した場合でも、所望のサービス品質を維持することができる。
【００５０】
また、要求元アプリケーション端末で実際にユーザが体感する品質を示すユーザ体感品質保証値を用いて呼接続可否を判定するようにしたので、要求元アプリケーション端末で測定されたネットワーク品質とユーザの主観的な品質とのズレが判定から除外され、ユーザ側から見た品質に基づく正確な判定を行うことができる。
【００５１】
［第２の実施の形態］
次に、図５を参照して、本発明の第２の実施の形態にかかる呼制御装置について説明する。図５は、本発明の第２の実施の形態にかかる呼制御装置による呼接続可否の判定例を示す説明図である。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
【００５２】
前述した第１の実施の形態では、図３のステップ１０３において、特性２００から推定されたユーザ体感品質保証値としきい値との比較結果に基づき呼接続の可否を判定する場合を例として説明したが、これに限定されるものではなく、サービス提供側のポリシに基づき、特性２０１や特性２０２を用いた他の判定方法を用いてもよい。
本実施の形態では、特性２００とその下限値を示す特性２０２を用いで呼接続の可否を判定する場合について説明する。
【００５３】
制御部１３では、図３のステップ１００，１０１を実行した後、呼制御手段１３Ｃにより、特性２００から推定されたユーザ体感品質保証値（平均値）および特性２０２から推定された下限値と、しきい値とをそれぞれ比較する。
ここで、上記平均値がしきい値ＳTHを満足していなければ、図３と同様に呼接続要求を拒否する。また、特性２０２により推定されたユーザ体感品質保証値の下限値がしきい値ＳTHを満足している場合は、呼接続後のサービス品質が確実に目標値を満たすと予想されることから呼接続を行う。
【００５４】
そして、上記平均値がしきい値を満足しているものの、下限値がしきい値を満足しない場合は、呼接続後のサービス品質がある程度目標値を満たすと予想されることから、要求元アプリケーション端末３に対して、品質低下の可能性があることをメッセージで通知し、呼接続を行う。
【００５５】
したがって、図５の例では、取得したネットワーク品質Ｄ1の場合、このＤ1から特性２０２により推定されたユーザ体感品質保証値の下限値ＳL1がＳL1≧ＳTHであることから呼接続が行われる。一方、取得したネットワーク品質がＤ2の場合、このＤ2から特性２００により推定されたユーザ体感品質保証値ＳA2はＳA2＜ＳTHとなり呼接続要求が拒否される。
また、取得したネットワーク品質がＤ3の場合、このＤ3から特性２００により推定されたユーザ体感品質保証値ＳA3はＳA3≧ＳTHであるものの、Ｄ3から特性２０２により推定された下限値ＳL3がＳL3＜ＳTHであることから、品質低下可能性が通知された後、呼接続が行われる。
【００５６】
このように、取得したネットワーク品質値に対応するユーザ体感品質保証値（第１の品質値）に加えて、当該ユーザ体感品質保証の推定ばらつきを考慮した上限値または下限値（第２の品質値）を推定し、これら両品質値を用いて呼接続可否を判定するようにしたので、図３と比較して、ユーザ体感品質保証値の推定ばらつきを考慮した呼接続制御を実現できる。
【００５７】
また、これら複数のユーザ体感品質保証値（第１および第２の品質値）のそれぞれをしきい値と比較し、そのうち低品質側のユーザ体感品質保証値がしきい値を満足した場合は接続可と判断するとともに、高品質側のユーザ体感品質保証値がしきい値を満足しない場合は接続不可と判断し、両ユーザ体感品質保証値の間にしきい値が存在する場合は、要求元アプリケーション端末３に対して品質低下の可能性を通知した後、呼接続するようにしたので、１つの品質値で判定する場合と比較して、より柔軟な呼制御を実現できる。
【００５８】
この際、平均値、上限値、下限値について共通したしきい値ではなく、複数のしきい値と比較して呼接続可否を判定してもよい。
また、以上で説明した呼接続可否判定において、ユーザ体感品質保証値（平均値）に代えて上限値を用い、下限値に代えて平均値を用いてもよく、上記と比較して緩やかな基準に基づく呼接続可否判定を実現できる。
なお、図３において、ユーザ体感品質保証値（平均値）に代えて上限値あるいは下限値を用いた呼接続可否判定を行ってもよい。
【００５９】
［第３の実施の形態］
次に、図６および図７を参照して、本発明の第３の実施の形態にかかる呼制御装置について説明する。図６は、本発明の第３の実施の形態にかかる呼制御装置で用いるネットワーク品質特性情報１２Ｃの一例を示すグラフである。図７は、本発明の第３の実施の形態にかかる呼制御装置による呼接続可否の判定例を示す説明図である。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
【００６０】
前述した第２の実施の形態では、特性２０２から推定された下限値を用いた場合について説明した。本実施の形態では、要求元アプリケーション端末３から得られたネットワーク品質値の上限値や下限値に対応するユーザ体感品質保証値を用いて、呼接続可否判定を行う場合について説明する。
【００６１】
ネットワーク品質値の上限値や下限値については、図６に示すような、記憶部１２のネットワーク品質特性情報１２Ｃに基づき推定できる。
ここでは、時刻ごとにネットワーク品質値を測定し、その分布に基づき時刻とネットワーク品質値との対応関係を示したものであり、特性２１０はその平均値を示す曲線である。また、特性２１１，２１２は、それぞれの時刻におけるネットワーク品質のばらつきを示す上限値および下限値であり、例えば分散、標準偏差、９５％信頼区間などに基づき決定される。
【００６２】
制御部１３では、ユーザ体感品質推定手段１３Ｂにより、上記のようなネットワーク品質特性情報１２Ｃを参照して、要求元アプリケーション端末３から得られたネットワーク品質値の取得時刻における、当該平均値に対する上限値および下限値の変動幅を取得し、その変動幅に基づき要求元アプリケーション端末３から得られたネットワーク品質値の上限値および下限値を得る。
次に、これらネットワーク品質値の上限値および下限値ごとに、体感品質特性情報１２Ｂを参照して、ユーザ体感品質保証値をそれぞれ推定することにより、特性２０１，２０２から推定された下限値、上限値に代わる、ユーザ体感品質保証値の上限値および下限値を特性２００から推定する。
【００６３】
そして、制御部１３は、呼制御手段１３Ｃにより、ネットワーク品質値の上限値および下限値から特性２００により推定したユーザ体感品質保証値の上限値および下限値に基づき、図７に示すような呼接続可否判定を行う。
したがって、図７の例では、取得したネットワーク品質Ｄ1の場合、その下限値ＤL1から特性２００により推定されたユーザ体感品質保証値の下限値ＳL1がＳL1≧ＳTHであることから呼接続が行われる。一方、取得したネットワーク品質がＤ2の場合、このＤ2から特性２００により推定されたユーザ体感品質保証値ＳA2がＳA2＜ＳTHであることから呼接続要求が拒否される。
【００６４】
また、取得したネットワーク品質がＤ3の場合、このＤ3から特性２００により推定されたユーザ体感品質保証値ＳA3はＳA3≧ＳTHであるものの、Ｄ3の下限値ＤL3から特性２００により推定された下限値ＳL3がＳL3＜ＳTHであることから、要求元アプリケーション端末３に対して品質低下可能性が通知された後、呼接続が行われる。
これにより、ネットワーク品質の変動を重視した呼接続可否判定を実現できる。また、体感品質特性情報１２Ｂとして、特性２００を用意しておけばよいことになる。
【００６５】
なお、以上の各実施の形態において、体感品質特性情報１２Ｂについては、各特性２００〜２０２を示す回帰曲線の方程式として記憶部１２で保持してもよく、数値からなるテーブル形式で保持してもよい。また、ネットワーク品質特性情報１２Ｃについても同様であり、特性２１０〜２１２を示す回帰曲線の方程式や、ネットワーク品質の時系列変化を表す数式、例えばポアソン分布などを用いた確率分布の方程式として記憶部１２で保持してもよく、数値からなるテーブル形式で保持してもよい。
【００６６】
［第４の実施の形態］
次に、図８を参照して、本発明の第４の実施の形態にかかる呼制御装置について説明する。図８は、本発明の第４の実施の形態にかかる呼制御装置での呼接続可否判定を示す説明図である。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
【００６７】
前述した各実施の形態では、ユーザ体感品質保証値としきい値とを比較する場合について説明した。本実施の形態では、当該しきい値に対応するネットワーク品質値の基準値を求めておき、この基準値とネットワーク品質値との比較結果に基づき呼接続可否を判定する場合について説明する。なお、本実施の形態は、ネットワーク品質値とユーザ体感品質保証値とが一意に対応する単調関数で表現できる場合を前提としている。
【００６８】
ネットワーク品質とユーザ体感品質保証値との対応関係を示す体感品質特性が、図８に示すような、特性２００〜２０２で表現される場合、所定の品質目標値を示すしきい値ＳTHと、これら特性２００〜２０２との交点から、しきい値ＳTHに対応するネットワーク品質値の基準値ＤTHA，ＤTHH，ＤTHLが求まる。
したがって、要求元アプリケーション端末３のネットワーク品質値Ｄを各基準値とを比較すればよい。
【００６９】
例えば、ＤTHLは、特性２０２すなわちユーザ体感品質値の下限値に対応する基準値であることから、下限値ＤLがＤTHLを満足する場合、呼接続を実行すればよい。
また、Ｄ≧ＤTHAであって、かつＤ＜ＤTHLの範囲では、品質低下の可能性を要求元アプリケーション端末３へ通知した後、呼接続を行えばよい。
【００７０】
［第５の実施の形態］
次に、図９〜図１１を参照して、本発明の第５の実施の形態にかかる呼制御装置について説明する。図９は、本発明の第５の実施の形態にかかる呼制御装置での呼制御処理を示すフローチャートである。図１０は、本発明の第５の実施の形態にかかる呼制御装置による呼接続可否の判定例を示す説明図である。図１１は、本発明の第５の実施の形態にかかる呼制御装置による呼接続可否の他の判定例を示す説明図である。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
【００７１】
前述した各実施の形態では、体感品質特性情報１２Ｂとして、ネットワーク品質と時間変動を考慮したユーザ体感品質保証値との対応関係を用いて、要求元アプリケーション端末３のネットワーク品質値に基づき、ユーザ体感品質保証値を推定する場合を例として説明した。
本実施の形態では、体感品質特性情報１２Ｂとして、ネットワーク品質と時間変動を考慮していないユーザ体感品質値との対応関係を用いて、ユーザ体感品質保証値を推定する場合について説明する。
【００７２】
まず、制御部１３は、ネットワーク品質取得手段１３Ａにより、通信Ｉ／Ｆ部１１およびパケット網５を介して当該リアルタイム系アプリケーションサービスを利用するアプリケーション端末３について、そのネットワーク品質測定装置２で測定されたネットワーク品質値Ｄを取得する（ステップ１１０）。
次に、制御部１３は、ネットワーク品質推定手段１３Ｄにより、上記ネットワーク品質値Ｄに基づき、記憶部１２のネットワーク品質特性情報１２Ｃを参照して、Ｄの分布ばらつきを、ネットワーク品質の時間変動が考慮された、当該ネットワーク品質値の下限値ＤL（上限値ＤH）と見なして推定する（ステップ１１１）。
【００７３】
そして、制御部１３は、ユーザ体感品質推定手段１３Ｂにより、記憶部１２の体感品質特性情報１２Ｂを参照して、これらネットワーク品質値Ｄ、その下限値ＤLについて、ネットワーク品質の時間変動が考慮されていない、呼接続要求元のアプリケーション端末３でユーザが体感するユーザ体感品質値ＳA，ＳLをそれぞれ推定する（ステップ１１２）。
本実施の形態では、このようにして得られたユーザ体感品質値ＳAや下限値ＳLが、ネットワーク品質の時間変動が考慮されたユーザ体感品質保証値に相当することになる。
【００７４】
その後、制御部１３は、呼制御手段１３Ｃにより、上記ユーザ体感品質値（平均値）ＳAおよびユーザ体感品質保証値ＳLと、所定の品質目標値を示すしきい値ＳTHとを比較する（ステップ１１３）。
ここで、平均値ＳAがしきい値ＳTHを満たさない場合は（ステップ１１４：ＮＯ）、リアルタイム系アプリケーションサービスのための呼を接続した後のサービス品質が目標値を満たさない可能性が高いことから、要求された当該呼接続を拒否し（ステップ１１５）、一連の呼制御処理を終了する。
【００７５】
一方、平均値ＳAがしきい値ＳTHを満たす場合は（ステップ１１４：ＹＥＳ）、下限値ＳLとしきい値とを比較する（ステップ１１６）。そして、下限値ＳLがしきい値ＳTHを満たす場合は（ステップ１１６：ＹＥＳ）、リアルタイム系アプリケーションサービスのための呼を接続した後のサービス品質が目標値を満たすと予想されることから、要求された当該呼接続を実行し（ステップ１１７）、一連の呼制御処理を終了する。
また、下限値ＳLがしきい値ＳTHを満たさない場合は（ステップ１１６：ＮＯ）、呼接続後のサービス品質がある程度目標値を満たすと予想されることから、要求元アプリケーション端末３に対して、品質低下の可能性があることをメッセージで通知し（ステップ１１８）、ステップ１１７へ移行して呼接続を行った後、一連の呼制御処理を終了する。
【００７６】
したがって、図１０の例では、取得したネットワーク品質Ｄ1の場合、その下限値ＤL1から特性２００により推定されたユーザ体感品質保証値の下限値ＳL1がＳL1≧ＳTHであることから呼接続が行われる。一方、取得したネットワーク品質がＤ2の場合、このＤ2から特性２００により推定されたユーザ体感品質保証値ＳA2がＳA2＜ＳTHであることから呼接続要求が拒否される。
【００７７】
また、図１１の例では、取得したネットワーク品質がＤ3の場合、このＤ3から特性２００により推定されたユーザ体感品質保証値ＳA3はＳA3≧ＳTHであるものの、Ｄ3の下限値ＤL3から特性２００により推定された下限値ＳL3がＳL3＜ＳTHであることから、要求元アプリケーション端末３に対して品質低下可能性が通知された後、呼接続が行われる。
これにより、体感品質特性情報１２Ｂとして、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値を用いた特性を用意しておく必要がなくなり、比較的複雑な体感品質特性情報１２Ｂの生成処理を省くことができ、呼制御装置１の処理負担を大幅に軽減できる。
【００７８】
なお、上記平均値、上限値、下限値について共通した１つのしきい値ではなく、複数のしきい値と比較して呼接続可否を判定してもよい。
また、以上で説明した呼接続可否判定において、ユーザ体感品質保証値（平均値）に代えて上限値を用い、下限値に代えて平均値を用いてもよく、上記と比較して緩やかな基準に基づく呼接続可否判定を実現できる。
【００７９】
［第６の実施の形態］
次に、図１２を参照して、本発明の第６の実施の形態にかかる呼制御装置について説明する。図１２は、本発明の第６の実施の形態にかかる呼制御装置での品質特性管理処理を示すフローチャートである。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
本実施の形態では、記憶部１２の体感品質特性情報１２Ｂさらにはネットワーク品質特性情報１２Ｃを生成し更新する品質特性管理動作について説明する。
【００８０】
呼制御装置１の制御部１３は、周期的あるいは任意の測定タイミングに、図１２の品質特性管理処理を開始する。
まず、制御部１３は、ネットワーク品質取得手段１３Ａにより、アプリケーション端末３について、そのネットワーク品質測定装置２で測定されたネットワーク品質値を取得する（ステップ１２０）。
【００８１】
次に、制御部１３は、ユーザ体感品質推定手段１３Ｂにより、アプリケーション端末３のネットワーク品質値に基づき、ネットワーク品質の時間変動を考慮して、呼接続要求元のアプリケーション端末３でユーザが体感するユーザ体感品質保証値を推定する（ステップ１２１）。
ネットワーク品質の時間変動を考慮したユーザ体感品質保証値については、第１の実施の形態で説明したように、例えば非特許文献２などの公知の技術により求めることができる。
【００８２】
続いて、制御部１３は、体感品質特性管理手段１３Ｅにより、上記ネットワーク品質値とユーザ体感品質値保証値との対を記憶部１２のデータベース１２Ａに格納する（ステップ１２２）。
そして、データベース１２Ａを参照して、ネットワーク品質値とユーザ体感品質値保証値との対応関係を算出し、その対応関係を体感品質特性情報１２Ｂとして記憶部１２へ格納更新する（ステップ１２３）。
【００８３】
また、データベース１２Ａを参照して、ネットワーク品質値と時刻との対応関係を算出し、その対応関係をネットワーク品質特性情報１２Ｃとして記憶部１２へ格納更新し（ステップ１２４）、一連の品質特性管理処理を終了する。
これにより、品質特性管理処理を実行するごとに、体感品質特性情報１２Ｂさらにはネットワーク品質特性情報１２Ｃが更新されるものとなり、呼接続可否判定に常時最新の特性情報を利用することができる。
【００８４】
なお、ステップ１２３，１２４において、ある程度古いデータについては削除するようにしてもよく、ネットワーク、装置、さらにはアプリケーションの性能変化にも適切に追従できる。
また、ステップ１２１では、ネットワーク品質の時間変動を考慮したユーザ体感品質保証値に代えて、ネットワーク品質の時間変動を考慮していないユーザ体感品質値を算出するようにしてもよく、前述した第５の実施の形態に対応できる。
【００８５】
［第７の実施の形態］
次に、図１３および図１４を参照して、本発明の第７の実施の形態にかかる呼制御装置について説明する。図１３は、本発明の第７の実施の形態にかかる呼制御装置でのタイミング管理処理を示すフローチャートである。図１４は、本発明の第７の実施の形態にかかる呼制御装置でのタイミング管理動作を示すタイミングチャートである。なお、呼制御装置１の構成については前述した第１の実施の形態（図２参照）と同様であり、ここでの詳細な説明は省略する。
【００８６】
前述した第６の実施の形態では、品質特性管理処理について説明した。本実施の形態では、この品質特性管理処理の実行タイミングを管理するタイミング管理処理について説明する。
前述した品質特性管理処理は、ネットワーク品質の時間変動を考慮する必要があるため、所定の期間ごとに実行する必要がある。制御部１３は、所定周期ごとに品質特性管理手段１３Ｅを制御して、図１３のタイミング管理処理を実行する。
【００８７】
まず、所定周期内に数回の割合で一定間隔ごとに設定されている測定タイミングが到来するまで待機し（ステップ１３０）、測定タイミングの到来に応じて（ステップ１３０：ＹＥＳ）、アプリケーション端末３において、当該端末３でやり取りされているパケットを監視することにより、呼制御対象となるアプリケーションが利用さているか確認する（ステップ１３１）。
この際、アプリケーションが利用されている場合にのみ（ステップ１３１：ＹＥＳ）、パッシブ測定による品質特性管理処理を実行し（ステップ１３２）、当該測定周期内での最終測定タイミングに達するまで（ステップ１３３：ＮＯ）、ステップ１３０へ戻って次の測定に備える。
【００８８】
このパッシブ測定とは、品質測定の対象となる経路で流れている対象アプリケーションのパケットを利用して、ネットワーク品質を測定する方式である。パッシブ測定によって得る情報は、以下の２つのネットワーク品質情報である。
・管理対象ネットワークのネットワーク品質（状態）情報
・アプリケーションのユーザ体感品質推定に必要なネットワーク品質情報
管理対象エリアのネットワーク品質状態は、全てパッシブ測定によって行う。例えば、呼制御装置１が、管理対象ネットワーク中の各ノード（具体的にはルータなど）から、ＳＮＭＰ（Simple Network Management Protocol）などのプロトコルを利用し、ノード中のＭＩＢ情報を定常的に得る。その情報より、ネットワーク中の帯域使用率やパケット損失率、ＣＰＵ使用率等の情報を得る。また、それらの情報を定常的に得ることで、品質の時間変動を把握可能とする。
【００８９】
アプリケーションのユーザ体感品質推定に必要なネットワーク品質情報は、図１に示したネットワーク品質測定装置２を利用して、アプリケーションの実行時に、必要な情報を得る。このネットワーク品質測定装置２は、ＩＥＴＦ  ＲＦＣ３６１１  ＲＴＣＰ  ＸＲのような枠組で構成され、アプリケーション端末３での品質状態をレポートする機能を有する。そして、ネットワーク品質測定装置２でＭＩＢ情報として保存されているネットワーク品質情報を、ＳＮＭＰなどのプロトコルを利用して呼制御装置１が得ることで、時間変動を考慮したユーザ体感品質を推定する。
【００９０】
その後、図１３のステップ１３３において、最終測定タイミングに達している場合は（ステップ１３３：ＹＥＳ）、当該測定周期内での測定回数が不足しているか判断し、不足している場合には（ステップ１３５：ＹＥＳ）、不足分がなくなるまで、アクティブ測定による品質特性管理処理を実行し（ステップ１３６）、当該測定周期内での測定回数が所定の回数に達した場合には（ステップ１３５：ＮＯ）、一連のタイミング管理処理を終了する。
【００９１】
ここで、アクティブ測定は、品質測定の対象となる経路で、ユーザパケットとは別個に測定用の擬似パケットを流し、ネットワーク品質を測定する方式である。アクティブ測定は、以下の情報を得るために実施する。
・周期中で得ることができなかった、アプリケーションのユーザ体感品質推定に必要なネットワーク品質情報
上記の情報を得るために、アプリケーションを模擬した擬似パケットを、図１に示したネットワーク品質測定装置２によって送受信する。そして、上記パッシブ測定と同様にしてアプリケーションのユーザ体感品質推定に必要なネットワーク品質情報を得る。
【００９２】
図１４の例では、測定周期Ｔ１，Ｔ２ごとに５つの測定タイミングｔ１〜ｔ５が等間隔でそれぞれ設けられている。この際、対象アプリケーションが測定周期Ｔ１の測定タイミングｔ１〜ｔ２の間に開始され、測定周期Ｔ２の測定タイミングｔ２〜ｔ３の間に終了している。また、１測定周期内での規定測定回数は３回とする。
まず、測定周期Ｔ１では、測定タイミングｔ１で対象アプリケーションが利用されていないのでパッシブ測定が行われず、それ以降の測定タイミングｔ２〜ｔ５では対象アプリケーションが利用されているためパッシブ測定が行われる。そして、これらパッシブ測定の回数が４回であり規定測定回数３に達していることから、アクティブ測定は行われない。
【００９３】
一方、測定周期Ｔ２では、測定タイミングｔ１，ｔ２で対象アプリケーションが利用されているためパッシブ測定が行われ、測定タイミングｔ３〜ｔ５で対象アプリケーションが利用されていないのでパッシブ測定が行われない。この際、最終測定タイミングｔ５において測定周期Ｔ２内での測定回数２回であり、規定測定回数３に達していないことから、アクティブ測定が１回行われる。
【００９４】
このように、測定周期内で対象アプリケーションのパケットを利用したパッシブ測定によりネットワーク品質を測定し、当該測定周期内でパッシブ測定による測定回数が不足している場合には、ユーザパケットとは別個の擬似パケットを用いたアクティブ測定により規定測定回数に達するまでネットワーク品質を測定するようにしたので、擬似パケットによるユーザのアプリケーション品質へ影響を最低限に抑制しつつ、各測定周期内で規定測定回数分のネットワーク品質を得ることができ、ネットワーク品質の時間変化を的確に捉えることができる。
【００９５】
なお、アクティブ測定については、ユーザのアプリケーション要求があった場合、その時点でアクティブ測定を中止し、ユーザのアプリケーション品質へ影響がないようにしてもよい。
また、ステップ１３１：ＮＯとステップ１３３との間で、残りの測定タイミングのすべてでパッシブ測定が行われた場合でも、当該測定周期での測定回数が規定回数に達しない場合には、アクティブ測定を行うようにしてもよく、ステップ１３６でアクティブ測定が連続して行われた場合の測定の時間的偏りを回避できる。
【００９６】
なお、以上で説明した各実施の形態では、呼制御装置１とネットワーク品質測定装置２との間でもネットワーク品質情報をやり取りする必要がある。この場合には、前述したようにＭＩＢ（Management Information Base）情報を利用できる。
まず、ネットワーク品質測定装置２で得られた各種ネットワーク品質情報を、ネットワーク管理の標準規格ＭＩＢで規定されたＭＩＢ情報として管理し、あるいは対応するアプリケーション端末３へ登録しておく。
【００９７】
呼制御装置１では、パケット網５を介して所望のネットワーク品質測定装置２あるいはアプリケーション端末３へアクセスし、ＳＮＭＰ（Simple Network Management Protocol）などのプロトコルにより所望のネットワーク品質情報を取得すればよい。
ＳＮＭＰは、ＴＣＰ／ＩＰネットワークにおいて、ルータやコンピュータ、端末など、ネットワークに接続された通信機器をネットワーク経由で監視・制御するためのプロトコルである。制御の対象となる機器はＭＩＢと呼ばれる管理情報データベースを持っており、管理を行う機器は対象機器のＭＩＢ情報を参照して適切な設定を行うことができる。
【００９８】
なお、ＭＩＢ情報については、コミュニケーションサービスに参加している各アプリケーション端末３や呼制御装置１の間を流通しているため、サービスに参加しているユーザ自身が、各種ネットワーク品質情報を確認して自身のアプリケーション端末の設定を変更することも可能である。
また、同様の理由で、コミュニケーションサービスに参加している各アプリケーション端末３の中間地点でこれら制御パケットをキャプチャし、コミュニケーションの品質監視を行うことも可能である。
【００９９】
なお、以上の各実施の形態では、ネットワーク品質測定装置２がアプリケーション端末３に別装置として併設されている場合を前提として説明したが、ネットワーク品質測定装置２をアプリケーションの１つとして、アプリケーション端末３内に実装するようにしてもよい。より具体的には、任意の対象アプリケーションのパケットを監視するプログラムを、アプリケーション端末３のコンピュータで実行することにより実現できる。もちろん、呼制御装置１をアプリケーションの１つとして、アプリケーション端末３内に実装するようにしてもよい。
【図面の簡単な説明】
【０１００】
【図１】本発明の第１の実施の形態にかかる呼制御システムの構成を示すブロック図である。
【図２】本発明の第１の実施の形態にかかる呼制御装置の構成を示すブロック図である。
【図３】本発明の第１の実施の形態にかかる呼制御装置による呼制御処理を示すフローチャートである。
【図４】体感品質特性情報の一例を示すグラフである。
【図５】本発明の第２の実施の形態にかかる呼制御装置による呼接続可否の判定方法を示す説明図である。
【図６】本発明の第３の実施の形態にかかる呼制御装置で用いるネットワーク品質特性情報の一例を示すグラフである。
【図７】本発明の第３の実施の形態にかかる呼制御装置による呼接続可否の判定方法を示す説明図である。
【図８】本発明の第４の実施の形態にかかる呼制御装置での呼接続可否判定を示す説明図である。
【図９】本発明の第５の実施の形態にかかる呼制御装置での呼制御処理を示すフローチャートである。
【図１０】本発明の第５の実施の形態にかかる呼制御装置による呼接続可否の判定例を示す説明図である。
【図１１】本発明の第５の実施の形態にかかる呼制御装置による呼接続可否の他の判定例を示す説明図である。
【図１２】本発明の第６の実施の形態にかかる呼制御装置での品質特性管理処理を示すフローチャートである。
【図１３】本発明の第７の実施の形態にかかる呼制御装置でのタイミング管理処理を示すフローチャートである。
【図１４】本発明の第７の実施の形態にかかる呼制御装置でのタイミング管理動作を示すタイミングチャートである。
【符号の説明】
【０１０１】
１…呼制御装置、２…ネットワーク品質測定装置、３…アプリケーション端末、５…パケット網、１１…通信Ｉ／Ｆ部、１２…記憶部、１３…制御部、１３Ａ…ネットワーク品質取得手段、１３Ｂ…ユーザ体感品質推定手段、１３Ｃ…呼制御手段、１３Ｄ…ネットワーク品質推定手段、１３Ｅ…品質特性管理手段。
【図１】
2005295304.tif 000003
【図２】
2005295304.tif 000004
【図３】
2005295304.tif 000005
【図４】
2005295304.tif 000006
【図５】
2005295304.tif 000007
【図６】
2005295304.tif 000008
【図７】
2005295304.tif 000009
【図８】
2005295304.tif 000010
【図９】
2005295304.tif 000011
【図１０】
2005295304.tif 000012
【図１１】
2005295304.tif 000013
【図１２】
2005295304.tif 000014
【図１３】
2005295304.tif 000015
【図１４】
2005295304.tif 000016