JP4348124B2

JP4348124B2 - ＱｏＳを推定する方法および通信装置

Info

Publication number: JP4348124B2
Application number: JP2003185272A
Authority: JP
Inventors: エムマッタジョニー
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2002-06-28
Filing date: 2003-06-27
Publication date: 2009-10-21
Anticipated expiration: 2023-06-27
Also published as: US20040001511A1; US7525923B2; JP2004040793A

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＰ通信ネットワークに関するものである。より詳細には、ＩＰネットワーク上の通信経路に対するサービスの品質（ＱｏＳ）の推定方法およびその方法を利用する装置に関するものである。
【０００２】
【従来の技術】
インターネットの「ベストエフォート」特性は、エンドユーザが認識するＱｏＳ（サービスの品質）を、予想不能にし、また時には大きく変化させる。そのため、ＩＰネットワークのＱｏＳ性能を推定するための、早く、正確で、有効なツールは、ネットワーク通信において重要性を増している。パケットネットワーク、特にインターネットに固有の時々刻々変化する条件下で予想されるユーザおよびプロバイダに対するサービスを維持するため、ＱｏＳに関する情報を使用できるようにするためである。具体例としては、輻輳制御、リアルタイムストリーミングと双方向通信、ＱｏＳ検証、サーバの選択、およびネットワークの管理等が挙げられる。
【０００３】
ＱｏＳ推定方法は、大きく２つのカテゴリに分類することができる。それは、受動的推定方法と能動的推定方法である。受動的推定方法は、ネットワークに測定用の新たなトラフィックを必要としないという利点がある。受動的測定方法は、ネットワークをありのまま測定する。すなわち、測定のための測定トラフィックにより現在のネットワークが乱されることがないので、真のネットワーク挙動が測定される。
【０００４】
測定は、処理能力、記憶容量、および利用可能なリソースの程度により種々のレベルの細分性で行うことができる。パケット測定は、例えば、パケット遅延変化、パケットサイズ分布、およびホスト間のスループットのようなパケット毎の情報の測定を可能にする。より高レベルの、オーバーヘッドの少ない測定は、送信された総バイト数、フローの開始／終了時刻を記録するフローレベル測定により実現できる。
【０００５】
受動的測定技術の主な利点は、測定しようとするネットワークに負荷をかけない点である。これはまた、ネットワークのトラフィックを歪ませないため、実際のネットワーク状態に近い推定を可能にすることを意味する。しかしながら、受動的測定技術の欠点は、実際に存在するトラフィックに依存するので、そのトラフィックが、ある測定に必要とされる特性を有することが保証されないことである。ボトルネック帯域幅の測定技術は、例えば、一定のパケットサイズ分布、パケット間の出発速度を必要とする。トラフィック測定は、ネットワークの性能を推定する目的で受動的に測定トラフィックの特性を測定するものである。
【０００６】
ＳＮＭＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃａｌ）およびＲＭＯＮ（ＲｅｍｏｔｅＭｏｎｉｔｏｒｉｎｇ）は、受動的測定に最も広く採用されている標準的なものであり、様々なネットワーク要素（ホスト、ルータ、交換機）にインストールされた管理エージェントあるいは測定用のデータ、エージェントから収集されたデータを含むＭＩＢ（ＭａｎａｇｅｍｅｎｔＩｎｆｏｒｍａｔｉｏｎＢａｓｅ）、測定用のデータから情報を収集する管理局／コンソール、および管理局／測定用のデータ間での情報交換のためのプロトコルから構成される。ＭＩＢは、物理層あるいはＩＰ層で収集されたパケットサイズの統計、ＣＲＣ（巡回冗長検査）による誤り等々の様々なグループを有する。管理制御を利用したトラフィック測定は、収集された情報をエージェントからコンソールに転送することを必要とする。測定対象であるネットワークへの負荷はこの程度である。時には、交換されるトラフィックの量を減少させるためにデータのサンプリングを使用することができる。
【０００７】
一方、能動的測定方法は、測定用のデータをネットワークに送信し、通信相手に送信されるまでの遅延、遅延の変化量、および損失の観点から測定用のデータが受ける処理を測定することによりネットワークのＱｏＳを推定する方法である。遅延、ジッタ、パケット損失、帯域幅といった観点から性能を推定するために、多様なツールが存在する。これらのツールは通常、インターネット制御メッセージプロトコル（ＩＣＭＰ）の誤り通報能力、あるいはパケット分散技術のいずれかを用いる。
【０００８】
ビット／秒単位でのリンクの情報路容量の推定は、伝統的にパケット分散技術を用いて行われてきた。パケット分散技術とは、２つ以上のパケットグループを継続的に送信することにある。それは、同一のグループからのパケットは、経路のボトルネックリンクにおいて次々に待たされる（キューイングする）という概念に基づいている。他の競合トラフィック（すなわち、他の発呼端末からのトラフィック）からの干渉がなければ、その分散（すなわち、受信先におけるパケット到着時間の差異）は、ボトルネックの帯域幅に反比例する。この方法を用いたツールの例としては、Ｎｅｔｔｉｍｅｒ、Ｐａｔｈｒａｔｅ、およびＰａｃｋｅｔＢｕｎｃｈＭｏｄｅ（ＰＢＭ）がある。
【０００９】
情報路容量推定の別の方法は、ＩＣＭＰの時間超過メッセージ（ＴｉｍｅＥｘｃｅｅｄｅｄｍｅｓｓａｇｅ）のオプションに基づくものである。この技術のはしりであるＰａｔｈｃｈａｒというツールは、ＩＰ寿命（ＴＴＬ）値を増加させながらパケットを送信することにより測定を行う。これにより、経路にあるルータは、ＩＣＭＰエラーメッセージを返信し、そのルータ自身を明らかにするのである。エンド・ツー・エンド（ｅｎｄ−ｔｏ−ｅｎｄ）の経路上の連続するホップに対する往復遅延の測定により、ホップ毎の遅延の測定が可能になる。Ｐａｔｈｃｈａｒはまた、各ＴＴＬ値に対してパケットのサイズを変化させる機能を有する。これにより、リンクの情報路容量を、各パケットサイズに対して測定された遅延の最小値を結ぶ線の傾きの逆数として推測するのである。ＰｃｈａｒやＣｌｉｎｋといった他のツールも存在するが、それらもＰａｔｈｃｈａｒと同一の概念に基づいている。
【００１０】
ＣｐｒｏｂｅおよびＰｉｐｅｃｈａｒは、経路上の利用可能な帯域幅を推定するために提案された最初のツールである。これらのツールは、長いパケットトレイン（複数のパケット）の分散を使用している。そのようなパケットトレインの分散は、ボトルネックのホップにおいて、送信に利用可能な速度、すなわち利用可能な帯域幅に反比例すると仮定している。しかしながら、最近の研究では、そのような分散の逆数では実際は利用可能な帯域幅を測定できず、ＡＤＲ（非対称データ速度）と呼ばれる別のパラメータを測定することになることが示されている。
【００１１】
Ｄｅｌｐｈｉという別のツールは、インターネット経路は単一のキューによりモデル化されると仮定している。その仮定によると、経路上のいくつかのリンクにおいて大きなキューイング遅延が存在する場合に、あるいは、ボトルネックの情報路容量とボトルネックの利用可能帯域幅リンクが異なるリンクに位置する場合は、Ｄｅｌｐｈｉの性能は悪化する。
【００１２】
現在において、利用可能帯域幅を推定できるツールは、Ｐａｔｈｌｏａｄと呼ばれるツールしか知られていない。Ｐａｔｈｌｏａｄは、受信先で測定されるエンド・ツー・エンドの遅延は、発呼端末の送信速度が経路の利用可能帯域幅を超えたときに増加するという単純な原理に基づいている。現実的な測定では、ボトルネックが処理できる速度よりも高速で経路に注入されたトラフィックがそのホップでキューを起こし、それによりキューイング遅延および全体の遅延が増加することが知られている。
【００１３】
Ｐａｔｈｌｏａｄは、各ホップにおける転送速度を変化させ、受信先における遅延の変化を測定するといった動作を繰り返し行うことにより作動する。ポイントは、遅延を増加させない最高速度を発見することである。
【００１４】
【発明が解決しようとする課題】
本発明は、ＩＰネットワークにおける通信経路（ＩＰネットワーク上の２つのルータあるいはホスト間のものであることが好ましい）に対するＱｏＳ推定を提供する方法を開示するものである。
【００１５】
【課題を解決するための手段】
ＱｏＳ推定技術は、要求される通信経路にポーリングする通常の原理に基づいて使用される。好適な方法は、次のように構成される。まず、対象となるエンド・ツー・エンドの経路上の全てのルータ／ホストのネットワークアドレスを特定する。次に、タイムスタンプ要求を経路上の各ルータ／ホストに送信する。最後に、その方法は、ＱｏＳ推定値を算出するために、ルータ／ホストから返信されたタイムスタンプ要求の処理を要求する。本発明において、「ホップ」という単語は、各ノード間のエンド・ツー・エンドの経路上にあるルータ／ホストを総称するために使用される。
【００１６】
【課題を解決するための手段】
好適な実施形態において、経路上のホップのアドレスを得るための技術は、Ｔｒａｃｅｒｏｕｔｅアプリケーションを使用することである。加えて、タイムスタンプ要求は、ＩＣＭＰタイムスタンプ要求／返信機能を使用して得られる。本発明は、要求される経路上の全てのホップのアドレスを決定するためにＴｒａｃｅｒｏｕｔｅを使用することから開始する。次に、５つのＩＣＭＰタイムスタンプ要求からなるグループが、経路の一端の発呼端末から測定対象の経路上の各ルータに送信されるのが好ましい。各グループの最初の３つのパケットは、対応するホスト／ルータ（すなわち、ホップ）に対する測定の初期条件を決定するために使用される。５つのパケットからなるグループのうち残りの２つの測定パケットは、対応するホップにおいて、ＩＣＭＰ要求パケットにより費やされた時間の総和の推定値を得るために使用される。
【００１７】
さらに、もう１対の同様なＩＣＭＰタイムスタンプ要求パケットが、同様に各ホップでＩＣＭＰ要求により費やされた時間の合計を推定するために規則的な間隔で各ホップに送信される。そのような継続的測定は、各ホップにおけるキューイング遅延変化の推定のために使用される。本発明の好適な実施形態において、推定値は測定を開始した発呼ノードで算出される。さらに別の実施形態において、そのような推定値は受信先あるいは宛先ノードで算出される。
【００１８】
本発明の好適な実施形態において、各ホップにおけるサービス時間の合計およびキューイング遅延の変化は、各ホップにおいて経路方向の利用率の推定のために使用される。それは、リンクにおいて競合トラフィックに使用されていない、空いている送信リソースの部分を指す。算出される推定値はまた、経路方向の各リンクの利用可能な帯域幅の推定のために使用される。利用可能な帯域幅は、リンクが輻輳およびキューの発生なしにさらに維持することができる速度を指す。加えて、推定値は、競合する発呼端末からリンクに導入されるトラフィックの速度を推定するために使用される。
【００１９】
本発明の好適な実施形態において、提案されたアプリケーションは、ＱｏＳ測定を開始した１つのノードにのみ存在する。このノードは、ホップから収集されたタイムスタンプ値に基づいてＱｏＳ推定のために必要な処理を行う。別の実施形態において、提案されたアプリケーションは、測定対象となる経路の発呼端末および受信先の両方に存在してもよい。その場合、受信先は、収集されたタイムスタンプ値を処理する役割をもつ。その違いは、ルータに送信されたＩＣＭＰパケットは宛先端末に対しスプーフィングするアドレスを有し、したがって応答はＩＣＭＰ要求をした発呼端末ではなく受信先に送信されることである。
【００２０】
本発明のさらなる目的および利点は、本発明の好適な実施形態を図示した図面を参照しながら以下の説明で明らかになる。
【００２１】
【発明の実施の形態】
まず図１を参照して説明する。ＩＰネットワーク１０は、少なくとも２つの端末（ノード）を有すると概ね図示されている。その少なくとも２つの端末は、複数のルータ（ホスト）１２、およびＩＰネットワーク１０上のルータ（ホスト）１２を介して互いに通信する。ルータ（ホスト）１２の集合、各エンドの端末（ノード）、およびそれらを接続するリンクにより、経路が構成される。送信時、データグラムは、宛先端末に到達するためにいくつかのホップを通過する。これらのホップは、ルータ（ホスト）１２全体を指してもよい。このように本願において「ホップ」という単語は、ホストおよびルータの両方を含むと解釈される。送信するノード（端末）は、経路の発呼端末（要するに、発呼端末）ということができ、また受信するノード（端末）は、経路の宛先端末（要するに、宛先端末）というできる。図1の通り、発呼端末は、リモート端末１４でも固定端末１６でもよい。同様に、宛先端末もリモート端末１８でも固定端末２０でもよい。
【００２２】
固定端末１６および２０は、固定リンクを介してルータ１２の各々に直接接続されている。リモート端末１４および１８は、無線ホップ２２を介してアクセスポイント２４に接続されている。アクセスポイント２４は、通常、通信塔２６およびルータ１２を有する。リモート端末１４および１８は無線電話として描かれている。しかし、無線ＩＰネットワーク１０で使用されるリモート端末としては、無線電話に限られず、個人情報端末（ＰＤＡ）、携帯型コンピュータ等であってもよいことは当業者にとって自明である。したがって、図１における無線電話の描写は例示であり本発明を限定するものではない。さらに図１に示されるように、ルータ１２の各々は少なくとも１つの他のルータに接続されており、これにより端末間でＩＰネットワーク１０を介したパケット送信が可能になっている。
【００２３】
リモート端末である無線電話機は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）や各種メモリを有する制御部、アクセスポイント２４と無線通信を行う無線通信部、ユーザが各種指示を入力するための操作入力部、各種情報を表示するための液晶表示部、音声通話を行うためのマイク及びスピーカ（いずれも図示略）などを備えている。また、固定端末は例えばコンピュータ装置であり、ＣＰＵや各種メモリを有する制御部、ハードディスク等の記憶装置、ネットワークと通信を行うための通信部、ユーザインターフェース（いずれも図示略）によって構成される。
【００２４】
図２には、ルータ１２における典型的なＩＰパケット処理の様子が図示されている。ＩＰパケットは、複数の入力ラインカード（ＩｎｇｒｅｓｓＬｉｎｅＣａｒｄ）３０に到着し、ＩＰ処理段階３２に入る。次にパケットは、典型的にはルータ１２の特定の実行状況に依存して入力キュー３４あるいは出力キュー３６に置かれる。スイッチファブリック３８は、パケットを適切な出力ラインカード（ＥｇｒｅｓｓＬｉｎｅＣａｒｄ）４０に誘導する。キューイングは、スイッチファブリック３８への入力および出力のどちらでも起こる可能性がある（もっとも最近のルータは入力キューイングを実行している）。しかし、キューイングは通常ＩＰ処理３２の後に起こる。後で詳細に説明するとおり、ＩＣＭＰタイムスタンプのオプションを使用する場合、ＩＣＭＰタイムスタンプ要求により引き出されたタイムスタンプは、入力キュー３４／出力キュー３６にエントリーする前の時刻を記録する。パケットは通常通信線の速度で取り扱われ、ＩＰ処理ステージ３２に対する待ち時間および実際の処理時間は、スイッチファブリック３８におけるキューイングおよび出口線カード４０における送信時間と比較して無視することができるので、ＩＰ処理の時間は短くてすむ。ＩＰ処理３２後のパケットのキューイングは、他のパケットが送信されるまでの待ち時間によるものである。キューイング遅延は、測定対象となるパケットの到達時におけるキューのサイズおよびリンクの転送速度と直接的に関連している。パケットは、キューが空くのを待って、送信される。
【００２５】
以降の議論においては、以下の項目を表すために次のような記号が使用される。ｔ_nすなわちｎは、イベントが記録される時刻を表す。Ｑ_i（ｎ）は、時刻ｎ、リンクｉにおけるキューのサイズ（ビット）を表す。Ｂ_iは、リンクｉの情報路容量（ビット／秒）を表す。Ｒ_i（ｎ）は、時刻ｎにキューに入ってくるフローの速度の総和（ビット／秒）を表す。ｑ_i（ｎ）は、時刻ｎにおいて、ルータｉにおけるキューイング遅延を表す。ｍは、パケットのサイズ（ビット）を表す。
【００２６】
時刻ｎにキューに入ったパケットに対して、既にキューに入っているデータのサイズはＱ_i（ｎ）である。そのパケットのキューイング遅延ｑ_i（ｎ）は、速度Ｂ_i（すなわち、パケットのキューイング遅延）において、リンクｉ中のキューを空けるのに必要な時間であり、以下のように表せる。
【数１】

