JP2012507895A - ネットワークにおける分散型リソース管理 - Google Patents

Abstract

ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを備えたネットワークを含むデータ通信システムであって、コントロールサーバが、配信サーバとＵＥデバイスの間におけるネットワークセッションのネットワークセッションＩＤを配信サーバに渡すように構成されており、配信サーバが、コントロールサーバから独立してネットワークセッションをトラッキングするように構成されており、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに対する参照を続けず、そこにまったく関与しない、データ通信システムが開示される。

Description

本発明は、ネットワークにおける分散型リソース管理に関する。詳細には、本発明は、次世代ネットワーク（ＮＧＮ）におけるリソース管理およびネットワークセッションのトラッキングに関するが、それらには限定されない。

次世代ネットワーク（ＮＧＮ）とは、パケットベースのシステムにおいて多くの種類の情報およびサービス（たとえば音声、データ、マルチメディアなど）を移送するネットワーキングに関する広義の用語である。このタイプのネットワークは、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ＴＶ）サービスをエンドユーザに提供するために、またはその他のタイプのデータのために使用することができる。このタイプのネットワークは、サービス品質（ＱｏＳ）を確保して保証するのにＲＡＣＳ（Ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂ−ｓｙｓｔｅｍ）に依存している。いくつかの標準団体が、ＲＡＣサブシステムのアーキテクチャーに取り組んでいる。

ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｓ Ｕｎｉｏｎ）−ＳＧＩおよびＡＴＩＳ（Ａｌｌｉａｎｃｅ ｆｏｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄｓ）の双方が、ＲＡＣ−Ｆ（Ｒｅｓｏｕｒｃｅ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｆａｃｉｌｉｔｙ）の使用について規定している。ＲＡＣ−ＦおよびＲＡＣＳは、それら自体よく知られている。

ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）が、ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂ−ｓｙｓｔｅｍ）の使用について規定している。

ＥＴＳＩ ＴＩＳＰＡＮが、ＥＴＳＩ ＥＳ ２８２ ００３：「Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）；Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂ−ｓｙｓｔｅｍ（ＲＡＣＳ）：Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ」においてＲＡＣＳアーキテクチャーについて定義した。ＥＴＳＩ ＥＳ ２８２ ００３は、その他のＮＧＮサブシステム（すなわちアプリケーションまたはサービス機能）が承認およびリソースの確保のためにＲＡＣＳとどのように対話すべきかについて規定している。しかしＥＴＳＩ ＥＳ ２８２ ００３においては、同じ機能エンティティーが、たとえばＧｑ’として知られているインターフェースを介して、リソースを確保し、修正し、リフレッシュし、解放することになると想定されている。したがって、管理を行う機能エンティティー（たとえば、ＥＴＳＩ ＴＳ １０２ ０２８において定義されているように、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ＴＶ）のコントロール）は、使用後にリソースを解放できるように、セッションをトラッキングすることが必要とされる。

一例について考えてみると、ＣｏＤ（Ｃｏｎｔｅｎｔ ｏｎ Ｄｅｍａｎｄ）サーバは通常、ＩＰＴＶ ＣｏＤサービスを配信し、その一方で、リソース管理を担うＩＰＴＶコントロール要素でもある。したがって、単一の機能エンティティーであるＩＰＴＶコントロールは、リソース管理の責任を負い、すべてのＣｏＤセッションの間中すべてのＱｏＳリソースをトラッキングしなければならない。同様の例が、ＩＭＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ドメインに存在し、ＩＭＳドメインでは、ＩＰＴＶコントロールの役割は、ＩＭＳの中核要素、たとえばＳ−ＣＳＣＦ（Ｓｅｒｖｉｃｅ−Ｃａｌｌ Ｓｅｔｕｐ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）によって実行される。

このアプローチでは、拡張性およびパフォーマンスの限界が生じる。なぜなら、リソースを確保し、修正し、リフレッシュし、解放するよう（すなわち確保／解放するよう）要求する機能エンティティーが、サービスを実際に配信する機能エンティティーと同じではないためである。したがって、複雑さおよびネットワーキングの問題が生じる可能性があり、それによってパフォーマンスが影響を受ける。

代替アプローチが、「ＥＴＳＩ ＤＴＳ １８３ ０６４ Ｖ ０．０．５（２００８−０３）ＥＴＳＩ Ｓｔａｎｄａｒｄ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）：Ｄｅｄｉｃａｔｅｄ ＩＰＴＶ ｓｕｂｓｙｓｔｅｍ Ｓｔａｇｅ ３ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」に記載されており、このアプローチでは、ＩＰＴＶコントロールがリソースを確保した後、それらのリソースの解放は、ＭＣＦと呼ばれる別の機能エンティティーに委ねられる。

しかし、このアプローチは、ネットワーク管理インターフェースへの（場合によっては、開放されたネットワークからの）分散型アクセスをオペレータが許可する場合にしか適用することができず、この分散型アクセスによって、ＲＡＣＳにおいてはまだ対処されていないセキュリティーリスクが生じる。

従来技術による一構成が、ＸＰ０１５００９０３９から知られており、このＸＰ０１５００９０３９は、マルチメディア配信を含めて、１人または複数の参加者を伴うセッションを生み出し、修正し、終了させるためのアプリケーション層コントロールプロトコルを開示している。

ＥＴＳＩ ＥＳ ２８２ ００３：「Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）；Ｒｅｓｏｕｒｃｅ ａｎｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｓｕｂ−ｓｙｓｔｅｍ（ＲＡＣＳ）：Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ」 ＥＴＳＩ ＴＳ １０２ ０２８ ＥＴＳＩ ＤＴＳ １８３ ０６４ Ｖ ０．０．５（２００８−０３）ＥＴＳＩ Ｓｔａｎｄａｒｄ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）：Ｄｅｄｉｃａｔｅｄ ＩＰＴＶ ｓｕｂｓｙｓｔｅｍ Ｓｔａｇｅ ３ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ＸＰ０１５００９０３９ ＥＴＳＩ ＴＳ １８２０２８ ＥＴＳＩ ＴＳ １８２ ０１９ ＲＦＣ２３２６

本発明は、改善されたリソース管理システムを提供する目的から生み出された。

本発明は、ネットワーク管理インターフェースへの分散型アクセスが必要とされず、拡張性およびパフォーマンスが制限されないソリューションを提供する。

本発明によれば、ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを備えたネットワークを含むデータ通信システムであって、コントロールサーバが、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すように構成されており、配信サーバが、コントロールサーバから独立してネットワークセッションをトラッキングするように構成されており、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、データ通信システムにおいて、配信サーバが、ネットワークセッションが完了するとネットワークセッションのＱｏＳネットワークセッションＩＤをコントロールサーバに返すように構成されており、ＲＡＣＳ（リソース／許可コントロールサーバ）が提供され、コントロールサーバが、ネットワークセッションＩＤを受信するとネットワークセッションを終了するようＲＡＣＳに指示するように構成されていることを特徴とする、データ通信システムが提供される。

コントロールサーバは、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡すように構成することができる。

コントロールサーバは、コントロールサーバから配信サーバに直接、またはＵＥを介して間接的にネットワークセッションＩＤを渡すように構成することができる。ＵＥは、ＲＴＳＰ（ｒｅａｌ ｔｉｍｅ ｓｔｒｅａｍｉｎｇ ｐｒｏｔｏｃｏｌ） ３００ ＲＥＤＩＲＥＣＴメッセージを使用してネットワークセッションＩＤを配信サーバに渡すように構成することができる。これらは、それら自体よく知られている。

ＵＥは、ＩＰＴＶ機器とすることができる。

実質的に、本発明は、ネットワークセッションの状態トラッキングを、リソースを確保している機能エンティティーから、コンテンツを配信する機能エンティティーへアウトソースすることを伴う。

さらなる態様における本発明によれば、ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを有するネットワークのネットワークリソースを管理する方法であって、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すステップと、配信サーバを使用して、コントロールサーバから独立してネットワークセッションをトラッキングするステップとを含み、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、方法において、ネットワークセッションが完了すると、配信サーバが、ネットワークセッションのネットワークセッションＩＤをコントロールサーバに返し、コントロールサーバがコントロールを再び得て、コントロールサーバが、ネットワークセッションＩＤを受信すると、ネットワークセッションを終了するようＲＡＣＳ（リソース／許可コントロールサーバ）に指示することを特徴とする、方法が提供される。

