JP4496987B2 - コンテンツ送信サーバ、システム及びサーバプログラム - Google Patents

Description

本発明は、同一コンテンツを多数の受信端末に同時に送信するコンテンツ送信に関し、例えば、インターネットによる放送型の映像配信等に適用されるものである。

インターネットプロトコル（ＩＰ）による通信網（以下ＩＰ網という。）を利用して、複数端末へ同一コンテンツを同時に配信するサービス、例えば、放送型の映像配信サービスを提供するためには、コンテンツを送信する送信サーバは、コンテンツのデータ送信速度の制限について考慮する必要がある。すなわち、受信端末の受信バッファ長は有限であるため、受信データの復号速度又は再生速度より速い速度でデータ送信を行い続けると、受信端末において、受信バッファのオーバフローが生じてしまう。従って、送信サーバは、受信端末でバッファオーバフローが生じないように、データ送信速度を制御する必要がある。

ライブ配信方式、すなわち、送信側で符号化後、直ちにデータ送信する方式では、データ送信速度と、受信端末での復号速度は等しい。従って、理想的な配信ネットワークを想定した場合、データ符号化後、順次符号化データを送信することで、受信端末でのバッファのオーバフローは生じない。

一方、蓄積配信方式、すなわち、符号化したデータを、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記録装置に予め記録しておき、記録したデータを読み出して送信する方式では、記録装置からのデータ読出速度と、復号速度とは通常一致しない。従って、蓄積配信方式においては、受信バッファのオーバフローを生じさせないために、送信サーバは、復号速度に応じたデータ送信速度の制御を行う必要がある。簡易な方法としては、送信サーバにおいて時刻を計測しながらデータ送信のタイミングを制御する方法がある。しかし、一般的なコンピュータの時刻制御の精度は、１０ｍｓ程度であり、復号速度が高速な場合には、正確に制御することはできない。また、送信サーバにおいて、ファイルファーマットから、復号速度を認識して、認識した復号速度で送信する必要があり、各種のデータファーマットに対応する煩雑さが生じる。このため、受信端末が、その受信バッファ残量、つまり、受信バッファに蓄積されているデータ量から、受信可能なデータ量を送信サーバに通知し、送信サーバが前記通知に基づき、送信データ量又は送信速度を調整するフロー制御が必要となる。

ＩＰ網でコンテンツ配信を行う場合、通常、トランスポート層のプロトコルとしては、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）又はＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を使用することになる。尚、ＴＣＰ及びＵＤＰの詳細は、非特許文献１に記載されている。

非特許文献１に記載されているとおり、ＴＣＰは、コネクション型であり、送受信間で、確認応答及びフロー制御を実行するプロトコルである。また、通信の方法としては、ユニキャスト通信とマルチキャスト通信があり、もし、マルチキャスト通信にＴＣＰといったフロー制御を行うプロトコルを組み合わせることができれば、複数の受信端末に同時に同一コンテンツを配信するのに有利である。しかし、マルチキャスト通信にＴＣＰといったフロー制御を行うプロトコルを組み合わせると、複数の受信端末からの応答が１台の送信装置に集中する応答爆発という状態を引き起こすため、マルチキャスト通信にＴＣＰを組み合わせることは困難である。従って、ＴＣＰを使用する場合はユニキャスト通信とする必要がある。

一方、ＵＤＰは、コネクションレス型であり、送信サーバが一方的に受信端末にデータ送信を行う方式であるため、ユニキャスト通信のみならず、複数箇所への同時コンテンツ送信に適したマルチキャスト通信にも使用可能である。

図５は、ＴＣＰユニキャストによるコンテンツ送信を説明する図である。図５は、コンテンツ送信を行う映像サーバ６が、Ｎ台の受信端末２−１〜２−Ｎに映像配信を行っている状態を示している。上述したように、ＴＣＰは、フロー制御を行うため、映像サーバ６は、各受信端末から受信可能なデータ量の通知を受け、前記通知に基づきコンテンツ送信を行う。すなわち、受信端末の受信バッファに蓄積されているデータ量に基づいたデータ送信を行うことが可能となる。しかし、ユニキャスト通信であるため、映像サーバ６は、各受信端末とのコネクションを、それぞれ、独立したコネクションとして管理及び処理し、同一コンテンツを並行して各コネクション上に送信する必要がある。このため、映像サーバ６は、受信端末の台数に比例して、その資源を確保する必要があり、配信可能な受信端末数は、映像サーバ６が、配信処理に割当て可能な資源により制限されることとなる。

