シグナリングＩＰフローのベアライベントを報告するための制御方法、システム、及び、機能エンティティ
シグナリングＩＰフローのベアライベントを報告するための制御方法、システム、及び、機能エンティティが提供される。５組は、シグナリングパス状態を報告するメカニズムと、メディアＩＰフローのベアライベントを報告するメカニズムとを結合するため、シグナリングＩＰフローとメディアＩＰフローに対して生成され、したがって、シグナリングパス状態を報告するメカニズムは、フロー使用、シグナリングタグを備えたＰＤＰコンテキストのパラメータに限定されず、それにより、シグナリングに対して対応するＰＣＣルールとシグナリングＩＰフロー及びベアラ間の関連付けとを確立する。シグナリングパス状態を報告する方法が本発明でさらに提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、中国特許出願公開第200710087199.6号公報、及び、第200710100495.5号公報（2007年３月23日及び2007年４月17日にそれぞれ出願され、発明の名称を「シグナリングＩＰフローのベアライベントを報告するための制御方法及び機能エンティティ」とする）のメリットを主張し、引用することによりその全体を本明細書に組み込む。
【０００２】
本発明は、通信技術に関し、特に、シグナリングＩＰ（Internet Protocol）フローのベアライベントを報告するための制御方法、システム、及び、機能エンティティ（function entity）に関する。
【背景技術】
【０００３】
ＩＭＳ（IP Multimedia Subsystem）ポリシー制御メカニズム（即ち、ＳＢＬＰ（Service Based Local Policy））、及び、ＦＢＣ（Flow Based Charging）技術は、３ＧＰＰ（Third Generation Partnership Project）Ｒ６プロトコル規格において指定されている。しかし、ポリシー制御は、特定の手順に関するＦＢＣのそれらに類似した多数の機能を含み、かつ、ポリシー制御とＦＢＣの分離は、ネットワーク構成の複雑さの増大、及び、コスト増大を必ずもたらし、さらに、制御効果は低減され、故に、ユーザ経験に影響を及ぼす。３ＧＰＰリリース７の規格は、ポリシー制御及びＦＢＣを収束させ、かつ、ＰＣＣ（Policy Control and Charging）アーキテクチャを提案し、図１の破線のブロックで示されるように、アーキテクチャは、ＯＳＣ（Online Charging System）（ＣＡＭＥＬ ＳＣＰ（Customized Applications for Mobile Network Enhanced Logic Service Control Point）、及び、サービスデータフローベースクレジット制御（Service Data Flow Based Credit Control）をさらに含む）を備えている。
【０００４】
ＡＦ（Application Function）は、アプリケーション機能エンティティ（例えば、ＩＭＳにおけるＰ−ＣＳＣＦ（Proxy Call Session Control Function））であり、かつ、ＰＣＲＦ（Policy Control and Charging Rules Function）にポリシー確立及びチャージング制御に対する動的セッション情報を提供するように構成されている。ＰＣＲＦは、アプリケーション層サービス情報、ベアラ層情報、ローカルオペレータ構成、及び、ユーザ申込（subscription）プロフィールに従って、ＱｏＳ認証及びチャージングルールを伴うＰＣＥＦ（Policy Control and Charging Rules Function）を提供し、かつ、ユーザプレーンデータ（例えば、ゲーティングの使用禁止、及び、ＩＰパケットの破棄）に関するゲーティング機能を判断するように構成されている。一般に、ＰＣＥＦは、ＧＷ（Gateway）（例えば、ＧＰＲＳ（General Packet Radio Service）におけるＧＧＳＮ（Gateway GRPS Support Node））に配置され、かつ、ＰＣＲＦから送信されたポリシールールに従って、ＱｏＳ処理を実行し、サービスデータフローを検出し、かつ、オンライン／オフラインチャージングなどの機能を実行するように構成されている。ＳＰＲ（Subscription Profile Repository）は、ユーザ申込プロフィール（ＰＣＲＦに対するポリシー確立及びチャージング制御に必要な）を格納及び提供するように構成された、論理エンティティである。
【０００５】
ＰＣＣアーキテクチャを用いて、オペレータは、ベアラ層でデータフローのＱｏＳ、チャージングなどの制御を実行してもよく、それによって、上位のサービス層からは隠蔽されるトランスポートネットワークの詳細を使用可能にし、換言すれば、サービス層はベアラ制御層の上にあり、かつ、ベアラ制御層はベアラ層の詳細をサービス層から隠蔽し、かつ、下位のトランスポートネットワークでリソースの使用を理解する。一方では、ＰＣＲＦは、サービス層によって示されたセッション交渉情報に従って、ポリシーを確立して、ベアラ層でネットワークリソースの使用を制御してもよく、他方では、下にあるベアラの使用に関する変化のメカニズム報告を通じて（例えば、リソース損失、及び、ゲートウェイ故障）、サービス層に通知してもよく、したがって、サービス層は、適した変更を実行し、かつ、対応するポリシーを提供してもよい。
【０００６】
次の２つの用語が記載のためにまず説明される。
【０００７】
フロー識別子情報：
フロー識別子情報は、２組（2-tuple）＜メディアコンポーネント番号（例えば、メディアコンポーネント番号（Media Component Number）ＡＶＰ）、ＩＰフロー番号（例えば、フロー番号（Flow Number）ＶＡＰ）＞として表される。メディアコンポーネント番号は、メディアタイプ（例えば、オーディオフロー及びビデオフロー）を識別する。メディアコンポーネントは、１又は複数のＩＰフローを含んでもよい。フロー識別子情報は、セッション交渉の後に取得されたＳＤＰ（Session Description Protocol）情報から導出され、かつ、メディアＩＰフローを固有に識別する。
【０００８】
２．５組(5-tuple)（例えば、フロー記述（Flow Description）ＡＶＰ）：
５組は、＜ソースアドレス、ソースポート番号、宛先アドレス、宛先ポート番号、プロトコル＞からなる。ソースアドレス及びソースポート番号は、セッションのイニシエータのＩＰアドレス及びポート番号を識別し、宛先アドレス及び宛先ポート番号は、セッションの受信器のＩＰアドレス及びポート番号を識別し、かつ、プロトコルは、メディアＩＰフローのトランスポートに使用されたプロトコルを識別する。５組は、メディアＩＰフローを固有に識別し、かつ、セッション中に、メディアＩＰフローと特定のベアラを関連付けるように構成されている（５組と、ベアラを固有に識別するＴＦＴ（Traffic Flow Template）とを結合することによって実行される）。５組は、セッション交渉に対するＳＤＰに従って導出される。
【０００９】
ＰＣＣアーキテクチャの仕様では、ＡＦはメディアベアラの使用を申し込み（subscribe）、故に、メディアベアライベントが報告されることを可能にする。ベアライベントの検出によって、ＰＣＥＦはベアライベントをＰＣＲＦに報告し、かつ、新規ポリシーをリクエストする。ＰＣＲＦは、新規ポリシーを確立する前に、イベント報告を通じて、ＡＦにＩＰフローに対応するベアラの変化を通知する。ＡＦは、ＰＣＲＦが新規ＰＣＣルールを確立することに基づき、ＰＣＲＦに調整されたセッション情報を送信する。メディアベアライベントを申し込み、かつ、メディアベアライベントを報告することの特定の実施例が図２に示されている。
【００１０】
ステップＳ201〜Ｓ206は、ベアライベント報告を申し込む手順を図示しており、かつ、次のように説明される。
【００１１】
ステップＳ201：
ＡＦは、アプリケーション層サービス情報をＰＣＲＦに送信して、ベアライベント報告を申し込む。セッションパラメータ（例えば、メディアコンポーネント番号（即ち、メディアコンポーネント番号（Media Component Number）ＡＶＰ）、フロー番号のパラメータ（即ち、フロー番号（Flow Number）ＡＶＰ）、５組のパラメータ（即ち、フロー記述（Flow Description）ＡＶＰ）、及び、申し込まれる特定のベアライベント（例えば、ベアラ損失及びベアラリリース）を示す特定のアクション（即ち、特定アクション（Specific Action）ＡＶＰ）のパラメータ）は、ＡＡＲ（Authorize-Authenticate-Request）で運ばれる。
【００１２】
ステップＳ202〜Ｓ203：
ＰＣＲＦは、受信したセッションパラメータを格納し、かつ、ＡＡＡ（Authorize-Authenticate-Answer）応答を返す。
【００１３】
ステップＳ204：
ＰＣＲＦは、サービス層情報、ベアラ層情報（ＰＤＰコンテキスト確立リクエストにより、ＰＣＥＦによってＰＣＲＦに提供された）、申込プロフィール、及び、オペレータのローカルポリシーに従って、ＰＣＣルールを確立及び格納する。
【００１４】
ステップＳ205〜Ｓ206：
ＰＣＲＦは、ＰＣＣルールをＰＣＥＦに送信する（ＰＡＲ（Re-Auth-Request）メッセージにおけるチャージングルールインストール（Charging Rule Install）を介して、チャージングルールインストール（Charging Rule Install）のパラメータで運ばれているＰＣＣルールと共に）。さらに、ＰＡＲメッセージは、ＰＣＣルール名（ＰＣＣルールのために生成された）を含んでいる。
【００１５】
ＰＣＥＦによるベアライベント検出が以前にリクエストされなかった場合、ＰＣＲＦは、検出される特定のベアライベント（例えば、ベアラ損失、及び、ベアラリリース）を示すために、イベントトリガ（Event Trigger）のパラメータを運ぶ。
【００１６】
ステップＳ207〜Ｓ211には、ベアライベントを報告する手順が図示されており、次のように説明される。
【００１７】
ステップＳ207：
前記ベアライベントは前記ＰＣＥＦによって検出される。
【００１８】
ステップＳ208〜Ｓ209：
ＰＣＥＦは、チャージングルール報告（Charging Rule Report）（ＣＣＲ（Credit-Control-Request）メッセージでＰＣＣルール名を運ぶ）のパラメータを通じて、ＰＣＣルール名（ＰＣＲＦに対するベアラに関連付けられた）を報告する。報告中、ベアライベントを示すイベントトリガ（Event Trigger）のパラメータも運ばれる。メッセージを受信すると、ＰＣＲＦはＣＣＡ（Credit-Control-Answer）メッセージをＰＣＥＦに返す。
【００１９】
ステップＳ210〜Ｓ211：
ＰＣＲＦは、ＡＦに、ＰＣＥＦによって報告されたＰＣＣルール名に従って、ベアライベントとともに、影響されたメディアＩＰフローの識別子を報告する。ＰＡＲメッセージは、フロー（Flow）のパラメータ（ベアライベントに関連付けられたメディアＩＰフローの識別子を示す）を運び、かつ、フロー（Flow）のパラメータは、メディアコンポーネント番号、及び、フロー番号を含んでいる。さらに、ＰＡＲメッセージは、特定のベアライベントを示す特定のアクションのパラメータを運ぶ。メッセージを受信すると、ＡＦはＲＡＡメッセージをＰＣＲＦに返す。
【００２０】
ベアライベントを報告するメカニズムを用いて、ベアラが変化するとき（例えば、ベアラリソース損失、及び、ゲートウェイ故障の発生）、ベアラ層は、ベアライベントのサービス層にタイムリーに通知して、新規ポリシーをリクエストしてもよい。サービス層は、報告メカニズムによってベアラ変化を理解し、かつ、ベアラ変化に応答する（例えば、サービス層が、セッション変更、セッション終了などをリクエストしてもよい）。
【００２１】
メディアＩＰフローと同様に、セッション中のシグナリングＩＰフローもベアラを利用し、かつ、サービス層は、シグナリングに関する下にあるベアラの状態をタイムリーに知る必要がある。シグナリングに関するベアラが変化したとき、ベアラはベアライベントをサービス層に報告する必要があり、したがって、サービス層は対応する変更をタイムリーに実行してもよい。シグナリングパスの状態を報告するための既存方法は次の通りである。
【００２２】
シグナリングタグが、ＵＥ（User Equipment）によってＰＤＰ（Packet Data Protocol）起動リクエストで運ばれる。ＰＣＲＦは、確立されるＰＤＰコンテキストがＩＰシグナリングを運ぶのに使用されることを理解し、かつ、ＰＣＣルールをＰＣＥＦに確立及び送信し、それによって、シグナリングタグを備えたＰＤＰコンテキストを確立する。シグナリングパス状態報告を申し込むと、ＡＦはシグナリングＩＰフロータグを運び、シグナリングイベントに対する申し込みについて、ＰＣＲＦに通知する。シグナリングタグを備えたベアラに関する変化の検出によって、ＰＣＥＦは、ＰＣＲＦに、ベアラに関連付けられたＰＣＣルール名を報告し、かつ、ＰＣＲＦは、ＰＣＣルール名に従って、シグナリングを運ぶＰＤＰコンテキストの変化を理解し、したがって、シグナリングパス状態はＡＳに報告される。
【００２３】
シグナリングパス状態を報告する特定の実施例が図３に示されている。
【００２４】
ステップＳ301〜Ｓ307は、シグナリングタグを備えたＰＤＰコンテキストを確立する手順を示しており、特に次のように説明される。
【００２５】
ステップＳ301：
ＰＣＥＦは、ＵＥから、ＰＤＰコンテキスト起動リクエスト（シグナリングタグを運ぶ）を受信する。
【００２６】
ステップＳ302：
ＰＣＥＦは、ＰＤＰコンテキスト確立リクエストをＰＣＲＦに送信する。ＣＣＲメッセージは、ベアラ層情報（例えば、ベアラ使用（Bearer Usage）のパラメータ）（シグナリングタグを備えたＰＤＰコンテキストの確立がリクエストされることを示す）を運ぶ。選択的に、ＰＣＲＦは、ＣＣＡメッセージをＰＣＥＦに返す（図示せず）。
【００２７】
ステップＳ303：
ＰＣＲＦは、受信したベアラ層情報を格納し、かつ、リクエストに応じて確立されるＰＤＰコンテキストが、ベアラ使用（Bearer Usage）のパラメータに従って、ＩＭＳシグナリングを運ぶのに使用されることを理解する。
【００２８】
ステップＳ304：
ＰＣＲＦは、ベアラ層情報、申込プロフィール、及び、オペレータポリシーに従って、ＰＣＣルール及び対応するＰＣＣルール名を生成する。
【００２９】
ステップＳ305〜Ｓ307：
ＰＣＲＦは、ＰＣＣルール及び対応するＰＣＣルール名をＰＣＥＦに送信し、かつ、ＰＣＥＦは、ＰＣＣルールをインストールし、かつ、ＰＤＰコンテキスト起動リクエストに対する応答をＵＥに返し、したがって、シグナリングタグを備えたＰＤＰコンテキストが確立される。
【００３０】
ステップＳ308〜Ｓ312は、シグナリングパス状態報告を申し込む手順を示しており、かつ、特に次のように説明される。
【００３１】
Ｓ308〜Ｓ310：
セッションメッセージがＡＦに到達したとき、ＡＦは、シグナリングパス状態報告に対する申込を開始する。フロー使用（Flow Usage）（ＡＦシグナリングとしてセットし、シグナリングイベントに関する申込を示す）、及び、特定のアクション（ベアラ損失、及び、ベアラリリースなどの特定の申込されたイベントを示す）のパラメータがＡＡＲメッセージで運ばれる。ＰＣＲＦは、フロー使用のパラメータ値に基づいて、この申込がシグナリングパス状態に関する申込であることを理解する。
【００３２】
Ｓ311〜Ｓ312：
ＰＣＲＦはＰＣＣルールをＰＣＥＦに送信する。ＰＣＣルールを示すチャージングルールインストール（Charging Rule Install）のパラメータは、ＲＡＲメッセージで運ばれる。ＰＣＥＦによるベアライベントの検出が申し込みされない場合、ＰＣＲＦは、運ばれている特定のベアライベントを示すイベントトリガ（Event Trigger）のパラメータを用いて、申込を開始する。イベントトリガ（Event Trigger）のパラメータは、特定のアクションのパラメータに従って生成される。
【００３３】
ステップＳ313〜Ｓ318はシグナリングパス状態を報告する手順を示しており、かつ、特に次のように説明される。
【００３４】
ステップＳ313：
ベアライベントがＰＣＥＦによって検出される。
【００３５】
ステップＳ314〜Ｓ315：
ＰＣＥＦは、ベアラに関連付けられたＰＣＣルールをＰＣＲＦに報告する。
【００３６】
ステップＳ316〜Ｓ318：
ＰＣＲＦは、ＰＣＣルール名に従って、ＩＭＳシグナリングを運ぶＰＤＰチャネルの変化を決定し、かつ、シグナリングパス状態を報告する。
【００３７】
シグナリングパス状態を報告するための既存メカニズムの実施例は、フロー使用（Flow Usage）のパラメータに依存する。シグナリングパス状態に対する申込を開始すると、サービス層は、ＡＦシグナリング識別子として、フロー使用（Flow Usage）のパラメータを使用して、ＰＣＲＦにシグナリング関連の申込を通知する。しかし、現在定義されたように、フロー使用（Flow Usage）のパラメータは、メディアサブコンポーネント（Media Sub-Component）のパラメータのサブパラメータとして存在し、かつ、フロー使用（Flow Usage）のパラメータは、メディアコンポーネント記述（Media Component Description）、及び、メディアサブコンポーネント（Media Sub-Component）のパラメータとともに使用しなければならない。シグナリングＩＰフローに対して、メディアコンポーネント記述（Media Component Description）のパラメータ、又は、メディアサブコンポーネント（Media Sub-Component）のパラメータの値は既存規格で定義されず、その結果、シグナリング情報は報告されることを許可されず、したがって、シグナリングパス状態を報告するメカニズムは実施することができない。
【先行技術文献】
【特許文献】
【００３８】
【特許文献１】中国特許出願公開第200710087199.6号公報
【特許文献２】中国特許出願公開第200710100495.5号公報
【発明の概要】
【課題を解決するための手段】
【００３９】
本発明の態様は、シグナリングＩＰフローのベアライベントを報告するための制御方法、システム、及び、機能エンティティを提供して、シグナリングＩＰフローのシグナリングパス状態の報告を実行する。
【００４０】
上記したソリューションを実行するため、シグナリングＩＰフローのベアライベントを報告する方法が本発明の態様によって提供され、前記方法は、
アプリケーション機能（Application Function）によって、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するステップと、
前記アプリケーション機能（Application Function）によって、前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するステップと
を具備し、
前記リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４１】
アプリケーション機能（Application Function）が本発明の他の態様により提供され、前記アプリケーション機能（Application Function）は、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第１申込リクエスト送信ユニットと、
前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４２】
ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）が本発明の他の態様により提供され、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を含む情報を運ぶベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えている。
【００４３】
シグナリングＩＰフローのベアライベントを報告するためのシステムが本発明の他の態様により提供され、かつ、前記システムは、アプリケーション機能（Application Function）と、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）とを備えている。
【００４４】
前記アプリケーション機能（Application Function）は、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第１申込リクエスト送信ユニットと、
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）によって送信された前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４５】
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
前記第１申込リクエスト送信ユニットから、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記リクエストを受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を含む情報を運ぶ前記ベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えている。
【００４６】
前記制御方法を用いて、ＩＰフローのベアライベントを報告するためのシステム及び機能エンティティが本発明の態様によって提供されて、５組はシグナリングＩＰフロー、及び、メディアＩＰフローに対してそれぞれ生成され、したがって、シグナリングパス状態を報告するメカニズムは、フロー使用（Flow Usage）、シグナリングタグを備えたＰＤＰコンテキストなどのパラメータによって限定されず、それによって、シグナリングＩＰフローの前記シグナリングパス状態を報告し、かつ、シグナリングパス状態を報告するメカニズムと、メディアＩＰフローのベアライベントを報告するメカニズムとを結合し、かつ、さらに、シグナリングＩＰフローとベアラとの間のシグナリング及び関連付けに対して、対応するＰＣＣルールを確立する。
【図面の簡単な説明】
【００４７】
【図１】従来技術におけるＰＣＣアーキテクチャの構成の概略図である。
【図２】従来技術におけるメディアベアライベントを申込及び報告するためのメカニズムの概略フローチャートである。
【図３】従来技術におけるシグナリングパス状態を報告するためのメカニズムの概略フローチャートである。
【図４】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御方法の概略フローチャートである。
【図５】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御方法の概略フローチャートである。
【図６】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御システムの一般的な構成の概略図である。
【図７】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御システムの一般的な構成の概略図である。
【図８】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図９】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図１０】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図１１】本発明の実施例によるＰＣＲＦの一般的な構成の概略図である。
【図１２】本発明の実施例によるＰＣＲＦの一般的な構成の概略図である。
【発明を実施するための形態】
【００４８】
背景技術で既存のメディアベアライベントを報告するメカニズム、及び、シグナリングパス状態を報告するメカニズムを理解することによって、シグナリングパス状態を報告するための既存のメカニズムのアプリケーションシナリオが、以下のように、多数の側面で限定されていることが分かる。
【００４９】
シグナリングパス状態を報告するための既存のメカニズムの実施例は、フロー使用（Flow Usage）のパラメータに依存する。シグナリングパス状態に対する申込を開始すると、サービス層は、ＡＦシグナリング識別子として、フロー使用（Flow Usage）のパラメータを使用して、ＰＣＲＦにシグナリング関連の申込を通知する。しかし、現在定義されたように、フロー使用（Flow Usage）のパラメータは、メディアサブコンポーネント（Media Sub-Component）のパラメータのサブパラメータとして存在し、かつ、フロー使用（Flow Usage）のパラメータを、メディアコンポーネント記述（Media Component Description）、及び、メディアサブコンポーネント（Media Sub-Component）のパラメータとともに使用しなければならない。シグナリングＩＰフローに対して、メディアコンポーネント記述（Media Component Description）のパラメータ、又は、メディアサブコンポーネント（Media Sub-Component）のパラメータの値が既存規格で定義されず、その結果、シグナリング情報は送信又は報告されることを許可されず、したがって、シグナリングパス状態を報告するメカニズムは実施することができない。
【００５０】
また、シグナリングパス状態を報告するための既存のメカニズムの実施例は、シグナリングタグを備えたＰＤＰコンテキストの確立に依存し、かつ、アプリケーションシナリオ（シグナリングタグを備えていない、シグナリング−ベアリング（bearing）ＰＤＰコンテキスト）はサポートされていない。シグナリングタグは、ＰＤＰコンテキストの確立中に運ばれる必要があり、したがって、ＰＣＲＦは、どのＰＤＰチャネルがシグナリングを運ぶのに使用されるかを理解してもよい。結果的にベアラが変更されたとき、ＰＣＲＦは、ベアラに対応するＰＣＣルール名に従って、シグナリング−ベアリングＰＤＰコンテキストが変更されることを決定し、それによって、シグナリングパスの報告を実行する。しかし、シグナリングタグを備えたＰＤＰコンテキストの確立は、ＵＥ能力及びオペレータによるサポートに依存する。換言すれば、アプリケーションシナリオ（シグナリングを運ぶＰＤＰコンテキストがシグナリングタグを備えていない）は、実際のネットワークアプリケーションの中に存在してもよい。その結果、シグナリングパス状態を報告するためのメカニズムは、アプリケーションシナリオ（ＰＤＰコンテキストがシグナリングタグを備えることなく提供される）において実行することができない。
【００５１】
また、シグナリングパス状態を報告する既存のメカニズムの実施例は、ＰＤＰコンテキストの確立中に生成された、関係するＰＣＣルールに依存している。ＰＤＰコンテキスト（シグナリングを運ぶ）の確立中に、関係するＰＣＣルールが生成されない場合、サービス層でのシグナリングＩＰフローのアドレス及びポート情報は、既存のメカニズムに従って、セッション中にＰＣＲＦに送信することができず、その結果、シグナリング関連のＰＣＣルールは確立することができず、結果として、ＰＣＥＦはベアライベントをＰＣＲＦに報告することができず、かつ、シグナリングパス状態報告は実行することができない。
【００５２】
さらに、シグナリングパス状態を報告するための既存のメカニズムは、メディアベアライベントを報告するメカニズムからは独立しており、その結果、ベアライベントを報告するメカニズム全体が複雑である。さらに、シグナリングパス状態を報告するメカニズムでは、シグナリングＩＰフローに対する５組（サービス層でシグナリングＩＰフローに対応する）が生成されず、その結果、シグナリングＩＰフローとベアラとの間の関連付けを確立することができない。
【００５３】
シグナリングパス状態を報告するための既存のメカニズムに存在する欠点のため、本発明の実施例によって、シグナリングＩＰフローのシグナリングパス状態を報告する制御方法が提供され、かつ、方法は、シグナリングパス状態を報告するメカニズムと、メディアベアラ状態を報告するメカニズムとを組合せ、したがって、ベアラ報告メカニズムが単純化され、かつ、シグナリングパス状態を報告するメカニズムのアプリケーションは、例えば、フロー使用（Flow Usage）のパラメータ、ＰＤＰコンテキストに対するシグナリングタグの提供、及び、ＰＤＰコンテキストの確立中に、関係するＰＣＣルールを生成することの必要性によって限定されない。
【００５４】
本発明の実施例では、主に、ベアライベントを報告する制御方法は次のステップを具備している。
【００５５】
１．各ＩＰフロー（ベアライベント報告に対する申込のリクエストがトリガされる）に対して、ＡＦは、５組を生成し、かつ、ＩＰフローのタイプに従って、フロー識別子情報を生成し、ＩＰフローは、シグナリングＩＰフロー及びメディアＩＰフローを具備してもよく、かつ、５組とフロー識別子情報の両方は、ＩＰフロー及びＩＰフローのタイプを識別してもよい。
【００５６】
２．ＡＦは、ＰＣＲＦに、ＩＰフローのベアライベントに対する申込のリクエストを送信する。申込リクエストは、５組及びフロー識別子情報を運ぶ。
【００５７】
３．ＰＣＲＦは、ＩＰフローのベアラに関連付けられたＰＣＣルール及びＰＣＣルール名を含むＰＣＣルール情報を確立し、ＰＣＣルール名及びフロー識別子情報をそれぞれ格納し、かつ、ＰＣＣルール情報をＰＣＥＦに送信する。
【００５８】
一部のアプリケーションシナリオでは、関連したＰＣＣルール情報は、ＩＰフローベアラに対して既に確立され、かつ、ＰＤＰコンテキスト又はセッションの交渉中に、ＰＣＥＦに送信される。この場合、ＩＰフローに利用可能なＰＣＣルール情報が既に存在し、かつ、ＰＣＲＦは、ＩＰフローベアラに関連付けられたＰＣＣルール情報を確立及び送信する必要はないが、生成されたＰＣＣルール名及びフロー識別子情報を格納する。
【００５９】
４．ＰＣＥＦは、ＰＣＣルールをインストールし、かつ、ベアライベントの検出によって、ＰＣＣルール名及び検出されたベアライベントをＰＣＲＦに報告する。
【００６０】
５．ＰＣＲＦは、関連したＰＣＣルール名に従って、フロー識別子情報を取得し、かつ、取得されたフロー識別子情報は、ベアライベント報告でＡＦに送信される。
【００６１】
６．ＡＦは、ベアライベント報告で運ばれた情報に従って、受信したベアライベント報告のタイプを決定し、シグナリングＩＰフローのベアライベント報告のタイプはシグナリングパス状態報告であり、かつ、メディアＩＰフローのベアライベント報告のタイプはメディアベアライベント報告である。
【００６２】
また、ステップ５では、対応する５組はベアライベント報告で運ばれ、かつ、ＡＦに転送してもよく、かつ、ステップ６では、ＡＦは５組に従って、受信したベアライベント報告のタイプを決定する。
【００６３】
本発明の実施例では、シグナリングパス状態を報告するメカニズムと、メディアＩＰフローのベアライベントを報告するメカニズムとは結合され、かつ、シグナリング情報はサービス層によって送信され、したがって、シグナリングパス状態を報告するメカニズムは、フロー使用（Flow Usage）のパラメータ、ＰＤＰコンテキストに対するシグナリングタグの提供などによって限定されず、故に、シグナリングＩＰフローに対して、ＰＣＣルール、及び、シグナリングＩＰフローとベアラとの間の関連付けを確立する。
【００６４】
本発明の実施例では、ＡＦは、サービス情報をＰＣＲＦに送信するに当たり、シグナリングＩＰフローか、又は、メディアＩＰフローのどちらが含まれるかをＰＣＲＦに通知する必要はなく、故に、ＰＣＲＦによって理解されることからフロータイプを隠蔽する。申込されたベアライベントの検出によって、ＰＣＥＦは、ＰＣＲＦに対するベアラに関するＰＣＣルール名を報告し、かつ、ＰＣＲＦは、ＰＣＣルール名に従って、フロー識別子情報を決定し、かつ、フロー識別子情報及びベアライベントをＡＦに報告する。ＡＦは、フロー識別子情報の生成ルールに従って、ベアライベント情報のタイプを決定し、かつ、適切に応答する。
【００６５】
本発明の実施例では、ベアライベントを報告するメカニズムは、確立されたＰＤＰコンテキストのタイプからは独立している。ＡＦは、サービス層プレーンで、一様なルールに従って、シグナリングＩＰフローとメディアＩＰフローに対する５組を生成し、かつ、ＰＣＲＦからフローに対応するベアライベントを申し込むとき、特定の５組を示す。ＰＣＲＦは、５組に従って、ベアラとＰＣＣルールとの間の関連付けを確立し、かつ、関連付けをＰＣＲＦに送信する。ベアライベントが発生したとき、ＰＣＥＦは、ベアラ及びベアライベントに関連付けられたＰＣＣルール名を報告する。
【００６６】
本発明の実施例では、５組、及び／又は、フロー識別子情報を次のように生成してもよい。メディアＩＰフローの５組、及び／又は、フロー識別子情報は、セッション交渉に対するＳＤＰから導出される。シグナリングＩＰフローの５組は、ＳＩＰメッセージ（例えば、ソースＩＰアドレス、宛先ＩＰアドレス、ポート番号、及び、採用されたプロトコル）における情報に従って生成される。メディアＩＰフローのメディアコンポーネント番号（１から始まり、かつ、昇順で識別することに使用される）を参照して、シグナリングＩＰフローは、デフォルトのメディアコンポーネント番号０を備えて、提供してもよい（例えば、＜０，１＞を使用して、シグナリングＩＰフローを示す）。
【００６７】
図４には、本発明の実施例によるシグナリングパス状態を報告する方法が示されている。本発明の実施例による制御方法は、ＰＤＰコンテキスト確立からは独立している。申込手順と報告手順が図４に示され、ステップＳ401〜Ｓ409が申込手順を示し、かつ、次のように説明される。
【００６８】
ステップＳ401：
ＡＦは、申込に対するトリガを受信すると、シグナリングパス状態に対する申込を開始する（例えば、登録メッセージがＡＦに到着し、かつ、ＡＦはシグナリングパス状態を申し込むように要求されるとき、又は、セッション交渉中）。
【００６９】
ステップＳ402：
メディアベアライベントを報告するメカニズムと、シグナリングパス状態を報告するメカニズムとの単一化に対して、シグナリングＩＰフローに対応するベアライベントを申し込むと、ＡＦは、シグナリングＩＰフロー５組、及び、シグナリングＩＰフローに対するフロー識別子情報を生成し、かつ、フロー識別子情報（メディアコンポーネント番号及びフロー番号）、シグナリングＩＰフロー５組、及び、特定の申し込みされたベアライベント（特定のアクションのパラメータによって示された）はＡＡＲで運ばれる。
【００７０】
ステップＳ403〜Ｓ404：
ＰＣＲＦは、受信したサービス層情報を格納し、かつ、ＡＡＡをＡＦに返す。
【００７１】
ステップＳ405：
ＰＣＲＦは、受信したサービス層情報（シグナリングＩＰフロー５組、ＱｏＳ情報など）、ベアラ情報（ＰＤＰ確立中にＰＣＥＦによって提供された）、申込プロフィール、及び、オペレータポリシーに従って、シグナリングＩＰフローのＰＣＣルール情報を確立及び格納し、前記ＰＣＣルール情報は、ＰＣＣルール及び対応するＰＣＣルール名を備えている。さらに、シグナリングＩＰフローに対して利用可能なＰＣＣルール及びＰＣＣルール名が既に存在するとＰＣＲＦが決定した場合、ＰＣＲＦは、ＰＣＣルール及びＰＣＣルール名をＰＣＥＦに送信する。
【００７２】
ステップＳ406：
ＰＣＲＦは、ＰＣＥＦに、ＲＡＲメッセージ（チャージングルールインストール（Charging Rule Install）のパラメータでＰＣＣルール情報を運ぶ）を送信する。
【００７３】
ＰＣＲＦがＰＣＥＦからベアライベント報告手順を以前に申し込んでいた場合、ＰＣＲＦは、ＰＣＥＦから申込を再び開始する必要はなく、そうでなければ、ＰＣＲＦは、ＰＣＥＦからベアライベントに対する申込を開始する必要がある。図４に示すように、ベアライベントに対する申込、及び、ＰＣＣルール情報の送信は、同じＲＡＲメッセージを介して、同時に実行してもよく、かつ、ＲＡＲメッセージでは、特定のアクションのパラメータに対応するイベントトリガ（Event Trigger）のパラメータは、ベアライベント（ＰＣＥＦから申込が行われる）を指定するために運ばれる。
【００７４】
ステップＳ407〜Ｓ408：
ＰＣＥＦはＰＣＣルール情報をインストールし、かつ、ＡＡＡをＰＣＲＦに返す。
【００７５】
上記した申込手順では、ＡＦは、生成された５組、及び、フロー識別子情報（シグナリングＩＰフローの）を使用して、シグナリングＩＰフローのベアライベント報告を申し込み、したがって、サービス層は、フロー使用（Flow Usage）のパラメータとは独立して、シグナリングパス状態に対する申込を開始することができる。
【００７６】
さらに、ＰＣＲＦは、受信したサービス層情報（シグナリングＩＰフローの５組、ＱｏＳ情報など）、ベアラ情報（ＰＤＰ確立中にＰＣＥＦによって提供された）、申込プロフィール、及び、オペレータポリシーに従って、ＰＣＣルール情報を確立及び格納し、それによって、各シグナリングＩＰフローのＰＤＰコンテキストがＰＣＣルールに関連付けられることを確実にする。実際には、ＰＣＲＦがＰＣＣルール情報を以前に確立及び格納した場合、ＰＣＲＦは、確立されたＰＣＣルール情報を、ＰＣＥＦに直接送信する。ＰＣＲＦによって申し込みされたベアライベントの検出によって、ＰＣＥＦは、検出されたベアライベントに関連付けられたＰＣＣルール名、及び、検出されたベアライベントをＰＣＲＦに報告する。換言すれば、シグナリングＩＰフローに利用可能なＰＣＣルール情報が存在すれば、ＰＣＣルール情報の確立又は格納は現ステップにおいて実行される必要はないが、ＰＣＣルール名とＩＰフローの５組は関連付けられ、かつ、格納される必要がある。
【００７７】
ステップＳ409〜Ｓ413は、ベアライベント報告の手順を図示しており、かつ、特に次のように説明される。
【００７８】
ステップＳ409：
ＰＣＥＦは、ベアラに関するイベントを検出する。
【００７９】
ステップＳ410〜Ｓ411：
ベアラに関するイベントを検出すると、ＰＣＥＦは、ベアラに関連付けられたＰＣＣルール名をＰＣＲＦに報告する。
【００８０】
ステップＳ412〜Ｓ413：
ＰＣＣルール名に従って、ＰＣＲＦは、ＡＦに、ベアライベント報告を介して、ベアライベントとともに、対応するフロー識別子情報について報告し、かつ、ＡＦは、報告の受信によって、ＰＣＲＦにＲＡＡ応答を返す。
【００８１】
さらに、ＡＦは、ベアライベント報告におけるフロー識別子情報に従って、報告されたベアライベントに関連付けられたＩＰフローのタイプを決定する。フロー識別子情報がシグナリングＩＰフローを示した場合、シグナリングパス状態報告が決定され、そうでなければ、メディアベアライベント報告が決定される。
【００８２】
ベアラに関するイベントを報告する手順では、ＰＣＥＦ及びＰＣＲＦは、ＩＰフローを区別する必要はなく、それによって、報告メカニズムを結合し、かつ、シグナリングＩＰフローとベアライベントとを関連付ける。
【００８３】
図５には本発明の他の実施例が図示されている。ＩＰフローを固有に識別するためのフロー識別子情報の機能は、５組によって実施してもよい。
【００８４】
ステップＳ502：
ＡＦは、ＩＰフローに対応するベアライベントを申し込むに当たり、フロー識別子情報を発行しなくてもよい。
【００８５】
ステップＳ512：
ＰＣＲＦは、ＰＣＣルール名に従って、ベアライベントとともにシグナリングＩＰフローの５組をＡＦに報告し、かつ、ＡＦはＲＡＡ応答をＰＣＲＦに返す。
【００８６】
ＡＦは、５組に対応するＰＣＣルール名に従って、報告されたベアライベントに関連付けられたＩＰフローのタイプを決定する。フロー識別子情報がシグナリングＩＰフローに一致した場合、シグナリングパス状態報告が決定され、そうでなければ、メディアベアライベント報告が決定される。
【００８７】
他のステップは、図４に示されたフローのステップと同じであり、それについての説明は重ねて記載されない。
【００８８】
本発明の実施例によれば、５組と、メディアコンポーネント番号及びシグナリングＩＰフローに対するフロー番号の値とを定義した後、シグナリング情報をサービス層から送信してもよく、したがって、申込及び報告手順を実行してもよい。
【００８９】
本発明の実施例によれば、５組はシグナリングＩＰフロー及びメディアＩＰフローに一致して生成され、したがって、セッション中、ＰＣＣルールはシグナリングＩＰフローに対して確立してもよく、かつ、シグナリングＩＰフローはベアラに結合してもよい。したがって、シグナリングパス状態は、ＰＤＰタイプに限定されることなく報告することができる。
【００９０】
本発明の実施例では、サービス層シグナリング情報が送信されて、リアルタイムでシグナリングに対応するＰＣＣルールを確立してもよく、それによって、シグナリングＩＰフローとベアラとの間の関連付けを確立する。
【００９１】
本発明の実施例では、ベアライベントを申し込むため、ＰＣＲＦは、シグナリングに関する申込について通知される必要がなく、かつ、ベアライベントの検出によって、ＰＣＲＦは、関係する申込がシグナリングに関する申込か、又は、メディアに関する申込かを理解する必要はないが、ベアラに対応する５組又はフロー識別子情報をＡＦに報告する。ＡＦは、報告がメディアベアライベントか、又は、シグナリングパス状態の報告に関するかをチェックする。換言すれば、フロータイプはＰＣＲＦの代わりにＡＦによって理解され、したがって、シグナリングパス状態を報告するメカニズムと、メディアベアライベントを報告するメカニズムとが結合される。
【００９２】
上記から分かるように、ユニバーサル、単純かつ効果的なベアライベントを報告するための制御方法が本発明の実施例によって提供され、かつ、シグナリングパス状態を報告するメカニズムとメディアＩＰフローのメディアイベントを報告するメカニズムとが結合され、それによって、シグナリングパス状態を報告するメカニズムを改善し、かつ、シグナリングパス状態報告の実行を確実にする。
【００９３】
図６には、本発明のさらなる実施例による図４に示された制御方法を実行するための制御システムが示され、かつ、制御システムは、ＡＦ61と、ＰＣＲＦ62と、ＰＣＥＦ63とを備えている。本発明はこれに限定されないが、実施例がほんの一例として示される（ＩＰフローの５組が運ばれる）。例えば、５組、又は、５組とフロー識別子情報の両方を運んでもよい。ＡＦ61は、主に、
ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを送信するように構成された、第１申込リクエスト送信ユニット611と、
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から、前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニット612と
を備え、
前記申込リクエストは前記シグナリングＩＰフローの５組を運び、
前記ベアライベント報告は前記シグナリングＩＰフローの前記５組を運ぶ。
【００９４】
ＰＣＲＦ62は、主に、第１申込リクエスト受信ユニット621と、第１ベアラ報告処理ユニット624とを備え、好ましくは、第１ルール確立ユニット622と、第１ベアライベント受信ユニット623とを備えている。
【００９５】
前記第１申込リクエスト受信ユニット621は、アプリケーション機能（Application Function）から、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記リクエストを受信するように構成されている。前記申込リクエストは前記シグナリングＩＰフローの前記５組を含んでいる。
【００９６】
第１ルール確立ユニット622は、前記シグナリングＩＰフローの前記５組に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、前記ポリシー制御及びチャージング（Policy Control and Charging）ルールの名前を確立し、かつ、前記ＰＣＣルール、及び、前記ＰＣＣルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成されている。
【００９７】
第１ベアライベント受信ユニット623は、前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、前記ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）から受信するように構成されている。
【００９８】
第１ベアラ報告処理ユニット624は、前記シグナリングＩＰフローの前記５組を運ぶベアライベント報告を生成及び送信するように構成されている。前記５組は、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージング（Policy Control and Charging）ルール名に対応する前記シグナリングＩＰフローの前記５組であってもよい。
【００９９】
好ましくは、ＰＣＲＦ62は、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、又は、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在すると決定すると、前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルールの名前を確立し、前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、決定ユニット（図示せず）をさらに備えている。
【０１００】
本発明の実施例によれば、第１申込リクエスト送信ユニットと、第１ベアライベント報告受信ユニットとを備えた、アプリケーション機能（Application Function）がさらに設けられている。第１申込リクエスト送信ユニットは、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成され、かつ、申込リクエストは、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、第１ベアライベント報告受信ユニットは、シグナリングＩＰフローのベアライベント報告を、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成され、かつ、ベアライベント報告は、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ。
【０１０１】
アプリケーション機能（Application Function）の実施例は、上記した方法及びシステムと同じであり、それについての説明は重ねて行われない。
【０１０２】
本発明の他の実施例によれば、第１申込リクエスト受信ユニットと、第１ベアラ報告処理ユニットとを含むポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）が設けられている。第１申込リクエスト受信ユニットは、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成され、かつ、申込リクエストは、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、第１ベアラ報告処理ユニットは、ベアライベント報告（シグナリングＩＰフローの５組、及び／又は、フロー識別子情報に対応するベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名などの情報を運ぶ）を生成し、かつ、返すように構成されている。
【０１０３】
好ましくは、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
シグナリングＩＰフローの５組、及び／又は、フロー識別子情報に従って、シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、かつ、ポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、第１ルール確立ユニットと、
検出されたベアライベント、及び、検出されたベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えてもよい。
【０１０４】
好ましくは、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
申込リクエストで運ばれたシグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、又は、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在しないと決定すると、あるいは、申込リクエストで運ばれたシグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在すると決定すると、第１ルール確立ユニットに命令して、ＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、チャージングルール及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、決定ユニット
をさらに備えてもよい。
【０１０５】
アプリケーション機能（Application Function）の実施例は、上記した方法及びシステムと同じであり、それについての説明は重ねて行われない。
【０１０６】
図７には、図５に示された制御方法を実施するための制御システムが本発明のさらに他の実施例によって設けられ、かつ、制御システムは、ＡＦ71と、ＰＣＲＦ72と、ＰＣＥＦ73とを備え、かつ、ＡＦ71は、主に、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第２申込リクエスト送信ユニット711と、
シグナリングＩＰフローのベアライベント報告を、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成された、第２ベアライベント報告受信ユニット712と
を備え、
前記申込リクエストは、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を運び（本実施例は、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を用いた実例として説明されるが、これに限定されない）、
前記ベアライベント報告は、シグナリングＩＰフローのフロー識別子情報を運ぶ。
【０１０７】
ＰＣＲＦ72は、主に、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成された、第２申込リクエスト受信ユニット721と、
シグナリングＩＰフローの５組に従って、シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、かつ、ポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）（選択的に）に送信するように構成された、第２ルール確立ユニット722と、
検出されたベアライベント、及び、検出されたベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）（選択的に）から受信するように構成された、第２ベアライベント受信ユニット723と、
シグナリングＩＰフローのフロー識別子情報を運ぶベアライベント報告を生成及び送信するように構成された、第２ベアラ報告処理ユニット724と
を備え、
前記申込リクエストは、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を運び、
前記識別子情報は、ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名に対応するシグナリングＩＰフローのフロー識別子情報であってもよい。
【０１０８】
シグナリングＩＰフローパス状態を報告する方法が、本発明のさらに他の実施例によって提供される。方法では、第１デフォルトＰＤＰコンテキストをＩＰ−ＣＡＮ（IP Connectivity Access Network）セッションから起動するリクエストに対して、ＰＣＣルールがデフォルトＰＤＰコンテキストに先立って起動又はインストールされ、ＩＰ−ＣＡＮセッションがシグナリングＩＰフローに対して専用のＰＤＰコンテキストを確立するステップを再度リクエストした場合、デフォルトＰＤＰコンテキストに対する以前のＰＣＣルールは動作を停止されるか又は削除され、かつ、ＰＣＣルールはシグナリングＩＰフローのＰＤＰコンテキストに対して起動又はインストールされ、したがって、ＩＰシグナリングパス状態報告は、ＰＣＣルール（シグナリングＩＰフローのＰＤＰコンテキストに対して新規に起動又はインストールされた）のルール名に従ってトリガされ、そうでなければ、デフォルトＰＤＰコンテキストがシグナリングＩＰフローを運ぶのに使用された場合、ＩＰシグナリングパス状態報告は、デフォルトＰＤＰコンテキストに先立って起動又はインストールされたＰＣＣルールのルール名に従ってトリガしてもよい。
【０１０９】
ＰＣＣルール（デフォルトＰＤＰコンテキストに先立って起動又はインストールされた）、及び、ＰＣＣルール（シグナリングＩＰフローのＰＤＰコンテキストに対して新規に起動又はインストールされた）は、次の方法で生成してもよい。
【０１１０】
１．事前定義方法
【０１１１】
事前に定義されたＰＣＣルールは、シグナリングＩＰフローに対してＰＣＥＦに配置される。デフォルトＰＤＰコンテキストを起動するリクエストか、又は、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストの各受信によって、ＰＣＲＦは、ＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する。この方法では、事前に定義されたＰＣＣルール及びその名前は固定され、かつ、ＩＰシグナリングを処理するためのＡＦのアドレス（事前に定義されたＰＣＣルールに含まれている）も固定される。ＩＰシグナリングを処理するためのＡＦのアドレスが変更された場合、事前に定義されたＰＣＣルールは、ＰＣＥＦ及びＰＣＲＦに同期して、再生成及び更新される。
【０１１２】
２．動的生成方法
【０１１３】
ＰＣＲＦは、ＩＰシグナリングを処理するためのＡＦのアドレスを用いて事前設定される。デフォルトＰＤＰコンテキストを起動するリクエストか、又は、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストの各受信によって、ＰＣＲＦは、シグナリングＰＣＣルール（ＩＰシグナリングを処理するためのＡＦの事前設定されたアドレスを含む）を生成し、かつ、シグナリングＰＣＣルールを、インストールするため、ＰＣＥＦに送信する。
【０１１４】
上記した２つの方法は組み合わせて、又は、別々に使用してもよく、かつ、それについての詳細な説明は図面を参照した実施例で以下に示される。
【０１１５】
図８には、第１の事前定義方法（ＰＣＣルールが事前に定義される）において、シグナリングＩＰフローパス状態を報告するメカニズムが示されており、ＰＣＥＦは事前に定義されたＰＣＣルールを用いて構成され、かつ、ＰＣＲＦは事前に定義されたＰＣＣルールの名前を用いて構成され、かつ、メカニズムの特定のフローは以下を含んでいる。
【０１１６】
ステップＳ801〜ｓ805は、デフォルトＰＤＰコンテキストを起動し、かつ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する手順を図示しており、特に次のように説明される。
【０１１７】
ステップＳ801：
ＰＣＥＦは、デフォルトＰＤＰコンテキストを起動するリクエストを、ＵＥから受信する。
【０１１８】
ステップＳ802：
ＰＣＥＦは、ＰＣＲＦに、デフォルトＰＤＰコンテキストの識別子情報を含むＣＣＲメッセージを送信する。
【０１１９】
ステップＳ803：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動させ、ＣＣＡメッセージは、デフォルトＰＤＰコンテキストの識別子情報、及び、事前に定義されたＰＣＣルール名を含んでいる。
【０１２０】
ステップＳ804：
ＰＣＥＦは、ＣＣＡメッセージを受信し、かつ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する。
【０１２１】
ステップＳ805：
ＰＣＥＦは、デフォルトＰＤＰコンテキスト起動応答を、前記ＵＥに返す。
【０１２２】
以降、ユーザは、シグナリングＩＰフローの専用ＰＤＰコンテキストを起動するリクエストを開始してもよい。ステップＳ806〜Ｓ810は、シグナリングＩＰフローのＰＤＰコンテキストを確立するステップ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止するステップ、及び、シグナリングＩＰフローのＰＤＰルールに対して事前に定義されたＰＣＣルールを起動するステップの手順を示しており、特に次のように説明される。
【０１２３】
ステップＳ806：
ＰＣＥＦは、ＰＤＰコンテキストを起動するためのリクエストをＵＥから受信し、前記リクエストはシグナリングタグを運ぶ。
【０１２４】
ステップＳ807：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（ベアラ使用（Bearer Usage）のパラメータ、及び、シグナリングＩＰフローのＰＤＰコンテキストの識別子を含む）を送信し、ベアラ使用（Bearer Usage）の前記パラメータはシグナリングタグ情報を含んでいる。
【０１２５】
ステップＳ808：
ＰＣＲＦは、確立されるＰＤＰコンテキストが、ベアラ使用（Bearer Usage）のパラメータにおけるシグナリングタグ情報に従って、シグナリングを運ぶのに使用されることを理解し、かつ、ＣＣＡメッセージを介して、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動させ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及び事前に定義されたＰＣＣルール名のＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及び事前に定義されたＰＣＣルール名の識別子とを含んでいる。
【０１２６】
ステップＳ809：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰルールに対して事前に定義されたＰＣＣルールの動きを停止し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたルールを起動する。
【０１２７】
ステップＳ810：
ＰＣＥＦは、シグナリングＩＰフローＰＤＰコンテキスト起動応答を、ＥＵに返す。
【０１２８】
ステップＳ811〜Ｓ816は、シグナリングＩＰフローパス状態報告を申し込むステップ、及び、シグナリングＩＰフローパス状態を報告するステップの手順を示しており、特に次のように説明される。
【０１２９】
ステップＳ811：
ＡＦはＵＥからのＳＩＰシグナリングを処理する。
【０１３０】
ステップＳ812：
ＡＦはＰＣＲＦからのシグナリングＩＰフローパス状態を申し込む。
【０１３１】
ステップＳ813：
ＰＣＲＦは、ＰＣＥＦからのＰＤＰコンテキストのベアラに関するイベントを申し込む。
【０１３２】
ステップＳ814：
事前に定義されたＰＣＣルールに対応するＰＤＰコンテキストのベアライベントが、ＰＣＥＦによって検出される。
【０１３３】
ステップＳ815：
ＰＣＥＦは、ＰＣＲＦに、ＰＤＰベアライベント検出報告（対応するベアライベント、及び、事前に定義されたＰＣＣルール名を運ぶ）を送信する。
【０１３４】
ステップＳ816：
ＰＣＲＦは、シグナリングＩＰフローシグナリングパス状態報告を、ＡＦに送信する。
【０１３５】
したがって、ＵＥがシグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングはデフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルール、及び、事前に定義されたルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始された場合、セッションシグナリングはシグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたＰＣＣルール、及び、事前に定義されたＰＣＣルール名によって実施される。
【０１３６】
図９には、第２方法において、シグナリングＰＣＣルール及びその名前を生成し、かつ、シグナリングＩＰフローパス状態を報告するメカニズムが示されており、メカニズムでは、ＰＣＲＦは、ＵＥに対するＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成され、かつ、メカニズムの特定のフローは以下を含んでいる。
【０１３７】
ステップＳ901〜Ｓ906は、デフォルトＰＤＰコンテキストを確立し、かつ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルール及びその名前をインストールする手順を示しており、かつ、次のように説明される。
【０１３８】
ステップＳ901：
ＰＣＥＦは、ＵＥから送信された、デフォルトＰＤＰコンテキストを起動するためのリクエストを受信する。
【０１３９】
ステップＳ902：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（デフォルトＰＤＰコンテキストの識別子情報を含む）を送信する。
【０１４０】
ステップＳ903：
ＰＣＲＦは、シグナリングＰＣＣルール（ＡＦのアドレスを含む）を生成する。
【０１４１】
ステップＳ904：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールさせ、ＣＣＡメッセージは、デフォルトＰＤＰコンテキストの識別子情報、及び、シグナリングＰＣＣルールを含んでいる。
【０１４２】
ステップＳ905：
ＰＣＥＦは、ＣＣＡメッセージを受信し、かつ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールする。
【０１４３】
ステップＳ906：
ＰＣＥＦは、デフォルトＰＤＰコンテキスト起動応答を、ＵＥに返す。
【０１４４】
以降、ユーザは、シグナリングＩＰフローの専用ＰＤＰコンテキストを起動するリクエストを開始してもよい。ステップＳ907〜Ｓ912は、シグナリングＩＰフローのＰＤＰコンテキストを起動するステップ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールを削除するステップ、及び、シグナリングＩＰフローのＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールするステップの手順を示しており、特に次のように説明される。
【０１４５】
ステップＳ907：
ＰＣＥＦは、ＰＤＰコンテキストを起動するためのリクエストを、ＵＥから受信し、前記リクエストはシグナリングタグを運ぶ。
【０１４６】
ステップＳ908：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（ベアラ使用（Bearer Usage）のパラメータ、及び、シグナリングＩＰフローのＰＤＰコンテキストの識別子を含む）を送信する。
【０１４７】
ステップＳ909：
ＰＣＲＦは、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータに従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成する。
【０１４８】
ステップＳ910：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルールを削除させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールさせ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及びシグナリングＰＣＣルールのＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及びシグナリングＰＣＣルールの識別子とを含んでいる。
【０１４９】
ステップＳ911：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルールを削除し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールする。
【０１５０】
ステップＳ912：
ＰＣＥＦは、シグナリングＩＰフローＰＤＰコンテキスト起動応答を、ＵＥに返す。
【０１５１】
ステップＳ913〜Ｓ918は、シグナリングＩＰフローパス状態報告を申し込み、かつ、シグナリングＩＰフローパス状態を報告する手順を示しており、ＰＣＥＦはシグナリングＰＣＣルールに対応するＰＤＰコンテキストのベアライベント検出報告を送信し、かつ、ＰＣＲＦは、報告で運ばれたシグナリングＰＣＣルール名に従ってシグナリングＩＰフローパス状態報告を送信する。
【０１５２】
したがって、ＵＥが、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングは、デフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルール及びシグナリングＰＣＣルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルール及びシグナリングＰＣＣルール名によって実行される。
【０１５３】
ステップＳ908では、ＰＣＥＦからＰＣＲＦに送信されたＣＣＲメッセージが、ＰＤＰコンテキストのＴＦＴ（Traffic Flow Template）をさらに含み、ＰＣＲＦは、ＴＦＴにおけるアドレスと、ステップ909におけるＡＦのアドレスとを比較してもよく、かつ、ＴＦＴにおけるアドレスがＡＦのアドレスとマッチングした場合、ＰＣＲＦは、確立されるＰＤＰがシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成してもよい。換言すれば、ステップＳ909では、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータに従ってシグナリングを運ぶのに使用されることをＰＣＲＦが理解できない場合、ＰＣＲＦは、確立されるＰＤＰがＴＦＴに従ってシグナリングを運ぶのに使用されることをさらに理解してもよい。代わりに、ＰＣＲＦは、確立されるＰＤＰがＴＦＴに直接従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成してもよい。
【０１５４】
図10に示されたように、事前に定義されたＰＣＣルールは、デフォルトＰＤＰコンテキストにおいて起動され、かつ、生成されたシグナリングＰＣＣルールは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいてインストールされる。この実施例では、ＰＣＥＦは、事前に定義されたＰＣＣルール及びその名前を用いて構成され、かつ、ＰＣＲＦは、事前に定義されたＰＣＣルール名、及び、ＵＥに対してＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成される。
【０１５５】
ステップＳ1008：
ＰＣＲＦは、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータ又はＴＦＴにおけるアドレス情報に従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成する。
【０１５６】
ステップＳ1009：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールさせ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及びシグナリングＰＣＣルールのＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及び事前に定義されたＰＣＣルール名の識別子を含んでいる。
【０１５７】
ステップＳ1010：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールする。
【０１５８】
他のステップの説明は重ねて行われない。したがって、ＵＥが、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングは、デフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルール及び事前に定義されたＰＣＣルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルール名及びその名前によって実施される。
【０１５９】
実際に、生成されたシグナリングＰＣＣルール及びその名前はデフォルトＰＤＰコンテキストにインストールされ、かつ、事前に定義されたＰＣＣルールは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて起動してもよく、かつ、この実施例では、ＰＣＥＦは、事前に定義されたＰＣＣルール及びその名前を用いて構成される必要があり、かつ、ＰＣＲＦは、事前に定義されたＰＣＣルール名、及び、ＵＥに対して、ＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成される必要がある。この場合、ＵＥがシグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングはデフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストにインストールされたシグナリングＰＣＣルール及びその名前によって実施され、かつ、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストにおいて起動された事前に定義されたＰＣＣルール及びその名前によって実施される。
【０１６０】
図11に示すように、ＰＣＲＦが本発明のさらに他の実施例によって設けられ、かつ、ＰＣＲＦは、
事前に定義されたＰＣＣルールとその名前とを格納するように構成された、第１記憶ユニット111と、
リクエストに応じて起動されるＰＤＰコンテキストに対して、前記事前に定義されたＰＣＣルールとその前記名前とを起動するように構成された、第１関連付けユニット112と、
ＰＣＥＦに命令して、前記ＰＤＰコンテキストに対して、前記事前に定義されたＰＣＣルールを起動させるように構成された、第１通知ユニット113と、
前記事前に定義されたＰＣＣルール名を運ぶＰＤＰベアライベント検出報告を受信し、かつ、シグナリングＩＰフローパス状態報告を、アプリケーション機能（Application Function）に送信するように構成された、第１報告ユニット114と
を備えている。
【０１６１】
図12に示すように、ＰＣＲＦが本発明の他の実施例によって設けられ、かつ、ＰＣＲＦは、
ＡＦの事前設定されたアドレスを格納するように構成された、第２記憶ユニット121と、
シグナリングＰＣＣルール（前記ＡＦの前記アドレスと、前記シグナリングＰＣＣルールの名前とを含む）を生成し、かつ、リクエストに応じて起動されるＰＤＰコンテキストに対して、前記シグナリングＰＣＣルールとその前記名前とを起動するように構成された、第２関連付けユニット122と、
ＰＣＥＦに命令して、前記ＰＤＰに対して、前記シグナリングＰＣＣルールをインストールさせるように構成された、第２通知ユニット213と、
シグナリングＰＣＣルール名を運ぶＰＤＰベアライベント検出報告を受信し、かつ、シグナリングＩＰフローパス状態報告を、前記ＡＦに送信するように構成された、第２報告ユニット124と
を備えている。
【０１６２】
本発明のさらに他の実施例によれば、図11及び図12において構築された構成を用いたＰＣＲＦが提供される。
【０１６３】
本発明の本質及び範囲から逸脱することなく、当業者によって、多様な変形例及びバリエーションが本発明に対してなされ得ることは明らかである。したがって、本発明は、添付の特許請求の範囲及びその均等物に含まれる全ての変形例及びバリーションを包含することを意図している。
【符号の説明】
【０１６４】
611 第１申込リクエスト送信ユニット
612 第１ベアライベント報告受信ユニット
621 第１申込リクエスト受信ユニット
622 第１ルール確立ユニット
623 第１ベアライベント受信ユニット
624 第１ベアラ報告処理ユニット
711 第２申込リクエスト送信ユニット
712 第２ベアライベント報告受信ユニット
721 第２申込リクエスト受信ユニット
722 第２ルール確立ユニット
723 第２ベアライベント受信ユニット
724 第２ベアラ報告処理ユニット
114 第1報告ユニット
111 第1記憶ユニット
112 第1関連付けユニット
113 第1通知ユニット
124 第２報告ユニット
121 第２記憶ユニット
122 第２関連付けユニット
123 第２通知ユニット
【技術分野】
【０００１】
本出願は、中国特許出願公開第200710087199.6号公報、及び、第200710100495.5号公報（2007年３月23日及び2007年４月17日にそれぞれ出願され、発明の名称を「シグナリングＩＰフローのベアライベントを報告するための制御方法及び機能エンティティ」とする）のメリットを主張し、引用することによりその全体を本明細書に組み込む。
【０００２】
本発明は、通信技術に関し、特に、シグナリングＩＰ（Internet Protocol）フローのベアライベントを報告するための制御方法、システム、及び、機能エンティティ（function entity）に関する。
【背景技術】
【０００３】
ＩＭＳ（IP Multimedia Subsystem）ポリシー制御メカニズム（即ち、ＳＢＬＰ（Service Based Local Policy））、及び、ＦＢＣ（Flow Based Charging）技術は、３ＧＰＰ（Third Generation Partnership Project）Ｒ６プロトコル規格において指定されている。しかし、ポリシー制御は、特定の手順に関するＦＢＣのそれらに類似した多数の機能を含み、かつ、ポリシー制御とＦＢＣの分離は、ネットワーク構成の複雑さの増大、及び、コスト増大を必ずもたらし、さらに、制御効果は低減され、故に、ユーザ経験に影響を及ぼす。３ＧＰＰリリース７の規格は、ポリシー制御及びＦＢＣを収束させ、かつ、ＰＣＣ（Policy Control and Charging）アーキテクチャを提案し、図１の破線のブロックで示されるように、アーキテクチャは、ＯＳＣ（Online Charging System）（ＣＡＭＥＬ ＳＣＰ（Customized Applications for Mobile Network Enhanced Logic Service Control Point）、及び、サービスデータフローベースクレジット制御（Service Data Flow Based Credit Control）をさらに含む）を備えている。
【０００４】
ＡＦ（Application Function）は、アプリケーション機能エンティティ（例えば、ＩＭＳにおけるＰ−ＣＳＣＦ（Proxy Call Session Control Function））であり、かつ、ＰＣＲＦ（Policy Control and Charging Rules Function）にポリシー確立及びチャージング制御に対する動的セッション情報を提供するように構成されている。ＰＣＲＦは、アプリケーション層サービス情報、ベアラ層情報、ローカルオペレータ構成、及び、ユーザ申込（subscription）プロフィールに従って、ＱｏＳ認証及びチャージングルールを伴うＰＣＥＦ（Policy Control and Charging Rules Function）を提供し、かつ、ユーザプレーンデータ（例えば、ゲーティングの使用禁止、及び、ＩＰパケットの破棄）に関するゲーティング機能を判断するように構成されている。一般に、ＰＣＥＦは、ＧＷ（Gateway）（例えば、ＧＰＲＳ（General Packet Radio Service）におけるＧＧＳＮ（Gateway GRPS Support Node））に配置され、かつ、ＰＣＲＦから送信されたポリシールールに従って、ＱｏＳ処理を実行し、サービスデータフローを検出し、かつ、オンライン／オフラインチャージングなどの機能を実行するように構成されている。ＳＰＲ（Subscription Profile Repository）は、ユーザ申込プロフィール（ＰＣＲＦに対するポリシー確立及びチャージング制御に必要な）を格納及び提供するように構成された、論理エンティティである。
【０００５】
ＰＣＣアーキテクチャを用いて、オペレータは、ベアラ層でデータフローのＱｏＳ、チャージングなどの制御を実行してもよく、それによって、上位のサービス層からは隠蔽されるトランスポートネットワークの詳細を使用可能にし、換言すれば、サービス層はベアラ制御層の上にあり、かつ、ベアラ制御層はベアラ層の詳細をサービス層から隠蔽し、かつ、下位のトランスポートネットワークでリソースの使用を理解する。一方では、ＰＣＲＦは、サービス層によって示されたセッション交渉情報に従って、ポリシーを確立して、ベアラ層でネットワークリソースの使用を制御してもよく、他方では、下にあるベアラの使用に関する変化のメカニズム報告を通じて（例えば、リソース損失、及び、ゲートウェイ故障）、サービス層に通知してもよく、したがって、サービス層は、適した変更を実行し、かつ、対応するポリシーを提供してもよい。
【０００６】
次の２つの用語が記載のためにまず説明される。
【０００７】
フロー識別子情報：
フロー識別子情報は、２組（2-tuple）＜メディアコンポーネント番号（例えば、メディアコンポーネント番号（Media Component Number）ＡＶＰ）、ＩＰフロー番号（例えば、フロー番号（Flow Number）ＶＡＰ）＞として表される。メディアコンポーネント番号は、メディアタイプ（例えば、オーディオフロー及びビデオフロー）を識別する。メディアコンポーネントは、１又は複数のＩＰフローを含んでもよい。フロー識別子情報は、セッション交渉の後に取得されたＳＤＰ（Session Description Protocol）情報から導出され、かつ、メディアＩＰフローを固有に識別する。
【０００８】
２．５組(5-tuple)（例えば、フロー記述（Flow Description）ＡＶＰ）：
５組は、＜ソースアドレス、ソースポート番号、宛先アドレス、宛先ポート番号、プロトコル＞からなる。ソースアドレス及びソースポート番号は、セッションのイニシエータのＩＰアドレス及びポート番号を識別し、宛先アドレス及び宛先ポート番号は、セッションの受信器のＩＰアドレス及びポート番号を識別し、かつ、プロトコルは、メディアＩＰフローのトランスポートに使用されたプロトコルを識別する。５組は、メディアＩＰフローを固有に識別し、かつ、セッション中に、メディアＩＰフローと特定のベアラを関連付けるように構成されている（５組と、ベアラを固有に識別するＴＦＴ（Traffic Flow Template）とを結合することによって実行される）。５組は、セッション交渉に対するＳＤＰに従って導出される。
【０００９】
ＰＣＣアーキテクチャの仕様では、ＡＦはメディアベアラの使用を申し込み（subscribe）、故に、メディアベアライベントが報告されることを可能にする。ベアライベントの検出によって、ＰＣＥＦはベアライベントをＰＣＲＦに報告し、かつ、新規ポリシーをリクエストする。ＰＣＲＦは、新規ポリシーを確立する前に、イベント報告を通じて、ＡＦにＩＰフローに対応するベアラの変化を通知する。ＡＦは、ＰＣＲＦが新規ＰＣＣルールを確立することに基づき、ＰＣＲＦに調整されたセッション情報を送信する。メディアベアライベントを申し込み、かつ、メディアベアライベントを報告することの特定の実施例が図２に示されている。
【００１０】
ステップＳ201〜Ｓ206は、ベアライベント報告を申し込む手順を図示しており、かつ、次のように説明される。
【００１１】
ステップＳ201：
ＡＦは、アプリケーション層サービス情報をＰＣＲＦに送信して、ベアライベント報告を申し込む。セッションパラメータ（例えば、メディアコンポーネント番号（即ち、メディアコンポーネント番号（Media Component Number）ＡＶＰ）、フロー番号のパラメータ（即ち、フロー番号（Flow Number）ＡＶＰ）、５組のパラメータ（即ち、フロー記述（Flow Description）ＡＶＰ）、及び、申し込まれる特定のベアライベント（例えば、ベアラ損失及びベアラリリース）を示す特定のアクション（即ち、特定アクション（Specific Action）ＡＶＰ）のパラメータ）は、ＡＡＲ（Authorize-Authenticate-Request）で運ばれる。
【００１２】
ステップＳ202〜Ｓ203：
ＰＣＲＦは、受信したセッションパラメータを格納し、かつ、ＡＡＡ（Authorize-Authenticate-Answer）応答を返す。
【００１３】
ステップＳ204：
ＰＣＲＦは、サービス層情報、ベアラ層情報（ＰＤＰコンテキスト確立リクエストにより、ＰＣＥＦによってＰＣＲＦに提供された）、申込プロフィール、及び、オペレータのローカルポリシーに従って、ＰＣＣルールを確立及び格納する。
【００１４】
ステップＳ205〜Ｓ206：
ＰＣＲＦは、ＰＣＣルールをＰＣＥＦに送信する（ＰＡＲ（Re-Auth-Request）メッセージにおけるチャージングルールインストール（Charging Rule Install）を介して、チャージングルールインストール（Charging Rule Install）のパラメータで運ばれているＰＣＣルールと共に）。さらに、ＰＡＲメッセージは、ＰＣＣルール名（ＰＣＣルールのために生成された）を含んでいる。
【００１５】
ＰＣＥＦによるベアライベント検出が以前にリクエストされなかった場合、ＰＣＲＦは、検出される特定のベアライベント（例えば、ベアラ損失、及び、ベアラリリース）を示すために、イベントトリガ（Event Trigger）のパラメータを運ぶ。
【００１６】
ステップＳ207〜Ｓ211には、ベアライベントを報告する手順が図示されており、次のように説明される。
【００１７】
ステップＳ207：
前記ベアライベントは前記ＰＣＥＦによって検出される。
【００１８】
ステップＳ208〜Ｓ209：
ＰＣＥＦは、チャージングルール報告（Charging Rule Report）（ＣＣＲ（Credit-Control-Request）メッセージでＰＣＣルール名を運ぶ）のパラメータを通じて、ＰＣＣルール名（ＰＣＲＦに対するベアラに関連付けられた）を報告する。報告中、ベアライベントを示すイベントトリガ（Event Trigger）のパラメータも運ばれる。メッセージを受信すると、ＰＣＲＦはＣＣＡ（Credit-Control-Answer）メッセージをＰＣＥＦに返す。
【００１９】
ステップＳ210〜Ｓ211：
ＰＣＲＦは、ＡＦに、ＰＣＥＦによって報告されたＰＣＣルール名に従って、ベアライベントとともに、影響されたメディアＩＰフローの識別子を報告する。ＰＡＲメッセージは、フロー（Flow）のパラメータ（ベアライベントに関連付けられたメディアＩＰフローの識別子を示す）を運び、かつ、フロー（Flow）のパラメータは、メディアコンポーネント番号、及び、フロー番号を含んでいる。さらに、ＰＡＲメッセージは、特定のベアライベントを示す特定のアクションのパラメータを運ぶ。メッセージを受信すると、ＡＦはＲＡＡメッセージをＰＣＲＦに返す。
【００２０】
ベアライベントを報告するメカニズムを用いて、ベアラが変化するとき（例えば、ベアラリソース損失、及び、ゲートウェイ故障の発生）、ベアラ層は、ベアライベントのサービス層にタイムリーに通知して、新規ポリシーをリクエストしてもよい。サービス層は、報告メカニズムによってベアラ変化を理解し、かつ、ベアラ変化に応答する（例えば、サービス層が、セッション変更、セッション終了などをリクエストしてもよい）。
【００２１】
メディアＩＰフローと同様に、セッション中のシグナリングＩＰフローもベアラを利用し、かつ、サービス層は、シグナリングに関する下にあるベアラの状態をタイムリーに知る必要がある。シグナリングに関するベアラが変化したとき、ベアラはベアライベントをサービス層に報告する必要があり、したがって、サービス層は対応する変更をタイムリーに実行してもよい。シグナリングパスの状態を報告するための既存方法は次の通りである。
【００２２】
シグナリングタグが、ＵＥ（User Equipment）によってＰＤＰ（Packet Data Protocol）起動リクエストで運ばれる。ＰＣＲＦは、確立されるＰＤＰコンテキストがＩＰシグナリングを運ぶのに使用されることを理解し、かつ、ＰＣＣルールをＰＣＥＦに確立及び送信し、それによって、シグナリングタグを備えたＰＤＰコンテキストを確立する。シグナリングパス状態報告を申し込むと、ＡＦはシグナリングＩＰフロータグを運び、シグナリングイベントに対する申し込みについて、ＰＣＲＦに通知する。シグナリングタグを備えたベアラに関する変化の検出によって、ＰＣＥＦは、ＰＣＲＦに、ベアラに関連付けられたＰＣＣルール名を報告し、かつ、ＰＣＲＦは、ＰＣＣルール名に従って、シグナリングを運ぶＰＤＰコンテキストの変化を理解し、したがって、シグナリングパス状態はＡＳに報告される。
【００２３】
シグナリングパス状態を報告する特定の実施例が図３に示されている。
【００２４】
ステップＳ301〜Ｓ307は、シグナリングタグを備えたＰＤＰコンテキストを確立する手順を示しており、特に次のように説明される。
【００２５】
ステップＳ301：
ＰＣＥＦは、ＵＥから、ＰＤＰコンテキスト起動リクエスト（シグナリングタグを運ぶ）を受信する。
【００２６】
ステップＳ302：
ＰＣＥＦは、ＰＤＰコンテキスト確立リクエストをＰＣＲＦに送信する。ＣＣＲメッセージは、ベアラ層情報（例えば、ベアラ使用（Bearer Usage）のパラメータ）（シグナリングタグを備えたＰＤＰコンテキストの確立がリクエストされることを示す）を運ぶ。選択的に、ＰＣＲＦは、ＣＣＡメッセージをＰＣＥＦに返す（図示せず）。
【００２７】
ステップＳ303：
ＰＣＲＦは、受信したベアラ層情報を格納し、かつ、リクエストに応じて確立されるＰＤＰコンテキストが、ベアラ使用（Bearer Usage）のパラメータに従って、ＩＭＳシグナリングを運ぶのに使用されることを理解する。
【００２８】
ステップＳ304：
ＰＣＲＦは、ベアラ層情報、申込プロフィール、及び、オペレータポリシーに従って、ＰＣＣルール及び対応するＰＣＣルール名を生成する。
【００２９】
ステップＳ305〜Ｓ307：
ＰＣＲＦは、ＰＣＣルール及び対応するＰＣＣルール名をＰＣＥＦに送信し、かつ、ＰＣＥＦは、ＰＣＣルールをインストールし、かつ、ＰＤＰコンテキスト起動リクエストに対する応答をＵＥに返し、したがって、シグナリングタグを備えたＰＤＰコンテキストが確立される。
【００３０】
ステップＳ308〜Ｓ312は、シグナリングパス状態報告を申し込む手順を示しており、かつ、特に次のように説明される。
【００３１】
Ｓ308〜Ｓ310：
セッションメッセージがＡＦに到達したとき、ＡＦは、シグナリングパス状態報告に対する申込を開始する。フロー使用（Flow Usage）（ＡＦシグナリングとしてセットし、シグナリングイベントに関する申込を示す）、及び、特定のアクション（ベアラ損失、及び、ベアラリリースなどの特定の申込されたイベントを示す）のパラメータがＡＡＲメッセージで運ばれる。ＰＣＲＦは、フロー使用のパラメータ値に基づいて、この申込がシグナリングパス状態に関する申込であることを理解する。
【００３２】
Ｓ311〜Ｓ312：
ＰＣＲＦはＰＣＣルールをＰＣＥＦに送信する。ＰＣＣルールを示すチャージングルールインストール（Charging Rule Install）のパラメータは、ＲＡＲメッセージで運ばれる。ＰＣＥＦによるベアライベントの検出が申し込みされない場合、ＰＣＲＦは、運ばれている特定のベアライベントを示すイベントトリガ（Event Trigger）のパラメータを用いて、申込を開始する。イベントトリガ（Event Trigger）のパラメータは、特定のアクションのパラメータに従って生成される。
【００３３】
ステップＳ313〜Ｓ318はシグナリングパス状態を報告する手順を示しており、かつ、特に次のように説明される。
【００３４】
ステップＳ313：
ベアライベントがＰＣＥＦによって検出される。
【００３５】
ステップＳ314〜Ｓ315：
ＰＣＥＦは、ベアラに関連付けられたＰＣＣルールをＰＣＲＦに報告する。
【００３６】
ステップＳ316〜Ｓ318：
ＰＣＲＦは、ＰＣＣルール名に従って、ＩＭＳシグナリングを運ぶＰＤＰチャネルの変化を決定し、かつ、シグナリングパス状態を報告する。
【００３７】
シグナリングパス状態を報告するための既存メカニズムの実施例は、フロー使用（Flow Usage）のパラメータに依存する。シグナリングパス状態に対する申込を開始すると、サービス層は、ＡＦシグナリング識別子として、フロー使用（Flow Usage）のパラメータを使用して、ＰＣＲＦにシグナリング関連の申込を通知する。しかし、現在定義されたように、フロー使用（Flow Usage）のパラメータは、メディアサブコンポーネント（Media Sub-Component）のパラメータのサブパラメータとして存在し、かつ、フロー使用（Flow Usage）のパラメータは、メディアコンポーネント記述（Media Component Description）、及び、メディアサブコンポーネント（Media Sub-Component）のパラメータとともに使用しなければならない。シグナリングＩＰフローに対して、メディアコンポーネント記述（Media Component Description）のパラメータ、又は、メディアサブコンポーネント（Media Sub-Component）のパラメータの値は既存規格で定義されず、その結果、シグナリング情報は報告されることを許可されず、したがって、シグナリングパス状態を報告するメカニズムは実施することができない。
【先行技術文献】
【特許文献】
【００３８】
【特許文献１】中国特許出願公開第200710087199.6号公報
【特許文献２】中国特許出願公開第200710100495.5号公報
【発明の概要】
【課題を解決するための手段】
【００３９】
本発明の態様は、シグナリングＩＰフローのベアライベントを報告するための制御方法、システム、及び、機能エンティティを提供して、シグナリングＩＰフローのシグナリングパス状態の報告を実行する。
【００４０】
上記したソリューションを実行するため、シグナリングＩＰフローのベアライベントを報告する方法が本発明の態様によって提供され、前記方法は、
アプリケーション機能（Application Function）によって、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するステップと、
前記アプリケーション機能（Application Function）によって、前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するステップと
を具備し、
前記リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４１】
アプリケーション機能（Application Function）が本発明の他の態様により提供され、前記アプリケーション機能（Application Function）は、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第１申込リクエスト送信ユニットと、
前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４２】
ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）が本発明の他の態様により提供され、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を含む情報を運ぶベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えている。
【００４３】
シグナリングＩＰフローのベアライベントを報告するためのシステムが本発明の他の態様により提供され、かつ、前記システムは、アプリケーション機能（Application Function）と、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）とを備えている。
【００４４】
前記アプリケーション機能（Application Function）は、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第１申込リクエスト送信ユニットと、
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）によって送信された前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ。
【００４５】
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
前記第１申込リクエスト送信ユニットから、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記リクエストを受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を含む情報を運ぶ前記ベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えている。
【００４６】
前記制御方法を用いて、ＩＰフローのベアライベントを報告するためのシステム及び機能エンティティが本発明の態様によって提供されて、５組はシグナリングＩＰフロー、及び、メディアＩＰフローに対してそれぞれ生成され、したがって、シグナリングパス状態を報告するメカニズムは、フロー使用（Flow Usage）、シグナリングタグを備えたＰＤＰコンテキストなどのパラメータによって限定されず、それによって、シグナリングＩＰフローの前記シグナリングパス状態を報告し、かつ、シグナリングパス状態を報告するメカニズムと、メディアＩＰフローのベアライベントを報告するメカニズムとを結合し、かつ、さらに、シグナリングＩＰフローとベアラとの間のシグナリング及び関連付けに対して、対応するＰＣＣルールを確立する。
【図面の簡単な説明】
【００４７】
【図１】従来技術におけるＰＣＣアーキテクチャの構成の概略図である。
【図２】従来技術におけるメディアベアライベントを申込及び報告するためのメカニズムの概略フローチャートである。
【図３】従来技術におけるシグナリングパス状態を報告するためのメカニズムの概略フローチャートである。
【図４】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御方法の概略フローチャートである。
【図５】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御方法の概略フローチャートである。
【図６】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御システムの一般的な構成の概略図である。
【図７】本発明の実施例によるシグナリングＩＰフローのベアライベントを報告するための制御システムの一般的な構成の概略図である。
【図８】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図９】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図１０】本発明の実施例によるシグナリングＩＰフローパス状態を報告するための方法の概略フローチャートである。
【図１１】本発明の実施例によるＰＣＲＦの一般的な構成の概略図である。
【図１２】本発明の実施例によるＰＣＲＦの一般的な構成の概略図である。
【発明を実施するための形態】
【００４８】
背景技術で既存のメディアベアライベントを報告するメカニズム、及び、シグナリングパス状態を報告するメカニズムを理解することによって、シグナリングパス状態を報告するための既存のメカニズムのアプリケーションシナリオが、以下のように、多数の側面で限定されていることが分かる。
【００４９】
シグナリングパス状態を報告するための既存のメカニズムの実施例は、フロー使用（Flow Usage）のパラメータに依存する。シグナリングパス状態に対する申込を開始すると、サービス層は、ＡＦシグナリング識別子として、フロー使用（Flow Usage）のパラメータを使用して、ＰＣＲＦにシグナリング関連の申込を通知する。しかし、現在定義されたように、フロー使用（Flow Usage）のパラメータは、メディアサブコンポーネント（Media Sub-Component）のパラメータのサブパラメータとして存在し、かつ、フロー使用（Flow Usage）のパラメータを、メディアコンポーネント記述（Media Component Description）、及び、メディアサブコンポーネント（Media Sub-Component）のパラメータとともに使用しなければならない。シグナリングＩＰフローに対して、メディアコンポーネント記述（Media Component Description）のパラメータ、又は、メディアサブコンポーネント（Media Sub-Component）のパラメータの値が既存規格で定義されず、その結果、シグナリング情報は送信又は報告されることを許可されず、したがって、シグナリングパス状態を報告するメカニズムは実施することができない。
【００５０】
また、シグナリングパス状態を報告するための既存のメカニズムの実施例は、シグナリングタグを備えたＰＤＰコンテキストの確立に依存し、かつ、アプリケーションシナリオ（シグナリングタグを備えていない、シグナリング−ベアリング（bearing）ＰＤＰコンテキスト）はサポートされていない。シグナリングタグは、ＰＤＰコンテキストの確立中に運ばれる必要があり、したがって、ＰＣＲＦは、どのＰＤＰチャネルがシグナリングを運ぶのに使用されるかを理解してもよい。結果的にベアラが変更されたとき、ＰＣＲＦは、ベアラに対応するＰＣＣルール名に従って、シグナリング−ベアリングＰＤＰコンテキストが変更されることを決定し、それによって、シグナリングパスの報告を実行する。しかし、シグナリングタグを備えたＰＤＰコンテキストの確立は、ＵＥ能力及びオペレータによるサポートに依存する。換言すれば、アプリケーションシナリオ（シグナリングを運ぶＰＤＰコンテキストがシグナリングタグを備えていない）は、実際のネットワークアプリケーションの中に存在してもよい。その結果、シグナリングパス状態を報告するためのメカニズムは、アプリケーションシナリオ（ＰＤＰコンテキストがシグナリングタグを備えることなく提供される）において実行することができない。
【００５１】
また、シグナリングパス状態を報告する既存のメカニズムの実施例は、ＰＤＰコンテキストの確立中に生成された、関係するＰＣＣルールに依存している。ＰＤＰコンテキスト（シグナリングを運ぶ）の確立中に、関係するＰＣＣルールが生成されない場合、サービス層でのシグナリングＩＰフローのアドレス及びポート情報は、既存のメカニズムに従って、セッション中にＰＣＲＦに送信することができず、その結果、シグナリング関連のＰＣＣルールは確立することができず、結果として、ＰＣＥＦはベアライベントをＰＣＲＦに報告することができず、かつ、シグナリングパス状態報告は実行することができない。
【００５２】
さらに、シグナリングパス状態を報告するための既存のメカニズムは、メディアベアライベントを報告するメカニズムからは独立しており、その結果、ベアライベントを報告するメカニズム全体が複雑である。さらに、シグナリングパス状態を報告するメカニズムでは、シグナリングＩＰフローに対する５組（サービス層でシグナリングＩＰフローに対応する）が生成されず、その結果、シグナリングＩＰフローとベアラとの間の関連付けを確立することができない。
【００５３】
シグナリングパス状態を報告するための既存のメカニズムに存在する欠点のため、本発明の実施例によって、シグナリングＩＰフローのシグナリングパス状態を報告する制御方法が提供され、かつ、方法は、シグナリングパス状態を報告するメカニズムと、メディアベアラ状態を報告するメカニズムとを組合せ、したがって、ベアラ報告メカニズムが単純化され、かつ、シグナリングパス状態を報告するメカニズムのアプリケーションは、例えば、フロー使用（Flow Usage）のパラメータ、ＰＤＰコンテキストに対するシグナリングタグの提供、及び、ＰＤＰコンテキストの確立中に、関係するＰＣＣルールを生成することの必要性によって限定されない。
【００５４】
本発明の実施例では、主に、ベアライベントを報告する制御方法は次のステップを具備している。
【００５５】
１．各ＩＰフロー（ベアライベント報告に対する申込のリクエストがトリガされる）に対して、ＡＦは、５組を生成し、かつ、ＩＰフローのタイプに従って、フロー識別子情報を生成し、ＩＰフローは、シグナリングＩＰフロー及びメディアＩＰフローを具備してもよく、かつ、５組とフロー識別子情報の両方は、ＩＰフロー及びＩＰフローのタイプを識別してもよい。
【００５６】
２．ＡＦは、ＰＣＲＦに、ＩＰフローのベアライベントに対する申込のリクエストを送信する。申込リクエストは、５組及びフロー識別子情報を運ぶ。
【００５７】
３．ＰＣＲＦは、ＩＰフローのベアラに関連付けられたＰＣＣルール及びＰＣＣルール名を含むＰＣＣルール情報を確立し、ＰＣＣルール名及びフロー識別子情報をそれぞれ格納し、かつ、ＰＣＣルール情報をＰＣＥＦに送信する。
【００５８】
一部のアプリケーションシナリオでは、関連したＰＣＣルール情報は、ＩＰフローベアラに対して既に確立され、かつ、ＰＤＰコンテキスト又はセッションの交渉中に、ＰＣＥＦに送信される。この場合、ＩＰフローに利用可能なＰＣＣルール情報が既に存在し、かつ、ＰＣＲＦは、ＩＰフローベアラに関連付けられたＰＣＣルール情報を確立及び送信する必要はないが、生成されたＰＣＣルール名及びフロー識別子情報を格納する。
【００５９】
４．ＰＣＥＦは、ＰＣＣルールをインストールし、かつ、ベアライベントの検出によって、ＰＣＣルール名及び検出されたベアライベントをＰＣＲＦに報告する。
【００６０】
５．ＰＣＲＦは、関連したＰＣＣルール名に従って、フロー識別子情報を取得し、かつ、取得されたフロー識別子情報は、ベアライベント報告でＡＦに送信される。
【００６１】
６．ＡＦは、ベアライベント報告で運ばれた情報に従って、受信したベアライベント報告のタイプを決定し、シグナリングＩＰフローのベアライベント報告のタイプはシグナリングパス状態報告であり、かつ、メディアＩＰフローのベアライベント報告のタイプはメディアベアライベント報告である。
【００６２】
また、ステップ５では、対応する５組はベアライベント報告で運ばれ、かつ、ＡＦに転送してもよく、かつ、ステップ６では、ＡＦは５組に従って、受信したベアライベント報告のタイプを決定する。
【００６３】
本発明の実施例では、シグナリングパス状態を報告するメカニズムと、メディアＩＰフローのベアライベントを報告するメカニズムとは結合され、かつ、シグナリング情報はサービス層によって送信され、したがって、シグナリングパス状態を報告するメカニズムは、フロー使用（Flow Usage）のパラメータ、ＰＤＰコンテキストに対するシグナリングタグの提供などによって限定されず、故に、シグナリングＩＰフローに対して、ＰＣＣルール、及び、シグナリングＩＰフローとベアラとの間の関連付けを確立する。
【００６４】
本発明の実施例では、ＡＦは、サービス情報をＰＣＲＦに送信するに当たり、シグナリングＩＰフローか、又は、メディアＩＰフローのどちらが含まれるかをＰＣＲＦに通知する必要はなく、故に、ＰＣＲＦによって理解されることからフロータイプを隠蔽する。申込されたベアライベントの検出によって、ＰＣＥＦは、ＰＣＲＦに対するベアラに関するＰＣＣルール名を報告し、かつ、ＰＣＲＦは、ＰＣＣルール名に従って、フロー識別子情報を決定し、かつ、フロー識別子情報及びベアライベントをＡＦに報告する。ＡＦは、フロー識別子情報の生成ルールに従って、ベアライベント情報のタイプを決定し、かつ、適切に応答する。
【００６５】
本発明の実施例では、ベアライベントを報告するメカニズムは、確立されたＰＤＰコンテキストのタイプからは独立している。ＡＦは、サービス層プレーンで、一様なルールに従って、シグナリングＩＰフローとメディアＩＰフローに対する５組を生成し、かつ、ＰＣＲＦからフローに対応するベアライベントを申し込むとき、特定の５組を示す。ＰＣＲＦは、５組に従って、ベアラとＰＣＣルールとの間の関連付けを確立し、かつ、関連付けをＰＣＲＦに送信する。ベアライベントが発生したとき、ＰＣＥＦは、ベアラ及びベアライベントに関連付けられたＰＣＣルール名を報告する。
【００６６】
本発明の実施例では、５組、及び／又は、フロー識別子情報を次のように生成してもよい。メディアＩＰフローの５組、及び／又は、フロー識別子情報は、セッション交渉に対するＳＤＰから導出される。シグナリングＩＰフローの５組は、ＳＩＰメッセージ（例えば、ソースＩＰアドレス、宛先ＩＰアドレス、ポート番号、及び、採用されたプロトコル）における情報に従って生成される。メディアＩＰフローのメディアコンポーネント番号（１から始まり、かつ、昇順で識別することに使用される）を参照して、シグナリングＩＰフローは、デフォルトのメディアコンポーネント番号０を備えて、提供してもよい（例えば、＜０，１＞を使用して、シグナリングＩＰフローを示す）。
【００６７】
図４には、本発明の実施例によるシグナリングパス状態を報告する方法が示されている。本発明の実施例による制御方法は、ＰＤＰコンテキスト確立からは独立している。申込手順と報告手順が図４に示され、ステップＳ401〜Ｓ409が申込手順を示し、かつ、次のように説明される。
【００６８】
ステップＳ401：
ＡＦは、申込に対するトリガを受信すると、シグナリングパス状態に対する申込を開始する（例えば、登録メッセージがＡＦに到着し、かつ、ＡＦはシグナリングパス状態を申し込むように要求されるとき、又は、セッション交渉中）。
【００６９】
ステップＳ402：
メディアベアライベントを報告するメカニズムと、シグナリングパス状態を報告するメカニズムとの単一化に対して、シグナリングＩＰフローに対応するベアライベントを申し込むと、ＡＦは、シグナリングＩＰフロー５組、及び、シグナリングＩＰフローに対するフロー識別子情報を生成し、かつ、フロー識別子情報（メディアコンポーネント番号及びフロー番号）、シグナリングＩＰフロー５組、及び、特定の申し込みされたベアライベント（特定のアクションのパラメータによって示された）はＡＡＲで運ばれる。
【００７０】
ステップＳ403〜Ｓ404：
ＰＣＲＦは、受信したサービス層情報を格納し、かつ、ＡＡＡをＡＦに返す。
【００７１】
ステップＳ405：
ＰＣＲＦは、受信したサービス層情報（シグナリングＩＰフロー５組、ＱｏＳ情報など）、ベアラ情報（ＰＤＰ確立中にＰＣＥＦによって提供された）、申込プロフィール、及び、オペレータポリシーに従って、シグナリングＩＰフローのＰＣＣルール情報を確立及び格納し、前記ＰＣＣルール情報は、ＰＣＣルール及び対応するＰＣＣルール名を備えている。さらに、シグナリングＩＰフローに対して利用可能なＰＣＣルール及びＰＣＣルール名が既に存在するとＰＣＲＦが決定した場合、ＰＣＲＦは、ＰＣＣルール及びＰＣＣルール名をＰＣＥＦに送信する。
【００７２】
ステップＳ406：
ＰＣＲＦは、ＰＣＥＦに、ＲＡＲメッセージ（チャージングルールインストール（Charging Rule Install）のパラメータでＰＣＣルール情報を運ぶ）を送信する。
【００７３】
ＰＣＲＦがＰＣＥＦからベアライベント報告手順を以前に申し込んでいた場合、ＰＣＲＦは、ＰＣＥＦから申込を再び開始する必要はなく、そうでなければ、ＰＣＲＦは、ＰＣＥＦからベアライベントに対する申込を開始する必要がある。図４に示すように、ベアライベントに対する申込、及び、ＰＣＣルール情報の送信は、同じＲＡＲメッセージを介して、同時に実行してもよく、かつ、ＲＡＲメッセージでは、特定のアクションのパラメータに対応するイベントトリガ（Event Trigger）のパラメータは、ベアライベント（ＰＣＥＦから申込が行われる）を指定するために運ばれる。
【００７４】
ステップＳ407〜Ｓ408：
ＰＣＥＦはＰＣＣルール情報をインストールし、かつ、ＡＡＡをＰＣＲＦに返す。
【００７５】
上記した申込手順では、ＡＦは、生成された５組、及び、フロー識別子情報（シグナリングＩＰフローの）を使用して、シグナリングＩＰフローのベアライベント報告を申し込み、したがって、サービス層は、フロー使用（Flow Usage）のパラメータとは独立して、シグナリングパス状態に対する申込を開始することができる。
【００７６】
さらに、ＰＣＲＦは、受信したサービス層情報（シグナリングＩＰフローの５組、ＱｏＳ情報など）、ベアラ情報（ＰＤＰ確立中にＰＣＥＦによって提供された）、申込プロフィール、及び、オペレータポリシーに従って、ＰＣＣルール情報を確立及び格納し、それによって、各シグナリングＩＰフローのＰＤＰコンテキストがＰＣＣルールに関連付けられることを確実にする。実際には、ＰＣＲＦがＰＣＣルール情報を以前に確立及び格納した場合、ＰＣＲＦは、確立されたＰＣＣルール情報を、ＰＣＥＦに直接送信する。ＰＣＲＦによって申し込みされたベアライベントの検出によって、ＰＣＥＦは、検出されたベアライベントに関連付けられたＰＣＣルール名、及び、検出されたベアライベントをＰＣＲＦに報告する。換言すれば、シグナリングＩＰフローに利用可能なＰＣＣルール情報が存在すれば、ＰＣＣルール情報の確立又は格納は現ステップにおいて実行される必要はないが、ＰＣＣルール名とＩＰフローの５組は関連付けられ、かつ、格納される必要がある。
【００７７】
ステップＳ409〜Ｓ413は、ベアライベント報告の手順を図示しており、かつ、特に次のように説明される。
【００７８】
ステップＳ409：
ＰＣＥＦは、ベアラに関するイベントを検出する。
【００７９】
ステップＳ410〜Ｓ411：
ベアラに関するイベントを検出すると、ＰＣＥＦは、ベアラに関連付けられたＰＣＣルール名をＰＣＲＦに報告する。
【００８０】
ステップＳ412〜Ｓ413：
ＰＣＣルール名に従って、ＰＣＲＦは、ＡＦに、ベアライベント報告を介して、ベアライベントとともに、対応するフロー識別子情報について報告し、かつ、ＡＦは、報告の受信によって、ＰＣＲＦにＲＡＡ応答を返す。
【００８１】
さらに、ＡＦは、ベアライベント報告におけるフロー識別子情報に従って、報告されたベアライベントに関連付けられたＩＰフローのタイプを決定する。フロー識別子情報がシグナリングＩＰフローを示した場合、シグナリングパス状態報告が決定され、そうでなければ、メディアベアライベント報告が決定される。
【００８２】
ベアラに関するイベントを報告する手順では、ＰＣＥＦ及びＰＣＲＦは、ＩＰフローを区別する必要はなく、それによって、報告メカニズムを結合し、かつ、シグナリングＩＰフローとベアライベントとを関連付ける。
【００８３】
図５には本発明の他の実施例が図示されている。ＩＰフローを固有に識別するためのフロー識別子情報の機能は、５組によって実施してもよい。
【００８４】
ステップＳ502：
ＡＦは、ＩＰフローに対応するベアライベントを申し込むに当たり、フロー識別子情報を発行しなくてもよい。
【００８５】
ステップＳ512：
ＰＣＲＦは、ＰＣＣルール名に従って、ベアライベントとともにシグナリングＩＰフローの５組をＡＦに報告し、かつ、ＡＦはＲＡＡ応答をＰＣＲＦに返す。
【００８６】
ＡＦは、５組に対応するＰＣＣルール名に従って、報告されたベアライベントに関連付けられたＩＰフローのタイプを決定する。フロー識別子情報がシグナリングＩＰフローに一致した場合、シグナリングパス状態報告が決定され、そうでなければ、メディアベアライベント報告が決定される。
【００８７】
他のステップは、図４に示されたフローのステップと同じであり、それについての説明は重ねて記載されない。
【００８８】
本発明の実施例によれば、５組と、メディアコンポーネント番号及びシグナリングＩＰフローに対するフロー番号の値とを定義した後、シグナリング情報をサービス層から送信してもよく、したがって、申込及び報告手順を実行してもよい。
【００８９】
本発明の実施例によれば、５組はシグナリングＩＰフロー及びメディアＩＰフローに一致して生成され、したがって、セッション中、ＰＣＣルールはシグナリングＩＰフローに対して確立してもよく、かつ、シグナリングＩＰフローはベアラに結合してもよい。したがって、シグナリングパス状態は、ＰＤＰタイプに限定されることなく報告することができる。
【００９０】
本発明の実施例では、サービス層シグナリング情報が送信されて、リアルタイムでシグナリングに対応するＰＣＣルールを確立してもよく、それによって、シグナリングＩＰフローとベアラとの間の関連付けを確立する。
【００９１】
本発明の実施例では、ベアライベントを申し込むため、ＰＣＲＦは、シグナリングに関する申込について通知される必要がなく、かつ、ベアライベントの検出によって、ＰＣＲＦは、関係する申込がシグナリングに関する申込か、又は、メディアに関する申込かを理解する必要はないが、ベアラに対応する５組又はフロー識別子情報をＡＦに報告する。ＡＦは、報告がメディアベアライベントか、又は、シグナリングパス状態の報告に関するかをチェックする。換言すれば、フロータイプはＰＣＲＦの代わりにＡＦによって理解され、したがって、シグナリングパス状態を報告するメカニズムと、メディアベアライベントを報告するメカニズムとが結合される。
【００９２】
上記から分かるように、ユニバーサル、単純かつ効果的なベアライベントを報告するための制御方法が本発明の実施例によって提供され、かつ、シグナリングパス状態を報告するメカニズムとメディアＩＰフローのメディアイベントを報告するメカニズムとが結合され、それによって、シグナリングパス状態を報告するメカニズムを改善し、かつ、シグナリングパス状態報告の実行を確実にする。
【００９３】
図６には、本発明のさらなる実施例による図４に示された制御方法を実行するための制御システムが示され、かつ、制御システムは、ＡＦ61と、ＰＣＲＦ62と、ＰＣＥＦ63とを備えている。本発明はこれに限定されないが、実施例がほんの一例として示される（ＩＰフローの５組が運ばれる）。例えば、５組、又は、５組とフロー識別子情報の両方を運んでもよい。ＡＦ61は、主に、
ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを送信するように構成された、第１申込リクエスト送信ユニット611と、
前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から、前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニット612と
を備え、
前記申込リクエストは前記シグナリングＩＰフローの５組を運び、
前記ベアライベント報告は前記シグナリングＩＰフローの前記５組を運ぶ。
【００９４】
ＰＣＲＦ62は、主に、第１申込リクエスト受信ユニット621と、第１ベアラ報告処理ユニット624とを備え、好ましくは、第１ルール確立ユニット622と、第１ベアライベント受信ユニット623とを備えている。
【００９５】
前記第１申込リクエスト受信ユニット621は、アプリケーション機能（Application Function）から、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記リクエストを受信するように構成されている。前記申込リクエストは前記シグナリングＩＰフローの前記５組を含んでいる。
【００９６】
第１ルール確立ユニット622は、前記シグナリングＩＰフローの前記５組に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、前記ポリシー制御及びチャージング（Policy Control and Charging）ルールの名前を確立し、かつ、前記ＰＣＣルール、及び、前記ＰＣＣルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成されている。
【００９７】
第１ベアライベント受信ユニット623は、前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、前記ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）から受信するように構成されている。
【００９８】
第１ベアラ報告処理ユニット624は、前記シグナリングＩＰフローの前記５組を運ぶベアライベント報告を生成及び送信するように構成されている。前記５組は、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージング（Policy Control and Charging）ルール名に対応する前記シグナリングＩＰフローの前記５組であってもよい。
【００９９】
好ましくは、ＰＣＲＦ62は、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、又は、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在すると決定すると、前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルールの名前を確立し、前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、決定ユニット（図示せず）をさらに備えている。
【０１００】
本発明の実施例によれば、第１申込リクエスト送信ユニットと、第１ベアライベント報告受信ユニットとを備えた、アプリケーション機能（Application Function）がさらに設けられている。第１申込リクエスト送信ユニットは、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成され、かつ、申込リクエストは、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、第１ベアライベント報告受信ユニットは、シグナリングＩＰフローのベアライベント報告を、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成され、かつ、ベアライベント報告は、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ。
【０１０１】
アプリケーション機能（Application Function）の実施例は、上記した方法及びシステムと同じであり、それについての説明は重ねて行われない。
【０１０２】
本発明の他の実施例によれば、第１申込リクエスト受信ユニットと、第１ベアラ報告処理ユニットとを含むポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）が設けられている。第１申込リクエスト受信ユニットは、シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成され、かつ、申込リクエストは、シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、第１ベアラ報告処理ユニットは、ベアライベント報告（シグナリングＩＰフローの５組、及び／又は、フロー識別子情報に対応するベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名などの情報を運ぶ）を生成し、かつ、返すように構成されている。
【０１０３】
好ましくは、前記ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
シグナリングＩＰフローの５組、及び／又は、フロー識別子情報に従って、シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、かつ、ポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、第１ルール確立ユニットと、
検出されたベアライベント、及び、検出されたベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えてもよい。
【０１０４】
好ましくは、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）は、
申込リクエストで運ばれたシグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、又は、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在しないと決定すると、あるいは、申込リクエストで運ばれたシグナリングＩＰフローに利用可能なポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名が存在すると決定すると、第１ルール確立ユニットに命令して、ＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、チャージングルール及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）に送信するように構成された、決定ユニット
をさらに備えてもよい。
【０１０５】
アプリケーション機能（Application Function）の実施例は、上記した方法及びシステムと同じであり、それについての説明は重ねて行われない。
【０１０６】
図７には、図５に示された制御方法を実施するための制御システムが本発明のさらに他の実施例によって設けられ、かつ、制御システムは、ＡＦ71と、ＰＣＲＦ72と、ＰＣＥＦ73とを備え、かつ、ＡＦ71は、主に、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）に送信するように構成された、第２申込リクエスト送信ユニット711と、
シグナリングＩＰフローのベアライベント報告を、ポリシー制御及びチャージングルール機能（Policy Control and Charging Rules Function）から受信するように構成された、第２ベアライベント報告受信ユニット712と
を備え、
前記申込リクエストは、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を運び（本実施例は、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を用いた実例として説明されるが、これに限定されない）、
前記ベアライベント報告は、シグナリングＩＰフローのフロー識別子情報を運ぶ。
【０１０７】
ＰＣＲＦ72は、主に、
シグナリングＩＰフローのベアライベントを申し込むためのリクエストを、アプリケーション機能（Application Function）から受信するように構成された、第２申込リクエスト受信ユニット721と、
シグナリングＩＰフローの５組に従って、シグナリングＩＰフローに対応するポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を確立し、かつ、ポリシー制御及びチャージング（Policy Control and Charging）ルール、及び、ポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）（選択的に）に送信するように構成された、第２ルール確立ユニット722と、
検出されたベアライベント、及び、検出されたベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名を、ポリシー及びチャージングエンフォースメント機能（Policy and Charging Enforcement Function）（選択的に）から受信するように構成された、第２ベアライベント受信ユニット723と、
シグナリングＩＰフローのフロー識別子情報を運ぶベアライベント報告を生成及び送信するように構成された、第２ベアラ報告処理ユニット724と
を備え、
前記申込リクエストは、シグナリングＩＰフローの５組、及び、シグナリングＩＰフローのフロー識別子情報を運び、
前記識別子情報は、ベアライベントに関連付けられたポリシー制御及びチャージング（Policy Control and Charging）ルール名に対応するシグナリングＩＰフローのフロー識別子情報であってもよい。
【０１０８】
シグナリングＩＰフローパス状態を報告する方法が、本発明のさらに他の実施例によって提供される。方法では、第１デフォルトＰＤＰコンテキストをＩＰ−ＣＡＮ（IP Connectivity Access Network）セッションから起動するリクエストに対して、ＰＣＣルールがデフォルトＰＤＰコンテキストに先立って起動又はインストールされ、ＩＰ−ＣＡＮセッションがシグナリングＩＰフローに対して専用のＰＤＰコンテキストを確立するステップを再度リクエストした場合、デフォルトＰＤＰコンテキストに対する以前のＰＣＣルールは動作を停止されるか又は削除され、かつ、ＰＣＣルールはシグナリングＩＰフローのＰＤＰコンテキストに対して起動又はインストールされ、したがって、ＩＰシグナリングパス状態報告は、ＰＣＣルール（シグナリングＩＰフローのＰＤＰコンテキストに対して新規に起動又はインストールされた）のルール名に従ってトリガされ、そうでなければ、デフォルトＰＤＰコンテキストがシグナリングＩＰフローを運ぶのに使用された場合、ＩＰシグナリングパス状態報告は、デフォルトＰＤＰコンテキストに先立って起動又はインストールされたＰＣＣルールのルール名に従ってトリガしてもよい。
【０１０９】
ＰＣＣルール（デフォルトＰＤＰコンテキストに先立って起動又はインストールされた）、及び、ＰＣＣルール（シグナリングＩＰフローのＰＤＰコンテキストに対して新規に起動又はインストールされた）は、次の方法で生成してもよい。
【０１１０】
１．事前定義方法
【０１１１】
事前に定義されたＰＣＣルールは、シグナリングＩＰフローに対してＰＣＥＦに配置される。デフォルトＰＤＰコンテキストを起動するリクエストか、又は、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストの各受信によって、ＰＣＲＦは、ＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する。この方法では、事前に定義されたＰＣＣルール及びその名前は固定され、かつ、ＩＰシグナリングを処理するためのＡＦのアドレス（事前に定義されたＰＣＣルールに含まれている）も固定される。ＩＰシグナリングを処理するためのＡＦのアドレスが変更された場合、事前に定義されたＰＣＣルールは、ＰＣＥＦ及びＰＣＲＦに同期して、再生成及び更新される。
【０１１２】
２．動的生成方法
【０１１３】
ＰＣＲＦは、ＩＰシグナリングを処理するためのＡＦのアドレスを用いて事前設定される。デフォルトＰＤＰコンテキストを起動するリクエストか、又は、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストの各受信によって、ＰＣＲＦは、シグナリングＰＣＣルール（ＩＰシグナリングを処理するためのＡＦの事前設定されたアドレスを含む）を生成し、かつ、シグナリングＰＣＣルールを、インストールするため、ＰＣＥＦに送信する。
【０１１４】
上記した２つの方法は組み合わせて、又は、別々に使用してもよく、かつ、それについての詳細な説明は図面を参照した実施例で以下に示される。
【０１１５】
図８には、第１の事前定義方法（ＰＣＣルールが事前に定義される）において、シグナリングＩＰフローパス状態を報告するメカニズムが示されており、ＰＣＥＦは事前に定義されたＰＣＣルールを用いて構成され、かつ、ＰＣＲＦは事前に定義されたＰＣＣルールの名前を用いて構成され、かつ、メカニズムの特定のフローは以下を含んでいる。
【０１１６】
ステップＳ801〜ｓ805は、デフォルトＰＤＰコンテキストを起動し、かつ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する手順を図示しており、特に次のように説明される。
【０１１７】
ステップＳ801：
ＰＣＥＦは、デフォルトＰＤＰコンテキストを起動するリクエストを、ＵＥから受信する。
【０１１８】
ステップＳ802：
ＰＣＥＦは、ＰＣＲＦに、デフォルトＰＤＰコンテキストの識別子情報を含むＣＣＲメッセージを送信する。
【０１１９】
ステップＳ803：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動させ、ＣＣＡメッセージは、デフォルトＰＤＰコンテキストの識別子情報、及び、事前に定義されたＰＣＣルール名を含んでいる。
【０１２０】
ステップＳ804：
ＰＣＥＦは、ＣＣＡメッセージを受信し、かつ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動する。
【０１２１】
ステップＳ805：
ＰＣＥＦは、デフォルトＰＤＰコンテキスト起動応答を、前記ＵＥに返す。
【０１２２】
以降、ユーザは、シグナリングＩＰフローの専用ＰＤＰコンテキストを起動するリクエストを開始してもよい。ステップＳ806〜Ｓ810は、シグナリングＩＰフローのＰＤＰコンテキストを確立するステップ、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止するステップ、及び、シグナリングＩＰフローのＰＤＰルールに対して事前に定義されたＰＣＣルールを起動するステップの手順を示しており、特に次のように説明される。
【０１２３】
ステップＳ806：
ＰＣＥＦは、ＰＤＰコンテキストを起動するためのリクエストをＵＥから受信し、前記リクエストはシグナリングタグを運ぶ。
【０１２４】
ステップＳ807：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（ベアラ使用（Bearer Usage）のパラメータ、及び、シグナリングＩＰフローのＰＤＰコンテキストの識別子を含む）を送信し、ベアラ使用（Bearer Usage）の前記パラメータはシグナリングタグ情報を含んでいる。
【０１２５】
ステップＳ808：
ＰＣＲＦは、確立されるＰＤＰコンテキストが、ベアラ使用（Bearer Usage）のパラメータにおけるシグナリングタグ情報に従って、シグナリングを運ぶのに使用されることを理解し、かつ、ＣＣＡメッセージを介して、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたＰＣＣルールを起動させ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及び事前に定義されたＰＣＣルール名のＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及び事前に定義されたＰＣＣルール名の識別子とを含んでいる。
【０１２６】
ステップＳ809：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰルールに対して事前に定義されたＰＣＣルールの動きを停止し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたルールを起動する。
【０１２７】
ステップＳ810：
ＰＣＥＦは、シグナリングＩＰフローＰＤＰコンテキスト起動応答を、ＥＵに返す。
【０１２８】
ステップＳ811〜Ｓ816は、シグナリングＩＰフローパス状態報告を申し込むステップ、及び、シグナリングＩＰフローパス状態を報告するステップの手順を示しており、特に次のように説明される。
【０１２９】
ステップＳ811：
ＡＦはＵＥからのＳＩＰシグナリングを処理する。
【０１３０】
ステップＳ812：
ＡＦはＰＣＲＦからのシグナリングＩＰフローパス状態を申し込む。
【０１３１】
ステップＳ813：
ＰＣＲＦは、ＰＣＥＦからのＰＤＰコンテキストのベアラに関するイベントを申し込む。
【０１３２】
ステップＳ814：
事前に定義されたＰＣＣルールに対応するＰＤＰコンテキストのベアライベントが、ＰＣＥＦによって検出される。
【０１３３】
ステップＳ815：
ＰＣＥＦは、ＰＣＲＦに、ＰＤＰベアライベント検出報告（対応するベアライベント、及び、事前に定義されたＰＣＣルール名を運ぶ）を送信する。
【０１３４】
ステップＳ816：
ＰＣＲＦは、シグナリングＩＰフローシグナリングパス状態報告を、ＡＦに送信する。
【０１３５】
したがって、ＵＥがシグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングはデフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルール、及び、事前に定義されたルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始された場合、セッションシグナリングはシグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対して事前に定義されたＰＣＣルール、及び、事前に定義されたＰＣＣルール名によって実施される。
【０１３６】
図９には、第２方法において、シグナリングＰＣＣルール及びその名前を生成し、かつ、シグナリングＩＰフローパス状態を報告するメカニズムが示されており、メカニズムでは、ＰＣＲＦは、ＵＥに対するＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成され、かつ、メカニズムの特定のフローは以下を含んでいる。
【０１３７】
ステップＳ901〜Ｓ906は、デフォルトＰＤＰコンテキストを確立し、かつ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルール及びその名前をインストールする手順を示しており、かつ、次のように説明される。
【０１３８】
ステップＳ901：
ＰＣＥＦは、ＵＥから送信された、デフォルトＰＤＰコンテキストを起動するためのリクエストを受信する。
【０１３９】
ステップＳ902：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（デフォルトＰＤＰコンテキストの識別子情報を含む）を送信する。
【０１４０】
ステップＳ903：
ＰＣＲＦは、シグナリングＰＣＣルール（ＡＦのアドレスを含む）を生成する。
【０１４１】
ステップＳ904：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールさせ、ＣＣＡメッセージは、デフォルトＰＤＰコンテキストの識別子情報、及び、シグナリングＰＣＣルールを含んでいる。
【０１４２】
ステップＳ905：
ＰＣＥＦは、ＣＣＡメッセージを受信し、かつ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールする。
【０１４３】
ステップＳ906：
ＰＣＥＦは、デフォルトＰＤＰコンテキスト起動応答を、ＵＥに返す。
【０１４４】
以降、ユーザは、シグナリングＩＰフローの専用ＰＤＰコンテキストを起動するリクエストを開始してもよい。ステップＳ907〜Ｓ912は、シグナリングＩＰフローのＰＤＰコンテキストを起動するステップ、デフォルトＰＤＰコンテキストに対してシグナリングＰＣＣルールを削除するステップ、及び、シグナリングＩＰフローのＰＤＰコンテキストに対してシグナリングＰＣＣルールをインストールするステップの手順を示しており、特に次のように説明される。
【０１４５】
ステップＳ907：
ＰＣＥＦは、ＰＤＰコンテキストを起動するためのリクエストを、ＵＥから受信し、前記リクエストはシグナリングタグを運ぶ。
【０１４６】
ステップＳ908：
ＰＣＥＦは、ＰＣＲＦに、ＣＣＲメッセージ（ベアラ使用（Bearer Usage）のパラメータ、及び、シグナリングＩＰフローのＰＤＰコンテキストの識別子を含む）を送信する。
【０１４７】
ステップＳ909：
ＰＣＲＦは、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータに従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成する。
【０１４８】
ステップＳ910：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルールを削除させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールさせ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及びシグナリングＰＣＣルールのＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及びシグナリングＰＣＣルールの識別子とを含んでいる。
【０１４９】
ステップＳ911：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルールを削除し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールする。
【０１５０】
ステップＳ912：
ＰＣＥＦは、シグナリングＩＰフローＰＤＰコンテキスト起動応答を、ＵＥに返す。
【０１５１】
ステップＳ913〜Ｓ918は、シグナリングＩＰフローパス状態報告を申し込み、かつ、シグナリングＩＰフローパス状態を報告する手順を示しており、ＰＣＥＦはシグナリングＰＣＣルールに対応するＰＤＰコンテキストのベアライベント検出報告を送信し、かつ、ＰＣＲＦは、報告で運ばれたシグナリングＰＣＣルール名に従ってシグナリングＩＰフローパス状態報告を送信する。
【０１５２】
したがって、ＵＥが、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングは、デフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対するシグナリングＰＣＣルール及びシグナリングＰＣＣルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルール及びシグナリングＰＣＣルール名によって実行される。
【０１５３】
ステップＳ908では、ＰＣＥＦからＰＣＲＦに送信されたＣＣＲメッセージが、ＰＤＰコンテキストのＴＦＴ（Traffic Flow Template）をさらに含み、ＰＣＲＦは、ＴＦＴにおけるアドレスと、ステップ909におけるＡＦのアドレスとを比較してもよく、かつ、ＴＦＴにおけるアドレスがＡＦのアドレスとマッチングした場合、ＰＣＲＦは、確立されるＰＤＰがシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成してもよい。換言すれば、ステップＳ909では、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータに従ってシグナリングを運ぶのに使用されることをＰＣＲＦが理解できない場合、ＰＣＲＦは、確立されるＰＤＰがＴＦＴに従ってシグナリングを運ぶのに使用されることをさらに理解してもよい。代わりに、ＰＣＲＦは、確立されるＰＤＰがＴＦＴに直接従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成してもよい。
【０１５４】
図10に示されたように、事前に定義されたＰＣＣルールは、デフォルトＰＤＰコンテキストにおいて起動され、かつ、生成されたシグナリングＰＣＣルールは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいてインストールされる。この実施例では、ＰＣＥＦは、事前に定義されたＰＣＣルール及びその名前を用いて構成され、かつ、ＰＣＲＦは、事前に定義されたＰＣＣルール名、及び、ＵＥに対してＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成される。
【０１５５】
ステップＳ1008：
ＰＣＲＦは、確立されるＰＤＰがベアラ使用（Bearer Usage）のパラメータ又はＴＦＴにおけるアドレス情報に従ってシグナリングを運ぶのに使用されることを理解し、かつ、ＡＦのアドレスを含むシグナリングＰＣＣルールを生成する。
【０１５６】
ステップＳ1009：
ＣＣＡメッセージを介して、ＰＣＲＦは、ＰＣＥＦに命令して、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止させ、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールさせ、前記ＣＣＡメッセージは、シグナリングＩＰフロー及びシグナリングＰＣＣルールのＰＤＰコンテキストの識別子と、デフォルトＰＤＰコンテキスト及び事前に定義されたＰＣＣルール名の識別子を含んでいる。
【０１５７】
ステップＳ1010：
ＰＣＥＦは、ＣＣＡメッセージを受信し、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルールの動作を停止し、かつ、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルールをインストールする。
【０１５８】
他のステップの説明は重ねて行われない。したがって、ＵＥが、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングは、デフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストに対して事前に定義されたＰＣＣルール及び事前に定義されたＰＣＣルール名によって実施され、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストに対するシグナリングＰＣＣルール名及びその名前によって実施される。
【０１５９】
実際に、生成されたシグナリングＰＣＣルール及びその名前はデフォルトＰＤＰコンテキストにインストールされ、かつ、事前に定義されたＰＣＣルールは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて起動してもよく、かつ、この実施例では、ＰＣＥＦは、事前に定義されたＰＣＣルール及びその名前を用いて構成される必要があり、かつ、ＰＣＲＦは、事前に定義されたＰＣＣルール名、及び、ＵＥに対して、ＳＩＰシグナリングを処理するためのＡＦのアドレスを用いて構成される必要がある。この場合、ＵＥがシグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストを後に開始しない場合、セッションシグナリングはデフォルトＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、デフォルトＰＤＰコンテキストにインストールされたシグナリングＰＣＣルール及びその名前によって実施され、かつ、シグナリングＩＰフローのＰＤＰコンテキストを起動するリクエストが開始される場合、セッションシグナリングは、シグナリングＩＰフローの専用のＰＤＰコンテキストにおいて運ばれ、かつ、シグナリングＩＰフローパス状態を報告するメカニズムは、シグナリングＩＰフローのＰＤＰコンテキストにおいて起動された事前に定義されたＰＣＣルール及びその名前によって実施される。
【０１６０】
図11に示すように、ＰＣＲＦが本発明のさらに他の実施例によって設けられ、かつ、ＰＣＲＦは、
事前に定義されたＰＣＣルールとその名前とを格納するように構成された、第１記憶ユニット111と、
リクエストに応じて起動されるＰＤＰコンテキストに対して、前記事前に定義されたＰＣＣルールとその前記名前とを起動するように構成された、第１関連付けユニット112と、
ＰＣＥＦに命令して、前記ＰＤＰコンテキストに対して、前記事前に定義されたＰＣＣルールを起動させるように構成された、第１通知ユニット113と、
前記事前に定義されたＰＣＣルール名を運ぶＰＤＰベアライベント検出報告を受信し、かつ、シグナリングＩＰフローパス状態報告を、アプリケーション機能（Application Function）に送信するように構成された、第１報告ユニット114と
を備えている。
【０１６１】
図12に示すように、ＰＣＲＦが本発明の他の実施例によって設けられ、かつ、ＰＣＲＦは、
ＡＦの事前設定されたアドレスを格納するように構成された、第２記憶ユニット121と、
シグナリングＰＣＣルール（前記ＡＦの前記アドレスと、前記シグナリングＰＣＣルールの名前とを含む）を生成し、かつ、リクエストに応じて起動されるＰＤＰコンテキストに対して、前記シグナリングＰＣＣルールとその前記名前とを起動するように構成された、第２関連付けユニット122と、
ＰＣＥＦに命令して、前記ＰＤＰに対して、前記シグナリングＰＣＣルールをインストールさせるように構成された、第２通知ユニット213と、
シグナリングＰＣＣルール名を運ぶＰＤＰベアライベント検出報告を受信し、かつ、シグナリングＩＰフローパス状態報告を、前記ＡＦに送信するように構成された、第２報告ユニット124と
を備えている。
【０１６２】
本発明のさらに他の実施例によれば、図11及び図12において構築された構成を用いたＰＣＲＦが提供される。
【０１６３】
本発明の本質及び範囲から逸脱することなく、当業者によって、多様な変形例及びバリエーションが本発明に対してなされ得ることは明らかである。したがって、本発明は、添付の特許請求の範囲及びその均等物に含まれる全ての変形例及びバリーションを包含することを意図している。
【符号の説明】
【０１６４】
611 第１申込リクエスト送信ユニット
612 第１ベアライベント報告受信ユニット
621 第１申込リクエスト受信ユニット
622 第１ルール確立ユニット
623 第１ベアライベント受信ユニット
624 第１ベアラ報告処理ユニット
711 第２申込リクエスト送信ユニット
712 第２ベアライベント報告受信ユニット
721 第２申込リクエスト受信ユニット
722 第２ルール確立ユニット
723 第２ベアライベント受信ユニット
724 第２ベアラ報告処理ユニット
114 第1報告ユニット
111 第1記憶ユニット
112 第1関連付けユニット
113 第1通知ユニット
124 第２報告ユニット
121 第２記憶ユニット
122 第２関連付けユニット
123 第２通知ユニット
【特許請求の範囲】
【請求項１】
シグナリングＩＰフローのベアライベントを報告する方法であって、
アプリケーション機能によって、シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するステップと、
前記アプリケーション機能によって、前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能から受信するステップと、
を具備し、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶことを特徴とする方法。
【請求項２】
前記ポリシー制御及びチャージングルール機能によって、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するステップと、
前記ポリシー制御及びチャージングルール機能によって申込された前記ベアライベントを検出すると、前記ポリシー及びチャージングエンフォースメント機能によって、前記ベアライベント及び前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー制御及びチャージングルール機能に報告するステップと、
前記ポリシー制御及びチャージングルール機能によって、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名に対応する前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を含む情報を運ぶ、前記ベアライベント報告を生成及び送信するステップと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記申込リクエストを受信すると、前記ポリシー制御及びチャージングルール機能によって、前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定した後、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応する前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立するステップと
をさらに具備することを特徴とする請求項２に記載の方法。
【請求項４】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに利用可能な前記ポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在することを前記ポリシー制御及びチャージングルール機能が決定した場合、前記ポリシー制御及びチャージングルール機能によって、前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するステップと、
前記ポリシー制御及びチャージングルール機能によって申し込みされた前記ベアライベントを検出すると、前記ポリシー及びチャージングエンフォースメント機能によって、前記ベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー制御及びチャージングルール機能に報告するステップと、
前記ポリシー制御及びチャージングルール機能によって、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名に対応する前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を含む情報を運ぶ、前記ベアライベント報告を生成及び送信するステップと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項５】
アプリケーション機能であって、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するように構成された、第１申込リクエスト送信ユニットと、
前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能から受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶことを特徴とするアプリケーション機能。
【請求項６】
ポリシー制御及びチャージングルール機能であって、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、アプリケーション機能から受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージングルール名を含む情報を運ぶベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えることを特徴とするポリシー制御及びチャージングルール機能。
【請求項７】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するように構成された、第１ルール確立ユニットと、
前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えることを特徴とする請求項６に記載のポリシー制御及びチャージングルール機能。
【請求項８】
前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在すると決定すると、
前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応するポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名を確立させ、
前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能に送信させるように構成された、決定ユニット
をさらに備えることを特徴とする請求項６又は７に記載のポリシー制御及びチャージングルール機能。
【請求項９】
シグナリングＩＰフローのベアライベントを報告するシステムであって、
アプリケーション機能と、
ポリシー制御及びチャージングルール機能と
を備え、
前記アプリケーション機能は、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するように構成された、第１申込リクエスト送信ユニットと、
前記ポリシー制御及びチャージングルール機能によって送信された前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運び、かつ、
前記ポリシー制御及びチャージングルール機能は、
前記第１申込リクエスト送信ユニットから、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記申込リクエストを受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージングルール名を含む情報を運ぶ前記ベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えることを特徴とするシグナリングＩＰフローのベアライベントを報告するシステム。
【請求項１０】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するように構成された、第１ルール確立ユニットと、
前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えることを特徴とする請求項９に記載のシグナリングＩＰフローのベアライベントを報告するシステム。
【請求項１１】
前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在すると決定すると、
前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応する前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立させ、
前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能に送信させるように構成された、決定ユニット
をさらに備えることを特徴とする請求項９又は１０に記載のシグナリングＩＰフローのベアライベントを報告するシステム。
【請求項１】
シグナリングＩＰフローのベアライベントを報告する方法であって、
アプリケーション機能によって、シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するステップと、
前記アプリケーション機能によって、前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能から受信するステップと、
を具備し、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶことを特徴とする方法。
【請求項２】
前記ポリシー制御及びチャージングルール機能によって、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するステップと、
前記ポリシー制御及びチャージングルール機能によって申込された前記ベアライベントを検出すると、前記ポリシー及びチャージングエンフォースメント機能によって、前記ベアライベント及び前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー制御及びチャージングルール機能に報告するステップと、
前記ポリシー制御及びチャージングルール機能によって、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名に対応する前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を含む情報を運ぶ、前記ベアライベント報告を生成及び送信するステップと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記申込リクエストを受信すると、前記ポリシー制御及びチャージングルール機能によって、前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定した後、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応する前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立するステップと
をさらに具備することを特徴とする請求項２に記載の方法。
【請求項４】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに利用可能な前記ポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在することを前記ポリシー制御及びチャージングルール機能が決定した場合、前記ポリシー制御及びチャージングルール機能によって、前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するステップと、
前記ポリシー制御及びチャージングルール機能によって申し込みされた前記ベアライベントを検出すると、前記ポリシー及びチャージングエンフォースメント機能によって、前記ベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー制御及びチャージングルール機能に報告するステップと、
前記ポリシー制御及びチャージングルール機能によって、前記ベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名に対応する前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を含む情報を運ぶ、前記ベアライベント報告を生成及び送信するステップと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項５】
アプリケーション機能であって、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するように構成された、第１申込リクエスト送信ユニットと、
前記シグナリングＩＰフローのベアライベント報告を、前記ポリシー制御及びチャージングルール機能から受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運ぶことを特徴とするアプリケーション機能。
【請求項６】
ポリシー制御及びチャージングルール機能であって、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、アプリケーション機能から受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージングルール名を含む情報を運ぶベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えることを特徴とするポリシー制御及びチャージングルール機能。
【請求項７】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するように構成された、第１ルール確立ユニットと、
前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えることを特徴とする請求項６に記載のポリシー制御及びチャージングルール機能。
【請求項８】
前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在すると決定すると、
前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応するポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名を確立させ、
前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能に送信させるように構成された、決定ユニット
をさらに備えることを特徴とする請求項６又は７に記載のポリシー制御及びチャージングルール機能。
【請求項９】
シグナリングＩＰフローのベアライベントを報告するシステムであって、
アプリケーション機能と、
ポリシー制御及びチャージングルール機能と
を備え、
前記アプリケーション機能は、
シグナリングＩＰフローのベアライベントを申し込むための申込リクエストを、ポリシー制御及びチャージングルール機能に送信するように構成された、第１申込リクエスト送信ユニットと、
前記ポリシー制御及びチャージングルール機能によって送信された前記シグナリングＩＰフローのベアライベント報告を受信するように構成された、第１ベアライベント報告受信ユニットと
を備え、
前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運び、かつ、
前記ベアライベント報告は、前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報を運び、かつ、
前記ポリシー制御及びチャージングルール機能は、
前記第１申込リクエスト送信ユニットから、前記シグナリングＩＰフローの前記ベアライベントを申し込むための前記申込リクエストを受信するように構成され、前記申込リクエストは、前記シグナリングＩＰフローの５組、及び／又は、フロー識別子情報を運ぶ、第１申込リクエスト受信ユニットと、
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に対応する前記ベアライベントに関連付けられたポリシー制御及びチャージングルール名を含む情報を運ぶ前記ベアライベント報告を生成及び送信するように構成された、第１ベアラ報告処理ユニットと
を備えることを特徴とするシグナリングＩＰフローのベアライベントを報告するシステム。
【請求項１０】
前記シグナリングＩＰフローの前記５組、及び／又は、前記フロー識別子情報に従って、前記シグナリングＩＰフローに対応するポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立し、かつ、
前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を、ポリシー及びチャージングエンフォースメント機能に送信するように構成された、第１ルール確立ユニットと、
前記検出されたベアライベント、及び、前記検出されたベアライベントに関連付けられた前記ポリシー制御及びチャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能から受信するように構成された、第１ベアライベント受信ユニットと
をさらに備えることを特徴とする請求項９に記載のシグナリングＩＰフローのベアライベントを報告するシステム。
【請求項１１】
前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、又は、ポリシー制御及びチャージングルール名が存在しないと決定すると、あるいは、前記申込リクエストで運ばれた前記シグナリングＩＰフローに利用可能なポリシー制御及びチャージングルール、及び、ポリシー制御及びチャージングルール名が存在すると決定すると、
前記第１ルール確立ユニットに命令して、前記ＩＰフローに対応する前記ポリシー制御及びチャージングルール、及び、前記ポリシー制御及びチャージングルール名を確立させ、
前記チャージングルール及び前記チャージングルール名を、前記ポリシー及びチャージングエンフォースメント機能に送信させるように構成された、決定ユニット
をさらに備えることを特徴とする請求項９又は１０に記載のシグナリングＩＰフローのベアライベントを報告するシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１０−５２１９０４（Ｐ２０１０−５２１９０４Ａ）
【公表日】平成２２年６月２４日（２０１０．６．２４）
【国際特許分類】
【出願番号】特願２００９−５５３８９４（Ｐ２００９−５５３８９４）
【出願日】平成２０年２月２２日（２００８．２．２２）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７０３４４
【国際公開番号】ＷＯ２００８／１１６４０６
【国際公開日】平成２０年１０月２日（２００８．１０．２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
【公表日】平成２２年６月２４日（２０１０．６．２４）
【国際特許分類】
【出願日】平成２０年２月２２日（２００８．２．２２）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７０３４４
【国際公開番号】ＷＯ２００８／１１６４０６
【国際公開日】平成２０年１０月２日（２００８．１０．２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
[ Back to top ]