JP5642888B2 - デュアルスタックをサポートするｉｐ−ｃａｎセッションにおいてアプリケーション検出及び制御を実現する方法及びシステム - Google Patents

Description

本発明は、ポリシー及び課金技術に関し、特に、デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法及びシステムに関する。

第３世代パートナーシッププロジェクトステージ７（３ＧＰＰ Ｒｅｌｅａｓｅ７）標準システム以来、ポリシー及び課金機能は、ポリシー及び課金制御（ＰＣＣ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ）フレームワークによって実現される。ＰＣＣ構造は、多種のアクセス技術に応用可能な機能的なフレームワークであり、例えば、ＰＣＣ構造は、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）の地上無線アクセスネットワーク（ＵＴＲＡＮ：ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）、モバイル通信用グローバルシステム（ＧＳＭ：Ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）／ＧＳＭ進化型高速データレート（ＥＤＧＥ）無線アクセスネットワーク、インターワーキング無線ＬＡＮ（Ｉ−ＷＬＡＮ）及び進化型パケットシステム（ＥＰＳ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）などに応用することができる。

ＰＣＣは、主にポリシー制御及び課金という２つの機能を実現する。図１は、従来のＲｅｌ−１１のＰＣＣ構成構造を示す図であり、以下に、図１に示すＰＣＣ構造における各論理機能エンティティ及びそのインタフェース機能を説明する。図１に示すように、
アプリケーション機能（ＡＦ）は、サービスアプリケーションのアクセスポイントを提供することに用いられ、これらのサービスアプリケーションに用いられたネットワークリソースについて、動的なポリシー制御を行う必要がある。サービス面においてパラメータ交渉を行う場合、ＡＦは、関連するサービス情報をポリシー制御及び課金ルール機能（ＰＣＲＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）エンティティに伝送する。これらのサービス情報がＰＣＲＦのポリシーに一致すると、ＰＣＲＦは、当該交渉を受け、そうでなければ、当該交渉を拒絶し、そしてフィードバックする時にＰＣＲＦが許容可能なサービスパラメータを与える。続いて、ＡＦは、これらのパラメータをユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）に返すことができる。ここで、ＡＦとＰＣＲＦの間のインターフェースは、Ｒｘインターフェースである。

ＰＣＲＦは、ＰＣＣのコアであり、ポリシーの決定と課金ルールの策定を担当することに用いられる。ＰＣＲＦは、サービスデータストリームに基づくネットワーク制御ルールを提供し、これらのネットワーク制御がサービスデータストリームの検出、ゲーティング制御（Ｇａｔｉｎｇ Ｃｏｎｔｒｏｌ）、サービス品質（Ｑｏｓ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御及びデータストリームに基づく課金などを含む。ＰＣＲＦは、その策定されたポリシーと課金ルールをポリシー及び課金実行機能（ＰＣＥＦ：Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｅｎｆｏｒｃｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）エンティティに送信して実行し、同時に、ＰＣＲＦは、これらのルールがユーザの契約情報と一致することを保証する必要がある。ここで、ＰＣＲＦがポリシーと課金ルールを策定する依拠は、ＡＦから取得されたサービスに関する情報、ユーザのサブスクリプションプロファイルリポジトリ（ＳＰＲ：Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｐｒｏｆｉｌｅ Ｒｅｐｏｓｉｔｏｒｙ）から取得されたポリシー制御及び課金に関するユーザポリシー課金制御契約情報、及びＧｘインターフェースを介してＰＣＥＦから取得された、ベアラに関連するネットワークの情報を含む。

ＰＣＥＦは、通常、ゲートウェイ（ＧＷ：Ｇａｔｅ−Ｗａｙ）内に位置し、ベアラ面においてＰＣＲＦによって策定されたポリシーと課金ルールを実行する。ＰＣＥＦは、ＰＣＲＦからのルールにおけるサービスデータストリームフィルタに従って、サービスデータストリームを検出し、更にこれらのサービスデータストリームに対してＰＣＲＦによって策定されたポリシーと課金ルールを実行し、ベアラが確立された場合、ＰＣＥＦは、ＰＣＲＦからのルールに従ってリソースを割り当てて、そしてＡＦから提供された情報によってゲーテッドコントロールを行い、同時に、ＰＣＥＦは、ＰＣＲＦによってサブスクライブされたイベントトリガーによって、ベアラネットワークに発生したイベントを報告し、ＰＣＲＦからの課金ルールに従って、ＰＣＥＦは、対応するサービスデータストリームの課金操作を実行し、課金がオンライン課金であってよく、オフライン課金であってもよい。オンライン課金とした場合、ＰＣＥＦは、オンライン課金システム（ＯＣＳ：Ｏｎｌｉｎｅ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ）と共に信用管理を行うことが必要となり、オフライン課金とした場合、ＰＣＥＦは、オフライン課金システム（ＯＦＣＳ：Ｏｆｆｌｉｎｅ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ）と関連する課金情報を交換することが必要となる。ここで、ＰＣＥＦとＰＣＲＦの間のインターフェースがＧｘインターフェースであり、ＰＣＥＦとＯＣＳの間のインターフェースがＧｙインターフェースであり、ＰＣＥＦとＯＦＣＳの間のインターフェースがＧｚインターフェースである。ＰＣＥＦは、サービス検出機能（ＴＤＦ：Ｔｒａｆｆｉｃ Ｄｅｔｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）を持ってもよい。ＰＣＥＦは、ローカル構成又はＰＣＲＦからの、アプリケーション検出制御ポリシーを含むＰＣＣルールに従って、アプリケーション検出を行ってポリシー実行（例えば、ゲーティッド、リダイレクトと帯域幅の制限）を行う。ＰＣＥＦは、一般的に、ＥＰＳのパケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）、汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）におけるＧＰＲＳゲートウェイサポートノード（ＧＧＳＮ）及びインターワーキング無線ＬＡＮ（Ｉ−ＷＬＡＮ：Ｉｎｔｅｒｗｏｒｋｉｎｇ ＷＬＡＮ）におけるパケットデータゲートウェイ（ＰＤＧ：Ｐａｃｋｅｔ Ｄａｔａ Ｇａｔｅｗａｙ）などのようなネットワークのゲートウェイに位置する。

