"物理網の帯域を複数に分割して構築された1又は複数の仮想網の状態を推定する網状態推定装置において、提供サービス、通信プロトコル、IPアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段と、提供されるサービスの品質をサービス毎に計測するサービス品質計測手段と、上記物理網上に存在する1又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段と、上記ベアラ特性計測手段及び上記サービス品質計測手段により計測された計測情報と、上記計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段と、上記グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段とを備えることを特徴とする網状態推定装置。上記各仮想網に対して所定の負荷を付与する負荷付与手段と、上記負荷付与手段が複数種類のパターンで付与した負荷情報に対して、上記ベアラ特性計測手段及び上記サービス品質計測手段が計測した計測情報と、上記計測情報取得手段が取得した計測情報とを蓄積する計測情報蓄積手段とを更に備え、上記網状態推定手段が、現時刻における計測情報に関して、上記計測情報蓄積手段から、上記現時刻の計測情報に最も近い過去の計測情報を検索し、上記検索された過去の計測状態から、上記負荷付与手段により負荷を付与したときの計測情報を上記計測情報蓄積手段から検索し、上記負荷を付与したときに、可用帯域が広がったとする計測情報を検索した場合、上記計測情報蓄積手段の過去の計測情報から、当該仮想網に実際にパケットを流すことができた情報を検索し、それを真の仮想網の状態情報として出力し、上記負荷が付与されても、可用帯域が広がらず、品質が劣化したとする計測情報を検索した場合、現時点での計測値を真の仮想網の状態情報として出力することを特徴とする請求項1に記載の網状態推定装置。上記網状態推定手段が、現時刻における計測情報に関して、上記計測情報蓄積手段から現時刻の計測情報に最も近い過去の計測情報を検索し、上記検索された過去の計測情報を計測した過去の時刻において、新たなサービスを追加し、新たなサービスの追加後の計測情報を、上記計測情報蓄積手段から検索し、上記計測蓄積情報から検索した新たなサービスの追加後の計測情報を、現時刻で新たなサービスを追加したときの各仮想網の計測情報として出力することを特徴とする請求項2に記載の網状態推定装置。上記網状態推定装置が、上記計測情報蓄積手段から複数の過去の計測情報を取得し、これら複数の過去の計測情報と、現時刻の計測情報との関係を求め、上記複数の過去の計測情報を計測した過去の時刻から、新たなサービス追加後のそれぞれの過去の計測情報と、上記複数の過去の計測情報との関係とを用いて、現時刻で新たなサービスを追加したときの各仮想網の計測情報を出力することを特徴とする請求項2又は3に記載の網状態推定装置。物理網の帯域を複数に分割して構築された1又は複数の仮想網の状態を推定する網状態推定プログラムにおいて、コンピュータを、提供サービス、通信プロトコル、IPアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段、提供されるサービスの品質をサービス毎に計測するサービス品質計測手段、上記物理網上に存在する1又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段、上記ベアラ特性計測手段及び上記サービス品質計測手段により計測された計測情報と、上記計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段、上記グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段として機能させることを特徴とする網状態推定プログラム。ところで、仮想網あるいは仮想ネットワークは、様々な意味で使われるが、ここでは以下に示すような場合を示す。この網は、図2Bの物理綱のルータ1及び2上でパケットの種別によるポリシング制御を行う。例えば、TV会議のトラヒックは最大30Mbit/secまで、オンデマンド映像配信のトラヒックは最大50Mbit/secまで流し、通常のWEBや電子メールを含むその他全てのアプリのトラヒックは最大で120Mbit/secまでしか流さない設定を行ったとする。このとき、図2Bの網は、論理的には、図2Aに示すような仮想網で構成されるものとみなすことができる。すなわち、網は、図2Aに示すように、帯域が30Mbit/secでTV会議を行う仮想網TV会議用仮想網1、帯域が50Mbit/secでオンデマンド映像配信を行う仮想網オンデマンド映像配信用仮想網2、帯域が120Mbit/secでその他のアプリを通す仮想網その他アプリ用仮想網3の3つの仮想的な網で構成される。この様な仮想網とすることで、以下のような効果が得られる。例えば、TV会議用仮想網1を構築すれば、他のアプリがどれ程混雑している場合でも、最大3本のTV会議が可能となる。また例えば、オンデマンド映像配信の場合は、再送制御可能なのでTV会議ほどは厳しくないが、映像の再生レートより、ダウンロード速度の方が遅いとき、映像が少し再生された後に停止するという状態が繰り返される。上記のオンデマン仮想綱を構築すれば、他のアプリの通信がどれ程利用されていても、最大5番組まで映像を同時に視聴できる。キャリアは利用者のアプリ毎の利用状況を想定し、仮想網の帯域を設定する。この様な仮想綱で可用帯域推定を行う際の課題を説明する。可用帯域を計測する際に用いるパケットには、例えばICMPと呼ばれるInternetControlMessageProtocolネットワーク制御通知プロトコルのパケットが用いられる。このパケットは、上記の分類では、その他アプリ用仮想網3上のトラヒックとして分類される。従って、ICMPを用いて推定された可用帯域は、その他アプリ用仮想網3の可用帯域である。例えば、図2Aにおいて、仮にIPアドレスが192.168.1.10のTV会議端末91と192.168.2.10のTV会議端末92との間でTV会議を行う際、事前にICMPのパケットを用いて可用帯域推定を行い、充分な帯域の空きがあるとの判定結果が出たとしても、それは、その他アプリ仮想網3の状態であって、TV会議用仮想網1の状態と異なる。その結果、TV会議が出来ない可能性がある。つまり、TV会議サービスやオンデマンド映像配信サービス等のサービス毎に構築した仮想網の可用帯域を推定することができない。更に大きな課題として、以下の課題が存在する。それは、省電力制御によって生じる課題である。例えば、TV会議用仮想網1の使用帯域が20Mbit/sec、オンデマンド映像配信用仮想網2の使用帯域が30Mbit/sec、その他アプリ用仮想網3の使用帯域が41Mbit/secの場合、合計トラヒック量は91Mbit/secであり、ルータ1及びルータ2間のリンク1本の容量よりも少ない。網の制御機能省電力制御機能は、自動的に、TV会議用仮想網1の帯域を23Mbit/sec、オンデマンド映像配信用仮想網2の帯域を33Mbit/sec、その他アプリ用仮想網3の帯域を44Mbit/secにルータで絞るように制御し、ルータ1及びルータ2は、IF12及びIF22同士を接続するリンクを停止し、リンク1本での通信を行うことがある。こうして、リンク1本分のインタフェースの消費電力を削減することができる。また、図2A及びBには、図示していないが、ルータ1及びルータ2間を接続する伝送路の光アンプ等の伝送に関する部品の消費電力も削減できる。なお、網の制御機能は、新たなTV会議の通信が行われると、直ちに休止中のインタフェースとリンクを復帰させて、ポリシングの設定値を元に戻し、利用者に不利益が出ないようにする。この様な仮想網で、可用帯域を推定した際、実際には合計100Mbit/sec以上の空き帯域があるにもかかわらず、網側の省電力制御によりリンク1本で通信しているので、可用帯域推定技術による計測値が1本分のリンクでの値となってしまい、計測値が例えば数Mbit/sec等という本来よりも小さい値となってしまうことがある。その結果、新たにTV会議サービスやオンデマンド映像配信サービスを追加的に行うことが不可能となってしまうおそれがある。なお、アプリケーションの利用者が、網の運用情報の全てを得られる場合、例えば、ルータ1及びルータ2といった全てのノードのMIB情報が得られるならば、可用帯域推定あるいは、利用するサービスの数を増やした場合の見込み品質の必要性は、それほど高くなくて済む可能性がある。しかし、図2Bの網は簡単化されており、図2Bのようにルータが2台だけの網は稀である。実際の網はより複雑であるため、1全てのノードの情報が得られなかったり、2複数のネットワーク事業者に跨っていて得られない情報があったり、3全ての情報が得られていてもそれだけでは体感品質の推定が困難だったりすることがある。そこで、本発明は、上記課題を解決するものであり、省電力制御等を目的として、帯域利用率が低い際、網の制御機能が利用可能な資源を絞るというような運用がなされる仮想網でも正しく網の状態を把握することができる網状態推定装置及び網状態推定プログラムを提供することにある。ここでいう網の状態とは、具体的には、例えば1可用帯域の推定値、2現在実行中のサービスの体感品質の推定値、3追加でサービスの接続要求をする前に、その追加されたサービスや既に実行中のサービスの体感品質の推定値を指す。かかる課題を解決するために、第1の本発明は、物理網の帯域を複数に分割して構築された1又は複数の仮想網の状態を推定する網状態推定装置において、1提供サービス、通信プロトコル、IPアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段と、2提供されるサービスの品質をサービス毎に計測するサービス品質計測手段と、3物理網上に存在する1又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段と、4ベアラ特性計測手段及びサービス品質計測手段により計測された計測情報と、計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段と、5グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段とを備えることを特徴とする網状態推定装置である。第2の本発明は、物理網の帯域を複数に分割して構築された1又は複数の仮想網の状態を推定する網状態推定プログラムにおいて、コンピュータを、1提供サービス、通信プロトコル、IPアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段、2提供されるサービスの品質をサービス毎に計測するサービス品質計測手段、3物理網上に存在する1又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段、4ベアラ特性計測手段及びサービス品質計測手段により計測された計測情報と、計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段、5グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段として機能させることを特徴とする網状態推定プログラムである。本発明によれば、例えば省電力制御等を目的として、帯域利用率が低い際、網の制御機能が利用可能な資源を絞るというような運用がなされる仮想網でも正しく網の状態を把握することができる。A実施形態以下では、本発明の網状態推定装置及び網状態推定プログラムの主たる実施形態を、図面を参照しながら詳細に説明する。A-1実施形態の構成図1は、この実施形態のネットワークの全体構成例と、網状態推定装置の内部構成とを説明する構成図である。図1において、この実施形態のネットワーク7は、複数台図1では4台のルータ1~4、複数の端末5、サーバ6、網状態推定装置10を有する。なお、ルータ1~4、端末5、サーバ6等の数は特に限定されるものではない。ルータ1~4は、UNIUserNetworkInterfaceを介してユーザ側のネットワークLANの端末5、サーバ6と接続し転送処理を行う転送装置である。ルータ1~4は、相互に複数のリンクで接続されており、これら複数のリンクを利用して、サービス毎に帯域を分割し、1又は複数の仮想網を構築するものである。例えば、ルータ1~4は、IEEE802.3adLACPLinkAggregationControlProtocolに規格化された標準化技術に対応の転送装置を適用することができる。端末5は、利用者が利用する端末装置であり、サーバ6が提供するサービスの提供を受けるものである。端末5は、例えば、TV会議端末、動画視聴端末、WEB端末等が該当する。サーバ6は、種々のサービスを提供するサーバであり、例えば、TV会議サーバ、動画配信サーバ、WEBサーバ等が該当する。網状態推定装置10は、ユーザ側のネットワーク又はルータ1~4に接続しており、端末5とサーバ6との間で授受されるパケットの通信状態を計測し、その計測結果に基づいて仮想網の利用状態を推定するものである。図1には、網状態推定装置10により実現される主な機能を示す。なお、網状態推定装置10は、例えば、CPU、ROM、RAM、EEPROM、入出力インタフェース等を有して構成されるものである。網状態推定装置10の機能は、CPUが、ROMに格納される網状態推定プログラムを実行することにより実現されるものである。また、網状推定プログラムは、ネットワーク通じてダウンロードしてインストールされるものであってもよく、その場合でも機能的には図1に示す構成を有する。図1に示すように、網状態推定装置10は、インタフェース機能部11、制御機能部12、アプリ品質計測機能部13、仮想網ベアラ特性計測機能部14、ノード計測情報取得機能部15、アプリ別負荷付与機能部16、計測情報蓄積機能部17、網状態推定機能部18を有する。インタフェース機能部11は、物理網と接続するインタフェース部であり、後述するアプリ品質計測機能部13及び仮想網ベアラ特性計測機能部14が物理網の情報を取得する出入り口として利用されるものである。具体的には、インタフェース機能部11は、端末5やサーバ6と同じUNIに接続したり、ルータ1~4等のノード装置のミラーポートに接続したりする。アプリ品質計測機能部13は、例えば、TV会議やオンデマンド映像受信、あるいは、WEB等のアプリケーションプログラムを実行する際、アプリケーション毎の品質を計測するものである。アプリ品質計測機能部13が計測する品質としては、例えば、客観品質や体感品質主観品質のいずれ又は双方を適用することができる。客観品質及び体感品質を計測する方法は、特に限定されるものではなく、種々の方法を広く適用することができる。例えば、映像の客観品質計測方法としては、ITU-T勧告J.247やITU-T勧告J.249等の標準化技術を適用でき、また例えば、映像の体感品質計測方法としては、MOSMeanOpinionScore値やDSCQSDoubleStimulusContinuousScale値等を適用することができる。なお、サービス提供中に、利用者の端末5が客観品質及び体感品質を計測し、網状態推定装置10が端末5から計測情報を取得可能な場合は、端末5に代行させるようにしてもよい。仮想網ベアラ特性計測機能部14は、各サービスの仮想網の状態を計測するものである。仮想網ベアラ特性計測機能部14は、従来の可用帯域推定技術を広く適用することができる。すなわち、仮想網ベアラ特性計測機能部14は、アクティブ型、パッシブ型、インライン型のいずれの計測手法を適用することができる。なお、アクティブ型の可用帯域推定方法は、ホストが計測用パケットを送出し、例えば転送遅延やパケット到着時間等の計測結果に基づいて仮想網の状態可用帯域を推定する方法である。また、パッシブ型の可用帯域推定方法は、仮想網のある計測地点を通過するトラフィックを監視し、その監視情報を収集して仮想網の状態可用帯域を推定する方法である。インライン型の可用帯域計測方法は、送信側からのパケットを受信側がそのまま転送し、送信側の送信間隔や受信間隔等に基づいて可用帯域を推定する方法である。例えば、仮想網ベアラ特性計測機能部14は、パケット情報として含まれる、提供サービスアプリケーション種別、使用するプロトコル例えば、TCP、UDP等、IPアドレス送信元IPアドレス、送信先IPアドレス、ポート番号送信元ポート番号、送信先ポート番号、パケット長等のいずれか、又は、全部若しくは一部の組み合わせに基づいて、パケット遅延やパケット遅延変動やパケット送信又は受信間隔変動やパケット損失率やトラフィック量等を計測する。また、仮想網ベアラ特性計測機能部14は、同一の仮想網に対して複数の計測方法で計測する事ができれば、より好適である。さらに、仮想網ベアラ特性計測機能部14が計測する計測結果は、例えば、トラフィック量、遅延時間分布等といった統計値であっても良いし、又上記統計値に基づいて導かれる各仮想網の可用帯域値であっても良い。仮想網ベアラ特性計測機能部14により計測方法は、例えば、インタフェース機能部11からUNIを介して、他の一般的な端末5やサーバ6と同様の接続を行って計測する方法を適用できる。また、別の方法としては、ルータ1~4のようなノード装置のミラーポートからの出力情報を用い、当該ノード装置に入力されたトラヒックの先頭何バイトかの情報を用いても構わない。ノード計測情報取得機能部15は、例えば、ルータ1~4等のノード装置内で計測された品質情報や、ノード装置が蓄積又は出力可能な品質情報を取得するものである。ノード装置が計測した品質情報は、ノード装置内のMIBに蓄積され、外部に公開されているものもある。その場合、ノード計測情報取得機能部15は、例えば、SNMPSimpleNetworkManagementProtocol等のプロトコルを用いてノード装置と通信することで品質情報を取得することができる。なお、ノード装置からの品質情報は、大半がトラフィック量や遅延時間分布等の統計情報である。アプリ別負荷付与機能部16は、アプリケーション別に、仮想網にトラヒックパケットを流して伝送路に負荷をかけたり、接続要求パケットを送信して負荷をかけたりするものである。計測情報蓄積機能部17は、アプリ品質計測機能部13及び仮想網ベアラ特性計測機能部14により計測された計測結果や、ノード計測情報取得機能部15により取得された品質情報を記憶部図示しないに蓄積するものである。また、計測情報蓄積機能部17は、アプリ別負荷付与機能部16が仮想網に対して付与した負荷の情報も蓄積するものである。このとき、計測情報蓄積機能部17は、アプリ別負荷付与機能部16がアプリケーション別に、網に負荷をかけたときに、その付与した網の負荷に対して、どのような計測変化があったかを認識できるようにするため、例えば、時間軸を合わせ、負荷の付与に対する上記計測結果及びノード装置の計測情報を対応可能なように蓄積する。網状態推定機能部18は、計測情報蓄積機能部17に蓄積された情報に基づいて、網の状態を推定し、その推定結果を表示部例えばディスプレイ等に出力するものである。網状態推定機能部18による網状態の推定方法は、動作の項で詳細に説明する。制御機能部12は、網状態推定装置10の機能を制御管理するものである。A-2実施形態の動作次に、この実施形態の網状態推定方法の動作を、図面を参照しながら詳細に説明する。なお、以下では、サービス毎に構築された仮想網の状態を推定するものであるため、適宜、図2の論理的な仮想網を例示しながら説明する。動作の説明に先立って、本発明に係る網状態推定装置10が網の状態を正しく推定する原理を説明する。まず、従来技術では、何故正しく仮想網の状態を推定できないかの理由を再度簡単に説明する。第1の理由は、先述したとおり、計測用パケットを用いて仮想網の状態を計測する場合、例えば会議TV用仮想網等の計測したい仮想網とは別の仮想網に計測用パケットが流れることによる。第2の理由は、計測したい仮想網の帯域に余裕がある場合、網側が帯域を絞ってしまい、それを感知できないことによる。本来、システム側は、仮想網の帯域に余裕がなくなれば、自動的に絞っていた帯域を拡大するが、可用帯域計測技術は、基本的に網に負荷をかけないことを目標としており、網側が検知できない程度の負荷例えば、偶然生じたバーストと認識される程度の負荷で計測する仕組みとなっている。そこで、本発明に係る網状態推定装置10は、仮想網の状態を以下の原理で推定する。A-2-1仮想網の状態推定の原理1網状態推定装置10はアプリケーション毎に品質を計測することで、評価したい仮想網の品質の情報を得る。また、仮想網がアプリケーションと1:1で対応しておらず、複数のアプリケーションが同一の仮想網に集約されている場合も考えられる。そこで、この様な場合に備え、網状態推定装置10は、各アプリケーション別の品質計測値や可用帯域等の網状態の推定値を比較し、等しい値又は近似する値のアプリケーションは同一グループとして同じ仮想網を利用していると推定する。なお、仮想網はアプリケーション別に用意されているのではなく、例えば、VPN等のように、利用者の所属集団例えば企業等別に用意されていたり、また例えば、公平性の観点から、ヘビーユーザとライトユーザという利用頻度別に分類されていたりする事がある。そこで、網状態推定装置10は、アプリケーション別に品質を計測する事に限定されるものではなく、例えば、所属集団別、利用頻度別等の属性別に品質を計測し、各特性別の仮想網の品質を取得するようにしてもよい。2網状態推定装置10は、特定の1個のアプリケーションの品質を計測するのではなく、1又は複数の他のアプリケーションの品質も評価し、総合的に判断する。例えば、仮にTV会議用仮想網1の可用帯域が10Mbit/sec、その他アプリ用仮想網3の可用帯域が100Mbit/secと計測された場合、リンクは2本とも使われており、TV会議用仮想網1の可用帯域は本当に10Mbit/secしかない事が解る。しかし、TV会議用仮想網1の可用帯域が10Mbit/sec、その他アプリ用仮想網3の可用帯域が20Mbit/secの場合は、リンクが2本とも生きていて、本当に残りがそれだけしかない状態なのか、省電力制御によりリンクが1本落ちていて、本当はもっと使えるのかはそれだけでは判断できない。そこで、網状態推定機能部18は、以下のようにして、アプリケーション別の仮想網の判定及び仮想網の状態推定処理を行う。3アプリケーション別の仮想網の判定処理及び状態推定処理図3は、網状態推定機能部18による仮想網の判定及び仮想網の状態推定処理の動作例を示すフローチャートである。また、図4は、仮想網の判定及び仮想網の状態推定処理を説明する説明図である。まず、運用を始める前に、仮想網ベアラ特性計測機能部14は、アクティブ型、パッシブ型、インライン型等の様々な計測手法により、例えば、アプリケーション別、通信プロトコル例えば、TCP等別、宛先IPアドレス及び又は宛先ポート番号別、パケット長別等の網のベアラ特性を計測する。なお、この時点では、アプリケーション別の仮想網が判定していないので、仮想網ベアラ特性計測機能部14は、アプリケーション別に計測した網のベアラ特性の計測を行う。また、アプリ品質計測機能部13は、客観品質及び又は体感品質によるアプリケーション別の品質値を計測する。さらに、ノード計測情報取得機能部15は、ルータ1~4等が計測したノード計測情報を取得する。このようにして、計測情報蓄積機能部17には、アプリ別負荷付与機能部16を用いて様々なアプリケーション別のパターンの負荷情報に対して、大量の計測値、すなわち、仮想網ベアラ特性計測機能部14及びアプリ品質計測機能部13が計測した計測値と、ノード計測情報取得機能部15により取得されたノード計測情報とが、計測情報蓄積機能部17に蓄積されるS101。図3において、網状態推定機能部18は、計測情報蓄積機能部17に蓄積されているアプリケーション別の網のベアラ特性計測値やアプリケーション別の品質計測値等を参照しS102、網状態推定機能部18は、複数の計測手法による様々な観測結果の微差を検出する。図4Aは、例えば、ルータ1及びルータ2の2本のリンクのうち、1本が落とされ、1本分のリンクを利用して、可能帯域が10Mbit/secのTV会議用仮想網1とその他アプリ用仮想網3を構築している場合を示す。図4A-1は、図4Aの場合の網のベアラ特性計測値の例であり、図4A-2は、図4Aの場合のTV会議サービスのアプリ体感品質計測値の例である。なお、横軸は時刻を示している。一方、図4Bは、例えば、ルータ1及びルータ2の2本のリンクのうち、1本のリンクを利用して可能帯域が10Mbit/secのTV会議用仮想網1を構築し、もう1本のリンクを利用してその他アプリ用仮想網3を構築している場合を示す。図4B-1は、図4Bの場合の網のベアラ特性計測値の例であり、図4B-2は、図4Bの場合のTV会議サービスのアプリ体感品質計測値の例である。なお、横軸は時刻を示している。例えば、図4Aのように、1本のリンクが落とされ、TV会議用仮想網1とその他アプリ用仮想網3とが同じリンクを利用している場合と、図4Bのように、すべてのリンクが運用中である場合とでは、計測される網のベアラ特性やアプリ品質に妙な差が生じる。網状態推定機能部18は、この微差に基づいて機械学習によって識別して、仮想網の判定を行う。4複数の計測手法の微差についての説明例えば、図4において、仮想網ベアラ特性計測機能部14が、アクティブ型で網のベアラ特性を計測する。すなわち、仮想網ベアラ特性計測機能部14は、従来と同様に、例えばICMPのパケットを計測用パケットとして網に送出して計測する。上述したように、計測用パケットICMPパケットにより推定される可用帯域は、その他アプリ用仮想網3の可用帯域であるため、TV会議用仮想網1の可用帯域を計測する事が出来ないが、計測用パケットが網に出力されるため、ユーザパケットのトラヒックに影響を与えることになる。例えば、図4Aのように、TV会議用仮想網1とその他アプリ用仮想網3とが1本のリンクを共用している場合に、アクティブ型の計測が行なわれると、図4A-3及びA-4に示すように、網のベアラ特性計測値及びアプリ体感品質計測値が、微妙に差が生じる。なお、図4A-3及びA-4において、点線は図4A-1及びA-2の計測値であり、実線がアクティブ型の計測値である。これに対して、図4Bのように、TV会議用仮想網1とその他アプリ用仮想網3とが別々のリンクの場合には、計測用パケットが網に送出されても、TV会議用仮想網1のユーザパケットのトラヒックに影響を与えない。そのため、例えば、図4B-3及びB-4に示すように、網のベアラ特性計測値及びアプリ体感品質計測値に変化が見られない。このように、仮想網ベアラ特性計測機能部14は、断続的に又は定期的に、アクティブ型の計測を行い、その計測値を計測情報蓄積機能部17に蓄積し、網状態推定機能部18は、アクティブ型の計測値によるパケットトラヒックの影響の度合いを検出する。なお、ここでは、アクティブ型の計測により計測用パケットを網に送出して上記の微差を検出する場合を例示したが、アクティブ型の計測に限定されない。つまり、アプリ別負荷付与機能部16が、アプリケーション別の負荷を網に付与するようにしてもよい。例えば、アプリ別負荷付与機能部16が、TV会議のパケットを網に送出する場合でも、TV会議のパケットはTV会議用仮想網1を伝送することになるので、同様の手法により、TV会議用仮想網1とその他アプリ用仮想網3のリンク状態を検出することができる。ただしこの方法は、運用中の網に悪影響を及ぼす可能生成があるため、継続的に用いるには注意が必要である。すなわち、可用帯域がゼロに近づいたら即座に負荷を与えるのをやめる等の配慮である。次に、網状態推定機能部18は、上記の微差を、計測情報蓄積機能部17の過去の累計データと機械学習して、アクティブ計測の計測値の微差が同等の値又は近似する値となるアプリケーションがある場合には、これらアプリケーションを1つのグループとし、そして、網状態推定機能部18は、このグループが同じ仮想網である判定するS103。なお、機械学習の手法は、様々な計測手法による過去の計測値との照合により、上記の微差と同等の値を求めることができる方法であれば、特に限定されるものではなく、既存の手法を用いても良いし、又は独自の演算モデルを用いるようにしても良い。これにより、アプリケーション別の仮想網を判定することができる。また、複数のアプリケーションが同一の仮想網に集約されている場合でも、上記の手法により、アプリケーション別の仮想網を判定することができる。そして、網状態推定機能部18は、判定した仮想網毎についての種々の計測値に基づいて、当該仮想網の品質計測値、可用帯域の推定値を求めることができ、これらを表示部例えばディスプレイ等等に出力する。仮想網の状態推定方法については、以下で詳細に説明する。A-2-2仮想網の状態推定処理S104、S105次に、網状態推定機能部18による仮想網の状態推定処理の動作を説明する。実際に仮想網の状態を推定できるようになるまで、網の負荷に対する反応データを取得し学習することが必要なる。まず、アプリ別負荷付与機能部16は、アプリケーション別に様々なパターンで網に対して負荷情報を付与する。例えば、アプリ別負荷機能部16は、TV会議等のアプリケーション別で、映像や音声パケット等の転送レートや送出時間等を様々なパターンで変えてパケットを送出して負荷をかける。また例えば、アプリ別負荷機能部16は、例えば、TV会議とオンデマンド映像配信の2つのサービスを同時期に実行し、複数のアプリケーションによるサービスを同時期に起動する等をする。仮想網ベアラ特性計測機能部14は、アプリ別負荷付与機能部16の負荷に対して、例えば、アプリケーション別、通信プロトコル例えば、TCP等別、宛先IPアドレス及び又は宛先ポート番号別、パケット長別等の網のベアラ特性を計測する。仮想網ベアラ特性計測機能部14は、同一の仮想網に対して、複数の計測手法で同時に計測する事ができればより好適である。また、アプリ品質計測機能部13は、アプリ別負荷付与機能部16の負荷に対して、客観品質及び又は体感品質によるアプリケーション別の品質値を計測する。さらに、ノード計測情報取得機能部15は、アプリ別負荷付与機能部16の負荷に対して、ルータ1~4等が計測したノード計測情報を取得する。このようにして、様々なアプリケーション別のパターンの負荷情報に対して、大量の計測値、すなわち、仮想網ベアラ特性計測機能部14及びアプリ品質計測機能部13が計測した計測値と、ノード計測情報取得機能部15により取得されたノード計測情報とが、計測情報蓄積機能部17に蓄積される。図5は、アプリケーション別に付与した負荷情報及び各計測値と、仮想網の可用帯域推定値との関係を説明する説明図である。図5において、横軸は時刻を示している。図6は、現在の計測値と過去の計測値の情報に基づいて、現在の真の網の状態を推定する方法を説明する説明図である。以下では、運用時ある時刻Tnにおける網の状態を推定する方法を説明する。まず、他のトラヒックに悪影響を及ぼす可能性があるので、制御機能部12は、アプリ別負荷付与機能部16を停止する。また、制御機能部12は、仮想網ベアラ特性計測機能部14、アプリ品質計測機能部13、ノード計測情報取得機能部15、についても、網に負荷をかける機能を停止させる。例えば、制御機能部12は、仮想網ベアラ特性計測機能部14に対して、パッシブ型やインライン型の計測、RTCP-XRRTPControlProtocol-ExtendedReport等のレポート情報等の網に負担をかけない方法だけで計測させる。この状態で、仮想綱ベアラ特性計測機能部14、ノード計測情報取得機能部15、アプリ品質計測機能部13は、時刻Tnにおける計測を行う。得られた計測値網の品質情報の集合はQTnとするS201。次に、網状態推定機能部18は、計測情報蓄積機能部17から、計測値の集合QTnと最も近い過去の計測値の集合QTaを、検索するS202。集合QTaは、過去の時刻Taにおける計測値の集合である。検索は、計測点の差分の合計値が最小の集合を探したり、ニューロ推定等の機械学習を用いた検索が利用できる。そして、網状態推定機能部18は、過去にQTaを計測した状態からアプリ別負荷付与機能部16で更に負荷をかけた時の計測値QTzを、計測情報蓄積機能部17から検索するS203。負荷をかけることで、可用帯域が広がっていた場合は、網状態推定機能部18は、網側の省電力制御でリンクが落とされている状態とし、過去の学習値から、実際にどれだけ流す事が出来たかの情報を検索して、それを真の仮想網の可用帯域の値として出力する。一方、可用帯域が広がらず、品質が劣化した場合、網状態推定機能部18は、全リンクが使われており、現時点での計測値が可用帯域として正しい事が解り、真の仮想網の可用帯域の値として出力できる。A-2-3新たなサービスを追加要求した場合次に、新たなサービスを追加要求した際に想定される品質を推定する動作を説明する。図7は、現在の計測値からサービスを追加した際の追加サービスと既存サービスの品質の推定値を求める動作を説明する説明図である。アプリ品質計測機能部13、仮想網ベアラ特性計測機能部14、ノード計測情報取得部15は、時刻Tnにおける計測値の集合QTnを求めるS301。網状態推定機能部18は、計測情報蓄積機能部17に蓄積されている過去の計測情報から、時刻tnにおける計測値の集合QTnに最も近似する計測値の集合QTaを検索するS302。網状態推定機能部18は、計測情報蓄積機能部17に蓄積されている計測情報を用いて、過去の集合QTaが計測された時刻Taにおいて、新たにサービスAを要求し、その結果、時刻TaΔに、既に実行中のサービスや、追加した新たなサービスAの品質がどうなったかの過去の計測値の集合QTaΔを検索して得るS303。網状態推定機能部18は、過去の計測値の集合QTaΔにおけるアプリ体感品質の計測値を、時刻TnΔにおいて、新たなサービスAを追加要求した場合のサービスA、並びに、既に実行中のサービスの推定値QTnΔとして出力するS304。上記の方法は、最も現時刻の計測値に最も近い過去の計測値を選択する場合を例示したが、この方法に限定されるものではない。別の方法として、現時刻Tnにおける計測値の集合QTnが、過去の時刻Ta、Tb、Tcにおける計測値の集合QTa,QTb,QTcの間に収まっている場合、あるいは、それらに近い場合、線形補間等で推定値を得る事も出来る。図8は、複数の過去の計測値の集合を用いて仮想網の状態を推定する方法を説明するイメージ図である。図8において、横軸は、計測値の集合Qのある要素計測値x,例えばベアラ特性計測値であり、縦軸は、計測値の集合Qのうちある要素計測値y,例えばアプリ別体感品質計測値である。例えば、現時刻Tnの計測値の集合QTnが、過去の過去の時刻Ta、Tb、Tcにおける計測値の集合QTa,QTb,QTcの間に収まっている場合、時刻TnΔにおける網状態の推定値QTnΔは、過去の時刻TaΔ、TbΔ、TcΔにおける計測値の集合QTaΔ,QTbΔ,QTcΔとの間で一定の関係を持って遷移することが考えられる。そこで、網状態推定機能部18は、現時刻の計測値の集合QTnと、過去の計測値の集合QTa,QTb,QTcとの間の関係を求め、計測値の集合QTaΔ,QTbΔ,QTcΔを用いて、所定の関係を反映させて、時刻TnΔにおける網状態の推定値QTnΔを出力する。例えば、過去の3点の計測値の集合QTa,QTb,QTcと現時刻Tnの計測値の集合QTnとの位置関係が、時刻TnΔにおいても同等の関係があるとして、計測値の集合QTaΔ,QTbΔ,QTcΔを用いて推定値QTnΔを求めるようにしても良い。なお、図8では、3点の過去の計測値の集合と、現時刻の計測値の集合との関係を一例として説明したが、過去の計測値の集合は、2点であっても良いし、4点以上であっても良い。また、上記では、新たなサービスを1つ追加した場合の品質の推定値を得る方法を述べた。新たなサービスをM個追加した際の品質を推定し、例えばTV会議用の仮想網で10Mbit/secのサービスを5つ追加しても品質劣化がなく、6つ追加した場合には品質劣化が生じると推定された場合、可用帯域を50Mbit/sec~60Mbit/secの間であると推定して出力し、図6で示した可用帯域の推定方法と別の可用帯域推定方法として利用する事もできる。A-3実施形態の効果以上のように、実施形態によれば、仮想網が用いられ、アプリ毎に利用可能な帯域が分離された網においても、可用帯域や、新たにサービス要求をした際のサービス品質や既存サービスの品質を推定できる。また、実施形態によれば、空き帯域に余裕がある場合、省電力などを目的として、リンクを落とすなど利用可能な資源を削減するような網においても、可用帯域や、新たにサービス要求をした際のサービス品質や既存サービスの品質を推定できる。B他の実施形態上述した実施形態では、アプリケーション別の仮想網を判定する場合を説明した。しかし、利用者の所属集団別、利用者の利用頻度別に仮想網が構築される場合がある。そこで、このような属性に応じても仮想網を判定できるようにするため、例えば、仮想網ベアラ特性計測機能部14が、VPNの識別情報毎、送信元IPアドレス及び又はポート番号毎等に計測し、網状態推定機能部18が、VPNの識別情報毎、送信元IPアドレス及び又はポート番号毎等の計測値を用いることで、利用者の所属集団別や利用頻度別の仮想網も判定するようにしてもよい。"