JP2010515354A - 通信ネットワークにおける動的サービストリガ - Google Patents

Abstract

サービストリガを動的に定義するための通信ネットワーク（１００）及び関連する方法が開示される。セッションのセッション開始メッセージの受信に応答し、アプリケーションサーバ（１１６〜１１８）はセッションのアプリケーションサーバ（１１６〜１１８）によって提供されるサービスの１以上の後続のサービストリガを定義する。後続のサービストリガはアプリケーションサーバ（１１６〜１１８）が通知を受けるよう望むセッションのメッセージ又は条件を識別する。次に、アプリケーションサーバ（１１６〜１１８）は後続のサービストリガを、セッションをセットアップ又は保持しているセッション制御機能（１１２）に伝送する。次に、セッション制御機能（１１２）はセッションの後続のメッセージを受信する。セッション制御機能（１１２）は後続のメッセージ及び後続のサービストリガを処理して後続のメッセージをアプリケーションサーバ（１１６〜１１８）に伝送するかどうかを決定する。

Description

本発明は通信の分野に関し、詳細には、通信ネットワークにおいて動的サービストリガを定義することに関する。さらに詳細には、通信ネットワークのアプリケーションサーバ（ＡＳ）はセッションに対してどのメッセージを受信したいか、又はどのメッセージを受信する必要があるかを指示するためにサービストリガを定義する。

人気を得ている通信ネットワークの１つの種類はＩＰマルチメディアサブシステム（ＩＭＳ；ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ネットワークである。３^ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）又は３ＧＰＰ２において示されるように、ＩＭＳは集中型ネットワーク向けのアクセス非依存のネットワークアーキテクチャを有する共通コアネットワークを提供する。サービスプロバイダは次世代のネットワーク変革においてこのアーキテクチャを受け入れようとしている。ＩＭＳアーキテクチャは当初、インターネットプロトコル（ＩＰ）ネットワークがビデオ、音声、及びデータを伝送する上で最も費用節減効果の高いベアラネットワークとなっているので、ＩＰネットワークを介してモバイル加入者にマルチメディアサービスを提供するために３ＧＰＰによって定義されている。ＩＭＳネットワーク内で使用される信号制御は通常、セッション開始プロトコル（ＳＩＰ；Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）である。ＩＭＳは、アプリケーションサーバ、ＩＭＳコアネットワーク（ＣＳＣＦ）、及びＩＭＳ加入者の間の標準ＳＩＰインターフェースを定義する。これらの標準は、ネットワークの統合費用を軽減することができ、加入者がさらに安定したサービスを受けられるようにすることができる。

ＩＭＳネットワークにおいて、発呼側のユーザ機器はＣＤＭＡネットワーク、ＧＳＭネットワーク、ＩＰネットワーク、ＷｉＦｉネットワーク、ＷｉＭＡＸネットワークなどのアクセスネットワークを通じてＩＭＳネットワークに登録する。登録は通常、アクセスネットワークにＳＩＰ ＲＥＧＩＳＴＥＲメッセージを伝送するユーザ機器によって行われる。アクセスネットワークはＲＥＧＩＳＴＥＲメッセージをＩＭＳネットワークにルーティングする。ＩＭＳネットワーク内のサービス提供−コールセッション制御機能（Ｓ−ＣＳＣＦ；ｓｅｒｖｉｎｇ−ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）はＲＥＧＩＳＴＥＲメッセージを受信する。発呼側のユーザ機器にサービスを提供しているＳ−ＣＳＣＦは発信元Ｓ−ＣＳＣＦと呼ばれる。ＲＥＧＩＳＴＥＲメッセージの受信に応答して、発信元Ｓ−ＣＳＣＦは発呼側のユーザプロファイルについてホーム加入者サーバ（ＨＳＳ；Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）にクエリを行う。ユーザプロファイルは発呼側によって加入された１以上のサービスのサービストリガ及びその他のトリガ情報を指示する初期フィルタ基準（ｉＦＣ；Ｉｎｉｔｉａｌ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ）を含む。次に、発信元Ｓ−ＣＳＣＦは発呼側のｉＦＣを格納する。

着呼側とのセッションを開始するため、発呼側のユーザ機器はアクセスネットワークを通じてＳＩＰ ＩＮＶＩＴＥメッセージをＩＭＳネットワークに伝送する。ＩＮＶＩＴＥメッセージは、セッション開始メッセージと見なすことができる。発信元Ｓ−ＣＳＣＦはＩＮＶＩＴＥメッセージを受信し、ｉＦＣを処理して、どのサービスがＩＮＶＩＴＥメッセージに応答してトリガされるかを決定する。１以上のサービスがトリガされる場合、発信元Ｓ−ＣＳＣＦはＩＭＳネットワークでそのようなサービスを提供するアプリケーションサーバ（ＡＳ）を識別し、さらにアプリケーションサーバのルーティング情報を識別する。次に、発信元Ｓ−ＣＳＣＦはルーティング情報に基づいてＩＮＶＩＴＥメッセージをアプリケーションサーバにルーティングする。

アプリケーションサーバはＩＮＶＩＴＥメッセージを受信し、サービスを提供するか、又はサービスを初期化するように操作する。次に、発信元Ｓ−ＣＳＣＦはＩＮＶＩＴＥメッセージを、着呼側のユーザ機器にサービスを提供している別のＳ−ＣＳＣＦに伝送する。着呼側のユーザ機器にサービスを提供しているＳ−ＣＳＣＦは着信先Ｓ−ＣＳＣＦと呼ばれる。次に、着信先Ｓ−ＣＳＣＦ及び発信元Ｓ−ＣＳＣＦはセッションの確立を試みる。

セッションの確立又は保持の一環として、発信元Ｓ−ＣＳＣＦは着信先Ｓ−ＣＳＣＦ及び発呼側のユーザ機器から後続のメッセージを受信する。後続のメッセージはセッション開始メッセージの後に受信される任意のメッセージからなる。例えば、発信元Ｓ−ＣＳＣＦは着信先Ｓ−ＣＳＣＦからＳＩＰ１８３メッセージ又はＳＩＰ２００ＯＫメッセージを受信することができるか、又は発呼側のユーザ機器からＳＩＰ ＵＰＤＡＴＥメッセージを受信することができる。セッションの後続のメッセージの受信に応答して、発信元Ｓ−ＣＳＣＦはセッション開始中に確立された信号制御パスにあるアプリケーションサーバを識別する。次に、発信元Ｓ−ＣＳＣＦは後続のメッセージを各々のアプリケーションサーバに伝送する。同じプロセスは発信元Ｓ−ＣＳＣＦがセッションに対して受信する後続の各メッセージに対して繰り返される。同様のプロセスは着信先Ｓ−ＣＳＣＦにおいて実行される。

