(57)【要約】ネットワークでコンテンツを提供する方法が開示されている。この方法は、未来時Ｔ１にて、コンテンツをコンテンツサーバーと契約者装置との間で移動させるセッションを確立させるリクエストをネットワークで受領し、リクエストされた未来セッションをサポートするのに必要なネットワークキャパシティを予約し、リクエスターのためにネットワークリソースが未来時Ｔ１で予約されたことをリクエスターに通知し、現在時が未来時Ｔ１に到達したとき、リクエストされたセッションをセットアップさせ、コンテンツサーバーと契約者装置との間でコンテンツを移動させる。  【選択図】  図１
2008509451.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークでコンテンツを提供する方法であって、
未来時Ｔ１にて、コンテンツをコンテンツサーバーと契約者装置との間で移動させるセッションを確立させるリクエストをネットワークで受領するステップと、
リクエストされた未来セッションをサポートするのに必要なネットワークキャパシティを予約するステップと、
リクエスターのためにネットワークリソースが未来時Ｔ１で予約されたことをリクエスターに通知するステップと、
現在時が未来時Ｔ１に到達したとき、リクエストされたセッションをセットアップさせ、コンテンツサーバーと契約者装置との間でコンテンツを移動させるステップと、
を含んで成ることを特徴とする方法。
【請求項２】
ネットワークキャパシティを予約するステップは、リクエストされたセッションをサポートするために未来時Ｔ１で充分なネットワークキャパシティが利用可能であるか否かを決定するステップをさらに含んでおり、ネットワークキャパシティの予約は充分なネットワークキャパシティが存在することの決定を条件とすることを特徴とする請求項１記載の方法。
【請求項３】
他の未来セッションのために留保されているネットワークキャパシティの状況を把握するステップをさらに含んでいることを特徴とする請求項２記載の方法。
【請求項４】
他のリクエスターによって未来時Ｔ１においてどのネットワークキャパシティリソースがリクエストされるかを予測するステップをさらに含んでおり、未来時Ｔ１で充分なネットワークキャパシティが利用可能か否かを決定するステップは、他のリクエスターによって未来時Ｔ１でリクエストされると予測されるネットワークキャパシティを考慮することを特徴とする請求項３記載の方法。
【請求項５】
それぞれが異なる優先レベルに対応する複数の行列を維持するステップと、
リクエストされたセッションの優先レベルを決定するステップと、
をさらに含んでおり、前記セッションの優先レベルは前記複数の行列の１つの優先レベルと同じであり、ネットワークキャパシティの予約ステップにはリクエストされたセッションの優先レベルに対応する行列に予約を保存するステップが関与することを特徴とする請求項１記載の方法。
【請求項６】
優先レベルの順序で複数の行列をポーリングして現在時に等しい予約時間を有した保存リクエストを特定し、コンテンツを提供するために対応するリクエストされたセッションをネットワーク上でセットアップするステップをさらに含んでいることを特徴とする請求項５記載の方法。
【請求項７】
コンテンツを提供させるネットワークはケーブルネットワークの少なくとも一部を含んでいることを特徴とする請求項１記載の方法。
【請求項８】
ネットワークで未来時Ｔ１にセッションを確立させるリクエストを受領するステップにはＰＣＭＭプロトコルを介してリクエストを受領することが関与することを特徴とする請求項１記載の方法。
【請求項９】
コンテンツサーバーはマルチメディアサーバーであることを特徴とする請求項１記載の方法。
【請求項１０】
ネットワークでのコンテンツ提供を管理する方法であって、
それぞれが異なる優先レベルに関係し、それぞれがその優先レベルに等しい関連優先権を有する未来セッションの予約を保存する複数の行列を維持するステップと、
サービス提供の準備が整った全リクエストを特定するために優先レベルの順序で複数の行列を定期的にポーリングするステップと、
を含んでいることを特徴とする方法。
【請求項１１】
ポーリングステップは別の行列に移動する前に複数の行列のひとつに保存された全リクエストをポーリングすることを特徴とする請求項１０記載の方法。
【請求項１２】
ネットワークでコンテンツを提供する方法であって、
ネットワークを介してコンテンツサーバーと契約者装置との間でコンテンツを移動させるセッションを確立させるリクエストを受領するステップと、
リクエストされたセッションをサポートするのに充分なネットワークキャパシティが現在利用不能であると決定するステップと、
未来時Ｔ１以後にどのネットワークキャパシティが利用可能になるかを予測するステップと、
間もなく充分なネットワークキャパシティが利用可能になると予測されたら、リクエストの拒絶を中止するステップと、
を含んでいることを特徴とする方法。
【請求項１３】
現在時が未来時Ｔ１に到達するまで待機し、その後にコンテンツサーバーと契約者装置との間でセッションをセットアップさせるリクエストを受領するステップをさらに含んでいることを特徴とする請求項１２記載の方法。
【請求項１４】
現在時が未来時Ｔ１に到達したとき、リクエストされたセッションをセットアップするステップをさらに含んでいることを特徴とする請求項１２記載の方法。
【請求項１５】
充分なネットワークキャパシティが未来時Ｔ１で利用可能になることをリクエスターに通知し、リクエストに対する応答が必要になる前にリクエストをキャンセルする機会をリクエスターに提供し、あるいは少なくとも未来時Ｔ１まで遅延を許可するステップをさらに含んでいることを特徴とする請求項１２記載の方法。
【請求項１６】
ネットワークによるコンテンツの提供を管理するポリシーサーバーであって、
プロセッサーと、
プロセッサーで実行されるとポリシーサーバーに、
ネットワークで未来時Ｔ１にコンテンツサーバーと契約者装置との間でコンテンツを移動させるセッションを確立させるリクエストを受領させ、
リクエストされた未来セッションをサポートするのに必要なネットワークキャパシティを予約させ、
ネットワークリソースが未来時Ｔ１にてリクエストのために予約されたことをリクエスターに通知させ、
現在時が未来時Ｔ１に到達したとき、コンテンツサーバーと契約者装置との間でコンテンツを移動させるためにリクエストされたセッションをセットアップさせる、
プログラムコードを保存するメモリーと、
を含んでいることを特徴とするポリシーサーバー。
【請求項１７】
ネットワークによるコンテンツの提供を管理するポリシーサーバーであって、
プロセッサーと、
プロセッサーで実行されるとポリシーサーバーに、
それぞれ異なる優先レベルに関連し、それぞれその優先レベルに等しい関連優先権を有した未来セッションの予約を保存する複数の行列を維持させ、
サービス提供準備ができた全リクエストを特定するために優先レベルの順序で複数の行列を定期的にポーリングさせる、
プログラムコードを保存するメモリーと、
を含んでいることを特徴とするポリシーサーバー。
【請求項１８】
ネットワークによるコンテンツの提供を管理するポリシーサーバーであって、
プロセッサーと、
プロセッサーで実行されるとポリシーサーバーに、
ネットワークでコンテンツサーバーと契約者装置との間でコンテンツを移動させるセッションを確立させるリクエストを受領させ、
リクエストされたセッションをサポートするために充分なネットワークキャパシティが現在利用不能であることを決定させ、
どのネットワークキャパシティが未来時Ｔ１以後に利用可能になるかを予測させ、
間もなく充分なネットワークキャパシティが利用可能になることが予測されたら、リクエストの拒絶を停止させる、
プログラムコードを保存するメモリーと、
を含んでいることを特徴とするポリシーサーバー。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的に通信とネットワークの分野に関し、特にブロードバンドインフラストラクチャーを介したサービスの提供に関する。
【背景技術】
【０００２】
ネットワークを介したサービスの提供に必要とされるネットワークリソースはネットワークを構築する相互接続技術に束縛される。ビジネス上の理由で、サービスプロバイダーのネットワークキャパシティはエンドユーザーの増加に伴って直線的には増加させることができない。その結果、サービスプロバイダーは所謂“契約超過”状態に陥る。すなわち、ネットワーク内の同一リソースが異なるエンドユーザーに多重販売される。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
“契約超過”は、全てのユーザーが自身のデータパイプを同時に利用するわけではないという原理に基づく。サービスプロバイダーはネットワークでどれだけ同時的な利用があるかを予測し、各データパイプで使用されるリソース量を最大にすべく努力する。混雑状態時（すなわち、多くのエンドユーザーが同時にネットワークにアクセスを試み、通信量がネットワークの許容能力を超える）に、ネットワークが特別処理を必要とするセッションと必要としないセッションとを区別できなければ、セッションに関連するサービス品質が実質的に損なわれるであろう。そうなると、サービスで利用されるリソースはエンドユーザーのデータパイプの特徴によって制限される。
【０００４】
例えば、オンデマンドビデオアプリケーション（例えば、ユーザーがビデオクリップや映画をリクエストする）の場合、もしエンドユーザーがコンテンツプロバイダー（例えば、ダイナミックサービス）から今日の統計データパイプを介してストリームビデオをダウンロードしたいなら、画質はＴＶ放送で得る画質よりもずっと劣悪であろう。その理由は、ビデオフレームを搬送するのに必要な帯域幅の所定量がネットワークで得られなければユーザーのための画質が劣化するからである（例えば、ジャーキー、フレームロス、等々）。これは、もしサービスプロバイダーアクセスネットワークがコンテンツのベストエフォートデリバリーに基づくものであればその通りである。これはそのようなサービスデリバリーに必要なサービス品質と比較して不十分である。このことは複数のユーザーが同一セットのネットワークリソースを得るために競争する競争ベースのアクセスネットワークでは特にそうである。
【０００５】
今日、エンドユーザーに異なるサービスを提供するように頻繁に使用されるモデルはグレードサービス（例えば、ブロンズ、シルバー、ゴールド）である。サービスプロバイダーはエンドユーザーによって契約されたグレードに基づいて異なるグレードサービスとなるグレードサービスモデルを提供する。
【０００６】
変化するネットワーク条件にさらによく対応し、様々な契約者やプロバイダーに提供されるサービス品質において差別的特徴を提供するように設計されたサービスを提供すべく提案された方法は、米国特許願１０/８６７１５７（２００４年６月１４日出願）“通信ネットワークのダイナミックサービスデリバリープラットホーム”において説明されている。その方法によれば、ポリシーサーバーは、契約者が様々なプロバイダーから受け取る権利を有するサービスのレベルに関するルールあるいはポリシーを保存し、そのポリシーに基づいてリソースを分配する。
【０００７】
それはネットワークで提供されるダイナミックサービスを管理する方法を説明する。その方法は、ネットワークの利用をコントロールするルールの保存、ネットワークの状態の把握、ネットワークを介したセッション確立のリクエスト受領、及びセッション確立のリクエストの承認可否を決定するネットワークの保存されたルールとステートの両方の使用が関与する。
【課題を解決するための手段】
【０００８】
本発明の１つの特徴では、本発明はネットワークを介してコンテンツをデリバーする方法を開示する。この方法は、ネットワークを介し、未来時Ｔ１においてコンテンツサーバーと契約者の装置との間でコンテンツを移動させるセッションを確立させるためのリクエストの受領と、リクエストされた未来セッションをサポートするのに必要なネットワークキャパシティの予約と、ネットワークリソースが未来時Ｔ１にリクエスターのために予約されたことの確認と、現在時が未来時Ｔ１に到達したときにコンテンツサーバーと契約者装置との間でコンテンツを移すためにリクエストされたセッションのセットアップとが関与する。
【０００９】
他の実施例は以下の特徴の一部を含む。ネットワークキャパシティの予約は、リクエストされたセッションをサポートするのに未来時Ｔ１において充分なネットワークキャパシティが得られるか否かの判定をさらに含み、ネットワークキャパシティの予約は、充分なネットワークキャパシティが確かに存在するとの判定を条件とする。この方法は未来セッションのために留保してあるネットワークキャパシティの現状把握と、どのリソースが未来時Ｔ１でリクエストされるかの予測を含む。充分なネットワークキャパシティが未来時Ｔ１で得られるか否かの判定はその予測されるリクエストを考慮する。方法はさらに、それぞれ異なる優先レベルに対応する複数の行列の維持と、リクエストされたセッションの優先レベルの判定を含む。セッションの優先レベルは複数の行列の１つに対する優先レベルと同じである。また、ネットワークキャパシティの予約には、リクエストされたセッションの優先レベルに対応する行列に予約を保存することが関与する。請求項５の方法は、現在時に等しい予約時を有した保存リクエストを特定するための優先レベルの順序で複数の行列をポール処理することをさらに含んでいる。さらに現在時に等しい予約時を有した保存リクエストのための行列をポール処理することを含んでいる。コンテンツが提供されるネットワークはケーブルネットワークである少なくとも一部を含んでいる。ネットワークにより未来時Ｔ１でセッションを確立させるリクエストを受領することは、ＰＣＭＭプロトコルを介したリクエストの受領が関与する。コンテンツサーバーはマルチメディアサーバーである。
【００１０】
別の特徴では、本発明はネットワークでのコンテンツの提供を管理する別方法を提供する。この方法は、それぞれが異なる優先レベルと関連し、それぞれがその行列の優先レベルに等しい関連優先権を有する未来セッションの予約を保存するための複数の行列を維持し、レベルの順序で定期的に複数の行列のポーリングを実行し、利用される準備が整った全リクエストを特定することが関与する。
【００１１】
他の実施例は次の特徴を含む。ポーリングは別の行列に移動する前に複数の行列の１つに保存された全行列を網羅する。
【００１２】
別の特徴では、本発明はコンテンツをネットワークでデリバーする別の方法も提供する。この方法はコンテンツサーバーと契約者装置との間でネットワークを介してセッションを確立するリクエストを受領する。このセッションはコンテンツサーバーと契約者装置との間でコンテンツを移すためのものである。さらに、リクエストされたセッションをサポートするのに充分なネットワークキャパシティが現在利用できないことを確認し、どのネットワークキャパシティが未来時Ｔ１以降に利用できるかを予測し、間もなく充分なネットワークキャパシティが得られると予測されれば、リクエストの拒否を停止する。
【００１３】
他の実施例は次の特徴を含む。この方法は現行時が未来時Ｔ１に到達するのを待ち、コンテンツサーバーと契約者装置との間でセッションのセットアップするリクエストを受け入れる。あるいは、現行時間が未来時Ｔ１に到達するとリクエストされたセッションをセットアップする。この方法はリクエスターに十分なネットワークキャパシティが未来時Ｔ１に利用でき、リクエスターに対してリクエストをキャンセルするかリクエストへの返事が必要となる前に少なくとも未来時Ｔ１まで遅れを許容する機会を提供する。
【００１４】
別の特徴では、本発明はネットワークでのコンテンツデリバリーの管理のためのポリシーサーバーを特徴とする。ポリシーサーバーは、プロセッサーと、プロセッサーで実行されたときにポリシーサーバーに対して、ネットワークで未来時Ｔ１にて、コンテンツサーバーと契約者装置との間でコンテンツを移動させるためのリクエストされたセッションを確立させるリクエストを受領させ、リクエストされた未来セッションをサポートするのに必要なネットワークキャパシティを予約させ、ネットワークリソースが未来時Ｔ１にてリクエスターのために予約させ、現行時が未来時Ｔ１に到達するとリクエストされたセッションをコンテンツサーバーと契約者装置との間でコンテンツを移動させるようにセットアップさせるプログラムコードを保存するメモリーとを含んでいる。
【００１５】
別の特徴では本発明はネットワークによるコンテンツのデリバリーを管理するポリシーサーバーを特徴とする。このポリシーサーバーはプロセッサーと、プロセッサーで実行されるとポリシーサーバーに、異なる優先レベルとそれぞれ関連し、行列の優先レベルに等しい関連優先権を有した未来セッションの予約を保存する複数の行列を維持させ、利用の用意ができている全リクエストを特定するためにその優先レベルで複数の行列を定期的にポーリングさせるプログラムコードを保存するメモリーとを含んでいる。
【００１６】
さらに別な特徴によれば、本発明はネットワークでコンテンツのデリバリーを管理するポリシーサーバーを特徴とする。ポリシーサーバーはプロセッサーと、プロセッサーで実行されるとコンテンツサーバーと契約者装置との間でコンテンツを移動させるセッションを確立するリクエストを受領させ、リクエストされたセッションをサポートするのに充分なネットワークキャパシティが得られないと決定させ、どのネットワークキャパシティが未来時Ｔ１後に利用できるか予測させ、もし充分なネットワークキャパシティがすぐに利用できると予測されるとリクエストの拒絶を中止させるプログラムコードを保存するメモリーとを含んでいる。
【発明を実施するための最良の形態】
【００１７】
本発明の実施例の詳細は以下で図面を利用して説明する。本発明の他の特徴、目的及び利点は以下の説明から明らかとなろう。
【００１８】
図１はクオリティ・オブ・サービス(Quality of Service)によるＤＯＣＳＩＳベースのＨＦＣネットワークにてマルチメディアセッションをデリバーする構造の高レベルブロック図である。それはアプリケーションサーバー（ＡＳ）１２、アクセスネットワーク１６に対するゲートウェイとして作用するマルチケーブルモデムターミネーションシステム（ＣＭＴＳ:Cable Modem Termination Systems）１４、及びアプリケーションサーバー１２の代わりにアクセスコントロールとクオリティ・オブ・サービスを管理するポリシーサーバー（ＰＳ）１８を含んでいる。これら要素は典型的には、それで互いに通信できるネットワーク２０（例えば、インターネット）に接続されている。パソコン（ＰＣ）のごときカスタマープレミスイクイップメント（ＣＰＥ:Customer Premises Equipment）２２、ゲームコンソール、またはセットトップボックス（ＳＴＢ）はケーブルモデム（ＣＭ）２４を介してアクセスネットワーク１６に接続されている。
【００１９】
一般的に、アプリケーションサーバー１２は特定された契約者にアプリケーションセッションをリクエストする。これらリクエストはポリシーサーバー１８に送られる。ポリシーサーバーはそれらを評価し、ネットワークリソースの利用性とポリシーサーバーに利用可能なポリシーまたはルールに基づいて承認するか拒絶する。もしリクエストが承認されると、ポリシーサーバー１８はその背後に契約者のケーブルモデムが位置する適切なＣＭＴＳ１４にセッション時間中の帯域幅を予約するように指示する。セッションが終了すると、アプリケーションはポリシーサーバー１８に情報を伝え、ポリシーサーバーはＣＭＴＳでその流れを阻止する。この実施例では、ポリシーサーバー１８は未来のリソース予約のリクエストをも受領し、その未来時にネットワークの予想状態がどうなるかによってリクエストを承認または拒絶する。もし、予約が承認されると、時間が来ればポリシーサーバーはＣＭＴＳに、特定されたサーバーを契約者のＩＰアドレスに接続してリクエストされたセッションを確立させる。
【００２０】
未来のリソースの予約に関するネットワークの特定局面の追加的詳細を提供する前に、そのプロセスに関与する様々なコンポーネントをまず詳細に解説する。
【００２１】
ケーブルヘッドエンドに設置された装置であるＣＭＴＳは多重ネットワークインターフェースで多くのケーブルモデムユーザーとのデータ交換をさせるデータ交換システムとして機能する。それは接続されたアクセスネットワーク（例えば、ケーブルデータネットワーク）で相互通信を一体化させる。ＣＴＭＳはケーブルモデムをアクセスネットワークで接続するためにプロトコル（例えば、ＤＯＣＳＩＳ・ＰＦＩ・ＭＡＣプロトコル）を実行させる。ＤＯＣＳＩＳとはデータオーバーケーブルサービスインターフェーススペシフィケーションズ(Data-Over-Cable Service Interface Specifications)の略である。それはどのようにデータを標準のケーブルネットワークで送信するかを定義する（ＤＯＣＳＩＳ１．０、ＤＯＣＳＩＳ１．１及びＤＯＣＳＩＳ２．０参照）。ＲＦＩはＤＯＣＳＩＳ電波インターフェーススペシフィケーション(Radio Frequency Interface Specification)であり、ＭＡＣ並びにＣＭＴＳとＣＭネットワーク要素間のフィジカルレイヤーインターフェース(Physical Layer Interface)を定義する。
【００２２】
コンテンツプロバイダーに管理されたアプリケーションサーバー１２はケーブルモデム２４に接続されたＣＰＥ２２のアプリケーションにコンテンツを送る。インターネットにおいて、そのようなサーバーの一般例にはヤフーウェブサーバー、ファイルアップロードサーバー、ビデオサーバ、Ｘボックスサーバーその他が含まれる。
【００２３】
エンドユーザーまたはネットワーク管理システムの代わりにＱoＳベースサービスをリクエストするためにポリシーサーバー１８にインターフェースするシステムであるアプリケーションマネージャー（ＡＭ）２６も存在する。典型的には、アプリケーションマネージャー２６はアプリケーションサーバー１２の一部として実行される。
【００２４】
ケーブルモデム２４は他のカスタマープレミスイクイップメント（ＣＰＥ）２２をアクセスネットワーク１６に接続させ、ケーブルサービスを受領させる。本実施例ではケーブルモデムは、３０から４０Ｍｂｐのデータを６ＭＨｚケーブルチャンネルでデリバーすることができる６４/２５６ＱＡＭ（クワドラチャーアンプリチュードモデュレーション:Quadrature Amplitude Modulation）ＲＦレシーバである。ユーザーからのデータはデータレートが３２０ｋｂｐから１０ＭｂｐのＱＰＳＫ/１６ＱＡＭトランスミッターを使用して調整される（ＱＰＳＫとはクワドラチャーフェーズシフトキーイングモジュレーション(Quadrature Phase Shift Keying Modulation)のことである）。双方向データレートはケーブルモデムを使用して契約者のニーズにマッチするようにフレキシブルに設計できる。
【００２５】
ポリシーサーバー１８は主としてアプリケーションマネージャー２６とＣＭＴＳ１４との間の仲介体として作用するシステムである。それはアプリケーションマネージャーからのリクエストにネットワークポリシーを適用することでＣＭＴＳの作動を管理し、アプリケーションマネージャーとＣＭＴＳとの間のメッセージを代理する。この実施例では、ポリシーサーバーはパケットケーブルマルチメディア（ＰＣＭＭ:Packet Cable Multimedia）基準（例えば、パケットケーブルマルチメディアアークテクチャーフレームワークテクニカルレポートＰＫＴ−ＴＲ−ＡＲＣＨ−Ｖ０１−０３０６２７参照）で特定された機能性並びにここで解説する拡張された機能性を実行する。仲介体としての能力でポリシーサーバー１８は、ネットワークまたはサービスのオペレータにより確立されたポリシールールに基づいて異なるリクエスターのＱoＳを承認し、ポリシー決定をターミナル装置（例えば、ＣＭＴＳ）に提供することでＱoＳに影響を及ぼす。その拡張機能性にはネットワークの状態（ネットワークでの事象、セッションの状況、等）を追跡してモニターし、ネットワーク状態に基づいてポリシー決定を行うことが含まれる。
【００２６】
本実施例では、ポリシーサーバーはアクセスネットワークで利用できる全リソースを管理する。さらに、典型的にはポリシーサーバーはＣＭＴＳ及びマルチメディアストリームを契約者に提供するアクセスネットワークと同様にケーブルオペレータの管理下にある。メディアストリームを発生させるアプリケーションサーバーは、ケーブルオペレータによって所有及び管理もできるが、典型的には第三者に所有されて管理されている。
【００２７】
一般的に、本実施例は前記の特許願（米国特許願１０/８６７１５７）で説明されている技術を使用して通信ネットワークでダイナミックサービスを提供できる。サービスの提供は、サービスのユーザー（エンドユーザーともいう）、サービスをデリバーするデリバリーネットワーク（例えば、アクセスネットワーク１６）及びサービスコンテンツのプロバイダーが関与する。デリバリーネットワーク（またはアクセスネットワーク１６）は一般的にサービスプロバイダーと呼称されるエンティティによって所有されている。一般的にサービスのユーザーは人間のオペレータまたはサービスを利用する機械を含む。ユーザーまたは契約者は居住者、会社あるいはサービスプロバイダーの他の顧客である。サービスコンテンツのプロバイダーはコンテンツプロバイダーと呼ばれる。コンテンツのソースはサービスプロバイダーが所有して管理することができる。その場合にはコンテンツはローカルコンテンツと呼ばれる。あるいは、コンテンツソースはサービスプロバイダー以外のエンティティが所有管理できる。その場合にはコンテンツは第三者コンテンツと呼ばれる。
【００２８】
典型的には、提供されているダイナミックサービスはユーザーがオンデマンドで得られ、コンテンツプロバイダーによって提供されるサービスであり、サービスプロバイダーによって所有されているデリバリーネットワークで提供される。解説するケーブルネットワーク実施例においては、ダイナミックサービスの例には音声とビデオ電話、ビデオオンデマンド、インターネットデータサービス、ゲーム、時間ベース及び/又はボリュームベースのサービスが含まれる。
【００２９】
サービスのユーザーにサービスを提供するには、データパイプと呼称される通路がコンテンツプロバイダーとユーザーとの間に提供される。典型的には、サービスプロバイダーはデリバリーネットワークに責任を負い、データパイプを提供するエンティティである。データパイプは論理的導管であり、物理的ネットワーク要素を通過し、サービスに関わる２つのエンドポイント間でデータを送るための接続性を提供する。ビデオ、音声/電話またはインターネットデータであるコンテンツのデリバリーは、家庭や会社へのデータパイプによって家庭や会社でのブロードバンドユーザーに提供される。データパイプは統計手段あるいは設計手段で確立される。
【００３０】
データパイプの提供は設計、管理及び電子サービス（例えば、電話、ビデオ）の活用、並びにダイナミックサービスをリクエストする顧客を満足させるためのデータパイプ利用のプロセスである。
【００３１】
データパイプは通信エンティティ間のセッションをサポートするのに使用される。セッションとはサービス（例えば、ビデオオンデマンド、ゲーム、電話/音声、ファイルシェアリング、等）のリクエストとデリバリーに関与する２以上のポイント間での情報の流れのことである。よって、セッションはダイナミックサービスインボケーションの場合に関連するダイナミックコンテキストを表す。セッションはサービスの提供に必要な全てのデータフローと、データパイプが通過する様々な要素で使用される全てのリソースを含む。ボイスコールのためには、セッションはユーザーが電話をかけるときに発生するエンドユーザー間のコネクションをマッピングするであろう。そのような音声セッションは電話を完成させるのに利用される全ネットワークリソースを含む。マルチメディアメッセージサービスのためには、セッションはメッセージサービスの提供に必要なネットワークリソースと共にビデオ、音声及びデータトラフィック（コンテンツ）を含む。
【００３２】
＜優先ベースの未来予約＞
リソースの未来的な使用のための承認コントロールを実行するため、予想されたネットワーク利用状況の理解に基づいてリソース承認者は未来の予約が成功するか否かを決定しなければならない。
【００３３】
この実施例ではリソース承認者はポリシーサーバーである。ポリシーサーバーはＣＭＴＳを管理し、どのタイプのトラフィックが他のタイプのトラフィックよりも優先順位を有するかを決定する。一般的には解説する実施例では、ＣＭＴＳはポリシーサーバーからの承認なしではトラフィクに対するアクセスを許可されない。基本的に２つのタイプのトラフィックであるサービス品質（ＱoＳ）トラフィックと“ベストエフォート”トラフィックが存在する。全ＱoＳリクエスト（すなわち、サービス品質セッションの全リクエスト）はポリシーサーバーを通過し、ポリシーサーバーは現在それらリクエストに応えるのにどのリソースが使用されているのか、未来のために何が行われたかを追尾する。ベストエフォートリクエストはポリシーサーバーを通過しないが、ポリシーサーバーはそのようなリクエストに応えるのにＣＭＴＳに使用が許されるには最大量のリソースを決定する。一般的に、それはベストエフォートリクエストに応えるのに利用できる量はサービス品質リクエストには利用できない。このため、ポリシーサーバーはＣＭＴＳがいつでも利用できる最低量を知ることができる。
【００３４】
典型的には、リソースが予約されるときは早い者勝ちであり、リソース予約リクエストは直ちに有効となる。“未来予約システム”では、リソースをリクエストするアプリケーションサーバー/マネージャーまたはクライエントは予約リクエストの承認に責任を有するポリシーサーバーに未来の予約を要求できる。ポリシーサーバーへのリクエストは関係する期間の帯域幅を予約するものである。ポリシーサーバーはデータベース４０を有している。そこでどのリソースがどの時間のために予約されたかを記録し、リクエストされた予定未来時のネットワークリソースを予約する。
【００３５】
未来予約のために多数のリクエスターが存在するであろう。それらリクエスターは異なるレベルの重要度（すなわち異なる優先順）を有するであろう。ポリシーサーバーは様々な予約リクエストの相対的重要度を決定し、その決定に沿って、アプリケーションからであろうとエンドユーザーからであろうと、リソースに対する高い確率でアクセスを提供する。
【００３６】
このプロセスは図２で示す例を介してより良く理解される。例えば、契約者がＭＬＢ．ｃｏｍから３週間後に放映されるゲームのストリームビデオの受領を希望したとする。契約者は、ＰＣで作動するブラウザーインターフェース、セットトップボックス、あるいは他の便利なインターフェースを介してＭＬＢ．ｃｏｍサーバーサイトに接続し、その放送を契約し、未来のプログラム放送の予約をリクエストする（ステップ１００）。それに応じてＭＬＢ．ｃｏｍサーバーは対応するリクエストをポリシーサーバーに送り、適切な時間スロットで契約者のために選択されたイベントの予約を求める（ステップ１０２）。
【００３７】
そのリクエストを受け取ると直ちにポリシーサーバーはそのデータベースに問い合わせ、（１）契約者が有する優先レベルを決定し、（２）その希望時間にネットワークリソースが利用可能であるか否かを決定する。
【００３８】
この例では、利用できるサービスレベルはプラチナ、ゴールド及びシルバーであり、プラチナが最優先で最高レベルのサービスを受け、シルバーが最低である。ケーブルオペレータはどのようにでも優先順位を設定することができるが、最もビジネス的にメリットのあるように設定するであろう。予約に与えられる優先順位を決定するキー要素は契約者の特定条件とアプリケーションまたはメディア源の特定条件であろう。例えば、最も高い契約料を払う意思のある契約者がプラチナレベルとなろう。同様に、ケーブルオペレータは、契約料が高く、ケーブルオペレータの実入りも多いプレミアソースからのメディアストリームが高い優先順位を得て、安いメディアコンテンツソースよりも高い質を得るように決定するであろう。いずれにしろ、ポリシーサーバーは、ケーブルオペレータに最も高収益を与える優先順位及び指定構造とするように幅広い要素に基づいて優先順位を決定するアルゴリズムを含むことになる。
【００３９】
本実施例では、充分なリソースが契約者の契約優先レベルで利用できると決定されると、ポリシーサーバーはそのリクエストに対する必要なリソースをデータベース更新により提供し、それらリソースを契約者に指定してリソースが他の契約者やセッションでは利用できないことを示す（ステップ１０６）。本実施例では、ポリシーサーバーはトークンをアプリケーションサーバーに送り返し、予約が完了したことを通知し、番号または他のユニークな識別手段により予約を特定する（ステップ１０８）。
【００４０】
もちろん、もし充分なネットワークキャパシテが予約のサポートに利用できなければ、ポリシーサーバーは予約リクエストを拒絶する（ステップ１０）。
【００４１】
予約されたビデオストリームを送り届けるときがくれば、ＭＬＢ．ｃｏｍサイトのアプリケーションサーバーはポリシーサーバーにトークンを送る。このアプローチはセッションを確立させるインテラプトモデルと呼ばれる。アプリケーションサーバーは、それが予約された時間スロットにあるかぎりそれが確立されるのを要求する。トークンを受け取ったポリシーサーバーはそのデータベースをチェックして受け取ったトークンが有効であるか、どの接続を確立するのか、どの優先レベルがその結果としてのセッションであるのかを調べる。続いて、ポリシーサーバーは対応するＣＭＴＳに指示を与え、セッションを設定し、ＭＬＢ．ｃｏｍサーバーはビデオコンテンツを契約者に流す。
【００４２】
＜利用可能なキャパシティの決定＞
ポリシーサーバーが予約リクエストを承認するかどうかを決定するとき、そのリクエストされたセッションがアクティブである全ての時間の予想される需要をチェックする。図２で示すように、一般的に利用可能なキャパシティは、ＣＭＴＳがデリバーすることができる全キャパシティから、その時間スロットで予期される利用を差し引いたものになる。この実施例では、２タイプの予想される未来利用が存在する。すなわち、“予約済み”と“承認済み”である。“予約済み”キャパシティは予約料を前払いした契約者のために留保しておいた未来キャパシティである。“承認済み”キャパシティは予約料を前払いしていない契約者のために留保した未来キャパシティである（例えば、セッションが確立される直前に支払う場合もあり）。このような区別を設ける理由は、オペレータは承認済みキャパシティに低優先順位を付与することを願うからである。それは前金を払うことを希望するか、ぎりぎりに申し込み、特別料金を払う契約者を優先するからである。
【００４３】
いずれにしろ、ポリシーサーバーはリクエストされたセッションのための必要なリソースがセッションの全期間で利用できるか否かを決定する。ポリシーサーバーはセッション全期間でリソースが利用可能であるときのみ予約リクエストを承認する。
【００４４】
＜優先順位行列＞
ケーブルオペラレータに高優先順位契約者が低優先順位契約者よりも優先的にアクセスを得ることの承認を簡単に提供させることができる１実施例では、ポリシーサーバーは全ローカルデータ保存５２の行列セット５０を活用する。それぞれの行列は異なる優先順位に対応する。ポリシーサーバーが予約リクエストを承認するとき、ポリシーサーバーは予約を対応する優先レベルの行列に割り当てる。与えられた優先順位の全予約は、いつ利用されるかに拘わらず、その優先レベルの１つの行列に入れられる。
【００４５】
周期的に、例えば１５分間隔で、ポリシーサーバーは最初にポーリングされた最高優先行列の優先順序でその行列をポーリングし、その行列が現在時に開始する予定の予約を有するかどうかを判定する。その時間に開始する予定の各予約に対して、ポリシーサーバーは対応するＣＭＴＳに指示してコンテンツプロバイダーのアプリケーションサーバーと契約者のケーブルモデムとの間で適当な品質のサービスのセッションをセットアップさせる。従って、この方法によれば、ポリシーサーバーは適切な時間に自動的にセッションを開始する（アプリケーションサーバーはトークンを提供し、セッションを開始させる前述のインテラプト方法参照）。
【００４６】
各ポーリングインターバルにてポリシーサーバーは優先順位に従って行列を通って移動し、その時に開始される予定の全セッションをセットアップする。もし、キャパシティが予定より少なく、全予約をサポートできなければ、この方法は高優先予約が低優先予約に優先し、もしサービスが拒絶されるなら、高優先予約の前に低優先予約を拒絶する。
【００４７】
もちろん、行列から予約を得る他の方法も存在する。行列はそれらの優先順位に従ってサービスされる。それらは加重総当りでもサービスされる。行列の優先順位がつけられたサービスは、優先ベース未来リソース予約システムに、リソースへのアクセスを得させるさらに高い優先順位のさらに大きいチャンス、すなわち、リソースを予約させる大きいチャンスを与えさせる。もしリソースがほとんど存在しなければ、これは高優先リクエストにさらに多くのリザベーションチャンスを与え、低優先リクエストにさらに少ないリソースチャンスを与える。また、行列はその時間が“現在”であるリクエストのみがリソースを予約できるようにサービスされる。行列サービスエンジン５５はポリシーサーバー１８内のソフトウェアモジュールであるが、時間をチェックし、行列を時間的に前進させ、行列のそれぞれのどこに“現在時”が存在するのかチェックする。サービスエンジンはそれぞれの優先順位に基づいて行列で“現在時”と関連する予約を処理する。
【００４８】
＜予測分析＞
ポリシーサーバーで実行される別の機能は、過去の経験に基づいたリソースに対する未来需要の予測と、特定リクエスターのために未来リソースを予約させるためのリソースが利用可能か否かの決定に至る情報である要素の検討である。例えば、過去の経験は、コンテンツが未来利用可能になるとき特定コンテンツを受領できる能力に対して特別料金を支払う気がある多数のビューアーがいることを示すかも知れない。言い換えると、その経験は未来のデマンドを予測させるかも知れない。その予測に基づいてケーブルオペレータは遅い申込者のためにリソースを留保することを願うかもしれない。その場合、他コンテンツのネットワーク帯域幅の未来予約のためのリクエストに応える利用できるリソースの量を減らせるかもしれない。予測機能のこのような使用は、所有するリソースの最大有効利用を可能にし、ケーブルオペレータに最大の利益をもたらすことができる。
【００４９】
この方法の変形では、ポリシーサーバーは現行承認のコントロールに予測を使用することもできる。もし現在のリクエストがセッションをスタートさせるようにアプリケーションサーバーから指令を受け取ったら、ポリシーサーバーはリソースが現在利用不能であると判断するかもしれない。１方法は単純にそのリクエストを拒絶し、契約者を待たせ、別のリクエストを移ることである。しかし、それではビジネスにならない。特に、その直後にネットワークの状況が変化し、リクエスト承認が可能になる場合があるからである。この実施例でポリシーサーバーにより利用される別の方法は、どのリソースが短時間で、例えば数分後に利用できるようになるか予測し、その予測に基づいて承認の決定をすることである。例えば、特定のリソースが別の契約者にストリームされている映画で使用されており、その映画は終わろうとしていることを知れば、現行のリクエストに対して現行のリクエストを満足させるのに必要なリソースが利用可能になることを予測できる。リソースがすぐに利用できるようになることが予測されれば、単純にそのリソースを利用可能になるまで遅らせ、少々後にリクエストを承認する。契約者にリクエストが処理中であり、システムに問題はないことを知らせるため、ポリシーサーバーはリクエスターにメッセージを送り返し、リクエストが処理中であることを通知する。アプリケーションサーバーはそのレスポンスを契約者に戻すことができる。
【００５０】
リソースがすぐに利用可能になるとき、単純にレシポンスを遅らせて接続する別の方法では、ポリシーサーバーは契約者にアプリケーションサーバーを介してリクエストが“Ｘ”分後に利用可能になるであろうことを知らせる。
【００５１】
そのような方法は、電話をセットアップしようとする契約者より、映画を観ることを願う契約者や、複数参加型ゲームに参加を願う契約者にとって成功の確率が高い。
【００５２】
そのようなアプローチはリクエスト承認者に対してリソース管理に柔軟性を与える。リクエスト承認者は未来のリソースのために予測モデルに基づいて自由となるリソースを“借りる”ことができる。それら未来の予測が少々間違っていれば（例えば、遅れが予想以上）ポリシーサーバーはＣＭＴＳに指示してセッションをセットアップし、ベストエフォートセッションのために一時的にそこに存在するリザーブからリソースを引き出す。他のリソースを自由にすることでそれらリザーブはすぐに補充されるという予測に基づいてポリシーサーバーはそのアプローチを直ちに実行することができる。
【００５３】
＜他の実施例＞
説明した実施例はケーブルアクセスネットワークが関与するが、提供されたアイデアはコンテンツを契約者に届けさせる他のどのようなセッション関与アクセスネットワークにも適用できる。
【００５４】
さらに、ＰＣＭＭはポリシーサーバーと通信する説明した実施例で使用されたプロトコルであったが、別プロトコルの範囲にある別プロトコルでも代用できる。例えば、アプリケーションサーバーはＤＱｏＳ、ＲＳＶＰ、ＳＯＡＰ／ＸＭＬ、ＨＴＴＰのいずれによってもポリシーサーバーと話すことができる。
【００５５】
上述から、ポリシーサーバーは、例えばアプリケーションまたはアプリケーションプロバイダーの特定情報、契約者または契約者層の特定情報、ネットワーク利用の現状または未来の予期される及び/又は予測された利用状態、時間、またはそれらの組み合わせを含んだ多くの相違した基準に基づいてポリシーをつくり、優先順位を決定できる。
【００５６】
一般的に、基準としてアプリケーションまたはアプリケーションプロバイダーの特定条件を含ませることでオペレータに第三者関係のコントロールを実行及び維持させる。また、オペレータに自身のサービスをさらに良好にコントロールさせる。アプリケーションベースのポリシー例は、“ＨＦＣネットワークによる１００セッション以上のビデオストリームは承認するな”である。
【００５７】
契約者及び/又は契約者層を含ませるとオペレータに個別の契約者や契約者層に基づいてサービスへのアクセスをコントロールさせる。それで、例えば、所定のサービスは“ゴールド”層契約者のみに提供される。そのようなポリシーの例は、“契約者が“ゴールド”契約者であればこのビデオセッションを提供せよ”である。
【００５８】
基準としてネットワークリソースを使用するとオペレータに既に承認されたセッションによるネットワーク利用の現状に基づいて新サービスセッションをコントロールさせる。ネットワーク利用ベースポリシーはＣＭＴＳ利用、ＣＭＴＳポート利用、ＣＭＴＳ−ＤＯＣＳＩＳチャンネル利用、ＣＭＴＳ−ＤＯＣＳＩＳスケジュールタイプ利用、等々に基づいて行うことができる。そのようなポリシーの例は“チャンネルのネットワーク利用率が８０％以内であればこのビデオセッションを承認せよ”である。
【００５９】
上述の基準の組合せ応用例は次の通りである。
【００６０】
アプリケーションがビデオストリームである場合、
契約者がゴールド層であれば、
チャンネルのネットワークリソース利用率が８０％以内であれば、
週日であれば、
このセッションを承認せよ。
【００６１】
他の実施例も本発明の範囲内である。
【図面の簡単な説明】
【００６２】
【図１】図１は契約者にマルチメディアコンテンツをデリバーするケーブルネットワークのブロック図である。
【図２】図２は予約プロセスのフロー図である。
【図３】図３は予約される未来キャパシティのグラフである。
【図１】
2008509451.tif 000003
【図２】
2008509451.tif 000004
【図３】
2008509451.tif 000005
【国際調査報告】
2008509451.tif 000006