JP2014107825A - 通信路識別装置 - Google Patents

Abstract

【課題】ネットワーク上の一箇所でパケットをキャプチャするのみで各パケットの通信路を識別し、各通信路をその識別結果に応じた固有の基準で評価できるようにする。
【解決手段】パケットキャプチャ部１０１はIPパケットをキャプチャする。監視結果管理部１０２は、キャプチャされたパケットをTCPコネクションやHTTPセッションといった所定の通信単位ごとに管理するTCPコネクションテーブル１０２ａを含む。品質パラメータ分析部１０３は、通信品質を代表するパラメータの確率分布等の統計値として出力する分析部１０３ａ〜１０３ｅを含む。学習部１０７は、通信路が既知であるパケットの品質パラメータに基づいて学習モデル（通信路辞書１０７ａ）を構築する。通信路推定部１０５は、キャプチャされたパケットの通信品質に関する各統計値をキーに通信路辞書１０７ａを逆引きすることで当該パケットの通信路を推定する。
【選択図】図２

Description

本発明は、通信路識別装置に係り、特に、セッションまたはコネクションを通信単位として送受されるパケットをパッシブに監視し、各パケットが経由するネットワークや通信回線を識別する通信路識別装置に関する。

無線通信システムの通信事業者には、広域なサービスエリアの全域で通信品質情報を局所領域ごとに取得してエリアマップを作成し、サービスエリア全体の通信品質状態を漏れなく評価することが要求される。

特許文献１には、通信品質管理装置が各無線基地局から、携帯情報端末の現在位置における無線回線の品質情報、無線基地局の無線回線のリソース情報、無線基地局のネットワーク回線の使用情報を収集し、各位置における通信品質を判定し、判定した通信品質を位置情報に対応付けた通信品質マップ情報を作成する技術が開示されている。

特許文献２には、移動体端末が、通信の際の位置情報や品質情報を、通常の通信情報に付加して基地局に通知することによって、通信品質と位置情報とを紐付けて管理するシステムが開示されている。

特許文献３には、パケット通信網を介して接続された２つの品質測定装置間で、一方の品質測定装置から一定間隔で間欠的に測定パケットを他方の品質測定装置へ送出し、各品質測定装置で送受信された測定パケットに関する送受信状況に基づいて当該測定パケットに関する通信品質をアクティブに計測する技術が開示されている。

特許文献４には、OverlayNWでのトラヒックを監視して、利用帯域やパケロス、遅延などを計測することにより、UnderlayNWである実際の物理NWの障害検知を行うシステムが開示されている。

しかしながら、上記の従来技術はいずれも、計測用の専用パケットを送受するアクティブ方式であるため、品質計測に際して余計なトラヒックや負荷が発生し、また計測範囲を拡げようとすれば多数の品質測定装置を設けなければならないなど、スケーラビリティの問題が生じる。

このような技術課題に対して、本発明の発明者等は、監視対象の通信トラヒックが集約される経路上でパケットをパッシブに測定し、パケットの種別や到着時刻に基づいてネットワークや通信回線の品質をスケーラブルに分析できる通信品質測定方法および装置を発明し、特許出願（特許文献５）した。

特開２０１０−６２７８３号公報 特開２００９−１６９４８号公報 特開２００４−７３３９号公報 特開２０１０−８８０３１号公報 特願２０１１−５３３７９号

特許文献５で計測されるRTTやスループット等の通信品質パラメータは、ネットワークや通信回線（以下、通信路で総称する）の品質を評価するための指標として広く用いられている。しかしながら、キャプチャされるIPパケットが多種多様な通信路を経由する環境下では、通信品質パラメータのみで各通信路を正当に評価することは難しい。

例えば、3G携帯（EV-DOやHSPA等）では、アクセス回線側RTT遅延が１５０〜２００msec、スループットは300kbpsから最大で3〜5Mbpsであるのに対して、3.9G携帯（LTE）やWiMAX（登録商標）では、アクセス回線側RTT遅延が１０〜５０msec、スループットは1Mbpsから最大で30〜40Mbpsにも達する。

しかしながら、特許文献５によりキャプチャされるIPパケットからは通信路までは識別できない。したがって、例えばスループットの計測結果として3Mbpsが得られても、これが3G携帯であれば十分な通信品質と評価できる一方、LTEであれば十分な通信品質とは評価できない。