図６は、ＵＤＰマルチキャストによるコンテンツ送信を説明する図である。マルチキャスト通信では、ＩＰ網内にあるルータ７は必要に応じて、パケットを複製し、複数の方路にパケットの転送を行う。従って、映像サーバ６は、１台の受信端末に送信するのと同様、１ストリーム分のデータ送信を行えばよく、ユニキャスト通信で問題となる映像サーバ６の資源の枯渇は生じず、また、ＩＰ網の帯域も効率的に使用できるという利点がある。しかし、ＵＤＰはフロー制御を行わないため、ＵＤＰマルチキャストでは、映像サーバ６は、受信端末の受信バッファのデータ量に基づくデータ送信速度の制御を行うことはできない。

Ｗ．Ｒ．スティーヴンス著、橘康雄 訳、井上尚司 監訳"詳解ＴＣＰ／ＩＰ Ｖｏｌ．１ プロトコル"、新装版第２刷、２００１年１月３１日発行

上述したように、インターネットといったＩＰ網を利用して、放送型の映像配信といった、同一コンテンツを複数箇所に同時に送信する場合には、コンテンツ送信を行う送信サーバ、すなわち、図４及び図５の映像サーバ６は、受信端末での受信バッファ残量に基づきデータ送信速度を制御する必要がある。しかし、ＴＣＰユニキャストを用いると、送信可能な端末数は、送信サーバが配信に割当て可能なコンピュータ資源により制限される。

ＵＤＰマルチキャストを用いると、送信サーバのコンピュータ資源の制限による問題は生じない。しかし、ＵＤＰはフロー制御を行わないため、他の方法によりフロー制御を実現する必要がある。しかし、このフロー制御においても、応答爆発を生じさせないように、ＩＰ網内で複数の受信端末からの応答を集約することが要求される。すなわち、送信サーバと、受信端末のみならず、ＩＰ網内の各機器に対して、特別な実装を行う必要があり、配信システムが複雑なものとなり、また、そのコストが増大することとなる。

従って、本発明は、受信端末数が増加しても、送信サーバに必要なコンピュータ資源の増大をもたらさず、かつ、受信端末で受信バッファのオーバフローを生じさせないように、データ送信速度を制御するコンテンツ送信サーバ、システム及びサーバ用プログラムを提供することを目的とする。

本発明における送信サーバによれば、
フロー制御を行う第１のプロトコルを用いて第１の受信端末にコンテンツを送信する第１の通信手段と、フロー制御を行わない第２のプロトコルを用いて他の複数の受信端末にマルチキャストで前記コンテンツを送信する第２の通信手段と、第２の通信手段によるコンテンツのデータ送信速度を、第１の通信手段によるコンテンツのデータ送信速度と同じとなるように制御する送信処理手段とを有することを特徴とする。

本発明の送信サーバにおける他の実施形態によれば、
第１の通信手段は、バッファを有し、バッファに蓄積されているデータを第１のプロトコルにより送信し、第２の通信手段は、バッファを有し、バッファに蓄積されているデータを第２のプロトコルにより送信し、送信処理手段は、第１の通信手段のバッファに所定長の空きがある場合は、第１の通信手段のバッファにコンテンツのデータを書き込み、前記書き込んだデータを第２の通信手段のバッファに書き込むことも好ましい。

また、本発明の送信サーバにおける他の実施形態によれば、
第１のプロトコルは、ＴＣＰであり、第２のプロトコルはＵＤＰであることも好ましい。

本発明における送信システムによれば、
前記送信サーバと、送信サーバの第２の通信手段が送信するコンテンツのデータを受信して、平滑化処理を行う帯域制御装置を有することを特徴とする。

本発明におけるプログラムによれば、
コンピュータを、上記送信サーバとして機能させることを特徴とする。

マルチキャストで送信を行うコンテンツと同一コンテンツを、フロー制御を行うプロトコルを用いて第１の受信端末に送信し、第１の受信端末へのコンテンツのデータ送信速度と同じ送信速度となるように、マルチキャストでのコンテンツのデータ送信速度を制御することで、マルチキャストで送信を行う受信端末でバッファオーバフローが生じないように、データ送信速度を調整することができ、また、送信サーバは、２ストリーム分のデータ送信を行えばよいため、送信サーバでデータ送信に割り当てる資源は、受信端末の数に左右されない。

