JP2017175334A - コンテンツ配信制御装置，そのコンテンツ配信制御方法，及びプログラム - Google Patents

Abstract

【課題】配信先毎に異なる再生位置で再生可能なコンテンツの配信において、コンテンツ配信に用いる帯域を削減可能とする。【解決手段】配信先毎に異なる再生位置で再生可能なコンテンツの複数の配信先への配信を制御するコンテンツ配信制御装置は、複数の配信先のそれぞれから得られる、コンテンツの再生位置と再生位置からの所定期間を示す情報とに基づいて、複数の配信先をグルーピングするグルーピング部と、複数の配信先へのコンテンツの配信に使用される網の使用状況に基づいて、グルーピングにより形成されたグループに対するコンテンツの配信方法を判定する判定部とを含む。【選択図】図１１

Description

本発明は、コンテンツ配信制御装置，そのコンテンツ配信制御方法，及びプログラムに関する。

近年、無線ＬＡＮ（Local Area Network）インタフェースを備える端末が広く使用されている。端末は、例えば、ラップトップのＰＣ（Personal Computer），スマートフォン
，タブレットＰＣなどを含む。

また、近年では、「セカンドスクリーン」と呼ばれるコンテンツ配信サービスが広まりつつある。セカンドスクリーンでは、スポーツスタジアムなどに設置された無線ＬＡＮ設備を用いて、端末を所持するユーザ（観戦者）に対し、カメラで撮影された画像や映像のコンテンツ（例えば、試合のダイジェスト動画やリプレイ動画など）を配信する。例えば、野球やバスケットボールのスタジアムにおいて、ユーザが所持するスマートフォンへ、試合の詳細情報やリプレイ動画等が配信される。

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

コンテンツ配信サービスで配信されるコンテンツ、例えば端末で再生される動画の再生開始タイミングや再生位置は、端末ごとに異なる。一方、スタジアムでスポーツの試合が行われている環境では、得点直後、休憩時間の開始直後など、特定のタイミングでユーザが一定時間内に一斉にコンテンツを取得し始めることが多い。このような無線網に対する一斉のアクセス時に輻輳が起こりやすい。

輻輳によって端末へのコンテンツ配信が遅延し、動画の再生中断などが生じると、ユーザが主観的に知覚・認知するユーザ体感品質（Quality of Experience：ＱｏＥ）が低下
するという問題が生じる。

本発明は、配信先毎に異なる再生位置で再生可能なコンテンツの配信において、コンテンツ配信に用いる帯域を削減可能とすることができるコンテンツ配信制御装置，そのコンテンツ配信制御方法，及びプログラムを提供することを目的とする。

一つの態様では、コンテンツ配信制御装置は、配信先毎に異なる再生位置で再生可能なコンテンツの複数の配信先のそれぞれから得られる、コンテンツの再生位置と再生位置からの所定期間を示す情報とに基づいて、複数の配信先をグルーピングするグルーピング部と、複数の配信先へのコンテンツの配信に使用される網の使用状況に基づいて、グルーピングにより形成されたグループに対するコンテンツの配信方法を判定する判定部とを含む。

一側面では、配信先毎に異なる再生位置で再生可能なコンテンツの配信において、コンテンツ配信に用いる帯域を削減可能とすることができる。

図１は、コンテンツ配信システムの構成例を模式的に示す。 図２は、ゲートウェイ及び端末のハードウェア構成例を示す図である。 図３は、ゲートウェイ及び端末の構成例を示す。 図４は、コンテンツバッファ管理テーブルのデータ構造例を示す。 図５は、アプリ実行状況管理テーブルのデータ構造例を示す。 図６は、コンテンツ配信状況管理テーブルのデータ構造例を示す。 図７は、処理１（アプリに対してコンテンツのフラグメントを提供する処理）の例を示すフローチャートである。 図８Ａは、処理２（アプリが要求するコンテンツのフラグメントを端末に配信する処理）の例を示すフローチャートであり、ゲートウェイにおける処理を示す。 図８Ｂは、処理２（アプリが要求するコンテンツのフラグメントを端末に配信する処理）の例を示すフローチャートであり、端末における処理を示す。 図９は、端末のグルーピング処理の例を示すフローチャートである。 図１０は、グルーピングの基本概念の説明図である。 図１１は、グルーピングの例の説明図である。 図１２は、第２実施形態におけるゲートウェイ及び端末の構成例を示す。 図１３は、第２実施形態におけるアプリ実行状況管理テーブル３０９Ｂのデータ構造例を示す。 図１４は、第２実施形態における端末５のグルーピング方法の説明図である。 図１５Ａは、第２実施形態における端末のグルーピング処理の例を示すフローチャートである。 図１５Ｂは、第２実施形態における端末のグルーピング処理の例を示すフローチャートである。 図１６は、第２実施形態におけるグルーピング方法の説明図である。 図１７は、第２実施形態における“処理１”の例を示すフローチャートである。 図１８Ａは、第２実施形態における“処理２”の例を示すフローチャートである。 図１８Ｂは、第２実施形態における“処理２”の例を示すフローチャートである。

以下、図面を参照して、コンテンツ配信制御装置、コンテンツ配信制御方法及びプログラムの実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。

〔第１実施形態〕
＜システム構成＞
図１は、コンテンツ配信システムの構成例を模式的に示す。図１において、コンテンツ配信システムは、コンテンツサーバ１と、コンテンツサーバ１と有線網２を介して接続されるゲートウェイ３と、ゲートウェイ３と無線網４を介して接続される複数の端末５とを含む。但し、図１には、１つの端末５を例示している。端末５は、プロキシサーバ（プロキシ）６と、動画再生アプリケーション（動画再生アプリ）７とを含む。ゲートウェイ３は、「コンテンツ配信制御装置」の一例である。複数の端末５は、「複数の配信先」の一
例である。無線網４は、「コンテンツの配信に使用される網」の一例である。

第１実施形態では、説明を簡単にするため、無線ＬＡＮのアクセスポイント（ＡＰ）とゲートウェイ装置とが一体化されたゲートウェイ３を例示する。但し、システムは、一体型のゲートウェイ３の代わりに、ゲートウェイとＡＰとが分離されている構成を採用することもできる。このとき、１つのゲートウェイに対して、複数のＡＰが接続された構成を採用することもできる。例えば、１つのゲートウェイと複数のＡＰが適用される場合、端末５は、複数のＡＰのいずれかを経由してゲートウェイ装置と通信する。ゲートウェイは、ＡＰ単位で後述する処理を行う。ゲートウェイとＡＰが分離された構成が採用される場合、端末５からゲートウェイに対して、端末５が接続しているＡＰのＢＳＳＩＤ（Basic Service Set Identifier：ＡＰのＭＡＣ（Media Access Control）アドレス）が送信される。ＢＳＳＩＤ（ＡＰの識別子）は、ゲートウェイにおいて、端末５とＡＰとの紐づけに使用される。

第１実施形態では、コンテンツ配信サービスの一例として、動画配信サービスについて説明する。コンテンツは、動画（ビデオ）、音声を含む。動画配信サービスは、動画コンテンツを複数の細かいフラグメントに分割する。フラグメントは、ゲートウェイ３を介して端末５に配信される。端末５は、再生順でフラグメントを受信し、再生処理を行う。動画配信サービスを実現する動画配信機構としては、例えば、ＨＬＳ（Http Live Streaming）やMPEG-DASH（Dynamic Adaptive Streaming over HTTP）が挙げられる。但し、これら以外の動画配信機構を適用し得る。

