JP3090388B2 - ネットワークのデータトラフィックのモデル化及びシミュレーション方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、広くは、通信ネットワ
ーク及び分散処理システムの動作及びパフォーマンスの
モデル化及びシミュレーションに関し、特に、そのよう
なネットワーク及びシステムのノードで発生したデータ
トラフィックのシミュレーションの精度を高めるモデル
化の方法に関する。

【０００２】

【従来の技術】過去２０年間におけるコンピュータと通
信との融合は、コンピュータ通信ネットワーク及び分散
処理システムの爆発的成長へと発展した。今日の通信ネ
ットワークの規模及び複雑さは、回路基板または半導体
上の複数のプロセッサのネットワークから何千ものユー
ザーがいるグローバルネットワークまで多様であるのに
対し、すべての通信ネットワークの基本機能は同じであ
る。すなわち、スイッチ、マルチプレクサ、コンセント
レータ、プロセッサ、及び、通信リンクからなる共有設
備を通した情報転送である。ネットワークユーザーのリ
ソースの共有は、管理及び統制方法と同様に、プロトコ
ルによって決められる。

【０００３】通信ネットワークの設計、実現及び運用上
の主要問題は、パフォーマンスの評価及びトレードオフ
分析である。通信ネットワークを評価するために使われ
るパフォーマンスの尺度は、分析するネットワークの種
類及び利用目的によって異なる（例えば、軍事または商
用、音声またはデータ、など）。軍事的通信システムで
は、主要なパフォーマンスの要求は、ネットワークの悪
環境での脆弱性及び耐久能力を含んでいる。商用通信ネ
ットワークの場合、回線交換ネットワークの最も標準的
な測定には、閉鎖の可能性、サービスの等級、スループ
ット、及びネットワーク効率が含まれる。スループッ
ト、延滞、及びリソース利用は、蓄積転送型商用ネット
ワークでは最も重要なパフォーマンスの尺度である。類
似のパフォーマンスへの関心が、分散処理システムの設
計の基準にもなっている。

【０００４】コンピュータを相互接続するためには、多
くの様々な種類のネットワークプロトコル、及び機器構
成があることは、コンピュータネットワーク技術の当業
者にはよく知られている。コンピュータネットワークの
一例として、最もよく使われている分散処理システム体
系の１つに、図１に示すような階層通信ネットワーク構
造をその中心部分に持っているものがある。Ｃａｍｐｕ
ｓ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）と呼ばれるこの
階層ネットワーク構造は、例えばＦｉｂｅｒＤｉｓｔｒ
ｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ（ＦＤＤ
Ｉ）のような高速バックボーン（１００Ｍｂｐｓ以上）
で構成され、それが多数の速度の遅いワークグループネ
ットワークにつながっている。次に、これらの各ワーク
グループのネットワークは、多くのローカルエリアネッ
トワーク（ＬＡＮ）、例えば１０Ｍｂｐｓのイーサネッ
ト、つまりＩＥＥＥ８０２．３を階層的に相互接続して
構成することができる。各ワークグループネットワーク
は、コンピュータ、及びワークステーション等を所定の
ワークグループで相互接続するために使われる。そして
バックボーンを使って、様々なワークグループ間のデー
タ共有及び通信が行われる。

【０００５】このＣＡＮの例は、非常に大きく多様な技
術ユーザー及び管理ユーザーの集団の要求を満たすよう
に構成されている。最終的にこのネットワークは、多数
の階層的に接続されたＬＡＮから構成可能で、それぞれ
は図３に示すような樹形トポロジーになるだろう。次
に、これらのＬＡＮはＦＤＤＩ ＬＡＮを使って相互接
続できるだろう。図２及び図３にあるように、ＦＤＤＩ
リングの各接続箇所はＩＥＥＥ ８０２．３ブリッジで
あり、マルチポートトランシーバー（ＭＰＴ）、１０−
Ｂａｓｅ−Ｔハブ、またはイーサネットバックボーンの
いずれかに接続されている。これらすべてのイーサネッ
トサブネットは、エンジニアリングワークステーション
（ＥＷＳ， Ｗ／Ｓ）、パーソナルコンピュータ（Ｐ
Ｃ）、及びファイルサーバ（ＦＳ， Ｆ／Ｓ）等の装置
への最大１０個までの接続をサポートし、これら数百の
装置は、最終的には数千に達する。

【０００６】また、ＩＥＥＥ Ｆｕｔｕｒｅｂｕｓ₊ Ｐ
８９６．１を含めて、当事者には馴染みのある下位の処
理機能を相互接続するためのプロトコルも多数存在して
いる。Ｆｕｔｕｒｅｂｕｓ₊プロトコルに基づくマルチ
プロセッシングの一例を図４に示す。この図にあるよう
に、このようなシステムは順次、ローカルエリアネット
ワーク（ＬＡＮ）への接続を通して、より大きな通信ネ
ットワークのノードを構成することができる。

【０００７】コンピュータネットワークの当業者であれ
ば、実際に図１及び図４に示された種類の大きなシステ
ムを構成する際の問題の大きさは容易に理解できる。複
雑な通信ネットワークのハードウエア及びソフトウエ
ア、並びに作動するネットワークを構成するのにかかる
コストは無視できるものではない。過去においては、立
証されていない設計は頻繁に、不必要な物品の購入及び
日々のネットワーク運用の中断の原因となった。

【０００８】ネットワークのパフォーマンスを評価する
現在ある方法は、直接測定する技術の利用、数学モデル
を用いた解析及びネットワークの実際のシミュレーショ
ンである。ネットワークに接続しモニタ機器の利用によ
る直接測定は、時間がかかり、実際にあるネットワーク
のパフォーマンスしか示さない。ノードやアプリケーシ
ョンを加えたときのネットワークのパフォーマンスへの
影響の予測は、ほとんどの場合において信頼性がない。
しかし、これらのツールはシミュレーションモデルを作
るための統計的データを得るために利用することができ
る。

【０００９】数学モデルに基づくネットワークの分析
は、処理できるモデルを開発するために多くの限定的な
仮定を要する。ゆえに、理想的で、かつ、多くの場合極
端に単純化されたケース除けば、一般に厳密な形の解を
得るのは不可能である。

【００１０】しかし、特定のネットワークの動作のシミ
ュレーションは、経験的なモデルと測定データをより容
易に組合せることができ、実際のネットワークパフォー
マンス、トレードオフ分析及び他の選択肢の評価とを、
より正確に予測するために利用することができる。

【００１１】ネットワークシミュレーションは、通信ネ
ットワークの設計、分析及び管理において重要な役割を
演じ得る。シミュレーションの結果は、ネットワークパ
フォーマンスの評価及び最適化のために利用できる。シ
ミュレーションを通して計算される典型的なパフォーマ
ンス尺度には、システムスループット、平均応答時間、
リソース利用、閉鎖及び損失の可能性、故障のあと回復
までにかかる時間、及び、ネットワークの過渡応答にと
もなう他のパラメータがある。これらの結果は、構成要
素及びアーキテクチャのレベルでのネットワーク設計の
選択肢の評価、構成要素を購入して試みる前のパフォー
マンスの予測、及び、物品購入のための構成及び仕様を
作るために利用できる。

【００１２】シミュレーションはまた、ネットワーク管
理においても重要な役割を演じ得る。ネットワーク管理
者は、ネットワークトラフィック、トポロジー、ハード
ウエア、及びソフトウエアの変更によるネットワークパ
フォーマンスの変化を予測するためのツールを必要とし
ている。管理者は「もし〜ならばどうなる」シナリオの
回答を得るため、容量変更の計画作成における補助をす
るため、負荷の均衡をとるため、ネットワーク耐久性シ
ナリオを作成するため、及び例外的な調査のためのツー
ルを必要としている。実際のネットワークで実験してみ
ることなく、管理者はネットワーク管理のための戦略の
選択肢をシミュレーションツールを使って評価すること
ができる。

【００１３】図２に絵画的に示し、図３に模式的に示し
たＣＡＮの例のようなネットワークアーキテクチャの動
作をシミュレートするために、このネットワークを完全
に表すようにモデルを規定しなければならない。ある程
度の抽象化や構成要素の集合化を、モデルの複雑さを減
少させることが可能な部分で織り込むことはよくある。
するとシミュレーションは、実際にはモデルが反応する
離散型のイベントを強制的に適用することによりモデル
を実行することになる。

【００１４】ネットワークパフォーマンスを評価するの
に通常使われるシミュレーションテクニックは、離散型
イベントシミュレーションである。離散型イベントシミ
ュレーションでは、調べている実際のネットワークの様
々な構成要素（通信リンク、バッファ、アクセス戦略、
ネットワーク制御構造）は、コンピュータプログラムで
のモデルで表される。ネットワークの実際の運用の最中
に起き得るイベント（到着、転送、ルーティング及びメ
ッセージの発信；メッセージの損失または変化などのエ
ラー状態；リンク／ノード障害及び回復）は実際にモデ
ルを実行するプログラムの実行中に模倣される。

【００１５】シミュレーションプログラムの機能はモデ
ルが応答するイベントを作ることである。モデルの応答
はネットワークの応答をシミュレートする。またシミュ
レーションプログラムはシミュレーション中のデータを
集め、パフォーマンスの尺度も計算する。モデルがネッ
トワークの構成要素をより正確に複製すればするほど、
より正確に実際のネットワークの上記イベントへの応答
をモデル化することができるのは明かである。しかしな
がら、シミュレーションの正確さは、実際のネットワー
クのイベントがいかに正確に、実行しているモデルで模
倣されているかにもよることも明かであろう。

【００１６】分散処理システム及び通信ネットワークを
モデル化する基本的な手法は、本質的には同じである。
ネットワーク技術者は、情報の「パケット」のフローに
関心があり、ネットワークパフォーマンスは、延滞、ス
ループット、及びトランクなどの通信リソースの使用に
よって通常は評価される。その一方で、分散処理システ
ムの設計者は、システム中の「ジョブ」または「処理」
のフローに関心があり、システムのパフォーマンスは、
スループット、完了の平均時間、並びにＣＰＵやディス
ク、及びプリンタといったコンピュータリソースの使用
によって評価される。両方の場合とも、設計者は明かに
離散型イベントシステムを扱っており、パフォーマンス
目標がリソース（トランク、ＣＰＵ等）の制約の範囲内
で満たされるように複数の対象（ユーザー、プロセス、
ジョブ、または処理）にリソースを割り当てることに努
力する。ゆえに、本発明の説明は高レベルの通信ネット
ワークへの応用において行われているが、当業者は、本
発明を分散処理システムへ同様に応用できることをたや
すく理解できるであろう。

【００１７】そのようなネットワークを展開するリスク
を減少させるため、ネットワーク設計、分析、及び管理
に利用するネットワークシミュレーションツール、例え
ばComdisco Systems Inc.の販売するBONeS（商標）(Blo
ck Oriented Network Simulator)などが市販品として入
手できる。一般に入手可能なBONeS（商標）の製品とマ
ニュアルを参考のために本明細書に援用する。

【００１８】これらのシュミレーターは、所定のネット
ワークの各ノードで作り出され、シミュレーションを進
行させる離散型イベントを供給するデータトラフィック
のモデルを含めて、図１〜図３で描かれているようなネ
ットワークの様々な構成要素のふるまい標準及びユーザ
ー定義モデルを供給するが、それらには、所定のネット
ワークの各ノードで作られ、かつシミュレーションを駆
動する離散型イベントを供給するデータトラフィックの
モデルが含まれる。

【００１９】BONeS（商標）製品はまた、ネットワーク
中でデータが流れる物理的形式（つまり、データ構造）
もモデル化する。通常ネットワーク中のデータは、パケ
ットの形態で一つのノードから他のノードへと移動す
る。データパケットは、転送されている実際のメッセー
ジからなるバイナリデータを含んでいるが、通常はメッ
セージルーティング、アドレッシング、及びエラー検出
のためにネットワークによって加えられる付加的なオー
バーヘッドデータを含んでいる。厳密なパケット構造は
採用する特定のネットワークプロトコルによって異な
る。

【００２０】ネットワークプロトコルは個別の供給元に
より異なるが、ほとんどのものはプロトコル機能の階層
のセットとして構造化されており、階層間のインターフ
ェイスはきちんと定義されている。各階層は特有の機能
を実行し、階層にインプリメントされた項目は、その上
下に接した階層に対して透過的であり、各階層はネット
ワークを介して他のノードの対応する階層とのみ通信す
る。

