JP5553990B2 - 拡張システム・アーキテクチャにおけるポリシ制御 - Google Patents

Description

本発明は、データ・パケット・ネットワークにおけるポリシ制御のための方法及びシステムに関する。

パケット交換コア・ネットワークを含むユニバーサル移動体通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）においては、提供することができるサービスは、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）のような回線交換移動電話システムよりも優れた利点を有する。例えば、映像又は通話呼出は、保証されたサービス品質（ＱｏＳ）を必要とし、一方、非リアルタイム・パケット・データをベスト・エフォート・ベースで提供することができる。提供される種々のサービスにおけるこの改善は、ネットワークによって適切に管理される必要があり、このことは過去における標準化会議の話題であった。

３ＧＰＰ（第３世代パートナーシップ・プロジェクト）は、ＩＰマルチメディア・サブシステム（ＩＭＳ）に対してＳＢＬＰ（Ｓｅｒｖｉｃｅ Ｂａｓｅｄ Ｌｏｃａｌ Ｐｏｌｉｃｙ）を使用することができるようにするため、リリース５においてポリシ制御アーキテクチャ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）を組み込んだ。ＳＢＬＰを使用すると、制御面（例えば、ＩＭＳ）は、セッション確立の際にネゴシエーションされたＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）パラメータに基づいて、ベアラ・トラフィック（ｂｅａｒｅｒ ｔｒａｆｆｉｃ）を許可し、制御することができる。ベアラとサービスとの間のバインディングは、許可トークン（Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｔｏｋｅｎ）機構に基づいている。許可トークン機構は、アプリケーション・セッション・シグナリング及びベアラ設定シグナリングによるサポートを必要とする。

リリース６において、ＳＢＬＰは、ＩＭＳから分離された。すなわち、ポリシ制御ノードは、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）の論理素子ではなく、ＳＢＬＰも他のアプリケーションに対して使用することができる。図１は、関連するエンティティで行われるＳＢＬＰ機能及びこれらの間のシグナリング・メッセージを示す。

リリース６においては、例えば、ゲートウェイへのフロー・フィルタ及び規則を提供するＳＢＬＰと類似の機能を有するＦＢＣ（Ｆｌｏｗ Ｂａｓｅｄ Ｃｈａｒｇｉｎｇ）が導入された。

リリース７のポリシ制御及び課金に対する作業項目においては、ＳＢＬＰ及びＦＢＣの完全な調和の研究が行われる。さらに、許可トークンが除去できるか否かの研究が行われ、したがって、サービスにベアラをバインディングするための他の機構が既に提案されている。

リリース７以降においては、３ＧＰＰにおいて、システム・アーキテクチャの展開が研究される。その目標は、高いデータ・レート、低いレイテンシ、複数の無線アクセス技術（ＲＡＴ）をサポートするパケット最適化システムを達成することである。

高レベルのアーキテクチャ提案のうちの１つは、例えば、複数の接続しているアクセス・システムを含む、例えば、ＭＩＰｖ６（Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌバージョン６）ホーム・エージェントのようなアクセス・システム間モビリティ管理（ＡＳ間ＭＭ）エンティティを有する。異なるアクセス・システムは、異なるアクセス技術をサポートすることができ、また、異なるネットワーク・オペレータに属している。アクセス・システムにおいては、ゲートウェイが、端末にＩＰ接続性を提供し、したがって、端末はそのホーム・ネットワーク内でＡＳ間ＭＭへの接続、又は、最適化した経路指定により通信相手ノードに直接接続を確立することができる。

図２及び図３は、可能なＩＰ及びトンネリング・フローを有する高レベルのアーキテクチャを示す。これらの図は、セッションＩＰフロー及び端末とＡＳ間ＭＭとの間のトンネルの他に、もう１つのトンネル、すなわち基地局とゲートウェイとの間のローカル・モビリティ・トンネルも示す。

一般的な動機付けは、拡張システム・アーキテクチャにおいてポリシ制御を行うことである。１つのオプションは、ＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｅｒｖｉｎｇ Ｎｏｄｅ）のところに、現在の３ＧＰＰポリシ制御機構に類似したＡＳ間ＭＭに接続しているポリシ制御ノードを有することである。問題は、経路最適化の場合、ＡＳ間ＭＭが、ユーザ・データ・トラフィックの経路上に存在していないために、ＡＳ間ＭＭが経路最適化したトラフィックに対してポリシ制御を行うことができないことである。さらに、ポリシ制御がＡＳ間ＭＭでのみ行われる場合には、ローミング・シナリオの場合に、在圏ネットワーク（ｖｉｓｉｔｅｄ ｎｅｔｗｏｒｋ）のオペレータは、ポリシ制御プロセスに関与することができない。

