JP2003169087A - Ｉｐストリーミングシステム、ポリシーサーバ、ネットワーク中継装置及びｉｐストリーミング配信方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＱｏＳを確保しつつネットワーク資源を
有効に活用する。 【解決手段】 複数のユーザ端末５１，５２が接続され
るケーブル４０を収容するＣＭＴＳ３１と視聴要求コン
テンツのストリーミング配信を実行するヘッドエンドシ
ステム１０とがネットワーク２０で接続されてなるシス
テムである。このヘッドエンドシステムは、ユーザから
視聴要求コンテンツの種類を受理するナビゲーションサ
ーバ１１と、このナビゲーションサーバから視聴要求コ
ンテンツの通知を受けると、ＱｏＳ確保可能か否かの問
い合わせを出し、配信可能であるとき要求コンテンツを
配信する配信サーバ１２と、この問合せに基づき、コン
テンツを配信するネットワーク経路のネットワーク中継
関連装置のリソース利用状況およびユーザ端末が接続さ
れるケーブルの周波数帯域の使用状況を判断し、この判
断結果を配信サーバに通知するポリシーサーバ１３とで
構成される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ケーブルインター
ネット上でＩＰストリーミングを利用して通信サービス
を行うＩＰストリーミングシステム、ポリシーサーバ、
ネットワーク中継装置及びＩＰストリーミング配信方法
に関する。

【０００２】

【従来の技術】近年、ＣＡＴＶにおける双方向通信のイ
ンフラ整備に伴い、ケーブルインターネットを用いて、
映像や音楽などのデータ通信サービスを提供することが
行われている。

【０００３】このようなデータ通信サービスは、インタ
ーネットの特性上、ユーザの利用状況に応じて回線条件
が変動するベストエフォート型のサービスとなってい
る。

【０００４】そこで、データ通信サービスの提供業者で
は、例えば下り方向のデータ伝送速度がユーザ当たり最
大１．５Ｍｂｐｓのサービスを提供しようとする場合、
各ユーザ毎にケーブルルータと称するＣＭＴＳ（Cable
Modem Termination System；ケーブルモデム終端装
置）を用いて、下り方向の単位時間当たりのトラフィッ
クを測定し、ある時間の平均値が１．５Ｍｂｐｓを越え
た場合、下り方向のトラフィックを一時停止するなどの
方法をとり、データ通信サービスを提供している。

【０００５】

【発明が解決しようとする課題】しかしながら、以上の
ようなデータ通信サービスでは、インターネット上で映
像等マルチメディアコンテンツを送信し、リアルタイム
に再生可能なＩＰストリーミングを利用した放送システ
ムであっても、当該マルチメディアコンテンツを確実に
配信することが難しい。

【０００６】この発明においてＩＰストリーミングと
は、Internet Protocolを利用して映像や音声等のコン
テンツをＩＰパケットとして配信し、ユーザ側にてコン
テンツを再生する技術全般を指し、ユーザ側でＩＰパケ
ットをメモリに受信して再生する狭義のＩＰストリーミ
ングと、ユーザ側で一部か全てのコンテンツを一旦ＨＤ
Ｄ等に蓄積した後に再生を開始する疑似ＩＰストリーミ
ングの双方の方法を含む。

【０００７】本発明は上記事情に鑑みてなされたもの
で、ユーザからコンテンツの視聴要求に対し、ネットワ
ークの資源の使用状況をチェックし、ＱｏＳ（Quality
ｏｆService：サービス品質）を確保しつつネットワ
ーク資源を有効に活用し、視聴要求コンテンツを配信す
るＩＰストリーミングシステム、ポリシーサーバ、ネッ
トワーク中継装置及びＩＰストリーミング配信方法を提
供することを目的とする。

【０００８】

【課題を解決するための手段】（１） 上記課題を解決
するために、各ユーザ端末からのコンテンツ視聴要求に
対し、視聴要求のあったコンテンツを配信する本発明に
係るＩＰストリーミングシステムは、コンテンツの視聴
要求を行う複数のユーザ端末が接続されるケーブルを収
容する複数のＣＭＴＳと当該視聴要求コンテンツのスト
リーミング配信を実行するヘッドエンドシステムとがネ
ットワークで接続され、前記ヘッドエンドシステムは、
ユーザ端末側から送られてくる要求元情報及び視聴要求
コンテンツの種類を受理するナビゲーションサーバと、
このナビゲーションサーバから要求元情報、視聴要求コ
ンテンツの通知を受けると、当該コンテンツを配信する
ためのＱｏＳが確保可能か否かの問い合わせを送出する
配信サーバと、この配信サーバからのＱｏＳ確保の問い
合わせを受けた場合、コンテンツを配信するネットワー
ク経路に存在する前記ＣＭＴＳを含むネットワーク中継
関連装置のリソースの利用状況およびユーザ端末が接続
される前記ケーブルの周波数帯域の使用状況を判断し、
この判断結果を配信サーバに通知するポリシーサーバと
を設けた構成である。

【０００９】本発明は以上のような構成とすることによ
り、ナビゲーションサーバがユーザ端末から要求元情報
のもとに視聴要求コンテンツを受けると、配信サーバに
通知する。この配信サーバは、要求元情報及び視聴要求
コンテンツに基づき、配信情報データベースからコンテ
ンツの必要帯域情報を読み出し、要求元情報とともに、
ポリシーサーバに配信すべきコンテンツのＱｏＳが確保
可能か否かについて問い合わせをする。ここで、ポリシ
ーサーバは、コンテンツを配信するネットワーク経路に
存在する前記ＣＭＴＳを含むネットワーク中継関連装置
のリソースの利用状況およびユーザ端末が接続される前
記ケーブルの周波数帯域の使用状況を判断するので、Ｑ
ｏＳ実現のためにリソースの使用状態および周波数帯域
の状態を判断し、両方が適切な状態にあれば、ＱｏＳ確
保可能と判断し、配信サーバに視聴要求のあったコンテ
ンツの配信が可能であることを通知するので、ＱＯＳを
確保しつつネットワーク資源を有効に活用し、視聴要求
コンテンツを配信することができる。

【００１０】なお、ＱｏＳ実現のためにリソースの使用
状態および周波数帯域の状態を判断処理機能を各ＣＭＴ
Ｓにもたせることも可能である。

【００１１】（２） また、本発明に係るポリシーサー
バは、各ユーザ端末までのネットワーク経路に存在する
リソースを管理するリソース管理記憶手段と、システム
全体の周波数帯域を管理する周波数管理記憶手段と、ユ
ーザ端末からのコンテンツ視聴要求のもとに、外部から
要求元情報、必要帯域情報を受けると、リソース管理記
憶手段を参照し、前記視聴要求コンテンツに関するＱｏ
Ｓ確保のためのリソース有無を判断する第１の判断手段
と、外部から要求元情報、必要帯域情報を受けると、前
記周波数管理記憶手段を参照し、視聴要求のあった前記
ユーザ端末に接続されるラインにおける周波数帯域の空
き有無を判断する第２の判断手段とを設けた構成であ
る。

