JP2013074494A - 網状態推定装置及び網状態推定プログラム - Google Patents

Abstract

【課題】網の制御機能が利用可能な資源を絞るというような運用がなされる仮想網でも正しく網の状態を把握できるようにする。
【解決手段】本発明は、物理網の帯域を複数に分割して構築された１又は複数の仮想網の状態を推定する網状態推定装置である。本発明は、ベアラ特性計測手段と、サービス品質計測手段と、ノード装置から計測情報を取得する計測情報取得手段と、ベアラ特性計測手段及びサービス品質計測手段の計測された計測情報と取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行い、同一グループのパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する。
【選択図】 図１

Description

本発明は、網状態推定装置及び網状態推定プログラムに関するものであり、例えば、ルータやスイッチ等のノードと、光ファイバ等のリンクで構成される網において、帯域を分割し、サービス毎に仮想的に別の網として機能させる仮想網が構築されている場合に、仮想網の利用状態を推定する網状態推定装置及び網状態推定プログラムに適用し得るものである。

最初に、網の利用状態を把握する従来の網状態推定技術を説明する。

非特許文献１には、PathLoadと呼ばれる可用帯域推定技術が記載されている。なお、PathLoadは、Manish JainとConstantinos Dovrolisyにより開発された。

非特許文献１の記載技術は、網に対して送信間隔が等しいパケット列を入力し、受信側での到着間隔を観測するものである。入力時のパケット列の帯域が、網の通信経路で利用可能な（可用）帯域の最小値よりも小さければ、送信間隔と到着間隔はほぼ等しくなる。入力時のパケット列の帯域が、網の可用帯域より大きければ、送信間隔よりも到着間隔の方が大きくなる。

そこで、非特許文献１の記載技術は、到着間隔が狭くならなければ送信間隔を短くし、到着間隔が伸びた時は送信間隔を長くする作業を繰り返す事で、網の空き帯域を推定するというものである。非特許文献１には、PathChip法やＩＧＩ（Initial Gap Increasing）法といった、他の可用帯域推定技術も示されているが、パケットの到着間隔から可用帯域を推定する点は同じである。

また、別の網状態推定技術として、非特許文献２に記載の技術がある。非特許文献２の記載技術は、端末がリアルタイム通信を行った際に、端末が受信したパケットの遅延時間の分散値を含む品質情報を計測し、これを、端末が送信側に転送し、その情報から網の状態を推定する。

上記のように網状態推定技術は、例えば、以下の様な具体的な利用が可能である。図２（Ｂ）は、物理的な網の構成を示す構成図である。図２（Ｂ）に示すように、例えば、１００Ｍｂｉｔ／ｓｅｃのリンク２本が２００Ｍｂｉｔ／ｓｅｃの伝送路（例えば、ＩＥＥＥ８０２．３ａｄ ＬＡＣＰにより１本のリンクとして利用）で接続された、ワイヤレートでの転送が可能なルータ１及びルータ２で構成される網を想定する。

この様な網で、帯域が１０Ｍｂｉｔ／ｓｅｃのＴＶ会議サービス、同じく帯域が１０Ｍｂｉｔ／ｓｅｃのオンデマンド映像配信サービスを受ける場合を考える。

この網を利用可能な加入者が、ＴＶ会議を行おうとした際、映像や音声が乱れたとする。その原因は、例えば、ＴＶ会議装置本体やＴＶカメラ、マイクが故障していたり、伝送路やルータが輻輳して帯域不足が生じたりすることが考えられる。

このとき、可用帯域推定技術を用いて、ＴＶ会議を行う２拠点間の可用帯域を計測する。仮に可用帯域が５Ｍｂｉｔ／ｓｅｃしかなければ、帯域不足が原因であると推定される。一方、可用帯域が３０Ｍｂｉｔ／ｓｅｃあるならば、ＴＶ会議装置本体やカメラやマイクの故障を疑うのが良いと考えられる。

この様に、網状態推定技術は障害時の原因推定に使えるし、そもそも、ＴＶ会議を行う前に可用帯域を推定し、空き帯域が不足するならば、利用者は、ＴＶ会議を諦めたり、又は利用時間をずらしたりする等という対策を取る事もできる。

加藤肇，行松健一，橋本仁，"Ｅｎｄ−ｔｏ−Ｅｎｄ可用帯域推定方式の性能評価とストリーミング通信への適用に関する検討"，平成１７年度 情報処理学会東北支部研究会 講演番号８ ＩＥＴＦの技術標準 ＲＦＣ５０９３（RTCP−XR：BT’s Extended Network Quality RTP Control Protocol Extended Reports）

ところで、「仮想網（あるいは仮想ネットワーク）」は、様々な意味で使われるが、ここでは以下に示すような場合を示す。

この網は、図２（Ｂ）の物理綱のルータ１及び２上でパケットの種別によるポリシング制御を行う。例えば、ＴＶ会議のトラヒックは最大３０Ｍｂｉｔ／ｓｅｃまで、オンデマンド映像配信のトラヒックは最大５０Ｍｂｉｔ／ｓｅｃまで流し、通常のＷＥＢや電子メールを含むその他全てのアプリのトラヒックは最大で１２０Ｍｂｉｔ／ｓｅｃまでしか流さない設定を行ったとする。

このとき、図２（Ｂ）の網は、論理的には、図２（Ａ）に示すような仮想網で構成されるものとみなすことができる。すなわち、網は、図２（Ａ）に示すように、帯域が３０Ｍｂｉｔ／ｓｅｃでＴＶ会議を行う仮想網（ＴＶ会議用仮想網）１、帯域が５０Ｍｂｉｔ／ｓｅｃでオンデマンド映像配信を行う仮想網（オンデマンド映像配信用仮想網）２、帯域が１２０Ｍｂｉｔ／ｓｅｃでその他のアプリを通す仮想網（その他アプリ用仮想網）３の３つの仮想的な網で構成される。

