(57)【特許請求の範囲】
【請求項１】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムであり、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す発呼予約装置を備え、
前記発呼予約装置は、
発呼側の無線端末および着呼側の無線端末の両方に対してアプリケーションサーバ側の無線回線のリソースが未確保であることを通知して着呼処理を行わせておき、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出し、
発呼側の無線端末からの着信応答があると、着呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出す、
ことを特徴とする通信制御システム。
【請求項２】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムであり、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す発呼予約装置と、
発呼側の無線端末からの発呼要求に対して受付応答を発呼側の無線端末に返した後に無線回線のリソースを確保できなかった場合に、当該発呼側の無線端末に対して同じ発呼要求を前記発呼予約装置へ送信するように要求する通信制御装置と、を備え、
前記発呼予約装置は、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行うものであり、
前記通信制御システムはＳＩＰ（Session Initiation Protocol）を使用し、
前記通信制御装置は、前記発呼側の無線端末からの「INVITEメッセージ」に対する前記着信側の無線端末からの「183 Session Progressメッセージ」を、当該呼の無線回線のリソースを確保する前に、前記発呼側の無線端末へ転送し、この後、当該呼の無線回線のリソースを確保できなかった場合に、「INVITEメッセージ」を新しい宛先URIへ送信することを指示する「301 Movedメッセージ」において該新しい宛先URIに前記発呼予約装置を示す「SIP URI」を使用して前記「301 Movedメッセージ」を前記発呼側の無線端末へ送信し、前記発呼側の無線端末からの「INVITEメッセージ」を取り消す「CANCELメッセージ」を前記着信側の無線端末へ送信する、
ことを特徴とする通信制御システム。
【請求項３】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御方法であり、
発呼予約装置が、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップを含み、
前記発呼予約装置は、
発呼側の無線端末および着呼側の無線端末の両方に対してアプリケーションサーバ側の無線回線のリソースが未確保であることを通知して着呼処理を行わせておき、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出し、
発呼側の無線端末からの着信応答があると、着呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出す、
ことを特徴とする通信制御方法。
【請求項４】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御方法であり、
通信制御装置が、発呼側の無線端末からの発呼要求に対して受付応答を発呼側の無線端末に返した後に無線回線のリソースを確保できなかった場合に、当該発呼側の無線端末に対して同じ発呼要求を発呼予約装置へ送信するように要求する第１のステップと、
前記発呼予約装置が、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う第２のステップと、
前記発呼予約装置が、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す第３のステップと、を含み、
前記通信制御方法はＳＩＰ（Session Initiation Protocol）を使用するものであり、
前記第１のステップにおいて、前記通信制御装置は、前記発呼側の無線端末からの「INVITEメッセージ」に対する前記着信側の無線端末からの「183 Session Progressメッセージ」を、当該呼の無線回線のリソースを確保する前に、前記発呼側の無線端末へ転送し、この後、当該呼の無線回線のリソースを確保できなかった場合に、「INVITEメッセージ」を新しい宛先URIへ送信することを指示する「301 Movedメッセージ」において該新しい宛先URIに前記発呼予約装置を示す「SIP URI」を使用して前記「301 Movedメッセージ」を前記発呼側の無線端末へ送信し、前記発呼側の無線端末からの「INVITEメッセージ」を取り消す「CANCELメッセージ」を前記着信側の無線端末へ送信する、
ことを特徴とする通信制御方法。
【請求項５】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御処理を行うためのコンピュータプログラムであって、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップ、をコンピュータに実行させるためのコンピュータプログラムであり、
前記ステップは、
発呼側の無線端末および着呼側の無線端末の両方に対してアプリケーションサーバ側の無線回線のリソースが未確保であることを通知して着呼処理を行わせておき、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出し、
発呼側の無線端末からの着信応答があると、着呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出す、
コンピュータプログラム。
【請求項６】
発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムが備える通信制御装置のコンピュータに、
発呼側の無線端末からの発呼要求に対して受付応答を発呼側の無線端末に返した後に無線回線のリソースを確保できなかった場合に、当該発呼側の無線端末に対して同じ発呼要求を発呼予約装置へ送信するように要求する第１のステップを実行させ、
前記通信制御システムが備える発呼予約装置のコンピュータに、
前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う第２のステップと、
発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す第３のステップと、を実行させるためのコンピュータプログラムであり、
前記通信制御システムはＳＩＰ（Session Initiation Protocol）を使用し、
前記第１のステップは、前記発呼側の無線端末からの「INVITEメッセージ」に対する前記着信側の無線端末からの「183 Session Progressメッセージ」を、当該呼の無線回線のリソースを確保する前に、前記発呼側の無線端末へ転送し、この後、当該呼の無線回線のリソースを確保できなかった場合に、「INVITEメッセージ」を新しい宛先URIへ送信することを指示する「301 Movedメッセージ」において該新しい宛先URIに前記発呼予約装置を示す「SIP URI」を使用して前記「301 Movedメッセージ」を前記発呼側の無線端末へ送信し、前記発呼側の無線端末からの「INVITEメッセージ」を取り消す「CANCELメッセージ」を前記着信側の無線端末へ送信する、
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御システム、通信制御方法、及びコンピュータプログラムに関する。
【背景技術】
【０００２】
従来、SIP（Session Initiation Protocol）は、IP（Internet Protocol）上における呼制御に用いられるプロトコルとして知られている。SIPには、端末間で通信に必要なIPアドレスやポート番号、エンコーディング等のネゴシエーション、発呼、着呼などの制御手順が規定されている。
【０００３】
又、SIPによる情報に基づいて通信に必要なネットワークリソースの割り当てやゲート制御を行うIMS（IP Multimedia Subsystem）が知られている。IMSでは、SIP処理を行うノードとして、複数のCSCF（Call Session Control Function）を定めている。P-CSCF（Proxy-CSCF）は、端末から直接接続されるノードであり、暗号化やメッセージのフィルタリング等を行う。I-CSCF（Interrogating CSCF）は、SIPのルーティングを行う際に、転送先の解決や、他のドメインへ転送するための処理を行う。S-CSCF（Serving-CSCF）は、端末の登録やアプリケーションサーバとの連携、通信相手の解決など、IMSの主要な機能を備える。
【０００４】
IMSを運用する際には、定常時に十分な処理能力を備えるように収容設計を行う。しかしながら、イベント時や災害時などの急激に呼が増加する場合には、IMSや端末が利用する無線アクセス回線の伝送帯域の能力を超えてしまい、呼が失敗し疎通率が低下する恐れがある。このような輻輳状態に対し、端末から発呼できないように規制すること（発呼規制）を行っている。この発呼規制時にユーザが繰り返し発呼操作を行うという不都合がある。
【０００５】
又、ユーザは、発呼先の移動ユーザが話中又は非登録であるのかが分からない場合にも、繰り返し発呼操作を行うという不都合がある。これに対して例えば特許文献１では、話中又は非登録であった発呼先の移動ユーザが終話したり登録されたりした時に、発呼者に対して発呼先の移動ユーザが利用可能であるメッセージを通知するとともに発呼者を呼び出している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−３５０２９４号公報
【非特許文献】
【０００７】
【非特許文献１】3GPP TS23.228 IP Multimedia Subsystem (IMS)
【非特許文献２】3GPP TS 24.642 Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、上述した従来の技術では、話中又は非登録であった発呼先の移動ユーザが終話したり登録されたりした時に発呼先の移動ユーザの無線回線の状況や発呼者である移動ユーザの無線回線の状況が分からないままに発呼者を呼び出すので、いざ通話しようとした時に無線回線の状態が悪くて通話できないという不都合が起こり得る。
【０００９】
本発明は、このような事情を考慮してなされたもので、発呼先の移動ユーザによる通信の応答が可能になった時に発呼者である移動ユーザを呼び出す際に、通信の実施の確実性を向上させることができる通信制御システム、通信制御方法、及びコンピュータプログラムを提供することを課題とする。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明に係る通信制御システムは、発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムであり、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す発呼予約装置を備えたことを特徴とする。
【００１１】
本発明に係る通信制御システムにおいて、前記発呼予約装置は、発呼側の無線端末および着呼側の無線端末の両方に対してアプリケーションサーバ側の無線回線のリソースが未確保であることを通知して着呼処理を行わせておき、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出し、発呼側の無線端末からの着信応答があると、着呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出す、ことを特徴とする。
【００１２】
本発明に係る通信制御システムにおいては、発呼側の無線端末からの発呼要求に対して受付応答を発呼側の無線端末に返した後に無線回線のリソースを確保できなかった場合に、当該発呼側の無線端末に対して同じ発呼要求を前記発呼予約装置へ送信するように要求する通信制御装置を備え、前記発呼予約装置は、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う、ことを特徴とする。
【００１３】
本発明に係る通信制御システムにおいては、発呼側の無線端末からの発呼要求に対して輻輳時又はエラー発生時に当該発呼要求を前記発呼予約装置へ転送する通信制御装置を備え、前記発呼予約装置は、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う、ことを特徴とする。
【００１４】
本発明に係る通信制御方法は、発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御方法であり、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップを含むことを特徴とする。
【００１５】
本発明に係るコンピュータプログラムは、発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御処理を行うためのコンピュータプログラムであって、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップ、をコンピュータに実行させるためのコンピュータプログラムであることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、発呼先の移動ユーザによる通信の応答が可能になった時に発呼者である移動ユーザを呼び出す際に、通信の実施の確実性を向上させることができるという効果が得られる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係る通信ネットワークシステムの概略構成図である。
【図２】本発明の一実施形態に係る機能構成図である。
【図３】本発明の一実施形態に係るINVITE段階での発呼予約の実施例である。
【図４】本発明の一実施形態に係るエラー発生時の発呼予約の実施例である。
【図５】本発明の一実施形態に係る非同期無線リソース確保失敗時の発呼予約の実施例である。
【図６】本発明の一実施形態に係る呼監視段階の実施例である。
【図７】本発明の一実施形態に係る予約発呼段階の実施例である。
【図８】本発明の他の実施形態に係る機能構成図である。
【図９】図８の実施形態に係る呼監視段階の実施例である。
【発明を実施するための形態】
【００１８】
以下、図面を参照し、本発明の実施形態について説明する。
図１は、本発明の一実施形態に係る通信ネットワークシステムの概略構成図である。図１において、IPネットワーク上にIMSが構築されている。IMSは、呼制御サーバであるP-CSCF（Proxy Call Session Control Function）＿６、I-CSCF（Interrogating CSCF）＿５およびS-CSCF（Serving CSCF）＿４と、加入者データベースであるHSS（Home Subscriber Server）＿３と、発呼予約AS（Application Server）＿１と、呼監視サーバ２を有する。これらのサーバは複数台あってもよい。無線端末であるUE（User Equipment）＿８は、基地局７を介してIMSに接続し、発呼して通話を行う。
【００１９】
図２は、本実施形態に係る機能構成図である。発呼予約AS＿１は、予約機能と自動発呼機能とAS機能を有する。予約機能は、失敗した呼などに対し、呼の予約を行う機能である。予約機能は、発呼者のUE＿８に対して、予約を行う旨のガイダンスを流し、発呼者からの了解を得て、着信者への発呼予約を行う。自動発呼機能は、予約された発呼を行う機能である。自動発呼機能は、3PCC（3rd Party Call Control）により発呼を行う際に、発呼者および着呼者の無線回線のリソースが確保でき、通話の準備が整ってから、呼び出しを行う（コール音を鳴らす）。発呼を行うタイミングは、呼監視サーバ２から通知される。AS機能は、iFC（initial Filter Criteria）を用いて、UE＿８が登録したときに通知を受けること、及び発呼時にINVITEメッセージを着信側の発呼予約AS＿１へ転送して処理を行う機能である。AS機能は、S-CSCF＿４とSIPを用いて通信を行う。
【００２０】
呼監視サーバ２は、SIP監視機能とUE監視機能と無線リソース監視機能と呼処理量監視機能と状態通知機能を有する。SIP監視機能は、IPネットワーク上を流れるSIPメッセージを読み取り、呼の監視を行う機能である。UE監視機能は、SIPメッセージから、各UE＿８の通話状態や登録状態を取得し、監視する機能である。無線リソース監視機能は、SIPメッセージから、各UE＿８が利用している基地局７と各UE＿８の呼数などを取得し、監視する機能である。呼処理量監視機能は、SIPメッセージから、IMS全体の呼の総量および各CSCFでの呼の処理量を取得し、監視する機能である。状態通知機能は、監視すべき対象のUE＿８および基地局７の指定を発呼予約AS＿１より受信し、呼が可能になると発呼予約AS＿１へ通知する機能である。
【００２１】
P-CSCF＿６は、輻輳転送機能とP-CSCF機能を有する。輻輳転送機能は、各CSCFでの処理量が多い場合に、発呼のINVITEメッセージを発呼予約AS＿１へ転送する機能である。また、輻輳転送機能は、無線リソースの確保に失敗した場合にも、発呼のINVITEメッセージを発呼予約AS＿１へ転送する。なお、輻輳転送機能は、処理フローのタイミングにより、発呼のINVITEメッセージを転送できないときは、UE＿８へ301 Movedメッセージなどを返す。また、Contactヘッダにisfocusタグを指定して、転送先を指定してもよい。P-CSCF＿６は、UE＿８がIMSへ接続する際の接点となる。P-CSCF機能は、UE＿８から送信されたメッセージをI-CSCF＿５やS-CSCF＿４へ転送する。また、P-CSCF機能は、I-CSCF＿５やS-CSCF＿４からUE＿８宛に送られるメッセージをUE＿８へ転送する。
【００２２】
UE＿８は、位置情報付加機能およびUE機能を有する。位置情報付加機能は、UE＿８が送信するSIPメッセージに対して、位置情報（例えば、UE＿８が利用している基地局７の識別子（セルIDなど））を付与する機能である。なお、本実施形態ではUE＿８が位置情報をSIPメッセージに付与するが、UE＿８の位置情報を、SIPメッセージの伝送経路の途中のCSCFなどが付与してもよい。UE機能は、IMSに対して登録処理を行い、IMSとメッセージの送受信を行う機能である。
【００２３】
テレフォニーAS＿１０はテレフォニーAS機能を有する。テレフォニーAS機能は、発呼先に繋がらない場合などに、ガイダンスを流すサーバ（MRF）へ呼を転送するなど、呼に関する付加制御行う機能である。
【００２４】
HSS＿３は、HSS機能を有する。HSS機能は、加入者情報を保持するデータベースの機能であり、認証情報やユーザがどのS-CSCF＿４に登録されているかを示す情報を有する。HSS機能は、I-CSCF＿５やS-CSCF＿４から問い合わせを受けたときに該データベースの情報を応答したり、該データベースの情報を更新するように要求されたときに更新したりする。
【００２５】
S-CSCF＿４は、S-CSCF機能を有する。S-CSCF機能は、UE＿８からの登録処理、及びUE＿８が送受信するメッセージの制御を行う。S-CSCF機能は、UE＿８から登録要求を受けると、HSS＿３へ当該UE＿８の認証情報を問い合わせてUE＿８を認証したのち、IPアドレスなどのUE＿８への接続情報を保持する。また、S-CSCF機能は、そのUE＿８が自S-CSCF＿４に登録されていることをHSS＿３へ登録する。以後、そのUE＿８宛に送信されるメッセージは、当該S-CSCF＿４に転送されてUE＿８のIPアドレスが確認されたのち、UE＿８へ転送される。またそのUE＿８が送信するメッセージも当該S-CSCF＿４を経由する。なお、登録処理やメッセージの転送処理の際、iFCで指定された条件に該当するものは、iFCで指定された発呼予約AS＿１へ通知したりメッセージを転送したりする。
【００２６】
I-CSCF＿５はI-CSCF機能を有する。I-CSCF機能は、UE＿８が登録処理を行う場合に、どのS-CSCF＿４へ登録すべきかをHSS＿３に問い合わせて、指定のS-CSCF＿４へ登録要求メッセージを転送する。また、UE＿８宛にメッセージを送信する際に、どのS-CSCF＿４にUE＿８が登録されているかをHSS＿３に問い合わせて、指定のS-CSCF＿４へ転送する。
【００２７】
次に本実施形態に係る動作を説明する。以下、発呼側の装置には符号「＃ａ」を付し、着呼側の装置には符号「＃ｂ」を付す。ここでは、UE＃a＿８がUE＃b＿８に対して発呼を行い、その呼が失敗し、発呼予約AS＿１に発呼予約する場合を例に挙げる。
【００２８】
［発呼予約段階］
まず、発呼予約段階の各実施例を説明する。呼が失敗する原因やタイミングに応じた各実施例がある。
【００２９】
（１）INVITE段階での発呼予約の実施例。
図３は、本実施形態に係るINVITE段階での発呼予約の実施例である。以下、図３を参照して、本実施形態に係るINVITE段階での発呼予約の実施例を説明する。この実施例では、CSCFの処理能力を超えた発呼数があったために、CSCFが呼の受付を拒否することによって呼が失敗する。これにより、CSCFは発呼予約ASへ呼を転送する。
【００３０】
P-CSCF＃ａ＿６には、輻輳時に発呼予約AS＿１へ呼を転送するように設定されている。
【００３１】
（ステップＳ１）UE＃a＿８は、UE＃b＿８への発呼のために、P-CSCF＃ａ＿６へINVITEメッセージを送信する。
【００３２】
（ステップＳ２）P-CSCF＃ａ＿６は、現在の呼処理量を確認し、自己の処理能力を超過すると判断した場合には、UE＃b＿８から受信したINVITEメッセージを発呼予約AS＿１へ転送する。なお、このINVITEメッセージの転送動作は、I-CSCF＃ａ＿５やS-CSCF＃ａ＿４が行ってもよい。
【００３３】
（ステップＳ３）発呼予約AS＿１とUE＃a＿８は、P-CSCF＃ａ＿６を介して、183 Session Progressメッセージ、PRACKメッセージ、200 OKメッセージ、ACKメッセージなどを用いた通常のINVITEの発呼処理を行う。これにより、UE＃a＿８と発呼予約AS＿１間で呼が確立される。
【００３４】
（ステップＳ４）発呼予約AS＿１は、UE＃a＿８との間で確立した呼を用いて、UE＃a＿８に対し、現在UE＃b＿８へ発呼できない旨を通知し、さらに発呼予約を行うかを問うガイダンスを流す。
【００３５】
（ステップＳ５）UE＃a＿８は、DTMF（Dual-Tone Multi-Frequency）信号を使って、発呼予約AS＿１へ応答する。なお、UE＃a＿８から発呼予約AS＿１への情報伝送には、DTMF信号以外に、SIPメッセージを使うようにしてもよい。
【００３６】
（ステップＳ６）発呼予約AS＿１は、UE＃a＿８から発呼予約の応答を受け取ると、発呼側のUE＃a＿８のSIP URIと着呼側のUE＃b＿８のSIP URIとを保持する。さらに、発呼予約AS＿１は、UE＃a＿８とUE＃b＿８を対象として監視を行うように、呼監視サーバ２へ通知する。
【００３７】
（ステップＳ７）発呼予約AS＿１は、発呼予約処理が終了すると、UE＃a＿８に対して、発呼予約が完了した旨のガイダンスを流す。
【００３８】
（ステップＳ８）
発呼予約AS＿１とUE＃a＿８は、発呼予約が完了した旨のガイダンスの終了後に、P-CSCF＃ａ＿６を介して、BYE/200OKメッセージを用いて呼を切断する。
【００３９】
（２）エラー発生時の発呼予約の実施例。
図４は、本実施形態に係るエラー発生時の発呼予約の実施例である。以下、図４を参照して、本実施形態に係るエラー発生時の発呼予約の実施例を説明する。この実施例では、INVITEに対してエラーが発生した時に発呼予約を行う。
【００４０】
テレフォニーAS＿１０には、輻輳時に発呼予約AS＿１へ呼を転送するように設定されている。
【００４１】
（ステップＳ１１）UE＃a＿８は、UE＃b＿８への発呼のために、P-CSCF＃ａ＿６へINVITEメッセージを送信する。
【００４２】
（ステップＳ１２）P-CSCF＃ａ＿６は、S-CSCF＃ａ＿４へINVITEメッセージを転送する。
【００４３】
（ステップＳ１３）S-CSCF＃ａ＿４は、iFCによりINVITEメッセージをテレフォニーAS＿１０へ転送する。
【００４４】
（ステップＳ１４）テレフォニーAS＿１０は、輻輳等の問題が無い場合には、INVITEメッセージをS-CSCF＃ａ＿４へ戻す。
【００４５】
（ステップＳ１５）S-CSCF＃ａ＿４は、UE＃b＿８が登録されているCSCF＃bへINVITEメッセージを転送する。
【００４６】
（ステップＳ１６）480 Timeoutや無線リソースを取得できなかった場合の503 Internal Errorなど、4xx/5xxなどのエラーが発生したことによって、S-CSCF＃ａ＿４に対して応答メッセージが送信される。
【００４７】
（ステップＳ１７）S-CSCF＃ａ＿４は、Viaヘッダに従い、応答メッセージをテレフォニーAS＿１０へ転送する。
【００４８】
（ステップＳ１８）テレフォニーAS＿１０は、応答メッセージのエラー内容を確認し、それがタイムアウトや無線リソース不足など、輻輳や着信者の状態に問題ありであることを確認すると、INVITEメッセージを発呼予約AS＿１へ送信する。なお、応答メッセージのエラー内容の確認や発呼予約AS＿１へのINVITEメッセージの転送をP-CSCF＃ａ＿６、I-CSCF＃ａ＿５、S-CSCF＃ａ＿４又は他のASが行ってもよい。
【００４９】
（ステップＳ１９）発呼予約AS＿１とUE＃a＿８は、P-CSCF＃ａ＿６、S-CSCF＃ａ＿４及びテレフォニーAS＿１０を介して、183 Session Progressメッセージ、PRACKメッセージ、200 OKメッセージ、ACKメッセージなどを用いた通常のINVITEの発呼処理を行う。これにより、UE＃a＿８と発呼予約AS＿１間で呼が確立される。
【００５０】
（ステップＳ２０）発呼予約AS＿１は、UE＃a＿８との間で確立した呼を用いて、UE＃a＿８に対し、現在UE＃b＿８へ発呼できない旨を通知し、さらに発呼予約を行うかを問うガイダンスを流す。
【００５１】
（ステップＳ２１）UE＃a＿８は、DTMF（Dual-Tone Multi-Frequency）信号を使って、発呼予約AS＿１へ応答する。なお、UE＃a＿８から発呼予約AS＿１への情報伝送には、DTMF信号以外に、SIPメッセージを使うようにしてもよい。
【００５２】
（ステップＳ２２）発呼予約AS＿１は、UE＃a＿８から発呼予約の応答を受け取ると、発呼側のUE＃a＿８のSIP URIと着呼側のUE＃b＿８のSIP URIとを保持する。さらに、発呼予約AS＿１は、UE＃a＿８とUE＃b＿８を対象として監視を行うように、呼監視サーバ２へ通知する。
【００５３】
（ステップＳ２３）発呼予約AS＿１は、発呼予約処理が終了すると、UE＃a＿８に対して、発呼予約が完了した旨のガイダンスを流す。
【００５４】
（ステップＳ２４）
発呼予約AS＿１とUE＃a＿８は、発呼予約が完了した旨のガイダンスの終了後に、P-CSCF＃ａ＿６、S-CSCF＃ａ＿４及びテレフォニーAS＿１０を介して、BYE/200OKメッセージを用いて呼を切断する。
【００５５】
（３）非同期無線リソース確保失敗時の発呼予約の実施例。
図５は、本実施形態に係る非同期無線リソース確保失敗時の発呼予約の実施例である。以下、図５を参照して、本実施形態に係る非同期無線リソース確保失敗時の発呼予約の実施例を説明する。この実施例では、非同期に無線リソースの確保を試みて失敗した時に、発呼予約を行う。
【００５６】
ここで非同期の無線リソースの確保とは、無線リソースを確保するときに、SIPメッセージを先にUE＃a＿８へ返し、無線リソースの確保後に改めてSIPメッセージを送る方式である。このため、無線リソースの確保に失敗したことが判明した段階では、UE＃a＿８に対して既にINVITEメッセージや応答メッセージの処理が終わっており、CSCFやASからINVITEメッセージを転送することができない。そこで、本実施形態では、301Moved応答メッセージを改めてUE＃a＿８へ送ることで、再度、UE＃a＿８からINVITEメッセージを送信させて、発呼予約を行うようにする。なお、本実施例では、テレフォニーAS＿１０の転送機能は用いない。
【００５７】
P-CSCF＃ａ＿６には、輻輳時に発呼予約AS＿１へ呼を転送するように設定されている。
【００５８】
（ステップＳ３１）UE＃a＿８は、UE＃b＿８への発呼のために、P-CSCF＃ａ＿６へINVITEメッセージを送信する。
【００５９】
（ステップＳ３２）P-CSCF＃ａ＿６は、S-CSCF＃ａ＿４へINVITEメッセージを転送する。
【００６０】
（ステップＳ３３）S-CSCF＃ａ＿４は、UE＃b＿８が登録されているCSCF＃bへINVITEメッセージを転送する。
【００６１】
（ステップＳ３４）UE＃b＿８は、INVITEに対して180 Session Progressメッセージを返信し、発呼処理を進める。
【００６２】
（ステップＳ３５）S-CSCF＃ａ＿４は、183 Session ProgressメッセージをViaヘッダに従って、I-CSCF＃ａ＿５を介してP-CSCF＃ａ＿６へ転送する。
【００６３】
（ステップＳ３６）P-CSCF＃ａ＿６は、183 Session Progressメッセージ等に記述されているSDPに基づいて、必要な無線リソースを確保する動作を開始する。このとき、P-CSCF＃ａ＿６は、無線リソースの確保完了前に、183 Session ProgressメッセージをUE＃a＿８へ転送する。そして、UE＃a＿８は、無線リソースが確保されるまで待機する。
【００６４】
（ステップＳ３７）P-CSCF＃ａ＿６は、無線リソースが確保できなかった場合に、UE＃a＿８へ301 Movedメッセージを送信する。この301 Movedメッセージにおいては、新しい宛先URIとタグなどを用いて、UE＃a＿８に対し、INVITEメッセージを発呼予約AS＿１へ送信することを指示する。転送先SIP URIの例としては、「ueb@test.com;call-reserved」や「ueb+callreserv@test.com;call-reserv」などを用いることができる。
【００６５】
（ステップＳ３８）P-CSCF＃ａ＿６は、S-CSCF＃ａ＿４を介して、UE＃b＿８に対し、発呼を中止するようにCANCELメッセージを送る。S-CSCF＃ａ＿４はUE＃b＿８が登録されるCSCFへCANCELメッセージを転送する。
【００６６】
（ステップＳ３９）発呼予約AS＿１とUE＃a＿８は、P-CSCF＃ａ＿６及びS-CSCF＃ａ＿４を介して、183 Session Progressメッセージ、PRACKメッセージ、200 OKメッセージ、ACKメッセージなどを用いた通常のINVITEの発呼処理を行う。これにより、UE＃a＿８と発呼予約AS＿１間で呼が確立される。
【００６７】
（ステップＳ４０）発呼予約AS＿１は、UE＃a＿８との間で確立した呼を用いて、UE＃a＿８に対し、現在UE＃b＿８へ発呼できない旨を通知し、さらに発呼予約を行うかを問うガイダンスを流す。
【００６８】
（ステップＳ４１）UE＃a＿８は、DTMF（Dual-Tone Multi-Frequency）信号を使って、発呼予約AS＿１へ応答する。なお、UE＃a＿８から発呼予約AS＿１への情報伝送には、DTMF信号以外に、SIPメッセージを使うようにしてもよい。
【００６９】
（ステップＳ４２）発呼予約AS＿１は、UE＃a＿８から発呼予約の応答を受け取ると、発呼側のUE＃a＿８のSIP URIと着呼側のUE＃b＿８のSIP URIとを保持する。さらに、発呼予約AS＿１は、UE＃a＿８とUE＃b＿８を対象として監視を行うように、呼監視サーバ２へ通知する。
【００７０】
（ステップＳ４３）発呼予約AS＿１は、発呼予約処理が終了すると、UE＃a＿８に対して、発呼予約が完了した旨のガイダンスを流す。
【００７１】
（ステップＳ４４）
発呼予約AS＿１とUE＃a＿８は、発呼予約が完了した旨のガイダンスの終了後に、P-CSCF＃ａ＿６及びS-CSCF＃ａ＿４を介して、BYE/200OKメッセージを用いて呼を切断する。
【００７２】
以上が発呼予約段階の説明である。
【００７３】
［呼監視段階］
次に、呼監視段階の実施例を説明する。図６は、本実施形態に係る呼監視段階の実施例である。以下、図６を参照して、本実施形態に係る呼監視段階の実施例を説明する。この実施例では、発呼予約が行われた後に、呼監視サーバ２が呼の監視を行う。
【００７４】
（ステップＳ５１）呼監視サーバ２は、パケットキャプチャ等を行ってSIPメッセージを取得する。
【００７５】
（ステップＳ５２）呼監視サーバ２は、取得したSIPメッセージに基づいて、呼の監視を行う。例えば、呼監視サーバ２は、call-id、to-tag及びfrom-tagに基づいて呼処理の数を算出する。また、呼監視サーバ２は、SIPメッセージのrouteヘッダ又はViaヘッダに基づいて、CSCFごとに呼処理数を算出する。また、呼監視サーバ２は、SIPメッセージに含まれる位置情報に基づいて、基地局あたりの呼処理数の算出、及び端末が利用している基地局の判別を行う。また、呼監視サーバ２は、監視対象であるUE＃a＿８とUE＃b＿８の登録状況および通話状況の監視を行う。
【００７６】
［予約発呼段階］
次に、予約発呼段階の実施例を説明する。図７は、本実施形態に係る予約発呼段階の実施例である。以下、図７を参照して、本実施形態に係る予約発呼段階の実施例を説明する。この実施例では、発呼予約AS＿１が発呼予約されている呼の自動発呼処理を行う。
【００７７】
（ステップＳ６１）呼監視サーバ２は、監視対象である発呼側のUE＃a＿８と着呼側のUE＃b＿８に関して自動発呼条件を満足する場合に、発呼予約AS＿１に対して、自動発呼を指示するトリガメッセージを送信する。自動発呼条件としては、着呼側のUE＃b＿８による通信の応答が可能であること以外に、発呼側のUE＃a＿８と着呼側のUE＃b＿８が共に、登録されていること、無線リソースが利用可能であること、CSCFでの呼処理が可能であること、などがある。但し、これらの自動発呼条件の中からどの条件を使用するのかは通信ネットワークシステムの運用ポリシーによって決めればよく、すべての自動発呼条件を満たす必要は無い。
【００７８】
（ステップＳ６２）発呼予約AS＿１は、UE＃a＿８とUE＃b＿８の間に呼を確立する。まず、発呼予約AS＿１は、SDPの無いINVITEメッセージをS-CSCF＃ａ＿４を経由してUE＃a＿８に送信する。なお、すでに使用されるコーデックが決まっているなど、ネゴシエーションが必要ない場合は、INVITEメッセージにSDPを入れて送信してもよい。
【００７９】
（ステップＳ６３）S-CSCF＃ａ＿４は発呼予約AS＿１から受信したINVITEメッセージをP-CSCF＃ａ＿６に転送する。
【００８０】
（ステップＳ６４）P-CSCF＃ａ＿６はS-CSCF＃ａ＿４から受信したINVITEメッセージをUE＃a＿８に転送する。
【００８１】
（ステップＳ６５）UE＃a＿８は、P-CSCF＃ａ＿６からINVITEメッセージを受信すると、通常の着呼と同じ処理を行い、183 Session ProgressメッセージをP-CSCF＃ａ＿６に返信する。
【００８２】
（ステップＳ６６）P-CSCF＃ａ＿６は、UE＃a＿８から受信した183 Session ProgressメッセージをViaヘッダに従って、S-CSCF＃ａ＿４へ転送する。
【００８３】
（ステップＳ６７）S-CSCF＃ａ＿４は、P-CSCF＃ａ＿６から受信した183 Session Progressメッセージを発呼予約AS＿１へ転送する。
【００８４】
（ステップＳ６８）発呼予約AS＿１は、S-CSCF＃ａ＿４から受信した183 Session Progressメッセージに含まれるSDPを含めたINVITEメッセージを、UE＃b＿８が登録されているCSCF＃bへS-CSCF＃ａ＿４を経由して送信する。
【００８５】
（ステップＳ６９）S-CSCF＃ａ＿４は、発呼予約AS＿１から受信したINVITEメッセージをUE＃b＿８が登録されているCSCF＃b(S-CSCFとP-CSCF)へ転送する。このINVITEメッセージは、UE＃b＿８が登録されているCSCF＃bからUE＃b＿８へ転送される。
【００８６】
（ステップＳ７０）UE＃b＿８は、そのINVITEメッセージを受信すると、通常の着と同様に処理し、SDPを付けた183 Session Progressメッセージを返信する。この183 Session Progressメッセージは、UE＃b＿８が登録されているCSCF＃bからS-CSCF＃ａ＿４に転送される。
【００８７】
（ステップＳ７１）S-CSCF＃ａ＿４は、受信した183 Session Progressメッセージを発呼予約AS＿１へ転送する。
【００８８】
（ステップＳ７２）発呼予約AS＿１は、S-CSCF＃ａ＿４から受信した183 Session Progressメッセージに含まれるSDPを含むUPDATEメッセージを、S-CSCF＃ａ＿４とP-CSCF＃ａ＿６を介してUE＃a＿８へ送信する。この時、UE＃b＿８のRTPなどのメディアのIPアドレスとポート番号は、発呼予約AS＿１のIPアドレスとポート番号に設定しておく。
【００８９】
（ステップＳ７３）発呼予約AS＿１は、UE＃a＿８とUE＃b＿８の間で、B2BUA（Back to Back User Agent）として動作し、メッセージを中継する。この中継動作において、発呼予約AS＿１は、中継するメッセージのSDPにおける無線リソースの予約状況を示すフィールドにおいて、はじめは、AS側の無線リソースの予約状況を未確保状態に設定する。これにより、UE＃a＿８及びUE＃b＿８の両方で呼び出しを行わない（コール音を鳴らさない）ようにする。このSDPの実施例を以下に示す。
【００９０】
（SDPの実施例）
a=curr:qos local recvonly
a=curr:qos remote none
a=des:qos mandatory local recvonly
a=des:qos mandatory remote sendonly
この実施例ではUE＃a＿８から発呼予約AS＿１に送られるSDPにおいて、AS側が未確保（none）になっている。
【００９１】
（ステップＳ７４）UE＃a＿８及びUE＃b＿８は、無線リソースが確保できると、UPDATEメッセージを送って、発呼予約AS＿１に無線リソースが確保できたことを通知する。発呼予約AS＿１は、UE＃a＿８及びUE＃b＿８の両方で無線リソースが確保できた場合に、UE＃a＿８に対して、AS側の無線リソースが確保できたことを通知するUPDATEメッセージを送信する。これにより、着信処理を行っているUE＃a＿８は、該UPDATEメッセージを受信すると、呼び出しを行う（コール音を鳴らす）。このSDPの実施例を以下に示す。
【００９２】
（SDPの実施例）
a=curr:qos local recvonly
a=curr:qos remote sendonly
a=des:qos mandatory local recvonly
a=des:qos mandatory remote sendonly
この実施例ではUE＃a＿８から発呼予約AS＿１に送られるSDPにおいて、AS側が確保（sendonly）になっている。
【００９３】
（ステップＳ７５）UE＃a＿８のユーザが電話に出ると、発呼予約AS＿１とUE＃a＿８の間で音声を流すことができる。発呼予約AS＿１は、この呼が予約によって発生した自動発呼であることと、現在UE＃b＿８を呼び出し中であることを伝えるガイダンスを流す。
【００９４】
（ステップＳ７６）発呼予約AS＿１は、UE＃a＿８が着信応答するとすぐにUE＃b＿８に対して、AS側の無線リソースが確保できたことを通知するUPDATEメッセージを送信する。これにより、着信処理を行っているUE＃b＿８は、該UPDATEメッセージを受信すると、呼び出しを行う（コール音を鳴らす）。
【００９５】
（ステップＳ７７）発呼予約AS＿１は、UE＃b＿８が着信応答すると、UE＃a＿８に対してRe-INVITEメッセージを送信する。発呼予約AS＿１は、このRe-INVITEメッセージに対して、RTPのメディアのIPアドレスとポート番号を、UE＃b＿８のものに変更する旨を記述する。また、発呼予約AS＿１は、UE＃a＿８とUE＃b＿８間の通信が、ガイダンスで一方的な音声通信になっていた場合には、双方向で音声を流せるように、SDPのsendrecvを変更する。このSDPの実施例を以下に示す。
【００９６】
（SDPの実施例）
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
【００９７】
（ステップＳ７８）UE＃a＿８とUE＃b＿８の間で音声通信が開始される。
【００９８】
なお、図７のステップＳ６２〜Ｓ７８は3PCCに対応する部分である。
【００９９】
本実施形態では、発呼予約されている呼の自動発呼処理において、発呼側のUE＃a＿８と着呼側のUE＃b＿８の両方で無線リソースが確保できた場合にのみ、発呼側のUE＃a＿８で呼び出しを行う（コール音を鳴らす）ようにしている。そして、発呼側のUE＃a＿８が着信応答した場合に、着呼側のUE＃b＿８で呼び出しを行う（コール音を鳴らす）ようにしている。これは、発呼側のUE＃a＿８または着呼側のUE＃b＿８で無線リソースの確保に失敗する可能性があるので、発呼側のUE＃a＿８と着呼側のUE＃b＿８の両方で無線リソースが確保できた場合にのみ、ユーザの呼び出しを行うものである。これにより、通信の実施の確実性を向上させることができ、ユーザの満足度を向上させることが期待できる。
【０１００】
以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【０１０１】
例えば、図７の予約発呼段階において、通常のREFERを使った3PCCなどを用いてもよい。その場合には、ユーザに不便さを感じさせないよう、UE側にREFERを受けた場合に通知するなどのUIを設ける。
【０１０２】
又、発呼予約AS＿１は、発呼予約された呼について、一定時間が経過したら発呼予約を解除するようにしてもよい。
【０１０３】
又、発呼予約AS＿１は、発呼予約時のガイダンスとして、例えば、呼に失敗した原因、着信側のUE＃b＿８の状態（動作している／していない）、通話できるようになるまでのおおよその待ち時間、などの情報を流すようにしてもよい。通話できるようになるまでのおおよその待ち時間は、現在の呼処理量と平均の通話時間などに基づいて算出するようにすることができる。又、呼監視サーバ２は、発呼予約AS＿１に対して、自動発呼を指示するトリガメッセージを送信する条件として、待ち時間を加えてもよい。
【０１０４】
又、発呼予約は、上述した実施形態のように自動的に行われてもよく、又は、ユーザ等の操作により手動的に行われてもよい。
【０１０５】
又、図８に示すように、上述した実施形態とは異なる機能構成としてもよい。図８は、本発明に係る他の実施形態の機能構成図である。この図８において図２の各部に対応する部分には同一の符号を付している。図８では、呼監視サーバ２の代わりに呼監視AS＿２０を備える。呼監視AS＿２０は、IMSを呼の監視を行う機能を、ASとして実装する。
【０１０６】
図８において、呼監視AS＿２０のSIP監視機能は、ASに転送されるSIPメッセージを読み取り、呼の監視を行う。図２の呼監視サーバ２と異なる点は、呼監視サーバ２がSIPサーバとして扱われずネットワーク上でSIPメッセージのパケットを読み取るのに対し、呼監視AS＿２０がSIPサーバとしてSIPメッセージの転送経路に組み込まれることである。
【０１０７】
図９は、図８の実施形態に係る呼監視段階の実施例である。この図９において図６の各部に対応する部分には同一の符号を付している。図９では、SIPメッセージは呼監視AS＿２０を経由して送受信される。ステップＳ５１において、呼監視AS＿２０は、SIPメッセージを受信する。そして、ステップＳ５２において、呼監視サーバ２は、受信したSIPメッセージに基づいて、呼の監視を行う。
【０１０８】
又、図２又は図８に示す実施形態において、テレフォニーAS＿１０の呼転送機能（発呼先に繋がらない場合に呼を転送する機能）を、発呼予約AS＿１が備えるようにしてもよい。この場合、発呼予約AS＿１は、発呼先に繋がらない場合にはそのまま発呼予約処理を行うこととなる。又、図８の実施形態において、呼監視AS＿２０が、テレフォニーAS＿１０の呼転送機能を備えてもよい。
【０１０９】
また、図３〜図７、図９に示す各ステップを実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、通信制御処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Digital Versatile Disk）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０１１０】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【０１１１】
１…発呼予約AS（発呼予約装置）、２…呼監視サーバ、３…HSS、４…S-CSCF（通信制御装置）、５…I-CSCF（通信制御装置）、６…P-CSCF（通信制御装置）、７…基地局、８…UE、１０…テレフォニーAS（通信制御装置）、２０…呼監視AS
【図１】
0005841879.tif 000002
【図２】
0005841879.tif 000003
【図３】
0005841879.tif 000004
【図４】
0005841879.tif 000005
【図５】
0005841879.tif 000006
【図６】
0005841879.tif 000007
【図７】
0005841879.tif 000008
【図８】
0005841879.tif 000009
【図９】
0005841879.tif 000010