JP2003124985A - Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 パケット交換網のトラヒック特性を効率的に
理解する課題を解決したトラヒックの測定、監視、制
御、管理、予測、または、設計の方法を提供することに
ある。 【解決手段】 ノード間の各リンクにおけるＩＰパケッ
トのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッショ
ン層で区別し、且つ、アプリケーション層でアプリケー
ション別にセッションを計数すること（アプリケーショ
ン別セッション計数法）を第１の特徴とする。更に、ア
プリケーション別に予め定めた分析方法を用いて上記の
アプリケーション別セッションの計数結果を分析するこ
と（アプリケーション別セッショントラヒック分析法）
を第２の特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、パケット交換網に
おけるトラヒック特性を効率的に理解する方法と、その
方法を実施するノード及び外付け装置に関するものであ
る。パケット通信網としては、例えば、ＴＣＰ／ＩＰプ
ロトコルを用いるインターネットが挙げられる。また、
トラヒック特性を理解することによって解決される技術
分野としては、トラヒックの測定、監視、制御、管理、
予測、設計などが挙げられる。

【０００２】

【従来の技術】周知のように、通信サービスは、ネット
ワークを介して物理的・地理的な距離の隔たりを解消さ
せることで、社会・経済活動に掛け替えのない生活基盤
（ライフライン）になっているので、短時間であっても
サービスが停滞することは容認されない。通信ネットワ
ークに流れる情報量は増加の一途を辿っていて、その情
報を迅速かつ確実に伝達することは社会からの要請であ
る。通信事業者は、顧客の満足に適った通信サービスを
提供するために、通信ネットワークの基本的な機能と性
能を測定し、監視し、制御し、管理し、更に、必要なリ
ソースを設計することで、効率のよい設備の構築、的確
な運用、コストの低廉化を実施する必要がある。

【０００３】通信システムの性能は、通信サービスの情
報量、即ち、トラヒック（traffic）で表現される。こ
の「トラヒック」という単語は、交通や運輸の分野にお
いても交通量や運輸量として、方向性を持った量の意味
で使われている。通信の分野でのトラヒックは、電話・
電報・データ・画像などの通信の交流や構造を意味して
いて、特に電話においては「通信設備によって運ばれる
呼（call）」が基本単位になっている。また、パケット
通信においては、従来、パケット（packet）やバイト
（byte）が基本単位になっている．非同期転送モード
（ATM,Asynchronous Transfer Mode）での通信では、セ
ル（cell）が基本単位になっている。

【０００４】一般の商品が、数量・品質・価格・売れ具
合などを生産・流通・販売の過程で把握し管理する必要
があるように、通信の分野では、業務の目的に合わせて
トラヒックを的確に把握・管理する必要がある。これを
通信網のトラヒック業務と呼ぶ。電話においては、呼を
測定し、同時接続中の呼数を管理することで、トラヒッ
クの把握や管理が可能であった。パケット通信において
は、パケット数やバイト数を測定し管理することで、あ
る程度のトラヒックの把握や管理が可能であった。ＡＴ
Ｍにおいてはセル数を測定する方法もあるが、セル送信
バッファの待ち行列しきい値を超過する回数も測定する
ことで、トラヒックの把握や管理が可能であった。

【０００５】近年、インターネットが普及し、ＴＣＰ／
ＩＰアプリケーションの観点からトラヒックの把握を行
なうことで、トラヒック特性を効率的に理解する方法が
求められている。ＴＣＰ／ＩＰの下位プロトコルとして
ＡＴＭが用いられることがある。上述のセルレベルの測
定に基づく技術はセルレベルのトラヒックを把握するこ
とに適用する技術であって、階層の異なるＴＣＰ／ＩＰ
アプリケーションの観点からは直接的ではない。

【０００６】次に上記の階層について説明する。通信プ
ロトコルは階層モデルが適用される。国際標準化機構
（ISO,International Organizationfor Standardizatio
n）は、通信の国際標準として開放型システム相互間接
続（OSI,Open System International）という通信プロ
トコルの標準化を目指すにあたり、通信プロトコルを設
計する指標として、通信プロトコルの機能を７つの階層
に分割するＯＳＩ参照モデルを提唱し、複雑になりがち
な通信プロトコルを単純化することを目指した。ＯＳＩ
参照モデルの各層の機能を表１の左側に示す。

【０００７】

【表１】

【０００８】パケット交換網として代表的なインターネ
ットにおける通信プロトコルは、ＴＣＰ／ＩＰと呼ばれ
る。ＯＳＩ参照モデルとの対応と共にＴＣＰ／ＩＰの階
層モデルを表１の右側に示す。両者に違いがあるのは、
ＯＳＩ参照モデルが、腑撤的にモデル化されたのに対し
て、ＴＣＰ／ＩＰの階層モデルはプロトコルの実装の観
点からモデル化されたためである。ＯＳＩ参照モデルに
当てはめると、その構造は第５〜７層がアプリケーショ
ン層に統合されている特徴がある。実装の観点からは、
単一のアプリケーションの内部で第５〜７層それぞれの
機能が実現される場合もあるし、複数のアプリケーショ
ンに分けて実装される場合もある。ＴＣＰ／ＩＰのアプ
リケーションプログラムの機能を詳細に見ていくと、Ｏ
ＳＩ参照モデルの第５〜７層のそれぞれの機能が見えて
くる。その説明の前に、両方のモデルに共通するトラン
スポート層のプロトコルについて説明する。

