JP5612105B2 - データ・サービスに対するスケーラブルなビデオ制御帯域幅の割り当て - Google Patents

Description

本発明は、ある量の帯域幅をデータ接続を介したデータとしてコンテンツ情報の移送に割り当てる方法に関するものである。本発明は、また、コンピュータ可読媒体に格納され、コンピュータによって起動される際に、ある量の帯域幅について、データ接続を介したデータとしてコンテンツ情報の移送への割り当てを制御するソフトウェア制御に関するものである。本発明は、更に、データ接続を介したコンテンツ情報のデータとして移送に対してある量の帯域幅の割り当てを制御するように構成される、データ処理システムに関するものである。

従来技術

ＩＰマルチメディア・システム（ＩＭＳ）がインターネット・プロトコル（ＩＰ）のマルチメディア・サービス、例えば、インターネット・プロトコル・テレビジョン（ＩＰＴＶ）をデリバリするためのアーキテクチャ・フレームワークであることは公知のことである。ＩＰＴＶが、ＴＶ番組をセット・トップ・ボックス（ＳＴＢ）を介し、またハイ・スピード・インターネット（ブロードバンド）接続を通じてテレビジョンにデリバリすることを可能とするデジタル・テレビジョン・サービスであることは公知のことである。ＩＭＳアーキテクチャをインターネットのようなＩＰネットワークと機能的に統合するのを容易にするために、ＩＭＳは、標準のインターネット・プロトコル、例えば、ＳＩＰ（セッション開始プロトコル）を用いる。ＳＩＰは、マルチメディア通信セッション、例えば、ＩＰを利用したボイス・コールやビデオ・コールを制御するために用いられるシグナリング・プロトコルである。ＩＭＳは、通例、リソース・アドミッションおよびチャージング・システム（ＲＡＣＳ）を有している。ＲＡＣＳは、アドミッション制御を提供する。当該ＲＡＣＳは、例えば、加入者が要求するサービスの認可を検査し、関係するネットワーク運用業者に特有のポリシ・ルールを検査し、そして要求されたネットワーク・リソース（例えば、帯域幅）が、加入者のユーザ・プロファイルやネットワーク・リソースの現在のスケーラビリティに適合するものかを検査し、仮にそうであるならば、リソースを割り当てるように構成される。

ネットワーク・リソースは、帯域幅を固定する、ある量の帯域幅を保証された最低値でフレキシブルに割り当てる、または低レイテンシを要求する（これは、例えばゲームに関係する）といった多くの方法で割り当てることができる。ビデオ映像をデリバリし、および／または２者間通信を可能にするために、ネットワーク・サービスは、通例、受け入れ可能なサービス品質（ＱｏＳ）および／または受け入れ可能な知覚経験品質（ＱｏＥ）についての最低保証量の帯域幅を必要とする。

実際のところ、利用可能な量の帯域幅は限られており、望まれる時点でＱｏＳおよび／またはせービスのスケーラビリティに影響することもあり得る。このことは、次のようなシナリオで説明される。

第１のシナリオでは、エンド・ユーザは、例えばＡＤＳＬ(非対称デジタル加入者線)といった専用のリンクを介したサービス・プロバイダに接続される彼／彼女の処理装置を有している。この接続は、制限量の帯域幅を有している。サービス提供者が三重のサービス、即ち、ビデオ・サービス（例えば、インターネット・テレビジョン、ビデオ・オン・デマンド（ＶｏＤ））、通信サービス（例えば、ボイス・オーバーＩＰ（ＶｏＩＰ）、ビデオ会議など）、およびインターネット・サービス（例えば、Ｗｅｂページ、ゲームへのアクセス）を提供する場合、これらサービスがこのユーザの単一接続の帯域幅を共有する。更に、ＡＤＳＬ２接続の総帯域幅が、例えば１２Ｍｂｐs（メガビット毎秒）であり、ビデオ・ストリーム（例えば、デジタル・テレビジョン・チャネル）が例えば４Ｍｂｐｓを必要とするとする。このユーザが同時に３つのビデオ・ストリームを視聴(watch)する場合、彼／彼女はそのインターネット・サービスを利用することができず、または通話の受信をすることができない。その替り、このユーザがインターネット・サービスまたは電話サービスを使用していると、彼／彼女は２つ以上のテレビジョン・チャネルを視聴することはできない。

第２のシナリオでは、多数ユーザが例えば、ケーブル・インフラストラクチャ（ＤＯＣＳＩＳ）、インターネットに接続されたホーム・ネットワーク、または無線インフラストラクチャ（ＧＳＭ、ＵＭＴＳ、またはＷｉＦｉ）におけるある量の帯域幅をシェアする。その結果、全てのユーザが全ての帯域幅を使用できるわけではない。明確にするため、頭文字「ＤＯＣＳＩＳ」は「データ・オーバー・ケーブル・サービス・インターフェース仕様」(Data Over Cable Service Interface Specification)の略であり、また、データ・オーバー・ケーブル・システムについての通信および動作のサポート・インターフェース要件を規定する国際標準を受けるものである。頭文字「ＧＳＭ」は「モバイル通信についてのグローバル・システム」(Global System for Mobile communication)の略であり、移動体電話のセルラー・ネットワークに関する。頭文字「ＵＭＴＳ」は、「ユニバーサル・モバイル・テレコミュニケーション・システム」(Universal Mobile Telecommunication System)の略であり、ＧＳＭに関する第３世代移動通信技術を受けるものである。頭文字「ＷｉＦｉ」は、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅの商標であり、例えば、ＰＣ、ビデオ・ゲーム・コンソール、移動体電話またはＭＰ３プレイヤといったワイヤレス・ネットワークを介してインターネットにするためのデータ処理装置を提供する。仮にあるユーザが帯域幅のほとんどをしようするとしたら、このことは他のユーザに利用可能な量の帯域幅を犠牲にすることになるであろう。この問題に対する現在の解決策は、個々のユーザごとに対して、ある特定の量の帯域幅に制限することであり、また、多数のユーザ間で利用可能な総帯域幅を分割することである。他の解決策は、ベース・レイヤおよび１またはそれ以上の強化(enhancement)レイヤの階層的コーディング・スキームでエンコードされたコンテンツ情報の管理に関する。ワイヤレス・アクセス・ポイントは、ネットワーク損失（ＷｉＦｉでグレーション）が発生したかを検出するために、無線チャネルを測定することができる。この測定に基づいて、アクセス・ポイントが１またはそれ以上の強化レイヤの欠落を判定することができ、ベース・レイヤのストリームを送ることができたかを確証する。更に他の解決策は、新しいセッションを再ネゴシエーションして、帯域幅の使用を調整することである。

KOFLER I他、「Ｈ．２６４／ＳＶＣ適用およびトラフィック・コントロールによるＩＰＴＶサービスの改良」(Improving IPTV services by H.264/SVC adaptation and traffic control)、ブロードバンド・マルチメディア・システムおよびブロードキャスティング、２００９年ＢＭＳＢ ‘０９ ＩＥＥＥ国際シンポジウム、ＩＥＥＥ，ＮＪ，ＵＳＡ，２００９年５月１３日（2009-05-13）の第１−６頁には、シグナリングされた拡張性情報に基づいて要求されたビデオ映像についてのアドミッション制御を実行するＲＴＳＰ／ＲＴＰプロキシ・サーバを傍受(intercept)して、コンテンツが変化なくまたは適用バージョンでストリームすることができるかを判定することが開示されている。ビデオ・ストリームに対するハード予約ポリシ(Hard Reservation Policy)アドミッション制御および適用はアドミッションの後にビデオ帯域幅の割り当てを修正しない。フレキシブル貸出ポリシ(Flexible Borrowing Policy)はアドミッション制御をＳＶＣストリームのベース・レイヤに対して制限し、強化レイヤのデータを搬送するパケットは、優先度と共にマーキングされ、優先度ベースのキューイング機構によりネットワーク・レイヤにおいて取り扱われる。

現在のリソース・アドミッション・システムは、十分な帯域幅を割り当てることができなときに、特定のサービス要求を不許可にすることにより帯域幅の問題を解決している。

本発明は、今、以下のシナリオを想定している。即ち、１またはそれ以上のサービスが、管理されるデータ接続、例えば、管理データ・ネットワークを介してエンド・ユーザのデータ処理システムに提供される。管理データ接続では、アドミッション制御が、データ接続をオーバーロードするために、また、輻輳を防止するために用いられる。前記サービスのうちの特定の１つが、データ接続を介して、ビデオ、オーディオ、またはマルチメディアといったコンテンツ情報を提供することに関連している。このコンテンツ情報は、階層型コーディング・スキームにおいて利用可能である。階層型ビデオ・コーディング・スキームがベース・レイヤおよび１つ以上の強化レイヤを含むことは公知である。強化レイヤは、レンダリングされる際にビデオ・コンテンツ情報の解析(resolution)を増加するためにベース・レイヤと統合することができる。階層型コーディング・スキームを用いるビデオ・コーディング基準には、スケーラブル・ビデオ・コーディング（ＳＶＣ）、ＭＰＥＧ−２、ＭＰＥＧ−４ ＡＳＰ／ＦＧＳ、Ｈ．２６３、Ｈ．２６３＋、などが含まれる。頭文字「ＭＰＥＧ−４」は、ビデオ・データ圧縮についての標準的なスケーラブル・コーディング・スキームの略である。様々な応用に対応するために、スキームはいくつものプロファイルを有している。各プロファイルは、意図した適用に対してスキームをあわせるのに用いることができる。最も共通的に展開されるプロファイルは、シンプル・プロファイル（ＳＰ;Simple Profile）、および先進シンプル・プロファイル（ＡＳＰ;Advanced Simple Profile）である。ＡＳＰは、拡張された帯域幅のバージョンのＳＰである。頭文字「ＦＧＳ」は、「細粒状スケーラブル・プロファイル」(Fine Granularity Scalable Profile)の略であり、スケーラビリティ（可用性）を提供するエンコーディング技術のことをいう。ＡＳＰとＦＧＳとの組み合わせが「ストリーミング・プロファイル」(Streaming Profile)である。オーディオ・コーディング基準は、階層型コーディング・スキームにおいて用いられ、ＭＰＥＧ−４オーディオ（ＡＡＣ−ＳＳＲ）およびＭＰＥＧ−４ＳＬＳを含む。頭文字「ＡＡＣ」は、「先進オーディオ・コーディング」(Advanced Audio Coding)の略であり、ＭＰＥＧ−２およびＭＰＥＧ−４仕様についてのオーディオ圧縮フォーマットである。頭文字「ＳＳＲ」は、「スケーラブル・サンプリング・レート」(Scalable Sampling Rate)の略である。頭文字「ＳＬＳ」は、「損失レスなオーディオ・コーディングに対してスケーラブル」(Scalable to Lossless Audio Coding)の略である。

本発明の一実施形態においては、接続を有するあるノード、例えば、１またはそれ以上のエンド・ユーザが有するデータ処理装置、または当該エンド・ユーザのデータ処理装置が有するデータ・ネットワークへのアクセス・ポイントが監視されている。ノードにおけるデータ・トラフィックは、現在利用されているデータ・サービスの数および種類に関して監視される。ポリシ制御サーバは、予め決められたポリシにおけるコンテンツ情報のデータ・デリバリによって消費される帯域幅を調整するように動作する。

本発明の一実施形態は、移送を開始する前に、ある量の帯域幅を、データ接続を介したデータとしてコンテンツ情報の移送に割り当てる方法に関するものである。このコンテンツ情報は、階層型コーディング・スキームにおいてエンコードされる。階層型コーディング・スキームは、ベース・レイヤおよび少なくとも１つの強化レイヤを用いる。本方法は、データ接続が、当該データ接続を介した更なるデータとして更なるコンテンツ情報の更なる移送用に用いているかどうかを判定するステップを備える。本方法は、また、更なる移送について１またはそれ以上の更なる属性を決定するステップを含む。本方法は、更に、前記更なる移送の１またはそれ以上の更なる属性に従う予め決められたポリシの制御下での移送について１またはそれ以上の強化レイヤの数を決定するステップを備えることができる。

本発明の一実施形態では、上記更なる移送の１またはそれ以上の属性が、予め決められたポリシの制御下において上記移送に割り当てられることになる帯域幅の量を決定する。この予め決められたポリシは、前もって用意された１組のルールを含む。当該ルールは決定した更なる属性に適用されて、結果を生成する。当該結果に基づいて、１つ以上の強化レイヤの数が選択される。従って、同一のデータ接続を介して何が既に移送されているかに従って、コンテンツ情報における強化レイヤの数を設定することによって、運用業者は、例えば、部品(piece)の数またはロード・バランスに関し、同一のデータ接続を介して移送されているコンテンツ情報が有する部品の適応を最適化することができる。勿論、上記移送のために利用可能な帯域幅がベース・レイヤを収容することにのみ十分である場合には、供給される強化レイヤの数を零とすることができる。これらの状況下では、本発明は、追加の帯域幅がこの特定のコンテンツ情報のストリームに利用可能である限りにおいて、１またはそれ以上の強化レイヤを追加することができるのみである。

更なる属性は、次のもののうち１またはそれ以上を含むことができる。即ち、コンテンツ情報に対する更なるコンテンツ情報の相対的な人気度、更なるコンテンツ情報の意味論的(semantic)な側面、データ接続を介して発信先に移送される更なるコンテンツ情報について表す更なるデータの発信先、並びに、更なるコンテンツ情報について表す更なるデータの発信元、更なるコンテンツ情報の移送を開始した時刻、更なるコンテンツ情報の更なるエンド・ユーザの識別情報である。

例えば、更なるコンテンツ情報の相対的な人気度または各優先度が、コンテンツ情報のそれよりも高い場合、コンテンツ情報の移送に割り当てられる量の帯域幅は、コンテンツ情報がより高い相対的な人気度またはより高い優先度を有している場合よりも少ないものとなる。