ＴＤＦは、独立して配置されてもよく、この場合、ＴＤＦは、ＰＣＲＦとＳｄインターフェースを介して接続し、ＴＤＦは、予めに設定された又はＰＣＲＦからのアプリケーション検出制御（ＡＤＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｃｏｎｔｒｏｌ）ルールに従って、アプリケーション検出とポリシー実行を行うことができる。

ベアラバインディング及びイベント報告機能（ＢＢＥＲＦ：Ｂｅａｒｅｒ Ｂｉｎｄｉｎｇ ａｎｄ Ｅｖｅｎｔ Ｒｅｐｏｒｔｉｎｇ Ｆｕｎｃｔｉｏｎ）は、通常に、アクセスネットワークのゲートウェイ（Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）内に位置する。例えば、ユーザ装置がＥ−ＵＴＲＡＮを介してＥＰＳにアクセスし、サービスゲートウェイＳ−ＧＷとＰ−ＧＷとの間はプロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６：Ｐｒｏｘｙ Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ６）を用いる場合、Ｓ−ＧＷにはＢＢＥＲＦが存在する。ユーザ装置が信頼できる非３ＧＰＰアクセスネットワークを介してアクセスする場合、信頼できる非３ＧＰＰアクセスゲートウェイにもＢＢＥＲＦが存在する。

サブスクリプションプロファイルリポジトリ（ＳＰＲ）には、ポリシー制御と課金に関するユーザポリシー課金制御契約情報が記憶されている。ＳＰＲとＰＣＲＦとの間のインターフェースは、Ｓｐインターフェースである。

ＯＣＳとＰＣＥＦは、一緒にオンライン課金モードでのユーザ信用の制御と管理を完了させる。

ＯＦＣＳとＰＣＥＦは、一緒にオフライン課金モードでの課金操作を完了させる。

図２は、従来のＩＰ−ＣＡＮセッションにおいて、ＴＤＦとＰＣＲＦがＴＤＦセッションを確立するフローチャートである。ここで、ＴＤＦは、非要求報告モードである。図２に示すように、具体的に以下のステップを含む。

ステップ２０１：ＵＥがＩＰ−ＣＡＮセッションの確立を要求する過程で、ＰＣＥＦが位置するゲートウェイは、ユーザＩＤとアクセスするように要求されたＰＤＮネットワークのＰＤＮＩＤを含むＩＰ−ＣＡＮセッションの確立要求メッセージを受信した。

ステップ２０２：ＰＣＥＦは、ユーザＩＤ、ＰＤＮＩＤ及びＵＥに割り当てられたＩＰｖ６アドレスプレフィックスを含むＩＰ−ＣＡＮセッションの確立要求指示メッセージをＰＣＲＦへ送信する。

ステップ２０３：ＰＣＲＦは、ユーザＩＤによって当該ユーザの契約情報がないと判断したのち、ユーザＩＤとＰＤＮＩＤを含む契約ドキュメント要求をＳＰＲへ送信する。

ステップ２０４：ＳＰＲは、ユーザＩＤとＰＤＮＩＤによって対応するユーザ契約情報を返す（契約ドキュメントの応答により返す）。

ステップ２０５：ＰＣＲＦは、戻されたユーザ契約情報、ネットワークポリシー、ＵＥのアクセス情報などによってポリシーを策定する。ＰＣＣルールとイベントトリガーを策定することが含まれる。

ステップ２０６：ＰＣＲＦは、ＰＣＣルールとイベントトリガーを含むＩＰ−ＣＡＮセッションの確立確認メッセージをＰＣＥＦへ送信する。

ステップ２０７：ＰＣＥＦは、ポリシーをインストールし、ＰＣＥＦに位置するゲートウェイは、ＩＰｖ６アドレスプレフィックスを含むＩＰ−ＣＡＮセッションの確立応答をＵＥへ戻る。

図２に示すようなフローを実行した後、ＵＥは、ＩＰｖ６アドレスプレフィックスによってＩＰｖ６アドレスを構成し、そして当該ＩＰｖ６アドレスを用いてサービスにアクセスする。

ステップ２０８：ＴＤＦは、それを流れるデータストリームを検出する時に、１つの新しいＩＰｖ６アドレス（当該ＩＰｖ６アドレスは、ステップ２０７においてＵＥがＩＰｖ６アドレスプレフィックスによって構造されたものである）が検出した場合、ＴＤＦは、当該新しいＩＰｖ６アドレスを含むＴＤＦセッション確立メッセージをＰＣＲＦへ送信する。

ステップ２０９：ＰＣＲＦは、ＰＣＥＦから取得されたＩＰｖ６アドレスプレフィックスとＴＤＦから取得されたＩＰｖ６アドレスによって、ＴＤＦセッションとＩＰ−ＣＡＮセッションを関連付けて、ＴＤＦへＴＤＦセッションの確立確認メッセージを返す。確立されたＴＤＦセッションはＵＥが確立されたＩＰ−ＣＡＮセッションに対応する。

続いて、ＴＤＦは、予めに設定されたＡＤＣルールに従って、送信元アドレスが上記の新しいＩＰｖ６アドレスである上りサービスデータストリーム、及び／又は送信先アドレスが当該新しいＩＰｖ６アドレスである下りサービスデータストリームに対してアプリケーション検出及び制御を行い、ＴＤＦは、予め設定されたアプリケーション検出ポリシーにおいて指定されたアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ ＩＤで識別される）を検出した。ＴＤＦは、ステップ２０８とステップ２０９で確立されたＴＤＦセッションによりＰＣＲＦへサービス検出レポートを送信し、検出されたＡｐｐｌｉｃａｔｉｏｎ ＩＤ及び選択可能なイベントトリガーを含んで、アプリケーショントラヒックの検出開始（Ｓｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）とアプリケーショントラヒックの検出停止（Ｓｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）に値を取り、ＰＣＲＦがＴＤＦからＳｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎのイベントトリガーをサブスクライブした場合、ＴＤＦは、ＰＣＲＦへサービスデータストリーム説明（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｆｌｏｗ Ｄｅｓｃｒｉｐｔｉｏｎ）を提供する場合もある。ＰＣＲＦは、ＴＤＦから報告されたＡｐｐｌｉｃａｔｉｏｎ ＩＤ、サービスデータストリーム説明（報告した場合）によってポリシーの決定を行い、ＰＣＣルールを策定する又は更新し、ＰＣＥＦに提供する。

