特許 6367106 ユーザデータを用いて通信帯域を計測するプログラム、サーバ、システム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6367106

(24)【登録日】2018年7月13日

(45)【発行日】2018年8月1日

(54)【発明の名称】ユーザデータを用いて通信帯域を計測するプログラム、サーバ、システム及び方法

(51)【国際特許分類】

   H04L 12/70 20130101AFI20180723BHJP

   H04L 12/955 20130101ALI20180723BHJP

   H04W 24/08 20090101ALI20180723BHJP

   H04M 3/00 20060101ALI20180723BHJP

【ＦＩ】

   H04L12/70 100Z

   H04L12/955

   H04W24/08

   H04M3/00 E

【請求項の数】10

【全頁数】13

(21)【出願番号】特願2014-253871(P2014-253871)

(22)【出願日】2014年12月16日

(65)【公開番号】特開2016-116104(P2016-116104A)

(43)【公開日】2016年6月23日

【審査請求日】2017年8月12日

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100135068

【弁理士】

【氏名又は名称】早原 茂樹

(72)【発明者】

【氏名】立花 篤男

(72)【発明者】

【氏名】長谷川 輝之

(72)【発明者】

【氏名】吉田 芳明

【審査官】 大石 博見

(56)【参考文献】

【文献】 特開２０１０−２１３０６５（ＪＰ，Ａ）

【文献】 特開２０１０−２３９３５５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

Ｈ０４Ｌ １２／９５５

Ｈ０４Ｍ ３／００

Ｈ０４Ｗ ２４／０８

(57)【特許請求の範囲】

【請求項1】

端末へ返信するユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信するサーバに搭載されたコンピュータを機能させるプログラムであって、
返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定する第１のステップと、
第１のステップによって真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰ(User Datagram Protocol)パケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信し、第１のステップによって偽と判定された場合、ユーザデータをＴＣＰ(Transmission Control Protocol)パケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信する第２のステップと
を実行させることを特徴とするサーバ用のプログラム。

【請求項2】

第２のステップについて、前記サーバは、ＵＤＰパケット又はＴＣＰパケットを構成する際に、パケット毎に指定データサイズまでユーザデータに追加して疑似バイトを埋めてパディングする
ように実行させることを特徴とする請求項１に記載のサーバ用のプログラム。

【請求項3】

第１のステップについて、前記サーバは、返信すべきユーザデータのパケットをバッファする毎に待機時間タイマを起動し、該待機時間タイマが所定時間値以上となった時、判定結果を真として第２のステップを実行させる
ことを特徴とする請求項１又は２に記載のサーバ用のプログラム。

【請求項4】

第１のステップについて、前記サーバは、ユーザデータの中で、送信優先度が高いパケットをバッファしないように実行させる
ことを特徴とする請求項１から３のいずれか１項に記載のサーバ用のプログラム。

【請求項5】

前記ユーザデータは、ＨＴＴＰ(HyperText Transport Protocol)に基づくものであり、
第１のステップについて、前記サーバは、ＨＴＭＬ(HyperText Markup Language)テキストに基づくユーザデータを、前記送信優先度が高いパケットとしてバッファしないように実行させる
ことを特徴とする請求項４に記載のサーバ用のプログラム。

【請求項6】

請求項１から５のいずれか１項に記載のサーバ用のプログラムをコンピュータによって実行するサーバと通信する「端末」に搭載されたコンピュータを機能させる端末用のプログラムであって、
前記端末は、ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測し、ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測する
ように実行することを特徴とする端末用のプログラム。

【請求項7】

端末へ返信するユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信するサーバであって、
返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定するバッファ判定手段と、
前記バッファ判定手段で真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信する可用帯域推定送信手段と、
前記バッファ判定手段で偽と判定された場合、ユーザデータをＴＣＰパケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信するスループット計測送信手段と
を有することを特徴とするサーバ。

【請求項8】

請求項７に記載のサーバと、該サーバと通信する端末とを有するシステムであって、
前記端末は、
ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測する可用帯域推定手段と、
ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測するスループット計測手段と
を有することを特徴とするシステム。

【請求項9】

前記サーバは、中継サーバであって、
前記端末が、コンテンツ取得要求を、前記中継サーバへ送信し、
前記中継サーバが、前記コンテンツ取得要求を、Ｗｅｂサーバへ送信し、
前記Ｗｅｂサーバが、コンテンツ応答に基づくユーザデータを、前記中継サーバへ返信し、
前記中継サーバが、端末へ返信するコンテンツ応答のユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信する
ことを特徴とする請求項８に記載のシステム。

【請求項10】

サーバから端末へ返信されるユーザデータを用いて、ネットワークの通信帯域を計測する方法において、
前記サーバが、返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定する第１のステップと、
前記サーバは、第１のステップで真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信し、第１のステップで偽と判定された場合、ユーザデータをＴＣＰパケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信する第２のステップと、
前記端末は、ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測し、ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測する第３のステップと
を有することを特徴とする方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークに対してアクティブ計測方式を実行する技術に関する。

【背景技術】

【0002】

インターネットや移動通信のサービス事業者にとって、自ら運営するネットワークの通信帯域を監視することは重要である。通信帯域の劣化を検出した場合、無線基地局の設置や通信帯域制御・規制などによって、その通信帯域を改善する必要がある。具体的には、ネットワークに測定用の試験パケットを転送して通信帯域を計測する「アクティブ計測方式」と、ユーザデータの実際の送受信状態の振る舞いから通信帯域を計測する「パッシブ計測方式」とがある。

【0003】

従来、アクティブ計測方式として、例えば以下のような方法がある。
計測サーバとクライアントとの間で、試験データを送受信し、転送データ量／転送時間から、ＴＣＰ(Transmission Control Protocol)スループットを推定する技術がある（例えば非特許文献１、２参照）。また、計測サーバとクライアントとの間で、複数の試験パケットの時間間隔を制御して送信し（パケットトレイン）、受信側で各試験パケットのキューイング遅延の増加傾向を分析して可用帯域を推定する技術もある（例えば非特許文献３参照）。ここで、（最大）ＴＣＰスループットは、送受信装置に実装されたＴＣＰ輻輳制御機能によって、ネットワーク回線の空き容量に合わせて上限付近に調整される。そのために、理想的な環境にあっては、送受信装置間の可用帯域と強い相関関係にあると考えられる。

【0004】

一方で、測定用の試験パケットをネットワークに送信することなく、送受信装置間の通信帯域を計測する技術もある（例えば非特許文献４、５参照）。この技術によれば、端末上で動作する映像ストリーミングアプリケーションや音声通話アプリケーション自身が、送信データの転送レートを動的に変化させる。そして、パケットロスやパケット遅延の増大が発生しない、成功した転送レートを探索する。

【0005】

また、ユーザデータを用いたアクティブ計測方式として、送受信装置間でユーザデータをペイロード部に埋め込んだ試験パケットを送受信し、可用帯域を推定する技術もある（例えば非特許文献６参照）。この技術は、Linux（登録商標）に実装されたものである。

【0006】

更に、送受信装置間に設定される通信コネクションを高速化するために、ネットワーク内の設備装置が、当該コネクションを複数の通信コネクションに分割してパケットを中継するＴＣＰプロキシ技術もある（例えば非特許文献７参照）。

【0007】

更に、セキュリティを向上させるために、端末からのHTTPコネクションを経路上の通信設備装置で一旦終端し、当該設備装置が代理してＷｅｂサーバへアクセスするウェブプロキシ技術もある（例えば非特許文献８参照）。

【先行技術文献】

【非特許文献】

【0008】

【非特許文献1】SPEEDTEST、[online]、［平成２６年１１月１０日検索］、インターネット＜URL:http://www.speedtest.net/＞

【非特許文献2】iperf、[online]、［平成２６年１１月１０日検索］、インターネット＜URL:http://code.google.com/p/iperf/＞

【非特許文献3】Vinay J. Ribeiro , Rudolf H. Riedi , Richard G. Baraniuk , Jiri Navratil , Les Cottrell, “pathChirp: Efficient Available Bandwidth Estimation for Network Paths,” (2003)、[online]、［平成２６年１１月１０日検索］、インターネット＜URL:http://www.slac.stanford.edu/cgi-wrap/getdoc/slac-pub-9732.ps.gz＞

【非特許文献4】David Hassoun, “Dynamic stream switching with Flash Media Server 3,” April 2008、[online]、［平成２６年１１月１０日検索］、インターネット＜URL:http://www.adobe.com/devnet/adobe-media-server/articles/dynamic_stream_switching.html＞

