JP2022122064A - 配信サーバ、配信システム及び配信プログラム - Google Patents

Abstract

【課題】ビットレートが互いに異なる動画を視聴する端末が複数存在する場合に、端末全体のサービス品質を向上できる配信システムを提供すること。【解決手段】配信サーバ１０は、複数の視聴端末３０から、セグメントのリクエストを受信するリクエスト受信部１１と、複数の視聴端末３０からリクエストされたセグメントそれぞれのビットレートの相互比較結果に基づいて、最高のビットレートのセグメントの優先度を最大値とし、かつ、ビットレートが低いセグメントほど優先度を小さく決定するＴｏＳ値計算部１４と、優先度を示すデータをヘッダに格納したセグメントデータのパケットを、当該優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチ２１へ送出するデータ送出部１６と、を備える。【選択図】図３

Description

本発明は、複数の視聴端末への動画配信システムに関する。

インターネットなどのパケット交換方式のネットワークは、ベストエフォートな回線であり、ネットワーク中を流れるトラフィックに応じて受信端末のスループットが変動することが知られている。このため、ＶｏＩＰなどのリアルタイム性が重視されるサービスでは、優先制御（ＱｏＳ）を利用することにより、受信端末に対して一定レートの通信帯域を確保することでサービスの安定性を担保している。
また、特許文献１及び２では、重要度の高い動画像データ又は再送データに対して、フレーム単位で優先度を付加することによる高品質な配信手法が提案されている。

ところで、動画配信では、動画のビットレートに対してスループットが十分な場合、視聴バッファが増加することで動画の安定性が確保されるが、スループットが十分でない場合は、視聴バッファが枯渇しリバッファリングが発生する。
そこで、現在のＯＴＴ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ）でのストリーミング動画配信は、ＭＰＥＧ－ＤＡＳＨを始めとするＨＴＴＰ ＡＢＲ（Ａｄａｐｔｉｖｅ－Ｂｉｔ－Ｒａｔｅ）方式を利用した配信が主流となっている。ＡＢＲとは、同じ動画コンテンツに対してビットレートの異なる複数の品質の動画ストリームを用意し、それぞれを一定時間ごとに区切られたセグメントと呼ばれる単位に分割することで、品質を切り替えながらシームレスに視聴することが可能な技術である。このことにより、視聴端末が現在のネットワーク状況に対して適切な品質のセグメントを選択することで、動画再生のフリーズを抑制しつつ、ネットワーク状況に応じて高品質な動画を視聴することが可能となる。

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

ＭＰＥＧ－ＤＡＳＨなど、通信プロトコルにＨＴＴＰを利用した動画配信方式では、トランスポート層にＴＣＰを利用していることから、帯域が限られたネットワークにおいて、全体の帯域に対し視聴端末ごとにスループットが等分される。これは、ＴＣＰの設計思想上の特性であり、帯域を公平利用する観点において最適化されている。しかしながら、動画配信においてスループットが等分されることは、視聴端末全体のサービス品質（ＱｏＥ）の観点から課題となっていた。

例えば、視聴端末数に対して配信帯域が十分に確保されていない動画配信において、互いに異なるビットレートの動画を視聴する端末が複数存在すると、ビットレートが低い動画を視聴する端末は、再生バッファが貯まりやすく安定視聴が可能となるが、ビットレートの高い動画を視聴する端末は、再生バッファが貯まりにくいためフリーズが発生しやすい。
このような状況下においては、ビットレートに応じた端末ごとの帯域の割り当てが必要となるが、単純にビットレート分の帯域制限を端末ごとに実施すると、配信帯域が十分な場合は配信帯域に無駄が生じてしまい、逆に配信帯域が不十分な場合はビットレートの比率に応じた帯域制限とならない。つまり、帯域を有効利用した上で、トラフィック状況によらずビットレートの比率に応じた配信制御をどのように実施するかが課題となっていた。

また、ＡＢＲ配信で利用する動画のエンコード方式が完全なＣＢＲ（Ｃｏｎｓｔａｎｔ Ｂｉｔ Ｒａｔｅ）でない場合、同じ品質のストリーム内であっても、セグメント単位でビットレートが異なるため、セグメント単位での動的な帯域の割り当てをどのように実現するかが課題となっていた。

特許文献１及び２の手法では、動画データフレーム又は再送パケットの重要度に着目した優先処理を行っているが、いずれも、自端末のビットレートと他端末のビットレートとの関係に着目し優先度を決めるといったことはなされていないため、これらの課題を解決できるものではなかった。

本発明は、ビットレートが互いに異なる動画を視聴する端末が複数存在する場合に、端末全体のサービス品質を向上できる配信システムを提供することを目的とする。

本発明に係る配信サーバは、複数の視聴端末から、セグメントのリクエストを受信するリクエスト受信部と、前記複数の視聴端末からリクエストされたセグメントそれぞれのビットレートの相互比較結果に基づいて、最高のビットレートのセグメントの優先度を最大値とし、かつ、ビットレートが低いセグメントほど優先度を小さく決定する優先度計算部と、前記優先度を示すデータをヘッダに格納したセグメントデータのパケットを、当該優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチへ送出するデータ送出部と、を備える。

前記配信サーバは、前記データ送出部によるパケットの送出後、所定時間の間に前記リクエスト受信部が受信したリクエストのセグメント情報を、前記優先度計算部へ通知するリクエスト管理部を備えてもよい。

前記リクエスト管理部は、前記データ送出部によるパケットの送出後、当該パケットのセグメントをリクエストした前記複数の視聴端末の全てから次のリクエストを受信すると、経過時間に関わらず、前記リクエスト受信部が受信したリクエストのセグメント情報を、前記優先度計算部へ通知してもよい。

前記優先度計算部は、ビットレートの最大値に対する割合に応じて、複数の優先度のいずれかを決定してもよい。

本発明に係る配信システムは、前記配信サーバと、前記優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチと、動画データのセグメントを、シーケンシャルに前記配信サーバにリクエストする複数の視聴端末を備える。

前記視聴端末は、前記セグメントのうち、ダウンロードの完了した部分から順に再生バッファに追加してもよい。

本発明に係る配信プログラムは、前記配信サーバとしてコンピュータを機能させるためのものである。

本発明によれば、ビットレートが互いに異なる動画を視聴する端末が複数存在する場合に、端末全体のサービス品質を向上できる。

実施形態における配信システムの全体構成、及び動画の配信フローを示す図である。 実施形態におけるセグメントの優先度の定義を例示する図である。 実施形態における配信サーバの機能構成を示す図である。 実施形態における配信サーバの処理フローを示す図である。

以下、本発明の実施形態の一例について説明する。
図１は、本実施形態における配信システム１の全体構成、及び動画の配信フローを示す図である。

配信システム１は、動画の配信サーバ１０、配信サーバ１０に接続された優先制御（ＱｏＳ）機能を持つスイッチ２１、スイッチ２１に接続されたスイッチ２２、スイッチ２２に接続された視聴端末３０群で構成される。
このとき、スイッチ２１とスイッチ２２との間にトラフィックが集中することから、視聴端末３０群においてスイッチ２１－スイッチ２２間がネットワークのボトルネックリンクであるとする。その他のリンクの帯域は十分あるものとする。

なお、配信サーバ１０、及び配信サーバ１０とスイッチ２１との間のリンクのトラフィック分散のため、配信サーバ１０は複数設けられてもよい。また、配信サーバ１０には、互いに品質が異なる複数の動画データが一定の時間（例えば２秒）ごとに区切られたセグメント単位で格納されているものとする。

まず、各視聴端末３０は、視聴する動画データのセグメントを、シーケンシャルに配信サーバ１０に対してリクエストを行う（１）。このリクエストのタイミングは任意だが、一般的に、前回のセグメントの受信が完了した時点である。

配信サーバ１０は、リクエストされたセグメントのビットレートに応じて、後述の優先度を算出し（２）、セグメントごとに、このセグメントを送信するＩＰパケットへそれぞれの優先度をマーキングする（３）。また、配信サーバ１０が複数台ある場合は、送信タイミングの同期が実施される（４）。

配信サーバ１０が一斉に優先度付きセグメントの送出を開始すると（５）、スイッチ２１は、ＩＰパケットの優先度に基づき優先制御を実行する（６）。

本実施形態では、スイッチ２１が実行する優先制御として、フローベースのＷＦＱ（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｅｉｎｇ）を利用した一例を示す。
ＷＦＱでは、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコルタイプ、ＴｏＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールドの情報をもとに、スイッチ２１がフローを分類し、フローごとに動的にキューを作成する。そして、スイッチ２１は、ＩＰパケットのヘッダの一部であるＴｏＳフィールドに格納されたＩＰ Ｐｒｅｃｅｄｅｎｃｅ値により、キューの重みを変更し、重みに応じてキュー内のパケットの送出順をスケジューリングし、送出量を決定する。

図２は、本実施形態におけるセグメントの優先度の定義を例示する図である。
ここでは、８ビットのＴｏＳフィールドの値（以下、ＴｏＳ値）、及びそのうちの上位３ビットで表されるＩＰ Ｐｒｅｃｅｄｅｎｃｅと、重みとの対応関係を示している。
なお、この対応関係は一例であり、スイッチ２１の実装違いにより異なるバリエーションがあり得る。