従来技術において、デュアルスタック問題、すなわちＩＰ−ＣＡＮセッション毎にＩＰｖ４アドレスとＩＰｖ６アドレスがあるという問題が考慮されていない。図２に示すフローを実行した後、ＰＣＥＦに位置するゲートウェイ又は外部の他のネットワークエレメントは、ＵＥの要求に応じて、もう１つのＩＰｖ４アドレスを割り当てて、且つＵＥが当該ＩＰｖ４アドレスを用いてサービスにアクセスする場合、ＴＤＦは、１つの新しいＩＰｖ４アドレスを見つけたら、ＴＤＦセッションの確立を開始し、確立されたＴＤＦセッションによりＰＣＲＦへアプリケーション検出結果を報告する。

このようにすると、その結果、すなわちＩＰ−ＣＡＮセッション毎に同時に２つのＴＤＦセッションが存在することを引き起こし、且つ同じＩＰ−ＣＡＮセッションのサービス検出について異なるＴＤＦセッションにより報告する必要がある。一方、リソースを浪費し、他方、シグナリングオーバーヘッドを増加した。

また、ＴＤＦを独立的に配置し、且つ報告要求のモードを用いる場合にも、同様の問題が発生する。図３に示すように、この場合、ＴＤＦセッションを確立するフローは、以下のステップを含む。

ステップ３０１：ＵＥがＩＰ−ＣＡＮセッションの確立を要求する過程で、ＰＣＥＦに位置するゲートウェイは、ユーザＩＤとアクセスするように要求されるＰＤＮネットワークのＰＤＮＩＤを含むＩＰ−ＣＡＮセッションの確立要求メッセージを受信する。

ステップ３０２：ＰＣＥＦは、ユーザＩＤとアクセスするように要求されるＰＤＮネットワークのＰＤＮＩＤを含むＩＰ−ＣＡＮセッションの確立指示メッセージをＰＣＲＦへ送信する。

ステップ３０３：ＰＣＲＦは、ユーザＩＤによって当該ユーザの契約情報がないと判定した後、ユーザＩＤとＰＤＮＩＤを含む契約ドキュメント要求をＳＰＲへ送信する。

ステップ３０４：ＳＰＲは、ユーザＩＤとＰＤＮＩＤによって対応するユーザ契約情報を返す（契約ドキュメント応答により返す）。ユーザ契約情報にはユーザドキュメント構成、アプリケーション検出及び制御をアクティブにすることを示すなどの情報が含まれる。

ステップ３０５：ＰＣＲＦは、戻されたユーザ契約情報、ネットワークポリシー、ＵＥのアクセス情報などによってポリシーを策定する。ＰＣＣルールと選択可能なイベントトリガーの策定が含まれる。本ステップでは、ユーザ契約情報にユーザドキュメント構成が含まれるため、ＰＣＲＦは、ＡＤＣルールを策定する必要もあり、ＡＤＣルールには、ＰＣＥＦの検出必要のアプリケーションＩＤ（Ａｐｐｌｉｃａｔｉｏｎ ＩＤ）を設定することと、Ｓｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎに値を取るイベントトリガーを設定することと、各検出可能なアプリケーションに対応する、ゲーティッド、最大帯域幅とリダイレクトなどを含む実行ポリシーと、が含まれる。

ステップ３０６：ＰＣＲＦは、当該ＴＤＦセッション確立要求メッセージにＩＰｖ６アドレスプレフィックス、ＡＤＣルールと選択可能な、Ｓｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎに値を取るイベントトリガーを含むＴＤＦセッション確立要求をＴＤＦへ送信する。

ステップ３０７：ＴＤＦは、ポリシーを実行し、ＡＤＣルールとイベントトリガーをインストールしまたはアクティブにする。

ステップ３０８：ＴＤＦは、ＰＣＲＦへＴＤＦセッション確立の確認メッセージを返す。

ステップ３０９：ＰＣＲＦは、ＰＣＣルールとイベントトリガーを含むＩＰ−ＣＡＮセッション確立の確認メッセージをＰＣＥＦへ送信する。

ステップ３１０：ＰＣＥＦは、ポリシーをインストルし、ＰＣＥＦに位置するゲートウェイが、ＩＰｖ６アドレスプレフィックスを含むＩＰ−ＣＡＮセッション確立応答をＵＥへ返す。

図３に示すフローにより、ＵＥは、ＩＰｖ６アドレスプレフィックスによってＩＰｖ６アドレスを構成し、且つＩＰｖ６アドレスを用いてサービスにアクセスすることができる。確立されたＴＤＦセッションは、ＵＥが確立されたＩＰ−ＣＡＮセッションに対応する。

続いて、ＴＤＦは、ＰＣＲＦからのＡＤＣルールに従って、送信元アドレスが当該ＩＰｖ６アドレス（ＴＤＦがＰＣＲＦによって取得されたＩＰｖ６アドレスプレフィックスから唯一的に確定できるＩＰｖ６アドレス）である上りサービスデータストリーム、及び又は送信先アドレスが当該ＩＰｖ６アドレスである下りサービスデータストリームに対してアプリケーション検出及び制御を行う。ＴＤＦがＡｐｐｌｉｃａｔｉｏｎ ＩＤに対応するアプリケーションを検出し且つＰＣＲＦがＳｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎをサブスクライブした場合、ＴＤＦは、ステップ３０６〜ステップ３０８で確立されたＴＤＦセッションによりＰＣＲＦへサービス検出レポートを送信し、検出されたＡｐｐｌｉｃａｔｉｏｎ ＩＤ及びＳｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎに値を取るイベントトリガーをキャリーし、ＰＣＲＦは、報告されたＡｐｐｌｉｃａｔｉｏｎ ＩＤによってポリシーの決定を行い、実行ポリシー（例えば、ゲーティッド、最大帯域幅とリダイレクトなど）を設定しまたは更新し、ＰＣＣルールを策定しまたは更新してＰＣＥＦに提供する。

