JP7456445B2 - 通信制御方法、通信装置及び通信システム - Google Patents

Description

本発明は、通信制御方法、通信装置及び通信システムに関する。

モバイル通信網の発展に伴い、スマートフォン等の移動体端末にて動画等のコンテンツを視聴する機会が増加している。動画配信サービスでは、端末がネットワーク上のサーバに対して動画配信リクエストを送信する。サーバは、当該リクエストに応じた動画データを端末に配信する。

上記の動画配信リクエストやその応答に関するメッセージ（パケット）は、モバイル通信網を介して転送される。モバイル通信網では、ＱｏＳ（Quality of Service）やＱｏＥ（Quality of Experience）を確保するためのトラフィック制御が行われることがある。

特許文献１には、複数のストリーミングビデオトラフィックに対応する通信ネットワーク内の輻輳制御のための方法が開示されている。

特許文献２には、ネットワーク帯域幅を効率的に利用して、より良い動画データ配信品質をユーザに提供することができる、と記載されている。

特許文献３には、動画配信サーバが複数の配信モードで動画データの配信を行う場合に、動画再生ビットレートの推定精度を向上させる技術が開示されている。

特表２０１６－５０８３１６号公報 特開２０１７－０２８７００号公報 国際公開第２０１９／０４４０６５号

上述のように、中継装置（プロキシサーバ）にてトラフィック制御が実施されることがある。例えば、動画の解像度とビットレートの関係は固定であるという前提でトラフィック制御が行われることがある。

上記トラフィック制御を実施することで、配信される動画が要求する以上の帯域を確保する必要がなくなりネットワークの輻輳を避けることができるなど一定の効果が期待できる。しかし、上記のようなトラフィック制御では、動画の解像度とビットレートの関係を固定的に扱っており、実情に合致しないという問題がある。

具体的には、動画の内容が異なれば、同じ解像度であっても必要とされるビットレートは異なる。例えば、動きの激しい動画と静止画に近いような動画では、同じ解像度であっても要求されるビットレートが異なる（動きの激しい動画の方がより高いビットレートを要求する）。例えば、風景のように複雑な配色の動画と、単色を用いる動画では、同じ解像度であっても要求されるビットレートが異なる（複雑な配色の動画の方がより高いビットレートを要求する）。

従って、上記予め用意された解像度とビットレートの関係を用いてトラフィック制御を行うと、端末側で目標とする解像度の動画が再生されない可能性がある。例えば、動きの激しい動画の場合には転送レートが足りず、目標とする解像度より低い解像度で動画が再生される可能性がある（端末が目標よりも低い解像度の動画配信をサーバに要求する）。

対して、静止画に近いような動画を再生した場合には中継装置の転送レートは動画が要求するビットレートよりも高く、目標とする解像度よりも高い解像度の動画が再生される可能性がある（端末が目標よりも高い解像度の動画配信をサーバに要求する）。
例えば、風景のように複雑な配色の動画の場合には転送レートが足りず、目標とする解像度よりも低い解像度で動画再生される可能性がある（端末が目標よりも低い解像度の動画配信をサーバに要求する）。
対して、単色を用いる動画を再生した場合には中継装置の転送レートは動画が要求するビットレートよりも高く、目標とする解像度よりも高い解像度の動画が再生される可能性がある（端末が目標よりも高い解像度の動画配信をサーバに要求する）。

さらに、上記トラフィック制御は、端末からサーバに要求されるパケットを解析し、配信される動画の解像度が取得できることを前提としている。しかし、近年、端末とサーバ間の通信が暗号化される傾向が強くなっており、中継装置にて動画の解像度を取得することが困難になってきている。その結果、上記説明したトラフィック制御自体が困難になってきている。

なお、上記問題は特許文献１等に開示された技術を適用しても解決することはできない。具体的には、特許文献１では、パケットが暗号化されていないことを前提としており、暗号化されたトラフィックの制御は考慮されていない。また、特許文献２では、動画ごとに求められている品質について考慮されておらず、上記説明した問題（動画によってペーシングレートの過不足が発生）が生じうる。

このように、動画配信の現状では、配信動画に対してトラフィック制御を実施しつつ、端末にて再生される解像度を変更することが困難である。

本発明は、配信動画の解像度を変更可能とすることに寄与する、通信制御方法、通信装置及び通信システムを提供することを主たる目的とする。

本発明の第１の視点によれば、配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定し、前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出すること、を含む通信制御方法が提供される。

本発明の第２の視点によれば、配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定部と、前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出部と、を備える通信装置が提供される。

本発明の第３の視点によれば、端末と、前記端末に動画を配信する、動画配信サーバと、前記端末と前記動画配信サーバの間の通信を中継する、通信装置と、を含み、前記通信装置は、配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定部と、前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出部と、を備える、通信システムが提供される。

本発明の各視点によれば、配信動画の解像度を変更可能とすることに寄与する、通信制御方法、通信装置及び通信システムが提供される。なお、本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

一実施形態の概要を説明するための図である。 第１の実施形態に係る通信システムの概略構成の一例を示す図である。 第１の実施形態に係るプロキシサーバの処理構成の一例を示す図である。 第１の実施形態に係るビットレート推定部の動作を説明するための図である。 第１の実施形態に係るビットレート推定部の動作を説明するための図である。 第１の実施形態に係るビットレート推定部の動作を説明するための図である。 解像度ごとの確率密度関数の一例を示す図である。 解像度ごとのビットレートの累積分布関数の一例を示す図である。 ビットレート情報の一例を示す図である。 第１の実施形態に係るビットレート情報生成部の動作の一例を示すフローチャートである。 第１の実施形態に係るプロキシサーバの別の処理構成の一例を示す図である。 第１の実施形態に係る通信制御部の動作の一例を示すフローチャートである。 第１の実施形態に係るプロキシサーバの動作の一例を示すフローチャートである。 解像度対ビットレートの分布の一例を示す図である。 解像度対ビットレート（対数）の分布の一例を示す図である。 第２の実施形態に係るビットレート情報生成部の動作の一例を示すフローチャートである。 第２の実施形態の変形例に係るビットレート情報生成部の動作の一例を示すフローチャートである。 プロキシサーバのハードウェア構成の一例を示す図である。

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

一実施形態に係る通信装置１００は、第１の推定部１０１と、算出部１０２と、を含む（図１参照）。第１の推定部１０１は、配信動画のトラフィックに基づいて配信動画の第１の解像度を推定する。算出部１０２は、第１の解像度に基づいて配信動画を第２の解像度で配信するための第１のビットレートを算出する。

ここで、ネットワーク上にて端末とサーバ間のパケット転送に関してトラフィック制御が行われることがある。具体的には、ネットワーク上にパケットの中継を行う中継装置（所謂、プロキシサーバ）を設け、当該中継装置がトラフィック制御を行う。

例えば、中継装置は、端末からサーバに送信される動画リクエストを解析し、端末がサーバに要求している動画品質（例えば、解像度）を推定する。中継装置は、当該推定した動画品質（解像度）と、予め用意された「解像度とビットレートの対応関係」を示す情報と、に基づいて配信されている動画のビットレートを推定する。例えば、「解像度が１４４ｐの場合は２００ｋｂｐｓのビットレート」、「解像度が２４０ｐの場合は４００ｋｂｐｓのビットレート」といったような情報が予め用意され、当該情報に推定した解像度を当て嵌めることで配信されている動画のビットレートが推定される。

中継装置は、当該推定されたビットレートをサーバから端末に送信されるパケットの転送レート（ペーシングレート）に設定する。しかし、上記のようなトラフィック制御では、動画の解像度とビットレートの関係を固定的に扱っており、実情に合致しないという問題がある。

一方、通信装置１００は、動画配信サーバから配信中の動画の解像度を推定する。詳細に関しては後述するように、動画の解像度とビットレートの間には所定の関係が認められる（例えば、図７、図８の統計情報を参照）。通信装置１００は、当該解像度とビットレートの間の関係を利用し、配信動画の解像度を変更した際のビットレートを算出する。当該算出されたビットレートに基づきトラフィック制御が実施されることで、ユーザは解像度が変更された動画の視聴が可能となる。即ち、通信装置１００によって配信動画の解像度が変更可能となる。

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

