JP2012508525A - 既存の認証アーキテクチャおよびプロトコルを用いたｓｉｐセッションポリシーをサポートする方法およびシステム - Google Patents

Abstract

セッションポリシー要求をネットワーク構成要素に送信するための方法を提供する。方法は、下位層プロトコルを使用して、セッションポリシー要求をネットワーク構成要素に送信する、ユーザエージェントを備える。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）、ポイントツーポイントプロトコル（ＰＰＰ）、および汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストのうちの少なくとも１つである。

Description

ＩＰ（インターネットプロトコル）マルチメディアサブシステム（ＩＭＳ）は、マルチメディアサービスおよびボイスオーバーＩＰ呼を、モバイルおよび固定ユーザエージェント（ＵＡ）に提供するための標準化されたアーキテクチャである。セッション開始プロトコル（ＳＩＰ）は、ＩＭＳベースの呼またはセッションを作成、修正、および終了するための信号送信プロトコルとして、主にインターネット技術特別調査委員会（ＩＥＴＦ）によって標準化および管理が行われてきた。本明細書で使用されるように、用語「ユーザエージェント」および「ＵＡ」は、ある場合には、電気通信能力を有する、携帯電話、携帯情報端末、携帯式またはラップトップコンピュータ、および類似のデバイス等のモバイルデバイスを指す場合がある。このようなＵＡは、ＵＡと、加入者識別モジュール（ＳＩＭ）アプリケーション、汎用加入者識別モジュール（ＵＳＩＭ）アプリケーション、または可撤性ユーザ識別モジュール（Ｒ−ＵＩＭ）アプリケーションを含む汎用集積回路カード（ＵＩＣＣ）等が挙げられるが、これに限定されない、その関連する可撤性メモリモジュールとから成る場合がある。代替的に、このようなＵＡは、このようなモジュールを伴わないデバイス自体から成る場合がある。他の場合において、用語「ＵＡ」は、固定回線電話、デスクトップコンピュータ、セットトップボックス、またはネットワークノード等の、移動可能ではないが類似した能力を有するデバイスを指す場合がある。ＵＡがネットワークノードである時、ネットワークノードは、ＵＡまたは固定回線デバイス等の別の機能に代わって作用し、ＵＡまたは固定回線デバイスをシミュレートまたはエミュレートし得る。例えば、いくつかのＵＡの場合、典型的にデバイス上に存在するＩＭＳ ＳＩＰクライアントは、実際は、ネットワーク内に存在して、最適化プロトコルを使用してＳＩＰメッセージ情報をデバイスに中継する。換言すれば、従来はＵＡによって実行された、いくつかの機能は、遠隔ＵＡの形態で分散させることができ、遠隔ＵＡは、ネットワーク内のＵＡを表す。用語「ＵＡ」はまた、ＳＩＰセッションが挙げられるが、これに限定されない、通信セッションを終了することができる、あらゆるハードウェアまたはソフトウェア構成要素を指すことができる。また、用語「ユーザエージェント」、「ＵＡ」、「ユーザ機器」、「ＵＥ」、および「ノード」は、本明細書で同義的に使用される場合がある。

最初に、本開示の１つ以上の実施形態の例示的な実装例を以下に提供するが、開示されるシステムおよび／または方法は、現在公知であるか、存在しているかに関わらず、任意の数の技術を使用して実装されてもよいことを理解されたい。本開示は、本明細書に示され、説明される例示的な設計および実装例を含む、以下に示される例示的な実装例、図面、および技術に限定されるべきではなく、同等物の十分な範囲とともに、添付の特許請求の範囲の範囲内で修正されてもよい。

リクエストフォーコメント（ＲＦＣ）３２６１は、セッションを作成、修正、および終了するための信号送信プロトコルである。ＳＩＰの主要な要素は、プロキシサーバである。プロキシサーバは、要求ルーティング、ランデブー、認証および認可、移動性、ならびに他の信号送信サービスに関与する、媒介である。しかしながら、プロキシは、ＳＩＰが確立する実際のセッション−オーディオ、ビデオ、およびセッションモードメッセージング−と分離される。セッションの詳細は、ＳＩＰメッセージのペイロードで搬送され、通常、セッション記述プロトコル（ＳＤＰ）ＲＦＣ４５６６およびＲＦＣ３２６４で説明される。

経験では、ＳＩＰ媒介がセッションの側面に影響を与える必要性があることを示している。セッションパラメータは、典型的に、セッションポリシーの施行によって制御される。例えば、ＳＩＰは、メディアトラフィックのための限られたリソースを有する、無線ネットワークで使用することができる。高活性の期間中に、無線ネットワークプロバイダは、各ユーザが利用可能な帯域幅の量を制限することを望み得る。セッションポリシーにより、無線ネットワーク内の媒介は、ＵＡが有する帯域幅が利用可能であること関してＵＡに知らせることができる。この情報は、ＵＡが、ストリームの数、メディアタイプ、およびセッションの中で成功裏に使用することができるコーデックに関して、十分な情報を得た上で決定することを可能にする。同様に、ネットワークプロバイダは、ユーザが使用することができる一組のメディアタイプを定義する、ユーザとのサービスレベル合意を有することができる。ネットワークは、現在の組のポリシーをユーザエージェントに輸送することができ、それらが、ネットワークポリシーのうちのいずれも犯すことなく、セッションを設定することを可能にする。

別の実施例において、ＳＩＰ ＵＡは、ファイアウォールまたはネットワーク境界デバイスを通して公衆インターネットに接続されるネットワークを使用している。ネットワークプロバイダは、公衆インターネットに到達するように、特定のＩＰアドレス、およびファイアウォールまたは境界デバイス上のポートにそのメディアストリームを送信する必要があることを、ＵＡに示すことを望む。このポリシーを知ることで、ＵＡが、ファイアウォールまたはネットワーク境界の全体にセッションを設定することを可能にする。メディア媒介を挿入するための他の方法とは対照的に、セッションポリシーの使用は、ＳＩＰメッセージ本体の検査または変更を必要としない。

ドメインは、しばしば、それらが有するセッションポリシーを適所で実施する必要性を有する。例えば、ドメインは、ビデオの使用を認めず、かつビデオ符号化を含有する全てのパケットをドロップする施行機構を有することができる、ポリシーを有する場合がある。残念なことに、これらの施行機構は、通常、それらが実施しているポリシーに関してユーザに知らせない。代わりに、それらは静かに、ユーザがそれらに対して何も行わないようにする。これは、ユーザに理解できないデバイスの故障を助長する可能性がある。セッションポリシーによって、ユーザは、現在のネットワークポリシーに関して知り、ポリシーに準拠したセッションを設定すること、または単純に、あまり厳しくないポリシーを伴うドメインに接続することができる。したがって、セッションポリシーは、施行に結び付けられる重要な同意の組み合わせを提供する。すなわち、ユーザは、ポリシーを認識し、それに従って行動する必要があるが、プロバイダはそれでも、ポリシーを実施する権利を保持する。

ＩＥＴＦは、ネットワークが、現在の組のポリシーをＳＩＰ ＵＡに輸送することを可能にするように、ｄｒａｆｔ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５において、セッションポリシーフレームワークを定義しており、それらが、ネットワークポリシーのうちのいずれも犯すことなく、セッションを設定することを可能にする。

セッション固有のポリシーおよびセッション独立のポリシーという２種類のセッションポリシーが定義されている。セッション固有のポリシーは、セッションの記述に基づいて、１つの特定のセッションについて作成されるポリシーである。それらは、ネットワーク媒介が、ＵＡが提案しているセッションを検査して、特にセッション記述のためのポリシーを返すことを可能にする。例えば、媒介は、提案されたセッション記述の中の各メディアストリームについて、ファイアウォール／ネットワークアドレス変換（ＮＡＴ）のピンホールを開くことができる。次いで、ＵＡのＩＰアドレスおよびポートを、外部ソースから到達可能であるファイアウォール／ＮＡＴで開いたものと置換する、セッション記述のためのポリシーを返すことができる。セッション固有のポリシーは、セッションに合うように調整されるので、それらが作成されるセッションに適用するのみである。セッション固有のポリシーは、セッションが確立される時にセッション単位で作成される。

一方で、セッション独立のポリシーは、セッションから独立して作成され、概して、ＵＡによって設定される全てのＳＩＰセッションに適用するポリシーである。セッション独立のポリシーは、例えば、既存の帯域幅限度またはメディアタイプ制限に関してＵＡに知らせるために使用することができる。これらのポリシーは、特定のセッション記述に基づいていないので、セッションを設定する試みから独立して作成することができ、初期化する時（例えば、デバイスの電源をオンにした時）、およびポリシーが変更された時に、ＵＡに輸送することしか必要としない。

以下に説明される機構は、セッション独立のポリシーおよびセッション固有のポリシーの両方に使用することができる。セッション固有のポリシー（すなわち、ＳＩＰの要求またはＳＩＰの応答に応答して供されるポリシー）の場合、ＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒ文書がＵＡに返される場合がある。セッション独立のポリシー（すなわち、セッションの前にＵＡに提供されるポリシー）の場合、セッションポリシー文書が返される場合がある。
メディアポリシーに加えて、本明細書で定義される機構は、ファイアウォールもしくはＮＡＴをナビゲートするように、またはトランスコーダもしくは他のメディアリレーを介してメディアをルーティングするように、ＳＤＰオファーまたはアンサーにおいて、異なるＩＰアドレスを使用することをＵＡに知らせるために使用することができる。

第３世代パートナーシッププロジェクト（３ＧＰＰ）は、モバイルおよび地上通信線ネットワーク用のマルチメディアサービスのための次世代ＳＩＰ／ＩＰに基づくネットワークとして、ＩＰマルチメディアサブシステム（ＩＭＳ）を標準化した。３ＧＰＰ ＩＭＳ用のアーキテクチャは、３ＧＰＰ技術仕様（ＴＳ）２３．２２８に明記されている。３ＧＰＰ ＴＳ２３．２２８には、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）およびプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）を含む、ＩＭＳ要素の機能が明記されている。Ｓ−ＣＳＣＦは、ＲＦＣ３２６１に定義されるように、ＳＩＰレジストラおよびＳＩＰプロキシの両方として作用する。Ｐ−ＣＳＣＦはまた、ＳＩＰプロキシとしても作用する。３ＧＰＰ ＩＭＳは、セッションの信号送信のためにＳＩＰを使用し、前述のように、ＩＭＳネットワークエンティティ（Ｐ−ＣＳＣＦおよびＳ−ＣＳＣＦ）は、セッションの側面（ストリームの数、メディアタイプ、およびコーデック等）の側面に影響を与えることが必要になり得る。

３ＧＰＰは、ＵＡがＩＭＳベアラリソースにアクセスする、必要な認可およびアカウント機能を実施する、ポリシーおよび課金制御（ＰＣＣ）のためのアーキテクチャを定義した。ＰＣＣアーキテクチャは、ＰＣＲＦ（ポリシー制御および課金規則機能）といったポリシーサーバを含み、これは、種々のソースからの入力に基づいて、どのＵＡが、セッションの属性および特徴（ストリームの数、メディアタイプ、コーデック）に基づいて、ベアラアクセスを許可されるのかを決定する。ＰＣＲＦは、サブスクリプションベースのポリシーのためのサブスクリプションプロファイルリポジトリ（ＳＰＲ）、およびアプリケーション固有の入力のためのアプリケーション機能（ＡＦ）にインターフェースする。ＩＭＳをＰＣＣとともに使用する時、ＡＦは、ＳＩＰセッション信号送信に基づいてＰＣＲＦに影響を与えることができる、ＳＩＰプロキシ（Ｐ−ＣＳＣＦ）である。ＰＣＲＦは、ポリシーが施行されるのを確実にするようにゲーティングおよびフィルタリング機能を提供する、ポリシー制御施行機能（ＰＣＥＦ）にインターフェースする。ＰＣＥＦは、アクセスネットワーク固有のゲートウェイ（例えば、ＧＧＳＮ、ＰＤＧ、ＰＤＳＮ、またはＣＭＴ）と一体化される。これらのエンティティは、ＤＩＡＭＥＴＥＲまたはＲＡＤＩＵＳプロトコルを使用して通信し、認証認可アカウンティング（ＡＡＡ）インフラストラクチャの一部を形成する場合がある。本明細書に記載するポリシーサーバは、ＰＣＲＦに限定されないことを理解されたい。Ｐ−ＣＳＣＦと一体化されるポリシーサーバ等の他の実施形態が可能である。

現在、３ＧＰＰは、ＴＳ２４．２２９で、元々のＳＩＰ ＩＮＶＩＴＥ要求が、ネットワークポリシーが許可しないメディアタイプまたはコーデックを含有している場合に、ＳＩＰ４８８応答を送信するＳＩＰプロキシに基づく、ＩＭＳのためのセッションポリシーのポリシング機構を有する。ＲＦＣ３２６１および３ＧＰＰ ＴＳ２４．２２９に明記されるように、４８８応答は、発呼ＵＡが、許可されるＳＤＰを伴う要求を再試行できるように、許可されるメディアタイプおよびコーデックのＳＤＰ記述を含有する。しかしながら、このアプローチは、ＳＩＰ要求が各ドメインを横断する時に、いずれのドメインもそれ自体の組のポリシーを有し得るという問題を有する。それは、単一のＳＩＰ要求が、４つ以上の異なるＩＭＳドメインを横断することができ、かつ潜在的に、各ドメインによって返信されるＳＩＰ４８８応答を有する、ローミング状況において非常に可能である。潜在的に、各ドメインの中の各プロキシは、ＳＩＰ４８８応答を伴うＳＩＰ ＩＮＶＩＴＥ要求を拒否しなければならない可能性があり、その結果、発呼ＵＡは、ＳＩＰ ＩＮＶＩＴＥ要求が着呼ＵＡに到達する前に、５つ以上（またはそれ以上）のＳＩＰ ＩＮＶＩＴＥ要求を送信（および４つ以上のＳＩＰ４８８応答を受信）しなければならない。これは、大幅に遅延したセッションのセットアップをもたらす。

また、この機構は、ＲＦＣ３２６１で許可されるＳＤＰを含有しないＳＩＰ ＩＮＶＩＴＥ要求に対しては機能せず、一方、ＳＤＰを伴わない初期のＳＩＰ ＩＮＶＩＴＥを送信することができ、次いで、着呼ＵＡが、その応答でＳＤＰオファーを返信することができ、次いで、発呼パーティが、ＡＣＫ要求でＳＤＰアンサーを返す。ＳＩＰ応答は、要求に応答して送信することしかできないので、応答は、４８８応答で拒否することができない。したがって、３ＧＰＰ ＩＭＳは、ネットワークサーバ（ポリシーを認識している）および外部ＩＭＳネットワークのみからオファーのないＳＩＰ ＩＮＶＩＴＥ要求が生じることを可能にすることによって、これらの要求の使用を制限しており、要求が起こり得る場合、セッションがポリシーに反するコーデックで確立されれば、ＢＹＥで即時に終了される。この状況は、満足できるものではない。

加えて、３ＧＰＰ ＰＣＣアーキテクチャは、セッションのベアラリソースの認可のためのＰＣＲＦへの入力を提供するように、ＳＩＰ信号送信からＳＤＰを分析する、Ｐ−ＣＳＣＦに依存する。着呼ＵＡの場合、着呼ＵＡによって受け入れられるメディアタイプおよびコーデックに基づいてベアラリソースを認可するために、Ｐ−ＣＳＣＦによって、応答して送信されるＳＤＰアンサーが必要とされる。これは、着呼ＵＡが、しばしば、そうでない場合にアンサーを送信してしまうよりも早く、ＳＤＰアンサーを含有する暫定（１ｘｘ）応答を送信する必要があることを意味する。ＩＭＳは、前提条件フレームワークＲＦＣ３３１２を使用するので、この暫定応答は、確実に送信する必要がある。これは、さらなるＳＩＰ ＰＲＡＣＫ要求および２００ＯＫ応答を交換することも必要とする可能性があり、末端の間で交換する必要がある付加的で不必要なＳＩＰメッセージにより、大幅に遅延した呼設定時間をもたらす。

本開示をより完全に理解するために、添付の図面および発明を実施するための形態と併せて理解される、以下の簡単な説明を参照し、類似参照数字は、類似部品を表す。
図１は、従来の技術によるＳＩＰセッションの確立のための流れ図である。 図２は、従来の技術によるポリシーアーキテクチャの図である。 図３は、従来の技術によるポリシーおよび課金制御アーキテクチャの図である。 図４は、本開示の一実施形態による電気通信システムの図である。 図５は、本開示の一実施形態によるプロトコルスタックの図である。 図６は、本開示の一実施形態によるアクセスネットワークの図である。 図７は、本開示の一実施形態による別のアクセスネットワークの図である。 図８は、本開示の一実施形態による別のアクセスネットワークの図である。 図９は、本開示の一実施形態による別のアクセスネットワークの図である。 図１０は、本開示の一実施形態による別のアクセスネットワークの図である。 図１１は、本開示の一実施形態による別のアクセスネットワークの図である。 図１２は、本開示の一実施形態による別のアクセスネットワークの図である。 図１３は、本開示の一実施形態による、セッションポリシー要求をネットワーク構成要素に送信するための方法の図である。 図１４は、本開示の代替の実施形態による、ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法の図である。 図１５は、本開示の一実施形態による、複数の相互結合したポリシー制御および課金規則機能の図である。 図１６は、本開示の代替の実施形態による、ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法の図である。 図１７は、本開示の代替の実施形態による、ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法の図である。 図１８は、本開示の複数の実施形態を実装するための好適なプロセッサおよびに関連する構成要素を示す図である。