ＨＬＳやMPEG-DASHなどの動画配信サービスでは，動画コンテンツの各フラグメントの
ＵＲＬ（Uniform Resource Locator）と、フラグメントの再生順序や再生オプションとが、“プレイリスト”と呼ばれるファイルに予め定義される。

動画再生アプリ７は、プレイリストを取得し、プレイリストに定義された再生順に従って、プロキシ６で受信されたフラグメントを取得し、動画の再生を行う。このとき、或るフラグメントを用いた再生中に次のフラグメントが入手される状況が継続する限り、動画の再生が滞りなく（継続して）行われる。すなわち、コンテンツの再生位置からの所定期間内に次のフラグメントが配信される場合、配信先はコンテンツの再生を中断や停止なく継続することができる。

第１実施形態に係る処理は、大略して、以下の処理１と処理２とに分けることができる。処理１は、動画再生アプリ７に動画コンテンツのフラグメントを提供する処理である。処理２は、動画再生アプリ７が要求する動画コンテンツのフラグメントを端末５に配信する処理である。

処理１は、プロキシ６が、動画再生アプリ７のフラグメントの取得リクエストに応じて、同期的に実行する。処理２は，動画再生アプリ７からのリクエストを契機として発生する処理であり、処理１とは非同期に行われる。処理１において、プロキシ６は、処理２によるフラグメントの端末５への配信を待ち合わせて，動画再生アプリ７に対し、リクエストに応じたフラグメントを提供する。

＜端末及びゲートウェイの構成＞
図２は、端末及びゲートウェイのハードウェア構成例を示す図である。図２において、ゲートウェイ３（ＡＰを含む）は、バスを介して相互に接続された、Central Processing
Unit（ＣＰＵ）３１と、主記憶装置３２と、補助記憶装置３３と、無線通信回路３４と
、通信インタフェース（通信ＩＦ）３５とを含む。通信ＩＦ３５は、有線網２を介してコンテンツサーバ１に接続されている。

端末５は、バスを介して相互に接続された、ＣＰＵ５１と、主記憶装置５２と、補助記憶装置５３と、無線通信回路５４と、アンテナ（図示せず）を含む。端末５とゲートウェイ３とは、無線網４を介して無線通信を行う。端末５は、例えば、無線通信機能を有する携帯型の端末である。但し、端末５はこのような端末に限られず、通信ＩＦを有し有線で通信するもの、固定配置されるものを含み得る。第１実施形態では、無線機能を有する携帯型の端末５が一例として示されている。

ここで、コンテンツサーバ１について説明する。コンテンツサーバ１は、図示を省略するが、バスを介して相互接続されたＣＰＵ，主記憶装置，補助記憶装置，通信インタフェースを備える。補助記憶装置には、映像，画像，音楽のコンテンツデータが記憶されている。コンテンツデータとして、オリジナルの映像，画像，音楽に関して、画像サイズ、送信ビットレートなどの異なる複数のコンテンツデータが記憶されている。ＣＰＵは、補助記憶装置や主記憶装置に記憶されているプログラムを主記憶装置にロードして実行する。これによって、ＣＰＵは、端末５からの要求に応じたコンテンツデータを補助記憶装置から読み出し、通信ＩＦを用いて端末５へ送信する処理（制御）を行う。

コンテンツサーバ１として使用される情報処理装置（コンピュータ）は、例えば、パーソナルコンピュータ（ＰＣ），ワークステーション（ＷＳ）のような汎用コンピュータを適用できる。或いは、サーバマシンのような専用のコンピュータを適用することもできる。但し、上述したＰＣ，ＷＳ，サーバマシン以外のコンピュータを用いる場合もある。

主記憶装置（例えば、主記憶装置３２，主記憶装置５２，コンテンツサーバ１に含まれた主記憶装置）は、プログラムの展開領域，ＣＰＵ（例えば、ＣＰＵ３１、ＣＰＵ５１、コンテンツサーバ１に含まれたＣＰＵ）の作業領域，データやプログラムの記憶領域又はバッファ領域として使用される。主記憶装置は、例えばRandom Access Memory（ＲＡＭ），或いはＲＡＭとRead Only Memory（ＲＯＭ）との組み合わせで形成される。

補助記憶装置（例えば、補助記憶装置３３，補助記憶装置５３，コンテンツサーバ１に含まれた補助記憶装置）は、データやプログラムの記憶領域として使用される。補助記憶装置は、例えば、ハードディスクドライブ（ＨＤＤ），Solid State Drive（ＳＳＤ），
フラッシュメモリ，Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲ
ＯＭ）などの不揮発性記憶媒体で形成される。補助記憶装置には、ディスク型記憶媒体や、ＵＳＢメモリなど、可搬性を有する記録媒体を含むことができる。主記憶装置及び補助記憶装置は、「記憶装置」，「記憶媒体」，「メモリ」，「記憶部」の一例である。

無線通信回路（例えば。無線通信回路３４，無線通信回路５４）は、ベースバンド回路（ＢＢ回路）と、Radio Frequency（ＲＦ）回路とを含む。ＢＢ回路は、データ（ディジ
タル）信号とベースバンド信号（ＢＢ信号）との間の変換処理を行う。ＲＦ回路は、ＢＢ信号と無線信号との間の変換処理を行う。無線信号はアンテナ（図示せず）によって送受信される。

通信ＩＦ（例えば、通信ＩＦ３５，コンテンツサーバ１に含まれた通信ＩＦ）は、パケットの送受信処理等を行う通信インタフェース回路である。通信ＩＦとして、例えば、ＬＡＮカード或いはネットワークインタフェースカードと呼ばれるネットワークカードを適用できる。

ＣＰＵ（例えば、ＣＰＵ３１，ＣＰＵ５１，コンテンツサーバ１に含まれたＣＰＵ）は、主記憶装置及び補助記憶装置の少なくとも一方に記憶されたプログラムを主記憶装置にロードして実行する。ＣＰＵ３１がプログラムを実行することによって、ゲートウェイ３
としての動作乃至処理が行われる。ＣＰＵ５１がプログラムを実行することによって、端末５としての動作乃至処理が行われる。ＣＰＵは、「制御装置」，「制御部」，「コントローラ」，「プロセッサ」の一例である。

ＣＰＵは、ＭＰＵ（Microprocessor）、プロセッサとも呼ばれる。ＣＰＵは、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。ＣＰＵで行われる処理の少なくとも一部は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor(DSP)、Graphics Processing Unit（GPU）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。

また、ＣＰＵで行われる処理の少なくとも一部は、集積回路（ＩＣ）、その他のディジタル回路で行われても良い。また、集積回路やディジタル回路はアナログ回路を含んでいても良い。集積回路は、ＬＳＩ，Application Specific Integrated Circuit（ASIC），
プログラマブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(FPGA)を含む。ＣＰＵで行われる処理の少なくとも一部は、プロセッサ
と集積回路との組み合わせにより実行されても良い。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ），ＳｏＣ（System-on-a-chip），システムＬＳＩ，チップセットなどと呼ばれる。