この相対的な人気度は、例えば、各コンテンツ情報のデリバリに対するエンド・ユーザが要求する各数に基づいて決定される。この数は、エンド・ユーザの人気度に対するエンド・ユーザの要求の履歴に基づくか、または、コンテンツ・プロバイダの予想に基づくことができる。例えば、国家元首の就任、またはＵＥＦＡチャンピオンズ・リーグの決勝といったライブ・イベントについての第１のＩＰＴＶ放送は、よく知られた映画の（他のチャネル上の）第２のＩＰＴＶ放送よりも人気があるであろう。より多くの人々が第２放送よりも第１放送を見ていることになる。映画の移送が開始されると、より少量の帯域幅が、就任ついてのライブ放送の移送の場合よりも割り当てられることになる。

更なる属性「意味的側面」について、移送が開始されるコンテンツ情報が子供向けのＴＶ番組であると想定する。運用業者は、事前にルールを用いてポリシを決定しており、更なるコンテンツ情報が映画である場合には、その子供向けＴＶ番組に割り当てられる帯域幅が、更なる情報がアニメである場合よりも少なくすることを特定している。

属性「発信先」（例えば、特定のデータ・ネットワーク・アドレスでのエンド・ユーザ機器）について、いくつかの発信先が他のものより重要であるとみなすことができる。例えば、更なるコンテンツ情報の発信先が、データ・ネットワークを介した更なるコンテンツ情報の更なる発信先についてのマルチキャスト・サーバであると想定する。その場合、コンテンツ情報に割り当てられる帯域幅は、更なるコンテンツ情報の発信先が個々のエンド・ユーザについての受信者である場合よりもより少なくする。

更なる属性「発信元」（例えば、コンテンツ・プロバイダ）について、発信元は、サービス・プロバイダと共に構成することができ、これらのコンテンツ情報の移送に対する帯域幅を、別の発信元からの他のコンテンツの移送に対するものより多くする。従って、開始されるコンテンツ情報の移送に割り当てられる量の帯域幅は、移送が既に始まった更なるコンテンツ情報の発信元に従う。

更なる属性「エンド・ユーザの識別情報」について、帯域幅が利用可能であるとして、他のエンド・ユーザよりも多い強化レイヤを用いてコンテンツ情報を受信するために、プレミアム加入料金をサービス・プロバイダに支払ってきたユーザもいる。更なるコンテンツ情報のエンド・ユーザがプレミアム加入料金を支払ってきた加入者であり、また、コンテンツ情報のエンド・ユーザがより少額の加入料金を支払ってきた加入者であるときには、コンテンツ情報のエンド・ユーザがプレミアム加入者であった場合よりも、コンテンツ情報の移送に割り当てることができる帯域幅をより小さくすることができる。

更なる属性「時刻」について、更なるコンツ情報の移送の時間がプライム・タイム、即ち、夕方の真ん中であると想定する。プライム・タイムとは、一番多くの視聴者がいる時間間隔であるため、放送局は、プライム・タイムにおいてブロードキャストされる番組から放送局広告予算のほとんどを受け取る。それ故、他の時間におけるよりもプライム・タイムにおける帯域幅の方をより高価なものとすることができる。このことは、ビジネス・モデルにもなり得、移送がプライム・タイムの間に開始されるコンテンツ情報に割り当てられる帯域幅が、他の時間に生じる移送のコンテンツ情報に割り当てられるのと比べて、より少なくなる。

本方法の一実施形態においては、更なるコンテンツ情報は更なる階層型コーディング・スキームでエンコードされる。この更なる階層型コーディング・スキームは、更なるベース・レイヤおよび１またはそれ以上の強化レイヤを用いる。一実施形態においては、本方法は、更なる移送の帯域幅について更なる量を調整するステップを備える。当該調整するステップは、１またはそれ以上の移送の属性を決定するステップ、および、第１の移送における１またはそれ以上の属性に従った予め決められた更なるポリシの制御下において、更なる移送における更なるコンテンツ情報の１またはそれ以上の更なる強化レイヤについての更なる数を決定するステップを備える。

再度、属性は、必要な変更を加えて、更なる属性について上述したのと同一の種類とすることができる。

本発明は、トランスポート・セッションを停止する必要なく、また、帯域幅といった新たに割り当てられるリソースに対して新たなセッションを再ネゴシエーションする必要がない。更なるコンテンツ情報のトランスポート・セッションは、１またはそれ以上の強化レイヤがブロックされることを除いて継続する。このことを実現するメカニズムの実装について、更に以下に説明する。

本発明の利点は、公知の手法に比べて、データ接続においてある総帯域幅が利用可能であるときに、より多くのコンテンツ情報デリバリ・サービスを提供し、また、任意の所与の時間において消費されるコンテンツ情報がより少ないときに、より高品質なデリバリを提供する能力を与えることである。例えば、１０Ｍｂｐｓの帯域幅が、２つの高品質な４Ｍｂｐｓビデオ・ストリームに適合することを可能にする。仮に３つ目のビデオ・ストリームが要求されたら、３つのビデオ・ストリーム全てが３Ｍｂｐｓという妥当な品質を用いてデリバリされるのであろう。後に、これらビデオ・ストリームのうちの１つが停止したら、状況は、２つのビデオ・ストリームをデリバリすることに戻り、残りのストリームの両方にそれぞれ４Ｍｂｐｓの帯域幅を再度割り当てることができる。

他の利点は、次に関するとおりである。ホーム・ネットワークは、例えば、ＳＴＢ、ネットワーク接続可能電話、ネットワーク・インターフェイスを有するコンピュータ等の異なるデータ処理デバイスを一般的に備えるものである。これらのデバイスは一般的にお互いの存在認識していない。帯域幅の割り当てをアクセス・ネットワーク、および／またはアクセス・ノードで管理することによって、これらデバイスは相互に認識しないままとすることができる一方で、帯域幅の仕様をそれでも最適化することができる。アクセス・ノードにおいて帯域幅の割り当てを管理することにより、また、異なるホーム・ネットワーク間、または共有したメディア（例えばケーブル、ワイヤレス）を介した電子コンテンツ情報を受信する多数のユーザ間で、帯域幅の割り当てを最適化することができる。アクセス・ネットワークの替わりに、帯域幅割り当ての管理は、アップリンクの帯域幅リソースが不足しているときに、エンド・ユーザからコア・ネットワークへのデータ伝送を必要とするサービスのために、例えば住居用のゲートウェイ(residential gateway)で実行することもできる。これは、例えば、ユーザが生成したコンテンツ、またはエンド・ユーザから発するビデオ放送についての場合である。

本発明の一実施形態においては、コンテンツ情報および更なるコンテンツ情報がＩＭＳアーキテクチャを介して提供される。ＩＭＳが、ポリシおよびチャージングの施行機能(Policy and Charging Enforcement Function; PCEF)、並びにポリシおよびチャージングのルール機能(Policy and Charging Rules Function; PCRF)を備えることは公知である。ＰＣＥＦおよびＰＣＲＦの詳細については、さらに図面を参照して以下に説明する。本方法は、ＰＣＲＦに示される１またはそれ以上の強化レイヤのゲーティングを用いて、ＰＣＥＦを介して１またはそれ以上の強化レイヤの数を制御するステップを含む。したがって、本発明は、既存の構成要素(building blocks)を用いて帯域幅割り当てを実施する。

ＩＭＳアーキテクチャを参照した上記の実施に関して、ここでは、本発明がＩＭＳアーキテクチャ以外の管理ネットワークのインフラストラクチャを介して提供されるサービスにおいても実施することができることを注記しておく。一般的には、管理ネットワークにおいては、エンド・ユーザは前もって知られており、管理ネットワークを介した通信同様、管理ネットワークへのアクセスは制御される。このような同様の他の管理ネットワークは、ＩＭＳアーキテクチャを参照して説明したものと対応の機能を有する。即ち、個々のアドレスおよび加入、ログイン・コード、アクセス権などについての情報といったエンド・ユーザのプロファイルを格納する第１の機能、ＱｏＳマネジメントの問題について決定するための、制御ポリシを決定するための第２の機能、および当該第２機能によって決定されたポリシを施行するための第３の機能である。勿論、第１、第２、および第３の機能について示すために、（例えば、デジタル・ビデオ放送（ＤＶＢ）に基づく）他の管理ネットワークについて仕様書で用いられる学術用語は、ＩＭＳ仕様で用いられるものとは異なるものとすることができる。しかしながら、本発明の文脈においては、ＩＭＳ仕様の学術用語は、本明細書において管理ネットワーク・インフラストラクチャ全般に適用可能な発明を説明するために用いられる。

上述の実施形態は、方法として活用される本発明の例を供する。このような方法は、例えば、サービス・プロバイダやネットワーク・オペレータに商業的に関係するものである。

本発明は、また、コンピュータ可読媒体上に格納される、制御ソフトウェアとして商業的に活用することができる。制御ソフトウェアは、移送を開始する前に、ある量の帯域幅を、データ接続を介してデータとしてコンテンツ情報の移送に割り当てるという制御のために構成される。コンテンツ情報は階層型コーディング・スキームでエンコードされる。当該階層型コーディング・スキームはベース・レイヤおよび少なくとも１つの強化レイヤを用いることができる。制御ソフトウェアは、好ましくは、データ接続が、データを介した更なるデータとして更なるコンテンツ情報の更なる移送について用いているかを判定する第１の命令、更なる移送についての１またはそれ以上の更なる属性を決定する第２の命令、および更なる移送についての１またはそれ以上の更なる属性に従って、予め決められたポリシの制御下で移送についてのコンテンツ情報の１またはそれ以上の強化レイヤの数を決定する第３の命令を備える。

コンピュータ可読媒体は、例えば、磁気ディスク（例えば、ハードディスク）もしくは光ディスク（例えば、ＣＤ−ＲＯＭ）上で実装されるメモリ、または半導体メモリ（例えば、メモリ・スティックもしくは集積回路チップとして実現されるもの）を含む。

本発明による制御ソフトウェアは、例えば、ソフトウェア・プロバイダまたはセット・メーカに商業的に関係することができる。制御ソフトウェアは、例えば、住居用のゲートウェイ(residential gateway)、またはデータ・ネットワーク、ルータ、もしくはネットワーク・サーバなどへのアクセスを提供するノード上にインストールすることができる。制御ソフトウェアは、データ・ネットワーク内の複数のそのようなエンティティ内に分散してインストールすることができ、当該エンティティは、協働してソフトウェア制御下において本発明の方法を実施する。

制御ソフトウェアは、ソース・コード、もしくはオブジェクト・コードの形態、または部分的にコンパイルされたフォーマットのような、ソース・コードとオブジェクト・コードとの間の中間コードの形態とすることができる。

本発明の制御ソフトウェアの更なる実施形態は、本説明で説明され、および／または付加される方法の従属クレームで特定される、本発明の方法についての様々な実施形態で生じる１またはそれ以上のステップの実行を四魚する命令といった、追加の命令を有することができる。

本発明は、また、ある量の帯域幅を、移送を開始する前にデータ接続を介したデータとしてコンテンツ情報の移送に割り当てることを制御する、データ処理システムとして商業的に活用することができる。コンテンツ情報は、階層型コーディング・スキームでエンコードされる。当該階層型コーディング・スキームはベース・レイヤおよび少なくとも１つの強化レイヤを使用することができる。データ処理システムは、好ましくは、データ接続が、データ接続を介した更なるデータとして更なるコンテンツ情報の更なる移送について用いているかを判定する第１の手段、更なる移送についての１またはそれ以上の更なる属性を決定する第２の手段、および更なる移送についての１またはそれ以上の更なる属性に従って、予め決められたポリシの制御下で移送についてのコンテンツ情報の１またはそれ以上の強化レイヤの数を決定する第３の手段を備える。

データ処理システムは、例えば、住居用のゲートウェイ、データ・ネットワークへのアクセスを提供するアクセス・ノード、ルータ、ネットワーク・サーバに収容することができ、データ・ネットワーク内の多数のこのようなエンティティ内で分散される機能を有する。当該エンティティは、協働して、本発明による方法を実施する。

第１、第２、および第３の手段は、例えば、データ処理システムにおける汎用コンピュータ上にインストールされた制御ソフトウェア、専用の電気回路といった専用ハードウェア、またはソフトウェアとハードウェアの組み合わせのような、様々な方法で実施することができる。再度、当該第１、第２、および第３の手段は、データ・ネットワーク内の多数のエンティティ間で分散することができ、協働して本発明の方法を実施する。

データ処理システムの更なる実施形態は、追加の特徴、例えば、上記説明で説明され、および／または付加される方法の従属クレームで特定される、本発明の方法が有する１またはそれ以上のステップを実行するように動作する特徴を有することができる。

本発明は、例により、および添付の図面を参照することにより、さらに詳細に説明される。

図１は、本発明によるシステムのブロック図である。 図２は、本発明によるシステムのブロック図である。 図３は、図２のシステムの機能図である。 図４は、ＩＭＳアーキテクチャにおけるＱｏＳ管理システムの一部分のみのブロック図である。 図５は、図４のＱｏＳ管理システムを用いた図２のシステムの実施についてのブロック図である。 図６は、図５の実施についての動作を説明するメッセージ・フロー図である。 図７は、図５の実施についての動作を説明するメッセージ・フロー図である。 図８は、図５の実施についての動作を説明するメッセージ・フロー図である。 図９は、本発明によるシステムの別のブロック図である。 図１０は、図９のシステムについての動作を説明するメッセージ・フロー図である。 図１１は、図９のシステムについての動作を説明するメッセージ・フロー図である。 図１２は、帯域幅の割り当てを説明するテーブルである。 図１３は、帯域幅の割り当てを説明するテーブルである。

図面を通じて、類似のまたは対応する特徴は同一の符番により示されている。

本発明の一実施形態は、コンテンツ情報によって消費される量の帯域幅を制御する方法に関するものであり、当該コンテンツ情報は、データ処理装置へのデータ接続を介して第１のデータ・サービスにおいてコンテンツ・情報の発信元(source)によってデリバリされる。当該発信元は、ベース・レイヤおよび少なくとも１つの強化レイヤを含む階層型コーディング・スキームでエンコードされた利用可能なコンテンツ情報を有する。データ処理装置は、データ接続に基づき利用可能な予め決められた第１の量の帯域幅を有している。本方法は、予め決められたポリシに従って、デリバリされるコンテンツ情報における強化レイヤの数を制御するステップを備える。当該数は、更なるデータ・サービスが、データ接続を用いるか否かおよび帯域幅を消費するか否かに従って制御される。

図１は、本発明におけるシステム１００の第１のブロック図である。システム１００は、データ処理装置１０２、当該データ処理装置１０２とアクセス・ノード１０６との間のデータ接続１０４、ならびにポリし制御サーバ１０８を備えている。システム１００は、さらに、１もしくはそれ以上のセッション・サーバ、および／または１もしくはそれ以上のアプリケーション・サーバを備えており、図１ではセッション／アプリケーション・サーバ１１０として選択的に表している。

データ処理装置１０２は、セッション／アプリケーション・サーバ１１０の制御化で、およびデータ接続１０４およびアクセス・ノード１０６を介して、複数のデータ・サービスにおけるコンテンツ情報（例えば、オーディオ、ビデオ映像、マルチメディア）を受信するように構成される。データ処理装置１０２の例として、セット・トップ・ボックス、ＶｏＩＰ電話、パーソナル・コンピュータ（ＰＣ）、およびホーム・ネットワークがある。公知のとおり、ホーム・ネットワークは住居用のローカル・エリアのデータ・ネットワークであり、家庭内で複数の電子デバイスを接続するのに用いられる。ホーム・ネットワークは、住居用のゲートウェイを介して、外部のデータ・ネットワーク、例えば、インターネットや他のワイド・エリア・ネットワーク（ＷＬＡＮ）に接続することができる。住居用ゲートウェイの例として、ＤＳＬ（デジタル加入者線）ルータ、およびケーブル・モデムがある。

アクセス・ノード１０６はコア・ネットワーク（図示せず）にアクセス・ネットワーク（図示せず）と共に接続される。「コア・ネットワーク」や「アクセス・ネットワーク」の特徴は、従来技術において公知であり、サービス・プロバイダと共に複数のエンド・ユーザが各データ接続を介して接続するポイントとしてしばしば参照されるものであり、データ接続の１つがデータ接続１０４として図示されている。データ接続１０４は、例えば、光ファイバ、同軸ケーブル接続（例えば、ＤＯＣＳＩＳ／ケーブル）、銅線接続（例えば、ＤＳＬライン）、または無線接続（例えば、ワイヤレスＬＡＮ若しくはＷＬＡＮ）として実施される。通例は、アクセス・ノード１０６は、多数エンド・ユーザ接続についての分配ポイントである。即ち、何千ものＤＳＬ等の加入者が単一のアクセス・ノードに接続する。このように接続する多数のエンド・ユーザのために、アクセス・ノード１０６とコア・ネットワークとの間のデータ・リンク（図示せず）が高い処理能力（毎秒ギガビット）を有するものとなっている。アクセス・ノード１０６とデータ処理装置１０２との間のデータ接続１０４は、例えば、様々なデータ・リンクを実装する技術に基づき、また、データ処理装置１０２のエンド・ユーザとのサービス・アグリーメントに基づいて、毎秒キロバイトから毎秒何百メガバイトまでの範囲で処理能力を有している。

セッション／アプリケーション・サーバ１１０は、例えば、データ処理装置１０２のエンド・ユーザといった、加入者へのデータ・サービスのデリバリを提供、さもなければ制御する。セッション・サーバ（例えば、ＳＩＰ／ＩＭＳサーバ）は、データ接続にわたり施される通信セッションにかかわるエンド・ユーザのセッション状態の情報を追跡するサーバであることは公知である。このようなセッションの例は、インターネット電話やインターネットにわたり施されるビデオ会議セッションである。アプリケーション・サーバ、例えばＩＰＴＶサーバは、第三者、ここではデータ処理装置１０２のエンド・ユーザが利用するためのサービスを提供する。アプリケーション・サーバによって提供されるデータ・サービスの例は、ライブＴＶ放送の提供、ＶｏＤといったコンテンツ・オンデマンドの提供、ＴＶ放送のようなコンテンツ情報の遠隔記録および格納のためのネットワークＰＶＲ（個人ビデオ・レコーダ）の提供、ビデオ会議サービスの提供などである。

セッション／アプリケーション・サーバ１１０のうちの特定の１つは、データ・サービスをデータ処理装置１０２に提供するように構成される。特定のサービスは、電子コンテンツ情報に関し、階層型コーディング・スキームでエンコードされるデータとして提供される。

階層型コーディング・スキームでデリバリすることができる電子コンテンツ情報の例はビデオ映像である。階層型ビデオ・コーディング・スキームにおいては、ビデオ情報は複数のレイヤ、即ちベース・レイヤに１またはそれ以上のレイヤを加えたレイヤでエンコードされる。ビデオ情報がレンダリングされると、１またはそれ以上の強化レイヤはベース・レイヤと統合することができ、レンダリングのみしたベース・レイヤに関連して、ビデオ映像もしくはフレーム・レートの解像度を増やし、および／またはエンド・ユーザが知覚する画像品質を改良する。このことは、同一のビデオ映像が、データ処理能力およびパフォーマンスの点で異なるデータ処理システムによってデコードされることを可能にする。階層型ビデオ・コーディングは、更に、異なるスクリーン・サイズのディスプレイ・モニタ上に同一のビデオ映像を表示することを可能にする。階層型ビデオ・コーディングは、また、動的に変化する異なるネットワーク条件、例えば、利用可能な帯域幅またはワイヤレス・ネットワーク上のインターフェイスの下において、ビデオ・サービスを提供することを可能にする。例えば、ベース・レイヤを、データ接続を介してデリバリされるのを保証する保護レイヤとすることができる。このことは、例えば、ＵＤＰ（ユーザ・データグラム・プロトコル）を介して起動するＲＴＰ（リアルタイム転送プロトコル）といった、ビデオ・データのベース・レイヤをデリバリする適切なデリバリ・プロトコルを用いることによって実現される。ビデオ・データの強化レイヤは、「なくても構わない」(nice-to-have)が、ビデオ映像のレンダリングには通常クリティカルなものではなく、ベスト・エフォートに基づいた他の通信プロトコルを用いて供給することができる。

動作において使用する際、システム１００は、例えば、セッション／アプリケーション・サーバ１１０、および／またはアクセス・ノード１０６において、後者の場合はトラフィック・モニタリングの結果として、現在データ処理装置１０２に提供されているデータ・サービスについて利用可能な情報を有する。

本発明の一実施形態においては、ポリシ制御サーバ１０８はこの情報をアクセス・ノード１０６から、若しくはセッション／アプリケーション・サーバ１１０から、またはこの両方から入手する。ポリシ制御サーバ１０８は、この情報を使用して、複数のセッション／アプリケーション・サーバ１１０のうちの特定の１つからのデリバリ経路における特定の位置でネットワーク・リソースを管理する方法を決定し、特定の１つは階層型コーディング・スキームでエンコードされたデータとしての電子コンテンツ情報を、１またはそれ以上のエンド・ユーザのデータ処理装置に提供する。ポリシ制御サーバ１０８は、これらネットワーク・リソースの管理方法を、予め決められたまたは自動的に生成した、単一のエンド・ユーザ用または多数のエンド・ユーザ用のポリシを適用することによって決定し、コーディング・レイヤへの動的な帯域幅の割り当てを提供する。ネットワーク・リソースの管理は、ネットワークの位置についてアップストリームのデータ・デリバリ経路の部分で行われ、そこは十分でない帯域幅が利用可能な部分、即ち、ネットワーク・ボトルネックである。

システム１００の動作について、ビデオ映像といった階層型コンテンツ情報を分配する例と共に説明する。データ接続１０４を用いたデータ・サービスのあらゆる変更は、ビデオ映像の分配に用いられるレイヤ数を調整するための理由をなり得る。例えば、データ処理装置１０２が２つのビデオ・ストリームを処理しており、データ処理装置１０２のエンド・ユーザがこれを単一のビデオ・ストリーム処理に切り戻すとすると、以前にビデオ・ストリームで使用され、現在スイッチ・オフした量の帯域幅が利用可能となる。残ったビデオ・ストリームは、それ故、より多くの帯域幅を利用することができる。その結果として、残ったビデオ・ストリームについての強化レイヤの数はより高品質なものに増やすことができる。

別の例として、データ処理装置１０２がビデオ・ストリームを処理しており、当該データ処理装置１０２のユーザがデータ接続１０４を通じて電話を受けると想定する。ビデオ・ストリームの１またはそれ以上の強化レイヤは、電話用の帯域幅を解放するために（一時的に）欠落される。

別の例として、データ処理装置１０２がビデオ・ストリームを処理しており、当該データ処理装置１０２のユーザがデータ接続１０４を介して電子ファイルのダウンロードを始めたことを想定する。このダウンロードは、例えば、アクセス・ノード１０６において、１またはそれ以上の強化レイヤのどれがダウンロードをスピードアップするために欠落することができるかに応じて、検出することができる。

更に別の例では、データ処理装置１０２内の複数のデバイスは、例えば、当該デバイスが同一のＩＰＴＶチャネルに合わせられてきて、同一のビデオ映像を消費するとしたとき、この特定のビデオ映像が、同時に、デバイスのうちの異なったものに送信される異なったビデオ映像のうちの各１つよりも多い強化レイヤを含むことができる。

ネットワーク・デバイスを管理する方法を決定できるようにするために、ポリシ制御サーバ１０８は、例えば、データ処理装置１０２に利用可能な帯域幅といったデータ処理装置１０２に現在提供されているサービスの種類
について知らされる必要があり、このサービス種類は、サービス記述、サービスによって必要とされる帯域幅の特性、階層型コーディング・スキームにおいて利用可能なコンテンツ情報のデリバリを含むセッションのスケーリング、レイヤ特性のコーディング、コンテンツ情報を受信する受信器の数、などを含む。

基準(criterion)「データ処理装置１０２に利用可能な帯域幅」について、これは、データ処理手段１０２に利用可能な総帯域幅、または、特定のデータ・リンク上のみ、例えば特定の仮想ＬＡＮ（ＶＬＡＮ）上のみでデータ処理装置１０２に利用可能な帯域幅ということになろう。データ処理装置１０２に利用可能な帯域幅は様々な方法で決定することができる。例えば、利用可能な帯域幅は、アクセス・ノード１０６で測定することができる。別の例では、利用可能な帯域幅は、データ処理装置それ自体、例えば、ホーム・ネットワークで測定することができる。ポリシ・サーバ１０８はこの情報を、例えばＳＮＭＰ（ＩＥＴＦ ＲＦＣ １４４１およびＲＦＣ ２５７１）を用いて住居用ゲートウェイに問い合わせることにより、またはＴＲ−０６９（ＤＳＬフォーラム）で情報を抽出することにより入手することができる。頭文字「ＳＮＭＰ」は、「シンプル・ネットワーク・マネジメント・プロトコル」(Simple Network Management Protocol)の略であり、ネットワーク・デバイスの監視、設定、および管理をするためのプロトコルのセットである。頭文字「ＩＥＴＦ」は、「インターネット・エンジニアリング・タスク・フォース」(Internet Engineering Task Force)の略であり、インターネット標準を発達させ促進する組織のことである。頭文字「ＲＦＣ」は、「リクエスト・フォー・コメント」(Request for Comments)の略であり、ＩＥＴＦによって発行される覚書のことである。「ＴＲ−０６９」が示すのは、「テクニカル・リポート０６９」(Technical Report 069)を表すものであり、ブロードバンド・フォーラムの技術仕様である。ＴＲ−０６９は、エンド・ユーザ・デバイスの遠隔管理についてのアプリケーション・レイヤのプロトコルを規定する。更なる他の例では、利用可能な帯域幅は、特定のＶＬＡＮについての予約帯域幅からデータ処理装置１０２に提供される全てのサービスに用いられる帯域幅を差し引いたものに基づいて決定する。帯域幅の計量は、ＳＮＭＰ（ＩＥＴＦ ＲＦＣ １４４１およびＲＦＣ ２５７１）またはＴＲ−０６９（放送フォーラム・ルールＴＲ−６９）のようなプロトコルを介して問い合わせまたはポーリングすることができる。

基準「データ処理装置１０２に現在提供されているサービスの種類」について、この情報は、セッション記述メッセージにおける、例えば、ＩＭＳベース・ネットワークのＳＩＰを用いて、またはＩＰＴＶネットワーク内のＲＴＳＰ（リアル・タイム・ストリーミング・プロトコル）を用いて、セッション・セットアップの間およびセッション・ネゴシエーションの間に抽出することができる。これらのプロトコルを用いて、ＳＤＰ（ＲＦＣ ２３２７）といったセッション記述メッセージをデリバリすることができる。これらのメッセージは、トランスポート・プロトコル、ネットワーク・アドレッシング、オーディオおよびビデオ映像の使用フォーマット、帯域幅要件、などに関連する、（マルチメディア）セションについてのメタ情報を収容する。