優先度を示すＩＰ Ｐｒｅｃｅｄｅｎｃｅは、０から７の整数値をとり、重みは、例えば、２^１５／（ＩＰ Ｐｒｅｃｅｄｅｎｃｅ＋１）で算出される。
スイッチ２１は、この重みに反比例した優先処理を行う。例えば、送出リンクの帯域が５Ｍｂｐｓのとき、次のように、フローそれぞれの重みに対して割当てられる帯域が決定される。
・フロー１（重み：１０９２０、帯域：３Ｍｂｐｓ）
・フロー２（重み：３２７６８、帯域：１Ｍｂｐｓ）
・フロー３（重み：３２７６８、帯域：１Ｍｂｐｓ）

なお、スイッチ２１の優先制御は、このように、セグメントデータが格納されたＩＰパケットのＴｏＳ値に応じてパケットの処理優先度を決定するものであるが、その手法は、ＷＦＱには限られない。

図３は、本実施形態における配信サーバ１０の機能構成を示す図である。
配信サーバ１０は、制御部及び記憶部の他、各種のインターフェースを備えた情報処理装置であり、記憶部に格納されたソフトウェア（配信プログラム）を制御部が実行することにより、本実施形態の各種機能が実現される。

配信サーバ１０の制御部は、リクエスト受信部１１と、リクエスト管理部１２と、データ情報管理部１３と、ＴｏＳ値計算部１４（優先度計算部）と、データストア部１５と、データ送出部１６とを備える。

リクエスト受信部１１は、複数の視聴端末３０からのセグメントのリクエストを受信し、リクエスト管理部１２にリクエスト情報を登録する。

リクエスト管理部１２は、リクエスト情報として、現在までにセグメントを未送出の今回のリクエストと、データ送出部１６により前回送出したセグメント分のリクエストを管理し、データストア部１５に、現在のリクエスト情報を通知する。

また、リクエスト管理部１２は、データ送出部１６からの送出完了通知を受けた後、所定時間（例えば、１００ｍｓ）を計時するタイマをセットする。リクエスト管理部１２は、タイマがタイムアウトになるか、又は前回リクエストがありセグメントを送出した全ての視聴端末３０から今回のリクエストを受信すると、保持している今回のリクエストのセグメント情報をＴｏＳ値計算部１４に通知する。このとき、タイマがセットされていた場合は解除される。

データ情報管理部１３は、視聴端末３０からリクエストされ得る全てのセグメントのビットレート情報を保持し、ＴｏＳ値計算部１４から要求されたビットレート情報をＴｏＳ値計算部１４に通知する。

ＴｏＳ値計算部１４は、視聴端末３０からリクエストされたセグメントのビットレート情報をデータ情報管理部１３に要求し、ビットレート情報の相互比較結果に基づいて、ＩＰヘッダに付加するＴｏＳ値を計算する。ＴｏＳ値計算部１４は、計算結果をデータ送出部１６に通知する。
このとき、ＴｏＳ値計算部１４は、今回のリクエストに含まれる最高のビットレートのセグメントの優先度を最大値とし、かつ、ビットレートが低いセグメントほど優先度を小さく決定したうえで、この優先度に対応するＴｏＳ値を計算する。例えば、ＴｏＳ値計算部１４は、ビットレートの最大値に対する割合に応じて、複数の優先度のいずれかを決定してよい。

ここで、前述した優先度であるＩＰ Ｐｒｅｃｅｄｅｎｃｅと、対応するＴｏＳ値の決定方法について例を示す。
視聴端末３０からのリクエストの中で最もビットレートの高いセグメントのビットレートをＢＲ_ｍａｘとし、ＴｏＳ値計算部１４は、このセグメントに付与するＩＰ Ｐｒｅｃｅｄｅｎｃｅを最も優先度の高い７に決定する。
また、ＢＲ_ｂａｓｅ＝ＢＲ_ｍａｘ／８とし、今回リクエストがあった各セグメントのビットレート、及び付与するＩＰ Ｐｒｅｃｅｄｅｎｃｅを、それぞれＢＲ_ｉ、ＩＰＰ_ｉとする。なお、ｉは、リクエスト順にシーケンシャルに付けられる識別番号である。

