(57)【特許請求の範囲】
【請求項１】
通信ネットワークのユーザに通信ネットワーク上のネットワーク活動レベルを報告する方法であって、
（ａ）宛先サイトを選択するステップと、
（ｂ）ネットワークに対するエントリ・ポイントを選択するステップと、
（ｃ）１時間に複数回、該エントリ・ポイントから該宛先サイトまでの伝送経路を追跡し、該伝送経路に関する通過特性を収集するステップと、
（ｄ）少なくとも１日の経過にわたって該通過特性を追跡して、該伝送経路について１日の間での最高と最低の混雑レベルの期間を決定するステップと、
（ｅ）前記通過特性に基づいて、該伝送経路について混雑レベル及び１日の間での最高と最低の混雑レベルを示すネットワーク活動レベルを記憶するステップと、
（ｆ）該ネットワーク活動レベルについての報告の要求を受信するステップと、
（ｇ）該要求に応答して該記憶されたネットワーク活動レベルに基づくネットワーク活動レベルを報告するステップとを含む方法。
【請求項２】
該伝送経路が複数のリンク及び該エントリ・ポイントと該宛先サイトの間の少なくとも１つの中間ポイントを含む請求項１に記載の方法。
【請求項３】
該通過特性情報を収集するステップが、該複数のリンクに沿うパケット消失の発生を検出するステップを含む請求項２に記載の方法。
【請求項４】
該通過特性情報を収集するステップが、該複数のリンクの各々についてラウンド・トリップ伝送遅延を検出するステップを含む請求項２に記載の方法。
【請求項５】
該ネットワークが、対象とする複数の宛先サイトを含んでいて、対象とする各々宛先サイトに対してステップ（ａ）（ｂ）及び（ｃ）を繰り返すステップが含まれる請求項４に記載の方法。
【請求項６】
該ネットワーク活動レベルについての報告の要求を提示するようユーザを促すステップを含む請求項５に記載の方法。
【請求項７】
該促すステップが、対象とする宛先サイトのメニューを提供するステップを含む請求項６に記載の方法。
【請求項８】
ユーザの好みの選択に基づいて対象とする宛先サイトのメニューをカスタマイズするステップを含む請求項７に記載の方法。
【請求項９】
該通過特性情報を分析して、今までのネットワーク活動レベルを決定するステップと、
ネットワーク・ユーザによるアクセスのために該今までのネットワーク活動レベルを記憶するステップとを更に含む請求項１に記載の方法。
【請求項１０】
第１のネットワークに対するエントリ・ポイントを第２のネットワークから選択する方法であって、
（ａ）該第１のネットワークに対する第１のエントリ・ポイントを指定するステップと、
（ｂ）該第１のネットワークにおける宛先サイトを選択するステップと、
（ｃ）１時間に複数回、指定されたエントリ・ポイントから該宛先サイトまでの伝送経路を追跡し、該伝送経路に関する通過特性情報を収集するステップと、
（ｄ）少なくとも１日の経過にわたって該通過特性を追跡して、該伝送経路について１日の間での最高と最低の混雑レベルの期間を決定するステップと、
（ｅ）該指定されたエントリ・ポイントと該宛先サイトとの間の経路について、該経路についての混雑レベル及び１日の間での最高と最低の混雑レベルを示す活動レベルを記憶するステップ、
（ｆ）該第１のネットワークに対する第２のエントリ・ポイントを指定し、該宛先サイトへの経路についてステップ（ｃ）、（ｄ）及び（ｅ）を繰り返すステップと、
（ｇ）該宛先サイトにアクセスする要請を受信する際に、該活動レベルに基づいて該第１のネットワークに対するエントリ・ポイントを選択するステップとを含む方法。
【請求項１１】
エントリ・ポイントと該宛先サイトとの間の該伝送経路が、複数のリンク及び該エントリ・ポイントと該宛先サイトの間の少なくとも１つの中間ポイントを含む請求項１０に記載の方法。
【請求項１２】
該通過特性情報を収集するステップが、該複数のリンクの各々についてのラウンド・トリップ伝送時間を検出するステップを含む請求項１０に記載の方法。
【請求項１３】
データ通信ネットワークの宛先アドレスにアクセスすることに伴う混雑レベル情報を報告する方法であって、
アクセス・プロバイダ・ネットワークを該データ通信ネットワークの宛先アドレスに接続する複数のリンク上のトラヒック・レベルを監視するステップを含み、
該監視するステップは、
アクセス・プロバイダ・ネットワークからデータ通信ネットワークの宛先アドレスへの伝送経路を１時間に複数回追跡して該伝送経路についての通過特性情報を収集するステップと、
少なくとも１日の経過にわたって該通過特性を追跡して該伝送経路について１日の間の最高と最低の混雑レベルの期間を決定するステップとを含み、該方法は、さらに、
少なくとも１つのリンクについて混雑レベル及び１日の間の最高と最低の混雑レベルを示すトラヒック・レベル情報を、該アクセス・プロバイダ・ネットワークの記憶装置に記憶するステップと、
該宛先アドレスにアクセスすることを要望するアクセス・プロバイダ・ネットワークのユーザからの要求に応答して、該トラヒック・レベル情報を該ユーザに伝送するステップとを含む方法。
【請求項１４】
前記監視するステップが、
少なくとも１つのリンク上のパケット消失の発生を検出するステップを更に含む請求項１３に記載の方法。
【請求項１５】
前記監視するステップが、
少なくとも１つのリンクのラウンド・トリップ伝送遅延を測定するステップを更に含む請求項１３に記載の方法。
【請求項１６】
データ通信ネットワークのためのトラヒック報告システムであって、
データ通信ネットワークの宛先アドレスに対してアクセス・プロバイダ・ネットワークを接続する複数のリンク上のトラヒック・レベルを監視するために、デーモン・プロセスを実行するコンピュータを含み、
該デーモン・プロセスは、
アクセス・プロバイダ・ネットワークからデータ通信ネットワークの宛先アドレスへの伝送経路を１時間に複数回追跡して、該伝送経路についての通過特性情報を収集する工程と、
少なくとも１日の経過にわたって該通過特性を追跡して該伝送経路について１日の間の最高と最低の混雑レベルの期間を決定する工程とを含み、該システムは、さらに、
少なくとも１つのリンク上の混雑レベル及び１日の間の最高と最低の混雑レベルを示すトラヒック・レベル情報が記憶されているアクセス・プロバイダ・ネットワークの記憶装置と、
該宛先アドレスにアクセスするためのユーザからの要求に応答して、少なくとも１つのリンク上のトラヒック・レベル情報をユーザに伝送する手段とを含むトラヒック報告システム。
【請求項１７】
該コンピュータが、少なくとも１つのリンク上のパケット消失の発生を検出する請求項１６に記載のシステム。
【請求項１８】
該コンピュータが、少なくとも１つのリンクのラウンド・トリップ伝送遅延を測定する請求項１６に記載の方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、インターネット上で選択されたサイトのネットワーク・トラヒック情報をユーザに提供するものである。特に、本発明は、種々のインターネット・アクセス・ポイントから対象とするウェブ・サイトにいたる混雑の可能性についてインターネットのユーザに知らせるサービスを提供することを意図している。
【０００２】
【従来技術】
インターネットは、希望した情報ピースを調べて入手できる驚くべき機能をユーザに提供するパワフルなツールになってきている。ユーザがインターネットの長所を理解するにつれて、ますます数多くの情報ポイントが、一般的にウェブ・サイトの形態で提供されてきている。これらのサイトは、ユーザに異なる情報のタイプを呈する。これらのサイトの一部は、比類のないほど普及し、アクセスの要求も多い。その結果、これらのサイトは、日中の種々の時間帯で非常に混雑することになる。
【０００３】
【発明が解決しようとする課題】
そのうえ、インターネット・アクセスを提供するビジネスも発展してきている。それらの加入者にインターネットに対する１つ又は複数のエントリ・ポイントを提供するアクセス・プロバイダも数多く存在する。この例として、ユーザ１０１が、インターネット１０３に対する通路をユーザに順に呈するインターネット・アクセス・プロバイダ１０２に接続している例が、図１に図示してある。そこで、ユーザはウェブ・サイト１０４と通信できる。
【０００４】
加入者がインターネットに入り、あるサイトとの通信を希望すると、加入者はそのサイトに経路が指定されなければならない。全ての経路指定は、ルータとも呼ばれる多重中間ポイントを介して普通は行われる。このような構成の例が図２に図示してある。
【０００５】
インターネット・アクセス・プロバイダ２０２は、インターネットに対する２つのアクセス・ポイント２０２Ａと２０２Ｂを備えている。このプロバイダの加入者がウェブ・サイト２１０との通信に興味があるとする。加入者は任意の数の方式で希望したウェブ・サイトに経路が指定される。例えば、加入者は、エントリ・ポイント２０２ＡからノードＡ（ルータとも呼ばれる）にインターネットで経路指定される。そこで、加入者は、ノードＣ、ノードＤ、最終的に希望したウェブ・サイトに経路指定される。各々ノードは、加入者をそのノードからその最終宛先に最も能率的に転送できると考えるものを選択できるインテリジェンスを備えている。そのインテリジェンスに少し制限がある。普通、経路指定の決定は、特に複雑な計算を必要とするので、実際の負荷条件に基づいていない。代わりに、その決定は、ネットワークのトポロジー、例えば、動作不能のルータや回線の動作状態（混雑している又はしていない）の認識に基づくと思われる。問題の加入者は、希望したウェブ・サイトに到達する前に代わりに、入り口２０２Ａから、ノードＡ、次にノードＢ、次にノードＣ、ノードＦ、ノードＥ、そして最終的にノードＤに経路指定されるかもしれない。ノード間のこれらのリンクの各々がホップと呼ばれる。これらのリンクの一部は、それらが臨界状態のノード間の主要な通路として作用するので、非常に高いトラヒック・リンクになる。代わりに、それらは、人気のあるウェブ・サイトに特に関係する又は結合するリンクになる。このケースで、関係するウェブ・サイトの人気が、そのリンクのトラヒックを増加させる結果になる。
【０００６】
普通、ユーザには、アクセス・プロバイダのエントリ・ポイントを基準にしてユーザ位置に準じてインターネット・アクセス・ポイントが指定される。トラヒック経路がインターネットのユーザ・エントリ・ポイントから対象とするウェブ・サイトにかけて、どの程度混雑しているかについて、ユーザが認識できることが望ましい。
【０００７】
【課題を解決するための手段】
本発明は、経路に沿う混雑状態をインターネットに対するアクセス・プロバイダのエントリ・ポイントから希望したウェブ・サイトにかけて定期的に分析する方法を提供する。混雑情報は、１つ又は複数のアクセス・プロバイダ・サービス・データベース・プラットフォームに記憶されている。ユーザは、混雑状態報告サービスの活用を強調して表示する指示要素を自動的に備えている。ユーザは、対象とするウェブ・サイトを選択して、アクセス・プロバイダからそのウェブ・サイトにいたる経路に沿う混雑状態を確認できる。そのうえ、ユーザには、そのサイトに関連する情報を入手するために、対象とする特定のウェブ・サイトを指定できるオプションが提供される。
【０００８】
本発明は、特定の宛先への経路を追跡するためにインターネット上で既に使用できる単純なコマンドを利用する。本発明は、繰り返し、このコマンドを対象とする１つ又は複数のウェブ・サイトに関して実行して、インターネットのエントリ・ポイントから希望したウェブ・サイトにかけての通過特性に関する重要な情報を編集する。このような特性として、希望したウェブ・サイトにいたる通路に沿うルータとインターネット・アクセス・ポイントとの間のラウンド・トリップ時間がある。特性には、コマンドの実行中に経路に沿って消失したデータ・パケットの数の平均を含めることもできる。分析には、平均ラウンド・トリップ遅延と経路追跡の実行から入手できるパケット消失情報とに基づいて、混雑していると思われる特定のホップを識別することも含まれている。
【０００９】
そのうえ、インターネットに対する多重エントリ・ポイントを有するサービス・プロバイダのために、この混雑情報を用いて、加入者が通信を試みるウェブ・サイトに基づいて対象とする加入者に最適のエントリ・ポイントを選択することができる。
【００１０】
【実施例】
従来技術で述べたように、図２は、インターネット・アクセス・プロバイダのアクセス・ポイントと特定のウェブ・サイトとの間のネットワーク接続を示す周知の構成を描いている。本発明に基づいて、１つ又は複数の重要な宛先が周知の人気のあるサイトから選択される。代わりに、あるサイトの人気が次に記すトラヒック監視動作に準じて決まる、すなわち、アクセス・プロバイダは、半ば無作為にサイトを選択できる（例えば、あるサイトの過去の資料に基づく既知のヒット数のような規準に基づいて、選択したウェブ・サイトのトラヒックを調べる）。次に、トラヒックの監視状態に基づいて、アクセス・プロバイダは、あるウェブ・サイトのサブセットが特に人気があると決定する。代わりに、サイトは、人気のあるメディアの説明に又は主なオンライン・ソースに基づいて選択され、“日中は落ち着いているサイト”として取り扱われる。
【００１１】
次に、アクセス・プロバイダは、そのプロバイダを介して使用できるインターネットに対する種々の接続ポイントを識別する。プロバイダは、標準ツールを用いて、インターネットに対するあるエントリ・ポイントとこれらの所定の重要な宛先の１つとの間の通過特性を検出する。“経路追跡コマンド”ツールの動作について、次に更に詳細に説明する。しかし、このコマンドを実行すると、末端ポイント間のホップと、インターネットのエントリ・ポイントから希望したウェブ・サイトにかけての複数のリンクの各々との間のラウンド・トリップ伝送時間と、データ・パケットが消える又はドロップする頻度とに関する重要な情報が、提示されることになる。
【００１２】
あるエントリ・ポイントからウェブ・サイトにいたる通路の選択は、時間を変更できる動的プロセスに実際になることに注目すべきである。通路は、接続が構築されているので、種々のノードで行われた中間決定から決まる。例えば、時刻Ｔ１で、ノードＡは、ネットをウェブ・サイトＸに進めるために最適の経路を計算して、ノードＣとのリンクを構築する。少し後の時刻Ｔ２で、ノードＡは、最適経路がノードＣよりノードＧのリンクを現実にはコールすると決定する。前述のように、経路の決定は、ネットワーク形式、例えば、ライン状態（混雑している又は混雑していない）に関する情報に基づいて普通は行われる。ノード・リンク又はホップを定める優先的な選択は、普通、数分間安定した状態を保つ。従って、本発明のこの特長を実行すると、ネットワークが混雑する時間帯に対してスナップ・ショットを実施できることになる。効果的な情報源とするために、混雑状態を定期的に監視して、その間で生じる経路変更を把握しなければならない。本発明に基づいて、これは、例えば、１時間に５〜６回実施できる。
【００１３】
特定のエントリ・ポイントから希望したウェブ・サイトにいたる通過特性の収集について、次に述べる。
【００１４】
経路追跡コマンドは、インターネットのあるポイントから別のポイントにかけて接続経路を追跡する周知のコマンドである。経路追跡コマンドは、パケットをインターネットの種々のポイントを介して始点ノードから宛先ノードに転送することを実際に試みる。コマンドは、ホップの最大数、すなわち、２つの端末間で許容できる中間リンクの設定と共にセットされる。更に、コマンドから、転送されるデータ・パケットのサイズが決まる。次に示す例では、経路追跡コマンドは、ウェブ上で人気のあるサイト、すなわち、ｗｗｗ．ｎｅｔｓｃａｐｅ．ｃｏｍに対して実行される。コマンドは、最大ホップのデフォルト数が３０であり、パケット・サイズが４０バイトでセットされるように、セットされる。
【００１５】
実際に実行すると、コマンドから、経路が一連の反復動作で定まる。まず、システムは、１つのホップ転送を指示し、コマンドを実行するパーティが選択できる所定の回数だけ、この転送を試みる。それは、アクセスごとに選択される第１のホップに相応するラウンド・トリップ伝送時間を検出する。次に、２つのホップが可能になり、コマンドが非常にはやく実行しているので、経路指定は、第１のホップを介してアクセスした第１のノードと第２のノードとを介することになる。ラウンド・トリップ伝送時間が再び検出される。経路確認の実行ごとに１つの更なるホップを可能にする動作は、接続が希望したウェブ・サイトに構築されるまで続く。
【００１６】
この経路追跡コマンドの１つの実行の結果について次に示す。
$ traceroute www.netscape.com
ｔｒａｃｅｒｏｕｔｅ  ｔｏ  ｗｗｗ１．ｎｅｔｓｃａｐｅ．ｃｏｍ  （１９８．９５．２５１．３０），  ３０  ｈｏｐｓｍａｘ，  ４０  ｂｙｔｅ  ｐａｃｋｅｔｓ
１  ｇｅｄ  （１３５．１０４．１０４．１）  ３．５２６  ｍｓ  ３３．６３５  ｍｓ  １０６．０９９  ｍｓ
２  ｈｕｂｂｌｅ−ｒｂｏｎｅ  （１３５．１０４．１．７）  ３．４０４  ｍｓ  ５．８２８  ｍｓ  ５．０３４  ｍｓ
３  ｓｔｉｌｅ  （１３５．１０４．２．７）  １８９．５２６  ｍｓ  １２８．３５１  ｍｓ  ４５．６６３  ｍｓ
４  １９２．２０．２２５．１  （１９２．２０．２２５．１）  ５７．５１６  ｍｓ  ５９．２２７  ｍｓ  １４．０９７ｍｓ
５  Ｎｅｗ−Ｂｒｕｎｓｗｉｃｋ１．ＮＪ．ＡＬＴＥＲ．ＮＥＴ  （１３７．３９．１８６．１６１）  ２８．３  ｍｓ２４．３６３  ｍｓ  ２０．８２  ｍｓ
６  １３７．３９．１０８．３  （１３７．３９．１０８．３）  ２２．７８１  ｍｓ  ２６．８０２  ｍｓ  ２２．３２８ｍｓ
７  １３７．３９．１００．１４  （１３７．３９．１００．１４）  ２１．７６４  ｍｓ  ２９．４８５  ｍｓ２４．０６  ｍｓ
８  １３７．３９．３３．９９  （１３７．３９．３３．９９）  ２６．６３  ｍｓ  ２９．８１９  ｍｓ  ２７．６８５ｍｓ
９  １３７．３９．１００．２９  （１３７．３９．１００．２９）  ３４．９９２  ｍｓ  ３３．０６３  ｍｓ３６．２４９  ｍｓ
１０  ｓｐｒｉｎｔｎａｐ．ｍｃｉ．ｎｅｔ  （１９２．１５７．６９．１１）  ３７．３３６  ｍｓ  ２２５．０７３ｍｓ＊
１１  −ｈｓｓｉ３−０．ＷｅｓｔＯｒａｎｇｅ．ｍｃｉ．ｎｅｔ  （２０４．７０．１．２０９）  ７０．６５６  ｍｓ２４８．１  ｍｓ  ２３８．２０２  ｍｓ
１２  ｃｏｒｅ  ２．ＳａｎＦｒａｎｃｉｓｃｏ．ｍｃｉ．ｎｅｔ  （２０４．７０．２０１）  ３１３．６９４  ｍｓ２１２．７１３  ｍｓ  １１３．８３４  ｍｓ
13 *borderx2-fddi-1.SanFrancisco.mci.net (204.70.158.68)186.739 ms*
１４  ２０４．７０．１５８．１２２  （２０４．７０．１５８．１２２）  １６７．２４３  ｍｓ  ２３６．７３７  ｍｓ２４４．５４９  ｍｓ
15 www1.netscape.com (198.95.251.30) 102.303 ms 105.281ms 99.058 ms
【００１７】
このコマンドは、情報の３つの貴重なピースを与える。第１に、それは、各々ルータ、例えば、“ｈｕｂｂｌｅ−ｒｂｏｎｅ”をホップ２で識別する。第２に、それは、ラウンド・トリップ時間値の数を与えられたルータに始動ポイントから呈する。第３に、それは、データ・パケットが消失する時を示す。例えば、経路指定識別子１３５．１０４．１０４．１を有する、ｇｅｄと識別された第１のノードが、変動するラウンド・トリップ伝送時間により３回アクセスされることが分かる。第２のノード−ｈｕｂｂｌｅ−ｒｂｏｎｅ（１３５．１０４．１．７）が次に分析される。これは、ステップ１５だけ、接続がｗｗｗ１．ｎｅｔｓｃａｐｅ．ｃｏｍの最終希望宛先に構築されるまで続く。試験中に、一部のパケットがドロップされる。これは、ラウンド・トリップ時間の代わりにアスタリスク（＊）により各々通路試験で指示される。
【００１８】
この事例では、ラウンド・トリップ時間はホップ１０で劇的に増加する。ホップ９で、時間は、３３．０６３ｍｓ〜３６．２４９ｍｓの範囲になる。しかし、ホップ１０では、１つのラウンド・トリップ時間が２２５．０７３ｍｓであり、１つのデータ・パケットが消失又はドロップする。かなり長いラウンド・トリップ時間とパケット・ドロップとの可能性が、ホップ１０からホップ１５にかけて続く この分析の結果、インターネット・アクセス・プロバイダは、ホップ１０で混雑状態が存在するので、処理量は、この通路で大きくないことが分かる。
【００１９】
第２の例として、イギリスのケンブリッジ大学のメール・サーバに対する経路追跡について次に示す。
$ traceroute ppsw3.cam.ac.uk
traceroute to ppsw3.cam.ac.uk (131.111.8.38), 30 hopsmax, 70 byte packets
１  ｇｅｄ  （１３５．１０４．１０４．１）  ３．１１４  ｍｓ  ２．４２１  ｍｓ  ２．２７５  ｍｓ
２  ｈｕｂｂｌｅ−ｒｂｏｎｅ  （１３５．１０４．１．７）  ３．６２７  ｍｓ  ８１．９６９  ｍｓ  ３．７５２  ｍｓ
３  ｓｔｉｌｅ  （１３５．１０４．２．７）  ９．４８５  ｍｓ  ３．８８５  ｍｓ  ７．７０３  ｍｓ
４  １９２．２０．２２５．１  （１９２．２０．２２５．１）  １２．１７６  ｍｓ  ８．１７６  ｍｓ  ６．１２３ｍｓ
５  Ｎｅｗ−Ｂｒｕｎｓｗｉｃｋ１．ＮＪ．ＡＬＴＥＲ．ＮＥＴ  （１３７．３９．１８６．１６１）  ２１．９６３  ｍｓ２０．０６６  ｍｓ  ４８．４９４  ｍｓ
６  １３７．３９．１０８．３  （１３７．３９．１０８．３）  ７５．５１  ｍｓ  １１８．４７８  ｍｓ  ２２．６７ｍｓ
７  １３７．３９．１００．１４  （１３７．３９．１００．１４）  ６２．６２５  ｍｓ  １６．７５６  ｍｓ２０６．４８３  ｍｓ
８  １３７．３９．３３．９９  （１３７．３９．３３．９９）  １３０．２２７  ｍｓ  １６２．４５２  ｍｓ２１．０５２  ｍｓ
９  １３７．３９．１００．２９  （１３７．３９．１００．２９）  ４２．８３  ｍｓ  ３３．６１  ｍｓ  ３８．１４７ｍｓ
１０  ｆ０−０．ｅｎｓｓ２１９．ｔ３．ａｎｓ．ｎｅｔ  （１９２．１５７．６９．１３）  ３４．２６２  ｍｓ２８．２４５  ｍｓ＊
１１  ｈ２−０．ｔ３２−０．Ｎｅｗ−Ｙｏｒｋ．ｔ３．ａｎｓ．ｎｅｔ  （１４０．２２３．３３．１２９）７５．０４９  ｍｓ  ３６．２８８  ｍｓ  ７６．３６２  ｍｓ
１２  ｈ５−０．ｔ３６−１．Ｎｅｗ−Ｙｏｒｋ２．ｔ３．ａｎｓ．ｎｅｔ  （１４０．２２３．３３．１０）１３１．３８１  ｍｓ  ５０．８３４  ｍｓ  ４７，８０９  ｍｓ
１３  ｆ０−０．ｃ３６−１１．Ｎｅｗ−Ｙｏｒｋ２．ｔ３．ａｎｓ．ｎｅｔ  （１４０．２２３．３６．２２２）４７．２６  ｍｓ  ５９．４２２  ｍｓ  ３３．５９  ｍｓ
１４  Ｄａｎｔｅ−ＵＫＥＲＮＡ．ｔ３．ａｎｓ．ｎｅｔ  （２０４．１５１．１８４．２６）  ２３３．１８３  ｍｓ２００．４０９．  ｍｓ＊
15 smds-gw.ulcc.ja.net (193.63.94.12) 211.977 ms 222.577ms 216.284 ms
16 smds-gw.cam.ja.net (193.63.203.36) 237.009 ms 337.539ms*
１７  ｒｏｕｔｅ−ｃｅｎｔ−１．ｃａｍ．ａｃ．ｕｋ  （１３１．１１１．１．６２）  ２１２．３４２  ｍｓ＊２０８．９４６  ｍｓ
18 mauve.csi.cam.ac.uk (131.111.8.38) 234.515 ms 266.596ms*
【００２０】
この結果を見ると、パケット消失の問題がホップ１４から出てくることが非常によく分かる。実際に、パケットの約１／３がホップ１４からドロップし、非常に低い特性になることを示唆している。これは混雑問題の一面を含んでいる。
【００２１】
インターネットに対するアクセス・プロバイダのエントリ・ポイントの各々に関連する生のデータが、数多くの方式で収集できる。例えば、アクセス・プロバイダは、各々エントリ・ポイントの“エージェント”を離すことができる。これらのエージェントは、図３で３２０Ａと３２０Ｂとして図示してある。各々エージェントは、プログラム設定したプロセッサと記憶機能とを備えている。プログラムは、図４と５に関連して次に示すステップを実行する。各々エージェントは、独自に、データ収集動作を実施し、それを次のように処理して、そのエントリ・ポイントに指定されたユーザが使用できるようにする。代わりに、プロバイダは、エントリ・ポイントごとに通過特性を収集する中心データ収集者になることもできる。
【００２２】
経路の混雑状態に関するスナップショットが時間帯に相応して正確であると想定するために、エージェントは、コマンドが各々宛先に関して１時間に５〜６回実行されるように、希望した宛先のリストを定期的に周期的に調べる。
【００２３】
どのように情報がインターネットを介する接続から収集されるかについて、前述のように説明される。本発明は、この情報を編集し、選択された着信ポイント間の通過特性を導き出すものである。この通過特性情報は、アクセス・プロバイダのデータベースに記憶される。情報は種々の形態で記憶できる。例えば、ラウンド・トリップ伝送時間や消失パケット・データに関する生のデータがデータベースに記憶できる。代わりに、計算又は推定が検出データに基づいて実施できて、データベースは、特定のウェブ・サイトに対するリンクの状態に関する情報、例えば、非常に混雑している、それほど混雑していない、クリアな状態などのような情報を記憶できる。
【００２４】
ある可能性のある実施例では、この計算は、平均ラウンド・トリップ時間とホップで消失したデータ・パケットの平均数とを分析して、混雑状態が現れるホップを識別する。この分析は、ホップで平均ラウンド・トリップ時間と消失したパケットの平均数とが素早く又はスパイクのように増加したかどうかについて決定するために、データを調べることも含んでいる。ｎｅｔｓｃａｐｅ．ｃｏｍへの経路が追跡される前述の第１の例では、平均ラウンド・トリップ時間は、ホップ１からホップ９にかけて滑らかに増加している。しかし、ホップ１０では、劇的に増加し、次のホップの間、高い状態を維持している。これは、ホップが混雑状態にあることを示している。同じことが、データ・パケットを消失する頻度の増加についても言うことができる。従って、この分析は、アクセス・プロバイダに、ウェブ・サイトへの経路が混雑しているかどうか、どの経路に沿うリンクが対応可能であるかについて指示できる。当然、データベースは、これらの情報のタイプから成る組合せを記憶し、末端ユーザに、経路追跡コマンドを実行して収集した生のデータに準じて適切に計算した情報を提供できる。
【００２５】
一端情報を得ると、プロバイダは、情報を末端ユーザに提示する方式を有することになる。
【００２６】
本発明に基づいて、加入者がインターネットへの接続を希望することをアクセス・プロバイダに知らせる実施例では、プロバイダは、使用可能なサービスのオプション数を加入者に与える確認のための“ページ”を自動的に提供する。あるこのようなオプションとして、ある図形表示要素、例えば、ヘリコプター・アイコンで指示されるトラヒック報告オプションがある。一端加入者がトラヒック報告アイコンを選択すると、アクセス・プロバイダのデータベースは、種々のメニュー項目を加入者に、例えば、宛先の選択を含んでいるユーザ・ファイルを提示できる。これらの宛先は、トラヒック情報が望まれる可能性のある着信ポイントとしてユーザに提示できる。ユーザが希望した末端宛先を選択すると、データベースは、その宛先サイトに関連するトラヒック情報にアクセスする。
【００２７】
トラヒック報告サービスに基づく別のオプションとして、希望したウェブ・サイトの各々に相応する通過特性を分析して、あるウェブ・サイトに対する接続の最適時間について加入者にアドバイスすることを意図して、ピーク・ロードとロー・ロード・タイム・フレームとを計算することがある。これは、従来技術で周知の日中夕刻監視プログラム（デーモン）を用いて行われる。このようなプログラムに基づいて、経路に沿う混雑状態を、１日中追跡して、最も厳しい及び最も軽いトラヒックの時間帯を決定する。
【００２８】
末端ユーザが使用できるサービスの更なる変形事例では、アクセス・プロバイダは、経路指定オプションの各々に関する情報と共に、多重アクセス・ポイントから希望したウェブ・サイトにいたる経路を、地図のような表示方式で、オプションで提供できる。このインターネット構成の場合に、ユーザは、あるウェブ・サイトに経路指定されるコールについて、それほど多く選択できない。しかし、複数の入り口ポイントのなかの任意の１つから希望したウェブ・サイトにいたる経路に関して収集した統計資料を、インターネット・アクセス・プロバイダ自ら用いて、インターネットに対するユーザの接続を最適にできる。例えば、図２に示すように、アクセス・ポイント２０２ＢからノードＧ、Ｆ、Ｅ、Ｄを経由してウェブ・サイトにいたる経路が、エントリ・ポイント２０２Ａから始まってホップＡ〜ＣとＣ〜Ｄを経由する場合より混雑しないと判定される場合、アクセス・プロバイダは、これらの２つのエントリ・ポイントに関する加入者の地理的位置にかかわらず、アクセス・ポイント２０２Ａよりむしろアクセス・ポイント２０２Ｂを経由してインターネットに加入者を接続することを選択すると思われる。
【００２９】
本発明は、図４と５のフローチャートに準じて、選択した宛先サイトに対する経路追跡コマンドの多重実行から通過特性情報を編集するために開発したソフトウェアによってサポートされている。
【００３０】
特に、ソフトウェアは、対象とする宛先サイトを、ステップ４０１で識別する。それは、インターネットに対する選択エントリ・ポイントと対象とするサイトとの間のトラヒック状態を、ステップ４０２で検出する。次に、それは、アクセス・プロバイダ・データベースの検出されたトラヒック情報をステップ４０３で保存する。
【００３１】
検出動作は、図５のステップに準じて行われる。特に、検出エージェントは、“経路追跡”を選択したエントリ・ポイントから選択したウェブ・サイトにかけて、ステップ５０１で実行する。ソフトウェアは、“経路追跡”を実行した結果から、ホップごとの平均ラウンド・トリップ時間を、ステップ５０２で分析する。次に、ソフトウェアは、“経路追跡”を実行した結果に基づいて、ホップごとに消失したパケットの平均数を、ステップ５０３で分析する。次に、ソフトウェアは、ウェブ・サイトのトラヒック・レベルの特長を定め、検出済みのデータに基づいて混雑ポイントを、ステップ５０４で識別する。
【００３２】
更に、ソフトウェアは、情報に適した表示スタイルを生成し、例えば、加入者に提示されるサービス・ボタンとメニュー・ルーチンを表示して、サービスの利用を推進する。これらの修正の全ては、当業者には周知のことである。
【００３３】
本発明は、周知のツールを用いて、対象とするウェブ・サイトの混雑状態に関する情報を収集して、この情報を論理的で効果的な形式で提示し、加入者が希望するウェブ・サイトの混雑状態と混雑の発生源と思われるリンクとを加入者に知らせて、特定のウェブ・サイトにアクセスするための最適時間帯を加入者にアドバイスする。そのうえ、本発明は、インターネット・アクセス・プロバイダ自体に役に立つ経路情報を呈するので、プロバイダは、ある加入者と対象とするウェブ・サイトとのためにインターネットのエントリ・ポイントを最も効果的に選択できる。この編集され分析された通過特性情報は、特定のウェブ・サイトに相応する処理量を呈する能力について、ネットワークの状況に関する重要な情報をユーザとアクセス・プロバイダ自体にアドバイスするうえでも、他のサービスの基本となるものである。
【図面の簡単な説明】
【図１】周知のネットワーク構成の略図である。
【図２】詳細に図１の構成要素を示す略図である。
【図３】本発明の実施例を包含するネットワーク構成の略図である。
【図４】本発明に基づくサービス・プロセスを説明するフローチャートである。
【図５】本発明に基づくサービス・プロセスを説明するフローチャートである。
【図１】
0003659448.tif 000002
【図２】
0003659448.tif 000003
【図３】
0003659448.tif 000004
【図４】
0003659448.tif 000005
【図５】
0003659448.tif 000006