(57)【要約】【課題】接続遅延と不要なＩＰバージョン変換の発生を減少させることができる呼制御処理システム、ゲートウェイ装置、呼制御処理方法およびプログラムを提供する。【解決手段】呼制御処理システム１は、発網２１にＳＢＣ３１を設置する。ＳＢＣ３１は、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部３１１と、接続先ドメイン毎に、算出部３１１で用いる閾値を設定する閾値設定部３１２と、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部３１３と、算出した比率が閾値を超えている場合、発端末からセッション開始オファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した比率が閾値を超えていない場合、バージョン変換部３１３によりオファーを含む呼制御プロトコル信号を下位バージョンに変換して着端末に送信する制御部３１４と、を備える。【選択図】図１
2017005466.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間にゲートウェイ装置を具備する呼制御処理システムであって、
前記ゲートウェイ装置は、
他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部と、
接続先ドメイン毎に、前記算出部で用いる閾値を設定する閾値設定部と、
ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部と、
算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、
算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換部を介して下位バージョンに変換して着端末に送信する制御部と、を備える
ことを特徴とする呼制御処理システム。
【請求項２】
前記端末は、ＩＰバージョンがIPv4および／またはIPv6に対応可能であり、発呼時に前記第１通信網ではIPv6が優先使用され、前記第２通信網にはIPv6未対応の端末が存在する場合において、
前記制御部は、
算出した前記比率が前記閾値を超えているならば、IPv6のオファーを透過し、
算出した前記比率が前記閾値を超えていないならば、前記バージョン変換部を介してIPv6のオファーをIPv4に変換して送信する
ことを特徴とする請求項１に記載の呼制御処理システム。
【請求項３】
前記算出部は、着側からのＩＰバージョン不一致を示すレスポンスの数を測定して、前記ＩＰバージョンが上位バージョンに対応するか否かの比率を算出する
ことを特徴とする請求項１または請求項２に記載の呼制御処理システム。
【請求項４】
前記閾値設定部は、
接続先ドメインに対する前記オファーの平均遅延時間が大きい場合、前記閾値を大きくするように設定し、
前記平均遅延時間が小さい場合、前記閾値を小さくするように設定する
ことを特徴とする請求項１ないし請求項３のいずれか１項に記載の呼制御処理システム。
【請求項５】
複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置であって、
他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部と、
接続先ドメイン毎に、前記算出部で用いる閾値を設定する閾値設定部と、
ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部と、
算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、
算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換部を介して下位バージョンに変換して着端末に送信する制御部と、を備える
ことを特徴とするゲートウェイ装置。
【請求項６】
複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置が実行する呼制御処理方法であって、
他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出ステップと、
接続先ドメイン毎に、前記算出ステップで用いる閾値を設定する閾値設定ステップと、
ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換ステップと、
算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、
算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換ステップにより下位バージョンに変換して着端末に送信する制御ステップと、
を含むことを特徴とする呼制御処理方法。
【請求項７】
複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置としてのコンピュータを、
他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出手段、
接続先ドメイン毎に、前記算出手段で用いる閾値を設定する閾値設定手段、
ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換手段、
算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、
算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換手段を介して下位バージョンに変換して着端末に送信する制御手段、として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御処理システム、ゲートウェイ装置、呼制御処理方法およびプログラムに関する。
【背景技術】
【０００２】
呼制御プロトコルであるＳＩＰ（Session Initiation Protocol-RFC3261）を利用した通信では、ＳＩＰだけでなく、音声等のメディアの情報等を記述するためのＳＤＰ（Session Description Protocol RFC2327）や、メディアパケットを伝達するためのＲＴＰ（Real-time Transport Protocol RFC2327）など様々なプロトコルが合わせて用いられる。なお、ＳＤＰとは、セッションの招待（INVITE）などを必要とするマルチメディアセッションを開始するために、必要な情報を記述するためのプレゼンテーション層に属するプロトコルである。
ある通信に用いられるメディア情報は、発端末と着端末との間でＳＤＰオファー／アンサーのネゴシエーション（RFC3264）により決定される。オファー側（通常はinitial-INVITEを生成する発端末側）は、利用するＩＰ（Internet Protocol）アドレスや受信可能なコーデック等のメディア情報をＳＩＰメッセージ中のＳＤＰに含めて送信する。アンサー側（通常は着端末側）は、ＳＤＰオファーに含まれる選択技の中からコーデック等の能力を選択し、自身が受信するメディア情報をＳＤＰに含めて返信する。
【０００３】
なお、端末にはＳＩＰ／ＳＤＰメッセージの送受信に用いられるC-Plane（一般にControl-Plane、制御プレーンとも呼ばれる）のＩＰアドレスと、メディアパケットの送受信に用いられるU-Plane（一般にUser-Plane、ユーザプレーンとも呼ばれる）のＩＰアドレスが必要となる。C-PlaneのＩＰアドレスはＳＩＰヘッダフィールド内のContactヘッダやViaヘッダ等に設定され、U-PlaneのＩＰアドレスはＳＤＰ内の“c=”行に設定される。
【０００４】
ＳＩＰを利用した通信網（３ＧＰＰで規定されるＩＭＳ（IP Multimedia Subsystem）等）が相互に接続する場合、対応するＩＰバージョンが異なる通信網やＳＩＰ端末が混在することが想定される（非特許文献１参照）。以下、具体的に説明する。
それぞれ異なる通信網に収容されている２つのＳＩＰ端末があり、オファー側、アンサー側の端末条件は、下記であると想定する。
【０００５】
オファー側（ＳＩＰ網Ａに収容）：C/U-Plane両方ともIPv4（Internet Protocol version 4）とIPv6（Internet Protocol version 6）両方のＩＰバージョンに対応している。
アンサー側（ＳＩＰ網Ｂに収容）：C-PlaneはIPv4とIPv6両方のＩＰバージョンに対応しているが、U-PlaneはIPv4アドレスのみが利用可能である。
【０００６】
ここで、VoIP（Voice over Internet Protocol）網において発着端末間の通信で利用するＩＰバージョンは発側と着側のＳＤＰネゴシエーションで決定される。
一般的に、オファー側はIPv4とIPv6両方のＩＰバージョンに対応している場合、IPv6アドレスを優先して利用する。例えば、VoLTE（Voice over Long Term Evolution）端末（GSMA IR.92準拠）では、IPv4とIPv6のデュアルスタックが必須であり、IPv6アドレスを優先的に用いて発信される。そのためこのようなケースは移動体のVoLTE網と固定網を相互接続する際に一般的に発生しうる。
オファー側はC/U-PlaneにIPv6のＩＰアドレスを設定してＳＤＰオファーを含むＳＩＰメッセージを送信した場合、アンサー側のU-PlaneはIPv6に対応しておらず、ＩＰバージョンの不一致が生じる。ＩＰバージョンの不一致が生じた場合でも、通信を確立するために以下の従来技術１，２が存在する。
【０００７】
図１８は、上記従来技術１のフォールバック手順制御を示すシーケンス図である。発端末１１をオファー側、着端末１２をアンサー側とする。発端末１１は、携帯電話、スマートフォンやＰＤＡ（Personal Digital Assistant）である。着端末１２は、ＩＰ電話である。ここでは、発端末１１を発信側とし、着端末１２を着信側とする。
発端末１１は、IPv4とIPv6デュアルスタック端末であり、IPv6アドレスを利用し発信し、着端末１２は、IPv4にのみ対応している。ＳＩＰ網Ａ２１（発網）は、オファー側の端末を収容する通信網であり、IPv4とIPｖ6両方のＩＰバージョンに対応する。具体的には、ＳＩＰ網Ａ２１は、対向網に接続するＳＩＰサーバまたはルータである。ＳＩＰ網Ｂ２２（着網）は、アンサー側通信網であり、IPv4とIPv6両方のＩＰバージョンに対応している。ただし、U-PlaneはIPv4アドレスのみが利用可能である。
【０００８】
発端末１１は、着端末１２にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図１８のステップＳ１１：initial-INVITE(SDP_O1:IPv6)）。
着端末１２は、発端末１１にＩＰバージョンの不一致を示す300/301 warn-codeを含めた488 （Not Acceptable Here）レスポンスを返却する（図１８のステップＳ１２：488 Alternative Service (Warning: 301)）。これにより、アンサー側がIPv6アドレスに対応していないことをオファー側に通知することができる。
【０００９】
488レスポンスを受信したオファー側の発端末１１は、着端末１２にＡＣＫを返すとともに（図１８のステップＳ１３）、着端末１２に対してC/U-PlaneにIPv4のＩＰアドレスを設定して再オファーする（図１８のステップＳ１４：INVITE(SDP_O2:IPv4)）。なお、この手順は、RFC3261/TTC TS-1020に準拠するものである。
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１８のステップＳ１５）。“180”はリクエストを受信して、その処理の実行中であることを表す。
【００１０】
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図１８のステップＳ１６：PRACK）。
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図１８のステップＳ１７：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A2:IPv4))”の信号を発端末１１に返す（図１８のステップＳ１８：200 OK (INVITE)(SDP_A2:IPv4)）。“200”は成功応答であることを表す。
以上の呼制御処理を経て、ステップＳ２０でMedia(IPv4)による接続が行われる。
【００１１】
図１９は、上記従来技術２のオファー変換制御を示すシーケンス図である。発端末１１をオファー側、着端末１２をアンサー側とする。
発端末１１は、着端末１２に対しイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図１９のステップＳ２１：initial-INVITE(SDP_O1:IPv6)）。
ＳＩＰ網Ａ２１（発網）は、C/U-PlaneのIPv6アドレスをIPv4アドレスにＩＰバージョン変換し、ＩＰバージョン変換したイニシャルINVITEの信号を着端末１２に送る（図１９のステップＳ２２：initial-INVITE(SDP_O1:IPv4)）。なお、この手順は、3GPP TS 29.162に準拠するものである（非特許文献１参照）。
【００１２】
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１９のステップＳ２３）。
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図１９のステップＳ２４：PRACK）。
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図１９のステップＳ２５：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A1:IPv4))”の信号を発端末１１に返す（図１８のステップＳ２６：200 OK (INVITE)(SDP_A1:IPv4)）。
ＳＩＰ網Ａ２１は、200 OK (INVITE)のIPv4アドレスをIPv6アドレスにＩＰバージョン変換し、ＩＰバージョン変換したイニシャル200 OK (INVITE)の信号を着端末１２に送る（図１９のステップＳ２７：200 OK (INVITE)(SDP_A1:IPv6)）。
以上の呼制御処理を経て、ステップＳ２８でMedia(IPv6)およびMedia(IPv4)による接続が行われる。
【００１３】
このように、VoIP網のＳＩＰサーバまたはルータにおいて、経由する全ＳＩＰメッセージとＲＴＰパケットのＩＰバージョン変換をする。この例では、オファー側の端末を収容する通信網のＳＩＰサーバまたはルータ（ＳＩＰ網Ａ２１）において、C/U-PlaneのIPv6アドレスをIPv4アドレスに変換、またはIPv4アドレスをIPv6アドレスに変換して対向網とＳＩＰメッセージまたはＲＴＰパケットの送受信を行う。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】"3GPP TS 29.162 V7.4.0",(13頁)[online],2014-06-27, 3GPP Organizational Partners,[平成27年６月４日検索]，インターネット<URL:http://www.arib.or.jp/IMT-2000/V830Mar11/5_Appendix/Rel7/29/29162-740.pdf>
【非特許文献２】"TTC TS-1020 IMS事業者網間相互接続インタフェース",(55頁),[online], 2015-03-05, [平成27年６月４日検索]，インターネット< URL:http://www.ttc.or.jp/jp/document_list/pdf/j/TS/TS-1020v3.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１５】
しかしながら、上記従来技術１，２では、それぞれ以下の課題が存在する。
（１）図１８の呼制御（フォールバック手順）では、アンサー側（着端末１２）から488レスポンスを返却し、オファー側（発端末１１）では再オファーする。このため、ＳＩＰメッセージのリクエスト／レスポンスにかかる接続遅延が発生し、ユーザの体感品質が低下する。特に、着網においてIPv6未対応端末が多い場合には、影響が顕著に表れる。
（２）図１９の呼制御（オファー変換手順）では、不要なIPv6-IPv4変換が発生する懸念がある。特に、着網においてIPv6対応端末が多い場合には、無駄な処理が多くなる。
【００１６】
本発明は上記実状に鑑み、接続遅延と不要なＩＰバージョン変換の発生を減少させることができる呼制御処理システム、ゲートウェイ装置、呼制御処理方法およびプログラムの提供を課題とする。
【課題を解決するための手段】
【００１７】
前記した課題を解決するため、請求項１に記載の発明は、複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間にゲートウェイ装置を具備する呼制御処理システムであって、前記ゲートウェイ装置は、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部と、接続先ドメイン毎に、前記算出部で用いる閾値を設定する閾値設定部と、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部と、算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換部を介して下位バージョンに変換して着端末に送信する制御部と、を備えることを特徴とする呼制御処理システムとした。
【００１８】
また、請求項５記載の発明は、複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置であって、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部と、接続先ドメイン毎に、前記算出部で用いる閾値を設定する閾値設定部と、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部と、算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換部を介して下位バージョンに変換して着端末に送信する制御部と、を備えることを特徴とするゲートウェイ装置とした。
【００１９】
また、請求項６記載の発明は、複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置が実行する呼制御処理方法であって、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出ステップと、接続先ドメイン毎に、前記算出ステップで用いる閾値を設定する閾値設定ステップと、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換ステップと、算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換ステップにより下位バージョンに変換して着端末に送信する制御ステップと、を含むことを特徴とする呼制御処理方法とした。
【００２０】
また、請求項７記載の発明は、複数の端末をそれぞれ異なる第１通信網および第２通信網を介して相互接続し、前記第１通信網と前記第２通信網の間に設置されるゲートウェイ装置としてのコンピュータを、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出手段、接続先ドメイン毎に、前記算出手段で用いる閾値を設定する閾値設定手段、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換手段、算出した前記比率が前記閾値を超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した前記比率が前記閾値を超えていない場合、前記オファーを含む呼制御プロトコル信号を前記バージョン変換手段を介して下位バージョンに変換して着端末に送信する制御手段、として機能させるためのプログラムとした。
【００２１】
このようにすることで、他網の端末のＩＰバージョンに応じた相互接続を選択することができる。すなわち、フォールバック手順を減らすことで、メッセージのリクエスト／レスポンスにかかる接続遅延の発生を減少させて、ユーザの体感品質を向上させることができる。また、オファー変換手順を最適化することで、不要なＩＰバージョン変換の発生を減少させて、処理の効率化を図ることができる。
【００２２】
また、請求項２に記載の発明は、前記端末は、ＩＰバージョンがIPv4および／またはIPv6に対応可能であり、発呼時に前記第１通信網ではIPv6が優先使用され、前記第２通信網にはIPv6未対応の端末が存在する場合において、前記制御部は、算出した前記比率が前記閾値を超えているならば、IPv6のオファーを透過し、算出した前記比率が前記閾値を超えていないならば、前記バージョン変換部を介してIPv6のオファーをIPv4に変換して送信することを特徴とする呼制御処理システムとした。
【００２３】
このようにすることで、IPv4/IPv6両対応の端末とIPv4のみ対応する端末の両方を収容する通信網同士が相互接続する場合において、十分多くの端末がIPv6に対応している場合、IPv6のオファーは透過とし、多くの端末がIPv6に未対応の場合、IPv6のオファーはIPv4へ変換し送信するので、着網でIPv6未対応端末が多い場合に接続遅延を減らしてユーザの体感品質を向上させることができる。また、着網でIPv6対応端末が多い場合に不要なＩＰバージョン変換の発生を減少させて、処理の効率化を図ることができる。
【００２４】
また、請求項３記載の発明は、前記算出部は、着側からのＩＰバージョン不一致を示すレスポンスの数を測定して、前記ＩＰバージョンが上位バージョンに対応するか否かの比率を算出することを特徴とする呼制御処理システムとした。
【００２５】
このようにすることで、着側からのＩＰバージョン不一致を示すレスポンスの数を保存して、上位バージョン未対応比率を算出することができる。
【００２６】
また、請求項４記載の発明は、前記閾値設定部は、接続先ドメインに対する前記オファーの平均遅延時間が大きい場合、前記閾値を大きくするように設定し、前記平均遅延時間が小さい場合、前記閾値を小さくするように設定することを特徴とする呼制御処理システムとした。
【００２７】
このようにすることで、平均遅延時間の大小に応じて閾値を設定することができ、不要なＩＰバージョン変換の発生を減少させつつ、より一層、接続遅延の発生を減少させて、ユーザの体感品質を向上させることができる。
【発明の効果】
【００２８】
本発明によれば、接続遅延と不要なＩＰバージョン変換の発生を減少させることができる呼制御処理システム、ゲートウェイ装置、呼制御処理方法およびプログラムを提供することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態に係る呼制御処理システムを示す図であり、（ａ）は、本発明に係る実施形態の呼制御処理システムの構成を示す構成図、（ｂ）は、データベースのレコードレイアウトを示す図である。
【図２】本実施形態に係る呼制御処理システムの着信先の端末の大部分がIPv6に対応する場合の動作の概要を説明する図である。
【図３】本実施形態に係る呼制御処理システムの着信先の端末の大部分がIPv6に未対応の動作の概要を説明する図である。
【図４】本実施形態に係る呼制御処理システムの閾値の決定方法を説明する図である。
【図５】本実施形態に係る呼制御処理システムの閾値の決定方法を説明する図である。
【図６】本実施形態の呼制御処理システムの自網からオファーを受信した場合（IPv6未対応）の動作を示すシーケンス図である。
【図７】図６の対応表を示す図である。
【図８】本実施形態の呼制御処理システムの自網からオファーを受信した場合（IPv6対応）の動作を示すシーケンス図である。
【図９】図８の対応表を示す図である。
【図１０】本実施形態の呼制御処理システムの他網からオファーを受信した場合（IPv6未対応）の動作を示すシーケンス図である。
【図１１】図１０の対応表を示す図である。
【図１２】本実施形態の呼制御処理システムの他網からオファーを受信した場合（IPv6対応）の動作を示すシーケンス図である。
【図１３】図１２の対応表を示す図である。
【図１４】本実施形態の呼制御処理システムの自網からオファーを受信した場合（αIPv6が閾値ｙを超えているとき）の動作を示すシーケンス図である。
【図１５】図１４の対応表を示す図である。
【図１６】本実施形態の呼制御処理システムの自網からオファーを受信した場合（αIPv6が閾値ｙを超えていないとき）の動作を示すシーケンス図である。
【図１７】図１６の対応表を示す図である。
【図１８】従来技術のフォールバック手順制御を示すシーケンス図である。
【図１９】従来技術のオファー変換制御を示すシーケンス図である。
【発明を実施するための形態】
【００３０】
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における呼制御処理システム等について説明する。
図１（ａ）は、本発明に係る実施形態の呼制御処理システムの構成を示す構成図であり、図１（ｂ）は、データベース（ＤＢ）３２のレコードレイアウトを示す図である。
本実施形態は、IPv4とIPv6のデュアルスタック（例えばVoLTE網）と、他網のIPv6未対応端末を含む固定網等との相互接続技術に適用した例である。
図１（ａ）に示すように、呼制御処理システム１は、複数の端末（発端末１１および着端末１２）を、それぞれ異なる発網２１（第１通信網）および着網２２（第２通信網）を介して相互接続し、発網２１と着網２２の間にＳＢＣ（Session Border Controller）３１（ゲートウェイ装置）を備える。
呼制御処理システム１は、発端末１１が接続される発網２１と、着端末１２が接続される着網２２と、において使用される。
【００３１】
発端末１１は、ＩＰバージョンがIPv4とIPv6の両方に対応可能な端末である。発端末１１は、通話において、例えば、電話をかける側の携帯電話、スマートフォンやＰＤＡ等の携帯端末である。
着端末１２は、ＩＰバージョンがIPv4のみか、またはIPv4とIPv6に対応可能な端末である。着端末１２は、電話を受ける側のＩＰ電話等の固定電話である。
発網２１は、例えばVoLTE網からなるＳＩＰ網である。
着網２２は、例えば固定網等からなるＳＩＰ網である。
なお、発呼時にはIPv6が優先使用され、他網にはIPv6未対応の端末が存在する場合がある。
【００３２】
呼制御処理システム１は、発網２１と着網２２間に設置されたＳＢＣ３１と、ＳＢＣ３１からアクセスされ、データを蓄積するＤＢ（データベース）３２と、を備える。本実施形態では、ＳＢＣ３１は、発網２１に設置されている。また、発網２１が複数のＳＢＣ３１を備える構成もある。複数設置された各ＳＢＣ３１に呼制御処理に関するデータを供給するために、ＳＢＣ３１外にＤＢ３２を設置することが好ましいが、ＳＢＣ３１内に設置されるものでもよい。
【００３３】
ＳＢＣ３１は、算出部３１１と、閾値設定部３１２と、バージョン変換部３１３と、制御部３１４と、を備える。
算出部３１１は、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する。算出部３１１は、例えば、着側からのＩＰバージョン不一致を示すレスポンスの数を測定して、上位バージョン未対応比率を算出する。この上位バージョン未対応比率は、他網におけるIPv6未対応端末の比率である。算出部３１１によって、他網におけるIPv6未対応端末の比率が動的に算出される。
【００３４】
閾値設定部３１２は、接続先ドメイン毎に、算出部３１１で用いる閾値ｙを設定する。なお、閾値ｙの決定方法については後記する。
また、閾値設定部３１２は、通信網の特性、リソース、接続先ドメインの平均遅延時間、オペレータポリシにより閾値ｙを設定する。閾値設定部３１２は、接続遅延が大きい場合、閾値ｙを大きく設定し、接続遅延が小さい場合、閾値ｙを小さく設定する。なお、接続遅延を基に決定される閾値ｙの大小については後記する。
【００３５】
バージョン変換部３１３は、ＩＰアドレスのＩＰバージョンを下位バージョンに変換する。具体的には、バージョン変換部３１３は、制御部３１４の指示に従ってIPv6アドレスをIPv4アドレスに変換する。
【００３６】
制御部３１４は、算出部３１１が算出した比率と閾値設定部３１２が設定した閾値ｙとを比較して、IPv6のオファーを透過するフォールバック手順か、オファーを下位バージョンに変換するオファー変換手順のうち、いずれかの手順を選択する。この際、閾値ｙは、接続遅延を基に動的に設定されるので、当該選択は動的に変わる。
制御部３１４は、算出部３１１が算出した比率が閾値ｙを超えている場合、発端末からセッション開始のオファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した比率が閾値ｙを超えていない場合、オファーを含む呼制御プロトコル信号をバージョン変換部３１３を介して下位バージョンに変換して着端末に送信する制御を実行する。制御部３１４は、例えば、算出部３１１が算出した比率が閾値ｙを超えているならば、IPv6のオファーを透過し、算出した比率が閾値ｙを超えていないならば、IPv6のオファーをIPv4に変換して送信する。
【００３７】
ＤＢ３２は、図１（ｂ）に示すように、着網２２のドメイン（接続先事業者またはそのＩＰアドレス）毎のIPv4-IPv6対応状況をレコードとしてもつ。例えば、ドメイン「xxx.co.jp」のIPv4-IPv6対応状況は、IPv6対応が多い（αIPv6が閾値ｙを超えている）、ドメイン「yyy.com」のIPv4-IPv6対応状況は、IPv6対応が小さい（αIPv6が閾値ｙを超えていない）、などである。なお、IPv4-IPv6対応状況の算出の具体例については後記する。
【００３８】
以下、上述のように構成された呼制御処理システム１の呼制御処理方法について説明する。
本実施形態では、IPv4/IPv6両対応の端末を収容する発網２１（ＳＩＰ網）と、IPv4のみまたはIPv4/IPv6両対応の端末を収容する着網２２（ＳＩＰ網）とを相互接続する場合を例に採る。ＳＩＰ網（発網２１および着網２２）の間にＳＢＣ３１を設置し、ＳＢＣ３１でＩＰバージョン変換を行う手順の概要について述べる。
［呼制御処理システムの動作概要］
図２および図３は、呼制御処理システムの動作の概要を説明する図であり、図２は、着信先の端末の大部分がIPv6に対応する場合の動作例を、図３は、着信先の端末の大部分がIPv6に未対応の動作例をそれぞれ示す。
【００３９】
<IPv6対応割合の算出>
まず、他網の端末のIPv6対応割合（αIPv6）を算出する。
ＳＢＣ３１の算出部３１１（図１参照）は、他網におけるIPv6対応端末の比率を算出する。具体的には、算出部３１１は、488 （Not Acceptable Here）レスポンスの返却回数と、他網からのオファーのＩＰバージョンをドメイン（接続先事業者またはそのＩＰアドレス）毎に記録してIPv6対応割合（αIPv6）を算出する。
【００４０】
例えば、図２（ａ）の符号ａに示すように、着信先の端末（着端末１２）の大部分がIPv6に対応していることが算出される。この場合、図２（ｂ）に示すＤＢ３２（図１参照）には、IPv6対応が多い（αIPv6が閾値ｙを超えている）というIPv4-IPv6対応状況が保存される。図３（ａ）の符号ａ，ｂに示すように、着信先の端末（着端末１２）の大部分がIPv6に未対応であることが算出される。この場合、図３（ｂ）に示すＤＢ３２には、IPv6対応が小さい（αIPv6が閾値ｙを超えていない）というIPv4-IPv6対応状況が保存される。なお、閾値ｙの決定方法については後記する。
【００４１】
<着信先の端末の大部分がIPv6に対応する場合>
自網からinitial-INVITEを送信する場合の動作を例に採り説明する。
図２（ａ）の符号ａに示すように、着信先の端末（着端末１２）の大部分がIPv6に対応する場合、図２（ａ）の符号ｂに示すように、オファーのＩＰバージョンは変換せずに（すなわちIPv6-IPv4変換せずに）オファーを透過（流通）させる。
このように、他網の端末のIPv6対応割合（αIPv6）が閾値ｙを超えている場合には、十分多くの端末がIPv6に対応しているとして、IPv6のオファーは透過とする。
【００４２】
また、必要に応じてフォールバック接続（図１８参照）を行う。ここで、TTC TS-1020（非特許文献２参照）におけるIPv4-IPv6フォールバック接続について記述する。発網が着網で発呼した場合において、着網２２または着端末１２が要求されたIPv6による通信が不可と判断した場合には、発網２１には、Warningヘッダの値に300(Incompatible network protocol)または301(Incompatible network address formats)を設定した488(Not Acceptable Here)エラーレスポンスが着網２２から返却される。Warningヘッダの値に300または301を設定した488エラーレスポンスを受信した発網２１または発端末１１は、着網２２または着端末１２がIPv6を用いた通信が不可能と解釈してIPv4を用いて再発呼する。以上をIPv4-IPv6フォールバック接続と呼ぶ。
【００４３】
<着信先の端末の大部分がIPv6に未対応の場合>
自網からinitial-INVITEを送信する場合の動作を例に採り説明する。
図３（ａ）の符号ａ，ｂに示すように、着信先の端末（着端末１２）の大部分がIPv6に未対応の場合、図３（ａ）の符号ｃに示すように、接続遅延が過大となるので、オファーのＩＰバージョンを変更する（すなわちIPv6-IPv4変換を実行する）。
このように、他網の端末のIPv6対応割合（αIPv6）が閾値ｙを超えていない場合には、多くの端末がIPv6には未対応であるため、IPv6のオファーはIPv4へ変換して送信する。
【００４４】
［閾値ｙの決定方法］
閾値ｙは、接続先ドメインの端末のIPv6対応割合が多いと算出する指標である。閾値ｙは、網の特性・リソース（ＣＰＵ、メモリ）、接続先ドメインの平均遅延時間、オペレータポリシ等により決定される。
例えば、接続先ドメインの接続遅延tが大きい場合、ｙはtの関数で表される（ｙ＝ｆ（t））、ｔ'＞ｔのとき、ｆ（t'）＞ｆ（t）となる。
【００４５】
図４および図５は、呼制御処理システムの閾値ｙの決定方法を説明する図であり、図４は、接続遅延t（平均遅延時間）が比較的大きい場合の説明図、図５は、接続遅延tが比較的小さい場合の説明図である。
また、図４（ａ）は、接続遅延tが比較的大きい場合の構成例、図４（ｂ）は、図４（ａ）の構成おけるIPv4-IPv6対応割合を示す。
図４（ａ）に示すように、接続遅延tが比較的大きい場合の例として、呼制御処理システムは、発網２１と着網２２との間に、発網２１と着網２２とを中継する中継網２３を備えている。
中継網２３は、海底ケーブル、バックボーンネットワーク等である。
なお、接続遅延tは、中継網２３を介在する場合には限られず、平均遅延時間を算出できるものであればどのような遅延でもよい。
【００４６】
図４（ｂ）に示すように、算出部３１１は、IPv4-IPv6対応割合を、IPv6が６０％、IPv4が４０％であると算出する。
一方、図４（ａ）に示す構成例において、閾値設定部３１２は、接続遅延tが比較的大きい場合には、閾値ｙは大きく（例えばｙ＝０．７）設定する。
制御部３１４は、IPv4-IPv6対応割合と閾値ｙとの比較により、発端末１１からオファーを着端末１２に透過して送信するフォールバック手順か、オファーを下位バージョンに変換して着端末１２に送信するIPv6-IPv4変換手順（オファー変換手順）のうち、いずれかの手順を選択・実行する。バージョン変換部３１３は、ＩＰアドレスのＩＰバージョンを下位バージョンに変換する。
すなわち、図４（ａ）の符号ａに示すように、接続遅延ｔが大きい場合は、閾値ｙが大きく設定される。閾値ｙが大きく設定されれば、IPv6対応割合（αIPv6）が閾値ｙを超えないので、IPv6-IPv4変換手順が選択される。ＳＢＣ３１は、IPv6-IPv4変換を行うことで、フォールバック接続の発生は回避される。
【００４７】
図５（ａ）は、接続遅延tが比較的小さい場合の構成例、図５（ｂ）は、図５（ａ）の構成おけるIPv4-IPv6対応割合を示す。
図５（ｂ）に示すように、算出部３１１は、IPv4-IPv6対応割合を、図４（ｂ）と同様にIPv6が６０％、IPv4が４０％であると算出する。
一方、図５（ａ）に示す構成例において、閾値設定部３１２は、接続遅延tが比較的小さい場合には、閾値ｙは小さく（例えばｙ＝０．５）設定する。
制御部３１４は、IPv4-IPv6対応割合と閾値ｙとを比較する。制御部３１４は、図５（ｂ）に示すように、閾値ｙが小さく設定されれば、IPv6対応割合（αIPv6）が閾値ｙを超えるので、IPv6-IPv4変換手順を選択せず、フォールバック手順を実行する。フォールバック手順では、フォールバック接続が実行される。
このように、接続遅延tが比較的大きい場合には、閾値ｙは大きく設定し、接続遅延tが比較的小さい場合には、閾値ｙは小さく設定する。
上記接続遅延tを基にした閾値ｙの決定方法に加えて、あるいは代えて、閾値ｙは、オペレータポリシに関して、設備コストや接続品質の違いを考慮に入れて決定してもよい。
以上、接続遅延tを基にした閾値ｙの決定方法について説明した。
【００４８】
［呼制御処理システムの動作の具体例］
次に、本呼制御処理システム１の動作の具体例について説明する。
図６ないし図１７は、本実施形態の呼制御処理システムの具体例を示す図である。
まず、ＳＢＣ３１の動作の概要と、このＳＢＣ３１の動作に対応する図（シーケンス図および対応図）との関係について示す。
ＳＢＣ３１（図１）は、次の処理１と処理２とを実行する。
【００４９】
処理１では、他網端末のＩＰバージョン対応状況を把握する。
ａ．自網からオファーを受信した場合の動作（図６〜図９で説明）
IPv6のオファーは透過して、IPv6のオファーの回数と488レスポンスが返却された回数を保存する。
488レスポンス返却時はその往復遅延時間を保存する。
ｂ．他網からオファーを受信した場合の動作（図１０〜図１３で説明）
オファーのＩＰバージョンの割合を保存する。
【００５０】
処理２では、他網端末のＩＰバージョン対応状況に応じた手順を選択する。
ｃ．他網の端末のIPv6対応割合（αIPv6）を算出する。
ｄ．自網からオファーを受信した場合の動作
αIPv6が閾値ｙを超えている場合：十分多くの端末がIPv6に対応しているとして、IPv6のオファーは透過とする（図１４および図１５で説明）。
αIPv6が閾値ｙを超えていない場合：多くの端末がIPv6には未対応であるため、IPv6のオファーはIPv4へ変換し送信する（図１６および図１７で説明）。
【００５１】
<自網からオファーを受信した場合（IPv6未対応）の動作>
図６は、本実施形態の呼制御処理システムの自網からオファーを受信した場合（IPv6未対応）の動作を示すシーケンス図、図７は、その対応表を示す図である。
本実施形態は、IPv4/IPv6両対応の端末を収容する発網２１（ＳＩＰ網）と、IPv4のみまたはIPv4/IPv6両対応の端末を収容する着網２２（ＳＩＰ網）とを相互接続する場合におけるシーケンスである。このＳＩＰ網は、発端末１１が接続される発網２１と、着端末１２が接続される着網２２とからなり、ＳＩＰ網の間にＳＢＣ３１を設置する。ここでは、ＳＩＰ網Ａ２１内にＳＢＣ３１を設置する。発端末１１をオファー側、着端末１２をアンサー側とする。したがって、ＳＢＣ３１からみてＳＩＰ網Ａ２１が自網、ＳＩＰ網Ｂ２２が他網となる。
発端末１１は、IPv4とIPv6デュアルスタック端末であり、IPv6アドレスを利用し発信する。着端末１２は、IPv4にのみ対応している。ＳＩＰ網Ａ２１は、オファー側の端末を収容する通信網であり、IPv4/IPｖ6両方のＩＰバージョンに対応する。具体的には、ＳＩＰ網Ａ２１は、対向網に接続するＳＩＰサーバ・ルータである。ＳＩＰ網Ｂ２２は、アンサー側通信網であり、IPv4とIPv6両方のＩＰバージョンに対応している。ただし、U-PlaneはIPv4アドレスのみが利用可能である。
【００５２】
オファー側の端末は、C/U-PlaneにIPv6のＩＰアドレスを設定してＳＤＰオファーを含むＳＩＰメッセージを送信する。図６では、オファー側の端末は、発端末１１である。
発端末１１は、着端末１２にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図６のステップＳ１０１：initial-INVITE(SDP_O1:IPv6)）。
【００５３】
ＳＢＣ３１は、他網端末のＩＰバージョン対応状況を把握する。具体的には、ＳＢＣ３１は、IPv6のオファーは透過して、着端末１２にイニシャルINVITEの信号を送信する（図６のステップＳ１０２：initial-INVITE(SDP_O1:IPv6)）。なお、このオファー受信時を、後記する平均遅延時間Ｔ(ms)測定のための開始時間（図６のハッチング矢印の上端部参照）とする。
【００５４】
着端末１２は、オファー側（ＳＢＣ３１）にＩＰバージョンの不一致を示す300/301 warn-codeを含めた488 （Not Acceptable Here）レスポンスを返却する（図６のステップＳ１０３：488 Alternative Service (Warning: 301)）。
ＳＢＣ３１は、IPv6のオファーの回数と488レスポンスが返却された回数を保存する（図６のステップＳ１０４）。ここでは、ＳＢＣ３１は、着端末１２がIPv6アドレスに対応していないと算出する。そして、ＳＢＣ３１は、端末を収容する事業者（この場合、ＳＩＰ網Ｂ２２事業者）の「IPv6未対応」をインクリメントする。
【００５５】
図７を参照して具体的に説明する。ＳＢＣ３１は、図７の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。具体的には、図７の符号ａに示すように、発事業者が自網（ＳＩＰ網Ａ２１）のときの、他事業者からの488受信数から、IPv6未対応端末数をカウントする。例えば、ＳＩＰ網Ｂ２２事業者の「IPv6未対応」をインクリメントして、IPv6未対応端末数が「３０」から「３１」となる。さらに、図７の対応表には、事業者毎に平均遅延時間Ｔ(ms)と閾値ｙを保存する。ＳＩＰ網Ｂ２２事業者の平均遅延時間Ｔ(ms)は、「１５０」である。なお、平均遅延時間Ｔ(ms)については後記する。
【００５６】
ＳＢＣ３１は、着端末１２から受信したＩＰバージョンの不一致を示す300/301 warn-codeを含めた488 （Not Acceptable Here）レスポンスを発端末１１に送信する（図６のステップＳ１０５：488 Alternative Service (Warning: 301)）。これにより、アンサー側がIPv6アドレスに対応していないことをオファー側に通知することができる。
488レスポンスを受信したオファー側の発端末１１は、着端末１２にＡＣＫを返すとともに（図６のステップＳ１０６）、着端末１２に対してC/U-PlaneにIPv4のＩＰアドレスを設定して再オファーする（図６のステップＳ１０８：INVITE(SDP_O2:IPv4)）。
【００５７】
ＳＢＣ３１は、発端末１１から返されたＡＣＫを着端末１２に送信するとともに（図６のステップＳ１０７）、発端末１１からの再オファーを着端末１２に送信する（図６のステップＳ１０９：INVITE(SDP_O2:IPv4)）。なお、再オファー受信時を平均遅延時間Ｔ(ms)測定のための終了時間（図６のハッチング矢印の下端部参照）とする。
ＳＢＣ３１は、ＩＰバージョン不一致と再オファーによる接続遅延時間（最初のIPv6でのオファー受信時から、IPv4での再オファー受信時までの時間）を測定し、「平均遅延時間」として保存する（図６のステップＳ１１０）。
【００５８】
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図６のステップＳ１１１）。“180”はリクエストを受信して、その処理の実行中であることを表す。
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図６のステップＳ１１２：PRACK）。
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図６のステップＳ１１３：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A2:IPv4))”の信号を発端末１１に返す（図６のステップＳ１１４）。“200”は成功応答であることを表す。
以上の呼制御処理を経て、ステップＳ１１５でMedia(IPv4)による接続が行われる。
【００５９】
<自網からオファーを受信した場合（IPv6対応）の動作>
図８は、本実施形態の呼制御処理システムの自網からオファーを受信した場合（IPv6対応）の動作を示すシーケンス図、図９は、その対応表を示す図である。
発端末１１は、IPv4とIPv6デュアルスタック端末であり、IPv6アドレスを利用し発信し、着端末１２は、IPv4とIPv6に対応している。
【００６０】
発端末１１は、着端末１２にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図８のステップＳ２０１：initial-INVITE(SDP_O1:IPv6)）。
ＳＢＣ３１は、IPv6のオファーは透過して、着端末１２にイニシャルINVITEの信号を送信する（図８のステップＳ２０１：initial-INVITE(SDP_O1:IPv6)）。
【００６１】
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図８のステップＳ２０２）。
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図８のステップＳ２０３：PRACK）。
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図８のステップＳ２０４：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A1:IPv6))”の信号を発端末１１に返す（図８のステップＳ２０６：200 OK (INVITE)(SDP_A1:IPv6)）。
【００６２】
ＳＢＣ３１は、着端末１２がIPv6アドレスに対応していると算出する。ＳＢＣ３１は、端末を収容する事業者（この場合、ＳＩＰ網Ｂ２２事業者）の「IPv6対応」をインクリメントする（図８のステップＳ２０５）。
【００６３】
図９を参照して具体的に説明する。ＳＢＣ３１は、図９の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。具体的には、図９の符号ａに示すように、発事業者が自網（ＳＩＰ網Ａ２１）のときの、他事業者からの200 OK（INVITE）（ＳＤＰはIPv6）受信数から、IPv6対応端末数をカウントする。ＳＩＰ網Ｂ２２事業者の「IPv6対応」をインクリメントすることで、IPv6対応端末数が「５０」から「５１」となる。
以上の呼制御処理を経て、図８のステップＳ２０７でMedia(IPv6)による接続が行われる。
【００６４】
<他網からオファーを受信した場合（IPv6未対応）の動作>
図１０は、本実施形態の呼制御処理システムの他網からオファーを受信した場合（IPv6未対応）の動作を示すシーケンス図、図１１は、その対応表を示す図である。
着端末１２は、発端末１１にイニシャルINVITE（セッション開始要求）の信号をIPv4アドレスを利用して発信する（図１０のステップＳ３０１：initial-INVITE(SDP_O1:IPv4)）。
【００６５】
ＳＢＣ３１は、着端末（ここでは、発端末１１）にイニシャルINVITEの信号を送信する（図１０のステップＳ３０１：initial-INVITE(SDP_O1:IPv4)）。
このとき、ＳＢＣ３１は、発端末（ここでは、着端末１２）がIPv4アドレスにのみ対応していると算出する。ＳＢＣ３１は、端末を収容する事業者（この場合、ＳＩＰ網Ｂ２２事業者）の「発：他網」の「IPv6未対応」をインクリメントする（図１０のステップＳ３０２）。
【００６６】
図１１を参照して具体的に説明する。ＳＢＣ３１は、図１１の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。具体的には、図１１の符号ａに示すように、発事業者が他網（ＳＩＰ網Ｂ２２）のときの、initial-INVITE（ＳＤＰはIPv4）受信数から、IPv6未対応端末数をカウントする。initial-INVITE（ＳＤＰはIPv4）受信数から、IPv6未対応端末数をカウントすることで、IPv6未対応端末数が「４０」から「４１」となる。
【００６７】
着端末（ここでは、発端末１１）は、発端末（ここでは、着端末１２）に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１０のステップＳ３０３）。
発端末（ここでは、着端末１２）は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末（ここでは、発端末１１）に対して応答“PRACK”を返す（図１０のステップＳ３０４：PRACK）。
着端末（ここでは、発端末１１）は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図１０のステップＳ３０５：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A1:IPv4))”の信号を発端末（ここでは、着端末１２）に返す（図１０のステップＳ３０６：200 OK (INVITE)(SDP_A1:IPv4)）。
以上の呼制御処理を経て、ステップＳ３０７でMedia(IPv4)による接続が行われる。
【００６８】
<他網からオファーを受信した場合（IPv6対応）の動作>
図１２は、本実施形態の呼制御処理システムの他網からオファーを受信した場合（IPv6対応）の動作を示すシーケンス図、図１３は、その対応表を示す図である。
着端末１２は、発端末１１にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図１２のステップＳ４０１：initial-INVITE(SDP_O1:IPv6)）。
【００６９】
ＳＢＣ３１は、着端末（ここでは、発端末１１）にイニシャルINVITEの信号を送信する（図１２のステップＳ４０１：initial-INVITE(SDP_O1:IPv6)）。
このとき、ＳＢＣ３１は、発端末（ここでは、着端末１２）がIPv6アドレスに対応していると算出する。ＳＢＣ３１は、端末を収容する事業者（この場合、ＳＩＰ網Ｂ２２事業者）の「発：他網」の「IPv6対応」をインクリメントする（図１２のステップＳ４０２）。
【００７０】
図１３を参照して具体的に説明する。ＳＢＣ３１は、図１３の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。具体的には、図１３の符号ａに示すように、発事業者が他網（ＳＩＰ網Ｂ２２）のときの、initial-INVITE（ＳＤＰはIPv6）受信数から、IPv6対応端末数をカウントする。initial-INVITE（ＳＤＰはIPv6）受信数から、IPv6対応端末数をカウントすることで、IPv6対応端末数が「８０」から「８１」となる。
【００７１】
着端末（ここでは、発端末１１）は、発端末（ここでは、着端末１２）に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１２のステップＳ４０３）。
発端末（ここでは、着端末１２）は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末（ここでは、発端末１１）に対して応答“PRACK”を返す（図１２のステップＳ４０４：PRACK）。
着端末（ここでは、発端末１１）は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図１２のステップＳ４０５：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A1:IPv6))”の信号を発端末（ここでは、着端末１２）に返す（図１２のステップＳ４０６）。
以上の呼制御処理を経て、ステップＳ４０７でMedia(IPv6)による接続が行われる。
以上、処理１（他網端末のＩＰバージョン対応状況把握）について説明した。
次に、処理２（他網端末のＩＰバージョン対応状況に応じた手順選択）について説明する。
【００７２】
<自網からオファーを受信した場合（αIPv6が閾値ｙを超えているとき）の動作>
図１４は、本実施形態の呼制御処理システムの自網からオファーを受信した場合（αIPv6が閾値ｙを超えているとき）の動作を示すシーケンス図、図１５は、その対応表を示す図である。
発端末１１は、IPv4とIPv6デュアルスタック端末であり、IPv6アドレスを利用し発信し、着端末１２は、IPv4とIPv6に対応している。
発端末１１は、着端末１２にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図１４のステップＳ５０１：initial-INVITE(SDP_O1:IPv6)）。
【００７３】
ＳＢＣ３１は、他網の端末のIPv6対応割合（αIPv6）を算出する。
図１５を参照して他網の端末のIPv6対応割合（αIPv6）算出について説明する。ＳＢＣ３１は、図１５の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。ＳＢＣ３１は、接続先事業者（この場合、ＳＩＰ網Ｂ２２事業者）のIPv6対応端末数／全端末数を基に、IPv6対応割合（αIPv6）を算出する。具体的には、図１５の符号ａに示すように、自網のIPv6対応端末数「６０」と他網のIPv6対応端末数「９０」を足した（６０＋９０）を、全端末数（４０＋６０＋５０＋９０）で除してIPv6対応割合（αIPv6）を算出する。ここでは、接続先事業者（ＳＩＰ網Ｂ２２）のIPv6対応割合（αIPv6）は、０．６２５である。いま、図１５の符号ｂに示すように、IPv6対応端末数算出のための閾値ｙは、０．６が設定されている。したがって、ＳＩＰ網Ｂ２２事業者のIPv6対応割合（αIPv6）は、閾値ｙを超えている。なお、閾値ｙの決定方法については図４および図５により述べた。
【００７４】
ＳＢＣ３１は、図１５の符号ｂに示すように、αIPv6が閾値ｙを超えているので、十分多くの端末がIPv6に対応しているとして、IPv6のオファーは透過とする。
ＳＢＣ３１は、IPv6のオファーは透過して、着端末１２にイニシャルINVITEの信号を送信する（図１４のステップＳ５０２：initial-INVITE(SDP_O1:IPv6)）。
【００７５】
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１４のステップＳ５０３）。
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図１４のステップＳ５０４：PRACK）。
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返し（図１４のステップＳ５０５：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A1:IPv6))”の信号を発端末１１に返す（図５０６のステップＳ２０６）。
以上の呼制御処理を経て、ステップＳ５０７でMedia(IPv6)による接続が行われる。
【００７６】
<自網からオファーを受信した場合（αIPv6が閾値ｙを超えていないとき）の動作>
図１６は、本実施形態の呼制御処理システムの自網からオファーを受信した場合（αIPv6が閾値ｙを超えていないとき）の動作を示すシーケンス図、図１７は、その対応表を示す図である。
発端末１１は、IPv4とIPv6デュアルスタック端末であり、IPv6アドレスを利用し発信し、着端末１２は、IPv4のみに対応している。
発端末１１は、着端末１２にイニシャルINVITE（セッション開始要求）の信号をIPv6アドレスを利用して発信する（図１６のステップＳ６０１：initial-INVITE(SDP_O1:IPv6)）。
【００７７】
ＳＢＣ３１は、他網の端末のIPv6対応割合（αIPv6）を算出する。
図１７を参照して他網の端末のIPv6対応割合（αIPv6）算出について説明する。ＳＢＣ３１は、図１７の対応表に示すように、接続先事業者（ＳＩＰ網Ｂ２２，ＳＩＰ網Ｃ(図示略)，…）に対して、発事業者：自網、発事業者：他網毎にIPv6未対応端末数／IPv6対応端末数をカウントして保存する。ＳＢＣ３１は、接続先事業者（この場合、ＳＩＰ網Ｂ２２事業者）のIPv6対応端末数／全端末数を基に、IPv6対応割合（αIPv6）を算出する。具体的には、図１７の符号ａに示すように、自網のIPv6対応端末数「５０」と他網のIPv6対応端末数「７０」を足した（５０＋７０）を、全端末数（５０＋５０＋５０＋７０）で除してIPv6対応割合（αIPv6）を算出する。ここでは、接続先事業者（ＳＩＰ網Ｂ２２）のIPv6対応割合（αIPv6）は、０．５５である。また、図１７の符号ｂに示すように、IPv6対応端末数算出のための閾値ｙは、０．６が設定されている。したがって、ＳＩＰ網Ｂ２２事業者のIPv6対応割合（αIPv6）は、閾値ｙを超えていない。
【００７８】
ＳＢＣ３１は、αIPv6が閾値ｙを超えていないので、多くの端末がIPv6には未対応であるとして、IPv6のオファーはIPv4へ変換して送信する。すなわち、ＳＢＣ３１は、C/U-PlaneのIPv6アドレスをIPv4アドレスにＩＰバージョン変換し、ＩＰバージョン変換したイニシャルINVITEの信号を着端末１２に送る（図１６のステップＳ６０２：initial-INVITE(SDP_O2:IPv4)）。このように、αIPv6が閾値ｙを超えていない場合、予めオファーをIPv6からIPv4に変換するものである。
着端末１２は、発端末１１に着信したことを知らせる暫定応答の“180 Ringing”の信号を返す（図１６のステップＳ６０３）。
発端末１１は、暫定応答の“180 Ringing”の情報が届くと保留音を発するとともに、着端末１２に対して応答“PRACK”を返す（図１６のステップＳ６０４：PRACK）。
【００７９】
着端末１２は、リクエストの成功を示す“200 OK(PRACK)”の信号を発端末１１に返す（図１６のステップＳ６０５：200 OK(PRACK)）、次いで“200 OK (INVITE)(SDP_A2:IPv4))”の信号を発端末１１に返す（図１６のステップＳ６０６）。
ＳＢＣ３１は、200 OK (INVITE)のIPv4アドレスをIPv6アドレスにＩＰバージョン変換し、ＩＰバージョン変換したイニシャル200 OK (INVITE)の信号を着端末１２に送る（図１６のステップＳ６０７：200 OK (INVITE)(SDP_A1:IPv6)）。このように、オファーをIPv6からIPv4に変換していた場合、アンサーはIPv4からIPv6に戻すようにする。
以上の呼制御処理を経て、ステップＳ６０８でMedia(IPv6)およびMedia(IPv4)による接続が行われる。
【００８０】
以上説明したように、呼制御処理システム１は、発網２１にＳＢＣ３１を設置する。ＳＢＣ３１は、他網における端末のＩＰバージョンが上位バージョンに対応するか否かの比率を算出する算出部３１１と、接続先ドメイン毎に、算出部３１１で用いる閾値を設定する閾値設定部３１２と、ＩＰアドレスのＩＰバージョンを下位バージョンに変換するバージョン変換部３１３と、算出した比率が閾値を超えている場合、発端末からセッション開始オファーを含む呼制御プロトコル信号を着端末に透過して送信し、算出した比率が閾値を超えていない場合、バージョン変換部３１３によりオファーを含む呼制御プロトコル信号を下位バージョンに変換して着端末に送信する制御部３１４と、を備える。
【００８１】
これにより、他網の端末のＩＰバージョンに応じた相互接続を選択することができる。すなわち、着信先の端末の大部分がIPv6に対応する場合は、オファーのＩＰバージョンは変換せず透過し、必要に応じてフォールバック接続を行う。逆に、着信先の端末の大部分がIPv6に未対応の場合は、接続遅延が課題となるので、オファーのＩＰバージョンを変更する。このように、フォールバック手順を減らすことで、ＳＩＰメッセージのリクエスト／レスポンスにかかる接続遅延の発生を減少させて、ユーザの体感品質を向上させることができる。また、オファー変換手順を最適化することで、不要なＩＰバージョン変換の発生を減少させて、処理の効率化を図ることができる。
【００８２】
また、本実施形態では、ＳＢＣ３１は、他網におけるIPv6対応端末の比率を算出し、αIPv6が閾値ｙを超えている場合には十分多くの端末がIPv6に対応しているとしてIPv6のオファーは透過し、αIPv6が閾値ｙを超えていない場合には多くの端末がIPv6には未対応であるため、IPv6のオファーはIPv4へ変換して送信するので、着網でIPv6未対応端末が多い場合に接続遅延を減らしてユーザの体感品質を向上させることができる。また、着網でIPv6対応端末が多い場合に不要なＩＰバージョン変換の発生を減少させて、処理の効率化を図ることができる。
【００８３】
また、本実施形態では、ＩＰバージョンの不一致を示す488レスポンスが返却された回数を保持することで、RFC3261/TTC TS-1020規格に準拠したシステム上で、上位バージョン未対応比率を算出することができる。
【００８４】
また、本実施形態では、接続遅延ｔが大きい場合、閾値ｙを大きく設定し、接続遅延ｔが小さい場合、閾値ｙを小さく設定する。例えば、接続遅延tが大きい場合は、IPv4-IPv6変換を行い、フォールバック制御を発生させないほうが望ましい。閾値yを大きくとれば、αIPv6が閾値を超えずIPv4-IPv6を行うことができる。このように、接続遅延ｔの大小に応じて閾値ｙを設定することができ、不要なＩＰバージョン変換の発生を減少させつつ、より一層、接続遅延の発生を減少させて、ユーザの体感品質を向上させることができる。
【００８５】
上記実施形態では、呼制御の一例として、ＳＩＰを例示して説明したが、他の呼制御プロトコルで本発明を構成してもよい。
【００８６】
また、上記実施形態では、記憶手段として、ＤＢ３２を例示したが、記憶手段であればよく、テーブル、一時ファイル等のデータベース以外の記憶手段を適用してもよい。
【００８７】
また、発端末１１としてＰＤＡ等の携帯端末を例示したが、固定電話でもよい。また、着端末１２として固定電話を例示したが、携帯電話、ＰＤＡ等の携帯端末でもよい。つまり、発端末１１、着端末１２は、携帯端末、固定電話等、通話が可能な端末ならば限定されない。
【００８８】
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【００８９】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
【符号の説明】
【００９０】
１  呼制御処理システム
１１  発端末
１２  着端末
２１  発網（第１通信網）(ＳＩＰ網)
２２  着網（第２通信網）(ＳＩＰ網)
２３  中継網
３１  ＳＢＣ（ゲートウェイ装置）
３２  データベース
３１１  算出部（算出手段）
３１２  閾値設定部（閾値設定手段）
３１３  バージョン変換部（バージョン変換手段）
３１４  制御部（制御手段）
【図１】
2017005466.tif 000003
【図２】
2017005466.tif 000004
【図３】
2017005466.tif 000005
【図４】
2017005466.tif 000006
【図５】
2017005466.tif 000007
【図６】
2017005466.tif 000008
【図７】
2017005466.tif 000009
【図８】
2017005466.tif 000010
【図９】
2017005466.tif 000011
【図１０】
2017005466.tif 000012
【図１１】
2017005466.tif 000013
【図１２】
2017005466.tif 000014
【図１３】
2017005466.tif 000015
【図１４】
2017005466.tif 000016
【図１５】
2017005466.tif 000017
【図１６】
2017005466.tif 000018
【図１７】
2017005466.tif 000019
【図１８】
2017005466.tif 000020
【図１９】
2017005466.tif 000021