この様な仮想網とすることで、以下のような効果が得られる。

例えば、ＴＶ会議用仮想網１を構築すれば、他のアプリがどれ程混雑している場合でも、最大３本のＴＶ会議が可能となる。

また例えば、オンデマンド映像配信の場合は、再送制御可能なのでＴＶ会議ほどは厳しくないが、映像の再生レートより、ダウンロード速度の方が遅いとき、映像が少し再生された後に停止するという状態が繰り返される。上記のオンデマン仮想綱を構築すれば、他のアプリの通信がどれ程利用されていても、最大５番組まで映像を同時に視聴できる。キャリアは利用者のアプリ毎の利用状況を想定し、仮想網の帯域を設定する。

この様な仮想綱で可用帯域推定を行う際の課題を説明する。

可用帯域を計測する際に用いるパケットには、例えばＩＣＭＰと呼ばれるInternet Control Message Protocol（ネットワーク制御通知プロトコル）のパケットが用いられる。

このパケットは、上記の分類では、その他アプリ用仮想網３上のトラヒックとして分類される。従って、ＩＣＭＰを用いて推定された可用帯域は、その他アプリ用仮想網３の可用帯域である。

例えば、図２（Ａ）において、仮にＩＰアドレスが「１９２．１６８．１．１０」のＴＶ会議端末９１と「１９２．１６８．２．１０」のＴＶ会議端末９２との間でＴＶ会議を行う際、事前にＩＣＭＰのパケットを用いて可用帯域推定を行い、充分な帯域の空きがあるとの判定結果が出たとしても、それは、その他アプリ仮想網３の状態であって、ＴＶ会議用仮想網１の状態と異なる。

その結果、ＴＶ会議が出来ない可能性がある。つまり、ＴＶ会議サービスやオンデマンド映像配信サービス等のサービス毎に構築した仮想網の可用帯域を推定することができない。

更に大きな課題として、以下の課題が存在する。それは、省電力制御によって生じる課題である。

例えば、ＴＶ会議用仮想網１の使用帯域が２０Ｍｂｉｔ／ｓｅｃ、オンデマンド映像配信用仮想網２の使用帯域が３０Ｍｂｉｔ／ｓｅｃ、その他アプリ用仮想網３の使用帯域が４１Ｍｂｉｔ／ｓｅｃの場合、合計トラヒック量は９１Ｍｂｉｔ／ｓｅｃであり、ルータ１及びルータ２間のリンク１本の容量よりも少ない。

網の制御機能（省電力制御機能）は、自動的に、ＴＶ会議用仮想網１の帯域を２３Ｍｂｉｔ／ｓｅｃ、オンデマンド映像配信用仮想網２の帯域を３３Ｍｂｉｔ／ｓｅｃ、その他アプリ用仮想網３の帯域を４４Ｍｂｉｔ／ｓｅｃにルータで絞るように制御し、ルータ１及びルータ２は、ＩＦ１２及びＩＦ２２同士を接続するリンクを停止し、リンク１本での通信を行うことがある。

こうして、リンク１本分のインタフェースの消費電力を削減することができる。また、図２（Ａ）及び（Ｂ）には、図示していないが、ルータ１及びルータ２間を接続する伝送路の光アンプ等の伝送に関する部品の消費電力も削減できる。

なお、網の制御機能は、新たなＴＶ会議の通信が行われると、直ちに休止中のインタフェースとリンクを復帰させて、ポリシングの設定値を元に戻し、利用者に不利益が出ないようにする。

この様な仮想網で、可用帯域を推定した際、実際には合計１００Ｍｂｉｔ／ｓｅｃ以上の空き帯域があるにもかかわらず、網側の省電力制御によりリンク１本で通信しているので、可用帯域推定技術による計測値が１本分のリンクでの値となってしまい、計測値が例えば数Ｍｂｉｔ／ｓｅｃ等という本来よりも小さい値となってしまうことがある。その結果、新たにＴＶ会議サービスやオンデマンド映像配信サービスを追加的に行うことが不可能となってしまうおそれがある。

なお、アプリケーションの利用者が、網の運用情報の全てを得られる場合、例えば、ルータ１及びルータ２といった全てのノードのＭＩＢ情報が得られるならば、可用帯域推定あるいは、利用するサービスの数を増やした場合の見込み品質の必要性は、それほど高くなくて済む可能性がある。

しかし、図２（Ｂ）の網は簡単化されており、図２（Ｂ）のようにルータが２台だけの網は稀である。実際の網はより複雑であるため、（１）全てのノードの情報が得られなかったり、（２）複数のネットワーク事業者に跨っていて得られない情報があったり、（３）全ての情報が得られていてもそれだけでは体感品質の推定が困難だったりすることがある。

そこで、本発明は、上記課題を解決するものであり、「省電力制御等を目的として、帯域利用率が低い際、網の制御機能が利用可能な資源を絞る」というような運用がなされる仮想網でも正しく網の状態を把握することができる網状態推定装置及び網状態推定プログラムを提供することにある。

ここでいう網の状態とは、具体的には、例えば（１）可用帯域の推定値、（２）現在実行中のサービスの体感品質の推定値、（３）追加でサービスの接続要求をする前に、その追加されたサービスや既に実行中のサービスの体感品質の推定値を指す。

かかる課題を解決するために、第１の本発明は、物理網の帯域を複数に分割して構築された１又は複数の仮想網の状態を推定する網状態推定装置において、（１）提供サービス、通信プロトコル、ＩＰアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段と、（２）提供されるサービスの品質をサービス毎に計測するサービス品質計測手段と、（３）物理網上に存在する１又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段と、（４）ベアラ特性計測手段及びサービス品質計測手段により計測された計測情報と、計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段と、（５）グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段とを備えることを特徴とする網状態推定装置である。