基準「サービスにより要求される帯域幅の特性」について、この情報は、セッション・ネゴシエーションの間、ＳＤＰ記述を介して交換することができる。頭文字「ＳＤＰ」は、「セッション記述プロトコル」の略であり、ストリーミング・メディアについてＡＳＣＩＩ文字列での開始パラメータを記述するフォーマットのことをいう。ＳＤＰは、セッション・アナウンス、セッション招待、およびパラメータ・ネゴシエーションの目的のためのマルチメディア（通信）セッションを記述する。代替的には、サービス・プロバイダによって予め決め、または予め構成することができる。例えば、ＩＰＴＶサービス・プロバイダはＩＰＴＶ放送のＴＶに用いられる帯域幅を規定する。サービス・プロバイダは、帯域幅の要件を、彼／彼女がＩＰＴＶエンコーダの制御をしている、または彼／彼女がＴＶストリームを提供するパーティ・コンテンツ・プロバイダと構成したような、要件として認識する。

基準「階層型コーディング・スキームで利用可能なコンテンツ情報のデリバリを含んだセッションのスケーリング」について、コンテンツ情報のプロバイダ、例えばＩＰＴＶプロバイダが、階層型コーディング・スキームでコンテンツ情報をエンコードしてきた。当該コンテンツ・プロバイダは、それ故、一方では用いられる強化レイヤの数と、他方ではレンダリングされる際のコンテンツ情報の知覚品質との間の関係についての情報を有する。

基準「コーディング・レイヤ特性」について、クライアント（ここでは、データ処理装置１０２）およびサーバ（ここでは、階層型コーディング・スキームでエンコードされたコンテンツ情報を供給するサーバ１１０のうちの特定の１つ）が、ネゴシエーションの間のセッション・パラメータを決定する。パラメータはレイヤ数、および、レイヤを分配するのに用いられるマルチキャスト・アドレスまたはユニキャスト・アドレスを含む。例えば、ＩＥＴＦから発行されたインターネット・ドラフトである、「ＳＶＣビデオのためのＲＴＰペイロード・フォーマット」(RTP Payload Format for SVC Video)、draft-ietf-avt-rtp-svc-18.txt、編集者Ｓ．Ｗｅｎｇｅｒ等、２００９年３月６日は、ＲＴＰを用いたＳＶＣビデオを分配する様々な方法について明記する。第１の方法は、別個のストリームとして複数のレイヤを送信するステップを含む。複数のレイヤのそれぞれ１つずつは、次いで、それぞれのマルチキャスト・アドレスを用いて送信され、またはユニキャスト・デリバリが、各ユニキャスト・アドレスおよび／もしくは各ポート番号を用いて送信される。第２の分配の方法は、データ・ストリームの結合としてレイヤを送信するステップを含む。異なるＳＶＣレイヤが単一のＲＴＰストリームとして送信される。ネットワーク抽象化レイヤ（ＮＡＬ）の識別子は、特定のＳＶＣレイヤを決定し、これにＲＴＰパケット・ペイロードが属する。第３の分配方法は、第１の分配方法および第２の分配方法の組み合わせを含む。

基準「コンテンツ情報の使用」について、当該使用は、セッション・セットアップを分析する手段により決定することができる。セッション・セットアップは、データ処理装置１０２と、階層型コーディング・スキームでエンコードされるデータとしてのコンテンツ情報を供給する複数のサーバ１１０のうちの特定の１つとの間のメッセージ交換を起こす。例えば、ＩＰＴＶの場合のシナリオを考慮する。ＳＩＰメッセージおよび／またはＲＴＳＰメッセージは、要求されたＴＶチャネルについての情報を収容する。ＩＧＭＰグループ結合メッセージは、ＴＶチャネルに変換することができる。ホスト、例えばデータ処理装置１０２がマルチキャスト・グループに供給されるエンコードされたコンテンツ情報を受信するためにマルチキャスト・グループを結合すると意図したときに、ＩＧＭＰグループ結合メッセージが、そのホストによって送られる。代替として、コンテンツ情報の使用は、データ・ネットワーク・トラフィックをスヌープする手段によって決定することができる。エンコードされたコンテンツ情報の使用を決定する更なる他の方法は、データ・ネットワーク管理を分析することである。例えば、サービス・プロバイダは特定のＳＴＢ、例えば、データ処理装置１０２のログ情報を、データ・ネットワークの管理目的のためにコア・ネットワークに転送することができる。視聴されるＴＶチャネルは、このログ情報に基づいて決定することができる。上記用いられた頭文字「ＩＧＭＰ」は、「インターネット・グループ・マネジメント・プロトコル」(Internet Group Management Protocol)の略であり、インターネット・プロトコル・マルチキャスト・グループのメンバシップを管理する通信プロトコルのことである。ＩＧＭＰは、ＩＰマルチキャスト仕様についての必須部分であり、ＩＰホストおよび隣接するマルチキャスト・ルータによって用いられ、マルチキャスト・グループのメンバシップを生成する。明確のために、ＩＰバージョン６（ＩＰｖ６）において、ネットワーク・マルチキャストのメンバシップ要求はＩＧＭＰでは扱われない。その替わり、マルチキャスト・リスナ発見（ＭＬＤ）プロトコル（ＩＥＴＦ ＲＦＣ ２７１０）またはＭＬＤプロトコル・バージョン２（ＲＦＣ ３８１０およびＲＦＣ４６０４）が用いられている。ＭＬＤの用語において、マルチキャスト・グループ結合メッセージは、「マルチキャスト・リスナ・レポート」と呼ばれる。

上記の基準(criterion)に基づいて、ポリシ制御サーバ１０８は、データ処理装置１０２へのデータ接続１０４における帯域幅の消費に含まれるネットワーク・リソースを管理するポリシを決定する。このポリシは、施行されて、効果を生じる。本発明においては、ポリシ施行は、エンコードされたコンテンツ情報の特定の強化レイヤのデータを収容するデータ・パケットを制御可能に欠落または通過させるのに用いられる。決定したポリシは、分散ネットワーク内の異なる位置において施行することができる。

一例として、ポリシは、データ処理装置１０２におけるホーム・ネットワークの住居用ゲートウェイで施行される。当該住居用ゲートウェイはアップリンク方向で階層型コンテンツ情報を管理する。通例の例では、アップリンク・リソースがまばらであるときには、多数ユーザに（アプリケーション・サーバへの）インターネットに対してＳＶＣビデオをブロードキャストすることを可能にする。

別の例として、ポリシはアクセス・ノード１０６で施行される。この手法は、シナリオが実行可能であり、階層型コンテンツ情報は、その間にデータ処理装置１０２がある異なる多数の家庭におけるデータ処理装置の多数の部品(piece)用として予定され、同一のデータ接続１０４を共有する。例えば、多数の家庭がデータ接続１０４（例えばＤＯＣＳＩＳネットワークにおけるような）の帯域幅を共有する。同一の手法が別のシナリオで実行可能であり、階層型コンテンツ情報が１つの家庭で多数ユーザ用として予定され、即ち、多数ユーザが同時にデータ処理装置を利用する。データ接続１０４の帯域幅は、次いで、同一のデータ処理装置１０２、例えばホーム・ネットワークの多数ユーザ間で共有される。

さらに別の例として、ポリシはネットワーク・ノード、例えば、ルータ（図示せず）において施行される。当該ネットワーク・ノードは、次いで、その間にアクセス・ノード１０６がある多数アクセス・ノード用として、または多数家庭用もしくは多数エンド・ユーザ用途して予定された階層型コンテンツ情報を管理するように構成される。例えば、多数アクセス・ノード用として予定される階層型コンテンツ情報の管理は、マルチキャストＩＰＴＶチャネルの分配のためにコア・ネットワークの使用を最適化することを含む。

図２は、本発明のシステム２００についての第２のブロック図であり、多数家庭または多数ユーザが帯域幅を共有するシナリオについて説明する。システム２００は、図１を参照して上述したようなシステム１００のコンポーネントを備えている。即ち、データ処理装置１０２、データ接続１０４、アクセス・ノード１０６、ならびにポリシ制御サーバ１０８およびセッション／アプリケーション・サーバ１１０である。当該システム２００は、また、１またはそれ以上の個数の更なるデータ処理装置を有している、例えば、データ処理装置２０２である。データ接続１０４はデータ処理装置１０２をデータ・リンク２０４およびアクセス・ネットワーク２０６を介してアクセス・ノード１０６に結合し、データ・リンク２０８、およびデータ処理装置２０２をアクセス・ネットワーク２０６を介してアクセス・ノードに結合するように実施される。

ケーブル・インフラストラクチャ（例えばＤＯＣＳＩＳ）や多くのワイヤレス・システム（ＧＳＭ／ＵＭＴＳ，ＷｉＦｉ，ＷｉＭａｘ，ＬＴＥ，ＤＶＢ−Ｈなど）といったアクセス・ネットワークにおいて帯域幅の共有が発生する。頭文字「ＷｉＭａｘ」は、「マイクロウェイブ・アクセスについてのワールドワイドな相互運用」(Worldwide Interoperability for Microwave access)の略であり、ポイント・ツー・マルチポイント・リンクからポータブルで十分なモバイル・インターネット・アクセスへのワイヤレス・データ伝送を表すＩＥＥＥ８０２．１６に基づく技術のことである。頭文字「ＬＴＥ」は「長期間エボリューション」(Long Term Evolution)の略であり、ＵＭＴＳ（第３世代技術）に続く第４世代モバイル・ブロードバンド規格のことである。頭文字「ＤＶＢ−Ｈ」は、「デジタル・ビデオ・ブロードキャスティング・ハンドヘルド」(Digital Video Broadcasting-Handheld)の略であり、モバイルＴＶフォーマット規格のことである。

システム２００の動作を次の例と共に説明する。多数のユーザが、マルチキャストによりデリバリされる同一のＴＶチャネル上の同一の番組を視聴するという、ＩＰＴＶマルチキャスト・サービスについて考慮する。ユーザは、同一のＴＶチャネルについて個々のストリームを個別に受信することはしない。しかしながら、ストリームは共有アクセス・ネットワーク２０６上に一度だけおかれる。多数ユーザが第１のＴＶチャネルの同一の番組を視聴し、他の１ユーザは第２のＴＶチャネルの別の番組を視聴するというシナリオについて考慮する。当該多数ユーザおよび当該他のユーザの組み合わせからなるグループで知覚されるＴＶサービスの平均品質を最大化するために、第１ＴＶチャネル上の番組は第２ＴＶチャネル上の番組よりもより多くのレイヤでデリバリする。即ち、第１の番組のマルチキャスト・デリバリに割り当てられるのは、第２番組のデリバリに割り当てられる帯域幅よりも高い帯域幅である。

コンテンツ情報、例えばビデオ・ストリームについての実際のスケーリングは、強化レイヤを追加し、または強化レイヤを削除することで実行される。レイヤは、１またはそれ以上の上述した基準(criterion)に基づくポリシ制御下において、ファイアウォール機構またはゲーティング機構を動作することにより欠落させることができ、その結果、どの強化レイヤを欠落させるべきかを判定する。ファイアウォール機構またはゲーティング機構は、強化レイヤが追加される際に非活性化される。

当該スケーリングは、データを移送するのに用いる機構に従って様々な方法により実施することができる。

例えば、１またはそれ以上のレイヤが、各個別のＲＴＰ毎の各個別のレイヤごとに移送される。異なるマルチキャスト・アドレスがレイヤ毎に用いられる。ユニキャストの場合、ストリームは異なる発信元ポート番号からのものと異なる送信先ポート番号のものとの両方がある。適切にストリームを処理するために、受け取るクライアントは、レイヤのうちのどの１つがストリームのうちどの１つに収容されているかについて知らされるべきである。この情報は例えばＳＡＰアナウンスにおいて提供される。頭文字「ＳＡＰ」は、「セッション・アナウンス・プロトコル」(Session Announcement Protocol)の略であり、マルチキャスト・セッション情報をブロードキャストするコンピュータ・プロトコルのことである。代替的に、どのストリームをどのレイヤが収容しているかについての情報が、クライアントとサーバとの間のセッション・ネゴシエーションで提供される。

スケーリングを実施する別の例として、１またはそれ以上のレイヤが移送され、個々のネットワーク抽象化レイヤ（ＮＡＬ）ごとの各個々のレイヤは、Ｈ．２６４／ＡＶＣビデオ・コーディング規格で用いられる。ＮＡＬは次いで、単一のＲＴＰストリーム内の異なるメディアを移送するために、ＲＴＰで利用可能なコンテナについて考慮される。各ＮＡＬはそれ自身の識別子を有しており、それはＲＴＰヘッダの部分である。

図３は、図２を参照して上述したシステム２００の図であり、本発明の機能的な態様を説明する。上述したように、データ処理装置１０２およびデータ処理装置２０２がコンテンツ情報を受信し、当該コンテンツ情報は階層型コーディング・スキームでエンコードしたようにセッション／アプリケーション・サーバ１１０において利用可能である。ポリシ制御機能３０２およびポリシ施行機能３０４は、一方ではセッション／アプリケーション・サーバ１１０と、他方ではデータ処理装置１０２およびデータ処理装置２０２の間で実施される。

ポリシ制御機能３０２についてはシステム１００および２００のポリシ制御サーバ１０８を参照して上述してきた。