図３は、ゲートウェイ３及び端末５の機能を模式的に示す。図３において、ゲートウェイのＣＰＵ３１は、プログラム実行によって、リクエスト受信部３０７，リクエスト送信部３０８，アプリ実行状況管理部３０９，ネットワーク状況管理部３１０として動作する。また、ゲートウェイのＣＰＵ３１は、プログラム実行によって、コンテンツ受信部３１１，端末グループ決定部３１２，コンテンツ配信状況管理部３１３，コンテンツ配信部３１４として動作する。ＣＰＵ３１は、リクエストやコンテンツの送受信に、通信ＩＦ３５や無線通信回路３４を用いる。端末グループ決定部３１２（ＣＰＵ３１）は，「グルーピング部」，「判定部」，第２実施形態に係る「設定部」の一例である。

端末５のＣＰＵ５１は、プログラムの実行によって、端末５を、プロキシ６と動画再生アプリ７とを含む装置として動作させる。ＣＰＵ５１は、プログラムの実行によって、プロキシ６に含まれるリクエスト受信部５０１，アプリ実行状況検出部５０２，リクエスト送信部５０３，コンテンツ受信部５０４，コンテンツバッファ５０５，コンテンツ配信部５０６として動作する。

前提として、動画再生アプリ７は、コンテンツサーバ１に対して、プレイリストの提供のリクエストを送り、コンテンツサーバ１は、動画再生アプリにプレイリストを送信する。プロキシ６は、リクエストとレスポンス（プレイリスト）の中継処理を行う。

端末５のリクエスト受信部５０１は、動画再生アプリ７から、動画取得リクエストを受信する。アプリ実行状況検出部５０２は、動画コンテンツの再生位置（コンテンツの再生時間軸上の位置）と配信遅延許容時間を検出する。配信遅延許容時間は、動画再生アプリ７内にキャッシュされているコンテンツの上記再生時間軸上の時間である。配信遅延許容時間は、コンテンツの端末への配信が遅延しても，動画再生が滞らない（停止乃至中断しない）最大の時間を意味する。

動画コンテンツの再生位置と配信遅延許容時間は、例えば、動画再生アプリ７が動画コンテンツのフラグメントを取得するリクエストのヘッダに含まれる。但し、動画再生アプリ７のリクエスト送信の挙動から推定したり，プレイリストの内容から計算したりしても良い。

端末５のリクエスト送信部５０３は、動画再生アプリ７からのリクエストを、ゲートウェイ３に送信する。このとき、リクエスト送信部５０３は、端末５の識別子として，端末のＭＡＣアドレスをリクエストのヘッダに付与する。

端末５のコンテンツ受信部５０４は、ゲートウェイ３からのユニキャスト配信またはマルチキャスト配信によって無線網４を介して転送されるコンテンツフラグメントを受信する。

コンテンツバッファ５０５は、ゲートウェイ３から受信したコンテンツフラグメントを一時的に記憶する。図１を用いて説明した“処理１”と“処理２”とが非同期的に実行されるので、端末５のプロキシ６において，コンテンツフラグメントの待ち合わせを行う。特に、ゲートウェイ３からマルチキャストでコンテンツフラグメントが端末５に配信される場合では、以下の可能性がある。すなわち、動画再生アプリ７が実際にコンテンツサーバ１にリクエストを送信する前に、同じグループに所属する端末５からのリクエストに従って、コンテンツフラグメントが配信される可能性がある。

このため，実際に動画再生アプリ７からリクエストが発生するまで，コンテンツフラグメントがリクエストのＵＲＬ（Uniform Resource Locator）と関連付けて記憶され、動画再生アプリ７にコンテンツフラグメントを提供できるようにしておく。

図４は、コンテンツバッファ管理テーブル５０５Ａのデータ構造例を示す。コンテンツバッファ管理テーブル５０５Ａは、コンテンツフラグメントのＩＤと、ローカルファイルのパス（コンテンツフラグメントの記憶位置）とを対応づけて記憶する。コンテンツバッファ５０５及びコンテンツバッファ管理テーブル５０５Ａは、ＣＰＵ５１によって生成され、主記憶装置５２及び補助記憶装置５３の少なくとも一方に記憶される。端末５のコンテンツ配信部５０６は、所定のタイミングでコンテンツフラグメントをコンテンツバッファ５０５から読み出して動画再生アプリ７に転送する。

ゲートウェイ３のリクエスト受信部３０７は、端末５からのリクエストを受信し，リクエストに含まれるアプリ実行状況情報，端末ＩＤ（端末５の識別子），取得対象のコンテンツフラグメントのＵＲＬを抽出し、アプリ実行状況管理部３０９に渡す。ゲートウェイ３のリクエスト送信部３０８は、端末５からのリクエストを，コンテンツサーバ１に送信する。

アプリ実行状況管理部３０９は、端末５毎の動画コンテンツの再生状況を管理する。図５は、アプリ実行状況管理テーブル３０９Ａのデータ構造例を示す。アプリ実行状況管理部３０９によってアプリ実行状況管理テーブル３０９Ａは管理される。アプリ実行状況管理テーブル３０９Ａは、端末５毎に形成されたレコード（エントリ）の集合である。レコードは、端末ＩＤと、コンテンツＩＤと、コンテンツの再生位置と、配信遅延許容時間とを含む。アプリ実行状況管理テーブル３０９Ａは、ＣＰＵ３１によって生成され、主記憶装置３２及び補助記憶装置３３の少なくとも一方に記憶される。端末ＩＤは、端末５のＭＡＣアドレスを適用することができる。但し、ＭＡＣアドレス以外の識別子で管理されても良い。また、ＭＡＣアドレスと，ＭＡＣアドレス以外の識別子の双方で管理されても良い。

アプリ実行状況管理部３０９は、プレイリストに含まれるコンテンツフラグメントの取得要求（リクエスト）を受信する度に、アプリ実行状況管理テーブル３０９Ａの該当するレコードを更新する。レコードは、例えば，最初にレコードが追加されてから所定期間（1日など）が経過した場合に削除される。経過時間のチェック及び削除は、定期的に又は
非定期に実行できる。また、レコードは、プレイリストに記載されている最後のコンテンツフラグメントが取得された時点で削除しても良い。

ネットワーク状況管理部３１０は、無線帯域（無線網４）の使用状況（ユニキャストとマルチキャストとのそれぞれ）を管理する。ゲートウェイ３のように、ゲートウェイがＡＰとの一体型である場合には、ＡＰの機能として，使用帯域情報を取得可能である。但し、コンテンツ配信部３１４による実際のデータ転送量と転送時間から無線帯域の使用状況（使用帯域）を算出しても良い。ゲートウェイとＡＰとが分離されている場合には、ＡＰの外部ＡＰＩ（Application Programming Interface）や、ゲートウェイ３と通信可能な
無線ネットワーク装置の管理システム（無線帯域の使用状況を管理している）から取得しても良い。

コンテンツ受信部３１１は、コンテンツサーバ１からコンテンツフラグメントを受信する。端末グループ決定部３１２は、端末５のアプリ実行状況と，無線網４の使用状況とから、グループ化する端末（各端末が属するグループ）、コンテンツフラグメントの配信方式（マルチキャストかユニキャストか）を決定する。