【００２１】解放型システム相互接続(OSI)モデルは１
９８４年に国際標準化機構(ISO)により開発され、ネッ
トワークプロトコルの標準化のための枠組を提供してい
る(参考文献ISO 7498-1984)。この７階層モデルの描写
を図５に示す。各パケットはアプリケーション階層（階
層７）で生じ、そのオリジナルメッセージは次の階層で
さらに追加データとともにカプセル化される。

【００２２】ネットワークのBONeS（商標） Designer
（商標）モデルは、パケットのフローや、メッセージ、
ジョブ、または処理を表す階層的ブロック図により記述
される。図６は２ノード通信システムの単純なBONeS
（商標） Designer（商標）のブロック図であり、４つ
のブロックで構成されている。それらは、２つのトラフ
ィックソース、転送システム、及び目的値ノードであ
る。これはそのようなシミュレーション製品の利用を説
明するための簡単な例である。音声トラフィックソース
は階層的ブロックで、図７に示される多数の構成要素か
らできている。図７のブロックは、一様な到着間隔のパ
ケットを作り出し、パケットの生成時間フィールドに現
在のシミュレーションの時間を、長さフィールドに音声
パケット長パラメータの値を、及び、優先度フィールド
に１の値をセットする。音声ソースを出たパケットは、
例えばデジタル化された音声のような同期的ソースによ
り発生されるようなパケットを表している。図８に示す
データトラフィックソースはポワソン到着、かつ指数分
布長のトラフィックを発生するが、これはネットワーク
の個々のノードで作られるデータトラフィックの統計的
モデルを表すものである。２つのソースからの出力はマ
ージされ、転送システムにより送り出される。

【００２３】パケットを表すデータ構造は、発生される
データトラフィックの個々の種類（つまり、優先度、パ
ケットの長さ、など）に対応して作ることができる。デ
ータパケットには、ソースにより作られた時間が、及
び、パケットの目的地により受信された時間がスタンプ
される。時間スタンプを比較することで、延滞が計算で
きる。システムにより転送されたすべてのパケットのパ
ケット長を加算することで、スループットが計算でき
る。図７の中央のブロック群においてパケットが作られ
た時間に対する値、優先度及びパケット長がデータ構造
に挿入され、そしてその他の時間スタンプ（例えば、到
着時間）はパケットがシステム中の様々な地点を通過す
るときに挿入される。

【００２４】実際のネットワークを流れているパケット
のデータ構造には時間スタンプのためのフィールドがな
く、そして実際に長さがあるのでメッセージ長を表すフ
ィールドは必要ないことを指摘しておく。データ構造の
時間スタンプフィールドは、シミュレーション中のシス
テムでのパケットのフローの記録を作るために使用され
る。ネットワークプロトコルはメッセージ長を利用して
モデル化される。このメッセージ長によって、パケット
がシステム中を移動する間のいずれのカプセル化も説明
される。

【００２５】図６の中央のブロックは転送システムを表
している。これはソースから出てくるパケットを待ち行
列に加え、優先度に基づいて転送用のトランクを割り当
て、そして時間延滞の後でパケットを目的地ノードに向
けて送り出す。この延滞は転送時間を表す。この転送シ
ステムブロックは階層的で、待ち行列とリソース割り当
て用のBONeS（商標） Designer（商標）ライブラリを使
って作られている。

【００２６】転送延滞の合計は、転送システムのブロッ
クにおいて伝搬時間と転送時間の和として計算される。
これはビットで表されたパケット長をビットで表された
１秒当りのトランク容量で割ったものに等しい。ただ
し、リンクへ転送される個々のビットを実際に生成する
必要はない。実際に必要なのは、パケットを転送するの
に必要な時間を計算することだけであろ。これはパケッ
ト長のみの関数で、その内容とは関係がない。

【００２７】目的地ノードは受信したパケットに時間ス
タンプを押し、それらをシンクに入れる。パケットが受
信された時間及びそれが作られた時間の差を平均するこ
とで、すべての延滞の平均が計算される。これらのシミ
ュレーションを異なったトラフィック負荷で繰り返すこ
とにより、ネットワークに対する典型的な延滞と負荷の
グラフを作ることができる。

【００２８】新たなトラフィックソースは、すなわちこ
れは新たなノードを表すが、ただ新たなトラフィックソ
ースのブロックを図６のシステムブロック図に加えるだ
けで追加できる。あるいは、パラメータを変えること
で、または、まったく新しいトラフィックソースのブロ
ックを作ることで、トラフィックの特徴を修正すること
ができる。

【００２９】BONeS（商標）ネットワークシュミレータ
ーについてのさらに詳しい情報は、BONeS（商標） Desi
gner（商標） Introductory Overview、BONeS（商標）
Designer（商標） User's Guide、及びBONeS（商標） D
esigner（商標） Modeling Guideから入手し得る。一般
に入手できるすべての製品、マニュアル、及びサポート
資料は本明細書に援用されており、Comdisco Systems,
Inc., 919 East Hillsdale Boulevard, Foster City, C
alifornia 94404 より入手できる。

【００３０】例えば上記の例にある音声トラフィックソ
ース及びデータトラフィックソースに採用したシュミレ
ーターに用いられるトラフィックモデルは、生成された
パケット間のメッセージサイズ及び時間に関するある統
計的モデルに典型的に基づくものである。上記の例で、
音声トラフィックソースモデルは、均一な到着時間及び
固定のパケット長を仕様としている。データトラフィッ
クソースモデルは、ポワソン到着のトラフィック及び指
数的に分布したパケット長を仕様としている。これらの
モデルの問題点は、最良でも、いわば特定のネットワー
ク負荷状態で特定の時間に特定のノードで作られたデー
タパケットの総計の近似であるということである。

【００３１】各ネットワークノードは異なるコンピュー
タシステムの構成からなり得、それ自身のリソースを持
ち、それ自信に指定されたアプリケーションプログラム
を走らせている。例えば、あるノードはパーソナルコン
ピュータ（ＰＣ）で、２０メガバイトのハードディス
ク、８０３８６ＣＰＵ、ディスクドライブ、及び他の様
々なリソースを備えている。このノードは様々なアプリ
ケーション、例えば、スプレッドシート、ワードプロセ
ッサ、文書管理などの目的に使用できるだろう。またあ
るノードはエンジニアリングワークステーションで、強
力なサーキットシミュレーションのアプリケーションを
実行することができ、それはトラフィックの激しい画像
またはグラフィック表示の機能を伴うことができる。さ
らに他のノードはファイルサーバとして使われ、大容量
のディスクを備えたＩＢＭやＤＥＣのミニコンピュー
タ、あるいはただのパーソナルコンピュータであること
もできる。これらの各ノードで生成されるデータトラフ
ィックは相当異なっており、それらは、各ノードで実行
されているアプリケーションプログラム、ノードで利用
できるリソースの質と量、ノードリソースへの現在の需
要、及び、データを要求してくる他のノードのレスポン
スタイムの関数である。

【００３２】先に述べた通り、あらゆるシミュレーショ
ンの正確さは、明らかにネットワーク構成要素について
のモデルの正確さのみによるのでなく、それらのネット
ワークモデルを実行する離散型イベントの発生のモデル
にもよる。

【００３３】特定の物理的なネットワークのノードで生
成されるトラフィックのより正確なモデルを作るため
に、トラフィックアナライザーを使ったネットワークの
実際のデータトラフィックの記録することが行われてき
た。特定ネットワークのトラフィックの特徴の統計的モ
デルを作るためには長期のサンプルが使われ、次にこれ
らのモデルはネットワークモデルを駆動するためにシュ
ミレーターで使用される。短期のサンプルもトレースを
作るために利用されてきた。このトレースは物理的ネッ
トワークで記録された正確なトラフィックのパターンを
再生するために使われる。これらのトレースはトラフィ
ックジェネレーターにより読み込まれ、それにより反復
性の出力が生成され、記録されたトラフィックパターン
を模倣するシミュレーションでネットワークモデルを駆
動する。

【００３４】

【発明が解決しようとする課題】これらの手法に、まだ
多くの正確さへの課題がある。まず、任意の時間のネッ
トワークでのデータトラフィックの断片は、他の時間の
ネットワークのデータトラフィックの断片とは大きく異
なるだろう。ゆえに、評価されるトラフィックの小さな
反復性のセグメントを生成することは、非常に不正確で
ある。さらに、長期のわたって集められた統計データは
相対的により正確ではあるが、ネットワークの使用率の
山や谷が失われるので、一時的な問題を生じかねないよ
うな使用の組合せを突き止めることができないだろう。

【００３５】最大の問題は、上記の手法で開発されたト
ラフィックモデルは、サンプルされた特定の物理的なネ
ットワーク構成要素についてだけものである。ネットワ
ークの負荷の増減により、あるノードのリソースの変
更、または既存のノードへの新しいアプリケーションの
インストールにより、ネットワークの各ノードで生成さ
れるトラフィックの特徴は変化するだろう。従って、既
存の１０のノードを２０のノードに増やしたときにネッ
トワークパフォーマンスがどうなるかを確定することが
シミュレーションを行う理由であれば、１０個のノード
を有する実際のネットワークのからのサンプルを用いた
トラフィックのエミュレーションはもはや有効ではな
い。

【００３６】各追加のノードとその結果のパフォーマン
スへの影響の関係の推定を試みることもできるが、これ
は不正確である。けれども、なによりもこれこそがシミ
ュレーションを使って正確に求めようとしている、まさ
にそのものなのである。従って、シミュレーション製品
を使う最大の魅力と利益、すなわち、実際にシステムを
構成することなくネットワークの負荷、リソース、及び
アプリケーションが変化するときのパフォーマンスを評
価及び予測したいという希望は、既存のネットワークに
基づいてこれらの変化との相関関係からモデルの特徴を
変化させるという現行のトラフィックモデルの無力さに
より、実現できないのである。

【００３７】本発明は、上記課題に鑑みてなされたもの
であり、その目的とするところは、既存のネットワーク
のサンプルトラフィックに基づいてトラフィックをモデ
ル化するが、ノードやノードのプロセッシングリソー
ス、及び各ノードで実行されるアプリケーションの数
が、変更されたときに、トラフィックが固定されないよ
うなモデル化の方法を提供することにある。

【００３８】

【課題を解決するための手段】本発明のネットワークの
各ノードにより生成されるトラフィックの特徴を記述す
る方法は、各ノードがクライアントまたはサーバノード
であり、該クライアントノードがリクエストパケットを
該サーバノードに送り、該サーバノードがレスポンスパ
ケットを該クライアントノードに送り、該各ノードが、
少なくとも１つのアプリケーションを実行していて、該
ネットワークの２つ以上の該ノードが、少なくとも１つ
の同じアプリケーションを有しているか、または、いず
れの該ノードも同じアプリケーションを有していない、
方法であって、該ネットワークのピークアクティビティ
ーがいつ起きるかを決定するステップと、該各ノードに
ついて、該ノードが該ピークアクティビティーの間アク
ティブであるかを決定し、該各アクティブなノードで該
少なくとも１つのアプリケーションが現在実行されてい
るかを決定するステップと、該各アクティブなクライア
ントノードについて、該アクティブなクライアントノー
ドがリクエストパケットを送るのに要する時間を決定
し、該リクエストパケットのサイズを決定するステップ
と、該各アクティブなサーバノードについて、該アクテ
ィブなサーバノードがレスポンスパケットを送るのに要
する時間を決定し、該レスポンスパケットのサイズを決
定するステップと、を包含することによって、上記目的
が達成される。

【００３９】上記方法において、前記アクティブなクラ
イアントノードがリクエストパケットを送るのに要する
前記時間、及び該リクエストパケットのサイズを、前記
ネットワークのシミュレーション中で該アクティブなク
ライアントノードをシミュレートするために用いること
もできる。

【００４０】上記の方法において、前記アクティブなサ
ーバノードがレスポンスパケットを送るために要する時
間、及び該レスポンスパケットのサイズを、前記ネット
ワークのシミュレーション中で該アクティブなサーバノ
ードをシミュレートするために用いることもできる。

【００４１】上記の方法において、前記ネットワークの
２つ以上のノードが、少なくとも１つの同じアプリケー
ションを有しており、前記アクティブなクライアントノ
ードがリクエストパケットを送るのに要する時間、及び
該リクエストパケットのサイズを決定する前記ステップ
が、該同じアプリケーションを備えたすべての該２つ以
上のノードに対して行われることもできる。