上記制限を克服するために、ゲートウェイをＡＳ間ＭＭの他に、ポリシ制御ノードにも接続しなければならない。このため、ゲートウェイとホーム・ポリシ制御ノードの間にプロキシ・ポリシ制御（Ｐｒｏｘｙ Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ）ノードを導入することができる。ゲートウェイは、プロキシ・ポリシ制御ノードに要求を送信し、プロキシ・ポリシ制御ノードは、その要求をホーム・ポリシ制御ノードに転送する。

ゲートウェイにおいてポリシ制御を実行しなければならないために、新しい問題が発生する。移動端末（ＵＥ）と通信相手ノード（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ Ｎｏｄｅ）の間のトラフィックは、トンネル可能（例えば、ＭＩＰｖ６の場合には、ホーム・エージェントへ逆方向にトンネル可能）であるか、あるいは、アドレス交換可能（例えば、ローカル・モビリティ管理手順のためにＩＰアドレスとポートを交換可能）であるか、あるいは、ＩＰｖ６ルーティング拡張ヘッダ（例えば、ＭＩＰｖ６タイプ２のルーティング・ヘッダ）やＩＰｖ６あて先オプション拡張ヘッダ内の（ＭＩＰｖ６におけるホーム・アドレス内の）ホーム・アドレス・オプション、又はこれらの組み合わせによって経路指定を行うことが可能である。このことは、ゲートウェイ上で受信したデータ・パケット及びベアラ要求の両方が、例えば、ＡＳ間ＭＭとＵＥの間のようなＩＰトンネルのＩＰフロー・パラメータ（ＩＰソース／あて先アドレス／ポート）を有することを意味する。一方、ホーム・ネットワーク内のポリシ制御ノードは、例えば、ソース・アドレスとしてＵＥのホーム・ＩＰアドレス、あて先アドレスとして通信相手ノードのＩＰアドレスを用いて、ＵＥと通信相手ノードの間のオリジナルのＩＰフローに関するセッション確立中に、そのポリシの判定を行う。それ故、ゲートウェイにおけるＩＰフロー・パラメータは、ホーム・ポリシ制御ノードにとって無用のものである。何故なら、ホーム・ポリシ制御ノードは、アプリケーション・レベルのＩＰフロー・パラメータに、トンネルのＩＰフロー・パラメータをマッピングすることができないからである。

ゲートウェイにとっての１つの可能性は、ホーム・ポリシ制御ノードで入手可能な適切なＩＰフロー・パラメータを入手し、ホーム・ポリシ制御ノードとの通信の際にこれらのパラメータだけを使用するために、トンネル内のＩＰフローをチェックすることができることである。しかし、このことは、（例えば、ＩＰＳｅｃにより）トンネルが暗号化されていない場合だけに行うことができる。さらに、ゲートウェイが各パケットをチェックしなければならない場合には、ゲートウェイにおける処理は劇的に増大する。

もう１つのオプションは、許可トークン機構を再使用することである。しかし、この機構は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）をベースとするアプリケーションに特有なものである。さらに、この機構は、（例えば、ＧＰＲＳ内の）ベアラ確立シグナリングによりサポートされている必要があり、それ故、ベアラ確立シグナリングに特有のものでもある。それ故、変更を行わずに他のアプリケーション及びアクセス・システムに適用することはできない。

本発明の１つの目的は、ゲートウェイで処理オーバヘッドを追加せずに、拡張システム・アーキテクチャにおいてポリシ制御を行うことである。

この目的は、独立請求項の主題により達成することができる。本発明の有利な実施の形態は、従属請求項の主題である。

本発明は、ユーザ機器と、ゲートウェイと、ホーム・ポリシ制御ノードとを備えるデータ・パケット・ネットワークにおいてポリシ制御を行う方法に関する。この方法は、ユーザ機器とアプリケーション機能との間のセッションを確立又は修正するステップを含む。セッション識別子がユーザ機器により生成され、同一のセッション識別子が、ホーム・ポリシ制御ノードにより独立して生成される。ユーザ機器は、データ・パケット・ネットワークからベアラの確立又は修正を要求し、そのセッション識別子によりベアラ確立又は修正パケットにマークを付ける。ゲートウェイは、ベアラ確立パケットからユーザ機器識別子を入手し、セッション識別子及びユーザ機器識別子に基づいてポリシ判定の決定を行う。ユーザ機器は、確立した又は修正したベアラを通して送信されるデータ・パケットにセッション識別子によりマークを付け、ゲートウェイは、ポリシ及び課金情報をマークが付けられているセッションのデータ・パケットに適用する。