現在のＩＭＳネットワークの１つの問題は、たとえアプリケーションサーバがサービスを実行するために後続のメッセージを受信する必要がない場合であっても、Ｓ−ＣＳＣＦが後続のメッセージを、ｉＦＣによってトリガされるとセッションのサービスを提供しているアプリケーションサーバのすべてに伝送することである。一例として、アプリケーションサーバがセッションのプリペイドサービスを提供するものと仮定する。アプリケーションサーバはセッションのプリペイド課金情報を決定するために、セッションが開始及び終了したときに通知される必要があるが、ＳＩＰ１８３メッセージ又はＳＩＰ ＵＰＤＡＴＥメッセージのような、他の状況タイプのメッセージについて通知を受ける必要はないこともある。この例において、アプリケーションサーバはこれらの後続のメッセージをアプリケーションサーバが受信する必要がないにもかかわらず、１以上の後続のメッセージをＳ−ＣＳＣＦから受信することになる。Ｓ−ＣＳＣＦとアプリケーションサーバとの間で不必要なメッセージを伝送することは、ネットワークを混雑させる可能性もあり、さらに長いコールセットアップの遅延を引き起こす可能性もあり、それらの不必要なメッセージを処理しなければならないネットワークノードの処理時間を浪費する可能性もある。

本発明は、セッションの受信された後続のメッセージに対してアプリケーションサーバにおいて動的にサービストリガを定義すること、及びセッションにサービスを提供しているセッション制御機能（例えば、Ｓ−ＣＳＣＦ）にサービストリガを伝送することにより上記及びその他の問題を解決する。セッション制御機能がセッションの後続のメッセージを受信すると、セッション制御機能はサービストリガを処理して、後続のメッセージを通知されるよう要求した１以上のアプリケーションサーバを識別し、後続のメッセージを識別されたアプリケーションサーバに伝送する。アプリケーションサーバにおいて後続のメッセージのサービストリガを定義することにより、セッション制御機能は、現在行われているように、セッションにサービスを提供しているアプリケーションサーバのすべてに後続のメッセージを伝送することはない。後続のメッセージはその特定のメッセージ又はメッセージタイプのサービストリガを定義したアプリケーションサーバに伝送されるが、このことはネットワークにおいて不必要なメッセージが伝送されることをなくす。このようにして、ネットワーク帯域幅及び処理時間は有利に節約することができる。

本発明の１つの実施形態は動的サービストリガを定義するように適合された通信ネットワークを備える。通信ネットワークは１以上のアプリケーションサーバ及び１つのセッション制御機能を含む。セッション制御機能は通信ネットワークにおいてセッションのセッション開始メッセージ（例えば、ＳＩＰ ＩＮＶＩＴＥメッセージ）を受信するように適合される。セッション制御機能はさらに、セッションの１以上の初期サービストリガを識別し、初期サービストリガに基づいて１以上のアプリケーションサーバにセッション開始メッセージを伝送するように適合される。セッション開始メッセージの受信に応答し、アプリケーションサーバはセッション開始メッセージを処理して、セッションのアプリケーションサーバによって提供されるサービスの１以上の後続のサービストリガを定義するように適合される。アプリケーションサーバはさらに、後続のサービストリガをセッション制御機能に伝送するように適合される。セッション制御機能はさらに、セッションの後続のメッセージ（例えば、ＳＩＰ２００ＯＫ（ＩＮＶＩＴＥ）メッセージ）を受信するように適合される。セッション制御機能はさらに、後続のメッセージ及び後続のサービストリガを処理して、後続のメッセージをアプリケーションサーバに伝送するかどうかを決定するように適合される。セッション制御機能は後続のサービストリガをセッション制御機能に伝送するその他のアプリケーションサーバに対して同様のプロセスを実行する。

本発明は以下に説明するその他の例示的な実施形態を含むことができる。

同じ参照番号はすべての図面において同じ要素又は同じ種類の要素を示す。

本発明の例示的な実施形態における通信ネットワークを示す図である。 本発明の例示的な実施形態における動的サービストリガを定義するように通信ネットワークを操作する方法を示す流れ図である。 本発明の例示的な実施形態におけるＩＭＳネットワークを示す図である。 本発明の例示的な実施形態におけるプリペイドサービスを提供するためのＩＭＳネットワーク内のメッセージングを示すメッセージ図である。 本発明の例示的な実施形態におけるコール転送（ｃａｌｌ ｔｒａｎｓｆｅｒ）サービスを提供するためのＩＭＳネットワーク内のメッセージングを示すメッセージ図である。 本発明の例示的な実施形態における無応答時コール転送（ｃａｌｌ ｆｏｒｗａｒｄ ｎｏ ａｎｓｗｅｒ）サービスを提供するためのＩＭＳネットワーク内のメッセージングを示すメッセージ図である。 ｓＦＣ情報のモデルの概要を示す図である。

図１〜７及び以下の説明は当業者に本発明を実施及び使用する方法を教示するために本発明の特定の例示的な実施形態を示す。発明の原理を教示するために、本発明の標準的な側面が一部簡略化又は省略されている。当業者であれば、本発明の範囲に含まれるそれらの実施形態の変形を理解するであろう。当業者であれば、以下に説明される特徴が様々な方法で組み合わされて、本発明の複数の変形を形成できることを理解するであろう。その結果、本発明は以下に説明される特定の実施形態に限定されるのではなく、特許請求の範囲及びそれらの等価物によってのみ限定される。

図１は本発明の例示的な実施形態における通信ネットワーク１００を示す。通信ネットワーク１００はセッション制御機能１１２、複数のアプリケーションサーバ１１６〜１１８、及び加入者データベース１１９を含む。通信ネットワーク１００の一例はＩＭＳネットワークである。セッション制御機能１１２は、通信ネットワーク１００においてセッション又はダイアログをセットアップ、保持、及び／又は分解するように適合された任意のシステム、サーバ、又はネットワークノードを備える。セッション制御機能１１２の一例は、ＩＭＳネットワークにおけるサービス提供−コールセッション制御機能（Ｓ−ＣＳＣＦ）である。アプリケーションサーバ１１６〜１１８は、通信ネットワーク１００においてセッション又はダイアログのサービスを提供するように適合された任意のシステム、サーバ、又はネットワークノードを備える。アプリケーションサーバ１１６〜１１８の例は、Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ（ＯＳＡ ＳＣＳ）又はＩＰ Ｍｕｌｔｉｍｅｄｉａ−Ｓｅｒｖｉｃｅ Ｓｗｉｔｃｈｉｎｇ Ｆｕｎｃｔｉｏｎ（ＩＭ−ＳＳＦ）に基づくＩＭＳアプリケーションサーバ（ＩＭＳ ＡＳ）、及びＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅアプリケーションサーバ（ＯＭＡ ＡＳ）を含む。加入者データベース１１９は、ユーザプロファイル及びその他のユーザ情報を格納する任意のシステム、サーバ、又はネットワークノードを備える。加入者データベース１１９の一例は、ホーム加入者サーバ（ＨＳＳ；Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）を含む。セッション制御機能１１２及びアプリケーションサーバ１１６〜１１８はセッションの発信側又は着信側を表すことができる。