【００２７】
速度Ｂ_iは、情報路容量、つまりリンクがデータを送信する速度を指す。つまり、リンクの転送速度のことである。したがってこの値は、ルータとネットワークの接続配置に固有の値である。
【００２８】
図３は、入ってくるフロー速度の変化に対する空いているキューのサイズ（つまり、キューイング時間）の変化を示す。Ｒ_iが速度Ｂ_iより小さい限り、キューサイズは増えない（Ｒ_iが速度Ｂ_iと等しい場合、リンクは出力ラインカード上でビットを直列化することができる）。しかし、インターネットトラフィックは爆発的に増加する性質のものであるため、Ｒ_iが情報路容量Ｂ_iを超え、キューイングが起こる可能性がある。本発明の目的に対して、時刻ｎにおけるリンクｉの利用率は以下のように定義される。
【数２】

【００２９】
図３を参照すると、次の式が得られる。
【数３】

あるいは、
【数４】

ここで、簡略化のため、時刻ゼロにおけるネットワーク初期化の際には、全てのリンクにおけるキューは空いている、すなわち、全てのｉに対しＱ_i（０）＝０であると仮定している。
【００３０】
後で変化させるため、ｔ_r-1、ｔ_r間の時間間隔は、一定に設定されない。数１および数３から、次式が得られる。
【数５】

