(57)【特許請求の範囲】
【請求項１】
複数のTCPソースのそれぞれが所定のタイミングでTCPコネクションを順次生起させ、TCPコネクションごとに所定量のデータが送出されるネットワーク用の疑似トラヒック生成装置において、
TCPソースごとに帯域の制限値を設定する帯域制限値設定手段と、
TCPソースごとに、帯域が前記各帯域制限値で制限されるトラヒックモデルを生成するトラヒックモデル生成手段と、
前記各トラヒックモデルに基づいて、各TCPソースが送出するデータを送出時刻ごとに累算して送出する疑似トラヒック発生手段とを含み、
前記帯域制限値設定手段は、各TCPソースの帯域制限値を、その総和が前記ネットワークのリンク帯域よりも大きく設定することを特徴とする疑似トラヒック生成装置。
【請求項２】
前記トラヒックモデル発生手段は、
TCPソースごとに、TCPコネクションの生起間隔に関する確率分布に基づいて、各TCPコネクションの生起タイミングを設定する手段と、
TCPソースごとに、各TCPコネクションで送出されるデータ量に関する確率分布に基づいて、各TCPコネクションで送出されるデータ量を設定する手段とを含み、
前記設定された生起タイミングおよびデータ量に基づいて前記トラヒックモデルを生成することを特徴とする請求項１に記載の疑似トラヒック生成装置。
【請求項３】
前記トラヒックモデル発生手段は、各TCPコネクションにおいて送出されるデータを複数のパケットに分割し、各パケットを前記帯域制限値に基づいて複数のパケット群（バースト）に分類し、各パケットがパケット群単位で送出されるようにすることを特徴とする請求項２に記載の疑似トラヒック生成装置。
【請求項４】
前記トラヒックモデル発生手段は、パケット群ごとに、パケット間隔に関する確率分布に基づいて、各パケット間隔を設定する手段と、TCPコネクションごとに、パケット群間隔に関する確率分布に基づいて、各パケット群間隔を設定する手段とを含み、前記設定されたパケット間隔およびパケット群間隔に基づいて各パケットの送出タイミングを設定することを特徴とする請求項３に記載の疑似トラヒック生成装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は疑似トラヒック生成装置に係り、特に、多重化されたＴＣＰ／ＩＰコネクションを想定した疑似トラヒックを簡易な構成で構築できるようにした疑似トラヒック生成装置に関する。
【０００２】
【従来の技術】
近年、トラヒックの増大に伴い、高速回線を用いて構築されたネットワークに関する研究、実験が行われている。このようなネットワークの構築にあたっては、実トラヒックに類似した負荷を事前にネットワークに加え、通信実験を行っておくことが必要である。
【０００３】
通信実験のためにネットワークに流すＩＰパケットを生成する従来装置としては、(1) 周期的にすなわち一定の時間間隔でＩＰパケットを生成する装置、(2) バースト的にＩＰパケットを生成する装置、あるいは(3) ランダムな時間間隔でＩＰパケットを生成する装置が提案されている。
【０００４】
しかしながら、上記した従来技術の装置で発生されるＩＰパケットのパターンは現実のトラヒックのパターンとは大きく異なるので、これらの装置で発生されたＩＰパケットをネットワークに流しても現実のトラヒックに近い負荷を加えているとはいえないという問題があった。
【０００５】
また、従来は固定長のパケットを生成しているので、実際のネットワークに流される可変長のＩＰパケットとは異なるという問題があった。
【０００６】
このような技術課題を解決するために、本発明等は、長期依存性のあるトラヒック分布に従ってＩＰパケットを生成することができる装置を開発して特許出願した（特開平２０００−２９２４２５号公報）。
【０００７】
【発明が解決しようとする課題】
多重化ＴＣＰ／ＩＰトラヒックの特性は、多重化によるＴＣＰコネクション間のインタラクションの影響をはじめとしたネットワークの挙動に影響を受けていると考えられる。従って、多重化ＴＣＰトラヒックに対応した疑似トラヒックを生成する場合、理想的には、各ＴＣＰソースのトラヒックモデルを他のＴＣＰソースのトラヒックモデルとの関係を考慮して生成することが望ましい。
【０００８】
しかしながら、疑似トラヒックのモデル化に際して、複数のＴＣＰコネクション間のインタラクションやＴＣＰの厳密な挙動を考慮することは多大な複雑さを伴い、その結果、これをネットワークの設計・運用計画策定に資するにあたって、解析的なアプローチはもとより、シミュレーションベースのアプローチすら困難なものとなってしまう。
【０００９】
本発明の目的は、上記した従来技術の課題を解消し、ネットワークの設計・運用計画策定において考慮すべき特徴的な特性を維持する事で、現実に近い負荷を簡単な構成でネットワークに供給できる疑似トラヒック生成装置を提供することにある。
【００１０】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、複数のＴＣＰソースのそれぞれが所定のタイミングでＴＣＰコネクションを順次生起させ、ＴＣＰコネクションごとに所定量のデータが送出されるネットワーク用の疑似トラヒック生成装置において、 ＴＣＰソースごとに帯域の制限値を設定する帯域制限値設定手段と、帯域が前記各帯域制限値で制限されるトラヒックモデルをＴＣＰソースごとに発生するトラヒックモデル発生手段と、前記各トラヒックモデルに基づいて、各ＴＣＰソースが送出するデータの量を送出時刻ごとに累算して送出する疑似トラヒック発生手段とを含み、前記帯域制限値設定手段は、各ＴＣＰソースの帯域制限値を、その総和が前記ネットワークのリンク帯域よりも大きく設定することを特徴とする。
【００１１】
上記した特徴によれば、各ＴＣＰソースのトラヒックモデルは、各ＴＣＰソースに割り当てられた帯域制限値を超えないように生成されるが、各ＴＣＰソースの帯域制限値は、その総和がネットワークのリンク帯域よりも大きくなるように設定される。したがって、各ＴＣＰソースのトラヒックモデルを生成する際に、他のＴＣＰソースのトラヒックモデルとの関係を無視して独立的に生成し、その後、各トラヒックモデルを合成して疑似トラヒックを生成しても、現実に近い疑似トラヒックを生成することができる。
【００１２】
【発明の実施の形態】
以下、図面を参照して本発明を詳細に説明する。図１は、本発明の一実施形態の構成を示したブロック図であり、ホスト端末１と、このホスト端末１から提供されたデータに基づいて疑似トラヒックを生成する疑似トラヒック生成部２とから構成されている。
【００１３】
本実施形態では、図３に示したように、複数のＴＣＰソースＵi｛ｉ＝１，２，…Ｉ｝がそれぞれ独立的にｊ番目｛ｊ＝１，２，…Ｊ｝のＴＣＰコネクションＣj（ｉ）を順次生起させる場合を考える。複数のＴＣＰソースＵiにより次々（ｊ＝１，２，…）と生起される多数のＴＣＰコネクションＣj（ｉ）は独立に扱われ、最終的に生成される疑似トラヒックは、各ＴＣＰコネクションＣj（ｉ）によって送出されるデータの単純和とする。
【００１４】
図１の疑似トラヒック生成部２において、帯域制限値設定部２１は、ホスト端末１から提供される試験対象ネットワーク３のリンク帯域に基づいて、ＴＣＰソースＵiごとに、帯域の制限値[パケットロスの発生するウインドウサイズ：後述するＷloss（ｉ，ｊ）]を設定する。
【００１５】
本実施形態では、帯域遅延積（＝リンク帯域×ＲＴＴ）を、その帯域を平均的に使用していると考えられるＴＣＰコネクションのそれぞれに公平に割り当て、これを各ＴＣＰコネクションが利用可能な帯域Ｗとみなした上で、Ｗloss（ｉ，ｊ）をその２倍と算出している。Ｗloss（ｉ，ｊ）を２倍とするのは、ＴＣＰの輻輳ウィンドウサイズの変化を考慮した概算による。
【００１６】
トラヒックモデル生成部２２は、後にフローチャートを参照して詳述するように、前記帯域制限値および前記ホスト端末１から提供される各種の情報に基づいて、ＴＣＰソースＵiごとに、帯域が前記各帯域制限値で制限されるトラヒックモデルを生成し、そのパラメータを疑似トラヒック発生部２３の出力テーブル２３ａに登録する。
【００１７】
図２は、前記出力テーブル２３ａの構成を示した図であり、後述するパケット送出時刻Ｐm（ｉ、ｊ、ｋ）、パケットサイズＰＳm（ｉ、ｊ、ｋ）、送信元ＩＰに相当するＴＣＰソースの序数ｉ、宛先ＩＰに相当するコネクションの序数ｊ、バーストの序数ｋおよびパケットの序数ｍが、前記パケット送出時刻Ｐm（ｉ、ｊ、ｋ）でソートされて登録される。
【００１８】
疑似トラヒック発生部２３は、前記出力テーブル２３ａに登録された各トラヒックモデルのパラメータに基づいて、各ＴＣＰソースＵiが送出するデータを送出時刻ごとに累算して得られる疑似トラヒックを発生する。回線インターフェース２４は、前記疑似トラヒック発生部２３から発生された疑似トラヒックをネットワーク３上に送出する。
【００１９】
本実施形態では、図３に示したように、各ＴＣＰソースＵiがｊ番目のＴＣＰコネクションＣj（ｉ）を生起させるタイミングが、前回の生起タイミングと今回の生起タイミングとの間隔を代表する生起間隔ΔＣj（ｉ）で定義される。各生起間隔ΔＣj（ｉ）は、ＴＣＰソースＵiごとに予め設定された確率分布Ｆ［ΔＣ（ｉ）]に基づいて決定される。
【００２０】
各ＴＣＰソースＵiがｊ番目に生起させるＴＣＰコネクションＣj（ｉ）で送出されるデータ量Ｄj（ｉ）は、ＴＣＰソースＵiごとに予め設定された確率分布Ｆ［ΔＤ（ｉ）]に基づいて設定される。
【００２１】
図４は、各ＴＣＰコネクションＣj（ｉ）において送出されるデータの構造を模式的に示した図である。
【００２２】
各ＴＣＰコネクションＣj（ｉ）では、複数のパケットが、その総和がデータ量Ｄj（ｉ）となるまで送り出される。各パケットはＫ個のパケット群（以下、バーストと表現する）に区切られ、各パケットはバースト単位で連続して送出される。各ＴＣＰソースＵiが１回のバーストで送出できるパケット数はウィンドウサイズによって制限される。なお、パケットが１つしか送出されない場合も、本実施形態では１個のパケットから構成されるバーストと考える。
【００２３】
ＴＣＰソースＵiがｊ番目に生起させたＴＣＰコネクションＣj（ｉ）内でｋ番目のバーストＢk（ｉ，ｊ）にはＬk（ｉ，ｊ）個のパケットが設定される。
【００２４】
各バーストＢk（ｉ，ｊ）内でのｍ番目のパケットのサイズＰＳm（ｉ，ｊ，ｋ）は、各コネクション内での最後のパケットを除いて最大パケットサイズ（すなわち、１４６０バイト）である。各バースト間隔ＢＧk（ｉ，ｊ）および各バースト内でのパケット間隔ＰＧm（ｉ、ｊ、ｋ）は、ＴＣＰソースＵiごとに予め設定された確率分布に基づいて設定されるものとする。
【００２５】
なお、本実施形態ではトラヒック量に着目したモデル化を意図するものとし、コネクション確立のためのパケット、コネクション終了のためのパケットおよび受信側から返送されるACKパケットについては無視する。
【００２６】
図５は、本実施形態における出力テーブル２３ａの生成方法を示したメインフローチャートであり、主に前記トラヒックモデル発生部２２の動作を示している。
【００２７】
ステップＳ１からＳ１０では、ＴＣＰソースＵiごとにステップＳ２からＳ９の処理が繰り返される。ステップＳ２では、前回のコネクションの生起時刻を代表する前回生起時刻ｔがリセットされる。ステップＳ３では、ＴＣＰソースＵiにより生起されるコネクションの序数を代表する変数ｊに「１」がセットされる。
【００２８】
ステップＳ４では、予めＴＣＰソースＵiごとに用意されている、コネクションの生起間隔に関する確率分布Ｆ［ΔＣ（ｉ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションに関する生起間隔ΔＣj（ｉ）が設定される。ステップＳ５では、前回生起時刻ｔと今回の生起間隔ΔＣj（ｉ）との和が新たな前回生起時刻ｔとして登録される。
【００２９】
ステップＳ６では、予めＴＣＰソースＵiごとに用意されている、疑似トラヒックのデータ量に関する確率分布Ｆ［ΔＤ（ｉ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションで送出されるデータ量Ｄj（ｉ）が設定される。ステップＳ７では、前記各ステップＳ４，６で求めたコネクションの生起間隔ΔＣj（ｉ）およびデータ量Ｄj（ｉ）に基づいて前記出力テーブル２３ａを作成するための出力テーブル作成処理が実行される。
【００３０】
図６は、前記出力テーブル作成処理の動作を示したフローチャートである。
【００３１】
ステップＳ７１では、予めＴＣＰソースＵiごとに用意されている、マキシマムセグメント（パケット）サイズＭＳＳに関する確率分布Ｆ［ＭＳＳ（ｉ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションにおけるマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）が設定される。
【００３２】
ステップＳ７２では、予めＴＣＰソースＵiごとに用意されている、受信側通知ウインドウサイズに関する確率分布Ｆ［Ｗrev（ｉ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションにおける受信側通知ウインドウサイズＷrev（ｉ，ｊ）が設定される。
【００３３】
ステップＳ７３では、予めＴＣＰソースＵiごとに用意されている、パケットロスの発生するウインドウサイズに関する確率分布Ｆ［Ｗloss（ｉ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションにおけるパケットロスウインドウサイズＷloss（ｉ，ｊ）が設定される。
【００３４】
ステップＳ７４では、ＴＣＰソースＵiのｊ番目のコネクションにおいてデータ量Ｄj（ｉ）のデータを送出するのに必要なバースト数Ｋ（ｉ，ｊ）、およびｋ番目のバーストに含まれるパケット数Ｌk（ｉ，ｊ）を設定するためのバースト数Ｋ／バースト内パケット数Ｌkの設定処理が実行される。
【００３５】
図７は、前記バースト数Ｋ／バースト内パケット数Ｌk設定処理の動作を示したフローチャートであり、図１０は、送出データ量のタイミングチャートである。
【００３６】
ステップＳ７４０１では初期化が実行され、バーストの序数を代表する変数ｋに「１」がセットされる。更に、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバーストに含まれるパケット数を代表するＬk（ｉ，ｊ）に初期値として「１」がセットされ、スロースタート閾値Ｒssthが無限大にセットされる。ステップＳ７４０２では、設定済みデータ量ＳＵＭがリセットされる。
【００３７】
ステップＳ７４０３では、パケット数Ｌk（ｉ，ｊ）とマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）との乗算値[すなわち、ｋ番目（今回）のバーストにおけるデータ設定量]と設定済みデータ量ＳＵＭとの加算値[すなわち、現時点での設定済みデータ量]と、今回のコネクションで設定すべき全データ量Ｄj（ｉ）とが比較される。最初は設定済みデータ量が設定すべき全データ量Ｄj（ｉ）を下回るのでステップＳ７４０４へ進み、前記加算値が新たな設定済みデータ量ＳＵＭとして登録される。
【００３８】
ステップＳ７４０５では、今回のバースト内で現在までに設定されたパケット数Ｌk（ｉ，ｊ）とマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）との乗算値、すなわち今回のバースト内で現在までに設定されたデータ量と、パケットロスウインドウサイズＷloss（ｉ，ｊ）とが比較される。最初は設定済みデータ量がパケットロスウインドウサイズＷloss（ｉ，ｊ）を下回っており、パケットロスが発生していないのでステップＳ７４０６へ進む。
【００３９】
ステップＳ７４０６では、バースト序数ｋがインクリメントされて次のバーストへ移行する。ステップＳ７４０７では、前回のバースト内のパケット数Ｌk-1（ｉ，ｊ）とマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）との乗算値である、前回のバーストで設定されたデータ量がスロースタート閾値Ｒssthと比較される。
【００４０】
ここで、図１０のタイミングｔ１のように、バースト内で現在までに設定されたデータ量がパケットロスウインドウサイズＷloss（ｉ，ｊ）を超える前までは、スロースタート閾値Ｒssthが無限大であり、送出データ量がスロースタート閾値Ｒssthよりも小さい。従って、パケット数Ｌk（ｉ，ｊ）を公知のスロースタート制御に基づいて増加させるべくステップＳ７４０８へ進む。
【００４１】
ステップＳ７４０８では、（ｋ−１）番目のバーストに含まれるパケット数Ｌk-1（ｉ，ｊ）と定数ａとの乗算値の切り上げ値［ｃｅｉｌ]と前記パケット数Ｌk-1（ｉ，ｊ）との加算値が、今回（ｋ番目）のバーストに含まれるパケット数Ｌk（ｉ，ｊ）として登録される。
【００４２】
ステップＳ７４１０では、パケット数Ｌk（ｉ，ｊ）とマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）との乗算値が前記受信側通知ウインドウサイズＷrev（ｉ，ｊ）と比較される。乗算値が受信側通知ウインドウサイズＷrev（ｉ，ｊ）を下回っていればそのまま終了し、上回っていればステップＳ７４１１へ進む。
【００４３】
ステップＳ７４１１では、受信側通知ウインドウサイズＷrev（ｉ，ｊ）をマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）で除算した値の切り捨て値［ｆｌｏｏｒ]が、受信側により制限されたパケット数Ｌk（ｉ，ｊ）として登録される。
【００４４】
その後、図１０のタイミングｔ２において、設定済みデータ量が受信側通知ウインドウサイズＷloss（ｉ，ｊ）を上回り、これが前記ステップＳ７４０５において判別されると、ステップＳ７４１２では、バースト序数ｋがインクリメントされ、パケット数Ｌk（ｉ，ｊ）が初期値の「１」に戻される。更に、スロースタート閾値Ｒssthが、パケット数Ｌk（ｉ，ｊ）を２で割った除算値と「２」との大きい方の値にセットされる。
【００４５】
その後、図１０のタイミングｔ３では、前記ステップＳ７４０７の判定結果が否定となるので前記と同様にステップＳ７４０８へ進む。これに対して、タイミングｔ４では、送出データ量がスロースタート閾値Ｒssthよりも大きくなるので、パケット数Ｌk（ｉ，ｊ）を公知の輻輳回避制御に基づいて増加させるべくステップＳ７４０９へ進む。
【００４６】
ステップＳ７４０９では、パケット数Ｌk-1（ｉ，ｊ）の逆数と定数ａとの乗算値の切り上げ値［ｃｅｉｌ]と前記パケット数Ｌk-1（ｉ，ｊ）との加算値がパケット数Ｌk（ｉ，ｊ）として登録される。
【００４７】
その後、前記ステップＳ７４０３において、設定済みデータ量がデータ量Ｄj（ｉ）を超えると、ステップＳ７４１３では、当該時点でのバースト序数ｋがＴＣＰソースＵiのｊ番目のコネクションにおけるバースト数Ｋ（ｉ，ｊ）として登録される。
【００４８】
更に、データ量Ｄj（ｉ）から設定済みデータ量ＳＵＭを減じた値をマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）で割った除算値の切り上げ値［ｃｅｉｌ]が、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバーストに含まれるパケット数Ｌk（ｉ，ｊ）として登録される。
【００４９】
図６のフローチャートに戻り、ステップＳ７５では、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバースト内でのｍ番目のパケットのサイズＰＳm（ｉ，ｊ，ｋ）を求めるパケットサイズ設定処理が実行される。
【００５０】
図８は、前記パケットサイズ設定処理の動作を具体的に示したフローチャートである。
【００５１】
ステップＳ７５０１では、ＴＣＰソースＵiのｊ番目のコネクションにおいて設定されるデータ量Ｄj（ｉ）が、残余パケットサイズＳＩＺＥに暫定登録される。ステップＳ７５０２からＳ７５０９では、バーストごとにステップＳ７５０３からＳ７５０８の処理が繰り返される。ステップＳ７５０３からＳ７５０８では、パケットごとにステップＳ７５０４からＳ７５０７の処理が繰り返される。
【００５２】
ステップＳ７５０４では、今回の注目パケットが現在のバースト内での最後のパケットであるか否かが判定される。最後のパケットと判定されるまではステップＳ７５０５へ進み、現在の残余パケットサイズＳＩＺＥからパケットサイズすなわちマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）を減じた値が新たな残余パケットサイズＳＩＺＥとして登録される。
【００５３】
ステップＳ７５０６では、今回のマキシマムセグメントサイズＭＳＳ（ｉ，ｊ）が 、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバースト内でのｍ番目のパケットサイズＰＳm（ｉ，ｊ，ｋ）として登録される。
【００５４】
また、前記ステップＳ７５０４において、今回のパケットがバースト内での最後のパケットと判定されると、ステップＳ７５０７では、現在の残余パケットサイズＳＩＺＥが最後のパケットのサイズＰＳm（ｉ，ｊ，ｋ）として登録される。
【００５５】
図６に戻り、ステップＳ７６では、各ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバースト内でのｍ番目のパケットのパケット送出時刻Ｐm（ｉ，ｊ，ｋ）を求めるパケット送出時刻設定処理が実行される。
【００５６】
図９は、前記パケット送出時刻設定処理の動作を詳細に示したフローチャートである。
【００５７】
ステップＳ７６０１では、所定の基準時刻ｔが今回のパケット送出時刻ｔｐとして登録される。ステップＳ７６０２からＳ７６１０では、バーストごとにステップＳ７６０３からＳ７６０９の処理が繰り返される。ステップＳ７６０３からＳ７６０７では、パケットごとにステップＳ７６０４からＳ７６０６の処理が繰り返される。
【００５８】
ステップＳ７６０４では、今回パケット送出時刻ｔｐが、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバースト内でのｍ番目のパケットのパケット送出時刻Ｐm（ｉ，ｊ，ｋ）として登録される。ステップＳ７６０５では、予め用意されているバースト内パケット間隔に関する確率分布Ｆ［ΔＰＧ（ｉ、ｊ、ｋ）]に基づいて、バースト内パケット間隔ΔＰＧm（ｉ、ｊ、ｋ）が設定される。ステップＳ７６０６では、今回パケット送出時刻ｔｐとバースト内パケット間隔ΔＰＧm（ｉ、ｊ、ｋ）との和が新たな今回パケット送出時刻ｔｐとして登録される。
【００５９】
今回の注目バーストに関する処理が終了すると、ステップＳ７６０８では、予め用意されているバースト間隔に関する確率分布Ｆ［ΔＢＧ（ｉ、ｊ）]に基づいて、ＴＣＰソースＵiのｊ番目のコネクションにおけるｋ番目のバースト間隔ΔＢＧk（ｉ、ｊ）が設定される。ステップＳ７６０９では、今回パケット送出時刻ｔｐと前記バースト間隔ΔＢＧk（ｉ、ｊ）との和が、新たな今回パケット送出時刻ｔｐとして登録される。
【００６０】
以上のようにして、全てのＴＣＰソースから送出されるパケットの送出時刻が同一の時間軸で整理されると、図６のステップＳ７７へ進み、パケット送出時刻Ｐm（ｉ、ｊ、ｋ）およびパケットサイズＰＳm（ｉ、ｊ、ｋ）が、前記ｉ，ｊ．ｋ，ｍと共に出力テーブル２３ａに登録される。
【００６１】
図５に戻り、ステップＳ８ではコネクション序数がインクリメントされる。ステップＳ９では、現在までの監視時間ｔが所定の監視周期Ｔと比較される。監視時間ｔが監視周期Ｔ内であればステップＳ３に戻って上記した各処理が繰り返される。監視時間ｔが監視周期Ｔを超えると、ステップＳ１０では、注目ＴＣＰソースが次のＴＣＰソースＵiへ移行される。
【００６２】
全てのＴＣＰソースＵiについての処理が終了すると、ステップＳ１１では、ＴＣＰソースごとに求められた出力テーブル２３ａ上のデータが、パケット送出時刻Ｐm（ｉ、ｊ、ｋ）に基づいて並べ替えられる。ステップＳ１２では、疑似トラヒック発生部２３が前記データに基づいて疑似トラヒックを出力する。
【００６３】
【発明の効果】
本発明によれば、各ＴＣＰソースのトラヒックモデルは、各ＴＣＰソースに割り当てられた帯域制限値を超えないように生成されるが、各ＴＣＰソースの帯域制限値は、その合計がネットワークの帯域よりも大きくなるように設定されるので、各ＴＣＰソースのトラヒックモデルを生成する際に、他のＴＣＰソースのトラヒックモデルとの関係を無視して独立的に生成し、その後、各トラヒックモデルを合成して疑似トラヒックを生成しても、現実に近い疑似トラヒックを生成する事ができる。
【図面の簡単な説明】
【図１】  本発明の一実施形態の構成を示したブロック図である。
【図２】  出力テーブル２３ａの構成を示した図である。
【図３】  本発明におけるＴＣＰコネクションの生起タイミングの設定方法を示した図である。
【図４】  各ＴＣＰコネクションにおいて送出されるデータの構造を模式的に示した図である。
【図５】  出力テーブルの生成方法を示したフローチャートである。
【図６】  出力テーブル作成処理のフローチャートである。
【図７】  バースト数Ｋ／バースト内パケット数Ｌkの設定処理の動作を示したフローチャートである。
【図８】  パケットサイズ設定処理のフローチャートである。
【図９】  パケット送出時刻設定処理のフローチャートである。
【図１０】  送出データ量の変化を示したタイミングチャートである。
【符号の説明】
１…ホスト端末、２…疑似トラヒック生成部、３…試験対象ネットワーク、２１…帯域制限値設定部、２２…トラヒックモデル生成部、２３…疑似トラヒック発生部、２３ａ…出力テーブル、２４…回線インターフェース
【図１】
0003731730.tif 000002
【図２】
0003731730.tif 000003
【図３】
0003731730.tif 000004
【図４】
0003731730.tif 000005
【図５】
0003731730.tif 000006
【図６】
0003731730.tif 000007
【図７】
0003731730.tif 000008
【図８】
0003731730.tif 000009
【図９】
0003731730.tif 000010
【図１０】
0003731730.tif 000011