【非特許文献5】L. De Cicco, S. Mascolo, and V. Palmisano, “Skype Video Responsiveness to Bandwidth Variations,” NOSSDAV, 2008、[online]、［平成２６年１１月１０日検索］、インターネット＜URL: http://c3lab.poliba.it/index.php/MultimediaCC＞

【非特許文献6】村瀬勉 , 下西英之, 長谷川洋平, “TCP オーバレイネットワークの提案,” 電子情報通信学会通信ソサイエティ大会報告(B-7-49), Sept. 2002.

【非特許文献7】Squid (ソフトウェア)、[online]、［平成２６年１１月１０日検索］、インターネット＜URL: http://ja.wikipedia.org/wiki/Squid_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)＞

【発明の概要】

【発明が解決しようとする課題】

【0009】

非特許文献１、２に記載の技術によれば、ＴＣＰスループットを計測するために、ユーザデータ通信とは別に、測定用の試験パケットをネットワークへ送信しなければならない。そのために、ネットワークの通信帯域に高い負荷を与えることとなる。

【0010】

非特許文献３に記載の技術によれば、非特許文献１、２に記載の技術よりも、少量の試験パケットで可用帯域を推定することができる。実際にネットワークに負荷を与えて計測するものではないため、推定結果の精度も比較的低くなる。特に、非特許文献１、２に記載の技術よりも少量ではあるが、試験パケットをネットワークに流入させる必要がある。

【0011】

非特許文献４、５に記載の技術によれば、アプリケーションが実際に使っているデータ転送レートから可用帯域を推定するために、測定用の試験パケットによるネットワーク負荷は発生しない。しかしながら、実際のユーザデータを用いるため、誤って転送レートを可用帯域よりも高くした場合、アプリケーション自身の通信帯域が劣化することとなる。このため、対象アプリケーションは、転送レートを下げる方向に調節することは容易であるが、転送レートを上げる方向に調節することは困難であり、通信帯域を正確に計測することはできない。尚、この技術によれば、通信帯域を計測するために、対象アプリケーションを予め起動しておく必要がある。

【0012】

尚、非特許文献６、７に記載の技術によれば、ユーザ通信の高速化やセキュリティ向上を主な目的としており、通信帯域のアクティブ計測機能を実装したものではない。

【0013】

スマートフォンのような携帯端末を想定した場合、一般に、通信事業者との間で、１ヶ月契約で使用可能なデータ通信量が予め制限されていたり、データ通信量に応じて利用料金が増加する。そのために、そのような携帯端末を用いて、計測用の試験パケットを転送することは、ユーザにとってコスト的な不利益（契約料金の侵食）となり、実際にはできない。
また、非特許文献３に記載の技術のようなデータ転送速度が低い（１計測当たりのデータ転送量が少ない）アクティブ計測方式に、ユーザデータを適用した場合、ユーザデータの受信相違への到着が大幅に遅延し、ユーザが経験する通信帯域が劣化することとなる。

【0014】

そこで、本発明は、ユーザが利用するデータ通信量が大きく変動する場合であっても、ユーザデータを用いてネットワークの通信帯域を計測することができるプログラム、サーバ、システム及び方法を提供することを目的とする。

【課題を解決するための手段】

【0015】

本発明によれば、端末へ返信するユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信するサーバに搭載されたコンピュータを機能させるプログラムであって、
返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定する第１のステップと、
第１のステップによって真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰ(User Datagram Protocol)パケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信し、第１のステップによって偽と判定された場合、ユーザデータをＴＣＰ(Transmission Control Protocol)パケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信する第２のステップと
を実行させることを特徴とする。

【0016】

本発明のサーバ用のプログラムにおける他の実施形態によれば、
第２のステップについて、サーバは、ＵＤＰパケット又はＴＣＰパケットを構成する際に、パケット毎に指定データサイズまで疑似バイトをユーザデータに追加して埋めてパディングする
ように実行させることも好ましい。

【0017】

本発明のサーバ用のプログラムにおける他の実施形態によれば、
第１のステップについて、サーバは、返信すべきユーザデータのパケットをバッファする毎に待機時間タイマを起動し、該待機時間タイマが所定時間値以上となった時、判定結果を真として第２のステップを実行させることも好ましい。