第２の本発明は、物理網の帯域を複数に分割して構築された１又は複数の仮想網の状態を推定する網状態推定プログラムにおいて、コンピュータを、（１）提供サービス、通信プロトコル、ＩＰアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段、（２）提供されるサービスの品質をサービス毎に計測するサービス品質計測手段、（３）物理網上に存在する１又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段、（４）ベアラ特性計測手段及びサービス品質計測手段により計測された計測情報と、計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段、（５）グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段として機能させることを特徴とする網状態推定プログラムである。

本発明によれば、例えば省電力制御等を目的として、帯域利用率が低い際、網の制御機能が利用可能な資源を絞るというような運用がなされる仮想網でも正しく網の状態を把握することができる。

実施形態のネットワークの全体構成例と、網状態推定装置の内部構成とを説明する構成図である。 物理網の構成と仮想網の構成を説明する説明図である。 実施形態において網状態推定機能部による仮想網の判定及び仮想網の状態推定処理の動作例を示すフローチャートである。 実施形態において仮想網の判定及び仮想網の状態推定処理を説明する説明図である。 実施形態において、アプリケーション別に付与した負荷情報及び各計測値と、仮想網の可用帯域推定値との関係を説明する説明図である。 実施形態において、現在の計測値と過去の計測値の情報に基づいて、現在の真の網の状態を推定する方法を説明する説明図である。 実施形態において、現在の計測値からサービスを追加した際の追加サービスと既存サービスの品質の推定値を求める動作を説明する説明図である。 実施形態において、複数の過去の計測値の集合を用いて仮想網の状態を推定する方法を説明するイメージ図である。

（Ａ）実施形態
以下では、本発明の網状態推定装置及び網状態推定プログラムの主たる実施形態を、図面を参照しながら詳細に説明する。

（Ａ−１）実施形態の構成
図１は、この実施形態のネットワークの全体構成例と、網状態推定装置の内部構成とを説明する構成図である。

図１において、この実施形態のネットワーク７は、複数台（図１では４台）のルータ１〜４、複数の端末５、サーバ６、網状態推定装置１０を有する。なお、ルータ１〜４、端末５、サーバ６等の数は特に限定されるものではない。

ルータ１〜４は、ＵＮＩ（User Network Interface）を介してユーザ側のネットワーク（ＬＡＮ）の端末５、サーバ６と接続し転送処理を行う転送装置である。ルータ１〜４は、相互に複数のリンクで接続されており、これら複数のリンクを利用して、サービス毎に帯域を分割し、１又は複数の仮想網を構築するものである。例えば、ルータ１〜４は、ＩＥＥＥ８０２．３ａｄ ＬＡＣＰ（Link Aggregation Control Protocol）に規格化された標準化技術に対応の転送装置を適用することができる。

端末５は、利用者が利用する端末装置であり、サーバ６が提供するサービスの提供を受けるものである。端末５は、例えば、ＴＶ会議端末、動画視聴端末、ＷＥＢ端末等が該当する。

サーバ６は、種々のサービスを提供するサーバであり、例えば、ＴＶ会議サーバ、動画配信サーバ、ＷＥＢサーバ等が該当する。

網状態推定装置１０は、ユーザ側のネットワーク又はルータ１〜４に接続しており、端末５とサーバ６との間で授受されるパケットの通信状態を計測し、その計測結果に基づいて仮想網の利用状態を推定するものである。

図１には、網状態推定装置１０により実現される主な機能を示す。なお、網状態推定装置１０は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、入出力インタフェース等を有して構成されるものである。網状態推定装置１０の機能は、ＣＰＵが、ＲＯＭに格納される網状態推定プログラムを実行することにより実現されるものである。また、網状推定プログラムは、ネットワーク通じてダウンロードしてインストールされるものであってもよく、その場合でも機能的には図１に示す構成を有する。

図１に示すように、網状態推定装置１０は、インタフェース機能部１１、制御機能部１２、アプリ品質計測機能部１３、仮想網ベアラ特性計測機能部１４、ノード計測情報取得機能部１５、アプリ別負荷付与機能部１６、計測情報蓄積機能部１７、網状態推定機能部１８を有する。

インタフェース機能部１１は、物理網と接続するインタフェース部であり、後述するアプリ品質計測機能部１３及び仮想網ベアラ特性計測機能部１４が物理網の情報を取得する出入り口として利用されるものである。具体的には、インタフェース機能部１１は、端末５やサーバ６と同じＵＮＩに接続したり、ルータ１〜４等のノード装置のミラーポートに接続したりする。

アプリ品質計測機能部１３は、例えば、ＴＶ会議やオンデマンド映像受信、あるいは、ＷＥＢ等のアプリケーションプログラムを実行する際、アプリケーション毎の品質を計測するものである。

アプリ品質計測機能部１３が計測する品質としては、例えば、客観品質や体感品質（主観品質）のいずれ又は双方を適用することができる。客観品質及び体感品質を計測する方法は、特に限定されるものではなく、種々の方法を広く適用することができる。例えば、映像の客観品質計測方法としては、ＩＴＵ−Ｔ勧告Ｊ．２４７やＩＴＵ−Ｔ勧告Ｊ．２４９等の標準化技術を適用でき、また例えば、映像の体感品質計測方法としては、ＭＯＳ（Mean Opinion Score）値やＤＳＣＱＳ（Double Stimulus Continuous Scale）値等を適用することができる。

なお、サービス提供中に、利用者の端末５が客観品質及び体感品質を計測し、網状態推定装置１０が端末５から計測情報を取得可能な場合は、端末５に代行させるようにしてもよい。

仮想網ベアラ特性計測機能部１４は、各サービスの仮想網の状態を計測するものである。

仮想網ベアラ特性計測機能部１４は、従来の可用帯域推定技術を広く適用することができる。すなわち、仮想網ベアラ特性計測機能部１４は、アクティブ型、パッシブ型、インライン型のいずれの計測手法を適用することができる。

