(57)【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステムからセッション及びイベントの少なくとも一方に関連する情報を収集するための課金トリガー機能として動作するように構成されている装置を制御する方法であって、
前記装置が、一致するストリングを識別するための１つ以上のストリングフィルタであって、加入者に関連する前記課金トリガー機能を通過するメッセージに適用される１つ以上のストリングフィルタで前記課金トリガー機能を構成設定するステップと、
前記装置が、前記課金トリガー機能を通過する、前記加入者に関連するメッセージが１つ以上の一致するストリングを含んでいるかを判定するステップと、
前記装置が、メッセージが１つ以上の一致するストリングを含んでいる場合、一致するストリングそれぞれに関連付けられているデータを含むレポートメッセージを課金制御エンティティへ送信するステップとを有し、
前記装置が、前記１つ以上のストリングフィルタで前記課金トリガー機能を構成設定するステップは、
前記ＩＰマルチメディアサブシステムに前記加入者を登録中に、ホーム加入者サーバから加入者プロファイルとして、前記加入者に関連する前記課金トリガー機能を通過するメッセージに適用される前記１つ以上のストリングフィルタを定義する加入者プロファイルを受信するステップを有する
ことを特徴とする方法。
【請求項２】
前記１つ以上のストリングフィルタのそれぞれは、一致するストリングを識別するための第１の正規表現を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記１つ以上のストリングフィルタは、更に、前記一致するストリングに関連付けられるデータとして含まれる特有の値、あるいは特有の範囲の値を識別するための第２の正規表現を含んでいる
ことを特徴とする請求項２に記載の方法。
【請求項４】
ストリングフィルタが第１の正規表現と第２の正規表現を含んでいる場合、前記装置が、前記課金トリガー機能を通過する、前記加入者に関連するメッセージが１つ以上の一致するストリングを含んでいるかを判定するステップは、
前記課金トリガー機能を通過するメッセージが前記第１の正規表現と一致する１つ以上のストリングを含んでいるかを判定するステップと
１つ以上のストリングを含んでいる場合、前記一致するストリングのそれぞれが、前記第２の正規表現に一致するデータに関連付けられているかを判定するステップと
を有することを特徴とする請求項３に記載の方法。
【請求項５】
前記１つ以上のストリングフィルタのそれぞれは、更に、前記第１の正規表現が適用されるべきメッセージのタイプの指示を含んでいる
ことを特徴とする請求項２乃至４のいずれか１項に記載の方法。
【請求項６】
前記レポートメッセージは、更に、前記一致するストリングに関連付けられているデータとともに、一致するストリングそれぞれを含んでいる
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記レポートメッセージは、更に、前記一致するストリングが識別されている場合のメッセージのタイプの指示を含んでいる
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記レポートメッセージは、前記１つ以上の一致するストリングに関連付けられているデータがグループ化Ｄｉａｍｅｔｅｒ属性値ペアに含まれている、Ｄｉａｍｅｔｅｒメッセージを有する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記一致するストリングそれぞれに関連付けられているデータは、グループ化属性値ペア内の属性値ペア内に含まれている
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記１つ以上のストリングフィルタのそれぞれは、
セッション開始プロトコルメッセージ、
Ｄｉａｍｅｔｅｒメッセージ、及び
ＩＳＤＮユーザパートメッセージ
の内の１つに関連している
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
セッション開始プロトコルメッセージに関連するストリングフィルタは、ヘッダ名を有する
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記課金トリガー機能を通過するセッション開始プロトコルメッセージが、１つ以上の一致するストリングを含むものとして識別される場合、前記一致するストリングそれぞれに関連付けられているデータは、一致するヘッダ内に含まれる値を有する
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
Ｄｉａｍｅｔｅｒメッセージに関連するストリングフィルタは、
属性値ペアの属性値ペアコード及びベンダＩＤ、あるいは
属性値ペアの属性名
を含んでいる
ことを特徴とする請求項１０に記載の方法。
【請求項１４】
前記課金トリガー機能を通過するＤｉａｍｅｔｅｒメッセージが１つ以上の一致するストリングを含むものとして識別される場合、前記一致するストリングに関連付けられているデータは、一致する属性値ペア内に含まれる値を有する
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記課金制御エンティティは、
オンライン課金システム、あるいは
課金データ機能
である
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記課金トリガー機能は、
ブレークアウトゲートウェイ制御機能、
メディアゲートウェイ制御機能、
マルチメディアリソース機能コントローラ、
アプリケーションサーバ、及び
呼セッション制御機能
の内の１つ以上に提供される
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
ＩＰマルチメディアサブシステム内のホーム加入者サーバとして動作するように構成されている装置を制御する方法であって、
前記装置が、前記ＩＰマルチメディアサブシステムに加入者を登録中に、前記加入者に関連するプロファイルとして、前記加入者に関連する課金トリガー機能を通過するメッセージに適用される１つ以上のストリングフィルタを定義する加入者プロファイルを、前記課金トリガー機能へ送信するステップを有する
ことを特徴とする方法。
【請求項１８】
課金トリガー機能として動作するように構成されている装置であって、
ホーム加入者サーバから、加入者に関連するメッセージに適用される１つ以上のストリングフィルタを含む加入者プロファイルを受信するための受信機と、
一致するストリングを識別するための１つ以上のストリングフィルタを記憶するためのメモリと、
前記課金トリガー機能を通過する、前記加入者に関連するメッセージが１つ以上の一致するストリングを含んでいるかを判定するためのマッチングユニットと、
一致するストリングそれぞれに関連付けられているデータを有するレポートメッセージを生成するためのメッセージ生成ユニットと、
前記レポートメッセージを課金制御エンティティへ送信するための送信機と
を備えることを特徴とする装置。
【請求項１９】
ホーム加入者サーバとして動作するように構成されている装置であって、
加入者に関連するメッセージに適用される１つ以上のストリングフィルタを含む加入者プロファイルを記憶するためのメモリと、
加入者プロファイルに対するリクエストを受信するための受信機と、
前記１つ以上のストリングフィルタを含む前記加入者プロファイルを課金トリガー機能へ送信するための送信機と
を備えることを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおいて使用するための方法及び装置に関するものである。より詳しくは、本発明は、セッション情報とイベント関連情報を収集するために、ＩＰマルチメディアサブシステムを制御する方法に関するものである。
【背景技術】
【０００２】
ＩＰマルチメディアサービスは、同一セッション内で、音声、ビデオ、メッセージング、データ等の動的な組み合わせを提供する。基本アプリケーションと、それを組み合わせることができるメディアの数の増加によって、エンドユーザに提供されるサービスの数も増加し、個人間の通信経験も充実しつつある。これは、新世代のパーソナライズされた、豊かなマルチメディア通信サービスをもたらすことになり、これには、いわゆる「複合ＩＰマルチメディアサービス」が含まれる。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ）は、伝統的なテレフォニーに加えて、新規のＩＰマルチメディアサービス群（３ＧＰＰ  ＴＳ２２．２２８、ＴＳ２３．２２８、ＴＳ２４．２２９、ＴＳ２９．２２８、ＴＳ２９．２２９、ＴＳ２９．３２８及びＴＳ２９．３２９）をサポートするためのアクセス独立アーキテクチャフレームワークである。ＩＭＳは、標準化されたＩＭＳサービスイネーブラの使用を通じてエンドユーザの個人間通信の経験を豊かにするという主要な特徴を提供する。このＩＭＳサービスイネーブラは、新規の豊かな個人間（クライアント間）通信サービスを容易にすることに加えて、ＩＰベースのネットワークを介する個人とコンテンツ間（クライアントとサーバ間）サービスを容易にする。ＩＭＳは、ＰＳＴＮ／ＩＳＤＮ（公衆回線電話ネットワーク／統合サービデジタルネットワーク）とインターネットとの両方に接続することができる。
【０００４】
ＩＭＳは、セッション開始プロトコル（ＳＩＰ）を使用して、ユーザ端末間（あるいは端末とアプリケーションサーバ間）の呼あるいはセッションをセットアップし、制御する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）は、セッションのメディアコンポーネントを記述しネゴシエートするために使用される。ＳＩＰがユーザ間プロトコルとして作成されているのに対して、ＩＭＳは、オペレータとサービスプロバイダに、サービスへのユーザアクセスを制御し、また、それに応じてユーザに対して課金を行うことを可能にする。３ＧＰＰは、ユーザ装置（ＵＥ）とＩＭＳ間のシグナリングに加えて、ＩＭＳ内のコンポーネント間のシグナリングに対してＳＩＰを選択している。
【０００５】
例としては、図１は、どのようにしてＩＭＳが、ＧＰＲＳ／ＰＳアクセスネットワークの場合の移動ネットワークアーキテクチャに適合するかを示している（ＩＭＳは、もちろん、他のアクセスネットワークを介して動作することができる）。呼／セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内のＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、３つのタイプのＣＳＣＦを定義する。これらの内、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）はＳＩＰ端末に対するＩＭＳ内での第１の接続点である。サービング（在圏）ＣＳＣＦ（Ｓ−ＣＳＣＦ）はユーザが加入しているサービスをユーザへ提供する。インターロゲイティング（尋問）ＣＳＣＦ（Ｉ−ＣＳＣＦ）は、その役割は、正しいＳ−ＣＳＣＦを識別して、Ｐ−ＣＳＣＦを介してＳＩＰ端末から受信されるリクエストをＳ−ＣＳＣＦへ転送することである。
【０００６】
ＩＭＳサービスネットワーク内では、アプリケーションサーバ（ＡＳ）が、ＩＭＳサービス機能を実現するために提供される。アプリケーションサーバは、ＩＭＳシステム内のエンドユーザへサービスを提供し、また、３ＧＰＰで定義されるＭｒインタフェースを介するエンドポイントとして接続されていても良いし、あるいは３ＧＰＰで定義されるＩＳＣインタフェースを介するＳ−ＣＳＣＦによって「リンクされて」いても良い。後者の場合、初期フィルタ基準（ＩＦＣ）がＳ−ＣＳＣＦによって使用され、ＳＩＰセッション確立中（あるいは、実際には、任意のＳＩＰメソッド、セッションあるいは関連する非セッションのために）にどのアプリケーションサーバが「リンクされる」べきであるかを判定する。ＩＦＣは、ユーザの加入者プロファイルの一部として、ＩＭＳ登録手順中にホーム加入者サーバ（ＨＳＳ）からＳ−ＣＳＣＦによって受信される。
【０００７】
ホーム加入者サーバ（ＨＳＳ）は、加入者とサービス関連データを記憶するための、ＩＭＳ内のメインデータベースである。このサービス関連データには、ユーザアイデンティティ、登録情報、アクセスパラメータ、及びサービスをトリガーするために使用されるＩＦＣがある。ユーザアイデンティティは、ＩＰマルチメディアパブリックアイデンティティ（ＩＭＰＵ）とＩＰマルチメディアプライベートアイデンティティ（ＩＭＰＩ）からなる。ＩＭＰＵは、他のユーザがユーザと連絡をとるために使用することができるアイデンティティ（識別情報）であり、一方、ＩＭＰＩは、ユーザのネットワークオペレータによって割り当てられるユーザアイデンティティであり、かつ、ＩＭＳ内の登録及び認可のために使用される。マルチメディアセッションに参加するために、ユーザは、少なくとも１つのＩＭＰＵをネットワークに登録しなければならず、また、ＩＭＰＩは、アプリケーションレベルでＩＭＳ内で認証されなければならない。プライベートユーザアイデンティティとパブリックユーザアイデンティティとは、ユーザの端末のＵＭＴＳ集積回路カード（ＵＩＣ）上のＩＭＳサービスアイデンティティモジュール（ＩＳＩＭ）アプリケーションに記憶され、また、特定のＩＭＰＵは、異なるＩＭＰＩと異なる連絡アドレスを使用する複数のＵＥから同時に登録されても良い。ＨＳＳは、また、パケット交換ドメインエンティティと回線交換ドメインエンティティに対するサポートを提供するための、ホームロケーションレジスタと認証局（ＨＬＲ／ＡＵＣ）の機能を含んでいる。このパケット交換ドメインエンティティには、例えば、サービング（在圏）ＧＰＲＳサポートノード（ＳＧＳＮ）と、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）があり、また、回線交換ドメインエンティティには、例えば、移動交換局（ＭＳＣ）がある。
【０００８】
３ＧＰＰ  ＴＳ  ３２．２６０は、ＩＰマルチメディアサブシステムに対するオフライン課金及びオンライン課金の記述を定義している。オフライン課金及びオンライン課金のどちらに対しても、ネットワークリソース使用に対する課金情報は、リソース使用と同時に収集される。オフライン課金では、この課金情報は、提供されるサービスにリアルタイムには反映されない。しかしながら、オンライン課金では、ネットワークリソース使用に対する認可は、実際のリソース使用前に、ネットワークによって取得されなければならない。
【０００９】
図２は、ＩＭＳオフライン課金アーキテクチャを示している。このアーキテクチャでは、課金トリガー機能（ＣＴＦ）は、ネットワークリソース使用の観測に基づいて課金イベントを生成する。ＳＩＰシグナリングを取り扱うすべてのＩＭＳエンティティは、ＣＴＦ機能で提供することができる。ＣＴＦは、ネットワーク要素内の課金可能イベントに関わる情報を収集し、その情報を合致する課金イベントへアセンブリして、そして、これらの課金イベントを課金データ機能（ＣＤＦ）へ送信するためのフォーカルポイントである。課金データ機能（ＣＤＦ）は、ＲＦリファレンスポイントを介してＣＴＦから課金イベントを受信する。次に、これは、課金イベントに含まれる情報を使用して、課金データレコード（ＣＤＲ）を構築する。ＣＤＦによって生成されるＣＤＲは、Ｇａリファレンスポイントを介して課金ゲートウェイ機能（ＣＧＦ）へ送信される。ＣＧＦは、３ＧＰＰネットワークと請求ドメイン（ＢＤ）との間のゲートウェイとして動作し、また、ＢＤへＣＤＲファイルを転送するためのＢｘリファレンスポイントとして使用する。ＢＤは、典型的には、オペレータの請求システムあるいは請求仲介デバイスのような後処理システムを備える。
【００１０】
図３は、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示していて、これには、３ＧＰＰ  ＴＳ３２．２６０で定義されるオフライン課金機能とＣＴＦとの通信を含んでいる。実行されるステップは以下のようになる。
【００１１】
Ａ１．ＵＥは、ＳＩＰ  ＩＮＶＩＴＥメッセージを送信することによってセッション確立を開始する。ＳＩＰ  ＩＮＶＩＴＥメッセージは、途中のＣＳＣＦ（例えば、Ｉ−ＣＳＣＦ、Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ）を通じて、自身の宛先へ渡る。
【００１２】
Ａ２．ＩＮＶＩＴＥメッセージの受信側は回答を行い、最終２００  ＯＫ応答がＵＥへ返信される。この応答も、ＣＳＣＦを経由する。
【００１３】
Ａ３．２００  ＯＫ応答の受信に応じて、少なくとも１つのＣＳＣＦによって提供されるＣＴＦは、ＣＤＦに向けて、ＳＴＡＲＴ（開始）を示すアカウンティング−レコード−タイプ  ＡＶＰを伴うアカウンティングリクエスト（ＡＣＲ）Ｄｉａｍｅｔｅｒメッセージを送信して、ユーザセッションの開始を記録する。
【００１４】
Ａ４．ＣＤＦは、アカウンティング回答（ＡＣＡ）メッセージを送信することによって、ＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を開始する。３ＧＰＰ  ＴＳ３２．２９９は、ＡＣＲメッセージとＡＣＡメッセージの内容を定義している。
【００１５】
Ａ５．ＵＥでの２００  ＯＫ  応答の受信に応じて、ＩＭＳセッションが確立される。
【００１６】
Ａ６．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッションの終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＣＳＣＦを通じて宛先へ渡る。
【００１７】
Ａ７．ＳＩＰ  ＢＹＥメッセージの受信に応じて、ＣＳＣＦの１つによって提供されるＣＴＦは、ＳＴＯＰ（停止）を示すアカウンティング−レコード−タイプＡＶＰを伴うＡＣＲメッセージをＣＤＦに向けて送信することで、ユーザのセッションの終了を記録する。
【００１８】
Ａ８．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を終了する。
【００１９】
図４は、ＩＭＳオンライン課金アーキテクチャを示している。このアーキテクチャでは、ネットワークリソース使用リクエストを受信すると、ＣＴＦは、関連課金情報（オフライン課金で採用される課金情報と必ずしも同一ではない）をアセンブルして、そして、Ｒｏリファレンスポイントを使用してリアルタイムでオンライン課金システム（ＯＣＳ）へ送信される課金イベントを生成する。次に、ＯＣＳは、加入者アカウント情報に基づいて適切なリソース使用認可を返信する。このリソース使用認可は、自身のスコープ（例えば、データ量あるいは持続時間）に制限されても良いので、加入者のネットワークリソース使用が存続する限り、時々更新されなければならない場合がある。オペレータによって要求される場合、ＣＤＲは追加的にオンライン課金される加入者に対して生成することができる。
【００２０】
図４に示されるように、ＡＳ、ＭＲＦＣあるいはＳ−ＣＳＣＦだけがオンライン課金をサポートする。しかしながら、Ｓ−ＣＳＣＦに関しては、Ｓ−ＣＳＣＦは任意のオンライン課金イベントをトリガーしない。それゆえ、特定のＣＴＦが、Ｓ−ＣＳＣＦによって実現されるＳＩＰベースのサービス制御と、ＲｏベースのＳＢＣＦとの間を仲介するために必要とされる。この役割はＩＭＳゲートウェイ機能（ＩＭＳ−ＧＷＦ）によって行われ、Ｓ−ＣＳＣＦに向けてのＳＩＰサービス制御と、ＯＣＳ側のＲＯクレジット制御との間を変換する。オンライン課金アーキテクチャの観点からは、ＩＭＳ  ＧＷＦはオンライン課金が可能なＣＴＦであり、一方、Ｓ−ＣＳＣＦの観点からは、ＩＭＳ−ＧＷＦはＳＩＰアプリケーションサーバであり、同一の方法でトリガーされる。このようにして、Ｓ−ＣＳＣＦは、ＩＳＣインタフェース（即ち、ＩＳＣインタフェースを介して向けられているアプリケーションサーバがＩＭＳ−ＧＷＦである場合）あるいはＲｏインタフェース（ＩＭＳ−ＧＷＦがＳ−ＣＳＣＦに統合されている場合）を直接使用してオンライン課金をサポートする。
【００２１】
図５は、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示していて、これには、ユニット予約を伴うセッション課金（ＳＣＵＲ）に対する、３ＧＰＰ  ＴＳ３２．２６０で定義されるオフライン課金機能とＣＴＦとの通信を含んでいる。実行されるステップは以下のようになる。
【００２２】
Ｂ１．ＵＥは、ＳＩＰ  ＩＮＶＩＴＥメッセージを送信することによってセッション確立を開始する。ＳＩＰ  ＩＮＶＩＴＥメッセージは、途中のＣＳＣＦ（例えば、Ｉ−ＣＳＣＦ、Ｐ−ＣＳＣＦ及びＳ−ＣＳＣＦ）を通じて、自身の宛先へ渡る。
【００２３】
Ｂ２．ＳＩＰ  ＩＮＶＩＴＥメッセージの受信に応じて、Ｓ−ＣＳＣＦによって提供されるＣＴＦは、ＯＣＳに向けて、ＩＮＩＴＩＡＬ（初期）を示すＣＣ−Ｒｅｑｕｅｓｔ−Ｔｙｐｅ  ＡＶＰを伴うクレジット制御リクエスト（ＣＣＲ）Ｄｉａｍｅｔｅｒメッセージを送信する。これは、サービスユニットの予約をリクエストするものである。オンラインクレジット制御セッションが開始される。
【００２４】
Ｂ３．ＯＣＳは、サービスユニット判定、レイティング及びクレジット制御を実行し、また、許可されたサービスユニットを示すクレジット−制御−回答メッセージでＣＣＲに応答する。
【００２５】
Ｂ４．Ｓ−ＣＳＣＦは、ＩＮＶＩＴＥを自身の宛先へ転送する。
【００２６】
Ｂ５．ＩＮＶＩＴＥメッセージの受信先は回答を行い、最終２００  ＯＫ応答がＵＥへ返信される。この応答も、ＣＳＣＦを介して転送される。
【００２７】
Ｂ６．Ｓ−ＣＳＣＦ／ＣＴＦにおける２００  ＯＫ応答の受信は、ＯＣＳへ向けて、ＵＰＤＡＴＥ（更新）を示すＣＣ−Ｒｅｑｕｅｓｔ−Ｔｙｐｅ  ＡＶＰを伴うＣＣＲメッセージをトリガーする。これは、サービスユニットの更なる予約をリクエストし、かつ任意の使用されるサービスユニットをレポートする。
【００２８】
Ｂ７．ＯＣＳは、再度、サービスユニット判定、レイティング及びクレジット制御を実行し、現在許可されているサービスユニットを示すＣＣＡメッセージでＣＣＲに応答する。
【００２９】
Ｂ８．ＵＥでの２００  ＯＫ応答の受信に応じて、ＩＭＳセッションが確立される。  
【００３０】
Ｂ９．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッション終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＣＳＣＦを通じて、自身の宛先へ渡る。
【００３１】
Ｂ１０．ＳＩＰ  ＢＹＥメッセージの受信に応じて、Ｓ−ＣＳＣＦ／ＣＴＦは、ＯＣＳへ向けて、ＴＥＲＭＩＮＡＴＥ（終了）を示すＣＣ−Ｒｅｑｕｅｓｔ−Ｔｙｐｅ  ＡＶＰを伴うＣＣＲメッセージを送信する。これは、使用される許可されたユニットをレポートするものである。
【００３２】
Ｂ１１．ＯＣＳは、ユーザのアカウントから使用されるユニット分を引き落とし、ＣＣＡメッセージを伴うＣＣＲに応答する。オンラインクレジット制御セッションが終了される。
【００３３】
ＣＴＦは、ＣＴＦを通過する任意のメッセージが課金対象となるアクティビティの指示を含むかどうかを判定し、そうである場合、オンライ課金メカニズムあるいはオフライン課金メカニズムを適用するかどうかを判定することが要求される。課金対象となるアクティビティに関する情報が、Ｄｉａｍｅｔｅｒアカウンティングメッセージ（即ち、ＡＣＲ）の属性値ペアでＣＤＦへ送信され、また、Ｄｉａｍｅｔｅｒクレジット制御メッセージ（即ち、ＣＣＲ）の属性値ペアでＯＣＳへ送信される。次に、この情報は、ネットワークオペレータへ渡されるＣＤＲを生成するために、課金アーキテクチャによって使用される場合がある。これらのＣＤＲの主要な目的は、ネットワークオペレータに、ユーザのアカウンティング及びオペレータ間アカウンティングの少なくとも一方に対して課金する／請求することを可能にし、これらのＣＤＲは、オペレータの裁量で任意の追加の機能のためにも使用することができる。例えば、統計を生成するために、あるいはセキュリティあるいはトラフィックモニタリング目的のために、ＣＤＲを使用することができる。このようにして、ＣＴＦは任意の情報を課金アーキテクチャ（即ち、ＣＤＦ／ＯＣＳ）に提供するために要求される場合がある。ここで、この任意の情報とは、課金アーキテクチャを通過するメッセージから導出することができ、Ｄｉａｍｅｔｅｒメッセージ（即ち、ＡＣＲ、ＣＣＲ等）内に定義されているＡＶＰが存在していないことについての情報を含んでいる。
【発明の概要】
【発明が解決しようとする課題】
【００３４】
今までのところ、このような状況において、唯一のソリューションは、ＲｆインタフェースとＲｏインタフェース上に新規のＡＶＰを作成することであり、これは、課金アーキテクチャによって要求される情報の項目に対して特有のものである。これらのアプリケーションに対する新規のＤｉａｍｅｔｅｒ  ＡＶＰの作成は、第３世代パートナシッププロジェクト（３ＧＰＰ）によって制御され、それゆえ、ネットワークオペレータは、３ＧＰＰで合意されている新規に提案されるＡＶＰのそれぞれを有することが要求される。このように、これらの新規のＡＶＰの導入は直接的に必要とされるものではなく、また、達成するために膨大な時間期間がかかり得る。加えて、これらの特有のＡＶＰの導入は、ＣＴＦによって実行されるエンコーディング及びデコーディングに影響を与えるばかりか、Ｄｉａｍｅｔｅｒスタック上にも影響を与える。
【００３５】
本発明の目的は、上述の識別される課題を少なくとも解消するあるいは軽減することである。この目的は、１つ以上のストリングフィルタを使用して情報を識別し、その識別された情報を、ＣＤＦ／ＯＣＳへ送信するための一般情報ＡＶＰに含めるための、ＩＭＳ課金アーキテクチャを構成設定することによって達成される。
【課題を解決するための手段】
【００３６】
本発明の第１の態様に従えば、ＩＰマルチメディアサブシステムからセッション及びイベントの少なくとも一方に関連する情報を収集するための課金トリガー機能を制御する方法が提供される。この方法は、一致するストリングを識別するための１つ以上のストリングフィルタで前記課金トリガー機能を構成設定するステップと、前記課金トリガー機能を通過するメッセージが１つ以上の一致するストリングを含んでいるかを判定するステップと、メッセージが１つ以上の一致するストリングを含んでいる場合、一致するストリングそれぞれに関連付けられているデータを含むレポートメッセージを課金制御エンティティへ送信するステップとを有する。
【００３７】
任意の所望の情報を識別するために１つ以上のストリングフィルタでＣＴＦを構成設定し、そして、識別された情報を一般情報ＡＶＰに含めることは、ＣＴＦからＣＤＦ／ＯＣＳへ渡されることが好ましい、課金関連情報の新しい部分毎について、新規の特有のＡＶＰが作成される必要がないことを実現し、その結果、コストが削減される。また、これは、柔軟なソリューションを提供する。それは、任意のＳＩＰヘッダ／Ｄｉａｍｅｔｅｒ  ＡＶＰを、ＯＣＳ／ＣＤＲに出力される課金あるいはイベント関連情報として特定することができるからである。
【００３８】
前記１つ以上のストリングフィルタで前記課金トリガー機能を構成設定するステップは、ホーム加入者サーバから加入者プロファイルとして、加入者に関連する前記課金トリガー機能を通過するメッセージに適用される前記１つ以上のストリングフィルタを定義する加入者プロファイルを受信するステップを有していても良い。選択的には、前記１つ以上のストリングフィルタで前記課金トリガー機能を構成設定するステップは、前記課金トリガー機能を通過するメッセージのすべてに適用される１つ以上のストリングフィルタを前記課金トリガー機能において定義するステップを有していても良い。
【００３９】
前記１つ以上のストリングフィルタのそれぞれは、第１の正規表現を適用すべきメッセージのタイプの指示を含んでいても良い。前記１つ以上のストリングフィルタのそれぞれは、一致するストリングを識別するための第１の正規表現を含んでいても良い。加えて、前記１つ以上のストリングフィルタは、更に、前記一致するストリングに関連付けられるデータとして含まれる特有の値、あるいは特有の範囲の値を識別するための第２の正規表現を含んでいても良い。
【００４０】
ストリングフィルタが第１の正規表現と第２の正規表現を含んでいる場合、前記課金トリガー機能を通過するメッセージが１つ以上の一致するストリングを含んでいるかを判定するステップは、前記課金トリガー機能を通過するメッセージが前記第１の正規表現と一致する１つ以上のストリングを含んでいるかを判定するステップと、１つ以上のストリングを含んでいる場合、前記一致するストリングのそれぞれが、前記第２の正規表現に一致するデータに関連付けられているかを判定するステップとを有していても良い。
【００４１】
前記レポートメッセージは、更に、前記一致するストリングに関連付けられているデータとともに、一致するストリングそれぞれを含んでいても良い。前記レポートメッセージは、更に、前記一致するストリングが識別されている場合のメッセージのタイプの指示を含んでいても良い。前記レポートメッセージは、前記１つ以上の一致するストリングに関連付けられているデータがグループ化Ｄｉａｍｅｔｅｒ属性値ペアに含まれている、Ｄｉａｍｅｔｅｒメッセージを有していても良い。
【００４２】
前記一致するストリングそれぞれに関連付けられているデータは、グループ化属性値ペア内の属性値ペア内に含まれていても良い。
【００４３】
前記１つ以上のストリングフィルタのそれぞれは、セッション開始プロトコルメッセージ、Ｄｉａｍｅｔｅｒメッセージ、及びＩＳＤＮユーザパートメッセージの内の１つに関連していても良い。
【００４４】
セッション開始プロトコルメッセージに関連するストリングフィルタは、ヘッダ名を有していても良い。また、前記課金トリガー機能を通過するセッション開始プロトコルメッセージが、１つ以上の一致するストリングを含むものとして識別される場合、前記一致するストリングそれぞれに関連付けられているデータは、一致するヘッダ内に含まれる値を有していても良い。
【００４５】
Ｄｉａｍｅｔｅｒメッセージに関連するストリングフィルタは、属性値ペアの属性値ペアコード及びベンダＩＤ、及び属性値ペアの属性名の一方を含んでいても良い。また、前記課金トリガー機能を通過するＤｉａｍｅｔｅｒメッセージが１つ以上の一致するストリングを含むものとして識別される場合、前記一致するストリングに関連付けられているデータは、一致する属性値ペア内に含まれる値を有していても良い。
【００４６】
前記課金トリガー機能は、ブレークアウトゲートウェイ制御機能、メディアゲートウェイ制御機能、マルチメディアリソース機能コントローラ、アプリケーションサーバ、及び呼セッション制御機能の内の１つ以上に提供されても良い。前記課金制御エンティティは、オンライン課金システム、あるいは課金データ機能であっても良い。
【００４７】
本発明の第２の態様に従えば、ＩＰマルチメディアサブシステム内のホーム加入者サーバを制御する方法が提供される。この方法は、前記ＩＰマルチメディアサブシステムに加入者を登録中に、前記加入者に関連するプロファイルとして、前記加入者に関連する課金トリガー機能を通過するメッセージに適用される１つ以上のストリングフィルタを定義する加入者プロファイルを、前記課金トリガー機能へ送信するステップを有する。
【００４８】
本発明の第３の態様に従えば、課金トリガー機能として動作するように構成されている装置が提供される。この装置は、一致するストリングを識別するための１つ以上のストリングフィルタを記憶するためのメモリと、前記課金トリガー機能を通過するメッセージが１つ以上の一致するストリングを含んでいるかを判定するためのマッチングユニットと、一致するストリングそれぞれに関連付けられているデータを有するレポートメッセージを生成するためのメッセージ生成ユニットと、前記レポートメッセージを課金制御エンティティへ送信するための送信機とを備える。この装置は、更に、ホーム加入者サーバから、加入者に関連するメッセージに適用される１つ以上のストリングフィルタを含む加入者プロファイルを受信するための受信機を更に備えても良い。
【００４９】
本発明の第４の態様に従えば、ホーム加入者サーバとして動作するように構成されている装置が提供される。この装置は、加入者に関連するメッセージに適用される１つ以上のストリングフィルタを含む加入者プロファイルを記憶するためのメモリと、加入者プロファイルに対するリクエストを受信するための受信機と、前記１つ以上のストリングフィルタを含む前記加入者プロファイルを課金トリガー機能へ送信するための送信機とを備える。
【図面の簡単な説明】
【００５０】
【図１】ＧＰＲＳ／ＰＳアクセスネットワークの移動ネットワークアーキテクチャを示す図である。
【図２】ＩＰマルチメディアサブシステムのオフライン課金アーキテクチャを示す図である。
【図３】ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図４】ＩＰマルチメディアサブシステムのオンライン課金アーキテクチャを示す図である。
【図５】ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図６】本発明の実施形態に従う、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図７】本発明の実施形態に従う、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図８】本発明の実施形態に従う、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図９】本発明の実施形態に従う、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示す図である。
【図１０】本発明の実施形態に従う課金トリガー機能の例を示す図である。
【図１１】本発明の実施形態に従うホーム加入者サーバの例を示す図である。
【発明を実施するための形態】
【００５１】
要求される情報の新規の項目のそれぞれに対して新規の特有のＡＶＰを作成する必要性なく、ＣＴＦ機能を提供するノードを通過するメッセージから導出することができる任意の情報を、ＣＴＦを使用して取得することができる方法を説明する。この方法は、１つ以上のストリングフィルタを使用して情報を識別し、その識別した情報を、ＣＤＦ／ＯＣＳへ送信するための一般情報ＡＶＰに含めるための、ＩＭＳ課金アーキテクチャを構成設定することを含んでいる。この方法に従えば、一般情報ＡＶＰは、ネットワークオペレータによって使用するための任意の情報を搬送するために構成され、これとは対照的に、これらのＡＶＰは特有項目の情報を搬送するために定義される。ＣＴＦを通過するメッセージから取得される情報は、ＩＭＳセッションに関連することができる、あるいはＩＭＳ内のユーザの登録のようなイベントに等しく関連することができる。次に、ＣＤＦ／ＯＣＳは、ＣＤＲ内に対応する新規のフィールドを作成することで、その情報をＢｉインタフェースを介して請求ドメインへ渡すことができる。
【００５２】
ＩＭＳ課金アーキテクチャによって識別される情報は、ユーザ単位で構成設定することができる。これは、その情報をＨＳＳ内の加入者のプロファイルに構成設定し、その情報を加入者のＩＭＳへの登録中にＣＴＦへ提供することによって達成される。ユーザ単位でこの情報を構成設定することは、ＩＭＳ課金アーキテクチャがＩＭＳセッション中にユーザ特有データを出力できることを提供する。
【００５３】
図６はＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示している。このシグナリングフローは、ＣＳＣＦ内で実装されるＣＴＦと、オフライン課金機能との通信を含んでいて、ここでは、ストリングフィルタがユーザ単位で構成設定される。実行されるステップは以下のようになる。
【００５４】
Ｃ１．ＨＳＳは、加入者のプロファイルで構成設定される。構成設定されるプロファイルは、１つ以上のストリングフィルタを定義する。
【００５５】
Ｃ２．ＩＭＳ登録中は、ユーザプロファイル情報はＨＳＳによってサーバ割当回答（ＳＡＡ）メッセージでＣＴＦへ送信される。これには、ユーザプロファイルで定義されるストリングフィルタを含んでいる。
【００５６】
Ｃ３．加入者のＩＭＳへの登録に続いて、加入者のＵＥは、途中のＣＳＣＦを通過するＳＩＰ  ＩＮＶＩＴＥメッセージを自身の宛先へ送信することによってセッション確立を開始する。
【００５７】
Ｃ４．ＩＮＶＩＴＥメッセージの受信先は回答を行い、最終２００  ＯＫ応答がＣＳＣＦを介して経由するＵＥへ返信される。
【００５８】
Ｃ５．ＣＳＣＦにおいて提供されるＣＴＦ機能は、加入者プロファイルで定義されるストリングフィルタを、ＣＳＣＦを通過する／横切るメッセージへ適用して、これらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別する。ＣＴＦは、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録（レコード）する。
【００５９】
Ｃ６．ＣＴＦは、ＡＣＲメッセージをＣＤＦに向けて送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、また、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの開始を記録するために、ＳＴＡＲＴ（開始）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００６０】
Ｃ７．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を開始する。
【００６１】
Ｃ８．ＵＥでの２００  ＯＫ応答の受信に応じて、ＩＭＳセッションが確立される。  
【００６２】
Ｃ９．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッション終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＣＳＣＦを通じて宛先へ渡る。
【００６３】
Ｃ１０．ＣＴＦは、加入者のプロファイルで定義されるストリングフィルタをＳ−ＣＳＣＦを通過する／横切るメッセージに適用することを継続して、そして、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００６４】
Ｃ１１．ＣＴＦは、ＣＤＦに向けてＡＣＲメッセージを送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの終了を記録するために、ＳＴＯＰ（停止）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００６５】
Ｃ１２．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築をクローズする。
【００６６】
図７は、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示している。このシグナリングフローは、ＡＳ内で実装されるＣＴＦと、オフライン課金機能との通信を含んでいて、ここでは、ストリングフィルタがユーザ単位で構成設定される。実行されるステップは以下のようになる。
【００６７】
Ｄ１．ＨＳＳは、加入者のプロファイルで構成設定される。構成設定されるプロファイルは、１つ以上のストリングフィルタを定義する。
【００６８】
Ｄ２．ＩＭＳ登録中は、ユーザプロファイル情報はＨＳＳによってユーザデータ回答（ＵＤＡ）メッセージでＡＳ／ＣＴＦへ送信される。これには、ユーザプロファイルで定義されるストリングフィルタを含んでいる。
【００６９】
Ｄ３．加入者のＩＭＳへの登録に続いて、加入者のＵＥは、途中のＡＳを通過するＳＩＰ  ＩＮＶＩＴＥメッセージを自身の宛先へ送信することによってセッション確立を開始する。
【００７０】
Ｄ４．ＩＮＶＩＴＥメッセージの受信先は回答を行い、最終２００  ＯＫ応答がＡＳを介して経由するＵＥへ返信される。
【００７１】
Ｄ５．ＡＳによって提供されるＣＴＦ機能は、加入者プロファイルで定義されるストリングフィルタを、ＡＳを通過する／横切るメッセージへ適用して、これらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別する。ＣＴＦは、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００７２】
Ｄ６．ＣＴＦは、ＡＣＲメッセージをＣＤＦに向けて送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの開始を記録するために、ＳＴＡＲＴ（開始）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００７３】
Ｄ７．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を開始する。
【００７４】
Ｄ８．ＵＥでの２００  ＯＫ応答の受信に応じて、ＩＭＳセッションが確立される。  
【００７５】
Ｄ９．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッション終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＡＳを通じて宛先へ渡る。
【００７６】
Ｄ１０．ＣＴＦは、加入者のプロファイルで定義されるストリングフィルタをＡＳを通過する／横切るメッセージに適用することを継続して、そして、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００７７】
Ｄ１１．ＣＴＦは、ＣＤＦに向けてＡＣＲメッセージを送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの終了を記録するために、ＳＴＯＰ（停止）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００７８】
Ｄ１２．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築をクローズする。
【００７９】
選択的には、ＩＭＳ課金アーキテクチャによって識別される情報は、この情報を直接ＣＴＦに構成設定することによって、ノード単位で構成することができる。図８は、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示している。このシグナリングフローは、ＣＳＣＦ内で実装されるＣＴＦと、オフライン課金機能との通信を含んでいて、ここでは、ストリングフィルタが、ＣＳＣＦ内でノード単位で構成設定される。実行されるステップは以下のようになる。
【００８０】
Ｅ１．ＣＳＣＦで提供されるＣＴＦが、１つ以上のストリングフィルタで構成設定される。このストリングフィルタは、ＣＳＣＦ／ＣＴＦを通過する任意のＳＩＰメッセージ及びＤｉａｍｅｔｅｒメッセージの少なくとも一方に適用されるものである。
【００８１】
Ｅ２．続いて、ＵＥは、途中のＣＳＣＦを通過するＳＩＰ  ＩＮＶＩＴＥメッセージを自身の宛先へ送信することによってセッション確立を開始する。
【００８２】
Ｅ３．ＩＮＶＩＴＥメッセージの受信先は回答を行い、最終２００  ＯＫ応答がＣＳＣＦを介して経由するＵＥへ返信される。
【００８３】
Ｅ４．ＣＳＣＦによって提供されるＣＴＦは、事前に構成設定されるストリングフィルタを、ＣＳＣＦを通過するメッセージへ適用して、これらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別する。ＣＴＦは、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００８４】
Ｅ５．ＣＴＦは、ＡＣＲメッセージをＣＤＦに向けて送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの開始を記録するために、ＳＴＡＲＴ（開始）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００８５】
Ｅ６．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を開始する。
【００８６】
Ｅ７．ＵＥでの２００  ＯＫ応答の受信に応じて、ＩＭＳセッションが確立される。  
【００８７】
Ｅ８．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッション終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＣＳＣＦを通じて宛先へ渡る。
【００８８】
Ｅ９．ＣＴＦは、事前に構成設定されるストリングフィルタをＣＳＣＦを通過する／横切るメッセージに適用することを継続して、そして、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００８９】
Ｅ１０．ＣＴＦは、ＣＤＦに向けてＡＣＲメッセージを送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの終了を記録するために、ＳＴＯＰ（停止）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００９０】
Ｅ１１．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築をクローズする。
【００９１】
図９は、ＵＥから始められるセッション確立及び終了の例示のシグナリングフロー図を示している。このシグナリングフローは、ＡＳ内で実装されるＣＴＦと、オフライン課金機能との通信を含んでいて、ここでは、ストリングフィルタがＣＳＣＦ内でノード単位で構成設定される。実行されるステップは以下のようになる。
【００９２】
Ｆ１．ＡＳが、１つ以上のストリングフィルタで構成設定される。このストリングフィルタは、ＡＳ／ＣＴＦを通過する任意のＳＩＰメッセージ及びＤｉａｍｅｔｅｒメッセージの少なくとも一方に適用されるものである。
【００９３】
Ｆ２．続いて、ＵＥは、途中のＡＳを通過するＳＩＰ  ＩＮＶＩＴＥメッセージを自身の宛先へ送信することによってセッション確立を開始する。
【００９４】
Ｆ３．ＩＮＶＩＴＥメッセージの受信先は回答を行い、最終２００  ＯＫ応答がＡＳを介して経由するＵＥへ返信される。
【００９５】
Ｆ４．ＡＳによって提供されるＣＴＦは、事前に構成設定されるストリングフィルタを、ＡＳを通過するメッセージへ適用して、これらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別する。ＣＴＦは、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【００９６】
Ｆ５．ＣＴＦは、ＡＣＲメッセージをＣＤＦに向けて送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰは、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの開始を記録するために、ＳＴＡＲＴ（開始）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【００９７】
Ｆ６．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築を開始する。
【００９８】
Ｆ７．ＵＥでの２００  ＯＫ応答の受信に応じて、ＩＭＳセッションが確立される。  
【００９９】
Ｆ８．このＩＭＳセッションは、ＵＥがセッションの終了を開始するまで継続する。ＵＥは、ＳＩＰ  ＢＹＥメッセージを送信することによってセッション終了を開始する。ＳＩＰ  ＢＹＥメッセージは、途中のＡＳを通じて宛先へ渡る。
【０１００】
Ｆ９．ＣＴＦは、事前に構成設定されるストリングフィルタを、ＡＳを通過する／横切るメッセージに適用することを継続して、そして、任意のこれらのストリングに一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを、これらの一致する任意のＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰ内で関連付けられている任意の値とともに記録する。
【０１０１】
Ｆ１０．ＣＴＦは、ＣＤＦに向けてＡＣＲメッセージを送信する。ＡＣＲメッセージは、一般情報ＡＶＰを含んでいる。一般情報ＡＶＰの値は、一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰを識別するものであり、そして、その一致するＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値を含んでいる。ＡＣＲメッセージは、ユーザセッションの終了を記録するために、ＳＴＯＰ（停止）を示すアカウンティング−レコード−タイプ（Accounting-Record-Type）  ＡＶＰを有している。
【０１０２】
Ｆ１１．ＣＤＦは、ＡＣＡメッセージを送信することによってＡＣＲの受信を確認応答する。ＣＤＦは、ＣＤＲの構築をクローズする。
【０１０３】
これらの方法を実現するために、ＣＴＦとＣＤＦ間のＲｆインタフェースと、ＣＴＦとＯＣＳ間のＲｏインタフェースの両方は、新規の一般情報ＡＶＰを含める拡張を要求することになる。上述のように、一般情報ＡＶＰは、ＣＴＦを通過するメッセージから取得される情報を搬送するために使用されることになる。一般情報ＡＶＰを定義することは、ＣＤＦ／ＯＣＳによってＣＴＦから要求される情報の新規の各部分に対して新規の特有のＡＶＰを作成するための必要性を回避する。
【０１０４】
加えて、ＣＤＦ／ＯＣＳによって要求される情報がＨＳＳ内でユーザ単位で定義される場合、ＨＳＳとＣＴＦ間のインタフェースも拡張を要求することで、ＨＳＳに、要求される情報を識別するために使用されるべきストリングフィルタを送信することを可能にする。例えば、ＨＳＳとＣＳＣＦ間のＣｘインタフェースと、ＨＳＳとＡＳ間のＳｈインタフェースとは、新規にリクエストされる情報ＡＶＰを含める拡張を要求する場合がある。リクエストされる情報ＡＶＰは、複数のＡＶＰのシーケンスで構成されるグループ化タイプＡＶＰの形式をとることになり、このＡＶＰに、複数のストリングフィルタを含めることを可能にする。グループ化タイプＡＶＰは、ＩＥＴＦ  ＲＦＣ３５８８で定義される。このリクエストされる情報ＡＶＰは、ＨＳＳから送信される加入者プロファイル情報を搬送するＤｉａｍｅｔｅｒメッセージ内に含まれることになる。例えば、リクエストされる情報ＡＶＰは、以下の形式をとることができる。
【０１０５】
*Requested-Transaction-Info ::=
*{Requested-Transaction-Type = ＜transaction type＞}
*[Requested-Transaction-Data-Entry = ＜header, CC/VendorlD/AVP
name/code＞]
*[Requested-Transaction-Data-Value = ＜value＞]
ここで、＜  ＞は、必須の位置依存フィールドを示していて、｛  ｝は必須のフィールドを示していて、［  ］はオプションのフィールドを示していて、＊は複数のインスタンスを有することができるフィールドを示している。
【０１０６】
Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏは、グループ化されているリクエストされた情報ＡＶＰの名前である。グループ化されているＡＶＰ内のＲｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｔｙｐｅ  ＡＶＰは、どのタイプのメッセージ（即ち、ＳＩＰリクエスト、Ｄｉａｍｅｔｅｒ応答等）にフィルタを適用すべきかを示している。Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｔｙｐｅ  ＡＶＰは、列挙型フォーマットとなり、また、その自身の定義は、有効値のリストを含んでいる（即ち、０＝ＳＩＰリクエスト）。Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｅｎｔｒｙ  ＡＶＰは、メッセージに対して一致すべきストリングフィルタを含んでいる。例えば、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｅｎｔｒｙ  ＡＶＰは、ＳＩＰヘッダフィールド名、ＡＶＰ名を有するＤｉａｍｅｔｅｒメッセージコマンドコード、あるいはＡＶＰコードを有するＤｉａｍｅｔｅｒコマンドコードを含むことができ、また、必要であれば、ベンダＩＤを含むことができる。
【０１０７】
Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰは、オプションのＡＶＰであり、これは、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｅｎｔｒｙ  ＡＶＰに関連付けられている追加のストリングフィルタを含めることができる。これが存在する場合、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰは、ＳＩＰヘッダあるいはＤｉａｍｅｔｅｒＡＶＰ内に、関心のある特有の値を定義するストリングを含んでいる。正規表現（ｒｅｇｅｘｐ）評価を、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰに定義されるストリングについて実行することができ、そうすることで、ストリングに一致する、ＳＩＰヘッダ／Ｄｉａｍｅｔｅｒ  ＡＶＰのこれらの一部だけが一般情報ＡＶＰに記録され出力される。Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰが存在しない場合、ＳＩＰヘッダあるいはＤｉａｍｅｔｅｒ  ＡＶＰに関連付けられている値全体が、一般情報ＡＶＰに記録され出力されることになる。
【０１０８】
ＨＳＳからＣＴＦへ送信されるＤｉａｍｅｔｅｒメッセージが、複数のストリングフィルタを定義するものである場合、次に、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｅｎｔｒｙ  ＡＶＰ（及び、可能であれば、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰ）の複数のインスタンスが、Ｒｅｑｕｅｓｔｅｄ−Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰに含められることになる。特定のＳＩＰヘッダを識別するためのストリングフィルタを定義する場合、これは、ＳＩＰヘッダフィールド名をストリングフィルタとして単に使用することで十分である。しかしながら、ＤｉａｍｅｔｅｒＡＶＰに対するストリングフィルタを定義する場合、ＡＶＰ名を含むＤｉａｍｅｔｅｒメッセージコマンドコード、あるいはＡＶＰコードを含むＤｉａｍｅｔｅｒメッセージコマンドコードを含めることが必要であり、要求される場合には、ベンダＩＤも必要である。
【０１０９】
一般情報ＡＶＰは、ＡＶＰのシーケンスからなるグループ化タイプＡＶＰの形式もとれ、また、このＡＶＰに、複数の一致するストリングに関連するデータを搬送することを可能にする。この一般情報ＡＶＰは、ＣＴＦを通過するメッセージから取得される情報を搬送するための、課金制御ノード（即ち、ＣＤＦ／ＯＣＳ）へ送信されるＤｉａｍｅｔｅｒメッセージ内に含められることになる。例えば、一般情報ＡＶＰは、以下の形式をとることができる。
【０１１０】
*Transaction-Info ::=
{Transaction-Type} Enumerated: O=SIP Request, 1 =SIP Response,
2=Diameter Request, 3=Diameter Response
*{Transaction-Data-Name}
*{Transaction-Data-Value}
Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏは、グループ化一般情報ＡＶＰの名前である。グループ化ＡＶＰ内のＴｒａｎｓａｃｔｉｏｎ−Ｔｙｐｅ  ＡＶＰは、どのメッセージのタイプ（即ち、ＳＩＰリクエスト、Ｄｉａｍｅｔｔｅｒ応答等）がストリングフィルタによって識別されているかを示している。Ｔｒａｎｓａｃｔｉｏｎ−Ｔｙｐｅ  ＡＶＰは列挙型（Enumerated）フォーマットとなり、また、その自身の定義は、有効値のリストを含んでいる（即ち、０＝ＳＩＰリクエスト）。Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｎａｍｅ  ＡＶＰは、ストリングフィルタを使用して一致するストリングを示していて、これには、例えば、ＳＩＰヘッダあるいは属性名がある。Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰは、一致するストリングに関連付けられている値を示している。例えば、Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰは、ＳＩＰヘッダあるいはＡＶＰの値に関連付けられている値を含んでいる。
【０１１１】
メッセージがストリングフィルタに対して２つ以上一致するものを含んでいると識別される場合、Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｎａｍｅ  ＡＶＰとＴｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰの複数のインスタンスが、各一致するストリングに関連する情報を搬送するために、Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰに含められる。加えて、Ｔｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｎａｍｅ  ＡＶＰとＴｒａｎｓａｃｔｉｏｎ−Ｄａｔａ−Ｖａｌｕｅ  ＡＶＰの複数のインスタンスは、メッセージが異なるストリングフィルタに一致する複数のストリングを含んでいる場合にも、Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰに含められることになる。
【０１１２】
例えば、ＣＴＦが、ＳＩＰリクエストのコンタクトヘッダ（Contact header）内に含まれる情報を取得するためのストリングフィルタで構成設定される場合、ＳＩＰリクエストが、２つのコンタクトヘッダに含まれるＣＴＦを通過すると想定すると、Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰは、以下の形式をとり得る。
【０１１３】
Transaction-Info ::=
Transaction-Type= 0
Transaction-Data-Name= Contact
Transaction-Data-Value= sip@ericsson.com
Transaction-Data-Name= Contact
Transaction-Data-Value= sip2@ericsson.com
別の例では、ＳＩＰ応答（SIP Response）のユーザエージェント（User-Agent）内に含まれる情報を取得するためのストリングフィルタで構成設定される場合、Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰは、以下の形式をとり得る。
【０１１４】
Transaction-Info ::=
Transaction-Type= 1
Transaction-Data-Name= user-agent
Transaction-Data-Value= sipclient
更なる例では、ＣＴＦが、Ｄｉａｍｅｔｅｒ  Ｌｏｃａｔｉｏｎ  Ｉｎｆｏ  Ａｎｓｅｗｅｒ（ＬＩＡ：ロケーション情報回答）リクエストのＳＩＰ−Ｓｅｒｖｅｒ−ＵＲＩ  ＡＶＰ内に含まれる情報を取得するためのストリングフィルタで構成設定される場合、Ｔｒａｎｓａｃｔｉｏｎ−Ｉｎｆｏ  ＡＶＰは、以下の形式をとり得る。
【０１１５】
Transaction-Info ::=
Transaction-Type= 2
Transaction-Data-Name= 285 SIP-Server-URI
Transaction-Data-Value= sip@ericsson.com
ここで、２８５は、Ｄｉａｍｅｔｅｒ  ＬＩＡメッセージコマンドコードである。
【０１１６】
図１０は、上述の方法を実現するために適合されているＣＴＦ１の例を示している。ＣＴＦ１は、コンピュータハードウェア及びソフトウェアの組み合わせとして実現することができる。ＣＴＦ１は、データベースあるいはメモリ２、マッチングユニット３、メッセージ生成ユニット４、送信機５及び受信機６を備える。メモリ２は、ストリングフィルタを記憶するために使用される。マッチングユニット３は、ＣＴＦ１を通過するメッセージが、メモリに２記憶されているストリングフィルタと一致（マッチング）する任意のストリングを含んでいるかを判定する。任意の一致するストリングが識別される場合、メッセージ生成ユニット４は、識別される一致するストリングそれぞれに関連付けられている任意のデータを含むＤｉａｍｅｔｅｒメッセージを生成する。次に、Ｄｉａｍｅｔｅｒメッセージは、送信機５によってＣＤＦあるいはＯＣＳによって送信され、一致するストリングとそれらのストリングに関連付けられているデータをレポートする。受信機６は、ＣＴＦがユーザ単位でストリングフィルタで構成設定される場合に、ＨＳＳから加入者のプロファイル情報を受信するために使用することができる。
【０１１７】
図１１は、上述の方法を実現するために適合されているＨＳＳ７の例を示している。ＨＳＳ７は、ハードウェア及びソフトウェアの組み合わせとして実現することができる。ＨＳＳ７は、受信機８、データベースあるいはメモリ９、プロセッサ１０及び送信機１１を備えている。メモリ９は、ＣＴＦによって加入者に関連するメッセージに適用されるストリングフィルタを含む加入者プロファイルを記憶するために使用される。ＨＳＳ７は、受信機８における加入者プロファイル情報に対するリクエストを受信する。プロセッサ１０は、そのリクエスト内の情報を使用して、メモリ９から加入者のプロファイルを識別し、取得する。ストリングフィルタを含む加入者のプロファイルは、次に、送信機１１によってＣＴＦへ送信される。
【０１１８】
上述の方法及び装置は、ＣＴＦに、ＣＴＦを通過するメッセージから導出することができる任意の情報を課金アーキテクチャ（即ち、ＣＤＦ／ＯＣＳ）へ提供することを可能にする。上述の方法を実現する場合、課金アーキテクチャに提供することができる情報は、要求に応じて、ネットワークオペレータに、ＩＭＳの加入者の使用の全体像を形成することを可能にする。例えば、ネットワークオペレータはこの情報を使用して、どれくらいの数のライセンスが使用されているかを判定することができ、これは、特に、この情報は、ライセンスに対する追加料金を支払うことが要求される場合に有用である。
【０１１９】
この情報を搬送するための一般情報ＡＶＰを定義することは、ＣＴＦとＣＤＦ／ＯＣＳから渡されることが好ましい、課金関連情報の新しい部分毎について、新規の特有のＡＶＰが作成される必要がないことを実現し、その結果、コストが削減される。また、これは、柔軟なソリューションを提供する。それは、任意のＳＩＰヘッダ／Ｄｉａｍｅｔｅｒ  ＡＶＰを、ＯＣＳ／ＣＤＲに出力される課金関連情報として特定することができるからである。
【０１２０】
本発明の範囲から逸脱しないで、上述の実施形態に対して様々な変形を行うことができることが明らかであろう。例えば、上述の方法は、ＣＴＦ機能を提供するノードを通過するＩＳＤＮユーザパート（ＩＳＵＰ）メッセージから情報を取得するために等しく適用することができる。
【図１】
0005583782.tif 000002
【図２】
0005583782.tif 000003
【図３】
0005583782.tif 000004
【図４】
0005583782.tif 000005
【図５】
0005583782.tif 000006
【図６】
0005583782.tif 000007
【図７】
0005583782.tif 000008
【図８】
0005583782.tif 000009
【図９】
0005583782.tif 000010
【図１０】
0005583782.tif 000011
【図１１】
0005583782.tif 000012