図２は、第１の実施形態に係る通信システムの概略構成の一例を示す図である。図２を参照すると、通信システムには、端末１０と、モバイル通信網２０と、動画配信サーバ３０と、が含まれる。

端末１０と動画配信サーバ３０は、モバイル通信網２０を介して接続されている。

ユーザは、端末１０を使用して動画を視聴する。端末１０にインストールされた動画再生アプリケーションは、再生動画の品質（解像度、ビットレート）を知ることができる。端末１０は、再生動画の品質を液晶ディスプレイ等に表示してもよい。

端末１０には、スマートフォン、携帯電話機、ゲーム機、タブレット等の携帯端末装置やコンピュータ（パーソナルコンピュータ、ノートパソコン）等が例示される。

動画配信サーバ３０は、端末１０からの要求に応じて動画を配信する装置である。

モバイル通信網２０には、ルータ２１及び２２と、ロードバランサ２３と、複数のプロキシサーバ２４と、が含まれる。さらに、モバイル通信網２０には、サービスコントローラ（ＳＣ；Service Controller）２５と、ポリシ及び課金ルールサーバ（ＰＣＲＦ；Policy and Charging Rules Function）２６と、ログ収集サーバ２７と、ログ表示サーバ２８と、が含まれる。

ロードバランサ２３は、ルータ２１及び２２を介してモバイル通信網２０に入力されたパケットを取得する。ロードバランサ２３は、複数のプロキシサーバ２４の負荷が均一になるように、各プロキシサーバ２４に割り振るパケットを決定する。

プロキシサーバ２４は、端末１０と動画配信サーバ３０の間の通信を中継する装置である。例えば、プロキシサーバ２４は、端末１０と動画配信サーバ３０の間のトラフィック制御を行う。プロキシサーバ２４の詳細は後述するが、プロキシサーバ２４は、ユーザが動画を快適に視聴するための解像度が選択されるようにトラフィック制御を実行する。その際、プロキシサーバ２４は、ユーザが動画を快適に視聴するための解像度を選択するポリシを参照する。

プロキシサーバ２４は、上述の通信装置１００に相当する装置である。プロキシサーバ２４は、配信動画のトラフィックに基づいて配信動画の第１の解像度を推定する機能（第１の推定部）と、第１の解像度に基づいて配信動画を第２の解像度で配信するための第１のビットレートを算出する機能（算出部）を備える。さらに、プロキシサーバ２４は、第１のビットレートに基づき、配信動画のトラフィック制御を行う機能（制御部）も備える。

サービスコントローラ２５は、プロキシサーバ２４がトラフィック制御等を実行する際に必要となる情報を制御する装置である。具体的には、サービスコントローラ２５は、ポリシ及び課金ルールサーバ２６からトラフィック制御に関するポリシや端末１０に関する課金ルールをプロキシサーバ２４に入力する。

ログ収集サーバ２７は、各プロキシサーバ２４における通信ログを収集する装置である。ログ収集サーバ２７は、収集したログをログ表示サーバ２８に送信する。ログ表示サーバ２８は、受信したログの解析等を行うことでログ情報を生成する。ログ表示サーバ２８は、当該生成されたログ情報を表示する（システム管理者にログ情報を提供する）。

続いて、図２を参照しつつ、第１の実施形態に係る通信システムの動作の概略を説明する。

端末１０が、モバイル網を介して、動画配信サーバ３０に対して動画リクエストを送信する。

動画配信サーバ３０は、当該リクエストに応じて動画（動画データを格納したパケット）を端末１０に向けて送信する。なお、動画リクエストは暗号化されており、プロキシサーバ２４は、当該リクエストに記載された内容、情報を得ることができない。プロキシサーバ２４は、どのような解像度、ビットレートの動画が動画配信サーバ３０から配信されてくるか知ることができない。

プロキシサーバ２４は、ロードバランサ２３を介して取得したパケットに基づいて、動画配信サーバ３０が配信している動画のビットレートを推定する。プロキシサーバ２４は、端末１０から送信される配信動画の再生に関するリクエストに基づき配信中の動画に関するビットレートを推定する。以降の説明において、プロキシサーバ２４にて推定される動画のビットレートを「推定ビットレート」と表記する。

プロキシサーバ２４は、推定ビットレートを用いて、動画配信サーバ３０から配信されている動画の解像度を推定する。その際、プロキシサーバ２４は、上記推定されたビットレートと複数の配信動画の解像度に関する統計情報（例えば、確率密度関数や累積分布関数）を用いて、上記解像度を推定する。以降の説明において、プロキシサーバ２４にて推定される動画の解像度を「推定解像度」と表記する。

プロキシサーバ２４は、動画配信サーバ３０から配信されている動画の解像度を変更した場合に、当該変更された解像度の動画をユーザが視聴できるようなビットレートを算出する。プロキシサーバ２４は、動画配信サーバ３０から配信されている動画の解像度を変更（例えば、動画の解像度を下げる変更）した場合、当該解像度が変更された動画が端末１０にて再生されるビットレートを算出する。

当該ビットレートの算出は、動画配信サーバ３０から配信される動画が取り得る解像度ごとに実行される。当該動画が取り得る解像度に関する情報は、予めプロキシサーバ２４に入力しておく。あるいは、プロキシサーバ２４は、動画配信サーバ３０に直接アクセスし、動画配信サーバ３０が取り扱い可能な解像度に関する情報を取得してもよい。例えば、動画配信サーバ３０が、１４４ｐ、２４０ｐ、３６０ｐの各解像度で動画の配信が可能な場合を考える。この場合、プロキシサーバ２４は、１４４ｐの解像度で動画が再生されるためのビットレート、２４０ｐの解像度で再生されるためのビットレート、３６０ｐの解像度で再生されるためのビットレートをそれぞれ算出する。

上記説明したように、プロキシサーバ２４は、動画の解像度ごとに当該解像度の動画が端末１０にて再生されるためのビットレートを算出する。以降の説明において、動画の解像度と、当該解像度の動画が端末１０で再生されるためのビットレートと、を対応付けた情報（解像度とビットレートの対応情報）を「ビットレート情報」と表記する。

プロキシサーバ２４は、外部（サービスコントローラ２５等）から設定されたポリシを参照し、動画配信サーバ３０から配信される動画の解像度に関する目標値を決定する。以降の説明において、プロキシサーバ２４が参照するポリシを「解像度選択ポリシ」と表記する。解像度選択ポリシは、端末１０で再生される動画の解像度の決定に関するポリシである。プロキシサーバ２４が当該解像度選択ポリシを参照して決定する解像度の目標値を「ターゲット解像度」と表記する。

プロキシサーバ２４は、解像度選択ポリシに従って決定したターゲット解像度で配信動画が再生されるようにトラフィック制御を行う。例えば、プロキシサーバ２４は、ビットレート情報を参照し、ターゲット解像度に対応するビットレートを特定する。プロキシサーバ２４は、当該特定したビットレートで動画が端末１０にて再生されるように動画配信サーバ３０から端末１０に向けたパケット転送を制御する。

例えば、動画配信サーバ３０が４８０ｐの動画を配信しており、当該動画の解像度を３６０ｐに下げる場合について考える。この場合、プロキシサーバ２４は、端末１０における動画再生が３６０ｐの解像度となるようにスループット（転送レート、ペーシングレート）を調整する。具体的には、プロキシサーバ２４は、端末１０が動画配信サーバ３０に対して、解像度が３６０ｐの動画を配信するように指示するようにスループットを低くする。スループットが低下すると、端末１０では４８０ｐの動画再生が途切れるなど動画再生に支障が生じる。そのため、端末１０は、現状の解像度（４８０ｐ）よりも低い解像度（３６０ｐ）の動画配信を動画配信サーバ３０に依頼する。

なお、図２に示す構成は例示であって、通信システムの構成を限定する趣旨ではない。例えば、図２には１台の端末１０を図示しているが、通信システムには多数の端末１０が含まれ得る。また、図２では、モバイル通信網２０と動画配信サーバ３０が直接接続されているように記載されているが、インターネット等のネットワークを介してモバイル通信網２０と動画配信サーバ３０が接続されていてもよい。

