"移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、前記基地局は、前記移動局とのRRCコネクションを確立する手段と、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第1の送信手段と、前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第2の送信手段と、を有し、前記ゲートウェイ装置は、前記基地局から、前記登録メッセージを受信する第1の受信手段と、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第2の受信手段と、前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行するチェック手段と、を有し、前記チェック手段によるチェックに基づいて、前記緊急呼の処理を行う、移動通信システム。前記チェック手段によるチェックは、前記登録メッセージに含まれるRegistrationCauseがEmergencyCallであることを示す場合に実行される、請求項1に記載の移動通信システム。移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、前記基地局と前記移動局とのRRCコネクションを確立し、前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行し、前記一貫性のチェックに基づいて、前記緊急呼の処理を行う、通信方法。前記チェックは、前記登録メッセージに含まれるRegistrationCauseがEmergencyCallであることを示す場合に実行される、請求項3に記載の通信方法。ゲートウェイ装置と、前記ゲートウェイ装置に接続する基地局と、を有する無線通信システムの移動局であって、前記基地局とのRRCコネクションを確立する手段と、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージ及び前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記通信コネクションを介して前記基地局に送信する手段と、を有し、前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックが、前記登録メッセージと前記確立メッセージとを受信する前記ゲートウェイ装置によって実行され、前記チェックに基づいて前記緊急呼の処理が行われる、移動局。ところで、上述した技術は、移動局10が緊急呼として発呼を行った場合には、HNB-GW30のアクセス規制をスキップし、移動局10によるHNB20へのアクセスを許可するものである。そのため、不正移動局10-2のように、本来はHNB20へアクセスできない移動局10であっても、RRCプロトコルにおける、EstablishmentCauseパラメータをEmergencycallと偽り、HNB-GW30のアクセス規制の対象外となることによって、HNB20へのアクセスが可能となってしまう。このような不正移動局10-2は、EstablishmentCauseパラメータのみを改ざんするようにソフトウェアを改造することによって、容易に作ることができると考えられる。あるいは、正当な移動局10-1から共通チャネルRACH:RandomAccessChannel上に送信される、秘匿も改ざん対策もされていないRRC:RRCCONNECTIONREQUESTメッセージをデコードし、EstablishmentCauseパラメータをEmergencycallに置き換えて、RRC:RRCCONNECTIONREQUESTメッセージをエンコードしてHNB20に送信する装置が介在する場合もある。この場合、正当な移動局10-1であっても、上述のような不正移動局10-2と同視されることになる。このような不正移動局10-2により、以下のような問題が生じる。1家庭用あるいは企業に設置されたHNB20が、不正移動局10-2により不正に使用されてしまう2不正移動局10-2は、HNB20を介した発信を行うことによって、通常の課金サービスよりも安い課金サービスを不正に受けることができてしまう3特定のユーザ向けへのコンテンツサービスを不正移動局10-2が不正に受けてしまうこのような問題を解決する方法としては、移動局10が緊急呼として発呼を行った場合に、コアネットワーク装置側で、その移動局10の呼解放処理を行うことが考えられる。そのためには、コアネットワーク装置は、移動局10が緊急呼として発呼を行ったことを知る必要がある。しかし、現状の構成では、コアネットワーク装置は、移動局10が緊急呼として発呼を行ったことを知ることができない。あるいは、HNB-GW30側で、緊急呼と偽って発呼を行った移動局10の呼解放処理を行うことも考えられる。そのためには、HNB-GW30は、移動局10が実際に発呼した呼種別が緊急呼であるかを知る必要がある。しかし、現状の構成では、HNB-GW30は、移動局10が実際に発呼した呼種別を知ることができない。本発明の目的は、コアネットワーク装置が、移動局が緊急呼として発呼を行ったことを知ることができる移動通信システムを提供することにある。本発明の他の目的は、ゲートウェイ装置が、移動局が実際に発呼した呼種別を知ることができる移動通信システムを提供することにある。本発明の移動通信システムは、移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、前記基地局は、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第1の送信手段と、前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第2の送信手段と、を有し、前記ゲートウェイ装置は、前記基地局から、前記登録メッセージを受信する第1の受信手段と、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第2の受信手段と、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、を有する。本発明のゲートウェイ装置は、基地局を、コアネットワークに接続するゲートウェイ装置であって、移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信する第1の受信手段と、前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信する第2の受信手段と、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、を有する。本発明の第1の通信方法は、移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。本発明の第2の通信方法は、基地局を、コアネットワークに接続するゲートウェイ装置による通信方法であって、移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信し、前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信し、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。本発明の第1の移動通信システムによれば、基地局あるいはゲートウェイ装置は、移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めて、コアネットワーク装置に送信する。したがって、コアネットワーク装置は、移動局が緊急呼として発呼を行ったことを知ることができるという効果が得られる。本発明の第2の移動通信システムによれば、コアネットワーク装置は、移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めて、ゲートウェイ装置に送信する。したがって、ゲートウェイ装置は、移動局が実際に発呼した呼種別が緊急呼であることを知ることができるという効果が得られる。以下に、本発明を実施するための最良の形態について図面を参照して説明する。なお、以下で説明する実施形態において、移動通信システムの全体構成自体は、図1の移動通信システムと同様であるとする。第1の実施形態図7~図10に、本実施形態のHNB20、HNB-GW30、MSC40、およびSGSN50の構成をそれぞれ示す。図7を参照すると、本実施形態のHNB20は、移動局10が緊急呼として発呼を行ったことを示す情報をRANAPRadioAccessNetworkApplicationPartプロトコルメッセージに含める制御部21Aと、そのRANAPプロトコルメッセージをHNB-GW30に送信する送信部22Aと、を有している。なお、RANAPプロトコルメッセージとは、無線アクセスネットワークのアプリケーション層のメッセージであり、例えば、UEとコアネットワーク装置間で送受信されるCC/MM信号をRAN内で透過的に転送する昨日を有するものである。また、図8を参照すると、本実施形態のHNB-GW30は、HNB20からRANAPプロトコルメッセージを受信する受信部31Aと、そのRANAPプロトコルメッセージを取り出す制御部32Aと、そのRANAPプロトコルメッセージをMSC40あるいはSGSN50に送信する送信部33Aと、を有している。また、図9を参照すると、本実施形態のMSC40は、HNB-GW30からRANAPプロトコルメッセージを受信する受信部41Aと、そのRANAPプロトコルメッセージに移動局10が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を行う制御部42Aと、を有している。また、図10を参照すると、本実施形態のSGSN50は、HNB-GW30からRANAPプロトコルメッセージを受信する受信部51Aと、そのRANAPプロトコルメッセージに移動局10が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を実施する制御部52Aと、を有している。したがって、本実施形態においては、MSC40あるいはSGSN50が、移動局10が緊急呼として発呼を行ったことを知ることができる。その結果、MSC40あるいはSGSN50は、移動局10がEstablishmentCauseを改ざんして緊急呼と偽っていた場合には、その移動局10の呼解放処理を実施することができるため、HNB20によるサービスを不正に受けることを防止することができる。第2の実施形態図11~図14に、本実施形態のHNB20、HNB-GW30、MSC40、およびSGSN50の構成をそれぞれ示す。本実施形態は、図7~図10の第1の実施形態のHNB20、HNB-GW30、MSC40、およびSGSN50の構成および動作をより具体化した例である。図11を参照すると、本実施形態のHNB20は、対移動局信号送受信部201Aと、RUARANAPUserAdaptionメッセージ処理部202Aと、対HNB-GW信号送受信部203Aと、HNBAPメッセージ処理部204Aと、呼制御部205Aと、RRCメッセージ処理部206Aと、RANAPメッセージ処理部207Aと、を有している。なお、図11においては、RUAメッセージ処理部202A、HNBAPメッセージ処理部204A、呼制御部205A、RRCメッセージ処理部206A、およびRANAPメッセージ処理部207Aにより、図7に示した制御部21Aを構成している。また、対HNB-GW信号送受信部203Aは、図7に示した送信部22Aの一例である。対移動局信号送受信部201Aは、移動局10との間でRRCプロトコルメッセージを送受信するための機能として、メッセージを秘匿暗号化、復号化する秘匿機能、メッセージの送達を確認する信号送達確認機能、メッセージを分配する信号分配機能等を有している。対HNB-GW信号送受信部203Aは、HNB-GW30との間でHNBAPプロトコルメッセージやRUAプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能、信号分配機能等を有している。RRCメッセージ処理部206Aは、移動局10へ送信するRRCプロトコルメッセージをエンコードする機能、および、移動局10から受信するRRCプロトコルメッセージをデコードする機能を有している。HNBAPメッセージ処理部204Aは、HNB-GW30へ送信するHNBAPプロトコルメッセージをエンコードする機能、および、HNB-GW30から受信するHNBAPプロトコルメッセージをデコードする機能を有している。RANAPメッセージ処理部207Aは、HNB-GW30へ送信するRANAPメッセージをエンコードする機能、および、HNB-GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。RUAプロトコルは、RANAPプロトコルメッセージを転送する働きをするプロトコルであり、RUAメッセージ処理部202Aは、HNB-GW30に送信するRUAプロトコルメッセージをエンコードする機能、および、HNB-GW30から受信するRUAプロトコルメッセージをデコードする機能を有している。呼制御部205Aは、RRCプロトコルメッセージやRANAPプロトコルメッセージを基に、RRCコネクションの確立、ベアラの確立、移動制御などの様々な呼処理を起動する。さらに、呼制御部205Aは、HNBAPプロトコルを起動して、HNB-GW30への移動局10の登録処理を実施する。以上の機能は、HNB20に実装される呼処理部が一般に有する機能である。その他にも、呼制御部205Aは、本実施形態の特徴的な機能として、HNB-GW30から受信したHNBAPプロトコルメッセージのRegistrationCauseパラメータを基に、HNB-GW30に送信するRANAPプロトコルメッセージのEmergencyCause値を設定する機能を有している。また、図12を参照すると、本実施形態のHNB-GW30は、対HNB信号送受信部301Aと、RUAメッセージ処理部302Aと、対SGSN信号送受信部303Aと、対MSC信号送受信部304Aと、HNBAPメッセージ処理部305Aと、呼制御部306Aと、RANAPメッセージ処理部307Aと、局データ格納部308Aと、を有している。なお、図12においては、RUAメッセージ処理部302A、HNBAPメッセージ処理部305A、呼制御部306A、RANAPメッセージ処理部307A、および局データ格納部308Aにより、図8に示した制御部32Aを構成している。また、対HNB信号送受信部301Aは、図8に示した受信部31Aの一例であり、また、対SGSN信号送受信部303Aおよび対MSC信号送受信部304Aは、図8に示した送信部33Aの一例である。対HNB信号送受信部301Aは、HNB20との間でRUAプロトコルメッセージやHNBAPプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能等を有している。対MSC信号送受信部304Aは、MSC40との間でRANAPプロトコルメッセージの送受信を行うための機能として、メッセージの順序を制御する順序制御機能、送達確認機能等を有している。対SGSN信号送受信部303Aは、SGSN50との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。HNBAPメッセージ処理部305Aは、HNB20へ送信するHNBAPプロトコルメッセージをエンコードする機能、および、HNBから受信するHNBAPプロトコルメッセージをデコードする機能を有している。RUAメッセージ処理部302Aは、HNB20へ送信するRUAプロトコルメッセージをエンコードする機能、および、HNB20から受信するRUAプロトコルメッセージをデコードする機能を有している。RANAPメッセージ処理部307Aは、MSC40に送信するRANAPプロトコルメッセージをエンコードする機能、および、MSC40から受信するRANAPプロトコルメッセージをデコードする機能を有している。呼制御部306Aは、HNB103の登録処理や、移動局10の登録処理を行う。また、呼制御部306Aは、局データ格納部308Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、HNB-GW30は、HNB20へのアクセス規制を実施する。以上の機能は、HNB-GW30に実装される呼処理部が一般に有する機能である。また、図13を参照すると、本実施形態のMSC40は、対HNB-GW信号送受信部401Aと、RANAPメッセージ処理部402Aと、NASNonAccessStratumメッセージ処理部403Aと、呼制御部404Aと、局データ格納部405Aと、を有している。なお、図13においては、RANAPメッセージ処理部402A、NASメッセージ処理部403A、呼制御部404A、および局データ格納部405Aにより、図9に示した制御部42Aを構成している。また、対HNB-GW信号送受信部401Aは、図9に示した受信部41Aの一例である。対HNB-GW信号送受信部401Aは、HNB-GW30との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。RANAPメッセージ処理部402Aは、HNB-GW30に送信するRANAPメッセージをエンコードする機能、および、HNB-GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。NASメッセージ処理部403Aは、移動局10との間でNASプロトコルCCCallControlプロトコル、MMMobilityManagementプロトコルのメッセージの送受信を行うための機能を有している。呼制御部404Aは、呼確立、呼解放などの呼処理を行う呼処理機能や、位置登録やハンドオーバなどの移動制御を行う移動制御機能、さらに、HNB20へのアクセスを規制するアクセス規制機能を有している。呼制御部404Aは、局データ格納部405Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、MSC40は、HNB20へのアクセス規制を実施する。以上の機能は、MSC40に実装される呼処理部が一般に有する機能である。その他にも、呼制御部404Aは、本実施形態の特徴的な機能として、HNB-GW30から受信するRANAPプロトコルメッセージにEmergencyCauseパラメータが設定されている場合に、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部404Aは、呼解放処理を行うことになる。また、図14を参照すると、本実施形態のSGSN50は、対HNB-GW信号送受信部501Aと、RANAPメッセージ処理部502Aと、NASメッセージ処理部503Aと、呼制御部504Aと、局データ格納部505Aと、を有している。なお、図14においては、RANAPメッセージ処理部502A、NASメッセージ処理部503A、呼制御部504A、および局データ格納部505Aにより、図10に示した制御部52Aを構成している。また、対HNB-GW信号送受信部501Aは、図10に示した受信部51Aの一例である。対HNB-GW信号送受信部501Aは、HNB-GW30との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。RANAPメッセージ処理部502Aは、HNB-GW30に送信するRANAPメッセージをエンコードする機能、および、HNB-GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。NASメッセージ処理部503Aは、移動局10との間でNASプロトコルCCプロトコル、MMプロトコルのメッセージの送受信を行うための機能を有している。呼制御部504Aは、呼処理機能や移動制御機能、さらに、アクセス規制機能を有している。呼制御部504Aは、局データ格納部505Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、SGSN50は、HNB20へのアクセス規制を実施する。以上の機能は、SGSN50に実装される呼処理部が一般に有する機能である。その他にも、呼制御部504Aは、本実施形態の特徴的な機能として、HNB-GW30から受信するRANAPプロトコルメッセージにEmergencyCauseパラメータが設定されている場合に、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部504Aは、呼解放処理を行うことになる。以下に、本実施形態の移動通信システムの動作について説明する。A回線交換呼の場合まず、移動局10が回線交換の緊急呼として発呼を行った場合の動作例を、図15のシーケンス図に沿って説明する。図15を参照すると、移動局10は、ステップS101において、EstablishmentCause図4をRRC:RRCCONNECTIONREQUESTメッセージ図2に設定し、ステップS102において、そのRRC:RRCCONNECTIONREQUESTメッセージをHNB20に送信する。HNB20は、無線リソースを確保した後、ステップS103において、その旨をRRC:RRCCONNECTIONSETUPメッセージにて移動局10に通知する。移動局10は、RRCコネクションを確立した後、ステップS104において、その旨をRRC:RRCCONNECTIONSETUPCOMPLETEメッセージにてHNB20に通知する。続いて、移動局10は、ステップS105において、MMプロトコルメッセージであるCMSERVICEREQUESTメッセージ図16のCMServiceTypeパラメータ図17をEmergencycallestablishmentと設定し、そのCMSERVICEREQUESTメッセージをRRC:INITIALDIRECTTRANSFERメッセージ図3に含める。さらに、移動局10は、ステップS106において、そのRRC:INITIALDIRECTTRANSFERメッセージのEstablishmentCause図4をEmergencyCallと設定し、そのRRC:INITIALDIRECTTRANSFERメッセージ図3をHNB20に送信する。HNB20では、RRCプロトコルメッセージ処理部707Aは、ステップS102で送信されてきたRRC:RRCCONNECTIONREQUESTメッセージおよびステップS106で送信されてきたRRC:INITIALDIRECTTRANSFERメッセージをデコードする。また、HNB20では、呼制御部205Aは、移動局10から、RRC:RRCCONNECTIONREQUESTメッセージおよびRRC:INITIALDIRECTTRANSFERメッセージにて通知されたEstablishmentCause値図4を保存しておき、ステップS107において、EstablishmentCause値を基に、RegistrationCauseパラメータを決定し、HNBAP:UEREGISTERREQUESTメッセージ図5に設定する。図18に、RegistrationCauseパラメータの決定処理のフローチャートを示す。図18を参照すると、呼制御部205Aは、ステップS201において、EstablishmentCause値がEmergencyCallであるか判断し、EmergencyCallである場合は、ステップS202において、RegistrationCauseパラメータをEmergencyCallと決定し、EmergencyCallでない場合は、ステップS203において、RegistrationCauseパラメータをNormalCallと決定する。再度図15を参照すると、HNB20は、ステップS108において、RegistrationCauseパラメータを設定したHNBAP:UEREGISTERREQUESTメッセージ図5をHNB-GW30に送信する。HNB-GW30では、対HNB信号送受信部301Aは、HNBAP:UEREGISTERREQUESTメッセージを受信し、HNBAPメッセージ処理部305Aは、HNBAP:UEREGISTERREQUESTメッセージをデコードし、呼制御部306Aは、ステップS109において、HNBAP:UEREGISTERREQUESTメッセージに設定されているRegistrationCauseパラメータを基に、アクセス規制ステップS110を実施するかどうかを判断する。HNB-GW30では、RegistrationCauseパラメータがEmergencyCallであれば、アクセス規制をしない。この場合、呼制御部306Aは、該当する移動局10に対してコンテキストIDを割り当て、HNBAPメッセージ処理部305Aは、HNBAP:UEREGISTERACCEPTメッセージをエンコードし、対HNB信号送受信部301Aは、ステップS111において、そのHNBAP:UEREGISTERACCEPTメッセージをHNB20に送信する。HNB20では、呼制御部205Aは、HNBAP:UEREGISTERACCEPTメッセージの受信後、ステップS112において、RegistrationCauseパラメータがEmergencyCallであるか判断し、EmergencyCallであれば、ステップS113において、本発明によって導入されるEmergencyCauseパラメータ図19を生成する。RANAPメッセージ処理部207Aは、EmergencyCauseパラメータを含むRANAP:INITIALUEMESSAGEメッセージのエンコードを行う。さらに、RANAPメッセージ処理部207Aは、RANAP:INITIALUEMESSAGEメッセージにNAS-PDUProtocolDataUnitパラメータを設定し、NAS-PDUパラメータには、移動局10から受信したMMプロトコルのCMSERVICEREQUESTメッセージを設定する。RUAメッセージ処理部703Aは、そのRANAP:INITIALUEMESSAGEメッセージを含むRUA:CONNECTメッセージを生成する。すなわち、RANAP:INITIALUEMESSAGEメッセージは、ステップS114において、HNB20からHNB-GW30に対して、RUA:CONNECTメッセージによって転送される。HNB-GW30では、RUAメッセージ処理部302Aは、RUAプロトコルのCONNECTメッセージをデコードし、呼制御部306Aは、HNB20で既にエンコードされているRANAP:INITIALUEMESSAGEメッセージを取り出し、RANAPメッセージ処理部307Aは、ステップS115において、RANAP:INITIALUEMESSAGEメッセージを、CNDomainID等のルーチング情報を基にMSC40に送信する。MSC40では、RANAPメッセージ処理部402Aは、RANAP:INITIALUEMESSAGEメッセージをデコードし、さらに、NASメッセージ処理部403Aは、NAS-PDUに設定されているCMSERVICEREQUESTメッセージをデコードする。これらのデコード結果は呼制御部404Aに通知される。呼制御部404Aは、ステップS116において、本発明で導入されるEmergencyCauseパラメータが設定されているかどうかを判断し、EmergencyCauseパラメータが設定されている場合には、ステップS117において、CSCircuitSwitchingサービス向けの不正対策処理を起動する。図20に、CSサービス向けの不正対策処理のフローチャートを示す。図20を参照すると、呼制御部404Aは、ステップS301において、移動局10から送信されてきたMMプロトコルのCMSERVICEREQUESTメッセージTS24008Ver850セクション929に設定されているCMServiceTypeパラメータTS24008Ver850セクション10533がEmergencyCallEstablishmentであるかどうかをチェックする。次に、呼制御部404Aは、ステップS302において、MSC40が送信する発呼信号であるCCプロトコルのSETUPTS24008Ver850セクション9323Setupメッセージの電話番号TS24008Ver850セクション10547が緊急番号であるかどうかをチェックする。具体的には、TS24008Ver850の図105913GPPTS24008CalledpartyBCDnumberinformationelementにおいて、Numberdigit1Numberdigit2Numberdigit3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24008のセクション10547の、CalledPartyBCDNumberとは、着番号を指し、BCDとは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。次に、呼制御部404Aは、ステップS303において、移動局10にてEMERGENCYSETUP手順TS24008Ver850セクション938が行われているかどうかをチェックする。例えば、移動局10からemergencycallestablishmentを開始するためのメッセージを受信すると、インフォメーションエレメントEmergencysetupmessagetypeからEMERGENCYSETUP手順が行われているかどうかをチェックする。ステップS301~S303のいずれかのチェックに合致すれば、呼制御部404Aは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部404Aは、ステップS304において、呼種別が通常呼であると判断し、不正移動局10-2であるとみなし、呼解放処理を起動する。これによって、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。Bパケット交換呼の場合次に、移動局10がパケット交換の緊急呼として発呼を行った場合の動作例を説明する。パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、パケット交換では、NASメッセージとして、SMSessionManagementプロトコルメッセージおよびGMMGPRSMobilityManagementプロトコルメッセージが適用される。そのため、ステップS117で起動する不正対策処理は、PSPacketSwitchingサービス向けの不正対策処理となる。この処理は、緊急呼の識別方法がCSサービスとは異なる。また、パケット交換で音声が使用される場合には、VoIPVoiceoverIPの手法が用いられる。なお、GMMとは、パケットサービスPSでの移動制御MobilityManagementのためのプロトコルである。図21に、PSサービス向けの不正対策処理のフローチャートを示す。図21を参照すると、SGSN50の呼制御部504Aは、ステップS401において、移動局10から送信されてきたSMプロトコルのActivatePDPPacketDataProtocolcontextrequestメッセージ3GPPTS24008Ver850セクション951に設定されているAPNAccessPointName3GPPTS2400895110561が緊急呼に特有のものであるかどうかをチェックする。次に、呼制御部504Aは、ステップS402において、移動局10にて行われているGMM手順がEmergencyAttach手順TR23869Ver900であるかどうかをチェックする。次に、呼制御部504Aは、ステップS403において、SGSN50にて起動しているPDPContextが緊急呼用のPDPContextであるかどうかをチェックする。例えば、SGSN50にて起動しているPDPContextがTR23869Ver900のEmemergencyPDPContextであるかどうかをチェックする。ステップS401~S403のいずれかのチェックに合致すれば、呼制御部504Aは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部504Aは、ステップS504において、呼種別が通常呼であると判断し、不正移動局10-2であるとみなし、呼解放処理を起動する。これによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。第3の実施形態図22~図24に、本実施形態のMSC40、SGSN50、およびHNB-GW30の構成をそれぞれ示す。図22を参照すると、本実施形態のMSC40は、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をRANAPプロトコルメッセージに含める制御部41Bと、そのRANAPプロトコルメッセージをHNB-GW30に送信する送信部42Bと、を有している。また、図23を参照すると、本実施形態のSGSN50は、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をRANAPプロトコルメッセージに含める制御部51Bと、そのRANAPプロトコルメッセージをHNB-GW30に送信する送信部52Bと、を有している。また、図24を参照すると、本実施形態のHNB-GW30は、MSC40あるいはSGSN50からRANAPプロトコルメッセージを受信する受信部31Bと、そのRANAPプロトコルメッセージに呼種別が緊急呼であることを示す情報が含まれている場合に、呼解放処理を行う制御部32Bと、を有している。したがって、本実施形態においては、HNB-GW30は、移動局10が実際に発呼した呼種別が緊急呼であることを知ることができる。その結果、HNB-GW30は、移動局10がEstablishmentCauseを改ざんして緊急呼と偽っていた場合には、その移動局10の呼解放処理を実施することができるため、HNB20によるサービスを不正に受けることを防止することができる。第4の実施形態図25~図27に、本実施形態のMSC40、SGSN50、およびHNB-GW30の構成をそれぞれ示す。本実施形態は、図22~図24の第3の実施形態のSC40、SGSN50、およびHNB-GW30の構成および動作をより具体化した一例である。図25を参照すると、本実施形態のMSC40は、対HNB-GW信号送受信部401Bと、RANAPメッセージ処理部402Bと、NASメッセージ処理部403Bと、呼制御部404Bと、局データ格納部405Bと、を有している。なお、図25においては、RANAPメッセージ処理部402B、NASメッセージ処理部403B、呼制御部404B、および局データ格納部405Bにより、図22に示した制御部41Bを構成している。また、対HNB-GW信号送受信部401Bは、図22に示した送信部42Bの一例である。対HNB-GW信号送受信部401B、RANAPメッセージ処理部402B、NASメッセージ処理部403B、および局データ格納部405Bは、それぞれ、図13に示した対HNB-GW信号送受信部401A、RANAPメッセージ処理部402A、NASメッセージ処理部403A、および局データ格納部405Aと同様の機能を有している。呼制御部404Bは、図13に示した呼制御部404Aと同様に、MSC40に実装される呼処理部が一般に有する機能を有している。その他にも、呼制御部404Bは、本実施形態の特徴的な機能として、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、HNB-GW30に送信するRANAPプロトコルメッセージのCallTypeパラメータを設定する機能を有している。また、図26を参照すると、本実施形態のSGSN50は、対HNB-GW信号送受信部501Bと、RANAPメッセージ処理部502Bと、NASメッセージ処理部503Bと、呼制御部504Bと、局データ格納部505Bと、を有している。なお、図26においては、RANAPメッセージ処理部502B、NASメッセージ処理部503B、呼制御部504B、および局データ格納部505Bにより、図23に示した制御部51Bを構成している。また、対HNB-GW信号送受信部501Bは、図23に示した送信部52Bの一例である。対HNB-GW信号送受信部501B、RANAPメッセージ処理部502B、NASメッセージ処理部503B、および局データ格納部505Bは、それぞれ、図14に示した対HNB-GW信号送受信部501A、RANAPメッセージ処理部502A、NASメッセージ処理部503A、および局データ格納部505Aと同様の機能を有している。呼制御部504Bは、図14に示した呼制御部504Aと同様に、SGSN50に実装される呼処理部が一般に有する機能を有している。その他にも、呼制御部504Bは、本実施形態の特徴的な機能として、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、HNB-GW30に送信するRANAPプロトコルメッセージのCallTypeパラメータを設定する機能を有している。また、図27を参照すると、本実施形態のHNB-GW30は、対HNB信号送受信部301Bと、RUAメッセージ処理部302Bと、対SGSN信号送受信部303Bと、対MSC信号送受信部304Bと、HNBAPメッセージ処理部305Bと、呼制御部306Bと、RANAPメッセージ処理部307Bと、局データ格納部308Bと、を有している。なお、図27においては、RUAメッセージ処理部302B、HNBAPメッセージ処理部305B、呼制御部306B、RANAPメッセージ処理部307B、および局データ格納部308Bにより、図24に示した制御部32Bを構成している。また、対SGSN信号送受信部303Bおよび対MSC信号送受信部304Bは、図24に示した受信部31Bの一例である。対HNB信号送受信部301B、RUAメッセージ処理部302B、対SGSN信号送受信部303B、対MSC信号送受信部304B、HNBAPメッセージ処理部305B、RANAPメッセージ処理部307B、および局データ格納部308Bは、それぞれ、図12に示した対HNB信号送受信部301A、RUAメッセージ処理部302A、対SGSN信号送受信部303A、対MSC信号送受信部304A、HNBAPメッセージ処理部305A、RANAPメッセージ処理部307A、および局データ格納部308Aと同様の機能を有している。呼制御部306Bは、図12に示した呼制御部306Aと同様に、HNB-GW30に実装される呼処理部が一般に有する機能を有している。その他にも、呼制御部306Bは、本実施形態の特徴的な機能として、MSC40あるいはSGSN50から受信するRANAPプロトコルメッセージのCallTypeパラメータにNormalCallが設定されている場合に、移動局10が発呼した呼種別が通常呼であると判断し、このときに移動局10が緊急呼として発呼を行っていれば、呼解放処理を行う機能を有している。なお、本実施形態のHNB20の構成は、図9と同様で構わない。ただし、HNB20の呼制御部205Aは、HNB20に実装される呼処理部が一般に有する機能を有していればよい。以下に、本実施形態の移動通信システムの動作について説明する。1動作例1本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP3GPPTS25413のCOMMONIDメッセージにて通知する例である。1-A回線交換呼の場合まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのCOMMONIDメッセージにて通知する場合の動作例を、図28のシーケンス図に沿って説明する。なお、図28は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIALUEMESSAGEメッセージにはEmergencyCauseパラメータが含まれないものとする。通常、3GPPTS25.413に記述されるように、コアネットワーク装置は、シグナリングコネクションが確立された後に、RANAP:COMMONIDメッセージをHNB-GW30に送信する。そのため、図28を参照すると、MSC40では、呼制御部404Bは、ステップS501において、シグナリングコネクションの確立後、ステップS502において、CallTypeパラメータの決定処理を起動する。図29に、MSC40におけるCallTypeパラメータの決定処理のフローチャートを示す。図29を参照すると、呼制御部404Bは、ステップS601において、移動局10から送信されてきたMMプロトコルのCMSERVICEREQUESTメッセージTS24008Ver850セクション929に設定されているCMServiceTypeパラメータTS24008Ver850セクション10533がEmergencyCallEstablishmentであるかどうかをチェックする。次に、呼制御部404Bは、ステップS602において、MSC40が送信する発呼信号であるCCプロトコルのSETUPTS240089323Ver850セクションSetupメッセージの電話番号TS24008Ver850セクション10547が緊急番号であるかどうかをチェックする。具体的には、TS24008Ver850の図105913GPPTS24008CalledpartyBCDnumberinformationelementにおいて、Numberdigit1Numberdigit2Numberdigit3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24008のセクション10547の、CalledPartyBCDNumberとは、着番号を指し、BCDとは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。次に、呼制御部404Bは、ステップS603において、移動局10にてEMERGENCYSETUP手順TS24008Ver850セクション938が行われているかどうかをチェックする。例えば、移動局10からemergencycallestablishmentを開始するためのメッセージを受信すると、インフォメーションエレメントEmergencysetupmessagetypeからEMERGENCYSETUP手順が行われているかどうかをチェックする。ステップS601~S603のいずれかのチェックに合致すれば、呼制御部404Bは、ステップS604において、呼種別が緊急呼であると判断し、CallTypeパラメータをNormalCallに決定する。一方、いずれのチェックにも合致しなければ、呼制御部404Bは、ステップS605において、呼種別が通常呼であると判断し、CallTypeパラメータをEmergencyCallに決定する。再度図28を参照すると、MSC40では、呼制御部404Bは、ステップS503において、RANAP:COMMONIDメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:COMMONIDメッセージの構成を、図30に示す。HNB-GW30では、呼制御部306Bは、ステップS504において、RANAP:COMMONIDメッセージ受信時に、CallTypeパラメータが含まれていた場合、ステップS505において、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。図31は、本実施形態のHNB-GW30における処理を、呼種別に応じて決定するためのテーブルを示す図である。例えば、図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、MSC40から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。これによって、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。1-Bパケット交換呼の場合次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのCOMMONIDメッセージにて通知する場合の動作例を説明する。パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS502で起動するCallTypeパラメータの決定処理は異なっている。図32に、SGSN50におけるCallTypeパラメータの決定処理のフローチャートを示す。図32を参照すると、呼制御部504Bは、ステップS701において、移動局10から送信されてきたSMプロトコルのActivatePDPcontextrequestメッセージ3GPPTS24008Ver850セクション951に設定されているAPN3GPPTS2400895110561が緊急呼に特有のものであるかどうかをチェックする。次に、呼制御部504Bは、ステップS702において、移動局10にて行われているGMM手順がEmergencyAttach手順TR23869Ver900であるかどうかをチェックする。次に、呼制御部504Bは、ステップS703において、SGSN50にて起動しているPDPContextが緊急呼用のPDPContextであるかどうかをチェックする。例えば、SGSN50にて起動しているPDPContextがTR23869Ver900のEmemergencyPDPContextであるかどうかをチェックする。ステップS701~S703のいずれかのチェックに合致すれば、呼制御部504Bは、ステップS704において、呼種別が緊急呼であると判断し、CallTypeパラメータをNormalCallに決定する。一方、いずれのチェックにも合致しなければ、呼制御部504Bは、ステップS705において、呼種別が通常呼であると判断し、CallTypeパラメータをEmergencyCallに決定する。SGSN50では、呼制御部504Bは、RANAP:COMMONIDメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:COMMONIDメッセージの構成は、図30に示すように、MSC40の場合と同様である。HNB-GW30では、呼制御部306Bは、RANAP:COMMONIDメッセージ受信時に、CallTypeパラメータが含まれていた場合、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。例えば、図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、SGSN50から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行うこれによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。2動作例2本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP3GPPTS25413のDIRECTTRANSFERメッセージにて通知する例である。2-A回線交換呼の場合まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのDIRECTTRANSFERメッセージにて通知する場合の動作例を、図33のシーケンス図に沿って説明する。なお、図33は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIALUEMESSAGEメッセージにはEmergencyCauseパラメータが含まれないものとする。通常、3GPPTS25.413に記述されるように、コアネットワーク装置は、CCプロトコルやMMプロトコルのようなNASメッセージを送信する場合に、RANAP:DIRECTTRANSFERメッセージをHNB-GW30に送信する。そのため、図33を参照すると、MSC40では、呼制御部404Bは、ステップS801において、NASメッセージの送信後、ステップS802において、CallTypeパラメータの決定処理を起動する。MSC40におけるCallTypeパラメータの決定処理は、動作例1と同様であり、図29に示される通りである。MSC40では、呼制御部404Bは、ステップS803において、RANAP:DIRECTTRANSFERメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:DIRECTTRANSFERメッセージの構成を、図34に示す。HNB-GW30では、呼制御部306Bは、RANAP:DIRECTTRANSFERメッセージ受信時に、ステップS804において、CallTypeパラメータが含まれていた場合、ステップS805において、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。例えば、図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、MSC40から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。これによって、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。1-Bパケット交換呼の場合次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのDIRECTTRANSFERメッセージにて通知する場合の動作例を説明する。パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS802で起動するCallTypeパラメータの決定処理は異なっている。このSGSN50におけるCallTypeパラメータの決定処理は、動作例1と同様であり、図32に示される通りである。SGSN50では、呼制御部504Bは、RANAP:DIRECTTRANSFERメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:DIRECTTRANSFERメッセージの構成は、図34に示すように、MSC40の場合と同様である。HNB-GW30では、呼制御部306Bは、RANAP:DIRECTTRANSFERメッセージ受信時に、CallTypeパラメータが含まれていた場合、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。例えば、図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、SGSN50から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行うこれによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。3動作例3本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP3GPPTS25413のRABRadioAccessBearerASSIGNMENTREQUESTメッセージにて通知する例である。3-A回線交換呼の場合まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのRABASSIGNMENTREQUESTメッセージにて通知する場合の動作例を、図35のシーケンス図に沿って説明する。なお、図35は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIALUEMESSAGEメッセージにはEmergencyCauseパラメータが含まれないものとする。通常、3GPPTS25.413に記述されるように、コアネットワーク装置は、移動局10からの呼確立要求を受信して、無線アクセスベアラを確立する場合に、RANAP:RABASSIGNMENTREQUESTメッセージをHNB-GW30に送信する。そのため、図35を参照すると、MSC40では、呼制御部404Bは、ステップS901において、移動局10からの呼確立要求の受信後、ステップS902において、無線アクセスベアラにためのQoSQualityofServiceを決定し、その後、ステップS903において、CallTypeパラメータの決定処理を起動する。MSC40におけるCallTypeパラメータの決定処理は、動作例1と同様であり、図29に示される通りである。MSC40では、呼制御部404Bは、ステップS904において、RANAP:RABASSIGNMENTREQUESTメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:RABASSIGNMENTREQUESTメッセージの構成を、図36に示す。HNB-GW30では、呼制御部306Bは、RANAP:RABASSIGNMENTREQUESTメッセージ受信時に、ステップS905において、CallTypeパラメータが含まれていた場合、ステップS906において、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。例えば、図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、MSC40から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。これによって、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。1-Bパケット交換呼の場合次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのRABASSIGNMENTREQUESTメッセージにて通知する場合の動作例を説明する。パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS802で起動するCallTypeパラメータの決定処理は異なっている。このSGSN50におけるCallTypeパラメータの決定処理は、動作例1と同様であり、図32に示される通りである。SGSN50では、呼制御部504Bは、RANAP:RABASSIGNMENTREQUESTメッセージをHNB-GW30に送信する際に、CallTypeパラメータが決定されていれば、本CallTypeパラメータを設定する。本発明による、RANAP:RABASSIGNMENTREQUESTメッセージの構成は、図36に示すように、MSC40の場合と同様である。HNB-GW30では、呼制御部306Bは、RANAP:RABASSIGNMENTREQUESTメッセージ受信時に、CallTypeパラメータが含まれていた場合、移動局10がHNB-GW30にアクセスした際の、HNBAP:UEREGISTERREQUESTメッセージ図5のRegistrationCauseパラメータ図6と比較する。図31に示すケース2では、HNBAP:UEREGISTERREQUESTメッセージのRegistrationCauseパラメータがEmergencyCallであるに関わらず、SGSN50から通知されたCallTypeパラメータは、NormalCallである。このことからHNB-GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行うこれによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10-2が、EstablishmentCauseを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。なお、本発明のHNB20、HNB-GW30、MSC40、およびSGSN50にて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。第5の実施形態第2の実施形態では、不正対策処理をMSC40あるいはSGSN50にて行っているが、本実施形態では、不正対策処理をHNB-GW30にて行う。この場合におけるシーケンスを図37に示す。図37は、HNB-GWが予めUERegister手順において、RegistrationCause=EmergencyCallを通知されているケースにおいてHNB-GWがNASメッセージの中身をチェックして、不正対策処理を起動するケースを示している。これは、図15において、MSCが、HNB-GWよりUEが緊急呼として発呼していたことの通知を受けている場合に、図20において、MMあるいはCCプロトコルのメッセージのチェック処理を実施していたことに相当する。また、同様に、SGSNが、HNB-GWよりUEが緊急呼として発呼していたことを示す場合に、図21において、GMMあるいはSMプロトコルのメッセージのチェック処理を実施していたことに相当する。なお、NASメッセージとは、NonAccessStratumを指し、無線アクセス方式に依存しないプロトコルを指す。本実施形態により以下の効果を奏する。HNG-GWにて、不正対策処理を実施するため、MSCあるいはSGSNに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のMSCあるいはSGSNに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。第2の実施形態に比べて、RANAPプロトコルに新たなパラメータの追加が不要となるため、RANAPプロトコルのメッセージサイズを削減し、HNB-GWとMSCあるいはSGSN間のシグナリングの通信量を減少させることができる。HNB-GWがNASメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、MSCあるいはSGSNより呼の種別の通知を受けなくても、HNB-GWが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。第6の実施形態第5の実施形態では、端末が緊急呼として発呼している場合に、HNB-GWがNASメッセージをのぞくことにより、不正対策処理を実現しているが、本実施形態では、本不正対策処理をHNBで行う。つまり、図38に示されるように、HNBがNASメッセージをのぞき、不正対策処理を起動する。本実施形態により以下の効果を奏する。HNBにて、不正対策処理を実施するため、上位装置が不正対策処理を実行するケースに比べて、より早期に、不正な端末との通信を終了することができる。これによって、ネットワークのリソースの利用性を高めて、HNBとHNB-GW間のシグナリングを減らすことができる。HNBがNASメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、MSCあるいはSGSNより呼の種別の通知を受けなくても、HNBが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。第7の実施形態第3の実施形態では、MSCあるいはSGSNが緊急呼の情報をHNB-GWに通知し、HNB-GWはUEが緊急呼としてアクセスしてきたかどうかを確認する。また、第4の実施形態では、RANAPプロトコルにおいて、CallTypeというパラメータを使用していた。本実施形態では、RANAPの緊急呼を示す情報として、既に、3GPPTS25.413で定義されたAllocation/RetentionPriorityと呼ばれるパラメータを使用する図39参照。Allocation/RetentionPriorityの使用方法については、公知の技術としてよく知られているものであり、本発明の対象外である。例えば、新しいベアラを割り当てるためのリソースが確保できない場合において、他の優先度の低いベアラを解放して、リソースを空けることで、新しいベアラがそのリソースを獲得するというプリエンプションのために使用される。MSCあるいはSGSNが、RABASSIGNMENTREQUESTメッセージにおいて、本Allocation/RetentionPriorityパラメータを、緊急呼の場合には、以下のように設定する。PriorityLevel1PreemptionCapabilitymaytriggerpreemptionPreemptionVulnerabilitynotpreemptableこのように設定することで、緊急呼として確立することを通知することができる。さらに、RANAPのRABASSIGNMENTREQUESTメッセージ以外のほかのメッセージでもよい。この場合に、MSCあるいはSGSNでのAllocation/RetentionPriorityパラメータを緊急呼設定する場合の設定論理は、図29および図32と同様であり、図40および図41のようになる。図40および図41においては、本Allocation/RetentionPriorityパラメータが通常呼を示しているが、UERegistration手順におけるRegistrationCause値が緊急呼を示す場合には、HNB-GWは、UEがEstablishmentCauseを偽ってアクセスしてきたと判断し、呼解放を実施する。この場合の動作シーケンスを図42に示す。本実施形態により以下の効果を奏する。既存のAllocation/RetentionPriorityを用いて緊急呼かどうかを通知するため、MSCあるいはSGSNに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のMSCあるいは、SGSNに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。第4の実施形態に比べて、RANAPプロトコルに新たなパラメータの追加が不要となるため、RANAPプロトコルのメッセージサイズを削減し、HNB-GWとMSCあるいはSGSN間のシグナリングの通信量を減少させることができる。第8の実施形態第7の実施形態では、HNB-GWがAllocation/RetentionPriorityパラメータを判断し、不正対策処理を実現しているが、本実施形態では、本不正対策処理をHNBで行う。つまり、図43に示されるように、HNBがRANAPのRABASSIGNMENTREQUESTメッセージを受信時に、Allocation/RetentionPriorityを判断し、それが通常呼であった場合に、UERegistration手順におけるRegistrationCauseが緊急呼であった場合には、HNB-GWは、UEがEstablishmentCauseを偽ってアクセスしてきたと判断し、呼解放を実施する。なお、第3の実施形態および第4の実施形態では、HNB-GWがMSCあるいはSGSNより通知される呼種別とUEがアクセスしてきた際のRegistrationCauseの比較処理を実施しているが、本比較処理はHNBで実施してもよい。本実施形態により以下の効果を奏する。HNB-GWでは、RANAPプロトコルメッセージを終端し、Allocation/RetentionPriorityによって呼種別を判断する必要がなくなるため、HNB-GWの処理を簡単にすることが可能となる。以上、本発明を、好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。例えば、第2の実施形態では、EmergencyCause値のRANAPプロトコルメッセージへの設定をHNB20にて行っているが、HNB-GW30にて行うこととしてもよい。また、第1~第4の実施形態によれば、RANAPプロトコルメッセージを用いて、移動局10が緊急呼として発呼を行ったことを示す情報または移動局10が発呼した実際の呼種別が緊急呼であることを示す情報を、HNB20、HNB-GW30およびコアネットワーク装置MSC40またはSGSN50間で通信した。しかし、RANAPプロトコルメッセージに限らず、HNB20、HNB-GW30またはコアネットワーク装置間で通信可能なメッセージであれば他のメッセージであってもよい。本出願は、2009年10月01日に出願された日本出願特願2009-229391を基礎とする優先権を主張し、その開示の全てをここに取り込む。"