このように、通信路の品質は、パケットが経由する通信路あるいは通信方式ごとに異なる基準で評価する必要があるにもかかわらず、従来技術では、パケットが経由する通信路を識別できず、全ての通信路が同じ基準で評価されていたので、各通信路を正当に評価することが困難であった。

本発明の目的は、上記した従来技術の課題を解決し、ネットワーク上の一箇所でパケットをキャプチャするのみで各パケットの通信路を識別し、各通信路をその識別結果に応じた固有の基準で評価できるようにした通信路識別装置を提供することにある。

上記の目的を達成するために、本発明は、セッションまたはコネクションを通信単位として送受されるパケットをパッシブに監視し、各パケットが経由する通信路を識別する通信路識別装置において、以下のような構成を具備した点に特徴がある。

(1)各通信単位が集約される経路に到着したパケットをキャプチャするキャプチャ手段と、キャプチャされたパケットの品質パラメータを記録する手段と、通信単位ごとに各品質パラメータを分析し、その統計値を出力する分析手段と、既知の通信路とその品質パラメータの統計値との関係を学習し、通信路が未知の品質パラメータの統計値に基づいて当該通信路を予測する通信路推定部とを具備した。

(2)キャプチャされたパケットの通信路を判別する手段をさらに具備し、予測モデルは、通信路を判別できたパケットの品質パラメータを分析して得られる統計値と当該通信路の判別結果とを教師データとして学習するようにした。

本発明によれば、以下のような効果が達成される。

(1)通信路が既知であるパケットから分析される品質パラメータを教師データとして通信路辞書が構築され、通信路が未知のパケットから分析される品質パラメータを前記通信路辞書に適用することにより、その通信路を識別できるようになるので、各通信路の品質を品質パラメータに基づいて正当に評価できるようになる。

(2)キャプチャされたパケットの通信路を判別し、判別できた通信路の品質パラメータを分析して教師データとして学習できるので、教師データを別途に用意して予め学習させる労力が不要になる。

本発明の通信路識別装置が適用されるネットワークのブロック図である。 キャプチャ装置の構成を示した機能ブロック図である。 品質パラメータを分析して得られる統計値の一例を示した図である。 本発明の一実施形態の動作を示したフローチャートである。 TCPコネクションテーブルの内容を模式的に表現した図である。 TCPコネクションの遅延特性を測定する方法を示したシーケンスフローである。 HTTPセッションにおけるエンドサーバのレスポンス特性を測定する方法を示したシーケンスフローである。 スループットの推定結果を初期ウィンドウサイズに応じて補正する必要性を示した図である。 通信路推定部による通信路の推定方法を示したフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。図１は、本発明の通信路識別装置が適用されるネットワークの構成を示したブロック図である。

サービス提供範囲の各エリアには無線基地局BSが設置され、当該エリア内のクライアント（本実施形態では、無線端末MN）は前記各無線基地局BSに収容される。各無線基地局BSは無線アクセス網RANに接続され、前記無線アクセス網RANはコア網のゲートウェイ(GW)に接続される。前記コア網はインターネットエクスチェンジ(IX)においてインターネットと接続される。

インターネットには、無線端末MNからの要求に応じてサービスを提供する各種のサーバが接続されている。本実施形態では、各端末MN（アクセス）と各サーバ（エンド）との間のトラヒックを集約できる回線として、無線アクセス網RANとコア網とを接続する回線Lに、通信路識別装置としてのキャプチャ装置１が接続されている。

図２は、前記キャプチャ装置１の主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。

パケットキャプチャ部１０１は、回線L上のTCPコネクション（HTTPセッションを含む）のIPパケットをキャプチャする。通信路判別部１０８は、例えばブラウザがサーバへUserAgentを通知する場合には、当該UserAgentに含まれるハードウェア情報、携帯キャリア名、ホストOS名、アプリケーション名等の端末情報に基づいて通信路を判別する。

監視結果管理部１０２は、キャプチャされたパケットをTCPコネクションやHTTPセッションといった所定の通信単位ごとに管理するテーブル（ここでは、TCPコネクションテーブル）１０２ａを含む。

