JP4643330B2 - 通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラム - Google Patents

Description

本発明は、通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラムに関する。特に、ストリーミングデータの送受信における的確なビットレート制御を行なう通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラムに関する。

昨今、インターネットを介したデータ通信が盛んに行なわれ、さらに家庭内においても家電機器やコンピュータ、その他の周辺機器をネットワーク接続して機器間での通信を可能としたホームネットワークが浸透しつつある。ホームネットワークは、例えば、ネットワーク接続機器間でのコンテンツ送受信を可能とし、ユーザに利便性・快適性を提供するものであり、今後、ますます普及することが予測される。

サーバの保持する画像データを、ネットワークを介してクライアントに送信し、クライアント側でデータ受信を実行しながら再生を行なうデータ配信処理は、いわゆるストリーミングデータ配信、あるいはデータストリーミングなどと呼ばれる。このようなストリーミングデータ配信を行なうサーバをストリーミングサーバ、ストリーミングサーバからデータを受信するクライアントをストリーミングクライアントと呼ぶ。ストリーミングサーバは、エンコードなどのデータ処理を実行して送信データを生成してネットワークに出力する。一方、ストリーミングクライアントは、受信データをバッファに一時蓄積し、その後、順次デコード処理、再生を行なう。

多くの場合、データストリーミングにおいて用いられる通信プロトコルは、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）である。ＲＴＰは、原則として再送制御を行わない。すなわち、パケットロス対策や伝送時間保証などは行われていないＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）型のプロトコルである。パケットロスが発生した場合でも再送処理を行わないため、再送処理に起因する遅延が起こらずリアルタイム再生に適したプロトコルである。

ＲＴＰを適用した通信では、例えばＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いたレート制御が行なわれる。例えば、特許文献１は、データ受信側の装置が、データ送信側の装置に対してパケット損失率などをＲＴＣＰのＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケットに記載して通知し、送信側でデータの伝送状態を推定し、送信レートを制御するという方法を開示している。

ストリーミング配信では、最適な伝送レートでデータ配信を行なうことが重要となる。例えば特許文献２には、データ送受信装置の双方が、上りまたは下りの伝送レートを計測して、レート制御を実行する装置が、計測されたレートのうち、小さいほうのレートに制御することで安定的にデータ伝送を行なう構成を開示している。

上述のＲＴＰによるストリーミング配信では、パケットロスが発生しても再送を行なわないため再生遅れを発生させないというメリットがあるが、データ品質を向上させるためには、クライアント側で、完全なデータ受信が行われることが好ましい。また、配信コンテンツが、暗号化データである場合などにおいては、クライアント側におけるコンテンツ復号の際に、消失データ部分があると復号が不可能となり再生ができなくなる場合もある。このようなコンテンツの場合、ＲＴＰのような再送制御を行わないプロトコルは不適当である。

このように転送データの完全性を望む場合は、パケットロスに対する対処を行なうプロトコル、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などのトランスポートプロトコルが適用される。ＴＣＰによる画像データの配信構成については、例えば特許文献３に記載されている。

ＴＣＰなどのトランスポートプロトコルを用いた通信はベストエフォートで行われる。マルチメディアデータのストリーミングを行う場合、ベストエフォートの通信による通信帯域幅の変動は深刻な問題となる。この問題は例えばＴＣＰでは顕著になる。ＴＣＰでは、データの喪失が無い代わりにデータの到達時間が遅れるため、通信帯域幅が狭くなるとデータ到達時間が遅れる。このデータ到達時間の遅れにより、ＴＣＰストリーミングでは、輻輳時に映像や音声が途切れやすくなる。そこで、その解決手法としてストリーミングサーバからのデータ配信において送信データのビットレートを増減させて、通信帯域幅の変動に適応させることが一般に行われる。映像データなどを含むマルチメディアデータのビットレート増減手法は、データストリーミングの品質に大きく影響を与える。

従来の手法ではストリーミングサーバが配信データのビットレートを増減させる判断材料は、主にクライアントからの情報である。例えば、クライアントのアプリケーションバッファに蓄えられているデータ量に関する情報が利用される。しかし、クライアントのアプリケーションバッファに蓄えられているデータ量の計算のみでは、ネットワークの帯域許容量以上のビットレートでデータを送信してしまう可能性がある。ネットワークの帯域許容量以上のビットレートでデータを送信すると、結果として輻輳が発生し、望むとおりにマルチメディアデータがクライアントに届かず、クライアントのアプリケーションバッファに蓄積されているデータ量の枯渇が起こり、映像や音声の途切れが発生する可能性が高まることになる。

また、クライアントからの情報を利用する従来の手法では、通信帯域幅の変動に迅速に対応できないという問題がある。例えばストリーミングサーバとストリーミングクライアント間の通信帯域幅が他トラフィックの出現などによって急激に狭くなったとする。通信帯域幅が狭くなった時点でストリーミングサーバが送信データのビットレートを減少させて対応すれば、送信データの再生が途切れることがない。しかし、上述した処理構成のように、クライアントからの情報を利用する構成では、通信帯域幅が狭くなった後、一定時間後にクライアントのバッファ蓄積データ量の減少が発生し、そのバッファデータの減少をサーバ側で認識するまでに時間を要することになる。従って、サーバは、通信帯域幅が細くなった時点での即時対応ができない。この結果、サーバ側でのビットレート削減などの処理を行なう以前に、クライアントのバッファが枯渇してしまい、映像や音声の途切れが発生するという事態が発生してしまうことになる。
特許公開２００２−２０４２７８号公報 特許公開２００４−２９７５６５号公報 特許公開２００５−００５８２３号公報

本発明は、上述の問題点に鑑みてなされたものであり、ストリーミングデータ送受信処理において、最適な送信態様に基づくデータ送信を実現する通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラムを提供することを目的とする。

さらに、具体的には、本発明は、通信経路上の輻輳や無線リンクの外乱の影響などを考慮した上で、サーバ側で送信データのビットレートの最適値を予測し、予測値に基づいてビットレートの動的変更を行なって最適なデータ送信態様に従ったデータストリーミングを実現する通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラムを提供することを目的とする。

本発明の第１の側面は、
クライアントに対するデータ送信処理を実行するサーバとしての通信処理装置であり、
クライアントとの通信処理を実行するデータ送受信部と、
クライアントに対する送信データのビットレートを決定するレート制御部と、
前記レート制御部において決定されたビットレートに対応する送信データの設定処理を実行するデータ処理部とを有し、
前記レート制御部は、
サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出するスループット算出部と、
前記スループット算出部の算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定するビットレート決定部とを有し、
前記ビットレート決定部は、
（ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
（ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
（ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
（ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
これら（ａ）〜（ｄ）の情報を用いて、
クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
として、
クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なう構成であることを特徴とする通信処理装置にある。

本発明の第２の側面は、
データ送信処理を実行するサーバにおける通信処理方法であり、
クライアントに対する送信データのビットレートを決定するレート制御ステップと、
前記レート制御ステップにおいて決定されたビットレートに対応する送信データの設定処理を実行するデータ処理ステップとを有し、
前記レート制御ステップは、
サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出するスループット算出ステップと、
前記スループット算出ステップにおいて算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定するビットレート決定ステップとを有し、
前記ビットレート決定ステップは、
（ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
（ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
（ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
（ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
これら（ａ）〜（ｄ）の情報を用いて、
クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
として、
クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なうことを特徴とする通信処理方法にある。

本発明の第３の側面は、
送信データのレート制御をコンピュータ上で実行させるコンピュータ・プログラムであり、
レート制御部において、クライアントに対する送信データのビットレートを決定させるレート制御ステップと、
データ処理部において、前記レート制御ステップにおいて決定されたビットレートに対応する送信データの設定処理を実行させるデータ処理ステップとを有し、
前記レート制御ステップは、
サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出させるスループット算出ステップと、
前記スループット算出ステップにおいて算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定させるビットレート決定ステップとを有し、
前記ビットレート決定ステップは、
（ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
（ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
（ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
（ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
これら（ａ）〜（ｄ）の情報を用いて、
クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
として、
クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なわせるステップであることを特徴とするコンピュータ・プログラムにある。

なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能なコンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記録媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本発明の構成によれば、「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］の計測値を適用して最大スループットを算出し、この最大スループットに基づいて、送信ビットレートの制御を行う構成とした。すなわち、データ送受信に対する寄与のない期間［データ送受信非実行期間］を省いたデータ送受信期間に基づく最大スループットを算出して、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大許容ビットレートを上限としたデータ送信が実現される。

さらに、本発明の構成によれば、クライアントで計測される連続送信パケットの受信間隔に基づいて最大スループットが算出され、算出された最大スループットを上限としたビットレート制御を行うことができる。すなわち、実際に連続送信されるパケットの計測に基づいて定められる最大スループットを算出して、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大許容ビットレートを上限としたデータ送信が実現される。

さらに、本発明の構成によれば、実際の送受信データ計測に基づいて算出される最大スループットに基づくビットレート制御に加え、基地局（ＡＰ）の測定する基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどの通信帯域情報に基づいて、ビットレートの制御を行う構成としたので、無線通信における通信状態の変動に即応したビットレート制御が実現される。

以下、図面を参照しながら、本発明の通信処理装置、データ通信システム、および通信処理方法、並びにコンピュータ・プログラムの詳細について説明する。

［システム概要］
まず、図１を参照して、本発明の適用可能なネットワーク構成例について説明する。図１は、様々なクライアント装置からの処理要求に応じて処理を実行するコンテンツ配信装置としてのサーバ１０１と、サーバ１０１に対して処理要求を行なうコンテンツ受信装置としてのクライアント１２１〜１２４がネットワーク１１０を介して接続された構成、例えばホームネットワーク構成を示している。クライアント装置としては、パーソナルコンピュータ（ＰＣ）１２１、１２２、携帯端末１２３、再生装置１２４を例示している。ただし、クライアント装置としては、この他にも様々な電子機器、家電機器が接続可能である。

クライアント（携帯端末）１２３、クライアント（再生装置）１２４は、基地局（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）１３１を介して無線通信を行なうクライアントであり、クライアント（ＰＣ）１２１，１２２は有線ＬＡＮによる通信をサーバ１０１と行なう。例えばクライアント１２１（ＰＣ）は１００ｂａｓｅ−ＴＸ、クライアント（ＰＣ）１２２は１０ｂａｓｅ−Ｔ規格による通信をサーバ１０１との間で実行する。クライアント（携帯端末）１２３、クライアント（再生装置）１２４は、基地局（ＡＰ）１３１を介してサーバ１０１との通信を実行し、基地局（ＡＰ）１３１とクライアント（携帯端末）１２３間では、ＩＥＥＥ８０２．１１ｂ規格による無線ＬＡＮ通信を実行し、基地局（ＡＰ）１３１とクライアント（再生装置）１２４間では、ＩＥＥＥ８０２．１１ｇ規格による無線ＬＡＮ通信を実行する。

このように、各クライアント１２１〜１２４は、サーバ１０１との通信、例えば、サーバ１０１から映像データの配信を受ける際に、それぞれの機器に対応した通信規格に従ったデータ通信を実行し、それぞれ異なるビットレートでのデータ受信を行なうことになる。サーバ１０１がクライアントからの要求に応じて実行する処理は、例えばサーバ１０１に装着されたハードディスク、ＤＶＤ等の記憶手段に格納されたコンテンツ、あるいはサーバ１０１の有するチューナを介して受信するライブコンテンツの提供、すなわちコンテンツ配信サービス等である。

ネットワーク１１０は、例えばイーサネット（登録商標）フレーム等の通信パケットを、ネットワーク１００を介して送受信する。すなわち、クライアントは、イーサネットフレームのデータ部に処理要求情報を格納してサーバ１０１に送信することにより、サーバ１０１に対するデータ処理要求を実行する。サーバ１０１は、処理要求フレームの受信に応じて、データ処理を実行し通信パケットに格納し、各クライアントに送信する。

サーバ１０１は、クライアント１２１〜１２４と個別に、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）コネクションを確立して、例えばストリーミングデータ配信により映像データなどを含むマルチメディアデータの送信を実行する。本発明の構成において、ＴＣＰコネクションにおけるサーバ１０１からのクライアント１２１〜１２４に対するデータ配信は、動的なビットレート制御を伴う処理として実行される。

このビットレートの動的制御は、
サーバと各クライアントの間のデータ通信における最大スループット計測処理、
計測された最大スループットに相当するビットレートを最大許容ビットレートとしたビットレート制御処理、
これらの処理を含む処理として実行される。以下、このビットレートの動的制御処理の複数の実施例の詳細について、順次、説明する。

［実施例１］
図２にストリーミングデータ配信を実行するサーバ２００と、ストリーミングデータの受信、再生を実行するクライアント３００の機能を説明するブロック図を示す。サーバ２００とクライアント３００間ではＴＣＰコネクションが設定されて通信が実行される。

サーバ２００は、送信コンテンツ格納部としてのコンテンツ提供部２０１を有する。コンテンツ提供部２０１は、ハードディスクや、ＤＶＤなどの記憶手段、あるいは外部からのコンテンツ受信を行なうチューナ機能を備えた構成である。コンテンツ提供部２０１から、クライアント３００に対する送信コンテンツがデータ処理部２０２に入力される。

データ処理部２０２では、エンコード処理などの送信データ生成処理を行なう。この送信データ生成処理では、動的レート制御部２１０において設定されたビットレートに対応するエンコードデータを生成する。なお、予め複数のビットレート対応のデータを準備し、これらの複数のビットレートデータから送信データを選択する処理を実行する構成としてもよい。

動的レート制御部２１０は、スループット算出部２１１と、ビットレート決定部２１２を有する。スループット算出部２１１は、サーバのデータ送受信部２０４とクライアントのデータ送受信部３０１との間で実行される通信状況の監視を実行し、監視結果に基づいてスループットを算出する。ビットレート決定部２１２は、スループット算出部２１１の算出したスループットに基づいて、クライアント３００に対するデータの送信ビットレートを決定し、データ処理部２０２に通知する。この動的レート制御部２１０の処理の詳細については後述する。

データ処理部２０２は、ビットレート決定部２１２の決定したビットレートに応じた送信データのエンコード、あるいはビットレート決定部２１２の決定したビットレートに応じたエンコードデータの選択処理を実行し、送信バッファ２０３に入力する。データ送受信部２０４は、送信バッファ２０３に蓄積された送信ビットレートに対応するデータ（パケット）をクライアント３００との間で設定したＴＣＰコネクションを介してクライアント３００に送信する。

クライアント３００は、データ送受信部３０１を介してサーバ２００からのストリーミングデータ（パケット）を受信し、受信バッファ３０２に格納する。受信バッファ３０２に格納されたデータは、再生処理部３０３によって順次、取り出されデコード処理、例えばデータ伸長処理、暗号化データであれば復号処理が実行され、ディスプレイ、スピーカなどによって構成される出力部３０４に出力される。

図３は、サーバクライアント間における通信処理のシーケンスについて説明する図である。まず、ステップＳ１１において、サーバとクライアント間でＴＣＰコネクションの確立処理が実行される。その後、ステップＳ１２において、クライアントからサーバに対するバッファ量通知処理が実行される。なお、バッファ量通知処理はコネクション確立処理に含まれる処理として実行してもよい。

本実施例では、ストリーミングデータを受信するクライアントのアプリケーションバッファの最大量、すなわちストリーミングデータ受信のために準備されるバッファの最大量をストリーミング開始時にサーバへ通知する。図２の受信バッファ３０２は、ストリーミングデータを受信するクライアントのアプリケーションバッファを示しており、この受信バッファ３０２最大量がサーバに通知される。例えば、ストリーミングがＨＴＴＰ方式に従ったストリーミングデータである場合、クライアントは、アプリケーションバッファ量をＨＴＴＰヘッダに含めてサーバへ通知する。サーバは、クライアントから通知されたバッファ量を、動的レート制御部２１０において決定するビットレートの増減処理の指標として利用する。この処理については、後述する。クライアントからサーバに対するバッファ量通知は、ストリーミング開始時の１回のみとなる。

その後、ステップＳ１３において、サーバからクライアントに対してストリーミングデータの配信が実行される。このストリーミングデータの送信処理においては、図２に示すサーバ２００の動的レート制御部２１０において動的な送信ビットレートの制御が行われ、最適なビットレートでのストリーミンクデータ送信が行われる。具体的な処理については後述する。全てのストリーミングデータの送信が終了すると、ステップＳ１４において、サーバクライアント間のコネクション切断を実行して処理を終了する。