図３は、第１の実施形態に係るプロキシサーバ２４の処理構成（処理モジュール）の一例を示す図である。図３を参照すると、プロキシサーバ２４は、通信制御部２０１と、ビットレート推定部２０２と、ビットレート情報生成部２０３と、ターゲット解像度決定部２０４と、ペーシングレート決定部２０５と、記憶部２０６と、を含んで構成される。

通信制御部２０１は、ロードバランサ２３から取得したパケットに関する通信制御を行う手段である。具体的には、通信制御部２０１は、端末１０から取得したパケットを動画配信サーバ３０に向けて送信し、動画配信サーバ３０から取得したパケットを端末１０に向けて送信する。

通信制御部２０１は、動画配信サーバ３０から送信されるパケット（動画配信パケット）に関するトラフィック制御を実施する。例えば、通信制御部２０１は、動画配信サーバ３０から端末１０に向けて送信されたパケットの転送をペーシングレート決定部２０５が決定したペーシングレートにより行う。

通信制御部２０１は、ペーシングレート決定部２０５からペーシングレートを取得していない場合には予め定めたペーシングレートによりトラフィック制御を実施してもよいし、トラフィック制御を実施しなくともよい。

通信制御部２０１は、上記トラフィック制御をユーザごと（端末１０ごと）に実施する。

通信制御部２０１は、ロードバランサ２３から取得したパケットの複製をビットレート推定部２０２に引き渡す。

ビットレート推定部２０２は、当該取得したパケットに基づいて、動画配信サーバ３０から配信されている動画のビットレートを推定する手段である。上述のように、端末１０と動画配信サーバ３０との間の通信は暗号化されていることが多く、プロキシサーバ２４は、端末１０が動画配信サーバ３０に要求した動画の品質（解像度、ビットレート）を知ることができない。

端末１０と動画配信サーバ３０の間の通信が暗号化されている場合であっても、ビットレート推定部２０２は、端末１０と動画配信サーバ３０間で送受信される暗号化パケット（暗号化トラフィック）を解析し、当該動画のビットレートを推定する。

なお、ビットレート推定部２０２は、特許文献３に開示された技術を用いて動画のビットレートを推定できるのでその詳細な説明を省略する。ビットレート推定部２０２は、概略、以下のような動作によりビットレートを推定する。

ビットレート推定部２０２は、動画配信サーバ３０から配信される動画が有する特徴に着目してビットレートを推定する。

具体的には、端末１０にインストールされた動画視聴アプリケーションが、動画視聴開始時点から所定の時間経過後にリクエストパケットの送信間隔を変更することで、動画配信サーバからの動画配信パターンが変化する。このときの動画配信モードはＴｈｒｏｔｔｌｉｎｇと称される。なお、Ｔｈｒｏｔｔｌｉｎｇの前の動画配信モードはＩｎｉｔｉａｌ Ｂｕｒｓｔと称される。Ｉｎｉｔｉａｌ Ｂｕｒｓｔでは、端末１０からリクエストを連続的に受け付け、要求された動画データ（チャンク）が連続的に端末１０に送信される。連続的に送信された動画データは、端末１０にてバッファリングされる。

上記説明したように、端末１０にインストールされた動画視聴アプリケーションは、通信開始から所定時間（例えば、５秒程度）経過後に、リクエストパケットの送信間隔を変更する。その結果、配信モードがＴｈｒｏｔｔｌｉｎｇに切り替わる。Ｔｈｒｏｔｔｌｉｎｇモードの動画配信サーバ３０は、単位時間あたりに受け付けるリクエストを制限する。図４に示されるように、Ｉｎｉｔｉａｌ ＢｕｒｓｔとＴｈｒｏｔｔｌｉｎｇの各配信モードでは、通信トラフィックのパターンが異なっている。上述したように、Ｉｎｉｔｉａｌ ＢｕｒｓｔとＴｈｒｏｔｔｌｉｎｇでは、端末１０から送信されるリクエストの送信間隔が異なる。ビットレート推定部２０２は、当該事実に着目し、リクエストの送信間隔に対して閾値処理を実行することで、Ｉｎｉｔｉａｌ Ｂｕｒｓｔ又はＴｈｒｏｔｔｌｉｎｇを判別する。

なお、端末１０と動画配信サーバ３０の間の通信が暗号化されている場合には、ビットレート推定部２０２は、端末１０から動画配信サーバ３０に送信されるパケットを動画配信リクエストとして取り扱えばよい。

ここで、図５を参照すると、Ｉｎｉｔｉａｌ Ｂｕｒｓｔのスループット（平均スループット）と既知の再生ビットレートの間には高い相関関係があることがわかる。対して、図６を参照すると、Ｔｈｒｏｔｔｌｉｎｇのスループット（平均スループット）と既知の再生ビットレートの間の相関関係は低いことがわかる。

ビットレート推定部２０２は、このようなＩｎｉｔｉａｌ ＢｕｒｓｔとＴｈｒｏｔｔｌｉｎｇの違いに着目し、正解再生レートとの相関が高いＩｎｉｔｉａｌ Ｂｕｒｓｔのスループットを用いて配信動画のビットレートを推定する。具体的には、ビットレート推定部２０２は、配信動画のＩｎｉｔｉａｌ Ｂｕｒｓｔにおけるスループットの平均値を推定ビットレートに設定する。

ビットレート推定部２０２は、推定したビットレート（推定ビットレート）をビットレート情報生成部２０３に通知する。

ビットレート情報生成部２０３は、上述の「ビットレート情報」を生成する手段である。繰り返しとなるが、ビットレート情報は、動画配信サーバ３０から配信されている動画の解像度を可変した場合における、動画の解像度と、当該解像度が端末で再生されるためのビットレートと、を対応付けた情報である。

ビットレート情報生成部２０３は、ビットレート推定部２０２から取得した推定ビットレートと、記憶部２０６に予め格納された「解像度ごとの確率密度関数」と、を用いて配信されている動画の解像度を推定する。

解像度ごとの確率密度関数は、多数の動画に関して、その解像度とビットレートの関係を収集することで生成できる。具体的には、動画のビットレートを確率変数に設定し、各確率変数が取り得る確率を求めることで解像度ごとの確率密度関数を得ることができる。

記憶部２０６に格納された解像度ごとの確率密度関数を図示すると、例えば、図７に示すようなグラフが得られる。図７に示すように、解像度ごとの確率密度関数により、各解像度に対するビットレートの分布を得ることができる。図７を参照すると、解像度が低い動画に関しては要求されるビットレートが低く、解像度が高くなるについて要求されるビットレートが高くなることが理解される。

ビットレート情報生成部２０３は、ビットレート推定部２０２から取得した推定ビットレートを解像度ごとの確率密度関数に入力し、解像度ごとに推定ビットレートにおける確率を計算する。ビットレート情報生成部２０３は、複数の計算結果から最大値を特定する。ビットレート情報生成部２０３は、当該最大値に対応する解像度を特定する。上記ビットレート情報生成部２０３の動作は、下記の式（１）として表現できる。ビットレート情報生成部２０３は、式（１）を用いて配信中の動画の推定解像度Ｑ_Ｅを算出する。

なお、式（１）において、Ｑ（ｒｅｓ）は、各解像度に対応した推定ビットレートの確率を示す。また、ａｒｇ ｍａｘは、引数のなかから最大値を選択する関数である。

図７を参照すると、推定ビットレートがＢ１であれば、解像度３６０ｐの確率が最も高いので３６０ｐが推定ビットレートに対応する推定解像度として特定される。

ビットレート情報生成部２０３は、推定ビットレートと、推定解像度と、解像度ごとのビットレートの累積分布関数と、を用いて、ビットレート情報を生成する。解像度ごとのビットレートの累積分布関数ＣＤＦ（ｘ）は、下記の式（２）に示すように、解像度ごとの確率密度関数ＰＤＦ（ｘ）を使って算出することができる。