品質パラメータ分析部１０３は、通信品質を代表するパラメータとして、スループット、アクセス回線側RTT遅延、サーバ側RTT遅延、パケットロス率（再送率）およびデータサイズ等を、各パケットの到着時刻やパケットサイズに基づいて計測、分析し、既知の統計的処理により確率分布等の統計値として出力する分析部１０３ａ〜１０３ｅを含む。

図３は、前記各分析部１０３ａ〜１０３ｅによる分析結果の一例を示した図であり、同図(a)は、前記スループット分析部１０３ａにより得られるスループットの確率分布の一例を示しており、通信路Aおよび通信路Bが異なる確率分布を示していることが判る。

同様に、同図(b)は前記アクセス回線側RTT分析部１０３ｂにより得られるアクセス回線側RTT遅延の確率分布を示しており、同図(c)は、前記サーバ側RTT分析部１０３ｃにより得られるサーバ側RTT遅延の確率分布を示しており、同図(d)は、前記パケットロス率（再送率）分析部１０３ｄにより得られるパケットロス率（再送率）の確率分布を示している。各分析結果は、通信単位（ここでは、TCPコネクション）ごとに分析結果DB１０４に保持される。

学習部１０７は、通信路が既知であるパケットの品質パラメータに基づいて学習モデルを構築する。本実施形態では、前記通信路判別部１０８により通信路が判別されたパケットについて、そのスループット、アクセス回線側RTT遅延、サーバ側RTT遅延、パケットロス率（再送率）およびデータサイズ等の品質パラメータを、前記通信路の判別結果をラベルとする教師データとして、通信路が未知であるパケットの品質パラメータに基づいて当該通信路を推定するための通信路辞書１０７ａが構築される。

通信路推定部１０５は、キャプチャされたパケットのうち、前記通信路判別部１０８により通信路を判別できなかったパケットの通信品質に関する各統計値をキーに前記通信路辞書１０７ａを逆引きすることで当該パケットの通信路を推定する。推定結果出力部１０６は、前記通信路の推定結果を出力する。

次いで、図４のフローチャートを参照して、前記キャプチャ装置１の動作を詳細に説明する。なお、図４のフローチャートは、主に監視結果管理部１０２の動作を示しており、所定の周期で繰り返し実行される。

ステップＳ１では、キャプチャ装置１の接続された集約リンクLに到着したパケットが、前記パケットキャプチャ部１０１によりキャプチャされる。ステップＳ２では、前記キャプチャされたパケットの送信元IPアドレスsrcIPおよびそのTCPポート番号srcPort、さらには必要に応じて、宛先IPアドレスdstIPおよびそのTCPポート番号dstPortならびにプロトコル番号が、各パケットを識別するためのキーとして抽出される。なお、識別キーとして採用する情報は上記に限定されるものではなく、クライアント（ユーザ）やその通信（コネクションまたはセッション）を一意に識別できる情報であれば、例えばHTTPにおけるユーザIDを識別キーとして採用しても良い。

このとき、無線端末MNのブラウザからサーバへUserAgentが通知されていれば、当該UserAgentに含まれるハードウェア情報、携帯キャリア名、ホストOS名、アプリケーション名等の端末情報も識別される。また、後に詳述するように、通信のURIやパスに、通信路や通信方式を識別可能な情報が載っている場合には、これらの情報を利用しても良い。

ステップＳ３では、前記キャプチャされたパケットのキーと同一キーのレコードが前記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のレコードの有無、すなわち新たに切断されたコネクションの有無が判定される。このようなレコードが存在すればステップＳ１０へ進み、当該レコードが通信ログとして品質パラメータ分析部１０３へ提供される。ステップＳ１１では、前記品質パラメータ分析部１０３へ提供された全てのレコードがTCPコネクションテーブル１０２ａから破棄される。

品質パラメータ分析部１０３では、TCPコネクション管理部１０２から提供された通信ログを分析することで各通信パラメータが算出され、さらに統計処理されて確率分布が求められる。この分析結果は分析結果データベース１０４に通知されて保持される。

図６は、前記品質パラメータ分析部１０３による分析方法を説明するための図である。ここでは、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)に基づいて、クライアント側で体感されるエンドサーバの応答時間を算出できる。

