JP5113254B2 - マルチメディア通信ネットワークにおけるリソース制限の通知 - Google Patents

Description

本発明は、通信セッションに関連するリソース制限を通信ネットワークにおいてアプリケーション機能に通知する方法に関する。

ＩＰマルチメディアサブシステム（ＩＭＳ）は、移動通信ネットワークを介してＩＰマルチメディアサービスを提供するために第３世代パートナプロジェクト（３ＧＰＰ）によって定義されている技術である。ＩＰマルチメディアサービスとは、音声、ビデオ、メッセージング、データなどの動的な組み合わせを同一セッションの内部で提供するサービスである。基本アプリケーションの数、及び、組み合わせ可能なメディアの数が増加するにつれて、エンドユーザに対して提供されるサービスの数も増加し、個人の贅沢なマルチメディア通信サービスの新たな世代を生み出している。

ＩＭＳは、ユーザ端末（或いはユーザ端末とアプリケーションサーバ）間の呼又はセッションを確立して、制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。セッションのメディアコンポーネントの記述及びネゴシエーションを行うために、ＳＩＰシグナリングにより搬送されるセッション記述プロトコル（ＳＤＰ）が使用される。ＳＩＰがユーザ対ユーザのプロトコルとして創り出されたものであるのに対して、ＩＭＳでは、通信事業者とサービスプロバイダとが、ユーザによるサービスへのアクセスを制御し、それに応じてユーザに料金を請求することができる。

図１はＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳがどのように移動体ネットワークのアーキテクチャに適合するかを概略的に示す図である。図１に示されているように、３つの層（又はプレーン）において通信の制御が行われる。最下位層はベアラプレーンとも呼ばれる接続層１であり、この接続層１を経由して信号がネットワークにアクセスするユーザ端末へ向けて／から送られる。ＧＰＲＳネットワークは種々のＧＰＲＳサポートノード（ＧＳＮ）を含む。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）２はＧＰＲＳ基幹ネットワークと他のネットワーク（無線ネットワーク及びＩＭＳネットワーク）との間でインタフェースとして機能する。

ＩＭＳ３はコアネットワーク３ａを含み、このコアネットワーク３ａは中間にある制御層４と接続層１、並びにサービスネットワーク３ｂを介して動作する。ＩＭＳコアネットワーク３ａは、接続層１においてＧＧＳＮ２ａを介してＧＰＲＳネットワークへ／から信号を送信／受信するノードと、中間にある制御層においてＩＭＳ内のＳＩＰプロキシとして機能する呼／セッション制御機能（ＣＳＣＦ）５を含むネットワークノードとを含む。３ＧＰＰアーキテクチャは３種類のＣＳＣＦを定義する。即ち、ＳＩＰ端末にとってＩＭＳ内部の最初のコンタクトポイントであるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）と、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）と、正しいＳ−ＣＳＣＦを特定し、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信した要求を当該Ｓ−ＣＳＣＦへ転送する役割を担うインターロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）とを定義する。

最上部にＩＭＳサービスネットワーク３ｂを含むアプリケーション層６がある。ＩＭＳサービス機能を実現するためにアプリケーションサーバ（ＡＳ）７が設けられる。アプリケーションサーバ７はエンドユーザにサービスを提供し、エンドポイントとして接続されてもよいし、Ｓ−ＣＳＣＦによって「結合」されてもよい。或る種のアプリケーションサーバ７は、被呼側の加入者であれ、発呼側の加入者であれ、いずれかの加入者ＩＤに応じてアクションを実行する（いずれのＩＤもアプリケーションサーバ７を制御するネットワークによって「所有」されている）。

ＩＭＳアーキテクチャによって、２以上のユーザがＳＩＰセッション中にデータを交換するピアツーピア・アプリケーションの利用が可能となる。このようなピアツーピア・アプリケーションの例には、マルチメディア電話（ＭＭＴｅＩ）、セルラを介するプッシュ・ツー・トーク（ＰＯＣ）、ストリーミング、リアルタイムのビデオ共有、ファイル共有、ゲームなどが含まれる。２つのエンドポイント（ユーザ端末）間でのＳＩＰ／ＳＤＰプロトコル交換によって、少なくとも一つのトランスポート接続のネゴシエーションが動的に行われる。

