JPWO2019244966A1 - 通信装置、通信方法及びプログラム - Google Patents

Abstract

ネットワークの状態に拘わらず、パケットロスを抑止し、かつ、ネットワークの利用効率を向上させる。通信装置は、データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部と、前記データ送信先の装置との間のネットワークの状態をセッション単位で監視する監視部と、前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する転送レート制御部と、を備える。

Description

本発明は、通信装置、通信方法及びプログラムに関する。

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１８−１１８８５２号（２０１８年 ６月２２日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）における輻輳制御アルゴリズムとして、パケットロスベース方式や遅延ベース方式、これらを組み合わせたハイブリッド方式が知られている。パケットロスベース方式は、パケットのロスを観測し、ロスが増えれば輻輳が発生したと見なして送信量を抑えるものであり、ＣＵＢＩＣアルゴリズムなどがある。また、遅延ベース方式は、パケットの遅延を観測し、遅延量が増えたら輻輳状態になったと判断して送信量を減らすものであり、Ｗｅｓｔｗｏｏｄ＋等の方式がある。

特許文献１には、送信バッファの空き容量を常時監視し、受信側の装置から通知されたウィンドウサイズを、送信バッファの空き容量に基づいて変更することで、スループットの低下を防止することができるという通信装置が開示されている。

また、特許文献２には、通信速度に応じて、ＴＣＰ通信に用いる送信用バッファサイズ及び受信用バッファサイズを適切なサイズに変更することができるという端末が開示されている。

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

以下の分析は、本発明によって与えられたものである。上記したパケットロスベース方式のものは、スロースタート方式を基本としているため、ネットワークの理論的な最大スループットを超えるトラフィックが流れ込んだ場合、パケットロスと再送とを繰り返すことになる。結果として、通信のみならず、ユーザの体感ＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）も悪化してしまうことになる。

図１３は、流入トラフィックに対し、伝送路の最大スループットが相対的に小さい、所謂狭帯域通信におけるＴＣＰ制御によるスループットの変化を表した図である。図１３に示すとおり、スロースタート後、伝送路上のスループットを超えるトラフィックが流入すると、パケットロスが発生し、ウィンドウサイズを小さくした上で、ロスしたパケットの再送が行われる。一方、その後も同程度のトラフィックが流入する場合、図１３の下段の網掛け領域に示すように、累積パケットロス量は増大していくことになる。結果として、ＴＡＴの増大、ユーザの体感ＱｏＥの悪化が発生する。また、ネットワークの状態も常に一定ではなく刻々と変化する場合があり、対応が遅れればその分だけ実質的なネットワークリソースの利用効率が落ちてしまうことになる。

本発明は、ネットワークの状態に拘わらず、安定してパケットロスを抑止し、ネットワークの利用効率の向上に貢献できる通信装置、通信方法及びプログラムを提供することを目的とする。

第１の視点によれば、データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部と、前記データ送信先の装置との間のネットワークの状態をセッション単位で監視する監視部とを備える通信装置が提供される。この通信装置は、さらに、前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する転送レート制御部を備える。

第２の視点によれば、データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部を備えた通信装置が、前記データ送信先の装置との間のネットワークの状態をセッション単位で監視するステップと、前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更するステップと、を含む通信方法が提供される。本方法は、データ送信先の装置に対してデータを送信する通信装置という、特定の機械に結びつけられている。

第３の視点によれば、データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部を備えた通信装置に、前記データ送信先の装置との間のネットワークの状態をセッション単位で監視する処理と、前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する処理と、を実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジトリーな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、ネットワークの状態に拘わらず、パケットロスを抑止し、かつ、ネットワークの利用効率を向上させることが可能となる。即ち、本発明は、背景技術に示したＴＣＰで通信する通信装置を、パケットロスの抑止とネットワークの利用効率の面で、飛躍的に向上させたものへと変換するものとなっている。