なお、一例としてEV-DOおよびLTEの通信パラメータを比較すると、EV-DOでは、無線通信機会の割当周期（スケジューリング）のタイムスロットが1.67ms毎であり、かつ瞬時的に同時通信できるユーザ数が、多重化方式としてTDMAを採用するために１人のみとなる。すなわち、1.67ms毎に１人のユーザに通信機会が与えられる。また、変調方式等により、レートもRevAだとダウンロードで最大3.1Mbps、アップロードで最大1.8Mbpsとなる。さらに、EV-DOでは信号処理の計算負荷や回路構成、シグナリング上の制約等により、システムの最小遅延（オフセット遅延、RTT）が約150-200msとなる。

これに対して、LTEでは、無線通信機会のスケジューリングのタイムスロットが1ms毎、かつ瞬時的に同時通信できるユーザ数も、多重化方式としてOFDMAを採用するので約８〜１０人となる。すなわち、1ms毎にN人のユーザに通信機会が与えられることになるので、 通信機会が与えられるまでの待ち時間が平均的、統計的に小さくなり易い。また、変調方式等により、レートも帯域幅が10MHzであれば、ダウンロードで最大75Mbps、アップロードで最大25Mbpsとなる。さらに、信号処理の計算負荷や回路構成のアップグレード、シグナリングの改善等により、システムの最小遅延（オフセット遅延、RTT）が約50msとなる。

このように、EV-DOとLTEとの比較では、通信機会の周期、最大レート、最小遅延が大きく異なり、選択性が高いので、これらの各通信パラメータを、通信方式の違い（EV-DOまたはLTE）をラベルとして学習すれば、確度の高い識別が可能になる。

次いで、図９のフローチャートを参照して前記通信路推定部１０５による通信路または通信方式の推定方法を説明する。

ステップＳ２１では、推定対象のセッション／コネクションに関する各品質パラメータの分析結果が前記分析結果DB１０４から取得される。本実施形態では、アクセス回線側RTT遅延、サーバ側RTT遅延、スループット、パケットロス率（再送率）および／またはデータサイズ等の各品質パラメータについて、その分析結果が取得される。ステップＳ２２では、前記学習部１０７から前記品質パラメータごとに、予め学習されている通信品質辞書１０７ａが取得される。

ステップＳ２３では、前記各品質パラメータの分析結果を、対応する各通信品質辞書１０７ａに適用することで、品質パラメータごとに通信路または通信方式が推定される。本実施形態では、前記図３を参照して説明したように、通信路ごとに各品質パラメータの確率分布が予め学習されており、前記各分析結果と、対応する各確率分布との比較・照合結果が通信路の推定結果とされる。

ステップＳ２４では、前記推定結果に基づいて通信路または通信方式が決定される。本実施形態では、通信パラメータごとに得られる推定結果が集計され、尤度の高い１ないし上位Nベストの通信路または通信方式が決定される。なお、前記各推定結果が尤度や確率と共に得られるのであれば、これらで重み付けされた集計結果に基づいて決定されるようにしても良い。

ステップＳ２５では、前記推定対象のセッション／コネクションについて、その通信路または通信方式を判別、特定できる情報が、例えば前記UserAgentに含まれる情報に基づいて予め取得されているか否かが判定される。取得されていなければステップＳ２６へ進み、前記ステップＳ２４で決定された通信路等の推定結果を出力して当該処理を終了する。

これに対して、通信路等を特定できる情報が予め取得されていればステップＳ２７へ進み、前記特定された通信路等が出力される。ステップＳ２８では、前記分析結果DB１０４から取得されたアクセス回線側RTT遅延、サーバ側RTT遅延、スループット、パケットロス率（再送率）および／またはデータサイズ等の各分析結果が、前記特定されている通信路または通信方式の教師データとして学習部１０７へ提供される。

前記学習部１０７では、前記提供された各分析結果および前記特定された通信路または通信方式を教師データとして通信路辞書１０７ａが追加学習または再学習される。この追加学習、再学習では、例えば前記複数の品質パラメータに関する分析結果と前記特定されている通信路等とを比較・照合し、特定されている通信路等に対して正しい推定結果を与えた品質パラメータが正例の教師データ、誤った推定結果を与えた品質パラメータが負例の教師データとして与えられる。