セッション／アプリケーション・サーバ１１０からデータ処理装置１０２およびデータ処理装置２０２へのコンテンツ情報データのフローは、ポリシ施行機能３０４の対象となる。ポリシ施行機能３０４は、ポリシ制御機能３０２で決定されたポリシを施行する。ポリシの施行は、例えば、特定の強化レイヤのデータを含むデータ・パケットを選択的に欠落させる、または転送させることにより、エンコードされたコンテンツ情報の１またはそれ以上の強化レイヤを選択的に通過させる、または選択的に停止することになる。セッション／アプリケーション・サーバ１１０からのコンテンツ情報データのフローは、セッション／アプリケーション・サーバ１１０とポリシ施行機能３０４との間の矢印３０８によって示されている。データ処理装置１０２へのコンテンツ情報のフローは、ポリシ施行機能３０４とデータ処理装置１０２との間の矢印３１０によって示されており、また、データ処理装置２０１へのコンテンツ情報のフロー（必ずしも、データ処理装置１０２へのコンテンツ情報のフローと同一であるとは限らない）については、ポリシ施行機能３０４とデータ処理装置２０２との間の矢印３１２によって示されている。セッション／アプリケーション・サーバ１１０からデータ処理装置１０２、およびデータ処理装置２０２へのデータ・フローは、ポリシ施行機能３０４の対象となる。矢印３１４、３１６および３１８によって示される信号経路は、セッションをセットアップするのにかかわる通信経路であり、データ処理装置１０２およびデータ処理装置２０２が、セッション／アプリケーション・サーバ１１０から利用可能なコンテンツ情報を受信するのを可能にする。矢印３１４は、データ処理装置１０２とポリシ施行機能３０４とを繋ぐ。矢印３１６は、データ処理装置２０２とポリシ施行機能３０４とを繋ぐ。矢印３１８は、ポリシ施行機能とセッション／アプリケーション・サーバとを繋ぐ。矢印３２０および３２２で示される信号経路は、適用される関連するポリシを決定し、決定されたポリシの施行を制御するのにかかわる通信経路である。矢印３２０はセッション／アプリケーション・サーバ１１０とポリシ制御機能３０２とを繋ぐ。矢印３２２は、ポリシ制御機能３０２とポリシ施行機能３０４とを繋ぐ。

ポリシ施行機能３０４の実施例は上述してきたとおりである。

本発明は、特に、管理データ・ネットワーク、例えばポリシ制御やアドミッション制御を有するデータ・ネットワークに適用可能である。本発明の第１の実施例は、以下に説明するように、ＩＰＴＶコンテキストのＩＭＳアーキテクチャについてＱｏＳインフラストラクチャにおいて標準化されたポリシおよびチャージング制御（ＰＣＣ）を用いた動的なレイヤ認(layer-aware)帯域幅管理を説明する。本発明の第２の実施例は、以下に説明するように、またＩＰＴＶコンテキストのアクセス・ノード１０６におけるＲＴＳＰスヌーピングに基づいた、動的なレイヤ認知帯域幅管理について説明する。アクセス・ノード１０６におけるＲＳＴＰスヌーピングの替わり、またはこれに加えて、ＲＴＳＰプロキシを用いることができる。そして、ユーザは、ＩＰＴＶサーバに直接接続するだけでなく、ＲＴＳＰプロキシを介して間接的に接続する。「スヌーピング」との用語は、特定のネットワーク・メッセージを捕獲する目的で、および（任意で）メッセージを発信先への手順を防止する目的で、特定のネットワーク・トラフィック向けにリスンするプロセスのことである。スヌーピングは、発信元と発信先の間のネットワーク・ノードが、例えば発信元と発信先の間のデータ・トラフィック・フローに介在する必要がある場合に用いられ、（例えば、ＲＴＳＰ用の）ネットワーク・メッセージのコンテンツを変更し、または（例えば、ＩＧＭＰ用の）冗長プロトコル・メッセージの伝送を防止する。ＩＭＳアーキテクチャのＰＣＣを用いた第１の実施例については、次の仕様書が参照される。即ち、第１の仕様書として「ＥＴＳＩ ＴＳ １８２０２７ ＴＩＳＰＡＮ ＩＰＴＶ Ａｒｃｈｉｔｅｃｔｕｒｅ：ＩＰＴＶ ｆｕｎｃｔｉｏｎｓ ｓｕｐｐｏｒｔｅｄ ｂｙ ｔｈｅ ＩＭＳサブシステム」、バージョンｖ２．０．０ （ＩＭＳベースＩＰＴＶリリース２）、第２の仕様書として「３ＧＰＰ ＴＳ ２３．２０３ Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ」，バージョンｖ９．０．０である。上記第１の仕様書は、図１のデータ処理装置１０２といったエンド・ユーザの装置がビデオ・ストリームを要求し、終了することができるかについて説明している。上記第２の仕様書は、ＱｏＳがどのように管理されるかについて説明している。ＱｏＳの管理はまた、「ポリシ・ベース・マネジメント」と称され、ポリシ制御（どのアクションを取るべきかについての決定）およびポリシ施行（その決定にしたがってアクションする）からなる。上記第２仕様書はリソースおよびアドミッション制御サブシステム（ＲＡＣＳ）についての別の仕様書と非常に類似している。即ち、「ＥＴＳＩ ＥＳ ２８２００３ ＴＩＳＰＡＮ Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｏｒｌ Ｓｕｂｓｙｓｔｅｍ」、バージョンｖ２．０．０である。

（ＩＭＳアーキテクチャのＰＣＣを用いた）第１の実施例をこれから説説明する。次のシナリオを考慮する。即ち、家庭内の第１の人物が第１のビデオ・ストリームとして受信する第１のビデオ映像の視聴を開始する。その後、家庭内の第２の人物が第２のビデオ・ストリームとして受信する第１のビデオ映像の視聴を開始する。しばらくした後に、第１人物が第１ビデオ映像の視聴を止める。技術的には、後続のプロセスは実行される。第１の人物が第１のビデオ映像の視聴を開始する。第１のビデオ・ストリームは階層型コーディング・スキームでエンコードされたビデオ・データを含む。利用可能な帯域幅は十分にあり、全てのレイヤ（ベース・レイヤおよび１またはそれ以上の強化レイヤ）は第１人物が知覚する最大品質のために用いられる。次いで、第２人物が第２ビデオ映像の視聴を開始する。第２ビデオ・ストリームについての帯域幅を解放するために、第１ビデオ・ストリームの１またはそれ以上の強化レイヤが遮断され、その結果として、第１ビデオ映像の品質が低下する。しばらくした後に、第１人物が第１ビデオ映像の視聴を止める。第１ビデオ・ストリームによって使用されえた帯域幅が利用可能になる。第２ビデオ映像の品質は、第２ビデオの１またはそれ以上の強化レイヤを追加することによって、向上する。

図４は、公知のＱｏＳ管理システム４００の一部分のみを示すブロック図であり、ＩＭＳアーキテクチャのＰＣＣを用いる本発明の第１の実施例を説明する。ＱｏＳ管理システム４００は、次のコンポーネントを有する。即ち、ＳＩＰメッセージを取り扱い、実際にＩＭＳコアの一部を形成するアプリケーション機能（ＡＦ）４０２、「ポリシおよびチャージング・ルール機能」（ＰＣＲＦ）と称され、ＱｏＳ管理で決定されるルールを収容するポリシ制御機能であるエンティティ４０４、エンド・ユーザについての１またはそれ以上のあるプロファイルに関連し、ＱｏＳ管理で決定するのに用いられる任意のユーザ特定ルールまたはユーザ特定情報を含む、ユーザ・プロファイルを収容する加入プロファイル・レポジトリ（ＳＰＲ）４０６、ＰＣＲＦ４０４により決定されるＱｏＳポリシを実行する、ポリシおよびチャージング施行機能（ＰＣＥＦ）４０８である。ＰＣＲＦ４０４は、ＳＰＲ４０６、ＡＦ４０２、ＰＣＲＦ４０８に機能的に接続される。

帯域幅管理に関するＱｏＳポリシは、あるセッションについてある量の帯域幅の許可に基づくルールを含み、また、データ・パケットについてあるストリームを完全に可能にまたは不能にするいわゆるゲーティング機能を含む。データ・パケットのストリームを識別できるために、ＩＰパケットについてのラべルとしていわゆる５タプルを用いることができる。あるＩＰデータ・パケットについての５タプルは、次のものからなる。即ち、データ・パケットの発生源についてのＩＰアドレス（「ソースＩＰアドレス」ともいう。）、データ・パケットの発生源についてのポート番号（「ソース・ポート」ともいう。）、データ・パケットの発信先についてのＩＰアドレス（「宛先ＩＰアドレス」ともいう。）、データ・パケットの発信先についてのポート番号（「宛先ポート」ともいう。）、および用いられるアプリケーション・プロトコルの識別情報である。代替としては、データ・ストリームを識別するために、ディープ・パケット検査(deep-packet inspection)をＰＣＥＦ４０８においてデータ・パケットに適用することができる。これは、より素晴らしく獲得された(fine-gained)制御を可能にする。ＰＣＥＦ４０８はデータ・パケットを解析して、アプリケーション・プロトコルの詳細を決定する。この手法の一例はＲＴＰの詳細を参照し、エンコードされたレイヤに対して情報を提供することができる。

図５は、図２のシステム２００の構成要素および図４の公知のＱｏＳ管理システム４００の構成要素を組み合わせたシステム５００についての別のブロック図である。第１のデータ処理装置１０２および第２のデータ処理装置２０２は、データ接続１０４（図示せず）を共有する。これらは同一の家庭に属しているからである。第１のデータ処理装置１０２および第２のデータ処理装置２０２のそれぞれは、ＩＭＳシステムのコア５０２に接続されている。第１のデータ処理装置１０２および第２のデータ処理装置２０２は、ＳＩＰメッセージを、コアＩＭＳ５０２を用いて交換する。ＳＩＰメッセージは、また、コアＩＭＳ５０２とメディア制御機能（ＭＣＦ）５０２との間で交換される。実際のメディア（ここでは、ビデオ映像）データは、メディア・デリバリ機能（ＭＤＦ）５０６によって、ＰＣＥＦ４０８を介して第１のデータ処理装置１０２と第２のデータ処理装置２０２へ、メディア・データ・パケットを運搬するためのＲＴＰを用いてデリバリされる。ＭＣＦ５０４とＭＤＦ５０６はメディア機能（ＭＦ）５０８のエレメントである。当該ＭＦ５０８は、ＩＰＴＶ環境の一部であり、ＩＰＴＶおよびＶｏＩＰストリーミング・サービスを提供する。ＩＰＴＶサービス機能は、ＩＰマルチキャストおよび／またはユニキャストを通じてライブＴＶストリーミング、並びにＩＰユニキャストを通じてデリバリされる遠隔ビデオ・レコーディングおよびＶｏＤをサポートする。ＭＣＦ５０４はＭＤＦ５０６を制御する。ＭＣＦ５０４はセッション制御およびメディア制御を統合する。セッション制御はＳＩＰ ＩＰＴＶセッションを（ＳＩＰインバイト、リファーを介して）セットアップし、メディア制御は対応するメディア・デリバリ機能またはメディア・ストリームのデリバリを実行するメディア格納機能を選択する。コアＩＭＳ５０２はＰＣＲＦ４０４にダイアミタ・プロトコルを用いて接続される。当該ダイアミタ・プロトコルは、認証・許可・アカウントについてのコンピュータ・ネットワーキング・プロトコルであり、ＩＥＴＦ ＲＦＣ ３５８８規格によって規定されている。ＰＣＲＦ４０４は、ダイアミタ・プロトコルを同様に用いて、ＳＰＲ４０６およびＰＣＥＦ４０８に接続される。より詳細な背景技術、および実施の詳細については、上記第１仕様書および第２仕様書を参照されたい。

図６は、第１のシグナリング図６００であり、第１データ処理装置１０２に関するメディア制御およびメディア・デリバリにかかわるシステム５００におけるメッセージ・フローについて説明している。ＥＴＳＩ ＴＳ １８２０２７によれば、第１データ処理装置１０２はネットワークに接続され、ＩＭＳサービス・プロバイダに登録されていることを想定する。また、第２データ処理装置２０２は非アクティブであり、即ち第２処理装置２０２は共有した接続の帯域幅を消費していないと想定する。第１のシグナリング図６００においては、第１のデータ処理装置１０２は略語「ＤＰＥ１」で示されている。

第１の人物は第１データ処理装置１０２を用いており、ブロードキャスト・セッションを要求する。ステップ６０２で、ＤＰＥ１ １０２はセッション開始要求をコアＩＭＳ５０２に送る。ステップ６０４で、コアＩＭＳ５０２が当該セッション開始要求を適切なＭＦ５０８に転送する。ステップ６０６で、ＭＦ５０８は、用いられるコーデックといったメディアに関する詳細を収容するメディア・オファーをコアＩＭＳ５０２に送る。コアＩＭＳ５０２は、このメディア・オファーに基づいて、ネットワークからリソースを要求する。ステップ６０８で、コアＩＭＳ５０２は、それ故、リソース要求メッセージをＰＣＲＦ４０４に送る。ステップ６１０で、ＰＣＲＦ４０４はユーザ・プロファイルをＳＰＲ４０６から要求し、ステップ６１２でこの要求を受信する。受信したプロファイルに基づいて、ＰＣＲＦ４０４は要求リソースに関する決定をすることができる。この場合、ＰＣＲＦ４０４は要求を認めることを決定する。ステップ６１４で、ＰＣＲＦ４０４はリソース要求をＰＣＥＦ４０８に送る。ステップ６１６で、ＰＣＥＦ４０８はリソースの割り当てをＰＣＲＦ４０４に確認する。ステップ６１８で、ＰＣＲＦ４０４は当該リソース割り当てをコアＩＭＳ５０２に対して確認する。リソースの割り当ての後に、ステップ６２０でメディア供給がＤＰＥ１ １０２に送られる。ＤＰＥ１ １０２は適切なフォーマットを選択し、ステップ６２２および６２４で、メディア回答を、コアＩＭＳ５０２を介してＭＦ５０８に送る。この後に、ＭＦ５０８は、ステップ６２６および６２８で、コアＩＭＳ５０２を介してＤＰＥ１に対し、セッションが確立したことを、セッション開始応答を用いて確認する。次に、メディア制御およびデリバリがＤＰＥ１ １０２およびＭＦ５０８との間で、例えば、メディア制御用にリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）を（ＩＥＴＦ ＲＦＣ ２３２６参照のこと）、およびメディア・デリバリ用にＲＴＰプロトコルを（ＩＥＴＦ ＲＦＣ ３５５０）用いて行うことができる。マルチＩＰＴＶストリームに対しては、通常メディア制御は、ストリームの開始および当該ストリームの停止に対して制限する。これには、通例、ＲＴＳＰの替りにＩＧＭＰを用いて実施される。メディア制御およびデリバリの局面については、符号６３０により示されている。