しかし、このようなピアツーピア・アプリケーションをサポートするためには、２つの基本要件が存在する。即ち、（ｉ）加入者の少なくとも一つのＩＭＳセッションに関連づけられたＳＩＰ信号フローを選択的に制御するメカニズムと、（ｉｉ）サービスの利用に対して効果的な課金を行うために、動的にネゴシエーションがなされるトランスポート接続を介してＩＰフローを制御する機能とである。１つの重要な側面はセッションに必要なリソースに関わり、この側面は、（エンドユーザ間でデータが転送されるデータレートなどの）セッションに対して提供されるサービス品質（ＱｏＳ）に影響を与えるものとなる。以下の説明では、ＱｏＳという用語は、要求されたセッション又は継続中のセッションのパラメータであって、エンドユーザが経験するセッションサービスの品質を決定するパラメータを意味する。ＱｏＳに影響を与える主要なベアラリソース特性としてセッションのために利用可能な帯域幅がある。

３ＧＰＰは上記のような必要性を認識した。そのため、３ＧＰＰは現在ポリシーおよび課金制御（ＰＣＣ）アーキテクチャを定義しているところである（非特許文献１を参照のこと）。図２はＰＣＣアーキテクチャの基本アウトラインを示す図である。アプリケーション機能（ＡＦ）１６は、動的ポリシーとトラフィックプレーンリソース（traffic plane resources）の課金制御との少なくともいずれかを必要とするアプリケーションを提供するエレメントである。アプリケーションサービスが開始され、かつ、（アプリケーションサーバ７（図１を参照のこと）などによって）アプリケーション層６においてサービス特性のネゴシエーションが行われるとはいえ、ＩＭＳの場合、Ｐ−ＣＳＣＦがＳＩＰシグナリングプレーン（制御層４）においてＡＦ１６の役割を果たすことになる。接続層１におけるポリシーおよび課金強制機能（ＰＣＥＦ）１２はサービスデータフローをモニタし、ユーザプレーントラフィックにおけるネットワークポリシーを強制する。ＰＣＥＦ１２は、モニタされるデータフローと課金ポリシーとに基づいて課金を適用する。この情報はＧｙインタフェースを介してオンライン課金システム１３へ提供される。ＧＰＲＳアクセスネットワークの内部では、ＰＣＥＦ１２はＧＧＳＮ２ａに配置される。３ＧＰＰリリース８に規定されているシステムアーキテクチャエボリューションの内部では、ＰＣＥＦはＰＤＮゲートウェイに配置されている。

ポリシーおよび課金ルール機能（ＰＣＲＦ）１４はＡＦ１６とＰＣＥＦ１２との間に存在する。ＰＣＲＦ１４はモニタされるデータフローに基づいて課金を制御するエンティティである。ＰＣＲＦ１４は、加入者情報のデータベースを含む加入プロファイル・レポジトリ（ＳＰＲ）１８からＳｐインタフェースを介して特定の加入者に対して適用される課金ポリシーに関連する規則を取得する。ＰＣＲＦ１４はＧｘインタフェースを介してＰＣＥＦ１２においてこれらのＰＣＣ規則をインストールする。これらのＰＣＣ規則は、要求されたサービスに関連づけられた許可されたメディアフローのみを許すことが保証される。さらに、ＰＣＥＦ１２でインストールされたＰＣＣ規則によって、正しい帯域、課金処理、及び優先順位が正しいベアラを介して適用されていることが保証される。

ひとたび、セッション特性が通信ピア間でネゴシエーションがなされ、このセッション特性がＩＭＳコアネットワーク３ａの内部で許可されると、ＡＦ１６はＲｘインタフェースを介してベアラリソースの許可をＰＣＲＦ１４へ与え、それによって対応するリソース予約を接続層１において許可できるようにする。

ＧＰＰ ＴＳ２３．２０３［Ｉ］ ３ＧＰＰ ＴＳ２９．２１４［２］

しかし、対応するリソース予約をベアラ層において許可できない環境が生じる場合もある。このような状況が生じる１つの理由として、例えば、アクセス事業者がそのユーザに対して、あるいは当該特定ユーザに対して帯域消費量の制限を設定している場合が考えられる。このような環境下において、非特許文献２の最新の仕様は以下のように言明している：
「ＰＣＲＦは、通信事業者のポリシーに従って受信したサービス情報を処理すべきであり、要求が受け付けられたものであるかどうかを決定することができる。」
しかし、上記要求が受け付けられなかった場合、ＰＣＲＦ１４が何を行うかは仕様には指定されていない。明示的に定義されたメカニズムが存在しない場合、通信事業者の基本設定に従ってＰＣＲＦ１４は構成されなければならないと仮定することができる。この構成は、要求が受け付けられなかった理由に関するＡＦ１６へのフィードバック情報を含んでもよいし、含まなくてもよい。現在ＰＣＲＦ１４は、ＡＦ１６がこのような情報を必要とするかどうかについては認知していないため、故に、（どのような構成であるにせよ）ＡＦの基本設定にかかわりなくその処理を実行するかどうかについては認知していない。