【０００９】トランスポート層のプロトコルにはＵＤＰ
（User Datagram Protocol）とＴＣＰ（Transmission C
ontrol Protocol）がある。ＵＤＰはコネクションを確
立せずに通信を開始できる軽量なプロトコルである。Ｕ
ＤＰについては、ＲＦＣ７６８に示されている。信頼性
が必要な場合はＵＤＰよりも上位のプロトコルでそれを
提供する。一方、ＴＣＰはコネクションを確立してから
通信するので、信頼性を提供することができるプロトコ
ルである。ＴＣＰについては、ＲＦＣ７９３に示されて
いる。図１にＴＣＰコネクションの確立と終了に対応す
る事象シーケンス図を示し、図２に通常の状態遷移ダイ
アグラムを示す。ただし、説明の簡単のために通常の場
合のみに限定している。

【００１０】ＴＣＰコネクションを確立するステップに
ついて説明する。ＴＣＰコネクションは２台の端末間の
コネクションで、それぞれの端末のＩＰアドレスをヘッ
ダーに指定されたパケットで通信する。そのため、端末
間のノードにおいて、このＩＰアドレスの組によって区
別される。ＴＣＰコネクションの確立には次の３ステッ
プを踏む。 １．要求側の端末（クライアントと呼ばれる）は、接続
したい端末（サーバとよばれる）に、ポート番号（アプ
リケーションの識別子）とクライアントの初期シーケン
ス番号を指定したＳＹＮセグメントＳ０１を送る。 ・クライアントはＳＹＮ−ＳＥＮＴ状態に遷移する。 ２．サーバは、Ｓ０ｌに応じて、サーバ側の初期シーケ
ンス番号を含む自分自身のＳＹＮセグメントＳ０２で応
答する。また、これにはクライアントの初期シーケンス
番号＋１のＡＣＫを含めて、クライアントのＳＹＮに確
認応答する。 ・サーバはＬＩＳＴＥＮ状態からＳＹＮ＿ＲＣＶＤ状態
に遷移する。 ３．クライアントは、Ｓ０２に応じて、サーバの初期シ
ーケンス番号＋１のＡＣＫセグメントＳ０３で確認応答
する。 ・クライアントはＳＹＮ＿ＳＥＮＴ状態からＥＳＴＡＢ
ＬＩＳＨＥＤ状態に遷移する。 ・サーバはＡＣＫを受けてＥＳＴＡＢＬＩＳＨＥＤ状態
に遷移する。 上記のステップは通常の場合であり、コネクションの確
立に至らずタイムアウトした場合や、両端末から同時に
コネクション確立要求があった場合などはこのステップ
には従わない。

【００１１】ＴＣＰコネクションを終了するステップに
ついて説明する。次の４ステップを踏む。 １．クライアントは、ＦＩＮセグメントＳｌｌをシーケ
ンス番号とともに送る。 ・クライアントはＥＳＴＡＢＬＩＳＩ正Ｄ状態からＦＩ
Ｎ ＷＡＩＴ １状態に遷移する。 ２．サーバは、Ｓ１１に応じて、受取ったシーケンス番
号＋１のＡＣＫセグメントＳ１２で確認応答する。サー
バはアプリケーションにＴＣＰコネクションの終了を知
らせる。そして、サーバはクライアントにＦＩＮセグメ
ントＳ１３をシーケンス番号とともに送る。 ・サーバはＥＳＴＡＢＬＩＳＨＥＤ状態からＣＬＯＳＥ
Ｄ＿ＷＡＩＴ状態に遷移する。 ・サーバはアプリケーションヘの終了通知に応じてＣＬ
ＯＳＥＤ＿ＷＡＩＴ状態からＬＡＳＴ＿ＡＣＫ状態に遷
移する。 ３．クライアントは、Ｓ１２とＳ１３に応じて、受取っ
たシーケンス番号＋１のＡＣＫセグメントＳ１４で確認
応答する。 ・クライアントはＳ１２に応じてＦＩＮ ＷＡＩＴ １
状態からＦＩＮ ＷＡＩＴ ２に遷移する。 ・クライアントはＳ１３に応じてＦＩＮ ＷＡＩＴ ２
状態からＴＩＭＥ＿ ＷＡＩＴ状態に遷移する。 ・クライアントは、予め定められた２ＭＬＳ待って、Ｔ
ＩＭＡ ＷＡＩＴ状態からＣＬＯＳＥＤ状態に遷移す
る。 ・サーバはＳ１４に応じてＬＡＳＴ＿ＡＣＫ状態からＣ
ＬＯＳＥＤ状態に遷移する。

【００１２】次に、代表的なＴＣＰ／ＩＰのアプリケー
ション、特に、そのセッション層について説明する。Ｆ
ＴＰ（File Transfer Protocol）は、異なるコンピュー
タの間（クライアントとサーバの間）でファイルを転送
するプロトコルである。詳細はＲＦＣ９５９に示されて
いる。ＦＴＰでは２本のＴＣＰコネクションが利用され
る。１つは制御用で、もう１つはデータ転送用である。
制御用のＴＣＰコネクションはＦＴＰの制御に利用され
る。ログインのためのユーザ名やパスワード認証の確認
や転送するファイルや転送の方向の指示に利用される。
これはポート番号２１が利用される。データ転送用のＴ
ＣＰコネクションはＦＴＰのデータ転送に利用される。
制御用ＴＣＰコネクションで、ファイルの取得ＧＥＴや
授与ＰＵＴ、ファイルの一覧表の取得ＬＩＳＴが実行さ
れると、その度にデータ転送用のＴＣＰコネクションが
確立され、データが転送され、切断される。そしてま
た、制御用のコネクションを利用して、コマンドや応答
の通信が行われる。データ転送用のＴＣＰコネクション
はポート番号２０が利用される。ＦＴＰセッションは、
これら２本のＴＣＰを束ねた概念として明示的である。

【００１３】ＷＷＷ（World Wide Web）はインターネッ
ト上の情報をハイパーテキストのような形式で参照でき
る情報提供システムである。ＷＷＷの情報を画面に表示
するクライアントソフトウェアのＷｅｂブラウザを利用
すると、利用者はデータが実際にどこのサーバにあるか
を意識せずに、マウスをクリックするだけで関連する様
々な情報を次々に閲覧することができる。ＷＷＷのプロ
トコルはＨＴＴＰ（Hyper Text Transport Protocol）
で、その詳細はＲＦＣ２６１６に示されている（ＨＴＴ
Ｐ／１．１）。ＨＴＴＰでは通常８０番のポート番号が
利用される。以下、８０番を代表値として説明する。利
用者が画面からハイパーテキストをクリックすると、ク
ライアントソフトウェアからサーバにポート番号８０で
ＴＣＰコネクションを確立し、要求コマンドの送信が行
われる。

【００１４】セッション層の機能を実現するものは明示
的ではない。なお、ＨＴＴＰの仕様は数回改版されてい
る。ＨＴＴＰ／１．０までは持続性のあるＴＣＰコネク
ションを使用できなかったため、ＨＴＴＰセッションは
複数のＴＣＰコネクションを束ねた概念である。ＨＴＴ
Ｐ／１．１では持続性のあるＴＣＰコネクションが使え
るようになったので、ＨＴＴＰセッションはＴＣＰコネ
クションと等価と考えることができる。

【００１５】電子メールの場合、通常ＴＣＰコネクショ
ンが使われ、サーバ間の配送プロトコルはＳＭＴＰ（Si
mple Mail Transfer Protocol）が使われている。ポー
ト番号は２５で、詳細はＲＦＣ２８２１に示されてい
る。サーバとクライアント間の配送プロトコルはＰＯＰ
３（Post Office Protocol-Version 3）が使われてい
る。ポート番号は１１０で、詳細はＲＦＣ１９３９に示
されている。送信できるデータ形式を拡張するＭＩＭＥ
（Multipurpose Internet Mail Extensions）により、
テキスト形式だけでなく、映像や音声のファイル、文字
の大きさや色の指定など、さまざまな情報を送ることが
できる。このＭＩＭＥはプレゼンテーション層のプロト
コルと言える。セッション層の機能を実現するものは明
示的ではないが、ＴＣＰコネクションと等価と考えるこ
とができる。

【００１６】ＶｏＩＰ（Voiceover IP）の場合、プレゼ
ンテーション層の機能として、実時間性を確保するため
のプロトコルＲＴＰ（Real-time Transport Protocol）
や装置ＣＯＤＥＣ（Coder/Decoder）に実装された音声
や映像の圧縮符号化方式が挙げられる。ＲＴＰのトラン
スポート層にはＵＤＰが使われる。ＲＴＰの詳細はＲＦ
Ｃ１８８９に示されている。また、端末間の通信制御機
能と端末とサーバ間の通信機能のためにＳＩＰ（Sessio
n Initiation Protcol）またはＨ．３２３が使われるこ
とがある。ＳＩＰのポート番号は５０６０である。ＳＩ
ＰやＨ．３２３はセッション層の機能を担っている。Ｓ
ＩＰの詳細はＲＦＣ２５４３に示されている。Ｈ．３２
３のうち、セッション層の記述は通信制御を扱ったＨ．
２４５と呼制御を扱ったＨ．２２５．０に詳細が示され
ている。ＳＩＰのトランスポート層にはＵＤＰが使わ
れ、Ｈ．３２３にはＴＣＰコネクションが使われる。

【００１７】以上、代表的なＴＣＰ／ＩＰアプリケーシ
ョンにおけるＯＳＩ参照モデルのセッション層、プレゼ
ンテーション層、アプリケーション層に相当する機能を
見てきた。プロトコルの観点からは、セッション層の機
能が明示的あるいは非明示的のいずれにせよ、ＴＣＰ／
ＩＰアプリケーションにおいても含まれている。

【００１８】通信網のトラヒック業務について説明す
る。通信網のトラヒック業務の分類例として、測定・監
視・制御・管理・予測・設計を挙げる。図３にその階層
を示す。測定業務は、それ以外の各業務の基盤として、
当該業務の目的に応じたトラヒックデータの測定を行な
う。測定に関する項目や周期や集約方法に技術的ノウハ
ウがある。図の左右は測定データの周期長を表してい
て、左側ほど短周期であり、右側ほど長周期である。具
体的には、監視・制御の業務は分秒単位で措置を行なう
必要があり、管理・予測業務はそれより長い月単位で措
置を行なう必要がある。設計業務は更に長い年周期で措
置を行なうが、監視・制御の業務や管理・予測の業務に
よって得られた結果もデータとして使用する。

【００１９】監視業務は、測定したデータから異常な状
態であることを把握する業務であり、制御業務は監視業
務で得た結果をデータとして適切な状態に戻るような措
置を施す業務である。管理業務は、測定したデータから
正常な状態が継続していることを把握する業務である。
予測業務は、管理業務で得たデータや外部要因からのデ
ータを元に需要を予測する業務である。設計業務は、制
御業務や管理業務や予測業務で得られたデータを元に、
年単位先を念頭にネットワークの構成やリソース量を設
計する業務である。

