JP5061619B2

JP5061619B2 - リソース確保方法、中継装置、配信システム、およびプログラム

Info

Publication number: JP5061619B2
Application number: JP2007013741A
Authority: JP
Inventors: 周平三浦; 勝博落合; 昭小林; 基伸木村; 要内藤; 淳一佐藤
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2007-01-24
Filing date: 2007-01-24
Publication date: 2012-10-31
Anticipated expiration: 2027-01-24
Also published as: US8239909B2; JP2008182426A; WO2008090843A1; CN101595732A; CN101595732B; US20100017837A1

Description

本発明は、映像音声ストリーミング配信システムに関し、特に映像音声ストリームの配信に必要なリソース確保方法に関する。

従来、一般的にユニキャストによる映像音声ストリーミングを実現するシステムにおいて、各ストリームをＴＶのチャネルと捉えて放送型のサービスを実現するには、各ストリームを伝送するための経路上の帯域確保やフィルタリング設定（アクセス制御）は、ザッピング（ＴＶにおけるユーザのリモコン操作によるチャンネル選択の意）を行う際に都度行われていた。

例えば、マルチキャストによって実現されるＩＰＴＶサービスを考えた場合、コアネットワークの帯域は全チャンネルを一度に配信するに足る容量を備えるが、端末と収容局の間の帯域は現在の一般的なサービスでは１００Ｍｂｐステップ以下であり、１本のストリームの消費帯域が６Ｍｂｐステップとして、最大でも１６本しかマルチキャストで端末に届けることはできない。現在普及しているＡＤＳＬ（ＡｓｙｍｍｅｔｒｉｃＤｉｇｉｔａｌＳｕｂｓｃｒｉｂｅｒＬｉｎｅ）方式による実効性能は１０Ｍｂｐステップ前後のものも多く、ストリーム２本を同時に配信ことも困難な場合がある。したがって、このような帯域のミスマッチに対応するためには、収容局内において、端末が視聴選択したストリームのみをユニキャストで端末に届けるようなシステムが現実的である。
特開２００３−１４３５８７号公報

従来技術における問題点は、ある映像音声ストリームを視聴中に、別の映像音声ストリームに切り替えるザッピング視聴の際に、映像音声ストリームを切り替える時間がかかり、ＴＶのようなザッピング性能が出ないことにある。特に、ＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）が保証された映像音声ストリーミングにおいては、ベストエフォートな映像音声ストリーミングに対して、さらに旧視聴映像音声ストリームの帯域解放と新視聴映像音声ストリームの帯域確保の動作が余計にかかり、ザッピング性能がさらに悪化する可能性がある。

図５は、前記従来技術による映像音声ストリーム配信システムの構成例を示す図である。

配信サーバ５０１から、配信経路５０２を経由して中継手段５０３に対してマルチキャストで複数の映像音声ストリームを配信する。端末５０７は、番組情報（図示せず）より視聴したい映像音声ストリームの配信要求を配信経路５０６、帯域制御手段５０５、配信経路５０４を経由して中継手段５０３に伝達する。中継手段５０３は、要求された前記ストリームの帯域情報（図示せず）に従って配信に必要な帯域要求を、制御線５１０を経由して帯域管理手段５０９に対して行う。帯域管理手段５０９は、その要求された帯域を確保可能であれば、制御線５０８を介して帯域制御手段５０５に対してその帯域確保を指示するとともに、制御線５１０を経由して中継手段５０３に帯域確保可能の旨を伝達する。中継手段５０３は、端末５０７からの要求による映像音声ストリームを、配信経路５０４、帯域制御手段５０５、配信経路５０６を経由して端末５０７に対してユニキャストで配信する。

