JP3590376B2 - Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 - Google Patents
Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 Download PDFInfo
- Publication number
- JP3590376B2 JP3590376B2 JP2001367850A JP2001367850A JP3590376B2 JP 3590376 B2 JP3590376 B2 JP 3590376B2 JP 2001367850 A JP2001367850 A JP 2001367850A JP 2001367850 A JP2001367850 A JP 2001367850A JP 3590376 B2 JP3590376 B2 JP 3590376B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- user terminal
- qos
- resource
- band
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ケーブルインターネット上でＩＰストリーミングを利用して通信サービスを行うＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法に関する。
【０００２】
【従来の技術】
近年、ＣＡＴＶにおける双方向通信のインフラ整備に伴い、ケーブルインターネットを用いて、映像や音楽などのデータ通信サービスを提供することが行われている。
【０００３】
このようなデータ通信サービスは、インターネットの特性上、ユーザの利用状況に応じて回線条件が変動するベストエフォート型のサービスとなっている。
【０００４】
そこで、データ通信サービスの提供業者では、例えば下り方向のデータ伝送速度がユーザ当たり最大１．５Ｍｂｐｓのサービスを提供しようとする場合、各ユーザ毎にケーブルルータと称するＣＭＴＳ（Ｃａｂｌｅ Ｍｏｄｅｍ Ｔｅｒｍｉｎａｔｉｏｎ Ｓｙｓｔｅｍ；ケーブルモデム終端装置）を用いて、下り方向の単位時間当たりのトラフィックを測定し、ある時間の平均値が１．５Ｍｂｐｓを越えた場合、下り方向のトラフィックを一時停止するなどの方法をとり、データ通信サービスを提供している。
【０００５】
【発明が解決しようとする課題】
しかしながら、以上のようなデータ通信サービスでは、インターネット上で映像等マルチメディアコンテンツを送信し、リアルタイムに再生可能なＩＰストリーミングを利用した放送システムであっても、当該マルチメディアコンテンツを確実に配信することが難しい。
【０００６】
この発明においてＩＰストリーミングとは、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌを利用して映像や音声等のコンテンツをＩＰパケットとして配信し、ユーザ側にてコンテンツを再生する技術全般を指し、ユーザ側でＩＰパケットをメモリに受信して再生する狭義のＩＰストリーミングと、ユーザ側で一部か全てのコンテンツを一旦ＨＤＤ等に蓄積した後に再生を開始する疑似ＩＰストリーミングの双方の方法を含む。
【０００７】
本発明は上記事情に鑑みてなされたもので、ユーザからのコンテンツの視聴要求に対し、ネットワークの資源の使用状況をチェックし、ＱｏＳ（Quality of Service：サービス品質）を確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信するＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
（１） 上記課題を解決するために、各ユーザ端末からＣＭＴＳ及びネットワークを介して送信されてくるコンテンツ視聴要求に基づき、配信サーバが視聴要求のあったコンテンツをユーザ端末に配信するＩＰストリーミングシステムにおいて、
前記視聴要求のあったコンテンツを配信するに先立ち、当該コンテンツを配信するためのＱｏＳが確保可能か否かの問い合わせを送出する前記配信サーバと、
前記各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、前記システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、前記ユーザ端末からのコンテンツ視聴要求のもとに、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を前記配信サーバに通知するとともに、ＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を前記配信サーバに通知する手段とを設けたポリシーサーバとを備えたＩＰストリーミングシステムの構成である。
【０００９】
本発明は以上のような構成とすることにより、ナビゲーションサーバがユーザ端末から要求元情報のもとに視聴要求コンテンツを受けると、配信サーバに通知する。この配信サーバは、要求元情報及び視聴要求コンテンツに基づき、配信情報データベースからコンテンツの必要帯域情報を読み出し、要求元情報とともに、ポリシーサーバに配信すべきコンテンツのＱｏＳが確保可能か否かについて問い合わせをする。ここで、ポリシーサーバは、コンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況およびユーザ端末が接続される前記ケーブルの周波数帯域の使用状況を判断するので、ＱｏＳ実現のためにリソースの使用状態および周波数帯域の状態を判断し、両方が適切な状態にあれば、ＱｏＳ確保可能と判断し、配信サーバに視聴要求のあったコンテンツの配信が可能であることを通知するので、ＱＯＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信することができる。
【００１０】
なお、ＱｏＳ実現のためにリソースの使用状態および周波数帯域の状態を判断処理機能を各ＣＭＴＳにもたせることも可能である。
【００１１】
（２） また、本発明に係るポリシーサーバは、各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、ユーザ端末からのコンテンツ視聴要求のもとに、外部から要求元情報、必要帯域情報を受けると、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記外部から要求元情報、必要帯域情報を受けると、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を判断し、またＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を算出する手段とを備えた構成である。
【００１２】
この発明は以上のような構成とすることにより、ポリシーサーバが配信サーバなどの外部から要求元情報、必要帯域情報を受けると、リソース管理記憶手段を参照し、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断し、また周波数管理記憶手段を参照し、視聴要求のあったユーザ端末に接続されるラインにおける周波数帯域の空き有無を判断するので、配信サーバにＱｏＳを確保可能であることを知らせることができる。
【００１４】
さらに、ポリシーサーバにリソース管理記憶手段および周波数管理記憶手段を設け、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無およびユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断したが、例えばネットワーク中継装置である例えばＣＭＴＳにリソース管理記憶手段および周波数管理記憶手段を設け、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無およびユーザ端末に接続されるラインにおける周波数帯域の空き有無を判断する場合でも、前述するポリシーサーバと同様の作用効果を奏することが可能である。
【００１５】
（３） 本発明に係るＩＰストリーミング配信方法は、コンテンツの視聴要求を行う複数のユーザ端末が接続されるケーブルを収容する複数のＣＭＴＳと当該視聴要求コンテンツのストリーミング配信を実行するヘッドエンドシステムとがネットワークデ接続されているＩＰストリーミングシステムにおいて、あるユーザ端末から要求元情報のもとにメニュー画面要求を受けた場合、当該ユーザ端末にメニュー画面を送信し、当該ユーザ端末から視聴要求コンテンツを受け付けるコンテンツ要求受付けステップと、このステップにより視聴要求コンテンツを受付けると、予め記憶される配信要求コンテンツ、当該コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、前記ヘッドエンドシステムが収容するポリシーサーバにＱｏＳ確保可能かを問い合わせる問合せステップと、このステップにより問い合わせを受けた場合、ポリシーサーバがリソース管理記憶手段に記憶される前記要求元ユーザ端末までのネットワーク経路に存在するリソース情報及びリソース使用に関係する時間情報を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断するリソース確保判断ステップと、問い合わせステップにより問い合せを受けると、システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段を参照し、前記ユーザ端末が接続されたケーブルにおける周波数帯域の空き有無を判断する帯域確保判断ステップと、前記各判断ステップによりＱｏＳ確保可能と判断されたとき、前記ヘッドエンドシステムが前記視聴要求コンテンツを前記要求元ユーザ端末に配信するステップと、前記各判断ステップによりＱｏＳ確保が否と判断されたとき、前記リソース使用及び帯域使用に関係する時間情報から配信可能時間を取得するステップとを有する方法である。
【００１６】
このようなストリーミング配信方法であっても、コンテンツ要求受付けステップで視聴要求を受付けると、問合せステップにて予め記憶されるコンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、ポリシーサーバにＱｏＳ確保可能かを問い合わせるので、ポリシーサーバがリソース管理記憶手段に記憶される前記要求元ユーザ端末までのネットワーク経路に存在するリソース情報を参照しコンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況およびユーザ端末が接続される前記ケーブルの周波数帯域の使用状況を判断するので、ＱｏＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信することが可能となる。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態を説明するに先立ち、例えば米国の放送システムについて説明する。
【００１８】
（１） 米国の放送システムの現状について。
【００１９】
アナログ地上波をケーブル上にブロードキャストする米国の放送システムでは、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）で利用可能な周波数帯のうち、５０ＭＨｚ〜４５０ＭＨｚの周波数範囲で利用されているが、この場合には１チャンネル当たり６ＭＨｚ程度の帯域が割当てられている。
【００２０】
一方、ケーブルインターネットを用いて、データ通信を行う場合、４５０ＭＨｚ以外の帯域、例えば５００ＭＨｚ〜６００ＭＨｚの周波数帯域が利用されている。すなわち、データ通信を行う場合、６ＭＨｚ帯域でディジタル変調であるＱＡＭ（Ｑｕａｄｒａｔｕｒｅ Ａｍｐｌｉｔｕｄｅ Ｍｏｄｕｌａｔｉｏｎ：直交振幅変調）変調が利用され、またＣＭＴＳやＩＰＢ（ＩＰストリーミング用セットトップボックス）のごときＩＰストリーミング対応装置の内部に実装されているチューナは前述する６ＭＨｚ帯毎にチューニングされている。このＱＡＭ方式は、正弦搬送波のパラメータである振幅、位相、周波数のうち、振幅と位相の２つのパラメータを同時に変調することにより、狭い帯域幅の中で多くのデータを搬送できる方式である。因みに、ケーブルインタネットで主に使用されるＱＡＭ変調には６４ＱＡＭ方式と２５６ＱＡＭ方式とがあるが、例えば６４ＱＡＭ方式の場合には約２７Ｍｂｐｓの伝送レートが得られる。現在、多数のユーザが２７Ｍｂｐｓの伝送帯域を共有する形でデータ通信サービスが行われている。
【００２１】
（２） 本発明に係るＩＰストリーミングシステムの構成について。
【００２２】
図１は本発明に係るＩＰストリーミングシステムの一実施の形態を示す構成図である。
【００２３】
このＩＰストリーミングシステムは、多種類のマルチメディアコンテンツを蓄積し、ユーザからの視聴要求に応じた配信処理を実行するヘッドエンドシステム１０と、例えばリング状の接続構成をとるネットワーク２０と、複数のディストリビューションＨＵＢ３０とが設けられ、これら各ディストリビューションＨＵＢ３０に収容されるＲＦケーブル４０にＩＰＢ５１を介してユーザ端末５２が接続されている。本発明では、ユーザ端末と呼ぶ場合には、ＩＰＢ５１とユーザ端末５２との組み合わせが対象となる。
【００２４】
また、ディストリビューションＨＵＢ３０とユーザ端末５２がもつＩＰＢ５１との間は、ＲＦケーブル４０だけでは距離が制限されることから、光信号に変換し距離を延長するために、電気−光変換器、ＨＦＣ（Ｈｙｂｒｉｄ Ｆｉｂｅｒ／Ｃｏａｘ）ネットワーク、光−電気変換器などが用いられるが、ここでは本発明の要旨と関連性が薄いことから省略する。
【００２５】
このヘッドエンドシステム１０は、ナビゲーションサーバ１１、配信サーバ１２、ポリシーサーバ１３およびＱｏＳを提供可能なルータ１４が設けられている。
【００２６】
なお、ＣＭＴＳ３１が１つで構成される場合には、ＣＭＴＳ３１を含めてヘッドエンドシステムと呼ぶ場合もある。
【００２７】
このナビゲーションサーバ１１は、当該サーバ１１自体が所有するメニューを容易に閲覧可能なＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ：電子プログラム・ガイド）およびナビゲーションクライアントソフトウエア等の間で連携をとりながら、ユーザが視聴を希望するコンテンツの種類を受理し、配信サーバ１２に通知する役割をもっている。
【００２８】
配信サーバ１２は、多種類のマルチメディアコンテンツの他、各コンテンツの配信に必要な帯域情報、配信必要時間情報その他配信に必要な情報を蓄積する大容量の配信情報データベース１５を有し、当該データベース１５に蓄積されるマルチメディアコンテンツを含む配信情報を管理する一方、ナビゲーションサーバ１１から配信通知を受けると、ポリシーサーバ１３に対し、コンテンツを配信するためのＱｏＳが確保可能か否かの問い合せを実施し、ＱＯＳが確保可能な場合、ユーザに対して希望するコンテンツを配信する機能をもっている。
【００２９】
ポリシーサーバ１３は、リソース管理データベース１６及び周波数管理データベース１７を有し、配信サーバ１２からＩＰアドレスなどの要求元情報、必要帯域情報をもとにＱｏＳ確保に関する問い合せを受けると、要求元ユーザに対してコンテンツを配信するために、ＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ実現のためのリソースを管理するリソース管理データベース１６及びシステム全体の周波数帯域を管理する周波数管理データベース１７の格納データからＣＭＴＳ３１を含むネットワーク中継関連装置の利用状況および要求元ユーザ端末が接続されるＲＦケーブルごとの周波数帯域の使用状況を判断し、ネットワーク経路のＱｏＳ確保および配信要求元ユーザの接続されるＲＦケーブルの帯域確保を行う機能をもっている。なお、リソース管理データベース１６及び周波数管理データベース１７はそれぞれ個別に独立したデータベースである必要がなく、同一のデータベースにエリア分けして必要な情報を記憶する構成であってもよい。
【００３０】
ルータ１４は、ＩＰパケットのヘッダをチェックし、前述するようにＱｏＳが確保可能な状態で中継するものであって、キューメカニズムやスケジュール管理メカニズムを有し、同一宛先トラフィックに対しても各ＩＰパケットに定義されるフローごとに管理する。また、ルータ１４は、配信サーバ１２から送信されるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に基づき、ルーター間の特定の通信チャンネルの伝送帯域を管理し、必要なＱｏＳを実現のためのリソースを確保する機能をもっている。
【００３１】
前記ネットワーク２０は、ストリーミング配信を実行するために必要な各種サーバ１１〜１３群を収容するヘッドエンドシステム１０と遠隔地に設置されるＣＭＴＳ３１を収容する多数のディストリビューションＨＵＢ３０とを接続する例えば光ファイバがリング状に形成された伝送ラインとなっている。
【００３２】
各ディストリビューションＨＵＢ３０は、多数のユーザの配信拠点となる部分であり、ＲＦケーブル４０を収容するリピータ機能或いはスイッチング機能をもったＬＡＮの集線装置としての役割を果たすものであって、少なくともＣＭＴＳ３１が収容されている。このＣＭＴＳ３１は一種のネットワーク中継装置である。
【００３３】
このＣＭＴＳ３１は、基本的にはＲＦインタフェースを有し、ルータ１４と同様の機能を有するケーブルルータである。つまり、ルータ１４と同様にキューメカニズムやスケジュール管理メカニズムが設けられている。
【００３４】
前記ＩＰＢ（ＩＰストリーミング用セットトップボックス）５１は、視聴要求コンテンツに対応するＩＰパケットを受信し、当該パケットに含まれるアプリケーションなど、上位の映像、音声に係るデータをＣＯＤＥＣ（コード・デコード）に従ってデコード処理を実施し、テレビジョンＴＶ、ＣＲＴや液晶のモニタを含むユーザ端末５２に表示する機能をもっている。
【００３５】
従って、以上のようなＩＰストリーミングシステムの実施の形態によれば、ポリシーサーバ１３にＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ実現のためのリソースを管理するリソース管理データベース１６及びシステム全体の周波数帯域を管理する周波数管理データベース１７を設け、ＩＰＢ５１を含むユーザ端末５２からコンテンツ視聴要求をナビゲーションサーバ１１で受けると、配信サーバ１２に通知し、配信情報データベース１５から視聴要求コンテンツに関する必要帯域情報、配信に必要な時間情報を要求元情報とともに、ＱｏＳ確保可能か否かをポリシーサーバ１３に問い合わせる。このポリシーサーバ１３は、リソース管理データベース１６を参照し、ＣＭＴＳ３１を含むネットワーク中継関連装置の利用状況を判断し、また周波数管理データベース１７を参照し、要求元ユーザ端末が接続されるＲＦケーブルごとの周波数帯域の使用状況を判断するので、ネットワーク経路のＱｏＳ確保および配信要求元ユーザの接続されるＲＦケーブルの帯域確保を行うことができ、ネットワーク資源を利用し、ＱｏＳを確保しながら視聴要求コンテンツをユーザ端末に配信することができる。
【００３６】
（３） リソース管理データベース１６及び周波数管理データベース１７の構成データ例について。
【００３７】
＊ リソース管理データベース１６について。
【００３８】
一般に、ＱｏＳを実現するためのネットワーク中継関連装置のリソースには制限があるので、ＱｏＳ保証可能な帯域にもおのずと限界がある。図１に示すヘッドエンドシステム１０に収容されるルータ１４、各ディストリビューションＨＵＢ３０に収容される例えばＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１が確保可能な帯域は、自身のＣＰＵやソフトウエアの処理能力により制限され、ＲＦインタフェース毎に１６Ｍｂｐｓの転送能力しかもっていない。さらに、ＱｏＳ管理単位であるフローの数がメモリの実装上の制約からキューの数が「３２」であるが、ＲＦインタフェース当たり３２本の異なるフローが処理可能である場合、例えばコンテンツの配信に必要な最低帯域が５００ｋｂｐｓとすれば、ＲＦインタフェース毎の転送能力である１６Ｍｂｐｓに対し、各ネットワーク中継関連装置のリソースは５００ｋｂｐｓにて３２本が限界である（図４の帯域番号参照）。
【００３９】
因みに、リソース管理データベース１６の構成データの一例としては、ユーザ名、ユーザ（ＩＰＢ）のＩＰアドレス、配信サーバ１２からの経路情報（例えばネットワーク中継装置名）、ネットワーク中継装置名、インタフェース名、帯域番号、使用帯域、使用開始時間、予想使用時間（或いは予想終了時間）、遅延時間等が挙げられる。
【００４０】
＊ 周波数管理データベース１７について。
【００４１】
ＣＭＴＳ３１のＲＦインタフェースは、チューナ１回路に付き１基本周波数（６ＭＨｚ）が使用可能である。前述したように６４ＱＡＭ方式の変調を使用した場合、伝送速度が２７Ｍｂｐｓとなる。このうち、各種プロトコルのオーバヘッドを考慮し、下り方向の実行速度を２０Ｍｂｐｓと見積もった場合、サービスを受けるユーザは当該速度範囲でなければならない。
【００４２】
因みに、周波数管理データベース１７の構成データの一例としては、ユーザ名、ユーザ（ＩＰＢ）のＩＰアドレス、ネットワーク中継装置名、インタフェース名、使用可能帯域、使用帯域数、使用開始時間、予想使用時間（或いは予想終了時間）、使用コンテンツアドレス（ＵＲＬ）等が挙げられる。
【００４３】
（４） 図１に示すシステムの動作ないし本発明に係るＩＰストリーミング配信方法について（図２、図３参照）。
【００４４】
先ず、ポリシーサーバ１３は、ＣＭＴＳ３１を含むネットワーク中継関連装置のＱＯＳを実現する為、当該装置における使用帯域等の情報をリソース管理データベース１６に格納し、またＲＦケーブル４０の周波数帯域等の情報を周波数管理データベース１７に格納するなどし、適切な管理を行うための初期化を実施する（Ｓ１：ポリシーサーバ初期化ステップ）。
【００４５】
この状態においてユーザがＩＰＢ５１を起動し、ＥＰＧのメニュー画面の要求操作を行うと、自身のＩＰアドレス等の要求元情報のもとにメニュー画面要求情報がＣＭＴＳ３１、ネットワーク２０を経由し、ナビゲーションサーバ１１に送られる（Ｓ２）。ここで、ナビゲーションサーバ１１は、画面要求に基づいて自身が所有するＥＰＧのメニュー画面を特定のユーザの要求元情報を所有するＩＰＢ５１に配信する（Ｓ３）。このメニュー画面はユーザ端末５２に表示される。ユーザはメニュー画面からジャンル毎（アクション、ドラマ）のボタンやシステムプロバイダーが推奨するコンテンツ等を見ることができる。
【００４６】
ここで、ユーザがユーザ端末５２に表示されるメニュー画面から特定の映像等マルチメディアコンテンツを指定すると、該当ＩＰＢ５１から自身の例えばＩＰアドレス等の要求元情報のもとに映像コンテンツ視聴要求が送信される。ヘッドエンドシステム１０のナビゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３１、ネットワーク２０を介して送られてくる要求元情報、映像コンテンツ視聴要求を受信し、コンテンツ視聴要求を受付ける（Ｓ４）。これらＳ２〜Ｓ４はコンテンツ要求受付けステップに相当する。
【００４７】
このナビゲーションサーバ１１は、ユーザによって指定された映像等のコンテンツの視聴要求を受信した後、配信サーバ１２に通知する（Ｓ５）。
【００４８】
この配信サーバ１２は、自身が管理する配信情報データベース１５から配信要求コンテンツ、当該コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、要求元（送信先）情報とともに、ポリシーサーバ１３に送信し、ＱｏＳ確保の観点から配信可能か否かを問い合わせる（Ｓ６）。これらステップＳ５，Ｓ６は問い合わせステップを意味する。
【００４９】
ここで、ポリシーサーバ（帯域ブローカ）１３は、要求元情報に基づいてリソース管理データベース１６から要求コンテンツを配信するためのネットワークの経路情報を取得し（Ｓ７）、さらに要求元情報および必要帯域情報（例えば５００ｋｂｐｓ等）をもとに要求元までのネットワーク経路に存在するＣＭＴＳ３１、ヘッドエンドシステム１０内のルータ１４を含む全てのネットワーク中継関連装置に関し、リソース管理データベース１６に格納される情報を参照し、５００ｋｂｐｓの帯域をもつＱｏＳ実現可能なリソースが有るか否かを判断する（Ｓ８）。リソース無しと判断されたとき、ポリシーサーバ１３は、配信サーバ１２に配信不可能と回答する。このとき、予想使用時間情報をもとに配信可能時間も回答する（Ｓ９）。そして、新たな外部から入力待ちの状態となる。
【００５０】
ポリシーサーバ１３は、ステップＳ８においてＱｏＳ実現のためのリソース有りと判断した場合、図４に示すようにリソース管理データベース１６に規定される項目のうち、例えば帯域番号特定、当該帯域番号対応使用帯域への「１」設定、使用開始時間の書込み等のなどの帯域使用情報を更新する（Ｓ１０）。これらステップＳ５〜Ｓ１０はリソース確保判断ステップに相当する。
【００５１】
さらに、ポリシーサーバ（帯域ブローカ）１３は、要求元情報および必要帯域情報をもとに、図５に示す周波数管理データベース１７を参照し、要求元ＩＰＢ５１が現在接続されているＲＦケーブル４０に対応するインタフェースに５００ｋｂｐｓ帯域の空きがあるか否かを判断する（Ｓ１１）。ここで、帯域に空きがない場合には配信不可能である旨を配信サーバ１２に回答するが、同時に予想使用時間情報をもとに配信可能時間も回答する。また、前述したステップＳ１０により確保したリソースを開放するために、リソース管理データベース１６をアップデータする（Ｓ１２）。
【００５２】
一方、ポリシーサーバ１３は、ステップＳ１１においてＲＦケーブル４０に対応するインタフェースに帯域に空きがあると判断された場合、要求元ユーザのコンテンツ配信要求がサービスの上限値を越えているか否かを判断し（Ｓ１３）、越えていないと判断された場合には配信サーバ１２に対して配信可能であることを回答するとともに、その帯域の利用分について周波数管理データベース１７を更新する（Ｓ１４）。これらステップＳ１１〜Ｓ１４は帯域確保判断ステップに相当する。
【００５３】
ここで、配信サーバ１２は、ポリシーサーバ１３から配信可能とする回答を受けると、ＲＳＶＰ等のプロトコルを用いて、ＣＭＴＳ３１を含むネットワーク中継関連装置の実際の使用帯域をチェックし、使用するリソースを確保する（Ｓ１５）。
【００５４】
このＲＳＶＰプロトコルとしては、通常、配信サーバ１２からｐａｔｈメッセージを送信し、当該ｐａｔｈメッセージの条件（帯域や遅延時間等）が正当であるか否かについてルータ１４、ＣＭＴＳ３１の順序で順次チェックしながら、コンテンツ配信要求元であるＩＰＢ５１まで到達する。このＩＰＢ５１は、エラーなしでｐａｔｈメッセージを受信すると、ｒｅｓｖメッセージを配信サーバ１２に向けて送信する。ＣＭＴＳ３１、ルータ１４は、ＩＰＢ５１から送信されるｒｅｓｖメッセージに基づいて実際のリソースを割当て予約する。
【００５５】
配信サーバ１２は、ｒｅｓｖメッセージを受けると、予約したネットワーク中継関連装置のリソースとＲＦケーブル４０の周波数帯を利用し、実際の映像等コンテンツを配信要求元のＩＰＢ５１に配信する（Ｓ１６）。ステップＳ１５，Ｓ１６はコンテンツ配信ステップを意味する。
【００５６】
配信サーバ１２は、コンテンツの送信を終了すると、ポリシーサーバ１３に対し、配信要求コンテンツに対する送信終了を通知する（Ｓ１７）。ポリシーサーバ１３は、送信終了情報を受け取ると、両管理データベース１６，１７の該当コンテンツ配信のために利用した帯域分の情報について開放する（Ｓ１８）。このステップＳ１７，Ｓ１８は帯域確保情報開放ステップを意味する。
【００５７】
従って、以上のようなＩＰストリーミング配信方法の実施の形態によれば、ユーザ端末側からの視聴要求コンテンツの受付けステップ、この受付けを行ったナビゲーションサーバ１１の配信サーバ１２への通知及び配信サーバによる配信コンテンツの必要帯域情報、配信するために必要な時間情報を取得し、ポリシーサーバ１３にＱｏＳ実現のための問合せを行う問合せステップ、さらにポリシーーバ１３によるリソース確保判断、使用帯域確保判断を行うステップ、何れも確保可能な場合に配信サーバ１２に通知するステップを採用することにより、リソース及び使用帯域を確保し、ＱｏＳを確保しつつ視聴要求コンテンツを確実に配信できる。
【００５８】
（５） ポリシーサーバ１３の実際の動作処理例について（図２〜図５参照）。
【００５９】
なお、サービスの前提としては、以下の＊に記述するような内容を設定する。
【００６０】
＊ コンテンツは、映像品質や音声品質等に応じて、５００ｋｂｐｓの整数倍の伝送レートが必要となるので、５００ｋｂｐｓ〜２Ｍｂｐｓまでの種類があるとする。例えば高品質映像コンテンツの場合は１Ｍｂｐｓ、中程度の品質の場合は５００ｋｂｐｓが必要となるという具合である。
【００６１】
＊ ポリシーサーバ１３にて、１サービス（例えば映画１本の視聴）毎にサービス使用の可否がリソース等の状況に応じて判断されるものとする。
【００６２】
＊ ＣＭＴＳ３１の１インタフェース毎（６ＭＨｚ帯当たり）の伝送速度は、６４ＱＡＭ変調方式の場合には２７Ｍｂｐｓであるが、各種プロトコルのオーバヘッドがあるので、有効速度は２０Ｍｂｐｓとする。
【００６３】
＊ ルータ１４、ＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１の確保可能な帯域は、インタフェース毎に１６Ｍｂｐｓであり、かつ、管理可能なフローの数は５００ｋｂｐｓで３２本とする。
【００６４】
＊ 通常、１つのＩＰＢ５１当たり最大２Ｍｂｐｓのベストエフォート型通信を保証するが、コンテンツ配信要求時は５００ｋｂｐｓの整数倍である最大例えば２Ｍｂｐｓまでの範囲でＱＯＳ管理に基づいた視聴が可能とする。
【００６５】
＊ ＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１の１インタフェース当たりに対し、ＩＰＢ５１の接続台数は５０台とする。すなわち、５０台中の２０％の使用率以上になると、各ユーザの使用可能な速度は２Ｍｂｐｓ以下となる（２０Ｍｂｐｓ÷（５０台の２０％）＝２Ｍｂｐｓ）。
【００６６】
以上のような設定条件のもとに実際のポリシーサーバ１３の詳細な動作について説明する。
【００６７】
▲１▼ 配信サーバ１２は、ナビゲーションサーバ１１からＩＰアドレス等の要求元情報のもとに映像コンテンツの配信要求を受けると、配信情報データベース１５に格納されるコンテンツ配信に必要な帯域情報（例えば５００ｋｂｐｓ）および配信必要時間情報（例えば２時間）を読み出し、要求元情報とともに、ポリシーサーバ１３に対して配信可能か否かの問い合わせを行う（図２のＳ６）。
【００６８】
▲２▼ ポリシーサーバ１３は、配信要求元ユーザが接続されているＣＭＴＳ（１）３１とインタフェースとを確認する為、要求元情報であるＩＰアドレスをキーとし、リソース管理データベース１６を用いて、配信サーバ１２からユーザＩＰＢ５１までのネットワーク経路情報、中継装置名（複数存在する場合には複数）、インタフェース名を検索する（図２のＳ７）。例えばユーザＡを指定し、ルータ１４／インタフェース１とＣＭＴＳ（１）３１／インタフェース１（図４参照）を取得する。
【００６９】
▲３▼ 次に、ポリシーサーバ１３は、ナビゲーションサーバ１１から受け取った要求元情報（通常，ＩＰアドレス）と必要帯域情報とをもとに、リソース管理データベース１６を参照し、要求元ＩＰＢ５１までのネットワーク中経路に存在するルータ１４とＣＭＴＳ（１）５１に帯域確保が可能か否かを判断する（図２のＳ８）。具体的には、図４に示すごとく、ＣＭＴＳ（１）／インタフェース１においては、ＣＭＴＳ（１）のＱｏＳ実現の為の全リソース３２本（５００ｋｂｐｓ）のうち、現在、帯域番号「１」，「２」，「３」しか使用されておらず、未だ十分に設定可能な状態にあることが分るので、今回の配信要求に対して帯域番号「４」を特定し、対応する使用帯域項目に「１」を設定し、使用開始時間を記入する。リソース管理データベース１６には図示されていないが、同様にルータ１４／インタフェース１についても実行する。
【００７０】
▲４▼ さらに、ポリシーサーバ１３は、要求元情報と必要帯域情報をもとに、周波数管理データベース１７を参照し、ＣＭＴＳ（１）／インタフェース１（要求元ＩＰＢが現在接続されているＲＦケーブル４０）に５００ｋｂｐｓ帯域の空きがあるか否かを判断する（図３のＳ１１）。具体的には、ＣＭＴＳ（１）／インタフェース１を指定し、ＲＦインタフェース当たりの周波数割り当てからくる制限（例えば合計２０Ｍｂｐｓ）と現在使用中の使用帯域との比較を行う。ここで、図５に示すごとく、ＣＭＴＳ（１）／インタフェース１のＲＦインタフェースの使用周波数帯域の合計は３であり、１．５Ｍｂｐｓの帯域より使用しておらず、２０Ｍｂｐｓ以下であるので、未だ周波数帯域の使用には問題がない。
【００７１】
▲５▼ 今回の配信要求元ユーザのＩＰアドレス（例えば１０．１．１．３）の使用帯域数は０となっており、各ユーザ毎に上限値２Ｍｂｐｓ以下となっているので、何ら問題なく空き帯域を使用できる（図３のＳ１３）。
【００７２】
▲６▼ ポリシーサーバ１３は、以上述べた２つのデータベース１６，１７の参照結果に基づき、配信サーバ１２に対し、今回ユーザＩＰＢ５１の配信要求に対する配信は可能であると回答する（図３のＳ１４）。
【００７３】
従って、以上のようなポリシーサーバ１３の実施の形態によれば、リソース管理データベース１６および周波数管理データベース１７の格納データを参照し、リソース確保および使用帯域確保を適切に判断でき、配信サーバ１２にコンテンツの配信に必要な適切な回答を提供できる。
【００７４】
（６） ＣＭＴＳ３１にリソース管理データベース３２及び周波数管理データベース１７を備えた場合の構成および動作処理例について。
【００７５】
前述するシステム例は、ポリシーサーバ１３によってリソース管理を一元管理する場合の構成例を述べたが、この例では、図６に示すように各ＣＭＴＳ３１にデータベース３２，３３を備えた構成となる。つまり、各ＣＭＴＳ３１から下流のリソース及び周波数帯域の管理については、個々のＣＭＴＳ３１が管理するデータベース３２，３３に必要な情報を格納し管理する例である。なお、これらデータベース３２，３３には前述するリソース管理データベース１６及び周波数管理データベース１７と同様な構成データを格納するものであり、とりわけ本発明の説明上必要な図４，図５と同様なデータを格納するものとする。
【００７６】
次に、データベース３２，３３を備えたＣＭＴＳ３１を含むシステムの動作について図７及び図８を参照して説明する。
【００７７】
先ず、ＣＭＴＳ３１は、動作を開始すると、ＱｏＳを実現する為、使用帯域等の情報やＲＦケーブル４０の周波数帯域等の情報を管理するための初期化を実行する（Ｓ２１：初期化ステップ）。
【００７８】
この状態においてユーザがＩＰＢ５１を起動し、ＥＰＧメニューの要求操作を行うと、自身のＩＰアドレス等の要求元情報のもとに画面要求情報がＣＭＴＳ３１、ネットワーク２０を経由し、ナビゲーションサーバ１１に送られる（Ｓ２２）。ここで、ナビゲーションサーバ１１は、ある特定のユーザの要求元情報を所有するＩＰＢ５１に配信する（Ｓ２３）。このＥＰＧメニュー画面はユーザ端末５２に表示される。ユーザはメニュー画面からジャンル毎（アクション、ドラマ）のボタンやシステムプロバイダーが推奨するコンテンツ等を見ることができる。
【００７９】
ここで、ユーザがユーザ端末５２に表示されるメニュー画面から特定の映像等マルチメディアコンテンツを指定すると、該当ＩＰＢ５１から自身の例えばＩＰアドレス等の要求元情報のもとに映像コンテンツ視聴要求が送信される。ヘッドエンドシステム１０のナビゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３１、ネットワーク２０を介して送られてくる要求元情報、映像コンテンツ視聴要求を受信し、視聴要求のあったコンテンツを受付ける（Ｓ２４）。これらＳ２２〜Ｓ２４はコンテンツ要求受付けステップに相当する。
【００８０】
このナビゲーションサーバ１１は、ユーザによって指定された映像等のコンテンツの視聴要求を受信した後、配信サーバ１２に通知する（Ｓ２５）。
【００８１】
この配信サーバ１２は、自身が管理する配信情報データベース１５から要求元情報をもとに、経路情報、コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、要求元（送信先）情報とともに、ポリシーサーバ１３に送信する（Ｓ２６）。
【００８２】
このポリシーサーバ１３は、要求元情報、経路情報、当該コンテンツの配信に必要な帯域情報、配信必要時間情報を受け取ると、これら要求元情報および必要帯域情報（例えば５００ｋｂｐｓ等）、配信必要時間情報等を要求元側ネットワーク経路に存在するＣＭＴＳ３１を通知しサービスを要求する（Ｓ２７）。
【００８３】
ここで、ＣＭＴＳ３１は、要求元情報をもとにインタフェース名を取得し（Ｓ２８）、このインタフェース名に基づいてリソースデータベース３２に格納される情報を参照し、該当インタフェース名にＱｏＳの観点から５００ｋｂｐｓの帯域確保が可能なリソースが存在するか否かを判断する（Ｓ２９）。帯域確保可能なリソースが存在しない場合、ＣＭＴＳ３１は、ポリシーサーバ１３に配信不可能と回答する。このとき、予想使用時間情報をもとに配信可能時間も回答する（Ｓ３０）。
【００８４】
ＣＭＴＳ３１は、ステップＳ２９においてＱｏＳ確保可能にリソースが存在すると判断した場合、図４に示すようにリソース管理データベース３２に規定される項目のうち、例えば帯域番号特定、当該帯域番号対応使用帯域への「１」設定、使用開始時間の書込み等のなどの帯域使用情報を更新する（Ｓ３１）。これらステップＳ２８〜Ｓ３１はリソース確保判断ステップに相当する。
【００８５】
さらに、ＣＭＴＳ３１は、要求元情報および必要帯域情報をもとに、図４に示す周波数管理データベース３３を参照し、該当インタフェースに５００ｋｂｐｓ帯域の空きがあるか否かを判断する（Ｓ３２）。ここで、帯域に空きがない場合にはリソース無しをポリシーサーバ１３に回答するが、同時に予想使用時間情報をもとに配信可能時間も回答する。また、前述したステップＳ３１により確保したリソースを開放するために、リソース管理データベース３２をアップデートする（Ｓ３３）。
【００８６】
一方、ＣＭＴＳ３１は、ステップＳ３２で該当インタフェースに空き帯域周波数があると判断された場合、要求元ユーザのコンテンツ配信要求がサービスの上限値を越えているか否かを判断し（Ｓ３４）、越えていないと判断された場合にはポリシーサーバ１３に配信可能であることを回答するとともに、その帯域の利用分について周波数管理データベース３３を更新する（Ｓ３５）。これらステップＳ３２〜Ｓ３５は帯域確保判断ステップに相当する。
【００８７】
ここで、ポリシーサーバ１３は、配信サーバ１２に配信可能を回答する（Ｓ３６）。この配信サーバ１２は、ポリシーサーバ１３から配信可能とする回答を受けると、ＲＳＶＰ等のプロトコルを用いて、ＣＭＴＳ３１を含むネットワーク中継関連装置の実際の使用帯域をチェックし、使用するリソースを確保する（Ｓ３７）。
【００８８】
つまり、配信サーバ１２からｐａｔｈメッセージを送信し、ルータ１４、ＣＭＴＳ３１の順序で順次チェックしながら、コンテンツ配信要求元であるＩＰＢ５１まで到達する。このＩＰＢ５１は、エラーなしでｐａｔｈメッセージを受信すると、ｒｅｓｖメッセージを配信サーバ１２に向けて送信する。
【００８９】
配信サーバ１２は、ｒｅｓｖメッセージを受けると、予約したネットワーク中継関連装置のリソースとＲＦケーブル４０の周波数帯を利用し、実際の映像等コンテンツを配信要求元のＩＰＢ５１に送信する（Ｓ３８：コンテンツ配信ステップ）。配信サーバ１２は、コンテンツの配信を終了すると、ポリシーサーバ１３を介してＣＭＴＳ３１に送信終了情報を送信する（Ｓ３９）。このＣＭＴＳ３１は、両管理データベース３２，３３の該当コンテンツ配信のために利用した帯域分の情報について開放する（Ｓ４０）。
【００９０】
従って、以上のようなネットワーク中継装置であるＣＭＴＳ３１の一実施の形態によれば、当該ＣＭＴＳ３１にポリシーサーバ１３と同様な情報を有するリソース管理データベース３２および周波数管理データベース３３を備えることにより、ＣＭＴＳ３１がこれらデータベース３２，３３の内容を参照し、ポリシーサーバ１３と同様な機能ないし作用効果を奏することができる。
【００９１】
なお、上記実施の形態は、ＱｏＳの実現のためにリソース管理データベース１６、周波数管理データベース１７を設けたが、何れか一方のデータベース１６または１７を設け、リソースまたは周波数の観点からＱｏＳを実現するようにしてもよい。
【００９２】
また、実施の形態では、ＣＭＴＳ３１側に両管理データベース３２，３３を設けたが、例えばＣＭＴＳ３１側に何れか一方の管理データベース３２または３３を設けてもよく、この場合には他方の管理データベース３３または３２はポリシーサーバ１３側に設置する。
【００９３】
さらに、ＣＭＴＳ３１側に両管理データベース３２，３３を設けた場合、システムからポリシーサーバ１３を削除する構成としてもよい。
【００９４】
その他、本願発明は、上記実施の形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変形して実施できる。また、各実施の形態は可能な限り組み合わせて実施することが可能であり、その場合には組み合わせによる効果が得られる。さらに、上記各実施の形態には種々の上位，下位段階の発明が含まれており、開示された複数の構成要素の適宜な組み合わせにより種々の発明が抽出され得るものである。例えば問題点を解決するための手段に記載される全構成要件から幾つかの構成要件が省略されうることで発明が抽出された場合には、その抽出された発明を実施する場合には省略部分が周知慣用技術で適宜補われるものである。
【００９５】
【発明の効果】
以上説明したように本発明によれば、ユーザからコンテンツの視聴要求に対し、ネットワークの資源の使用状況をチェックし、ＱＯＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを適切に配信できるＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法を提供できる。
【図面の簡単な説明】
【図１】本発明に係わるＩＰストリーミングシステムの一実施の形態を示す系統構成図。
【図２】図１に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明するフローチャート。
【図３】図１に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明する図２に続くフローチャート。
【図４】図１に示すリソース管理データベースのデータ構成の一例を示す図。
【図５】図１に示す周波数管理データベースのデータ構成の一例を示す図。
【図６】本発明に係わるＩＰストリーミングシステムの他の実施形態を示す系統構成図。
【図７】図６に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明するフローチャート。
【図８】図６に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明する図７に続くフローチャート。
【符号の説明】
１０…ヘッドエンドシステム
１１…ナビゲーションサーバ
１２…配信サーバ
１３…ポリシーサーバ
１６…リソース管理データベース
１７…周波数管理データベース
２０…ネットワーク
３０…ディストリビューションＨＵＢ
３１…ＣＭＴＳ（ネットワーク中継装置）
３２…リソース管理データベース
３３…周波数管理データベース
４０…ＲＦケーブル
５１…ＩＰＢ
５２…ユーザ端末
【発明の属する技術分野】
本発明は、ケーブルインターネット上でＩＰストリーミングを利用して通信サービスを行うＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法に関する。
【０００２】
【従来の技術】
近年、ＣＡＴＶにおける双方向通信のインフラ整備に伴い、ケーブルインターネットを用いて、映像や音楽などのデータ通信サービスを提供することが行われている。
【０００３】
このようなデータ通信サービスは、インターネットの特性上、ユーザの利用状況に応じて回線条件が変動するベストエフォート型のサービスとなっている。
【０００４】
そこで、データ通信サービスの提供業者では、例えば下り方向のデータ伝送速度がユーザ当たり最大１．５Ｍｂｐｓのサービスを提供しようとする場合、各ユーザ毎にケーブルルータと称するＣＭＴＳ（Ｃａｂｌｅ Ｍｏｄｅｍ Ｔｅｒｍｉｎａｔｉｏｎ Ｓｙｓｔｅｍ；ケーブルモデム終端装置）を用いて、下り方向の単位時間当たりのトラフィックを測定し、ある時間の平均値が１．５Ｍｂｐｓを越えた場合、下り方向のトラフィックを一時停止するなどの方法をとり、データ通信サービスを提供している。
【０００５】
【発明が解決しようとする課題】
しかしながら、以上のようなデータ通信サービスでは、インターネット上で映像等マルチメディアコンテンツを送信し、リアルタイムに再生可能なＩＰストリーミングを利用した放送システムであっても、当該マルチメディアコンテンツを確実に配信することが難しい。
【０００６】
この発明においてＩＰストリーミングとは、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌを利用して映像や音声等のコンテンツをＩＰパケットとして配信し、ユーザ側にてコンテンツを再生する技術全般を指し、ユーザ側でＩＰパケットをメモリに受信して再生する狭義のＩＰストリーミングと、ユーザ側で一部か全てのコンテンツを一旦ＨＤＤ等に蓄積した後に再生を開始する疑似ＩＰストリーミングの双方の方法を含む。
【０００７】
本発明は上記事情に鑑みてなされたもので、ユーザからのコンテンツの視聴要求に対し、ネットワークの資源の使用状況をチェックし、ＱｏＳ（Quality of Service：サービス品質）を確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信するＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法を提供することを目的とする。
【０００８】
【課題を解決するための手段】
（１） 上記課題を解決するために、各ユーザ端末からＣＭＴＳ及びネットワークを介して送信されてくるコンテンツ視聴要求に基づき、配信サーバが視聴要求のあったコンテンツをユーザ端末に配信するＩＰストリーミングシステムにおいて、
前記視聴要求のあったコンテンツを配信するに先立ち、当該コンテンツを配信するためのＱｏＳが確保可能か否かの問い合わせを送出する前記配信サーバと、
前記各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、前記システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、前記ユーザ端末からのコンテンツ視聴要求のもとに、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を前記配信サーバに通知するとともに、ＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を前記配信サーバに通知する手段とを設けたポリシーサーバとを備えたＩＰストリーミングシステムの構成である。
【０００９】
本発明は以上のような構成とすることにより、ナビゲーションサーバがユーザ端末から要求元情報のもとに視聴要求コンテンツを受けると、配信サーバに通知する。この配信サーバは、要求元情報及び視聴要求コンテンツに基づき、配信情報データベースからコンテンツの必要帯域情報を読み出し、要求元情報とともに、ポリシーサーバに配信すべきコンテンツのＱｏＳが確保可能か否かについて問い合わせをする。ここで、ポリシーサーバは、コンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況およびユーザ端末が接続される前記ケーブルの周波数帯域の使用状況を判断するので、ＱｏＳ実現のためにリソースの使用状態および周波数帯域の状態を判断し、両方が適切な状態にあれば、ＱｏＳ確保可能と判断し、配信サーバに視聴要求のあったコンテンツの配信が可能であることを通知するので、ＱＯＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信することができる。
【００１０】
なお、ＱｏＳ実現のためにリソースの使用状態および周波数帯域の状態を判断処理機能を各ＣＭＴＳにもたせることも可能である。
【００１１】
（２） また、本発明に係るポリシーサーバは、各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、ユーザ端末からのコンテンツ視聴要求のもとに、外部から要求元情報、必要帯域情報を受けると、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記外部から要求元情報、必要帯域情報を受けると、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を判断し、またＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を算出する手段とを備えた構成である。
【００１２】
この発明は以上のような構成とすることにより、ポリシーサーバが配信サーバなどの外部から要求元情報、必要帯域情報を受けると、リソース管理記憶手段を参照し、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断し、また周波数管理記憶手段を参照し、視聴要求のあったユーザ端末に接続されるラインにおける周波数帯域の空き有無を判断するので、配信サーバにＱｏＳを確保可能であることを知らせることができる。
【００１４】
さらに、ポリシーサーバにリソース管理記憶手段および周波数管理記憶手段を設け、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無およびユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断したが、例えばネットワーク中継装置である例えばＣＭＴＳにリソース管理記憶手段および周波数管理記憶手段を設け、視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無およびユーザ端末に接続されるラインにおける周波数帯域の空き有無を判断する場合でも、前述するポリシーサーバと同様の作用効果を奏することが可能である。
【００１５】
（３） 本発明に係るＩＰストリーミング配信方法は、コンテンツの視聴要求を行う複数のユーザ端末が接続されるケーブルを収容する複数のＣＭＴＳと当該視聴要求コンテンツのストリーミング配信を実行するヘッドエンドシステムとがネットワークデ接続されているＩＰストリーミングシステムにおいて、あるユーザ端末から要求元情報のもとにメニュー画面要求を受けた場合、当該ユーザ端末にメニュー画面を送信し、当該ユーザ端末から視聴要求コンテンツを受け付けるコンテンツ要求受付けステップと、このステップにより視聴要求コンテンツを受付けると、予め記憶される配信要求コンテンツ、当該コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、前記ヘッドエンドシステムが収容するポリシーサーバにＱｏＳ確保可能かを問い合わせる問合せステップと、このステップにより問い合わせを受けた場合、ポリシーサーバがリソース管理記憶手段に記憶される前記要求元ユーザ端末までのネットワーク経路に存在するリソース情報及びリソース使用に関係する時間情報を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断するリソース確保判断ステップと、問い合わせステップにより問い合せを受けると、システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段を参照し、前記ユーザ端末が接続されたケーブルにおける周波数帯域の空き有無を判断する帯域確保判断ステップと、前記各判断ステップによりＱｏＳ確保可能と判断されたとき、前記ヘッドエンドシステムが前記視聴要求コンテンツを前記要求元ユーザ端末に配信するステップと、前記各判断ステップによりＱｏＳ確保が否と判断されたとき、前記リソース使用及び帯域使用に関係する時間情報から配信可能時間を取得するステップとを有する方法である。
【００１６】
このようなストリーミング配信方法であっても、コンテンツ要求受付けステップで視聴要求を受付けると、問合せステップにて予め記憶されるコンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、ポリシーサーバにＱｏＳ確保可能かを問い合わせるので、ポリシーサーバがリソース管理記憶手段に記憶される前記要求元ユーザ端末までのネットワーク経路に存在するリソース情報を参照しコンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況およびユーザ端末が接続される前記ケーブルの周波数帯域の使用状況を判断するので、ＱｏＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを配信することが可能となる。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態を説明するに先立ち、例えば米国の放送システムについて説明する。
【００１８】
（１） 米国の放送システムの現状について。
【００１９】
アナログ地上波をケーブル上にブロードキャストする米国の放送システムでは、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）で利用可能な周波数帯のうち、５０ＭＨｚ〜４５０ＭＨｚの周波数範囲で利用されているが、この場合には１チャンネル当たり６ＭＨｚ程度の帯域が割当てられている。
【００２０】
一方、ケーブルインターネットを用いて、データ通信を行う場合、４５０ＭＨｚ以外の帯域、例えば５００ＭＨｚ〜６００ＭＨｚの周波数帯域が利用されている。すなわち、データ通信を行う場合、６ＭＨｚ帯域でディジタル変調であるＱＡＭ（Ｑｕａｄｒａｔｕｒｅ Ａｍｐｌｉｔｕｄｅ Ｍｏｄｕｌａｔｉｏｎ：直交振幅変調）変調が利用され、またＣＭＴＳやＩＰＢ（ＩＰストリーミング用セットトップボックス）のごときＩＰストリーミング対応装置の内部に実装されているチューナは前述する６ＭＨｚ帯毎にチューニングされている。このＱＡＭ方式は、正弦搬送波のパラメータである振幅、位相、周波数のうち、振幅と位相の２つのパラメータを同時に変調することにより、狭い帯域幅の中で多くのデータを搬送できる方式である。因みに、ケーブルインタネットで主に使用されるＱＡＭ変調には６４ＱＡＭ方式と２５６ＱＡＭ方式とがあるが、例えば６４ＱＡＭ方式の場合には約２７Ｍｂｐｓの伝送レートが得られる。現在、多数のユーザが２７Ｍｂｐｓの伝送帯域を共有する形でデータ通信サービスが行われている。
【００２１】
（２） 本発明に係るＩＰストリーミングシステムの構成について。
【００２２】
図１は本発明に係るＩＰストリーミングシステムの一実施の形態を示す構成図である。
【００２３】
このＩＰストリーミングシステムは、多種類のマルチメディアコンテンツを蓄積し、ユーザからの視聴要求に応じた配信処理を実行するヘッドエンドシステム１０と、例えばリング状の接続構成をとるネットワーク２０と、複数のディストリビューションＨＵＢ３０とが設けられ、これら各ディストリビューションＨＵＢ３０に収容されるＲＦケーブル４０にＩＰＢ５１を介してユーザ端末５２が接続されている。本発明では、ユーザ端末と呼ぶ場合には、ＩＰＢ５１とユーザ端末５２との組み合わせが対象となる。
【００２４】
また、ディストリビューションＨＵＢ３０とユーザ端末５２がもつＩＰＢ５１との間は、ＲＦケーブル４０だけでは距離が制限されることから、光信号に変換し距離を延長するために、電気−光変換器、ＨＦＣ（Ｈｙｂｒｉｄ Ｆｉｂｅｒ／Ｃｏａｘ）ネットワーク、光−電気変換器などが用いられるが、ここでは本発明の要旨と関連性が薄いことから省略する。
【００２５】
このヘッドエンドシステム１０は、ナビゲーションサーバ１１、配信サーバ１２、ポリシーサーバ１３およびＱｏＳを提供可能なルータ１４が設けられている。
【００２６】
なお、ＣＭＴＳ３１が１つで構成される場合には、ＣＭＴＳ３１を含めてヘッドエンドシステムと呼ぶ場合もある。
【００２７】
このナビゲーションサーバ１１は、当該サーバ１１自体が所有するメニューを容易に閲覧可能なＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ：電子プログラム・ガイド）およびナビゲーションクライアントソフトウエア等の間で連携をとりながら、ユーザが視聴を希望するコンテンツの種類を受理し、配信サーバ１２に通知する役割をもっている。
【００２８】
配信サーバ１２は、多種類のマルチメディアコンテンツの他、各コンテンツの配信に必要な帯域情報、配信必要時間情報その他配信に必要な情報を蓄積する大容量の配信情報データベース１５を有し、当該データベース１５に蓄積されるマルチメディアコンテンツを含む配信情報を管理する一方、ナビゲーションサーバ１１から配信通知を受けると、ポリシーサーバ１３に対し、コンテンツを配信するためのＱｏＳが確保可能か否かの問い合せを実施し、ＱＯＳが確保可能な場合、ユーザに対して希望するコンテンツを配信する機能をもっている。
【００２９】
ポリシーサーバ１３は、リソース管理データベース１６及び周波数管理データベース１７を有し、配信サーバ１２からＩＰアドレスなどの要求元情報、必要帯域情報をもとにＱｏＳ確保に関する問い合せを受けると、要求元ユーザに対してコンテンツを配信するために、ＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ実現のためのリソースを管理するリソース管理データベース１６及びシステム全体の周波数帯域を管理する周波数管理データベース１７の格納データからＣＭＴＳ３１を含むネットワーク中継関連装置の利用状況および要求元ユーザ端末が接続されるＲＦケーブルごとの周波数帯域の使用状況を判断し、ネットワーク経路のＱｏＳ確保および配信要求元ユーザの接続されるＲＦケーブルの帯域確保を行う機能をもっている。なお、リソース管理データベース１６及び周波数管理データベース１７はそれぞれ個別に独立したデータベースである必要がなく、同一のデータベースにエリア分けして必要な情報を記憶する構成であってもよい。
【００３０】
ルータ１４は、ＩＰパケットのヘッダをチェックし、前述するようにＱｏＳが確保可能な状態で中継するものであって、キューメカニズムやスケジュール管理メカニズムを有し、同一宛先トラフィックに対しても各ＩＰパケットに定義されるフローごとに管理する。また、ルータ１４は、配信サーバ１２から送信されるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に基づき、ルーター間の特定の通信チャンネルの伝送帯域を管理し、必要なＱｏＳを実現のためのリソースを確保する機能をもっている。
【００３１】
前記ネットワーク２０は、ストリーミング配信を実行するために必要な各種サーバ１１〜１３群を収容するヘッドエンドシステム１０と遠隔地に設置されるＣＭＴＳ３１を収容する多数のディストリビューションＨＵＢ３０とを接続する例えば光ファイバがリング状に形成された伝送ラインとなっている。
【００３２】
各ディストリビューションＨＵＢ３０は、多数のユーザの配信拠点となる部分であり、ＲＦケーブル４０を収容するリピータ機能或いはスイッチング機能をもったＬＡＮの集線装置としての役割を果たすものであって、少なくともＣＭＴＳ３１が収容されている。このＣＭＴＳ３１は一種のネットワーク中継装置である。
【００３３】
このＣＭＴＳ３１は、基本的にはＲＦインタフェースを有し、ルータ１４と同様の機能を有するケーブルルータである。つまり、ルータ１４と同様にキューメカニズムやスケジュール管理メカニズムが設けられている。
【００３４】
前記ＩＰＢ（ＩＰストリーミング用セットトップボックス）５１は、視聴要求コンテンツに対応するＩＰパケットを受信し、当該パケットに含まれるアプリケーションなど、上位の映像、音声に係るデータをＣＯＤＥＣ（コード・デコード）に従ってデコード処理を実施し、テレビジョンＴＶ、ＣＲＴや液晶のモニタを含むユーザ端末５２に表示する機能をもっている。
【００３５】
従って、以上のようなＩＰストリーミングシステムの実施の形態によれば、ポリシーサーバ１３にＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ実現のためのリソースを管理するリソース管理データベース１６及びシステム全体の周波数帯域を管理する周波数管理データベース１７を設け、ＩＰＢ５１を含むユーザ端末５２からコンテンツ視聴要求をナビゲーションサーバ１１で受けると、配信サーバ１２に通知し、配信情報データベース１５から視聴要求コンテンツに関する必要帯域情報、配信に必要な時間情報を要求元情報とともに、ＱｏＳ確保可能か否かをポリシーサーバ１３に問い合わせる。このポリシーサーバ１３は、リソース管理データベース１６を参照し、ＣＭＴＳ３１を含むネットワーク中継関連装置の利用状況を判断し、また周波数管理データベース１７を参照し、要求元ユーザ端末が接続されるＲＦケーブルごとの周波数帯域の使用状況を判断するので、ネットワーク経路のＱｏＳ確保および配信要求元ユーザの接続されるＲＦケーブルの帯域確保を行うことができ、ネットワーク資源を利用し、ＱｏＳを確保しながら視聴要求コンテンツをユーザ端末に配信することができる。
【００３６】
（３） リソース管理データベース１６及び周波数管理データベース１７の構成データ例について。
【００３７】
＊ リソース管理データベース１６について。
【００３８】
一般に、ＱｏＳを実現するためのネットワーク中継関連装置のリソースには制限があるので、ＱｏＳ保証可能な帯域にもおのずと限界がある。図１に示すヘッドエンドシステム１０に収容されるルータ１４、各ディストリビューションＨＵＢ３０に収容される例えばＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１が確保可能な帯域は、自身のＣＰＵやソフトウエアの処理能力により制限され、ＲＦインタフェース毎に１６Ｍｂｐｓの転送能力しかもっていない。さらに、ＱｏＳ管理単位であるフローの数がメモリの実装上の制約からキューの数が「３２」であるが、ＲＦインタフェース当たり３２本の異なるフローが処理可能である場合、例えばコンテンツの配信に必要な最低帯域が５００ｋｂｐｓとすれば、ＲＦインタフェース毎の転送能力である１６Ｍｂｐｓに対し、各ネットワーク中継関連装置のリソースは５００ｋｂｐｓにて３２本が限界である（図４の帯域番号参照）。
【００３９】
因みに、リソース管理データベース１６の構成データの一例としては、ユーザ名、ユーザ（ＩＰＢ）のＩＰアドレス、配信サーバ１２からの経路情報（例えばネットワーク中継装置名）、ネットワーク中継装置名、インタフェース名、帯域番号、使用帯域、使用開始時間、予想使用時間（或いは予想終了時間）、遅延時間等が挙げられる。
【００４０】
＊ 周波数管理データベース１７について。
【００４１】
ＣＭＴＳ３１のＲＦインタフェースは、チューナ１回路に付き１基本周波数（６ＭＨｚ）が使用可能である。前述したように６４ＱＡＭ方式の変調を使用した場合、伝送速度が２７Ｍｂｐｓとなる。このうち、各種プロトコルのオーバヘッドを考慮し、下り方向の実行速度を２０Ｍｂｐｓと見積もった場合、サービスを受けるユーザは当該速度範囲でなければならない。
【００４２】
因みに、周波数管理データベース１７の構成データの一例としては、ユーザ名、ユーザ（ＩＰＢ）のＩＰアドレス、ネットワーク中継装置名、インタフェース名、使用可能帯域、使用帯域数、使用開始時間、予想使用時間（或いは予想終了時間）、使用コンテンツアドレス（ＵＲＬ）等が挙げられる。
【００４３】
（４） 図１に示すシステムの動作ないし本発明に係るＩＰストリーミング配信方法について（図２、図３参照）。
【００４４】
先ず、ポリシーサーバ１３は、ＣＭＴＳ３１を含むネットワーク中継関連装置のＱＯＳを実現する為、当該装置における使用帯域等の情報をリソース管理データベース１６に格納し、またＲＦケーブル４０の周波数帯域等の情報を周波数管理データベース１７に格納するなどし、適切な管理を行うための初期化を実施する（Ｓ１：ポリシーサーバ初期化ステップ）。
【００４５】
この状態においてユーザがＩＰＢ５１を起動し、ＥＰＧのメニュー画面の要求操作を行うと、自身のＩＰアドレス等の要求元情報のもとにメニュー画面要求情報がＣＭＴＳ３１、ネットワーク２０を経由し、ナビゲーションサーバ１１に送られる（Ｓ２）。ここで、ナビゲーションサーバ１１は、画面要求に基づいて自身が所有するＥＰＧのメニュー画面を特定のユーザの要求元情報を所有するＩＰＢ５１に配信する（Ｓ３）。このメニュー画面はユーザ端末５２に表示される。ユーザはメニュー画面からジャンル毎（アクション、ドラマ）のボタンやシステムプロバイダーが推奨するコンテンツ等を見ることができる。
【００４６】
ここで、ユーザがユーザ端末５２に表示されるメニュー画面から特定の映像等マルチメディアコンテンツを指定すると、該当ＩＰＢ５１から自身の例えばＩＰアドレス等の要求元情報のもとに映像コンテンツ視聴要求が送信される。ヘッドエンドシステム１０のナビゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３１、ネットワーク２０を介して送られてくる要求元情報、映像コンテンツ視聴要求を受信し、コンテンツ視聴要求を受付ける（Ｓ４）。これらＳ２〜Ｓ４はコンテンツ要求受付けステップに相当する。
【００４７】
このナビゲーションサーバ１１は、ユーザによって指定された映像等のコンテンツの視聴要求を受信した後、配信サーバ１２に通知する（Ｓ５）。
【００４８】
この配信サーバ１２は、自身が管理する配信情報データベース１５から配信要求コンテンツ、当該コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、要求元（送信先）情報とともに、ポリシーサーバ１３に送信し、ＱｏＳ確保の観点から配信可能か否かを問い合わせる（Ｓ６）。これらステップＳ５，Ｓ６は問い合わせステップを意味する。
【００４９】
ここで、ポリシーサーバ（帯域ブローカ）１３は、要求元情報に基づいてリソース管理データベース１６から要求コンテンツを配信するためのネットワークの経路情報を取得し（Ｓ７）、さらに要求元情報および必要帯域情報（例えば５００ｋｂｐｓ等）をもとに要求元までのネットワーク経路に存在するＣＭＴＳ３１、ヘッドエンドシステム１０内のルータ１４を含む全てのネットワーク中継関連装置に関し、リソース管理データベース１６に格納される情報を参照し、５００ｋｂｐｓの帯域をもつＱｏＳ実現可能なリソースが有るか否かを判断する（Ｓ８）。リソース無しと判断されたとき、ポリシーサーバ１３は、配信サーバ１２に配信不可能と回答する。このとき、予想使用時間情報をもとに配信可能時間も回答する（Ｓ９）。そして、新たな外部から入力待ちの状態となる。
【００５０】
ポリシーサーバ１３は、ステップＳ８においてＱｏＳ実現のためのリソース有りと判断した場合、図４に示すようにリソース管理データベース１６に規定される項目のうち、例えば帯域番号特定、当該帯域番号対応使用帯域への「１」設定、使用開始時間の書込み等のなどの帯域使用情報を更新する（Ｓ１０）。これらステップＳ５〜Ｓ１０はリソース確保判断ステップに相当する。
【００５１】
さらに、ポリシーサーバ（帯域ブローカ）１３は、要求元情報および必要帯域情報をもとに、図５に示す周波数管理データベース１７を参照し、要求元ＩＰＢ５１が現在接続されているＲＦケーブル４０に対応するインタフェースに５００ｋｂｐｓ帯域の空きがあるか否かを判断する（Ｓ１１）。ここで、帯域に空きがない場合には配信不可能である旨を配信サーバ１２に回答するが、同時に予想使用時間情報をもとに配信可能時間も回答する。また、前述したステップＳ１０により確保したリソースを開放するために、リソース管理データベース１６をアップデータする（Ｓ１２）。
【００５２】
一方、ポリシーサーバ１３は、ステップＳ１１においてＲＦケーブル４０に対応するインタフェースに帯域に空きがあると判断された場合、要求元ユーザのコンテンツ配信要求がサービスの上限値を越えているか否かを判断し（Ｓ１３）、越えていないと判断された場合には配信サーバ１２に対して配信可能であることを回答するとともに、その帯域の利用分について周波数管理データベース１７を更新する（Ｓ１４）。これらステップＳ１１〜Ｓ１４は帯域確保判断ステップに相当する。
【００５３】
ここで、配信サーバ１２は、ポリシーサーバ１３から配信可能とする回答を受けると、ＲＳＶＰ等のプロトコルを用いて、ＣＭＴＳ３１を含むネットワーク中継関連装置の実際の使用帯域をチェックし、使用するリソースを確保する（Ｓ１５）。
【００５４】
このＲＳＶＰプロトコルとしては、通常、配信サーバ１２からｐａｔｈメッセージを送信し、当該ｐａｔｈメッセージの条件（帯域や遅延時間等）が正当であるか否かについてルータ１４、ＣＭＴＳ３１の順序で順次チェックしながら、コンテンツ配信要求元であるＩＰＢ５１まで到達する。このＩＰＢ５１は、エラーなしでｐａｔｈメッセージを受信すると、ｒｅｓｖメッセージを配信サーバ１２に向けて送信する。ＣＭＴＳ３１、ルータ１４は、ＩＰＢ５１から送信されるｒｅｓｖメッセージに基づいて実際のリソースを割当て予約する。
【００５５】
配信サーバ１２は、ｒｅｓｖメッセージを受けると、予約したネットワーク中継関連装置のリソースとＲＦケーブル４０の周波数帯を利用し、実際の映像等コンテンツを配信要求元のＩＰＢ５１に配信する（Ｓ１６）。ステップＳ１５，Ｓ１６はコンテンツ配信ステップを意味する。
【００５６】
配信サーバ１２は、コンテンツの送信を終了すると、ポリシーサーバ１３に対し、配信要求コンテンツに対する送信終了を通知する（Ｓ１７）。ポリシーサーバ１３は、送信終了情報を受け取ると、両管理データベース１６，１７の該当コンテンツ配信のために利用した帯域分の情報について開放する（Ｓ１８）。このステップＳ１７，Ｓ１８は帯域確保情報開放ステップを意味する。
【００５７】
従って、以上のようなＩＰストリーミング配信方法の実施の形態によれば、ユーザ端末側からの視聴要求コンテンツの受付けステップ、この受付けを行ったナビゲーションサーバ１１の配信サーバ１２への通知及び配信サーバによる配信コンテンツの必要帯域情報、配信するために必要な時間情報を取得し、ポリシーサーバ１３にＱｏＳ実現のための問合せを行う問合せステップ、さらにポリシーーバ１３によるリソース確保判断、使用帯域確保判断を行うステップ、何れも確保可能な場合に配信サーバ１２に通知するステップを採用することにより、リソース及び使用帯域を確保し、ＱｏＳを確保しつつ視聴要求コンテンツを確実に配信できる。
【００５８】
（５） ポリシーサーバ１３の実際の動作処理例について（図２〜図５参照）。
【００５９】
なお、サービスの前提としては、以下の＊に記述するような内容を設定する。
【００６０】
＊ コンテンツは、映像品質や音声品質等に応じて、５００ｋｂｐｓの整数倍の伝送レートが必要となるので、５００ｋｂｐｓ〜２Ｍｂｐｓまでの種類があるとする。例えば高品質映像コンテンツの場合は１Ｍｂｐｓ、中程度の品質の場合は５００ｋｂｐｓが必要となるという具合である。
【００６１】
＊ ポリシーサーバ１３にて、１サービス（例えば映画１本の視聴）毎にサービス使用の可否がリソース等の状況に応じて判断されるものとする。
【００６２】
＊ ＣＭＴＳ３１の１インタフェース毎（６ＭＨｚ帯当たり）の伝送速度は、６４ＱＡＭ変調方式の場合には２７Ｍｂｐｓであるが、各種プロトコルのオーバヘッドがあるので、有効速度は２０Ｍｂｐｓとする。
【００６３】
＊ ルータ１４、ＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１の確保可能な帯域は、インタフェース毎に１６Ｍｂｐｓであり、かつ、管理可能なフローの数は５００ｋｂｐｓで３２本とする。
【００６４】
＊ 通常、１つのＩＰＢ５１当たり最大２Ｍｂｐｓのベストエフォート型通信を保証するが、コンテンツ配信要求時は５００ｋｂｐｓの整数倍である最大例えば２Ｍｂｐｓまでの範囲でＱＯＳ管理に基づいた視聴が可能とする。
【００６５】
＊ ＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１の１インタフェース当たりに対し、ＩＰＢ５１の接続台数は５０台とする。すなわち、５０台中の２０％の使用率以上になると、各ユーザの使用可能な速度は２Ｍｂｐｓ以下となる（２０Ｍｂｐｓ÷（５０台の２０％）＝２Ｍｂｐｓ）。
【００６６】
以上のような設定条件のもとに実際のポリシーサーバ１３の詳細な動作について説明する。
【００６７】
▲１▼ 配信サーバ１２は、ナビゲーションサーバ１１からＩＰアドレス等の要求元情報のもとに映像コンテンツの配信要求を受けると、配信情報データベース１５に格納されるコンテンツ配信に必要な帯域情報（例えば５００ｋｂｐｓ）および配信必要時間情報（例えば２時間）を読み出し、要求元情報とともに、ポリシーサーバ１３に対して配信可能か否かの問い合わせを行う（図２のＳ６）。
【００６８】
▲２▼ ポリシーサーバ１３は、配信要求元ユーザが接続されているＣＭＴＳ（１）３１とインタフェースとを確認する為、要求元情報であるＩＰアドレスをキーとし、リソース管理データベース１６を用いて、配信サーバ１２からユーザＩＰＢ５１までのネットワーク経路情報、中継装置名（複数存在する場合には複数）、インタフェース名を検索する（図２のＳ７）。例えばユーザＡを指定し、ルータ１４／インタフェース１とＣＭＴＳ（１）３１／インタフェース１（図４参照）を取得する。
【００６９】
▲３▼ 次に、ポリシーサーバ１３は、ナビゲーションサーバ１１から受け取った要求元情報（通常，ＩＰアドレス）と必要帯域情報とをもとに、リソース管理データベース１６を参照し、要求元ＩＰＢ５１までのネットワーク中経路に存在するルータ１４とＣＭＴＳ（１）５１に帯域確保が可能か否かを判断する（図２のＳ８）。具体的には、図４に示すごとく、ＣＭＴＳ（１）／インタフェース１においては、ＣＭＴＳ（１）のＱｏＳ実現の為の全リソース３２本（５００ｋｂｐｓ）のうち、現在、帯域番号「１」，「２」，「３」しか使用されておらず、未だ十分に設定可能な状態にあることが分るので、今回の配信要求に対して帯域番号「４」を特定し、対応する使用帯域項目に「１」を設定し、使用開始時間を記入する。リソース管理データベース１６には図示されていないが、同様にルータ１４／インタフェース１についても実行する。
【００７０】
▲４▼ さらに、ポリシーサーバ１３は、要求元情報と必要帯域情報をもとに、周波数管理データベース１７を参照し、ＣＭＴＳ（１）／インタフェース１（要求元ＩＰＢが現在接続されているＲＦケーブル４０）に５００ｋｂｐｓ帯域の空きがあるか否かを判断する（図３のＳ１１）。具体的には、ＣＭＴＳ（１）／インタフェース１を指定し、ＲＦインタフェース当たりの周波数割り当てからくる制限（例えば合計２０Ｍｂｐｓ）と現在使用中の使用帯域との比較を行う。ここで、図５に示すごとく、ＣＭＴＳ（１）／インタフェース１のＲＦインタフェースの使用周波数帯域の合計は３であり、１．５Ｍｂｐｓの帯域より使用しておらず、２０Ｍｂｐｓ以下であるので、未だ周波数帯域の使用には問題がない。
【００７１】
▲５▼ 今回の配信要求元ユーザのＩＰアドレス（例えば１０．１．１．３）の使用帯域数は０となっており、各ユーザ毎に上限値２Ｍｂｐｓ以下となっているので、何ら問題なく空き帯域を使用できる（図３のＳ１３）。
【００７２】
▲６▼ ポリシーサーバ１３は、以上述べた２つのデータベース１６，１７の参照結果に基づき、配信サーバ１２に対し、今回ユーザＩＰＢ５１の配信要求に対する配信は可能であると回答する（図３のＳ１４）。
【００７３】
従って、以上のようなポリシーサーバ１３の実施の形態によれば、リソース管理データベース１６および周波数管理データベース１７の格納データを参照し、リソース確保および使用帯域確保を適切に判断でき、配信サーバ１２にコンテンツの配信に必要な適切な回答を提供できる。
【００７４】
（６） ＣＭＴＳ３１にリソース管理データベース３２及び周波数管理データベース１７を備えた場合の構成および動作処理例について。
【００７５】
前述するシステム例は、ポリシーサーバ１３によってリソース管理を一元管理する場合の構成例を述べたが、この例では、図６に示すように各ＣＭＴＳ３１にデータベース３２，３３を備えた構成となる。つまり、各ＣＭＴＳ３１から下流のリソース及び周波数帯域の管理については、個々のＣＭＴＳ３１が管理するデータベース３２，３３に必要な情報を格納し管理する例である。なお、これらデータベース３２，３３には前述するリソース管理データベース１６及び周波数管理データベース１７と同様な構成データを格納するものであり、とりわけ本発明の説明上必要な図４，図５と同様なデータを格納するものとする。
【００７６】
次に、データベース３２，３３を備えたＣＭＴＳ３１を含むシステムの動作について図７及び図８を参照して説明する。
【００７７】
先ず、ＣＭＴＳ３１は、動作を開始すると、ＱｏＳを実現する為、使用帯域等の情報やＲＦケーブル４０の周波数帯域等の情報を管理するための初期化を実行する（Ｓ２１：初期化ステップ）。
【００７８】
この状態においてユーザがＩＰＢ５１を起動し、ＥＰＧメニューの要求操作を行うと、自身のＩＰアドレス等の要求元情報のもとに画面要求情報がＣＭＴＳ３１、ネットワーク２０を経由し、ナビゲーションサーバ１１に送られる（Ｓ２２）。ここで、ナビゲーションサーバ１１は、ある特定のユーザの要求元情報を所有するＩＰＢ５１に配信する（Ｓ２３）。このＥＰＧメニュー画面はユーザ端末５２に表示される。ユーザはメニュー画面からジャンル毎（アクション、ドラマ）のボタンやシステムプロバイダーが推奨するコンテンツ等を見ることができる。
【００７９】
ここで、ユーザがユーザ端末５２に表示されるメニュー画面から特定の映像等マルチメディアコンテンツを指定すると、該当ＩＰＢ５１から自身の例えばＩＰアドレス等の要求元情報のもとに映像コンテンツ視聴要求が送信される。ヘッドエンドシステム１０のナビゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３１、ネットワーク２０を介して送られてくる要求元情報、映像コンテンツ視聴要求を受信し、視聴要求のあったコンテンツを受付ける（Ｓ２４）。これらＳ２２〜Ｓ２４はコンテンツ要求受付けステップに相当する。
【００８０】
このナビゲーションサーバ１１は、ユーザによって指定された映像等のコンテンツの視聴要求を受信した後、配信サーバ１２に通知する（Ｓ２５）。
【００８１】
この配信サーバ１２は、自身が管理する配信情報データベース１５から要求元情報をもとに、経路情報、コンテンツの配信に必要な帯域情報、配信必要時間情報等を読み出し、要求元（送信先）情報とともに、ポリシーサーバ１３に送信する（Ｓ２６）。
【００８２】
このポリシーサーバ１３は、要求元情報、経路情報、当該コンテンツの配信に必要な帯域情報、配信必要時間情報を受け取ると、これら要求元情報および必要帯域情報（例えば５００ｋｂｐｓ等）、配信必要時間情報等を要求元側ネットワーク経路に存在するＣＭＴＳ３１を通知しサービスを要求する（Ｓ２７）。
【００８３】
ここで、ＣＭＴＳ３１は、要求元情報をもとにインタフェース名を取得し（Ｓ２８）、このインタフェース名に基づいてリソースデータベース３２に格納される情報を参照し、該当インタフェース名にＱｏＳの観点から５００ｋｂｐｓの帯域確保が可能なリソースが存在するか否かを判断する（Ｓ２９）。帯域確保可能なリソースが存在しない場合、ＣＭＴＳ３１は、ポリシーサーバ１３に配信不可能と回答する。このとき、予想使用時間情報をもとに配信可能時間も回答する（Ｓ３０）。
【００８４】
ＣＭＴＳ３１は、ステップＳ２９においてＱｏＳ確保可能にリソースが存在すると判断した場合、図４に示すようにリソース管理データベース３２に規定される項目のうち、例えば帯域番号特定、当該帯域番号対応使用帯域への「１」設定、使用開始時間の書込み等のなどの帯域使用情報を更新する（Ｓ３１）。これらステップＳ２８〜Ｓ３１はリソース確保判断ステップに相当する。
【００８５】
さらに、ＣＭＴＳ３１は、要求元情報および必要帯域情報をもとに、図４に示す周波数管理データベース３３を参照し、該当インタフェースに５００ｋｂｐｓ帯域の空きがあるか否かを判断する（Ｓ３２）。ここで、帯域に空きがない場合にはリソース無しをポリシーサーバ１３に回答するが、同時に予想使用時間情報をもとに配信可能時間も回答する。また、前述したステップＳ３１により確保したリソースを開放するために、リソース管理データベース３２をアップデートする（Ｓ３３）。
【００８６】
一方、ＣＭＴＳ３１は、ステップＳ３２で該当インタフェースに空き帯域周波数があると判断された場合、要求元ユーザのコンテンツ配信要求がサービスの上限値を越えているか否かを判断し（Ｓ３４）、越えていないと判断された場合にはポリシーサーバ１３に配信可能であることを回答するとともに、その帯域の利用分について周波数管理データベース３３を更新する（Ｓ３５）。これらステップＳ３２〜Ｓ３５は帯域確保判断ステップに相当する。
【００８７】
ここで、ポリシーサーバ１３は、配信サーバ１２に配信可能を回答する（Ｓ３６）。この配信サーバ１２は、ポリシーサーバ１３から配信可能とする回答を受けると、ＲＳＶＰ等のプロトコルを用いて、ＣＭＴＳ３１を含むネットワーク中継関連装置の実際の使用帯域をチェックし、使用するリソースを確保する（Ｓ３７）。
【００８８】
つまり、配信サーバ１２からｐａｔｈメッセージを送信し、ルータ１４、ＣＭＴＳ３１の順序で順次チェックしながら、コンテンツ配信要求元であるＩＰＢ５１まで到達する。このＩＰＢ５１は、エラーなしでｐａｔｈメッセージを受信すると、ｒｅｓｖメッセージを配信サーバ１２に向けて送信する。
【００８９】
配信サーバ１２は、ｒｅｓｖメッセージを受けると、予約したネットワーク中継関連装置のリソースとＲＦケーブル４０の周波数帯を利用し、実際の映像等コンテンツを配信要求元のＩＰＢ５１に送信する（Ｓ３８：コンテンツ配信ステップ）。配信サーバ１２は、コンテンツの配信を終了すると、ポリシーサーバ１３を介してＣＭＴＳ３１に送信終了情報を送信する（Ｓ３９）。このＣＭＴＳ３１は、両管理データベース３２，３３の該当コンテンツ配信のために利用した帯域分の情報について開放する（Ｓ４０）。
【００９０】
従って、以上のようなネットワーク中継装置であるＣＭＴＳ３１の一実施の形態によれば、当該ＣＭＴＳ３１にポリシーサーバ１３と同様な情報を有するリソース管理データベース３２および周波数管理データベース３３を備えることにより、ＣＭＴＳ３１がこれらデータベース３２，３３の内容を参照し、ポリシーサーバ１３と同様な機能ないし作用効果を奏することができる。
【００９１】
なお、上記実施の形態は、ＱｏＳの実現のためにリソース管理データベース１６、周波数管理データベース１７を設けたが、何れか一方のデータベース１６または１７を設け、リソースまたは周波数の観点からＱｏＳを実現するようにしてもよい。
【００９２】
また、実施の形態では、ＣＭＴＳ３１側に両管理データベース３２，３３を設けたが、例えばＣＭＴＳ３１側に何れか一方の管理データベース３２または３３を設けてもよく、この場合には他方の管理データベース３３または３２はポリシーサーバ１３側に設置する。
【００９３】
さらに、ＣＭＴＳ３１側に両管理データベース３２，３３を設けた場合、システムからポリシーサーバ１３を削除する構成としてもよい。
【００９４】
その他、本願発明は、上記実施の形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変形して実施できる。また、各実施の形態は可能な限り組み合わせて実施することが可能であり、その場合には組み合わせによる効果が得られる。さらに、上記各実施の形態には種々の上位，下位段階の発明が含まれており、開示された複数の構成要素の適宜な組み合わせにより種々の発明が抽出され得るものである。例えば問題点を解決するための手段に記載される全構成要件から幾つかの構成要件が省略されうることで発明が抽出された場合には、その抽出された発明を実施する場合には省略部分が周知慣用技術で適宜補われるものである。
【００９５】
【発明の効果】
以上説明したように本発明によれば、ユーザからコンテンツの視聴要求に対し、ネットワークの資源の使用状況をチェックし、ＱＯＳを確保しつつネットワーク資源を有効に活用し、視聴要求コンテンツを適切に配信できるＩＰストリーミングシステム、ポリシーサーバ及びＩＰストリーミング配信方法を提供できる。
【図面の簡単な説明】
【図１】本発明に係わるＩＰストリーミングシステムの一実施の形態を示す系統構成図。
【図２】図１に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明するフローチャート。
【図３】図１に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明する図２に続くフローチャート。
【図４】図１に示すリソース管理データベースのデータ構成の一例を示す図。
【図５】図１に示す周波数管理データベースのデータ構成の一例を示す図。
【図６】本発明に係わるＩＰストリーミングシステムの他の実施形態を示す系統構成図。
【図７】図６に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明するフローチャート。
【図８】図６に示すシステムの動作及び本発明に係わるＩＰストリーミング配信方法の一実施の形態を説明する図７に続くフローチャート。
【符号の説明】
１０…ヘッドエンドシステム
１１…ナビゲーションサーバ
１２…配信サーバ
１３…ポリシーサーバ
１６…リソース管理データベース
１７…周波数管理データベース
２０…ネットワーク
３０…ディストリビューションＨＵＢ
３１…ＣＭＴＳ（ネットワーク中継装置）
３２…リソース管理データベース
３３…周波数管理データベース
４０…ＲＦケーブル
５１…ＩＰＢ
５２…ユーザ端末
Claims (5)
- 各ユーザ端末からＣＭＴＳ及びネットワークを介して送信されてくるコンテンツ視聴要求に基づき、配信サーバが視聴要求のあったコンテンツを要求元ユーザ端末に配信するＩＰストリーミングシステムにおいて、
前記視聴要求のあったコンテンツを配信するに先立ち、当該コンテンツを配信するためのＱｏＳが確保可能か否かの問い合わせを送出する前記配信サーバと、
前記各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、前記システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、前記ユーザ端末から要求元情報を含むコンテンツ視聴要求のもとに、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ＣＭＴＳを含むネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を前記配信サーバに通知するとともに、ＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を前記配信サーバに通知する手段とを設けたポリシーサーバと
を備えたことを特徴とするＩＰストリーミングシステム。 - 各ユーザ端末からＣＭＴＳ及びネットワークを介して送信されてくるコンテンツ視聴要求に基づき、配信サーバが視聴要求のあったコンテンツを要求元ユーザ端末に配信するＩＰストリーミングシステムにおいて、
前記視聴要求のあったコンテンツを配信するに先立ち、当該コンテンツを配信するためのＱｏＳが確保可能か否かの問い合わせを送出する前記配信サーバと、
前記各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、前記システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、前記ユーザ端末から要求元情報を含むコンテンツ視聴要求のもとに、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、前記配信サーバから前記要求元情報、必要帯域情報を含むＱｏＳ確保の問い合わせを受けた場合、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在するネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を前記配信サーバに通知するとともに、ＱｏＳ確保が否の場合には前記リソース使用及び前記帯域使用に関係する時間情報から配信可能時間を前記配信サーバに通知する手段とを設けた前記ＣＭＴＳと
を備えたことを特徴とするＩＰストリーミングシステム。 - 請求項1又は請求項２に記載のＩＰストリーミングシステムにおいて、
前記ケーブルの周波数帯域に空きがあり、かつリソースの使用状況から前記ＱｏＳ確保が可能であると判断された場合、前記ユーザ端末からのコンテンツ視聴要求が通信サービスの上限値を越えているか否かを判断し、越えていないと判断された場合、ＱｏＳを確保しつつ視聴要求のあったコンテンツが配信可能であることを前記配信サーバに通知することを特徴とするＩＰストリーミングシステム。 - 各ユーザ端末からのコンテンツ視聴要求に基づいて視聴要求のあったコンテンツを配信するＩＰストリーミングシステムにおいて、
前記各ユーザ端末までのネットワーク経路に存在するリソースの状況及びリソース使用に関係する時間情報を記憶するリソース管理記憶手段と、
前記システム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段と、
前記ユーザ端末からのコンテンツ視聴要求のもとに、外部から要求元情報、必要帯域情報を受けると、前記リソース管理記憶手段を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断する第１の判断手段と、
前記外部から要求元情報、必要帯域情報を受けると、前記周波数管理記憶手段を参照し、視聴要求のあった前記ユーザ端末が接続されるケーブルにおける周波数帯域の空き有無を判断する第２の判断手段と、これら第１及び第２の判断手段から得られる前記コンテンツを配信するネットワーク経路に存在する前記ネットワーク中継関連装置のリソースの利用状況および前記ユーザ端末が接続される前記ケーブルの周波数帯域の使用状況に基づいてＱｏＳ確保の可否を判断し、またＱｏＳ確保が否の場合には前記リソース使用及び帯域使用に関係する時間情報から配信可能時間を算出する手段とを備えたことを特徴とするポリシーサーバ。 - コンテンツの視聴要求を行う複数のユーザ端末とこの複数のユーザ端末がケーブルを介して接続されたＣＭＴＳを持ち、前記ユーザ端末からの前記視聴要求に基づいて前記視聴要求されたコンテンツを前記ユーザ端末にネットワークを介して配信するＩＰストリーミングシステムにおいて、
あるユーザ端末から要求元情報のもとにメニュー画面要求を受けた場合、当該ユーザ端末にメニュー画面を送信し、当該ユーザ端末から視聴要求コンテンツを受け付けるコンテンツ要求受付けステップと、
このステップにより視聴要求コンテンツを受付けると、予め記憶される配信要求コンテンツ、当該コンテンツの配信に必要な帯域情報、配信必要時間情報を読み出し、ＱｏＳ確保可能かを問い合わせる問合せステップと、
この問い合わせに基づいて予め記憶された前記要求元ユーザ端末までのネットワーク経路に存在するリソース情報及びリソース使用に関係する時間情報を参照し、前記視聴要求コンテンツに関するＱｏＳ確保のためのリソース有無を判断するリソース確保判断ステップと、
前記問合せに基づいてシステム全体の周波数帯域の使用状況及び帯域使用に関係する時間情報を記憶する周波数管理記憶手段を参照し、前記ユーザ端末が接続されたケーブルにおける周波数帯域の空き有無を判断する帯域確保判断ステップと、
前記各判断ステップによりＱｏＳ確保可能と判断されたとき、前記視聴要求コンテンツを前記要求元ユーザ端末に配信するステップと、
前記各判断ステップによりＱｏＳ確保が否と判断されたとき、前記リソース使用及び帯域使用に関係する時間情報から配信可能時間を取得するステップとを有することを特徴とするＩＰストリーミング配信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001367850A JP3590376B2 (ja) | 2001-11-30 | 2001-11-30 | Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001367850A JP3590376B2 (ja) | 2001-11-30 | 2001-11-30 | Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003169087A JP2003169087A (ja) | 2003-06-13 |
| JP3590376B2 true JP3590376B2 (ja) | 2004-11-17 |
Family
ID=19177537
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001367850A Expired - Fee Related JP3590376B2 (ja) | 2001-11-30 | 2001-11-30 | Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3590376B2 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1867068A (zh) | 1998-07-14 | 2006-11-22 | 联合视频制品公司 | 交互式电视节目导视系统及其方法 |
| ES2312475T3 (es) | 2000-10-11 | 2009-03-01 | United Video Properties, Inc. | Sistemas y metodos para proporcionar el almacenamiento de datos en servidores de un sistema de entrega de medios bajo demanda. |
| US7493646B2 (en) | 2003-01-30 | 2009-02-17 | United Video Properties, Inc. | Interactive television systems with digital video recording and adjustable reminders |
| US7912457B2 (en) | 2004-04-21 | 2011-03-22 | Qualcomm Incorporated | Methods and apparatus for creation and transport of multimedia content flows |
| US8544043B2 (en) | 2004-07-21 | 2013-09-24 | Qualcomm Incorporated | Methods and apparatus for providing content information to content servers |
| KR100999285B1 (ko) * | 2004-12-09 | 2010-12-07 | 콸콤 인코포레이티드 | 멀티미디어 컨텐트 플로우들을 생성하고 분산 네트워크로전달하기 위한 방법 및 장치 |
| US7653085B2 (en) * | 2005-04-08 | 2010-01-26 | Qualcomm Incorporated | Methods and apparatus for enhanced delivery of content over data network |
| JP5062999B2 (ja) * | 2005-12-28 | 2012-10-31 | キヤノン株式会社 | 情報処理装置及びその制御方法とプログラム |
| JP2009531963A (ja) * | 2006-03-29 | 2009-09-03 | トムソン ライセンシング | ケーブルモデム上でのビデオ |
| KR100938259B1 (ko) * | 2006-11-29 | 2010-01-22 | 한국전자통신연구원 | Ｉｐｔｖ 서비스 제공 기능을 가지는 ｃａｔｖ 네트워크시스템 및 그 방법 |
| US20090025027A1 (en) * | 2007-07-20 | 2009-01-22 | Michael Craner | Systems & methods for allocating bandwidth in switched digital video systems based on interest |
| US10063934B2 (en) | 2008-11-25 | 2018-08-28 | Rovi Technologies Corporation | Reducing unicast session duration with restart TV |
| JP5532768B2 (ja) * | 2009-09-07 | 2014-06-25 | 日本電気株式会社 | 動画配信システム、その帯域制限方法、管理サーバ及びプログラム |
| US20110154420A1 (en) | 2009-12-17 | 2011-06-23 | Level 3 Communications, Llc | Data Feed Resource Reservation System |
| US8805418B2 (en) | 2011-12-23 | 2014-08-12 | United Video Properties, Inc. | Methods and systems for performing actions based on location-based rules |
| KR102168428B1 (ko) * | 2019-01-23 | 2020-10-21 | 넷마블 주식회사 | 컨텐츠 다운로드 방법, 컨텐츠 다운로드 관리 서버 및 컴퓨터 프로그램 |
| CA3158104A1 (en) * | 2019-11-25 | 2021-06-03 | Mircea Orban | Automated lifecycle management flexible scaling and dynamic resource allocation for virtualized cable data plane applications |
-
2001
- 2001-11-30 JP JP2001367850A patent/JP3590376B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003169087A (ja) | 2003-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3590376B2 (ja) | Ｉｐストリーミングシステム、ポリシーサーバ及びｉｐストリーミング配信方法 | |
| US12170799B2 (en) | Method and system of managing and allocating communication related resources | |
| CA2682364C (en) | Bandwidth sensitive switched digital video content delivery | |
| AU2008279824C1 (en) | Systems and methods for allocating bandwidth in switched digital video systems based on interest | |
| AU2008279824B2 (en) | Systems and methods for allocating bandwidth in switched digital video systems based on interest | |
| US9554166B2 (en) | Methods and apparatus for providing multi-source bandwidth sharing management | |
| EP3145198B1 (en) | Video policy server | |
| US9986062B2 (en) | Quality of service for distribution of content to network devices | |
| US6928656B1 (en) | Method for delivery of IP data over MPEG-2 transport networks | |
| US20030126610A1 (en) | IP streaming system, network router, IP-streaming set-top box, and IP streaming distribution method | |
| US20090178091A1 (en) | Contents distribution method and receiving device | |
| JP2005512361A (ja) | ストリームコンテンツ配信のサービス品質制御 | |
| US8787165B2 (en) | Parameterized quality of service for multimedia in a coaxial network | |
| KR20210119357A (ko) | 전자장치, 그의 제어 방법, 프로그램, 기록매체 및 iptv 시스템 | |
| KR100656526B1 (ko) | 토큰 정보를 이용한 주문형 비디오 서비스의 대역폭 보장시스템 및 그 방법 | |
| AU2014201280B2 (en) | Systems and Methods for Allocating Bandwidth in Switched Digital Video Systems Based on Interest | |
| KR100765321B1 (ko) | 보장된 큐오에스를 제공하는 브이오디 시스템 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040311 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040517 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040817 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040819 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070827 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080827 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090827 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090827 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100827 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100827 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110827 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110827 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120827 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120827 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130827 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |