JP3725462B2 - Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 - Google Patents
Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 Download PDFInfo
- Publication number
- JP3725462B2 JP3725462B2 JP2001313374A JP2001313374A JP3725462B2 JP 3725462 B2 JP3725462 B2 JP 3725462B2 JP 2001313374 A JP2001313374 A JP 2001313374A JP 2001313374 A JP2001313374 A JP 2001313374A JP 3725462 B2 JP3725462 B2 JP 3725462B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- traffic
- protocol
- tcp
- session
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、パケット交換網におけるトラヒック特性を効率的に理解する方法と、その方法を実施するノード及び外付け装置に関するものである。パケット通信網としては、例えば、ＴＣＰ／ＩＰプロトコルを用いるインターネットが挙げられる。また、トラヒック特性を理解することによって解決される技術分野としては、トラヒックの測定、監視、制御、管理、予測、設計などが挙げられる。
【０００２】
【従来の技術】
周知のように、通信サービスは、ネットワークを介して物理的・地理的な距離の隔たりを解消させることで、社会・経済活動に掛け替えのない生活基盤（ライフライン）になっているので、短時間であってもサービスが停滞することは容認されない。通信ネットワークに流れる情報量は増加の一途を辿っていて、その情報を迅速かつ確実に伝達することは社会からの要請である。通信事業者は、顧客の満足に適った通信サービスを提供するために、通信ネットワークの基本的な機能と性能を測定し、監視し、制御し、管理し、更に、必要なリソースを設計することで、効率のよい設備の構築、的確な運用、コストの低廉化を実施する必要がある。
【０００３】
通信システムの性能は、通信サービスの情報量、即ち、トラヒック（traffic）で表現される。
この「トラヒック」という単語は、交通や運輸の分野においても交通量や運輸量として、方向性を持った量の意味で使われている。通信の分野でのトラヒックは、電話・電報・データ・画像などの通信の交流や構造を意味していて、特に電話においては「通信設備によって運ばれる呼（call）」が基本単位になっている。また、パケット通信においては、従来、パケット（packet）やバイト（byte）が基本単位になっている．非同期転送モード（ATM,Asynchronous Transfer Mode）での通信では、セル（cell）が基本単位になっている。
【０００４】
一般の商品が、数量・品質・価格・売れ具合などを生産・流通・販売の過程で把握し管理する必要があるように、通信の分野では、業務の目的に合わせてトラヒックを的確に把握・管理する必要がある。これを通信網のトラヒック業務と呼ぶ。電話においては、呼を測定し、同時接続中の呼数を管理することで、トラヒックの把握や管理が可能であった。パケット通信においては、パケット数やバイト数を測定し管理することで、ある程度のトラヒックの把握や管理が可能であった。ＡＴＭにおいてはセル数を測定する方法もあるが、セル送信バッファの待ち行列しきい値を超過する回数も測定することで、トラヒックの把握や管理が可能であった。
【０００５】
近年、インターネットが普及し、ＴＣＰ／ＩＰアプリケーションの観点からトラヒックの把握を行なうことで、トラヒック特性を効率的に理解する方法が求められている。ＴＣＰ／ＩＰの下位プロトコルとしてＡＴＭが用いられることがある。上述のセルレベルの測定に基づく技術はセルレベルのトラヒックを把握することに適用する技術であって、階層の異なるＴＣＰ／ＩＰアプリケーションの観点からは直接的ではない。
【０００６】
次に上記の階層について説明する。通信プロトコルは階層モデルが適用される。国際標準化機構（ISO,International Organizationfor Standardization）は、通信の国際標準として開放型システム相互間接続（OSI,Open System International）という通信プロトコルの標準化を目指すにあたり、通信プロトコルを設計する指標として、通信プロトコルの機能を７つの階層に分割するＯＳＩ参照モデルを提唱し、複雑になりがちな通信プロトコルを単純化することを目指した。ＯＳＩ参照モデルの各層の機能を表１の左側に示す。
【０００７】
【表１】
【０００８】
パケット交換網として代表的なインターネットにおける通信プロトコルは、ＴＣＰ／ＩＰと呼ばれる。ＯＳＩ参照モデルとの対応と共にＴＣＰ／ＩＰの階層モデルを表１の右側に示す。両者に違いがあるのは、ＯＳＩ参照モデルが、腑撤的にモデル化されたのに対して、ＴＣＰ／ＩＰの階層モデルはプロトコルの実装の観点からモデル化されたためである。ＯＳＩ参照モデルに当てはめると、その構造は第５〜７層がアプリケーション層に統合されている特徴がある。実装の観点からは、単一のアプリケーションの内部で第５〜７層それぞれの機能が実現される場合もあるし、複数のアプリケーションに分けて実装される場合もある。ＴＣＰ／ＩＰのアプリケーションプログラムの機能を詳細に見ていくと、ＯＳＩ参照モデルの第５〜７層のそれぞれの機能が見えてくる。その説明の前に、両方のモデルに共通するトランスポート層のプロトコルについて説明する。
【０００９】
トランスポート層のプロトコルにはＵＤＰ（User Datagram Protocol）とＴＣＰ（Transmission Control Protocol）がある。ＵＤＰはコネクションを確立せずに通信を開始できる軽量なプロトコルである。ＵＤＰについては、ＲＦＣ７６８に示されている。信頼性が必要な場合はＵＤＰよりも上位のプロトコルでそれを提供する。一方、ＴＣＰはコネクションを確立してから通信するので、信頼性を提供することができるプロトコルである。ＴＣＰについては、ＲＦＣ７９３に示されている。図１にＴＣＰコネクションの確立と終了に対応する事象シーケンス図を示し、図２に通常の状態遷移ダイアグラムを示す。ただし、説明の簡単のために通常の場合のみに限定している。
【００１０】
ＴＣＰコネクションを確立するステップについて説明する。ＴＣＰコネクションは２台の端末間のコネクションで、それぞれの端末のＩＰアドレスをヘッダーに指定されたパケットで通信する。
そのため、端末間のノードにおいて、このＩＰアドレスの組によって区別される。ＴＣＰコネクションの確立には次の３ステップを踏む。
１．要求側の端末（クライアントと呼ばれる）は、接続したい端末（サーバとよばれる）に、ポート番号（アプリケーションの識別子）とクライアントの初期シーケンス番号を指定したＳＹＮセグメントＳ０１を送る。
・クライアントはＳＹＮ−ＳＥＮＴ状態に遷移する。
２．サーバは、Ｓ０ｌに応じて、サーバ側の初期シーケンス番号を含む自分自身のＳＹＮセグメントＳ０２で応答する。また、これにはクライアントの初期シーケンス番号＋１のＡＣＫを含めて、クライアントのＳＹＮに確認応答する。
・サーバはＬＩＳＴＥＮ状態からＳＹＮ＿ＲＣＶＤ状態に遷移する。
３．クライアントは、Ｓ０２に応じて、サーバの初期シーケンス番号＋１のＡＣＫセグメントＳ０３で確認応答する。
・クライアントはＳＹＮ＿ＳＥＮＴ状態からＥＳＴＡＢＬＩＳＨＥＤ状態に遷移する。
・サーバはＡＣＫを受けてＥＳＴＡＢＬＩＳＨＥＤ状態に遷移する。
上記のステップは通常の場合であり、コネクションの確立に至らずタイムアウトした場合や、両端末から同時にコネクション確立要求があった場合などはこのステップには従わない。
【００１１】
ＴＣＰコネクションを終了するステップについて説明する。次の４ステップを踏む。
１．クライアントは、ＦＩＮセグメントＳｌｌをシーケンス番号とともに送る。
・クライアントはＥＳＴＡＢＬＩＳＩ正Ｄ状態からＦＩＮ ＷＡＩＴ １状態に遷移する。
２．サーバは、Ｓ１１に応じて、受取ったシーケンス番号＋１のＡＣＫセグメントＳ１２で確認応答する。サーバはアプリケーションにＴＣＰコネクションの終了を知らせる。そして、サーバはクライアントにＦＩＮセグメントＳ１３をシーケンス番号とともに送る。
・サーバはＥＳＴＡＢＬＩＳＨＥＤ状態からＣＬＯＳＥＤ＿ＷＡＩＴ状態に遷移する。
・サーバはアプリケーションヘの終了通知に応じてＣＬＯＳＥＤ＿ＷＡＩＴ状態からＬＡＳＴ＿ＡＣＫ状態に遷移する。
３．クライアントは、Ｓ１２とＳ１３に応じて、受取ったシーケンス番号＋１のＡＣＫセグメントＳ１４で確認応答する。
・クライアントはＳ１２に応じてＦＩＮ ＷＡＩＴ １状態からＦＩＮ ＷＡＩＴ ２に遷移する。
・クライアントはＳ１３に応じてＦＩＮ ＷＡＩＴ ２状態からＴＩＭＥ＿ ＷＡＩＴ状態に遷移する。
・クライアントは、予め定められた２ＭＬＳ待って、ＴＩＭＡ ＷＡＩＴ状態からＣＬＯＳＥＤ状態に遷移する。
・サーバはＳ１４に応じてＬＡＳＴ＿ＡＣＫ状態からＣＬＯＳＥＤ状態に遷移する。
【００１２】
次に、代表的なＴＣＰ／ＩＰのアプリケーション、特に、そのセッション層について説明する。
ＦＴＰ（File Transfer Protocol）は、異なるコンピュータの間（クライアントとサーバの間）でファイルを転送するプロトコルである。詳細はＲＦＣ９５９に示されている。ＦＴＰでは２本のＴＣＰコネクションが利用される。１つは制御用で、もう１つはデータ転送用である。制御用のＴＣＰコネクションはＦＴＰの制御に利用される。ログインのためのユーザ名やパスワード認証の確認や転送するファイルや転送の方向の指示に利用される。これはポート番号２１が利用される。データ転送用のＴＣＰコネクションはＦＴＰのデータ転送に利用される。制御用ＴＣＰコネクションで、ファイルの取得ＧＥＴや授与ＰＵＴ、ファイルの一覧表の取得ＬＩＳＴが実行されると、その度にデータ転送用のＴＣＰコネクションが確立され、データが転送され、切断される。そしてまた、制御用のコネクションを利用して、コマンドや応答の通信が行われる。データ転送用のＴＣＰコネクションはポート番号２０が利用される。ＦＴＰセッションは、これら２本のＴＣＰを束ねた概念として明示的である。
【００１３】
ＷＷＷ（World Wide Web）はインターネット上の情報をハイパーテキストのような形式で参照できる情報提供システムである。ＷＷＷの情報を画面に表示するクライアントソフトウェアのＷｅｂブラウザを利用すると、利用者はデータが実際にどこのサーバにあるかを意識せずに、マウスをクリックするだけで関連する様々な情報を次々に閲覧することができる。ＷＷＷのプロトコルはＨＴＴＰ（Hyper Text Transport Protocol）で、その詳細はＲＦＣ２６１６に示されている（ＨＴＴＰ／１．１）。ＨＴＴＰでは通常８０番のポート番号が利用される。以下、８０番を代表値として説明する。利用者が画面からハイパーテキストをクリックすると、クライアントソフトウェアからサーバにポート番号８０でＴＣＰコネクションを確立し、要求コマンドの送信が行われる。
【００１４】
セッション層の機能を実現するものは明示的ではない。なお、ＨＴＴＰの仕様は数回改版されている。ＨＴＴＰ／１．０までは持続性のあるＴＣＰコネクションを使用できなかったため、ＨＴＴＰセッションは複数のＴＣＰコネクションを束ねた概念である。ＨＴＴＰ／１．１では持続性のあるＴＣＰコネクションが使えるようになったので、ＨＴＴＰセッションはＴＣＰコネクションと等価と考えることができる。
【００１５】
電子メールの場合、通常ＴＣＰコネクションが使われ、サーバ間の配送プロトコルはＳＭＴＰ（Simple Mail Transfer Protocol）が使われている。ポート番号は２５で、詳細はＲＦＣ２８２１に示されている。サーバとクライアント間の配送プロトコルはＰＯＰ３（Post Office Protocol-Version 3）が使われている。ポート番号は１１０で、詳細はＲＦＣ１９３９に示されている。送信できるデータ形式を拡張するＭＩＭＥ（Multipurpose Internet Mail Extensions）により、テキスト形式だけでなく、映像や音声のファイル、文字の大きさや色の指定など、さまざまな情報を送ることができる。このＭＩＭＥはプレゼンテーション層のプロトコルと言える。セッション層の機能を実現するものは明示的ではないが、ＴＣＰコネクションと等価と考えることができる。
【００１６】
ＶｏＩＰ（Voiceover IP）の場合、プレゼンテーション層の機能として、実時間性を確保するためのプロトコルＲＴＰ（Real-time Transport Protocol）や装置ＣＯＤＥＣ（Coder/Decoder）に実装された音声や映像の圧縮符号化方式が挙げられる。ＲＴＰのトランスポート層にはＵＤＰが使われる。ＲＴＰの詳細はＲＦＣ１８８９に示されている。また、端末間の通信制御機能と端末とサーバ間の通信機能のためにＳＩＰ（Session Initiation Protcol）またはＨ．３２３が使われることがある。ＳＩＰのポート番号は５０６０である。ＳＩＰやＨ．３２３はセッション層の機能を担っている。ＳＩＰの詳細はＲＦＣ２５４３に示されている。Ｈ．３２３のうち、セッション層の記述は通信制御を扱ったＨ．２４５と呼制御を扱ったＨ．２２５．０に詳細が示されている。ＳＩＰのトランスポート層にはＵＤＰが使われ、Ｈ．３２３にはＴＣＰコネクションが使われる。
【００１７】
以上、代表的なＴＣＰ／ＩＰアプリケーションにおけるＯＳＩ参照モデルのセッション層、プレゼンテーション層、アプリケーション層に相当する機能を見てきた。プロトコルの観点からは、セッション層の機能が明示的あるいは非明示的のいずれにせよ、ＴＣＰ／ＩＰアプリケーションにおいても含まれている。
【００１８】
通信網のトラヒック業務について説明する。
通信網のトラヒック業務の分類例として、測定・監視・制御・管理・予測・設計を挙げる。
図３にその階層を示す。測定業務は、それ以外の各業務の基盤として、当該業務の目的に応じたトラヒックデータの測定を行なう。測定に関する項目や周期や集約方法に技術的ノウハウがある。図の左右は測定データの周期長を表していて、左側ほど短周期であり、右側ほど長周期である。具体的には、監視・制御の業務は分秒単位で措置を行なう必要があり、管理・予測業務はそれより長い月単位で措置を行なう必要がある。設計業務は更に長い年周期で措置を行なうが、監視・制御の業務や管理・予測の業務によって得られた結果もデータとして使用する。
【００１９】
監視業務は、測定したデータから異常な状態であることを把握する業務であり、制御業務は監視業務で得た結果をデータとして適切な状態に戻るような措置を施す業務である。管理業務は、測定したデータから正常な状態が継続していることを把握する業務である。予測業務は、管理業務で得たデータや外部要因からのデータを元に需要を予測する業務である。設計業務は、制御業務や管理業務や予測業務で得られたデータを元に、年単位先を念頭にネットワークの構成やリソース量を設計する業務である。
【００２０】
ＴＣＰ／ＩＰアプリケーションに対するトラヒック業務について説明する。
測定業務は、前述の通り測定項目がパケット数やバイト数が基本になっている．これらの測定項目は、インターネット層の測定データであり、ＴＣＰ／ＩＰアプリケーションの区別がない。測定以外の業務の基礎データとして使われるので、アプリケーション別に目的を持った措置を行なうためには、アプリケーション別ではない測定項目が基本になっていることは重大な支障を来す。
【００２１】
測定業務は、ネットワーク管理用のプロトコルＳＮＭＰ（Simple Network Management Protocol）によりＭＩＢ（Management Information Base）と呼ばれるデータベースの値を見ることが多い。ＭＩＢの一種にＲＭＯＮ（Remote Monitoring MIB）がある。ＳＮＭＰ／ＭＩＢがネットワーク・ノードのインターフェース（点）に関する情報を測定するように構成されているのに対して、ＭＩＢから派生して定義されたＲＭＯＮは接続されるネットワークのリンク（線）に関する情報を測定するように構成されている。なお、ＴＣＰ／ＩＰアプリケーションの機能としてＯＳＩ参照モデルに当てはめると、アプリケーション層の機能がＳＮＭＰで、プレゼンテーション層の機能がＭＩＢやＲＭＯＮと言える。
【００２２】
ＲＭＯＮを含めたＭＩＢを測定データとした各トラヒック業務を行なうことには幾つかの課題がある。各業務の目的に照らして必要な測定項目が定義されているとは限らない課題や、ＭＩＢデータを取得することによるノードに与える負荷の課題や、ＭＩＢデータを転送することによるリンクに与える負荷の課題などがある。
【００２３】
【発明が解決しようとする課題】
本発明の目的は、パケット交換網のトラヒック特性を効率的に理解する課題を解決したトラヒックの測定、監視、制御、管理、予測、または、設計の方法を提供することにあり、更に、その方法を実施するノードや外付け装置を提供することにある。
【００２４】
【課題を解決するための手段】
本発明は、ＴＣＰ／ＩＰプロトコルのトラヒック特性がアプリケーション別セッション数で特徴づけられる点に着目してなされたものであり、請求項１に記載された本発明によるトラヒックの測定、監視、制御、管理、予測、または、設計の方法は、端末とノードとリンクから構成されるパケット交換網において、端末で生成されるＴＣＰ／ＩＰプロトコルによるパケットのトラヒックに対し、
ノード間の各リンクにおけるトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１のステップ（アプリケーション別セッション計数法）を備えることを第１の特徴とし、
アプリケーション別に予め定めた分析方法を用いて上記のアプリケーション別セッションの計数結果を分析する第２のステップ（アプリケーション別セッショントラヒック分析法）を備えることを第２の特徴とする。
【００２５】
上述した本発明方法は、第１の特徴として、従来の技術とは、セッション層のデータでトラヒック測定を行なう点およびアプリケーション別にセッション層のトラヒックデータを測定する点が異なり、第２の特徴として、このような測定データをアプリケーション別に定めた分析方法で分析する点が異なる。
【００２６】
請求項２に記載された本発明の方法では、複数のアプリケーションを１つの集合としてアプリケーションの集合別にセッションを計数すること（アプリケーション群別セッション計数法）、および該集合に対して予め定めた分析方法を用いて分析すること（アプリケーション群別セッショントラヒック分析法）を特徴とする。
この方法は、従来技術とは、いくつかのＴＣＰ／ＩＰアプリケーションを集約した単位でトラヒック測定を行なう点およびその単位別にセッション層のトラヒックデータを測定する点が異なり、更に、このような測定データをその単位別に予め定めた分析方法で分析する点が異なる。
【００２７】
本発明は、更に、上述した方法を実施するパケット交換網のノードを提供し、請求項９に記載された本発明のノードは、ノードを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１の手段と、アプリケーション別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段とを備えることを特徴とする。
【００２８】
本発明は、更に、パケット交換網のリンクに接続され、上述の方法を実施するパッシブ型の測定装置を提供し、請求項１０に記載された本発明の測定装置は、リンクを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１の手段と、 アプリケーション別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段を備えることを特徴とする。
【００２９】
【作用】
請求項１に述べたアプリケーション別セッション計数法は、ＴＣＰ／ＩＰプロトコルのトラヒックをセッション層で測定することで測定データを削減する効果が生じ、アプリケーション別にセッション数を計数することで測定項目を削減する効果が生じ、アプリケーション別セッショントラヒック分析法は、予め個々に定めたアプリケーション別のトラヒック特性を基本データにすることで精度高く分析する効果が生じる。
請求項２に述べたアプリケーション群別セッション計数法は、予め同じまたは類似のトラヒック特性を持つと分かっているアプリケーションを群として扱うことで測定項目を削減する効果が生じ、群として扱ったアプリケーション間の相互作用が相殺されることで精度高く分析する効果が生じる。
請求項３に述べたノードは、ＴＣＰ／ＩＰプロトコルのトラヒックを転送しつつ、直接的にそのトラヒックの測定、監視、制御、管理、予測、または設計の業務を提供する効果が生じる。直接的であるため、得られた結果の応用が可能になる効果が生じる。
請求項４に述べたリンクに付随するパッシプ型測定装置は、ＴＣＰ／ＩＰプロトコルのトラヒックを転送しつつ、間接的にそのトラヒックの測定、監視、制御、管理、予測、または設計の業務を提供する効果が生じる。間接的であるため、結果を得るための負荷をノードに与えない効果がある。
【００３０】
【発明の実施の形態】
【実施例１】
本発明によるアプリケーション別のセッション数の測定方法について説明する。
図４は、実施例１の構成図である。
端末をＣ/Ｓ−０１，０２，…，０ｎ，１１，１２，…，１ｎで示し、ノードをＮ０，Ｎｌで示し、ノードＮ０とＮｌを結ぶリンクをＬで示す。端末は一つのノードとリンクで結ばれている（記号は省略する）。
リンクＬに付随するパッシブ型のトラヒック測定装置をＰで示す。リンクＬを転送されるトラヒックは分岐装置（・）で信号線Ｓに分岐されて測定装置Ｐに流れるが、パッシプ型なので測定装置ＰからリンクＬの向きには流れない。
図４は、送信も受信も同一のデータリンク層の回線を用いる場合の構成図である。
【００３１】
送信と受信を異なるデータリンク層の回線を用いる場合の構成図を図５に示す。リンクＬ０−１はノードＮ０が送信し、ノードＮｌが受信する回線であり、リンクＬｌ−０はノードＮｌが送信し、ノードＮ０が受信する回線である。
また、信号線Ｓ０−１とＳ１−０は、それぞれリンクＬ０−１とＬｌ−０に流れるデータをスヌープ（snoop）する。どちらも、測定装置Ｐが受信する。
【００３２】
測定装置Ｐが測定したデータを蓄積するテーブル表２に示す。
【表２】
レコードＲ１１，Ｒ２１．．．はアプリケーションを識別するレコードＡＰｌ，ＡＰ２，．．．で、
レコードＲ１２，Ｒ２２，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．のセッション確立数を蓄積するレコードＡｌ，Ａ２，．．．で、
レコードＲ１３，Ｒ２３，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．のセッション終了数を蓄積するレコードＤｌ，Ｄ２，．．．で、
レコードＲ１４，Ｒ２４，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．の同時接続セッション数を蓄積するレコードＣｌ，Ｃ２，…で、
レコードＲ１５，Ｒ２５，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．に対するセッショントラヒック分析結果（例として、帯域）を蓄積するレコードＢｌ，Ｂ２，．．．である。
このテーブルを時系列で蓄積する。
【００３３】
表２のレコードＲ１２，Ｒ２２，．．．；Ｒ１３，Ｒ２３，．．．を定める方法を説明する。
（１）アプリケーションＡＰがＴＣＰコネクションを用いる場合
（ａ）単一のコネクションを使う場合
例：ＨＴＴＰ/１．１（８０）、ＳＭＴＰ（２５）、ＰＯＰ３（１１０）、ＳＮＭＰ（１６１）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションを特定するポート番号（カツコ内の数字）のＴＣＰコネクションの確立と終了で定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
（ｂ）複数のコネクションを同時に使う場合
例：ＦＴＰ（２０，２１）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。ＦＴＰの場合は、ポート番号２０のＴＣＰコネクションの確立と終了で定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
（ｃ）複数のコネクションを断続的に使う場合
例：ＨＴＴＰ／１．０（８０）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。ＨＴＴＰ／１．０の場合、ポート番号（デフォルトでは８０番）のＴＣＰコネクションの確立と終了が断続することから、ＴＣＰコネクションの終了後予め定めた短時間のうちに再度確立される場合はセッションの終了とせず、また、ＴＣＰコネクションの終了後予め定めた時間のうちに再度確立されない場合に遡ってセッションの終了とする。測定装置は、該当セグメントの検知によりトラヒックを測定する。
【００３４】
（２）アプリケーションＡＰがＵＤＰを用いる場合
例：ＶｏＩＰ
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。特にアプリケーションを制御するＵＤＰの上位プロトコル（例えばＳＩＰ）または別途確立するＴＣＰコネクションを用いた制御プロトコル（例えばＨ．２４５やＨ．２２５．０）のセグメントによって定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
【００３５】
従来の技術の説明で、ＴＣＰコネクションの状態遷移と事象シーケンス図を示した。上記のアプリケーション別セッション計数法において、ＴＣＰをトランスポート層に用いるアプリケーションに対して、セッションの確立と終了をＴＣＰコネクションが通信状態にあることで定義した。通信状態にあることの認識は、データリンク層の使用方法に応じて２通りある。
（１）図４の場合（１本のデータリンク層の回線で両方向の通信）
ＴＣＰコネクションの確立をセグメントＳ０３で認識し、終了をセグメントＳｌ ｌで認識する。
（２）図５の場合（２本のデータリンク層の回線で方向別の通信）
ＴＣＰコネクションの確立と終了を次のセグメントに変更して定義する。
（Ｃ−Ｓ）クライアントからサーバヘの回線については、ＴＣＰコネクションの 確立をセグメントＳ０３で認識し、終了をセグメントＳｌｌで認識する。また、 （Ｓ−Ｃ）サーバからクライアントヘの回線については、確立をセグメントＳ０ ２で認識し、終了をセグメントＳ１２で認識する。
なお、２本のデータリンク層の回線を使っていても、測定装置Ｐで測定データを統合して分析できるならば、上のような認識方法の変更は不要で、１本の場合と同様に処理することができる。
【００３６】
ＵＤＰを用いるアプリケーションについても、その上位プロトコルまたは別途確立するＴＣＰコネクションを用いた制御プロトコルについて、特定のセグメントを検出することによりアプリケーションのセッションの確立と終了を定義する。定義の方法は、ＴＣＰコネクションと同様に、通信状態になる直前と直後のセグメントを用いる。
【００３７】
以上、測定装置がリンクに付随するパッシブ型の場合で説明した。クライアントとサーバの間のノードにおいて測定する場合も同様に前述のセグメントによりコネクションの確立と終了を認識する実装が容易に行える。
【００３８】
次に、アプリケーション別セッショントラヒック分析法を説明する。即ち、表２のレコードＲ１５，Ｒ２５，…を定める方法であり、アプリケーションＡＰ別に同時接続セッション数Ｃの所要帯域関数Ｆをトラヒック業務の目的別に定めることである。特に、図６に示したグラフのように、関数Ｆが変数Ｃに関して単調増加、または上に凸の特性を持つように定めることで、ネットワーク資源を効率的に利用できる効果が得られる。即ち、多数のセッション数を多重することで、セッション１本あたりに必要となる帯域Ｂが少なくて済むようになる。
【００３９】
以上のように、アプリケーション別セッション数の測定方法を説明し、その測定結果を基に分析する方法と効果を述べた。
次に、このような測定方法によって、簡易に適切な分析が可能になる理由を説明する。
パケット通信におけるトラヒックは、アプリケーションによって特性が大きく異なることに着目する。このトラヒックの基本単位は、前述のように、パケットやバイトであるが、アプリケーションによって、パケットの発生間隔やバイト数は、明らかに異なる特性を示す。例えばＶｏＩＰの場合、ＣＯＤＥＣに応じてパケットが、基本的には一定間隔、一定長で生成される。ただし、無音圧縮を行う場合は間隔が長くなることが確率的に発生し、実時間制御のためのプロトコル仕様に応じて制御パケットが割り込み、間隔が詰まったり、異なる長さのパケットが混入する。ＦＴＰやＨＴＴＰは、転送するファイルサイズと転送可能な最大パケット長が主な要因になって特徴が定まる。即ち、パケット通信におけるトラヒックは、アプリケーション別に各セッションのパケット発生間隔やパケット長の統計的観点あるいはプロトコル仕様の観点から特徴づけられ、同一アプリケーションのトラヒックはセッション数の関数で記述することが可能である。この特徴づけとこの関数の特定が十分な精度で行われれば、パケットやバイト単位の測定を行わずとも、セッション数を測定することにより同一アプリケーション全体のトラヒック特性を理解することができる。このほうが測定の負担は非常に軽く、且つ、妥当である。
【００４０】
もし、複数のアプリケーションに対して同一あるいは類似のトラヒック特性であると分かれば、それらのアプリケーションをグループ化して扱うことで、測定項目を削減する効果がある。これにより測定データの蓄積量を削減する効果もある。
【００４１】
以上の説明は、パッシブ型の測定装置Ｐで説明したが、ノードＮ０またはＮ１が測定機能を持つことも可能である。パッシブ型測定装置Ｐが測定することによる長所は、測定行為がトラヒックに影響を与えない点であるが、一方で、分析結果を各トラヒック業務で直接的に活用できない短所がある。ノードＮ０またはＮ１で測定することの長所は、パッシブ型測定装置Ｐによる測定の短所を改善する効果がある。しかしながら、ノードはパケット転送をインターネット層で行っているので、トランスポート層以上の測定も行うことは負荷を高める悪影響がある。このようにパッシプ型測定装置とノードのどちらにも長所と短所があるので、測定を行うのがどちらが適切かは一概に言えない。
【００４２】
〔実施例２〕
様々なトラヒック業務での応用例を説明する。
まず、監視業務に適用した例を説明する。
電話サービスにおいては、発呼数や同時接続回線数に基づいて監視業務が行われている。
ＴＣＰ／ＩＰアプリケーションに対しては、アプリケーション別のセッションに対して同様の測定データがあれば、同様の業務を展開することが可能である。
表２のアプリケーション別のセッション確立数Ｒ１２，Ｒ２２，．．．や同時接続セッション数Ｒ１４，Ｒ２４，．．．の時系列データを監視し、次のような分析を行うことで、異常な状態であるかどうかを把握する。
（１）ノードやリンクの処理能力を超えると予想されるぼどの急激な増加傾向
（２）ノードやリンクの処理能力を超える増加事象
【００４３】
制御業務に適用した例を説明する。
電話サービスにおいては、輻輳制御として行われている業務である。ＴＣＰ／ＩＰアプリケーションに対しては、アプリケーション別のセッションに対して同様の測定データがあれば、同様の業務を展開することが可能である。
監視業務で述べた異常状態を把握した場合など、表２のアプリケーション別のセッション確立数について、一定間隔において一定率を上限に受付ける、あるいは、一定間隔において一定数を上限に受付ける制限を予め定め、測定装置においてこれらの制限値を越えたかどうかを分析し、ノードに通知する。通知を受けたノードは制限を実行することができる。
【００４４】
管理業務に適用した例を説明する。
表２のアプリケーション別の同時接続セッション数Ｒ１４，Ｒ２４，…の時系列データを基に、次のような分析を行うことで、ネットワーク資源とトラヒック量の過不足を把握する。
（１）上記の１時間毎の時系列データの日毎最繁値について、年間上位３０個の平均値を基に、品質を保証するのに必要な帯域を求める関数Ｆｌを用いて、現在のリンクの帯域と比較する。
（２）上記の１時間毎の時系列データの日毎最繁値について、連続平日２０個の最大値を基に、品質を保証するのに必要な帯域を求める関数Ｆ２を用いて、現在のリンクの帯域と比較する。
【００４５】
予測業務に適用した例を説明する．
表２のアプリケーション別の同時接続セッション数Ｒ１４，Ｒ２４，．．．の時系列データを基に、次のような周知の時系列データの統計分析手法を用いて分析を行うことで、アプリケーション別のトラヒック需要の予測を行う。
（１）変動特性、例えば日変動、週変動、月変動、年変動を把握する。
（２）トレンド特性を把握する。
【００４６】
設計業務に適用した例を説明する。
管理業務で述べた必要帯域に、予測業務で述べた変動特性とトレンド特性を加味し、ネットワーク（ここではリンクの帯域）の設計値を算出する。
【００４７】
【発明の効果】
以上説明したように、ＴＣＰ／ＩＰアプリケーションのトラヒックについて、そのセッション数をアプリケーション別に測定することからパケット交換網のトラヒック特性を効率的に理解する効果があり、アプリケーション別セッション数のデータとアプリケーション別トラヒック特性から通信網の監視、制御、管理、予測、または、設計の方法を効率的に提供する効果がある。
更に、その方法を実施するルータや外付け装置を簡単且つ安価に提供する効果がある。
【図面の簡単な説明】
【図１】 ＴＰＣコネクションの確立と終了に対応する事象シーケンス図を示す。
【図２】 ＴＣＰコネクションの確立と終了に対応する状態遷移ダイアグラムを示す。
【図３】 トラヒック業務の階層構造を示す図である。
【図４】 本発明の第１の実施例の構成図である。
【図５】 本発明の第２の実施例の構成図である。
【図６】 ネットワーク資源の効率的使用のために必要な帯域Ｂを同時接続セッション数Ｃの関数として示す図である。
【符号の説明】
Ｃ/Ｓ−０１，０２，…，０ｎ，１１，１２，…，１ｎ 端末
Ｎ０，Ｎｌ ノード
Ｌ；Ｌ０−１，Ｌｌ−０ リンク
Ｓ；Ｓ０−１，Ｓ１−０ 信号線
【発明の属する技術分野】
本発明は、パケット交換網におけるトラヒック特性を効率的に理解する方法と、その方法を実施するノード及び外付け装置に関するものである。パケット通信網としては、例えば、ＴＣＰ／ＩＰプロトコルを用いるインターネットが挙げられる。また、トラヒック特性を理解することによって解決される技術分野としては、トラヒックの測定、監視、制御、管理、予測、設計などが挙げられる。
【０００２】
【従来の技術】
周知のように、通信サービスは、ネットワークを介して物理的・地理的な距離の隔たりを解消させることで、社会・経済活動に掛け替えのない生活基盤（ライフライン）になっているので、短時間であってもサービスが停滞することは容認されない。通信ネットワークに流れる情報量は増加の一途を辿っていて、その情報を迅速かつ確実に伝達することは社会からの要請である。通信事業者は、顧客の満足に適った通信サービスを提供するために、通信ネットワークの基本的な機能と性能を測定し、監視し、制御し、管理し、更に、必要なリソースを設計することで、効率のよい設備の構築、的確な運用、コストの低廉化を実施する必要がある。
【０００３】
通信システムの性能は、通信サービスの情報量、即ち、トラヒック（traffic）で表現される。
この「トラヒック」という単語は、交通や運輸の分野においても交通量や運輸量として、方向性を持った量の意味で使われている。通信の分野でのトラヒックは、電話・電報・データ・画像などの通信の交流や構造を意味していて、特に電話においては「通信設備によって運ばれる呼（call）」が基本単位になっている。また、パケット通信においては、従来、パケット（packet）やバイト（byte）が基本単位になっている．非同期転送モード（ATM,Asynchronous Transfer Mode）での通信では、セル（cell）が基本単位になっている。
【０００４】
一般の商品が、数量・品質・価格・売れ具合などを生産・流通・販売の過程で把握し管理する必要があるように、通信の分野では、業務の目的に合わせてトラヒックを的確に把握・管理する必要がある。これを通信網のトラヒック業務と呼ぶ。電話においては、呼を測定し、同時接続中の呼数を管理することで、トラヒックの把握や管理が可能であった。パケット通信においては、パケット数やバイト数を測定し管理することで、ある程度のトラヒックの把握や管理が可能であった。ＡＴＭにおいてはセル数を測定する方法もあるが、セル送信バッファの待ち行列しきい値を超過する回数も測定することで、トラヒックの把握や管理が可能であった。
【０００５】
近年、インターネットが普及し、ＴＣＰ／ＩＰアプリケーションの観点からトラヒックの把握を行なうことで、トラヒック特性を効率的に理解する方法が求められている。ＴＣＰ／ＩＰの下位プロトコルとしてＡＴＭが用いられることがある。上述のセルレベルの測定に基づく技術はセルレベルのトラヒックを把握することに適用する技術であって、階層の異なるＴＣＰ／ＩＰアプリケーションの観点からは直接的ではない。
【０００６】
次に上記の階層について説明する。通信プロトコルは階層モデルが適用される。国際標準化機構（ISO,International Organizationfor Standardization）は、通信の国際標準として開放型システム相互間接続（OSI,Open System International）という通信プロトコルの標準化を目指すにあたり、通信プロトコルを設計する指標として、通信プロトコルの機能を７つの階層に分割するＯＳＩ参照モデルを提唱し、複雑になりがちな通信プロトコルを単純化することを目指した。ＯＳＩ参照モデルの各層の機能を表１の左側に示す。
【０００７】
【表１】
パケット交換網として代表的なインターネットにおける通信プロトコルは、ＴＣＰ／ＩＰと呼ばれる。ＯＳＩ参照モデルとの対応と共にＴＣＰ／ＩＰの階層モデルを表１の右側に示す。両者に違いがあるのは、ＯＳＩ参照モデルが、腑撤的にモデル化されたのに対して、ＴＣＰ／ＩＰの階層モデルはプロトコルの実装の観点からモデル化されたためである。ＯＳＩ参照モデルに当てはめると、その構造は第５〜７層がアプリケーション層に統合されている特徴がある。実装の観点からは、単一のアプリケーションの内部で第５〜７層それぞれの機能が実現される場合もあるし、複数のアプリケーションに分けて実装される場合もある。ＴＣＰ／ＩＰのアプリケーションプログラムの機能を詳細に見ていくと、ＯＳＩ参照モデルの第５〜７層のそれぞれの機能が見えてくる。その説明の前に、両方のモデルに共通するトランスポート層のプロトコルについて説明する。
【０００９】
トランスポート層のプロトコルにはＵＤＰ（User Datagram Protocol）とＴＣＰ（Transmission Control Protocol）がある。ＵＤＰはコネクションを確立せずに通信を開始できる軽量なプロトコルである。ＵＤＰについては、ＲＦＣ７６８に示されている。信頼性が必要な場合はＵＤＰよりも上位のプロトコルでそれを提供する。一方、ＴＣＰはコネクションを確立してから通信するので、信頼性を提供することができるプロトコルである。ＴＣＰについては、ＲＦＣ７９３に示されている。図１にＴＣＰコネクションの確立と終了に対応する事象シーケンス図を示し、図２に通常の状態遷移ダイアグラムを示す。ただし、説明の簡単のために通常の場合のみに限定している。
【００１０】
ＴＣＰコネクションを確立するステップについて説明する。ＴＣＰコネクションは２台の端末間のコネクションで、それぞれの端末のＩＰアドレスをヘッダーに指定されたパケットで通信する。
そのため、端末間のノードにおいて、このＩＰアドレスの組によって区別される。ＴＣＰコネクションの確立には次の３ステップを踏む。
１．要求側の端末（クライアントと呼ばれる）は、接続したい端末（サーバとよばれる）に、ポート番号（アプリケーションの識別子）とクライアントの初期シーケンス番号を指定したＳＹＮセグメントＳ０１を送る。
・クライアントはＳＹＮ−ＳＥＮＴ状態に遷移する。
２．サーバは、Ｓ０ｌに応じて、サーバ側の初期シーケンス番号を含む自分自身のＳＹＮセグメントＳ０２で応答する。また、これにはクライアントの初期シーケンス番号＋１のＡＣＫを含めて、クライアントのＳＹＮに確認応答する。
・サーバはＬＩＳＴＥＮ状態からＳＹＮ＿ＲＣＶＤ状態に遷移する。
３．クライアントは、Ｓ０２に応じて、サーバの初期シーケンス番号＋１のＡＣＫセグメントＳ０３で確認応答する。
・クライアントはＳＹＮ＿ＳＥＮＴ状態からＥＳＴＡＢＬＩＳＨＥＤ状態に遷移する。
・サーバはＡＣＫを受けてＥＳＴＡＢＬＩＳＨＥＤ状態に遷移する。
上記のステップは通常の場合であり、コネクションの確立に至らずタイムアウトした場合や、両端末から同時にコネクション確立要求があった場合などはこのステップには従わない。
【００１１】
ＴＣＰコネクションを終了するステップについて説明する。次の４ステップを踏む。
１．クライアントは、ＦＩＮセグメントＳｌｌをシーケンス番号とともに送る。
・クライアントはＥＳＴＡＢＬＩＳＩ正Ｄ状態からＦＩＮ ＷＡＩＴ １状態に遷移する。
２．サーバは、Ｓ１１に応じて、受取ったシーケンス番号＋１のＡＣＫセグメントＳ１２で確認応答する。サーバはアプリケーションにＴＣＰコネクションの終了を知らせる。そして、サーバはクライアントにＦＩＮセグメントＳ１３をシーケンス番号とともに送る。
・サーバはＥＳＴＡＢＬＩＳＨＥＤ状態からＣＬＯＳＥＤ＿ＷＡＩＴ状態に遷移する。
・サーバはアプリケーションヘの終了通知に応じてＣＬＯＳＥＤ＿ＷＡＩＴ状態からＬＡＳＴ＿ＡＣＫ状態に遷移する。
３．クライアントは、Ｓ１２とＳ１３に応じて、受取ったシーケンス番号＋１のＡＣＫセグメントＳ１４で確認応答する。
・クライアントはＳ１２に応じてＦＩＮ ＷＡＩＴ １状態からＦＩＮ ＷＡＩＴ ２に遷移する。
・クライアントはＳ１３に応じてＦＩＮ ＷＡＩＴ ２状態からＴＩＭＥ＿ ＷＡＩＴ状態に遷移する。
・クライアントは、予め定められた２ＭＬＳ待って、ＴＩＭＡ ＷＡＩＴ状態からＣＬＯＳＥＤ状態に遷移する。
・サーバはＳ１４に応じてＬＡＳＴ＿ＡＣＫ状態からＣＬＯＳＥＤ状態に遷移する。
【００１２】
次に、代表的なＴＣＰ／ＩＰのアプリケーション、特に、そのセッション層について説明する。
ＦＴＰ（File Transfer Protocol）は、異なるコンピュータの間（クライアントとサーバの間）でファイルを転送するプロトコルである。詳細はＲＦＣ９５９に示されている。ＦＴＰでは２本のＴＣＰコネクションが利用される。１つは制御用で、もう１つはデータ転送用である。制御用のＴＣＰコネクションはＦＴＰの制御に利用される。ログインのためのユーザ名やパスワード認証の確認や転送するファイルや転送の方向の指示に利用される。これはポート番号２１が利用される。データ転送用のＴＣＰコネクションはＦＴＰのデータ転送に利用される。制御用ＴＣＰコネクションで、ファイルの取得ＧＥＴや授与ＰＵＴ、ファイルの一覧表の取得ＬＩＳＴが実行されると、その度にデータ転送用のＴＣＰコネクションが確立され、データが転送され、切断される。そしてまた、制御用のコネクションを利用して、コマンドや応答の通信が行われる。データ転送用のＴＣＰコネクションはポート番号２０が利用される。ＦＴＰセッションは、これら２本のＴＣＰを束ねた概念として明示的である。
【００１３】
ＷＷＷ（World Wide Web）はインターネット上の情報をハイパーテキストのような形式で参照できる情報提供システムである。ＷＷＷの情報を画面に表示するクライアントソフトウェアのＷｅｂブラウザを利用すると、利用者はデータが実際にどこのサーバにあるかを意識せずに、マウスをクリックするだけで関連する様々な情報を次々に閲覧することができる。ＷＷＷのプロトコルはＨＴＴＰ（Hyper Text Transport Protocol）で、その詳細はＲＦＣ２６１６に示されている（ＨＴＴＰ／１．１）。ＨＴＴＰでは通常８０番のポート番号が利用される。以下、８０番を代表値として説明する。利用者が画面からハイパーテキストをクリックすると、クライアントソフトウェアからサーバにポート番号８０でＴＣＰコネクションを確立し、要求コマンドの送信が行われる。
【００１４】
セッション層の機能を実現するものは明示的ではない。なお、ＨＴＴＰの仕様は数回改版されている。ＨＴＴＰ／１．０までは持続性のあるＴＣＰコネクションを使用できなかったため、ＨＴＴＰセッションは複数のＴＣＰコネクションを束ねた概念である。ＨＴＴＰ／１．１では持続性のあるＴＣＰコネクションが使えるようになったので、ＨＴＴＰセッションはＴＣＰコネクションと等価と考えることができる。
【００１５】
電子メールの場合、通常ＴＣＰコネクションが使われ、サーバ間の配送プロトコルはＳＭＴＰ（Simple Mail Transfer Protocol）が使われている。ポート番号は２５で、詳細はＲＦＣ２８２１に示されている。サーバとクライアント間の配送プロトコルはＰＯＰ３（Post Office Protocol-Version 3）が使われている。ポート番号は１１０で、詳細はＲＦＣ１９３９に示されている。送信できるデータ形式を拡張するＭＩＭＥ（Multipurpose Internet Mail Extensions）により、テキスト形式だけでなく、映像や音声のファイル、文字の大きさや色の指定など、さまざまな情報を送ることができる。このＭＩＭＥはプレゼンテーション層のプロトコルと言える。セッション層の機能を実現するものは明示的ではないが、ＴＣＰコネクションと等価と考えることができる。
【００１６】
ＶｏＩＰ（Voiceover IP）の場合、プレゼンテーション層の機能として、実時間性を確保するためのプロトコルＲＴＰ（Real-time Transport Protocol）や装置ＣＯＤＥＣ（Coder/Decoder）に実装された音声や映像の圧縮符号化方式が挙げられる。ＲＴＰのトランスポート層にはＵＤＰが使われる。ＲＴＰの詳細はＲＦＣ１８８９に示されている。また、端末間の通信制御機能と端末とサーバ間の通信機能のためにＳＩＰ（Session Initiation Protcol）またはＨ．３２３が使われることがある。ＳＩＰのポート番号は５０６０である。ＳＩＰやＨ．３２３はセッション層の機能を担っている。ＳＩＰの詳細はＲＦＣ２５４３に示されている。Ｈ．３２３のうち、セッション層の記述は通信制御を扱ったＨ．２４５と呼制御を扱ったＨ．２２５．０に詳細が示されている。ＳＩＰのトランスポート層にはＵＤＰが使われ、Ｈ．３２３にはＴＣＰコネクションが使われる。
【００１７】
以上、代表的なＴＣＰ／ＩＰアプリケーションにおけるＯＳＩ参照モデルのセッション層、プレゼンテーション層、アプリケーション層に相当する機能を見てきた。プロトコルの観点からは、セッション層の機能が明示的あるいは非明示的のいずれにせよ、ＴＣＰ／ＩＰアプリケーションにおいても含まれている。
【００１８】
通信網のトラヒック業務について説明する。
通信網のトラヒック業務の分類例として、測定・監視・制御・管理・予測・設計を挙げる。
図３にその階層を示す。測定業務は、それ以外の各業務の基盤として、当該業務の目的に応じたトラヒックデータの測定を行なう。測定に関する項目や周期や集約方法に技術的ノウハウがある。図の左右は測定データの周期長を表していて、左側ほど短周期であり、右側ほど長周期である。具体的には、監視・制御の業務は分秒単位で措置を行なう必要があり、管理・予測業務はそれより長い月単位で措置を行なう必要がある。設計業務は更に長い年周期で措置を行なうが、監視・制御の業務や管理・予測の業務によって得られた結果もデータとして使用する。
【００１９】
監視業務は、測定したデータから異常な状態であることを把握する業務であり、制御業務は監視業務で得た結果をデータとして適切な状態に戻るような措置を施す業務である。管理業務は、測定したデータから正常な状態が継続していることを把握する業務である。予測業務は、管理業務で得たデータや外部要因からのデータを元に需要を予測する業務である。設計業務は、制御業務や管理業務や予測業務で得られたデータを元に、年単位先を念頭にネットワークの構成やリソース量を設計する業務である。
【００２０】
ＴＣＰ／ＩＰアプリケーションに対するトラヒック業務について説明する。
測定業務は、前述の通り測定項目がパケット数やバイト数が基本になっている．これらの測定項目は、インターネット層の測定データであり、ＴＣＰ／ＩＰアプリケーションの区別がない。測定以外の業務の基礎データとして使われるので、アプリケーション別に目的を持った措置を行なうためには、アプリケーション別ではない測定項目が基本になっていることは重大な支障を来す。
【００２１】
測定業務は、ネットワーク管理用のプロトコルＳＮＭＰ（Simple Network Management Protocol）によりＭＩＢ（Management Information Base）と呼ばれるデータベースの値を見ることが多い。ＭＩＢの一種にＲＭＯＮ（Remote Monitoring MIB）がある。ＳＮＭＰ／ＭＩＢがネットワーク・ノードのインターフェース（点）に関する情報を測定するように構成されているのに対して、ＭＩＢから派生して定義されたＲＭＯＮは接続されるネットワークのリンク（線）に関する情報を測定するように構成されている。なお、ＴＣＰ／ＩＰアプリケーションの機能としてＯＳＩ参照モデルに当てはめると、アプリケーション層の機能がＳＮＭＰで、プレゼンテーション層の機能がＭＩＢやＲＭＯＮと言える。
【００２２】
ＲＭＯＮを含めたＭＩＢを測定データとした各トラヒック業務を行なうことには幾つかの課題がある。各業務の目的に照らして必要な測定項目が定義されているとは限らない課題や、ＭＩＢデータを取得することによるノードに与える負荷の課題や、ＭＩＢデータを転送することによるリンクに与える負荷の課題などがある。
【００２３】
【発明が解決しようとする課題】
本発明の目的は、パケット交換網のトラヒック特性を効率的に理解する課題を解決したトラヒックの測定、監視、制御、管理、予測、または、設計の方法を提供することにあり、更に、その方法を実施するノードや外付け装置を提供することにある。
【００２４】
【課題を解決するための手段】
本発明は、ＴＣＰ／ＩＰプロトコルのトラヒック特性がアプリケーション別セッション数で特徴づけられる点に着目してなされたものであり、請求項１に記載された本発明によるトラヒックの測定、監視、制御、管理、予測、または、設計の方法は、端末とノードとリンクから構成されるパケット交換網において、端末で生成されるＴＣＰ／ＩＰプロトコルによるパケットのトラヒックに対し、
ノード間の各リンクにおけるトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１のステップ（アプリケーション別セッション計数法）を備えることを第１の特徴とし、
アプリケーション別に予め定めた分析方法を用いて上記のアプリケーション別セッションの計数結果を分析する第２のステップ（アプリケーション別セッショントラヒック分析法）を備えることを第２の特徴とする。
【００２５】
上述した本発明方法は、第１の特徴として、従来の技術とは、セッション層のデータでトラヒック測定を行なう点およびアプリケーション別にセッション層のトラヒックデータを測定する点が異なり、第２の特徴として、このような測定データをアプリケーション別に定めた分析方法で分析する点が異なる。
【００２６】
請求項２に記載された本発明の方法では、複数のアプリケーションを１つの集合としてアプリケーションの集合別にセッションを計数すること（アプリケーション群別セッション計数法）、および該集合に対して予め定めた分析方法を用いて分析すること（アプリケーション群別セッショントラヒック分析法）を特徴とする。
この方法は、従来技術とは、いくつかのＴＣＰ／ＩＰアプリケーションを集約した単位でトラヒック測定を行なう点およびその単位別にセッション層のトラヒックデータを測定する点が異なり、更に、このような測定データをその単位別に予め定めた分析方法で分析する点が異なる。
【００２７】
本発明は、更に、上述した方法を実施するパケット交換網のノードを提供し、請求項９に記載された本発明のノードは、ノードを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１の手段と、アプリケーション別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段とを備えることを特徴とする。
【００２８】
本発明は、更に、パケット交換網のリンクに接続され、上述の方法を実施するパッシブ型の測定装置を提供し、請求項１０に記載された本発明の測定装置は、リンクを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーション別にセッションを計数する第１の手段と、 アプリケーション別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段を備えることを特徴とする。
【００２９】
【作用】
請求項１に述べたアプリケーション別セッション計数法は、ＴＣＰ／ＩＰプロトコルのトラヒックをセッション層で測定することで測定データを削減する効果が生じ、アプリケーション別にセッション数を計数することで測定項目を削減する効果が生じ、アプリケーション別セッショントラヒック分析法は、予め個々に定めたアプリケーション別のトラヒック特性を基本データにすることで精度高く分析する効果が生じる。
請求項２に述べたアプリケーション群別セッション計数法は、予め同じまたは類似のトラヒック特性を持つと分かっているアプリケーションを群として扱うことで測定項目を削減する効果が生じ、群として扱ったアプリケーション間の相互作用が相殺されることで精度高く分析する効果が生じる。
請求項３に述べたノードは、ＴＣＰ／ＩＰプロトコルのトラヒックを転送しつつ、直接的にそのトラヒックの測定、監視、制御、管理、予測、または設計の業務を提供する効果が生じる。直接的であるため、得られた結果の応用が可能になる効果が生じる。
請求項４に述べたリンクに付随するパッシプ型測定装置は、ＴＣＰ／ＩＰプロトコルのトラヒックを転送しつつ、間接的にそのトラヒックの測定、監視、制御、管理、予測、または設計の業務を提供する効果が生じる。間接的であるため、結果を得るための負荷をノードに与えない効果がある。
【００３０】
【発明の実施の形態】
【実施例１】
本発明によるアプリケーション別のセッション数の測定方法について説明する。
図４は、実施例１の構成図である。
端末をＣ/Ｓ−０１，０２，…，０ｎ，１１，１２，…，１ｎで示し、ノードをＮ０，Ｎｌで示し、ノードＮ０とＮｌを結ぶリンクをＬで示す。端末は一つのノードとリンクで結ばれている（記号は省略する）。
リンクＬに付随するパッシブ型のトラヒック測定装置をＰで示す。リンクＬを転送されるトラヒックは分岐装置（・）で信号線Ｓに分岐されて測定装置Ｐに流れるが、パッシプ型なので測定装置ＰからリンクＬの向きには流れない。
図４は、送信も受信も同一のデータリンク層の回線を用いる場合の構成図である。
【００３１】
送信と受信を異なるデータリンク層の回線を用いる場合の構成図を図５に示す。リンクＬ０−１はノードＮ０が送信し、ノードＮｌが受信する回線であり、リンクＬｌ−０はノードＮｌが送信し、ノードＮ０が受信する回線である。
また、信号線Ｓ０−１とＳ１−０は、それぞれリンクＬ０−１とＬｌ−０に流れるデータをスヌープ（snoop）する。どちらも、測定装置Ｐが受信する。
【００３２】
測定装置Ｐが測定したデータを蓄積するテーブル表２に示す。
【表２】
レコードＲ１２，Ｒ２２，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．のセッション確立数を蓄積するレコードＡｌ，Ａ２，．．．で、
レコードＲ１３，Ｒ２３，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．のセッション終了数を蓄積するレコードＤｌ，Ｄ２，．．．で、
レコードＲ１４，Ｒ２４，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．の同時接続セッション数を蓄積するレコードＣｌ，Ｃ２，…で、
レコードＲ１５，Ｒ２５，．．．はそれぞれアプリケーションＡＰｌ，ＡＰ２，．．．に対するセッショントラヒック分析結果（例として、帯域）を蓄積するレコードＢｌ，Ｂ２，．．．である。
このテーブルを時系列で蓄積する。
【００３３】
表２のレコードＲ１２，Ｒ２２，．．．；Ｒ１３，Ｒ２３，．．．を定める方法を説明する。
（１）アプリケーションＡＰがＴＣＰコネクションを用いる場合
（ａ）単一のコネクションを使う場合
例：ＨＴＴＰ/１．１（８０）、ＳＭＴＰ（２５）、ＰＯＰ３（１１０）、ＳＮＭＰ（１６１）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションを特定するポート番号（カツコ内の数字）のＴＣＰコネクションの確立と終了で定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
（ｂ）複数のコネクションを同時に使う場合
例：ＦＴＰ（２０，２１）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。ＦＴＰの場合は、ポート番号２０のＴＣＰコネクションの確立と終了で定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
（ｃ）複数のコネクションを断続的に使う場合
例：ＨＴＴＰ／１．０（８０）
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。ＨＴＴＰ／１．０の場合、ポート番号（デフォルトでは８０番）のＴＣＰコネクションの確立と終了が断続することから、ＴＣＰコネクションの終了後予め定めた短時間のうちに再度確立される場合はセッションの終了とせず、また、ＴＣＰコネクションの終了後予め定めた時間のうちに再度確立されない場合に遡ってセッションの終了とする。測定装置は、該当セグメントの検知によりトラヒックを測定する。
【００３４】
（２）アプリケーションＡＰがＵＤＰを用いる場合
例：ＶｏＩＰ
方法：アプリケーションＡＰのセッションの確立と終了を、当該アプリケーションの使用方法に応じて別途定める。特にアプリケーションを制御するＵＤＰの上位プロトコル（例えばＳＩＰ）または別途確立するＴＣＰコネクションを用いた制御プロトコル（例えばＨ．２４５やＨ．２２５．０）のセグメントによって定義する。測定装置は、該当セグメントの検知によりトラヒックを測定する。
【００３５】
従来の技術の説明で、ＴＣＰコネクションの状態遷移と事象シーケンス図を示した。上記のアプリケーション別セッション計数法において、ＴＣＰをトランスポート層に用いるアプリケーションに対して、セッションの確立と終了をＴＣＰコネクションが通信状態にあることで定義した。通信状態にあることの認識は、データリンク層の使用方法に応じて２通りある。
（１）図４の場合（１本のデータリンク層の回線で両方向の通信）
ＴＣＰコネクションの確立をセグメントＳ０３で認識し、終了をセグメントＳｌ ｌで認識する。
（２）図５の場合（２本のデータリンク層の回線で方向別の通信）
ＴＣＰコネクションの確立と終了を次のセグメントに変更して定義する。
（Ｃ−Ｓ）クライアントからサーバヘの回線については、ＴＣＰコネクションの 確立をセグメントＳ０３で認識し、終了をセグメントＳｌｌで認識する。また、 （Ｓ−Ｃ）サーバからクライアントヘの回線については、確立をセグメントＳ０ ２で認識し、終了をセグメントＳ１２で認識する。
なお、２本のデータリンク層の回線を使っていても、測定装置Ｐで測定データを統合して分析できるならば、上のような認識方法の変更は不要で、１本の場合と同様に処理することができる。
【００３６】
ＵＤＰを用いるアプリケーションについても、その上位プロトコルまたは別途確立するＴＣＰコネクションを用いた制御プロトコルについて、特定のセグメントを検出することによりアプリケーションのセッションの確立と終了を定義する。定義の方法は、ＴＣＰコネクションと同様に、通信状態になる直前と直後のセグメントを用いる。
【００３７】
以上、測定装置がリンクに付随するパッシブ型の場合で説明した。クライアントとサーバの間のノードにおいて測定する場合も同様に前述のセグメントによりコネクションの確立と終了を認識する実装が容易に行える。
【００３８】
次に、アプリケーション別セッショントラヒック分析法を説明する。即ち、表２のレコードＲ１５，Ｒ２５，…を定める方法であり、アプリケーションＡＰ別に同時接続セッション数Ｃの所要帯域関数Ｆをトラヒック業務の目的別に定めることである。特に、図６に示したグラフのように、関数Ｆが変数Ｃに関して単調増加、または上に凸の特性を持つように定めることで、ネットワーク資源を効率的に利用できる効果が得られる。即ち、多数のセッション数を多重することで、セッション１本あたりに必要となる帯域Ｂが少なくて済むようになる。
【００３９】
以上のように、アプリケーション別セッション数の測定方法を説明し、その測定結果を基に分析する方法と効果を述べた。
次に、このような測定方法によって、簡易に適切な分析が可能になる理由を説明する。
パケット通信におけるトラヒックは、アプリケーションによって特性が大きく異なることに着目する。このトラヒックの基本単位は、前述のように、パケットやバイトであるが、アプリケーションによって、パケットの発生間隔やバイト数は、明らかに異なる特性を示す。例えばＶｏＩＰの場合、ＣＯＤＥＣに応じてパケットが、基本的には一定間隔、一定長で生成される。ただし、無音圧縮を行う場合は間隔が長くなることが確率的に発生し、実時間制御のためのプロトコル仕様に応じて制御パケットが割り込み、間隔が詰まったり、異なる長さのパケットが混入する。ＦＴＰやＨＴＴＰは、転送するファイルサイズと転送可能な最大パケット長が主な要因になって特徴が定まる。即ち、パケット通信におけるトラヒックは、アプリケーション別に各セッションのパケット発生間隔やパケット長の統計的観点あるいはプロトコル仕様の観点から特徴づけられ、同一アプリケーションのトラヒックはセッション数の関数で記述することが可能である。この特徴づけとこの関数の特定が十分な精度で行われれば、パケットやバイト単位の測定を行わずとも、セッション数を測定することにより同一アプリケーション全体のトラヒック特性を理解することができる。このほうが測定の負担は非常に軽く、且つ、妥当である。
【００４０】
もし、複数のアプリケーションに対して同一あるいは類似のトラヒック特性であると分かれば、それらのアプリケーションをグループ化して扱うことで、測定項目を削減する効果がある。これにより測定データの蓄積量を削減する効果もある。
【００４１】
以上の説明は、パッシブ型の測定装置Ｐで説明したが、ノードＮ０またはＮ１が測定機能を持つことも可能である。パッシブ型測定装置Ｐが測定することによる長所は、測定行為がトラヒックに影響を与えない点であるが、一方で、分析結果を各トラヒック業務で直接的に活用できない短所がある。ノードＮ０またはＮ１で測定することの長所は、パッシブ型測定装置Ｐによる測定の短所を改善する効果がある。しかしながら、ノードはパケット転送をインターネット層で行っているので、トランスポート層以上の測定も行うことは負荷を高める悪影響がある。このようにパッシプ型測定装置とノードのどちらにも長所と短所があるので、測定を行うのがどちらが適切かは一概に言えない。
【００４２】
〔実施例２〕
様々なトラヒック業務での応用例を説明する。
まず、監視業務に適用した例を説明する。
電話サービスにおいては、発呼数や同時接続回線数に基づいて監視業務が行われている。
ＴＣＰ／ＩＰアプリケーションに対しては、アプリケーション別のセッションに対して同様の測定データがあれば、同様の業務を展開することが可能である。
表２のアプリケーション別のセッション確立数Ｒ１２，Ｒ２２，．．．や同時接続セッション数Ｒ１４，Ｒ２４，．．．の時系列データを監視し、次のような分析を行うことで、異常な状態であるかどうかを把握する。
（１）ノードやリンクの処理能力を超えると予想されるぼどの急激な増加傾向
（２）ノードやリンクの処理能力を超える増加事象
【００４３】
制御業務に適用した例を説明する。
電話サービスにおいては、輻輳制御として行われている業務である。ＴＣＰ／ＩＰアプリケーションに対しては、アプリケーション別のセッションに対して同様の測定データがあれば、同様の業務を展開することが可能である。
監視業務で述べた異常状態を把握した場合など、表２のアプリケーション別のセッション確立数について、一定間隔において一定率を上限に受付ける、あるいは、一定間隔において一定数を上限に受付ける制限を予め定め、測定装置においてこれらの制限値を越えたかどうかを分析し、ノードに通知する。通知を受けたノードは制限を実行することができる。
【００４４】
管理業務に適用した例を説明する。
表２のアプリケーション別の同時接続セッション数Ｒ１４，Ｒ２４，…の時系列データを基に、次のような分析を行うことで、ネットワーク資源とトラヒック量の過不足を把握する。
（１）上記の１時間毎の時系列データの日毎最繁値について、年間上位３０個の平均値を基に、品質を保証するのに必要な帯域を求める関数Ｆｌを用いて、現在のリンクの帯域と比較する。
（２）上記の１時間毎の時系列データの日毎最繁値について、連続平日２０個の最大値を基に、品質を保証するのに必要な帯域を求める関数Ｆ２を用いて、現在のリンクの帯域と比較する。
【００４５】
予測業務に適用した例を説明する．
表２のアプリケーション別の同時接続セッション数Ｒ１４，Ｒ２４，．．．の時系列データを基に、次のような周知の時系列データの統計分析手法を用いて分析を行うことで、アプリケーション別のトラヒック需要の予測を行う。
（１）変動特性、例えば日変動、週変動、月変動、年変動を把握する。
（２）トレンド特性を把握する。
【００４６】
設計業務に適用した例を説明する。
管理業務で述べた必要帯域に、予測業務で述べた変動特性とトレンド特性を加味し、ネットワーク（ここではリンクの帯域）の設計値を算出する。
【００４７】
【発明の効果】
以上説明したように、ＴＣＰ／ＩＰアプリケーションのトラヒックについて、そのセッション数をアプリケーション別に測定することからパケット交換網のトラヒック特性を効率的に理解する効果があり、アプリケーション別セッション数のデータとアプリケーション別トラヒック特性から通信網の監視、制御、管理、予測、または、設計の方法を効率的に提供する効果がある。
更に、その方法を実施するルータや外付け装置を簡単且つ安価に提供する効果がある。
【図面の簡単な説明】
【図１】 ＴＰＣコネクションの確立と終了に対応する事象シーケンス図を示す。
【図２】 ＴＣＰコネクションの確立と終了に対応する状態遷移ダイアグラムを示す。
【図３】 トラヒック業務の階層構造を示す図である。
【図４】 本発明の第１の実施例の構成図である。
【図５】 本発明の第２の実施例の構成図である。
【図６】 ネットワーク資源の効率的使用のために必要な帯域Ｂを同時接続セッション数Ｃの関数として示す図である。
【符号の説明】
Ｃ/Ｓ−０１，０２，…，０ｎ，１１，１２，…，１ｎ 端末
Ｎ０，Ｎｌ ノード
Ｌ；Ｌ０−１，Ｌｌ−０ リンク
Ｓ；Ｓ０−１，Ｓ１−０ 信号線
Claims (12)
- 端末とノードとリンクから構成されるパケット交換網において、
端末で生成されるＴＣＰ／ＩＰプロトコルによるパケットのトラヒックについて、
ノード間の各リンクにおけるトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層で複数のアプリケーションを１つの集合としてアプリケーション集合別に、あるいは、アプリケーション別及び該アプリケーション集合別にセッションを計数する第１のステップと、
アプリケーション集合別、あるいは、アプリケーション別及びアプリケーション集合別に予め定めた分析方法を用いて上の計数結果を分析する第２のステップと、
を備えることを特徴とするトラヒックの測定、監視、制御、管理、予測、または、設計の方法。 - 第１のステップにおいて、アプリケーションの集合別、あるいは、アプリケーション別及びアプリケーションの集合別にセッション確立数、セッション終了数、及び/又は同時接続セッション数を時系列に計測することを特徴とする請求項１に記載の方法。
- 第２のステップにおいて、アプリケーション集合別、あるいは、アプリケーション別及びアプリケーション集合別のセッション確立数や同時接続セッション数の時系列データを監視し、次の分析：
（１）ノードやリンクの処理能力を超えると予想されるほどの急激な増加傾向
（２）ノードやリンクの処理能力を超える増加事象
を行うことで、異常な状態であるかどうかを把握することを特徴とする請求項２に記載の方法。 - 第２のステップにおいて、アプリケーション集合別、あるいは、アプリケーション別及びアプリケーション集合別のセッション確立数について、一定間隔において一定率を上限に受付ける、あるいは、一定間隔において一定数を上限に受付ける制限を予め定め、これらの制限値を越えたかどうかを分析し、ノードにて制限を実行することを特徴とする請求項２に記載の方法。
- 第２のステップにおいて、アプリケーションの集合別、あるいは、アプリケーション別及びアプリケーション集合別の同時接続セッション数の時系列データを基いて、次の分析：
（１）上記の１時間毎の時系列データの日毎最繁値について、年間上位数十個の平均値を基に、品質を保証するのに必要な帯域を求める関数を用いて、現在のリンクの帯域と比較する分析、
（２）上記の１時間毎の時系列データの日毎最繁値について、連続平日数十個の最大値を基に、品質を保証するのに必要な帯域を求める関数を用いて、現在のリンクの帯域と比較する分析、
を行うことで、ネットワーク資源とトラヒック量の過不足を把握することを特徴とする請求項２に記載の方法。 - 第２のステップにおいて、アプリケーション集合別、あるいは、アプリケーション別及びアプリケーション集合別の同時接続セッション数の時系列データを統計的に分析して、
（１）日、週、月または年単位の変動特性
（２）トレンド特性
を把握することで、アプリケーション集合別、あるいは、アプリケーション別及びアプリケーション集合別のトラヒック需要の予測を行うことを特徴とする請求項２に記載の方法。 - 請求項５に記載の必要帯域に、請求項６に記載の変動特性とトレンド特性を加味し、リンクの帯域の設計値を算出することを特徴とする請求項２に記載の方法。
- 請求項１〜７の何れかに記載の方法を実施するパケット交換網のノードにおいて、
該ノードを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーションの集合別、あるいは、アプリケーション別及びアプリケーションの集合別にセッションを計数する第１の手段と、
アプリケーション集合別、あるいは、アプリケーション別及びアプリケーションの集合別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段と、
を備えることを特徴とするノード。 - パケット交換網のリンクに接続され、請求項１〜７の何れかに記載の方法を実施するパッシブ型の測定装置において、
該リンクを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーションの集合別、あるいは、アプリケーション別及びアプリケーションの集合別にセッションを計数する第１の手段と、
アプリケーション集合別、あるいは、アプリケーション別及びアプリケーションの集合別に予め定めた分析方法を用いて上の計数結果を分析する第２の手段、
を備えることを特徴とする測定装置。 - 端末とノードとリンクから構成されるパケット交換網において、
端末で生成されるＴＣＰ／ＩＰプロトコルによるパケットのトラヒックについて、
ノード間の各リンクにおけるトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層で複数のアプリケーションを１つの集合としてアプリケーションの集合別に、あるいは、アプリケーション別及び該アプリケーションの集合別にセッションを計数することを特徴とするＩＰトラヒックの測定方法。 - パケット交換網のノードにおいて、該ノードを通過するＩＰプロトコルのパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーションの集合別、あるいはアプリケーション別及びアプリケーションの集合別にセッションを計数する手段を備えるノード。
- パケット交換網のリンクに付随する測定装置において、該リンクを通過するＩＰパケットのトラヒックを、ＴＣＰ／ＩＰプロトコルのセッション層で区別し、且つ、アプリケーション層でアプリケーションの集合別、あるいは、アプリケーション別及びアプリケーションの集合別にセッションを計数することを特徴とする測定装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001313374A JP3725462B2 (ja) | 2001-10-11 | 2001-10-11 | Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001313374A JP3725462B2 (ja) | 2001-10-11 | 2001-10-11 | Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003124985A JP2003124985A (ja) | 2003-04-25 |
| JP3725462B2 true JP3725462B2 (ja) | 2005-12-14 |
Family
ID=19131853
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001313374A Expired - Fee Related JP3725462B2 (ja) | 2001-10-11 | 2001-10-11 | Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3725462B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3715577B2 (ja) * | 2002-02-20 | 2005-11-09 | 日本電信電話株式会社 | 通信トラヒック分析方法および通信トラヒック分析装置 |
| JP3896111B2 (ja) | 2003-12-15 | 2007-03-22 | 株式会社日立製作所 | リソース割り当てシステム、方法及びプログラム |
| JP4535275B2 (ja) * | 2005-04-27 | 2010-09-01 | 日本電気株式会社 | 帯域制御装置 |
| JP5018663B2 (ja) | 2008-06-17 | 2012-09-05 | 富士通株式会社 | 遅延時間計測装置、遅延時間計測プログラム、および遅延時間計測方法 |
| JP5155284B2 (ja) * | 2009-11-27 | 2013-03-06 | 日本電信電話株式会社 | Ｐ２ｐトラヒック量推定方法と装置およびプログラム |
| JP2011151514A (ja) * | 2010-01-20 | 2011-08-04 | Hitachi Ltd | トラフィック量監視システム |
| JPWO2013145628A1 (ja) * | 2012-03-30 | 2015-12-10 | 日本電気株式会社 | 情報処理装置及び負荷テスト実施方法 |
-
2001
- 2001-10-11 JP JP2001313374A patent/JP3725462B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003124985A (ja) | 2003-04-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1422871B1 (en) | Network monitoring system responsive to changes in packet arrival variance and mean | |
| US6807156B1 (en) | Scalable real-time quality of service monitoring and analysis of service dependent subscriber satisfaction in IP networks | |
| JP3602972B2 (ja) | 通信性能測定装置及びその測定方法 | |
| US6957255B1 (en) | Method and apparatus for session reconstruction and accounting involving VoIP calls | |
| EP3400687A1 (en) | Bidirectional data traffic control | |
| US20030225549A1 (en) | Systems and methods for end-to-end quality of service measurements in a distributed network environment | |
| Choi et al. | Adaptive packet sampling for accurate and scalable flow measurement | |
| JP2005508593A (ja) | ネットワークで情報のルーティング制御を実現するためのシステム及び方法 | |
| JP2005509369A (ja) | データネットワーク上での情報のルーティング制御を実現するためのシステム及び方法 | |
| KR20150013800A (ko) | 아웃라이어 검출을 이용한 가입자 공정성 보장 시스템 및 방법 | |
| Attar et al. | E-health communication system with multiservice data traffic evaluation based on a G/G/1 analysis method | |
| JP3725462B2 (ja) | Ｉｐトラヒックの測定、監視、制御、管理、予測、または、設計の方法及び装置 | |
| Sun et al. | Internet QoS and traffic modelling | |
| WO2010149186A1 (en) | Estimating user-perceived tcp throughput | |
| CN103718509B (zh) | 采用自适应的传输队列长度来降低数据分组损失的系统和方法 | |
| Bagal et al. | Comparative study of RED, ECN and TCP Rate Control | |
| KR100553553B1 (ko) | 순차적인 서비스 품질(ＱｏＳ) 정보를 관리 및 제공하는시스템 및 방법 | |
| KR100358721B1 (ko) | 클라이언트/서버 시스템에 대한 큐오에스정보 및기타정보의 수집/분석 시스템 및 방법 | |
| CN113923133B (zh) | 基于quic的加密网页流量的体验质量指标监控方法 | |
| KR100959663B1 (ko) | 고성능망 지원 웹기반의 단대단 망 성능측정 및 진단시스템 및 방법 | |
| EP1228605B1 (en) | Communications network | |
| Cao et al. | The S-net system for Internet packet streams: Strategies for stream analysis and system architecture | |
| Grgic et al. | Agreements in IP-based Networks | |
| Saad et al. | Big data analysis on secure VoIP services | |
| JP3648429B2 (ja) | 通信品質推定方法および装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040210 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050414 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050621 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050822 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050913 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050921 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080930 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090930 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090930 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100930 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100930 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110930 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |