JPWO2016208768A1 - 通信装置、端末、及び通信方法 - Google Patents

Abstract

本発明は、ローミング先からの呼を、正確に、効率的に、加入者の位置する場所に応じて接続可能とする通信装置を提供する。通信装置は、端末の位置情報を取得する位置情報取得部と、前記端末が発した呼の要求を受ける受信部と、前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定するサービス特定部と、前記要求のサービスを提供できない場合、応答を前記端末に送信する送信部と、を備える。

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１５−１２８８５６号（２０１５年６月２６日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信装置、端末、及び通信方法に関する。

３ＧＰＰ（3rd Generation Partnership Project）において規定されるＬＴＥ（Long Term Evolution）においてＩＰマルチメディアサブシステム（IP(Internet Protocol) Multimedia Subsystem：ＩＭＳ）を介して音声通話相手に接続するため、ＶｏＬＴＥ（Voice over LTE）が用いられる。ＶｏＬＴＥは、ＬＴＥ方式で、音声通話をデータ通信（パケット通信）として提供し、システム構成として、ＶｏＬＴＥ対応の端末（User Equipment：ＵＥ）、ＬＴＥ／ＥＰＣ（Evolved Packet Core）、ＩＭＳを含む。ＩＭＳを介して緊急呼を、警察、消防署・救急等のＰＳＡＰ（Public Safety Answering Point：緊急通報受付けセンタ）に接続する方法が非特許文献１の４．１ Architectural Principles等に規定されている。ＩＭＳ緊急呼とはＩＭＳで提供される緊急呼をいう（例えば日本国内の１１０番）。緊急呼は、テレコムの定義として、ローカルサービスというカテゴリーに入る。つまり、１１０番や１１９番は、その地域（＝日本国内）でのみ有効である。ヨーロッパでの緊急番号（警察、救急、消防）は１２２であり（イギリスでは警察は１１０）、ヨーロッパでのみ意味を持つ。

端末（ＵＥ）がＩＭＳ緊急呼を発信する場合、端末（ＵＥ）は、緊急呼用のＰＤＮ（Packet Data Network）に対するコネクション（Emergency PDNコネクション）の設定を行う。端末がＩＭＳに登録されていない場合、端末は、IMS Emergency Registration処理を行った上で、ＩＭＳ内のＰ−ＣＳＣＦ（Proxy Call Session Control Function:呼セッション制御機能）に対し、緊急呼の発信であることを示すＳＩＰ（Session Initiation Protocol）のＩＮＶＩＴＥリクエストを送信する。ＩＭＳがＩＮＶＩＴＥリクエストを受信した後に、ＩＭＳは、端末の位置情報に基づいて、緊急呼の接続先を選択する。例えば、Ｐ−ＣＳＣＦが、端末からのＩＮＶＩＴＥリクエストを受信した後に、緊急呼を制御するＳＩＰサーバであるＥ−ＣＳＣＦ（Emergency Call Session Control Function：緊急呼用呼セッション制御機能）に対し、Ｐ−ＣＳＣＦがＩＮＶＩＴＥリクエストを転送する。Ｅ−ＣＳＣＦは、ＬＲＦ（Location Retrieval Function）を介して端末の位置情報として、例えば端末の在圏セルのセル識別情報を取得する。Ｅ−ＣＳＣＦは、接続すべきＰＳＡＰ（Public Safety Answering Point）へのルートを選択し、ＩＮＶＩＴＥリクエストを送信する。ＬＲＦは、ＩＭＳ緊急セッションを開始した端末の位置情報とＰＳＡＰへのルート情報とを検索する機能を有する。なお、ＩＮＶＩＴＥリクエストの「Ｒｅｑｕｅｓｔ−ＵＲＩ（Uniform Resource Identifier）」の部分には、緊急サービスＵＲＮ（Emergency Service URN(uniform resource name)）（例えば、urn:service:sos.police）が含まれる。緊急サービスＵＲＮに基づいて、Ｅ−ＣＳＣＦは、警察のＰＳＡＰに向けて当該緊急呼の接続要求を送信する。

3GPP TS 23.167 V12.1.0 (2015-03) 4.1, 6.1, 7.1.2, 7.3 3GPP TS 24.229 V13.1.0 (2015-03) 5.1, 5.2, 7.2A.4 3GPP TSG SA WG2 Meeting #109, S2-152061 (2015-05)

非特許文献３等に開示されるＳ８ＨＲ（S8 Home Routed）は、ＶｏＬＴＥのローミング方式の一形態である。Ｓ８ＨＲでは、ＥＰＣ（Evolved Packet Core）コア網のＳＧＷ（Serving gateway）とＰＧＷ（Packet Data Network gateway）との間のＳ８インタフェースが、オペレータ網を跨ぐ形態で用いられる。例えば、呼のサービスを行うＩＭＳ（IP Multimedia Subsystem）がホーム網（ＨＰＬＭＮ（Home PLMN（Public Land Mobile Network））側にあり、端末（ＵＥ）がＶＰＬＭＮ（Visited PLMN）にローミングしたとする。この場合、ＰＧＷ、ＰＣＲＦ（Policy and Charging Rules Function）、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）はホーム網（ＨＰＬＭＮ）に位置している。Ｓ８ＨＲでは、Ｓ８インタフェースを用いてＩＭＳトラヒックを含むすべてのＩＰ（Internet Protocol）トラヒックが、ホーム網（ＨＰＬＭＮ）からローミング先の端末（ＵＥ）に提供される。ＰＧＷが、端末（ＵＥ）のホーム網（ＨＰＬＭＮ）に存在し、端末（ＵＥ）に割り当てられるＩＰアドレスがＰＧＷを通じてホーム網側のオペレータから払い出される。

Ｓ８ＨＲによるＩＭＳ緊急呼は、端末（ＵＥ）のユーザが移動先（ローミング先）で発信したＩＭＳの緊急呼である。例えば、オランダからの旅行者が日本に滞在し、日本で日本固有の緊急用の番号である１１０番を端末（ホーム網はオランダ）からダイヤル入力した場合、ホーム網がオランダ、ローミング先が日本となる。オランダからの当該旅行者が、日本で当該端末から１１０番をダイヤルした場合、ＩＭＳのトラヒックはすべてオランダに伝送される。前述したように、ＩＭＳ緊急呼は、主に、ＩＭＳのＰ−ＣＳＣＦとＥ−ＣＳＣＦと連携して処理される。この場合、ホーム網であるオランダのＰ−ＣＳＣＦが１１０番を受信する。

Ｐ−ＣＳＣＦがホーム網にある場合の緊急呼の実現方針等に関して非特許文献１が参照される。またＳＩＰ応答コード３８０を送信するＰ−ＣＳＣＦと該応答コードを受信した端末（ＵＥ）については非特許文献２が参照される。

Ｓ８ＨＲによるＩＭＳ緊急呼に対してホーム網で提供されるＩＭＳでローミング先への緊急呼サービスを提供することは、接続遅延、世界規模での緊急番号管理など運用上課題が多い。

例えば、海外ローミング先からのＳ８ＨＲによるＩＭＳへ送信された緊急呼等を、正確に、加入者の位置する場所に応じて接続先に呼接続する事が課題である。そして、非特許文献１、２等にはこれらの課題を解決するための手段は記載されていない。

したがって、本発明は、上記課題に鑑みてなされたものであって、その目的は、ローミング先からの呼を、正確に、効率的に、加入者の位置する場所に応じて接続先に呼接続可能とする装置、方法、端末を提供することにある。

本発明の１つの側面によれば、端末の位置情報を取得する位置情報取得部と、前記端末が発した呼の要求を受ける受信部と、前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定するサービス特定部と、前記要求のサービスを提供できない場合、応答を前記端末に送信する送信部と、を備えた通信装置が提供される。

本発明の別の側面によれば、呼の要求を第一の通信装置に送信する送信部と、前記第一の通信装置から、前記要求が受け付けられないことと前記通信装置で特定された前記要求のサービスとを示す情報を含む応答を受信する受信部と、前記応答に含まれる前記情報に基づいて、前記第一の通信装置が属するドメイン以外のドメインに属する第二の通信装置を選択し、前記要求のサービスの提供を受けるための呼の要求を前記第二の通信装置へ送信する再送信部と、を備えた端末が提供される。

本発明のさらに別の側面によれば、通信装置が、端末の位置情報を取得し、前記端末が発する呼の要求を受け、前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定し、
前記位置情報に対して前記サービスを提供できない場合、応答を前記端末に送信する、通信方法が提供される。

一形態によれば、上記１つの側面に係る通信装置と、上記別の側面に係る少なくとも一つの端末を含む通信システムが提供される。

さらに別の形態によれば、端末の位置情報を取得する位置情報取得部と、前記端末が発した呼の要求を受ける受信処理と、前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定するサービス特定処理と、前記要求のサービスを提供できない場合、応答を前記端末に送信する送信処理とを、通信装置を構成するコンピュータに実行させるプログラムが提供される。

本発明のさらに別の側面によれば、受け付けられないことと前記通信装置で特定された前記要求のサービスとを示す情報を含む応答を受信する受信処理と、前記応答に含まれる前記情報に基づいて、前記第一の通信装置が属するドメイン以外のドメインに属する第二の通信装置を選択し、前記要求のサービスの提供を受けるための呼の要求を前記第二の通信装置へ送信する再送信処理とを、端末を構成するコンピュータに実行させるプログラムが提供される。本発明によれば、上記プログラムを記録した記録媒体（半導体メモリ、磁気ディスク、ＣＤ（Compact Disc）・ＤＶＤ（Digital Versatile Disc）等）が提供される。

