コンテンツオンデマンド方法およびそのためのネットワーク
複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備えるシステムにおいて、ユーザ端末にコンテンツオンデマンドサービスを提供する方法が提供される。この方法は、コンテンツオンデマンドサーバのうちの第１のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス配信を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、前記第１のサーバが、リソース予約が不十分であったというメッセージを送るステップと、コンテンツオンデマンドサーバのうちの別のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス提供を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、前記別のサーバが、リソース予約が十分であるというメッセージを送るステップと、前記別のサーバが、パケット交換ネットワークを経由して、ユーザ端末にコンテンツを提供するステップとを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信に関し、詳細には、ビデオなどのコンテンツの配信システムに関する。
【背景技術】
【０００２】
図１に示すように、インタラクティブインターネットプロトコルテレビＩＰＴＶなど、ビデオサービスを提供するための知られているネットワークでは、アプリケーションサーバＡＳは、そのインターフェースを経由して、中央リソース受付制御サブシステム（Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）（ＲＡＣＳ）サーバに接続される。このアプリケーションサーバは、それを経由して、当該アプリケーションサーバが、ＲＡＣＳサーバに接続されるリソース受付制御（ＲＡＣ）インターフェースを含む。このアプリケーションサーバは、説明を簡単にするために、そのうちの１つだけが図１に示されるコンテンツオンデマンド（ＣｏＤ）サーバにも接続される。
【０００３】
使用の際、このアプリケーションサーバは、（テレビセットに接続されたセットトップボックスまたは画面表示を含むデジタル移動体ハンドセットなどのユーザ機器ＵＥとして示される）ユーザ端末からコンテンツオンデマンド（ＣｏＤ）サービス要求を受信する。この要求は、ＲＡＣＳサーバに渡され、ＲＡＣＳサーバは、次いで、インターネットプロトコルネットワークの適切なリソースを予約することを要求する。リソースが予約され得る場合、ＲＡＣＳサーバは、当該アプリケーションサーバにリソース予約肯定応答を送り、次いで、当該アプリケーションサーバは、サービス要求の肯定応答および当該サービスを供給するために選択されたＣｏＤサーバの識別アドレスの両方を転送する。この情報は、ユーザ端末が、次いで、コンテンツオンデマンドセッションを確立することを要求することを可能にする。したがって、ＲＡＣＳサーバは、リソース予約機能および受付制御機能の両方を処理することを理解されよう。
【０００４】
知られている手法において、ＲＡＣＳサーバに対するインターフェースは、当該アプリケーションサーバ内にあってよく、またはその代わりに、ＣｏＤサーバ内にあってもよいが、いずれの場合も、中央ＲＡＣＳサーバと交信する。中央ＲＡＣＳサーバは、適切なＩＰネットワークリソースを予約する際に効果的であるように、ネットワークトポロジの詳細な知識を要求する。
【発明の概要】
【課題を解決するための手段】
【０００５】
添付の独立請求項を参照されたい。いくつかの好ましい特徴が従属請求項に提示される。
【０００６】
本発明の例は、複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備えるシステムにおいて、ユーザ端末にコンテンツオンデマンドサービスを提供する方法である。この方法は、
コンテンツオンデマンドサーバのうちの第１のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス配信を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記第１のサーバが、リソース予約が不十分であったというメッセージを送るステップと、
コンテンツオンデマンドサーバのうちの別のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス提供を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記別のサーバが、リソース予約が十分であるというメッセージを送るステップと、
前記別のサーバが、パケット交換ネットワークを経由して、ユーザ端末に当該コンテンツを提供するステップとを備える。
【０００７】
その好ましい実施形態では、ＣｏＤサーバは、リソース予約を行うように構成される。あるＣｏＤサーバが予約を行うことができない場合、代わりに、別のＣｏＤサーバが予約を行うことを要求される。このコンテンツは、ビデオであることが好ましい。
【０００８】
サーバが予約を行うことを要求される順序は、優先リストに従ってよい。このリストは、サーバの動作履歴を考慮に入れるよう適応可能であり得る。
【０００９】
その好ましい実施形態では、本発明は、ビデオコンテンツオンデマンド（ＣｏＤ）サービスなど、インタラクティブインターネットプロトコルテレビ（ＩＰＴＶ）サービスに関するリソース予約のための、回復性および適応性のある機構を提供する。
【００１０】
好ましい実施形態は、中央ＲＡＣＳサーバの使用を回避し、代わりに、リソース予約制御機能性を配信するため、発明者は、先行技術と比較して、好ましい実施形態は有利であろうことを理解した。これは、考えられる主な障害点を除去し、集中型サーバの要件、すなわち、ネットワークトポロジの正確な知識を有するかどうかを不要にした。
【００１１】
次に、図面を参照して、本発明の実施形態が例として説明される。
【図面の簡単な説明】
【００１２】
【図１】インタラクティブＩＰＴＶサービス（先行技術）に関して知られているネットワークを例示する図である。
【図２】本発明の第１の実施形態による、インタラクティブＩＰＴＶサービスに関するネットワークを例示する図である。
【図３】図２に示されるネットワークにおいて、要求されるサービスを提供するように、ネットワークリソースを予約することを例示するメッセージシーケンス図である。
【図４】図２に示されたネットワークにおいて、リソースがどのように予約されるかのさらなる詳細を示す、さらなるメッセージシーケンス図である。
【図５】本発明の第２の実施形態による、インタラクティブＩＰＴＶサービスに関するネットワークを例示する図である。
【発明を実施するための形態】
【００１３】
知られているシステムを考慮するとき、発明者は、中央ＲＡＣＳサーバを除去して、代わりに、関連する機能性を処理するために、コンテンツオンデマンドＣｏＤサーバを適応することが有用であろうことを理解した。
【００１４】
ネットワーク
図２に示すように、インタラクティブＩＰＴＶサービスに関するネットワーク２は、ユーザ端末ＵＥ６に接続可能なアプリケーションサーバＡＳ４からなる。ユーザ端末は、リソース受付制御（ＲＡＣ）インターフェース１０を含む制御プロトコルリダイレクタ（Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｒｅｄｉｒｅｃｔｏｒ）８にも接続可能である。このインターフェース１０は、一連のコンテンツオンデマンドＣｏＤサーバ、ＣｏＤ１、．．．、ＣｏＤｎ１２に接続される。この例では、それぞれのＣｏＤサーバは、デジタルマルチメディアコンテンツ、例えば、ビデオコンテンツを提供し、ビデオコンテンツオンデマンドサーバまたはビデオオンデマンドサーバと呼ばれる場合もある。それぞれのＣｏＤサーバ１２は、リソース受付制御（ＲＡＣ）コントローラ１４を含む。それぞれの制御プロトコルリダイレクタ８は、ＣｏＤサーバのリストが格納されるリレーショナルデータベース管理システム（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）（ＲＤＢＭＳ）１６にも接続される。ユーザ端末ＵＥ６は、インターネットプロトコルネットワーク１８を経由してＣｏＤサーバ１２に接続される。
【００１５】
動作
図３に示すように、ネットワーク２は、以下のように動作する。
【００１６】
ユーザ端末６は、まず、アプリケーションサーバ４に、ビデオフィルム、スポーツイベントまたはその他のマルチメディアコンテンツの記録など、特定のビデオストリームに対する要求を送る（ステップａ）。アプリケーションサーバ４は、移動体端末６にサービス要求許可を送ることによって応答し（ステップｂ）、次いで、移動体端末６は、選択されたコンテンツが当該ユーザによって所望されるものであるという確認をアプリケーションサーバ４に送り返す（ステップｃ）。
【００１７】
アプリケーションサーバ４は、次いで、移動体端末６にサービス入口点（ＳＥＰ）を送る（ステップｄ）。ＳＥＰは、制御プロトコルリダイレクタ８を識別し、次いで、移動体端末６は、サービスに対して許可された要求を制御プロトコルリダイクタ８に送る。それに応じて、移動体端末６は、その要求を送る（ステップｅ）。
【００１８】
ユーザ端末を識別するその要求を受信すると、制御プロトコルリダイレクタ８は、当該ユーザ端末に当該サービスを提供するために、（メタデータ記憶装置とみなされ得る）ＲＤＢＭＳ内の候補ＣｏＤサーバ１２のリストをリアルタイムで調べて（ステップｆ）、明らかに最も適しているサーバを選択する。
【００１９】
ＣｏＤサーバの選択
どのＣｏＤサーバに、特定のサービス要求に対応することを要求するかを選択するために使用される簡単な手法は、２個以上のＣｏＤサーバが、場合によっては、要求されたサービスをユーザ端末６に提供することが可能であるが、そのそれぞれのＣｏＤサーバは、特定の地理的位置からの要求を処理するためのその望ましさに関して、関連する重みを有すると仮定する。例えば、サーバが、例えば、ユーザ端末の現在の位置に対するサーバの近接性に基づいて、好ましくは、ユーザ端末６にサービス提供し得る順序のリストが格納される。制御プロトコルリダイレクタ８は、要求されるサービスを提供するために利用可能なリソースを現在有するＣｏＤサーバが識別されるまで、リストを処理していく。
【００２０】
特に、リスト上の第１のサーバは、当該サービスを提供するために必要なネットワークリソースを予約することが要求される（ステップｇ）。この要求は、アドレス指定されたサーバ１２内のリソース受付コントローラＲＡＣ１４によって受信される。
【００２１】
図４に示すように、ＲＡＣコントローラ１４は、それを経由して、当該コンテンツがユーザ端末６に送られるインターネットプロトコルネットワーク１８の適切なリソースを予約するように、知られているリソースリザベーションプロトコル（Ｒｅｓｏｕｒｃｅ ｒｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）−トラヒックエンジニアリング（ＲＳＶＰ−ＴＥプロトコル）を使用して、ラベル付けされた経路を作成することを要求する。この図に示すように、これは、選択されたＣｏＤサーバ１２が、ＲＳＶＰ−ＴＥ予約要求メッセージを、ユーザ端末６とサーバ１２の間のホップ同士の間で対応するＰＡＴＨメッセージおよびＲＥＳメッセージがセットアップされることが要求されるＩＰネットワーク１８内に送ることによって行われる（ステップｈ）。成功裏のリソース予約が発生した場合、サーバ１２内のＲＡＣコントローラ１４に応えて予約肯定応答メッセージ（ＰＡＴＨメッセージ（ステップｉ）。
【００２２】
再び図３を参照すると、例えばリスト上の第１のサーバに関して、予約は成功しなかったと想像されたい。したがって、制御プロトコルリダイレクタ８には、その特定のサーバがネットワークリソース予約を行うことができなかったことが通知される（ステップｊ）。それに応じて、制御プロトコルリダイレクタ８は、リスト内の次のＣｏＤサーバに、必要なネットワークリソースを予約する要求を送る（ステップｋ）。
【００２３】
このプロセスは、サーバがネットワークリソース予約を成功裏に達成するまで、サーバのリストを処理しながら繰り返される。成功裏のリソース予約が発生するのは、リスト上の第ｎ番目のサーバであると想像されたい（この場合、ｎは、正の整数、例えば２である）。予約肯定応答メッセージ（ＰＡＴＨメッセージ）は、ＩＰネットワーク１８からサーバ１２内のＲＡＣコントローラ１４に送られる（ステップｉ）。この第ｎ番目のサーバ１２内のＲＡＣコントローラ１４は、次いで、リソースが制御プロトコルリダイレクタ８に対して予約されたという肯定応答を送る（ステップｌ）。
【００２４】
次いで、制御プロトコルリダイレクタ８は、リソースを成功裏に予約した特定のサーバ１２からサービスを要求する命令をユーザ端末６に送る（ステップｍ）。すなわち、制御プロトコルリダイレクタ８は、当該コンテンツをユーザ端末８に配信することになるＣｏＤサーバのアドレスを戻す。
【００２５】
次いで、ユーザ端末１２は、当該コンテンツを配信することになるＣｏＤサーバに、サービスに対する要求を送る（ステップｎ）。そのＣｏＤサーバは、選択された映画のデータストリームなど、要求されたビデオサービスを配信することによって、ユーザ端末１２に応答する（ステップｏ）。
【００２６】
別の例示的なシステム
その他の点では、上の図２から図４に関して説明されたものと類似する代替の実施形態では、サービス要求に関して考慮されることになるＣｏＤサーバのリストは、それぞれのＣｏＤサーバに関して、最後の障害からの時間と、その障害を修正するのにかかった時間とをさらに考慮に入れるために適応可能に再度順序付けられる。障害は、ＣｏＤサーバ自体の障害または当該ＣｏＤサーバとユーザ端末の間のネットワーク接続の障害である。例えば、障害を迅速に修正し、最近障害を経験していないＣｏＤサーバは、その他のサーバより好ましい可能性がある。数学的に、
【数１】
とすると、ここで、ｗｋは第ｋ番目のＣｏＤサーバを選択するための選好（すなわち、確率）を示す重みであり、次のＣｏＤサーバｌは、例えば、以下の方程式に従って、選択される。
【数２】
ここで、ｗｋは、第ｋ番目のＣｏＤサーバを選択するための重みであり、ΔＴは、障害を修正するための平均時間であり、Δｔｎは、第ｋ番目のＣｏＤサーバ上で第ｎ番目のリコードされた障害からの時間である。
【００２７】
例えば、ＣｏＤ１に関して０．５、ＣｏＤ２に関して０．３、およびＣｏＤ３に関して０．２の関連する重みを有する３個のビデオサーバＣｏＤ１、ＣｏＤ２、およびＣｏＤ３が現在利用可能であるとしよう。これは、その他の係数を無視して、リスト上のＣｏＤサーバの中で、最高の選好はＣｏＤ１であり、最低の選好はＣｏＤ３であり、したがって、ＣｏＤ１が十分なリソースを有する場合、ＣｏＤ１が選択されることになることを意味する。しかし、これらの重みの考慮事項に加えて、ＣｏＤサーバ選択の一部として、間欠的ネットワーク障害の数が監視および考慮される。真の障害を修正するためには、平均してΔＴがかかることが分かっている。しかし、すべてΔＴ未満に分解する、ネットワーク欠陥（ｎｅｔｗｏｒｋ ｇｌｉｔｃｈｅｓ）によるいくつかの間欠的な短期間障害が存在すると仮定しよう。例えば、ΔＴ＝５時間であり、ＣｏＤ１に関して、故障からの時間が１時間、２時間、および３時間である、３つの間欠的な短期間障害が報告されているとしよう。
【００２８】
そこで、方程式を使用して、ＣｏＤ１に関する初期の重みは：
【数３】
に従って解くと、ＣｏＤ１に関する重みは、
【数４】
になる。
【００２９】
これは、それらの間欠的障害が存在する場合、サーバＣｏＤ１は、もはや最高の重みを有さず、０．３の重みを有するサーバＣｏＤ２が代わりに選択されることになることを意味する。
【００３０】
別の例示的なシステム
図５に示すように、その他の点では、図２に示されたものと類似する別の実施形態は、ユーザ端末と制御プロトコルリダイレクタ８’の間で接続された負荷分散装置（ｌｏａｄ ｂａｌａｎｃｅｒ）段階３０を含む。異なる位置の全体にわたって分散された、または代替の実施形態では、負荷分散装置３０段階の近くに局在化された、制御プロトコルリダイレクタ８’の複数のインスタンス（ｉｎｓｔａｎｃｅｓ）も存在する。リダイレクタ８’はそれぞれ、ＣｏＤサーバ１２’内のＲＡＣコントローラ１４’への接続のためのＲＡＣインターフェース１０’を含む。これらのリダイレクタは、ＣｏＤサーバの位置の特定の知識を必要としない。ＣｏＤサーバ１２’は、ＲＤＢＭＳ記憶装置１６’内のＣｏＤリスト内に自動的かつ適応可能に登録または登録解除する。
【００３１】
いくつかの別のオプション
いくつかのその他の実施形態では、ＲＳＶＰ−ＴＥプロトコルの代わりにネットワーク内でリソースを予約するためのその他の技法、例えば、マルチプロトコルラベル交換ＭＰＬＳが使用され得る。
【００３２】
全般
上で詳述された例示的な実施形態は、（いわゆる、次世代ネットワークＮＧＮなど）ネットワークの専用のＩＰＴＶサブシステムとみなされ得る。いくつかの代替の実施形態は、リソース予約および受付制御が、代わりに、呼出セットアップ制御機能によって行われる、インターネットプロトコルマルチメディアサブシステム（ＭＳ）ベースのＩＰＴＶシステムである。ビデオは、例えば、フィルム、クリップ、写真、またはスライドショーであり得る。ビデオ以外のいくつかの実施形態のコンテンツでは、例えば、音声、またはその他のマルチメディアが提供され得る。
【００３３】
本発明は、その趣旨または必須の特性から逸脱せずに、その他の特定の形態で実施されることが可能である。説明された実施形態は、すべての点で、限定ではなく、例示として、考慮されるべきである。したがって、本発明の範囲は、先の記述によってではなく、特許請求の範囲によって示される。特許請求の範囲の意味内でかつ特許請求の範囲の均等物の範囲内で生じるすべての変更は、その範囲内に包含されるべきである。
【技術分野】
【０００１】
本発明は、電気通信に関し、詳細には、ビデオなどのコンテンツの配信システムに関する。
【背景技術】
【０００２】
図１に示すように、インタラクティブインターネットプロトコルテレビＩＰＴＶなど、ビデオサービスを提供するための知られているネットワークでは、アプリケーションサーバＡＳは、そのインターフェースを経由して、中央リソース受付制御サブシステム（Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂｓｙｓｔｅｍ）（ＲＡＣＳ）サーバに接続される。このアプリケーションサーバは、それを経由して、当該アプリケーションサーバが、ＲＡＣＳサーバに接続されるリソース受付制御（ＲＡＣ）インターフェースを含む。このアプリケーションサーバは、説明を簡単にするために、そのうちの１つだけが図１に示されるコンテンツオンデマンド（ＣｏＤ）サーバにも接続される。
【０００３】
使用の際、このアプリケーションサーバは、（テレビセットに接続されたセットトップボックスまたは画面表示を含むデジタル移動体ハンドセットなどのユーザ機器ＵＥとして示される）ユーザ端末からコンテンツオンデマンド（ＣｏＤ）サービス要求を受信する。この要求は、ＲＡＣＳサーバに渡され、ＲＡＣＳサーバは、次いで、インターネットプロトコルネットワークの適切なリソースを予約することを要求する。リソースが予約され得る場合、ＲＡＣＳサーバは、当該アプリケーションサーバにリソース予約肯定応答を送り、次いで、当該アプリケーションサーバは、サービス要求の肯定応答および当該サービスを供給するために選択されたＣｏＤサーバの識別アドレスの両方を転送する。この情報は、ユーザ端末が、次いで、コンテンツオンデマンドセッションを確立することを要求することを可能にする。したがって、ＲＡＣＳサーバは、リソース予約機能および受付制御機能の両方を処理することを理解されよう。
【０００４】
知られている手法において、ＲＡＣＳサーバに対するインターフェースは、当該アプリケーションサーバ内にあってよく、またはその代わりに、ＣｏＤサーバ内にあってもよいが、いずれの場合も、中央ＲＡＣＳサーバと交信する。中央ＲＡＣＳサーバは、適切なＩＰネットワークリソースを予約する際に効果的であるように、ネットワークトポロジの詳細な知識を要求する。
【発明の概要】
【課題を解決するための手段】
【０００５】
添付の独立請求項を参照されたい。いくつかの好ましい特徴が従属請求項に提示される。
【０００６】
本発明の例は、複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備えるシステムにおいて、ユーザ端末にコンテンツオンデマンドサービスを提供する方法である。この方法は、
コンテンツオンデマンドサーバのうちの第１のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス配信を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記第１のサーバが、リソース予約が不十分であったというメッセージを送るステップと、
コンテンツオンデマンドサーバのうちの別のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス提供を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記別のサーバが、リソース予約が十分であるというメッセージを送るステップと、
前記別のサーバが、パケット交換ネットワークを経由して、ユーザ端末に当該コンテンツを提供するステップとを備える。
【０００７】
その好ましい実施形態では、ＣｏＤサーバは、リソース予約を行うように構成される。あるＣｏＤサーバが予約を行うことができない場合、代わりに、別のＣｏＤサーバが予約を行うことを要求される。このコンテンツは、ビデオであることが好ましい。
【０００８】
サーバが予約を行うことを要求される順序は、優先リストに従ってよい。このリストは、サーバの動作履歴を考慮に入れるよう適応可能であり得る。
【０００９】
その好ましい実施形態では、本発明は、ビデオコンテンツオンデマンド（ＣｏＤ）サービスなど、インタラクティブインターネットプロトコルテレビ（ＩＰＴＶ）サービスに関するリソース予約のための、回復性および適応性のある機構を提供する。
【００１０】
好ましい実施形態は、中央ＲＡＣＳサーバの使用を回避し、代わりに、リソース予約制御機能性を配信するため、発明者は、先行技術と比較して、好ましい実施形態は有利であろうことを理解した。これは、考えられる主な障害点を除去し、集中型サーバの要件、すなわち、ネットワークトポロジの正確な知識を有するかどうかを不要にした。
【００１１】
次に、図面を参照して、本発明の実施形態が例として説明される。
【図面の簡単な説明】
【００１２】
【図１】インタラクティブＩＰＴＶサービス（先行技術）に関して知られているネットワークを例示する図である。
【図２】本発明の第１の実施形態による、インタラクティブＩＰＴＶサービスに関するネットワークを例示する図である。
【図３】図２に示されるネットワークにおいて、要求されるサービスを提供するように、ネットワークリソースを予約することを例示するメッセージシーケンス図である。
【図４】図２に示されたネットワークにおいて、リソースがどのように予約されるかのさらなる詳細を示す、さらなるメッセージシーケンス図である。
【図５】本発明の第２の実施形態による、インタラクティブＩＰＴＶサービスに関するネットワークを例示する図である。
【発明を実施するための形態】
【００１３】
知られているシステムを考慮するとき、発明者は、中央ＲＡＣＳサーバを除去して、代わりに、関連する機能性を処理するために、コンテンツオンデマンドＣｏＤサーバを適応することが有用であろうことを理解した。
【００１４】
ネットワーク
図２に示すように、インタラクティブＩＰＴＶサービスに関するネットワーク２は、ユーザ端末ＵＥ６に接続可能なアプリケーションサーバＡＳ４からなる。ユーザ端末は、リソース受付制御（ＲＡＣ）インターフェース１０を含む制御プロトコルリダイレクタ（Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｒｅｄｉｒｅｃｔｏｒ）８にも接続可能である。このインターフェース１０は、一連のコンテンツオンデマンドＣｏＤサーバ、ＣｏＤ１、．．．、ＣｏＤｎ１２に接続される。この例では、それぞれのＣｏＤサーバは、デジタルマルチメディアコンテンツ、例えば、ビデオコンテンツを提供し、ビデオコンテンツオンデマンドサーバまたはビデオオンデマンドサーバと呼ばれる場合もある。それぞれのＣｏＤサーバ１２は、リソース受付制御（ＲＡＣ）コントローラ１４を含む。それぞれの制御プロトコルリダイレクタ８は、ＣｏＤサーバのリストが格納されるリレーショナルデータベース管理システム（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）（ＲＤＢＭＳ）１６にも接続される。ユーザ端末ＵＥ６は、インターネットプロトコルネットワーク１８を経由してＣｏＤサーバ１２に接続される。
【００１５】
動作
図３に示すように、ネットワーク２は、以下のように動作する。
【００１６】
ユーザ端末６は、まず、アプリケーションサーバ４に、ビデオフィルム、スポーツイベントまたはその他のマルチメディアコンテンツの記録など、特定のビデオストリームに対する要求を送る（ステップａ）。アプリケーションサーバ４は、移動体端末６にサービス要求許可を送ることによって応答し（ステップｂ）、次いで、移動体端末６は、選択されたコンテンツが当該ユーザによって所望されるものであるという確認をアプリケーションサーバ４に送り返す（ステップｃ）。
【００１７】
アプリケーションサーバ４は、次いで、移動体端末６にサービス入口点（ＳＥＰ）を送る（ステップｄ）。ＳＥＰは、制御プロトコルリダイレクタ８を識別し、次いで、移動体端末６は、サービスに対して許可された要求を制御プロトコルリダイクタ８に送る。それに応じて、移動体端末６は、その要求を送る（ステップｅ）。
【００１８】
ユーザ端末を識別するその要求を受信すると、制御プロトコルリダイレクタ８は、当該ユーザ端末に当該サービスを提供するために、（メタデータ記憶装置とみなされ得る）ＲＤＢＭＳ内の候補ＣｏＤサーバ１２のリストをリアルタイムで調べて（ステップｆ）、明らかに最も適しているサーバを選択する。
【００１９】
ＣｏＤサーバの選択
どのＣｏＤサーバに、特定のサービス要求に対応することを要求するかを選択するために使用される簡単な手法は、２個以上のＣｏＤサーバが、場合によっては、要求されたサービスをユーザ端末６に提供することが可能であるが、そのそれぞれのＣｏＤサーバは、特定の地理的位置からの要求を処理するためのその望ましさに関して、関連する重みを有すると仮定する。例えば、サーバが、例えば、ユーザ端末の現在の位置に対するサーバの近接性に基づいて、好ましくは、ユーザ端末６にサービス提供し得る順序のリストが格納される。制御プロトコルリダイレクタ８は、要求されるサービスを提供するために利用可能なリソースを現在有するＣｏＤサーバが識別されるまで、リストを処理していく。
【００２０】
特に、リスト上の第１のサーバは、当該サービスを提供するために必要なネットワークリソースを予約することが要求される（ステップｇ）。この要求は、アドレス指定されたサーバ１２内のリソース受付コントローラＲＡＣ１４によって受信される。
【００２１】
図４に示すように、ＲＡＣコントローラ１４は、それを経由して、当該コンテンツがユーザ端末６に送られるインターネットプロトコルネットワーク１８の適切なリソースを予約するように、知られているリソースリザベーションプロトコル（Ｒｅｓｏｕｒｃｅ ｒｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）−トラヒックエンジニアリング（ＲＳＶＰ−ＴＥプロトコル）を使用して、ラベル付けされた経路を作成することを要求する。この図に示すように、これは、選択されたＣｏＤサーバ１２が、ＲＳＶＰ−ＴＥ予約要求メッセージを、ユーザ端末６とサーバ１２の間のホップ同士の間で対応するＰＡＴＨメッセージおよびＲＥＳメッセージがセットアップされることが要求されるＩＰネットワーク１８内に送ることによって行われる（ステップｈ）。成功裏のリソース予約が発生した場合、サーバ１２内のＲＡＣコントローラ１４に応えて予約肯定応答メッセージ（ＰＡＴＨメッセージ（ステップｉ）。
【００２２】
再び図３を参照すると、例えばリスト上の第１のサーバに関して、予約は成功しなかったと想像されたい。したがって、制御プロトコルリダイレクタ８には、その特定のサーバがネットワークリソース予約を行うことができなかったことが通知される（ステップｊ）。それに応じて、制御プロトコルリダイレクタ８は、リスト内の次のＣｏＤサーバに、必要なネットワークリソースを予約する要求を送る（ステップｋ）。
【００２３】
このプロセスは、サーバがネットワークリソース予約を成功裏に達成するまで、サーバのリストを処理しながら繰り返される。成功裏のリソース予約が発生するのは、リスト上の第ｎ番目のサーバであると想像されたい（この場合、ｎは、正の整数、例えば２である）。予約肯定応答メッセージ（ＰＡＴＨメッセージ）は、ＩＰネットワーク１８からサーバ１２内のＲＡＣコントローラ１４に送られる（ステップｉ）。この第ｎ番目のサーバ１２内のＲＡＣコントローラ１４は、次いで、リソースが制御プロトコルリダイレクタ８に対して予約されたという肯定応答を送る（ステップｌ）。
【００２４】
次いで、制御プロトコルリダイレクタ８は、リソースを成功裏に予約した特定のサーバ１２からサービスを要求する命令をユーザ端末６に送る（ステップｍ）。すなわち、制御プロトコルリダイレクタ８は、当該コンテンツをユーザ端末８に配信することになるＣｏＤサーバのアドレスを戻す。
【００２５】
次いで、ユーザ端末１２は、当該コンテンツを配信することになるＣｏＤサーバに、サービスに対する要求を送る（ステップｎ）。そのＣｏＤサーバは、選択された映画のデータストリームなど、要求されたビデオサービスを配信することによって、ユーザ端末１２に応答する（ステップｏ）。
【００２６】
別の例示的なシステム
その他の点では、上の図２から図４に関して説明されたものと類似する代替の実施形態では、サービス要求に関して考慮されることになるＣｏＤサーバのリストは、それぞれのＣｏＤサーバに関して、最後の障害からの時間と、その障害を修正するのにかかった時間とをさらに考慮に入れるために適応可能に再度順序付けられる。障害は、ＣｏＤサーバ自体の障害または当該ＣｏＤサーバとユーザ端末の間のネットワーク接続の障害である。例えば、障害を迅速に修正し、最近障害を経験していないＣｏＤサーバは、その他のサーバより好ましい可能性がある。数学的に、
【数１】
とすると、ここで、ｗｋは第ｋ番目のＣｏＤサーバを選択するための選好（すなわち、確率）を示す重みであり、次のＣｏＤサーバｌは、例えば、以下の方程式に従って、選択される。
【数２】
ここで、ｗｋは、第ｋ番目のＣｏＤサーバを選択するための重みであり、ΔＴは、障害を修正するための平均時間であり、Δｔｎは、第ｋ番目のＣｏＤサーバ上で第ｎ番目のリコードされた障害からの時間である。
【００２７】
例えば、ＣｏＤ１に関して０．５、ＣｏＤ２に関して０．３、およびＣｏＤ３に関して０．２の関連する重みを有する３個のビデオサーバＣｏＤ１、ＣｏＤ２、およびＣｏＤ３が現在利用可能であるとしよう。これは、その他の係数を無視して、リスト上のＣｏＤサーバの中で、最高の選好はＣｏＤ１であり、最低の選好はＣｏＤ３であり、したがって、ＣｏＤ１が十分なリソースを有する場合、ＣｏＤ１が選択されることになることを意味する。しかし、これらの重みの考慮事項に加えて、ＣｏＤサーバ選択の一部として、間欠的ネットワーク障害の数が監視および考慮される。真の障害を修正するためには、平均してΔＴがかかることが分かっている。しかし、すべてΔＴ未満に分解する、ネットワーク欠陥（ｎｅｔｗｏｒｋ ｇｌｉｔｃｈｅｓ）によるいくつかの間欠的な短期間障害が存在すると仮定しよう。例えば、ΔＴ＝５時間であり、ＣｏＤ１に関して、故障からの時間が１時間、２時間、および３時間である、３つの間欠的な短期間障害が報告されているとしよう。
【００２８】
そこで、方程式を使用して、ＣｏＤ１に関する初期の重みは：
【数３】
に従って解くと、ＣｏＤ１に関する重みは、
【数４】
になる。
【００２９】
これは、それらの間欠的障害が存在する場合、サーバＣｏＤ１は、もはや最高の重みを有さず、０．３の重みを有するサーバＣｏＤ２が代わりに選択されることになることを意味する。
【００３０】
別の例示的なシステム
図５に示すように、その他の点では、図２に示されたものと類似する別の実施形態は、ユーザ端末と制御プロトコルリダイレクタ８’の間で接続された負荷分散装置（ｌｏａｄ ｂａｌａｎｃｅｒ）段階３０を含む。異なる位置の全体にわたって分散された、または代替の実施形態では、負荷分散装置３０段階の近くに局在化された、制御プロトコルリダイレクタ８’の複数のインスタンス（ｉｎｓｔａｎｃｅｓ）も存在する。リダイレクタ８’はそれぞれ、ＣｏＤサーバ１２’内のＲＡＣコントローラ１４’への接続のためのＲＡＣインターフェース１０’を含む。これらのリダイレクタは、ＣｏＤサーバの位置の特定の知識を必要としない。ＣｏＤサーバ１２’は、ＲＤＢＭＳ記憶装置１６’内のＣｏＤリスト内に自動的かつ適応可能に登録または登録解除する。
【００３１】
いくつかの別のオプション
いくつかのその他の実施形態では、ＲＳＶＰ−ＴＥプロトコルの代わりにネットワーク内でリソースを予約するためのその他の技法、例えば、マルチプロトコルラベル交換ＭＰＬＳが使用され得る。
【００３２】
全般
上で詳述された例示的な実施形態は、（いわゆる、次世代ネットワークＮＧＮなど）ネットワークの専用のＩＰＴＶサブシステムとみなされ得る。いくつかの代替の実施形態は、リソース予約および受付制御が、代わりに、呼出セットアップ制御機能によって行われる、インターネットプロトコルマルチメディアサブシステム（ＭＳ）ベースのＩＰＴＶシステムである。ビデオは、例えば、フィルム、クリップ、写真、またはスライドショーであり得る。ビデオ以外のいくつかの実施形態のコンテンツでは、例えば、音声、またはその他のマルチメディアが提供され得る。
【００３３】
本発明は、その趣旨または必須の特性から逸脱せずに、その他の特定の形態で実施されることが可能である。説明された実施形態は、すべての点で、限定ではなく、例示として、考慮されるべきである。したがって、本発明の範囲は、先の記述によってではなく、特許請求の範囲によって示される。特許請求の範囲の意味内でかつ特許請求の範囲の均等物の範囲内で生じるすべての変更は、その範囲内に包含されるべきである。
【特許請求の範囲】
【請求項１】
複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備えたシステムにおいて、ユーザ端末にコンテンツオンデマンドサービスを提供する方法であって、
コンテンツオンデマンドサーバのうちの第１のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス配信を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記第１のサーバが、リソース予約が不十分であったというメッセージを送るステップと、
コンテンツオンデマンドサーバのうちの別のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス提供を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記別のサーバが、リソース予約が十分であるというメッセージを送るステップと、
前記別のサーバが、パケット交換ネットワークを経由して、ユーザ端末にコンテンツを提供するステップとを備える、方法。
【請求項２】
コンテンツがビデオを備える、請求項１に記載の方法。
【請求項３】
それぞれのサーバが、関連するカバレージエリアを有し、第１のサーバが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて選択される、請求項１に記載の方法。
【請求項４】
コントローラが、サーバがリソースを予約することを要求することを要求されることになるシーケンスを決定する目的で、候補コンテンツオンデマンドサーバのリストを使用し、コントローラが、次に、あるサーバが、リソース予約が十分であることを報告するまで、リソースを予約して、リソース予約が十分であったかどうかのメッセージを送るようサーバに要求する、請求項１に記載の方法。
【請求項５】
リストが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて選択される、請求項４に記載の方法。
【請求項６】
シーケンスが、リスト内で参照されたＣｏＤサーバに関連するこれまでの障害に関する情報に依存する、請求項４に記載の方法。
【請求項７】
シーケンスが、最後の故障からの時間に依存する、請求項６に記載の方法。
【請求項８】
コンテンツオンデマンドサービスのためのシステムであって、
複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備え、
コンテンツオンデマンドサーバのうちの少なくとも２つが、そのコンテンツに対するユーザ端末からの要求に応答して、ユーザ端末にアドレス指定されたコンテンツを提供する候補であり、
それぞれの候補コンテンツオンデマンドサーバが、そのコンテンツオンデマンドサーバによるコンテンツ配信を可能にするように、ネットワークのリソースを予約することを要求するために動作可能なリソース予約段階を含む、システム。
【請求項９】
コンテンツがビデオを備える、請求項８に記載のシステム。
【請求項１０】
サーバがリソースを予約することを要求することを要求されるシーケンスを決定する目的で、候補コンテンツオンデマンドサーバのリストを検査するために動作可能なコントローラをさらに備え、使用中のコントローラが、次に、サーバのうちの１つが、リソース予約が十分であることを報告するまで、リソースを予約して、リソース予約が十分であったかどうかのメッセージを送るようにサーバに要求する、請求項８に記載のシステム。
【請求項１１】
コントローラが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて、複数のリストの中から、リストを選択するためにも動作可能である、請求項１０に記載のシステム。
【請求項１２】
コントローラが、ユーザ端末が許可されたサービス要求を送る制御プロトコルリダイレクタである、請求項１０に記載のシステム。
【請求項１３】
リストが格納されたリレーションデータベース管理システムをさらに備える、請求項１０に記載のシステム。
【請求項１】
複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備えたシステムにおいて、ユーザ端末にコンテンツオンデマンドサービスを提供する方法であって、
コンテンツオンデマンドサーバのうちの第１のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス配信を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記第１のサーバが、リソース予約が不十分であったというメッセージを送るステップと、
コンテンツオンデマンドサーバのうちの別のコンテンツオンデマンドサーバが、ユーザ端末に対するサービス提供を可能にするために、パケット交換ネットワークリソースを予約することを要求するステップと、
前記別のサーバが、リソース予約が十分であるというメッセージを送るステップと、
前記別のサーバが、パケット交換ネットワークを経由して、ユーザ端末にコンテンツを提供するステップとを備える、方法。
【請求項２】
コンテンツがビデオを備える、請求項１に記載の方法。
【請求項３】
それぞれのサーバが、関連するカバレージエリアを有し、第１のサーバが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて選択される、請求項１に記載の方法。
【請求項４】
コントローラが、サーバがリソースを予約することを要求することを要求されることになるシーケンスを決定する目的で、候補コンテンツオンデマンドサーバのリストを使用し、コントローラが、次に、あるサーバが、リソース予約が十分であることを報告するまで、リソースを予約して、リソース予約が十分であったかどうかのメッセージを送るようサーバに要求する、請求項１に記載の方法。
【請求項５】
リストが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて選択される、請求項４に記載の方法。
【請求項６】
シーケンスが、リスト内で参照されたＣｏＤサーバに関連するこれまでの障害に関する情報に依存する、請求項４に記載の方法。
【請求項７】
シーケンスが、最後の故障からの時間に依存する、請求項６に記載の方法。
【請求項８】
コンテンツオンデマンドサービスのためのシステムであって、
複数のコンテンツオンデマンドサーバとパケット交換ネットワークとを備え、
コンテンツオンデマンドサーバのうちの少なくとも２つが、そのコンテンツに対するユーザ端末からの要求に応答して、ユーザ端末にアドレス指定されたコンテンツを提供する候補であり、
それぞれの候補コンテンツオンデマンドサーバが、そのコンテンツオンデマンドサーバによるコンテンツ配信を可能にするように、ネットワークのリソースを予約することを要求するために動作可能なリソース予約段階を含む、システム。
【請求項９】
コンテンツがビデオを備える、請求項８に記載のシステム。
【請求項１０】
サーバがリソースを予約することを要求することを要求されるシーケンスを決定する目的で、候補コンテンツオンデマンドサーバのリストを検査するために動作可能なコントローラをさらに備え、使用中のコントローラが、次に、サーバのうちの１つが、リソース予約が十分であることを報告するまで、リソースを予約して、リソース予約が十分であったかどうかのメッセージを送るようにサーバに要求する、請求項８に記載のシステム。
【請求項１１】
コントローラが、サービスを要求しているユーザ端末が現在存在するカバレージエリアに応じて、複数のリストの中から、リストを選択するためにも動作可能である、請求項１０に記載のシステム。
【請求項１２】
コントローラが、ユーザ端末が許可されたサービス要求を送る制御プロトコルリダイレクタである、請求項１０に記載のシステム。
【請求項１３】
リストが格納されたリレーションデータベース管理システムをさらに備える、請求項１０に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１０−５３０６７９（Ｐ２０１０−５３０６７９Ａ）
【公表日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願番号】特願２０１０−５１２５５１（Ｐ２０１０−５１２５５１）
【出願日】平成２０年５月３０日（２００８．５．３０）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００４３９３
【国際公開番号】ＷＯ２００８／１５５０１４
【国際公開日】平成２０年１２月２４日（２００８．１２．２４）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２２年９月９日（２０１０．９．９）
【国際特許分類】
【出願日】平成２０年５月３０日（２００８．５．３０）
【国際出願番号】ＰＣＴ／ＥＰ２００８／００４３９３
【国際公開番号】ＷＯ２００８／１５５０１４
【国際公開日】平成２０年１２月２４日（２００８．１２．２４）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]