JP4885525B2 - Ｉｍｓネットワークにおけるアプリケーション・サーバー・ロジックとゲートウェイ・ロジックの統合によるコール制御（ｃａｌｌｃｏｎｔｒｏｌ） - Google Patents

Description

本発明は、通信の分野に関し、特にアプリケーション・サーバー（ＡＳ）ロジックとゲートウェイ・ロジックを統合してＩＭＳネットワーク内でオンライン課金（ｏｎｌｉｎｅ ｃｈａｒｇｉｎｇ）を可能にするＩＭＳコール制御ノードおよび方法に関する。

３^ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）で規定するように、ＩＰマルチメディア・サブシステム（ＩＭＳ：ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）は統合ネットワークを実現するためのアクセス不問の（ａｃｃｅｓｓ−ａｇｎｏｓｔｉｃ）ネットワーク・アーキテクチャを備える共通コア・ネットワークを提供する。サービス・プロバイダは、次世代ネットワークの発展においてこのアーキテクチャを容認している。オペレータの収益を生成する効率的なＩＭＳオンライン課金を実現することは、ＩＭＳネットワークの配備を成功させる上で重要である。

いくつかの３ＧＰＰ技術仕様では、ＩＭＳネットワークのオンライン課金について記載している。たとえば、３ＧＰＰ ＴＳ ３２．２００およびＴＳ ３２．２４０仕様では、セッション課金機能を備えたオンライン課金サーバー（ＯＣＳ：ｏｎｌｉｎｅ ｃｈａｒｇｉｎｇ ｓｅｒｖｅｒ）について記述している。ＯＣＳは、ＩＭＳサービス制御（ＩＳＣ：ＩＭＳ ｓｅｒｖｉｃｅ ｃｏｎｔｒｏｌ）インターフェイスを経由してコール・セッション制御機能（ＣＳＣＦ：ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）に接続する。ＣＳＣＦは、発呼側または被呼側のコール・セッションを制御し、ＩＳＣインターフェイスを経由してＯＣＳと通信することで、コール・セッションのオンライン課金を実行する必要がある。しかし、ＩＳＣインターフェイスはサービス・インターフェイスであり、オンライン課金をサポートしない。したがって、ＣＳＣＦとＯＣＳの間でＩＳＣインターフェイスを使用してオンライン課金を実行するためには、残念ながらＯＣＳに新しい機能を追加する必要がある。

ＯＣＳに機能を追加することによる過負荷を避けるため、およびオンライン課金アーキテクチャの一貫性を維持するためには、ＯＣＳに機能を追加する代わりに、オンライン課金をサポートするようにＣＳＣＦとＯＣＳとのインターフェイスを変更してもよい。オンライン課金をサポートするインターフェイスを実現するための１つの選択肢は、課金メカニズムを有効にするようにＩＳＣインターフェイスを拡張することである。これで、ＩＳＣインターフェイスはサービス・インターフェイスであると同時に、課金インターフェイスにもなる。残念ながら、ＩＳＣインターフェイスをサービス／課金のハイブリッド・インターフェイスとして使用する方法は、３ＧＰＰで望まれる標準化としては容認されない。

もう１つの選択肢は、ＩＳＣインターフェイスの代わりにＲｏインターフェイスを使用することである。Ｒｏインターフェイスはすでにオンライン課金をサポートしている。３ＧＰＰ ＴＳ ３２．２９６仕様では、ＣＳＣＦとＯＣＳの間でゲートウェイとして機能するＩＭＳゲートウェイ機能を導入することでオンライン課金を実現する場合に、Ｒｏインターフェイスの使用を提唱している。３２．２９６仕様で提唱するＩＭＳゲートウェイ機能は、ＩＳＣインターフェイスを経由してＣＳＣＦと通信し、Ｒｏインターフェイスを経由してＯＣＳと通信する。残念ながら、３２．２９６仕様にもその他の３ＧＰＰ仕様にも、ＩＭＳゲートウェイ機能を使用してオンライン課金を実現する方法についての説明はない。たとえば、こうした仕様では、ＩＭＳゲートウェイ機能がどのように動作してオンライン課金を実現するかを定義していない。また、ＩＳＣインターフェイス、Ｒｏインターフェイス、ＣＳＣＦがどのように連携して機能するかについても明らかにしていない。たとえば、ゲートウェイ（ＩＭＳゲートウェイ機能）を経由してＣＳＣＦを直接ＯＣＳに接続するかどうかを規定した仕様は標準化の域を超えている。ＩＭＳゲートウェイ機能の物理的な位置は仕様ごとにさまざまである。

こうした仕様では、ＩＭＳネットワークについてさらにＯＣＳのイベントベースの課金機能に接続する複数のアプリケーション・サーバーを含むとして説明している。アプリケーション・サーバーは、Ｒｏインターフェイスを経由してＯＣＳと通信し、ＩＳＣインターフェイスを経由してＣＳＣＦと通信する。残念ながら、こうした仕様では、どのようにしてアプリケーション・サーバーがＯＣＳと通信し、サービスのセッションベースのオンライン課金を実現するかを定義していない。

現在の３ＧＰＰ仕様では、ＩＭＳネットワークでオンライン課金を実現する方法は適切には定義されていない。ＩＭＳネットワークでオンライン課金を実現する機能を定義するには問題が残る。

本発明は、ＩＭＳネットワーク内でオンライン課金を可能にするＩＭＳコール制御ノードおよび方法を定義することによって発生する前述の問題およびその他の問題を解決する。本明細書で説明するＩＭＳコール制御ノードおよび方法は、３ＧＰＰ仕様でも出版物でもまだ定義されていない便利なオンライン課金またはオンライン・セッション課金の手法を定義する。これで、顧客はこのオンライン課金機能を実装することで収益を増大できる。

本発明の１つの実施形態は、コール・セッション制御機能（ＣＳＣＦ）とオンライン課金サーバー（ＯＣＳ）に接続し、セッションベースのオンライン課金を可能にするＩＭＳコール制御ノードを備えている。ＩＭＳコール制御ノードには、ＣＳＣＦと通信するための第１のインターフェイス、処理システム、アプリケーション・サーバー（ＡＳ）ロジック、ゲートウェイ・ロジック、およびＯＣＳと通信するための第２のインターフェイスが含まれる。第１のインターフェイスは第１のプロトコルに従ってＣＳＣＦと通信する。ただし、第１のプロトコルはオンライン課金をサポートしない。第２のインターフェイスは、オンライン課金をサポートする第２のプロトコルに従ってＯＣＳと通信する。

稼働中に、処理システムはＣＳＣＦから第１のインターフェイスを経由してコール・メッセージを受信する。コール・メッセージに応答して、処理システムは、コール・メッセージがサービスまたはコール・セッション制御のいずれか１つの要求であるかを識別することによって、コール・メッセージに応答するＡＳロジックを実行するかゲートウェイ・ロジックを実行するかを決定する。処理システムがコール・メッセージをサービスの要求と判断した場合に、処理システムはサービスを実行するＡＳロジックを実行する。処理システムは、さらに第２のプロトコルによる第２のインターフェイスを経由してＯＣＳに接続し、サービスのセッションベースのオンライン課金を実行するＡＳロジックを実行する。処理システムがコール・メッセージをコール・セッション制御を実行するものと判断した場合に、処理システムはコール・セッション制御を行うゲートウェイ・ロジックを実行する。処理システムは、さらに第２のプロトコルによる第２のインターフェイスを経由してＯＣＳに接続し、コール・セッションのセッションベースのオンライン課金を行うゲートウェイ・ロジックを実行する。

ＩＭＳコール制御ノード内でＡＳロジックとゲートウェイ・ロジックを統合すると、統合によってＩＭＳネットワーク・トポロジが簡素化され、ＣＳＣＦとＯＣＳの間のコール・トラフィックが削減される。また、統合することでＩＭＳコール制御ノードが提供するサービスの性能が向上し、応答時間が短縮される。ＩＭＳコール制御ノードは、さらにＡＳロジックが提供する複数のサービスのオンライン課金、およびコール・セッションに関するリアルタイム・セッションベースのオンライン課金を実行する。

本発明には、以下で説明する他の例示的な実施形態が含まれる。
すべての図面を通じて、同じ参照番号は同類の機能を表している。

図１〜１４と以下の説明は、本発明の特定の例示的な実施形態を示しており、本発明の最適なモードを作成し、使用する方法を当業者に教示することを目的とする。発明の原理を教示するために、本発明の慣例的ないくつかの態様は簡素化または省略されている。当業者には言うまでもないが、このような実施形態のバリエーションは本発明の範囲を逸脱しない。当業者には言うまでもないが、以下で説明する機能をさまざまな方法で組み合わせることによって、本発明の複数のバリエーションを構成できる。したがって、本発明は以下で説明する特定の実施形態に限定されず、請求項およびそれと同等のものよってのみ限定される。

図１は、本発明の１つの例示的な実施形態においてオンライン課金を実行するＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワーク１００を示している。ＩＭＳネットワーク１００には、コール・セッション制御機能（ＣＳＣＦ）１１０、ＩＭＳコール制御ノード１０１、オンライン課金サーバー（ＯＣＳ）１２０が含まれる。ＩＭＳコール制御ノード１０１には、ＣＳＣＦ １１０と通信するためのインターフェイス１１２、処理システム１０２、アプリケーション・サーバー（ＡＳ）ロジック１０４〜１０６、ゲートウェイ・ロジック１０８、およびＯＣＳ １２０と通信するためのインターフェイス１２２が含まれる。インターフェイス１１２は、リンク１１１を経由してＣＳＣＦ １１０に接続し、第１のプロトコルに従って通信する。第１のプロトコルはオンライン課金をサポートしない。インターフェイス１１２とＣＳＣＦ １１０で使用する第１のプロトコルの１つの例は、ＩＭＳサービス制御（ＩＳＣ）プロトコルである。インターフェイス１２２は、リンク１２１を経由してＯＣＳ １２０に接続し、第１のプロトコルとは異なる第２のプロトコルに従って通信する。第２のプロトコルはオンライン課金をサポートする。インターフェイス１２２とＯＣＳ １２０で使用する第２のプロトコルの１つの例は、Ｒｏプロトコルである。ＩＭＳネットワーク１００には、図１に示さないその他のコンポーネント、デバイス、あるいはシステムを含めてもよい。

１つの実施態様では、処理システム１０２にはメッセージ・キュー１６０とアプリケーション・サーバー（ＡＳ）マネージャ１７０も含まれる。メッセージ・キュー１６０は、処理システム１０２の影響を受ける任意のメッセージをバッファに格納するように構成される。ＡＳマネージャ１７０は、どのＡＳロジック１０４〜１０６を実行するかを決定するように構成される。ＡＳマネージャ１７０は、さらにＡＳロジック１０４〜１０６の実行シーケンスを決定し、サービスを実行するＡＳロジックの実行シーケンスのリストを生成するように構成される。

