通信品質測定方法および装置
【課題】監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいてクライアントの通信品質を正確に分析する。
【解決手段】一括送信回数判定部１０４は、データ通信開始時における初期ウィンドウサイズ(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)一括送信回数が１回と判定されると、サーバエンド側の固定遅延時間を算出し、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、セッションの確立時から終了時までに通信された総データ量を算出し、総データ量を、代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出するようにした。
【００１８】
このとき、スループットの測定対象が、HTTPセッションのデータ通信終了後にTCPコネクションも終了するセッションであれば、セッションの終了時に送信されるパケットとしてFINパケットを監視し、HTTPセッションのデータ通信終了後も継続して異なるHTTP通信が行われるHTTPセッションであれば、セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視するようにした。
【００１９】
(6)キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備した。
【００２０】
(7)測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間からオーバヘッド時間を減じて当該セッションの所要時間とするようにした。
【００２１】
(8)一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、あるいは無線クライアントの種別に基づいてTCPウィンドウサイズの初期値、最大値および増え方を識別し、通信開始時のウィンドウサイズを判別するようにした。
【００２２】
(9)スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されるようにした。
【発明の効果】
【００２３】
本発明によれば、以下のような効果が達成される。
【００２４】
(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が最初にリクエスト(REQ)を送信した時刻、または、最初のHTTP RESパケットを受信した時刻tsから、最後のリクエストに対してサーバから返信された応答(2nd HTTP RES)がMHで受信された時刻teまでを所要時間T_airとし、この間にダウンロードされたデータ量M1，M2…の総和を前記所要時間T_airで除すことで求まる。
【００３８】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では下り方向のパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではサーバからMHへダウンロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００３９】
ネットワーク上にキャプチャポイントを設けた場合、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から最後（ここでは、第２回目）の送信パケット(2nd HTTP RES)に対するACKの到着時刻t3までをスループット計測の所要時間TotalTimeとできる。しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間として、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から最後（ここでは、第２回目）の送信パケット(2nd HTTP RES)の到着時刻t2までの期間Tに着目する。
【００４０】
ただし、この代替所要時間Tは、本来の所要時間TotalTimeよりも、最後（第２回目）の送信パケットの到着時刻t2から、そのACKの到着時刻t3までの期間だけ短くなってしまう。一方、前記代替所要時間Tと本体の所要時間TotalTimeとの差分[t3-t2]は、無線エンド側に固有の固定的な遅延時間と、2nd HTTP RESのデータ量M2に依存する通信時間との和に相当する。
【００４１】
そこで、本発明では最初の送信パケットの到着時刻t1から最後の送信パケットの到着時刻t2までの代替所要時間Tを、前記キャプチャされたパケットの通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分（不足分）を、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて求まる無線エンド側固定遅延時間RTT_airなどから算出し、この算出値で前記代替所要時間Tを補正することで前記本来の所要時間TotalTimeを算出することを考える。
【００４２】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、前記代替所要時間Tに、片道分の無線エンド側固定遅延時間RTT_air/2および2nd HTTP RESのデータ量に依存した遅延時間を加算することで前記所要時間TotalTimeを算出するようにしても良い。
【００４３】
さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が更に不足する。したがって、前記代替所要時間Tに、無線エンド側固定遅延時間RTT_air、2nd HTTP RESのデータ量に依存した遅延時間、および片道分のサーバエンド側固定遅延時間RTT_srv/2を加算することで前記所要時間TotalTimeを算出するようにしても良い。
【００４４】
B．セッションが１回の一括送信のみで完了する場合、あるいは総データ量が初期ウィンドウサイズ以下の場合／
【００４５】
ネットワーク上にキャプチャポイントを設けた場合、図９に示したように、３ウェイハンドシェイクによるTCPコネクションの確立後、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から、これに対してMHが返信する応答パケット(ACK)の到着時刻t2までを、MH側（無線区間）のスループット計測の所要時間TotalTimeとできる。
【００４６】
しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tとして、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から、当該セッションの終了を示唆する下りパケット（ここでは、FINパケット）の到着時刻t3までの期間に着目する。
【００４７】
ただし、この代替所要時間Tは、前記ACKの到着時刻t2からFINの到着時刻t3までの所要時間だけ、本来の所要時間TotalTimeよりも長くなってしまう。一方、前記FIN到着時刻t3とACK到着時刻t2との差分[T3-t2]は、その間に送受されるパケットサイズが小さいことから、TCPコネクション確立時の３ウェイハンドシェイクにおけるサーバエンド側固定遅延時間RTT_srvにほぼ等しい。
【００４８】
そこで、本発明では送信パケットの到着時刻t1からFINパケットの到着時刻t3までの代替所要時間Tを通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分[T3-t2]を、TCPコネクションの確立時に送受される制御パケットの到着時刻に基づいて求まるサーバエンド側固定遅延時間RTT_srvで補正することにより、前記所要時間TotalTimeを算出する。
【００４９】
なお、セッション終了を示唆する下りパケットとしてFINを利用できるのは、最後のデータ通信の終了直後（例えば０．１秒以内）にFINがキャプチャされている場合に限られる。また、HTTPセッションの終了後もTCPコネクションが維持されて次のセッションが確立される場合には、当該次のセッションの開始時に送信される下りパケット（例えば、MHからのHTTP REQに対してサーバが送信されるHTTP RES）を、前記セッション終了を示唆する下りパケットとして利用できる。ただし、この場合も先のセッションの通信終了直後に次のセッションの下りパケットがキャプチャされている場合に限られる。
【００５０】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、上記と同様に、代替所要時間Tから、サーバエンド側固定遅延時間RTT_SRVおよび最後のACKがMHからキャプチャポイントに到着するまでの片道分の無線エンド側遅延時間(RTT_air/2)を減じれば良い。
【００５１】
さらに、スループット計測の所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、代替所要時間Tから、最後のACKがキャプチャポイントからサーバへ到着するまでの片道分のサーバエンド側固定遅延時間(RTT_srv/2)のみを減じれば良い。
【００５２】
次いで、本発明の実施形態について具体的に説明する。図１は、本発明の通信品質測定方法が適用されるネットワークの構成を示したブロック図である。
【００５３】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線移動端末MH）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００５４】
前記インターネットには、MHからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MHと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置１が接続されている。
【００５５】
図２は、前記キャプチャ装置１の第１実施形態の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００５６】
パケットキャプチャ部１０１は、前記回線L上でTCPパケットを選択的にキャプチャする。本実施形態では、キャプチャ対象のパケットが、MHとサーバとの間にTCPコネクションを確立するための3ウェイハンドシェイクで送受される制御パケット、およびTCPコネクションの確立後は、監視対象のセッション内で送受される下りパケットのみに限定される。
【００５７】
ログ情報管理部１０２には、前記キャプチャされたパケットの、少なくとも種別および到着時刻がログ情報としてコネクション毎に記録、管理される。エンド側固定遅延算出部１０３は、前記ログ情報を参照し、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて、データ量に依存しない固定的な各エンド側（無線側およびサーバ側）の遅延時間を算出する。
【００５８】
一括送信回数判定部１０４は、監視対象のコネクション（セッション）について、前記ログ情報を参照することで、そのデータ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、サーバから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パケットが返信される。
【００６５】
TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTP REQパケットが送信されてHTTPセッションが開始される。時刻t5では、前記HTTP REQパケットの受信に応答して、サーバからMHへHTTP RESパケット（データパケット）が送信される。時刻t6では、前記HTTP RESパケットの受信に応答して、MHからサーバへACKが返信される。このACKには、MH側で受信可能な最大受信ウィンドウサイズが記述されている。
【００６６】
時刻t7，t8では、前記ACKパケットに応答してサーバからMHへ次のHTTP RESパケットが送信される。このとき、サーバはMHから通知された最大受信ウィンドウサイズとサーバ自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが「２」に決定され、２つのHTTP RESパケットが一括送信されるものとして説明を続ける。時刻t9，t10では、前記２つのHTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【００６７】
このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYN＋ACKパケットの到着時刻taおよびそのACKの到着時刻tb、ならびにHTTPセッション内での各HTTP RESの到着時刻が参照される。
【００６８】
ここで、MH側の無線区間のスループットRateは、測定期間中に通信される測定対象コネクション（HTTPセッション）の総データ量をTotalSize、通信の所要時間をTotalTimeとすれば次式(1)で表される。
Rate[bps]＝TotalSize[bit]／TotalTime[sec] …(1)
【００６９】
前記総データ量TotalSizeは、ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量をSz、このSzを除く送信済みかつ確認応答[ACK]済みパケット（群）のデータ量をSumSentSzとすれば、次式(2)で表される。
TotalSize＝SumSentSz＋Sz …(2)
【００７０】
なお、SumSentSz（ACK済みのデータ量の合計値）は、一般的にはACKを直接監視し、ACKされたデータのシーケンス番号を確認することで把握できるが、本実施形態ではACKが監視対象外なので、その代わりに以下のような手法で把握する。
【００７１】
第１の手法として、サーバが送信する際のウィンドウサイズの遷移から推定する方法がある。第２の方法として、サーバが送信するデータパケットの連続送信状態から推定する方法がある。第３の方法として、対象セッションで送信された全データ量から、前記ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量Szを減算する方法がある。
【００７２】
第１の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば１，２，４，８…６４と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケットの区切りが推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値（例えば、1sec）以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ＝１から開始されたと推定できるので、一括送信されるパケットの区切りを容易に推定できる。
【００７３】
また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが１，２，４，８，１６と増加して終了していれば、今回のセッションはウィンドウサイズが「３２」から始まるものと推定できる。
【００７４】
なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。
【００７５】
第２の手法では、パケット送信が無い状態、すなわちパケット送信・到着間隔が、例えば１RTT_airや0.5RTT_airなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と見なし、例えば一括送信の総回数が１０回のセッションであれば、最後の一括送信を除く残り９回分の一括送信の総データ量をSumSentSzとして算出する。
【００７６】
第３の方法では、前記第１または第２の方法と同様の手法で最後の一括送信のデータ量（前記Szに相当）を求め、これを総データ量から減じることでSumSentSzを算出する。例えば、一括送信の総回数が１０回のセッションであれば、その総データ量から最後（１０回目）の一括送信のデータ量（前記Szに相当）を減じてSumSentSzを算出する。
【００７７】
前記TotalTimeは、キャプチャポイントで観測された、最初のHTTP RESパケットの到着時刻tcから最後のHTTP RESパケットの到着時刻tdまでの代替所要時間をT、無線区間においてデータ量とは無関係に固定的にかかる無線エンド側の遅延時間をRTT_air、前記データ量Szの送信に要する時間をαとすれば次式(3)で表される。
TotalTime＝T＋｛RTT_air＋α｝ …(3)
【００７８】
したがって、上式(1)は前記データ量Szの送信時におけるスループットをR'とすれば、次式(4)のように展開できる。
Rate＝TotalSize／TotalTime
＝TotalSize／(T+｛RTT_air+α｝)
＝TotalSize／(T+｛RTT_air+(Sz／R')｝) …(4)
【００７９】
上式(4)を更に展開すると次式(5)が得られる。
Rate＝R'・TotalSize／(R'(T+RTT_air)+Sz）
Rate｛R'(T+RTT_air)+Sz｝＝R'・TotalSize …(5)
【００８０】
ここで、データ通信時におけるスループットは当該通信時間内において同一であると仮定する、すなわち本実施形態ではセッション内の平均スループットを求めたいので、Rate=R'とすれば、上式(5)は次式(6)のように展開できる。
R'(T+RTT_air)+Sz＝TotalSize
R'＝(TotalSize-Sz)／(T+RTT_air)
＝SumSentSz／(T+RTT_air) …(6)
【００８１】
したがって、次式(7)が成立し、前記ACKを待たずに送信されたデータ量Szを考慮する必要が無くなる。
Rate[bps]＝SumSentSz／(T+RTT_air) …(7)
【００８２】
前記SumSentSzは、これを前記第１の方法で算出するのであれば、セッション開始時からのウィンドウサイズの遷移履歴に基づいて、ウィンドウサイズ単位で一括送信されたパケット群の切れ目を識別し、最初に送信されたパケット（群）P1から最後に送信されたパケット（群）Peの直前に送信されたパケット群Pe-1までの総データ量ΣP＝P1+P2+…+Pe-1として、前記通信ログを参照することで求められる。
【００８３】
例えば、セッション開始時のウィンドウサイズが「１」であり、最後のパケット（群）が送信された際のウィンドウサイズが「８」であり、ウィンドウサイズが１，２，４，８…と増加するのであれば、最初の一括送信では１パケット、２番目の一括送信では２パケット、３番目の一括送信では４パケットが送信され、４番目の一括送信で残りの全てのパケット（８パケット以下）が送信されたことになる。したがって、SumSentSzは７(=１+２+４)パケット相当となる。
【００８４】
また、セッション開始時のウィンドウサイズが「２」であり、最後のパケット（群）が送信された際のウィンドウサイズが「８」であれば、最初の一括送信では２パケット、２番目の一括送信では４パケットが送信され、３番目の一括送信で残りの全てのパケット（８パケット以下）が送信されたことになる。したがって、SumSentSzは６(=２+４)パケット相当となる。
【００８５】
なお、前記SumSentSzを前記第２の方法で算出するのであれば、パケット送信・到着間隔が閾値を超えた切れ目に基づいて識別される一括送信の総回数が例えば３回であり、最後を除く１，２回目の一括送信のパケット数がそれぞれ「４」，「８」であれば、SumSentSzは１２(=４+８)パケット相当となる。
【００８６】
さらに、前記SumSentSzを前記第３の方法で算出するのであれば、前記ウィンドウサイズの遷移やパケット送信・到着間隔に基づいて一括送信の切れ目を識別し、総データ量ΣPが１２パケット相当であって、最後の一括送信のデータ量が２パケット相当であれば、SumSentSzは１０(=１２-２)パケット相当となる。
【００８７】
前記代替所要時間Tは、最初のHTTP RESパケットの到着時刻tcから最後のHTTP RESパケットの到着時刻tdまでの期間として、前記通信ログを参照することで求められる。さらに、データ量に依存しない各エンド側の固定遅延時間RTT_air，RTT_srvは、３ウェイハンドシェイクにおける各制御パケットの到着時刻差から算出できる。
【００８８】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、上式(7)の代わりに次式(8)を用いる。
Rate[bps]＝SumSentSz／(T+RTT_air/2) …(8)
【００８９】
さらに、スループット計測の所要時間TotalTimeを、サーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が不足する。したがって、上式(7)，(8)の代わりに次式(9)を用いる。
Rate[bps]＝SumSentSz／(T+RTT_air+RTT_srv/2) …(9)
【００９０】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてSumSentSz、TおよびRTT_air、さらには必要に応じてRTT_srvを算出すると共に、これらを上式(7)，(8)または(9)に適用することで無線区間のスループットRate[bps]を算出する。
【００９１】
なお、上式(7)-(9)の代替所要時間Tについては、ウィンドウサイズが最大値に達するまで（ウィンドウが開ききるまで）の一括送信回数ｎ分やデータ通信における全ての一括送信回数N分だけ、無線エンド側固定遅延時間RTT_airとサーバエンド側固定遅延時間RTT_srvとの和（RTT_sum）だけ減じ、例えば上式(7)であれば次式(10)のように変更しても良い。
Rate[bps]＝SumSentSz／(T-(n×RTT_sum)＋RTT_air) …(10)
【００９２】
次いで、１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パケットが返信される。時刻t7では、サーバからMHへFINパケットが送信される。時刻t8では、前記FINパケットに応答してMHからサーバへACKパケットが返信される。
【００９５】
このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYNパケットの到着時刻taおよびSYN+ACKパケットの到着時刻tbがキャプチャされ、TCPコネクション確立後のHTTPセッション内では、下りパケット（本実施形態では、HTTP RESパケットおよびFINパケット）の到着時刻のみがキャプチャされる。
【００９６】
なお、今回のセッションの終了後に次のセッションが直ちに開始される場合は、後に詳述するように、当該次のセッションにおいてサーバからMHへ最初に送信される下り方向のHTTP RESパケットが、前記FINパケットの代わりにキャプチャされる。
【００９７】
ここで、MH側の無線区間のスループットRateは、観測期間中に測定対象コネクションで通信される総データ量をTotalSize、通信の所要時間をTotalTimeとすれば、次式(11)で表される。
Rate[bps]＝TotalSize[bit]／TotalTime[sec] …(11)
【００９８】
前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まる。所要時間TotalTimeは、HTTP RESパケットの到着時刻tcからFINパケットの到着時刻teまでの代替所要時間Tと、前記HTTP RESパケットに対するACKパケットの到着時刻tdからFINパケットの到着時刻teまでの所要時間（補正値）ΔT3との差分として求まる。
【００９９】
前記代替所要時間Tは、通信ログとして記録されたHTTP RESパケットおよびFINパケットの各到着時刻tc，teから求まる。一方、所要時間（補正値）ΔT3はサーバエンド側の固定遅延時間RTT_sevに相当し、これはTCPコネクション確立時の3ウェイハンドシェイクにおけるSYNパケットに対するSYN+ACKパケットの応答遅延時間に相当するので、SYNパケットの到着時刻taからSYN+ACKパケットの到着時刻tbまでの所要時間として求まる。
【０１００】
なお、前記サーバエンド側の固定遅延時間RTT_sevや無線エンド側固定遅延時間RTT_airも、厳密にはスループットの影響を受けることになるが、3ウェイハンドシェイクでは、送受されるパケットサイズが他のデータパケットに較べて十分に小さいので、実質的には無視できる。
【０１０１】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてTotalTimeおよびTotalSizeを算出すると共に、これらを上式(11)に適用することで、無線区間のスループットRate[bps]を算出する。
【０１０２】
本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内ではダウンロード方向のパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。
【０１０３】
図６は、セッション終了後もTCPコネクションが維持されるためにFINパケットを観測できないときに、当該FINパケットに代えて、次のセッションでサーバからMHへ送信されるHTTP RESパケットの到着時刻に基づいて所要時間TotalTimeを算出する例を示したシーケンスフローである。
【０１０４】
TCPコネクションが確立されると、時刻t4では、最初のHTTPセッションにおいて、MHからサーバへHTTP REQパケットが送信される。時刻t5では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t6では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【０１０５】
時刻t7では、次のHTTPセッションにおいて、MHからサーバへHTTP REQパケットが送信される。時刻t8では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t9では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【０１０６】
本実施形態では、前記所要時間TotalTimeが、最初のHTTP RESパケットの到着時刻tcから次のHTTP RESパケットの到着時刻teまでの代替所要時間Tと、前記最初のHTTP RESパケットに対するACKパケットの到着時刻tdから次のHTTP RESパケットの到着時刻teまでの所要時間（補正値）ΔT4との差分として求まる。前記補正値ΔT4は、サーバエンド側固定遅延時間RTT_srvとして求まる。
【０１０７】
そして、前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まり、これらを上式(11)に適用することで、無線区間のスループットRate[bps]を算出できる。
【０１０８】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、前記代替所要時間Tから、サーバエンド側固定遅延時間RTT_srvおよび片道分の無線エンド側固定遅延時間RTT_air/2を減じることで前記所要時間TotalTimeを算出するようにしても良い。
【０１０９】
さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)を加える必要がある。したがって、前記代替所要時間Tから片道分のサーバエンド側固定遅延時間RTT_srv/2を減じることで前記所要時間TotalTimeを算出するようにしても良い。
【０１１０】
次いで、本発明の第２実施形態について説明する。図７は、前記キャプチャ装置１の第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【０１１１】
ログ情報補完部１０６は、監視対象のコネクションに関して、前記パケットキャプチャ部１０１がキャプチャし損ねたパケットおよびそのデータ量を、その前後にキャプチャされたパケットのデータ量から予測される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)一括送信回数が１回と判定されると、サーバエンド側の固定遅延時間を算出し、サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、セッションの確立時から終了時までに通信された総データ量を算出し、総データ量を、代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出するようにした。
【００１８】
このとき、スループットの測定対象が、HTTPセッションのデータ通信終了後にTCPコネクションも終了するセッションであれば、セッションの終了時に送信されるパケットとしてFINパケットを監視し、HTTPセッションのデータ通信終了後も継続して異なるHTTP通信が行われるHTTPセッションであれば、セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視するようにした。
【００１９】
(6)キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備した。
【００２０】
(7)測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間からオーバヘッド時間を減じて当該セッションの所要時間とするようにした。
【００２１】
(8)一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、あるいは無線クライアントの種別に基づいてTCPウィンドウサイズの初期値、最大値および増え方を識別し、通信開始時のウィンドウサイズを判別するようにした。
【００２２】
(9)スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されるようにした。
【発明の効果】
【００２３】
本発明によれば、以下のような効果が達成される。
【００２４】
(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が最初にリクエスト(REQ)を送信した時刻、または、最初のHTTP RESパケットを受信した時刻tsから、最後のリクエストに対してサーバから返信された応答(2nd HTTP RES)がMHで受信された時刻teまでを所要時間T_airとし、この間にダウンロードされたデータ量M1，M2…の総和を前記所要時間T_airで除すことで求まる。
【００３８】
しかしながら、本発明ではキャプチャポイントをMHではなくネットワーク上に設定し、かつ監視対象のパケットを、TCPコネクション確立後の当該コネクション内では下り方向のパケットのみに限定し、キャプチャ対象のパケット数を減ずることでスケーラビリティを確保する。したがって、ここではサーバからMHへダウンロードされるパケットのキャプチャポイントへの到着時刻のみを所要時間の算出基準とすることを考える。
【００３９】
ネットワーク上にキャプチャポイントを設けた場合、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から最後（ここでは、第２回目）の送信パケット(2nd HTTP RES)に対するACKの到着時刻t3までをスループット計測の所要時間TotalTimeとできる。しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間として、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から最後（ここでは、第２回目）の送信パケット(2nd HTTP RES)の到着時刻t2までの期間Tに着目する。
【００４０】
ただし、この代替所要時間Tは、本来の所要時間TotalTimeよりも、最後（第２回目）の送信パケットの到着時刻t2から、そのACKの到着時刻t3までの期間だけ短くなってしまう。一方、前記代替所要時間Tと本体の所要時間TotalTimeとの差分[t3-t2]は、無線エンド側に固有の固定的な遅延時間と、2nd HTTP RESのデータ量M2に依存する通信時間との和に相当する。
【００４１】
そこで、本発明では最初の送信パケットの到着時刻t1から最後の送信パケットの到着時刻t2までの代替所要時間Tを、前記キャプチャされたパケットの通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分（不足分）を、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて求まる無線エンド側固定遅延時間RTT_airなどから算出し、この算出値で前記代替所要時間Tを補正することで前記本来の所要時間TotalTimeを算出することを考える。
【００４２】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、前記代替所要時間Tに、片道分の無線エンド側固定遅延時間RTT_air/2および2nd HTTP RESのデータ量に依存した遅延時間を加算することで前記所要時間TotalTimeを算出するようにしても良い。
【００４３】
さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が更に不足する。したがって、前記代替所要時間Tに、無線エンド側固定遅延時間RTT_air、2nd HTTP RESのデータ量に依存した遅延時間、および片道分のサーバエンド側固定遅延時間RTT_srv/2を加算することで前記所要時間TotalTimeを算出するようにしても良い。
【００４４】
B．セッションが１回の一括送信のみで完了する場合、あるいは総データ量が初期ウィンドウサイズ以下の場合／
【００４５】
ネットワーク上にキャプチャポイントを設けた場合、図９に示したように、３ウェイハンドシェイクによるTCPコネクションの確立後、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から、これに対してMHが返信する応答パケット(ACK)の到着時刻t2までを、MH側（無線区間）のスループット計測の所要時間TotalTimeとできる。
【００４６】
しかしながら、本発明では上りパケットは監視対象外なので、下りパケットの到着時刻のみで計測でき、かつ無線区間の影響を受けて変化する代替所要時間Tとして、第１回目の送信パケット(1st HTTP RES)の到着時刻t1から、当該セッションの終了を示唆する下りパケット（ここでは、FINパケット）の到着時刻t3までの期間に着目する。
【００４７】
ただし、この代替所要時間Tは、前記ACKの到着時刻t2からFINの到着時刻t3までの所要時間だけ、本来の所要時間TotalTimeよりも長くなってしまう。一方、前記FIN到着時刻t3とACK到着時刻t2との差分[T3-t2]は、その間に送受されるパケットサイズが小さいことから、TCPコネクション確立時の３ウェイハンドシェイクにおけるサーバエンド側固定遅延時間RTT_srvにほぼ等しい。
【００４８】
そこで、本発明では送信パケットの到着時刻t1からFINパケットの到着時刻t3までの代替所要時間Tを通信ログに基づいて算出する一方、この代替所要時間Tと本来の所要時間TotalTimeとの差分[T3-t2]を、TCPコネクションの確立時に送受される制御パケットの到着時刻に基づいて求まるサーバエンド側固定遅延時間RTT_srvで補正することにより、前記所要時間TotalTimeを算出する。
【００４９】
なお、セッション終了を示唆する下りパケットとしてFINを利用できるのは、最後のデータ通信の終了直後（例えば０．１秒以内）にFINがキャプチャされている場合に限られる。また、HTTPセッションの終了後もTCPコネクションが維持されて次のセッションが確立される場合には、当該次のセッションの開始時に送信される下りパケット（例えば、MHからのHTTP REQに対してサーバが送信されるHTTP RES）を、前記セッション終了を示唆する下りパケットとして利用できる。ただし、この場合も先のセッションの通信終了直後に次のセッションの下りパケットがキャプチャされている場合に限られる。
【００５０】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、上記と同様に、代替所要時間Tから、サーバエンド側固定遅延時間RTT_SRVおよび最後のACKがMHからキャプチャポイントに到着するまでの片道分の無線エンド側遅延時間(RTT_air/2)を減じれば良い。
【００５１】
さらに、スループット計測の所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、代替所要時間Tから、最後のACKがキャプチャポイントからサーバへ到着するまでの片道分のサーバエンド側固定遅延時間(RTT_srv/2)のみを減じれば良い。
【００５２】
次いで、本発明の実施形態について具体的に説明する。図１は、本発明の通信品質測定方法が適用されるネットワークの構成を示したブロック図である。
【００５３】
サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線移動端末MH）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００５４】
前記インターネットには、MHからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各MHと各サーバとの間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置１が接続されている。
【００５５】
図２は、前記キャプチャ装置１の第１実施形態の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００５６】
パケットキャプチャ部１０１は、前記回線L上でTCPパケットを選択的にキャプチャする。本実施形態では、キャプチャ対象のパケットが、MHとサーバとの間にTCPコネクションを確立するための3ウェイハンドシェイクで送受される制御パケット、およびTCPコネクションの確立後は、監視対象のセッション内で送受される下りパケットのみに限定される。
【００５７】
ログ情報管理部１０２には、前記キャプチャされたパケットの、少なくとも種別および到着時刻がログ情報としてコネクション毎に記録、管理される。エンド側固定遅延算出部１０３は、前記ログ情報を参照し、TCPコネクションの確立時に送受される制御パケットの到着時刻差に基づいて、データ量に依存しない固定的な各エンド側（無線側およびサーバ側）の遅延時間を算出する。
【００５８】
一括送信回数判定部１０４は、監視対象のコネクション（セッション）について、前記ログ情報を参照することで、そのデータ通信開始時における初期ウィンドウサイズ(WS)を検知するWS検知部１０４ａを具備し、サーバから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パケットが返信される。
【００６５】
TCPコネクションが確立されると、時刻t4では、MHからサーバへHTTP REQパケットが送信されてHTTPセッションが開始される。時刻t5では、前記HTTP REQパケットの受信に応答して、サーバからMHへHTTP RESパケット（データパケット）が送信される。時刻t6では、前記HTTP RESパケットの受信に応答して、MHからサーバへACKが返信される。このACKには、MH側で受信可能な最大受信ウィンドウサイズが記述されている。
【００６６】
時刻t7，t8では、前記ACKパケットに応答してサーバからMHへ次のHTTP RESパケットが送信される。このとき、サーバはMHから通知された最大受信ウィンドウサイズとサーバ自身が管理する送信ウィンドウサイズとに基づいて今回のウィンドウサイズWSを決定する。ここでは、ウィンドウサイズWSが「２」に決定され、２つのHTTP RESパケットが一括送信されるものとして説明を続ける。時刻t9，t10では、前記２つのHTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【００６７】
このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYN＋ACKパケットの到着時刻taおよびそのACKの到着時刻tb、ならびにHTTPセッション内での各HTTP RESの到着時刻が参照される。
【００６８】
ここで、MH側の無線区間のスループットRateは、測定期間中に通信される測定対象コネクション（HTTPセッション）の総データ量をTotalSize、通信の所要時間をTotalTimeとすれば次式(1)で表される。
Rate[bps]＝TotalSize[bit]／TotalTime[sec] …(1)
【００６９】
前記総データ量TotalSizeは、ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量をSz、このSzを除く送信済みかつ確認応答[ACK]済みパケット（群）のデータ量をSumSentSzとすれば、次式(2)で表される。
TotalSize＝SumSentSz＋Sz …(2)
【００７０】
なお、SumSentSz（ACK済みのデータ量の合計値）は、一般的にはACKを直接監視し、ACKされたデータのシーケンス番号を確認することで把握できるが、本実施形態ではACKが監視対象外なので、その代わりに以下のような手法で把握する。
【００７１】
第１の手法として、サーバが送信する際のウィンドウサイズの遷移から推定する方法がある。第２の方法として、サーバが送信するデータパケットの連続送信状態から推定する方法がある。第３の方法として、対象セッションで送信された全データ量から、前記ACKを待たずに送信された最後の送信パケットまたはパケット群のデータ量Szを減算する方法がある。
【００７２】
第１の手法では、ウィンドウサイズがTCPセッションの確立直後から通信毎に、例えば１，２，４，８…６４と離散的かつ規則的に増加する点に着目し、各パケットの到着時刻およびデータサイズに基づいて、一括送信されるパケットの区切りが推定される。このとき、TCPセッションの確立時刻とHTTPセッションの開始時刻との差が所定の閾値（例えば、1sec）以内であり、HTTPセッションがTCPコネクションの確立直後に構築されているのであれば、当該HTTPセッションが最初のセッションであってウィンドウサイズ＝１から開始されたと推定できるので、一括送信されるパケットの区切りを容易に推定できる。
【００７３】
また、HTTPセッションがTCPコネクションの確立直後に構築されていない場合でも、当該TCPコネクションにおけるHTTPセッションおよびデータ通信のこれまでの推移、履歴などを記録しておけば、これらの情報を参照することによってウィンドウサイズの初期値を推定できる。例えば、当該TCPコネクションにおける直前のセッションにおいて、ウィンドウサイズが１，２，４，８，１６と増加して終了していれば、今回のセッションはウィンドウサイズが「３２」から始まるものと推定できる。
【００７４】
なお、ウィンドウサイズの初期値、最大値および増え方は、各エンド端末の種類や採用されるTCPの種別により異なるが、各エンド端末の種類は、例えばHTTPのユーザエージェントを分析することで判別できる。また、TCPの種別はTCPヘッダに明示的に記述された情報やその後のシーケンスや挙動などを基に判定できる。
【００７５】
第２の手法では、パケット送信が無い状態、すなわちパケット送信・到着間隔が、例えば１RTT_airや0.5RTT_airなどの閾値を超えたら、当該タイミングをウィンドウサイズに基づく一括送信の切れ目と見なし、例えば一括送信の総回数が１０回のセッションであれば、最後の一括送信を除く残り９回分の一括送信の総データ量をSumSentSzとして算出する。
【００７６】
第３の方法では、前記第１または第２の方法と同様の手法で最後の一括送信のデータ量（前記Szに相当）を求め、これを総データ量から減じることでSumSentSzを算出する。例えば、一括送信の総回数が１０回のセッションであれば、その総データ量から最後（１０回目）の一括送信のデータ量（前記Szに相当）を減じてSumSentSzを算出する。
【００７７】
前記TotalTimeは、キャプチャポイントで観測された、最初のHTTP RESパケットの到着時刻tcから最後のHTTP RESパケットの到着時刻tdまでの代替所要時間をT、無線区間においてデータ量とは無関係に固定的にかかる無線エンド側の遅延時間をRTT_air、前記データ量Szの送信に要する時間をαとすれば次式(3)で表される。
TotalTime＝T＋｛RTT_air＋α｝ …(3)
【００７８】
したがって、上式(1)は前記データ量Szの送信時におけるスループットをR'とすれば、次式(4)のように展開できる。
Rate＝TotalSize／TotalTime
＝TotalSize／(T+｛RTT_air+α｝)
＝TotalSize／(T+｛RTT_air+(Sz／R')｝) …(4)
【００７９】
上式(4)を更に展開すると次式(5)が得られる。
Rate＝R'・TotalSize／(R'(T+RTT_air)+Sz）
Rate｛R'(T+RTT_air)+Sz｝＝R'・TotalSize …(5)
【００８０】
ここで、データ通信時におけるスループットは当該通信時間内において同一であると仮定する、すなわち本実施形態ではセッション内の平均スループットを求めたいので、Rate=R'とすれば、上式(5)は次式(6)のように展開できる。
R'(T+RTT_air)+Sz＝TotalSize
R'＝(TotalSize-Sz)／(T+RTT_air)
＝SumSentSz／(T+RTT_air) …(6)
【００８１】
したがって、次式(7)が成立し、前記ACKを待たずに送信されたデータ量Szを考慮する必要が無くなる。
Rate[bps]＝SumSentSz／(T+RTT_air) …(7)
【００８２】
前記SumSentSzは、これを前記第１の方法で算出するのであれば、セッション開始時からのウィンドウサイズの遷移履歴に基づいて、ウィンドウサイズ単位で一括送信されたパケット群の切れ目を識別し、最初に送信されたパケット（群）P1から最後に送信されたパケット（群）Peの直前に送信されたパケット群Pe-1までの総データ量ΣP＝P1+P2+…+Pe-1として、前記通信ログを参照することで求められる。
【００８３】
例えば、セッション開始時のウィンドウサイズが「１」であり、最後のパケット（群）が送信された際のウィンドウサイズが「８」であり、ウィンドウサイズが１，２，４，８…と増加するのであれば、最初の一括送信では１パケット、２番目の一括送信では２パケット、３番目の一括送信では４パケットが送信され、４番目の一括送信で残りの全てのパケット（８パケット以下）が送信されたことになる。したがって、SumSentSzは７(=１+２+４)パケット相当となる。
【００８４】
また、セッション開始時のウィンドウサイズが「２」であり、最後のパケット（群）が送信された際のウィンドウサイズが「８」であれば、最初の一括送信では２パケット、２番目の一括送信では４パケットが送信され、３番目の一括送信で残りの全てのパケット（８パケット以下）が送信されたことになる。したがって、SumSentSzは６(=２+４)パケット相当となる。
【００８５】
なお、前記SumSentSzを前記第２の方法で算出するのであれば、パケット送信・到着間隔が閾値を超えた切れ目に基づいて識別される一括送信の総回数が例えば３回であり、最後を除く１，２回目の一括送信のパケット数がそれぞれ「４」，「８」であれば、SumSentSzは１２(=４+８)パケット相当となる。
【００８６】
さらに、前記SumSentSzを前記第３の方法で算出するのであれば、前記ウィンドウサイズの遷移やパケット送信・到着間隔に基づいて一括送信の切れ目を識別し、総データ量ΣPが１２パケット相当であって、最後の一括送信のデータ量が２パケット相当であれば、SumSentSzは１０(=１２-２)パケット相当となる。
【００８７】
前記代替所要時間Tは、最初のHTTP RESパケットの到着時刻tcから最後のHTTP RESパケットの到着時刻tdまでの期間として、前記通信ログを参照することで求められる。さらに、データ量に依存しない各エンド側の固定遅延時間RTT_air，RTT_srvは、３ウェイハンドシェイクにおける各制御パケットの到着時刻差から算出できる。
【００８８】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、これをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、上式(7)の代わりに次式(8)を用いる。
Rate[bps]＝SumSentSz／(T+RTT_air/2) …(8)
【００８９】
さらに、スループット計測の所要時間TotalTimeを、サーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)が不足する。したがって、上式(7)，(8)の代わりに次式(9)を用いる。
Rate[bps]＝SumSentSz／(T+RTT_air+RTT_srv/2) …(9)
【００９０】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてSumSentSz、TおよびRTT_air、さらには必要に応じてRTT_srvを算出すると共に、これらを上式(7)，(8)または(9)に適用することで無線区間のスループットRate[bps]を算出する。
【００９１】
なお、上式(7)-(9)の代替所要時間Tについては、ウィンドウサイズが最大値に達するまで（ウィンドウが開ききるまで）の一括送信回数ｎ分やデータ通信における全ての一括送信回数N分だけ、無線エンド側固定遅延時間RTT_airとサーバエンド側固定遅延時間RTT_srvとの和（RTT_sum）だけ減じ、例えば上式(7)であれば次式(10)のように変更しても良い。
Rate[bps]＝SumSentSz／(T-(n×RTT_sum)＋RTT_air) …(10)
【００９２】
次いで、１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パケットが返信される。時刻t7では、サーバからMHへFINパケットが送信される。時刻t8では、前記FINパケットに応答してMHからサーバへACKパケットが返信される。
【００９５】
このようなシーケンスにおいて、本実施形態では3ウェイハンドシェイクで送受されるSYNパケットの到着時刻taおよびSYN+ACKパケットの到着時刻tbがキャプチャされ、TCPコネクション確立後のHTTPセッション内では、下りパケット（本実施形態では、HTTP RESパケットおよびFINパケット）の到着時刻のみがキャプチャされる。
【００９６】
なお、今回のセッションの終了後に次のセッションが直ちに開始される場合は、後に詳述するように、当該次のセッションにおいてサーバからMHへ最初に送信される下り方向のHTTP RESパケットが、前記FINパケットの代わりにキャプチャされる。
【００９７】
ここで、MH側の無線区間のスループットRateは、観測期間中に測定対象コネクションで通信される総データ量をTotalSize、通信の所要時間をTotalTimeとすれば、次式(11)で表される。
Rate[bps]＝TotalSize[bit]／TotalTime[sec] …(11)
【００９８】
前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まる。所要時間TotalTimeは、HTTP RESパケットの到着時刻tcからFINパケットの到着時刻teまでの代替所要時間Tと、前記HTTP RESパケットに対するACKパケットの到着時刻tdからFINパケットの到着時刻teまでの所要時間（補正値）ΔT3との差分として求まる。
【００９９】
前記代替所要時間Tは、通信ログとして記録されたHTTP RESパケットおよびFINパケットの各到着時刻tc，teから求まる。一方、所要時間（補正値）ΔT3はサーバエンド側の固定遅延時間RTT_sevに相当し、これはTCPコネクション確立時の3ウェイハンドシェイクにおけるSYNパケットに対するSYN+ACKパケットの応答遅延時間に相当するので、SYNパケットの到着時刻taからSYN+ACKパケットの到着時刻tbまでの所要時間として求まる。
【０１００】
なお、前記サーバエンド側の固定遅延時間RTT_sevや無線エンド側固定遅延時間RTT_airも、厳密にはスループットの影響を受けることになるが、3ウェイハンドシェイクでは、送受されるパケットサイズが他のデータパケットに較べて十分に小さいので、実質的には無視できる。
【０１０１】
前記第２算出部１０５ｂは、通信ログを参照し、以上のようにしてTotalTimeおよびTotalSizeを算出すると共に、これらを上式(11)に適用することで、無線区間のスループットRate[bps]を算出する。
【０１０２】
本実施形態によれば、TCPコネクションの確立時に送受される制御パケット、およびTCPコネクション確立後のコネクション内ではダウンロード方向のパケットのみをキャプチャするだけで無線区間のスループットを正確に求められるようになる。したがって、一箇所のキャプチャポイントにおいて、一コネクション当たりのキャプチャ対象のパケット数を減ずることができ、その結果、多数のコネクションを監視することが可能になるので、スケーラブルなスループット測定が可能になる。
【０１０３】
図６は、セッション終了後もTCPコネクションが維持されるためにFINパケットを観測できないときに、当該FINパケットに代えて、次のセッションでサーバからMHへ送信されるHTTP RESパケットの到着時刻に基づいて所要時間TotalTimeを算出する例を示したシーケンスフローである。
【０１０４】
TCPコネクションが確立されると、時刻t4では、最初のHTTPセッションにおいて、MHからサーバへHTTP REQパケットが送信される。時刻t5では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t6では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【０１０５】
時刻t7では、次のHTTPセッションにおいて、MHからサーバへHTTP REQパケットが送信される。時刻t8では、前記HTTP REQパケットの受信に応答してサーバからMHへHTTP RESパケットが送信される。時刻t9では、前記HTTP RESパケットの受信に応答してMHからサーバへACKパケットが返信される。
【０１０６】
本実施形態では、前記所要時間TotalTimeが、最初のHTTP RESパケットの到着時刻tcから次のHTTP RESパケットの到着時刻teまでの代替所要時間Tと、前記最初のHTTP RESパケットに対するACKパケットの到着時刻tdから次のHTTP RESパケットの到着時刻teまでの所要時間（補正値）ΔT4との差分として求まる。前記補正値ΔT4は、サーバエンド側固定遅延時間RTT_srvとして求まる。
【０１０７】
そして、前記TotalSizeは、唯一の送信パケットのデータ量なので、そのログ情報を参照することで求まり、これらを上式(11)に適用することで、無線区間のスループットRate[bps]を算出できる。
【０１０８】
なお、以上ではMHがサーバから通信データを受けきってACKを応答するまでがスループット計測の所要時間TotalTimeであるものとして説明したが、所要時間TotalTimeをMHがサーバから通信データを受けきるまでとするならば、最後のACKがMHからチャプチャポイントに到着するまでの時間(RTT_air/2)が不要となる。したがって、前記代替所要時間Tから、サーバエンド側固定遅延時間RTT_srvおよび片道分の無線エンド側固定遅延時間RTT_air/2を減じることで前記所要時間TotalTimeを算出するようにしても良い。
【０１０９】
さらに、所要時間TotalTimeをサーバがMHからACKを受信するまでとするならば、最後のACKがキャプチャポイントからサーバへ到着するまでの時間(RTT_srv/2)を加える必要がある。したがって、前記代替所要時間Tから片道分のサーバエンド側固定遅延時間RTT_srv/2を減じることで前記所要時間TotalTimeを算出するようにしても良い。
【０１１０】
次いで、本発明の第２実施形態について説明する。図７は、前記キャプチャ装置１の第２実施形態の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【０１１１】
ログ情報補完部１０６は、監視対象のコネクションに関して、前記パケットキャプチャ部１０１がキャプチャし損ねたパケットおよびそのデータ量を、その前後にキャプチャされたパケットのデータ量から予測されるMH側のウィンドウサイズWSの遷移状態から予測して前記ログ情報管理部１０２に補完する。
【０１１２】
すなわち、TCPではウィンドウサイズがコネクションの確立直後から離散的かつ規則的に所定の上限値まで増加し、例えば３回目の通信では、４パケット分のデータが送信されることになる。したがって、例えば前回の通信では２パケット分のログ情報が記録され、次回の通信では８パケット分のログ情報が記録されているにも関わらず、今回の通信で３パケット分のログ情報しか記録されていなければ、ここで１パケット分のキャプチャ漏れが生じたと判断して、当該１パケット分のログ情報を追加する。なお、キャプチャし損ねたパケットは、キャプチャできた各パケットに記述されているシーケンス番号の連続性に基づいても把握できる。
【０１１３】
本実施形態によれば、パケットキャプチャ部１０１においてパケットのキャプチャ漏れが生じても、ウィンドウサイズWSやシーケンス番号の遷移履歴に基づいて、キャプチャ漏れしたパケットのログ情報を補完できるので、総データ量をより正確に算出できるようになり、その結果、スループットの測定精度が向上する。
【０１１４】
なお、上記の実施形態では、代替所要時間を補正するための各エンド側固定遅延時間が、TCPコネクション確立時の3ウェイハンドシェイクで送受される制御パケットの到着時刻差に基づいて算出されるものとして説明したが、本発明はこれのみに限定されるものではなく、同一エリアまたは同一基地局において同一時間帯に他の同一種別の端末で別途に計測された遅延時間の算術平均や移動平均などを用いてもよい。
【０１１５】
また、上記の各実施形態では、スループットの計測対象がHTTPセッションである場合を説明したが、本発明はこれのみに限定されるものではなく、メールセッションのスループット計測にも同様に適用できる。
【０１１６】
ただし、メールセッションではTCPコネクションの確立後にユーザ認証処理やCIMAP処理などが実行され、これらのオーバヘッド処理によりデータ転送とは無関係な遅延が発生する。このため、メールセッションに対して前記HTTPセッションの場合と同様にスループット計測を行うと、本来よりも小さな計測結果しか得られない。
【０１１７】
したがって、本発明をメールセッションに適用する場合には、セッションサイズの小さいメールセッション（例えば、1KB以下）は計測対象外として当該メールセッションのセッション時間をオーバヘッド時間（複数であれば、その平均時間）として記憶し、セッションサイズの大きいメールセッション（例えば、50KB以上）のみを計測対象とすると共に、そのセッション時間から前記オーバヘッド時間を減じて所要時間を求めることが望ましい。
【符号の説明】
【０１１８】
１０１…パケットキャプチャ部，１０２…ログ情報管理部，１０３…エンド側固定遅延算出部，１０４…一括送信回数判定部，１０４ａ…ウィンドウサイズ検知部，１０５…通信品質算出部，１０５ａ…第１測定部，１０５ｂ…第２測定部，１０６…ログ情報補完部
【特許請求の範囲】
【請求項１】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントに到着した下りのTCPパケットをキャプチャするキャプチャ手段と、
前記キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、
前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、
スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、
前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を下りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。
【請求項２】
前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項１に記載の通信品質測定装置。
【請求項３】
前記ログ情報を参照し、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、
前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる下りパケットを選択することを特徴とする請求項１または２に記載の通信品質測定装置。
【請求項４】
前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、
前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば１回と判定し、前記ウィンドウサイズよりも大きければ２回以上と判定することを特徴とする請求項３に記載の通信品質測定装置。
【請求項５】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項６】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項７】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項８】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項９】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間および無線エンド側固定遅延時間の片道分の和を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１０】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１１】
スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとしてFINパケットを監視することを特徴とする請求項８−１１のいずれかに記載の通信品質測定装置。
【請求項１２】
スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視することを特徴とする請求項８−１１のいずれかに記載の通信品質測定装置。
【請求項１３】
前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項１ないし１２のいずれかに記載の通信品質測定装置。
【請求項１４】
測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１に記載の通信品質測定装置。
【請求項１５】
前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１２のいずれかに記載の通信品質測定装置。
【請求項１６】
前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１２のいずれかに記載の通信品質測定装置。
【請求項１７】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１８】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１９】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットのログ情報をコネクションごとに管理し、
前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が２回以上であると、
無線エンド側の固定的な遅延時間を算出し、
サーバから無線クライアントへ一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に少なくとも無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２０】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、
前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が１回であると、
サーバエンド側の固定的な遅延時間を算出し、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２１】
前記スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されることを特徴とする請求項１９または２０に記載の通信品質測定方法。
【請求項２２】
前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１９または２０に記載の通信品質測定方法。
【請求項１】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上でパッシブに監視して通信品質を測定する通信品質測定装置において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントに到着した下りのTCPパケットをキャプチャするキャプチャ手段と、
前記キャプチャされたパケットのログ情報をコネクションおよび／またはセッションごとに管理するログ情報管理手段と、
前記ログ情報に基づいて、前記キャプチャポイントから見た各エンド側の固定的な遅延時間を算出するエンド側固定遅延算出手段と、
スループット計測用の所要時間内に通信されたデータ量に基づいて無線クライアント側のスループットを算出する通信品質算出手段とを具備し、
前記通信品質算出手段は、無線区間の影響を受けて変化する代替所要時間を下りのTCPパケットの到着時刻差で計測し、当該代替所要時間を前記エンド側の固定遅延時間で補正することで前記所要時間を算出することを特徴とする通信品質測定装置。
【請求項２】
前記エンド側固定遅延算出手段は、TCPコネクションの確立時に送受される制御パケットのキャプチャポイントへの到着時刻差に基づいて、前記各エンド側の固定遅延時間を算出することを特徴とする請求項１に記載の通信品質測定装置。
【請求項３】
前記ログ情報を参照し、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数が、１回および２回以上のいずれであるかを判定する一括送信回数判定手段をさらに具備し、
前記通信品質算出手段は、前記一括送信回数に基づいて、到着時刻を前記代替所要時間の算出に用いる下りパケットを選択することを特徴とする請求項１または２に記載の通信品質測定装置。
【請求項４】
前記一括送信回数判定手段は、前記通信開始時のウィンドウサイズを検知するウィンドウサイズ検知手段を具備し、
前記一括送信回数を、通信のデータ量が前記通信開始時のウィンドウサイズ以下であれば１回と判定し、前記ウィンドウサイズよりも大きければ２回以上と判定することを特徴とする請求項３に記載の通信品質測定装置。
【請求項５】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項６】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項７】
前記一括送信回数が２回以上と判定されたときに、
前記エンド側固定遅延算出手段は、無線エンド側およびサーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへウィンドウサイズ単位で一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを前記代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に無線エンド側固定遅延時間およびサーバエンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項８】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項９】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間および無線エンド側固定遅延時間の片道分の和を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１０】
前記一括送信回数が１回と判定されたときに、
前記エンド側固定遅延算出手段は、サーバエンド側の固定遅延時間を算出し、
前記品質算出手段は、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを前記代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から前記サーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする請求項３または４に記載の通信品質測定装置。
【請求項１１】
スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとしてFINパケットを監視することを特徴とする請求項８−１１のいずれかに記載の通信品質測定装置。
【請求項１２】
スループットの測定対象がHTTPセッションであり、前記セッションの終了時に送信されるパケットとして、次のセッションでサーバから無線クライアントへ最初に送信される下りパケットを監視することを特徴とする請求項８−１１のいずれかに記載の通信品質測定装置。
【請求項１３】
前記キャプチャ手段においてキャプチャ漏れしたパケットのログ情報を、無線クライアント側のウィンドウサイズが規則的に変化することを前提に補完するログ情報補完手段を具備したことを特徴とする請求項１ないし１２のいずれかに記載の通信品質測定装置。
【請求項１４】
測定対象がメールセッションであるとき、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１に記載の通信品質測定装置。
【請求項１５】
前記一括送信回数判定手段は、TCPウィンドウサイズの初期値、最大値および増え方を規定する情報を取得し、当該取得した情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１２のいずれかに記載の通信品質測定装置。
【請求項１６】
前記一括送信回数判定手段は、無線クライアントの種別を識別し、当該種別から識別されるTCPウィンドウサイズの初期値、最大値および増え方を規定する情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定することを特徴とする請求項３ないし１２のいずれかに記載の通信品質測定装置。
【請求項１７】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、通信開始時のウィンドウサイズ、最大値および増え方に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１８】
前記品質算出手段は、ウィンドウサイズ単位で一括送信されるパケット群の切れ目を、各パケットの到着時刻の差に基づいて識別することを特徴とする請求項１ないし４のいずれかに記載の通信品質測定装置。
【請求項１９】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットのログ情報をコネクションごとに管理し、
前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が２回以上であると、
無線エンド側の固定的な遅延時間を算出し、
サーバから無線クライアントへ一括送信される最初のパケット群の到着時刻から最後のパケット群の到着時刻までを代替所要時間として算出し、
前記最初のパケット群から最後の直前のパケット群までの総データ量を算出し、
前記総データ量を、前記代替所要時間に少なくとも無線エンド側固定遅延時間の片道分を加算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２０】
無線クライアントとサーバとの間に確立されたTCPコネクションでの通信トラヒックをネットワーク上のキャプチャポイントに設置した通信品質測定装置でパッシブに監視して通信品質を測定する通信品質測定方法において、
サーバから無線クライアントへ送信され、ネットワーク上のキャプチャポイントでキャプチャされた下りのTCPパケットの種別および到着時刻をログ情報としてコネクションごとに管理し、
前記ログ情報に基づいて、データがサーバから無線クライアントへウィンドウサイズ単位で一括送信される回数を判定し、
前記一括送信回数が１回であると、
サーバエンド側の固定的な遅延時間を算出し、
サーバから無線クライアントへセッションの確立時に送信されるパケットの到着時刻からセッションの終了時に送信されるパケットの到着時刻までを代替所要時間として算出し、
前記セッションの確立時から終了時までに通信された総データ量を算出し、
前記総データ量を、前記代替所要時間から少なくともサーバエンド側固定遅延時間の片道分を減算して得られる所要時間で除してスループットを算出することを特徴とする通信品質測定方法。
【請求項２１】
前記スループット計測がHTTPセッション単位で行われ、セッション間のthink timeがスループットの計測対象期間から除外されることを特徴とする請求項１９または２０に記載の通信品質測定方法。
【請求項２２】
前記スループット計測がメールセッション単位で行われ、セッションサイズが所定値を下回るメールセッションのセッション時間をオーバヘッド時間として記憶し、セッションサイズが所定値を上回るメールセッションについて、そのセッション時間から前記オーバヘッド時間を減じて当該セッションの所要時間とすることを特徴とする請求項１９または２０に記載の通信品質測定方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−３８７４９（Ｐ２０１３−３８７４９Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７５７７３（Ｐ２０１１−１７５７７３）
【出願日】平成２３年８月１１日（２０１１．８．１１）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月１１日（２０１１．８．１１）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]