(57)【特許請求の範囲】
【請求項１】
移動利用される端末と緊急機関との間の緊急呼をＩＰ−ＣＡＮ（IP Connectivity Access Network）、ＩＭＳ（IP Multimedia Subsystem）を経由して処理するシステムに用いられる装置であって、
前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の回線を、前記端末−前記ＩＰ−ＣＡＮ−前記ＩＭＳ間の端末側の回線と前記ＩＭＳ−前記緊急機関間の緊急機関側の回線とに分離して確立させる回線確立手段と、
前記端末側からの前記緊急呼切断時に、前記端末側の回線を解放すると共に前記緊急機関側の回線を保留する回線保留手段と、
前記緊急呼切断後の前記緊急機関から前記端末への再呼び出し時に、保留された前記緊急機関側の回線を利用して前記緊急機関から前記端末へ着信させる再呼び出し手段とを有することを特徴とする緊急呼処理装置。
【請求項２】
前記回線確立手段は、前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の前記ＩＭＳ経由の回線によるセッションを、Ｂ２ＢＵＡ（Back-to-Back User Agent）制御により、前記端末側の回線による第１のセッションと、前記緊急機関側の回線による第２のセッションとにそれぞれ分離して確立させるものであり、
前記回線保留手段は、前記端末からの前記緊急呼切断時に、前記第１のセッションにおける前記端末側の回線を解放すると共に、前記第２のセッションにおける前記緊急機関側の回線を保留するものであり、
前記再呼び出し手段は、保留された前記第２のセッションによる回線を用いて前記緊急機関から前記緊急呼の再呼び出しが行われたときに、前記端末側の回線による第３のセッションを作成して前記端末へ着信させるものであることを特徴とする請求項１記載の緊急呼処理装置。
【請求項３】
前記ＩＭＳは、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）、Ｓ−ＣＳＣＦ（Serving Call Session Control Function）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）、Ｅ−ＣＳＣＦ（Emergency Call Session Control Function）、及びＭＧＣＦ（Media Gateway Control Function）を有し、
前記端末は、ＩＰ−ＣＡＮ（IP Connectivity Access Network）を介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記緊急機関は、前記ＭＧＣＦを介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記第１のセッションによる前記端末側の回線は、前記Ｅ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであり、
前記第２のセッションによる前記緊急機関側の回線は、前記Ｅ−ＣＳＣＦ及び前記ＭＧＣＦを経由するものであり、
前記第３のセッションによる前記端末側の回線は、前記Ｉ−ＣＳＣＦ、前記Ｓ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであることを特徴とする請求項２記載の緊急呼処理装置。
【請求項４】
移動利用される端末と緊急機関との間の緊急呼をＩＰ−ＣＡＮ（IP Connectivity Access Network）、ＩＭＳ（IP Multimedia Subsystem）を経由して処理する方法であって、
前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の回線を、前記端末−前記ＩＰ−ＣＡＮ−前記ＩＭＳ間の端末側の回線と前記ＩＭＳ−前記緊急機関間の緊急機関側の回線とに分離して確立させる回線確立ステップと、
前記端末側からの前記緊急呼切断時に、前記端末側の回線を解放すると共に前記緊急機関側の回線を保留する回線保留ステップと、
前記緊急呼切断後の前記緊急機関から前記端末への再呼び出し時に、保留された前記緊急機関側の回線を利用して前記緊急機関から前記端末へ着信させる再呼び出しステップとを有することを特徴とする緊急呼処理方法。
【請求項５】
前記端末と前記緊急機関との間の回線は、ＩＭＳ（IP Multimedia Subsystem）を経由するものであり、
前記回線確立ステップは、前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の前記ＩＭＳ経由の回線によるセッションを、Ｂ２ＢＵＡ（Back-to-Back User Agent）制御により、前記端末側の回線による第１のセッションと、前記緊急機関側の回線による第２のセッションとにそれぞれ分離して確立させるものであり、
前記回線保留ステップは、前記端末からの前記緊急呼切断時に、前記第１のセッションにおける前記端末側の回線を解放すると共に、前記第２のセッションにおける前記緊急機関側の回線を保留するものであり、
前記再呼び出しステップは、保留された前記第２のセッションによる回線を用いて前記緊急機関から前記緊急呼の再呼び出しが行われたときに、前記端末側の回線による第３のセッションを作成して前記端末へ着信させるものであることを特徴とする請求項４記載の緊急呼処理方法。
【請求項６】
前記回線確立ステップは、
前記端末からの発信信号を受信した場合、前記発信信号が緊急呼であるか判定するステップと、
前記発信信号が緊急呼である場合、回線情報に緊急呼を設定するステップとを有し、
前記回線保留ステップは、
前記端末から切断信号を受信した場合、前記回線情報を参照し、前記切断信号が緊急呼であるか判定するステップと、
前記切断信号が緊急呼である場合、前記端末側の回線を解放すると共に、前記緊急機関側の回線を保留するステップとを有し、
前記再呼び出しステップは、
保留された前記緊急機関側の回線を利用して、前記緊急機関から前記端末へ再呼び出し信号を受けた場合、解放された前記端末側の回線を再構築するステップと、
前記緊急機関側の回線と再構築した前記端末側の回線を用いて、前記緊急機関から前記端末へ再呼び出し信号を着信させるステップとを有することを特徴とする請求項５記載の緊急呼処理方法。
【請求項７】
前記回線確立ステップは、
前記端末からの発信信号を受信した場合、前記発信信号のヘッダを参照して、宛先が前記緊急機関であるか判定するステップと、
前記宛先が緊急機関である場合、前記端末側の回線による第１のセッションに関する情報と前記緊急機関側の第２のセッションに関する情報とを互いに対応付けたセッション情報を作成してそのセッション情報に緊急呼を設定し、前記セッション情報を記憶するステップとを有し、
前記回線保留ステップは、
前記端末から切断信号を受信した場合、記憶された前記セッション情報を参照し、前記切断信号が緊急呼であるか判定するステップと、
前記切断信号が緊急呼である場合、記憶された前記セッション情報の内の前記第１のセッションに関する情報を削除して前記端末側の回線を解放すると共に、前記第２のセッションに関する情報の内の前記第１のセッションとの対応情報を削除して前記緊急機関側の回線を保留するステップとを有し、
前記再呼び出しステップは、
保留された前記緊急機関側の回線を利用して、前記緊急機関から前記端末へ再呼び出し信号を受けた場合、前記第２のセッションに関する情報に対応付けて前記端末側の回線による第３のセッションに関する情報を作成して、解放された前記端末側の回線を再構築するステップと、
前記緊急機関側の回線と再構築した前記端末側の回線を用いて、前記緊急機関から前記端末へ再呼び出し信号を着信させるステップとを有することを特徴とする請求項５記載の緊急呼処理方法。
【請求項８】
前記ＩＭＳは、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）、Ｓ−ＣＳＣＦ（Serving Call Session Control Function）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）、Ｅ−ＣＳＣＦ（Emergency Call Session Control Function）、及びＭＧＣＦ（Media Gateway Control Function）を有し、
前記端末は、ＩＰ−ＣＡＮ（IP Connectivity Access Network）を介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記緊急機関は、前記ＭＧＣＦを介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記第１のセッションによる前記端末側の回線は、前記Ｅ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであり、
前記第２のセッションによる前記緊急機関側の回線は、前記Ｅ−ＣＳＣＦ及び前記ＭＧＣＦを経由するものであり、
前記第３のセッションによる前記端末側の回線は、前記Ｉ−ＣＳＣＦ、前記Ｓ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであることを特徴とする請求項５から７のいずれか１項に記載の緊急呼処理方法。
【請求項９】
移動利用される端末と緊急機関との間の緊急呼をＩＰ−ＣＡＮ（IP Connectivity Access Network）、ＩＭＳ（IP Multimedia Subsystem）を経由して処理するシステムに用いられるサーバ装置であって、
前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の回線を、前記端末−前記ＩＰ−ＣＡＮ−前記ＩＭＳ間の端末側の回線と前記ＩＭＳ−前記緊急機関間の緊急機関側の回線とに分離して確立させる回線確立手段と、
前記端末側からの前記緊急呼切断時に、前記端末側の回線を解放すると共に前記緊急機関側の回線を保留する回線保留手段と、
前記緊急呼切断後に保留された前記緊急機関側の回線を利用して前記緊急機関から前記端末への再呼び出しを可能とする再呼び出し手段とを有することを特徴とするサーバ装置。
【請求項１０】
前記回線確立手段は、前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の前記ＩＭＳ経由の回線によるセッションを、Ｂ２ＢＵＡ（Back-to-Back User Agent）制御により、前記端末側の回線による第１のセッションと、前記緊急機関側の回線による第２のセッションとにそれぞれ分離して確立させるものであり、
前記回線保留手段は、前記端末からの前記緊急呼切断時に、前記第１のセッションにおける前記端末側の回線を解放すると共に、前記第２のセッションにおける前記緊急機関側の回線を保留するものであり、
前記再呼び出し手段は、保留された前記第２のセッションによる回線を用いて前記緊急機関から前記緊急呼の再呼び出しが行われたときに、前記端末側の回線による第３のセッションを作成して前記端末へ着信させるものであることを特徴とする請求項９記載のサーバ装置。
【請求項１１】
前記ＩＭＳは、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）、Ｓ−ＣＳＣＦ（Serving Call Session Control Function）、Ｉ−ＣＳＣＦ（Interrogating Call Session Control Function）、Ｅ−ＣＳＣＦ（Emergency Call Session Control Function）、及びＭＧＣＦ（Media Gateway Control Function）を有し、
前記端末は、ＩＰ−ＣＡＮ（IP Connectivity Access Network）を介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記緊急機関は、前記ＭＧＣＦを介して前記ＩＭＳにプロトコル変換可能な状態で接続され、
前記第１のセッションによる前記端末側の回線は、前記Ｅ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであり、
前記第２のセッションによる前記緊急機関側の回線は、前記Ｅ−ＣＳＣＦ及び前記ＭＧＣＦを経由するものであり、
前記第３のセッションによる前記端末側の回線は、前記Ｉ−ＣＳＣＦ、前記Ｓ−ＣＳＣＦ、前記Ｐ−ＣＳＣＦ、及び前記ＩＰ−ＣＡＮを経由するものであることを特徴とする請求項１０記載のサーバ装置。
【請求項１２】
請求項９から１１のいずれか１項に記載のサーバ装置と、
前記サーバ装置に接続されるＩＭＳ（IP Multimedia Subsystem）と、
を有することを特徴とする緊急呼処理システム。
【請求項１３】
前記ＩＭＳと前記端末との間をプロトコル変換可能に接続するＩＰ−ＣＡＮ（IP Connectivity Access Network）をさらに有することを特徴とする請求項１２に記載の緊急呼処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、緊急呼処理装置、方法、プログラム、並びにサーバ装置及びこれを用いた緊急呼処理システムに係り、特にＩＭＳ（IP Multimedia Subsystem）を利用して第３世代携帯電話等の移動を伴う端末に回線交換サービスを提供するシステムの緊急呼回線保留方法に関する。
【背景技術】
【０００２】
近年の携帯電話やＩＰ（Internet Protocol）電話の利用増大に伴い、これらの電話端末から緊急機関への緊急通報の割合も増加している。これに関連して、電話端末と緊急機関との間の回線確保や緊急機関から電話端末への再呼び出し等の緊急呼に関する処理を行うシステムや方法が各種提案されている。
【０００３】
例えば、特許文献１には、緊急機関に通話中の電話端末にてオンフック動作が行われた場合にも、端末側ゲートウェイ装置でそのオンフック信号を無視して端末側と交換機側との間のセッションを維持することで、回線保留及び呼び返しを行うことができるインターネット電話システムが記載されている。
【０００４】
また、特許文献２には、着信側の番号が予め設定された電話番号であった場合に発信側が発信した切断信号を着信側へ伝送せずに公衆回線網の接続回線を保持し、その切断信号に基づいて発信側へ呼び返し信号を送り返すＩＰ電話呼び返しシステムが記載されている。これによれば、発信側端末からの切断時に中継サーバからの指示による呼び返し処理を可能とし、ＩＰ電話端末の回線を中継サーバ側で確保することで、緊急通報に必要な回線保持や再呼び出しが実現できるとされている。
【０００５】
上記の特許文献１、２は、固定利用するＩＰ電話と緊急機関との間の緊急通報の呼処理に関するものであり、固定網内で利用されるものである。このため、移動体網（モバイル網）を介して移動利用する携帯電話などの端末から発信される緊急呼の処理には適用できない。
【０００６】
これに対し、移動利用する携帯電話と緊急機関との間の緊急通報の呼処理に関しては、例えばＷ−ＣＤＭＡ（Wideband-Code Division Multiple Access）方式の標準化団体である３ＧＰＰ（3rd Generation Partnership Project）により、３ＧＰＰ  ＴＳ  ２３．１６７  Ｖ７．６．０（非特許文献１）にて標準化が進められているＩＰ（Internet Protocol）技術をベースとした、「ＩＭＳ（IP Multimedia Subsystem）」を利用したものが知られている。
【０００７】
ここで、ＩＭＳの概要について簡単に説明する。
【０００８】
ＩＭＳは、従来の回線交換方式のコアネットワークからＩＰ技術をベースとした新たなコアネットワークに置き換えることをめざし、その導入が検討されているものである（例えば、非特許文献２参照）。ＩＭＳは、呼制御用プロトコルとしてＳＩＰ（Session Initiation Protocol）を採用している。ＩＭＳには、その制御の中核を担うＣＳＣＦ（Call Session Control Function：呼セッション制御機能）のほか、端末の加入者の位置情報やプロファイル（サービス契約情報）を保持する機能を有するＨＳＳ（Home Subscriber Server）や、ＳＩＰ信号とＩＳＵＰ信号とのプロトコル変換を行うＭＧＣＦ（Media Gateway Control Function）等の各構成要素が規定されている。この内、ＣＳＣＦには、Ｐ（Proxy）−ＣＳＣＦ、Ｓ（Serving）−ＣＳＣＦ、及びＩ（Interrogating）−ＣＳＣＦの各要素が含まれ、さらに緊急呼用のものとして、後述するＥ（Emergency）−ＣＳＣＦも規定されている。
【０００９】
ＩＭＳの最も単純な装置構成は、Ｐ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、及びＨＳＳにより構成される。Ｓ−ＣＳＣＦは、サービスを提供する装置であり、加入者の端末からの位置登録時にＨＳＳより指定される。端末の位置登録期間が有効の間は、その端末の加入者のサービス制御は、ＨＳＳで指定されたＳ−ＣＳＣＦで行われる。Ｐ−ＣＳＣＦは、端末とＳ−ＣＳＣＦとの間に信号の送受信と端末の認証を行う。
【００１０】
ＩＭＳによる呼制御の手順として、端末は事前に位置登録を行う必要がある。位置登録手順により、端末は、自身のアドレス（ユーザ識別子：通常は電話番号）とＩＰアドレスとの対応をＨＳＳに登録する。具体的な位置登録手順では、端末はＤＮＳ（Domain Name System）などによりＰ−ＣＳＣＦのＩＰアドレスを解決し、そのＩＰアドレスに基づいてＰ−ＣＳＣＦに対してＳＩＰの「ＲＥＧＩＳＴＥＲ」信号を送信する。Ｐ−ＣＳＣＦでは、その「ＲＥＧＩＳＴＥＲ」信号を受信すると、これに基づいて端末の認証を行い、ＨＳＳにどこのＳ−ＣＳＣＦにルーティングするかを問い合わせ、その応答からルーティング先となるＳ−ＣＳＣＦのＩＰアドレスを取得し、そのＩＰアドレスに基づいてＳ−ＣＳＣＦに対して「ＲＥＧＩＳＴＥＲ」信号を送信する。Ｓ−ＣＳＣＦは、その「ＲＥＧＩＳＴＥＲ」信号を受信すると、これに基づいてＨＳＳより加入者のプロファイルのダウンロードにより保持し、また端末のアドレスとＰ−ＣＳＣＦのＩＰアドレスとの対応をメモリに保持する。
【００１１】
上記位置登録手順の後に行われる発信手順においては、発側の端末（発端末）は、Ｐ−ＣＳＣＦにＳＩＰの「ＩＮＶＩＴＥ」信号を送信する。Ｐ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受けると、これに基づいてその発端末がどのＳ−ＣＳＣＦで制御されるべきかＨＳＳに問い合わせ、その応答から適切なＳ−ＣＳＣＦのＩＰアドレスを取得し、そのＩＰアドレスに基づいてＳ−ＣＳＣＦに対し「ＩＮＶＩＴＥ」信号を送信する。Ｓ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受けると、これに基づいて着側の端末（着端末）がどのＳ−ＣＳＣＦで制御されるのかＨＳＳに問い合わせ、その応答から着側のＳ−ＣＳＣＦ（着Ｓ−ＣＳＣＦ）のＩＰアドレスを取得し、その着Ｓ−ＣＳＣＦに対し「ＩＮＶＩＴＥ」信号を送信する。着Ｓ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受信すると、これに基づいて保持している着端末のアドレスと着側のＰ−ＣＳＣＦ（着Ｐ−ＣＳＣＦ）のＩＰアドレスとの対応から、着Ｐ−ＣＳＣＦを決定し、その着Ｐ−ＣＳＣＦに対し「ＩＮＶＩＴＥ」信号を送信する。着Ｐ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受信すると、これに基づいて着端末のアドレスを特定し、そのアドレスに基づいて着端末に「ＩＮＶＩＴＥ」信号を送信する。
【００１２】
以上がＩＭＳの単純な構成及び呼制御手順での例であるが、着端末がＩＭＳ網ではなく電話網に接続されている場合、電話網は、Ｎｏ．７共通線信号方式（「ＳＳ７」、「Ｃ７」、「ＳＳＣ７」とも略記される。）に基づき電話網の交換機間で使用されるシグナリングプロトコルであるＩＳＵＰ（ISDN User Part）信号しか解釈できない。このため、Ｓ−ＣＳＣＦは、ＩＭＳ網と電話網間のゲートウェイ装置であるＭＧＣＦに対して「ＩＮＶＩＴＥ」信号を送信する。
【００１３】
ＭＧＣＦは、その「ＩＮＶＩＴＥ」信号を受信すると、これに対してＳＩＰ−ＩＳＵＰ変換を行い、変換されたＩＳＵＰ信号を電話網の交換機へ送信する。これとは逆に、ＭＧＣＦは、電話網からＩＳＵＰ信号を受信すると、これをＳＩＰ信号に変換する。また、電話網からＩＭＳ網への着信の場合、ＭＧＣＦがＩＳＵＰの「ＩＡＭ（Initial Address Message）」信号を受信するが、ＭＧＣＦは、ＨＳＳとのインターフェースが無いため、着端末を制御するＳ−ＣＳＣＦを認識できない。そのため、Ｉ−ＣＳＣＦにＳＩＰの「ＩＮＶＩＴＥ」信号を送信し、これによりＩ−ＣＳＣＦがＨＳＳに適切なＳ−ＣＳＣＦを問い合わせ、そのＳ−ＣＳＣＦに対し「ＩＮＶＩＴＥ」信号を送信する。
【００１４】
なお、通常はＳ−ＣＳＣＦでサービス提供を行うが、より高度なサービスを提供する場合、ＩＭＳに接続されたＡＳ（Application Server）にて、そのサービス制御を実現する。その場合、Ｓ−ＣＳＣＦからＡＳに「ＩＮＶＩＴＥ」信号を送信し、ＡＳ内で「ＩＮＶＩＴＥ」信号の編集を行った後、Ｓ−ＣＳＣＦに「ＩＮＶＩＴＥ」信号を送信する。
【００１５】
次に、３ＧＰＰ  ＴＳ  ２３．１６７  Ｖ７．６．０の概要について説明する。
【００１６】
３ＧＰＰ  ＴＳ  ２３．１６７  Ｖ７．６．０は、ＩＭＳにおいて緊急呼を実現するための必要な要素（機能）について記述されたドキュメントである。これによると、緊急呼用のＣＳＣＦとして、Ｅ−ＣＳＣＦが規定されている。Ｅ−ＣＳＣＦの大きな機能は、発端末の位置情報から適切な緊急機関の端末のアドレスを求める機能と、発端末の位置情報が得られない場合、ＬＲＦ（Location Retrieval Function：位置検索機能）にその発端末の位置情報を問い合わせる機能とにある。
【００１７】
この場合、ＩＭＳによる緊急呼を実現するため、位置登録手順では、端末は、前述した通常のユーザ識別子（電話番号相当）ではなく、緊急呼用パブリックユーザ識別子を用いて位置登録を行う。そして、発信手順においては、緊急呼のセッションを確立する際、移動体網の発端末からの緊急呼の信号に対応して、ＩＭＳ網内ではＳＩＰの「ＩＮＶＩＴＥ」信号に緊急呼セッション識別子を乗せて転送するようになっている。Ｐ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受信すると、これに基づいて、Ｓ−ＣＳＣＦではなくＥ−ＣＳＣＦに「ＩＮＶＩＴＥ」信号を送信する。Ｅ−ＣＳＣＦは、その「ＩＮＶＩＴＥ」信号を受信すると、これに基づいて着端末となる緊急機関のアドレスを求め、そのアドレスに基づいてその緊急機関に接続されたＭＧＣＦに対し「ＩＮＶＩＴＥ」信号を送信する。以下、前述同様に、ＭＧＣＦは、ＳＩＰ−ＩＳＵＰ変換を行い、変換されたＩＳＵＰ信号をその電話網へ送信し、これにより緊急機関の端末に着信させる。
【００１８】
この場合、緊急機関の端末から通報者の端末への再呼び出しは、その通報者の端末のユーザ識別子（電話番号相当）に向けて通常の発信手順により発信を行うようになっている。
【特許文献１】特開２００４−３６３８１８号公報
【特許文献２】特開２００５−３５４６４１号公報
【非特許文献１】3GPP TS 23.167 V7.6.0(2007-09), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 7)
【非特許文献２】河村  厚男、田村  利之、塚越  努、蓮実  利昭、渡邉  一生、「次世代（ＦＭＣ）コアネットワーク」、ＮＥＣ技報、Ｖｏｌ．５９、Ｎｏ．２、２００６年、ｐ．２９−３２
【発明の開示】
【発明が解決しようとする課題】
【００１９】
上記の３ＧＰＰ  ＴＳ  ２３．１６７  Ｖ７．６．０では、緊急機関への通話時に、緊急機関へ、発信者に接続できるユーザ識別子（電話番号など）を通知することのみ定義されており、緊急機関からの再呼び出しの際にその接続の確実性を高める方法について標準化されていない。つまり、緊急機関から通報者の端末への再呼び出しは、通常の発信と同様の通報者への発信であるため、ネットワークの状況によっては通話に十分な資源が得られず、接続できない場合があった。
【００２０】
本発明の目的は、移動利用される端末と緊急機関との間の緊急呼を処理するシステムにおいて、回線保留により緊急機関からの再呼び出しの接続の確実性を高めることができる緊急呼処理システムを提供することにある。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明に係る緊急呼処理装置は、移動利用される端末と緊急機関との間の緊急呼をＩＰ−ＣＡＮ（IP Connectivity Access Network）、ＩＭＳ（IP Multimedia Subsystem）を経由して処理するシステムに用いられる装置であって、前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の回線を、前記端末−前記ＩＰ−ＣＡＮ−前記ＩＭＳ間の端末側の回線と前記ＩＭＳ−前記緊急機関間の緊急機関側の回線とに分離して確立させる回線確立手段と、前記端末側からの前記緊急呼切断時に、前記端末側の回線を解放すると共に前記緊急機関側の回線を保留する回線保留手段と、前記緊急呼切断後の前記緊急機関から前記端末への再呼び出し時に、保留された前記緊急機関側の回線を利用して前記緊急機関から前記端末へ着信させる再呼び出し手段とを有することを特徴とする。
【００２２】
本発明に係る緊急呼処理方法は、移動利用される端末と緊急機関との間の緊急呼をＩＰ−ＣＡＮ（IP Connectivity Access Network）、ＩＭＳ（IP Multimedia Subsystem）を経由して処理する方法であって、
前記端末から前記緊急機関への緊急呼発信時に、前記端末と前記緊急機関との間の回線を、前記端末−前記ＩＰ−ＣＡＮ−前記ＩＭＳ間の端末側の回線と前記ＩＭＳ−前記緊急機関間の緊急機関側の回線とに分離して確立させる回線確立ステップと、
前記端末側からの前記緊急呼切断時に、前記端末側の回線を解放すると共に前記緊急機関側の回線を保留する回線保留ステップと、
前記緊急呼切断後の前記緊急機関から前記端末への再呼び出し時に、保留された前記緊急機関側の回線を利用して前記緊急機関から前記端末へ着信させる再呼び出しステップとを有することを特徴とする。
【発明の効果】
【００２４】
本発明によれば、移動利用される端末と緊急機関との間の緊急呼を処理するシステムにおいて、回線保留により緊急機関からの再呼び出しの接続の確実性を高めることができる。
【発明を実施するための最良の形態】
【００２５】
次に、本発明に係る緊急呼処理システム、方法、及びプログラムを実施するための最良の形態について図面を参照して詳細に説明する。
【実施例】
【００２６】
図１〜図５を参照して、本実施例について説明する。
【００２７】
本実施例は、ＩＭＳを利用して既存の第３世代携帯電話などの移動を伴う端末に回線交換サービスを提供するシステムに適用したものである。このシステムでは、発信者（通報者）が緊急機関へ電話し、発側切断した場合、通報者から十分な情報を得ていない場合などの理由で緊急機関から発信者へ再呼び出しを可能とする必要がある。そのため、本実施例では、切断時に使用した回線を保留し、再呼び出し時に回線を再捕捉しない。これによれば、最初の通話で使用した回線を切断せず保留することで、再呼び出し時の接続の確実性を高めることができる。
【００２８】
図１は、本実施例に係る緊急呼処理システムの全体構成を示す。
【００２９】
同図に示す緊急呼処理システムは、ＩＭＳ網を経由して移動体網（図示しない）側の第３世代携帯電話（以下、「携帯電話」と称する。）１０から公衆電話網（図示しない）側の緊急機関の端末（以下、「緊急機関」と称する。）２０へ緊急通報（例：国内では１１０番、１１９番、１１８番等）を行えるようにした通報システムに搭載されるもので、携帯電話１０に回線交換サービスを提供するシステム（以下、便宜上、「回線交換サービス提供システム」と呼ぶ。）３０と、ＩＭＳシステム４０とを有する。
【００３０】
ＩＭＳシステム４０は、ＩＭＳの中核を担うＣＳＣＦ（Ｐ−ＣＳＣＦ４１１、Ｓ−ＣＳＣＦ４１２、Ｉ−ＣＳＣＦ４１３、Ｅ−ＣＳＣＦ４１４から構成される。）４１と、緊急機関２０の端末が接続された電話網とＩＭＳ網間でＳＩＰ−ＩＳＵＰ変換を行う機能を有するゲートウェイ装置であるＭＧＣＦ４２と、加入者の端末の位置情報やプロファイル（サービス契約情報）を保持しているＨＳＳ４３とを含む。ＣＳＣＦ４１、ＭＧＣＦ４２、及びＨＳＳ４３は、前述と同様のものを用いるため、その詳細は省略する。
【００３１】
回線交換サービス提供システム３０は、携帯電話１０とＩＭＳシステム４０間に接続されるＩＰ接続アクセスネットワークであるＩＰ−ＣＡＮ（IP Connectivity Access Network）３１と、本発明に係る緊急呼処理装置及びサーバ装置を構成する回線交換サービス用サーバ（以下、「ＣＳ−ＡＳ（Circuit Service Application Server」と略称する。）３２とを有し、ＩＰ−ＣＡＮ３１及びＣＳ−ＡＳ３２をＩＭＳシステム４０に接続することで、ＩＭＳを利用して携帯電話１０に回線交換サービスの提供を可能としている。
【００３２】
ＩＰ−ＣＡＮ３１は、携帯電話１０との間で送受信される信号のプロトコル（本例では、第３世代携帯電話で用いる「ＲＡＮＡＰ：Radio Access Network Application Part」を適用しているが、これに限定されない。）をＩＭＳで用いるＳＩＰに変換する機能を有する。即ち、ＩＰ−ＣＡＮ３１は、携帯電話１０からのＲＡＮＡＰ信号をＳＩＰ信号に変換し、Ｐ−ＣＳＣＦ４１１に送信する一方、これとは逆に、Ｐ−ＣＳＣＦ４１１からのＳＩＰ信号をＲＡＮＡＰ信号に変換し、携帯電話１０に送信する。
【００３３】
ＣＳ−ＡＳ３２は、Ｅ−ＣＳＣＦ４１４により起動され、回線交換サービス特有の制御を行うサーバである。即ち、ＣＳ−ＡＳ３２は、本発明の各手段（回線確立手段、回線保留手段、及び再呼び出し手段）に対応する処理を実行する機能を有し、Ｅ−ＣＳＣＦ４１４からサービス起動要求を受け、携帯電話１０の回線交換サービス特有の制御を行い、Ｅ−ＣＳＣＦ４１４に動作指示を行う。
【００３４】
図２は、ＣＳ−ＡＳ３２の内部構成例を説明するものである。同図に示すように、ＣＳ−ＡＳ３２は、制御部３２１及びメモリ部３３１を有する。
【００３５】
メモリ部３３１は、回線情報であるセッション情報３３２及び信号情報要素３３３を格納する。セッション情報３３２は、「キー」、「Ｃａｌｌ−ＩＤ」、「ＴＯ」、「ＦＲＯＭ」、「相手先キー」、「緊急呼表示」等から構成される。ＣＳ−ＡＳ３２は、セッション情報３３２として、ダイアログＩＤを「キー」に設定し、その呼に付随する情報、例えば呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ、緊急呼識別子等をそれぞれ「Ｃａｌｌ−ＩＤ」、「ＴＯ」、「ＦＲＯＭ」、「相手先キー」、「緊急呼表示」等に設定し、メモリ部３３１に保持して管理する。信号情報要素３３３は、ＳＩＰ信号のヘッダに含まれる「Ｒｅｑｕｅｓｔ−ＵＲＩ」、「ＴＯ」、「Ｆｒｏｍ」、「Ｃａｌｌ−ＩＤ」などの各情報要素から構成される。
【００３６】
制御部３２１は、緊急呼制御部３２２、Ｂ２ＢＵＡ（Back-to-Back User Agent）制御部３２３、及びＳＩＰプロトコル制御部３２４を有する。
【００３７】
緊急呼制御部３２２は、携帯電話１０からの緊急呼の発信時に、ＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、Ｅ−ＣＳＣＦ４１４を経由して送られてくるＳＩＰ信号に乗せた緊急呼セッション識別子から、その携帯電話１０の緊急呼を認識し、緊急呼が認識された場合はセッション情報３３２に「緊急呼表示」を設定し、メモリ部３３１に保持する。また、緊急呼制御部３２２は、どのセッションにいずれのＳＩＰ信号を出すかＢ２ＢＵＡ制御部３２３へ指示する。さらに、緊急呼制御部３２２は、緊急呼特有の信号情報要素３３３を編集し、メモリ部３３１に保持する。
【００３８】
Ｂ２ＢＵＡ制御部３２３は、携帯電話１０からの緊急呼の発信時に、ＳＩＰ信号のセッション情報３３２を捕捉／解放し、緊急呼表示以外のセッション情報３３２を設定し、メモリ部３３１に保持する。また、Ｂ２ＢＵＡ制御部３２３は、緊急呼特有以外の信号情報要素３３３を編集し、メモリ部３３１に保持する。
【００３９】
ＳＩＰプロトコル制御部３２４は、ＳＩＰ信号の送受信を制御し、ＳＩＰのプロトコル規定をチェックし、メモリ部３３１に保持している信号情報要素３３３からＳＩＰ信号を組み立てる。
【００４０】
ＣＳ−ＡＳ３２は、携帯電話１０からの緊急呼発信時に、その緊急呼に対応するＳＩＰの「ＩＮＶＩＴＥ」信号を受信すると、Ｂ２ＢＵＡ制御部３２３により、セッション情報（キー、Ｃａｌｌ−ＩＤ、ＴＯ、ＦＲＯＭ、相手先キー、緊急呼表示等）３３２として、発信側の携帯電話（発端末）１０との間の「セッション１」を設定し、その「セッション１」のダイアログＩＤとその付随情報（呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ（セッション２）、緊急呼識別子等）をメモリ部３３１に保持する。そして、ＣＳ−ＡＳ３２は、着信先の緊急機関２０向けのダイアログＩＤを新たに捕捉（ＣＳ−ＡＳ３２内でダイアログＩＤの払い出しの管理）し、緊急機関２０向けの信号編集を行い、セッション情報（キー、Ｃａｌｌ−ＩＤ、ＴＯ、ＦＲＯＭ、相手先キー、緊急呼表示等）３３２として、緊急機関２０との間の「セッション２」に対応するダイアログＩＤとその付随情報（呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ（セッション１）、緊急呼識別子等）をメモリ部３３１に保持する。
【００４１】
ＣＳ−ＡＳ３２は、携帯電話１０からの発側切断時に、メモリ部３３１に保持されているセッション情報３３２の内、発信側の携帯電話１０向けの「セッション１」の情報と、着信側の緊急機関２０向けの「セッション２」の情報の内の相手側ダイアログＩＤ（「セッション１」のダイアログＩＤ）とを削除する。
【００４２】
ＣＳ−ＡＳ３２は、着信側の緊急機関２０からの再呼び出しでは、メモリ部３３１のセッション情報３３２として、発信側の携帯電話１０向けのダイアログＩＤを払い出し、「セッション３」に対応するダイアログＩＤとその付随情報（呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ、緊急呼識別子等）を作成してメモリ部３３１に保持するとともに「セッション２」の相手側ダイアログＩＤに「セッション３」を設定し、メモリ部３３１に保持する。
【００４３】
上記構成において、図１に示すように、携帯電話１０が緊急機関２０と通話すると、携帯電話１０、ＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、Ｅ−ＣＳＣＦ４１４、ＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、ＭＧＣＦ４２、緊急機関２０の順に回線のパス（経路）が確立する。
【００４４】
一方、携帯電話１０側から呼を解放した場合、通常これらのパスを構成する回線は全て解放されるが、本実施例では、ＣＳ−ＡＳ３２が携帯電話１０からの切断を検知し、ＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、ＭＧＣＦ４２、緊急機関２０の間の回線のパスを切断せず、保留する（図１中の回線保留区間Ａ１参照）。なお、携帯電話１０、ＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、Ｅ−ＣＳＣＦ４１４、ＣＳ−ＡＳ３２間の回線のパスは、携帯電話１０が在圏エリアを移動することを考慮し解放する（図１中の回線解放区間Ａ２参照）。
【００４５】
このようにして、本実施例では、緊急機関２０から携帯電話１０への再呼び出しが行われた場合、ＣＳ−ＡＳ３２と緊急機関２０の間の回線を保留しているので、再呼び出し時に回線が捕捉できないことで通話が不能になる、ということを防ぐことができる。
【００４６】
次に、図３〜図８を参照して、本実施例の全体動作について説明する。
【００４７】
図３〜図５は、携帯電話１０の緊急呼発信からその発側切断を経て緊急機関２０の再呼び出しまでの一連のシーケンスを説明するものである。
【００４８】
最初に、緊急呼の発信シーケンスについて説明する。この概要を図６に示す。
【００４９】
図３及び図４を参照すると、通報者の携帯電話（発端末）１０から緊急機関２０への緊急呼の発信時に、携帯電話１０は、携帯電話用プロトコルに基づく呼設定用の「ｓｅｔｕｐ」信号をＩＰ−ＣＡＮ３１に送る（ステップＳ１）。
【００５０】
ＩＰ−ＣＡＮ３１は、その応答メッセージとして、携帯電話用プロトコルに基づく呼設定受付用の「ｃａｌｌｐｒｏｃ」信号を携帯電話１０に送る（ステップＳ２）と共に、ＳＩＰの「ＩＮＶＩＴＥ」信号に変換し、その「ＩＮＶＩＴＥ」信号をＰ−ＣＳＣＦ４１１に送る（ステップＳ３）。このＩＮＶＩＴＥ信号には、送信元のアドレスを示す「Ｆｒｏｍ」ヘッダに携帯電話１０のアドレス（電話番号等）、宛先のアドレスを示す「Ｔｏ」ヘッダに緊急機関２０のアドレス（電話番号等）が記述され、緊急呼である旨を示す緊急呼識別子が設定されている。
【００５１】
Ｐ−ＣＳＣＦ４１１は、ＩＰ−ＣＡＮ３１からの「ＩＮＶＩＴＥ」信号を受信すると、その応答メッセージとして「１００  Ｔｒｙｉｎｇ」信号をＩＰ−ＣＡＮ３１に返す（ステップＳ４）と共に、その「ＩＮＶＩＴＥ」信号をＥ−ＣＳＣＦ４１４に送る（ステップＳ５）。同様に、Ｅ−ＣＳＣＦ４１４は、Ｐ−ＣＳＣＦ４１１からの「ＩＮＶＩＴＥ」信号を受信すると、その応答メッセージとして「１００  Ｔｒｙｉｎｇ」信号をＰ−ＣＳＣＦ４１１に返す（ステップＳ６）と共に、その「ＩＮＶＩＴＥ」信号をＣＳ−ＡＳ３２に送る（ステップＳ７）（図６中の矢印で示すシグナリングの経路参照）。
【００５２】
次いで、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、Ｅ−ＣＳＣＦ４１４からの「ＩＮＶＩＴＥ」信号を受信すると、その応答メッセージとして「１００  Ｔｒｙｉｎｇ」信号をＥ−ＣＳＣＦ４１４に返す（ステップＳ６）と共に、緊急呼制御部３２２により、受信した「ＩＮＶＩＴＥ」信号の「Ｔｏ」ヘッダに記述されている緊急機関２０のアドレスから、緊急機関２０への発呼であることを認識する。
【００５３】
そうすると、ＣＳ−ＡＳ３２は、Ｂ２ＢＵＡ制御部３２３により、受信した「ＩＮＶＩＴＥ」信号に基づいて、セッション情報３３２として、「セッション１」を設定し、メモリ部３３１に保持する。この場合、「セッション１」の「キー」、「Ｃａｌｌ−ＩＤ」、「ＴＯ」、「ＦＲＯＭ」、「相手先キー」、「緊急呼表示」には、それぞれ、セッション１のダイアログＩＤ、呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ（本例では、「セッション２」のダイアログＩＤ）、緊急呼識別子が設定される。
【００５４】
これと共に、ＣＳ−ＡＳ３２は、Ｂ２ＢＵＡ制御部３２３により、受信した「ＩＮＶＩＴＥ」信号に基づいて、「セッション１」のダイアログＩＤに対応付けて、緊急機関２０向けのダイアログＩＤ（「セッション２」のダイアログＩＤ）を新たに捕捉（ＣＳ−ＡＳ３２内でダイアログＩＤの払い出しの管理）し、緊急機関２０向けの信号編集を行い、セッション情報３３２として、「セッション２」を設定し、メモリ部３３１に保持する。この場合、「セッション２」の「キー」、「Ｃａｌｌ−ＩＤ」、「ＴＯ」、「ＦＲＯＭ」、「相手先キー」、「緊急呼表示」には、それぞれ、セッション２のダイアログＩＤ、呼識別子、呼の方向性（生起側、非生起側）、相手側のダイアログＩＤ（本例では、「セッション１」のダイアログＩＤ）、緊急呼識別子が設定される。
【００５５】
これにより、ＣＳ−ＡＳ３２は、携帯電話１０と緊急機関２０との間の緊急呼の回線によるセッションを、携帯電話１０側のＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、Ｅ−ＣＳＣＦ４１４、ＣＳ−ＡＳ３２までの「セッション１」と、緊急機関２０側のＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、ＭＧＣＦ４２、緊急機関２０までの「セッション２」に分離して確立する（図６中の太線で示すセッション１、２の経路参照）。
【００５６】
上記処理を終了すると、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、緊急呼セッション識別子を乗せたＳＩＰの「ＩＮＶＩＴＥ信号」をＥ−ＣＳＣＦ４１４に送る（ステップＳ１０）。Ｅ−ＣＳＣＦ４１４は、ＣＳ−ＡＳ３２からの「ＩＮＶＩＴＥ」信号を受信すると、その応答メッセージとして「１００  Ｔｒｙｉｎｇ」信号をＣＳ−ＡＳ３２に返す（ステップＳ１１）と共に、そのＩＮＶＩＴＥ信号をＭＧＣＦ４２に送る（ステップＳ１２）。ＭＧＣＦ４２は、Ｅ−ＣＳＣＦ４１４からのＩＮＶＩＴＥ信号を受信すると、その応答メッセージとして「１００  Ｔｒｙｉｎｇ」信号をＥ−ＣＳＣＦ４１４に返す（ステップＳ１３）と共に、ＩＳＵＰの「ＩＡＭ（Initial Address Message）」信号に変換して電話網の緊急機関２０に送り、着信させる（ステップＳ１４）（図６中の矢印で示すシグナリングの経路参照）。
【００５７】
緊急機関２０は、ＭＧＣＦ４２からの「ＩＡＭ」信号を受信すると、その応答メッセージとしてＩＳＵＰの「ＡＣＭ（Address Complete Message）」信号をＭＧＣＦ４２に返す（ステップＳ１５）。そうすると、ＭＧＣＦ４２は、その「ＡＣＭ」信号を受信すると、ＳＩＰの「１８３  Ｓｅｓｓｉｏｎ  Ｐｒｏｇｒｅｓｓ」信号をＥ−ＣＳＣＦ４１４に送る（ステップＳ１６）。これにより、「１８３  Ｓｅｓｓｉｏｎ  Ｐｒｏｇｒｅｓｓ」信号は、Ｅ−ＣＳＣＦ４１４から、ＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、及びＰ−ＣＳＣＦ４１１を経て、ＩＰ−ＣＡＮ３１に送られる（ステップＳ１７〜Ｓ２０）。
【００５８】
次いで、緊急機関２０は、ＩＳＵＰの「ＣＰＧ（Call Progress）」信号をＭＧＣＦ４２に送る（ステップＳ２１）。そうすると、ＭＧＣＦ４２は、その「ＣＰＧ」信号を受信すると、ＳＩＰの「１８０  Ｒｉｎｇｉｎｇ」信号に変換し、Ｅ−ＣＳＣＦ４１４に送る（ステップＳ２２）。これにより、「１８０  Ｒｉｎｇｉｎｇ」信号は、Ｅ−ＣＳＣＦ４１４から、ＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、及びＰ−ＣＳＣＦ４１１を経て、ＩＰ−ＣＡＮ３１に送られる（ステップＳ２３〜Ｓ２６）。ＩＰ−ＣＡＮ３１は、その「１８０  Ｒｉｎｇｉｎｇ」信号を受信すると、携帯電話用プロトコルに基づく呼出用の「ａｌｅｒｔ」信号に変換し、携帯電話１０に送る（ステップＳ２７）。
【００５９】
次いで、緊急機関２０は、ＩＳＵＰの「ＡＮＭ（Answer Message）」信号をＭＧＣＦ４２に送る（ステップＳ２８）。そうすると、ＭＧＣＦ４２は、その「ＡＮＭ」信号を受信すると、ＳＩＰの「２００  ＯＫ」信号をＥ−ＣＳＣＦ４１４に送る（ステップＳ２９）。これにより、「２００  ＯＫ」信号は、Ｅ−ＣＳＣＦ４１４から、ＣＳ−ＡＳ３２、Ｅ−ＣＳＣＦ４１４、及びＰ−ＣＳＣＦ４１１を経て、ＩＰ−ＣＡＮ３１に送られる（ステップＳ３０〜Ｓ３３）。
【００６０】
ＩＰ−ＣＡＮ３１は、Ｐ−ＣＳＣＦ４１１からの「２００  ＯＫ」信号を受信すると、携帯電話用プロトコルに基づく応答用の「ｃｏｎｎ」信号に変換し、携帯電話１０に送る（ステップＳ３４）と共に、ＳＩＰの「Ａｃｋ」信号をＰ−ＣＳＣＦ４１１に送る（ステップＳ３５）。これにより、「Ａｃｋ」信号は、Ｐ−ＣＳＣＦ４１１から、Ｅ−ＣＳＣＦ４１４、ＣＳ−ＡＳ３２、及びＥ−ＣＳＣＦ４１４を経て、ＭＧＣＦ４２に送られる（ステップＳ３６〜Ｓ３９）。次いで、携帯電話１０は、携帯電話用プロトコル（ＲＡＮＡＰ）に基づく応答確認用の「ｃｏｎｎ  ａｃｋ」信号をＩＰ−ＣＡＮ３１に送る（ステップＳ４０）。
【００６１】
以上の緊急呼の発信シーケンスにより、携帯電話１０と緊急機関２０との間の回線によるセッションが確立され、緊急通報による通信が行なわれる（ステップＳ４１）。
【００６２】
次に、上記セッション確立後の緊急呼の発側切断シーケンスについて説明する。この概要を図７に示す。
【００６３】
図４を参照すると、通報者の携帯電話１０からの発側切断時に、携帯電話１０は、携帯電話用プロトコルに基づく切断用の「ｄｉｓｃ」信号をＩＰ−ＣＡＮ３１に送る（ステップＳ４２）。
【００６４】
ＩＰ−ＣＡＮ３１は、その応答メッセージとして、携帯電話用プロトコルに基づく解放用の「ｒｅｌｅａｓｅ」信号を携帯電話１０に送る（ステップＳ４３）と共に、ＳＩＰの切断要求である「ＢＹＥ」信号に変換し、Ｐ−ＣＳＣＦ４１１に送る（ステップＳ４４）。これにより、「ＢＹＥ」信号は、Ｐ−ＣＳＣＦ４１１から、Ｅ−ＣＳＣＦ４１４を経て、ＣＳ−ＡＳ３２に送られる（ステップＳ４５及びＳ４６）（図７中の矢印で示すシグナリングの経路参照）。
【００６５】
ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、上記「ＢＹＥ」信号を受信すると、その応答として「２００  ＯＫ」信号をＥ−ＣＳＣＦ４１４に返す（ステップＳ４７）。これにより、「２００  ＯＫ」信号は、Ｅ−ＣＳＣＦ４１４から、Ｐ−ＣＳＣＦ４１１を経て、ＩＰ−ＣＡＮ３１に送られる（ステップＳ４８及びＳ４９）。その間に、携帯電話１０は、携帯電話用プロトコルに基づく解放完了用の「ｒｅｃｏｍ」信号をＩＰ−ＣＡＮ３１に送る（ステップＳ５０）。
【００６６】
これと並行して、ＣＳ−ＡＳ３２は、Ｂ２ＢＵＡ制御部３２３により、メモリ部３３１に保持されているセッション情報３３２の内、「セッション１」の情報と「セッション２」の情報の相手側ダイアログＩＤ（セッション１）とを削除し、これによりＣＳ−ＡＳ３２と携帯電話１０との間のセッション１を解放する（ステップＳ５１）（図７中の点線で示すセッション１の経路参照）。
【００６７】
さらに、ＣＳ−ＡＳ３２は、緊急機関２０側の「セッション２」に関しては、ＳＩＰプロトコル制御部３２４により、保留である表示（保留表示）を含むＳＩＰ信号をＥ−ＣＳＣＦ４１４に送る（ステップＳ５１、Ｓ５２）。ここで、保留表示を含むＳＩＰ信号は、一例として、ＳＩＰの「ＩＮＦＯ」信号を想定するが、これに限らず、どの信号を用いてもよい。「ＩＮＦＯ」信号を用いる場合は、一例として、拡張ヘッダの「Ｈｏｌｄ」ヘッダに「Ｈｏｌｄ」を設定する（Ｈｏｌｄ：Ｈｏｌｄ）等の方法により、保留表示を含むＳＩＰ信号としてもよい。
【００６８】
Ｅ−ＣＳＣＦ４１４は、ＣＳ−ＡＳ３２からの保留表示を含む「ＩＮＦＯ」信号を受信すると、その信号をさらにＭＧＣＦ４２に送る（ステップＳ５３）。ＭＧＣＦ４２は、その保留表示を含む「ＩＮＦＯ」信号を受信すると、そのＳＩＰの「ＩＮＦＯ」信号をＩＳＵＰの「ＩＮＦ」信号に変換し、緊急機関２０側に対し通報者が切断した旨と回線が保留されている旨を通知する（ステップＳ５５）。これにより、ＣＳ−ＡＳ３２と緊急機関２０との間の「セッション２」を保留する（ステップＳ５６）（図７中の太線で示すセッション２の経路参照）。ここで、「ＩＮＦ」信号による緊急機関２０側の緊急呼切断保留表示の例として、例えば「ＩＮＦ」信号の該当情報要素の設定コードが「００」のときに「表示なし」、「０１」のときの「緊急呼保留中（保留）」、「１０」のときに「緊急機関からの再呼出し（再呼出し）」、「１１」のときの「緊急呼への再応答（応答）」等と設定してもよい。この場合、ＭＧＣＦ４２から緊急機関２０への「ＩＮＦ」信号の設定コードを「０１」に設定することにより、発側切断による「セッション１」の解放及び「セッション２」の保留が通知される。
【００６９】
次に、上記発側切断後の緊急呼の再呼び出しシーケンスについて説明する。この概要を図８に示す。
【００７０】
図６を参照すると、上記発側切断後に緊急機関２０から通報者の携帯電話１０に対して再呼び出しを行う場合、緊急機関２０は、再呼び出し要求としてＩＳＵＰの「ＩＮＦ」信号をＭＧＣＦ４２に送る（ステップＳ５７）。ここで、上記の緊急呼切断保留表示の例では、「ＩＮＦ」信号の設定コードを「１０」に設定することにより、発側切断後の再呼び出し要求を行う。
【００７１】
ＭＧＣＦ４２は、緊急機関２０からの再呼び出し要求の「ＩＮＦ」信号を受信すると、これを再呼び出し表示を含むＳＩＰ信号に変換し、Ｅ−ＣＳＣＦ４１４に送る（ステップＳ５８、Ｓ５９）。ここで、再呼び出し表示を含むＳＩＰ信号は、一例として、ＳＩＰの「ＩＮＦＯ」信号を想定するが、これに限らずどの信号を用いてもよい。「ＩＮＦＯ」信号を用いる場合は、その一例として、拡張ヘッダの「Ｈｏｌｄ」ヘッダに「Ｃａｌｌｂａｃｋ」を設定する（Ｈｏｌｄ：Ｃａｌｌｂａｃｋ）等の方法により、再呼び出し表示を含むＳＩＰ信号としてもよい。
【００７２】
Ｅ−ＣＳＣＦ４１４は、ＭＧＣＦ４２からの再呼び出し表示を含む「ＩＮＦＯ」信号を受信すると、その信号をＣＳ−ＡＳ３２に送信する（ステップＳ６０）。
【００７３】
ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、Ｅ−ＣＳＣＦ４１４からの再呼び出し表示を含む「ＩＮＦＯ」信号を受信すると、Ｂ２ＢＵＡ制御部３２１により、携帯電話１０向けのダイアログＩＤを払い出し、携帯電話１０側のＣＳ−ＡＳ３２から、Ｉ−ＣＳＣＦ４１３、Ｓ−ＣＳＣＦ４１２、Ｐ−ＣＳＣＦ４１１、ＩＰ−ＣＡＮ３１までの「セッション３」を作成すると共に、「セッション２」の「相手側キー」に「セッション３」のダイアログＩＤを設定し、携帯電話１０側の「セッション３」のダイアログＩＤを捕捉する（ステップＳ６１）。そして、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、「ＩＮＶＩＴＥ」信号の「ＴＯ」ヘッダに通報者のアドレスを乗せて、Ｉ−ＣＳＣＦ４１３に送信する（ステップＳ６０）（図８中の矢印で示すシグナリングの経路参照）。
【００７４】
これにより、Ｉ−ＣＳＣＦ４１３を使用する場合の通常の発信手順（前述参照）により、Ｉ−ＣＳＣＦ４１３から、Ｓ−ＣＳＣＦ４１２、Ｐ−ＣＳＣＦ４１１を経由して、ＩＰ−ＣＡＮ３１に「ＩＮＶＩＴＥ」信号をその応答メッセージである「１００  Ｔｒｙｉｎｇ」信号を相手側に返しながら送る（ステップＳ６２〜Ｓ６９）。
【００７５】
ＩＰ−ＣＡＮ３１は、Ｐ−ＣＳＣＦ４１１からの上記「ＩＮＶＩＴＥ」信号を受信すると、携帯電話用プロトコルに基づく「ｓｅｔｕｐ」信号に変換して携帯電話１０に送り（ステップＳ７０）、これにより携帯電話１０に着信させる（図８中の矢印で示すシグナリングの経路参照）。
【００７６】
以上詳細に実施例の構成を述べたが、図１〜図８に示す携帯電話１０、緊急機関２０、ＩＰ−ＣＡＮ３１、ＣＳＣＦ４１（Ｐ−ＣＳＣＦ４１１、Ｓ−ＣＳＣＦ４１２、Ｉ−ＣＳＣＦ４１３、Ｅ−ＣＳＣＦ４１４）、ＭＧＣＦ４２は、当業者にとってよく知られているので、その詳細な構成は省略する。
【００７７】
次に、図９に示すフローチャートを使用して、ＣＳ−ＡＳ３２の動作を説明する。
【００７８】
図９（ａ）は、図６に示す緊急呼の発信シーケンスに対応する動作フロー、図９（ｂ）は、図７に示す緊急呼の発側切断シーケンスに対応する動作フロー、図９（ｃ）は、図８に示す緊急呼の再呼び出しシーケンスに対応する動作フローをそれぞれ示す。
【００７９】
まず、図９（ａ）において、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、携帯電話１０からＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、Ｅ−ＣＳＣＦ４１４を経由して送られてくるＳＩＰの「ＩＮＶＩＴＥ」信号を受信すると（ステップＳｔ１１）、緊急呼制御部３２２により、その「ＩＮＶＩＴＥ」信号のＴＯヘッダを参照し、あて先が緊急機関２０のアドレスか否かを判定する（ステップＳｔ１２）。その結果、あて先が緊急機関２０のアドレスの場合（ＹＥＳ）、ＣＳ−ＡＳ３２は、緊急呼制御部３２２により、該当するセッション情報３３２（携帯電話１０側の「セッション１」と、緊急機関２０側の「セッション２」）に緊急呼を設定し、メモリ部３３１に格納する（ステップＳｔ１３）。一方、あて先が緊急機関２０のアドレスでない場合（ＮＯ）、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、Ｅ−ＣＳＣＦ４１４に「ＩＮＶＩＴＥ」信号を送信する（ステップＳｔ１４）。
【００８０】
次に、図９（ｂ）において、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、携帯電話１０からＩＰ−ＣＡＮ３１、Ｐ−ＣＳＣＦ４１１、及びＥ−ＣＳＣＦ４１４を経由して送られてくるＳＩＰの「ＢＹＥ」信号を受信すると（ステップＳｔ２１）、緊急呼制御部３２２により、上記ステップＳｔ１３でメモリ部３３１に格納した該当するセッション情報３３２（「セッション１」）を参照し、緊急呼であるか否かを判定する（ステップＳｔ２２）。その結果、緊急呼である場合（ＹＥＳ）、Ｂ２ＢＵＡ制御部３２３及びＳＩＰプロトコル制御部３２４により、Ｅ−ＣＳＣＦ４１４を介してＰ−ＣＳＣＦ４１１及びＩＰ−ＣＡＮ３１に「２００  ＯＫ」信号を返送して、携帯電話１０側の「セッション１」を解放し（ステップＳ２３）、Ｅ−ＣＳＣＦ４１４を介してＭＧＣＦ４２に保留表示を含むＳＩＰ信号を送信し（ステップＳｔ２４）、緊急機関２０側の「セッション２」を保留する。一方、緊急呼でない場合（ＮＯ）、ＣＳ−ＡＳ３２は、Ｂ２ＢＵＡ制御部３２３及びＳＩＰプロトコル制御部３２４により、通常の切断処理を行う（ステップＳｔ２５）。
【００８１】
次に、図９（ｃ）において、ＣＳ−ＡＳ３２は、ＳＩＰプロトコル制御部３２４により、緊急機関２０からＭＧＣＦ４２及びＥ−ＣＳＣＦ４１４を経由して送られてくる再呼び出し表示を含むＳＩＰ信号を受信すると（ステップＳｔ３１）、Ｂ２ＢＵＡ制御部３２３及びＳＩＰプロトコル制御部３２４により、携帯電話１０側の「セッション３」を作成し、Ｉ−ＣＳＣＦ４１３に「ＩＮＶＩＴＥ」信号を送信し（ステップＳｔ３２）、Ｉ−ＣＳＣＦ４１３から、Ｓ−ＣＳＣＦ４１２、Ｐ−ＣＳＣＦ４１１、及びＩＰ−ＣＡＮ３１を経由して、携帯電話１０に着信させる。
【００８２】
以上説明したように、本実施例においては、以下に記載するような効果を奏する。
【００８３】
第１の効果は、ＣＳ−ＡＳ３２により携帯電話１０と緊急機関２０との間の緊急呼の回線を保留しているので、緊急機関２０からの再呼び出し時の接続の確実性を高めることである。
【００８４】
第２の効果は、ＣＳ−ＡＳ３２のＢ２ＢＵＡ制御部３２３により携帯電話１０と緊急機関２０との間でＢ２ＢＵＡ制御を行っているため、通報者向きの回線のみ解放でき、再呼び出し待ち中に通報者が在圏移動した場合、無効な回線保留を防げることできることである。
【００８５】
第３の効果は、ＣＳ−ＡＳ３２のＢ２ＢＵＡ制御部３２３により携帯電話１０と緊急機関２０との間でＢ２ＢＵＡ制御を行っているため、再呼び出し待ち中に通報者が在圏移動した場合でも再呼び出しができることである。
【００８６】
なお、上記実施例では、ＩＭＳを利用した場合を説明しているが、本発明はこれに限らず、移動利用される端末と緊急機関との間の緊急呼を処理可能なものであれば、いずれの通信ネットワークを利用したものでも適用可能である。また、移動利用される端末は、第３世代携帯電話に限られず、例えば第３世代以降の携帯電話にも適用可能である。
【００８７】
また、上記実施例に係る緊急呼処理システムは、ＣＳ−ＡＳ３２（回線交換サービス用サーバ）により実現されているが、本発明の各手段（回線確立手段、回線保留手段、及び再呼び出し手段）に対応する処理を実行可能なものであれば、その物理的構成、システム内部のハードウェア（回路）及びソフトウェア（プログラム）構成については、特に限定されるものではない。例えば、１台のサーバ機で構成しても、複数台のサーバ機で構成してもよい。或いは、本発明の各手段やその機能ごとに独立して個別の回路やユニット或いはプログラム部品（プログラムモジュール等）を構成したり、１つの回路やユニット内に一体的に構成したりする等、いずれの形態でも提供可能である。これらの形態は、実際に使用するシステムの機能や用途等の事情に応じて適宜選択可能である。
【００８８】
また、上述した本発明の各手段に対応して、これらと同様の処理を行う各ステップを有する緊急呼処理方法も、本発明の範疇に含まれる。
【００８９】
さらに、上述した本発明の各手段の少なくとも一部をＣＰＵ（Central Processing Unit）を有するプロセッサ等のコンピュータによるソフトウェア処理で実現する場合には、そのコンピュータを機能させるためのプログラム（緊急呼処理プログラム）も、本発明の範疇に含まれる。このプログラムは、ＣＰＵにより直接実行可能な形式のプログラムに限らず、ソース形式のプログラムや、圧縮処理されたプログラム、暗号化されたプログラム等、種々形態のプログラムを含む。また、このプログラムは、システム全体の制御を行うＯＳ（Operating System）やファームウェア等の制御プログラムと連携して動作し、或いはその一部に組み込まれて一体的に動作するアプリケーションプログラムやそれを構成するソフトウェア部品（ソフトウェアモジュール）等、いずれの形態でも提供可能である。さらに、このプログラムは、無線又は有線回線を介して他のサーバ機からダウンロードして自システム内の記録媒体にインストールして使用することもできる。これらの形態は、実際に使用するシステムの機能や用途等の事情に応じて適宜選択可能である。
【００９０】
また、上記のコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体も、本発明の範疇に含まれる。この場合、記録媒体は、ＲＯＭ（Read Only Memory）等のメモリ等、装置内に固定して使用されるものや、利用者により持ち運びが可能な可搬型のもの等、いずれの形態でも提供可能である。
【産業上の利用可能性】
【００９１】
本発明は、ＩＭＳを利用して携帯電話に回線交換サービスを提供する装置、方法、プログラム、サーバ、システム等の用途に適用できる。
【図面の簡単な説明】
【００９２】
【図１】本発明の一実施例に係る緊急呼処理システムの全体構成を示す概略ブロック図である。
【図２】図１に示すＣＳ−ＡＳの内部構成を示す概略ブロック図である。
【図３】図１に示す緊急呼処理システムの全体動作を説明するシーケンス図である。
【図４】図３に続き、図１に示す緊急呼処理システムの全体動作を説明するシーケンス図である。
【図５】図４に続き、図１に示す緊急呼処理システムの全体動作を説明するシーケンス図である。
【図６】図１に示す緊急呼処理システムによる緊急呼の発信シーケンスを説明する図である。
【図７】図１に示す緊急呼処理システムによる緊急呼の発側切断シーケンスを説明する図である。
【図８】図１に示す緊急呼処理システムによる緊急呼の再呼び出しシーケンスを説明する図である。
【図９】（ａ）〜（ｃ）は、図６〜図８に示す各シーケンスに対応するＣＳ−ＡＳの動作を説明するフローチャートである。
【符号の説明】
【００９３】
１０  携帯電話
２０  緊急機関
３０  回線交換サービス提供システム
３１  ＩＰ−ＣＡＮ
３２  ＣＳ−ＡＳ（回線交換サービス用サーバ）
４０  ＩＭＳシステム
４１  ＣＳＣＦ
４２  ＭＧＣＦ
４３  ＨＳＳ
３２１  制御部
３２２  緊急呼制御部
３２３  Ｂ２ＢＵＡ制御部
３２４  ＳＩＰプロトコル制御部
３３１  メモリ部
３３２  セッション情報
３３３  信号情報要素
４１１  Ｐ−ＣＳＣＦ
４１２  Ｓ−ＣＳＣＦ
４１３  Ｉ−ＣＳＣＦ
４１４  Ｅ−ＣＳＣＦ
【図１】
0005224036.tif 000002
【図２】
0005224036.tif 000003
【図３】
0005224036.tif 000004
【図４】
0005224036.tif 000005
【図５】
0005224036.tif 000006
【図６】
0005224036.tif 000007
【図７】
0005224036.tif 000008
【図８】
0005224036.tif 000009
【図９】
0005224036.tif 000010