このような構成を採用したシステムは特許文献１に記載されている。特許文献１では、ザッピングの際の高速化を図るため、配信サーバから配信されるマルチキャストでの複数映像音声ストリームのいくつかを次に選択対象となるストリームとして予測し、マルチキャストポイントでフィルタリングしてあらかじめ端末に配信しておき、上位アプリケーションからザッピング指示を受けると、もし予測が当たっていれば、端末内で既に受信している複数の映像音声ストリームから該当映像音声ストリームを選択し再生する。

しかし、特許文献１に記載の方法では、ユーザが視聴している映像音声ストリームに加え、予測された映像音声ストリームについても、マルチキャストポイントと端末間で実際に映像音声ストリームとして流れてしまうため、前記のようにＡＤＳＬを用いる等してマルチキャストポイントと端末間のネットワークリソースが十分にない場合や複数の端末が同じマルチキャストポイントから映像音声ストリームを受信している場合に、ネットワークリソースが枯渇しやすい。例えば、ネットワークのスループットが１０Ｍｂｐステップしかない回線に、６Ｍｂｐステップのストリームは１本しか通らないため、この方法によるザッピングの高速化は実現できない。

本発明の目的は、ＱｏＳが保証されたストリーミングにおいて、ザッピング時のストリーム切り替え速度を向上させ、なおかつ実使用ネットワークリソースは最低限に抑えるリソース確保方法、中継装置、配信システム、およびプログラムを提供することにある。

本発明のリソース確保方法は、
端末と、当該端末に映像音声ストリームを配信する配信サーバとに通信回線を介して接続された中継装置が、
前記端末が受信中または選択した映像音声ストリームの次に選択する映像音声ストリームを予測し、
前記端末が受信中または選択した映像音声ストリームに加え、前記予測した映像音声ストリームの配信に必要なリソースを、当該端末による次の選択が行われる前に確保し、
前記予測した映像音声ストリームが、前記端末が次に選択する映像音声ストリームと一致した場合、当該端末に当該映像音声ストリームの配信を開始すること
を特徴とする。

本発明は、ストリーミングに仮想のチャンネルが与えられた際に、予測を元に、次にザッピングして視聴される可能性のあるストリーム分の帯域確保とアクセス制御のみを、ザッピング操作に先行して行うことによって、ザッピング時のストリーム切り替え速度を向上させ、なおかつ実使用ネットワークリソースは最低限に抑える。

本発明によれば、ユーザがザッピング操作を行う前に既に次の新しいストリーム視聴に必要な帯域確保やアクセス制御が完了しているため、新しいストリーム視聴のための帯域確保の時間短縮が図れ、またユーザがザッピング操作を行う前に既に次の新しいストリーム視聴に必要な帯域確保が可能かどうかを判定済みのため、ザッピング操作時にはザッピングできるかどうかを速やかにユーザに通知できる。

次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。

図１は本発明の一実施形態の映像音声ストリーミング配信システムのブロック図である。

配信サーバ１０１は配信経路１０２を介して中継手段１０３に接続している。中継手段１０３は配信経路１０４を介して帯域制御手段１０５に接続している。帯域制御手段１０５は配信経路１０６を介して端末１０７に接続している。ザッピング先予測手段１１１は制御線１１０を介して中継手段１０３と接続し、また制御線１１２を介して帯域管理手段１０９と接続している。帯域管理手段１０９は制御線１０８を介して帯域制御手段１０５と接続している。

図２は本実施形態の映像音声ストリーミング配信システムの動作を表すフローチャートである。

配信サーバ１０１は、中継手段１０３に対して複数のストリームをマルチキャストで配信する（ステップ２０２）。この際の配信はマルチキャストに代えてユニキャストでもよい。また、中継手段１０３は、他の配信サーバ（図示せず）からも同時にストリームを受信してもよい。

ユーザがリモコン等を用いてあるストリームを選択すると、そのストリームを視聴希望ストリームとして、端末１０７より中継手段１０３に視聴希望ストリームを要求する（ステップ２０３）。要求時にはストリームを識別する情報を付与する。ストリームを識別する情報は、そのストリームをチャンネルとして識別するチャンネル番号を用いたり、そのストリームを受信するためのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）やＩＰアドレスを用いてもよい。

