JP2012509041A - 制限付きポリシー及び課金制御ケイパビリティの検出及び報告 - Google Patents

Abstract

ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）の方法は、ネットワークインタフェースにおいてシグナリングメッセージを受信するステップを含んでいる。処理ユニットが、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するポリシー及び課金制御（ＰＣＣ）状況を、受信したメッセージから動的に検出するステップが存在する。前記検出されたＰＣＣ状況をホームアプリケーション機能（Ｈ−ＡＦ）に通知するメッセージを、前記ネットワークインタフェースから前記Ｈ−ＡＦへ送信するステップが存在し、そうすることで、Ｈ−ＡＦは、前記ＶＰＬＭＮ上でローミングしているユーザに関してサービスネゴシエーションが進行中であるかどうかを決定することができる。ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）装置を含んでいる。ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシーアプリケーション機能（Ｈ−ＡＦ）の方法を含んでいる。ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシーアプリケーション機能（Ｈ−ＡＦ）装置を含んでいる。
【選択図】 なし

Description

本発明は、ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）に関するものであり、この訪問先公衆移動体ネットワーク（ＶＰＬＭＮ）は、ＶＰＬＭＮのポリシー及び課金制御（ＰＣＣ）ケイパビリティに関するポリシー及び課金制御（ＰＣＣ）状況を動的に検出する（本明細書で使用されるように、「本発明」あるいは「発明」との参照は、例示の実施形態に関連し、かつ添付の請求項によって包含される各実施形態に必須でない）。より詳しくは、本発明は、ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）に関連し、この訪問先公衆移動体ネットワーク（ＶＰＬＭＮ）は、ＶＰＬＭＮのポリシー及び課金制御（ＰＣＣ）ケイパビリティに関するポリシー及び課金制御（ＰＣＣ）状況を動的に検出し、また、検出したＰＣＣ状況をホームアプリケーション機能（Ｈ−ＡＦ）に通知するメッセージをＨ−ＡＦへ送信する。そうすることで、Ｈ−ＡＦは、ＶＰＬＭＮでローミングしているユーザに関するサービスネゴシエーションが進行しているかどうかを決定することができる。

このセクションは、本発明の様々な態様に関連する場合がある技術の様々な態様を読者に案内することを意図している。以下の議論は、本発明のより良い理解を容易にするための情報を提供することを意図している。従って、以下の議論の記述は、このような観点で読まれるべきであり、従来技術を認定するものではないことが理解されるべきである。

ポリシー及び課金制御ＰＣＣは、３ＧＰＰリリース７で定義された。ＰＣＣアーキテクチャは、サービスデータフロー検出を提供するＰＣＲＦ（ポリシー及び課金ルール機能）と、ＰＣＥＦ（ポリシー及び課金エンフォース（執行）機能）に向けての課金制御とを含んでいる。これらの機能群は、いわゆるＰＣＣルール群によって提供される。ＰＣＣルールは、サービスデータフローの検出を実現し、かつポリシー制御及び課金制御の少なくとも一方に対するパラメータ群を提供する情報のセットである。ＰＣＲＦは、ＰＣＣルール群を生成するための入力として、Ｈ−ＡＦ（ホームアプリケーション機能）からサービス情報を受信する。ここで、ＰＣＣルール群は、ＳＤＦ（サービスデータフロー）フィルタ群とＡＤによってリクエストされる特定のサービスに対するＱｏＳ要件群を含んでいる。次に、ＰＣＣルール群は、ＰＣＥＦにインストールされ、ＰＣＥＦは、それらに、サービスデータフロー検出とポリシーエンフォースメント（enforcement：執行）を提供することを執行する。ＰＣＲＦはＰＣＣルール群をＰＣＥＦに提供する場合、ＰＣＥＦは、ＰＣＣルール内でリクエストされているＱｏＳ要件群はＲＡＮ向けの新規のベアラの確立を要求しているかを決定する。ＰＣＲＦとＰＣＥＦに対して定義される機能性は、特殊化ノード群に実装することができる、あるいは、更なる機能群を実行するノードとともに配置することができる。例えば、ＧＧＳＮのようなゲートウェイノード群、あるいは、より一般的には、ユーザ端末群用のメディアとのインタフェースを実現するゲートウェイノード群、例えば、パケットデータネットワークゲートウェイ群ノード（ＰＤＮ−ＧＷ）が、ＰＣＥＦに対して定義される執行機能群を実現することが好ましい。

３ＧＰＰリリース８は、「オフパスモデル（off-path model）」を標準化している。これは、ＰＣＣアーキテクチャ内のＢＢＥＲＦ（ベアラバインディング及びイベント報告機能（Bearer Binding and Event Reporting Function））を含み、このＰＣＣアーキテクチャは、ＧＴＰプロトコル（ＧＰＲＳトンネリングプロトコル）がサービング（在圏）ゲートウェイＳ−ＧＷとＰＤＮ−ＧＷとの間で使用されない場合に対するものである。ＢＢＥＲＦは、サービスデータフロー検出、ベアラバインディング及びイベント報告機能（イベントをＰＣＲＦへ報告する）群を提供する。このＢＢＥＲＦは、ＰＣＲＦを調停者として使用して、アクセスゲートウェイＡ−ＧＷ（ＢＢＥＲＦを含んでいる）とＰＤＮ−ＧＷ（ＰＣＥＦを含んでいる）との間でＰＣＣ情報を交換することを可能にする。このＰＣＣ情報はＧＴＰを介して搬送されるが、モビリティプロトコル群（ＤＳＭＩＰ、ＰＭＩＰｖ６及びＭＩＰｖ４）を介して転送することはできない。このモビリティプロトコル群は、リリース８改良パケットコアアーキテクチャに含まれているものである。

ＰＣＲＦは、ＰＣＣルール群を生成するための入力として、Ｈ−ＡＦからサービス情報を受信する。ＰＣＲＦは、ＰＣＣルール群をＰＣＥＦに提供し、また、ＱｏＳルール群（変更情報を含まないＰＣＣルール群のサブセット）をＢＢＥＲＦへ提供する。ＢＢＥＲＦは、ＱｏＳ要件群で、ＱｏＳルール内のＳＤＦ記述によって識別されるサービスが、ＲＡＮ向けの新規のベアラの確立を要求していることを決定する。

「オフ−パスモデル」は、Ｇｘｘと呼ばれる、ＰＣＲＦとＢＢＥＲＦとの間の新規のリファレンスポイントを配置する必要性をもたらしている。加えて、「オフパスモデル」は、Ｖ−ＰＣＲＦとＨ−ＰＣＲＦとの間でＰＣＣ情報を通信するために、Ｓ９と呼ばれる、新規のオペレータリファレンスポイントと、ＶＰＬＭＮ内にＰＣＲＦを配置する必要性をもたらしている。

ローミングの状況では、ＰＣＣがＶＰＬＭＮによってもＨＰＬＭＮによっても配置されないということが発生する場合がある。ＶＰＬＭＮがＰＣＣを配置しない状況に対しては（例えば、ＰＣＣをサポートしない非３ＧＰＰアクセスへのローミングの場合）、以下のＰＣＣ機能群（[３ＧＰＰ ＴＳ ２３．２０３ ｖ８．３．１ ポリシー及び課金制御アーキテクチャ（リリース８）]に記載される）を提供することができない。

・ＶＰＬＭＮ内の動的ＱｏＳ制御
・ＶＰＬＭＮからＨＰＬＭＮへのイベント報告

しかしながら、ＰＣＣは、依然として、ＨＰＬＭＮ内での課金目的のために使用することができる。Ｈ−ＰＣＲＦにおける及びＯＣＳにおける両方でのローカル静的コンフィグレーション（構成設定）に基づくメカニズムは、[３ＧＰＰ ＴＳ ２３．２０３ ｖ８．３．１ ポリシー及び課金制御アーキテクチャ（リリース８）]に定義されている。ローカルコンフィグレーションは、ローミング協定に基づいている。Ｈ−ＰＣＲＦは、動的ＱｏＳ制御あるいはイベント報告のどちらかをサポートしないＰＬＭＮ内で、ＵＥがローミングしていることに気づいている。ＯＣＳは、イベント報告をサポートしないＰＬＭＮ内でＵＥがローミングしていることに気づいている。図１は、ホームでルーティングされる状況での制限されたＰＣＣ配置を示している。ＶＰＬＭＮは、ＰＣＣをサポートしていない。