これにより、ＵＤＰマルチキャストでのフロー制御の問題を解決できるため、ＵＤＰマルチキャストを、映像配信等に用いることが可能となり、ネットワーク帯域の有効利用を図ることができる。

また、オペレーティングシステムが標準的に提供する機能だけで実装可能であるため、信頼の高いシステムを低コストで実現できる。

更に、送信サーバのバースト的なデータ送信に対しては、帯域制御装置を送信サーバとＩＰ網との間に設置して、バッファオーバフローを防止する。

本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。

図１は、本発明のシステム構成図である。図１によると、システムは、送信サーバ１と、Ｎ台の受信端末２−１〜２−Ｎと、受信端末３と、ＩＰ網４と、帯域制御装置５とを有する。

送信サーバ１は、本発明による送信サーバであり、帯域制御装置５を介してＩＰ網４に接続している。送信サーバ１はコンテンツを保持しており、受信端末２−１〜２−Ｎ及び３にコンテンツの送信を行う。尚、後述するように、帯域制御装置５を経由せずに、直接ＩＰ網４と接続する構成とすることも可能である。

受信端末２−１〜２−Ｎは、ＩＰ網４と接続しており、送信サーバ１からＩＰ網４経由でコンテンツのデータを受信して復号を行う。尚、受信端末２−１〜２−Ｎは、同一のマルチキャストグループを構成している。各受信端末は、数秒程度の受信バッファを備え、受信データをバッファに蓄積後、復号処理を行う。

受信端末３は、受信端末２−１〜２−Ｎと同一であるが、同じマルチキャストグループには属していない。本システムでは受信端末３を、参照受信端末として使用する。受信端末３は、送信サーバ１と通信可能なように設置される。例えば受信端末２−１〜２−Ｎと同様に、ＩＰ網４を経由して送信サーバ１と通信を行う構成とすることも可能である。しかし、後述する参照受信端末として動作するためには、通信経路上での影響を排除することが好ましく、従って、送信サーバ１に極力近い位置で接続することが望ましい。図１においては、送信サーバ１と直接接続している。

ＩＰ網４は、インターネットプロトコルを使用し、マルチキャストに対応する通信網である。従って、ＩＰ網４は、同一マルチキャストグループへのパケットは、必要に応じて複製を行い転送する。例えば、送信サーバ１が、同一マルチキャストグループに属する受信端末２−１〜２−Ｎにコンテンツの送信を行う場合、送信サーバ１は、１のデータストリームをＩＰ網４に送信すればよく、ＩＰ網４が必要に応じて網内でマルチキャスト、すなわち、ストリームの複製又は分岐を行い、受信端末２−１〜２−Ｎに送信を行う。

帯域制御装置５は、送信サーバ１からの送信信号を一旦受信し、平滑化して送信する装置であり、例えば、送信サーバ１からの送信信号がバースト的であり、バースト期間のデータ量が多い場合に、ＩＰ網４内のルータ装置で生じる可能性のあるバッファオーバフローを回避する目的で使用する。従って、ＩＰ網４内のルータのバッファ量が比較的大きい場合等、送信サーバ１が送信するバーストデータによりＩＰ網４内のルータ装置でバッファオーバフローが生じない場合には必要ではない。

図２は、本発明によるシステムでのコンテンツ送信を説明する図である。図２によると、送信サーバ１は、受信端末２−１〜２−Ｎにコンテンツの送信を行うに当たり、参照受信端末である受信端末３にも同一コンテンツを送信する。但し、受信端末２−１〜２−Ｎには、ＵＤＰ、すなわち、フロー制御を行わないプロトコルを使用しマルチキャストで送信し、受信端末３に対しては、ＴＣＰ、すなわち、フロー制御を行うプロトコルを使用してユニキャストで送信する。

参照受信端末である受信端末３へのコンテンツ送信はフロー制御を伴う。従って、受信端末３は、受信端末３が受信可能であるデータ量等を示すフロー制御情報を送信サーバ１に送信し、送信サーバ１は、受信するフロー制御情報に基づき、データ送信速度を変更又は調整してコンテンツ送信を行う。

