インターネット等の通信ネットワークにおいて、致命的な障害や問題が発生するのを防いだり、ユーザが要求するQoS(Quality of Service)条件に応じた安定した回線を提供するためには、回線における通信量の現状把握が不可欠である。
通信量を把握する回線監視ツールとして、現在、SNMP(Simple Network Management Protocol)を利用したものが主流である。また、回線監視ソフトとしては、例えばMRTG(Multi Router Traffic Grapher)等がある。MRTGは、回線中のトラヒック量の情報を定期的に収集してグラフ化し、トラヒック量を時系列的に監視することができるツールとして広く普及しており、監視対象の回線に対してSNMPを利用してポーリング(問い合わせ)を行って所望の情報を取得するものである。MRTGのデフォルトのポーリング時間間隔は5分であり、監視側は5分平均のトラヒック量をデータとして得ることができる。図23にインターネット回線中を流れるトラヒック量をMRTGにより監視した結果の一例を示す。縦軸がトラヒック量(単位Mbps)、横軸は経過時間(時間)を示しており、5分間隔でトラヒック量をプロットしたものである。尚、ポーリング時間間隔を短くすることにより、より詳細なトラヒック量の変動を監視することが出来ると考えられるが、SNMP用いた他の多くの回線監視ツールも、ポーリング時間間隔を5分以上にするように推奨している。これは、SNMPによる制御信号の増大がネットワークを圧迫したり、ネットワーク機器に対してSNMPの処理による過負荷を避けるようにするための処置である。
しかしながら、近年VoIP(Voice over IP) や動画配信等に代表されるように、リアルタイムに動作するアプリケーションの導入が広まっている。これらのアプリケーションは、瞬時の輻輳障害で帯域が保てないと、アプリケーションとして動作しない可能性がある。即ち、一瞬でも回線に障害が発生すると、ユーザのアプリケーションがエラーになる可能性がある。このため、VoIPについては総務省によりクラス基準が定められており、端末間で所定の遅延時間や廃棄率等のQoS条件を満足するようにネットワーク運用を行わなければならない。
また、ユーザがインターネットを利用して使うアプリケーションの中には、5分以下の短い時間で遅延時間を保証しなくてはならない場合がある。例えば、近年インターネットでよく利用されるストリーミングサービスアプリケーションは、サーバからユーザクライアントへ映像を流すものであるが、配信中に通信途絶があってもある程度大丈夫なように、ユーザ側の端末であらかじめ映像データを貯えながら再生を行う。ところが、インターネット中で伝送遅延が発生した場合、データがユーザに届かず再生が満足にできない状況が発生する。バッファの大きさは通常10秒間分であることが多く、10秒間以上遅延が発生すると再生に不具合が出る恐れがある。
また、回線中には回線を交換するスイッチがあり、スイッチは流入するトラヒックを一旦蓄えるバッファを設けている。このバッファの量はトラヒック量に適したものにする必要があり、流入トラヒック量に対してバッファの量が少なすぎるとバッファが溢れ、パケットを廃棄することになり、通信の不具合の原因となる。
したがって、ユーザアプリケーションが正常に動作することを保証するためには、既存回線監視システムの監視情報から、アプリケーションの動作条件に合わせたより細かい(短い)時間平均でのトラヒック量を推定する必要がある。即ち、SNMPのデフォルトのポーリング時間間隔である5分よりも短い時間間隔平均でのトラヒック量の推定を行う必要がある。また、トラヒックが流入するスイッチでトラヒック最大量に応じたバッファ量を設定する必要がある。
そこで、これらの問題を解決する従来技術として、SNMP等を利用して得られる5分平均のトラヒック量から、トラヒックの自己相似性を利用して、より短い時間平均(10秒平均、100ミリ秒平均等)のトラヒック量を推定する技術が存在する(特許文献1)。
尚、トラヒックの自己相似性とは、異なる時間平均のトラヒック量のデータを基に、各時間平均のデータの分散値を求めた時に、数式1が成り立っていることを意味する。ここで、x(t)は時間平均tで測定されたデータ、var(x(t))はx(t)の分散値、aは比例係数、Hは異なる時間での分散値の大きさを結びつけているスケーリングパラメータである。
<数1>
var(x(t))= a−Hvar(x(at))
また、図24に自己相似性の一例をグラフに示す。尚、図24は、縦軸は分散値の大きさ、横軸は時間間隔を示し、得られた各時間平均のトラヒック量のデータより分散値を算出し、各時間平均での分散値の大きさをプロットしたものである。この時、各分散値の大きさが直線で近似できるのであれば、自己相似性があると言える。尚、その直線の傾きがパラメータHに相当する。
特許文献1の技術では、この自己相似性を利用して所望時間平均での分散値の大きさを推定している。また、数式2に示すようにトラヒック量の推定最大値を算出している。ここで、パラメータaは、推定した最大トラヒック量が実測の最大トラヒック量に一致するように、特許文献1に記載の推定方法を実施する前に、試験を行って決めておく補正値である。
<数2>
最大トラヒック量 = 既存回線監視システムのトラヒック量 + a × σ1/2
また、トラヒックのマルチフラクタル性を示すモデルとして、MWM(Multi-fractal Wavelet Model)が提案されている(非特許文献1)。また、ネットワークの特性や性能を評価する簡易型のネットワークシュミレータとして非特許文献2に記載の技術が提案されている。
特開2005−86566
R.H.Riedi and J.Levy-Vehel, "TCP traffic is multifractal: a numerical study," Technical Report No.3129, INRIA Rocquencourt,France, Feb., 1997.
土井博生 "簡易型ネットワークシミュレータの設計と実装"電力中央研究所報告R03023,2004.
しかしながら、特許文献1に記載の技術では、自己相似性の度合いの大きさを決めるために、一度、回線中を流れるトラヒックを全て測定し、そのデータに基づき算出する必要があった。また、自己相似性の度合いの大きさは長期的に変動し、特許文献1に記載の技術では、高い精度での推定を行うことができなかった。さらに、特許文献1に記載の技術においては、この変動に対して追従するために、定期的に回線中のトラヒックを全て測定し、自己相似性の度合いの大きさを算出し直さなければならなかった。具体的には、上記パラメータa及びHを更新するために、対象回線上に測定機器を設置して定期的にトラヒックの実データを測定して、パラメータa及びHを再計算する必要があった。このため、回線中を流れるトラヒックの測定を行うための測定機器をネットワーク内に設けておかなければならなかった。
また、特許文献1に記載の技術において、回線中のパケットを実測すること無しに、SNMPからのトラヒック量のみでパラメータa及びHを決定しようとすると、SNMPからは一般に、分単位でしかトラヒック量を得ることができないため、誤差が大きくなるという問題点があった。このため、推定精度を上げるためには、SNMPからのトラヒック量のみで精度良くパラメータa及びHを決める別の算出法が必要となる。また、回線中のパケットを実測すること無しに、SNMPからのトラヒック量のデータのみを利用したトラヒック量の推定が可能であれば、ネットワークの運用者、管理者は、簡易にトラヒック量推定を行うことができるようになる。
そこで、本発明は、トラヒックのマルチフラクタル性を利用して、精度の高いトラヒック量の推定を行うトラヒック量推定方法、推定装置、推定プログラムを提供することを目的とする。更に、SNMPからのトラヒック量のみで精度良くパラメータを設定し、パラメータを自動更新することによりネットワーク運用者の負担を軽減し、かつネットワーク中のトラヒックを実測することなく精度の高いトラヒック量の推定を行うトラヒック量推定方法、推定装置を提供することを目的とする。更に、当該トラヒック量推定処理により求めたトラヒック量により伝送パケットのバッファ溢れを防止することを特徴とするパケット廃棄防止方法を提供することを目的とする。
かかる目的を達成するため、請求項1に記載のトラヒック量推定方法は、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得処理と、トラヒックのマルチフラクタル性を利用してデータベースに記憶されたトラヒックの数値データに基づいて複数の時間間隔について当該各時間間隔毎に平均トラヒック量を繰り返し求めて各時間間隔別に分散値を求め、求めた各分散値に基づいて時間間隔よりも短い時間間隔における分散値を推定し、平均トラヒック量と分散値に基づいて短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定処理とを行うようにしている。
また、請求項7に記載のトラヒック量推定装置は、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得部と、トラヒックのマルチフラクタル性を利用してデータベースに記憶されたトラヒックの数値データに基づいて複数の時間間隔について当該各時間間隔毎に平均トラヒック量を繰り返し求めて各時間間隔別に分散値を求め、求めた各分散値に基づいて時間間隔よりも短い時間間隔における分散値を推定し、平均トラヒック量と分散値に基づいて短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定部とを備えるものである。
また、請求項12に記載のトラヒック量推定プログラムは、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得処理と、トラヒックのマルチフラクタル性を利用してデータベースに記憶されたトラヒックの数値データに基づいて複数の時間間隔について当該各時間間隔毎に平均トラヒック量を繰り返し求めて各時間間隔別に分散値を求め、求めた各分散値に基づいて時間間隔よりも短い時間間隔における分散値を推定し、平均トラヒック量と分散値に基づいて短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定処理とをコンピュータに実行させるものである。
したがって、通信ネットワーク内の通信機器に対して問い合わせを行い、一定時間間隔のトラヒック量を取得してデータベースに記憶し、記憶された数値データを読み出して、トラヒックのマルチフラクタル性を用いて、短い時間間隔での分散値を推定し、さらに当該時間間隔でのトラヒック量の最大値を推定している。
請求項2に記載のトラヒック量推定方法は、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得処理と、データベースに記憶されたトラヒックの数値データを、マルチフラクタルウェブレットモデルに適用し、一定時間間隔でのトラヒックパターンから、時間間隔よりも短い時間間隔でのトラヒックパターンを推定し、該トラヒックパターンから短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定処理とを行うようにしている。
また、請求項8に記載のトラヒック量推定方法は、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得部と、データベースに記憶されたトラヒックの数値データを、マルチフラクタルウェブレットモデルに適用し、一定時間間隔でのトラヒックパターンから、時間間隔よりも短い時間間隔でのトラヒックパターンを推定し、該トラヒックパターンから短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定部とを備えるものである。
また、請求項13に記載のトラヒック量推定プログラムは、通信ネットワーク内の通信機器より一定時間間隔のトラヒック量を取得してデータベースに記憶するトラヒック量取得処理と、データベースに記憶されたトラヒックの数値データを、マルチフラクタルウェブレットモデルに適用し、一定時間間隔でのトラヒックパターンから、時間間隔よりも短い時間間隔でのトラヒックパターンを推定し、該トラヒックパターンから短い時間間隔でのトラヒック量の最大値を推定するトラヒック量推定処理とをコンピュータに実行させるものである。
したがって、通信ネットワーク内の通信機器に対して問い合わせを行い、一定時間間隔のトラヒック量を取得してデータベースに記憶し、記憶された数値データを読み出して、MWM(Multi-fractal Wavelet Model:マルチフラクタルウェブレットモデル)を用いて、短い時間間隔でのトラヒック量の最大値を推定している。
請求項3に記載の発明は、請求項2に記載のトラヒック量推定方法において、トラヒック量推定処理は、マルチフラクタルウェブレットモデルへの適用に際し、マルチフラクタル性の大きさを示すパラメータを平均化することにより、変動パターンを平均化するようにしている。また、請求項9に記載の発明は、請求項8に記載のトラヒック量推定装置において、トラヒック量推定部は、マルチフラクタルウェブレットモデルへの適用に際し、マルチフラクタル性の大きさを示すパラメータを平均化することにより、変動パターンを平均化するものである。
したがって、マルチフラクタルウェブレットモデルへの適応に際して、各時間スケールでのマルチフラクタル性の大きさを表すパラメータを、ネットワークにおけるバースト現象等に左右されないように平均化する処理を行っている。
請求項4に記載の発明は、請求項1から3までのいずれかに記載のトラヒック量推定方法において、トラヒック量取得処理は、通信プロトコルとしてSNMPを利用してトラヒック量を取得するようにしている。また、請求項10に記載の発明は、請求項7から9までのいずれかに記載のトラヒック量推定装置において、トラヒック量取得部は、通信プロトコルとしてSNMPを利用してトラヒック量を取得するものである。したがって、汎用の通信プロトコルを用いてトラヒック量の推定を行っている。
請求項5記載の発明は、請求項1に記載のトラヒック量推定方法において、トラヒック量推定処理により推定されたトラヒック量の推定最大値は数式3により表され、
数式3中のCは、トラヒック量の最大値とトラヒック量の推定最大値が一致するように求められるパラメータであり、該パラメータCは、予め設定された一定時間毎に計算され、当該計算結果に基づいて該パラメータCが更新されるようにしている。また、請求項11に記載の発明は、請求項7に記載のトラヒック量推定装置において、トラヒック量推定部により推定されたトラヒック量の推定最大値は数式4により表され、
数式4中のCは、トラヒック量の最大値とトラヒック量の推定最大値が一致するように求められるパラメータであり、該パラメータCは、予め設定された一定時間毎に計算され、当該計算結果に基づいて該パラメータCが更新されるものである。
したがって、パラメータCをトラヒック量の最大値とトラヒック量の推定最大値が一致するように自動更新することにより、パラメータの見直しが不要となるトラヒック量の推定を行っている。
さらに、請求項6記載のパケット廃棄防止方法は、請求項1から5のいずれかに記載のトラヒック量推定方法によって短い時間間隔平均でのトラヒック量の推定最大値を求め、かつ伝送パケットを一旦蓄積するバッファの容量を、トラヒック量の推定最大値に合わせて調整し、伝送パケットのバッファ溢れを防止するようにしている。
したがって、トラヒック量の推定最大値にあわせて、バッファ容量を設定し、伝送パケットのバッファ溢れを防止している。
以上説明したように、本発明にかかるトラヒック量推定方法、トラヒック量推定装置、及びトラヒック量推定プログラムによれば、元となるトラヒック量より短い時間間隔で、かつトラヒックのマルチフラクタル性を考慮した精度の高いトラヒック量の推定を行うことができる。
更に、請求項2に記載のトラヒック量推定方法、請求項8に記載のトラヒック量推定装置、請求項13に記載のトラヒック量推定プログラムによれば、トラヒックパターンを一度MWM(Multi-fractal Wavelet Model)へモデル化するため、トラヒックのマルチフラクタル性の特徴をパラメータとして把握できる。
更に、請求項3に記載のトラヒック量推定方法、請求項9に記載のトラヒック量推定装置によれば、ネットワークのバースト現象に左右されない安定したトラヒック量の推定を行うことができる。
更に、請求項4に記載のトラヒック量推定方法、請求項10に記載のトラヒック量推定装置によれば、汎用の通信プロトコルを用いてトラヒック量の推定を行うことができる。
更に、請求項5に記載のトラヒック量推定方法、請求項11に記載のトラヒック量推定装置によれば、パラメータを自動設定するので更新を行う必要がなくなる、即ち、一定時間毎に通信機器にポーリングを行う必要がなくなるので、対象となる回線上に計測機器を用いることなくトラヒック量の推定をすることができる。
更に、請求項6に記載のパケット廃棄防止方法によれば、インターネット回線のスイッチのバッファ溢れを防止してパケットが廃棄されるのを防止することができる。
以下、本発明の構成を図面に示す最良の形態に基づいて詳細に説明する。
図1から図6に本発明の第一の実施形態を示す。まず、本発明のトラヒック量推定装置1について説明する。図1にトラヒック量推定装置1の構成の一例を示す。トラヒック量推定装置1は、ディスプレイ等の出力装置2と、キーボード、マウス等の入力装置3と、演算処理を行う中央処理演算装置(CPU)4と、計算中のデータ、パラメータ等が記憶される主記憶装置5と、計算結果等が記録されるハードディスク等の補助記憶装置6等を備えている。上記ハードウェア資源は例えばバス7を通じて電気的に接続されている。また、入出力I/F12を通じて、ネットワーク11との通信を行うものである。また、補助記憶装置6には本発明のトラヒック量推定プログラムが記録されており、当該プログラムがCPU4に読み込まれ実行されることによって、コンピュータがトラヒック量推定装置1として機能する。
更に、トラヒック量推定装置1はSNMP(Simple Network Management Protocol)を利用したトラヒック量の取得を行うトラヒック量取得部8と、演算式を用いたトラヒック量の推定を行う演算によるトラヒック量推定部9とMWM(Multi-fractal Wavelet Model)を用いてトラヒック量の推定を行うMWMによるトラヒック量推定部10を備えるものである。尚、演算によるトラヒック量推定部9とMWMによるトラヒック量の推定を行うMWMによるトラヒック量推定部10は、いずれか一方備えることとしても、双方を備えるようにしても良い。尚、上記述べたトラヒック量推定装置1の構成は一例であり、これに限られるものではない。
次に、本発明のトラヒック量推定方法について説明する。まず、図6に基づいて演算によるトラヒック量推定を行う場合のトラヒック推定方法を概説する。尚、横軸は、時間間隔Δtであり、縦軸は、トラヒック量の変動幅Sである。
本発明のトラヒック量推定方法は、SNMPを利用して通信機器より得られる一定時間間隔のトラヒック量を基に、より短い時間間隔での最大トラヒック量を以下の手順で推定するものである。本実施形態においては、一定時間間隔を5分とし、求めるより短い時間間隔を100ミリ秒とするが、時間間隔はこれらに限られるものではない。また、通信機器とは、例えばルータ、スイッチ等を指す。
まず、SNMPを利用して通信機器より一定時間間隔のトラヒック量を取得する。尚、図6に示すように、5分間隔で3時間分の計測を行っている。さらに、演算式、またはMWMを用いて分散値の時間間隔による減少傾向を示す指数の最大αmaxを推定する。尚、分散値の時間間隔による減少傾向を示す指数のαは、特許文献1におけるパラメータHに相当する。パラメータHが分散値の時間間隔による減少傾向を示す指数の平均値であるのに対して、αは分散値の時間による変動を捉えた、即ちマルチフラクタル性を考慮した値であり、αmaxはその最大値である。尚、αは特異性指数(singularity exponent)と呼ばれ、特異性指数の分布を持つ集合をマルチフラクタルといい、単一指数しか持たないものをモノフラクタルという。例えば、特許文献1に記載の技術で用いている自己相似性はモノフラクタルであるといえる。さらに、分散値の大きさ及び最大トラヒック量を数式5を用いて算出する。尚、パラメータCは推定最大値がSNMPより得られたトラヒック量の最大値に一致するように決定するものであり、自動更新される。尚、パラメータCは、特許文献1におけるパラメータaに相当する。具体的には、予め記憶装置等に記憶された一定時間おきに数式5によりパラメータCを再計算し、主記憶装置5等の記憶装置に記憶させることにより更新を行うものである。尚、再計算による更新は、例えば3時間毎に行うこととすればよいが、更新間隔はこれに限られるものではない。また、トラヒックのマルチフラクタル性とは、インターネットのトラヒック量について、測定する時間間隔の大きさを変えてもトラヒック特性が変わらない相似傾向の度合いが、時間的に変化を示す性質のことである。即ち、マルチフラクタル性を算出することにより、回線中のトラヒックの自己相似性の大きさの変動を捉えることができる。
次に、推定される最大の傾きαmaxとパラメータCから、最大変動幅Smaxを推定し、さらに、100ミリ秒平均の推定最大トラヒック量を求めるものである。
以下、本発明のトラヒック量推定方法について図2から図5及び図7に示すフローチャートを用いて詳細に説明する。図2に示すようにトラヒック量推定方法は、SNMPよりトラヒック量を取得するトラヒック量取得処理(S1)を行い、次にマルチフラクタル性を用いて、所望の時間間隔での分散値を推定し、推定分散値の大きさより推定最大値を算出する、演算によるトラヒック量推定処理(S2)または、MWMを用いてトラヒック量の推定を行うMWMによるトラヒック量推定処理(S3)を行う。尚、本実施形態においては、演算によるトラヒック量推定処理とMWMによるトラヒック量推定処理はいずれか行うこととしても、双方を行うようにしても良い。
まず、トラヒック量取得処理(S1)について説明する。図3にトラヒック量取得処理のフローチャートを示す。インターネット回線等の対象となる回線インタフェースに対して、SNMPコマンドを送信し(S101)、トラヒック量を取得できたかどうかの判断を行う(S102)。回線に不具合が生じた等の理由によりトラヒック量を取得できなかった場合(S102;No)は、エラー処理を行い(S103)、S105へ移る。尚、エラー処理が生じた場合は、例えば出力装置2上に情報の取得に失敗した旨の表示を出すようにしても良い。トラヒック量を取得した場合(S102;Yes)は、取得したトラヒック量をX(k),k=1,2,3,...(トラヒック量)として補助記憶装置6等に予め記憶されたデータベースへ格納し記憶する(S104)。尚、本実施形態においては、データベースには3時間分のトラヒック量を記憶することとし、以降はFIFOによる更新を行うこととしているが、更新方法、更新間隔は、これに限られるものではない。例えば、補助記憶装置6の容量等により、記憶する時間を増やすこととしても良い。さらに、5分経過したかどうかを判断し、5分経過した場合は、S101に戻る処理(S105)を繰り返すものである。尚、本実施形態においては、トラヒック量を取得する間隔は5分としたが、これに限られるものではない。以上で、トラヒック量取得処理(S1)は終了する。
また、本実施形態においては、ネットワーク管理プロトコルとして、SNMPを用いることとしているが、必ずしもこれに限るものではない。本発明に係るトラヒック量の推定は、ネットワークプロトコルの種類に依存するものではないので、他のネットワークプロトコルについても適用可能である。
次に、演算によるトラヒック量推定処理(S2)について説明する。図4に演算によるトラヒック量推定処理のフローチャートを示す。
まず、トラヒック量をX(k),k=1,2,3,...としてデータベースより3時間分取得する(S201)。具体的には、トラヒック量XΔt(t)を一定時間間隔(本実施形態においては、5分毎:Δt=5)で、対象回線に対しSNMPを利用して、通信機器より取得する。尚、本実施形態においては、トラヒック量を3時間分取得することとしているが、これに限られるものではない。本実施形態においては、トラヒック量を5分毎に3時間分取得することとしているので、k=36となる。
次に、データ個数をm個のブロック毎に各ブロックの平均値を算出(S202)する。具体的には、数式6に示すように、測定されたトラヒック量XΔt(t)をm個のブロックに毎の平均値をXmΔtで表す。
また、こうして作り上げられた時系列データXmΔtの集合を数式7とする。mは、時間スケールを意味するパラメータである。具体的には、一定時間間隔毎のトラヒック量から平均値を求める際に、いくつのトラヒック量から平均値を求めるかを設定するパラメータである。尚、本実施形態においては、mは2から6までの任意の数とし、予め記憶装置等に記憶させておくものとしている。即ち、本実施形態においては、トラヒック量は5分毎に求めることとしているので、m=2であれば、10分ごとの平均値を、m=6であれば30分毎の平均値を求めるものである。しかしながら、パラメータmの値は、これに限られるものではなく、例えば、トラヒック量の取得間隔を短く設定した場合は、mをより大きな数とすることとしても良い。
<数7>
XmΔt=(XmΔt(t):t=1,2,3,...)
次に、得られたXmΔtを用いて次数q=−2.5、−2、−1.5、...、2、2.5のそれぞれについて数式8を算出する(S203)。尚、次数qの範囲は一例であり、これに限られるものではない。
次に、数式9より、モーメントqに対するτ(q)を算出する(S204)。尚、τ(q)は、パラメータmに対するXをq乗し、あるqに対してのパラメータmをプロットしたものの傾きである。尚、パラメータmは対数尺によりプロットする。
次に、数式9により算出したτ(q)を用いて、数式10よりf(α)を求める(S205)。
更に、f(α)の算出可能範囲より傾きαの最大の傾きαmaxを求める(S206)。
αmaxとX(k)を用いて、測定時間間隔Δtに対して、m倍の時間スケールの分散値s2を数式11により算出する(S207)。
求めるトラヒック量の最大推定値を数式12により算出する(S208)。
<数12>
XmΔt+C×s
3時間分のX(k)の最大値と数式12よりパラメータCを決定する(S209)。具体的には、SNMPを利用して通信機器より5分毎に得られるトラヒック量の分布を作成し、その分布の平均、分散値、最大トラヒック量を求め、数式12よりパラメータCを決定する。さらに、推定される最大の傾きαmaxとパラメータCから、数式13により最大変動幅Smaxを推定(Δt=100ミリ秒)し(S210)、数式14により100ミリ秒平均の推定最大トラヒック量を求める(S211)。
<数13>
最大変動幅Smax=C・Δt−αMAX
<数14>
var(x(t))= a−Hvar(x(at))
以上で、演算によるトラヒック量の推定処理(S2)は終了する。
次に、第一の実施形態のMWMによるトラヒック量の推定処理(S3)について説明する。図5にMWMによるトラヒック量の推定処理のフローチャートを示す。
まず、トラヒック量をX(k),k=1,2,3,...としてデータベースより3時間分取得する(S301)。具体的には、トラヒック量XΔt(t)を一定時間間隔(本実施形態においては、5分毎:Δt=5)で、対象回線に対してSNMPを利用し、通信機器より取得する。
次に、データ個数をm個のブロック毎に各ブロックの平均値を算出(S302)する。具体的には、数式15に示すように、測定されたトラヒック量XΔt(t)をm個のブロックに毎に、各々のブロックの要素の平均値をXmΔtで表す。
また、こうして作り上げられた時系列データXmΔtの集合を数式16とする。
<数16>
XmΔt=(XmΔt(t):t=1,2,3,...)
次に、Xm(t)よりMWMに適合するパラメータpを算出する(S303)。具体的には、実測より算出したXmΔt=(XmΔt(t):t=1,2,3,...)に対して、MWMを利用し、最小時間分解能Δt=5分(m=1)よりトラヒックモデルフィットを行い、MWMのパラメータを決定する。尚、MWM(Multi-fractal Wavelet Model)とは数式17、数式18のように定義されるモデルである。
<数17>
XmΔt(t)=((1+B(p,p))/√2)*X(m+1)Δt(t’)
<数18>
XmΔt(t)=((1−B(p,p))/√2)*X(m+1)Δt(t’+1)
ここで、B(p,p)はベータ関数であり、t’はtの時間分解能を2倍にしたものである。即ち、時刻tはt’とt’+1を合わせた時間スケールに相当する。尚、パラメータpは、異なる時間分解能のトラヒックパターンを比較し、各時間スケール間のマルチフラクタル性の大きさ(変動パターン)を示すパラメータである。即ち、pの値が小さいほどパターン変化が大きく、バースト性が大きくなることを示す。本実施形態では、一番マルチフラクタル性が大きい時のpの値、即ち、最小となるpの値を取るものとする。
本実施形態では、各スケールmについてXmΔtを算出し、スケールmとm+1の間の関係よりパラメータpを推定する。次に、各スケールm間で求めたpの中で、パラメータpの最小値を算出する(S304)。求めたMWMΔt=5分より、MWMの定義に従って100ミリ秒に対応するMWMΔt=100msecを算出し、Δt=100msecでのトラヒックパターンを5分間生成(S305)する。
生成したトラヒックパターンより、トラヒック量の最大値を推定する(S306)。以上で、MWMによるトラヒック量推定処理(S3)は終了する。
以上述べたように、3時間分のトラヒック量の取得をして、100ミリ秒平均のトラヒック量の推定がなされる。尚、通信回線のトラヒック量の推定は、通常は継続して行うものであるので、トラヒック量取得処理(S1)の処理は、一定時間経過後は、データベースを更新しながら処理を継続し、一定時間毎に演算、またはMWMによるトラヒック量推定処理(S2,S3)を行う処理を繰り返すものである。
上述した第一の実施形態のMWMによるトラヒック量の推定方法により、トラヒック量の推定の高度化を図ることができる。しかしながら、当該方法では、では、各時間スケール間のマルチフラクタル性の大きさを示すパラメータpを算出し、一番マルチフラクタル性が大きい時のpの値、即ち、最小となるpの値をとっている(S303、S304)。ここで、最小となるpの値は、実ネットワークにおいて、起こりうるバースト現象(短時間でトラヒック量が集中する現象)等に大きく左右される値であり、安定する値とはならない。したがって、パラメータpとして、バースト現象時の最小のpの値を推定に用いてしまうと、推定トラヒック量が大きく変わり、推定値の誤差が大きくなるという問題があった。
換言すれば、第一の実施形態のMWMによるトラヒック量の推定方法では、トラヒックのマルチフラクタル性をMWMを用いてモデル化を行い、その変動パターンの最も激しい場合(pの最小値)を想定しトラヒック量の推定を行っているといえる。しかし、当該方法では、変動パターンの最も激しい場合を想定するため、過剰な大きさのトラヒック量を推定する場合があり、安定的に推定値を算出できないという問題がある。
そこで、以下に述べる第二の実施形態でのMWMによるトラヒック量の推定方法では、バーストの量を図るパラメータpを、各時間スケールでの最小値に代えて、pの平均値をパラメータpとすることで推定値の誤差を減らし、トラヒック量の推定精度を向上させている。
図7から図9に本発明の第二の実施形態を示す。以下に、第二の実施形態のMWMによるトラヒック量の推定処理(S3)における処理(S311〜S316)について、説明する。図7に第二の実施形態のトラヒック量の推定処理のフローチャートを示す。
先ず、トラヒック量をX(k),k=1,2,3,...としてデータベースより3時間分取得する(S311)。次に、データ個数をm個のブロック毎に各ブロックの平均値を算出(S312)する。具体的には、数式19に示すように、測定されたトラヒック量XΔt(t)をm個のブロックに区切り、各々のブロックの要素の平均値をXmΔtで表す。
また、こうして作り上げられた時系列データXmΔtの集合を数式20に示す。
<数20>
XmΔt=(XmΔt(t):t=1,2,3,...)
時系列データXmΔtに対して、図8(a)(b)に示すようなWavelet(ウェーブレット)関数を用い、数式21により分解する。ここで、j=1,2,...は時間スケールを表す変数、k=1,2,...は時系列データの順番を示す変数であり、スケールjは、値が1増す毎に時間分解能が2倍に細かくなることを示す。尚、図8(a)は、Wavelet関数Φj,kを、図8(b)は、Wavelet関数Ψj,kを示す。
即ち、j=1の時は、時系列データは一つしかない状態であり、時間分解能は最も大きい。j=2以上の時は、Uj,k及びWj,kは、数式22及び数式23で算出される計数であり、それぞれ、スケールjとj+1の間での平均トラヒック量(平均成分)と差分トラヒック量(差分成分)に対応する。
尚、平均トラヒック量Uj,kは、スケールjとj+1の間での平均であり、大きいほど平均トラヒック量が多く、小さいほど平均トラヒック量が小さいことを示すパラメータである。差分トラヒック量Wj,kは,時間スケール間jとj+1のトラヒック量の形状変化を示すパラメータである。即ち、差分成分Wj,kが大きい場合は、同じ時間スケールでのパターン形状の変動が大きいことを意味しており、差分成分Wj,kが小さい場合は、パターン形状の変動が小さいことを意味している。
Wavelet関数Φj,kとΨj,kの形をあてはめると、時間スケールjでのUj,k及びWj,kは、時間スケールj+1でのUj+1,2kとUj+1,2k+1を用いて、数式24及び数式25で算出される。また、その生成の様子を図式化した図を図9に示す。尚、Uj,kは、第一の実施形態(数式17及び18)でのX(t)に、Uj+1,2kは、X(t’)に、Uj+1,2k+1は、X(t’+1)に相当するものである。
次に、ある時間スケールjでの平均トラヒック量Uj,kより、2倍の時間分解能を持つ時間スケールj+1での平均トラヒック量Uj+1,2kとUj+1,2k+1を算出するには、差分成分Wj,kを用いて、数式26及び数式27で算出する。
MWMは、差分成分Wj,kについて、ランダム変数Aj,kにベータ分布関数B(p,p)を用いてモデル化する(数式28)。
算出したスケールjとj+1の差分成分の2乗平均E[Wj 2]とE[Wj+1 2]の比を用い、数式29及び数式30によりパラメータpを算出する(S313)。
更に、算出した各時間スケール間のマルチフラクタル性の大きさを示すパラメータpjを数式31により平均値を求める(S314)。
数式31により算出した値を推定パラメータpestとする。
求めたpestを使い、MWMΔt=5分より、100ミリ秒に対応するMWMΔt=100msecを算出し、100ミリ秒でのトラヒックパターンを5分間生成(S315)し、生成したトラヒックパターンより、トラヒック量の最大値を推定する(S316)。以上で、第二の実施形態でのMWMによるトラヒック量推定処理(S3)は終了する。
更に、上述のいずれかのトラヒック量推定方法により推定されたトラヒック最大量から回線中に設置されたスイッチ内のバッファ量を適切に設定することが可能となる。これによりパケット廃棄を防ぐことができる。図10にその概念図を示す。
対象回線のトラヒック最大量が、本発明のトラヒック量推定方法により推定されたとする。対象ネットワーク回線11を流れるトラヒックはスイッチ13へ流入するものとする。スイッチ13では、トラヒックをいったんバッファ14に蓄えてから、トラヒックの制御を行う。即ち、スイッチ13は流入するトラヒックが十分にバッファ14に蓄えられるだけのバッファ量を持つ必要がある。
よって、バッファ量を本推定方法により求めたトラヒック最大量に予め設定し、かつ出力回線速度がこのトラヒック量の平均値以上であれば、バッファ溢れによるパケット廃棄は避けることができる。尚、出力回線速度がこのトラヒック量の平均値以上としているのは、スイッチから出力される速度が、スイッチへの入力トラヒックの平均速度以上であれば、スイッチにパケットが溜まることはないからである。このようにして、バッファ漏れを起こさない適切なバッファ量を決定することができる。
尚、スイッチ13のバッファ容量は、自動調整されるようにしても良いし、手動操作で調整するようにしても良い。バッファ容量の自動調整は、例えば次のようにして行われる。つまり、上述の推定方法により推定した最大トラヒック量からスイッチ13の出力速度を引いたものを、スイッチ13に通知してバッファ量として設定する。これは、SNMPプロトコルを用いて、スイッチ13に接続して設定値を変えることで可能である。これらの一連の動作をスクリプトと呼ばれる命令コマンドを書き並べたものを用意し、それを実行することで自動的にバッファ容量を調整することができる。
本発明により推定されたトラヒック量の最大値は、ネットワークの回線の伝送容量を決定する上で重要である。即ち、回線の容量をエラーが発生しないように大きく取りすぎても、回線の容量の無駄が大きくなり、コスト高となる。即ち、オーバーエスティメイト(over estimate)となる。また、トラヒック量の最大値が回線の伝送容量を超えると伝送負荷となりエラーが発生する。従って、本発明により推定されたトラヒック量の最大値と同等か、やや多く伝送可能な回線を採用することにより、エラーの発生がなく、かつコストの無駄のないネットワークの構築を行うことができる。
加えて、上述のMWMによるトラヒック量の推定方法のいずれかを用いて推定したトラヒック量のデータに基づいて、ルータの遅延時間評価を行うことも可能である(実施例3参照)。トラヒック量だけでは、アプリケーションの動作に影響する伝送遅延時間を定量的に把握できないからである。図11にルータの遅延時間評価方法のフローチャートの一例を示す。尚、トラヒック量取得処理(S1)及びMWMによるトラヒック量取得処理(S3)については、上述した通りであるので説明は省略する。
MWMによるトラヒック量取得処理により得られたトラヒック量のデータを計算機シミュレーションに適用することにより、単一ルータの遅延時間特性を求めることができる(S4)。尚、本実施形態では、計算機シミュレーションには、ネットワークシミュレータ「Fantasy」(非特許文献2)を使用しているが、これに限られるものではない。このシミュレータは、電力用ネットワークのシミュレーションを簡易に行うために開発されたものである。
MWMによるトラヒック量の推定方法により得たトラヒック量のデータに対し計算機シミュレーションを利用することにより、単一ルータで発生する遅延時間の評価が可能となる。このため、回線の健全性や、中継線の増設の必要が有るかといったネットワーク設計における種々の判断を行うことが可能となる(S5)。
尚、ネットワークに複数のルータがある場合に、ルータの遅延時間評価を同時に処理することは、計算時間が厖大となり、現実的ではない。したがって、複数のルータが存在する場合は、単一のルータに対して、ルータ設置個数分の遅延時間を足し合わせれば、ルータの遅延時間評価を簡便、且つ高精度に行うことが可能となる。
尚、上述の実施形態は本発明の好適な実施の例ではあるがこれに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々変形実施可能である。例えば、Wavelet関数は、上述の例には、限られず他の関数を用いてもよいのは勿論である。
(実施例1)
トラヒック量の推定について広域イーサネット(登録商標)ネットワークでトラヒック量の実測を行った。その結果を図12から図14までのグラフに示す。尚、図12から図14の図中、「マルチフラクタル性を考慮」とあるのは、本発明の演算によるトラヒック量推定を行った場合を、「マルチフラクタル性を考慮(MWMを利用)」とあるのは、本発明の第一の実施形態でのMWMによるトラヒック量推定を行った場合を、「自己相似性のみを考慮(従来手法)」とあるのは、特許文献1に記載のトラヒック量推定を行った場合をそれぞれ意味している。また、本実施例におけるトラヒック量推定プログラムはC言語により作成し、計算機としては汎用のパソコン(Apple(登録商標)Powerbook G4,CPU1.2GHz,メモリ1GB)を用いた。
トラヒック量取得処理において5分毎に対象回線インターフェイスに対して、SNMPを利用して5分間分のトラヒック量を取得した。正常に取得できたら、データベースにトラヒック量とその時刻を登録した。尚、データベースには3時間分のデータを記録した。
本実施例では、SNMPを利用して取得した5分毎のトラヒック量から、100ミリ秒でのトラヒック量を推定を行った。
演算によるトラヒック量推定処理と、MWMによるトラヒック量推定処理について、それぞれ実測を行った。まず、データベースから3時間分のトラヒック量を取得し、トラヒック量の推定を行った。
演算によるトラヒック量の推定処理は、数式8から数式14にあるような算出式に従って、トラヒック量の算出を行った。ここで、パラメータCは、SNMPを利用して通信機器から得られる5分毎のトラヒック量の3時間分のトラヒック量のデータの最大値に合うように決定した。
数式14に従って、測定開始3時間以降のトラヒック量の推定を行った。図12に本発明の推定方法より算出された推定最大トラヒック量と実測データとの違いを示す。尚、実測データは100ミリ間隔でのトラヒック量である。横軸は秒、縦軸はトラヒック量(Mbps)を示している。また、符号15は、本発明の演算によるトラヒック量推定を行った場合を、16は本発明の第一の実施形態でのMWMによるトラヒック量推定を行った場合を、17は特許文献1に記載のトラヒック量推定を行った場合を、18は最大トラヒック量の実測値を示している。また、図13に、単位時間を5分間とし、その単位時間の間に、実測データが推定トラヒック量を越える割合の時間変化を示す。縦軸は、エラー割合(単位:%)、横軸は時間を示している。尚、エラー割合とは、トラヒック量の推定値とトラヒック量の実測値を比較し、実測値のデータの方が大きい場合にエラーとみなして、全体のデータ数に対しての割合を求めたものである。図13(a)は、演算によるトラヒック量推定処理を行った場合、図13(b)は、MWMによるトラヒック推定処理を行った場合、図13(c)は、特許文献1に記載の技術による場合である。また、図14に、その場合の頻度分布を示す。尚、符号15は、本発明の演算によるトラヒック量推定を行った場合を、16は本発明の第一の実施形態でのMWMによるトラヒック量推定を行った場合を、17は特許文献1に記載のトラヒック量推定を行った場合を示している。これらから演算によるトラヒック量推定処理の場合、推定エラー割合は5%以内であることがわかった。
第一の実施形態でのMWMによるトラヒック量推定処理は、3時間分のトラヒック量のデータをMWMにあてはめ、マルチフラクタル性の大きさを表すパラメータであるパラメータpの推定を行った。そしてマルチフラクタル性が一番大きい場合に対応するpの最小値を使って、MWMの時間分解能を上げることにより100ミリ秒単位でのトラヒックパターンを生成した。そのトラヒックパターンの最大量を、トラヒック量最大量とする。また、測定開始3時間以降は、5分毎に得られるXΔtを用い各統計量(Cや最大量等)をアップデートを行った。尚、統計量として、データベースには3時間分のデータを保持することとした。
第一の実施形態でのMWMによるトラヒック量推定処理の場合は、推定エラー割合は8%以内であった。一方、特許文献1に記載の技術である自己相似性のみを考慮した推定方法の場合は、推定エラー割合は14%以内であり、推定精度が低いことが分かった。第一の実施形態でのMWMによるトラヒック量推定処理は、トラヒックが増大傾向にある時、推定量が低くなる特徴があり、この時、エラーが多く発生する。これは、大きな時間的変動があった場合、MWMの追従が遅いことを意味している。このため、MWMでトラヒックパターンをモデル化せずに、直接マルチフラクタル解析を行う方が、エラー割合が低く性能が良いことが分かった。しかし、MWMを用いる場合は、トラヒックモデルにあてはめることによりネットワーク特性をしることができる点において有効である。
(実施例2)
次に、第二の実施形態で説明したMWMによるトラヒック量推定を用いて、インターネットを提供している通信事業者の運用回線において実測(実測例1〜3)を行った、尚、上りは通信事業者からインターネットに向かう方向。下りは上位のインターネットから通信事業者へ向かう方向を示す。実測結果を表1に示す。尚、表1中、「第二の実施形態」とあるのは、第二の実施形態で説明したMWMによるトラヒック量推定処理での推定トラヒック量(Mbps)を、「第一の実施形態」とあるのは、第一の実施形態で説明したトラヒック量推定処理での推定トラヒック量(Mbps)を示すものである。
第二の実施形態で説明したMWMによるトラヒック量推定によれば、誤差は2%以内であり、第一の実施形態で説明したMWMによるトラヒック量推定に比して大幅な性能の向上を図ることができた。以上の実験から、変動パターンを示すパラメータpを平均化することにより、更に、検出誤差を減らし、推定精度を向上させることが確認できた。
(実施例3)
次に、ルータの遅延時間評価方法について実験を行った。本実験では、帯域量と伝送速度が異なる2回線を例に、評価実験を行った。
回線として、トラヒック量が大きな回線(以下、回線1)とトラヒック量が小さな回線(以下、回線2)を用いた。
回線1及び回線2について、トラヒック量推定処理により、ある一日の10分間平均のトラヒック量の時系列データを得た。図15(A)は、回線1を、図15(b)は、回線2をそれぞれ示す。本実験では、ネットワークの負荷が高いときの性能評価を目的とするため、午前8時から午後7時までを評価対象とした。尚、回線1では、平均3.38Mbps、回線2では、平均0.15Mbpsのトラヒック量であった。
次に、10分間平均のトラヒック量の時系列データに基づいて、パラメータpの算出を行った。本実験では、パラメータpは、図16に示すように回線1では、p=6、回線2では、p=11となった。尚、パラメータpの算出には、第一の実施形態で説明した手法(S303〜S304)を用いた。
求めたパラメータpの値を用い、1回線について10秒間平均のトラヒック量分布を生成し、さらに回線数を増やし多重化してトラヒック量の分布を算出した。回線1及び2について、その95%値を10秒間平均のトラヒック量分布の95%値とし、10分平均でのトラヒック量の対応関係を図17に示す。尚、回線平均使用率(%)とは、平均スループットを物理回線帯域で割ったものをいい、95%値とは、トラヒック量の分布が与えられたときに95%を占める部分をいう。
回線1は、トラヒック量が大きく、かつバーストを多く含み、回線2ではバーストが少なく差が小さくなる結果を得た。また、図17における回線1と2のトラヒック量95%値に対して、最小2乗法を用いて、数式32の1次式で近似した場合、回線1と2についてa及びbの値は、表2のようになった。
<数32>
10秒間の平均トラヒック量95%値=a×10分間の平均トラヒック量95%値+b
次に、当該トラヒック量の推定値に基づき、単一ルータで発生する遅延時間の評価を行った。尚、計算機シミュレーションには、「Fantasy」(非特許文献2)を用いた。
評価モデルを図18に示す。ルータ13には、入力回線11aが複数あり、出力回線11bが一つであるモデル(以下、ルータ単一モデルという)を用いた。尚、符号13aは、入力バッファを示している。また、パラメータとして、以下の値を入力した。
1)シミュレーション時間 10秒間
2)スイッチ速度 8×108PPS(Packets Per Second)
3)バッファ量 150,000パケット
次に、評価モデルにトラヒックモデル1及び2を入力し、計算機シミュレーションにより遅延時間を算出した。尚、評価モデルの条件ではパケット廃棄は起こらなかった。
平均遅延時間と遅延時間95%値の算出結果を回線1について図19に、回線2について図20に示す。回線1は伝送速度が速いため、回線2の遅延特性と比較し、遅延時間が少なくなる特性を示した。また、回線2は回線使用率約50%で、遅延時間の増加が急激に大きくなる特性を示した。
また、図17で求めた10分間平均と10秒間平均のトラヒック量を、数式32により補正した。その結果を回線1については、図21に、回線2については、図22に示す。
これを補正前の遅延特性と比較すると、回線使用率が低いところで遅延の増大傾向が現れる。また、回線2は、低速なため、回線使用率45%で遅延時間の増加が急激に大きくなる特性を示している。
以上より、単一ルータに対して200ミリ秒以下で運用するためには、トラヒック量推定処理より得られる10分間平均の回線利用率は30%以下で運用することが望ましいことがわかった。