例えば、帯域制限に起因して拒絶された要求済みのピアツーピア・セッションサービスが、少なくともある種のメディアタイプの場合、低い帯域で提供される可能性があり、それによって、セッションが低いＱｏＳで続行することが許可される場合もあり得る。拒絶されたセッション要求に影響を与える帯域制限に関する情報が利用できるようになれば、この情報を用いて修正されたセッション要求を開始することが可能となる。この修正された要求はＡＦそれ自身から開始することも可能であるが、これらの制限がＡＦ１６によって知らされるか、あるいは、直接接続層１から知らされるかのいずれかで知らされた後、上記要求は通常ＵＥによって開始されることになる。したがって、セッション要求を修正したり、セッションに対する許容帯域をＵＥに知らせたりするために、帯域制限指示がＡＦ１６に関連するものであるかどうかを知っているのはＡＦ１６のみである。

さらに、帯域制限の指示がＡＦ１６に関連するものであるときでさえ、ＡＦ１６がどの特定のフォーマットで情報を必要とするかを知っているのはＡＦ１６のみである。ＰＣＲＦ１４が或る一定の方法で構成されていると、ＡＦ１６によって用いられるこれらの情報に対し、ＰＣＲＦ１４が要求された情報をフィードバックしなかったり、正しくないフォーマットで要求された情報をフィードバックしたりすることとなる。例えば、ＰＣＲＦ１４は、利用可能な帯域幅を計算するように構成されたものであってもよく、ＡＦ１６がメディアコンポーネント毎に利用可能な帯域幅を実際に必要とする際に、（例えばセッションのために利用可能な総帯域幅の）１つの特定のフォーマットでこの情報をＡＦ１６へ提供することも可能である。

本発明は上述の内容を念頭に置いて着想されたものである。

本発明の第１の態様によれば、通信ネットワークにおいて、通信セッションに関連するリソース制限をアプリケーション機能（ＡＦ）に通知する方法が提供される。このネットワークには、セッション時にデータフローの認証と制御とを行うポリシーおよび課金ルール機能（ＰＣＲＦ）が含まれている。ＡＦは通信セッションを確立するために認証要求をＰＣＲＦへ送信する。この認証要求には、セッション時のデータフローに対するリソース制限をＡＦに通知する旨の指示が含まれている。ＰＣＲＦはリソース制限をＡＦに通知する。

ＡＦは、利用可能な帯域幅情報をＰＣＲＦから受信したいという所望を示すことができるという利点を有する。次いで、セッション要求を修正するためにこの情報を利用することができる。

通信セッションはマルチメディアセッションであってもよく、ＰＣＲＦは、このマルチメディアセッション時に複数のメディアコンポーネントのそれぞれに対してデータフローを認証し、制御する。ＡＦは、ＩＭＳネットワーク内のプロキシ呼／セッション制御機能の中に含まれてもよい。

本発明の実施形態では、ＰＣＲＦは、要求されたセッションが続行することが許されるか否かを示す認証応答メッセージの形でリソース制限をＡＦに通知する。認証要求の形のこの指示の中には、要求された帯域が帯域制限を越えているという理由で要求されたセッションが続行することが許されなかった場合、ＡＦに対して帯域制限情報が通知されるように求める要求が含まれていてもよい。上記指示は複数のレベルのうちの１つのレベルを特定することが可能であり、このレベルでＡＦに対して帯域制限が通知されることになる。上記複数のレベルの中には総セッション帯域レベルと、メディアコンポーネント毎のレベルとが含まれる。

リソース制限を通知するためにＡＦの基本設定が知らされ、この基本設定をＡＦの動作時に考慮して、正しいフォーマットで所望の情報をＡＦへ提供できるようにすることが可能となるという利点がＰＣＲＦにはある。