ＴｏＳ値計算部１４は、各セグメントに付与するＩＰ Ｐｒｅｃｅｄｅｎｃｅを、ガウス記号［］を用いて、
ＩＰＰ_ｉ＝ｍａｘ（［（ＢＲ_ｉ／ＢＲ_ｂａｓｅ）＋０．５］－１，０）
と決定する。なお、０＜ＢＲ_ｉ＜ＢＲ_ｍａｘとなることから、０≦ＩＰＰ_ｉ≦７となる。
算出されたＩＰＰ_ｉに対応するＴｏＳ値＝ＩＰＰ_ｉ×３２を、送出するセグメントのＩＰヘッダ内のＴｏＳフィールドに格納することで、ビットレートに応じた優先度を与えることができる。

データストア部１５は、リクエスト管理部１２から通知されたリクエストに対応するセグメントデータをデータ送出部１６に転送する。

データ送出部１６は、ＴｏＳ値計算部１４で計算されたＴｏＳ値をＩＰパケットのヘッダに格納し、セグメントデータのＩＰパケットをスイッチ２１へ送出する。

配信サーバ１０は、これらの各機能部を動作させることにより、動画再生中の視聴端末３０全てから、あるいはタイマが満了するまでのリクエストを取得すると、それぞれに該当するセグメントのビットレート情報を参照し、ビットレートの比率に基づき各視聴端末ごとに優先度を算出する。
そして、配信サーバ１０は、送出するセグメントのＩＰパケットに対して、ＩＰヘッダのＴｏＳフィールドに、スイッチ２１の優先制御（ＱｏＳ）機能に適合し優先度に応じたＴｏＳ値をマーキングして一斉に送出を開始する。
これにより、セグメントのビットレートの比率に応じて、各視聴端末３０への帯域の割当がセグメント単位で可能となる。

各視聴端末３０は、セグメントのダウンロード完了後にセグメントデータを再生バッファに追加するのではなく、セグメントのダウンロード中であっても、ダウンロードの完了した部分から順に断片的に再生バッファに追加していく。この処理は、例えばＷｅｂでは、Ｆｅｔｃｈ ＡＰＩを利用することにより可能である。
断片的に再生バッファを追加すること、及び帯域がセグメントのビットレートの比率に応じて割り当てられることの２点の効果により、複数の視聴端末３０の間で再生バッファの蓄積量の差を最小化することで、サービス全体としてのバッファの枯渇リスクが最小化される。

図４は、本実施形態における配信サーバ１０の処理フローを示す図である。
本処理（ステップＳ１～Ｓ６のサイクル）は、配信システム１のサービスが開始されると、繰り返し実行され、サービスの終了まで常にリクエストの待ち受け状態となる。

ステップＳ１において、リクエスト管理部１２は、タイマ（例えば、１００ｍｓ）をセットする。

ステップＳ２において、リクエスト管理部１２は、タイマがタイムアウトになるか、又は前回分の送出を行った全ての端末からのリクエストを受信するまで待機する。なお、前回リクエストが無く、新規リクエストが１つでもあった場合、処理は直ちにステップＳ３へ遷移する。

ステップＳ３において、リクエスト管理部１２は、リクエストがあったか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ４に移り、判定がＮＯの場合、処理はステップＳ１に戻る。

ステップＳ４において、ＴｏＳ値計算部１４は、現在のリクエストに該当するセグメントに付与するためのＴｏＳ値を計算する。現在のリクエストとは、ステップＳ３までに受信し、該当のセグメントを未送出のリクエストであり、これ以降に受信したリクエストは次回送出分のリクエストとして管理される。

ステップＳ５において、データ送出部１６は、セグメントデータを含むＩＰパケットのＩＰヘッダに該当のＴｏＳ値を格納し、現在のリクエストに対応したＩＰパケットの送出を開始する。

ステップＳ６において、データ送出部１６は、現在のリクエストに対応するＩＰパケットの送出を全て完了すると、リクエスト管理部１２に送出完了通知を行う。これにより、現在のリクエストに対応した１サイクルが終了する。

なお、この処理例では、ステップＳ２において、新規のリクエストに対して直ちにステップＳ３へ遷移することとしたが、タイムアウトまで待機してもよい。
また、例えば、視聴端末３０での処理の遅延、又はセグメントの長さ（時間）の違いなどによって、タイムアウトまでに受信されなかったリクエストは、次回のサイクルで処理され、１サイクルごとに複数のリクエストに該当するセグメントが同期して視聴端末３０へ送出される。

本実施形態によれば、配信サーバ１０は、複数の視聴端末からリクエストされたセグメントそれぞれのビットレートの相互比較結果に基づいて、最高のビットレートのセグメントの優先度を最大値とし、かつ、ビットレートが低いセグメントほど優先度を小さく決定し、この優先度を示すデータをヘッダに格納したセグメントデータのパケットを、優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチへ送出する。