【００２０】ＴＣＰ／ＩＰアプリケーションに対するト
ラヒック業務について説明する。測定業務は、前述の通
り測定項目がパケット数やバイト数が基本になってい
る．これらの測定項目は、インターネット層の測定デー
タであり、ＴＣＰ／ＩＰアプリケーションの区別がな
い。測定以外の業務の基礎データとして使われるので、
アプリケーション別に目的を持った措置を行なうために
は、アプリケーション別ではない測定項目が基本になっ
ていることは重大な支障を来す。

【００２１】測定業務は、ネットワーク管理用のプロト
コルＳＮＭＰ（Simple Network Management Protocol）
によりＭＩＢ（Management Information Base）と呼ば
れるデータベースの値を見ることが多い。ＭＩＢの一種
にＲＭＯＮ（Remote Monitoring MIB）がある。ＳＮＭ
Ｐ／ＭＩＢがネットワーク・ノードのインターフェース
（点）に関する情報を測定するように構成されているの
に対して、ＭＩＢから派生して定義されたＲＭＯＮは接
続されるネットワークのリンク（線）に関する情報を測
定するように構成されている。なお、ＴＣＰ／ＩＰアプ
リケーションの機能としてＯＳＩ参照モデルに当てはめ
ると、アプリケーション層の機能がＳＮＭＰで、プレゼ
ンテーション層の機能がＭＩＢやＲＭＯＮと言える。

【００２２】ＲＭＯＮを含めたＭＩＢを測定データとし
た各トラヒック業務を行なうことには幾つかの課題があ
る。各業務の目的に照らして必要な測定項目が定義され
ているとは限らない課題や、ＭＩＢデータを取得するこ
とによるノードに与える負荷の課題や、ＭＩＢデータを
転送することによるリンクに与える負荷の課題などがあ
る。

【００２３】

【発明が解決しようとする課題】本発明の目的は、パケ
ット交換網のトラヒック特性を効率的に理解する課題を
解決したトラヒックの測定、監視、制御、管理、予測、
または、設計の方法を提供することにあり、更に、その
方法を実施するノードや外付け装置を提供することにあ
る。

【００２４】

【課題を解決するための手段】本発明は、ＴＣＰ／ＩＰ
プロトコルのトラヒック特性がアプリケーション別セッ
ション数で特徴づけられる点に着目してなされたもので
あり、請求項１に記載された本発明によるトラヒックの
測定、監視、制御、管理、予測、または、設計の方法
は、端末とノードとリンクから構成されるパケット交換
網において、端末で生成されるＴＣＰ／ＩＰプロトコル
によるパケットのトラヒックに対し、ノード間の各リン
クにおけるトラヒックを、ＴＣＰ／ＩＰプロトコルのセ
ッション層で区別し、且つ、アプリケーション層でアプ
リケーション別にセッションを計数する第１のステップ
（アプリケーション別セッション計数法）を備えること
を第１の特徴とし、アプリケーション別に予め定めた分
析方法を用いて上記のアプリケーション別セッションの
計数結果を分析する第２のステップ（アプリケーション
別セッショントラヒック分析法）を備えることを第２の
特徴とする。

【００２５】上述した本発明方法は、第１の特徴とし
て、従来の技術とは、セッション層のデータでトラヒッ
ク測定を行なう点およびアプリケーション別にセッショ
ン層のトラヒックデータを測定する点が異なり、第２の
特徴として、このような測定データをアプリケーション
別に定めた分析方法で分析する点が異なる。

【００２６】請求項２に記載された本発明の方法では、
複数のアプリケーションを１つの集合としてアプリケー
ションの集合別にセッションを計数すること（アプリケ
ーション群別セッション計数法）、および該集合に対し
て予め定めた分析方法を用いて分析すること（アプリケ
ーション群別セッショントラヒック分析法）を特徴とす
る。この方法は、従来技術とは、いくつかのＴＣＰ／Ｉ
Ｐアプリケーションを集約した単位でトラヒック測定を
行なう点およびその単位別にセッション層のトラヒック
データを測定する点が異なり、更に、このような測定デ
ータをその単位別に予め定めた分析方法で分析する点が
異なる。

【００２７】本発明は、更に、上述した方法を実施する
パケット交換網のノードを提供し、請求項９に記載され
た本発明のノードは、ノードを通過するＩＰプロトコル
のパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルの
セッション層で区別し、且つ、アプリケーション層でア
プリケーション別にセッションを計数する第１の手段
と、アプリケーション別に予め定めた分析方法を用いて
上の計数結果を分析する第２の手段とを備えることを特
徴とする。

【００２８】本発明は、更に、パケット交換網のリンク
に接続され、上述の方法を実施するパッシブ型の測定装
置を提供し、請求項１０に記載された本発明の測定装置
は、リンクを通過するＩＰプロトコルのパケットのトラ
ヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区
別し、且つ、アプリケーション層でアプリケーション別
にセッションを計数する第１の手段と、 アプリケーシ
ョン別に予め定めた分析方法を用いて上の計数結果を分
析する第２の手段を備えることを特徴とする。

【００２９】