本発明の諸実施形態では、本方法は、リソース制限に対する何らかの違反であって、進行中のセッション中に当てはまる違反をＡＦに通知するステップをさらに有する。ＰＣＲＦは、リソース制限の修正通知を含む再認証要求メッセージをＡＦへ送信することができる。再認証要求の受信時に、ＡＦは通知された制限でセッションが進行できるか否かを決定することができ、そして、進行できなければ、ＡＦはセッションの終了を要求することができる。この要求は、ＡＦがセッション終了要求をＰＣＲＦへ送信するステップを含んでもよい。

セッションの終了又は継続に関する決定をＰＣＲＦにさせるのではなく、ＡＦにさせることができるということは利点である。

本発明の実施形態では、リソース制限をＡＦに通知する旨の指示は、特定アクション属性値ペア（ＡＶＰ）（Specific-Action Attribute Value Pair, AVP）を認証要求メッセージの中に含む。この認証要求メッセージの中には、リソース制限をＡＦに通知する形式を示す利用可能な帯域情報ＡＶＰがさらに含まれてもよい。リソース制限通知には、利用可能な帯域情報ＡＶＰの形で示される形式に従ってＡＦセッションのために利用可能になるリソース情報を提供するサポート・サービス情報ＡＶＰを含むことができる。

本発明の第２の側面によれば、ネットワークを介して通信を行うユーザ端末間でアプリケーションセッションを提供するアプリケーション機能（ＡＦ）が通信ネットワークにおいて提供される。ＡＦは、ネットワークにおいてセッション認証要求をポリシーおよび課金ルール機能（ＰＣＲＦ）へ送信する手段を備える。このセッション認証要求には、セッション時のデータフローに対するリソース制限がＡＦに通知される旨の指示が含まれている。ＡＦはリソース制限の通知を受信する手段も備える。

アプリケーション機能は、マルチメディアアプリケーションセッションを提供するように構成されてもよい。アプリケーション機能は、ＩＭＳネットワーク内にプロキシ呼／セッション制御機能を備えることができる。

アプリケーション機能の実施形態では、セッション認証要求時の指示が複数のレベルのうちの１つのレベルを特定し、このレベルで帯域制限はＡＦに通知される。上記複数のレベルには総セッション帯域レベルと、メディアコンポーネント毎のレベルとを含む。

アプリケーション機能の実施形態では、リソース制限通知は認証応答メッセージの中に含まれ、この認証応答メッセージは、要求されたセッションが所望のリソースを要求通りに受信するかどうかを示す。

アプリケーション機能は、セッションに参加する１以上のユーザ端末に対して通知されたリソース制限に関する情報を通知するように構成されてもよい。

前記リソース制限を満たすために、上記アプリケーション機能の実施形態はセッション認証要求を修正するように構成されてもよい。アプリケーション機能は、修正されたセッション認証要求をユーザ端末のうちの少なくとも１つに知らせるように構成されてもよい。このアプリケーション機能は、セッション認証要求をＰＣＲＦへ送信するように構成されてもよい。

本発明の第３の側面によれば、ネットワークを介して通信を行うユーザ端末間でのセッションのためにデータフローを認証し、制御するように構成されたポリシーおよび課金ルール機能（ＰＣＲＦ）が通信ネットワークにおいて提供される。ＰＣＲＦは、ネットワークにおいて、セッション認証要求をアプリケーション機能から受信する手段を備える。このセッション認証要求には、セッション時のデータフローに対するリソース制限がアプリケーション機能に通知される旨の指示が含まれている。ＰＣＲＦはリソース制限通知をアプリケーション機能へ送信する手段も備える。

ＰＣＲＦは、マルチメディアセッション時に複数のメディアコンポーネントのそれぞれに対してデータフローを認証し、制御するように構成される。

ＰＣＲＦの諸実施形態において、アプリケーション機能からの認証要求は複数のレベルのうちの１つのレベルを特定する指示を含み、リソース制限はこのレベルでアプリケーション機能に通知される。上記複数のレベルは、総セッション帯域レベルと、メディアコンポーネント毎のレベルとを含むと共に、帯域制限通知を送信する手段は、上記特定レベルで通知を送信する手段を含む。

ＰＣＲＦは、リソース制限をアプリケーション機能に通知するレベルを特定する前記指示をメモリに保存するように構成される。

ＰＣＲＦは、前記保存された指示に基づいて、進行中のセッション中に行われるリソース制限に対するその後の違反を前記アプリケーション機能に通知するように構成されてもよい。

以下、図面を参照しながら本発明の実施形態について説明する。