【００４２】上記の方法において、前記ネットワークの
２つ以上の前記ノードが少なくとも１つの同じアプリケ
ーションを有しており、前記アクティブなサーバノード
がレスポンスパケットを送るのに要する時間、及び該レ
スポンスパケットのサイズとを決定する前記ステップ
が、該同じアプリケーションを備えたすべての該２つ以
上のノードに対して１度行われることもできる。

【００４３】上記の方法において、さらに、前記クライ
アントノードが前記少なくとも１つのアプリケーション
を実行している間に、該アクティブなクライアントノー
ド及び前記サーバノードとの間の相互作用を表示するト
レースを記録するステップを包含することもできる。

【００４４】上記の方法において、前記アクティブなク
ライアントノードがリクエストパケットを送るのに要す
る時間を決定し、かつ、該リクエストパケットのサイズ
を決定するステップが、さらに前記トレースから該時間
及び該サイズを抽出するステップを包含することもでき
る。

【００４５】上記の方法において、前記サーバノードが
レスポンスパケットを送るのに要する時間を決定し、か
つ、該レスポンスパケットのサイズを決定するステップ
が、さらに前記トレースから該時間及び該サイズを抽出
するステップを包含することもできる。

【００４６】

【作用】本発明の手法は、実際のシステムでサンプルさ
れたトラフィックに基づくが、ノードやノードのプロセ
ッシングリソース、及び各ノードで実行されるアプリケ
ーションの数の変化に相関して特徴を変化させるトラフ
ィックモデルを提供し、ネットワークパフォーマンスの
より正確な予想を行うものである。

【００４７】ネットワークで生成され、ネットワークに
接続されているノードからネットワークのどこか他のノ
ードへとネットワーク中を転送されるリクエストメッセ
ージを典型的に含むモードで作動するネットワーク及び
分散処理システムを、本発明の手法により捕らえること
ができる。そして受信するノードはリクエストを処理し
てレスポンスを返し、それはネットワーク中を転送され
てリクエストをしたノードに帰って来る。リクエストす
るノードの次のリクエストは、レスポンスを受信するこ
と、及びそのレスポンスの性質に依存しうることは、非
常によく起きる。もちろん、リクエストまたはリクエス
トへのレスポンスという形になっていないメッセージも
有り得る。それらは受信されれば他のノードに動作を起
こすこともあるし、あるいは他のメッセージとはまった
く相関関係がないこともある。

【００４８】今日のほとんどのネットワークは、一連の
クライアントノード及び比較的少ない数のサーバノード
からなる。クライアントノードはローカルにアプリケー
ションプログラムを実行し、使用するデータのために大
きなデータベースにアクセスしなければならない。サー
バノードはクライアントがアクセスするデータベースを
保守し、クライアントからのリクエストに応じてこのデ
ータベースの部分的なコピーを与えるように設計されて
いる。

【００４９】クライアントノードがリクエストを作るの
に必要な時間は様々な要因に依存する。例えば、実行さ
れているアプリケーションの種類や、ローカルノードの
プロセッシングリソースへの競合や、それらのリソース
の速度や、もし現在のリクエストが前回のリクエストへ
のレスポンスに相関するものならばそのレスポンスを受
け取る時間や、さらにオペレーターが考えたりタイプし
たりする時間にも依存するのである。

【００５０】同様に、リクエストが受信されてからサー
バノードがレスポンスを作る時間は、サーバのリソース
への需要や競合（それは、しばしば、サーバが供しなけ
ればならないクライアントノードの数の直接的な関数で
ある）、クライアントノードが実行しているアプリケー
ションの種類（それは、要求されるレスポンスのサイ
ズ、複雑さ、及び頻度を決める。）、並びに、サーバの
使えるリソースの速度及び能力に依存するであろう。

【００５１】もちろん、ネットワークトポロジー及びプ
ロトコルはノード間の転送時間に関してネットワークに
制限を課す、リクエスト及びレスポンスを構成するパケ
ットのサイズもまたリクエスト及びレスポンス時間に影
響を与えるであろう。システムのこの側面はネットワー
クトポロジー（つまり、ノード及びリンクの数）、ネッ
トワークデータ構造、ネットワークリソース（つまり、
バッファ、トランク、バス、ＣＰＵ及びスイッチ）、及
びネットワークプロトコル機能（つまり、これはプロト
コル階層でのパケットのフロー及びリソースの割当を管
理する）、とについてのモデルに反映されるであろう。

【００５２】ゆえに、各ノードによって実行されるアプ
リケーションと、ノードが利用できるリソース及びその
リソースへの競合と、リクエストの開始及びそのような
リクエストを出すのに必要な処理時間とを支配する応答
時間、の関数として変化する各クライアントノードで生
成されるトラフィックの特徴をモデル化することが、本
発明の目的である。

【００５３】本発明の手法は、図９に示されるクライア
ント／サーバパラダイムに従ってクライアントノードで
生成されるトラフィックをモデル化することにより、こ
の目的を達成する。このモデルは、図９に示される４つ
の基本的なパラメータを用いて記述されるが、それら
は、クライアントウエイティングタイム、クライアント
リクエストサイズ、サーバレスポンスタイム、及びサー
バレスポンスサイズである。

【００５４】図９に示されているように、クライアント
ウエイティングタイムは、最後のサーバノードレスポン
スパケットの到着と、次のクライアントリクエストパケ
ットの転送との間の時間である。この時間は、オペレー
ターの思考時間、タイプする時間、及びクライアントノ
ードのローカルプロセッサがサーバレスポンスを評価し
て（もしレスポンスと次のリクエストが相関するのなら
ば）転送するための次のクライアントリクエストを処理
する時間、とを表している。ローカルプロセッシングタ
イムは、そこにあるリソースの速さ及びそれへの競合と
の関数であるだろう。クライアントウエイティングタイ
ムもまた、クライアントノードで実行されているアプリ
ケーション、及び、そのアプリケーションのリクエスト
に関係する特定の操作との関数である。

【００５５】クライアントリクエストサイズはリクエス
トパケットのサイズであり、また、アプリケーション及
び、実行されている特定の操作との関数でもある。サー
バレスポンスタイムは、クライアントリクエストパケッ
トの目的地ノードへの到着時間と、サーバノードがクラ
イアントリクエストに応答してパケットを転送する時間
の間の時間である。サーバレスポンスタイムは、リソー
ス競合、アプリケーション及び前述の操作状況との関数
である。サーバレスポンスサイズはレスポンスパケット
サイズであり、また、アプリケーション及び操作との関
数である。

【００５６】本発明の方法が、分散処理システムのトラ
ンザクショントラフィックをモデル化することにも利用
できることは、当業者には自明であろう。分散処理シス
テム同士は、通常多数のローカルメモリを持つローカル
プロセッサがローカルプログラムを実行し、小数の大き
なメモリソースから取り込んだデータを処理しているこ
とにおいて類似している。プロセッサは、ローカルで持
っていないデータが必要になり、共有バスを介して、共
有メモリソースからのデータをリクエストするトランザ
クションを開始するまで、プログラムを実行する。そし
て共有メモリはローカルプロセッサへのレスポンスを出
す。データの一貫性と同様、バスへのアクセス並びに、
トランザクションのサイズ及び形式は、バスプロトコル
によって決定され、リクエスト及びレスポンスタイムに
影響を与える。リクエスト及びレスポンスの速さもま
た、ローカルプロセッサで実行されているアプリケーシ
ョンの種類同様、関連するプロセッシングリソースの速
さ及びそれへの競合の影響を受ける。

【００５７】本発明は、ネットワークに他の負荷がない
状態でクライアントノードが特定のアプリケーションま
たは複数のアプリケーションを実行している場合の、ク
ライアントノードとサーバノード間の既知または評価さ
れたリクエスト／レスポンス相互作用に基づいて、通信
ネットワークまたは分散処理システムのノードにより生
成されるトラフィックをモデル化するための方法であ
る。この相互作用のシミュレーションモデルは、クライ
アント／サーバパラダイムからなる４つのパラメータの
関数として作られる。このモデルを用いて、ネットワー
クに他のトラフィックがない状態でクライアントとサー
バノードの間のネットワークを流れるデータトラフィッ
クを模倣する離散型イベントを生成できる。ネットワー
クを構成するリソースをモデル化することができ、モデ
ルにより生成されるトラフィックでモデルをシミュレー
トすることでネットワークのレスポンスを予測すること
ができる。

【００５８】クライアントノードの数を増やすことへの
ネットワークの応答は、シミュレーションのためにモデ
ル化されたトラフィックを生成するソースの数を増やす
ことによって予測することができる。ネットワークリソ
ースを奪い合うトラフィックの量の変化の関数として、
シミュレーション中にネットワークモデルにより予測さ
れる全体のレスポンスが変化するとき、ネットワークレ
スポンスの変化はトラフィックソースにフィードバック
され、それに応答してトラフィックソースは生成してい
るトラフィックの特徴を変化させる、というのがトラフ
ィックモデルの特徴である。従って、アプリケーション
を実行しているネットワーク上のノードとサーバノード
の間のトラフィックのモデルは、ネットワークに他の負
荷がない状態について開発されるだろう、そしてモデル
は様々な負荷状態での適切なトラフィックを生成するよ
うに生成するトラフィックを自動的に変化させるだろ
う。負荷の変化は、トラフィックの増加となり得るが、
またトラフィック負荷を処理するのに利用されるネット
ワークリソースの量または質の変化にもなり得る。

【００５９】物理的ネットワークのクライアントノード
数が増えるほど、それらのリクエストに対するネットワ
ークの全体としての応答が遅くなるため、クライアント
ノードで発生するパケット間の時間が長くなり始めるの
で、本発明の方法に従って作られたトラフィックモデル
はより正確なネットワークシミュレーション結果を作
る。

【００６０】クライアント／サーバパラダイムによりモ
デル化されたノードトラフィックは、ネットワークレス
ポンスが遅くなるにつれてのリクエストパケットインタ
アライバルの増加を予測するだけではなく、クライアン
ト及びサーバの両方のリソースへの競合の説明もする。
つまり、クライアントノードリクエストの数が増えるに
つれて、サーバノードのリソースは最終的に限界に達
し、リクエストは待ち行列に加えられなくてはならな
い。クライアントノードでのリソースへの需要は、その
ノードが実行しているアプリケーションの関数として変
化し得る。さらに、複数のアプリケーションを実行して
いるクライアントノードでは、サーバノードによく似た
種類の、リソースへの競合が起きるだろう。本発明によ
りにより作られたトラフィックモデルによって、これら
すべての変数は説明され、それらの影響は予測される。

【００６１】もちろん、異なるアプリケーションを実行
している複数のノードを持つネットワークを記述するシ
ミュレーションは、異なるアプリケーションを実行して
いるそれぞれのノード構成を単純にモデル化するか、ま
たは、アプリケーションを上記のような方法で単純にモ
デル化することによって、実行され得、シミュレートさ
れるネットワーク上の各異なるノードのシミュレーショ
ンにおいてトラフィックソースモデルを供給し得る。

【００６２】従って、本発明の方法は、ノード数、各ノ
ードのプロセッシングリソースの質または量、ネットワ
ークリソースの質または量、及び／または、各ノードで
実行されるアプリケーション、とが変化するときのネッ
トワークの動作及びパフォーマンスのシミュレーション
の精度を大幅に改善する。この方法は現在利用できるネ
ットワークシミュレーション製品に完全に対応すること
ができる。

【００６３】各クライアントノードで生成されるトラフ
ィックは、クライアント／サーバパラダイムによってモ
デル化される。すなわちトラフィックは、リクエスト及
びそれに続くレスポンスとしてモデル化される。このモ
デルは４つの基本的なパラメータを用いて記述される。
それらは、クライアントウエイティングタイム、クライ
アントリクエストサイズ、サーバレスポンスタイム、及
びサーバレスポンスサイズである。

【００６４】クライアント／サーバパラダイムは、ノー
ドで実行されるアプリケーション及びそれを実行するた
めに使われるリソースに従って、それぞれのネットワー
ククライアントノードとサーバノード間とので生成され
るトラフィックカンバセーションのモデル化に応用され
る。もし２つ以上のクライアントが同一のリソースを使
って同じアプリケーションを実行するならば、１つだけ
モデルを作り、それを同一のクライアントノードの数に
従ってシミュレーションのために複製すればよい。