コンテンツ配信状況管理部３１３は、端末５毎に，端末５へ送信したコンテンツフラグメントのＩＤ（識別子）を管理する。マルチキャスト配信は、或る端末５と同じグループに属し、且つ再生位置が或る端末５より先行する或る端末５以外の端末５からのリクエストによって発生する場合がある。この場合に，同一のコンテンツフラグメントの重複配信を回避するために、各コンテンツフラグメントの配信先の端末５を示す情報を管理する。

図６は、コンテンツ配信状況管理部３１３によって管理される、コンテンツ配信状況管理テーブル３０３Ａのデータ構造例を示す。コンテンツ配信状況管理テーブル３０３Ａは、各端末５に対応するレコードを含む。レコードは、端末ＩＤと、コンテンツフラグメントＩＤと、配信時刻とを含む。レコードの削除は、例えば、定期的に実行される。但し、削除要求に応じてレコードが削除されるようにしても良い。コンテンツ配信状況管理テーブル３０３Ａは、ＣＰＵ３１によって生成され、主記憶装置３２及び補助記憶装置３３の少なくとも一方に記憶される。

コンテンツ配信部３１４は、端末グループ決定部３１２によって決定された配信方法（ゆにキャスト又はマルチキャスト）に従って，コンテンツフラグメントを端末５に配信する。配信の際に、コンテンツ配信部３１４は、コンテンツ配信状況管理部３１３が管理する配信状況（コンテンツ配信状況管理テーブル３０３Ａ）を参照して，同一のコンテンツの配信を回避する。

＜“処理１”のフロー＞
図７は、処理１（アプリに対してコンテンツフラグメントを提供する処理）の例を示すフローチャートである。図７の処理は、動画再生アプリ７，プロキシ６として動作するＣＰＵ３１によって実行される。

図７において、動画再生アプリ７は（以下「アプリ７」とも表記）、コンテンツフラグメント（以下単に「フラグメント」とも表記）の取得リクエスト（以下「リクエスト」とも表記）をプロキシ６に送信する（０１）。

プロキシ６において、リクエスト受信部５０１は、アプリ７からのリクエストを受信すると（０２）、アプリ実行状況検出部５０２を用いて、アプリ７の実行状況（再生位置，配信遅延許容時間）を検出する（０３）。

０４において、リクエスト受信部５０１は、アプリ７の実行状況，端末ＩＤ及びコンテンツＩＤをリクエストのヘッダに付与する。リクエスト送信部５０３は、リクエストをゲートウェイ３（以下「ＧＷ３」とも表記）へ送信する。リクエストはＧＷ３のリクエスト受信部３０７で受信される。

０５の処理において、リクエスト受信部５０１は、リクエストに係る（要求された）フラグメントのＵＲＬに対応するフラグメントがコンテンツバッファ５０５にバッファ済か否かを確認し、バッファ済かバッファ済みでないかを判定する（０６）。

０６においてバッファ済でないと判定される場合には（０６，Ｎｏ）、リクエスト受信部５０１は、経過時間が閾値を超過するか否かを判定する。閾値を超過しないと判定される場合には（０７，Ｎｏ）、一定時間待機の後、処理が０５に戻される。これに対し、所定時間が閾値を超過すると判定される場合には（０７，Ｙｅｓ）、処理が０９に進む。０９の処理では、エラー（タイムアウト）がリクエストの応答としてアプリ７に返却される。

一方、０６において、バッファ済であると判定される場合には（０６，Ｙｅｓ）、コンテンツ配信部５０６は、該当のフラグメントをコンテンツバッファ５０５から取得し（１０）、アプリ７に送る（１１）。

アプリ７は、フラグメントを取得し、アプリ７内でバッファリングする。バッファリングされたフラグメントは、コンテンツの再生処理に使用される。なお、０９でプロキシからエラーが通知された場合には、アプリ７は、所定のエラー処理を行う（１３）。１２又は１３の処理の終了後、図７の処理が終了する。

＜“処理２”のフロー＞
図８Ａ及び図８Ｂは、処理２（アプリが要求するコンテンツのフラグメントを端末に配信する処理）の例を示すフローチャートである。図８Ａは、ゲートウェイ３における処理を示し、図８Ｂは、端末５における処理を示す。ゲートウェイ３における処理は、ＣＰＵ３１によって行われ、端末５における処理は、ＣＰＵ５１によって行われる。

図８Ａにおいて、リクエスト受信部３０７は、リクエスト送信部５０３からリクエストを受信する（００１）。リクエスト受信部３０７は、リクエストから、アプリの実行状況，端末ＩＤ，コンテンツＩＤを抽出し、アプリ実行状況管理部３０９に渡す。アプリ実行状況管理部３０９は、アプリ実行状況管理テーブル３０９Ａ（図５）を更新する（００２）。

００３では、リクエスト送信部３０８が、リクエスト中のＵＲＬに従って，所定のコンテンツサーバ１に，リクエストを転送する。コンテンツサーバ１は、リクエストに対応するコンテンツのフラグメントを送信し、コンテンツ受信部３１１がフラグメントを受信する。

００４では、端末グループ決定部３１２が各端末５のアプリ実行状況と、無線網４の使用状況とを参照して，端末のグルーピングを行う（この処理の詳細は後述する）。

００５では、コンテンツ配信部３１４が、グルーピングの結果に基づき、リクエストの送信元端末への配信方式がユニキャストかマルチキャストかを判定する。このとき、配信方式がユニキャストであると判定される場合には（００５，Ｙｅｓ）、処理が０１０に進む。これに対し、配信方式がマルチキャストであると判定される場合には（００５，Ｎｏ）、処理が００６に進む。

００６では、コンテンツ配信状況管理部３１３（管理部３１３）が、リクエストの送信元端末が属するグループに，フラグメントをマルチキャストで送信済みか否かを確認する。確認は、コンテンツ配信状況管理テーブル３０３Ａを参照することで行われる。

００７では、コンテンツ配信部３１４が、管理部３１３の確認結果に基づき送信済であるか否かを判定する。送信済であると判定される場合には（００７，Ｙｅｓ）、図８Ａの処理が終了する。これに対し、送信済でないと判定される場合には（００７，Ｎｏ）、処理が００８に進む。

００８では、コンテンツ配信部３１４は、ＵＲＬとグループに属する端末ＩＤのリストとともに、フラグメントをマルチキャストで配信する。００９では、コンテンツ配信状況管理部３１３が、配信に応じて、コンテンツ配信状況管理テーブル３０３Ａを更新する。

０１０に処理が進んだ場合には、コンテンツ配信部３１４は、ＵＲＬとグループに属する端末ＩＤのリストとともに、フラグメントをユニキャストで配信する。その後、処理が００９に進む。

端末５では、０１１において、コンテンツ受信部５０４が、ユニキャストで配信されたフラグメントを受信し、処理を０１４に進める。０１２では、コンテンツ受信部５０４が、マルチキャストで配信されたフラグメントを受信し、処理を０１３に進める。

