(57)【要約】【課題】  動画像データのビットレートを考慮して、端末に対して動画像データの送信を間欠的に行うような場合には、端末におけるバッファ量を適切に制御することができていなかった。【解決手段】  本発明による配信装置は、配信するデータを受信する端末のバッファ量を推定する推定手段と、前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する調整手段と、を備えることを特徴とする。【選択図】      図１
2013141138.tif 000002
【特許請求の範囲】
【請求項１】
配信するデータを受信する端末のバッファ量を推定する推定手段と、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する調整手段と、
を備えることを特徴とする配信装置。
【請求項２】
前記配信装置は、さらに、
前記ネットワークの状態を監視する監視手段と、
前記端末の種類を判別する判別手段と、
を備え、
前記調整手段は、さらに、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする請求項１に記載の配信装置。
【請求項３】
前記配信装置は、さらに、
前記ネットワークの状態、前記端末の種類、前記データのビットレートのうち、少なくとも１つを用いて、前記端末のバッファに前記データを蓄積させる最大バッファ量と最小バッファ量を決定するバッファ量決定手段と、
前記推定したバッファ量が前記最小バッファ量未満であれば、前記最大バッファ量から、前記最小バッファ量を減算した量に相当するデータを送信する送信手段と、
を備えることを特徴とする請求項２に記載の配信装置。
【請求項４】
前記送信手段は、さらに、
前記端末のバッファが蓄積するデータ量が、前記最大バッファ量を超えず、かつ、前記最小バッファ量を下回らないように、前記データを間欠的に送信する
ことを特徴とする請求項３に記載の配信装置。
【請求項５】
ネットワークを介してデータを配信する配信方法であって、
配信するデータを受信する端末のバッファ量を推定し、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする配信方法。
【請求項６】
前記配信方法は、さらに、
前記ネットワークの状態を監視し、
前記端末の種類を判別し、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする請求項５に記載の配信方法。
【請求項７】
前記配信方法は、さらに、
前記ネットワークの状態、前記端末の種類、前記データのビットレートのうち、少なくとも１つを用いて、前記端末のバッファに前記データを蓄積させる最大バッファ量と最小バッファ量を決定し、
前記推定したバッファ量が前記最小バッファ量未満であれば、前記最大バッファ量から、前記最小バッファ量を減算した量に相当するデータを送信する
ことを特徴とする請求項６に記載の配信方法。
【請求項８】
前記配信方法は、さらに、
前記端末のバッファが蓄積するデータ量が、前記最大バッファ量を超えず、かつ、前記最小バッファ量を下回らないように、前記データを間欠的に送信する
ことを特徴とする請求項７に記載の配信方法。
【請求項９】
ネットワークを介してデータを配信させるプログラムであって、
配信するデータを受信する端末のバッファ量を推定する処理と、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する処理と、
をコンピュータに実行させることを特徴とするプログラム。
【請求項１０】
前記プログラムは、さらに、
前記ネットワークの状態を監視する処理と、
前記端末の種類を判別する処理と、
を含み、
前記調整する処理は、さらに、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする請求項９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してデータを配信する配信装置、配信方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、ネットワークの高速化に伴い、動画像配信サービスが本格的に普及し始めている。家庭やオフィスにおける有線ネットワークを介した動画像配信だけでなく、スマートフォン等の小型で、かつ高機能な端末の登場により、無線ネットワークを介した動画像配信による視聴の割合も急速に増大している。この結果、音声通信やデータ通信によるトラフィックを上回り、動画像視聴によるトラフィックが、ネットワークの輻輳を引き起こす大きな要因となっている。
【０００３】
通常、インターネットを介して、動画像を配信する場合は、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）などが用いられるが、プロキシやファイアウォールなどの中継点に存在するサーバを介する場合、ＲＴＳＰトラフィックの通過が許容されていない場合が多い。
【０００４】
そこで、非特許文献１で述べられているように、ホームページの閲覧などで広く用いられているＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）により、動画像を配信する手法が広く用いられている。
【０００５】
ＨＴＴＰによる動画像配信では、下位レイヤの伝送プロトコルであるＴＣＰ  （Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）により決定される速度でデータが送信される。動画像データのビットレートを考慮せずに、一度に全ての動画像データを配信すると、スループットが高いネットワークでは、受信側で動画像が再生される速度よりも速い速度で動画像データが配信されてしまう問題が生じる。非特許文献１では、ＨＴＴＰによる動画配信において、動画像データのビットレートを考慮して、間欠的に動画像を配信する手法が開示されている。
【０００６】
さらに、ネットワークを介したデータ配信に関連する技術としては、特許文献１や特許文献２が挙げられる。
【０００７】
特許文献１には、配信データの伝送エラーを低減することを目的として、データ特性と、データの通信特性に基づいて、パケット送信間隔を調整することが開示されている。
【０００８】
また、特許文献２には、ディスプレイ（受信側）と無線通信可能なチューナ（送信側）が、ディスプレイの映像バッファの残時間を推定し、推定した残時間と、無線帯域に基づいて、配信するデータのコンテンツビットレートを制御することが開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００９−０４９５２９号公報
【特許文献２】特開２０１１−００９９０４号公報
【非特許文献】
【００１０】
【非特許文献１】Ｋｅｖｉｎ  Ｊ．  Ｍａ，  ｅｔ  ａｌ、  「Ｍｏｂｉｌｅ  Ｖｉｄｅｏ  Ｄｅｌｉｖｅｒｙ  ｗｉｔｈ  ＨＴＴＰ」  ＩＥＥＥ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｍａｇａｚｉｎｅ、  ｐｐ．１６６−１７５、  ２０１１年４月
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述したように、動画像データのビットレートを考慮せずに、短時間に集中して大量のデータを送信することは、ネットワークの輻輳の原因となる。さらに、受信側の端末は、あらかじめ多くのデータを受信することになるため、ユーザが途中で視聴を停止すると、停止した以降の動画像データは無駄となる。よって、効率的にネットワークを利用しているとは言えない。
【００１２】
一方、非特許文献１では、動画像データのビットレートを考慮した動画像配信を行っている。非特許文献１では、ネットワークの輻輳やネットワークの伝送路誤りなどを原因としてスループットの一時的な低下が発生していると、動画像データの配信が端末の再生時刻に間に合わないような場合には、端末側で動画像の再生が停止してしまう。
【００１３】
このスループットの低下による再生停止を防止する方法として、端末側で動画像データをバッファリングさせることが一般的に行われる。しかしながら、端末側で動画像データを過剰にバッファリングしておくと、端末側での再生開始の遅れやネットワークの利用効率の低下を引き起こしてしまう。また、端末のハードウェア的な制約により決まるバッファ可能な動画像データの量も考慮する必要がある。
【００１４】
従って、動画像データのビットレートを考慮して、端末に対して動画像データの送信を間欠的に行うような場合には、端末におけるバッファ量を適切に制御することができていなかった。
【００１５】
本発明の目的は、上述した課題を解決することが可能な、通信装置、通信システム、通信方法、および通信プログラムを提供することにある。
【課題を解決するための手段】
【００１６】
本発明による配信装置は、配信するデータを受信する端末のバッファ量を推定する推定手段と、前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する調整手段と、を備えることを特徴とする。
【００１７】
本発明による配信方法は、ネットワークを介してデータを配信する配信方法であって、配信するデータを受信する端末のバッファ量を推定し、前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整することを特徴とする。
【００１８】
本発明によるプログラムは、ネットワークを介してデータを配信させるプログラムであって、配信するデータを受信する端末のバッファ量を推定する処理と、前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する処理と、をコンピュータに実行させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、データの配信先のバッファ量を適切に制御することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】第１の実施形態による通信システムの構成例を示す図である。
【図２】第１の実施形態によるオリジンサーバ１３０の構成例を示す図である。
【図３】第１の実施形態による動作の流れを示すフローチャートである。
【図４】第１の実施形態における、端末バッファ量と時間の関係を示す図である。
【図５】第１の実施形態における、目標バッファ量の変化を示す図である。
【図６】第２の実施形態によるオリジンサーバ１３０の構成例を示す図である。
【図７】第２の実施形態における、端末バッファ量と時間の関係を示す図である。
【図８】第４の実施形態による配信装置１０００の構成例を示す図である。
【図９】第４の実施形態による動作の流れを示すフローチャートである。
【発明を実施するための形態】
【００２１】
［第１の実施形態］
図１は、本発明の第１の実施形態による通信システムの構成例を示す図である。図１の通信システムは、コアネットワーク１１０、モバイルネットワーク１２０の２つのネットワークを含む。
【００２２】
図１の通信システムでは、オリジンサーバ１３０に蓄積された動画像等のデータを、パソコン１３１、パソコン１３２、モバイル端末１４１、モバイル端末１４２等に配信する例を示している。配信するデータとしては、動画像に限らず、画像のみ、音声のみ、その他各種データであっても良い。以下では、オリジンサーバ１３０は、動画像データを配信するものとして説明する。また、以下では、データの配信先となるパソコン１３１、パソコン１３２、モバイル端末１４１、モバイル端末１４２を「端末」と総称する。
【００２３】
コアネットワーク１１０は、コアルータ１１１、エッジルータ１１２、エッジルータ１１３、エッジルータ１１４、エッジルータ１１５の各ルータを含む。また、コアネットワーク１１０は、キャッシュサーバ１１６を含む。
【００２４】
モバイルネットワーク１２０は、エッジルータ１１４、キャッシュサーバ１２１、基地局１２２、基地局１２３を含む。
【００２５】
図２は、オリジンサーバ１３０の構成の一例を示している。なお、図１の通信システムでは、キャッシュサーバ１１６、キャッシュサーバ１２１が、オリジンサーバ１３０に蓄積されたデータをキャッシュして配信する場合も考えられる。この場合には、キャッシュサーバ１１６、キャッシュサーバ１２１は、図２に示すオリジンサーバ１３０と同様の構成であっても良い。
【００２６】
図２によれば、オリジンサーバ１３０は、推定部１３１、調整部１３２、監視部１３３、判別部１３４、送信部１３５を含む。以下、オリジンサーバ１３０の各部の動作について、図３に示すフローチャートを参照しながら説明する。
【００２７】
まず、調整部１３２は、初期設定として、データ送信周期Ｔ（秒）、目標端末バッファ量Ｂｔ（秒）を設定する（Ｓ２０１）。具体的には、例えば、Ｔ＝２秒、Ｂｔ＝２０秒という値を設定する。データ送信周期Ｔは、通常の状態において、データを送信する周期である。調整部１３２では、配信する動画像データをＴ秒分毎に分割し、Ｔ秒毎に送信する。
【００２８】
ここで、オリジンサーバ１３０が配信する動画像データは、映像と音声が多重化されたフォーマットで保存されたファイルであるとする。また、メディアにおける再生時刻に対応するデータ位置がバイト単位で分かるものとする。なお、通常、動画像データのＴ秒分のデータサイズは区間毎に一定ではない。
【００２９】
さらに、サーバから送信されたデータが端末に到着するまでに要するデータ送信時間を考慮し、その時間だけ送信開始時刻を早くすることもできる。データ送信時間は、データサイズをネットワークのスループットで除算することにより算出できる。例えば、データサイズが１００Ｋバイト、スループットが１Ｍｂｐｓ（ｂｉｔ  ｐｅｒ  ｓｅｃｏｎｄ）である場合、データ送信時間は、１００×８÷１０００＝０．８秒となる。
【００３０】
目標端末バッファ量Ｂｔは、端末側で受信したデータで未再生の部分の時間、即ち、端末が受信済みの動画像データの総時間長から端末が既に再生した時間を減算した時間の目標値である。
【００３１】
端末に設けられるバッファは、ネットワークのスループットが低下した場合に再生が停止することを防止するために用いられるものである。バッファ量が大きい程、長時間の伝送スループットの低下に耐えることが出来るが、その反面、再生開始までに時間を要する欠点もある。また、バッファ量の最大値は、端末が搭載するメモリ量などのハードウェア的な要因などで制約される。
【００３２】
次に、送信部１３５は、配信するデータを送信する（Ｓ２０２）。送信部１３５は、まず、初期データ送信区間において、目標端末バッファ量Ｂｔ（秒）に相当するデータを送信する。その後、送信部１３５は、Ｔ秒周期毎に動画像ファイルの先頭からＴ（秒）のデータを送信する。図４に、端末における動画像データバッファ量と時間の関係を示す。ここでは、データ送信プロトコルとしてＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を用いることとする。また、送信したデータのサイズを送信データ量Ｄ（バイト）として設定する。
【００３３】
続いて、送信部１３５は、データ送信レートを計算する（Ｓ２０３）。具体的には、送信部１３５は、送信データ量Ｄ（バイト）をデータ転送に要した時間で割ることによりデータ送信レートＲ（バイト／秒）を算出する。
【００３４】
データ転送に要した時間は、実装上の制約などにより測定方法が制限されることがあるが、ＴＣＰによる転送の場合、送信を開始した時刻から、送信を終了するまでの時刻、或いは、端末からの受信完了通知であるＡＣＫパケットを受信するまでの時刻とする。
【００３５】
次に、推定部１３１は、端末のバッファ量を推定する計算を行う（Ｓ２０４）。端末で蓄積されているバッファ量の推定値である推定端末バッファ量Ｂｅ（秒）は、送信済の動画像データの時間長である送信済動画像時刻Ｔｓ（秒）から、端末側で再生されている動画像の時刻である端末側動画像再生時刻Ｔｒ（秒）を減算することにより算出する。
【００３６】
端末側動画像再生時刻Ｔｒは、オリジンサーバ１３０が最初のデータを送信した時刻、或いは、端末が最初に送信したデータに対するＡＣＫを返信した時刻を再生開始時刻として、経過時間を加算することで算出する。
【００３７】
最後に、調整部１３２は、データ送信制御を行う（Ｓ２０５）。
【００３８】
調整部１３２は、ネットワークの状態が良好である場合は、Ｔ秒周期でＴ秒分の動画像データを送信するように制御することにより、過剰なネットワークの利用を防止する。この場合、次に送信するＴ秒分のデータを動画像ファイルから読み出し、そのデータサイズＤを取得し、前回データを送信した時刻のＴ秒後に、データを送信するように制御する。
【００３９】
調整部１３２は、もし、Ｔ秒後に、前回のデータ送信が終了していなかった場合は、前のデータ送信が終了した後、すぐに次のデータを送信するように制御する。
【００４０】
このように、予定の時刻にデータの送信ができない状態では、データ送信レートＲが、動画像データのビットレートよりも小さい値となる。また、推定端末バッファ量計算で計算される推定端末バッファ量Ｂｅが減少し、推定端末バッファ量Ｂｅが０となった時点で、端末での再生が停止する。また、調整部１３２は、停止中に相当する時間を端末側動画像再生時刻Ｔｒに加算しないように調整する。
【００４１】
さらに、調整部１３２は、端末とサーバ間のネットワークの種類、ネットワークの状態、端末の種類、動画像のビットレートなどに応じて、図５に示すように、目標端末バッファ量Ｂｔを適切な値に調整し、データ送信時刻、及びデータ送信量を決定する。図５は、端末のバッファ量の時間による変化を示している。実線は、端末のバッファ量を示し、点線は、端末のバッファ量の目標値を示している。
【００４２】
ここで、ネットワークの種類やネットワークの状態といったような、ネットワークの情報については、監視部１３３がネットワークを監視しておくことで取得する。また、端末の種類は、判別部１３４により判別される。
【００４３】
図５における区間Ａは、ネットワークのスループットが、動画像のビットレートより低い区間である。このため、端末のバッファ量は時間の経過とともに減少していく。区間Ａのような場合には、調整部１３２は、端末のバッファ枯渇を避けるために、バッファ量の目標値を増加するよう制御を行う。その後、調整部１３２は、区間Ｂのように、スループットが一定期間安定した状態になってくれば、目標値を下げるような制御を行う。
【００４４】
また、データ送信時刻を決定する際に、データを送信してから端末に到着するまでの伝送時間を考慮して、送信時刻から伝送時間を減算しておくこともできる。伝送時間は、データ送信量をネットワークのスループットで除算することにより算出する。ネットワークのスループットは、直前の測定値、過去の測定値から予測した値、または予測した最悪値とすることもできる。また、伝送時間を予め定めた固定値にすることもできる。
【００４５】
例えば、端末とサーバ間が、有線ネットワークで接続されており、動画像データを配信するために必要なスループットが常に確保できるならば、目標端末バッファ量Ｂｔは最小限の値（１０秒程度以内）にする。
【００４６】
一方、端末とサーバ間に、無線ネットワークが存在するなどして、動画像データを配信するために必要なスループットが、一時的に確保できない状況となりえるならば、目標端末バッファ量Ｂｔを適切な値に増やすことで調整する。
【００４７】
過去のスループットの平均値や分散などの値に対して、適切なＢｔの値を定めておくことで調整を行うことも可能である。３０秒間のスループット平均値が、動画像のビットレートの半分となっても、再生が停止しないようにするには、目標バッファ量を１５秒以上とする必要がある。
【００４８】
スループットの分散が大きい場合は、ネットワークが不安定であり、スループットが下がる可能性が高いと予測し、目標バッファ量を増やすように制御することが有効となる。逆に、スループットの平均値が高い場合や分散が小さい場合は、目標バッファ量を減らすように制御することが有効である。
【００４９】
あるいは、ネットワークの状態の１つとして、過去のスループットに基づいて未来における下限値、または最悪値のスループットを予測しても良い。スループットの下限値または最悪値を予測することで、実際にその下限値のスループットに陥った場合でも、端末のバッファを枯渇させないために最低限必要な値を目標バッファ量として設定することも有効である。
【００５０】
また、目標バッファ量を増減させる場合、瞬時に反映させるように、送信時刻や送信データ量を制御するのではなく、送信レートの急激な変動を抑えるために、時間をかけて目標値に近づくように制御することも有効である。
【００５１】
さらに、端末毎に、確保可能なバッファ量と動画像のビットレートから、確保できる目標端末バッファ量Ｂｔの最大値を定めて、その値を超えないように制御することもできる。例えば、確保可能なバッファ量が１Ｍバイトで、動画像のビットレートが２５０Ｋｂｐｓであるならば、Ｂｔの最大値は、（１Ｍ×８）／２５０Ｋ＝３２秒となる。
【００５２】
以上説明した通り、第１の実施形態によれば、端末のバッファ量を推定し、このバッファ量やネットワークの状態等に基づいて、送信時刻と送信データ量を制御している。よって、第１の実施形態によれば、データの配信先のバッファ量を適切に制御することが可能となる。さらに、ネットワークの状態に応じて送信制御を行うことで、データの配信速度をできるだけ一定にすることが可能となる。
【００５３】
加えて、第１の実施形態によれば、データ配信先のバッファ量を制御することができるため、動画像データの配信において、輻輳を発生させる等のネットワークに悪影響を与えるような、不必要に短時間で大量の動画像データを送信することを防ぐことが可能である。
【００５４】
また、第１の実施形態によれば、ネットワークの輻輳や無線ネットワークにおける電波障害等で発生する伝送スループットの低下によって生じる端末側での動画像再生の停止を極力防止することが可能である。即ち、第１の実施形態によれば、ユーザの体験する動画像品質を向上させながら、効率的なネットワークの利用を実現することができる。
【００５５】
［第２の実施形態］
次に、第２の実施形態について説明する。以下では、第２の実施形態と、第１の実施形態の差分について説明する。各変数は、第１の実施形態で定義したものと同じであり、使用しない変数もある。
【００５６】
図６は、第２の実施形態によるオリジンサーバ１３０の構成を示している。第１の実施形態との違いは、オリジンサーバ１３０がバッファ量決定部１３６を含んでいる点にある。なお、第１の実施形態と同様に、キャッシュサーバ１１６、キャッシュサーバ１２１が図６のオリジンサーバ１３０と同様の構成であっても良い。
【００５７】
以下、図３のフローチャートを参照しながら、第２の実施形態の動作について説明する。まずは、調整部１３２は、初期設定として、第１の実施形態で説明したものに加え、最小端末バッファ量Ｂｌ（秒）、最大端末バッファ量Ｂｈ（秒）を設定する（Ｓ２０１）。具体的には、例えば、Ｂｌ＝４０秒、Ｂｈ＝６０秒という値を設定する。
【００５８】
ここで、最大端末バッファ量Ｂｈは、端末におけるハードウェアなどにより制約されるバッファ量の最大値とする。明確な値が不明な場合でも、ある想定値を設定する。最小端末バッファ量Ｂｌは、Ｂｈより小さい値を設定する。
【００５９】
Ｓ２０２では、送信部１３５は、最大端末バッファ量Ｂｈのデータを送信する。Ｓ２０３では、第１の実施形態と同様に、データ送信レートＲ（バイト／秒）が算出される。
【００６０】
次に、Ｓ２０４では、端末で蓄積されているバッファ量の推定値である推定端末バッファ量Ｂｅ（秒）を第１の実施形態と同様に算出する。
【００６１】
Ｓ２０５では、調整部１３２は、推定端末バッファ量Ｂｅが、Ｂｈを超えずＢｌを下回らないように、ＢｅがＢｌとなる時刻に、Ｂｈ−Ｂｌ（秒）の時間長に相当する動画像データを間欠的に送信するように制御する。図７に、第２の実施形態における推定端末バッファ量と時間の関係を示す。
【００６２】
以上説明した通り、第２の実施形態によれば、端末のバッファ量の最大値や最小値に基づいて、通信時刻と送信データ量を制御している。よって、第２の実施形態によれば、データの配信先のバッファ量を適切に制御することが可能となる。
【００６３】
加えて、第２の実施形態によれば、データ配信先のバッファ量を制御することができるため、動画像データの配信において、輻輳を発生させる等のネットワークに悪影響を与えるような、不必要に短時間で大量の動画像データを送信することを防ぐことが可能である。
【００６４】
また、第２の実施形態によれば、ネットワークの輻輳や無線ネットワークにおける電波障害等で発生する伝送スループットの低下によって生じる端末側での動画像再生の停止を極力防止することが可能である。即ち、第２の実施形態によれば、ユーザの体験する動画像品質を向上させながら、効率的なネットワークの利用を実現することができる。
【００６５】
［第３の実施形態］
次に、本発明の第３の実施形態について説明する。第３の実施形態は、第１の実施形態と第２の実施形態の動作を、ネットワークの状態に応じて切替えることを特徴とする。
【００６６】
まず、図３のフローチャートにおける初期設定（Ｓ２０１）として、目標端末バッファ量Ｂｔ（秒）、最小端末バッファ量Ｂｌ（秒）、最大端末バッファ量Ｂｈ（秒）を設定する。具体的には、例えば、Ｂｔ＝３０秒、Ｂｌ＝４０秒、Ｂｈ＝６０秒という値を設定する。
【００６７】
調整部１３２は、例えば、ネットワークが安定している状態では、第１の実施形態の方法により端末バッファ量を制御し、かつ、目標端末バッファ量Ｂｔの適応的な変更も行う。一方、ネットワークが不安定な状態となると、第２の実施形態の方法に切替える。
【００６８】
ネットワークの状態が不安定と判断するには、例えば、サーバで測定しているスループットにおけるある区間での平均値が予め定めた閾値以下になった場合に、不安定と判断する方法が考えられる。
【００６９】
第３の実施形態によれば、第１の実施形態、第２の実施形態と同様に、端末のバッファ量を推定し、このバッファ量やネットワークの状態等に基づいて、送信時刻と送信データ量を制御している。よって、第３の実施形態によれば、データの配信先のバッファ量を適切に制御することが可能となる。
【００７０】
加えて、第３の実施形態によれば、データ配信先のバッファ量を制御することができるため、動画像データの配信において、輻輳を発生させる等のネットワークに悪影響を与えるような、不必要に短時間で大量の動画像データを送信することを防ぐことが可能である。
【００７１】
また、第３の実施形態によれば、ネットワークの輻輳や無線ネットワークにおける電波障害等で発生する伝送スループットの低下によって生じる端末側での動画像再生の停止を極力防止することが可能である。即ち、第２の実施形態によれば、ユーザの体験する動画像品質を向上させながら、効率的なネットワークの利用を実現することができる。
【００７２】
さらに、配信速度をできるだけ一定にすることを重視する第１の実施形態の方式と、動画像の再生停止を回避することを重視した第２の実施形態の方式を適応的に切替えることで、ネットワーク負荷の低減と動画像品質劣化の低減を効率的に行うことが可能である。
【００７３】
［第４の実施形態］
次に、本発明の第４の実施形態について説明する。図８は、第４の実施形態による配信装置１０００の構成を示す図である。図８の配信装置１０００は、図示されていない端末に対してデータを配信するものである。
【００７４】
図８によれば、配信装置１０００は、推定手段１００１と、調整手段１００２とを含む。
【００７５】
図９は、第４の実施形態による動作の一例を示したフローチャートである。まず、推定手段１００１は、データを受信する端末のバッファ量を推定する（Ｓ１００１）。次に、調整手段は、推定したバッファ量に基づいて、データの送信時刻と、データの送信量とを調整する（Ｓ１００２）。
【００７６】
以上説明した通り、第４の実施形態によれば、端末のバッファ量を推定し、推定したバッファ量に基づいて、送信時刻と送信データ量を制御している。よって、第４の実施形態によれば、データの配信先のバッファ量を適切に制御することが可能となる。
【００７７】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【００７８】
さらに、上記の実施形態の一部または全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００７９】
（付記１）
配信するデータを受信する端末のバッファ量を推定する推定手段と、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する調整手段と、
を備えることを特徴とする配信装置。
【００８０】
（付記２）
前記配信装置は、さらに、
前記ネットワークの状態を監視する監視手段と、
前記端末の種類を判別する判別手段と、
を備え、
前記調整手段は、さらに、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする付記１に記載の配信装置。
【００８１】
（付記３）
前記配信装置は、さらに、
前記ネットワークの状態、前記端末の種類、前記データのビットレートのうち、少なくとも１つを用いて、前記端末のバッファに前記データを蓄積させる最大バッファ量と最小バッファ量を決定するバッファ量決定手段と、
前記推定したバッファ量が前記最小バッファ量未満であれば、前記最大バッファ量から、前記最小バッファ量を減算した量に相当するデータを送信する送信手段と、
を備えることを特徴とする付記２に記載の配信装置。
【００８２】
（付記４）
前記送信手段は、さらに、
前記端末のバッファが蓄積するデータ量が、前記最大バッファ量を超えず、かつ、前記最小バッファ量を下回らないように、前記データを間欠的に送信する
ことを特徴とする付記３に記載の配信装置。
【００８３】
（付記５）
ネットワークを介してデータを配信する配信方法であって、
配信するデータを受信する端末のバッファ量を推定し、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする配信方法。
【００８４】
（付記６）
前記配信方法は、さらに、
前記ネットワークの状態を監視し、
前記端末の種類を判別し、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする付記５に記載の配信方法。
【００８５】
（付記７）
前記配信方法は、さらに、
前記ネットワークの状態、前記端末の種類、前記データのビットレートのうち、少なくとも１つを用いて、前記端末のバッファに前記データを蓄積させる最大バッファ量と最小バッファ量を決定し、
前記推定したバッファ量が前記最小バッファ量未満であれば、前記最大バッファ量から、前記最小バッファ量を減算した量に相当するデータを送信する
ことを特徴とする付記６に記載の配信方法。
【００８６】
（付記８）
前記配信方法は、さらに、
前記端末のバッファが蓄積するデータ量が、前記最大バッファ量を超えず、かつ、前記最小バッファ量を下回らないように、前記データを間欠的に送信する
ことを特徴とする付記７に記載の配信方法。
【００８７】
（付記９）
ネットワークを介してデータを配信させるプログラムであって、
配信するデータを受信する端末のバッファ量を推定する処理と、
前記推定したバッファ量に基づいて、前記データの送信時刻と前記データの送信量とを調整する処理と、
をコンピュータに実行させることを特徴とするプログラム。
【００８８】
（付記１０）
前記プログラムは、さらに、
前記ネットワークの状態を監視する処理と、
前記端末の種類を判別する処理と、
を含み、
前記調整する処理は、さらに、
前記推定したバッファ量に加え、前記ネットワークの状態と、前記端末の種類と、前記データのビットレートのうち、少なくとも１つに基づいて、前記データの送信時刻と前記データの送信量とを調整する
ことを特徴とする付記９に記載のプログラム。
【００８９】
（付記１１）
前記プログラムは、さらに、
前記ネットワークの状態、前記端末の種類、前記データのビットレートのうち、少なくとも１つを用いて、前記端末のバッファに前記データを蓄積させる最大バッファ量と最小バッファ量を決定する処理と、
前記推定したバッファ量が前記最小バッファ量未満であれば、前記最大バッファ量から、前記最小バッファ量を減算した量に相当するデータを送信する処理と、
を含むことを特徴とする付記１０に記載のプログラム。
【００９０】
（付記１２）
前記プログラムは、さらに、
前記端末のバッファが蓄積するデータ量が、前記最大バッファ量を超えず、かつ、前記最小バッファ量を下回らないように、前記データを間欠的に送信する処理と、
を含むことを特徴とする付記１１に記載のプログラム。
【符号の説明】
【００９１】
１１０    コアネットワーク
１１１    コアルータ
１１２、１１３、１１４、１１５    エッジルータ
１１６、１２１    キャッシュサーバ
１２０    モバイルネットワーク
１２２、１２３    基地局
１３１、１３２    パソコン
１４１、１４２    モバイル端末
１０００    配信装置
１００１    推定手段
１００２    調整手段
【図１】
2013141138.tif 000003
【図２】
2013141138.tif 000004
【図３】
2013141138.tif 000005
【図４】
2013141138.tif 000006
【図５】
2013141138.tif 000007
【図６】
2013141138.tif 000008
【図７】
2013141138.tif 000009
【図８】
2013141138.tif 000010
【図９】
2013141138.tif 000011