また、数１および数４から
【数６】

数２を数６に代入すると、
【数７】

したがって利用率は次式のように表される。
【数８】

【００３１】
通過時間Ｔ_i（ｎ）は、時刻ｎにおいて、ある連続したｍビットのデータがリンクを通過するのに必要な時間である。すなわち、通過時間は次式で表される。
【数９】

【００３２】
ｍ／Ｂはまた、リンクの転送時間も指している。ここで定義される通過時間は、転送遅延およびキューイング遅延の総和であるが、伝播遅延および処理遅延は無視している。数７および数９から、次式が得られる。
【数１０】

したがって、Ｂ_iは次式のように表される。
【数１１】

【００３３】
次に、数２を数１１に代入すると、Ｒ_iは次式のように表される。
【数１２】

【００３４】
新たなフローに対する利用可能な帯域幅は、あるリンクがサポートできる速度である。つまり、キューのサイズ（すなわち、キューイング遅延）が増えないような速度である。つまり、利用可能な帯域幅は、リンクの情報路容量Ｂのうち、速度の総和がＲである競合するフローに使用されない部分であり、次式のように表される。
【数１３】

【００３５】
数２を数１３に代入すると、次式が得られる。
【数１４】

ここで、ＡｖＢｗ_i（ｎ）は、時刻ｎ、リンクｉにおける利用可能な帯域幅である。
【００３６】
利用可能な帯域幅の測定値は、その経路が輻輳が始まることにより、遅延およびジッタの発生なしで付加できる入力フローのマージンを評価するのに使用することができる。例えば、音声符号機に対する帯域幅要求は、利用可能帯域幅の観点からのものである。
【００３７】
スループットは、通常、リンクあるいは経路を介して一定量のビットのデータを得るのに必要な時間を測ることにより測定される。したがって、受信先において測定されるリンクｉのスループットは、次式のように表される。
【数１５】