既存の解決策に伴う問題に関しては、本発明は、以下のローミング状況に関連している。

ＵＥはローミングしている（ＶＰＬＭＮ内で）。

・ホームでルーティングされる状況：トラフィックは、ＨＰＬＭＮへ送信される。

・ＰＣＣは、ＶＰＬＭＮ内ではなくＨＰＬＭＮ内に配置される。

・ＱｏＳ情報サポートを伴わないプロトコルは、ＵＥからＰＣＥＦへの方向で使用される（ＰＭＩＰ、ＭＩＰｖ４あるいはＤＳＭＩＰｖ６を使用するオフパスモデル）。

図２は、課題の説明及び対象とする状況を示す図である。

ローミング協定（即ち、ＵＥが現在ローミングしているＰＬＭＮ−ｉｄ）に基づいて、動的ＰＣＣがＶＰＬＭＮによってサポートされるかをＨＰＬＭＮに検出させることを可能にするために定義される静的メカニズムは、以下の問題を提示している。

・ＵＥがローミングしているＰＬＭＮの識別子は、ＨＰＬＭＮへ送信されない。ＵＥがローミングしているＰＬＭＮ−ｉｄ（ＭＣＣ＋ＭＮＣ）は、ＰＣＥＦで利用可能でない。ＰＬＭＮ−ｉｄは、ＧＴＰが使用される場合にはＰＣＥＦへ送信されるが、モビリティプロトコル群（ＰＭＩＰ、ＭＩＰｖ４あるいはＤＳＭＩＰｖ６）のいずれかを介して送信されない。静的コンフィグレーションは、その時点に対しては、ＶＰＬＭＮ識別子群に基づくことができない。そして、静的コンフィグレーションは、Ａ−ＧＷのＩＰアドレスを取得するＰＣＥＦのような他の情報に基づいている必要があり、これは、ＩＰアドレス範囲からＰＬＭＮ−ｉｄへのマッピングテーブルが存在しなければならない。

・マッピングテーブルのコンフィグレーション（構成設定）は、ＰＣＲＦのインスタンスと、ＨＰＬＭＮのＯＣＳインスタンスとの間で調整されなければならない。これは、集中化ＯＡＭシステムが、Ｈ−ＲＣＲＦとＯＣＳとを正しい情報で構成設定するためのタスクを実行することが要求されること意味する。

・同一のＰＬＭＮ内で、いくつかのＡ−ＧＷがＳ９をサポートし、かついくつかのＡ−ＧＷがまだサポートしていない配置状況では、マッピングテーブルは、かなり複雑になる。マッピングテーブルは、Ａ−ＧＷの完全なＩＰアドレスを含まなければならない場合がある。

加えて、［３ＧＰＰ ＴＳ ２３．２０３ ｖ８．３．１ ポリシー及び課金制御アーキテクチャ（リリース８）］に定義される静的コンフィグレーションメカニズムによってカバーされないＨ−ＡＦに対して基本的な問題が存在する。Ｈ−ＡＦは、Ｈ−ＰＣＲＦに提供され、かつＨ−ＡＦサービスセッションに関連付けられているＱｏＳ認可が、ネットワークを通して執行できるかどうかを把握することができないからである。Ｈ−ＡＦは、ＱｏＳ認可が首尾よく執行できる場合のように動作することになる。しかしながら、関連するＱｏＳポリシー群は、ＶＰＬＭＮに渡って通過することができないので、ＶＰＬＭＮは対応するリソース群を予約することができない。その結果、サービス配信は、ある程度の悪影響を受ける可能性がある、あるいは、オペレータとユーザとの両方に対して不完全な状況を作成して、完了することが可能でない可能性もある。

システム内のＰＣＣ機能群の制限付き配備の詳細な説明をここで提示する。Ｇｘｘ／Ｓ９がサポートされない場合、以下のＰＣＣ機能群は利用不可能となる。

・ＱｏＳ制御：サービス要件群に従って、一定のサービスセッションに対するリソース群を認可することが可能でない。

・イベント報告：ＶＰＬＭＮで検出される任意のイベントをＨ−ＰＣＲＦへ報告することが可能でない。その結果、Ｈ−ＰＣＲＦは、これらのイベントを承認することができず、また、その情報をＰＣＥＦあるいはＨ−ＡＦに報告するために、その情報に基づくポリシー決定を行うこともできない。

これらのＰＣＣ機能群の欠点は、以下の結論を持っている。

１．Ｈ−ＡＦは、動的ポリシー及び課金制御をリクエストするためにＨ−ＣＰＲＦへコンタクトすることになるが、課金制御だけが利用可能となる。

○ Ｈ−ＡＦは、そのことについて通知されず、サービス配信はオペレータの制御下とはならないが、新規のベアラをセットアップするためにはＵＥケイパビリティ群に依存することになる。

２．Ｈ−ＰＣＲＦは、Ｒｘインタフェースを介して受信されるセッション情報を適切な方法で認可することができなくなる。

○ Ｈ−ＰＣＲＦが認可されたＧＢＲについて知らないので、管理制御に基づく加入は実行されないことになる。

３．不正課金がサービスに対して適用される可能性がある。

○ ＯＣＳは、クレジット再認可あるいはイベントトリガによって、任意のＩＰ−ＣＡＮセッション変更について通知されないことになる。

４．不正ポリシー群がサービスに適用される可能性がある。

○ Ｈ−ＰＣＲＦは、クレジット再認可あるいはイベントトリガによって、任意のＩＰ−ＣＡＮセッション変更について通知されないことになる。

５．ベアラ主導ケイパビリティとＨ−ＰＣＲＦでのＢＣＭが未知である。

○ Ｈ−ＰＣＲＦは、ネットワーク主導手順がネットワーク内のすべてのノードによってサポートされるかを知ることができない。これは、このパラメータが、ＤＳＭＩＰあるいはＰＭＩＰプロトコルを介して送信されないからである。

○ Ｈ−ＰＣＲＦは、このＩＰ−ＣＡＮセッションに対して使用するためのＢＣＭを割り当てることができない。ＢＣＭがＨ−ＰＣＲＦによって設定されない場合に、どのようにしてＡ−ＧＷあるいはＵＥが反応することになるかが定義されない。

６．ネットワークによる専用ベアラ確立に対して間違った試行をする。

Ｈ−ＰＣＲＦと、オプションのＰＣＥＦ（チェーン化されている場合）とは、ネットワーク配備に関与していない。これは、間違ったエンフォースメントと不適切なポリシー決定をもたらす。

例：
この問題は、図３に示される。図３は、ホームでルーティングされる場合に関する、制限付きのＰＣＣ配備を示している。ＵＥは、非３ＧＰＰアクセスに接続する（ステップ１）。ゲートウェイ制御セッション確立手順（ステップ２）は、この場合は実行されない。これは、Ａ−ＧＷがＧｘｘインタフェースをサポートしないからである。Ａ−ＧＷは、ＰＤＮ−ＧＷに対してＵＥ−ＩＰアドレスをリクエストし（ステップ３）、ＰＤＮ−ＧＷ／ＰＣＥＦは、Ｈ−ＰＣＲＦへ、ＰＣＣルール群をリクエストするＩＰ−ＣＡＮセッション確立の表示を送信する（ステップ４）。Ｈ−ＰＣＲＦは、任意のＧｘｘ／Ｓ９セッションに関連付けられていないＧｘセッションを作成する（Ｇｘｘによる対話もＳ９による対話も受信していないからである）。ＰＣＣルール群が、ＰＤＮ−ＧＷ／ＰＣＥＦにインストールされる。ＰＤＮ−ＧＷ／ＰＣＥＦは、割り当てられたＵＥ ＩＰアドレスをＡ−ＧＷへ返信する（ステップ５）。ＱｏＳルール群プロビジョン手順がＡ−ＧＷに向けて実行されない（ステップ６）。これは、Ｇｘｘが実装されていないからである。その後、ＵＥはサービスセッションをネゴシエートし、次に、Ｈ−ＡＦは、サービスセッションに対するＰＣＣルール群を作成するＨ−ＰＣＲＦに通知する（ステップ７）。ＰＣＣルール群は、Ｇｘを介してＰＤＮ−ＧＷ／ＰＣＥＦへインストールされる（ステップ８）。ここで、ＰＣＣルール群は、サービスデータフロー検出に対する情報と、サービスデータフローの課金に対する情報を含んでいる。ＰＤＮ−ＧＷ／ＰＣＥＦは、サービスセッションが、ＮＷが送信リソース群をセットアップすることを要求しているとしても、サービスに対して新規のベアラを確立しない。この場合、Ｈ−ＡＦは、ＱｏＳ制御がＨ−ＡＦセッション群に適用されていないことを気付いていない。サービスがＵＥ主導で構成設定されている場合、端末は、セッションネゴシエーションに従ってベアラを開始することを試行することになる。この手順は、オペレータが認識することがないオペレータの制御外となり、不完全な状況を導く可能性がある。