一方、受信端末２−１〜２−Ｎへのマルチキャストによるコンテンツ送信ではフロー制御は行われないが、送信するコンテンツは受信端末３に送信するものと同一であるため、受信端末２−１〜２−Ｎの受信バッファ残量は、受信端末３とほぼ等しいものとなる。従って、受信端末３からのフロー制御情報を、受信端末２−１〜２−Ｎへのコンテンツ送信に適用し、受信端末２−１〜２−Ｎへのデータ送信速度を、受信端末３へのデータ送信速度と同期、即ち、同じ速度となるように制御して送信することで、受信端末２−１〜２−Ｎの受信バッファのオーバフローを回避できることとなる。

以上、参照受信端末とフロー制御を行うプロトコルによりコンテンツ送信を行い、参照受信端末からのフロー制御情報に基づき、マルチキャストによるコンテンツ送信を行うことで、送信サーバ１は、２ストリーム分のデータ送信を行えばよく、送信サーバ１でデータ送信に割り当てる資源は、受信端末の数に左右されず、受信端末でバッファオーバフローが生じないように、データ送信速度を制御することができる。

これにより、ＵＤＰマルチキャストでのフロー制御の問題を解決できるため、ＵＤＰマルチキャストを、映像配信等に用いることが可能となり、ネットワーク帯域の有効利用を図ることができる。

続いて、送信サーバ１の構成について説明をする。図３は、本発明の送信サーバ１のブロック図である。図３によると、送信サーバ１は、通信部１１と、通信部１２と、送信処理部１３と、記憶部１４とを有する。

通信部１１は、バッファを有し、フロー制御を行うプロトコルによりバッファに蓄積されている送信データの送信を行い、通信部１２は、バッファを有し、フロー制御を行わないプロトコルによりバッファに蓄積されている送信データの送信を行う。送信処理部１３は、記憶部１４が保存している送信対象のコンテンツのデータを順次読み出して、通信部１１及び１２に出力、すなわち、通信部１１及び１２のバッファに書き込みを行う。

図４は、送信サーバ１の送信処理部１３でのコンテンツ送信のフロー図である。送信処理部１３は、フロー制御を行う通信部１１のバッファの空きを参照して、所定のデータ長が書き込み可能であるか否かを判定し、書き込めない場合は、所定のデータ長の空きができるまで待機する（Ｓ４１）。書き込み可能である場合は、所定長のデータを通信部１１のバッファに書き込み（Ｓ４２）、続けてフロー制御を行わない通信部１２のバッファにも、Ｓ４２で通信部１１に書き込みを行ったのと同一のデータを書き込む（Ｓ４３）。その後、コンテンツの全データを送信したか否かを判定し（Ｓ４４）、全データを送信するまでＳ４１からＳ４３を繰り返す。

通信部１１はフロー制御を行いながらバッファに蓄積されているデータの送信を行う。従って、例えば、フロー制御により通信部１１が、参照受信端末より送信データを少なくする旨の通知を受けている場合は、通信部１１のバッファに空きが生じず、よって、送信処理部１３は待ち状態となるといったように、送信処理部１３の通信部１１のバッファへの書き込みは、フロー制御により制御されることとなる。そして、通信部１１のバッファへ書き込みを行ったデータを、続けて通信部１２のバッファへ書き込む構成とすることで参照受信端末からのフロー制御を、他の受信端末へのコンテンツ送信に反映させている。

実際の実装においては、アプリケーションは、ネットワーク通信とのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）となるソケットを、ＴＣＰユニキャスト通信用及びＵＤＰマルチキャスト通信用それぞれに作成する。ソケットの作成は、一般的なオペレーティングシステムで利用可能なｓｏｃｋｅｔシステムコールを利用できる。

また、ＴＣＰコネクションの確立にも一般的なオペレーティングシステムでは標準的なｂｉｎｄ、ｌｉｓｔｅｎ、ａｃｃｅｐｔ及びｃｏｎｎｅｃｔシステムコールを利用できる。確立したＴＣＰコネクションでのデータ送信のために、アプリケーションは、ＴＣＰユニキャスト通信用ソケットに対して、ブロックＩ／Ｏモードで送信データを書き込む。送信データの書き込みには、同様に、標準的なｗｒｉｔｅシステムコールを利用できる。ここでブロックＩ／Ｏモードとは、アプリケーションがデータをソケットに書き込み後、データが送信バッファに総て格納されるまでオペレーティングシステムがアプリケーションの動作を一時停止するモードである。ここで、送信バッファに格納されているデータ量が減らないことは、受信端末でバッファの空きが少なく、ＴＣＰのフロー制御により送信が抑えられていることを意味し、逆に、送信バッファに格納されているデータ量がすぐに減少することは、受信端末でバッファの空きが大きいことを意味する。すなわち、送信バッファのデータ量と、受信端末の受信バッファのデータ量には相関がある。

