(57)【要約】  これらの例示的な実施形態によるシステムおよび方法は、通信システムにおいてリソースを交渉するための方法およびシステムを提供する。１つの例示的な方法には、サービスを求めるリクエストをサービスマネージャが送信することが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及することを特徴とする。加えて、リソースマネージャが、送信リクエストをサービスマネージャから受信して、明示的に送信されたサービス選択肢のリストかまたはサービス選択肢のリストへの言及に基づいてリクエストを処理することができる。
2010522453.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおいてリソースを交渉する方法であって、
サービスマネージャが、サービス要求を送信するステップを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及する
ことを特徴とする方法。
【請求項２】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージであって、当該リストの各エントリは複数のパラメータを含む
ことを更に特徴とする請求項１に記載の方法。
【請求項３】
前記複数のパラメータは、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザデバイスのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項１に記載の方法。
【請求項５】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項４に記載の方法。
【請求項６】
リソースマネージャが、前記リストを含む前記サービス要求を受信するステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項２に記載の方法。
【請求項７】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項６に記載の方法。
【請求項９】
リソースマネージャが前記要求を受信するステップと、
前記複数のサービス選択肢の前記リストを、前記リソースマネージャに関連するメモリデバイスから取り出すステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項４に記載の方法。
【請求項１０】
前記サービスマネージャは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項１に記載の方法。
【請求項１２】
通信システムにおいてリソースを交渉する方法であって、
リソースマネージャがサービス要求を受信するステップを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及する
ことを特徴とする方法。
【請求項１３】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージであって、当該リストの各エントリは複数のパラメータを含む
ことを更に特徴とする請求項１２に記載の方法。
【請求項１４】
前記複数のパラメータは、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザデバイスのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項１２に記載の方法。
【請求項１６】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項１３に記載の方法。
【請求項１８】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項１７に記載の方法。
【請求項２０】
前記複数のサービス選択肢の前記リストを、前記リソースマネージャに関連するメモリデバイスから取り出すステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項１５に記載の方法。
【請求項２１】
前記リソースマネージャは、サービスマネージャから受信した予約要求に基づいて、ドメイン内のネットワークリソースを予約し、割り当て、そして監視する機能を提供するサーバであることを特徴とする請求項１２に記載の方法。
【請求項２２】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項１２に記載の方法。
【請求項２３】
通信システムにおいてリソースを交渉する通信ノードであって、
サービス要求を送信するプロセッサを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及する
ことを特徴とする通信ノード。
【請求項２４】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージであって、当該リストの各エントリは複数のパラメータを含む
ことを更に特徴とする請求項２３に記載の通信ノード。
【請求項２５】
前記複数のパラメータは、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項２３に記載の通信ノード。
【請求項２６】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項２３に記載の通信ノード。
【請求項２７】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項２６に記載の通信ノード。
【請求項２８】
前記通信ノードは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項２３に記載の通信ノード。
【請求項２９】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項２３に記載の通信ノード。
【請求項３０】
通信システムにおいてリソースを交渉する通信ノードであって、
サービス要求を受信するプロセッサを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及する
ことを特徴とする通信ノード。
【請求項３１】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージであって、当該リストの各エントリは複数のパラメータを含む
ことを更に特徴とする請求項３０に記載の通信ノード。
【請求項３２】
前記複数のパラメータは、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項３０に記載の通信ノード。
【請求項３３】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項３０に記載の通信ノード。
【請求項３４】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項３０に記載の通信ノード。
【請求項３５】
前記プロセッサは、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価し、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記第１のノードが選択したかを示す、前記サービス要求に対する応答を送信する
ことを特徴とする請求項３１に記載の方法。
【請求項３６】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項３５に記載の通信ノード。
【請求項３７】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項３５に記載の通信ノード。
【請求項３８】
前記複数のサービス選択肢の前記リストをそこから取り出せる、前記リソースマネージャに関連するメモリデバイスを更に備え、
前記プロセッサは、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価し、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記第１のノードが選択したかを示す、前記サービス要求に対する応答を送信する
ことを特徴とする請求項３３に記載の通信ノード。
【請求項３９】
前記第１のノードは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項３０に記載の通信ノード。
【請求項４０】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項３０に記載の通信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に電気通信システムに関し、詳細には、ネットワーク上でサービスを配信するための方法およびシステムに関する。
【背景技術】
【０００２】
家電業界が成熟を続け、プロセッサの能力が向上するのに伴って、デバイス間でのデータ転送が可能なデバイスが次々と入手可能となっており、この転送されたデータに基づいて動作するアプリケーションも次々と入手可能となっている。特に注目すべきなのは、インターネットおよびローカル・エリア・ネットワーク（ＬＡＮ）である。これらの２つの革新によって、複数のユーザと複数のデバイスとが、様々なデバイスおよびデバイスタイプの間でデータを通信して交換することができる。これらのデバイスおよび能力の出現によって、ユーザはこれらのネットワーク上で多様なサービスを受信することをますます望むようになってきている。これらのサービス（またはアプリケーション）の一般的な例として、ビデオ・オン・デマンド（ＶｏＤ）、インターネットプロトコルテレビジョン（ＩＰＴＶ）および音声ファイルなどがある。さらに、これらのサービスの多くは、例えば、異なる形式で、また、多様なパラメータに基づいてというように、異なるサービス品質レベルで受信することができる。これらのパラメータとしては、例えば、ユーザの出力デバイス能力、利用可能な帯域幅、サービス契約およびネットワークリソースの利用可能性などがある。
【０００３】
ユーザがネットワーク上でサービスを求めかつ受信できる方法は、現在すでに存在する。ここで、そのような通信に関与しうる例示的要素を記述する基本的システムについて、図１に関連して記述しよう。これらの要素には、エンドユーザ１０２、リソースマネージャ（ＲＭ）１０４、サービスマネージャ（ＳＭ）１０６、アプリケーション機能（ＡＦ）１０８、およびネットワーク１１０が含まれる。これらの構成要素は、典型的には相互にネットワーク１１０上で通信することができるが、ネットワークリソースに関する制御機能の大半は、ＲＭ１０４によって行われ、他方、サービスポリシーおよびセッションに関する制御機能の大半は、ＳＭ１０６によって行われる。エンドユーザ１０２は、例えばディスプレイ付きのコンピュータ、テレビジョン、オーディオデバイスまたはそれに類似したもののような、ＡＦ１０８によって送信されたアプリケーションを広めるために用いられるデバイス（図示せず）と対話を行う。加えて、図１ではネットワーク１１０が唯一のネットワークとして図解されているが、多くの実例では、互いに相互接続された複数の異なるネットワークが存在する。
【０００４】
さらに、公共ネットワーク上で提供されるアプリケーションおよびネットワークサービスが複数の異なる運営事業体または組織によって提供されたりサポートされたりすることは普通である。これらの組織は、１つあるいは多数のビジネス的役割を果たすであろうし、また、１つあるいは複数の企業体の一部でもあるであろう。例えば、競合するプログラム配信業者が存在する場合もあるだろうし、あるいは、１つの会社が電話サービスや標準的なテレビ番組やＶｏＤ映画を提供することもあるだろう。従って、ネットワークリソースがいろいろな時に共有されうるとするならば、多数のネットワークを通して異なるサービスプロバイダによって提供される多様なアプリケーションと対話することを、エンドユーザがいかに望むであろうかということは、容易に理解できる。各種のサービスプロバイダからのこれらのネットワーク上でエンドユーザが何にアクセスできるかを定義する際に役立つ１つのツールは、サービスレベル契約（ＳＬＡ）である。
【０００５】
エンドユーザとサービスプロバイダの間の関係は、典型的には特定の契約を通して規制される。ＳＬＡは、サービス配信の一組の特性を定義する、エンドユーザとサービスプロバイダとの間の契約である。これには、例えば帯域幅やユーザがアクセスを許可されるサービスの利用可能性といった一般的な技術的側面と、例えば料金設定や罰則あるいは検証方法といった非技術的側面とが含まれる。この関係は、一般に、エンドユーザがＡＦからのサービスをリクエスト（要求）する前に確立される。
【０００６】
ＳＬＡの詳細がＳＭの理解できる形式、例えばプログラムまたはデータベースにまとめられた後、エンドユーザはサービスをリクエストすることができる。ここで、サービスリクエストについての現存のメッセージの流れ、および、それに関連するリソースの交渉について、図２に関連して記述しよう。最初に、エンドユーザ２０２が、サービスを求める要望を表すメッセージ２１０をＡＦ２０８へ送信する。次いでＡＦ２０８は、エンドユーザ２０２はそのアプリケーションへのアクセスを許可されるべきだということをＳＭがまず検証できるようにするメッセージ２１１をＳＭ２０６へ送信する。エンドユーザ２０２が所望のアプリケーションへのアクセスを許可されると、次いでＳＭ２０６は、リクエストと、関連するいずれかのＳＬＡの詳細とに基づいて、メッセージ２１２をＲＭ２０４へ送信する。メッセージ２１２には、サービス品質（ＱｏＳ）リクエストとそのリクエストに関するその他の適切な詳細とが含まれる。
【０００７】
この例ではＲＭ２０４は、例えば現在利用可能なネットワークリソースが不十分であることが原因で所望のＱｏＳを提供することができず、リクエストを拒否してメッセージ２１４をＳＭ２０６へ送信する。次いでＳＭ２０６は、同じアプリケーションのためのより低レベルのＱｏＳリクエストを含む別のメッセージ２１６をＲＭ２０４へ送信する。ＲＭ２０４は再度リクエストを拒否して、メッセージ２１８の中でＳＭ２０６に通知する。この反復プロセスは、ＲＭ２０４が認めうるリクエストを伴うメッセージ２２０をＳＭ２０６が送信するまで続く。次いで、この受入れメッセージ２２２が、ＲＭ２０４からＳＭ２０６へ送信される。この時点で、ＳＭ２０６は、ＡＦ２０８がアプリケーション２２６をエンドユーザ２０２へ送信することを可能にするメッセージ２２４をＡＦ２０８へ送信する。アプリケーション（サービス）２２６は、ＲＭ２０４によって指定される許容基準およびリソースに基づいてエンドユーザ２０２へ送信される。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
当業者なら理解するであろうが、リソース交渉のためのこの反復方法は、不要な帯域幅を消費して、通信ネットワークを通してのサービスの配信に重大な遅延をもたらすことがある。
【０００９】
従って、本書に記述した例示的な複数の実施形態は、ＳＭとＲＭとの間のメッセージングとエンドユーザへのアプリケーションの配信とを改良する必要性に取り組む。
【課題を解決するための手段】
【００１０】
１つの例示的な実施形態によると、通信システムにおいてリソースを交渉するための方法には、サービスを求めるリクエスト（サービス要求）をサービスマネージャが送信することが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及する。
【００１１】
別の例示的な実施形態によると、通信システムにおいてリソースを交渉するための方法には、サービスを求めるリクエストをリソースマネージャが受信することが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及する。
【００１２】
更に別の例示的な実施形態によると、通信システムにおいてリソースを交渉するための通信ノードには、サービスを求めるリクエストを送信するためのプロセッサが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及する。
【００１３】
更に別の例示的な実施形態によると、通信システムにおいてリソースを交渉するための通信ノードには、サービスを求めるリクエストを受信するためのプロセッサが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストに明示的にまたは暗示的に言及する。
【００１４】
添付の図面は、本発明の例示的な実施形態を示す。
【図面の簡単な説明】
【００１５】
【図１】アプリケーションをエンドユーザに配信するのに用いられる通信ネットワークの構成要素を示す図である。
【図２】アプリケーションをエンドユーザに配信するためにノード間で送信される一連のメッセージを示す図である。
【図３】例示的な実施形態によってアプリケーションをエンドユーザに配信するのに用いられる通信ネットワーク内の構成要素を示す図である。
【図４】例示的な実施形態によってアプリケーションをエンドユーザに配信するためにノード間で送信される一連のメッセージを示す図である。
【図５】例示的な実施形態によってサービス選択肢の順位リストを描いた図である。
【図６】例示的な実施形態によってサーバの構成要素を描いた図である。
【図７（ａ）】例示的な実施形態によってサービスマネージャおよびリソースマネージャによって用いられる通信方法および通信プロセスを描いたフローチャートである。
【図７（ｂ）】例示的な実施形態によってサービスマネージャおよびリソースマネージャによって用いられる通信方法および通信プロセスを描いたフローチャートである。
【図７（ｃ）】例示的な実施形態によってサービスマネージャおよびリソースマネージャによって用いられる通信方法および通信プロセスを描いたフローチャートである。
【発明を実施するための形態】
【００１６】
例示的実施形態についての下記の詳細記述は、添付の図面を参照する。異なる図面における同一の参照番号は、同一または類似の要素を特定する。また、下記の詳細記述は、本発明を限定するものではない。そうではなく、本発明の範囲は、添付の請求項によって定義される。
【００１７】
理想としては、エンドユーザは単一のアクセスポイントを通して多数のアプリケーションやサービスプロバイダにアクセスできるべきである。例えば、ユーザは、１台のテレビでＴＶ番組を視聴し、将来の利用を目的として録画機に映画を録画し、別の部屋でストリーミングオーディオを演奏し続けることを望むかもしれないし、それらがすべて単一のアクセスポイントを介して提供されることが望ましい。エンドユーザからのこれらのリクエストを実装するため、多数のメッセージおよび構成要素が対話する。例示するリソース交渉をこれらの例示的実施形態によって議論するために何らかのコンテクストを提供することを目的として、まず、例示する通信ネットワークについて図３に関して記述しよう。
【００１８】
この中で、相互接続ネットワーク３００のグループ分けは、加入者宅内機器ネットワーク３０２と、ファーストマイル／ラストマイルネットワーク３０４と、アクセスネットワーク３０６と、地域ネットワーク３０８と、サービスプロバイダネットワーク３１０と、ＩＤプロバイダ３１２と、アプリケーションサービスプロバイダ３１４とに分類できる。加入者宅内機器ネットワーク３０２には、ネットワーク対応の宅内機器、例えばコンピュータ３１６と、ラップトップ３１８と、ＴＶ３２０と、レジデンシャルゲートウェイ３２２とが含まれる。レジデンシャルゲートウェイ３２２は、ルータかまたは住宅から外部ネットワークまでのいずれかの他の接続であってもよいだろう。ファーストマイル／ラストマイルネットワーク３０４には、加入者宅内機器ネットワーク３０２におけるレジデンシャルゲートウェイ３２２からアクセスネットワーク３０６におけるアクセスノード３２４までの通信を提供するために用いられる各種の接続および機器（図示せず）が含まれる。アクセスネットワーク３０６には、アクセスノード３２４と、アクセスエッジサイト（ＡＥＳ）３２８と、サーバ（図示せず）上で実行されるリソースマネージャ（ＲＭ）３２６とが含まれる。ＡＥＳ３２８は、アクセスネットワーク３０６中のノードとも地域ネットワーク３０８中のノードとも通信する。また、地域ネットワーク３０８には、ボーダエッジサイト（ＢＥＳ）３３０および３３２が含まれるが、それらはサービスプロバイダネットワーク３１０の一部であってもよいだろう。また、サービスプロバイダネットワーク３１０には、サーバ（図示せず）上で実行されるサービスマネージャ（ＳＭ）３３４が含まれる。加えて、アプリケーションサービスプロバイダ３１４に関連するサーバ（またはアプリケーション機能（ＡＦ））３３６、３３８、３４０、および、ＩＤプロバイダ３１２に関連するサーバ３４２は、サービスプロバイダネットワーク３１０の範囲内の要素と通信することができる。これらの例示的な構成要素は、エンドユーザへのサービスを通信し、制御し、配信するために用いられる。しかし、理解されるであろうが、用いられる構成要素が上記より多いかまたは少なくてもよく、例えば、より多くのサービスプロバイダが、通信路の中でより多くのサーバおよび／またはより多くのルータ上でより多くのアプリケーションを実行することがあってもよい。さらに、サーバが複数のアプリケーション機能をサポートしてもよいだろう。
【００１９】
上記の例示するシステムの中で最も注目される機能要素は、ＲＭ３２６とＳＭ３３４とＡＦ３３６とである。ＡＦ３３６とＳＭ３３４とＲＭ３２６との間の対話には、以下の一組の機能をサポートするために用いられるシグナリングが含まれるが、機能とは、（１）サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能、（２）サービスポリシー制御およびネットワークポリシー制御に基づく入場制御のための機能、（３）アクセスネットワークおよび隣接ネットワークの中のリソースを予約する特定の機能を備えた、多様なサービスプロバイダによって提供されるサービスを提供する機能、（４）複数の管理領域の全域におよぶリソース予約および入場制御のための機能、（５）ポリシープルＱｏＳシナリオおよびポリシープッシュＱｏＳシナリオに関連する機能、（６）保証された、規制された、そしてベストエフォートの、ネットワークサービスクラス（ＮＳＣ）に関連する機能、（７）課金情報のエクスポートおよび監視を目的とするＱｏＳ測定に関連する機能、および、（８）さまざまな基礎的なアクセスネットワーク技術およびコアネットワーク技術に関連する機能である。
【００２０】
ＡＦ３３６は、エンドユーザにサービスを配信する責任を持つネットワークエンティティである。従ってＡＦ３３６は、サービスをエンドユーザに配信するのに必要なリソースのタイプおよび量を知っているエンティティである。ＡＦ３３６の例として、ビデオストリーマ、ＩＰ電話（ＶｏＩＰ）ゲートウェイ、および他のメディアサーバがある。サービスを配信する前に、ＡＦ３３６は、ＳＭ３３４からの許可を要求する。
【００２１】
ＳＭ３３４は、レジストリを通して、ＱｏＳ対応サービスの公開および提供をコーディネートする。ＳＭ３３４は、さまざまな公開されたサービスがその中で制御される容器とみなすことができる。さらに、ＳＭ３３４は、特定のポリシーに基づいてサービスリクエストを処理するためにユーザポータルおよびＡＦ３３６（例えばメディアサーバ）と対話する。対話は、領域内インタフェースまたは領域間インタフェースを通して行われてもよい。また、ＳＭ３３４は、２つ以上のユーザポータルおよびＡＦ３３６にサービス提供できる。しかし、サービスセッションベースでは、ユーザポータルおよびＡＦ３３６は典型的には１つのＳＭ３３４とだけ対話する。また、ＳＭ３３４は、エンドユーザは自分が要求したサービスを受信する権利があることを検証し、そして、権利がある場合、ＳＭ３３４は次いで必要なリソースをＲＭ３２６に要求する。
【００２２】
例示する実施形態によると、ＳＭ３３４は、さらに、拡張マークアップ言語（ＸＭＬ）で符号化されたシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージをその終点へ送信することによって、そして、ＳＯＡＰメッセージ応答を受信することによって、ウェブサービスを通してＲＭ３２６と通信する。ビジネス上の役割が多様なかたちで実装されることが見込まれるため、ＳＭ３３４は、それが対話するＲＭ３２６と同じ領域の中に位置してもよいし、異なる領域の中に位置してもよい。従って、２つのエンティティ間のインタフェースは両方の場合をサポートすべきである。ＲＭ３２６は、２つ以上のＳＭ３３４にサービス提供することができ、１つのＳＭ３３４が、多数のＲＭ３２６と対話してもよいが、サービスセッションベースでは、ＳＭ３３４は典型的には１つのＲＭ３２６とだけ対話する。特定のサービスに関してエンドユーザと交渉されたサービスレベル契約（ＳＬＡ）に基づいて、ＳＭ３３４は、セッションおよびメディア関連情報を、サービスレベル仕様（ＳＬＳ）の形で、ＲＭ３２６へリソース予約と入場制御を目的として送信する責任とを有する。ＳＬＡおよびＳＬＳについては、以下で詳細に論じる。予約が成功するとＳＭ３３４は、必要に応じて情報を同期させるためにＡＦ３３６と通信してもよい。
【００２３】
ＲＭ３２６は、ＳＭ３３４から受信した特定のＳＬＳ予約リクエストに基づいて所与の領域の範囲内でネットワークリソースを予約し、割り当て、監視する責任を有する。加えて、ＲＭ３２６は、必要に応じて領域の境界線を跨いでＳＬＳをコーディネートすることを目的として、隣接する領域内の他のＲＭ３２６との領域間通信を管理する責任がある。ＲＭ３２６は、ウェブサービスを通してＸＭＬで符号化されたＳＯＡＰメッセージをそれらの終点に対して送信し、そしてＳＯＡＰメッセージ応答を受信することによって、相互に通信する。その目的で、ＲＭのインタフェースは、ウェブサービス記述言語（ＷＳＤＬ）を用いて文書化され、それらの各々のレジストリの中で公開される。隣接する領域は、配信が領域間の境界線を越える場合、エンド・ツー・エンドのサービスを提供するため、協力する。各領域は、そのサービストラヒックを配信するためにその隣接領域に依存し、次には、この隣接領域が、サービストラヒックをその隣接領域に渡すというようなことが、最終目的地に到着するまで行われる。典型的には、管理領域毎に１つのＲＭ３２６が存在する。また、ＳＬＳ予約リクエストにサービス提供する以外にも、ＲＭ３２６は、ローカル許可ポリシーに基づいて入場制御を行い、ネットワークを適切に構成するためにネットワーク要素の中でレイヤ２ポリシーとレイヤ７ポリシーとを設定し、そして、その領域の端部（すなわち、隣接ネットワークに接続しているノード）を含めてその領域の範囲内のリソースの状態を監視する。
【００２４】
いったんＲＭ３２６が予約リクエストを通してＳＬＳを受信すると、それは、各隣接領域について１つずつの、複数の単一領域ＳＬＳインスタンスに再帰的に分割される。ＲＭ３２６は、２段階のリソース予約と１段階のリソース予約とをサポートすることができる。２段階のケースでは、必要なリソースが最初に予約され、その予約は、リソースが利用可能であることだけを保証する。その後、別個のメッセージを使って予約が行われた場合には、リソースがネットワーク内で構成されうる。この２段階予約技術は主に、領域間の予約リクエストを管理するために用いられる。１段階のリソース割り当ては、予約リクエストが行われた時点ですべてのパラメータが既知である場合には、いつでも用いられうる。加えて、既存の予約への修正を要求することも可能である。
【００２５】
通信ネットワークで用いられる上記の構成要素は、多様なメッセージタイプを送信し、受信し、転送することができる。インスタントアプリケーションの中で特に注目されるメッセージは、アプリケーション（サービス）をエンドユーザに提供するために用いられることになるリソースについて交渉することに関するメッセージである。例示する実施形態によると、ＳＭ３３４とＲＭ３２６との間で往復して送信されるメッセージの量は、現在使われている方法に比べて著しく削減することができる。ここで、図４に示す例示的実施形態による通信シーケンス４００について、記述しよう。
【００２６】
ここでは、エンドユーザ４０２が、リクエストされるサービスを指示するメッセージ４１０をＡＦ４０８へ送信する。次いでＡＦ４０８が、メッセージ４１１をＳＭ４０６へ送信し、それによってＳＭ４０６は、エンドユーザ４０２がそのアプリケーションへのアクセスを許可されるべきだということを最初に検証することができる。エンドユーザ４０２が所望のアプリケーションへのアクセスを許可されると、次いでＳＭ４０６は、リクエストおよび関連するいずれかの現行のＳＬＡの詳細に基づいて、メッセージ４１２をＲＭ４０４へ送信する。この例示的実施形態によると、メッセージ４１２には、ＱｏＳリクエストの選択肢を記述する順位リストと、リクエストに関するその他の関連する詳細とが含まれる。例えば、メッセージ４１２は、リクエストされたサービスが配信されうる各種のやり方についての選好序列を指示することができる。このメッセージ４１２の例を、以下の図５に関して詳細に論じる。
【００２７】
サービスリクエストメッセージを受信すると、次いでＲＭ４０４は、現在利用可能なネットワークリソースと、場合によってはその他の要因とに基づいて、所望のアプリケーションをエンドユーザに対して提供可能な最高レベルのサービス（または順位リストの中で最高の順位を得たサービス選択肢）を判定する。次いでＲＭ４０４は、予約トークンおよび選択されたサービスレベルを含めてこの受入れ情報を、メッセージ４１４でＳＭ４０６へ送信する。次いでＳＭ４０６は、メッセージ４１６をＡＦ４０８へ送信し、それによってＡＦ４０８は、交渉されたサービスレベルを用いて所望のアプリケーション４１８をエンドユーザ４０２に送信することができる。このプロセスは、ＳＭ４０６がサービスレベルを、その第１の、第２の、第３の、等等のサービス選択肢の選択が利用できない場合には、どのように交渉するであろうかということを最初のインスタンスの中に指示する、サービス選択肢の順位リストをメッセージ４１２の中に提供することによって、ＳＭ４０６とＲＭ４０４の間で送信されることが見込まれるメッセージ数を著しく削減する。従って、特定のアプリケーション（サービス）が提供されうるサービスレベルの選択肢の各々についてＳＭとＲＭとの間で、恐らく、複数の交渉メッセージが交換される代わりに、一度のメッセージ交換を採用することができる。
【００２８】
上記のように、例示する一実施形態によると、ＳＭ４０６からＲＭ４０４へのメッセージには、ＱｏＳ選択肢の順位リストだけでなく、例えば、エンドユーザデバイスのアドレス情報およびＡＦ４０８のアドレス情報が含まれる。例えば、ＳＭ４０６は、エンドユーザデバイスのアドレス、ＡＦ４０８のアドレス、サービス識別子「ジェームズ・ボンド」およびＱｏＳ選択肢の順位リストを含んだメッセージを送信することができよう。図５に描かれた純粋に例示的な順位リスト５００には、列で示され、選択の順に列挙された３つのサービス選択肢が含まれる。各サービス選択肢はそれぞれ、一組のパラメータ（パラメータセット）、すなわち、表示形式、帯域幅フィールドおよびコーデックフィールドを含む。映画「ジェームズ・ボンド」が配信されるやり方に関して、選択肢＿１  ５０２は、例えばエンドユーザが最も望む選択肢であり、選択肢＿３  ５０６は、最も望まれない選択肢である。選択肢＿１  ５０２のパラメータは、Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  ＴＶ（ＨＤＴＶ）、高帯域幅、およびＭｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）４を含む。選択肢＿２  ５０４のパラメータは、Ｅｎｈａｎｃｅｄ  Ｄｅｆｉｎｉｔｉｏｎ  ＴＶ（ＥＤＴＶ）、中帯域幅、およびＭＰＥＧ−２を含む。選択肢＿３  ５０６のパラメータは、Ｓｔａｎｄａｒｄ  Ｄｅｆｉｎｉｔｉｏｎ  ＴＶ（ＳＤＴＶ）、低帯域幅、およびＭＰＥＧ−２を含む。前述したように、ＲＭ４０４は、順位リストのそれぞれにおけるこれらの特定のサービスリクエストの選択肢を選択して、利用可能なリソースにそれらを適合させて、ネットワークで現在サポートされうる最高の順位の選択肢はどれであるかを判定する。理解されるべきだが、図５に示す順位リストに用いられたパラメータは、使用されるために利用可能である見込みがあるパラメータの一部を単純に例示しているのであって、その他の情報が、ＳＭ４０６からＲＭ４０４へ送信されるメッセージ４１２の中に含まれてもよい。加えて、リスト５００に、明示的な順位情報、例えば、選択の順に体系化されるのではなく、番号を振ったフィールドが含まれてもよい。
【００２９】
別の例示的な実施形態によると、順位リストは、メッセージ４１２で明示的に送信されるのではなく、代わりに、事前にＲＭ４０４の中に、例えばそれに関連するメモリデバイスの中に、記憶される。この場合、ＳＭ４０６は、例えば所望のサービス識別子とエンドユーザデバイスのアドレス情報と（あるいはエンドポイントを識別するためのその他の適切な情報）を含むメッセージをＲＭ４０４へ送信する。このメッセージを受信した時点で、ＲＭ４０４は、ＳＭ４０６および所望のサービスによって指定された特定のエンドユーザデバイスのアドレスに関連する、前に記憶された順位リスト情報にアクセスする。次いで、この情報を利用可能なネットワークリソースに合致させ、そこから、ＲＭ４０４は、どのＱｏＳレベルでアプリケーションがエンドユーザへ送信されるであろうかを決定する。例をあげると、例えば「ジェームズ・ボンド」のような所望の映画とエンドユーザデバイスのアドレス情報とを含むメッセージがＳＭ４０６からＲＭ４０４へ送信されると仮定する。ＲＭ４０４は、その情報を使って、識別されたサービスに関連する、事前に記憶されたサービス選択肢順位リストを検索する。例えば、各エントリに必要なリソースと現在利用可能なリソースとが与えられた場合に、リクエストされたサービスを提供するためにどの最高順位のエントリを使用しうるかを判定することを目的として、（例えば図５に示したもののような）事前に記憶されたサービス選択肢順位リストの中の各選択肢が、次いで評価されてもよい。
【００３０】
この決定を行うため、例えば既知のリクエストまたはスケジュール化されたハードウェアダウンタイムのような、上記のパラメータへの追加パラメータまたは代替パラメータが、ＲＭ４０４によって用いられてもよい。次いで、この情報がＳＭ４０６へ返信され、それによってエンドユーザにアプリケーションを提供するためのプロセスが続いてもよい。さらに、ＲＭ４０４は、ＳＭ４０６によって送信されたリクエストメッセージに基づいてアクセスされる特定のサービスに関連して事前に記憶された複数のリストを有することもできよう。あるいは、ＲＭ４０４の中に事前に記憶されたリストとＳＭ４０６からのメッセージの中で送信されたリストとを両方使用することもできる。後者の場合、ＲＭ４０４は、２つのリストを合致させて新たな順位リストを生成し、そこから、要求されたアプリケーションのためのＱｏＳパラメータが選択されてもよいだろう。
【００３１】
別の例示的な実施形態によると、ＲＭ４０４は、このサービス選択肢のリストの範囲から、少なくとも部分的に、ユーザの選択および利用可能なリソース以外のものに基づいて、選択することができる。例えば、ＳＭ４０６が、リソースリクエストをＲＭ４０４へ送信し、そして、リクエストの中にＲＭ４０４が理解できないコードが存在すると仮定する。このシナリオは、例えば、ＳＭ４０６が順位付けされた順序になっていないリストを送信する場合、あるいは、例えばＲＭ４０４が認識できないタイプのコーデックを用いるリクエストのような、ＲＭ４０４の精通していないリソースをＳＭ４０６が要求する場合に生じうるであろう。次いで、ＲＭ４０４は、リスト内をナビゲートして、自分の理解するサービスの選択肢を見つけ、そして、リスト内のそのポイントから、どのサービスレベルを提供するかを、利用可能なネットワークリソースに基づいて判定することができるであろう。別の例として、ＳＭ４０６が、例えば、ＱｏＳより優先度が高いとしてリストされる、コストのようなパラメータを含むリクエストメッセージをＲＭ４０４へ送信すると仮定する。この場合、ＲＭ４０４は、コスト制限を満たすベストな利用可能ＱｏＳが見つかるまでリストをナビゲートすることができるであろう。
【００３２】
ＲＭ４０４およびＳＭ４０６は、典型的には、異なる領域内にあることが多い別個のサーバ上に存在する。例えば、図６に一般的に示すように、そのようなサーバ６００は、プロセッサ６０２（または複数のプロセッサコア）と、メモリ６０４と、１つ以上の二次的記憶装置６０６と、プロセッサ６０２上で実行されてメモリ６０４を用いるオペレーティングシステム６０８と、並びに、例えばＲＭ４０４のためのリソース管理プログラムおよびＳＭ４０６サーバのためのサービスマネージャプログラムのような、対応するアプリケーション６１０とを含んでもよい。サーバ６００とそれ以外のネットワークとの間の通信を円滑に行うために、インタフェースユニット６１２が提供されるか、または、プロセッサ６０２に組み込まれてもよい。また、サーバ６００について記述してきたのと同じかまたは類似した構成要素を、ルータやネットワークノードが自分のために有することもできる。従って、例示的実施形態によると、サーバまたはネットワークノードには、アプリケーション（サービス）をエンドユーザに供給することに関連するメッセージを送受信するためのプロセッサが含まれてもよい。例えば、ＳＭ４０６の観点から、通信ノードには、サービスを求めるリクエストを送信するためのプロセッサが含まれてもよく、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及することを特徴とする。別の例として、ＲＭ４０４の観点から、通信ノードには、サービスを求めるリクエストを受信するためのプロセッサが含まれてもよく、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及することを特徴とする。
【００３３】
エンドユーザがリクエストするサービスのタイプによっては、サービスを、ユニキャストメッセージストリームとしてかまたはマルチキャストメッセージストリームとしてかいずれか一方で提供することができる。例をあげると、エンドユーザが例えばジェームズ・ボンドの映画のようなサービスをビデオ・オン・デマンド（ＶｏＤ）サービスの一部としてリクエストし、承認を受信した場合には、この特定の時間にはエンドユーザだけが、例えば再生、一時停止、早送りなどの、自分の特定の制御選択肢を持ってその映画を視聴するのであろうから、メッセージは、ユニキャストメッセージストリームとして送出されるであろう。このアプリケーションは、そのエンドユーザにとって一意であることが必要であることから、それをユニキャストメッセージとして送出することが適切である。別の例として、現在複数のエンドユーザに対してブロードキャストされている定期のＴＶ番組をリクエストするエンドユーザについて考えよう。このＴＶ番組は、特定の時間に限ってブロードキャストされ、複数のエンドユーザに対して送信されることから、アプリケーションはマルチキャストストリームとして送出される。これらの例示的実施形態によるＳＭ４０６とＲＭ４０４の間のリソース割り当てメッセージングは、ユニキャストシグナリングに関連するサービスがリクエストされているのかマルチキャストシグナリングに関連するサービスがリクエストされているのかに応じて異なってもよい。ユニキャストリソース予約およびマルチキャストリソース予約のための詳細であるが純粋に例証である一部の実施形態について、以下に記述する。
【００３４】
例示するユニキャストのリソース交渉メッセージング
例えばＶｏＤのようなユニキャストを介してエンドユーザにアプリケーションまたはサービスを配信することに関して用いられる例示的なメッセージおよび動作について、ＳＭ４０６とＲＭ４０４の間の通信に関連して説明する。これらの動作には、例えば、リソース割り当て動作とリソース修正動作とリソース解放動作とが含まれる。
【００３５】
リソース割り当て動作は、新たなリソースが必要な場合に、例えば上記のメッセージ４１２のコンテクストにおいて、ＳＭ４０６によって用いられる。このメッセージの中でＳＭ４０６は、ソース（エンドユーザデバイス）インターネットプロトコル（ＩＰ）アドレスと宛先（ＡＦ）ＩＰアドレスとの間にリソースを割り当てるようにＲＭ４０４に要求する。この純粋に例示的な例におけるリソース割り当て動作には、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」と呼ばれる入力構造と、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」と呼ばれる出力構造とが含まれる。
【００３６】
この例示的実施形態によると、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージは、エンドユーザがアクセスを望むアプリケーションに関する情報をＳＭ４０６からＲＭ４０４へ伝達するのに用いられる。この例では、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造には、「ｒｅｓＩｄ」パラメータと「ｓｌｓ」パラメータとが含まれる。加えて、リソースが割り当てられた場合には、グローバル的に一意であるリソース識別子によってそれらを参照することができる。「ｒｅｓＩｄ」パラメータは、このリソース識別子を表す任意のパラメータ文字列である。「ｒｅｓＩｄ」が存在している場合、このリクエストに関連するリソースは、「ｒｅｓＩｄ」で指定される値によって識別されるであろう。それが存在していない場合、ＲＭ４０４は、一意のリソース識別子を生成して、それを応答のかたちでＳＭ４０６に返信するであろう。「ｓｌｓ」パラメータについては、この例によって実際に必要なリソースのパラメータを説明する、ＸＭＬで符号化された文字列として、以下に記述する。
【００３７】
＜?xml encoding=“UTF-8”?＞
＜!ELEMENT sls(FullResponse?,SourceAddr,DestinationAddr,UnicastSelections＞
＜!--The＜FullResponse＞value should be 0 or 1--＞
＜!ELEMENT FullResponse(#PCDATA)＞
＜!ELEMENT UnicastSelections(Media+)＞
＜!ELEMENT Media SourceAddr,DestinationAddr＞
＜!ATTLIST Media nsc NMTOKEN #REQUIRED
downstream NMTOKEN #IMPLIED
upstream NMTOKEN #IMPLIED＞
＜!ELEMENT SourceAddr(#PCDATA)＞
＜!ELEMENT DestinationAddr(#PCDATA)＞
【００３８】
上記の「ＦｕｌｌＲｅｓｐｏｎｓｅ」フィールドは、応答の中ではＳＭ４０６がリソースの見出しだけではなくて選択されたリソースの記述全体を必要とすることを、ＲＭ４０４に示す。「ｎｓｃ」パラメータは、ＲＭ４０４構成データに相関されていることが望ましい。ＲＭ４０４の中で、１つの「ｎｓｃ」値が特定の優先度および特定のＱｏＳに変換される。「ＳｏｕｒｃｅＡｄｄｒ」および「ＤｅｓｔｉｎａｔｉｏｎＡｄｄｒ」の値は、ｖｒ，ＩＰＡｄｄｒｅｓｓの形式になっており、ここで「ｖｒ」はＩＰアドレスが割り当てられているＩＰ領域である。「ＳｏｕｒｃｅＡｄｄｒ」は、エンドユーザデバイスのＩＰアドレスである。「ＤｅｓｔｉｎａｔｉｏｎＡｄｄｒ」は、ＡＦサーバのＩＰアドレスである。「ＳｏｕｒｃｅＡｄｄｒ」と「ＤｅｓｔｉｎａｔｉｏｎＡｄｄｒ」のペアは、異なるサービスクラスが異なるサーバによって配信されることがあるため、メディア毎に異なることがある。「ｕｐｓｔｒｅａｍ」パラメータおよび「ｄｏｗｎｓｔｒｅａｍ」パラメータは、そのメディアのために要求された帯域幅の品質を表し、それらの値は、例えばキロビット／秒で指定されてもよい。典型的には、２つのパラメータのうち少なくとも１つは存在するが、メディアの記述の中に両方が出現してもよい。
【００３９】
この例では、ＲＭ４０４は、リクエストの中に出現する順序でリクエストを利用可能なリソースに合わせることによって、各＜Ｍｅｄｉａ＞のエントリを試行するであろう。次いで、最初に成功した＜Ｍｅｄｉａ＞に関連するリソースが予約されて、応答の中でＳＭ４０６へ返信されるであろう。理解されるべきだが、上述したリクエストの符号化は、例えばＡｂｓｔｒａｃｔ  Ｓｙｎｔａｘ  Ｎｏｔａｔｉｏｎ  ｏｎｅ（ＡＳＮ．１）またはＴｙｐｅ  Ｌｅｎｇｔｈ  Ｖａｌｕｅ（ＴＬＶ）のような各種の形式のうちのいずれかであってもよいだろう。上記で示したメッセージは、一組のネットワークサービスクラスがＳＭ４０６とＲＭ４０４との間で事前に確立しているような、すなわち、好適サービスの選択肢リストが「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの中では明示的に送信されないような、例示的な実施形態を記述する。別の例示的実施形態では、ＳＭ４０６は、ネットワークサービスクラスの順位リストを「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの中で直接ＲＭ４０４に提供することができる。
【００４０】
「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージに応じて、ＲＭ４０６は、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」メッセージを送信してもよい。この例示的な実施形態による「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」構造には、「ｄｏｎｅ」パラメータ、「ｒｅｓＩｄ」パラメータ、そして「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータが含まれる。「ｄｏｎｅ」パラメータは、リソース割り当て動作のステータスを提供する。「−１」の値はエラーを表し、「０」の値はリソースが現在利用できないことを表し、「１」の値は、リソースがこのリクエストに割り当てられたことを表す。「ｒｅｓＩｄ」パラメータは、割り当てられたリソースに関連するリソース識別子を提供し、そして、「ｄｏｎｅ」パラメータが「１」の値と共に返信された場合に限って提供されてもよい。また、この「ｒｅｓＩｄ」パラメータを、その後のメッセージの中でリソースを更新するか解放するために用いることもできる。「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータは、＜ＦｕｌｌＲｅｓｐｏｎｓｅ＞のタグが「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造の「ｓｌｓ」文字列の中に存在して、その値が「１」である場合に割り当てられた実際のリソースを表す、ＸＭＬで符号化された文字列である。この例による「ｓｌｓＲｅｓｐｏｎｓｅ」の文字列の形式は、下記のＤｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ（ＤＴＤ）によって管理される。
【００４１】
＜?xml encoding=“UTF-8”?＞
＜!ELEMENT sls UnicastSelections＞
＜!ELEMENT UnicastSelections(Media)＞
＜!ELEMENT Media SourceAddr,DestinationAddr＞
＜!ATTLIST Media nsc NMTOKEN #REQUIRED
downstream NMTOKEN #IMPLIED
upstream NMTOKEN #IMPLIED＞
＜!ELEMENT SourceAddr(#PCDATA)＞
＜!ELEMENT DestinationAddr(#PCDATA)＞
【００４２】
上記のＸＭＬ文字列の中で用いられるフィールドの定義は、上記の「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの中でこの純粋に例示的なメッセージのために用いられたのと同じ定義であってもよい。
【００４３】
例示的な実施形態は、初期のリソースの割り当てに関連するメッセージングに限定されるのではなく、その後のリソース交渉に関連するメッセージングの中で、それにも関連するシグナリングの量を削減するためにも用いられてよい。例えば、別の例示的な動作であるｍｏｄｉｆｙＲｅｓｏｕｒｃｅが、以前に割り当てられたリソースへの修正が望まれるかまたは必要となる場合に、ＡＦによって用いられる。この純粋に例示的な例によると、ｍｏｄｉｆｙＲｅｓｏｕｒｃｅ動作には、入力構造「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」と出力構造「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」とが含まれる。「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造には、「ｒｅｓＩｄ」パラメータと「ｓｌｓ」パラメータとが含まれる。「ｒｅｓＩｄ」パラメータは、以前に割り当てられたリソースに関連するリソース識別子を表す文字列であり、そして「ｓｌｓ」パラメータは、既存のリソースの修正について記述する、ＸＭＬで符号化された文字列である。この例による「ｓｌｓ」文字列の形式は、下記のＤＴＤによって管理される。
【００４４】
＜?xml encoding=“UTF-8”?＞
＜!ELEMENT sls UnicastSelections＞
＜!ELEMENT UnicastSelections(Media+)＞
＜!--「ｎｓｃ」属性は、Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒによって内部的に用いられる値とコーディネートさせるべきである
「ｄｏｗｎｓｔｒｅａｍ」および「ｕｐｓｔｒｅａｍ」のための形式は、任意でＭまたはＧが続く整数である。ＭもＧも存在しない場合には、その値はキロビット／秒を指定する。Ｍはメガビット／秒であり、
Ｇはギガビット／秒であり、
例えば  ２００    １２Ｍ  １Ｇである
ｕｎｉｃａｓｔＳｅｌｅｃｔｉｏｎｓの中では、「ｄｏｗｎｓｔｒｅａｍ」または「ｕｐｓｔｒｅａｍ」またはその両方を定義してもよい。少なくとも１つは存在しなければならない。--＞
＜!ELEMENT MediaEMPTY＞
＜ATTLIST Media nsc NMTOKEN #REQUIRED
downstream NMTOKEN #IMPLIED
upstream NMTOKEN #IMPLIED＞
【００４５】
上記のＸＭＬ文字列の中で用いられるフィールドの定義は、上記の「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの中で用いられるのと同じ定義であってもよい。
【００４６】
「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージに応じて、ＲＭ４０４が、「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージを送信してもよい。この例示的実施形態による「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造には、「ｄｏｎｅ」パラメータおよび「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータが含まれる。「ｄｏｎｅ」パラメータは、リソース割り当て動作のステータスを提供する。「−１」の値はエラーを示し、「０」の値はリソースが現在は利用不可能であることを示し、「１」の値はリソースが修正されたことを示す。「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータは、タグ＜ＦｕｌｌＲｅｓｐｏｎｓｅ＞が「ｍｏｄｉｆｙＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造の「ｓｌｓ」文字列の中に存在し、かつその値が「１」である場合に、修正された実際のリソースを表す、ＸＭＬで符号化された文字列である。「ｓｌｓＲｅｓｐｏｎｓｅ」文字列の形式は、この例によると、下記のＤＴＤによって管理される。
【００４７】
＜?xml encoding=“UTF-8”?＞
＜!ELEMENT sls(UnicastSelections)＞
＜!ELEMENT UnicastSelections(Media)＞
＜!--「ｎｓｃ」属性は、Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｒによって内部的に用いられる値とコーディネートさせるべきである
「ｄｏｗｎｓｔｒｅａｍ」および「ｕｐｓｔｒｅａｍ」のための形式は、任意でＭまたはＧが続く整数である。ＭもＧも存在しない場合には、その値はキロビット／秒を指定する
Ｍはメガビット／秒であり、
Ｇはギガビット／秒であり、
例えば  ２００    １２Ｍ  １Ｇである
ＵｎｉｃａｓｔＳｅｌｅｃｔｉｏｎｓの中では、「ｄｏｗｎｓｔｒｅａｍ」または「ｕｐｓｔｒｅａｍ」またはその両方を定義してもよい。典型的には少なくとも１つは存在する。--＞
＜!ELEMENT Media EMPTY＞
＜ATTLIST Media nsc NMTOKEN #REQUIRED
downstream NMTOKEN #IMPLIED
upstream NMTOKEN #IMPLIED＞
【００４８】
上記のＸＭＬ文字列の中で用いられるフィールドの定義は、上記の「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの中で用いられるのと同じ定義であってもよい。
【００４９】
これらの例示する技術を用いて実装されうる、さらに別の例示するリソース通信は、解放の通信である。例えば、以前に割り当てられたリソースがそれ以上必要でない場合に、ｆｒｅｅＲｅｓｏｕｒｃｅ動作がＡＦによって用いられる。ｆｒｅｅＲｅｓｏｕｒｃｅ動作には、「ｆｒｅｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」と呼ばれる入力構造だけが含まれる。「ｆｒｅｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造には、解放されることが必要なリソースのリソース識別子「ｒｅｓＩｄ」だけが含まれる。
【００５０】
例示するマルチキャストのリソース交渉メッセージング
別の例示する実施形態によって、マルチキャストを介して例えばＰａｙＰｅｒＶｉｅｗのようなアプリケーションをエンドユーザに配信するために用いられるメッセージおよび動作について、ＳＭ４０６とＲＭ４０４との間の通信に関連して以下に述べる。先述したユニキャストの実施形態と同様、これらの動作にも、例えば、リソース割り当て動作とリソース修正動作とリソース解放動作とが含まれる。
【００５１】
リソース割り当て動作は、新たなリソースが必要な場合に、上記のメッセージ４１２のコンテクストにおいて、ＳＭ４０６によって用いられる。このメッセージの中でＳＭ４０６は、ソース（エンドユーザデバイス）インターネットプロトコル（ＩＰ）アドレスと宛先（ＡＦ）ＩＰアドレスの間にリソースを割り当てるようにＲＭ４０４に要求する。この純粋に例示的な例におけるリソース割り当て動作には、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」と呼ばれる入力構造と、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」と呼ばれる出力構造とが含まれる。
【００５２】
この例示的実施形態によると、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージは、エンドユーザがアクセスを望むアプリケーションに関する情報をＳＭ４０６からＲＭ４０４へ伝達するのに用いられる。この例では、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造には、「ｒｅｓＩｄ」パラメータと「ｓｌｓ」パラメータとが含まれる。加えて、リソースが割り当てられた場合には、グローバル的に一意であるリソース識別子によってそれらを参照することができる。「ｒｅｓＩｄ」パラメータは、このリソース識別子を表す任意のパラメータ文字列である。「ｒｅｓＩｄ」が存在している場合、このリクエストに関連するリソースは、「ｒｅｓＩｄ」で指定される値によって識別されるであろう。それが存在していない場合、ＲＭ４０４は、一意のリソース識別子を生成して、それを応答のかたちでＳＭ４０６に返信するであろう。「ｓｌｓ」パラメータについては、この例で実際に必要なリソースのパラメータを説明する、ＸＭＬで符号化された文字列として、以下に記述する。
【００５３】
＜xml encoding=“UTF-8”?＞
＜!ELEMENT sls(FullResponse?,SourceAddr,DestinationAddr,MulticastSelections)＞
＜!--The＜FullResponse＞value should be 0 or 1--＞
＜!ELEMENT FullResponse(#PCDATA)＞
＜!ELEMENT Address-Realm＞
＜ATTLIST Address-Realm vno NMTOKEN #REQUIRED＞
＜!ELEMENT MulticastSelections(Multicast-Group+)＞
＜ATTLIST MulticastSelections uip NMTOKEN #REQUIRED＞
＜!ELEMENT Multicast-Group＞
＜!ATTLIST Multicast-Group
addr NMTOKEN #REQUIRED
server NMTOKEN #REQUIRED
nsc NMTOKEN #REQUIRED
downstream NMTOKEN #REQUIRED＞
【００５４】
上記の「ＦｕｌｌＲｅｓｐｏｎｓｅ」フィールドは、応答の中ではＳＭ４０６がリソースの見出しだけではなくて選択されたリソースの記述全体を必要とすることを、ＲＭ４０４に示す。「ｖｎｏ」パラメータは、ＳＬＳの中で指定されたＩＰアドレスが属する領域を指定する。「ｕｉｐ」パラメータは、交渉が行われる対象であるユーザデバイスのＩＰアドレスを指定する。「ａｄｄｒ」パラメータは、マルチキャストグループのためのＩＰアドレスを指定する。「ｓｅｒｖｅｒ」パラメータは、マルチキャストストリームのソースを示す。「ｎｓｃ」パラメータは、ＲＭ４０４構成データに相関されていることが望ましい。ＲＭ４０４の中で、１つの「ｎｓｃ」値が特定の優先度および特定のＱｏＳに変換される。「ｄｏｗｎｓｔｒｅａｍ」パラメータは、そのマルチキャストストリームに必要な帯域幅を、例えばキロビット／秒でリストされうる値で指定する。この例では、ＲＭ４０４は、リクエストの中に出現する順に、または順位リストの中に出現する順に、各＜Ｍｕｌｔｉｃａｓｔ−Ｇｒｏｕｐ＞のエントリを試行するであろう。最初に成功した＜Ｍｕｌｔｉｃａｓｔ−Ｇｒｏｕｐ＞に関連するリソースが予約されて、応答の中でＳＭ４０６へ返信されるであろう。
【００５５】
「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージに応じて、ＲＭ４０４は、「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」メッセージを送信してもよい。この例示的な実施形態による「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｓｐｏｎｓｅ」構造には、「ｄｏｎｅ」パラメータ、「ｒｅｓＩｄ」パラメータ、そして「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータが含まれる。「ｄｏｎｅ」パラメータは、リソース割り当て動作のステータスを提供する。「−１」の値はエラーを表し、「０」の値はリソースが現在利用できないことを表し、「１」の値は、リソースがこのリクエストに割り当てられたことを表す。「ｒｅｓＩｄ」パラメータは、割り当てられたリソースに関連するリソース識別子を提供する。これは典型的には「ｄｏｎｅ」パラメータが「１」の値と共に返信された場合に提供される。また、その後、この「ｒｅｓＩｄ」パラメータを、リソースを更新するか解放するために用いることもできる。「ｓｌｓＲｅｓｐｏｎｓｅ」パラメータは、＜ＦｕｌｌＲｅｓｐｏｎｓｅ＞のタグが「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」構造の「ｓｌｓ」文字列の中に存在して、その値が「１」である場合に割り当てられた実際のリソースを表す、ＸＭＬで符号化された文字列である。この例による「ｓｌｓＲｅｓｐｏｎｓｅ」の文字列の形式は、下記のＤＴＤによって管理される。
【００５６】
＜?xml encoding=“UTF-8”?＞
＜!ELEMENT sls MulticastSelections＞
＜!ELEMENT MulticastSelections(Multicast-Group)＞
＜!ELEMENT Multicast-Group＞
＜!ATTLIST Multicast-Group
addr NMTOKEN #REQUIRED
server NMTOKEN #REQUIRED
nsc NMTOKEN #REQUIRED
downstream NMTOKEN #REQUIRED＞
【００５７】
フィールドの定義は、（マルチキャスト用の）「ａｌｌｏｃａｔｅＲｅｓｏｕｒｃｅＲｅｑｕｅｓｔ」メッセージの場合と同じであってもよい。また、典型的には、この応答の中では１つのマルチキャストグループだけが用いられうる。
【００５８】
サービスレベル仕様（ＳＬＳ）
上記の例示するメッセージは、リソース交渉のシグナリングの量を削減した状態でアプリケーションまたはサービスをできるだけ「ベスト」な形式でエンドユーザに配信するために、ＳＭ４０６とＲＭ４０４の間で用いられる。このできるだけ「ベスト」な形式は、特に、ＳＭ４０６からの指示と、ＲＭ４０４によって判定されるリソースの利用可能性とに基づく。次に、ＳＭ４０６からのこれらの指示は、特に、ＳＬＳへと変換されたサービスレベル契約（ＳＬＡ）の内容に基づく。このプロセスについて上記の各セクションの中で簡単に記述してきたが、以下でより詳細に記述しよう。
【００５９】
例示する実施形態によると、ＳＬＡは通常、プロバイダ間のネットワークの接続性を規制するために用いられるが、それらは小売の交渉に一定の形を与えるのに用いられてもよい。ＳＬＡは、加入と同時に署名され、通常、リクエストされたサービスについて特別に考えられたテンプレートから作成される。サービスについてのエンドユーザの期待が、ＳＬＡの中に明記されている。これらの期待に応えるため、サービスプロバイダは、契約を考慮に入れて、リクエストされたサービスのためのリソースを提供することを計画する。しかし、リソースをどのように管理するかを決定して自社独自のＱｏＳポリシーを適用することを目的として、典型的にはサービスプロバイダが、エンドユーザのＱｏＳリクエストを受け入れるための最終決定を行う。エンド・ツー・エンドの観点からサービスを提供して配信するには、関係する領域の各々において、すなわちアクセス領域およびサービスプロバイダ領域において、適切なメカニズムがしかるべく機能することが必要である。達成されるべきサービス動作のタイプに応じて、ＳＬＡに基づいてこれらの領域において１つ以上のＱｏＳ特性が、実装される必要がある。
【００６０】
ＳＬＡが、必要なサービスの高レベルの記述を表すのに対して、ＳＬＳは、必要なネットワークリソースの提供および予約に用いられる技術パラメータのリストを含む、より形式的な技術文書である。さらに、ＳＬＡの加入が、比較的静的なプロセスと考えることができるのに対して、ＳＬＳは、ネットワーク条件の変動に起因することが多い、より動的なプロセスに関わる。例えば、同じサービスに関連する２つの異なる加入があった場合、現行のネットワークリソースのステータスによっては、異なるＳＬＳインスタンスが導出されうる。ＳＬＳインスタンスは、上記のリソース予約および入場制御プロセスを通して作成され、それによって、サービスがリクエストされた時点でサービスに対するリソースを動的に割り当てることや、サービスが停止された時点でこれらのリソースを解放することが可能になる。この手法があれば、保証されたトラヒックの提供についての不満が回避され、展開済みの基底に存在するネットワークリソースが効率的に使用される。
【００６１】
加えて、これらのＳＬＳのリクエストおよび交換は、典型的には、プロバイダ間ですでに確立済みの双務契約のコンテクストの中で行われる。これらの双務契約の連結は、エンド・ツー・エンドのＱｏＳ対応サービスの適切な配信に役立つ。交渉の目的でＲＭ４０４に配信されるＳＬＳの数は、ソースから宛先までのパス沿いの領域の数には関係ない。実際、ＳＬＡから１つ以上のＳＬＳへの変換を担当するＳＭ４０６は、例えばルーティングやトポロジのようなネットワークの詳細についてはまったく無知である。
【００６２】
例示する実施形態によると、ＳＬＳの中に含まれうる一部の特徴には、（１）サービスフローのためのトラヒックパラメータ、すなわちＣｏｍｍｉｔｔｅｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｒａｔｅ（ＣＩＲ）、Ｐｅａｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｒａｔｅ（ＰＩＲ）、パケット長など、（２）プロファイル内トラヒックのためのＱｏＳ属性（スループット、損失率、最大遅延、ジッタなど）、（３）プロファイル外トラヒックのためのＱｏＳ属性、（４）サービス継続期間（常時、オンデマンド、または、事前にスケジュールを組む）、（５）サービスフローおよびそれらの割り当てられたＮＳＣ、（６）費用、（７）出力デバイス、（８）ペアレンタル・コントロール、（９）ストレージ選択肢、そして、（１０）多様なサービスフローに関連するポリシー、が含まれるが、それらに限定されない。これらの特徴はさらに、ＳＭ４０６が理解して必要に応じて使用しうる形式へと符号化される。加えて、ＳＬＳのこれらの特徴は、サービスのためのリソースを要求するため、ＳＭ４０６からＲＭ４０４へのメッセージの中に（明示的かまたは暗示的かいずれかで）組み込まれてもよいし、あるいは、エンドユーザに配信されることになるアプリケーションのためのリソースをＳＭが要求する場合に検索されるようにＲＭ４０４の中に記憶されてもよい。
【００６３】
前記から、例示する実施形態には、通信システムにおいてリソースを交渉するための方法が含まれることが明らかであろうが、それらの例を図７（ａ）乃至７（ｄ）のフローチャートに示す。その中で、図７（ａ）に示すＳＭ４０６の観点から、リソースを交渉するための方法には、サービスを求めるリクエストをＳＭが送信するステップが含まれており、この場合、サービスリクエストは、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及する（７０２）。さらに、図７（ｂ）に示す明示的なサービス選択肢がメッセージに含まれる場合、交渉方法は、ステップ７１２によって示すように、「リクエストは、複数のサービス選択肢のリストを含むメッセージであり、リスト内の各エントリには、複数のパラメータが含まれる」と規定する。ステップ７１４において、リクエストはリソースマネージャによって受信される。次いで、ステップ７１６において、サービスを提供するのに用いられうる、複数のサービス選択肢のうち最高の順位の選択肢を判定するために、リストが評価される。ステップ７１８において、サ−ビスを求めるリクエストへの応答が送信されて、サービスを提供するために複数のサービス選択肢のうちでどれがリソースマネージャによってサービス選択肢順位リストの評価に基づいて選択されたかを示す（７１８）。
【００６４】
図７（ｃ）に示すように、ＲＭ４０４の観点から、リソースを交渉するための方法には、サービスを求めるリクエストを受信するステップが含まれており、この場合、サービスリクエストは、前記サービスを提供するための複数のサービス選択肢のリストを明示的に提供するかまたは暗示的にそれに言及する（７２２）。
【００６５】
上記の例示的な実施形態は、本発明を限定するというより、あらゆる点で例証であることを意図している。従って、本発明は、本書に含まれる記述から当業者によって導出されることができる、詳細な実装における多くの変形形態がありうる。そのような変形形態および修正形態はすべて、下記の請求項によって定義される本発明の適用範囲および精神の範囲内にあると考えられる。本願の記述の中で用いられている要素、動作または指示は、そのように明示的に記述されていない限り、本発明に不可欠または必須であると考えられるべきではない。また、本書では、冠詞「ａ」は、１つ以上の項目を含むことが意図されている。
【図１】
2010522453.tif 000003
【図２】
2010522453.tif 000004
【図３】
2010522453.tif 000005
【図４】
2010522453.tif 000006
【図５】
2010522453.tif 000007
【図６】
2010522453.tif 000008
【図７（ａ）】
2010522453.tif 000009
【図７（ｂ）】
2010522453.tif 000010
【図７（ｃ）】
2010522453.tif 000011
【手続補正書】
【提出日】平成21年1月21日(2009.1.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信システムにおいてリソースを交渉する方法であって、
サービスマネージャが、サービス要求を送信するステップを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及し、
前記複数のサービス選択肢の各々は、サービスレベルを規定するパラメータセットを含み、
前記複数のサービス選択肢は、複数のサービスレベルにおける選択を提供する
ことを特徴とする方法。
【請求項２】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージである
ことを更に特徴とする請求項１に記載の方法。
【請求項３】
前記パラメータセットの各々は、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザデバイスのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項１に記載の方法。
【請求項５】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項４に記載の方法。
【請求項６】
リソースマネージャが、前記リストを含む前記サービス要求を受信するステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項２に記載の方法。
【請求項７】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項６に記載の方法。
【請求項９】
リソースマネージャが前記要求を受信するステップと、
前記複数のサービス選択肢の前記リストを、前記リソースマネージャに関連するメモリデバイスから取り出すステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項４に記載の方法。
【請求項１０】
前記サービスマネージャは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項１に記載の方法。
【請求項１１】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項１に記載の方法。
【請求項１２】
通信システムにおいてリソースを交渉する方法であって、
リソースマネージャがサービス要求を受信するステップを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及し、
前記複数のサービス選択肢の各々は、サービスレベルを規定するパラメータセットを含み、
前記複数のサービス選択肢は、複数のサービスレベルにおける選択を提供する
ことを特徴とする方法。
【請求項１３】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージである
ことを更に特徴とする請求項１２に記載の方法。
【請求項１４】
前記パラメータセットの各々は、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザデバイスのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項１２に記載の方法。
【請求項１６】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項１３に記載の方法。
【請求項１８】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項１７に記載の方法。
【請求項２０】
前記複数のサービス選択肢の前記リストを、前記リソースマネージャに関連するメモリデバイスから取り出すステップと、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価するステップと、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記リソースマネージャが選択したかを示す、前記サービス要求に対する応答を送信するステップと、
を更に備えることを特徴とする請求項１５に記載の方法。
【請求項２１】
前記リソースマネージャは、サービスマネージャから受信した予約要求に基づいて、ドメイン内のネットワークリソースを予約し、割り当て、そして監視する機能を提供するサーバであることを特徴とする請求項１２に記載の方法。
【請求項２２】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項１２に記載の方法。
【請求項２３】
通信システムにおいてリソースを交渉する通信ノードであって、
サービス要求を送信するプロセッサを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及し、
前記複数のサービス選択肢の各々は、サービスレベルを規定するパラメータセットを含み、
前記複数のサービス選択肢は、複数のサービスレベルにおける選択を提供する
ことを特徴とする通信ノード。
【請求項２４】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージである
ことを更に特徴とする請求項２３に記載の通信ノード。
【請求項２５】
前記パラメータセットの各々は、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項２３に記載の通信ノード。
【請求項２６】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項２３に記載の通信ノード。
【請求項２７】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項２６に記載の通信ノード。
【請求項２８】
前記通信ノードは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項２３に記載の通信ノード。
【請求項２９】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項２３に記載の通信ノード。
【請求項３０】
通信システムにおいてリソースを交渉する通信ノードであって、
サービス要求を受信するプロセッサを備え、
前記サービス要求は、サービスを提供するための複数のサービス選択肢のリストを明示的に提供するか、または、当該リストに暗示的に言及し、
前記複数のサービス選択肢の各々は、サービスレベルを規定するパラメータセットを含み、
前記複数のサービス選択肢は、複数のサービスレベルにおける選択を提供する
ことを特徴とする通信ノード。
【請求項３１】
前記サービス要求は、前記複数のサービス選択肢の前記リストを明示的に提供し、
前記サービス要求は、前記複数のサービス選択肢の前記リストを含むメッセージである
ことを更に特徴とする請求項３０に記載の通信ノード。
【請求項３２】
前記パラメータセットの各々は、前記サービスを提供するために使用される帯域幅と、前記サービスを提供するために使用されるコーデックと、前記サービスを提供するために使用される形式と、のうちの少なくとも１つを含むことを特徴とする請求項３０に記載の通信ノード。
【請求項３３】
前記サービス要求は、複数のサービス選択肢の前記リストに暗示的に言及し、
前記サービス要求は、エンドユーザのアドレスと、前記サービスに関連づけられた識別子と、を含むメッセージである
ことを更に特徴とする請求項３０に記載の通信ノード。
【請求項３４】
前記サービス要求は、要求される帯域幅と、要求されるコーデックと、要求される形式と、のうちの少なくとも１つに関連するパラメータを含まないことを特徴とする請求項３３に記載の通信ノード。
【請求項３５】
前記プロセッサは、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価し、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記第１のノードが選択したかを示す、前記サービス要求に対する応答を送信する
ことを特徴とする請求項３１に記載の通信ノード。
【請求項３６】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に関連する順位情報を含むことを特徴とする請求項３５に記載の通信ノード。
【請求項３７】
前記複数のサービス選択肢の前記リストは、前記サービスを受信するためのエンドユーザの選好に基づいて順位付けされていることを特徴とする請求項３５に記載の通信ノード。
【請求項３８】
前記複数のサービス選択肢の前記リストをそこから取り出せる、前記リソースマネージャに関連するメモリデバイスを更に備え、
前記プロセッサは、
前記サービスを提供するために使用可能である、前記複数のサービス選択肢のうちの最高の順位の選択肢を判定するために、前記リストを評価し、
前記サービスを提供するために前記複数のサービス選択肢のうちのどれを前記第１のノードが選択したかを示す、前記サービス要求に対する応答を送信する
ことを特徴とする請求項３３に記載の通信ノード。
【請求項３９】
前記第１のノードは、サービス品質（ＱｏＳ）対応サービスを公開し、発見し、加入し、呼び出し、そして配信する機能を提供するサーバであることを特徴とする請求項３０に記載の通信ノード。
【請求項４０】
前記サービスはアプリケーション機能からエンドユーザへ提供される映画であることを特徴とする請求項３０に記載の通信ノード。
【国際調査報告】
2010522453.tif 000012
2010522453.tif 000013
2010522453.tif 000014