(57)【特許請求の範囲】
【請求項１】
ユーザ装置から発信されるVoLTE（Voice over LTE）の呼が緊急呼か否かを、ユーザ装置からの発信時のメッセージに基づいて判断する緊急呼判断部と、
前記呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティから送信される、前記呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、前記呼に関して一般呼のための音声用デフォルトベアラを確立する一般音声デフォルトベアラ確立部と、
前記移動管理エンティティから送信される、前記呼が実際に緊急呼であることを示す第２のベアラ確立要求メッセージに応答して、前記呼に関して緊急呼のための音声用デフォルトベアラを確立する緊急音声デフォルトベアラ確立部と、
前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記呼をハンドオーバすべきか否かを判断するハンドオーバ判断部と、
前記ハンドオーバ判断部が前記ユーザ装置の前記呼をハンドオーバすべきであると判断する場合に、前記他の無線基地局にハンドオーバ要求を送信するハンドオーバ要求送信部とを備え、
前記ハンドオーバ要求送信部は、前記一般音声デフォルトベアラ確立部によって前記一般呼のための音声用デフォルトベアラが確立された後に、前記緊急音声デフォルトベアラ確立部によって前記緊急呼のための音声用デフォルトベアラが確立される前に、前記ハンドオーバ要求を送信するときに、前記緊急呼判断部が前記呼が緊急呼であると判断している場合に、前記ハンドオーバ要求に、前記呼が緊急呼であることを示す情報を含めることを特徴とする
ハンドオーバ元無線基地局。
【請求項２】
請求項１に記載のハンドオーバ元無線基地局から前記ハンドオーバ要求を受信するハンドオーバ要求受信部と、
前記ハンドオーバ要求を前記ハンドオーバ要求受信部が受信した後に、前記移動管理エンティティから送信されるベアラ確立要求メッセージを受信するベアラ確立要求メッセージ受信部と、
前記ベアラ確立要求メッセージ受信部が前記移動管理エンティティから受信する前記ベアラ確立要求メッセージが前記呼が実際に緊急呼であることを示す場合に、前記呼に関して緊急呼のためのベアラを確立するベアラ確立部と、
前記呼である直前の呼が終結した後でも、前記ユーザ装置から新規な呼が発信されると、前記新規な呼を受け付ける新規呼受付部と、
前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記新規呼をハンドオーバすべきか否かを判断する第２のハンドオーバ判断部と、
前記第２のハンドオーバ判断部が前記ユーザ装置の前記新規な呼をハンドオーバすべきであると判断する場合に、他の無線基地局に第２のハンドオーバ要求を送信する第２のハンドオーバ要求送信部とを備え、
前記第２のハンドオーバ要求送信部は、前記直前の呼が終結した後に、前記第２のハンドオーバ要求を送信するときに、前記ベアラ確立要求メッセージ受信部が前記移動管理エンティティから受信した前記ベアラ確立要求メッセージが前記直前の呼が実際に緊急呼であることを示している場合に、前記第２のハンドオーバ要求に、前記新規な呼が緊急呼であることを示す情報を含めないことを特徴とする
ハンドオーバ先無線基地局。
【請求項３】
前記ベアラ確立要求メッセージ受信部は、前記直前の呼が緊急呼であることを示す前記移動管理エンティティから送信される音声用デフォルトベアラのための第３のベアラ確立要求メッセージと、前記直前の呼が緊急呼であることを示す前記移動管理エンティティから送信される音声用デディケイテッドベアラのための第４のベアラ確立要求メッセージとを受信し、
前記ベアラ確立部は、前記ベアラ確立要求メッセージ受信部が前記第３のベアラ確立要求メッセージを受信すると、前記直前の呼に関して緊急呼のための音声用デフォルトベアラを確立し、前記ベアラ確立要求メッセージ受信部が前記第４のベアラ確立要求メッセージを受信すると、前記直前の呼に関して緊急呼のための音声用デディケイテッドベアラを確立し、
前記第２のハンドオーバ要求送信部は、前記直前の呼が終結した後に、前記第２のハンドオーバ要求を送信するときに、前記ベアラ確立要求メッセージ受信部が前記移動管理エンティティから受信した前記第３のベアラ確立要求メッセージが前記直前の呼が実際に緊急呼であることを示している場合に、前記ハンドオーバ要求に、前記新規な呼が緊急呼であることを示す情報を含めないことを特徴とする
請求項２に記載のハンドオーバ先無線基地局。
【請求項４】
請求項１に記載のハンドオーバ元無線基地局と、他の無線基地局とを備え、
前記他の無線基地局は、
前記他の無線基地局が輻輳状態であるか否かを判断する輻輳判断部と、
前記ハンドオーバ元無線基地局から前記ハンドオーバ要求を受信するハンドオーバ要求受信部と、
前記輻輳判断部が前記他の無線基地局が輻輳状態であると判断する場合、かつ前記呼が緊急呼であることを示す前記情報を前記ハンドオーバ要求が含む場合に、前記ハンドオーバ要求に従って前記ユーザ装置との通信を開始し、前記輻輳判断部が前記他の無線基地局が輻輳状態であると判断する場合、かつ前記呼が緊急呼であることを示す前記情報を前記ハンドオーバ要求が含まない場合に、前記ハンドオーバ要求を拒否するハンドオーバ制御部と
を備えることを特徴とする無線通信システム。
【請求項５】
請求項２に記載のハンドオーバ先無線基地局と、前記ハンドオーバ先無線基地局から前記第２のハンドオーバ要求を受信する他の無線基地局とを備え、
前記ハンドオーバ先無線基地局は、
前記ハンドオーバ先無線基地局が輻輳状態であるか否かを判断する第１の輻輳判断部と、
前記第１の輻輳判断部が前記ハンドオーバ先無線基地局が輻輳状態であると判断する場合、かつ前記呼が緊急呼であることを示す前記情報を前記ハンドオーバ要求が含む場合に、前記ハンドオーバ要求に従って前記ユーザ装置との通信を開始し、前記第１の輻輳判断部が前記ハンドオーバ先無線基地局が輻輳状態であると判断する場合、かつ前記呼が緊急呼であることを示す前記情報を前記ハンドオーバ要求が含まない場合に、前記ハンドオーバ要求を拒否する第１のハンドオーバ制御部と
を備え、
前記他の無線基地局は、
前記他の無線基地局が輻輳状態であるか否かを判断する第２の輻輳判断部と、
前記ハンドオーバ先無線基地局から前記第２のハンドオーバ要求を受信する第２のハンドオーバ要求受信部と、
前記第２の輻輳判断部が他の無線基地局が輻輳状態であると判断する場合、かつ前記新規呼が緊急呼であることを示す前記情報を前記第２のハンドオーバ要求が含む場合に、前記第２のハンドオーバ要求に従って前記ユーザ装置との通信を開始し、前記第２の輻輳判断部が前記他の無線基地局が輻輳状態であると判断する場合、かつ前記新規呼が緊急呼であることを示す前記情報を前記第２のハンドオーバ要求が含まない場合に、前記第２のハンドオーバ要求を拒否する第２のハンドオーバ制御部と
を備えることを特徴とする無線通信システム。
【請求項６】
ユーザ装置から発信されるVoLTE（Voice over LTE）の呼が緊急呼か否かを、ハンドオーバ元無線基地局にて、ユーザ装置からの発信時のメッセージに基づいて判断することと、
前記呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティから送信される、前記呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、前記ハンドオーバ元無線基地局にて、前記呼に関して一般呼のための音声用デフォルトベアラを確立することと、
前記ハンドオーバ元無線基地局にて、前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記呼をハンドオーバすべきか否かを判断することと、
前記ユーザ装置の前記呼をハンドオーバすべきであると判断された場合に、前記ハンドオーバ元無線基地局にて、前記他の無線基地局にハンドオーバ要求を送信することとを備え、
前記ハンドオーバ要求を送信することは、前記一般呼のための音声用デフォルトベアラが確立された後に、緊急呼のための音声用デフォルトベアラが確立される前に、前記ハンドオーバ要求を送信するときに、前記呼が緊急呼であると判断されている場合に、前記ハンドオーバ要求に、前記呼が緊急呼であることを示す情報を含めることを有することを特徴とする
無線通信方法。
【請求項７】
ハンドオーバ先無線基地局にて、前記ハンドオーバ元無線基地局から、前記呼が緊急呼であることを示す前記情報を含む前記ハンドオーバ要求を受信することと、
前記移動管理エンティティから送信されるベアラ確立要求メッセージを前記ハンドオーバ先無線基地局にて受信することと、
前記移動管理エンティティから受信する前記ベアラ確立要求メッセージが前記直前の呼が実際に緊急呼であることを示す場合に、前記ハンドオーバ先無線基地局にて、前記呼に関して緊急呼のためのベアラを確立することと、
前記呼である直前の呼が終結した後でも、前記ユーザ装置から新規な呼が発信されると、前記ハンドオーバ先無線基地局にて、前記新規な呼を受け付けることと、
前記ハンドオーバ先無線基地局にて、前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記新規呼をハンドオーバすべきか否かを判断することと、
前記ユーザ装置の前記新規な呼をハンドオーバすべきであると判断する場合に、前記ハンドオーバ先無線基地局にて、他の無線基地局に第２のハンドオーバ要求を送信することとを備え、
前記第２のハンドオーバ要求を送信することは、前記直前の呼が終結した後に、前記第２のハンドオーバ要求を送信するときに、前記移動管理エンティティから受信した前記ベアラ確立要求メッセージが前記直前の呼が実際に緊急呼であることを示している場合に、前記ハンドオーバ要求に、前記新規な呼が緊急呼であることを示す情報を含めないことを有することを特徴とする
請求項６に記載の無線通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハンドオーバ元無線基地局、ハンドオーバ先無線基地局、無線通信システムおよび無線通信方法に関する。
【背景技術】
【０００２】
3GPP (Third-Generation Partnership Project)のLTE (Long Term Evolution)において、Voice over LTE (VoLTE)を行う場合、UE (ユーザ装置、User Equipment、移動局)が無線ネットワークに接続するには、まずデフォルトベアラ（default bearer）と呼ばれるベアラが確立され、デフォルトベアラを介してSIP（セッションイニシエーションプロトコル）手順に従ったシグナリングが実行され、その後に、デディケイテッドベアラ（dedicated bearer、個別ベアラ）と呼ばれる音声通信用のベアラが確立される。
【０００３】
図１は、VoLTEを利用可能なUEに対して確立される各種のベアラを示す概略図である。図１に示すように、アクセスポイント（AP）とUEの間には、eNB（基地局）を介して、各種のベアラが確立される。アクセスポイントには、SPモード（smart phone mode）用のアクセスポイントと、IMS (IP Multimedia Subsystem)のアクセスポイントと、IMS緊急呼のアクセスポイントがある。データ通信にはSPモード用のアクセスポイントが利用され、音声データ通信つまりVoLTEには、IMSまたはIMS緊急呼のアクセスポイントが利用される。VoLTEはIMSを利用する。
【０００４】
VoLTEの一般呼のためには、まずUEとIMSのアクセスポイントの間にデフォルトベアラが確立される。デフォルトベアラは、あるUEとあるアクセスポイントの間に最初に設定されるベアラである。デフォルトベアラを利用して、SIPのシグナリングが実行され、その後にUEとIMSのアクセスポイントの間にデディケイテッドベアラが確立される。デディケイテッドベアラは、あるUEとあるアクセスポイントの間に２つ目またはそれ以降に設定されるベアラである。このデディケイテッドベアラが確立されることで、音声データが通信される。
【０００５】
VoLTEの緊急呼（警察機関、消防機関または救急医療機関への呼）のためには、まずUEとIMS緊急呼のアクセスポイントの間にデフォルトベアラが確立される。デフォルトベアラを利用して、SIPのシグナリングが実行され、その後にUEとIMS緊急呼のアクセスポイントの間にデディケイテッドベアラが確立される。このデディケイテッドベアラが確立されることで、緊急呼の音声データが通信される。
【０００６】
データ通信のためには、まずUEとIMSのアクセスポイントの間にデフォルトベアラが確立される。その後、UEとSPモード用のアクセスポイントの間にデフォルトベアラが確立されて、このデフォルトベアラを介してデータが通信される。
【０００７】
LTEでは、Allocation and Retention Priority (ARP)と呼ばれる情報要素によって、一般呼と優先的な呼を区別する（非特許文献１参照）。非特許文献１のSec. 9.2.31には、ARPを用いて一般呼と優先的な呼を識別することが記載されている。具体的には、ARPに含まれる優先度レベル（Priority Level）が１５であれば一般呼であり、優先度レベルが１〜１４であれば、優先的な呼である。また、優先的な音声呼のベアラが存在する状態で、データ通信が発信された場合には、そのデータ通信の呼には優先度レベルとして１５が使用されることもある。
【０００８】
ARPは、下記のメッセージに添付されて送信される。
S1-AP（application protocol）：Initial Context Setup Request
S1-AP：E-RAB Setup Request
S1-AP：E-RAB Modify Request
S1-AP：Handover Request
X2-AP：Handover Request
【０００９】
また、ARPの優先度レベル１〜１４で識別される優先的な呼は、優先ユーザの呼と緊急呼に分類される。優先ユーザの呼は例えば重要な加入者のUEが発信する呼である。UEから送信されるIMSI（International Mobile Subscriber Identity）によって、呼が優先ユーザの呼か否かをeNBおよびMME(Mobility Management Entity、移動管理エンティティ)が判別することができる。したがって、eNBおよびMMEは、優先ユーザの呼と緊急呼とを区別することができる。優先ユーザの呼は、緊急呼と異なり、常に優先的に無線通信ネットワークで取り扱われる。
【００１０】
図２は、VoLTEの一般呼の発信における無線通信ネットワークでの制御手順を示すシーケンス図である。UEにおいて一般呼が発信されると、UEとeNBは、RRC Connection確立処理Step1を実行する。RRC Connection確立処理Step1では、UEがeNBにRRC Connection Requestを送信し、eNBがUEにRRC Connection Setupを送信し、UEがeNBにRRC Connection Setup Completeを送信する。
【００１１】
次に、音声用デフォルトベアラ確立処理Step2が実行される。ここでは、eNBがMME にInitial UE Messageを送信し、MMEがeNBにInitial Context Setup Requestを送信し、eNBがUEにSecurity Mode CommandおよびRRC Connection Reconfigurationを送信し、UEがeNBにSecurity Mode CompleteおよびRRC Connection Reconfiguration Completeを送信し、eNBがMMEにInitial Context Setup Responseを送信する。この処理により、UEとIMSのアクセスポイントの間にデフォルトベアラが確立される。
【００１２】
次に、UEとIMSのアクセスポイントの間に設定されたデフォルトベアラを利用して、SIP手順Step3が実行される。さらに、音声用デディケイテッドベアラ確立処理Step4が実行される。ここでは、MMEがeNBにE-RAB Setup Requestを送信し、eNBがUEにRRC Connection Reconfigurationを送信し、UEがeNBにRRC Connection Reconfiguration Completeを送信し、eNBがMMEにE-RAB Setup Responseを送信する。この処理により、UEとIMSのアクセスポイントの間にデディケイテッドベアラが確立される。以降、VoLTEによる音声通信が開始される（Step5）。
【００１３】
音声用デフォルトベアラ確立処理Step2で、MMEがeNBに送信するInitial Context Setup Requestは情報要素ARPを含んでおり、このARPでは優先度レベルが15（つまり一般呼）に設定されている。これは、実際に発信される呼が一般呼か緊急呼かという事実には関係なく、eNBがMMEに送信するInitial UE MessageがService Requestと呼ばれる情報要素を含んでいれば、MMEは優先度レベル15をeNBに通知するように、規定されているためである。
【００１４】
音声用デディケイテッドベアラ確立処理Step4で、MMEがeNBに送信するE-RAB Setup Requestも情報要素ARPを含んでおり、このARPでも優先度レベルが15（つまり一般呼）に設定されている。これは、特別にUEからMMEにNAS (Non-Access Stratum)で緊急呼の通知がされない限り、MMEは優先度レベル15をeNBに通知するように、規定されているためである。
【００１５】
図３は、VoLTEの緊急呼の発信における無線通信ネットワークでの制御手順を示すシーケンス図である。UEにおいて緊急呼が発信されると、UEとeNBは、図２の制御手順と同様に、RRC Connection確立処理Step1を実行する。
【００１６】
次に、音声用デフォルトベアラ確立処理Step2が実行される。この音声用デフォルトベアラ確立処理Step2も図２の音声用デフォルトベアラ確立処理Step2と同様であり、UEとIMSのアクセスポイントの間にデフォルトベアラが確立される。
【００１７】
緊急呼のための制御手順でも音声用デフォルトベアラ確立処理Step2で、MMEがeNBに送信するInitial Context Setup Requestに含まれるARPでは優先度レベル15（つまり一般呼）が設定されている。これは、実際に発信される呼が一般呼か緊急呼かという事実には関係なく、eNBがMMEに送信するInitial UE MessageがService Requestと呼ばれる情報要素を含んでいれば、MMEは優先度レベル15をeNBに通知するように、規定されているためである。緊急呼の発信があった場合、非特許文献２のSec. 5.10.2に記載されているように、MMEは、IMS緊急呼のアクセスポイントに接続する前にService Request手順を実施する。
【００１８】
音声用デフォルトベアラ確立処理Step2によりUEとMMEとがデータ交換可能となった後（Active 遷移の後）、緊急呼通知処理Step6が実行される。緊急呼通知処理Step6では、UEがeNBにUL Information Transferを送信し、eNBがMMEにUplink NAS Transferを送信する。UL Information TransferおよびUplink NAS Transferは、NASを利用したPDN Connectivity Requestである。このようにして、UEからNASを介してMMEに呼が緊急呼であることが通知される。
【００１９】
緊急呼通知処理Step6が終わると、緊急音声用デフォルトベアラ確立処理Step7が実行される。ここでは、MMEがeNBにE-RAB Setup Requestを送信し、eNBがUEにRRC Connection Reconfigurationを送信し、UEがeNBにRRC Connection Reconfiguration Completeを送信し、eNBがMMEにE-RAB Setup Responseを送信する。緊急音声用デフォルトベアラ確立処理Step7で、MMEがeNBに送信するE-RAB Setup Requestに含まれる情報要素ARPでは優先度レベルが15以外（つまり緊急呼）に設定されている。緊急音声用デフォルトベアラ確立処理Step7により、UEとIMS緊急呼のアクセスポイントの間にデフォルトベアラが確立される。
【００２０】
次に、UEとIMS緊急呼のアクセスポイントの間に設定されたデフォルトベアラを利用して、SIP手順Step8が実行される。さらに、緊急音声用デディケイテッドベアラ確立処理Step9が実行される。ここでは、MMEがeNBにE-RAB Setup Requestを送信し、eNBがUEにRRC Connection Reconfigurationを送信し、UEがeNBにRRC Connection Reconfiguration Completeを送信し、eNBがMMEにE-RAB Setup Responseを送信する。緊急音声用デディケイテッドベアラ確立処理Step9で、MMEがeNBに送信するE-RAB Setup Requestに含まれる情報要素ARPでは優先度レベルが15以外（つまり緊急呼）に設定されている。緊急音声用デディケイテッドベアラ確立処理Step9により、UEとIMS緊急呼のアクセスポイントの間にデディケイテッドベアラが確立される。以降、VoLTEによる音声通信が開始される（Step10）。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】3GPP TS 36.423 V11.1.0 (2012-06), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); "X2 application protocol (X2AP) (Release 11)", ２０１２年６月
【非特許文献２】3GPP TS 23.401 V11.2.0 (2012-06), 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 11)", ２０１２年６月
【発明の概要】
【発明が解決しようとする課題】
【００２２】
上記のように、VoLTEの緊急呼の発信においては、一般呼の発信と同様に、UEとIMSのアクセスポイントの間にデフォルトベアラを確立する音声用デフォルトベアラ確立処理Step2が実行される。緊急呼のための制御手順でも音声用デフォルトベアラ確立処理Step2で、MMEがeNBに送信するInitial Context Setup Requestに含まれるARPでは優先度レベル15（つまり一般呼）が設定され、eNBには呼が一般呼であると通知されてしまう。このため、UEの移動に伴うハンドオーバにおいて問題が生ずるおそれがある。
【００２３】
図４は、VoLTEの緊急呼の発信におけるハンドオーバの問題を示すシーケンス図である。ハンドオーバの問題を示すため、２つのeNB（eNB１およびeNB２）を示す。UEは、まずeNB１にアタッチする。したがって、UEとeNB１がRRC Connection確立処理Step1を実行し、UEとeNB１とMMEが音声用デフォルトベアラ確立処理Step2を実行する。
【００２４】
音声用デフォルトベアラ確立処理Step2でActive遷移後は、UEとeNB１の間で通信が可能であり、UEはMeasurement ReportをeNB１に送信することができる。Measurement Reportは、UEでのUEがアタッチしているeNBから電波の受信品質および他のeNBからの電波の受信品質を示す信号である。UEがeNB１よりもeNB２と通信する方がUEでの受信品質が改善する場合には、eNB１はUEのハンドオーバを決定し、そのUEのためにeNB２にHandover Requestを送信する。Handover Requestは情報要素ARPを含む。Initial Context Setup Requestによって、eNBには一般呼の通知がされているため、Handover Requestに含まれるARPでは優先度レベルが15（つまり一般呼）に設定されている。
【００２５】
しかし、eNB２は、Handover Requestの受信の前に輻輳のために、CAC（Call Admission Control、呼受付制御）において一般呼の受け付けを行わないと決定していたと想定する。この場合、Handover Requestを受信したeNB２は、その呼を受け付けず（図の"CAG NG"）、ハンドオーバは失敗する。やがてUEとeNB１との間の電波は弱まってゆき、UEとeNB１は通信不能となる（呼損が発生する）。
【００２６】
この問題は例えば震災のときに発生しうる。多くの利用者が利用して輻輳が発生するeNB２と、少ない利用者が利用するeNB１が近接しており、ある利用者が消防機関を呼び出すと想定する。その利用者のUEがVoLTEを利用可能で、まずeNB１にアタッチする場合、利用者が移動しなければ呼が継続するが、利用者とともにUEが移動してeNB２へのハンドオーバが必要となった場合には、呼損が生ずる。
【００２７】
上記の緊急呼通知処理Step6が実行され、緊急音声用デフォルトベアラ確立処理Step7が実行されていれば、この問題は生じない。しかし、緊急音声用デフォルトベアラ確立処理Step7が実行される前に、Handover Requestが送信される場合には、この問題が発生する。
【００２８】
そこで、本発明は、VoLTEの緊急呼に関して一般呼のための音声デフォルトベアラが確立され、緊急呼のための音声用デフォルトベアラが確立される前に、ハンドオーバを実行すべき場合に、この緊急呼のハンドオーバを確実にするハンドオーバ元無線基地局、ハンドオーバ先無線基地局、無線通信システムおよび無線通信方法を提供する。
【課題を解決するための手段】
【００２９】
本発明に係るハンドオーバ元無線基地局は、ユーザ装置から発信されるVoLTE（Voice over LTE）の呼が緊急呼か否かを、ユーザ装置からの発信時のメッセージに基づいて判断する緊急呼判断部と、前記呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティから送信される、前記呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、前記呼に関して一般呼のための音声用デフォルトベアラを確立する一般音声デフォルトベアラ確立部と、前記移動管理エンティティから送信される、前記呼が実際に緊急呼であることを示す第２のベアラ確立要求メッセージに応答して、前記呼に関して緊急呼のための音声用デフォルトベアラを確立する緊急音声デフォルトベアラ確立部と、前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記呼をハンドオーバすべきか否かを判断するハンドオーバ判断部と、前記ハンドオーバ判断部が前記ユーザ装置の前記呼をハンドオーバすべきであると判断する場合に、前記他の無線基地局にハンドオーバ要求を送信するハンドオーバ要求送信部とを備え、前記ハンドオーバ要求送信部は、前記一般音声デフォルトベアラ確立部によって前記一般呼のための音声用デフォルトベアラが確立された後に、前記緊急音声デフォルトベアラ確立部によって前記緊急呼のための音声用デフォルトベアラが確立される前に、前記ハンドオーバ要求を送信するときに、前記緊急呼判断部が前記呼が緊急呼であると判断している場合に、前記ハンドオーバ要求に、前記呼が緊急呼であることを示す情報を含めることを特徴とする。
【００３０】
本発明に係る無線通信方法は、ユーザ装置から発信されるVoLTE（Voice over LTE）の呼が緊急呼か否かを、ハンドオーバ元無線基地局にて、ユーザ装置からの発信時のメッセージに基づいて判断することと、前記呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティから送信される、前記呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、前記ハンドオーバ元無線基地局にて、前記呼に関して一般呼のための音声用デフォルトベアラを確立することと、前記ハンドオーバ元無線基地局にて、前記ユーザ装置からの報告に基づいて、他の無線基地局へ前記ユーザ装置の前記呼をハンドオーバすべきか否かを判断することと、前記ユーザ装置の前記呼をハンドオーバすべきであると判断された場合に、前記ハンドオーバ元無線基地局にて、前記他の無線基地局にハンドオーバ要求を送信することとを備え、前記ハンドオーバ要求を送信することは、前記一般呼のための音声用デフォルトベアラが確立された後に、緊急呼のための音声用デフォルトベアラが確立される前に、前記ハンドオーバ要求を送信するときに、前記呼が緊急呼であると判断されている場合に、前記ハンドオーバ要求に、前記呼が緊急呼であることを示す情報を含めることを有する。
【発明の効果】
【００３１】
本発明においては、呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティ（MME）から送信される、呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、ハンドオーバ元無線基地局にて、呼に関して一般呼のための音声用デフォルトベアラを確立する。しかし、ユーザ装置から発信されるVoLTE（Voice over LTE）の呼が緊急呼か否かを、ハンドオーバ元無線基地局は、ユーザ装置からの発信時のメッセージに基づいて判断する。そして、一般呼のための音声用デフォルトベアラが確立された後に、緊急呼のための音声用デフォルトベアラが確立される前に、ハンドオーバ要求を送信するときに、呼が緊急呼であると判断されている場合に、ハンドオーバ元無線基地局は、ハンドオーバ要求に、呼が緊急呼であることを示す情報を含める。ハンドオーバ先無線基地局は、ハンドオーバ要求に含まれる情報により、ハンドオーバされる呼が緊急呼であることを認識することができる。ハンドオーバされる呼が緊急呼である場合には、ハンドオーバ先無線基地局は、たとえ輻輳が生じていても、この緊急呼のハンドオーバを受け付けることができる。このようにして、本発明では、緊急呼のハンドオーバを確実にすることができる。
【図面の簡単な説明】
【００３２】
【図１】VoLTEを利用可能なUEに対して確立される各種のベアラを示す概略図である。
【図２】VoLTEの一般呼の発信における無線通信ネットワークでの制御手順を示すシーケンス図である。
【図３】VoLTEの緊急呼の発信における無線通信ネットワークでの制御手順を示すシーケンス図である。
【図４】VoLTEの緊急呼の発信におけるハンドオーバの問題を示すシーケンス図である。
【図５】本発明の第１の実施の形態に係るVoLTEの呼の発信における無線通信ネットワークでの制御手順の一部とハンドオーバの手順を示すシーケンス図である。
【図６】本発明の第１の実施の形態に係る無線基地局の構成を示すブロック図である。
【図７】本発明の第１の実施の形態において想定されうるハンドオーバの問題を示すシーケンス図である。
【図８】本発明の第２の実施の形態に係るVoLTEの緊急呼のハンドオーバにおける無線通信ネットワークでの制御手順を示すシーケンス図である。
【発明を実施するための形態】
【００３３】
以下、添付の図面を参照しながら本発明に係る様々な実施の形態を説明する。説明を簡略化するため、図面には、１つのUE、２つのeNB、１つのMMEが示されている。但し、無線通信ネットワークは、もちろん、より多数のeNB、より多数のMMEを有しており、より多数のUEと通信可能である。
【００３４】
第１の実施の形態
図５は、本発明の第１の実施の形態に係るVoLTEの呼の発信における無線通信ネットワークでの制御手順の一部とハンドオーバの手順を示すシーケンス図である。図５に示すように、UEにおいて呼が発信されると、UEは、まずeNB１にアタッチする。UEとeNB１は、RRC Connection確立処理Step11を実行する。RRC Connection確立処理Step11では、UEがeNB１にRRC Connection Requestを送信し、eNB１がUEにRRC Connection Setupをソウシンシ、UEがeNB１にRRC Connection Setup Completeを送信する。
【００３５】
図２および図３に示すRRC Connection確立処理Step1と異なり、図５のRRC Connection確立処理Step11では、UEがeNB１に送信するRRC Connection Request（ユーザ装置からの発信時のメッセージ）に基づいて、eNB１は、UEから発信されるVoLTEの呼が緊急呼か否かを判断する（図の"緊急呼判定"）。具体的には、RRC Connection Requestに含まれる情報要素Establishment Causeが緊急呼であることを示す場合には、eNB１は、呼が緊急呼であると判断し、それ以外の場合には、eNB１は、呼が一般呼であると判断する。
【００３６】
次に、呼が実際に一般呼か緊急呼かに関わらず、UEとeNB１とMMEが音声用デフォルトベアラ確立処理Step2を実行する。音声用デフォルトベアラ確立処理Step2の内容は、図２および図３に示す制御手順の音声用デフォルトベアラ確立処理Step2と同様である。つまり、呼が実際に一般呼か緊急呼かに関わらず、MMEから送信される、優先度レベルが15（つまり一般呼）に設定されている情報要素ARPを含むInitial Context Setup Request（呼が一般呼であることを示す第１のベアラ確立要求メッセージ）に応答して、eNB１は、当該呼に関して一般呼のための音声用デフォルトベアラを確立する。
【００３７】
音声用デフォルトベアラ確立処理Step2でActive遷移後は、UEとeNB１の間で通信が可能であり、UEはMeasurement ReportをeNB１に送信することができる。Measurement Reportは、UEでのUEがアタッチしているeNBから電波の受信品質および他のeNBからの電波の受信品質を示す信号である。UEがeNB１よりもeNB２と通信する方がUEでの受信品質が改善する場合には、eNB１（ハンドオーバ元基地局）はUEのハンドオーバを決定し、そのUEのためにeNB２にHandover Request（ハンドオーバ要求）を送信する。つまり、eNB１は、UEからの報告に基づいて、他のeNBへUEの呼をハンドオーバすべきか否かを判断し、ハンドオーバすべきであると判断する場合に、他のeNBにハンドオーバ要求を送信する。
【００３８】
Active遷移の直後の段階でHandover RequestをeNB１が送信しない場合には、通常の手順を経て、当該呼のためのデディケイテッドベアラが確立されて、音声通信が開始される。つまり、呼が一般呼であれば、図２の制御手順と同様に、SIP手順Step3、音声用デディケイテッドベアラ確立処理Step4、および音声通信開始Step5が実行される。音声用デディケイテッドベアラ確立処理Step4では、呼が実際に一般呼か緊急呼かに関わらず、MMEから送信される、優先度レベルが15（つまり一般呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が一般呼であることを示すベアラ確立要求メッセージ）に応答して、eNB１は、当該呼に関して一般呼のための音声用デディケイテッドベアラを確立する。
【００３９】
Active遷移の直後の段階でHandover RequestをeNB１が送信しない場合には、呼が緊急呼であれば、図３の制御手順と同様に、緊急呼通知処理Step6、緊急音声用デフォルトベアラ確立処理Step7、SIP手順Step8、緊急音声用デディケイテッドベアラ確立処理Step9および音声通信開始Step10が実行される。緊急音声用デフォルトベアラ確立処理Step7では、MMEから送信される、優先度レベルが15以外（つまり緊急呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が実際に緊急呼であることを示す第２のベアラ確立要求メッセージ）に応答して、eNB１は、当該呼に関して緊急呼のための音声用デフォルトベアラを確立する。緊急音声用デディケイテッドベアラ確立処理Step9では、MMEから送信される、優先度レベルが15以外（つまり緊急呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が実際に緊急呼であることを示すベアラ確立要求メッセージ）に応答して、eNB１は、当該呼に関して緊急呼のための音声用デディケイテッドベアラを確立する。
【００４０】
一般呼のための音声用デフォルトベアラが確立された（音声用デフォルトベアラ確立処理Step2）後に、緊急呼のための音声用デフォルトベアラが確立される（緊急音声用デフォルトベアラ確立処理Step7）前に、eNB１がHandover Requestを送信するときに、前記の緊急呼判定において呼が緊急呼であるとeNB１が判断している場合に、eNB１は、そのHandover Requestに、呼が緊急呼であることを明示する情報を含める。呼が緊急呼であることを明示する情報としては、例えばフラグであってもよく、その情報のタイプは限定されない。但し、この情報は、Handover Requestに含まれうる情報要素ARP（優先度レベルを示す）とは別の情報であり、Handover Requestを受信するeNBは、Handover Requestに含まれるARPでは優先度レベルが15（つまり一般呼）に設定されていても、呼が緊急呼であることを明示する情報がHandover Requestに含まれていれば、呼が緊急呼であると認識する。
【００４１】
eNB２（ハンドオーバ先無線基地局）は、Handover Requestの受信の前にeNB２の輻輳のためにCACにおいて一般呼の受け付けを行わないと決定していたと想定する。しかし、eNB２は、Handover Requestに含まれる情報により、ハンドオーバされる呼が緊急呼であることを認識することができる。ハンドオーバされる呼が緊急呼である場合には、eNB２は、たとえ輻輳が生じていても、この緊急呼のハンドオーバを受け付けることができる（図の"CAC OK"）。そして、eNB２はHandover Requestに従って、UEと通信を開始する。このようにして、この実施の形態は、緊急呼のハンドオーバを確実にすることができる。
【００４２】
前記の緊急呼判定において呼が一般呼であるとeNB１が判断している場合に、eNB１は、Handover Requestに、呼が一般呼であることを明示する情報を含めてもよいし、特にそのような情報を含めなくてもよい。つまり、呼が一般呼であれば、Handover Requestは一般呼であることを明示しても暗示してもよい。
【００４３】
CACにおいて一般呼の受け付けを行わないと決定していたeNB２は、呼が緊急呼であることを明示する情報を含まない（呼が一般呼であることを明示または暗示する）Handover Requestを受信すると、この一般呼のハンドオーバの受付を拒否する。このようにして、呼が実際に緊急呼か一般呼かに応じて、ハンドオーバ先無線基地局であるeNB２は適切に呼のハンドオーバを受け入れるべきか否か決定することができる。
【００４４】
図６は、本発明の第１の実施の形態に係る無線基地局（eNB）１０の構成を示すブロック図である。無線基地局１０は、前記のハンドオーバ元無線基地局（eNB１）としても、前記のハンドオーバ先無線基地局（eNB２）としても機能しうる。無線基地局１０は、無線送信部１２、無線受信部１４、基地局間通信インターフェース１６、アクセスポイントインターフェース１８、MMEインターフェース２０および制御部２２を備える。
【００４５】
無線送信部１２はUEに無線信号を送信する無線送信回路であり、無線受信部１４はUEから無線信号を受信する無線受信回路である。基地局間通信インターフェース１６は他のeNBと通信するためのインターフェースである。アクセスポイントインターフェース１８は、SPモード用のアクセスポイント、IMSのアクセスポイントおよびIMS緊急呼のアクセスポイントと通信するためのインターフェースである。MMEインターフェース２０は、MMEと通信するためのインターフェースである。
【００４６】
制御部２２は、緊急呼判断部２２０、ハンドオーバ判断部２２２、ハンドオーバ要求送信部２２４、輻輳判断部２２６およびハンドオーバ制御部２２８を備える。制御部２２は、例えばCPU（central processing unit）であり、コンピュータプログラムに従って動作する。緊急呼判断部２２０、ハンドオーバ判断部２２２、ハンドオーバ要求送信部２２４、輻輳判断部２２６およびハンドオーバ制御部２２８は、制御部２２がコンピュータプログラムに従って機能することによって実現される機能ブロックである。
【００４７】
無線基地局１０がハンドオーバ元無線基地局である場合、緊急呼判断部２２０は、UEがeNB１に送信するRRC Connection Requestに含まれる情報要素Establishment Causeに基づいて、UEから発信されるVoLTEの呼が緊急呼か否かを判断する。
【００４８】
無線基地局１０がハンドオーバ元無線基地局である場合、ハンドオーバ判断部２２２は、UEからの報告（Measurement Report）に基づいて、他のeNBへUEの呼をハンドオーバすべきか否かを判断する。無線基地局１０がハンドオーバ元無線基地局である場合、ハンドオーバ判断部２２２がUEの呼をハンドオーバすべきであると判断する場合に、ハンドオーバ要求送信部２２４は、基地局間通信インターフェース１６を介して他のeNBにHandover Requestを送信する。一般呼のための音声用デフォルトベアラが確立された（音声用デフォルトベアラ確立処理Step2）後に、緊急呼のための音声用デフォルトベアラが確立される（緊急音声用デフォルトベアラ確立処理Step7）前に、ハンドオーバ要求送信部２２４がHandover Requestを送信するときに、緊急呼判断部２２０が呼が緊急呼であると判断している場合に、ハンドオーバ要求送信部２２４はHandover Requestに呼が緊急呼であることを示す情報を含める。
【００４９】
輻輳判断部２２６は、このeNBが輻輳状態であるか否かを判断する。このeNBが輻輳状態であると判断する場合、輻輳判断部２２６は、CACにおいて一般呼の受け付けを行わないと決定する。
【００５０】
基地局間通信インターフェース１６は、他のeNBからHandover Requestを受信するハンドオーバ要求受信部として機能する。無線基地局１０がハンドオーバ先無線基地局である場合、ハンドオーバ制御部２２８が機能する。輻輳判断部２２６がこのeNBが輻輳状態であると判断する場合、かつ呼が緊急呼であることを示す情報を含むHandover Requestを他のeNBから基地局間通信インターフェース１６が受信する場合に、ハンドオーバ制御部２２８は、Handover Requestに従ってUEとの通信を開始する。輻輳判断部２２６がこのeNBが輻輳状態であると判断する場合、かつ呼が緊急呼であることを示す情報を含まないHandover Requestを他のeNBから基地局間通信インターフェース１６が受信する場合に、ハンドオーバ制御部２２８は、Handover Requestを拒否する。
【００５１】
また、制御部２２は、他の要素と協働して、UEのためのベアラ確立処理を実行する。音声用デフォルトベアラ確立処理Step2では、呼が実際に一般呼か緊急呼かに関わらず、MMEから送信される、優先度レベルが15（つまり一般呼）に設定されている情報要素ARPを含むInitial Context Setup Request（呼が一般呼であることを示す第１のベアラ確立要求メッセージ）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して一般呼のための音声用デフォルトベアラをIMSのアクセスポイントとUEの間に確立する。つまり、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、一般音声デフォルトベアラ確立部として機能する。
【００５２】
音声用デディケイテッドベアラ確立処理Step4では、呼が実際に一般呼か緊急呼かに関わらず、MMEから送信される、優先度レベルが15（つまり一般呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が一般呼であることを示すベアラ確立要求メッセージ）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して一般呼のための音声用デディケイテッドベアラをIMSのアクセスポイントとUEの間に確立する。つまり、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、一般音声デディケイテッドベアラ確立部として機能する。
【００５３】
緊急音声用デフォルトベアラ確立処理Step7では、MMEから送信される、優先度レベルが15以外（つまり緊急呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が実際に緊急呼であることを示す第２のベアラ確立要求メッセージ）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して緊急呼のための音声用デフォルトベアラをIMS緊急呼のアクセスポイントとUEの間に確立する。つまり、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、緊急音声デフォルトベアラ確立部として機能する。
【００５４】
緊急音声用デディケイテッドベアラ確立処理Step9では、MMEから送信される、優先度レベルが15以外（つまり緊急呼）に設定されている情報要素ARPを含むE-RAB Setup Request（呼が実際に緊急呼であることを示すベアラ確立要求メッセージ）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して緊急呼のための音声用デディケイテッドベアラをIMS緊急呼のアクセスポイントとUEの間に確立する。つまり、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、緊急音声デディケイテッドベアラ確立部として機能する。
【００５５】
以上の構成において、呼が実際に一般呼か緊急呼かに関わらず、移動管理エンティティ（MME）から送信される呼が一般呼であることを示す第１のベアラ確立要求メッセージに応答して、ハンドオーバ元無線基地局の一般音声デフォルトベアラ確立部は、当該呼に関して一般呼のための音声用デフォルトベアラを確立する。しかし、ユーザ装置から発信されるVoLTEの呼が緊急呼か否かを、ハンドオーバ元無線基地局の緊急呼判断部２２０は、ユーザ装置からの発信時のメッセージ（RRC Connection Request）に基づいて判断する。そして、一般呼のための音声用デフォルトベアラが確立された後に、緊急呼のための音声用デフォルトベアラが確立される前に、Handover Requestを送信するときに、呼が緊急呼であると判断されている場合に、ハンドオーバ元無線基地局のハンドオーバ要求送信部２２４は、Handover Requestに、呼が緊急呼であることを示す情報を含める。ハンドオーバ先無線基地局のハンドオーバ制御部２２８は、Handover Requestに含まれる情報により、ハンドオーバされる呼が緊急呼であることを認識することができる。ハンドオーバされる呼が緊急呼である場合には、ハンドオーバ先無線基地局のハンドオーバ制御部２２８は、たとえ輻輳が生じていても、この緊急呼のハンドオーバを受け付けることができる。このようにして、緊急呼のハンドオーバを確実にすることができる。
【００５６】
第１の実施の形態で起こりうる問題
図７は、本発明の第１の実施の形態において想定されうるハンドオーバの問題を示すシーケンス図である。上記のように、eNB１からeNB２に呼が緊急呼であることを示す情報を含むHandover Requestが送信され、eNB１からeNB２に緊急呼であるVoLTE呼がハンドオーバされたと想定する。そして、呼が緊急呼であることを示す情報をeNB２が持った状態で、UEにて緊急呼が終話したと想定する。
【００５７】
UEでの呼の終話と無線通信ネットワークでの呼の解放は同時ではない。無線通信ネットワークでは、UEで呼が終話しても、その後、ある程度の期間は、呼を解放せずに維持している。この期間の長さは、無線通信ネットワークのオペレータ次第であるが、例えば数分間に及ぶことがある。UEで呼が終話すると、呼を解放するため、UEがアタッチしていたeNB（eNB２）にMMEがE-RAB Release Requestを送信し、eNB２がUEにRRC Connection Reconfigurationを送信し、UEがeNB２にRRC Connection Reconfiguration Completeを送信し、eNB２がMMEにE-RAB Release Responseを送信する。
【００５８】
しかし、呼が解放される前に、UEがデータ発信または一般の音声呼を発信すると想定する。この場合、呼が解放されていないため、呼が終結していても、eNB２は新規な呼を受け付ける。さらに、UEとeNB２の間で通信が可能であるため、UEはMeasurement ReportをeNB２に送信することができる。UEがeNB２よりも他のeNB（例えばeNB１）と通信する方がUEでの受信品質が改善する場合には、eNB２はUEのハンドオーバを決定し、そのUEのために他のeNB（例えばeNB１）にHandover Requestを送信する。eNB１がHandover Requestを受け付ければ、UEはeNB１にアタッチし、その呼が継続することになる。
【００５９】
eNB１は、Handover Requestの受信の前にeNB１の輻輳のために、CACにおいて一般呼の受け付けを行わないと決定していたと想定する。もしも、このHandover Requestに、ハンドオーバされるべき呼が緊急呼であることを示す情報が含まれている場合には、たとえ実際にはこの呼がデータの呼または一般の音声呼であったとしても、eNB１はこの呼を緊急呼として取り扱い、UEはeNB１にアタッチし、その呼が継続してしまう。つまり、緊急呼であることを示す情報をeNBが常に保持していて、Handover Requestに緊急呼であることを示す情報を含めると、そのHandover Requestに係る呼が実際に緊急呼ではなくても、ハンドオーバが成立してしまう。
【００６０】
実際にはその呼は緊急呼ではないため、このような取り扱いは他のユーザに対して不公平である。緊急呼は優遇されるべきであるが、緊急呼を終結した直後に発信したデータの呼または一般の音声呼まで優遇すべきではない。このような取り扱いが許容されると、ユーザが緊急呼を発信し、緊急呼を終結し、すぐにデータの呼または一般の音声呼を発信すると、呼を確立することができてしまう。下記に説明する第２の実施の形態はこの問題を解決する。
【００６１】
第２の実施の形態
図８は、本発明の第２の実施の形態に係るVoLTEの緊急呼のハンドオーバにおける無線通信ネットワークでの制御手順を示すシーケンス図である。第１の実施形態と同様に、図５の音声用デフォルトベアラ確立処理Step2の後に、eNB１からeNB２に緊急呼であるVoLTE呼をハンドオーバするために、eNB１からeNB２に呼が緊急呼であることを示す情報を含むHandover Requestが送信されると想定する。
【００６２】
この後、緊急音声用デフォルトベアラ確立処理Step17が実行される。ここでは、MMEがeNB２にE-RAB Setup Requestを送信し、eNB２がUEにRRC Connection Reconfigurationを送信し、UEがeNB２にRRC Connection Reconfiguration Completeを送信し、eNB２がMMEにE-RAB Setup Responseを送信する。緊急音声用デフォルトベアラ確立処理Step7により、eNB２を経由してUEとIMS緊急呼のアクセスポイントの間にデフォルトベアラが確立される。緊急音声用デフォルトベアラ確立処理Step17で、MMEがeNB２に送信するE-RAB Setup Request（第３のベアラ確立要求メッセージ）に含まれる情報要素ARPでは優先度レベルが15以外（つまり緊急呼）に設定されている。これは、MMEおよびより上位の装置は、ハンドオーバされる呼が実際に緊急呼か一般呼かを既に把握しているからである。
【００６３】
緊急音声用デフォルトベアラ確立処理Step17において、E-RAB Setup Requestを受信すると、eNB２は呼が緊急呼であることを示す情報を無効化する。無効化の態様としては、例えば、eNB２のメモリ（図示せず）に記憶されている当該情報を削除すること、およびその他の無効化が考えられる。
【００６４】
次に、eNB２経由でUEとIMS緊急呼のアクセスポイントの間に設定されたデフォルトベアラを利用して、SIP手順Step18が実行される。さらに、緊急音声用デディケイテッドベアラ確立処理Step19が実行される。ここでは、MMEがeNB２にE-RAB Setup Requestを送信し、eNB２がUEにRRC Connection Reconfigurationを送信し、UEがeNB２にRRC Connection Reconfiguration Completeを送信し、eNB２がMMEにE-RAB Setup Responseを送信する。緊急音声用デディケイテッドベアラ確立処理Step19で、MMEがeNB２に送信するE-RAB Setup Request（第４のベアラ確立要求メッセージ）に含まれる情報要素ARPでは優先度レベルが15以外（つまり緊急呼）に設定されている。緊急音声用デディケイテッドベアラ確立処理Step19により、eNB２経由でUEとIMS緊急呼のアクセスポイントの間にデディケイテッドベアラが確立される。以降、eNB２経由でVoLTEによる音声通信が可能となる。このようにして、eNB１からeNB２に緊急呼であるVoLTE呼がハンドオーバされる。
【００６５】
そして、UEにて緊急呼が終話したと想定する。UEで呼が終話すると、呼を解放するため、UEがアタッチしていたeNB（eNB２）にMMEがE-RAB Release Requestを送信し、eNB２がUEにRRC Connection Reconfigurationを送信し、UEがeNB２にRRC Connection Reconfiguration Completeを送信し、eNB２がMMEにE-RAB Release Responseを送信する。
【００６６】
呼が解放される前に、UEがデータ発信または一般の音声呼を発信すると想定する。この場合、呼が解放されていないため、呼が終結していても、eNB２は新規な呼を受け付ける。さらに、UEとeNB２の間で通信が可能であるため、UEはMeasurement ReportをeNB２に送信することができる。UEがeNB２よりも他のeNB（例えばeNB１）と通信する方がUEでの受信品質が改善する場合には、eNB２はUEのハンドオーバを決定し、そのUEのために他のeNB（例えばeNB１）にHandover Request（第２のハンドオーバ要求）を送信する。eNB１がHandover Requestを受け付ければ、UEはeNB１にアタッチし、その呼が継続することになる。
【００６７】
eNB１は、Handover Requestの受信の前にeNB１の輻輳のために、CACにおいて一般呼の受け付けを行わないと決定していたと想定する。もしも、このHandover Requestに、ハンドオーバされるべき呼が緊急呼であることを示す情報が含まれている場合には、たとえ実際にはこの呼がデータの呼または一般の音声呼であったとしても、eNB１はこの呼を緊急呼として取り扱い、UEはeNB１にアタッチし、その呼が継続してしまう。
【００６８】
しかし、この実施の形態では、緊急音声用デフォルトベアラ確立処理Step17において、既に受信していたE-RAB Setup Requestが直前の呼が実際に緊急呼であることを示している場合に、eNB２は直前の呼が緊急呼であることを示す情報を無効化する。eNB２が緊急呼の情報を無効化しているので、直前の呼が終結した後に、Handover Request（第２のハンドオーバ要求）を送信するときに、eNB２は、Handover Request（第２のハンドオーバ要求）に、新規な呼が緊急呼であることを示す情報を含めない。eNB２は、Handover Requestに、呼が一般呼であることを明示する情報を含めてもよい。つまり、Handover Requestは一般呼であることを明示しても暗示してもよい。
【００６９】
CACにおいて一般呼の受け付けを行わないと決定していたeNB１は、呼が緊急呼であることを明示する情報を含まない（呼が一般呼であることを明示または暗示する）Handover Requestを受信すると、この新規な呼（データの呼または一般の音声呼）のハンドオーバの受付を拒否する。したがって、第２の実施の形態によれば、緊急呼を終結した直後に発信したデータの呼または一般の音声呼がハンドオーバにおいて優遇されるというおそれを排除することができる。
【００７０】
eNB２がハンドオーバされた緊急呼を取り扱うとき、eNB２は、緊急音声用デフォルトベアラ確立処理Step17において、呼（直前の呼）が緊急呼であることを示す音声用デフォルトベアラのための第３のベアラ確立要求メッセージ（E-RAB Setup Request）をMMEから受信し、緊急音声用デディケイテッドベアラ確立処理Step19において、呼（直前の呼）が緊急呼であることを示す音声用デディケイテッドベアラのための第４のベアラ確立要求メッセージ（E-RAB Setup Request）をMMEから受信する。呼が緊急呼であることを示す情報を無効化するトリガーは、第３のベアラ確立要求メッセージの受信でもよいし、第４のベアラ確立要求メッセージの受信でもよい。
【００７１】
しかし、緊急音声用デディケイテッドベアラ確立処理Step19の前、かつ緊急音声用デフォルトベアラ確立処理Step17の後に、新規な呼（データの呼または一般の音声呼）のハンドオーバのためにHandover RequestをeNB２が送信する事態がありえる。このHandover Requestに新規な呼が緊急呼であることを示す情報を含めないようにするためには、緊急音声用デフォルトベアラ確立処理Step17で受信される第３のベアラ確立要求メッセージ（E-RAB Setup Request）に応じて、呼が緊急呼であることを示す情報を無効化することが好ましい。
【００７２】
第２の実施の形態に係る無線基地局（eNB）の構成は図６に示される構成と同じでよい。無線基地局１０は、前記のハンドオーバ元無線基地局（eNB１）としても、前記のハンドオーバ先無線基地局（eNB２）としても機能しうる。
【００７３】
無線基地局１０がハンドオーバ先無線基地局である場合、基地局間通信インターフェース１６は、ハンドオーバ元無線基地局からHandover Requestを受信するハンドオーバ要求受信部として機能する。無線基地局１０がハンドオーバ先無線基地局である場合、MMEインターフェース２０は、Handover Requestをハンドオーバ要求受信部が受信した後に、MMEから送信されるベアラ確立要求メッセージ（緊急音声用デフォルトベアラ確立処理Step17および緊急音声用デディケイテッドベアラ確立処理Step19のE-RAB Setup Request）を受信するベアラ確立要求メッセージ受信部として機能する。
【００７４】
緊急音声用デフォルトベアラ確立処理Step17では、第３のベアラ確立要求メッセージ（E-RAB Setup Request）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して緊急呼のための音声用デフォルトベアラをIMSのアクセスポイントとUEの間に確立する。緊急音声用デディケイテッドベアラ確立処理Step19では、第４のベアラ確立要求メッセージ（E-RAB Setup Request）に応答して、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、当該呼に関して緊急呼のための音声用デディケイテッドベアラをIMSのアクセスポイントとUEの間に確立する。つまり、制御部２２、無線送信部１２、無線受信部１４およびアクセスポイントインターフェース１８は、ベアラ確立部として機能する。
【００７５】
制御部２２は、直前の呼が終結した後でも、終結した呼に係るUEから新規な呼が発信されると、新規な呼を受け付ける新規呼受付部として機能する。ハンドオーバ判断部２２２は、UEからの報告に基づいて、他のeNBへUEの新規呼をハンドオーバすべきか否かを判断する第２のハンドオーバ判断部として機能する。ハンドオーバ要求送信部２２４は、第２のハンドオーバ判断部がUEの新規な呼をハンドオーバすべきであると判断する場合に、他のeNBにHandover Request（第２のハンドオーバ要求）を送信する第２のハンドオーバ要求送信部として機能する。
【００７６】
第２のハンドオーバ要求送信部であるハンドオーバ判断部２２２は、直前の呼が終結した後に、第２のハンドオーバ要求を送信するときに、ベアラ確立要求メッセージ受信部（MMEインターフェース２０）がMMEから受信したベアラ確立要求メッセージ（E-RAB Setup Request、特に好ましくは緊急音声用デフォルトベアラ確立処理Step17でのE-RAB Setup Request）が直前の呼が実際に緊急呼であることを示している場合に、第２のハンドオーバ要求に新規な呼が緊急呼であることを示す情報を含めない。この目的のため、制御部２２は、MMEから受信したベアラ確立要求メッセージ（E-RAB Setup Request、特に好ましくは緊急音声用デフォルトベアラ確立処理Step17でのE-RAB Setup Request）が直前の呼が実際に緊急呼であることを示している場合に、呼が緊急呼であることを示す情報を無効化する。
【００７７】
無線基地局１０がハンドオーバ先無線基地局である場合、輻輳判断部２２６は、ハンドオーバ先無線基地局が輻輳状態であるか否かを判断する第１の輻輳判断部として機能する。ハンドオーバ制御部２２８は、第１の輻輳判断部がハンドオーバ先無線基地局が輻輳状態であると判断する場合、かつ呼が緊急呼であることを示す情報をHandover Requestが含む場合に、Handover Requestに従ってUEとの通信を開始し、第１の輻輳判断部がハンドオーバ先無線基地局が輻輳状態であると判断する場合、かつ呼が緊急呼であることを示す情報をHandover Requestが含まない場合に、Handover Requestを拒否する第１のハンドオーバ制御部として機能する。
【００７８】
無線基地局１０が他の無線基地局である場合、輻輳判断部２２６は、この無線基地局が輻輳状態であるか否かを判断する第２の輻輳判断部として機能し、基地局間通信インターフェース１６は、ハンドオーバ先無線基地局（eNB２）から第２のハンドオーバ要求（Handover Request）を受信する第２のハンドオーバ要求受信部として機能する。ハンドオーバ制御部２２８は、第２の輻輳判断部がこの無線基地局が輻輳状態であると判断する場合、かつ新規呼が緊急呼であることを示す情報を第２のハンドオーバ要求が含む場合に、第２のハンドオーバ要求に従ってUEとの通信を開始し、第２の輻輳判断部がこの無線基地局が輻輳状態であると判断する場合、かつ新規呼が緊急呼であることを示す情報を第２のハンドオーバ要求が含まない場合に、第２のハンドオーバ要求を拒否する第２のハンドオーバ制御部として機能する。
【００７９】
以上の構成において、第１の実施の形態と同様の効果が達成される。また、直前の呼が終結した後でも、UEから発信された新規な呼をeNBが受け付けて、eNBが他のeNBに第２のハンドオーバ要求を送信するときに、MMEから受信したベアラ確立要求メッセージが直前の呼が実際に緊急呼であることを示している場合に、eNBは第２のハンドオーバ要求に新規な呼が緊急呼であることを示す情報を含めない。第２のハンドオーバ要求を受信する無線基地局のハンドオーバ制御部２２８は、第２のハンドオーバ要求により、ハンドオーバされる呼が一般呼であることを認識することができる。したがって、緊急呼を終結した直後に発信したデータの呼または一般の音声呼がハンドオーバにおいて優遇されるというおそれを排除することができる。
【００８０】
他の変形
eNBにおいて、ＣＰＵが実行する各機能は、ＣＰＵの代わりに、ハードウェアで実行してもよいし、例えばFPGA（Field Programmable Gate Array），DSP（Digital Signal Processor）等のプログラマブルロジックデバイスで実行してもよい。
【符号の説明】
【００８１】
１，２，１０  eNB（無線基地局）、
１２  無線送信部（一般音声デフォルトベアラ確立部、緊急音声デディケイテッドベアラ確立部、ベアラ確立部）、
１４  無線受信部（一般音声デフォルトベアラ確立部、緊急音声デディケイテッドベアラ確立部、ベアラ確立部）、
１６  基地局間通信インターフェース（ハンドオーバ要求受信部、第２のハンドオーバ要求受信部）、
１８  アクセスポイントインターフェース（一般音声デフォルトベアラ確立部、緊急音声デディケイテッドベアラ確立部、ベアラ確立部）、
２０  MMEインターフェース（ベアラ確立要求メッセージ受信部）、
２２  制御部（一般音声デフォルトベアラ確立部、緊急音声デディケイテッドベアラ確立部、ベアラ確立部、新規呼受付部）、
２２０  緊急呼判断部、
２２２  ハンドオーバ判断部（第２のハンドオーバ判断部）、
２２４  ハンドオーバ要求送信部（第２のハンドオーバ要求送信部）、
２２６  輻輳判断部（第１の輻輳判断部、第２の輻輳判断部）、
２２８  ハンドオーバ制御部（第１のハンドオーバ制御部、第２のハンドオーバ制御部）。
【要約】
【課題】VoLTEの緊急呼に関して一般呼のための音声デフォルトベアラが確立され、緊急呼のための音声用デフォルトベアラが確立される前に、ハンドオーバを実行するべき場合に、この緊急呼のハンドオーバを確実にする。
【解決手段】無線基地局は、ユーザ装置から発信されるVoLTEの呼が緊急呼か否かを、ユーザ装置からの発信時のメッセージに基づいて判断する。無線基地局は、他の無線基地局にハンドオーバ要求を送信するハンドオーバ要求送信部を備え、ハンドオーバ要求送信部は、一般呼のための音声用デフォルトベアラが確立された後に、緊急呼のための音声用デフォルトベアラが確立される前に、ハンドオーバ要求を送信するときに、呼が緊急呼であると判断している場合に、ハンドオーバ要求に呼が緊急呼であることを示す情報を含める。
【選択図】図５【図１】
0005412566.tif 000002
【図２】
0005412566.tif 000003
【図３】
0005412566.tif 000004
【図４】
0005412566.tif 000005
【図５】
0005412566.tif 000006
【図６】
0005412566.tif 000007
【図７】
0005412566.tif 000008
【図８】
0005412566.tif 000009