また、本発明の有利な実施の形態では、セッション識別子によるデータ・パケット及びベアラ確立又は修正パケットのマーク付けは、上記データ・パケットの外部ＩＰｖ６ヘッダのフロー・ラベル・フィールドを使用する。

本発明の更なる実施の形態の利点は、ユーザ機器によるセッション識別子の生成ステップ、及びホーム・ポリシ制御ノードによるセッション識別子の生成ステップにおいて、ハッシュ関数を使用していることである。

別の有利な実施の形態によれば、ハッシュ関数は、入力パラメータとして、セッションのソース及びあて先アドレスと、ソース及びあて先ポート番号とを使用する。

更なる有利な実施の形態の場合では、ゲートウェイは、ポリシ判定の決定のステップの際に下記のサブステップ、すなわち、ユーザ機器識別子からホーム・ポリシ制御ノードを決定するサブステップと、ホーム・ポリシ制御ノードからセッションに対するポリシ及び課金情報を要求し、この要求がセッション識別子及びユーザ機器識別子を含むサブステップと、ホーム・ポリシ制御ノードからセッションに対するポリシ及び課金情報を受信するサブステップとを実行する。

この実施の形態の変形例では、ポリシ判定の決定を行うステップは、プロキシ・ポリシ制御ノードにより実行される下記のサブステップ、すなわち、ゲートウェイから、セッション識別子及びユーザ機器識別子を受信するサブステップと、ユーザ機器識別子からホーム・ポリシ制御ノードを決定するサブステップと、ホーム・ポリシ制御ノードからセッションに対するポリシ及び課金情報を要求し、この要求がセッション識別子及びユーザ機器識別子を含むサブステップと、ホーム・ポリシ制御ノードからセッションに対するポリシ及び課金情報を受信するサブステップと、ゲートウェイにセッションに対するポリシ及び課金情報を転送するサブステップとを含む。

更なる有利な実施の形態は、ユーザ機器とアプリケーション機能の間にセッションを確立又は修正する前に、ユーザ機器及びデータ・パケット・ネットワークを相互に認証するステップを含む。

別の有利な実施の形態によれば、ゲートウェイは、ユーザ機器及びデータ・パケット・ネットワークを相互に認証するステップにおいて、ユーザ機器識別子を受信する。

更なる有利な実施の形態は、ユーザ機器及びデータ・パケット・ネットワークを相互に認証するステップの後又は前に、ユーザ機器にローカル・アドレスを割り当てるステップを更に含む。

別の有利な実施の形態によれば、ゲートウェイは、ユーザ機器識別子とユーザ機器に割り当てられたローカル・アドレスとの間のマッピングを受信する。

別の有利な実施の形態では、ゲートウェイによりユーザ機器識別子を入手するステップは、ユーザ機器のローカル・アドレスとユーザ機器識別子との間のマッピングを使用する。

ゲートウェイによりユーザ機器識別子を入手するステップが、ベアラ確立又は修正パケットのソース・アドレスからユーザ機器のローカル・アドレスを入手するステップを含んでいるので更に有利である。

有利な実施の形態によれば、データ・パケット・ネットワーク内でポリシ制御を行うシステムは、ユーザ機器とアプリケーション機能との間でセッションを確立し、セッション識別子を生成することができるユーザ機器を備える。上記システムは、また、セッション識別子を生成することができるホーム・ポリシ制御ノードを備える。ユーザ機器が生成した上記セッション識別子とホーム・ポリシ制御ノードが生成した上記セッション識別子は同一のものである。さらに、ユーザ機器は、データ・パケット・ネットワークからベアラ確立又は修正を要求し、上記セッション識別子により、ベアラ確立又は修正パケットにマークを付ける。ゲートウェイは、ベアラ確立又は修正パケットからユーザ機器識別子を入手し、セッション識別子及びユーザ機器識別子に基づいてポリシ判定の決定を行うことができる。ユーザ機器は、また、確立した又は修正したベアラを通して送信されるデータ・パケットにセッション識別子によりマークを付け、ゲートウェイは、マークを付けたデータ・パケットにセッションに対するポリシ及び課金情報を適用する。