なお、アクティブ型の可用帯域推定方法は、ホストが計測用パケットを送出し、例えば転送遅延やパケット到着時間等の計測結果に基づいて仮想網の状態（可用帯域）を推定する方法である。また、パッシブ型の可用帯域推定方法は、仮想網のある計測地点を通過するトラフィックを監視し、その監視情報を収集して仮想網の状態（可用帯域）を推定する方法である。インライン型の可用帯域計測方法は、送信側からのパケットを受信側がそのまま転送し、送信側の送信間隔や受信間隔等に基づいて可用帯域を推定する方法である。

例えば、仮想網ベアラ特性計測機能部１４は、パケット情報として含まれる、提供サービス（アプリケーション）種別、使用するプロトコル（例えば、ＴＣＰ、ＵＤＰ等）、ＩＰアドレス（送信元ＩＰアドレス、送信先ＩＰアドレス）、ポート番号（送信元ポート番号、送信先ポート番号）、パケット長等のいずれか、又は、全部若しくは一部の組み合わせに基づいて、パケット遅延やパケット遅延変動やパケット送信又は受信間隔変動やパケット損失率やトラフィック量等を計測する。

また、仮想網ベアラ特性計測機能部１４は、同一の仮想網に対して複数の計測方法で計測する事ができれば、より好適である。

さらに、仮想網ベアラ特性計測機能部１４が計測する計測結果は、例えば、トラフィック量、遅延時間分布等といった統計値であっても良いし、又上記統計値に基づいて導かれる各仮想網の可用帯域値であっても良い。

仮想網ベアラ特性計測機能部１４により計測方法は、例えば、インタフェース機能部１１からＵＮＩを介して、他の一般的な端末５やサーバ６と同様の接続を行って計測する方法を適用できる。また、別の方法としては、ルータ１〜４のようなノード装置のミラーポートからの出力情報を用い、当該ノード装置に入力されたトラヒックの先頭何バイトかの情報を用いても構わない。

ノード計測情報取得機能部１５は、例えば、ルータ１〜４等のノード装置内で計測された品質情報や、ノード装置が蓄積又は出力可能な品質情報を取得するものである。ノード装置が計測した品質情報は、ノード装置内のＭＩＢに蓄積され、外部に公開されているものもある。その場合、ノード計測情報取得機能部１５は、例えば、ＳＮＭＰ（Simple Network Management Protocol）等のプロトコルを用いてノード装置と通信することで品質情報を取得することができる。なお、ノード装置からの品質情報は、大半がトラフィック量や遅延時間分布等の統計情報である。

アプリ別負荷付与機能部１６は、アプリケーション別に、仮想網にトラヒック（パケット）を流して伝送路に負荷をかけたり、接続要求パケットを送信して負荷をかけたりするものである。

計測情報蓄積機能部１７は、アプリ品質計測機能部１３及び仮想網ベアラ特性計測機能部１４により計測された計測結果や、ノード計測情報取得機能部１５により取得された品質情報を記憶部（図示しない）に蓄積するものである。

また、計測情報蓄積機能部１７は、アプリ別負荷付与機能部１６が仮想網に対して付与した負荷の情報も蓄積するものである。このとき、計測情報蓄積機能部１７は、アプリ別負荷付与機能部１６がアプリケーション別に、網に負荷をかけたときに、その付与した網の負荷に対して、どのような計測変化があったかを認識できるようにするため、例えば、時間軸を合わせ、負荷の付与に対する上記計測結果及びノード装置の計測情報を対応可能なように蓄積する。

網状態推定機能部１８は、計測情報蓄積機能部１７に蓄積された情報に基づいて、網の状態を推定し、その推定結果を表示部（例えばディスプレイ等）に出力するものである。網状態推定機能部１８による網状態の推定方法は、動作の項で詳細に説明する。

制御機能部１２は、網状態推定装置１０の機能を制御管理するものである。

（Ａ−２）実施形態の動作
次に、この実施形態の網状態推定方法の動作を、図面を参照しながら詳細に説明する。なお、以下では、サービス毎に構築された仮想網の状態を推定するものであるため、適宜、図２の論理的な仮想網を例示しながら説明する。

動作の説明に先立って、本発明に係る網状態推定装置１０が網の状態を正しく推定する原理を説明する。

まず、従来技術では、何故正しく仮想網の状態を推定できないかの理由を再度簡単に説明する。

第１の理由は、先述したとおり、計測用パケットを用いて仮想網の状態を計測する場合、例えば会議ＴＶ用仮想網等の計測したい仮想網とは別の仮想網に計測用パケットが流れることによる。

第２の理由は、計測したい仮想網の帯域に余裕がある場合、網側が帯域を絞ってしまい、それを感知できないことによる。本来、システム側は、仮想網の帯域に余裕がなくなれば、自動的に絞っていた帯域を拡大するが、可用帯域計測技術は、基本的に網に負荷をかけないことを目標としており、網側が検知できない程度の負荷（例えば、偶然生じたバーストと認識される程度の負荷）で計測する仕組みとなっている。

そこで、本発明に係る網状態推定装置１０は、仮想網の状態を以下の原理で推定する。

（Ａ−２−１）仮想網の状態推定の原理
（１）網状態推定装置１０はアプリケーション毎に品質を計測することで、評価したい仮想網の品質の情報を得る。

また、仮想網がアプリケーションと１：１で対応しておらず、複数のアプリケーションが同一の仮想網に集約されている場合も考えられる。そこで、この様な場合に備え、網状態推定装置１０は、各アプリケーション別の品質計測値や可用帯域等の網状態の推定値を比較し、等しい値（又は近似する値）のアプリケーションは同一グループとして同じ仮想網を利用していると推定する。

なお、仮想網はアプリケーション別に用意されているのではなく、例えば、ＶＰＮ等のように、利用者の所属集団（例えば企業等）別に用意されていたり、また例えば、公平性の観点から、ヘビーユーザとライトユーザという利用頻度別に分類されていたりする事がある。そこで、網状態推定装置１０は、アプリケーション別に品質を計測する事に限定されるものではなく、例えば、所属集団別、利用頻度別等の属性別に品質を計測し、各特性別の仮想網の品質を取得するようにしてもよい。