【００１２】この発明は以上のような構成とすることに
より、ポリシーサーバが配信サーバなどの外部から要求
元情報、必要帯域情報を受けると、リソース管理記憶手
段を参照し、視聴要求コンテンツに関するＱｏＳ確保の
ためのリソース有無を判断し、また周波数管理記憶手段
を参照し、視聴要求のあったユーザ端末に接続されるラ
インにおける周波数帯域の空き有無を判断するので、配
信サーバにＱｏＳを確保可能であることを知らせること
ができる。

【００１３】なお、ＱｏＳ確保のためのリソース有無と
ＱｏＳ確保のためのリソース有無とを判断するようにし
たが、何れか一方だけを判断し、視聴要求のあったコン
テンツを配信する構成であってもよい。

【００１４】さらに、ポリシーサーバにリソース管理記
憶手段および周波数管理記憶手段を設け、視聴要求コン
テンツに関するＱｏＳ確保のためのリソース有無および
ユーザ端末が接続されるケーブルにおける周波数帯域の
空き有無を判断したが、例えばネットワーク中継装置で
ある例えばＣＭＴＳにリソース管理記憶手段および周波
数管理記憶手段を設け、視聴要求コンテンツに関するＱ
ｏＳ確保のためのリソース有無およびユーザ端末に接続
されるラインにおける周波数帯域の空き有無を判断する
場合でも、前述するポリシーサーバと同様の作用効果を
奏することが可能である。

【００１５】（３） コンテンツの視聴要求を行う複数
のユーザ端末が接続されるケーブルを収容する複数のＣ
ＭＴＳと当該視聴要求コンテンツのストリーミング配信
を実行するヘッドエンドシステムとがネットワークで接
続されてなるＩＰストリーミングシステムにおいて、あ
るユーザ端末から要求元情報のもとにメニュー画面要求
を受けた場合、前記ヘッドエンドシステムが当該ユーザ
端末にメニュー画面を送信し、当該ユーザ端末から視聴
要求コンテンツを受け付けるコンテンツ要求受付けステ
ップと、このステップにより視聴要求コンテンツを受付
けると、予め記憶される配信要求コンテンツ、当該コン
テンツの配信に必要な帯域情報、配信必要時間情報等を
読み出し、前記ヘッドエンドシステムが収容するポリシ
ーサーバにＱｏＳ確保可能かを問い合わせる問合せステ
ップと、このステップにより問い合わせを受けた場合、
ポリシーサーバがリソース管理記憶手段に記憶される前
記要求元ユーザ端末までのネットワーク経路に存在する
リソース情報を参照し、前記視聴要求コンテンツに関す
るＱｏＳ確保のためのリソース有無を判断するリソース
確保判断ステップと、問合せステップにより問い合わせ
を受けると、システム全体の周波数帯域を管理する周波
数管理記憶手段を参照し、前記ユーザ端末に接続される
ラインにおける周波数帯域の空き有無を判断する帯域確
保判断ステップと、各判断ステップにより確保可能と判
断されたとき、前記ヘッドエンドシステムが前記視聴要
求コンテンツを前記要求元ユーザ端末に配信するステッ
プとを有するストリーミング配信方法である。

【００１６】このようなストリーミング配信方法であっ
ても、コンテンツ要求受付けステップで視聴要求を受付
けると、問合せステップにて予め記憶されるコンテンツ
の配信に必要な帯域情報、配信必要時間情報等を読み出
し、ポリシーサーバにＱｏＳ確保可能かを問い合わせる
ので、ポリシーサーバがリソース管理記憶手段に記憶さ
れる前記要求元ユーザ端末までのネットワーク経路に存
在するリソース情報を参照しコンテンツを配信するネッ
トワーク経路に存在する前記ＣＭＴＳを含むネットワー
ク中継関連装置のリソースの利用状況およびユーザ端末
が接続される前記ケーブルの周波数帯域の使用状況を判
断するので、ＱｏＳを確保しつつネットワーク資源を有
効に活用し、視聴要求コンテンツを配信することが可能
となる。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態を説明
するに先立ち、例えば米国の放送システムについて説明
する。

【００１８】（１） 米国の放送システムの現状につい
て。

【００１９】アナログ地上波をケーブル上にブロードキ
ャストする米国の放送システムでは、ＲＦ（Radio Fre
quency）で利用可能な周波数帯のうち、５０ＭＨｚ〜４
５０ＭＨｚの周波数範囲で利用されているが、この場合
には１チャンネル当たり６ＭＨｚ程度の帯域が割当てら
れている。

【００２０】一方、ケーブルインターネットを用いて、
データ通信を行う場合、４５０ＭＨｚ以外の帯域、例え
ば５００ＭＨｚ〜６００ＭＨｚの周波数帯域が利用され
ている。すなわち、データ通信を行う場合、６ＭＨｚ帯
域でディジタル変調であるＱＡＭ（Quadrature Amplit
ude Modulation：直交振幅変調）変調が利用され、ま
たＣＭＴＳやＩＰＢ（ＩＰストリーミング用セットトッ
プボックス）のごときＩＰストリーミング対応装置の内
部に実装されているチューナは前述する６ＭＨｚ帯毎に
チューニングされている。このＱＡＭ方式は、正弦搬送
波のパラメータである振幅、位相、周波数のうち、振幅
と位相の２つのパラメータを同時に変調することによ
り、狭い帯域幅の中で多くのデータを搬送できる方式で
ある。因みに、ケーブルインタネットで主に使用される
ＱＡＭ変調には６４ＱＡＭ方式と２５６ＱＡＭ方式とが
あるが、例えば６４ＱＡＭ方式の場合には約２７Ｍｂｐ
ｓの伝送レートが得られる。現在、多数のユーザが２７
Ｍｂｐｓの伝送帯域を共有する形でデータ通信サービス
が行われている。

【００２１】（２） 本発明に係るＩＰストリーミング
システムの構成について。

【００２２】図１は本発明に係るＩＰストリーミングシ
ステムの一実施の形態を示す構成図である。

【００２３】このＩＰストリーミングシステムは、多種
類のマルチメディアコンテンツを蓄積し、ユーザからの
視聴要求に応じた配信処理を実行するヘッドエンドシス
テム１０と、例えばリング状の接続構成をとるネットワ
ーク２０と、複数のディストリビューションＨＵＢ３０
とが設けられ、これら各ディストリビューションＨＵＢ
３０に収容されるＲＦケーブル４０にＩＰＢ５１を介し
てユーザ端末５２が接続されている。本発明では、ユー
ザ端末と呼ぶ場合には、ＩＰＢ５１とユーザ端末５２と
の組み合わせが対象となる。

