(57)【要約】  本発明の移動通信システムは、複数の基地局を有する。前記基地局は、当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する。
2015098268.tif 000002
【特許請求の範囲】
【請求項１】
複数の基地局を有する移動通信システムであって、
前記基地局は、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する、移動通信システム。
【請求項２】
前記基地局は、
当該基地局における前記緊急呼サポート情報をメッセージに含め、当該メッセージを、当該基地局に隣接する隣接基地局に送信する、請求項１に記載の移動通信システム。
【請求項３】
前記基地局を配下に持つ移動管理装置をさらに有し、
前記基地局は、
当該基地局における前記緊急呼サポート情報をメッセージに含め、当該メッセージを、前記移動管理装置を介して、当該基地局に隣接する隣接基地局に送信する、請求項１に記載の移動通信システム。
【請求項４】
前記基地局を配下に持つ移動管理装置をさらに有し、
前記移動管理装置は、
当該移動管理装置の配下の基地局における前記緊急呼サポート情報をメッセージに含め、当該メッセージを、当該基地局に隣接する隣接基地局に送信する、請求項１に記載の移動通信システム。
【請求項５】
前記基地局と無線通信を行う端末をさらに有し、
前記基地局は、
当該基地局における前記緊急呼サポート情報を第１のメッセージに含め、当該第１のメッセージを無線上に報知し、
前記端末は、
前記第１のメッセージを受信した場合、当該第１のメッセージに含まれる前記緊急呼サポート情報を第２のメッセージに含め、当該第２のメッセージを、無線通信中の基地局に送信する、請求項１に記載の移動通信システム。
【請求項６】
前記移動通信システムの運用／保守を行う運用保守装置をさらに有し、
前記運用保守装置は、
前記基地局における前記緊急呼サポート情報をメッセージに含め、当該メッセージを、当該基地局に隣接する隣接基地局に送信する、請求項１に記載の移動通信システム。
【請求項７】
前記基地局は、
当該基地局における緊急呼通信のサポート状況を変更した時に、変更後のサポート状況を示す前記緊急呼サポート情報をメッセージに含め、当該メッセージを、当該基地局に隣接する隣接基地局に送信する、請求項１に記載の移動通信システム。
【請求項８】
複数の基地局を有する移動通信システムにおける基地局であって、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する通信部を有する、
基地局。
【請求項９】
複数の基地局を有する移動通信システムにおける基地局による通信方法であって、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する、通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムにおいて、緊急呼を処理する技術に関する。
【背景技術】
【０００２】
移動通信システムにおいては、UE（User Equipment：端末）からの緊急呼（例えば、日本国内では、110番や119番宛の呼）を最優先で安定的にネットワークに伝達するために、確実に通信路を確保する必要がある。また、移動通信システム内のUEは、移動がなされる前提である（緊急呼は特許文献１，２に開示）。【０００３】
従って、移動通信システムにおいては、緊急呼通信中のUEが、通信路確保のために、eNB（evolved NodeB：基地局）のセルを跨いで移動するH/O（Hand Over：ハンドオーバ）を実施する場合がある。【０００４】
以下、緊急呼通信中のUEがH/Oを実施する場合の例を説明する。【０００５】
UEは、eNB#1と緊急呼通信中に、eNB#1のセルとeNB#1に隣接するeNB#2のセルとのセル境界へ移動して、eNB#2から、eNB#2へのH/Oが可能な領域に移動したことを知るために使用される信号を受信したとする。すると、UEは、その信号を受信したことをeNB#1に通知し、eNB#1は、UEにeNB#2へのH/Oを実施させようとする。【０００６】
しかし、eNB#2が必ずしも緊急呼通信をサポートしているとは限らない。例えば、eNB#1とeNB#2とが異なるPLMN（Public Land Mobile Network）に属する場合、PLMNを管理するネットワークオペレータが異なることがある。そのため、ネットワークオペレータ間で緊急呼通信のサポート状況が異なり、eNB#2が緊急呼通信をサポートしていないことも考えられる。【０００７】
したがって、UEは、eNB#2へのH/Oを実施したとしても、eNB#2が緊急呼通信をサポートしていなければ、緊急呼通信を継続できなくなる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２０１０−５２６４８６号公報
【特許文献２】国際公開第２０１３／０６５８２４号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述したように、移動通信システムにおいては、緊急呼通信中のUEは、緊急呼通信をサポートしていないeNBへのH/Oを実施すると、緊急呼通信を継続できなくなる。【００１０】
これを防止するためには、例えば、eNBは、緊急呼通信をサポートしていない隣接eNBに、緊急呼通信中のUEをH/Oさせてしまうのを回避する必要がある。【００１１】
しかし、eNBは、隣接eNBにおける緊急呼通信のサポート状況を知らない。【００１２】
そのため、eNBは、緊急呼通信をサポートしていない隣接eNBへのH/Oの実施を阻止することができない。【００１３】
本発明の目的は、上述した課題を解決するための技術を提供することにある。
【課題を解決するための手段】
【００１４】
本発明の移動通信システムは、
複数の基地局を有する移動通信システムであって、
前記基地局は、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する。【００１５】
本発明の基地局は、
複数の基地局を有する移動通信システムにおける基地局であって、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する通信部を有する。【００１６】
本発明の通信方法は、
複数の基地局を有する移動通信システムにおける基地局による通信方法であって、
当該基地局に隣接する隣接基地局における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する。
【発明の効果】
【００１７】
本発明によれば、基地局は、自己の基地局に隣接する隣接基地局における緊急呼通信のサポート状況を知ることができるという効果が得られる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態の移動通信システムの構成を示す図である。
【図２】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法１を説明するシーケンス図である。
【図３】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法２を説明するシーケンス図である。
【図４】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法３を説明するシーケンス図である。
【図５】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法４を説明するシーケンス図である。
【図６】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法５を説明するシーケンス図である。
【図７】本実施形態の移動通信システムにおいて、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法６を説明するシーケンス図である。
【図８】本実施形態の移動通信システムにおいて、緊急呼通信中のUE20のH/O時の動作を説明するシーケンス図である。
【図９】本発明の基地局の概要の構成を示す図である。
【発明を実施するための形態】
【００１９】
以下に、本発明を実施するための形態について図面を参照して説明する。
（１）本実施形態
（１−１）本実施形態の構成
図１に、本発明の一実施形態の移動通信システムの構成を示す。
【００２０】
図１に示すように、本実施形態の移動通信システムは、LTE（Long Term Evolution）の移動通信システムに適用した例である。
【００２１】
PLMN(#1)10-1とPLMN(#2)10-2とは、ネットワークシェアリングをしている。以下では、PLMN(#1)10-1とPLMN(#2)10-2を区別しない場合は、単にPLMN10と称す。
【００２２】
PLMN(#1)10-1の配下には、eNB(#1a)30-1aおよびeNB(#1b)30-1bと、MME（Mobility Management Entity）(#1)40-1と、EMS（Element Management System）(#1)50-1と、SON（Self Organizing Network）(#1)60-1と、が設けられている。
【００２３】
PLMN(#2)10-2の配下には、eNB(#2a)30-2aと、MME(#2)40-2と、EMS(#2)50-2と、SON(#2)60-2と、が設けられている。
【００２４】
UE20は、PLMN(#1)10-1のエリアとPLMN(#2)10-2のエリアを移動して、eNB(#1a)30-1a、eNB(#1b)30-1b、およびeNB(#2a)30-2aのいずれかと無線通信を行うことが可能な端末である。
【００２５】
eNB(#1a)30-1a、eNB(#1b)30-1b、およびeNB(#2a)30-2aは、UE20と無線通信を行うノードであり、基地局の一例である。以下では、eNB(#1a)30-1a、eNB(#1b)30-1b、およびeNB(#2a)30-2aを区別しない場合は、単にeNB30と称す。
【００２６】
MME(#1)40-1およびMME(#2)40-2は、UE20の移動管理を行うノードであり、移動管理装置の一例である。以下では、MME(#1)40-1およびMME(#2)40-2を区別しない場合は、単にMME40と称す。
【００２７】
EMS(#1)50-1およびEMS(#2)50-2は、移動通信システムの運用／保守を行うノードであり、運用保守装置（O&M（Operation and Maintenance）装置）の一例である。以下では、EMS(#1)50-1およびEMS(#2)50-2を区別しない場合は、単にEMS50と称す。
【００２８】
SON(#1)60-1およびSON(#2)60-2は、各eNB30の隣接セル情報を管理するノードを含む。以下では、SON(#1)60-1およびSON(#2)60-2を区別しない場合は、単にSON60と称す。
【００２９】
なお、SON60は、PLMN(#1)10-1およびPLMN(#2)10-2毎に設けているが、PLMN(#1)10-1およびPLMN(#2)10-2をまたぐ構成のSON60を設けても良い。
【００３０】
また、SON60は、EMS50を介してeNB30に接続されているが、eNB30に直接接続されていても良い。
（１−２）本実施形態の動作
以下、本実施形態の移動通信システムの動作について説明する。
（１−２−１）緊急呼サポート情報の通知動作
移動通信システムにおいては、緊急呼通信中のUE20が、緊急呼通信をサポートしていないeNB30へのH/Oを実施すると、緊急呼通信を継続できなくなる。
【００３１】
これを防止するためには、eNB30は、緊急呼通信中のUE20が、緊急呼通信をサポートしていない隣接eNB30へのH/Oを実施することを阻止する必要がある。
【００３２】
そのためには、eNB30は、自己のeNB30に隣接する隣接eNB30における緊急呼通信のサポート状況を知る必要がある。
【００３３】
そこで、本実施形態においては、eNB30に対し、そのeNB30に隣接する隣接eNB30における緊急呼通信のサポート状況（緊急呼通信をサポートしているか否か）を示す緊急呼サポート情報を知らせることとする。
【００３４】
例えば、eNB(#1a)30-1aに対しては、eNB(#1a)30-1aに隣接するeNB(#1b)30-1bおよびeNB(#2a)30-2aにおける緊急呼サポート情報を知らせる。
【００３５】
以下、eNB(#1a)30-1aに対して、eNB(#2a)30-2aにおける緊急呼サポート情報を知らせる方法について説明する。以下の図２〜図７の説明では、緊急呼サポート情報は、緊急呼通信をサポートしているか否かを示す識別子である緊急呼サポート識別子であるとする。
（１−２−１−１）方法１
図２に、方法１を説明するシーケンス図を示す。
【００３６】
図２に示すように、方法１は、eNB(#2a)30-2aが、X2インタフェースを用いて、緊急呼サポート識別子をeNB(#1a)30-1aに直接送信する方法である。
【００３７】
具体的には、eNB(#2a)30-2aは、例えば、立ち上げ時に、eNB(#2a)30-2aの緊急呼サポート識別子をX2 Setup requestメッセージに含め、そのX2 Setup requestメッセージをeNB(#1a)30-1aに送信する（ステップS11）。
【００３８】
なお、eNB30が緊急呼サポート識別子を含むX2 Setup requestメッセージを送信するタイミングは、立ち上げ時には限定されない。
【００３９】
また、eNB30は、隣接eNB30からのX2 Setup requestメッセージの受信をトリガーにして、X2 Setup responseメッセージに緊急呼サポート識別子を含めて、その隣接eNB30に送信しても良い。
（１−２−１−２）方法２
図３に、方法２を説明するシーケンス図を示す。
【００４０】
図３に示すように、方法２は、eNB(#2a)30-2aが、MME(#2)40-2およびMME(#1)40-1を介して、緊急呼サポート識別子をeNB(#1a)30-1aに送信する方法である。
【００４１】
具体的には、eNB(#2a)30-2aは、例えば、立ち上げ時に、eNB(#2a)30-2aの緊急呼サポート識別子をeNB Direct Information Transferメッセージに含め、そのeNB Direct Information TransferメッセージをMME(#2)40-2に送信する（ステップS21）。
【００４２】
次に、MME(#2)40-2は、eNB Direct Information Transferメッセージに含まれる緊急呼サポート識別子をRAN Information Relayメッセージに含め、そのRAN Information RelayメッセージをMME(#1)40-1に送信する（ステップS22）。
【００４３】
次に、MME(#1)40-1は、RAN Information Relayメッセージに含まれる緊急呼サポート識別子をMME Direct Information Transferメッセージに含め、そのMME Direct Information TransferメッセージをeNB(#1a)30-1aに送信する（ステップS23）。
【００４４】
なお、eNB30が緊急呼サポート識別子を含むX2 Setup requestメッセージを送信するタイミングは、立ち上げ時には限定されない。
（１−２−１−３）方法３
図４に、方法３を説明するシーケンス図を示す。
【００４５】
図４に示すように、方法３は、MME(#2)40-2が、配下のeNB(#2a)30-2aの緊急呼サポート識別子をeNB(#1a)30-1aに送信する方法である。
【００４６】
具体的には、MME(#2)40-2は、配下の各eNB30（eNB(#2a)30-2aを含む）における緊急呼通信のサポート状況を把握している。
【００４７】
そのため、MME(#2)40-2は、配下の各eNB30毎の緊急呼サポート識別子をRAN Information Relayメッセージに含め、そのRAN Information RelayメッセージをMME(#1)40-1に送信する（ステップS31）。
【００４８】
次に、MME(#1)40-1は、RAN Information Relayメッセージに含まれる、MME(#2)40-2配下の各eNB30毎の緊急呼サポート識別子をMME Direct Information Transferメッセージに含め、そのMME Direct Information TransferメッセージをeNB(#1a)30-1aに送信する（ステップS32）。
【００４９】
なお、MME(#2)40-2からMME(#1)40-1を介してeNB(#1a)30-1aに送信する緊急呼サポート識別子は、MME(#2)40-2配下のeNB30のうちeNB(#1a)30-1aに隣接するeNB30の緊急呼サポート識別子のみでも良い。
（１−２−１−４）方法４
図５に、方法４を説明するシーケンス図を示す。
【００５０】
図５に示すように、方法４は、eNB(#2a)30-2aが、緊急呼サポート識別子を無線上に報知して、eNB(#1a)30-1aが、UE20からの報告でeNB(#2a)30-2aの緊急呼サポート識別子を知る方法である。
【００５１】
具体的には、eNB(#2a)30-2aは、eNB(#2a)30-2aの緊急呼サポート識別子をeNB Direct Informationメッセージに含め、そのeNB Direct Informationメッセージを無線上に報知する（ステップS41）。
【００５２】
UE20は、eNB Direct Informationメッセージを受信した場合、そのeNB Direct Informationメッセージに含まれる緊急呼サポート識別子をRAN Information Relayメッセージに含め、そのRAN Information Relayメッセージを、無線通信中のeNB(#1a)30-1aに送信する（ステップS42）。
（１−２−１−５）方法５
図６に、方法５を説明するシーケンス図を示す。
【００５３】
図６に示すように、方法５は、EMS(#1)50-1が、eNB(#2a)30-2aの緊急呼サポート識別子をeNB(#1a)30-1aに送信する方法である。
【００５４】
具体的には、EMS(#1)50-1は、MME(#2)40-2から、MME(#2)40-2配下の各eNB30（eNB(#2a)30-2aを含む）毎の緊急呼サポート識別子を取得している。
【００５５】
そのため、EMS(#1)50-1は、MME(#2)40-2配下の各eNB30毎の緊急呼サポート識別子をSetup Informationメッセージに含め、そのSetup InformationメッセージをeNB(#1a)30-1aに送信する（ステップS51）。
【００５６】
なお、EMS(#1)50-1からeNB(#1a)30-1aに送信する緊急呼サポート識別子は、MME(#2)40-2配下のeNB30のうちeNB(#1a)30-1aに隣接するeNB30の緊急呼サポート識別子のみでも良い。
（１−２−１−６）方法６
図７に、方法６を説明するシーケンス図を示す。
【００５７】
図７に示すように、方法６は、eNB(#2a)30-2aが、運営途中で緊急呼通信のサポート状況を変更した時に、X2インタフェースを用いて、変更後の緊急呼サポート識別子をeNB(#1a)30-1aに直接送信する方法である。
【００５８】
具体的には、eNB(#2a)30-2aは、運営途中で緊急呼通信のサポート状況を変更した時（未サポート状態からサポート状態に変更した時や、サポート状態から未サポート状態に変更した時）、eNB(#2a)30-2aの変更後の緊急呼サポート状況を示す緊急呼サポート識別子をX2 eNB Configuration Updateメッセージに含め、そのX2 eNB Configuration UpdateメッセージをeNB(#1a)30-1aに送信する（ステップS61）。
【００５９】
なお、eNB(#1a)30-1aに対して、eNB(#1b)30-1bにおける緊急呼サポート情報を知らせる方法は、上記の方法１〜６（図２〜図７）のいずれか１つを使用しても良しい、いずれか２つ以上を組み合わせて使用しても良い。
【００６０】
ただし、方法２（図３）を使用する場合、ステップS21において、eNB Direct Information Transferメッセージは、eNB(#1b)30-1bからMME(#1)40-1に送信されるため、ステップS22は省略できる。また、方法３（図４）を使用する場合、eNB(#1b)30-1bにおける緊急呼通信のサポート状況を把握しているのはMME(#1)40-1であるため、ステップS31は省略できる。
【００６１】
eNB(#1a)30-1aは、上記の方法１〜６（図２〜図７）のようにして、eNB(#1a)30-1aに隣接するeNB(#1b)30-1bおよびeNB(#2a)30-2aにおける緊急呼サポート情報を知ることができるため、その緊急呼サポート情報をeNB(#1a)30-1a内の隣接セルリストに記録する。
【００６２】
隣接セルリストとは、自己のeNB30に隣接する隣接eNB30のセルのセル情報を記録したリストである。
【００６３】
例えば、隣接セルリストは、表１に示すように、各隣接セルのセル情報として、セル識別子、緊急呼通信のサポート状況、H/O可否等を記録する。なお、H/O可否は、例えば、故障中のeNB30等がH/O不可となる。また、H/O可否の情報はSON60から通知される。
【００６４】
【表１】
2015098268.tif 000003
上述したように、eNB30は、自己のeNB30に隣接する隣接eNB30における緊急呼通信のサポート状況を知ることができる。
【００６５】
そのため、eNB30は、後述のように、緊急呼通信中のUE20が緊急呼通信をサポートしていない隣接eNB30へのH/Oを実施することを阻止することができる。
【００６６】
これにより、UE20はH/O後も緊急呼通信を継続することができるため、移動通信システムのネットワーク品質および信頼性が損なわれることがない。
（１−２−２）H/O動作
次に、UE20のH/O時の動作について説明する。
【００６７】
図８に、UE20のH/O時の動作を説明するシーケンス図を示す。
【００６８】
なお、図８のシーケンス図は3GPP（Third Generation Partnership Project）標準を元にした簡易版である。
【００６９】
eNB30において緊急呼を表現する場合、TS23.401にある以下の表現を使う。
【００７０】
“emergency bearer service”、“E-RAB with a Particular ARP value”。
（ARP= Allocation/Retention Priorityである。eNBのTS36.413やRNCのTS25.413では特にこのARPを使ってEmergency Bearer Serviceを表現している。）
また、図８では、PLMN(#1)10-1配下のeNB(#1a)30-1aと緊急呼通信中のUE20が、PLMN(#1)10-1のエリアから、PLMN(#1)10-1とネットワークシェアリングをしているPLMN(#2)10-2のエリアに移動し、H/Oをしようとしているものとする。
【００７１】
また、eNB(#1a)30-1a、eNB(#1b)30-1b、およびeNB(#2a)30-2aは、上記の方法１〜６（図２〜図７）のようにして、自己のeNB30に隣接する隣接eNB30における緊急呼サポート情報を受信し、隣接セルリストに記録しているものとする。
【００７２】
図８に示すように、PLMN(#2)10-2配下のeNB(#2a)30-2aは、システム報知情報を報知している。PLMN(#2)10-2のエリアに移動したUE20は、eNB(#2a)30-2aからシステム報知情報を受信したとする（ステップS71）。
【００７３】
すると、UE20は、eNB(#2a)30-2aのシステム報知情報から、eNB(#2a)30-2aへのH/Oが可能な領域に移動したことを知るために使用される信号を受信する。この信号は3GPP標準に規定済みの信号である。
【００７４】
そして、UE20は、緊急呼通信中のeNB(#1a)30-1aへメジャーメントリポートを送信し、eNB(#2a)30-2aへのH/Oが可能な領域に位置することを通知する（ステップS72）。
【００７５】
一方、PLMN(#1)10-1配下のeNB(#1b)30-1bも、システム報知情報を報知しており、このシステム報知情報もUE20が受信したとする（ステップS73）。
【００７６】
すると、UE20は同様に、緊急呼通信中のeNB(#1a)30-1aへメジャーメントリポートを送信し、eNB(#1b)30-1bへもH/Oが可能な領域に位置することを通知する（ステップS74）。
【００７７】
ここで、eNB(#1a)30-1aは、上記の方法１〜６のようにして、eNB(#2a)30-2aおよびeNB(#1b)30-1bにおける緊急呼サポート情報をすでに受信し、隣接セルリストに記録している。ただし、eNB(#1a)30-1aが、eNB(#2a)30-2a及び/またはeNB(#1b)30-1bの緊急呼サポート情報を受信していない場合には、UE20からのメジャーメントリポートの受信をトリガーに、隣接eNB30に緊急呼サポート情報を問い合わせることで、緊急呼サポート情報の収集を行っても良い。
【００７８】
ここでは、eNB(#2a)30-2aが緊急呼通信をサポートしておらず、eNB(#1b)30-1bが緊急呼通信をサポートしているとする。
【００７９】
また、eNB(#1a)30-1aは、UE20がeNB(#2a)30-2aおよびeNB(#1b)30-1bへのH/Oが可能な領域に位置していることをUE20からのメジャーメントリポートで認識している。また、UE20は緊急呼通信中である。
【００８０】
これらを鑑み、eNB(#1a)30-1aは、UE20のH／O先を、緊急呼通信をサポートしているeNB(#1b)30-1bに決定し、eNB(#1b)30-1bへのH／O要求をMME(#1)40-1に送信する（ステップS75）。
【００８１】
上記の例は、UE20がシステム報知情報を受信することを示しているが、図示していない例として、システム報知情報を受信しない場合もある。例えば、UE20は、eNB(#2a)30-2aのシステム報知情報に相当する情報を、通信中のeNB(#1a)30-1aから受信することができる。そのため、UE20は、隣接するeNB(#2a)30-2aのシステム報知情報を受信せずとも、通信中のeNB(#1a)30-1aにメジャーメントリポートを送信することができる。例えば、UE20は、eNB(#2a)30-2aの使っている周波数などの情報（図８のS71におけるシステム報知情報に相当する情報）をeNB(#1a)30-1aからもらい、この周波数などの情報を使って、eNB(#2a)30-2aの使っている周波数の電力レベルを測定して、eNB(#1a)30-1aへメジャーメントリポートを送信することができる。
【００８２】
上記の方法１〜６（図２〜図７）のようにして、eNB(#1a)30-1aに対し、eNB(#2a)30-2aおよびeNB(#1b)30-1bにおける緊急呼サポート情報を知らせることは、本発明の本質となる部分である。特に、eNB(#1a)30-1aから見て、隣接するeNB(#2a)30-2aは、ネットワークシェアリングされた、異なるPLMN10配下のノードでありながら、事前に緊急呼サポート情報を知ることができる。
【００８３】
これにより、eNB(#1a)30-1aは、隣接するeNB(#2a)30-2aおよびeNB(#1b)30-1bにおける緊急呼サポート情報を事前に隣接セルリスト中に記録することができるため、隣接するeNB(#2a)30-2aおよびeNB(#1b)30-1bがH/O先のeNB30として適切かどうかの判断ができる。そのため、UE20はH/O後も問題なく緊急呼通信を継続することができる。
（２）他の実施形態
以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明の範囲内で当業者が理解し得る様々な変更をすることができる。以下、その変形例を示す。
（２−１）例えば、上記実施形態は、eNB30が、隣接eNB30、MME40、およびUE20から緊急呼サポート情報を受信し、eNB30内の隣接セルリストに記録していく方式である。
【００８４】
その一方、SON60内のノードは、ネットワークの効率的な運用を目的として、各eNB30の隣接セル情報を管理している。隣接セル情報には、各eNB30の隣接セルリストとして、表１に示したような緊急呼サポート情報が記録された隣接セルリストが含まれている。また、SON60内のノードは、自己のSON60が属するPLMN10配下の各eNB30の隣接セル情報だけでなく、そのPLMN10がネットワークシェアリングをしている他のPLMN配下の各eNB30の隣接セル情報も管理している。
【００８５】
そのため、SON60内のノードが、各eNB30に対し、隣接セル情報を提供しても良い。
【００８６】
ここで、SON60内のノードが、各eNB30に隣接セル情報を提供する一例として、ANR（Automatic Neighbor Relation）を使用する例を説明する。
【００８７】
まず、UE20が、eNB30に対して、そのeNB30の隣接セルリストに含まれないセル情報を報告する。
【００８８】
次に、eNB30は、SON60内のノードに対して、UE20から報告されたセル情報を報告する。
【００８９】
次に、SON60内のノードは、eNB30からセル情報が報告されたセルを、そのeNB30のセルに隣接する隣接セルとして管理すべきか判断する。
【００９０】
SON60内のノードは、隣接セルとして管理すべきと判断した場合、eNB30に対して、そのセルのセル情報（セル識別子、緊急呼通信のサポート状況、H/O可否等）を報告する。
【００９１】
その後、eNB30は、SON60内のノードから報告されたセル情報を、隣接セルリストに記録する。
（２−２）また、上記実施形態は、H/O元のeNB30がH/O先のeNB30を決定する方式である。
【００９２】
その一方、SON60内のノードは、上述したように、各eNB30の隣接セルリストを含む隣接セル情報を管理している。
【００９３】
そのため、SON60内のノードがH/O先のeNB30を決定しても良い。
【００９４】
SON60内のノードがH/O先のeNB30を決定する方式は、上記実施形態のように、H/O元のeNB30がH/O先のeNB30を決定する方式と比較して、H/O先のeNB30を早く決定することが可能になるという利点がある。
（２−３）また、上記実施形態では、eNB30同士は、緊急呼サポート情報のみを単体で交換する方式であったが、緊急呼サポート情報を含む隣接セルリストを交換しても良い。この場合、自己のeNB30における緊急呼サポート情報を相手に通知するために、自己のeNB30も隣接セルリストに含める必要がある。
（２−４）また、上記実施形態は、H/O元のeNB30が、自己のeNB30内の隣接セルリストを参照して、H/O先のeNB30を決定する方式であったが、H/O元のeNB30が、SON60内のノードが保持する隣接セルリストを参照して、H/O先のeNB30を決定しても良い。
（２−５）また、上記実施形態の方法１，２，４，６（図２、図３、図５、図７）では、eNB30が、自己のeNB30における緊急呼通信のサポート状況を把握していることを想定しているが、必ずしもeNB30が把握しているとは限らない。
【００９５】
そのため、eNB30が、MME40に対し、自己のeNB30における緊急呼通信のサポート状況を問合せても良い。
【００９６】
問い合わせの方法としては、S1 setup requestメッセージやeNB configuration requestメッセージを用いる方法が挙げられる。また、その問い合わせに対する応答の方法としては、S1 setup responseメッセージやeNB configuration responseメッセージを用いる方法が挙げられる。
（２−６）また、上記実施形態では、eNB30が、自己のeNB30の緊急呼サポート情報を送信したり、MME40が、配下の各eNB30毎の緊急呼サポート情報を送信したりする等、eNB30単位で緊急呼通信のサポート状況を知らせていた。
【００９７】
しかし、同じPLMN10配下のeNB30に対し、緊急呼通信のサポート状況を同じ設定にする場合も考えられる。
【００９８】
その場合は、eNB30に対し、PLMN10における緊急呼通信のサポート状況（すなわち、PLMN10配下の全eNB30における緊急呼通信のサポート状況）を知らせても良い。
【００９９】
そこで、eNB30は、未サポート状態に遷移することをトリガーに、UE20を、隣接eNB30に強制的にH/Oさせても良い。
（２−８）また、上記実施形態では、UE20が緊急呼通信中であるものとして説明した。eNB30は、緊急呼通信以外の通信中のUE20は、緊急呼通信をサポートしていないeNB30へH/Oをさせても良い。しかし、eNB30は、少なくとも緊急呼通信中のUE20は、緊急呼通信をサポートしているeNB30へH/Oをさせるものとする。
（２−９）また、上記実施形態では、UE20は、eNB30からシステム報知情報を受信し、そのシステム報知情報から、そのeNB30へのH/Oが可能な領域に移動したことを知るために使用される信号を受信するものとして説明したが、UE20は、システム報知情報の受信よりも先に、上記の信号の検出または上記の信号の品質測定をしても良いものとする。
（３）本発明の概要
最後に、本発明の概要を説明する。
【０１００】
図９に、本発明の特徴部分となるeNB30の概要の構成を示す。
【０１０１】
図９に示すように、eNB30は、通信部31を有している。通信部31は、自己のeNB30に隣接する隣接eNB30における緊急呼通信のサポート状況を示す緊急呼サポート情報を受信する。
【０１０２】
なお、隣接eNB30における緊急呼サポート情報を受信する方法は、例えば、上記の方法１〜６（図２〜図７）を使用することができる。
【０１０３】
これにより、eNB30は、自己のeNB30に隣接する隣接eNB30における緊急呼通信のサポート状況を知ることができる。
【０１０４】
なお、通信部31は、他ノードと通信を行う部分であり、上記の方法１，２，４，６（図２、図３、図５、図７）の場合、自己のeNB30における緊急呼サポート情報を隣接eNB30に送信することも行うものとする。
【０１０５】
また、eNB30は、通信部31以外にも、各種情報を記憶する記憶部を有するものとする。この記憶部は、例えば、自己のeNB30に隣接する隣接eNB30のセルのリストである隣接セルリストを記憶する。
【０１０６】
また、eNB30は、各種処理を行う制御部を有するものとする。この制御部は、例えば、緊急呼サポート情報をメッセージに含める処理や、自己のeNB30がH/O元である場合に、H/O先のeNB30を決定する処理等を行う。
【０１０７】
また、eNB30以外のノード（UE20、MME40、EMS50、SON60内のノード）も、eNB30と同様に、他ノードと通信を行う通信部と、各種情報を記憶する記憶部と、緊急呼サポート情報をメッセージに含める処理等の各種処理を行う制御部と、を有するものとする。
【０１０８】
なお、通信部（通信機）は、送信部（送信機）と受信部（受信機）を有し、例えば、送信部（送信機）は、上述した緊急呼サポート情報を送信し、受信部（受信機）は、上述した緊急呼サポート情報を受信するよう構成される。
【産業上の利用可能性】
【０１０９】
本発明は、自動車、船舶、航空機等の移動体に搭載された端末を対象とする移動通信に利用可能である。【０１１０】
本出願は、２０１３年１２月２７日に出願された日本出願特願２０１３−２７１５８１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【図１】
2015098268.tif 000004
【図２】
2015098268.tif 000005
【図３】
2015098268.tif 000006
【図４】
2015098268.tif 000007
【図５】
2015098268.tif 000008
【図６】
2015098268.tif 000009
【図７】
2015098268.tif 000010
【図８】
2015098268.tif 000011
【図９】
2015098268.tif 000012
【国際調査報告】
2015098268.tif 000013
2015098268.tif 000014