なお、解像度ごとのビットレートの累積分布関数は、式（２）に示すように確率密度関数から導出することができるが、予め、累積分布関数を算出して記憶部２０６に格納しておいてもよい。図８は、解像度ごとのビットレートの累積分布関数の一例を示す図である。

ビットレート情報生成部２０３は、推定解像度に対応する累積分布関数に推定ビットレートを入力し、推定解像度以下となる確率を計算する。以降の説明において、上記計算された確率を「ビットレート一致確率」と表記する。

ビットレート情報生成部２０３は、ビットレート一致確率と、推定解像度に対応する累積分布関数以外の関数と、を用いて、各解像度について、ビットレート一致確率となるビットレートを算出する。

例えば、ビットレート情報生成部２０３は、「推定解像度に対応する累積分布関数以外の関数」について逆関数を算出し、当該逆関数にビットレート一致確率を入力して上記ビットレートを算出してもよい。あるいは、ビットレート情報生成部２０３は、「推定解像度に対応する累積分布関数以外の関数」において、ビットレートを可変していき累積分布関数の出力がビットレート一致確率となるビットレートを特定してもよい。

例えば、図８を参照すると、推定解像度が３６０ｐ及び推定ビットレートがＢ１の場合、ビットレート一致確率は「Ｐ１」となる。当該ビットレート一致確率Ｐ１となるビットレートとして、１４４ｐに関してはｂ２が、２４０ｐに関してはｂ３が、それぞれ算出される。

ビットレート情報生成部２０３は、解像度と上記算出されたビットレートを対応付けて「ビットレート情報」を生成する。ビットレート情報生成部２０３は、例えば、図９に示すような情報を「ビットレート情報」として生成する。

ビットレート情報生成部２０３は、当該生成したビットレート情報を記憶部２０６に格納する。

ビットレート情報生成部２０３の動作をまとめると図１０に示すフローチャートのとおりとなる。

ビットレート情報生成部２０３は、推定ビットレートと、記憶部２０６に格納された解像度ごとのビットレートの確率密度関数と、を用いて推定ビットレートに対する各解像度の確率Ｑ（ｒｅｓ）を算出する（ステップＳ１０１）。

ビットレート情報生成部２０３は、上記解像度の確率Ｑ（ｒｅｓ）のうち最大値を取る解像度を特定することで、推定解像度を算出する（ステップＳ１０２）。

ビットレート情報生成部２０３は、推定ビットレート、推定解像度及び解像度ごとのビットレートの累積分布関数を用いてビットレート一致確率を算出する（ステップＳ１０３）。

ビットレート情報生成部２０３は、解像度ごとに、ビットレート一致確率になるビットレートを特定し、解像度と当該ビットレートを対応付けることでビットレート情報を算出する（ステップＳ１０４）。

なお、上記ビットレート一致確率を用いたビットレート情報の生成は以下のような知見に基づく。特定の動画における解像度が、例えば、３６０ｐとすると、当該３６０ｐのビットレートが動画全体の３０％程度に位置するならば、同一動画の他の解像度（１４４ｐ、２４０ｐなど）に関しても同様に３０％程度の位置にビットレートが存在する。例えば、第２の実施形態にて説明に使用する図１４や図１５のビットレート対解像度分布を参照すると、ビットレートが低い動画は解像度を変えても全体の動画のなかで低いビットレートを維持する。同様に、ビットレートが高い動画は解像度を変えても全体の動画の中で高いビットレートを維持する。即ち、図１４や図１５は、動画全体に対して、ある特定の動画の解像度を変えたときのビットレートの位置は維持されることを示す。例えば、動画Ａについて、７２０ｐで動画全体の上位５％の位置のビットレートを示す場合、当該動画Ａの解像度を３６０ｐに変えたときのビットレートは、全動画の３６０ｐのビットレート分布の上位５％位置のビットレートと等しくなるもしくは類似する。

ターゲット解像度決定部２０４は、例えば外部から取得した解像度選択ポリシに基づき、ターゲット解像度を決定する手段である。解像度選択ポリシは、記憶部２０６に格納されている。解像度選択ポリシは、端末１０ごとに用意されてもよいし、各端末１０に共通のポリシが用意されてもよい。端末１０ごとに解像度選択ポリシを用意する場合には、端末１０の識別子（例えば、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレス）と解像度選択ポリシが対応付けられて管理される。

例えば、解像度選択ポリシには「推定解像度（Ｉｎｉｔｉａｌ Ｂｕｒｓｔ時の推定解像度）に対するＮ段階下の解像度をターゲット解像度とする」等が記載されている。ターゲット解像度決定部２０４は、当該記載に基づき推定解像度からＮ段階下げた解像度をターゲット解像度に選択する。

例えば、配信動画が取り得る解像度が「４８０ｐ」、「３６０ｐ」、「２４０ｐ」、「１４４ｐ」であって、推定解像度が「４８０ｐ」、解像度選択ポリシに記載された解像度の下げ幅Ｎが「３」であれば、「１４４ｐ」がターゲット解像度に選択される。

なお、上記「推定解像度に対するＮ段階下の解像度をターゲット解像度とする」は、解像度選択ポリシの一例である。解像度選択ポリシには種々の内容を設定することができる。

例えば、解像度選択ポリシには以下の内容のような内容が含まれていてもよい。

・顧客が指定した解像度
例えば、顧客（端末１０のユーザ）が、キャリアに対して動画配信の際の解像度を指定していた場合には、当該指定された解像度が解像度選択ポリシに記載される。

・スループット制限値に対する最大の解像度
例えば、端末１０のユーザの料金プランよって当該端末１０へのスループットの上限値が決まっている場合には、当該スループットに対応する解像度の最大値が解像度選択ポリシに記載される。

ターゲット解像度決定部２０４は、ターゲット解像度をペーシングレート決定部２０５に通知する。

ペーシングレート決定部２０５は、動画配信サーバ３０から配信された動画を端末１０に転送する際のペーシングレート（スループット、転送レート）を決定する手段である。その際、ペーシングレート決定部２０５は、端末１０にて再生される動画の解像度がターゲット解像度となるようにペーシングレートを決定する。

例えば、ペーシングレート決定部２０５は、下記の式（３）に基づきペーシングレートｘ（ｔ）を決定する。

なお、式（３）に記載されたβは、ターゲット解像度から特定されるビットレート（式（３）のｂｉｔｒａｔｅ ｏｆ ｔａｒｇｅｔ ｒｅｓｏｌｕｔｉｏｎ）に乗算する定数である。定数βは、機械学習等により予め算出することができる。

具体的には、図１１に示すように、プロキシサーバ２４に学習部２０７を設け、当該学習部２０７がβを算出してもよい。

例えば、学習部２０７は、強化学習によりβを決定することができる。

学習部２０７は動画の状態（リクエスト間隔、チャンクサイズ）を観測しつつ、βを変化させる。

βを変化させた結果の動画を観測者が視聴する。

観測者は、視聴した動画がターゲット解像度で再生されていれば、報酬を学習部２０７に与える。観測者は、視聴した動画がターゲット解像度で再生されていなければ、報酬を学習部２０７に与えない。

このように、βの強化学習において、状態空間を観測スループット（リクエスト間隔、チャンクサイズ）に設定し、行動空間をβに設定し、報酬空間をターゲット解像度であるか否かに設定することで、学習部２０７は定数βを決定できる。

上記式（３）に従ったペーシングレートの設定は例示であって、ペーシングレート決定部２０５は、ターゲット解像度の一段上の解像度に対応するビットレートをペーシングレートとしてもよい。

例えば、図９の例では、ターゲット解像度が「１４４ｐ」であれば、ペーシングレート決定部２０５は、解像度１４４ｐの一段上のビットレートｂ３をペーシングレートに選択してもよい。当該ペーシングレートの設定は、ビットレート情報に記載されたターゲット解像度のビットレートをそのままペーシングレートに設定すると、ペーシングレートに十分な余裕がなく、結果的に１段下の解像度にて動画が再生される場合であっても、当初想定したターゲット解像度による動画再生がなされる。