ここで、ＴｈｒＢｗ_i（ｎ，ｋ）は、時刻ｎ，ｋにおけるリンクｉのスループット（ビット／秒）である。データパケットのサイズはビット単位で測定され、それは「データチャンク（ｄａｔａｃｈｕｎｋ）」と呼ばれる。データチャンクは、種々のサイズのパケットで構成されることが可能である。Ｂ_iはリンク情報路容量、ｑ_iはリンクのｋビットチャンクのキューイング遅延である。
【００３８】
複数のリンクにより構成される経路全体に対して、数１５を使用すると、スループットは次式のように表される。
【数１６】

【００３９】
数１６の右辺の分母は、実際にリンクおよび経路それぞれを通過するのに必要な遅延に対応している。したがって、スループットは、ネットワークにおける遅延状態を示す良い指標である。このように、スループットは、それ自体ではここで定義されるリンクあるいは経路の情報路容量、あるいは利用可能な帯域幅を表すものではない。
【００４０】
しかしながら、次のような方法でリンクあるいは経路の情報路容量、あるいは利用可能な帯域幅の測定に関連する。
【００４１】
数２および数５を連続した領域に拡張すると、次式が得られる。
【数１７】

次に、数１４を用いると、次式が得られる。
【数１８】

最後に、この結果を数１５に代入すると、スループットは次式のように表される。
【数１９】