図１は、ＳＩＰセッション確立を伴うセッションポリシーフレームワークの基本的なＩＥＴＦ ＳＩＰアーキテクチャを例証する、ｄｒａｆｔ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５からの流れ図である。イベント１２で、第１のＵＡ_Ａ１１０_Ａは、ＳＤＰオファーを含有するＳＩＰ ＩＮＶＩＴＥメッセージを第１のプロキシ_Ａ１２０_Ａに送信する。イベント１４で、第１のプロキシ_Ａ１２０_Ａは、ポリシーコンタクトヘッダを含む４８８メッセージを第１のＵＡ_Ａ１１０_Ａに送信する。次いで、第１のＵＡ_Ａ１１０_Ａは、肯定応答メッセージを第１のプロキシ_Ａ１２０_Ａに返す。イベント１６で、第１のＵＡ_Ａ１１０_Ａは、ＩｎｆｏＯｆｆｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第１のポリシーサーバ_Ａ１３０_Ａに送信する。イベント１８で、第１のポリシーサーバ_Ａ１３０_Ａは、ＰｏｌｉｃｙＯｆｆｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第１のＵＡ_Ａ１１０_Ａに送信する。

イベント２０で、第１のＵＡ_Ａ１１０_Ａは、第１のプロキシ_Ａ１２０_Ａおよび第２のプロキシ_Ｂ１２０_Ｂを介して、ＳＤＰオファーを含有するＩＮＶＩＴＥメッセージを第２のＵＡ_Ｂ１１０_Ｂに送信する。イベント２２で、第２のＵＡ_Ｂ１１０_Ｂは、ＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第２のポリシーサーバ_Ｂ１３０_Ｂに送信する。イベント２４で、第２のポリシーサーバ_Ｂ１３０_Ｂは、ＰｏｌｉｃｙＯｆｆｅｒおよびＰｏｌｉｃｙＡｎｓｗｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第２のＵＡ_Ｂ１１０_Ｂに送信する。イベント２６で、第２のＵＡ_Ｂ１１０_Ｂは、第２のプロキシ_Ｂ１２０_Ｂおよび第１のプロキシ_Ａ１２０_Ａを介して、ＳＩＰ２００ＯＫアンサーを第１のＵＡ_Ａ１１０_Ａに送信する。次いで、第１のＵＡ_Ａ１１０_Ａは、ＳＩＰ肯定応答（ＡＣＫ）メッセージを第２のＵＡ_Ｂ１１０_Ｂに返す。イベント２８で、第１のＵＡ_Ａ１１０_Ａは、ＩｎｆｏＡｎｓｗｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第１のプロキシ_Ａ１２０_Ａに送信する。イベント３０で、第１のプロキシ_Ａ１２０_Ａは、ＰｏｌｉｃｙＡｎｓｗｅｒを含有するＰｏｌｉｃｙＣｈａｎｎｅｌメッセージを第１のＵＡ_Ａ１１０_Ａに送信する。

以下のエンティティは、典型的に、セッション固有のポリシーに必要とされる。ＵＡ、プロキシ、ポリシーサーバ、および場合によりポリシー施行エンティティ。これらのエンティティのためのポリシーアーキテクチャを図２に例証する。ＵＡ１１０は、ＳＩＰ信号送信１２５を介してプロキシ１２０と通信し、かつポリシーチャネル１３５を介してポリシーサーバ１３０と通信する。メディア１４５は、ＵＡ１１０とポリシー施行構成要素１４０との間で交換される場合がある。

プロキシ１２０は、ＵＡ１１０およびポリシーサーバ１３０のためのランデブー機構を提供する。それは、各ＵＡ１１０が、そのドメインの中のポリシーサーバ１３０のユニフォームリソース識別子（ＵＲＩ）を得て、どこからポリシーを検索するのかを知ることを確実にする。プロキシ１２０は、ＵＡ１１０がまだポリシーサーバＵＲＩを受信していなかった場合、（例えば、以前の呼の際に、または構成等の他の手段を通して）ポリシーサーバＵＲＩを該ＵＡに輸送する。プロキシ１２０は、実際のポリシーをＵＡ１１０に配信しない。代わりに、プロキシ１２０は、ＵＡ１１０がそこからポリシー文書または他のポリシー情報を読み出すことができるポリシーサーバ１３０のＵＲＩまたは他の識別子を、ＵＡ１１０に提供する。

ポリシーサーバ１３０は、プロキシ１２０とともに物理的に並置することができる、別個の論理エンティティである。ポリシーサーバ１３０の役割は、セッションポリシーをＵＡ１１０に配信することである。ポリシーサーバ１３０は、ＵＡ１１０からセッション情報を受信し、この情報を使用してセッションに適用するポリシーを決定し、そして、これらのポリシーをＵＡ１１０に返す。

セッションポリシーフレームワークは、それによってＵＡ１１０がプロキシ１２０からポリシーサーバ１３０のＵＲＩを受信する機構として、ＳＩＰポリシーコンタクトヘッダ（プロキシ１２０によって、ＳＩＰ要求および応答の中に含めることができる）を定義する。すなわち、プロキシ１２０は、ポリシーサーバ１３０のＵＲＩをポリシーコンタクトヘッダに追加することができる。ＵＡ１１０は、このＵＲＩを使用してポリシーサーバ１３０にコンタクトし、現在のセッションに関する情報（セッション記述（ＳＤＰ）を含む）をポリシーサーバ１３０に提供する。次いで、ＵＡ１１０は、それに応答して、ポリシーサーバ１３０からセッションポリシーを受信する。ＵＡ１１０はまた、セッションの経過中に、ポリシーサーバ１３０からポリシーの更新を受信することができる。ＵＡ１１０とポリシーサーバ１３０との間の通信交換は、ポリシーチャネル１３５として定義される。

現在のセッションポリシーフレームワークは、ポリシーチャネル１３５を使用して、セッションポリシーをＵＡ１１０に配信するように、ＳＩＰイベントフレームワークＲＦＣ３２６５、およびｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｐｏｌｉｃｙ−ｐａｃｋａｇｅ−０５に定義されるイベントパッケージのみに基づいて、ＳＩＰベースの機構を定義し、かつ現在、ＳＩＰ、およびプロキシ１２０によってＳＩＰポリシーコンタクトヘッダの中に含めることができるＵＲＩとして、ＳＩＰＳ ＵＲＩのみを定義する。セッションポリシーフレームワークの全詳細は、ｄｒａｆｔ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５に定義されている。

３ＧＰＰは、図３に示されるように、ＴＳ２３．２０３においてポリシーおよび課金制御（ＰＣＣ）アーキテクチャを画定した。図中、ポリシーおよび課金規則機能（ＰＣＲＦ）は、ポリシーサーバである。太破線は、ｄｒａｆｔ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５に定義されるように、その上でポリシーチャネルが動作する必要がある、基準点を示す。サブスクリプションプロファイルリポジトリ（ＳＰＲ）はまた、サブスクリプション関連のポリシーを含有するが、これらは、ＰＣＲＦによってＰＣＲＦポリシーの中に組み込まれる。ＴＳ２３．２０３はまた、ローミングシナリオのための訪問先ＰＣＲＦを伴う他の構成をサポートするが、これらの場合、単一のＰＣＲＦが、他のポリシーサーバにインターフェースする。ポリシー課金施行機能は、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）固有のゲートウェイ（例えば、ＧＧＳＮ、ＰＤＧ、ＣＭＴ）に組み込まれる。３ＧＰＰ ＩＭＳにおいて、Ｐ−ＣＳＣＦは、ＡＦ（アプリケーション機能）機能を実装する。ＡＦは、Ｒｘ基準点を介して、ＰＣＲＦと通信する。３ＧＰＰ ＩＭＳにおいて、Ｐ−ＣＳＣＦは、ＩＭＳ ＳＩＰセッションのためのベアラリソースを認可するために、ＰＣＲＦと相互作用する。ＰＣＲＦは、ＰＣＥＦがセッションベアラに適用するポリシーを決定するための基準のうちの１つとして、Ｐ−ＣＳＣＦ情報を使用する。Ｇｘ基準点は、ＰＣＥＦとＰＣＲＦとの間で通信するためのプロトコルとして、ＤＩＡＭＥＴＥＲを利用する。同様に、ＤＩＡＭＥＴＥＲは、Ｐ−ＣＳＣＦとＰＣＲＦとの間のＲｘ基準点上で使用されるプロトコルである。

ＳＩＰイベントフレームワークＲＦＣ３２６５は、仮想のポリシーおよびネットワークアーキテクチャから独立しているので、良好な一般的ソリューションを提供し、全てのＳＩＰ ＵＡ１１０が、全てのポリシーサーバ１３０と相互作用するのを可能にするのを確実にする。しかしながら、ＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）、ＵＭＴＳ（汎用モバイル通信システム）、ＣＤＭＡ（符号分割多重アクセス）、およびＥ−ＵＴＲＡＮ（進化型ＵＭＴＳ地上無線アクセスネットワーク）等の、限られた帯域幅のネットワークの場合、ＳＩＰイベントフレームワークＲＦＣ３２６５は、セッションのセットアップ中に、セッションポリシーをＵＡ１１０に転送する場合には極めて重くなる。少なくとも、ＳＩＰイベントフレームワークは、セッションポリシーを得るために、以下のＳＩＰメッセージを送信することを必要とする。ＳＩＰ ＳＵＢＳＣＲＩＢＥメッセージ、ＳＩＰ２００ＯＫメッセージ、ＳＩＰ ＮＯＴＩＦＹメッセージ、および別のＳＩＰ２００ＯＫメッセージ。

加えて、これらのメッセージ、特にＳＵＢＳＣＲＩＢＥメッセージおよびＮＯＴＩＦＹメッセージは、ＩＰおよびＵＤＰヘッダのオーバーヘッドも含む、大きいテキストベースのメッセージである。したがって、メッセージは、数百バイトの大きさになり得る。ＮＯＴＩＦＹメッセージは、拡張マークアップ言語（ＸＭＬ）符号化ポリシー文書を含むので、特に大きくなる場合がある。

したがって、図１のセッションポリシーの流れ図に示されるシナリオでは、セッションを確立するために必要である９つのＳＩＰセッション信号送信メッセージに加えて、ポリシーチャネル上でＳＩＰイベントを使用する３つのポリシーチャネルの相互作用のために、１２のＳＩＰメッセージが必要とされる。したがって、ＳＩＰイベントフレームワークを使用したＳＩＰ信号送信オーバーヘッドは、ＳＩＰセッションの確立に必要とされるＳＩＰ信号送信よりも大きい。これは、信号送信帯域幅の浪費であるだけでなく、１秒あたり数千キロビットしか信号送信チャネルを伴わない、携帯電話等の限られた帯域幅のネットワークにおいても、これは、セッションのセットアップにかなりの遅延を引き起こし得る。

また、ＳＩＰイベントフレームワークは、ステートフルであり、これは、ＳＩＰダイアログを確立することを意味する。これは、ネットワークインフラストラクチャのエンティティにかなりの負荷をかける可能性がある。また、ポリシーサーバ１３０は、従来、ＳＩＰを実装していなかったが、ポリシーを転送するために、ＡＡＡ（ＲＡＤＩＵＳおよびＤＩＡＭＥＴＥＲ）等の他のプロトコルを使用していた。

このシナリオの下で送信する必要がある多数の往復ＳＩＰメッセージ、ならびに大きいサイズのメッセージおよびポリシー文書は、多量のオーバーヘッドを消費する可能性がある、容認し難いほどに非効率的な機構をもたらす可能性がある。これは、信号送信帯域幅の浪費であるだけでなく、セッションのセットアップにかなりの遅延を引き起こし得る。

ある実施形態では、３ＧＰＰ ＰＣＣまたは類似したＡＡＡインフラストラクチャを展開した、ＳＩＰまたはＳＩＰＳ ＵＲＩの代わりに、ＡＡＡ ＵＲＩまたは類似したＵＲＩをポリシーコンタクトヘッダに提供する。すなわち、ＳＩＰメッセージング層よりも下位の層である通信経路がＵＡとポリシーサーバとの間に作成されて、ポリシーチャネルとして使用される。ＵＡは、下位層プロトコルを使用して、このポリシーチャネル上でセッションポリシー要求をポリシーサーバに送信することができる。ある場合には、下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）を使用する、ＤＩＡＭＥＴＥＲプロトコルまたはＲＡＤＩＵＳプロトコルである場合がある。ＥＡＰを説明したが、当業者は、これに限定されないが、ポイントツーポイントプロトコル（ＰＰＰ）等の、他のプロトコルを選択してもよい。他の場合において、下位層プロトコルは、無線デバイスとネットワークとの間にデータベアラチャネルを作成する。例えば、無線デバイスは、データチャネルを作成する情報を含有するメッセージをネットワークに送信する場合がある。これは、無線デバイスからＳＧＳＮと呼ばれるネットワークノードへの通信である、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）である場合がある。ＬＴＥ環境において、ＥＳＭメッセージの下位層プロトコルは、無線デバイスからＭＭＥへのＡＴＴＡＣＨメッセージの中に、または別個のデフォルトのメッセージとして、トンネリングおよび／またはピギーバックされ得る、ＰＤＮ＿ＣＯＮＮＥＣＴＩＶＩＴＹ＿ＲＥＱＵＥＳＴまたはＢＥＡＲＥＲ＿ＲＥＳＯＵＲＣＥ＿ＭＯＤＩＦＩＣＡＴＩＯＮ＿ＲＥＱＵＥＳＴである場合があるが、これに限定されない。ＲＦＣ３５８８に従って、以下は、有効なＤＩＡＭＥＴＥＲまたはＲＡＤＩＵＳホスト識別の実施例である。

ａａａ：／／ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
ａａａ：／／ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ：６６６６。

代替的に、ＡＡＡ ＵＲＩを使用する代わりに、ＭＰＤＦ ＵＲＩ「ｍｐｄｆ：」または「ｍｐｄｆｅａｐ：」等の、新しいＵＲＩ形式をＭＰＤＦに対して定義することができる。他のＵＲＩ構文も可能である。

図４は、ＵＥがＥＡＰ（拡張認証プロトコル）を実装し、ＥＡＰを使用してＰＣＲＦを伴うポリシーチャネルプロトコルを実装するような方法で、セッションポリシー要求およびポリシー文書を送信することができる、システムを例証する。ＵＡ１１０は、ゲートウェイ、アクセスポイント、ネットワークアクセスサーバ、プロキシ、または実質的に同等の能力を伴う他の構成要素である場合がある、第１のタイプのネットワークノードに接続することができる。以下、この構成要素は、ゲートウェイ１２０と称する。ゲートウェイ１２０は、ポリシー課金施行機能（ＰＣＥＦ）を含む場合がある。以下、ゲートウェイ１２０という記述は、ゲートウェイ１２０単独、ＰＣＥＦ単独、またはＰＣＥＦと組み合わせたゲートウェイ１２０を指す場合がある。

ＵＡ１１０は、ＥＡＰプロトコルまたは類似した下位層プロトコルを介して、セッションポリシー要求をゲートウェイ１２０に送信することができる。ゲートウェイ１２０は、ポリシーサーバ、ポリシーおよび課金規則機能、認証サーバ、または類似した構成要素である場合がある、第２のタイプのネットワークノードに接続することができる。いくつかの実施形態では、この構成要素は、スタンドアロンの要素であることができる。他の実施形態では、この構成要素は、Ｐ−ＣＳＣＦを含む、ＳＩＰプロキシ等の別の構成要素と組み合わせることができる。以下、この構成要素は、ポリシーサーバ１３０と称する。１つのポリシーサーバ１３０のみが示されているが、複数のポリシーサーバが存在し得る。ゲートウェイ１２０は、ＲＡＤＩＵＳプロトコル、ＤＩＡＭＥＴＥＲプロトコル、または実質的に同等の能力を伴う他の何らかの下位層プロトコルを介して、セッションポリシー要求をポリシーサーバ１３０に送信することができる。セッションポリシー要求を送信し、ポリシー文書を受信するための、前述した最先端の技術の手順を、図４において破線で示す。