【0018】

本発明のサーバ用のプログラムにおける他の実施形態によれば、
第１のステップについて、サーバは、ユーザデータの中で、送信優先度が高いパケットをバッファしないように実行させることも好ましい。

【0019】

本発明のサーバ用のプログラムにおける他の実施形態によれば、
ユーザデータは、ＨＴＴＰ(HyperText Transport Protocol)に基づくものであり、
第１のステップについて、サーバは、ＨＴＭＬ(HyperText Markup Language)テキストに基づくユーザデータを、送信優先度が高いパケットとしてバッファしないように実行させることも好ましい。

【0020】

本発明によれば、前述したサーバ用のプログラムをコンピュータによって実行するサーバと通信する「端末」に搭載されたコンピュータを機能させる端末用のプログラムであって、
端末は、ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測し、ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測する
ように実行することを特徴とする。

【0021】

本発明によれば、端末へ返信するユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信するサーバであって、
返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定するバッファ判定手段と、
バッファ判定手段で真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信する可用帯域推定送信手段と、
バッファ判定手段で偽と判定された場合、ユーザデータをＴＣＰパケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信するスループット計測送信手段と
を有することを特徴とする。

【0022】

本発明によれば、前述したサーバと、該サーバと通信する端末とを有するシステムであって、
端末は、
ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測する可用帯域推定手段と、
ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測するスループット計測手段と
を有することも好ましい。

【0023】

本発明のシステムにおける他の実施形態によれば、
サーバは、中継サーバであって、
端末が、コンテンツ取得要求を、中継サーバへ送信し、
中継サーバが、コンテンツ取得要求を、Ｗｅｂサーバへ送信し、
Ｗｅｂサーバが、コンテンツ応答に基づくユーザデータを、中継サーバへ返信し、
中継サーバが、端末へ返信するコンテンツ応答のユーザデータを用いて、該端末によってネットワークの通信帯域を計測することができるように送信する
ことを特徴とする。

【0024】

本発明によれば、サーバから端末へ返信されるユーザデータを用いて、ネットワークの通信帯域を計測する方法において、
サーバが、返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定する第１のステップと、
サーバは、第１のステップで真と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信し、第１のステップで偽と判定された場合、ユーザデータをＴＣＰパケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信する第２のステップと、
端末は、ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測し、ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測する第３のステップと
を有することを特徴とする。

【発明の効果】

【0025】

本発明のプログラム、サーバ、システム及び方法によれば、ユーザが利用するデータ通信量が大きく変動する場合であっても、ユーザデータを用いてネットワークの通信帯域を計測することができる。

【図面の簡単な説明】

【0026】

【図1】本発明におけるサーバ−端末間のシーケンス図である。

【図2】可用帯域推定及びスループット推定の違いを表すシーケンス図である。

【図3】本発明におけるサーバ−中継サーバ−端末間のシーケンス図である。

【図4】本発明におけるサーバの機能構成図である。

【発明を実施するための形態】

【0027】

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

【0028】

図１は、本発明におけるサーバ−端末間のシーケンス図である。

【0029】

図１によれば、サーバ１と端末２とが、ネットワークを介して接続されている。そして、サーバ１と端末２との間でＴＣＰコネクションが確立されていると共に、ＵＤＰストリームの通信も可能であるとする。

【0030】

最初に、端末２が、サーバ１へ、ＴＣＰコネクション（ＵＤＰパケットであってもよい）を用いて、HTTP GETリクエスト（コンテンツ要求）を送信する。
次に、サーバ１は、HTTP GETリクエストに対応したHTTP GETレスポンスによって返信するユーザデータを返信する。このとき、サーバ１は、端末２へ返信すべきユーザデータを、端末２によってネットワークの通信帯域を計測することができるように送信する。
これに対し、端末２は、サーバ１から連続して受信するユーザデータを用いて、ネットワークの通信帯域を計測する。

【0031】