本発明は、ＨＰＬＭＮとＶＰＬＭＮを有する電気通信ネットワークにおけるＨ−ＰＣＲＦの方法に関するものである。この方法は、ネットワークインタフェースにおいてシグナリングメッセージを受信するステップを備える。処理ユニットが、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するＰＣＣ状況を、受信したメッセージから動的に検出するステップが存在する。前記検出されたＰＣＣ状況をＨ−ＡＦに通知するメッセージを、前記ネットワークインタフェースから前記Ｈ−ＡＦへ送信するステップが存在し、そうすることで、Ｈ−ＡＦは、前記ＶＰＬＭＮ上でローミングしているユーザに関してサービスネゴシエーションが進行しているかどうかを決定することができる。

本発明は、ＨＰＬＭＮとＶＰＬＭＮを有する電気通信ネットワークにおけるＨ−ＰＣＲＦ装置に関するものである。Ｈ−ＰＣＲＦ装置は、シグナリングメッセージを送受信するネットワークインタフェースを備える。Ｈ−ＰＣＲＦ装置は、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するＰＣＣ状況を、受信したメッセージから動的に検出する処理ユニットを備える。前記ネットワークインタフェースは、前記検出されたＰＣＣ状況をＨ−ＡＦに通知するメッセージをＨ−ＡＦへ送信することで、Ｈ−ＡＦは、前記ＶＰＬＭＮ上でローミングしているユーザに関してサービスネゴシエーションが進行しているかどうかを決定することができる。

本発明は、ＨＰＬＭＮとＶＰＬＭＮを有する電気通信ネットワークにおけるＨ−ＡＦの方法に関するものである。この方法は、ネットワークインタフェースにおいて、Ｈ−ＰＣＲＦから、ＶＰＬＭＮのＰＣＣケイパビリティ群に関する検出されたＰＣＣ状況を前記Ｈ−ＡＦへ通知するメッセージを受信するステップを有する。処理ユニットが、前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に基づいて、前記ＶＰＬＭＮ上でローミングするユーザに関するサービスネゴシエーションが進行しているかどうかを決定するステップが存在する。

本発明は、ＨＰＬＭＮとＶＰＬＭＮを有する電気通信ネットワークにおけるＨ−ＡＦ装置に関するものである。Ｈ−ＡＦ装置は、Ｈ−ＰＣＲＦから、ＶＰＬＭＮのＰＣＣケイパビリティ群に関する検出されたＰＣＣ状況をＨ−ＡＦへ通知するメッセージを受信するネットワークインタフェースを備える。Ｈ−ＡＦ装置は、前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に基づいて、前記ＶＰＬＭＮ上でローミングするユーザに関するサービスネゴシエーションが進行しているかどうかを決定する処理ユニットを備える。

ＶＰＬＭＮがＰＣＣをサポートしない、ホームでルーティングされる状況での制限付きのＰＣＣ配備を示す図である。 課題の説明及び対象とする状況を示す図である。 ホームでルーティングされる場合に関係する制限付きのＰＣＣ配備を示す図である。 動的ＱｏＳをサポートしない新規のアクセスに接続するＵＥを示す図である。 ホームポリシー及び課金ルール機能のブロック図である。 ホームポリシーアプリケーション機能のブロック図である。

全体を通して、参照番号の類が同様のあるいは同一の部分を示している図面を参照して、より詳しくは、図５を参照すると、ＨＰＬＭＮとＶＰＬＭＮを有する電気通信ネットワークにＨ−ＰＣＲＦ１０が示される。Ｈ−ＰＣＲＦ１０は、シグナリングメッセージを送受信するネットワークインタフェース１４を備える。Ｈ−ＰＣＲＦ１０は処理ユニット１６を備え、これは、受信メッセージから、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するＰＣＣの状況を動的に検出する。ネットワークインタフェース１４は検出したＰＣＣの状況をＨ−ＡＦ１２に通知するメッセージをＨ−ＡＦ１２に送信することで、Ｈ−ＡＦ１２はＶＰＬＭＮでローミングしているユーザに関するサービスネゴシエーションが進行しているかどうかを決定することができる。

処理ユニット１６は、検出されたＰＣＣの状況において、ＶＰＬＭＮでローミングしているユーザに対して、完全なＰＣＣ制御あるいは制限付きのＰＣＣ制御が存在し得るか検出することができる。処理ユニット１６は、様々な情報に基づいて特定のＰＣＣの状況でサポートされているＰＣＣケイパビリティを検出することができる。この様々な情報には、Ｇｘインタフェースを介するＩＰ−ＣＡＮセッション確立の表示で受信される、インターネットプロトコル接続性アクセスネットワーク（ＩＰ−ＣＡＮ）タイプ及びモビリティプロトコルタイプについての情報、及びそのセッションに対応するゲートウェイ制御セッションの存在についての情報（即ち、関与するローミングしているユーザのＧｘセッションに関連し得るゲートウェイ制御シグナリング）がある。

ネットワークインタフェース１４は、ゲートウェイ制御シグナリングを受信する、Ｓ９インタフェースあるいはＧｘｘインタフェースの少なくともどちらかを含むことができ、処理ユニット１６は、特定のＰＣＣの状況で制限付きのＰＣＣケイパビリティ群を利用可能であるかを検出する。これは、Ｓ９あるいはＧｘｘインタフェースの使用が特定のＩＰ−ＣＡＮ／モビリティティプロトコルタイプの組み合わせに対して要求されているが、対応するゲートウェイ制御セッションシグナリングがＨ−ＰＣＲＦ１０によって受信されていない場合である。本明細書の内容において、表現「制限付きのＰＣＣケイパビリティ群が利用可能である（例えば、特定のＰＣＣの状況において）」とは、その状況において完全ではないＰＣＣケイパビリティだけが利用可能であることを意味する。例えば、動的ＱｏＳ制御及びセッション認可の少なくとも一方と、イベント報告が利用可能でないことを意味する。処理ユニット１６は、１つ以上の特定のＩＰ−ＣＡＮ／モビリティティプロトコルタイプの組み合わせに対して、Ｓ９あるいはＧｘｘインタフェースの使用がＨ−ＰＣＲＦ１０によってゲートウェイ制御セッションシグナリングを受信することが要求されているかどうかについて、内部的に構成設定されたデータを使用して確認する。ネットワークインタフェースを、対応するノード内のポリシー及び課金エンフォースメント機能（ＰＣＥＦ）に、ＶＰＬＭＮのＰＣＣケイパビリティ群に関して検出されたＰＣＣの状況を通知するメッセージを送信する。この対応するノードには、例えば、パケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）内のＰＣＥＦがある。それにより、ＰＣＥＦは、そのＶＰＬＭＮでローミングしているユーザに関して、Ｈ−ＰＣＲＦによって報告されるＰＣＣケイパビリティ群の少なくとも一部を課金システム（ＯＣＳ）に通知するための情報を取得する。

本発明は、ＨＰＬＭＮとＶＰＬＭＮとを有する電気通信ネットワークにおけるＨ−ＰＣＲＦ１０の方法に関係する。この方法は、ネットワークインタフェース１４においてシグナリングメッセージを受信するステップを有する。処理ユニット１６で受信したメッセージから、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するＰＣＣの状況を動的に検出するステップを備える。検出されたＰＣＣの状況をＨ−ＡＦ１２に通知するメッセージをネットワークインタフェース１４からＨ−ＡＦ１２へ送信するテップを有し、そうすることで、Ｈ−ＡＦ１２は、ＶＰＬＭＮでローミングしているユーザに関してサービスネゴシエーションが進行しているかどうかを決定することができる。