この実施形態について、ユーザ機器（ＵＥ）１２０が通信ネットワーク１００を通じてセッションを開始するものと仮定する。本明細書に使用されている用語「セッション（ｓｅｓｓｉｏｎ）」は、通信ネットワーク１００におけるセッション、コール、又はダイアログに適用される。セッションを開始する前に、ＵＥ１２０はセッション制御機能１１２に登録する。ＵＥ１２０は登録メッセージ（例えば、ＳＩＰ ＲＥＧＩＳＴＥＲメッセージ）をセッション制御機能１１２に伝送する。登録メッセージに応答して、セッション制御機能１１２はＵＥ１２０を通信ネットワーク１００に登録し、ＵＥ１２０に関連付けられているユーザプロファイルに加入者データベース１１９からアクセスすることができる。次に、ＵＥ１２０はセッション開始メッセージをセッション制御機能１１２に伝送することによりセッションを開始する準備が整う。セッション開始メッセージの一例は、ＳＩＰ ＩＮＶＩＴＥメッセージである。次に、通信ネットワーク１００は、図２に説明されるように、セッションをセットアップ又は保持するように動作する。

図２は本発明の例示的な実施形態における動的サービストリガを提供するように通信ネットワーク１００を操作する方法２００を示す流れ図である。方法２００のステップは図１の通信ネットワーク１００を参照して説明される。図２の流れ図のステップは包括的なものではなく、図示されていない他のステップを含むことができる。

方法２００のステップ２０２において、セッション制御機能１１２はＵＥ１２０からセッションのセッション開始メッセージを受信する。セッション開始メッセージの受信に応答し、セッション制御機能１１２は、ステップ２０４においてセッションの１以上の初期サービストリガ（又はサービスポイントトリガ（ＳＰＴ；Ｓｅｒｖｉｃｅ Ｐｏｉｎｔ Ｔｒｉｇｇｅｒ））を識別する。初期サービストリガの一例は、セッションの１以上の初期サービストリガを指示する初期フィルタ基準（ｉＦＣ；Ｉｎｉｔｉａｌ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ）を含む。セッション制御機能１１２は既に初期サービストリガを格納している場合もある。例えば、セッション制御機能１１２はＵＥ１２０のセッション制御機能１１２への登録に応答してＵＥ１２０のユーザプロファイルを要求することができ、ここでユーザプロファイルは初期サービストリガを含む。代替として、セッション制御機能１１２は初期サービストリガについて加入者データベース１１９にクエリを行うことにより、セッション開始メッセージの受信に応答して、初期サービストリガを要求することができる。ステップ２０６において、セッション制御機能１１２は、初期サービストリガに基づいて、セッション開始メッセージを１以上のアプリケーションサーバ１１６〜１１８に伝送する。初期サービストリガは、どのサービスがＵＥ１２０のユーザによって加入されているかを指示する。初期サービストリガはまた、どのアプリケーションサーバ１１６〜１１８がそれらのサービスを提供しているかを指示する。このようにして、セッション制御機能１１２は、どのアプリケーションサーバ１１６〜１１８がセッションに使用されるか識別することができ、アプリケーションサーバ１１６〜１１８のルーティング情報を識別して、セッション開始メッセージを適切なアプリケーションサーバ１１６〜１１８に伝送する。

セッション開始メッセージの受信に応答し、ステップ２０８において、アプリケーションサーバ（アプリケーションサーバ１１６とする）はセッション開始メッセージを処理して、セッションのアプリケーションサーバ１１６によって提供されるサービスの１以上の後続のサービストリガ（又はサービスポイントトリガ（ＳＰＴ））を定義する。後続のサービスポイントトリガは、後続のメッセージに応答して、アプリケーションサーバからアクションを導き出す任意の条件を備える。一例として、アプリケーションサーバ１１６がプリペイドサービスを提供する場合、アプリケーションサーバ１１６は、プリペイドサービスを実行するためにアプリケーションサーバ１１６が受信する必要のある後続のメッセージを指示する複数の後続のサービストリガを定義することができる。もう１つの例として、アプリケーションサーバ１１６がコール転送サービスを提供する場合、アプリケーションサーバ１１６は、コール転送サービスを実行するためにアプリケーションサーバ１１６が受信する必要のある後続のメッセージを指示する複数の後続のサービストリガを定義することができる。ステップ２１０において、アプリケーションサーバ１１６はさらに、後続のサービストリガをセッション制御機能１１２に伝送する。セッション開始メッセージを受信するその他のアプリケーションサーバ１１７〜１１８の各々は同様のプロセスを実行することができる。

アプリケーションサーバ１１６〜１１８は様々な方法で後続のサービストリガを定義することができる。例えば、アプリケーションサーバ１１６〜１１８はセッション開始メッセージを処理して、アプリケーションサーバによって提供されるサービスの後続のサービストリガ又はその他のトリガ情報を指示する後続フィルタ基準（ｓＦＣ；Ｓｕｂｓｅｑｕｅｎｔ Ｆｉｌｔｅｒ Ｃｒｉｔｅｒｉａ）を定義することができる。アプリケーションサーバ１１６〜１１８はｓＦＣ本体をＸＭＬ形式（又はその他の形式）でフォーマットすることができ、ｓＦＣ本体に後続のサービストリガを含めることができる。次に、アプリケーションサーバ１１６〜１１８はｓＦＣ本体をＳＩＰ ＩＮＶＩＴＥ要求メッセージのようなセッション開始メッセージに組み込むことができ、セッション開始メッセージをセッション制御機能１１２に伝送することができる。ｓＦＣ本体を含むセッション開始メッセージの受信に応答し、セッション制御機能１１２はセッション開始メッセージを着信先デバイスに転送する前に、セッション開始メッセージからｓＦＣ本体を取り去る。セッション制御機能１１２はまた、ｓＦＣを格納する。