中継手段１０３は、ザッピング先予測手段１１１に対して、端末１０７より受信した視聴希望ストリームに必要な帯域幅の確保を要求する帯域確保要求を行う（ステップ２０４）。必要な帯域幅は、中継手段１０３で受信している複数のストリームから、視聴希望ストリームに該当するストリームの平均レート等を用いてもよいし、あらかじめストリーム情報が別途与えられている場合には、その情報を参照して決定してもよい。ザッピング先予測手段１１１は、受信した視聴希望ストリームが、前回の要求成功時に記録した予測ストリームと同じものかどうかを判定する（ステップ２０５）。

ステップ２０５での判定の結果、同じであれば、ザッピング先予測手段１１１は、帯域管理手段１０９に対して、前回予測時に確保したストリームのうち今回視聴希望に該当しないストリーム分の帯域解放要求と、端末１０７が現在ストリーム受信に使用している帯域の帯域解放要求と、ユーザの嗜好情報によって、次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行う（ステップ２０６）。ユーザの嗜好情報によるザッピング先予測は以下のように行う。ザッピング先予測手段１１１はユーザの視聴履歴や性別、年齢層、およびキーワードを嗜好情報として保持する。該キーワードとしては、タイトル、ジャンル、出演者名、脚本・監督名、番組情報中の単語、インターネットを用いた通信販売の購買履歴があり、ユーザがあらかじめザッピング先予測手段１１１に登録してもよいし、ザッピング先予測手段１１１が自動で蓄積してもよい。また、それぞれの嗜好情報には重みを付けてもよい。該嗜好情報をもとに中継手段１０３で受信している複数のストリームそれぞれに対してユーザとの嗜好の合致度を算出し、合致度が高いものをザッピング先の候補とする。予測したザッピング先の候補数は、中継手段１０３と端末１０７の間にある、配信経路１０４や１０６、帯域制御手段１０５のスペックによって定めてもよい。すなわち帯域幅にもともと余裕がない配信経路設計の場合には予測したザッピング先の候補を１つに限定し、余裕がある配信経路設計の場合には予測したザッピング先の候補を２や３に設定する等である。

ステップ２０５での判定の結果、同じでなければ、ザッピング先予測手段１１１は、帯域管理手段１０９に対して、前回予測時に確保した予測ストリーム分の帯域解放要求と、現在端末１０７がストリーム受信に使用している帯域の帯域解放要求と、視聴希望ストリームに必要な帯域確保要求と、ユーザの嗜好情報によって次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行う（ステップ２０７）。

ステップ２０６およびステップ２０７で同時に行っている各帯域解放要求や各帯域確保要求は手順の一例であり、各要求を個別に順序立てて実施してもよい。また、実施タイミングもそれぞれずらしてよい。例えば、ステップ２０６の例では、ステップ２１０で受付結果を中継手段１０３に通知した後に、予測に外れたストリームの帯域解放要求と新たな予測ストリームの帯域確保要求とを行ってもよいし、また端末１０７が現在受信しているストリームの帯域解放要求はステップ２１０の後やステップ２１１の後やステップ２１２の後や端末１０７が新たなストリームの受信に成功してから（図示せず）行ってもよい。ステップ２０７についても同様である。

帯域管理手段１０９は要求された帯域確保要求または帯域解放要求に応じて帯域制御手段１０５に帯域制御を指示する（ステップ２０８）。この時、帯域確保要求や帯域解放要求に失敗した場合にはステップ２０８では帯域制御手段１０５に対して何も指示しないことにしてもよい。またその場合には、ステップ２０９、ステップ２１０、ステップ２１１、ステップ２１２では、視聴希望ストリームや新旧の予測ストリームに関して、端末１０７からは要求がなかったように振る舞い、端末１０７での現在の受信が途切れないようにしてもよい。その場合でも要求が失敗したことは、ステップ２０９、ステップ２１０、ステップ２１１において通知し、端末１０７に対して失敗したことが伝わるようにしてもよい。
ザッピング先予測手段１１１は、中継手段１０３に対して、視聴希望ストリームの帯域確保要求受付結果を通知する（ステップ２１０）。