第１のシグナリング図６００は、ＰＣＲＦ４０４ｔｏＰＣＥＦ４０８との間の通信を、「リソース要求」および「リソース応答」を含むものとして示す。実際には、この通信は、どのポリシ施行が利用可能かに従って様々な方法で実施することができる。このリソース要求およびリソース応答は、通常は、帯域幅の予約と関係する。

上述した例の代替として、ゲーティングを用いることができる。「ゲーティング」という用語は、あるデータ・ストリームを完全にブロッキングする動作のことであり、ファイアウォールで動作する方法と比較される。認識されるあらゆるデータ・ストリームをゲーティングすることができる。階層型コーディング・スキームでエンコードされたビデオ映像に対し、ゲーティングを用いて、特定レイヤのデータ・ストリームをブロックし、他のレイヤのデータ・ストリームに通過させることができる。ゲーティングの処理を制御するために、ＰＣＲＦ４０４は単一のリソース要求を送るのではなく、その替りに、関連のデータ・ストリームを識別するのに必要な情報を収容するゲーティング要求を送る。別の手法は、ＰＣＲＦ４０４はＰＣＲＦ４０８で予め決められたポリシを使用し、ＰＣＲＦ４０４は、単に、セットするのに必要とされるポリシを示すポリシ制御メッセージを送るのみである。

上記シナリオで言及したとおり、同一の家庭内の第２の人物が第２のビデオ映像をストリームすることを要求する一方で、第１の人物がそのセッション内でストリームされている第１のビデオ映像を視聴している。当該第１のビデオ映像は、第１のシグナリング図６００を参照して説明したメッセージ・フローに従ってセットアップされたものである。しかしながら、この第２のビデオ映像に利用可能な帯域幅はもはや十分ではない。例えば、第１ビデオ映像のストリーミングは６Ｍｂｐｓを占める一方で、利用可能な帯域幅全体は１０Ｍｂｐｓに制限される。

この点について、コアＩＭＳ５０２内のどこか、例えば、ＩＭＳアプリケーション・サーバ（図示せず）において解決するとも考えられよう。１つの手法は次のとおりである。第２ビデオ映像に対する要求が最初に拒否される。この後、メディア供給についての再ネゴシエーションが第１ビデオ映像について必要になる。この後に第２ビデオ映像についての再ネゴシエーションが行われる。これは非常に複雑な処理であり、多量のシグナリング・メッセージが必要とされる。ＩＥＴＦ ＲＦＣ ３７２５仕様は、これについてのガイドラインとして提供されるいくつかのメッセージ・フローを与えている。第２のユーザのデータ処理装置２０２について、セッション・セットアップ処理が用いられ、これは第１のユーザのデータ処理装置１０２に対するものと同一である。第２メディア・ストリームに利用可能な帯域幅は十分にはないため、データ処理装置１０２に対するメディア・ストリームは調整する必要がある。ＰＣＲＦ４０４は、いくらかの帯域幅を提供する必要がある第１データ処理システム１０２に供給されるメディアを決定し、コアＩＭＳ５０２に通知する。コアＩＭＳ５０２は、第１データ処理装置１０２のセッションを、ＭＦ５０８、第１データ処理装置１０２、およびＰＣＲＦ４０４にメッセージを送ることにより修正する。その結果、ＰＣＲＦ４０４およびＰＣＥＦ４０８が実際にリソースを修正する。

継続しているセッションの帯域幅をダウンスケールするこの方法には欠点がある。第１の欠点は、ネットワークを介して送られる多くのシグナリング・メッセージを必要とする点で、この方法はネットワーク効率がよくないということである。第２の欠点は、システム全体にまたがる多くのコンポーネントがこの継続セッションの修正に巻き込まれ、これらコンポーネントのそれぞれがこの特定のダウンスケールする方法をサポートすることができる必要があるという点である。第３の欠点は、上記方法を用いてダウンスケールするのを完了するのに幾分時間がかかるということである。シグナリング・メッセージはネットワークにわたり行き来するため、第２のデータ処理装置２０２についてセッション・セットアップする間遅延を生じさせる。関係するシグナリング・メッセージの数は、第１データ処理装置１０２に関して上述したとおり、正規のセッション・セットアップに必要とされる数に比べてほぼ倍である。第２のユーザにより知覚されるメディア・サービスの応答性は、第１のユーザが経験した応答性よりはるかに悪いものとなることになる。この文脈において、ＴＶチャネルを素早くスイッチする（即ち、ザッピングする）ユーザのことを考慮すると、ユーザがザッピングしている間のＴＶサービスの遅い反応性は、ユーザが欠点として知覚するものである。

図７は、第２のシグナリング図７００であり、第１データ処理装置１０２が既に第１のビデオ映像の受信にかかわっているときに、第２のビデオ映像を要求する第２のデータ処理装置２０２について、メディア制御およびメディア・デリバリにかかわるシステム５００でのメッセージのフローに関する発明を説明している。第２シグナリング図７００において、第２データ処理装置２０２は略語「ＤＰＥ２」で示している。

第２シグナリング図７００は、ＤＰＥ２ ２０２で実行されまたは代表される、ステップ７０２、７０４、７０６、７０８、７１０および７１２を含む。ステップ７０２−７１２は、ＤＰＥ１ １０２で実行されまたは代表される、第１シグナリング図６００のステップ６０２−６１２に対応する。即ち、ＤＰＥ２ ２０２に向けられるメッセージ・フローはＤＰＥ１ １０２に向けられるものと一致する同じものであり、そしてステップ７１２を含む。その局面の過程では、ＰＣＲＦ４０４がリソースの割り当てについて決定する必要があり、ＰＣＲＦ４０４は、ＤＰＥ２ ２０２からの要求をまた引き受けるのに、利用可能な帯域幅が十分でないと判断する。ＰＣＲＦ４０４は、次いで、ＤＰＥ１ １０２に割り当てられた量の帯域幅を低減し、要求されたものより少ない量の帯域幅をＤＰＥ２０２ ２に割り当てることを決定する。

メディア・ストリームは階層型コーディング・スキームでエンコードされるビデオ映像からなり、１またはそれ以上の強化レイヤを欠落させることで帯域幅を低減する。ＰＣＥＦ４０８は、そのゲーティング機能を用いて、ＰＣＲＦ４０４で示したような１またはそれ以上の強化レイヤのブロックを行う。例示のシナリオにおいて、ＤＰＥ２０２に割り当てられる帯域幅は最大６Ｍｂｐｓから５Ｍｂｐｓに低減されることになり、ＤＰＥ２ ２０２に割り当てられる帯域幅が５Ｍｂｐｓということになる。

ＤＰＥ１ １０２に対するサービスにおける帯域幅の再調整は、ステップ７１２の後に実施されるステップ７０３および７０５で実現される。ステップ７０３で、ＰＣＲＦ４０４は、リソース修正メッセージをＰＣＥＦ４０８に対して命令と共にＰＣＥＦ４０８に送り、現在ＤＰＥ１ １０２に割り当てられている量の帯域幅を再調整する。修正メッセージは、ＤＰＥ１ １０２にデリバリされる第１ビデオ映像でブロックする強化レイヤを認識するために必要となる情報を収容する。これを本明細書ではリソース修正(resource modification)と呼ぶが、ＰＣＥＦ４０８に対する新たなポリシ制御命令または新たなゲーティング命令と呼んでもよい。上記第１の図６００の説明を参照されたい。ステップ７０５で、ＰＣＥＦ４０８はＰＣＲＦ４０４に対して、リソース修正が実行されたことを確認する。ＰＣＲＦで取られるこのアクションの結果は、以前よりより少ないレイヤのビデオ・データを受信することである。この結果、第１ユーザは品質低下を経験することになる。このステージについては、符号７０７により示され、以下に説明するとおり、ステップ７０５とステップ７１４の間に描かれる。ＤＰＥ２ ２０２について、リソース修正要求の部分が更なる命令を含み、ＤＰＥ２ ２０２によって要求される第２ビデオ・ストリーム内の特定の強化レイヤをブロックする。なお、ＤＰＥ１はこの過程では動作可能に関係していない。

第２のシグナリング図７００におけるステップ７１４、７１６、７１８、７２０、７２２、７２４、７２６および７２８は、第１のシグナリング図６００のステップ６１４、６１６、６１８、６２０、６２２、６２４、６２６および６２８に対応しており、ＤＰＥ２ ２０２によって実行されまたは代表される。このため、ここでは更なる詳細は説明しない。ステップ７２６および７２８で、ＭＦ５０８は、セッション開始応答を用いて、コアＩＭＳ５０２を介してＤＰＥ２ ２０２に対し、セッションが確立されたかを確認する。この後に、ステージ７３０に到達し、ＤＰＥ２ ２０２へのメディアの制御およびデリバリが発生する。

図８は、第３のシグナリング図８００であり、第１ユーザが自身のＤＰＥ１ １０２を電源オフした場合に、メディア制御およびメディア・デリバリにかかわるシステム５００におけるメッセージのフローに関する発明を説明している。ステップ８０２で、ＤＰＥ１ １０２はコアＩＭＳ５０２にセッション終了要求を送る。ステップ８０４で、コアＩＭＳ５０２がＰＣＲＦ４０４へメッセージを送ることにより、リソースを解放する。ステップ８０６で、ＰＣＲＦ４０４は、リソース解放メッセージをＰＣＥＦ４０８に送る。ステップ８０８で、ＰＣＥＦ４０８は、帯域幅の解放についての確認メッセージをＰＣＲＦ４０４に送る。その後に、ＰＣＲＦ４０４は、決定過程を開始する。今やより多い帯域幅が利用可能である。尚、ＤＰＥ２ ２０２により受信したメディア・ストリームは要求される最大帯域幅未満である。即ち、ＤＰＥ２ ２０２へのストリームは、現在のところ、階層型コーディング・スキームでエンコードされた第２のビデオ映像利用可能な全ての強化レイヤを用いているわけではない。ＰＣＲＦ４０４は、適用可能なポリシに基づいて決定を行う。ステップ８１０で、ＰＣＲＦ４０４は、ＰＣＥＦ４０８に対しリソース修正メッセージを用いて命令して、ＤＰＥ２ ２０２への第２のビデオ映像における特定の強化レイヤのブロッキングを停止させる。ＰＣＥＦ４０８は、ステップ８１２で、ＰＣＲＦ４０４にリソース確認メッセージを送ることにより、このことに従い、および確認する。したがって、第２ビデオ映像の品質は、第２ユーザによって知覚されるように、向上する。次いで、ＤＰＥ２ ２０２へデリバリされるメディア内のレイヤ数を増加するというステージに到達する。このステージは、ステップ８１２とステップ８１４との間に参照番号８１３で示される。次のステップ８１４、８１６、８１８および８２０は、ＤＰＥ１ １０２のセッションを停止する手順における従来型のステップである。ステップ８１４で、ＰＣＲＦ４０４は、コアＩＭＳ５０２に対し、ＤＰＥ１ １０２用に予約されたリソースの解放を確認する。ステップ８１６において、コアＩＭＳ５０２は、ＤＰＥＩ１ １０２のセッションを終了させる要求をＭＦ５０８に送る。ステップ８１２および８２０において、ＭＦ５０８は、コアＩＭＳ５０２を介してＤＰＥ１ １０２に終了を確認する。

上記図５〜８の説明は、管理ネットワークの例としてＩＭＳネットワークに関するものである。本発明はまた、他の管理ネットワークで提供されるサービスで実施することができる。これにおいては、ＩＭＳアーキテクチャに関して説明してものに類似しており、エンド・ユーザは前もって知られている。また、ネットワークを介した通信と同様、ネットワークへのアクセスが制御される。このような他の管理ネットワークも同様に、ＩＭＳアーキテクチャに関して説明したものに対応する。即ち、第１の機能は、ＳＰＲ４０６に対応し、個々人のアドレス、加入者、ログイン・コード、アクセス権などについての情報といったエンド・ユーザのプロファイルを格納する。第２の機能は、ＩＭＳアーキテクチャのＰＣＲＦ４０４に対応し、ポリシ制御機能を決定して、ＱｏＳ管理事項について決定する。第３の機能は、ＩＭＳアーキテクチャにおけるＰＣＥＦ４０８に対応し、第２機能で決定したポリシを施行する。

上記の説明は、ＩＰＴＶコンテキストにおけるＩＭＳアーキテクチャのＱｏＳインフラストラクチャでの標準化されたポリシおよびチャージング制御（ＰＣＣ）を用いた動的な、レイヤ認知の帯域幅管理に関する本発明の第１実施例に関するものである。これから本発明の第２の実施例について説明する。第２の例は、アクセス・ノード１０６においてスヌーピングするＲＴＳＰに基づいて動的に帯域幅を管理する。

