通信品質測定方法および装置
【課題】監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいてクライアントの通信品質を正確に分析する。
【解決手段】一括送信回数判定部１０４は、データ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、MHからサーバへ送信された総データ量をデータ通信開始時におけるサーバ側の初期ウィンドウサイズと比較することで、監視対象のコネクションが、その完了までにデータをウィンドウサイズ単位で一括送信する回数を判定する。通信品質算出部１０５は、一括送信回数が「１回」のセッションを対象に通信品質を測定する第１測定部１０５ａ、および一括送信回数が「２回以上」のセッションを対象に通信品質を測定する第２測定部１０５ｂを備え、エンド側固定遅延時間を利用して無線区間のスループットを計測する。
【解決手段】一括送信回数判定部１０４は、データ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、MHからサーバへ送信された総データ量をデータ通信開始時におけるサーバ側の初期ウィンドウサイズと比較することで、監視対象のコネクションが、その完了までにデータをウィンドウサイズ単位で一括送信する回数を判定する。通信品質算出部１０５は、一括送信回数が「１回」のセッションを対象に通信品質を測定する第１測定部１０５ａ、および一括送信回数が「２回以上」のセッションを対象に通信品質を測定する第２測定部１０５ｂを備え、エンド側固定遅延時間を利用して無線区間のスループットを計測する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信品質測定方法および装置に係り、特に、無線区間の通信品質をパッシブに測定する通信品質測定方法および装置に関する。
【背景技術】
【０００２】
無線通信システムの通信事業者には、広域なサービスエリアの全域で通信品質情報を局所領域ごとに取得してエリアマップを作成し、サービスエリア全体の通信品質状態を漏れなく評価することが要求される。
【０００３】
特許文献１には、パケット通信網を介して接続された２つの品質測定装置間で、一方の品質測定装置から他方の品質測定装置に向けて測定パケットを送信し、他方の品質測定装置は一方の品質測定装置からの送信された測定パケットの受信に応答して測定パケットを返送し、一方の品質測定装置は他方の品質測定装置から返送された測定パケットの受信状況に基づき品質測定装置間のTCPスループット、再送発生率、平均パケット往復遅延、タイムアウト再送等が発生する確率を推定する技術が開示されている。
【０００４】
特許文献２には、複数の端末やTCPコネクションが１つのボトルネックリンクを共有し、それらTCPコネクションによりデータが転送される場合に、ボトルネックリンクの伝送帯域に基づいてTCPコネクションの平均スループットを精度よく算出するTCPスループット算出方法が開示されている。
【０００５】
上記の先行技術はいずれも、送信側端末および受信側端末を協働させ、各端末での計測結果に基づいて通信品質が推定されるので、要求対象の装置数が大量になるとスケーラビリティの問題がある。
【０００６】
このような技術課題に対して、本発明の発明者等は、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいてクライアントの通信品質を分析する通信品質測定方法および装置を発明し、特許出願（特許文献３）した。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【特許文献２】特開２００３−２０９５７４号公報
【特許文献３】特願２０１１−５３３７９号
【発明の概要】
【発明が解決しようとする課題】
【０００８】
相互に通信するノードペアの一方が無線端末である場合、その無線区間の通信品質としてスループットを測定するのであれば、経路上のキャプチャポイントにおいて、データ通信の開始を要求する要求パケットの到着時刻t_startと、データ通信の完了を通知する完了パケットの到着時刻t_endと、その間に送受された総データ量ｄとを測定し、総データ量dをデータ通信の所要期間TotalTime(=t_end−t_start)で除せば良い。なお、無線区間を含むネットワークでのデータ通信の場合、一般的に無線区間がボトルネックとなることから、無線区間側のスループットを算出することにより、ユーザあるいは端末が享受・体感しているスループットを算出することができる。
【０００９】
しかしながら、このようなパッシブ測定ではキャプチャポイントを通過するパケット量が膨大であるため、双方向の全てのパケットを漏れなくキャプチャし、かつ全ての要求パケットと応答パケットとを対応付けることは、処理規模が膨大となり、リアルタイムまたは准リアルタイムに計算するのが困難であった。
【００１０】
さらに、リクエストパケットに対する応答として返信されるACKパケットは、TCPの性質上、一つのデータパケットの受信毎に返信されるとは限らない。このため、パケット転送の終了タイミングをACKパケットの到着時刻で代表させてしまうと、所要期間が大きな誤差を含むことになり、スループットを正確に測定できなくなる。
【００１１】
本発明の目的は、上記した従来技術の課題を全て解決し、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいて無線クライアント側の通信品質を正確に分析できる通信品質測定方法および装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明は、無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、以下のような手段を講じた点に特徴がある。
【００１３】
(1) 無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、ログ情報に基づいて、キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを設けた。通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出するようにした。
【００１４】
(2) エンド側固定遅延が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて算出されるようにした。
【００１５】
(3) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定し、この一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択するようにした。
【００１６】
(4) 通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を設け、一括送信回数を、通信のデータ量が通信開始時のウィンドウサイズ以下であれば１回と判定し、ウィンドウサイズよりも大きければ２回以上と判定するようにした。
【００１７】
(5) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が２回以上と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを代替所要時間として算出し、２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じて所要時間を算出し、前記総データ量を前記所要時間で除してスループットを算出するようにした。
【００１８】
なお、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を減じる回数はスループットの定義に応じて変更しても良い。例えば、このような固定遅延（オーバヘッド）をスループットに含ませないのであれば、各固定遅延時間の和の(n-1)倍を減じれば良い。また、TCPウィンドウサイズが開き切るまでの固定遅延のみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでの通信回数の倍数だけ減じればよい。
【００１９】
さらに、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じ、片道分のサーバエンド側固定遅延時間を加えることで算出する。
【００２０】
(6) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が１回と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出するようにした。ただし、このようなスループット算出方式は、TCPの確立直後（例えば、0.1sec以内）からデータ通信が開始されることが前提となる。
【００２１】
なお、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えることで算出する。
【００２２】
(7) キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段をさらに設けた。
【００２３】
(8) 測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とするようにした。
【００２４】
(9) スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されるようにした。
【００２５】
(10) 一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定するようにした。
【発明の効果】
【００２６】
本発明によれば、以下のような効果が達成される。
【００２７】
(1) TCPコネクションのスループットを、ネットワーク上に設けたキャプチャポイントにおいて一方向のパケット（無線クライアントからサーバへ送信される上りパケット）のみをパッシブに監視するだけで計測できるようになる。したがって、一コネクション当たりの監視パケット数を少なくでき、その結果、多数のコネクションを同時に監視できるようになるので、スケーラブルなスループット測定が可能になる。
【００２８】
(2) 無線側およびサーバ側の各エンド側固定遅延時間が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて求められるので、各エンド側の固定遅延時間を計測する為の機能を別途に用意する必要がない。
【００２９】
(3) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、一括送信回数が１回の場合と２回以上の場合とで、スループットの測定アルゴリズムを異ならせるので、通信の総データ量にかかわらず常に正確なスループット計測が可能になる。また、一括送信回数が１回であるか２回以上であるかを、通信開始時のウィンドウサイズをデータサイズと比較するだけで判定できるようになる。
【００３０】
(4) キャプチャ漏れしたパケットのログ情報を、ウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を設けたので、通信の総データ量を、より正確に算出できるようになる。
【００３１】
(5) メールセッションでは、セッションサイズの小さいメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズの大きいメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じてメールセッションの所要時間とするので、メールセッションについても正確なスループット計測が可能になる。
【００３２】
(6) HTTPセッションでは、スループット計測がセッション単位で行われるので、例えばHTTP・WEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThink Timeが生じても、このThink Timeが除外された正確なスループット計測が可能になる。
【００３３】
(7) TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得することにより、クライアント端末やTCPの違いにかかわらず通信開始時のウィンドウサイズを正確に判別できるようになる。その結果、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を正確に判定できるようになる。
【図面の簡単な説明】
【００３４】
【図１】本発明が適用されるネットワークの構成を示したブロック図である。
【図２】キャプチャ装置の第１実施形態の機能ブロック図である。
【図３】本発明の動作を示したフローチャートである。
【図４】本発明の動作を示したシーケンスフロー（その１）である。
【図５】本発明の動作を示したシーケンスフロー（その２）である。
【図６】キャプチャ装置の第１実施形態の機能ブロック図である。
【図７】本発明の概要を説明するための図（その１）である。
【図８】本発明の概要を説明するための図（その２）である。
【発明を実施するための形態】
【００３５】
以下、図面を参照して本発明の実施形態について詳細に説明する。ここでは初めに、本発明の概要について説明し、次いで、その具体的な実施形態について説明する。なお、以下の説明では基本的に、トランスポート層（第４層）での接続を「コネクション」と表現し、これよりも上位層での接続を「(HTTP)セッション」と表現することで両者を区別しているが、両者を「コネクション」で代表する場合もある。
【００３６】
本発明は、無線区間を含むTCPコネクションのスループットをコネクション単位(HTTPおよびメールでは、セッション単位)で測定するものとし、ネットワーク上のキャプチャポイントで監視するキャプチャ対象のパケットを、TCPコネクションの確立時に送受される制御パケット、ならびにTCPコネクション確立後は当該コネクションまたはそのセッション内で観測される上りパケットのみに限定することで、一コネクション当たりのキャプチャ対象のパケット数を減じ、多数のコネクションを監視対象とできるようにすることで、パッシブ測定に必須のスケーラビリティを担保しながら、精度の高いスループット測定を可能にしている。
【００３７】
ただし、このようにして計測される期間（上りパケットの到着時刻差）は、スループット計測のための前記所要時間TotalTime(=t_end−t_start)とは異なり、また当該期間内で通信されるデータ量も、スループット計測のための前記総データ量dとは異なる。そこで、本発明ではスループット計測に用いる所要時間TotalTimeおよび総データ量dを、前記期間に応じて補正、見直すことで、所要時間TotalTimeを直接求めることなくスループットを正確に計測できるようにしている。
【００３８】
さらに、本発明では通信データが無線クライアントからサーバへウィンドウサイズ単位で一括送信（バルク送信）される回数を判定し、この一括送信回数が１回であるのか、あるいは２回以上であるのかに応じて測定アルゴリズムを異ならせることで、各セッションにおけるデータ量の多少に関わらずスループットを高精度で測定できるようにしている。
【００３９】
A．セッションが２回以上の一括送信を要する場合、あるいは総データ量が初期ウィンドウサイズを越える場合／
【００４０】
無線クライアント端末MH(Mobile Host)側のスループットは、図７に示したように、３ウェイハンドシェイク(3WHS)によるTCPコネクションの確立後、MHが最初のリクエストパケット(HTTP REQ=POST1)を送信した時刻tsから、最後のリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間T_airとし、この間にアップロードされたデータ量M1，M2…の総和を前記所要時間T_airで除すことで求まる。
【００４１】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００４２】
ネットワーク上にキャプチャポイントを設けた場合、第１番目のリクエストパケット(POST1)の到着時刻t1から最後（ここでは、第３番目）のリクエストパケット(POST3)に対するACKの到着時刻t5までが前記スループット計測の所要時間TotalTimeに相当する。しかしながら、本発明では下りパケットは監視対象外であり、また、第１番目(POST1)のリクエストパケットの到着時刻t1には無線区間の影響が現れない。そこで、上りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替の所要時間Tとして、第１番目のリクエストパケット(POST1)の到着時刻t1から最後（ここでは、第３番目）のリクエストパケットの到着時刻t4までの期間[t4-t1]に着目する。
【００４３】
第２番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT2は、第１番目のリクエストパケット(POST1)の到着時刻t1から第２番目の最後のリクエストパケット(POST2)の到着時刻t3までの経過時間[t3-t1]として求まる。そして、この所要時間ΔT2は、第１番目のリクエストパケット(POST1)の到着時刻t1からそのACKパケットの到着時刻t2までの所要時間[t2-t1]と、前記t2からt3までの所要時間[t3-t2]との和に等しい。
【００４４】
ここで、サーバ側のネットワーク及び接続回線は有線回線であることが多く、帯域幅も大きく、スループットによる遅延は微少であるとみなせることから、前記所要時間[t2-t1]は、サーバエンド側の固定的な遅延時間RTT_srvと略等しく、所要時間[t3-t2]は、第２番目のリクエストパケットのデータ量をM2とすれば、無線エンド側の固定的な遅延時間RTT_airと所定のスループット下でデータ量M2を送信するのに要する遅延時間t(M2)との和に等しい。したがって、前記所要時間ΔT2は次式(1)で表せる。
ΔT2＝RTT_srv＋RTT_air＋t(M2) … (1)
【００４５】
同様に、第３番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT3は、当該第３番目のリクエストパケット(POST3)のデータ量をM3とすれば、次式(2)で表せる。
ΔT3＝RTT_srv＋RTT_air＋t(M3) … (2)
【００４６】
したがって、サーバエンド側および無線側の各固定遅延時間RTT_srv，RTT_airの和をRTT_sumで表現すれば、最後の第３番目の送信までに要する代替所要時間T3（=ΔT2＋ΔT3）は次式(3)で表せる。
T3＝t(M2)＋t(M3)＋2×RTT_sum … (3)
【００４７】
また、第２、３番目のアップロード時のスループットをRとし、各リクエストパケットのデータ量M2，M3の総和をΣMとすれば次式(4)，(5)が得られる。
T3＝ΣM／R＋2×RTT_sum … (4)
R＝ΣM／(T3-2×RTT_sum) … (5)
【００４８】
したがって、n番目(POSTn)のアップロードまでのスループットRateは、当該n番目までにアップロードされたリクエストパケットのデータ量から第１番目のリクエストパケットのデータ量を減じたデータ量をSzとすれば、次式(6a)で求まる。
Rate＝Sz／(Tn-(n-1)×RTT_sum) … (6a)
【００４９】
なお、上式(6a)の右辺分母において、TnからRTT_sumの減じる回数（倍数）はスループットの定義に応じて適宜に変更でき、少なくともRTT_sumの１倍が減ぜられれば良い。例えば、RTT_sumのオーバヘッドをスループットに含ませないのであれば、上式(6a)のように、送信回数分のオーバヘッド[（n-1）×RTT_sum]を全てTnから減じるようにすればよい。これに対して、RTT_sumのオーバヘッドも含めてスループットと定義するのであれば、次式(6b)のように、所要時間ΔTの開始直後の最初の１回分のRTT_sum（図７の時刻t1〜t3に占めるRTT_sum）のみを減じるようにすれば良い。
Rate＝Sz／(Tn-RTT_sum) … (6b)
【００５０】
上式(6b)によれば、本発明のようにネットワーク上にキャプチャポイントを設け、このキャプチャポイントにおいて上りパケットの到着時刻のみを基準にしてスループットを計測しようとする際に、その所要時間の開始時に含まれてしまう無関係なオーバヘッドを排除できるので、より正確なスループット計測が可能になる。
【００５１】
さらに、TCPウィンドウサイズが開き切るまでのRTT_sumのみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでのm回分のRTT_sumのみが排除されるように、次式(6c)を採用しても良い。
Rate＝Sz／(Tn-m×RTT_sum) … (6c)
【００５２】
以上の考察から、本発明では第１番目のリクエストパケット(POST1)の到着時刻t1からn番目のリクエストパケット(POSTn)の到着時刻までを代替所要時間Tnとし、その間にアップロードされた総データ量Sz、代替所要時間Tnならびに無線エンド側およびサーバエンド側の各固定遅延時間RTT_air，RTT_srvをログ情報等から算出し、これらをスループットの定義に応じて上式(6a)，(6b)，(6c)のいずれか[以下、単に式(6)で代表する場合もある]に代入することでスループットRateを算出する。
【００５３】
なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバがリクエストパケットを受けきるまでとするならば、キャプチャポイントからサーバまでの区間に相当する片道分のサーバエンド側固定遅延時間RTT_srv/2を上式(6)の分母に加算すれば良い。
【００５４】
B．セッションが１回の一括送信のみで完了する場合、あるいはデータ量が初期ウィンドウサイズ以下の場合／
【００５５】
無線クライアント端末MH側のスループットは、図８に示したように、３ウェイハンドシェイク(3WHS)によるTCPコネクションの確立後、MHがリクエストパケット(HTTP REQ=POST1)を送信した時刻tsから、このリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間T_airとし、この間にアップロードされたデータ量M1を前記所要時間T_airで除すことで求まる。
【００５６】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００５７】
ネットワーク上にキャプチャポイントを設けると、セッションが１回の送信のみで完了する場合、TCPコネクション確立後の当該コネクション内でキャプチャできるリクエストパケットが第１番目のリクエストパケット(POST1)に限られてしまうので、アップロードの所要時間を算出することができない。
【００５８】
そこで、本発明では第１番目のアップロードが無線区間の影響を受けることで変化し、リクエストパケットの到着時刻差のみで計測できる代替所要時間Tとして、３ウェイハンドシェイクにおいてMHからサーバへ送信されるSYNパケットの到着時刻t1から第１番目のリクエストパケットの到着時刻t2までに注目し、この代替所要時間T[=t2-t1]にアップロードされる総データ量に基づいてスループットを計測する。ただし、本実施形態では３ウェイハンドシェイクによるTCPの確立直後から最初のデータ通信(POST1)が開始されることが前提となる。
【００５９】
前記TCPの確立直後からの開始であるか否かは、TCPの確立から最初のデータ通信(POST1)が開始されるまでの時間（本実施形態では、3WHSにおいてMHから送信されるACKのキャプチャ時刻から、最初のデータ(POST1)のキャプチャ時刻までの時間）が、1/2・RTT_AIR以内であるか否か、あるいは例えば0.1sec以内であるか否かに基づいて判断できる。これは、TCPが確立されてから1/2・RTT_AIRあるいは例えば0.1secを超えると、平均的な無線回線側の片側オーバヘッド遅延を超えることになり、連続した通信ではないと解せるからである。換言すれば、1/2・RTT_AIR以内あるいは例えば0.1sec以内であれば、オーバヘッド未満の通信であって連続通信であると解せる。
【００６０】
ただし、上記の代替所要時間Tは、無線側のスループットに影響されないサーバエンド側および無線エンド側の各固定遅延時間RTT_srv，RTT_air、ならびにHTTP_REQが無線区間をMHからキャプチャポイントまでの片道だけ経由する際の遅延時間RTT_air／2を余計に含むので、スループット計測に用いる所要時間TotalTimeは次式(7)で求める。
TotalTime＝T−RTT_SUM−RTT_air／2 … (7)
【００６１】
また、この所要時間T内にアップロードされるリクエストパケットの総データ量ΣMは、HTTP_REQのパケットサイズM1とACKのデータサイズMa(＝略４０byte)との和なので次式(8)で求まる。なお、３ウェイハンドシェイクの最初にMHから送信されるSYNについては、無線区間の影響が代替所要時間Tに表れないので考慮する必要はない。
ΣM＝M1＋Ma … (8)
【００６２】
したがって、アップロード時のスループットRateは次式(9)で求まる。
Rate＝M／T … (9)
【００６３】
本発明では、代替所要時間T[=t2-t1]、RTT_SUM、RTT_air／2およびパケットサイズM1を通信ログ等に基づいて算出し、これらを上式(7)-(9)に代入することでスループットRateを算出する。
【００６４】
なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバが通信データを受けきるまでとするならば、片道分のサーバエンド側固定遅延時間RTT_srv/2を上式(9)の分母に加算すれば良い。
【００６５】
次いで、本発明の実施形態について具体的に説明する。図１は、本発明の通信品質測定方法が適用されるネットワークの構成を示したブロック図である。
【００６６】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線移動端末MH）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００６７】
前記インターネットには、MHからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MHと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置１が接続されている。
【００６８】
図２は、前記キャプチャ装置１の第１実施形態の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００６９】
パケットキャプチャ部１０１は、前記回線L上でTCPパケットを選択的にキャプチャする。本実施形態では、キャプチャ対象のパケットが、MHとサーバとの間にTCPコネクションを確立するための3ウェイハンドシェイクで送受される制御パケット、およびTCPコネクションの確立後は、監視対象のコネクションまたはセッション内で送受される上りパケットのみに限定される。
【００７０】
ログ情報管理部１０２には、前記キャプチャされたパケットの、少なくとも種別および到着時刻がログ情報としてコネクションまたはセッション毎に記録、管理される。エンド側固定遅延算出部１０３は、前記ログ情報を参照し、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて、データ量に依存しない各エンド側（無線側およびサーバ側）の固定的な遅延時間を算出する。
【００７１】
一括送信回数判定部１０４は、監視対象のコネクション（セッション）について、前記ログ情報を参照することで、そのデータ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、MHからサーバへ送信された総データ量をデータ通信開始時におけるMH側の初期ウィンドウサイズと比較することで、監視対象のセッションが、その完了までにデータをウィンドウサイズ単位で一括送信する回数が、１回または２回以上のいずれであるのかを判定する。
【００７２】
通信品質算出部１０５は、前記一括送信回数が「１回」のセッション（以下、1RTTセッションと表現する場合もある）を対象に通信品質を測定する第１測定部１０５ａ、および一括送信回数が「２回以上」のセッション（以下、2RTT以上セッションと表現する場合もある）を対象に通信品質を測定する第２測定部１０５ｂを備え、前記一括送信回数判定部１０４による判定結果に応じて、無線区間の影響を受けて変化する所定時間と当該所定時間内に通信されたデータ量とに基づいて無線区間の通信品質を算出する。
【００７３】
前記第１および第２測定部１０５ａ，１０５ｂはいずれも、上りのTCPパケットの到着時刻差のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tを前記各エンド側の固定遅延時間で補正することで、スループットの計測期間となる所定時間を算出し、この所定時間と当該所定時間内に通信されたデータ量とに基づいて無線クライアント側のスループットを算出する。
【００７４】
図３は、前記エンド側固定遅延算出部１０３、一括送信回数判定部１０４および通信品質算出部１０５が協働し、前記ログ情報を参照して通信品質を算出する手順を示したフローチャートであり、例えば監視対象のコネクションが完了することに実行される。
【００７５】
ステップＳ１では、今回の測定対象コネクションのログ情報が識別される。ステップＳ２では、前記一括送信回数判定部１０４において、当該測定対象が1RTTセッションおよび2RTT以上セッションのいずれであるかが判定される。
【００７６】
1RTTセッションと判定されればステップＳ３へ進み、前記第１測定部１０５ａによりスループットが算出される。これに対して、2RTT以上セッションと判定されればステップＳ４へ進み、前記第２測定部１０５ｂによりスループットが算出される。
【００７７】
図４は、2RTT以上セッションのシーケンスフローであり、時刻t1〜t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、前記SYNパケットを受信したサーバからMHへSYN+ACKが返信される。時刻t3では、前記SYN+ACKパケットを受信したMHからサーバへACKパケットが返信される。本実施形態では、前記SYN、SYN+ACKおよびACKの各パケットがキャプチャされ、その到着時刻ta，tb，tcが通信ログとして記録される。
【００７８】
TCPコネクションが確立されると、時刻t4では、MHからサーバへ最初のHTTP REQパケット(POST1)が送信されてHTTPセッションが開始される。時刻t5では、前記HTTP REQパケットの受信に応答して、サーバからMHへACKが返信される。このACKには、サーバ側で受信可能な最大受信ウィンドウサイズが記述されている。
【００７９】
時刻t6，t7では、前記ACKの受信に応答して、MHからサーバへ２番目のHTTP REQパケット(POST2)が送信される。このとき、MHはサーバから通知された最大受信ウィンドウサイズとMH自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが「２」に決定され、２つのHTTP REQパケットが一括送信されるものとして説明を続ける。時刻t8，t9では、前記HTTP REQパケットの受信に応答して、サーバからMHへACKが返信される。
【００８０】
本実施形態では、このような2RTT以上セッションについては上式(6)が適用され、右辺分母の代替所要時間Tn(T2)は、第１番目のHTTP REQパケット（群）の到着時刻tdからn番目（最後）のHTTP REQパケット（群）の到着時刻teまでの経過時間[te-td]として、前記通信ログを参照することで算出される。
【００８１】
なお、上記のようにHTTP REQパケットのアップロードにおいてウィンドウサイズ単位での一括送信が繰り返される場合、第１番目のHTTP REQパケット（群）のログ情報と第２番目以降の各HTTP REQパケット群のログ情報との識別が難しくなる。そこで、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を、以下のような手法で推定するようにしている。
【００８２】
第１の手法として、MHがパケットを送信する際のウィンドウサイズの遷移から推定する方法がある。第２の方法として、MHが送信するパケットの連続送信状態から推定する方法がある。
【００８３】
第１の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば１，２，４，８…６４と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケット群の切れ目が推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値（例えば、1sec）以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ＝１から開始されたと推定できるので、第１番目のHTTP REQパケットを容易に推定できる。
【００８４】
また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが１，２，４，８，１６と規則的に増加して終了していれば、今回のセッションはウィンドウサイズ「３２」から始まるものと推定できる。
【００８５】
なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。
【００８６】
第２の手法では、パケット送信が無い状態、すなわちパケット送信・到着間隔が、例えば１RTT_airや0.5RTT_airなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と推定する。
【００８７】
このように、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を簡単に推定できるので、第１番目のHTTP REQパケット（群）の到着時刻tdからn番目（最後）のHTTP REQパケット（群）の到着時刻teまでの経過時間[te-td]を求められるようになる。
【００８８】
上式(6)に戻り、右辺分母のRTT_sumは、無線エンド側およびサーバエンド側の各固定遅延時間RTT_air，RTT_srvの和なので、前記3ウェイハンドシェイクで送受された各制御パケットの到着時刻差から、これらも記通信ログを参照することで算出される。
【００８９】
一方、右辺分子のSz（n番目までにアップロードされた総データ量から第１番目のアップロードに対応する１パケット分のデータ量を減じた値：ここでは、第２番目のHTTP REQパケットのデータ量に相当）についても、上記のように各HTTP REQパケット群の切れ目を推定できれば、第１番目のHTTP REQパケット（群）のデータ量を簡単に求められるので、これを総データ量から減じるか、あるいは第２番目以降の全てのHTTP REQパケットのデータ量の総和として求められる。
【００９０】
なお、以上ではMHから送信されたパケットがキャプチャポイントに到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをサーバがHTTP REQパケットを受けきるまでとするならば、最後の通信データがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が不足する。したがって、例えば上式(6)の代わりに次式(10)を用いる。
Rate＝Sz／(Tn-(n-1)×RTT_sum+RTT_srv/2) … (10)
【００９１】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてSz、TnおよびRTT_sum、さらには必要に応じてRTT_srvを算出すると共に、これらを上式(6)または(10)に適用することで無線区間のスループットRate[bps]を算出する。
【００９２】
次いで、１RTTセッションのスループット計測について説明する。図５は、１RTTセッションのシーケンスフローである。
【００９３】
時刻t1〜t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、SYNパケットを受信したサーバからMHへSYN+ACKパケットが返信される。時刻t3では、前記SYN+ACKパケットを受信したMHからサーバへACKが返信される。
【００９４】
TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTP REQパケットが送信される。時刻t5では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t6では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【００９５】
このようなシーケンスにおいて、本実施形態でも3ウェイハンドシェイクで送受されるSYNパケット、SYN+ACKパケットおよびACKパケットがキャプチャされ、それぞれの到着時刻t1，t2，t3が通信ログとして記録される。また、TCPコネクション確立後のコネクションまたはセッション内では、MHから送信されるHTTP REQパケットの到着時刻teのみがキャプチャされる。
【００９６】
本実施形態では、このような1RTTセッションについては上式(9)が適用され、右辺分母の代替所用時間Tが[te-ta]として算出され、サーバエンド側および無線エンド側の各固定遅延時間RTT_srv，RTT_air、ならびにRTT_air／2が前記と同様に通信ログに基づいて算出され、これらを上式(7)に代入することでTotalTimeが差出される。
【００９７】
データ量Mについては、HTTP_REQのパケットサイズM1が前記通信ログに基づいて算出され、これとACKのパケットサイズMa(略40 byte)とを上式(8)に代入して求める。そして、これらを上式(9)に適用することでスループットRateが算出される。
【００９８】
本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内では上りパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。
【００９９】
また、HTTPセッションでは、スループット計測をセッション単位でも行えるので、例えばHTTP・WEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThink Timeが生じても、このThink Timeが除外された正確なスループット計測が可能になる。
【０１００】
次いで、本発明の第２実施形態について説明する。図６は、前記キャプチャ装置１の第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【０１０１】
ログ情報補完部１０６は、監視対象のコネクションに関して、前記パケットキャプチャ部１０１がキャプチャし損ねたパケットおよびそのデータ量を、その前後にキャプチャされたパケットのデータ量から予測されるMH側のウィンドウサイズWSの遷移状態から予測して前記ログ情報管理部１０２に補完する。
【０１０２】
すなわち、TCPではウィンドウサイズがコネクションの確立直後から離散的かつ規則的に所定の上限値まで増加し、例えば３番目の通信では、４パケット分のデータが送信されることになる。したがって、例えば前回の通信では２パケット分のログ情報が記録され、次回の通信では８パケット分のログ情報が記録されているにも関わらず、今回の通信で３パケット分のログ情報しか記録されていなければ、ここで１パケット分のキャプチャ漏れが生じたと判断して、当該１パケット分のログ情報を追加する。なお、キャプチャし損ねたパケットは、キャプチャできた各パケットに記述されているシーケンス番号の連続性に基づいても把握できる。
【０１０３】
本実施形態によれば、パケットキャプチャ部１０１においてパケットのキャプチャ漏れが生じても、ウィンドウサイズWSやシーケンス番号の遷移履歴に基づいて、キャプチャ漏れしたパケットのログ情報を補完できるので、総データ量をより正確に算出できるようになり、その結果、スループットの測定精度が向上する。
【０１０４】
なお、上記の実施形態では、概略所要時間を補正するための各エンド側固定遅延時間が、TCPコネクション確立時の3ウェイハンドシェイクで送受される制御パケットの到着時刻差に基づいて算出されるものとして説明したが、本発明はこれのみに限定されるものではなく、同一エリアまたは同一基地局において同一時間帯に他の同一種別の端末で別途に計測された遅延時間の算術平均や移動平均などを用いてもよい。
【０１０５】
また、上記の各実施形態では、スループットの計測対象がHTTPセッションである場合を説明したが、本発明はこれのみに限定されるものではなく、メールセッションのスループット計測にも同様に適用できる。
【０１０６】
ただし、メールセッションではTCPコネクションの確立後にユーザ認証処理やCIMAP処理などが実行され、これらのオーバヘッド処理によりデータ転送とは無関係な遅延が発生する。このため、メールセッションに対して前記HTTPセッションの場合と同様にスループット計測を行うと、本来よりも小さな計測結果しか得られない。
【０１０７】
したがって、本発明をメールセッションに適用する場合には、セッションサイズの小さいメールセッション（例えば、1KB以下）は計測対象外として当該メールセッションのセッション時間をオーバヘッド時間（複数であれば、その平均時間）として記憶し、セッションサイズの大きいメールセッション（例えば、50KB以上）のみを計測対象とすると共に、そのセッション時間から前記オーバヘッド時間を減じて所要時間を求めることが望ましい。
【符号の説明】
【０１０８】
１０１…パケットキャプチャ部，１０２…ログ情報管理部，１０３…エンド側固定遅延算出部，１０４…一括送信回数判定部，１０４ａ…ウィンドウサイズ検知部，１０５…通信品質算出部，１０５ａ…第１測定部，１０５ｂ…第２測定部，１０６…ログ情報補完部
【技術分野】
【０００１】
本発明は、通信品質測定方法および装置に係り、特に、無線区間の通信品質をパッシブに測定する通信品質測定方法および装置に関する。
【背景技術】
【０００２】
無線通信システムの通信事業者には、広域なサービスエリアの全域で通信品質情報を局所領域ごとに取得してエリアマップを作成し、サービスエリア全体の通信品質状態を漏れなく評価することが要求される。
【０００３】
特許文献１には、パケット通信網を介して接続された２つの品質測定装置間で、一方の品質測定装置から他方の品質測定装置に向けて測定パケットを送信し、他方の品質測定装置は一方の品質測定装置からの送信された測定パケットの受信に応答して測定パケットを返送し、一方の品質測定装置は他方の品質測定装置から返送された測定パケットの受信状況に基づき品質測定装置間のTCPスループット、再送発生率、平均パケット往復遅延、タイムアウト再送等が発生する確率を推定する技術が開示されている。
【０００４】
特許文献２には、複数の端末やTCPコネクションが１つのボトルネックリンクを共有し、それらTCPコネクションによりデータが転送される場合に、ボトルネックリンクの伝送帯域に基づいてTCPコネクションの平均スループットを精度よく算出するTCPスループット算出方法が開示されている。
【０００５】
上記の先行技術はいずれも、送信側端末および受信側端末を協働させ、各端末での計測結果に基づいて通信品質が推定されるので、要求対象の装置数が大量になるとスケーラビリティの問題がある。
【０００６】
このような技術課題に対して、本発明の発明者等は、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいてクライアントの通信品質を分析する通信品質測定方法および装置を発明し、特許出願（特許文献３）した。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【特許文献２】特開２００３−２０９５７４号公報
【特許文献３】特願２０１１−５３３７９号
【発明の概要】
【発明が解決しようとする課題】
【０００８】
相互に通信するノードペアの一方が無線端末である場合、その無線区間の通信品質としてスループットを測定するのであれば、経路上のキャプチャポイントにおいて、データ通信の開始を要求する要求パケットの到着時刻t_startと、データ通信の完了を通知する完了パケットの到着時刻t_endと、その間に送受された総データ量ｄとを測定し、総データ量dをデータ通信の所要期間TotalTime(=t_end−t_start)で除せば良い。なお、無線区間を含むネットワークでのデータ通信の場合、一般的に無線区間がボトルネックとなることから、無線区間側のスループットを算出することにより、ユーザあるいは端末が享受・体感しているスループットを算出することができる。
【０００９】
しかしながら、このようなパッシブ測定ではキャプチャポイントを通過するパケット量が膨大であるため、双方向の全てのパケットを漏れなくキャプチャし、かつ全ての要求パケットと応答パケットとを対応付けることは、処理規模が膨大となり、リアルタイムまたは准リアルタイムに計算するのが困難であった。
【００１０】
さらに、リクエストパケットに対する応答として返信されるACKパケットは、TCPの性質上、一つのデータパケットの受信毎に返信されるとは限らない。このため、パケット転送の終了タイミングをACKパケットの到着時刻で代表させてしまうと、所要期間が大きな誤差を含むことになり、スループットを正確に測定できなくなる。
【００１１】
本発明の目的は、上記した従来技術の課題を全て解決し、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいて無線クライアント側の通信品質を正確に分析できる通信品質測定方法および装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明は、無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、以下のような手段を講じた点に特徴がある。
【００１３】
(1) 無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、ログ情報に基づいて、キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを設けた。通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出するようにした。
【００１４】
(2) エンド側固定遅延が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて算出されるようにした。
【００１５】
(3) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定し、この一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択するようにした。
【００１６】
(4) 通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を設け、一括送信回数を、通信のデータ量が通信開始時のウィンドウサイズ以下であれば１回と判定し、ウィンドウサイズよりも大きければ２回以上と判定するようにした。
【００１７】
(5) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が２回以上と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを代替所要時間として算出し、２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、前記代替所要時間から、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じて所要時間を算出し、前記総データ量を前記所要時間で除してスループットを算出するようにした。
【００１８】
なお、無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を減じる回数はスループットの定義に応じて変更しても良い。例えば、このような固定遅延（オーバヘッド）をスループットに含ませないのであれば、各固定遅延時間の和の(n-1)倍を減じれば良い。また、TCPウィンドウサイズが開き切るまでの固定遅延のみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでの通信回数の倍数だけ減じればよい。
【００１９】
さらに、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じ、片道分のサーバエンド側固定遅延時間を加えることで算出する。
【００２０】
(6) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が１回と判定されると、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、前記総データ量を前記代替所要時間で除してスループットを算出するようにした。ただし、このようなスループット算出方式は、TCPの確立直後（例えば、0.1sec以内）からデータ通信が開始されることが前提となる。
【００２１】
なお、所要時間として、無線クライアントがデータを送信しきるまでではなく、サーバが受信するまでとするのであれば、前記所要時間は、代替所要時間から無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えることで算出する。
【００２２】
(7) キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段をさらに設けた。
【００２３】
(8) 測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とするようにした。
【００２４】
(9) スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されるようにした。
【００２５】
(10) 一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定するようにした。
【発明の効果】
【００２６】
本発明によれば、以下のような効果が達成される。
【００２７】
(1) TCPコネクションのスループットを、ネットワーク上に設けたキャプチャポイントにおいて一方向のパケット（無線クライアントからサーバへ送信される上りパケット）のみをパッシブに監視するだけで計測できるようになる。したがって、一コネクション当たりの監視パケット数を少なくでき、その結果、多数のコネクションを同時に監視できるようになるので、スケーラブルなスループット測定が可能になる。
【００２８】
(2) 無線側およびサーバ側の各エンド側固定遅延時間が、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて求められるので、各エンド側の固定遅延時間を計測する為の機能を別途に用意する必要がない。
【００２９】
(3) データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、一括送信回数が１回の場合と２回以上の場合とで、スループットの測定アルゴリズムを異ならせるので、通信の総データ量にかかわらず常に正確なスループット計測が可能になる。また、一括送信回数が１回であるか２回以上であるかを、通信開始時のウィンドウサイズをデータサイズと比較するだけで判定できるようになる。
【００３０】
(4) キャプチャ漏れしたパケットのログ情報を、ウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を設けたので、通信の総データ量を、より正確に算出できるようになる。
【００３１】
(5) メールセッションでは、セッションサイズの小さいメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズの大きいメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じてメールセッションの所要時間とするので、メールセッションについても正確なスループット計測が可能になる。
【００３２】
(6) HTTPセッションでは、スループット計測がセッション単位で行われるので、例えばHTTP・WEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThink Timeが生じても、このThink Timeが除外された正確なスループット計測が可能になる。
【００３３】
(7) TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得することにより、クライアント端末やTCPの違いにかかわらず通信開始時のウィンドウサイズを正確に判別できるようになる。その結果、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を正確に判定できるようになる。
【図面の簡単な説明】
【００３４】
【図１】本発明が適用されるネットワークの構成を示したブロック図である。
【図２】キャプチャ装置の第１実施形態の機能ブロック図である。
【図３】本発明の動作を示したフローチャートである。
【図４】本発明の動作を示したシーケンスフロー（その１）である。
【図５】本発明の動作を示したシーケンスフロー（その２）である。
【図６】キャプチャ装置の第１実施形態の機能ブロック図である。
【図７】本発明の概要を説明するための図（その１）である。
【図８】本発明の概要を説明するための図（その２）である。
【発明を実施するための形態】
【００３５】
以下、図面を参照して本発明の実施形態について詳細に説明する。ここでは初めに、本発明の概要について説明し、次いで、その具体的な実施形態について説明する。なお、以下の説明では基本的に、トランスポート層（第４層）での接続を「コネクション」と表現し、これよりも上位層での接続を「(HTTP)セッション」と表現することで両者を区別しているが、両者を「コネクション」で代表する場合もある。
【００３６】
本発明は、無線区間を含むTCPコネクションのスループットをコネクション単位(HTTPおよびメールでは、セッション単位)で測定するものとし、ネットワーク上のキャプチャポイントで監視するキャプチャ対象のパケットを、TCPコネクションの確立時に送受される制御パケット、ならびにTCPコネクション確立後は当該コネクションまたはそのセッション内で観測される上りパケットのみに限定することで、一コネクション当たりのキャプチャ対象のパケット数を減じ、多数のコネクションを監視対象とできるようにすることで、パッシブ測定に必須のスケーラビリティを担保しながら、精度の高いスループット測定を可能にしている。
【００３７】
ただし、このようにして計測される期間（上りパケットの到着時刻差）は、スループット計測のための前記所要時間TotalTime(=t_end−t_start)とは異なり、また当該期間内で通信されるデータ量も、スループット計測のための前記総データ量dとは異なる。そこで、本発明ではスループット計測に用いる所要時間TotalTimeおよび総データ量dを、前記期間に応じて補正、見直すことで、所要時間TotalTimeを直接求めることなくスループットを正確に計測できるようにしている。
【００３８】
さらに、本発明では通信データが無線クライアントからサーバへウィンドウサイズ単位で一括送信（バルク送信）される回数を判定し、この一括送信回数が１回であるのか、あるいは２回以上であるのかに応じて測定アルゴリズムを異ならせることで、各セッションにおけるデータ量の多少に関わらずスループットを高精度で測定できるようにしている。
【００３９】
A．セッションが２回以上の一括送信を要する場合、あるいは総データ量が初期ウィンドウサイズを越える場合／
【００４０】
無線クライアント端末MH(Mobile Host)側のスループットは、図７に示したように、３ウェイハンドシェイク(3WHS)によるTCPコネクションの確立後、MHが最初のリクエストパケット(HTTP REQ=POST1)を送信した時刻tsから、最後のリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間T_airとし、この間にアップロードされたデータ量M1，M2…の総和を前記所要時間T_airで除すことで求まる。
【００４１】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００４２】
ネットワーク上にキャプチャポイントを設けた場合、第１番目のリクエストパケット(POST1)の到着時刻t1から最後（ここでは、第３番目）のリクエストパケット(POST3)に対するACKの到着時刻t5までが前記スループット計測の所要時間TotalTimeに相当する。しかしながら、本発明では下りパケットは監視対象外であり、また、第１番目(POST1)のリクエストパケットの到着時刻t1には無線区間の影響が現れない。そこで、上りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替の所要時間Tとして、第１番目のリクエストパケット(POST1)の到着時刻t1から最後（ここでは、第３番目）のリクエストパケットの到着時刻t4までの期間[t4-t1]に着目する。
【００４３】
第２番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT2は、第１番目のリクエストパケット(POST1)の到着時刻t1から第２番目の最後のリクエストパケット(POST2)の到着時刻t3までの経過時間[t3-t1]として求まる。そして、この所要時間ΔT2は、第１番目のリクエストパケット(POST1)の到着時刻t1からそのACKパケットの到着時刻t2までの所要時間[t2-t1]と、前記t2からt3までの所要時間[t3-t2]との和に等しい。
【００４４】
ここで、サーバ側のネットワーク及び接続回線は有線回線であることが多く、帯域幅も大きく、スループットによる遅延は微少であるとみなせることから、前記所要時間[t2-t1]は、サーバエンド側の固定的な遅延時間RTT_srvと略等しく、所要時間[t3-t2]は、第２番目のリクエストパケットのデータ量をM2とすれば、無線エンド側の固定的な遅延時間RTT_airと所定のスループット下でデータ量M2を送信するのに要する遅延時間t(M2)との和に等しい。したがって、前記所要時間ΔT2は次式(1)で表せる。
ΔT2＝RTT_srv＋RTT_air＋t(M2) … (1)
【００４５】
同様に、第３番目のアップロードが無線区間の影響を受けることで変化する所要時間ΔT3は、当該第３番目のリクエストパケット(POST3)のデータ量をM3とすれば、次式(2)で表せる。
ΔT3＝RTT_srv＋RTT_air＋t(M3) … (2)
【００４６】
したがって、サーバエンド側および無線側の各固定遅延時間RTT_srv，RTT_airの和をRTT_sumで表現すれば、最後の第３番目の送信までに要する代替所要時間T3（=ΔT2＋ΔT3）は次式(3)で表せる。
T3＝t(M2)＋t(M3)＋2×RTT_sum … (3)
【００４７】
また、第２、３番目のアップロード時のスループットをRとし、各リクエストパケットのデータ量M2，M3の総和をΣMとすれば次式(4)，(5)が得られる。
T3＝ΣM／R＋2×RTT_sum … (4)
R＝ΣM／(T3-2×RTT_sum) … (5)
【００４８】
したがって、n番目(POSTn)のアップロードまでのスループットRateは、当該n番目までにアップロードされたリクエストパケットのデータ量から第１番目のリクエストパケットのデータ量を減じたデータ量をSzとすれば、次式(6a)で求まる。
Rate＝Sz／(Tn-(n-1)×RTT_sum) … (6a)
【００４９】
なお、上式(6a)の右辺分母において、TnからRTT_sumの減じる回数（倍数）はスループットの定義に応じて適宜に変更でき、少なくともRTT_sumの１倍が減ぜられれば良い。例えば、RTT_sumのオーバヘッドをスループットに含ませないのであれば、上式(6a)のように、送信回数分のオーバヘッド[（n-1）×RTT_sum]を全てTnから減じるようにすればよい。これに対して、RTT_sumのオーバヘッドも含めてスループットと定義するのであれば、次式(6b)のように、所要時間ΔTの開始直後の最初の１回分のRTT_sum（図７の時刻t1〜t3に占めるRTT_sum）のみを減じるようにすれば良い。
Rate＝Sz／(Tn-RTT_sum) … (6b)
【００５０】
上式(6b)によれば、本発明のようにネットワーク上にキャプチャポイントを設け、このキャプチャポイントにおいて上りパケットの到着時刻のみを基準にしてスループットを計測しようとする際に、その所要時間の開始時に含まれてしまう無関係なオーバヘッドを排除できるので、より正確なスループット計測が可能になる。
【００５１】
さらに、TCPウィンドウサイズが開き切るまでのRTT_sumのみを余計なオーバヘッドとみなすのでれば、TCPウィンドウサイズが開ききるまでのm回分のRTT_sumのみが排除されるように、次式(6c)を採用しても良い。
Rate＝Sz／(Tn-m×RTT_sum) … (6c)
【００５２】
以上の考察から、本発明では第１番目のリクエストパケット(POST1)の到着時刻t1からn番目のリクエストパケット(POSTn)の到着時刻までを代替所要時間Tnとし、その間にアップロードされた総データ量Sz、代替所要時間Tnならびに無線エンド側およびサーバエンド側の各固定遅延時間RTT_air，RTT_srvをログ情報等から算出し、これらをスループットの定義に応じて上式(6a)，(6b)，(6c)のいずれか[以下、単に式(6)で代表する場合もある]に代入することでスループットRateを算出する。
【００５３】
なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバがリクエストパケットを受けきるまでとするならば、キャプチャポイントからサーバまでの区間に相当する片道分のサーバエンド側固定遅延時間RTT_srv/2を上式(6)の分母に加算すれば良い。
【００５４】
B．セッションが１回の一括送信のみで完了する場合、あるいはデータ量が初期ウィンドウサイズ以下の場合／
【００５５】
無線クライアント端末MH側のスループットは、図８に示したように、３ウェイハンドシェイク(3WHS)によるTCPコネクションの確立後、MHがリクエストパケット(HTTP REQ=POST1)を送信した時刻tsから、このリクエストパケットに対してサーバから返信されたACKパケットがMHへ到着した時刻teまでを所要時間T_airとし、この間にアップロードされたデータ量M1を前記所要時間T_airで除すことで求まる。
【００５６】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では上りパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではMHからサーバへアップロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００５７】
ネットワーク上にキャプチャポイントを設けると、セッションが１回の送信のみで完了する場合、TCPコネクション確立後の当該コネクション内でキャプチャできるリクエストパケットが第１番目のリクエストパケット(POST1)に限られてしまうので、アップロードの所要時間を算出することができない。
【００５８】
そこで、本発明では第１番目のアップロードが無線区間の影響を受けることで変化し、リクエストパケットの到着時刻差のみで計測できる代替所要時間Tとして、３ウェイハンドシェイクにおいてMHからサーバへ送信されるSYNパケットの到着時刻t1から第１番目のリクエストパケットの到着時刻t2までに注目し、この代替所要時間T[=t2-t1]にアップロードされる総データ量に基づいてスループットを計測する。ただし、本実施形態では３ウェイハンドシェイクによるTCPの確立直後から最初のデータ通信(POST1)が開始されることが前提となる。
【００５９】
前記TCPの確立直後からの開始であるか否かは、TCPの確立から最初のデータ通信(POST1)が開始されるまでの時間（本実施形態では、3WHSにおいてMHから送信されるACKのキャプチャ時刻から、最初のデータ(POST1)のキャプチャ時刻までの時間）が、1/2・RTT_AIR以内であるか否か、あるいは例えば0.1sec以内であるか否かに基づいて判断できる。これは、TCPが確立されてから1/2・RTT_AIRあるいは例えば0.1secを超えると、平均的な無線回線側の片側オーバヘッド遅延を超えることになり、連続した通信ではないと解せるからである。換言すれば、1/2・RTT_AIR以内あるいは例えば0.1sec以内であれば、オーバヘッド未満の通信であって連続通信であると解せる。
【００６０】
ただし、上記の代替所要時間Tは、無線側のスループットに影響されないサーバエンド側および無線エンド側の各固定遅延時間RTT_srv，RTT_air、ならびにHTTP_REQが無線区間をMHからキャプチャポイントまでの片道だけ経由する際の遅延時間RTT_air／2を余計に含むので、スループット計測に用いる所要時間TotalTimeは次式(7)で求める。
TotalTime＝T−RTT_SUM−RTT_air／2 … (7)
【００６１】
また、この所要時間T内にアップロードされるリクエストパケットの総データ量ΣMは、HTTP_REQのパケットサイズM1とACKのデータサイズMa(＝略４０byte)との和なので次式(8)で求まる。なお、３ウェイハンドシェイクの最初にMHから送信されるSYNについては、無線区間の影響が代替所要時間Tに表れないので考慮する必要はない。
ΣM＝M1＋Ma … (8)
【００６２】
したがって、アップロード時のスループットRateは次式(9)で求まる。
Rate＝M／T … (9)
【００６３】
本発明では、代替所要時間T[=t2-t1]、RTT_SUM、RTT_air／2およびパケットサイズM1を通信ログ等に基づいて算出し、これらを上式(7)-(9)に代入することでスループットRateを算出する。
【００６４】
なお、以上ではMHから送信されたリクエストパケットがキャプチャポイントへ到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをサーバが通信データを受けきるまでとするならば、片道分のサーバエンド側固定遅延時間RTT_srv/2を上式(9)の分母に加算すれば良い。
【００６５】
次いで、本発明の実施形態について具体的に説明する。図１は、本発明の通信品質測定方法が適用されるネットワークの構成を示したブロック図である。
【００６６】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線移動端末MH）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００６７】
前記インターネットには、MHからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MHと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置１が接続されている。
【００６８】
図２は、前記キャプチャ装置１の第１実施形態の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００６９】
パケットキャプチャ部１０１は、前記回線L上でTCPパケットを選択的にキャプチャする。本実施形態では、キャプチャ対象のパケットが、MHとサーバとの間にTCPコネクションを確立するための3ウェイハンドシェイクで送受される制御パケット、およびTCPコネクションの確立後は、監視対象のコネクションまたはセッション内で送受される上りパケットのみに限定される。
【００７０】
ログ情報管理部１０２には、前記キャプチャされたパケットの、少なくとも種別および到着時刻がログ情報としてコネクションまたはセッション毎に記録、管理される。エンド側固定遅延算出部１０３は、前記ログ情報を参照し、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて、データ量に依存しない各エンド側（無線側およびサーバ側）の固定的な遅延時間を算出する。
【００７１】
一括送信回数判定部１０４は、監視対象のコネクション（セッション）について、前記ログ情報を参照することで、そのデータ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、MHからサーバへ送信された総データ量をデータ通信開始時におけるMH側の初期ウィンドウサイズと比較することで、監視対象のセッションが、その完了までにデータをウィンドウサイズ単位で一括送信する回数が、１回または２回以上のいずれであるのかを判定する。
【００７２】
通信品質算出部１０５は、前記一括送信回数が「１回」のセッション（以下、1RTTセッションと表現する場合もある）を対象に通信品質を測定する第１測定部１０５ａ、および一括送信回数が「２回以上」のセッション（以下、2RTT以上セッションと表現する場合もある）を対象に通信品質を測定する第２測定部１０５ｂを備え、前記一括送信回数判定部１０４による判定結果に応じて、無線区間の影響を受けて変化する所定時間と当該所定時間内に通信されたデータ量とに基づいて無線区間の通信品質を算出する。
【００７３】
前記第１および第２測定部１０５ａ，１０５ｂはいずれも、上りのTCPパケットの到着時刻差のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tを前記各エンド側の固定遅延時間で補正することで、スループットの計測期間となる所定時間を算出し、この所定時間と当該所定時間内に通信されたデータ量とに基づいて無線クライアント側のスループットを算出する。
【００７４】
図３は、前記エンド側固定遅延算出部１０３、一括送信回数判定部１０４および通信品質算出部１０５が協働し、前記ログ情報を参照して通信品質を算出する手順を示したフローチャートであり、例えば監視対象のコネクションが完了することに実行される。
【００７５】
ステップＳ１では、今回の測定対象コネクションのログ情報が識別される。ステップＳ２では、前記一括送信回数判定部１０４において、当該測定対象が1RTTセッションおよび2RTT以上セッションのいずれであるかが判定される。
【００７６】
1RTTセッションと判定されればステップＳ３へ進み、前記第１測定部１０５ａによりスループットが算出される。これに対して、2RTT以上セッションと判定されればステップＳ４へ進み、前記第２測定部１０５ｂによりスループットが算出される。
【００７７】
図４は、2RTT以上セッションのシーケンスフローであり、時刻t1〜t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、前記SYNパケットを受信したサーバからMHへSYN+ACKが返信される。時刻t3では、前記SYN+ACKパケットを受信したMHからサーバへACKパケットが返信される。本実施形態では、前記SYN、SYN+ACKおよびACKの各パケットがキャプチャされ、その到着時刻ta，tb，tcが通信ログとして記録される。
【００７８】
TCPコネクションが確立されると、時刻t4では、MHからサーバへ最初のHTTP REQパケット(POST1)が送信されてHTTPセッションが開始される。時刻t5では、前記HTTP REQパケットの受信に応答して、サーバからMHへACKが返信される。このACKには、サーバ側で受信可能な最大受信ウィンドウサイズが記述されている。
【００７９】
時刻t6，t7では、前記ACKの受信に応答して、MHからサーバへ２番目のHTTP REQパケット(POST2)が送信される。このとき、MHはサーバから通知された最大受信ウィンドウサイズとMH自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが「２」に決定され、２つのHTTP REQパケットが一括送信されるものとして説明を続ける。時刻t8，t9では、前記HTTP REQパケットの受信に応答して、サーバからMHへACKが返信される。
【００８０】
本実施形態では、このような2RTT以上セッションについては上式(6)が適用され、右辺分母の代替所要時間Tn(T2)は、第１番目のHTTP REQパケット（群）の到着時刻tdからn番目（最後）のHTTP REQパケット（群）の到着時刻teまでの経過時間[te-td]として、前記通信ログを参照することで算出される。
【００８１】
なお、上記のようにHTTP REQパケットのアップロードにおいてウィンドウサイズ単位での一括送信が繰り返される場合、第１番目のHTTP REQパケット（群）のログ情報と第２番目以降の各HTTP REQパケット群のログ情報との識別が難しくなる。そこで、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を、以下のような手法で推定するようにしている。
【００８２】
第１の手法として、MHがパケットを送信する際のウィンドウサイズの遷移から推定する方法がある。第２の方法として、MHが送信するパケットの連続送信状態から推定する方法がある。
【００８３】
第１の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば１，２，４，８…６４と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケット群の切れ目が推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値（例えば、1sec）以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ＝１から開始されたと推定できるので、第１番目のHTTP REQパケットを容易に推定できる。
【００８４】
また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが１，２，４，８，１６と規則的に増加して終了していれば、今回のセッションはウィンドウサイズ「３２」から始まるものと推定できる。
【００８５】
なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。
【００８６】
第２の手法では、パケット送信が無い状態、すなわちパケット送信・到着間隔が、例えば１RTT_airや0.5RTT_airなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と推定する。
【００８７】
このように、本発明ではウィンドウサイズ単位で一括送信されるパケット群の切れ目を簡単に推定できるので、第１番目のHTTP REQパケット（群）の到着時刻tdからn番目（最後）のHTTP REQパケット（群）の到着時刻teまでの経過時間[te-td]を求められるようになる。
【００８８】
上式(6)に戻り、右辺分母のRTT_sumは、無線エンド側およびサーバエンド側の各固定遅延時間RTT_air，RTT_srvの和なので、前記3ウェイハンドシェイクで送受された各制御パケットの到着時刻差から、これらも記通信ログを参照することで算出される。
【００８９】
一方、右辺分子のSz（n番目までにアップロードされた総データ量から第１番目のアップロードに対応する１パケット分のデータ量を減じた値：ここでは、第２番目のHTTP REQパケットのデータ量に相当）についても、上記のように各HTTP REQパケット群の切れ目を推定できれば、第１番目のHTTP REQパケット（群）のデータ量を簡単に求められるので、これを総データ量から減じるか、あるいは第２番目以降の全てのHTTP REQパケットのデータ量の総和として求められる。
【００９０】
なお、以上ではMHから送信されたパケットがキャプチャポイントに到着するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをサーバがHTTP REQパケットを受けきるまでとするならば、最後の通信データがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が不足する。したがって、例えば上式(6)の代わりに次式(10)を用いる。
Rate＝Sz／(Tn-(n-1)×RTT_sum+RTT_srv/2) … (10)
【００９１】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてSz、TnおよびRTT_sum、さらには必要に応じてRTT_srvを算出すると共に、これらを上式(6)または(10)に適用することで無線区間のスループットRate[bps]を算出する。
【００９２】
次いで、１RTTセッションのスループット計測について説明する。図５は、１RTTセッションのシーケンスフローである。
【００９３】
時刻t1〜t3では、3ウェイハンドシェイクによりMHとサーバとの間にTCPコネクションが確立される。すなわち、時刻t1では、MHからサーバへSYNパケットが送信される。時刻t2では、SYNパケットを受信したサーバからMHへSYN+ACKパケットが返信される。時刻t3では、前記SYN+ACKパケットを受信したMHからサーバへACKが返信される。
【００９４】
TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTP REQパケットが送信される。時刻t5では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t6では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【００９５】
このようなシーケンスにおいて、本実施形態でも3ウェイハンドシェイクで送受されるSYNパケット、SYN+ACKパケットおよびACKパケットがキャプチャされ、それぞれの到着時刻t1，t2，t3が通信ログとして記録される。また、TCPコネクション確立後のコネクションまたはセッション内では、MHから送信されるHTTP REQパケットの到着時刻teのみがキャプチャされる。
【００９６】
本実施形態では、このような1RTTセッションについては上式(9)が適用され、右辺分母の代替所用時間Tが[te-ta]として算出され、サーバエンド側および無線エンド側の各固定遅延時間RTT_srv，RTT_air、ならびにRTT_air／2が前記と同様に通信ログに基づいて算出され、これらを上式(7)に代入することでTotalTimeが差出される。
【００９７】
データ量Mについては、HTTP_REQのパケットサイズM1が前記通信ログに基づいて算出され、これとACKのパケットサイズMa(略40 byte)とを上式(8)に代入して求める。そして、これらを上式(9)に適用することでスループットRateが算出される。
【００９８】
本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内では上りパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。
【００９９】
また、HTTPセッションでは、スループット計測をセッション単位でも行えるので、例えばHTTP・WEBにおいて、今回のセッションと次回のセッションとの間に無線クライアント側でユーザのThink Timeが生じても、このThink Timeが除外された正確なスループット計測が可能になる。
【０１００】
次いで、本発明の第２実施形態について説明する。図６は、前記キャプチャ装置１の第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【０１０１】
ログ情報補完部１０６は、監視対象のコネクションに関して、前記パケットキャプチャ部１０１がキャプチャし損ねたパケットおよびそのデータ量を、その前後にキャプチャされたパケットのデータ量から予測されるMH側のウィンドウサイズWSの遷移状態から予測して前記ログ情報管理部１０２に補完する。
【０１０２】
すなわち、TCPではウィンドウサイズがコネクションの確立直後から離散的かつ規則的に所定の上限値まで増加し、例えば３番目の通信では、４パケット分のデータが送信されることになる。したがって、例えば前回の通信では２パケット分のログ情報が記録され、次回の通信では８パケット分のログ情報が記録されているにも関わらず、今回の通信で３パケット分のログ情報しか記録されていなければ、ここで１パケット分のキャプチャ漏れが生じたと判断して、当該１パケット分のログ情報を追加する。なお、キャプチャし損ねたパケットは、キャプチャできた各パケットに記述されているシーケンス番号の連続性に基づいても把握できる。
【０１０３】
本実施形態によれば、パケットキャプチャ部１０１においてパケットのキャプチャ漏れが生じても、ウィンドウサイズWSやシーケンス番号の遷移履歴に基づいて、キャプチャ漏れしたパケットのログ情報を補完できるので、総データ量をより正確に算出できるようになり、その結果、スループットの測定精度が向上する。
【０１０４】
なお、上記の実施形態では、概略所要時間を補正するための各エンド側固定遅延時間が、TCPコネクション確立時の3ウェイハンドシェイクで送受される制御パケットの到着時刻差に基づいて算出されるものとして説明したが、本発明はこれのみに限定されるものではなく、同一エリアまたは同一基地局において同一時間帯に他の同一種別の端末で別途に計測された遅延時間の算術平均や移動平均などを用いてもよい。
【０１０５】
また、上記の各実施形態では、スループットの計測対象がHTTPセッションである場合を説明したが、本発明はこれのみに限定されるものではなく、メールセッションのスループット計測にも同様に適用できる。
【０１０６】
ただし、メールセッションではTCPコネクションの確立後にユーザ認証処理やCIMAP処理などが実行され、これらのオーバヘッド処理によりデータ転送とは無関係な遅延が発生する。このため、メールセッションに対して前記HTTPセッションの場合と同様にスループット計測を行うと、本来よりも小さな計測結果しか得られない。
【０１０７】
したがって、本発明をメールセッションに適用する場合には、セッションサイズの小さいメールセッション（例えば、1KB以下）は計測対象外として当該メールセッションのセッション時間をオーバヘッド時間（複数であれば、その平均時間）として記憶し、セッションサイズの大きいメールセッション（例えば、50KB以上）のみを計測対象とすると共に、そのセッション時間から前記オーバヘッド時間を減じて所要時間を求めることが望ましい。
【符号の説明】
【０１０８】
１０１…パケットキャプチャ部，１０２…ログ情報管理部，１０３…エンド側固定遅延算出部，１０４…一括送信回数判定部，１０４ａ…ウィンドウサイズ検知部，１０５…通信品質算出部，１０５ａ…第１測定部，１０５ｂ…第２測定部，１０６…ログ情報補完部
【特許請求の範囲】
【請求項１】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、
前記キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、
前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、
スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、
前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。
【請求項２】
前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項１に記載の通信品質測定装置。
【請求項３】
前記ログ情報を参照し、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、
前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択することを特徴とする請求項１または２に記載の通信品質測定装置。
【請求項４】
前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、
前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば１回と判定し、前記ウィンドウサイズよりも大きければ２回以上と判定することを特徴とする請求項３に記載の通信品質測定装置。
【請求項５】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を少なくとも一倍を減じて所要時間を算出し、
前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項６】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍だけ減じ、片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、
前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項７】
前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の(n-1)倍を減じることを特徴とする請求項５または６に記載の通信品質測定装置。
【請求項８】
前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を、ウィンドウサイズが開き切るまでの通信回数分の倍数だけ減じることを特徴とする請求項５または６に記載の通信品質測定装置。
【請求項９】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１０】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１１】
前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項１ないし１０のいずれかに記載の通信品質測定装置。
【請求項１２】
測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１に記載の通信品質測定装置。
【請求項１３】
前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１１のいずれかに記載の通信品質測定装置。
【請求項１４】
前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１１のいずれかに記載の通信品質測定装置。
【請求項１５】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１６】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１７】
前記一括送信回数が１回と判定されたときに、TCPコネクションの確立から第１番目のパケット群の到着時刻までの時間が無線エンド側固定遅延時間の半分以内であることを条件にスループットが算出されることを特徴とする請求項９または１０に記載の通信品質測定装置。
【請求項１８】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットのログ情報をコネクションごとに管理し、
前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が２回以上であると、
無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じて所要時間を算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項１９】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、
前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が１回であると、
無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２０】
前記スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されることを特徴とする請求項１８または１９に記載の通信品質測定方法。
【請求項２１】
前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１８または１９に記載の通信品質測定方法。
【請求項１】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントに到着した上りのTCPパケットをキャプチャするキャプチャ手段と、
前記キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、
前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、
スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、
前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を上りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。
【請求項２】
前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項１に記載の通信品質測定装置。
【請求項３】
前記ログ情報を参照し、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、
前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる上りパケットを選択することを特徴とする請求項１または２に記載の通信品質測定装置。
【請求項４】
前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、
前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば１回と判定し、前記ウィンドウサイズよりも大きければ２回以上と判定することを特徴とする請求項３に記載の通信品質測定装置。
【請求項５】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を少なくとも一倍を減じて所要時間を算出し、
前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項６】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍だけ減じ、片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、
前記総データ量を前記所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項７】
前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の(n-1)倍を減じることを特徴とする請求項５または６に記載の通信品質測定装置。
【請求項８】
前記品質算出手段は、前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和を、ウィンドウサイズが開き切るまでの通信回数分の倍数だけ減じることを特徴とする請求項５または６に記載の通信品質測定装置。
【請求項９】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１０】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
前記品質算出手段は、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて、さらに片道分のサーバエンド側固定遅延時間を加えて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１１】
前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項１ないし１０のいずれかに記載の通信品質測定装置。
【請求項１２】
測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１に記載の通信品質測定装置。
【請求項１３】
前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１１のいずれかに記載の通信品質測定装置。
【請求項１４】
前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１１のいずれかに記載の通信品質測定装置。
【請求項１５】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１６】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１７】
前記一括送信回数が１回と判定されたときに、TCPコネクションの確立から第１番目のパケット群の到着時刻までの時間が無線エンド側固定遅延時間の半分以内であることを条件にスループットが算出されることを特徴とする請求項９または１０に記載の通信品質測定装置。
【請求項１８】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットのログ情報をコネクションごとに管理し、
前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が２回以上であると、
無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
無線クライアントからサーバへウィンドウサイズ単位で一括送信される第１番目のパケット群の到着時刻から最後の第n番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記２番目のパケット群から最後の第n番目のパケット群までの総データ量を算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和の少なくとも１倍を減じて所要時間を算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項１９】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
無線クライアントからサーバへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた上りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、
前記ログ情報に基づいて、データが無線クライアントからサーバへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が１回であると、
無線エンド側およびサーバエンド側の各固定遅延時間を算出し、
TCPコネクション確立時の３ウェイハンドシェイクにおいて無線クライアントから送信されるSYNパケットの到着時刻から、無線クライアントがサーバへウィンドウサイズ単位で一括送信する第１番目のパケット群の到着時刻までを前記代替所要時間として算出し、
前記代替所要時間から、前記無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の和、ならびに片道分の無線エンド側固定遅延時間を減じて所要時間を算出し、
前記第１番目のパケット群のデータ量とTCPにおける標準的なACKサイズとの和を総データ量として算出し、
前記総データ量を前記代替所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２０】
前記スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されることを特徴とする請求項１８または１９に記載の通信品質測定方法。
【請求項２１】
前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１８または１９に記載の通信品質測定方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−７８０１１（Ｐ２０１３−７８０１１Ａ）
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願番号】特願２０１１−２１７１４７（Ｐ２０１１−２１７１４７）
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２５年４月２５日（２０１３．４．２５）
【国際特許分類】
【出願日】平成２３年９月３０日（２０１１．９．３０）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]