(57)【要約】【課題】  簡単な仕組みで、ストリーミングデータの再生開始までの待機時間を短縮することができると共に、ストリーミングデータの再生後に映像及び音声の安定化を図ることができ、最適な伝送速度でのストリーミング配信を可能とする。【解決手段】  本発明に係るストリーミング配信システムにおいて、通信端末３は、ストリーミングデータの受信状態に応じて、要求するストリーミングデータのデータサイズを決定して、サーバ１に対して通知するように構成されており、サーバ１は、通信端末３によって通知されたストリーミングデータのデータサイズの変化を検出した場合、ストリーミングデータの伝送速度を変更するように構成されている伝送速度制御部１２と、変更された伝送速度でストリーミングデータを送信するように構成されているデータ送信部１０とを具備する。【選択図】  図１
2007013675.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してサーバから通信端末に対してストリーミングデータを配信するストリーミング配信システムであって、
前記通信端末は、前記ストリーミングデータの受信状態に応じて、要求するストリーミングデータのデータサイズを決定して、前記サーバに対して通知するように構成されており、
前記サーバは、
前記通信端末によって通知された前記ストリーミングデータのデータサイズの変化を検出した場合、該ストリーミングデータの伝送速度を変更するように構成されている伝送速度制御部と、
変更された前記伝送速度で、前記ストリーミングデータを送信するように構成されているデータ送信部とを具備することを特徴とするストリーミング配信システム。
【請求項２】
ネットワークを介して通信端末に対してストリーミングデータを送信するサーバであって、
前記通信端末によって通知された前記ストリーミングデータのデータサイズの変化を検出した場合、該ストリーミングデータの伝送速度を変更するように構成されている伝送速度制御部と、
変更された前記伝送速度で、前記ストリーミングデータを送信するように構成されているデータ送信部とを具備することを特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してサーバから通信端末に対してストリーミングデータを配信するストリーミング配信システム、及び、サーバに関する。
【背景技術】
【０００２】
従来、通信端末が、サーバに対して必要なストリーミングデータを要求し、当該サーバが、かかる要求に応えることによって、ストリーミングデータの配信を開始し継続するように構成されているストリーミング配信システムが知られている（例えば、非特許文献１参照）。
【０００３】
かかるストリーミング配信システムでは、ストリーミングデータの配信の開始時やジャンプ時のように、シーンが大きく変わる際には、通信端末は、要求するストリーミングデータのデータサイズを小さくし、当該ストリーミングデータの再生までのタイムラグをできるだけ無くし、その後、徐々に要求するストリーミングデータのデータサイズを大きくするように構成されている。
【０００４】
また、一般的に、ストリーミング配信において伝送速度を制御する方法として、非特許文献２に記載されている方法が知られている。
【０００５】
さらに、本発明の背景技術として、データ復元処理（エラー訂正処理）及びインタリーブ処理と、データサイズとの関係について説明する。
【０００６】
ストリーミング配信において、データを先頭から順に転送する方式では、パケットロスが起きたときに、データが連続して抜け落ちてしまう。そこで、一般的に、ストリーミング配信では、ある程度のサイズにまとめてパリティビットを付与したデータを、所定規則に従って入れ替えて送信するように構成されている。
【０００７】
具体的には、一般的なストリーミング配信では、図６に示すように、データを仮想的に２次元的に取り扱う。図６において、「０」〜「ｍ」は、データ復元処理（エラー訂正処理）を行うためにパリティを付加する１つのブロック単位である。ここで、例えば、「ｍ＝４７」とすると、図６に示すように、１次元のデータが、４７バイトごとに折り返されて２次元的に表わされることとなる。
【０００８】
そして、図７に示すように、各行の４７バイトのデータに対して、例えば、４バイトのパリティビットを付加して、各行を５１バイトとすると、各行を構成する５１バイトのうち４バイトまでの消失であれば、残りのデータから消失したデータを復元（エラー訂正）することができる。
【０００９】
なお、インタリーブ処理とは、図８に示すように、横方向に書き込んだデータを、縦方向に読み込んでいく処理である。また、インタリーブ処理において、縦方向に読み込むデータサイズ（図８の例では「ｎ」）を「インタリーブブロック長」と呼ぶ。
【００１０】
また、ストリーミング配信では、図９に示すように、サーバ１が、インタリーブ処理を施したデータを、インターネット等のネットワーク２を介して通信端末３に送信し、通信端末３が、受信したデータに対してデインタリーブ処理（インタリーブの逆変換処理）を施すことによって元のデータに復元するように構成されている。
【００１１】
従来のストリーミング配信では、一般的に、ストリーミングデータ（コンテンツデータ）を再生するまでの待機時間が長かった。これは、パケットロス等のエラー対策のために、通信端末３において受信するストリーミングデータのデータサイズを大きくしていたためである。
【００１２】
図１０（ａ）に示すように、デインタリーブ処理の対象となるデータサイズが大きい（インタリーブブロック長が大きい）とすると、所定のブロック分のデータが、１度のパケットで送信される。
【００１３】
このように、インタリーブブロック長が大きいと、図１０（ｂ）に示すように、パケットロスがあったとしても、消失したデータの位置が異なった行にばらばらに分散されるため、エラー訂正が可能となる。
【００１４】
その結果、ストリーミングデータの損失が抑えられ、安定した再生を行うことができる。
【００１５】
しかしながら、デインタリーブ処理の対象となるデータサイズ（すなわち、インタリーブブロック長）を大きくすると、通信端末３において、ストリーミングデータを取得するのに時間がかかり、ストリーミングデータの再生を開始するまでの待機時間が長くなってしまうという問題点があった。
【００１６】
そこで、図１１（ａ）に示すように、デインタリーブ処理の対象となるデータサイズ（すなわち、インタリーブ長）を小さくすると、ストリーミングデータを取得する時間は短くなるが、図１１（ｂ）に示すように、パケットロスが起きると、消失したデータの位置が同じ行に集中してしまう可能性が高いため、エラー訂正ができずに、結果的に、ストリーミングデータの再生時に、音声及び映像が乱れてしまう可能性が高いという問題点があった。
【００１７】
かかる問題点を解決するために、上述のストリーミング配信システムのように、通信端末３が、ストリーミングデータの配信の開始時には、要求するストリーミングデータのデータサイズを小さくし、その後、徐々に要求するストリーミングデータのデータサイズを大きくするように構成されている。
【特許文献１】特開２００５-９４１４０号公報
【特許文献２】特開２００３-１６３９１６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１８】
しかしながら、従来のストリーミング配信システムのように、徐々にストリーミングデータのデータサイズを大きくしていくためには、通信端末３において、現在の伝送速度や残存バッファ量を考慮して、サーバ１にストリーミングデータのデータサイズを要求する必要があり、通信端末３の負荷が大きくなるという問題点があった。
【００１９】
また、ストリーミング配信システムにおいて伝送速度を制御するためには、サーバ１及び通信端末３の双方に、伝送速度を知らせる通信プロトコル上の何らかの取り決めが必要であり、また、伝送速度を検出するための回路や演算が必要であり、回路構成が複雑になるという問題点があった。
【００２０】
そこで、本発明は、以上の点に鑑みてなされたもので、簡単な仕組みで、ストリーミングデータの再生開始までの待機時間を短縮することができると共に、ストリーミングデータの再生後に映像及び音声の安定化を図ることができ、最適な伝送速度でのストリーミング配信を可能とするストリーミング配信システム及びサーバを提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明の第１の特徴は、ネットワークを介してサーバから通信端末に対してストリーミングデータを配信するストリーミング配信システムであって、前記通信端末が、前記ストリーミングデータの受信状態に応じて、要求するストリーミングデータのデータサイズを決定して、前記サーバに対して通知するように構成されており、前記サーバが、前記通信端末によって通知された前記ストリーミングデータのデータサイズの変化を検出した場合、該ストリーミングデータの伝送速度を変更するように構成されている伝送速度制御部と、変更された前記伝送速度で、前記ストリーミングデータを送信するように構成されているデータ送信部とを具備することを要旨とする。
【００２２】
本発明の第２の特徴は、ネットワークを介して通信端末に対してストリーミングデータを送信するサーバであって、前記通信端末によって通知された前記ストリーミングデータのデータサイズの変化を検出した場合、該ストリーミングデータの伝送速度を変更するように構成されている伝送速度制御部と、変更された前記伝送速度で、前記ストリーミングデータを送信するように構成されているデータ送信部とを具備することを要旨とする。
【発明の効果】
【００２３】
以上説明したように、本発明によれば、簡単な仕組みで、ストリーミングデータの再生開始までの待機時間を短縮することができると共に、ストリーミングデータの再生後に映像及び音声の安定化を図ることができ、最適な伝送速度でのストリーミング配信を可能とするストリーミング配信システム及びサーバを提供することができる。
【発明を実施するための最良の形態】
【００２４】
（本発明の第１の実施形態に係るストリーミング配信システムの構成）
図１を参照して、本発明の第１の実施形態に係るストリーミング配信システムの構成について説明する。本実施形態に係るストリーミング配信システムは、インターネット等のネットワーク２を介してサーバ１から通信端末３に対してストリーミングデータを配信するように構成されている。なお、ストリーミングデータは、ＴＣＰによって送信されるように構成されていてもよいし、ＵＤＰによって送信されるように構成されていてもよく、伝送方式は、限定しない。
【００２５】
図１に示すように、サーバ１は、データ送受信部１０と、要求判定部１１と、伝送速度制御部１２と、ストリーミングデータ記憶部１３とを具備する。
【００２６】
データ送受信部１０は、ネットワーク２を介して通信端末３との間でデータを送受信するように構成されている。例えば、データ送受信部１０は、伝送速度制御部１２によって指定された伝送速度で、ストリーミングデータを送信するように構成されている。また、データ送受信部１０は、通信端末３から送信されたデータ要求を受信するように構成されている。
【００２７】
要求判定部１１は、データ送受信部１０によって受信されたデータ要求に含まれるストリーミングデータのデータサイズの変化を検出するように構成されている。
【００２８】
伝送速度制御部１２は、要求判定部１１によってストリーミングデータのデータサイズの変化を検出したことを通知された場合、ストリーミングデータの伝送速度を変更するように構成されている。
【００２９】
具体的には、伝送速度制御部１２は、図１に示すように、通信端末３によって通知されるストリーミングデータのデータサイズを示す「要求データサイズ」と、ストリーミングデータ伝送速度を示す「伝送速度」とを関連付けるテーブルを有しており、ストリーミングデータのデータサイズの変化を検出した場合、かかるテーブルを参照することによって、ストリーミングデータの伝送速度を決定するように構成されていてもよい。
【００３０】
また、伝送速度制御部１２は、通信端末３からのデータ要求に含まれるストリーミングデータのデータサイズ及び当該ストリーミングデータの再生速度を考慮して、当該ストリーミングデータの伝送速度を計算するように構成されていてもよい。
【００３１】
ストリーミングデータ記憶部１３は、通信端末３に送信するストリーミングデータを蓄積するように構成されており、データ送受信部１０からの要求に応じて、該当するストリーミングデータを出力するように構成されている。
【００３２】
また、ストリーミングデータ記憶部１３は、ストリーミングデータを識別するためのＩＤと、当該ストリーミングデータの初期再生速度と、当該ストリーミングデータとを関連付けて記憶するように構成されていてもよい。
【００３３】
通信端末３は、データ送受信部３０と、回線安定判定部３１と、バッファ３２とを具備する。
【００３４】
データ送受信部３０は、ネットワーク２を介してサーバ１との間でデータを送受信するように構成されている。例えば、データ送受信部３０は、サーバ１から送信されたストリーミングデータを受信するように構成されている。また、データ送受信部３０は、回線安定判定部３１によって決定されたストリーミングデータのデータサイズを含むデータ要求を送信するように構成されている。
【００３５】
回線安定判定部３１は、ストリーミングデータの受信状態に応じて、要求するストリーミングデータのデータサイズを決定するように構成されている。
【００３６】
具体的には、回線安定判定部３１は、一定時間、所定のデータサイズでのストリーミングデータの安定受信を確認すると、一定の増加割合で、要求するストリーミングデータのデータサイズを大きくするように構成されている。
【００３７】
また、回線安定判定部３１は、ストリーミングデータの受信失敗を検出した場合、一定の減少割合で、要求するストリーミングデータのデータサイズを小さくするように構成されていてもよいし、要求するストリーミングデータのデータサイズを初期要求データサイズに設定するように構成されていてもよい。
【００３８】
また、回線安定判定部３１は、ストリーミングデータの受信を開始する際は、要求するストリーミングデータのデータサイズを初期要求データサイズに設定するように構成されている。
【００３９】
さらに、回線安定判定部３１は、通信端末各々が持つ性能の最大データサイズに到達するまで、要求するストリーミングデータのデータサイズを増加させることができる。
【００４０】
バッファ３２は、バッファＡ及びバッファＢを含むダブルバッファ構造を有する。バッファ３２では、一方のバッファに蓄積されているストリーミングデータが再生されている場合、他方のバッファにデータ送受信部３０によって受信されたストリーミングデータが蓄積されるように構成されている。
【００４１】
（本発明の第１の実施形態に係るストリーミング配信システムの動作）
図２乃至図５を参照して、本発明の第１の実施形態に係るストリーミング配信システムの動作について説明する。
【００４２】
第１に、図２を参照して、本実施形態に係る通信端末３の動作について説明する。図２に示すように、ステップＳ１１において、ストリーミングデータの受信を開始する際に、通信端末３の回線安定判定部３１は、要求するストリーミングデータのデータサイズを、初期要求データサイズに設定する。
【００４３】
ステップＳ１２において、データ送受信部３０は、回線安定判定部３１によって設定されたデータサイズを通知するためのデータ要求をサーバ１に対して送信する。
【００４４】
ステップＳ１３において、データ送受信部３０は、サーバ１によって送信されたストリーミングデータを受信する。
【００４５】
ステップＳ１４において、回線安定判定部３１は、一定時間、所定のデータサイズでのストリーミングデータを安定して受信しているか否かについて確認する。かかる安定受信を確認した場合、本動作はステップＳ１５に進み、それ以外の場合、本動作はステップＳ１２に戻る。
【００４６】
ステップＳ１５において、回線安定判定部３１は、一定の増加割合で、要求するストリーミングデータのデータサイズを大きくする。その後、本動作はステップＳ１２に戻る。
【００４７】
第２に、図３を参照して、本実施形態に係るサーバ１の動作について説明する。図３に示すように、ステップＳ２１において、サーバ１の要求判定部１１は、通信端末１によって送信されたデータ要求（要求するストリーミングデータのデータサイズを含む）を受信する。
【００４８】
ステップＳ２２において、要求判定部１１は、受信したデータ要求が初期要求であるか否かについて判定する。初期要求である場合、本動作はステップＳ２４に進み、それ以外の場合、本動作はステップＳ２３に進む。
【００４９】
ステップＳ２３において、要求判定部１１は、当該データ要求に含まれるストリーミングデータのデータサイズが、現在のストリーミングデータのデータサイズと異なるか否かについて判定する。異なると判定された場合、本動作はステップＳ２４に進み、それ以外の場合、本動作はステップＳ２５に進む。
【００５０】
伝送速度制御部１２は、ステップＳ２４において、当該データ要求に含まれるストリーミングデータのデータサイズを記憶し、ステップＳ２５において、当該データサイズに対応する伝送速度を、以降送信するストリーミングデータの伝送速度として設定する。
【００５１】
ステップＳ２６において、データ送受信部１０は、伝送速度制御部１２によって設定された伝送速度で、ストリーミングデータを送信する。その後、本動作はステップＳ２１に戻る。
【００５２】
第３に、図４及び図５を参照して、本実施形態に係るストリーミング配信システムにおいて、ストリーミングデータが配信される全体動作について説明する。
【００５３】
ここで、ユーザが、所望のストリーミングデータ（コンテンツデータ）を選択すると、通信端末３は、サーバ１に対して、ユーザによって選択されたストリーミングデータを取得する動作、すなわち、データ要求動作を開始する。
【００５４】
この際、従来のストリーミング配信のように、通信端末３は、乱れの無い安定したストリーミングデータの再生を行うのに十分なデータサイズ、例えば、１０秒分のストリーミングデータを送信するように要求すると、受信するストリーミングデータのデータサイズが大きくなり、ストリーミングデータの受信に時間がかかり、ストリーミングデータの再生が行われるまでに時間がかかってしまう。
【００５５】
したがって、本実施形態に係るストリーミング配信システムでは、ステップＳ１０１において、通信端末３は、再生が可能で、かつ、できるだけ小さいサイズ（初期要求データサイズ）、例えば、１秒分のストリーミングデータを要求するためのデータ要求を送信する。
【００５６】
なお、要求するストリーミングデータのデータサイズを小さくすると、パケットロス等のエラーにより、ストリーミングデータの再生状況が乱れる恐れがあるが、ストリーミングデータの受信時間は短くなり、結果、ストリーミングデータの再生までにかかる時間も短くなる。
【００５７】
このように、ストリーミングデータの再生開始時において、要求するストリーミングデータのデータサイズを小さくするのは、安定したストリーミングデータの再生よりも、ストリーミングデータの再生開始までの待機時間が短い方が、ユーザの満足度が高いと考えられるからである。
【００５８】
ステップＳ１０２において、サーバ１は、１秒分のストリーミングデータを要求するためのデータ要求を受信すると、１秒分のストリーミングデータが、１秒よりも早い時間で通信端末３に到達する伝送速度を設定し、当該ストリーミングデータの配信を開始する。
【００５９】
このように伝送速度を設定するのは、ストリーミングデータの伝送に１秒以上かかると、通信端末３において、ストリーミングデータの再生に追いつかなくなり、ストリーミングデータの再生がストップしてしまうからである。
【００６０】
例えば、サーバ１は、１秒分のストリーミングデータ（０.７５Ｍｂｉｔ）を、０.７５秒で通信端末３に到達するように、伝送速度を１Ｍｂｐｓに設定する。
【００６１】
そして、通信端末３は、ストリーミングデータの再生に用いられていない方のバッファに、受信したストリーミングデータを蓄積する。
【００６２】
その後、サーバ１は、通信端末３によって通知されるストリーミングデータのデータサイズ（要求データサイズ）が変わらない限り、ステップＳ１０２において設定した伝送速度で、ストリーミングデータを配信し続ける（ステップＳ１０４、Ｓ１１１）。
【００６３】
また、通信端末３は、ストリーミングデータの再生開始直後は、しばらく初期要求データサイズを含むデータ要求を送信するが、回線が安定しており、一定期間、１秒分のストリーミングデータを正常に受信していると判断すると、要求データサイズを大きくする。
【００６４】
これは、上述の通り、ストリーミングデータのデータサイズが小さいままでは、ストリーミングデータの再生エラーが起きやすいからである。
【００６５】
ただし、通信端末３が、いきなり、むやみに要求データサイズを大きくすると、現在のストリーミングデータの再生が終了しても、続きのストリーミングデータを再生するための準備（例えば、受信処理やデインタリーブ処理等）が完了せず、ストリーミングデータの再生が途切れてしまう。
【００６６】
そこで、現在のストリーミングデータの再生が終了するまでに、続きのストリーミングデータを再生するための準備が完了し、かつ、パケットロス等による再生エラーが少なくなるように、通信端末３は、要求データサイズを徐々に大きくしていく。
【００６７】
そして、通信端末３は、要求データサイズが最大データサイズに到達すると、以降、要求データサイズを最大データサイズに固定する。
【００６８】
なお、かかる最大データサイズや、初期要求データサイズや、要求データサイズの増加量は、通信端末ごとに異なる。また、通信端末３は、自身の伝送受信能力やバッファ量等から、上述の最大データサイズや初期要求データサイズや要求データサイズの増加量を、予め自身の記憶領域に設定しておく。
【００６９】
ステップＳ２０１において、通信端末３は、回線が安定しており、一定期間、ストリーミングデータを正常に受信していると判断した結果、要求データサイズを大きくし、２秒分のストリーミングデータを要求するためのデータ要求を送信する。
【００７０】
ステップＳ２０２において、サーバ１は、２秒分のストリーミングデータを要求するためのデータ要求を受信すると、要求データサイズの変化を検出し、ストリーミングデータの伝送速度を変更する。
【００７１】
ここで、先の要求データサイズが１秒分のストリーミングデータであったため、通信端末３のバッファには、１秒分のストリーミングデータしか蓄積されていない。
【００７２】
したがって、サーバ１は、２秒分のストリーミングデータを、１秒よりも早い時間で通信端末３に到達する伝送速度を設定し、かかる伝送速度で２秒分のストリーミングデータを配信する。
【００７３】
例えば、サーバ１は、２秒分のストリーミングデータ（１.５Ｍｂｉｔ）を、１秒で通信端末３に到達するように、伝送速度を１.５Ｍｂｐｓに設定する。
【００７４】
通信端末３は、その後しばらく、ステップＳ２０１で設定した要求データサイズを含むデータ要求を送信するが（ステップＳ２０３、Ｓ２１０）、回線が安定しており、一定期間、２秒分のストリーミングデータを正常に受信していると判断すると、ステップＳ３０１において、要求データサイズを大きくし、３秒分のストリーミングデータを要求するためのデータ要求を送信する。
【００７５】
ステップＳ３０２において、サーバ１は、３秒分のストリーミングデータを要求するためのデータ要求を受信すると、要求データサイズの変化を検出し、ストリーミングデータの伝送速度を変更する。
【００７６】
ここで、先の要求データサイズが２秒分のストリーミングデータであったため、通信端末３のバッファには、２秒分のストリーミングデータしか蓄積されていない。
【００７７】
したがって、サーバ１は、３秒分のストリーミングデータを、２秒よりも早い時間で通信端末３に到達する伝送速度を設定し、かかる伝送速度で３秒分のストリーミングデータを配信する。
【００７８】
例えば、サーバ１は、３秒分のストリーミングデータ（２.２５Ｍｂｉｔ）を、１.２５秒で通信端末３に到達するように、伝送速度を１.８Ｍｂｐｓに設定する。
【００７９】
以降、要求データサイズが最大データサイズに到達するまで、上記動作が繰り返され、ストリーミング配信が維持される。
【００８０】
（本実施形態に係るストリーミング配信システムの作用・効果）
本実施形態に係るストリーミング配信システムによれば、簡単な仕組みで、ストリーミングデータの再生開始までの待機時間を短縮することができると共に、ストリーミングデータの再生後に映像及び音声の安定化を図ることができ、最適な伝送速度でのストリーミング配信を可能とする。
【図面の簡単な説明】
【００８１】
【図１】本発明の第１の実施形態に係るストリーミング配信システムの全体構成図である。
【図２】本発明の第１の実施形態に係る通信端末の動作を示すフローチャートである。
【図３】本発明の第１の実施形態に係るサーバの動作を示すフローチャートである。
【図４】本発明の第１の実施形態に係るストリーミング配信システムの動作を示すシーケンス図である。
【図５】本発明の第１の実施形態に係るストリーミング配信システムの動作を説明するための図である。
【図６】従来のストリーミング配信方法を説明するための図である。
【図７】従来のストリーミング配信方法を説明するための図である。
【図８】従来のストリーミング配信方法を説明するための図である。
【図９】従来のストリーミング配信システムの全体構成図である。
【図１０】従来のストリーミング配信システムの問題点を説明するための図である。
【図１１】従来のストリーミング配信システムの問題点を説明するための図である。
【符号の説明】
【００８２】
１…サーバ
１０…データ送受信部
１１…要求判定部
１２…伝送速度制御部
１３…ストリーミングデータ記憶部
２…ネットワーク
３…通信端末
３０…データ送受信部
３１…回線安定判定部
３２…バッファ
【図１】
2007013675.tif 000003
【図２】
2007013675.tif 000004
【図３】
2007013675.tif 000005
【図４】
2007013675.tif 000006
【図５】
2007013675.tif 000007
【図６】
2007013675.tif 000008
【図７】
2007013675.tif 000009
【図８】
2007013675.tif 000010
【図９】
2007013675.tif 000011
【図１０】
2007013675.tif 000012
【図１１】
2007013675.tif 000013