ＩＭＳコール制御ノード１０１は、ゲートウェイ・ロジックと複数のアプリケーション・サーバーのロジックとを唯一のノードに統合する。個々のアプリケーション・サーバーのロジックは、独立したプラグイン・コンポーネントを備えていてもよい。「ロジック」という用語は、アプリケーション・サーバーまたはゲートウェイのアクションを実行する任意の機能、メカニズム、ソフトウェア、ファームウェア、あるいはハードウェアを意味する。ＡＳロジック１０４〜１０６とゲートウェイ・ロジック１０８は、いずれも処理システム１０２で実行できる。ＡＳロジック１０４〜１０６とゲートウェイ・ロジック１０８は、処理システム１０２からアクセスできる記憶媒体（図示せず）に格納できる。

図２は、本発明の１つの例示的な実施形態においてＩＭＳコール制御ノード１０１を操作する方法２００を示す流れ図である。ステップ２０２で、処理システム１０２はＣＳＣＦ １１０からインターフェイス１１２を経由してコール・メッセージを受信する。コール・メッセージは第１のプロトコルに従う。コール・メッセージには、ＳＩＰメッセージ（ＳＩＰ ＩＮＶＩＴＥメッセージなど）、ＯＫメッセージ、ＡＣＫメッセージなどが含まれていてもよい。ＣＳＣＦ １１０からのコール・メッセージに応答して、処理システム１０２はコール・メッセージに応答するＡＳロジック１０４〜１０６を実行するかゲートウェイ・ロジック１０８を実行するかを決定する（ステップ２０４）。決定時に、処理システム１０２はまずコール・メッセージがサービスの要求かコール・セッション制御メッセージかを識別してもよい。コール・メッセージがサービスを要求している場合は、処理システム１０２がＡＳロジック１０４〜１０６を使用してコール・メッセージを処理することを決定する。第１のメッセージがサービスの要求ではなくコール・セッションのセットアップまたは保守に関連する場合は、処理システム１０２がゲートウェイ・ロジック１０８を使用してコール・メッセージを処理することを決定する。

処理システム１０２がコール・メッセージをＡＳロジック１０４〜１０６で処理することを決定した場合は、処理システム１０２がサービスを実行するＡＳロジック１０４〜１０６を実行する（ステップ２０６）。ＡＳロジック１０４〜１０６のどれを実行するかは、どのサービスを実行するかによって決まる。処理システム１０２は、さらにＯＣＳ １２０に接続し、第２のプロトコルによるインターフェイス１２２を経由してサービスのオンライン課金を行うＡＳロジック１０４〜１０６を実行する（ステップ２０８）。

処理システム１０２がコール・メッセージをゲートウェイ・ロジック１０８で処理する必要があることを決定した場合は、処理システム１０２がコール・セッション制御を行うゲートウェイ・ロジック１０８を実行する（ステップ２１０）。処理システム１０２は、さらにＯＣＳ １２０に接続し、ステップ２１２で第２のプロトコルによるインターフェイス１２２を経由してコール・セッションのオンライン課金を行うゲートウェイ・ロジック１０８を実行する。コール・セッションはあらかじめ確立され、開始されていてもよい。

たとえば、処理システム１０２はコール・セッション中にＣＳＣＦ １１０から第１のメッセージを受信すると仮定する。処理システム１０２は第１のメッセージを処理し、第１のメッセージに応答して第１のサービスが必要であることを決定する。次に、処理システム１０２は第１のサービスを実行するＡＳロジック１０４を実行する。ＡＳロジック１０４は、このコールの課金がオンラインかオフラインかを決定する。オフライン課金の場合は、ＡＳロジック１０４はオフライン課金ノード（図４には表示せず）に課金情報を送信する。オンライン課金の場合は、処理システム１０２がＯＣＳ １２０に接続し、第１のサービスのオンライン課金を行うＡＳロジック１０４を実行する。処理システム１０２は、インターフェイス１２２を経由し、第２のプロトコルに従ってＯＣＳ １２０に接続する。

さらに、処理システム１０２はコール・セッション中にＣＳＣＦ １１０から第２のメッセージを受信すると仮定する。処理システム１０２は第２のメッセージを処理し、第２のメッセージに応答して第２のサービスが必要であることを決定する。ここで、処理システム１０２は第２のサービスを実行するＡＳロジック１０５を実行する。次に、処理システム１０２はＯＣＳ １２０に接続し、第２のサービスのオンライン課金を行うＡＳロジック１０５を実行する。処理システム１０２は、インターフェイス１２２を経由し、第２のプロトコルに従ってＯＣＳ １２０に接続する。

さらに、処理システム１０２はコール・セッション中にＣＳＣＦ １１０から第３のメッセージを受信すると仮定する。処理システム１０２は、第３のメッセージを処理し、第３のメッセージに応答してコール・セッション制御が必要であることを決定する。ここで、処理システム１０２はコール・セッション制御を行うゲートウェイ・ロジック１０８を実行する。さらに、処理システム１０２はＯＣＳ １２０に接続し、コール・セッションのオンライン課金を行うゲートウェイ・ロジック１０８を実行する。処理システム１０２は、インターフェイス１２２を経由し、第２のプロトコルに従ってＯＣＳ １２０に接続する。

図３は、本発明の別の例示的な実施形態におけるＩＭＳコール制御ノード３０１を伴うＩＭＳネットワーク３００を示す図である。ＩＭＳネットワーク３００には、モバイル・ステーション３３０、コール・セッション制御機能（ＣＳＣＦ）３１０、ＩＭＳコール制御ノード３０１、オンライン課金サーバー（ＯＣＳ）３２０が含まれる。ＩＭＳコール制御ノード３０１は、ＣＳＣＦ ３１０およびＯＣＳ ３２０とは別個のノードとして示されている。ＩＭＳコール制御ノード３０１には、ＣＳＣＦ ３１０と通信するためのインターフェイス３１２、処理システム３０２、記憶媒体３０３、およびＯＣＳ ３２０と通信するためのＲｏインターフェイス３２２が含まれる。処理システム３０２には、メッセージ・キュー３６０とアプリケーション・サーバー（ＡＳ）マネージャ３７０も含まれる。メッセージ・キュー３６０には、ＩＳＣメッセージ・キュー３６２とｄｉａｍｅｔｅｒメッセージ・キュー３６４も含まれる。

ＩＳＣインターフェイス３１２は、リンク３１１を経由してＣＳＣＦ ３１０に接続し、ＩＳＣプロトコルに従って通信する。たとえば、ＩＳＣインターフェイス３１２はＳＩＰインターフェイスまたは他の類似のプロトコルを備えていてもよい。Ｒｏインターフェイス３２２は、リンク３２１を経由してＯＣＳ ３２０に接続し、Ｒｏプロトコルに従って通信する。より具体的には、Ｒｏインターフェイス３２２はリンク３２１を経由してＯＣＳ ３２０内のセッションベースの課金機能３２４に接続する。ＩＭＳネットワーク３００には、図３に示さないその他のコンポーネント、デバイス、あるいはシステムを含めてもよい。

処理システム３０２は、記憶媒体３０３に格納されたロジックとソフトウェアを実行するように構成される。記憶媒体３０３には、アプリケーション・サーバー（ＡＳ）ロジック３０４〜３０６、ゲートウェイ・ロジック３０８、コール制御ソフトウェア３５２、トリガー・ソフトウェア３５３、および予算管理ソフトウェア３５４が格納される。図３に示すロジックとソフトウェアは、記憶媒体３０３に格納された命令で構成される。こうした命令は、処理システム３０２で取得でき、実行できる。命令のいくつかの例として、ソフトウェア、プログラム・コード、ファームウェアがある。記憶媒体３０３のいくつかの例として、メモリ・デバイス、テープ、ディスク、集積回路、サーバーがある。命令は、処理システム３０２で実行された場合に機能し、処理システム３０２に対して本発明に従って動作するように指示する。「処理システム」という用語は、１台の処理装置または相互運用可能な処理装置のグループを意味する。処理システムのいくつかの例として、コンピュータ、集積回路、論理回路がある。命令、プロセッサ、記憶媒体については、当業者には周知である。

処理システム３０２はメッセージ・キュー３６０を保持しており、アプリケーション・サーバー（ＡＳ）マネージャ３７０による複数の独立したプラグイン「ロジック」の相互作用を実装する。ＩＳＣメッセージ・キュー３６２は、ＣＳＣＦ ３１０から受信したメッセージまたはＣＳＣＦ ３１０に宛てたメッセージをバッファに格納する。ＩＳＣメッセージ・キュー３６２は、ＡＳロジック３０４〜３０６の間のメッセージをバッファに格納する。Ｄｉａｍｅｔｅｒメッセージ・キュー３６４は、ＯＣＳ ３２０から受信したメッセージまたはＯＣＳ ３２０に宛てたメッセージをバッファに格納する。ＡＳマネージャ３７０は、サービスを実行する特定のＡＳロジック実行シーケンスを定義する。１つのＡＳロジックの出力は、別のＡＳロジックの入力になることができる。ＡＳロジックの実行シーケンスは、実世界のアプリケーション・シナリオに従って構成できる。処理システム３０２は、他のサービス・コンポーネントに影響することなく１つのアプリケーションを無効化できる。ＩＭＳコール制御ノード３０１は、次の３種類のアプリケーションとして構成できる。
１）単純なＩＭＳゲートウェイ
２）スタンドアロンのアプリケーション・サーバー
３）統合されたＩＭＳアプリケーション・サーバー

ＩＭＳネットワーク３００は、実質的に図２に示すように動作する。処理システム３０２は、ＣＳＣＦ ３１０からＩＳＣインターフェイス３１２を経由してコール・メッセージを受信する。コール・メッセージは、ＳＩＰメッセージ（ＳＩＰ ＩＮＶＩＴＥメッセージなど）、ＯＫメッセージ、ＡＣＫメッセージなどである。ＣＳＣＦ ３１０からのコール・メッセージに応答して、処理システム３０２はコール・メッセージに応答するＡＳロジック３０４〜３０６を実行するかゲートウェイ・ロジック３０８を実行するかを決定する。