図３に示すフローを実行した後、ＰＣＥＦが位置するゲートウェイ又は外部の他のネットワークエレメントがＵＥの要求に応じて、もう１つのＩＰｖ４アドレスを割り当てて、且つＵＥが当該ＩＰｖ４アドレスを用いてサービスにアクセスする場合、ＴＤＦは、サービスデータを検出すると１つの新しいＩＰｖ４アドレスのサービスデータストリームを見つけたことがあり、ＴＤＦが当該ＩＰｖ４アドレスのサービスデータストリームを検出する必要があると通知されていいないし、当該サービスデータストリームを検出することに対応するＡＤＣルールもないので、ＴＤＦは、当該サービスデータストリームを検出しない。この場合、ＰＣＲＦは、１つの新しいＴＤＦセッションの確立要求を開始して、１つのＩＰ−ＣＡＮセッションに同時に２つのＴＤＦセッションが存在することを引き起こし、且つ同じＩＰ−ＣＡＮセッションのサービス検出について異なるＴＤＦセッションにより報告する必要がある。一方、リソースを浪費し、他方で、シグナリングオーバーヘッドを増加した。

これを鑑みて、本発明の主な目的は、リソースを節約し、シグナリングオーバーヘッドを減らすことができるように、デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法を提供することにある。

前記目的を実現するために、本発明の技術案は、以下のように実現される。

デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法は、ユーザ装置ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを取得して、更にＩＰｖ４アドレスを取得するステップを含み、前記方法は、更に、
ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、割り当てられたＩＰｖ４アドレスをＴＤＦに通知するステップと、
前記ＴＤＦが、取得されたＩＰｖ４アドレスと前記確立されたＴＤＦセッションとを関連付けるステップとを含む。

更に、前記ＴＤＦが、ＩＰｖ４アドレスとＴＤＦセッションとを関連付けた後、前記方法は、更に、前記ＰＣＲＦがアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、前記ＴＤＦが、検出された、前記ＩＰｖアドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すステップとを含む。

更に、前記方法は、更に、前記ＴＤＦが前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスが前記ＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うステップを含む。

更に、前記方法は、更に、前記ＴＤＦセッションに関するＡＤＣルールが、ＩＰ−ＣＡＮセッションの、ＩＰ６アドレスに応用されるアプリケーション検出制御ＡＤＣルール、及び／又は単独でＩＰｖ４アドレスに応用されるＡＤＣルールを含むステップを含む。

更に、前記方法は、更に、前記ＩＰｖ４アドレスが解放された場合、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、解放されたＩＰｖ４アドレスを前記ＴＤＦに通知するステップと、前記ＴＤＦが前記ＩＰｖ４アドレスと前記ＴＤＦセッションとの関連関係を解除するステップとを含む。

更に、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、解放されたＩＰｖ４アドレスを前記ＴＤＦに通知するステップは、ＰＣＥＦが、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスちを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信するステップと、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを解放し、ＰＣＥＦへ確認メッセージを返すステップと、
前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信する。

更に、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、割り当てられたＩＰｖ４アドレスをＴＤＦに通知するステップは、
前記ＰＣＥＦが、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信し、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶し、ＰＣＥＦへ確認メッセージを返すステップと、
前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信するステップとを含む。

デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現するシステムであって、前記システムは、少なくともＰＣＲＦ、ＰＣＥＦ、ＴＤＦ及びＵＥを含み、ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを取得することに用いられ、ここで、
ＰＣＥＦが、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信することに用いられ、
ＰＣＲＦが、前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶して、ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、アドレスＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信することに用いられ、
ＴＤＦが、前記ＩＰｖ４アドレスと前記ＴＤＦセッションを関連付けて、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられる。

更に、ＴＤＦは、更に、前記ＰＣＲＦが自身からアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すことに用いられる。

更に、前記ＰＣＥＦは、更に、ＩＰアドレスの解放指示と解放されたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッション変更指示メッセージを前記ＰＣＲＦへ送信することに用いられる。

前記ＰＣＲＦは、更に、前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを解放し、前記ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求を前記ＴＤＦへ送信することに用いられる。

前記ＴＤＦは、更に、前記ＩＰｖ４アドレスと前記ＴＤＦセッションとの関連関係を解除して、前記ＰＣＲＦに確認メッセージを返信することに用いられる。

ＴＤＦであって、前記ＴＤＦは、ＰＣＲＦからのＩＰｖ４アドレスとＴＤＦセッションとを関連付けて、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられる。

更に、前記ＴＤＦは、更に、前記ＰＣＲＦが自身からアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すことに用いられる。

本発明の別の方面に基づいて、本発明の別の目的は、ＵＥがもう１つのＩＰｖ４アドレスを取得した場合、ＴＤＦが当該ＩＰｖ４アドレスを取得できるように、ユーザ装置ＵＥのＩＰアドレスをアプリケーション検出機能ＴＤＦに通知する方法を提供することにある。

前記のもう１つの目的を達成するために、本発明の別の技術案は、以下のように実現される。

ＵＥのＩＰアドレスをＴＤＦに通知する方法であって、ＩＰ−ＣＡＮセッションを確立するステップを含み、前記方法は、更に、ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＰＣＲＦへ通知するステップと、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスを前記ＴＤＦに通知するステップとを含む。

更に、ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＰＣＲＦへ通知するステップは、前記ＰＣＥＦが、ＩＰアドレス割り当て指示と前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスとを含む通知メッセージを前記ＰＣＲＦへ送信することを含む。

更に、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスを前記ＴＤＦに通知するステップは、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスとを含む通知メッセージを前記ＴＤＦへ送信することを含む。

更に、前記ＩＰｖ４アドレスが解放された場合、前記方法は、更に、前記ＰＣＥＦが、前記ＩＰｖ４アドレスが解放されたことを前記ＰＣＲＦに通知するステップと、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知するステップとを含む。

ＵＥのＩＰアドレスをＴＤＦに通知するシステムであって、前記システムは、少なくともＰＣＲＦ、ＰＣＥＦ、ＴＤＦ及びＵＥを含み、前記ＵＥがＩＰ−ＣＡＮセッションを確立することに用いられ、ここで、
前記ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスを前記ＰＣＲＦに通知することに用いられ、
前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスを前記ＴＤＦに通知することに用いられ、
前記ＴＤＦが、前記ＰＣＥＦからの通知を受信して、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスを取得することに用いられる。

更に、前記ＰＣＥＦは、更に、前記ＩＰｖ４アドレスが解放された場合、前記ＩＰｖ４アドレスが解放されたことを前記ＰＣＲＦに通知することに用いられ、前記ＰＣＲＦは、更に、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知することに用いられる。

