(57)【要約】【課題】通信パケットをパッシブにキャプチャして通信パラメータを分析し、データサイズの大きなコネクションの分析結果に基づいてデータサイズの小さなコネクションのスループットを精度良く推定する。【解決手段】パケットをキャプチャするキャプチャ部１０１と、キャプチャされたパケットの属性情報、パケットサイズおよび到着時刻を、コネクション等の通信単位ごとに監視結果として管理する監視結果管理部１０２と、各パケットの監視結果に基づいて通信単位ごとに通信レートを含む通信パラメータを分析するネットワーク品質分析部１０３と、データサイズが大きい通信単位の通信レートおよびスループットを教師データとして、任意の通信単位の通信レートからスループットを推定する通信品質辞書を構築する学習部１０７と、データサイズが小さい通信単位のスループットを、その通信レートを通信品質辞書に適用して推定するユーザ品質推定部１０５とを有する。【選択図】図２
2014116840.tif 000002
【特許請求の範囲】
【請求項１】
セッションまたはコネクションを通信単位として送受されるパケットをパッシブに監視して通信品質を推定する通信品質推定装置において、
各通信単位が集約される経路に到着したパケットをキャプチャするキャプチャ手段と、
前記キャプチャされたパケットの属性情報、パケットサイズおよび到着時刻を通信単位ごとに監視結果として管理する監視結果管理手段と、
前記各パケットの監視結果に基づいて、通信単位ごとに通信レートを含む通信パラメータを分析するネットワーク品質分析手段と、
スループットがフロー制御の影響を受けにくい通信単位の通信レートおよびスループットを教師データとして、任意の通信単位の通信レートからスループットを推定する通信品質辞書を構築する学習手段と、
スループットがフロー制御の影響を受け易い通信単位の通信レートを前記通信品質辞書に適用して当該通信単位のスループットを推定する品質推定手段とを具備したことを特徴とする通信品質推定装置。
【請求項２】
前記学習手段は、データサイズが所定の閾値以上である通信単位の通信レートおよびスループットを教師データとして、任意の通信単位の通信レートからスループットを推定する通信品質辞書を構築し、
前記品質推定手段は、データサイズが前記閾値未満である通信単位の通信レートを前記通信品質辞書に適用して当該通信単位のスループットを推定することを特徴とする請求項１に記載の通信品質推定装置。
【請求項３】
前記学習手段は、スロースタートが完了したと推定されるまでの間に送受されたデータ量の積算値を判別し、データサイズが当該積算値の所定倍数以上である通信単位の通信レートから、スループットを推定する通信品質辞書を構築することを特徴とする請求項２に記載の通信品質推定装置。
【請求項４】
前記学習手段は、各通信単位において、送信ウィンドウサイズが、データ受信側から通知される広告ウィンドウサイズを初めて超えまでに送受されたデータ量の積算値を、前記スロースタートが完了するまでに送受されたデータ量の積算値と推定する請求項３に記載の通信品質推定装置。
【請求項５】
前記学習手段は、各通信単位において、送信ウィンドウサイズが、直前の値と比較して初めて減少するまでに送受されたデータ量の積算値を、前記スロースタートが完了するまでに送受されたデータ量の積算値と推定する請求項３に記載の通信品質推定装置。
【請求項６】
前記学習手段は、通信レート／スループットの時系列推移の変動幅が所定の閾値内に落ち着くまでの時間が所定の時間閾値以上である通信単位の通信レートおよびスループットを教師データとして、任意の通信単位の通信レートからスループットを推定する通信品質辞書を構築し、
前記品質推定手段は、通信レート／スループットの時系列推移の変動幅が前記閾値内に落ち着くまでの時間が所定の時間閾値未満である通信単位の通信レートを前記通信品質辞書に適用して当該通信単位のスループットを推定することを特徴とする請求項１に記載の通信品質推定装置。
【請求項７】
前記ネットワーク品質分析手段は、通信単位ごとにTCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTおよび帯域幅遅延積の少なくとも一つを通信パラメータの一つとして分析し、
前記品質推定手段によるスループットの推定結果を、前記TCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTおよび帯域幅遅延積の少なくとも一つに基づいて補正する補正手段をさらに具備したことを特徴とする請求項１ないし６のいずれかに記載の通信品質推定装置。
【請求項８】
前記ネットワーク品質分析手段は、通信単位ごとにTCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTおよび帯域幅遅延積の少なくとも一つ通信パラメータの一つとして分析し、
前記学習手段は、前記TCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTおよび帯域幅遅延積の少なくとも一つごとに通信品質辞書を構築することを特徴とする請求項１ないし６のいずれかに記載の通信品質推定装置。
【請求項９】
前記ネットワーク品質分析手段が、前記通信レートに代えて当該通信レートの微分値を分析することを特徴とする請求項１ないし８のいずれかに記載の通信品質推定装置。
【請求項１０】
前記通信レートが、通信単位の確立時刻を基準とした経過時刻ごとに分析されることを特徴とする請求項１ないし９のいずれかに記載の通信品質推定装置。
【請求項１１】
前記スループットが、通信単位の確立から終了までの間に送受された総データ量の平均値であることを特徴とする請求項１ないし１０のいずれかに記載の通信品質推定装置。
【請求項１２】
前記各通信単位の通信方式を識別する手段をさらに具備し、
前記学習手段は、通信方式ごとに固有の通信品質辞書を構築し、
前記品質推定手段は、各通信方式の通信レートを、対応する通信品質辞書に適用してスループットを推定することを特徴とする請求項１ないし１１のいずれかに記載の通信品質推定装置。
【請求項１３】
前記学習手段は、LTEに固有の通信品質辞書を構築し、
前記品質推定手段は、LTEの通信レートを前記LTEに固有の通信品質辞書に適用してスループットを推定することを特徴とする請求項１ないし１２のいずれかに記載の通信品質推定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信品質推定装置に係り、特に、通信パケットをパッシブにキャプチャして通信パラメータを分析し、データサイズの大きなセッション等の分析結果に基づいてデータサイズの小さなセッション等のスループットを推定する通信品質推定装置に関する。
【背景技術】
【０００２】
無線通信システムの通信事業者には、広域なサービスエリアの全域で通信品質情報を局所領域ごとに取得してエリアマップを作成し、サービスエリア全体の通信品質状態を漏れなく評価することが要求される。
【０００３】
特許文献１には、ネットワークヘかかる負荷を小さく抑え、かつ少ない計算量でTCP品質を推定すべく、パケット通信網を介して接続された２つの品質測定装置間で、一方の品質測定装置から他方の品質測定装置に向けて測定パケットを送信し、他方は、これに対応する測定パケットを一方の品質測定装置へ返送し、一方の品質測定装置は返送された測定パケットの受信状況に基いて品質測定装置間のTCPスループット、再送発生率、平均パケット往復遅延、タイムアウト再送が発生する確率をアクティブに推定する技術が開示されている。
【０００４】
特許文献２には、帯域が複数の端末やコネクションにより共有される通信回線の伝送帯域に基づいて、TCPコネクションの平均スループットを算出する技術が開示されている。
【０００５】
特許文献３には、パケット通信網を介して接続された２つの品質測定装置間で、一方の品質測定装置から一定間隔で間欠的に測定パケットを他方の品質測定装置へ送出し、各品質測定装置で送受信された測定パケットに関する送受信状況に基づいて当該測定パケットに関する通信品質をアクティブに計測する技術が開示されている。
【０００６】
特許文献４には、通信品質管理装置が各無線基地局から、携帯情報端末の現在位置における無線回線の品質情報、無線基地局の無線回線のリソース情報、無線基地局のネットワーク回線の使用情報を収集し、各位置における通信品質を判定し、判定した通信品質を位置情報に対応付けた通信品質マップ情報を作成する技術が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【特許文献２】特開２００３−２０９５７４号公報
【特許文献３】特開２００４−７３３９号公報
【特許文献４】特開２０１０−６２７８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１，３は、計測用の専用パケットを送受するアクティブ方式であるため、品質計測に際して余計なトラヒックや負荷が発生し、また計測範囲を拡げようとすれば多数の品質測定装置を設けなければならないなど、スケーラビリティの問題が生じる。特許文献２では、通信回線の品質が計測されるのみで、クライアントユーザの体感品質を計測できない。
【０００９】
特許文献４では、通信品質情報管理装置が能動的に動作し、無線基地局やパケット交換装置に対して通信品質の測定および通知を要求しなければならないので、要求対象の装置数が大量になるとスケーラビリティの問題がある。また、通信品質の監視が管理装置側からの要求により追加的な処理として行われるので、測定に伴って処理負荷やトラヒックが増加するという問題もある。
【００１０】
本発明の目的は、従来技術の課題を全て解決し、通信パケットをパッシブにキャプチャして通信パラメータを分析し、データサイズが大きくてフロー制御の影響を受けにくいセッション等の分析結果に基づき、データサイズが小さくてフロー制御の影響を受けやすいセッション等のスループットを、高い精度で推定できる通信品質推定装置を提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するために、本発明は、セッションまたはコネクションを通信単位として送受されるパケットをパッシブに監視して通信品質を推定する通信品質推定装置において、以下のような手段を講じた点に特徴がある。
【００１２】
(1)各通信単位が集約される経路上でキャプチャされたパケットの属性情報、パケットサイズおよび到着時刻を通信単位ごとに監視結果として管理する監視結果管理手段と、各パケットの監視結果に基づいて、通信単位ごとに通信レートを含む通信パラメータを分析するネットワーク品質分析手段と、スループットがフロー制御の影響を受けにくい通信単位の通信レートおよびスループットを教師データとして、任意の通信単位の通信レートからスループットを推定する通信品質辞書を構築する学習手段と、スループットがフロー制御の影響を受け易い通信単位のスループットを、当該通信単位の通信レートを前記通信品質辞書に適用して推定するスループット推定手段とを具備した。
【００１３】
(2)通信単位ごとにTCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTあるいは帯域幅遅延積を通信パラメータの一つとして算出し、スループットの推定結果を、これらのパラメータに基づいて補正し、あるいはパラメータの区分毎に通信品質辞書を構築するようにした。
【発明の効果】
【００１４】
本発明によれば、以下のような効果が達成される。
【００１５】
(1)データサイズが大きいために、通信開始直後のスロースタートの影響がスループットに影響しにくいコネクションを対象に、その通信レートとスループットとの関係を予め学習してモデル化し、データサイズが小さいために、そのスループットを通信レートに基づいて求めてしまうとスロースタートの影響で低めに算出されてしまうコネクションのスループットを、前記学習モデルに通信レートを適用することで推定できるので、データサイズが小さいコネクション等のスループットを精度良く推定できるようになる。
【００１６】
(2)TCPコネクションまたはセッションに関するスループットの推定結果を、TCPの初期ウィンドウサイズ、広告ウィンドウサイズ、ウィンドウサイズの時系列推移、RTTあるいは帯域幅遅延積に基づいて補正するようにしたので、スループットの推定結果に対するTCPフロー制御の影響を排し、例えば初期ウィンドウサイズの小さいコネクションのスループットが大きいコネクションに較べて低目に推定される精度低下を改善できるようになる。
【図面の簡単な説明】
【００１７】
【図１】本発明の通信品質測定方法が適用されるネットワークのブロック図である。
【図２】キャプチャ装置の構成を示した機能ブロック図である。
【図３】本発明の一実施形態の動作を示したフローチャートである。
【図４】TCPコネクションテーブルの内容を模式的に表現した図である。
【図５】TCPコネクションの遅延特性を測定する方法を示したシーケンスフローである。
【図６】HTTPセッションにおけるエンドサーバのレスポンス特性を測定する方法を示したシーケンスフローである。
【図７】HTTPセッションごとに特性を分析する方法を示したシーケンスフローである。
【図８】通信品質辞書の構築手順を示したフローチャートである。
【図９】通信品質辞書を利用したスループットの推定手順を示したフローチャートである。
【図１０】スループットの推定結果を初期ウィンドウサイズに応じて補正する必要性を示した図である。
【図１１】データサイズとスループットとの関係を示した図である。
【図１２】本発明によるスループットの推定メカニズムを表現した図である。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施形態について詳細に説明する。ここでは、初めに本発明の概要について説明し、次いで、その詳細について具体的に説明する。
【００１９】
TCPにおけるフロー制御のように、ネットワーク品質とは別にプロトコル上の仕様、制約から帯域が一時的に制限され、これが原因で見かけ上の通信レートやスループットが低下する場合がある。例えばTCPのスロースタートアルゴリズムでは、コネクションの確立直後はウィンドウサイズを小さくすることで通信レートが低く抑えられ、その後、ネットワークの実品質に応じてウィンドウサイズを漸増させることで徐々に通信レートが上昇する。したがって、図１１(a)に示したように、TCPコネクションで転送されるデータサイズが十分に大きく、スロースタートが終了してウィンドウサイズがネットワークの実品質に応じたサイズまで拡大された時刻t1以降の通信期間が十分に長ければ、当該期間の通信レートの平均値AVEに基づいてスループットを十分な精度で求められる。
【００２０】
これに対して、データサイズが小さいために、同図(b)に示したように、ウィンドウサイズがネットワークの実品質に応じたサイズまで拡大されるよりも前の時刻t2で通信が完了したり、あるいは同図(c)に示したように、ウィンドウサイズがネットワークの実品質に応じたサイズまで拡大された時刻t3以降の通信期間が短かったりすると、スループットを通信レートの平均値として求めることができない。
【００２１】
一方、コネクションやセッションが確立された以降の通信レートの時系列は、初期ウィンドウサイズやRTTの影響を多少受けるものの、ウィンドウサイズがネットワークの実品質に応じたサイズまで拡大された以降の通信レートと強い相関のあることが発明者等の観察により確認されている。
【００２２】
そこで、本発明ではデータサイズが大きなコネクションやセッションにおける通信レートの時系列とスループットとの関係を予め学習して通信品質辞書を構築し、その後、データサイズが大きくないコネクションやセッションに関しては、図１２(a)，(b)に示したように、そのセッション等の開始直後からの通信レートの変化をパラメータとして前記通信品質辞書を逆引きすることにより、その通信レートやスループットを推定している。
【００２３】
図１は、本発明の通信品質推定方法が適用されるネットワークの構成を示したブロック図であり、サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線移動端末MN）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。
【００２４】
前記インターネットには、クライアントからの要求に応答してサービスを提供する各種のサーバが接続されている。本実施形態では、各端末MN（アクセス）と各サーバ（エンド）との間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信品質測定装置としてのキャプチャ装置１が接続されている。
【００２５】
図２は、前記キャプチャ装置１の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。
【００２６】
パケットキャプチャ部１０１は、前記回線L上のTCPコネクション（HTTPセッションを含む）からIPパケットをキャプチャする。監視結果管理部１０２は、キャプチャされたパケットをTCPコネクションやHTTPセッションといった所定の通信単位ごとに管理するテーブル（ここでは、TCPコネクションテーブル）１０２ａを含む。
【００２７】
ネットワーク(NW)品質分析部１０３は、通信レート計測部１０３ａ、ウィンドウサイズ検知部１０３ｂ、データ積算量算出部１０３ｃおよびRTT計測部１０３ｄを含む各種の分析手段を備えている。分析結果データベース１０４には、通信単位（ここでは、TCPコネクション）ごとに監視結果が保持される。
【００２８】
学習部１０７は、前記分析結果データベース１０４を参照し、データサイズが所定のサイズ閾値以上であるためにスループットがTCPフロー制御の影響を受け難い通信に関して、その分析結果を教師データとして学習モデルを構築する。本実施形態では、TCPコネクション（または、HTTPセッション）の確立時刻を基準として、通信レート、ウィンドウサイズ、転送データの積算量、RTTなどを経過時間ごとに記録し、さらには各セッションを時間帯や曜日等で分類し、コネクション等の確立から終了までに観測された平均スループットと紐付けることで、任意のコネクション等の通信レート等に基づいて、そのスループットを推定する通信品質辞書１０７ａを構築する。
【００２９】
ユーザ品質推定部１０５は、キャプチャされたパケットの分析結果（通信レートの時系列）をキーに前記通信品質辞書１０７ａを逆引きすることでスループットを推定する分類部１０５ａを含み、データサイズが所定のサイズ閾値以上の通信については、その通信レートの平均値に基づいてスループットを算出する一方、データサイズが所定のサイズ閾値未満の通信に対しては、そのコネクション確立から一定期間またはセッション終了までの間に観測された通信レートの時系列を前記通信品質辞書に適用することでスループットを推定する。結果出力部１０６は、前記スループットの算出または推定結果を出力する。
【００３０】
なお、スループットがTCPフロー制御の影響を受け易いか否かは、通信のデータサイズのみに依存するものではなく、通信レートとスループットとの比（通信レート／スループット）の時系列推移の変動幅が落ち着くまでの時間にも依存する。すなわち、通信レート／スループットの時系列推移の変動幅は、通信レート／スループットの時間的な傾き（微分あるいは差分であるデルタΔ成分）なので、これが落ち着くということはスロースタートの影響が小さくなったことを意味する。
【００３１】
したがって、上記のようなデータサイズによる選別に代えて、通信レート／スループットの時系列推移の変動幅が所定の閾値内に落ち着くまでの時間が所定の時間閾値以上の通信を教師データとして通信品質辞書を構築し、通信レート／スループットの時系列推移の変動幅が所定内に落ち着くまでの時間が所定の時間閾値未満の通信について、その通信レートを前記通信品質辞書に適用してスループットを推定するようにしても良い。
【００３２】
次いで、図３のフローチャートを参照して、前記キャプチャ装置１の動作を詳細に説明する。なお、図３のフローチャートは、主に監視結果管理部１０２の動作を示しており、所定の周期で繰り返し実行される。
【００３３】
ステップＳ１では、キャプチャ装置１の接続された集約リンクLに到着したパケットが、前記パケットキャプチャ部１０１によりキャプチャされる。ステップＳ２では、前記キャプチャされたパケットの送信元IPアドレスsrcIPおよびそのTCPポート番号srcPort、さらには必要に応じて、宛先IPアドレスdstIPおよびそのTCPポート番号dstPortならびにプロトコル番号が、各パケットを識別するためのキーとして抽出される。なお、識別キーとして採用する情報は上記に限定されるものではなく、クライアント（ユーザ）やその通信（コネクションまたはセッション）を一意に識別できる情報であれば、例えばHTTPにおけるユーザIDを識別キーとして採用しても良い。
【００３４】
ステップＳ３では、前記キャプチャされたパケットのキーと同一キーのレコードが前記TCPコネクションテーブル１０２ａに既登録であるか否かが判定される。本実施形態では、図４に一例を示したように、監視対象のパケットについて、その種別(SYN，SYN+ACK，ACK，Dataなど)、到着時刻t、位置情報P，方向（上り下りの別）、パケットサイズ、シーケンス番号などの属性情報が、前記キーをインデックスとしてコネクションごとにレコード形式で記録されている。
【００３５】
キャプチャの開始直後であれば未登録と判定されるのでステップＳ４へ進み、所定の乱数R(0<R<1.0)が発生される。ステップＳ５では、パケットをキャプチャして記録・解析する頻度として予め設定されているサンプリング比率Rsamplingが前記乱数Rと比較され、R≦Rsamplingであれば、今回のパケットが監視対象と判定されてステップＳ６へ進む。ステップＳ６では、前記キャプチャされたパケットの属性情報が、前記キーをインデックスとするレコード方式でTCPコネクションテーブル１０２ａに新規記録される。なお、前記ステップＳ５において、R＞Rsamplingと判定されたパケットは、ステップＳ１２において破棄される。
【００３６】
一方、前記ステップＳ３において、前記キャプチャされたパケットの識別キーと同一キーのレコードがTCPコネクションテーブル１０２ａに既登録と判定されるとステップＳ６へジャンプし、当該パケットに関するレコードが前記TCPコネクションテーブル１０２ａに追加登録される。ステップＳ７では、前記パケットがTCPコネクションの切断要求(FIN)または強制切断(RST)であるか否かが判定される。初めは、FINおよびRSTのいずれでもないと判定されるのでステップＳ９へ進む。なお、前記FINやRSTの代わりにTCPタイムアウト(TO)を検知するようにしても良い。その後、FINまたはRSTパケットがキャプチャされると、当該処理はステップＳ７からＳ８へ進み、当該コネクションで記録されたレコードに終了フラグFendがセットされる。
【００３７】
ステップＳ９では、Fend=1のレコードの有無、すなわち新たに切断されたコネクションの有無が判定される。このようなレコードが存在すればステップＳ１０へ進み、当該レコードが通信ログとしてNW品質分析部１０３へ提供される。ステップＳ１１では、前記NW品質分析部１０３へ提供された全てのレコードがTCPコネクションテーブル１０２ａから破棄される。前記NW品質分析部１０３では、前記TCPコネクション管理部１０２から提供された通信ログを分析して、エンド-エンドの通信品質が算出される。この算出結果は分析結果データベース１０４に通知されて保持される。
【００３８】
図５は、前記NW品質分析部１０３による分析方法を説明するための図である。ここでは、TCPコネクションの確立時にクライアント／サーバ間で実行されるTCP_3wayハンドシェークのSYNパケットからキャプチャできたコネクションについて、遅延特性を測定する方法について説明する。
【００３９】
この場合、端末MNからサーバへ最初に送信されたSYNパケットの到着時刻t1と、サーバから端末MNへ返信されたSYN+ACKパケットの到着時刻t2との差分(t2-t1)に基づいてサーバ側RTT（往復）遅延が算出される。また、前記SYN+ACKパケットの到着時刻t2と端末MNからサーバへ最後に送信されたACKパケットの到着時刻t3との差分(t3-t2)に基づいて、クライアント側RTT遅延が算出される。
【００４０】
さらに、前記最初のSYNパケットの到着時刻t1と前記3wayハンドシェーク後に端末MNからサーバへ最初に送信されデータパケットの到着時刻t4との差分(t4-t1)に基づいて、TCP接続所要時間が算出される。さらに、3wayハンドシェーク後に端末MNから最初に送信されるデータの到着時刻t1からFINまたはRSTパケットの到着時刻t5までの差分(t5-t1)、および当該差分時間内にキャプチャされた送受信データ量に基づいて、TCPコネクションのスループット特性が算出される。
【００４１】
なお、パケットのキャプチャがコネクションの途中から開始されているような場合には、得られた到着時刻から可能な分析のみが選択的に行われる。すなわち、キャプチャがSYN+ACKパケットから開始されていれば、その到着時刻t2からACKパケットの到着時刻t3までの差分(t3-t2)に基づいて、クライアント側RTT遅延のみが算出される。
【００４２】
また、前記TCPコネクションのスループット特性やTCP接続所要時間は、クライアント側の遅延のみならずサーバ側の遅延にも依存するので、サーバ側遅延が大きいときに算出されたこれらの特性等は、クライアント側の位置ベースに基づく通信品質を正確に代表できない。したがって、前記サーバ側RTT遅延が所定の閾値を超えているとき、あるいはサーバ側遅延を代表できるデータやACKなどのパケット到着間隔が所定の閾値を越えているときに算出されたスループット特性やTCP接続所要時間は、品質分析の対象から除外することが望ましい。
【００４３】
図６は、HTTPセッションにおけるエンドサーバのレスポンス特性の算出方法を示した図である。端末MNから送信されたHTTP要求を受信したプロキシサーバは、エンドサーバとの間で3wayハンドシェークにより接続処理を実行する。次いで、HTTP要求の送信およびHTTP応答の受信を繰り返し、サーバとの接続切断後に、前記端末HMへHTTP応答を返信する。なお、図６の構成は、図１のGWにおいてTCPコネクションを終端させ、当該GWをプロキシとして機能させることでも実現できる。
【００４４】
この場合、前記図５で算出されるクライアント側RTT遅延（無線区間およびRANの遅延）やサーバ側RTT遅延に加えて、さらに端末MNからサーバへ送信されたHTTP要求の到着時刻t4とプロキシサーバから端末MNへ返信されたHTTP応答の到着時刻t5との差分(t5-t4)に基づいて、クライアント側で体感されるエンドサーバの応答時間を算出できる。
【００４５】
図７は、HTTPセッションごとに特性を分析する方法を示した図である。複数のHTTPセッションが順次に確立されるコネクションでは、分析がHTTPセッションごとに行われ、一番目のHTTPセッションに関しては、端末MNが最初に送信するHTTP Req1-1の到着時刻t31から、サーバが最後に送信するHTTP Rep1-3の到着時刻t32までが一番目のHTTPセッションの所要時間とされ、その間に送受されたデータ量が当該HTTPセッションでの通信量とされる。
【００４６】
同様に、二番目のHTTPセッションに関しても、端末MNが最初に送信するHTTP Req2-1の到着時刻t33から、サーバが最後に送信するHTTP Rep2-1の到着時刻t34までが二番目のHTTPセッションの所要時間とされ、その間に送受されたデータ量が当該HTTPセッションでの通信量とされる。
【００４７】
このように、所要時間およびデータ量がセッションごとに求まれば、データ量を所要時間で除することで、HTTPセッションごとにスループットを算出できるようになる。
【００４８】
図８は、前記学習部１０７による通信品質辞書１０７ａの構築手順を示したフローチャートであり、ステップＳ３１では、前記分析結果データベース１０４から、データサイズが所定のサイズ閾値を上回るコネクションが選択され、その分析結果が取り込まれる。
【００４９】
前記サイズ閾値は、全てのコネクションに共通の値とするのではなく、コネクションごとに異ならせることが望ましい。例えば、サイズ閾値は各コネクションにおいてスロースタートが完了するまでに送受されたデータ量の積算値の所定倍数（例えば、１０倍）とすることができる。
【００５０】
この場合、各コネクションの送信ウィンドウサイズが、データ受信側から通知される広告ウィンドウサイズを初めて超えまでに送受されたデータ量の積算値を、スロースタートが完了するまでに送受されたデータ量の積算値と推定できる。あるいは、当該コネクションの送信ウィンドウサイズが、直前の値と比較して初めて減少するまでに送受信されたデータ量の積算値を、スロースタートが完了するまでに送受されたデータ量の積算値と推定しても良い。さらに、データサイズの閾値に加えて、保留時間TMが所定の時間閾値を下回るコネクションが選択されるようにしても良い。
【００５１】
ステップＳ３２では、前記選択された各コネクションのスループットならびに各コネクションの確立時刻を基準にした経過時間毎の通信レートおよび積算データ量を教師データとして、任意のコネクションの確立時刻を基準にした経過時間毎の通信レートおよび積算データ量の入力に対して当該コネクションのスループットを推定する学習モデルが構築される。ステップＳ３３では、前記学習モデルが通信品質辞書１０７ａとして登録される。
【００５２】
図９は、前記ユーザ品質推定部１０５によるスループットの推定手順を示したフローチャートであり、ステップＳ４１では、前記分析結果データベース１０４から今回の注目コネクションについて、その分析結果が読み込まれる。ステップＳ４２では、注目コネクションのスループットが推定対象であるか否かが判定される。本実施形態では、データサイズが所定のサイズ閾値を下回るコネクションがスループットの推定対象とされる。
【００５３】
推定対象であればステップＳ４３へ進み、当該コネクションの確立時刻を基準にした経過時間毎の通信レートおよび積算データ量が前記通信品質辞書１０７ａに適用されてスループットが推定される。これに対して、推定対象でなければステップＳ４４へ進み、当該コネクションの分析結果に基づいて、そのスループットが算出される。本実施形態では、コネクション確立後の通信レートの平均値がスループットとして算出される。
【００５４】
ステップＳ４５では、前記スループットの推定結果または算出結果が出力される。ステップＳ４６では、全ての分析結果についてスループットの推定／算出が完了したか否かが判定される。完了していなければステップＳ４１へ戻り、次の分析結果を対象に上記と同様の処理が実行される。
【００５５】
本実施形態によれば、データサイズが大きいために、通信開始直後のスロースタートの影響がスループットに影響しにくいコネクションを対象に通信レートとスループットとの関係を予め学習してモデル化し、データサイズが小さいために、そのスループットを通信レートから求めてしまうとスロースタートの影響で低めに算出されてしまうコネクションのスループットを、前記学習モデルに通信レートを適用することで推定できるので、データサイズが小さいコネクション等のスループットを精度良く推定できるようになる。
【００５６】
なお、上記の実施形態では、一つの通信品質辞書１０７ａが全てのコネクションのスループット推定に共用されるものとして説明したが、本発明はこれのみに限定されるものではない。すなわち、各コネクションのパケットがキャプチャされた時間帯や曜日、また各パケットに無線移動端末MNの位置情報が記述されている場合には更に当該位置情報ごとに各コネクションを分類し、この分類結果ごとに通信品質辞書１０７ａを構築しても良い。このようにすれば、推定対象のコネクションがキャプチャされた時間帯、曜日、位置情報に応じて最適な通信品質辞書を用いてスループットを推定できるので、その精度を向上させることが可能になる。
【００５７】
また、HTTPではブラウザがサーバへ通知するUserAgentにハードウェア情報、携帯キャリア名、ホストOS名、アプリケーション名等の端末情報が含まれ、HTTPのリクエストパスやURIに無線通信方式を判別する情報などが載っている場合もある。したがって、これらの情報に基づいてクライアント端末を識別し、例えば通信方式としてEV-DOやLTEしか利用しない端末の分析結果のみを教師データとするようにしても良い。
【００５８】
例えば、LTEは一般的に、EV-DOなど他の通信方式に較べて通信レートが高いので、UserAgentやURIなどから判別したLTE通信時の分析結果のみを教師データとすることにより、通信レート／スループットの推定を更に高精度化できると共に、通信の潜在的な能力を推定できるようになる。
【００５９】
したがって、前記通信品質辞書１０７ａを通信方式ごとに構築し、通信方式の判別結果に応じて通信品質辞書１０７ａを切り替えるようにしても良いし、あるいはLTEに固有の通信品質辞書１０７ａのみを構築し、LTE通信時の分析結果のみを通信品質辞書１０７ａに適用してスループットを推定するようにしても良い。
【００６０】
さらに、コネクションの確立時刻を基準にした経過時間毎の通信レートや積算データ量は、ネットワーク環境のみならずTCPの初期ウィンドウサイズやRTTにも依存する。図１０は、同一のネットワーク環境において、初期ウィンドウサイズが小さい場合[実線A]と大きい場合[実線B]との通信レートを比較した図であり、初期ウィンドウサイズが大きい場合は小さい場合に較べてスープットの上昇率が高くなる。したがって、初期ウィンドウサイズが考慮されないと、同一のネットワーク環境であっても初期ウィンドウサイズが大きなコネクションは小さなコネクションに較べてスループットの推定結果が高くなる傾向にある。
【００６１】
そこで、予めTCPの初期ウィンドウサイズとスループットとの関係を統計的に分析し、観測された初期ウィンドウサイズに応じた補正係数をスループットの推定結果に乗じるようにしても良い。あるいは、初期ウィンドウサイズ毎に教師データを作成するようにしても良い。また、初期ウィンドウサイズに代えて、ウィンドウサイズの時系列推移や広告ウィンドウサイズの値に応じて補正係数を乗じたり、教師データを作成したりするようにしても良いし、これらを組み合わせても良い。
【００６２】
同様に、RTTはネットワーク環境のみならず通信方式にも依存し、RTTが小さい通信方式は大きい通信方式に場合に較べてスープットが高くなる。したがって、RTTが考慮されないと、同一のネットワーク環境であってもRTTの小さなコネクションは大きなコネクションに較べてスループットの推定結果が高くなる傾向にある。そこで、予めRTTとスループットとの関係を統計的に分析し、観測されたRTTに応じた補正係数をスループットの推定結果に乗じるようにしても良い。また、RTTの区分毎に教師データを作成するようにしても良い。
【００６３】
さらに、帯域と遅延時間との積として求まる帯域幅遅延積も、前記RTTと同様にスループットの推定結果に影響し、帯域幅遅延積が大きいネットワークや回線では、回線上に流れている（TCPでは、ACK待ちの状態）パケット・データが多くなる。したがって、前記RTTに代えて、あるいは前記RTTと共に帯域幅遅延積も求め、帯域幅遅延積に応じて補正係数を乗じたり、教師データを作成したりするようにしても良い。
【００６４】
なお、上記に実施形態では、通信レートの時系列とスループットとの関係を予め学習するものとして説明したが、本発明はこれのみに限定されるものではなく、通信レートの時系列に代えて、通信レートの傾きや微分値の時系列推移、分布、統計量とスループットとの関係を予め学習するようにしても良い。
【符号の説明】
【００６５】
１０１…パケットキャプチャ部，１０２…TCPコネクション管理部，１０２ａ…TCPコネクションテーブル，１０３…ネットワーク(NW)品質分析部，１０４…分析結果データベース，１０５…ユーザ品質推定部，１０６…結果出力部，１０７…学習部，１０７ａ…通信品質辞書
【図１】
2014116840.tif 000003
【図２】
2014116840.tif 000004
【図３】
2014116840.tif 000005
【図４】
2014116840.tif 000006
【図５】
2014116840.tif 000007
【図６】
2014116840.tif 000008
【図７】
2014116840.tif 000009
【図８】
2014116840.tif 000010
【図９】
2014116840.tif 000011
【図１０】
2014116840.tif 000012
【図１１】
2014116840.tif 000013
【図１２】
2014116840.tif 000014