アプリケーションサーバ１１６〜１１８は、代替として、ｓＦＣ本体を、セッション開始メッセージ以外の別のタイプのメッセージにｓＦＣ本体を組み込むことができる。バックツーバック・ユーザエージェント（Ｂ２ＢＵＡ；ｂａｃｋ−ｔｏ−ｂａｃｋ ｕｓｅｒ ａｇｅｎｔ）モデルの場合、アプリケーションサーバは新しいＳＩＰダイアログを開始するので、アプリケーションサーバはｓＦＣをＳＩＰ要求メッセージ（例えば、セッション開始メッセージ）に組み込むことができる。しかし、Ｂ２ＢＵＡ以外のモデルの場合、アプリケーションサーバはｓＦＣをＳＩＰ応答メッセージに組み込むことができる。例えば、セッション制御機能はＢ２ＢＵＡ以外のアプリケーションサーバにＳＩＰ要求メッセージを送信することができ、アプリケーションサーバは同じダイアログで応答する。このようにして、アプリケーションサーバはｓＦＣをＳＩＰ応答メッセージ（例えば、ＳＩＰ２００ ＯＫメッセージ）に組み込み、セッション制御機能はｓＦＣを保存する。

ステップ２１２において、セッション制御機能１１２は、セッションの後続のメッセージを受信する。先に説明されているように、後続のメッセージはセッション開始メッセージの後に受信される任意のメッセージからなる。ステップ２１４において、後続のメッセージの受信に応答し、セッション制御機能１１２は後続のメッセージ及び１以上のアプリケーションサーバ１１６〜１１８から受信した後続のサービストリガを処理して、後続のメッセージをアプリケーションサーバ１１６〜１１８に伝送するかどうかを決定する。例えば、セッション制御機能１１２がアプリケーションサーバ１１６から後続のサービストリガを受信した場合、セッション制御機能１１２は後続のメッセージ及びアプリケーションサーバ１１６からの後続のサービストリガを処理して、後続のメッセージをアプリケーションサーバ１１６に伝送するかどうかを決定する。セッション制御機能１１２がアプリケーションサーバ１１７から後続のサービストリガを受信した場合、セッション制御機能１１２は後続のメッセージ及びアプリケーションサーバ１１７からの後続のサービストリガを処理して、後続のメッセージをアプリケーションサーバ１１７に伝送するかどうかを決定する。

サービストリガに基づいて後続のメッセージをアプリケーションサーバ１１６〜１１８に伝送するという決定が行われた場合、セッション制御機能１１２は後続のメッセージを適切なアプリケーションサーバ１１６〜１１８に伝送し、サービスの取り扱い後にアプリケーションサーバからのメッセージを処理する準備を整える。セッション制御機能１１２は、Ｖｉａヘッダ又はＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダにおけるように、アプリケーションサーバ１１６〜１１８へのセッション開始メッセージのルーティングからアプリケーションサーバ１１６〜１１８のルーティング情報を既に有している場合もある。サービストリガに基づいて後続のメッセージをアプリケーションサーバ１１６〜１１８に伝送しないという決定が行われた場合、セッション制御機能１１２は後続のメッセージを１以上のアプリケーションサーバ１１６〜１１８に伝送せず、対応するアプリケーションサーバ１１６〜１１８がセッションに関与しないかのように後続のメッセージを処理する。このようにして、セッション制御機能１１２は不必要な後続のメッセージをアプリケーションサーバ１１６〜１１８に伝送することを有利に回避し、通信ネットワーク１００における帯域幅及び処理時間を節約する。

サービストリガがアプリケーションサーバによって動的に定義され得る通信ネットワークの１つの種類はＩＭＳネットワークである。図３〜６はＩＭＳネットワークにおける様々なサービスのサービストリガの定義を示す。図３は本発明の例示的な実施形態におけるＩＭＳネットワーク３００を示す。ＩＭＳネットワーク３００は発呼側ネットワーク３１０及び着呼側ネットワーク３２０を含む。発呼側ネットワーク３１０はアクセスネットワーク３１２、パケットネットワーク３１４、プロキシ−コールセッション制御機能（Ｐ−ＣＳＣＦ；ｐｒｏｘｙ−ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）３１６、サービス提供−コールセッション制御機能（Ｓ−ＣＳＣＦ；ｓｅｒｖｉｎｇ−ｃａｌｌ ｓｅｓｓｉｏｎ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎ）３１８、及びアプリケーションサーバ３１９を含む。着呼側ネットワーク３２０はアクセスネットワーク３２２、パケットネットワーク３２４、Ｐ−ＣＳＣＦ３２６、Ｓ−ＣＳＣＦ３２８、アプリケーションサーバ３２９、及びホーム加入者サーバ（ＨＳＳ）３３０を含む。

図４は本発明の例示的な実施形態におけるプリペイドサービスを提供するためのＩＭＳネットワーク３００内のメッセージングを示すメッセージ図である。開始するため、ユーザ機器（ＵＥ）３１１は（図３を参照）ＵＥ３２１に電話をかける。電話をかけるため、ＵＥ３１１はアクセスネットワーク３１２、パケットネットワーク３１４、及びＰ−ＣＳＣＦ３１６を通じてＳＩＰ ＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。ＩＮＶＩＴＥ要求メッセージの受信に応答し、Ｓ−ＣＳＣＦ３１８はＵＥ３１１のｉＦＣを処理して、ＩＮＶＩＴＥ要求メッセージがＡＳ３１９によって提供されるプリペイドサービスをトリガするかどうかを決定する。Ｓ−ＣＳＣＦ３１８はＨＳＳ（図示せず）からのｉＦＣを含むＵＥ３１１のユーザプロファイルを以前ダウンロードしている場合もある。この例において、ＩＮＶＩＴＥ要求メッセージはプリペイドサービスをトリガしないので、Ｓ−ＣＳＣＦ３１８はＩＮＶＩＴＥ要求メッセージをＡＳ３１９に伝送する。

ＡＳ３１９はＩＮＶＩＴＥ要求メッセージを処理し、ＵＥ３１１がプリペイドサービスを割り当てられたことを識別する。サービス論理に基づいて、ＡＳ３１９はプリペイドサービスを提供するために課金を開始するコール応答（ｃａｌｌ ａｎｓｗｅｒ）イベント及び課金を停止するコール終了（ｃａｌｌ ｅｎｄ）イベントを認識する必要があることを決定する。このようにして、ＡＳ３１９はセッションの後続のＳＩＰ２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージのサービストリガ、及びセッションの後続のＢＹＥメッセージのサービストリガを含むｓＦＣ本体を構築する。２００ＯＫ応答メッセージはコール応答イベントを指示し、ＢＹＥメッセージはコール終了イベントを指示する。次に、ＡＳ３１９はｓＦＣ本体をＩＮＶＩＴＥ要求メッセージに組み込み、構築されたｓＦＣ本体を含むＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。