添付の図面を参照しながら以下に本発明をさらに詳細に説明する。

以下の節においては、本発明の種々の実施の形態について説明する。大部分の実施の形態においてはＵＭＴＳ通信システムに関連して概略説明するが、これは単に例示としてのものに過ぎないし、以下の説明で使用する用語は、主としてＵＭＴＳ用語に関連する。しかし、使用する用語及びＵＭＴＳアーキテクチャについての実施の形態の説明は、本発明の原理及びアイデアをこのようなシステムに限定するものではない。

また、上記技術的背景の詳細な説明は、以下に記載する大部分のＵＭＴＳの特定の例示としての実施の形態を単によりよく理解してもらうためのものであり、移動通信ネットワークでのプロセス及び機能の上記特定の実施の形態に本発明を限定するものと解釈すべきではない。

本発明は、移動通信システム内のゲートウェイへのポリシ及び課金情報の転送に関する。アプリケーション・セッション確立中にネゴシエーションする移動端末のアプリケーション・セッション（少なくとも１つのＩＰフローを有する）に対するポリシ及び課金情報は、ゲートウェイに転送される。ゲートウェイは、移動端末と通信相手ノードの間のトンネル内でカプセル化されたデータ・パケットを制御するためにポリシ及び課金情報を必要とする。

ＵＥ及びホーム・ポリシ制御ノードは、別々に、アプリケーション・レベルのＩＰフロー・パラメータからの情報を少なくとも使用して、同一の一意のアプリケーション・セッション識別子を生成する。ポリシ制御ノードにおいては、アプリケーション・セッション識別子は、適切な格納しているポリシ及び課金情報を参照する。ＵＥとゲートウェイの間のベアラ確立／修正シグナリング及び（トンネルした）ユーザ・データ・トランスポートにおいては、生成されたセッション識別子が、ＩＰｖ６ヘッダのＩＰｖ６フロー・レベル・フィールドに含まれる。

ベアラ確立／修正メッセージを受信した場合には、ゲートウェイは、例えば、ネットワーク認証中にＵＥに割り当てられたＩＰアドレスを含むテーブル内においてメッセージのＩＰソース・アドレスを検索することにより、ＵＥ識別子を入手する。

次に、ゲートウェイは、プロキシ／ホーム・ポリシ制御ノードへのシグナリングにＵＥ識別子及びセッション識別子を含ませ、それ故、ホーム・ポリシ制御ノードは、ＵＥ及びセッションを識別することができ、要求しているゲートウェイにポリシ判定を返送する。

無線ネットワークへの接続を確立するために、ＵＥとネットワークの間で相互認証が必要になる。この認証プロセス中に、ＵＥは、シグナリング・メッセージ内のＵＥ識別子（例えば、ＩＭＳＩ（国際移動加入者識別子）、ＮＡＩ（ネットワーク・アクセス識別子）をネットワークのゲートウェイに送信する。

ＵＥ認証の後又は前に、ＵＥは現在のネットワーク内の到着可能なローカルＩＰアドレス（気付アドレス）が必要であり、このＩＰアドレスは、現在のネットワークにトポロジー的に属するものでなければならない。ローカルＩＰアドレスは、サーバにより（例えば、ＤＨＣＰにより）ステートフルに割り当てることもできるし、又はＵＥによりステートレスに生成することもできる。階層的モビリティ管理（例えば、ＨＭＩＰ）が行われているネットワークにおいては、いくつかのローカル、又は、リージョナル及びローカルＩＰアドレスを使用することができる一方、階層的モビリティ管理において、ＵＥに対してローカルＩＰを割り当てる基地局（ＢＳ）又はアクセス・ポイント（ＡＰ）によって、ＵＥに対してそれぞれ透過（トランスペアレント）に隠されていてもよい。

ステートフル又は透過なアドレス割り当てを使用する場合には、割り当て手順中にアドレス割り当てサーバに対してＵＥが識別される。それ故、ＵＥ識別子とローカル的に割り当てられたアドレスとの間には、ネットワーク内で確立されたマッピングが存在する。アドレスがゲートウェイにより直接割り当てられない場合には、対応するアドレス割り当てネットワーク・エンティティ（例えば、ＤＨＣＰ（動的ホスト構成プロトコル）サーバ）により、ＵＥ識別子とローカルＩＰアドレスとの間のマッピングをゲートウェイが入手できるようにしなければならない。