ＰＣＲＦであって、前記ＰＣＲＦは、ＰＣＥＦがＵＥによって新たに割り当てられたＩＰｖ４アドレスを自身に通知した後、ＩＰ−ＣＡＮセッションに対応する確立されたＴＤＦセッションを介して、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＴＤＦに通知することに用いられる。

更に、前記ＰＣＲＦは、更に、ＰＣＥＦが前記ＩＰｖ４アドレスが解放されたことを自身に通知した後、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知することに用いられる。

上記本発明に係る技術案から分かるように、本発明の方法において、デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいて、ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを用いてサービスにアクセスした後、ＰＣＥＦが位置するゲートウェイ又は外部の他のネットワークエレメントが、ＵＥの要求に応じて、もう１つのＩＰｖ４アドレスを割り当てて、且つＵＥが当該ＩＰｖ４アドレスを用いてサービスにアクセスする場合、ＰＣＲＦは、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰｖ４アドレスをＴＤＦに通知し、ＴＤＦは、確立されたＩＰ−ＣＡＮセッションの、ＩＰｖ６アドレスに用いられるＡＤＣルール及び／又は単独でＩＰｖ４アドレスに用いられるＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行う。本発明の方法によれば、ＰＣＲＦは、更に１つの新しいＴＤＦセッション確立要求を開始しない。このように、同じＩＰ−ＣＡＮセッションのサービス検出について同一のＴＤＦセッションのみで報告することができ、リソースを節約し、シグナリングオーバーヘッドを減らした。

従来のＲｅｌ−１１のＰＣＣ構成構造を示す図である。 従来のＩＰ−ＣＡＮセッション過程で、ＴＤＦとＰＣＲＦがＴＤＦセッションを確立するフローチャートである。 従来のＩＰ−ＣＡＮセッション過程で、ＩＰ−ＣＡＮセッション過程で、ＴＤＦセッションを確立する別のフローチャートである。 本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法のフローチャートである。 本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現するシステムの構成構造を示す図である。 本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法の第１の実施形態のフローチャートである。 本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法の第２の実施形態のフローチャートである。

図４は、本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法のフローチャートである。図４に示すように、以下のステップを含む。

ステップ４００：ＵＥは、ＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを取得して、ＩＰｖ６アドレスを用いてサービスにアクセスする。本ステップは、従来技術であり、具体的に、図２と図３に示すように実現される。

ステップ４０１：確立されたＩＰ−ＣＡＮセッションのＩＰｖ４アドレスが割り当てられた場合、ＰＣＲＦは、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、当該ＩＰｖ４アドレスをＴＤＦに通知する。

本ステップでは、確立されたＩＰ−ＣＡＮセッションのＩＰｖ４アドレスが割り当てられることは、ＰＣＥＦに位置するゲートウェイ又は外部の他のネットワークがＵＥの要求に応じて、もう１つのＩＰｖ４アドレスを割当てて、且つＵＥが当該ＩＰｖ４アドレスを用いてサービスにアクセスする。この場合に、
ＰＣＥＦは、ＩＰアドレスの割り当て指示と割り当てられたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッションの変更指示メッセージをＰＣＲＦへ送信し、ＰＣＲＦは、ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶し、ＰＣＥＦへ確認メッセージを返す。

ＰＣＲＦは、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレスの割り当て指示と割り当てられたＩＰｖ４アドレスを含むＴＤＦセッションの変更要求をＴＤＦへ送信する。

ステップ４０２：ＴＤＦは、取得されたＩＰｖ４アドレスと前記確立されたＴＤＦセッションを関連付けて、受信されたＩＰｖ４アドレスを記憶する。

更に、本発明の方法は、以下のステップを含む。

ステップ４０３：ＴＤＦは、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータ（ユーザプレーンデータとも称される）に対してアプリケーション検出及び制御を行う。

ステップ４０３は、更に、前記ＰＣＲＦがＴＤＦへアプリケーショントラフィック検出開始（Ｓｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）とアプリケーショントラフィック検出停止（Ｓｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）のイベントをサブスクライブした場合、ＴＤＦが検出された、当該ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションによりＰＣＲＦに返すことを含む。ここで、どのように対応するアプリケーション情報を検出するかについて、従来技術に属することであり、具体的に実現するのは、本発明の保護範囲に限定されるものではない。

前記ＩＰｖ４アドレスが解放された場合、当該方法は、更に、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、解放されたＩＰｖ４アドレスをＴＤＦに通知するステップと、ＴＤＦが、受信されたＩＰｖ４アドレスを解放して、ＩＰｖ４アドレスと確立されたＴＤＦセッションとの関連関係を解除するステップとを含む。ＴＤＦは、当該ＴＤＦセッションに関するＡＤＣルールを解放されたＩＰｖ４アドレスとマッチングするサービスデータストリーム（ユーザプレーンデータとも称される）に応用することを、停止し、アプリケーション情報の検出を行う。

具体的には以下のステップを含む。

ＰＣＥＦは、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスちを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信し、前記ＰＣＲＦは、ＩＰ−ＣＡＮセッション変更指示メッセージに携帯されたＩＰｖ４アドレスを解放し、ＰＣＥＦへ確認メッセージを返す。

ＰＣＲＦは、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信する。

本発明の方法において、デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいて、ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを用いてサービスにアクセスした後、ＰＣＥＦが位置するゲートウェイ又は他の外部のネットワークエレメントがＵＥの要求に応じてもう１つのＩＰｖ４アドレスを割り当てて、且つＵＥが当該ＩＰｖ４アドレスを用いてサービスにアクセスする場合、ＰＣＲＦは、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰｖ４アドレスをＴＤＦに通知し、ＴＤＦは、確立されたＩＰ−ＣＡＮセッションのＩＰｖ６アドレスに用いられるＡＤＣルール及び／又は単独でＩＰｖ４アドレスに用いられるＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行う。本発明の方法によれば、ＰＣＲＦは、もう１つの新しいＴＤＦセッション確立要求を開始しない。このように、同じＩＰ−ＣＡＮセッションのサービス検出について同一のＴＤＦセッションのみで報告することができ、リソースを節約し、シグナリングオーバーヘッドを減らした。