【００６５】モデルは、特定のアプリケーションに対す
るクライアント／サーバ相互作用の既知の特徴によりモ
デルを作ることができる。また、初めに、ネットワーク
アナライザーまたはネットワークマネージメントシステ
ムを実際のネットワークに適用しても、モデルを作るこ
とができる。クライアントノードで生成されるネットワ
ークトラフィックのトレースは、ネットワークの同じセ
グメントにサーバノードがある状況で、影響を知りたい
アプリケーションを実行しながら測定する。他のノード
がサーバにアクセスしていてはならず、ネットワークに
は最小限のバックグランドアクティビティしかあっては
ならない。

【００６６】その結果得られたトレースを調べて、ネッ
トワークでのクライアントとサーバとの間のリクエスト
／レスポンストラフィックのパターンが決定されなくて
はならない。クライアントウエイティングタイム、クラ
イアントリクエストサイズ、サーバレスポンスタイム、
及びサーバレスポンスサイズを示す情報は、モデル化さ
れるべきトラフィックパターンの各リクエスト−レスポ
ンスステップのトレースから抽出されるべきである。

【００６７】最後に、４つのパラメータはスクリプトフ
ォーマットに組み込まれる。このスクリプトフォーマッ
トは市販のトラフィックジェネレーターによって、シュ
ミレーターのネットワークモデルを駆動する離散型イベ
ントに変換され得る。本発明の方法により作られるスク
リプトは、離れたノードからのレスポンスパケットの受
信に依存する、またはそれに相関するクライアントリク
エストパケットをトラフィックジェネレーターが生成す
るのを遅れさせる。従って、ネットワーク負荷及びパフ
ォーマンスの関数としてレスポンスタイムが増加するに
つれて、それに応じてトラフィックソースで生成される
トラフィックは調節される。

【００６８】本発明に従って作られるスクリプトは、サ
ーバレスポンスタイムパラメータによってサーバリソー
スの速度及びサーバリソースへの競合も考慮に入れ、ク
ライアントウエイティングタイムパラメータの仕様によ
ってクライアントノードリソースの速度及びクライアン
トリソースへの需要を考慮に入れるだろう。

【００６９】従って本発明は、クライアントノードで実
行されている特定のアプリケーション、各ノードにロー
カルなリソースへの競合を生じさせる需要、そのローカ
ルリソースの作動できる速さ、オペレーターが以前のレ
スポンスに応答するのに必要な時間、及びサーバノード
リソースへの需要、とに関する様々な変動が導入された
ときに自動的にモデルを調節する、クライアントノード
から見たネットワークトラフィックのモデルを提供す
る。

【００７０】これらのモデルは、ネットワーク自体の特
徴に基づいてのみでなく、現在各ノードで実行されてい
る特定のアプリケーション、それらを実行するために使
われるリソース、及び、リソースへの需要、との関数と
してノードの数あるいはノードで実行されているアプリ
ケーションの数が変化するに従ってネットワークのノー
ド間の「カンバセーション」の特徴を変化させる。従っ
て、本発明は、ノード数が増減するとき、または、コン
ピューティングリソースを付加または交換するとき、あ
るいは、追加の、または異なったアプリケーションを導
入するときの所定のネットワークのパフォーマンスへの
影響をシミュレートしようとするネットワーク設計者ま
たは管理者に、より正確なイメージを提供する。

【００７１】

【実施例】前述のように、特定の１つまたは複数のアプ
リケーションを実行いているときに各クライアントノー
ドで生成されるトラフィックを、ネットワーク上のサー
バノードとの一連のリクエスト／レスポンス相互作用と
してモデル化することが本発明の目的である。このモデ
ル化過程は、他のクライアントノードがサーバとインタ
ラクトしていないときに行われなければならない。この
モデル化過程はまた、異なるアプリケーションを実行す
る、あるいは非常に異なるリソース構成を有する、各ノ
ードについて行われなければならない。クライアントウ
エイティングタイム、クライアントリクエストサイズ、
サーバレスポンスタイム、及びサーバレスポンスサイズ
が、ネットワークノードからなる特定のリソース構成で
実行される特定のアプリケーションあるいはアプリケー
ションのセットの、一連の進行中のクライアント／サー
バ相互作用に対して決められると、これらのクライアン
ト／サーバパラダイムパラメータはスクリプトに変換す
ることができ、これを市販のトラフィックジェネレータ
ーで変換して、それに従ってトラフィックを生成するこ
とができる。そのようなトラフィックジェネレーターの
一例は、ComdiscoSystems, Inc.から入手できるPlanNet
Application Traffic Generator Module(ATG)である。
ATG Module及び一般に入手可能なマニュアルは本明細書
に援用されている。このトラフィックジェネレーターか
らの離散型イベントは、ネットワークモデルのシミュレ
ーションを実行するのに使用することができる。

【００７２】本発明のクライアント／サーバパラダイム
に従って生成されたトラフィックは、従来のトラフィッ
クモデルによって生成されたトラフィックよりもより現
実的な様子で振舞うであろう。サーバからのレスポンス
に依存するのクライアントノードリクエストについて
は、本発明によりモデル化されたトラフィックソースが
リクエストパケットを生成する前に、満たされねばなら
ない条件が２つある。第１に、レスポンスパケットはト
ラフィックソースで受けとられなければならない。そし
て第２に、クライアントウエイティングタイムが経過し
なければならない。もし本発明に従ってモデル化された
あるノードと同一の１０個のノードをネットワークモデ
ルに加えて、この追加によるネットワークパフォーマン
スへの影響をシミュレートするならば、増加したトラフ
ィックによりサーバからクライアントへの全体としての
レスポンスタイムはネットワークのモデルに従って低下
するだろう。クライアントリクエストへの全体としての
システムレスポンスは、クライアントリクエスト及びサ
ーバリクエスト転送タイムを含み、これらは追加の１０
個のトラフィックソースからのトラフィックがネットワ
ークリソースを奪い合うので増加する。さらに、サーバ
ノードリソースへの需要が増加するために全体としての
システムレスポンスタイムが長くなる。つまり、クライ
アントリクエストの増加により、サーバリソースの容量
の限界を越えると、これらのリクエストが待ち行列に入
れられ、そしてサーバはリクエストパケットを実際に受
け取りそしてサーバレスポンスタイムが過ぎるまでは、
レスポンスを返せない。この全体としてのシステムレス
ポンスの増加は、シミュレーション中にネットワークモ
デルによって予測される。次のリクエストパケットが相
関するレスポンスパケットがトラフィックソースによっ
て受けとられるまでは（そしてクライアントウエイティ
ングタイムが過ぎるまでは）、トラフィックソースは次
のリクエストパケットを出せないので、ネットワークパ
フォーマンスへの増加したトラフィックの影響は実質的
にトラフィックソースにフィードバックされる。続いて
トラフィックソースはクライアントノードパケットを生
成する間隔を長くするだろう。このトラフィックソース
の振舞いは、もし物理的ネットワークに１０個のノード
を加えると何が起きるかをモデル化している。

【００７３】特定のプログラムの実行中に起こり得るす
べてのクライアント／サーバ相互作用を本発明に従って
モデル化することは可能ではあるが、ひどく時間がかか
るし、不必要である。ネットワークパフォーマンスを決
定するときに第１の関心事となるのは、需要がピークに
あるときのネットワークの動作である。従って、現実問
題としては、ネットワークで需要がピークにあるとき
に、ノードでのトラフィックをモデル化するのが最もよ
い。さらに、最もデータ量の激しいクライアント／サー
バ相互作用のみをモデル化し、シミュレーションの入力
値として使用する必要がある。

【００７４】市販のネットワークアナライザーまたはネ
ットワークマネージャーは、ネットワーク上にいつアク
ティビティーのピークが起きているのか、そのときどの
ネットワークノードがアクティブなのか、及び現在何の
アプリケーションがそのアクティブなノードで実行され
ているのか、とを決定することができる。そのような市
販のネットワークアナライザーに、Network General Co
rporation, 4200 Bohannon Drive, Menlo Park, Califo
rnia 94025の販売している一連のSniffer製品がある。
一般に入手できるSniffer製品及びすべての説明書は本
明細書に援用されている。図１０〜図３５にに関して、
本発明の好ましい実施態様の詳細な説明を述べる。図１
０は、シミュレートするネットワークのノードのトラフ
ィックをモデル化するための手順１０を示している。第
１のブロック１２で、シミュレートするネットワークシ
ステム上のアクティビティーのピークの回数を決定しな
ければならない。ピークの間作動しているアクティブな
ノード（またはステーション）の数を判別し、そしてそ
れはブロック１４に示すように、ピークの間にノードが
実行しているアプリケーションと相関付けしなければな
らない。

【００７５】もし、シミュレートするネットワークが物
理的に存在しているのならば、ネットワークアナライザ
ー（つまりNetwork General Sniffer）、またはネット
ワークマネージメントシステムを用いて、上記の情報を
得ることは簡単にできる。もし、ネットワークが仮想的
なものならば、最悪の場合は、すべてのノードあるいは
ステーションがアクティブで、それらが最もトラフィッ
クの激しいアプリケーションを同時に実行している場合
と仮定できる。

【００７６】そして、それぞれの異なるアプリケーショ
ンをクライアント／サーバパラダイムに従ってモデル化
し、スクリプトの形式で表さなければならない。判断１
６に示すように、スクリプトが作られるか、または、も
しアプリケーションがノードで実行され、そのアプリケ
ーションを実行するのに使われるリソースがよくある組
み合せを有しているならば、そのようなノードで生成さ
れるトラフィックをモデル化しているスクリプトは市販
されるであろう。もしスクリプトを作らなければならな
いなら、手順１８に従ってネットワーク上のノードを分
析することができる。

【００７７】図１１で示す手順１８は以下のステップを
含む。ネットワークアナライザー、クライアントステー
ション、及びサーバステーションとを、間にブリッジ、
ルータ、またはゲートウエイをはさまずに同じＬＡＮセ
グメントにセットする（ブロック３０及び３２）。もし
モデル化してているアプリケーションを実行中のクライ
アントステーションのいくつかの、あるいはすべてが、
普段間に介するネットワークノードを通してサーバにア
クセスしているとしても、これを行わなくてはならな
い。間に介するネットワークリピータ、またはハブの存
在は、それらの影響はネットワークモデルで考慮される
ので無視することができる。このことは、すべての場合
で可能ではないことに注意が必要である。一例を挙げる
と、もしアップルトーク上にあるアップルのマッキント
ッシュのステーションが、１０−Ｂａｓｅ−Ｔ上にある
ファイルサーバに、ゲートウエイノードを用いてアクセ
スしているときである。この場合、ワークステーション
はゲートウエイをはさんで普通の状態で動作していなけ
ればならず、ゲートウエイの最小の潜伏期間（ネットワ
ークパケットを転送するための延滞）は、もしわかって
いるならば、トレースパケットインターバルタイムから
それを差し引かなければならない（ブロック４２）。ゲ
ートウエイの影響はネットワークモデルによりモデル化
されるので、ネットワークの影響はトラフィックモデル
から差し引かれる。

【００７８】サーバには他に何もアクティビティーが存
在せず、ＬＡＮセグメントの他のアクティビティーのレ
ベルは最小でなければならない。アナライザートレース
から評価されるクライアント／サーバパラダイムパラメ
ータが、アプリケーションを実行しているクライアント
及びサーバのものであり、他のネットワーク構成要素及
び他の無関係なネットワークアクティビティーのもので
はないことを確実にしておくことは重要である。

【００７９】ネットワークアナライザーは、トレースキ
ャプチャーモードにセットしなければならない（ブロッ
ク３２）。もし、各ネットワークパケットについてネッ
トワークトレースバッファに保持されている情報の量を
最小にするフレームスライシングの特徴をアナライザー
が備えていれば、これはセーブされるであろうトレース
の長さを最大にし、アナライザーのトレースパフォーマ
ンスを最大にするために使用できるだろう。もしネット
ワークアナライザーがパケット復号を行うなら、パケッ
トのプロトコル復号を保存するために十分なパケット内
容を保持することを確実にしなければならない。