ペーシングレート決定部２０５は、決定したペーシングレートを通信制御部２０１に通知する。

通信制御部２０１は、取得したペーシングレートで動画配信サーバ３０から端末１０へのパケットが転送されるように制御する。

図１２は、第１の実施形態に係る通信制御部２０１によるトラフィック制御の一例を示すフローチャートである。

通信制御部２０１は、パケットを受信する（ステップＳ２０１）。

通信制御部２０１は、付加遅延量を算出する（ステップＳ２０２）。具体的には、通信制御部２０１は、受信パケットのサイズをペーシングレート（目標スループット）で除算することで付加遅延量を計算する。

通信制御部２０１は、受信パケットを端末１０に向けて送信する（ステップＳ２０３）。

通信制御部２０１は、付加遅延量に相当する時間待機する（ステップＳ２０４）。

通信制御部２０１は、動画の再生が終了したか否かを判定する（ステップＳ２０５）。具体的には、通信制御部２０１は、直前にパケットを受信してから所定の時間経過しても次のパケットを受信できない場合に「動画の再生が終了」と判断する。通信制御部２０１は、直前にパケットを受信してから所定の時間以内に次のパケットが受信できた場合に「動画の再生は継続」と判断する。

動画の再生が終了していれば（ステップＳ２０５、Ｙｅｓ分岐）、通信制御部２０１は処理を終了する。動画の再生が終了していなければ（ステップＳ２０５、Ｎｏ分岐）、通信制御部２０１はステップＳ２０１に戻り処理を継続する。

第１の実施形態に係るプロキシサーバ２４の動作をまとめると図１３に示すフローチャートのとおりとなる。

プロキシサーバ２４は、Ｉｎｉｔｉａｌ Ｂｕｒｓｔ時のパケットを受信し、当該受信パケットから動画のビットレートを推定する（ステップＳ０１）。

プロキシサーバ２４は、推定ビットレート、解像度ごとの確率密度関数を用いて動画の解像度を推定する（ステップＳ０２）。

プロキシサーバ２４は、推定ビットレート、推定解像度及び解像度ごとの累積分布関数を用いてビットレート情報を生成する（ステップＳ０３）。

プロキシサーバ２４は、解像度選択ポリシを参照し、ターゲット解像度を決定する（ステップＳ０４）。

プロキシサーバ２４は、ターゲット解像度とビットレート情報を用いてペーシングレートを決定する（ステップＳ０５）。

プロキシサーバ２４は、決定されたペーシングレートに基づきトラフィック制御を実行する（ステップＳ０６）。プロキシサーバ２４は、ターゲット解像度にて動画が再生されるように端末１０に転送されるパケットの流量を調整する。

このように、プロキシサーバ２４は、ステップＳ０４及びＳ０５の処理を実行することで、現在のビットレートではなく、ユーザが動画を視聴するための解像度（ターゲット解像度）に対応したビットレートを特定する。プロキシサーバ２４は、当該特定されたビットレートが実現されるように、動画配信サーバ３０から端末１０に転送されるフローの流量調整（流量制御）を行う。

以上のように、第１の実施形態に係るプロキシサーバ２４は、配信動画のビットレートを推定し、当該推定されたビットレートと事前に用意された解像度ごとの確率密度関数を用いて配信動画の解像度を推定する。プロキシサーバ２４は、推定された動画の品質（推定ビットレート、推定解像度）と解像度ごとの累積分布関数を用いて、配信動画の解像度を変化させた場合の対応するビットレートに関する情報（ビットレート情報）を生成する。また、プロキシサーバ２４は、サービスコントローラ２５等から設定されるポリシ（解像度選択ポリシ）に従い、ターゲット解像度を選択する。プロキシサーバ２４は、ビットレート情報を用いてターゲット解像度を実現するためのビットレートを選択し、当該選択されたビットレートに基づきトラフィック制御を行う。

ここで、上記ターゲット解像度は、ユーザが動画を快適に視聴する環境を提供するという観点から決定される。ユーザが動画再生に不満を持つのは、高画質な動画であってもその再生が不安定な場合であると考えられる。例えば、高画質な動画であっても頻繁に再生が途切れるような場合には、ユーザの体感品質は高くない。対して、多少低画質な動画（解像度が低い動画）であっても安定して再生されると、ユーザは動画を快適に視聴できる。即ち、端末１０に割り当てられた帯域に対して余裕のないビットレートを持つ動画が再生されると、動画品質の変動を引き起こしユーザの体感品質が低下する。つまり、動画品質の変動は、多少の低画質の安定した動画よりも体感品質が低い。

第１の実施形態に係るプロキシサーバ２４は、上記観点に基づき決定されたターゲット解像度にてユーザが動画を視聴できるようにトラフィック制御を行う。そのため、安定した動画の再生環境がユーザに提供される。とりわけ、ＭＶＮＯ（Mobile Virtual Network Operator）のユーザは、時間帯等により通信帯域（可用帯域）が制限されることも少なくない。このようなＭＶＮＯのユーザであっても、低速なネットワーク環境に適した解像度にて動画が安定して再生されるため、動画視聴時の満足度が高くなる。その結果、満足度の高い動画視聴者が増えることによりＭＶＮＯの事業者はより多くの顧客を獲得できるようになる。このように、第１の実施形態では、端末１０の可用帯域の上限まで使用するのではなく、可用帯域に余裕を作ることができるため、端末１０における動画品質が安定する。

また、プロキシサーバ２４によるトラフィック制御により、モバイル通信網２０におけるトラフィック削減効果が得られる。ＭＮＯ（Mobile Network Operator）と契約しているユーザは、料金プランにより月々のデータ使用量の上限が決まっていることも多い。そのような現状では、ＭＮＯのユーザは動画に過度な高品質を要求することが少なくなってきている。第１の実施形態に係るプロキシサーバ２４は、このような実情を鑑みて設定されたターゲット解像度の動画再生を可能とするので、データ使用量を気にかけるユーザに対してデータ使用量を節約しつつ安定した動画を視聴できる環境を提供できる。また、ＭＶＮＯの事業者の観点では、動画再生時のトラフィック量が削減されるので、ＭＮＯから借り受ける回線の使用率が低下し、ＭＮＯに支払うコストが削減できる。

このように、第１の実施形態に係るプロキシサーバ２４は、パケットの中身が暗号化されており動画品質の詳細が知ることができない場合であっても観測可能なビットレートから動画品質（解像度、ビットレート）を判定しトラフィック制御を実施する。その結果、「モバイル通信網２０におけるトラフィック削減効果」と「ユーザに対する安定した動画再生環境を提供」を両立できる。

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

第１の実施形態では、確率密度関数を用いてビットレート情報を算出する場合について説明した。第２の実施形態では、第１の実施形態とは異なる方法でビットレート情報を算出する場合について説明する。

第２の実施形態において、通信システムの構成やプロキシサーバ２４の処理構成は第１の実施形態と同一とすることができるので、図２や図３等に相当する説明を省略する。

図１４は、動画の解像度とビットレートの関係をグラフ化した図である。なお、図１１に示すような解像度とビットレートの関係は予めプロキシサーバ２４に入力されていてもよいし、学習等により生成されてもよい。

図１４を確認すると、解像度が上がれば必要とするビットレートも上昇することが分かる。また、動画が異なれば、ビットレートの上昇率も異なることが分かる。例えば、動きの激しい動画では解像度が上がればビットレートが急上昇する（例えば、図１４の曲線３０１）。対して、静止画に近いような動画では解像度を上げてもビットレートの上昇は緩やかである（例えば、図１４の曲線３０２）。

図１４に示すグラフのＹ軸（ビットレート）の常用対数（１０を底とする対数）を計算すると図１５に示すグラフが得られる。図１５を参照すると、解像度とビットレートの対数値の間には、解像度が増加するとビットレート（対数値）が線形増加することが理解される。当該関係を数式にて表現すると、下記の式（４）が得られる。