【作用】請求項１に述べたアプリケーション別セッショ
ン計数法は、ＴＣＰ／ＩＰプロトコルのトラヒックをセ
ッション層で測定することで測定データを削減する効果
が生じ、アプリケーション別にセッション数を計数する
ことで測定項目を削減する効果が生じ、アプリケーショ
ン別セッショントラヒック分析法は、予め個々に定めた
アプリケーション別のトラヒック特性を基本データにす
ることで精度高く分析する効果が生じる。請求項２に述
べたアプリケーション群別セッション計数法は、予め同
じまたは類似のトラヒック特性を持つと分かっているア
プリケーションを群として扱うことで測定項目を削減す
る効果が生じ、群として扱ったアプリケーション間の相
互作用が相殺されることで精度高く分析する効果が生じ
る。請求項３に述べたノードは、ＴＣＰ／ＩＰプロトコ
ルのトラヒックを転送しつつ、直接的にそのトラヒック
の測定、監視、制御、管理、予測、または設計の業務を
提供する効果が生じる。直接的であるため、得られた結
果の応用が可能になる効果が生じる。請求項４に述べた
リンクに付随するパッシプ型測定装置は、ＴＣＰ／ＩＰ
プロトコルのトラヒックを転送しつつ、間接的にそのト
ラヒックの測定、監視、制御、管理、予測、または設計
の業務を提供する効果が生じる。間接的であるため、結
果を得るための負荷をノードに与えない効果がある。

【００３０】

【発明の実施の形態】

【実施例１】本発明によるアプリケーション別のセッシ
ョン数の測定方法について説明する。図４は、実施例１
の構成図である。端末をＣ/Ｓ−０１，０２，…，０
ｎ，１１，１２，…，１ｎで示し、ノードをＮ０，Ｎｌ
で示し、ノードＮ０とＮｌを結ぶリンクをＬで示す。端
末は一つのノードとリンクで結ばれている（記号は省略
する）。リンクＬに付随するパッシブ型のトラヒック測
定装置をＰで示す。リンクＬを転送されるトラヒックは
分岐装置（・）で信号線Ｓに分岐されて測定装置Ｐに流
れるが、パッシプ型なので測定装置ＰからリンクＬの向
きには流れない。図４は、送信も受信も同一のデータリ
ンク層の回線を用いる場合の構成図である。

【００３１】送信と受信を異なるデータリンク層の回線
を用いる場合の構成図を図５に示す。リンクＬ０−１は
ノードＮ０が送信し、ノードＮｌが受信する回線であ
り、リンクＬｌ−０はノードＮｌが送信し、ノードＮ０
が受信する回線である。また、信号線Ｓ０−１とＳ１−
０は、それぞれリンクＬ０−１とＬｌ−０に流れるデー
タをスヌープ（snoop）する。どちらも、測定装置Ｐが
受信する。

【００３２】測定装置Ｐが測定したデータを蓄積するテ
ーブル表２に示す。

【表２】 レコードＲ１１，Ｒ２１．．．はアプリケーションを識
別するレコードＡＰｌ，ＡＰ２，．．．で、レコードＲ
１２，Ｒ２２，．．．はそれぞれアプリケーションＡＰ
ｌ，ＡＰ２，．．．のセッション確立数を蓄積するレコ
ードＡｌ，Ａ２，．．．で、レコードＲ１３，Ｒ２
３，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ
２，．．．のセッション終了数を蓄積するレコードＤ
ｌ，Ｄ２，．．．で、レコードＲ１４，Ｒ２４，．．．
はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．の
同時接続セッション数を蓄積するレコードＣｌ，Ｃ２，
…で、レコードＲ１４，Ｒ２４，．．．はそれぞれアプ
リケーションＡＰｌ，ＡＰ２，．．．に対するセッショ
ントラヒック分析結果（例として、帯域）を蓄積するレ
コードＢｌ，Ｂ２，．．．である。このテーブルを時系
列で蓄積する。

【００３３】表２のレコードＲ１２，Ｒ２２，．．．；
Ｒ１３，Ｒ２３，．．．を定める方法を説明する。 （１）アプリケーションＡＰがＴＣＰコネクションを用
いる場合 （ａ）単一のコネクションを使う場合 例：ＨＴＴＰ/１．１（８０）、ＳＭＴＰ（２５）、Ｐ
ＯＰ３（１１０）、ＳＮＭＰ（１６１） 方法：アプリケーションＡＰのセッションの確立と終了
を、当該アプリケーションを特定するポート番号（カツ
コ内の数字）のＴＣＰコネクションの確立と終了で定義
する。測定装置は、該当セグメントの検知によりトラヒ
ックを測定する。 （ｂ）複数のコネクションを同時に使う場合 例：ＦＴＰ（２０，２１） 方法：アプリケーションＡＰのセッションの確立と終了
を、当該アプリケーションの使用方法に応じて別途定め
る。ＦＴＰの場合は、ポート番号２０のＴＣＰコネクシ
ョンの確立と終了で定義する。測定装置は、該当セグメ
ントの検知によりトラヒックを測定する。 （ｃ）複数のコネクションを断続的に使う場合 例：ＨＴＴＰ／１．０（８０） 方法：アプリケーションＡＰのセッションの確立と終了
を、当該アプリケーションの使用方法に応じて別途定め
る。ＨＴＴＰ／１．０の場合、ポート番号（デフォルト
では８０番）のＴＣＰコネクションの確立と終了が断続
することから、ＴＣＰコネクションの終了後予め定めた
短時間のうちに再度確立される場合はセッションの終了
とせず、また、ＴＣＰコネクションの終了後予め定めた
時間のうちに再度確立されない場合に遡ってセッション
の終了とする。測定装置は、該当セグメントの検知によ
りトラヒックを測定する。