本発明は、ローミング先からの呼を、正確に、効率的に、加入者の位置する場所に応じて接続可能とする。

本発明の一実施形態のシステム構成の一例を例示する図である。 本発明の一実施形態の動作例を例示する図である。 本発明の一実施形態の動作例を例示する図である。 図２のステップＳ２の動作の詳細な一例を例示する図である。 本発明の一実施形態のＰ−ＣＳＣＦの構成の一例を例示する図である。 本発明の一実施形態の端末の構成の一例を例示する図である。 本発明の一実施形態の端末の構成の別の例を例示する図である。

本発明の実施形態について説明する。図１は、本発明の一実施形態を説明する図である。ＨＰＬＭＮ所属の端末（ＵＥ）１０がＶＰＬＭＮ側にローミングアウト（ＬＴＥローミングアウト）しているものとする。端末（ＵＥ）１０は、例えばＶｏＬＴＥと、第三世代携帯電話方式（３Ｇ：3rd Generation）との通話モードを有し、通話モード設定により、ＶｏＬＴＥ優先に設定されているものとする。端末（ＵＥ）１０は、電源オン時に基地局（evolved NodeB：ｅＮＢ）２０を介してＥＰＣ３０のＭＭＥ（Mobility Management Entity）３１に位置登録要求を行う。ＭＭＥ３１は、ＨＳＳ（Home Subscriber Server）と連携して端末（ＵＥ）１０の位置登録を行う。ＭＭＥ３１は、ＨＳＳから、例えばＶｏＬＴＥ用ＡＰＮ（Access Point Name）が含まれる端末（ＵＥ）１０の加入者情報を取得し、ＶｏＬＴＥ用ＡＰＮに基づき、接続先のＰＧＷ（PDN(Packet Data Network) gateway）３３を決定する。ＭＭＥ３１がＳＧＷ（Serving gateway）３２に対してＳＧＷ３２とＰＧＷ３３との間のベアラ設定要求を送信すると、ＳＧＷ３２はＰＧＷ３３に対してベアラを設定する。その結果、図１に示すように、ＶＰＬＭＮ側のＳＧＷ３２とＰＧＷ３３との間のＳ８インタフェースにＧＴＰ（GPRS(General Packet Radio Service) Tunneling Protocol）トンネル３４（Ｓ８ ＧＴＰ トンネル）が張られる。なお、ＳＧＷ３２は、基地局２０との間でユーザデータの送受信を行い、ＰＧＷ３２とＰＧＷ３３との間の通信経路の設定及び解放を行う。ＰＧＷ３３は、ＩＭＳ４０やインターネット等のパケットデータ網（ＰＤＮ）と接続される。ＰＧＷ３３は、端末（ＵＥ）１０にＩＰアドレスを割り当て、さらに端末（ＵＥ）１０の接続先となるＩＭＳ４０のＰ−ＣＳＣＦ４１のアドレスを特定する。ＰＧＷ３３は、ＳＧＷ３２とＰＧＷ３３との間のベアラ設定の応答をＳＧＷ３２を介してＭＭＥ３１に送信する。Ｐ−ＣＳＣＦ４１のアドレスは、アタッチ完了応答としてＭＭＥ３１から基地局２０経由で端末（ＵＥ）１０に送信される。

端末（ＵＥ）１０は、上記したように、電源投入後、自らをＥＰＣ３０に登録する（アタッチ）。このアタッチ手順において、ＥＰＣ３０は、端末（ＵＥ）１０の位置登録、及び、端末（ＵＥ）１０へのＩＰアドレスの割り当て、ＳＩＰメッセージ送受信用の通信路（ベアラ）の確立を行う。アタッチ手順が完了した後、端末（ＵＥ）１０は、Ｐ−ＣＳＣＦ４１に対してＳＩＰメッセージ（ＲＥＧＩＳＴＥＲ）を送信することで、自らをＩＭＳ４０へ登録（registration）する。端末（ＵＥ）１０のＥＰＣ３０及びＩＭＳ４０への登録（registration）が完了した後、端末（ＵＥ）１０がＩＭＳサービスを利用する場合、端末（ＵＥ）１０はＩＭＳ４０との間でＳＩＰメッセージを送受信することで通信セッションの確立を行う。図１では、端末（ＵＥ）１０は、ＶＰＬＭＮ側でアタッチし、ホーム網（ＨＰＬＭＮ）側のＩＭＳ４０に登録済みであるものとする。

ＨＰＬＭＮ所属の端末（ＵＥ）１０が、ＶＰＬＭＮ側において、通話モードがＶｏＬＴＥ優先に設定されており、データローミングがオンに設定されている状況で、端末（ＵＤＥ）１０が電話番号１１０や１１９等の緊急通報番号を入力して発呼すると、ＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト）３５が端末（ＵＥ）１０からホーム網（ＨＰＬＭＮ）のＩＭＳ４０のＰ−ＣＳＣＦ４１に送信される。

なお、ＨＰＬＭＮが日本国であり、ＨＰＬＭＮ所属の端末（ＵＥ）１０で、ＨＰＬＭＮ側において例えば電話番号１１９等が入力された場合、端末（ＵＥ）１０は以下の動作を行う。端末（ＵＥ）１０は、電話番号１１９が消防の緊急呼であることを検知（UE detectable emergency call）し、ＳＩＰメッセージのＩＮＶＩＴＥ要求のＲｅｑｕｅｓｔ−ＵＲＩに、消防の緊急サービスＵＲＮである“ｕｒｎ：ｓｅｒｖｉｃｅ：ｓｏｓ．ｆｉｒｅ”等を設定する。これに対して、ＨＰＬＭＮが例えばオランダ等である端末（ＵＥ）１０は、以下の動作を行う。端末（ＵＥ）１０において、日本の緊急通報番号と緊急サービスＵＲＮの対応関係が未設定である場合、ＶＰＬＭＮ側（例えば日本国）において、端末（ＵＥ）１０で電話番号１１９等が入力されても、端末（ＵＥ）１０は、電話番号１１９等を緊急呼と検出することができない（Non UE detectable emergency call）。端末（ＵＥ）１０は、電話番号をそのままＲｅｑｕｅｓｔ−ＵＲＩに設定し、ＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト）３５をホーム側のＰ−ＣＳＣＦ４１に送信する。

ＩＭＳ４０のＰ−ＣＳＣＦ４１がＳＩＰのＩＮＶＩＴＥリクエスト３５を受けると、Ｐ−ＣＳＣＦ４１は、端末（ＵＥ）１０の位置情報（P-Access-Network-infoヘッダ）と、ダイヤルされた宛先電話番号（Ｒｅｑｕｅｓｔ−ＵＲＩ）とに基づいてＳ８ＨＲでの緊急呼発信を認識する。その結果、ＩＭＳ４０のＰ−ＣＳＣＦ４１は、端末（ＵＥ）１０に対してＳＩＰの応答（応答コード：３８０）３６を返送する。Ｐ−ＣＳＣＦ４１は、ＨＳＳ、ＰＣＲＦ等、ＩＭＳ４０に配置される他の装置に問い合わせて端末（ＵＥ）１０の位置情報を取得してもよい。Ｐ−ＣＳＣＦ４１は、ＨＳＳ、ＰＣＲＦ等、ＩＭＳ４０に配置される他の装置に問い合わせて得られる情報、ＳＩＰのＩＮＶＩＴＥリクエスト３５に含まれるＳＩＰヘッダに設定される他の情報、または、Ｐ−ＣＳＣＦ４１に事前設定されるデータなどを考慮することで、Ｓ８ＨＲでの緊急呼発信を認識してもよい。

ＳＩＰ応答の応答コード（ｒｅｓｐｏｎｓｅ ｃｏｄｅ）は、ステータスコード（ｓｔａｔｕｓ ｃｏｄｅ）ともいう。ＳＩＰ応答の応答コード３００番台は、ユーザに要求先の変更を求めるリダイレクション応答である。“380 Alternative Service”は指定されたサービスは利用できないが代替サービスが存在することを意味する。３００番台のリダイレクション応答として、
・３００：Multiple Choices（複数のリダイレクト候補あり）、
・３０１：Moved Permanently（恒久的に場所を移動）、
・３０２：Moved Temporarily（一時的に場所を移動）、
・３０５：Use Proxy（ＳＩＰプロキシ使用要求）
等がＩＥＴＦ（Internet Engineering Task Force） ＲＦＣ（Request For Comments） ３２６１の２１．３に定義されている。ＳＩＰリクエストに対する成功応答は２００番台（ＯＫ）、エラーは４００番台である。

図１において、Ｐ−ＣＳＣＦ４１は、端末（ＵＥ）１０からのＩＮＶＩＴＥリクエスト３５を受け取り、端末（ＵＥ）１０の位置情報（P-Access-Network-infoヘッダ）と、Ｒｅｑｕｅｓｔ−ＵＲＩの宛先電話番号とに基づき、ＩＮＶＩＴＥリクエスト３５がＩＭＳ４０でサービス可能な呼か判断する。Ｐ−ＣＳＣＦ４１は、ＩＮＶＩＴＥリクエスト３５がＩＭＳ４０でサービス可能な呼であると判断した場合、Ｐ−ＣＳＣＦ４１は、リダイレクション応答を行わず、Ｅ−ＣＳＣＦ４３に向けてＩＮＶＩＴＥリクエスト３５を送信する。

