ユーザ待ち時間推定装置、ユーザ待ち時間推定方法、及びプログラム
【課題】取得データのサイズを軽減し、アプリケーション層等に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とする。
【解決手段】ユーザ待ち時間推定装置において、TCPベースのサービスを提供するサーバからユーザ端末に向けて送信された各パケットを取得し、時刻の情報とともに記憶手段に格納する手段と、タイムスロット毎のパケット数を算出する手段と、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する手段と、所定のウィンドウ時間長を有するスライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、ウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する手段と、識別された連続区間を、推定されたユーザ待ち時間として出力する手段と、を備える。
【解決手段】ユーザ待ち時間推定装置において、TCPベースのサービスを提供するサーバからユーザ端末に向けて送信された各パケットを取得し、時刻の情報とともに記憶手段に格納する手段と、タイムスロット毎のパケット数を算出する手段と、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する手段と、所定のウィンドウ時間長を有するスライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、ウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する手段と、識別された連続区間を、推定されたユーザ待ち時間として出力する手段と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント／サーバ型のTCPベースアプリケーションを利用するユーザが、ユーザ端末上で体感する待ち時間を推定するための技術に関するものである。
【背景技術】
【０００２】
クライアント／サーバ型のTCPベースのアプリケーションが広く普及している。当該アプリケーションをユーザが快適に使用するためには、ユーザがユーザ端末に対する操作を行ってから、当該操作に対する結果がユーザ端末の画面上に表示されるまでの時間である待ち時間（以下、これをユーザ待ち時間と呼ぶ）が短いことが好ましい。そのため、アプリケーションの品質を評価するにあたって、ユーザ待ち時間は重要な指標の一つであり、ユーザ待ち時間を適切に推定することが求められている。
【０００３】
ユーザ待ち時間を推定する従来技術としては、事前評価型とインサービス評価型がある。
【０００４】
事前評価型の技術は、実際の利用環境ではなく、擬似的な利用環境を用いて、被験者にアプリケーションを利用してもらい、待ち時間を計測するものである。また、擬似的な利用環境で、擬似クライアントを用いて待ち時間を計測する技術もある。
【０００５】
インサービス評価型の技術としては、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術、サーバとユーザ端末間で送受信される情報を収集、解析し、解析結果からユーザ待ち時間を推定する技術、実際の利用環境で擬似クライアントプログラムをユーザ端末で実行させることにより待ち時間を計測する技術等がある。
【０００６】
なお、先行技術文献として、TCP上でのデータ転送における遅延等の品質を推定する技術を開示した特許文献１がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の事前評価型の技術では、実際にユーザがアプリケーションを利用しているときのユーザ待ち時間を推定することができない。従って、通信ネットワークの状況等に応じて変化する場合があるユーザ待ち時間を適切に推定できない。また、事前評価型の技術では、通信ネットワークの状況等によりユーザ待ち時間が悪化した場合等に、それに対する対応をとるといったことができない。
【０００９】
インサービス評価型の技術を用いることにより、事前評価型の問題を解決できる。しかし、従来のインサービス評価型の技術には次のような問題がある。
サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術では、サーバでの処理時間に関わる時間しか推定できず、通信ネットワークに起因するユーザ待ち時間の変化等を把握することができない。
【００１０】
また、擬似クライアントプログラムを用いる技術では、サーバ及び通信ネットワークに測定用のオーバヘッドを生じさせることになり、測定に起因してアプリケーションの品質劣化等が生じてしまう可能性があるという問題がある。
【００１１】
また、サーバとユーザ端末間で送受信される情報を収集、解析する従来の技術では、ユーザ待ち時間を推定するために、ユーザ端末とサーバ間で双方向に送受信される全てのデータを取得する必要があり、取得するべきデータのサイズが非常に大きくなってしまうという問題がある。更に、従来技術では、トランスポート層よりも上位の層までの情報を解析する必要があるため、ＨＴＴＰＳのようなトランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合、取得した情報の解析が不可能となり、ユーザ待ち時間の算出が行えないという問題がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、ユーザ端末とサーバ間で送受信されるデータを取得することによりユーザ待ち時間を推定する技術において、取得するべきデータのサイズを軽減し、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段とを備えることを特徴とするユーザ待ち時間推定装置として構成される。
【００１４】
前記連続区間識別手段は、ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段とを備えて構成することができる。
【発明の効果】
【００１５】
本発明によれば、アプリケーションサーバからユーザ端末に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本発明では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施の形態に係るシステムの全体構成図である。
【図２】「ユーザ待ち時間」を説明するための図である。
【図３】ユーザ待ち時間推定装置１の機能構成図である。
【図４】ユーザ待ち時間推定装置１の動作を説明するためのフローチャートである。
【図５】パケット格納部１２に格納されるパケットの例を示す図である。
【図６】パケット格納部１２に格納されるパケットの例を示す図である。
【図７】トラヒック分類部１３により分類されたパケットの例を示す図である。
【図８】パケット数集計部１４により得られた集計結果を示すヒストグラムである。
【図９】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１０】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１１】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１２】連続区間識別部１５が実行する処理を説明するための概念図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施の形態を説明する。
【００１８】
（システム構成）
図１に、本発明の実施の形態に係るユーザ待ち時間推定装置１を含むシステムの全体構成図を示す。
【００１９】
図１に示すように、本実施の形態に係るシステムは、ユーザ待ち時間推定装置１、アプリケーションサーバ２、ユーザ端末３を備え、これらが通信ネットワーク４に接続されて構成されている。
【００２０】
アプリケーションサーバ２は、アプリケーションサービスをユーザ端末３に対して提供するサーバである。アプリケーションサーバ２が提供するアプリケーションサービスは、例えば、Webページ提供サービス等である。
【００２１】
ユーザ待ち時間推定装置１は、アプリケーションサーバ２と通信を行うユーザ端末３を操作するユーザが体感する待ち時間を推定する装置である。また、ユーザ端末３は、Webブラウザ等を備えた一般的なPC端末である。通信ネットワーク４は、インターネットやLAN等を含むIP（Internet Protocol）によるデータ通信可能なネットワークである。
【００２２】
また、アプリケーションサーバ２とユーザ端末３間で送受信される全てのパケット（ＩＰパケット）をユーザ待ち時間推定装置１が受信できるように通信ネットワーク４が構成されているものとする。例えば、ユーザ待ち時間推定装置１は、通信ネットワーク４内で、アプリケーションサーバ２を接続するLANスイッチのミラーポートに接続される。
【００２３】
ただし、ユーザ待ち時間推定装置１は、必ずしも通信ネットワーク４から直接にパケットを取得しなくてもよい。例えば、通信ネットワーク４から他の装置により取得されたパケットを、当該装置からユーザ待ち時間推定装置１に入力する構成としてもよい。
【００２４】
なお、本実施の形態では、ユーザ端末３とアプリケーションサーバ２間におけるデータ通信のトランスポート層のプロトコルとしてTCP（Transmission Control Protocol）を用いることを前提としている。TCPは、フロー制御等の制御のための通信が頻繁に発生するとともに、要求に対応する応答が必ず発生するので、本発明に係る技術に適しているからである。また、図１では、アプリケーションサーバ２とユーザ端末３がそれぞれ１つづつ示されているが、それぞれ複数台備えられてよいことはいうまでもない。
【００２５】
次に、図２を参照して、本実施の形態に係る"ユーザ待ち時間"について説明する。図２は、アプリケーションサーバ２とユーザ端末３間でのTCPの通信シーケンスの概要を表している図である。
【００２６】
図２に示すように、ユーザがユーザ端末３上で、所望の表示結果を得るための所定の操作（例えば、ブラウザ画面上に表示された特定のボタンをクリックする操作）を行うと、パケットがアプリケーションサーバ２とユーザ端末３間で送受信され、上記操作に対応する結果（例えば、表示されることを期待していたWebページ画面）がユーザ端末３上に表示される。
【００２７】
本明細書及び特許請求の範囲では、上記のように所定の操作を行った時刻から、当該所定の操作に対応する結果が表示される時刻までをユーザ待ち時間としている。
【００２８】
図３に、本実施の形態に係るユーザ待ち時間推定装置１の機能構成図を示す。図３に示すように、ユーザ待ち時間推定装置１は、入力部１１、パケット格納部１２、トラヒック分類部１３、パケット数集計部１４、連続区間識別部１５、RTT（Round Trip Time）提供部１６、及び出力部１７を有する。
【００２９】
各機能部の処理の内容については、後述するシステムの動作説明のところで詳細に説明することとし、以下では各機能部の機能の概要を説明する。
【００３０】
入力部１１は、ユーザ端末３とアプリケーションサーバ２間で送受信されるパケットのうち、アプリケーションサーバ２からユーザ端末３に向かうパケットを通信ネットワーク４等から取得し、各パケットにタイムスタンプ（現在時刻、パケットを取得した時刻）を付してパケット格納部１２に格納する機能部である。
【００３１】
トラヒック分類部１３は、アプリケーションサーバ２からユーザ端末３に向かうパケットを宛先毎に分類する機能部である。パケット数集計部１４は、特定のユーザ端末宛であると識別されたパケット群毎に、予め定めた時間幅（タイムスロット）毎のパケット数を算出する処理を行う機能部である。
【００３２】
連続区間識別部１５は、パケット数集計部１４により得られた予め定めた時間幅毎のパケット数を用いて、所定の時間幅内に一定量以上のパケットが連続して出現しているか否かを識別することにより、ユーザによる待ち時間が継続していると推定できる時間区間を求める機能部である。
【００３３】
また、RTT提供部１６は、RTT（Round Trip Time:ユーザ端末３からアプリケーションサーバ２にパケットを送信して、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間）を取得し、それを連続区間識別部１５に提供する機能部である。出力部１７は、連続区間識別部１５により得られた時間区間を、推定されたユーザ待ち時間の情報として出力する機能部である。
【００３４】
ユーザ待ち時間推定装置１は、メモリやハードディスク等の記憶手段及びCPUを備える一般的なコンピュータに、各機能部に対応する処理を行うためのプログラムを搭載することにより実現できる。当該プログラムは、可搬メモリやディスク等の記録媒体から上記コンピュータにインストールしてもよいし、ネットワーク上のサーバから上記コンピュータにダウンロードし、インストールすることとしてもよい。
【００３５】
（システムの動作）
次に、ユーザ待ち時間推定装置１の動作の例を、図４のフローチャートに沿って説明する。まず、ユーザ待ち時間推定装置１の入力部１１は、通信ネットワーク４から、アプリケーションサーバ２を送信元とするパケットを順次取得し、取得した時刻の情報であるタイムスタンプを付してパケット格納部１２に格納する（図４のステップ１）。
【００３６】
ユーザ待ち時間推定装置１は、特定のアプリケーションサーバ２から送信されるパケットを常にパケット格納部１２に格納し、当該アプリケーションサーバ２に関するユーザ待ち時間推定の必要が生じたときに、特定の時間区間に取得されたパケットを解析の対象としてもよいし、ユーザ指示等により特定の時間区間だけパケット収集を行い、そこで収集されたパケットを解析の対象としてもよい。また、常にパケットをパケット格納部１２に格納し、一定時間毎に特定のアプリケーションサーバに関するユーザ待ち時間推定処理を実行することとしてもよい。もちろん、その他の形態を用いてもよい。
【００３７】
パケット格納部１２に格納されるパケットの例を図５（ａ）に示す。例えば、図５（ａ）の第１行目は、送信元IPアドレスがIPアドレス１、送信元ポート番号がポート番号１、宛先IPアドレスがIPアドレス３、宛先ポート番号がポート番号１であるIPパケットが、時刻１に取得され、格納されたことを示している。他の行も同様である。
【００３８】
なお、図５（ａ）では、宛先IPアドレスがIPアドレス３であるIPパケットのみを示しているが、一般には、種々の宛先IPアドレスのIPパケットが取得される。また、パケット格納部１２に格納する対象となるパケットの送信元ＩＰアドレスと宛先ＩＰアドレスとを予め決めている場合には、取得したパケットからＩＰヘッダを除き、TCPヘッダが付されたTCPパケットの形式でパケット格納部１２に格納することとしてもよい。
【００３９】
続いて、図４のステップ２において、トラヒック分類部１３が、パケット格納部１２に格納されたパケットを、宛先ユーザ端末毎に分類する処理を行う。分類にあたって、本実施の形態では、宛先IPアドレスと宛先ポート番号の１つの組が１つの宛先ユーザ端末に対応するものとし、宛先IPアドレスと宛先ポート番号の組毎にパケットを分類する処理を行う。
【００４０】
ただし、NAT経由の通信等の場合に、１つの宛先ユーザ端末に対して、１つの宛先IPアドレスと、連続する複数の宛先ポート番号が割り当てられる場合があることを考慮して、同じ宛先IPアドレスの複数のパケットであって、連続するポート番号を有する複数のパケットが所定の短い時間（例えば０．５秒）内に現れた場合は、それらのパケットは１つのユーザ端末宛のパケットであるとみなしている。
【００４１】
例えば、パケット格納部１２に格納されたパケットが図５（ａ）に示すとおりのものであった場合、宛先IPアドレスは同一なので、トラヒック分類部１３は、図５（ｂ）に示すようにパケットを分類（ソート）する。図５（ｂ）の例において、宛先ポート番号１のIPパケットはユーザ端末A宛てのパケット、宛先ポート番号８のパケットはユーザ端末Aと異なるユーザ端末B宛てのパケットなどとみなすことができる。
【００４２】
また、例えば、パケット格納部１２に格納されたパケットが図６（ａ）に示すようなものであり、時刻１から時刻４までの時間及び時刻５から時刻７までの時間のそれぞれが所定の時間より短い場合、トラヒック分類部１３は、パケットを図６（ｂ）に示すように分類する。図６（ｂ）の例において、宛先ポート番号１〜４のパケットはユーザ端末Ｘ宛てのパケット、宛先ポート番号１０〜１２のパケットはユーザ端末Ｘと異なるユーザ端末Ｙ宛てのパケットとみなすことができる。
【００４３】
なお、以下で説明する処理は、分類されたパケット群のうち、特定の１つのユーザ端末宛のパケットに対する処理であるものとする。また、分類がなされたパケットは、パケット格納部１２に格納してもよいし、パケット格納部１２以外のメモリ等の記憶手段に格納してもよい。
【００４４】
また、宛先ユーザ端末毎に分類されたパケットを取得する方法は、上記の方法に限られるわけではなく、結果として、宛先ユーザ端末毎に分類されたパケットを取得できるのであればどのような手段を用いてもよい。
【００４５】
次に、図４のステップ３において、ユーザ待ち時間推定装置１のパケット数集計部１４は、分類されたパケットについて、予め定めた時間幅（Ｗで表し、タイムスロットとも呼ぶ）毎の個数を算出する処理を行う。
【００４６】
例えば、トラヒック分類部１３により、図７に示すパケットが、アプリケーションサーバ２からユーザ端末３宛（ＩＰアドレス３及び宛先ポート番号１０で識別されるユーザ端末）のパケットとして抽出されたものとする。また、例えば、タイムスロットの大きさＷとして０．１秒（以下、時間の単位は秒であるとする）を使用するものとする。
【００４７】
この場合、パケット数集計部１４は、時刻０から時刻０．１の間のタイムスロットのパケット数を３として求め、時刻０．１から時刻０．２の間のタイムスロットのパケット数を４として求める。他のタイムスロットでも同様である。このようにして算出した結果から、図８に示すヒストグラムが得られる。
【００４８】
続いて、図４のステップ４において、連続区間識別部１５が、パケット数集計部１４により得られたタイムスロット毎のパケット数に基づき、ユーザ待ち時間であると推定することができるパケットの連続区間を識別する処理を行う。
【００４９】
本実施の形態では、連続区間識別部１５は、ユーザ端末３からアプリケーションサーバ２にパケットが送信されてから、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間であるRTTを利用して連続区間を識別することもできるし、RTTを利用しないで連続区間を識別することもできる。RTTを利用するかしないかは、例えば、アプリケーションサーバ２の位置（国内か外国か等）や、通信ネットワーク４の状態等で判断し、ユーザによりRTTを利用するかしないかを設定することができる。
【００５０】
＜RTTを利用しない場合＞
まず、RTTを利用しない場合の処理について、図９のフローチャート、及び、図１０に示す処理の概念図を用いて説明する。
【００５１】
なお、以下の処理の前提として、タイムスロットにおけるパケット数の閾値である検知閾値と、スライディングウィンドウの時間長さＬと、連続性判定閾値Ｓとが予め連続区間識別部１５に入力され、メモリ等に保持されているものとする。
【００５２】
まず、図９のステップ１０において、連続区間識別部１５は、パケット数が検知閾値以上の全てのタイムスロットを抽出する。ここで、検知閾値は、０以上の整数である。検知閾値は、対象とする通信（ユーザによる操作に起因する通信）以外の通信に係るパケットを、ユーザ待ち時間推定において検知しないようにするために設けられるものである。
また、各タイムスロットは、その開始時間位置と終了時間位置で識別される情報である。ステップ１０の処理は、図１０において、パケット数が点線と重なるか、点線を越えているタイムスロットを抽出する処理に相当する。以下、ここで抽出されたタイムスロットを、抽出タイムスロットと呼ぶ。
【００５３】
次に、図９のステップ２０において、連続区間識別部１５は、複数の抽出タイムスロットのうちの、後述する連続性判定開始位置になったことがない抽出タイムスロットの中で、時間的に最初に位置する抽出タイムスロットの開始位置（時刻Ｔとする）を特定する。
【００５４】
そして、連続区間識別部１５は、連続区間識別のためにスライディングウィンドウをずらす時間長さを示す変数であるＣを初期化（Ｃ＝０とする）する（ステップ３０）。続いて、連続区間識別部１５は、上記抽出タイムスロットの開始位置である時刻Ｔから始まるスライディングウィンドウに含まれる抽出タイムスロットの合計の時間長さを求め、スライディングウィンドウの時間長さLに対する当該抽出タイムスロットの合計の時間長さの割合Ｒを求める（ステップ４０）。以下では、スライディングウィンドウの開始位置を連続性判定開始位置と呼ぶことにする。
【００５５】
ステップ４０において、タイムスロットの時間幅がＷであり、連続性判定開始位置から始まるスライディングウィンドウの時間長さＬの中に、抽出タイムスロット（パケット数が検知閾値以上のタイムスロット）がＭ個含まれるとした場合、抽出タイムスロットの合計の時間長さはＷ×Ｍであるから、Ｒ＝Ｗ×Ｍ／Ｌとなる。また、図１０の場合について、タイムスロットの幅を０．１、各スライディングウィンドウの長さを１とすると、スライディングウィンドウＡの中に、８個の抽出タイムスロットが含まれるから、Ｒ＝０．１×８／１＝０．８となる。
【００５６】
続いて、連続区間識別部１５は、Ｒが連続性判定閾値Ｓ以上であるか否かを判定する（ステップ５０）。本実施の形態において、Ｓは、０から１の間の定数であり、例えばＳ＝０．５である。
【００５７】
ステップ５０において、Ｒが連続性判定閾値Ｓ以上であると判定された場合、連続区間識別部１５は、連続性判定開始位置を、時間進行方向において次に位置する抽出タイムスロットの開始位置とする。また、連続性判定開始位置をずらした長さ（前の連続性判定開始位置から次の連続性判定開始位置までの時間）をＫとし、Ｃ＝Ｃ＋Ｋとする（ステップ６０）。その後、ステップ４０に戻る。
【００５８】
また、ステップ５０において、Ｒが連続性判定閾値Ｓ以上でないと判定された場合、連続区間識別部１５は、ステップ７０に進み、Ｃ＝Ｃ−Ｋとするとともに、ＴからＴ＋Ｃ＋Ｌの区間を連続区間としてメモリ等の記憶手段に記録し、ステップ２０に戻る。ただし、ステップ５０の判定処理において、一度もＹｅｓの判定がされずに最初からＮｏと判定された場合には、ステップ７０を経ずにステップ２０に戻る。ステップ２０において、現在の連続性開始判定位置の次の抽出タイムスロットの開始位置がＴとなり、それ以降の処理が繰り返される。ここで、次の抽出タイムスロットが存在しなければ処理を終了する（ステップ８０）。
【００５９】
上記の処理の概念を図１０を参照して説明する。図１０の例では、スライディングウィンドウの時間長さがタイムスロット１０個分の長さであり、連続性判定閾値Ｓ＝１／２＝０．５であるものとする。つまり、この場合、スライディングウィンドウ内に、５個以上の抽出タイムスロットが含まれる場合に、ステップ５０においてＹＥＳと判定される。
【００６０】
図１０の例では、点線よりパケット数の多いタイムスロットがまず抽出される。そして、スライディングウィンドウＡの開始位置Tが最初の連続性判定開始位置となり、スライディングウィンドウＡには、８個の抽出タイムスロットが含まれるので、ステップ５０においてＹＥＳと判定され、連続性判定開始位置がスライディングウィンドウＢの開始位置までずらされ、同様の判定処理及び連続性判定開始位置をずらす処理等が繰り返される。
【００６１】
図１０の例では、スライディングウィンドウＥには、５個の抽出タイムスロットが含まれるが、スライディングウィンドウＦには、４個の抽出タイムスロットしか含まれず、ここではステップ５０の判定はＮｏになる。従って、スライディングウィンドウＡの開始位置Ｔから、スライディングウィンドウEの終了位置（Ｔ＋Ｃ＋Ｌ）までの時間区間が、ユーザ待ち時間に対応する連続区間であるとして記憶手段に記録されることになる。
【００６２】
ステップ８０において、処理が終了すると、記憶手段に格納されている連続区間情報（＝ユーザ待ち時間情報）が、出力部１７に渡され、出力される（図４のステップ５）。例えば、出力部１７は、ユーザ待ち時間情報として、対象となっているアプリケーションサーバ２のIPアドレス及びポート番号、ユーザ端末３に対応するIPアドレス及びポート番号、及び、ユーザ待ち時間（連続区間）の開始時刻と終了時刻を出力する。また、ユーザ端末３に対応するIPアドレス及びポート番号から、ユーザ端末もしくはユーザの名前を識別可能である場合には、ユーザ端末もしくはユーザの名前を出力してもよい。
【００６３】
出力部１７から出力された情報は、例えば、ネットワーク管理者の端末に転送され、表示される。
【００６４】
上述した本実施の形態における技術を用いることにより、安定したネットワーク環境において、ユーザ待ち時間を適切に推定することが可能となる。TCPパケットを用いる場合において、TCPヘッダの中の情報から、データ転送開始及び終了を判定することにより、ユーザ待ち時間を推定することも考えられるが、ユーザ待ち時間の中で、TCP上でのデータ転送開始及び終了が連続的に複数回発生する場合があるので、TCPヘッダの中の情報からでは、適切にユーザ待ち時間を推定することはできない。
【００６５】
本実施の形態のように、TCPベースのアプリケーションサーバ２からユーザ端末３に送信されるパケットが、ある程度の短い時間間隔で連続的に発生している場合はユーザの待ちが継続していると判定する手法により、より適切にユーザ待ち時間を推定することが可能になる。なお、本実施の形態における技術は、アプリケーションサーバ２側において、ユーザ端末３に対してTCPパケットを送出せずにデータ処理（データのハードディスクへの書き込み処理等）を行う時間が比較的短い場合に適している。
【００６６】
上記の例において、タイムスロットの時間幅W、スライディングウィンドウの時間長さL、及び、連続性判定閾値Ｓについては、実験等により適切な値を定めればよいが、安定したネットワーク環境での一例として、タイムスロットの時間幅Wとして０．１を用い、スライディングウィンドウの時間長さLとしてタイムスロット１０個分である１を用い、連続性判定閾値Ｓとして１／２を用いることにより、良好な結果が得られている。
【００６７】
＜RTTを利用する場合＞
次に、RTTを利用する場合の連続区間の識別処理のフローチャートを図１１に示す。以下では、RTTを利用しない場合との相違点を中心に説明する。
【００６８】
RTTを利用しない場合は、スライディングウィンドウの時間長さＬとして予め定めた長さを用いていたのに対し、RTTを利用する場合の処理は、図１１のステップ３５において、スライディングウィンドウの長さＬをRTTに基づき算出し、それ以降の処理において、RTTに基づき求めたＬを用いて連続区間を判定している。その他の処理については図９の場合と同じである。より詳細には以下のとおりである。
【００６９】
本実施の形態では、入力部１１は、RTTを求めるためのデータとして、アプリケーションサーバ２からユーザ端末３に向かうパケットの他に、ユーザ端末３からプリケーションサーバ２に向かうパケットのうちの一部のパケットを取得してパケット格納部１２に格納することができる。RTT提供部１６は、パケット格納部１２に格納されたデータを参照することにより、例えば、シーケンス番号で送信パケットとそれに対応する応答パケットを識別し、所定の時間毎のRTTを算出することができる。なお、TCPパケットからRTTを算出すること自体は従来技術である。もちろん、RTT提供部１６は、その他の方法でRTTを算出することとしてもよい。例えば、ユーザ待ち時間推定装置１の外部にある装置でRTTを取得し、その装置からRTTを受信することとしてもよい。
【００７０】
ステップ３５において、連続区間識別部１５は、RTT提供部１６から、連続性判定開始位置に最も近い時刻に対応するRTTを取得する。ここでRTTをＴＲと表すと、連続区間識別部１５は、Ｌ＝（ＴＲ＋Ｗ）×Ｎ（Ｎは自然数）としてＬを求める。例えば、ＴＲ＝０．０１、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１１×１０＝１．１となる。また、例えば、Ｒ＝０．０５、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１５×１０＝１．５となる。
【００７１】
ＲＴＴを用いる場合の処理の概念を図１２を用いて説明する。図１２において、（Ａ）で示される部分は、Ｌ＝１．１の場合であり、（Ｂ）で示される部分は、Ｌ＝１．５の場合を示している。図１２に示すとおり、スライディングウィンドウの長さＬをＲＴＴに応じて伸ばすことにより、ＲＴＴの影響でパケットの出現間隔が間延びする場合であっても、適切に連続区間（ユーザ待ち時間であると推定できる区間）を識別できる。
【００７２】
（実施の形態の効果について）
上記のように、本実施の形態で説明した技術によれば、アプリケーションサーバ２からユーザ端末３に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本実施の形態の技術では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００７３】
また、本実施の形態の技術では、RTTに応じてスライディングウィンドウの時間長さを変更することが可能なので、通信ネットワークの状況に応じたユーザ待ち時間を推定できる。
【００７４】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００７５】
１ ユーザ待ち時間推定装置
２ アプリケーションサーバ
３ ユーザ端末
４ 通信ネットワーク
１１ 入力部
１２ パケット格納部
１３ トラヒック分類部
１４ パケット数集計部
１５ 連続区間識別部
１６ RTT提供部
１７ 出力部
【技術分野】
【０００１】
本発明は、クライアント／サーバ型のTCPベースアプリケーションを利用するユーザが、ユーザ端末上で体感する待ち時間を推定するための技術に関するものである。
【背景技術】
【０００２】
クライアント／サーバ型のTCPベースのアプリケーションが広く普及している。当該アプリケーションをユーザが快適に使用するためには、ユーザがユーザ端末に対する操作を行ってから、当該操作に対する結果がユーザ端末の画面上に表示されるまでの時間である待ち時間（以下、これをユーザ待ち時間と呼ぶ）が短いことが好ましい。そのため、アプリケーションの品質を評価するにあたって、ユーザ待ち時間は重要な指標の一つであり、ユーザ待ち時間を適切に推定することが求められている。
【０００３】
ユーザ待ち時間を推定する従来技術としては、事前評価型とインサービス評価型がある。
【０００４】
事前評価型の技術は、実際の利用環境ではなく、擬似的な利用環境を用いて、被験者にアプリケーションを利用してもらい、待ち時間を計測するものである。また、擬似的な利用環境で、擬似クライアントを用いて待ち時間を計測する技術もある。
【０００５】
インサービス評価型の技術としては、サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術、サーバとユーザ端末間で送受信される情報を収集、解析し、解析結果からユーザ待ち時間を推定する技術、実際の利用環境で擬似クライアントプログラムをユーザ端末で実行させることにより待ち時間を計測する技術等がある。
【０００６】
なお、先行技術文献として、TCP上でのデータ転送における遅延等の品質を推定する技術を開示した特許文献１がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−１４０５９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の事前評価型の技術では、実際にユーザがアプリケーションを利用しているときのユーザ待ち時間を推定することができない。従って、通信ネットワークの状況等に応じて変化する場合があるユーザ待ち時間を適切に推定できない。また、事前評価型の技術では、通信ネットワークの状況等によりユーザ待ち時間が悪化した場合等に、それに対する対応をとるといったことができない。
【０００９】
インサービス評価型の技術を用いることにより、事前評価型の問題を解決できる。しかし、従来のインサービス評価型の技術には次のような問題がある。
サーバに蓄積されたログを解析することによりユーザ待ち時間を推定する技術では、サーバでの処理時間に関わる時間しか推定できず、通信ネットワークに起因するユーザ待ち時間の変化等を把握することができない。
【００１０】
また、擬似クライアントプログラムを用いる技術では、サーバ及び通信ネットワークに測定用のオーバヘッドを生じさせることになり、測定に起因してアプリケーションの品質劣化等が生じてしまう可能性があるという問題がある。
【００１１】
また、サーバとユーザ端末間で送受信される情報を収集、解析する従来の技術では、ユーザ待ち時間を推定するために、ユーザ端末とサーバ間で双方向に送受信される全てのデータを取得する必要があり、取得するべきデータのサイズが非常に大きくなってしまうという問題がある。更に、従来技術では、トランスポート層よりも上位の層までの情報を解析する必要があるため、ＨＴＴＰＳのようなトランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合、取得した情報の解析が不可能となり、ユーザ待ち時間の算出が行えないという問題がある。
【００１２】
本発明は上記の点に鑑みてなされたものであり、ユーザ端末とサーバ間で送受信されるデータを取得することによりユーザ待ち時間を推定する技術において、取得するべきデータのサイズを軽減し、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することを可能とした技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の課題を解決するために、本発明は、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段とを備えることを特徴とするユーザ待ち時間推定装置として構成される。
【００１４】
前記連続区間識別手段は、ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段とを備えて構成することができる。
【発明の効果】
【００１５】
本発明によれば、アプリケーションサーバからユーザ端末に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本発明では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施の形態に係るシステムの全体構成図である。
【図２】「ユーザ待ち時間」を説明するための図である。
【図３】ユーザ待ち時間推定装置１の機能構成図である。
【図４】ユーザ待ち時間推定装置１の動作を説明するためのフローチャートである。
【図５】パケット格納部１２に格納されるパケットの例を示す図である。
【図６】パケット格納部１２に格納されるパケットの例を示す図である。
【図７】トラヒック分類部１３により分類されたパケットの例を示す図である。
【図８】パケット数集計部１４により得られた集計結果を示すヒストグラムである。
【図９】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１０】連続区間識別部１５が実行する処理を説明するための概念図である。
【図１１】連続区間識別部１５が実行する処理を説明するためのフローチャートである。
【図１２】連続区間識別部１５が実行する処理を説明するための概念図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施の形態を説明する。
【００１８】
（システム構成）
図１に、本発明の実施の形態に係るユーザ待ち時間推定装置１を含むシステムの全体構成図を示す。
【００１９】
図１に示すように、本実施の形態に係るシステムは、ユーザ待ち時間推定装置１、アプリケーションサーバ２、ユーザ端末３を備え、これらが通信ネットワーク４に接続されて構成されている。
【００２０】
アプリケーションサーバ２は、アプリケーションサービスをユーザ端末３に対して提供するサーバである。アプリケーションサーバ２が提供するアプリケーションサービスは、例えば、Webページ提供サービス等である。
【００２１】
ユーザ待ち時間推定装置１は、アプリケーションサーバ２と通信を行うユーザ端末３を操作するユーザが体感する待ち時間を推定する装置である。また、ユーザ端末３は、Webブラウザ等を備えた一般的なPC端末である。通信ネットワーク４は、インターネットやLAN等を含むIP（Internet Protocol）によるデータ通信可能なネットワークである。
【００２２】
また、アプリケーションサーバ２とユーザ端末３間で送受信される全てのパケット（ＩＰパケット）をユーザ待ち時間推定装置１が受信できるように通信ネットワーク４が構成されているものとする。例えば、ユーザ待ち時間推定装置１は、通信ネットワーク４内で、アプリケーションサーバ２を接続するLANスイッチのミラーポートに接続される。
【００２３】
ただし、ユーザ待ち時間推定装置１は、必ずしも通信ネットワーク４から直接にパケットを取得しなくてもよい。例えば、通信ネットワーク４から他の装置により取得されたパケットを、当該装置からユーザ待ち時間推定装置１に入力する構成としてもよい。
【００２４】
なお、本実施の形態では、ユーザ端末３とアプリケーションサーバ２間におけるデータ通信のトランスポート層のプロトコルとしてTCP（Transmission Control Protocol）を用いることを前提としている。TCPは、フロー制御等の制御のための通信が頻繁に発生するとともに、要求に対応する応答が必ず発生するので、本発明に係る技術に適しているからである。また、図１では、アプリケーションサーバ２とユーザ端末３がそれぞれ１つづつ示されているが、それぞれ複数台備えられてよいことはいうまでもない。
【００２５】
次に、図２を参照して、本実施の形態に係る"ユーザ待ち時間"について説明する。図２は、アプリケーションサーバ２とユーザ端末３間でのTCPの通信シーケンスの概要を表している図である。
【００２６】
図２に示すように、ユーザがユーザ端末３上で、所望の表示結果を得るための所定の操作（例えば、ブラウザ画面上に表示された特定のボタンをクリックする操作）を行うと、パケットがアプリケーションサーバ２とユーザ端末３間で送受信され、上記操作に対応する結果（例えば、表示されることを期待していたWebページ画面）がユーザ端末３上に表示される。
【００２７】
本明細書及び特許請求の範囲では、上記のように所定の操作を行った時刻から、当該所定の操作に対応する結果が表示される時刻までをユーザ待ち時間としている。
【００２８】
図３に、本実施の形態に係るユーザ待ち時間推定装置１の機能構成図を示す。図３に示すように、ユーザ待ち時間推定装置１は、入力部１１、パケット格納部１２、トラヒック分類部１３、パケット数集計部１４、連続区間識別部１５、RTT（Round Trip Time）提供部１６、及び出力部１７を有する。
【００２９】
各機能部の処理の内容については、後述するシステムの動作説明のところで詳細に説明することとし、以下では各機能部の機能の概要を説明する。
【００３０】
入力部１１は、ユーザ端末３とアプリケーションサーバ２間で送受信されるパケットのうち、アプリケーションサーバ２からユーザ端末３に向かうパケットを通信ネットワーク４等から取得し、各パケットにタイムスタンプ（現在時刻、パケットを取得した時刻）を付してパケット格納部１２に格納する機能部である。
【００３１】
トラヒック分類部１３は、アプリケーションサーバ２からユーザ端末３に向かうパケットを宛先毎に分類する機能部である。パケット数集計部１４は、特定のユーザ端末宛であると識別されたパケット群毎に、予め定めた時間幅（タイムスロット）毎のパケット数を算出する処理を行う機能部である。
【００３２】
連続区間識別部１５は、パケット数集計部１４により得られた予め定めた時間幅毎のパケット数を用いて、所定の時間幅内に一定量以上のパケットが連続して出現しているか否かを識別することにより、ユーザによる待ち時間が継続していると推定できる時間区間を求める機能部である。
【００３３】
また、RTT提供部１６は、RTT（Round Trip Time:ユーザ端末３からアプリケーションサーバ２にパケットを送信して、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間）を取得し、それを連続区間識別部１５に提供する機能部である。出力部１７は、連続区間識別部１５により得られた時間区間を、推定されたユーザ待ち時間の情報として出力する機能部である。
【００３４】
ユーザ待ち時間推定装置１は、メモリやハードディスク等の記憶手段及びCPUを備える一般的なコンピュータに、各機能部に対応する処理を行うためのプログラムを搭載することにより実現できる。当該プログラムは、可搬メモリやディスク等の記録媒体から上記コンピュータにインストールしてもよいし、ネットワーク上のサーバから上記コンピュータにダウンロードし、インストールすることとしてもよい。
【００３５】
（システムの動作）
次に、ユーザ待ち時間推定装置１の動作の例を、図４のフローチャートに沿って説明する。まず、ユーザ待ち時間推定装置１の入力部１１は、通信ネットワーク４から、アプリケーションサーバ２を送信元とするパケットを順次取得し、取得した時刻の情報であるタイムスタンプを付してパケット格納部１２に格納する（図４のステップ１）。
【００３６】
ユーザ待ち時間推定装置１は、特定のアプリケーションサーバ２から送信されるパケットを常にパケット格納部１２に格納し、当該アプリケーションサーバ２に関するユーザ待ち時間推定の必要が生じたときに、特定の時間区間に取得されたパケットを解析の対象としてもよいし、ユーザ指示等により特定の時間区間だけパケット収集を行い、そこで収集されたパケットを解析の対象としてもよい。また、常にパケットをパケット格納部１２に格納し、一定時間毎に特定のアプリケーションサーバに関するユーザ待ち時間推定処理を実行することとしてもよい。もちろん、その他の形態を用いてもよい。
【００３７】
パケット格納部１２に格納されるパケットの例を図５（ａ）に示す。例えば、図５（ａ）の第１行目は、送信元IPアドレスがIPアドレス１、送信元ポート番号がポート番号１、宛先IPアドレスがIPアドレス３、宛先ポート番号がポート番号１であるIPパケットが、時刻１に取得され、格納されたことを示している。他の行も同様である。
【００３８】
なお、図５（ａ）では、宛先IPアドレスがIPアドレス３であるIPパケットのみを示しているが、一般には、種々の宛先IPアドレスのIPパケットが取得される。また、パケット格納部１２に格納する対象となるパケットの送信元ＩＰアドレスと宛先ＩＰアドレスとを予め決めている場合には、取得したパケットからＩＰヘッダを除き、TCPヘッダが付されたTCPパケットの形式でパケット格納部１２に格納することとしてもよい。
【００３９】
続いて、図４のステップ２において、トラヒック分類部１３が、パケット格納部１２に格納されたパケットを、宛先ユーザ端末毎に分類する処理を行う。分類にあたって、本実施の形態では、宛先IPアドレスと宛先ポート番号の１つの組が１つの宛先ユーザ端末に対応するものとし、宛先IPアドレスと宛先ポート番号の組毎にパケットを分類する処理を行う。
【００４０】
ただし、NAT経由の通信等の場合に、１つの宛先ユーザ端末に対して、１つの宛先IPアドレスと、連続する複数の宛先ポート番号が割り当てられる場合があることを考慮して、同じ宛先IPアドレスの複数のパケットであって、連続するポート番号を有する複数のパケットが所定の短い時間（例えば０．５秒）内に現れた場合は、それらのパケットは１つのユーザ端末宛のパケットであるとみなしている。
【００４１】
例えば、パケット格納部１２に格納されたパケットが図５（ａ）に示すとおりのものであった場合、宛先IPアドレスは同一なので、トラヒック分類部１３は、図５（ｂ）に示すようにパケットを分類（ソート）する。図５（ｂ）の例において、宛先ポート番号１のIPパケットはユーザ端末A宛てのパケット、宛先ポート番号８のパケットはユーザ端末Aと異なるユーザ端末B宛てのパケットなどとみなすことができる。
【００４２】
また、例えば、パケット格納部１２に格納されたパケットが図６（ａ）に示すようなものであり、時刻１から時刻４までの時間及び時刻５から時刻７までの時間のそれぞれが所定の時間より短い場合、トラヒック分類部１３は、パケットを図６（ｂ）に示すように分類する。図６（ｂ）の例において、宛先ポート番号１〜４のパケットはユーザ端末Ｘ宛てのパケット、宛先ポート番号１０〜１２のパケットはユーザ端末Ｘと異なるユーザ端末Ｙ宛てのパケットとみなすことができる。
【００４３】
なお、以下で説明する処理は、分類されたパケット群のうち、特定の１つのユーザ端末宛のパケットに対する処理であるものとする。また、分類がなされたパケットは、パケット格納部１２に格納してもよいし、パケット格納部１２以外のメモリ等の記憶手段に格納してもよい。
【００４４】
また、宛先ユーザ端末毎に分類されたパケットを取得する方法は、上記の方法に限られるわけではなく、結果として、宛先ユーザ端末毎に分類されたパケットを取得できるのであればどのような手段を用いてもよい。
【００４５】
次に、図４のステップ３において、ユーザ待ち時間推定装置１のパケット数集計部１４は、分類されたパケットについて、予め定めた時間幅（Ｗで表し、タイムスロットとも呼ぶ）毎の個数を算出する処理を行う。
【００４６】
例えば、トラヒック分類部１３により、図７に示すパケットが、アプリケーションサーバ２からユーザ端末３宛（ＩＰアドレス３及び宛先ポート番号１０で識別されるユーザ端末）のパケットとして抽出されたものとする。また、例えば、タイムスロットの大きさＷとして０．１秒（以下、時間の単位は秒であるとする）を使用するものとする。
【００４７】
この場合、パケット数集計部１４は、時刻０から時刻０．１の間のタイムスロットのパケット数を３として求め、時刻０．１から時刻０．２の間のタイムスロットのパケット数を４として求める。他のタイムスロットでも同様である。このようにして算出した結果から、図８に示すヒストグラムが得られる。
【００４８】
続いて、図４のステップ４において、連続区間識別部１５が、パケット数集計部１４により得られたタイムスロット毎のパケット数に基づき、ユーザ待ち時間であると推定することができるパケットの連続区間を識別する処理を行う。
【００４９】
本実施の形態では、連続区間識別部１５は、ユーザ端末３からアプリケーションサーバ２にパケットが送信されてから、確認応答パケットがアプリケーションサーバ２からユーザ端末３に返されるまでの時間であるRTTを利用して連続区間を識別することもできるし、RTTを利用しないで連続区間を識別することもできる。RTTを利用するかしないかは、例えば、アプリケーションサーバ２の位置（国内か外国か等）や、通信ネットワーク４の状態等で判断し、ユーザによりRTTを利用するかしないかを設定することができる。
【００５０】
＜RTTを利用しない場合＞
まず、RTTを利用しない場合の処理について、図９のフローチャート、及び、図１０に示す処理の概念図を用いて説明する。
【００５１】
なお、以下の処理の前提として、タイムスロットにおけるパケット数の閾値である検知閾値と、スライディングウィンドウの時間長さＬと、連続性判定閾値Ｓとが予め連続区間識別部１５に入力され、メモリ等に保持されているものとする。
【００５２】
まず、図９のステップ１０において、連続区間識別部１５は、パケット数が検知閾値以上の全てのタイムスロットを抽出する。ここで、検知閾値は、０以上の整数である。検知閾値は、対象とする通信（ユーザによる操作に起因する通信）以外の通信に係るパケットを、ユーザ待ち時間推定において検知しないようにするために設けられるものである。
また、各タイムスロットは、その開始時間位置と終了時間位置で識別される情報である。ステップ１０の処理は、図１０において、パケット数が点線と重なるか、点線を越えているタイムスロットを抽出する処理に相当する。以下、ここで抽出されたタイムスロットを、抽出タイムスロットと呼ぶ。
【００５３】
次に、図９のステップ２０において、連続区間識別部１５は、複数の抽出タイムスロットのうちの、後述する連続性判定開始位置になったことがない抽出タイムスロットの中で、時間的に最初に位置する抽出タイムスロットの開始位置（時刻Ｔとする）を特定する。
【００５４】
そして、連続区間識別部１５は、連続区間識別のためにスライディングウィンドウをずらす時間長さを示す変数であるＣを初期化（Ｃ＝０とする）する（ステップ３０）。続いて、連続区間識別部１５は、上記抽出タイムスロットの開始位置である時刻Ｔから始まるスライディングウィンドウに含まれる抽出タイムスロットの合計の時間長さを求め、スライディングウィンドウの時間長さLに対する当該抽出タイムスロットの合計の時間長さの割合Ｒを求める（ステップ４０）。以下では、スライディングウィンドウの開始位置を連続性判定開始位置と呼ぶことにする。
【００５５】
ステップ４０において、タイムスロットの時間幅がＷであり、連続性判定開始位置から始まるスライディングウィンドウの時間長さＬの中に、抽出タイムスロット（パケット数が検知閾値以上のタイムスロット）がＭ個含まれるとした場合、抽出タイムスロットの合計の時間長さはＷ×Ｍであるから、Ｒ＝Ｗ×Ｍ／Ｌとなる。また、図１０の場合について、タイムスロットの幅を０．１、各スライディングウィンドウの長さを１とすると、スライディングウィンドウＡの中に、８個の抽出タイムスロットが含まれるから、Ｒ＝０．１×８／１＝０．８となる。
【００５６】
続いて、連続区間識別部１５は、Ｒが連続性判定閾値Ｓ以上であるか否かを判定する（ステップ５０）。本実施の形態において、Ｓは、０から１の間の定数であり、例えばＳ＝０．５である。
【００５７】
ステップ５０において、Ｒが連続性判定閾値Ｓ以上であると判定された場合、連続区間識別部１５は、連続性判定開始位置を、時間進行方向において次に位置する抽出タイムスロットの開始位置とする。また、連続性判定開始位置をずらした長さ（前の連続性判定開始位置から次の連続性判定開始位置までの時間）をＫとし、Ｃ＝Ｃ＋Ｋとする（ステップ６０）。その後、ステップ４０に戻る。
【００５８】
また、ステップ５０において、Ｒが連続性判定閾値Ｓ以上でないと判定された場合、連続区間識別部１５は、ステップ７０に進み、Ｃ＝Ｃ−Ｋとするとともに、ＴからＴ＋Ｃ＋Ｌの区間を連続区間としてメモリ等の記憶手段に記録し、ステップ２０に戻る。ただし、ステップ５０の判定処理において、一度もＹｅｓの判定がされずに最初からＮｏと判定された場合には、ステップ７０を経ずにステップ２０に戻る。ステップ２０において、現在の連続性開始判定位置の次の抽出タイムスロットの開始位置がＴとなり、それ以降の処理が繰り返される。ここで、次の抽出タイムスロットが存在しなければ処理を終了する（ステップ８０）。
【００５９】
上記の処理の概念を図１０を参照して説明する。図１０の例では、スライディングウィンドウの時間長さがタイムスロット１０個分の長さであり、連続性判定閾値Ｓ＝１／２＝０．５であるものとする。つまり、この場合、スライディングウィンドウ内に、５個以上の抽出タイムスロットが含まれる場合に、ステップ５０においてＹＥＳと判定される。
【００６０】
図１０の例では、点線よりパケット数の多いタイムスロットがまず抽出される。そして、スライディングウィンドウＡの開始位置Tが最初の連続性判定開始位置となり、スライディングウィンドウＡには、８個の抽出タイムスロットが含まれるので、ステップ５０においてＹＥＳと判定され、連続性判定開始位置がスライディングウィンドウＢの開始位置までずらされ、同様の判定処理及び連続性判定開始位置をずらす処理等が繰り返される。
【００６１】
図１０の例では、スライディングウィンドウＥには、５個の抽出タイムスロットが含まれるが、スライディングウィンドウＦには、４個の抽出タイムスロットしか含まれず、ここではステップ５０の判定はＮｏになる。従って、スライディングウィンドウＡの開始位置Ｔから、スライディングウィンドウEの終了位置（Ｔ＋Ｃ＋Ｌ）までの時間区間が、ユーザ待ち時間に対応する連続区間であるとして記憶手段に記録されることになる。
【００６２】
ステップ８０において、処理が終了すると、記憶手段に格納されている連続区間情報（＝ユーザ待ち時間情報）が、出力部１７に渡され、出力される（図４のステップ５）。例えば、出力部１７は、ユーザ待ち時間情報として、対象となっているアプリケーションサーバ２のIPアドレス及びポート番号、ユーザ端末３に対応するIPアドレス及びポート番号、及び、ユーザ待ち時間（連続区間）の開始時刻と終了時刻を出力する。また、ユーザ端末３に対応するIPアドレス及びポート番号から、ユーザ端末もしくはユーザの名前を識別可能である場合には、ユーザ端末もしくはユーザの名前を出力してもよい。
【００６３】
出力部１７から出力された情報は、例えば、ネットワーク管理者の端末に転送され、表示される。
【００６４】
上述した本実施の形態における技術を用いることにより、安定したネットワーク環境において、ユーザ待ち時間を適切に推定することが可能となる。TCPパケットを用いる場合において、TCPヘッダの中の情報から、データ転送開始及び終了を判定することにより、ユーザ待ち時間を推定することも考えられるが、ユーザ待ち時間の中で、TCP上でのデータ転送開始及び終了が連続的に複数回発生する場合があるので、TCPヘッダの中の情報からでは、適切にユーザ待ち時間を推定することはできない。
【００６５】
本実施の形態のように、TCPベースのアプリケーションサーバ２からユーザ端末３に送信されるパケットが、ある程度の短い時間間隔で連続的に発生している場合はユーザの待ちが継続していると判定する手法により、より適切にユーザ待ち時間を推定することが可能になる。なお、本実施の形態における技術は、アプリケーションサーバ２側において、ユーザ端末３に対してTCPパケットを送出せずにデータ処理（データのハードディスクへの書き込み処理等）を行う時間が比較的短い場合に適している。
【００６６】
上記の例において、タイムスロットの時間幅W、スライディングウィンドウの時間長さL、及び、連続性判定閾値Ｓについては、実験等により適切な値を定めればよいが、安定したネットワーク環境での一例として、タイムスロットの時間幅Wとして０．１を用い、スライディングウィンドウの時間長さLとしてタイムスロット１０個分である１を用い、連続性判定閾値Ｓとして１／２を用いることにより、良好な結果が得られている。
【００６７】
＜RTTを利用する場合＞
次に、RTTを利用する場合の連続区間の識別処理のフローチャートを図１１に示す。以下では、RTTを利用しない場合との相違点を中心に説明する。
【００６８】
RTTを利用しない場合は、スライディングウィンドウの時間長さＬとして予め定めた長さを用いていたのに対し、RTTを利用する場合の処理は、図１１のステップ３５において、スライディングウィンドウの長さＬをRTTに基づき算出し、それ以降の処理において、RTTに基づき求めたＬを用いて連続区間を判定している。その他の処理については図９の場合と同じである。より詳細には以下のとおりである。
【００６９】
本実施の形態では、入力部１１は、RTTを求めるためのデータとして、アプリケーションサーバ２からユーザ端末３に向かうパケットの他に、ユーザ端末３からプリケーションサーバ２に向かうパケットのうちの一部のパケットを取得してパケット格納部１２に格納することができる。RTT提供部１６は、パケット格納部１２に格納されたデータを参照することにより、例えば、シーケンス番号で送信パケットとそれに対応する応答パケットを識別し、所定の時間毎のRTTを算出することができる。なお、TCPパケットからRTTを算出すること自体は従来技術である。もちろん、RTT提供部１６は、その他の方法でRTTを算出することとしてもよい。例えば、ユーザ待ち時間推定装置１の外部にある装置でRTTを取得し、その装置からRTTを受信することとしてもよい。
【００７０】
ステップ３５において、連続区間識別部１５は、RTT提供部１６から、連続性判定開始位置に最も近い時刻に対応するRTTを取得する。ここでRTTをＴＲと表すと、連続区間識別部１５は、Ｌ＝（ＴＲ＋Ｗ）×Ｎ（Ｎは自然数）としてＬを求める。例えば、ＴＲ＝０．０１、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１１×１０＝１．１となる。また、例えば、Ｒ＝０．０５、Ｗ＝０．１、Ｎ＝１０であるとすると、Ｌ＝０．１５×１０＝１．５となる。
【００７１】
ＲＴＴを用いる場合の処理の概念を図１２を用いて説明する。図１２において、（Ａ）で示される部分は、Ｌ＝１．１の場合であり、（Ｂ）で示される部分は、Ｌ＝１．５の場合を示している。図１２に示すとおり、スライディングウィンドウの長さＬをＲＴＴに応じて伸ばすことにより、ＲＴＴの影響でパケットの出現間隔が間延びする場合であっても、適切に連続区間（ユーザ待ち時間であると推定できる区間）を識別できる。
【００７２】
（実施の形態の効果について）
上記のように、本実施の形態で説明した技術によれば、アプリケーションサーバ２からユーザ端末３に向けて送信されたパケットを取得することによりユーザ待ち時間を推定できるので、ユーザ端末とサーバ間で双方向に送受信されるパケットを取得しなければならない従来技術に比べて、取得すべきデータ量を削減できる。また、本実施の形態の技術では、トランスポート層よりも上位の層のプロトコルに係るヘッダの内容等を参照する必要がないので、トランスポート層よりも上位の層に対して暗号化を行うプロトコルが使用された場合でも、ユーザ待ち時間を推定することが可能になる。
【００７３】
また、本実施の形態の技術では、RTTに応じてスライディングウィンドウの時間長さを変更することが可能なので、通信ネットワークの状況に応じたユーザ待ち時間を推定できる。
【００７４】
本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【符号の説明】
【００７５】
１ ユーザ待ち時間推定装置
２ アプリケーションサーバ
３ ユーザ端末
４ 通信ネットワーク
１１ 入力部
１２ パケット格納部
１３ トラヒック分類部
１４ パケット数集計部
１５ 連続区間識別部
１６ RTT提供部
１７ 出力部
【特許請求の範囲】
【請求項１】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、
前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段と
を備えることを特徴とするユーザ待ち時間推定装置。
【請求項２】
前記連続区間識別手段は、
ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、
前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、
前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段と
を備えることを特徴とする請求項１に記載のユーザ待ち時間推定装置。
【請求項３】
前記スライディングウィンドウのウィンドウ時間長を、前記通信ネットワークにおけるRTTに基づき算出する算出手段を備えることを特徴とする請求項１又は２に記載のユーザ待ち時間推定装置。
【請求項４】
前記算出手段は、予め定めた時間長に、前記RTTの値を加えることにより得た値から、前記スライディングウィンドウのウィンドウ時間長を算出することを特徴とする請求項３に記載のユーザ待ち時間推定装置。
【請求項５】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置が実行するユーザ待ち時間推定方法であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得ステップと、
前記パケット取得ステップにより取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計ステップと、
前記パケット数集計ステップにより算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出ステップと、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別ステップと、
前記連続区間識別ステップにより識別された連続区間を、推定されたユーザ待ち時間として出力する出力ステップと
を備えることを特徴とするユーザ待ち時間推定方法。
【請求項６】
コンピュータを、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置として機能させるためのプログラムであって、コンピュータを、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段、
前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段、
として機能させるためのプログラム。
【請求項１】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段と、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段と、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段と、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段と、
前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段と
を備えることを特徴とするユーザ待ち時間推定装置。
【請求項２】
前記連続区間識別手段は、
ある抽出タイムスロットに対応する連続性判定開始位置から時間進行方向に伸びるスライディングウィンドウに含まれる抽出タイムスロットの合計時間を算出し、前記ウィンドウ時間長に対する前記合計時間の割合が予め定めた閾値以上であるか否かを判定する判定手段と、
前記判定手段により、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値以上であると判定された場合に、連続性判定開始位置を次の抽出タイムスロットにずらし、当該ずらした連続性判定開始位置に基づき前記判定手段による処理を行うスライディング手段と、
前記判定手段と前記スライディング手段による処理を、前記ウィンドウ時間長に対する前記合計時間の割合が前記予め定めた閾値未満であると判定されるまで繰り返し行い、最初の連続性判定開始位置から、最後に前記合計時間の割合が前記閾値以上であると判定されたスライディングウィンドウの末尾までの時間を前記パケットが連続して出現した時間区間であると決定する手段と
を備えることを特徴とする請求項１に記載のユーザ待ち時間推定装置。
【請求項３】
前記スライディングウィンドウのウィンドウ時間長を、前記通信ネットワークにおけるRTTに基づき算出する算出手段を備えることを特徴とする請求項１又は２に記載のユーザ待ち時間推定装置。
【請求項４】
前記算出手段は、予め定めた時間長に、前記RTTの値を加えることにより得た値から、前記スライディングウィンドウのウィンドウ時間長を算出することを特徴とする請求項３に記載のユーザ待ち時間推定装置。
【請求項５】
TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置が実行するユーザ待ち時間推定方法であって、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得ステップと、
前記パケット取得ステップにより取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計ステップと、
前記パケット数集計ステップにより算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出ステップと、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別ステップと、
前記連続区間識別ステップにより識別された連続区間を、推定されたユーザ待ち時間として出力する出力ステップと
を備えることを特徴とするユーザ待ち時間推定方法。
【請求項６】
コンピュータを、TCPベースのアプリケーションサービスを提供するアプリケーションサーバに通信ネットワークを介して接続され、前記アプリケーションサービスを利用するユーザ端末におけるユーザ待ち時間を推定するユーザ待ち時間推定装置として機能させるためのプログラムであって、コンピュータを、
前記アプリケーションサーバから前記ユーザ端末に向けて送信された各パケットを取得し、当該パケットを取得した時刻の情報とともに、当該パケットを記憶手段に格納するパケット取得手段、
前記パケット取得手段により取得されたパケット群から、予め定めた時間幅を有するタイムスロット毎のパケット数を算出するパケット数集計手段、
前記パケット数集計手段により算出されたタイムスロット毎のパケット数に基づき、パケット数が予め定めた検知閾値以上であるタイムスロット群を、抽出タイムスロット群として抽出する抽出手段、
所定のウィンドウ時間長を有するスライディングウィンドウを定め、スライディングウィンドウに含まれる抽出タイムスロットの合計時間と前記ウィンドウ時間長とに基づき、スライディングウィンドウを時間進行方向にずらしながら、パケットが連続して出現した時間区間である連続区間を識別する連続区間識別手段、
前記連続区間識別手段により識別された連続区間を、推定されたユーザ待ち時間として出力する出力手段、
として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−１４２４７３（Ｐ２０１１−１４２４７３Ａ）
【公開日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願番号】特願２０１０−１５８６（Ｐ２０１０−１５８６）
【出願日】平成２２年１月６日（２０１０．１．６）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
【公開日】平成２３年７月２１日（２０１１．７．２１）
【国際特許分類】
【出願日】平成２２年１月６日（２０１０．１．６）
【出願人】（３９９０３５７６６）エヌ・ティ・ティ・コミュニケーションズ株式会社 (321)
【Ｆターム（参考）】
[ Back to top ]