コントロールサーバは、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡すことが好ましい。ネットワークセッションＩＤは、コントロールサーバから配信サーバに直接、またはＵＥを介して間接的に渡すことができる。ネットワークセッションＩＤは、間接的に渡される場合には、ＲＴＳＰ ３００ ＲＥＤＩＲＥＣＴメッセージを使用してＵＥから配信サーバに渡されることが好ましい。

本発明を使用することによって、ネットワーク内の単一の機能エンティティーが、ＱｏＳセッションの状態を保持することなくリソースを管理する。この構成のおかげで、セキュリティーへの配慮から同一の機能エンティティーのみがリソースを管理することを許可されるため、クローズドなネットワークドメイン内でのリソース確保へのアクセスを保持することができる。これによって、セキュリティーが改善され、たとえばＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃を防止することができる。

本発明はまた、本明細書に開示されている新規な特徴、特徴の組合せ、ステップ、またはステップの組合せのうちの任意の１つまたは複数を含むデータ通信のシステムまたは方法を提供する。

次いで本発明の実施形態について、例示のみを目的として、添付の概略図を参照して説明する。

ネットワークを概略的に示す図である。

図１を参照すると、本発明の一実施形態が概略的に示されている。ＵＥ１、この場合はＩＰＴＶ ＵＥデバイス（たとえばセットトップボックスおよびディスプレイ）が、次世代ネットワーク（ＮＧＮ）に接続されている。単一のＵＥ１しか示されていないが、一般には、ネットワークに接続されている多数のＵＥ１が存在し、それらのＵＥ１どうしの間でネットワークリソースが共有されることになるということを理解されたい。

このネットワークは、次世代ネットワーク（ＮＧＮ）であり、すなわち、ＩＰおよびサービス品質（ＱｏＳ）テクノロジーを使用して、音声、データ、およびビデオを含む（ただし、それらには限定されない）すべてのタイプのカスタマートラフィックをサポートするように設計されたネットワークであり、それによって、さまざまなＩＰベースのカスタマーデバイスおよび次世代型の進化したアプリケーションが、単一の共通ネットワークを介して通信することができる。

このネットワークは、（ＥＴＳＩ ＴＳ １８２０２８において定義されている）ＩＰＴＶ−Ｃ（ＩＰＴＶコントロール）２と、ＲＡＣＳ（リソース／許可コントロールサーバ）３と、ＭＦ（メディア機能）４サーバ（この場合は、インタラクティブなメディア配信のためのＣｏＤサーバ（ＭＣＦ））と、ＢＧＦ（ボーダーゲートウェイ機能）デバイス５と、ローカルな一群のＵＥにアクセスを提供するアクセスノード（ＡＮ）６とを含む。これらの構成要素は、図に概略的に示されている。

いわゆる次世代ネットワーク（ＮＧＮ）以外のネットワークを含む代替ネットワーク構成が、本発明の範囲内で可能であるということを当業者なら容易に理解するであろう。

次いで、オンデマンドコンテンツ、たとえばＶＯＤ（ｖｉｄｅｏ ｏｎ ｄｅｍａｎｄ）をユーザが要求する用途におけるこのネットワークのオペレーションについて、図におけるラベル付けされたステップを参照しながら考察する（図における英数字でラベル付けされたラインは、物理的な（または無線による）ネットワーク接続ではなく、論理的な機能フローを表しているということに留意されたい。

実際には、ＵＥは、当然ながらＡＮ６を介してネットワークに接続することになり、ＡＮ６は、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）とすることができる：
ａ）ユーザは、ＵＥからオンデマンドコンテンツを選択し、ＵＥは、ＣｏＤセッションを開始するためにリクエストをＩＰＴＶ−Ｃへ送信する。

ｂ）ＵＥ１からのリクエストを受信すると、ＩＰＴＶ−Ｃは、リソースの確保をＲＡＣＳにリクエストする。ＩＰＴＶ−ＣとＲＡＣＳは、ＥＴＳＩ ＴＳ １８２ ０１９において定義されているＧｑ’インターフェースを使用して接続されている。しかし、その他の標準団体またはフォーラム、たとえばＡＴＩＳ（Ａｌｌｉａｎｃｅ ｆｏｒ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｉｎｄｕｓｔｒｙ Ｓｏｌｕｔｉｏｎｓ）や、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｓ Ｕｎｉｏｎ）において定義されている代替インターフェースを使用することもできる。