０１３では、コンテンツ受信部５０４が、端末ＩＤリストに自端末の端末ＩＤが含まれるか否か（端末５が参加しているマルチキャストグループのパケット（フラグメント）か）を判定する。端末ＩＤが含まれていないと判定される場合には（０１３，Ｎｏ）、図８Ｂの処理が終了する（フラグメントは保存されない）。端末ＩＤが含まれていると判定される場合には（０１３，Ｙｅｓ）、処理が０１４に進む。

０１４では、フラグメントがコンテンツバッファ５０５に保存（記憶）される。また、コンテンツバッファ管理テーブル５０５Ａ（図４）が更新される。フラグメントとＵＲＬとが関連づけられる。その後、図８Ｂの処理が終了する。

なお、図８Ｂの破線矩形で囲まれた処理は、コンテンツフラグメント取得リクエストの発生とは無関係に、マルチキャストで配信されたパケット（フラグメント）が受信された場合に実行されることがある。

なお，マルチキャスト配信の場合，他の端末５からの，同じコンテンツフラグメントについてのリクエストの発生タイミング次第で，端末５へのコンテンツフラグメントの配信が行われない場合があり得る。逆に、リクエストを送信しなくても，コンテンツフラグメントの配信が発生する場合もあり得る。

＜端末のグルーピング処理＞
図９は、端末のグルーピング処理の例を示すフローチャートである。図９に示す処理は、端末グループ決定部３１２（決定部３１２）として動作するＣＰＵ３１によって行われる。０２１の処理では、決定部３１２は、全ての端末５がユニキャスト配信した場合の使用帯域を計算する。

０２２の処理では、決定部３１２は、使用帯域がＡＰの許容帯域の上限以上か否かを判定する。使用帯域がＡＰの許容帯域の上限以上と判定される場合には（０２２，Ｙｅｓ）、処理が０２３に進む。これに対し、使用帯域がＡＰの許容帯域の上限未満と判定される
場合には（０２２，Ｎｏ）、処理が０３１に進む。

０２３の処理では、決定部３１２は、各端末５の再生位置と配信遅延許容時間とを参照し，マルチキャスト可能な端末グループを決定する（各グループとも「未選択」に設定する）。なお、０２３において、或るグループの部分集合となるグループは除外される。また、端末５からの電波強度から、端末毎の伝送レートを判定し、レートが大きくなる場合には、コンテンツの再生位置が近くてもグルーピングしない構成を採用可能である。

０２４の処理では、０２３で決定されたグループが存在するか否かを判定する。グループが存在しないと判定される場合には（０２４，Ｎｏ）、処理が０３１に進む。グループが存在すると判定される場合には（０２４，Ｙｅｓ）、処理が０２５に進む。

０２５の処理では、決定部３１２は、各グループの使用帯域と、マルチキャスト配信への変更による使用帯域の削減量を計算する。０２６では、決定部３１２は、未選択グループがあるか否かを判定する。未選択グループがない場合には（０２６，Ｙｅｓ）、処理が０３３に進み、未選択グループがある場合には（０２６，Ｎｏ）、処理が０２７に進む。

０２７では，決定部３１２は、未選択グループのうち、使用帯域の削減量が一番多いグループの使用帯域を参照する。０２８では、決定部３１２は、グループの使用帯域がマルチキャスト用の帯域を超過するか否かを判定する。グループの使用帯域がマルチキャスト用帯域を超過すると判定される場合には（０２８，Ｙｅｓ）、処理が０３３に進む。これに対し、グループの使用帯域がマルチキャスト用帯域以下と判定される場合には（０２８，Ｎｏ）、処理が０２９に進む。

０２９の処理では、決定部３１２は、使用帯域の削減量の一番多いグループを、マルチキャスト配信が適用されるグループとして選択する。０３０の処理では、決定部３１２は、これまでに選択されたグループが全端末をカバーしているか否かを判定する。すなわち、全ての端末５が、マルチキャストが選択されたグループのいずれかに属しているかが判定される。全ての端末がカバーされる場合には（０３０，Ｙｅｓ）、処理が０３２に進み、そうでない場合には（０３０，Ｎｏ）、０２９で選択されたグループが「選択済」に設定され（「未選択」が解除され）処理が０２６に戻る。０２６では、０２９で選択されたグループ以外の未選択のグループについて、０２７〜０３０の処理が行われる。

０３１に処理が進んだ場合には、決定部３１２は、全ての端末５に対する配信方式をユニキャストにすることを決定する。０３２に処理が進んだ場合には、決定部３１２は、選択されたグループに属する端末５（全端末）に対する配信方式をマルチキャストにすることを決定する。０３３に処理が進んだ場合には、決定部３１２は、現状で選択された（選択済の）グループの配信方式をマルチキャストに設定する。一方、選択されたグループに属しない残りの端末５に対する配信方式をユニキャストに設定することを決定する。

図１０及び図１１は、グルーピングの説明図である。図１０は、どのような場合にグルーピング可能か、グルーピング不可能かという基本的な考え方を説明する。例えば、同一のコンテンツを再生中の端末ｔ１，端末ｔ２，及び端末ｔ３があると仮定する。そして、各端末が再生しているコンテンツ全体を長方形で表し、コンテンツは複数のフラグメントに分割されていることを意味する。コンテンツは、再生時間の経過によって、再生位置が先頭（長方形の左端）から末尾（右端）方向へ移動する。コンテンツに対して、再生位置（再生時刻）とバッファリング可能な位置（バッファリング可能時刻）とが規定され、時間経過に伴い、再生位置とバッファリング可能な位置は末尾方向に移動する。

再生時刻とバッファリング可能時刻との間の時間は、配信遅延許容時間であり、この間
は、コンテンツバッファ５０５に格納されたフラグメントを用いたコンテンツの再生がなされる。よって、配信遅延許容時間が経過する前に次のフラグメントが供給されれば、中断や停止のない再生が行われる。

ここで。端末ｔ２に注目すると、端末ｔ１の配信遅延許容時間内に再生位置が入っているので、この配信遅延許容時間内に次のフラグメントが供給されるようにフラグメントの配信を行っても、バッファリングが可能で、且つ再生が中断又は停止することもない。決定部３１２は、このような端末ｔ１と端末ｔ２とを同じグループ（例えばグループ１）にグルーピングする。端末ｔ１は、「第１の配信先」の一例であり、端末ｔ２は、「第１の配信先に対応する所定期間内に再生位置が存する第１の配信先以外の配信先」の一例である。これに対し、端末ｔ３の再生位置は、端末ｔ１の配信遅延許容時間外にあるので、フラグメントの配信タイミングを端末ｔ１に揃えることができない。よって、端末ｔ３は、端末ｔ１と同じグループにグルーピングされない。

図１１は、グルーピングの例を示す。想定として、端末ｔ１〜ｔ６は、同じ動画コンテンツを再生中である。各端末の使用帯域は１０Ｍｂｐｓである。ＡＰの許容帯域は５０Ｍｂｐｓである。そして、マルチキャスト用の帯域上限が２０Ｍｂｐｓである。