【００２４】また、ディストリビューションＨＵＢ３０
とユーザ端末５２がもつＩＰＢ５１との間は、ＲＦケー
ブル４０だけでは距離が制限されることから、光信号に
変換し距離を延長するために、電気−光変換器、ＨＦＣ
（Hybrid Fiber／Coax）ネットワーク、光−電気変換
器などが用いられるが、ここでは本発明の要旨と関連性
が薄いことから省略する。

【００２５】このヘッドエンドシステム１０は、ナビゲ
ーションサーバ１１、配信サーバ１２、ポリシーサーバ
１３およびＱｏＳを提供可能なルータ１４が設けられて
いる。

【００２６】なお、ＣＭＴＳ３１が１つで構成される場
合には、ＣＭＴＳ３１を含めてヘッドエンドシステムと
呼ぶ場合もある。

【００２７】このナビゲーションサーバ１１は、当該サ
ーバ１１自体が所有するメニューを容易に閲覧可能なＥ
ＰＧ（Electronic Program Guide：電子プログラム・
ガイド）およびナビゲーションクライアントソフトウエ
ア等の間で連携をとりながら、ユーザが視聴を希望する
コンテンツの種類を受理し、配信サーバ１２に通知する
役割をもっている。

【００２８】配信サーバ１２は、多種類のマルチメディ
アコンテンツの他、各コンテンツの配信に必要な帯域情
報、配信必要時間情報その他配信に必要な情報を蓄積す
る大容量の配信情報データベース１５を有し、当該デー
タベース１５に蓄積されるマルチメディアコンテンツを
含む配信情報を管理する一方、ナビゲーションサーバ１
１から配信通知を受けると、ポリシーサーバ１３に対
し、コンテンツを配信するためのＱｏＳが確保可能か否
かの問い合せを実施し、ＱＯＳが確保可能な場合、ユー
ザに対して希望するコンテンツを配信する機能をもって
いる。

【００２９】ポリシーサーバ１３は、リソース管理デー
タベース１６及び周波数管理データベース１７を有し、
配信サーバ１２からＩＰアドレスなどの要求元情報、必
要帯域情報をもとにＱｏＳ確保に関する問い合せを受け
ると、要求元ユーザに対してコンテンツを配信するため
に、ＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ
実現のためのリソースを管理するリソース管理データベ
ース１６及びシステム全体の周波数帯域を管理する周波
数管理データベース１７の格納データからＣＭＴＳ３１
を含むネットワーク中継関連装置の利用状況および要求
元ユーザ端末が接続されるＲＦケーブルごとの周波数帯
域の使用状況を判断し、ネットワーク経路のＱｏＳ確保
および配信要求元ユーザの接続されるＲＦケーブルの帯
域確保を行う機能をもっている。なお、リソース管理デ
ータベース１６及び周波数管理データベース１７はそれ
ぞれ個別に独立したデータベースである必要がなく、同
一のデータベースにエリア分けして必要な情報を記憶す
る構成であってもよい。

【００３０】ルータ１４は、ＩＰパケットのヘッダをチ
ェックし、前述するようにＱｏＳが確保可能な状態で中
継するものであって、キューメカニズムやスケジュール
管理メカニズムを有し、同一宛先トラフィックに対して
も各ＩＰパケットに定義されるフローごとに管理する。
また、ルータ１４は、配信サーバ１２から送信されるＲ
ＳＶＰ（Resource Reservation Protocol）に基づ
き、ルーター間の特定の通信チャンネルの伝送帯域を管
理し、必要なＱｏＳを実現のためのリソースを確保する
機能をもっている。

【００３１】前記ネットワーク２０は、ストリーミング
配信を実行するために必要な各種サーバ１１〜１３群を
収容するヘッドエンドシステム１０と遠隔地に設置され
るＣＭＴＳ３１を収容する多数のディストリビューショ
ンＨＵＢ３０とを接続する例えば光ファイバがリング状
に形成された伝送ラインとなっている。

【００３２】各ディストリビューションＨＵＢ３０は、
多数のユーザの配信拠点となる部分であり、ＲＦケーブ
ル４０を収容するリピータ機能或いはスイッチング機能
をもったＬＡＮの集線装置としての役割を果たすもので
あって、少なくともＣＭＴＳ３１が収容されている。こ
のＣＭＴＳ３１は一種のネットワーク中継装置である。

【００３３】このＣＭＴＳ３１は、基本的にはＲＦイン
タフェースを有し、ルータ１４と同様の機能を有するケ
ーブルルータである。つまり、ルータ１４と同様にキュ
ーメカニズムやスケジュール管理メカニズムが設けられ
ている。

【００３４】前記ＩＰＢ（ＩＰストリーミング用セット
トップボックス）５１は、視聴要求コンテンツに対応す
るＩＰパケットを受信し、当該パケットに含まれるアプ
リケーションなど、上位の映像、音声に係るデータをＣ
ＯＤＥＣ（コード・デコード）に従ってデコード処理を
実施し、テレビジョンＴＶ、ＣＲＴや液晶のモニタを含
むユーザ端末５２に表示する機能をもっている。

【００３５】従って、以上のようなＩＰストリーミング
システムの実施の形態によれば、ポリシーサーバ１３に
ＣＭＴＳを含むネットワーク中継関連装置のＱｏＳ実現
のためのリソースを管理するリソース管理データベース
１６及びシステム全体の周波数帯域を管理する周波数管
理データベース１７を設け、ＩＰＢ５１を含むユーザ端
末５２からコンテンツ視聴要求をナビゲーションサーバ
１１で受けると、配信サーバ１２に通知し、配信情報デ
ータベース１５から視聴要求コンテンツに関する必要帯
域情報、配信に必要な時間情報を要求元情報とともに、
ＱｏＳ確保可能か否かをポリシーサーバ１３に問い合わ
せる。このポリシーサーバ１３は、リソース管理データ
ベース１６を参照し、ＣＭＴＳ３１を含むネットワーク
中継関連装置の利用状況を判断し、また周波数管理デー
タベース１７を参照し、要求元ユーザ端末が接続される
ＲＦケーブルごとの周波数帯域の使用状況を判断するの
で、ネットワーク経路のＱｏＳ確保および配信要求元ユ
ーザの接続されるＲＦケーブルの帯域確保を行うことが
でき、ネットワーク資源を利用し、ＱｏＳを確保しなが
ら視聴要求コンテンツをユーザ端末に配信することがで
きる。

【００３６】（３） リソース管理データベース１６及
び周波数管理データベース１７の構成データ例につい
て。

【００３７】＊ リソース管理データベース１６につい
て。

【００３８】一般に、ＱｏＳを実現するためのネットワ
ーク中継関連装置のリソースには制限があるので、Ｑｏ
Ｓ保証可能な帯域にもおのずと限界がある。図１に示す
ヘッドエンドシステム１０に収容されるルータ１４、各
ディストリビューションＨＵＢ３０に収容される例えば
ＣＭＴＳ（１）３１、ＣＭＴＳ（２）３１が確保可能な
帯域は、自身のＣＰＵやソフトウエアの処理能力により
制限され、ＲＦインタフェース毎に１６Ｍｂｐｓの転送
能力しかもっていない。さらに、ＱｏＳ管理単位である
フローの数がメモリの実装上の制約からキューの数が
「３２」であるが、ＲＦインタフェース当たり３２本の
異なるフローが処理可能である場合、例えばコンテンツ
の配信に必要な最低帯域が５００ｋｂｐｓとすれば、Ｒ
Ｆインタフェース毎の転送能力である１６Ｍｂｐｓに対
し、各ネットワーク中継関連装置のリソースは５００ｋ
ｂｐｓにて３２本が限界である（図４の帯域番号参
照）。

