(57)【要約】【課題】CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合であっても呼損としない。【解決手段】端末４またはアプリケーションサーバ３から送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と各接続条件１２とを、既に合致した接続条件の優先度に関わらず優先度の高い順番に比較し、信号情報と接続条件とが合致するか否かを判定する判定ステップ１５と、いずれかの接続条件と合致した場合に、信号情報と合致した接続条件に設定されたアプリケーションサーバ３へ接続するサーバ接続ステップ１３、１４とを行う呼セッション制御方法。【選択図】図２
2011254423.tif 000002
【特許請求の範囲】
【請求項１】
呼セッション制御方法であって、
呼セッション制御サーバは、
複数のサービスの各々の接続条件が優先度とともに記憶された記憶部を、有し、
端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶部に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の高い順番に比較し、前記信号情報と接続条件とが合致するか否かを判定する判定ステップと、
前記判定ステップにおいて、いずれかの接続条件と合致した場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続ステップと、を行うこと
を特徴とする呼セッション制御方法。
【請求項２】
請求項１記載の呼セッション制御方法であって、
前記判定ステップにおいて、いずれかの接続条件と合致した場合、ループ事象が発生しているか否かを判定するループ判定ステップを、さらに行うこと
を特徴とする呼セッション制御方法。
【請求項３】
請求項２記載の呼セッション制御方法であって、
前記呼確立要求信号には、前記サーバ接続ステップを行った回数が判別可能な接続回数が含まれ、
前記ループ判定ステップは、前記呼確立要求信号に含まれる接続回数を取得し、当該接続回数が所定の値以上の場合に、ループ事象が発生したと判別すること
を特徴とする呼セッション制御方法。
【請求項４】
請求項２記載の呼セッション制御方法であって、
前記呼確立要求信号には、呼を識別する呼識別子が含まれ、
前記ループ判定ステップは、前記判定ステップで受信する前記呼確立要求信号の呼識別子を監視し、同一の呼識別子が所定の回数以上出現した場合に、ループ事象が発生したと判別すること
を特徴とする呼セッション制御方法。
【請求項５】
請求項２記載の呼セッション制御方法であって、
前記呼確立要求信号には、呼を識別する呼識別子が含まれ、
前記ループ判定ステップは、サーバ接続ステップで前記アプリケーションサーバに接続するために生成された呼確立要求信号に含まれる識別子、着信先アドレス、および発信元アドレスを対応付けて識別子記憶部に記憶し、前記判定ステップで受信した前記呼確立要求信号の識別子、着信先アドレス、および発信元アドレスが、前記識別子記憶部に記憶された識別子、着信先アドレス、および発信元アドレスと一致する場合、ループ事象が発生したと判別すること
を特徴とする呼セッション制御方法。
【請求項６】
請求項２から請求項４のいずれか１項に記載の呼セッション制御方法であって、
ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理ステップを行うこと
を特徴とする呼セッション制御方法。
【請求項７】
呼セッション制御サーバであって、
複数のサービスの各々の接続条件が優先度とともに記憶された記憶手段と、
端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶手段に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の高い順番に比較し、前記信号情報と接続条件とが合致するか否かを判定する判定手段と、
前記信号情報といずれかの接続条件とが合致した場合、ループ事象が発生しているか否かを判定するループ判定手段と、
ループ事象が発生していないと判定された場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続手段と、
ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理手段と、を有すること
を特徴とする呼セッション制御サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、3GPP（Third Generation Partnership Project）、3GPP2（Third Generation Partnership Project2）にて標準化されているＩＭＳ（IP Multimedia ）において、呼確立要求信号を受信した呼セッション制御機能部（以下CSCF：Call Session Control Functionと称する）が、受信した呼確立要求信号の内容と予め設定している接続条件（以下、iFC：initial Filter Criteriaと称する）とを比較し、合致するか否かを判定し、合致した場合は、該当するサービスを提供するアプリケーションサーバ（以下、「AS」：Application Serverと称する）に接続する処理を行う呼セッション制御技術に関する。
【背景技術】
【０００２】
従来のiFC処理の実装技術としては、次のような技術がある。すなわち、CSCFが呼確立要求信号（SIP：Session Initiation Protocolにおける、INVITEメソッド、MESSAGEメソッドなどを指す）を受信すると、呼確立要求信号の内容と予め設定しているiFCとを、予めiFC毎に設定された優先度の高い順番に合致するか否かを判定する。合致した場合は、該当するASに呼確立要求信号を送信して接続する処理（以下、「AS接続処理」と称する）を行う。呼確立要求信号を受信したASは、サービスを提供し、提供したサービスにもとづく呼確立要求信号をCSCFへ送信して接続する処理（以下、「CSCF接続処理」と称する）を行う。CSCFがASから送信された呼確立要求信号を受信すると、先に合致したiFCより低い優先度を持った未判定のiFCから判定を継続する（例えば、非特許文献1参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“3ＧＰＰ  ＴＳ  23．218””、［online］、［平成２２年３月３０日検索］、インターネット＜http://www.3gpp.org/ftp/Specs/archive/23_series/23.218/23218-900.zip＞
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記の技術では、CSCFにとっては優先度の高いiFCから順番に判定していくことができるが、CSCF側の優先度のつけ方とAS側のサービスの提供の仕方とが整合していない場合には、不具合が発生する場合がある。具体的には、呼確立要求信号の着信先アドレスを例にすると、CSCFが受信した呼確立要求信号の着信先アドレスがiFCに合致したことによりAS接続処理を行い、接続されたASのCSCF接続処理によりCSCFが受信した呼確立要求信号の着信先アドレスが、（1）論理アドレスなどのルーチングすることができないアドレスであって、（2）前記着信先アドレスが既に判定の対象となった判定済みのiFCに合致するアドレスであり、さらに（3）前記着信先アドレスの条件に合致する未判定iFCが存在しない場合に不具合が発生する。
【０００５】
前記（1）、（2）および（3）の条件を全て満たす場合、CSCF接続処理によりCSCFが受信した呼確立要求信号は、判定済みiFCとの合致判定は行われず、また、未判定iFCにも合致しないことから、着信先アドレスは論理アドレスの状態のままでiFC処理を終了することになる。このため、CSCF接続処理によりCSCFがASから受信する呼確立要求信号の着信先アドレスを用いて接続先へルーチングすることができず、呼損等となり、ASがサービスを提供できなくなる。
【０００６】
図8は、着信先アドレスがiFCに合致したことによりAS接続処理を行い、接続されたASのCSCF接続処理によりCSCFが受信した呼確立要求信号の着信先アドレスを基に着信先へルーチングできない場合を説明するための図である。図示するシステムは、CSCF−B2と、AS＃6  3ｆと、端末装置4とを有し、AS＃6  3ｆおよび端末装置4は、CSCF−B2に接続されている。
【０００７】
CSCF−B2は、加入者系のセッション制御機能を含むユーザ収容ノードである。AS＃6  3fは、CSCF−B2から接続されることにより、所定のサービスを提供するアプリケーションサーバ（AS）である。端末装置4は、通信サービスを利用するユーザが操作する端末装置である。
【０００８】
CSCF−B2には、予めiFC11およびiFC12の2つの接続条件が設定されている。iFC11は、CSCFが受信した呼確立要求信号の着信先アドレスが0800の論理番号（図示する例では0800−123456）である場合に、AS＃6  3ｆに接続する処理を行うという条件および動作を、優先度「1」として定義したものである。
【０００９】
iFC12は、着信先アドレスが0120の論理番号（図示する例では0120−234567）である場合に、AS＃6  3ｆに接続する処理を行うという条件および動作を、優先度「2」として定義したものである（iFCには、その他に記載する条件として条件合致時の接続先ASのアドレス等があるが、ここでは省略するものとする。）。
【００１０】
また、AS＃6  3ｆのサービスの提供の仕様としては、0120番号（図示する例では0120−234567）が送られてきた場合は0800番号（図示する例では0800−123456）に変換し、また、0800番号（図示する例は0800−123456）が送られてきた場合は0AB〜Ｊの物理番号に変換する処理を行うものとする。
【００１１】
端末装置4が、着信先アドレスが0120番号（0120−234567）である呼確立要求信号を送信すると、CSCF−B2が当該信号を受信する。そして、CSCF−B2は、呼確立要求信号の0120番号（0120−234567）と、優先度が最も高いiFC11との比較を行うが、合致しないことからスキップし、優先度が次に高いiFC12との比較を行う。iFC12（着信先アドレス：0120−234567）と合致するため、CSCF−B2は、AS＃6  3ｆにAS接続処理を行う。
【００１２】
AS＃6  3ｆは、CSCF−B2から着信先アドレスが0120番号（0120−234567）である呼確立要求信号が送られてくると、着信先アドレスを0800番号（0800−123456）に変換するサービスを行い、着信先アドレスが0800番号（0120−234567）である呼確立要求信号をCSCF−B2に送信するCSCF接続処理を行う。
【００１３】
CSCF−B2は、着信先アドレスが0800番号（0800−123456）である呼確立要求信号を受信し、CSCF接続処理の呼確立要求信号と、iFCとの比較を行う。ここで比較を行う対象は、iFCは未判定のiFCのみである。iFC11およびiFC12については、既に判定済みのiFCであるため、判定対象外となる。そのため、着信先アドレスが0800番号（0800−123456）については、既に判定済みでスキップしたiFC11で定義されてはいるが、判定されることはない。
【００１４】
図８に示す例では、iFC11およびiFC12以外のiFCが存在しないため、未判定iFC なしとなり、iFC判定処理は終了する。iFC判定処理終了後、CSCF-B2は、着信先アドレスを基にルーチング処理を試行するが、呼確立要求信号の着信先アドレスが論理アドレスであることからルーチング先を解決できず、エラー応答により呼損とするなどのルーチング不可能時の動作をすることになる。
【００１５】
また、図８において、方路なし（NG）となることを回避するために、iFC11とiFC12の優先度の順番を入れ替えるということが考えられる。しかしその場合、iFCの優先度設定において、iFCを設定するユーザ（システム管理者など）は、各ASの提供するサービスの内容毎に、関連するiFCの優先度の高低の条件を考慮し、条件に従った設定を確実に行う必要がある。その結果、iFCの設定が難しくなり、iFCを設定するユーザの負荷が大きくなる。また、ユーザが行ったiFCの設定誤りにより、呼損となる可能性が排除できない。
【００１６】
以上説明したように、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合は、呼損となってしまうという問題がある。
【００１７】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合であっても呼損とすることがない、呼セッション制御方法、および呼セッション制御サーバを提供することにある。
【課題を解決するための手段】
【００１８】
上記目的を達成するため、本発明は、呼セッション制御方法であって、呼セッション制御サーバは、複数のサービスの各々の接続条件が優先度とともに記憶された記憶部を、有し、端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶部に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の高い順番に比較し、前記信号情報と接続条件とが合致するか否かを判定する判定ステップと、前記判定ステップにおいて、いずれかの接続条件と合致した場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続ステップと、を行う。
【００１９】
本発明は、呼セッション制御サーバであって、複数のサービスの各々の接続条件が優先度とともに記憶された記憶手段と、端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶手段に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の高い順番に比較し、前記信号情報と接続条件とが合致するか否かを判定する判定手段と、前記信号情報といずれかの接続条件とが合致した場合、ループ事象が発生しているか否かを判定するループ判定手段と、ループ事象が発生していないと判定された場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続手段と、ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理手段と、を有する。
【発明の効果】
【００２０】
本発明によれば、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合であっても呼損とすることがない、呼セッション制御方法、および呼セッション制御サーバを提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態に係るシステムの全体構成図である。
【図２】本実施形態のCSCFの構成例を示す図である。
【図３】CSCFの判定部の処理概要を説明するための図である。
【図４】CSCFの判定部の処理例（ループなし）を説明するための図である。
【図５】CSCFの判定部の処理例（ループあり）を説明するための図である。
【図６】CSCFの動作の一例を示すフローチャートである。
【図７】システムの動作の一例を示すシーケンスチャートである。
【図８】CSCFが受信した呼確立要求信号の着信先アドレスを用いて着信先へルーチングできない場合を説明するための図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態について、図面を参照して説明する。
【００２３】
まず、本発明の実施形態に係るシステムについて説明する。
【００２４】
［システムの構成］
図１は、本実施形態のシステムの構成例を示す構成図である。図示する本システムは、CSCF−A1（呼セッション制御サーバ）と、複数のAS （AS＃1  3a、AS＃2  3b、AS＃3  3c、AS＃4  3d、およびAS＃5  3e）と、端末装置4とを有する。なお、どのASであるかを特定しない場合は、「AS3」と記載する。AS＃1  3a、AS＃2  3b、AS＃3  3c、AS＃4  3dおよびAS＃5  3eは、それぞれCSCF−A1に接続され、端末装置4もCSCF−A1に接続される。
【００２５】
CSCF−A1は、iFC処理を実装した加入者系のセッション制御機能を含むユーザ収容ノード（例えば、SIPサーバなど）である。詳細についてはこの後説明する。
【００２６】
AS＃1  3a〜AS＃5  3eは、CSCF−A1から接続されて、各種のサービスを提供するアプリケーションサーバである。
【００２７】
端末装置4は、通信サービスを利用するユーザが操作する端末装置である。なお、図１では、CSCF−A1に接続される端末装置4は1つであるが、端末装置４は複数存在してもよい。
【００２８】
次に、本システムの機能について説明する。
【００２９】
［システムの機能］
本システムでは、CSCF−A1は、端末装置4あるいは他のCSCF−A（不図示）から送信されてきた呼確立要求信号を受信すると、呼確立要求信号の内容と、当該CSCF−A1に設定された各iFC（接続条件）とを比較し、条件に合致するか否かを判定する。条件に合致した場合は、ループ事象が発生しているか否かを判別し、ループ事象が発生していない場合は、AS接続処理を行う。
【００３０】
接続されたASは、CSCF接続処理を行い、呼確立要求信号をCSCF-A1に送信する。CSCF-A1は、ASから送信された呼確立要求信号を受信すると、先に合致したiFCの優先度の高低に関わらず、ASから送信された呼確立要求信号の内容とiFCとを、優先度の最も高いiFCから順番に比較し、条件に合致するか否かを判定する処理を行う。そして、CSCF-A1は、条件に合致するまで、未判定の全てのiFCについての判定処理が終了すると、判定結果に従った呼確立要求信号を着信先となる端末装置4あるいは他のCSCF−A（不図示）に送信する。
【００３１】
次に、本実施形態のCSCF−A1について説明する。
【００３２】
［CSCF−A1の構成］
図２は、図１に示すシステムにおけるCSCF−A1の構成例を示す図である。同図は、CSCF−A1の機能のうち、本発明に関係する部分のみを概念的に示している。
【００３３】
CSCF−A1は、サービス契約情報蓄積部11と、iFC蓄積部12と、SIP信号制御部13と、セッション制御部14と、判定部15とを有している。
【００３４】
サービス契約情報蓄積部11は、ユーザ毎にユーザが契約したサービス契約情報を蓄積する機能を有する。サービス契約情報には、iFC蓄積部12が蓄積する各iFCについて、各ユーザがどのサービスに契約しているかが記憶されている。すなわち、各ユーザと、当該ユーザが契約している少なくとも1つのサービスとが、対応付けて記憶されている。
【００３５】
iFC蓄積部12は、各サービスのiFC（接続条件）を蓄積する機能を有する。すなわち、各サービスと、当該サービスのiFCとが対応付けて記憶されている。なお、各iFCには、iFC蓄積部12に蓄積された全てのiFC内での優先度が設定されている。
【００３６】
SIP信号制御部13は、呼確立要求信号（SIP信号のINVITE、MESSAGE等）や呼確立要求信号に対する応答信号（200 OK信号等）を受信し、これらの信号をセッション制御部14に送出するとともに、セッション制御部14から送出される、これらの信号の処理結果にもとづいて呼確立要求信号およびその応答信号を送信する機能を有する。
【００３７】
セッション制御部14は、SIP信号制御部13から送出される信号を解析し、発信元アドレス、着信先アドレスおよびサービス要求内容等の信号情報を判定部15に送出するとともに、判定部15から送出される接続先AS3情報をSIP信号制御部13に送出する機能を有する。また、セッション制御部14は、SIP信号制御部13から送出される、AS3が提供するサービスに則った呼確立要求信号を解析し、発信元アドレス、着信先アドレスおよびサービス要求内容等の信号情報を判定部15に送出する機能を有する。また、セッション制御部14は、判定部15から送出される判定終了後の着信先アドレス、発信元アドレスおよびサービス要求内容等の信号情報をSIP信号制御部13に送出する機能を有する。
【００３８】
また、セッション制御部14は、判定部15からループ発生情報が送出された場合は、ループ検出後処理を行う機能を有する。
【００３９】
判定部15は、セッション制御部14から送出される発信元アドレスを用いて、サービス契約情報蓄積部11から該当する発信ユーザが契約している全てのサービスを取得する。そして、取得した各サービスに対応するiFCを、iFC蓄積部12からそれぞれ抽出し、当該発信ユーザのiFCとする。なお、iFC蓄積部12から抽出した各iFCには、iFC蓄積部12内でユニークな（重複しない）優先度が設定されている。このため、iFC蓄積部12から抽出した発信ユーサの各iFCの優先度が、重複することはない。
【００４０】
そして、判定部15は、これらの各iFCと、呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等とを比較し、合致するか否かを判定する。そして、いずれかの各iFCと合致した場合、判定部15は、ループ事象が発生していないことを確認し、接続先AS3情報をセッション制御部14に送出する。
【００４１】
また、判定部15は、セッション制御部14から送出された、AS3が提供するサービスに則った呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等を受け取り、先に合致したiFCの優先度の高低に関わらず、優先度の最も高いiFCから順番に比較し、合致するか否かを判定する処理を行う。そして、判定部15は、合致するまで全ての未判定のiFCについて判定を行い、判定が終了すると、判定結果に従った着信先アドレス、発信元アドレスおよびサービス要求内容等をセッション制御部14に送出する機能を有する。
【００４２】
また、判定部15は、ループ事象が発生していると判断した場合は、セッション制御部14にループ発生情報を送出する機能を有する。
【００４３】
なお、CSCF−A1は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされたCSCF−A1用のプログラムを実行することにより、CSCF−A1の各機能が実現される。また、CSCF−A1用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００４４】
次に、CSCF−A1の判定部15の処理について詳しく説明する。
【００４５】
［CSCF−Aの判定部の処理］
まずCSCF−Aの処理の概要について説明する。
【００４６】
図３は、判定部15の処理概要を説明するための図である。判定部15の処理は、iFC判定処理151と、ループ判定処理152とを有する。
【００４７】
SIP信号制御部13およびセッション制御部14は、端末装置4から送信されてきた呼確立要求信号を受信する。これにより、判定部15は、呼確立要求信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等（S1）を用いて、iFC判定処理151を行う。
【００４８】
iFC判定処理151では、優先度が最も高いiFCを比較対象として設定し(1511)、当該iFCと呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等の信号情報とを比較し(1512)、合致するか否かを判定する。合致しない場合であって、未判定iFCが存在する場合は(1513)、次に優先度が高いiFCを比較対照として設定し（1514）、当該iFCと比較し（1512）、未判定のiFCがなくなるまで以降の処理を繰り返す。
【００４９】
一方、いずれかのiFCと合致した場合は（1512：合致あり）、ループ判定処理152を行う。ループ判定処理152は、例えばAS3への接続処理回数（ASアクセス回数）を取得し（1521）、接続処理回数が所定の回数（規定数）より少ない場合（1521：規定数未満）は、ループ事象が発生していないと判定し、接続先AS情報（S2）をセッション制御部14に送出する。この場合、セッション制御部14およびSIP信号制御部13は、接続先AS情報（S2）を用いて対応するAS3にAS3接続処理を行う。なお、接続先AS情報は、合致した場合に接続するASのアドレス情報であって、各iFCに設定されている。
【００５０】
そして、SIP信号制御部13およびセッション制御部14は、接続されたAS3のCSCF接続処理により、当該AS3の提供サービスに則った呼確立要求信号を受信する。これにより、判定部15は、当該呼確立要求信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等（S1A）を用いて、iFC判定処理151を行う。その際、iFC判定処理151では、先に合致したiFCの優先度の高低に関わらず、優先度が最も高いiFCから順に比較しなおす。
【００５１】
いずれかのiFCと合致することなく、全てのiFCについて判定が終了すると（1513：未判定iFCなし）、判定結果に従った着信先アドレス、発信元アドレス、サービス要求内容等（S3）をセッション制御部14に送出し、セッション制御部14およびSIP信号制御部13は、端末装置4あるいは他CSCF−A（不図示）に呼確立要求信号を送信する。なお、判定結果に従った着信先アドレス、発信元アドレス、サービス要求内容等（S3）は、接続されたAS3のCSCF接続処理により、当該AS3の提供サービスに則った呼確立要求信号に含まれるものである。
【００５２】
また、ループ判定処理152において、AS接続処理回数を取得し（1521）、AS接続処理回数が規定数以上の場合（1522：規定数以上）、判定部15は、ループ事象が発生していると判定し、ループが発生していることを通知するためのループ発生情報（S4）をセッション制御部14に送出する。これにより、セッション制御部14は、ループ検出後処理を行う。ループ検出後処理としては、例えば呼切断処理、または、ループが発生したことを通知し、ASの設定について確認するよう促すためのガイダンスを、システム管理者の端末装置に送出をすることなどが考えられる。
【００５３】
ここで、ループ判定処理152を設けている理由は、AS3から送信された当該AS3の提供サービスに則った呼確立要求信号を受信すると、本実施形態では呼確立要求信号の信号情報とiFCとを優先度が最も高いから順に比較しなおすため、AS3の提供サービスによっては、ループが発生する可能性があるためである。具体例については、図5を用いて後述する。
【００５４】
ループの検出方法としては、図３に示すように、AS接続処理を行う呼確立要求信号の中にAS接続処理回数が判別可能な情報を含めるようにし、AS接続処理回数が規定数以上になった時点でループ事象が発生したとみなす方法がある。
【００５５】
この方法の場合、実際にループとなる呼か否かに関わらず、AS接続処理の回数を制限することになる。そのため、ASサービスの実現に必要なAS接続処理回数と、ループ事象発生時にシステムに与える処理負荷の影響とを考慮して、AS接続処理回数の最大値（規定数）を決定する必要がある。
【００５６】
AS接続処理回数の最大値を決定する際の自由度を確保するため、AS接続処理を行う呼確立要求信号の中に含めるAS接続処理回数の情報は、AS接続処理回数を判別する目的のために使用する値を信号のヘッダ、あるいはパラメタに含める方法が好ましい。この場合、ループ判定処理152において、AS接続処理回数が規定数未満の場合（1522：規定数未満）、判定部15は、AS接続処理回数に「1」加算（または「1」減算）するなどして、AS接続処理回数を更新する。そして、更新後のAS接続処理回数は、接続先AS情報（S2）とともにSIP信号制御部13およびセッション制御部14に送信され、AS接続処理の呼確立要求信号に含まれてASに送信される。そして、更新後のAS接続処理回数は、接続されたAS3のCSCF接続処理による呼確立要求信号に含まれて送信され、判定部15は、当該呼確立要求信号に含まれるAS接続処理回数を取得する（1521）。
【００５７】
また、システムの処理負荷耐性に余裕があり、かつASがProxyとして処理を行うタイプのASである場合は、例えば、RFC3261（SIP）に規定のMax-Forwardヘッダ値の減算機構（デフォルト値70から始まり、ノードを通過するたびに1ずつ減算されていき、0になった時点で呼確立要求信号が破棄される）を、AS接続処理回数の情報として用いることも可能である。
【００５８】
また、他のループ検出方法として、AS接続処理を行う一連の呼を識別する識別子を呼確立要求信号に含め、CSCFの判定部15が当該識別子を監視し、同一識別子の通過回数（出現回数）が規定数以上になった時点でループ事象が発生したとみなす方法が考えられる。
【００５９】
AS接続処理を行う一連の呼を識別する識別子は、セッション制御部14などが設定する3GPP TS23.218に規定のODI（Original Dialog Identifier）を用いる方法を用いてもよいし、独自の信号拡張による識別子を用いてもよい。
【００６０】
さらに、他のループ検出方法として、AS接続処理を行う度に、当該AS接続処理の呼確立要求信号に含まれる、AS接続処理を行う一連の呼を識別する識別子と、着信先アドレスと、発信元アドレスとを1組（1レコード）としてCSCF−A1の識別子記憶部（不図示）に記憶し、当該識別子記憶部に記憶されたいずれかの組（レコード）の識別子、着信先アドレスおよび発信元アドレスと一致する呼確立要求信号が通過（検出）する場合に、ループが発生したとみなす方法がある。この方法で用いる識別子は、前述のODIを用いる方法でもよいし、独自の信号拡張を行う方法でもよい。
【００６１】
ループ検出後処理の方法としては、図3に示したように、AS3の設定について確認するよう促すガイダンスを送出するものがある。また、他のループ検出後処理方法としては、呼を切断するものがある。
【００６２】
なお、ループ検出処理およびループ検出後処理は、AS接続処理によりCSCFからASへ呼接続要求信号を送信する前に実施するか、あるいはCSCF接続処理によりASからCSCFが呼接続要求信号を受信した後に実施してもよい。
【００６３】
図4は、CSCF−A1の判定部15の具体的な処理例（ループなし）を説明するための図である。ここでは、iFC蓄積部12に蓄積された各iFCは次のとおりとする。またループ判定処理は、ASアクセス回数が規定数以上になったことでループが発生したとみなすものとする。
【００６４】
優先度1：iFC  01（接続先AS＃1  3a）着信先アドレスが0800番号（0800−123456）である場合にAS＃1  3aに接続する処理を行う。AS＃1  3a の提供サービスは0800番号を0AB〜Ｊに変換するものである。
【００６５】
優先度2：iFC  02（接続先AS＃2  3b）着信先アドレスが0120番号（0120−234567）である場合にAS＃2  3bに接続する処理を行う。AS＃2  3bの提供サービスは0120番号を0800番号に変換するものである。
【００６６】
優先度3：iFC  03（接続先AS＃3  3c）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃3  3cに接続する処理を行う。
【００６７】
優先度4：iFC  04（接続先AS＃4  3d）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃4  3dに接続する処理を行う。
【００６８】
優先度5：iFC  05（接続先AS＃5  3e）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃5  3eに接続する処理を行う。
【００６９】
図４に示す判定部15の処理は、端末装置4から送信された呼確立要求信号の着信先アドレス（ここでは0120−234567とする）、発信元アドレスおよびサービス要求内容をもとに行われる。ただし、ここでは着信先アドレスと合致するiFCは存在するが、発信元アドレスおよびサービス要求内容等と合致するiFCは存在しないものとして説明する。
【００７０】
まず、判定部15は、セッション制御部14から、端末装置4から送信された呼確立要求信号の着信先アドレス（0120−234567）、発信元アドレス、サービス要求内容等を含む信号情報（S1）を受け付け、これらの信号情報と優先度1のiFC  01とを比較し、合致しないのでスキップする。そして、判定部15は、優先度2のiFC  02と信号情報と比較し、着信先アドレス（0120−234567）が合致するため、ループ処理判定152を行う。ループ処理判定152において、ASアクセス回数が規定数に達しないため（すなわち、ループなしと判定され）、AS＃2  3bへの接続先AS情報（S2）をセッション制御部14に送出する（以上の処理は、図４の（1）で示す矢印の流れである。）。
【００７１】
そして、判定部15は、セッション制御部14から、AS＃2  3bから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1A）を受け付ける。この着信先アドレスは、AS＃2  3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス（0800−123456）と、優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないので（すなわち、ループなしと判定され）、AS＃1  3aへの接続先AS情報をセッション制御部14に送出する（以上の処理は、図４の（2）で示す矢印の流れである。）。
【００７２】
そして、判定部15は、セッション制御部14から、AS＃1  3ａから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1A）を受け付ける。この着信先アドレスは、AS＃1  3aの提供するサービスにより、0800−123456から0AB〜Ｊ（物理アドレス）に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス（0AB〜Ｊ）と優先度が最も高いiFC01とを比較し、今度は合致しないのでスキップし、次に優先度2のiFC  02とを比較し、合致しないのでスキップし、次に優先度3のiFC  03とを比較し、合致しないのでスキップし、次に優先度4のiFC  04と比較し、合致しないのでスキップし、次に優先度5のiFC  05と比較し、合致しないのでスキップする。全てのiFCについて判定が終了すると、判定部15は、判定結果に従った判定後の着信先アドレス(0AB〜Ｊ)、発信元アドレスおよびサービス要求内容等（S3）を、セッション制御部14に送出する。なお、この着信先アドレス(0AB〜Ｊ)、発信元アドレスおよびサービス要求内容等は、AS＃1  3ａから送信された呼確立要求信号の信号情報と同じものである（以上の処理は、図４の（3）で示す矢印の流れである。）。
【００７３】
図5は、CSCF−A1の判定部15の具体的な処理例（ループあり）を説明するための図である。ここでは、iFC蓄積部12に蓄積された各iFCは次のとおりとする。またループ判定処理は、ASアクセス回数が規定数以上になったことでループ事象が発生したとみなすものとする。
【００７４】
優先度1：iFC  01（接続先AS＃1  3a）着信先アドレスが0800番号（0800−123456）である場合にAS＃1  3aに接続する処理を行う。ここでのAS＃1  3a の提供サービスは0800番号を0120番号（0120−234567）に変換するものである。
【００７５】
優先度2：iFC  02（接続先AS＃2  3b）着信先アドレスが0120番号（0120−234567）である場合にAS＃2  3bに接続する処理を行う。AS＃2  3bの提供サービスは0120番号を0800番号（0800−123456）に変換するものである。
【００７６】
優先度3：iFC  03（接続先AS＃3  3c）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃3  3cに接続する処理を行う。
【００７７】
優先度4：iFC  04（接続先AS＃4  3d）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃4  3dに接続する処理を行う。
【００７８】
優先度5：iFC  05（接続先AS＃5  3e）発信元アドレスおよびサービス要求内容等が合致した場合にAS＃5  3eに接続する処理を行う。
【００７９】
図５に示す判定部15の処理は、端末装置4から送信された呼確立要求信号の着信先アドレス（ここでは0120−234567とする）、発信元アドレスおよびサービス要求内容をもとに行われる。ただし、ここでは着信先アドレスと合致するiFCは存在するが、発信元アドレスおよびサービス要求内容等と合致するiFCは存在しないものとして説明する。
【００８０】
まず、判定部15は、セッション制御部14から、端末装置4から送信された呼確立要求信号の着信先アドレス（0120−234567）、発信元アドレス、サービス要求内容等を含む信号情報（S1）を受け付け、これらの信号情報と優先度1のiFC  01とを比較し、合致しないのでスキップする。そして、判定部15は、信号情報と優先度2のiFC  02と比較し、着信先アドレス（0120−234567）が合致するため、ループ処理判定152を行う。ループ処理判定152において、ASアクセス回数が規定数に達しないため（すなわち、ループなしと判定され）、AS＃2  3bへの接続先AS情報をセッション制御部14に送出する（以上の処理は、図5の（1）で示す矢印の流れである。）。
【００８１】
そして、判定部15は、セッション制御部14から、AS＃2  3bから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1A）を受け付ける。この着信先アドレスは、AS＃2  3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス（0800−123456）と優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないためループなしと判定され、AS＃1  3aへの接続先AS情報をセッション制御部14に送出する（以上の処理は、図４で（2）で示す矢印の流れである。）。
【００８２】
そして、判定部15は、セッション制御部14から、AS＃1  3ａから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1A）を受け付ける。この着信先アドレスは、AS＃1  3aの提供するサービスにより、0800−123456から0120−234567に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス（0120−234567）と優先度が最も高いiFC01とを比較し、今度は合致しないのでスキップする。次に変更後の着信先アドレス（0120−234567）と優先度2のiFC  02とを比較し、今度も合致するためループ処理判定152を行い、ASアクセス回数が規定数に達しないためループなしと判定され、AS＃2  3bへの接続先AS情報をセッション制御部14に送出する（以上の処理は、図5の（3）で示す矢印の流れであるが、前述の(1)の流れと同様である。）。
【００８３】
そして、判定部15は、セッション制御部14から、AS＃2  3bから送信された呼確立要求信号の着信先アドレス、発信元アドレスおよびサービス要求内容等を含む信号情報（S1A）を受け付ける。この着信先アドレスは、AS＃2  3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス（0800−123456）と優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないためループなしと判定され、AS＃1  3aへの接続先AS情報をセッション制御部14に送出する（以上の処理は、図４で（4）で示す矢印の流れであるが、前述の(2)の流れと同様である。）。
【００８４】
そして、判定部15は、セッション制御部14から、AS＃1  3aの提供するサービスにより変更された変更後の着信先アドレス（0120−234567）、発信元アドレスおよびサービス要求内容を含む信号情報（S1A）を受け付ける。
【００８５】
以上の流れにより、同じ動作を何度も繰り返すループ事象が発生し、ASアクセス回数が規定数に達する。これにより、判定部15は、ループ判定処理152においてループありと判定し、ループ発生情報（S4）をセッション制御部14に送出し、セッション制御部14がループ検出後処理を行う。
【００８６】
次に、CSCF−A1の動作について説明する。
【００８７】
［CSCF−A1の動作］
図6は、CSCF−A1の動作の一例を示すフローチャートである。図2の構成において、図3の処理を基本とした図4および図5の処理の流れを説明するものである。なお図6では、図3のiFC判定処理151およびループ判定処理152は簡略化した表現にしている。
【００８８】
CSCF−A1のSIP信号制御部13が、端末装置4から送信される呼確立要求信号を受信し、セッション制御部14に送出する（ステップA1）。セッション制御部14は、呼確立要求信号を解析し、当該信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1）を判定部15に送出する（ステップA2）。判定部15は、送出された信号情報の発信元アドレスを用いて、サービス契約情報蓄積部11から該当するユーザのサービス契約情報を読み出し（ステップA3）、iFC蓄積部12から該当するユーザが契約する各サービスのiFCを読み出し、該当するユーザのサービス契約情報に対応したiFCを決定する（ステップA4）（以上の処理は、図6で（1）で示す矢印の流れである。）。
【００８９】
そして、判定部15は、ステップA4で決定した各iFCと、ステップA2で送出された信号情報（着信先アドレス、発信元アドレスおよびサービス要求内容等）とを比較し、合致するか否かを判定する（ステップA5）（以上の処理は、図6で（2）で示す矢印の流れである。）。
【００９０】
そして、判定部15は、いずれかのiFCと合致すると判定した場合（ステップA5：YES）、ループが発生していないか否かを判定し（ステップA6）、ループが発生していないと判定した場合は（ステップA6：NO）は、当該iFCで指定されたAS3に接続するための接続先AS情報（S2）をセッション制御部14に送出する。セッション制御部14は、当該AS3に接続するための呼確立要求信号を構成し（組み立て）、SIP信号制御部13に送出する（ステップA7）。SIP信号制御部13は、当該呼確立要求信号をAS3に送信する（ステップA8）（以上の処理は、図6で（3）で示す矢印の流れである。）。
【００９１】
そして、SIP信号制御部13は、AS3から送信される、AS3が提供するサービスに則った呼確立要求信号を受信し、セッション制御部14に送出する（ステップA1）。セッション制御部14は、送出された呼確立要求信号を解析し、当該信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報（S1A）を判定部15に送出する（ステップA2）（以上の処理は、図6で（4）で示す矢印の流れである。）。
【００９２】
判定部15は、ステップA4で決定した各iFCと、ステップA2で送出された信号情報とを比較し、合致するか否かを判定する（ステップA5）。そして、合致しないと判定した場合（ステップA5：NO）、判定部15は、未判定のiFC が存在するか否かを判定し（ステップA9）、未判定のiFCについて合致するか否かを判定する（ステップA5）。全ての未判定のiFCについて合致するか否かの判定処理を終了すると（ステップA9：NO）、判定終了後の着信先アドレス、発信元アドレス、サービス要求内容等（S3）を、セッション制御部14に送出する。セッション制御部14は、端末装置4あるいは他CSCF−A（不図示）に接続するための呼確立要求信号を構成し（組み立て）、SIP信号制御部13に送出する（ステップA7）。SIP信号制御部13は、端末装置4あるいは他CSCF−A（不図示）に呼確立要求信号送信する（ステップA8）（以上の処理は、図6で（5）で示す矢印の流れである。）。
【００９３】
また、ステップA6においてループが発生していると判定した場合（ステップA6：YES）、判定部15は、ループ発生情報（S4）をセッション制御部14に送出する。これにより、セッション制御部14は、例えば、所定のガイダンスを端末装置4に送信するための呼確立要求信号号を構成し（組み立て）、SIP信号制御部13に送出する（ステップA7）。SIP信号制御部13は、所定のガイダンスを送出するための呼確立要求信号を送信する（ステップA8）。（以上の処理は、図6で（6）で示す矢印の流れである。）
次に、本実施形態のシステムの動作について説明する。
【００９４】
［システムの動作］
図7は、図1におけるシステムの動作の一例を示すシーケンスチャートである。同図は、端末装置4、CSCF−A1およびAS3の間のシーケンスを示している。
【００９５】
端末装置4が、呼確立要求信号を送信し（ステップB1）、CSCF−A1のSIP信号制御部13が当該呼確立要求信号を受信する(ステップB2)。そして、判定部15が、着信先アドレス、発信元アドレス、サービス要求内容等と、各iFCとを比較し、合致するか否かを判定する（ステップB3）。合致するiFCが存在する場合（ステップB3:YES）、判定部15は、ループが発生しているか否かを判定する（ステップB4）。
【００９６】
ループが発生していない場合（ステップB4:NO）、SIP信号制御部13は、AS3に呼確立要求信号を送信する（ステップB5）。AS3は、呼確立要求信号を受信し、所定のサービスを提供（実行）し、提供したサービスに則った呼確立要求信号をCSCF−A1に送信する（ステップB6）。SIP信号制御部13は、AS3が送信した呼確立要求信号を受信し(ステップB7)、判定部15は、AS3が提供したサービスに則った着信先アドレス、発信元アドレス、サービス要求内容等と、各iFCとを比較する（ステップB3）。このステップB3の比較は、未判定のiFCが存在する場合（ステップB8:YES）、繰り返し行われる。合致するiFCが存在することなく、全てのiFCについてステップB3の比較が終了すると（ステップB8:NO）、判定終了後の着信先アドレス、発信元アドレス、サービス要求内容等を含む呼確立要求信号をSIP信号制御部13が端末装置4あるいは他CSCF−A（不図示）に送信する（ステップB9）。
【００９７】
また、ステップB4において、ループが発生していると判断された場合（ステップB4:YES）、SIP信号制御部13は端末装置4に所定のガイダンスを送出するための呼確立要求信号を送信する（ステップB10）。
【００９８】
なお、図7の中では呼確立要求信号の例としてINVITEメソッドを記載しているが、呼確立要求信号はMESSAGEメソッド等を含むSIP信号である。
【００９９】
以上説明した本実施形態のCSCF−A1では、呼確立要求信号の信号情報（着信先アドレス、発信元アドレス、サービス要求内容等）と各iFC （接続条件）とを、優先度の高い順番に条件に合致するか否かを判定し、合致した場合は、ループ事象が発生していないことを確認してAS接続処理を行い、ASのCSCF接続処理によりAS3から送信された呼確立要求信号を受信すると、先に合致したiFCの優先度の高低に関わらず、呼確立要求信号の信号情報とiFCとを優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。
【０１００】
すなわち、ASのCSCF接続処理によりASからCSCFが受信した呼接続要求信号については、判定済みiFCについてもiFC判定対象に含め、先に合致したiFCの優先度の高低に関わらず、ASから送信された呼確立要求信号の内容とiFCとを優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。
【０１０１】
これにより、本実施形態では、CSCF側の優先度の設定方法と、AS側のサービス提供の仕方（仕様）とが整合していない場合であっても、呼損となることを回避することができる。そのため、CSCF側とAS側とでは、それぞれ独自に優先度や提供の仕方を決定することができる。すなわち、CSCF側では、着信先アドレス、発信元アドレスおよびサービス要求内容を考慮することなく、iFC蓄積部12に蓄積される各iFCの優先度を自由に設定することができ、設定した優先度に従って判定処理を行うことができる。
【０１０２】
また、判定済みiFCについてもiFC判定対象に含めることにより、ASのサービス提供内容によっては、ループ事象が発生する場合が考えられることため、ループ事象の検出処理、およびループを防止するループ検出後処理を行う。これにより、ループ事象の発生を確実に防止することができる。
【０１０３】
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態のCSCF−A1では、判定部15は、呼確立要求信号の内容とiFCとを優先度の最も高いiFCから順番に比較し、いずれかのiFCと合致する場合、ループ判定処理を行うこととした（図３：ループ判定処理152）。しかしながら、本発明はこれに限定されることなく、例えば、AS側でループするような呼確立要求信号をCSCFに送信しない仕様とすることなどにより、ループ判定処理を行うことなく、AS接続処理を行うこととしてもよい。
【符号の説明】
【０１０４】
１  ：ＣＳＣＦ−Ａ
１１：サービス契約情報蓄積部
１２：iFC蓄積部
１３：SIP信号制御部
１４：セッション制御部
１５：判定部
３  ：AS
４  ：端末装置
【図１】
2011254423.tif 000003
【図２】
2011254423.tif 000004
【図３】
2011254423.tif 000005
【図４】
2011254423.tif 000006
【図５】
2011254423.tif 000007
【図６】
2011254423.tif 000008
【図７】
2011254423.tif 000009
【図８】
2011254423.tif 000010