（２）網状態推定装置１０は、特定の１個のアプリケーションの品質を計測するのではなく、１又は複数の他のアプリケーションの品質も評価し、総合的に判断する。

例えば、仮にＴＶ会議用仮想網１の可用帯域が１０Ｍｂｉｔ／ｓｅｃ、その他アプリ用仮想網３の可用帯域が１００Ｍｂｉｔ／ｓｅｃと計測された場合、リンクは２本とも使われており、ＴＶ会議用仮想網１の可用帯域は本当に１０Ｍｂｉｔ／ｓｅｃしかない事が解る。

しかし、ＴＶ会議用仮想網１の可用帯域が１０Ｍｂｉｔ／ｓｅｃ、その他アプリ用仮想網３の可用帯域が２０Ｍｂｉｔ／ｓｅｃの場合は、リンクが２本とも生きていて、本当に残りがそれだけしかない状態なのか、省電力制御によりリンクが１本落ちていて、本当はもっと使えるのかはそれだけでは判断できない。

そこで、網状態推定機能部１８は、以下のようにして、アプリケーション別の仮想網の判定及び仮想網の状態推定処理を行う。

（３）アプリケーション別の仮想網の判定処理及び状態推定処理
図３は、網状態推定機能部１８による仮想網の判定及び仮想網の状態推定処理の動作例を示すフローチャートである。また、図４は、仮想網の判定及び仮想網の状態推定処理を説明する説明図である。

まず、運用を始める前に、仮想網ベアラ特性計測機能部１４は、アクティブ型、パッシブ型、インライン型等の様々な計測手法により、例えば、アプリケーション別、通信プロトコル（例えば、ＴＣＰ等）別、宛先ＩＰアドレス及び又は宛先ポート番号別、パケット長別等の網のベアラ特性を計測する。

なお、この時点では、アプリケーション別の仮想網が判定していないので、仮想網ベアラ特性計測機能部１４は、アプリケーション別に計測した網のベアラ特性の計測を行う。

また、アプリ品質計測機能部１３は、客観品質及び又は体感品質によるアプリケーション別の品質値を計測する。さらに、ノード計測情報取得機能部１５は、ルータ１〜４等が計測したノード計測情報を取得する。

このようにして、計測情報蓄積機能部１７には、アプリ別負荷付与機能部１６を用いて様々なアプリケーション別のパターンの負荷情報に対して、大量の計測値、すなわち、仮想網ベアラ特性計測機能部１４及びアプリ品質計測機能部１３が計測した計測値と、ノード計測情報取得機能部１５により取得されたノード計測情報とが、計測情報蓄積機能部１７に蓄積される（Ｓ１０１）。

図３において、網状態推定機能部１８は、計測情報蓄積機能部１７に蓄積されているアプリケーション別の網のベアラ特性計測値やアプリケーション別の品質計測値等を参照し（Ｓ１０２）、網状態推定機能部１８は、複数の計測手法による様々な観測結果の微差を検出する。

図４（Ａ）は、例えば、ルータ１及びルータ２の２本のリンクのうち、１本が落とされ、１本分のリンクを利用して、可能帯域が１０Ｍｂｉｔ／ｓｅｃのＴＶ会議用仮想網１とその他アプリ用仮想網３を構築している場合を示す。

図４（Ａ−１）は、図４（Ａ）の場合の網のベアラ特性計測値の例であり、図４（Ａ−２）は、図４（Ａ）の場合のＴＶ会議サービスのアプリ体感品質計測値の例である。なお、横軸は時刻を示している。

一方、図４（Ｂ）は、例えば、ルータ１及びルータ２の２本のリンクのうち、１本のリンクを利用して可能帯域が１０Ｍｂｉｔ／ｓｅｃのＴＶ会議用仮想網１を構築し、もう１本のリンクを利用してその他アプリ用仮想網３を構築している場合を示す。

図４（Ｂ−１）は、図４（Ｂ）の場合の網のベアラ特性計測値の例であり、図４（Ｂ−２）は、図４（Ｂ）の場合のＴＶ会議サービスのアプリ体感品質計測値の例である。なお、横軸は時刻を示している。

例えば、図４（Ａ）のように、１本のリンクが落とされ、ＴＶ会議用仮想網１とその他アプリ用仮想網３とが同じリンクを利用している場合と、図４（Ｂ）のように、すべてのリンクが運用中である場合とでは、計測される網のベアラ特性やアプリ品質に妙な差が生じる。網状態推定機能部１８は、この微差に基づいて機械学習によって識別して、仮想網の判定を行う。

（４）複数の計測手法の微差についての説明
例えば、図４において、仮想網ベアラ特性計測機能部１４が、アクティブ型で網のベアラ特性を計測する。すなわち、仮想網ベアラ特性計測機能部１４は、従来と同様に、例えばＩＣＭＰのパケットを計測用パケットとして網に送出して計測する。

上述したように、計測用パケット（ＩＣＭＰパケット）により推定される可用帯域は、その他アプリ用仮想網３の可用帯域であるため、ＴＶ会議用仮想網１の可用帯域を計測する事が出来ないが、計測用パケットが網に出力されるため、ユーザパケットのトラヒックに影響を与えることになる。

例えば、図４（Ａ）のように、ＴＶ会議用仮想網１とその他アプリ用仮想網３とが１本のリンクを共用している場合に、アクティブ型の計測が行なわれると、図４（Ａ−３）及び（Ａ−４）に示すように、網のベアラ特性計測値及びアプリ体感品質計測値が、微妙に差が生じる。

なお、図４（Ａ−３）及び（Ａ−４）において、点線は図４（Ａ−１）及び（Ａ−２）の計測値であり、実線がアクティブ型の計測値である。

これに対して、図４（Ｂ）のように、ＴＶ会議用仮想網１とその他アプリ用仮想網３とが別々のリンクの場合には、計測用パケットが網に送出されても、ＴＶ会議用仮想網１のユーザパケットのトラヒックに影響を与えない。

そのため、例えば、図４（Ｂ−３）及び（Ｂ−４）に示すように、網のベアラ特性計測値及びアプリ体感品質計測値に変化が見られない。

このように、仮想網ベアラ特性計測機能部１４は、断続的に（又は定期的に）、アクティブ型の計測を行い、その計測値を計測情報蓄積機能部１７に蓄積し、網状態推定機能部１８は、アクティブ型の計測値によるパケット（トラヒック）の影響の度合いを検出する。

なお、ここでは、アクティブ型の計測により計測用パケットを網に送出して上記の微差を検出する場合を例示したが、アクティブ型の計測に限定されない。つまり、アプリ別負荷付与機能部１６が、アプリケーション別の負荷を網に付与するようにしてもよい。例えば、アプリ別負荷付与機能部１６が、ＴＶ会議のパケットを網に送出する場合でも、ＴＶ会議のパケットはＴＶ会議用仮想網１を伝送することになるので、同様の手法により、ＴＶ会議用仮想網１とその他アプリ用仮想網３のリンク状態を検出することができる。ただしこの方法は、運用中の網に悪影響を及ぼす可能生成があるため、継続的に用いるには注意が必要である。すなわち、可用帯域がゼロに近づいたら即座に負荷を与えるのをやめる等の配慮である。

次に、網状態推定機能部１８は、上記の微差を、計測情報蓄積機能部１７の過去の累計データと機械学習して、アクティブ計測の計測値の微差が同等の値（又は近似する値）となるアプリケーションがある場合には、これらアプリケーションを１つのグループとし、そして、網状態推定機能部１８は、このグループが同じ仮想網である判定する（Ｓ１０３）。

なお、機械学習の手法は、様々な計測手法による過去の計測値との照合により、上記の微差と同等の値を求めることができる方法であれば、特に限定されるものではなく、既存の手法を用いても良いし、又は独自の演算モデルを用いるようにしても良い。

これにより、アプリケーション別の仮想網を判定することができる。また、複数のアプリケーションが同一の仮想網に集約されている場合でも、上記の手法により、アプリケーション別の仮想網を判定することができる。

そして、網状態推定機能部１８は、判定した仮想網毎についての種々の計測値に基づいて、当該仮想網の品質計測値、可用帯域の推定値を求めることができ、これらを表示部（例えばディスプレイ等）等に出力する。仮想網の状態推定方法については、以下で詳細に説明する。

（Ａ−２−２）仮想網の状態推定処理（Ｓ１０４、Ｓ１０５）
次に、網状態推定機能部１８による仮想網の状態推定処理の動作を説明する。

実際に仮想網の状態を推定できるようになるまで、網の負荷に対する反応データを取得し学習することが必要なる。

まず、アプリ別負荷付与機能部１６は、アプリケーション別に様々なパターンで網に対して負荷情報を付与する。

例えば、アプリ別負荷機能部１６は、ＴＶ会議等のアプリケーション別で、映像や音声パケット等の転送レートや送出時間等を様々なパターンで変えてパケットを送出して負荷をかける。

また例えば、アプリ別負荷機能部１６は、例えば、ＴＶ会議とオンデマンド映像配信の２つのサービスを同時期に実行し、複数のアプリケーションによるサービスを同時期に起動する等をする。

仮想網ベアラ特性計測機能部１４は、アプリ別負荷付与機能部１６の負荷に対して、例えば、アプリケーション別、通信プロトコル（例えば、ＴＣＰ等）別、宛先ＩＰアドレス及び又は宛先ポート番号別、パケット長別等の網のベアラ特性を計測する。仮想網ベアラ特性計測機能部１４は、同一の仮想網に対して、複数の計測手法で同時に計測する事ができればより好適である。

また、アプリ品質計測機能部１３は、アプリ別負荷付与機能部１６の負荷に対して、客観品質及び又は体感品質によるアプリケーション別の品質値を計測する。さらに、ノード計測情報取得機能部１５は、アプリ別負荷付与機能部１６の負荷に対して、ルータ１〜４等が計測したノード計測情報を取得する。

このようにして、様々なアプリケーション別のパターンの負荷情報に対して、大量の計測値、すなわち、仮想網ベアラ特性計測機能部１４及びアプリ品質計測機能部１３が計測した計測値と、ノード計測情報取得機能部１５により取得されたノード計測情報とが、計測情報蓄積機能部１７に蓄積される。

図５は、アプリケーション別に付与した負荷情報及び各計測値と、仮想網の可用帯域推定値との関係を説明する説明図である。図５において、横軸は時刻を示している。

図６は、現在の計測値と過去の計測値の情報に基づいて、現在の真の網の状態を推定する方法を説明する説明図である。

以下では、運用時（ある時刻Ｔｎ）における網の状態を推定する方法を説明する。

まず、他のトラヒックに悪影響を及ぼす可能性があるので、制御機能部１２は、アプリ別負荷付与機能部１６を停止する。

また、制御機能部１２は、仮想網ベアラ特性計測機能部１４、アプリ品質計測機能部１３、ノード計測情報取得機能部１５、についても、網に負荷をかける機能を停止させる。

例えば、制御機能部１２は、仮想網ベアラ特性計測機能部１４に対して、パッシブ型やインライン型の計測、ＲＴＣＰ−ＸＲ（RTP Control Protocol−Extended Report）等のレポート情報等の網に負担をかけない方法だけで計測させる。

この状態で、仮想綱ベアラ特性計測機能部１４、ノード計測情報取得機能部１５、アプリ品質計測機能部１３は、時刻Ｔｎにおける計測を行う。得られた計測値（網の品質情報）の集合はＱ（Ｔｎ）とする（Ｓ２０１）。