【００３９】因みに、リソース管理データベース１６の
構成データの一例としては、ユーザ名、ユーザ（ＩＰ
Ｂ）のＩＰアドレス、配信サーバ１２からの経路情報
（例えばネットワーク中継装置名）、ネットワーク中継
装置名、インタフェース名、帯域番号、使用帯域、使用
開始時間、予想使用時間（或いは予想終了時間）、遅延
時間等が挙げられる。

【００４０】＊ 周波数管理データベース１７につい
て。

【００４１】ＣＭＴＳ３１のＲＦインタフェースは、チ
ューナ１回路に付き１基本周波数（６ＭＨｚ）が使用可
能である。前述したように６４ＱＡＭ方式の変調を使用
した場合、伝送速度が２７Ｍｂｐｓとなる。このうち、
各種プロトコルのオーバヘッドを考慮し、下り方向の実
行速度を２０Ｍｂｐｓと見積もった場合、サービスを受
けるユーザは当該速度範囲でなければならない。

【００４２】因みに、周波数管理データベース１７の構
成データの一例としては、ユーザ名、ユーザ（ＩＰＢ）
のＩＰアドレス、ネットワーク中継装置名、インタフェ
ース名、使用可能帯域、使用帯域数、使用開始時間、予
想使用時間（或いは予想終了時間）、使用コンテンツア
ドレス（ＵＲＬ）等が挙げられる。

【００４３】（４） 図１に示すシステムの動作ないし
本発明に係るＩＰストリーミング配信方法について（図
２、図３参照）。

【００４４】先ず、ポリシーサーバ１３は、ＣＭＴＳ３
１を含むネットワーク中継関連装置のＱＯＳを実現する
為、当該装置における使用帯域等の情報をリソース管理
データベース１６に格納し、またＲＦケーブル４０の周
波数帯域等の情報を周波数管理データベース１７に格納
するなどし、適切な管理を行うための初期化を実施する
（Ｓ１：ポリシーサーバ初期化ステップ）。

【００４５】この状態においてユーザがＩＰＢ５１を起
動し、ＥＰＧのメニュー画面の要求操作を行うと、自身
のＩＰアドレス等の要求元情報のもとにメニュー画面要
求情報がＣＭＴＳ３１、ネットワーク２０を経由し、ナ
ビゲーションサーバ１１に送られる（Ｓ２）。ここで、
ナビゲーションサーバ１１は、画面要求に基づいて自身
が所有するＥＰＧのメニュー画面を特定のユーザの要求
元情報を所有するＩＰＢ５１に配信する（Ｓ３）。この
メニュー画面はユーザ端末５２に表示される。ユーザは
メニュー画面からジャンル毎（アクション、ドラマ）の
ボタンやシステムプロバイダーが推奨するコンテンツ等
を見ることができる。

【００４６】ここで、ユーザがユーザ端末５２に表示さ
れるメニュー画面から特定の映像等マルチメディアコン
テンツを指定すると、該当ＩＰＢ５１から自身の例えば
ＩＰアドレス等の要求元情報のもとに映像コンテンツ視
聴要求が送信される。ヘッドエンドシステム１０のナビ
ゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３
１、ネットワーク２０を介して送られてくる要求元情
報、映像コンテンツ視聴要求を受信し、コンテンツ視聴
要求を受付ける（Ｓ４）。これらＳ２〜Ｓ４はコンテン
ツ要求受付けステップに相当する。

【００４７】このナビゲーションサーバ１１は、ユーザ
によって指定された映像等のコンテンツの視聴要求を受
信した後、配信サーバ１２に通知する（Ｓ５）。

【００４８】この配信サーバ１２は、自身が管理する配
信情報データベース１５から配信要求コンテンツ、当該
コンテンツの配信に必要な帯域情報、配信必要時間情報
等を読み出し、要求元（送信先）情報とともに、ポリシ
ーサーバ１３に送信し、ＱｏＳ確保の観点から配信可能
か否かを問い合わせる（Ｓ６）。これらステップＳ５，
Ｓ６は問い合わせステップを意味する。

【００４９】ここで、ポリシーサーバ（帯域ブローカ）
１３は、要求元情報に基づいてリソース管理データベー
ス１６から要求コンテンツを配信するためのネットワー
クの経路情報を取得し（Ｓ７）、さらに要求元情報およ
び必要帯域情報（例えば５００ｋｂｐｓ等）をもとに要
求元までのネットワーク経路に存在するＣＭＴＳ３１、
ヘッドエンドシステム１０内のルータ１４を含む全ての
ネットワーク中継関連装置に関し、リソース管理データ
ベース１６に格納される情報を参照し、５００ｋｂｐｓ
の帯域をもつＱｏＳ実現可能なリソースが有るか否かを
判断する（Ｓ８）。リソース無しと判断されたとき、ポ
リシーサーバ１３は、配信サーバ１２に配信不可能と回
答する。このとき、予想使用時間情報をもとに配信可能
時間も回答する（Ｓ９）。そして、新たな外部から入力
待ちの状態となる。

【００５０】ポリシーサーバ１３は、ステップＳ８にお
いてＱｏＳ実現のためのリソース有りと判断した場合、
図４に示すようにリソース管理データベース１６に規定
される項目のうち、例えば帯域番号特定、当該帯域番号
対応使用帯域への「１」設定、使用開始時間の書込み等
のなどの帯域使用情報を更新する（Ｓ１０）。これらス
テップＳ５〜Ｓ１０はリソース確保判断ステップに相当
する。

【００５１】さらに、ポリシーサーバ（帯域ブローカ）
１３は、要求元情報および必要帯域情報をもとに、図５
に示す周波数管理データベース１７を参照し、要求元Ｉ
ＰＢ５１が現在接続されているＲＦケーブル４０に対応
するインタフェースに５００ｋｂｐｓ帯域の空きがある
か否かを判断する（Ｓ１１）。ここで、帯域に空きがな
い場合には配信不可能である旨を配信サーバ１２に回答
するが、同時に予想使用時間情報をもとに配信可能時間
も回答する。また、前述したステップＳ１０により確保
したリソースを開放するために、リソース管理データベ
ース１６をアップデータする（Ｓ１２）。

