(57)【要約】      （修正有）【課題】ネットワークの品質を計測する装置において、通信端末が実際に受信したデータ量「グッドプット」と、通信相手先まで届かなかったデータ量「パケットロス」と、計測装置と通信端末間でのパケットロスデータ量「パケットロスの発生箇所」とを、精度良く計測し、計測装置がデータを受信部で取り損ねても、ネットワークの品質を推定する。【解決手段】計測装置のネットワークの品質計測を行う処理において、データ受信部においてデータを受信し、フィルタリング部においてデータ受信部で受信したデータのフロー識別を行い、状態監視部において管理している同一フロー毎のACK番号情報とSN番号情報を元に、品質判定部でグッドプットや、パケットロスの有無、パケットロスの発生箇所を判断することを特徴とする計測装置。 【選択図】図１
2006067217.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークの品質を計測する方法であって、
前記ネットワークに属する端末間で送受信されているデータを受信するステップと、
前記端末がデータの再送を要求する再送要求状態であるかを判定する判定ステップと、
前記受信したデータに含まれるデータの送信順番を示す送信順情報と、前記端末が受信したデータの情報を示す受信確認情報と、前記判定結果との中、少なくとも１つの情報に基づいて前記ネットワークの品質を判断する判断ステップと
を有することを特徴とするネットワーク品質計測方法。
【請求項２】
前記判断ステップは、
前記受信したデータの送信順情報と、前回までに受信したデータの送信順情報とを比較するステップと、
前記比較の結果、前回までに受信したデータの送信順情報の方が大きい場合であり、前記判定結果が再送要求状態でない場合、若しくは前記判断結果が再送要求状態であるとは判定できない場合には、データ損失はなかったと判断するステップと
を有することを特徴とする請求項１に記載のネットワーク品質計測方法。
【請求項３】
前記判断ステップは、
前記受信したデータの送信順情報と、前回までに受信したデータの送信順情報とを比較するステップと、
前記比較の結果、前回までに受信したデータの送信順情報の方が大きい場合であり、前記判定結果が再送要求状態である場合、若しくは前記判断結果が再送要求状態であると判定できる場合には、データ損失があったと判断するステップと
を有することを特徴とする請求項１に記載のネットワーク品質計測方法。
【請求項４】
前記判定ステップは、
前記受信ステップにおいて、一定回数以上同一の受信確認情報のデータを受信している場合、もしくは、前記受信ステップが該送信順情報に対応する受信確認情報が記載されているデータを一定時間以内に受信しない場合に、再送要求状態であると判定することを特徴とする請求項１から請求項３のいずれかに記載のネットワーク品質計測方法。
【請求項５】
前記判断ステップは、前記受信したデータの送信順情報の履歴を作成し、データの損失又はデータ損失場所を判断することを特徴とする請求項１から請求項４のいずれかに記載のネットワーク品質計測方法。
【請求項６】
前記判断ステップは、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、該送信順情報のデータを以前にも受信したことがある場合には計測装置から受信端末までの間のデータの損失であると判断し、前記受信手段が該送信順情報のデータを以前にも受信したことがない場合には送信端末から計測装置までの間のデータ損失であると判断することを特徴とする請求項５に記載のネットワーク品質計測方法。
【請求項７】
前記判断ステップは、前記受信データの送信順情報の履歴を前記受信ステップで該受信データを受信した時刻と共に記録し、端末側での通信量を判断することを特徴とする請求項１に記載のネットワーク品質計測方法。
【請求項８】
前記判断ステップは、前記記録した送信順情報の履歴とその受信時刻との記録を参照し，ある一定期間の記録の中で最大値のデータ送信順情報を持つデータのデータ量と最小値のデータ送出順情報を持つデータのデータ量との差分をその期間の通信量と判断することを特徴とする請求項７に記載のネットワーク品質計測方法。
【請求項９】
前記判断ステップは、前記受信データの受信確認情報の履歴を前記受信ステップで該受信データを受信した時刻と共に記録し、端末側での通信量を判断することを特徴とする請求項１に記載のネットワーク品質計測方法。
【請求項１０】
前記判断ステップは、前記記録した受信確認情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値の受信確認情報を持つデータのデータ量と最小値の受信確認情報を持つデータのデータ量との差分をその期間の通信量と判断することを特徴とする請求項９に記載のネットワーク品質計測方法。
【請求項１１】
前記判断ステップは、単位時間あたりのデータ送信量が増加している間はデータ損失がないと判断し、通信量が減少した場合にはデータ損失が生じたと判断することを特徴とする請求項１０に記載のネットワーク品質計測方法。
【請求項１２】
ネットワークの品質を計測する計測装置であって、
前記ネットワークに属する端末間で送受信されているデータを受信する受信手段と、
前記端末がデータの再送を要求する再送要求状態であるかを判定する判定手段と、
前記受信したデータに含まれる、データの送信順番を示す送信順情報と、端末が受信したデータの情報を示す受信確認情報の監視結果と、前記判定結果との中、少なくとも１つの情報に基づいて、前記ネットワークの品質を判断する判断手段と
を有することを特徴とする計測装置。
【請求項１３】
前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、且つ前記判定結果が再送要求状態ではない場合、もしくは前記判定結果が再送要求状態であるとは推定できない場合には、データ損失があったと判断しないように構成されていることを特徴とする請求項１２に記載の計測装置。
【請求項１４】
前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、且つ前記判定の結果が再送要求状態である場合、もしくは前記判定の結果が再送要求状態であると推定できる場合には、データ損失があったと判断するように構成されていることを特徴とする請求項１２に記載の計測装置。
【請求項１５】
前記判定手段は、前記受信手段が一定回数以上同一の受信確認情報のデータを受信している場合、もしくは、前記受信手段が該送信順情報に対応する受信確認情報が記載されているデータを一定時間以内に受信しない場合に、再送要求状態であると判定するように構成されていることを特徴とする請求項１２から請求項１４のいずれかに記載の計測装置。
【請求項１６】
前記判断手段は、前記受信手段が受信したデータの送信順情報の履歴を作成し、データの損失、又はデータ損失場所を判断するように構成されていることを特徴とする請求項１２から請求項１５のいずれかに記載の計測装置。
【請求項１７】
前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、前記受信手段が該送信順情報のデータを以前にも受信したことがある場合には計測装置から受信端末までの間のデータの損失であると判断し、前記受信手段が該送信順情報のデータを以前にも受信したことがない場合には送信端末から計測装置までの間のデータ損失であると判断するように構成されていることを特徴とする請求項１６に記載の計測装置。
【請求項１８】
前記判断手段は、前記受信データの送信順情報の履歴を前記受信手段が該受信データを受信した時刻と共に記録し、端末側での通信量を判断するように構成されていることを特徴とする請求項１２に記載の計測装置。
【請求項１９】
前記判断手段は、前記記録した送信順情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値のデータ送信順情報を持つデータのデータ量と最小値のデータ送出順情報を持つデータのデータ量との差分をその期間の通信量と判断するように構成されていることを特徴とする請求項１８に記載の計測装置。
【請求項２０】
前記判断手段は、前記受信データの受信確認情報の履歴を前記受信手段が該受信データを受信した時刻と共に記録し、端末側での通信量を判断するように構成されていることを特徴とする請求項１２に記載の計測装置。
【請求項２１】
前記判断手段は、前記記録した受信確認情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値の受信確認情報を持つデータのデータ量と最小値の受信確認情報を持つデータのデータ量との差分をその期間の通信量と判断するように構成されていることを特徴とする請求項２０に記載の計測装置。
【請求項２２】
前記判断手段は、単位時間あたりのデータ送信量が増加している間はデータ損失がないと判断し、通信量が減少した場合にはデータ損失が生じたと判断するように構成されていることを特徴とする請求項１６に記載の計測装置。
【請求項２３】
ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報及び受信確認情報の状態と、前記端末がデータの再送を要求しているかの再送要求状態とを監視することにより前記ネットワーク上でパケットロスがあったかを判定するように構成されていることを特徴とする計測装置。
【請求項２４】
ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報及び受信確認情報の履歴を監視することにより前記ネットワーク上でパケットロスが発生したか否か、もしくはパケットロスが発生した箇所を判定するように構成されていることを特徴とする計測装置。
【請求項２５】
ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報の時間変化及び受信確認情報の時間変化と、プロトコルの動きとを監視することにより前記ネットワークの品質を推定するように構成されていることを特徴とする計測装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの品質を測定する方法、及び計測装置に関する。
【背景技術】
【０００２】
本発明は、ネットワークの品質を測定する装置および方法に関するものである。ここでのネットワークの品質とは、ネットワークの品質を計測する計測装置に入力されるデータ、つまりネットワーク上の分岐装置を通過するデータの品質のことを指す。又、データの品質とは、スループット、グッドプット、パケットロス、応答時間、トランザクション継続時間、パケットロスの発生箇所等を指す。
【０００３】
以下では簡単化のために、TCP（Transmission Control Protocol）を用いて、ネットワークの品質を測定する装置について説明する。
【０００４】
TCP通信の品質を測定する技術として、従来、いくつかの技術が存在する（例えば、特許文献１、非特許文献１）。
【０００５】
ここで、特許文献１について説明する。
【０００６】
特許文献１の技術に記載されているスループット、グッドプット、パケットロスに相当する計測方法について、図１、図２を用いて説明する。
【０００７】
図１は特許文献１の適用領域を示す図であり、図２は特許文献１の動作を説明するためのフロー図である。
【０００８】
通信端末２と通信端末３とのデータ通信の品質を計測する場合、その通信リンク上に分岐装置４及び分岐装置５を設置して、計測したい通信のデータを計測装置１に取り入れる。計測装置１でデータを取り込まれることにより、品質の計測が開始される。
【０００９】
図２に示すように、特許文献１では、パケットを取得し、それを送受信IPアドレスやTCPポート番号が同一のフローによって分類する（ステップＡ１）。
【００１０】
同一フロー毎に計測装置１で取得したデータ量を計測する。過去にこの装置１を通過したデータ量と今回新たに取得したデータ量とを加算し、現在まで累計の通過データ量を計測する（ステップＡ２）。
【００１１】
取得したデータのTCPプロトコルヘッダ内に存在するシーケンスナンバー（以後SN）を確認し、この値をXと設定する（ステップＡ３）。
【００１２】
同一フローで過去に取得したSN内の最大の値（Yと設定）と、ステップＡ３で設定されたXの値とを比較する（ステップＡ４）。
【００１３】
ステップＡ４での比較の結果、Xの方がYよりも大きければ、現在取得したデータのSNが、過去のSNの中で最大であるため、今回のXをYと新たに設定しなおして処理を終了する（ステップＡ５）。
【００１４】
ステップＡ４での比較の結果、Xの方がYよりも小さければ、パケットロス回数を１加算して、現在取得したデータ量をパケットロス量にカウントする（ステップＡ６）。
【００１５】
ここで、通信が終了した時点でのステップＡ２で計測した蓄積パケットサイズが通信したデータ量となり、単位時間毎にこの値を計測することで“スループット”となる。また、ステップＡ６でカウントしたパケットロス回数、パケットロス量が、“パケットロス”に関する品質となる。さらにこの通常通信したデータ量からパケットロス量を引いた量が、通信相手先が受信したデータ量となり、単位時間毎にこの値を計測することでグッドプットを計測することが出来る。
【００１６】
この方法は、一般的にTCPのSNが単調に増加している間は、データロスなしで通信されており、データのロスを検知して再送処理が行われた場合のみ、SNが小さくなるという仕組みを利用している。
【００１７】
続いて、非特許文献１に記載されている技術について、図３から図８を用いて説明する。
【００１８】
非特許文献１は、TCPの３wayハンドシェイク（データ通信確立処理）における「パケットロス」の発生、及びこのときの「パケットロスの発生箇所」を特定する技術である。
【００１９】
TCPのデータ通信確立において、パケットロスが発生しなかった場合は、同一コネクションのデータは、図３のような処理フロー（CASE０）となり、SYN（Synchronous）、SYN＋ACK（Acknowledgement）、ACK、GET、RST（Reset）の順に計測する。しかしながら、仮にデータ確立処理時にパケットロスが発生した場合はこの順番や回数が異なり、CASE１[計測順：SYN、SYN、SYN＋ACK、ACK、GET、RST]（図４）、CASE２[計測順：SYN、SYN＋ACK、ACK、GET、RST]（図５）、CASE３[計測順：SYN、SYN＋ACK、SYN＋ACK、ACK、GET、RST]（図６）、CASE４[計測順：SYN、SYN＋ACK、SYN、SYN＋ACK、ACK、GET、RST]（図７）、又はCASE５[計測順：SYN、SYN＋ACK、GET、RST]（図８）の場合が考えられる。非特許文献１の技術では、計測したデータが図３から図８のどの処理フローに分類されるかということから、データ通信確立時のパケットロスの発生、およびこのときのパケットロスの発生箇所を特定する。
【００２０】
処理フローが、CASE０[計測順：SYN、SYN＋ACK、ACK、GET、RST]のように計測された場合は理想的なデータ確立処理順のままであるため、パケットロスが発生していないと判断する。
【００２１】
処理フローが、CASE１[計測順：SYN、SYN、SYN＋ACK、ACK、GET、RST]のように計測された場合、２種類のケースが考えられる。図４の左図のような場合と右図のような場合である。図４の左図の場合は、一番初めに通信端末２から計測装置１へ送信したSYNデータが、計測装置１−通信端末３間でパケットロスした場合である。また図４の右図は、通信端末３が、はじめのSYNデータに対する返答、SYN＋ACKデータを、通信端末２に対して送ったとき、そのデータが通信端末２−計測装置１間でパケットロスを起こした場合である。どちらの場合においても、このような順でデータが計測された場合は、計測装置１−通信端末３間のパケットロスと判定することができる。
【００２２】
処理フローが、CASE２[計測順：SYN、SYN＋ACK、ACK、GET、RST]のように計測された場合は、通信端末２からのはじめのSYNデータを通信端末３が受け取り、それに対して送信したSYN＋ACKデータが計測装置１−通信端末３間でパケットロスを起こした場合である。通信端末３のSYN＋ACKデータの再送により、通信が継続された場合はCASE２の状態になる。ただし、CASE２のように計測された場合、SYNとその次のSYN＋ACKとのデータの到着間隔がある程度（一例として３秒程度）の時間以上必要とした場合を対象とする。
【００２３】
処理フローが、CASE３[計測順：SYN、SYN＋ACK、SYN＋ACK、ACK、GET、RST]のように計測されたとき、通信端末２と計測装置１との間での発生したパケットロスである。この場合も、図６の左図の場合と右図の場合とに場合分けすることができる。図６の左図の場合は、通信端末２からのはじめのSYNデータを通信端末３が受け取り、それに対して送信したSYN＋ACKデータが計測装置１を通過後、通信端末２−計測装置１間でパケットロスを起こした場合である。また、図６の右図の場合は、通信端末３が送付したSYN＋ACKデータが通信端末２に届き、それに対して送信したACKデータが、計測装置１を通過する前、通信端末２−計測装置１間でパケットロスを起こした場合である。どちらの場合においても、このような順でデータが計測された場合には、通信端末２−計測装置１間のパケットロスと判定することができる。
【００２４】
処理フローが、CASE４[計測順：SYN、SYN＋ACK、SYN、SYN＋ACK、ACK、GET、RST]のように計測されたとき、通信端末２と計測装置１との間で発生したパケットロスである。この場合は、通信端末２が一番はじめに送信したSYNデータが通信端末３に届き、その計測データが計測装置１を経過後に通信端末２−計測装置１間でパケットロスを起こした場合である。通信端末２は通信端末３からの返答が一定期間経過後も受け取ることができていないため、再度SYNデータを送付している。
【００２５】
処理フローが、CASE５[計測順：SYN、SYN＋ACK、GET、RST]のように計測された場合は、本来HTTP（Hyper Text
Transfer Protocol）通信では3wayハンドシェイク後にGETデータを送信するため、通信端末２−計測装置１間のパケットロスとなっている可能性がある。なおTCPのデータ通信確立の処理に関しては、RFC（Request
for Comments）や文献「詳解TCP/IP Vol.1プロトコル」第１８章 TCPコネクションの確立と終了に詳しく記載されている。 
【特許文献１】特開２００１‐９４５７３号
【非特許文献１】信学技法 TECHNICAL REPORT OF IEICE。 NS2003-162 CQ2003-79 TM2003-40 (2003-11)
【発明の開示】
【発明が解決しようとする課題】
【００２６】
上述した特許文献１の技術では、パケットロスを起こさなかったデータに対しても、パケットロスを起こしてしまったと誤認識する可能性があり、パケットロスが実際の値よりも高めに判定されるという問題点がある。
【００２７】
その理由を、図９を用いて説明する。特許文献１の技術では、単純にSNの順番のみでパケットロスを判定している。しかしながら、通信状態によっては、通信端末２から先に送信されたデータ（図９のSN２０００のデータ）が、後に送信されたデータ（図９のSN３０００のデータ）よりも遅く計測装置１を通過する可能性がある。この場合、先に送信したデータ（図９のSN２０００のデータ）はパケットロスを起こさずに、通信端末３に到着したにもかかわらず、計測装置１で過去に計測した最大SN（図９では３０００）よりも小さいために、パケットロスであると判定される。
【００２８】
更に、特許文献１の技術では、単位時間あたりに通信相手先が受け取ったデータ量であるグッドプットの品質が本来よりも低く算出されるという問題点がある。グッドプットは、通信相手側に届いたデータ量であり、“送信端末が送信したデータ量−パケットロス量”で求めることができる。しかしながら、特許文献１の技術では、パケットロス量を本来よりも多めに見積もる可能性があるため、“送信端末が送信したデータ量−パケットロス量”が本来よりも少なめに見積もられる可能性がある。
【００２９】
又、上述した非特許文献１の技術では、データ通信確立処理（3wayハンドシェイク）時のパケットロスの発生箇所しか判定できないという問題点がある。これは、非特許文献１の技術では、データ通信確立処理時のパケット到着順番を利用して、パケットの判定箇所を判断しているからである。一度通信処理が確立された後のデータ通信の順番は考慮していないため、長期間のデータ通信の途中でパケットロスした場合には、それを認識することはできない。
【００３０】
更に、非特許文献１の技術では、詳細なパケットロスの発生箇所までは判定できないという問題点がある。判定できるパケットロスの発生箇所は、通信装置２と計測装置１と間で発生したパケットロスか、計測装置１と通信装置３との間で発生したパケットロスである。前者のパケットロスの場合、通信装置２から計測装置１への通信でパケットがロスしたのか、計測装置１から通信装置２への通信でパケットがロスしたのかまでは判定することができない。同様に後者のパケットロスの場合には、計測装置１から通信装置３への通信でのパケットロスか、通信装置３から計測装置１へのパケットロスかまでは判定することはできない。これは、データ通信確立時のパケット計測の判断のみでは、通信端末２−計測装置１間のパケットロスの場合、通信装置２から計測装置１への通信でのパケットロスと、計測装置１から通信装置２への通信でのパケットロスで、計測装置１地点でのデータ計測順が同じになるからである。同様に、計測装置１−通信端末３間のパケットロスの場合、計測装置１から通信端末３への通信でのパケットロスと、通信端末３から計測装置１への通信でのパケットロスで、計測装置１地点でのデータ計測順が同じになるからである。
【００３１】
又、特許文献１及び非特許文献１の技術では、データ受信部で入力された情報のみを対象にネットワークの品質を計測しているため、ネットワーク内ではロスが発生していなくても、分岐装置４や分岐装置５、あるいはデータ受信部でデータを損失した場合には、データ損失であるとの誤認識や分類不能状態との判断が下される可能性があるという問題点がある。
【００３２】
これは、特許文献１の技術では、データ受信部で計測したパケットの量をもとに、パケットロスをしなかったデータ量やパケットロスした量を判定するため、計測装置内でデータが損失すると、そのデータに関しては、パケットロスにも通信量にも計上されないからである。また、非特許文献１の技術では、計測したデータの順番に依存した判断方法を採用しているために、その中のひとつでも計測装置内でデータが損失すると、想定している分類に収まらないからである。
【００３３】
そこで、本発明は上記課題に鑑みて発明されたものであって、その目的は、計測装置１において、通信端末２と通信端末３の間のグッドプット、パケットロス、及びパケットロスの発生箇所の測定精度を向上させる技術を提供することである。
【００３４】
又、計測装置１において、分岐装置から計測装置へデータを取り込む途中にデータが損失してもネットワークの品質を推定する技術を提供することである。
【課題を解決するための手段】
【００３５】
上記課題を解決するための第１の発明は、ネットワークの品質を計測する方法であって、
前記ネットワークに属する端末間で送受信されているデータを受信するステップと、
前記端末がデータの再送を要求する再送要求状態であるかを判定する判定ステップと、
前記受信したデータに含まれるデータの送信順番を示す送信順情報と、前記端末が受信したデータの情報を示す受信確認情報と、前記判定結果との中、少なくとも１つの情報に基づいて前記ネットワークの品質を判断する判断ステップと
を有することを特徴とする。
【００３６】
上記課題を解決すための第２の発明は、上記第１の発明において、前記判断ステップは、
前記受信したデータの送信順情報と、前回までに受信したデータの送信順情報とを比較するステップと、
前記比較の結果、前回までに受信したデータの送信順情報の方が大きい場合であり、前記判定結果が再送要求状態でない場合、若しくは前記判断結果が再送要求状態であるとは判定できない場合には、データ損失はなかったと判断するステップと
を有することを特徴とする。
【００３７】
上記課題を解決すための第３の発明は、上記第１の発明において、前記判断ステップは、
前記受信したデータの送信順情報と、前回までに受信したデータの送信順情報とを比較するステップと、
前記比較の結果、前回までに受信したデータの送信順情報の方が大きい場合であり、前記判定結果が再送要求状態である場合、若しくは前記判断結果が再送要求状態であると判定できる場合には、データ損失があったと判断するステップと
を有することを特徴とする。
【００３８】
上記課題を解決すための第４の発明は、上記第１から第３のいずれかの発明において、前記判定ステップは、
前記受信ステップにおいて、一定回数以上同一の受信確認情報のデータを受信している場合、もしくは、前記受信ステップが該送信順情報に対応する受信確認情報が記載されているデータを一定時間以内に受信しない場合に、再送要求状態であると判定することを特徴とする。
【００３９】
上記課題を解決すための第５の発明は、上記第１から第４のいずれかの発明において、前記判断ステップは、前記受信したデータの送信順情報の履歴を作成し、データの損失又はデータ損失場所を判断することを特徴とする。
【００４０】
上記課題を解決すための第６の発明は、上記第５の発明において、前記判断ステップは、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、該送信順情報のデータを以前にも受信したことがある場合には計測装置から受信端末までの間のデータの損失であると判断し、前記受信手段が該送信順情報のデータを以前にも受信したことがない場合には送信端末から計測装置までの間のデータ損失であると判断することを特徴とする。
【００４１】
上記課題を解決すための第７の発明は、上記第１の発明において、前記判断ステップは、前記受信データの送信順情報の履歴を前記受信ステップで該受信データを受信した時刻と共に記録し、端末側での通信量を判断することを特徴とする。
【００４２】
上記課題を解決すための第８の発明は、上記第７の発明において、前記判断ステップは、前記記録した送信順情報の履歴とその受信時刻との記録を参照し，ある一定期間の記録の中で最大値のデータ送信順情報を持つデータのデータ量と最小値のデータ送出順情報を持つデータのデータ量との差分をその期間の通信量と判断することを特徴とする。
【００４３】
上記課題を解決すための第９の発明は、上記第１の発明において、前記判断ステップは、前記受信データの受信確認情報の履歴を前記受信ステップで該受信データを受信した時刻と共に記録し、端末側での通信量を判断することを特徴とする。
【００４４】
上記課題を解決すための第１０の発明は、上記第９の発明において、前記判断ステップは、前記記録した受信確認情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値の受信確認情報を持つデータのデータ量と最小値の受信確認情報を持つデータのデータ量との差分をその期間の通信量と判断することを特徴とする。
【００４５】
上記課題を解決すための第１１の発明は、上記第１０の発明において、前記判断ステップは、単位時間あたりのデータ送信量が増加している間はデータ損失がないと判断し、通信量が減少した場合にはデータ損失が生じたと判断することを特徴とする。
【００４６】
上記課題を解決すための第１２の発明は、ネットワークの品質を計測する計測装置であって、
前記ネットワークに属する端末間で送受信されているデータを受信する受信手段と、
前記端末がデータの再送を要求する再送要求状態であるかを判定する判定手段と、
前記受信したデータに含まれる、データの送信順番を示す送信順情報と、端末が受信したデータの情報を示す受信確認情報の監視結果と、前記判定結果との中、少なくとも１つの情報に基づいて、前記ネットワークの品質を判断する判断手段と
を有することを特徴とする。
【００４７】
上記課題を解決すための第１３の発明は、上記第１２の発明において、前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、且つ前記判定結果が再送要求状態ではない場合、もしくは前記判定結果が再送要求状態であるとは推定できない場合には、データ損失があったと判断しないように構成されていることを特徴とする。
【００４８】
上記課題を解決すための第１４の発明は、上記第１２の発明において、前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、且つ前記判定の結果が再送要求状態である場合、もしくは前記判定の結果が再送要求状態であると推定できる場合には、データ損失があったと判断するように構成されていることを特徴とする。
【００４９】
上記課題を解決すための第１５の発明は、上記第１２から第１４のいずれかの発明において、前記判定手段は、前記受信手段が一定回数以上同一の受信確認情報のデータを受信している場合、もしくは、前記受信手段が該送信順情報に対応する受信確認情報が記載されているデータを一定時間以内に受信しない場合に、再送要求状態であると判定するように構成されていることを特徴とする。
【００５０】
上記課題を解決すための第１６の発明は、上記第１２から第１５のいずれかの発明において、前記判断手段は、前記受信手段が受信したデータの送信順情報の履歴を作成し、データの損失、又はデータ損失場所を判断するように構成されていることを特徴とする。
【００５１】
上記課題を解決すための第１７の発明は、上記第１６の発明において、前記判断手段は、前記送信順情報が前回までに計測したデータの送信順情報より大きくない場合であり、前記受信手段が該送信順情報のデータを以前にも受信したことがある場合には計測装置から受信端末までの間のデータの損失であると判断し、前記受信手段が該送信順情報のデータを以前にも受信したことがない場合には送信端末から計測装置までの間のデータ損失であると判断するように構成されていることを特徴とする。
【００５２】
上記課題を解決すための第１８の発明は、上記第１２の発明において、前記判断手段は、前記受信データの送信順情報の履歴を前記受信手段が該受信データを受信した時刻と共に記録し、端末側での通信量を判断するように構成されていることを特徴とする。
【００５３】
上記課題を解決すための第１９の発明は、上記第１８の発明において、前記判断手段は、前記記録した送信順情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値のデータ送信順情報を持つデータのデータ量と最小値のデータ送出順情報を持つデータのデータ量との差分をその期間の通信量と判断するように構成されていることを特徴とする。
【００５４】
上記課題を解決すための第２０の発明は、上記第１１の発明において、前記判断手段は、前記受信データの受信確認情報の履歴を前記受信手段が該受信データを受信した時刻と共に記録し、端末側での通信量を判断するように構成されていることを特徴とする。
【００５５】
上記課題を解決すための第２１の発明は、上記第２０の発明において、前記判断手段は、前記記録した受信確認情報の履歴とその受信時刻との記録を参照し、ある一定期間の記録の中で最大値の受信確認情報を持つデータのデータ量と最小値の受信確認情報を持つデータのデータ量との差分をその期間の通信量と判断するように構成されていることを特徴とする。
【００５６】
上記課題を解決すための第２２の発明は、上記第１６の発明において、ネットワークの品質を計測する計測装置であって、
前記判断手段は、単位時間あたりのデータ送信量が増加している間はデータ損失がないと判断し、通信量が減少した場合にはデータ損失が生じたと判断するように構成されていることを特徴とする。
【００５７】
上記課題を解決すための第２３の発明は、ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報及び受信確認情報の状態と、前記端末がデータの再送を要求しているかの再送要求状態とを監視することにより前記ネットワーク上でパケットロスがあったかを判定するように構成されていることを特徴とする。
【００５８】
上記課題を解決すための第２４の発明は、ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報及び受信確認情報の履歴を監視することにより前記ネットワーク上でパケットロスが発生したか否か、もしくはパケットロスが発生した箇所を判定するように構成されていることを特徴とする。
【００５９】
上記課題を解決すための第２５の発明は、ネットワークの品質を計測する計測装置であって、
端末が前記ネットワークを介して送受信するデータの送信順情報の時間変化及び受信確認情報の時間変化と、プロトコルの動きとを監視することにより前記ネットワークの品質を推定するように構成されていることを特徴とする。
【発明の効果】
【００６０】
本発明によると、データ到着順が逆転することによるパケットロスの誤認識を防ぎ、計測装置で計測する「パケットロス」の精度を向上させることが可能である。その理由は、状態監視部においてネットワークの状況を監視することで、データの受信端末側からの再送要求が出ていない間は、SNの順番が逆転していても、パケットロスに計上しないからである。
【００６１】
更に、本発明によると、データ受信端末における通信速度であるグッドプットを、計測装置で正しく計測することができる。その理由は、グッドプットの計測を、通過しているデータ量からではなく、プロトコルヘッダ情報をもとに観測しているため、計測装置を通過したパケットがロスしたかどうかの判断に関係なく、通信端末に届いたデータ量を認識することができるからである。
【００６２】
また、本発明によると、データ通信中におけるパケットロスの発生箇所を特定することができる。その理由は、データ確立処理時の処理順番ではなく、通信中にデータ送信端末とデータ受信端末間で発生している、データ送信番号（SN）と、受信確認番号（ACK）とをもとに判定しているからである。
【００６３】
また、本発明によると、計測装置で判定するパケットロスの発生箇所を、通信装置２から計測装置１への通信でパケットがロスしたのか、計測装置１から通信装置２への通信でパケットがロスしたのかを判定することができる。同様に、計測装置１から通信装置３への通信でのパケットロスか、通信装置３から計測装置１へのパケットロスかを判定することができる。その理由は、データ確立処理時の処理順番ではなく、通信中にデータ送信端末とデータ受信端末間で発生している、データ送信番号（SN）と、受信確認番号（ACK）と、をもとに判定しているからである。
【００６４】
また、本発明によると、分岐装置からネットワーク品質計測装置間でデータを損失しても、ネットワークの品質を計測することができる。その理由は、ネットワークの品質を、データ送信順番の時間変化と受信確認信号の時間変化の他に、対象としているプロトコルの動作を考慮しているからである。
【発明を実施するための最良の形態】
【００６５】
ネットワークの品質を計測する計測装置は、データ受信部において端末同士で送受信しているデータを受信し、フィルタリング部においてデータ受信部で受信したデータのフロー識別を行い、状態監視部において管理している同一フロー毎のACK番号情報とSN番号情報を元に、品質判定部でグッドプットや、パケットロスの有無、パケットロスの発生箇所を判断する。
【実施例１】
【００６６】
本発明の実施例１について図１０を参照して詳細に説明する。尚、本発明のネットワークの概念図は従来技術と同様であるため、詳細な説明は省略する。
【００６７】
図１０は、本実施例における計測装置１aを示すブロック図である。
【００６８】
計測装置１aは、データ受信部１１１、データ受信部１１２、フィルタリング部１２０、状態監視部１３０a、ACK番号監視部１３１a、再送監視部１３２a、最大SN監視部１３３a、品質判定部１４０a、パケットロス判定部１４１a、通常通信部１４２a、及びパケットロス部１４３aから構成される。尚、本実施例では、ネットワーク上を流れているデータを計測装置１aで取り込むことにより、処理が開始される。
【００６９】
データ受信部１１１は分岐装置４からのデータを受信し、データ受信部１１２は、分岐装置５からのデータを受信する。更に、データ受信部１１１及びデータ受信部１１２は、受信したデータをフィルタリング部１２０に渡す。
【００７０】
フィルタリング部１２０は、受信データの中に書き込まれている、送受信IP（Internet Protocol）アドレスや送受信TCP（Transmission Control Protocol）ポート番号、プロトコル番号等を元に、受信データを同一フロー毎に識別し、その結果を状態監視部１３０aに通知する。また、フィルタリング部１２０は、同一フロー毎に識別する際に、受信データが該当フローのACK側情報を持つか、SN側情報を持つかを判定する。更に、フィルタリング部１２０は、単位時間当たりに同一フローのデータを受信した量であるスループットを計測する。尚、本発明における同一フローとは、例えば、送信端末Ａが受信端末Ｂに対してあるデータを送信する際に行われる一連の処理を指す。
【００７１】
状態監視部１３０aは、同一フロー毎に、受信データのTCPプロトコルヘッダのSN（シーケンス番号）と、データ受信端末が受信確認信号に受信したSNの番号を記載したACK番号とを監視し、ACK番号、SN等の各種情報を抽出する。
状態監視部１３０aは、受信データがACK側情報を持っている場合、受信データのACK番号とACK番号監視部１３１aが保持している前回受信時のACK番号とを比較して、ACK番号が増加しているかを判定する。ACK番号は増加していないと判定すると、データ受信端末がデータの再送を要求しているかを判定する。尚、データ受信端末がデータの再送を要求しているか判定の方法として様々な種類が挙げられるが、例えば、通常のTCPの場合、データ送信端末がデータ受信端末から同じACK番号を３つ以上受信すると、データ送信端末は受信したACK番号の次の番号がＳＮに記載されているデータの再送をデータ受信端末が求めていると判断して、受信したACK番号の次の番号がＳＮに記載されているデータを再送する構成となっているので、同一ACK番号の重複回数を監視し、データ受信端末から同じACK番号を３つ以上送信しているかを確認して判定する。また、SACK（Selective
Acknowledgment）オプションが有効な場合、データ受信端末が再送してほしいデータのＳＮを記載して再送要求を出す構成となっているので、このような再送要求を受信端末が送信しているのかを監視して判定する構成であってもよい。また、受信端末が送信端末からのデータを受信し、そのデータを受信したことを示すACK信号を一定時間以内に受信しない場合に、受信端末が再送要求状態であると判定する構成であっても良い。
状態監視部１３０aは、再送要求をしていると判定すると、再送監視部１３２ａに再送要求されているACK番号を記憶する。
状態監視部１３０aは、受信データがＳＮ側情報を持っている場合、受信データのSNの値と、今まで受信した受信データのSNの最大値を記憶している最大ＳＮ監視部１３３ａの値とを比較し、大きい方の値を最大ＳＮ監視部１３３ａに記憶させる。
更に、状態監視部１３０ａは、単位時間当たりのACK番号の増加量を観測することにより、単位時間内にデータの受信端末が実際に受け取ったデータ量であるグッドプットを計測する。
【００７２】
ACK番号監視部１３１ａは、受信データのACK番号を同一フロー毎に受信した順に保持する。
【００７３】
再送監視部１３２ａは、データ受信端末が再送を要求しているACK番号をフロー毎に保持する。
【００７４】
最大SN監視部１３３ａは、同一フローにおいて、今まで受信したデータのSNの値が最大であるSNの値を保持する。
【００７５】
品質判定部１４０ａは、パケットロスとパケットロスの発生箇所とを判定するものであり、品質判定部１４０aは、パケットロス判定部１４１ａと、通常通信部１４２ａと、パケットロス部１４３ａとを有する。
【００７６】
パケットロス判定部１４１aは、状態監視部１３０aの状態を見ながら、パケットがロスしたかどうかを判断する。この判断結果をもとに、パケットロスが発生していない場合には、通常通信部１４２aに通信量を計上する。一方、パケットロスが発生している場合には、パケットロス部１４３aにロス量を計上する。
【００７７】
次に、計測装置１aにおけるスループット、グッドプット、パケットロスを判定する方法について説明する。
【００７８】
図１１は、計測装置１aにおける動作を説明するためのフロー図である。
【００７９】
データ受信部１１１が分岐装置４からのデータを受信する、若しくはデータ受信部１１２が分岐装置５からのデータを受信する（ステップＢ−１）。
【００８０】
フィルタリング部１２０は、受信データを送受信IPアドレス、送受信TCPポート番号、プロトコル番号などに基づいてフローを識別し、同一フロー毎に状態を管理する。さらに、フィルタリング部１２０は、単位時間当たりに同一フローのデータが計測装置１ａに入力された量であるスループットを計測する（ステップＢ−２）。
【００８１】
フィルタリング部１２０は、受信データが該当フローのACK側情報を持つか、SN側情報を持つかを判定する（ステップＢ−３）。なお、TCP通信の場合には、ひとつのデータ内にACK側情報とSN側情報とを持てる構成になっており、あるフローのACK側情報データが、他方のSN側情報データとなっている場合が多い。
【００８２】
ステップＢ−３でACK側情報を持つと判定された場合、状態監視部１３０ａは受信データのACK番号とACK番号監視部１３１ａが保持している前回受信時のACK番号とを比較して、ACK番号が増加しているかを判定する（ステップＢ−４）。
【００８３】
ステップＢ−４で、ACK番号が増加していると判定された場合、パケットロスが発生しておらず、順調にデータ通信が行われている状態であるため、ACK番号監視部１３１aは今回受信したACK番号を保持し（ステップＢ−５）、計測装置１ａは次のデータ入力を待つ（ステップB−１へ）。
【００８４】
ステップＢ−４で、ACK番号が増加していないと判定された場合、状態監視部１３０ａはデータ受信端末がデータの再送を要求しているかどうかを判定する（ステップＢ−６）。データの再送が要求されていないと判定された場合には、ACK番号監視部１３１aは今回受信したACK番号を保持し、計測装置１ａは次のデータ入力を待つ（ステップB−１へ）。
【００８５】
ステップＢ−６でデータ受信端末がデータの再送を要求していると判定された場合、パケットがロスし、データ受信端末がデータの再送を要求している最中であることを記憶しておくために、再送監視部１３２aは現在再送を要求されているACK番号を保持し（ステップＢ−７）、更にACK番号監視部１３１aは今回受信したACK番号を保持し、計測装置１ａは処理を終了して次のデータを待つ（ステップB−１へ）。
【００８６】
一方、ステップＢ−３でSN側情報を持つと判定された場合、状態監視部１３１ａは、最大ＳＮ監視部１３３ａの値を確認する（ステップＢ−８）。
【００８７】
状態監視部１３１ａは、ACK番号監視部１３１aが保持しているACK番号の値と再送監視部１３２aが保持している再送要求されているACK番号の値とを参照し、現在、データ受信端末からデータの再送が要求されている最中かどうかを確認する（ステップＢ−９）。ACK番号監視部１３１aが保持するACK番号の最大値と再送監視部１３２aが保持する再送要求番号の値とが一致している場合には現在再送中であると判断する。データの再送中で無い場合には、処理を終了して次のデータ入力を待つ（ステップＢ−１へ）。
【００８８】
ステップＢ−９でデータの再送中であると判定された場合、パケットロス判定部１４１aは、受信データのSNの値と最大SN監視部１３３aの値とを比較する（ステップＢ−１０）。受信データのSNの値と最大SN監視部１３３aの値とが一致するが、受信データのSNの値と再送監視部１３２aの値とが一致しない場合には、再送要求がデータ送信端末に届く前にデータ送信端末が送信したデータである、又は再送中であるが新規に送出したデータであるため、再送データではないと確定して通常通信部１４２ａの値を計上し、処理を終了して次のデータ入力を待つ（ステップＢ−１へ）。
【００８９】
受信データのSNの値が最大SN監視部１３３aの値よりも小さい場合、又は、受信データのSNの値と最大SN監視部１３３aの値と再送監視部１３２aの値とが一致する場合、受信データは再送データであると確定する。そして、受信データは少なくとも二度送信されたデータであり、一度目に送信されたデータは通信途中にパケットロスをしているため、パケットロス部１４３aの値として計上する（ステップＢ−１１）。
以上が本発明による実施例１における計測装置１aにおける処理内容である。
【００９０】
従来の技術においては、データ受信した場合に、過去に受信したSNの最大値と現在受信したデータのSNとを比較し、現在受信したデータのSNが小さければ、再送データとしてみなしていた。ネットワークの途中でパケットの順番が入れ替わった場合、パケットロスが実際には生じていなくても、過去に受信したデータのSNより現在受信したSNの方が小さくなる場合があり、パケットロスの誤認識が生じる可能性があった。
【００９１】
しかしながら、本実施例では、ACK番号の変化を監視し、再送要求を検知した場合に再送監視部１３２aに再送要求されている番号を格納し、ACK番号監視部１３１ａと再送監視部１３２aとの値が一致している場合のみ、過去に受信したSNの最大値と現在受信したデータのSNの値とを比較する構成である。このような構成をとっているため、パケットの順番が入れ替わって到着するような場合においても、再送要求が出ていない場合にはパケットロスであると判断せず、到着順変化によるパケットロスの誤認識をなくすことが可能となる。
【００９２】
尚、本実施例では簡単化のために、TCP通信の品質を計測する装置を用いて説明したが、送信データ中にデータの送信順を示す送信情報が記載されており、データ欠損に対する再送の仕組みが存在する構成に共通の技術である。したがって、HSTCP（High Speed TCP）やSCTP（Stream Control
Transmission Protocol）やDCCP（Datagram Congestion Control Protocol）といった再送機構の存在するプロトコル一般に用いることが可能である。また適用領域としては、上述した特許文献１の技術や非特許文献の技術のように、被計測ネットワークおよびトラヒックに影響を与えない図１の状態のみではなく、データを取得できる形式であれば、通信端末間の途中に挿入し、被計測ネットワークおよびトラヒックに影響を与える図１２のような形態でも用いることが可能である。図１２でのデータ中継端末とは、レイヤ２でデータ転送するイーサスイッチや、レイヤ３でデータ転送するルータ、レイヤ４以上で転送するゲートウェイ等であり、データをそのまま転送、あるいは、プロトコルを変更して転送する場合や、ロードバランス機能や帯域制御機能を付加した端末のことを指す。
【実施例２】
【００９３】
本発明における実施例２について説明する。
【００９４】
図１３は本発明の実施例２における計測装置１ｂの構成を示すブロック図である。尚、上述した実施例と同様の構成については同一番号を付し、詳細な説明は省略する。又、本実施例でも、ネットワーク上を流れているデータを計測装置１ｂに取り込むことにより、処理が開始されるものとする。
【００９５】
計測装置１ｂは、分岐装置４からのデータを受信するデータ受信部１１１と、分岐装置５からのデータを受信するデータ受信部１１２と、入力されたデータを同一フロー毎に識別するフィルタリング部１２０と、現在のネットワークの状態をチェックしている状態監視部１３０ｂと、パケットロスとパケットロスの発生箇所の判定を行う品質判定部１４０ｂとから構成される。
【００９６】
分岐装置４から入力されたデータはデータ受信部１１１で、分岐装置５から入力されたデータは、データ受信部１１２で受信する。データ受信部１１１又はデータ受信部１１２はデータを受け取った後、そのデータをフィルタリング部１２０に渡す。
【００９７】
フィルタリング部１２０では、受信データを送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、その結果を状態監視部１３０ｂに通知する。
【００９８】
状態監視部１３０ｂは、最大SN監視部１３３ｂと、SN監視部１３４ｂとを有する。
【００９９】
最大SN監視部１３３ｂは、受信した中で最大のSNを記憶する。
【０１００】
SN監視部１３４ｂは、すべての受信データのSNの記録及びそのSNが何度受信されたかが記録されているSN監視表を記憶する。
【０１０１】
品質判定部１４０ｂは、パケットロス判定部１４１ｂと、通常通信と判断されたデータの通信量を記憶しておく通常通信部１４２ｂと、パケットロスと判定されたデータの通信量を記憶しておくパケットロス部１４３ｂと、計測装置１と通信端末２の間でパケットロスした量を記憶する通信端末２−計測装置１パケットロス部１４３１ｂと、計測装置１と通信端末３の間でパケットロスした量を記憶する通信端末３−計測装置１パケットロス部１４３２ｂとを有する。
【０１０２】
パケットロス判定部１４１ｂは、状態監視部１３０ｂの状態を見ながら、パケットがロスしたかどうかを判断する。この判断結果を元に品質判定部１４０ｂは、パケットロスが発生していない場合には、通常通信部１４２ｂの通信量を計上する。パケットロスが発生している場合には、パケットロス部１４３ｂのロス量を計上する。さらに、パケットロス判定部１４１ｂは、パケットロスの発生箇所の結果をもとに、通信端末２−計測装置１パケットロス部１４３１ｂか、あるいは、計測装置１−通信端末３パケットロス部１４３２ｂに、パケットロス量を計上する。
【０１０３】
続いて本実施例における計測装置１ｂの動作について説明する。
【０１０４】
図１４は、計測装置１ｂにおけるスループット、グッドプット、パケットロス、パケットロスの発生箇所の判定動作のフロー図である。
【０１０５】
計測装置１aは、分岐装置４からのデータをデータ受信部１１１が受信する、又は分岐装置５からのデータをデータ受信部１１２が受信することにより処理が開始される（ステップC−１）。
【０１０６】
フィルタリング部１２０において、受信データに記載されている送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、同一フロー毎に状態を管理する。さらに、フィルタリング部１２０では、単位時間当たりに同一フローのデータが装置に入力された量であるスループットを計測する（ステップＣ−２）。
【０１０７】
フィルタリング部１２０は、入力されたデータが、該当フローのACK側情報を持つか、SN側情報を持つかを判定する（ステップＣ−２）。ここでACK側情報を持つ場合には、処理を終了し、次のデータ入力を待つ（ステップC−１へ）。なお、TCP通信の場合には、ひとつのデータ内にACK側情報とSN側情報を持てる構成になっており、あるフローのACK側情報データが、他方のSN側情報データとなっている場合が多い。
【０１０８】
ステップＣ−３で、SN側情報を持つと判定された場合には、状態監視部１３０ｂは受信データのSNを確認し、SN監視部１３４ｂに一度通過したSNを記憶させる。SN監視部１３４ｂに今回入力されたデータが、今までに通過した中の最大SNよりも大きい場合には、最大ＳＮ監視部１３３ｂの値を更新する（ステップＣ−４）。ここで、単位時間毎にSN監視部１３４ｂを参照し、その時間内に新たに増加した最小のSNと最大のSNとを比較すると、ユーザに届いたデータ量であるグッドプットを計測することが可能である。
【０１０９】
状態監視部１３０ｂは、現在入力されたデータのＳＮが最大ＳＮであるかを判定する（ステップＣ−５）。最大SN監視部１３４ｂが更新されていたと判定された場合には、今回パケットロスは認められないと判断して、処理を終了し、次のデータ入力を待つ（ステップC−１へ）。尚、ここで、現在入力されたデータが、最大SN監視部１３４ｂの値よりも小さな場合のデータ量を計上することでパケットロスの計測が可能である。
【０１１０】
ステップＣ−５で、現在入力されたデータのＳＮが最大SN監視部１３４ｂの値よりも小さいと判定された場合、パケットロス判定部１４１ｂは、前回通信時に、通信端末２と計測装置１との間と、計測装置１と通信端末３との間とのどちら側でパケットがロスしたかのパケットロスの発生箇所を判断する（ステップＣ−６）。通信端末２から通信端末３への通信の場合には、SN監視部１３４ｂのSN監視表を参照し、SNがそのチェックリストに存在する場合には、計測装置１と通信端末３との間のパケットロスと判断し、ステップC−７へ移動する。SNがそのチェックリストに存在しない場合には、通信端末２と計測装置１との間のパケットロスと判断し、ステップC−８へ移動する。通信端末３から通信端末２への通信の場合には、SN監視部１３４ｂのSN監視表を参照し、SNがそのチェックリストに存在しない場合には、計測装置１と通信端末３との間のパケットロスと判断し、ステップC−７へ移動する。SNがそのチェックリストに存在する場合には、通信端末２と計測装置１と間のパケットロスと判断し、ステップC−８へ移動する。
【０１１１】
ステップＣ−６で、計測装置１と通信端末３との間のパケットロスと判断された場合、今回受信時のパケットロス量を、測装端末１−通信端末３パケットロス部１４３２ｂに計上し（ステップＣ−７）、処理を終了する（ステップC−１へ）。
【０１１２】
ステップＣ−６で、計測装置２と通信端末１との間のパケットロスと判断された場合、今回受信時のパケットロス量を、通信端末２−計測装置１パケットロス部１４３１ｂに計上し（ステップＣ−８）、処理を終了する（ステップC−１へ）。
【０１１３】
以上が本発明の実施例２における計測装置１ｂの動作である。
【０１１４】
従来の技術においては、データ確立処理の3wayハンドシェイクの仕組みを利用してパケットロスの発生箇所を特定していた。このため、データ通信中のパケットロスの発生箇所を特定することができなかった。また、3wayハンドシェイク時のデータ計測順の判定では、通信端末２−計測装置１間のパケットロスか、計測装置１−通信端末３間のパケットロスかは判定することが可能であるが、データ計測順が、通信端末２から計測装置１への通信中のロスと、計測装置１から通信端末２への通信中のロスとで同じになるため、どちら側の通信中のロスかまでは判定できない。計測装置１−通信端末３間のパケットロスも同様である。
【０１１５】
しかしながら、本実施例では、通信中に常に発生しているSNとACK番号の変化から、パケットロスの発生箇所を特定している。このため、通信が発生している間は常にロス位置を特定することが可能である。また、SNやACKは通信端末２から通信端末３への通信と、通信端末３から通信端末２への通信で別々に管理するために、通信端末２−計測装置１間のパケットロスの場合、通信端末２から計測装置１への通信中のロスか、計測装置１から通信端末２への通信中のロスか、を判定することが可能である。計測装置１−通信端末３間のパケットロスも同様である。
【０１１６】
本実施例は、簡単化のために、TCP通信の品質を計測する装置で説明したが、送信データ中にデータ列の順番が記載されており、データ欠損に対する再送の仕組みが存在するものに共通の技術である。したがって、HSTCPやSCTPやDCCPといった再送機構の存在するプロトコル一般を含む。
【０１１７】
また適用領域としては、特許文献１や非特許文献１のように、被計測ネットワークおよびトラヒックに影響を与えない図１の状態のみではなく、データを取得できる形式であれば、通信端末間の途中に挿入し、被計測ネットワークおよびトラヒックに影響を与える図１２のような形態でも可能である。図１２でのデータ中継端末とは、レイヤ２でデータ転送を行うイーサスイッチや、レイヤ３でデータ転送を行うルータ、レイヤ４以上での転送を行うゲートウェイ等であり、データをそのまま転送、あるいは、プロトコルを変更して転送する場合や、ロードバランス機能や帯域制御機能を付加した端末のことをさす。
【実施例３】
【０１１８】
本発明における実施例３について説明する。
【０１１９】
図１５は実施例３の計測装置１ｃのブロック図である。尚、上述した実施例と同様の構成については同一番号を付し、詳細な説明は省略する。又、本実施例でも、ネットワーク上を流れているデータを計測装置１ｃに取り込むことにより、処理が開始されるものとする。
【０１２０】
実施例３の計測装置１ｃは、分岐装置からのデータを受信するデータ受信部１１１と、データ受信部１１２と、入力されたデータを同一フロー毎に識別するフィルタリング部１２０と、現在のネットワークの状態をチェックしている状態監視部１３０ｃと、パケットロス及びパケットロスの発生箇所の判定を行う品質判定部１４０ｃとから構成される。
【０１２１】
データ受信部１１１は、分岐装置４からのデータを受信する。データ受信部１１２は、分岐装置５からのデータを受信する。データ受信部１１１又はデータ受信部１１２は受信したデータを受け取った後、そのデータをフィルタリング部１２０に渡す。
【０１２２】
フィルタリング部１２０は、受信データを送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、その結果を状態監視部１３０ｃに通知する。又、受信データが該当フローのACK側情報を持つか、SN側情報を持つかを判定する。
【０１２３】
状態監視部１３０ｃは、同一フロー毎に、受信データのTCPプロトコルヘッダのSN（シーケンス番号）と、受信端末が受信確認信号に受信したSNの番号を記載したACK番号とを監視し、ACK番号、SN等の各種情報を抽出する。
【０１２４】
品質判定部１４０ｃは、はじめにパケットロス判定部１４１ｃで、状態監視部１３０ｃの状態を見ながら、パケットロスが発生したかどうかを判断し、ロスが発生している場合にはそのロスの発生箇所を特定する。パケットロスが発生したかの判断結果をもとに、パケットロスが発生していない場合には、通常通信部１４２ｃに通信量を計上する。パケットロスが発生している場合には、パケットロス部１４３ｃにロス量を計上する。さらに、パケットロスの発生箇所の結果をもとに、通信端末２−計測装置１パケットロス部１４３１ｃか、あるいは、計測装置１−通信端末３パケットロス部１４３２ｃに、パケットロス量を計上する。
【０１２５】
続いて、本実施例の計測装置１ｃにおけるスループット、グッドプット、パケットロス、パケットロスの発生箇所を判定する動作について説明する。
【０１２６】
図１６は、計測装置１ｃにおける動作のフローを示す図である。
【０１２７】
図１７は、本実施例における状態遷移図である。
【０１２８】
計測装置１ｃは、分岐装置４からのデータをデータ受信部１１１が受信する、あるいは分岐装置５からのデータをデータ受信部１１２が受信することにより処理が開始される（ステップD−１）。
【０１２９】
フィルタリング部１２０において、受信データを送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、同一フロー毎に状態を管理する。さらに、フィルタリング部１２０は、単位時間当たりに同一フローのデータが装置に入力された量であるスループットを計測する（ステップＤ−２）。
【０１３０】
フィルタリング部１２０は、受信データが該当フローのACK側情報を持つか、或いはSN側情報を持つかを判定する（ステップD−３）。ここでACK側情報を持つと判定された場合には、ステップD−４へ移動する。SN側情報を持つと判定された場合には、ステップD−８へ移動する。なお、TCP通信の場合には、ひとつのデータ内にACK側情報とSN側情報を持てる構成になっており、あるフローのACK側情報データが、他方のSN側情報データとなっている場合が多い。
【０１３１】
状態監視部１３０ｃは、受信データのACK番号とACK番号監視部１３１ｃに格納されている前回受信したデータのACK番号とを比較して、受信データのACK番号が増加しているかどうかを判定する（ステップD−４）。ACK番号が増加している場合には、ステップD−５へ、ACK番号が前回受信時と同じ番号の場合には、ステップD−６へ移動する。なお、状態監視部１３０ｃは、単位時間当たりのACK番号の増加量を観測することにより、単位時間内にデータの受信端末が実際に受け取ったデータ量であるグッドプットを計測することが可能である。図１７の状態遷移図でいうと、ACK番号が増加している場合には、状態Xである。また、いままで状態Yや状態Z、状態Wであったとしても、ACKが増加することにより、状態Xに変化する。
【０１３２】
ステップＤ−４でACK番号が増加していると判定された場合、パケットロスが発生しておらず、順調にデータ通信が行われている状態であるので、状態監視部１３０ｃは今回受信したACK番号をACK番号監視部１３１ｃに格納し（ステップD−５）、処理を終えて、次のデータ入力を待つ（ステップD−１へ）。
【０１３３】
ステップＤ−４でACK番号が増加していないと判定された場合、状態監視部１３０ｃはデータ受信端末がデータの再送を要求しているかどうかを判定する（ステップＤ−６）。尚、判定の方法としては、例えば、通常のTCPの場合、データ送信端末がデータ受信端末から同じACK番号を３つ以上受信すると、データ送信端末は受信したACK番号の次の番号がＳＮに記載されているデータの再送をデータ受信端末が求めていると判断して、受信したACK番号の次の番号がＳＮに記載されているデータを再送する構成となっているので、データ受信端末から同じACK番号を３つ以上送信しているかを確認して判定する構成であっても良い。また、SACKオプションが有効な場合、データ受信端末が再送して欲しいデータのＳＮを記載して再送要求を出す構成となっているので、このような再送要求を受信端末が送信しているかを確認して判定する構成であっても良い。
再送要求されている場合には、ステップD−７へ、再送要求されていない場合には、処理を終了し、次のデータ入力を待つ（ステップD−１へ）。
【０１３４】
現在データ受信端末側がデータの再送を要求している状態であるため、パケットがロスし、データの再送を要求している最中であることを記憶しておくために、状態監視部１３０ｃは現在再送を要求されているデータのＳＮ番号を再送監視部１３２a内に記憶し（ステップD−７）、処理を終える（ステップD−１へ）。ここで、新たな番号で再送要求されたとき、図１７の状態遷移図での再送トリガ（再送要求）が行われたとみなされ、状態Xから状態Yへ遷移する。
【０１３５】
状態監視部１３０ｃは、ACK番号監視部１３１ｃの最大値と再送監視部１３２ｃの最大値とを参照し、現在データ受信端末からの再送要求が行われている最中かどうかを確認する（ステップD−８）。ACK番号監視部１３１ｃの最大値と、再送監視部１３２ｃの最大値が一致している場合には、現在再送中の通信であると判断してステップD-９へ移動する。データの再送中で無い場合には、ステップD−１４へ移動する。
【０１３６】
現在の状態は、パケットロスが発生し、再送中の状態であり、図１７の状態遷移図では状態Yか状態Zに相当する。このような状態において、状態監視部１３０ｃは、パケットロスが発生した後の再送要求後に、データ送信端末が初めに送付したデータかどうかを判定する（ステップD−９）。状態遷移図の状態Xから状態Yに遷移した直後に、はじめてSNが減少した場合を、再送要求後の初データと判断する。計測装置1ｃで再送要求信号を受信したとしても、それがデータ送信端末に届くまでに時間差が存在する。このため、データ送信端末からのデータ再送を確認して、パケットロスが生じる前に通信していた最大SNを調査するために、本ステップの処理を行う。再送要求後の初データの場合にはステップD−１０へ、再送要求後の初データでない場合にはステップD−１５へ移動する。
【０１３７】
状態監視部１３０ｃは、パケットロスが発生する直前に何番までのSNのデータが通信されていたかを確認し、その中の最大ＳＮを最大SN監視部１３３ｃに記憶する（ステップD−１０）。図１７の状態遷移図では状態Yである。
【０１３８】
パケットロス判定部１４１ｃは、前回通信時に、通信端末２と計測装置１との間と、計測装置１と通信端末３との間とのどちら側でパケットがロスしたかの「パケットロスの発生箇所」を判断する。通信端末２から通信端末３への通信の場合には、SN監視部１３４ｃのSN監視表を参照し、SNがそのチェックリストに存在する場合には、計測装置１と通信端末３との間のパケットロスと判断し、ステップD−１４へ移動する。SNがそのチェックリストに存在しない場合には、通信端末２と計測装置１との間のパケットロスと判断し、ステップD−１５へ移動する。通信端末３から通信端末２への通信の場合には、SN監視部１３４ｃのSN監視表を参照し、SNがそのチェックリストに存在しない場合には、計測装置１と通信端末３との間のパケットロスと判断し、ステップD−１４へ移動する。SNがそのチェックリストに存在する場合には、通信端末２と計測装置１との間のパケットロスと判断し、ステップD−１５へ移動する。
【０１３９】
パケットロス判定部１４１ｃは、今回受信時のパケットロス量を、測装端末１−通信端末３間パケットロス部１４３２ｃに計上し（ステップD−１２）、処理を終了する（ステップD−１へ）。
【０１４０】
パケットロス判定部１４１ｃは、今回受信時のパケットロス量を、通信端末２−計測装置１間パケットロス部１４３１ｃに計上し（ステップD−１３）、処理を終了する（ステップD−１へ）。
【０１４１】
一方、ステップＤ−８で、SN側情報であると判定された場合、SN監視部１３４ｃに受信データのSNを記憶し（ステップD−１４）、処理を終了して次回データ入力を待つ(ステップD-1へ)。この状態は、図１７の状態遷移図中の状態Xである。
【０１４２】
ステップD−９で、再送要求中であるが、再送要求後の初データ以外を受信したと判定された場合、受信データのSNとSN監視部１３４cの値とを比較する（ステップD−１５）。本ステップでは，データ送信端末が再送要求を受け取る前に送信したデータである、即ち、状態が状態Xから状態Yに変化後、SNが小さくなっていない状態の場合と、再送通信中にパケットロス前の通信よりもSNが大きなデータを計測した場合と、最大SN監視部１３３cのSN以上のSNを持つデータを計測した場合に行われる。この処理で、受信データのSNが今回のロスに対する最大SN監視部１３３cのSNを超える判定されると、図１７の状態遷移での，状態Yから状態Zに遷移し，処理を終了する（ステップD−１へ）。受信データのSNが今回のロスに対する最大SN監視部１３３cのSNを超えないと判定された場合には、ステップD−１１へ移動する．
本実施例における状態遷移図と状態監視部１３０ｃとの関係の一例を、図１８に示す。
【０１４３】
以上が本発明による実施例３における計測装置１ｃの動作内容である。
【０１４４】
従来の技術においては、データ受信した際に、過去に受信したSNの最大値と、現在受信したデータのSNとを比較し、現在受信したデータのSNが小さければ、再送データとしてみなしていた。そのため、ネットワークの途中でパケットの順番が入れ替わった場合、パケットロスが実際には生じていなくても、過去に受信したデータのSNより現在受信したSNの方が小さくなる場合があり、パケットロスの誤認識が生じる可能性があった。また、データ確立処理の3wayハンドシェイクの仕組みを利用してパケットロスの発生箇所を特定していた。このため、データ通信中のパケットロスの発生箇所を特定することができなかった。さらに、3wayハンドシェイク時のデータ計測順の判定では、通信端末２−計測装置１間のパケットロスか、計測装置１−通信端末３間のパケットロスかは判定することが可能であるが、データ計測順が、通信端末２から計測装置１への通信中のロスと、計測装置１から通信端末２への通信中のロスとで同じになるため、どちら側の通信中のロスかまでは判定できなかった。計測装置１−通信端末３間のパケットロスも同様である。
【０１４５】
これに対して、本実施例では、状態監視部１３０ｃにおいて、ACK番号の変化を監視し、ACK番号監視部１３１ｃの値と再送要求を検知した場合に再送監視部１３２ｃの値とを比較し、これらの番号が一致している場合のみ、過去に受信したSNの最大値と現在受信したデータのSNとを比較する。このため、パケットの順番が入れ替わって到着するような場合においても、再送要求が出ていない場合にはパケットロスであると判断せず、到着順変化によるパケットロスの誤認識をなくすことが可能である。また、通信中に常に発生しているSNとACK番号との変化から、パケットロスの発生箇所を特定している。このため、通信が発生している間は常にロス位置を特定することが可能である。さらに、本発明では、SNやACKを、通信端末２から通信端末３への通信と、通信端末３から通信端末２への通信とで別々に管理するために、通信端末２−計測装置１間のパケットロスの場合、通信端末２から計測装置１への通信中のロスか、計測装置１から通信端末２への通信中のロスか、を判定することが可能である。計測装置１−通信端末３間のパケットロスも同様である。
【０１４６】
本実施例は、簡単化のために、TCP通信の品質を計測する装置で説明したが、送信データ中にデータ列の順番が記載されており、データ欠損に対する再送の仕組みが存在するものに共通の技術である。したがって、HSTCPやSCTPやDCCPといった再送機構の存在するプロトコル一般を含む。
【０１４７】
また適用領域としては、特許文献１や非特許文献２のように、被計測ネットワークおよびトラヒックに影響を与えない図１の状態のみではなく、データを取得できる形式であれば、通信端末間の途中に挿入し、被計測ネットワークおよびトラヒックに影響を与える図１２のような形態でも可能である。図１２でのデータ中継端末とは、レイヤ２でデータ転送を行うイーサスイッチや、レイヤ３でデータ転送を行うルータ、レイヤ４以上での転送を行うゲートウェイ等であり、データをそのまま転送、あるいは、プロトコルを変更して転送する場合や、ロードバランス機能や帯域制御機能を付加した端末のことをさす。
【実施例４】
【０１４８】
本発明における実施例４について説明する。
【０１４９】
図１９は本発明の実施例四における計測装置１ｄの構成を示すブロック図である。尚、上述した実施例１と同様の構成については同一番号を付し、詳細な説明は省略する。又、本実施例でも、ネットワーク上を流れているデータを計測装置１ｂに取り込むことにより、処理が開始されるものとする。
【０１５０】
実施例４の計測装置１ｄは、分岐装置４からのデータを受信するデータ受信部１１１と、分岐装置５からのデータを受信するデータ受信部１１２と、入力されたデータを同一フロー毎に識別するフィルタリング部１２０と、現在のネットワークの状態をチェックしている状態監視部１３０ｄと、品質判定部１４０ｄと、から構成される。
【０１５１】
データ受信部１１１は、分岐装置４からのデータを受信する。データ受信部１１２は、分岐装置５からのデータを受信する。データ受信部１１１又はデータ受信部１１２はデータを受け取った後、そのデータをフィルタリング部１２０に渡す。
【０１５２】
フィルタリング部１２０では、データを受け取るとタイマ１５０で受信時刻を記録する。その後、受信データを送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、その結果を状態監視部１３０ｄに通知する。
【０１５３】
状態監視部１３０ｄでは、同一フロー毎に、受信データのTCPプロトコルヘッダの、データ順番情報であるSNと、受信端末で受信確認したSNの番号を記載しているACK番号を監視する。ACK変化監視部１３５ｄは、ACK番号の変化を監視する。SN変化監視部１３６ｄは、SNの変化を監視する。
【０１５４】
品質判定部１４０ｄは、通信中のプロトコルの動作がどのように振舞うかを記憶しているプロトコル動作記憶部１４６ｄと、状態監視部１３０ｄの情報をもとに、パケットロスやラウンドトリップ時間、スループットなどの情報を推定するネットワーク品質判定部１４５ｄとを有す。
【０１５５】
続いて、計測装置１ｄにおけるネットワークの品質を判定する動作について説明する。
【０１５６】
計測装置１ｄは、データ受信部１１１が分岐装置４からのデータを受信する、あるいは、データ受信部１１２が分岐装置５からのデータを受信することにより処理が開始される（ステップＥ−１）。
【０１５７】
フィルタリング部１２０には、受信データを送受信IPアドレスや送受信TCPポート番号、プロトコル番号などを元に、フローの識別を行い、同一フロー毎に状態を管理する。このとき、タイマ１５０の値を参照し、データが入力された時刻も記録する。さらに、単位時間当たりに同一フローのデータが装置に入力された量であるスループットを計測する（ステップE−２）。
【０１５８】
状態監視部１３０ｄは、SN変化量を確認してSN変化監視部１３６ｄに記録し、ACK変化量を確認してACK変化監視部１３５ｄに記録する（ステップE−３）。
【０１５９】
ネットワーク品質判定部１４０ｄは、現在通信中のプロトコルの動作と、ACK変化監視部１３５ｄやSN変化監視部１３６ｄの動きを照らし合わせて、ネットワークの品質を確認する（ステップＥ−４）。
【０１６０】
たとえば、対象プロトコルがTCPであり、パケットロスが発生していない場合、データ送信端末は通信速度を速くし、パケットロスが発生した場合には、通信速度を遅くする。このようにプロトコルの動作を参照し、SNチェックを行い、単位時間中のデータ送信速度が向上している間は、パケットロスが発生していないと推定し、単位時間中のデータ通信速度が落ちた場合には、パケットロスが発生していると推定する。その他、パケットロスが発生していない間は、通信速度が通信相手とのラウンドトリップ時間に依存する関数によって上昇していく。この通信速度の向上の割合を計測することにより、通信端末２と通信端末３の間のラウンドトリップ時間を推定することが可能である。さらに、単位時間中に変化したACK番号の増量分やSN番号の増量分から、データ受信端末が実際に受け取ったデータ量であるグッドプットを推定することが可能になる。
以上が本発明による実施例４における計測装置における処理内容である。
【図面の簡単な説明】
【０１６１】
【図１】本技術の適用領域の概要を示す図である。
【図２】従来のTCP通信の品質を測定する技術の処理概要を示す図である。
【図３】従来のTCP通信の品質を測定する技術でのCASE０のHTTPフローの流れを示す図である。
【図４】従来のTCP通信の品質を測定する技術でのCASE１のHTTPフローの流れを示す図である。
【図５】従来のTCP通信の品質を測定する技術でのCASE２のHTTPフローの流れを示す図である。
【図６】従来のTCP通信の品質を測定する技術でのCASE３のHTTPフローの流れを示す図である。
【図７】従来のTCP通信の品質を測定する技術でのCASE４のHTTPフローの流れを示す図である。
【図８】従来のTCP通信の品質を測定する技術でのCASE５のHTTPフローの流れを示す図である。
【図９】従来の第一の方法の問題点を示す図である。
【図１０】第一の実施例における計測装置でのブロック図である。
【図１１】第一の実施例における計測装置での処理フローの概要を示す図である。
【図１２】本技術の適用領域の概要を示す図である。
【図１３】第二の実施例における計測装置でのブロック図である。
【図１４】第二の実施例における計測装置での処理フローの概要を示す図である。
【図１５】第三の実施例における計測装置でのブロック図である。
【図１６】第三の実施例における計測装置での処理フローの概要を示す図である。
【図１７】第三の実施例における計測装置での状態遷移を示す図である。
【図１８】第三の実施例における計測装置での状態監視部でのチェック手法の一例を示す図である。
【図１９】第四の実施例における計測装置でのブロック図である。
【図２０】第四の実施例における計測装置での処理フローの概要を示す図である。
【符号の説明】
【０１６２】
１          計測装置
２，３      通信端末
４，５      分岐装置
１１１      データ受信部
１１２      データ受信部
１２０      フィルタリング部
１３０      状態監視部
１４０      品質判定部
【図１】
2006067217.tif 000003
【図２】
2006067217.tif 000004
【図３】
2006067217.tif 000005
【図４】
2006067217.tif 000006
【図５】
2006067217.tif 000007
【図６】
2006067217.tif 000008
【図７】
2006067217.tif 000009
【図８】
2006067217.tif 000010
【図９】
2006067217.tif 000011
【図１０】
2006067217.tif 000012
【図１１】
2006067217.tif 000013
【図１２】
2006067217.tif 000014
【図１３】
2006067217.tif 000015
【図１４】
2006067217.tif 000016
【図１５】
2006067217.tif 000017
【図１６】
2006067217.tif 000018
【図１７】
2006067217.tif 000019
【図１８】
2006067217.tif 000020
【図１９】
2006067217.tif 000021
【図２０】
2006067217.tif 000022