ＡＳマネージャ３７０は、ＣＳＣＦ ３１０から受信したコール・メッセージを処理する。ＡＳマネージャ３７０は、コール・メッセージに基づいてＡＳロジック３０４〜３０６またはゲートウェイ・ロジック３０８でアクションの実行シーケンスを決定する。ＡＳマネージャ３７０は、ＡＳ実行シーケンスのリストを生成し、これに従って１つまたは複数のサービスを実行する。ＡＳマネージャ３７０は、ＡＳロジック３０４〜３０６とゲートウェイ・ロジック３０８の実行シーケンスを定義することによって、ＡＳロジック３０４〜３０６とゲートウェイ・ロジック３０８を統合できる。

図１４は、本発明の１つの例示的な実施形態における、ＩＭＳコール制御ノード３０１内のロジックの統合を示している。図１４において、メッセージ・キュー３６０はＣＳＣＦ ３１０からＩＳＣインターフェイス３１２を経由してＳＩＰメッセージを受信する。ＡＳマネージャ３７０は、ＳＩＰメッセージを処理してアクションの実行シーケンスを決定する。ＡＳマネージャ３７０は、ＡＳ実行シーケンスのリストを生成して実行するアクションを制御する。処理システム３０２は、ＡＳ実行シーケンスのリストに基づいてまずＡＳロジック３０４を実行する。次に、処理システム３０２はＡＳロジック３０５を実行する。さらに、処理システム３０２はＡＳロジック３０６を実行する。最後に、処理システム３０２はゲートウェイ・ロジック３０８を実行する。図１４に示すように、１つのＡＳロジックの出力は別のＡＳロジックの入力になることができる。

図３で、ＡＳマネージャ３７０がコール・メッセージをＡＳロジック３０４〜３０６で処理する必要があることを決定した場合は、処理システム３０２がサービスを実行するＡＳロジック３０４〜３０６を実行する。ＡＳロジック３０４〜３０６のどれを実行するかは、ＡＳ実行シーケンスのリストによって決まる。さらに、処理システム３０２はＯＣＳ ３２０に接続し、Ｒｏインターフェイス３２２を経由してサービスのオンライン課金を行うＡＳロジック３０４〜３０６を実行する。より具体的には、ＡＳ ロジック３０４〜３０６はＯＣＳ ３２０内のセッションベースの課金機能３２４に接続する。ＡＳロジック３０４〜３０６は、ＯＣＳ ３２０に対してＤｉａｍｅｔｅｒクレジット管理アプリケーション（Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎ）要求メッセージを送信することによってＯＣＳ ３２０に接続する。ＡＳロジック３０４〜３０６は、Ｄｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージ用の新しいフィールドすなわち拡張フィールドにサービスの課金情報を挿入し、サービスの課金情報をＯＣＳ ３２０に報告する。Ｒｏインターフェイス３２２の新しいフィールドまたは拡張フィールドは、以前は存在しなかったが、本発明ではＩＭＳコール制御ノード３０１または別のシステムあるいはエンティティによって追加されており、Ｒｏインターフェイス３２２を経由してサービスあたりのオンライン課金が可能になっている。

ＡＳマネージャ３７０がコール・メッセージをゲートウェイ・ロジック３０８で処理する必要があることを決定した場合は、処理システム３０２がコール・セッション制御を行うゲートウェイ・ロジック３０８を実行する。さらに、処理システム３０２はＯＣＳ ３２０に接続し、Ｒｏインターフェイス３２２を経由してコール・セッションのオンライン課金を行うゲートウェイ・ロジック３０８を実行する。

図４は、本発明の１つの実施形態においてＩＭＳコール制御ノード３０１におけるコール制御を示している。本実施形態において、コア・サービス制御ロジックはコール制御ソフトウェア３５２内でルール・セットとして定義される。個々のアプリケーション・サービスには独自のサービス・ルールがある。すべてのポリシー・ルールは、コール制御ソフトウェア３５２からアクセスできるポリシー・リポジトリに格納される。ポリシー・リポジトリ内のルールは、時間に関するルール、場所に関するルール、発呼側に関するルール、被呼側に関するルール、閉じたユーザー・グループに関するルール、セッション処理に関するルール、ＱｏＳに関するルール、メディア・コンポーネントに関するルールなどのさまざまなカテゴリに分類される。

ＡＳロジック３０４〜３０６内のポリシー実行点（ＰＥＰ：ｐｏｌｉｃｙ ｅｎｆｏｒｃｅｍｅｎｔ ｐｏｉｎｔ）は、コール制御ソフトウェア３５２内のポリシー決定点（ＰＤＰ：ｐｏｌｉｃｙ ｄｅｃｉｓｉｏｎ ｐｏｉｎｔ）と通信し、決定要求を予約する。ＰＤＰはポリシー・リポジトリにアクセスし、対応するルールを取得し、これを評価して決定応答を決定する。決定応答が得られると、ＡＳロジック３０４〜３０６はサービス制御とオンライン課金に関する決定を実行する機能を呼び出す。

サービス・ポリシー管理において、ルールは条件リスト（以下のＣｏｎｄｉｔｉｏｎ＿Ｌｉｓｔ）と一連のアクション（以下のＳｅｑｕｅｎｃｅ＿Ａｃｔｉｏｎｓ）として表現される。
ＩＦ Ｃｏｎｄｉｔｉｏｎ＿Ｌｉｓｔ
ＴＨＥＮ
Ｓｅｑｕｅｎｃｅ＿Ａｃｔｉｏｎｓ
ＥＮＤ ＩＦ

条件リストは、ＢＯＯＬＥＡＮ演算子、ＣＮＦ（Ｃｏｎｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ：乗法標準形）のＡＮＤ、ＯＲ、ＮＯＴによって連結された条件のリストで構成される。ルールが呼び出されると、ＰＤＰでルールの条件が評価される。ルールの条件が一致すると、ルールに指定したアクションが順に実行される。

たとえば、コール・プレゼンス（ｃａｌｌ ｐｒｅｓｅｎｃｅ）・アプリケーション・サービスを使用すると、このサービスは加入者の着信コールを曜日、時刻、発呼側ロールに基づいてさまざまな場所にルーティングする。以下で、ＩＭＳコール制御のコール・プレゼンスに関するいくつかの詳細なルールについて説明する。

時刻に関するカテゴリは次のルールに従って決定する。

IF Day_of_Week="Monday" AND Begin_Time="8:30AM" AND End_Time="5:30PM"
THEN Time_Category="Working Hour"
END IF
IF Day_of_Week="Monday" AND Begin_Time="5:31PM" AND End_Time="11:30PM"
THEN Time_Category="Family Hour"
END IF

加入者１３５７９８４８が着信するＩＭＳコールを受信する場合に、発呼側ロールは次のルールに従って決定する。

IF Call_Direction="Incoming" AND Called_Party_Number=13579848 AND Calling_Party_Number=13599090 THEN Calling_Party_Role="Boss" END IF
IF Call_Direction="Incoming" AND Called_Party_Number=13579848 AND Calling_Party_Number=13599091 THEN Calling_Party_Role="Colleague" END IF

加入者１３５７９８４８のプレゼンスは次のルールによって決定される。

IF Time_Category="Working Hour" And Calling_Party_Category="Boss" THEN Ring Call to "Personal Phone"
THEN Ring Call to "Personal Phone" THEN Ring Call to "Voice Mail Box" END IF
IF Time_Category="Family Hour" And Calling_Party_Category="Boss" THEN Ring Call to "Personal Phone"
THEN Ring Call to "Voice Mail Box"
END IF
IF Time_Category="Family Hour" And Calling_Party _Category="Colleague"
THEN Ring Call to "Voice Mail Box"
END IF

図５は、本発明の１つの例示的な実施形態において、トリガー・ソフトウェア３５３を実行してオンライン課金を行う方法５００を示す流れ図である。方法５００では、処理システム３０２はトリガー・ソフトウェア３５３を実行し、以下のように動作する。ステップ５０２で、トリガー・ソフトウェア３５３はＣＳＣＦ ３１０からＩＳＣインターフェイス３１２を経由してコール・セッションの第１のメッセージを受信する。コール・セッションはあらかじめ確立されていてもよいし、第１のメッセージで開始されてもよい。第１のメッセージは、ＳＩＰ ＩＮＶＩＴＥメッセージなどのＳＩＰメッセージでも、別のプロトコルのメッセージでもよい。ステップ５０４で、トリガー・ソフトウェア３５３は第１のメッセージを処理し、ＯＣＳ ３２０に接続してコール・セッションのオンライン課金を行うかどうかを決定する。ステップ５０４で、トリガー・ソフトウェア３５３はルールを識別し、このルールに基づいて第１のメッセージを処理する。たとえば、ルールには１つまたは複数の条件を指定できる。第１のメッセージに関する条件が満たされると、トリガー・ソフトウェア３５３はそのルールで定義されたアクションを実行する。アクションの１つは、ＯＣＳ ３２０に接続してオンライン課金を実行することでもよい。このルールベースのアプローチによって、トリガー・ソフトウェア３５３はＯＣＳ ３２０に接続して課金レコードを報告する場合の条件を柔軟に定義できる。

ＯＣＳ ３２０に接続しないと決定した場合は、トリガー・ソフトウェア３５３がステップ５０６でＣＳＣＦ ３１０からの次のメッセージを待機する。ＯＣＳ ３２０に接続すると決定した場合は、ステップ５０８でトリガー・ソフトウェア３５３がＯＣＳ ３２０に送信する課金要求を含む第２のメッセージを生成する。第２のメッセージの１つの例は、クレジット管理要求（ＣＣＲ）である。ステップ５１０で、トリガー・ソフトウェア３５３はＩＳＣプロトコルによる第１のメッセージのフィールドをＲｏプロトコルによる第２のメッセージのフィールドにマップする。ステップ５１２で、トリガー・ソフトウェア３５３はＲｏインターフェイス３２２を経由してＯＣＳ ３２０に第２のメッセージを送信する。第２のメッセージは、コール・セッションの加入者の確認、加入者のプリペイド残高（ｐｒｅ−ｐａｉｄ ｂａｌａｎｃｅ）の確認、コール・セッション情報およびコール・セッションの料金の決定、コール・セッションの単位の付与、加入者のアカウントから単位数の減分、あるいは他の任意のオンライン課金機能など、オンライン課金機能を実行するための該当する情報をＯＣＳ ３２０に提供する。

ＯＣＳ ３２０が１つまたは複数の課金機能を実行するのに応答して、トリガー・ソフトウェア３５３は第２のメッセージに応答してＯＣＳ ３２０から第３のメッセージを受信する（ステップ５１４）。第３のメッセージで、ＯＣＳ ３２０は加入者がコール・セッションを開始し、維持するのに十分な数の単位を備えているかどうか、コール・セッションの課金を許可するか拒否するか、あるいはコール・セッションのオンライン課金に関する他の任意の情報を指定できる。ステップ５１６で、トリガー・ソフトウェア３５３はＯＣＳ ３２０からのコール・セッションの課金が許可されたか拒否されたかを示す第４のメッセージを生成し、ＩＳＣインターフェイス３１２を経由してＣＳＣＦ ３１０にこの第４のメッセージを送信する。