検出するステップは、検出されたＰＣＣの状況において、ＶＰＬＭＮでローミングしているユーザに対して完全なＰＣＣ制御あるいは制限付きのＰＣＣ制御が存在するかどうかを処理ユニット１６が検出するステップを含むことができる。例えば、検出されたＰＣＣの状況に従って、あるＶＰＬＭＮにおいてローミングしているユーザに与えられているセッションに対して、イベント報告と動的なサービス品質制御が可能であるかどうかを判定することができる。この検出するステップは、様々な情報に基づいて、特定のＰＣＣの状況でサポートされるＰＣＣケイパビリティ群を検出するステップを含むことができる。この様々な情報には、Ｇｘインタフェースを介するＩＰ−ＣＡＮセッション確立の表示で受信される、インターネットプロトコル接続性アクセスネットワーク（ＩＰ−ＣＡＮ）タイプとモビリティプロトコルタイプについての情報、及び関連しているゲートウェイ制御シグナリングの存在についての情報がある。

ゲートウェイ制御シグナリングは、Ｓ９インタフェースあるいはＧｘｘインタフェースを通じてＨ−ＰＣＲＦ１０によって受信することができ、そして、処理ユニット１６が、制限付きのＰＣＣケイパビリティが特定のＰＣＣ状況で利用可能であることを検出するステップが存在しても良く、これは、Ｓ９インタフェースあるいはＧｘｘインタフェースが特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせに対して要求されているが、対応するゲートウェイ制御シグナリングがＨ−ＰＣＲＦ１０によって受信されていない場合である。処理ユニット１６が、Ｈ−ＰＣＲＦ１０によってゲートウェイ制御セッションシグナリングを受信するためにＳ９インタフェースあるいはＧｘｘインタフェースの使用が要求されているかどうかを、１つ以上の特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプに対して、確認する、内部的に構成設定されているデータを使用するステップが存在しても良い。ＶＰＬＭＮのＰＣＣケイパビリティ群に関して検出されたＰＣＣ状況を通知するメッセージを、ネットワークインタフェース１４からポリシー及び課金エンフォースメント機能（ＰＣＥＦ）（例えば、パケットデータネットワークゲートウェイであるＰＤＮ−ＧＷ内のＰＣＥＦ）に送信するステップが存在しても良く、そうすることで、ＰＣＥＦは、そのＶＰＬＭＮ上をローミングしているユーザに関して、Ｈ−ＰＣＲＦ１０によって報告される少なくとも一部のＰＣＣケイパビリティ群について、課金システム（ＯＣＳ）に通知するための情報を取得する。

図６を参照すると、本発明は、ＨＰＬＭＮとＶＰＬＭＮとを有する電気通信ネットワークにおけるＨ−ＡＦ１２に関係する。Ｈ−ＡＦ１２は、Ｈ−ＰＣＲＦ１０からメッセージを受信するネットワークインタフェース２２を備え、このＨ−ＰＣＲＦ１０は、ＶＰＬＭＮのＰＣＣケイパビリティに関して、検出されたＰＣＣ状況をＨ−ＡＦ１２へ通知する。Ｈ−ＡＦ１２は処理ユニット２４を備え、これは、ＶＰＬＭＮ上をローミングしているユーザに関するサービスネゴシエーションが、Ｈ−ＰＣＲＦ１０からのメッセージで受信されるメッセージに基づいて進行しているかどうかを検出する。

処理ユニット２４は、Ｈ−ＰＣＲＦ１９からのメッセージで受信される情報に従って、動的なサービス品質（ＱｏＳ）が利用可能でない場合に、サービスセッションリクエストを拒否することができる。ネットワークインタフェース２２は、ＶＰＬＭＮ上でローミングしているユーザに関して、ＶＰＬＭＮのＰＣＣケイパビリティ群の変更についての通知を承認するメッセージをＨ−ＰＣＲＦ１０へ送信することができる。ネットワークインタフェース２２は、変更についての通知を承認するためのメッセージの結果として、検出されたＰＣＣ状況を通知するメッセージをＨ−ＰＣＲＦ１０から受信することができる。

本発明は、ＨＰＬＭＮとＶＰＬＭＮとを有する電気通信ネットワークにおけるＨ−ＡＦ１２の方法に関係する。この方法は、ネットワークインタフェース２２においてＨ−ＰＣＲＦ１０からメッセージを受信するステップを有し、このネットワークインタフェース２２は、ＶＰＬＭＮのＰＣＣケイパビリティ群に関して、検出されたＰＣＣ状況をＨ−ＡＦ１２へ通知する。Ｈ−ＰＣＲＦ１０からのメッセージで受信される情報に基づいて、ＶＰＬＭＮ上でローミングするユーザに関してのサービスネゴシエーションが進行しているかどうかを、処理ユニット２４で検出するステップが存在する。

サービスネゴシエーションが進行しているかどうかを処理ユニット２４で検出するステップは、Ｈ−ＰＣＲＦ１０からのメッセージで受信される情報に従って、動的なサービス品質（ＱｏＳ）が利用可能でない場合に、サービスセッションリクエストを処理ユニット２４が拒否するステップを含んでいても良い。ＶＰＬＭＮ上でローミングしているユーザに関して、ＶＰＬＭＮのＰＣＣケイパビリティ群の変更についての通知を承認するメッセージをネットワークインタレース２２からＨ−ＰＣＲＦ１０へ送信するステップが存在しても良い。受信するステップは、変更についての通知を承認するメッセージの結果として、検出されたＰＣＣ状況を通知するメッセージをＨ−ＰＣＲＦ１０から受信するステップを含むことができる。

本発明の動作においては、柔軟で／動的な検出メカニズムが提供され、そうすることで、Ｈ−ＰＣＲＦ１０が、静的な構成設定に基づいている本発明の分野の欠点を解消するＰＣＣ配備の状況（即ち、完全なＰＣＣ制御とすることができるか、あるいは制限されることになるか）を気付けるようにする。このような知識に基づいて、Ｈ−ＰＣＲＦ１０はＨ−ＡＦ１２へ通知する。そうすることで、Ｈ−ＡＦ１２は、制限付きのＰＣＣ制御でサービスネゴシエーションが進行しているか、終了しているかを決定することができる。ＰＣＥＦは、ＯＣＳに向けての特定の動作を開始しないようにするために、Ｈ−ＰＣＲＦ１０からも通知され得る。

本発明の検出メカニズムは、以下のものを含むことができる。

・静的な構成設定を必要とすることなく、Ｇｘを介する「ＩＰ−ＣＡＮセッション確立」表示で受信される（例えば、図５のステップ３）ＩＰ−ＣＡＮタイプとモビリティプロトコル情報（Ｇｘインタフェースに含まれる新規のＡＶＰ）と、ゲートウェイ制御シグナリング（Ｓ９／Ｇｘｘ）の存在（／不存在）とに基づいて、特定の配備及びローミングの場合にサポートされているＰＣＣケイパビリティ（例えば、訪問先ネットワークが動的ＱｏＳ制御をサポートしているかどうか）を検出するための、Ｈ−ＰＣＲＦ１０に対する手段。

注：従来技術では、静的な構成設定に基づく、制限付きのＰＣＣケイパビリティ群のＨ−ＰＣＲＦ１０による判定に及ぶと考えられる。

この検出の結果に基づいて、本発明は、更に、以下のものを含むことができる。

・サポートされているＰＣＣケイパビリティ群に依存する方法をプロビジョニングする、適用可能なＰＣＣルール（例えば、ＩＰ−ＣＡＮに対して選択されるＢＣＭとは無関係なく、常時、ルール群をＰＣＥＦへプッシュする）を決定するための、Ｈ−ＰＣＲＦ１０に対する手段。

・制限付きのケイパビリティについて、ＵＥ、「アプリケーション機能」Ｈ−ＡＦ１２、ＰＣＥＦ及びＯＣＳ（ＰＣＥＦ経由で）を報告するための、Ｈ−ＰＣＲＦ１０に対する手段。この報告には、以下のものが含まれる。

○ 動的ＱｏＳ制御がサポートされていないこと
○ イベント単位に基づくイベント報告が利用可能でないこと

注：従来技術では、制限付きのＰＣＣケイパビリティサポートのＯＣＳへの通知に及ぶが、静的な構成設定にのみ基づいていると考えられる。しかしながら、Ｈ−ＡＦ１２への通知は、現状では従来技術によって対応されておらず、また、制限付きのＰＣＣケイパビリティサポートの知識に基づいてＰＣＥＦでは追加的に決定はなされないと考えられる。