次に、網状態推定機能部１８は、計測情報蓄積機能部１７から、計測値の集合Ｑ（Ｔｎ）と最も近い過去の計測値の集合Ｑ（Ｔａ）を、検索する（Ｓ２０２）。集合Ｑ（Ｔａ）は、過去の時刻Ｔａにおける計測値の集合である。検索は、計測点の差分の合計値が最小の集合を探したり、ニューロ推定等の機械学習を用いた検索が利用できる。

そして、網状態推定機能部１８は、過去にＱ（Ｔａ）を計測した状態からアプリ別負荷付与機能部１６で更に負荷をかけた時の計測値Ｑ（Ｔｚ）を、計測情報蓄積機能部１７から検索する（Ｓ２０３）。

負荷をかけることで、可用帯域が広がっていた場合は、網状態推定機能部１８は、網側の省電力制御でリンクが落とされている状態とし、過去の学習値から、実際にどれだけ流す事が出来たかの情報を検索して、それを真の仮想網の可用帯域の値として出力する。

一方、可用帯域が広がらず、品質が劣化した場合、網状態推定機能部１８は、全リンクが使われており、現時点での計測値が可用帯域として正しい事が解り、真の仮想網の可用帯域の値として出力できる。

（Ａ−２−３）新たなサービスを追加要求した場合
次に、新たなサービスを追加要求した際に想定される品質を推定する動作を説明する。

図７は、現在の計測値からサービスを追加した際の追加サービスと既存サービスの品質の推定値を求める動作を説明する説明図である。

アプリ品質計測機能部１３、仮想網ベアラ特性計測機能部１４、ノード計測情報取得部１５は、時刻Ｔｎにおける計測値の集合Ｑ（Ｔｎ）を求める（Ｓ３０１）。

網状態推定機能部１８は、計測情報蓄積機能部１７に蓄積されている過去の計測情報から、時刻ｔｎにおける計測値の集合Ｑ（Ｔｎ）に最も近似する計測値の集合Ｑ（Ｔａ）を検索する（Ｓ３０２）。

網状態推定機能部１８は、計測情報蓄積機能部１７に蓄積されている計測情報を用いて、過去の集合Ｑ（Ｔａ）が計測された時刻Ｔａにおいて、新たにサービスＡを要求し、その結果、時刻Ｔａ＋Δに、既に実行中のサービスや、追加した新たなサービスＡの品質がどうなったかの過去の計測値の集合Ｑ（Ｔａ＋Δ）を検索して得る（Ｓ３０３）。

網状態推定機能部１８は、過去の計測値の集合Ｑ（Ｔａ＋Δ）におけるアプリ体感品質の計測値を、時刻Ｔｎ＋Δにおいて、新たなサービスＡを追加要求した場合のサービスＡ、並びに、既に実行中のサービスの推定値Ｑ（Ｔｎ＋Δ）として出力する（Ｓ３０４）。

上記の方法は、最も現時刻の計測値に最も近い過去の計測値を選択する場合を例示したが、この方法に限定されるものではない。

別の方法として、現時刻Ｔｎにおける計測値の集合Ｑ（Ｔｎ）が、過去の時刻Ｔａ、Ｔｂ、Ｔｃにおける計測値の集合Ｑ（Ｔａ），Ｑ（Ｔｂ），Ｑ（Ｔｃ）の間に収まっている場合、あるいは、それらに近い場合、線形補間等で推定値を得る事も出来る。

図８は、複数の過去の計測値の集合を用いて仮想網の状態を推定する方法を説明するイメージ図である。図８において、横軸は、計測値の集合Ｑのある要素（計測値ｘ，例えばベアラ特性計測値）であり、縦軸は、計測値の集合Ｑのうちある要素（計測値ｙ，例えばアプリ別体感品質計測値）である。

例えば、現時刻Ｔｎの計測値の集合Ｑ（Ｔｎ）が、過去の過去の時刻Ｔａ、Ｔｂ、Ｔｃにおける計測値の集合Ｑ（Ｔａ），Ｑ（Ｔｂ），Ｑ（Ｔｃ）の間に収まっている場合、時刻Ｔｎ＋Δにおける網状態の推定値Ｑ（Ｔｎ＋Δ）は、過去の時刻Ｔａ＋Δ、Ｔｂ＋Δ、Ｔｃ＋Δにおける計測値の集合Ｑ（Ｔａ＋Δ），Ｑ（Ｔｂ＋Δ），Ｑ（Ｔｃ＋Δ）との間で一定の関係を持って遷移することが考えられる。

そこで、網状態推定機能部１８は、現時刻の計測値の集合Ｑ（Ｔｎ）と、過去の計測値の集合Ｑ（Ｔａ），Ｑ（Ｔｂ），Ｑ（Ｔｃ）との間の関係を求め、計測値の集合Ｑ（Ｔａ＋Δ），Ｑ（Ｔｂ＋Δ），Ｑ（Ｔｃ＋Δ）を用いて、所定の関係を反映させて、時刻Ｔｎ＋Δにおける網状態の推定値Ｑ（Ｔｎ＋Δ）を出力する。

例えば、過去の３点の計測値の集合Ｑ（Ｔａ），Ｑ（Ｔｂ），Ｑ（Ｔｃ）と現時刻Ｔｎの計測値の集合Ｑ（Ｔｎ）との位置関係が、時刻Ｔｎ＋Δにおいても同等の関係があるとして、計測値の集合Ｑ（Ｔａ＋Δ），Ｑ（Ｔｂ＋Δ），Ｑ（Ｔｃ＋Δ）を用いて推定値Ｑ（Ｔｎ＋Δ）を求めるようにしても良い。

なお、図８では、３点の過去の計測値の集合と、現時刻の計測値の集合との関係を一例として説明したが、過去の計測値の集合は、２点であっても良いし、４点以上であっても良い。