ＵＡ１１０を認証するプロセスにおいて、下位層通信経路１６０は、ゲートウェイ１２０を介して、ＵＡ１１０とポリシーサーバ１３０との間に作成される。この経路１６０は、ポリシーチャネルとして使用することができる。それによってＥＡＰベースの要求をＵＡ１１０からゲートウェイ１２０に輸送することができる種々の技術は、ＥＡＰフレームを輸送することができる、ＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲベースのインフラストラクチャを有することができる。したがって、ＥＡＰベースの要求は、ＵＡ１１０から、ゲートウェイ１２０を介して、ポリシーサーバ１３０に輸送することができ、ＥＡＰベースの応答は、ポリシーサーバ１３０からＵＡ１１０に輸送することができる。

ある実施形態では、ポリシーチャネル１６０は、セッションポリシー要求をＵＡ１１０からポリシーサーバ１３０に送信するために、およびポリシー文書または他のポリシー情報をポリシーサーバ１３０からＵＡ１１０に配信するために使用される。ポリシーチャネル１６０は、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋドラフトに定義される加入および通知機構に基づく、ポリシーチャネル機構のための置換物であることができる。より具体的には、１つ以上のＥＡＰフレームは、ＵＡ１１０とゲートウェイ１２０との間で、ＲＦＣ５１０８に従って、ＩＰ（インターネットプロトコル）上でＩＫＥｖ２（インターネット鍵交換バージョン２）を介して、ＩＰ−ＣＡＮ（ＩＰ接続アクセスネットワーク）上で輸送され得る。代替的に、ＲＦＣ２２８４に従って、ＰＰＰ（ポイントツーポイントプロトコル）上でのＥＡＰの輸送、有線ＩＥＥＥ８０２ ＬＡＮ（ＩＥＥＥ−８０２．１Ｘ）、ＩＥＥＥ ８０２．１１無線ＬＡＮ（ＩＥＥＥ−８０２．１１）、ＵＤＰ（Ｌ２ＴＰ［ＲＦＣ２６６１］およびＩＫＥｖ２［ＩＫＥｖ２］）、およびＴＣＰ（ＰＩＣ）等の、他の輸送プロトコルが使用される場合がある。他の輸送プロトコルも可能である。これらの輸送プロトコルのうちのいずれかにおいて、メッセージは、典型的にアプリケーション層で送信されるＳＩＰメッセージよりも下位のプロトコル層で送信される。

いくつかの実施形態では、ＥＡＰで許可されるタイプ・長さ・値（ＴＬＶ）構造は、ポリシー文書を要求するクエリーを挿入するために使用される場合がある。他の実施形態では、ポリシーコンタクトＵＲＩは、ユーザを識別するために使用したＲＦＣ４４８２に従って、あらゆるＮＡＩに付加することができる。ポリシーサーバアドレスはまた、ＳＩＰ ＵＡと、ＥＡＰフレームを扱うホームＡＡＡサーバとの間で共有されたキーによって、暗号化され得る。これは、ポリシーアドレスを、あらゆる媒介ノードに秘密にしておくのを可能にする。

ある実施形態では、ゲートウェイ１２０は、ＤＩＡＭＥＴＥＲを使用して、ＥＡＰフレームをＧｘ基準点上でポリシーサーバ１３０に転送する。他の実施形態では、ＲＡＤＩＵＳまたは類似したプロトコルを使用する場合がある。ＥＡＰフレームは、ＵＡ１１０とゲートウェイ１２０とポリシーサーバ１３０との間で、セッション情報文書等のポリシーチャネル文書を輸送することができる。セッション情報文書は、ＩｎｆｏＯｆｆｅｒ、ＩｎｆｏＡｎｓｗｅｒ、またはｄｒａｆｔ−ｉｅｆｔ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙフレームワークのような他の文書、および関連文書、または将来の拡張版である場合がある。ＵＡ１１０は、ポリシーコンタクトヘッダの中に提供されるポリシーコンタクトＵＲＩ（ユニフォームリソースインジケータ）、またはポリシーコンタクトヘッダと呼ばれ得るが、これに限定されない、新しいヘッダに基づいて、ポリシー文書を得るように、ポリシーサーバ１３０にアクセスすることができる。次いで、ポリシーサーバ１３０は、ポリシー文書または他のポリシー情報をＵＡ１１０に返すことができる。ポリシー情報は、要求と同じプロトコルを使用して同じ経路に沿うか、要求に使用したものと異なるプロトコルを使用して同じ経路に沿うか、要求に使用したものと異なる経路に沿うか、または他の何らかの手法で返さる場合がある。セッション固有のポリシーの場合、セッションポリシーが（例えば、利用可能な無線リソースの変化により）セッション中に変化した場合、ポリシーサーバ１３０は、同じＤＩＡＭＥＴＥＲおよびＥＡＰプロトコルを使用して、修正したポリシー文書をＵＡ１１０に送信することができる。

図５は、ＩＰ−ＣＡＮアクセスゲートウェイを介して、ＵＡと、ＤＩＡＭＥＴＥＲベースのＰＣＲＦとの間を、ＥＡＰおよびＩＰ上でメディアポリシー文書を輸送するための、提案されたプロトコルスタックの実施形態を示す。

本明細書に記載する実施形態を実装する時、前述のＳＩＰシナリオで使用された複数のＳＩＰメッセージと比較して、ＵＡ１１０がポリシー文書を要求および受信するために必要である往復メッセージを、大幅に低減することができる。また、ＥＡＰベースのセッションポリシー要求は、前述のＳＩＰメッセージのうちのいくつかよりもかなり小さくすることができる。例えば、ＳＩＰメッセージのオーバーヘッドは、典型的に、約５００〜１０００バイトである。一方で、ＥＡＰベースのメッセージのオーバーヘッドは、典型的に、約５０バイトである。

加えて、ある実施形態において、ポリシー文書は、より小さくするように２進数に変換することができ、ＳＩＰベースの方法で送信される大きいＸＭＬベースのポリシー文書ではなく、このより小さいポリシー文書をＵＡ１１０に送信することができる。セッションポリシー文書のＸＭＬコンテンツは、当技術分野において公知の多数の方法によって２進形に圧縮され得る。一実施例は、ＩＴＵ−Ｔ Ｒｅｃ．Ｘ．８９１に明記される、ＸＭＬインフォセットである。

３ＧＰＰは、メディアに対する認可要求がＳＩＰ信号送信とリンクされないという目的を有する。本明細書に記載するセッションポリシー要求は、メディアを得るよう認可を要求するように、ＥＡＰベースのメッセージを使用し、したがって、メディアに対する認可ポリシーからのこのＳＩＰ信号送信の分断を達成することができる。

加えて、ＥＡＰベースのセッションポリシー要求は、アクセスネットワークを問わない。すなわち、ＵＡ１１０は、ＧＰＲＳ（ＧＳＭ、ＥＤＧＥ、ＵＴＲＡＮ、および／またはＥ−ＵＴＲＡＮを含む場合がある）、３ＧＰＰ ＵＴＲＡＮ、３ＧＰＰ２ ＣＤＭＡ、８０２．１１ｘ ＷＬＡＮ、８０２．１６ ＷｉＭＡＸ、８０２．２０ ＷＬＡＮ、ＤＯＣＳＩＳ（データオーバーケーブルサービスインターフェース仕様）、および／またはＴＩＳＰＡＮ（高度なネットワークのための電気通信およびインターネット集中サービスおよびプロトコル）、ＮＡＳＳ／ＲＡＣＳ（ネットワークアタッチメントサブシステム／リソースおよび承認制御サブシステム）等の、複数の異なる無線または有線通信技術のうちの１つ以上を介して、ゲートウェイ１２０に接続する場合がある。これらのアーキテクチャは、典型的に、ＤＩＡＭＥＴＥＲベースの、またはＲＡＤＩＵＳベースのポリシーサーバに依存するので、ＵＡ１１０が、これらのアクセスネットワークのうちのどれを、ゲートウェイ１２０に接続するために使用するのかに関わらず、ＵＡ１１０は、本明細書に記載するように、ＥＡＰベースのセッションポリシー要求をゲートウェイ１２０に提出することができる。

図６は、ＵＡ１１０（図６−１２ではＵＥと称される）が、ＧＰＲＳ（ＧＳＭ／ＥＤＧＥ／ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮ）ＩＰ−ＣＡＮを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＩＭＳに対する３ＧＰＰセルアクセス（ＧＳＭ／ＥＤＧＥ／ＵＴＲＡＮ／Ｅ−ＵＴＲＡＮ）は、ＧＰＲＳを使用する。ＧＰＲＳの場合、ＩＰ−ＣＡＮベアラは、ＰＤＰコンテキストである。ＧＰＲＳにおいて、ゲートウェイは、ＧＧＳＮであり、ＰＣＥＦは、ＧＧＳＮと並置される。ＰＣＥＦとＰＣＲＦとの間のＧｘ基準点、およびＰ−ＣＳＣＦとＰＣＲＦとの間のＲｘ基準点は、ＤＩＡＭＥＴＥＲを使用する。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、または代替的にＰＰＰ上で、ＧＧＳＮに輸送される。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＥＡＰフレームは、Ｇｘ基準点を使用して、ＤＩＭＥＴＥＲ上でＰＣＲＦにルーティングされる。次いで、ＰＣＲＦは、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＣＲＦに搭載されるポリシー、ＳＰＲからフェッチされる加入者ポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびにＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦは、Ｇｘ上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＧＧＳＮに送信し、次いで、ＧＧＳＮが、ＩＰ上のＩＫＥｖ２上で、または代替的にＰＰＰ上でＵＥに輸送されるＥＡＰで、ＵＥに転送する。他のシナリオも可能である。

図７は、ＵＥが、拡張パケットコア（ＥＰＣ）ＩＰ−ＣＡＮを伴う３ＧＰＰ Ｅ−ＵＴＲＡＮまたは他の非３ＧＰＰアクセスを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。３ＧＰＰ Ｅ−ＵＴＲＡＮおよび他の非３ＧＰＰアクセスは、ＩＭＳにアクセスするために、拡張パケットコア（ＥＰＣ）を使用することができる。ＥＰＣの場合、ＩＰ−ＣＡＮベアラは、ＧＰＲＳまたはプロキシモバイルＩＰ（ＰＭＩＰ）から拡張されるＰＤＰコンテキストである。ＥＰＣにおいて、ゲートウェイは、ＰＤＮ ＧＷであり、ＰＣＥＦは、ＰＤＮ ＧＷと並置される。ＰＣＥＦとＰＣＲＦとの間のＧｘ基準点、およびＰ−ＣＳＣＦとＰＣＲＦとの間のＲｘ基準点は、ＤＩＡＭＥＴＥＲを使用する。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、ＰＤＮ ＧＷに輸送することができる。代替的に、チャネルＩｎｆｏＯｆｆｅｒは、ＰＤＮ ＣＯＮＮＥＣＴＩＶＩＴＹ ＲＥＱＵＥＳＴ等のＥＳＭメッセージで、ＰＤＮ ＧＷにトンネリング、ピギーバック、もしくは輸送され得、または、ＥＳＭメッセージが無線デバイスからのＡＴＴＡＣＨメッセージに含まれていなかった場合、ＩｎｆｏＯｆｆｅｒは、ＭＭＥを介して、ＰＤＮ ＧＷに輸送され得る。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージ、または、例えば、ＩｎｆｏＯｆｆｅｒを含有するセッション作成要求、およびＩｎｆｏＡｎｓｗｅｒメッセージを含有するセッション作成応答を含有するＥＰＣベアラチャネルを作成する、ＭＭＥからＰＤＮへのメッセージ、を含有するＥＡＰフレームは、Ｇｘ基準点を使用して、ＤＩＭＥＴＥＲ上でＰＣＲＦにルーティングされる。次いで、ＰＣＲＦは、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＣＲＦに搭載されるポリシー、ＳＰＲからフェッチされる加入者ポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびに／またはＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦは、Ｇｘ上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＰＤＮ ＧＷに送信し、次いで、ＰＤＮ ＧＷが、ＩＰ上のＩＫＥｖ２上でＵＥに輸送されるＥＡＰで、またはＰｏｌｉｃｙＡｎｓｗｅｒを含有するセッション作成応答を介して、ＵＥに転送する。

図８は、ＵＥが、３ＧＰＰ２ ＣＤＭＡ ＩＰ−ＣＡＮを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＩＭＳに対する３ＧＰＰ２セルアクセス（ＣＤＭＡ−１Ｘ、ＣＤＭＡ ＥＶＤＯ）は、モバイルＩＰを使用する。３ＧＰＰ２ ＣＤＭＡにおいて、ゲートウェイは、ＰＤＳＮであり、ＰＣＥＦは、ＰＤＳＮと並置される。ＰＣＥＦとＰＣＲＦとの間のＧｘ基準点、およびＰ−ＣＳＣＦとＰＣＲＦとの間のＲｘ基準点は、ＤＩＡＭＥＴＥＲを使用する。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、ＰＤＳＮに輸送される。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＥＡＰフレームは、Ｇｘ基準点を使用して、ＤＩＭＥＴＥＲ上でＰＣＲＦにルーティングされる。次いで、ＰＣＲＦは、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＣＲＦに搭載されるポリシー、ホームネットワークから（ＳＰＲもしくはホームＰＣＲＦ、またはホームネットワークの中の別のポリシーサーバ等から）フェッチされる加入者ポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびに／またはＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦは、Ｇｘ上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＰＤＳＮに送信し、次いで、ＰＤＳＮが、ＩＰ上のＩＫＥｖ２上でＵＥに輸送されるＥＡＰで、ＵＥに転送する。

図９は、ＵＥが、８０２．１１ｘ ＷＬＡＮ ＩＰ−ＣＡＮを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＩＭＳへの８０２．１１ｘ ＷＬＡＮアクセスにおいて、ゲートウェイは、ＰＤＧであり、ＰＣＥＦは、ＰＤＧと並置される。ＰＣＥＦとＰＣＲＦとの間のＧｘ基準点、およびＰ−ＣＳＣＦとＰＣＲＦとの間のＲｘ基準点は、ＤＩＡＭＥＴＥＲを使用する。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、または代替的に８０２．１Ｘ上で、ＰＧＤに輸送される。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒを含有するＥＡＰフレームは、Ｇｘ基準点を使用して、ＤＩＭＥＴＥＲ上でＰＣＲＦにルーティングされる。次いで、ＰＣＲＦは、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＣＲＦに搭載されるポリシー、ＳＰＲからフェッチされる加入者ポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびにＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦは、Ｇｘ上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＰＧＤに送信し、次いで、ＰＧＤが、ＩＰ上のＩＫＥｖ２上でＵＥに輸送されるＥＡＰで、ＵＥに転送する。

図１０は、ＵＥが、ＷｉＭＡＸ／８０２．１６ ＩＰ−ＣＡＮを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＷｉＭＡＸ ＩＰ−ＣＡＮにおいて、ＵＥ（ＩＥＥＥ８０２．１６規格では、移動局またはＭＳとしても参照される）は、ＷｉＭＡＸアクセスサービスネットワーク（ＡＳＮ）に接続する。ＡＳＮは、論理的に、一群のコアネットワーキング機能（例えば、モバイルＩＰ ＨＡ、ＡＡＡサーバ、ＤＨＣＰ、ＤＮＳ等）である、接続サービスネットワーク（ＣＳＮ）と通信する。ＡＳＮは、トラフィックの承認およびスケジューリングを管理し、認可されたＵＥに対するＱｏＳを実施し、かつＵＥに対するアカウント機能を実施する（セッション、フローまたはＵＥあたり）。ＷｉＭＡＸ ＰＣＥＦは、ＷｉＭＡＸ ＩＰ−ＣＡＮの一部であり、ＷｉＭＡＸフォーラムによって定義される。ＷｉＭＡＸ ＰＣＥＦは、ＰＣＲＦからのＧｘ基準点を終端し、分散型施行アーキテクチャであってもよい。

ＷｉＭＡＸ ＩＰ−ＣＡＮに対するＰＣＣ機能マッピングを図８に示し、ＰＣＣ ＧｘおよびＲｘが適用される。ＧｘおよびＲｘは、ＤＩＡＭＥＴＥＲを使用する。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、または代替的に８０２．１Ｘ上で、ＷｉＭＡＸ ＰＣＥＦに輸送される。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＥＡＰフレームは、Ｇｘ基準点を使用して、ＤＩＭＥＴＥＲ上でＰＣＲＦにルーティングされる。次いで、ＰＣＲＦは、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＣＲＦに搭載されるポリシー、ＳＰＲからフェッチされる加入者ポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびにＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦは、Ｇｘ上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＷｉＭＡＸ ＰＣＥＦに送信し、次いで、ＷｉＭＡＸ ＰＣＥＦが、ＩＰ上のＩＫＥｖ２上でＵＥに輸送されるＥＡＰで、ＵＥに転送する。