・新規の配備状況を適用し、そして、ＵＥへ報告することを検出するための、Ｈ−ＰＣＲＦ１０に対する手段。この報告は、以下のものが含まれる。

○ 動的ＱｏＳ制御がサポートされている。

○ イベント単位でのインベンと報告が利用可能である。

注：制限付きＰＣＣケイパビリティ群のサポートのＯＣＳ（ＰＣＥＦ経由）への通知に及ぶが、静的な構成設定にのみ基づいていると考えられる。しかしながら、従来技術は、ＰＣＥＦ、ＯＣＳ（ＰＣＥＦ経由）への通知にも、完全なＰＣＣケイパビリティ群が再度利用可能になる場合でのＨ−ＡＦ１２への通知にも及ばないと考えられる。

・Ｈ−ＰＣＲＦ１０によって報告される現在のＰＣＣ機能群／ケイパビリティ群に適切に反応するために、Ｈ−ＡＦ１２、ＯＣＳ及びＰＤＮ−ＧＷ／ＰＣＥＦに対する手順。例えば、
○ Ｈ−ＡＦ１２は、動的ＱｏＳ制御が利用可能でない場合に、サービスセッションリクエストを拒否することができる。

○ ＰＤＮ−ＧＷ／ＰＣＥＦは、ある事前に構成設定されているＰＣＣルール群に基づいてベアラ群を開始ないように自身を構成設定することができ、また、イベント報告が利用可能であるあるいは利用不可能であることをＯＣＳへ通知することができ、そうすることで、適切な課金認可をそこで実行することができる。

注：利用可能なＰＣＣケイパビリティ群の知識に基づくＨ−ＡＦ１２とＰＣＥＦは従来技術によって現在対応されていないと考えられる。

本発明に関して、２つの主要な使用する場合が以下で示される。：
・ＵＥは、動的ＰＣＣをサポートしない新規のアクセスに接続する。

○ Ｈ−ＰＣＲＦ１０は、制限付きのＰＣＣケイパビリティ群がＩＰ−ＣＡＮセッションに対して提供されることを判定する。

○ Ｈ−ＡＦ１２とＰＤＮ−ＧＷ／ＰＣＥＦは、制限付きのＰＣＣケイパビリティ群が利用可能である（動的ＱｏＳ制御、セッション認可及びイベント報告が利用可能でない）ことが通知される。

・ＵＥは、動的ＰＣＣサポートしないアクセスから動的ＰＣＣをサポートするアクセスへ移動する。

○ Ｈ−ＰＣＲＦ１０は、完全な動的ＰＣＣ制御がＩＰ−ＣＡＮセッションに対して提供されることを判定する。

○ ＡＦとＰＤＮ−ＧＷ／ＰＣＥＦは、動的ＰＣＣ制御が利用可能である（動的ＱｏＳ、セッション認可及びイベント報告が利用可能である）ことが通知される。

・ＵＥは、動的ＰＣＣをサポートするアクセスから、動的ＰＣＣをサポートしないアクセスへと移動する。

○ Ｈ−ＰＣＲＦ１０は、制限付きのＰＣＣケイパビリティ群をＩＰ−ＣＡＮセッションに対して適用することを判定し、ＰＣＥＦでＰＣＣルール群を更新する。ＰＣＣルール群は、サービスデータフロー検出と課金情報のみを含んでいる。

○ Ｈ−ＡＦ１２とＰＤＮ−ＧＷ／ＰＣＥＦには、制限付きの動的ＱｏＳ制御、セッション認可、及びイベント報告が利用可能でないことが通知される。

動的ＰＣＣをサポートしない新規のアクセスにＵＥが接続する状況をここで記載する。図４は、動的ＱｏＳをサポートしない新規のアクセスに接続するＵＥを示している。Ｈ−ＰＣＲＦ１０は、ＩＰ−ＣＡＮセッション確立で、サポートされているＰＣＣケイパビリティ群の検出を行う。ＵＥがＡ−ＧＷ（ＶＰＬＭＮ）に接続する場合、ＰＤＮ−ＧＷ／ＰＣＥＦ（ＨＰＬＭＮ）は、ＩＰ−ＣＡＮベアラを確立するためのリクエストを受信する（図４のステップ１及び２）。次に、ＰＤＮ−ＧＷ／ＰＣＥＦは、Ｈ−ＰＣＲＦ１０に対してＰＣＣルール群をリクエストする（図４のステップ３）。Ｈ−ＰＣＲＦ１０は、以下の方法を使用して、ＩＰ−ＣＡＮセッション確立時点でサポートされているＰＣＣケイパビリティ群を検出する。

− Ｈ−ＰＣＲＦ１０は、ＩＰ−ＣＡＮセッション確立時にＰＣＥＦによって示される、ＩＰ−ＣＡＮタイプとモビリティプロトコルタイプを参照する（図４のステップ３）。これは、Ｇｘｘ／Ｓ９が要求されているかどうか、そして、制限付きのＰＣＣ配備の訪問先ネットワークをローミングしている場合であるかどうかを判定するためである。以下の表１は、使用されるＩＰ−ＣＡＮタイプとモビリティプロトコルタイプに依存してＳ９／Ｇｘｘが要求される場合と要求されない場合とを示している。表１の構成設定は、オペレータによって実行することができる。

表１ Ｓ９／Ｇｘｘが要求されているかの判定方法

− Ｈ−ＰＣＲＦ１０は、最終的には、特定のローミング状況で制限付きのＰＣＣケイパビリティ群が利用可能であることを判定する。これは、Ｓ９／Ｇｘｘの使用が特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせ（上述のように）に対して要求されているが、Ｓ９／Ｇｘｘを介して対応するゲートウェイ制御セッションシグナリングが受信されない場合である。

モビリティプロトコルタイプは新規のＡＶＰであり、これは、Ａ−ＧＷとＰＤＮ−ＧＷとの間でサポートされる様々なプロトコル群（ＧＴＰ、ＰＭＰ、ＤＳＭＩＰ、ＭＩＰ）を列挙する。

制限付きのＰＣＣ配備で動作するためのＨ−ＰＣＲＦ１０の構成設定に関し、Ｈ−ＰＣＲＦ１０がＰＣＣ（Ｓ９／Ｇｘｘが要求され、かつＳ９／Ｇｘｘの対話が受信されていない）をサポートしない訪問先ネットワークでＵＥがローミングしていると判定する場合、Ｈ−ＰＣＲＦ１０は、以下の動作を実行する。

・制限付きのＰＣＣ配備によりＩＰ−ＣＡＮセッション確立がオペレータのポリシー群に基づいて拒否されるか受け入れられるかを判定する。受け入れられる場合、以下のステップ群も適用する。

・選択されたベアラ制御モードに関わらず、Ｈ−ＡＦ１２からのリクエストの受信時にＰＤＮ−ＧＷ／ＰＣＥＦへＰＣＣルール群をプッシュするためのオペレータモードを構成設定する。

・ＵＥへ通知するために「ＵＥのみ」として常にＢＣＭを選択する。

・非動的ＱｏＳ制御が事前に確立された専用のベアラ群をＰＤＮ−ＧＷ／ＰＣＥＦから開始することができないことを意味することを考慮して、ＰＤＮ−ＧＷ／ＰＣＥＦにＰＣＣルール群をインストールする（例えば、ＩＭＳシグナリングに対するＩＰ−ＣＡＮセッション確立で事前に確立された専用ベアラ群はセットアップすることができない）。

・関連するサポートされているＰＣＣケイパビリティ群についてＰＤＮ−ＧＷ／ＰＣＥＦへ通知し（イベント報告ケイパビリティ群だけがＰＤＮ−ＧＷ／ＰＣＥＦに関連している）、トンネル情報がＡ−ＧＷ／ＢＢＥＲＦへインストールされていないことを通知し、そして、同一のモビリティプロトコルが同一のＩＰ−ＣＡＮタイプ内で使用されると想定して、ＩＰ−ＣＡＮタイプの変更を承認する。

サポートされているＰＣＣケイパビリティ群をＰＤＮ−ＧＷ／ＰＣＥＦへ報告する場合、Ｈ−ＰＣＲＦ１０は、ＩＰ−ＣＡＮセッション確立リクエストに応じて、関連するサポートされているＰＣＣケイパビリティ群についてＰＤＮ−ＧＷ／ＰＣＥＦへ通知する（図４のステップ４）。以下では、Ｇｘリファレンスポイント内でこの情報を符号化する潜在的なＤｉａｍｅｔｅｒプロトコルの更なる詳細を示す。