図１５を確認すると、各動画の解像度とビットレート（対数）の間には線形な関係が認められ、上記式（４）の関係が成り立つ。さらに、図１５に示す各直線の傾きはほぼ同じであることが理解される。従って、上記式（４）において傾きａは、各動画について共通の値とすることもできる。対して、図１５を確認すると、切片は動画ごとに異なることも理解される。従って、上記式（４）における切片ｂは、動画ごとに異なる値となる。

傾きａに関しては図１５に示す各直線の傾きに関する最小二乗法により算出することができる。具体的には、図１５に示す動画ごとの傾きを最小二乗法により算出され、当該算出された傾きの平均値が上記式（４）の傾きａに設定される。システム管理者等は、図１５に示すようなデータから予め傾きａの平均値を算出し、当該平均値を記憶部２０６に格納しておく。なお、動画ごとの傾きの平均値に代えて、動画ごとの傾きの最頻値や中央値を傾きａとして算出してもよい。

傾きａが算出されると、推定ビットレートを式（４）に示すビットレートに設定し、推定解像度を式（４）に示す解像度に設定すれば、式（４）の切片ｂを求めることができる。

切片ｂが求まると、推定ビットレート及び推定解像度を有する動画の解像度とビットレート（対数）の関係を規定する下記の式（５）が得られる。

式（５）に示すａ_ａｖｅは、上記最小二乗法により算出した傾きの平均値である。また、式（５）に示す切片ｂ_ｍは推定ビットレート及び推定解像度を用いて算出された切片ｂである。

第２の実施形態に係るプロキシサーバ２４のビットレート情報生成部２０３は、上記式（５）に解像度を入力することで当該解像度に対応したビットレートを算出することができる。例えば、ビットレート情報生成部２０３は、解像度として１４４ｐを式（５）に入力し、対応するビットレートを計算する。同様に、ビットレート情報生成部２０３は、２４０ｐを式（５）に入力し、対応するビットレートを計算する。ビットレート情報生成部２０３は、上記の計算を繰り返すこと図９に示すようなビットレート情報を生成することができる。

上記ビットレート情報生成部２０３の動作をまとめると図１６に示すフローチャートのとおりとなる。なお、図１０と図１６に示すフローチャートにおいて同一の処理とすることができる工程（ステップ）には同一の符号を付し説明を省略する。

第２の実施形態においても、確率密度関数を用いて推定解像度を算出する（ステップＳ１０１、Ｓ１０２）。その後、ビットレート情報生成部２０３は、推定ビットレート、推定解像度、動画ごとの解像度対ビットレート分布の片対数から得られる一次関数の傾きの平均値ａ_ａｖｅを用いて切片ｂ_ｍを算出する（ステップＳ１０５）。

ビットレート情報生成部２０３は、式（５）に解像度を入力し、各解像度に対応したビットレートを算出する。ビットレート情報生成部２０３は、解像度とビットレートを対応づけてビットレート情報を生成する（ステップＳ１０６）。

［第２の実施形態の変形例］
上記説明では、解像度とビットレート（対数）の関係が一次関数により近似できることを利用してビットレート情報を生成することを説明した。しかし、図１４に示す解像度とビットレートの関係を直接用いてビットレート情報を生成することもできる。

具体的には、図１４に示す解像度とビットレートの関係は二次関数により近似できる。従って、図１４に示す各曲線は、下記の式（６）のように表記できる。

ビットレート情報生成部２０３は、上記式（６）に推定ビットレート、推定解像度を入力し、定数ｃを得る。ビットレート情報生成部２０３は、得られた定数ｃによりビットレートと解像度の関係を規定する二次関数を得る。その後、ビットレート情報生成部２０３は、得られた二次関数に解像度を可変して入力し、対応するビットレートを計算する。ビットレート情報生成部２０３は、このような計算を繰り返し、図９に示すようなビットレート情報を生成する。

第２の実施形態に係る変形例のビットレート情報生成部２０３の動作をまとめると図１７に示すフローチャートのとおりとなる。なお、図１６と図１７に示すフローチャートにおいて同一の処理とすることができる工程（ステップ）には同一の符号を付し説明を省略する。

図１７に示すように、ビットレート情報生成部２０３は、推定ビットレート、推定解像度を利用して式（６）に示す二次関数を導出する（ステップＳ１０７）。その後、ビットレート情報生成部２０３は、当該二次関数を利用してビットレート情報を算出する（ステップＳ１０８）。

なお、式（５）を用いたビットレート情報の算出であっても、式（６）を用いたビットレートの算出であっても、同程度の精度を持ったビットレートの算出が可能である。式（５）による方法では傾きａを事前に算出するといった準備が必要なのに対し、式（６）による方法ではこのような事前準備は不要である。但し、式（５）による方法は一次関数を用いたビットレートの算出であり、その際の計算量が少ない。対して、式（６）による方法では二次関数を用いたビットレートの算出であり、その際の計算量が多い。どちらの方式にもメリットが存在するため、本願開示の通信システムが運用される環境等に適した方式が選択されればよい。

以上のように、第２の実施形態では、解像度とビットレート（ビットレートの対数値）の関係を一次関数又は二次関数により近似（フィッティング）すると共に、当該一次関数又は二次関数に解像度を可変して入力することでビットレート情報を生成する。第２の実施形態に係るプロキシサーバ２４も第１の実施形態に係るプロキシサーバ２４と同様の効果を奏することができる。

続いて、通信システムを構成する各装置のハードウェアについて説明する。図１８は、プロキシサーバ２４のハードウェア構成の一例を示す図である。

プロキシサーバ２４は、情報処理装置（所謂、コンピュータ）により構成可能であり、図１８に例示する構成を備える。例えば、プロキシサーバ２４は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

但し、図１８に示す構成は、プロキシサーバ２４のハードウェア構成を限定する趣旨ではない。プロキシサーバ２４は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、プロキシサーバ２４に含まれるプロセッサ３１１等の数も図１８の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１がプロキシサーバ２４に含まれていてもよい。

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

プロキシサーバ２４の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

なお、動画配信サーバ３０等もプロキシサーバ２４と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成はプロキシサーバ２４と相違する点はないので説明を省略する。

［変形例］
なお、上記実施形態にて説明した通信システムやプロキシサーバ２４の構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。また、本願開示は、無線のシステムにも有線のシステムにも適用することができる。

上記実施形態では、動画の品質として解像度とビットレートを例に取り説明したが、動画の品質をこれらの例に限定する趣旨ではない。

上記実施形態では、解像度選択ポリシに従って決定されたターゲット解像度に応じてトラフィック制御（流量調整）が行われる場合を説明した。しかし、例えば、ビットレート情報生成部２０３が推定した推定解像度のＮ段階下の解像度相当に流量を調整する制御であってもよい。つまり、現状の解像度から下げる段数を予め定めておいてもよい。このような対応により、ターゲット解像度の決定に要する時間を削減（短縮）することができる。

プロキシサーバ２４は、複数の端末１０に関する一連のトラフィック制御を同時に（並列に）実行する。その際、プロキシサーバ２４は、自装置で扱う複数の動画のうち、推定ビットレートの高い動画を優先してトラフィック制御の対象としてもよい。このような対応により、モバイル通信網２０内のトラフィックを効率的に削減できる。例えば、解像度が７２０ｐ、ビットレートが２Ｍｂｐｓの動画Ａと解像度は同一でビットレートが５００ｋｂｐｓの動画Ｂがプロキシサーバ２４にて処理されていれば、動画Ａの解像度を優先し下げることでトラフィックが効率良く削減できる。このことは、図１４の曲線３０１の動画を動画Ａに、曲線３０２の動画を動画Ｂに設定することで、容易に理解される。図１４を参照すると、同じ解像度であっても、曲線３０１の動画の方が曲線３０２の動画よりも解像度を下げた場合のビットレートの低下率が大きいためである。

プロキシサーバ２４は、複数の動画のうち、解像度変更に伴うビットレートの変化幅が少ない動画を優先してトラフィック制御を行ってもよい。例えば、解像度が７２０ｐの場合のビットレートが２Ｍｂｐｓ、解像度が４８０ｐでビットレートが８００ｋｂｐｓの動画Ａと、解像度が７２０ｐの場合のビットレートが５００ｋｂｐｓ、解像度が４８０ｐでビットレートが３００ｋｂｐｓの動画Ｂの場合を考える。この場合、動画Ｂを優先して解像度を下げる（動画Ｂのトラフィック制御を実施する）ことで、画質の変化が緩やかになりユーザは画質の劣化を認識するのが難しくなる。