また、上記では、新たなサービスを１つ追加した場合の品質の推定値を得る方法を述べた。新たなサービスをＭ個追加した際の品質を推定し、例えばＴＶ会議用の仮想網で１０Ｍｂｉｔ／ｓｅｃのサービスを５つ追加しても品質劣化がなく、６つ追加した場合には品質劣化が生じると推定された場合、可用帯域を５０Ｍｂｉｔ／ｓｅｃ〜６０Ｍｂｉｔ／ｓｅｃの間であると推定して出力し、図６で示した可用帯域の推定方法と別の可用帯域推定方法として利用する事もできる。

（Ａ−３）実施形態の効果
以上のように、実施形態によれば、仮想網が用いられ、アプリ毎に利用可能な帯域が分離された網においても、可用帯域や、新たにサービス要求をした際のサービス品質や既存サービスの品質を推定できる。

また、実施形態によれば、空き帯域に余裕がある場合、省電力などを目的として、リンクを落とすなど利用可能な資源を削減するような網においても、可用帯域や、新たにサービス要求をした際のサービス品質や既存サービスの品質を推定できる。

（Ｂ）他の実施形態
上述した実施形態では、アプリケーション別の仮想網を判定する場合を説明した。しかし、利用者の所属集団別、利用者の利用頻度別に仮想網が構築される場合がある。そこで、このような属性に応じても仮想網を判定できるようにするため、例えば、仮想網ベアラ特性計測機能部１４が、ＶＰＮの識別情報毎、送信元ＩＰアドレス及び又はポート番号毎等に計測し、網状態推定機能部１８が、ＶＰＮの識別情報毎、送信元ＩＰアドレス及び又はポート番号毎等の計測値を用いることで、利用者の所属集団別や利用頻度別の仮想網も判定するようにしてもよい。

１０…網状態推定装置、
１１…インタフェース機能部、１２…制御機能部、
１３…アプリ品質計測機能部、１４…仮想網ベアラ特性計測機能部、
１５…ノード計測情報取得機能部、１６…アプリ別負荷付与機能部、
１７…計測情報蓄積機能部、１８…網状態推定機能部、
１〜４…ルータ、５…端末、６…サーバ、７…ネットワーク。

Claims (5)

1. 物理網の帯域を複数に分割して構築された１又は複数の仮想網の状態を推定する網状態推定装置において、
   提供サービス、通信プロトコル、ＩＰアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段と、
   提供されるサービスの品質をサービス毎に計測するサービス品質計測手段と、
   上記物理網上に存在する１又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段と、
   上記ベアラ特性計測手段及び上記サービス品質計測手段により計測された計測情報と、上記計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段と、
   上記グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段と
   を備えることを特徴とする網状態推定装置。
2. 上記各仮想網に対して所定の負荷を付与する負荷付与手段と、
   上記負荷付与手段が複数種類のパターンで付与した負荷情報に対して、上記ベアラ特性計測手段及び上記サービス品質計測手段が計測した計測情報と、上記計測情報取得手段が取得した計測情報とを蓄積する計測情報蓄積手段と
   を更に備え、
   上記網状態推定手段が、
   現時刻における計測情報に関して、上記計測情報蓄積手段から、上記現時刻の計測情報に最も近い過去の計測情報を検索し、
   上記検索された過去の計測状態から、上記負荷付与手段により負荷を付与したときの計測情報を上記計測情報蓄積手段から検索し、
   上記負荷を付与したときに、可用帯域が広がったとする計測情報を検索した場合、上記計測情報蓄積手段の過去の計測情報から、当該仮想網に実際にパケットを流すことができた情報を検索し、それを真の仮想網の状態情報として出力し、
   上記負荷が付与されても、可用帯域が広がらず、品質が劣化したとする計測情報を検索した場合、現時点での計測値を真の仮想網の状態情報として出力する
   ことを特徴とする請求項１に記載の網状態推定装置。
3. 上記網状態推定手段が、
   現時刻における計測情報に関して、上記計測情報蓄積手段から現時刻の計測情報に最も近い過去の計測情報を検索し、
   上記検索された過去の計測情報を計測した過去の時刻において、新たなサービスを追加し、新たなサービスの追加後の計測情報を、上記計測情報蓄積手段から検索し、
   上記計測蓄積情報から検索した新たなサービスの追加後の計測情報を、現時刻で新たなサービスを追加したときの各仮想網の計測情報として出力する
   ことを特徴とする請求項２に記載の網状態推定装置。
4. 上記網状態推定装置が、
   上記計測情報蓄積手段から複数の過去の計測情報を取得し、これら複数の過去の計測情報と、現時刻の計測情報との関係を求め、
   上記複数の過去の計測情報を計測した過去の時刻から、新たなサービス追加後のそれぞれの過去の計測情報と、上記複数の過去の計測情報との関係とを用いて、現時刻で新たなサービスを追加したときの各仮想網の計測情報を出力する
   ことを特徴とする請求項２又は３に記載の網状態推定装置。
5. 物理網の帯域を複数に分割して構築された１又は複数の仮想網の状態を推定する網状態推定プログラムにおいて、
   コンピュータを、
   提供サービス、通信プロトコル、ＩＰアドレス、ポート番号、パケット長のいずれ又は、全部若しくは一部の組み合わせに基づいて、伝送されるパケットのベアラ特性を計測するベアラ特性計測手段、
   提供されるサービスの品質をサービス毎に計測するサービス品質計測手段、
   上記物理網上に存在する１又は複数のノード装置が伝送パケットのトラフィック情報を計測した計測情報を取得する計測情報取得手段、
   上記ベアラ特性計測手段及び上記サービス品質計測手段により計測された計測情報と、上記計測情報取得手段により取得された計測情報との中から、類似する傾向にある計測情報をパケット別に求めてグループ分けを行うグループ作成手段、
   上記グループ作成手段により同一グループとされたパケットが同一の仮想網を利用して通信している判定し、仮想網別の網状態の推定値を出力する網状態推定手段
   として機能させることを特徴とする網状態推定プログラム。

Images