追加的には、サポートされているＰＣＣケイパビリティ群の情報は、ＰＤＮ−ＧＷ／ＰＣＥＦに関連し、これは、以下のことを行うためである。

・ある事前構成設定されているＰＣＣルール群に基づいてベアラ群を開始しないことを自身に構成設定すること（例えば、ＩＭＳシグナリングに対するＩＰ−ＣＡＮセッション確立時には専用の事前確立されたベアラ群を確立しない）。

・特に、あるケイパビリティ群、即ち、イベント報告が欠如している場合に、Ｈ−ＰＣＲＦ１０によって報告されるＰＣＣケイパビリティ群について、Ｇｙリファレンスポイントを介してＯＣＳへ更に通知すること（図４のステップ５及び６）。

以下では、Ｇｙリファレンスポイント内でこの情報を符号化する潜在的なＤｉａｍｅｔｅｒプロトコルの更なる詳細を示す。

ここでは、ＯＣＳに、例えば、これらのケイパビリティ群のいくつかがサポートされていない状況で課金認可が拒否されるべきかどうかを決定することを可能にする。例えば、課金認可は、ロケーションベースの課金ポリシー群が存在するが、イベント報告（例えば、特定のローミングエリア群へローミングイベントについて通知するための）が利用可能でない状況では拒否されても良い。

ＰＤＮ−ＧＷ／ＰＣＥＦは、割り当てられているＵＥ ＩＰアドレスを含む場合があるＩＰ−ＣＡＮセッション確立の確認を返信する（図４のステップ７及び８）。

サポートされているＰＣＣケイパビリティ群をＨーＡＦ１２へ報告するために、デフォルトのベアラの接続及び作成後、ユーザは、特定のサービスを享受するためのアプリケーション機能にコンタクトすることができる。ＱｏＳ及び課金制御がこのサービスに対して要求される場合、Ｈ−ＡＦ１２は、対応するＱｏＳ認可を提供するために、Ｈ−ＰＣＲＦ１０と対話する（図４のステップ９）。

本実施形態に従えば、Ｈ−ＰＣＲＦ１０は、ユーザが接続されている特定の状況で現在サポートされているＰＣＣ機能群／ケイパビリティ群の表示をＨ−ＡＦ１２への応答で含んでいる。尚、Ｈ−ＰＣＲＦ１０が、上述の実施形態で提案されているメカニズムを使用してこのような状況を気付かせることに注意されたい。

Ｈ−ＰＣＲＦ１０からのこの表示は、とりわけ、あるＶＰＬＭＮ上でローミングしているユーザに関してサービスセッションが進行しているかを決定するために、Ｈ−ＡＦ１２に関連することになる。例えば、Ｈ−ＰＣＲＦ１０からのこの表示を受信すると、Ｈ−ＡＦ１２は、以下の動作の１つ以上を実行することができる。

・開始されているサービスセッションの継続を決定する。

・将来のサービスセッションリクエスト群でＰＣＣアーキテクチャと対話しないことを自身に構成設定する。

・課金制御に対してだけの将来のサービスセッションリクエスト群でＰＣＣアーキテクチャと対話することを自身に構成設定する。

・例えば、ユーザが動的ＱｏＳ制御を許容するアクセスにローミングしている場合に、サポートされているＰＣＣ機能群／ケイパビリティ群の将来の更新の通知を承認する。

以下では、Ｒｘリファレンスポイント内でこの情報を符号化する潜在的なＤｉａｍｅｔｅｒプロトコルの更なる詳細を示す。

特定の動作のＡＶＰに対する新規の値が、サポートされているＰＣＣケイパビリティ群の変更（ＳＵＰＰＯＲＴＥＤ＿ＰＣＣ＿ＣＡＰＡＢＩＬＩＴＩＥＳ＿ＣＨＡＮＧＥ）イベント群を承認し、かつＨ−ＡＦ１２に通知するために要求されることになる。自身で適用可能な値を有するその新規のサポートされているＰＣＣケイパビリティ群は、この場合に追加的に提供されるべきである。

Ｈ−ＰＣＲＦ１０の最初の通知と後続の通知、及び対応するＨ−ＡＦ１２のアクション群は、サービスセッション単位で行うことができる。

ＩＭＳの場合に対しては、この実施形態は、ＩＭＳドメイン内でのユーザ登録で処理されるＨ−ＰＣＲＦ１０通知を有している。この特定の実施形態（ＩＭＳ）内では、アプリケーション機能Ｈ−ＡＦ１２は、「プロキシ呼セッション制御機能」であるＰ−ＣＳＣＦであると想定されることに注意されたい。

・３ＧＰＰ Ｒｘ ＴＳ ２９．２１４［３ＧＰＰ ＴＳ ２９．２１４ ｖ．８．２．０ Ｒｘインタフェースを介するポリシー及び課金制御（リリース８）］で現在定義されているように、ユーザ登録時には、Ｐ−ＣＳＣＦは、Ｈ−ＰＣＲＦ１０とのＲｘセッションを確立する。これは、ユーザに接続されている現在のＩＰ−ＣＡＮタイプを通知し、また、シグナリングの接続性の損失及びＩＰ−ＣＡＮタイプの変更の通知を承認するためである。

・この実施形態では、Ｈ−ＡＦ１２は、Ｒｘセッションリクエスト内のこの時点で、サポートされているＰＣＣケイパビリティ群の変更（ＳＵＰＰＯＲＴＥＤ＿ＰＣＣ＿ＣＡＰＡＢＩＬＩＴＩＥＳ＿ＣＨＡＮＧＥ）イベント群の変更の通知を承認し、そして、Ｈ−ＰＣＲＦ１０は、応答内で、現在のアクセスでサポートされているＰＣＣケイパビリティ群についての情報を提供する。

・Ｐ−ＣＳＣＦは、ＰＣＣケイパビリティ群の現在のサポートに従って自身を構成設定することになる。Ｐ−ＣＳＣＦの決定は、好ましくは、ユーザが試行する可能性がある後続のＩＭＳセッション群に適用しながら、この状況では、例えば、
○ 例えば、動的ＱｏＳ制御が提供できない限り、特定のユーザに対してすべてのＩＭＳセッションリクエスト群を拒否する。

○ 課金制御目的のためだけに対話しないこと、あるいは将来のＩＭＳセッションリクエスト群でＰＣＣと対話しないことを自身に構成設定する。

・Ｐ−ＣＳＣＦは、ＩＭＳ登録に対応するＲｘセッションを通じて、サポートされているＰＣＣケイパビリティ群の変更について通知される。適切な動作群は、この時点でＰ−ＣＳＣＦによって決定することができ、その上、例えば、
○ 例えば、動的ＱｏＳ制御がこれ以上利用可能でない場合、すべての進行中のセッションを終了することを決定する。

○ 将来のＩＭＳセッションリクエスト群に対するＰＣＣアーキテクチャと適切に対話することを自身に構成設定する。

ＵＥが動的ＰＣＣをサポートしないアクセスから動的ＰＣＣをサポートするアクセスへ移動する状況をここで記載する。ＵＥは、動的ＰＣＣをサポートしないアクセス（新規のＩＰ−ＣＡＮタイプ）から動的ＰＣＣをサポートするアクセス（新規のＩＰ−ＣＡＮタイプ）へ移動する。これは、以下の場合の１つが発生していることを意味する。

・その到達するアクセスが、Ａ−ＧＷ内でＢＢＥＲＦ機能を有している。

・ネットワークがＧＴＰプロトコルをサポートしている。

Ｈ−ＰＣＲＦ１０は、ＶＰＬＭＮ内のサポートされているＰＣＣケイパビリティ群が、以下の入力の使用を行うことを変更をしていることを理解する。

・Ａ−ＧＷ／ＢＢＥＲＦが新規のアクセスで配備されていることの情報（即ち、Ｓ９／Ｇｘｘを介するＱｏＳルール群に対するリクエストの受信によって）、あるいは
・新規のアクセスがＧＴＰをサポートしているが、モビリティプロトコルを含む明示的な表示がＰＤＮ−ＧＷ／ＰＣＥＦから受信されていることの情報、あるいは上述のように、ＧＴＰを介して転送される情報要素群の１つがＰＤＮ−ＧＷ／ＰＣＥＦから受信されていることをチェックする情報。

・ ＶＰＬＭＮへの古いアクセスがＰＣＣを配備していないことの、Ｈ−ＰＣＲＦ１０における現在の情報
Ｈ−ＰＣＲＦ１０が完全なＰＣＣケイパビリティ群を現在利用可能であることを一旦検出すると、Ｈ−ＰＣＲＦ１０は、上述の手順を使用させることをＰＤＮ−ＧＷ／ＰＣＥＦとＨ−ＡＦ１２へ通知することができる。

ＵＥが動的ＰＣＣをサポートするアクセスから動的ＰＣＣをサポートしないアクセスへ移動する状況をここで記載する。ＵＥは、ＱｏＳ制御をサポートするアクセスから、動的ＱｏＳ制御をサポートしないアクセスへ移動する。これは、到達するアクセスが、Ａ−ＧＷ内でＢＢＥＲＦ機能を有さないことを意味する。

Ｈ−ＰＣＲＦ１０は、ＶＰＬＭＮ内のＰＣＣケイパビリティ群が、以下の入力を使用を行うことを変更をしていることを理解する。

・新規のアクセス内で、Ａ−ＧＷ／ＢＢＥＲＦはどこにも配置されないことの情報（即ち、対応するＳ９手順の欠如によるものである）
・ＶＰＬＭＮへの古いアクセスがＰＣＣを配備していたことの、Ｈ−ＰＣＲＦにおける現在の情報
・メディアプレーン（ＵＥからＰＤＮ−ＧＷへの経路内）で使用されるプロトコル群のすべてが、上述のかつ表１のようなＱｏＳ情報（即ち、ＰＭＩＰあるいはＤＳＭＩＰが使用される）を必ずしも含んでいないことの、Ｈ−ＰＣＲＦにおける情報
・新規のアクセスはＧＴＰをサポートしないが、上述のかつ表１で使用されるように、ＰＤＮ−ＧＷ／ＰＣＥＦから受信されるパラメータ群のリストをチェックすることの情報

Ｈ−ＰＣＲＦ１０が制限付きのＰＣＣケイパビリティ群のみが現在利用可能であることを一旦検出すると、Ｈ−ＰＣＲＦ１０は、上述の手順を使用させることをＰＤＮ−ＧＷ／ＰＣＥＦとＨ−ＡＦ１２へ通知することができる。

ＰＣＣケイパビリティ群の符号化が、ＤＩＡＭＥＴＥＲプロトコルに従って現在サポートされている状況をここで記載する。本実施形態では、現在のアクセスで利用可能なＰＣＣ機能群／ケイパビリティ群についての情報は、新規のグループ化されているＡＶＰとして、Ｄｉａｍｅｔｅｒプロトコル内で符号化することができる。このような符号化の例は以下のようにすることができる。

Supported-PCC-Capabilities:=
[Dynamic-QoS-Control] ENABLED/NOT ENABLED
[Session-Authorization] ENABLED/NOT ENABLED
[Event-Reporting] ENABLED/NOT ENABLED
[Charging-Control] ENABLED/NOT ENABLED
（サポートされているＰＣＣケイパビリティ群：＝
[動的ＱｏＳ制御] 有効／無効
[セッション認可] 有効／無効
[イベント報告] 有効／無効
[課金制御] 有効／無効）
注：いくつかの理由によって課金制御は無効にされる場合があることに注意されたい。サポートされているＰＣＣケイパビリティ群のＡＶＰ内の課金制御ＡＶＰは、この状態を示すことを提示することができる。

この符号化は、インタフェース群：Ｇｘ、Ｒｘ及びＧｙを介して交換されるプロトコルメッセージ群で（再）使用することができる。

本明細書で提示される発明は、以下の利点を提供する。

１．Ｈ−ＰＣＲＦ１０は、静的な構成設定を必要とすることなく、ローミング状況に対するＰＣＣ配備（ＰＣＣ機能群／ケイパビリティ群）に気付くことができ、また、それゆえ、以下のことを実行することができる。

ａ．自身を適切に構成設定すること（例えば、動的ＱｏＳが利用可能でない場合、ＢＣＭに無関係なルール群をプッシュすること）
ｂ．他のネットワークノード群（ＰＤＮ−ＧＷ／ＰＣＥＦとＨ−ＡＦ１２）へ通知すること
ｃ．適切な方法でポリシー群に適合させること

２．Ｈ−ＡＦ１２は、現在サポートされているＰＣＣケイパビリティ群に気付くことができ、また、現在の条件に従うサービスリクエストを適合することができる。これにより、Ｒｘでの対話数を削減できるとともに、制限付きのＰＣＣケイパビリティ群がＨ−ＡＦ１２へ報告される。

３．ＰＤＮ−ＧＷ／ＰＣＥＦは、現在サポートされているＰＣＣケイパビリティ群に気付くことができ、また、現在の条件に従ってＯＣＳへ通知することができる。

４．ＯＣＳは、現在サポートされているＰＣＣケイパビリティ群の知識を取得することができ、かつ適切な課金を適合することができる。

略語表
Ａ−ＧＷ アクセスゲートウェイ
ＡＦ アプリケーション機能
ＡＶＰ 属性／値ペア
ＢＢＥＲＦ ベアラバインディング及びイベント報告機能
ＢＣＭ ベアラ制御モード
ＧＴＰ ＧＰＲＳトンネリングプロトコル
Ｈ−ＡＦ ＨＰＬＭＮ内のＡＦ
Ｈ−ＰＣＲＦ ＨＰＬＭＮ内のＰＣＲＦ
ＩＭＳ ＩＰマルチメディアサブシステム
ＩＰ−ＣＡＮ ＩＰ接続性アクセスネットワーク
ＩＰ−ＣＡＮ状況 用語「ＩＰ−ＣＡＮセッション」は、ＩＰｖ４アドレス及びＩＰｖ６アドレスの少なくとも一方と、利用可能である場合には、ＵＥアイデンティティ情報とによって表されるＵＥと、ＰＤＮ ＩＤ（例えば、ＡＰＮ）によって表されるＰＤＮとの関係を記述する。ＩＰ−ＣＡＮセッションは、１つ以上のＩＰ−ＣＡＮベアラを組み込むことができる。

ＯＣＳ オンライン課金システム
ＰＣＥＦ ポリシー及び課金エンフォースメント機能
ＰＣＲＦ ポリシー及び課金ルール機能
ＰＤＮ パケットデータネットワーク
ＰＤＮ−ＧＷ パケットデータネットワークゲートウェイ
ＱｏＳ サービス品質
ＳＤＦ サービスデータフロー
Ｓ−ＧＷ 在圏ゲートウェイ（３ＧＰＰアクセス用のＡ−ＧＷ）
ＵＥ ユーザ機器
Ｖ−ＰＣＲＦ ＶＰＬＭＮ内のＰＣＲＦ

本発明は、例示の目的のために上述の実施形態で詳細に説明しているが、この詳細は単にその例示の目的のものであり、また、様々な変形を、添付の請求項によって記載される本発明以外の、本発明の精神及び範囲から逸脱することなく、当業者によって行うことができることが理解されるべきである。

Claims (20)

1. ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）の方法であって、
   ネットワークインタフェースにおいてシグナリングメッセージを受信するステップと、
   処理ユニットが、ＶＰＬＭＮのＰＣＣケイパビリティ群に関するポリシー及び課金制御（ＰＣＣ）状況を、受信したメッセージから動的に検出するステップと、
   前記ＶＰＬＭＮ上でローミングするユーザに関して、前記検出されたＰＣＣ状況をホームアプリケーション機能（Ｈ−ＡＦ）に通知するメッセージを、前記ネットワークインタフェースから前記Ｈ−ＡＦへ送信するステップと
   を備えることを特徴とする方法。
2. 前記検出するステップは、前記処理ユニットが、前記検出されたＰＣＣ状況において、前記ＶＰＬＭＮ上でローミングしているユーザに対して完全なＰＣＣ制御あるいは制限付きのＰＣＣ制御が存在しているかを検出するステップを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記検出するステップは、情報に基づいて特定のＰＣＣ状況でサポートされているＰＣＣケイパビリティ群を検出するステップを含み、
   前記情報は、Ｇｘインタフェースを通じてＩＰ−ＣＡＮセッション確立表示で受信される、インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）タイプとモビリティプロトコルタイプを示す情報と、前記セッションに対応するゲートウェイ制御シグナリングの存在を示す情報とを含む
   ことを特徴とする請求項１または２に記載の方法。