【００３４】（２）アプリケーションＡＰがＵＤＰを用
いる場合 例：ＶｏＩＰ 方法：アプリケーションＡＰのセッションの確立と終了
を、当該アプリケーションの使用方法に応じて別途定め
る。特にアプリケーションを制御するＵＤＰの上位プロ
トコル（例えばＳＩＰ）または別途確立するＴＣＰコネ
クションを用いた制御プロトコル（例えばＨ．２４５や
Ｈ．２２５．０）のセグメントによって定義する。測定
装置は、該当セグメントの検知によりトラヒックを測定
する。

【００３５】従来の技術の説明で、ＴＣＰコネクション
の状態遷移と事象シーケンス図を示した。上記のアプリ
ケーション別セッション計数法において、ＴＣＰをトラ
ンスポート層に用いるアプリケーションに対して、セッ
ションの確立と終了をＴＣＰコネクションが通信状態に
あることで定義した。通信状態にあることの認識は、デ
ータリンク層の使用方法に応じて２通りある。 （１）図５の場合（１本のデータリンク層の回線で両方
向の通信） ＴＣＰコネクションの確立をセグメントＳ０３で認識
し、終了をセグメントＳｌｌで認識する。 （２）図６の場合（２本のデータリンク層の回線で方向
別の通信） ＴＣＰコネクションの確立と終了を次のセグメントに変
更して定義する。 （Ｃ−Ｓ）クライアントからサーバヘの回線について
は、ＴＣＰコネクションの確立をセグメントＳ０３で認
識し、終了をセグメントＳｌｌで認識する。また、（Ｓ
−Ｃ）サーバからクライアントヘの回線については、確
立をセグメントＳ０２で認識し、終了をセグメントＳ１
２で認識する。なお、２本のデータリンク層の回線を使
っていても、測定装置Ｐで測定データを統合して分析で
きるならば、上のような認識方法の変更は不要で、１本
の場合と同様に処理することができる。

【００３６】ＵＤＰを用いるアプリケーションについて
も、その上位プロトコルまたは別途確立するＴＣＰコネ
クションを用いた制御プロトコルについて、特定のセグ
メントを検出することによりアプリケーションのセッシ
ョンの確立と終了を定義する。定義の方法は、ＴＣＰコ
ネクションと同様に、通信状態になる直前と直後のセグ
メントを用いる。

【００３７】以上、測定装置がリンクに付随するパッシ
ブ型の場合で説明した。クライアントとサーバの間のノ
ードにおいて測定する場合も同様に前述のセグメントに
よりコネクションの確立と終了を認識する実装が容易に
行える。

【００３８】次に、アプリケーション別セッショントラ
ヒック分析法を説明する。即ち、表２のレコードＲ１
５，Ｒ２５，…を定める方法であり、アプリケーション
ＡＰ別に同時接続セッション数Ｃの所要帯域関数Ｆをト
ラヒック業務の目的別に定めることである。特に、図６
に示したグラフのように、関数Ｆが変数Ｃに関して単調
増加、または上に凸の特性を持つように定めることで、
ネットワーク資源を効率的に利用できる効果が得られ
る。即ち、多数のセッション数を多重することで、セッ
ション１本あたりに必要となる帯域Ｂが少なくて済むよ
うになる。

【００３９】以上のように、アプリケーション別セッシ
ョン数の測定方法を説明し、その測定結果を基に分析す
る方法と効果を述べた。次に、このような測定方法によ
って、簡易に適切な分析が可能になる理由を説明する。
パケット通信におけるトラヒックは、アプリケーション
によって特性が大きく異なることに着目する。このトラ
ヒックの基本単位は、前述のように、パケットやバイト
であるが、アプリケーションによって、パケットの発生
間隔やバイト数は、明らかに異なる特性を示す。例えば
ＶｏＩＰの場合、ＣＯＤＥＣに応じてパケットが、基本
的には一定間隔、一定長で生成される。ただし、無音圧
縮を行う場合は間隔が長くなることが確率的に発生し、
実時間制御のためのプロトコル仕様に応じて制御パケッ
トが割り込み、間隔が詰まったり、異なる長さのパケッ
トが混入する。ＦＴＰやＨＴＴＰは、転送するファイル
サイズと転送可能な最大パケット長が主な要因になって
特徴が定まる。即ち、パケット通信におけるトラヒック
は、アプリケーション別に各セッションのパケット発生
間隔やパケット長の統計的観点あるいはプロトコル仕様
の観点から特徴づけられ、同一アプリケーションのトラ
ヒックはセッション数の関数で記述することが可能であ
る。この特徴づけとこの関数の特定が十分な精度で行わ
れれば、パケットやバイト単位の測定を行わずとも、セ
ッション数を測定することにより同一アプリケーション
全体のトラヒック特性を理解することができる。このほ
うが測定の負担は非常に軽く、且つ、妥当である。

【００４０】もし、複数のアプリケーションに対して同
一あるいは類似のトラヒック特性であると分かれば、そ
れらのアプリケーションをグループ化して扱うことで、
測定項目を削減する効果がある。これにより測定データ
の蓄積量を削減する効果もある。