本発明の方法について、デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現するシステムを提供する。図５に示すように、少なくともＰＣＲＦ、ＰＣＥＦ、ＴＤＦ及びＵＥ（未図示）を含み、ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを用いてサービスにアクセスすることに用いられ、ここで、
ＰＣＥＦが、ＩＰアドレスの割り当て指示と割り当てられたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッションの変更指示メッセージをＰＣＲＦへ送信することに用いられ、
ＰＣＲＦが、ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶し、ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信することに用いられ、
ＴＤＦが当該ＩＰｖ４アドレスと確立されたＴＤＦセッションを関連付けて、受信されたＩＰｖ４アドレスを記憶し、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられる。

ここで、ＴＤＦは、更に、前記ＰＣＲＦが自身へアプリケーショントラフィック検出開始（Ｓｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）とアプリケーショントラフィック検出停止（Ｓｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ）のイベントトリガーをサブスクライブした場合、検出された、当該ＩＰｖ４アドレスに関するアプリケーション情報を、当該ＴＤＦセッションによりＰＣＲＦに返すことに用いられることができる。

ＰＣＥＦは、更に、ＰＣＲＦへＩＰアドレスの解放指示と解放されたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッション変更指示メッセージを送信することに用いられる。

ＰＣＲＦは、更に、ＩＰ−ＣＡＮセッションの変更指示メッセージに携帯されたＩＰｖ４アドレスを解放し、ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信することに用いられる。

ＴＤＦは、更に、ＩＰｖ４アドレスと確立されたＴＤＦセッションとの関連関係を解除して、受信されたＩＰｖ４アドレスを解放し、ＰＣＲＦへ確認メッセージを返答する。

それに応じて、ＴＤＦを提供する。前記ＴＤＦは、ＰＣＲＦからのＩＰｖ４アドレスとＴＤＦセッションとを関連付けて、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられる。

ここで、前記ＴＤＦは、更に、前記ＰＣＲＦが自身からアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すことに用いられることができる。

本発明は、ＵＥがもう１つのＩＰｖ４アドレスを取得した場合、ＴＤＦが当該ＩＰｖ４アドレスを取得することができるように、ＵＥのＩＤアドレスをＴＤＦに通知する方法を提供する。当該方法は、ＩＰ−ＣＡＮセッションを確立するステップを含み、更に、ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＰＣＲＦへ通知するステップと、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスを前記ＴＤＦに通知するステップとを含む。

更に、ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＰＣＲＦへ通知するステップは、前記ＰＣＥＦが前記ＩＰ−ＣＡＮセッションにより、ＩＰアドレス割り当て指示と前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスとを含む通知メッセージを前記ＰＣＲＦへ送信することを含む。

更に、前記ＰＣＲＦが前記ＩＰ−ＣＡＮセッションによって確立された前記ＴＤＦセッションにより、前記ＩＰｖ４アドレスを前記ＴＤＦに通知することは、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスとを含む通知メッセージを前記ＴＤＦへ送信することを含む。

更に、前記ＩＰｖ４アドレスが解放された場合、当該方法は、更に、前記ＰＣＥＦが、前記ＩＰｖ４アドレスが解放されたことを前記ＰＣＲＦに通知するステップと、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知するステップとを含む。

それに応じて、本発明は、ＰＣＲＦを更に提供する。前記ＰＣＲＦは、ＰＣＥＦがＵＥによって新たに割り当てられたＩＰｖ４アドレスを自身に通知した後、ＩＰ−ＣＡＤセッションに対応する確立されたＴＤＦセッションにより、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＴＤＦに通知することに用いられる。

ここで、前記ＰＣＲＦは、更に、ＰＣＥＦが前記ＩＰｖ４アドレスが解放されたことを自身に通知した後、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知することに用いられる。

本発明は、ＵＥのＩＰアドレスをＴＤＦに通知するシステムを更に提供し、ＰＣＥＦ、ＵＥ、上記のＰＣＲ及びＴＤＦが含まれ、前記ＵＥがＩＰ−ＣＡＮセッションを確立することに用いられ、ここで、ＰＣＥＦが前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスを前記ＰＣＲＦに通知することに用いられ、前記ＴＤＦが前記ＰＣＲＦの通知を受信して、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスを取得することに用いられる。

ここで、前記ＰＣＥＦ、ＰＣＲＦ及びＴＤＦは、いずれも前記ＵＥが前記ＩＰ−ＣＡＮセッションを確立する過程に加入することがある。

ここで、前記ＰＣＥＦは、更に、前記ＩＰｖ４アドレスが解放された場合、前記ＩＰｖ４アドレスが解放されたことを前記ＰＣＲＦに通知することに用いられ、前記ＰＣＲＦは、更に、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知することに用いられる。

以下、図６と図７を参照しながら本発明の方法を詳細に説明する。

図６は、本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法の第１の実施形態のフローチャートである。第１の実施形態において、仮定に、ＴＤＦが独立的に配置され、且つ図２又は図３のフローに従って、ＴＤＦとＰＣＲＦがＴＤＦセッションを確立したとし、その後、ＩＰｖ４アドレスが割り当てられた場合、当該方法は、以下のステップを含む。

ステップ６０１：ＰＣＥＦが位置するゲートウェイ又は他のネットワークエレメントは、ＵＥの要求に応じて、当該ＵＥに１つのＩＰｖ４アドレスをさらに割り当てる。

ステップ６０２：ＰＣＥＦは、ＩＰアドレスの割り当て指示と割り当てられたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッションの変更指示メッセージをＰＣＲＦへ送信する。具体的に実現する場合、ＩＰアドレスの割り当て指示は、ＵＥ−ＩＰ−ＡＤＤＲＥＳＳ−ＡＬＬＯＣＡＴＥに値を取るイベントトリガーｅｖｅｎｔ ｔｒｉｇｇｅｒである。

ステップ６０３：ＰＣＲＦは、ＩＰｖ４アドレスを記憶してＰＣＥＦへＩＰ−ＣＡＮセッションの変更確認メッセージを返す。