図１１は、ＵＥが、ＤＯＣＳＩＳ ＩＰ−ＣＡＮを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＤＯＣＳＩＳ ＩＰ−ＣＡＮにおいて、各ＵＥは、ハイブリッド同軸ファイバ（ＨＦＣ）アクセスネットワークを通してケーブルモデム終端システム（ＣＭＴ）に接続されるケーブルモデム（ＣＭ）を介して、ネットワークに接続される。ＵＥおよびＣＭは、同じ物理パッケージ内に埋め込まれる場合があるが、それらは別個の論理デバイスのままである。１つ以上のＵＥは、単一のＣＭの範囲を定めてもよい。ＣＭＴＳは、ＩＰ接続およびトラフィックスケジューリングを提供し、ＣＭおよびその範囲を定めるＵＥに対するサービスの質を管理するので、ＣＭＴＳは、ＤＯＣＳＩＳ ＩＰ−ＣＡＮに対するＰＣＥＦの役割を果たす。ＤＯＣＳＩＳ ＩＰ−ＣＡＮにおいて、アプリケーションマネージャ（ＡＭ）およびポリシーサーバ（ＰＳ）は、ＰＣＲＦの役割を果たす。

ＤＯＣＳＩＳ ＩＰ−ＣＡＮを介してリソースにアクセスする時、リソースを要求するために、Ｒｘインターフェースを使用することができる。Ｒｘインターフェースは、ＤＩＡＭＥＴＥＲを使用する。ＡＭとＰＳとＣＭＴＳとの間の通信は、ＣＯＰＳに基づき、かつＪ．１７９に定義される、ＰＫＴ−ＭＭ−２インターフェースを使用する。ＣＯＰＳは、ＩＰ上で動作して、キー管理のためのＩＫＥまたはＫｅｒｂｅｒｏｓを使用する、ＩＰｓｅｃ ＥＳＰを使用する。

ＰＫＴ−ＭＭ−２インターフェースは、Ｇｘインターフェースの機能を実施するが、ＤＩＡＭＥＴＥＲではなくＣＯＰＳを使用する。ＤＯＣＳＩＳシステムは、３ＧＰＰ ＰＣＣの完全な実装例を表していないが、それにインターフェースすることができる。

ＤＯＣＳＩＳは、ＵＥがＡＭと相互作用することを可能にするように、およびＱｏＳリソースを直接的に要求および管理するのを可能にするように、ＵＥとＡＭとの間のｍｍ−７インターフェースを定義した。このインターフェースは、まだパケットケーブルによって標準化されていない。

ＥＡＰフレームは、潜在的に、ＡＭに、およびＡＭを介してＰＳに到達するように、ｍｍ−７上で送信され得る。代替的に、ＤＯＣＳＩＳは、別の８０２．１ｘの実装例であるので、ＥＡＰフレームは、ＣＭＴＳに到達するように、８０２．１ｘで送信することができ、次いで、ＰＫＴ−ＭＭ−２上のＣＯＰＳプロトコルは、ＲＡＤＩＵＳ属性としてＥＡＰフレームを中継するために使用することができる。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ｍｍ−７を使用して、ＩＰ上のＩＫＥｖ２上で、ＰＣＲＦ／ＡＭに輸送される。次いで、ＰＣＲＦ（ＡＭおよびＰＳ）は、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒに含有されるＰｏｌｉｃｙＩｎｆｏ、ＰＳに搭載されるポリシー、Ｒｘを介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびにＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＰＣＲＦ／ＡＭは、ｍｍ−７を介して、またはＣＯＰＳおよび８０２．１ｘを介して、ＩＰ上のＩＫＥｖ２上でＵＥに輸送される、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージで、メディアポリシー文書を送信する。

図１２は、ＵＥが、ＴＩＳＰＡＮ ＮＡＳＳ／ＲＡＣＳを使用する時に、セッションポリシー要求がどのように扱われる場合があるのかという実施例を示す。ＴＩＳＰＡＮ ＮＧＮは、３ＧＰＰ ＰＣＣを使用しない。ＴＩＳＰＡＮ ＮＧＮでは、ＮＡＳＳ（ネットワークアタッチメントサブシステム）およびＲＡＣＳ（リソースおよび承認制御サブシステム）がある。ＲＡＣＳは、アクセスおよび集合ネットワークにおけるリソース予約および承認制御を含む、ポリシング制御の要素に関与する。ＲＡＣＳは、ポリシーベースの輸送制御サービスをアプリケーションに提供する。これらのサービスは、アプリケーションが、ＲＡＣＳの範囲内の輸送ネットワークから輸送リソースを要求および予約することを可能にする。ＲＡＣＳは、ＳＰＤＦおよびＡ−ＲＡＣＦから成る。

ＳＰＤＦは、Ｐ−ＣＳＣＦから受信するリソース予約要求を調整する、機能要素である。ＳＰＤＦが実施する機能のうちの１つは、Ｐ−ＣＳＣＦから受信した要求情報が、ＳＰＤＦで定義されるポリシー規則と一致しているかどうかを決定することである。ＳＰＤＦはまた、ＳＩＰセッションに対する要求されたリソースを認可する。そのようにするために、ＳＰＤＦは、Ｐ−ＣＳＣＦから受信した要求情報を使用して適切な認可を計算する（すなわち、特定のメディア構成要素を認可する）。加えて、ＳＰＤＦは、所望の輸送能力に従って、Ａ−ＲＡＣＦの場所を提供し、Ａ−ＲＡＣＦのリソースを要求し、制御アーキテクチャからＲＡＣＳの詳細およびコア輸送層を隠蔽し、かつアプリケーション機能からの要求を適切なＡ−ＲＡＣＦに向けてマッピングすることによって、リソース調停を提供する。

Ａ−ＲＡＣＦは、承認制御およびネットワークポリシーアセンブリを提供する、機能要素である。承認制御の場合、Ａ−ＲＡＣＦは、ＳＰＤＦからＱｏＳリソースに対する要求を受信し、受信したＱｏＳ情報を使用して承認制御を実施する。次いで、リソースに対する要求が許可されるかどうかをＳＰＤＦに示す。

アクセスネットワークポリシーは、アクセス回線に適用されるべきであるポリシーを明記した、一組の規則である。ネットワークポリシーアセンブリの場合、Ａ−ＲＡＣＦは、複数のＳＰＤＦがＡ−ＲＡＣＦからリソースを要求できるので、ＳＰＤＦからの要求がアクセスポリシーに整合することを確実にする。Ａ−ＲＡＣＦはまた、リソースを要求したＳＰＤＦからの要求を組み合わせて、要求の合計がアクセス回線の能力に整合することを確実にする。

ＳＰＤＦは、Ｒｑインターフェースを通して、アクセスネットワークのリソースに対する要求を発行する。これらの要求は、ＩＰ ＱｏＳ特性を示す。Ａ−ＲＡＣＦは、承認制御を実施するためにＩＰ ＱｏＳ情報を使用し、Ｒｑインターフェースを通して、その承認制御決定をＳＰＤＦに示す。Ｒｑインターフェースは、ＤＩＡＭＥＴＥＲを使用する。ＲＡＣＳは、３ＧＰＰ ＰＣＣ ＰＣＲＦと類似したポリシー制御機能を実施する。Ｐ−ＣＳＣＦは、ＲＡＣＳと通信するためにＧｑ’を使用し、Ｇｑ’は、ＤＩＡＭＥＴＥＲを使用する。Ｇｑ’は、類似した機能を３ＧＰＰ ＰＣＣのＲｘに提供する。

３ＧＰＰ ＰＣＣのゲートウェイと同等であるＩＰエッジルータは、ＡＣＥＦ（アクセス制御施行機能）を含有するが、これは、３ＧＰＰ ＰＣＣのＰＣＥＦと同等の機能を実施する。ＲＡＣＳとＡＣＥＦとの間のＲｅインターフェースは、まだ標準化されていない。ＩＰエッジルータはまた、ＡＭＦ（アクセス管理機能）を含有するが、これは、ＮＡＳＳ（技術的に、ＡＭＦは、ＮＡＳＳの一部である）にインターフェースする、ＲＡＤＩＵＳクライアントである。ＡＭＦは、ＵＥによって送信されたネットワークアクセス要求を翻訳し、ＩＰアドレスおよびネットワークの割り当てのための要求を送り、そして、ユーザ認証要求をユーザアクセス認可機能（ＵＡＡＦ）に転送する。逆方向において、ＡＭＦは、ＮＡＳＳ内のＵＡＡＦ（ユーザアクセス認可機能）からＵＥに応答を送る。

ＮＡＳＳは、ＴＩＳＰＡＮ ＮＧＮサービスへのアクセスのための、アクセスレベルでの登録、およびユーザ機器の初期化を提供する。ＮＡＳＳは、ネットワークレベル識別および認証を提供し、アクセスネットワークのＩＰアドレス空間を管理し、かつアクセスセッションを認証する。ＮＡＳＳは、また、ＴＩＳＰＡＮ ＮＧＮサービス／アプリケーションサブシステムのコンタクト点をユーザ機器に通知する。ＮＡＳＳを介したネットワークアタッチメントは、暗示的または明示的なユーザ識別、およびＮＡＳＳに記憶される認証証明書に基づく。ＮＡＳＳ内には、ここでは関連しない他の機能とともに、ＵＵＡＦおよびＣＬＦ（接続性セッション位置およびリポジトリ機能）がある。ＵＡＡＦは、ユーザ認証および認可チェックを実施する。ＵＡＡＦは、プロファイルデータベース機能（ＰＤＢＦ）に含有されるユーザプロファイルから、ユーザ認証およびアクセス認可情報を読み出す。ＵＡＡＦはまた、請求のためのアカウンティングデータを収集する。ＣＬＦは、ＵＥに割り当てられたＩＰアドレス、関連するネットワーク位置情報、およびＮＡＣＦによって提供される地理的位置情報を登録し、全ての情報を関連付ける。ＣＬＦは、ユーザの識別、ユーザネットワークのＱｏＳプロファイル、および位置情報のユーザプライバシー設定を記憶する。ＣＬＦは、高レベルのサービスのための場所クエリー機能を提供する。ＣＬＦは、ＲＡＣＳ内で、ｅ４インターフェースを介して、Ａ−ＲＡＣＦと通信する。ｅ４インターフェースは、ＤＩＡＭＥＴＥＲを使用する。インターフェースａ３は、ＡＭＦとＵＡＡＦとの間で使用される。それは、ＡＭＦが、ユーザを認証して、ネットワークサブスクリプション情報を確認するようにＵＡＡＦに要求することを可能にする。インターフェースａ４は、ＵＡＡＦとＣＬＦとの間で使用される。それは、ＵＡＡＦが、プッシュモードにおいて、ユーザ識別と位置情報のユーザプライバシー設定との関係、ならびにユーザネットワークプロファイル情報（例えば、ＱｏＳプロファイル）を登録するようにＣＬＦに要求することを可能にする。インターフェースａ４は、ＣＬＦが、プルモードで、ＵＡＡＦからユーザネットワークプロファイルへのクエリーを行うことを可能にする。インターフェースａ３およびａ４は、現在、標準化されていない。

このアクセスネットワークシナリオにおいて、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＵＥからのＥＡＰフレームは、ＩＰ上のＩＫＥｖ２上で、ＩＰエッジルータに輸送される。次いで、ポリシーチャネルＩｎｆｏＯｆｆｅｒおよびＩｎｆｏＡｎｓｗｅｒメッセージを含有するＥＡＰフレームは、ａ３インターフェースを使用して、ＲＡＤＩＵＳ上で、ＮＡＳＳ（ＵＵＡＦ）にルーティングされる。次いで、ＮＡＳＳ（ＵＵＡＦ）は、ＲＡＤＩＵＳ（ａ４）およびＤＩＡＭＥＴＥＲ（ｅ４）を使用して、ＲＡＣＳ（Ａ−ＲＡＣＦ）に転送される。次いで、ＲＡＣＳ（Ａ−ＲＡＣＦおよびＳＰＤＦ）は、ＵＥからのＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージに含有されるＰｏｌｉｃｙＩｎｆｏ、ＳＰＤＦに搭載されるポリシー、Ｇｑ’を介してＰ−ＣＳＣＦによって搭載されるサービスに基づく認可ポリシー、ならびにＵＥが使用しているアクセスネットワークの知識およびその利用可能なリソースに基づいて、メディアポリシー文書を生成する。ＲＡＣＳ（Ａ−ＲＡＣＦ）は、ｅ４上で、ＥＡＰフレームのＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージでメディアポリシー文書をＮＡＳＳに送信し、該ＮＡＳＳは、ａ４およびａ３上で、ＲＡＤＩＵＳを使用して該文書をＩＰエッジルータに転送し、次いで、該ルータが、ＩＰ上のＩＫＥｖ２上でＵＥに輸送されるＥＡＰで、ＵＥに転送する。

図１３は、セッションポリシー要求をネットワーク構成要素に送信するための方法４００の実施形態を例証する。ブロック４１０で、ＵＡは、ＥＡＰプロトコル、または、これに限定されないが、アクティブＰＤＰコンテキスト等の類似したプロトコルを使用して、セッションポリシー要求をネットワーク構成要素に送信する。ネットワーク構成要素は、ポリシーサーバ、認証サーバ、ポリシー制御および課金規則機能、サブスクリプションプロファイルリポジトリ、ポリシー制御および施行機能、ネットワークアクセスサーバ、ゲートウェイ、ルータ、ＣＳＣＦ（例えば、Ｐ−ＣＳＣＦまたはＳ−ＣＳＣＦ）等のＳＩＰプロキシ、または類似した構成要素である場合がある。ある場合には、セッションポリシー要求は、これらの構成要素のうちの他方で終端する前に、これらの構成要素のうちの１つ以上を通過する場合がある。

ある場合には、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５で定義されるＳＩＰおよびＳＩＰＳ ＵＲＩスキームのみを理解する、既存のＳＩＰユーザエージェントとの下位互換性を確保するように、１つ以上の新しいＵＲＩスキームが、既存のポリシーコンタクトヘッダとともに使用される場合がある。ある実施形態において、新しいＵＲＩスキームは、ＳＩＰまたはＳＩＰＳ ＵＲＩに加えて、ポリシーサーバの新しい代替の非ＳＩＰ ＵＲＩ（例えば、ＡＡＡ ＵＲＩ）を加えることによって、ポリシーコンタクトヘッダの中に含まれる。例えば、代替のＵＲＩは次のようになり得る。

ポリシーコンタクト：ｓｉｐ：：ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ、
ａａａ：／／ｐｃｒｆ．ｅｘａｍｐｌｅ．ｃｏｍ；ａｌｔ−ｕｒｉ＝ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
上述の実施例は、実際には、２つのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩが、ポリシー文書を得るように異なるプロトコルをポリシーチャネルに使用する、同じポリシーサーバの代替のＵＲＩである。これは、ＵＲＩが、どちらもコンタクトする必要がある２つの異なるポリシーサーバについて明記される場合がある、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５における最先端の技術と対比することができる。

パラメータ（ここでは、ａｌｔ−ｕｒｉパラメータとして示される）は、同じポリシーサーバのＳＩＰ ＵＲＩに含有されるホスト名を含有することによって、それが、他のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩ（ｓｉｐ：：ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ）における同じポリシーサーバの代替のＵＲＩであることを示す。既存のＳＩＰ ＵＡが、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５において命令された時に、それらが理解しないｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩ ＵＲＩスキームを無視するものと仮定すると、セッションポリシーをサポートする全てのＵＡは、ポリシー文書を得るために、ＳＩＰおよびＳＩＰＳスキームをサポートすることが必要である場合がある。ＳＩＰおよびＳＩＰＳ ＵＲＩスキームのみをサポートするＵＡは、他のＵＲＩスキームを使用するｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを無視する。新しいＵＲＩスキームおよびａｌｔ−ｕｒｉタグを理解およびサポートするＵＡは、ａａａ：／／ｐｃｒｆ．ｅｘａｍｐｌｅ．ｃｏｍが、代替のＵＲＩであること、またはｓｉｐ：ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍで同じポリシーサーバのアドレスであることを理解する。

パラメータ「ａｌｔ−ｕｒｉ」は、１つのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩが、別のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩの代替のＵＲＩであることを示すために使用され、パラメータの名前が、異なる実施形態では異なり得ることを当業者は理解すべきである。他の可能な実施形態は、パラメータの値として、ホスト名を含有し得ない。それらは、ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩの索引を含むＳＩＰ ＵＲＩまたは他の何らかの通知を含有し得る。例えば、「１」は、第１のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを示し得、または、パラメータ「ｐｒｅｖ」は、以前のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを示し得る。

別の可能な実施形態において、パラメータは、複数のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩが、同じポリシーサーバのためのものであることを示すラベルを含有し得る。例：
ポリシーコンタクト：ｓｉｐ：：ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ；ラベル＝”Ａ”、
ａａａ：／／ｐｃｒｆ１．ｅｘａｍｐｌｅ１．ｃｏｍ；ラベル＝”Ａ”、
ｓｉｐ：：ｈｏｓｔ２．ｅｘａｍｐｌｅ２．ｃｏｍ；ラベル＝”Ｂ”、
ａａａ：／／ｐｃｒｆ２．ｅｘａｍｐｌｅ２．ｃｏｍ；ラベル＝”Ｂ”
別の可能な実施形態において、ＳＩＰ ＵＡは、単純に、ＵＲＩのホスト名のドメイン名部分または完全修飾ドメイン名（ＦＱＤＮ）を比較し、それらが同じである場合、ＵＡは、それらが、同じポリシーサーバに対する異なるｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩであると想定する。同じポリシーサーバに対する代替のｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩがある場合、ＳＩＰ ＵＡは、ポリシーサーバにコンタクトするために、どのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを使用するのかを決定することができる。

図１４は、ＵＡがネットワーク内でセッションポリシーにアクセスするための方法５００の実施形態を例証する。ブロック５１０で、ＵＡは、応答メッセージのヘッダフィールドで、ポリシーサーバに対する複数のＵＲＩを受信する。

ＤＩＡＭＥＴＥＲまたはＲＡＤＩＵＳに基づいて、３ＧＰＰ ＰＣＣアーキテクチャは、ポリシーサーバの間でのドメイン間の通信をサポートする。ＩＭＳセッションでは、４つものドメイン（Ｏｒｉｇｉｎａｔｉｎｇ Ｖｉｓｉｔｅｄ、Ｏｒｉｇｉｎａｔｉｎｇ Ｈｏｍｅ、Ｔｅｒｍｉｎａｔｉｎｇ Ｈｏｍｅ、およびＴｅｒｍｉｎａｔｉｎｇ Ｖｉｓｉｔｅｄ）が、（さらに、場合により、トランジットネットワークが含まれる場合も）セッションセットアップの際に関与する可能性がある。これらのドメインのそれぞれは、潜在的に、セッション（メディアタイプ、コーデック等）に適用される、ポリシーを有し得る。

加えて、３ＧＰＰによって定義される現在のセッションポリシー機構によって、潜在的に、各ドメインの中の各プロキシは、ＳＩＰ４８８応答を伴うＳＩＰ ＩＮＶＩＴＥ要求を拒否しなければなり得ず、その結果、発呼ＵＡは、ＳＩＰ ＩＮＶＩＴＥ要求が着呼ＵＡに到達する前に、５つのＳＩＰ ＩＮＶＩＴＥ要求を送信（および４つのＳＩＰ４８８応答を受信）しなければならない。加えて、ＳＩＰサーバは、ポリシー情報を得るように、複数のポリシーサーバのうちのそれぞれにコンタクトすることを必要とする場合がある。これは、呼セットアップを遅延させ、ＵＡのバッテリを消耗させる可能性がある。

ＩＥＴＦセッションポリシーフレームワークは、セッションに適用するセッションポリシーの発信側および受信側ＵＡの両方に知らせるように、ＳＩＰプロキシのための機構を提供する。これは、それぞれが、それらのポリシーサーバのＵＲＩをポリシーコンタクトヘッダに追加することによって行われる。

ＤＩＡＭＥＴＥＲおよびＲＡＤＩＵＳは、一方のドメインの中のポリシーサーバが、他方のドメインの中のポリシーサーバ（サービスプロバイダの間で合意を受ける）と通信することを可能にする。ある実施形態において、この能力は、複数のポリシーサーバが、単一の要求を介して、他のポリシーサーバに、または階層的ツリーの中でコンタクトする第１のポリシーサーバにコンタクトすることを可能にするために使用される。例えば、ＵＡがポリシーサーバＡにコンタクトする、ポリシーサーバＡがポリシーサーバＡおよびポリシーサーバＢにコンタクトする、ポリシーサーバＢがポリシーサーバＤおよびポリシーサーバＥにコンタクトする、等である。返されたポリシー文書は、次いで、単一のポリシー文書に組み合わせられ、次いで、ＵＡに返される。これを達成するために、ＳＩＰプロキシは、そのＵＲＩがポリシーコンタクトヘッダの中に既に列記されている他のポリシーサーバが、そのドメインの中のポリシーサーバを介してコンタクトできることを、ＵＡに示す。

ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５は、次のようにポリシーコンタクトヘッダフィールドの構文を定義する。

Ｐｏｌｉｃｙ−Ｃｏｎｔａｃｔ＝”Ｐｏｌｉｃｙ−Ｃｏｎｔａｃｔ” ＨＣＯＬＯＮ ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩ
＊（ＣＯＭＭＡ ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩ）
ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩ＝（ＳＩＰ−ＵＲＩ／ＳＩＰＳ−ＵＲＩ／ａｂｓｏｌｕｔｅＵＲＩ）
［ＳＥＭＩ ”ｎｏｎ−ｃａｃｈｅａｂｌｅ”］＊（ＳＥＭＩ ｇｅｎｅｒｉｃ−ｐａｒａｍ）
ポリシーコンタクトＵＲＩは、付加的なパラメータ（ＲＦＣ３２６１で定義されるような、ｇｅｎｅｒｉｃ−ｐａｒａｍ）を可能にする。ＲＦＣ３２６１から：
ｇｅｎｅｒｉｃ−ｐａｒａｍ＝ｔｏｋｅｎ［ＥＱＵＡＬ ｇｅｎ−ｖａｌｕｅ］
ｇｅｎ−ｖａｌｕｅ＝ｔｏｋｅｎ／ｈｏｓｔ／ｑｕｏｔｅｄ−ｓｔｒｉｎｇ
ｈｏｓｔ＝ｈｏｓｔｎａｍｅ／ＩＰｖ４ａｄｄｒｅｓｓ／ＩＰｖ６ｒｅｆｅｒｅｎｃｅ
ｈｏｓｔｎａｍｅ＝＊（ｄｏｍａｉｎｌａｂｅｌ”．”）ｔｏｐｌａｂｅｌ”．”］
ｄｏｍａｉｎｌａｂｅｌ＝ａｌｐｈａｎｕｍ
／ａｌｐｈａｎｕｍ＊（ａｌｐｈａｎｕｍ／”−”）ａｌｐｈａｎｕｍ
ｔｏｐｌａｂｅｌ＝ＡＬＰＨＡ／ＡＬＰＨＡ＊（ａｌｐｈａｎｕｍ／”−”）ａｌｐｈａｎｕｍ
したがって、上述のバッカス−ナウア記法を使用して、以下のポリシーコンタクトヘッダを構築することができる。

ポリシーコンタクト：＜ａａａ：／／ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ：１８１３＞、
＜ａａａ：／／ｈｏｓｔ２．ｅｘａｍｐｌｅ２．ｃｏｍ：３８６８、＞；ｐｒｏｘｙ−ｔｏ＝ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ、
＜ａａａ：／／ｈｏｓｔ３．ｅｘａｍｐｌｅ３．ｃｏｍ：１７２７＞；＞；
ｐｒｏｘｙ−ｔｏ＝ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ；ｐｒｏｘｙ−ｔｏ＝ｈｏｓｔ２．ｅｘａｍｐｌｅ２．ｃｏｍ
上述の例では、ドメインｅｘａｍｐｌｅ１．ｃｏｍに対するＳＩＰプロキシは、そのポリシーサーバＵＲＩ「ａａａ：／／ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ：１８１３」を含んでいた。次いで、ドメインｅｘａｍｐｌｅ２．ｃｏｍに対するＳＩＰプロキシは、そのポリシーサーバＵＲＩ「ａａａ：／／ｈｏｓｔ２．ｅｘａｍｐｌｅ２．ｃｏｍ：３８６８」を追加し、ｅｘａｍｐｌｅ１．ｃｏｍに対するポリシーサーバが、そのポリシーサーバを介して到達できるものと決定して、ｅｘａｍｐｌｅ１．ｃｏｍ（ｈｏｓｔ１．ｅｘａｍｐｌｅ１．ｃｏｍ）に対するポリシーサーバのホスト名と同等であるパラメータ「ｐｒｏｘｙ−ｔｏ」セットをそのように追加する。同様に、ドメインｅｘａｍｐｌｅ３．ｃｏｍに対するＳＩＰプロキシは、そのポリシーサーバＵＲＩ「ａａａ：／／ｈｏｓｔ３．ｅｘａｍｐｌｅ３．ｃｏｍ：１７２７」を追加し、ｅｘａｍｐｌｅ１．ｃｏｍに対するポリシーサーバおよびｅｘａｍｐｌｅ２．ｃｏｍに対するポリシーサーバが、そのポリシーサーバを介して到達できるものと決定して、ｅｘａｍｐｌｅ１．ｃｏｍに対するホスト名と同等に設定されるパラメータ「ｐｒｏｘｙ−ｔｏ」、およびｅｘａｍｐｌｅ２．ｃｏｍに対するポリシーサーバのホスト名と同等に設定される第２の「ｐｒｏｘｙ−ｔｏ」パラメータをそのように追加する。

ＵＡは、上述のポリシーコンタクトヘッダを含有するＳＩＰ ＩＮＶＩＴＥ要求またはＳＩＰ４８８応答を受信する時に、ＵＲＩのリストを走査する。リストの中のＵＲＩが、ポリシーコンタクトヘッダの中の他のＵＲＩの中に現れる１つ以上のホスト名またはドメイン名を含有する、１つ以上のｐｒｏｘｙ−ｔｏパラメータと関連した場合、ＵＡは、ＥＡＰ ＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒの書式作成をする時に、そのホスト名またはドメイン名が、ポリシーコンタクトヘッダに列記されるそのＵＲＩと関連付けられる、ｐｒｏｘｙ−ｔｏパラメータの中に現れるポリシーコンタクトヘッダからのポリシーサーバのＡＡＡ ＵＲＩを含有する、Ａｌｓｏ−ｃｏｎｔａｃｔパラメータ等の、パラメータを含む。ＥＡＰ ＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージはまた、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｍｅｄｉａ−ｐｏｌｉｃｙ−ｄａｔａｓｅｔ−０６で定義される、意図するオファーまたはアンサーを含む。

第１のポリシーサーバは、Ａｌｓｏ−Ｃｏｎｔａｃｔパラメータを含有するＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージを含有する、ポリシーチャネルメッセージを受信する時、ＤＩＡＭＥＴＥＲ要求を、Ａｌｓｏ−Ｃｏｎｔａｃｔパラメータで定義されるポリシーサーバ宛てに送り、要求の中のＡｌｓｏ−Ｃｏｎｔａｃｔパラメータの中に、任意のｐｒｏｘｙ−ｔｏパラメータからのＵＲＩを含む。

第１のポリシーサーバは、他のポリシーサーバからポリシー文書を受信する時、それ自体のポリシー文書とともに、全ての受信したポリシー文書を単一のポリシー文書に構成し、それを、ＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージで、要求元に返す。第１のポリシーサーバはまた、ＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージの中のポリシーコントリビュータパラメータで、含有するポリシー文書に寄与する、全てのポリシーサーバの全てのＡＡＡ ＵＲＩを含む。

ＵＡは、ＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージを受信する時、ポリシーコントリビュータパラメータを確認し、ポリシー文書が、ＥＡＰ ＩｎｆｏＯｆｆｅｒまたはＩｎｆｏＡｎｓｗｅｒメッセージで示された、全てのポリシーサーバからのポリシーを表すことを確実にする。ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙによれば、「発見されたポリシーサーバのうちの１つに対するポリシーチャネルのセットアップが失敗した場合、ＵＡは、このポリシーサーバにコンタクトせずにセッションの開始を継続し得る」とある。しかしながら、ポリシーサーバがコンタクトされなかった場合、ＵＡは、ＳＩＰリクエストまたは応答の中のポリシーＩＤヘッダに、そのポリシーサーバのＵＲＩを含まない。ＵＡは、それらのポリシーサーバがポリシー文書に寄与したという確認を受信したポリシーサーバのみを含む。

代替的に、ＵＡは、上述の統合されたアプローチを使用する代わりに、ＥＡＰ／ＡＡＡインフラストラクチャを使用して、個々に並行して全てのポリシーサーバにコンタクトすることができる。

別の実施形態では、Ｐ−ＣＳＣＦもしくは他のＳＩＰプロキシ（例えば、Ｓ−ＣＳＣＦ等）は、ポリシーサーバが、他のポリシーを得ることができるように、またはＰ−ＣＳＣＦもしくは他のＳＩＰプロキシ（例えば、Ｓ−ＣＳＣＦ等）自体が、他のポリシーサーバ（例えば、ＳＩＰベースのポリシーチャネル、ＤＩＡＭＥＴＥＲ、またはＲＡＤＩＵＳ等）からポリシー文書を得て、次いで、そのポリシー文書をそれらのポリシーサーバに提供し得るように、他のポリシーサーバのポリシーコンタクトＵＲＩのそれらのポリシーサーバを上流側に知らせるために、Ａｌｓｏ−Ｃｏｎｔａｃｔパラメータを使用してもよい。次いで、ポリシーサーバは、他のポリシーサーバのポリシーの集約に基づいて、集約したポリシー文書を作成し、ＵＡがポリシーチャネル上でポリシー文書を要求した時に、集約したポリシー文書をＵＡに提供する。ポリシーサーバはまた、ＰｏｌｉｃｙＯｆｆｅｒまたはＰｏｌｉｃｙＡｎｓｗｅｒメッセージの中のポリシーコントリビュータパラメータで、含有するポリシー文書に寄与する、全てのポリシーサーバの全てのＡＡＡ ＵＲＩを含んでもよい。

ＡＡＡ ＵＲＩが、簡単にするために上記のように使用されているが、ＵＡまたはＳＩＰプロキシ（Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ等）が、ＥＡＰ／ＤＩＭＥＴＥＲ／ＲＡＤＩＵＳインフラストラクチャ上でポリシーサーバにコンタクトすることを可能にする、あらゆるＵＲＩスキームが十分である際には、ＵＲＩスキームの実際の構文は、上述の実施形態に関連しない。

図１５は、異なるドメインの中の複数のＰＣＲＦが、ＤＩＡＭＥＴＥＲを使用してどのように相互接続され得るのか（ＲＡＤＩＵＳを使用しても類似した接続が提供され得る）、および異なるドメインの中の複数のＳＩＰプロキシ（Ｐ−ＣＳＣＦおよびＳ−ＣＳＣＦ）が、返されるポリシーへのセッションベースの入力をそれらのＰＣＲＦにどのように提供し得るのかを示す。例えば、ユーザのホームネットワークにおけるＳ−ＣＳＣＦは、ＳＩＰ要求に含まれるＩＭＳ通信サービス識別子に基づくポリシーに影響を与え得る。

この技術を使用して、単一のセッションポリシー要求を第１のポリシーサーバに対して行うことができ、そのポリシーサーバは、セッションポリシー要求を他のポリシーサーバに中継することができる。次いで、第１のポリシーサーバは、他のポリシーサーバからのポリシー文書を集約し、単一のポリシー文書をＵＡに配信することができる。より具体的には、ある実施形態において、ＤＩＡＭＥＴＥＲおよびＲＡＤＩＵＳプロトコルは、ＡＡＡサーバ（ポリシーサーバ等）が、ドメイン全体に相互にインターフェースすることを可能にするので、単一のポリシーサーバは、単一のポリシーチャネルの交換の際にＳＩＰセッションが横断する複数のドメインから、ポリシーの複合ポリシーを供給することができる。ポリシーチャネル機構には、既存の３ＧＰＰ ＰＣＣ機構およびＤＩＡＭＥＴＥＲまたはＲＡＤＩＵＳベースのポリシーサーバにインターフェースする、ＩＥＴＦセッションポリシーフレームワークに基づくことが望ましい場合がある。

図１６は、ＵＡがネットワーク内でセッションポリシーにアクセスするための方法６００の実施形態を例証する。ブロック６１０で、ＵＡは、単一のネットワーク構成要素に対する単一のセッションポリシー要求を介して、複数のネットワーク構成要素にコンタクトする。

代替の実装例において、ＳＩＰ ＵＡが、例えばＩＭＳネットワークといったＳＩＰインフラストラクチャからサービスを得ることを望む時、ＳＩＰ ＵＡは、これに限定されないが、ＳＩＰ ＲＥＧＩＳＴＥＲ等のメッセージを送信する。ネットワークノードが、Ｓ−ＣＳＣＦ初期フィルタ基準（ｉＦＣ）トリガ等の、このＳＩＰ ＲＥＧＩＳＴＥＲを受信する時、これに限定されないが、ＳＩＰサーバまたはポリシーサーバであり得る、別のネットワークノードに対して第３者登録が行われる。ＳＩＰサーバは、ＳＩＰ ＵＡによって必要とされるセッションポリシー情報を含有する、ノードである。次いで、ＳＩＰサーバは、ＳＩＰプッシュ、ＳＭ、ＵＳＳＤ、Ｃｅｌｌｂｒｏａｄｃａｓｔ、またはＭＢＭＳを介して、ポリシー情報をＳＩＰ ＵＡに送信する。上述の実施例において、ポリシー情報は、独自にコード化される場合があり、またはＯＭＡ ＤＭ管理オブジェクトである場合がある。