ステップＳ２９では、前記分析結果を通信路辞書１０７ａに適用して得られる推定結果に基づく通信路や通信方式の決定規則が見直される。本実施形態では、正しい推定結果を与える通信パラメータを通信路または通信方式ごとに識別し、次回以降の推定では、正しい推定結果を与える確率の高い品質パラメータに基づく推定結果を優先させるような見直しが行われる。

例えば、通信路が「EV-DO」と特定されているセッション／コネクションの分析結果について、アクセス回線側RTT遅延に基づく推定結果およびサーバ側RTT遅延に基づく推定結果が特異的に高い正答率を示していれば、当該アクセス回線側RTT遅延およびサーバ側RTT遅延の組合せを優先させることが前記「EV-DO」の決定規則とされる。

同様に、通信路が「LTE」と特定されているセッション／コネクションの分析結果について、アクセス回線側RTT遅延に基づく推定結果およびスループットに基づく推定結果が特異的に高い正答率を示していれば、当該アクセス回線側RTT遅延およびスループットの組合せを優先させることが前記「LTE」の決定規則とされる。

そして、通信路が未知であるセッション／コネクションについて、その各品質パラメータの分析結果を前記通信路辞書１０７ａに適用した結果、アクセス回線側RTT遅延に基づく推定結果およびサーバ側RTT遅延に基づく推定結果のいずれもが「EV-DO」である通信路は「EV-DO」に決定される。また、アクセス回線側RTT遅延に基づく推定結果およびスループットに基づく推定結果のいずれもが「LTE」である通信路は「LTE」に決定される。

本実施形態によれば、通信路が既知のパケットから算出される品質パラメータを教師データとして通信路辞書が構築され、通信路が未知のパケットから算出される品質パラメータを前記通信路辞書に適用することにより、その通信路を識別できるようになる。その結果、各通信路をパケットの品質パラメータに基づいて正当に評価できるようになる。

なお、上記の実施形態では、一つの通信路辞書１０７ａを、通信方式が同一の全てのコネクションのスループット推定に共用されるものとして説明したが、本発明はこれのみに限定されるものではない。

すなわち、各コネクションのパケットがキャプチャされた時間帯や曜日、また各パケットに無線移動端末MNの位置情報が記述されている場合には更に当該位置情報ごとに各コネクションを分類し、この分類結果ごとに通信路辞書１０７ａを構築しても良い。このようにすれば、推定対象のコネクションがキャプチャされた時間帯、曜日、位置情報に応じて最適な通信品質辞書を用いてスループットを推定でき

さらに、コネクションの確立時刻を基準にした経過時間ごとの通信レートや積算データ量は、ネットワーク環境のみならずTCPの初期ウィンドウサイズやRTTにも依存する。図８は、同一のネットワーク環境において、初期ウィンドウサイズが小さい場合[実線A]と大きい場合[実線B]との通信レートを比較した図であり、初期ウィンドウサイズが大きい場合は小さい場合に較べてスープットの上昇率が高くなる。したがって、初期ウィンドウサイズが考慮されないと、同一のネットワーク環境であっても初期ウィンドウサイズが大きなコネクションは小さなコネクションに較べてスループットの推定結果が高くなる傾向にある。

そこで、予めTCPの初期ウィンドウサイズとスループットとの関係を統計的に分析し、観測された初期ウィンドウサイズに応じた補正係数をスループットの推定結果に乗じるようにしても良い。あるいは、初期ウィンドウサイズ毎に教師データを作成するようにしても良い。また、初期ウィンドウサイズに代えて、ウィンドウサイズの時系列推移や広告ウィンドウサイズの値に応じて補正係数を乗じたり、教師データを作成したりするようにしても良い。

さらに、帯域と遅延時間との積として求まる帯域幅遅延積も、前記RTTと同様にスループットの推定結果に影響し、帯域幅遅延積が大きいネットワークや回線では、回線上に流れている（TCPでは、ACK待ちの状態）パケット・データが多くなる。したがって、前記RTTに代えて、あるいは前記RTTと共に帯域幅遅延積も求め、帯域幅遅延積に応じて補正係数を乗じたり、教師データを作成したりするようにしても良い。