【００４２】
図４は、好適な実施形態における方法の全体的な動作を示す図である。この方法の本質は、連続するホップにおけるキューイング遅延の変化を推定することである。したがって、前述の数２、数１１〜数１３は、情報路容量Ｂ、利用可能帯域幅ＡｖＢｗ、入ってくる競合フローＲの総和、および利用率ｕの推定に使用される。
【００４３】
図４に示されるように、好適な方法は、その経路の発呼端末１４および１６からその経路の宛先端末１８および２０までに存在するルータ（ホップ）１２全部のネットワークアドレスを特定することから始まる（ステップ４０）。本方法の好適な実施形態において、これは、Ｔｒａｃｅｒｏｕｔｅアプリケーションを使用して実現される。次のステップは、経路上の各ホップにおけるキューイング遅延の第１の推定値を得ることである（ステップ４２）。ステップ４０とステップ４２を合わせて、好適な方法の初期化（ブートストラップ）段階４４と呼ぶ。それから、複数組のＩＣＭＰタイムスタンプ要求は、各ルータ１２に通常の間隔で送信される。これにより、前述の数式群４８を用いてルータ１２におけるキューイング遅延変化４６の測定が可能になる。また、ＩＣＭＰタイムスタンプ要求の各々により、図４で５０と示される、ルータ１２の各々に対するＱｏＳパラメータ（情報路容量、利用可能な帯域幅、スループット）について１つの推定値の生成が可能になる。さらに、リンクの利用率および競合トラフィックのサイズが推定される。図４で示されているステップ４６、４８、５０を合わせて、測定段階と呼ぶ。
【００４４】
測定は、エンド・ツー・エンドの経路上の全てのホップを特定するために、Ｔｒａｃｅｒｏｕｔｅアプリケーションを発呼端末１４あるいは１６に呼び出すことにより開始される。いったんホップのリストが得られると、本発明において、各ホップにおける遅延の変化量を得るために複数組のＩＣＭＰタイムスタンプ要求を使用する。以下は、あるホップに対しこれを実現する方法の説明である。その手順は、経路上の全てのホップに対し共通である。
【００４５】
図５は、連続したルータ１２における１組のＩＣＭＰタイムスタンプ要求６０および６２の処理の好適な実施形態を示す。第１のルータに到着後、第１のパケット６０は、ＩＰ処理部６６からタイムスタンプを受け取る。次に、好適な実施形態において、第１のパケット６０は、第１のルータ６４の返信キュー６８を介してその発信元に戻る。第２のパケット６２は、送信キュー７０、リンク７２を通って、第２のルータ７４のＩＰ処理部６６に到達しタイムスタンプを受け取る。次に、好適な実施形態において、第２のパケット６２は、第２のルータ７４の返信キュー６８を介してその発信元に戻る。
【００４６】
図５に示される第１のルータ６４から第２のルータ７４までのリンクにおけるキューイング遅延の変化を得るために、２つのＩＣＭＰタイムスタンプ要求が、第１のパケットの最終ビットの送信と第２のパケットの最初のビットの送信の時間差が生じないように次々に送信される。第１のパケットのＩＣＭＰ要求は、第１のルータ６４に指示され、第２のパケットのＩＣＭＰ要求は、第２のルータ７４に送信される。同一のペアに属するパケットは、識別子あるいはＩＣＭＰパケットのシークエンス番号フィールドを用いて特定される。
【００４７】
そのパケットペアの第１のパケットの、第１のルータ６４におけるタイムスタンプは、Θ_i ¹で表され、そのペアの第２のパケットの、第２のルータ７４におけるタイムスタンプは、Θ_i+1 ²で表される。異なる時間軸上での測定を一般性を損なうことなく特定するため、ＩＣＭＰタイムスタンプ要求により報告される、同一のパケットペアのタイムスタンプは、第２のパケットがタイムスタンプを受け取ったときに記録されると仮定する。これは、記号Θ_i ¹（ｊ）とΘ_i+1 ²（ｊ）に等しく、両方のタイムスタンプは、同時刻ｊに集積されることを意味する。次の関係は、これらのタイムスタンプの差を表す。
【数２０】

ここで、ｍはＩＣＭＰタイムスタンプ要求パケットのサイズ（すなわち、ＩＣＭＰに対しては４０バイト、ＩＰに対しては２０バイト）である。ｑ_i（ｊ）は、第１のルータ６４から第２のルータ７４まで送信されるのを待っているパケットペアｊのキューイング遅延である。そして、ｄ_i _→ _i+1（ｊ）は、２つのルータ間の伝播遅延である。
【００４８】
重要なことは、第１のパケットのタイムスタンプは、パケットが第１のルータ６４のＩＰ処理段階を出発した時刻を示すだけでなく、第２のパケットが同一の段階を出発した時刻も示すと仮定している点である。この仮定が成り立つためには、２つのＩＣＭＰパケットが、他のパケットの後で到達することが必要である。すなわち、これら２つのパケットがキューのため第１のルータ６４に到達するまで、２つのパケット間に干渉トラフィックは存在しないということである。これは、ほとんどの場合実情にあっていると考えられる。
【００４９】
伝播遅延、処理遅延を無視すると、次式が得られる。
【数２１】

数２１は、前述の数９と同一である。すなわち、数２１は、リンク７２経由で第１のルータ６４から第２のルータ７４までの移動時間を定義する。リンクにおける送信時間およびキューイング時間は考慮しているが、伝播遅延および処理遅延は無視している。
【００５０】
第１のパケットペアの送信後、送信機は次のパケットペアを送信する前に、ユーザが定義した遅延αだけ待機する。今度は、集積される測定は、Θ_i ¹（ｊ＋１）とΘ_i+1 ²（ｊ＋１）である。したがって、キューイング遅延変化は次式のように推定される。
【数２２】

ここで数８を用いて、
【数２３】

ここでｕ_i（ｊ＋１）は、第１のルータ６４と第２のルータ７４の間のリンクｉ７２における利用率であり、時刻ｔ_jにおいて、２つの測定の組ｊおよびｊ＋１間で測定されたものである。さらに、
【数２４】

であり、ここで、情報路容量Ｂ_ｉは、数２１を用いて次式のように定義できる。
【数２５】

【００５１】
数２５で未知の変数は、時刻ｔ_jにおける第１のルータ６４におけるキューイング遅延である。キューイング遅延は次式のように表せる。
【数２６】

ここで、Δｑ_i（ｊ−１，ｊ）は、パケットｊ−１とパケットｊのペアにより測定される、第１のルータ６４におけるキューイング遅延の変化である。したがって、キューイング遅延は次式のように表せる。
【数２７】

【００５２】
数２７において、ｑ_i（０）は、測定開始時に第１のパケットペアが体験するキューイング遅延の推定値である。第１のルータ６４における第１のキューイング遅延の推定値ｑ_ｉ（０）は、まず、３つの連続したＩＣＭＰタイムスタンプ要求を（最初の１つを第１のルータ６４へ、残りの２つを第２のルータ７４へ）送信することにより、最初の測定過程において得られる。これにより次の式が導かれる。
【数２８】

【００５３】
したがって、第１のルータ６４から第２のルータ７４間のリンクの時刻０における情報路容量Ｂ_iの推定値が次式のように得られる。
【数２９】

【００５４】
情報路容量Ｂ_iの推定値は、後述するように測定が進むにつれ後に更新される。しかし、時刻０（ゼロ）における数２１は、次式のようにも書ける。
【数３０】

ここで、数２９と合わせて、キューイング遅延は次式のように表される。
【数３１】