【００５２】一方、ポリシーサーバ１３は、ステップＳ
１１においてＲＦケーブル４０に対応するインタフェー
スに帯域に空きがあると判断された場合、要求元ユーザ
のコンテンツ配信要求がサービスの上限値を越えている
か否かを判断し（Ｓ１３）、越えていないと判断された
場合には配信サーバ１２に対して配信可能であることを
回答するとともに、その帯域の利用分について周波数管
理データベース１７を更新する（Ｓ１４）。これらステ
ップＳ１１〜Ｓ１４は帯域確保判断ステップに相当す
る。

【００５３】ここで、配信サーバ１２は、ポリシーサー
バ１３から配信可能とする回答を受けると、ＲＳＶＰ等
のプロトコルを用いて、ＣＭＴＳ３１を含むネットワー
ク中継関連装置の実際の使用帯域をチェックし、使用す
るリソースを確保する（Ｓ１５）。

【００５４】このＲＳＶＰプロトコルとしては、通常、
配信サーバ１２からｐａｔｈメッセージを送信し、当該
ｐａｔｈメッセージの条件（帯域や遅延時間等）が正当
であるか否かについてルータ１４、ＣＭＴＳ３１の順序
で順次チェックしながら、コンテンツ配信要求元である
ＩＰＢ５１まで到達する。このＩＰＢ５１は、エラーな
しでｐａｔｈメッセージを受信すると、ｒｅｓｖメッセ
ージを配信サーバ１２に向けて送信する。ＣＭＴＳ３
１、ルータ１４は、ＩＰＢ５１から送信されるｒｅｓｖ
メッセージに基づいて実際のリソースを割当て予約す
る。

【００５５】配信サーバ１２は、ｒｅｓｖメッセージを
受けると、予約したネットワーク中継関連装置のリソー
スとＲＦケーブル４０の周波数帯を利用し、実際の映像
等コンテンツを配信要求元のＩＰＢ５１に配信する（Ｓ
１６）。ステップＳ１５，Ｓ１６はコンテンツ配信ステ
ップを意味する。

【００５６】配信サーバ１２は、コンテンツの送信を終
了すると、ポリシーサーバ１３に対し、配信要求コンテ
ンツに対する送信終了を通知する（Ｓ１７）。ポリシー
サーバ１３は、送信終了情報を受け取ると、両管理デー
タベース１６，１７の該当コンテンツ配信のために利用
した帯域分の情報について開放する（Ｓ１８）。このス
テップＳ１７，Ｓ１８は帯域確保情報開放ステップを意
味する。

【００５７】従って、以上のようなＩＰストリーミング
配信方法の実施の形態によれば、ユーザ端末側からの視
聴要求コンテンツの受付けステップ、この受付けを行っ
たナビゲーションサーバ１１の配信サーバ１２への通知
及び配信サーバによる配信コンテンツの必要帯域情報、
配信するために必要な時間情報を取得し、ポリシーサー
バ１３にＱｏＳ実現のための問合せを行う問合せステッ
プ、さらにポリシーーバ１３によるリソース確保判断、
使用帯域確保判断を行うステップ、何れも確保可能な場
合に配信サーバ１２に通知するステップを採用すること
により、リソース及び使用帯域を確保し、ＱｏＳを確保
しつつ視聴要求コンテンツを確実に配信できる。

【００５８】（５） ポリシーサーバ１３の実際の動作
処理例について（図２〜図５参照）。

【００５９】なお、サービスの前提としては、以下の＊
に記述するような内容を設定する。

【００６０】＊ コンテンツは、映像品質や音声品質等
に応じて、５００ｋｂｐｓの整数倍の伝送レートが必要
となるので、５００ｋｂｐｓ〜２Ｍｂｐｓまでの種類が
あるとする。例えば高品質映像コンテンツの場合は１Ｍ
ｂｐｓ、中程度の品質の場合は５００ｋｂｐｓが必要と
なるという具合である。

【００６１】＊ ポリシーサーバ１３にて、１サービス
（例えば映画１本の視聴）毎にサービス使用の可否がリ
ソース等の状況に応じて判断されるものとする。

【００６２】＊ ＣＭＴＳ３１の１インタフェース毎
（６ＭＨｚ帯当たり）の伝送速度は、６４ＱＡＭ変調方
式の場合には２７Ｍｂｐｓであるが、各種プロトコルの
オーバヘッドがあるので、有効速度は２０Ｍｂｐｓとす
る。

【００６３】＊ ルータ１４、ＣＭＴＳ（１）３１、Ｃ
ＭＴＳ（２）３１の確保可能な帯域は、インタフェース
毎に１６Ｍｂｐｓであり、かつ、管理可能なフローの数
は５００ｋｂｐｓで３２本とする。

【００６４】＊ 通常、１つのＩＰＢ５１当たり最大２
Ｍｂｐｓのベストエフォート型通信を保証するが、コン
テンツ配信要求時は５００ｋｂｐｓの整数倍である最大
例えば２Ｍｂｐｓまでの範囲でＱＯＳ管理に基づいた視
聴が可能とする。

【００６５】＊ ＣＭＴＳ（１）３１、ＣＭＴＳ（２）
３１の１インタフェース当たりに対し、ＩＰＢ５１の接
続台数は５０台とする。すなわち、５０台中の２０％の
使用率以上になると、各ユーザの使用可能な速度は２Ｍ
ｂｐｓ以下となる（２０Ｍｂｐｓ÷（５０台の２０％）
＝２Ｍｂｐｓ）。

【００６６】以上のような設定条件のもとに実際のポリ
シーサーバ１３の詳細な動作について説明する。

【００６７】 配信サーバ１２は、ナビゲーションサ
ーバ１１からＩＰアドレス等の要求元情報のもとに映像
コンテンツの配信要求を受けると、配信情報データベー
ス１５に格納されるコンテンツ配信に必要な帯域情報
（例えば５００ｋｂｐｓ）および配信必要時間情報（例
えば２時間）を読み出し、要求元情報とともに、ポリシ
ーサーバ１３に対して配信可能か否かの問い合わせを行
う（図２のＳ６）。

【００６８】 ポリシーサーバ１３は、配信要求元ユ
ーザが接続されているＣＭＴＳ（１）３１とインタフェ
ースとを確認する為、要求元情報であるＩＰアドレスを
キーとし、リソース管理データベース１６を用いて、配
信サーバ１２からユーザＩＰＢ５１までのネットワーク
経路情報、中継装置名（複数存在する場合には複数）、
インタフェース名を検索する（図２のＳ７）。例えばユ
ーザＡを指定し、ルータ１４／インタフェース１とＣＭ
ＴＳ（１）３１／インタフェース１（図４参照）を取得
する。