接続確立、認証及びアドレス割り当てが完了した後で、ＵＥは、ＡＳ間ＭＭ（例えば、ホーム・エージェント）にローカルＩＰアドレスを登録する。このことは、通信相手ノードから／へ、ＵＥへ／からのトラフィックが、ＵＥとＡＳ間ＭＭの間のトンネルを通して転送されることを意味する。

ここでユーザは、例えば、ＳＩＰ及びＳＤＰによるＶｏＩＰ呼のようなアプリケーション・セッションを確立することができる。この場合、セッションのあて先／ソースとしてアプリケーションが使用したアドレスは、ＵＥのホームＩＰアドレスであり、ローカルＩＰアドレスでないことを考慮に入れなければならない。アプリケーション・レベルのシグナリング・メッセージは、例えば、ＳＩＰプロキシ又はＩＭＳの場合には各Ｐ−ＣＳＣＦのようなホーム・ネットワーク内のアプリケーション機能（ＡＦ）を通る。セッション確立中、ＵＥ識別子と一緒にセッション情報は、セッションのＩＰフローを許可するために、ホーム・ネットワーク内のポリシ制御ノード（ＰＣＲＦ）に転送される。ＰＣＲＦは、許可手順の結果をＡＦに返送し、ＡＦは、ＵＥにアプリケーション・セッション確立の結果について通知する。

アプリケーション・セッションが許可され、ＩＰフロー・パラメータがネゴシエーションされた後で、ＵＥ及びホーム・ポリシ制御ノードは、アプリケーション・レベルＩＰフロー・パラメータからの情報を少なくとも使用して、別々に、同一の一意のアプリケーション・セッション識別子を生成する。例えば、ＩＰソース／あて先アドレス及びソース／あて先ポート番号は、アプリケーション・セッション識別子を計算するためにハッシュ関数で使用される。ハッシュ関数は、可変長サイズ入力を取り、固定サイズ・ストリングを返す変換である。使用するハッシュ関数は、ＵＥ及びホーム・ポリシ制御ノード内で同一のものであり、ＵＥのＵＳＩＭに組み込むことができる。ホーム・ポリシ制御ノードは、アプリケーション・セッションのために決定したポリシ及び課金規則を参照するために、データベース内の索引として、生成されたアプリケーション・セッション識別子を使用する。

次のステップにおいて、アプリケーション・セッションに対するリソースを、ネットワーク内に確立しなければならない。このために、ＵＥは、ＡＳ間ＭＭへのトンネル用のリソースを設定しなければならないか、又はサポートされた最適化経路指定機構の場合には、ＵＥと通信相手ノードの間の経路を設定しなければならない。また、リソース予約シグナリング・メッセージは、ＵＥとＡＳ間ＭＭの間、又はＵＥと通信相手ノードの間に位置するゲートウェイのそれぞれにより受信される。例えば、最適化経路指定により、又はローミング及び在圏ネットワーク・オペレータ課金又はＱｏＳ制御要件により、ポリシ判定をゲートウェイで行わなければならない場合には、ホーム・ネットワーク内のＰＣＲＦで行ったポリシ判定についてゲートウェイに通知しなければならない。ＵＥと通信相手ノードの間のトンネルに加えて、ローカル・モビリティ管理のために、例えば、ＢＳとゲートウェイの間にもう１つのトンネルがあってもよい。また、このローカル・モビリティ管理のためにトンネル・リソースを設定しなければならない。

ゲートウェイが適切なポリシ判定を入手し、適用することができるようにするために、ＵＥは、リソース予約メッセージのＩＰｖ６ヘッダ及びユーザ・データの外部ヘッダのＩＰｖ６フロー・ラベル・フィールド内に、生成したセッション識別子を含ませる。次に、ゲートウェイは、ローカルＩＰアドレス割り当て中に確立された一致によって、外部ヘッダで使用したローカルＩＰアドレスから、対応するＵＥ識別子を入手することができる。