ｃ）ＲＡＣＳは、ＱｏＳセッションＩＤをＩＰＴＶ−Ｃに返す。

ｄ、ｅ）ＩＰＴＶ−Ｃは、ＱｏＳセッションＩＤをＣｏＤサーバに渡し、ＣｏＤサーバは、ＱｏＳセッションの参照を続けることになる（リソースの確保）。ＱｏＳセッションＩＤは、ＣｏＤサーバとＵＥの間におけるＣｏＤセッションの確立中に渡される。この時点から、ＩＰＴＶ−Ｃは、ＣｏＤセッションに関してステートレスである、すなわちＩＰＴＶ−Ｃは、自分が今しがた確保したＱｏＳセッションに関してそれ以上関知しない−換言すれば、ＱｏＳセッションに対する参照を続けず、そこにまったく関与しない。

ＱｏＳセッションＩＤは、ＲＦＣ２３２６において規定されているＲＴＳＰ（ｒｅａｌ ｔｉｍｅ ｓｔｒｅａｍｉｎｇ ｐｒｏｔｏｃｏｌ）３００ ＲＥＤＩＲＥＣＴメッセージを使用して、ＵＥを介して渡される。しかし、任意の適切な代替プロトコルを使用することもでき、あるいはセッションＩＤを直接渡すこともできるということに留意されたい。

この例においては、ＱｏＳセッションは、ＣｏＤセッションの確立中にＣｏＤサーバに渡されるが、別法として、ＣｏＤセッションの確立前に渡すこともできる。さらに、この例においては、ＱｏＳセッションＩＤは、ＵＥを介して間接的にＣｏＤサーバに渡されるが、別法として、直接渡すこともできる。

ｆ）ＣｏＤサーバは、ＣｏＤセッションが機能している間はＱｏＳセッションをトラッキングする。上述のように、この期間中に、ＩＰＴＶ−Ｃは、ＱｏＳセッションに関してステートレスである。

ｇ）したがってＣｏＤサーバは、インタラクティブなコンテンツ配信の状態と、そのインタラクティブな配信がもはや必要とされなくなる時点とを知り、それに応じてＣＯＤサーバは、確保されているリソース（ＱｏＳセッション）がもはや必要とされなくなる時点を知る、または判断する。そのようにしてＣｏＤセッションが終了すると、ＣｏＤサーバは、ＱｏＳセッションが存在し、解放する必要がある旨をＩＰＴＶ−Ｃに通知し、ＣｏＤサーバは、ＱｏＳセッションＩＤをＩＰＴＶ−Ｃに返し、次いでＩＰＴＶ−Ｃは、ＱｏＳセッションに関してもはやステートレスでなくなり、再び主体的な役割を担うようになる。

ｈ、ｉ）ＩＰＴＶ−Ｃは、ＱｏＳセッションＩＤを指定して、Ｇｑ’インターフェースを介して、ＱｏＳセッションを終了するようＲＡＣＳをトリガーする。

このようにして、通常のオペレーション中に、ＩＰＴＶコントロールは、ＱｏＳセッション（確保されているリソース）をトラッキングせず、それによって、コスト効率のよい分散型ソリューションの構築が可能になる。ＱｏＳの状態は、そのＱｏＳが使用されている場所で維持され、それによって、別々の機能エンティティーの間でサービスセッション（ＣｏＤセッション）とリソース確保セッション（ＱｏＳセッション）とを同期化する必要がなくなる。

したがって、ＱｏＳセッションの状態トラッキングは、リソースを確保している機能エンティティーから、リソース確保の段階中にサービス配信のために選択された機能エンティティーへ「アウトソース」される。リソースを確保している機能エンティティーは、サービスを実行するために選択された機能エンティティーに、そのサービスが継続する間は、その選択された機能エンティティーがＱｏＳセッションのトラッキングを担当するよう指示する。サービスが終了し、重要とされる（ｕｎｄｅｒｌｉｎｅｄ）ＱｏＳセッションがもはや不要になると、サービスを提供している機能エンティティーは、リソースを確保している機能エンティティーに、確保されているリソースはもはや不要であり、解放することができる旨を返信する。