Ｅ−ＣＳＣＦ４３は、ＬＲＦ（Location Retrieval Function）を介して端末（ＵＥ）１０の位置情報として、例えば端末（ＵＥ）１０の在圏セルのセル識別情報を取得して、ＨＰＬＭＮ側で接続されるＰＳＡＰ（Public Safety Answering Point）へのルートを選択する。Ｅ−ＣＳＣＦ４３は、例えばゲートウェイ（Gateway: ＧＷ：例えばＭＧＣＦ（Media Gateway Control Function））４４を介して緊急呼を通報する。

Ｐ−ＣＳＣＦ４１が、端末（ＵＥ）１０の位置情報（P-Access-Network-infoヘッダ）と、Ｒｅｑｕｅｓｔ−ＵＲＩの宛先電話番号とに基づき、ＩＮＶＩＴＥリクエスト３５がＩＭＳ４０でサービス可能な呼ではないと判断した場合、Ｐ−ＣＳＣＦ４１は、ＳＩＰのリダイレクション応答（３８０）を端末（ＵＥ）１０に返す。

ＳＩＰ応答としてリダイレクション応答（３８０）を受信した端末（ＵＥ）１０は、ホーム網（ＨＰＬＭＮ）で提供されるＩＭＳによるＩＭＳ緊急呼の発信とは異なる代替方法で緊急呼接続を行う。例えば、端末（ＵＥ）１０は、ローミング先（ＶＰＬＭＮ）で、緊急呼接続を行い、ＶＰＬＭＮ側の警察／消防等のＰＳＡＰ５０に接続する。

特に制限されるものではないが、代替方法の一例は、端末（ＵＥ）１０が、無線アクセス網をＥ−ＵＴＲＡＮ(Evolved-UMTS(Universal Mobile Telecommunications System) Terrestrial Radio Access Network)からＵＴＲＡＮに切り替えて、緊急呼のダイヤル発信を行うことであってもよい。この場合、端末（ＵＥ）１０は、ＬＴＥのＰＳ（Packet Switched）ドメイン（パケット交換方式）から３G（3rd Generation）又は２G（2nd Generation）のＣＳ（Circuit Switched）ドメイン（回線交換方式）に切り替えた上で、緊急呼のダイヤル発信を行う。

端末（ＵＥ）１０は、ＬＴＥ在圏中、音声通話時に自動的に３Ｇ等のＣＳドメインにある無線アクセス方式に切り替えるＣＳＦＢ（Circuit Switched Fall Back）を用いてもよい。ＥＰＣ３０のＭＭＥ３１は、回線交換網上のＭＳＣ（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ）サーバとＳＧｓインタフェースを介して接続される。ＣＳＦＢはこのＳＧｓインタフェースを介して実現されるようにしてもよい。

図２は、図１を参照して説明した実施形態の動作を説明する図である。図２には、Ｐ−ＣＳＣＦ４１の動作が例示されている。端末（ＵＥ）１０と、ＳＧＷ３２及びＭＭＥ３１とは、図１の基地局（ｅＮＢ）２０を介して通信する。