次に、図４〜図６を参照して、図２に示すサーバ２００の動的レート制御部２１０において実行する送信データのビットレート制御処理の詳細について説明する。まず、図４を参照して、動的レート制御部２１０のスループット算出部２１１の実行するスループット算出処理について説明する。

図４は、図３におけるステップＳ１３のデータ転送処理を、より詳細に示したシーケンス図である。サーバは、ストリーミング配信データをＴＣＰパケット（ＴＣＰセグメント）に格納して、順次クライアントに送信する。図４に示すデータ１〜データ８は、個々の送信パケットを示す。ＴＣＰ通信では、クライアントは、受信パケットの受信確認応答としてのａｃｋをサーバに送信する。図に示すａｃｋ１〜４がクライアントからサーバに送信される受信確認応答（ａｃｋ）を示している。なお、クライアントからサーバに送信される受信確認応答（ａｃｋ）は、必ずしも全ての送信データに対応してクライアントから送信されるとは限らない。クライアント側では、時間的余裕のない場合は、受信確認応答（ａｃｋ）を省略する場合もある。図４に示すａｃｋ１は、データ１およびデータ２の受信確認応答（ａｃｋ）であり、ａｃｋ２は、データ３およびデータ４に対する受信確認応答（ａｃｋ）である。

サーバからクライアントに対するデータ送信は、クライアントからサーバに提示されるウィンドウサイズに基づく連続送信処理として実行される。例えば、図４に示すデータ１〜データ４の送信は、連続送信処理として実行された処理である。すなわち各パケットの送信後、サーバが、その受信確認をクライアントから受領して次のパケットを送信するという処理を行なうと、スループットが低下しデータ送信処理の効率が落ちてしまう。

これを防止するため、一定の一括送信可能なデータ量としてのウィンドウサイズを決定して、このウィンドウサイズに基づいてパケットを連続して送信する。このウィンドウサイズは、例えばセッション確立時にクライアントからサーバに通知される。すなわち、クライアント側で一括受信可能なデータ量としてウィンドウサイズをサーバに通知する。サーバ側では、このウィンドウサイズに基づいて、ウィンドウサイズに対応するデータ量を持つパケットの連続送信を実行する。また、クライアントからサーバに対して送信される受信確認応答（ａｃｋ）パケットに更新されたウィンドウサイズをサーバに通知して、サーバ側では更新されたウィンドウサイズに基づいて連続送信データ量を逐次変更制御する構成としてもよい。

ウィンドウサイズに基づくデータ送信を実行すると、サーバからクライアントに対するデータ送信は、図４に示すように間欠したデータ送信処理として実行されることになる。たとえば図４に示す期間Ａは、連続データ送信および送信された連続データに対する最終の受信確認応答（ａｃｋ）の受信までの期間である。

図４に示す期間Ｂは、期間Ａの終了点、すなわち、期間Ａにおける［ＴＣＰデータ群］の最終の受信確認応答（ａｃｋ）の受信時間から、次の［ＴＣＰデータ群］の送信開始までの待機時間である。期間Ｃは、期間Ｂの後の次の［ＴＣＰデータ群］の送信および受信確認応答（ａｃｋ）の受信期間である。

従来のスループット算出手法は、送信データの量を単純に送信時間で除算して算出していた。例えば図３のデータ送信処理シーケンスである場合にＡ〜Ｃの時間帯でのスループットを求める際は、
スループット＝（データ１〜８の送信データ量）／（時間Ａ＋Ｂ＋Ｃ）
によってスループットを算出していた。このスループット算出処理によれば、サーバから送信されたデータ量以上の値がＴＣＰスループットとして測定されることはない。

しかし、ＴＣＰにおけるデータ送信において、データ送信ビットレートを制御して、より高いビットレートでの送信を行なう場合、どこまでビットレートを上昇させて良いか、すなわち最大許容ビットレートを決定することが必要となる。

本発明の構成では、図４に示すＢの期間を省いた時間で転送データ量を除算することにより、最大スループットを予測し、この最大スループットに対応するビットレートを最大許容ビットレートとする。図４の期間Ｂは、サーバがクライアントに対するデータを送信していない期間である。期間Ｂの部分をスループット算出のための時間計測値に含めてしまうと、実際にデータの送受信を実行していない期間がスループット計測に適用されてしまうことになり、実際のスループットに対する寄与のない期間がスループット算出に適用されてしまうことになる。すなわち、データ送受信の実行されていないＢの期間を入れて、最大スループットの算出を実行すると、最大スループットの値が低下してしまう。すなわち、この場合のＴＣＰスループットの測定値はコンテンツのビットレート以上の値にならない。

本発明の構成では、期間Ｂのような［データ送受信非実行期間］の部分を除いた期間、すなわち、ウィンドウサイズに基づく連続データ送信およびその受信確認応答（ａｃｋ）の受信に至るまでの期間、すなわち、図４に示す期間Ａや期間Ｃをスループット算出の期間として適用する。具体的には、
スループット算出用サンプル１＝（データ１〜４の送信データ量）／（時間Ａ＋Ｂ−Ｂ）
スループット算出用サンプル２＝（データ５〜８の送信データ量）／（時間Ｃ＋Ｄ−Ｄ）
：
スループット算出用サンプルｎ
のように、複数のスループット算出用サンプルを算出し、これら複数のスループット算出用サンプルに基づいて、最大スループットを算出する。なお、上記式においてＤは、図４に示す期間Ｃの後に発生するデータ非送信期間である。

このように、本発明の最大スループット算出処理は、図４に示すＡやＣの「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち［データ送受信実行期間］のみをスループット算出処理に適用する期間とし、図４に示す期間Ｂのような［データ送受信非実行期間］についてはスループット算出処理の非適用期間とする。この処理により、ＴＣＰセッションにおいて実際のデータ送信および応答（ａｃｋ）受信が行われている有効期間のみがスループット算出処理の適用期間となり、真のＴＣＰの最大スループットが測定できる。

前述したように、ＴＣＰセッションにおけるデータパケットの送信では、ウィンドウサイズに基づくデータの連続送信が実行される。すなわち、クライアント側でウィンドウが空いているときに受信確認応答（ａｃｋ）を待たずに連続してデータパケットを送信する。そのため、図４のＡ，Ｃに示すような、「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］と、Ｂに示すような［データ送受信非実行期間］が交互に発生する。

なお、図４のＡ，Ｃに示すような、「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］において送信されるＴＣＰパケットデータを「ＴＣＰデータ群」と呼ぶ。個々のＴＣＰデータ群に対応する［データ送受信実行期間］は、ウィンドウや瞬間的な輻輳に大きく影響される。そのため、値が大きく変動し、最大スループットの測定結果が安定しない。本発明では、この問題を回避するために、上述したように、複数のスループット算出用サンプル、すなわち、
スループット算出用サンプル１＝（データ１〜４の送信データ量）／（時間Ａ＋Ｂ−Ｂ）
スループット算出用サンプル２＝（データ５〜８の送信データ量）／（時間Ｃ＋Ｄ−Ｄ）
：
スループット算出用サンプルｎ
を算出し、これら複数のスループット算出用サンプルに基づいて、スループットを算出する。なお、スループット算出用サンプルデータ中、他のサンプルデータと大きく外れる測定結果は、例外値として除外する処理を実行する。

本実施例において、図２に示すサーバ２００の動的レート制御部２１０のスループット算出部２１１の実行する最大スループット算出処理の手順について図５に示すフローチャートを参照して説明する。スループット算出部２１１は、ウィンドウサイズに基づく連続データ送信の開始から、送信された連続データに対する受信確認応答（ａｃｋ）を受信するまでの期間をデータ送受信実行期間とし、このデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出する。図５は、サーバ２００がクライアントとＴＣＰコネクションを確立し、通信を実行して、ＴＣＰコネクションの切断を行なうまでの処理の流れを説明したフローチャートである。

まず、ステップＳ１０１において、サーバはストリーミングデータの配信対象としてのクライアントとＴＣＰコネクションを確立する。なお、このコネクション確立時点で、サーバは、クライアントからバッファ量（ウィンドウサイズに相当）の通知を受ける。

ステップＳ１０２において、上位層のアプリケーションからのデータ送信要求ありの判定がなされると、ステップＳ１０３においてＴＣＰセグメント（パケット）の送信を開始し、送信開始時間［Ｔｓ］をメモリに記憶する。なお、このパケット送信は、先にクライアントから通知されたウィンドウサイズに相当するデータ量のパケットの連続送信処理として実行される。例えば図４に示す期間Ａの複数のデータ送信処理である。

ステップＳ１０４において、サーバはクライアントからの受信確認応答（ＴＣＰ ＡＣＫ）を受信したか否かを判定する。受信確認応答（ＴＣＰ ＡＣＫ）を受信していない場合は、ステップＳ１０５に進み、ＴＣＰ送信ウィンドウがＭＡＸ、すなわち、ウィンドウサイズに相当するデータ量のパケットを送信済みか否かを判定する。ウィンドウサイズに相当するデータ量のパケットを送信済みでない場合は、ステップＳ１０６において、ＴＣＰセグメント（パケット）を継続して送信する。

ＴＣＰ送信ウィンドウがＭＡＸ、すなわち、ウィンドウサイズに相当するデータ量のパケットを送信済みである場合は、受信確認応答を待機する。ステップＳ１０４において、受信確認応答を受信した場合は、ステップＳ１０７に進み、送信済みＴＣＰセグメントの最終セグメントに対応する受信確認応答（ＴＣＰ ＡＣＫ）を受信したか否かを判定し、未受信の場合は、受信するまで待機する。この最終セグメントに対応する受信確認応答（ＴＣＰ ＡＣＫ）は、例えば図４の期間Ａにおけるａｃｋ２である。

ステップＳ１０７において、最終セグメントに対応する受信確認応答（ＴＣＰ ＡＣＫ）を受信したと判定すると、ステップＳ１０８において、最終セグメントに対応する受信確認応答（ＴＣＰ ＡＣＫ）の受信時間［Ｔｅ］をメモリに記憶する。

次に、ステップＳ１０９において、スループット算出用サンプル対応時間Ｔｎ＝Ｔｅ−Ｔｓを算出する。この処理は、図２に示すサーバ２００の動的レート制御部２１０におけるスループット算出部２１１において実行される。このＴｎ＝Ｔｅ−Ｔｓは、すなわち、図４に示す期間ＡやＣの「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］の計測値である。

次に、ステップＳ１１０において、測定サンプル数ｎが予め定めた閾値［Ｔｈｎ］以上となったか否かを判定する。測定サンプル数ｎが予め定めた閾値［Ｔｈｎ］以上でない場合は、ステップＳ１１１において通信が継続中か否かを判定し、通信継続中である場合は、ステップＳ１０２に進み、さらに、測定サンプル数ｎが予め定めた閾値［Ｔｈｎ］以上となるまで、同様の処理を繰り返し、スループット算出用サンプル対応時間Ｔｎ＝Ｔｅ−Ｔｓを集める。この処理は、例えば図４における期間ＡやＣの「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］の計測値を所定数、すなわち予め定めた閾値［Ｔｈｎ］以上となるまで集める処理である。

ステップＳ１１０において、測定サンプル数ｎが予め定めた閾値［Ｔｈｎ］以上となったと判定されると、ステップＳ１１２に進み、測定サンプル、すなわち、スループット算出用サンプル対応時間Ｔ１〜Ｔｎ中、値が大きくはずれたものを例外値として除去する処理を実行し、ステップＳ１１３において、例外値を除去したスループット算出用サンプル対応時間Ｔ１〜Ｔｎのみを適用して、最大スループットを算出する。

ステップＳ１１３におけるスループット算出は、最大スループットを、
最大スループット＝（Σ（各データ送受信実行期間における送信データ量））／（Σ（各データ送受信実行期間））
として算出する。ただし、上記式において、Σ（各データ送受信実行期間における送信データ量）、および、Σ（各データ送受信実行期間）には、例外値に対応する
期間および送信データ量は含まない。

このようにして、図２に示すサーバ２００の動的レート制御部２１０におけるスループット算出部２１１は、複数の［データ送受信実行期間］の計測時間および送信データ量に基づいて、最大スループットを算出する。この処理において算出されるスループットは、図４に示すデータ送受信非実行期間（Ｂ）を含まない。スループット算出部２１１は、この算出スループットを最大スループットとして、図２に示すサーバ２００の動的レート制御部２１０のビットレート決定部２１２に入力する。

ビットレート決定部２１２の処理について、図６、図７を参照して説明する。図６に示すように、ビットレート決定部２１２は、スループット算出部２１１が上述の処理によって算出した最大スループットを入力するとともに、クライアントのバッファ量を見積もり、ビットレートを決定し、エンコード処理あるいはエンコードデータの選択処理などを実行するデータ処理部２０２に対して、送信データのビットレート決定情報を入力する。

ビットレート決定部２１２では、クライアントのバッファ量の見積もり処理を以下の処理によって行なう。すなわち、
通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間にサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ））
これらの情報を用いて、クライアントのバッファ量の見積もりを実行する。

サーバは、クライアントにおいて送信コンテンツの再生が開始されたことを、サーバが実際に送信したデータ量が、クライアントから通知されたバッファ量［Ｂ＿ｃｌｉ］を上回ったことで判断することができる。つまり、クライアントは、コンテンツ再生開始前にクライアントバッファ量［Ｂ＿ｃｌｉ］分だけ、バッファにデータを蓄積し、その分の量のデータをサーバが送信した時点で、サーバは、クライアントのバッファが一杯になり、再生が開始されたと判断する。

クライアント側においてコンテンツの再生が開始された時点では、クライアントのバッファ量は［Ｂ＿ｃｌｉ］であり、再生開始後、時間Ｔが経過すると、サーバは［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］のデータをクライアントに送信し、クライアントのバッファに送信データが蓄積される。クライアントは、［Ｒ＊Ｔ（ｂｙｔｅ）］のデータ量を再生することで、このデータ量がクライアントのバッファから消去される。

サーバは、これらのデータの推移に基づき、
Ｂ＿ｃｌｉ＋Ｄ＿ｓｅｒｖ−Ｒ＊Ｔ
のデータ量が、現在のクライアントのバッファ量であると見積もる。このようにして見積もられたバッファ量は、図６のバッファ量情報２５０に示すように、０〜ＭＡＸの範囲で見積もられる。ＭＡＸはクライアントバッファ量［Ｂ＿ｃｌｉ］に相当する。ビットレート決定部２１２は、このようにクライアント側バッファの見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、スループット算出部２１１の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なう。

図７に示すフローチャートを参照して、ビットレート決定部２１２の処理シーケンスについて説明する。ステップＳ２０１において、ビットレート決定部２１２は、バッファ量が、予め定めた閾値Ｔｈ１より少ないか否かを判定する。なお、バッファ量とは、上述の見積もり処理によって見積もられたバッファ量である。バッファ量が、予め定めた閾値Ｔｈ１より少ないと判定された場合は、ステップＳ２０２に進み、送信ビットレートの低下処理を実行する。この処理は、図６に示すバッファ量情報２５０におけるバッファ量がＢａの領域にある場合の処理である。

ステップＳ２０１において、バッファ量が、予め定めた閾値Ｔｈ１より少なくないと判定されると、ステップＳ２０３に進み、バッファ量が、予め定めた閾値Ｔｈ２より多いか否かを判定する。バッファ量が、予め定めた閾値Ｔｈ２より多くない場合は、ステップＳ２０１に戻る。この処理は、図６に示すバッファ量情報２５０におけるバッファ量がＢｂの領域にある場合の処理である。

バッファ量が、予め定めた閾値Ｔｈ２より多い場合は、ステップＳ２０４に進み、現在の送信データのビットレートと、スループット算出部２１１が上述の処理によって算出した最大スループットとを比較する。現在の送信データのビットレートが、スループット算出部２１１が算出した最大スループットに対応するビットレートより小さい場合は、ステップＳ２０５に進み、送信データのビットレートを上昇させる処理を実行する。ただし、スループット算出部２１１が算出した最大スループットに対応するビットレート、すなわち最大許容ビットレートを上限値とする。現在の送信データのビットレートが、スループット算出部２１１が算出した最大スループットに相当する最大許容ビットレートに等しい場合は、ビットレートの制御を行なうことなく、ステップＳ２０１に戻る。この処理は、図６に示すバッファ量情報２５０におけるバッファ量がＢｃの領域にある場合の処理である。

なお、先に説明した図５に示すフローチャートにおけるスループット算出処理は、データ通信の継続中、所定期間毎に繰り返し実行され、スループット算出部２１１は、最大スループットを逐次更新してビットレート決定部２１２に入力する。ビットレート決定部２１２においても、図７のフローチャートに示す処理を繰り返し実行し、スループット算出部２１１の算出した最新の最大スループットに対応する最大許容ビットレートに基づいてビットレートを逐次決定する。従って、ネットワーク状況に応じた最大スループットに基づくビットレート制御が行われる。

本実施例では、図４を参照して説明したように、図４に示す期間ＡやＣの「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］の計測値を適用して最大スループットを算出し、この最大スループットに相当する最大許容ビットレートを上限とした送信ビットレートの制御を行う構成とした。すなわち、図４に示す期間Ｂのようなデータ送受信に対する寄与のない期間［データ送受信非実行期間］を省いたデータ送受信期間に基づく最大スループットを算出して、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大ビットレートを上限としたデータ送信が実現される。

［実施例２］
次に、実施例２として、クライアント側において受信データに基づいてスループットを算出、あるいはスループット算出に適用する値を算出し、この算出値に基づいてサーバがビットレート制御を実行する構成例について説明する。

図８は、実施例２におけるストリーミングデータ配信を実行するサーバ２００と、ストリーミングデータの受信、再生を実行するクライアント３００の機能を説明するブロック図を示す。サーバ２００とクライアント３００間ではＴＣＰコネクションが設定されて通信が実行される。

先に図２を参照して説明した実施例１の構成と異なる点は、クライアント３００がパケット間隔計測部３０５を有する点である。その他の構成は図２の構成と同様である。ただし、各構成部における処理が異なる。以下、実施例２の構成において、実施例１と異なる点を中心として説明する。

実施例２の構成において、サーバ２００のデータ送受信部２０４は、所定間隔で、緊急フラグ（ＵＲＧフラグ）をＯＮ［１］としたデータ送信パケットを連続送信する。緊急フラグは、通常、ＴＣＰパケットに緊急データが含まれる場合にＯＮ［１］として送信する。本実施例では、緊急データの有無に関わらず、クライアント側でＴＣＰパケットの受信間隔を測定するパケットであることを示すために、緊急フラグ（ＵＲＧフラグ）をＯＮ［１］としたパケットを連続送信する。

図９を参照して、サーバクライアント間のデータ通信シーケンスを説明する。実施例２においても、実施例１と同様、サーバクライアント間で、コネクション確立が実行された後、サーバからクライアントに対してストリーミングデータの配信が実行される。図９に示すデータ通信シーケンスは、実施例１において説明した図３に示すステップＳ１３のデータ転送処理の詳細を示す図である。

実施例２では、図９に示すように、サーバはＴＣＰパケットとしてのデータ１から順にクライアントに送信する。サーバは、クライアントにおいてパケット受信間隔を計測する要求のあるパケットについて、緊急フラグをＯＮ［１］として連続送信する。図９に示すパケットｎ、パケットｎ＋１のＴＣＰパケットのヘッダに設定される緊急フラグがＯＮ［１］に設定されたパケットである。この緊急フラグがＯＮ［１］に設定された２つの連続するパケットをスループット計測用ペアパケットとする。

クライアントは、緊急フラグがＯＮ［１］に設定されたパケットを２つ連続して受信した場合、その受信間隔［ｔ］を計測する。この計測値に基づいてスループットを算出し、サーバに通知する。あるいは、受信間隔データ［ｔ］をサーバに通知して、サーバにおいて受信間隔データ［ｔ］に基づいてスループットを算出してもよい。

サーバはこの連続パケット受信間隔データ［ｔ］に基づいて算出されるスループットを最大スループットとして、この最大スループットに相当するビットレートを最大許容ビットレートとしたビットレート制御を実行する。図１０、図１１を参照して、実施例２におけるサーバの処理と、クライアントの処理シーケンスについて説明する。

まず図１０を参照して、サーバの処理について説明する。図１０は、サーバ２００がクライアントとＴＣＰコネクションを確立し、通信を実行して、ＴＣＰコネクションの切断を行なうまでの処理の流れを説明したフローチャートである。

まず、ステップＳ３０１において、サーバはストリーミングデータの配信対象としてのクライアントとＴＣＰコネクションを確立する。ステップＳ３０２において、クライアントアプリケーションからのデータ送信要求ありの判定がなされると、ステップＳ３０３においてＴＣＰセグメント（パケット）の送信を開始する。

ステップＳ３０４において、サーバは、クライアントに対する送信パケットをスループット計測用ペアパケットとするかを判定する。送信パケットをスループット計測用ペアパケットとする場合は、ステップＳ３０５に進み、緊急フラグをＯＮ［１］に設定したパケットを生成し、連続送信する。送信パケットをスループット計測用ペアパケットとしない場合は、ステップＳ３０６に進み、緊急フラグをＯＦＦ［０］に設定したパケットを生成して送信する。

ステップＳ３０７において、通信が継続していると判定した場合は、ステップＳ３０２以下の処理を繰り返し実行する。通信が終了した場合は、ステップＳ３０８に進みＴＣＰコネクションを切断して処理を終了する。

次に、クライアント側の処理について、図１１のフローチャートを参照して説明する。図１１は、クライアント３００がサーバ２００とＴＣＰコネクションを確立し、通信を実行して、ＴＣＰコネクションの切断を行なうまでの処理の流れを説明したフローチャートである。

まず、ステップＳ３５１において、クライアントはストリーミングデータの配信元としてのサーバとＴＣＰコネクションを確立する。ステップＳ３５２において、クライアントは、サーバからのＴＣＰパケットを受信し、ステップＳ３５３においてＴＣＰパケットの受信時間をメモリに記憶する。

ステップＳ３５４において、受信パケットの緊急フラグがＯＮ［１］であるか否かを判定し、Ｎｏであれば、ステップＳ３５２に戻る。Ｙｅｓであれば、１つ前の受信パケットの緊急フラグもＯＮ［１］であったかを確認し、Ｎｏであれば、ステップＳ３５２に戻る。Ｙｅｓであれば、ステップＳ３５６に進み、緊急フラグがＯＮ［１］である２つの連続パケットの受信間隔［ｔ］を算出する。この処理は、図８に示すクライアント３００のパケット間隔計測部３０５において実行される。

ステップＳ３５７では、２つの連続パケットの受信間隔［ｔ］に基づいて、最大スループットが算出される。
最大スループット＝（ペアパケットの後ろパケットのデータ量）／ｔ
によって算出される。この算出処理もパケット間隔計測部３０５において実行される。

ステップＳ３５８では、算出情報をサーバにフィードバックするか否かを判定し、フィードバックしない場合は、ステップＳ３６０において通信の継続を判定して、継続している場合はステップＳ３５２に戻り処理を繰り返す。ステップＳ３５８では、算出情報をサーバにフィードバックすると判定した場合は、ステップＳ３５９に進み、算出スループット情報、または受信間隔情報をサーバに送信する。

ステップＳ３５９の処理の後、ステップＳ３６０において通信の継続を判定して、継続している場合はステップＳ３５２に戻り処理を繰り返す。ステップＳ３６０において通信の終了と判定された場合は、ステップＳ３６１においてＴＣＰコネクションを切断する。

なお、前述したように、クライアントは、緊急フラグがＯＮ［１］に設定されたパケットを２つ連続して受信した場合、その受信間隔［ｔ］を計測して、計測値に基づいてスループットを算出し、サーバに通知する構成としてもよいが、受信間隔データ［ｔ］をサーバに通知して、サーバにおいて受信間隔データ［ｔ］に基づいてスループットを算出してもよい。この場合は、ステップＳ３５７の処理は、クライアントでは実行する必要がない。

サーバ側では、クライアントから受信した情報が受信間隔データ［ｔ］である場合は、サーバ２００のスループット算出部２１１において、受信間隔データ［ｔ］に基づいて、上記と同様のスループット算出式、すなわち、
スループット＝（ペアパケットの総データ量／２）／ｔ
によって最大スループットを算出する。

サーバ側のビットレート決定部２１２は、クライアントから受信したスループット、あるいは、クライアントから受信した受信間隔データ［ｔ］に基づいてサーバのスループット算出部２１１において算出したスループットを最大スループットとして、ビットレート入力部２１２に入力する。

ビットレート入力部２１２における処理は、実施例１と同様の処理であり、先に図７を参照して説明したビットレート制御処理が実行される。本処理でも実際の連続送信パケットの受信間隔に基づいて最大スループットが計測される。すなわち、先に図４を参照して説明した期間Ｂのようなデータ送受信に対する寄与のない期間［データ送受信非実行期間］を考慮しない最大スループットが算出され、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行うことができる。このように実施例２も、実際に連続送信されるパケットの計測に基づいて定められる最大スループットに相当する最大許容ビットレートに従ってビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大ビットレートを上限としたデータ送信が実現される。

［実施例３］
次に、実施例３として、基地局（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）において取得する情報を適用してビットレート制御を行う構成について説明する。

図１のネットワーク構成において、クライアント（携帯端末）１２３、クライアント（再生装置）１２４は、基地局（ＡＰ）１３１を介してサーバ１０１との通信を実行する。

サーバが基地局（ＡＰ）を介してクライアントに対してストリーミングデータを配信する際、サーバは、まず、サーバクライアント間にある最適な基地局（ＡＰ）を発見する処理を行なうことが必要である。まずこのＡＰ発見処理について図１２を参照して説明する。

まず、ストリーミング配信を実行するサーバ２００は、ストリーミングを開始する前に、ステップＳ４０１において、サーバ２００自身およびストリーミングデータの配信先クライアント１２３の二つのＭＡＣアドレスを格納した「ＡＰ発見メッセージ」をサブネット内にブロードキャストする。

ブロードキャストされた「ＡＰ発見メッセージ」は、ＬＡＮに接続されたすべての基地局（ＡＰ）が受信する。図には２つの基地局ａ（ＡＰａ）４００ａと基地局ｂ（ＡＰｂ）４００ｂを示している。サーバ２００からの「ＡＰ発見メッセージ」を受信した各ＡＰ４００ａ，４００ｂは、ステップＳ４０２において、「ＡＰ発見メッセージ」に含まれるクライアントのＭＡＣアドレスをもつノードが無線リンク内に存在するかを、自身の無線アソシエーションリストを参照して調べる。

もし、アソシエーションリストに該当ＭＡＣアドレスがある場合は、ＡＰは自身がそのストリーミングの通信経路上に存在していることがわかる。なお、アソシエーションリストに該当ＭＡＣアドレスがあるないにかかわらず、受信した「ＡＰ発見メッセージ」は無線リンクへは転送せず、破棄する。

ＡＰがストリーミングの通信経路上に存在していることが分かった場合は、ステップＳ４０３において、ＡＰ、図１２の例では、基地局ａ（ＡＰａ）４００ａはサーバ２００、クライアント１２３のＭＡＣアドレスに加え、基地局ａ（ＡＰａ）４００ａ自身のＭＡＣアドレスを格納した「ＡＰ発見応答メッセージ」を、サーバ２００にユニキャストで送信する。ストリーミング配信実行サーバ２００は、これから行うストリーミングの経路上に無線リンク（ボトルネック）が存在することが分かる。なお、ＡＰがストリーミングの通信経路上に存在していないことがわかった場合は、ＡＰは「ＡＰ発見応答メッセージ」を送信しない。

以上のやりとりにより、ストリーミングデータ配信を実行するサーバおよび通信経路上の基地局（ＡＰ）は、お互いのＭＡＣアドレスを把握することができるため、両者間で通信（無線リンク情報をＡＰからサーバへ通知）が可能となる。なお、ストリーミングデータを受信するクライアントの移動や電源ＯＦＦ等で、基地局（ＡＰ）自身のアソシエーションリストから該当ＭＡＣアドレスが削除された場合は、基地局（ＡＰ）はサーバへの通知を取りやめる。

また、サーバによる「ＡＰ発見メッセージ」をストリーミング開始だけでなく、ストリーミング最中も、定期的に送信することにより、ストリーミングクライアントがＡＰ間をハンドオーバーした場合に対応可能となる。つまり、移動先で接続したＡＰが、「ＡＰ発見メッセージ」を受信した瞬間に、移動先ＡＰが、「ＡＰ発見応答メッセージ」をサーバに返答し、無線リンクの状況を通知し始める。なお、自身のアソシエーションリストから該当ストリーミングクライアントのＭＡＣアドレスが削除された、移動前に接続していたＡＰは、サーバへの無線リンク情報の通知は取りやめる。

なお、基地局（ＡＰ）からサーバへの通知をＬ２（データリンク層）レベルのメッセージではなく、上位レベル（ＩＰ）のメッセージで行う場合は、「ＡＰ発見メッセージ」「ＡＰ発見応答メッセージ」に、ＭＡＣアドレスに加え、ＩＰアドレスも格納しておく。また、基地局（ＡＰ）は、「ＡＰ発見応答メッセージ」の代わりに、即座に無線リンク情報をサーバに通知してもよい。

このようなＡＰ発見処理によって、ストリーミング配信を実行するサーバと基地局（ＡＰ）とクライアントの関係が設定される。実施例３では、ストリーミング配信を実行するサーバが、ストリーミング配信経路上の基地局（ＡＰ）において取得する情報を適用してビットレート制御を行う。

図１３を参照して、実施例３におけるストリーミングデータ配信を実行するサーバ２００と、ストリーミングデータの受信、再生を実行するクライアント３００、およびストリーミング配信経路上の基地局（ＡＰ）４００の機能を説明する。サーバ２００とクライアント３００間では基地局（ＡＰ）４００を介したＴＣＰコネクションが設定されて通信が実行される。

サーバ２００およびクライアント３００の構成は、先に図２を参照して説明した実施例１の構成と同様である。ただしサーバ２００における処理は異なる。基地局（ＡＰ）４００は、図１３に示すように、データ送受信部４０１、通信帯域監視部４０２、通信帯域情報生成部４０３を有する。

基地局（ＡＰ）４００の通信帯域監視部４０２は、無線通信区間のＬ２（データリンク層）レイヤでのＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）や、ＲＳＳＩ（電波強度）、送信レートなどの値を監視する。ＲＴＴは、基地局（ＡＰ）４００からパケットが送信されてからクライアントから応答が戻ってくるまでの時間である。基地局（ＡＰ）４００の通信帯域監視部４０２における監視動作は定期的に行われる。

通信帯域監視部４０２が取得した通信区間の情報は、必要に応じて通信帯域情報生成部４０３において、サーバに通知するためのデータ処理が実行される。データ処理の例としては加重平均値や標準偏差値の導出などである。ＲＴＴ、ＲＳＳＩ、送信レートなどの各値について加重平均値や標準偏差値の導出がなされ、サーバへの報告値が生成される。通信帯域情報生成部４０３の生成したデータは、データ送受信部４０１、通信網を介してサーバ２００に通知される。

基地局（ＡＰ）４００からサーバ２００に送信された通信帯域情報は、サーバ２００のデータ送受信部２０４で受信され、動的レート制御部２１０のビットレート決定部２１２に入力される。ビットレート決定部２１２は、基地局（ＡＰ）４００から取得した通信帯域情報を判定アルゴリズムにかけて解析し、ストリーミングデータのビットレートを減少させた方が良いと判断したときは、即座にビットレートを減少させる。

判定アルゴリズムは、例えば基地局（ＡＰ）４００から取得した通信帯域情報と、ビットレート決定部２１２の保持する閾値との比較処理として実行される。具体的には、例えば基地局（ＡＰ）４００から取得した通信帯域情報に含まれるＲＴＴ、ＲＳＳＩ、送信レートなどに基づく加重平均値や標準偏差値などのパラメータが、ビットレート決定部２１２の保持する閾値をＮ回連続で超過した場合にビットレートを減少させるなどの処理を実行する。このような複数回の閾値比較を行う理由は、突発的に１回だけパラメータが閾値を超過した場合などに、無駄にビットレートを減少させてしまうことを防ぐためである。

実施例３におけるビットレート決定部２１２の処理について、図１４、図１５を参照して説明する。実施例３は、実施例１または実施例２におけるスループット算出処理を併用して、ビットレート制御を行なう。図１４に示すように、ビットレート決定部２１２は、スループット算出部２１１が実施例１または実施例２の処理によって算出した最大スループットを入力するとともに、上述した基地局（ＡＰ）４００から取得した通信帯域情報、具体的には、基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどに基づく加重平均値や標準偏差値などのパラメータを入力する。さらに、先に説明したクライアントのバッファ量の見積もり処理を実行して、ビットレートを決定し、エンコード処理あるいはエンコードデータの選択処理などを実行するデータ処理部２０２に対して、送信データのビットレート決定情報を入力する。見積もりバッファ量は、図１４のバッファ量情報２５０に示すように、クライアントの見積もりバッファ量として０〜ＭＡＸの範囲の見積もりバッファ量がビットレート決定部２１２によって取得される。

図１５に示すフローチャートを参照して、ビットレート決定部２１２の処理シーケンスについて説明する。ビットレート決定部２１２は、ステップＳ５０１において、基地局（ＡＰ）４００から通信帯域情報の入力の有無を判定する。具体的には、ＲＴＴ、ＲＳＳＩ、送信レートなどに基づく加重平均値や標準偏差値などのパラメータである。ステップＳ５０１において、基地局（ＡＰ）４００から通信帯域情報の入力有りと判定すると、ステップＳ５０２に進み、基地局（ＡＰ）４００から入力した通信帯域情報の解析処理を実行する。

ステップＳ５０２の解析処理は、例えば、上述したように、基地局（ＡＰ）４００から取得した通信帯域情報と、ビットレート決定部２１２の保持する閾値との比較処理である。例えば基地局（ＡＰ）４００から取得した基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどに基づく加重平均値や標準偏差値などのパラメータと、ビットレート決定部２１２の保持する閾値との比較処理として実行される。

ステップＳ５０３では、ステップＳ５０２における解析結果として、送信ビットレートの低下が必要と判断されたか否かを判定し、送信ビットレートの低下が必要と判定された場合は、ステップＳ５０４に進み、送信ビットレートの低下処理を実行する。また、ステップＳ５０５において、ステップＳ５０２における解析結果として、送信ビットレートの上昇が可能と判断されたか否かを判定し、送信ビットレートの上昇が可能と判定された場合は、ステップＳ５０６に進み、送信ビットレートの上昇処理を実行する。ただし、スループット算出部２１１が算出した最大スループットに相当するビットレートを最大許容ビットレート、すなわち上限値とする。この上限値は、実施例１、実施例２で説明したスループット算出部２１１またはクライアントが算出する最大スループットに相当する最大許容ビットレートである。

ステップＳ５０３およびステップＳ５０５において、基地局（ＡＰ）４００から取得した通信帯域情報の解析に基づいて、送信ビットレートの低下あるいは上昇が必要と判断するのは、前述したように、基地局（ＡＰ）４００から取得した基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどに基づく加重平均値や標準偏差値などのパラメータと、ビットレート決定部２１２の保持する閾値との比較処理の結果、複数回、連続して同様の結果が発生した場合にビットレートの変更制御を必要と判断する。

例えば、基地局とクライアント間の無線通信におけるＲＴＴが閾値ａより長い状態が継続した場合は、送信ビットレートを低下させる。閾値ｂより短い状態が継続した場合は、送信ビットレートを上昇させる。基地局とクライアント間の無線通信におけるＲＳＳＩ（電波強度）が閾値ｃより高い状態が継続した場合は、送信ビットレートを上昇させる。閾値ｄより低い状態が継続した場合は、送信ビットレートを低下させる。基地局とクライアント間の無線通信におけるビットレートが閾値ｅより低い状態が継続した場合は、送信ビットレートを低下させる。閾値ｆより高い状態が継続した場合は、送信ビットレートを上昇させるなどの処理が行なわれることになる。

ステップＳ５０７〜Ｓ５０９の処理は、実施例１と同様の処理であり、見積もりバッファ量に基づいてビットレートを制御する処理である。すなわち、ステップＳ５０７において、ビットレート決定部２１２は、バッファ量が、予め定めた閾値Ｔｈ１より少ないか否かを判定する。バッファ量が、予め定めた閾値Ｔｈ１より少ないと判定された場合は、ステップＳ５０４に進み、送信ビットレートの低下処理を実行する。この処理は、図１４に示すバッファ量情報２５０におけるバッファ量がＢａの領域にある場合の処理である。

ステップＳ５０７において、バッファ量が、予め定めた閾値Ｔｈ１より少なくないと判定されると、ステップＳ５０８に進み、バッファ量が、予め定めた閾値Ｔｈ２より多いか否かを判定する。バッファ量が、予め定めた閾値Ｔｈ２より多くない場合は、ステップＳ５０１に戻る。この処理は、図６に示すバッファ量情報２５０におけるバッファ量がＢｂの領域にある場合の処理である。

バッファ量が、予め定めた閾値Ｔｈ２より多い場合は、ステップＳ５０６に進み、現在の送信データのビットレートと、スループット算出部２１１が実施例１の処理に従って算出した最大スループット、あるいは実施例２の処理に従って、クライアントまたはスループット算出部２１１が算出した最大スループットに相当する最大許容ビットレートとを比較する。現在の送信データのビットレートが、最大スループットに相当する最大許容ビットレートより小さい場合は、ステップＳ５０６に進み、送信データのビットレートを上昇させる処理を実行する。ただし、最大許容ビットレートを上限値とする。現在の送信データのビットレートが、最大スループットに相当する最大許容ビットレートを等しい場合は、ビットレートの制御を行なうことなく、ステップＳ５０１に戻る。この処理は、図１４に示すバッファ量情報２５０におけるバッファ量がＢｃの領域にある場合の処理である。

実施例３の処理では、実施例１または実施例２のスループット算出処理に従って算出される最大スループットに基づくビットレート制御に加え、基地局（ＡＰ）の測定する基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどの通信帯域情報に基づいて、ビットレートの制御を行う構成としたので、無線通信における通信状態の変動に即応したビットレート制御が実現される。また、実施例１、実施例２と同様、有効なデータ送受信期間に基づくスループット算出値を最大スループットとした設定であるので、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大ビットレートを上限としたデータ送信が実現される。

なお、基地局（ＡＰ）の測定する基地局とクライアント間の無線通信における通信帯域情報に基づいて、サーバクライアント間のストリーミングデータの配信の続行が困難と判断された場合は、サーバまたは基地局（ＡＰ）からクライアントに対してストリーミングデータの配信の続行が困難になったことを通知する構成としてもよい。クライアントでは、通知をディスプレイに表示し、ユーザにデータ配信が困難であることを知らせる処理を実行する。この処理によって、ユーザは、例えばクライアント端末を基地局（ＡＰ）に近づけたり、あるいは障害を発生させている機器、例えば電子レンジの停止などの処置を行なうなどの適切な対応ができる。

［サーバ、基地局（ＡＰ）、クライアントのハードウェア例］
次に、サーバ、基地局（ＡＰ）、クライアントのハードウェア構成例について、図１６参照して説明する。図１を参照して説明したように、サーバやクライアントは様々な機器によって構成可能である。図１６は、サーバ、基地局（ＡＰ）、クライアントとして適用可能なハードウェア構成の一例を示している。

図１６のハード構成について説明する。ＣＰＵ(Central Processing Unit)５０１は、ＲＯＭ(Read Only Memory)５０２、またはＨＤＤ(Hard Disk Drive)等の記録媒体５１４等に記憶されているプログラムに従って、各種の処理を実行し、データ処理手段、あるいは通信制御処理手段として機能する。ＲＡＭ(Random Access Memory)５０３には、ＣＰＵ５０１が実行するプログラムやデータが適宜記憶される。ＣＰＵ５０１、ＲＯＭ５０２、およびＲＡＭ５０３は、バス５２１を介して相互に接続されている。