ＵＤＰによるマルチキャストグループ宛ての送信には、まず、ＵＤＰマルチキャスト通信用のソケット作成時にｓｏｃｋｅｔシステムコールが返す戻り値と、マルチキャストグループの識別子を引数としてｃｏｎｎｅｃｔシステムコールの呼出しを行う。その後、実際のデータ送信には、ＵＤＰマルチキャスト通信用ソケットに対して、送信データの書き込みを行う。

上述した実装方法では、オペレーティングシステムがパケットの送信タイミングを制御しており、アプリケーションから制御することはできない。送信サーバ１が、例えば、ギガビットの物理速度で動作するＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）といった、高速リンクを使用している場合、一定帯域でのデータ送信に対して、オペレーティングシステムは、一定量のパケットを送信するのではなく、瞬間的に多量のパケットを送信し、その後しばらく送信を停止して平均的には一定帯域でデータ送信を行うことがある。このバースト的な送信により、ＩＰ網４でパケットの廃棄等が生じる場合には、帯域制御装置５を送信サーバ１とＩＰ網４との間に設置する。尚、送信サーバ側において平滑化して送信する構成とすることも可能である。

以上述べたように、本発明では、オペレーティングシステムが標準的に提供する機能だけで実装可能である。変更内容についても、参照受信端末に対するＴＣＰユニキャスト通信と、ＵＤＰマルチキャスト通信を連携させるという簡易なもので、送信サーバ１以外の受信端末２−１〜２−Ｎや、ＩＰ網４には変更が必要ない。従って、複雑な変更を行う必要がないため、信頼の高いシステムを低コストで実現できる。

本発明のシステム構成図 本発明のシステムでのコンテンツ送信を説明する図である。 本発明の送信サーバのブロック図である。 送信サーバでのコンテンツ送信のフロー図である ＴＣＰユニキャストによるコンテンツ送信を説明する図である。 ＵＤＰマルチキャストによるコンテンツ送信を説明する図である。

符号の説明

１ 送信サーバ
２−１〜２−Ｎ、３ 受信端末
４ ＩＰ網
５ 帯域制御装置
６ 映像サーバ
７ ルータ
１１、１２ 通信部
１３ 送信処理部
１４ 記憶部

Claims (5)

1. フロー制御を行う第１のプロトコルを用いて第１の受信端末にコンテンツを送信する第１の通信手段と、
   フロー制御を行わない第２のプロトコルを用いて他の複数の受信端末にマルチキャストで前記コンテンツを送信する第２の通信手段と、
   第２の通信手段によるコンテンツのデータ送信速度を、第１の通信手段によるコンテンツのデータ送信速度と同じとなるように制御する送信処理手段と、
   を有することを特徴とする送信サーバ。
2. 第１の通信手段は、バッファを有し、バッファに蓄積されているデータを第１のプロトコルにより送信し、
   第２の通信手段は、バッファを有し、バッファに蓄積されているデータを第２のプロトコルにより送信し、
   送信処理手段は、第１の通信手段のバッファに所定長の空きがある場合は、第１の通信手段のバッファにコンテンツのデータを書き込み、前記書き込んだデータを第２の通信手段のバッファに書き込むことを特徴とする請求項１に記載の送信サーバ。
3. 第１のプロトコルは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）であり、第２のプロトコルはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）であることを特徴とする請求項１又は２に記載の送信サーバ。
4. 請求項１から３のいずれか１項に記載の送信サーバと、
   送信サーバの第２の通信手段が送信するコンテンツのデータを受信して、平滑化処理を行う帯域制御装置を有することを特徴とする送信システム。
5. コンピュータを、
   フロー制御を行う第１のプロトコルを用いて第１の受信端末にコンテンツを送信する第１の通信手段と、
   フロー制御を行わない第２のプロトコルを用いて他の複数の受信端末にマルチキャストで前記コンテンツを送信する第２の通信手段と、
   第２の通信手段によるコンテンツのデータ送信速度を、第１の通信手段によるコンテンツのデータ送信速度に基づき制御する送信処理手段と、
   して機能させることを特徴とするプログラム。

Images