中継手段１０３は、端末１０７に対して、視聴希望ストリームの帯域確保要求受付結果を通知する（ステップ２１１）。中継手段１０３は、ステップ２１０の受付結果が成功と通知された場合、要求された視聴希望ストリームを端末１０７にユニキャストで配信する（ステップ２１２）。この時、ユニキャストに代えてマルチキャストで配信してもよい。この際のマルチキャストによる配信は、他の端末（図示せず）が同時に中継手段１０３と接続されている場合に効果がある。すなわち、配信経路１０４や配信経路１０６、帯域制御手段１０５の能力が複数の端末に対してそれぞれユニキャストするのに十分な帯域や性能のない場合に、複数の端末で同じ映像音声ストリームを同時視聴する場合には、その同じ映像音声ストリームをマルチキャストで配信してもよい。

また、帯域管理手段１０９における帯域確保時に、帯域制御手段１０５に十分な空きリソースが無い場合には、予測映像音声ストリーム分の帯域については、仮想的なリソースに対する帯域確保として処理するようにしてもよい。その場合、帯域制御手段１０５で実際に予測映像音声ストリームが次に視聴する映像音声ストリームとして確定した段階で、実ストリームとして配信可能なように、帯域制御手段１０５や帯域管理手段１０９やザッピング先予測手段１１１で、実ストリームとして配信する接続を切り替える処理を含んでもよい。例えば、実ストリームとして確定した際には、ザッピング先予測手段１１１から帯域管理手段１０９に確定を通知し、帯域管理手段１０９は帯域制御手段１０５に切り替え指示を行うようにしてもよい。

なお、上記全てのフローを通じて、帯域確保、帯域解放の際には接続端末のフィルタリング処理（アクセス制御）を伴ってもよい。例えば、帯域制御手段１０５にファイアウォール機能を搭載する場合には、該当ストリームの帯域確保を行う際に、そのストリームを受信する端末と送信する配信サーバ間との通信が可能になるようにパケットフィルタリングを設定してもよい。また、同様に、帯域解放の際には、そのストリームを受信する端末と送信する配信サーバ間との通信が不可能になるようにパケットフィルタリングを設定してもよい。また、フィルタリング処理は帯域確保および帯域解放の前に行われても、同時に行われても、後に行われてもよい。

図３は図２の映像音声ストリーミング配信システムの具体例のブロック図である。

中継装置３０３は、マルチキャストを終端しユニキャストに変換するマルチキャスト終端ユニット３０４と、次に選択されるストリームを予測するザッピング先予測ユニット３１０から構成される。マルチキャスト終端ユニット３０４とザッピング先予測ユニット３１０はプログラムによる実装を示しており、各プログラム間を接続する論理的な通信パス３０９によって通信する。ＩＰＴＶ配信サーバ３０１は、イントラネット３０２を介してマルチキャスト終端ユニット３０４（中継装置３０３内）と接続する。マルチキャスト終端ユニット３０４はイントラネット３０５を介してルータ３０６と接続する。ルータ３０６は、パケット優先制御機能とアクセス制御機能を有するルータであり、パケット優先制御機能は特定パケットの帯域をコントロールする機能を、アクセス制御機能はパケットを流してよいソースやディスティネーションを指定することが可能である。ルータ３０６は公衆電話回線（ＡＤＳＬ）を介してＩＰＴＶ受信端末３０８と接続する。リソース受付制御サーバ３１２は、イントラネット３１３を介してルータ３０６のパケット優先制御機能とアクセス制御機能を制御する。また、イントラネット３１１を介してザッピング先予測ユニット３１０（中継装置３０３内）からルータ制御要求を受け付ける。