ＩＭＳが移動ネットワークアーキテクチャの中へどのように適合するかを示すＧＰＲＳ／ＰＳアクセスネットワークの概略図である。 ポリシーおよび課金制御（ＰＣＣ）システムを示すネットワークエンティティアーキテクチャの概略図である。 本発明の実施形態に基づくＵＥとＰＣＣエンティティ間での信号フローを例示する図である。

図３は、ＩＭＳに登録し、かつ、他のＵＥ（不図示）とのピアツーピア・マルチメディアアプリケーションセッションを開始したユーザ端末（ＵＥ）１０のためのＰＣＣノード間での信号フローを示す図である。リソースの動的ポリシーと課金制御の少なくともいずれかを要求するアプリケーションがＡＦ１６によって提供される。セッション開始要求がＩＭＳコアネットワークによってＵＥ１０から最初に受信されると、この要求はＡＦ１６へ転送される。次いで、図３のステップ３０１において、ＡＦ１６はＲｘインタフェースを介して認証要求（ＡＡＲ）をＰＣＲＦ１４へ送信する（図２を参照のこと）。ＰＣＣの設定された機能に従って、上記認証要求はセッションのための所望のＱｏＳリソースを指定する。ステップ３０２において、ネットワークにより課されている制限を考慮して、ＰＣＲＦ１４はチェックを行い、要求されたＱｏＳリソースの提供が可能かどうかを調べる。これらの制限はネットワークに広がったの制限であってもよいし、あるいは、特定の加入者に対して課されている制限であってもよい。ステップ３０３において、ＰＣＲＦ１４は認証要求応答（ＡＡＡ）をＡＦ１６へ返信する。要求されたＱｏＳリソースがいずれの制限も越えていなければ、ＡＡＡは単にセッションが進行することを許すことになる。

本発明は、接続層における制限に起因して、要求されたＱｏＳリソースを提供できない場合に何が起こるかに関するものである。本発明の基本的なコンセプトは、ＱｏＳリソースの認証がＰＣＲＦ１４によって拒絶された場合、制限の通知を明白に要求する手段をＡＦ１６に提供するステップを含む。ＱｏＳに影響を与える主要なベアラリソース特性はセッションのために利用可能な帯域幅であり、以下の説明は帯域制限に焦点を絞ったものとなる。しかし、或る種のメディア特性のようなＱｏＳに影響を与え得る他のリソースが存在する場合もある。本発明の原理がこのようなリソースに対しても適用され得ることは理解できよう。

図３に示す実施形態では、ＡＦ１６が帯域制限通知を要求する場合、ＡＦ１６は初期ＡＡＲの内部に在るＰＣＲＦ１４に対して明確な指示を与える。この指示には（総セッション帯域に対する、又は、メディアコンポーネント毎の帯域に対する）帯域制限通知に関するＡＦ基本設定も含まれる。したがって、ＡＡＲの形で提供されるサービス情報が拒絶された場合（例えば加入者の保証された帯域ＱｏＳを越えた場合など）には、初期ＡＡＲの形で表現されたＡＦ基本設定に従って要求されれば、ＰＣＲＦ１４は拒絶されたセッション要求に対して利用可能な帯域を与えることになる。

図３に示されているように、このメカニズムは、図３のステップ３０１においてＲｘインタフェースを介してＰＣＲＦ１４へ送信されるＡＡＲの内部に追加情報エレメントの導入を必要とする。この追加情報は、ＡＡＲコマンドの処理がこの理由に起因して失敗した場合、帯域制限の情報が通知されるための明確な要求（［NOTIFICATION_BANDWIDTH_RESTRICTION］（帯域制限通知）））を含むものである。この追加情報には、帯域制限がＡＦ１６へ提供されるべきフォーマットのための基本設定も含まれる。上記追加情報はＡＦセッション全体［TOTAL_BW］に対しても、あるいは、個々のメディアコンポーネント［BW_PER_MEDIA_COMP］に対しても適用され得るものである。以下、この追加情報についてさらに詳細に説明する。

上記追加情報は、ＰＣＲＦ１４により処理される場合、ＰＣＲＦ１４に帯域制限を決定させ、必要な場合に適宜ＡＦ１６に情報を通知するものである。図３のステップ３０３において、ＡＡＡ応答の中に上記情報を含めることによって上記通知は行われる。