ＳＩＰ ＲＥＧＩＳＴＲＡＴＩＯＮは、常時起こり得、ＳＩＰ ＵＡは、それが無線アクセス技術を変化させる、またはその能力を変化させる時に、それが登録を実施するように提供され得る。この登録情報は、前述のようにＳＩＰサーバによって受信された時に、ポリシー情報の更新をトリガすることができる。この更新は、ＳＩＰ ＵＡ能力等の新しい情報、または場合により第３者登録の際に、もしくは登録イベントパッケージに加入するＳＩＰサーバを介して送信され得る、ｐ−Ｎｅｔｗｏｒｋ−Ａｃｃｅｓｓ−ｉｎｆｏヘッダ情報に基づく場合がある。

別の実施形態では、ＳＩＰ ＲＥＧＩＳＴＲＡＴＩＯＮおよび第３者レジスタは、ＳＩＰサーバが、ＳＩＰにメッセージを送信し、ＥＡＰフレーム要求を実施して、ポリシー情報の収集をもたらすようにトリガしてもよい。

さらに別の実施形態では、Ｓ−ＣＳＣＦ等のネットワークノードが２００ＯＫを返信する時、この２００ＯＫは、ポリシー情報を含有し得、またはポリシー情報が得られ得る場所を指すＵＲＬを含有し得る。ＵＲＬは、ＳＩＰヘッダの中に含有され得る、またはＸＭＬに埋め込まれ得るが、これに限定されない。

さらに別の実施形態では、Ｓ−ＣＳＣＦ／レジストラは、ＲＥＧＩＳＴＥＲへのＳＩＰ ２００ＯＫで、ポリシー文書へのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダを返してもよい。ＳＩＰ ＲＥＧＩＳＴＥＲの経路上の、Ｐ−ＣＳＣＦ等の他のＳＩＰプロキシは、それ自体のポリシーサーバのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを、ＳＩＰ ＲＥＧＩＳＴＥＲに対するＳＩＰ ２００ＯＫの中に直接的に、またはＳＩＰ ＲＥＧＩＳＴＥＲ自体の中に直接的に含有する、それら自体のポリシーコンタクトヘッダを含んでもよい。ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩがＳＩＰ ＲＥＧＩＳＴＥＲの中に含まれる場合、Ｓ−ＣＳＣＦ／レジストラまたは他のプロキシは、次いで、直接的にポリシー文書を得て、それ自体のサーバにそれを提供して、集約したポリシー文書を生成するか、または、前述の機構を使用して、ポリシーサーバによって集約したポリシー文書を生成できるように、他のポリシーサーバのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを提供する。ＳＩＰレジスタで受信されるポリシーコンタクトヘッダはまた、ＳＩＰ ＲＥＧＩＳＴＥＲに対するＳＩＰ ２００ＯＫの中でＳＩＰ ＵＡ提供されてもよい。

ｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩが代替のＵＲＩ（例えば、ａｌｔ−ｕｒｉパラメータ）であり、ポリシー文書を別のポリシー（例えば、ｐｒｏｘｙ−ｔｏパラメータ）を介して得ることができることを識別するための前述の機構はまた、ＳＩＰ ＵＡが、複数のポリシーサーバにコンタクトしなければならないというのではなく、前述の機構を使用したポリシーチャネルを使用して単一のポリシーサーバのみにコンタクトすればよい、効率的な手法で、集約したポリシーを得ることを可能にするように、ＳＩＰ ＲＥＧＩＳＴＥＲおよびＳＩＰ ２００ＯＫとともに使用することができる。

ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５は、現在、ＳＩＰ ＲＥＧＩＳＴＥＲまたはＳＩＰ ２００ＯＫで使用されているポリシーコンタクトヘッダを定義していないので、この実施形態は、ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５へのＳＩＰの拡張として実装することができる。この拡張のためのサポートを示すために、ＳＩＰ ＵＡは、ＳＩＰ ＲＥＧＩＳＴＥＲ要求の中のオプションタグ「ポリシー」等のオプションタグを含有する、サポートされたヘッダを含むことができる。このオプションタグに基づいて、プロキシ、Ｓ−ＣＳＣＦ／レジストラ、および／または第３者登録を介したアプリケーションサーバは、ＳＩＰ ＵＡが、ＳＩＰ ＲＥＧＩＳＴＥＲに対するＳＩＰ ２００ＯＫの中のポリシーコンタクトヘッダの受信をサポートすることを決定することができる。

さらに別の実施形態では、ＵＡは、第１の認可タイプのメッセージをネットワークに送信することができ、第１の認可タイプは、ＥＡＰ、ＧＲＰＳアクティブＰＤＰコンテキスト、またはＳＩＰ ＲＥＧＩＳＴＥＲであり得るが、これに限定されない。第１の認可タイプのメッセージ内では、ＳＩＰ ＵＡ等の情報、ＩｎｆｏＯｆｆｅｒ情報、およびパブリックユーザ識別等の加入者の識別を識別する、一組のパラメータを示すことができる。当業者は、一組という用語が、一群の明確かつ相異なるオブジェクトであり、これらの明確かつ相異なるオブジェクトまたは情報要素の数は、ゼロから多数であることができることを認識されるであろう。以下は、ＵＡからネットワークへのそのようなメッセージの実施例である。

ＥＡＰコード：１（要求）
タイプ：１２５＊ＳｅｓｓｉｏｎＰｏｌｉｃｙ
長さ：変数
値：
［ＮＡＩ］
［インフォオファー］
［インフォアンサー］
＜ＭＩＣ＞
ＮＡＩは、ネットワークで認証するように、ＵＡによって使用される識別子である。識別の形式は、ＲＦＣ４２８２で定義される。ＮＡＩコンテンツは、ポリシー要求を適切なポリシーサーバにルーティングするために、ＡＡＡサーバ（ＲＡＤＩＵＳまたはＤＩＡＭＥＴＥＲ）によって使用される。ＥＡＰ「タイプ」はまた、ＥＡＰコンテンツをルーティングするために使用されてもよい。

第１の認可タイプメッセージは、これに限定されないが、ＡＡＡサーバ、ＧＧＳＮ、またはＣＳＣＦであり得る、ネットワークノードによって受信することができる。このネットワークノードは、一組の第１の認可タイプの情報を取り込み、それを、これに限定されないが、ＲＡＤＩＵＳ、ＤＩＡＭＥＴＥＲ、またはＳＩＰ ＲＥＧＩＳＴＥＲであり得る、第２の認可タイプのメッセージの中に入れることができる。第１の下位層メッセージは、その全体が第２の下位層の中に配置され得る。この第２の下位層メッセージは、必要なポリシー情報を第１のネットワークノードに返すことができる、第２のネットワークノードに送信することができる。第１のネットワークノードは、逆翻訳を行い、第１の認可タイプの肯定応答をポリシー情報を含有するＵＡに返信することができる。以下は、ネットワークからＵＡへのそのようなメッセージの実施例である。

ＥＡＰコード：２（応答）
タイプ：１２５＊ＳｅｓｓｉｏｎＰｏｌｉｃｙ
長さ：変数
値：
［ＮＡＩ］
［ポリシーオファー］
［ポリシーアンサー］
＜ＭＩＣ＞
ポリシーオファー、ポリシーアンサー、インフォオファー、およびインフォアンサーは、
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｍｅｄｉａ−ｐｏｌｉｃｙ−ｄａｔａｓｅｔ−０６．ｔｘｔで定義される。

認証のために使用されるＥＡＰ方法（ＥＡＰ−ＳＩＭまたはＥＡＰ−ＡＫＡ）が、ＥＡＰキーイングフレームワーク（ＲＦＣ５２４７）に準拠している場合、偽造および反射攻撃に対してセッションポリシー要求／応答を保護するために、ＭＩＣを使用することができる。代替的に、セッションポリシー要求／応答は、共有キーで保護され得る。

図１７は、ＵＡがネットワーク内でセッションポリシーにアクセスするための方法７００の実施形態を例証する。ブロック７１０で、ＵＡは、登録メッセージを第１のネットワークノードに送信する。ブロック７２０で、ＵＡは、ポリシー関連情報を受信する。

前述のＵＡ１１０および他の構成要素は、前述の作用に関する命令を実行する処理構成要素を含む場合がある。図１８は、本明細書に開示される１つ以上の実施形態を実装するために好適な処理構成要素１３１０を含む、システム１３００の実施例を例証する。プロセッサ１３１０（中央プロセッサユニットまたはＣＰＵと称され得る）に加えて、システム１３００は、ネットワーク接続デバイス１３２０と、ランダムアクセスメモリ（ＲＡＭ）１３３０と、読取専用メモリ（ＲＯＭ）１３４０と、二次記憶装置１３５０と、入力／出力（Ｉ／Ｏ）デバイス１３６０とを含む場合がある。これらの構成要素は、バス１３７０を介して相互に通信する場合がある。ある場合には、これらの構成要素のうちのいくつかは、存在しなくてもよく、または相互の組み合わせ、もしくは図示されない他の構成要素との種々の組み合わせとして、組み合わされてもよい。これらの構成要素は、単一の物理エンティティ内、または２つ以上の物理エンティティ内に位置する場合がある。プロセッサ１３１０によって講じられていると本明細書に記載するいずれの措置も、プロセッサ１３１０のみ、または、デジタル信号プロセッサ（ＤＳＰ）１３８０等の、図中に示される、もしくは示されない１つ以上の構成要素と協働するプロセッサ１３１０によって講じられる場合がある。ＤＳＰ１３８０は、別個の構成要素として示されているが、ＤＳＰ１３８０は、プロセッサ１３１０に組み込まれる場合がある。

プロセッサ１３１０は、それがネットワーク接続デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または二次記憶装置１３５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等、種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、またはスクリプトを実行する。１つのＣＰＵ１３１０のみが示されているが、複数のプロセッサが存在してもよい。したがって、命令が、プロセッサによって実行されているように述べられ得るが、命令は、同時に、順次、あるいは別様に１つまたは複数のプロセッサによって実行されてもよい。プロセッサ１３１０は、１つ以上のＣＰＵチップとして実装されてもよい。

ネットワーク接続デバイス１３２０は、モデム、モデムバンク、イーサネット（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）無線送受信機デバイス等の無線送受信機デバイス、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ）デバイス、デジタル加入者回線（ｘＤＳＬ）デバイス、データオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）モデム、および／またはネットワークに接続するための他の公知のデバイスの形態を成してもよい。これらのネットワーク接続性デバイス１３２０によって、プロセッサ１３１０が、情報を受信する場合があるか、またはプロセッサ１３１０が情報を出力する場合がある、インターネット、あるいは１つ以上の電気無線通信ネットワークまたは他のネットワークと、プロセッサ１３１０が通信することを可能にしてもよい。

また、ネットワーク接続デバイス１３２０は、無線周波数信号またはマイクロ波周波数信号等の電磁波の形態で、データを無線で送信および／または受信することが可能な１つ以上の送受信機構成要素１３２５も含む場合がある。代替として、データは、導電体の表面内または上を、同軸ケーブル内、導波管内、光ファイバ等の光媒体内、あるいは他の媒体内を伝播してもよい。送受信機構成要素１３２５は、別個の受信および送信ユニット、または単一の送受信機を含んでもよい。送受信機１３２５によって送信または受信される情報は、プロセッサ１３１０によって処理されたデータ、またはプロセッサ１３１０によって実行される命令を含んでもよい。そのような情報は、例えば、コンピュータデータベースバンド信号または搬送波の中に具現化される信号の形態で、ネットワークから受信し、ネットワークに出力されてもよい。データは、データを処理または生成するか、あるいはデータを送信または受信するかのいずれかに対して、望ましいとされ得る、異なるシーケンスに従って順序付けられてもよい。ベースバンド信号、搬送波に統合される信号、あるいは現在使用されている、または今後開発される他の種類の信号は、送信媒体と称されてもよく、当業者に周知のいくつかの方法に従って生成されてもよい。

ＲＡＭ１３３０を使用して、揮発性データ、および可能性として、プロセッサ１３１０によって実行される命令を記憶する場合がある。ＲＯＭ１３４０は、典型的には、二次記憶装置１３５０のメモリ容量より小さいメモリ容量を有する、不揮発性メモリデバイスである。ＲＯＭ１３４０を使用して、命令、および可能性として、命令の実行中に読み取られるデータを記憶する場合がある。ＲＡＭ１３３０およびＲＯＭ１３４０の両方へのアクセスは、典型的には、二次記憶装置１３３０へのアクセスよりも高速である。二次記憶装置１３５０は、典型的には、１つ以上のディスクドライブまたはテープドライブから成り、ＲＡＭ１３３０が全ての作業用データを保持するのに十分大きくない場合、データの不揮発性保存用に、またはオーバーフローデータ記憶デバイスとして使用される場合がある。二次記憶装置１３５０は、プログラムが実行用に選択される時、ＲＡＭ１３３０へロードされるプログラムを記憶するために使用されてもよい。

Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カードリーダ、紙テープ読取機、プリンタ、ビデオモニタ他の公知の入出力デバイスを含んでもよい。また、送受信機１３２５は、ネットワーク接続デバイス１３２０の構成要素である代わりに、またはそれに加えて、Ｉ／Ｏデバイス１３６０の構成要素であると見なされる場合がある。

以下のＩＥＴＦインターネットドラフトは、参照することにより、あたかもそれらの全体がここに記載されているかのように、本明細書に組み込まれる。

ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｆｒａｇｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｅｓｓｉｏｎ−ｐｏｌｉｃｙ−ｆｒａｍｅｗｏｒｋ−０５．ｔｘｔ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｆｒａｇｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｍｅｄｉａ−ｄａｔａｓｅｔ−０６．ｔｘｔ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｆｒａｇｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｃｏｎｆｉｇ−ｆｒａｍｅｗｏｒｋ−１５．ｔｘｔ
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｆｒａｇｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｐｏｌｉｃｙ−ｐａｃｋａｇｅ−０５．ｔｘｔ
また、以下の３ＧＰＰ文書も、参照することにより、あたかもそれらの全体がここに記載されているかのように、本明細書に組み込まれる。ＲＦＣ２２８４、ＲＦＣ２６６１、ＲＦＣ３２６４、ＲＦＣ３２６５、ＲＦＣ３２６１、ＲＦＣ３３１２、ＲＦＣ３５８８、ＲＦＣ４２８２、ＲＦＣ４４８２、ＲＦＣ４５６６、ＲＦＣ５１０８、ＲＦＣ５２４７、ＴＳ２３．２０３、ＴＳ２３．２２８、ＴＳ２３．２２９、およびＴＳ２４．２２９。

また、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、およびＩＥＥＥ８０２．２０も、参照することにより、あたかもそれらの全体がここに記載されているかのように、本明細書に組み込まれる。

ある実施形態では、セッションポリシー要求をネットワーク構成要素に送信するための方法を提供する。方法は、下位層プロトコルを使用して、セッションポリシー要求をネットワーク構成要素に送信する、ユーザエージェントを備える。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）と、ポイントツーポイントプロトコル（ＰＰＰ）と、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、のうちの少なくとも１つである。

代替の実施形態では、ユーザエージェントを提供する。ユーザエージェントは、下位層プロトコルを使用して、セッションポリシー要求をネットワーク構成要素に送信するように構成される、プロセッサを備える。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）と、ポイントツーポイントプロトコル（ＰＰＰ）と、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、のうちの少なくとも１つである。

代替の実施形態では、ネットワーク構成要素を提供する。ネットワーク構成要素は、下位層プロトコルに送信されるセッションポリシー要求を受信するように構成される、認証構成要素を備える。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）と、ポイントツーポイントプロトコル（ＰＰＰ）と、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、のうちの少なくとも１つである。

代替の実施形態では、ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法を提供する。方法は、応答メッセージのヘッダフィールドにおいて、ポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信する、ユーザエージェントを備え、複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する。

代替の実施形態では、ユーザエージェントを提供する。ユーザエージェントは、応答メッセージのヘッダフィールドにおいて、ネットワーク内でのセッションポリシーへのアクセスを提供するポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信するように構成される、プロセッサを備え、複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する。

代替の実施形態では、ネットワーク構成要素を提供する。ネットワーク構成要素は、ネットワーク構成要素が、応答メッセージのヘッダフィールドにおいて、ネットワーク内でセッションポリシーへのアクセスを提供することができるポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信するように構成される、プロセッサを備え、複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する。

