(57)【特許請求の範囲】
【請求項１】
ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを備えたネットワークを含むデータ通信システムであって、前記コントロールサーバが、前記配信サーバと前記ＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを前記配信サーバに渡すように構成されており、前記配信サーバが、前記コントロールサーバから独立してネットワークセッションをトラッキングするように構成されており、それによって、ネットワークセッションの前記ＱｏＳネットワークセッションＩＤが前記配信サーバに渡されると、前記コントロールサーバが、ネットワークセッションに関してステートレスである、データ通信システムにおいて、
前記配信サーバが、ネットワークセッションが完了するとネットワークセッションの前記ＱｏＳネットワークセッションＩＤを前記コントロールサーバに返すように構成されており、
ＲＡＣＳ（リソース／許可コントロールサーバ）が提供され、前記コントロールサーバが、前記ＱｏＳネットワークセッションＩＤを受信すると、ネットワークセッションを終了するよう前記ＲＡＣＳに指示するように構成されている、データ通信システム。
【請求項２】
前記コントロールサーバが、前記配信サーバと前記ＵＥデバイスの間におけるネットワークセッションの確立中に前記ＱｏＳネットワークセッションＩＤを前記配信サーバに渡すように構成されている、請求項１に記載のシステム。
【請求項３】
前記コントロールサーバが、前記ＱｏＳネットワークセッションＩＤを前記コントロールサーバから前記配信サーバに渡すように構成されている、請求項１または２に記載のシステム。
【請求項４】
前記コントロールサーバおよび前記ＵＥデバイスが、前記ＵＥデバイスを介して前記コントロールサーバから前記配信サーバに前記ＱｏＳネットワークセッションＩＤを渡すように構成されている、請求項１または２に記載のシステム。
【請求項５】
前記ＵＥデバイスが、ＲＴＳＰ  ３００  ＲＥＤＩＲＥＣＴメッセージを使用して前記ＱｏＳネットワークセッションＩＤを前記配信サーバに渡すように構成されている、請求項４に記載のシステム。
【請求項６】
前記ＵＥデバイスがＩＰＴＶ機器である、請求項１から５のいずれか一項に記載のシステム。
【請求項７】
ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを有するネットワークのネットワークリソースを管理する方法であって、前記配信サーバと前記ＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを前記配信サーバに渡すステップと、前記配信サーバを使用して、前記コントロールサーバから独立してネットワークセッションをトラッキングするステップとを含み、それによって、ネットワークセッションの前記ＱｏＳネットワークセッションＩＤが前記配信サーバに渡されると、前記コントロールサーバが、ネットワークセッションに関してステートレスである、方法において、
ネットワークセッションが完了すると、前記配信サーバが、ネットワークセッションの前記ＱｏＳネットワークセッションＩＤを前記コントロールサーバに返し、前記コントロールサーバがコントロールを再び得て、
前記コントロールサーバが、前記ＱｏＳネットワークセッションＩＤを受信すると、ネットワークセッションを終了するようＲＡＣＳ（リソース／許可コントロールサーバ）に指示する、方法。
【請求項８】
前記コントロールサーバが、前記配信サーバと前記ＵＥデバイスの間におけるネットワークセッションの確立中に前記ＱｏＳネットワークセッションＩＤを前記配信サーバに渡す、請求項７に記載の方法。
【請求項９】
前記ＱｏＳネットワークセッションＩＤが、前記コントロールサーバから前記配信サーバに渡されるか、または前記ＵＥデバイスを介して前記コントロールサーバから前記配信サーバに渡される、請求項７または８に記載の方法。
【請求項１０】
前記ＱｏＳネットワークセッションＩＤが、ＲＴＳＰ  ３００  ＲＥＤＩＲＥＣＴメッセージを使用して前記ＵＥデバイスを介して前記配信サーバに渡される、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおける分散型リソース管理に関する。詳細には、本発明は、次世代ネットワーク（ＮＧＮ）におけるリソース管理およびネットワークセッションのトラッキングに関するが、それらには限定されない。
【背景技術】
【０００２】
次世代ネットワーク（ＮＧＮ）とは、パケットベースのシステムにおいて多くの種類の情報およびサービス（たとえば音声、データ、マルチメディアなど）を移送するネットワーキングに関する広義の用語である。このタイプのネットワークは、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ＴＶ）サービスをエンドユーザに提供するために、またはその他のタイプのデータのために使用することができる。このタイプのネットワークは、サービス品質（ＱｏＳ）を確保して保証するのにＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  ｒｅｓｅｒｖａｔｉｏｎ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂ−ｓｙｓｔｅｍ）に依存している。いくつかの標準団体が、ＲＡＣサブシステムのアーキテクチャーに取り組んでいる。
【０００３】
ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｓ  Ｕｎｉｏｎ）−ＳＧＩおよびＡＴＩＳ（Ａｌｌｉａｎｃｅ  ｆｏｒ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄｓ）の双方が、ＲＡＣ−Ｆ（Ｒｅｓｏｕｒｃｅ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｆａｃｉｌｉｔｙ）の使用について規定している。ＲＡＣ−ＦおよびＲＡＣＳは、それら自体よく知られている。
【０００４】
ＥＴＳＩ（Ｅｕｒｏｐｅａｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｔａｎｄａｒｄｓ  Ｉｎｓｔｉｔｕｔｅ）が、ＲＡＣＳ（Ｒｅｓｏｕｒｃｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂ−ｓｙｓｔｅｍ）の使用について規定している。
【０００５】
ＥＴＳＩ  ＴＩＳＰＡＮが、ＥＴＳＩ  ＥＳ  ２８２  ００３：「Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）；Ｒｅｓｏｕｒｃｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂ−ｓｙｓｔｅｍ（ＲＡＣＳ）：Ｆｕｎｃｔｉｏｎａｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ」においてＲＡＣＳアーキテクチャーについて定義した。ＥＴＳＩ  ＥＳ  ２８２  ００３は、その他のＮＧＮサブシステム（すなわちアプリケーションまたはサービス機能）が承認およびリソースの確保のためにＲＡＣＳとどのように対話すべきかについて規定している。しかしＥＴＳＩ  ＥＳ  ２８２  ００３においては、同じ機能エンティティーが、たとえばＧｑ’として知られているインターフェースを介して、リソースを確保し、修正し、リフレッシュし、解放することになると想定されている。したがって、管理を行う機能エンティティー（たとえば、ＥＴＳＩ  ＴＳ  １０２  ０２８において定義されているように、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ＴＶ）のコントロール）は、使用後にリソースを解放できるように、セッションをトラッキングすることが必要とされる。
【０００６】
一例について考えてみると、ＣｏＤ（Ｃｏｎｔｅｎｔ  ｏｎ  Ｄｅｍａｎｄ）サーバは通常、ＩＰＴＶ  ＣｏＤサービスを配信し、その一方で、リソース管理を担うＩＰＴＶコントロール要素でもある。したがって、単一の機能エンティティーであるＩＰＴＶコントロールは、リソース管理の責任を負い、すべてのＣｏＤセッションの間中すべてのＱｏＳリソースをトラッキングしなければならない。同様の例が、ＩＭＳ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）ドメインに存在し、ＩＭＳドメインでは、ＩＰＴＶコントロールの役割は、ＩＭＳの中核要素、たとえばＳ−ＣＳＣＦ（Ｓｅｒｖｉｃｅ−Ｃａｌｌ  Ｓｅｔｕｐ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）によって実行される。
【０００７】
このアプローチでは、拡張性およびパフォーマンスの限界が生じる。なぜなら、リソースを確保し、修正し、リフレッシュし、解放するよう（すなわち確保／解放するよう）要求する機能エンティティーが、サービスを実際に配信する機能エンティティーと同じではないためである。したがって、複雑さおよびネットワーキングの問題が生じる可能性があり、それによってパフォーマンスが影響を受ける。
【０００８】
代替アプローチが、「ＥＴＳＩ  ＤＴＳ  １８３  ０６４  Ｖ  ０．０．５（２００８−０３）ＥＴＳＩ  Ｓｔａｎｄａｒｄ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  Ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）：Ｄｅｄｉｃａｔｅｄ  ＩＰＴＶ  ｓｕｂｓｙｓｔｅｍ  Ｓｔａｇｅ  ３  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」に記載されており、このアプローチでは、ＩＰＴＶコントロールがリソースを確保した後、それらのリソースの解放は、ＭＣＦと呼ばれる別の機能エンティティーに委ねられる。
【０００９】
しかし、このアプローチは、ネットワーク管理インターフェースへの（場合によっては、開放されたネットワークからの）分散型アクセスをオペレータが許可する場合にしか適用することができず、この分散型アクセスによって、ＲＡＣＳにおいてはまだ対処されていないセキュリティーリスクが生じる。
【００１０】
従来技術による一構成が、ＸＰ０１５００９０３９から知られており、このＸＰ０１５００９０３９は、マルチメディア配信を含めて、１人または複数の参加者を伴うセッションを生み出し、修正し、終了させるためのアプリケーション層コントロールプロトコルを開示している。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】ＥＴＳＩ  ＥＳ  ２８２  ００３：「Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）；Ｒｅｓｏｕｒｃｅ  ａｎｄ  Ａｄｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｓｕｂ−ｓｙｓｔｅｍ（ＲＡＣＳ）：Ｆｕｎｃｔｉｏｎａｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ」
【非特許文献２】ＥＴＳＩ  ＴＳ  １０２  ０２８
【非特許文献３】ＥＴＳＩ  ＤＴＳ  １８３  ０６４  Ｖ  ０．０．５（２００８−０３）ＥＴＳＩ  Ｓｔａｎｄａｒｄ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  Ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ（ＴＩＳＰＡＮ）：Ｄｅｄｉｃａｔｅｄ  ＩＰＴＶ  ｓｕｂｓｙｓｔｅｍ  Ｓｔａｇｅ  ３  Ｓｐｅｃｉｆｉｃａｔｉｏｎ
【非特許文献４】ＸＰ０１５００９０３９
【非特許文献５】ＥＴＳＩ  ＴＳ  １８２０２８
【非特許文献６】ＥＴＳＩ  ＴＳ  １８２  ０１９
【非特許文献７】ＲＦＣ２３２６
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明は、改善されたリソース管理システムを提供する目的から生み出された。
【課題を解決するための手段】
【００１３】
本発明は、ネットワーク管理インターフェースへの分散型アクセスが必要とされず、拡張性およびパフォーマンスが制限されないソリューションを提供する。
【００１４】
本発明によれば、ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを備えたネットワークを含むデータ通信システムであって、コントロールサーバが、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すように構成されており、配信サーバが、コントロールサーバから独立してネットワークセッションをトラッキングするように構成されており、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、データ通信システムにおいて、配信サーバが、ネットワークセッションが完了するとネットワークセッションのＱｏＳネットワークセッションＩＤをコントロールサーバに返すように構成されており、ＲＡＣＳ（リソース／許可コントロールサーバ）が提供され、コントロールサーバが、ネットワークセッションＩＤを受信するとネットワークセッションを終了するようＲＡＣＳに指示するように構成されていることを特徴とする、データ通信システムが提供される。
【００１５】
コントロールサーバは、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡すように構成することができる。
【００１６】
コントロールサーバは、コントロールサーバから配信サーバに直接、またはＵＥを介して間接的にネットワークセッションＩＤを渡すように構成することができる。ＵＥは、ＲＴＳＰ（ｒｅａｌ  ｔｉｍｅ  ｓｔｒｅａｍｉｎｇ  ｐｒｏｔｏｃｏｌ）  ３００  ＲＥＤＩＲＥＣＴメッセージを使用してネットワークセッションＩＤを配信サーバに渡すように構成することができる。これらは、それら自体よく知られている。
【００１７】
ＵＥは、ＩＰＴＶ機器とすることができる。
【００１８】
実質的に、本発明は、ネットワークセッションの状態トラッキングを、リソースを確保している機能エンティティーから、コンテンツを配信する機能エンティティーへアウトソースすることを伴う。
【００１９】
さらなる態様における本発明によれば、ネットワークリソースを管理するためのコントロールサーバと、マルチメディアコンテンツを１つまたは複数のＵＥ（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）デバイスに配信するための配信サーバとを有するネットワークのネットワークリソースを管理する方法であって、配信サーバとＵＥデバイスの間におけるネットワークセッションのサービス品質（ＱｏＳ）ネットワークセッションＩＤを配信サーバに渡すステップと、配信サーバを使用して、コントロールサーバから独立してネットワークセッションをトラッキングするステップとを含み、それによって、ネットワークセッションのネットワークセッションＩＤが配信サーバに渡されると、コントロールサーバが、ネットワークセッションに関してステートレスである、方法において、ネットワークセッションが完了すると、配信サーバが、ネットワークセッションのネットワークセッションＩＤをコントロールサーバに返し、コントロールサーバがコントロールを再び得て、コントロールサーバが、ネットワークセッションＩＤを受信すると、ネットワークセッションを終了するようＲＡＣＳ（リソース／許可コントロールサーバ）に指示することを特徴とする、方法が提供される。
【００２０】
コントロールサーバは、配信サーバとＵＥの間におけるネットワークセッションの確立中にネットワークセッションＩＤを配信サーバに渡すことが好ましい。ネットワークセッションＩＤは、コントロールサーバから配信サーバに直接、またはＵＥを介して間接的に渡すことができる。ネットワークセッションＩＤは、間接的に渡される場合には、ＲＴＳＰ  ３００  ＲＥＤＩＲＥＣＴメッセージを使用してＵＥから配信サーバに渡されることが好ましい。
【００２１】
本発明を使用することによって、ネットワーク内の単一の機能エンティティーが、ＱｏＳセッションの状態を保持することなくリソースを管理する。この構成のおかげで、セキュリティーへの配慮から同一の機能エンティティーのみがリソースを管理することを許可されるため、クローズドなネットワークドメイン内でのリソース確保へのアクセスを保持することができる。これによって、セキュリティーが改善され、たとえばＤｏＳ（Ｄｅｎｉａｌ  ｏｆ  Ｓｅｒｖｉｃｅ）攻撃を防止することができる。
【００２２】
本発明はまた、本明細書に開示されている新規な特徴、特徴の組合せ、ステップ、またはステップの組合せのうちの任意の１つまたは複数を含むデータ通信のシステムまたは方法を提供する。
【００２３】
次いで本発明の実施形態について、例示のみを目的として、添付の概略図を参照して説明する。
【図面の簡単な説明】
【００２４】
【図１】ネットワークを概略的に示す図である。
【発明を実施するための形態】
【００２５】
図１を参照すると、本発明の一実施形態が概略的に示されている。ＵＥ１、この場合はＩＰＴＶ  ＵＥデバイス（たとえばセットトップボックスおよびディスプレイ）が、次世代ネットワーク（ＮＧＮ）に接続されている。単一のＵＥ１しか示されていないが、一般には、ネットワークに接続されている多数のＵＥ１が存在し、それらのＵＥ１どうしの間でネットワークリソースが共有されることになるということを理解されたい。
【００２６】
このネットワークは、次世代ネットワーク（ＮＧＮ）であり、すなわち、ＩＰおよびサービス品質（ＱｏＳ）テクノロジーを使用して、音声、データ、およびビデオを含む（ただし、それらには限定されない）すべてのタイプのカスタマートラフィックをサポートするように設計されたネットワークであり、それによって、さまざまなＩＰベースのカスタマーデバイスおよび次世代型の進化したアプリケーションが、単一の共通ネットワークを介して通信することができる。
【００２７】
このネットワークは、（ＥＴＳＩ  ＴＳ  １８２０２８において定義されている）ＩＰＴＶ−Ｃ（ＩＰＴＶコントロール）２と、ＲＡＣＳ（リソース／許可コントロールサーバ）３と、ＭＦ（メディア機能）４サーバ（この場合は、インタラクティブなメディア配信のためのＣｏＤサーバ（ＭＣＦ））と、ＢＧＦ（ボーダーゲートウェイ機能）デバイス５と、ローカルな一群のＵＥにアクセスを提供するアクセスノード（ＡＮ）６とを含む。これらの構成要素は、図に概略的に示されている。
【００２８】
いわゆる次世代ネットワーク（ＮＧＮ）以外のネットワークを含む代替ネットワーク構成が、本発明の範囲内で可能であるということを当業者なら容易に理解するであろう。
【００２９】
次いで、オンデマンドコンテンツ、たとえばＶＯＤ（ｖｉｄｅｏ  ｏｎ  ｄｅｍａｎｄ）をユーザが要求する用途におけるこのネットワークのオペレーションについて、図におけるラベル付けされたステップを参照しながら考察する（図における英数字でラベル付けされたラインは、物理的な（または無線による）ネットワーク接続ではなく、論理的な機能フローを表しているということに留意されたい。
【００３０】
実際には、ＵＥは、当然ながらＡＮ６を介してネットワークに接続することになり、ＡＮ６は、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ａｃｃｅｓｓ  Ｍｕｌｔｉｐｌｅｘｅｒ）とすることができる：
ａ）ユーザは、ＵＥからオンデマンドコンテンツを選択し、ＵＥは、ＣｏＤセッションを開始するためにリクエストをＩＰＴＶ−Ｃへ送信する。
【００３１】
ｂ）ＵＥ１からのリクエストを受信すると、ＩＰＴＶ−Ｃは、リソースの確保をＲＡＣＳにリクエストする。ＩＰＴＶ−ＣとＲＡＣＳは、ＥＴＳＩ  ＴＳ  １８２  ０１９において定義されているＧｑ’インターフェースを使用して接続されている。しかし、その他の標準団体またはフォーラム、たとえばＡＴＩＳ（Ａｌｌｉａｎｃｅ  ｆｏｒ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｉｎｄｕｓｔｒｙ  Ｓｏｌｕｔｉｏｎｓ）や、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｓ  Ｕｎｉｏｎ）において定義されている代替インターフェースを使用することもできる。
【００３２】
ｃ）ＲＡＣＳは、ＱｏＳセッションＩＤをＩＰＴＶ−Ｃに返す。
【００３３】
ｄ、ｅ）ＩＰＴＶ−Ｃは、ＱｏＳセッションＩＤをＣｏＤサーバに渡し、ＣｏＤサーバは、ＱｏＳセッションの参照を続けることになる（リソースの確保）。ＱｏＳセッションＩＤは、ＣｏＤサーバとＵＥの間におけるＣｏＤセッションの確立中に渡される。この時点から、ＩＰＴＶ−Ｃは、ＣｏＤセッションに関してステートレスである、すなわちＩＰＴＶ−Ｃは、自分が今しがた確保したＱｏＳセッションに関してそれ以上関知しない−換言すれば、ＱｏＳセッションに対する参照を続けず、そこにまったく関与しない。
【００３４】
ＱｏＳセッションＩＤは、ＲＦＣ２３２６において規定されているＲＴＳＰ（ｒｅａｌ  ｔｉｍｅ  ｓｔｒｅａｍｉｎｇ  ｐｒｏｔｏｃｏｌ）３００  ＲＥＤＩＲＥＣＴメッセージを使用して、ＵＥを介して渡される。しかし、任意の適切な代替プロトコルを使用することもでき、あるいはセッションＩＤを直接渡すこともできるということに留意されたい。
【００３５】
この例においては、ＱｏＳセッションは、ＣｏＤセッションの確立中にＣｏＤサーバに渡されるが、別法として、ＣｏＤセッションの確立前に渡すこともできる。さらに、この例においては、ＱｏＳセッションＩＤは、ＵＥを介して間接的にＣｏＤサーバに渡されるが、別法として、直接渡すこともできる。
【００３６】
ｆ）ＣｏＤサーバは、ＣｏＤセッションが機能している間はＱｏＳセッションをトラッキングする。上述のように、この期間中に、ＩＰＴＶ−Ｃは、ＱｏＳセッションに関してステートレスである。
【００３７】
ｇ）したがってＣｏＤサーバは、インタラクティブなコンテンツ配信の状態と、そのインタラクティブな配信がもはや必要とされなくなる時点とを知り、それに応じてＣＯＤサーバは、確保されているリソース（ＱｏＳセッション）がもはや必要とされなくなる時点を知る、または判断する。そのようにしてＣｏＤセッションが終了すると、ＣｏＤサーバは、ＱｏＳセッションが存在し、解放する必要がある旨をＩＰＴＶ−Ｃに通知し、ＣｏＤサーバは、ＱｏＳセッションＩＤをＩＰＴＶ−Ｃに返し、次いでＩＰＴＶ−Ｃは、ＱｏＳセッションに関してもはやステートレスでなくなり、再び主体的な役割を担うようになる。
【００３８】
ｈ、ｉ）ＩＰＴＶ−Ｃは、ＱｏＳセッションＩＤを指定して、Ｇｑ’インターフェースを介して、ＱｏＳセッションを終了するようＲＡＣＳをトリガーする。
【００３９】
このようにして、通常のオペレーション中に、ＩＰＴＶコントロールは、ＱｏＳセッション（確保されているリソース）をトラッキングせず、それによって、コスト効率のよい分散型ソリューションの構築が可能になる。ＱｏＳの状態は、そのＱｏＳが使用されている場所で維持され、それによって、別々の機能エンティティーの間でサービスセッション（ＣｏＤセッション）とリソース確保セッション（ＱｏＳセッション）とを同期化する必要がなくなる。
【００４０】
したがって、ＱｏＳセッションの状態トラッキングは、リソースを確保している機能エンティティーから、リソース確保の段階中にサービス配信のために選択された機能エンティティーへ「アウトソース」される。リソースを確保している機能エンティティーは、サービスを実行するために選択された機能エンティティーに、そのサービスが継続する間は、その選択された機能エンティティーがＱｏＳセッションのトラッキングを担当するよう指示する。サービスが終了し、重要とされる（ｕｎｄｅｒｌｉｎｅｄ）ＱｏＳセッションがもはや不要になると、サービスを提供している機能エンティティーは、リソースを確保している機能エンティティーに、確保されているリソースはもはや不要であり、解放することができる旨を返信する。
【００４１】
上述のように、単一のエンティティー、（すなわち、この実施形態では）ＭＦ（ＣＯＤ）サーバ４が、セッション中にリソースを管理するので、複数の構成要素／ノードが１つのネットワーク内に存在する場合に生じる可能性のあるセキュリティーの問題が最小限に抑えられるため、セキュリティーが大幅に改善される。
【００４２】
本発明では、ＮＧＮにおけるすべてのＱｏＳセッション（すなわち、すべてのＩＰＴＶ  ＣｏＤセッション）を単一の機能エンティティーがトラッキングする必要性をなくすことによって、従来技術の拡張性およびパフォーマンスの限界が取り除かれ、ステートレスな機能エンティティーによってリソースの確保および管理を実行することができるため、コスト効率のよい実施態様が可能になり、サービス機能とリソース管理機能の間における費用のかかる同期化が不要になり、そしてネットワーク管理インターフェースへの分散型アクセスを使用せずにオペレータの分散型リソース管理が可能になり、それによってセキュリティーリスクが減少し、たとえばＤｏＳ（ｄｅｎｉａｌ  ｏｆ  ｓｅｒｖｉｃｅ）攻撃が防止される。
【００４３】
記載の実施形態は、ＩＰＴＶに関連しているが、本発明は、次世代ネットワークを含む（ただし、それには限定されない）さまざまなネットワークにおける任意のタイプのマルチメディアコンテンツ、ならびにＩＰＴＶ以外のタイプのコンテンツおよびデータのための分散型リソース管理に適用可能であるということに留意されたい。
【図１】
0005271419.tif 000002