本発明によれば、サーバ１は、以下の２つのステップによって、ユーザデータを端末２へ返信する。
［ステップ１：Ｓ１］サーバ１は、返信すべきユーザデータ（HTTPコンテンツ）を所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定（真／偽）する。
［ステップ２：Ｓ２］
Ｓ２１：サーバ１は、Ｓ１によって真と判定された場合（バッファ量が所定閾値以下）、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、「可用帯域推定」に基づいて各ＵＤＰパケットを送信する。
Ｓ２２：逆に、サーバ１は、Ｓ１によって偽と判定された場合（バッファ量が所定閾値よりも多い）、ユーザデータをＴＣＰパケットに構成し、「スループット計測」に基づいて各ＴＣＰパケットを送信する。

【0032】

これに対し、端末２は、以下のように動作する。
Ｓ２１：ＵＤＰパケットのユーザデータを受信した場合、「可用帯域推定」に基づいて送信レートを計測する。
Ｓ２２：ＴＣＰパケットのユーザデータを受信した場合、「スループット計測」に基づいて送信レートを計測する。
計測に用いられたパケットのペイロードには、ユーザデータが含まれている。そのために、端末２は、それらユーザデータをアプリケーションへ出力する。ユーザデータがHTTPコンテンツである場合、Ｗｅｂブラウザへ出力される。

【0033】

図２は、可用帯域推定及びスループット推定の違いを表すシーケンス図である。

【0034】

本発明によれば、所定単位単位時間におけるユーザデータの通信量に応じて、推定に基づく「可用帯域推定」と、比較的精度が高い「スループット計測」とを、適応的に切り換えながら実行される。

【0035】

［Ｓ２１：可用帯域推定］
所定単位時間のバッファ量が少ない場合（転送すべきユーザデータが少ない場合）、ユーザの体感への影響を考慮して、ＵＤＰパケットによって遅延時間を短くすると共に、「可用帯域推定」によって通信帯域を推定する。

【0036】

「可用帯域推定」とは、試験パケットを、その送信間隔が指数関数的に短くなるように調整して送信する技術をいい、代表的にはpathChirp（例えば非特許文献３参照）がある。本発明によれば、試験パケットではなく、ユーザデータを含むパケットを送信する。送信するパケットのペイロードには、各パケットの送信タイミングの時刻情報が含められる。また、可用帯域推定に基づくパケットは、連続的なリアルタイムの転送が必要となるために、ＵＤＰで構成される。連続するＵＤＰパケットを受信した端末２は、その受信時刻を記録する。端末２は、パケット毎に送信時刻と受信時刻との差分となる遅延時間の変動を分析し、可用帯域を推定する。

【0037】

ここで、pathChirpについて、具体的に説明する。トレイン内の隣り合うパケット同士でパケットペアを構成する。そして、そのプローブ転送間隔を指数関数的に減少させながら送信する。パケットの送信レートが可用帯域以上となった場合に、遅延時間の変動が増加する現象を検出する。最初は送信間隔が広いために、遅延時間の変動はみられない。その後、パケット同士の送信間隔が狭まってくると、あるペアから遅延時間の変動が増え始める。遅延時間の変動が増加し始める時のパケットの送信レートに基づいて、可用帯域を推定する。

【0038】

［Ｓ２２：スループット計測］
所定単位時間のバッファ量が多い場合（転送すべきユーザデータが多い場合）、ＴＣＰパケットによってペイロードを長くすると共に、「スループット計測」によって高い精度で通信帯域を計測する。

【0039】

「スループット計測」とは、受信側端末が、単位時間当たりに受信するパケットのデータ量に基づいて、以下のようにＴＣＰスループットを算出する。
ＴＣＰスループット＝受信データ量／遅延時間
遅延時間＝受信時刻−送信時刻
尚、遅延時間は、複数のパケットに基づく平均値又は最大値であることが好ましい。

【0040】

＜実施形態１：パケットに対する疑似パディングの使用＞
Ｓ２１及びＳ２２について、サーバ１は、ＵＤＰパケット又はＴＣＰパケットを構成する際に、パケット毎に指定データサイズまで疑似バイトを埋めて「パディング」する。即ち、１つのパケットに埋めるユーザデータが指定データサイズに達しない場合に、残りの部分に、例えばNullバイト列で埋める。指定データサイズは、ＵＤＰパケット又はＴＣＰパケットそれぞれで指定されたものであってもよい。ユーザデータを用いて、試験パケットと同様に構成する。

【0041】