プロキシサーバ２４は、内部に目標トラフィック削減量を保持し、当該目標トラフィック削減量に到達するまでトラフィック制御を継続してもよい。換言すれば、プロキシサーバ２４は、目標トラフィック削減量に到達すれば、トラフィック制御を停止してもよい。なお、端末１０の個別のトラフィック削減量は、推定ビットレートからターゲット解像度に対応するビットレートを減算することで算出可能である。プロキシサーバ２４は、各端末１０に関するトラフィック削減量の合計と上記目標トラフィック削減量を比較し、トラフィック制御の実施、不実施を決定すればよい。

あるいは、プロキシサーバ２４は、ビットレートの高い動画から１段階解像度を低下させ、その状態のトラフィック削減量が目標トラフィック削減量に到達していればトラフィック制御を停止してもよい。換言すれば、プロキシサーバ２４は、目標とするトラヒック削減量を達成するまで解像度を落とし続けるような制御を実施してもよい。このような対応により、特定の動画について急激に画質が劣化したとユーザに認識されることを回避できる。

プロキシサーバ２４は、解像度の下限を設定し、当該設定された下限を下回らないようにターゲット解像度を選択してもよい。

プロキシサーバ２４は、各動画の画質（現解像度、ビットレート）をユーザや管理者が確認可能となるように、上記画質に関する情報を端末１０や管理者の制御端末に送信してもよい。端末１０や制御端末は、これらの情報を液晶ディスプレイ等に表示してもよい。

上記実施形態では、送信パケット間の間隔を調整することでスループットを制御しているが、他の方法によりスループットが変更されてもよい。例えば、プロキシサーバ２４が、動画配信パケットに施された圧縮をデコード可能な場合には、プロキシサーバ２４は、圧縮率を変えることでスループットを変更してもよい。

上記実施形態では、式（３）の定数βを決定する際の強化学習において作業者がターゲット解像度で動画が再生されていることを確認している。しかし、端末１０にインストールされた動画再生アプリケーション等を変更することで、定数βの決定における作業者の介在を排除できる。具体的には、定数βの強化学習時には、端末１０は再生動画の解像度をプロキシサーバ２４に通知するようにすればよい。プロキシサーバ２４の学習部２０７は、端末１０から通知された解像度により定数βを決定すればよい。

上記実施形態では、通信システムに含まれる各プロキシサーバ２４がビットレート情報を生成し、自装置で生成したビットレート情報を使ってペーシングレートを決定している。しかし、各プロキシサーバ２４が生成したビットレート情報が共有されてペーシングレートの決定等に使用されても良い。上記説明したように、ロードバランサ２３が、プロキシサーバ２４の負荷分散を行う。当該負荷分散の結果、あるプロキシサーバ２４にて生成したビットレート情報は当該サーバでは不要になり、他のサーバで必要になることがある。このような場合を考慮し、プロキシサーバ２４は、他のプロキシサーバ２４にビットレート情報を送信してもよい。あるいは、プロキシサーバ２４は、生成したビットレート情報をロードバランサ２３に送信し、ロードバランサ２３にてビットレート情報を集中管理してもよい。

あるいは、ロードバランサ２３が、複数のプロキシサーバ２４の制御装置として動作し、時間帯や日付等によりプロキシサーバ２４の動作を変更してもよい。例えば、モバイル通信網２０に流れるデータ量が急増するような時間帯には、プロキシサーバ２４に対してターゲット解像度を低く設定するように指示をし、データ量が少ないような時間帯にはトラフィック制御自体を不実施とするような指示をしてもよい。

上記実施形態では、プロキシサーバ２４が、受信パケットを送信する際に所定時間待機することでトラフィック制御を実現している。即ち、プロキシサーバ２４は、ペーシングレートを超えたパケットをバッファ（メモリ）に格納し、当該バッファに格納されたパケットを所定時間後に送信するシェーピングとも称される流量制御を行っている。しかし、プロキシサーバ２４は、他の流量制御を行うことも可能である。例えば、プロキシサーバ２４は、ポリシングと称されるトラフィック制御を実行してもよい。この場合、ペーシングレートを超えたパケットは破棄される。

上記実施形態にて説明したプロキシサーバ２４には、プロセッサ、メモリ等を備える計算機（情報処理装置）が想定される。あるいは、プロキシサーバ、１つのコンピュータ上に複数のコンピュータをエミュレートする仮想マシンであってもよい。即ち、上記プロキシサーバは、サーバ等の計算機（物理マシン）であってもよいし、仮想マシンであってもよい。

モバイル通信網２０は、物理的に複数の装置（ノード）によって構成されていてもよく、物理的に１台の装置によって構成されていてもよい。例えば、後者の場合、通信ネットワーク機能を仮想化し、汎用のサーバで当該機能を実現するＮＦＶ（Network Functions Virtualization）を用いてモバイル通信網２０が構築されてもよい。

上記実施形態では、プロキシサーバ２４にてトラフィック制御を実行する場合について説明したが、他の装置にて上記トラフィック制御が実行されてもよい。具体的には、上記説明した処理モジュールが端末１０、ルータ２１又は２２、ロードバランサ２３、動画配信サーバ３０に実装されていてもよい。

上記説明したプロキシサーバ２４の機能の一部が他の装置により実現されてもよい。例えば、クラウド上のサーバにてペーシングレートを決定する機能が実現されてもよい。