【００６９】 次に、ポリシーサーバ１３は、ナビゲ
ーションサーバ１１から受け取った要求元情報（通常，
ＩＰアドレス）と必要帯域情報とをもとに、リソース管
理データベース１６を参照し、要求元ＩＰＢ５１までの
ネットワーク中経路に存在するルータ１４とＣＭＴＳ
（１）５１に帯域確保が可能か否かを判断する（図２の
Ｓ８）。具体的には、図４に示すごとく、ＣＭＴＳ
（１）／インタフェース１においては、ＣＭＴＳ（１）
のＱｏＳ実現の為の全リソース３２本（５００ｋｂｐ
ｓ）のうち、現在、帯域番号「１」，「２」，「３」し
か使用されておらず、未だ十分に設定可能な状態にある
ことが分るので、今回の配信要求に対して帯域番号
「４」を特定し、対応する使用帯域項目に「１」を設定
し、使用開始時間を記入する。リソース管理データベー
ス１６には図示されていないが、同様にルータ１４／イ
ンタフェース１についても実行する。

【００７０】 さらに、ポリシーサーバ１３は、要求
元情報と必要帯域情報をもとに、周波数管理データベー
ス１７を参照し、ＣＭＴＳ（１）／インタフェース１
（要求元ＩＰＢが現在接続されているＲＦケーブル４
０）に５００ｋｂｐｓ帯域の空きがあるか否かを判断す
る（図３のＳ１１）。具体的には、ＣＭＴＳ（１）／イ
ンタフェース１を指定し、ＲＦインタフェース当たりの
周波数割り当てからくる制限（例えば合計２０Ｍｂｐ
ｓ）と現在使用中の使用帯域との比較を行う。ここで、
図５に示すごとく、ＣＭＴＳ（１）／インタフェース１
のＲＦインタフェースの使用周波数帯域の合計は３であ
り、１．５Ｍｂｐｓの帯域より使用しておらず、２０Ｍ
ｂｐｓ以下であるので、未だ周波数帯域の使用には問題
がない。

【００７１】 今回の配信要求元ユーザのＩＰアドレ
ス（例えば１０．１．１．３）の使用帯域数は０となっ
ており、各ユーザ毎に上限値２Ｍｂｐｓ以下となってい
るので、何ら問題なく空き帯域を使用できる（図３のＳ
１３）。

【００７２】 ポリシーサーバ１３は、以上述べた２
つのデータベース１６，１７の参照結果に基づき、配信
サーバ１２に対し、今回ユーザＩＰＢ５１の配信要求に
対する配信は可能であると回答する（図３のＳ１４）。

【００７３】従って、以上のようなポリシーサーバ１３
の実施の形態によれば、リソース管理データベース１６
および周波数管理データベース１７の格納データを参照
し、リソース確保および使用帯域確保を適切に判断で
き、配信サーバ１２にコンテンツの配信に必要な適切な
回答を提供できる。

【００７４】（６） ＣＭＴＳ３１にリソース管理デー
タベース３２及び周波数管理データベース１７を備えた
場合の構成および動作処理例について。

【００７５】前述するシステム例は、ポリシーサーバ１
３によってリソース管理を一元管理する場合の構成例を
述べたが、この例では、図６に示すように各ＣＭＴＳ３
１にデータベース３２，３３を備えた構成となる。つま
り、各ＣＭＴＳ３１から下流のリソース及び周波数帯域
の管理については、個々のＣＭＴＳ３１が管理するデー
タベース３２，３３に必要な情報を格納し管理する例で
ある。なお、これらデータベース３２，３３には前述す
るリソース管理データベース１６及び周波数管理データ
ベース１７と同様な構成データを格納するものであり、
とりわけ本発明の説明上必要な図４，図５と同様なデー
タを格納するものとする。

【００７６】次に、データベース３２，３３を備えたＣ
ＭＴＳ３１を含むシステムの動作について図７及び図８
を参照して説明する。

【００７７】先ず、ＣＭＴＳ３１は、動作を開始する
と、ＱｏＳを実現する為、使用帯域等の情報やＲＦケー
ブル４０の周波数帯域等の情報を管理するための初期化
を実行する（Ｓ２１：初期化ステップ）。

【００７８】この状態においてユーザがＩＰＢ５１を起
動し、ＥＰＧメニューの要求操作を行うと、自身のＩＰ
アドレス等の要求元情報のもとに画面要求情報がＣＭＴ
Ｓ３１、ネットワーク２０を経由し、ナビゲーションサ
ーバ１１に送られる（Ｓ２２）。ここで、ナビゲーショ
ンサーバ１１は、ある特定のユーザの要求元情報を所有
するＩＰＢ５１に配信する（Ｓ２３）。このＥＰＧメニ
ュー画面はユーザ端末５２に表示される。ユーザはメニ
ュー画面からジャンル毎（アクション、ドラマ）のボタ
ンやシステムプロバイダーが推奨するコンテンツ等を見
ることができる。

【００７９】ここで、ユーザがユーザ端末５２に表示さ
れるメニュー画面から特定の映像等マルチメディアコン
テンツを指定すると、該当ＩＰＢ５１から自身の例えば
ＩＰアドレス等の要求元情報のもとに映像コンテンツ視
聴要求が送信される。ヘッドエンドシステム１０のナビ
ゲーションサーバ１１は、ユーザ端末側からＣＭＴＳ３
１、ネットワーク２０を介して送られてくる要求元情
報、映像コンテンツ視聴要求を受信し、視聴要求のあっ
たコンテンツを受付ける（Ｓ２４）。これらＳ２２〜Ｓ
２４はコンテンツ要求受付けステップに相当する。

【００８０】このナビゲーションサーバ１１は、ユーザ
によって指定された映像等のコンテンツの視聴要求を受
信した後、配信サーバ１２に通知する（Ｓ２５）。

【００８１】この配信サーバ１２は、自身が管理する配
信情報データベース１５から要求元情報をもとに、経路
情報、コンテンツの配信に必要な帯域情報、配信必要時
間情報等を読み出し、要求元（送信先）情報とともに、
ポリシーサーバ１３に送信する（Ｓ２６）。

【００８２】このポリシーサーバ１３は、要求元情報、
経路情報、当該コンテンツの配信に必要な帯域情報、配
信必要時間情報を受け取ると、これら要求元情報および
必要帯域情報（例えば５００ｋｂｐｓ等）、配信必要時
間情報等を要求元側ネットワーク経路に存在するＣＭＴ
Ｓ３１を通知しサービスを要求する（Ｓ２７）。

【００８３】ここで、ＣＭＴＳ３１は、要求元情報をも
とにインタフェース名を取得し（Ｓ２８）、このインタ
フェース名に基づいてリソースデータベース３２に格納
される情報を参照し、該当インタフェース名にＱｏＳの
観点から５００ｋｂｐｓの帯域確保が可能なリソースが
存在するか否かを判断する（Ｓ２９）。帯域確保可能な
リソースが存在しない場合、ＣＭＴＳ３１は、ポリシー
サーバ１３に配信不可能と回答する。このとき、予想使
用時間情報をもとに配信可能時間も回答する（Ｓ３
０）。

【００８４】ＣＭＴＳ３１は、ステップＳ２９において
ＱｏＳ確保可能にリソースが存在すると判断した場合、
図４に示すようにリソース管理データベース３２に規定
される項目のうち、例えば帯域番号特定、当該帯域番号
対応使用帯域への「１」設定、使用開始時間の書込み等
のなどの帯域使用情報を更新する（Ｓ３１）。これらス
テップＳ２８〜Ｓ３１はリソース確保判断ステップに相
当する。