端末ｔ１〜ｔ６の再生位置（再生時刻）とバッファリング可能な位置（バッファリング可能時刻）とが図１１に示すような状態である場合、端末ｔ２及び端末ｔ３の再生位置は、端末ｔ１の配信遅延許容時間内にある。このため、決定部３１２は、端末ｔ１〜ｔ３を同一のグループＧ１にグルーピングする。また、決定部３１２は、端末ｔ６の再生位置が端末ｔ５の配信遅延許容時間内にあるので、端末ｔ５と端末ｔ６とを同一のグループＧ２にグルーピングする。図１１の左下には、決定部３１２が管理するグループリスト３１２Ａを示す。グループＧ１の削減量は、端末ｔ１〜ｔ３の各帯域１０Ｍｂｐｓをマルチキャストにより一つに纏めるため、２０Ｍｂｐｓである。これに対し、グループＧ２の削減量は、端末ｔ５及びｔ６を一つに纏めるため、１０Ｍｂｐｓである。

そして、図９に示す０２７の処理においてグループＧ１が選択される。グループＧ１の使用帯域１０Ｍｂｐｓは、マルチキャスト用帯域２０Ｍｂｐｓを超えないので、０２９の処理でグループＧ１が選択される。０３０の処理で、グループＧ１は全端末をカバーしないので、グループＧ２について０２７〜０３０の処理が行われる。その後、０３０から０２６へ処理が遷移する。グループＧ１及びＧ２以外のグループは存在しないので、処理が０３３に遷移する。そして、図１１にグルーピング結果として示されるように、グループＧ１（端末ｔ１，ｔ２，ｔ３）に対するマルチキャスト配信が決定され、グループＧ２（端末ｔ５及びｔ６）に対するマルチキャスト配信が決定される。もっとも、端末ｔ４は、いずれのグループにも属することができないので、端末ｔ４に対するユニキャストが決定される。

＜第１実施形態の効果＞
第１実施形態では、「配信先毎に異なる再生位置で再生可能なコンテンツの複数の配信先」の一例として複数の端末５が用意され、「複数の配信先へのコンテンツの配信を制御するコンテンツ配信制御装置」の一例として、ゲートウェイ３が用意されている。

ゲートウェイ３は、各端末５から得られる、コンテンツの再生位置と前記再生位置からの所定期間を示す情報（配信遅延許容時間）とに基づいて、複数の配信先をグルーピングするグルーピング部としての決定部３１２（ＣＰＵ３１）を含む。

また、決定部３１２（ＣＰＵ３１）は、複数の配信先へのコンテンツの配信に使用される網の使用状況に基づいて、グルーピングにより形成されたグループに対するコンテンツ
の配信方法を判定する判定部の一例である。

グルーピング部としての決定部３１２は、複数の配信先（例えば、端末ｔ１〜ｔ６（図１１））のうち、第１の配信先（端末ｔ１）と、第１の配信先に対応する所定期間内に再生位置が存する第１の配信先以外の配信先（端末ｔ２，ｔ３）とを１つのグループ（Ｇ１）にグルーピングする。

判定部としての決定部３１２は、無線網４の使用状況に基づいて、１つのグループに対する前記コンテンツのマルチキャスト配信が可能か否かを判定する（図９，０２８）。そして、マルチキャスト配信可能な場合には、グループＧ１に対するマルチキャスト配信の設定を行う。これによって、端末ｔ１，ｔ２，ｔ３に対し、マルチキャストで共通な帯域を用いたコンテンツ配信がなされるので、無線網４の使用帯域を削減することができる。このように、第１実施形態は。コンテンツ配信に用いる帯域を削減可能とすることができる。

また、第１実施形態では、判定部としての決定部３１２は、複数のグループ（例えばＧ１，Ｇ２）が形成される場合に、マルチキャスト配信による帯域削減量が大きいグループの配信方法の判定を優先して行う（図９，０２７〜０２９の処理参照）。これによって、削減量の多いグループからマルチキャストに切り替えて、使用帯域の削減を図る。

第１実施形態によれば、図１に示したようなコンテンツの配信システム（ゲートウェイ３）において、端末５毎のアプリの実行状況（コンテンツの再生状況）である動画コンテンツの再生位置と配信遅延許容時間とに基づき、端末５のグルーピングを行う。グルーピングは、コンテンツの配信を一纏めに可能な端末、すなわち、或る端末５の再生位置に基づく配信遅延許容時間内に再生位置が存する或る端末５以外の端末５が同一のグループにグルーピングされる。

そして、各端末５に対するコンテンツフラグメントの供給網（網）である無線網４の使用状況に基づき、各グループに対するコンテンツ（フラグメント）の配信方法として、マルチキャストとユニキャストとのいずれを適用するかが決定される。第１実施形態では、各グループに属する端末５の使用帯域がマルチキャスト用の帯域以下である場合に、マルチキャスト配信が決定され、そうでない場合にユニキャスト配信が決定される。

グルーピング（グループ化）前では、個々の端末５に対してユニキャストによりフラグメントが供給されていたのに対し、マルチキャスト配信では、共通の帯域を用いてフラグメントが供給されるので、無線網４における使用帯域が削減される。よって、輻輳の発生が抑えられ、ユーザがユーザ体感品質（ＱｏＥ）が低下したと認識するケースを減らす（抑える）ことができる。

上記したように、第１実施形態では、複数のグループが形成された場合に、帯域の削減量が大きいグループから優先的に配信方法が判定される。これによって、帯域の削減効果の大きいグループを優先的にマルチキャスト配信に変更することで、使用帯域を削減できる。

〔第２実施形態〕
以下、第２実施形態について説明する。第２実施形態は第１実施形態との共通点を含むので、主として相違点について説明し。共通点についての説明は省略する。

第２実施形態では、ユーザに分からないように（ユーザに認識されない程度に）動画再生アプリ７によるコンテンツの再生速度を調整し、グループ化可能な端末５を増やす。こ
れにより、コンテンツの供給網（無線網４）の使用帯域を削減し、第１実施形態よりもＱｏＥの低下を認識するユーザを減らすことを可能とする。

図１２は、第２実施形態におけるゲートウェイ３及び端末５の構成例を示す図である。第２実施形態のハードウェア構成は、第１実施形態と同様の構成（図２）を適用することができる。

第２実施形態におけるゲートウェイ３及び端末５は、第１実施形態とほぼ同様の構成を採ることができる（図３）。但し、第２実施形態の構成が第１実施形態の構成と異なる点は、以下の通りである。
（０）端末５のプロキシ６がさらに再生速度制御部５１５を有する。再生速度制御部５１５は、動画再生アプリ７によるコンテンツの再生速度を速めたり遅くしたりすることができる。

（１）端末５側のアプリ実行状況検出部５０２が、再生位置と配信遅延許容時間の他に、再生速度を検出する。
再生速度は，通常の再生速度を例えば１．０とした場合における倍率である。再生速度の変化がユーザにとって気にならないように、再生速度の取り得る範囲は、例えば、１．０（標準）を中心に±０．１（倍）の範囲に収められる。但し、再生速度（倍率）は、ユーザが気にしない範囲で適宜変更可能である。

（２）ゲートウェイ３のアプリ実行状況管理部３０９が，端末毎の再生速度も管理する。
図１３は、第２実施形態におけるアプリ実行状況管理テーブル３０９Ｂのデータ構造例を示す。図１３に示すように、第１実施形態におけるアプリ実行状況管理テーブル３０９Ａのデータ構造（図５）に加えて、再生速度が記憶される。

（３）ゲートウェイ３の端末グループ決定部３１２が、端末５毎の再生速度を変更可能なことを考慮したグルーピングを行う。