本発明の一実施形態の構成を示す図である。 本発明の一実施形態の変形構成を示す図である。 本発明の第１の実施形態の構成を示す図である。 本発明の第１の実施形態のＰｒｏｘｙサーバの動作概要を説明するための図である。 本発明の第１の実施形態のＰｒｏｘｙサーバの構成を示す図である。 本発明の第１の実施形態のＰｒｏｘｙサーバが保持するセッション情報の一例を示す図である。 本発明の第１の実施形態の動作を表したシーケンス図である。 本発明の第１の実施形態の効果を説明するための図である。 比較例の方式による複数のセッション接続時の累積パケットロス量を説明するための図である。 本発明の第１の実施形態による複数のセッション接続時の効果を説明するための図である。 ネットワーク状況が変化した際の効果の違いを説明するための図である。 ネットワーク状況が変化した際の効果の違いを説明するための別の図である。 狭帯域通信におけるＴＣＰ制御によるスループットの変化を表した図である。 本発明のＰｒｏｘｙサーバを構成するコンピュータの構成を示す図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。また、以降の説明で参照する図面等のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。プログラムはコンピュータ装置を介して実行され、コンピュータ装置は、例えば、プロセッサ、記憶装置、入力装置、通信インターフェース、及び必要に応じ表示装置を備える。また、コンピュータ装置は、通信インターフェースを介して装置内又は外部の機器（コンピュータを含む）と、有線、無線を問わず、交信可能に構成される。また、図中の各ブロックの入出力の接続点には、ポート乃至インターフェースがあるが図示省略する。また、以下の説明において、「Ａ及び／又はＢ」は、Ａ及びＢの少なくともいずれかという意味で用いる。

本発明は、その一実施形態において、図１に示すように、ＴＣＰ終端部１１と、監視部１２と、転送レート制御部１３と、を備える通信装置１０にて実現できる。このような通信装置１０の典型例としてはコンテンツサーバが挙げられる。

より具体的には、ＴＣＰ終端部１１は、データ送信先装置２０とのＴＣＰ通信を終端する。監視部１２は、前記データ送信先装置２０との間のネットワーク（回線）の状態をセッション単位で監視する。このネットワーク（回線）の状態を表す指標としては、スループットやＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）などが挙げられる。

そして、転送レート制御部１３は、前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する。例えば、ネットワークの状態が悪いと判定した場合、転送レート制御部１３は、パケットロスの増大や受信装置からのウィンドウサイズの通知の受信有無に拘わらず、送信バッファのサイズを小さくする制御を行う。これにより、パケットロスが増える前に転送レートを落とし、パケットロスの発生を抑えることが可能になる。

逆に、ネットワークの状態が良いと判定した場合、転送レート制御部１３は、パケットロスの増大や受信装置からのウィンドウサイズの通知の受信有無に拘わらず、送信バッファのサイズを大きくする制御を行う。これにより、良好な状態になるネットワークリソースを有効に活用することが可能となる。

なお、本発明を適用可能な通信装置は、図１に示す態様の通信装置１０に限られない。例えば、図２に示すようにデータ送信元装置３０からデータ送信先装置２０へとデータを中継する中継装置として機能する通信装置１０ａにも本発明を適用することができる。この場合の通信装置１０ａも同様に、ネットワークの状態に応じて、転送レートを動的に制御するため、パケットロスの発生を抑え、ネットワークリソースを有効に利用することが可能となる。

［第１の実施形態］
続いて、本発明を移動体通信網に配置され、データの中継を行うＰｒｏｘｙサーバに適用した第１の実施形態について、図面を参照して詳細に説明する。図３は、本発明の第１の実施形態の構成を示す図である。図３を参照すると、通信端末２００と、コンテンツサーバ３００との間にＰｒｏｘｙサーバ１００が配置された構成が示されている。なお、図３では省略しているが、Ｐｒｏｘｙサーバ１００と、基地局４００との間に、ＢｏｒｄｅｒＧａｔｅＷａｙ（ＢＧＷ）やＳ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）、Ｐ−ＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）といった機器が配置されていてもよい。

通信端末２００は、基地局４００を介して、コンテンツサーバ３００にアクセスし、コンテンツの送信を受ける。本実施形態では、通信端末が、データ送信先の装置となる。なお、通信端末２００は、スマートフォンなどのほか、車載端末やコンテンツサーバ３００から受信したコンテンツを再配布する機器であってもよい。

コンテンツサーバ３００は、動画や音楽などの各種コンテンツを提供するサーバである。

Ｐｒｏｘｙサーバ１００は、通信端末２００とコンテンツサーバ３００との間に配置され、通信端末２００とコンテンツサーバ３００との間のＴＣＰコネクション１、２を終端する。Ｐｒｏｘｙサーバ１００は、前記各ＴＣＰコネクションについて、それぞれウィンドウサイズ等の設定値の適切な設定を行うことで、パケットロスや再送を抑えるために配置される。本実施形態のＰｒｏｘｙサーバ１００は、図３の無線区間を含むＴＣＰコネクション１の最適化を行うものとして説明する。

Ｐｒｏｘｙサーバ１００は、ＴＣＰコネクション１上のセッション毎に、所定の時間間隔でスループット、ＲＴＴ、パケットロス状況、ＡＣＫ密度（後述）を測定する。そして、その測定結果に基づいて、通信端末２００向けのデータの送信バッファのサイズを調整する。

また、本実施形態では、Ｐｒｏｘｙサーバ１００はトラフィック全体のリソースを収容できるリソースを持ちＰｒｏｘｙサーバ自体のリソース枯渇は発生しないものとして説明する。なお、より望ましい形態において、Ｐｒｏｘｙサーバ１００のリソースの不足が予測される場合は、ロードバランサによる複数プロキシサーバへの分散、もしくは別経路への迂回などを行うことが望ましい。

図４は、本実施形態のＰｒｏｘｙサーバ１００の動作概要を説明するための図である。図４は、ＴＣＰコネクション１上で開始された２つのセッション１、２を示している。また、セッション１、２上の破線の楕円は測定タイミングを示している。図４に示すように、Ｐｒｏｘｙサーバ１００は、セッション開始後、所定の時間間隔で、測定を開始し、その結果に基づいて通信端末２００向けのデータの送信バッファのサイズを決定する。さらに、本実施形態のＰｒｏｘｙサーバ１００は、セッション２の開始時に、セッション１の測定結果を用いて送信バッファのサイズを決定する。これにより、セッション２は通信開始当初から望ましい速度で通信できることになる。

続いて、上記機能を実現するためのＰｒｏｘｙサーバ１００の構成について図面を参照して詳細に説明する。図５を参照すると、ＲＴＴ計測部１１１と、スループット計測部１１２と、ＡＣＫ密度計測部１１３と、パケットロス計測部１１４と、送信バッファ変更部１２１と、ＴＣＰ終端部１０１と、セッション管理部１３１とを備えた構成が示されている。

ＲＴＴ計測部１１１は、通信端末２００に対して送信したパケットに対し、通信端末２００から送信されたＡＣＫパケットの時刻に基づいて、ＲＴＴを計測する。

スループット計測部１１２は、セッションごとのスループットを計測する。スループットは、送信データサイズ／単位時間により計算してもよいが、ウィンドウサイズと上記したＲＴＴを用いて計算することもできる。この場合、スループット（ｂｐｓ）は、ウィンドウサイズ＊８／ＲＴＴにより計算することができる。

ＡＣＫ密度計測部１１３は、単位時間あたりのＡＣＫ受信パケットの平均値であるＡＣＫ密度という指標を計測する。上記送信データサイズ／単位時間によりスループットを計算する場合、送信データサイズは通常Ｍｂｉｔ（メガビット）単位、単位時刻はミリ秒以下の単位となる。ネットワークの変化をより精密に把握することを目的に、単位時刻を短くしていくと、単位時刻は０に近似していくため、スループットの計算誤差が非常に大きくなる場合がある。このＡＣＫ密度は、送信データサイズではなく、ＡＣＫパケットの変化量である密度を計測するため、測定誤差は小さくなる。従って、上記ＲＴＴ、スループットと併用してＡＣＫ密度を測定することで、計測結果の信頼性向上を図ることが可能となる。

パケットロス計測部１１４は、単位時間あたりのパケットロス量を計測する。以上のＲＴＴ計測部１１１、スループット計測部１１２、ＡＣＫ密度計測部１１３及びパケットロス計測部１１４が上記した監視部１２に相当する。

セッション管理部１３１は、上記ＲＴＴ計測部１１１、スループット計測部１１２、ＡＣＫ密度計測部１１３及びパケットロス計測部１１４で計測されたセッションごとのデータをセッションごとに管理する。

図６は、セッション管理部１３１にて管理されるセッション情報の一例を示す図である。図６の例では、セッションごとに直近に計測されたＲＴＴ、スループット、ＡＣＫ密度、パケットロス量と、現在適用中の送信バッファのサイズを管理可能となっている。

送信バッファ変更部１２１は、セッション管理部１３１に格納された各計測データに基づいて、送信バッファのサイズの変更の要否を判定する。前記判定の結果、送信バッファのサイズの変更が必要と判定した場合、ＴＣＰ終端部１０１に、送信バッファのサイズの変更を指示する。従って、この送信バッファ変更部１２１が、上記した転送レート制御部１３に相当する。また、送信バッファ変更部１２１は、セッション管理部１３１に保持されている送信バッファの値を、前記指示した送信バッファのサイズに更新する。

送信バッファのサイズの変更の要否は、例えば、セッション管理部１３１に格納された各計測データに、有意な変化があったか否かにより判定することができる。また、送信バッファのサイズの増減は、次のように決定することができる。例えば、ネットワークの状況が前回の判定時点よりも悪化している場合、所定値だけ送信バッファのサイズを減らすことができる。また、例えば、ネットワークの状況が前回の判定時点よりも良くなっている場合、所定値だけ送信バッファのサイズを増やすことができる。このように、送信バッファのサイズを増減することで、ネットワークの状況に応じたレートで送信を行うことが可能となり、結果としてパケットロスを減らし、ネットワークの利用効率を向上させることが可能となる。このネットワークの状況は、例えば、上記ＲＴＴ、スループット、ＡＣＫ密度、パケットロス量などにそれぞれ重みを与えて計算したスコアにより計算してもよい。

また、前記送信バッファ変更部１２１による送信バッファのサイズの変更の要否は次のような基準で判断させることもできる。例えば、ＲＴＴ、スループット、ＡＣＫ密度、パケットロス量といった計測データのカテゴリ毎に、計測値に応じた適正送信バッファサイズを複数設定しておく。そして、送信バッファ変更部１２１は、これらを参照して送信バッファサイズを決定する。また、より望ましい形態において、送信バッファ変更部１２１が、これらの計測データから求めた送信バッファサイズのうち、最も小さい送信バッファサイズを選択させることができる。

もちろん、ネットワークの状況の変化の度合いに応じて、送信バッファのサイズの増減幅を変更することもできる。例えば、ネットワークの状況が前回の判定時点よりも極端に悪化している場合、送信バッファのサイズの減少幅を通常よりも大きい値にすることができる。また、例えば、ネットワークの状況が前回の判定時点よりも極端に良くなっている場合、送信バッファのサイズの増大幅を通常よりも大きい値にすることができる。もちろん、ネットワークの状況を示すスコアと、２つ以上の閾値とを比較することで、送信バッファのサイズの変更幅を段階的に変更してもよい。

ＴＣＰ終端部１０１は、コンテンツサーバ３００とＰｒｏｘｙサーバ１００間のＴＣＰコネクション２と、通信端末２００とＰｒｏｘｙサーバ１００間のＴＣＰコネクション１とをそれぞれ終端する。また、ＴＣＰ終端部１０１は、通信端末２００とＰｒｏｘｙサーバ１００間のＴＣＰコネクション１上のセッションについて、上記送信バッファ変更部１２１にて決定された送信バッファのサイズを適用してデータの送信を行う。当然に、通信端末２００に通知するウィンドウサイズも、この送信バッファの空き容量に基づいて決定される。

また、ＴＣＰ終端部１０１は、新規セッションの開始時に、セッション管理部１３１に保持されている既存セッションの計測情報を参照して送信バッファサイズの初期値を決定する。これにより、通信当初から適切なスループットを得ることが可能となる。

続いて、本実施形態の動作について図面を参照して詳細に説明する。図７は、本発明の第１の実施形態の動作を表したシーケンス図である。図７を参照すると、まず、通信端末２００からコンテンツの送信要求（リクエスト）を受信したＰｒｏｘｙサーバ１００は、通信端末２００との間にＴＣＰコネクションを確立する。

次に、Ｐｒｏｘｙサーバ１００は、コンテンツサーバ３００との間にＴＣＰコネクションを確立し、通信端末２００からのコンテンツの送信要求（リクエスト）を送信する。

次に、Ｐｒｏｘｙサーバ１００は、既存セッションの計測情報を参照して（Ｓ００１）、送信バッファサイズの初期値を決定する（Ｓ００２）。ここで例えば、Ｐｒｏｘｙサーバ１００と通信端末２００間に既存のセッションが存在する場合には、その計測値を用いて、送信バッファサイズの初期値を決定することができる。

前記リクエストを受けたコンテンツサーバ３００が、コンテンツの送信要求（リクエスト）に対するＡＣＫ、次いで、コンテンツの送信を行うと（レスポンス）、Ｐｒｏｘｙサーバ１００は、これらを通信端末２００に転送する。これにより、通信端末２００でコンテンツの再生等が開始される。

以降、Ｐｒｏｘｙサーバ１００は、所定の時間間隔で、ネットワークの状況の計測と（ステップＳ１０１、Ｓ２０１「ＮＷ計測」）と、送信バッファサイズの変更（ステップＳ１０２、Ｓ２０２「送信バッファ制御」）とを繰り返す。

以上により、セッションが終了するまで、Ｐｒｏｘｙサーバ１００によるネットワークの状況に応じた送信バッファサイズの最適化が行われる。

続いて、本実施形態の効果について図面を用いて説明する。図８は、本発明の第１の実施形態の効果を説明するための図である。図８に示すように、既存のセッションがない状態でスロースタートを行って、伝送路上のスループットを超えるトラフィックが流入すると、パケットロスが計測される。また、パケットのロスによりＲＴＴやスループットが低下するので、送信バッファのサイズの減少が実施される。以降は、所定の間隔で、ネットワークの状態が計測され、この計測結果に基づいた送信バッファのサイズのコントロールが行われる（図８の下段「送信バッファ制御実施」参照）。これにより、パケットロスの発生が抑止される。

その後、データの送信が止まった場合であっても、本実施形態のＰｒｏｘｙサーバ１００は、ネットワークの状態を計測しているため、送信バッファのサイズを維持する。このため、図８の右側に示すように、データの送信が再開された場合に、速やかに伝送路上の最大スループットに近いスループットを出すことが可能となっている。なお、前記送信バッファのサイズを維持する期間は一定期間でよく、その後は所定の初期値に戻しても良い。このようにすることで、Ｐｒｏｘｙサーバ１００のリソースを有効に活用することができる。

また、本実施形態は複数のセッションが発生した場合において、よりその効果を発揮する。図９は、送信バッファのサイズの制御を行わない比較例において、連続して３つのセッションが開始された場合のパケットロスの発生箇所を示している。図９に示されたように、セッション１つであれば、帯域幅（通信路容量）に余裕がある場合であっても、セッションが２以上となると、伝送路上の最大スループットを超えて流入したパケットがロスとなる。

図１０は、本実施形態の送信バッファのサイズ制御を実施した場合において、連続して３つのセッションが開始された場合のパケットロスの発生箇所を示している。図１０に示されたとおり、セッション＃２の開始後、伝送路上の最大スループットを超えて流入したパケットがロスとなるが、直ちに、送信バッファサイズの減少制御が行われるため、以降のセッション＃２のパケットのロスは抑止される。そして、セッション＃３の開始時は、セッション＃２の計測データを用いて送信バッファのサイズ初期値が決定される。このため、初期輻輳ウィンドウとして大きな値が設定されていたとしても、セッション開始時から抑制された転送レートで通信を行うことが可能となっている。

さらに、本実施形態は、ネットワークの状況の変動にも柔軟に対応することが可能となっている。図１１は、帯域制限のない状態から帯域制限２０Ｍｂｐｓに変化した際のスループットの変化を測定した図である。図１１の破線は帯域が変化したタイミングを表している。上段のグラフは、本実施形態を用いた場合のスループットの変化を表している。また、中段のグラフは、ＣＵＢＩＣアルゴリズムかつ広帯域専用設定で運用した際のスループットの変化を表している。また、下段のグラフは、ＣＵＢＩＣアルゴリズムかつ狭帯域専用設定で運用した際のスループットの変化を表している。

中段のＣＵＢＩＣ広帯域専用設定では、波形が荒くスループットが不安定になっており、結果として再送継続時間や再送帯域（再送帯域ピーク値）も大きくなっている。一方、本実施形態では、再送継続時間及び再送帯域をそれぞれ小さくすることに成功している。その理由は、ネットワークの計測結果に基づいて、動的に送信バッファのサイズを追従させているためである。なお、下段のＣＵＢＩＣ狭帯域専用設定では、ＣＵＢＩＣ広帯域専用設定よりも、再送継続時間や再送帯域（再送帯域ピーク値）が小さくなっているが、本実施形態には及ばない。

図１２は、帯域制限２０Ｍｂｐｓが設定されている状態から帯域制限のない状態に変化した際のスループットの変化を測定した図である。図１２の破線は帯域が変化したタイミングを表している。図１２の上段のグラフは、本実施形態を用いた場合のスループットの変化を表している。また、中段、下段のグラフは、それぞれＣＵＢＩＣアルゴリズムの広帯域専用設定と狭帯域専用設定で運用した際のスループットの変化を表している。

中段のＣＵＢＩＣ広帯域専用設定では、帯域制限が設定されている区間の波形が荒くスループットが不安定になっており、パケットロスが発生している。一方、本実施形態では、帯域の変化の前後において、スループットは安定しており、かつ、ＣＵＢＩＣ狭帯域専用設定との比較において、帯域制限がなくなった後のスループットの立ち上がりが早くなっている。

以上の本実施形態の効果は以下のようにまとめることができる。
（１）本実施形態では、計測済みのネットワーク状況に基づいて、新規セッションにも適切な送信バッファサイズを設定することができる（図９、図１０参照）。
（２）本実施形態では、ネットワークの状況に応じて送信バッファサイズの調整が行われるため、パケットロスが減り、スループットも安定する（図８、図１１、図１２参照）。
（３）マルチセッション接続時において上記（１）、（２）の効果は発揮される。

以上、本発明の実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示したネットワーク構成、各要素の構成、メッセージの表現形態は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。

例えば、上記した実施形態では、ＲＴＴ、スループット、ＡＣＫ密度及びパケットロスを計測するものとして説明したが、これらは、あくまでネットワークの状況を把握するための計測項目の一例である。ＲＴＴ、スループット、ＡＣＫ密度及びパケットロスのうち、いずれかの項目を省略し、または他の項目に置換することもできる。また、これらの項目の計測間隔は、Ｐｒｏｘｙサーバ１００やネットワークに与える負荷や、測定精度などに応じて適宜設定することができる。また、これらの項目の計測間隔は、同一である必要はなく、項目毎に測定間隔を変えても良い。

また、上記した実施形態では、Ｐｒｏｘｙサーバ１００に送信バッファサイズの制御を行わせるものとして説明したが、同様の制御をコンテンツサーバ３００に行わせてもよい。

上記した実施形態では、Ｐｒｏｘｙサーバ１００から通信端末２００に向かう下りデータを制御の対象にするものとして説明したが、通信端末２００からコンテンツサーバ３００向けの上りデータについてもＰｒｏｘｙサーバ１００の制御の対象としてもよい。この場合、Ｐｒｏｘｙサーバ１００は、図３のＴＣＰコネクション２の最適化を行うことになる。

また、上記した実施形態に示した手順は、Ｐｒｏｘｙサーバ１００として機能するコンピュータ（図１４の９０００）に、Ｐｒｏｘｙサーバ１００としての機能を実現させるプログラムにより実現可能である。このようなコンピュータは、図１４のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１０、通信インターフェース９０２０、メモリ９０３０、補助記憶装置９０４０を備える構成に例示される。すなわち、図１４のＣＰＵ９０１０にて、ネットワーク状況の監視プログラムや送信バッファサイズ変更プログラムを実行し、その補助記憶装置９０４０等に保持された各計算パラメータの更新処理を実施させればよい。

即ち、上記した実施形態に示したＰｒｏｘｙサーバ１００の各部（処理手段、機能）は、Ｐｒｏｘｙサーバ１００に搭載されたプロセッサに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することができる。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点による通信装置参照）
［第２の形態］
上記した通信装置の監視部は、前記ネットワークの状態として、少なくとも該当セッションのスループット、ＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）、パケットロスの発生割合の少なくとも１以上を監視する構成を採ることができる。
［第３の形態］
上記した通信装置の監視部は、前記ネットワークの状態として、単位時間当たりのＡＣＫ受信パケットの受信数を監視することもできる。
［第４の形態］
上記した通信装置は、同一のＴＣＰコネクションのネットワーク状態を示す測定済データを参照して、送信バッファのサイズの初期値を決定する構成を採ることもできる。
［第５の形態］
上記した通信装置は、コンテンツサーバと、前記コンテンツサーバに基地局を介してデータの送信を要求する通信端末との間に配置され、前記通信端末との間のＴＣＰコネクションを終端するプロキシサーバとして機能する構成を採ることができる。
［第６の形態］
（上記第２の視点による通信方法参照）
［第７の形態］
（上記第３の視点によるプログラム参照）
なお、上記第６〜第７の形態は、第１の形態と同様に、第２〜第５の形態に展開することが可能である。

なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０、１０ａ 通信装置
１１ ＴＣＰ終端部
１２ 監視部
１３ 転送レート制御部
２０ データ送信先装置
３０ データ送信元装置
１００ Ｐｒｏｘｙサーバ
１０１ ＴＣＰ終端部
１１１ ＲＴＴ計測部
１１２ スループット計測部
１１３ ＡＣＫ密度計測部
１１４ パケットロス計測部
１２１ 送信バッファ変更部
１３１ セッション管理部
２００ 通信端末
３００ コンテンツサーバ
４００ 基地局
９０００ コンピュータ
９０１０ ＣＰＵ
９０２０ 通信インターフェース
９０３０ メモリ
９０４０ 補助記憶装置

Claims (10)

1. データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部と、
   前記データ送信先の装置との間のネットワークの状態をセッション単位で監視する監視部と、
   前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する転送レート制御部と、
   を備える通信装置。
2. 前記監視部は、前記ネットワークの状態として、少なくとも該当セッションのスループット、ＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）、パケットロスの発生割合の少なくとも１以上を監視する請求項１の通信装置。
3. 前記監視部は、前記ネットワークの状態として、単位時間当たりのＡＣＫ受信パケットの受信数を監視する請求項１又は２の通信装置。
4. 同一のＴＣＰコネクションのネットワーク状態を示す測定済データを参照して、送信バッファのサイズの初期値を決定する請求項１から３いずれか一の通信装置。
5. コンテンツサーバと、前記コンテンツサーバに基地局を介してデータの送信を要求する通信端末との間に配置され、前記通信端末との間のＴＣＰコネクションを終端するプロキシサーバとして機能する請求項１から３いずれか一の通信装置。
6. データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部を備えた通信装置が、
   前記データ送信先の装置との間のネットワークの状態をセッション単位で監視するステップと、
   前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更するステップと、
   を含む通信方法。
7. 前記監視するステップにおいて、前記ネットワークの状態として、少なくとも該当セッションのスループット、ＲＴＴ（Ｒｏｕｎｄ−Ｔｒｉｐ Ｔｉｍｅ）、パケットロスの発生割合の少なくとも１以上を監視する請求項６の通信方法。
8. 前記監視するステップにおいて、前記ネットワークの状態として、単位時間当たりのＡＣＫ受信パケットの受信数を監視する請求項６又は７の通信方法。
9. 同一のＴＣＰコネクションのネットワーク状態を示す測定済データを参照して、送信バッファのサイズの初期値を決定する請求項６から８いずれか一の通信方法。
10. データ送信先の装置とのＴＣＰ通信を終端するＴＣＰ終端部を備えた通信装置に、
    前記データ送信先の装置との間のネットワークの状態をセッション単位で監視する処理と、
    前記ネットワークの状態に基づいて、該当セッションに適用する送信バッファのサイズを変更する処理と、
    を実行させるプログラム。

Images