【００４１】以上の説明は、パッシブ型の測定装置Ｐで
説明したが、ノードＮ０またはＮ１が測定機能を持つこ
とも可能である。パッシブ型測定装置Ｐが測定すること
による長所は、測定行為がトラヒックに影響を与えない
点であるが、一方で、分析結果を各トラヒック業務で直
接的に活用できない短所がある。ノードＮ０またはＮ１
で測定することの長所は、パッシブ型測定装置Ｐによる
測定の短所を改善する効果がある。しかしながら、ノー
ドはパケット転送をインターネット層で行っているの
で、トランスポート層以上の測定も行うことは負荷を高
める悪影響がある。このようにパッシプ型測定装置とノ
ードのどちらにも長所と短所があるので、測定を行うの
がどちらが適切かは一概に言えない。

【００４２】〔実施例２〕様々なトラヒック業務での応
用例を説明する。まず、監視業務に適用した例を説明す
る。電話サービスにおいては、発呼数や同時接続回線数
に基づいて監視業務が行われている。ＴＣＰ／ＩＰアプ
リケーションに対しては、アプリケーション別のセッシ
ョンに対して同様の測定データがあれば、同様の業務を
展開することが可能である。表２のアプリケーション別
のセッション確立数Ｒ１２，Ｒ２２，．．．や同時接続
セッション数Ｒ１４，Ｒ２４，．．．の時系列データを
監視し、次のような分析を行うことで、異常な状態であ
るかどうかを把握する。 （１）ノードやリンクの処理能力を超えると予想される
ぼどの急激な増加傾向 （２）ノードやリンクの処理能力を超える増加事象

【００４３】制御業務に適用した例を説明する。電話サ
ービスにおいては、輻輳制御として行われている業務で
ある。ＴＣＰ／ＩＰアプリケーションに対しては、アプ
リケーション別のセッションに対して同様の測定データ
があれば、同様の業務を展開することが可能である。監
視業務で述べた異常状態を把握した場合など、表２のア
プリケーション別のセッション確立数について、一定間
隔において一定率を上限に受付ける、あるいは、一定間
隔において一定数を上限に受付ける制限を予め定め、測
定装置においてこれらの制限値を越えたかどうかを分析
し、ノードに通知する。通知を受けたノードは制限を実
行することができる。

【００４４】管理業務に適用した例を説明する。表２の
アプリケーション別の同時接続セッション数Ｒ１４，Ｒ
２４，…の時系列データを基に、次のような分析を行う
ことで、ネットワーク資源とトラヒック量の過不足を把
握する。 （１）上記の１時間毎の時系列データの日毎最繁値につ
いて、年間上位３０個の平均値を基に、品質を保証する
のに必要な帯域を求める関数Ｆｌを用いて、現在のリン
クの帯域と比較する。 （２）上記の１時間毎の時系列データの日毎最繁値につ
いて、連続平日２０個の最大値を基に、品質を保証する
のに必要な帯域を求める関数Ｆ２を用いて、現在のリン
クの帯域と比較する。

【００４５】予測業務に適用した例を説明する．表２の
アプリケーション別の同時接続セッション数Ｒ１４，Ｒ
２４，．．．の時系列データを基に、次のような周知の
時系列データの統計分析手法を用いて分析を行うこと
で、アプリケーション別のトラヒック需要の予測を行
う。 （１）変動特性、例えば日変動、週変動、月変動、年変
動を把握する。 （２）トレンド特性を把握する。

【００４６】設計業務に適用した例を説明する。管理業
務で述べた必要帯域に、予測業務で述べた変動特性とト
レンド特性を加味し、ネットワーク（ここではリンクの
帯域）の設計値を算出する。

【００４７】

【発明の効果】以上説明したように、ＴＣＰ／ＩＰアプ
リケーションのトラヒックについて、そのセッション数
をアプリケーション別に測定することからパケット交換
網のトラヒック特性を効率的に理解する効果があり、ア
プリケーション別セッション数のデータとアプリケーシ
ョン別トラヒック特性から通信網の監視、制御、管理、
予測、または、設計の方法を効率的に提供する効果があ
る。更に、その方法を実施するルータや外付け装置を簡
単且つ安価に提供する効果がある。

【図面の簡単な説明】

【図１】 ＴＰＣコネクションの確立と終了に対応する
事象シーケンス図を示す。

【図２】 ＴＣＰコネクションの確立と終了に対応する
状態遷移ダイアグラムを示す。

【図３】 トラヒック業務の階層構造を示す図である。

【図４】 本発明の第１の実施例の構成図である。

【図５】 本発明の第２の実施例の構成図である。

【図６】 ネットワーク資源の効率的使用のために必要
な帯域Ｂを同時接続セッション数Ｃの関数として示す図
である。

【符号の説明】

Ｃ/Ｓ−０１，０２，…，０ｎ，１１，１２，…，１ｎ
端末 Ｎ０，Ｎｌ ノード Ｌ；Ｌ０−１，Ｌｌ−０ リンク Ｓ；Ｓ０−１，Ｓ１−０ 信号線

───────────────────────────────────────────────────── フロントページの続き (72)発明者 大原 久樹 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B089 HA04 HB02 HB12 HB18 JA35 KA05 MA07 MC02 5K030 GA11 HA08 JA10 LC09 LE16 MA04 MB09 MC08

Claims (14)

【特許請求の範囲】
1. 【請求項１】 端末とノードとリンクから構成されるパ
   ケット交換網において、 端末で生成されるＴＣＰ／ＩＰプロトコルによるパケッ
   トのトラヒックについて、 ノード間の各リンクにおけるトラヒックを、ＴＣＰ／Ｉ
   Ｐプロトコルのセッション層で区別し、且つ、アプリケ
   ーション層でアプリケーション別にセッションを計数す
   る第１のステップと、 アプリケーション別に予め定めた分析方法を用いて上の
   計数結果を分析する第２のステップと、を備えることを
   特徴とするトラヒックの測定、監視、制御、管理、予
   測、または、設計の方法。