ＩＰｖ６ヘッダは、図６に示すように、ＩＰｖ４ヘッダと比較すると、フローのラベル付けの包含を含めていくつかの利点を有する。この２０ビットのフロー・ラベル・フィールドは、一連のパケットに関してソースからあて先に対して特殊なルータ処理を指定するために使用される。このことは、ネットワーク層でパケットを区別するために特定のフローのパケットにタグを付けることにより行うことができる。このラベルを使用すれば、ルータはフローを識別するために、パケットの深くチェックしなくてもすむ。何故なら、この情報は、ＩＰパケット・ヘッダ内で入手することができるからである。フロー・ラベルを使用すれば、エンド・システム上のアプリケーションは、ＩＰ層でトラフィックを容易に区別することができ、ＩＰＳｅｃにより暗号化されたパケットに対するＱｏＳ、及びＩＰデータグラムを保護するセキュリティ・アーキテクチャをより容易に提供することができる。

ゲートウェイに接続しているプロキシ・ポリシ制御ノードが存在している場合には、ゲートウェイは、プロキシ・ポリシ制御ノードにＵＥ識別子及びセッション識別子を転送する。プロキシ・ポリシ制御ノードが存在していない場合には、ゲートウェイは、また自分自身で下記のステップを実行することができる。プロキシ・ポリシ制御ノードは、ＵＥ識別子からホーム・ポリシ制御ノードを入手する。例えば、ユーザを識別するためにＮＡＩを使用する場合には、ホーム・ポリシ制御ノードのＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）を組み立てるために範囲部分を使用することができ、ＩＰアドレスを決定するためにＤＮＳを使用することができる。次に、セッションに対するポリシ及び課金規則を求めて、ＵＥ識別子及びセッション識別子を有する要求がホーム・ポリシ制御ノードに送信される。

ホーム・ポリシ制御ノードは、要求内の識別子によって、セッションに対する適切なポリシ及び課金情報を識別することができる。ポリシ及び課金情報は、プロキシ・ポリシ制御ノードに送信される応答に含まれている。プロキシ・ポリシ制御ノードは、ローカル・ポリシ規則によりポリシ及び課金情報を修正することができ、ゲートウェイに最終的なポリシ及び課金情報を転送する。

図４は、ポリシ及び課金制御手順に関連するエンティティの機能を示す。

図５は、ポリシ及び課金制御手順ノードに関連するエンティティ間のシグナリング・フローを示す。

最初のアクセス認証中に、ゲートウェイは、ＵＥ識別子（例えば、ＩＭＳＩ）を入手する（５０１）。ゲートウェイは、ＵＥ識別子へのローカル割り当てＩＰアドレスのマッピングを格納する（５０２）。ＵＥは、セッションを確立し（５０３）、シグナリング・メッセージがアプリケーション機能（例えば、ＳＩＰ−Ｐｒｏｘｙ）に経路指定される。ＡＦは、セッションを許可する（５０４）ために、ＵＥのホーム・ネットワーク内のＰＣＲＦを要求する。ＡＦは、ＵＥにセッション確立の成功について知らせるために（５０５）、ＵＥにメッセージを送信する。

ＩＰセッションを識別するために、ＵＥ及びホーム・ポリシ制御ノードは、例えば、セッションＩＰフローのソース／あて先アドレス／ポートを使用し、（例えば、共通のハッシュ関数により）アプリケーション・セッションに対する一意の識別子を計算する（５０６）。

ＵＥからゲートウェイへのベアラ確立要求において（５０７）、ＵＥは、生成したセッション識別子をＩＰｖ６フロー・ラベル・フィールド内に含ませる。使用するベアラ確立機構により、ゲートウェイからＡＳ間ＭＭ又は通信相手ノードへのベアラ確立は継続することができる。ゲートウェイは、ローカルＩＰアドレスからＵＥ識別子を入手する（５０８）。ゲートウェイは、ＵＥ識別子及びセッション識別子を含む要求をローカル・プロキシ・ポリシ制御ノードに送信する（５０９）（アクセス・ネットワーク識別子も、アクセス意識ポリシ制御を実行するために含ませることができる）。ＵＥ識別子から、プロキシ・ポリシ制御ノードは、ホーム・ポリシ制御ノードを決定する（５１０）。プロキシ・ポリシ制御ノードは、ＵＥのセッションに対するポリシ及び課金情報に関するホーム・ポリシ制御ノードを要求する（５１１）。ホーム・ポリシ制御ノードは、適切なセッション識別子に属するそのポリシ・データベース内のエントリを検索する（５１２）。ホーム・ポリシ制御ノードは、プロキシ・ポリシ制御ノードへの応答（５１３）内に格納されているポリシ及び課金情報を送信する。プロキシ・ポリシ制御ノードは、ゲートウェイにポリシ及び課金情報を送信する（５１４）。ゲートウェイは、ＵＥへ確立したベアラについての応答を送信する（５１５）。