図６は、本発明の１つの例示的な実施形態において、トリガー・ソフトウェア３５３によってトリガーする方法をさらに示している。処理システム３０２はトリガー・ソフトウェア３５３を実行し、加入者はオンライン課金を利用できる。本実施形態において、課金トリガー・ポイントはＳＩＰ／ＳＤＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ／Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）メッセージに一致するルール群、すなわちＳＩＰメソッド・ルール（ＳＩＰ ｍｅｔｈｏｄ ｒｕｌｅ）、要求ＵＲＩルール（Ｒｅｑｕｅｓｔ−ＵＲＩ ｒｕｌｅ）、ＳＩＰヘッダー・ルール（ＳＩＰ ｈｅａｄｅｒ ｒｕｌｅ）、セッション・ケース・ルール（Ｓｅｓｓｉｏｎ Ｃａｓｅ ｒｕｌｅ）、または、セッション記述ルール（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ ｒｕｌｅ）として定義される。課金トリガー・ポイントによって、ＩＭＳコール制御ノード３０１からＯＣＳ ３２０に報告する次の情報、すなわち（１）ＩＭＳコールに関する基本的な情報、（２）ＩＭＳセッション内でのメディア・コンポーネントの更新、（３）ＩＭＳセッション内でのＱｏＳの更新、および（４）ＩＭＳセッション内でのモバイル・ロケーションの更新が有効になる。

ポリシー・ルールは、トリガー・ソフトウェア３５３からアクセスできるリポジトリに格納される。ルールは条件リスト（以下のＣｏｎｄｉｔｉｏｎ＿Ｌｉｓｔ）と一連のアクション（以下のＳｅｑｕｅｎｃｅ＿Ａｃｔｉｏｎｓ）として表現される。たとえば、ルールは次のように表現されうる。
IF Condition_List
THEN
Sequence_Actions
END IF

条件リストは、ＢＯＯＬＥＡＮ演算子、ＣＮＦ（Ｃｏｎｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ：乗法標準形）のＡＮＤ、ＯＲ、ＮＯＴで構成される。ルールが呼び出されると、ルールの条件が評価される。ルールの条件が一致する場合は、ルールに指定したアクションが順に実行される。

本実施形態において、課金トリガー・ポイントは、ＩＮＴＥＲＲＵＰＴタイプ、ＮＯＴＩＦＹタイプ、ＮＵＬＬタイプ（トリガーを装備しない）の３種類のモニタ・タイプで定義される。トリガー・ポイントがＩＮＴＥＲＲＵＰＴタイプとして構成されており、トリガー基準が一致する場合は、ＩＭＳコール制御ノード３０１はＩＭＳセッションの処理を中断し、ＯＣＳ ３２０からの命令を待機する。トリガー・ポイントがＮＯＴＩＦＹタイプとして構成されており、トリガー基準が一致する場合は、ＩＭＳコール制御ノード３０１がＯＣＳ ３２０にセッション情報を送信し、セッションの処理を継続する。課金トリガーがＩＭＳコール制御ノード３０１に装備されていない場合は、ＩＭＳコール制御ノード３０１がＳＩＰメッセージをＣＳＣＦ ３１０に返し、課金制御に関係なく現在のセッションを継続する。以下にトリガーの例を示す。

IF SIP_Method="INVITE" AND Call_Status="NULL" AND Trigger_Point_Type=”INTERRUPT"
THEN
Hold on the current session
Send "CCR [INITIAL]" charging report to OCS
Start timer to wait "CCA [INITIAL]" from OCS
END IF
IF SIP_Method="200" AND Call_Status="WAIT_FOR_CALL_ANSWER" AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait for "CCA [UPDATE]" from OCS
END IF

図７は、本発明の１つの例示的な実施形態において予算管理ソフトウェア３５４を実行する方法７００を示している。ステップ７０２で、予算管理ソフトウェア３５４はトリガー・ソフトウェア３５３がＯＣＳ ３２０に課金要求メッセージを送信していることを示すメッセージをトリガー・ソフトウェア３５３から受信する。ステップ７０４で、トリガー・ソフトウェア３５３からメッセージを受信するのに応答して予算管理ソフトウェア３５４は初期メッセージを生成し、Ｒｏインターフェイス３２２を経由してＯＣＳ ３２０にこの初期メッセージを送信する。初期メッセージは、ＯＣＳ ３２０からクォータ単位数（ｑｕｏｔａ ａｍｏｕｎｔ ｏｆ ｕｎｉｔｓ）を要求する。初期メッセージは、さらに加入者を識別し、加入者のアカウントを識別してアカウントの残高を確認し、さらに予算管理ソフトウェア３５４に割り当てるクォータ単位数を確認するための適切な情報をＯＣＳ ３２０に提供する。「単位」という用語は、加入者の残高を表す場合に使用され、分や通貨など、任意の測定単位を表すことができる。初期メッセージはＣＣＲメッセージを備えていてもよい。

ステップ７０６で、予算管理ソフトウェア３５４は予算管理ソフトウェア３５４に割り当てられたコール・セッションのクォータ単位数を示すＯＣＳ ３２０からの応答メッセージを受信する。クォータ単位数は、ＯＣＳ ３２０で許可または提供された任意の数量を備えている。クォータ単位数は、必ずしも加入者のアカウントの残高合計を示すわけではない。応答メッセージはＣＣＡメッセージを備えていてもよい。ステップ７０８で、予算管理ソフトウェア３５４はコール・セッション中に消費される単位数を監視する。

コール・セッション中にクォータ単位数が消費された場合、またはトリガー・ソフトウェア３５３から別のメッセージを受信した場合は、予算管理ソフトウェア３５４が中間メッセージを生成し、Ｒｏインターフェイス３２２を経由してこの一時的なメッセージをＯＣＳ ３２０に送信する（ステップ７１０）。この中間メッセージは消費された単位数を示している。中間メッセージは、ＯＣＳ ３２０から新しいクォータ単位数も要求する。ステップ７１２で、予算管理ソフトウェア３５４に割り当てられたコール・セッションに関する別のクォータ単位数を示すＯＣＳ３２０からの応答メッセージを受信する。ステップ７０８に与えられるように、予算管理ソフトウェア３５４はコール・セッション中に消費される単位数を監視する。

予算管理ソフトウェア３５４がトリガー・ソフトウェア３５３からコール・セッションが終了中であることまたは終了したことを示すメッセージを受信した場合は、ステップ７１４で予算管理ソフトウェア３５４が最終メッセージを生成し、Ｒｏインターフェイス３２２を経由してＯＣＳ ３２０にこの最終メッセージを送信する。最終メッセージは、コール・セッションで使用した単位数の合計を報告する。

図８は、本発明の１つの例示的な実施形態において、予算管理ソフトウェア３５４がＯＣＳ ３２０と通信する方法を示している。予算管理ソフトウェア３５４は、ドラフトＩＥＴＦ Ｄｉａｍｅｔｅｒクレジット管理アプリケーション・プロトコルで定義するＣｒｅｄｉｔ−Ｃｏｎｔｒｏｌ−Ｒｅｑｕｅｓｔ（ＣＣＲ）およびＣｒｅｄｉｔ−Ｃｏｎｔｒｏｌ−Ａｎｓｗｅｒ（ＣＣＡ）の拡張であるＲｏインターフェイス３２２を経由してＯＣＳ ３２０と通信する。予算管理ソフトウェア３５４は、ＩＭＳコール制御ノード３０１とＯＣＳ ３２０の間のＲｏインターフェイス３２２を経由した一連の「インターロゲーション（ｉｎｔｅｒｒｏｇａｔｉｏｎｓ）」に基づいている。インターロゲーションには、１つの初期インターロゲーション、１つまたは複数の中間インターロゲーション、１つの最終インターロゲーションがある。個々のインターロゲーションはＣＣＲとＣＣＡのペアで構成される。

初期インターロゲーション（すなわちＣＣＲ［ＩＮＩＴＩＡＬ］とＣＣＡ［ＩＮＩＴＩＡＬ］）は、初期メッセージ（すなわちＣＣＲ［ＩＮＩＴＩＡＬ］）をＯＣＳ ３２０に送信し、ＯＣＳ ３２０からクォータ単位数を要求する。予算管理ソフトウェア３５４は、予約されたクォータ単位数を示す応答メッセージ（すなわちＣＣＡ［ＩＮＩＴＩＡＬ］）をＯＣＳ ３２０から受信する。

予約されたクォータが定義されたしきい値まで消費された場合、または次の課金ポイントがトリガーされた場合は、予算管理ソフトウェア３５４がＯＣＳ ３２０に中間インターロゲーション（すなわちＣＣＲ［ＵＰＤＡＴＥ］とＣＣＡ［ＵＰＤＡＴＥ］）としての中間メッセージを送信し、現在の課金ポイントまでの実際のクォータ単位数を報告する。予算管理ソフトウェア３５４は、次の課金ポイント用の新しいクォータ単位数も要求する。最終インターロゲーション（すなわちＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］とＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］）で、予算管理ソフトウェア３５４はＩＭＳコール・セッションで消費された単位数の合計を報告する。ＯＣＳ ３２０に接続するときに、ゲートウェイ・ロジック３０８はＩＳＣメッセージのフィールドをＲｏメッセージのフィールドにマップし、コール・セッションの課金要求を提示できる。ＡＳロジック３０４〜３０６がＲｏインターフェイス３２２を経由してＯＣＳ ３２０に接続する場合に、その時点ではＡＳロジック３０４〜３０６で提供するサービスの課金要求のフィールドはない。ＡＳロジック３０４〜３０６でさまざまなサービス実行する場合は、異なるサービスの利用に対しては異なるオンライン課金を実行してもよい。

図９は、本発明の１つの例示的な実施形態におけるＲｏプロトコルの新しいフィールドを示している。ＩＭＳコール制御ノード３０１は、サービスごとに独自のオンライン課金をサポートする。このようなシナリオの最適なサポートを実現するために、サービスの課金要求ごとに複数のＲｏ要求を送信する代わりに、ＩＭＳコール制御ノード３０１はＭｕｌｔｉｐｌｅ−Ｓｅｒｖｉｃｅ−Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ（ＭＳＣＣ）Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ（ＡＶＰ）をサポートしており、複数のサービスの課金を含む１つのＤｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージをＯＣＳ ３２０に送信する。ＩＭＳコール制御ノード３０１では、各サービスがサービス識別子（ＩＤ）で識別される。課金特性の同じ複数のサービスは、１つの評価グループ（ｒａｔｉｎｇ ｇｒｏｕｐ）にまとめることができる。評価グループを決定するルールは、サービスＩＤとサービス・パラメータに基づいている。抽象評価グループのルールは次のように表現できる。
IF Service_ID AND IMS_Parameter
THEN Rating Group
END IF