図４は、ＩＰＴＶ受信端末３０８を操作するリモコンの一構成例である。

リモコン４０１は電源ボタン４０２とチャンネル逆送りボタン４０３とチャンネル順送りボタン４０４とボリューム減少ボタン４０５とボリューム増加ボタン４０６とチャンネル指定ボタン群４０７から構成される。

チャンネル指定ボタン群４０７の各ボタンには、ＩＰＴＶ配信サーバ３０１より配信されている複数の映像音声ストリームＡ〜Ｌまでが順に割り当てられている。すなわち、チャンネル１には映像音声ストリームＡが、チャンネル２には映像音声ストリームＢが、チャンネル３には映像音声ストリームＣが、チャンネル４には映像音声ストリームＤが、チャンネル５には映像音声ストリームＥが、チャンネル６には映像音声ストリームＦが、チャンネル７には映像音声ストリームＧが、チャンネル８には映像音声ストリームＨが、チャンネル９には映像音声ストリームＩが、チャンネル１０には映像音声ストリームＪが、チャンネル１１には映像音声ストリームＫが、チャンネル１２には映像音声ストリームＬが、それぞれ割り当てられている。

チャンネル逆送りボタン４０３を操作すると、ＴＶのチャンネルに相当する操作として、現在視聴中の映像音声ストリームに対して隣接する、チャンネル番号の小さい映像音声ストリームを再生するよう要求する。すなわち、現在映像音声ストリームＣが視聴中である場合にチャンネル逆送りボタン４０３を押下すると、映像音声ストリームＢが視聴される。この場合、チャンネル指定ボタン群５０７のボタン「２」を操作したのと同じ効果が得られる。

チャンネル順送りボタン４０４を操作すると、ＴＶのチャンネルに相当する操作として、現在視聴中の映像音声ストリームに対して隣接する、チャンネル番号の大きい映像音声ストリームを再生するよう要求する。すなわち現在映像音声ストリームＣが視聴中である場合にチャンネル順送りボタン４０４を押下すると、映像音声ストリームＤが視聴される。この場合、チャンネル指定ボタン群４０７のボタン「４」を操作したのと同じ効果が得られる。

次に、本具体例の動作について説明する。
ＩＰＴＶ配信サーバ３０１は、マルチキャスト終端ユニット３０４に対して、１２本の映像音声ストリームＡ〜Ｌ（図示せず）をマルチキャストで送信中である。また、ザッピング先予測ユニット３１０が保持している嗜好情報をもとに該映像音声ストリームＡ〜Ｌそれぞれに対してユーザとの嗜好の合致度を算出した結果、合致度の高い上位５ストリームは高い順にＡ、Ｂ、Ｃ、Ｄ、Ｅであるものとし、ザッピング先の候補数は２であることとする。そして、現在ＩＰＴＶ受信端末３０８で受信している映像音声ストリームは、映像音声ストリームＤであるものとし、前回リモコン４０１操作時に映像音声ストリームＡとＢが予測され、ＡとＢは帯域確保がなされた状態であることとする。

ユーザがリモコン４０１を操作し、チャンネル指定ボタン群４０７のボタン「１」を押下すると、ＩＰＴＶ受信端末３０８はマルチキャスト終端ユニット３０４に、視聴要求（映像音声ストリームＡ）を送信する。マルチキャスト終端ユニット３０４はザッピング先予測ユニット３１０に前記視聴要求を送信する。

ザッピング先予測ユニット３１０では、前回視聴要求受付時に映像音声ストリームＡを予測映像音声ストリームとし、ルータ３０６を介した配信に必要な帯域確保およびアクセス制御を実施済みである。そこでザッピング先予測ユニット３１０では、再度嗜好の合致度の計算を行い、次の予測映像音声ストリームとして映像音声ストリームＡ以外でユーザの嗜好との合致度が高い映像音声ストリームＢとＣを設定する。次に、ザッピング先予測ユニット３１０は、映像音声ストリームＡ、Ｂ、Ｃを配信するために必要な帯域確保およびアクセス可能設定要求（映像音声ストリームＡとＢは継続、Ｃは新規）と、不要となった映像音声ストリームＤの帯域解放およびアクセス不可能設定要求を行う。