上述の説明で用いた複数のフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定し、
前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出すること、
を含む通信制御方法。
［付記２］
前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行うことを含む、付記１に記載の通信制御方法。
［付記３］
複数の配信動画の解像度に関する統計情報を用いて、前記第１の解像度を推定する、付記１又は２に記載の通信制御方法。
［付記４］
前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定し、
前記第２のビットレートと前記統計情報を用いて前記第１の解像度を推定する、付記３に記載の通信制御方法。
［付記５］
前記第２の解像度と前記第１のビットレートの対応情報に基づき前記第１のビットレートを決定することを含む、付記４に記載の通信制御方法。
［付記６］
配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定部（１０１）と、
前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出部（１０２）と、
を備える通信装置（２４、１００）。
［付記７］
前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行う、制御部（２０１）をさらに備える、付記６に記載の通信装置（２４、１００）。
［付記８］
前記第１の推定部（１０１）は、複数の配信動画の解像度に関する統計情報を用いて、前記第１の解像度を推定する、付記６又は７に記載の通信装置（２４、１００）。
［付記９］
前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定する、第２の推定部（２０２）をさらに含み、
前記第１の推定部（１０１）は、前記第２のビットレートと前記統計情報を用いて前記第１の解像度を推定する、付記８に記載の通信装置（２４、１００）。
［付記１０］
前記第２の解像度と前記第１のビットレートの対応情報に基づき前記第１のビットレートを決定する、決定部（２０５）をさらに備える、付記９に記載の通信装置（２４、１００）。
［付記１１］
端末（１０）と、
前記端末（１０）に動画を配信する、動画配信サーバ（３０）と、
前記端末（１０）と前記動画配信サーバ（３０）の間の通信を中継する、通信装置（２４、１００）と、
を含み、
前記通信装置（２４、１００）は、
配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定部（１０１）と、
前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出部と、
を備える、通信システム。
［付記１２］
前記通信装置（２４、１００）は、
前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行う、制御部をさらに備える、付記１１に記載の通信システム。
［付記１３］
前記第１の推定部（１０１）は、複数の配信動画の解像度に関する統計情報を用いて、前記第１の解像度を推定する、付記１１又は１２に記載の通信システム。
［付記１４］
前記通信装置（２４、１００）は、前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定する、第２の推定部をさらに含み、
前記第１の推定部（１０１）は、前記第２のビットレートと前記統計情報を用いて前記第１の解像度を推定する、付記１３に記載の通信システム。
［付記１５］
前記通信装置（２４、１００）は、前記第２の解像度と前記第１のビットレートの対応情報に基づき前記第１のビットレートを決定する、決定部をさらに備える、付記１４に記載の通信システム。
［付記１６］
動画配信サーバ（３０）から配信されている配信動画のビットレートを推定する、ビットレート推定部（２０２）と、
前記配信動画の解像度を可変した場合における、解像度と前記解像度が可変された動画が端末（１０）で再生されるためのビットレートを対応付けたビットレート情報を生成する、ビットレート情報生成部（２０３）と、
前記端末（１０）で再生される動画の解像度の決定に関するポリシを定めた、解像度選択ポリシに基づき、ターゲット解像度を決定する、ターゲット解像度決定部（２０４）と、
少なくとも前記ビットレート情報と前記ターゲット解像度に基づき、前記動画配信サーバ（３０）から前記端末（１０）に向けて送信されたパケットを転送する際のペーシングレートを決定する、ペーシングレート決定部（２０５）と、
を備える、通信装置（２４、１００）。
［付記１７］
前記決定されたペーシングレートに基づき、前記動画配信サーバ（３０）から前記端末（１０）に向けたトラフィックを制御する、通信制御部をさらに備える、付記１６に記載の通信装置（２４、１００）。
［付記１８］
前記ビットレート情報生成部（２０３）は、
前記推定されたビットレートと、ビットレートが確率変数に設定された、解像度ごとの確率密度関数と、を用いて、前記配信動画の解像度を推定し、
前記推定されたビットレート、前記推定された解像度、及び、解像度ごとのビットレートの累積分布関数を用いて、前記ビットレート情報を生成する、付記１７に記載の通信装置（２４、１００）。
［付記１９］
前記ビットレート情報生成部（２０３）は、解像度とビットレートの対数値の関係を一次関数により近似すると共に、前記一次関数に解像度を可変して入力することで対応するビットレートを算出し、前記ビットレート情報を生成する、付記１７に記載の通信装置（２４、１００）。
［付記２０］
前記ビットレート情報生成部（２０３）は、解像度とビットレートの関係を二次関数により近似すると共に、前記二次関数に解像度を可変して入力することで対応するビットレートを算出し、前記ビットレート情報を生成する、付記１７に記載の通信装置（２４、１００）。
［付記２１］
前記ペーシングレート決定部（２０５）は、前記ビットレート情報を参照し、前記ターゲット解像度に対応するビットレートを特定すると共に、前記特定されたビットレートに所定の定数を乗算した結果を前記ペーシングレートとする、付記１６乃至２０のいずれか一つに記載の通信装置（２４、１００）。
［付記２２］
前記定数は、状態空間が動画の観測スループットに設定され、行動空間が前記定数に設定され、報酬空間が前記ターゲット解像度に設定された、強化学習により算出される、付記２１に記載の通信装置（２４、１００）。
［付記２３］
通信装置（２４、１００）において、
動画配信サーバ（３０）から配信されている配信動画のビットレートを推定するステップと、
前記配信動画の解像度を可変した場合における、解像度と前記解像度が可変された動画が端末（１０）で再生されるためのビットレートを対応付けたビットレート情報を生成するステップと、
前記端末（１０）にて動画を再生する際のポリシを定めた、解像度選択ポリシに基づき、ターゲット解像度を決定するステップと、
少なくとも前記ビットレート情報と前記ターゲット解像度に基づき、前記動画配信サーバ（３０）から前記端末（１０）に向けて送信されたパケットを転送する際のペーシングレートを決定するステップと、
を含む、通信方法。
［付記２４］
通信装置（２４、１００）に搭載されたコンピュータ（３１１）に、
動画配信サーバ（３０）から配信されている配信動画のビットレートを推定する処理と、
前記配信動画の解像度を可変した場合における、解像度と前記解像度が可変された動画が端末（１０）で再生されるためのビットレートを対応付けたビットレート情報を生成する処理と、
前記端末（１０）にて動画を再生する際のポリシを定めた、解像度選択ポリシに基づき、ターゲット解像度を決定する処理と、
少なくとも前記ビットレート情報と前記ターゲット解像度に基づき、前記動画配信サーバ（３０）から前記端末（１０）に向けて送信されたパケットを転送する際のペーシングレートを決定する処理と、
を実行させるプログラム。
なお、付記２３の形態及び付記２４の形態は、付記１６の形態と同様に、付記１７の形態～付記２２の形態に展開することが可能である。

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。

１０ 端末
２０ モバイル通信網
２１、２２ ルータ
２３ ロードバランサ
２４ プロキシサーバ
２５ サービスコントローラ
２６ ポリシ及び課金ルールサーバ
２７ ログ収集サーバ
２８ ログ表示サーバ
３０ 動画配信サーバ
１００ 通信装置
１０１ 第１の推定部
１０２ 算出部
２０１ 通信制御部
２０２ ビットレート推定部
２０３ ビットレート情報生成部
２０４ ターゲット解像度決定部
２０５ ペーシングレート決定部
２０６ 記憶部
２０７ 学習部
３０１、３０２ 曲線
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス

Claims (12)

1. 配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定することと、
   前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出することと、
   前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定することと、
   前記第２のビットレートを、複数の配信動画の解像度に関する確率密度関数に入力することにより、前記第１の解像度を推定することと、
   を含む通信制御方法。
2. 前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行うことを含む、請求項１に記載の通信制御方法。
3. 前記第２のビットレートと、前記第１の解像度と、複数の配信動画の解像度に関する累積分布関数とを用いて、動画の解像度と、当該解像度が端末で再生されるためのビットレートとを対応付けた情報であるビットレート情報を生成する、請求項１又は２に記載の通信制御方法。
4. 前記第２の解像度と、前記ビットレート情報とに基づき前記第１のビットレートを決定することを含む、請求項３に記載の通信制御方法。
5. 配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定手段と、
   前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定する、第２の推定手段と、
   前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出手段と、
   を備え、
   前記第１の推定手段は、前記第２のビットレートを、複数の配信動画の解像度に関する確率密度関数に入力することにより、前記第１の解像度を推定する、
   通信装置。
6. 前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行う、制御手段をさらに備える、請求項５に記載の通信装置。
7. 前記第１の推定手段は、前記第２のビットレートと、前記第１の解像度と、複数の配信動画の解像度に関する累積分布関数とを用いて、動画の解像度と、当該解像度が端末で再生されるためのビットレートとを対応付けた情報であるビットレート情報を生成する、請求項５又は６に記載の通信装置。
8. 前記第２の解像度と、前記ビットレート情報とに基づき前記第１のビットレートを決定する、決定手段をさらに備える、請求項７に記載の通信装置。
9. 端末と、
   前記端末に動画を配信する、動画配信サーバと、
   前記端末と前記動画配信サーバの間の通信を中継する、通信装置と、
   を含み、
   前記通信装置は、
   配信動画のトラフィックに基づいて前記配信動画の第１の解像度を推定する、第１の推定手段と、
   前記配信動画の再生に関するリクエストに基づき前記配信動画の第２のビットレートを推定する、第２の推定手段と、
   前記第１の解像度に基づいて前記配信動画を第２の解像度で配信するための第１のビットレートを算出する、算出手段と、
   を備え、
   前記第１の推定手段は、前記第２のビットレートを、複数の配信動画の解像度に関する確率密度関数に入力することにより、前記第１の解像度を推定する、
   通信システム。
10. 前記通信装置は、
    前記第１のビットレートに基づき、前記配信動画のトラフィック制御を行う、制御手段をさらに備える、請求項９に記載の通信システム。
11. 前記第１の推定手段は、前記第２のビットレートと、前記第１の解像度と、複数の配信動画の解像度に関する累積分布関数とを用いて、動画の解像度と、当該解像度が前記端末で再生されるためのビットレートとを対応付けた情報であるビットレート情報を生成する、請求項９又は１０に記載の通信システム。
12. 前記通信装置は、前記第２の解像度と、前記ビットレート情報とに基づき前記第１のビットレートを決定する、決定手段をさらに備える、請求項１１に記載の通信システム。
    

Images