【００８０】分析したいアプリケーションプログラムま
たは機能を実行する（ブロック３６）。これには、アプ
リケーションプログラムを読み込み、ドキュメントファ
イルを読み込みまたはセーブし、あるネットワークステ
ーションから他へファイルをコピーし、ネットワークデ
ータベースサーバに検索または更新リクエストを送り、
通信メッセージを非同期通信ゲートウエイに送ることな
どを含む。ピーク時に最大のネットワークトラフィック
を生成するアプリケーションの動作をモデル化しなけれ
ばならない。もし、あるアプリケーションの動作が最小
のネットワークアクティビティーを生成するならば、そ
れをモデル化する必要はない。もし、この種の動作がピ
ークネットワーク時のシステムアクティビティーの重要
な部分であれば、シミュレーションにおいて、各セグメ
ントのトラフィックソースにより表されるノード数を適
当にスケールすることで、その存在を処理することがで
きる。

【００８１】ネットワークアクティビティーが完了した
後、またはアナライザートレースバッファがいっぱいに
なった後、ネットワークアナライザーキャプチャーを停
止させ、そしてトレースバッファをファイルにセーブし
なければならない（ブロック３６）。その後トレースは
アナラーザーディスプレイスクリーンで、またはプリン
トして検査できる。ほとんどのネットワークアナライザ
ーで、トレースバッファはファーストインファーストア
ウト（ＦＩＦＯ）待行列として働くが、これはトレース
バッファがいっぱいになると、ネットワークパケットは
セーブされ、そしてトレースの最初のパケットが破棄さ
れるということである。もし、アプリケーションの動作
が始まった直後のトレースの始めの部分を保存しておく
ことが重要ならば、バッファがいっぱいになる直前にト
レースキャプチャーを停止しなければならない。

【００８２】ネットワークアナライザーディスプレイオ
プションをセットし、パケットインターバルタイム、パ
ケットサイズ、ソース及び目的地ステーション（つま
り、ノード）アドレス、並びに、もし利用可能ならプロ
トコル復号情報とを、表示するべきである（ブロック３
４）。検査を容易にするために、もしネットワークアナ
ライザーがネットワークアドレスに所定の記憶用の（mn
emonic）名前を使うことを許すならば、トレースを解り
やすくするために、クライアントステーション及びサー
バステーションのＭＡＣレベルのアドレスに新しい名前
を定義できるだろう。もし、他のネットワークステーシ
ョンから、あるいは他のネットワークステーションへ移
動するパケットがトレースに現れたら、もし利用可能な
らば、ディスプレイフィルタ操作を用いてそれらを取り
除くべきである。

【００８３】ブロック３８に示すように、クライアント
とサーバステーションの間のトラフィックのパターンを
調べて、トレースを検査しなければならない。通常、ネ
ットワークトポロジーが１つのパケットで転送できるよ
り大きなメッセージが送られない限り、１つのクライア
ントリクエストパケットに１つのサーバレスポンスパケ
ットが続く。インプリメンテーションパケットサイズ
は、１０−Ｂａｓｅ−Ｔ、すなわちイーサネットで１０
００から１５００バイト、トークンリングで４０００₊
バイト、及びＦＤＤＩで約４０００バイトであろう。も
しそれよりも大きなメッセージが送られるとき、例えば
１０−Ｂａｓｅ−Ｔネットワーク上のＳｕｎのＮＦＳサ
ーバから読まれた８１９２バイトのファイルブロックな
らば、ネットワークトランスポート階層は、これはこの
場合ＵＤＰだが、パケットを５つの１５１４バイトパケ
ット、及び６つの９３４バイトパケットに分割するだろ
う。ここでの目的のため、これらの６つのパケットは１
つにまとめられ、第１のパケットのタイミングパラメー
タと一致させなければならない。連続するパケットのタ
イミングはトポロジーの転送レートにより決められる
が、これはネットワークモデルにより考慮される。

【００８４】トレース中の重要な情報は、クライアント
が前回のレスポンスの後でリクエストパケットを送るの
に要する時間（リクエストパケットウエイティングタイ
ム）、リクエストパケットのサイズ（リクエストパケッ
トサイズ）、サーバがレスポンスを送るのに要する時間
（レスポンスパケットウエイティングタイム）、及びサ
ーバレスポンスパケットのサイズ（レスポンスパケット
サイズ）である。

【００８５】望ましくは、最もトラフィックの激しいク
ライアント／サーバ − リクエスト／レスポンス相互作
用のうちの、１つ以上の典型的なものを選んでモデル化
すべきである（ブロック３８）。正確な特徴はモデル化
されている動作の種類に依存して大きく異なるだろう。
典型的なネットワークトレースの数百から数千のパケッ
ト中で、スクリプトで定義される必要があるのはたった
数個であり、それらはシミュレーション中に何度も繰り
返し得るものである。このように、トレース中にもっと
も頻繁に繰り返される動作が、モデル化に最も適当であ
る。それらの動作を突き止めるために、送受信されてい
るパケットのサイズ、またはパケットのタイミングの目
だったパターンを判別すべきである。先に述べたよう
に、本発明に従って、実際のリクエスト／レスポンス相
互作用のすべてをモデル化することができる。しかし、
このレベルでの正確さは、ネットワークシミュレーショ
ンに望まれる正確さのレベルを達成するためのトラフィ
ックモデルには必要ない。

【００８６】クライアント／サーバアクティビティーの
典型的なパターンを識別したら、ブロック４８に示すよ
うに、以下の数値を各クライアント／サーバ − リクエ
スト／レスポンス相互作用から抽出しなければならな
い。

【００８７】リクエストパケットウエイティングタイム
（秒） リクエストパケットサイズ（バイト） レスポンスパケットウエイティングタイム（秒） レスポンスパケットサイズ（バイト） パラダイムの値からスクリプトステップを作るために、
もう一度パケットサイズを修正する必要がある。ネット
ワークアナライザートレースから得られたパケットサイ
ズ値は、データリンク階層オーバーヘッド、及びネット
ワーク階層オーバーヘッドを含み得る。これらのオーバ
ーヘッドビットは、先の述べたように、実際のメッセー
ジデータをカプセル化する。１０−Ｂａｓｅ−Ｔ及びＩ
Ｐについてはオーバーヘッドは計３４バイトであり、ク
ライアントリクエストサイズ及びサーバレスポンスサイ
ズを作るために、この３４バイトをクライアントリクエ
ストパケットサイズ及びサーバレスポンスパケットサイ
ズから差し引かなければならない。これらのオーバーヘ
ッドビットはネットワークのモデル自身によりすでに考
慮に入れられており、従って、もしトラフィックモデル
から除かれないならば、不正確な結果を作り出すだろ
う。このステップは図１２のブロック５０で表されてい
る。

【００８８】ある状況においては、リクエストするクラ
イアントノード、あるいはレスポンスするサーバノード
により転送されているメッセージが、ネットワークプロ
トコルによるパケットのサイズを越える場合があるだろ
う。この場合は、ネットワークプロトコルが、パケット
サイズの最大制限に合うようにパケットをサブメッセー
ジに分割するだろう。アナライザーによって記録される
トレースは、そのようなメッセージを一連のサブメッセ
ージとして記録するだろう。

【００８９】このような性質のリクエスト／レスポンス
相互作用をモデル化するために、サブメッセージを再結
合し（各送信からのモデル化したオーバーヘッドを引い
た後に）、ネットワークプロトコルのアプリケーション
階層で生成されたようなメッセージを作り直さなければ
ならない。この過程は、ブロック５２、５８、及び６２
に反映されている。さらに、再結合されたリクエストま
たはレスポンスのリクエストまたはレスポンスパケット
ウエイティングタイムは、再結合されたパケットを構成
するうちの最初のサブメッセージパケットのリクエスト
またはレスポンスパケットウエイティングタイムでなけ
ればならない。このネットワークモデルは、メッセージ
を分割して、それをサブメッセージパケットとして転送
するのに必要な新たなオーバーヘッドを含むネットワー
クのプロトコルをシミュレートするだろう。この過程
は、図１２のブロック６０及び６４で示してある。

【００９０】上記のようにして抽出された数値は、ブロ
ック５４に従って、以下のようにクライアント／サーバ
パラダイムのパラメータに等式化される。

【００９１】リクエストパケットサイズ＝クライアント
リクエストサイズ リクエストパケットウエイティングタイム＝クライアン
トウエイティングタイム レスポンスパケットサイズ＝サーバレスポンスサイズ レスポンスウエイティングタイム＝サーバレスポンスタ
イム 一度クライアント／サーバパラダイムに従ってモデル化
されれば、その後リクエスト／レスポンス相互作用はス
クリプトに変換可能で、それを用いて、モデル化された
リクエスト／レスポンス相互作用を模倣する離散型シミ
ュレーションイベントをComdisco ATGによって生成する
ことができる。モデル化された相互作用は、図１４のス
クリプト作成過程２２で示すようにしてスクリプトに変
換することができる。

【００９２】以下のようにして、クライアント／サーバ
パラダイムパラメータをＡＴＧスクリプトパラメータに
変換する。

【００９３】クライアントウエイティングタイム＝＞シ
ンキングタイム クライアントリクエストサイズ×８＝＞出ていくメッセ
ージ長 サーバレスポンスサイズ×８＝＞入って来るメッセージ
長 サーバレスポンスタイム×１０⁷＝＞リモートＣＰＵア
クセスタイム ネットワークモデルはスループットをビット／時間で表
すので、２つのサイズの値に８を掛けてバイトからビッ
トに変換する（ブロック６８）。サーバレスポンスタイ
ムに１０ＭＩＰＳ掛けてＣＰＵインストラクションに変
換する（もちろん、ネットワークで実際に使われている
サーバに依存して、他のＣＰＵアクセスレートが指定さ
れるだろう）（ブロック７０）。残りのＡＴＧスクリプ
ト値は、タイムアウト値の０．２秒にセットする強制ス
テップタイム以外は、ゼロにセットする。タイムアウト
値は、ネットワークのトランスポートプロトコル階層の
振舞いをモデル化するために必要であり、これによりパ
ケットが転送中に失われても処理過程が進行することを
保証にする。もし、パケットが物理的ネットワーク中で
失われたとき、物理的ネットワークはパケットを再転送
する。しかし、もしシミュレーションに強制ステップが
利用できないのならば、パケットの損失はシミュレーシ
ョンが停止することを意味するだろう。なぜなら、レス
ポンスが受けとられるまで次のパケットが生成されない
からである。従って、タイムアウト機能がなければ、ト
ラフィックソースは停止したままになるだろう。図１４
のブロック７４で示すように、強制ステップ値はシンキ
ングタイムより大きくなくてはならず、さもなければ、
シンキングタイムパラメータは無効になる。

【００９４】クライアントウエイティングタイムパラメ
ータをＡＴＧスクリプトシンキングタイムパラメータに
割り当てることによって、各クライアントリクエストに
サーバレスポンスが対応付けられ、そして引き続くクラ
イアントリクエストが前回のサーバレスポンスを待つ
と、仮定していることを理解することは重要である。サ
ーバレスポンスに相関しないステップを記述する場合
は、そのステップのスクリプトのシンキングタイム値
を、強制ステップタイムよりも大きな値として記述しな
ければならない。さらに、クライアントノード自身がマ
シン上で他のアプリケーションに共有されていないとい
う仮定がなされる。

【００９５】もし、クライアントノードが複数のアプリ
ケーションを実行しているならば、クライアントウエイ
ティングタイムからＡＴＧスクリプトパラメータ「シン
キングタイム」への変換は、秒からＣＰＵインストラク
ションへの変換であり、ＡＴＧパラメータ「ローカルＣ
ＰＵアクセスタイム」として記述されなければならな
い。

【００９６】その結果の値は、Comdisco Systems, Inc.
の供給するAutomatic Traffic Generator (ATG)などの
市販のトラフィックモデルジェネレータが認識できるス
クリプトフォーマットに最終的に記述される。このフォ
ーマットはパラメータを、各値について、固定値、一様
な分布または指数分布として記述することができる。モ
デル化している各クライアント／サーバ − リクエスト
／レスポンスについて、１つのＡＴＧスクリプトステッ
プを作成する。リスタートステップは典型的にスクリプ
トの最後に含まれていて、シミュレーション中にそのス
クリプトが繰り返されることを示す。スクリプトの例を
図１７（ａ）及び図１７（ｂ）に示す。