３ＧＰＰで定義するＲｏインターフェイスは、ＩＥＴＦのクレジット管理アプリケーション・プロトコルの拡張に基づいており、アプリケーション・サービス統合サポートに適合しない。したがって、ＩＭＳコール制御ノード３０１は、新しい動的課金トリガー・ポイントＡＶＰを定義し、動的課金レポートをサポートするようにＭｕｌｔｉｐｌｅ−Ｓｅｒｖｉｃｅ−Ｃｒｅｄｉｔ−Ｃｏｎｔｒｏｌ（ＭＳＣＣ）ＡＶＰを拡張する。ＩＭＳコール制御ノード３０１がＲｏ応答から動的課金ポイントを取得した場合に、ＩＭＳコール制御ノード３０１は課金レコード・レポートのフィルタをルール・リポジトリに動的に適用する。進行中のメッセージが後に続く場合は、ゲートウェイ・ロジック３０８のＰＥＰがＰＤＰに対してＩＭＳコール情報を評価するように要求する。課金レポート・フィルタ・ルールに一致する場合は、ＩＭＳコール制御ノード３０１がＯＣＳ ３２０に課金要求を送信することを決定する。

図１０は、ＣＳＣＦ ３１０とＩＭＳコール制御ノード３０１の間でＳＩＰメッセージのルーティングを実装するためのループ・アラウンド・メカニズムを示している。ループ・アラウンド・メカニズムによって、ＩＭＳコール制御ノード３０１はＣＳＣＦ ３１０における通常のセッション制御を中断せずにセッション課金制御を実行できる。

ＣＳＣＦ ３１０がＳＩＰメッセージを受信するときに、ＣＳＣＦ ３１０はＳＩＰメッセージをＩＭＳコール制御ノード３０１にルーティングしてセッション制御を行う。セッション課金制御を完了すると、ＩＭＳコール制御ノード３０１は同じＳＩＰメッセージをＣＳＣＦ ３１０に戻るようにルーティングする。このように、ＣＳＣＦ ３１０とＩＭＳコール制御ノード３０１とのメッセージのやり取りはループする。

ループバック機能を実行するために、ＳＩＰ要求メッセージはモバイル・ステーションＡからＣＳＣＦ ３１０にルーティングされた場合に、ＣＳＣＦ ３１０はＳＩＰ要求メッセージのＶｉａフィールドに自らのアドレスを追加する。別の実施形態では、ＳＩＰ要求メッセージの他のフィールドを使用してもよい。次に、ＣＳＣＦ ３１０はＳＩＰ要求メッセージをＩＭＳコール制御ノード３０１にルーティングする。セッション課金制御の処理を完了すると、ＩＭＳコール制御ノード３０１は、ＣＳＣＦ ３１０がアドレスを追加したＶｉａフィールドの上にあるＶｉａフィールドに、自らのアドレスを追加する。さらに、ＩＭＳコール制御ノード３０１は、ＳＩＰ要求メッセージをＣＳＣＦ ３１０に戻るようにルーティングし、さらなる制御処理を行う。ＣＳＣＦ ３１０がＳＩＰ要求メッセージをルーティングするときに、ＣＳＣＦ ３１０はＩＭＳコール制御ノード３０１のアドレスの上にあるＶｉａフィールドに、もう一度自らのアドレスを追加する。ＳＩＰメッセージをモバイル・ステーションＢにルーティングする場合は、ＳＩＰメッセージのヘッダーに少なくとも３つのＶｉａフィールドが存在する。したがって、ＣＳＣＦ→ＩＭＳゲートウェイ・システム→ＣＳＣＦというＶｉａフィールドのループが存在する。

ＳＩＰ応答メッセージがモバイル・ステーションＢからＣＳＣＦ ３１０に戻るようにルーティングされると、ＣＳＣＦ ３１０は要求された任意の機能を実行し、Ｖｉａフィールドの一番上のアドレス（ＣＳＣＦ ３１０のアドレスの第１のインスタンス）を削除する。ここで、ＣＳＣＦ ３１０はＳＩＰ応答メッセージをＶｉａフィールドの次のアドレス（ＩＭＳコール制御ノード３０１のアドレス）にルーティングする。ＩＭＳコール制御ノード３０１は要求された任意の機能を実行し、Ｖｉａフィールドの一番上のアドレス（自らのアドレス）を削除する。次に、ＩＭＳコール制御ノード３０１はＳＩＰ応答メッセージをＣＳＣＦ ３１０にルーティングする。ＣＳＣＦ ３１０は要求された任意の機能を実行し、Ｖｉａフィールドの残りのアドレス（ＣＳＣＦ ３１０のアドレスの第２のインスタンス）を削除する。さらに、ＣＳＣＦ ３１０はＳＩＰ応答メッセージをモバイル・ステーションＡにルーティングする。

ＩＭＳコール制御ノード３０１は多くの利点を提供する。ＡＳロジック３０４〜３０６とゲートウェイ・ロジック３０８を統合すると、統合によってＩＭＳネットワーク・トポロジが簡素化され、ＣＳＣＦ ３１０とＯＣＳ ３２０の間のコール・トラフィックが削減される。また、統合することでＩＭＳコール制御ノード３０１が提供するサービスの性能が向上し、応答時間が短くなる。さらに、ＩＭＳコール制御ノード３０１は、Ｒｏプロトコルの拡張を使用することにより、ＡＳロジック３０４〜３０６が提供する複数のサービスのオンライン課金が可能になる。ＩＭＳコール制御ノード３０１では、サービスの課金だけでなく、リアルタイムのセッションベースのオンライン課金も可能である。

以下に、ＩＭＳネットワーク３００の動作を示す３つの例、すなわちＩＭＳコール発信シナリオ、コール終了シナリオ、コール・リダイレクト・シナリオを示す。

例１
図１１は、図３に関連して説明したＩＭＳネットワーク３００のＩＭＳコール発信シナリオを示している。開始するには、発呼側（発呼側ステーション）がＣＳＣＦ ３１０にＳＩＰ ＩＮＶＩＴＥメッセージを送信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１にＩＮＶＩＴＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、アプリケーション・サービス（ＡＳ）ロジックを呼び出して以下の作業を実行する。ＩＭＳコール制御ノード３０１は、被呼側の番号が短縮された番号であることを確認し、短縮ダイヤル（ＡＢＤ：Ａｂｂｒｅｖｉａｔｅｄ Ｄｉａｌｉｎｇ）アプリケーション・ロジックを呼び出して短縮された番号を標準のコール番号に変換する。ＡＢＤアプリケーション・ロジックの課金ポリシー実行点（ＰＥＰ）は、課金ポリシー決定点（ＰＤＰ）を要求し、ＡＢＤ番号の変換に対して評価グループ１として課金する（たとえば、ＡＢＤ番号の変換に対しては一様に課金する）ことを決定する。ＡＢＤ番号の変換を完了すると、ＩＭＳコール制御ノード３０１はこのセッションを標準のセッションとみなし、セッション制御を実行する。ＩＭＳコール制御ノード３０１はＩＭＳゲートウェイ・ロジックを呼び出し、ＩＭＳセッション制御の課金ＰＥＰは課金ＰＤＰを要求し、さらにこのセッションに対して評価グループ２ととして課金することを決定する。ポリシー管理において、課金トリガー・ポイントはＩＮＴＥＲＲＵＰＴとして構成される。ＩＭＳコール制御ノード３０１は、現在のセッションに対してタイマーを起動し、継続する。ＰＤＰの課金トリガー・ルールは次のように表現できる。
IF SIP_Method="INVITE" AND Call_Status="NULL"
AND Trigger_Point_Type="INTERRUPT"
THEN
Hold on the current session
Send "CCR [INITIAL]" charging report to OCS
Start timer to wait for the "CCA [INITIAL]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＤｉａｍｅｔｅｒクレジット管理要求（ＣＣＲ：Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ｒｅｑｕｅｓｔ）［ＩＮＩＴＩＡＬ］メッセージを送信してクレジット・リザーブ（ｃｒｅｄｉｔ ｒｅｓｅｒｖｅ）を実行する。ＣＣＲメッセージには、２つのＭＳＣＣ ＡＶＰが含まれる。１つのＭＳＣＣ ＡＶＰは評価グループ１のクレジット・リザーブ用である（たとえば、ＡＢＤ番号変換にする一様の課金）。もう１つのＭＳＣＣ ＡＶＰは評価グループ２のクレジット・リザーブ用である（たとえば、セッション・クレジットの事前の許可によって発呼側が利用できる最大セッション持続時間の概算値）。

ＯＣＳ ３２０は、評価グループごとにそれぞれのクォータ単位数を付与し、各評価グループのＭＳＣＣ ＡＶＰで付与されたクォータを設定する。ＯＣＳ ３２０によって、各ＭＳＣＣ ＡＶＰの下にサービスに固有の課金トリガー・サブＡＶＰが配置される。ここで、ＯＣＳ ３２０はＩＭＳコール制御ノード３０１にＤｉａｍｅｔｅｒクレジット管理応答（ＣＣＡ：Ｃｒｅｄｉｔ Ｃｏｎｔｒｏｌ Ａｎｓｗｅｒ）［ＩＮＩＴＩＡＬ］メッセージを送信する。

ＩＭＳコール制御ノード３０１がＣＣＡメッセージを受信し、セッションが許可されるかどうかを決定する場合に、ＩＭＳコール制御ノード３０１は現在のセッションの処理を継続し、ＣＳＣＦ ３１０を経由して被呼側にＩＮＶＩＴＥメッセージを送信する。

被呼側がコールに応答する場合は、被呼側がＣＳＣＦ ３１０に２００ ＯＫメッセージを送信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１に２００ ＯＫメッセージを送信する。ＩＭＳコール制御ノード３０１が２００ ＯＫメッセージを受信する場合に、ＩＭＳコール制御ノード３０１は課金ポリシー管理を要求し、課金ルールが次のように評価される。
IF SIP_Method="200" AND Call_Status="WAIT_FOR_CALL_ANSWER" AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait for "CCA [UPDATE]" from OCS
END IF

課金トリガー・タイプは”ＮＯＴＩＦＹ”なので、ＩＭＳコール制御ノード３０１は既存のセッションを中断しない。ＩＭＳコール制御ノード３０１はＣＳＣＦ ３１０に２００ ＯＫメッセージを送信し、セッションを継続する。