さらなる改善が図３の下の部分に示されている。ここで、ＵＥ１０に関わる現在進行中のセッションが存在し、このセッションにおいてＰＣＥＦ１２はデータトラフィックをモニタしている。また、ＰＣＲＦ１４は、ステップ３０１において、初期ＡＡＲの形でＡＦ１６により示されるＡＦ基本設定を含む追加情報をＡＦセッションのライフタイムの間メモリの中に保存している。ステップ３１０において、（１人の特定ユーザに対してメディアＩＰフローを事前に処理するベアラの損失又は解除などの）ベアラプレーンでのイベントが生じる。このイベントは接続層からＧｘインタフェースを介してＰＣＲＦ１４に通知される。この通知は、ＡＦ１６から初期ＡＡＲの形で提供されるサービス情報に従う所望のＱｏＳリソースであって、当初受け入れられていたＱｏＳリソースがもはや保証されなくなっている可能性があることを意味するものである。この場合、ＰＣＲＦ１４が、ＡＦ１６によって示されるＡＦ基本設定をＡＦセッションのライフタイムの間初期ＡＡＲに保存していたため、さらに、本実施形態によると、ＡＦが更新情報を要求していた場合、ＡＦ基本設定に基づいて、ＰＣＲＦはＡＦセッションのために利用可能な帯域幅に対する任意の修正に関する更新情報をＡＦ１６に与えることができる。

この場合、ステップ３１１において、ＡＦ１６への、利用可能な帯域幅の通知は、ＰＣＲＦ１４からＡＦ１６へ送信される再認証要求（ＲＡＲ）の内部に含まれる。更新済みの利用可能な帯域幅は、保存済みのＡＦ基本設定（利用可能な総セッション帯域を指定するか、あるいは、メディアコンポーネント毎に利用可能な帯域幅を指定するかのいずれか）に従ってＲＡＲと共に送信される。ステップ３１２において、ＡＦ１６は、再認証応答（ＲＡＡ）をＰＣＲＦ１４へ送信することによって応答を行う。このＲＡＡは、上記制限に従うＱｏＳリソースに対する修正された要求を含んでもよく、それによってＡＦセッションが継続できるようにする（但し、認証されたＱｏＳリソースに対する修正を伴う）。この時点で、ＡＦセッションが通知済みの制限により続行できない旨がＡＦによって決定された場合、ＡＦ１６はＲｘセッションの終了をさらに要求する。その場合、図示のように、ステップ３１３に示したように、ＡＦ１６はセッション終了要求をＰＣＲＦ１４へ送信する。ステップ３１４において、セッションが終了された旨を確認することによってＰＣＲＦは応答を行う。

図３に示す実施形態では、要求とさらなる帯域制限の通知とは、Ｒｘインタフェースを介して通知に対する現在のフレームワークの内部で処理されると共に、既存の特定アクション属性値ペア（ＡＶＰ）の内部に新たなトリガとして含まれることになる。次いで、特定アクションＡＶＰの新たな値が以下のように定義される。

［帯域制限通知］
ＡＡＲにおいて、上記値は、帯域制限を経験した場合、ＡＦが通知を提供するようにＰＣＲＦに要求することを示す。（ＡＡＲには、ＰＣＲＦが帯域制限情報を提供する形式のためのＡＦ基本設定も含まれ、ＰＣＲＦは、新たな「利用可能帯域幅情報」ＡＶＰの内部に含まれる：以下を参照のこと）。

ＡＡＡの内部では、初期のセッション情報の供給中に、あるいは、（新たなメディアタイプなどの）セッション特性の修正以降にＰＣＲＦが帯域制限を経験した場合、上記値が用いられる。

ＲＡＲの内部では、上記値は、ＰＣＲＦがベアラプレーンでのイベントに起因して帯域制限を経験する場合に用いられるが、ＡＦセッションの内部のすべてのサービスデータフローが影響を受けるというわけではない。

その場合、上記値がＡＡＲ要求の内部に在る特定アクションＡＶＰの内部に含まれていなければ、要求されたＡＦセッションに対して利用可能になる帯域についての情報はＡＦには通知されない。その場合、ＡＦセッションの設定又は修正はＰＣＲＦによって拒絶される場合はあるが、ＰＣＲＦが帯域制限に関する情報をＡＦへ送信することはない。また、上記値が初期ＡＡＲの特定アクションＡＶＰの内部に含まれていなければ、その後に経験される帯域制限についてＰＣＲＦはＡＦに通知することはない。

さもなければ、上記値がＡＡＲ要求の内部に在る特定アクションＡＶＰの内部に含まれていれば、ＡＡＲは「利用可能な帯域幅情報」ＡＶＰも含むことになる。この値は、ＡＦが帯域制限に関する情報を必要とする形式のＡＦ基本設定を表現するものである。