【００９７】ＡＴＧはスクリプトを読んで、モデル化さ
れたネットワークに接続されたトラフィックソースから
出るトラフィックを生成し、ネットワークモデルのシミ
ュレーションを駆動する。もし、同じアプリケーション
を実行していて、かつ同じリソース構成の複数のクライ
アントノードをモデル化するならば、シミュレーション
は同一のスクリプトで駆動される同一のトラフィックソ
ースを記述する必要があるだけである。サーバはネット
ワークの一部として記述し、かつ、モデル化されるけれ
ども、そのトラフィックはクライアントノードトラフィ
ックソースの一部としてすでにモデル化されているの
で、スクリプトは必要ない。

【００９８】ここで用いたＡＴＧのパラメータ等につい
て、説明を加える。詳細はＡＴＧＭｏｄｕｌｅマニュア
ルに記載されている。

【００９９】スクリプトファイルのフォーマット スクリプトファイルは、２つ以上のノードが特定のタス
ク（たとえば、ダウンロードなど）を行うために相互的
に作動している状態、すなわちネットワークシナリオを
表す。

【０１００】ネットワークシナリオは、ノードにおける
処理、ディスクアクセス、延滞、及びネットワークでの
パケットの送信などを含んでいる。スクリプトファイル
はトランザクションを開始する側、つまりクライアント
ノード側から見る。

【０１０１】スクリプトファイルは１つ以上のレコード
から出きており、各レコードが１つのステップとなって
いる。そして、各レコードは９つのフィールドを持って
いる。各フィールドは確率分布関数（probability dist
ribution function）または定数によって指定される。
以下はスクリプトファイルの９つのフィールドであり、
この順序でスクリプトファイルに記述する。各フィール
ドはスペース、復帰改行、復帰、及びタブキャラクタに
よって区切られる。最後のフィールド（９番目）の後に
はセミコロンが必要である。スクリプトファイルの終り
に「ＲＥＳＴＡＲＴ」を指定すると、スクリプトは開始
行に戻る。

【０１０２】シンキングタイム（Thinking time）
（秒）：クライアントノードが前回送ったメッセージへ
のサーバノードからのレスポンスを受け取る時間と、そ
の次のメッセージを送る時間との間の時間。

【０１０３】このことは前回のステップがサーバノード
からメッセージが戻って来るのを必要としていることを
意味する。もし前回のステップがサーバノードからメッ
セージが戻って来るのを必要としていることを必要とし
ないならば（「入って来るメッセージ長」が０のときは
この場合にあたる）、このフィールドを使う必要はな
く、無限大を表す任意の大きな値セットしておいてよい
（ＡＴＧでは１Ｅ３４が無限大を表すのに使われる）。

【０１０４】強制ステップタイム（Forced-step time）
（秒）：前回のメッセージの生成から、その次のメッセ
ージの生成までの、クライアントノードの待時間。この
フィールドは、前回送ったメッセージに対するメッセー
ジが戻ってくるかどうかとは関係なく、メッセージ生成
時間のみを監視する。

【０１０５】もしメッセージが戻ってきて、そしてシン
キングタイムが経過すれば、次のメッセージが生成され
る。しかし、もし戻ってくるメッセージが受けとられる
までに、あるいはシンキングタイムが経過するまでに、
強制ステップタイムが経過すれば、次のメッセージが強
制的に生成される。もしサーバノードからのメッセージ
が使用されない場合（「入って来るメッセージ長」が０
のとき）、またはシンキングタイムが任意の大きな値
（シミュレーション時間と相対して）にセットされてい
る場合は、強制ステップ時間はＡＴＧで生成されるメッ
セージの間隔に等しい。

【０１０６】出ていくメッセージ長（Outgoing message
length）（ビット）：サーバノードへ送られるメッセ
ージのサイズ。もしこのサイズが０ならば、出ていくメ
ッセージは送信されない。

【０１０７】入って来るメッセージ長（Incoming messa
ge length）（ビット）：このサイズが０でなければ、
メッセージを送ったクライアントノードへ返されるメッ
セージが、サーバノードで生成される。

【０１０８】ローカルディスクアクセス（Local disk a
ccess）（ビット）：ローカルディスクへアクセスして
読まなければならないビットのサイズ。このアクセス
は、メッセージの生成、及びローカルＣＰＵアクセス
と、平行して行われる。

【０１０９】リモートディスクアクセス（Remote disk
access）（ビット）：サーバノードへアクセスして読ま
なければならないファイルのサイズ。サーバノードが
「出ていくメッセージ」を受け取ると、このアクセスは
リモートＣＰＵアクセスと平行して行われる。

【０１１０】ローカルＣＰＵアクセス（Local CPU acce
ss）（インストラクション）：このリソースアクセス
は、ローカルディスクアクセス及びメッセージの生成と
平行して行われる。

【０１１１】リモートＣＰＵアクセスタイム（Remote C
PU access time）（インストラクション）：サーバノー
ドがメッセージを受け取ると、このリソースアクセスは
リモートディスクアクセスと平行して行われる。

【０１１２】優先度（Priority）（ＬＡＮセグメントに
よって決まる）：クライアントノードからサーバノード
へ送らるメッセージの優先度を指定する。優先度パラメ
ータの働きは、使用されるＬＡＮセグメントによって決
まる。例えば、ＦＤＤＩには優先度が存在するが、１０
−Ｂａｓｅ−Ｔには存在しない。 利用できる分布関数 スクリプトファイルの各フィールドには、定数あるいは
確率分布関数によって記述された乱数値を使うことがで
きる。

【０１１３】固定値：固定値、すなわち定数は最も記述
しやすい値である。固定値は、引き数に１つの定数しか
とらない。固定値は、括弧の中に値を入れたＦ関数によ
って記述される。

【０１１４】Ｆ（値） 例えば定数２００は、Ｆ（２００．０）と記述される。

【０１１５】指数分布：この乱数値はＥ関数によって記
述される。平均値、最小値及び最大値のパラメータがあ
り、それらは括弧の中にコンマで区切って並べられる。

【０１１６】Ｅ（平均値，最小値，最大値） フィールドが典型的な指数変数値ならば、最小及び最大
値は、それぞれ通常０及び無限大である。これらはＡＴ
Ｇにおいては、それぞれ０．０及び１Ｅ３４と記述され
る。平均値が０．０３であるこのような乱数値は、Ｅ
（Ｏ．Ｏ３，０．０，１．０Ｅ３４）と記述される。

【０１１７】一様分布：この乱数値は、最小値から最大
値まで一様に分布する。これはＵ関数により表される。
最小値及び最大値は、カンマで区切って括弧の中に並べ
られる。

【０１１８】Ｕ（最小値，最大値） Ｏと１の間に一様に分布する典型的な乱数値は、Ｕ
（０．０，１．０）と記述される。

【０１１９】本発明に従ってノードにより生成されたト
ラフィックをモデル化するのに使用する実際のネットワ
ークトラフィックトレースからのパラメータの抽出を、
以下の例により、さらに説明する。最初の例では、ＤＯ
Ｓワークステーションを操作して、Novel NetWare 386
ファイルサーバからプログラムとファイルを読み込ん
で、ワードプロセッサを使っている４０人のユーザーの
いる部門を分析している。すべてのステーション及びサ
ーバは、同じ１０−Ｂａｓｅ−ＴのＬＡＮセグメントに
ある。すべてのステーションは昼間は稼働しているが、
利用のレベルは様々である。部門の管理者は、任意の時
点において、最高で２０台のステーションがプログラム
またはファイルの読み込みをしていて、おそらくそれが
このネットワークのピークアクティビティーレベルだろ
うと見積もっている。このことをネットワークモニタで
確かめてから（図１０のブロック１２及び１４）、本発
明に従ってこのアプリケーションの動作のモデル化を以
下のように行った。

【０１２０】Network General Snifferを用いて、386sx
DOS PCステーションによるNetware386サーバからのMic
rosoft Wordアプリケーションのプログラム読み込みの
トレースを記録する。このステーション、つまりノード
のリソース構成は、この部門のクライアントステーショ
ンの典型的なものである。この記録されたトレースの一
部を図１８〜図２６に示す。DOS PCクライアントステー
ション及びNovell NetWareサーバステーションは、Snif
fer（つまり、ネットワークアナライザー）を別にする
と、トレースが記録されたとき、このネットワークセグ
メントで作動していたただ２つのステーションであっ
た。Snifferのノーマルキャプチャートレースモードを
使用し、約５．４秒間にわたる５９７フレームのトレー
スを得た。この過程を図１１のブロック１８、３０、３
２、３４、及び３６に示す。

【０１２１】このトレースを分析するために、Sniffer
のサマリーディスプレイオプションの、バイト及びデル
タタイムを用いた。ネットワーク上の他のステーション
から、またはそこへのパケットを除くために、ディスプ
レイフィルターズステーションアドレスフロム／トゥオ
プションも使用した。ディスプレイマネージネームオプ
ションを用いて、クライアントステーション及びサーバ
ステーションのＭＡＣアドレスを、それぞれ「NetWare
Clnt」及び「NetWare Srvr」と定義する。これらのセッ
ティングにより、ＡＴＧスクリプトを作るのに必要な表
示が生成される。

【０１２２】図１８〜図２６のトレースの印刷出力を読
むために、トレースの各行はSnifferによってネットワ
ーク上で捕らえられた１パケットを典型的に表している
ことに留意しなければならない。各パケットの値は、左
から右へ、パケット番号（Snifferが作成する）１０
０、秒でのパケットインターアライバルタイム１０２、
ヘッダを含みパケットチェックサムを除外したパケット
サイズ１０４（バイト）、目的地ＭＡＣアドレス１０
６、ソースＭＡＣアドレス１０８、パケットの最上位の
プロトコルタイプ１１０、及びプロトコル依存の記述フ
ィールド１１２、である。

【０１２３】図１１のブロック３８に従ったこのトレー
スの分析で、プログラム読み込みファイル読み出しの間
のサーバレスポンスタイムに、明かな典型的なパターン
があることがわかる。例えば、パケット番号１５（図１
８）からパケット番号１１０（図２３）において、４８
のクライアント／サーバ − リクエスト／レスポンス相
互作用がある。各クライアントリクエストパケットは６
４バイト長で、各サーバレスポンスパケットは１０７８
バイト長である。図１８〜図２６のトレースには、クラ
イアント／サーバ相互作用の他の典型的なパターンがあ
り、もし本発明に従って使用すれば、それらは正確な結
果を作り出すであろうことを指摘しておく。９６個の連
続したネットワークパケットにおいて、ほとんどのもの
は約１．６から２．０ｍｓの延滞で送られる。しかし、
４サーバレスポンス毎に相当する８つ毎のパケットは、
約２５ｍｓから５０ｍｓというより長い時間がかかって
いる。プログラムの読み込みは連続ファイル読み取りで
あり、 Novell NetWareサーバがディスクから読み取っ
たファイルブロックをキャッシュしていることは、当業
者には分かるだろう。従って、ファイル読み取りリクエ
スト４つ毎の長くかかる時間は、４つのネットワークリ
クエストを満たすのに十分な新しいブロックをディスク
から読み取るための時間を表していることを推定でき
る。

【０１２４】このプログラム読みだしファイル読み取り
をモデル化するために、３つの短いサーバレスポンスに
続く１つの大きなサーバレスポンスのパターンを表す４
つのステップが必要であろう。ブロック４４、４６、及
び４８に従って、ネットワークトレースシーケンスから
抽出された値は、以下の通りである。

【０１２５】リクエストパケットウェイティングタイム
＝０．００１７秒 リクエストパケットサイズ＝６４バイト レスポンスパケットウエイティングタイム＝０．００１
８秒が３個 ０．０３５０秒が１個 レスポンスパケットサイズ＝１０７８バイト このアプリケーションアクティビティーをスクリプト化
する前に、もう一度パケットサイズ値の修正（ブロック
５０に示すように）をする必要がある。上記のパケット
サイズには、イーサネット、すなわち１０−Ｂａｓｅ−
Ｔのためのデータリンク階層オーバーヘッド、及びＩＰ
Ｘのためのネットワーク階層オーバーヘッドが含まれる
ことを、当業者には、分かるであろう。従って、ネット
ワークプロトコルの機能として必要なすべてのオーバー
ヘッドデータがネットワークシミュレーションモデルに
よって考慮されるので、各パケットサイズから３４バイ
トを差し引かなければならない。このプロトコルオーバ
ーヘッドには、１４バイトのＬＡＮデータリンクオーバ
ーヘッド、及び２０バイトのＩＰネットワークオーバー
ヘッドが含まれる。もし、そのようなオーバーヘッドデ
ータのどれかがネットワークシミュレーションモデルで
考慮されないならば、それらの考慮されないビットは、
リクエストパケットまたはレスポンスパケットサイズパ
ラメータの一部として残されるだけである。従って、ブ
ロック５４からの出力としてのクライアント／サーバパ
ラダイムの結果の値は、以下のようになる。