次に、ＩＭＳコール制御ノード３０１はＯＣＳ ３２０にＤｉａｍｅｔｅｒ ＣＣＲ［ＵＰＤＡＴＥ］メッセージを送信して課金レコードを報告する。評価グループ１のＭＳＣＣ ＡＶＰは、セッションが正常に応答されたので、クレジット・リザーブを引き落とすようにＯＣＳ ３２０に指示する。ＡＢＤの一様な課金が残高から引き落とされる。この時点でセッションの応答時間が経過しているので、評価グループ２のＭＳＣＣ ＡＶＰは、セッション・クレジットを再認可するようにＯＣＳ ３２０に指示する。ＯＣＳ ３２０は、現在のセッションの応答時間から再びクレジット・リザーブを行う。ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＵＰＤＡＴＥ］メッセージを送信する。付与されたクォータと有効期限は、評価グループ２のＭＳＣＣ ＡＶＰで指定される。拡張されたトリガー・ポイントＡＶＰも、ＯＣＳ ３２０によって評価グループ１のＭＳＣＣ ＡＶＰに配置される。ＣＣＡメッセージを受信すると、ＩＭＳコール制御ノード３０１はポリシー・リポジトリ内の課金フィルタ基準を動的に適用する。ＩＭＳコール制御ノード３０１は、セッション制御タイマーを起動し、付与されたクォータに基づいてセッションをリアルタイムで監視する。

２００ ＯＫメッセージを受信すると、発呼側はＳＩＰ ＡＣＫメッセージを送信する。このメッセージは、ＣＳＣＦ ３１０からＩＭＳコール制御ノード３１０に転送される。ＩＭＳコール制御ノード３０１はＰＥＰを呼び出し、ＯＣＳ ３２０に課金レポートを送信するかどうかを評価するようにＰＤＰに要求する。この例では、次の課金フィルタ・ルールが適合する。
IF SIP_Method="ACK" AND Call_Status="ANSWERED"
AND Trigger_Point_Type="NULL"
THEN
Continue the current session.
END IF

このメッセージはトリガーが装備されていないので、ＩＭＳコール制御ノード３０１はＳＩＰメッセージを継続し、ＣＳＣＦ ３１０を経由して被呼側にＡＣＫメッセージを送信する。この時点で許可されたクォータを使い果たしており、ＩＭＳコール制御ノード３０１はＣＣＲ［ＵＰＤＡＴＥ］メッセージを経由してＯＣＳ ３２０に使用されたクォータを送信し、さらに次の新しいクォータを割り当てるように要求する。ＯＣＳ ３２０は、発呼側に十分なクレジットがあるかどうかを判定し、別の新しいクォータを評価グループ２に割り当て、さらにＣＣＡ［ＵＰＤＡＴＥ］メッセージを経由してＩＭＳコール制御ノード３０１に新しいクォータを送信する。ＩＭＳコール制御ノード３０１は、新しいクォータに対してセッション制御タイマーをリセットし、このセッションをリアルタイムで監視する。

現在のセッションの終了を開始するために、発呼側はＢＹＥメッセージを送信し、ＣＳＣＦ ３１０を経由してＩＭＳコール制御ノード３０１でこれを受信する。ＩＭＳコール制御ノード３０１はＰＥＰを呼び出し、次の課金フィルタ・ルールを適用するようにＰＤＰに要求する。
IF SIP_Method="BYE " AND Call_Status="In_Progess"
AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [TERMINATION]" charging report to OCS
Start timer to wait "CCA [TERMINATION]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＳＩＰメッセージの処理を継続し、ＣＳＣＦ ３１０にＢＹＥメッセージを送信する。ＩＭＳコール制御ノード３０１はＢＹＥメッセージを受信した時点までに消費したクォータを計算し、セッション制御タイマーを停止し、さらにＯＣＳ ３２０にＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを送信して消費されたクォータを報告する。ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを返し、メッセージを受信したことを示す。被呼側は、ＣＳＣＦ ３１０を経由してＩＭＳコール制御ノード３０１に２００ ＯＫメッセージを返し、被呼側のセッション・リソースが解放されたことを示す。ＩＭＳコール制御ノード３０１は、現在のセッション・ステータスの下にはこの２００ ＯＫメッセージに一致するルールがないと判定するので、このセッションを制御するためのアクションは実行しない。さらに、ＩＭＳコール制御ノード３０１は２００ ＯＫメッセージを送信して発呼側を解放し、セッション・リソースを解放する。

例２
図１２は、図３に関連して説明したＩＭＳネットワーク３００のＩＭＳコール終了シナリオを示している。開始するには、被呼側のＣＳＣＦ ３１０が発呼側からＳＩＰ ＩＮＶＩＴＥメッセージを受信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１にＩＮＶＩＴＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、アプリケーション・サービス（ＡＳ）ロジックを呼び出して以下の作業を実行する。ＩＭＳコール制御ノード３０１はＩＭＳゲートウェイ・ロジックを呼び出し、ＩＭＳセッション制御の課金ＰＥＰは課金ＰＤＰを要求し、さらにこのセッションに対して評価グループ１として課金することを決定する。ポリシー管理において、課金トリガー・ポイントはＩＮＴＥＲＲＵＰＴとして構成される。ＩＭＳコール制御ノード３０１は、現在のセッションに対してタイマーを起動し、継続する。ＰＤＰの課金トリガー・ルールは次のように表現できる。
IF SIP_Method="INVITE" AND Call_Status="NULL"
AND Trigger_Point_Type="INTERRUPT"
THEN
Hold on the current session
Send "CCR [INITIAL]" charging report to OCS
Start timer to wait for the "CCA [INITIAL]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にｉａｍｅｔｅｒ ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージを送信し、評価グループ１のクレジット・リザーブを実行する（たとえば、セッション・クレジットの事前の許可によって被呼側が利用できるセッション持続時間の概算値）。ＯＣＳ ３２０は、評価グループ１にクォータ単位数を付与し、この評価グループのＭＳＣＣ ＡＶＰ内にこの評価グループに付与されたクォータを設定する。ＯＣＳ ３２０には、このＭＳＣＣ ＡＶＰの下のサービスに固有の課金トリガー・サブＡＶＰが配置される。ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＤｉａｍｅｔｅｒ ＣＣＡ［ＩＮＩＴＩＡＬ］メッセージを送信する。

ＩＭＳコール制御ノード３０１がＣＣＡメッセージを受信し、セッションが許可されることを評価する場合に、ＩＭＳコール制御ノード３０１は現在のセッションの処理を継続し、ＣＳＣＦ ３１０を経由して被呼側にＩＮＶＩＴＥ要求を転送する。

被呼側がコールに応答する場合は、被呼側がＣＳＣＦ ３１０に２００ ＯＫメッセージを送信する。ＣＳＣＦ ３１０は、２００ ＯＫメッセージをＩＭＳコール制御ノード３０１に転送する。ＩＭＳコール制御ノード３０１が２００ ＯＫメッセージを受信する場合に、ＩＭＳコール制御ノード３０１は課金ポリシー管理を要求し、課金ルールが次のように評価される。
IF SIP_Method="200" AND Call_Status="WAIT_FOR_CALL_ANSWER" AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait for "CCA [UPDATE]" from OCS
END IF

課金トリガー・タイプは”ＮＯＴＩＦＹ”なので、ＩＭＳコール制御ノード３０１は既存のセッションを中断しない。ＩＭＳコール制御ノード３０１はＣＳＣＦ ３１０に２００ ＯＫメッセージを送信し、セッションを継続する。ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＤｉａｍｅｔｅｒ ＣＣＲ［ＵＰＤＡＴＥ］メッセージを送信してコールの応答時間を報告する。この時点でセッションの応答時間が終了しているので、評価グループ１のＭＳＣＣ ＡＶＰは、セッション・クレジットを再認可するようにＯＣＳ ３２０に指示する。ＯＣＳ ３２０は、現在のセッションの応答時間から再びクレジット・リザーブを行う。

ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＵＰＤＡＴＥ］メッセージを送信する。付与されたクォータと有効期限は、評価グループ２のＭＳＣＣ ＡＶＰに含まれる。拡張されたトリガー・ポイントＡＶＰ（メディア・コンポーネント更新ＡＶＰなど）もＯＣＳ ３２０によってＭＳＣＣ ＡＶＰに配置される。ＣＣＡメッセージを受信すると、ＩＭＳコール制御ノード３０１はポリシー・リポジトリ内の課金フィルタ基準を動的に適用する。ＩＭＳコール制御ノード３０１は、セッション制御タイマーを起動し、付与されたクォータに基づいてセッションをリアルタイムで監視する。

２００ ＯＫメッセージを受信すると、発呼側はＳＩＰ ＡＣＫメッセージを送信する。このメッセージは、ＣＳＣＦ ３１０からＩＭＳコール制御ノード３０１に転送される。ＩＭＳコール制御ノード３０１がＡＣＫメッセージを受信すると、ＩＭＳコール制御ノード３０１はＰＥＰを呼び出し、ＯＣＳ ３２０に課金レポートを送信するかどうかを判定するようにＰＤＰに要求する。この例では、次の課金フィルタ・ルールが適合する。
IF SIP_Method="ACK" AND Call_Status="ANSWERED"
AND Trigger_Point_Type="NULL"
THEN
Continue the current session.
END IF

このメッセージはトリガーが装備されていないので、ＩＭＳコール制御ノード３０１はＳＩＰメッセージを継続し、ＣＳＣＦ ３１０を経由して被呼側にＡＣＫメッセージを送信する。ＩＭＳコール制御ノード３０１は、コール・ステータスをＩｎ Ｐｒｏｇｒｅｓｓに設定する。この時点で、発呼側のメディア・コンポーネントが更新され、発呼側はＣＳＣＦ ３１０にＳＩＰ ＵＰＤＡＴＥメッセージを送信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１にＵＰＤＡＴＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、このセッションのＵＰＤＡＴＥメッセージを評価する。ＩＭＳコール制御ノード３０１は課金ＰＥＰを呼び出してＩＭＳセッション制御を行い、課金ＰＤＰを要求し、さらにこのセッションに対して評価グループ２として課金することを決定する。課金トリガー・ポイントは次のように評価できる。
IF SIP_Method="UPDATE" AND Call_Status="In_Progress" AND Trigger_Point_Type="INTERRUPT"
THEN
Hold on the current session
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait for "CCA [UPDATE]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、評価グループ１に使用したクォータを計算し、Ｄｉａｍｅｔｅｒ ＣＣＲメッセージを送信して課金レコードを報告する。ＣＣＲメッセージには、２つのＭＳＣＣ ＡＶＰが含まれる。１つのＭＳＣＣ ＡＶＰを使用して評価グループ１で使用されたクォータを報告し、ＯＣＳ ３２０内の加入者残高からクレジットを引き落とす。メディア・コンポーネントの更新により、別のＭＳＣＣ ＡＶＰを追加して評価グループ２のクレジットを要求する。