2. 【請求項２】 前記計数ステップにおいて、複数のアプ
   リケーションを１つの集合としてアプリケーションの集
   合別にセッションを計数し、 第２のステップにおいて、該集合に対して予め定めた分
   析方法用いて分析することを特徴とする請求項１記載の
   方法。
3. 【請求項３】 第１のステップにおいて、アプリケーシ
   ョン別またはアプリケーション集合別にセッション確立
   数、セッション終了数、及び/又は同時接続セッション
   数を時系列に計測することを特徴とする請求項１又は２
   記載の方法。
4. 【請求項４】 第２のステップにおいて、アプリケーシ
   ョン別またはアプリケーション集合別のセッション確立
   数や同時接続セッション数の時系列データを監視し、次
   の分析： （１）ノードやリンクの処理能力を超えると予想される
   ほどの急激な増加傾向 （２）ノードやリンクの処理能力を超える増加事象 を行うことで、異常な状態であるかどうかを把握するこ
   とを特徴とする請求項３に記載の方法。
5. 【請求項５】 第２のステップにおいて、アプリケーシ
   ョン別またはアプリケーション集合別のセッション確立
   数について、一定間隔において一定率を上限に受付け
   る、あるいは、一定間隔において一定数を上限に受付け
   る制限を予め定め、これらの制限値を越えたかどうかを
   分析し、ノードにて制限を実行することを特徴とする請
   求項３に記載の方法。
6. 【請求項６】 第２のステップにおいて、アプリケーシ
   ョン別またはアプリケーション集合別の同時接続セッシ
   ョン数の時系列データを基いて、次の分析： （１）上記の１時間毎の時系列データの日毎最繁値につ
   いて、年間上位数十個の平均値を基に、品質を保証する
   のに必要な帯域を求める関数を用いて、現在のリンクの
   帯域と比較する分析、（２）上記の１時間毎の時系列デ
   ータの日毎最繁値について、連続平日数十個の最大値を
   基に、品質を保証するのに必要な帯域を求める関数を用
   いて、現在のリンクの帯域と比較する分析、を行うこと
   で、ネットワーク資源とトラヒック量の過不足を把握す
   ることを特徴とする請求項３に記載の方法。
7. 【請求項７】 第２のステップにおいて、アプリケーシ
   ョン別またはアプリケーション集合別の同時接続セッシ
   ョン数の時系列データを統計的に分析して、 （１）日、週、月または年単位の変動特性 （２）トレンド特性 を把握することで、アプリケーション別またはアプリケ
   ーション集合別のトラヒック需要の予測を行うことを特
   徴とする請求項３の何れかに記載の方法。
8. 【請求項８】 請求項６に記載の必要帯域に、請求項７
   に記載の変動特性とトレンド特性を加味し、リンクの帯
   域の設計値を算出することを特徴とする請求項３に記載
   の方法。
9. 【請求項９】 請求項１〜８の何れかに記載の方法を実
   施するパケット交換網のノードにおいて、 該ノードを通過するＩＰプロトコルのパケットのトラヒ
   ックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別
   し、且つ、アプリケーション層でアプリケーション別、
   あるいは、アプリケーションの集合別にセッションを計
   数する第１の手段と、アプリケーション別、あるいは、
   アプリケーションの集合別に予め定めた分析方法を用い
   て上の計数結果を分析する第２の手段と、を備えること
   を特徴とするノード。
10. 【請求項１０】 パケット交換網のリンクに接続され、
    請求項１〜８の何れかに記載の方法を実施するパッシブ
    型の測定装置において、 該リンクを通過するＩＰプロトコルのパケットのトラヒ
    ックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別
    し、且つ、アプリケーション層でアプリケーション別、
    あるいは、アプリケーションの集合別にセッションを計
    数する第１の手段と、アプリケーション別、あるいは、
    アプリケーションの集合別に予め定めた分析方法を用い
    て上の計数結果を分析する第２の手段、を備えることを
    特徴とする測定装置。
11. 【請求項１１】 端末とノードとリンクから構成される
    パケット交換網において、 端末で生成されるＴＣＰ／ＩＰプロトコルによるパケッ
    トのトラヒックについて、 ノード間の各リンクにおけるトラヒックを、ＴＣＰ／Ｉ
    Ｐプロトコルのセッション層で区別し、且つ、アプリケ
    ーション層でアプリケーション別にセッションを計数す
    ることを特徴とするＩＰトラヒックの測定方法。
12. 【請求項１２】 アプリケーション別にセッションを計
    数するに当たり、複数のアプリケーションを１つの集合
    としてアプリケーションの集合別にセッションを計数す
    ることを特徴とする請求項１１記載の方法。
13. 【請求項１３】 パケット交換網のノードにおいて、該
    ノードを通過するＩＰプロトコルのパケットのトラヒッ
    クを、ＴＣＰ／ＩＰプロトコルのセッション層で区別
    し、且つ、アプリケーション層でアプリケーション別に
    セッションを計数する手段を備えるノード。
14. 【請求項１４】 パケット交換網のリンクに付随する測
    定装置において、該リンクを通過するＩＰパケットのト
    ラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で
    区別し、且つ、アプリケーション層でアプリケーション
    別にセッションを計数することを特徴とする測定装置。