【０１２６】クライアントウエイティングタイム＝０．
００１７秒 クライアントリクエストサイズ＝３０バイト サーバレスポンスタイム＝０．００１８秒が３個 ０．００３５０秒が１個 サーバレスポンスサイズ＝１０４４バイト 上記のパラメータは、本発明の方法に従ってモデル化さ
れる記録されたトラフィックを表していることを理解し
なければならない。一度このモデルを作れば、シミュレ
ーションの目的のモデルに従って離散型イベントを作る
ために、様々な形に変換することができる。図１４のス
クリプト作成２２プロセスに従い、かつComdisco Syste
ms, Inc.から入手できるApplication Traffic Generato
r Module(ATG)に認識されるようなスクリプト入力を作
るために、２つのサイズ値に８を掛けてバイトからビッ
トへ変換し（ブロック６８）、サーバレスポンスタイム
にサーバＣＰＵアクセスレート（例えば、１０ＭＩＰ
Ｓ）を掛けて時間からＣＰＵインストラクションに変換
する（ブロック７０）。クライアントウエイティングタ
イムは、「シンキングタイム」パラメータとして記述さ
れる（ブロック７２）。従って、モデルはスクリプト中
の４つのステップに変換され、それによりＡＴＧはクラ
イアントリクエストの特徴を模倣する離散型イベントを
生成し、次にディスク読み取りを必要とするサーバレス
ポンス、そして３つのクライアントリクエスト、さらに
既に読み取ってあるディスクブロックを用いるより高速
なサーバレスポンスを行う。その結果得られるＡＴＧス
クリプトは、スクリプトがシミュレーション中に繰り返
されることを示すリスタートステップを含んでいる。こ
れを図１７（ａ）に示す。

【０１２７】次に、例にあげたネットワークをシミュレ
ートするための、図１６のシミュレートネットワーク手
順２８に移る。ＡＴＧをプログラムして、スクリプトで
表されたモデルに従って、１０個のトラフィックのソー
スを供給させる（ブロック８６）。これらのソースは１
０−Ｂａｓｅ−Ｔセグメントのモデルに連続して接続さ
れている（ブロック９０）。サーバノードの動作をモデ
ル化するトラフィック目的地ノードも、同じ１０−Ｂａ
ｓｅ−Ｔセグメントに接続されている。

【０１２８】図６、図７、及び図８に示されるような、
あるいは以前にネットワークから記録したトレースをた
だ再生するのような、先行技術と異なり、本発明を適用
して作られたモデルに従ってパケットを生成するトラフ
ィックソースは、シミュレーション中にネットワークモ
デルが予想するようにサーバ及びネットワークリソース
への需要の関数としてパケットを生成する頻度を自動的
に変化させる。

【０１２９】一方、トラフィックソースをモデル化する
以前の方法では、もしシミュレートされているネットワ
ークを含むクライアントノードの数が増えても、それに
対応したサーバリソースへの需要の増加という結果にな
り、ネットワークの総応答時間が遅くなることについて
のモデルへのフィードバックがないために、以前の方法
のトラフィックモデルは同じ頻度でパケットを送り出し
続ける。物理的ネットワークではクライアントノードが
生成するパケットの頻度が下がるので（サーバレスポン
スに相関しているクライアントリクエストは、レスポン
スの到着を待たなければいけない）、フィードバックが
欠如していると、不正確なシミュレーションになる。

【０１３０】本発明を適用した２番目の例は、ある部門
において、１０人の設計技術者がＣＡＤアプリケーショ
ンを実行しているＳｕｎ ＳＰＡＲＣステーションを操
作して、Ｓｕｎ ＮＦＳサーバとして作動しているＳｕ
ｎ ＳＰＡＲＣステーションからプログラム及びファイ
ルを読み込んでいる場合である。すべてのステーション
（つまり、ノード）、及びサーバノードは、同じ１０−
Ｂａｓｅ−ＴのＬＡＮセグメント上にある。すべてのス
テーションは昼間は稼働しているが、その使用のレベル
は様々である。その部門の管理者は、任意の時点で最高
４つのステーションが、プログラムまたはファイルを読
み込んでおり、そして多分それがこのネットワークセグ
メントのアクティビティーレベルのピークだろうと見積
る。このことをネットワークモニタで確認した後（図１
０のブロック１２及び１４）、本発明に従ったこのアプ
リケーションの動作のモデル化は、以下のようにして続
けられる。

【０１３１】Network General Snifferを用いて、Ｓｕ
ｎ ＳＰＡＲＣ Ｓｔａｔｉｏｎ ２ＮＦＳサーバステー
ションから３２ＭＢのＲＡＭを備えたＳｕｎ ＳＰＡＲ
Ｃ Ｓｔａｔｉｏｎ ２による、BONeS（商標） Designer
（商標） 2.0アプリケーションのプログラム読み込みの
トレースを記録する。このステーションは、この部門の
中の典型的なクライアントステーション（つまり、ノー
ド）である。このトレースの一部は、図２７〜図３５に
示してある。トレースの間、サーバ及びネットワークで
の他のアクティビティーは最小に抑えたが、このトレー
スが記録されたときに、他のアクティビティーは存在し
ていた。Snifferのノーマルキャプチャートレースモー
ドを使用して、約２４２秒間にわたる６２４７フレーム
を得た（図１１のブロック１８、３０、３２、３４、及
び３６）。

【０１３２】このトレースを分析するために、Sniffer
のサマリーディスプレイオプションのバイト及びデルタ
タイム値を使用する。ネットワーク上の他のステーショ
ンからの、またはそこへのパケットを除くために、ディ
スプレイフィルターズステーションアドレスフロム／ト
ゥオプションも使用した。ディスプレイマネージネーム
オプションを用いて、クライアントステーション及びサ
ーバステーションのＭＡＣアドレスを、それぞれ「ｚｅ
ｕｓ」及び「ｃｏｒｋｙ」と定義する。このセッティン
グにより、ＡＴＧスクリプトを作成するのに必要な表示
が生成される（ブロック３４）。

【０１３３】トレースの印刷出力を分析するために、ト
レースの各行は、Snifferによりネットワーク上で捕ら
えられた１パケットを表していることに留意しなければ
ならない。各パケットの値は、左から右へ、パケット番
号１００（Snifferが生成する）、秒でのパケットイン
ターアライバルタイム１０２、ヘッダを含みパケットチ
ェックサムを除くパケットサイズ（バイト）、目的地Ｍ
ＡＣアドレス１０６、ソースＭＡＣアドレス１０８、パ
ケット中に組み込まれた最上位のプロトコル１１０、及
びプロトコルに依存する記述フィールド１１２、であ
る。

【０１３４】例えば、図２７のパケット１から図２９の
５８に見られるように、最もトラフィックの激しいネッ
トワークアクティビティーは、クライアントノードによ
るサーバノードからの大きな４Ｋまたは８Ｋブロック読
み取りで表されていることが、このトレースの分析から
わかる。サーバレスポンスメッセージは、ＵＤＰトラン
スポートプロトコルにより分割されている。パケット３
７において、クライアントノードからサーバノードへ、
８１９２バイトを読み取るリクエストが送られている。
パケット３８から４３はレスポンスメッセージで、サイ
ズが８Ｋ以上あるが、１０−Ｂａｓｅ−Ｔのパケットサ
イズ制約により、５つの１５１４バイトパケット及び１
つの９３４バイトパケットとして送られる。このファイ
ル読み取りアクティビティーは、例えばパケット５９
（図２９）から６４（図３０）にあるように、他のファ
イルを捜すためのリクエストに定期的に割り込まれる。
ファイルを捜すことと、そしてそのファイルの内容を読
み取ることのサイクルとしてアクティビティーをモデル
化するのが妥当なアプローチである。本発明に従ってア
クティビティーのモデルから得られるスクリプトは、こ
の例のネットワークのシミュレーション中に反復するの
で、進行中のプログラム読み込みのトラフィックの特徴
を実際的にモデル化するであろう。さらに、ノード数が
増えるにつれてネットワークレスポンスは遅くなると
き、ブロック３８に従って、ネットワークにより重い負
荷があるときのプログラム読み込みのトラフィックの特
徴を、スクリプトは実際的にモデル化するであろう。

【０１３５】パケット５９（図２９）からパケット１０
９（図３２）までのパケットシーケンスサイクルを選
ぶ。この中には、ステーション「ｚｅｕｓ」がクライア
ントノードであり、ステーション「ｃｏｒｋｙ」がサー
バノードである１０個のクライアント／サーバ−リクエ
スト／レスポンス相互作用がある。クライアントステー
ションは、最初にサーバ上のファイル名「Ｐ００００
５」を捜すが、これは見つからない。それでファイル拡
張子「ｓｂｉｎ」を加えてもう一度捜し、そのファイル
を見つけて、ファイルハンドルを得る。次に、クライア
ントはファイルハンドルの属性を読み、パケット６５
で、そのファイルへの４Ｋバイトの読み取りリクエスト
を出す。サーバは、計１７６１バイトのファイルを含む
レスポンスメッセージを返す。このメッセージサイズは
依然として１０−Ｂａｓｅ−Ｔの最大転送サイズを越え
るので、番号６７及び６８の２つのパケットを要する。
その後、さらにクライアントは以前にオープンしていた
他のファイルへ８Ｋバイトの読み取りリクエストを出
し、シーケンスを完了する。それぞれの場合、サーバレ
スポンスメッセージはＵＤＰトランスポート階層プロト
コル（使用しているＬＡＮプロトコルの特徴）により、
５つの１５１４バイトレスポンスパケット、及び１つの
９３４レスポンスパケットに分割される。実行されてい
るアプリケーションプログラムに詳しい人なら、ファイ
ル「Ｐ００００５ ｓｂｉｎ」は、ＢＯＮｅＳ（商標）
Ｄｅｓｉｇｎｅｒ（商標） ２．０のリリースパッチフ
ァイルの１つであることに気づくであろう。従って、こ
のシーケンスは、大きなファイルを読み取るプログラム
読み込み動作、及び必要なときに比較的小さなパッチフ
ァイルをオープンして読み取るものであると推定でき
る。ゆえに、このデータのやり取りの激しいクライアン
ト／サーバ相互作用のシーケンスは、このアプリケーシ
ョンのデータトラフィックを適切に典型的に示すであろ
う。

【０１３６】このシーケンスを模倣するために、１０個
のステップをモデル化し、適当なＡＴＧのスクリプトに
変換する。１５００バイトよりも大きな７つのサーバレ
スポンスメッセージについては、ブロック５８、６０、
６２、及び６４に示すように、１つのサーバレスポンス
に相当する複数のパケットを１つのメッセージに統合し
なければならない。なぜならば、本発明により作られる
トラフィックのモデルは、ネットワークプロトコルのア
プリケーション階層で作られるパッケットをモデル化す
るからである。ＡＴＧは、シミュレートするネットワー
クのプロトコルに従って、アプリケーションメッセージ
を適当なサイズのパケットに分割する過程をモデル化す
るだろう。従って、モデル化しているノードから出るト
ラフィックを表す離散型イベントを生成する過程におい
て、ネットワーク階層及びデータリンク階層オーバーヘ
ッドバイトを加え戻しながら、ＡＴＧはＵＤＰ連続フレ
ームを再構成する。

【０１３７】６つのサーバ８Ｋバイトブロック読み取り
の正しいメッセージサイズを計算するために、最初に、
３４バイトのデータリンクオーバーヘッド及びＩＰネッ
トワークオーバーヘッドを６つのパケットのそれぞれの
長さから差し引く（図１２のブロック５０）。これは、
１４８０バイトの５つのレスポンスサブメッセージパケ
ット、及び９００バイトの１つのリクエストメッセージ
サブパケットを作成する。従って、再結合された単一の
リクエストパケット合計の長さは、５×１４８０＋９０
０＝８３００バイトであり、これは８１９２バイトのデ
ータ読み取りと、１０８バイトの第１のパケットのトラ
ンスポート階層オーバーヘッドを加えた値を反映してい
る。このトランスポート階層オーバーヘッドは、ＡＴＧ
またはネットワークモデルによりモデル化されない。１
つの４Ｋバイトブロック読み取りは、このレスポンスは
たった１７６１バイトのデータであるが、１８７２のサ
イズのシングルレスポンスパケットを必要とする。