ＩＭＳコール制御ノード３０１がＣＣＡメッセージを受信する場合に、ＩＭＳコール制御ノード３０１は評価グループ２に新しく割り当てられたクォータに対してセッション制御タイマーをリセットする。ＩＭＳコール制御ノード３０１は、ＣＳＣＦ ３１０を経由して被呼側にＵＰＤＡＴＥメッセージを送信する。現在のセッション更新ステータスの下のＡＣＫメッセージについては、ＩＭＳコール制御ノード３０１の課金フィルタ基準がない。ＩＭＳコール制御ノード３０１は、ＡＣＫメッセージを発呼側メッセージに転送し、発呼側から被呼側にＡＣＫメッセージを送信する。

被呼側が現在のセッションを終了すると、被呼側はＣＳＣＦ ３１０を経由してＩＭＳコール制御ノード３０１にＢＹＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、課金ＰＥＰを呼び出して課金ＰＤＰを要求する。課金トリガー・ポイントは次のように評価される。
IF SIP_Method="BYE " AND Call_Status="In_Progess"
AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [TERMINATION]" charging report to OCS
Start timer to wait "CCA [TERMINATION]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＳＩＰメッセージ処理の継続を許可し、ＣＳＣＦ ３１０を経由して発呼側にＢＹＥメッセージを送信する。ＩＭＳコール制御ノード３０１はＢＹＥメッセージを受信した時点までに使用したクォータを計算し、セッション制御タイマーを停止する。ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを送信して消費したクォータを報告する。ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを送信し、メッセージを受信したことを示す。発呼側は２００ ＯＫメッセージを返し、発呼側のセッション・リソースが解放されたことを示す。ＩＭＳコール制御ノード３０１は、現在のセッション状況下ではこの課金レポートに関するメッセージに一致するルールがないと判定するので、このセッションを制御するためのアクションは実行しない。ＩＭＳコール制御ノード３０１は、２００ ＯＫメッセージを送信してセッション・リソースを解放する。

例３
図１３は、図３に関連して説明したＩＭＳネットワーク３００のコール・リダイレクト・シナリオを示している。開始するには、発呼側（または発呼側ステーション）がＣＳＣＦ ３１０にＳＩＰ ＩＮＶＩＴＥメッセージを送信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１にＩＮＶＩＴＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、以下の作業を行うアプリケーション・サービス（ＡＳ）ロジックを呼び出す。ＩＭＳコール制御ノード３０１はＩＭＳゲートウェイ・ロジックを呼び出し、ＩＭＳセッション制御の課金ＰＥＰは課金ＰＤＰを要求し、さらにこのセッションの課金を評価グループ１と決定する。ポリシー管理において、課金トリガー・ポイントはＩＮＴＥＲＲＵＰＴとして構成される。ＩＭＳコール制御ノード３０１は、現在のセッションに対してタイマーを起動し、継続する。ＰＤＰの課金トリガー・ルールは次のように表現できる。
IF SIP_Method="INVITE" AND Call_Status="NULL"
AND Trigger_Point_Type="INTERRUPT"
THEN
Hold on the current session
Send "CCR [INITIAL]" charging report to OCS
Start timer to wait for the "CCA [INITIAL]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＤｉａｍｅｔｅｒ ＣＣＲ［ＩＮＩＴＩＡＬ］メッセージを送信し、評価グループ１のクレジット・リザーブを実行する（たとえば、セッション・クレジットの事前の許可によって被呼側が利用できるセッション持続時間の概算値）。ＯＣＳ ３２０は、評価グループ１にクォータ単位数を付与し、この評価グループのＭＳＣＣ ＡＶＰ内にこの評価グループに付与されたクォータを設定する。ＯＣＳ ３２０には、このＭＳＣＣ ＡＶＰの下のサービスに固有の課金トリガー・サブＡＶＰが配置される。次に、ＯＣＳ ３２０はＩＭＳコール制御ノード３０１にＣＣＡ［ＩＮＩＴＩＡＬ］メッセージを送信する。ＩＭＳコール制御ノード３０１がＣＣＡメッセージを受信し、セッションが許可されるかどうかを決定する場合に、ＩＭＳコール制御ノード３０１は現在のセッションの処理を継続し、ＣＳＣＦ ３１０を経由して被呼側にＩＮＶＩＴＥメッセージを送信する。

この時点で、発呼側は別のコールを受け付ているので、被呼側はＣＳＣＦ ３１０に４８６ ＢＵＳＹメッセージを送信する。ＣＳＣＦ ３１０は、ＩＭＳコール制御ノード３０１に４８６ ＢＵＳＹメッセージを送信する。ＩＭＳコール制御ノード３０１が４８６ ＢＵＳＹメッセージを受信する場合に、ＩＭＳコール制御ノード３０１は課金ポリシー管理を要求し、課金ルールが次のように評価される。
IF SIP_Method="486" AND Call_Status="WAIT_FOR_CALL_ANSWER" AND Trigger_Point_Type="INTERRUPT"
THEN
Continue the current session.
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait for "CCA [UPDATE]" from OCS
END IF

課金トリガー・タイプは"ＩＮＴＥＲＲＵＰＴ"なので、ＩＭＳコール制御ノード３０１は既存のセッションを中断する。ＩＭＳコール制御ノード３０１は、コール制御処理の現在のセッションを保持する。ＩＭＳコール制御ノード３０１は、被呼側がコール・リダイレクト・サービスを予約したことを確認する。ＰＤＰから次のサービス制御ルールが決定する。
IF Call Status="On_Busy" AND Time_Category="Working Hour" And Calling_Party_Category="Colleague"
THEN Redirect Call to "The phone number of UE2"
END IF

ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＤｉａｍｅｔｅｒ ＣＣＲ［ＵＰＤＡＴＥ］メッセージを送信し、評価グループ２のクレジット・リザーブを行う（たとえば、セッション・クレジットの事前の許可による発呼側から被呼側への最大セッション持続時間の概算値）。

ＯＣＳ ３２０は、評価グループ２のクォータ単位数を付与し、ＭＳＣＣ ＡＶＰ内に評価グループ２内の付与されたクォータを設定する。ＯＣＳ ３２０には、このＭＳＣＣ ＡＶＰの下のサービスに固有の課金トリガー・サブＡＶＰが配置される。ここで、ＯＣＳ ３２０はＩＭＳコール制御ノード３０１にＤｉａｍｅｔｅｒクレジット管理応答（ＣＣＡ）［ＵＰＤＡＴＥ］を送信する。ＩＭＳコール制御ノード３０１は、発呼側に十分なコール・リダイレクトのクォータがあるかどうかを確認し、ＣＳＣＦ ３１０を経由して被呼側にＩＮＶＩＴＥメッセージを送信する。

被呼側がコールに応答し、ＣＳＣＦ ３１０に２００ ＯＫメッセージを送信する。ＣＳＣＦ ３１０は、このメッセージをＩＭＳコール制御ノード３０１に転送する。ＩＭＳコール制御ノード３０１は２００ ＯＫメッセージを受信し、課金ポリシー管理を要求する。課金ルールは次のように評価できる。
IF SIP_Method="200" AND Call_Status="WAIT_FOR_CALL_ANSWER" AND Trigger_Point_Type="NOTIFY"
THEN
Continue the current session.
Send "CCR [UPDATE]" charging report to OCS
Start timer to wait "CCA [UPDATE]" from OCS
END IF

課金トリガー・タイプは"ＮＯＴＩＦＹ"なので、ＩＭＳコール制御ノード３０１は既存のセッションを中断しない。ＩＭＳコール制御ノード３０１はＣＳＣＦ ３１０に２００ ＯＫメッセージを送信し、セッションを継続する。ＩＭＳコール制御ノード３０１は、ＯＣＳ ３２０にＤｉａｍｅｔｅｒ ＣＣＲ［ＵＰＤＡＴＥ］を送信してコール応答時間を報告する。この時点でセッションの応答時間に到達しているので、評価グループ１（発呼側から被呼側へのコールの課金）と評価グループ２（発呼側から被呼側へのコール・リダイレクトのコールの課金）のＭＳＣＣ ＡＶＰは、ＯＣＳ ３２０に対してセッション・クレジットを再認可するように指示する。ＯＣＳ ３２０は、現在のセッションの応答時間から再びクレジット・リザーブを行う。ＩＭＳコール制御ノード３０１は、ＣＳＣＦ ３１０を経由して発呼側に２００ ＯＫメッセージを送信する。

ＣＳＣＦ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＵＰＤＡＴＥ］を送信する。付与された単位と有効期限は、評価グループ１と評価グループ２のＭＳＣＣ ＡＶＰに別々に含まれる。拡張されたトリガー・ポイントＡＶＰも、ＯＣＳ ３２０によってＭＳＣＣ ＡＶＰに配置される。ＣＣＡ応答を受信すると、ＩＭＳコール制御ノード３０１はポリシー・リポジトリ内の課金フィルタ基準を動的に適用する。ＩＭＳコール制御ノード３０１は、セッション制御タイマーを起動し、予約されたクォータに基づいて実行されているセッションをリアルタイムで監視する。

２００ ＯＫメッセージを受信すると、発呼側はＣＳＣＦ ３０１からＳＩＰ ＡＣＫメッセージを送信し、このメッセージがＩＭＳコール制御ノード３１０に転送される。ＩＭＳコール制御ノード３０１はＰＥＰを呼び出し、ＯＣＳ ３２０に課金レポートを送信するかどうかを判定するようにＰＤＰに要求する。この例では、次の課金フィルタ・ルールが適合する。
IF SIP_Method="ACK" AND Call_Status="ANSWERED"
AND Trigger_Point_Type="NULL"
THEN
Continue the current session.
END IF

このメッセージはトリガーが装備されていないので、ＩＭＳコール制御ノード３０１はＳＩＰメッセージを継続し、ＣＳＣＦ ３１０を経由して被呼側にＡＣＫメッセージを送信する。