ＵＥとゲートウェイの間のデータ・トラフィック（５１６）のトンネルしたパケットは、適切な計算されたＩＰｖ６フロー・ラベルによりマークが付けられる。

上記手順は、ＵＥがリソース確立を開始するという仮定に基づくものである。しかし、リソース確立がＡＳ間ＭＭにより又は通信相手ノードにより開始する場合であっても、適切なアプリケーション・セッション識別子がパケット・ヘッダに含まれている場合には、ポリシ制御を行うことができる。

さらに、ホーム・ネットワーク内のポリシ及び課金制御の場合には、ＡＳ間ＭＭも、ホームＰＣＲＦからポリシ判定を要求しなければならない。このことは、ゲートウェイで行われる機能と同様に実行することができる。

また、既に確立したリソース又は他の関連するシグナリング・メッセージのリソース修正の場合には、フロー・ラベル・フィールドに、生成したアプリケーション・セッション識別子によりマークを付けなければならない。

移動端末及びホーム・ネットワーク内のポリシ制御ノードでそれぞれ別々に生成した一意のアプリケーション・セッション識別子により、トンネルしたデータ・パケットへのポリシ及び課金情報のマッピングを行うことができる。アプリケーション・セッション識別子は、リソース設定メッセージのヘッダのフィールド内、及びトンネルしたアプリケーション・セッション・データ・パケットの外部ヘッダに含まれている。

本発明の別の実施の形態は、ハードウェア及びソフトウェアを使用する上記種々の実施の形態の実施態様に関する。例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は他のプログラマブル論理装置のようなコンピューティング・デバイス（プロセッサ）により上記種々の方法を実施又は実行することができることを理解することができるだろう。本発明の種々の実施の形態も、これらの装置の組み合わせにより実行又は実施することができる。

さらに、本発明の種々の実施の形態は、また、プロセッサにより実行されるソフトウェア・モジュールにより又はハードウェア内で直接実施することができる。また、ソフトウェア・モジュールとハードウェア実施態様とを組み合わせることもできる。ソフトウェア・モジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどのような任意のタイプのコンピュータ読み取り可能な記憶媒体上に格納することができる。

３ＧＰＰリリース６でのＳＢＬＰによるベアラ許可中のメッセージ及び機能を示す図 ＡＳ間ＭＭを通してトラフィックが経路指定されるいくつかの例示としてのＩＰフロー及びトンネルを含む拡張３ＧＰＰシステム・アーキテクチャの高レベルのアーキテクチャを示す図 トラフィックが最適化経路指定され、ＡＳ間ＭＭを通らないいくつかの例示としてのＩＰフロー及びトンネルを含む拡張３ＧＰＰシステム・アーキテクチャの高レベルのアーキテクチャを示す図 拡張システム・アーキテクチャのポリシ制御のためのエンティティ及び機能を示す図 拡張システム・アーキテクチャのポリシ制御のためのシグナリング・フローを示す図 ＩＰｖ６ヘッダを示す図

Claims (12)

1. ユーザ機器と、ゲートウェイと、前記ユーザ機器のホームネットワークであって、ホームエージェント及びホーム・ポリシ制御ノードを有する前記ホームネットワークとを備えるデータ・パケット・ネットワークにおいてポリシ制御を行うための方法であって、
   前記ユーザ機器が、前記ホームネットワークを経由するセッションを通信相手ノードとの間に確立するステップと、
   前記ユーザ機器が、前記ホームネットワークとは異なるアクセスネットワークから割り当てられたローカルアドレスを使用して、前記ユーザ機器と前記通信相手ノードとの間に前記セッションのための暗号化トンネルを確立するステップと、
   前記ユーザ機器が、前記セッションを一意に識別するセッション識別子を生成するステップと、
   前記ホーム・ポリシ制御ノードが、前記ホームネットワークを経由する前記セッションの確立中に受信した前記セッションに関する情報に基づいて、前記セッション識別子と同一のセッション識別子を生成するステップと、
   前記ゲートウェイが、前記セッションのセッション識別子と、前記セッションのためのポリシとを、前記ホーム・ポリシ制御ノードから受信するステップと、
   前記ユーザ機器が、前記暗号化トンネルを通して送信する前記セッションのデータ・パケットの外部ヘッダに、生成された前記セッション識別子を含ませることによりマークを付けるステップと、
   前記ゲートウェイは、前記マークが付けられた前記データ・パケットに対して、前記ポリシを適用するステップとを含む方法。