【００５５】
リンクｉにおけるキューイング遅延の初期の推定値は、数２７の測定過程を通じて使用することができる。また、数２７を使用して得られる推定値より良い推定値を得るために３つの連続したＩＣＭＰパケットを送信するという手順を通じて、キューイング遅延の推定を測定イベントごとに繰り返すことができる。
【００５６】
ｑ_i（ｊ）の推定値が得られると、それはリンクの情報路容量Ｂ_ｉを推定するために数２５で使用される。したがって、Ｂ_iは、数２５、数２７、数３１を用いて推定することができる。ここで入ってくる競合フローＲ_ｉの総和は、数２、数２３、数２５、数２７、および数３１を用いて推定することができる。これはまず、情報路容量Ｂ_iの推定により実行される。次に数２３を使用して利用率を推定する。そして数２を使用してＲ_iを得る。さらに、利用可能な帯域幅ＡｖＢｗ_iは、数２、数１３、数２３、数２５、数２７、および数３１を用いて、同一の過程により推定することができる。
【００５７】
本発明の好適な実施形態において、ルータ１２の全ては、規則的に、そして同一の頻度で測定される。さらに別の実施形態では、特定のルータ１２は、そのルータ自身のキューイング遅延の変化率に基づいて、測定頻度を変更してもよい。本発明の実施形態において、経路のホップのアドレスは、まずＩＣＭＰペアの送信が始まった後に特定される。さらに別の実施形態において、各ホップに対するＩＣＭＰペアの送信は、そのホップが特定されるとすぐに始まる。
【００５８】
本発明の好適な実施形態において、ＩＣＭＰタイムスタンプ要求は、ＩＣＭＰプロトコルで定められた標準サイズである。さらに別の実施形態においては、ＩＰペイロードフィールドにダミーデータが付加されてもよい。これにより、ルータにおける転送時間が増加するが、非常に高速なリンクに対しては有用な機能である。本発明の好適な実施形態において、経路の特定とタイムスタンプ要求は、発呼端末あるいは宛先端末のどちらからも送信される。さらに別の実施形態では、種々のタイムスタンプ要求および経路の特定は、発呼端末、受信先、あるいはネットワークの他のホストから同時に送信されてもよい。さらに、測定の処理は、ネットワーク上のホストの任意の１つ、一部、あるいは発呼端末および通信先ホストを含む全てのホストにおいて実行されてもよい。
【００５９】
この方法は、タイムスタンプ要求パケットのペアが経路上の最も遅いリンク（ボトルネックリンク）を介した送信を回避するように改良できる。これは、タイムスタンプ要求パケットのペアがそのリンクに到達したときのタイムスタンプ間の分散を回避するということである。これを実現するために、測定は、ボトルネックリンクを回避するために、発呼端末あるいは宛先ノードのどちらからも行われる。本発明の好適な実施形態において、種々のリンクの変化率の測定により、ボトルネックが特定される。この方法はまた、リンクの伝播遅延を考慮して測定の精度をさらに向上させることにより更に改良される。これは、伝播遅延の推定により実現される。
【００６０】
本発明は、現在最も好適と考えられる動作および実施の態様で説明されているが、本発明に関する他の態様、実施形態、および利点は、当業者には明らかであり、ここに含まれる。
【００６１】
【発明の効果】
以上で説明したように、本発明によれば、ＩＰネットワークにおける通信経路に対するＱｏＳ推定値を得ることができる。
【図面の簡単な説明】
【図１】ＩＰネットワークの例を示す図である。
【図２】ルータのパケット処理の詳細を示す図である。
【図３】入力速度に対するキューイングサイズの変化の例を示す図である。
【図４】好適な方法のフローチャートである。
【図５】１組のホップにおけるＩＣＭＰタイムスタンプ要求の処理の一例を示す図である。
【符号の説明】
１０……ＩＰネットワーク、１２……ルータ、１４、１８……リモート端末、１６、２０……固定端末、２４……アクセスポイント、３０……入力ラインカード、３４……入力キュー、３６……出力キュー、３８……スイッチファブリック、４０……出力ラインカード

Claims