バス５２１には、入出力インタフェース５２２が接続されており、この入出力インタフェース５２２には、例えば、ユーザにより操作されるキーボード、スイッチ、ボタン、ポインティングデバイス、あるいはマウス等により構成される入力部５１１、ユーザに各種の情報を提示するＬＣＤ、ＣＲＴ、スピーカ等により構成される出力部５１２が接続される。さらに、データ送受信手段として機能する通信部５０４、さらに、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどの記録媒体５１４を装着し、記録媒体５１４からのデータ読み出しあるいは書き込み処理を実行するドライブ５１３が接続される。ただし、基地局（ＡＰ）においては、入力部５１１、出力部５１２、ドライブ５１３、記録媒体５１４等は必ずしも必要とはならない。各種設定を行う設定部当が備えられればよい。

図１６に示す構成は、図１に示すネットワーク接続機器としてのサーバ、基地局（ＡＰ）、クライアントとして利用可能な機器の一例であるが、ネットワーク接続機器は図１６の構成に限らず、様々な電子機器、情報処理装置によって構成することが可能である。従って、それぞれの機器固有のハードウェア構成を持つことが可能である。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。

例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Read Only Memory)に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)，ＭＯ(Magneto optical)ディスク，ＤＶＤ(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本発明の構成によれば、「連続データ送信および受信確認応答（ａｃｋ）の受信期間」、すなわち、［データ送受信実行期間］の計測値を適用して最大スループットを算出し、この最大スループットに基づいて、送信ビットレートの制御を行う構成とした。すなわち、データ送受信に対する寄与のない期間［データ送受信非実行期間］を省いたデータ送受信期間に基づく最大スループットを算出して、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大許容ビットレートを上限としたデータ送信が実現される。

さらに、本発明の構成によれば、クライアントで計測される連続送信パケットの受信間隔に基づいて最大スループットが算出され、算出された最大スループットを上限としたビットレート制御を行うことができる。実際に連続送信されるパケットの計測に基づいて定められる最大スループットを算出して、算出した最大スループットに相当する最大許容ビットレートを上限としたビットレート制御を行う。本構成により、実際の送信レートを考慮したビットレート制御が可能となり、ビットレートの上げすぎや抑えすぎといったことがなく、データ送信を確実に実行可能な最大許容ビットレートを上限としたデータ送信が実現される。

さらに、本発明の構成によれば、実際の送受信データ計測に基づいて算出される最大スループットに基づくビットレート制御に加え、基地局（ＡＰ）の測定する基地局とクライアント間の無線通信におけるＲＴＴ、ＲＳＳＩ、送信レートなどの通信帯域情報に基づいて、ビットレートの制御を行う構成としたので、無線通信における通信状態の変動に即応したビットレート制御が実現される。

本発明の適用可能なネットワーク構成例を示す図である。 ストリーミングデータの送受信装置としてのサーバおよびクライアントの構成を説明するブロック図である。 サーバクライアント間で実行するＴＣＰコネンションの確立に基づくデータ配信処理シーケンスを説明する図である。 ウィンドウサイズに基づくデータの連続配信処理シーケンスについて説明する図である。 本発明の実施例１におけるサーバの処理シーケンスについて説明するフローチャートを示す図である。 本発明の実施例１におけるビットレート決定部の処理について説明する図である。 本発明の実施例１におけるビットレート決定部の処理シーケンスについて説明するフローチャートを示す図である。 本発明の実施例２に対応するストリーミングデータの送受信装置としてのサーバおよびクライアントの構成を説明するブロック図である。 本発明の実施例２のサーバクライアント間のデータ送受信処理において送信される緊急フラグ設定データについて説明する図である。 本発明の実施例２におけるサーバの処理シーケンスについて説明するフローチャートを示す図である。 本発明の実施例２におけるクライアントの処理シーケンスについて説明するフローチャートを示す図である。 サーバのＡＰ発見処理シーケンスについて説明する図である。 本発明の実施例３に対応するストリーミングデータの送受信装置としてのサーバおよびクライアントおよび基地局（ＡＰ）の構成を説明するブロック図である。 本発明の実施例３におけるビットレート決定部の処理シーケンスについて説明する図である。 本発明の実施例３におけるビットレート決定部の処理シーケンスについて説明するフローチャートを示す図である。 サーバ、クライアント、基地局を構成するハードウェアについて説明する図である。

符号の説明

１０１ サーバ
１１０ ネットワーク
１２１，１２２ クライアント（ＰＣ）
１２３ クライアント（携帯端末）
１２４ クライアント（再生装置）
１３１ 基地局（ＡＰ）
２００ サーバ
２０１ コンテンツ提供部
２０２ データ処理部
２０３ 送信バッファ
２０４ データ送受信部
２１０ 動的レート制御部
２１１ スループット算出部
２１２ ビットレート決定部
３００ クライアント
３０１ データ送受信部
３０２ 受信バッファ
３０３ 再生処理部
３０４ 出力部
３０５ パケット間隔計測部
４００ 基地局（ＡＰ）
４０１ データ送受信部
４０２ 通信帯域監視部
４０３ 通信帯域情報生成部
５０１ ＣＰＵ
５０２ ＲＯＭ
５０３ ＲＡＭ
５０４ 通信部
５１１ 入力部
５１２ 出力部
５１３ ドライブ
５１４ 記録媒体
５２１ バス
５２２ 入出力インタフェース

Claims (3)

1. クライアントに対するデータ送信処理を実行するサーバとしての通信処理装置であり、
   クライアントとの通信処理を実行するデータ送受信部と、
   クライアントに対する送信データのビットレートを決定するレート制御部と、
   前記レート制御部において決定されたビットレートに対応する送信データの設定処理を実行するデータ処理部とを有し、
   前記レート制御部は、
   サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出するスループット算出部と、
   前記スループット算出部の算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定するビットレート決定部とを有し、
   前記ビットレート決定部は、
   （ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
   （ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
   （ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
   （ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
   これら（ａ）〜（ｄ）の情報を用いて、
   クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
   として、
   クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なう構成であることを特徴とする通信処理装置。
2. データ送信処理を実行するサーバにおける通信処理方法であり、
   クライアントに対する送信データのビットレートを決定するレート制御ステップと、
   前記レート制御ステップにおいて決定されたビットレートに対応する送信データの設定処理を実行するデータ処理ステップとを有し、
   前記レート制御ステップは、
   サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出するスループット算出ステップと、
   前記スループット算出ステップにおいて算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定するビットレート決定ステップとを有し、
   前記ビットレート決定ステップは、
   （ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
   （ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
   （ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
   （ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
   これら（ａ）〜（ｄ）の情報を用いて、
   クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
   として、
   クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なうことを特徴とする通信処理方法。
3. 送信データのレート制御をコンピュータ上で実行させるコンピュータ・プログラムであり、
   レート制御部において、クライアントに対する送信データのビットレートを決定させるレート制御ステップと、
   データ処理部において、前記レート制御ステップにおいて決定されたビットレートに対応する送信データの設定処理を実行させるデータ処理ステップとを有し、
   前記レート制御ステップは、
   サーバクライアント間における通信コネクション設定期間内におけるデータ送受信実行期間の時間および送信データ量に基づいて最大スループットを算出させるスループット算出ステップと、
   前記スループット算出ステップにおいて算出した最大スループットに相当するビットレートを最大許容ビットレートとして送信ビットレートを決定させるビットレート決定ステップとを有し、
   前記ビットレート決定ステップは、
   （ａ）通信開始時にクライアントから通知されたバッファ量：［Ｂ＿ｃｌｉ（ｂｙｔｅ）］
   （ｂ）クライアントが再生を開始してからの経過時間：［Ｔ（ｓｅｃ）］
   （ｃ）クライアントが再生を開始以降、経過時間［Ｔ（ｓｅｃ）］の間のサーバからの送信データ量：［Ｄ＿ｓｅｒｖ（ｂｙｔｅ）］
   （ｄ）送信コンテンツから取得可能なコンテンツの再生レート［Ｒ（ｂｙｔｅ／ｓｅｃ）］
   これら（ａ）〜（ｄ）の情報を用いて、
   クライアントバッファの見積もりバッファ量＝Ｂ ｃｌｉ＋Ｄ ｓｅｒｖ−Ｒ＊Ｔ
   として、
   クライアントのバッファ量の見積もり処理を実行し、前記見積もりバッファ量の推移に基づいてビットレートを決定する構成であり、見積もりバッファ量が予め定めた閾値以上である場合、前記スループット算出部の算出した最大スループットに相当する最大許容ビットレートを上限としてビットレート上昇処理を行なわせるステップであることを特徴とするコンピュータ・プログラム。

Images