ＡＡＲが「利用可能な帯域幅情報」ＡＶＰを含む場合、ＰＣＲＦは、（３ＧＰＰ修正要求Ｃ３−０７０７１６に定義されているような）利用可能なサービス情報ＡＶＰをＡＡＡ又はＲＡＲの内部にも含むことになる。サポート・サービス情報ＡＶＰは、ＡＦによって表現される基本設定に従って、ＡＦセッションのために利用可能となる帯域情報を提供する。

「利用可能な帯域幅情報」ＡＶＰとは以下の値と共に列挙される種類の情報として定義することができる：
総帯域幅値（１）
ＡＦがＡＦセッション全体に対して利用可能な総帯域幅の通知を必要とするとき（例えば、帯域制限に起因してＰＣＲＦがＡＡ要求を受け付けることができなかった場合などに）、この値が用いられる。

メディアコンポーネント毎の値（２）
ＡＦがＡＦセッション内部の異なるメディアコンポーネントのために利用可能な帯域幅の通知を必要とするとき（例えば、帯域制限に起因してＰＣＲＦがＡＡ要求を受け付けることができなかった場合などに）、この値が用いられる。

Claims (21)

1. 通信ネットワークにおける、通信セッションに関連して利用可能なリソース量を示すリソース制限をアプリケーション機能（ＡＦ）に通知する方法であって、
   前記通信ネットワークは、前記セッションにおけるデータフローの認証及び制御を行うポリシーおよび課金ルール機能（ＰＣＲＦ）を含み、
   前記方法は、
   前記アプリケーション機能が、前記通信セッションを確立するために前記ポリシーおよび課金ルール機能へ認証要求を送信する工程であって、前記認証要求は、前記アプリケーション機能に前記セッションを続行するための、前記要求されたセッションにおける前記データフローに対するリソース制限を通知する旨の指示を含む、工程と、
   前記ポリシーおよび課金ルール機能が、前記認証要求が拒絶された場合に、前記リソース制限を前記アプリケーション機能に通知する工程と
   を有し、
   前記通信セッションはマルチメディアセッションであり、
   前記ポリシーおよび課金ルール機能は、前記マルチメディアセッションにおける複数のメディアコンポーネントそれぞれに対してデータフローの認証及び制御を行い、
   前記指示は、前記アプリケーション機能にリソース制限が通知される複数のレベルのうちの一つを特定し、
   前記複数のレベルは、セッション全体のレベルとメディアコンポーネントごとのレベルを含むことを特徴とする方法。
2. 前記アプリケーション機能は、ＩＭＳネットワークにおけるプロキシ呼／セッション制御機能に含まれることを特徴とする請求項１に記載の方法。
3. 前記ポリシーおよび課金ルール機能は、前記要求されたセッションが続行するのを許可されたか否かを示す認証応答メッセージにて、前記リソース制限を前記アプリケーション機能に通知することを特徴とする請求項１または２に記載の方法。
4. 前記認証要求における前記指示は、前記要求されたセッションが帯域幅制限を超える帯域幅を要求するために、続行することが許されない場合には、帯域幅制限の情報が前記アプリケーション機能に通知されるようにする要求を含むことを特徴とする請求項３に記載の方法。
5. セッションが進行中の間に適用される前記リソース制限に対する違反を前記アプリケーション機能に通知することを更に特徴とする請求項１乃至４のいずれか一項に記載の方法。
6. 前記ポリシーおよび課金ルール機能は、前記アプリケーション機能に対するリソース制限への変化の通知を含む再認証要求メッセージを送信することを特徴とする請求項５に記載の方法。
7. 再認証要求の受信時に、前記アプリケーション機能は、前記セッションが前記通知された制限で続行できるか否かを判定し、
   もし続行できなければ、前記セッションの終了を要求する
   ことを特徴とする請求項６に記載の方法。