図１４は、第２実施形態における端末５のグルーピング方法（端末５のグルーピングの考え方）の説明図である。第１実施形態との違いは、グルーピングの際の再生位置の範囲を第１実施形態よりも多少多めに評価することにある。

例えば、図１４における端末ｔ３は、第１実施形態においてグループ１に属さないと判定される。これに対し、第２実施形態では、端末ｔ１の配信遅延許容時間の満了時期と端末ｔ３の再生位置との時間差（再生位置のズレ）が小さい場合には、端末ｔ３における再生速度を遅くして端末ｔ１と同じグループにグルーピング可能と判定される。端末ｔ４は、再生位置のズレが若干大きいので、即座に端末ｔ１とグルーピングすることは不可能であるが、再生速度を遅くし、しばらくすると、端末ｔ１とグルーピング可能になると考えられる。端末ｔ１は、「第１の配信先」の一例であり、端末ｔ３は、「第２の配信先」の一例である。

図１５Ａ及び図１５Ｂは、第２実施形態における端末のグルーピング処理の例を示すフローチャートである。第２実施形態では、図１５Ａにおける０４１及び０４２の処理と、図１５Ｂにおける０５１〜０５７の処理とが追加されている点で、第１実施形態（図９）と異なる。図１６は、第２実施形態におけるグルーピング方法の説明図である。

０４１，０４２の処理では、決定部３１２は、各端末５の再生速度を確認し、再生速度が１．０未満の場合には０．０２を加算し、１．０を超えている場合には０．０２を減算
した値にするような、動画再生アプリ７に対するコマンドを各端末５に割り当てる。割当られたコマンドが、各端末５の動画再生アプリ７に供給される。これは、どの端末も既にグルーピングされるか、そもそも帯域が潤沢にあるため、グルーピングする必要がなく、再生速度の調整を行う必要がないため、変更された再生速度を、本来の値１．０に徐々に戻すための処理である。

０５１の処理は、０２６にて未選択グループがないと判定された場合、及びグループの使用帯域がマルチキャスト用帯域を超える場合に行われる。０５１では、決定部３１２は、選択されたグループに所属する各端末５の再生速度を確認する。このとき、１．０未満の場合に０．０２加算し、１．０を超えている場合に０．０２減算した値にするような動画再生アプリ７に対するコマンドが各端末５に割り当てられる。

０５２の処理では、決定部３１２は、グループ未所属でまだ速度調整確認してないものがあるか否かを判定する。速度調整確認していないものがない場合には処理が０３３に進み。速度調整確認していないものがある場合には処理が０５３に進む。

０５３の処理では、決定部３１２は、グループに所属しない端末５を一つ選択し，選択した端末５の再生位置の近傍で、且つ或るグループに属する端末５の再生位置との差分を計算する。このとき、選択した端末５の両隣に別個のグループにそれぞれ属する端末５の再生位置が存する場合には、決定部３１２は、再生位置が近い側の再生位置との差分を計算する。

０５４では、決定部３１２は、差分がグループ化の閾値Δ１以下であるか否かを判定する。差分が閾値Δ１以下である場合には、処理が０５５に進み、そうでない場合には、処理が０５７に進む。

０５５では、決定部３１２は、０５３で選択した端末を、０５３での差分算出に用いた再生位置の端末５（最近傍端末）が属するグループに追加する。０５６では、決定部３１２は、追加した端末の再生位置がグループより遅れている場合に０．０２を加算し、進んでいる場合に０．０２を再生速度から減算した値にするコマンドを当該端末に割り当てる（供給する）。但し，再生速度が１．０の±０．１、すなわち[０．９≦再生速度≦１．
１]の範囲に収まらない場合は、再生速度を変更しない。その後、処理が０５２に戻る。

０５７に処理が進んだ場合には、決定部３１２は、０５３で算出した差分が速度調整の閾値Δ２以下か否かを判定する。差分が閾値Δ２以下の場合には、処理が０５６に進み、グループ化はされないが、再生位置が最近傍グループの再生位置に近づけられる。これに対し、差分が閾値Δ２を超える場合には、処理が０５２に戻る。

図１６に示すように、同じコンテンツを再生する端末ｔ１〜ｔ７があり、端末ｔ１〜ｔ７の再生位置が、図１６に示すように分布していると仮定する。端末ｔ２及びｔ３の再生位置は、端末ｔ１の配信遅延許容時間内（破線枠参照）に存するため、グループＧ１にグルーピングされる（図１５Ａ，０２３）。同様にして、端末ｔ６と端末ｔ７とがグループＧ２にグルーピングされる。なお、端末ｔ４，端末ｔ５はグルーピングされない。このような処理の結果、０２６から０５１へ処理が進む。

端末ｔ４、端末ｔ５は、どちらもグループに所属していないので、０５１において、再生速度の調整は行われず、０５２の条件に合致するので、処理が０５３に進む。

０５３では、端末ｔ４と端末ｔ５とのうち、例えば端末ｔ４が選択される。図１６に示すように、端末ｔ４の再生位置の左隣には、グループＧ１に属する端末ｔ３の再生位置が
隣接している。右側には、グループ２が存在するが、グループ２に属する端末ｔ６およびｔ７よりも、端末ｔ３の方が近いので、端末ｔ３を端末ｔ４の最近傍端末と見なす。決定部３１２は、端末ｔ４の再生位置と、端末ｔ３の再生位置との差分を算出し（０５３）、閾値Δ１以下か否かを判定する（０５４）。このとき、差分がΔ１以下である（再生位置がグループＧ１に非常に近い）と仮定すると、決定部３１２は、端末ｔ４をグループＧ１に追加する（０５５）。０５６で、決定部３１２は、端末ｔ４がグループＧ１より進んでいるので、再生速度に０．０２を減算する。これにより，端末ｔ４の再生位置が端末ｔ３の再生位置に近づく。

その後、処理が０５２に戻り、０５３にて端末ｔ５が選択される。端末ｔ５の右側には端末ｔ５に隣接するグループＧ２がある（左側のグループはグループＧ２よりも離れている）。このため、グループＧ２中の最近傍の再生位置（端末ｔ６の再生位置）と端末ｔ５の再生位置との差分を決定部３１２は計算する（０５３）。このとき、差分は閾値Δ１を超過する（０５４）、しかし差分は閾値Δ２以下である（０５７）と仮定する（再生位置がグループＧ２にやや近い）。この場合、０５６において、端末ｔ５の再生速度が０．０２減算される。これにより，端末ｔ５の再生位置が端末ｔ６の再生位置に近づく。端末ｔ５は、グループＧ２に追加されないが、０５６でグループＧ２に近づけられるため、やがてグループＧ２に追加される程に再生位置が近づく可能性がある。

コマンドに関しては、以下のように扱われる。０４１，０４２等でコマンドが端末に割り当てられると、ゲートウェイ３でコマンドが発行され（コンテンツサーバ１に発行させても良い）、フラグメントとともに、宛先の端末５へ送信される。但し、コマンドは、フラグメントとは別個に端末５へ送信されても良い。