図９は、システム９００のブロック図であり、ＲＳＴＰスヌーピングを用い、且つサービス・プロバイダがＩＰＴＶストリーミング・セッションを管理する、本発明の第２の実施例を説明する。システム９００は、図３で説明したシステム３００の変化形であり、対応する特徴について説明を添えている。システム９００は、第１データ処理装置１０２、ここでは第１のＳＴＢ、および第２のデータ処理装置２０２、ここでは第２ＳＴＢを備え、アクセス・ノード１０６を介したＩＰＴＶサーバ１１０から共有データ接続１０４を介してコンテンツ情報を受け取る。一方では第１ＳＴＢ１０２および第２ＳＴＢ２０２と他方ではアクセス・ノード１０６との間のデータ接続１０４の帯域幅が制限される。システム９００の動作は、次のような利用ケースで説明される。即ち、第１ＳＴＢ１０２の第１ユーザが、彼／彼女のハンドヘルド１０２を介して彼／彼女の家庭内でＴＶチャネルの視聴を始める。しばらくした後、第２ＳＴＢ２０２の第２ユーザが、彼／彼女のハンドヘルド２０２を介して彼／彼女の家庭内で異なるＴＶチャネルの視聴を始める。システム９００の動作を説明するために、図１０のメッセージ・フロー図１０００をこれから参照する必要がある。図１０は第１メッセージ・フロー図１０００であり、システム９００の動作を示している。第１ステップ１００２で、第１ＳＴＢ１０２が、アクセス・ノード１０６を介してＲＴＳＰ要求を送ることによって、ＩＰＴＶストリーミング・サーバ１１０からのＩＰＴＶチャネルを要求する。ＩＰＴＶストリーミング・サーバ１１０は、ステップ１００４で、アクセス・ノード１０６へのＳＤＰ記述を用いてＲＴＳＰ応答を送信することによって応答する。アクセス・ノード１０６において、ＳＤＰ記述を収容するＲＴＳＰプロトコル・メッセージはスヌープされ、例えば、ステップ１００４でＩＰＴＶストリーミング・サーバ１１０からのＲＴＳＰ応答がスヌープされる。ステップ１００６で、アクセス・ノード１０６は、スヌープされたメッセージのコンテンツ、例えばＳＤＰ記述をポリシ制御機能３０２に転送し、例えばアクセス・ノード１０６自身、即ち異なるデバイス内で実施される。ポリシ制御機能３０２は、セッションをロギングし、そして、データ接続１０４の帯域幅特性に基づいて、当該ポリシ制御機能３０２は、十分な帯域幅が利用可能かを判定してストリーミング・セッションをサポートする。したがって、帯域幅を制限するポリシの施行は、必要とされない。この後、ステップ１０１０で、ポリシ制御機能３０２は、リソース要求メッセージを送信することによって、要求されたリソースについてポリシ施行機能３０４に通知する。このメッセージは、例えば、ＩＰＴＶサーバ１１０から第１ＳＴＢ１０２へのストリームのデリバリに対してオープンとすべきポート番号についての情報を含む。帯域幅の利用可能性の監視は、例えばアクセス・ノード１０６により、またはポリシ施行機能３０２により提供される。このセットアップの後には、ポリシ制御機能３０２は第１ＳＴＢ１０２およびＩＰＴＶストリーミング・サーバ１１０との間のセッションについて、およびＩＰＴＶビデオ・ストリームのコンテンツ情報について認知している。例えば、ポリシ制御機能３０２は用いられる強化レイヤの数および個々のレイヤを識別する手法についての情報、およびレイヤが送信されている方法についての情報を有している。ステップ１０１２で、ポリシ施行機能３０４は、ポリシ制御機能３０２を介してアクセス・ノード１０６に対して、ステップ１００２で要求されたように、セッションについてのリソースの割り当てを確認する。この確認をすると、アクセス・ノード１０６は、ステップ１０１４でＲＴＳＰ応答をＳＴＢ１０２に送る。ステップ１０１６で、第１ＳＴＢ１０２はＲＳＴＰメッセージを、アクセス・ノード１０６を介してＩＰＴＶストリーム・サーバ１１０に送り、ＩＰＴＶストリーム・サーバ１１０にストリーミングを開始できることを通知する。ＩＰＴＶストリーミング・サーバ１１０は、ステップ１０１８でＲＳＴＰを用いて、ストリーミングが開始されることになるかを確認し、この後に、ステージ１０２０に到達してメディアを第１ＳＴＢ１０２にストリームする。

図１１は、メッセージ・フロー図１１００であり、第２ＳＴＢがＲＴＳＰを介してＩＰＴＶストリーミング・サーバ１１０からＩＰＴＶチャネルを要求する際のシステム９００におけるメッセージ・フローについて示している。ステップ１１０２で、第２ＳＴＢ２０２は、アクセス・ノード１０６を介してＩＰＴＶストリーミング・サーバ１１０にＲＴＳＰ要求を送り、ＴＶチャネルを要求する。アクセス・ノード１０６は、このＲＴＳＰ要求をスヌーピングする。ステップ１１０４で、ＩＰＴＶストリーミング・サーバ１１０は、ＲＳＴＰ応答をＳＤＰ記述と共にアクセス・ノードに送る。ステップ１１０６で、アクセス・ノード１０６は、ＩＰＴＶストリーミング・サーバ１１０から受信したＲＴＳＰ応答のコンテンツを、ポリシ制御機能３０２に送る。ポリシ制御機能３０２は、次いで、データ接続１０４における利用可能な帯域幅が、ＳＴＢ２０２のＩＰＴＶセッション同様、第１ＳＴＢ１０２のＩＰＴＶセッションにおいてサポートするのに十分なものではないかを判定する。それ故、ポリシ制御機能３０２は、予め決められたポリシに従って何を起こす必要があるかを決定する。ポリシ制御機能３０２は、アクセス・ノード１０６が第１ＳＴＢ１０２について定めた特定のレイヤを欠落させるべきであると判定し、ステップ１１１０で、第１ＳＴＢ１０２についてのこのリソースの修正を、ポリシ施行機能３０４に通知する。ステップ１１１２で、ポリシ施行機能３０４は、ポリシ制御機能３０２に対し、リソース、ここでは帯域幅、の再割り当てを確認する。ステージ１１１３に次いで到達し、ここで、解放された帯域幅が利用可能となり、第２ＳＴＢ２０２に要求されたサービスを提供する。残りのステップは、図１１００に示され、ここで、ステップ１１１４、１１１６、１１１８、１１２０、１１２２、および１１２４は、第２のＳＴＢ２０２に対するセッションのセットアップをするための公知のメッセージについての公知のステップである。ステップ１１１４で、ポリシ制御機能３０２はポリシ施行機能３０４からリソースの割り当てを要求する。ステップ１１１６で、ポリシ施行機能３０４は、リソースの割り当てをポリシ制御機能３０２に確認する。ステップ１１１８で、ポリシ制御機能３０２はセッションをアクセス・ノード１０６に確認する。ステップ１１２０で、アクセス・ノード１０６はＲＴＳＰメッセージを介して第２ＳＴＢ２０２に通知する。ステップ１１２２で、第２ＳＴＢ２０２は、ステップ１１０２で特定したＩＰＴＶチャネル上の番組の再生終了(play-out)のために、ＲＴＳＰ要求を、アクセス・ノード１０６を介してＩＰＴＶサーバ１１０に送る。ステップ１１２４で、ＩＰＴＶサーバ１１０は、この再生終了を確認するＲＴＳＰメッセージを送る。次いで、符号１１２６に関するステージに到達し、要求されたメディアが第２ＳＴＢ２０２にデリバリされる。

ＲＴＳＰスヌーピングについての代替の実施は、ＳＴＢ２０２とＩＰＴＶサーバ１１０との間にＲＴＳＰプロキシ・サーバ（図示せず）を用いることである。この時、ＳＴＢ２０２はＩＰＴＶサーバ１１０に直接接続するのではなく、ＲＴＳＰプロキシ・サーバを介してＩＰＴＶサーバ１１０に接続する。ＲＴＳＰプロキシは、例えばアクセス・ノード１０６に、またはネットワーク内のそれ以外の場所に位置する。ＲＴＳＰプロキシは、ＳＴＢ２０２を代理してＩＰＴＶサーバに接続し、ＳＴＢ２０２とＩＰＴＶサーバ１１０との間で交換されるＲＴＳＰメッセージをリレーする。これにより第１ＲＴＳＰセッションおよび第２ＲＴＳＰセッションが生じる。第１ＲＴＳＰセッションは、ＳＴＢ２０２とＲＴＳＰプロキシ・サーバにかかわる。第２ＲＴＳＰセッションはＲＴＳＰプロキシ・サーバとＩＰＴＶサーバ１１０にかかわる。これにより、ＲＴＳＰプロキシ・サーバは、ＳＴＢ２０２とＩＰＴＶ１１０がこれを検知できなくとも、ＳＴＢ２０２とＩＰＴＶサーバ１１０との間で交換されるメッセージを修正することを可能にする。

本発明がどのように用いられるかについての別の例は、動的レイヤ認知(Dynamic Layer-Aware)帯域幅管理を大グループのユーザ、例えば、デジタル加入者線マルチプレクサ（ＤＳＬＡＭ;Digital Subscriber Line Access Multiplexer）に接続される全てのユーザに対して適用することである。ＤＳＬＡＮはサービス・プロバイダの電話交換におけるネットワーク・デバイスである。ＤＳＬＡＭは多数のカスタマ・デジタル加入者ライン（ＤＳＬ）を高スピードのインターネット・バックボーンに多重化により接続する。

ＩＰＴＶチャネルは、通例、マルチキャストで分配される。エッジに近づく限り、より人気のある(polular)チャネルが分配され、チャネルの立ち上がり時間が削減される。他のチャネルは、コア・ネットワークに向けて分配されるのみで、まれに視聴されているチャネルの帯域幅の浪費を削減する。一方では帯域幅の消費と、他方では立ち上がりレイテンシとの間にはトレードオフがある。

帯域幅効率、および／または立ち上がり時間を改良するために、ＩＰＴＶサービス・プロバイダ（ＳＰ）は、全てのチャネルの最適なデリバリのために動的レイヤ認知帯域幅管理を用いることができる。このＳＰはチャネルの人気度を利用して、ＴＶチャネルがどの品質（ここでは、強化レイヤの数）でデリバリされるべきかを判定する。人気のあるチャネルに対しては、全ての強化レイヤが送信されている。他のチャネルに対してまたは視聴者が現在誰もいないチャネルに対しては、強化レイヤは削除される。ここでは、より多くのＴＶサービス、またはテレフォニー（ＶｏＩＰ）、コンテンツ・オンデマンド型のサービス、もしくはベスト・エフォート型のインターネット・サービスといった他のサービスについての帯域幅を解放する。

そのＳＰは、ユーザが何を視聴しているかを監視することができる。例えば、ＳＰはＩＧＭＰ参加グループ・メッセージをスヌープまたは傍受(sniff)することができる。ＳＴＢは、このようなメッセージをマルチキャスト・グループに加入するために送信する。ＳＰは、マルチキャスト・アドレスをＴＶチャネルに変換し、ＴＶチャネルがマルチキャスト・グループに分配される。代替として、ＳＰはＲＴＳＰ要求を傍受することができる。ＲＴＳＰ要求は、ＴＶチャネル識別子、および任意でＳＤＰ記述を収容し、当該ＳＤＰ記述がチャネルおよびマルチキャスト・アドレスを提供する。更に別の代替としては、ＳＰはＳＩＰ（ＩＭＳ）セッション制御情報を用いることができ、視聴されているチャネルを判定する。この情報に基づいて、ＳＰは動的にチャネルごとの量の帯域幅（即ち、レイヤの数）を決定することができる。

次の例について検討する。コア・リンク帯域幅の総量は１５Ｍｐｓである。チャネルごとの最低帯域幅要件は、２Ｍｂｐｓである。チャネルごとの最大帯域幅要件は５Ｍｂｐｓである。図１２は、複数のチャネル（ＣＨＮＮＬ）の間の帯域幅についてあり得る分配（即ち、レイヤ数（＃ＬＲＳ））についてのテーブル１２００を与える。複数のチャネルとは、チャネルＣｈ１、チャネルＣｈ２、チャネルＣｈ３、およびチャネルＣｈ４であり、（現在人気のある）個々のチャネルごとの現在の視聴者数（＃ＶＷＲＳ）を与える。

次の例について検討する。ここでは、単一の家庭に関し、アクセス・リンク帯域幅の総量は１０Ｍｐｓである。チャネルごとの最低帯域幅要件は、３Ｍｂｐｓである。チャネルごとの最大帯域幅要件は５Ｍｂｐｓである。図１３は、単一の家庭内で受信するＴＶチャネルごとのレイヤ数に関するテーブル１３００を与える。視聴者の数は、例えば、セッション・セットアップもしくはネゴシエーションのメッセージ（ＳＩＰ若しくはＲＴＳＰ）を介して、または、管理メッセージ（即ち、どのチャネルが示されているかについてのサービス・プロバイダへのＳＴＢ定期レポート）を介して決定することができる。このことは、例えば、ＳＯＡＰメッセージまたは私有の実施により為されることができる。頭文字「ＲＴＣＰ」は、「ＲＴＰ制御プロトコル」(RTP Control Protocol)の略であり、これは、ＲＴＰフローに対する帯域外の統計や制御情報を提供するためのプロトコルである。頭文字「ＳＯＡＰ」は、「単一オブジェクト・アクセス・プロトコル」(Simple Object Access Protocol)の略であり、データ・ネットワーク内のウェブ・サービスの実施において構造化された情報の交換に関するプロトコル仕様である。

以前の使用ケースとしては、ＳＰからエンド・ユーザへのＴＶチャネルのデリバリにフォーカスされる。本発明は、またサービスにも適用することができ、ここでは、ユーザはコンテンツ情報をブロードキャストしている。例えば、ユーザは、スケーラブルなビデオ・コーデックを用いてビデオ方法またはビデオ会議を開始する。最初に、アップロード帯域幅が２Ｍｂｐｓのビデオ・ストリームを送信することができる。ある時に、第２ユーザが別のビデオ・ストリームのアップロードを望む。アップリンク方向に利用可能な帯域幅は十分にはないため、ポリシ制御サーバは、強化レイヤを欠落させることにより、第１ユーザについてのアップリンクのストリームを制限することを決定する。これにより、第２のビデオ・ストリームについてのリソースを解放する。