8. 前記アプリケーション機能は、前記ポリシーおよび課金ルール機能へセッション終了要求を送信することを特徴とする請求項７に記載の方法。
9. 前記アプリケーション機能にリソース制限を通知する旨の指示は、前記認証要求メッセージにおいて、特定動作属性値ペア（Ｓｐｅｃｉｆｉｃ−Ａｃｔｉｏｎ Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ：ＡＶＰ）を含むことを特徴とする請求項１乃至８のいずれか一項に記載の方法。
10. 前記認証要求メッセージは更に、前記アプリケーション機能がリソース制限を通知される形式を示す利用可能帯域幅情報の特定動作属性値ペアを含むことを特徴とする請求項９に記載の方法。
11. 前記リソース制限の通知は、前記利用可能帯域幅情報の特定動作属性値ペアにおいて示された前記形式に従って前記アプリケーション機能セッションに対して利用可能な前記リソースの情報を提供するサポートサービス情報（Ｓｕｐｐｏｒｔｅｄ−Ｓｅｒｖｉｃｅ−Ｉｎｆｏ）の特定動作属性値ペアを含むことを特徴とする請求項１０に記載の方法。
12. 通信ネットワークにおける、前記ネットワークを介して通信するユーザ端末間でのアプリケーションセッションを提供するためのアプリケーション機能（ＡＦ）を実現する装置であって、
    前記通信ネットワークにおいてポリシーおよび課金ルール機能（ＰＣＲＦ）へセッション認証要求を送信する手段であって、前記セッション認証要求は、前記アプリケーション機能に前記セッションを続行するために、前記要求されたセッションにおけるデータフローに対して利用可能なリソース量を示すリソース制限を通知する旨の指示を含む、手段と、
    前記セッション認証要求が拒絶された場合に、前記リソース制限の通知を受信する手段と
    を有し、
    前記通信セッションはマルチメディアセッションであり、
    前記ポリシーおよび課金ルール機能は、前記マルチメディアセッションにおける複数のメディアコンポーネントそれぞれに対してデータフローの認証及び制御を行い、
    前記指示は、前記アプリケーション機能にリソース制限が通知される複数のレベルのうちの一つを特定し、
    前記複数のレベルは、セッション全体のレベルとメディアコンポーネントごとのレベルを含むことを特徴とする装置。
13. 前記アプリケーション機能は、ＩＭＳネットワークにおけるプロキシ呼／セッション制御機能（Ｐｒｏｘｙ Ｃａｌｌ／Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）に含まれることを特徴とする請求項１２に記載の装置。
14. 前記リソース制限の通知は、前記要求されたセッションが要求されるように前記要求されたリソース量を提供されるか否かを示す認証応答メッセージに含まれることを特徴とする請求項１２または１３に記載の装置。
15. 前記セッションに加わる１以上の前記ユーザ端末へ、前記通知されたリソース制限に関連する情報を提供することを特徴とする請求項１２乃至１４のいずれか一項に記載の装置。
16. 前記アプリケーション機能は、前記リソース制限に適合するために前記セッション認証要求を修正するように構成されることを特徴とする請求項１２乃至１５のいずれか一項に記載の装置。
17. 前記セッション認証要求への修正を、少なくとも一つの前記ユーザ端末へ通知することを特徴とする請求項１６に記載の装置。
18. 前記アプリケーション機能は、前記ポリシーおよび課金ルール機能へ、前記修正されたセッション認証要求を送信するように構成されることを特徴とする請求項１６または１７に記載の装置。
19. 通信ネットワークにより通信を行うユーザ端末間のセッションに対するデータフローを認証及び制御する、前記ネットワークにおけるポリシーおよび課金ルール機能（ＰＣＲＦ）を実現する装置であって、
    前記通信ネットワークにおけるアプリケーション機能からセッション認証要求を受信する手段であって、前記セッション認証要求は、前記アプリケーション機能に前記セッションを続行するために、前記セッションにおけるデータフローに対して利用可能なリソース量を示すリソース制限を通知する旨の指示を含む、手段と、
    前記セッション認証要求が拒絶された場合に、前記アプリケーション機能にリソース制限の通知を送信する手段と
    を有し、
    前記通信セッションはマルチメディアセッションであり、
    前記ポリシーおよび課金ルール機能は、前記マルチメディアセッションにおける複数のメディアコンポーネントそれぞれに対してデータフローの認証及び制御を行い、
    前記指示は、前記アプリケーション機能にリソース制限が通知される複数のレベルのうちの一つを特定し、
    前記複数のレベルは、セッション全体のレベルとメディアコンポーネントごとのレベルを含むことを特徴とする装置。
20. 前記ＰＣＲＦは、前記アプリケーション機能がリソース制限を通知される前記レベルを特定する指示を、メモリに格納するように構成されることを特徴とする請求項１９に記載の装置。
21. 前記格納された指示に従って、セッションが進行中の間、前記アプリケーション機能にリソース制限へのその後の違反を通知することを特徴とする請求項２０に記載の装置。