(57)【要約】【課題】複数の端末間で動的に帯域を分配することで、プログレッシブダウンロード方式で送信されたデータを円滑に再生させること。【解決手段】情報処理装置は、通信部と制御部とを有する。上記通信部は、サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器と通信可能である。上記制御部は、上記複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得可能である。また制御部は、上記複数のクライアント機器のうち、最も短い上記バッファ時間を有するクライアント機器を、上記データを優先して送信すべき優先機器として決定することが可能である。【選択図】図６
2014093655.tif 000002
【特許請求の範囲】
【請求項１】
サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器と通信可能な通信部と、
前記複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得し、前記複数のクライアント機器のうち、最も短い前記バッファ時間を有するクライアント機器を、前記データを優先して送信すべき優先機器として決定することが可能な制御部と
を具備する情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記制御部は、前記サーバから送信された、前記複数のクライアント機器宛の前記データをそれぞれ受信し、前記優先機器宛の前記データを、前記優先機器以外のクライアント機器宛のデータよりも優先して前記優先機器へ送信するように前記通信部を制御可能である
情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
前記制御部は、
前記複数のクライアント装置から、前記バッファ時間情報をそれぞれ受信するように前記通信部を制御可能であり、
前記受信されたバッファ時間情報を比較することで前記優先機器を決定可能である
情報処理装置。
【請求項４】
請求項２に記載の情報処理装置であって、
前記制御部は、
前記サーバから、前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように前記通信部を制御可能であり、
前記エンコードレート情報と、前記複数のクライアント機器へ送信したデータのデータ量と、当該送信を開始してから現在までの経過時間とを基に、前記複数のクライアント機器の前記バッファ時間情報を算出可能である
情報処理装置。
【請求項５】
請求項３に記載の情報処理装置であって、
前記制御部は、
前記サーバから、前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように前記通信部を制御可能であり、
前記エンコードレート情報に応じて、前記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、前記優先機器に割り当てられる帯域を広くするように設定することが可能であり、
前記設定された帯域に対応する速度で前記データを前記複数のクライアント機器へ送信するように前記通信部を制御可能である
情報処理装置。
【請求項６】
請求項１に記載の情報処理装置であって、
前記サーバから送信されたデータをバッファリングして再生することが可能な再生部をさらに具備し、
前記制御部は、
前記サーバから、当該情報処理装置宛及び前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信し、複数のクライアント機器から前記バッファ時間情報をそれぞれ受信するように前記通信部を制御可能であり、
前記受信されたバッファ時間情報を比較することで前記優先機器を決定可能であり、
前記エンコードレート情報に応じて、前記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、前記優先機器に割り当てられる帯域を広くするように設定することが可能であり、
前記優先機器及び当該優先機器以外のクライアント機器へ、前記割り当てられた帯域を示す帯域情報を送信するように前記通信部を制御可能である
情報処理装置。
【請求項７】
サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得し、
前記複数のクライアント機器のうち、最も短い前記バッファ時間を有するクライアント機器を、前記データを優先して送信すべき優先機器として決定する
情報処理方法。
【請求項８】
情報処理装置に、
サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得するステップと、
前記複数のクライアント機器のうち、最も短い前記バッファ時間を有するクライアント機器を、前記データを優先して送信すべき優先機器として決定するステップと
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、ネットワークを介して動画像等のデータを送受信することが可能な情報処理装置、当該情報処理装置における情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来から、ネットワークを介した動画像等のデータの再生方式として、ＨＴＴＰプロトコルを用いてデータをダウンロードしながら再生するプログレッシブダウンロード方式が知られている。
【０００３】
このプログレッシブダウンロード方式により、あるネットワークにおいて複数の端末が同時に動画像データをダウンロードして再生する場合、それぞれについてある程度の帯域が確保されているにも関わらず、端末によっては動画像データを円滑に再生できない場合がある。
【０００４】
これは、プログレッシブダウンロード方式では、複数の端末に対して均一に帯域が配分されてしまうためである。すなわち、複数の端末に帯域が均一に配分された結果、高レートでエンコードされた動画像データについては帯域が不足し、低レートでエンコードされた動画像データについては帯域が過多になる。したがって高レートでエンコードされた動画像データを再生する端末では、バッファにおけるデータの蓄積量が足りなくなり、その再生が中断してしまう場合がある。
【０００５】
このような問題を解決する従来技術として、端末間における静的な帯域制御がある。この技術では、端末毎に、各端末がダウンロードする予定の動画像データのエンコードレートに対応した帯域が設定される。すなわち、１つのネットワーク内で、高レートでエンコードされた動画像データを再生する端末にはその再生に十分な広い帯域が割り当てられ、低レートでエンコードされた動画像を再生する端末には比較的狭い帯域が割り当てられる。
【０００６】
また、プログレッシブダウンロード方式に関連した文献としては、下記特許文献１に記載のものが挙げられる。この特許文献１には、受信端末が、プログレッシブダウンロードを指示された場合に、受信端末内の他のストリーム処理で利用しているリソース（バス帯域、ＣＰＵ等）をプログレッシブダウンロード処理に動的に割当て、ダウンロードが済んでいない部分を高速ダウンロードし、再生が途切れないようにすることが記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１８８９８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記静的な帯域制御では、ネットワーク内におけるダウンロード帯域の上限が決まっているため、柔軟性に欠け、特に無線ＬＡＮ環境において帯域が有効活用されないという問題がある。具体的には、大きな帯域が割り当てられた端末において電波の受信状況が悪化し、スループットが低下した場合、その分の帯域が空くことになるが、他の端末は、その空いた帯域を利用してそのバッファの蓄積量を増やすことはできない。また、電波の受信状況が回復した場合でも、スループット低下によって減ったバッファの蓄積量は回復されない。
【０００９】
また、上記特許文献１に記載の技術は、１つの受信端末において、コンテンツの配信（再生）方式に応じてスループットを制御することはできるが、複数の端末間で動的に帯域を分配することはできない。
【００１０】
以上のような事情に鑑み、本技術の目的は、複数の端末間で動的に帯域を分配することで、プログレッシブダウンロード方式で送信されたデータを円滑に再生させることが可能な情報処理装置、情報処理システム、情報処理方法及びプログラムを提供することにある。
【課題を解決するための手段】
【００１１】
上述の課題を解決するため、本技術の一形態に係る情報処理装置は、通信部と制御部とを有する。上記通信部は、サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器と通信可能である。上記制御部は、上記複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得可能である。また制御部は、上記複数のクライアント機器のうち、最も短い上記バッファ時間を有するクライアント機器を、上記データを優先して送信すべき優先機器として決定することが可能である。
【００１２】
これにより情報処理装置は、バッファ時間情報を基に優先機器を決定することができるため、その優先機器へデータを優先して送信することで、複数のクライアント機器間で動的に帯域を分配することができる。これによりクライアント機器は、プログレッシブダウンロード方式で送信されたデータを円滑に再生することができる。この場合、情報処理装置は、アクセスポイント等の中継ノードであっても構わない。
【００１３】
上記制御部は、上記サーバから送信された、上記複数のクライアント機器宛の上記データをそれぞれ受信し、上記優先機器宛の上記データを、上記優先機器以外のクライアント機器宛のデータよりも優先して上記優先機器へ送信するように上記通信部を制御可能であってもよい。
【００１４】
これにより情報処理装置は、サーバと複数のクライアント機器との通信を中継して、各クライアント機器におけるデータダウンロード再生用の帯域を効率よく分配することができる。
【００１５】
上記制御部は、上記複数のクライアント装置から、上記バッファ時間情報をそれぞれ受信するように上記通信部を制御可能であってもよい。またこの場合制御部は、上記受信されたバッファ時間情報を比較することで上記優先機器を決定可能であってもよい。
【００１６】
これにより情報処理装置は、各クライアント装置からバッファ時間情報を受信することで、優先機器を決定することができる。
【００１７】
上記制御部は、上記サーバから、上記複数のクライアント機器宛に送信された上記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように上記通信部を制御可能であってもよい。またこの場合制御部は、上記エンコードレート情報と、上記複数のクライアント機器へ送信したデータのデータ量と、当該送信を開始してから現在までの経過時間とを基に、上記複数のクライアント機器の上記バッファ時間情報を算出可能であってもよい。
【００１８】
これにより情報処理装置は、データのエンコードレート情報を受信するだけで、クライアント機器と通信することなく、各クライアント装置のバッファ時間情報を算出することができる。
【００１９】
上記制御部は、上記サーバから、上記複数のクライアント機器宛に送信された上記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように上記通信部を制御可能であってもよい。この場合制御部は、上記エンコードレート情報に応じて、上記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、上記優先機器に割り当てられる帯域を広くするように設定することが可能であってもよい。この場合さらに制御部は、上記設定された帯域に対応する速度で上記データを上記複数のクライアント機器へ送信するように上記通信部を制御可能であってもよい。
【００２０】
これにより情報処理装置は、バッファ時間情報に応じて、優先機器のバッファ量が増加するように各クライアント機器に割り当てられる帯域を動的に変更することができる。
【００２１】
上記情報処理装置は、上記サーバから送信されたデータをバッファリングして再生することが可能な再生部をさらに有してもよい。この場合上記制御部は、上記サーバから、当該情報処理装置宛及び上記複数のクライアント機器宛に送信された上記データのエンコードレートをそれぞれ示すエンコードレート情報を受信し、複数のクライアント機器から上記バッファ時間情報をそれぞれ受信するように上記通信部を制御可能であってもよい。またこの場合制御部は、上記受信されたバッファ時間情報を比較することで上記優先機器を決定可能であってもよい。この場合さらに制御部は、上記エンコードレート情報に応じて、上記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、上記優先機器に割り当てられる帯域を広くするように設定することが可能であってもよい。またこの場合さらに制御部は、上記優先機器及び当該優先機器以外のクライアント機器へ、上記割り当てられた帯域を示す帯域情報を送信するように上記通信部を制御可能であってもよい。
【００２２】
これにより情報処理装置は、自らもクライアント機器の一部でありながら、他のクライアント機器のバッファ時間情報を収集し、それを基に優先機器を決定して、優先機器のバッファ量が増加するように各クライアント機器に帯域を割り当て、それを各クライアント機器へ通知することができる。これにより各クライアント機器が、通知を受けた帯域に対応した速度でデータを受信することで、優先機器のバッファ量が増加する。
【００２３】
本技術の他の形態に係る情報処理方法は、サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得すること、及び、上記複数のクライアント機器のうち、最も短い上記バッファ時間を有するクライアント機器を、上記データを優先して送信すべき優先機器として決定することを含む。
【００２４】
本技術のまた別の形態に係るプログラムは、情報処理装置に、取得ステップと決定ステップとを実行させる。上記取得ステップでは、サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報が定期的に取得される。上記決定ステップでは、上記複数のクライアント機器のうち、最も短い上記バッファ時間を有するクライアント機器が、上記データを優先して送信すべき優先機器として決定される。
【発明の効果】
【００２５】
以上のように、本技術によれば、複数の端末間で動的に帯域を分配することで、プログレッシブダウンロード方式で送信されたデータを円滑に再生させることができる。
【図面の簡単な説明】
【００２６】
【図１】本技術の第１の実施形態におけるシステムのネットワーク構成を示した図である。
【図２】上記システムにおけるアクセスポイントのハードウェア構成を示したブロック図である。
【図３】上記システムにおける端末のハードウェア構成を示したブロック図である。
【図４】上記システムにおけるサーバ、アクセスポイント及び端末が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【図５】上記アクセスポイントが有するバッファ時間データベースの構成を示した図である。
【図６】上記アクセスポイントによる、各端末へのパケット転送処理の流れを示したフローチャートである。
【図７】上記アクセスポイントによる、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。
【図８】上記端末による動画像データのパケットの受信処理の流れを示したフローチャートである。
【図９】上記端末による動画像データの再生処理の流れを示したフローチャートである。
【図１０】上記端末によるバッファ時間登録処理の流れを示したフローチャートである。
【図１１】従来のネットワーク環境における動画像データの再生処理の概要を示した図である。
【図１２】従来のネットワーク環境における動画像データの再生処理の概要を示した図である。
【図１３】従来のネットワーク環境における動画像データの再生処理の概要を示した図である。
【図１４】本技術の第１の実施形態における動画像データの再生処理の概要を示した図である。
【図１５】本技術の第２の実施形態におけるサーバ、アクセスポイント及び端末が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【図１６】本技術の第２の実施形態に係るアクセスポイントによる、各端末へのパケット転送処理の流れを示したフローチャートである。
【図１７】本技術の第２の実施形態に係るアクセスポイントによる、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。
【図１８】本技術の第３の実施形態におけるサーバ、アクセスポイント及び端末が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【図１９】本技術の第３の実施形態においてアクセスポイントが有するバッファ時間データベースの構成を示した図である。
【図２０】本技術の第３の実施形態に係るアクセスポイントによる、各端末へのパケット転送処理の流れを示したフローチャートである。
【図２１】本技術の第３の実施形態に係るアクセスポイントによる、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。
【図２２】本技術の第４の実施形態におけるサーバ、アクセスポイント及び端末が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【図２３】本技術の第４の実施形態に係る端末による動画像データのパケットの受信処理の流れを示したフローチャートである。
【図２４】本技術の第４の実施形態に係る端末による動画像データの再生処理の流れを示したフローチャートである。
【図２５】本技術の第４の実施形態に係る端末によるバッファ時間登録処理の流れを示したフローチャートである。
【図２６】本技術の第４の実施形態に係る端末による帯域変更処理の流れを示したフローチャートである。
【発明を実施するための形態】
【００２７】
以下、本技術に係る実施形態を、図面を参照しながら説明する。
【００２８】
＜第１の実施形態＞
まず、本技術の第１の実施形態を説明する。
【００２９】
［システムのネットワーク構成］
図１は、本実施形態に係るシステムのネットワーク構成を示した図である。
【００３０】
同図に示すように、このシステムは、配信サーバ３００、アクセスポイント１００及び端末２００を有する。配信サーバ３００は複数存在しうる。同図では２台の配信サーバ３００Ａ及び３００Ｂが示されているが、３台以上の配信サーバ３００が存在していてもよい。また端末２００も、１つのアクセスポイント１００に対して複数存在しうる。同図では２台の端末２００Ａ及び２００Ｂが示されているが、１つのアクセスポイント１００に３台以上の端末２００が接続されていてもよい。
【００３１】
配信サーバ３００は、例えばインターネット５０上に設けられ、端末２００へ動画像データを配信する。動画像データはプログレッシブダウンロード方式により送信される。配信サーバ３００または動画像データの種類等によって、動画像データのエンコードレートは異なる場合がある。
【００３２】
端末２００は、アクセスポイント１００によって無線ＬＡＮ１５０及びインターネット５０に接続される。端末２００は、アクセスポイント１００を介して、上記配信サーバ３００から動画像データをプログレッシブダウンロード方式により受信し、バッファリングして再生する。
【００３３】
端末２００は、例えばスマートフォン、携帯電話機、タブレットＰＣ（Personal Computer）、デスクトップＰＣ、ノートブックＰＣ、ＴＶ、ＰＤＡ（Personal Digital Assistant）、携帯型ＡＶプレイヤー、電子ブック、デジタルスチルカメラ、カムコーダ、テレビジョン装置、ＰＶＲ（Personal Video Recorder）、ゲーム機器、プロジェクター、カーナビゲーションシステム等、あらゆる情報処理装置であり得る。
【００３４】
アクセスポイント１００は、インターネット５０を介して配信サーバ３００から異なる複数の端末２００宛の動画像データを受信し、それらを、その宛先である無線ＬＡＮ１５０の配下の各端末２００へ送信する。
【００３５】
アクセスポイント１００は、ルータとしての機能を有する情報処理装置である。詳細は後述するが、本実施形態におけるアクセスポイント１００は、無線ＬＡＮ１５０における帯域を有効活用すべく、配下の各端末２００に送信される動画像データのパケットに優先順位を付与することで、各端末２００における動画像データのバッファ量を制御する機能を有する。
【００３６】
［アクセスポイントのハードウェア構成］
図２は、上記アクセスポイント１００のハードウェア構成を示した図である。同図に示すように、アクセスポイント１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。
【００３７】
ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながらアクセスポイント１００の各ブロック全体を統括的に制御する。本実施形態では、ＣＰＵ１１は、例えば配信サーバ３００からの動画像データの受信処理や各端末２００への送信処理（上記バッファ量の制御処理を含む）等を実行する。
【００３８】
ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種プログラム、処理中の各種データを一時的に保持する。
【００３９】
入出力インタフェース１５には、操作受付部１７、記憶部１８、通信部１９等が接続される。
【００４０】
操作受付部１７は、例えばプッシュボタンであるが、タッチパネル等の他の入力装置であってもよい。
【００４１】
記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。特に本実施形態において、記憶部１８には、上記各端末２００における動画像データのバッファ量を制御するためのプログラム及びそのためのデータベース等が記憶される。
【００４２】
通信部１９は、インターネット５０に接続するためのＮＩＣ、及び、無線ＬＡＮ１５０を構築するための無線通信モジュールを有する。図示しないが、アクセスポイント１００は、無線ＬＡＮによる通信用のアンテナも有する。
【００４３】
［端末のハードウェア構成］
図３は、上記端末２００のハードウェア構成を示した図である。同図に示すように、端末２００は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、入出力インタフェース２５、及び、これらを互いに接続するバス２４を備える。
【００４４】
ＣＰＵ２１は、必要に応じてＲＡＭ２３等に適宜アクセスし、各種演算処理を行いながら端末２００の各ブロック全体を統括的に制御する。本実施形態では、ＣＰＵ２１は、例えば、動画像データのダウンロード及び再生処理、後述するバッファ時間の算出処理及びアクセスポイント１００へのバッファ時間の通知処理等を実行する。
【００４５】
ＲＯＭ２２及びＲＡＭ２３の機能は上記アクセスポイント１００のＲＯＭ１２及びＲＡＭ１３の機能と同様であるため説明を省略する。
【００４６】
入出力インタフェース２５には、表示部２６、操作受付部２７、記憶部２８、通信部２９等が接続される。
【００４７】
表示部２６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。端末２００によっては、自身では表示部２６を内蔵しておらず、外部の表示装置に接続されている機器もある。当該表示部２６は、配信サーバ３００からアクセスポイント１００を介してダウンロードされ再生された動画像データを表示する。
【００４８】
操作受付部２７は、例えばマウス等のポインティングデバイス、キーボード、ボタン、タッチパネル、その他の入力装置である。操作受付部２７がタッチパネルである場合、そのタッチパネルは表示部２６と一体となり得る。
【００４９】
記憶部２８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部２８には、上記ＯＳや各種アプリケーション、各種データが記憶される。特に本実施形態において、記憶部２８は、プログレッシブダウンロード方式によりダウンロードされた動画像データのキャッシュとしても機能する。
【００５０】
通信部１９は、無線ＬＡＮ１５０等に接続するための無線通信モジュールであるが、インターネット５０有線接続するためのＮＩＣ等を有していても構わない。
【００５１】
［サーバ、アクセスポイント及び端末のモジュール構成］
図４は、上記アクセスポイント１００、端末２００及び配信サーバ３００が有するソフトウェアモジュール及びデータベースの構成を示した図である。
【００５２】
同図に示すように、配信サーバ３００は、ソフトウェアモジュールとしての送信部３０１を有する。
【００５３】
送信部３０１は、端末２００からの要求に応じて、所定のエンコードレートでエンコードされた動画像データを、プログレッシブダウンロード方式により送信する。
【００５４】
アクセスポイント１００は、受信部１０１、優先制御フラグ設定モジュール１０２及び送信部１０３の各ソフトウェアモジュール及びバッファ時間データベース１０４を有する。
【００５５】
受信部１０１は、配信サーバ３００から、各端末２００宛の動画像データ（パケット）を受信する。
【００５６】
優先制御フラグ設定モジュール１０２は、受信部１０１からパケットを受け取り、優先的にパケットを送信すべき端末を優先端末として決定し、当該優先端末宛のパケットに優先フラグを設定して送信部１０３へ送る。
【００５７】
本実施形態において上記優先端末の決定処理には、「バッファ時間」という概念が用いられる。バッファ時間とは、各端末２００のバッファに蓄積されている動画像データの量が、データサイズではなく、当該データの再生に必要な時間で表現されたものである。
【００５８】
優先制御フラグ設定モジュール１０２は、動画像データの受信を開始した各端末２００から、上記バッファ時間を示すバッファ時間情報を定期的に受信する。そして優先制御フラグ設定モジュール１０２は、各端末２００から受信したバッファ時間情報を比較し、最も少ないバッファ時間を有する端末２００、すなわちバッファの状態が最も逼迫している（アンダーフローの可能性がある）端末２００を優先端末と決定し、優先端末宛のパケットに優先フラグを設定する。
【００５９】
各端末２００におけるバッファ量がバッファ時間として表現されることで、優先制御フラグ設定モジュール１０２は、エンコードレートの異なる動画像データのバッファ量を同じ尺度で比較することができる。
【００６０】
バッファ時間データベース１０４は、上記各端末２００から受信したバッファ時間情報を、各端末２００に関するデータと共に記憶する。
【００６１】
送信部１０３は、上記優先制御フラグ設定モジュール１０２が設定した優先フラグに基づいて、各端末２００へ動画像データのパケットを送信する。
【００６２】
端末２００は、受信部２０１、バッファ２０２、デコーダ２０３及びバッファ時間管理部２０４の各ソフトウェアモジュールを有する。
【００６３】
受信部２０１は、上記アクセスポイント１００の送信部１０３から送信された動画像データのパケットを受信し、バッファ２０２へ送る。
【００６４】
バッファ２０２は、上記受信された動画像データを一時的に蓄積し、所定のデータ量が蓄積された場合に、当該データをデコーダ２０３へ出力する。
【００６５】
デコーダ２０３は、上記バッファ２０２から出力されたデータをデコードし、上記表示部２６へ出力して再生させる。
【００６６】
バッファ時間管理部２０４は、上記バッファ２０２に蓄積されたデータのサイズと、予め配信サーバ３００から通知された動画像データのエンコードレートとから、バッファ時間を定期的に算出し、アクセスポイント１００へ通知する。
【００６７】
［バッファ時間データベースの構成］
図５は、上記アクセスポイント１００が有するバッファ時間データベース１０４の構成を示した図である。
【００６８】
同図に示すように、バッファ時間データベース１０４は、配信サーバ３００から各端末２００へ送信された動画像データを識別するストリームＩＤと、各端末２００のＵＰアドレス及びポート番号と、各端末２００におけるバッファのバッファ時間とで構成される。動画像データのエンコードレートの違いは、その配信元である配信サーバ３００の違いによるものである場合、上記ストリームＩＤは、配信サーバ３００のＩＤとしての機能も有している。
【００６９】
［システムの動作］
次に、以上のように構成されたシステムにおけるアクセスポイント１００及び端末２００の動作について説明する。本実施形態及び他の実施形態において、アクセスポイント１００及び端末２００における動作は、それらの各ＣＰＵ１１及び２１と、その制御下においてそれぞれ実行される上記各ソフトウェアモジュールとで協働して行われる。
【００７０】
［アクセスポイントの動作］
まず、アクセスポイント１００の動作について説明する。図６は、アクセスポイント１００による各端末２００へのパケット転送処理の流れを示したフローチャートである。また図７は、アクセスポイント１００による、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。これら２つの処理は、並行して実行される。
【００７１】
（パケット転送処理）
図６に示すように、まず、アクセスポイント１００の受信部１０１は、配信サーバ３００から、配下のいずれかの端末２００宛の動画像データのパケットを受信する（ステップ６１）。
【００７２】
続いて優先制御フラグ設定モジュール１０２は、上記受信したパケットが、優先端末宛か否かを判断する（ステップ６２）。
【００７３】
上記パケットが優先端末宛であると判断した場合（Ｙｅｓ）、優先制御フラグ設定モジュール１０２は、上記パケットに対して優先フラグをＯＮに設定し、当該パケットを送信部１０３へ送る（ステップ６３）。
【００７４】
一方、上記パケットが優先端末宛でないと判断した場合（Ｎｏ）、優先制御フラグ設定モジュール１０２は、上記パケットに対する優先フラグをＯＦＦに設定して、当該パケットを送信部１０３へ送る（ステップ６４）。
【００７５】
そして送信部１０３は、上記優先フラグの設定にしたがって、上記パケットをその宛先である端末２００へ送信する（ステップ６５）。
【００７６】
ここで、優先フラグの設定には、例えばIEEE802.11eが用いられる。IEEE802.11eの優先フラグが設定されたパケットは、当該パケットの転送レートが無線ＬＡＮ１５０における帯域の上限に達した場合でも、廃棄されることなく優先的に送信される。
【００７７】
IEEE802.11eに代えて、上記パケットのＩＰヘッダ内のＴｏＳ（Type of Service）フィールドのIP Precedenceに優先度が設定されてもよい。また上記ＴｏＳフィールドがＤＳ（DiffServ）フィールドとして再定義されたＤＳＣＰ（DiffServ Code Point）が利用されても構わない。これらの場合も、上記IEEE802.11eが利用される場合と同様の優先的な送信処理が実現される。
【００７８】
優先度の設定手法は、以上説明したものに限られるものではなく、様々な手法が用いられ得る。
【００７９】
（優先端末決定処理）
図７に示すように、まず、アクセスポイント１００の優先制御フラグ設定モジュール１０２は、各端末２００から、バッファ時間情報を受信する（ステップ７１）。
【００８０】
続いて優先制御フラグ設定モジュール１０２は、上記受信したバッファ時間情報を基に、上記バッファ時間データベース１０４を更新する（ステップ７２）。
【００８１】
続いて優先制御フラグ設定モジュール１０２は、上記バッファ時間データベース１０４から、各バッファ時間情報の比較により、最短のバッファ時間を有する端末２００を検索する（ステップ７３）。
【００８２】
そして優先制御フラグ設定モジュール１０２は、上記最短のバッファ時間を有する端末２００が、前回の検索時と異なる端末２００であるか否かを判断し（ステップ７４）、異なる端末２００である場合には当該端末２００を新たな優先端末として決定する（ステップ７５）。
【００８３】
いずれかの端末２００が動画像データのダウンロードを開始してから最初に優先端末が決定される場合には、上記ステップ７４から７５の処理では、最短のバッファ時間を有する端末２００がそのまま優先端末として決定される。
【００８４】
優先制御フラグ設定モジュール１０２は、以上の処理を、各端末２００からバッファ時間情報を定期的に受信する度に実行する。
【００８５】
［端末の動作］
次に、端末２００の動作について説明する。図８は、端末２００による動画像データのパケットの受信処理の流れを示したフローチャートである。また図９は、端末２００による動画像データの再生処理の流れを示したフローチャートである。また図１０は、端末２００によるバッファ時間登録処理の流れを示したフローチャートである。これら３つの処理は、並行して実行される。
【００８６】
（パケット受信処理）
図８に示すように、端末２００の受信部２０１は、アクセスポイント１００から動画像データのパケットを受信すると（ステップ８１）、当該データをバッファ２０２へ書き込む（ステップ８２）。
【００８７】
（再生処理）
図９に示すように、端末２００のデコーダ２０３は、バッファ２０２へのデータの蓄積量が所定量に達した場合、バッファ２０２から当該データを取り出す（ステップ９１）。
【００８８】
続いてデコーダ２０３は、上記取り出したデータを書き込み（ステップ９２）、当該データをデコードして（ステップ９３）、表示部２６へ出力する（ステップ９４）。
【００８９】
（バッファ時間登録処理）
図１０に示すように、まず、端末２００のバッファ時間管理部２０４は、所定の時間間隔に設定されたタイマーが満了したことを検出する（ステップ１０１）。
【００９０】
続いてバッファ時間管理部２０４は、その時点におけるバッファ２０２のデータ蓄積量を確認する（ステップ１０２）。
【００９１】
続いてバッファ時間管理部２０４は、上記バッファ２０２のデータ量と、現在受信している動画像データのエンコードレートとを基に、上記バッファ時間を算出する（ステップ１０３）。具体的には、バッファ時間管理部２０４は、上記データ量をエンコードレートで除した値をバッファ時間として算出する。
【００９２】
続いてバッファ時間管理部２０４は、上記算出したバッファ時間を示すバッファ時間情報を、アクセスポイント１００へ登録（送信）する（ステップ１０４）。
【００９３】
そしてバッファ時間管理部２０４は、次回のバッファ時間登録処理のためのタイマーを設定する（ステップ１０５）。
【００９４】
バッファ時間管理部２０４は、以上の処理を、タイマーが満了する度に繰り返す。
【００９５】
［本実施形態において実現される再生処理及びその効果］
以下では、本実施形態において実現される再生処理の効果について、従来技術と比較して説明する。
【００９６】
図１１、図１２、図１３は、従来のネットワーク環境における動画像データの再生処理を概略的に示した図である。
【００９７】
これらいずれのネットワーク環境も、本実施形態と同様、インターネット及び無線ＬＡＮによって構築されている。２台の端末（端末Ａ、端末Ｂ）は、異なる配信サーバ（配信サーバＡ、配信サーバＢ）から、それぞれプログレッシブダウンロード方式で送信された動画像データを、アクセスポイントを介して受信して再生する。
【００９８】
端末Ａが配信サーバＡから受信して再生する動画像データＭ１のエンコードレートは２Ｍｂｐｓ、端末Ｂが配信サーバＢから受信して再生する動画像データＭ２のエンコードレートは６Ｍｂｐｓとする。またいずれのネットワーク環境においても、動画像データの実効スループットは１０Ｍｂｐｓとする。
【００９９】
図１１に示すネットワーク環境では、動画像データがプログレッシブダウンロード方式で送信されるため、各端末は、実効スループットである１０Ｍｂｐｓを５Ｍｂｐｓずつ利用することになる。
【０１００】
端末Ａにおいては、動画像データＭ１のエンコードレートよりもそのスループットが大きいため、動画像データＭ１は継続してバッファに蓄積され、データは途切れることなく再生される。一方、端末Ｂでにおいては、動画像データＭ２のエンコードレートよりもそのスループットが小さいため、バッファがアンダーフローし、動画像データの再生が途中で途切れてしまう。
【０１０１】
２つの動画像データＭ１、Ｍ２のエンコードレートの合計は２＋６＝８Ｍｂｐｓであるため、適切に帯域が配分されれば、いずれの端末でも途切れることのない動画像データの再生が可能なはずである。そこで、従来技術では、図１２に示すように、静的な帯域制御が利用される。この静的な帯域制御が利用された場合、例えば端末Ａに３Ｍｂｐｓ、端末Ｂに７Ｍｂｐｓの帯域が割り当てられることで、いずれの端末でも途切れることなく動画像データが再生される。
【０１０２】
しかし、図１２に示した静的な帯域制御では、各端末が利用できる帯域の上限が決まってしまうため、柔軟性に欠けており、無線ＬＡＮ環境で帯域を有効に活用できない状況が発生してしまう。その状況を示したのが図１３である。
【０１０３】
例えば、端末Ｂの電波の受信状況が悪化し、スループットが３Ｍｐｂｓに低下したとする。そうすると、７−３＝４Ｍｂｐｓの帯域が空くことになる。しかし、上述のような静的な帯域制御が設定されている場合、端末Ａはその空き帯域を利用してバッファの蓄積量を増やすことができない。
【０１０４】
また、端末Ｂの電波の受信状況が回復した場合でも、端末Ｂは、受信状況悪化によるスループット低下時に減ってしまったバッファの蓄積量を回復することができない。
【０１０５】
図１４は、上記従来のネットワーク環境と比較して、本実施形態において実現される動画像データの再生処理を概略的に示した図である。
【０１０６】
同図に示すように、本実施形態では、より柔軟な帯域の配分を行うため、上述のように、アクセスポイント１００及び各端末２００は、各端末２００のバッファ２０２におけるデータ蓄積量を、バッファ時間として扱う。これによりアクセスポイント１００は、エンコードレートの異なる動画像データＭ１及びＭ２を、同じ尺度で比較でき、バッファ２０２の状態が最も逼迫している端末２００に優先的にデータを転送する。
【０１０７】
例えば、端末２００Ａのバッファに４Ｍビット、端末２００Ｂのバッファに６Ｍビットのデータがそれぞれ蓄積されているとする。また図１１〜図１３と同様に、端末２００Ａが受信する動画像データのエンコードレートは２Ｍｂｐｓ、端末２００Ｂが受信する動画像データのエンコードレートは６Ｍｂｐｓであるとする。この場合、データサイズは端末２００Ｂのバッファ２０２Ｂに蓄積されたデータの方が大きい。しかし、バッファ時間で比較すると、端末２００Ａのバッファ２０２Ａに蓄積されたデータのバッファ時間は２秒であり、端末２００Ｂのバッファに蓄積されたデータのバッファ時間は１秒であるため、端末２００Ｂのバッファの方がより逼迫した状態であると言える。
【０１０８】
したがってアクセスポイント１００は、端末２００Ｂを優先端末として決定し、端末２００Ｂへ送信されるパケットに優先フラグを設定することで、端末２００Ｂへパケットを優先的に送信する。これによりアクセスポイント１００は、常に無線ＬＡＮ１５０の帯域を最大限に利用しつつ、全ての配下の端末２００において、動画像データを極力途切れさせずに再生させることができる。
【０１０９】
＜第２の実施形態＞
次に、本技術の第２の実施形態を説明する。本実施形態及びこれ以降の実施形態において、上記第１の実施形態と同様の機能を有する箇所には同一の符号を付してその説明を省略または簡略化し、第１の実施形態と異なる点を中心に説明する。
【０１１０】
上記第１の実施形態では、アクセスポイント１００は各端末２００から定期的にバッファ時間情報を取得していた。一方、本実施形態では、アクセスポイント１００は、自ら各端末２００のバッファ時間を算出する。
【０１１１】
［サーバ、アクセスポイント及び端末のモジュール構成］
図１５は、本実施形態における配信サーバ３００、アクセスポイント１００及び端末２００が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【０１１２】
同図に示すように、本実施形態では、上記第１の実施形態の図４で示したシステムと比較して、端末２００のバッファ時間管理部２０４が廃される代わりに、アクセスポイント１００が、バッファ時間管理部１０５を有している。
【０１１３】
また、配信サーバ３００は、上記第１の実施形態と比較して、新たにビットレート通知部３０２を有している。
【０１１４】
アクセスポイント１００のバッファ時間管理部１０５は、配信サーバ３００から、各端末２００宛に送信される動画像データのパケットのビットレート（エンコードレート）を問い合わせ、当該ビットレートを示すビットレート情報を取得する。そしてバッファ時間管理部１０５は、ある端末２００が動画像データのダウンロードを開始すると、その端末２００宛に送信したパケットのデータサイズと、当該動画像データのビットレート情報とを基に、その端末２００のバッファ時間を算出する。図示しないが、バッファ時間管理部１０５は、上記第１の実施形態の図５で示したのと同様のバッファ時間データベースを有しており、算出されたバッファ時間は当該データベースに記憶される。
【０１１５】
配信サーバ３００のビットレート通知部３０２は、上記バッファ時間管理部１０５からの要求を受けて、各端末２００宛の動画像データのパケットのビットレートをアクセスポイント１００へ通知する。
【０１１６】
［システムの動作］
次に、本実施形態におけるアクセスポイント１００の動作について説明する。図１６は、アクセスポイント１００による各端末２００へのパケット転送処理の流れを示したフローチャートである。また図１７は、アクセスポイント１００による、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。これら２つの処理は、並行して実行される。
【０１１７】
（パケット転送処理）
図１６に示すように、本実施形態におけるアクセスポイント１００のパケット転送処理の流れ（ステップ１６１〜１６５）は、上記第１の実施形態において図６で説明したアクセスポイント１００のパケット転送処理の流れ（ステップ６１〜６５）と同様である。したがってここではその説明は省略する。
【０１１８】
（優先端末決定処理）
図１７に示す処理の前提として、上述したように、アクセスポイント１００は、配信サーバ３００から、各端末２００宛に送信される動画像データのパケットのビットレートを問い合わせ、当該ビットレートを示すビットレート情報を取得しておく。
【０１１９】
図１７に示すように、まず、アクセスポイント１００のバッファ時間管理部１０５は、所定の時間間隔に設定されたタイマーが満了したことを検出する（ステップ１７１）。
【０１２０】
続いてバッファ時間管理部１０５は、配信サーバ３００から受信し各端末２００へ送信したデータのサイズを送信部１０３からそれぞれ取得する（ステップ１７２）。
【０１２１】
続いてバッファ時間管理部１０５は、上記予め取得した各端末２００宛のデータのビットレートと、上記取得した送信済みデータサイズと、当該送信を開始した時刻（端末２００がダウンロードを開始した時刻）から現在までの経過時間とを基に、各端末２００のバッファ時間を算出する（ステップ１７３）。
【０１２２】
バッファ時間は、上記取得した送信済みデータサイズをＤ、端末２００がダウンロードを開始した時刻をＴ１、現在時刻をＴ２、上記ビットレートをＲとすると、以下の式で算出される。
【０１２３】
【数１】
2014093655.tif 000003
【０１２４】
算出されたバッファ時間に関する情報は、上記バッファ時間データベースに登録される。
【０１２５】
続いて優先制御フラグ設定モジュール１０２は、バッファ時間管理部１０５と協働して、上記バッファ時間データベースから、各バッファ時間情報の比較により、最短のバッファ時間を有する端末２００を検索する（ステップ１７４）。
【０１２６】
続いて優先制御フラグ設定モジュール１０２は、上記最短のバッファ時間を有する端末２００が、前回の検索時と異なる端末２００であるか否かを判断する（ステップ１７５）。
【０１２７】
最短のバッファ時間を有する端末が異なる端末２００である場合には、優先制御フラグ設定モジュールは、当該端末２００を新たな優先端末として決定し、当該優先端末宛のパケットに優先フラグを設定して送信部１０３へ送る（ステップ１７６）。
【０１２８】
いずれかの端末２００が動画像データのダウンロードを開始してから最初に優先端末が決定される場合には、上記ステップ１７５から１７６の処理では、最短のバッファ時間を有する端末２００がそのまま優先端末として決定される。
【０１２９】
そして優先制御フラグ設定モジュール１０２は、次回の優先端末決定処理のためのタイマーを設定する（ステップ１７７）。
【０１３０】
優先制御フラグ設定モジュール１０２は、以上の処理を、タイマーが満了する度に繰り返す。
【０１３１】
このように本実施形態では、アクセスポイント１００は、配信サーバ３００から、端末２００宛の動画像データのエンコードレートを受信することで、自ら各端末２００のバッファ時間を算出し、優先端末を決定することができる。
【０１３２】
＜第３の実施形態＞
次に、本技術の第３の実施形態を説明する。
【０１３３】
上記第１及び第２の実施形態では、アクセスポイント１００は、優先端末へパケットを優先して送信するために、例えばIEEE802.11eやＩＰヘッダ内のＴｏＳフィールド等の優先制御方法を利用した。しかし、本実施形態では、アクセスポイント１００は、各端末２００宛の動画像データのエンコードレートに応じて、無線ＬＡＮ１５０において各端末２００用に割り当てられる帯域を動的に変更することで、優先端末宛のパケットを優先して送信する。
【０１３４】
［サーバ、アクセスポイント及び端末のモジュール構成］
図１８は、本実施形態における配信サーバ３００、アクセスポイント１００及び端末２０が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【０１３５】
同図に示すように、本実施形態では、アクセスポイント１００は、上述の第１及び第２の実施形態において有していた優先制御フラグ設定モジュール１０２に代えて、帯域制御モジュール１０６を有している。
【０１３６】
アクセスポイント１００、端末２００及び配信サーバ３００が有するその他のモジュールの構成は上記第１の実施形態における図４の構成と同様である。しかし、この構成に代えて、上記第２の実施形態における図１５の構成における優先制御フラグ設定モジュール１０２が帯域制御モジュール１０６に変更された構成が採用されても構わない。
【０１３７】
帯域制御モジュール１０６は、各端末２００からバッファ時間情報を取得し、それらの比較により、優先機器を決定する。また帯域制御モジュール１０６は、配信サーバ３００から、各端末２００宛の動画像データのエンコードレートを取得し、当該エンコードレートに応じて、優先端末以外の端末２００に割り当てられる帯域を狭くし、優先機器に割り当てられる帯域を広くするように帯域を制御する。
【０１３８】
［バッファ時間データベースの構成］
図１９は、本実施形態においてアクセスポイント１００が有するバッファ時間データベース１０４の構成を示した図である。
【０１３９】
同図に示すように、本実施形態におけるバッファ時間データベース１０４では、上記第１の実施形態において図５で説明したものと比較すると、動画像データのエンコードレートが追加されている。これは、各端末２００に割り当てる帯域を計算するためにエンコードレートが必要であるためである。
【０１４０】
［システムの動作］
次に、本実施形態におけるアクセスポイント１００の動作について説明する。図２０は、アクセスポイント１００による各端末２００へのパケット転送処理の流れを示したフローチャートである。また図２１は、アクセスポイント１００による、バッファ時間に基づく優先端末の決定処理の流れを示したフローチャートである。これら２つの処理は、並行して実行される。
【０１４１】
（パケット転送処理）
図２０に示すように、まず、アクセスポイント１００の受信部１０１は、配信サーバ３００から、配下のいずれかの端末２００宛の動画像データのパケットを受信する（ステップ２０１）。
【０１４２】
続いて、帯域制御モジュール１０６は、上記受信したデータを、自身が有するバッファに書き込む（ステップ２０２）。
【０１４３】
続いて帯域制御モジュール１０６は、後述する優先端末決定処理において各端末２００に割り当てられた帯域に応じて、上記バッファから各端末２００宛のデータを取り出す（ステップ２０３）。
【０１４４】
そして帯域制御モジュール１０６は、送信部１０３と協働して、上記取り出されたデータを、各端末２００に割り当てられた帯域に応じた速度で各端末２００へ送信する（ステップ２０４）。
【０１４５】
（優先端末決定処理）
図２１に示すように、帯域制御モジュール１０６は、各端末２００が動画像データのダウンロードを開始すると、各端末２００から定期的にバッファ時間情報を受信する（ステップ２１１）。
【０１４６】
続いて帯域制御モジュール１０６は、上記受信したバッファ時間情報を基に、上記バッファ時間データベース１０４を更新する（ステップ２１２）。
【０１４７】
続いて帯域制御モジュール１０６は、上記バッファ時間データベース１０４から、各バッファ時間情報の比較により、最短のバッファ時間を有する端末２００を検索する（ステップ２１３）。
【０１４８】
そして帯域制御モジュール１０６は、上記最短のバッファ時間を有する端末２００が、前回の検索時と異なる端末２００であるか否かを判断する（ステップ２１４）。
【０１４９】
上記最短のバッファ時間を有する端末２００が異なる端末２００である場合（Ｙｅｓ）、帯域制御モジュール１０６は、当該端末２００を新たな優先端末として決定し、当該優先端末及びその他の端末２００に割り当てられる帯域を新たに計算する。
【０１５０】
具体的には、帯域制御モジュール１０６は、非優先端末に対しては、それぞれの非優先端末が受信している動画像データのエンコードレートの５０％の帯域を割り当て、それによって空いた帯域を、優先端末に割り当てる。
【０１５１】
例えば、優先端末が受信している動画像データのエンコードレートが２Ｍｂｐｓで、２台の非優先端末が受信している動画像データのエンコードレートがそれぞれ４Ｍｂｐｓと１Ｍｂｐｓである場合を想定する。この場合、非優先端末に割り当てられる帯域は、それぞれ、４×１／２＝２Ｍｂｐｓと、１×１／２＝０．５Ｍｐｂｓとなる。したがって優先端末に割り当てられる帯域は、それが受信している動画像データのエンコードレート２Ｍｂｐｓに、上記各非優先端末への帯域の割り当てによって空いた２Ｍｂｐｓと０．５Ｍｐｂｓとを足して、４．５Ｍｂｐｓとなる。
【０１５２】
いずれかの端末２００が動画像データのダウンロードを開始してから最初に優先端末が決定される場合には、上記ステップ２１４から２１５の処理では、最短のバッファ時間を有する端末２００がそのまま優先端末として決定される。
【０１５３】
帯域制御モジュール１０６は、以上の処理を、各端末２００からバッファ時間情報を定期的に受信する度に実行する。
【０１５４】
以上の処理により、本実施形態では、アクセスポイント１００は、各端末２００のバッファ時間と各端末２００が受信している動画像データのエンコードレートに応じて、非優先端末へ割り当てられる帯域を狭く、優先機器へ割り当てられる帯域を広くするように設定可能である。そしてアクセスポイント１００は、当該設定された帯域に応じた速度で各端末２００へ動画像データを送信することで、各端末２００のバッファの逼迫度に応じて帯域を配分して、各端末２００において途切れない再生を実現させることができる。
【０１５５】
＜第４の実施形態＞
次に、本技術の第４の実施形態を説明する。
【０１５６】
上記第３の実施形態では、アクセスポイント１００が帯域制御モジュール１０６を有することで、バッファ時間及びエンコードレートに応じて各端末２００に帯域を動的に割り当てていた。本実施形態では、この動的な帯域制御を、アクセスポイント１００ではなく、複数の端末２００が相互に通信し合うことで実現している。
【０１５７】
［サーバ、アクセスポイント及び端末のモジュール構成］
図２２は、本実施形態における配信サーバ３００、アクセスポイント１００及び端末２００が有するソフトウェアモジュール及びデータベースの構成を示したブロック図である。
【０１５８】
同図に示すように、本実施形態では、上記第３の実施形態において図１８で示した図と比較して、アクセスポイント１００が有していた帯域制御モジュール１０６が廃され、それが単なるバッファ１０７に置換されている。
【０１５９】
一方その代わりに、それぞれの端末２００が、帯域制御モジュール２０５及びバッファ時間管理部２０４を有している。また、複数の端末２００のうち、優先度決定処理を担う端末（優先度決定端末）２００Ａは、バッファ時間データベース２０６を有している。
【０１６０】
優先度決定端末２００Ａのバッファ時間管理部２０４は、その他の端末２００Ｂのバッファ時間管理部２０４からバッファ時間情報を受信し、それを自身のバッファ時間情報と共にバッファ時間データベース２０６に登録する。
【０１６１】
また優先度決定端末２００Ａの帯域制御モジュール２０５は、上記第３の実施形態におけるアクセスポイント１００の帯域制御モジュール１０６と同様の手法により、各端末２００への割り当て帯域を決定し、それを他の端末２００Ｂへ通知する。
【０１６２】
上記通知を受けた端末２００Ｂの帯域制御モジュール２０５は、割り当てられた帯域に応じた速度で動画像データをダウンロードする。これにより結果的に上記第３の実施形態と同様の動的な帯域制御処理が実現される。
【０１６３】
［システムの動作］
次に、以上のように構成されたシステムにおける各端末２００Ａ及び２００Ｂの動作について説明する。
【０１６４】
図２３は、端末２００におけるパケット受信処理の流れを示したフローチャートである。また図２４は、端末２００における再生処理の流れを示したフローチャートである。また図２５は、端末２００におけるバッファ時間登録処理の流れを示したフローチャートである。また図２６は、端末２００における帯域変更処理の流れを示したフローチャートである。これらの処理は並行して実行される。
【０１６５】
（パケット受信処理）
図２３に示すように、端末２００におけるパケット受信処理の流れは、上記第１の実施形態において図８を用いて説明した処理の流れ（ステップ８１、８２）と同様であるため（ステップ２３１、２３２）、ここでは説明を省略する。
【０１６６】
（再生処理）
図２４に示すように、端末２００における再生処理の流れも、上記第１の実施形態において図９を用いて説明した処理の流れ（ステップ９１〜９４）と同様であるため（ステップ２４１〜２４４）、ここでは説明を省略する。
【０１６７】
（バッファ時間登録処理）
図２５に示すように、端末２００（非優先度決定端末２００Ｂ）におけるバッファ時間登録処理の流れも、上記第１の実施形態において図１０を用いて説明した処理の流れ（ステップ１０１〜１０５）と同様であるため（ステップ２５１〜２５５）、ここでは説明を省略する。優先度決定端末２００Ａは、他の端末２００Ｂからバッファ時間情報を受信すると共に、同様の計算手法で自らのバッファ２０２Ａのバッファ時間を算出し、それらをまとめてバッファ時間データベース２０６Ａに登録する。
【０１６８】
（優先端末決定処理）
図示しないが、優先度決定端末２００Ａの帯域制御モジュール２０５Ａは、上記第３の実施形態の図２１で示したのと同様の手法により、各端末２００Ｂから受信したバッファ時間情報を基に、優先端末を決定し、各端末２００へ割り当てる帯域を決定する。また帯域制御モジュール２０５Ａは、各端末２００Ｂに割り当てられた帯域を示す情報を各端末２００Ｂへ通知する。
【０１６９】
（帯域変更処理）
図２６に示すように、端末２００Ｂの帯域制御モジュール２０５Ｂは、優先度決定端末２００Ａから割り当て帯域（変更）の通知を受信する（ステップ２６１）。
【０１７０】
そして帯域制御モジュール２０５Ｂは、当該通知に含まれる、割り当てられた帯域に応じた速度で、配信サーバ３００からアクセスポイント１００を介して動画像データをダウンロードするべく、帯域設定を変更する（ステップ２６２）。この処理は、優先度決定端末２００Ａから帯域変更通知を受信するたびに繰り返される。
【０１７１】
以上の処理により、本実施形態では、優先度決定端末２００Ａは、アクセスポイント１００の処理によらずに、自ら無線ＬＡＮ１５０内の各端末２００が利用する帯域を割り当てることで、バッファ時間が少ない端末２００におけるバッファ量を増加させることができる。
【０１７２】
［変形例］
本技術は上述の実施形態にのみ限定されるものではなく、本技術の要旨を逸脱しない範囲内において種々変更され得る。
【０１７３】
上述の第１乃至第４の実施形態においては、各端末２００が動画像データをプログレッシブダウンロード方式で受信及び再生する例が示された。しかし、本技術で受信及び再生されるデータは動画像データに限られず、例えば音声データであっても構わない。
【０１７４】
上述の第１乃至第４の実施形態においては、配信サーバ３００はインターネット５０上に設けられたが、配信サーバ３００は、例えばＬＡＮ等の他のネットワーク上に設けられていても構わない。
【０１７５】
上述の第１乃至第４の実施形態においては、一般ユーザの家庭において端末２００が動画像データを受信及び再生する場合を想定して説明がなされた。しかし、本技術は、業務用のシステムにも適用され得る。例えば、放送局等で製作中の動画像コンテンツが、ある現場（サーバ）から他の現場（端末）へ送信されるようなシステムにも本技術は適用され得る。
【０１７６】
［その他］
本技術は以下のような構成も採ることができる。
（１）
サーバからプログレッシブダウンロード方式で送信されたデータをバッファリングして再生することが可能な同一ネットワーク上の複数のクライアント機器と通信可能な通信部と、
前記複数のクライアント機器でバッファリングされているデータの量を当該データの再生に必要な時間で表現したバッファ時間を示すバッファ時間情報を定期的に取得し、前記複数のクライアント機器のうち、最も短い前記バッファ時間を有するクライアント機器を、前記データを優先して送信すべき優先機器として決定することが可能な制御部と
を具備する情報処理装置。
（２）
上記（１）に記載の情報処理装置であって、
前記制御部は、前記サーバから送信された、前記複数のクライアント機器宛の前記データをそれぞれ受信し、前記優先機器宛の前記データを、前記優先機器以外のクライアント機器宛のデータよりも優先して前記優先機器へ送信するように前記通信部を制御可能である
情報処理装置。
（３）
上記（１）または（２）に記載の情報処理装置であって、
前記制御部は、
前記複数のクライアント装置から、前記バッファ時間情報をそれぞれ受信するように前記通信部を制御可能であり、
前記受信されたバッファ時間情報を比較することで前記優先機器を決定可能である
情報処理装置。
（４）
上記（１）または（２）に記載の情報処理装置であって、
前記制御部は、
前記サーバから、前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように前記通信部を制御可能であり、
前記エンコードレート情報と、前記複数のクライアント機器へ送信したデータのデータ量と、当該送信を開始してから現在までの経過時間とを基に、前記複数のクライアント機器の前記バッファ時間情報を算出可能である
情報処理装置。
（５）
上記（３）に記載の情報処理装置であって、
前記制御部は、
前記サーバから、前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信するように前記通信部を制御可能であり、
前記エンコードレート情報に応じて、前記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、前記優先機器に割り当てられる帯域を広くするように設定することが可能であり、
前記設定された帯域に対応する速度で前記データを前記複数のクライアント機器へ送信するように前記通信部を制御可能である
情報処理装置。
（６）
上記（１）に記載の情報処理装置であって、
前記サーバから送信されたデータをバッファリングして再生することが可能な再生部をさらに具備し、
前記制御部は、
前記サーバから、当該情報処理装置宛及び前記複数のクライアント機器宛に送信された前記データのエンコードレートをそれぞれ示すエンコードレート情報を受信し、複数のクライアント機器から前記バッファ時間情報をそれぞれ受信するように前記通信部を制御可能であり、
前記受信されたバッファ時間情報を比較することで前記優先機器を決定可能であり、
前記エンコードレート情報に応じて、前記優先機器以外のクライアント機器に割り当てられる帯域を狭くするように設定し、前記優先機器に割り当てられる帯域を広くするように設定することが可能であり、
前記優先機器及び当該優先機器以外のクライアント機器へ、前記割り当てられた帯域を示す帯域情報を送信するように前記通信部を制御可能である
情報処理装置。
【符号の説明】
【０１７７】
１１、２１…ＣＰＵ
１９、２９…通信部
２０…端末
５０…インターネット
１００…アクセスポイント
１０１…受信部
１０２…優先制御フラグ設定モジュール
１０３…送信部
１０４…バッファ時間データベース
１０５…バッファ時間管理部
１０６…帯域制御モジュール
１０７…バッファ
１５０…無線ＬＡＮ
２００（２００Ａ，２００Ｂ）…端末
２０１…受信部
２０２（２０２Ａ，２０２Ｂ）…バッファ
２０３（２０３Ａ，２０３Ｂ）…デコーダ
２０４（２０４Ａ，２０４Ｂ）…バッファ時間管理部
２０５（２０５Ａ，２０５Ｂ）…帯域制御モジュール
２０６（２０６Ａ，２０６Ｂ）…バッファ時間データベース
３００（３００Ａ，３００Ｂ）…配信サーバ
３０１…送信部
３０２…ビットレート通知部
【図１】
2014093655.tif 000004
【図２】
2014093655.tif 000005
【図３】
2014093655.tif 000006
【図４】
2014093655.tif 000007
【図５】
2014093655.tif 000008
【図６】
2014093655.tif 000009
【図７】
2014093655.tif 000010
【図８】
2014093655.tif 000011
【図９】
2014093655.tif 000012
【図１０】
2014093655.tif 000013
【図１１】
2014093655.tif 000014
【図１２】
2014093655.tif 000015
【図１３】
2014093655.tif 000016
【図１４】
2014093655.tif 000017
【図１５】
2014093655.tif 000018
【図１６】
2014093655.tif 000019
【図１７】
2014093655.tif 000020
【図１８】
2014093655.tif 000021
【図１９】
2014093655.tif 000022
【図２０】
2014093655.tif 000023
【図２１】
2014093655.tif 000024
【図２２】
2014093655.tif 000025
【図２３】
2014093655.tif 000026
【図２４】
2014093655.tif 000027
【図２５】
2014093655.tif 000028
【図２６】
2014093655.tif 000029