ＡＳ３１９からのＩＮＶＩＴＥ要求メッセージの受信に応答して、Ｓ−ＣＳＣＦ３１８はｓＦＣ本体がＩＮＶＩＴＥ要求メッセージに含まれるかどうかを検査する。このコールのシナリオにおいて、ｓＦＣ本体が含まれており、そのためＳ−ＣＳＣＦ３１８は対応するＡＳ３１９に関連付けられているｓＦＣ情報及び後続のメッセージを必要に応じてＡＳ３１９に送信するために必要なルーティング情報の内容を格納する。次に、Ｓ−ＣＳＣＦ３１８はｓＦＣ情報をＩＮＶＩＴＥ要求メッセージから削除し、ＩＮＶＩＴＥ要求メッセージを着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８にルーティングする。

コールセットアップ中のある時点において、Ｓ−ＣＳＣＦ３２８はＳＩＰ１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は１８３メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は１８３メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は１８３メッセージをＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

前提条件及びリソース予約が使用される場合、ＵＥ３１１はベアラセットアップを確認するためにＳＩＰ ＵＰＤＡＴＥ要求メッセージを伝送する。Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥ要求メッセージを受信し、ＵＰＤＡＴＥ要求メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥメッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥ要求メッセージをＡＳ３１９に伝送することなく、引き続き着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８に転送する。

ＵＰＤＡＴＥ要求メッセージに応答して、Ｓ−ＣＳＣＦ３２８はＳＩＰ２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

着呼側ネットワーク３２０のコールセットアップ中に、ＵＥ３２１はアラートを受信し、Ｓ−ＣＳＣＦ３２８は１８０ＲＩＮＧＩＮＧ応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージを、ＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

ＵＥ３２１のユーザがコールに応答した場合、Ｓ−ＣＳＣＦ３２８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージのサービストリガを検出し、そのためＳ−ＣＳＣＦ３１８は初期ＩＮＶＩＴＥ要求メッセージをＡＳ３１９にルーティングするために以前取得したルーティング情報を使用して、２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＡＳ３１９に伝送する。

ＡＳ３１９は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージを受信し、コール応答イベントを識別する。次に、ＡＳ３１９はプリペイドサービスの課金を開始することができる。ＡＳ３１９はまた、２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は引き続き２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＵＥ３１１に転送する。ＵＥ３１１は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージにＳＩＰ ＡＣＫメッセージで応答する。Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージを受信し、ＡＣＫメッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージをＡＳ３１９に伝送することなく、引き続き着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８に転送する。次に、セッションはＵＥ３１１とＵＥ３２１との間で確立される。

複数のアプリケーションサーバがセッションに関与する場合、それらの複数のアプリケーションサーバはｉＦＣデータの優先度に基づいてＳ−ＣＳＣＦ３１８からトリガされる。複数のアプリケーションサーバがＳ−ＣＳＣＦ３１８に送信されたｓＦＣ本体でトリガする動的サービスを適用する場合、Ｓ−ＣＳＣＦ３１８はｓＦＣデータを対応するアプリケーションサーバに関連付ける。様々な機構がこの相関に使用されてもよい。１つのアプリケーションサーバからの要求メッセージを処理して要求メッセージを次のアプリケーションサーバに送信した後、先のアプリケーションサーバに関連付けられているｓＦＣ本体は格納されて要求メッセージから削除されるので、Ｓ−ＣＳＣＦ３１８は同時に複数のｓＦＣ本体を扱う必要はない。セッションの後続のメッセージが受信されると、Ｓ−ＣＳＣＦ３１８はアプリケーションサーバの順序に従ってメッセージをｓＦＣデータと照合し、セッションの先のアプリケーションサーバからの出力メッセージが次のアプリケーションサーバの入力メッセージとして使用される。

この例において明らかなように、ＡＳ３１９はサービストリガをｓＦＣ情報として定義し、Ｓ−ＣＳＣＦ３１８はサービストリガを使用して、ＡＳ３１９に伝送すべき後続のメッセージを決定する。その結果、ＡＳ３１９はＡＳ３１９によって提供されているプリペイドサービスに関連する後続のメッセージのみを受信し、関連のない他のメッセージは受信しない。

図５は本発明の例示的な実施形態におけるコール転送サービスを提供するためのＩＭＳネットワーク３００内のメッセージングを示すメッセージ図である。開始するため、ＵＥ３１１は（図３を参照）ＵＥ３２１に電話をかける。電話をかけるため、ＵＥ３１１はアクセスネットワーク３１２、パケットネットワーク３１４、及びＰ−ＣＳＣＦ３１６を通じてＳＩＰ ＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。ＩＮＶＩＴＥ要求メッセージの受信に応答し、Ｓ−ＣＳＣＦ３１８はＵＥ３１１のｉＦＣを処理して、ＩＮＶＩＴＥ要求メッセージがＡＳ３１９によって提供されたコール転送サービスをトリガするかどうかを決定する。この例において、ＩＮＶＩＴＥ要求メッセージはコール転送サービスをトリガするので、Ｓ−ＣＳＣＦ３１８はＩＮＶＩＴＥ要求メッセージをＡＳ３１９に伝送する。

ＡＳ３１９はＩＮＶＩＴＥ要求メッセージを処理し、ＵＥ３１１がコール転送サービスを割り当てられたことを識別する。サービス論理に基づいて、ＡＳ３１９はコール転送サービスを提供するためにコール応答（ｃａｌｌ ａｎｓｗｅｒ）イベント及びコール転送呼び出し（ｃａｌｌ ｔｒａｎｓｆｅｒ ｉｎｖｏｃａｔｉｏｎ）イベントを認識する必要があることを決定する。このようにして、ＡＳ３１９はセッションの後続のＳＩＰ２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージのサービストリガ、及びセッションの後続のＲＥＦＥＲメッセージのサービストリガを含むｓＦＣ本体を構築する。２００ＯＫ応答メッセージはコール応答イベントを指示し、ＲＥＦＥＲメッセージはコール転送呼び出しイベントを指示する。次に、ＡＳ３１９はｓＦＣ本体をＩＮＶＩＴＥ要求メッセージに組み込み、構築されたｓＦＣ本体を含むＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。