リソース受付制御サーバ３１２では、ザッピング先予測ユニット３１０からの要求に従い、ルータ３０６に、映像音声ストリームＤの帯域解放およびアクセス不可能設定要求を、映像音声ストリームＡ、Ｂ、Ｃの帯域確保（映像音声ストリームＡとＢは継続、Ｃは新規）およびアクセス可能設定要求を行う。ここでは、この要求に対してルータ３０６から要求受付成功が返信されたものとする。そこで、リソース受付制御サーバ３１２はザッピング先予測ユニット３１０に対して要求受付成功を送信する。

ザッピング先予測ユニット３１０では、リソース受付制御サーバ３１２からの要求受付成功を受信したため、リソース受付制御サーバ３１２に要求した新たな視聴中の映像音声ストリームＡおよび映像音声ストリームＡ以外でユーザの嗜好との合致度が高い映像音声ストリームＢとＣをそれぞれ確定し、マルチキャスト終端ユニット３０４に要求受付成功を送信する。

マルチキャスト終端ユニット３０４は、ザッピング先予測ユニット３１０から返信された要求受付成功を受け、現在ルータ３０６を介してＩＰＴＶ受信端末３０８にユニキャストで送信している映像音声ストリームＤを停止し、替わりに映像音声ストリームＡを送信開始する。

ＩＰＴＶ受信端末３０８は新たな映像音声ストリームＡを受信開始し、再生する。

上記具体例におけるザッピング先予測ユニット３１０は、中継装置３０３に替えてリソース受付制御サーバ３１２に含まれていてもよい。この場合、マルチキャスト終端ユニット３０４でＩＰＴＶ受信端末３０８からの前記視聴要求を受信した際に、ザッピング先予測ユニット３１０（リソース受付制御サーバ３１２内）に視聴要求を行なう。ザッピング先予測ユニット３１０は、前記具体例と同様にリソース受付制御サーバ３１２内にある帯域やアクセスの管理ユニット（図示せず）に前記具体例における帯域確保要求およびアクセス設定要求を行う。

また、前記具体例においては、ＩＰＴＶ受信端末が一つの場合について説明したが、複数のＩＰＴＶ受信端末が中継装置３０３に同時に接続していてもよく、この場合のＩＰＴＶ受信端末はＩＰＴＶ受信端末３０８と同様に動作するものとする。また、ルータ３０６は前記の複数のＩＰＴＶ受信端末の視聴要求・応答や映像音声ストリームを同時に制御できるようにしてもよい。

また、ＩＰＴＶ配信サーバ３０１からマルチキャストで送信される複数の映像音声ストリームを複数の中継装置で同時に受信し、各中継装置にはそれぞれ１つ以上のＩＰＴＶ受信端末が接続していてもよい。この場合の各中継装置は中継装置３０３と同様に動作し、各ＩＰＴＶ受信端末はＩＰＴＶ受信端末３０８と同様に動作するものとする。

また、中継装置３０３とＩＰＴＶ受信端末３０８間の視聴要求・応答や映像音声ストリームを一つのセッションとして捉えた場合、ルータ３０６は、複数の中継装置、複数のＩＰＴＶ受信端末で発生する複数のセッションを同時に制御できるようになっていてもよい。
また、ルータ３０６を複数設置し、それぞれが１つ以上のセッションを制御する場合、その複数設置されたルータを１台のリソース受付制御サーバ３１２で制御してもよいし、複数台のリソース受付制御サーバで制御してもよい。この場合、前記の具体例におけるザッピング予測ユニット３１０が、自身のセッションを制御するルータ３０６を管理するリソース受付制御サーバ３１２の特定方法を知っているものとする。リソース受付制御サーバ３１２の特定方法としては、起動時設定ファイルで固定的にアドレスを保持しておく方法等により実現してもよい。また、ザッピング先予測ユニット３１０がリソース受付制御サーバ３１２内にある場合には、マルチキャスト終端ユニット３０４が、自身のセッションを制御するルータ３０６を管理するリソース受付制御サーバ３１２内のザッピング先予測ユニットの特定方法を知っているものとする。前記ザッピング先予測ユニットの特定方法についても、起動時設定ファイルで固定的にアドレスを保持しておく方法等により実現してもよい。