さらに、発明者等が実トラヒックを分析したところ、通信に利用するアプリケーションや、通信先のサーバあるいは提供されるサービスによっては、そのURIやパスに、通信路や通信方式を識別可能な情報が載っている場合がある。例えば、動画コンテンツをストリーミング視聴する際、同一内容で高画質版と低画質版とが用意されており、それぞれに異なるURIが割り当てられていたり、通信方式を識別する固有の情報が記載されていたりする。例えば、Wi-Fi利用時の通信では高画質版を視聴し、高画質である情報やWi-Fi利用中である旨の情報が記載されている一方、3G携帯回線利用時の通信では低画質版を視聴し、低画質である情報や3G利用中である旨の情報が記載されている

したがって、ストリーミング視聴用のパスやURIに、提供サービスが高画質および低画質のいずれであるか、またはWi-Fiであるか3Gであるかいずれかの情報が載っており、これをキャプチャした各パケットから判別できる場合には、例えば、提供サービスが高画質であれば「Wi-Fi」、提供サービスが低画質であれば「3G携帯回線」といったラベル付けを行い、これを教師データの一つに加えても良い

さらに、通信路と品質パラメータとの関係には地理的依存性があり、端末MNの現在位置が異なれば、たとえ通信路が同一であっても品質パラメータに違いが生じることが確認されている。したがって、キャプチャされたパケットに端末MNの位置情報が記述されていたり、あるいは端末MNから現在位置の位置情報が明示的に提供されたりするのであれば、当該端末MNの現在位置（通信位置）も教師データの一つに加えても良い。

１０１…パケットキャプチャ部，１０２…TCPコネクション管理部，１０２ａ…TCPコネクションテーブル，１０３…品質パラメータ分析部，１０４…分析結果データベース，１０５…通信路推定部，１０６…結果出力部，１０７…学習部，１０７ａ…通信路辞書

Claims (9)

1. セッションまたはコネクションを通信単位として送受されるパケットをパッシブに監視し、各パケットが経由する通信路を識別する通信路識別装置において、
   各通信単位が集約される経路に到着したパケットをキャプチャするキャプチャ手段と、
   前記キャプチャされたパケットの品質パラメータを記録する手段と、
   通信単位ごとに各品質パラメータを分析し、その統計値を出力する分析手段と、
   通信路とその品質パラメータの統計値との関係を学習して通信路辞書を作成する学習手段と、
   通信路が未知の品質パラメータの統計値を前記通信路辞書に適用して当該通信路を推定する通信路推定手段とを具備したことを特徴とする通信路識別装置。
2. 前記キャプチャされたパケットに基づいて、その通信路を判別する手段をさらに具備し、
   前記学習手段は、通信路を判別できたパケットの品質パラメータを分析して得られる統計値と当該通信路の判別結果とを教師データとして前記通信路辞書を作成することを特徴とする請求項１に記載の通信路識別装置。
3. 前記通信路を判別する手段は、UserAgentに含まれる情報に基づいて通信路を判別することを特徴とする請求項２に記載の通信路識別装置。
4. 前記通信路を判別する手段は、通信のパスまたはURIに含まれて通信路を判別できる情報に基づいて通信路を判別することを特徴とする請求項２に記載の通信路識別装置。
5. 前記統計値が、各品質パラメータの確率分布であることを特徴とする請求項１ないし４のいずれかに記載の通信路識別装置。
6. 前記品質パラメータの少なくとも一つが、スループット、サーバ側RTT遅延、アクセス回線側RTT遅延、パケットロス率、再送率およびデータサイズであることを特徴とする請求項１ないし５のいずれかに記載の通信路識別装置。
7. 前記学習部は、前記通信路の判別結果と推定結果とを照合し、推定結果が判別結果と同じになる品質パラメータの分析結果を正例の教師データとして前記通信路辞書を作成することを特徴とする請求項２ないし６のいずれかに記載の通信路識別装置。
8. 前記学習部は、前記通信路の判別結果と推定結果とを照合し、推定結果が判別結果と異なる品質パラメータの分析結果を負例の教師データとして前記通信路辞書を作成することを特徴とする請求項２ないし７のいずれかに記載の通信路識別装置。
9. 前記通信路推定手段は、通信路ごとに正答率の高い推定結果を与える品質パラメータの組合せを識別し、各組合せに係る品質パラメータの推定結果に基づいて通信路を決定することを特徴とする請求項２ないし８のいずれかに記載の通信路識別装置。