被呼側が現在のセッションを終了すると、被呼側はＣＳＣＦ ３０１を経由してＩＭＳコール制御ノード３１０にＢＹＥメッセージを送信する。ＩＭＳコール制御ノード３０１は、課金ＰＥＰを呼び出し、課金ＰＤＰを要求する。課金トリガー・ポイントは次のように評価される。
IF SIP_Method="BYE" AND Call_Status="In_Progess"
AND Trigger_Point_Type="NOTIFY"
THEN
Send "CCR[TERMINATION]" charging report to OCS
Start timer to wait "CCA[TERMINATION]" from OCS
END IF

ＩＭＳコール制御ノード３０１は、ＳＩＰメッセージ処理の継続を許可し、ＣＳＣＦ ３１０を経由して発呼側にＢＹＥメッセージを送信する。ＩＭＳコール制御ノード３０１はＢＹＥメッセージを受信した時点までに、評価グループ１と評価グループ２に使用したクォータを計算し、セッション制御タイマーを停止する。ＩＭＳコール制御ノード３０１はＯＣＳ ３２０にＣＣＲ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを送信し、消費したクォータを報告する。ＩＭＳコール制御は、ＣＳＣＦ ３１０を経由して発呼側にＢＹＥメッセージを送信する。ＯＣＳ ３２０は、ＩＭＳコール制御ノード３０１にＣＣＡ［ＴＥＲＭＩＮＡＴＩＯＮ］メッセージを送信し、メッセージを受信したことを示す。発呼側は２００ ＯＫメッセージを返し、発呼側のセッション・リソースが解放されたことを示す。ＩＭＳコール制御ノード３０１は、現在のセッション状況下ではこの課金レポートに関するメッセージに一致するルールがないと判定するので、このセッションを制御するためのアクションは実行しない。ＩＭＳコール制御ノード３０１は２００ ＯＫメッセージを送信してセッション・リソースを解放する。

本発明の１つの例示的な実施形態においてオンライン課金を実行するＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークを示す図である。 本発明の１つの例示的な実施形態においてＩＭＳコール制御ノードを操作する方法を示す流れ図である。 本発明の別の例示的な実施形態においてＩＭＳコール制御ノードを伴うＩＭＳネットワークを示す図である。 本発明の１つの例示的な実施形態においてＩＭＳコール制御ノードで行うコール制御を示す図である。 本発明の１つの例示的な実施形態においてトリガー・ソフトウェアを実行してオンライン課金を行う方法を示す流れ図である。 本発明の１つの例示的な実施形態においてトリガー・ソフトウェアがトリガーする方法を詳細に示す図である。 本発明の１つの例示的な実施形態において予算管理ソフトウェアを実行する方法を示す図である。 本発明の１つの例示的な実施形態において予算管理ソフトウェアがＯＣＳと通信する方法を示す図である。 本発明の１つの例示的な実施形態におけるＲｏプロトコル用の新しいフィールドを示す図である。 ＣＳＣＦとＩＭＳコール制御ノードの間でＳＩＰメッセージのルーティングを実装するためのループ・アラウンド（ｌｏｏｐ ａｒｏｕｎｄ）・メカニズムを示す図である。 本発明の１つの例示的な実施形態におけるＩＭＳネットワークのＩＭＳコール発信シナリオを示すメッセージ・ダイヤグラム（ｍｅｓｓａｇｅ ｄｉａｇｒａｍ）である。 本発明の１つの例示的な実施形態におけるＩＭＳネットワークのＩＭＳコール終了シナリオを示すメッセージ・ダイヤグラムである。 本発明の１つの例示的な実施形態におけるＩＭＳネットワークのコール・リダイレクト・シナリオを示すメッセージ・ダイヤグラムである。 本発明の１つの例示的な実施形態において、ＩＭＳコール制御ノード内のロジックの統合を示す図である。

Claims (10)

1. ＩＭＳネットワーク（１００）においてオンライン課金を実現するＩＰマルチメディア・サブシステム（ＩＭＳ）コール制御ノード（１０１）であって、
   第１のプロトコルに従ってコール・セッション制御機能（ＣＳＣＦ）（１１０）と通信するための第１のインターフェイス（１１２）と、
   第２のプロトコルに従ってオンライン課金サーバー（ＯＣＳ）（１２０）と通信するための第２のインターフェイス（１２２）と、
   前記第１のインターフェイスと前記第２のインターフェイスに接続する処理システム（１０２）と、
   前記処理システムで実行することによって複数のサービスを提供できるアプリケーション・サーバー（ＡＳ）ロジック（１０４〜１０６）と、
   前記処理システムで実行できるゲートウェイ・ロジック（１０８）とを備えており、
   前記処理システムが、前記第１のプロトコルに従って前記ＣＳＣＦから前記第１のインターフェイスを経由してコール・メッセージを受信するとともに、前記コール・メッセージがサービスの要求またはコール・セッション制御の要求であるかを識別することによって、前記ＡＳロジックを実行するか前記ゲートウェイ・ロジックを実行するかを決定し、
   前記コール・メッセージがサービスを要求する場合、次いで、前記処理システムが、前記サービスを実行するとともに前記第２のプロトコルに従って前記第２のインターフェイスを経由して前記ＯＣＳに接続しセッションベースのオンライン課金を行うための前記ＡＳロジックを実行し、
   前記コール・メッセージがコール・セッション制御を要求する場合、次いで、前記処理システムが、前記コール・セッション制御を実行するとともに前記第２のプロトコルに従って前記第２のインターフェイスを経由して前記ＯＣＳに接続しセッションベースのオンライン課金を行うための前記ゲートウェイ・ロジックを実行することを特徴とするＩＭＳコール制御ノード（１０１）。
2. 前記ＡＳロジック（１０４〜１０６）が前記サービスに関する課金情報をＤｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージの拡張フィールドに挿入し、前記ＯＣＳ（１２０）に前記Ｄｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージを送信し、前記サービスに関する課金情報を前記ＯＣＳに報告することによって、前記ＯＣＳに接続しセッションベースのオンライン課金を行うことを、前記処理システムが実行する請求項１に記載のＩＭＳコール制御ノード（１０１）。
3. 前記処理システム（１０２、３０２）が、前記ＩＭＳコール制御ノードを、スタンドアロンのＩＭＳゲートウェイとして構成する前記ＡＳロジック（１０４〜１０６、３０４〜３０６）を無効化するか、または、
   前記処理システム（１０２、３０２）が、前記ＩＭＳコール制御ノードを、スタンドアロンのＡＳとして構成する前記ゲートウェイ・ロジック（１０８、３０８）を無効化する請求項１に記載のＩＭＳコール制御ノード（１０１、３０１）。
4. 複数のサービスを提供する前記ＡＳロジック（１０４〜１０６、３０４〜３０６）および前記ゲートウェイ・ロジック（１０８、３０８）の少なくとも１つによって実行されるアクションのシーケンスを決定する前記コール・メッセージを処理し、
   前記複数のサービスを提供するように実行するアクションの前記シーケンスを示すシーケンスのリストを生成し、
   前記複数のサービスを提供する前記シーケンスのリストに基づいて、前記ＡＳロジックおよび前記ゲートウェイ・ロジックの少なくとも１つを実行するＡＳマネージャをさらに備える請求項１に記載のＩＭＳコール制御ノード（１０１、３０１）。
5. 前記ＡＳマネージャ（１７０、３７０）が、前記複数のサービスを１つの評価グループにまとめ、前記評価グループ内の前記複数のサービスのためにセッションベースのオンライン課金を提供する前記ＯＣＳ（１２０、３２０）へと単一の課金メッセージを発信する請求項４に記載のＩＭＳコール制御ノード（１０１、３０１）。
6. ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークにおいてオンライン課金を実現するＩＭＳコール制御ノードを操作する方法であって、前記ＩＭＳコール制御ノードは、第１のプロトコルに従ってコール・セッション制御機能（ＣＳＣＦ）と通信するための第１のインターフェイスと、第２のプロトコルに従ってオンライン課金サーバー（ＯＣＳ）と通信するための第２のインターフェイスと、前記第１のインターフェイスと前記第２のインターフェイスに接続する処理システムとを備えており、
   前記第１のプロトコルに従って前記ＣＳＣＦから前記第１のインターフェイスを経由してコール・メッセージを受信する工程と、
   前記コール・メッセージがサービスの要求またはコール・セッション制御の要求であるかを識別することによって、アプリケーション・サーバ（ＡＳ）ロジックを実行するかゲートウェイ・ロジックを実行するかを決定する工程と、
   前記コール・メッセージがサービスを要求する場合、次いで、前記サービスを実行するとともに前記第２のプロトコルに従って前記第２のインターフェイスを経由して前記ＯＣＳに接続しセッションベースのオンライン課金を行うための前記ＡＳロジックを実行する工程をさらに備え、
   前記コール・メッセージがコール・セッション制御を要求する場合、次いで、前記コール・セッション制御を実行するとともに前記第２のプロトコルに従って前記第２のインターフェイスを経由して前記ＯＣＳに接続しセッションベースのオンライン課金を行うための前記ゲートウェイ・ロジックを実行する工程をさらに備えることを特徴とする方法。
7. 前記処理システムにおいて前記ＯＣＳに接続する前記ＡＳロジックを実行する工程は、
   前記サービスに関する課金情報をＤｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージの拡張フィールドに挿入する前記ＡＳロジックを実行する工程と、
   前記ＯＣＳに前記Ｄｉａｍｅｔｅｒクレジット管理アプリケーション要求メッセージを送信し、前記サービスに関する課金情報を、セッションベースのオンライン課金のために前記ＯＣＳに報告する前記ＡＳロジックを実行する工程とを備える請求項６に記載の方法。
8. 前記ＩＭＳコール制御ノードを、スタンドアローンのＩＭＳゲートウェイとして構成する前記ＡＳロジックを無効化する工程、または、
   前記ＩＭＳコール制御ノードを、スタンドアローンのＡＳとして構成する前記ゲートウェイ・ロジックを無効化する工程をさらに備える請求項６に記載の方法。
9. 複数のサービスを提供する前記ＡＳロジックおよび前記ゲートウェイ・ロジックの少なくとも１つによって実行されるアクションのシーケンスを決定する前記コール・メッセージを処理する工程と、
   前記複数のサービスを提供するように実行するアクションの前記シーケンスを示すシーケンスのリストを生成する工程と、
   前記複数のサービスを提供する前記シーケンスのリストに基づいて、前記ＡＳロジックおよび前記ゲートウェイ・ロジックの少なくとも１つを実行する工程とをさらに備える請求項６に記載の方法。
10. 前記複数のサービスを１つの評価グループにまとめる工程と、
    前記評価グループ内の前記複数のサービスのためにセッションベースのオンライン課金を提供する前記ＯＣＳへと単一の課金メッセージを発信する工程とをさらに備える請求項９に記載の方法。

Images