ＡＳ３１９からのＩＮＶＩＴＥ要求メッセージの受信に応答して、Ｓ−ＣＳＣＦ３１８は、ｓＦＣ本体がＩＮＶＩＴＥ要求メッセージに含まれるかどうかを検査する。このコールのシナリオにおいて、ｓＦＣ本体が含まれており、そのためＳ−ＣＳＣＦ３１８は対応するＡＳ３１９に関連付けられているｓＦＣ情報及び後続のメッセージを必要に応じてＡＳ３１９に送信するために必要なルーティング情報の内容を格納する。次に、Ｓ−ＣＳＣＦ３１８はｓＦＣ情報をＩＮＶＩＴＥ要求メッセージから削除し、ＩＮＶＩＴＥ要求メッセージを着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８にルーティングする。

コールセットアップ中のある時点において、Ｓ−ＣＳＣＦ３２８はＳＩＰ１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は１８３メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は１８３メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は１８３メッセージをＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

前提条件及びリソース予約が使用される場合、ＵＥ３１１はベアラセットアップを確認するためにＳＩＰ ＵＰＤＡＴＥ要求メッセージを伝送する。Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥ要求メッセージを受信し、ＵＰＤＡＴＥ要求メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥメッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８はＵＰＤＡＴＥ要求メッセージをＡＳ３１９に伝送することなく、引き続き着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８に転送する。

ＵＰＤＡＴＥメッセージに応答して、Ｓ−ＣＳＣＦ３２８はＳＩＰ２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

着呼側ネットワーク３２０のコールセットアップ中に、ＵＥ３２１はアラートを受信し、Ｓ−ＣＳＣＦ３２８は１８０ＲＩＮＧＩＮＧ応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８は１８０ＲＩＮＧＩＮＧ応答メッセージをＡＳ３１９に伝送することなく、引き続きＵＥ３１１に転送する。

ＵＥ３２１のユーザがコールに応答した場合、Ｓ−ＣＳＣＦ３２８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージのサービストリガを検出し、そのためＳ−ＣＳＣＦ３１８は初期ＩＮＶＩＴＥ要求メッセージをＡＳ３１９にルーティングするために以前取得したルーティング情報を使用して、２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＡＳ３１９に伝送する。

ＡＳ３１９は２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージを受信し、コール応答イベントを識別する。次に、ＡＳ３１９はコールが確立されていることを識別することができる。ＡＳ３１９はまた、２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８は引き続き２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージをＵＥ３１１に転送する。ＵＥ３１１はＳＩＰ ＡＣＫメッセージで応答する。Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージを受信し、ＡＣＫメッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３１８はＡＣＫメッセージをＡＳ３１９に伝送することなく、引き続き着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８に転送する。次に、セッションはＵＥ３１１とＵＥ３２１との間で確立される。

コール中のある時点において、ＵＥ３１１がコールをＵＥ３２１から別のＵＥ（図示せず）に転送しようとするものと仮定する。コールを転送するため、ＵＥ３１１はＳＩＰ ＲＥＦＥＲ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。ＲＥＦＥＲメッセージはコール転送の宛先番号を含む。Ｓ−ＣＳＣＦ３１８はＲＥＦＥＲ要求メッセージをＡＳ３１９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３１８はＲＥＦＥＲ要求メッセージのサービストリガを検出し、そのためＳ−ＣＳＣＦ３１８は初期ＩＮＶＩＴＥ要求メッセージをＡＳ３１９にルーティングするために以前取得したルーティング情報を使用して、ＲＥＦＥＲ要求メッセージをＡＳ３１９に伝送する。ＡＳ３１９はＲＥＦＥＲ要求メッセージを受信し、コール転送呼び出しイベントを識別する。次に、ＡＳ３１９はＵＥ３２１からＲＥＦＥＲ要求メッセージの宛先番号によって識別された他のＵＥ３１１へのコールの転送を開始することができる。

この例において明らかなように、ＡＳ３１９はサービストリガをｓＦＣ情報として定義し、Ｓ−ＣＳＣＦ３１８はサービストリガを使用して、ＡＳ３１９に伝送すべき後続のメッセージを決定する。その結果、ＡＳ３１９はＡＳ３１９によって提供されているコール転送サービスに関連する後続のメッセージのみを受信し、関連のない他のメッセージは受信しない。

図６は本発明の例示的な実施形態における無応答時コール転送（ｃａｌｌ ｆｏｒｗａｒｄ ｎｏ ａｎｓｗｅｒ）サービスを提供するためのＩＭＳネットワーク３００内のメッセージングを示すメッセージ図である。開始するため、ＵＥ３１１は（図３を参照）ＵＥ３２１に電話をかける。電話をかけるため、ＵＥ３１１はアクセスネットワーク３１２、パケットネットワーク３１４、及びＰ−ＣＳＣＦ３１６を通じてＳＩＰ ＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３１８に伝送する。Ｓ−ＣＳＣＦ３１８はＩＮＶＩＴＥメッセージを着呼側ネットワーク３２０のＳ−ＣＳＣＦ３２８に転送する。ＩＮＶＩＴＥ要求メッセージの受信に応答し、Ｓ−ＣＳＣＦ３２８はＵＥ３２１のｉＦＣを処理して、ＩＮＶＩＴＥ要求メッセージがＡＳ３２９によって提供された無応答時コール転送サービスをトリガするかどうかを決定する。この例において、ＩＮＶＩＴＥ要求メッセージは無応答時コール転送サービスをトリガするので、Ｓ−ＣＳＣＦ３２８はＩＮＶＩＴＥ要求メッセージをＡＳ３２９に伝送する。

ＡＳ３２９はＩＮＶＩＴＥ要求メッセージを処理し、ＵＥ３２１のユーザが無応答時コール転送サービスをこの時点でアクティブ化されていることを識別する。サービス論理に基づいて、ＡＳ３２９は無応答時コール転送サービスを提供するために着信先無応答（ｔｅｒｍｉｎａｔｉｎｇ ｐａｒｔｙ ｎｏ ａｎｓｗｅｒ）イベント及びコール応答（ｃａｌｌ ａｎｓｗｅｒ）イベントを認識する必要があることを決定する。このようにして、ＡＳ３２９はセッションの後続のＳＩＰ４０８ Ｒｅｑｕｅｓｔ Ｔｉｍｅｏｕｔ応答メッセージのサービストリガ、及びセッションの後続の２００ＯＫ（ＩＮＶＩＴＥ）応答メッセージのサービストリガを含むｓＦＣ本体を構築する。４０８ Ｒｅｑｕｅｓｔ Ｔｉｍｅｏｕｔ応答メッセージは無応答イベントを指示し、２００ＯＫ応答メッセージはコール応答イベントを指示する。次に、ＡＳ３２９はｓＦＣ本体をＩＮＶＩＴＥ要求メッセージに組み込み、構築されたｓＦＣ本体を含むＩＮＶＩＴＥ要求メッセージをＳ−ＣＳＣＦ３２８に伝送する。