上述のように、単一のエンティティー、（すなわち、この実施形態では）ＭＦ（ＣＯＤ）サーバ４が、セッション中にリソースを管理するので、複数の構成要素／ノードが１つのネットワーク内に存在する場合に生じる可能性のあるセキュリティーの問題が最小限に抑えられるため、セキュリティーが大幅に改善される。

本発明では、ＮＧＮにおけるすべてのＱｏＳセッション（すなわち、すべてのＩＰＴＶ ＣｏＤセッション）を単一の機能エンティティーがトラッキングする必要性をなくすことによって、従来技術の拡張性およびパフォーマンスの限界が取り除かれ、ステートレスな機能エンティティーによってリソースの確保および管理を実行することができるため、コスト効率のよい実施態様が可能になり、サービス機能とリソース管理機能の間における費用のかかる同期化が不要になり、そしてネットワーク管理インターフェースへの分散型アクセスを使用せずにオペレータの分散型リソース管理が可能になり、それによってセキュリティーリスクが減少し、たとえばＤｏＳ（ｄｅｎｉａｌ ｏｆ ｓｅｒｖｉｃｅ）攻撃が防止される。

記載の実施形態は、ＩＰＴＶに関連しているが、本発明は、次世代ネットワークを含む（ただし、それには限定されない）さまざまなネットワークにおける任意のタイプのマルチメディアコンテンツ、ならびにＩＰＴＶ以外のタイプのコンテンツおよびデータのための分散型リソース管理に適用可能であるということに留意されたい。

Claims (10)

1. ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを備えたネットワークを含むデータ通信システムであって、コントロールサーバが、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すように構成されており、配信サーバが、コントロールサーバから独立してネットワークセッションをトラッキングするように構成されており、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、データ通信システムにおいて、
   配信サーバが、ネットワークセッションが完了するとネットワークセッションのＱｏＳネットワークセッションＩＤをコントロールサーバに返すように構成されており、
   ＲＡＣＳ（リソース／許可コントロールサーバ）が提供され、コントロールサーバが、ネットワークセッションＩＤを受信すると、ネットワークセッションを終了するようＲＡＣＳに指示するように構成されている、データ通信システム。
2. コントロールサーバが、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡すように構成されている、請求項１に記載のシステム。
3. コントロールサーバが、ネットワークセッションＩＤをコントロールサーバから配信サーバに渡すように構成されている、請求項１または２に記載のシステム。
4. コントロールサーバおよびＵＥが、ＵＥを介してコントロールサーバから配信サーバにネットワークセッションを渡すように構成されている、請求項１または２に記載のシステム。
5. ＵＥが、ＲＴＳＰ ３００ ＲＥＤＩＲＥＣＴメッセージを使用してネットワークセッションＩＤを配信サーバに渡すように構成されている、請求項４に記載のシステム。
6. ＵＥがＩＰＴＶ機器である、請求項１から５のいずれか一項に記載のシステム。
7. ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを有するネットワークのネットワークリソースを管理する方法であって、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すステップと、配信サーバを使用して、コントロールサーバから独立してネットワークセッションをトラッキングするステップとを含み、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、方法において、
   ネットワークセッションが完了すると、配信サーバが、ネットワークセッションのネットワークセッションＩＤをコントロールサーバに返し、コントロールサーバがコントロールを再び得て、
   コントロールサーバが、ネットワークセッションＩＤを受信すると、ネットワークセッションを終了するようＲＡＣＳ（リソース／許可コントロールサーバ）に指示する、方法。
8. コントロールサーバが、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡す、請求項７に記載の方法。
9. ネットワークセッションＩＤが、コントロールサーバから配信サーバに渡されるか、またはＵＥを介してコントロールサーバから配信サーバに渡される、請求項７または８に記載の方法。
10. ネットワークセッションＩＤが、ＲＴＳＰ ３００ ＲＥＤＩＲＥＣＴメッセージを使用してＵＥを介して配信サーバに渡される、請求項９に記載の方法。

Images