JP2013211663A - 通信制御システム、通信制御方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】発呼先の移動ユーザによる通信の応答が可能になった時に発呼者である移動ユーザを呼び出す際に、通信の実施の確実性を向上させることを図る。
【解決手段】発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムであり、発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す発呼予約AS＿１を備えたことを特徴とする。
【選択図】図１

Description

本発明は、通信制御システム、通信制御方法、及びコンピュータプログラムに関する。

従来、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

Claims (6)

1. 発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御システムであり、
   発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出す発呼予約装置を備えたことを特徴とする通信制御システム。
2. 前記発呼予約装置は、
   発呼側の無線端末および着呼側の無線端末の両方に対してアプリケーションサーバ側の無線回線のリソースが未確保であることを通知して着呼処理を行わせておき、
   発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出し、
   発呼側の無線端末からの着信応答があると、着呼側の無線端末に対してアプリケーションサーバ側の無線回線のリソースが確保できたことを通知して呼び出す、
   ことを特徴とする請求項１に記載の通信制御システム。
3. 発呼側の無線端末からの発呼要求に対して受付応答を発呼側の無線端末に返した後に無線回線のリソースを確保できなかった場合に、当該発呼側の無線端末に対して同じ発呼要求を前記発呼予約装置へ送信するように要求する通信制御装置を備え、
   前記発呼予約装置は、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う、
   ことを特徴とする請求項１又は２に記載の通信制御システム。
4. 発呼側の無線端末からの発呼要求に対して輻輳時又はエラー発生時に当該発呼要求を前記発呼予約装置へ転送する通信制御装置を備え、
   前記発呼予約装置は、前記発呼側の無線端末からの発呼要求に基づいて、発呼要求された呼の発呼予約を行う、
   ことを特徴とする請求項１から３のいずれか１項に記載の通信制御システム。
5. 発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御方法であり、
   発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップを含むことを特徴とする通信制御方法。
6. 発呼予約された呼の着信側の無線端末による通信の応答が可能になった時に発呼側の無線端末を呼び出す通信制御処理を行うためのコンピュータプログラムであって、
   発呼側の無線端末および着呼側の無線端末の両方の無線回線のリソースが確保できてから、発呼側の無線端末を呼び出すステップ、
   をコンピュータに実行させるためのコンピュータプログラム。

Images