各々特定のアドレスを有する発呼端末、宛先端末、および前記発呼端末と前記宛先端末を結ぶエンド・ツー・エンド経路上に存在する少なくとも１つのホップを含むネットワークにおける前記エンド・ツー・エンド経路の品質を示すＱｏＳ推定値を取得する方法であって、
前記発呼端末が、前記エンド・ツー・エンド経路上に存在するすべてのホップのアドレスを特定するアドレス特定ステップと、
前記発呼端末が、第１のタイムスタンプ要求パケットおよび第２のタイムスタンプ要求パケットを含む第１の組のタイムスタンプ要求パケットを生成する第１の要求生成ステップと、
前記発呼端末が、第３のタイムスタンプ要求パケットおよび第４のタイムスタンプ要求パケットを含む第２の組のタイムスタンプ要求パケットを生成する第２の要求生成ステップと、
前記発呼端末が、前記第１のタイムスタンプ要求パケットを、前記アドレス特定ステップにおいて特定されたアドレスを用いて、前記エンド・ツー・エンド経路上に存在する第１のホップに送信する第１の要求送信ステップと、
前記発呼端末が、前記第２のタイムスタンプ要求パケットを、前記アドレス特定ステップにおいて特定されたアドレスを用いて、前記エンド・ツー・エンド経路上に存在する第２のホップに送信する第２の要求送信ステップと、
前記発呼端末が、前記第３のタイムスタンプ要求パケットを、前記第１のホップに送信する第３の要求送信ステップと、
前記発呼端末が、前記第４のタイムスタンプ要求パケットを、前記第２のホップに送信する第４の要求送信ステップと、
前記第１のホップが、前記第１のタイムスタンプ要求パケットに応じて、第１のタイムスタンプを生成する第１のタイムスタンプ生成ステップと、
前記第２のホップが、前記第２のタイムスタンプ要求パケットに応じて、第２のタイムスタンプを生成する第２のタイムスタンプ生成ステップと、
前記第１のホップが、前記第３のタイムスタンプ要求パケットに応じて、第３のタイムスタンプを生成する第３のタイムスタンプ生成ステップと、
前記第２のホップが、前記第４のタイムスタンプ要求パケットに応じて、第４のタイムスタンプを生成する第４のタイムスタンプ生成ステップと、
前記発呼端末が、前記第１のタイムスタンプを含むパケットを受信する第１のタイムスタンプ受信ステップと、
前記発呼端末が、前記第２のタイムスタンプを含むパケットを受信する第２のタイムスタンプ受信ステップと、
前記発呼端末が、前記第３のタイムスタンプを含むパケットを受信する第３のタイムスタンプ受信ステップと、
前記発呼端末が、前記第４のタイムスタンプを含むパケットを受信する第４のタイムスタンプ受信ステップと、
前記発呼端末が、前記第１のタイムスタンプ、前記第２のタイムスタンプ、前記第３のタイムスタンプおよび前記第４のタイムスタンプにより示される時刻を変数として含む数式を用いて、前記第１のホップにおけるキューイング遅延変化の推定値を算出する算出ステップと、
前記発呼端末が、前記キューイング遅延変化の推定値を変数として含む数式を含む数式群を用いて、前記第１のホップにおけるキューイング遅延の推定値、前記第１のホップと前記第２のホップとの間の経路の情報路容量の推定値、前記第１のホップと前記第２のホップとの間の経路の利用率の推定値、前記第１のホップと前記第２のホップとの間の経路の利用可能な帯域幅の推定値および前記第１のホップのキューにデータが入ってくる速度の推定値のうち少なくとも１つの値をＱｏＳ推定値としてを算出するＱｏＳ推定ステップと
を有するＱｏＳ推定方法。
各々特定のアドレスを有する発呼端末、宛先端末、および前記発呼端末と前記宛先端末を結ぶエンド・ツー・エンド経路上に存在する少なくとも１つのホップを含むネットワークにおける前記エンド・ツー・エンド経路の品質を示すＱｏＳ推定値を取得する方法であって、
前記宛先端末が、前記エンド・ツー・エンド経路上に存在するすべてのホップのアドレスを特定するアドレス特定ステップと、
前記宛先端末が、第１のタイムスタンプ要求パケットおよび第２のタイムスタンプ要求パケットを含む第１の組のタイムスタンプ要求パケットを生成する第１の要求生成ステップと、
前記宛先端末が、第３のタイムスタンプ要求パケットおよび第４のタイムスタンプ要求パケットを含む第２の組のタイムスタンプ要求パケットを生成する第２の要求生成ステップと、
前記宛先端末が、前記第１のタイムスタンプ要求パケットを、前記エンド・ツー・エンド経路上に存在する第１のホップに送信する第１の要求送信ステップと、
前記宛先端末が、前記第２のタイムスタンプ要求パケットを、前記アドレス特定ステップにおいて特定されたアドレスを用いて、前記エンド・ツー・エンド経路上に存在する第２のホップに送信する第２の要求送信ステップと、
前記宛先端末が、前記第３のタイムスタンプ要求パケットを、前記第１のホップに送信する第３の要求送信ステップと、
前記宛先端末が、前記第４のタイムスタンプ要求パケットを、前記第２のホップに送信する第４の要求送信ステップと、
前記第１のホップが、前記第１のタイムスタンプ要求パケットに応じて、第１のタイムスタンプを生成する第１のタイムスタンプ生成ステップと、
前記第２のホップが、前記第２のタイムスタンプ要求パケットに応じて、第２のタイムスタンプを生成する第２のタイムスタンプ生成ステップと、
前記第１のホップが、前記第３のタイムスタンプ要求パケットに応じて、第３のタイムスタンプを生成する第３のタイムスタンプ生成ステップと、
前記第２のホップが、前記第４のタイムスタンプ要求パケットに応じて、第４のタイムスタンプを生成する第４のタイムスタンプ生成ステップと、
前記宛先端末が、前記第１のタイムスタンプを含むパケットを受信する第１のタイムスタンプ受信ステップと、
前記宛先端末が、前記第２のタイムスタンプを含むパケットを受信する第２のタイムスタンプ受信ステップと、
前記宛先端末が、前記第３のタイムスタンプを含むパケットを受信する第３のタイムスタンプ受信ステップと、
前記宛先端末が、前記第４のタイムスタンプを含むパケットを受信する第４のタイムスタンプ受信ステップと、
前記宛先端末が、前記第１のタイムスタンプ、前記第２のタイムスタンプ、前記第３のタイムスタンプおよび前記第４のタイムスタンプにより示される時刻を変数として含む数式を用いて、前記第１のホップにおけるキューイング遅延変化の推定値を算出する算出ステップと、
前記宛先端末が、前記キューイング遅延変化の推定値を変数として含む数式を含む数式群を用いて、前記第１のホップにおけるキューイング遅延の推定値、前記第１のホップと前記第２のホップとの間の経路の情報路容量の推定値、前記第１のホップと前記第２のホップとの間の経路の利用率の推定値、前記第１のホップと前記第２のホップとの間の経路の利用可能な帯域幅の推定値および前記第１のホップのキューにデータが入ってくる速度の推定値のうち少なくとも１つの値をＱｏＳ推定値としてを算出するＱｏＳ推定ステップと
を有するＱｏＳ推定方法。
前記第１の要求生成ステップおよび前記第２の要求生成ステップにおいて生成されるタイムスタンプ要求パケットの数が、少なくとも５つであることを特徴とする請求項１または２のいずれかに記載のＱｏＳ推定方法。
前記エンド・ツー・エンド経路上の特定のホップに対してタイムスタンプ要求パケットを生成する頻度を、他のホップに対してタイムスタンプ要求パケットを生成する頻度よりも増加または減少させる頻度変化ステップをさらに備えることを特徴とする請求項１または２のいずれかに記載のＱｏＳ推定方法。
前記特定のホップは、利用率、キューイング遅延、キューのサイズ、処理遅延、利用可能な帯域幅、輻輳状態の変化パターンのうち少なくとも１つに基づいて決定されることを特徴とする請求項４に記載のＱｏＳ推定方法。
連続するタイムスタンプ要求パケットの送信の間にあらかじめ決められた待ち時間を導入する待ち時間ステップをさらに備えることを特徴とする請求項１または２のいずれかに記載のＱｏＳ推定方法。
あらかじめ決められたダミーデータを前記タイムスタンプ要求パケットに付加することにより、当該タイムスタンプ要求パケットのサイズを増加させるサイズ増加ステップをさらに備えることを特徴とする請求項１または２のいずれかに記載のＱｏＳ推定方法。
通信相手と当該通信端末との間でエンド・ツー・エンド経路を介した通信が行われる場合に、前記エンド・ツー・エンド経路上にある全てのホップのアドレスを特定する特定手段と、
第１のタイムスタンプ要求パケットおよび第２のタイムスタンプ要求パケットを含む第１の組のタイムスタンプ要求パケットを生成する第１の生成手段と、
第３のタイムスタンプ要求パケットおよび第４のタイムスタンプ要求パケットを含む第２の組のタイムスタンプ要求パケットを生成する第２の生成手段と、
前記第１のタイムスタンプ要求パケットを、前記特定手段によりそのアドレスが特定された第１のホップに送信する送信手段と、
前記第２のタイムスタンプ要求パケットを、前記特定手段によりそのアドレスが特定された第２のホップに送信する送信手段と、
前記第１のタイムスタンプ要求パケットに応じて生成された第１のタイムスタンプを含んだパケットを前記エンド・ツー・エンド経路を介して受信する第１の受信手段と、
前記第２のタイムスタンプ要求パケットに応じて生成された第２のタイムスタンプを含んだパケットを前記エンド・ツー・エンド経路を介して受信する第２の受信手段と、
前記第３のタイムスタンプ要求パケットに応じて生成された第３のタイムスタンプを含むパケットを前記エンド・ツー・エンド経路を介して受信する第３の受信手段と、
前記第４のタイムスタンプ要求パケットに応じて生成された第４のタイムスタンプを含むパケットを前記エンド・ツー・エンド経路を介して受信する第４の受信手段と、
前記第１のタイムスタンプ、前記第２のタイムスタンプ、前記第３のタイムスタンプおよび前記第４のタイムスタンプにより示される時刻を変数として含む数式を用いて、前記第１のホップにおけるキューイング遅延変化の推定値を算出する第１の算出手段と、
前記キューイング遅延変化の推定値を変数として含む数式を含む数式群を用いて、前記第１のホップにおけるキューイング遅延の推定値、前記第１のホップと前記第２のホップとの間の経路の情報路容量の推定値、前記第１のホップと前記第２のホップとの間の経路の利用率の推定値、前記第１のホップと前記第２のホップとの間の経路の利用可能な帯域幅の推定値および前記第１のホップのキューにデータが入ってくる速度の推定値のうち少なくとも１つの値をＱｏＳ推定値としてを算出する第２の算出手段と、
を備える通信装置。
通信相手との間でエンド・ツー・エンド経路を介した通信が行われる場合に、前記エンド・ツー・エンド経路上にある全てのホップのアドレスを特定する特定ステップと、
第１のタイムスタンプ要求パケットおよび第２のタイムスタンプ要求パケットを含む第１の組のタイムスタンプ要求パケットを生成する第１の要求生成ステップと、
第３のタイムスタンプ要求パケットおよび第４のタイムスタンプ要求パケットを含む第２の組のタイムスタンプ要求パケットを生成する第２の要求生成ステップと、
前記第１のタイムスタンプ要求パケットを、前記特定ステップによりそのアドレスが特定された第１のホップに送信する第１の送信ステップと、
前記第２のタイムスタンプ要求パケットを前記エンド・ツー・エンド経路上の第２のホップに送信する第２の送信ステップと、
前記第３のタイムスタンプ要求パケットを、前記第１のホップに送信する第３の送信ステップと、
前記第４のタイムスタンプ要求パケットを、前記第２のホップに送信する第４の送信ステップと、
前記第１のタイムスタンプ要求パケットに応じて生成された第１のタイムスタンプを含んだパケットを前記経路を介して受信する第１の受信ステップと、
前記第２のタイムスタンプ要求パケットに応じて生成された第２のタイムスタンプを含んだパケットを前記経路を介して受信する第２の受信ステップと、
前記第３のタイムスタンプ要求パケットに応じて生成された第３のタイムスタンプを含むパケットを前記経路を介して受信する第３の受信ステップと、
前記第４のタイムスタンプ要求パケットに応じて生成された前記第４のタイムスタンプを含むパケットを前記経路を介して受信する第４の受信ステップと、
前記第１のタイムスタンプ、前記第２のタイムスタンプ、前記第３のタイムスタンプおよび前記第４のタイムスタンプにより示される時刻を変数として含む数式を用いて、前記第１のホップにおけるキューイング遅延変化の推定値を算出する算出ステップと、
前記キューイング遅延変化の推定値を変数として含む数式を含む数式群を用いて、前記第１のホップにおけるキューイング遅延の推定値、前記第１のホップと前記第２のホップとの間の経路の情報路容量の推定値、前記第１のホップと前記第２のホップとの間の経路の利用率の推定値、前記第１のホップと前記第２のホップとの間の経路の利用可能な帯域幅の推定値および前記第１のホップのキューにデータが入ってくる速度の推定値のうち少なくとも１つの値をＱｏＳ推定値としてを算出するＱｏＳ推定ステップと
をコンピュータに実行させるプログラム。