【００８５】さらに、ＣＭＴＳ３１は、要求元情報およ
び必要帯域情報をもとに、図４に示す周波数管理データ
ベース３３を参照し、該当インタフェースに５００ｋｂ
ｐｓ帯域の空きがあるか否かを判断する（Ｓ３２）。こ
こで、帯域に空きがない場合にはリソース無しをポリシ
ーサーバ１３に回答するが、同時に予想使用時間情報を
もとに配信可能時間も回答する。また、前述したステッ
プＳ３１により確保したリソースを開放するために、リ
ソース管理データベース３２をアップデートする（Ｓ３
３）。

【００８６】一方、ＣＭＴＳ３１は、ステップＳ３２で
該当インタフェースに空き帯域周波数があると判断され
た場合、要求元ユーザのコンテンツ配信要求がサービス
の上限値を越えているか否かを判断し（Ｓ３４）、越え
ていないと判断された場合にはポリシーサーバ１３に配
信可能であることを回答するとともに、その帯域の利用
分について周波数管理データベース３３を更新する（Ｓ
３５）。これらステップＳ３２〜Ｓ３５は帯域確保判断
ステップに相当する。

【００８７】ここで、ポリシーサーバ１３は、配信サー
バ１２に配信可能を回答する（Ｓ３６）。この配信サー
バ１２は、ポリシーサーバ１３から配信可能とする回答
を受けると、ＲＳＶＰ等のプロトコルを用いて、ＣＭＴ
Ｓ３１を含むネットワーク中継関連装置の実際の使用帯
域をチェックし、使用するリソースを確保する（Ｓ３
７）。

【００８８】つまり、配信サーバ１２からｐａｔｈメッ
セージを送信し、ルータ１４、ＣＭＴＳ３１の順序で順
次チェックしながら、コンテンツ配信要求元であるＩＰ
Ｂ５１まで到達する。このＩＰＢ５１は、エラーなしで
ｐａｔｈメッセージを受信すると、ｒｅｓｖメッセージ
を配信サーバ１２に向けて送信する。

【００８９】配信サーバ１２は、ｒｅｓｖメッセージを
受けると、予約したネットワーク中継関連装置のリソー
スとＲＦケーブル４０の周波数帯を利用し、実際の映像
等コンテンツを配信要求元のＩＰＢ５１に送信する（Ｓ
３８：コンテンツ配信ステップ）。配信サーバ１２は、
コンテンツの配信を終了すると、ポリシーサーバ１３を
介してＣＭＴＳ３１に送信終了情報を送信する（Ｓ３
９）。このＣＭＴＳ３１は、両管理データベース３２，
３３の該当コンテンツ配信のために利用した帯域分の情
報について開放する（Ｓ４０）。

【００９０】従って、以上のようなネットワーク中継装
置であるＣＭＴＳ３１の一実施の形態によれば、当該Ｃ
ＭＴＳ３１にポリシーサーバ１３と同様な情報を有する
リソース管理データベース３２および周波数管理データ
ベース３３を備えることにより、ＣＭＴＳ３１がこれら
データベース３２，３３の内容を参照し、ポリシーサー
バ１３と同様な機能ないし作用効果を奏することができ
る。

【００９１】なお、上記実施の形態は、ＱｏＳの実現の
ためにリソース管理データベース１６、周波数管理デー
タベース１７を設けたが、何れか一方のデータベース１
６または１７を設け、リソースまたは周波数の観点から
ＱｏＳを実現するようにしてもよい。

【００９２】また、実施の形態では、ＣＭＴＳ３１側に
両管理データベース３２，３３を設けたが、例えばＣＭ
ＴＳ３１側に何れか一方の管理データベース３２または
３３を設けてもよく、この場合には他方の管理データベ
ース３３または３２はポリシーサーバ１３側に設置す
る。

【００９３】さらに、ＣＭＴＳ３１側に両管理データベ
ース３２，３３を設けた場合、システムからポリシーサ
ーバ１３を削除する構成としてもよい。

【００９４】その他、本願発明は、上記実施の形態に限
定されるものでなく、その要旨を逸脱しない範囲で種々
変形して実施できる。また、各実施の形態は可能な限り
組み合わせて実施することが可能であり、その場合には
組み合わせによる効果が得られる。さらに、上記各実施
の形態には種々の上位，下位段階の発明が含まれてお
り、開示された複数の構成要素の適宜な組み合わせによ
り種々の発明が抽出され得るものである。例えば問題点
を解決するための手段に記載される全構成要件から幾つ
かの構成要件が省略されうることで発明が抽出された場
合には、その抽出された発明を実施する場合には省略部
分が周知慣用技術で適宜補われるものである。

【００９５】

【発明の効果】以上説明したように本発明によれば、ユ
ーザからコンテンツの視聴要求に対し、ネットワークの
資源の使用状況をチェックし、ＱＯＳを確保しつつネッ
トワーク資源を有効に活用し、視聴要求コンテンツを適
切に配信できるＩＰストリーミングシステム、ポリシー
サーバ、ネットワーク中継装置及びＩＰストリーミング
配信方法を提供できる。

【図面の簡単な説明】

【図１】 本発明に係わるＩＰストリーミングシステム
の一実施の形態を示す系統構成図。

【図２】 図１に示すシステムの動作及び本発明に係わ
るＩＰストリーミング配信方法の一実施の形態を説明す
るフローチャート。

【図３】 図１に示すシステムの動作及び本発明に係わ
るＩＰストリーミング配信方法の一実施の形態を説明す
る図２に続くフローチャート。

【図４】 図１に示すリソース管理データベースのデー
タ構成の一例を示す図。

【図５】 図１に示す周波数管理データベースのデータ
構成の一例を示す図。

【図６】 本発明に係わるＩＰストリーミングシステム
の他の実施形態を示す系統構成図。

【図７】 図６に示すシステムの動作及び本発明に係わ
るＩＰストリーミング配信方法の一実施の形態を説明す
るフローチャート。

【図８】 図６に示すシステムの動作及び本発明に係わ
るＩＰストリーミング配信方法の一実施の形態を説明す
る図７に続くフローチャート。

【符号の説明】

１０…ヘッドエンドシステム １１…ナビゲーションサーバ １２…配信サーバ １３…ポリシーサーバ １６…リソース管理データベース １７…周波数管理データベース ２０…ネットワーク ３０…ディストリビューションＨＵＢ ３１…ＣＭＴＳ（ネットワーク中継装置） ３２…リソース管理データベース ３３…周波数管理データベース ４０…ＲＦケーブル ５１…ＩＰＢ ５２…ユーザ端末

Claims (6)