ステップ６０４：ＰＣＲＦは、図２に示すフローにおけるステップ２０８〜ステップ２０９、又は図３に示すフローにおけるステップ３０６〜ステップ３０８で確立されたＴＤＦセッションにより、アドレスＩＰアドレスの割り当て指示と割り当てられたＩＰｖ４アドレスを含むＴＤＦセッション変更要求をＴＤＦへ送信する。具体的に実現する場合、ＰＣＲＦがＴＤＦへ送信するセッションの変更要求メッセージに属性値ペア（Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ：ＡＶＰ）が含まれ、且つ当該ＡＶＰに、ＵＥ−ＩＰ−ＡＤＤＲＥＳＳ−ＡＬＬＯＣＡＴＥに値を取るｅｖｅｎｔ ｔｒｉｇｇｅｒと割り当てられたＩＰｖ４アドレスが含まれる。

ステップ６０５：ＴＤＦは、当該ＵＥにもう１つのＩＰｖ４アドレスが割り当てられたことを取得する。ＴＤＦは、新たに割り当てられたＩＰｖ４アドレスを記憶して、ＰＣＲＦへＴＤＦセッションの変更要求確認メッセージを返す。

図６に示すフローにより、ＴＤＦは、当該ＩＰｖ４アドレスとその前のＩＰｖ６アドレスが同じＩＰ−ＣＡＮセッションに属することを取得した。ＴＤＦは、ＩＰｖ４アドレスと確立されたＴＤＦセッションを関連付ける。ＴＤＦは、その前にＩＰｖ６アドレスに用いられたＡＤＣルール（すなわち、ＰＣＲＦからのもの、又はＰＣＥＦのローカルに予めに設定されたもの）に従って、送信元アドレスが当該ＩＰｖ４アドレスとする上りサービスデータストリーム（ユーザプレーンデータとも称される）、及び／又は送信先アドレスが当該ＩＰｖ４アドレスとする下りサービスデータストリームに対してアプリケーション検出及び制御を行い、ＩＰｖ６アドレスのために確立されたＴＤＦセッションにより、検出されたアプリケーション及びサービスデータストリーム説明などの情報を報告する。なお、ＰＣＲＦは、確立されたＴＤＦセッションにより、単独でＩＰｖ４アドレスに用いられるＡＤＣルールを送信することもできる。ＴＤＦは、ＰＣＲＦからの単独でＩＰｖ４アドレスに用いられるＡＤＣルール又はＰＣＥＦのローカルに予めに設定された単独でＩＰｖ４アドレスに用いられるＡＤＣルールに従って、アプリケーション検出及び制御を行う。すなわち、ＴＤＦは、当該ＴＤＦセッションに関するＡＤＣルール（ＩＰｖ４、及び／又はＩＰｖ６に対するＡＤＣルール）に従って、送信元アドレスが当該ＩＰｖ４アドレスである上りサービスデータストリーム（ユーザプレーンデータとも称される）、及び／又は送信先アドレスが当該ＩＰｖ４アドレスである下りサービスデータストリームに対してアプリケーション検出及び制御を行う。この前にＰＣＲＦがＴＤＦへＳｔａｒｔ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎとＳｔｏｐ ｏｆ ａｐｐｌｉｃａｔｉｏｎ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎのイベントトリガーをサブスクライブする場合、ＴＤＦは、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を当該ＴＤＦセッションによりＰＣＲＦに返すこともできる。

図７は、本発明に係るデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法の第２の実施形態のフローチャートであるである。第２の実施形態において、仮定に、ＴＤＦが独立的に配置され、且つ図２又は図３のフローに従って、ＴＤＦとＰＣＲＦがＴＤＦセッションを確立したとし、その後、ＩＰｖ４アドレスが解放された場合、当該方法は、以下のステップを含む。

ステップ７０１：ＰＣＥＦが位置するゲートウェイ又は他のネットワークエレメントは、この前にＵＥに割り当てられたＩＰｖ４アドレスを解放する。

ステップ７０２：ＰＣＥＦは、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスちを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信する。具体的に実現する場合、ＩＰアドレス割り当て指示は、ＵＥ−ＩＰ−ＡＤＤＲＥＳＳ−ＲＥＬＥＡＳＥを含むように値を取るイベントトリガーｅｖｅｎｔ ｔｒｉｇｇｅｒである。

ステップ７０３：ＰＣＲＦは、ＰＣＥＦへＩＰ−ＣＡＮセッションの変更確認メッセージを返す。

ステップ７０４：ＰＣＲＦは、図２に示すフローにおけるステップ２０８〜ステップ２０９、又は図３に示すフローにおけるステップ３０６〜ステップ３０８で確立されたＴＤＦセッションにより、ＩＰアドレスの解放指示と解放されたＩＰｖ４アドレスを含むＴＤＦセッション変更要求をＴＤＦへ送信する。具体的に実現する場合、ＰＣＲＦがＴＤＦへ送信するセッションの変更要求メッセージにＥｖｅｎｔ−Ｒｅｐｏｒｔ−Ｉｎｄｉｃａｔｉｏｎ ＡＶＰが含まれ、且つ当該ＡＶＰにＵＥ−ＩＰ−ＡＤＤＲＥＳＳ−ＲＥＬＥＡＳＥを含むように値を取るｅｖｅｎｔ ｔｒｉｇｇｅｒと解放されたＩＰｖ４アドレスが含まれる。

ステップ７０５：ＴＤＦは、ＰＣＲＦへＴＤＦセッションの変更要求確認メッセージを返す。

図７に示すフローにより、ＴＤＦは、当該ＩＰ−ＣＡＮセッションの前に割り当てられたＩＰｖ４アドレスが解放され、すなわち当該ＩＰｖ４アドレスと前のＩＰｖ６アドレスが同じＩＰ−ＣＡＮセッションに属しないことを取得した。ＴＤＦは、ＩＰｖ４アドレスと確立されたＴＤＦセッションとの関連関係を解除する。ＴＤＦは、当該ＴＤＦセッションに関するＡＤＣルールを解放されたＩＰｖ４アドレスとマッチングするサービスデータストリーム（ユーザプレーンデータとも称される）に用いることを、停止して、アプリケーション情報の検出を行う。

以上の説明は、本発明の好適な実施形態に過ぎず、本発明を限定するものではない。当業者にとっては、本発明に基づく種々の変更と変形が可能である。本発明の趣旨及び範囲を逸脱することなく実施されたあらゆる修正、同等の置換及び改良等は、すべて本発明の保護範囲に属する。

Claims (15)

1. デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法であって、前記方法は、
   ユーザ装置ＵＥがＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを取得した後、ＩＰｖ４アドレスを更に取得するステップを含み、
   前記方法は、更に、ポリシー制御及び課金ルール機能ＰＣＲＦエンティティが、前記ＩＰ−ＣＡＮセッションによって確立されたサービス検出機能ＴＤＦセッションを介して、割り当てられたＩＰｖ４アドレスをＴＤＦに通知するステップと、
   前記ＴＤＦが、取得されたＩＰｖ４アドレスと前記確立されたＴＤＦセッションとを関連付けるステップとを含むことを特徴とするデュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現する方法。
2. 前記ＴＤＦが、ＩＰｖ４アドレスとＴＤＦセッションとを関連付けた後、前記方法は、更に、
   前記ＰＣＲＦが前記ＴＤＦからアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、前記ＴＤＦが、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すステップを含むことを特徴とする
   請求項１に記載の方法。
3. 前記方法は、更に、
   前記ＴＤＦが前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスが前記ＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うステップを含むことを特徴とする
   請求項１又は２に記載の方法。
4. 前記方法は、更に、
   前記ＴＤＦセッションに関するＡＤＣルールが、前記ＩＰ−ＣＡＮセッションの、ＩＰｖ６アドレスに用いられるアプリケーション検出制御ＡＤＣルール、及び／又は単独でＩＰｖ４アドレスに用いられるＡＤＣルールを含むことを特徴とする
   請求項３に記載の方法。
5. 前記方法は、更に、
   前記ＩＰｖ４アドレスが解放された場合、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、解放されたＩＰｖ４アドレスを前記ＴＤＦに通知するステップと、前記ＴＤＦが、前記ＩＰｖ４アドレスと前記ＴＤＦセッションとの関連関係を解除するステップとを含むことを特徴とする
   請求項１に記載の方法。
6. 前記ＴＤＦは、前記ＴＤＦセッションに関するＡＤＣルールを、解放されたＩＰｖ４アドレスとマッチングするサービスデータストリームに応用させることを停止することを特徴とする
   請求項５に記載の方法。
7. 前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、解放されたＩＰｖ４アドレスを前記ＴＤＦに通知するステップは、
   ポリシー及び課金実行機能ＰＣＥＦエンティティが、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信するステップと、前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを解放し、ＰＣＥＦへ確認メッセージを返すステップと、
   前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信するステップとを含むことを特徴とする
   請求項５に記載の方法。
8. 前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、割り当てられたＩＰｖ４アドレスをＴＤＦに通知するステップは、
   ＰＣＥＦが、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信するステップと、前記ＰＣＲＦが、ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶し、ＰＣＥＦへ確認メッセージを返すステップと、
   前記ＰＣＲＦが、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信するステップとを含むことを特徴とする
   請求項１に記載の方法。
9. デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現するシステムであって、前記システムは、少なくともＰＣＲＦ、ＰＣＥＦ、ＴＤＦ及びＵＥを含み、ＵＥが、ＩＰ−ＣＡＮセッションを確立してＩＰｖ６アドレスを取得することに用いられる後に、ここで、
   ＰＣＥＦが、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＩＰ−ＣＡＮセッション変更指示メッセージを前記ＰＣＲＦへ送信することに用いられ、
   ＰＣＲＦが、前記ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを記憶して、前記ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス割り当て指示と割り当てられたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求をＴＤＦへ送信することに用いられ、
   ＴＤＦが、前記ＩＰｖ４アドレスと前記ＴＤＦセッションを関連付けて、前記ＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられることを特徴とする
   デュアルスタックをサポートするＩＰ−ＣＡＮセッションにおいてアプリケーション検出及び制御を実現するシステム。
10. 前記ＴＤＦは、更に、前記ＰＣＲＦが自身からアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記ＴＤＦセッションを介して前記ＰＣＲＦに返すことに用いられることを特徴とする
    請求項９に記載のシステム。
11. 前記ＰＣＥＦは、更に、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスを含むＩＰ−ＣＡＮセッション変更指示メッセージをＰＣＲＦへ送信することに用いられ、
    前記ＰＣＲＦは、更に、ＩＰ−ＣＡＮセッション変更指示メッセージに含まれるＩＰｖ４アドレスを解放し、ＰＣＥＦへ確認メッセージを返し、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、ＩＰアドレス解放指示と解放されたＩＰｖ４アドレスとを含むＴＤＦセッション変更要求を前記ＴＤＦへ送信することに用いられ、
    前記ＴＤＦは、更に、前記ＩＰｖ４アドレスと前記ＴＤＦセッションとの関連関係を解除して、前記ＰＣＲＦに確認メッセージを返信することに用いられることを特徴とする
    請求項９に記載のシステム。
12. ＴＤＦであって、前記ＴＤＦは、
    ＰＣＲＦからのＩＰｖ４アドレスと確立されたＴＤＦセッションとを関連付けて、前記確立されたＴＤＦセッションに関するＡＤＣルールに従って、送信元アドレス及び／又は送信先アドレスがＩＰｖ４アドレスであるサービスデータに対してアプリケーション検出及び制御を行うことに用いられることを特徴とする
    ＴＤＦ。
13. 前記ＴＤＦは、更に、前記ＰＣＲＦが自身からアプリケーショントラフィック検出開始とアプリケーショントラフィック検出停止のイベントトリガーをサブスクライブした場合、検出された、前記ＩＰｖ４アドレスに関するアプリケーション情報を、前記確立されたＴＤＦセッションを介して前記ＰＣＲＦに返すことに用いられることを特徴とする
    請求項１２に記載のＴＤＦ。
14. ＰＣＲＦであって、前記ＰＣＲＦは、ＰＣＥＦがＵＥによって新たに割り当てられたＩＰｖ４アドレスを自身に通知した後、ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＵＥによって新たに割り当てられたＩＰｖ４アドレスをＴＤＦに通知することに用いられることを特徴とする
    ＰＣＲＦ。
15. 前記ＰＣＲＦは、更に、ＰＣＥＦが前記ＩＰｖ４アドレスが解放されたことを自身に通知した後、前記ＩＰ−ＣＡＮセッションによって確立されたＴＤＦセッションを介して、前記ＩＰｖ４アドレスが解放されたことを前記ＴＤＦに通知することに用いられることを特徴とする
    請求項１４に記載のＰＣＲＦ。

Images