ＡＳ３２９からのＩＮＶＩＴＥ要求メッセージの受信に応答して、Ｓ−ＣＳＣＦ３２８はｓＦＣ本体がＩＮＶＩＴＥ要求メッセージに含まれるかどうかを検査する。このコールのシナリオにおいて、ｓＦＣ本体が含まれており、そのためＳ−ＣＳＣＦ３２８は対応するＡＳ３２９に関連付けられているｓＦＣ情報及び後続のメッセージを必要に応じてＡＳ３２９に送信するために必要なルーティング情報の内容を格納する。次に、Ｓ−ＣＳＣＦ３２８はｓＦＣ情報をＩＮＶＩＴＥ要求メッセージから削除し、ＩＮＶＩＴＥ要求メッセージをＵＥ３２１にルーティングする。

コールセットアップ中のある時点において、ＵＥ３２１はＳＩＰ１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ応答メッセージをＳ−ＣＳＣＦ３２８に伝送する。Ｓ−ＣＳＣＦ３２８は１８３メッセージをＡＳ３２９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３２８は１８３メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３２８は１８３メッセージをＡＳ３２９に伝送することなく、引き続き（Ｓ−ＣＳＣＦ３１８を通じて）ＵＥ３１１に転送する。

前提条件及びリソース予約が使用される場合、ＵＥ３１１はベアラセットアップを確認するためにＳＩＰ ＵＰＤＡＴＥ要求メッセージを伝送する。Ｓ−ＣＳＣＦ３２８はＵＰＤＡＴＥ要求メッセージを受信し、ＵＰＤＡＴＥ要求メッセージをＡＳ３２９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３２８はＵＰＤＡＴＥメッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３２８はＵＰＤＡＴＥ要求メッセージをＡＳ３２９に伝送することなく、引き続きＵＥ３２１に転送する。

ＵＰＤＡＴＥ要求メッセージに応答して、ＵＥ３２１はＳＩＰ２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＳ−ＣＳＣＦ３２８に伝送する。Ｓ−ＣＳＣＦ３２８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３２９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３２８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３２８は２００ＯＫ（ＵＰＤＡＴＥ）メッセージをＡＳ３２９に伝送することなく、引き続きＵＥ３１１に転送する。

着呼側ネットワーク３２０のコールセットアップ中に、ＵＥ３２１はアラートを受信し、１８０ＲＩＮＧＩＮＧ応答メッセージをＳ−ＣＳＣＦ３２８に伝送する。Ｓ−ＣＳＣＦ３２８は、１８０ＲＩＮＧＩＮＧ応答メッセージをＡＳ３２９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３２８は１８０ＲＩＮＧＩＮＧ応答メッセージのサービストリガを検出しないので、Ｓ−ＣＳＣＦ３２８は１８０ＲＩＮＧＩＮＧ応答メッセージをＡＳ３２９に伝送することなく、引き続きＵＥ３１１に転送する。

ＵＥ３２１のユーザが、ＵＥ３２１の無応答タイマーが満了する前にコールに応答しない場合、ＵＥ３２１は４０８応答メッセージをＳ−ＣＳＣＦ３２８に伝送する。Ｓ−ＣＳＣＦ３２８は４０８応答メッセージをＡＳ３２９の格納されたｓＦＣ情報と照合する。この実施形態において、Ｓ−ＣＳＣＦ３２８は４０８応答メッセージのサービストリガを検出し、そのためＳ−ＣＳＣＦ３２８は初期ＩＮＶＩＴＥ要求メッセージをＡＳ３２９にルーティングするために以前取得したルーティング情報を使用して、４０８応答メッセージをＡＳ３２９に伝送する。ＡＳ３２９は４０８応答メッセージを受信し、無応答イベントを識別する。次に、ＡＳ３２９は望ましい宛先番号へのコールの転送を開始することができる。

この例において明らかなように、ＡＳ３２９はサービストリガをｓＦＣ情報として定義し、Ｓ−ＣＳＣＦ３２８はサービストリガを使用して、ＡＳ３２９にどの後続のメッセージを伝送すべきかを決定する。その結果、ＡＳ３２９はＡＳ３２９によって提供されている無応答時コール転送サービスに関連する後続のメッセージのみを受信し、関連のない他のメッセージは受信しない。

図７は上記の実施形態において使用されるｓＦＣ情報のモデルの概要を示す。クラスＳｅｒｖｉｃｅ Ｐｏｉｎｔ Ｔｒｉｇｇｅｒ（ＳＰＴ）の属性「Ｇｒｏｕｐ」により、論理積正規形（ＣＮＦ；Ｃｏｎｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ）又は論理和正規形（ＤＮＦ；Ｄｉｓｊｕｎｃｔｉｖｅ Ｎｏｒｍａｌ Ｆｏｒｍ）式の内部に副次式を構成するＳＰＴのグループ化が可能になる。ＣＮＦにおいて、属性「Ｇｒｏｕｐ」はＳＰＴインスタンスのＯＲのセットを識別する。ＳＰＴが別のＯＲのセットに属す場合、ＳＰＴは複数の「Ｇｒｏｕｐ」値を割り当てられている場合がある。少なくとも１つの「Ｇｒｏｕｐ」は各ＳＰＴに対して割り当てられる。ＤＮＦにおいて、属性「Ｇｒｏｕｐ」はＳＰＴインスタンスのＡＮＤのセットを識別する。ＳＰＴが別のＡＮＤのセットに属す場合、ＳＰＴは複数の「Ｇｒｏｕｐ」値を割り当てられている場合がある。少なくとも１つの「Ｇｒｏｕｐ」は各ＳＰＴに対して割り当てられる。クラスＳｅｒｖｉｃｅ Ｐｏｉｎｔ Ｔｒｉｇｇｅｒの属性「ＣｏｎｄｉｔｉｏｎＮｅｇａｔｅｄ」は個々のＳＰＴインスタンスが否定されるかどうかを定義する（つまり、ＮＯＴ論理式）。