したがって、配信サーバ１０は、ビットレートが互いに異なる動画を視聴する視聴端末３０が複数存在する場合において、通信帯域をビットレートに応じて配分することで、動画セグメントごとのダウンロード進捗率を同期させることができる。この結果、動画配信サービス全体として、動画視聴時のフリーズを抑制してサービス品質を向上させることができる。
また、エンコード方式が完全なＣＢＲではなく、同じコンテンツの時系列セグメントのビットレートが異なる場合においても、配信サーバ１０は、セグメント単位で優先度を設定するため、動画のダウンロード進捗率を同期させることが可能となる。

配信サーバ１０は、パケットの送出後、所定時間の間に受信したリクエストのセグメント情報を比較することで、視聴端末３０ごとに通信帯域をビットレートに応じて適切に配分できる。

また、配信サーバ１０は、パケットの送出後、当該パケットのセグメントをリクエストした複数の視聴端末の全てから次のリクエストを受信すると、経過時間に関わらず、これらのリクエストのセグメント情報に基づいて優先度を計算する。
したがって、配信サーバ１０は、シーケンシャルなセグメントのリクエストを、待機時間を低減して効率的に処理することができる。

配信サーバ１０は、ビットレートの最大値に対する割合に応じて、複数の優先度のいずれかを決定する。
これにより、配信サーバ１０は、複数の視聴端末３０に対して通信帯域を無駄なく効率的に配分することができる。

視聴端末３０は、セグメントのうち、ダウンロードの完了した部分から順に再生バッファに追加する。
これにより、再生バッファに追加されるまでの待ち時間が短縮され、視聴端末３０の間でのバッファ量の差が縮小し、サービス全体としてのサービス品質が向上する。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、前述の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施形態に記載されたものに限定されるものではない。

本実施形態では、主に配信システム１の構成と動作について説明したが、本発明はこれに限られず、各構成要素を備え、動画を配信するための方法、又はプログラムとして構成されてもよい。

さらに、配信システム１の機能を実現するためのプログラムをコンピュータで読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。

ここでいう「コンピュータシステム」とは、ＯＳや周辺機器などのハードウェアを含むものとする。また、「コンピュータで読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭなどの可搬媒体、コンピュータシステムに内蔵されるハードディスクなどの記憶装置のことをいう。

さらに「コンピュータで読み取り可能な記録媒体」とは、インターネットなどのネットワークや電話回線などの通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでもよい。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

１ 配信システム
１０ 配信サーバ
１１ リクエスト受信部
１２ リクエスト管理部
１３ データ情報管理部
１４ ＴｏＳ値計算部（優先度計算部）
１５ データストア部
１６ データ送出部
２１ スイッチ
２２ スイッチ
３０ 視聴端末

Claims (7)

1. 複数の視聴端末から、セグメントのリクエストを受信するリクエスト受信部と、
   前記複数の視聴端末からリクエストされたセグメントそれぞれのビットレートの相互比較結果に基づいて、最高のビットレートのセグメントの優先度を最大値とし、かつ、ビットレートが低いセグメントほど優先度を小さく決定する優先度計算部と、
   前記優先度を示すデータをヘッダに格納したセグメントデータのパケットを、当該優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチへ送出するデータ送出部と、を備える配信サーバ。
2. 前記データ送出部によるパケットの送出後、所定時間の間に前記リクエスト受信部が受信したリクエストのセグメント情報を、前記優先度計算部へ通知するリクエスト管理部を備える請求項１に記載の配信サーバ。
3. 前記リクエスト管理部は、前記データ送出部によるパケットの送出後、当該パケットのセグメントをリクエストした前記複数の視聴端末の全てから次のリクエストを受信すると、経過時間に関わらず、前記リクエスト受信部が受信したリクエストのセグメント情報を、前記優先度計算部へ通知する請求項２に記載の配信サーバ。
4. 前記優先度計算部は、ビットレートの最大値に対する割合に応じて、複数の優先度のいずれかを決定する請求項１から請求項３のいずれかに記載の配信サーバ。
5. 請求項１から請求項４のいずれかに記載の配信サーバと、
   前記優先度に基づいて通信帯域を割り当てる優先制御機能を有するスイッチと、
   動画データのセグメントを、シーケンシャルに前記配信サーバにリクエストする複数の視聴端末を備えた配信システム。
6. 前記視聴端末は、前記セグメントのうち、ダウンロードの完了した部分から順に再生バッファに追加する請求項５に記載の配信システム。
7. 請求項１から請求項４のいずれかに記載の配信サーバとしてコンピュータを機能させるための配信プログラム。

Images