2. 前記セッション識別子による、前記データ・パケットの外部ヘッダの前記マーク付けステップが、前記データ・パケットの外部ヘッダのＩＰｖ６ヘッダのフロー・ラベル・フィールドを使用する、請求項１に記載の方法。
3. 前記ユーザ機器による前記セッション識別子を生成するステップ及び前記ホーム・ポリシ制御ノードによる前記セッション識別子を生成するステップにおいて、ハッシュ関数を使用する、請求項１又は２に記載の方法。
4. 前記ハッシュ関数が、入力パラメータとして、前記セッションのソース・アドレス及びあて先アドレスと、ソースポート番号及びあて先ポート番号とを使用する、請求項３に記載の方法。
5. ユーザ機器のホームネットワークであって、ホームエージェント及びホーム・ポリシ制御ノードを有する前記ホームネットワークを備えるデータ・パケット・ネットワーク内でポリシ制御を行うシステムであって、
   前記ホームネットワークを経由するセッションを通信相手ノードとの間に確立し、前記ホームネットワークとは異なるアクセスネットワークから割り当てられたローカルアドレスを使用して、前記通信相手ノードとの間にセッションのための暗号化トンネルを確立し、前記セッションのセッション識別子を生成するユーザ機器と、
   前記ホームネットワークを経由する前記セッションの確立中に受信した前記セッションに関する情報に基づいて、前記セッション識別子と同一のセッション識別子を生成するホーム・ポリシ制御ノードと、
   前記セッションのセッション識別子と、前記セッションのためのポリシとを、前記ホーム・ポリシ制御ノードから受信するゲートウェイとを備え、
   前記ユーザ機器が、前記暗号化トンネルを通して送信する前記セッションのデータ・パケットの外部ヘッダに、前記セッション識別子でマークを付け、
   前記ゲートウェイは、前記マークが付けられた前記データ・パケットに対して、前記ポリシを適用するシステム。
6. 前記セッション識別子による、前記データ・パケットの外部ヘッダの前記マーク付けが、前記データ・パケットの外部ヘッダのＩＰｖ６ヘッダのフロー・ラベル・フィールドを使用する、請求項５に記載のシステム。
7. 前記ユーザ機器及び前記ホーム・ポリシ制御ノードが、前記セッション識別子を生成するために、ハッシュ関数を使用することができる、請求項５又は６に記載のシステム。
8. 前記ハッシュ関数が、入力パラメータとして、前記セッションのソース・アドレス及びあて先アドレス及びソースポート番号及びあて先ポート番号を使用する、請求項７に記載のシステム。
9. 請求項５に記載の前記システムが備える前記ゲートウェイであって、
   前記ユーザ機器が前記ユーザ機器と通信相手ノードとの間に前記セッションのための前記暗号化トンネルを確立するとともに、前記セッションを一意に識別する前記セッション識別子を生成した前記セッションに関して、前記ホーム・ポリシ制御ノードが生成した前記セッション識別子と同一のセッション識別子と、前記セッションのためのポリシとを、前記ホーム・ポリシ制御ノードから受信する受信部と、
   前記ユーザ機器により前記セッションのデータ・パケットの外部ヘッダに、生成された前記セッション識別子を含ませることによりマークが付けられ、前記暗号化トンネルを通して送信された前記データ・パケットに対して、前記ポリシを適用するポリシ適用部とを具備するゲートウェイ。
10. 請求項５に記載の前記システムが備える前記ユーザ機器であって、
    前記ホームネットワークとは異なる前記アクセスネットワークから割り当てられた前記ローカルアドレスを使用して、前記ユーザ機器と前記通信相手ノードとの間に前記セッションのための暗号化トンネルを確立する確立部と、
    前記セッションを一意に識別するセッション識別子を生成する生成部と、
    前記暗号化トンネルを通して送信する前記セッションのデータ・パケットの外部ヘッダに、生成された前記セッション識別子を含ませることによりマークを付けるマーク付加部とを具備するユーザ機器。
11. 前記セッション識別子を生成するために、ハッシュ関数を使用することができる、請求項１０に記載のユーザ機器。
12. 前記ハッシュ関数が、入力パラメータとして、前記セッションのソース・アドレス及びあて先アドレスと、ソースポート番号及びあて先ポート番号とを使用する、請求項１１に記載のユーザ機器。

Images