「Ｒｅｑｕｅｓｔ−ＵＲＩ」クラスは属性ＲｅｑｕｅｓｔＵＲＩを含むＲｅｑｕｅｓｔ−ＵＲＩのＳＰＴを定義する。「ＳＩＰ Ｍｅｔｈｏｄ」クラスは任意のＳＩＰメソッド／要求の名前を保持する属性Ｍｅｔｈｏｄを含む、ＳＩＰメソッドのＳＰＴを定義する。「ＳＩＰ Ｈｅａｄｅｒ」クラスは任意のＳＩＰヘッダの有無又は任意のＳＩＰヘッダの内容に対してＳＰＴを定義するが、これは（ＳＰＴである）ＳＩＰ Ｈｅａｄｅｒを識別する属性Ｈｅａｄｅｒ及び必要に応じてＳＩＰ Ｈｅａｄｅｒの値を定義するＣｏｎｔｅｎｔ属性を含む。Ｃｏｎｔｅｎｔ属性の不在及びＣｏｎｄｉｔｉｏｎＮｅｇａｔｅｄ＝ＴＲＵＥはＳＰＴが決定されたＳＩＰヘッダの不在であることを指示する。「Ｓｅｓｓｉｏｎ Ｃａｓｅ」クラスは、フィルタが発信元サービス又は着信先サービスを扱うＳ−ＣＳＣＦによって使用されるべきかどうかを指示する可能な値「Ｏｒｉｇｉｎａｔｉｎｇ」及び「Ｔｅｒｍｉｎａｔｉｎｇ」を持つ列挙型を表す。「Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ」クラスはＳＩＰメッセージの本体内の任意のＳＤＰフィールドの内容に対してＳＰＴを定義する。「Ｌｉｎｅ」属性はセッション記述の内部の行を識別する。「Ｃｏｎｔｅｎｔ」属性は「Ｌｉｎｅ」属性の内容を定義する文字列である。「ＳＩＰ Ｒｅｓｐｏｎｓｅ」クラスはＳＩＰ応答情報を保持する属性Ｒｅｓｐｏｎｓｅを含むＳＩＰ応答メッセージに対してＳＰＴを定義する。

本明細書において、特定の実施形態について説明してきたが、本発明の範囲はそれらの特定の実施形態に限定されることはない。本発明の範囲は、以下の特許請求の範囲及びその任意の相当物によって定義される。

Claims (10)

1. 通信ネットワーク（１００）であって、
   少なくとも１つのアプリケーションサーバ（１１６〜１１８）、
   前記通信ネットワーク（１００）においてセッションのセッション開始メッセージを受信するように適合されたセッション制御機能（１１２）を備え、
   前記セッション制御機能（１１２）が、前記セッションの少なくとも１つの初期サービストリガを識別するようにさらに適合され、
   前記セッション制御機能（１１２）が、前記少なくとも１つの初期サービストリガに基づいて前記セッション開始メッセージを前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）に伝送するようにさらに適合され、
   該通信ネットワーク（１００）が、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は、前記セッション開始メッセージを処理して、前記セッションの前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）によって提供されるサービスの少なくとも１つの後続のサービストリガを定義するように適合され、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は、前記少なくとも１つの後続のサービストリガを前記セッション制御機能（１１２）に伝送するようにさらに適合され、
   前記セッション制御機能（１１２）は、前記セッションの後続のメッセージを受信するようにさらに適合され、及び
   前記セッション制御機能（１１２）は、前記後続のメッセージ及び前記少なくとも１つの後続のサービストリガを処理して、前記後続のメッセージを前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）に伝送するかどうかを決定するようにさらに適合されたことを特徴とする通信ネットワーク。
2. 請求項１記載の通信ネットワーク（１００）において、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は、前記セッション開始メッセージを処理して、前記少なくとも１つの後続のサービストリガを指示する後続のフィルタ基準を定義するようにさらに適合された通信ネットワーク。
3. 請求項２記載の通信ネットワーク（１００）において、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は後続のフィルタ基準本体をフォーマットするようにさらに適合され、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は前記後続のフィルタ基準本体を前記セッション開始メッセージに組み込むようにさらに適合され、
   前記少なくとも１つのアプリケーションサーバ（１１６〜１１８）は前記セッション開始メッセージを前記セッション制御機能（１１２）に伝送するようにさらに適合された通信ネットワーク。
4. 請求項３記載の通信ネットワーク（１００）において、
   前記セッション制御機能（１１２）は、前記セッション開始メッセージを着信先デバイスに転送する前に、前記後続のフィルタ基準本体を前記セッション開始メッセージから取り去るようにさらに適合された通信ネットワーク。
5. 請求項１記載の通信ネットワーク（１００）において、前記セッション制御機能（１１２）はＩＭＳネットワークのサービス提供−コールセッション制御機能Ｓ−ＣＳＣＦを備えた通信ネットワーク。
6. サービストリガを定義するために通信ネットワークを操作する方法であって、
   セッション制御機能においてセッションのセッション開始メッセージを受信するステップ、
   前記セッション制御機能において前記セッションの少なくとも１つの初期サービストリガを識別するステップ、及び
   前記少なくとも１つの初期サービストリガに基づいて前記セッション開始メッセージを少なくとも１つのアプリケーションサーバに伝送するステップ
   を備え、
   該方法が、
   前記少なくとも１つのアプリケーションサーバにおいて前記セッション開始メッセージを処理して、前記セッションの前記少なくとも１つのアプリケーションサーバによって提供されるサービスの少なくとも１つの後続のサービストリガを定義するステップ、
   前記少なくとも１つの後続のサービストリガを前記少なくとも１つのアプリケーションサーバから前記セッション制御機能に伝送するステップ、
   前記セッション制御機能において前記セッションの後続のメッセージを受信するステップ、及び
   前記セッション制御機能において前記後続のメッセージ及び前記少なくとも１つの後続のサービストリガを処理して、前記後続のメッセージを前記少なくとも１つのアプリケーションサーバに伝送するかどうかを決定するステップを備えることを特徴とする方法。
7. 請求項６記載の方法において、前記セッション開始メッセージを処理して少なくとも１つの後続のサービストリガを定義するステップが、
   前記セッション開始メッセージを処理して、前記少なくとも１つの後続のサービストリガを指示する後続のフィルタ基準を定義するステップからなる方法。
8. 請求項７記載の方法において、前記セッション開始メッセージを処理して少なくとも１つの後続のサービストリガを定義するステップが、
   前記少なくとも１つのアプリケーションサーバにおいて後続のフィルタ基準本体をフォーマットするステップからなる方法。
9. 請求項８記載の方法において、前記少なくとも１つの後続のサービストリガを前記少なくとも１つのアプリケーションサーバから前記セッション制御機能に伝送するステップが、
   前記後続のフィルタ基準本体を前記セッション開始メッセージに組み込むステップ、及び
   前記セッション開始メッセージを前記少なくとも１つのアプリケーションサーバから前記セッション制御機能に伝送するステップ
   からなる方法。
10. 請求項９記載の方法であって、
    前記セッション開始メッセージを着信先デバイスに転送する前に、前記セッション制御機能において前記後続のフィルタ基準本体を前記セッション開始メッセージから取り去るステップをさらに備える方法。

Images