JP2004289627A - ストリーミングコンテンツ配信要求受付制御システム - Google Patents
ストリーミングコンテンツ配信要求受付制御システム Download PDFInfo
- Publication number
- JP2004289627A JP2004289627A JP2003080743A JP2003080743A JP2004289627A JP 2004289627 A JP2004289627 A JP 2004289627A JP 2003080743 A JP2003080743 A JP 2003080743A JP 2003080743 A JP2003080743 A JP 2003080743A JP 2004289627 A JP2004289627 A JP 2004289627A
- Authority
- JP
- Japan
- Prior art keywords
- server
- distribution
- streaming content
- request
- bandwidth
- 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.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
【課題】ＱｏＳを保証したストリーミングコンテンツ配信サービスを提供する。
【解決手段】映像配信サーバ３ａ１から通信ネットワークＮＷ経由で配信可能なストリーミングコンテンツの配信要求がクライアント端末５ａ１から通信ネットワークＮＷを介して送信されてきた際に、そのストリーミングコンテンツ配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システム２５。映像配信サーバ３ａ１の現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視部２１と、通信ネットワークＮＷ上の複数の中継点に対応する複数のルータ１５ａ１〜１５ａ５、クライアント端末２ａ１および映像配信サーバ３ａ１の間の複数の通信経路Ｒ１〜Ｒ１１それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視部２２と、を備えている。
【選択図】 図２
【解決手段】映像配信サーバ３ａ１から通信ネットワークＮＷ経由で配信可能なストリーミングコンテンツの配信要求がクライアント端末５ａ１から通信ネットワークＮＷを介して送信されてきた際に、そのストリーミングコンテンツ配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システム２５。映像配信サーバ３ａ１の現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視部２１と、通信ネットワークＮＷ上の複数の中継点に対応する複数のルータ１５ａ１〜１５ａ５、クライアント端末２ａ１および映像配信サーバ３ａ１の間の複数の通信経路Ｒ１〜Ｒ１１それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視部２２と、を備えている。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアント端末から通信ネットワークを介して、映像コンテンツ、音楽コンテンツ等のストリーミング型コンテンツ（ダウンロードしながら再生できるコンテンツ；本明細書では、ストリーミングコンテンツと記載する）の配信要求が送信された際に、その配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システムに関する。
【０００２】
【従来の技術】
ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ：非同期転送モード）ネットワークのコネクション設定方式をモデルにして、静的に通信ネットワーク（以下、ＮＷとも記載する）の帯域を積上げて管理し、新しい呼の接続要求に対してＮＷの空き状況を考慮して帯域の割り当てを行い、品質を確保する方式が知られている（例えば、特許文献１参照）。
【０００３】
また、クライアントからＮＷの必要帯域、区間および利用帯域を含む帯域予約情報が指定された際に、Ｐｏｌｉｃｙサーバを用いてクライアントの帯域予約情報に対してネットワーク機器のプロビジョニング（事前準備）を行い、動的にネットワーク機器のコンフィグレーション（設定）を行う方式についても知られている（例えば、特許文献２参照）。
【０００４】
【特許文献１】
特開２００１−２５３０２１号公報
【０００５】
【特許文献２】
特開２００１−２２３７４１号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、上述した新しい呼の接続要求に対してＮＷの空き状況を考慮して帯域の割り当てを行う方式では、ＮＷのブローカ（クライアント端末とサーバとの間の仲介する）がネットワーク事業者の指定するＮＷの利用期間、区間および必要帯域等についてＮＷを貸し出すようなサービスにおいて帯域を割り当てる場合に有効である。
【０００７】
しかしながら、マスユーザ向けのビデオ・オン・デマンド型のストリーミングコンテンツ配信サービスでは、任意の時間に各ユーザのクライアント端末からアクセスされるため、クライアント端末のＮＷの利用期間を予め予測することは不可能である。
【０００８】
すなわち、上記ストリーミングコンテンツ配信サービスに対して従来の帯域割当方式を用いた場合においては、クライアントのアクセス毎に必要帯域を確保して通信品質｛ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）：サービスの質を表す指標｝を保証することが非常に困難であった。
【０００９】
また、上述したクライアントからの帯域予約情報に基づいてネットワーク機器のプロビジョニングを行って帯域を割り当てる方式においては、コンテンツ配信サービスのＱｏＳをＮＷリソースの観点のみから捉えており、コンテンツ配信元のサーバのリソースを考慮していないため、ＱｏＳを保証した配信サービスを提供しているとはいえなかった。
【００１０】
本発明は、上述した事情に鑑みてなされたものであり、ＱｏＳを保証したストリーミングコンテンツ配信サービスを提供できるストリーミングコンテンツ配信要求受付制御システムを提供することをその目的とする。
【００１１】
【課題を解決するための手段】
上述した目的を達成するため、本発明は、請求項１に記載したように、配信サーバから通信ネットワーク経由で配信可能なストリーミングコンテンツの配信要求がクライアント端末から当該通信ネットワークを介して送信されてきた際に、そのストリーミングコンテンツ配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システムであって、前記配信サーバの現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視手段と、前記通信ネットワーク上の複数の中継点、前記クライアント端末および前記配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視手段と、備えたことを特徴とする。
【００１２】
特に、請求項２に記載された発明においては、前記サーバリソース監視手段は、監視した前記配信サーバの帯域リソース情報を当該配信サーバの識別情報に関連付けて管理する配信サーバリソース管理手段を備え、前記ネットワークリソース監視手段は、監視した前記複数の通信経路それぞれのネットワークリソース情報を当該複数の通信経路それぞれの経路識別情報に関連付けて管理するネットワークリソース管理手段を備えたことを特徴とする。
【００１３】
また、請求項３に記載された発明においては、前記通信ネットワーク上における前記配信サーバおよび前記配信要求送信元のクライアント端末間の最適ルートとして設定された複数の通信経路それぞれの経路識別情報を前記配信サーバおよびクライアント端末に関連付けて記憶する経路管理手段を備えたことを特徴とする。
【００１４】
さらに、請求項４に記載された発明においては、前記クライアント端末から送信されてきた配信要求に対応するストリーミングコンテンツの必要帯域、前記配信サーバの帯域リソース情報、前記複数の通信経路それぞれのネットワークリソース情報および前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報に基づいて、当該配信要求を受け付けるか否かを判断する受付可否判断手段をさらに備えたことを特徴とする。
【００１５】
そして、請求項５に記載された発明においては、前記受付可否判断手段は、前記配信サーバの帯域リソース情報から当該配信サーバの使用可能帯域を把握し、把握した使用可能帯域と前記受信した配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第１の比較判断手段を備えたことを特徴とする。
【００１６】
特に、請求項６に記載された発明においては、前記受付可否判断手段は、前記第１の比較判断手段により前記配信要求が受付可能であると判断された際に、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報および前記複数の通信経路それぞれのネットワークリソース情報から当該パスを構成する複数の通信経路それぞれの使用可能帯域を把握し、把握したそれぞれの使用可能帯域と前記配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第２の比較判断手段をさらに備えたことを特徴とする。
【００１７】
さらに、請求項７に記載された発明においては、前記受付可否判断手段により前記配信要求が受付られた場合において、当該配信要求に対応するクライアント端末の識別情報、前記配信サーバの識別情報、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報、当該配信要求に対応するストリーミングコンテンツの必要帯域および当該ストリーミングコンテンツの再生時間を互いに関連付けて当該クライアント端末のセッション情報として記憶するセッション情報記憶手段をさらに備えたことを特徴とする。
【００１８】
そして、請求項８に記載された発明においては、前記受付可否判断手段により前記配信要求が受付られた場合において、前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの再生要求コマンドを受信し、受信した再生要求コマンドを中継して前記配信サーバに送信する第１の中継手段と、前記ストリーミングコンテンツの再生要求コマンドの受信に応じて、当該ストリーミングコンテンツの視聴開始時刻を表す視聴開始時刻情報を前記セッション情報に関連付けて記録する視聴開始時刻記録手段と、前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの終了要求コマンドを受信し、受信した終了要求コマンドを中継して前記配信サーバに送信する第２の中継手段と、前記ストリーミングコンテンツの終了要求コマンドの受信に応じて、前記セッション情報を削除するセッション情報削除手段と、をさらに備えたことを特徴とする。
【００１９】
【発明の実施の形態】
図１は、本発明の実施の形態に係わるストリーミングコンテンツ配信要求受付制御システムを含むストリーミングコンテンツ配信システム１の概略構成を示す図である。
【００２０】
図１に示すように、ストリーミングコンテンツ配信システム１は、ダウンロード型コンテンツ（パケット）の通信用プロトコルである例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；パケット配信管理用プロトコル）に加えて、ストリーミングコンテンツ配信用プロトコルであるＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ；ストリーミングコンテンツのデータ送受信単位であるＲＴＰパケット管理用プロトコル）、ＲＴＳＰ（Ｒｅａｌｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ；ストリーミングコンテンツ再生、静止等の制御用プロトコル）等｝に基づいてＷＷＷコンテンツ、ストリーミングコンテンツを中継可能なインターネット等の通信ネットワークＮＷを備えている。
【００２１】
また、ストリーミングコンテンツ配信システム１は、例えば分散配置され、通信ネットワークＮＷを経由したＲＴＳＰコマンドを監視する機能およびＲＴＳＰコマンドを中継する機能をそれぞれ有する複数のＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・（図１においては、２つのＲＴＳＰプロキシサーバ２ａ１、２ａ２のみ示す）を備えている。
【００２２】
さらに、ストリーミングコンテンツ配信システム１は、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・に通信可能にそれぞれ設けられ、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・により中継されたＲＴＳＰコマンドに応じてストリーミングコンテンツである例えば映像コンテンツを、通信ネットワークＮＷとの接続が確立された複数のクライアント端末（以下、クライアントと略記する）５ａ１、５ａ２、・・・（図１においては、２つのクライアント５ａ１、５ａ２のみ示す）に対して配信可能な映像配信サーバ３ａ１、３ａ２、・・・（図１においては、２つの映像配信サーバ３ａ１、３ａ２のみ示す）を備えている。
【００２３】
各ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・は、少なくとも１台のコンピュータ（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）から構成されており、そのメモリには、上記ＴＣＰ等の通信プロトコルが実装されている。同様に、各映像配信サーバ３ａ１、３ａ２、・・・は、少なくとも１台のコンピュータ（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）から構成されており、そのメモリには、上記ＲＴＰ、ＲＴＳＰ等のストリーミングコンテンツ配信用プロトコルが実装されている。
【００２４】
そして、ＲＴＳＰプロキシサーバ２ａ１および映像配信サーバ３ａ１が配置されているロケーションには、そのロケーションを識別するためのエッジ番号Ｅ１が設定されており、ＲＴＳＰプロキシサーバ２ａ１および映像配信サーバ３ａ１は、Ｅ１エッジのロケーションに分散配置されている。
【００２５】
同様に、ＲＴＳＰプロキシサーバ２ａ２および映像配信サーバ３ａ２は、Ｅ２エッジのロケーションに分散配置されている。なお、本実施形態においては、以下、２つのＲＴＳＰプロキシサーバ２ａ１、２ａ２および２つの映像配信サーバ３ａ１、３ａ２が配置されている場合について説明する。
【００２６】
また、各クライアント５ａ１および５ａ２（以下、クライアントがこの２つのクライアント５ａ１、５ａ２であるものとする）は、パーソナルコンピュータや携帯端末（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）等から構成されている。
【００２７】
さらに、各クライアント５ａ１および５ａ２のメモリには、ＷＷＷコンテンツをディスプレイを介して表示（閲覧）する手段、および上記ＷＷＷコンテンツ上において入力部を介して入力されたイベントを後述するＷＷＷポータルサーバ７に送信する手段としてのＷＷＷブラウザ（ソフトウェア）Ｂが実装されている。
【００２８】
各クライアント５ａ１および５ａ２のメモリには、上記ストリーミングコンテンツをディスプレイ、スピーカ等を介して再生する手段としてのソフトウェアであるプレーヤＰが実装されている。
【００２９】
そして、各クライアント５ａ１および５ａ２は、例えばＬＡＮ等のサブネットワークＳｂ１およびＳｂ２に属しており、このサブネットワークＳｂ１およびＳｂ２が通信ネットワークＮＷに対して通信可能になっている。なお、サブネットワークＳｂ１の識別情報である識別番号（以下、サブネット番号と記載する）を”ＳＢ１”とし、サブネットワークＳｂ２のサブネット番号を”Ｓｂ２”とする。
【００３０】
そして、ストリーミングコンテンツ配信システム１は、複数のクライアント５ａ１、５ａ２それぞれに対して、そのクライアント５ａ１、５ａ２それぞれにより閲覧（ブラウズ）でき、かつ映像コンテンツ再生等を要求可能なＷＷＷコンテンツとして、上記映像配信サーバ３ａ１、３ａ２により配信可能な複数の映像コンテンツのリストの表示および所望の映像コンテンツの視聴（再生）要求を入力できる映像コンテンツ視聴用ＷＷＷコンテンツを提供するためのＷＷＷポータルサーバ（少なくとも１つのコンピュータから構成されている）７を備えている。このＷＷＷポータルサーバ７は、そのメモリに格納されたＷＷＷサーバ（ソフトウェア）に従って動作するようになっている。
【００３１】
さらに、ストリーミングコンテンツ配信システム１は、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、映像配信サーバ３ａ１、３ａ２、ＷＷＷポータルサーバ７および通信ネットワークＮＷにそれぞれ通信可能であり、通信ネットワークＮＷおよび各映像配信サーバ３ａ１、３ａ２のリソースをリアルタイムに監視して該監視結果であるリソース情報をリアルタイムで更新しながら統合的に管理し、この管理内容に基づいて、各クライアント５ａ１、５ａ２から送信された映像コンテンツ視聴要求（配信要求）に対する受付制御するための受付制御サーバ１０と、この受付制御サーバ１０がアクセス可能であり、上記リソース情報等を格納するためのリソースデータベース（ＤＢ）１１とを備えている。
【００３２】
さらに、通信ネットワークＮＷ上の複数の中継点には、通信ネットワークＮＷ経由のデータをルーティングするための複数のルータ１５ａ１〜１５ａｎ（本実施形態では、説明を容易にするため、ｎ＝５とする）がそれぞれ設置されている。
【００３３】
複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ１は、クライアント５ａ１が属するサブネットＳｂ１に対する中継点に設置されており、このルータ１５ａ１およびクライアント５ａ１間の経路を経路Ｒ１とする。
【００３４】
また、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ２は、クライアント５ａ２が属するサブネットＳｂ２に対する中継点に設置されており、このルータ１５ａ２およびクライアント５ａ２間の経路を経路Ｒ２とする。
【００３５】
同様に、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ３は、映像配信サーバ３ａ１に対する中継点に設置されており、このルータ１５ａ３および映像配信サーバ３ａ１間の経路を経路Ｒ１０とする。
【００３６】
また、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ４は、映像配信サーバ３ａ２に対する中継地点に設置されており、このルータ１５ａ４および映像配信サーバ３ａ２間の経路を経路Ｒ１１とする。
【００３７】
さらに、ルータ１５ａ１およびルータ１５ａ３間には、そのルータ１５ａ１およびルータ１５ａ３間のデータ通信を中継するルータ１５ａ５が設置されている。
【００３８】
ここで、ルータ１５ａ１およびルータ１５ａ２間の経路を経路Ｒ３、ルータ１５ａ１およびルータ１５ａ５間の経路を経路Ｒ４、ルータ１５ａ２よびルータ１５ａ５間の経路を経路Ｒ５、ルータ１５ａ２およびルータ１５ａ４間の経路を経路Ｒ６、ルータ１５ａ４およびルータ１５ａ５間の経路を経路Ｒ７、ルータ１５ａ３およびルータ１５ａ５間の経路を経路Ｒ８およびルータ１５ａ３およびルータ１５ａ４間の経路を経路Ｒ９とする。
【００３９】
受付制御サーバ１０は、図２に示すように、各映像配信サーバ３ａ１、３ａ２の現在の使用可能帯域｛各サーバの最大帯域（映像コンテンツの品質を確保して配信できる最大の通信帯域を表す）から実際に使用している通信帯域（使用帯域とする）を減算した帯域に相当し、映像コンテンツの配信に使用できる帯域を表す｝に関連するサーバリソースとして、上記各映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域をそれぞれ監視するためのサーバリソース監視部２１と、上記複数の通信経路Ｒ１〜Ｒ１１それぞれの現在の使用可能帯域｛各通信経路の最大帯域（映像コンテンツの品質を確保して配信できる最大の通信帯域を表す）から実際に使用している通信帯域（使用帯域とする）を減算した帯域に相当し、映像コンテンツの配信に使用できる帯域を表す｝に関連するネットワークリソースとして、上記各通信経路Ｒ１〜Ｒ１１の最大帯域および使用帯域をそれぞれ監視するためのネットワークリソース監視部２２とを備えている。なお、サーバリソース監視部２１およびネットワークリソース監視部２２は、受付制御サーバ１０のメモリに格納された監視用プログラムに基づく受付制御サーバ１０の機能として具体化される。
【００４０】
また、本実施の形態では、受付制御サーバ１０および各ＲＴＳＰプロキシサーバ２ａ１、２ａ２によりストリーミングコンテンツ配信要求受付制御システム２５を構成している。
【００４１】
リソースＤＢ１１は、図２に示すように、クライアント管理テーブルＴ１、サーバリソース管理テーブルＴ２、コンテンツ管理テーブルＴ３、経路管理テーブルＴ４、経路リソース管理テーブルＴ５およびセッション管理テーブルＴ６を有している。
【００４２】
クライアント管理テーブルＴ１には、図３に示すように、各クライアント５ａ１、５ａ２、・・・の通信ネットワークＮＷ経由の通信場所（宛先）を表すアドレスとしてのＩＰアドレスと、各クライアント５ａ１、５ａ２、・・・が属するサブネットのサブネット番号（例えば、クライアント５ａ１→サブネット番号Ｓｂ１、クライアント５ａ２→サブネット番号Ｓｂ２）と、各クライアント５ａ１、５ａ２、・・・が属するサブネットに対して最寄のエッジを示すエッジ番号（例えば、サブネットＳｂ２→エッジ番号Ｅ２、サブネットＳｂ１→エッジ番号Ｅ１）とがクライアント毎に互いに関連付けられて記憶されている。
【００４３】
また、サーバリソース管理テーブルＴ２には、図４に示すように、各映像配信サーバ３ａ１、３ａ２の識別情報であるサーバ番号と、各映像配信サーバ３ａ１、３ａ２が属するエッジを示すエッジ番号と、各映像配信サーバ３ａ１、３ａ２の使用帯域と、各映像配信サーバ３ａ１、３ａ２の最大帯域と、各映像配信サーバ３ａ１、３ａ２と同一のエッジに属するＲＴＳＰプロキシサーバ２ａ１、２ａ２の通信ネットワークＮＷ経由の通信場所を表すアドレスとしてのＩＰアドレスと、各ＲＴＳＰプロキシサーバ２ａ１、２ａ２が複数の映像配信サーバに対してＲＴＳＰコマンドを中継する場合、それぞれの映像配信サーバを識別するためのポート番号とが映像配信サーバ毎に互いに関連付けられて記憶されている。
【００４４】
さらに、コンテンツ管理テーブルＴ３には、図５に示すように、映像配信サーバ３ａ１、３ａ２から配信可能な複数の映像コンテンツ（例えば、映像コンテンツＣ１、Ｃ２、Ｃ３とする）を識別するためのコンテンツ番号（映像コンテンツＣ１→コンテンツ番号Ｃ１、映像コンテンツＣ２→コンテンツ番号Ｃ２、映像コンテンツＣ３→コンテンツ番号Ｃ３）と、それぞれの映像コンテンツＣ１〜Ｃ３の配信に必要な必要帯域と、それぞれの映像コンテンツＣ１〜Ｃ３の保存場所を表す映像配信サーバのサーバ番号（映像コンテンツＣ１→映像配信サーバ３ａ１、映像コンテンツＣ２→映像配信サーバ３ａ１、映像コンテンツＣ３→映像配信サーバ３ａ２）と、それぞれの映像コンテンツＣ１〜Ｃ３の再生時間とが映像コンテンツ毎に互いに関連付けられて記憶されている。
【００４５】
そして、経路管理テーブルＴ４には、図６に示すように、各エッジ番号と、各サブネット番号と、各エッジ番号および各サブネット番号から決定された各エッジＥ１、Ｅ２および各サブネットＳｂ１、Ｓｂ２間の最適ルートとして設定された複数の経路を識別するための経路番号のグループ（例えば、エッジＥ１とサブネットＳｂ１との間の最適ルート→経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０、エッジＥ１とサブネットＳｂ２との間の最適ルート→経路Ｒ２、経路Ｒ６、経路Ｒ９、経路Ｒ１０、エッジＥ２とサブネットＳｂ１との間の最適ルート→経路Ｒ１、経路Ｒ３、経路Ｒ５、経路Ｒ７、経路Ｒ１１、エッジＥ２とサブネットＳｂ２との間の最適ルート→経路Ｒ２、経路Ｒ６、経路Ｒ１１）とがエッジ毎に互いに関連付けられて記憶されている。
【００４６】
また、経路リソース管理テーブルＴ５には、図７に示すように、各経路Ｒ１〜Ｒ１１の経路番号（経路番号Ｒ１〜Ｒ１１）と、各経路Ｒ１〜Ｒ１１の使用帯域と、各経路Ｒ１〜Ｒ１１の最大帯域とが経路毎に互いに関連付けられて記憶されている。
【００４７】
さらに、セッション管理テーブルＴ６には、図８に示すように、映像コンテンツを視聴（再生）しているクライアントのＩＰアドレスと、その映像コンテンツの配信元の映像配信サーバ３ａ１、３ａ２を表すサーバ番号と、映像配信サーバ３ａ１、３ａ２（対応するエッジ）から配信先のクライアント５ａ１、５ａ２に対して映像コンテンツを配信しているルート（最適ルート）を構成する複数の経路の経路番号と、上記映像コンテンツ配信において使用している使用帯域と、配信先クライアントによる映像コンテンツの視聴開始時刻と、その映像コンテンツの再生時間（視聴時間：映像コンテンツを最初から最後まで視聴するのに要する時間）とが映像コンテンツ視聴クライアント毎に互いに関連付けられて記憶されている。
【００４８】
一方、ＲＴＳＰプロキシサーバ２ａ１には、図２および図９に示すように、各映像配信サーバ３ａ１、３ａ２のサーバ番号とその各映像配信サーバ３ａ１、３ａ２に対応するＵＲＬとが互いに関連付けられたＵＲＬ変換テーブルＴ１０が設けられている。
【００４９】
次に、本実施形態に係わるストリーミングコンテンツ配信システム１の全体動作について、特に、ストリーミングコンテンツ配信要求受付制御システム２５の動作処理を中心に説明する。
【００５０】
ストリーミングコンテンツ配信要求受付制御システム２５の受付制御サーバ１０は、サーバリソース監視部２１に基づく処理により、通信ネットワークＮＷに対して通信可能な映像配信サーバ３ａ１、３ａ２の現在の使用帯域、最大帯域等のサーバリソース情報をリアルタイムで監視しており、その監視情報に基づいてサーバリソース管理テーブルＴ２を更新し、現在のサーバ３ａ１、３ａ２のサーバリソース情報をリアルタイムで把握している。
【００５１】
さらに、受付制御サーバ１０は、ネットワークリソース監視部２２に基づく処理により、通信ネットワークＮＷを経由した通信経路である通信経路Ｒ１〜Ｒ１１それぞれの現在の使用帯域および最大帯域等のネットワーク（ＮＷ）リソース情報をリアルタイムで監視しており、その監視情報に基づいて経路リソース管理テーブルＴ５を更新し、現在の通信ネットワークＮＷを経由した通信経路のリソース情報をリアルタイムで把握している。
【００５２】
また、クライアント５ａ１には、ＷＷＷポータルサーバ７から、映像コンテンツ視聴用ＷＷＷコンテンツがダウンロードされており、そのＷＷＷブラウザＢに基づくクライアント５ａ１の閲覧表示機能により、映像コンテンツ視聴用ＷＷＷコンテンツがディスプレイを介して表示されている。
【００５３】
このとき、クライアント５ａ１のユーザは、そのクライアント５ａ１にダウンロードされている映像コンテンツ視聴用ＷＷＷコンテンツにおける映像コンテンツリスト（複数の映像コンテンツＣ１、Ｃ２およびＣ３のリスト）を閲覧しながら、自分が見たい映像コンテンツを入力部を操作して選択（例えば、映像コンテンツＣ１を選択したとする）して、その選択映像コンテンツＣ１の配信要求のイベントをクライアント５ａ１に入力する。
【００５４】
クライアント５ａ１は、入力された映像コンテンツＣ１の配信要求（視聴要求）を通信ネットワークＮＷを介してＷＷＷポータルサーバ７に対して送信する（図２中、処理▲１▼参照）。
【００５５】
このとき、ＷＷＷポータルサーバ７は、クライアント５ａ１の処理▲１▼により送信されてきた映像コンテンツＣ１の視聴要求を受けると、ＷＷＷポータルサーバ７は、その視聴要求に対応する映像コンテンツＣ１のコンテンツ番号、および対応クライアント５ａ１のＩＰアドレスを受付制御サーバ１０に通知する。
【００５６】
受付制御サーバ１０は、図１０に示すように、ＷＷＷポータルサーバ７から送信されてきたデータに対応するイベントを受信し（ステップＳ１）、受信したイベントの送信元（受信イベントの相手）がＷＷＷポータルサーバ７かＲＴＳＰプロキシサーバ２ａ１、２ａ２か否か判断する（ステップＳ２）。
【００５７】
今、イベントの送信元（受信相手）がＷＷＷポータルサーバ７であるため、ステップＳ２の判断は図１０に示す”ＷＷＷポータルサーバの場合”となり、受付制御サーバ１０は、視聴要求の受付の可否判断処理を実行する（図２の処理▲２▼およびステップＳ３）。
【００５８】
すなわち、受付制御サーバ１０は、ステップＳ３の処理として、ＷＷＷポータルサーバ７から通知された視聴要求に対応する映像コンテンツＣ１のコンテンツ番号、および対応クライアント５ａ１のＩＰアドレスを受信し（図１１；ステップＳ１０）、受信したクライアントＩＰアドレスを検索キーとしてリソースＤＢ１１のクライアント管理テーブルＴ１を検索し、クライアントＩＰアドレスに対応するエッジ番号およびサブネット番号（クライアントが５ａ１の場合、エッジ番号Ｅ１およびサブネット番号Ｓｂ１）を含むクライアント情報を取得する（ステップＳ１１）。
【００５９】
次いで、受付制御サーバ１０は、受信したコンテンツ番号を検索キーとしてリソースＤＢ１１のコンテンツ管理テーブルＴ３を検索し、コンテンツ番号（Ｃ１）に対応する必要帯域、映像コンテンツＣ１の保存場所を表す映像配信サーバ（３ａ１）のサーバ番号および再生時間を含むコンテンツ情報を取得する（ステップＳ１２）。
【００６０】
さらに、受付制御サーバ１０は、取得した映像コンテンツＣ１の保存場所を表す映像配信サーバ３ａ１のサーバ番号を検索キーとしてリソースＤＢ１１のサーバリソース管理テーブルＴ２を検索し、サーバ番号（映像配信サーバ３ａ１）に対応する映像配信サーバ３ａ１の使用帯域、最大帯域、対応するＲＴＳＰプロキシサーバ（２ａ１）のＩＰアドレスおよびポート番号を含むサーバ情報を取得する（ステップＳ１３）。
【００６１】
続いて、受付制御サーバ１０は、ステップＳ１２の処理で取得した映像コンテンツＣ１の必要帯域と、ステップＳ１３の処理で取得した映像配信サーバ３ａ１の使用帯域および最大帯域とから、その必要帯域と使用帯域とを加算した値と最大帯域の値とを比較し（ステップＳ１４）、必要帯域および使用帯域の加算値が最大帯域を越える場合には（ステップＳ１４の判断の結果ＮＧ）、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１を配信するための空きリソースが映像配信サーバ３ａ１に無く、配信要求の受付ができない（ＮＧ）ことを表す情報（配信受付ＮＧ結果）をＷＷＷポータルサーバ７に通知する（ステップＳ１５）。
【００６２】
一方、必要帯域および使用帯域の加算値が最大帯域以下の場合には（ステップＳ１４の判断の結果ＯＫ）、受付制御サーバ１０は、取得したエッジ番号およびサブネット番号を検索キーとしてリソースＤＢ１１の経路管理テーブルＴ４を検索し、そのエッジ番号（エッジＥ１）およびサブネット番号（サブネット番号Ｓｂ１）に対応する経路番号（経路番号グループ）を取得し（エッジＥ１、サブネット番号Ｓｂ１の場合、経路Ｒ１、経路Ｒ４、経路Ｒ８および経路Ｒ１０）、その取得した経路番号グループに対応するルート（経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０）を、配信要求に対応する通信ネットワークＮＷを介した配信ルート（最適ルート）として決定する（ステップＳ１６）。
【００６３】
次いで、受付制御サーバ１０は、取得したそれぞれの経路番号を検索キーとしてリソースＤＢ１１の経路リソース管理テーブルＴ５を検索し、それぞれの経路番号の使用帯域および最大帯域を含むＮＷリソース情報を取得する（ステップＳ１７）。
【００６４】
続いて、受付制御サーバ１０は、ステップＳ１２の処理で取得した映像コンテンツＣ１の必要帯域と、ステップＳ１７の処理で取得した配信ルートを構成するそれぞれの経路の使用帯域および最大帯域とから、各経路の必要帯域とコンテンツＣ１使用帯域とを加算した値と各経路の最大帯域の値とを各経路毎に比較し（ステップＳ１８）、上記配信ルートを構成する各経路の内、１つでも上記加算値が最大帯域を超える経路が存在した場合には（ステップＳ１８の判断の結果ＮＧ）、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１を配信するための空きリソースが通信ネットワークＮＷに無く、配信要求の受付ができない（ＮＧ）ことを表す情報（配信受付ＮＧ）をＷＷＷポータルサーバ７に通知する（ステップＳ１５）。
【００６５】
一方、決定した配信ルートを構成する各経路の必要帯域とコンテンツＣ１使用帯域との加算値が対応する各経路の最大帯域以下の場合には（ステップＳ１８の判断の結果ＯＫ）、受付制御サーバ１０は、経路リソース管理テーブルＴ５における配信ルートを構成する各経路に対応する使用帯域に対して、今回の映像コンテンツＣ１の必要帯域を加算して経路リソース管理テーブルＴ５を更新して経路リソースを確保する（ステップＳ１９）。
【００６６】
次いで、受付制御サーバ１０は、サーバリソース管理テーブルＴ２における上記映像コンテンツＣ１配信元の映像配信サーバ３ａ１の使用帯域に対して、今回の映像コンテンツＣ１の必要帯域を加算してサーバリソース管理テーブルＴ２を更新してサーバリソースを確保する（ステップＳ２０）。
【００６７】
続いて、受付制御サーバ１０は、配信要求送信元のクライアント５ａ１のセッション情報として、そのクライアント５ａ１のクライアントＩＰアドレス、配信要求に対応する映像コンテンツＣ１の配信元である映像配信サーバ３ａ１のサーバ番号、その映像コンテンツＣ１の配信ルートに対応する各経路の経路番号、映像コンテンツＣ１の使用帯域およびその映像コンテンツＣ１の再生時間を互いに関連付けてセッション管理テーブルＴ６に追加登録する（ステップＳ２１）。
【００６８】
そして、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１の配信元である映像配信サーバ３ａ１に対応するＲＴＳＰプロキシサーバ２ａ１のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ；通信ネットワークＮＷを経由してＲＴＳＰプロキシサーバ２ａ１を指定する際のアドレス）をＷＷＷポータルサーバ７に通知して（ステップＳ２２）、処理を終了する。
【００６９】
ＷＷＷポータルサーバ７は、受付制御サーバ１０からＲＴＳＰプロキシサーバのＵＲＬが送信されてきた場合（ステップＳ２２参照）、受付可否判断がＯＫであると判断して、配信要求送信元のクライアント５ａ１に対してＲＴＳＰプロキシサーバのＵＲＬを返送する（図２；処理▲３▼参照）。
【００７０】
一方、受付制御サーバ１０からＮＧ結果通知が送信されてきた場合（ステップＳ１５参照）、受付可否判断がＮＧであると判断して、配信要求送信元のクライアント５ａ１に対して、現在、配信要求に対応する映像コンテンツＣ１が視聴できない（視聴ＮＧである）ことを通知して（図２；処理▲３▼参照）、クライアント５ａ１の配信要求を拒否する。
【００７１】
クライアント５ａ１は、受付制御サーバ１０からＲＴＳＰプロキシサーバ２ａ１のＵＲＬを受け取ると、プレーヤＰを起動し、このプレーヤＰに基づくクライアント５ａ１のＲＴＳＰコマンドとしてＲＴＳＰ再生要求コマンド（ＲＴＳＰに基づく映像コンテンツの再生要求メソッドを含むコマンド）を、そのＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対して送信する（図２；処理▲４▼参照）。
【００７２】
ＲＴＳＰプロキシサーバ２ａ１は、送信されてきたＲＴＳＰコマンドを受信し（図１２；ステップＳ３０）、そのＲＴＳＰコマンドからクライアント５ａ１のクライアントＩＰアドレスおよびメソッドを抽出し（ステップＳ３１）、抽出したメソッドに基づいてＲＴＳＰコマンドが再生要求、すなわち、再生開始を表す開始コマンドおよび終了要求、すなわち、再生終了を表す終了コマンドか否かを判断する（ステップＳ３２）。
【００７３】
今、ＲＴＳＰコマンドは、ＲＴＳＰに基づく映像コンテンツの再生要求メソッドを含むコマンドであるため、ステップＳ３２の判断の結果はＹＥＳとなり、ＲＴＳＰプロキシサーバ２ａ１は、対応するクライアント５ａ１のＩＰアドレスを含む視聴開始イベントを受付制御サーバ１０に送信する（ステップＳ３３および図２；処理▲６▼参照）。
【００７４】
受付制御サーバ１０は、送信されてきた視聴開始イベントを受信し（図１０；ステップＳ１参照）、このイベントの受信相手（送信元）はＲＴＳＰプロキシサーバ２ａ１であるため、ステップＳ２の判断の結果は”ＲＴＳＰプロキシサーバの場合”となり、受付制御サーバ１０は、受信したイベントが視聴開始イベントか視聴終了イベントかを判断する（図１０；ステップＳ４）。
【００７５】
今、送信されてきたイベントは視聴開始イベントであるため、ステップＳ４の判断の結果は”開始イベントの場合”となり、受付制御サーバ１０は、視聴開始通知処理を実行する（図１０；ステップＳ５）。
【００７６】
すなわち、受付制御サーバ１０は、受信した視聴開始イベントのクライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６から上記クライアントＩＰアドレスに対応するセッション情報を検索し（ステップＳ４０）、検索したセッション情報に対して現在時刻（視聴開始時刻）を追加して当該セッション情報を更新登録する（ステップＳ４１）。
【００７７】
すなわち、図８に示すように、クライアント５ａ１に対応するクライアントＩＰアドレス（１０．６．１．１／２４）に対応するサーバ番号（映像配信サーバ３ａ１）、経路番号（経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０）、使用帯域（６Ｍｂｐｓ）、再生時間（２時間）から構成されたセッション情報に対して視聴開始時刻（１８時４１分５０秒）が追加される。
【００７８】
一方、ステップＳ３４の処理において、ＲＴＳＰプロキシサーバ２ａ１は、ＲＴＳＰコマンドに含まれるＲＴＳＰプロキシサーバ２ａ１のＵＲＬの一部のサーバ番号を検索キーとしてＵＲＬ変換テーブルＴ１０を検索し、ＲＴＳＰプロキシサーバ２ａ１の配下の映像配信サーバ３ａ１のＵＲＬを取得し、そのＵＲＬの値を変換し、次いで、ＲＴＳＰコマンド（ＲＴＳＰ再生要求コマンド）のコンテンツ配信要求（Ｄｅｓｔｉｎａｔｉｏｎ）の値をクライアント５ａ１のＩＰアドレスの値に変換し、変換したＲＴＳＰコマンドを映像配信サーバ３ａ１に対して送信する（ステップＳ３５および図２：処理▲５▼参照）。
【００７９】
このとき、映像配信サーバ３ａ１は、送信されてきたＲＴＳＰコマンドを受信し、そのＲＴＳＰコマンドにおけるコンテンツ配信宛先（Ｄｅｓｔｉｎａｔｉｏｎ）として指定されたクライアント５ａ１のＩＰアドレスに対して映像コンテンツＣ１（映像ストリーム）を配信（ダウンロード）する（図２；処理▲７▼参照）。
【００８０】
すなわち、ＲＴＳＰプロキシサーバ２ａ１に対して送信されたＲＴＳＰコマンドは、その宛先が変換された状態で中継されて対応する映像配信サーバ３ａ１に対して送信されるようになっており、そのＲＴＳＰコマンド（ＲＴＳＰ再生要求コマンド）に対応する映像コンテンツＣ１は、映像配信サーバ３ａ１から直接クライアント５ａ１に対して配信されるようになっている。
【００８１】
このとき、クライアント５ａ１では、そのプレーヤＰに基づく再生処理により、ダウンロードされてきた映像コンテンツＣ１は順次再生されるため、ユーザは、配信要求に対応する映像コンテンツＣ１を視聴することができる。
【００８２】
一方、クライアント５ａ１において映像コンテンツＣ１の再生が終了すると、クライアント５ａ１は、プレーヤＰに基づいてＲＴＳＰ終了要求コマンド（ＲＴＳＰに基づく映像コンテンツの終了要求メソッドを含むコマンド）を、そのＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対して送信する（図２；処理▲８▼参照）。
【００８３】
ＲＴＳＰプロキシサーバ２ａ１は、送信されてきたＲＴＳＰコマンドを受信し（図１２、ステップＳ３０参照）、そのＲＴＳＰコマンドからクライアント５ａ１のクライアントＩＰアドレスおよびメソッドを抽出し（ステップＳ３２参照）、抽出したメソッドに基づいてＲＴＳＰコマンドが再生要求、すなわち、再生開始を表す開始コマンドおよび終了要求、すなわち、再生終了を表す終了コマンドか否かを判断する（ステップＳ３２参照）。
【００８４】
今、ＲＴＳＰコマンドは、ＲＴＳＰに基づく映像コンテンツの終了要求メソッドを含むコマンドであるため、ステップＳ３２の判断の結果はＹＥＳとなり、ＲＴＳＰプロキシサーバ２ａ１は、対応するクライアント５ａ１のＩＰアドレスを含む視聴終了イベントを受付制御サーバ１０に送信する（ステップＳ３３）。
【００８５】
【外１】
【００８６】
このとき、受付制御サーバ１０は、送信されてきた視聴終了イベントを受信し（図１０；ステップＳ１参照）、このイベントの受信相手（送信元）はＲＴＳＰプロキシサーバ２ａ１であるため、ステップＳ２の判断の結果は”ＲＴＳＰプロキシサーバの場合”となり、受付制御サーバ１０は、受信したイベントが視聴開始イベントか視聴終了イベントかを判断する（図９；ステップＳ４参照）。
【００８７】
今、送信されてきたイベントは視聴終了イベントであるため、ステップＳ４の判断の結果は”終了イベントの場合”となり、受付制御サーバ１０は、視聴終了通知処理を実行する（図１０；ステップＳ６）。
【００８８】
すなわち、受付制御サーバ１０は、送信されてきた視聴終了イベントを受信し（図１４；ステップＳ５０）、クライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６を検索し、セッション管理テーブルＴ６におけるクライアントＩＰアドレスに対応するセッション情報（クライアントＩＰアドレスに対応する映像コンテンツ配信元のサーバ番号、配信ルートに対応する複数の経路それぞれの経路番号、映像コンテンツの使用帯域等）を取得し（ステップＳ５１）、映像コンテンツＣ１の必要帯域を経路リソース管理テーブルＴ５における対応する複数の経路番号の使用帯域からそれぞれ減算して、上記配信ルートのネットワークリソースを開放する（ステップＳ５２）。
【００８９】
ステップＳ５２の前後において、受付制御サーバ１０は、映像コンテンツＣ１の必要帯域を、サーバリソース管理テーブルＴ２における取得したサーバ番号に対応する映像配信サーバの使用帯域から減算して、上記映像配信サーバ３ａ１のサーバリソースを開放する（ステップＳ５３）。
【００９０】
続いて、受付制御サーバ１０は、クライアント５ａ１のクライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６を検索し、このテーブルＴ６から、対応するクライアント５ａ１のセッション情報を削除する（ステップＳ５４）。
【００９１】
一方、ステップＳ３３の前後において、ＲＴＳＰプロキシサーバ２ａ１は、ＲＴＳＰコマンドに含まれるＲＴＳＰプロキシサーバ２ａ１のＵＲＬを検索キーとしてサーバ番号／ＵＲＬ変換テーブルＴ１０を検索し、ＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対応する映像配信サーバ３ａ１のサーバ番号を取得し、上記ＲＴＳＰコマンド（ＲＴＳＰ終了要求コマンド）をクライアント５ａ１をコンテンツ配信宛先（Ｄｅｓｔｉｎａｔｉｏｎ）とするＲＴＳＰコマンド（ＲＴＳＰ終了要求コマンド）に変換し（ステップＳ３４参照）、変換したＲＴＳＰコマンドを、取得したサーバ番号に対して送信する（ステップＳ３５および図２▲９▼参照）。
【００９２】
このとき、映像配信サーバ３ａ１は、送信されてきたＲＴＳＰコマンドを受信し、クライアント５ａ１のＩＰアドレスに対する映像コンテンツＣ１（映像ストリーム）の配信を終了する。
【００９３】
すなわち、クライアント５ａ１からの終了要求に応じて、クライアント５ａ１に対する映像コンテンツＣ１の配信が終了される。
【００９４】
以上述べたように、本実施形態によれば、映像コンテンツ配信元の映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域を含むサーバリソース情報、および通信ネットワークＮＷを経由した通信経路（経路Ｒ１〜Ｒ１１）の最大帯域および使用帯域を含むＮＷリソース情報を受付制御サーバ１０によりそれぞれリアルタイムで監視し、サーバリソース管理テーブルＴ２および経路リソース管理テーブルＴ５により管理している。
【００９５】
このため、クライアント５ａ１からの映像コンテンツ配信要求に対して、その配信元の映像配信サーバ３ａ１の現在のサーバリソース情報および通信ネットワークＮＷを経由したクライアント端末５ａ１と映像配信サーバ３ａ１との間の最適ルートのＮＷリソース情報とを考慮して、その配信要求の受付可否判断を行うことができる。
【００９６】
すなわち、コンテンツ配信元の映像配信サーバ３ａ１の現在のサーバリソース情報に基づいて、そのサーバ３ａ１による配信要求に対応する映像コンテンツの配信が不可と判断された場合には、その配信要求の受付を拒否することができ、また、通信ネットワークＮＷを経由したクライアント端末５ａ１と映像配信サーバ３ａ１との間の最適ルートのＮＷリソース情報に基づいて、その最適ルートによる配信要求に対応する映像コンテンツの配信が不可と判断された場合には、上記配信要求の受付を拒否することができる。
【００９７】
この結果、映像コンテンツ配信元である映像配信サーバ３ａ１および映像コンテンツ配信先であるクライアント５ａ１間のエンドツーエンドでのＱｏＳを保証した映像配信サービスを提供することができる。
【００９８】
（実施例）
本実施の形態に係わるストリーミングコンテンツ配信システム１におけるＲＴＳＰプロキシサーバによる映像コンテンツ視聴終了時のリソース開放のリアルタイム性を検証するため、ストリーミングコンテンツ配信システム１のプロトタイプを作成し、作成したストリーミングコンテンツ配信システム１（プロトタイプ）におけるリソース開放処理時間の測定を行った。
【００９９】
この測定結果を図１５に示した。
【０１００】
図１５に示すように、ユーザ１００人（クライアント１００台）が同時に映像コンテンツの視聴を終了した場合、約１０秒以内にリソース開放を行えることが確認できた。
【０１０１】
すなわち、本実施形態に係わるＲＴＳＰプロキシサーバによるコンテンツ視聴終了検知方式は、映像配信サーバのログを収集する方式と比べてリアルタイム性があり、通信ネットワークＮＷおよび映像配信サーバのリソースの利用効率を向上させることができる。
【０１０２】
また、上記ストリーミングコンテンツ配信システム１のプロトタイプにおいて、ＲＴＳＰプロキシサーバの処理性能を測定した結果、図１６に示すように、このＲＴＳＰプロキシサーバによりＲＴＳＰコマンドを中継することによる遅延は、同時アクセス１００ユーザ（クライアント１００台）で最大０．５秒程度に収まる結果となり、ＲＴＳＰプロキシサーバによる遅延の影響がほとんど無いことが確認できた。
【０１０３】
すなわち、本実施形態に係わるＲＴＳＰプロキシサーバによるＲＴＳＰコマンド中継方式を用いた場合でも、映像コンテンツ配信のリアルタイム性に対してほとんど影響を与えることがなく、ＱｏＳおよび配信リアルタイム性をそれぞれ高く維持することができる。
【０１０４】
なお、本実施形態では、ストリーミングコンテンツを映像コンテンツとしたが、例えば音楽コンテンツ等の他のストリーミングコンテンツであっても適用可能である。
【０１０５】
また、本実施の形態では、受付制御サーバ１０および各ＲＴＳＰプロキシサーバ２ａ１、２ａ２によりストリーミングコンテンツ配信要求受付制御システム２５を構成したが、本発明はこの構成に限定されるものではなく、受付制御サーバ１０および少なくとも１つのＲＴＳＰプロキシサーバによりストリーミングコンテンツ配信要求受付制御システム２５を構成することができる。また、少なくとも１つのＲＴＳＰプロキシサーバの機能を受付制御サーバ１０にプログラムとして実装することにより、受付制御サーバによりストリーミングコンテンツ配信要求受付制御システム２５を構成することも可能である。
【０１０６】
また、本実施形態におけるＲＴＳＰプロキシサーバを用いた映像コンテンツ視聴開始イベントおよび終了イベント検知方式は、ＲＴＳＰプロトコルを実装した複数ベンダーの映像配信サーバに対して適用可能である。
【０１０７】
さらに、本実施形態では、各クライアントに対してＩＰアドレスが固定割当されている場合について説明したが、本発明はこの構成に限定されるものではなく、クライアントに対してＩＰアドレスを動的に割り当てる場合においても適用可能である。
【０１０８】
このＩＰアドレス動的割当方式の場合、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）サーバを用いて、ＩＰアドレスを各クライアントに対して動的に割り当てることができる。この場合、受付制御サーバがＲＡＤＩＵＳサーバと連携し、そのＲＡＤＩＵＳサーバにより各クライアントに割り当てたＩＰアドレスを受付制御サーバに通知することにより、上記ＩＰアドレスの動的割当に対しても対応可能である。
【０１０９】
また、本実施形態では、各映像配信サーバ３ａ１、３ａ２の現在の使用可能帯域に関連するサーバリソースとして、上記各映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域をそれぞれ監視して管理したが、本発明はこの構成に限定されるものではなく、各映像配信サーバ３ａ１、３ａ２の残帯域（最大帯域−使用帯域）を監視および管理してもよい。
【０１１０】
同様に、各通信経路Ｒ１〜Ｒ１１の現在の使用可能帯域に関連するネットワークリソースとして、その各通信経路Ｒ１〜Ｒ１１の最大帯域および使用帯域をそれぞれ監視したが、本発明はこの構成に限定されるものではなく、各通信経路Ｒ１〜Ｒ１１の残帯域（最大帯域−使用帯域）を監視および管理してもよい。
【０１１１】
そして、本実施形態では、クライアントおよび映像配信サーバ間の最適ルートは、クライアントが所属するサブネットワークのサブネット番号と映像配信サーバが所属するエッジのエッジ番号とが決定されれば一意に定まるものとして説明したが、本発明はこの構成に限定されるものではなく、例えばＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ：ルータの接続数ではなく、通信ネットワークＮＷに関連する各経路Ｒ１〜Ｒ１１の帯域幅等に基づいた「コスト」という値により計算を行い、最小のコストで到達できるルートを最適ルートとして選択するルーティングアルゴリズム）等の最適ルート決定アルゴリズムによりダイナミックルーティングしてもよい。この場合、上記最適ルート決定アルゴリズムに基づくプログラムを受付制御サーバのメモリに実装し、上記最適ルート決定アルゴリズムに基づくプログラムにより受付制御サーバを動作させることにより、対応可能である。
【０１１２】
さらに、本実施形態では、クライアントのストリーミングコンテンツ再生用プレーヤがＲＴＳＰコマンドの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）指定機能を実装しているものとしたが、本発明はこの構成に限定されるものではなく、ＲＴＳＰプロキシサーバにおいて、ＲＴＳＰコマンドの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）にクライアントのＩＰアドレスを指定させるようにしてもよい。
【０１１３】
【発明の効果】
以上述べたように、本発明に係わるストリーミングコンテンツ配信要求受付制御システムによれば、配信サーバの現在の使用可能帯域に関連する帯域リソース情報、および通信ネットワーク上の複数の中継点、前記クライアント端末および前記配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報をそれぞれ監視することにより、クライアント端末からのストリーミングコンテンツ配信要求に対して、その配信元の配信サーバの現在のサーバリソース情報および通信ネットワークＮＷを経由したクライアント端末と配信サーバとの間の最適ルートのネットワークリソース情報とを考慮して、その配信要求の受付可否判断を行うことができる。
【０１１４】
したがって、ストリーミングコンテンツ配信元の配信サーバおよびストリーミングコンテンツ配信要求元であるクライアント端末間のエンドツーエンドでのＱｏＳを保証した映像配信サービスを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるストリーミングコンテンツ配信要求受付制御システムを含むストリーミングコンテンツ配信システムの概略構成を示す図。
【図２】図１に示すストリーミングコンテンツ配信要求受付制御システムの概略構成およびストリーミングコンテンツ配信システムの全体処理をそれぞれ示す図。
【図３】図２に示すクライアント管理テーブルの概略構成を示す図。
【図４】図２に示すサーバリソース管理テーブルの概略構成を示す図。
【図５】図２に示すコンテンツ管理テーブルの概略構成を示す図。
【図６】図２に示す経路管理テーブルの概略構成を示す図。
【図７】図２に示す経路リソース管理テーブルの概略構成を示す図。
【図８】図２に示すセッション管理テーブルの概略構成を示す図。
【図９】図２に示すＵＲＬ変換テーブルの概略構成を示す図。
【図１０】図１および図２に示す受付制御サーバの処理の一例を示す概略フローチャート。
【図１１】図１０に示す受付可否処理を詳細に説明するためのフローチャート。
【図１２】図１および図２に示すＲＴＳＰプロキシサーバの処理の一例を示す概略フローチャート。
【図１３】図１０に示す視聴開始通知処理を詳細に説明するためのフローチャート。
【図１４】図１０に示す視聴終了通知処理を詳細に説明するためのフローチャート。
【図１５】本発明の実施の形態に係わるストリーミングコンテンツ配信システムのプロトタイプを用いたリソース開放処理時間の測定結果を表す図。
【図１６】本発明の実施の形態に係わるストリーミングコンテンツ配信システムのプロトタイプを用いたＲＴＳＰプロキシサーバの処理性能の測定結果を表す図。
【符号の説明】
１ ストリーミングコンテンツ配信システム
２ａ１、２ａ２ ＲＴＳＰプロキシサーバ
３ａ１、３ａ２ 映像配信サーバ
５ａ１、５ａ２ クライアント端末
７ ＷＷＷポータルサーバ
１０ 受付制御サーバ
１１ リソースデータベース
１５ａ１〜１５ａ５ ルータ
２１ サーバリソース監視部
２２ ネットワークリソース監視部
２５ ストリーミングコンテンツ配信要求受付制御システム
Ｔ１ クライアント管理テーブル
Ｔ２ サーバリソース管理テーブル
Ｔ３ コンテンツ管理テーブル
Ｔ４ 経路管理テーブル
Ｔ５ 経路リソース管理テーブル
Ｔ６ セッション管理テーブル
Ｔ１０ ＵＲＬ変換テーブル
【発明の属する技術分野】
本発明は、クライアント端末から通信ネットワークを介して、映像コンテンツ、音楽コンテンツ等のストリーミング型コンテンツ（ダウンロードしながら再生できるコンテンツ；本明細書では、ストリーミングコンテンツと記載する）の配信要求が送信された際に、その配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システムに関する。
【０００２】
【従来の技術】
ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ：非同期転送モード）ネットワークのコネクション設定方式をモデルにして、静的に通信ネットワーク（以下、ＮＷとも記載する）の帯域を積上げて管理し、新しい呼の接続要求に対してＮＷの空き状況を考慮して帯域の割り当てを行い、品質を確保する方式が知られている（例えば、特許文献１参照）。
【０００３】
また、クライアントからＮＷの必要帯域、区間および利用帯域を含む帯域予約情報が指定された際に、Ｐｏｌｉｃｙサーバを用いてクライアントの帯域予約情報に対してネットワーク機器のプロビジョニング（事前準備）を行い、動的にネットワーク機器のコンフィグレーション（設定）を行う方式についても知られている（例えば、特許文献２参照）。
【０００４】
【特許文献１】
特開２００１−２５３０２１号公報
【０００５】
【特許文献２】
特開２００１−２２３７４１号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、上述した新しい呼の接続要求に対してＮＷの空き状況を考慮して帯域の割り当てを行う方式では、ＮＷのブローカ（クライアント端末とサーバとの間の仲介する）がネットワーク事業者の指定するＮＷの利用期間、区間および必要帯域等についてＮＷを貸し出すようなサービスにおいて帯域を割り当てる場合に有効である。
【０００７】
しかしながら、マスユーザ向けのビデオ・オン・デマンド型のストリーミングコンテンツ配信サービスでは、任意の時間に各ユーザのクライアント端末からアクセスされるため、クライアント端末のＮＷの利用期間を予め予測することは不可能である。
【０００８】
すなわち、上記ストリーミングコンテンツ配信サービスに対して従来の帯域割当方式を用いた場合においては、クライアントのアクセス毎に必要帯域を確保して通信品質｛ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）：サービスの質を表す指標｝を保証することが非常に困難であった。
【０００９】
また、上述したクライアントからの帯域予約情報に基づいてネットワーク機器のプロビジョニングを行って帯域を割り当てる方式においては、コンテンツ配信サービスのＱｏＳをＮＷリソースの観点のみから捉えており、コンテンツ配信元のサーバのリソースを考慮していないため、ＱｏＳを保証した配信サービスを提供しているとはいえなかった。
【００１０】
本発明は、上述した事情に鑑みてなされたものであり、ＱｏＳを保証したストリーミングコンテンツ配信サービスを提供できるストリーミングコンテンツ配信要求受付制御システムを提供することをその目的とする。
【００１１】
【課題を解決するための手段】
上述した目的を達成するため、本発明は、請求項１に記載したように、配信サーバから通信ネットワーク経由で配信可能なストリーミングコンテンツの配信要求がクライアント端末から当該通信ネットワークを介して送信されてきた際に、そのストリーミングコンテンツ配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システムであって、前記配信サーバの現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視手段と、前記通信ネットワーク上の複数の中継点、前記クライアント端末および前記配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視手段と、備えたことを特徴とする。
【００１２】
特に、請求項２に記載された発明においては、前記サーバリソース監視手段は、監視した前記配信サーバの帯域リソース情報を当該配信サーバの識別情報に関連付けて管理する配信サーバリソース管理手段を備え、前記ネットワークリソース監視手段は、監視した前記複数の通信経路それぞれのネットワークリソース情報を当該複数の通信経路それぞれの経路識別情報に関連付けて管理するネットワークリソース管理手段を備えたことを特徴とする。
【００１３】
また、請求項３に記載された発明においては、前記通信ネットワーク上における前記配信サーバおよび前記配信要求送信元のクライアント端末間の最適ルートとして設定された複数の通信経路それぞれの経路識別情報を前記配信サーバおよびクライアント端末に関連付けて記憶する経路管理手段を備えたことを特徴とする。
【００１４】
さらに、請求項４に記載された発明においては、前記クライアント端末から送信されてきた配信要求に対応するストリーミングコンテンツの必要帯域、前記配信サーバの帯域リソース情報、前記複数の通信経路それぞれのネットワークリソース情報および前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報に基づいて、当該配信要求を受け付けるか否かを判断する受付可否判断手段をさらに備えたことを特徴とする。
【００１５】
そして、請求項５に記載された発明においては、前記受付可否判断手段は、前記配信サーバの帯域リソース情報から当該配信サーバの使用可能帯域を把握し、把握した使用可能帯域と前記受信した配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第１の比較判断手段を備えたことを特徴とする。
【００１６】
特に、請求項６に記載された発明においては、前記受付可否判断手段は、前記第１の比較判断手段により前記配信要求が受付可能であると判断された際に、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報および前記複数の通信経路それぞれのネットワークリソース情報から当該パスを構成する複数の通信経路それぞれの使用可能帯域を把握し、把握したそれぞれの使用可能帯域と前記配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第２の比較判断手段をさらに備えたことを特徴とする。
【００１７】
さらに、請求項７に記載された発明においては、前記受付可否判断手段により前記配信要求が受付られた場合において、当該配信要求に対応するクライアント端末の識別情報、前記配信サーバの識別情報、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報、当該配信要求に対応するストリーミングコンテンツの必要帯域および当該ストリーミングコンテンツの再生時間を互いに関連付けて当該クライアント端末のセッション情報として記憶するセッション情報記憶手段をさらに備えたことを特徴とする。
【００１８】
そして、請求項８に記載された発明においては、前記受付可否判断手段により前記配信要求が受付られた場合において、前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの再生要求コマンドを受信し、受信した再生要求コマンドを中継して前記配信サーバに送信する第１の中継手段と、前記ストリーミングコンテンツの再生要求コマンドの受信に応じて、当該ストリーミングコンテンツの視聴開始時刻を表す視聴開始時刻情報を前記セッション情報に関連付けて記録する視聴開始時刻記録手段と、前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの終了要求コマンドを受信し、受信した終了要求コマンドを中継して前記配信サーバに送信する第２の中継手段と、前記ストリーミングコンテンツの終了要求コマンドの受信に応じて、前記セッション情報を削除するセッション情報削除手段と、をさらに備えたことを特徴とする。
【００１９】
【発明の実施の形態】
図１は、本発明の実施の形態に係わるストリーミングコンテンツ配信要求受付制御システムを含むストリーミングコンテンツ配信システム１の概略構成を示す図である。
【００２０】
図１に示すように、ストリーミングコンテンツ配信システム１は、ダウンロード型コンテンツ（パケット）の通信用プロトコルである例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ；パケット配信管理用プロトコル）に加えて、ストリーミングコンテンツ配信用プロトコルであるＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ；ストリーミングコンテンツのデータ送受信単位であるＲＴＰパケット管理用プロトコル）、ＲＴＳＰ（Ｒｅａｌｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ；ストリーミングコンテンツ再生、静止等の制御用プロトコル）等｝に基づいてＷＷＷコンテンツ、ストリーミングコンテンツを中継可能なインターネット等の通信ネットワークＮＷを備えている。
【００２１】
また、ストリーミングコンテンツ配信システム１は、例えば分散配置され、通信ネットワークＮＷを経由したＲＴＳＰコマンドを監視する機能およびＲＴＳＰコマンドを中継する機能をそれぞれ有する複数のＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・（図１においては、２つのＲＴＳＰプロキシサーバ２ａ１、２ａ２のみ示す）を備えている。
【００２２】
さらに、ストリーミングコンテンツ配信システム１は、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・に通信可能にそれぞれ設けられ、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・により中継されたＲＴＳＰコマンドに応じてストリーミングコンテンツである例えば映像コンテンツを、通信ネットワークＮＷとの接続が確立された複数のクライアント端末（以下、クライアントと略記する）５ａ１、５ａ２、・・・（図１においては、２つのクライアント５ａ１、５ａ２のみ示す）に対して配信可能な映像配信サーバ３ａ１、３ａ２、・・・（図１においては、２つの映像配信サーバ３ａ１、３ａ２のみ示す）を備えている。
【００２３】
各ＲＴＳＰプロキシサーバ２ａ１、２ａ２、・・・は、少なくとも１台のコンピュータ（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）から構成されており、そのメモリには、上記ＴＣＰ等の通信プロトコルが実装されている。同様に、各映像配信サーバ３ａ１、３ａ２、・・・は、少なくとも１台のコンピュータ（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）から構成されており、そのメモリには、上記ＲＴＰ、ＲＴＳＰ等のストリーミングコンテンツ配信用プロトコルが実装されている。
【００２４】
そして、ＲＴＳＰプロキシサーバ２ａ１および映像配信サーバ３ａ１が配置されているロケーションには、そのロケーションを識別するためのエッジ番号Ｅ１が設定されており、ＲＴＳＰプロキシサーバ２ａ１および映像配信サーバ３ａ１は、Ｅ１エッジのロケーションに分散配置されている。
【００２５】
同様に、ＲＴＳＰプロキシサーバ２ａ２および映像配信サーバ３ａ２は、Ｅ２エッジのロケーションに分散配置されている。なお、本実施形態においては、以下、２つのＲＴＳＰプロキシサーバ２ａ１、２ａ２および２つの映像配信サーバ３ａ１、３ａ２が配置されている場合について説明する。
【００２６】
また、各クライアント５ａ１および５ａ２（以下、クライアントがこの２つのクライアント５ａ１、５ａ２であるものとする）は、パーソナルコンピュータや携帯端末（ＣＰＵ、メモリ、入力部、ディスプレイ、スピーカ、通信インタフェース等を含む）等から構成されている。
【００２７】
さらに、各クライアント５ａ１および５ａ２のメモリには、ＷＷＷコンテンツをディスプレイを介して表示（閲覧）する手段、および上記ＷＷＷコンテンツ上において入力部を介して入力されたイベントを後述するＷＷＷポータルサーバ７に送信する手段としてのＷＷＷブラウザ（ソフトウェア）Ｂが実装されている。
【００２８】
各クライアント５ａ１および５ａ２のメモリには、上記ストリーミングコンテンツをディスプレイ、スピーカ等を介して再生する手段としてのソフトウェアであるプレーヤＰが実装されている。
【００２９】
そして、各クライアント５ａ１および５ａ２は、例えばＬＡＮ等のサブネットワークＳｂ１およびＳｂ２に属しており、このサブネットワークＳｂ１およびＳｂ２が通信ネットワークＮＷに対して通信可能になっている。なお、サブネットワークＳｂ１の識別情報である識別番号（以下、サブネット番号と記載する）を”ＳＢ１”とし、サブネットワークＳｂ２のサブネット番号を”Ｓｂ２”とする。
【００３０】
そして、ストリーミングコンテンツ配信システム１は、複数のクライアント５ａ１、５ａ２それぞれに対して、そのクライアント５ａ１、５ａ２それぞれにより閲覧（ブラウズ）でき、かつ映像コンテンツ再生等を要求可能なＷＷＷコンテンツとして、上記映像配信サーバ３ａ１、３ａ２により配信可能な複数の映像コンテンツのリストの表示および所望の映像コンテンツの視聴（再生）要求を入力できる映像コンテンツ視聴用ＷＷＷコンテンツを提供するためのＷＷＷポータルサーバ（少なくとも１つのコンピュータから構成されている）７を備えている。このＷＷＷポータルサーバ７は、そのメモリに格納されたＷＷＷサーバ（ソフトウェア）に従って動作するようになっている。
【００３１】
さらに、ストリーミングコンテンツ配信システム１は、ＲＴＳＰプロキシサーバ２ａ１、２ａ２、映像配信サーバ３ａ１、３ａ２、ＷＷＷポータルサーバ７および通信ネットワークＮＷにそれぞれ通信可能であり、通信ネットワークＮＷおよび各映像配信サーバ３ａ１、３ａ２のリソースをリアルタイムに監視して該監視結果であるリソース情報をリアルタイムで更新しながら統合的に管理し、この管理内容に基づいて、各クライアント５ａ１、５ａ２から送信された映像コンテンツ視聴要求（配信要求）に対する受付制御するための受付制御サーバ１０と、この受付制御サーバ１０がアクセス可能であり、上記リソース情報等を格納するためのリソースデータベース（ＤＢ）１１とを備えている。
【００３２】
さらに、通信ネットワークＮＷ上の複数の中継点には、通信ネットワークＮＷ経由のデータをルーティングするための複数のルータ１５ａ１〜１５ａｎ（本実施形態では、説明を容易にするため、ｎ＝５とする）がそれぞれ設置されている。
【００３３】
複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ１は、クライアント５ａ１が属するサブネットＳｂ１に対する中継点に設置されており、このルータ１５ａ１およびクライアント５ａ１間の経路を経路Ｒ１とする。
【００３４】
また、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ２は、クライアント５ａ２が属するサブネットＳｂ２に対する中継点に設置されており、このルータ１５ａ２およびクライアント５ａ２間の経路を経路Ｒ２とする。
【００３５】
同様に、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ３は、映像配信サーバ３ａ１に対する中継点に設置されており、このルータ１５ａ３および映像配信サーバ３ａ１間の経路を経路Ｒ１０とする。
【００３６】
また、複数のルータ１５ａ１〜１５ａ５におけるルータ１５ａ４は、映像配信サーバ３ａ２に対する中継地点に設置されており、このルータ１５ａ４および映像配信サーバ３ａ２間の経路を経路Ｒ１１とする。
【００３７】
さらに、ルータ１５ａ１およびルータ１５ａ３間には、そのルータ１５ａ１およびルータ１５ａ３間のデータ通信を中継するルータ１５ａ５が設置されている。
【００３８】
ここで、ルータ１５ａ１およびルータ１５ａ２間の経路を経路Ｒ３、ルータ１５ａ１およびルータ１５ａ５間の経路を経路Ｒ４、ルータ１５ａ２よびルータ１５ａ５間の経路を経路Ｒ５、ルータ１５ａ２およびルータ１５ａ４間の経路を経路Ｒ６、ルータ１５ａ４およびルータ１５ａ５間の経路を経路Ｒ７、ルータ１５ａ３およびルータ１５ａ５間の経路を経路Ｒ８およびルータ１５ａ３およびルータ１５ａ４間の経路を経路Ｒ９とする。
【００３９】
受付制御サーバ１０は、図２に示すように、各映像配信サーバ３ａ１、３ａ２の現在の使用可能帯域｛各サーバの最大帯域（映像コンテンツの品質を確保して配信できる最大の通信帯域を表す）から実際に使用している通信帯域（使用帯域とする）を減算した帯域に相当し、映像コンテンツの配信に使用できる帯域を表す｝に関連するサーバリソースとして、上記各映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域をそれぞれ監視するためのサーバリソース監視部２１と、上記複数の通信経路Ｒ１〜Ｒ１１それぞれの現在の使用可能帯域｛各通信経路の最大帯域（映像コンテンツの品質を確保して配信できる最大の通信帯域を表す）から実際に使用している通信帯域（使用帯域とする）を減算した帯域に相当し、映像コンテンツの配信に使用できる帯域を表す｝に関連するネットワークリソースとして、上記各通信経路Ｒ１〜Ｒ１１の最大帯域および使用帯域をそれぞれ監視するためのネットワークリソース監視部２２とを備えている。なお、サーバリソース監視部２１およびネットワークリソース監視部２２は、受付制御サーバ１０のメモリに格納された監視用プログラムに基づく受付制御サーバ１０の機能として具体化される。
【００４０】
また、本実施の形態では、受付制御サーバ１０および各ＲＴＳＰプロキシサーバ２ａ１、２ａ２によりストリーミングコンテンツ配信要求受付制御システム２５を構成している。
【００４１】
リソースＤＢ１１は、図２に示すように、クライアント管理テーブルＴ１、サーバリソース管理テーブルＴ２、コンテンツ管理テーブルＴ３、経路管理テーブルＴ４、経路リソース管理テーブルＴ５およびセッション管理テーブルＴ６を有している。
【００４２】
クライアント管理テーブルＴ１には、図３に示すように、各クライアント５ａ１、５ａ２、・・・の通信ネットワークＮＷ経由の通信場所（宛先）を表すアドレスとしてのＩＰアドレスと、各クライアント５ａ１、５ａ２、・・・が属するサブネットのサブネット番号（例えば、クライアント５ａ１→サブネット番号Ｓｂ１、クライアント５ａ２→サブネット番号Ｓｂ２）と、各クライアント５ａ１、５ａ２、・・・が属するサブネットに対して最寄のエッジを示すエッジ番号（例えば、サブネットＳｂ２→エッジ番号Ｅ２、サブネットＳｂ１→エッジ番号Ｅ１）とがクライアント毎に互いに関連付けられて記憶されている。
【００４３】
また、サーバリソース管理テーブルＴ２には、図４に示すように、各映像配信サーバ３ａ１、３ａ２の識別情報であるサーバ番号と、各映像配信サーバ３ａ１、３ａ２が属するエッジを示すエッジ番号と、各映像配信サーバ３ａ１、３ａ２の使用帯域と、各映像配信サーバ３ａ１、３ａ２の最大帯域と、各映像配信サーバ３ａ１、３ａ２と同一のエッジに属するＲＴＳＰプロキシサーバ２ａ１、２ａ２の通信ネットワークＮＷ経由の通信場所を表すアドレスとしてのＩＰアドレスと、各ＲＴＳＰプロキシサーバ２ａ１、２ａ２が複数の映像配信サーバに対してＲＴＳＰコマンドを中継する場合、それぞれの映像配信サーバを識別するためのポート番号とが映像配信サーバ毎に互いに関連付けられて記憶されている。
【００４４】
さらに、コンテンツ管理テーブルＴ３には、図５に示すように、映像配信サーバ３ａ１、３ａ２から配信可能な複数の映像コンテンツ（例えば、映像コンテンツＣ１、Ｃ２、Ｃ３とする）を識別するためのコンテンツ番号（映像コンテンツＣ１→コンテンツ番号Ｃ１、映像コンテンツＣ２→コンテンツ番号Ｃ２、映像コンテンツＣ３→コンテンツ番号Ｃ３）と、それぞれの映像コンテンツＣ１〜Ｃ３の配信に必要な必要帯域と、それぞれの映像コンテンツＣ１〜Ｃ３の保存場所を表す映像配信サーバのサーバ番号（映像コンテンツＣ１→映像配信サーバ３ａ１、映像コンテンツＣ２→映像配信サーバ３ａ１、映像コンテンツＣ３→映像配信サーバ３ａ２）と、それぞれの映像コンテンツＣ１〜Ｃ３の再生時間とが映像コンテンツ毎に互いに関連付けられて記憶されている。
【００４５】
そして、経路管理テーブルＴ４には、図６に示すように、各エッジ番号と、各サブネット番号と、各エッジ番号および各サブネット番号から決定された各エッジＥ１、Ｅ２および各サブネットＳｂ１、Ｓｂ２間の最適ルートとして設定された複数の経路を識別するための経路番号のグループ（例えば、エッジＥ１とサブネットＳｂ１との間の最適ルート→経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０、エッジＥ１とサブネットＳｂ２との間の最適ルート→経路Ｒ２、経路Ｒ６、経路Ｒ９、経路Ｒ１０、エッジＥ２とサブネットＳｂ１との間の最適ルート→経路Ｒ１、経路Ｒ３、経路Ｒ５、経路Ｒ７、経路Ｒ１１、エッジＥ２とサブネットＳｂ２との間の最適ルート→経路Ｒ２、経路Ｒ６、経路Ｒ１１）とがエッジ毎に互いに関連付けられて記憶されている。
【００４６】
また、経路リソース管理テーブルＴ５には、図７に示すように、各経路Ｒ１〜Ｒ１１の経路番号（経路番号Ｒ１〜Ｒ１１）と、各経路Ｒ１〜Ｒ１１の使用帯域と、各経路Ｒ１〜Ｒ１１の最大帯域とが経路毎に互いに関連付けられて記憶されている。
【００４７】
さらに、セッション管理テーブルＴ６には、図８に示すように、映像コンテンツを視聴（再生）しているクライアントのＩＰアドレスと、その映像コンテンツの配信元の映像配信サーバ３ａ１、３ａ２を表すサーバ番号と、映像配信サーバ３ａ１、３ａ２（対応するエッジ）から配信先のクライアント５ａ１、５ａ２に対して映像コンテンツを配信しているルート（最適ルート）を構成する複数の経路の経路番号と、上記映像コンテンツ配信において使用している使用帯域と、配信先クライアントによる映像コンテンツの視聴開始時刻と、その映像コンテンツの再生時間（視聴時間：映像コンテンツを最初から最後まで視聴するのに要する時間）とが映像コンテンツ視聴クライアント毎に互いに関連付けられて記憶されている。
【００４８】
一方、ＲＴＳＰプロキシサーバ２ａ１には、図２および図９に示すように、各映像配信サーバ３ａ１、３ａ２のサーバ番号とその各映像配信サーバ３ａ１、３ａ２に対応するＵＲＬとが互いに関連付けられたＵＲＬ変換テーブルＴ１０が設けられている。
【００４９】
次に、本実施形態に係わるストリーミングコンテンツ配信システム１の全体動作について、特に、ストリーミングコンテンツ配信要求受付制御システム２５の動作処理を中心に説明する。
【００５０】
ストリーミングコンテンツ配信要求受付制御システム２５の受付制御サーバ１０は、サーバリソース監視部２１に基づく処理により、通信ネットワークＮＷに対して通信可能な映像配信サーバ３ａ１、３ａ２の現在の使用帯域、最大帯域等のサーバリソース情報をリアルタイムで監視しており、その監視情報に基づいてサーバリソース管理テーブルＴ２を更新し、現在のサーバ３ａ１、３ａ２のサーバリソース情報をリアルタイムで把握している。
【００５１】
さらに、受付制御サーバ１０は、ネットワークリソース監視部２２に基づく処理により、通信ネットワークＮＷを経由した通信経路である通信経路Ｒ１〜Ｒ１１それぞれの現在の使用帯域および最大帯域等のネットワーク（ＮＷ）リソース情報をリアルタイムで監視しており、その監視情報に基づいて経路リソース管理テーブルＴ５を更新し、現在の通信ネットワークＮＷを経由した通信経路のリソース情報をリアルタイムで把握している。
【００５２】
また、クライアント５ａ１には、ＷＷＷポータルサーバ７から、映像コンテンツ視聴用ＷＷＷコンテンツがダウンロードされており、そのＷＷＷブラウザＢに基づくクライアント５ａ１の閲覧表示機能により、映像コンテンツ視聴用ＷＷＷコンテンツがディスプレイを介して表示されている。
【００５３】
このとき、クライアント５ａ１のユーザは、そのクライアント５ａ１にダウンロードされている映像コンテンツ視聴用ＷＷＷコンテンツにおける映像コンテンツリスト（複数の映像コンテンツＣ１、Ｃ２およびＣ３のリスト）を閲覧しながら、自分が見たい映像コンテンツを入力部を操作して選択（例えば、映像コンテンツＣ１を選択したとする）して、その選択映像コンテンツＣ１の配信要求のイベントをクライアント５ａ１に入力する。
【００５４】
クライアント５ａ１は、入力された映像コンテンツＣ１の配信要求（視聴要求）を通信ネットワークＮＷを介してＷＷＷポータルサーバ７に対して送信する（図２中、処理▲１▼参照）。
【００５５】
このとき、ＷＷＷポータルサーバ７は、クライアント５ａ１の処理▲１▼により送信されてきた映像コンテンツＣ１の視聴要求を受けると、ＷＷＷポータルサーバ７は、その視聴要求に対応する映像コンテンツＣ１のコンテンツ番号、および対応クライアント５ａ１のＩＰアドレスを受付制御サーバ１０に通知する。
【００５６】
受付制御サーバ１０は、図１０に示すように、ＷＷＷポータルサーバ７から送信されてきたデータに対応するイベントを受信し（ステップＳ１）、受信したイベントの送信元（受信イベントの相手）がＷＷＷポータルサーバ７かＲＴＳＰプロキシサーバ２ａ１、２ａ２か否か判断する（ステップＳ２）。
【００５７】
今、イベントの送信元（受信相手）がＷＷＷポータルサーバ７であるため、ステップＳ２の判断は図１０に示す”ＷＷＷポータルサーバの場合”となり、受付制御サーバ１０は、視聴要求の受付の可否判断処理を実行する（図２の処理▲２▼およびステップＳ３）。
【００５８】
すなわち、受付制御サーバ１０は、ステップＳ３の処理として、ＷＷＷポータルサーバ７から通知された視聴要求に対応する映像コンテンツＣ１のコンテンツ番号、および対応クライアント５ａ１のＩＰアドレスを受信し（図１１；ステップＳ１０）、受信したクライアントＩＰアドレスを検索キーとしてリソースＤＢ１１のクライアント管理テーブルＴ１を検索し、クライアントＩＰアドレスに対応するエッジ番号およびサブネット番号（クライアントが５ａ１の場合、エッジ番号Ｅ１およびサブネット番号Ｓｂ１）を含むクライアント情報を取得する（ステップＳ１１）。
【００５９】
次いで、受付制御サーバ１０は、受信したコンテンツ番号を検索キーとしてリソースＤＢ１１のコンテンツ管理テーブルＴ３を検索し、コンテンツ番号（Ｃ１）に対応する必要帯域、映像コンテンツＣ１の保存場所を表す映像配信サーバ（３ａ１）のサーバ番号および再生時間を含むコンテンツ情報を取得する（ステップＳ１２）。
【００６０】
さらに、受付制御サーバ１０は、取得した映像コンテンツＣ１の保存場所を表す映像配信サーバ３ａ１のサーバ番号を検索キーとしてリソースＤＢ１１のサーバリソース管理テーブルＴ２を検索し、サーバ番号（映像配信サーバ３ａ１）に対応する映像配信サーバ３ａ１の使用帯域、最大帯域、対応するＲＴＳＰプロキシサーバ（２ａ１）のＩＰアドレスおよびポート番号を含むサーバ情報を取得する（ステップＳ１３）。
【００６１】
続いて、受付制御サーバ１０は、ステップＳ１２の処理で取得した映像コンテンツＣ１の必要帯域と、ステップＳ１３の処理で取得した映像配信サーバ３ａ１の使用帯域および最大帯域とから、その必要帯域と使用帯域とを加算した値と最大帯域の値とを比較し（ステップＳ１４）、必要帯域および使用帯域の加算値が最大帯域を越える場合には（ステップＳ１４の判断の結果ＮＧ）、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１を配信するための空きリソースが映像配信サーバ３ａ１に無く、配信要求の受付ができない（ＮＧ）ことを表す情報（配信受付ＮＧ結果）をＷＷＷポータルサーバ７に通知する（ステップＳ１５）。
【００６２】
一方、必要帯域および使用帯域の加算値が最大帯域以下の場合には（ステップＳ１４の判断の結果ＯＫ）、受付制御サーバ１０は、取得したエッジ番号およびサブネット番号を検索キーとしてリソースＤＢ１１の経路管理テーブルＴ４を検索し、そのエッジ番号（エッジＥ１）およびサブネット番号（サブネット番号Ｓｂ１）に対応する経路番号（経路番号グループ）を取得し（エッジＥ１、サブネット番号Ｓｂ１の場合、経路Ｒ１、経路Ｒ４、経路Ｒ８および経路Ｒ１０）、その取得した経路番号グループに対応するルート（経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０）を、配信要求に対応する通信ネットワークＮＷを介した配信ルート（最適ルート）として決定する（ステップＳ１６）。
【００６３】
次いで、受付制御サーバ１０は、取得したそれぞれの経路番号を検索キーとしてリソースＤＢ１１の経路リソース管理テーブルＴ５を検索し、それぞれの経路番号の使用帯域および最大帯域を含むＮＷリソース情報を取得する（ステップＳ１７）。
【００６４】
続いて、受付制御サーバ１０は、ステップＳ１２の処理で取得した映像コンテンツＣ１の必要帯域と、ステップＳ１７の処理で取得した配信ルートを構成するそれぞれの経路の使用帯域および最大帯域とから、各経路の必要帯域とコンテンツＣ１使用帯域とを加算した値と各経路の最大帯域の値とを各経路毎に比較し（ステップＳ１８）、上記配信ルートを構成する各経路の内、１つでも上記加算値が最大帯域を超える経路が存在した場合には（ステップＳ１８の判断の結果ＮＧ）、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１を配信するための空きリソースが通信ネットワークＮＷに無く、配信要求の受付ができない（ＮＧ）ことを表す情報（配信受付ＮＧ）をＷＷＷポータルサーバ７に通知する（ステップＳ１５）。
【００６５】
一方、決定した配信ルートを構成する各経路の必要帯域とコンテンツＣ１使用帯域との加算値が対応する各経路の最大帯域以下の場合には（ステップＳ１８の判断の結果ＯＫ）、受付制御サーバ１０は、経路リソース管理テーブルＴ５における配信ルートを構成する各経路に対応する使用帯域に対して、今回の映像コンテンツＣ１の必要帯域を加算して経路リソース管理テーブルＴ５を更新して経路リソースを確保する（ステップＳ１９）。
【００６６】
次いで、受付制御サーバ１０は、サーバリソース管理テーブルＴ２における上記映像コンテンツＣ１配信元の映像配信サーバ３ａ１の使用帯域に対して、今回の映像コンテンツＣ１の必要帯域を加算してサーバリソース管理テーブルＴ２を更新してサーバリソースを確保する（ステップＳ２０）。
【００６７】
続いて、受付制御サーバ１０は、配信要求送信元のクライアント５ａ１のセッション情報として、そのクライアント５ａ１のクライアントＩＰアドレス、配信要求に対応する映像コンテンツＣ１の配信元である映像配信サーバ３ａ１のサーバ番号、その映像コンテンツＣ１の配信ルートに対応する各経路の経路番号、映像コンテンツＣ１の使用帯域およびその映像コンテンツＣ１の再生時間を互いに関連付けてセッション管理テーブルＴ６に追加登録する（ステップＳ２１）。
【００６８】
そして、受付制御サーバ１０は、配信要求に対応する映像コンテンツＣ１の配信元である映像配信サーバ３ａ１に対応するＲＴＳＰプロキシサーバ２ａ１のＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ；通信ネットワークＮＷを経由してＲＴＳＰプロキシサーバ２ａ１を指定する際のアドレス）をＷＷＷポータルサーバ７に通知して（ステップＳ２２）、処理を終了する。
【００６９】
ＷＷＷポータルサーバ７は、受付制御サーバ１０からＲＴＳＰプロキシサーバのＵＲＬが送信されてきた場合（ステップＳ２２参照）、受付可否判断がＯＫであると判断して、配信要求送信元のクライアント５ａ１に対してＲＴＳＰプロキシサーバのＵＲＬを返送する（図２；処理▲３▼参照）。
【００７０】
一方、受付制御サーバ１０からＮＧ結果通知が送信されてきた場合（ステップＳ１５参照）、受付可否判断がＮＧであると判断して、配信要求送信元のクライアント５ａ１に対して、現在、配信要求に対応する映像コンテンツＣ１が視聴できない（視聴ＮＧである）ことを通知して（図２；処理▲３▼参照）、クライアント５ａ１の配信要求を拒否する。
【００７１】
クライアント５ａ１は、受付制御サーバ１０からＲＴＳＰプロキシサーバ２ａ１のＵＲＬを受け取ると、プレーヤＰを起動し、このプレーヤＰに基づくクライアント５ａ１のＲＴＳＰコマンドとしてＲＴＳＰ再生要求コマンド（ＲＴＳＰに基づく映像コンテンツの再生要求メソッドを含むコマンド）を、そのＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対して送信する（図２；処理▲４▼参照）。
【００７２】
ＲＴＳＰプロキシサーバ２ａ１は、送信されてきたＲＴＳＰコマンドを受信し（図１２；ステップＳ３０）、そのＲＴＳＰコマンドからクライアント５ａ１のクライアントＩＰアドレスおよびメソッドを抽出し（ステップＳ３１）、抽出したメソッドに基づいてＲＴＳＰコマンドが再生要求、すなわち、再生開始を表す開始コマンドおよび終了要求、すなわち、再生終了を表す終了コマンドか否かを判断する（ステップＳ３２）。
【００７３】
今、ＲＴＳＰコマンドは、ＲＴＳＰに基づく映像コンテンツの再生要求メソッドを含むコマンドであるため、ステップＳ３２の判断の結果はＹＥＳとなり、ＲＴＳＰプロキシサーバ２ａ１は、対応するクライアント５ａ１のＩＰアドレスを含む視聴開始イベントを受付制御サーバ１０に送信する（ステップＳ３３および図２；処理▲６▼参照）。
【００７４】
受付制御サーバ１０は、送信されてきた視聴開始イベントを受信し（図１０；ステップＳ１参照）、このイベントの受信相手（送信元）はＲＴＳＰプロキシサーバ２ａ１であるため、ステップＳ２の判断の結果は”ＲＴＳＰプロキシサーバの場合”となり、受付制御サーバ１０は、受信したイベントが視聴開始イベントか視聴終了イベントかを判断する（図１０；ステップＳ４）。
【００７５】
今、送信されてきたイベントは視聴開始イベントであるため、ステップＳ４の判断の結果は”開始イベントの場合”となり、受付制御サーバ１０は、視聴開始通知処理を実行する（図１０；ステップＳ５）。
【００７６】
すなわち、受付制御サーバ１０は、受信した視聴開始イベントのクライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６から上記クライアントＩＰアドレスに対応するセッション情報を検索し（ステップＳ４０）、検索したセッション情報に対して現在時刻（視聴開始時刻）を追加して当該セッション情報を更新登録する（ステップＳ４１）。
【００７７】
すなわち、図８に示すように、クライアント５ａ１に対応するクライアントＩＰアドレス（１０．６．１．１／２４）に対応するサーバ番号（映像配信サーバ３ａ１）、経路番号（経路Ｒ１、経路Ｒ４、経路Ｒ８、経路Ｒ１０）、使用帯域（６Ｍｂｐｓ）、再生時間（２時間）から構成されたセッション情報に対して視聴開始時刻（１８時４１分５０秒）が追加される。
【００７８】
一方、ステップＳ３４の処理において、ＲＴＳＰプロキシサーバ２ａ１は、ＲＴＳＰコマンドに含まれるＲＴＳＰプロキシサーバ２ａ１のＵＲＬの一部のサーバ番号を検索キーとしてＵＲＬ変換テーブルＴ１０を検索し、ＲＴＳＰプロキシサーバ２ａ１の配下の映像配信サーバ３ａ１のＵＲＬを取得し、そのＵＲＬの値を変換し、次いで、ＲＴＳＰコマンド（ＲＴＳＰ再生要求コマンド）のコンテンツ配信要求（Ｄｅｓｔｉｎａｔｉｏｎ）の値をクライアント５ａ１のＩＰアドレスの値に変換し、変換したＲＴＳＰコマンドを映像配信サーバ３ａ１に対して送信する（ステップＳ３５および図２：処理▲５▼参照）。
【００７９】
このとき、映像配信サーバ３ａ１は、送信されてきたＲＴＳＰコマンドを受信し、そのＲＴＳＰコマンドにおけるコンテンツ配信宛先（Ｄｅｓｔｉｎａｔｉｏｎ）として指定されたクライアント５ａ１のＩＰアドレスに対して映像コンテンツＣ１（映像ストリーム）を配信（ダウンロード）する（図２；処理▲７▼参照）。
【００８０】
すなわち、ＲＴＳＰプロキシサーバ２ａ１に対して送信されたＲＴＳＰコマンドは、その宛先が変換された状態で中継されて対応する映像配信サーバ３ａ１に対して送信されるようになっており、そのＲＴＳＰコマンド（ＲＴＳＰ再生要求コマンド）に対応する映像コンテンツＣ１は、映像配信サーバ３ａ１から直接クライアント５ａ１に対して配信されるようになっている。
【００８１】
このとき、クライアント５ａ１では、そのプレーヤＰに基づく再生処理により、ダウンロードされてきた映像コンテンツＣ１は順次再生されるため、ユーザは、配信要求に対応する映像コンテンツＣ１を視聴することができる。
【００８２】
一方、クライアント５ａ１において映像コンテンツＣ１の再生が終了すると、クライアント５ａ１は、プレーヤＰに基づいてＲＴＳＰ終了要求コマンド（ＲＴＳＰに基づく映像コンテンツの終了要求メソッドを含むコマンド）を、そのＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対して送信する（図２；処理▲８▼参照）。
【００８３】
ＲＴＳＰプロキシサーバ２ａ１は、送信されてきたＲＴＳＰコマンドを受信し（図１２、ステップＳ３０参照）、そのＲＴＳＰコマンドからクライアント５ａ１のクライアントＩＰアドレスおよびメソッドを抽出し（ステップＳ３２参照）、抽出したメソッドに基づいてＲＴＳＰコマンドが再生要求、すなわち、再生開始を表す開始コマンドおよび終了要求、すなわち、再生終了を表す終了コマンドか否かを判断する（ステップＳ３２参照）。
【００８４】
今、ＲＴＳＰコマンドは、ＲＴＳＰに基づく映像コンテンツの終了要求メソッドを含むコマンドであるため、ステップＳ３２の判断の結果はＹＥＳとなり、ＲＴＳＰプロキシサーバ２ａ１は、対応するクライアント５ａ１のＩＰアドレスを含む視聴終了イベントを受付制御サーバ１０に送信する（ステップＳ３３）。
【００８５】
【外１】
このとき、受付制御サーバ１０は、送信されてきた視聴終了イベントを受信し（図１０；ステップＳ１参照）、このイベントの受信相手（送信元）はＲＴＳＰプロキシサーバ２ａ１であるため、ステップＳ２の判断の結果は”ＲＴＳＰプロキシサーバの場合”となり、受付制御サーバ１０は、受信したイベントが視聴開始イベントか視聴終了イベントかを判断する（図９；ステップＳ４参照）。
【００８７】
今、送信されてきたイベントは視聴終了イベントであるため、ステップＳ４の判断の結果は”終了イベントの場合”となり、受付制御サーバ１０は、視聴終了通知処理を実行する（図１０；ステップＳ６）。
【００８８】
すなわち、受付制御サーバ１０は、送信されてきた視聴終了イベントを受信し（図１４；ステップＳ５０）、クライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６を検索し、セッション管理テーブルＴ６におけるクライアントＩＰアドレスに対応するセッション情報（クライアントＩＰアドレスに対応する映像コンテンツ配信元のサーバ番号、配信ルートに対応する複数の経路それぞれの経路番号、映像コンテンツの使用帯域等）を取得し（ステップＳ５１）、映像コンテンツＣ１の必要帯域を経路リソース管理テーブルＴ５における対応する複数の経路番号の使用帯域からそれぞれ減算して、上記配信ルートのネットワークリソースを開放する（ステップＳ５２）。
【００８９】
ステップＳ５２の前後において、受付制御サーバ１０は、映像コンテンツＣ１の必要帯域を、サーバリソース管理テーブルＴ２における取得したサーバ番号に対応する映像配信サーバの使用帯域から減算して、上記映像配信サーバ３ａ１のサーバリソースを開放する（ステップＳ５３）。
【００９０】
続いて、受付制御サーバ１０は、クライアント５ａ１のクライアントＩＰアドレスを検索キーとしてセッション管理テーブルＴ６を検索し、このテーブルＴ６から、対応するクライアント５ａ１のセッション情報を削除する（ステップＳ５４）。
【００９１】
一方、ステップＳ３３の前後において、ＲＴＳＰプロキシサーバ２ａ１は、ＲＴＳＰコマンドに含まれるＲＴＳＰプロキシサーバ２ａ１のＵＲＬを検索キーとしてサーバ番号／ＵＲＬ変換テーブルＴ１０を検索し、ＲＴＳＰプロキシサーバ２ａ１のＵＲＬに対応する映像配信サーバ３ａ１のサーバ番号を取得し、上記ＲＴＳＰコマンド（ＲＴＳＰ終了要求コマンド）をクライアント５ａ１をコンテンツ配信宛先（Ｄｅｓｔｉｎａｔｉｏｎ）とするＲＴＳＰコマンド（ＲＴＳＰ終了要求コマンド）に変換し（ステップＳ３４参照）、変換したＲＴＳＰコマンドを、取得したサーバ番号に対して送信する（ステップＳ３５および図２▲９▼参照）。
【００９２】
このとき、映像配信サーバ３ａ１は、送信されてきたＲＴＳＰコマンドを受信し、クライアント５ａ１のＩＰアドレスに対する映像コンテンツＣ１（映像ストリーム）の配信を終了する。
【００９３】
すなわち、クライアント５ａ１からの終了要求に応じて、クライアント５ａ１に対する映像コンテンツＣ１の配信が終了される。
【００９４】
以上述べたように、本実施形態によれば、映像コンテンツ配信元の映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域を含むサーバリソース情報、および通信ネットワークＮＷを経由した通信経路（経路Ｒ１〜Ｒ１１）の最大帯域および使用帯域を含むＮＷリソース情報を受付制御サーバ１０によりそれぞれリアルタイムで監視し、サーバリソース管理テーブルＴ２および経路リソース管理テーブルＴ５により管理している。
【００９５】
このため、クライアント５ａ１からの映像コンテンツ配信要求に対して、その配信元の映像配信サーバ３ａ１の現在のサーバリソース情報および通信ネットワークＮＷを経由したクライアント端末５ａ１と映像配信サーバ３ａ１との間の最適ルートのＮＷリソース情報とを考慮して、その配信要求の受付可否判断を行うことができる。
【００９６】
すなわち、コンテンツ配信元の映像配信サーバ３ａ１の現在のサーバリソース情報に基づいて、そのサーバ３ａ１による配信要求に対応する映像コンテンツの配信が不可と判断された場合には、その配信要求の受付を拒否することができ、また、通信ネットワークＮＷを経由したクライアント端末５ａ１と映像配信サーバ３ａ１との間の最適ルートのＮＷリソース情報に基づいて、その最適ルートによる配信要求に対応する映像コンテンツの配信が不可と判断された場合には、上記配信要求の受付を拒否することができる。
【００９７】
この結果、映像コンテンツ配信元である映像配信サーバ３ａ１および映像コンテンツ配信先であるクライアント５ａ１間のエンドツーエンドでのＱｏＳを保証した映像配信サービスを提供することができる。
【００９８】
（実施例）
本実施の形態に係わるストリーミングコンテンツ配信システム１におけるＲＴＳＰプロキシサーバによる映像コンテンツ視聴終了時のリソース開放のリアルタイム性を検証するため、ストリーミングコンテンツ配信システム１のプロトタイプを作成し、作成したストリーミングコンテンツ配信システム１（プロトタイプ）におけるリソース開放処理時間の測定を行った。
【００９９】
この測定結果を図１５に示した。
【０１００】
図１５に示すように、ユーザ１００人（クライアント１００台）が同時に映像コンテンツの視聴を終了した場合、約１０秒以内にリソース開放を行えることが確認できた。
【０１０１】
すなわち、本実施形態に係わるＲＴＳＰプロキシサーバによるコンテンツ視聴終了検知方式は、映像配信サーバのログを収集する方式と比べてリアルタイム性があり、通信ネットワークＮＷおよび映像配信サーバのリソースの利用効率を向上させることができる。
【０１０２】
また、上記ストリーミングコンテンツ配信システム１のプロトタイプにおいて、ＲＴＳＰプロキシサーバの処理性能を測定した結果、図１６に示すように、このＲＴＳＰプロキシサーバによりＲＴＳＰコマンドを中継することによる遅延は、同時アクセス１００ユーザ（クライアント１００台）で最大０．５秒程度に収まる結果となり、ＲＴＳＰプロキシサーバによる遅延の影響がほとんど無いことが確認できた。
【０１０３】
すなわち、本実施形態に係わるＲＴＳＰプロキシサーバによるＲＴＳＰコマンド中継方式を用いた場合でも、映像コンテンツ配信のリアルタイム性に対してほとんど影響を与えることがなく、ＱｏＳおよび配信リアルタイム性をそれぞれ高く維持することができる。
【０１０４】
なお、本実施形態では、ストリーミングコンテンツを映像コンテンツとしたが、例えば音楽コンテンツ等の他のストリーミングコンテンツであっても適用可能である。
【０１０５】
また、本実施の形態では、受付制御サーバ１０および各ＲＴＳＰプロキシサーバ２ａ１、２ａ２によりストリーミングコンテンツ配信要求受付制御システム２５を構成したが、本発明はこの構成に限定されるものではなく、受付制御サーバ１０および少なくとも１つのＲＴＳＰプロキシサーバによりストリーミングコンテンツ配信要求受付制御システム２５を構成することができる。また、少なくとも１つのＲＴＳＰプロキシサーバの機能を受付制御サーバ１０にプログラムとして実装することにより、受付制御サーバによりストリーミングコンテンツ配信要求受付制御システム２５を構成することも可能である。
【０１０６】
また、本実施形態におけるＲＴＳＰプロキシサーバを用いた映像コンテンツ視聴開始イベントおよび終了イベント検知方式は、ＲＴＳＰプロトコルを実装した複数ベンダーの映像配信サーバに対して適用可能である。
【０１０７】
さらに、本実施形態では、各クライアントに対してＩＰアドレスが固定割当されている場合について説明したが、本発明はこの構成に限定されるものではなく、クライアントに対してＩＰアドレスを動的に割り当てる場合においても適用可能である。
【０１０８】
このＩＰアドレス動的割当方式の場合、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）サーバを用いて、ＩＰアドレスを各クライアントに対して動的に割り当てることができる。この場合、受付制御サーバがＲＡＤＩＵＳサーバと連携し、そのＲＡＤＩＵＳサーバにより各クライアントに割り当てたＩＰアドレスを受付制御サーバに通知することにより、上記ＩＰアドレスの動的割当に対しても対応可能である。
【０１０９】
また、本実施形態では、各映像配信サーバ３ａ１、３ａ２の現在の使用可能帯域に関連するサーバリソースとして、上記各映像配信サーバ３ａ１、３ａ２の最大帯域および使用帯域をそれぞれ監視して管理したが、本発明はこの構成に限定されるものではなく、各映像配信サーバ３ａ１、３ａ２の残帯域（最大帯域−使用帯域）を監視および管理してもよい。
【０１１０】
同様に、各通信経路Ｒ１〜Ｒ１１の現在の使用可能帯域に関連するネットワークリソースとして、その各通信経路Ｒ１〜Ｒ１１の最大帯域および使用帯域をそれぞれ監視したが、本発明はこの構成に限定されるものではなく、各通信経路Ｒ１〜Ｒ１１の残帯域（最大帯域−使用帯域）を監視および管理してもよい。
【０１１１】
そして、本実施形態では、クライアントおよび映像配信サーバ間の最適ルートは、クライアントが所属するサブネットワークのサブネット番号と映像配信サーバが所属するエッジのエッジ番号とが決定されれば一意に定まるものとして説明したが、本発明はこの構成に限定されるものではなく、例えばＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ：ルータの接続数ではなく、通信ネットワークＮＷに関連する各経路Ｒ１〜Ｒ１１の帯域幅等に基づいた「コスト」という値により計算を行い、最小のコストで到達できるルートを最適ルートとして選択するルーティングアルゴリズム）等の最適ルート決定アルゴリズムによりダイナミックルーティングしてもよい。この場合、上記最適ルート決定アルゴリズムに基づくプログラムを受付制御サーバのメモリに実装し、上記最適ルート決定アルゴリズムに基づくプログラムにより受付制御サーバを動作させることにより、対応可能である。
【０１１２】
さらに、本実施形態では、クライアントのストリーミングコンテンツ再生用プレーヤがＲＴＳＰコマンドの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）指定機能を実装しているものとしたが、本発明はこの構成に限定されるものではなく、ＲＴＳＰプロキシサーバにおいて、ＲＴＳＰコマンドの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）にクライアントのＩＰアドレスを指定させるようにしてもよい。
【０１１３】
【発明の効果】
以上述べたように、本発明に係わるストリーミングコンテンツ配信要求受付制御システムによれば、配信サーバの現在の使用可能帯域に関連する帯域リソース情報、および通信ネットワーク上の複数の中継点、前記クライアント端末および前記配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報をそれぞれ監視することにより、クライアント端末からのストリーミングコンテンツ配信要求に対して、その配信元の配信サーバの現在のサーバリソース情報および通信ネットワークＮＷを経由したクライアント端末と配信サーバとの間の最適ルートのネットワークリソース情報とを考慮して、その配信要求の受付可否判断を行うことができる。
【０１１４】
したがって、ストリーミングコンテンツ配信元の配信サーバおよびストリーミングコンテンツ配信要求元であるクライアント端末間のエンドツーエンドでのＱｏＳを保証した映像配信サービスを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるストリーミングコンテンツ配信要求受付制御システムを含むストリーミングコンテンツ配信システムの概略構成を示す図。
【図２】図１に示すストリーミングコンテンツ配信要求受付制御システムの概略構成およびストリーミングコンテンツ配信システムの全体処理をそれぞれ示す図。
【図３】図２に示すクライアント管理テーブルの概略構成を示す図。
【図４】図２に示すサーバリソース管理テーブルの概略構成を示す図。
【図５】図２に示すコンテンツ管理テーブルの概略構成を示す図。
【図６】図２に示す経路管理テーブルの概略構成を示す図。
【図７】図２に示す経路リソース管理テーブルの概略構成を示す図。
【図８】図２に示すセッション管理テーブルの概略構成を示す図。
【図９】図２に示すＵＲＬ変換テーブルの概略構成を示す図。
【図１０】図１および図２に示す受付制御サーバの処理の一例を示す概略フローチャート。
【図１１】図１０に示す受付可否処理を詳細に説明するためのフローチャート。
【図１２】図１および図２に示すＲＴＳＰプロキシサーバの処理の一例を示す概略フローチャート。
【図１３】図１０に示す視聴開始通知処理を詳細に説明するためのフローチャート。
【図１４】図１０に示す視聴終了通知処理を詳細に説明するためのフローチャート。
【図１５】本発明の実施の形態に係わるストリーミングコンテンツ配信システムのプロトタイプを用いたリソース開放処理時間の測定結果を表す図。
【図１６】本発明の実施の形態に係わるストリーミングコンテンツ配信システムのプロトタイプを用いたＲＴＳＰプロキシサーバの処理性能の測定結果を表す図。
【符号の説明】
１ ストリーミングコンテンツ配信システム
２ａ１、２ａ２ ＲＴＳＰプロキシサーバ
３ａ１、３ａ２ 映像配信サーバ
５ａ１、５ａ２ クライアント端末
７ ＷＷＷポータルサーバ
１０ 受付制御サーバ
１１ リソースデータベース
１５ａ１〜１５ａ５ ルータ
２１ サーバリソース監視部
２２ ネットワークリソース監視部
２５ ストリーミングコンテンツ配信要求受付制御システム
Ｔ１ クライアント管理テーブル
Ｔ２ サーバリソース管理テーブル
Ｔ３ コンテンツ管理テーブル
Ｔ４ 経路管理テーブル
Ｔ５ 経路リソース管理テーブル
Ｔ６ セッション管理テーブル
Ｔ１０ ＵＲＬ変換テーブル
Claims (8)
- 配信サーバから通信ネットワーク経由で配信可能なストリーミングコンテンツの配信要求がクライアント端末から当該通信ネットワークを介して送信されてきた際に、そのストリーミングコンテンツ配信要求の受付を制御するためのストリーミングコンテンツ配信要求受付制御システムであって、
前記配信サーバの現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視手段と、
前記通信ネットワーク上の複数の中継点、前記クライアント端末および前記配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視手段と、
を備えたことを特徴とするストリーミングコンテンツ配信要求受付制御システム。 - 前記サーバリソース監視手段は、監視した前記配信サーバの帯域リソース情報を当該配信サーバの識別情報に関連付けて管理する配信サーバリソース管理手段を備え、
前記ネットワークリソース監視手段は、監視した前記複数の通信経路それぞれのネットワークリソース情報を当該複数の通信経路それぞれの経路識別情報に関連付けて管理するネットワークリソース管理手段を備えたことを特徴とする請求項１記載のストリーミングコンテンツ配信要求受付制御システム。 - 前記通信ネットワーク上における前記配信サーバおよび前記配信要求送信元のクライアント端末間の最適ルートとして設定された複数の通信経路それぞれの経路識別情報を前記配信サーバおよびクライアント端末に関連付けて記憶する経路管理手段を備えたことを特徴とする請求項１または２記載のストリーミングコンテンツ配信要求受付制御システム。
- 前記クライアント端末から送信されてきた配信要求に対応するストリーミングコンテンツの必要帯域、前記配信サーバの帯域リソース情報、前記複数の通信経路それぞれのネットワークリソース情報および前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報に基づいて、当該配信要求を受け付けるか否かを判断する受付可否判断手段をさらに備えたことを特徴とする請求項３記載のストリーミングコンテンツ配信要求受付制御システム。
- 前記受付可否判断手段は、前記配信サーバの帯域リソース情報から当該配信サーバの使用可能帯域を把握し、把握した使用可能帯域と前記受信した配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第１の比較判断手段を備えたことを特徴とする請求項４記載のストリーミングコンテンツ配信要求受付制御システム。
- 前記受付可否判断手段は、前記第１の比較判断手段により前記配信要求が受付可能であると判断された際に、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報および前記複数の通信経路それぞれのネットワークリソース情報から当該パスを構成する複数の通信経路それぞれの使用可能帯域を把握し、把握したそれぞれの使用可能帯域と前記配信要求に対応するストリーミングコンテンツの必要帯域とを用いた比較処理により当該配信要求を受け付けるか否か判断する第２の比較判断手段をさらに備えたことを特徴とする請求項５記載のストリーミングコンテンツ配信要求受付制御システム。
- 前記受付可否判断手段により前記配信要求が受付られた場合において、当該配信要求に対応するクライアント端末の識別情報、前記配信サーバの識別情報、前記最適ルートとして設定された複数の通信経路それぞれの経路識別情報、当該配信要求に対応するストリーミングコンテンツの必要帯域および当該ストリーミングコンテンツの再生時間を互いに関連付けて当該クライアント端末のセッション情報として記憶するセッション情報記憶手段をさらに備えたことを特徴とするストリーミングコンテンツ配信要求受付制御システム。
- 前記受付可否判断手段により前記配信要求が受付られた場合において、前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの再生要求コマンドを受信し、受信した再生要求コマンドを中継して前記配信サーバに送信する第１の中継手段と、
前記ストリーミングコンテンツの再生要求コマンドの受信に応じて、当該ストリーミングコンテンツの視聴開始時刻を表す視聴開始時刻情報を前記セッション情報に関連付けて記録する視聴開始時刻記録手段と、
前記クライアント端末から、前記ストリーミングコンテンツ用通信プロトコルに基づく前記ストリーミングコンテンツの終了要求コマンドを受信し、受信した終了要求コマンドを中継して前記配信サーバに送信する第２の中継手段と、
前記ストリーミングコンテンツの終了要求コマンドの受信に応じて、前記セッション情報を削除するセッション情報削除手段と、
をさらに備えたことを特徴とする請求項７記載のストリーミングコンテンツ配信要求受付制御システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080743A JP2004289627A (ja) | 2003-03-24 | 2003-03-24 | ストリーミングコンテンツ配信要求受付制御システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003080743A JP2004289627A (ja) | 2003-03-24 | 2003-03-24 | ストリーミングコンテンツ配信要求受付制御システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004289627A true JP2004289627A (ja) | 2004-10-14 |
Family
ID=33294517
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003080743A Pending JP2004289627A (ja) | 2003-03-24 | 2003-03-24 | ストリーミングコンテンツ配信要求受付制御システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004289627A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008035398A1 (fr) | 2006-09-19 | 2008-03-27 | Nec Corporation | Système de distribution de contenu, dispositif intermédiaire de commande de bande passante et procédé de commande de bande passante |
| JP2013520119A (ja) * | 2010-02-19 | 2013-05-30 | トムソン ライセンシング | アダプティブ・ストリーミングのマルチパス配信 |
| JP2016526355A (ja) * | 2013-06-05 | 2016-09-01 | アルカテル−ルーセント | Ｈａｓコンテンツ配信システムに使用するためのノードおよび方法 |
-
2003
- 2003-03-24 JP JP2003080743A patent/JP2004289627A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008035398A1 (fr) | 2006-09-19 | 2008-03-27 | Nec Corporation | Système de distribution de contenu, dispositif intermédiaire de commande de bande passante et procédé de commande de bande passante |
| JP2013520119A (ja) * | 2010-02-19 | 2013-05-30 | トムソン ライセンシング | アダプティブ・ストリーミングのマルチパス配信 |
| US10034048B2 (en) | 2010-02-19 | 2018-07-24 | Thomson Licensing Dtv | Multipath delivery for adaptive streaming |
| JP2016526355A (ja) * | 2013-06-05 | 2016-09-01 | アルカテル−ルーセント | Ｈａｓコンテンツ配信システムに使用するためのノードおよび方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4113115B2 (ja) | 移動機通信システムおよび通信方法 | |
| JP4500542B2 (ja) | モバイルＩＰネットワークにおけるポリシーに基づくＵＭＴＳのＱｏＳとＩＰのＱｏＳ管理のためのメカニズム | |
| JP3486125B2 (ja) | ネットワーク機器制御システム及び装置 | |
| JP3816390B2 (ja) | サービス割り当て装置 | |
| CN109831548B (zh) | 虚拟内容分发网络vCDN节点建立方法及服务器 | |
| WO2006000627A1 (en) | Method for service chaining in a communication network | |
| JP2002091843A (ja) | サーバ選択装置、サーバ選択方法、及びサーバ選択プログラムを記録した記録媒体 | |
| US20020048264A1 (en) | Network management method, apparatus of same and network systems | |
| WO2012065531A1 (zh) | 实现中继选择的方法及装置、系统 | |
| JP2011228864A (ja) | トラヒック制御指示装置、トラヒック制御指示プログラム、トラヒック制御指示システム、及びトラヒック制御指示方法 | |
| WO2007082448A1 (fr) | Procédé de qualité de service (qos) garantie, dispositif de gestion de ressources et système d'accès multi-services | |
| JP2000312226A (ja) | 通信品質を保証する方法 | |
| Park et al. | Smart base station-assisted partial-flow device-to-device offloading system for video streaming services | |
| JP2012118709A (ja) | 配信システム、ストレージ容量決定プログラム、及びストレージ容量決定方法 | |
| CN110445723A (zh) | 一种网络数据调度方法及边缘节点 | |
| KR102376496B1 (ko) | 서비스 스트림 분산 포워딩 시스템 및 그 방법 | |
| JP6287859B2 (ja) | 通信ノード、制御装置、制御情報エントリの管理方法及びプログラム | |
| US20040028062A1 (en) | Controlling service stream | |
| JP2004348495A (ja) | パーソナルストレージサービス提供方法 | |
| JP4391960B2 (ja) | リソース管理装置、システムおよび方法 | |
| JP2019169783A (ja) | 経路制御システム、経路制御方法、及び、プログラム | |
| US7711780B1 (en) | Method for distributed end-to-end dynamic horizontal scalability | |
| JP2004289627A (ja) | ストリーミングコンテンツ配信要求受付制御システム | |
| US8305918B2 (en) | Method of configuring the quality-of-service profile of a given stream at an access node of a packet communications network | |
| JP2004096380A (ja) | 経路制御装置及び経路制御システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041122 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070306 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070619 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070813 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080115 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080310 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080408 |