代替の実施形態では、ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法を提供する。方法は、ユーザエージェントから、単一のセッションポリシー要求を単一のネットワーク構成要素に送信し、単一のネットワーク構成要素は、複数のネットワーク構成要素にコンタクトするステップを含み、単一のセッションポリシー要求を単一のネットワーク構成要素に送信するステップは、下位層プロトコルを利用する。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）と、ポイントツーポイントプロトコル（ＰＰＰ）と、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、のうちの少なくとも１つである。方法はさらに、ポリシー情報を集約するステップと、集約したポリシー情報をユーザエージェントに提供するステップとを含む。

代替の実施形態では、ユーザエージェントを提供する。ユーザエージェントは、単一のセッションポリシー要求の送信に応答する複数のネットワーク構成要素に関する、集約したポリシー情報を受信するように構成される、プロセッサを備え、ユーザエージェントは、下位層プロトコルを利用して、セッションポリシー要求を単一のネットワーク構成要素に送信する。下位層プロトコルは、拡張認証プロトコル（ＥＡＰ）と、ポイントツーポイントプロトコル（ＰＰＰと、汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、のうちの少なくとも１つである。

代替の実施形態では、ネットワーク構成要素を提供する。ネットワーク構成要素は、単一のセッションポリシー要求を受信し、かつ複数のネットワーク構成要素からのポリシー情報の集約に応答するように構成され、さらに、集約したポリシー情報を送信するように構成される。ネットワーク構成要素は、拡張認証プロトコル（ＥＡＰ）、ポイントツーポイントプロトコル（ＰＰＰ）、および汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストのうちの少なくとも１つである下位層プロトコルを介して、ユーザエージェントからセッションポリシー要求を受信する。

代替の実施形態では、ユーザエージェントがネットワーク内でセッションポリシーにアクセスする方法を提供する。方法は、登録メッセージを第１のネットワークノードに送信する、ユーザエージェントを備える。方法はさらに、登録メッセージに応答して、第１のネットワークノードからポリシー関連情報を受信する、ユーザエージェントを備える。ポリシー関連情報は、セッションポリシーと、セッションポリシーを指すユニフォームリソースロケータと、ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、のうちの１つである。

代替の実施形態では、ユーザエージェントを提供する。ユーザエージェントは、ユーザエージェントが、登録メッセージを送信し、登録メッセージに応答して、第１のネットワークノードからポリシー関連情報を受信するように構成される、プロセッサを備える。ポリシー関連情報は、ユーザエージェントが通信することができるネットワークのためのセッションポリシーと、セッションポリシーを指すユニフォームリソースロケータと、ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、のうちの１つである。

代替の実施形態では、ネットワークノードを提供する。ネットワークノードは、ネットワークノードが、登録メッセージの受信に応答して、ポリシー関連情報をユーザエージェントに送信するように構成される、プロセッサを備える。ポリシー関連情報は、ネットワークノードが構成要素であるネットワークのためのセッションポリシーと、セッションポリシーを指すユニフォームリソースロケータと、ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、のうちの１つである。

これらの論題に関する付加的な情報は、Ａｎｄｒｅｗ Ａｌｌｅｎ他によって２００８年２月１８日に出願された、米国暫定特許出願第６１／０２９，５２２号、名称「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｎｄｉｃａｔｉｎｇ Ｓｕｐｐｏｒｔｅｄ Ｓｅｓｓｉｏｎ Ｐｏｌｉｃｙ ＵＲＩ Ｓｃｈｅｍｅｓ Ｅｘｔｅｎｓｉｏｎｓ」、およびＡｎｄｒｅｗ Ａｌｌｅｎ他によって２００８年２月１８日に出願された、米国暫定特許出願第６１／０２９，５２３号、名称「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｒｅｓｏｌｖｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ ｔｈｅ ＳＩＰ Ｓｅｓｓｉｏｎ Ｐｏｌｉｃｙ Ｆｒａｍｅｗｏｒｋ」に見出すことができ、どちらも参照することにより本明細書に組み込まれる。

本開示において複数の実施形態を提供してきたが、開示されたシステムおよび方法は、本発明の精神または範囲から逸脱することなく、多数の他の特定の形態で具体化されてもよいことを理解されたい。本実施例は、制限的ではなく例証的と見なされ、本明細書で提供される詳細に限定されることを意図しない。例えば、種々の要素または構成要素を、別のシステムに組み入れるか、または一体化してもよく、あるいは、ある特徴を省略するか、または実装しなくてもよい。

また、離散したものまたは別個のものとして種々の実施形態の中で説明および例証される技術、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わせても、または一体化してもよい。連結もしくは直接連結または相互に通信するように図示または説明される他のアイテムは、電気的、機械的、またはその他の方法かどうかにかかわらず、何らかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結または通信してもよい。変更、置換、および改変の他の例は、当業者により解明可能であり、本明細書で開示される精神および範囲から逸脱することなく行うことができる。

Claims (93)

1. セッションポリシー要求をネットワーク構成要素に送信するための方法であって、
   下位層プロトコルを使用して、前記セッションポリシー要求を前記ネットワーク構成要素に送信する、ユーザエージェントを備え、前記下位層プロトコルは、
   拡張認証プロトコル（ＥＡＰ）と、
   ポイントツーポイントプロトコル（ＰＰＰ）と、
   汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと
   のうちの少なくとも１つである、方法。
2. 前記ネットワーク構成要素は、
   ポリシーサーバと、
   認証サーバと、
   ポリシー制御および課金規則機能と、
   ポリシー制御および施行機能と、
   ネットワークアクセスサーバと、
   ゲートウェイと、
   ルータと
   のうちの少なくとも１つである、請求項１に記載の方法。
3. 前記セッションポリシー要求は、前記ユーザエージェントと前記ネットワーク構成要素との間の中間構成要素を通過し、前記中間構成要素は、
   ゲートウェイと、
   アクセスポイントと、
   ネットワークアクセスサーバと
   のうちの少なくとも１つである、請求項１に記載の方法。
4. 前記ユーザエージェントは、
   汎用パケット無線サービス（ＧＰＲＳ）と、
   グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）と、
   ＧＳＭ進化型高速データレート（ＥＤＧＥ）と、
   ＵＭＴＳ（汎用モバイル通信システム）地上無線アクセスネットワーク（ＵＴＲＡＮ）と、
   進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）、
   第３世代パートナーシッププロジェクト（３ＧＰＰ）ＵＴＲＡＮと、
   ３ＧＰＰ２符号分割多重アクセス（ＣＤＭＡ）と、
   ８０２．１１無線ローカルエリアネットワーク（ＷＬＡＮ）と、
   ８０２．１６無線メトロポリタンエリアネットワーク（ＷＭＡＮ）と、
   ８０２．２０無線広域ネットワーク（ＷＷＡＮ）と、
   ８０２．２２地域無線ネットワーク（ＷＲＡＮ）と、
   データオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）と、
   プロトコルのｘＤＳＬファミリを含む、高度なネットワークのための電気通信およびインターネット集中サービスおよびプロトコル（ＴＩＳＰＡＮ）と、
   のうちの少なくとも１つを備える、接続アクセスネットワークを介して、前記中間構成要素に接続する、請求項３に記載の方法。
5. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと前記中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
   ＤＩＡＭＥＴＥＲプロトコルと、
   ＲＡＤＩＵＳプロトコルと、
   のうちの少なくとも１つを使用して、前記中間構成要素と前記ネットワーク構成要素との間で前記セッションポリシー要求を輸送する、請求項３に記載の方法。
6. 前記少なくとも１つの下位層プロトコルの中のタイプ・長さ・値構造能力は、前記セッションポリシーを表すために使用される、請求項１に記載の方法。
7. 前記ネットワーク構成要素は、前記セッションポリシー要求に応答して、ポリシー文書を前記ユーザエージェントに提供し、前記ポリシー文書は、そのサイズを減少させるように、２進数に変換される、請求項１に記載の方法。
8. 前記ユーザエージェントは、前記ユーザエージェントによって受信されるセッション開始プロトコル（ＳＩＰ）の中のユニフォームリソース識別子（ＵＲＩ）を使用して、前記ネットワーク構成要素にコンタクトする、請求項１に記載の方法。
9. 前記ＵＲＩは、前記ＳＩＰメッセージのポリシーコンタクトヘッダの中にある、請求項８に記載の方法。
10. 前記ユーザエージェントは、単一のネットワーク構成要素に送信される単一のセッションポリシー要求を介して、複数のネットワーク構成要素にコンタクトし、前記単一のネットワーク構成要素は、前記ネットワーク構成要素の残りにコンタクトし、前記ネットワーク構成要素の前記残りからポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項８に記載の方法。
11. ネットワーク構成要素に対するセッションポリシー要求のためのユーザエージェントであって、
    下位層プロトコルを使用して、前記セッションポリシー要求を前記ネットワーク構成要素に送信するように構成される、プロセッサを備え、前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    ユーザエージェント。
12. 前記ネットワーク構成要素は、
    ポリシーサーバと、
    認証サーバと、
    ポリシー制御および課金規則機能と、
    ポリシー制御および施行機能と、
    ネットワークアクセスサーバと、
    ゲートウェイと、
    ルータと、
    のうちの少なくとも１つである、
    請求項１１に記載のユーザエージェント。
13. 前記セッションポリシー要求は、前記ユーザエージェントと前記ネットワーク構成要素との間の中間構成要素を通過し、前記中間構成要素は、
    ゲートウェイと、
    アクセスポイントと、
    ネットワークアクセスサーバと、
    のうちの少なくとも１つである、
    請求項１１に記載のユーザエージェント。
14. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと前記中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
    ＤＩＡＭＥＴＥＲプロトコルと、
    ＲＡＤＩＵＳプロトコルと、
    のうちの少なくとも１つを使用して、前記中間構成要素と前記ネットワーク構成要素との間で前記セッションポリシー要求を輸送する、
    請求項１３に記載のユーザエージェント。
15. 前記ユーザエージェントは、
    汎用パケット無線サービス（ＧＰＲＳ）と、
    グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）と、
    ＧＳＭ進化型高速データレート（ＥＤＧＥ）と、
    ＵＭＴＳ（汎用モバイル通信システム）地上無線アクセスネットワーク（ＵＴＲＡＮ）と、
    進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）と、
    第３世代パートナーシッププロジェクト（３ＧＰＰ）ＵＴＲＡＮと、
    ３ＧＰＰ２符号分割多重アクセス（ＣＤＭＡ）と、
    ８０２．１１無線ローカルエリアネットワーク（ＷＬＡＮ）と、
    ８０２．１６無線メトロポリタンエリアネットワーク（ＷＭＡＮ）と、
    ８０２．２０無線広域ネットワーク（ＷＷＡＮ）と、
    ８０２．２２地域無線ネットワーク（ＷＲＡＮ）と、
    データオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）と、
    プロトコルのｘＤＳＬファミリを含む、高度なネットワークのための電気通信およびインターネット集中サービスおよびプロトコル（ＴＩＳＰＡＮ）と、
    のうちの少なくとも１つを備える、接続アクセスネットワークを介して、前記中間構成要素に接続する、
    請求項１３に記載のユーザエージェント。
16. 前記少なくとも１つの下位層プロトコルの中のタイプ・長さ・値構造能力は、前記セッションポリシーを表すために使用される、請求項１１に記載のユーザエージェント。
17. 前記ネットワーク構成要素は、前記セッションポリシー要求に応答して、ポリシー文書を前記ユーザエージェントに提供し、前記ポリシー文書は、そのサイズを減少させるように、２進数に変換される、請求項１１に記載のユーザエージェント。
18. 前記ユーザエージェントは、前記ユーザエージェントによって受信されるセッション開始プロトコル（ＳＩＰ）の中のユニフォームリソース識別子（ＵＲＩ）を使用して、前記ネットワーク構成要素にコンタクトする、請求項１１に記載のユーザエージェント。
19. 前記ＵＲＩは、前記ＳＩＰメッセージのポリシーコンタクトヘッダの中にある、請求項１８に記載のユーザエージェント。
20. 前記ユーザエージェントは、単一のネットワーク構成要素に送信される単一のセッションポリシー要求を介して、複数のネットワーク構成要素にコンタクトし、前記単一のネットワーク構成要素は、前記ネットワーク構成要素の残りにコンタクトし、前記ネットワーク構成要素の前記残りからポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項１８に記載のユーザエージェント。
21. セッションポリシーを提供するためのネットワーク構成要素であって、
    下位層プロトコルに送信されるセッションポリシー要求を受信するように構成される、認証構成要素を備え、前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    ネットワーク構成要素。
22. 前記認証構成要素は、
    ポリシーサーバと、
    認証サーバと、
    ポリシー制御および課金規則機能と、
    ポリシー制御および施行機能と、
    ネットワークアクセスサーバと、
    ゲートウェイと、
    ルータと、
    のうちの少なくとも１つである、
    請求項２１に記載のネットワーク構成要素。
23. 前記セッションポリシー要求は、中間構成要素を通してユーザエージェントから前記ネットワーク構成要素に移り、前記中間構成要素は、
    ゲートウェイと、
    アクセスポイントと、
    ネットワークアクセスサーバと、
    のうちの少なくとも１つである、
    請求項２１に記載のネットワーク構成要素。
24. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと前記中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
    ＤＩＡＭＥＴＥＲプロトコルと、
    ＲＡＤＩＵＳプロトコルと、
    のうちの少なくとも１つを使用して、前記中間構成要素と前記ネットワーク構成要素との間で前記セッションポリシー要求を輸送する、
    請求項２３に記載のネットワーク構成要素。
25. 前記ユーザエージェントは、
    汎用パケット無線サービス（ＧＰＲＳ）と、
    グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）と、
    ＧＳＭ進化型高速データレート（ＥＤＧＥ）と、
    ＵＭＴＳ（汎用モバイル通信システム）地上無線アクセスネットワーク（ＵＴＲＡＮ）と、
    進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）と、
    第３世代パートナーシッププロジェクト（３ＧＰＰ）ＵＴＲＡＮと、
    ３ＧＰＰ２符号分割多重アクセス（ＣＤＭＡ）と、
    ８０２．１１無線ローカルエリアネットワーク（ＷＬＡＮ）と、
    ８０２．１６無線メトロポリタンエリアネットワーク（ＷＭＡＮ）と、
    ８０２．２０無線広域ネットワーク（ＷＷＡＮ）と、
    ８０２．２２地域無線ネットワーク（ＷＲＡＮ）と、
    データオーバーケーブルサービスインターフェース仕様（ＤＯＣＳＩＳ）と、
    プロトコルのｘＤＳＬファミリを含む、高度なネットワークのための電気通信およびインターネット集中サービスおよびプロトコル（ＴＩＳＰＡＮ）と、
    のうちの少なくとも１つを備える、接続アクセスネットワークを介して、前記中間構成要素に接続する、
    請求項２３に記載のネットワーク構成要素。
26. 前記少なくとも１つの下位層プロトコルの中のタイプ・長さ・値構造能力は、前記セッションポリシーを表すために使用される、請求項２１に記載のネットワーク構成要素。
27. 前記認証構成要素は、前記セッションポリシー要求に応答して、ポリシー文書を前記ユーザエージェントに提供し、前記ポリシー文書は、そのサイズを減少させるように、２進数に変換される、請求項２１に記載のネットワーク構成要素。
28. 前記ユーザエージェントによって受信されるセッション開始プロトコル（ＳＩＰ）の中のユニフォームリソース識別子（ＵＲＩ）を使用して、前記認証構成要素にコンタクトする、請求項２１に記載のネットワーク構成要素。
29. 前記ＵＲＩは、前記ＳＩＰメッセージのポリシーコンタクトヘッダの中にある、請求項２８に記載のネットワーク構成要素。
30. 前記ユーザエージェントは、単一の認証構成要素に送信される単一のセッションポリシー要求を介して、複数の認証構成要素にコンタクトし、前記単一の認証構成要素は、前記認証構成要素の残りにコンタクトし、前記認証構成要素の前記残りからポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項２８にネットワーク構成要素。
31. ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法であって、
    応答メッセージのヘッダフィールドにおいて、ポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信する、前記ユーザエージェントを備え、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する、
    方法。
32. 第１のＵＲＩは、セッション開始プロトコル（ＳＩＰ）ベースのＵＲＩおよびＳＩＰセキュリティＵＲＩ（ＳＩＰＳ ＵＲＩ）のうちの１つであり、第２のＵＲＩは、異なるプロトコルを伴う別の種類のＵＲＩであり、前記第２のＵＲＩおよび前記第１のＵＲＩは、同じポリシーサーバを参照する、請求項３１に記載の方法。
33. 前記ユーザエージェントは、一組のＵＲＩの間で複数のＵＲＩパラメータの値を比較し、前記パラメータ値が、前記一組のＵＲＩの２つ以上のＵＲＩパラメータの間で同一である時、前記値は、同じポリシーサーバを示す、請求項３２に記載の方法。
34. 前記パラメータの前記値は、
    前記ポリシーサーバのホスト名と、
    前記ポリシーサーバのドメイン名と、
    前記ＳＩＰベースのＵＲＩと、
    前記ＳＩＰＳ ＵＲＩと、
    前記ＵＲＩのうちの１つと関連付けられる索引と、
    前記ＵＲＩのうちの１つと関連付けられるラベルと、
    のうちの少なくとも１つである、
    請求項３３に記載の方法。
35. 複数のＵＲＩを識別し、
    前記ＵＲＩの共通パラメータに基づいて、前記ＵＲＩに含有される値を決定し、
    ポリシー情報を得るように、前記ＵＲＩの前記値のうちの１つを選択する、
    前記ユーザエージェントをさらに備える、
    請求項３１に記載の方法。
36. 前記ユーザエージェントは、ポリシーチャネルプロトコルを使用して、前記ポリシーサーバから前記ポリシー情報を要求する、請求項３５に記載の方法。
37. 前記ポリシーチャネルプロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    請求項３６に記載の方法。
38. ユーザエージェントであって、
    前記ユーザエージェントが、応答メッセージのヘッダフィールドにおいて、ネットワーク内でのセッションポリシーへのアクセスを提供するポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信するように構成される、プロセッサを備え、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する、
    ユーザエージェント。
39. 第１のＵＲＩは、セッション開始プロトコル（ＳＩＰ）ベースのＵＲＩおよびＳＩＰセキュリティＵＲＩ（ＳＩＰＳ ＵＲＩ）のうちの１つであり、第２のＵＲＩは、異なるプロトコルを伴う別の種類のＵＲＩであり、前記第２のＵＲＩおよび前記第１のＵＲＩは、同じポリシーサーバを参照する、請求項３８に記載のユーザエージェント。
40. 前記ユーザエージェントは、一組のＵＲＩの間で複数のＵＲＩパラメータの値を比較し、前記パラメータ値が、前記一組のＵＲＩの２つ以上のＵＲＩパラメータの間で同一である時、前記値は、同じポリシーサーバを示す、請求項３９に記載のユーザエージェント。
41. 前記パラメータの前記値は、
    前記ポリシーサーバのホスト名と、
    前記ポリシーサーバのドメイン名と、
    前記ＳＩＰベースのＵＲＩと、
    前記ＳＩＰＳ ＵＲＩと、
    前記ＵＲＩのうちの１つと関連付けられる索引と、
    前記ＵＲＩのうちの１つと関連付けられるラベルと、
    のうちの少なくとも１つである、
    請求項４０に記載のユーザエージェント。
42. 複数のＵＲＩを識別し、
    前記ＵＲＩの共通パラメータに基づいて、前記ＵＲＩに含有される値を決定し、
    ポリシー情報を得るように、前記ＵＲＩの前記値のうちの１つを選択する、
    前記ユーザエージェントをさらに備える、
    請求項３８に記載のユーザエージェント。
43. 前記ユーザエージェントは、ポリシーチャネルプロトコルを使用して、前記ポリシーサーバから前記ポリシー情報を要求する、請求項４２に記載のユーザエージェント。
44. 前記ポリシーチャネルプロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    請求項４３に記載のユーザエージェント。
45. ネットワーク構成要素であって、
    前記ネットワーク構成要素が、応答メッセージのヘッダフィールドにおいて、ネットワーク内でのセッションポリシーへのアクセスを提供することができるポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を送信するように構成される、プロセッサを備え、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用する、
    ネットワーク構成要素。
46. 第１のＵＲＩは、セッション開始プロトコル（ＳＩＰ）ベースのＵＲＩおよびＳＩＰセキュリティＵＲＩ（ＳＩＰＳ ＵＲＩ）のうちの１つであり、第２のＵＲＩは、異なるプロトコルを伴う別の種類のＵＲＩであり、前記第２のＵＲＩおよび前記第１のＵＲＩは、同じポリシーサーバを参照する、請求項４５に記載のネットワーク構成要素。
47. 前記第１のＵＲＩおよび前記第２のＵＲＩは、
    前記ポリシーサーバのホスト名と、
    前記ポリシーサーバのドメイン名と、
    前記ＳＩＰベースのＵＲＩと、
    前記ＳＩＰ ＵＲＩと、
    前記ＵＲＩのうちの１つと関連付けられる索引と、
    前記ＵＲＩのうちの１つと関連付けられるラベルと、
    のうちの少なくとも１つを共通して有することによって、同じポリシーサーバを参照するものとして指定される、
    請求項４６に記載のネットワーク構成要素。
48. ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法であって、
    前記ユーザエージェントから、単一のセッションポリシー要求を単一のネットワーク構成要素に送信するステップであって、前記単一のネットワーク構成要素は、複数のネットワーク構成要素にコンタクトする、ステップであって、前記単一のセッションポリシー要求を前記単一のネットワーク構成要素に送信するステップは、下位層プロトコルを利用し、前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、ステップと、
    ポリシー情報を集約するステップと、
    前記集約したポリシー情報を前記ユーザエージェントに提供するステップと、
    を含む、方法。
49. 前記集約したポリシー情報は、前記単一のネットワーク構成要素で決定される、請求項４８に記載の方法。
50. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
    ＤＩＡＭＥＴＥＲプロトコルと、
    ＲＡＤＩＵＳプロトコルと、
    のうちの少なくとも１つを使用して、前記中間構成要素と前記単一のネットワーク構成要素との間で前記セッションポリシー要求を輸送する、
    請求項４８に記載の方法。
51. 前記セッションポリシー要求は、ＰＲＯＸＹ−ＴＯパラメータを含み、前記ＰＲＯＸＹ−ＴＯパラメータは、前記ネットワーク構成要素の残りのうちの１つ以上を示す、少なくとも１つのＵＲＩを含む、請求項４８に記載の方法。
52. ポリシーサーバの間でプロトコルを利用する、前記ネットワーク構成要素間での前記集約したポリシー情報の送信をさらに備える、請求項４８に記載の方法。
53. 前記単一のネットワーク構成要素は、
    ポリシーサーバと、
    認証サーバと、
    ポリシー制御および課金規則機能と、
    ポリシー制御および施行機能と、
    ネットワークアクセスサーバと、
    ゲートウェイと、
    ルータと、
    のうちの少なくとも１つである、
    請求項４８に記載の方法。
54. ユーザエージェントであって、
    単一のセッションポリシー要求を送信するステップに応答して、複数のネットワーク構成要素に関する集約したポリシー情報を受信するように構成される、プロセッサを備え、前記ユーザエージェントは、下位層プロトコルを利用して、前記セッションポリシー要求を単一のネットワーク構成要素に送信し、前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    ユーザエージェント。
55. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
    ＤＩＡＭＥＴＥＲプロトコルと、
    ＲＡＤＩＵＳプロトコルと、
    のうちの少なくとも１つを使用して、前記中間構成要素と単一のネットワーク構成要素との間で前記セッションポリシー要求を輸送する、
    請求項５４に記載のユーザエージェント。
56. 前記セッションポリシー要求は、ＰＲＯＸＹ−ＴＯパラメータを含み、前記ＰＲＯＸＹ−ＴＯパラメータは、前記ネットワーク構成要素の残りを示す、少なくとも１つのＵＲＩを含む、請求項５４に記載のユーザエージェント。
57. ポリシーサーバの間でプロトコルを利用する、前記ネットワーク構成要素間での前記集約したポリシー情報の送信をさらに含む、請求項５４に記載のユーザエージェント。
58. ネットワーク構成要素であって、
    単一のセッションポリシー要求を受信するように構成され、かつ複数のネットワーク構成要素からのポリシー情報の集約に応答し、さらに、前記集約したポリシー情報を送信するように構成される、プロセッサを備え、前記ネットワーク構成要素は、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである下位層プロトコルを介して、ユーザエージェントから前記セッションポリシー要求を受信する、
    ネットワーク構成要素。
59. 前記少なくとも１つの下位層プロトコルは、前記ユーザエージェントと中間構成要素との間で前記セッションポリシー要求を輸送するために使用され、少なくとも１つの下位層プロトコルフレームは、
    ＤＩＡＭＥＴＥＲプロトコルと、
    ＲＡＤＩＵＳプロトコルと、
    のうちの少なくとも１つを使用して、前記中間構成要素と前記ネットワーク構成要素との間で前記セッションポリシー要求を輸送する、
    請求項５８に記載のネットワーク構成要素。
60. 前記ネットワーク構成要素は、
    ポリシーサーバと、
    認証サーバと、
    ポリシー制御および課金規則機能と、
    ポリシー制御および施行機能と、
    ネットワークアクセスサーバと、
    ゲートウェイと、
    ルータと、
    のうちの少なくとも１つである、
    請求項５８に記載のネットワーク構成要素。
61. ユーザエージェントがネットワーク内でセッションポリシーにアクセスするための方法であって、
    登録メッセージを第１のネットワークノードに送信する、前記ユーザエージェントと、
    前記登録メッセージに応答して、前記第１のネットワークノードからポリシー関連情報を受信する、前記ユーザエージェントと、を備え、前記ポリシー関連情報は、
    セッションポリシーと、
    前記セッションポリシーを指すユニフォームリソースロケータと、
    ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、
    のうちの１つである、
    方法。
62. 前記第１のネットワークノードは、
    サービング呼セッション制御機能と、
    レジストラと、
    のうちの１つである、
    請求項６１に記載の方法。
63. 登録は、前記第１のネットワークノードを介して、前記ポリシー関連情報を含有する第２のネットワークノードに対して行われ、前記ユーザエージェントは、前記第２のネットワークノードから前記ポリシー関連情報を受信する、請求項６１に記載の方法。
64. 前記第２のネットワークノードは、
    ＳＩＰサーバと、
    ポリシーサーバと、
    のうちの少なくとも１つである、
    請求項６３に記載の方法。
65. 前記ユーザエージェントは、前記ポリシー関連情報の受信をもたらす、下位層プロトコルフレーム要求を実施するように、前記第２のネットワークノードによって知らされる、請求項６３に記載の方法。
66. 前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    請求項６５に記載の方法。
67. 登録は、前記第１のネットワークノードを介して、前記ポリシー関連情報を含有する第２のネットワークノードに対して行われ、前記ユーザエージェントは、前記第１のネットワークノードから前記ポリシー関連情報を受信する、請求項６１に記載の方法。
68. 前記ユーザエージェントは、前記ポリシー関連情報の受信をもたらす、下位層プロトコルフレーム要求を実施するように、前記第１のネットワークノードによって知らされる、請求項６７に記載の方法。
69. 前記ネットワークノードは、
    ＳＩＰサーバと、
    ポリシーサーバと、
    のうちの少なくとも１つである、
    請求項６７に記載の方法。
70. 前記ユーザエージェントは、単一のネットワーク構成要素に送信されている前記登録メッセージを介して、複数のネットワーク構成要素にコンタクトし、前記単一のネットワーク構成要素は、前記ネットワーク構成要素の残りにコンタクトし、前記ネットワーク構成要素の前記残りからポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項６１に記載の方法。
71. 前記集約したポリシー情報は、ｐｒｏｘｙ−ｔｏパラメータを使用して提供される、請求項７０に記載の方法。
72. 前記ユーザエージェントは、応答メッセージのヘッダフィールドにおいて、ポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信し、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用し、前記ユーザエージェントは、前記ポリシーサーバからポリシー文書を得るために、前記複数のＵＲＩのうちのどれを使用するのかを決定する、請求項６１に記載の方法。
73. 前記複数のＵＲＩのうちのいずれかは、ａｌｔｅｒｎａｔｉｖｅ＿ＵＲＩパラメータで提供される、請求項７２に記載の方法。
74. ポリシーサーバの間でプロトコルを利用する、ネットワーク構成要素間での集約したポリシー情報の送信をさらに含む、請求項６１に記載の方法。
75. ユーザエージェントであって、
    前記ユーザエージェントが、登録メッセージを送信し、前記登録メッセージに応答して、第１のネットワークノードからポリシー関連情報を受信するように構成される、プロセッサを備え、前記ポリシー関連情報は、
    前記ユーザエージェントが通信することができるネットワークのためのセッションポリシーと、
    セッションポリシーを指すユニフォームリソースロケータと、
    ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、
    のうちの１つである、
    ユーザエージェント。
76. 登録は、前記第１のネットワークノードを介して、前記ポリシー関連情報を含有する第２のネットワークノードに対して行われ、前記ユーザエージェントは、前記第２のネットワークノードから前記ポリシー関連情報を受信する、請求項７５に記載のユーザエージェント。
77. 前記ユーザエージェントは、前記ポリシー関連情報の受信をもたらす、下位層プロトコルフレーム要求を実施するように、前記第２のネットワークノードによって知らされる、請求項７６に記載のユーザエージェント。
78. 前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    請求項７７に記載のユーザエージェント。
79. 登録は、前記第１のネットワークノードを介して、前記ポリシー関連情報を含有する第２のネットワークノードに対して行われ、前記ユーザエージェントは、前記第１のネットワークノードから前記ポリシー関連情報を受信する、請求項７５に記載のユーザエージェント。
80. 前記ユーザエージェントは、前記ポリシー関連情報の受信をもたらす、下位層プロトコルフレーム要求を実施するように、前記第１のネットワークノードによって知らされる、請求項７９に記載のユーザエージェント。
81. 前記ユーザエージェントは、単一のネットワーク構成要素に送信されている前記登録メッセージを介して、複数のネットワーク構成要素にコンタクトし、前記単一のネットワーク構成要素は、前記ネットワーク構成要素の残りにコンタクトし、前記ネットワーク構成要素の前記残りからポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項７５に記載のユーザエージェント。
82. 前記集約ポリシー情報は、ｐｒｏｘｙ−ｔｏパラメータを使用して提供される、請求項８１に記載のユーザエージェント。
83. 前記ユーザエージェントは、応答メッセージのヘッダフィールドにおいて、ポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）を受信し、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用し、前記ユーザエージェントは、前記ポリシーサーバからポリシー文書を得るために、前記複数のＵＲＩのうちのどれを使用するのかを決定する、請求項７５に記載のユーザエージェント。
84. 前記複数のＵＲＩのうちのいずれかは、ａｌｔｅｒｎａｔｉｖｅ＿ＵＲＩパラメータで提供される、請求項８３に記載のユーザエージェント。
85. ネットワークノードであって、
    前記ネットワークノードが、登録メッセージの受信に応答して、ポリシー関連情報をユーザエージェントに送信するように構成される、プロセッサを備え、前記ポリシー関連情報は、
    前記ネットワークノードが構成要素であるネットワークのためのセッションポリシーと、
    前記セッションポリシーを指すユニフォームリソースロケータと、
    ポリシー文書のためのｐｏｌｉｃｙＣｏｎｔａｃｔＵＲＩを含有するポリシーコンタクトヘッダと、
    のうちの１つである、
    ネットワークノード。
86. 前記ネットワークノードは、
    サービング呼セッション制御機能と、
    レジストラと、
    のうちの１つである、
    請求項８５に記載のネットワークノード。
87. 登録は、媒介ネットワーク構成要素を介して、前記ネットワークノードに対して行われ、前記ネットワークノードは、前記ポリシー関連情報を含有する、請求項８５に記載のネットワークノード。
88. 前記ネットワークノードは、前記ポリシー関連情報の送信をもたらす、下位層プロトコルフレーム要求を実施するように、前記ユーザエージェントに知らせる、請求項８５に記載のネットワークノード。
89. 前記下位層プロトコルは、
    拡張認証プロトコル（ＥＡＰ）と、
    ポイントツーポイントプロトコル（ＰＰＰ）と、
    汎用パケット無線サービス（ＧＰＲＳ）活性化パケットデータプロトコル（ＰＤＰ）コンテキストと、
    のうちの少なくとも１つである、
    請求項８８に記載のネットワークノード。
90. 前記ネットワークノードは、ユーザエージェントから前記登録メッセージを受信すると、複数の他のネットワーク構成要素にコンタクトし、前記他のネットワーク構成要素からポリシー情報を集約し、前記集約したポリシー情報を前記ユーザエージェントに提供する、請求項８５に記載のネットワークノード。
91. 前記ネットワークノードは、応答メッセージのヘッダフィールドにおいて、ポリシーサーバのための複数のユニフォームリソース識別子（ＵＲＩ）をユーザエージェントに送信し、前記複数のＵＲＩのそれぞれは、異なるポリシーチャネルプロトコルを使用し、前記ユーザエージェントは、前記ポリシーサーバからポリシー文書を得るために、前記複数のＵＲＩのうちのどれを使用するのかを決定する、請求項８５に記載のネットワークノード。
92. 前記複数のＵＲＩのうちのいずれかは、ａｌｔｅｒｎａｔｉｖｅ＿ＵＲＩパラメータで提供される、請求項９１に記載のネットワークノード。
93. ポリシーサーバの間でプロトコルを利用する、ネットワーク構成要素間での集約したポリシー情報の送信をさらに含む、請求項８５に記載のネットワークノード。

Images