また、ＩＰＴＶ配信サーバ３０１からマルチキャスト終端ユニット３０４に配信される映像音声ストリームはマルチキャストに替えてユニキャストで配信してもよい。

また、中継装置３０３は複数のＩＰＴＶ配信サーバから同時に映像音声ストリームを受信し、それぞれの映像音声ストリームの中からＩＰＴＶ受信端末３０８から視聴要求のあった映像音声ストリームをＩＰＴＶ受信端末３０８に送信してもよい。

また、リソース受付制御サーバ３１２への前記帯域確保要求、前記帯域解放要求、前記アクセス制御設定要求は、ザッピング先予測ユニット３１０に替えてマルチキャスト終端ユニット３０４が行ってもよい。この場合、ザッピング先予測ユニット３１０で予測映像音声ストリームを設定した際に、その情報をマルチキャスト終端ユニット３０４に返信し、マルチキャスト終端ユニット３０４がその情報を利用して必要な帯域確保要求、帯域解放要求、アクセス制御設定要求をリソース受付制御サーバ３１２に対して送信し、その返答を受信するよう動作する。

なお、ザッピング先予測ユニット３１０、リソース受付制御サーバ３１２の機能は、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定時間プログラムを保持しているものを含む。

本発明によれば、配信サーバと端末とから構成される映像音声ストリームの配信システムに適用できる。

本発明の一実施形態による映像音声ストリーミング配信システムのブロック図である。図２の映像音声ストリーミング配信システムの動作を示すフローチャートである。図２の映像音声ストリーミング配信システムの具体例のブロック図である。ＩＰＴＶ受信端末３０８をユーザが操作するためのリモコンのユーザインタフェースを示す図である。従来技術による映像音声ストリーミング配信システムのブロック図である。

符号の説明

１０１配信サーバ
１０２配信経路
１０３中継手段
１０４配信経路
１０５帯域制御手段
１０６配信経路
１０７端末
１０８制御線
１０９帯域管理手段
１１０制御線
１１１ザッピング先予測手段
１１２制御線
２０１−２１１ステップ
３０１ＩＰＴＶ配信サーバ
３０２イントラネット
３０３中継装置
３０４マルチキャスト終端ユニット
３０５イントラネット
３０６ルータ
３０７公衆電話回線
３０８ＩＰＴＶ受信端末
３０９論理的な通信パス
３１０ザッピング先予測ユニット
３１１イントラネット
３１２リソース受付制御サーバ
３１３イントラネット
４０１リモコン
４０２電源ボタン
４０３チャンネル逆送りボタン
４０４チャンネル順送りボタン
４０５ボリューム減少ボタン
４０６ボリューム増加ボタン
４０７チャンネル指定ボタン群

Claims