【０１３８】シングルレスポンスパケットに関する次の
問題は、これにどんなレスポンスパケットウエイティン
グタイムを割り当てるかである。トレースより、１５１
４バイトの反復されるＵＤＰ連続フレームが、１．１か
ら１．３ｍｓの間隔で転送されることが分かる。１５１
４バイトの転送時間を計算し、１．２ｍｓの値を得る
（つまり、１５１４×８／１０⁷＝０．００１２１）。
連続フレームの延滞は単に転送時間と媒体競合の問題で
あると結論することができる。１０−Ｂａｓｅ−Ｔモデ
ルがこれを考慮に入れるだろう。従って、シングルレス
ポンスパケットの正しいレスポンスパケットウエイティ
ングタイムは、レスポンスの第１のサブメッセージパケ
ットのインターアライバルタイムである（ブロック６０
及び６４に図示した）。

【０１３９】他のリクエスト及びレスポンスパケットサ
イズからも３４バイトを差し引いた後、本発明の方法に
従ったクライアント／サーバパラダイムの形式での１０
ステップシーケンスは、以下のようになる。

【０１４０】１． クライアントウエイティングタイム
＝０．０２９６秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００１６秒 サーバレスポンスサイズ＝３６バイト ２． クライアントウエイティングタイム＝０．０２５
６秒 クライアントリクエストサイズ＝１２４バイト サーバレスポンスタイム＝０．００１６秒 サーバレスポンスサイズ＝１３６バイト ３． クライアントウエイティングタイム＝０．３６０
６秒 クライアントリクエストサイズ＝１０８バイト サーバレスポンスタイム＝０．００１２秒 サーバレスポンスサイズ＝１０４バイト ４． クライアントウエイティングタイム＝０．０２７
４秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．０１４３秒 サーバレスポンスサイズ＝１８７２バイト ５． クライアントウエイティングタイム＝０．０１０
３秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２８秒 サーバレスポンスサイズ＝８３００バイト ６． クライアントウエイティングタイム＝０．０１２
８秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２６秒 サーバレスポンスサイズ＝８３００バイト ７． クライアントウエイティングタイム＝０．００２
９秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２６秒 サーバレスポンスサイズ＝８３００バイト ８． クライアントウエイティングタイム＝０．００４
２秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２６秒 サーバレスポンスサイズ＝８３００バイト ９． クライアントウエイティングタイム＝０．００８
４秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２８秒 サーバレスポンスサイズ＝８３００バイト １０．クライアントウエイティングタイム＝０．００４
９秒 クライアントリクエストサイズ＝１２０バイト サーバレスポンスタイム＝０．００２８秒 サーバレスポンスサイズ＝８３００バイト 図１４のスクリプト作成手順２２に従って、パラダイム
パラメータを変換するために、各ステップの２つのサイ
ズ値に８をかけてバイトからビットに変換し、各ステッ
プのサーバレスポンスタイムに１０ＭＩＰＳを掛けてＣ
ＰＵインストラクションに変換し、サーバファイル探索
に一連の大きなブロックファイルの読み取りが続くシー
ケンスを表す１０ステップのＡＴＧスクリプトを作成す
る。その結果得られるスクリプトは、そのスクリプトが
シミュレーション中に反復されることを示すリスタート
ステップを含んでいる。このスクリプトを図１７（ｂ）
に示す。

【０１４１】第３ステップにある強制タイムアウト（ブ
ロック７４）は、必要なクライアントウエイティングタ
イムの０．３６０６秒よりも長くなるように、０．４秒
となっていることに注意すること（ブロック７４）。

【０１４２】図１６のシミュレートネットワーク手順２
８に従って、本発明の方法により作られたモデルに従い
４つのトラフィックソースを供給するようにプログラム
されたＡＴＧに、１０−Ｂａｓｅ−Ｔセグメントを接続
することにより、シミュレーションのためのネットワー
クのモデルは作成される。従って、上記のスクリプトに
より指示される通りに、４つのノードは離散型イベント
を作ってシミュレーションを駆動する。トラフィック目
的地パラメータも記述され、ネットワークモデルに接続
される。

【０１４３】さらに、よくあるアプリケーションプログ
ラムを実行しているよくあるノード構成は本発明に従っ
てモデル化され、その結果得られるスクリプトはネット
ワークシミュレーション製品のユーザーに市販されるあ
ろう。これは図１５に、既製スクリプト２６という手順
で示してある。これにより、ユーザーがよくあるネット
ワークノードで生成されるトラフィックの特徴を再度記
述しなくてすむようになるのは明かである。

【０１４４】典型的及び好ましい実施態様によって本発
明を説明してきたが、それのみに制限されるものではな
い。本質的な意図及び範囲を外れることなく、多くの新
たな修正及び改良を本発明に加えることができることに
当業者は気づくであろう。例えば本発明の方法は、モデ
ルパラメータを抽出する過程、またはモデルパラメータ
のスクリプトへの変換へのわずかな修正がプロトコルの
違いに基いて必要であるにしても、実施例のいずれでも
具体化しなかったあらゆる他のネットワークプロトコル
へ応用可能である。

【０１４５】

【発明の効果】以上説明したように、本発明のモデル化
方法は、ネットワークに他の負荷がない状態でクライア
ントノードが特定のアプリケーションまたは複数のアプ
リケーションを実行している場合の、クライアントノー
ドとサーバノード間の既知または評価されたリクエスト
／レスポンス相互作用に基づいて、通信ネットワークま
たは分散処理システムのノードにより生成されるトラフ
ィックをモデル化する。従って、ノード数、各ノードの
プロセッシングリソースの質または量、ネットワークリ
ソースの質または量、及び／または、各ノードで実行さ
れるアプリケーション、とが変化するときのネットワー
クの動作及びパフォーマンスのシミュレーションの精度
を大幅に改善することが可能になる。

【図面の簡単な説明】

【図１】一般的な分散システムアーキテクチャの例を示
す図である。

【図２】Ｃａｍｐｕｓ Ｎｅｔｗｏｒｋの絵図である。

【図３】図２のＣａｍｐｕｓ Ｎｅｔｗｏｒｋの概略図
である。

【図４】ある高度な分散処理システムのブロック図であ
る。

【図５】ＩＳＯ 開放型システム相互接続（ＯＳＩ）モ
デルの説明図である。

【図６】転送システムシミュレーションのブロック図で
ある。

【図７】図６の音声トラフィックソースブロックのブロ
ック図である。

【図８】図６のデータトラフィックソースブロックのブ
ロック図である。

【図９】本発明のクライアント／サーバパラダイムの概
念図である。

【図１０】シミュレートするネットワークのトラフィッ
クをモデル化するための手順を示すフロー図である。

【図１１】ネットワーク分析を行う手順を示すフロー図
である。

【図１２】本発明のクライアント／サーバパラダイムに
従って、ノードトラフィックをモデル化するための手順
を示すフロー図である。

【図１３】本発明のクライアント／サーバパラダイムに
従って、ノードトラフィックをモデル化するための手順
を示すフロー図である。

【図１４】モデルパラメータからスクリプトを作るため
のステップを示すフロー図である。

【図１５】よくあるアプリケーションのスクリプトを得
るための手順を示すフロー図である。

【図１６】ネットワークモデルのシミュレーションにお
いてスクリプトを使用する手順を示すフロー図である。

【図１７】本発明の方法の第１の適用例及び第２の適用
例で作られたスクリプトを示す図である。

【図１８】第１の例のトレースで捕らえられたパケット
を示す図である。

【図１９】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２０】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２１】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２２】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２３】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２４】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２５】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２６】第１の例のトレースで捕らえられたパケット
を示す図である。

【図２７】第２の例のトレースで捕らえられたパケット
を示す図である。

【図２８】第２の例のトレースで捕らえられたパケット
を示す図である。

【図２９】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３０】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３１】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３２】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３３】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３４】第２の例のトレースで捕らえられたパケット
を示す図である。

【図３５】第２の例のトレースで捕らえられたパケット
を示す図である。

【符号の説明】

１０ シミュレートするネットワークのトラフィックを
モデル化する手順 １８ ネットワーク分析ブロック ２０ クライアント／サーバパラダイムに従ってノード
トラフィックをモデル化するブロック ２２ スクリプトを作るブロック ２８ ネットワークをシミュレートする手順

───────────────────────────────────────────────────── フロントページの続き (72)発明者 コリン ケイ． ミック アメリカ合衆国 カリフォルニア 94306，パロ アルト，ハノーバー ス トリート 2130 (56)参考文献 特開 平３−65835（ＪＰ，Ａ) 米国特許5247517（ＵＳ，Ａ) 欧州特許出願公開46466（ＥＰ，Ａ１) 電子情報通信学会技術研究報告，Ｖｏ ｌ．92 Ｎｏ．514，（ＩＮ92−155）, 松永靖彦 他「ネットワークシミュレー ターによるコンピュータネットワーク管 理」，ｐａｇｅｓ．49−54 1991 ＩＥＥＥ／ＳＭＣ Ｉｎｔｅｒ ｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃ ｅ ｏｎ Ｓｙｓｔｅｍ，Ｍａｎ，ａｎ ｄ Ｃｙｂｅｒｎｅｔｉｃｓ，Ｖｏｌｕ ｍｅ．２，Ａｌｅｘｉｓ Ｄｅｌｉｓ ｅｔ ａｌ．，”Ｓｅｒｖｅｒ Ｂａｓ ｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔ ｒｉｅｖａｌ Ｓｙｓｔｅｍｓ Ｕｎｄ ｅｒ Ｌｉｇｈｔ Ｕｐｄａｔｅ Ｌｏ ａｄｓ”，ｐａｇｅｓ．813−818 (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 12/28 G06F 13/00 355 H04L 29/14 ＪＩＣＳＴファイル（ＪＯＩＳ) ＰＣＩ（ＤＩＡＬＯＧ)

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】 ネットワークによって相互接続される複
   数のノードの間でネットワーク上を転送されるデータト
   ラフィックをシミュレートする方法であって、該データ
   トラフィックは該複数のノードの間で複数の対話を備え
   ており、該複数のノードの１以上はクライアントノード
   であり、該複数のノードの１以上はサーバノードであ
   り、 該方法は、 該ネットワークを表すモデルを提供するステップと、 １以上のリクエスト／レスポンス相互作用の列として、
   該複数の対話の１以上を特徴づけるステップであって、
   該１以上の相互作用のそれぞれは、該１以上のクライア
   ントノードの１つから該１以上のサーバノードの１つへ
   のリクエストメッセージの転送を備えており、該１以上
   の相互作用の全てが該リクエストメッセージに関連する
   レスポンスメッセージの転送を備えない、あるいは、該
   １以上の相互作用のいくつかまたは全てが該リクエスト
   メッセージに関連する該レスポンスメッセージの転送を
   さらに備え、該関連するレスポンスメッセージは該１つ
   のサーバノードから該１つのクライアントノードへ該リ
   クエストメッセージを受信することに応答して転送され
   るステップと、 該特徴づけられた対話のそれぞれの該１以上の相互作用
   を表すデータを生成するステップであって、該生成ステ
   ップが該相互作用のそれぞれに対して該生成されたデー
   タを該ネットワークモデルに入力して、該関連するレス
   ポンスメッセージを有する該相互作用のそれぞれの該関
   連するレスポンスメッセージが、該１つのクライアント
   によっていつ受信されるかを決定するステップと、 該相互作用の１つの該リクエストメッセージが以前に生
   成されたリクエストメッセージに関連する該レスポンス
   メッセージの該１つのクライアントノードの受信に依存
   しているとき、該ネットワークモデルにより決定された
   ように、該１つのクライアントノードによって該以前に
   生成されたリクエストメッセージに関連する該レスポン
   スメッセージが受信されるまで、該依存した相互作用を
   表す該データを該ネットワークモデルに入力することを
   延滞させるステップと、 をさらに包含するステップとを包含する方法。