図１２に示すように、第２実施形態では。端末５のプロキシ６が再生速度制御部５１５を有する。端末５のコンテンツ受信部５０４は、ゲートウェイ３から、コンテンツフラグメントとともに再生速度の変更コマンドを受信する。コンテンツ受信部５０４は、再生速度変更コマンドを再生速度制御部５１５に渡し、動画再生アプリ７のＡＰＩを呼び出して，動画コンテンツの再生速度を変更する。

図１７は、第２実施形態における“処理１”の例を示すフローチャートである。第２実施形態では、０３の処理（図７）の代わりに０３Ａの処理が行われる点で、第１実施形態と異なる。

プロキシ６において、リクエスト受信部５０１は、アプリ７からのリクエストを受信すると（０２）、アプリ実行状況検出部５０２を用いて、アプリ７の実行状況（再生位置，配信遅延許容時間、再生速度）を検出する（０３Ａ）。図１７の処理は、０３Ａ以外は第１実施形態の処理（図７）と同じであるので説明は省略する。

図１８Ａ及び図１８Ｂは、第２実施形態における“処理２”を示すフローチャートである。図１８Ａにおいて、第１実施形態の処理（図８Ａ及び図８Ｂ）における００４，００８，０１０の代わりに００４Ａ，００８Ａ，０１０Ａが設けられている点で、第１実施形態と異なる。また、図１８Ｂに示すように、０１６及び０１７が追加されている点で、第１実施形態と異なる。

００４Ａでは、００４では、端末グループ決定部３１２が各端末５のアプリ実行状況と、無線網４の使用状況とを参照して，端末のグルーピングを行う。このとき、決定部３１２は、再生速度の変更を要する端末５向けに、変更内容を決定する。

００８Ａでは、コンテンツ配信部３１４は、ＵＲＬとグループに属する端末ＩＤのリス
トとともに、フラグメントをマルチキャストで配信する。このとき、再生速度の変更コマンドがあれば、変更コマンドがフラグメントともに配信される。

０１０Ａでは、コンテンツ配信部３１４は、ＵＲＬとグループに属する端末ＩＤのリストとともに、フラグメントをユニキャストで配信する。このとき、再生速度の変更コマンドがあれば、変更コマンドがＵＲＬ，端末ＩＤリスト及びフラグメントともに配信される。

０１６では、再生速度の変更コマンドの有無が判定され、変更コマンドがある場合、変更コマンドに従って動画再生アプリ７によるコンテンツの再生速度が経項される（０１７）。

第２実施形態では、グループに属しない第２の配信先のコンテンツの再生速度と、グループに属する第１の配信先の再生速度との差分が求められる。第２の配信先は、例えば、図１６の例における端末ｔ４，端末ｔ５である。第１の配信先は、端末ｔ４に対する端末ｔ３，端末ｔ５に対する端末ｔ６である。端末ｔ３は、グループＧ１に属し且つ再生位置が端末ｔ４の再生位置の最近傍に位置する。端末ｔ６は、グループＧ２に属し且つ再生位置が端末ｔ５の再生位置の最近傍に位置する。

決定部３１２は、第１及び第２の配信先の再生位置の差分に基づいて、第１の配信先（ｔ４，ｔ５）の再生位置をグループ（Ｇ１，Ｇ２）に属する配信先（ｔ３，ｔ６）の再生位置に近づける再生速度の変更を設定する設定部（図１５Ｂ，０５６）の一例である。

第２実施形態は、さらに、グルーピング部としての決定部３１２が第１の配信先（ｔ３）の再生位置と第２の配信先（ｔ４）の再生位置との差分が閾値Δ１より小さい場合に第２の配信先（ｔ４）を第１の配信先（ｔ３）が属するグループＧ１に追加する。これによって、端末ｔ４をマルチキャストグループに含めて帯域削減を図ることができる。

換言すれば、第２実施形態では、コンテンツの再生速度を変更し、グループに属する端末５の数を増やすことができる。これによって、輻輳発生を第１実施形態よりも抑え、ユーザのＱｏＥが低下する可能性を抑えることができる。
以上説明した実施形態の構成は、適宜組み合わせることができる。

１・・・コンテンツサーバ
３・・・ゲートウェイ（ＡＰ含む）
４・・・無線網
５・・・端末
６・・・プロキシ
７・・・動画再生アプリ
３１，５１・・・ＣＰＵ
３２，５２・・・主記憶装置
３３，５３・・・補助記憶装置
３４，５４・・・無線通信回路

Claims (7)

1. 異なる再生位置で再生可能なコンテンツの複数の配信先のそれぞれから得られる、前記コンテンツの再生位置と前記再生位置からの所定期間を示す情報とに基づいて、前記複数の配信先をグルーピングするグルーピング部と、
   前記複数の配信先への前記コンテンツの配信に使用される網の使用状況に基づいて、前記グルーピングにより形成されたグループに対するコンテンツの配信方法を判定する判定部と
   を含むコンテンツ配信制御装置。
2. 前記グルーピング部は、前記複数の配信先のうち、第１の配信先と、前記第１の配信先に対応する前記所定期間内に再生位置が存する前記第１の配信先以外の配信先とを１つのグループにグルーピングし、
   前記判定部は、前記使用状況に基づいて、前記１つのグループに対する前記コンテンツのマルチキャスト配信が可能か否かを判定する
   請求項１に記載のコンテンツ配信制御装置。
3. 前記判定部は、前記グルーピング部によって複数のグループが形成された場合に、マルチキャスト配信による帯域削減量が大きいグループの配信方法の判定を優先して行う
   請求項１又は２に記載のコンテンツ配信制御装置。
4. 前記グループに属しない第２の配信先の前記コンテンツの再生速度と、前記グループに属し且つ再生位置が前記第２の配信先の再生位置の最近傍の第１の配信先の再生位置と前記第２の配信先の再生位置との差分とに基づいて、前記第２の配信先の再生位置を前記グループに属する配信先の再生位置に近づける再生速度の変更を設定する設定部をさらに含む
   請求項１から３のいずれか１項に記載のコンテンツ配信制御装置。
5. 前記グルーピング部は、前記第１の配信先の再生位置と前記第２の配信先の再生位置との差分が閾値より小さい場合に前記第２の配信先を前記グループに追加する
   請求項４に記載のコンテンツ配信制御装置。
6. 異なる再生位置で再生可能なコンテンツの複数の配信先への配信を制御するコンテンツ配信制御装置が、
   前記複数の配信先のそれぞれから得られる、前記コンテンツの再生位置と前記再生位置からの所定期間を示す情報とに基づいて、前記複数の配信先をグルーピングし、
   前記複数の配信先への前記コンテンツの配信に使用される網の使用状況に基づいて、前記グルーピングにより形成されたグループに対するコンテンツの配信方法を判定する
   ことを含むコンテンツ配信制御装置のコンテンツ配信制御方法。
7. 異なる再生位置で再生可能なコンテンツの複数の配信先への配信を制御するコンテンツ配信制御装置として動作するコンピュータに、
   前記複数の配信先のそれぞれから得られる、前記コンテンツの再生位置と前記再生位置からの所定期間を示す情報とに基づいて、前記複数の配信先をグルーピングし、
   前記複数の配信先への前記コンテンツの配信に使用される網の使用状況に基づいて、前記グルーピングにより形成されたグループに対するコンテンツの配信方法を判定する
   ことを実行させるプログラム。

Images