【特許請求の範囲】
1. 【請求項１】 コンテンツの視聴要求を行う複数のユー
   ザ端末とこの複数のユーザ端末がケーブルを介して接続
   されたＣＭＴＳとを持ち、前記ユーザ端末からの前記視
   聴要求に基づいて前記視聴要求されたコンテンツを前記
   ユーザ端末にネットワークを介して配信するＩＰストリ
   ーミングであって、 前記ユーザ端末側から前記視聴要求にともない送信され
   てくる要求元情報及び視聴要求されたコンテンツの種類
   を受理するナビゲーションサーバと、このナビゲーショ
   ンサーバから要求元情報、視聴要求コンテンツの通知を
   受けると、当該コンテンツを配信するためのＱｏＳが確
   保可能か否かの問い合わせを送出する配信サーバと、こ
   の配信サーバからのＱｏＳ確保の問い合わせを受けた場
   合、前記コンテンツを配信するネットワーク経路に存在
   する前記ＣＭＴＳを含むネットワーク中継関連装置のリ
   ソースの利用状況および前記ユーザ端末が接続される前
   記ケーブルの周波数帯域の使用状況に基づいてＱｏＳの
   可否を前記配信サーバに通知するポリシーサーバとを備
   えたことを特徴とするＩＰストリーミングシステム。
2. 【請求項２】 コンテンツの視聴要求を行う複数のユー
   ザ端末とこの複数のユーザ端末がケーブルを介して接続
   されたＣＭＴＳとを持ち、前記ユーザ端末からの前記視
   聴要求に基づいて前記視聴要求されたコンテンツを前記
   ユーザ端末にネットワークを介して配信するＩＰストリ
   ーミングであって、 前記ユーザ端末から視聴要求にともない送信されてくる
   要求元情報及び視聴要求されたコンテンツの種類を受理
   するナビゲーションサーバと、このナビゲーションサー
   バから要求元情報、視聴要求コンテンツの通知を受ける
   と、当該コンテンツを配信するためのＱｏＳが確保可能
   か否かの問い合わせを送出する配信サーバとを設け、 前記ＣＭＴＳは、ＱｏＳが確保可能か否かの問い合わせ
   を受けた場合、前記コンテンツを配信するネットワーク
   経路に存在する前記ＣＭＴＳを含むネットワーク中継関
   連装置のリソースの利用状況および前記ユーザ端末が接
   続される前記ケーブルの周波数帯域の使用状況に基づい
   てＱｏＳの可否を前記配信サーバに通知する手段を設け
   たことを特徴とするＩＰストリーミングシステム。
3. 【請求項３】 各ユーザ端末からのコンテンツ視聴要求
   に基づいて視聴要求のあったコンテンツを配信するＩＰ
   ストリーミングシステムにおいて、 前記各ユーザ端末までのネットワーク経路に存在するリ
   ソースの状況を記憶するリソース管理記憶手段と、 前記システム全体の周波数帯域の使用状況を記憶する周
   波数管理記憶手段と、 前記ユーザ端末からのコンテンツ視聴要求のもとに、外
   部から要求元情報、必要帯域を受けると、前記リソース
   管理記憶手段を参照し、前記視聴要求コンテンツに関す
   るＱｏＳ確保のためのリソース有無を判断する第１の判
   断手段と、 前記外部から要求元情報、必要帯域情報を受けると、前
   記周波数管理記憶手段を参照し、視聴要求のあった前記
   ユーザ端末が接続されるケーブルにおける周波数帯域の
   空き有無を判断する第２の判断手段と、 を備えたことを特徴とするポリシーサーバ。
4. 【請求項４】 各ユーザ端末からのコンテンツ視聴要求
   に基づいて視聴要求のあったコンテンツを配信するＩＰ
   ストリーミングシステムにおいて、 前記各ユーザ端末までのネットワーク経路に存在するリ
   ソースおよび前記システム全体の周波数帯域の何れか一
   方の使用状況を記憶する管理記憶手段と、 前記ユーザ端末からのコンテンツ視聴要求に基づいて要
   求元情報、必要帯域情報を受けると、前記管理記憶手段
   を参照し、前記視聴要求コンテンツに関するＱｏＳ確保
   のためのリソースの有無および視聴要求のあった前記ユ
   ーザ端末が接続されるケーブルにおける周波数帯域の空
   き有無の何れか一方を判断する手段とを備えたことを特
   徴とするポリシーサーバ。
5. 【請求項５】 各ユーザ端末からのコンテンツ視聴要求
   に対し、当該視聴要求コンテンツのストリーミング配信
   を実行するヘッドエンドシステムにネットワークを介し
   て接続され、当該ヘッドエンドシステムから要求元情
   報、必要帯域情報のもとにＱｏＳ確保可能か否かの問い
   合わせを受ける前記視聴要求のあったユーザ端末が接続
   されるケーブルを収容するネットワーク中継装置におい
   て、 前記各ユーザ端末までのネットワーク経路に存在するリ
   ソースおよび周波数帯域の何れか一方または両方を管理
   する管理記憶手段と、 前記ＱｏＳ確保可能か否かの問い合わせを受けた場合、
   前記要求元情報、必要帯域情報のもとに前記管理記憶手
   段を参照し、前記視聴要求コンテンツに関するＱｏＳ確
   保のためのリソース有無および前記ユーザ端末に接続さ
   れるラインにおける周波数帯域の空き有無の何れか一方
   又は両方を判断する手段とを備えたことを特徴とするネ
   ットワーク中継装置。
6. 【請求項６】 コンテンツの視聴要求を行う複数のユー
   ザ端末とこの複数のユーザ端末がケーブルを介して接続
   されたＣＭＴＳを持ち、前記ユーザ端末からの前記視聴
   要求に基づいて前記視聴要求されたコンテンツを前記ユ
   ーザ端末にネットワークを介して配信するＩＰストリー
   ミングシステムにおいて、 あるユーザ端末から要求元情報のもとにメニュー画面要
   求を受けた場合、当該ユーザ端末にメニュー画面を送信
   し、当該ユーザ端末から視聴要求コンテンツを受け付け
   るコンテンツ要求受付けステップと、 このステップにより視聴要求コンテンツを受付けると、
   予め記憶される配信要求コンテンツ、当該コンテンツの
   配信に必要な帯域情報、配信必要時間情報を読み出し、
   ＱｏＳ確保可能かを問い合わせる問合せステップと、 この問い合わせに基づいて予め記憶された前記要求元ユ
   ーザ端末までのネットワーク経路に存在するリソース情
   報を参照し、前記視聴要求コンテンツに関するＱｏＳ確
   保のためのリソース有無を判断するリソース確保判断ス
   テップと、 前記問合せに基づいてシステム全体の周波数帯域の使用
   状況を記憶する周波数管理記憶手段を参照し、前記ユー
   ザ端末が接続されたケーブルにおける周波数帯域の空き
   有無を判断する帯域確保判断ステップと、 前記各判断ステップによりＱｏＳ確保可能と判断された
   とき、前記視聴要求コンテンツを前記要求元ユーザ端末
   に配信するステップとを有することを特徴とするＩＰス
   トリーミング配信方法。