4. 前記ゲートウェイ制御シグナリングは、Ｓ９インタフェースあるいはＧｘｘインタフェースを通じて前記Ｈ−ＰＣＲＦによって受信され、
   前記処理ユニットが、前記Ｓ９インタフェースあるいはＧｘｘインタフェースの使用が、特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせに対して要求されているが、対応するゲートウェイ制御セッションシグナリングが前記Ｈ−ＰＣＲＦによって受信されていない場合、制限付きのＰＣＣケイパビリティ群が特定のＰＣＣ状況で利用可能であることを検出するステップを含む
   ことを特徴とする請求項３に記載の方法。
5. 前記処理ユニットが、１つ以上の特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせに対して、前記Ｓ９インタフェースあるいはＧｘｘインタフェースの使用が、前記Ｈ−ＰＣＲＦによってゲートウェイ制御セッションシグナリングを受信するために要求されているかを、内部的に構成設定されているデータを使用して確認するステップを含む
   ことを特徴とする請求項４に記載の方法。
6. 前記ＶＰＬＭＮのＰＣＣケイパビリティ群に関して前記検出されたＰＣＣ状況を通知するメッセージを、前記ネットワークインタフェースからポリシー及び課金エンフォースメント機能（ＰＣＥＦ）へ送信することで、前記ＰＣＥＦが、前記ＶＰＬＭＮ上でローミングしているユーザに関して前記Ｈ−ＰＣＲＦによって報告される少なくとも１つの前記ＰＣＣケイパビリティ群について課金システム（ＯＣＳ）へ通知するための情報を取得するステップを更に含む
   ことを特徴とする請求項１に記載の方法。
7. ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）装置であって、
   シグナリングメッセージを送受信するネットワークインタフェースと、
   ＶＰＬＭＮのＰＣＣケイパビリティ群に関するポリシー及び課金制御（ＰＣＣ）状況を、受信したメッセージから動的に検出する処理ユニットとを備え、
   前記ネットワークインタフェースは、前記ＶＰＬＭＮ上でローミングするユーザに関して、前記検出されたＰＣＣ状況をホームアプリケーション機能（Ｈ−ＡＦ）に通知するメッセージを前記Ｈ−ＡＦへ送信する
   ことを特徴とするＨ−ＰＣＲＦ装置。
8. 前記処理ユニットは、前記検出されたＰＣＣ状況において、前記ＶＰＬＭＮ上でローミングしているユーザに対して完全なＰＣＣ制御あるいは制限付きのＰＣＣ制御が存在しているかを検出する
   ことを特徴とする請求項７に記載のＨ−ＰＣＲＦ装置。
9. 前記処理ユニットは、情報に基づいて特定のＰＣＣ状況でサポートされているＰＣＣケイパビリティ群を検出し、
   前記情報は、Ｇｘインタフェースを通じてＩＰ−ＣＡＮセッション確立表示で受信される、インターネットプロトコル接続アクセスネットワーク（ＩＰ−ＣＡＮ）タイプとモビリティプロトコルタイプを示す情報と、前記セッションに対応するゲートウェイ制御シグナリングの存在を示す情報とを含む
   ことを特徴とする請求項７または８に記載のＨ−ＰＣＲＦ装置。
10. 前記ネットワークインタフェースは、ゲートウェイ制御シグナリングを受信する、Ｓ９インタフェースあるいはＧｘｘインタフェースの少なくとも一方を含み、
    前記処理ユニットは、前記Ｓ９インタフェースあるいはＧｘｘインタフェースの使用が、特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせに対して要求されているが、対応するゲートウェイ制御セッションシグナリングが前記Ｈ−ＰＣＲＦによって受信されていない場合、制限付きのＰＣＣケイパビリティ群が特定のＰＣＣ状況で利用可能であることを検出する
    ことを特徴とする請求項９に記載のＨ−ＰＣＲＦ装置。
11. 前記処理ユニットは、１つ以上の特定のＩＰ−ＣＡＮ／モビリティプロトコルタイプの組み合わせに対して、前記Ｓ９インタフェースあるいはＧｘｘインタフェースの使用が、前記Ｈ−ＰＣＲＦによってゲートウェイ制御セッションシグナリングを受信するために要求されているかを、内部的に構成設定されているデータを使用して確認する
    ことを特徴とする請求項１０に記載のＨ−ＰＣＲＦ装置。
12. 前記ネットワークインタフェースは、前記ＶＰＬＭＮのＰＣＣケイパビリティ群に関して前記検出されたＰＣＣ状況を通知するメッセージを、ポリシー及び課金エンフォースメント機能（ＰＣＥＦ）へ送信することで、前記ＰＣＥＦが、前記ＶＰＬＭＮ上でローミングしているユーザに関して前記Ｈ−ＰＣＲＦによって報告される少なくとも１つの前記ＰＣＣケイパビリティ群について課金システム（ＯＣＳ）へ通知するための情報を取得する
    ことを特徴とする請求項７に記載のＨ−ＰＣＲＦ装置。
13. ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシーアプリケーション機能（Ｈ−ＡＦ）の方法であって、
    ネットワークインタフェースにおいて、ホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）から、ＶＰＬＭＮのＰＣＣケイパビリティ群に関する検出されたポリシー及び課金制御（ＰＣＣ）状況を前記Ｈ−ＡＦへ通知するメッセージを受信するステップと、
    処理ユニットが、前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に基づいて、前記ＶＰＬＭＮ上でローミングするユーザに関するサービスネゴシエーションが進行しているかどうかを決定するステップと
    を備えることを特徴とする方法。
14. 前記決定するステップは、前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に従って、動的な品質サービス（ＱｏＳ）が利用可能でない場合に、前記処理ユニットが、サービスセッションリクエストを拒否するステップを含む
    ことを特徴とする請求項１３に記載の方法。
15. 前記ＶＰＬＭＮ上でローミングするユーザに関するＶＰＬＭＮの前記ＰＣＣケイパビリティ群の変更の通知を承認するメッセージを、前記ネットワークインタフェースから前記Ｈ−ＰＣＲＦへ送信するステップを含む
    ことを特徴とする請求項１３に記載の方法。
16. 前記受信するステップは、前記変更の通知を承認するメッセージの結果として、検出されたＰＣＣ状況を通知するメッセージを、前記Ｈ−ＰＣＲＦから受信するステップを含む
    ことを特徴とする請求項１５に記載の方法。
17. ホーム公衆移動体公衆ネットワーク（ＨＰＬＭＮ）と訪問先公衆移動体公衆ネットワーク（ＶＰＬＭＮ）を有する電気通信ネットワークにおけるホームポリシーアプリケーション機能（Ｈ−ＡＦ）装置であって、
    ホームポリシー及び課金ルール機能（Ｈ−ＰＣＲＦ）から、ＶＰＬＭＮのＰＣＣケイパビリティ群に関する検出されたポリシー及び課金制御（ＰＣＣ）状況を前記Ｈ−ＡＦへ通知するメッセージを受信するネットワークインタフェースと、
    前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に基づいて、前記ＶＰＬＭＮ上でローミングするユーザに関するサービスネゴシエーションが進行しているかどうかを決定する処理ユニットと
    を備えることを特徴とするＨ−ＡＦ装置。
18. 前記処理ユニットは、前記Ｈ−ＰＣＲＦからの前記メッセージで受信される情報に従って、動的な品質サービス（ＱｏＳ）が利用可能でない場合に、サービスセッションリクエストを拒否する
    ことを特徴とする請求項１７に記載のＨ−ＡＦ装置。
19. 前記ネットワークインタフェースは、前記ＶＰＬＭＮ上でローミングするユーザに関するＶＰＬＭＮの前記ＰＣＣケイパビリティ群の変更の通知を承認するメッセージを前記Ｈ−ＰＣＲＦへ送信する
    ことを特徴とする請求項１７に記載のＨ−ＡＦ装置。
20. 前記ネットワークインタフェースは、前記変更の通知を承認するメッセージの結果として、検出されたＰＣＣ状況を通知するメッセージを、前記Ｈ−ＰＣＲＦから受信する
    ことを特徴とする請求項１９に記載のＨ−ＡＦ装置。

Images