移動通信システム
【課題】コアネットワーク装置が、移動局が緊急呼として発呼を行ったことを知ることができる移動通信システムを提供する。
【解決手段】移動通信システムは、移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する。前記基地局は、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、前記ゲートウェイ装置は、前記基地局から、前記登録メッセージを受信する第１の受信手段と、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、を有する。
【解決手段】移動通信システムは、移動局と、前記移動局と無線通信を行う基地局と、前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する。前記基地局は、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、前記ゲートウェイ装置は、前記基地局から、前記登録メッセージを受信する第１の受信手段と、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムに関する。
【背景技術】
【０００２】
フェムト基地局（Ｈｏｍｅ ＮｏｄｅＢ、以下、ＨＮＢと略す）の産業上の利用形態としては、例えば、家庭用の小型無線基地局として利用する形態や、企業内における小型無線基地局として利用する形態が考えられている。
【０００３】
ＨＮＢによりサービスを提供する場合には、例えば、以下のような利点がある。
【０００４】
（１）マクロ基地局の電波が届かない不感地帯での通話サービスを提供することができる
（２）マクロ基地局が提供する通常の課金サービスよりも安い課金サービスを提供することができる
（３）基地局と移動局との距離が近く、移動局が高い無線品質（Ｅｃ／Ｉｏ）を得ることができるため、６４ＱＡＭ（64 Quadrature Amplitude Modulation）やＭＩＭＯ（Multiple Input Multiple Output）の高速化技術を活かすことができ、ＨＮＢ配下において高速パケットサービスを提供することができる
（４）ＨＮＢの局所性を活かした特有のコンテンツサービスを提供することができる
このように、ＨＮＢによるサービスは、多くの利点を有するため、通信事業者と契約を結んだ加入者や、そのＨＮＢの所持者が許容した加入者のみに提供されるべきである。
【０００５】
そこで、３ＧＰＰ（3rd Generation Partnership Project）では、許容されたグループの移動局のみがＨＮＢにアクセスし、サービスを受けられるようにするために、リリース８において、ＣＳＧ（Closed Subscriber Group）を導入している。
【０００６】
ここで、ＣＳＧについて、図１を参照して詳細に説明する。
【０００７】
図１に示す第３世代の移動通信システムは、ＨＮＢ２０と、フェムト基地局ゲートウェイ（Ｈｏｍｅ ＮｏｄｅＢ ＧＷ、以下、ＨＮＢ−ＧＷと略す）３０と、回線交換局（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ、以下、ＭＳＣと略す）４０と、パケット交換局（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、以下、ＳＧＳＮと略す）５０と、第３世代対応の移動局１０−１，１０−２と、を有している。
【０００８】
なお、図１において、ＨＮＢ２０の配下に在圏する移動局１０−１，１０−２のうち、移動局１０−１は、正当な移動局である。これに対し、移動局１０−２は、ＨＮＢ２０によるサービスを不正に受けようとする移動局であり、以下、不正移動局１０−２と称す。また、以下、どちらの移動局かを特定しない場合は、移動局１０と称す。
【０００９】
ＨＮＢ２０は、ＨＮＢ−ＧＷ３０を介してオペレータのコアネットワークに接続されている。
【００１０】
コアネットワークは、コアネットワーク装置として、回線交換を制御するＭＳＣ４０と、パケット交換を制御するＳＧＳＮ５０と、を含んでいる。
【００１１】
ＨＮＢ２０は、ＣＳＧ機能をサポートしている場合には、自身のＣＳＧセル（CSG Cell）のＣＳＧ識別子（CSG identity）を、自身の配下に在圏する移動局１０に報知する。
【００１２】
移動局１０−１は、ＨＮＢ２０から報知されたＣＳＧ識別子をデコードし、自身の持っているＣＳＧリストにそのＣＳＧ識別子が含まれているかどうかを判断する。
【００１３】
ＣＳＧリストにＣＳＧ識別子が含まれていれば、移動局１０−１は、自身が在圏するＣＳＧセルにキャンプオンし、発信、着信といった様々なサービスを受けることができる。
【００１４】
一方、ＣＳＧリストにＣＳＧ識別子が含まれていなければ、移動局１０−１は、自身が在圏するＣＳＧセルにはキャンプオンせずに、そのＣＳＧセルとは別の適切なＣＳＧセルを選択する動作を行う。
【００１５】
このようなメカニズムによって、ＨＮＢ２０には、そのＨＮＢ２０のＣＳＧセルのＣＳＧ識別子を持つ限られた移動局１０−１のみがアクセス可能になる。
【００１６】
ただし、図１に示した不正移動局１０−２のように、ＣＳＧ機能をサポートしているにも関わらず、本来、アクセスできないＨＮＢ２０のＣＳＧセルにて、不正にサービスを受けようとするケースが考えられる。
【００１７】
このようなケースにおいては、ＭＳＣ４０あるいはＳＧＳＮ５０が、移動局１０のＩＭＳＩ（International Mobile Subscriber Identity）とその移動局１０が在圏しているＣＳＧセルのＣＳＧ識別子とをチェックすることによって、その移動局１０によるＨＮＢ２０へのアクセスを規制するアクセス規制を行う（3GPP TS25.467 Ver8.0.0 5.1.3節）。
【００１８】
一方、ＣＳＧ機能は、３ＧＰＰのリリース８より導入されている機能であるため、リリース８以前の移動局１０−１がＣＳＧ機能をサポートしていないケースがある。また、ＨＮＢ２０がＣＳＧ機能をサポートしていないケースもある。
【００１９】
このようなケースにおいては、ＨＮＢ２０は、移動局１０−１のＩＭＳＩを問い合わせるために、移動局１０−１に対してＩｄｅｎｔｉｆｉｃａｔｉｏｎ手順（3GPP TS24.008 Ver8.4.0）を実施し、また、移動局１０−１をＨＮＢ−ＧＷ３０に登録するために、ＨＮＢ−ＧＷ３０に対してＨＮＢＡＰ（HNB Application Part）：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴ手順（3GPP TS25.469 Ver8.0.0）を実施する。この際に、ＨＮＢ−ＧＷ３０は、移動局１０−１のＩＭＳＩがＨＮＢ２０にアクセスできるものかどうかをチェックすることによって、アクセス規制を行う。
【００２０】
ＨＮＢ−ＧＷ３０は、移動局１０−１がＨＮＢ２０にアクセスできると判断した場合には、アクセスが許可されることを、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージによってＨＮＢ２０に通知する。これにより、ＨＮＢ２０によるサービスが移動局１０−１に対して提供される。
【００２１】
一方、移動局１０が図１に示した不正移動局１０−２である場合には、不正移動局１０−２のＩＭＳＩはＣＳＧにアクセスできるように登録されていない。そのため、ＨＮＢ−ＧＷ３０は、不正移動局１０−２がＨＮＢ２０にアクセスできないと判断し、アクセスが許可されないことを、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＪＥＣＴメッセージによってＨＮＢ２０に通知する。これにより、不正移動局１０−２とＨＮＢ２０との間のＲＲＣ（Radio Resource Control）コネクションは切断される（3GPP TS25.467 Ver8.0.0 5.1.2節）。
【００２２】
上記により、ＨＮＢ２０によるサービスを提供するに際しては、ＭＳＣ４０、ＳＧＳＮ５０、あるいはＨＮＢ−ＧＷ３０が、移動局１０のＩＭＳＩを基に、アクセス規制を行っているため、ＨＮＢ２０へのアクセスが許容されていない不正移動局１０−２が仮に発信を行ったとしても、信号確立手順中に移動通信ネットワーク側によりＨＮＢ２０へのアクセスが拒絶されることとなる。
【００２３】
一方、３ＧＰＰの標準化においては、本来、ＨＮＢ２０へのアクセスが許容されていない移動局１０であっても、呼種別が緊急呼である場合は発呼を可能とすることが定められている（3GPP TS22.011 Ver 8.6.0 8.5.1節）。
【００２４】
呼種別が緊急呼である場合、移動局１０−１は、ＲＲＣコネクション確立要求時あるいはシグナリングコネクション確立要求時にＨＮＢ２０に送信するＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージあるいはＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲにおいて、確立要求の要因を示すＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータに“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”と設定する（3GPP TS25.331 Ver8.5.0 10.3.3.11節、特許文献１）。
【００２５】
そして、ＨＮＢ２０は、ＨＮＢ−ＧＷ３０に送信するＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”値に設定する。
【００２６】
Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”である場合には、ＨＮＢ−ＧＷ３０は、ＩＭＳＩに基づくアクセス規制を実施しない（3GPP TS25.467 Ver8.0.0 5.1.2節）。
【００２７】
この手法によって、本来、ＨＮＢ２０にアクセスしてはならない移動局１０であっても、呼種別が緊急呼である場合には、ＨＮＢ−ＧＷ３０のアクセス規制をスキップし、ＨＮＢ２０へのアクセスが可能となる。
【００２８】
ここで、図２に、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージの構成を示し、また、図３に、ＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示し、また、図４に、ＲＲＣプロトコルにおける、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータの構成を示し、また、図５に、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージの構成を示し、また、図６に、ＨＢＮＡＰプロトコルにおける、Ｒｅｇｓｉｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの構成を示す。
【先行技術文献】
【特許文献】
【００２９】
【特許文献１】特開２００３−２４４２８４号公報
【発明の概要】
【発明が解決しようとする課題】
【００３０】
ところで、上述した技術は、移動局１０が緊急呼として発呼を行った場合には、ＨＮＢ−ＧＷ３０のアクセス規制をスキップし、移動局１０によるＨＮＢ２０へのアクセスを許可するものである。
【００３１】
そのため、不正移動局１０−２のように、本来はＨＮＢ２０へアクセスできない移動局１０であっても、ＲＲＣプロトコルにおける、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”と偽り、ＨＮＢ−ＧＷ３０のアクセス規制の対象外となることによって、ＨＮＢ２０へのアクセスが可能となってしまう。
【００３２】
このような不正移動局１０−２は、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータのみを改ざんするようにソフトウェアを改造することによって、容易に作ることができると考えられる。
【００３３】
あるいは、正当な移動局１０−１から共通チャネル（ＲＡＣＨ：Random Access Channel）上に送信される、秘匿も改ざん対策もされていないＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをデコードし、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”に置き換えて、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをエンコードしてＨＮＢ２０に送信する装置が介在する場合もある。この場合、正当な移動局１０−１であっても、上述のような不正移動局１０−２と同視されることになる。
【００３４】
このような不正移動局１０−２により、以下のような問題が生じる。
【００３５】
（１）家庭用あるいは企業に設置されたＨＮＢ２０が、不正移動局１０−２により不正に使用されてしまう
（２）不正移動局１０−２は、ＨＮＢ２０を介した発信を行うことによって、通常の課金サービスよりも安い課金サービスを不正に受けることができてしまう
（３）特定のユーザ向けへのコンテンツサービスを不正移動局１０−２が不正に受けてしまう
このような問題を解決する方法としては、移動局１０が緊急呼として発呼を行った場合に、コアネットワーク装置側で、その移動局１０の呼解放処理を行うことが考えられる。そのためには、コアネットワーク装置は、移動局１０が緊急呼として発呼を行ったことを知る必要がある。
【００３６】
しかし、現状の構成では、コアネットワーク装置は、移動局１０が緊急呼として発呼を行ったことを知ることができない。
【００３７】
あるいは、ＨＮＢ−ＧＷ３０側で、緊急呼と偽って発呼を行った移動局１０の呼解放処理を行うことも考えられる。そのためには、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別が緊急呼であるかを知る必要がある。
【００３８】
しかし、現状の構成では、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別を知ることができない。
【００３９】
本発明の目的は、コアネットワーク装置が、移動局が緊急呼として発呼を行ったことを知ることができる移動通信システムを提供することにある。
【００４０】
本発明の他の目的は、ゲートウェイ装置が、移動局が実際に発呼した呼種別を知ることができる移動通信システムを提供することにある。
【課題を解決するための手段】
【００４１】
本発明の移動通信システムは、
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、
前記基地局は、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、
前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、
前記ゲートウェイ装置は、
前記基地局から、前記登録メッセージを受信する第１の受信手段と、
前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、
を有する。
【００４２】
本発明のゲートウェイ装置は、
基地局を、コアネットワークに接続するゲートウェイ装置であって、
移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信する第１の受信手段と、
前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、
を有する。
【００４３】
本発明の第１の通信方法は、
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、
前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、
前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、
前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、
前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、
前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。
【００４４】
本発明の第２の通信方法は、
基地局を、コアネットワークに接続するゲートウェイ装置による通信方法であって、
移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信し、
前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信し、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。
【発明の効果】
【００４５】
本発明の第１の移動通信システムによれば、基地局あるいはゲートウェイ装置は、移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めて、コアネットワーク装置に送信する。
【００４６】
したがって、コアネットワーク装置は、移動局が緊急呼として発呼を行ったことを知ることができるという効果が得られる。
【００４７】
本発明の第２の移動通信システムによれば、コアネットワーク装置は、移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めて、ゲートウェイ装置に送信する。
【００４８】
したがって、ゲートウェイ装置は、移動局が実際に発呼した呼種別が緊急呼であることを知ることができるという効果が得られる。
【図面の簡単な説明】
【００４９】
【図１】第３世代の移動通信システムの構成を示す図である。
【図２】ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図３】ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示す図である。
【図４】Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータの構成を示す図である。
【図５】ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図６】Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの構成を示す図である。
【図７】本発明の第１の実施形態のＨＮＢの構成を示すブロック図である。
【図８】本発明の第１の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図９】本発明の第１の実施形態のＭＳＣの構成を示すブロック図である。
【図１０】本発明の第１の実施形態のＳＧＳＮの構成を示すブロック図である。
【図１１】本発明の第２の実施形態のＨＮＢの構成を示すブロック図である。
【図１２】本発明の第２の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図１３】本発明の第２の実施形態のＭＳＣの構成を示すブロック図である。
【図１４】本発明の第２の実施形態のＳＧＳＮの構成を示すブロック図である。
【図１５】本発明の第２の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図１６】ＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図１７】ＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータの構成を示す図である。
【図１８】ＨＮＢよるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの決定処理を示すフローチャートである。
【図１９】本発明に係るＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが追加されたＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージの構成を示す図である。
【図２０】本発明の第２の実施形態のＭＳＣによる不正対策処理を示すフローチャートである。
【図２１】本発明の第２の実施形態のＳＧＳＮによる不正対策処理を示すフローチャートである。
【図２２】本発明の第３の実施形態のＭＳＣの構成を示すブロック図である。
【図２３】本発明の第３の実施形態のＳＧＳＮの構成を示すブロック図である。
【図２４】本発明の第３の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図２５】本発明の第４の実施形態のＭＳＣの構成を示すブロック図である。
【図２６】本発明の第４の実施形態のＳＧＳＮの構成を示すブロック図である。
【図２７】本発明の第４の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図２８】本発明の第４の実施形態の移動通信システムの動作例１を説明するシーケンス図である。
【図２９】本発明の第４の実施形態のＭＳＣによるＣａｌｌ Ｔｙｐｅパラメータの決定処理を示すフローチャートである。
【図３０】本発明に係るＣＯＭＭＯＮ ＩＤメッセージの構成を示す図である。
【図３１】本発明の第４の実施形態のＨＮＢ−ＧＷにおける処理を、呼種別に応じて決定するためのテーブルを示す図である。
【図３２】本発明の第４の実施形態のＳＧＳＮによるＣａｌｌ Ｔｙｐｅパラメータの決定処理を示すフローチャートである。
【図３３】本発明の第４の実施形態の移動通信システムの動作例２を説明するシーケンス図である。
【図３４】本発明に係るＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示す図である。
【図３５】本発明の第４の実施形態の移動通信システムの動作例３を説明するシーケンス図である。
【図３６】本発明に係るＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図３７】本発明の第５の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図３８】本発明の第６の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図３９】本発明の第７の実施形態に係るＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙのパラメータを示す図である。
【図４０】本発明の第７の実施形態のＭＳＣによる呼種別設定処理を示すフローチャートである。
【図４１】本発明の第７の実施形態のＳＧＳＮによる呼種別設定処理を示すフローチャートである。
【図４２】本発明の第７の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図４３】本発明の第８の実施形態の移動通信システムの動作を説明するシーケンス図である。
【発明を実施するための形態】
【００５０】
以下に、本発明を実施するための最良の形態について図面を参照して説明する。
【００５１】
なお、以下で説明する実施形態において、移動通信システムの全体構成自体は、図１の移動通信システムと同様であるとする。
【００５２】
（第１の実施形態）
図７〜図１０に、本実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成をそれぞれ示す。
【００５３】
図７を参照すると、本実施形態のＨＮＢ２０は、移動局１０が緊急呼として発呼を行ったことを示す情報をＲＡＮＡＰ（Radio Access Network Application Part）プロトコルメッセージに含める制御部２１Ａと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部２２Ａと、を有している。なお、ＲＡＮＡＰプロトコルメッセージとは、無線アクセスネットワークのアプリケーション層のメッセージであり、例えば、UEとコアネットワーク装置間で送受信されるＣＣ／ＭＭ信号をＲＡＮ内で透過的に転送する昨日を有するものである。
【００５４】
また、図８を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、ＨＮＢ２０からＲＡＮＡＰプロトコルメッセージを受信する受信部３１Ａと、そのＲＡＮＡＰプロトコルメッセージを取り出す制御部３２Ａと、そのＲＡＮＡＰプロトコルメッセージをＭＳＣ４０あるいはＳＧＳＮ５０に送信する送信部３３Ａと、を有している。
【００５５】
また、図９を参照すると、本実施形態のＭＳＣ４０は、ＨＮＢ−ＧＷ３０からＲＡＮＡＰプロトコルメッセージを受信する受信部４１Ａと、そのＲＡＮＡＰプロトコルメッセージに移動局１０が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を行う制御部４２Ａと、を有している。
【００５６】
また、図１０を参照すると、本実施形態のＳＧＳＮ５０は、ＨＮＢ−ＧＷ３０からＲＡＮＡＰプロトコルメッセージを受信する受信部５１Ａと、そのＲＡＮＡＰプロトコルメッセージに移動局１０が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を実施する制御部５２Ａと、を有している。
【００５７】
したがって、本実施形態においては、ＭＳＣ４０あるいはＳＧＳＮ５０が、移動局１０が緊急呼として発呼を行ったことを知ることができる。
【００５８】
その結果、ＭＳＣ４０あるいはＳＧＳＮ５０は、移動局１０がＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽っていた場合には、その移動局１０の呼解放処理を実施することができるため、ＨＮＢ２０によるサービスを不正に受けることを防止することができる。
【００５９】
（第２の実施形態）
図１１〜図１４に、本実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成をそれぞれ示す。本実施形態は、図７〜図１０の第１の実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成および動作をより具体化した例である。
【００６０】
図１１を参照すると、本実施形態のＨＮＢ２０は、対移動局信号送受信部２０１Ａと、ＲＵＡ（RANAP User Adaption）メッセージ処理部２０２Ａと、対ＨＮＢ−ＧＷ信号送受信部２０３Ａと、ＨＮＢＡＰメッセージ処理部２０４Ａと、呼制御部２０５Ａと、ＲＲＣメッセージ処理部２０６Ａと、ＲＡＮＡＰメッセージ処理部２０７Ａと、を有している。
【００６１】
なお、図１１においては、ＲＵＡメッセージ処理部２０２Ａ、ＨＮＢＡＰメッセージ処理部２０４Ａ、呼制御部２０５Ａ、ＲＲＣメッセージ処理部２０６Ａ、およびＲＡＮＡＰメッセージ処理部２０７Ａにより、図７に示した制御部２１Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部２０３Ａは、図７に示した送信部２２Ａの一例である。
【００６２】
対移動局信号送受信部２０１Ａは、移動局１０との間でＲＲＣプロトコルメッセージを送受信するための機能として、メッセージを秘匿（暗号化、復号化）する秘匿機能、メッセージの送達を確認する信号送達確認機能、メッセージを分配する信号分配機能等を有している。
【００６３】
対ＨＮＢ−ＧＷ信号送受信部２０３Ａは、ＨＮＢ−ＧＷ３０との間でＨＮＢＡＰプロトコルメッセージやＲＵＡプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能、信号分配機能等を有している。
【００６４】
ＲＲＣメッセージ処理部２０６Ａは、移動局１０へ送信するＲＲＣプロトコルメッセージをエンコードする機能、および、移動局１０から受信するＲＲＣプロトコルメッセージをデコードする機能を有している。
【００６５】
ＨＮＢＡＰメッセージ処理部２０４Ａは、ＨＮＢ−ＧＷ３０へ送信するＨＮＢＡＰプロトコルメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＨＮＢＡＰプロトコルメッセージをデコードする機能を有している。
【００６６】
ＲＡＮＡＰメッセージ処理部２０７Ａは、ＨＮＢ−ＧＷ３０へ送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００６７】
ＲＵＡプロトコルは、ＲＡＮＡＰプロトコルメッセージを転送する働きをするプロトコルであり、ＲＵＡメッセージ処理部２０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＵＡプロトコルメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＵＡプロトコルメッセージをデコードする機能を有している。
【００６８】
呼制御部２０５Ａは、ＲＲＣプロトコルメッセージやＲＡＮＡＰプロトコルメッセージを基に、ＲＲＣコネクションの確立、ベアラの確立、移動制御などの様々な呼処理を起動する。さらに、呼制御部２０５Ａは、ＨＮＢＡＰプロトコルを起動して、ＨＮＢ−ＧＷ３０への移動局１０の登録処理を実施する。以上の機能は、ＨＮＢ２０に実装される呼処理部が一般に有する機能である。
【００６９】
その他にも、呼制御部２０５Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信したＨＮＢＡＰプロトコルメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅ値を設定する機能を有している。
【００７０】
また、図１２を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、対ＨＮＢ信号送受信部３０１Ａと、ＲＵＡメッセージ処理部３０２Ａと、対ＳＧＳＮ信号送受信部３０３Ａと、対ＭＳＣ信号送受信部３０４Ａと、ＨＮＢＡＰメッセージ処理部３０５Ａと、呼制御部３０６Ａと、ＲＡＮＡＰメッセージ処理部３０７Ａと、局データ格納部３０８Ａと、を有している。
【００７１】
なお、図１２においては、ＲＵＡメッセージ処理部３０２Ａ、ＨＮＢＡＰメッセージ処理部３０５Ａ、呼制御部３０６Ａ、ＲＡＮＡＰメッセージ処理部３０７Ａ、および局データ格納部３０８Ａにより、図８に示した制御部３２Ａを構成している。また、対ＨＮＢ信号送受信部３０１Ａは、図８に示した受信部３１Ａの一例であり、また、対ＳＧＳＮ信号送受信部３０３Ａおよび対ＭＳＣ信号送受信部３０４Ａは、図８に示した送信部３３Ａの一例である。
【００７２】
対ＨＮＢ信号送受信部３０１Ａは、ＨＮＢ２０との間でＲＵＡプロトコルメッセージやＨＮＢＡＰプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能等を有している。
【００７３】
対ＭＳＣ信号送受信部３０４Ａは、ＭＳＣ４０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、メッセージの順序を制御する順序制御機能、送達確認機能等を有している。
【００７４】
対ＳＧＳＮ信号送受信部３０３Ａは、ＳＧＳＮ５０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００７５】
ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢ２０へ送信するＨＮＢＡＰプロトコルメッセージをエンコードする機能、および、ＨＮＢから受信するＨＮＢＡＰプロトコルメッセージをデコードする機能を有している。
【００７６】
ＲＵＡメッセージ処理部３０２Ａは、ＨＮＢ２０へ送信するＲＵＡプロトコルメッセージをエンコードする機能、および、ＨＮＢ２０から受信するＲＵＡプロトコルメッセージをデコードする機能を有している。
【００７７】
ＲＡＮＡＰメッセージ処理部３０７Ａは、ＭＳＣ４０に送信するＲＡＮＡＰプロトコルメッセージをエンコードする機能、および、ＭＳＣ４０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００７８】
呼制御部３０６Ａは、ＨＮＢ１０３の登録処理や、移動局１０の登録処理を行う。また、呼制御部３０６Ａは、局データ格納部３０８Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＨＮＢ−ＧＷ３０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＨＮＢ−ＧＷ３０に実装される呼処理部が一般に有する機能である。
【００７９】
また、図１３を参照すると、本実施形態のＭＳＣ４０は、対ＨＮＢ−ＧＷ信号送受信部４０１Ａと、ＲＡＮＡＰメッセージ処理部４０２Ａと、ＮＡＳ（Non Access Stratum）メッセージ処理部４０３Ａと、呼制御部４０４Ａと、局データ格納部４０５Ａと、を有している。
【００８０】
なお、図１３においては、ＲＡＮＡＰメッセージ処理部４０２Ａ、ＮＡＳメッセージ処理部４０３Ａ、呼制御部４０４Ａ、および局データ格納部４０５Ａにより、図９に示した制御部４２Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部４０１Ａは、図９に示した受信部４１Ａの一例である。
【００８１】
対ＨＮＢ−ＧＷ信号送受信部４０１Ａは、ＨＮＢ−ＧＷ３０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００８２】
ＲＡＮＡＰメッセージ処理部４０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００８３】
ＮＡＳメッセージ処理部４０３Ａは、移動局１０との間でＮＡＳプロトコル（ＣＣ（Call Control）プロトコル、ＭＭ（Mobility Management）プロトコル）のメッセージの送受信を行うための機能を有している。
【００８４】
呼制御部４０４Ａは、呼確立、呼解放などの呼処理を行う呼処理機能や、位置登録やハンドオーバなどの移動制御を行う移動制御機能、さらに、ＨＮＢ２０へのアクセスを規制するアクセス規制機能を有している。呼制御部４０４Ａは、局データ格納部４０５Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＭＳＣ４０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＭＳＣ４０に実装される呼処理部が一般に有する機能である。
【００８５】
その他にも、呼制御部４０４Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージにＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合に、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部４０４Ａは、呼解放処理を行うことになる。
【００８６】
また、図１４を参照すると、本実施形態のＳＧＳＮ５０は、対ＨＮＢ−ＧＷ信号送受信部５０１Ａと、ＲＡＮＡＰメッセージ処理部５０２Ａと、ＮＡＳメッセージ処理部５０３Ａと、呼制御部５０４Ａと、局データ格納部５０５Ａと、を有している。
【００８７】
なお、図１４においては、ＲＡＮＡＰメッセージ処理部５０２Ａ、ＮＡＳメッセージ処理部５０３Ａ、呼制御部５０４Ａ、および局データ格納部５０５Ａにより、図１０に示した制御部５２Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部５０１Ａは、図１０に示した受信部５１Ａの一例である。
【００８８】
対ＨＮＢ−ＧＷ信号送受信部５０１Ａは、ＨＮＢ−ＧＷ３０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００８９】
ＲＡＮＡＰメッセージ処理部５０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００９０】
ＮＡＳメッセージ処理部５０３Ａは、移動局１０との間でＮＡＳプロトコル（ＣＣプロトコル、ＭＭプロトコル）のメッセージの送受信を行うための機能を有している。
【００９１】
呼制御部５０４Ａは、呼処理機能や移動制御機能、さらに、アクセス規制機能を有している。呼制御部５０４Ａは、局データ格納部５０５Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＳＧＳＮ５０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＳＧＳＮ５０に実装される呼処理部が一般に有する機能である。
【００９２】
その他にも、呼制御部５０４Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージにＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合に、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部５０４Ａは、呼解放処理を行うことになる。
【００９３】
以下に、本実施形態の移動通信システムの動作について説明する。
【００９４】
（Ａ）回線交換呼の場合
まず、移動局１０が回線交換の緊急呼として発呼を行った場合の動作例を、図１５のシーケンス図に沿って説明する。
【００９５】
図１５を参照すると、移動局１０は、ステップＳ１０１において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ（図４）をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージ（図２）に設定し、ステップＳ１０２において、そのＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをＨＮＢ２０に送信する。
【００９６】
ＨＮＢ２０は、無線リソースを確保した後、ステップＳ１０３において、その旨をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＳＥＴＵＰメッセージにて移動局１０に通知する。
【００９７】
移動局１０は、ＲＲＣコネクションを確立した後、ステップＳ１０４において、その旨をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＳＥＴＵＰ ＣＯＭＰＬＥＴＥメッセージにてＨＮＢ２０に通知する。
【００９８】
続いて、移動局１０は、ステップＳ１０５において、ＭＭプロトコルメッセージであるＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（図１６）のＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（図１７）を“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”と設定し、そのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージをＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ（図３）に含める。
【００９９】
さらに、移動局１０は、ステップＳ１０６において、そのＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージのＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ（図４）を“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”と設定し、そのＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ（図３）をＨＮＢ２０に送信する。
【０１００】
ＨＮＢ２０では、ＲＲＣプロトコルメッセージ処理部７０７Ａは、ステップＳ１０２で送信されてきたＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージおよびステップＳ１０６で送信されてきたＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをデコードする。
【０１０１】
また、ＨＮＢ２０では、呼制御部２０５Ａは、移動局１０から、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージおよびＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知されたＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値（図４）を保存しておき、ステップＳ１０７において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値を基に、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを決定し、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）に設定する。
【０１０２】
図１８に、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの決定処理のフローチャートを示す。
【０１０３】
図１８を参照すると、呼制御部２０５Ａは、ステップＳ２０１において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるか判断し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”である場合は、ステップＳ２０２において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”と決定し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”でない場合は、ステップＳ２０３において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”と決定する。
【０１０４】
再度図１５を参照すると、ＨＮＢ２０は、ステップＳ１０８において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを設定したＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）をＨＮＢ−ＧＷ３０に送信する。
【０１０５】
ＨＮＢ−ＧＷ３０では、対ＨＮＢ信号送受信部３０１Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージを受信し、ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージをデコードし、呼制御部３０６Ａは、ステップＳ１０９において、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージに設定されているＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを基に、アクセス規制（ステップＳ１１０）を実施するかどうかを判断する。
【０１０６】
ＨＮＢ−ＧＷ３０では、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であれば、アクセス規制をしない。この場合、呼制御部３０６Ａは、該当する移動局１０に対してコンテキストＩＤを割り当て、ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージをエンコードし、対ＨＮＢ信号送受信部３０１Ａは、ステップＳ１１１において、そのＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージをＨＮＢ２０に送信する。
【０１０７】
ＨＮＢ２０では、呼制御部２０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージの受信後、ステップＳ１１２において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるか判断し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であれば、ステップＳ１１３において、本発明によって導入されるＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータ（図１９）を生成する。ＲＡＮＡＰメッセージ処理部２０７Ａは、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータを含むＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージのエンコードを行う。さらに、ＲＡＮＡＰメッセージ処理部２０７Ａは、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにＮＡＳ−ＰＤＵ（Protocol Data Unit）パラメータを設定し、ＮＡＳ−ＰＤＵパラメータには、移動局１０から受信したＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージを設定する。ＲＵＡメッセージ処理部７０３Ａは、そのＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを含むＲＵＡ：ＣＯＮＮＥＣＴメッセージを生成する。すなわち、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージは、ステップＳ１１４において、ＨＮＢ２０からＨＮＢ−ＧＷ３０に対して、ＲＵＡ：ＣＯＮＮＥＣＴメッセージによって転送される。
【０１０８】
ＨＮＢ−ＧＷ３０では、ＲＵＡメッセージ処理部３０２Ａは、ＲＵＡプロトコルのＣＯＮＮＥＣＴメッセージをデコードし、呼制御部３０６Ａは、ＨＮＢ２０で既にエンコードされているＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを取り出し、ＲＡＮＡＰメッセージ処理部３０７Ａは、ステップＳ１１５において、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを、ＣＮ Ｄｏｍａｉｎ ＩＤ等のルーチング情報を基にＭＳＣ４０に送信する。
【０１０９】
ＭＳＣ４０では、ＲＡＮＡＰメッセージ処理部４０２Ａは、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージをデコードし、さらに、ＮＡＳメッセージ処理部４０３Ａは、ＮＡＳ−ＰＤＵに設定されているＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージをデコードする。これらのデコード結果は呼制御部４０４Ａに通知される。呼制御部４０４Ａは、ステップＳ１１６において、本発明で導入されるＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されているかどうかを判断し、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合には、ステップＳ１１７において、ＣＳ（Circuit Switching）サービス向けの不正対策処理を起動する。
【０１１０】
図２０に、ＣＳサービス向けの不正対策処理のフローチャートを示す。
【０１１１】
図２０を参照すると、呼制御部４０４Ａは、ステップＳ３０１において、移動局１０から送信されてきたＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（TS24.008 Ver8.5.0 セクション9.2.9）に設定されているＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（TS24.008 Ver8.5.0 セクション10.5.3.3）が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ Ｅｓｔａｂｌｉｓｈｍｅｎｔ”であるかどうかをチェックする。
【０１１２】
次に、呼制御部４０４Ａは、ステップＳ３０２において、ＭＳＣ４０が送信する発呼信号であるＣＣプロトコルのＳＥＴＵＰ（TS24.008 Ver8.5.0 セクション9.3.23 Setup）メッセージの電話番号（TS24.008 Ver8.5.0 セクション10.5.4.7）が緊急番号であるかどうかをチェックする。具体的には、TS24.008 Ver8.5.0の図10.5.91/3GPP TS 24.008 Called party BCD number information elementにおいて、Number digit 1, Number digit 2, Number digit 3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24.008のセクション10.5.4.7の、Called Party BCD Numberとは、着番号を指し、BCD (BCD、Binary-coded decimal)とは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。
【０１１３】
次に、呼制御部４０４Ａは、ステップＳ３０３において、移動局１０にてＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順（TS24.008 Ver8.5.0 セクション9.3.8）が行われているかどうかをチェックする。例えば、移動局１０から“ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”を開始するためのメッセージを受信すると、インフォメーションエレメント“Ｅｍｅｒｇｅｎｃｙ ｓｅｔｕｐ ｍｅｓｓａｇｅ ｔｙｐｅ”からＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順が行われているかどうかをチェックする。
【０１１４】
ステップＳ３０１〜Ｓ３０３のいずれかのチェックに合致すれば、呼制御部４０４Ａは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部４０４Ａは、ステップＳ３０４において、呼種別が通常呼であると判断し、不正移動局１０−２であるとみなし、呼解放処理を起動する。
【０１１５】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１１６】
（Ｂ）パケット交換呼の場合
次に、移動局１０がパケット交換の緊急呼として発呼を行った場合の動作例を説明する。
【０１１７】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、パケット交換では、ＮＡＳメッセージとして、ＳＭ（Session Management）プロトコルメッセージおよびＧＭＭ（GPRS Mobility Management）プロトコルメッセージが適用される。そのため、ステップＳ１１７で起動する不正対策処理は、ＰＳ（Packet Switching）サービス向けの不正対策処理となる。この処理は、緊急呼の識別方法がＣＳサービスとは異なる。また、パケット交換で音声が使用される場合には、ＶｏＩＰ（Voice over IP）の手法が用いられる。なお、ＧＭＭとは、パケットサービス（PS）での移動制御（Mobility Management）のためのプロトコルである。
【０１１８】
図２１に、ＰＳサービス向けの不正対策処理のフローチャートを示す。
【０１１９】
図２１を参照すると、ＳＧＳＮ５０の呼制御部５０４Ａは、ステップＳ４０１において、移動局１０から送信されてきたＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ（Packet Data Protocol） ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージ（3GPP TS24.008 Ver8.5.0 セクション9.5.1）に設定されているＡＰＮ（Access Point Name）（3GPP TS24.008 9.5.1 10.5.6.1）が緊急呼に特有のものであるかどうかをチェックする。
【０１２０】
次に、呼制御部５０４Ａは、ステップＳ４０２において、移動局１０にて行われているＧＭＭ手順がＥｍｅｒｇｅｎｃｙ Ａｔｔａｃｈ手順（TR23.869 Ver9.0.0）であるかどうかをチェックする。
【０１２１】
次に、呼制御部５０４Ａは、ステップＳ４０３において、ＳＧＳＮ５０にて起動しているＰＤＰ Ｃｏｎｔｅｘｔが緊急呼用のＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。例えば、ＳＧＳＮ５０にて起動しているＰＤＰ ＣｏｎｔｅｘｔがTR23.869 Ver9.0.0のＥｍｅｍｅｒｇｅｎｃｙ ＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。
【０１２２】
ステップＳ４０１〜Ｓ４０３のいずれかのチェックに合致すれば、呼制御部５０４Ａは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部５０４Ａは、ステップＳ５０４において、呼種別が通常呼であると判断し、不正移動局１０−２であるとみなし、呼解放処理を起動する。
【０１２３】
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１２４】
（第３の実施形態）
図２２〜図２４に、本実施形態のＭＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成をそれぞれ示す。
【０１２５】
図２２を参照すると、本実施形態のＭＳＣ４０は、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をＲＡＮＡＰプロトコルメッセージに含める制御部４１Ｂと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部４２Ｂと、を有している。
【０１２６】
また、図２３を参照すると、本実施形態のＳＧＳＮ５０は、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をＲＡＮＡＰプロトコルメッセージに含める制御部５１Ｂと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部５２Ｂと、を有している。
【０１２７】
また、図２４を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、ＭＳＣ４０あるいはＳＧＳＮ５０からＲＡＮＡＰプロトコルメッセージを受信する受信部３１Ｂと、そのＲＡＮＡＰプロトコルメッセージに呼種別が緊急呼であることを示す情報が含まれている場合に、呼解放処理を行う制御部３２Ｂと、を有している。
【０１２８】
したがって、本実施形態においては、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別が緊急呼であることを知ることができる。
【０１２９】
その結果、ＨＮＢ−ＧＷ３０は、移動局１０がＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽っていた場合には、その移動局１０の呼解放処理を実施することができるため、ＨＮＢ２０によるサービスを不正に受けることを防止することができる。
【０１３０】
（第４の実施形態）
図２５〜図２７に、本実施形態のＭＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成をそれぞれ示す。本実施形態は、図２２〜図２４の第３の実施形態のＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成および動作をより具体化した一例である。
【０１３１】
図２５を参照すると、本実施形態のＭＳＣ４０は、対ＨＮＢ−ＧＷ信号送受信部４０１Ｂと、ＲＡＮＡＰメッセージ処理部４０２Ｂと、ＮＡＳメッセージ処理部４０３Ｂと、呼制御部４０４Ｂと、局データ格納部４０５Ｂと、を有している。
【０１３２】
なお、図２５においては、ＲＡＮＡＰメッセージ処理部４０２Ｂ、ＮＡＳメッセージ処理部４０３Ｂ、呼制御部４０４Ｂ、および局データ格納部４０５Ｂにより、図２２に示した制御部４１Ｂを構成している。また、対ＨＮＢ−ＧＷ信号送受信部４０１Ｂは、図２２に示した送信部４２Ｂの一例である。
【０１３３】
対ＨＮＢ−ＧＷ信号送受信部４０１Ｂ、ＲＡＮＡＰメッセージ処理部４０２Ｂ、ＮＡＳメッセージ処理部４０３Ｂ、および局データ格納部４０５Ｂは、それぞれ、図１３に示した対ＨＮＢ−ＧＷ信号送受信部４０１Ａ、ＲＡＮＡＰメッセージ処理部４０２Ａ、ＮＡＳメッセージ処理部４０３Ａ、および局データ格納部４０５Ａと同様の機能を有している。
【０１３４】
呼制御部４０４Ｂは、図１３に示した呼制御部４０４Ａと同様に、ＭＳＣ４０に実装される呼処理部が一般に有する機能を有している。
【０１３５】
その他にも、呼制御部４０４Ｂは、本実施形態の特徴的な機能として、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ Ｔｙｐｅパラメータを設定する機能を有している。
【０１３６】
また、図２６を参照すると、本実施形態のＳＧＳＮ５０は、対ＨＮＢ−ＧＷ信号送受信部５０１Ｂと、ＲＡＮＡＰメッセージ処理部５０２Ｂと、ＮＡＳメッセージ処理部５０３Ｂと、呼制御部５０４Ｂと、局データ格納部５０５Ｂと、を有している。
【０１３７】
なお、図２６においては、ＲＡＮＡＰメッセージ処理部５０２Ｂ、ＮＡＳメッセージ処理部５０３Ｂ、呼制御部５０４Ｂ、および局データ格納部５０５Ｂにより、図２３に示した制御部５１Ｂを構成している。また、対ＨＮＢ−ＧＷ信号送受信部５０１Ｂは、図２３に示した送信部５２Ｂの一例である。
【０１３８】
対ＨＮＢ−ＧＷ信号送受信部５０１Ｂ、ＲＡＮＡＰメッセージ処理部５０２Ｂ、ＮＡＳメッセージ処理部５０３Ｂ、および局データ格納部５０５Ｂは、それぞれ、図１４に示した対ＨＮＢ−ＧＷ信号送受信部５０１Ａ、ＲＡＮＡＰメッセージ処理部５０２Ａ、ＮＡＳメッセージ処理部５０３Ａ、および局データ格納部５０５Ａと同様の機能を有している。
【０１３９】
呼制御部５０４Ｂは、図１４に示した呼制御部５０４Ａと同様に、ＳＧＳＮ５０に実装される呼処理部が一般に有する機能を有している。
【０１４０】
その他にも、呼制御部５０４Ｂは、本実施形態の特徴的な機能として、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ Ｔｙｐｅパラメータを設定する機能を有している。
【０１４１】
また、図２７を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、対ＨＮＢ信号送受信部３０１Ｂと、ＲＵＡメッセージ処理部３０２Ｂと、対ＳＧＳＮ信号送受信部３０３Ｂと、対ＭＳＣ信号送受信部３０４Ｂと、ＨＮＢＡＰメッセージ処理部３０５Ｂと、呼制御部３０６Ｂと、ＲＡＮＡＰメッセージ処理部３０７Ｂと、局データ格納部３０８Ｂと、を有している。
【０１４２】
なお、図２７においては、ＲＵＡメッセージ処理部３０２Ｂ、ＨＮＢＡＰメッセージ処理部３０５Ｂ、呼制御部３０６Ｂ、ＲＡＮＡＰメッセージ処理部３０７Ｂ、および局データ格納部３０８Ｂにより、図２４に示した制御部３２Ｂを構成している。また、対ＳＧＳＮ信号送受信部３０３Ｂおよび対ＭＳＣ信号送受信部３０４Ｂは、図２４に示した受信部３１Ｂの一例である。
【０１４３】
対ＨＮＢ信号送受信部３０１Ｂ、ＲＵＡメッセージ処理部３０２Ｂ、対ＳＧＳＮ信号送受信部３０３Ｂ、対ＭＳＣ信号送受信部３０４Ｂ、ＨＮＢＡＰメッセージ処理部３０５Ｂ、ＲＡＮＡＰメッセージ処理部３０７Ｂ、および局データ格納部３０８Ｂは、それぞれ、図１２に示した対ＨＮＢ信号送受信部３０１Ａ、ＲＵＡメッセージ処理部３０２Ａ、対ＳＧＳＮ信号送受信部３０３Ａ、対ＭＳＣ信号送受信部３０４Ａ、ＨＮＢＡＰメッセージ処理部３０５Ａ、ＲＡＮＡＰメッセージ処理部３０７Ａ、および局データ格納部３０８Ａと同様の機能を有している。
【０１４４】
呼制御部３０６Ｂは、図１２に示した呼制御部３０６Ａと同様に、ＨＮＢ−ＧＷ３０に実装される呼処理部が一般に有する機能を有している。
【０１４５】
その他にも、呼制御部３０６Ｂは、本実施形態の特徴的な機能として、ＭＳＣ４０あるいはＳＧＳＮ５０から受信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ ＴｙｐｅパラメータにＮｏｒｍａｌ Ｃａｌｌが設定されている場合に、移動局１０が発呼した呼種別が通常呼であると判断し、このときに移動局１０が緊急呼として発呼を行っていれば、呼解放処理を行う機能を有している。
【０１４６】
なお、本実施形態のＨＮＢ２０の構成は、図９と同様で構わない。ただし、ＨＮＢ２０の呼制御部２０５Ａは、ＨＮＢ２０に実装される呼処理部が一般に有する機能を有していればよい。
【０１４７】
以下に、本実施形態の移動通信システムの動作について説明する。
【０１４８】
（１）動作例１
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＣＯＭＭＯＮ ＩＤメッセージにて通知する例である。
【０１４９】
（１−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＣＯＭＭＯＮ ＩＤメッセージにて通知する場合の動作例を、図２８のシーケンス図に沿って説明する。なお、図２８は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１５０】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、シグナリングコネクションが確立された後に、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１５１】
そのため、図２８を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ５０１において、シグナリングコネクションの確立後、ステップＳ５０２において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。
【０１５２】
図２９に、ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理のフローチャートを示す。
【０１５３】
図２９を参照すると、呼制御部４０４Ｂは、ステップＳ６０１において、移動局１０から送信されてきたＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（TS24.008 Ver8.5.0 セクション9.2.9）に設定されているＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（TS24.008 Ver8.5.0 セクション10.5.3.3）が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ Ｅｓｔａｂｌｉｓｈｍｅｎｔ”であるかどうかをチェックする。
【０１５４】
次に、呼制御部４０４Ｂは、ステップＳ６０２において、ＭＳＣ４０が送信する発呼信号であるＣＣプロトコルのＳＥＴＵＰ（TS24.008 9.3.23 Ver 8.5.0 セクションSetup）メッセージの電話番号（TS24.008 Ver 8.5.0 セクション10.5.4.7）が緊急番号であるかどうかをチェックする。具体的には、TS24.008 Ver 8.5.0の図10.5.91/3GPP TS 24.008 Called party BCD number information elementにおいて、Number digit 1, Number digit 2, Number digit 3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24.008のセクション10.5.4.7の、Called Party BCD Numberとは、着番号を指し、BCDとは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。
【０１５５】
次に、呼制御部４０４Ｂは、ステップＳ６０３において、移動局１０にてＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順（TS24.008 Ver 8.5.0 セクション9.3.8）が行われているかどうかをチェックする。例えば、移動局１０から“ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”を開始するためのメッセージを受信すると、インフォメーションエレメント“Ｅｍｅｒｇｅｎｃｙ ｓｅｔｕｐ ｍｅｓｓａｇｅ ｔｙｐｅ”からＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順が行われているかどうかをチェックする。
【０１５６】
ステップＳ６０１〜Ｓ６０３のいずれかのチェックに合致すれば、呼制御部４０４Ｂは、ステップＳ６０４において、呼種別が緊急呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部４０４Ｂは、ステップＳ６０５において、呼種別が通常呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”に決定する。
【０１５７】
再度図２８を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ５０３において、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージの構成を、図３０に示す。
【０１５８】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ステップＳ５０４において、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ５０５において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１５９】
図３１は、本実施形態のＨＮＢ−ＧＷ３０における処理を、呼種別に応じて決定するためのテーブルを示す図である。
【０１６０】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１６１】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１６２】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＣＯＭＭＯＮ ＩＤメッセージにて通知する場合の動作例を説明する。
【０１６３】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ５０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。
【０１６４】
図３２に、ＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理のフローチャートを示す。
【０１６５】
図３２を参照すると、呼制御部５０４Ｂは、ステップＳ７０１において、移動局１０から送信されてきたＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージ（3GPP TS24.008 Ver8.5.0 セクション9.5.1）に設定されているＡＰＮ（3GPP TS24.008 9.5.1 10.5.6.1）が緊急呼に特有のものであるかどうかをチェックする。
【０１６６】
次に、呼制御部５０４Ｂは、ステップＳ７０２において、移動局１０にて行われているＧＭＭ手順がＥｍｅｒｇｅｎｃｙ Ａｔｔａｃｈ手順（TR23.869 Ver9.0.0）であるかどうかをチェックする。
【０１６７】
次に、呼制御部５０４Ｂは、ステップＳ７０３において、ＳＧＳＮ５０にて起動しているＰＤＰ Ｃｏｎｔｅｘｔが緊急呼用のＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。例えば、ＳＧＳＮ５０にて起動しているＰＤＰ ＣｏｎｔｅｘｔがTR23.869 Ver9.0.0のＥｍｅｍｅｒｇｅｎｃｙ ＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。
【０１６８】
ステップＳ７０１〜Ｓ７０３のいずれかのチェックに合致すれば、呼制御部５０４Ｂは、ステップＳ７０４において、呼種別が緊急呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部５０４Ｂは、ステップＳ７０５において、呼種別が通常呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”に決定する。
【０１６９】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージの構成は、図３０に示すように、ＭＳＣ４０の場合と同様である。
【０１７０】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１７１】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１７２】
（２）動作例２
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する例である。
【０１７３】
（２−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する場合の動作例を、図３３のシーケンス図に沿って説明する。なお、図３３は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１７４】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、ＣＣプロトコルやＭＭプロトコルのようなＮＡＳメッセージを送信する場合に、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１７５】
そのため、図３３を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ８０１において、ＮＡＳメッセージの送信後、ステップＳ８０２において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図２９に示される通りである。
【０１７６】
ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ８０３において、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を、図３４に示す。
【０１７７】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ受信時に、ステップＳ８０４において、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ８０５において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１７８】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１７９】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１８０】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する場合の動作例を説明する。
【０１８１】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ８０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。このＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図３２に示される通りである。
【０１８２】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成は、図３４に示すように、ＭＳＣ４０の場合と同様である。
【０１８３】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１８４】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１８５】
（３）動作例３
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＲＡＢ（Radio Access Bearer） ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する例である。
【０１８６】
（３−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する場合の動作例を、図３５のシーケンス図に沿って説明する。なお、図３５は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１８７】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、移動局１０からの呼確立要求を受信して、無線アクセスベアラを確立する場合に、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１８８】
そのため、図３５を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ９０１において、移動局１０からの呼確立要求の受信後、ステップＳ９０２において、無線アクセスベアラにためのＱｏＳ（Quality of Service）を決定し、その後、ステップＳ９０３において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図２９に示される通りである。
【０１８９】
ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ９０４において、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成を、図３６に示す。
【０１９０】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、ステップＳ９０５において、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ９０６において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１９１】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１９２】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１９３】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する場合の動作例を説明する。
【０１９４】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ８０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。このＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図３２に示される通りである。
【０１９５】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成は、図３６に示すように、ＭＳＣ４０の場合と同様である。
【０１９６】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１９７】
図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１９８】
なお、本発明のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０にて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
【０１９９】
（第５の実施形態）
第２の実施形態では、不正対策処理をＭＳＣ４０あるいはＳＧＳＮ５０にて行っているが、本実施形態では、不正対策処理をＨＮＢ−ＧＷ３０にて行う。
【０２００】
この場合におけるシーケンスを図３７に示す。図３７は、ＨＮＢ−ＧＷが予めＵＥ Ｒｅｇｉｓｔｅｒ手順において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅ＝Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌを通知されているケースにおいてＨＮＢ−ＧＷがＮＡＳメッセージの中身をチェックして、不正対策処理を起動するケースを示している。これは、図１５において、ＭＳＣが、ＨＮＢ−ＧＷよりＵＥが緊急呼として発呼していたことの通知を受けている場合に、図２０において、ＭＭあるいはＣＣプロトコルのメッセージのチェック処理を実施していたことに相当する。また、同様に、ＳＧＳＮが、ＨＮＢ−ＧＷよりＵＥが緊急呼として発呼していたことを示す場合に、図２１において、ＧＭＭあるいはＳＭプロトコルのメッセージのチェック処理を実施していたことに相当する。なお、ＮＡＳメッセージとは、Ｎｏｎ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍを指し、無線アクセス方式に依存しないプロトコルを指す。
【０２０１】
本実施形態により以下の効果を奏する。
・ＨＮＧ−ＧＷにて、不正対策処理を実施するため、ＭＳＣあるいはＳＧＳＮに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のＭＳＣあるいはＳＧＳＮに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。
・第２の実施形態に比べて、ＲＡＮＡＰプロトコルに新たなパラメータの追加が不要となるため、ＲＡＮＡＰプロトコルのメッセージサイズを削減し、ＨＮＢ−ＧＷとＭＳＣあるいはＳＧＳＮ間のシグナリングの通信量を減少させることができる。
・ＨＮＢ−ＧＷがＮＡＳメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、ＭＳＣあるいはＳＧＳＮより呼の種別の通知を受けなくても、ＨＮＢ−ＧＷが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。
【０２０２】
（第６の実施形態）
第５の実施形態では、端末が緊急呼として発呼している場合に、ＨＮＢ−ＧＷがＮＡＳメッセージをのぞくことにより、不正対策処理を実現しているが、本実施形態では、本不正対策処理をＨＮＢで行う。つまり、図３８に示されるように、ＨＮＢがＮＡＳメッセージをのぞき、不正対策処理を起動する。
【０２０３】
本実施形態により以下の効果を奏する。
・ＨＮＢにて、不正対策処理を実施するため、上位装置が不正対策処理を実行するケースに比べて、より早期に、不正な端末との通信を終了することができる。これによって、ネットワークのリソースの利用性を高めて、ＨＮＢとＨＮＢ−ＧＷ間のシグナリングを減らすことができる。
・ＨＮＢがＮＡＳメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、ＭＳＣあるいはＳＧＳＮより呼の種別の通知を受けなくても、ＨＮＢが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。
【０２０４】
（第７の実施形態）
第３の実施形態では、ＭＳＣあるいはＳＧＳＮが緊急呼の情報をＨＮＢ−ＧＷに通知し、ＨＮＢ−ＧＷはＵＥが緊急呼としてアクセスしてきたかどうかを確認する。また、第４の実施形態では、ＲＡＮＡＰプロトコルにおいて、Ｃａｌｌ Ｔｙｐｅというパラメータを使用していた。
【０２０５】
本実施形態では、ＲＡＮＡＰの緊急呼を示す情報として、既に、３ＧＰＰ ＴＳ２５．４１３で定義されたＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙと呼ばれるパラメータを使用する（図３９参照）。
【０２０６】
Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙの使用方法については、公知の技術としてよく知られているものであり、本発明の対象外である。例えば、新しいベアラを割り当てるためのリソースが確保できない場合において、他の優先度の低いベアラを解放して、リソースを空けることで、新しいベアラがそのリソースを獲得するというプリエンプションのために使用される。
【０２０７】
ＭＳＣあるいはＳＧＳＮが、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにおいて、本Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを、緊急呼の場合には、以下のように設定する。
【０２０８】
Priority Level = 1
Pre-emption Capability = "may trigger pre-emption"
Pre-emption Vulnerability = not pre-emptable
このように設定することで、緊急呼として確立することを通知することができる。さらに、ＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ以外のほかのメッセージでもよい。この場合に、ＭＳＣあるいはＳＧＳＮでのＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを緊急呼設定する場合の設定論理は、図２９および図３２と同様であり、図４０および図４１のようになる。
【０２０９】
図４０および図４１においては、本Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータが通常呼を示しているが、ＵＥ Ｒｅｇｉｓｔｒａｔｉｏｎ手順におけるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅ値が緊急呼を示す場合には、ＨＮＢ−ＧＷは、ＵＥがＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを偽ってアクセスしてきたと判断し、呼解放を実施する。この場合の動作シーケンスを図４２に示す。
【０２１０】
本実施形態により以下の効果を奏する。
・既存のＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙを用いて緊急呼かどうかを通知するため、ＭＳＣあるいはＳＧＳＮに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のＭＳＣあるいは、ＳＧＳＮに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。
・第４の実施形態に比べて、ＲＡＮＡＰプロトコルに新たなパラメータの追加が不要となるため、ＲＡＮＡＰプロトコルのメッセージサイズを削減し、ＨＮＢ−ＧＷとＭＳＣあるいはＳＧＳＮ間のシグナリングの通信量を減少させることができる。
【０２１１】
（第８の実施形態）
第７の実施形態では、ＨＮＢ−ＧＷがＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを判断し、不正対策処理を実現しているが、本実施形態では、本不正対策処理をＨＮＢで行う。つまり、図４３に示されるように、ＨＮＢがＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージを受信時に、Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙを判断し、それが通常呼であった場合に、ＵＥ Ｒｅｇｉｓｔｒａｔｉｏｎ手順におけるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅが緊急呼であった場合には、ＨＮＢ−ＧＷは、ＵＥがＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを偽ってアクセスしてきたと判断し、呼解放を実施する。
【０２１２】
なお、第３の実施形態および第４の実施形態では、ＨＮＢ−ＧＷがＭＳＣあるいはＳＧＳＮより通知される呼種別とＵＥがアクセスしてきた際のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅの比較処理を実施しているが、本比較処理はＨＮＢで実施してもよい。
【０２１３】
本実施形態により以下の効果を奏する。
・ＨＮＢ−ＧＷでは、ＲＡＮＡＰプロトコルメッセージを終端し、Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙによって呼種別を判断する必要がなくなるため、ＨＮＢ−ＧＷの処理を簡単にすることが可能となる。
【０２１４】
以上、本発明を、好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【０２１５】
例えば、第２の実施形態では、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅ値のＲＡＮＡＰプロトコルメッセージへの設定をＨＮＢ２０にて行っているが、ＨＮＢ−ＧＷ３０にて行うこととしてもよい。
【０２１６】
また、第１〜第４の実施形態によれば、ＲＡＮＡＰプロトコルメッセージを用いて、移動局１０が緊急呼として発呼を行ったことを示す情報または移動局１０が発呼した実際の呼種別が緊急呼であることを示す情報を、ＨＮＢ２０、ＨＮＢ−ＧＷ３０およびコアネットワーク装置（ＭＳＣ４０またはＳＧＳＮ５０）間で通信した。しかし、ＲＡＮＡＰプロトコルメッセージに限らず、ＨＮＢ２０、ＨＮＢ−ＧＷ３０またはコアネットワーク装置間で通信可能なメッセージであれば他のメッセージであってもよい。
【０２１７】
本出願は、２００９年１０月０１日に出願された日本出願特願２００９−２２９３９１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【技術分野】
【０００１】
本発明は、移動通信システムに関する。
【背景技術】
【０００２】
フェムト基地局（Ｈｏｍｅ ＮｏｄｅＢ、以下、ＨＮＢと略す）の産業上の利用形態としては、例えば、家庭用の小型無線基地局として利用する形態や、企業内における小型無線基地局として利用する形態が考えられている。
【０００３】
ＨＮＢによりサービスを提供する場合には、例えば、以下のような利点がある。
【０００４】
（１）マクロ基地局の電波が届かない不感地帯での通話サービスを提供することができる
（２）マクロ基地局が提供する通常の課金サービスよりも安い課金サービスを提供することができる
（３）基地局と移動局との距離が近く、移動局が高い無線品質（Ｅｃ／Ｉｏ）を得ることができるため、６４ＱＡＭ（64 Quadrature Amplitude Modulation）やＭＩＭＯ（Multiple Input Multiple Output）の高速化技術を活かすことができ、ＨＮＢ配下において高速パケットサービスを提供することができる
（４）ＨＮＢの局所性を活かした特有のコンテンツサービスを提供することができる
このように、ＨＮＢによるサービスは、多くの利点を有するため、通信事業者と契約を結んだ加入者や、そのＨＮＢの所持者が許容した加入者のみに提供されるべきである。
【０００５】
そこで、３ＧＰＰ（3rd Generation Partnership Project）では、許容されたグループの移動局のみがＨＮＢにアクセスし、サービスを受けられるようにするために、リリース８において、ＣＳＧ（Closed Subscriber Group）を導入している。
【０００６】
ここで、ＣＳＧについて、図１を参照して詳細に説明する。
【０００７】
図１に示す第３世代の移動通信システムは、ＨＮＢ２０と、フェムト基地局ゲートウェイ（Ｈｏｍｅ ＮｏｄｅＢ ＧＷ、以下、ＨＮＢ−ＧＷと略す）３０と、回線交換局（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ、以下、ＭＳＣと略す）４０と、パケット交換局（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ、以下、ＳＧＳＮと略す）５０と、第３世代対応の移動局１０−１，１０−２と、を有している。
【０００８】
なお、図１において、ＨＮＢ２０の配下に在圏する移動局１０−１，１０−２のうち、移動局１０−１は、正当な移動局である。これに対し、移動局１０−２は、ＨＮＢ２０によるサービスを不正に受けようとする移動局であり、以下、不正移動局１０−２と称す。また、以下、どちらの移動局かを特定しない場合は、移動局１０と称す。
【０００９】
ＨＮＢ２０は、ＨＮＢ−ＧＷ３０を介してオペレータのコアネットワークに接続されている。
【００１０】
コアネットワークは、コアネットワーク装置として、回線交換を制御するＭＳＣ４０と、パケット交換を制御するＳＧＳＮ５０と、を含んでいる。
【００１１】
ＨＮＢ２０は、ＣＳＧ機能をサポートしている場合には、自身のＣＳＧセル（CSG Cell）のＣＳＧ識別子（CSG identity）を、自身の配下に在圏する移動局１０に報知する。
【００１２】
移動局１０−１は、ＨＮＢ２０から報知されたＣＳＧ識別子をデコードし、自身の持っているＣＳＧリストにそのＣＳＧ識別子が含まれているかどうかを判断する。
【００１３】
ＣＳＧリストにＣＳＧ識別子が含まれていれば、移動局１０−１は、自身が在圏するＣＳＧセルにキャンプオンし、発信、着信といった様々なサービスを受けることができる。
【００１４】
一方、ＣＳＧリストにＣＳＧ識別子が含まれていなければ、移動局１０−１は、自身が在圏するＣＳＧセルにはキャンプオンせずに、そのＣＳＧセルとは別の適切なＣＳＧセルを選択する動作を行う。
【００１５】
このようなメカニズムによって、ＨＮＢ２０には、そのＨＮＢ２０のＣＳＧセルのＣＳＧ識別子を持つ限られた移動局１０−１のみがアクセス可能になる。
【００１６】
ただし、図１に示した不正移動局１０−２のように、ＣＳＧ機能をサポートしているにも関わらず、本来、アクセスできないＨＮＢ２０のＣＳＧセルにて、不正にサービスを受けようとするケースが考えられる。
【００１７】
このようなケースにおいては、ＭＳＣ４０あるいはＳＧＳＮ５０が、移動局１０のＩＭＳＩ（International Mobile Subscriber Identity）とその移動局１０が在圏しているＣＳＧセルのＣＳＧ識別子とをチェックすることによって、その移動局１０によるＨＮＢ２０へのアクセスを規制するアクセス規制を行う（3GPP TS25.467 Ver8.0.0 5.1.3節）。
【００１８】
一方、ＣＳＧ機能は、３ＧＰＰのリリース８より導入されている機能であるため、リリース８以前の移動局１０−１がＣＳＧ機能をサポートしていないケースがある。また、ＨＮＢ２０がＣＳＧ機能をサポートしていないケースもある。
【００１９】
このようなケースにおいては、ＨＮＢ２０は、移動局１０−１のＩＭＳＩを問い合わせるために、移動局１０−１に対してＩｄｅｎｔｉｆｉｃａｔｉｏｎ手順（3GPP TS24.008 Ver8.4.0）を実施し、また、移動局１０−１をＨＮＢ−ＧＷ３０に登録するために、ＨＮＢ−ＧＷ３０に対してＨＮＢＡＰ（HNB Application Part）：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴ手順（3GPP TS25.469 Ver8.0.0）を実施する。この際に、ＨＮＢ−ＧＷ３０は、移動局１０−１のＩＭＳＩがＨＮＢ２０にアクセスできるものかどうかをチェックすることによって、アクセス規制を行う。
【００２０】
ＨＮＢ−ＧＷ３０は、移動局１０−１がＨＮＢ２０にアクセスできると判断した場合には、アクセスが許可されることを、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージによってＨＮＢ２０に通知する。これにより、ＨＮＢ２０によるサービスが移動局１０−１に対して提供される。
【００２１】
一方、移動局１０が図１に示した不正移動局１０−２である場合には、不正移動局１０−２のＩＭＳＩはＣＳＧにアクセスできるように登録されていない。そのため、ＨＮＢ−ＧＷ３０は、不正移動局１０−２がＨＮＢ２０にアクセスできないと判断し、アクセスが許可されないことを、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＪＥＣＴメッセージによってＨＮＢ２０に通知する。これにより、不正移動局１０−２とＨＮＢ２０との間のＲＲＣ（Radio Resource Control）コネクションは切断される（3GPP TS25.467 Ver8.0.0 5.1.2節）。
【００２２】
上記により、ＨＮＢ２０によるサービスを提供するに際しては、ＭＳＣ４０、ＳＧＳＮ５０、あるいはＨＮＢ−ＧＷ３０が、移動局１０のＩＭＳＩを基に、アクセス規制を行っているため、ＨＮＢ２０へのアクセスが許容されていない不正移動局１０−２が仮に発信を行ったとしても、信号確立手順中に移動通信ネットワーク側によりＨＮＢ２０へのアクセスが拒絶されることとなる。
【００２３】
一方、３ＧＰＰの標準化においては、本来、ＨＮＢ２０へのアクセスが許容されていない移動局１０であっても、呼種別が緊急呼である場合は発呼を可能とすることが定められている（3GPP TS22.011 Ver 8.6.0 8.5.1節）。
【００２４】
呼種別が緊急呼である場合、移動局１０−１は、ＲＲＣコネクション確立要求時あるいはシグナリングコネクション確立要求時にＨＮＢ２０に送信するＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージあるいはＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲにおいて、確立要求の要因を示すＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータに“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”と設定する（3GPP TS25.331 Ver8.5.0 10.3.3.11節、特許文献１）。
【００２５】
そして、ＨＮＢ２０は、ＨＮＢ−ＧＷ３０に送信するＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”値に設定する。
【００２６】
Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”である場合には、ＨＮＢ−ＧＷ３０は、ＩＭＳＩに基づくアクセス規制を実施しない（3GPP TS25.467 Ver8.0.0 5.1.2節）。
【００２７】
この手法によって、本来、ＨＮＢ２０にアクセスしてはならない移動局１０であっても、呼種別が緊急呼である場合には、ＨＮＢ−ＧＷ３０のアクセス規制をスキップし、ＨＮＢ２０へのアクセスが可能となる。
【００２８】
ここで、図２に、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージの構成を示し、また、図３に、ＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示し、また、図４に、ＲＲＣプロトコルにおける、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータの構成を示し、また、図５に、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージの構成を示し、また、図６に、ＨＢＮＡＰプロトコルにおける、Ｒｅｇｓｉｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの構成を示す。
【先行技術文献】
【特許文献】
【００２９】
【特許文献１】特開２００３−２４４２８４号公報
【発明の概要】
【発明が解決しようとする課題】
【００３０】
ところで、上述した技術は、移動局１０が緊急呼として発呼を行った場合には、ＨＮＢ−ＧＷ３０のアクセス規制をスキップし、移動局１０によるＨＮＢ２０へのアクセスを許可するものである。
【００３１】
そのため、不正移動局１０−２のように、本来はＨＮＢ２０へアクセスできない移動局１０であっても、ＲＲＣプロトコルにおける、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”と偽り、ＨＮＢ−ＧＷ３０のアクセス規制の対象外となることによって、ＨＮＢ２０へのアクセスが可能となってしまう。
【００３２】
このような不正移動局１０−２は、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータのみを改ざんするようにソフトウェアを改造することによって、容易に作ることができると考えられる。
【００３３】
あるいは、正当な移動局１０−１から共通チャネル（ＲＡＣＨ：Random Access Channel）上に送信される、秘匿も改ざん対策もされていないＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをデコードし、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ”に置き換えて、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをエンコードしてＨＮＢ２０に送信する装置が介在する場合もある。この場合、正当な移動局１０−１であっても、上述のような不正移動局１０−２と同視されることになる。
【００３４】
このような不正移動局１０−２により、以下のような問題が生じる。
【００３５】
（１）家庭用あるいは企業に設置されたＨＮＢ２０が、不正移動局１０−２により不正に使用されてしまう
（２）不正移動局１０−２は、ＨＮＢ２０を介した発信を行うことによって、通常の課金サービスよりも安い課金サービスを不正に受けることができてしまう
（３）特定のユーザ向けへのコンテンツサービスを不正移動局１０−２が不正に受けてしまう
このような問題を解決する方法としては、移動局１０が緊急呼として発呼を行った場合に、コアネットワーク装置側で、その移動局１０の呼解放処理を行うことが考えられる。そのためには、コアネットワーク装置は、移動局１０が緊急呼として発呼を行ったことを知る必要がある。
【００３６】
しかし、現状の構成では、コアネットワーク装置は、移動局１０が緊急呼として発呼を行ったことを知ることができない。
【００３７】
あるいは、ＨＮＢ−ＧＷ３０側で、緊急呼と偽って発呼を行った移動局１０の呼解放処理を行うことも考えられる。そのためには、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別が緊急呼であるかを知る必要がある。
【００３８】
しかし、現状の構成では、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別を知ることができない。
【００３９】
本発明の目的は、コアネットワーク装置が、移動局が緊急呼として発呼を行ったことを知ることができる移動通信システムを提供することにある。
【００４０】
本発明の他の目的は、ゲートウェイ装置が、移動局が実際に発呼した呼種別を知ることができる移動通信システムを提供することにある。
【課題を解決するための手段】
【００４１】
本発明の移動通信システムは、
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、
前記基地局は、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、
前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、
前記ゲートウェイ装置は、
前記基地局から、前記登録メッセージを受信する第１の受信手段と、
前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、
を有する。
【００４２】
本発明のゲートウェイ装置は、
基地局を、コアネットワークに接続するゲートウェイ装置であって、
移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信する第１の受信手段と、
前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行するチェック手段と、
を有する。
【００４３】
本発明の第１の通信方法は、
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、
前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、
前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、
前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、
前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、
前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。
【００４４】
本発明の第２の通信方法は、
基地局を、コアネットワークに接続するゲートウェイ装置による通信方法であって、
移動局を前記ゲートウェイ装置に登録するための登録メッセージを、前記基地局から受信し、
前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記基地局から受信し、
前記登録メッセージと前記確立メッセージとの一貫性のチェックを実行する。
【発明の効果】
【００４５】
本発明の第１の移動通信システムによれば、基地局あるいはゲートウェイ装置は、移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めて、コアネットワーク装置に送信する。
【００４６】
したがって、コアネットワーク装置は、移動局が緊急呼として発呼を行ったことを知ることができるという効果が得られる。
【００４７】
本発明の第２の移動通信システムによれば、コアネットワーク装置は、移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めて、ゲートウェイ装置に送信する。
【００４８】
したがって、ゲートウェイ装置は、移動局が実際に発呼した呼種別が緊急呼であることを知ることができるという効果が得られる。
【図面の簡単な説明】
【００４９】
【図１】第３世代の移動通信システムの構成を示す図である。
【図２】ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図３】ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示す図である。
【図４】Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅパラメータの構成を示す図である。
【図５】ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図６】Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの構成を示す図である。
【図７】本発明の第１の実施形態のＨＮＢの構成を示すブロック図である。
【図８】本発明の第１の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図９】本発明の第１の実施形態のＭＳＣの構成を示すブロック図である。
【図１０】本発明の第１の実施形態のＳＧＳＮの構成を示すブロック図である。
【図１１】本発明の第２の実施形態のＨＮＢの構成を示すブロック図である。
【図１２】本発明の第２の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図１３】本発明の第２の実施形態のＭＳＣの構成を示すブロック図である。
【図１４】本発明の第２の実施形態のＳＧＳＮの構成を示すブロック図である。
【図１５】本発明の第２の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図１６】ＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図１７】ＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータの構成を示す図である。
【図１８】ＨＮＢよるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの決定処理を示すフローチャートである。
【図１９】本発明に係るＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが追加されたＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージの構成を示す図である。
【図２０】本発明の第２の実施形態のＭＳＣによる不正対策処理を示すフローチャートである。
【図２１】本発明の第２の実施形態のＳＧＳＮによる不正対策処理を示すフローチャートである。
【図２２】本発明の第３の実施形態のＭＳＣの構成を示すブロック図である。
【図２３】本発明の第３の実施形態のＳＧＳＮの構成を示すブロック図である。
【図２４】本発明の第３の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図２５】本発明の第４の実施形態のＭＳＣの構成を示すブロック図である。
【図２６】本発明の第４の実施形態のＳＧＳＮの構成を示すブロック図である。
【図２７】本発明の第４の実施形態のＨＮＢ−ＧＷの構成を示すブロック図である。
【図２８】本発明の第４の実施形態の移動通信システムの動作例１を説明するシーケンス図である。
【図２９】本発明の第４の実施形態のＭＳＣによるＣａｌｌ Ｔｙｐｅパラメータの決定処理を示すフローチャートである。
【図３０】本発明に係るＣＯＭＭＯＮ ＩＤメッセージの構成を示す図である。
【図３１】本発明の第４の実施形態のＨＮＢ−ＧＷにおける処理を、呼種別に応じて決定するためのテーブルを示す図である。
【図３２】本発明の第４の実施形態のＳＧＳＮによるＣａｌｌ Ｔｙｐｅパラメータの決定処理を示すフローチャートである。
【図３３】本発明の第４の実施形態の移動通信システムの動作例２を説明するシーケンス図である。
【図３４】本発明に係るＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を示す図である。
【図３５】本発明の第４の実施形態の移動通信システムの動作例３を説明するシーケンス図である。
【図３６】本発明に係るＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成を示す図である。
【図３７】本発明の第５の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図３８】本発明の第６の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図３９】本発明の第７の実施形態に係るＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙのパラメータを示す図である。
【図４０】本発明の第７の実施形態のＭＳＣによる呼種別設定処理を示すフローチャートである。
【図４１】本発明の第７の実施形態のＳＧＳＮによる呼種別設定処理を示すフローチャートである。
【図４２】本発明の第７の実施形態の移動通信システムの動作を説明するシーケンス図である。
【図４３】本発明の第８の実施形態の移動通信システムの動作を説明するシーケンス図である。
【発明を実施するための形態】
【００５０】
以下に、本発明を実施するための最良の形態について図面を参照して説明する。
【００５１】
なお、以下で説明する実施形態において、移動通信システムの全体構成自体は、図１の移動通信システムと同様であるとする。
【００５２】
（第１の実施形態）
図７〜図１０に、本実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成をそれぞれ示す。
【００５３】
図７を参照すると、本実施形態のＨＮＢ２０は、移動局１０が緊急呼として発呼を行ったことを示す情報をＲＡＮＡＰ（Radio Access Network Application Part）プロトコルメッセージに含める制御部２１Ａと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部２２Ａと、を有している。なお、ＲＡＮＡＰプロトコルメッセージとは、無線アクセスネットワークのアプリケーション層のメッセージであり、例えば、UEとコアネットワーク装置間で送受信されるＣＣ／ＭＭ信号をＲＡＮ内で透過的に転送する昨日を有するものである。
【００５４】
また、図８を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、ＨＮＢ２０からＲＡＮＡＰプロトコルメッセージを受信する受信部３１Ａと、そのＲＡＮＡＰプロトコルメッセージを取り出す制御部３２Ａと、そのＲＡＮＡＰプロトコルメッセージをＭＳＣ４０あるいはＳＧＳＮ５０に送信する送信部３３Ａと、を有している。
【００５５】
また、図９を参照すると、本実施形態のＭＳＣ４０は、ＨＮＢ−ＧＷ３０からＲＡＮＡＰプロトコルメッセージを受信する受信部４１Ａと、そのＲＡＮＡＰプロトコルメッセージに移動局１０が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を行う制御部４２Ａと、を有している。
【００５６】
また、図１０を参照すると、本実施形態のＳＧＳＮ５０は、ＨＮＢ−ＧＷ３０からＲＡＮＡＰプロトコルメッセージを受信する受信部５１Ａと、そのＲＡＮＡＰプロトコルメッセージに移動局１０が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を実施する制御部５２Ａと、を有している。
【００５７】
したがって、本実施形態においては、ＭＳＣ４０あるいはＳＧＳＮ５０が、移動局１０が緊急呼として発呼を行ったことを知ることができる。
【００５８】
その結果、ＭＳＣ４０あるいはＳＧＳＮ５０は、移動局１０がＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽っていた場合には、その移動局１０の呼解放処理を実施することができるため、ＨＮＢ２０によるサービスを不正に受けることを防止することができる。
【００５９】
（第２の実施形態）
図１１〜図１４に、本実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成をそれぞれ示す。本実施形態は、図７〜図１０の第１の実施形態のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０の構成および動作をより具体化した例である。
【００６０】
図１１を参照すると、本実施形態のＨＮＢ２０は、対移動局信号送受信部２０１Ａと、ＲＵＡ（RANAP User Adaption）メッセージ処理部２０２Ａと、対ＨＮＢ−ＧＷ信号送受信部２０３Ａと、ＨＮＢＡＰメッセージ処理部２０４Ａと、呼制御部２０５Ａと、ＲＲＣメッセージ処理部２０６Ａと、ＲＡＮＡＰメッセージ処理部２０７Ａと、を有している。
【００６１】
なお、図１１においては、ＲＵＡメッセージ処理部２０２Ａ、ＨＮＢＡＰメッセージ処理部２０４Ａ、呼制御部２０５Ａ、ＲＲＣメッセージ処理部２０６Ａ、およびＲＡＮＡＰメッセージ処理部２０７Ａにより、図７に示した制御部２１Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部２０３Ａは、図７に示した送信部２２Ａの一例である。
【００６２】
対移動局信号送受信部２０１Ａは、移動局１０との間でＲＲＣプロトコルメッセージを送受信するための機能として、メッセージを秘匿（暗号化、復号化）する秘匿機能、メッセージの送達を確認する信号送達確認機能、メッセージを分配する信号分配機能等を有している。
【００６３】
対ＨＮＢ−ＧＷ信号送受信部２０３Ａは、ＨＮＢ−ＧＷ３０との間でＨＮＢＡＰプロトコルメッセージやＲＵＡプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能、信号分配機能等を有している。
【００６４】
ＲＲＣメッセージ処理部２０６Ａは、移動局１０へ送信するＲＲＣプロトコルメッセージをエンコードする機能、および、移動局１０から受信するＲＲＣプロトコルメッセージをデコードする機能を有している。
【００６５】
ＨＮＢＡＰメッセージ処理部２０４Ａは、ＨＮＢ−ＧＷ３０へ送信するＨＮＢＡＰプロトコルメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＨＮＢＡＰプロトコルメッセージをデコードする機能を有している。
【００６６】
ＲＡＮＡＰメッセージ処理部２０７Ａは、ＨＮＢ−ＧＷ３０へ送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００６７】
ＲＵＡプロトコルは、ＲＡＮＡＰプロトコルメッセージを転送する働きをするプロトコルであり、ＲＵＡメッセージ処理部２０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＵＡプロトコルメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＵＡプロトコルメッセージをデコードする機能を有している。
【００６８】
呼制御部２０５Ａは、ＲＲＣプロトコルメッセージやＲＡＮＡＰプロトコルメッセージを基に、ＲＲＣコネクションの確立、ベアラの確立、移動制御などの様々な呼処理を起動する。さらに、呼制御部２０５Ａは、ＨＮＢＡＰプロトコルを起動して、ＨＮＢ−ＧＷ３０への移動局１０の登録処理を実施する。以上の機能は、ＨＮＢ２０に実装される呼処理部が一般に有する機能である。
【００６９】
その他にも、呼制御部２０５Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信したＨＮＢＡＰプロトコルメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅ値を設定する機能を有している。
【００７０】
また、図１２を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、対ＨＮＢ信号送受信部３０１Ａと、ＲＵＡメッセージ処理部３０２Ａと、対ＳＧＳＮ信号送受信部３０３Ａと、対ＭＳＣ信号送受信部３０４Ａと、ＨＮＢＡＰメッセージ処理部３０５Ａと、呼制御部３０６Ａと、ＲＡＮＡＰメッセージ処理部３０７Ａと、局データ格納部３０８Ａと、を有している。
【００７１】
なお、図１２においては、ＲＵＡメッセージ処理部３０２Ａ、ＨＮＢＡＰメッセージ処理部３０５Ａ、呼制御部３０６Ａ、ＲＡＮＡＰメッセージ処理部３０７Ａ、および局データ格納部３０８Ａにより、図８に示した制御部３２Ａを構成している。また、対ＨＮＢ信号送受信部３０１Ａは、図８に示した受信部３１Ａの一例であり、また、対ＳＧＳＮ信号送受信部３０３Ａおよび対ＭＳＣ信号送受信部３０４Ａは、図８に示した送信部３３Ａの一例である。
【００７２】
対ＨＮＢ信号送受信部３０１Ａは、ＨＮＢ２０との間でＲＵＡプロトコルメッセージやＨＮＢＡＰプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能等を有している。
【００７３】
対ＭＳＣ信号送受信部３０４Ａは、ＭＳＣ４０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、メッセージの順序を制御する順序制御機能、送達確認機能等を有している。
【００７４】
対ＳＧＳＮ信号送受信部３０３Ａは、ＳＧＳＮ５０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００７５】
ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢ２０へ送信するＨＮＢＡＰプロトコルメッセージをエンコードする機能、および、ＨＮＢから受信するＨＮＢＡＰプロトコルメッセージをデコードする機能を有している。
【００７６】
ＲＵＡメッセージ処理部３０２Ａは、ＨＮＢ２０へ送信するＲＵＡプロトコルメッセージをエンコードする機能、および、ＨＮＢ２０から受信するＲＵＡプロトコルメッセージをデコードする機能を有している。
【００７７】
ＲＡＮＡＰメッセージ処理部３０７Ａは、ＭＳＣ４０に送信するＲＡＮＡＰプロトコルメッセージをエンコードする機能、および、ＭＳＣ４０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００７８】
呼制御部３０６Ａは、ＨＮＢ１０３の登録処理や、移動局１０の登録処理を行う。また、呼制御部３０６Ａは、局データ格納部３０８Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＨＮＢ−ＧＷ３０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＨＮＢ−ＧＷ３０に実装される呼処理部が一般に有する機能である。
【００７９】
また、図１３を参照すると、本実施形態のＭＳＣ４０は、対ＨＮＢ−ＧＷ信号送受信部４０１Ａと、ＲＡＮＡＰメッセージ処理部４０２Ａと、ＮＡＳ（Non Access Stratum）メッセージ処理部４０３Ａと、呼制御部４０４Ａと、局データ格納部４０５Ａと、を有している。
【００８０】
なお、図１３においては、ＲＡＮＡＰメッセージ処理部４０２Ａ、ＮＡＳメッセージ処理部４０３Ａ、呼制御部４０４Ａ、および局データ格納部４０５Ａにより、図９に示した制御部４２Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部４０１Ａは、図９に示した受信部４１Ａの一例である。
【００８１】
対ＨＮＢ−ＧＷ信号送受信部４０１Ａは、ＨＮＢ−ＧＷ３０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００８２】
ＲＡＮＡＰメッセージ処理部４０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００８３】
ＮＡＳメッセージ処理部４０３Ａは、移動局１０との間でＮＡＳプロトコル（ＣＣ（Call Control）プロトコル、ＭＭ（Mobility Management）プロトコル）のメッセージの送受信を行うための機能を有している。
【００８４】
呼制御部４０４Ａは、呼確立、呼解放などの呼処理を行う呼処理機能や、位置登録やハンドオーバなどの移動制御を行う移動制御機能、さらに、ＨＮＢ２０へのアクセスを規制するアクセス規制機能を有している。呼制御部４０４Ａは、局データ格納部４０５Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＭＳＣ４０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＭＳＣ４０に実装される呼処理部が一般に有する機能である。
【００８５】
その他にも、呼制御部４０４Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージにＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合に、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部４０４Ａは、呼解放処理を行うことになる。
【００８６】
また、図１４を参照すると、本実施形態のＳＧＳＮ５０は、対ＨＮＢ−ＧＷ信号送受信部５０１Ａと、ＲＡＮＡＰメッセージ処理部５０２Ａと、ＮＡＳメッセージ処理部５０３Ａと、呼制御部５０４Ａと、局データ格納部５０５Ａと、を有している。
【００８７】
なお、図１４においては、ＲＡＮＡＰメッセージ処理部５０２Ａ、ＮＡＳメッセージ処理部５０３Ａ、呼制御部５０４Ａ、および局データ格納部５０５Ａにより、図１０に示した制御部５２Ａを構成している。また、対ＨＮＢ−ＧＷ信号送受信部５０１Ａは、図１０に示した受信部５１Ａの一例である。
【００８８】
対ＨＮＢ−ＧＷ信号送受信部５０１Ａは、ＨＮＢ−ＧＷ３０との間でＲＡＮＡＰプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
【００８９】
ＲＡＮＡＰメッセージ処理部５０２Ａは、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰメッセージをエンコードする機能、および、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージをデコードする機能を有している。
【００９０】
ＮＡＳメッセージ処理部５０３Ａは、移動局１０との間でＮＡＳプロトコル（ＣＣプロトコル、ＭＭプロトコル）のメッセージの送受信を行うための機能を有している。
【００９１】
呼制御部５０４Ａは、呼処理機能や移動制御機能、さらに、アクセス規制機能を有している。呼制御部５０４Ａは、局データ格納部５０５Ａに格納された局データにアクセスすることができる。局データには、ＣＳＧ毎に、アクセス可能なＩＭＳＩのリストが設定されている。このＩＭＳＩリストを基に、ＳＧＳＮ５０は、ＨＮＢ２０へのアクセス規制を実施する。以上の機能は、ＳＧＳＮ５０に実装される呼処理部が一般に有する機能である。
【００９２】
その他にも、呼制御部５０４Ａは、本実施形態の特徴的な機能として、ＨＮＢ−ＧＷ３０から受信するＲＡＮＡＰプロトコルメッセージにＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合に、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部５０４Ａは、呼解放処理を行うことになる。
【００９３】
以下に、本実施形態の移動通信システムの動作について説明する。
【００９４】
（Ａ）回線交換呼の場合
まず、移動局１０が回線交換の緊急呼として発呼を行った場合の動作例を、図１５のシーケンス図に沿って説明する。
【００９５】
図１５を参照すると、移動局１０は、ステップＳ１０１において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ（図４）をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージ（図２）に設定し、ステップＳ１０２において、そのＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージをＨＮＢ２０に送信する。
【００９６】
ＨＮＢ２０は、無線リソースを確保した後、ステップＳ１０３において、その旨をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＳＥＴＵＰメッセージにて移動局１０に通知する。
【００９７】
移動局１０は、ＲＲＣコネクションを確立した後、ステップＳ１０４において、その旨をＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＳＥＴＵＰ ＣＯＭＰＬＥＴＥメッセージにてＨＮＢ２０に通知する。
【００９８】
続いて、移動局１０は、ステップＳ１０５において、ＭＭプロトコルメッセージであるＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（図１６）のＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（図１７）を“Ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”と設定し、そのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージをＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ（図３）に含める。
【００９９】
さらに、移動局１０は、ステップＳ１０６において、そのＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージのＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ（図４）を“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”と設定し、そのＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ（図３）をＨＮＢ２０に送信する。
【０１００】
ＨＮＢ２０では、ＲＲＣプロトコルメッセージ処理部７０７Ａは、ステップＳ１０２で送信されてきたＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージおよびステップＳ１０６で送信されてきたＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをデコードする。
【０１０１】
また、ＨＮＢ２０では、呼制御部２０５Ａは、移動局１０から、ＲＲＣ：ＲＲＣ ＣＯＮＮＥＣＴＩＯＮ ＲＥＱＵＥＳＴメッセージおよびＲＲＣ：ＩＮＩＴＩＡＬ ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知されたＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値（図４）を保存しておき、ステップＳ１０７において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値を基に、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを決定し、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）に設定する。
【０１０２】
図１８に、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータの決定処理のフローチャートを示す。
【０１０３】
図１８を参照すると、呼制御部２０５Ａは、ステップＳ２０１において、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅ値が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるか判断し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”である場合は、ステップＳ２０２において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”と決定し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”でない場合は、ステップＳ２０３において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”と決定する。
【０１０４】
再度図１５を参照すると、ＨＮＢ２０は、ステップＳ１０８において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを設定したＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）をＨＮＢ−ＧＷ３０に送信する。
【０１０５】
ＨＮＢ−ＧＷ３０では、対ＨＮＢ信号送受信部３０１Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージを受信し、ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージをデコードし、呼制御部３０６Ａは、ステップＳ１０９において、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージに設定されているＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータを基に、アクセス規制（ステップＳ１１０）を実施するかどうかを判断する。
【０１０６】
ＨＮＢ−ＧＷ３０では、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であれば、アクセス規制をしない。この場合、呼制御部３０６Ａは、該当する移動局１０に対してコンテキストＩＤを割り当て、ＨＮＢＡＰメッセージ処理部３０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージをエンコードし、対ＨＮＢ信号送受信部３０１Ａは、ステップＳ１１１において、そのＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージをＨＮＢ２０に送信する。
【０１０７】
ＨＮＢ２０では、呼制御部２０５Ａは、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＡＣＣＥＰＴメッセージの受信後、ステップＳ１１２において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるか判断し、“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であれば、ステップＳ１１３において、本発明によって導入されるＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータ（図１９）を生成する。ＲＡＮＡＰメッセージ処理部２０７Ａは、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータを含むＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージのエンコードを行う。さらに、ＲＡＮＡＰメッセージ処理部２０７Ａは、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにＮＡＳ−ＰＤＵ（Protocol Data Unit）パラメータを設定し、ＮＡＳ−ＰＤＵパラメータには、移動局１０から受信したＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージを設定する。ＲＵＡメッセージ処理部７０３Ａは、そのＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを含むＲＵＡ：ＣＯＮＮＥＣＴメッセージを生成する。すなわち、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージは、ステップＳ１１４において、ＨＮＢ２０からＨＮＢ−ＧＷ３０に対して、ＲＵＡ：ＣＯＮＮＥＣＴメッセージによって転送される。
【０１０８】
ＨＮＢ−ＧＷ３０では、ＲＵＡメッセージ処理部３０２Ａは、ＲＵＡプロトコルのＣＯＮＮＥＣＴメッセージをデコードし、呼制御部３０６Ａは、ＨＮＢ２０で既にエンコードされているＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを取り出し、ＲＡＮＡＰメッセージ処理部３０７Ａは、ステップＳ１１５において、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージを、ＣＮ Ｄｏｍａｉｎ ＩＤ等のルーチング情報を基にＭＳＣ４０に送信する。
【０１０９】
ＭＳＣ４０では、ＲＡＮＡＰメッセージ処理部４０２Ａは、ＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージをデコードし、さらに、ＮＡＳメッセージ処理部４０３Ａは、ＮＡＳ−ＰＤＵに設定されているＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージをデコードする。これらのデコード結果は呼制御部４０４Ａに通知される。呼制御部４０４Ａは、ステップＳ１１６において、本発明で導入されるＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されているかどうかを判断し、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが設定されている場合には、ステップＳ１１７において、ＣＳ（Circuit Switching）サービス向けの不正対策処理を起動する。
【０１１０】
図２０に、ＣＳサービス向けの不正対策処理のフローチャートを示す。
【０１１１】
図２０を参照すると、呼制御部４０４Ａは、ステップＳ３０１において、移動局１０から送信されてきたＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（TS24.008 Ver8.5.0 セクション9.2.9）に設定されているＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（TS24.008 Ver8.5.0 セクション10.5.3.3）が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ Ｅｓｔａｂｌｉｓｈｍｅｎｔ”であるかどうかをチェックする。
【０１１２】
次に、呼制御部４０４Ａは、ステップＳ３０２において、ＭＳＣ４０が送信する発呼信号であるＣＣプロトコルのＳＥＴＵＰ（TS24.008 Ver8.5.0 セクション9.3.23 Setup）メッセージの電話番号（TS24.008 Ver8.5.0 セクション10.5.4.7）が緊急番号であるかどうかをチェックする。具体的には、TS24.008 Ver8.5.0の図10.5.91/3GPP TS 24.008 Called party BCD number information elementにおいて、Number digit 1, Number digit 2, Number digit 3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24.008のセクション10.5.4.7の、Called Party BCD Numberとは、着番号を指し、BCD (BCD、Binary-coded decimal)とは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。
【０１１３】
次に、呼制御部４０４Ａは、ステップＳ３０３において、移動局１０にてＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順（TS24.008 Ver8.5.0 セクション9.3.8）が行われているかどうかをチェックする。例えば、移動局１０から“ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”を開始するためのメッセージを受信すると、インフォメーションエレメント“Ｅｍｅｒｇｅｎｃｙ ｓｅｔｕｐ ｍｅｓｓａｇｅ ｔｙｐｅ”からＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順が行われているかどうかをチェックする。
【０１１４】
ステップＳ３０１〜Ｓ３０３のいずれかのチェックに合致すれば、呼制御部４０４Ａは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部４０４Ａは、ステップＳ３０４において、呼種別が通常呼であると判断し、不正移動局１０−２であるとみなし、呼解放処理を起動する。
【０１１５】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１１６】
（Ｂ）パケット交換呼の場合
次に、移動局１０がパケット交換の緊急呼として発呼を行った場合の動作例を説明する。
【０１１７】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、パケット交換では、ＮＡＳメッセージとして、ＳＭ（Session Management）プロトコルメッセージおよびＧＭＭ（GPRS Mobility Management）プロトコルメッセージが適用される。そのため、ステップＳ１１７で起動する不正対策処理は、ＰＳ（Packet Switching）サービス向けの不正対策処理となる。この処理は、緊急呼の識別方法がＣＳサービスとは異なる。また、パケット交換で音声が使用される場合には、ＶｏＩＰ（Voice over IP）の手法が用いられる。なお、ＧＭＭとは、パケットサービス（PS）での移動制御（Mobility Management）のためのプロトコルである。
【０１１８】
図２１に、ＰＳサービス向けの不正対策処理のフローチャートを示す。
【０１１９】
図２１を参照すると、ＳＧＳＮ５０の呼制御部５０４Ａは、ステップＳ４０１において、移動局１０から送信されてきたＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ（Packet Data Protocol） ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージ（3GPP TS24.008 Ver8.5.0 セクション9.5.1）に設定されているＡＰＮ（Access Point Name）（3GPP TS24.008 9.5.1 10.5.6.1）が緊急呼に特有のものであるかどうかをチェックする。
【０１２０】
次に、呼制御部５０４Ａは、ステップＳ４０２において、移動局１０にて行われているＧＭＭ手順がＥｍｅｒｇｅｎｃｙ Ａｔｔａｃｈ手順（TR23.869 Ver9.0.0）であるかどうかをチェックする。
【０１２１】
次に、呼制御部５０４Ａは、ステップＳ４０３において、ＳＧＳＮ５０にて起動しているＰＤＰ Ｃｏｎｔｅｘｔが緊急呼用のＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。例えば、ＳＧＳＮ５０にて起動しているＰＤＰ ＣｏｎｔｅｘｔがTR23.869 Ver9.0.0のＥｍｅｍｅｒｇｅｎｃｙ ＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。
【０１２２】
ステップＳ４０１〜Ｓ４０３のいずれかのチェックに合致すれば、呼制御部５０４Ａは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部５０４Ａは、ステップＳ５０４において、呼種別が通常呼であると判断し、不正移動局１０−２であるとみなし、呼解放処理を起動する。
【０１２３】
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１２４】
（第３の実施形態）
図２２〜図２４に、本実施形態のＭＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成をそれぞれ示す。
【０１２５】
図２２を参照すると、本実施形態のＭＳＣ４０は、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をＲＡＮＡＰプロトコルメッセージに含める制御部４１Ｂと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部４２Ｂと、を有している。
【０１２６】
また、図２３を参照すると、本実施形態のＳＧＳＮ５０は、移動局１０が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をＲＡＮＡＰプロトコルメッセージに含める制御部５１Ｂと、そのＲＡＮＡＰプロトコルメッセージをＨＮＢ−ＧＷ３０に送信する送信部５２Ｂと、を有している。
【０１２７】
また、図２４を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、ＭＳＣ４０あるいはＳＧＳＮ５０からＲＡＮＡＰプロトコルメッセージを受信する受信部３１Ｂと、そのＲＡＮＡＰプロトコルメッセージに呼種別が緊急呼であることを示す情報が含まれている場合に、呼解放処理を行う制御部３２Ｂと、を有している。
【０１２８】
したがって、本実施形態においては、ＨＮＢ−ＧＷ３０は、移動局１０が実際に発呼した呼種別が緊急呼であることを知ることができる。
【０１２９】
その結果、ＨＮＢ−ＧＷ３０は、移動局１０がＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽っていた場合には、その移動局１０の呼解放処理を実施することができるため、ＨＮＢ２０によるサービスを不正に受けることを防止することができる。
【０１３０】
（第４の実施形態）
図２５〜図２７に、本実施形態のＭＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成をそれぞれ示す。本実施形態は、図２２〜図２４の第３の実施形態のＳＣ４０、ＳＧＳＮ５０、およびＨＮＢ−ＧＷ３０の構成および動作をより具体化した一例である。
【０１３１】
図２５を参照すると、本実施形態のＭＳＣ４０は、対ＨＮＢ−ＧＷ信号送受信部４０１Ｂと、ＲＡＮＡＰメッセージ処理部４０２Ｂと、ＮＡＳメッセージ処理部４０３Ｂと、呼制御部４０４Ｂと、局データ格納部４０５Ｂと、を有している。
【０１３２】
なお、図２５においては、ＲＡＮＡＰメッセージ処理部４０２Ｂ、ＮＡＳメッセージ処理部４０３Ｂ、呼制御部４０４Ｂ、および局データ格納部４０５Ｂにより、図２２に示した制御部４１Ｂを構成している。また、対ＨＮＢ−ＧＷ信号送受信部４０１Ｂは、図２２に示した送信部４２Ｂの一例である。
【０１３３】
対ＨＮＢ−ＧＷ信号送受信部４０１Ｂ、ＲＡＮＡＰメッセージ処理部４０２Ｂ、ＮＡＳメッセージ処理部４０３Ｂ、および局データ格納部４０５Ｂは、それぞれ、図１３に示した対ＨＮＢ−ＧＷ信号送受信部４０１Ａ、ＲＡＮＡＰメッセージ処理部４０２Ａ、ＮＡＳメッセージ処理部４０３Ａ、および局データ格納部４０５Ａと同様の機能を有している。
【０１３４】
呼制御部４０４Ｂは、図１３に示した呼制御部４０４Ａと同様に、ＭＳＣ４０に実装される呼処理部が一般に有する機能を有している。
【０１３５】
その他にも、呼制御部４０４Ｂは、本実施形態の特徴的な機能として、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ Ｔｙｐｅパラメータを設定する機能を有している。
【０１３６】
また、図２６を参照すると、本実施形態のＳＧＳＮ５０は、対ＨＮＢ−ＧＷ信号送受信部５０１Ｂと、ＲＡＮＡＰメッセージ処理部５０２Ｂと、ＮＡＳメッセージ処理部５０３Ｂと、呼制御部５０４Ｂと、局データ格納部５０５Ｂと、を有している。
【０１３７】
なお、図２６においては、ＲＡＮＡＰメッセージ処理部５０２Ｂ、ＮＡＳメッセージ処理部５０３Ｂ、呼制御部５０４Ｂ、および局データ格納部５０５Ｂにより、図２３に示した制御部５１Ｂを構成している。また、対ＨＮＢ−ＧＷ信号送受信部５０１Ｂは、図２３に示した送信部５２Ｂの一例である。
【０１３８】
対ＨＮＢ−ＧＷ信号送受信部５０１Ｂ、ＲＡＮＡＰメッセージ処理部５０２Ｂ、ＮＡＳメッセージ処理部５０３Ｂ、および局データ格納部５０５Ｂは、それぞれ、図１４に示した対ＨＮＢ−ＧＷ信号送受信部５０１Ａ、ＲＡＮＡＰメッセージ処理部５０２Ａ、ＮＡＳメッセージ処理部５０３Ａ、および局データ格納部５０５Ａと同様の機能を有している。
【０１３９】
呼制御部５０４Ｂは、図１４に示した呼制御部５０４Ａと同様に、ＳＧＳＮ５０に実装される呼処理部が一般に有する機能を有している。
【０１４０】
その他にも、呼制御部５０４Ｂは、本実施形態の特徴的な機能として、ＮＡＳメッセージを解析して、移動局１０が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、ＨＮＢ−ＧＷ３０に送信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ Ｔｙｐｅパラメータを設定する機能を有している。
【０１４１】
また、図２７を参照すると、本実施形態のＨＮＢ−ＧＷ３０は、対ＨＮＢ信号送受信部３０１Ｂと、ＲＵＡメッセージ処理部３０２Ｂと、対ＳＧＳＮ信号送受信部３０３Ｂと、対ＭＳＣ信号送受信部３０４Ｂと、ＨＮＢＡＰメッセージ処理部３０５Ｂと、呼制御部３０６Ｂと、ＲＡＮＡＰメッセージ処理部３０７Ｂと、局データ格納部３０８Ｂと、を有している。
【０１４２】
なお、図２７においては、ＲＵＡメッセージ処理部３０２Ｂ、ＨＮＢＡＰメッセージ処理部３０５Ｂ、呼制御部３０６Ｂ、ＲＡＮＡＰメッセージ処理部３０７Ｂ、および局データ格納部３０８Ｂにより、図２４に示した制御部３２Ｂを構成している。また、対ＳＧＳＮ信号送受信部３０３Ｂおよび対ＭＳＣ信号送受信部３０４Ｂは、図２４に示した受信部３１Ｂの一例である。
【０１４３】
対ＨＮＢ信号送受信部３０１Ｂ、ＲＵＡメッセージ処理部３０２Ｂ、対ＳＧＳＮ信号送受信部３０３Ｂ、対ＭＳＣ信号送受信部３０４Ｂ、ＨＮＢＡＰメッセージ処理部３０５Ｂ、ＲＡＮＡＰメッセージ処理部３０７Ｂ、および局データ格納部３０８Ｂは、それぞれ、図１２に示した対ＨＮＢ信号送受信部３０１Ａ、ＲＵＡメッセージ処理部３０２Ａ、対ＳＧＳＮ信号送受信部３０３Ａ、対ＭＳＣ信号送受信部３０４Ａ、ＨＮＢＡＰメッセージ処理部３０５Ａ、ＲＡＮＡＰメッセージ処理部３０７Ａ、および局データ格納部３０８Ａと同様の機能を有している。
【０１４４】
呼制御部３０６Ｂは、図１２に示した呼制御部３０６Ａと同様に、ＨＮＢ−ＧＷ３０に実装される呼処理部が一般に有する機能を有している。
【０１４５】
その他にも、呼制御部３０６Ｂは、本実施形態の特徴的な機能として、ＭＳＣ４０あるいはＳＧＳＮ５０から受信するＲＡＮＡＰプロトコルメッセージのＣａｌｌ ＴｙｐｅパラメータにＮｏｒｍａｌ Ｃａｌｌが設定されている場合に、移動局１０が発呼した呼種別が通常呼であると判断し、このときに移動局１０が緊急呼として発呼を行っていれば、呼解放処理を行う機能を有している。
【０１４６】
なお、本実施形態のＨＮＢ２０の構成は、図９と同様で構わない。ただし、ＨＮＢ２０の呼制御部２０５Ａは、ＨＮＢ２０に実装される呼処理部が一般に有する機能を有していればよい。
【０１４７】
以下に、本実施形態の移動通信システムの動作について説明する。
【０１４８】
（１）動作例１
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＣＯＭＭＯＮ ＩＤメッセージにて通知する例である。
【０１４９】
（１−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＣＯＭＭＯＮ ＩＤメッセージにて通知する場合の動作例を、図２８のシーケンス図に沿って説明する。なお、図２８は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１５０】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、シグナリングコネクションが確立された後に、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１５１】
そのため、図２８を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ５０１において、シグナリングコネクションの確立後、ステップＳ５０２において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。
【０１５２】
図２９に、ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理のフローチャートを示す。
【０１５３】
図２９を参照すると、呼制御部４０４Ｂは、ステップＳ６０１において、移動局１０から送信されてきたＭＭプロトコルのＣＭ ＳＥＲＶＩＣＥ ＲＥＱＵＥＳＴメッセージ（TS24.008 Ver8.5.0 セクション9.2.9）に設定されているＣＭ Ｓｅｒｖｉｃｅ Ｔｙｐｅパラメータ（TS24.008 Ver8.5.0 セクション10.5.3.3）が“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ Ｅｓｔａｂｌｉｓｈｍｅｎｔ”であるかどうかをチェックする。
【０１５４】
次に、呼制御部４０４Ｂは、ステップＳ６０２において、ＭＳＣ４０が送信する発呼信号であるＣＣプロトコルのＳＥＴＵＰ（TS24.008 9.3.23 Ver 8.5.0 セクションSetup）メッセージの電話番号（TS24.008 Ver 8.5.0 セクション10.5.4.7）が緊急番号であるかどうかをチェックする。具体的には、TS24.008 Ver 8.5.0の図10.5.91/3GPP TS 24.008 Called party BCD number information elementにおいて、Number digit 1, Number digit 2, Number digit 3などが電話番号に該当し、この電話番号が緊急番号であるかどうかをチェックする。なお、TS24.008のセクション10.5.4.7の、Called Party BCD Numberとは、着番号を指し、BCDとは、コンピュータにおける数値の表現方式の一つで、十進表現での1桁を、0から9までを表す4桁の二進数で表したものを示す。
【０１５５】
次に、呼制御部４０４Ｂは、ステップＳ６０３において、移動局１０にてＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順（TS24.008 Ver 8.5.0 セクション9.3.8）が行われているかどうかをチェックする。例えば、移動局１０から“ｅｍｅｒｇｅｎｃｙ ｃａｌｌ ｅｓｔａｂｌｉｓｈｍｅｎｔ”を開始するためのメッセージを受信すると、インフォメーションエレメント“Ｅｍｅｒｇｅｎｃｙ ｓｅｔｕｐ ｍｅｓｓａｇｅ ｔｙｐｅ”からＥＭＥＲＧＥＮＣＹ ＳＥＴＵＰ手順が行われているかどうかをチェックする。
【０１５６】
ステップＳ６０１〜Ｓ６０３のいずれかのチェックに合致すれば、呼制御部４０４Ｂは、ステップＳ６０４において、呼種別が緊急呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部４０４Ｂは、ステップＳ６０５において、呼種別が通常呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”に決定する。
【０１５７】
再度図２８を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ５０３において、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージの構成を、図３０に示す。
【０１５８】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ステップＳ５０４において、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ５０５において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１５９】
図３１は、本実施形態のＨＮＢ−ＧＷ３０における処理を、呼種別に応じて決定するためのテーブルを示す図である。
【０１６０】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１６１】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１６２】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＣＯＭＭＯＮ ＩＤメッセージにて通知する場合の動作例を説明する。
【０１６３】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ５０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。
【０１６４】
図３２に、ＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理のフローチャートを示す。
【０１６５】
図３２を参照すると、呼制御部５０４Ｂは、ステップＳ７０１において、移動局１０から送信されてきたＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージ（3GPP TS24.008 Ver8.5.0 セクション9.5.1）に設定されているＡＰＮ（3GPP TS24.008 9.5.1 10.5.6.1）が緊急呼に特有のものであるかどうかをチェックする。
【０１６６】
次に、呼制御部５０４Ｂは、ステップＳ７０２において、移動局１０にて行われているＧＭＭ手順がＥｍｅｒｇｅｎｃｙ Ａｔｔａｃｈ手順（TR23.869 Ver9.0.0）であるかどうかをチェックする。
【０１６７】
次に、呼制御部５０４Ｂは、ステップＳ７０３において、ＳＧＳＮ５０にて起動しているＰＤＰ Ｃｏｎｔｅｘｔが緊急呼用のＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。例えば、ＳＧＳＮ５０にて起動しているＰＤＰ ＣｏｎｔｅｘｔがTR23.869 Ver9.0.0のＥｍｅｍｅｒｇｅｎｃｙ ＰＤＰ Ｃｏｎｔｅｘｔであるかどうかをチェックする。
【０１６８】
ステップＳ７０１〜Ｓ７０３のいずれかのチェックに合致すれば、呼制御部５０４Ｂは、ステップＳ７０４において、呼種別が緊急呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｎｏｒｍａｌ Ｃａｌｌ”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部５０４Ｂは、ステップＳ７０５において、呼種別が通常呼であると判断し、Ｃａｌｌ Ｔｙｐｅパラメータを“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”に決定する。
【０１６９】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージの構成は、図３０に示すように、ＭＳＣ４０の場合と同様である。
【０１７０】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＣＯＭＭＯＮ ＩＤメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１７１】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１７２】
（２）動作例２
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する例である。
【０１７３】
（２−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する場合の動作例を、図３３のシーケンス図に沿って説明する。なお、図３３は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１７４】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、ＣＣプロトコルやＭＭプロトコルのようなＮＡＳメッセージを送信する場合に、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１７５】
そのため、図３３を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ８０１において、ＮＡＳメッセージの送信後、ステップＳ８０２において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図２９に示される通りである。
【０１７６】
ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ８０３において、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成を、図３４に示す。
【０１７７】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ受信時に、ステップＳ８０４において、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ８０５において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１７８】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１７９】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１８０】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージにて通知する場合の動作例を説明する。
【０１８１】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ８０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。このＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図３２に示される通りである。
【０１８２】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージの構成は、図３４に示すように、ＭＳＣ４０の場合と同様である。
【０１８３】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＤＩＲＥＣＴ ＴＲＡＮＳＦＥＲメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１８４】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１８５】
（３）動作例３
本動作例は、ＭＳＣ４０あるいはＳＧＳＮ５０において判別した呼種別の判別結果を、ＲＡＮＡＰ（3GPP TS25.413）のＲＡＢ（Radio Access Bearer） ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する例である。
【０１８６】
（３−Ａ）回線交換呼の場合
まず、ＭＳＣ４０が回線交換呼の呼種別の判別結果をＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する場合の動作例を、図３５のシーケンス図に沿って説明する。なお、図３５は、図１５に示した処理が終了した後の動作を示すものであるが、図１５に示したステップＳ１１２，Ｓ１１３，Ｓ１１６，Ｓ１１７の処理は行われず、また、ステップＳ１１４，Ｓ１１５において送信されるＲＡＮＡＰ：ＩＮＩＴＩＡＬ ＵＥ ＭＥＳＳＡＧＥメッセージにはＥｍｅｒｇｅｎｃｙ Ｃａｕｓｅパラメータが含まれないものとする。
【０１８７】
通常、３ＧＰＰ ＴＳ２５．４１３に記述されるように、コアネットワーク装置は、移動局１０からの呼確立要求を受信して、無線アクセスベアラを確立する場合に、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する。
【０１８８】
そのため、図３５を参照すると、ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ９０１において、移動局１０からの呼確立要求の受信後、ステップＳ９０２において、無線アクセスベアラにためのＱｏＳ（Quality of Service）を決定し、その後、ステップＳ９０３において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図２９に示される通りである。
【０１８９】
ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ９０４において、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成を、図３６に示す。
【０１９０】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、ステップＳ９０５において、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ９０６において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１９１】
例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。
【０１９２】
これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１９３】
（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する場合の動作例を説明する。
【０１９４】
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ８０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。このＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図３２に示される通りである。
【０１９５】
ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成は、図３６に示すように、ＭＳＣ４０の場合と同様である。
【０１９６】
ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。
【０１９７】
図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。
【０１９８】
なお、本発明のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０にて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
【０１９９】
（第５の実施形態）
第２の実施形態では、不正対策処理をＭＳＣ４０あるいはＳＧＳＮ５０にて行っているが、本実施形態では、不正対策処理をＨＮＢ−ＧＷ３０にて行う。
【０２００】
この場合におけるシーケンスを図３７に示す。図３７は、ＨＮＢ−ＧＷが予めＵＥ Ｒｅｇｉｓｔｅｒ手順において、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅ＝Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌを通知されているケースにおいてＨＮＢ−ＧＷがＮＡＳメッセージの中身をチェックして、不正対策処理を起動するケースを示している。これは、図１５において、ＭＳＣが、ＨＮＢ−ＧＷよりＵＥが緊急呼として発呼していたことの通知を受けている場合に、図２０において、ＭＭあるいはＣＣプロトコルのメッセージのチェック処理を実施していたことに相当する。また、同様に、ＳＧＳＮが、ＨＮＢ−ＧＷよりＵＥが緊急呼として発呼していたことを示す場合に、図２１において、ＧＭＭあるいはＳＭプロトコルのメッセージのチェック処理を実施していたことに相当する。なお、ＮＡＳメッセージとは、Ｎｏｎ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍを指し、無線アクセス方式に依存しないプロトコルを指す。
【０２０１】
本実施形態により以下の効果を奏する。
・ＨＮＧ−ＧＷにて、不正対策処理を実施するため、ＭＳＣあるいはＳＧＳＮに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のＭＳＣあるいはＳＧＳＮに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。
・第２の実施形態に比べて、ＲＡＮＡＰプロトコルに新たなパラメータの追加が不要となるため、ＲＡＮＡＰプロトコルのメッセージサイズを削減し、ＨＮＢ−ＧＷとＭＳＣあるいはＳＧＳＮ間のシグナリングの通信量を減少させることができる。
・ＨＮＢ−ＧＷがＮＡＳメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、ＭＳＣあるいはＳＧＳＮより呼の種別の通知を受けなくても、ＨＮＢ−ＧＷが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。
【０２０２】
（第６の実施形態）
第５の実施形態では、端末が緊急呼として発呼している場合に、ＨＮＢ−ＧＷがＮＡＳメッセージをのぞくことにより、不正対策処理を実現しているが、本実施形態では、本不正対策処理をＨＮＢで行う。つまり、図３８に示されるように、ＨＮＢがＮＡＳメッセージをのぞき、不正対策処理を起動する。
【０２０３】
本実施形態により以下の効果を奏する。
・ＨＮＢにて、不正対策処理を実施するため、上位装置が不正対策処理を実行するケースに比べて、より早期に、不正な端末との通信を終了することができる。これによって、ネットワークのリソースの利用性を高めて、ＨＮＢとＨＮＢ−ＧＷ間のシグナリングを減らすことができる。
・ＨＮＢがＮＡＳメッセージをのぞき見ることによって、緊急呼か、あるいは、通常呼かを知ることができるようになるため、ＭＳＣあるいはＳＧＳＮより呼の種別の通知を受けなくても、ＨＮＢが緊急呼手順は通常呼よりも、リソースの割り当てやトラフィックのスケジューリング上、優先度を高くすることが可能となる。
【０２０４】
（第７の実施形態）
第３の実施形態では、ＭＳＣあるいはＳＧＳＮが緊急呼の情報をＨＮＢ−ＧＷに通知し、ＨＮＢ−ＧＷはＵＥが緊急呼としてアクセスしてきたかどうかを確認する。また、第４の実施形態では、ＲＡＮＡＰプロトコルにおいて、Ｃａｌｌ Ｔｙｐｅというパラメータを使用していた。
【０２０５】
本実施形態では、ＲＡＮＡＰの緊急呼を示す情報として、既に、３ＧＰＰ ＴＳ２５．４１３で定義されたＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙと呼ばれるパラメータを使用する（図３９参照）。
【０２０６】
Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙの使用方法については、公知の技術としてよく知られているものであり、本発明の対象外である。例えば、新しいベアラを割り当てるためのリソースが確保できない場合において、他の優先度の低いベアラを解放して、リソースを空けることで、新しいベアラがそのリソースを獲得するというプリエンプションのために使用される。
【０２０７】
ＭＳＣあるいはＳＧＳＮが、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにおいて、本Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを、緊急呼の場合には、以下のように設定する。
【０２０８】
Priority Level = 1
Pre-emption Capability = "may trigger pre-emption"
Pre-emption Vulnerability = not pre-emptable
このように設定することで、緊急呼として確立することを通知することができる。さらに、ＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ以外のほかのメッセージでもよい。この場合に、ＭＳＣあるいはＳＧＳＮでのＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを緊急呼設定する場合の設定論理は、図２９および図３２と同様であり、図４０および図４１のようになる。
【０２０９】
図４０および図４１においては、本Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータが通常呼を示しているが、ＵＥ Ｒｅｇｉｓｔｒａｔｉｏｎ手順におけるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅ値が緊急呼を示す場合には、ＨＮＢ−ＧＷは、ＵＥがＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを偽ってアクセスしてきたと判断し、呼解放を実施する。この場合の動作シーケンスを図４２に示す。
【０２１０】
本実施形態により以下の効果を奏する。
・既存のＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙを用いて緊急呼かどうかを通知するため、ＭＳＣあるいはＳＧＳＮに対する変更を伴わなくてもよい。これにより、フェムトを導入するにあたって、既に運用中のＭＳＣあるいは、ＳＧＳＮに対して変更を加えないため、容易にフェムトシステムを導入することが可能となる。
・第４の実施形態に比べて、ＲＡＮＡＰプロトコルに新たなパラメータの追加が不要となるため、ＲＡＮＡＰプロトコルのメッセージサイズを削減し、ＨＮＢ−ＧＷとＭＳＣあるいはＳＧＳＮ間のシグナリングの通信量を減少させることができる。
【０２１１】
（第８の実施形態）
第７の実施形態では、ＨＮＢ−ＧＷがＡｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙパラメータを判断し、不正対策処理を実現しているが、本実施形態では、本不正対策処理をＨＮＢで行う。つまり、図４３に示されるように、ＨＮＢがＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージを受信時に、Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙを判断し、それが通常呼であった場合に、ＵＥ Ｒｅｇｉｓｔｒａｔｉｏｎ手順におけるＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅが緊急呼であった場合には、ＨＮＢ−ＧＷは、ＵＥがＥｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを偽ってアクセスしてきたと判断し、呼解放を実施する。
【０２１２】
なお、第３の実施形態および第４の実施形態では、ＨＮＢ−ＧＷがＭＳＣあるいはＳＧＳＮより通知される呼種別とＵＥがアクセスしてきた際のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅの比較処理を実施しているが、本比較処理はＨＮＢで実施してもよい。
【０２１３】
本実施形態により以下の効果を奏する。
・ＨＮＢ−ＧＷでは、ＲＡＮＡＰプロトコルメッセージを終端し、Ａｌｌｏｃａｔｉｏｎ／Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙによって呼種別を判断する必要がなくなるため、ＨＮＢ−ＧＷの処理を簡単にすることが可能となる。
【０２１４】
以上、本発明を、好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【０２１５】
例えば、第２の実施形態では、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅ値のＲＡＮＡＰプロトコルメッセージへの設定をＨＮＢ２０にて行っているが、ＨＮＢ−ＧＷ３０にて行うこととしてもよい。
【０２１６】
また、第１〜第４の実施形態によれば、ＲＡＮＡＰプロトコルメッセージを用いて、移動局１０が緊急呼として発呼を行ったことを示す情報または移動局１０が発呼した実際の呼種別が緊急呼であることを示す情報を、ＨＮＢ２０、ＨＮＢ−ＧＷ３０およびコアネットワーク装置（ＭＳＣ４０またはＳＧＳＮ５０）間で通信した。しかし、ＲＡＮＡＰプロトコルメッセージに限らず、ＨＮＢ２０、ＨＮＢ−ＧＷ３０またはコアネットワーク装置間で通信可能なメッセージであれば他のメッセージであってもよい。
【０２１７】
本出願は、２００９年１０月０１日に出願された日本出願特願２００９−２２９３９１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【特許請求の範囲】
【請求項１】
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、
前記基地局は、
前記移動局とのＲＲＣコネクションを確立する手段と、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、
前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、
前記ゲートウェイ装置は、
前記基地局から、前記登録メッセージを受信する第１の受信手段と、
前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行するチェック手段と、を有し、
前記チェック手段によるチェックに基づいて、前記緊急呼の処理を行う、
移動通信システム。
【請求項２】
前記チェック手段によるチェックは、
前記登録メッセージに含まれるＲｅｇｉｓｔｒａｔｉｏｎ ＣａｕｓｅがＥｍｅｒｇｅｎｃｙ Ｃａｌｌであることを示す場合に実行される、請求項１に記載の移動通信システム。
【請求項３】
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、
前記基地局と前記移動局とのＲＲＣコネクションを確立し、
前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、
前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、
前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、
前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、
前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行し、
前記一貫性のチェックに基づいて、前記緊急呼の処理を行う、
通信方法。
【請求項４】
前記チェックは、
前記登録メッセージに含まれるＲｅｇｉｓｔｒａｔｉｏｎ ＣａｕｓｅがＥｍｅｒｇｅｎｃｙ Ｃａｌｌであることを示す場合に実行される、請求項３に記載の通信方法。
【請求項５】
ゲートウェイ装置と、前記ゲートウェイ装置に接続する基地局と、を有する無線通信システムの移動局であって、
前記基地局とのＲＲＣコネクションを確立する手段と、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージ及び前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記通信コネクションを介して前記基地局に送信する手段と、を有し、
前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックが、前記登録メッセージと前記確立メッセージとを受信する前記ゲートウェイ装置によって実行され、前記チェックに基づいて前記緊急呼の処理が行われる、
移動局。
【請求項１】
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムであって、
前記基地局は、
前記移動局とのＲＲＣコネクションを確立する手段と、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信する第１の送信手段と、
前記移動局が発呼する緊急呼の確立に関するメッセージを送信する第２の送信手段と、を有し、
前記ゲートウェイ装置は、
前記基地局から、前記登録メッセージを受信する第１の受信手段と、
前記基地局から、前記緊急呼の確立に関する確立メッセージを受信する第２の受信手段と、
前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行するチェック手段と、を有し、
前記チェック手段によるチェックに基づいて、前記緊急呼の処理を行う、
移動通信システム。
【請求項２】
前記チェック手段によるチェックは、
前記登録メッセージに含まれるＲｅｇｉｓｔｒａｔｉｏｎ ＣａｕｓｅがＥｍｅｒｇｅｎｃｙ Ｃａｌｌであることを示す場合に実行される、請求項１に記載の移動通信システム。
【請求項３】
移動局と、
前記移動局と無線通信を行う基地局と、
前記基地局とコアネットワークとに接続されるゲートウェイ装置と、を有する移動通信システムによる通信方法であって、
前記基地局と前記移動局とのＲＲＣコネクションを確立し、
前記基地局が、前記移動局を前記ゲートウェイ装置に登録するための登録メッセージを送信し、
前記基地局が、前記移動局が発呼する緊急呼の確立に関するメッセージを送信し、
前記ゲートウェイ装置が、前記基地局から、前記登録メッセージを受信し、
前記ゲートウェイ装置が、前記基地局から、前記緊急呼の確立に関する確立メッセージを受信し、
前記ゲートウェイ装置が、前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックを実行し、
前記一貫性のチェックに基づいて、前記緊急呼の処理を行う、
通信方法。
【請求項４】
前記チェックは、
前記登録メッセージに含まれるＲｅｇｉｓｔｒａｔｉｏｎ ＣａｕｓｅがＥｍｅｒｇｅｎｃｙ Ｃａｌｌであることを示す場合に実行される、請求項３に記載の通信方法。
【請求項５】
ゲートウェイ装置と、前記ゲートウェイ装置に接続する基地局と、を有する無線通信システムの移動局であって、
前記基地局とのＲＲＣコネクションを確立する手段と、
前記移動局を前記ゲートウェイ装置に登録するための登録メッセージ及び前記移動局が発呼する緊急呼の確立に関する確立メッセージを、前記通信コネクションを介して前記基地局に送信する手段と、を有し、
前記登録メッセージと前記確立メッセージとの緊急呼に関する情報の一貫性のチェックが、前記登録メッセージと前記確立メッセージとを受信する前記ゲートウェイ装置によって実行され、前記チェックに基づいて前記緊急呼の処理が行われる、
移動局。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【公開番号】特開２０１２−９５３０２（Ｐ２０１２−９５３０２Ａ）
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願番号】特願２０１１−２３８９９１（Ｐ２０１１−２３８９９１）
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【分割の表示】特願２０１１−５０４２６８（Ｐ２０１１−５０４２６８）の分割
【原出願日】平成２２年１０月１日（２０１０．１０．１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年５月１７日（２０１２．５．１７）
【国際特許分類】
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【分割の表示】特願２０１１−５０４２６８（Ｐ２０１１−５０４２６８）の分割
【原出願日】平成２２年１０月１日（２０１０．１０．１）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]