＜ステップＳ１＞：
ＶＰＬＭＮ側に滞在し、通話モードがＶｏＬＴＥ優先に設定されている端末（ＵＥ）１０は、ＳＩＰ ＩＮＶＩＴＥリクエスト（INVITE (Request URI=110 (=Emergency number in Japan）））３５を、基地局経由で、ＳＧＷ３２、ＧＴＰトンネル３４を介して、ＨＰＬＭＮ側のＰＧＷ３３からＩＭＳ４０のＰ−ＣＳＣＦ４１に送信する。

ＳＩＰメッセージのリクエストラインは、ＳＩＰメソッド、Ｒｅｑｕｅｓｔ−ＵＲＩ（Uniform Resource Indicator）、プロトコルバージョン名（例えばＳＩＰ／２．０）からなる。この場合、ＳＩＰメソッドがＩＮＶＩＴＥ、Ｒｅｑｕｅｓｔ−ＵＲＩがｔｅｌ：１１０である。ＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト）のスタートライン（リクエストライン）の具体例は、以下のようになる。
ＩＮＶＩＴＥ ｔｅｌ：１１０ ＳＩＰ／２．０

＜ステップＳ２＞：
ＳＩＰメッセージ：ＩＮＶＩＴＥリクエスト３５を受信したＰ−ＣＳＣＦ４１は、加入者の位置情報（例えば非特許文献２ 7.2A.4節等に記載のP-Access-Network-Infoヘッダから得られる位置情報）と、ダイヤル番号（Ｒｅｑｕｅｓｔ−ＵＲＩ）とに基づき、緊急呼を認識し（つまり、ローカルサービスである緊急呼を、ローカルにない装置であるホーム網のＰ−ＣＳＣＦ４１で認識する）、以下のいずれを行うかを判断する。
・緊急呼の処理をＨＰＬＭＮ側で継続する（ＩＭＳ４０で緊急呼のサービスが可能）（ステップＳ５）、あるいは、
・応答コード：３８０のＳＩＰ応答を端末（ＵＥ）１０に返す（ステップＳ３）。

＜ステップＳ３＞：
端末（ＵＥ）１０の位置情報と宛先電話番号とが条件に一致した場合（例えばＨＰＬＭＮがオランダからの旅行者（ユーザ）が日本に滞在し、当該旅行者（ユーザ）の端末で、日本において１１０番をかけた場合）、Ｐ−ＣＳＣＦ４１は、応答コード：３８０のＳＩＰ応答３６を、ＰＧＷ３３、ＧＴＰトンネル３４、ＳＧＷ３２、基地局経由で、端末（ＵＥ）１０に返す。ＳＩＰ応答のスタートライン（レスポンスライン）の一例は以下のようになる。

ＳＩＰ／２．０ ３８０ Ａｌｔｅｒｎａｔｉｖｅ Ｓｅｒｖｉｃｅ

ＳＩＰ応答のヘッダのコンタクト（以降のリクエストの送り先を指定：コンタクトヘッダ）に、ｕｒｎ(Uniform Resource Name)：ｓｅｒｖｉｃｅ：ｓｏｓ．ｐｏｌｉｃｅが設定される。また、緊急呼であることを明示するため、ＳＩＰ応答の３ＧＰＰ ＩＭ ＣＮ ｓｕｂｓｙｓｔｅｍ ＸＭＬ ｂｏｄｙ部の＜ｔｙｐｅ＞子要素（以降のリクエストを緊急呼として扱うように指定）に、ｅｍｅｒｇｅｎｃｙが設定される。

このＳＩＰ応答を受信した端末（ＵＥ）１０は、当該ＳＩＰ応答において、コンタクトヘッダに指定された以降のリクエストの送り先（ｕｒｎ：ｓｅｒｖｉｃｅ：ｓｏｓ．ｐｏｌｉｃe等）をＲｅｑｕｅｓｔ−ＵＲＩに設定したＩＮＶＩＴＥリクエストを、緊急呼として再度送信（UE detectable emergency call）する仕組みとなっている。

応答コード：３８０のＳＩＰ応答を受信した端末（ＵＥ）１０は、通常、自動で、以下のリクエストラインのＩＮＶＩＴＥリクエストを、ＩＭＳ４０のＰ−ＣＳＣＦ４１へ送信する。

ＩＮＶＩＴＥ ｕｒｎ：ｓｅｒｖｉｃｅ：ｓｏｓ．ｐｏｌｉｃｅ ＳＩＰ／２．０

しかし、端末（ＵＥ）１０が、上記ＩＮＶＩＴＥリクエストを再送信しても、ＩＭＳ４０のＰ−ＣＳＣＦ４１からは再び、応答コード：３８０のＳＩＰ応答が端末（ＵＥ）１０に返ってくる。

例えば、ローミング先の端末（ＵＥ）１０に対して、ローミング先のＳｅｒｖｉｃｅ ＵＲＮ（例：ｕｒｎ：ｓｅｒｖｉｃｅ：ｓｏｓ．ｐｏｌｉｃｅ）のサービスをＰ−ＣＳＣＦ４１が所属するＩＭＳ４０で取り扱い（ハンドリング）ができない場合に、Ｐ−ＣＳＣＦ４１は、応答コード：３８０のＳＩＰ応答を端末（ＵＥ）１０に送信する。

ＩＭＳ４０で当該サービスをハンドリングできるか否かの情報は、例えばＰ−ＣＳＣＦ４１で保持されてもよいし、外部のデータベース等で保持されてもよい。ＩＭＳ４０で当該サービスをハンドリングできるか否かの情報は、例えば、
・端末のローミング有無、
・ローミング国、
・ローミング地域、
・サービス種別（ｓｏｓ．ｐｏｌｉｃｅ，ｓｏｓ．ｆｉｒｅ等）
のいずれか又はこれらの組合せに応じたハンドリングの可否を示すものであってもよい。ＩＭＳ４０で当該サービスをハンドリングできるか否かの情報は、Ｐ−ＣＳＣＦ４１又は外部データベースに事前に設定されるようにしてもよい。

＜ステップＳ４＞：
本実施形態では、ローミング先の端末（ＵＥ）１０は、応答コード：３８０のＳＩＰ応答３６のコンタクトヘッダに指定された送り先（Ｓｅｒｖｉｃｅ ＵＲＮ）を指定したＩＮＶＩＴＥリクエストの再送信は行わず、ＬＴＥのＰＳ（Packet Switched：パケット交換）ドメインから、例えば３ＧのＣＳ（Circuit Switched：回線交換）ドメインによる音声通話に切り替え、電話番号１１０でＣＳ発呼を行う。この場合、ＬＴＥサービスエリアと３Ｇサービスエリアとが互いにオーバラップしていることが必要である。ローミング先の端末（ＵＥ）は、応答コード：３８０のＳＩＰ応答３６を受信した際に得られる情報（コンタクトヘッダ、３ＧＰＰ ＩＭ ＣＮ ｓｕｂｓｙｓｔｅｍ ＸＭＬ ｂｏｄｙ部の＜ｔｙｐｅ＞子要素等）に応じて、切り替えるドメインと、発呼信号に含まれるパラメータとを制御する構成としてもよい。

図３は、端末（ＵＥ）１０がＶＰＬＭＮのＣＳドメインで緊急呼を発信した場合の動作を説明する図である。図３のステップＳ４は、図２のステップＳ４に相当する。このため、図３のステップＳ４の説明は省略する。以下では、端末（ＵＥ）１０はセルサーチを行って３Ｇの基地局（ＮｏｄｅＢ）を探索できたものとする。

＜ステップＳ５＞：
端末（ＵＥ）１０は、回線接続要求を行う呼設定メッセージＳＥＴＵＰ（Ｃａｌｌｅｄ ｐａｒｔｙ ｎｕｍｂｅｒ ＝１１０）を、基地局ＮｏｄｅＢ／ＲＮＣ(Radio Network Controller）２１を介して、ＰＳＴＮ（Public Switched Telephone Networks）６０のＭＳＣ６１に送信する。図１のＥＰＣ３０のＭＭＥ３１と図３のＭＳＣ６１とは、ＳＧｓインタフェースで接続されていてもよい。呼設定メッセージＳＥＴＵＰは、発番号、着番号（Called party number）の情報要素を含む。ＭＳＣ６１は、移動局である端末（ＵＥ）１０の呼制御機能と端末（ＵＥ）１０の移動に伴う移動管理機能とを備える。

＜ステップＳ６＞：
ＭＳＣ６１は、ＩＳＵＰ（Integrated Services Digital Network User Part）のＩＡＭ（Initial Address Message）をＰＳＡＰ６２に送信する。ＩＡＭは、指定の相手まで回線の接続を要求するメッセージであり、発番号、着番号（Called Party Number）を含む。

図３の上記ステップＳ４からステップＳ５において、応答コード：３８０のＳＩＰ応答３６を受信したローミング先の端末（ＵＥ）１０は、ＣＳドメインによる音声通話に切り替え、電話番号１１０でＣＳ発呼を行う。しかし、ローミング先の端末（ＵＥ）１０は、応答コード：３８０のＳＩＰ応答３６を受信した場合、図３のステップＳ４からステップＳ５では無く、例えば、非特許文献１の７．１章で規定されるHigh Level Procedures for IMS Emergency Servicesを起動し、ＶＰＬＭＮ網のＰＳドメインに切り替えてもよい。その場合、非特許文献１で規定されるＩＰ−ＣＡＮ（IP Connectivity Access Network）、およびＩＭＳは全てＶＰＬＭＮ網内で設定される。

図４は、図２を参照して説明した実施形態の動作を説明する図である。図４には、Ｐ−ＣＳＣＦ４１の図２のステップＳ２（判断：緊急呼がＩＭＳでハンドリング可能か否か）の詳細の一例が示されている。なお、図４のＰＧＷ３３は、図１と同様に基地局（ｅＮＢ）を介して端末（ＵＥ）１０と通信する。

＜ステップＳ１＞
ステップＳ１で端末（ＵＥ）１０は、基地局（ｅＮＢ）経由で、Ｐ−ＣＳＣＦ４１にＳＩＰメッセージ（ＩＮＶＩＴＥ、Ｒｅｑｕｅｓｔ−ＵＲＩ＝１１０）を送信する。このステップＳ１は、図２のステップＳ１と同一であるため説明は省略する。

ＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト、例えばemergency session establishment request）を受信したＰ−ＣＳＣＦ４１は、ＰＣＲＦ３７に連絡してネットワーク側で提供されるユーザ位置情報を取得する。

＜ステップＳ１１＞
ＩＮＶＩＴＥリクエストを受信したＰ−ＣＳＣＦ４１は、ＡＡＲ（AA-Request）コマンドを、ホーム網側のＰＣＲＦ３７に送信する。ＡＡＲでは、アクセスネットワーク情報の要求（access network information request）が指定される。

＜ステップＳ１２＞
ＰＣＲＦ３７は、ＡＡＲコマンドをＰＧＷ３３に送信する。

＜ステップＳ１３、Ｓ１４＞
ＰＧＷ３３はＡＡＲの応答であるＡＡＡ（AA-Answer）コマンドをＰＣＲＦ３７に返す。ＰＣＲＦ３７はＡＡＡコマンドをＰ−ＣＳＣＦ４１に返す。ＡＡＲとＡＡＡのコマンドフォーマット等については、例えば非特許文献２（5.2節）が参照する３ＧＰＰ ＴＳ ２９．２１４（V13.1.0 (2015-03) ）の５．６．１、５．６．２等に記載されている。

＜ステップＳ１５、１６＞
ＰＧＷ３３は、ＰＣＲＦ３７を介してＰ−ＣＳＣＦ４１に、ＲＡＲ（Re-Authorization-Request）を送信する。ＲＡＲには、ネットワーク側で提供されたユーザ位置情報として、
・Ｕｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ ＡＶＰ、
・ＴＷＡＮ（Trusted WLAN Access Network）−Ｉｄｅｎｔｉｆｉｅｒ ＡＶＰ、
・Ｕｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ−Ｔｉｍｅ ＡＶＰ、
・３ＧＰＰ−ＳＧＳＮ（Serving GPRS Gateway Node）−ＭＣＣ（Mobile Country Code）−ＭＮＣ（Mobile Network Code） ＡＶＰ
等が含まれる。

上記のとおり、ＰＣＲＦ３７からのＲＡＲのＵｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ ＡＶＰに、国および地域を特定可能な、端末（ＵＥ）１０の位置情報が含まれる。

なお、ＡＶＰ（Attribute Value Pair）は、端末（ＵＥ）１０の認証、課金管理を行うＲＡＤＩＵＳ（Remote Authentication Dial-In User Service）プロトコルがユーザ情報等を送受信する際に利用する情報の形式である。ＴＷＡＮ−Ｉｄｅｎｔｉｆｉｅｒは信頼できるＷＬＡＮ（Wireless Local Area Network）識別子である。ＭＣＣは、運用地域（国）のコードである。ＭＮＣは、電気通信事業者を識別するためのコード（電気通信番号）である。

＜ステップＳ１７、Ｓ１８＞
Ｐ−ＣＳＣＦ４１は、ＲＡＲの応答であるＲＡＡをＰＣＲＦ３７を介してＰＧＷ３３に返す。ＲＡＲとＲＡＡとのコマンドフォーマット等については、例えば非特許文献２（5.2.1節）が参照する３ＧＰＰ ＴＳ ２９．２１４（V13.1.0 (2015-03) ）の５．６．３、５．６．４等に記載される。

＜ステップＳ１９＞
Ｐ−ＣＳＣＦ４１は、ＰＣＲＦ３７からのＲＡＡのＵｓｅｒ−Ｌｏｃａｔｉｏｎ−Ｉｎｆｏ ＡＶＰから、端末（ＵＥ）１０の位置情報を取得する。例えば、端末（ＵＥ）１０のＭＣＣとＭＮＣを取得する。なお、Ｐ−ＣＳＣＦ４１は、ＨＳＳ等、ＩＭＳ４０に配置される他の装置に問い合わせて端末（ＵＥ）１０の位置情報を取得してもよい。

＜ステップＳ２０＞
Ｐ−ＣＳＣＦ４１は、ＤＢ ｅｎｔｉｔｙ（データベースエンティティ）４５に対して、端末（ＵＥ）１０の位置情報とダイヤル番号（Ｒｅｑｕｅｓｔ−ＵＲＩ）とに対応したサービス種別、サービス提供可否を取得するための問い合わせ（Ｑｕｅｒｙ）を発行してもよい。

ＤＢ ｅｎｔｉｔｙ４５は、例えば、
・ホーム網（ＨＰＬＭＮ）の事業者が提携している、ローミング先の事業者が管轄する位置情報（例えば国、地域）、
・当該位置における緊急特番、
・緊急特番に対応するサービス種別（Ｓｅｒｖｉｃｅ ＵＲＮ）、および、
・該当サービスの提供可否の対応、
等の一欄を記憶保持する構成としてもよい。なお、緊急特番等に対応するサービス種別（Ｓｅｒｖｉｃｅ ＵＲＮ）は、例えばＩＥＴＦ ＲＦＣ ５０３１で規定されている。

ＤＢ ｅｎｔｉｔｙ４５は、さらに、該当サービスの提供が不可の場合に、端末（ＵＥ）１０が別のドメインを選択することに備えて、端末（ＵＥ）１０が選ぶドメインの候補を記憶保持していてもよい。

また、ＤＢ ｅｎｔｉｔｙ４５は、Ｐ−ＣＳＣＦ４１の装置内部に配置されてもよいし、図４で例示されるように外部の別装置に配置されてもよい。Ｐ−ＣＳＣＦ４１が外部の別装置に配置される場合、問い合わせ（Ｑｕｅｒｙ）と回答（Ａｎｓｗｅｒ）とがＳＩＰプロトコルで実現されてもよい。例えば、Ｐ−ＣＳＣＦ４１は、ＤＢ ｅｎｔｉｔｙ４５に対してＳＩＰメッセージのＩＮＶＩＴＥリクエストを用いて問い合わせを行うようにしてもよい。ＤＢ ｅｎｔｉｔｙ４５からの回答（Ａｎｓｗｅｒ）に、応答コード：３８０又は３００（Multiple Choices）等が用いられてもよい。

ＤＢ ｅｎｔｉｔｙ４５は、まず、Ｐ−ＣＳＣＦ４１からの問い合わせ（Ｑｕｅｒｙ）に含まれる端末（ＵＥ）１０の位置情報とダイヤル番号（Ｒｅｑｕｅｓｔ−ＵＲＩ）とに対応するサービス種別（Ｓｅｒｖｉｃｅ ＵＲＮ）を出力する。

次に、ＤＢ ｅｎｔｉｔｙ４５は、端末（ＵＥ）１０の位置情報とサービス種別（Ｓｅｒｖｉｃｅ ＵＲＮ）とに対するサービス提供可否を出力する。

例えば、日本のＨＰＬＭＮにあるＩＭＳ４０で、フランスのＶＰＬＭＮにある端末（ＵＥ）１０に対して、フランスの警察の緊急呼サービスを提供できないことと、フランスの消防の緊急呼サービスを提供できることとを、出力する構成とする場合、ＤＢ ｅｎｔｉｔｙ４５に保持される情報の一例は、以下の表１のようになる。

また、例えば、表１に加えて、サービス提供が不可だった場合に、端末（ＵＥ）１０がＶＰＬＭＮのＰＳドメインまたはＣＳドメインを選択するように、ドメインの候補を通知する構成とする場合、ＤＢ ｅｎｔｉｔｙ４５に保持される情報の一例は、以下の表２のようになる。

＜ステップＳ２１＞
Ｐ−ＣＳＣＦ４１は、ＤＢ ｅｎｔｉｔｙ４５からの回答（Ａｎｓｅｒ）を受信する。回答（Ａｎｓｅｒ）には、サービス識別子（Ｓｅｒｖｉｃｅ ＵＲＮ）と、サービス提供可否と、（さらに必要であれば）端末（ＵＥ）１０が選ぶドメインの候補と、が含まれる。

＜ステップＳ２２＞
Ｐ−ＣＳＣＦ４１は、ＤＢ ｅｎｔｉｔｙ４５からの回答（Ａｎｓｅｒ）に基づき、ＩＭＳ４０で当該緊急呼サービスをハンドリングできるか否かが分かる。

＜ステップＳ３＞
このステップＳ３は、図２のステップＳ３と同一である。Ｐ−ＣＳＣＦ４１は、緊急呼の呼処理（ハンドリング）が不可の場合、応答コード：３８０のＳＩＰ応答のヘッダのコンタクトに、ステップＳ２１で回答されたＳｅｒｖｉｃｅ ＵＲＮ（ｕｒｎ：ｓｅｒｖｉｃｅ：ｓｏｓ．ｐｏｌｉｃｅ）を設定したＳＩＰ応答を、基地局経由で、端末（ＵＥ）１０に返す。Ｐ−ＣＳＣＦ４１は、（さらに必要であれば）端末（ＵＥ）１０が選ぶべきドメインの候補のコードを、ＳＩＰ応答に含める。候補のコードは、「ＨＰＬＭＮドメイン」等、複数のドメインをまとめた単位であってもよいし、端末（ＵＥ）１０が選ぶべきではないドメインを指定したものでもよい。例えば、ＨＰＬＭＮ側のドメインでは緊急呼の発信が不可であることを通知するコードでもよい。

このステップＳ３で送信されたＳＩＰ応答メッセージを受信した端末（ＵＥ）１０は、図２、図３のステップＳ４の処理（ＣＳドメインへ切り替えて緊急呼の発信）を実行する。

ステップＳ３において、ＳＩＰ応答に、端末（ＵＥ）１０が選ぶドメインの候補が指定されている場合には、端末（ＵＥ）１０は、当該指定されたドメインへ切り替えて緊急呼の発信を実行するようにしてもよい。

ＤＢ ｅｎｔｉｔｙ４５が保持するデータベース情報の別例を以下に示す。Ｐ−ＣＳＣＦ４１は、図４のステップＳ２０のＱｕｅｒｙで、位置情報を指定せず、ダイヤル番号（Ｃａｌｌｅｄ ｎｕｍｂｅｒ）だけをＤＢ ｅｎｔｉｔｙ４５に入力してもよい。この場合、ＤＢ ｅｎｔｉｔｙ４５は、国情報とＳｅｒｖｉｃｅ ＵＲＮとのリストをＰ−ＣＳＣＦ４１に回答する。Ｐ−ＣＳＣＦ４１は、端末（ＵＥ）１０の位置情報に応じたＳｅｒｖｉｃｅ ＵＲＮを受け取ったリストから選択する。

上記した実施形態では、端末（ＵＥ）１０は、通話モードがＶｏＬＴＥに設定可能であり、データローミングがオンに設定可能であり、且つ、ＶＰＬＭＮのＣＳドメインに切り替えが可能なＬＴＥ／３Ｇ対応端末（ＵＥ）１０であることを前提としている。端末（ＵＥ）１０はスマートフォンやタブレット端末等であってもよい。

なお、本実施形態では、前述したように、
１）図２のステップＳ１で、端末（ＵＥ）１０がＩＮＶＩＴＥリクエスト３５を送信すると、端末（ＵＥ）１０は、Ｐ−ＣＳＣＦ４１から応答コード：３８０のＳＩＰ応答３６を受ける。

２）端末（ＵＥ）１０が応答コード：３８０のＳＩＰ応答３６を受けると、前述したように、Ｒｅｑｕｅｓｔ−ＵＲＩにＳｅｒｖｉｃｅ ＵＲＮを設定したＳＩＰのＩＮＶＩＴＥリクエストをドメインを切り替えることなく、再びＰＳ（Packet Switched）網に送信する。その結果、端末（ＵＥ）１０は、Ｐ−ＣＳＣＦ４１から、再び、応答コード：３８０のＳＩＰ応答を受信する。これは、前述したように、Ｐ−ＣＳＣＦ４１が、ＩＭＳで当該サービスのハンドリングが不可であると判断されるためである。

３）この２回目の応答コード３８０を受信した端末（ＵＥ）１０は、図２、図３のステップＳ４において、ＣＳドメインに切り替え、緊急呼をダイヤル発信し、ＰＳＡＰ６２（図３）への呼接続の成功となる。本実施形態では、好ましくは、上記２）のステップを省略する。

例えば、端末（ＵＥ）１０が、現在Ｓ８ＨＲのローミングの状況下であることを認識し、緊急呼をダイヤル発信したことを認識している場合、上記ステップ２）を省略する。すなわち、図２に示したように、端末（ＵＥ）１０がステップＳ３でＰ−ＣＳＣＦ４１から応答コード：３８０のＳＩＰ応答を受けると、端末（ＵＥ）１０はステップＳ４のＣＳドメインへの切り替えを行う。

あるいは、Ｐ−ＣＳＣＦ４１が、ステップＳ３で端末（ＵＥ）１０に送信するＳＩＰ応答に、ＶｏＬＴＥによるＶＰＬＭＮ側からＨＰＬＭＮ側（パケット網）への緊急呼の発信が不可であることを通知するコードをＳＩＰ応答に設定し、端末（ＵＥ）１０でこのコードを検知すると、上記２）のステップを省略するようにしてもよい。

図５は、図１のＰ−ＣＳＣＦ４１の構成例を例示した図である。図５を参照すると、Ｐ−ＣＳＣＦ４１は、呼受信部４１０と、サービス特定部４１１と、判定処理部４１２と、位置情報取得部４１３と、緊急呼処理部４１４と、応答情報生成部４１５と、応答情報送信部４１６と、を備えている。

呼受信部４１０は、図１の端末（ＵＥ）１０からＳ８ＨＲ（Ｓ８ ＧＴＰ トンネル）を介して転送されたＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト）を受信し、サービス特定部４１１に送信する。

サービス特定部４１１は、ＳＩＰメッセージ（ＩＮＶＩＴＥリクエスト）のＲｅｑｕｅｓｔ−ＵＲＩ情報に基づき、呼のサービス（例えば緊急サービスであるか）を特定する。サービス特定部４１１は、緊急サービスの場合、ＩＮＶＩＴＥリクエストを判定処理部４１２に転送する。

ＩＮＶＩＴＥリクエストのＲｅｑｕｅｓｔ−ＵＲＩ情報に着番号が指定されている場合、判定処理部４１２は、位置情報取得部４１３に端末の位置情報を取得するよう依頼する。位置情報取得部４１３は、前述したようにＰＣＲＦ３７にＡＡ要求を送信し、ＰＷＧ３３から、端末（ＵＥ）１０の位置情報を取得する（図４のステップＳ１１〜Ｓ１８）。位置情報取得部４１３は、端末（ＵＥ）１０側から送信される端末（ＵＥ）１０の位置情報等を使用せず、ＰＣＲＦ３７に位置情報の取得を依頼しネットワーク側で管理する加入者位置情報を取得している。これは、端末（ＵＥ）１０から送信される位置情報は必ずしも信頼できるとは限らないためである。

判定処理部４１２は、端末（ＵＥ）１０の位置情報と緊急呼の着番号（入力された宛先電話番号（着番号））とに基づき、ＩＭＳ４０で当該緊急呼を処理（ハンドリング）することは不可であると判断した場合（図２ステップＳ２、図４のステップＳ２２）、応答情報生成部４１５に応答情報の生成を依頼する。

応答情報生成部４１５は、図４のステップＳ２０の問い合わせを行い、図４のステップＳ２１でＤＢ ｅｎｔｉｔｙ４５から取得した回答に基づき、応答コード：３８０のＳＩＰ応答のコンタクトに設定するリダイレクト先情報（ＩＮＶＩＴＥリクエストの送り先）を作成する。応答情報生成部４１５は、端末（ＵＥ）１０が接続可能なドメインを通知する情報を生成してもよい。応答情報生成部４１５は、端末（ＵＥ）１０が接続不可のドメインを通知する情報を生成してもよい。

応答情報送信部４１６は、応答コード：３８０のＳＩＰ応答をホーム側のＰＧＷ３３を介してＶＰＬＭＮ側の端末（ＵＥ）１０に送信する。応答情報送信部４１６は、端末（ＵＥ）１０が接続可能なドメインを通知する情報、及び／又は、端末（ＵＥ）１０が接続不可のドメインを通知する情報を、端末（ＵＥ）１０に送信するようにしてもよい。応答情報送信部４１６からの応答は、Ｐ−ＣＳＣＦ４１から、例えばＩＭＳ等ＰＳ網（Packet Switched Network）への接続不可、あるいは、Ｗｉ−Ｆｉ（Wireless Fidelity：登録商標）等無線ＬＡＮ（Local Area Network）経由でＰＳ網への接続不可を、端末（ＵＥ）１０に通知するものであってもよい。図５において、呼受信部４１０と、サービス特定部４１１と、判定処理部４１２と、位置情報取得部４１３とは、端末（ＵＥ）１０が発した呼の要求を受けると、端末（ＵＥ）１０の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するかを判断する第１の手段（ユニット）に対応し、応答情報生成部４１５と応答情報送信部４１６とは、第１の手段（ユニット）での判断結果を含む応答を端末（ＵＥ）１０に通知する第２の手段（ユニット）に対応する。

なお、サービス特定部４１１、判定処理部４１２、位置情報取得部４１３、緊急呼処理部４１４、応答情報生成部４１５、応答情報送信部４１６の少なくとも一部は、Ｐ−ＣＳＣＦ４１を構成するコンピュータ上で動作するプログラムで実現してもよいことは勿論である。

図６は、図１乃至図４を参照して説明した端末（ＵＥ）１０の一実施形態の構成例を例示した図である。

図６を参照すると、端末（ＵＥ）１０は、発呼、着呼の呼制御を行う呼制御部１０１と、ＬＴＥ通信を行うＬＴＥ通信モジュール１０２と、ＵＴＲＡＮを介して通信を行う３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）通信モジュール１０３と、緊急呼の再発信を制御する再発信制御部１０４と、を備えている。

再発信制御部１０４は、ＬＴＥ通信モジュール１０２から送信された緊急呼（ＳＩＰメッセージのＩＮＶＩＴＥリクエスト）に対するＰ−ＣＳＣＦからのＳＩＰ応答が応答コード：３８０を含む応答であるか判定する判定部１０４１と、応答コード：３８０のＳＩＰ応答である場合、ＳＩＰ応答のコンタクトで指定されている呼のリダイレクト先（送信先）を抽出する送信先抽出部１０４２と、リダイレクト先（送信先）が端末（ＵＥ）１０のローミング先であるＶＰＬＭＮである場合、当該リダイレクト先（送信先）に緊急呼を再発信する再発信部１０４３と、を備えている。ＳＩＰ応答のコンタクトで指定されているリダイレクト先がＣＳドメインである場合、再発信部１０４３による緊急呼の再発信先は、３Ｇ（3rd Generation）通信モジュール１０３となる。３Ｇ通信モジュール１０３は呼を再発信する。ＳＩＰ応答のコンタクトで指定されているリダイレクト先がＰＳドメインであり、当該ＰＳドメインが緊急呼をサポートする場合、再発信部１０４３による緊急呼の再発信先は、ＬＴＥ通信モジュール１０２となる。ＬＴＥ通信モジュール１０２は、呼（ＩＮＶＩＴＥリクエスト）を再発信する。再発信制御部１０４の処理、及び他の各部１０２〜１０３の少なくとも一部は、端末（ＵＥ）１０のコンピュータ上で動作するプログラム（コンピュータで読み出し可能な記録媒体に記録される）で実現してもよいことは勿論である。

端末（ＵＥ）１０は、３Ｇ通信モジュール１０３の代わりに、あるいは、３Ｇ通信モジュール１０３に加えてＷｉ−Ｆｉ等無線ＬＡＮ通信モジュールを備え、緊急呼をＷｉ−Ｆｉ等無線ＬＡＮ通信モジュールから送信（あるいは再送信）するようにしてもよい。

Ｐ−ＣＳＣＦ４１から応答コード：３８０の応答で指示するリダイレクト先（端末（ＵＥ）１０が接続する可能性がある接続先）として例えば、以下が挙げられる。
・ＶＰＬＭＮのＣＳドメイン（２Ｇ／３Ｇ： ＶＰＬＭＮがサポートする場合）、
・ＶＰＬＭＮのＰＳドメイン（ＬＴＥを介したＶＰＬＭＮ内のＰ−ＣＳＣＦ：ＶＰＬＭＮがサポートする場合）
・ＶＰＬＭＮのＰＳドメイン（Ｗｉ−Ｆｉを介したＶＰＬＭＮ内のＰ−ＣＳＣＦ：ＶＰＬＭＮがサポートする場合）
・ＨＰＬＭＮのＰＳドメイン（ＬＴＥを介したＨＰＬＭＮ内のＰ−ＣＳＣＦ）、
・ＨＰＬＭＮのＰＳドメイン（Ｗｉ−Ｆｉを介したＨＰＬＭＮ内のＰ−ＣＳＣＦ）、
・端末で選択されるＶＰＬＭＮ内の任意ドメイン、
・端末で選択される任意のドメイン。

図７は、図１乃至図４を参照して説明した端末（ＵＥ）１０の別の実施形態の構成例を例示した図である。この実施形態では、図６の構成とは異なり、端末（ＵＥ）１０がＰ−ＣＳＣＦ４１から応答コード：３８０のリダイレクト応答を受けた場合、端末（ＵＥ）１０はリダイレクト応答で指定された送信先への発信は行わず、ＬＴＥからＣＳドメインへの接続に切り替える。

図７を参照すると、端末（ＵＥ）１０は、発呼、着呼の呼制御を行う呼制御部１０１と、ＬＴＥ通信を行うＬＴＥ通信モジュール１０２と、ＵＴＲＡＮを介して通信を行う３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）通信モジュール１０３と、緊急呼の再発信を制御する再発信制御部１０４と、を備えている。端末（ＵＥ）１０は、ＬＴＥ通信モジュール１０２、３Ｇ通信モジュール１０３に加えて、Ｗｉ−Ｆｉ（登録商標）等無線ＬＡＮ通信モジュールをさらに備え、緊急呼をＷｉ−Ｆｉ等無線ＬＡＮ通信モジュールから送信するようにしてもよい。

再発信制御部１０４は、ＬＴＥ通信モジュール１０２からダイヤル発信された緊急呼に対する応答が応答コード：３８０であるか判定する判定部１０４１と、応答コード：３８０である場合、ＣＳドメインへの切り替えを行うＣＳドメイン切替部１０４４と、を備えている。再発信制御部１０４の処理、及び他の各部１０２〜１０３の少なくとも一部は、端末（ＵＥ）１０のコンピュータ上で動作するプログラム（コンピュータで読み出し可能な記録媒体）で実現してもよいことは勿論である。

再発信制御部１０４は、例えば、端末（ＵＥ）１０が、現在Ｓ８ＨＲの状況下であることを認識し、ダイヤル発信し、応答コード：３８０のＳＩＰ応答を受けると、ＬＴＥ通信モジュール１０２からＣＳドメインへの切り替えを行うようにしてもよい。

Ｐ−ＣＳＣＦ４１からの応答コード：３８０のＳＩＰ応答に、ＶＰＬＭＮ側からＨＰＬＭＮ側（パケット網）への緊急呼の発信が不可であることを通知する情報が設定されている場合、再発信制御部１０４は、ＬＴＥ通信モジュール１０２からＣＳドメインに切り替えるようにしてもよい。あるいは、ＣＳドメインに限らず、ＶＰＬＭＮ内の他の任意のドメインに切り替えるようにしてもよい。

なお、上記実施形態では海外ローミング先から端末のホーム網へ発信された緊急呼サービスについて説明したが、他に、
・天気予報、
・時報、
・番号案内
等の各種サービスに適用することも可能である。

すなわち、上記のとおり、緊急セッション確立要求はホーム網（Ｓ８ＨＲローミング）に位置するＰ−ＣＳＣＦ４１にルーティングされる。ホーム網は、当該セッションが緊急サービスであるか検出し、端末（ＵＥ）１０に対する応答として、端末（ＵＥ）１０が在圏する訪問先ネットワーク（Ｖｉｓｉｔｅｄ Ｎｅｔｗｏｒｋ）（例えばＣＳドメイン）で緊急セッションを開始すべきことを指示する。ホーム網（ＨＰＬＭＮ）に位置するＰ−ＣＳＣＦ４１は、緊急呼（緊急セッション）のみならず、非緊急のローカルサービス（例えば天気予報、時報通知、その他）に対するセッション開始要求を拒否するように構成してもよい。Ｐ−ＣＳＣＦ４１と端末（ＵＥ）１０との手順等については、上記実施形態で説明したものに制限されるものではなく、これ以外の各種手法を適法してもよいことは勿論である。

Ｐ−ＣＳＣＦ４１は、緊急呼（緊急セッション）であることを示すセッション開始要求を拒否してもよい。Ｐ−ＣＳＣＦ４１は、オプションとして、端末（ＵＥ）１０が在圏する訪問先ネットワーク（Ｖｉｓｉｔｅｄ Ｎｅｔｗｏｒｋ： ＶＰＬＭＮ）のドメイン（ＣＳドメイン、ＬＴＥアクセスを介してのＰＳドメイン、及び／又は、Ｗｉ―Ｆｉ（登録商標）アクセスその他を介してのＰＳドメイン、等）を介して、緊急呼（緊急セッション）を開始すべきことを指示するように構成してもよい。

端末（ＵＥ）１０は、Ｐ−ＣＳＣＦ４１からのセッション拒否を受信した場合、Ｐ−ＣＳＣＦ４１からの指示（端末は訪問先ネットワーク（Ｖｉｓｉｔｅｄ Ｎｅｔｗｏｒｋ： ＶＰＬＭＮ）で緊急セッションを開始すべきである）が存在する場合、当該指示にしたがって、緊急呼に対するドメインの選択を行うように構成してもよい。すなわち、端末（ＵＥ）１０は、Ｐ−ＣＳＣＦ４１からの該指示を受けると、端末（ＵＥ）１０が在圏する訪問先ネットワーク（Ｖｉｓｉｔｅｄ Ｎｅｔｗｏｒｋ）のドメイン（ＣＳドメイン、ＬＴＥアクセスを介してのＰＳドメイン、及び／又は、Ｗｉ−Ｆｉ（登録商標）アクセス、その他）を選択するように構成してもよい。

ローミング（Ｓ８ＨＲローミング）している端末（ＵＥ）１０に対するＨＰＬＭＮ内のＰ−ＣＳＣＦ４１が端末からの緊急呼のセッション開始要求の継続を認可する構成等については、各種手法が適法される。

上記実施形態は、例えば以下のようにも付記される（だたし、以下に制限されない）。

（付記１）
端末からの要求を、前記端末の位置に基づき、前記要求がローカルサービスであることを検出する手段を備えた、ことを特徴とする通信装置。

（付記２）
前記ローカルサービスが緊急サービスである、ことを特徴とする付記１記載の通信装置。

（付記３）
前記端末と異なるネットワークに配置されており、前記端末とはトンネルを介して接続されていることを特徴とする付記１又は２に記載の通信装置。

（付記４）
前記要求は、前記端末ではローカルサービスであることを検出できないことを特徴とする付記１乃至３のいずれか一に記載の通信装置。

（付記５）
前記要求を提供するために前記要求を受け付けるか拒否するかを判断し、判断結果を含む応答を、前記端末に通知する手段をさらに備えた、ことを特徴とする付記１乃至４のいずれか一に記載の通信装置。

（付記６）
端末が発した呼の要求を受けると、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するか判断し、判断結果を含む応答を、前記端末に通知する手段を備えた、ことを特徴とする通信装置。

（付記７）
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答を返す手段を備えた、ことを特徴とする付記６記載の通信装置。

（付記８）
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスの提供を受けるために接続可能な又は接続不可能なドメインを指定したリダイレクト応答を返す手段を備えた、ことを特徴とする付記７記載の通信装置。

（付記９）
前記通信装置は、前記端末がローミング先からＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで発信した前記要求を受ける、ホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の呼制御を行う装置からなる、ことを特徴とする付記６乃至８のいずれか一に記載の通信装置。

（付記１０）
前記ホーム網側のＩＭＳが接続する前記ホーム網側のパケットコア網の管理ノード及びゲートウェイから前記端末の位置情報を取得する手段を備えた、ことを特徴とする付記９記載の通信装置。

（付記１１）
前記ゲートウェイは、前記ホーム網側のＩＭＳに接続し、前記端末に対してＩＰアドレスを割り当てるＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ） Ｇａｔｅｗａｙ）であり、前記管理ノードは、ポリシ及び課金ルールを管理するＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ）である、ことを特徴とする付記１０記載の通信装置。

（付記１２）
前記要求のサービスは緊急呼を含む、ことを特徴とする付記６乃至１１のいずれか一に記載の通信装置。

（付記１３）
端末が発した呼の要求を受け、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するか判断する呼制御装置にローミング接続される端末であって、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記端末側で選択する別のドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする端末。

（付記１４）
前記端末は、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスと、前記通信装置で特定した前記要求のサービスの提供を受けるために接続可能又は接続不可能なドメインと、を指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記応答に基づき接続可能なドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする付記１３記載の端末。

（付記１５）
ローミング先からホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の前記呼制御装置へＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで前記要求を発信し、
前記呼制御装置から前記拒否を通知する応答を受信した場合、
前記呼制御装置へ接続するための現在のドメインから、ローミング先のＣＳ（回線交換）ドメイン又はＰＳ（パケット交換）ドメインへ切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする付記１３又は１４に記載の端末。

（付記１６）
前記要求のサービスは緊急呼を含む、ことを特徴とする付記１３乃至１５のいずれか一に記載の端末。

（付記１７）
端末と、
呼制御装置と、
を備え、
前記呼制御装置は、
前記端末が発した呼の要求を受けると、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するか判断し、判断結果を含む応答を、前記端末に通知する手段を備えた、ことを特徴とする通信システム。

（付記１８）
前記呼制御装置は、
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答を返す手段を備えた、ことを特徴とする付記１７記載の通信システム。

（付記１９）
前記呼制御装置は、
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信システムで特定した前記要求のサービスの提供を受けるために接続可能な、又は接続不可能なドメインを指定したリダイレクト応答を返す手段を備えた、ことを特徴とする付記１８記載の通信システム。

（付記２０）
前記呼制御装置は、
前記端末がローミング先からＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで発信した前記要求を受ける、ホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の呼制御装置からなる、ことを特徴とする付記１７乃至１９のいずれか一に記載の通信システム。

（付記２１）
前記呼制御装置は、
前記ホーム網側のＩＭＳが接続する前記ホーム網側のパケットコア網の管理ノード及びゲートウェイから前記端末の位置情報を取得する手段を備えた、ことを特徴とする付記２０記載の通信システム。

（付記２２）
前記ゲートウェイは、前記ホーム網側のＩＭＳに接続し、前記端末に対してＩＰアドレスを割り当てるＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ） Ｇａｔｅｗａｙ）であり、前記管理ノードは、ポリシ及び課金ルールを管理するＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ）である、ことを特徴とする付記２１記載の通信システム。

（付記２３）
前記端末は、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記端末側で選択する別のドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする付記１７乃至２２のいずれか一に記載の通信システム。

（付記２４）
前記端末は、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスと、前記通信装置で特定した前記要求のサービスの提供を受けるために接続可能又は接続不可能なドメインと、を指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記応答に基づき接続可能なドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする付記１７乃至２３のいずれか一に記載の通信システム。

（付記２５）
前記端末は、
ローミング先からホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の前記呼制御装置へＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで前記要求を発信し、
ホーム網側の前記呼制御装置から前記拒否を通知する応答を受信した場合、
前記呼制御装置へ接続するための現在のドメインから、ローミング先のＣＳ（回線交換）ドメイン又はＰＳ（パケット交換）ドメインへ切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する手段を備えた、ことを特徴とする付記１７乃至２４のいずれか一に記載の通信システム。

（付記２６）
前記要求のサービスは緊急呼を含む、ことを特徴とする付記１７乃至２５のいずれか一に記載の通信システム。

（付記２７）
端末が発した呼の要求を受ける呼制御装置では、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するか判断し、判断結果を含む応答を、前記端末に通知する、ことを特徴とする通信方法。

（付記２８）
前記呼制御装置は、
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答を返す、ことを特徴とする付記２７記載の通信方法。

（付記２９）
前記呼制御装置は、
前記拒否を通知する応答を行う場合、前記端末に対して、前記要求のリダイレクト先情報として、前記通信システムで特定した前記要求のサービスの提供を受けるために接続可能な、又は接続不可能なドメインを指定したリダイレクト応答を返す、ことを特徴とする付記２７記載の通信方法。

（付記３０）
前記呼制御装置は、前記端末がローミング先からＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで発信した前記要求を受ける、ホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の呼制御装置からなる、ことを特徴とする付記２７乃至２９のいずれか一に記載の通信方法。

（付記３１）
前記呼制御装置は、
前記ホーム網側のＩＭＳが接続する前記ホーム網側のパケットコア網の管理ノード及びゲートウェイから前記端末の位置情報を取得する、ことを特徴とする付記３０記載の通信方法。

（付記３２）
前記ゲートウェイは、前記ホーム網側のＩＭＳに接続し、前記端末に対してＩＰアドレスを割り当てるＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ） Ｇａｔｅｗａｙ）であり、前記管理ノードは、ポリシ及び課金ルールを管理するＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅ Ｆｕｎｃｔｉｏｎ）である、ことを特徴とする付記３１記載の通信方法。

（付記３３）
前記端末は、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記端末側で選択する別のドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する、ことを特徴とする付記２７乃至３２のいずれか一に記載の通信方法。

（付記３４）
前記端末は、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスと、前記通信装置で特定した前記要求のサービスの提供を受けるために接続可能又は接続不可能なドメインと、を指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記応答に基づき接続可能なドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する、ことを特徴とする付記２７乃至３３のいずれか一に記載の通信方法。

（付記３５）
前記端末は、
ローミング先からホーム網側のＩＭＳ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ） Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）の前記呼制御装置へＶｏＬＴＥ（Ｖｏｃｅ ｏｖｅｒ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））の通話モードで前記要求を発信し、
ホーム網側の前記呼制御装置から前記拒否を通知する応答を受信した場合、
前記呼制御装置へ接続するための現在のドメインから、ローミング先のＣＳ（回線交換）ドメイン又はＰＳ（パケット交換）ドメインへ切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する、ことを特徴とする付記２７乃至３４のいずれか一に記載の通信方法。

（付記３６）
前記要求のサービスは緊急呼を含む、ことを特徴とする付記２７乃至３５のいずれか一に記載の通信方法。

（付記３７）
端末が発した呼の要求を受けると、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記緊急呼を受け付けるか拒否するか判断し、判断結果を含む応答を前記端末に通知する処理を、呼制御装置を構成するコンピュータに実行させるプログラム。

（付記３８）
端末が発した呼の要求を受け、前記端末の位置及び前記要求の宛先電話番号に基づき、前記要求のサービスを特定し、且つ、前記要求のサービスを提供するために前記要求を受け付けるか拒否するか判断する呼制御装置にローミング接続される端末であって、
前記呼制御装置から前記拒否を通知する応答を受け、且つ、
前記応答が、前記要求のリダイレクト先情報として、前記通信装置で特定した前記要求のサービスを指定したリダイレクト応答である場合、
前記呼制御装置へ接続する現在のドメインから、前記端末側で選択する別のドメインに切り替えて、前記要求のサービスの提供を受けるための呼の要求を発信する処理を、前記端末を構成するコンピュータに実行させるプログラム。

なお、上記非特許文献１、２、３の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ乃至選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１０ 端末（ＵＥ）
２０ 基地局（ｅＮＢ）
２１ ＲＮＣ／ＮｏｄｅＢ
３０ ＥＰＣ
３１ ＭＭＥ
３２ ＳＧＷ
３３ ＰＧＷ
３４ Ｓ８ ＧＴＰ トンネル
３５ ＳＩＰ ＩＮＶＩＴＥリクエスト
３６ ＳＩＰ応答（リダイレクト応答）
３７ ＰＣＲＦ
４０ ＩＭＳ
４１ Ｐ−ＣＳＣＦ
４２ Ｉ−ＣＳＣＦ
４３ Ｅ−ＣＳＣＦ
４４ ゲートウェイ（ＧＷ）
４５ ＤＢ Ｅｎｔｉｔｙ
５０ ＰＳＡＰ（警察／消防署）
６０ ＰＳＴＮ
６１ ＭＳＣ
６２ ＰＳＡＰ
１０１ 呼制御部
１０２ ＬＴＥ通信モジュール
１０３ ３Ｇ通信モジュール
１０４ 再発信制御部
４１０ 呼受信部
４１１ サービス特定部
４１２ 判定処理部
４１３ 位置情報取得部
４１４ 緊急呼処理部
４１５ 応答情報生成部
４１６ 応答情報送信部
１０４１ 判定部
１０４２ 送信先抽出部
１０４３ 再発信部
１０４４ ＣＳドメイン切替部

Claims (21)

1. 端末の位置情報を取得する位置情報取得部と、
   前記端末が発した呼の要求を受ける受信部と、
   前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定するサービス特定部と、
   前記要求のサービスを提供できない場合、応答を前記端末に送信する送信部と、
   を備える、ことを特徴とする通信装置。
2. 前記応答に、前記要求のサービスに関する情報が含まれる、ことを特徴とする請求項１記載の通信装置。
3. 前記応答に、前記要求のサービスを提供可能又は提供不可能なドメインを指定した情報が含まれる、ことを特徴とする請求項２記載の通信装置。
4. 前記通信装置は、前記端末がローミング先からＶｏＬＴＥ（Voice over LTE(Long Term Evolution））の通話モードで発信した前記要求を受ける、ホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳ（IP(Internet Protocol) Multimedia Subsystem）の呼制御を行う装置からなる、ことを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記位置情報取得部は、前記ホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳが接続する前記ホーム網側のＰＳ（パケット交換）ドメインに属するパケットコア網の管理ノード及び／又はゲートウェイから前記端末の位置情報を取得する、ことを特徴とする請求項４記載の通信装置。
6. 前記ゲートウェイは、前記端末に対してＩＰアドレスを割り当てるＰＧＷ（PDN(Packet Data Network) Gateway）であり、
   前記管理ノードは、ポリシ及び課金ルールを管理するＰＣＲＦ（Policy and Charging Rule Function）である、ことを特徴とする請求項５記載の通信装置。
7. 前記要求のサービスは緊急呼を含む、ことを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 呼の要求を第一の通信装置に送信する送信部と、
   前記第一の通信装置から、前記要求が受け付けられないことと前記通信装置で特定された前記要求のサービスとを示す情報を含む応答を受信する受信部と、
   前記応答に含まれる前記情報に基づいて、前記第一の通信装置が属するドメイン以外のドメインに属する第二の通信装置を選択し、前記要求のサービスの提供を受けるための呼の要求を前記第二の通信装置へ送信する再送信部と、
   を備える、ことを特徴とする端末。
9. 前記応答に、前記要求のサービスを提供可能又は提供不可能なドメインを指定した情報がさらに含まれる、ことを特徴とする請求項８記載の端末。
10. 前記送信部は、
    ローミング先からホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳ（IP(Internet Protocol) Multimedia Subsystem）の前記第一の通信装置へＶｏＬＴＥ（Voice over LTE(Long Term Evolution））の通話モードで前記要求を送信し、
    前記再送信部は、
    ローミング先のＣＳ（回線交換）ドメインに属する第二の通信装置を選択し、前記要求のサービスの提供を受けるための呼の要求を前記第二の通信装置へ送信する、ことを特徴とする請求項８又は９に記載の端末。
11. 前記要求のサービスは緊急呼を含む、ことを特徴とする請求項８乃至１０のいずれか１項に記載の端末。
12. 通信装置が、端末の位置情報を取得し、前記端末が発する呼の要求を受け、前記端末の位置情報及び前記要求の宛先電話番号に基づいて前記要求のサービスを特定し、
    前記位置情報に対して前記サービスを提供できない場合、応答を前記端末に送信する、ことを特徴とする通信方法。
13. 前記通信装置は、
    前記応答に、前記要求のサービスに関する情報を含める、ことを特徴とする請求項１２記載の通信方法。
14. 前記通信装置は、
    前記応答に、前記要求のサービスを提供可能又は提供不可能なドメインを指定した情報を含める、ことを特徴とする請求項１２記載の通信方法。
15. 前記通信装置は、前記端末がローミング先からＶｏＬＴＥ（Voice over LTE(Long Term Evolution)）の通話モードで発信した前記要求を受ける、ホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳ（IP(Internet Protocol) Multimedia Subsystem）の呼制御を行う装置からなる、ことを特徴とする請求項１２乃至１４のいずれか１項に記載の通信方法。
16. 前記通信装置は、
    前記ホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳが接続する前記ホーム網側のＰＳ（パケット交換）ドメインに属するパケットコア網の管理ノード及び／又はゲートウェイから前記端末の位置情報を取得する、ことを特徴とする請求項１５記載の通信方法。
17. 前記ゲートウェイは、前記端末に対してＩＰアドレスを割り当てるＰＧＷ（PDN(Packet Data Network) Gateway）であり、
    前記管理ノードは、ポリシ及び課金ルールを管理するＰＣＲＦ（Policy and Charging Rule Function）である、ことを特徴とする請求項１６記載の通信方法。
18. 端末が、呼の要求を第一の通信装置に送信し、
    前記通信装置から、前記要求が受け付けられないことと、前記第一の通信装置で特定した前記要求のサービスとを示す情報と、を含む応答を受信し、
    前記情報に基づいて、前記第一の通信装置が属するドメイン以外のドメインに属する第二の通信装置を選択し、
    前記要求のサービスの提供を受けるための呼の要求を、前記第二の通信装置へ送信する、ことを特徴とする通信方法。
19. 前記応答に、前記要求のサービスを提供可能又は提供不可能なドメインを指定した情報がさらに含まれる、ことを特徴とする請求項１８に記載の通信方法。
20. 前記端末は、
    ローミング先からホーム網側のＰＳ（パケット交換）ドメインに属するＩＭＳ（IP(Internet Protocol) Multimedia Subsystem）の前記第一の通信装置へＶｏＬＴＥ（Voice over LTE(Long Term Evolution)）の通話モードで前記要求を送信し、
    ローミング先のＣＳ（回線交換）ドメインに属する第二の通信装置を選択し、前記要求のサービスの提供を受けるための呼の要求を前記第二の通信装置へ送信する、ことを特徴とする請求項１８又は１９に記載の通信方法。
21. 前記要求のサービスは緊急呼を含む、ことを特徴とする請求項１８乃至２０のいずれか１項に記載の通信方法。

Images