(57)【特許請求の範囲】
【請求項１】
呼セッション制御機能(ＣＳＣＦ)と、
複数のＰＵＣＩアプリケーションサーバと、
を含み、
前記複数のＰＵＣＩアプリケーションサーバは、ユーザ装置から受信された通信が未承諾通信であるかどうかの判定を行い、
前記ＣＳＣＦは、前記判定に基づいて、前記複数のＰＵＣＩアプリケーションサーバに向かうルーティングに関して決定を行い、
前記呼セッション制御機能は、前記決定に基づいて、前記ルーティングを実行する、
ＰＵＣＩシステム。
【請求項２】
それぞれのＰＵＣＩアプリケーションサーバは、ＩＭＳ／ＳＩＰヘッダに含まれる特別なＰＵＣＩ情報に基づいて、動的な呼ルーティング性能を有する、
請求項１に記載のＰＵＣＩシステム。
【請求項３】
ＩＮＶＩＴＥを前記ユーザ装置から前記ＣＳＣＦに送ることと、
前記ＣＳＣＦにおいてＰＵＣＩサービスを実行することと、
初期フィルタ条件に照らして、前記ＩＮＶＩＴＥを前記ＣＳＣＦから第１のＰＵＣＩアプリケーションサーバに送ることと、
前記第１のＰＵＣＩアプリケーションサーバにおいてＰＵＣＩ  Ｔｅｓｔ  １を実行し、したがって、未承諾呼の発生の可能性を示す結果を生成することと、
前記ＰＵＣＩ  Ｔｅｓｔ  １の前記結果を含む前記ＩＮＶＩＴＥを前記第１のＰＵＣＩアプリケーションサーバから前記ＣＳＣＦに返送することと、
前記ＩＮＶＩＴＥをさらなるテスティングに適している第２のＰＵＣＩアプリケーションサーバに送るために前記結果を判定することと、
前記第２のＰＵＣＩアプリケーションサーバにおいてＰＵＣＩ  Ｔｅｓｔ  ２を実行し、したがって、前記未承諾呼の前記発生のさらなる可能性を示す結果を生成することと、
前記ＰＵＣＩ  Ｔｅｓｔ  ２の前記結果を含む前記ＩＮＶＩＴＥを前記第２のＰＵＣＩアプリケーションサーバから前記ＣＳＣＦに返送することと、
前記未承諾呼を拒否するために両方の前記結果を判定することと
を含む処理を実装する、請求項１に記載のＰＵＣＩシステム。
【請求項４】
ＩＮＶＩＴＥを前記ユーザ装置から前記ＣＳＣＦに送ることと、
前記ＣＳＣＦにおいてＰＵＣＩサービスを実行することと、
初期フィルタ条件に照らして、前記ＩＮＶＩＴＥを前記ＣＳＣＦから第１のＰＵＣＩアプリケーションサーバに送ることと、
前記第１のＰＵＣＩアプリケーションサーバにおいてＰＵＣＩ  Ｔｅｓｔ  １を実行し、したがって、未承諾呼の発生の可能性を示す結果を生成することと、
さらなるテスティングに適している第２のＰＵＣＩアプリケーションサーバを確定するために前記結果を判定することと、
前記第２のＰＵＣＩアプリケーションサーバに送られることになっている前記結果を含む前記ＩＮＶＩＴＥを前記第１のＰＵＣＩアプリケーションサーバから前記ＣＳＣＦに返送することと、
前記第２のＰＵＣＩアプリケーションサーバへの前記ＩＮＶＩＴＥを前記ＣＳＣＦから前記第２のＰＵＣＩアプリケーションサーバに送ることと、
前記第２のＰＵＣＩアプリケーションサーバにおいてＰＵＣＩ  Ｔｅｓｔ  ２を実行し、したがって、前記未承諾呼の前記発生のさらなる可能性を示す結果を生成することと、
前記未承諾呼を終端側にルーティングするために、または前記未承諾呼の前記発生の可能性がないことを示す前記結果を含む前記ＩＮＶＩＴＥを前記ＣＳＣＦに返送するために前記結果を判定することと
を含む処理を実装する、請求項１に記載のＰＵＣＩシステム。
【請求項５】
呼セッション制御機能(ＣＳＣＦ)と、
複数のＰＵＣＩアプリケーションサーバと、
を備えたＰＵＣＩシステムの、ＩＭＳ(ＰＵＣＩ)に対する未承諾通信の防御の方法であって、
前記ＰＵＣＩアプリケーションサーバが、ユーザ装置から受信された通信が未承諾通信であるかどうかの判定を行うステップと、
前記ＣＳＣＦが、前記判定に基づいて、前記複数のＰＵＣＩアプリケーションサーバに向かうルーティングに関して決定を行うステップと、
前記ＣＳＣＦが、前記決定に基づいて、前記ルーティングを実行するステップと、
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットプロトコルマルチメディアサブシステムに対する未承諾通信の防御に関する。
【０００２】
本出願は、特願2008-260088に基づいて優先権を主張するものであり、その内容を参照によって本明細書に組み込む。
【背景技術】
【０００３】
近年の電気通信の流れは、電話網に代表される音声通信システムに関して、IP(Internet Protocol)標準化を行うに至っている。移動体通信の標準化に関する業界団体である3GPP(3rd Generation Partnership Project)では、IPネットワーク上で音声サービスなどのマルチメディアサービスを提供するための基盤となるIPマルチメディアサブシステム(IMS)の標準化のための仕様が作成された。近年では、次世代ネットワーク(NGN)に関する固定型のIP標準化に関して、検討が行われている。
【０００４】
電子メールサービスでは、望みもしないメールが一方的に送信者から受信者に送られるというSpamメールや未承諾(またはジャンク)メールなどの厄介な社会問題が起きている。未承諾通信（すなわち迷惑通信）は、通信コストの大幅な低下や、不特定の人またはサイトに大量の電子メールを送信することができる(一般のユーザが購入可能なパソコンなどの)ネットワークアクセス端末の進歩など、インターネットの普及から派生する様々な要因により生じる。
【０００５】
(電子メールサービスでは、すでに生じている)上述の問題は、IMSでもその普及により生じるように思われる。3GPP仕様では、IP電話によるSpam(SPIT)からユーザを防御するために、IMSに対する未承諾通信の防御(the protection against unsolicited communication for IMS:簡単に「PUCI」と呼ぶ)が開始されている。これに関連して、特許文献1には、IMSエンティティを有する移動体ネットワークシステムが開示されている。
【０００６】
特許文献1:特表2007-527633
【０００７】
3GPPは、IMSに対するPUCIに関しての検討を開始したばかりである。加入者が発信する呼はそれぞれ、PUCIアプリケーションによってテストを受け、そのアプリケーションは、呼を順に未承諾評価スコア(unsolicited rating scores)により判定する。未承諾呼は、拒否(または拒絶)されるが、未承諾呼と見なされない呼は、ユーザの装置に送られる。本明細書においては、問題は、IMSがスコアを確認するためのPUCIアプリケーションをいかに含むかである。
【０００８】
上述の問題を解決するために、2つの代替的なソリューションを以下に明示する。
(1)サービング呼セッション制御機能(S-CSCF)は、ディスパッチング機能(dispatching functionality)を提供するように改善される。
(2)PUCIアプリケーションは、次ホップルーティング決定を行うための分散処理を可能にするように改善され、PUCIアプリケーションは、次の呼に関してPUCIテスト/段階を実行すべきかどうかを自律的に判断する必要がある。
【０００９】
初期フィルタ条件(iFC)を採用する従来のIMS仕様は、アプリケーションサーバに関して静的なルーティングのみを受け入れ、デジタル加入者網(DSN)に基づく動的なアプリケーションサーバ(AS)指定に限定される。これにより、PUCIの対処に十分な柔軟性を与える際に、IMSの改善が求められる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特願2008-260088
【特許文献２】特表2007-527633
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、上述の問題の解決を目指し、その目的は、S-CSCFを改善すること、または新規ルーティングロジックをアプリケーションサーバに実装することによってIMSの機能を拡張することである。
【課題を解決するための手段】
【００１２】
具体的には、ＩＭＳに対する未承諾通信の防御（ＰＵＣＩ）システムは、呼セッション制御機能(ＣＳＣＦ)と、複数のＰＵＣＩアプリケーションサーバと、を含み、前記複数のＰＵＣＩアプリケーションサーバは、ユーザ装置から受信された通信が未承諾通信であるかどうかの判定を行い、前記ＣＳＣＦは、前記判定に基づいて、前記複数のＰＵＣＩアプリケーションサーバに向かうルーティングに関して決定を行い、前記呼セッション制御機能は、前記決定に基づいて、前記ルーティングを実行する。
【００１３】
ソリューション1によれば、PUCIシステムは、INVITEをユーザ装置からCSCFに送ることと、CSCFにおいてPUCIサービスを実行することと、イニシャルフィルタリングクライテリアを用いた動作により、INVITEをCSCFから第1のPUCIアプリケーションサーバに送ることと、第1のPUCIアプリケーションサーバにおいてPUCI Test 1を実行し、したがって、未承諾呼の発生の可能性を示す結果を生成することと、PUCI Test 1の結果を含むINVITEを第1のPUCIアプリケーションサーバからCSCFに返送することと、INVITEをさらなるテスティングに適している第2のPUCIアプリケーションサーバに送るために、結果を判定することと、第2のPUCIアプリケーションサーバにおいてPUCI Test 2を実行し、したがって、未承諾呼の発生のさらなる可能性を示す結果を生成することと、PUCI Test 2の結果を含むINVITEを第2のPUCIアプリケーションサーバからCSCFに返送することと、未承諾呼を拒否するために両方の結果を判定することとを含む処理を実装する。
【００１４】
ソリューション2によれば、PUCIシステムは、INVITEをユーザ装置からCSCFに送ることと、CSCFにおいてPUCIサービスを実行することと、初期フィルタ条件(iFC)に照らして、INVITEをCSCFから第1のPUCIアプリケーションサーバに送ることと、第1のPUCIアプリケーションサーバにおいてPUCI Test 1を実行し、したがって、未承諾呼の発生の可能性を示す結果を生成することと、さらなるテスティングに適している第2のPUCIアプリケーションサーバを確定するために、結果を判定することと、第2のPUCIアプリケーションサーバに送られることになっている結果を含むINVITEを第1のPUCIアプリケーションサーバからCSCFに返送することと、第2のPUCIアプリケーションサーバへのINVITEをCSCFから第2のPUCIアプリケーションに送ることと、第2のPUCIアプリケーションサーバにおいてPUCI Test 2を実行し、したがって、未承諾呼の発生のさらなる可能性を示す結果を生成することと、未承諾呼を終端側にルーティングするために、または未承諾呼の発生の可能性がないことを示す結果を含むINVITEをCSCFに返送するために、結果を判定することと含む処理を実装する。
【図面の簡単な説明】
【００１５】
【図１】インターネットプロトコルマルチメディアサブシステムに対する未承諾通信の防御、すなわち、PUCIシステムについての構成を示すブロック図である。
【図２】実施形態1によるPUCIシステムの構成を示すブロック図である。
【図３】図2のPUCIシステムに含まれるユーザ装置と、プロキシ呼セッション制御機能(P-CSCF)と、サービング呼セッション制御機能(S-CSCF)と、アプリケーションサーバ(PUCI AS1-AS2)との間で実行される処理の説明に使用するシーケンス図である。
【図４】実施形態2によるPUCIシステムの構成を示すブロック図である。
【図５】図4のPUCIシステムに含まれるユーザ装置と、P-CSCFと、S-CSCFと、PUCI AS1-AS2との間で実行される処理の説明に使用するシーケンス図である。
【発明を実施するための形態】
【００１６】
本発明は、2つの方法、すなわち、サービング呼セッション制御機能(S-CSCF)において動的なルーティングを実行するための第1の方法、またはPUCIアプリケーションサーバにおいて動的なルーティングを実行するための第2の方法によって、複数のPUCIアプリケーションサーバを使用して、未承諾呼に関する動的なルーティング決定について示す。本明細書においては、動的なルーティング決定は、PUCIテスティングの結果およびテスティングのスコアに基づいて、S-CSCFか、またはPUCIアプリケーションサーバのいずれかで行われる。
【００１７】
具体的には、本発明は、以下の技術的な特徴を明示する。
(1)S-CSCFは、シグナリングメッセージ(例えばIMS/SIPヘッダ、ただし、SIPは、Signal Initiated Protocolを表す)に追加される特別なPUCI情報に基づいて、またはS-CSCFと、PUCIアプリケーションサーバとの間の帯域外シグナリングによって、PUCIアプリケーションサーバに向かう動的なルーティングを実行するように改善される。
(2)PUCIアプリケーションサーバは、シグナリングメッセージ(例えば、IMS/SIPヘッダ)に含まれる特別なPUCI情報に基づいて、動的な呼ルーティング性能を有するように設計される。
【００１８】
図1は、PUCIシステム、すなわち、IMSに対する未承諾通信の防御についてのシステムの構成を示すブロック図であり、それは、呼を発信するためのユーザ装置(UE A)100と、ユーザ装置100によって発信された呼を宛先に転送するためのプロキシ呼セッション制御機能(P-CSCF)200と、転送された呼が未承諾呼と見なされるか否かの決定を行うようにアプリケーションサーバに要求するサービング呼セッション制御機能(S-CSCF)300と、未承諾呼に関する決定を行うための複数のアプリケーションサーバ(AS1からAS4)401から404とから構成されている。
【００１９】
3GPPは、広帯域符号分割多元符号化を用いたアクセスシステム(W-CDMA)と、グローバルシステムフォーモバイルコミュニケーションズ(global system for mobile communications:GMS)とを実装する世界共通ネットワークに関して、仕様を作成するための第3世代携帯電話システムに関するプロジェクトであり、それは、近年、1つのPUCIアプリケーションを使用することによって、または複数のPUCIアプリケーションを使用することによって実装されるPUCIシステムの研究を開始した。本明細書においては、PUCIアプリケーションは、それぞれの加入者の呼が潜在的未承諾呼と見なされるか否かを確認するために、それぞれの加入者の呼に関してセッションをテストする。PUCIアプリケーションがセッションを様々な段階によって潜在的未承諾呼に分類できるようにする様々な方法および規格があり、PUCIアプリケーションは、未承諾評価スコアにより呼を判定し、それは順次、蓄積される。これに関連して、PUCIアプリケーションは、次のPUCIアプリケーションまたはS-CSCF300(すなわち、次のPUCIアプリケーションを指定するためのIMS)に対するPUCIテスティングの詳細な情報を含むセッションシグナリングを送信することが可能である。
【００２０】
PUCIテスティングの様々な段階を通過する呼は、最終的に、(未承諾呼でない)応答型呼と見なされ、次いで、ユーザ装置(UE)に転送されるが、その他の呼は、拒否される。PUCIアプリケーションまたはIMSは、3つの手順、すなわち、(i)拒否されたセッションを単に破棄すること、(ii)ERRORまたはBYEメッセージを送信することによって、拒否されたセッションを巧みに終了させること、および(iii)拒否の理由を含む明確な指示をソースエンティティに示すことによって、拒否されたセッションに対処する。
【００２１】
REJECTメッセージに含まれる(ソースエンティティ、例えば、未承諾呼を送信するユーザ装置100に送信される)以下の情報要素、およびそれらの使用方法に関する具体的なアイデアを示す。
(1)PUCIアプリケーションの名称(実行すべきテスティングの結果およびタイプを推定するために使用する)
(2)PUCIアプリケーションのテスティング結果(特定のテスティングによって生成される)
(3)PUCIアプリケーションの署名(テスティングを有効にし、テスティングヒストリにアクセスするために使用する)
(4)累積PUCIスコアおよびPUCIアプリケーションのリスト
(5)それぞれのセッションがPUCIテスティングを通過するか否かの表示(SIP端末適応が容易に生じないようにするために使用する)
(6)テスティングを実行する法人の署名(テスティングを有効にするために使用する)
【００２２】
オペレータが、エンドユーザに代わって、呼をブロックする法的権利を所有していない場合、ユーザ装置(UE)は、最終的に呼を終了させるように設計されているので、上述の情報は、最終的に呼をブロックすることが可能なUEに含まれるPUCIアプリケーション/機能によって、あるいはSIPのBYEメッセージもしくはERRORメッセージの処理に関わるPUCIアプリケーションサーバまたはIMSによって、REJECTメッセージに追加される。
【００２３】
IMSが複数の潜在的独立PUCIアプリケーションサーバを支持するように設計されている場合、IMSは、動的なPUCIルーティング機能を達成する必要があるか、またはそれぞれのPUCIアプリケーションサーバは、それぞれのセッションを次のPUCIアプリケーションに、自律的にルーティングする必要があるという厄介な問題を3GPPは抱えている。
【００２４】
加えて、当IMS仕様は、初期フィルタ条件(iFC)に基づいて、複数のアプリケーションサーバと関わるルーティングロジックを明示することは可能であるが、このソリューションでは単に、単純なフィルタ条件に基づいて、アプリケーションサーバに向かう静的なルーティングが達成されるに過ぎない。
【００２５】
その上、当IMS仕様は、DSN名称に基づいて、動的なアプリケーションサーバ指定を確実にすることは可能であるが、このソリューションは単に、ロードバランシングの目的で有益なだけである。
【００２６】
PUCI仕様に基づく動的なやり方で、複数のPUCIアプリケーションサーバをチェーン化するために、本発明は、以下のソリューションを提供する。
(1)IMSのS-CSCFを、シグナリングメッセージ(例えば、IMS/SIPヘッダ)に追加される特別なPUCI情報に基づいて、またはS-CSCFと、PUCIアプリケーションサーバとの間の帯域外シグナリングによって、PUCIアプリケーションサーバに向かう動的なルーティングを確実にするように改善される。
(2)PUCIアプリケーションサーバは、IMS/SIPシグナリングに含まれる特別なPUCI情報に基づいて、動的な呼ルーティング性能を有するように設計される。
【００２７】
1.実施形態1(またはIMS/S-CSCFの改善を実装するソリューション1)
図2は、実施形態1によるPUCIシステムの構成を示すブロック図であり、それは、呼を発信するためのユーザ装置(UE A)100と、ユーザ装置100によって発信された呼を宛先に転送するためのプロキシ呼セッション制御機能(P-CSCF)200と、転送された呼が未承諾呼と見なされるか否かの決定を行うようにアプリケーションサーバに要求するサービング呼セッション制御機能(S-CSCF)300と、様々な段階によって、未承諾呼に関する決定を行うための複数のアプリケーションサーバ(PUCI AS1からPUCI AS4)501から504とを含む。図2のPUCIシステムは、呼を宛先に転送するための呼セッション制御機能(CSCF)600と、1つの宛先として機能するユーザ装置(UE B)700とをさらに含む。
【００２８】
ソリューション1は、IMS/S-CSCFに対する新規のPUCIを意識したルーティングロジックを実装し、それは、セッションシグナリングヘッダか、またはIMSサービス制御(ISC)のための装置間信号のいずれかに含まれる、前のPUCIテスティング結果を判定し、したがって、どのPUCIアプリケーションを次に動作させるべきか、またはセッションを拒否すべきかどうかの決定を行う。
【００２９】
ソリューション1では、IMS/SIPシグナリングヘッダか、または(ルーティングロジックに基づいて、さらに処理するために使用すべき)帯域外ISCに含まれる以下の情報要素が参照される。
(1)PUCIアプリケーションの名称(テスティング結果を推定するために使用する)
(2)それぞれのセッションがPUCIテスティングを通過するか否かの表示
(3)PUCIアプリケーションテスティングの詳細結果
(4)PUCIアプリケーションの署名(実行すべきテスティングを有効にするために使用する)
(5)累積PUCIスコアおよびPUCIアプリケーションのリスト
【００３０】
加えて、ソリューション1では、ルーティングロジック(またはルーティングロジックモジュール)に関する以下のアイデアが参照される。
(1)ルーティングロジックは、累積PUCIスコアに基づいて決定する。
(2)ルーティングロジックは、重み付けされた累積PUCIスコアに基づいて決定し、オペレータは、PUCIアプリケーションに関する種々の重みを構成することが可能である。
(3)重みは、PUCIアプリケーションおよび/またはテスティングを行う法人に基づいて確定される。
(4)ルーティングロジックは、最後のPUCIテスティングの詳細結果に基づいて決定する。
(5)ルーティングロジックは、前のPUCIテスティングの詳細な結果すべてに関する分析によって決定する。
(6)ルーティングロジックモジュールは、(フラグをアップグレードすることによって)柔軟に/動的に拡張され/置換えられるプログラムに基づいて決定する。
(7)ルーティングロジックモジュールは、パターンマッチングアルゴリズムに基づいて決定する。
(8)ルーティングロジックは、自己学習ストラテジーを使用し、新規PUCIアプリケーションがインストールされると、ルーティングロジックは、明確なユーザフィードバック、他のPUCIアプリケーションおよび/または呼パターン(呼が応答型であるか否かを推定するために使用する)の結果、ならびに詳細なPUCIアプリケーション出力に基づく結果をいかに解釈すべきかを学習する。
(9)ルーティングロジックは、同じアプリケーションサーバによるダブルトリガを避けるために、テスティングがすでに行われているか否かを判定する。
【００３１】
PUCI機能は、セッションを拒否する決定を行う可能性があり、それにより、様々なアプリケーションサーバの処理が無駄になるので、新規PUCIルーティングロジックは、標準的な初期フィルタ条件の実行前に呼び出すべきである。
【００３２】
図3は、図2のPUCIシステムに含まれるユーザ装置100と、P-CSCF200と、S-CSCF300と、アプリケーションサーバ(PUCI AS1-AS2)501、502との間で実行される処理を説明するために使用するシーケンス図である。
【００３３】
ステップS101:A側ユーザ装置(UE A)100は、B側ユーザ装置(UE B)700に対するINVITEをP-CSCF200に送信する。
【００３４】
ステップS102:P-CSCF200は、INVITEをそこへ送るためにS-CSCF300を確定する。
【００３５】
ステップS103:S-CSCF300は、PUCIサービスを実行するためにiFC(初期フィルタ条件)をトリガする。
【００３６】
ステップS104:S-CSCF300は、iFCに照らして、INVITEをアプリケーションサーバ(PUCI AS1)501に送る。
【００３７】
ステップS105:アプリケーションサーバ501は、未承諾呼の発生の可能性を評価するスコアを生成するためにPUCI1 Test 1を実行する。
【００３８】
ステップS106:アプリケーションサーバ501は、PUCI Test 1の結果をINVITEのPUCIヘッダに組み込み、それは、次いで、S-CSCF300に返送される。
【００３９】
ステップS107:S-CSCF300は、PUCI Test 1の結果を判定し、PUCI Test 1のスコアが未承諾呼の可能性を示す場合、S-CSCF300は、さらなるテスティングに適している特定のアプリケーションサーバを確定する。S-CSCF300が(未承諾呼でない)応答型呼の可能性を示すPUCI Test 1の結果を受け取った場合、S-CSCF300は、通常の呼処理を実行し、それにより、それ以上のテスティングは実行されなくなる。S-CSCF300は、高い確率での未承諾呼を検出すると即座に、そのような未承諾呼を拒否する。
【００４０】
ステップS108:S-CSCF300が、さらにテスティングする必要性を検出した場合、S-CSCF300は、さらなるテスティングに適している特定のアプリケーションサーバを選択し、すなわち、INVITEをアプリケーションサーバ(PUCI AS2)502に送る。
【００４１】
ステップS109:アプリケーションサーバ502は、未承諾呼に関する確定を行うために、PUCI Test 2を実行する。
【００４２】
ステップS110:アプリケーションサーバ502は、PUCI Test 2の結果をS-CSCF300に送信する。
【００４３】
ステップS111:S-CSCF300は、呼を配信すべきかどうか、さらにテスティングを行うべきかどうか、または呼を拒否すべきかどうかを確定するために、PUCI Test 1の結果およびPUCI Test 2の結果をともに判定する。
2.実施形態2(またはIMS/S-CSCFの改善を実装するソリューション2)
【００４４】
図4は、実施形態2によるPUCIシステムの構成を示すブロック図であり、それは、ユーザ装置(UE A)100と、プロキシ呼セッション制御機能(P-CSCF)200と、サービング呼セッション制御機能(S-CSCF)300と、アプリケーションサーバ(PUCI AS1からPUCI AS4)と、呼セッション制御機能(CSCF)600と、ユーザ装置(UE B)700とを含む。
【００４５】
ソリューション2は、それぞれのアプリケーションサーバの一部として動的な呼ルーティング性能を実装し、それは、それぞれのアプリケーションサーバが、実行すべき次のPUCIアプリケーションに関して自律的に決定を行うことを可能にする。ルーティング決定は、実行されたばかりのPUCIアプリケーションの結果、ならびに前に実行された他のPUCIアプリケーションの前の結果に基づいて行わることになる。前の結果は、IMS/SIPシグナリング(すなわち、PUCIの特定のヘッダ情報)の一部として、帯域内方式でそれぞれのアプリケーションサーバに供給される。
【００４６】
上述においては、アプリケーションサーバは、連続のユーザエージェントとして働き、それによって、さらにテスティングするための次の所望のアプリケーションサーバへの要求URIを変更する必要がある。本明細書においては、アプリケーションサーバは、特別なヘッダレコードですでに実行されたテスティングの結果を含み、それにより、後続のアプリケーションサーバは、別のテスティングが要求されると、その情報を考慮に入れるためにすでに実行されたテスティングを認識するようになる。
【００４７】
図5は、図4のPUCIシステムに含まれるユーザ装置(UE A)100と、P-CSCF200と、S-CSCF300と、アプリケーションサーバ(PUCI AS1-AS2)501、502との間で実行される処理を説明するために使用するシーケンス図である。
【００４８】
ステップS201:A側ユーザ装置100は、B側ユーザ装置700に対するINVITEをP-CSCF200に送信する。
【００４９】
ステップS202:P-CSCF200は、INVITEをそこへ送るためにS-CSCF300を確定する。
【００５０】
ステップS203:S-CSCF300は、PUCIサービスを実行するために初期フィルタ条件(iFC)をトリガする。
【００５１】
ステップS204:S-CSCF300は、iFCに照らして、INVITEをアプリケーションサーバ(PUCI AS1)501に送る。
【００５２】
ステップS205:アプリケーションサーバ501は、未承諾呼の発生の可能性を評価するスコアを生成するためにPUCI Test 1を実行する。
【００５３】
ステップS206:アプリケーションサーバ501は、PUCI Test 1の結果を判定し、結果が未承諾呼の可能性を示す場合、アプリケーションサーバ501は、さらなるテスティングに適している特定のPUCIアプリケーションサーバを確定する。アプリケーションサーバ501が(未承諾呼でない)応答型呼の可能性を示す結果を受け取った場合、それは、通常の呼処理を実行し、それにより、それ以上のテスティングは実行されなくなる。アプリケーションサーバ501は、未承諾呼を検出するとすぐに、そのような未承諾呼を拒否する。
【００５４】
ステップS207:アプリケーションサーバ501は、PUCI Test 1の結果(ならびにそのテスト情報)をINVITEのPUCIヘッダに組み込み、それは、次いで、アプリケーションサーバ(PUCI AS2)502に送られることになっているINVITEとしてS-CSCF300に返送される。
【００５５】
ステップS208:S-CSCF300は、PUCI Test 1の結果およびテスト情報を含むINVITEをアプリケーションサーバ(PUCI AS2)502に送信する。
【００５６】
ステップS209:アプリケーションサーバ502は、未承諾呼に関するさらなる確定を行うためにPUCI Test 2を実行する。
【００５７】
ステップS210:アプリケーションサーバ502は、呼を配信すべきかどうか、さらにテスティングを行うべきかどうか、または呼を拒否すべきかどうかを確定するために、PUCI Test 1の結果およびPUCI Test 2の結果をともに判定する。
【００５８】
ステップS211:さらにテスティングする場合には、アプリケーションサーバ502は、PUCI Test 2の結果を含むINVITEをS-CSCF300に送信する。アプリケーションサーバ502が、未承諾呼を検出した場合、そのような未承諾呼を配信する必要がなく、したがってそれは、終端側にルーティングされる。
【００５９】
上述したように、本発明は、以下の本発明のステップに含まれる。
(1)IMSは、PUCIアプリケーションサーバの所望の命令を呼び出す動的なルーティング性能を有する。
(2)IMS(S-CSCF)は、シグナリングメッセージ(例えば、IMS/SIPヘッダ)に追加される特別なPUCI情報に基づいて、または、IMS(S-CSCF)とPUCIアプリケーションサーバとの間の帯域外シグナリングによって、PUCIアプリケーションサーバに向かう動的なルーティングを確実にするように改善される。
(3)PUCIアプリケーションサーバは、IMS/SIPシグナリングに含まれる特別な情報に基づく動的な呼ルーティング性能を有する。
【００６０】
最後に、本発明は、実施形態1および2に必ずしも限定されるわけでなく、それは、添付の特許請求の範囲が規定する本発明の範囲の中でさらに修正可能である。
【符号の説明】
【００６１】
100  ユーザ装置(UE A)
200  プロキシ呼セッション制御機能(P-CSCF)
300  サービング呼セッション制御機能(S-CSCF)
401  アプリケーションサーバ(AS1)
402  アプリケーションサーバ(AS2)
403  アプリケーションサーバ(AS3)
404  アプリケーションサーバ(AS4)
501  アプリケーションサーバ(PUCI AS1)
502  アプリケーションサーバ(PUCI AS2)
503  アプリケーションサーバ(PUCI AS3)
504  アプリケーションサーバ(PUCI AS4)
600  呼セッション制御機能(CSCF)
700  ユーザ装置(UE B)
【図１】
0005500171.tif 000002
【図２】
0005500171.tif 000003
【図３】
0005500171.tif 000004
【図４】
0005500171.tif 000005
【図５】
0005500171.tif 000006