＜実施形態２：バッファに対する待機時間タイマの使用＞
Ｓ１について、サーバ１は、返信すべきユーザデータのパケットをバッファする毎に「待機時間タイマ」を起動する（タイマのリスタート）。その待機時間タイマが所定時間値以上となった時、判定結果を真としてＳ２１を実行させる。即ち、「可用帯域推定」が実行される。これによって、端末を操作するユーザの体感について、通信帯域の計測におけるユーザデータの到着遅延の増大を抑制することができる。

【0042】

＜実施形態３：優先度の高いパケットのバッファ除外＞
Ｓ１について、サーバ１は、ユーザデータの中で、送信優先度が高いパケットをバッファしないように実行させる。優先度とは、ユーザデータの特性によって予め決められたものである。

【0043】

ここで、ユーザデータが、ＨＴＴＰに基づくものであるとする。このとき、Ｓ１について、サーバ１は、ＨＴＭＬテキストに基づくユーザデータを、送信優先度が高いパケットとしてバッファしないように実行させる。レスポンスとしてのＨＴＭＬテキストは、端末２が、Ｗｅｂサーバ１から最初にダウンロードするユーザデータである。このパケットを、送信優先度が高いパケットとしてバッファしないことによって、ユーザが視認する端末のＷｅｂブラウザへの表示の遅延をできる限り短くすることができる。

【0044】

理由として、一般的なＨＴＭＬテキストはデータサイズが小さいことに基づく。そのために、ＨＴＭＬテキストをバッファした場合、バッファの所定閾値まで蓄積することなく、所定のタイムアウトまで、ユーザデータの送信が停止する可能性が高い。端末２は、ＨＴＭＬテキストが到着しない限り、次のコンテンツデータの受信を開始しないこととなる。そのような、ＨＴＭＬテキストの転送停止は、ユーザが視認する端末のＷｅｂブラウザへの表示の遅延につながる。
一方で、ＨＴＭＬテキスト以外のコンテンツデータは、そのデータサイズが大きいため、短時間で、バッファの所定閾値まで蓄積されることとなる。この実施形態によれば、ＨＴＭＬテキストのような小さいユーザデータによって、通信帯域を計測することなく、コンテンツのような大きいユーザデータによって通信帯域を計測しようとする。

【0045】

尚、ＨＴＭＬテキストか又はそれ以外のコンテンツデータかを判定するために、例えばＨＴＭＬヘッダに含まれているContent-Typeエンティティヘッダフィールドを参照することも好ましい。このフィールドには、一般的に、ＨＴＭＬテキストの場合、text/htmlのヘッダ情報が付与され、画像や映像のようなコンテンツデータの場合、image/jpegや video/mpeg等のヘッダ情報が付与される。

【0046】

他の実施形態として、バッファの可否を選択する方法として、ＨＴＭＬテキスト以外に、ＩＰヘッダのＴＯＳ(Type Of Service)値を用いることも好ましい。ＴＯＳ値（８ビット）は、通信サービスの種別に基づいて、転送の優先度を表す目的使用される。

【0047】

図３は、本発明におけるサーバ−中継サーバ−端末間のシーケンス図である。

【0048】

図３によれば、図１と比較して、既存のＷｅｂサーバ（アプリケーションサーバ）と端末２との間に、本発明の特徴ある中継サーバ１が配置されている。図３のシステムによれば、Ｗｅｂサーバに本発明の機能を搭載することなく、ユーザの端末２からみて、何れのＷｅｂサーバに対する通信帯域であっても計測することができる。また、本発明のサーバの機能を、既存のＷｅｂサーバに実装することなく、中継サーバ１を介して実現することができる。

【0049】

ここで、本発明を中継サーバに搭載した理由としては、以下の２つがある。
第１に、通信帯域の計測が最も必要とされるのは、無線リンクの区間である。無線リンクを介して中継サーバ−端末間の通信帯域を計測することが好ましい。
第２に、何れのＷｅｂサーバとの間の通信帯域を計測するために、通信事業者設備に中継サーバを配置することが好ましい。

【0050】