端末と、当該端末に映像音声ストリームを配信する配信サーバとに通信回線を介して接続された中継装置が、
前記端末が受信中または選択した映像音声ストリームの次に選択する映像音声ストリームを予測し、
前記端末が受信中または選択した映像音声ストリームに加え、前記予測した映像音声ストリームの配信に必要なリソースを、当該端末による次の選択が行われる前に確保し、
前記予測した映像音声ストリームが、前記端末が次に選択する映像音声ストリームと一致した場合、当該端末に当該映像音声ストリームの配信を開始する、
リソース確保方法。
前記中継装置が、前記映像音声ストリームの予測に、ユーザの嗜好情報を使用する、請求項１に記載の、リソース確保方法。
前記中継装置が、
前記端末により選択された映像音声ストリームが、当該端末による選択前に予測した予測映像音声ストリームに含まれているか否かを判定し、
前記判定の結果、含まれていれば、リソースの管理を行う帯域管理手段に対して、前記予測映像音声ストリームのうち、前記端末により選択された映像音声ストリームを除いた映像音声ストリームのリソースの解放と、前記端末が現在ストリーム受信に使用しているリソースの解放とを要求し、
前記判定の結果、含まれていなければ、前記帯域管理手段に対して、前記予測映像音声ストリーム分のリソースの解放と、前記端末が現在ストリーム受信に使用しているリソースの解放とを要求する、請求項１または２に記載の、リソース確保方法。
前記中継装置が、前記リソースの確保および解放に際して前記端末のフィルタリング処理を行う、請求項１から３のいずれかに記載の、リソース確保方法。
端末と、映像音声ストリームを当該端末に配信する配信サーバとを中継する中継手段と、
前記端末が受信中または選択した映像音声ストリームの次に選択する映像音声ストリームを予測する予測手段を備え、
前記予測手段は、
前記端末が受信中または選択した映像音声ストリームに加え、前記予測した映像音声ストリームの配信に必要なリソースを、当該端末による次の選択が行われる前に確保し、
前記予測した映像音声ストリームが、前記端末が次に選択する映像音声ストリームと一致した場合、当該端末に当該映像音声ストリームの配信を開始する、中継装置。
前記予測手段は、前記映像音声ストリームの予測に、ユーザの嗜好情報を使用する、請求項５に記載の、中継装置。
前記予測手段は、
前記端末により選択された映像音声ストリームが、当該端末による選択の前に行なった予測の際にリソースを確保した予測映像音声ストリームに含まれているか否かを判定し、
前記判定の結果、含まれていれば、リソースの管理を行う帯域管理手段に対して、前記予測映像音声ストリームのうち、前記端末により選択された映像音声ストリームを除いた映像音声ストリームのリソースの解放と、前記端末が現在ストリーム受信に使用しているリソースの解放とを要求し
前記判定の結果、含まれていなければ、前記帯域管理手段に対して、前記予測映像音声ストリーム分のリソースの解放と、前記端末が現在ストリーム受信に使用しているリソースの解放とを要求する、請求項５または６に記載の、中継装置。
端末と、
前記端末に映像音声ストリームを配信する配信サーバと、
前記端末および前記配信サーバに通信回線を介して接続された中継装置と、を備え、
前記中継装置は、
前記端末が受信中または選択した映像音声ストリームの次に選択する映像音声ストリームを予測する手段と、
前記端末が受信中または選択した映像音声ストリームに加え、前記予測した映像音声ストリームの配信に必要なリソースを、当該端末による次の選択が行われる前に確保する手段と、
前記予測した映像音声ストリームが、前記端末が次に選択する映像音声ストリームと一致した場合、当該端末に当該映像音声ストリームの配信を開始する手段と、
を含む、配信システム。
前記予測手段は、前記映像音声ストリームの予測に、ユーザの嗜好情報を使用する、請求項８に記載の、配信システム。
端末と当該端末に映像音声ストリームを配信する配信サーバとに通信回線を介して接続された中継装置のコンピュータに、
前記端末が受信中または選択した映像音声ストリームの次に選択する映像音声ストリームを予測する手順と、
前記端末が受信中または選択した映像音声ストリームに加え、前記予測した映像音声ストリームの配信に必要なリソースを、当該端末による次の選択が行われる前に確保する手順と、
前記予測した映像音声ストリームが、前記端末が次に選択する映像音声ストリームと一致した場合、当該端末に当該映像音声ストリームの配信を開始する手順と、
を実行させるためのプログラム。