（一番多い強化レイヤを最も人気のあるコンテンツ情報に割り当てるという点で）最良のサービスを提供するという原則は、また、エンド・ユーザ・ブロードキャストに応用することができる。例えば、一番大きい数の加入受信者を有するエンド・ユーザは、全てのレイヤを送信することが許される。より人気のないブロードキャストについては、より少ないレイヤを送信することになろう。例えば、第１ユーザおよび第２ユーザは各自のホーム・ネットワークからインターネットにブロードキャストしている。第１ユーザおよび第２ユーザのアップロードの帯域幅は、３Ｍｂｐｓである。帯域幅の割り当ては、第１ユーザおよび第２ユーザ両方のインターネット・サービス・プロバイダ（ＩＳＰ）によって制御され、また、アクセス・ネットワークまたはコア・ネットワークからアップロード接続を制御する。第１ユーザからのブロードキャストが１００人の視聴者に視聴されており、一方、第２ユーザからのブロードキャストが１０人の視聴者に視聴されていることを想定する。それぞれの視聴者数に基づいて、ＩＳＰは２Ｍｂｐｓの第１帯域幅を第１ユーザのブロードキャストに割り当て、第２ユーザへは１Ｍｂｐｓの第２帯域幅を割り当てる。したがって、第１ユーザのブロードキャストの品質は、第２ユーザのブロードキャストのそれより高いものとなる。ブロードキャストしている間に第２ユーザからのブロードキャストの視聴者数が、例えば１０００に増加したときには、ＩＳＰは、帯域幅を再度割り当て、第１ユーザからのブロードキャストに１Ｍｂｐｓの第１帯域幅を割り当て、そして第２ユーザからのブロードキャストに２Ｍｂｐｓの第２帯域幅を割り当てる。個々のブロードキャストごとに割り当てられる帯域幅の大きさは、どの強化レイヤが欠落させまたは追加するかを決定付ける。この場合、住居用ゲートウェイは、管理ネットワークの一部であり、ゲーティング機能を提供することになる（即ち、住居用ゲートウェイがポリシ施行機能を実施する）。

ポリシは、データ処理装置が階層型コーディング・スキームでエンコードされたコンテンツ情報のデリバリをサービスから要求する際に、どのアクションを取るべきかを規定する。例えば、ポリシは、強化レイヤが欠落されて他のデータ処理装置がサービス提供されるのを可能にすることを明確にし、または欠落されたレイヤがリソースが解放された際に追加されることを明確にすることができる。

意思決定過程における重要な側面は、適用可能なポリシに基づいて、何が削除することができ、何ができないかを決定することである。この情報は、事前に（即ち、サービス・プロバイダから提供して）提供することができ、またはセッションの確立中に生成することができる。何故ならば、データ処理装置はまた、異なるレイヤおよびこのレイヤについての移送との間の関係（例えばＳＤＰ記述）について通知される必要があるからである。

異なるタイプのポリシ基準(criterion)の例は次のとおりである。この基準には時間ベースがあり、リソースは時刻に基づいて割り当てられる。この時刻は、レイヤを削除できるかどうか、また、いくつのレイヤを削除できるかを判定する。この基準には人気度ベースがあり、コンテンツ情報の人気度（例えば現在の加入者数）でゲーティングが制御される。この基準にはコンテンツ・ベースがあり、分配されたコンテンツ情報がレイヤ削除についてのポリシを決定する。コンテンツ情報に付随するメタデータが最終的なレイヤの削除を決定する。

本発明の特定の実施形態が、例による方法、およびＲＴＰを用いるコンテンツ情報の移送を参照して上述のとおり説明された。ＲＴＰが、トランスポート・プロトコルのグループのうちの唯一のものであり、階層型コンテンツ情報のデリバリに適している。ベース・レイヤおよび１またはそれ以上の強化レイヤは、別個で個々のデータ・ストリームの集合として、またはベース・レイヤ、および１またはそれ以上の強化レイヤのストリームについてのデータの多重化の結果の単一データ・ストリームとして、デリバリすることができる。両方の場合においても、本発明は、レイヤのうちの１またはそれ以上の個々のものを構成するデータをフィルタ・アウトするために、階層型のコンテンツ情報の移送の間にフィルタリグ機構が必要となる。ＲＴＰプロトコルの代替可能な適切なトランスポート・プロトコルは、例えば、ＨＴＴＰ、ＵＤＰ、ＴＣＰ、またはビットトレント（Bittorrent）といったピア・ツー・ピア（Ｐ２Ｐ）コンテンツ・デリバリ・プロトコルである。完全のために、頭文字「ＨＴＴＰ」は、「ハイパーテキスト・トランスファー・プロトコル」(Hypertext Transfer Protocol)の略であり、インターネットを介してマルチメディアを分配するアプリケーション・レベルのプロトコルである。頭文字「ＵＤＰ」は上記前半部で紹介した。頭文字「ＴＣＰ」は「伝送制御プロトコル」(Transmission control Protocol)の略であり、インターネット・プロトコルのコアに含まれるトランスポート・レイヤのプロトコルである。「Ｂｉｔｔｏｒｒｅｎｔ」という名前は、Ｐ２Ｐネットワーク上の特定のファイル共有プロトコルのことである。

Claims (13)

1. データ接続（１０４）を介するデータとしてのコンテンツ情報の移送に対し、帯域幅の量の割り当てを制御する方法であって、
   前記コンテンツ情報が階層型コーディング・スキームでエンコードされ、
   前記階層型コーディング・スキームがベース・レイヤおよび少なくとも１つの強化レイヤを用い、当該方法が、
   前記データ接続を介する更なるデータとしての更なるコンテンツ情報の更なる移送に対し、前記データ接続が用いられているかどうかを確認するステップと、
   前記更なる移送における１またはそれ以上の更なる属性を確認するステップと、
   前記更なる移送における前記１またはそれ以上の更なる属性に従って、予め決められたポリシの制御下において、前記移送についての前記コンテンツ情報の１またはそれ以上の強化レイヤの数を決定するステップと、
   前記コンテンツ情報の前記強化レイヤの数に従って、帯域幅の量を前記コンテンツ情報の前記移送に割り当てるステップと、
   を備える方法。
2. 請求項１に記載の方法において、前記更なるコンテンツ情報が、更なる階層型コーディング・スキームでエンコードされ、
   前記更なる階層型コーディング・スキームが、更なるベース・レイヤおよび１またはそれ以上の更なる強化レイヤを用い、当該方法が、
   前記更なる移送について更なる帯域幅の量を調整するステップを備えており、該調整するステップが、
   前記移送における１またはそれ以上の属性を確認すること、
   前記移送における前記１またはそれ以上の属性に従って、予め決められた更なるポリシの制御下において、前記更なる移送についての前記更なるコンテンツ情報の前記１またはそれ以上の強化レイヤの更なる数を決定すること、
   前記コンテンツ情報の前記強化レイヤの数に従って、前記更なる移送について前記更なる帯域幅の量を調整すること、
   を備える方法。
3. 請求項１に記載の方法において、
   前記更なる属性が、
   前記コンテンツ情報に関する前記更なるコンテンツ情報についての更なる相対的な人気度、
   前記更なるコンテンツ情報についての更なる意味論的側面、
   前記更なるコンテンツ情報を表す前記更なるデータの更なる発信先、
   前記更なるコンテンツ情報を表す前記更なるデータの更なる発信元、
   前記更なるコンテンツ情報について前記移送を開始した日の時刻、および
   前記更なるコンテンツ情報についての更なるエンド・ユーザの更なる識別情報、
   のうちの１またはそれ以上を含む、
   方法。
4. 請求項２または３に記載の方法において、
   前記属性が、
   前記更なるコンテンツ情報に関する前記コンテンツ情報についての相対的な人気度、
   前記コンテンツ情報についての意味論的側面、
   前記コンテンツ情報を表す前記データの発信先、
   前記コンテンツ情報を表す前記データの発信元、
   前記コンテンツ情報について前記移送を開始した日の時刻、および
   前記コンテンツ情報についてのエンド・ユーザの識別情報、
   のうちの１またはそれ以上を含む、
   方法。
5. 請求項１に記載の方法において、
   前記コンテンツ情報が管理ネットワークのインフラストラクチャを介して提供され、
   該インフラストラクチャが、前記予め決められたポリシを選択するポリシ制御機能（３０４；４０８）、および前記予め決められたポリシを施行するポリシ施行機能（３０２；４０４）を備えており、当該方法が、
   前記ポリシ制御機能によって示されるような、前記１またはそれ以上の強化レイヤについてのゲーティングを用いて、前記ポリシ施行機能を介して前記１またはそれ以上の強化レイヤの数を制御するステップを備える、
   方法。
6. 請求項５に記載の方法において、
   前記インフラストラクチャが加入プロファイル・レポジトリを備え、
   前記ポリシ制御機能が、前記加入プロファイル・レポジトリの制御下で前記１またはそれ以上の強化レイヤを示すことを可能にする、方法。
7. 請求項５に記載の方法において、
   前記コンテンツ情報がＩＰＴＶサービスにおいてサーバ（１１０）により提供され、
   前記データ接続がアクセス・ノード（１０６）を有し、
   該アクセス・ノードが、
   前記アクセス・ノードを介して前記サーバに送られる前記コンテンツ情報についての要求、および
   前記コンテンツ情報についての前記要求に対する前記サーバからの応答、
   のうちの少なくとも１つについてスヌーピングするように構成され、
   前記アクセス・ノードが、前記応答のコンテンツを前記ポリシ制御機能に転送するように構成される、方法。
8. 請求項５に記載の方法において、
   前記コンテンツ情報が、ＩＰＴＶサービスにおいてサーバ（１１０）によって、プロキシ・サーバを介して提供され、
   該プロキシ・サーバが、
   前記コンテンツ情報を要求するために、前記ＩＰＴＶサービスにおいて前記プロキシ・サーバを介して前記サーバに送られる要求、および
   前記コンテンツ情報についての前記要求に対する、前記ＩＰＴＶサービスにおける前記サーバからの応答であって、前記プロキシ・サーバを介して送られる応答、
   のうちの少なくとも１つについてスヌーピングするように構成され、
   前記プロキシ・サーバが、前記応答のコンテンツを前記ポリシ制御機能に転送するように構成される、方法。
9. 請求項２に記載の方法において、
   前記更なるコンテンツ情報が、管理ネットワーク（５００）のインフラストラクチャを介して提供され、該インフラストラクチャが、前記予め決められたポリシを選択するポリシ制御機能（３０４；４０８）、および前記予め決められたポリシを施行するポリシ施行機能（３０２；４０４）を備えており、
   前記方法が、前記ポリシ制御機能によって示されるような、前記１またはそれ以上の強化レイヤについてのゲーティングを用いて、前記ポリシ施行機能を介して前記１またはそれ以上の更なる強化レイヤの数を制御するステップを備える、方法。
10. 請求項９に記載の方法において、
    前記インフラストラクチャが加入プロファイル・レポジトリを備え、
    前記ポリシ制御機能が、前記加入プロファイル・レポジトリの制御下で前記１またはそれ以上の更なる強化レイヤを示すことを可能にする、方法。
11. 請求項９記載の方法において、
    前記更なるコンテンツ情報がＩＰＴＶサービスにおいてサーバ（１１０）により提供され、
    前記データ接続がアクセス・ノード（１０６）を有し、
    該アクセス・ノードが、
    前記アクセス・ノードを介して前記サーバに送られる、前記更なるコンテンツ情報についての更なる要求、および
    前記更なるコンテンツ情報についての前記更なる要求に対する前記サーバからの更なる応答、
    のうちの少なくとも１つについてスヌーピングするように構成され、
    前記アクセス・ノードが、前記更なる応答の更なるコンテンツを前記ポリシ制御機能に転送するように構成される、方法。
12. データ接続（１０４）を介するデータとしてのコンテンツ情報の移送に対し、帯域幅の量の割り当てを制御するためのコンピュータ可読媒体上の制御ソフトウェアであって、
    前記コンテンツ情報が、階層型コーディング・スキームでエンコードされ、
    前記階層型コーディング・スキームが、ベース・レイヤおよび少なくとも１つの強化レイヤを用いており、前記制御ソフトウェアが、
    前記データ接続を介する更なるデータとしての更なるコンテンツ情報の更なる移送に対し、前記データ接続が用いられているかどうかを確認するための第１の命令と、
    前記更なる移送における１またはそれ以上の更なる属性を確認するための第２の命令と、
    前記更なる移送における前記１またはそれ以上の更なる属性に従って、予め決められたポリシの制御下において、前記移送についての前記コンテンツ情報の１またはそれ以上の強化レイヤの数を決定するための第３の命令と、
    前記コンテンツ情報の前記強化レイヤの数に従って、帯域幅の量を前記コンテンツ情報の前記移送に割り当てる第４の命令と、
    を備える制御ソフトウェア。
13. 移送を開始する前に、データ接続（１０４）を介するデータとしてのコンテンツ情報の移送に対し、帯域幅の量の割り当てを制御するように構成されるデータ処理システム（１００；２００）であって、
    前記コンテンツ情報が、階層型コーディング・スキームでエンコードされ、
    前記階層型コーディング・スキームが、ベース・レイヤおよび少なくとも１つの強化レイヤを用いており、前記データ処理システムが、
    前記データ接続を介する更なるデータとしての更なるコンテンツ情報の更なる移送に対し、前記データ接続が用いられているかどうかを確認するための第１の手段と、
    前記更なる移送における１またはそれ以上の更なる属性を確認するための第２の手段と、
    前記更なる移送における前記１またはそれ以上の更なる属性に従って、予め決められたポリシの制御下において、前記移送についての前記コンテンツ情報の１またはそれ以上の強化レイヤの数を決定するための第３の手段と、
    前記コンテンツ情報の前記強化レイヤの数に従って、帯域幅の量を前記コンテンツ情報の前記移送に割り当てる第４の手段と、
    を備えるデータ処理システム。
    

Images