中継サーバ１は、端末との間のＴＣＰコネクションと、Ｗｅｂサーバとの間のＴＣＰコネクションとを別々に確立する。
（Ｓ３１）端末２は、Ｗｅｂサーバへ送信すべきHTTP GETリクエストについて、ＵＤＰ又はＴＣＰヘッダを付与し、宛先ＩＰアドレスとして中継サーバ１を指定したパケットを、中継サーバ１へ送信する。
（Ｓ３２）次に、中継サーバ１は、受信したパケットのＵＤＰ又はＴＣＰヘッダを除去し、HTTP GETリクエストを抽出する。そのHTTP GETリクエストから、通信先のＷｅｂサーバのＩＰアドレス等の情報を取得する。そして、中継サーバ１は、そのHTTP GETリクエストについて、ＵＤＰ又はＴＣＰヘッダを付与し、宛先ＩＰアドレスとしてＷｅｂサーバを指定したパケットを、Ｗｅｂサーバへ送信する。
（Ｓ３３）これに対し、Ｗｅｂサーバは、受信したパケットのＵＤＰ又はＴＣＰヘッダを除去し、HTTP GETリクエストを抽出する。そして、Ｗｅｂサーバは、リクエストに対応するHTMLテキスト及びコンテンツデータのパケットにＵＤＰ又はＴＣＰヘッダを付与し、宛先ＩＰアドレスとして中継サーバ１を指定したパケットを、中継サーバ１へ送信する。

【0051】

そして、中継サーバ１は、Ｗｅｂサーバから受信したパケットを、本発明のバッファに入力する。その後、中継サーバ１は、前述したＳ１及びＳ２の処理を実行する。尚、中継サーバ１は、HTTP GETレスポンスのみについて、通信帯域の計測を実行するものであってもよい。その場合、ＯＳ（例えばLinux（登録商標）やAndroid（登録商標）等）に実装されたiptables機能を用いて、パケットを区別するものであってもよい。

【0052】

結果的に、端末２は、中継サーバ１からのユーザデータの受信と同時に、通信帯域を計測することができる。

【0053】

図４は、本発明におけるサーバの機能構成図である。

【0054】

図４のサーバは、図１のサーバ１であってもよいし、図３の中継サーバ１であってもよい。図４によれば、サーバ１は、バッファ判定部１１と、可用帯域推定送信部１２と、スループット計測部１３とを有する。これら機能構成部は、サーバに搭載されたコンピュータを機能させるプログラムを実行することによって実現される。また、これら機能構成部の処理の流れは、パケット転送方法としても理解できる。

【0055】

バッファ判定部１１は、返信すべきユーザデータを所定単位時間でバッファし、そのバッファ量が所定閾値以下か否かを判定する（図１のＳ１参照）。
可用帯域推定送信部１２は、バッファ判定部１１で真（バッファ量が所定閾値以下）と判定された場合、ユーザデータを分割し、分割された各データをＵＤＰパケットに構成し、可用帯域推定に基づいて各ＵＤＰパケットを送信する（図１のＳ２１参照）。
スループット計測送信部１３は、バッファ判定部１１で偽（バッファ量が所定閾値よりも多い）と判定された場合、ユーザデータをＴＣＰパケットに構成し、スループット計測に基づいて各ＴＣＰパケットを送信する（図１のＳ２２参照）。

【0056】

これに対し、端末２は、ＵＤＰパケットのユーザデータを受信した場合、可用帯域推定に基づいて送信レートを計測し、ＴＣＰパケットのユーザデータを受信した場合、スループット計測に基づいて送信レートを計測する。また、例えばHTTPレスポンスのユーザデータは、Ｗｅｂブラウザへ出力される。

【0057】

以上、詳細に説明したように、本発明のプログラム、サーバ、システム及び方法によれば、ユーザが利用するデータ通信量が大きく変動する場合であっても、ユーザデータを用いてネットワークの通信帯域を計測することができる。ユーザデータを用いるために、特定の試験パケットを転送する必要がなく、ユーザ毎に契約されたデータ通信量を浸食することがない。また、ユーザデータの転送データ量が少ない場合、ＵＤＰパケットに構成した可用帯域推定によって通信帯域を計測するために、長いペイロードで且つウィンドウ制御を伴うＴＣＰを用いることがなく、ユーザデータの到着遅延を小さくすることができる。

【0058】

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

【符号の説明】

【0059】

１ サーバ、中継サーバ
１１ バッファ判定部
１２ 可用帯域推定送信部
１３ スループット計測送信部
２ 端末
３ Ｗｅｂサーバ

【図1】

【図2】

【図3】

【図4】