JP2014209782A - 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法 - Google Patents

Abstract

【課題】移動局が緊急呼として発呼を行ったことを知ることができる移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法を提供する。【解決手段】移動局１０と、移動局１０と無線通信を行う基地局２０と、基地局２０をコアネットワークに接続するゲートウェイ装置３０と、コアネットワークに配置されたコアネットワーク装置４０と、を有する。基地局２０は、移動局１０が緊急呼として発呼を行ったことを示す情報をメッセージに含めＳ１１３、メッセージをゲートウェイ装置３０に送信しＳ１１４、ゲートウェイ装置３０はメッセージをコアネットワーク装置４０に送信するＳ１１５。コアネットワーク装置４０は、受信したメッセージから発呼が緊急呼として行われたことを認識するＳ１１６。【選択図】図１５

Description

本発明は、移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法に関する。

フェムト基地局（Ｈｏｍｅ ＮｏｄｅＢ、以下、ＨＮＢと略す）の産業上の利用形態としては、例えば、家庭用の小型無線基地局として利用する形態や、企業内における小型無線基地局として利用する形態が考えられている。

ＨＮＢによりサービスを提供する場合には、例えば、以下のような利点がある。

（１）マクロ基地局の電波が届かない不感地帯での通話サービスを提供することができる
（２）マクロ基地局が提供する通常の課金サービスよりも安い課金サービスを提供することができる
（３）基地局と移動局との距離が近く、移動局が高い無線品質（Ｅｃ／Ｉｏ）を得ることができるため、６４ＱＡＭ（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）を決定し、その後、ステップＳ９０３において、Ｃａｌｌ Ｔｙｐｅパラメータの決定処理を起動する。ＭＳＣ４０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図２９に示される通りである。

ＭＳＣ４０では、呼制御部４０４Ｂは、ステップＳ９０４において、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成を、図３６に示す。

ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、ステップＳ９０５において、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、ステップＳ９０６において、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。

例えば、図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＭＳＣ４０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う。

これによって、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。

（１−Ｂ）パケット交換呼の場合
次に、ＳＧＳＮ５０がパケット交換呼の呼種別の判別結果をＲＡＮＡＰのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージにて通知する場合の動作例を説明する。

パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にＭＳＣ４０で行っていた処理を、ＳＧＳＮ５０で行う点以外は同様である。ただし、ステップＳ８０２で起動するＣａｌｌ Ｔｙｐｅパラメータの決定処理は異なっている。このＳＧＳＮ５０におけるＣａｌｌ Ｔｙｐｅパラメータの決定処理は、動作例１と同様であり、図３２に示される通りである。

ＳＧＳＮ５０では、呼制御部５０４Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージをＨＮＢ−ＧＷ３０に送信する際に、Ｃａｌｌ Ｔｙｐｅパラメータが決定されていれば、本Ｃａｌｌ Ｔｙｐｅパラメータを設定する。本発明による、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージの構成は、図３６に示すように、ＭＳＣ４０の場合と同様である。

ＨＮＢ−ＧＷ３０では、呼制御部３０６Ｂは、ＲＡＮＡＰ：ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージ受信時に、Ｃａｌｌ Ｔｙｐｅパラメータが含まれていた場合、移動局１０がＨＮＢ−ＧＷ３０にアクセスした際の、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージ（図５）のＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータ（図６）と比較する。

図３１に示すケース２では、ＨＮＢＡＰ：ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージのＲｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅパラメータが“Ｅｍｅｒｇｅｎｃｙ Ｃａｌｌ”であるに関わらず、ＳＧＳＮ５０から通知されたＣａｌｌ Ｔｙｐｅパラメータは、“Ｎｏｒｍａｌ Ｃａｌｌ”である。このことからＨＮＢ−ＧＷ３０は、移動局１０が緊急呼と偽って、不正にＨＮＢ２０にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のＶｏＩＰのケースにおいても、本来、ＨＮＢ２０にアクセスできない不正移動局１０−２が、Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅを改ざんして緊急呼と偽り、ＨＮＢ２０によるサービスを受けることを防止することができる。

なお、本発明のＨＮＢ２０、ＨＮＢ−ＧＷ３０、ＭＳＣ４０、およびＳＧＳＮ５０にて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。

以上、本発明を、好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

例えば、第２の実施形態では、Ｅｍｅｒｇｅｎｃｙ Ｃａｕｓｅ値のＲＡＮＡＰプロトコルメッセージへの設定をＨＮＢ２０にて行っているが、ＨＮＢ−ＧＷ３０にて行うこととしてもよい。

また、第２の実施形態では、不正対策処理をＭＳＣ４０あるいはＳＧＳＮ５０にて行っているが、ＨＮＢ−ＧＷ３０にて行うこととしてもよい。この場合、第４の実施形態と同様に、ＨＮＢ−ＧＷ３０は、ＭＳＣ４０あるいはＳＧＳＮ５０から、移動局１０が発呼した実際の呼種別が緊急呼であることを示す情報を受信し、図３１のテーブルを用いて不正対策処理を実施することになる。

また、第１〜第４の実施形態によれば、ＲＡＮＡＰプロトコルメッセージを用いて、移動局１０が緊急呼として発呼を行ったことを示す情報または移動局１０が発呼した実際の呼種別が緊急呼であることを示す情報を、ＨＮＢ２０、ＨＮＢ−ＧＷ３０およびコアネットワーク装置（ＭＳＣ４０またはＳＧＳＮ５０）間で通信した。しかし、ＲＡＮＡＰプロトコルメッセージに限らず、ＨＮＢ２０、ＨＮＢ−ＧＷ３０またはコアネットワーク装置間で通信可能なメッセージであれば他のメッセージであってもよい。

本出願は、２００９年４月１７日に出願された日本出願特願２００９−１０１１３０を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (14)

1. 基地局とコアネットワーク装置とに接続するゲートウェイ装置であって、
   前記基地局と通信する第一の信号送受信部と、
   前記コアネットワーク装置と通信する第二の信号送受信部と、を有し、
   緊急呼に関する第一のメッセージと、緊急呼に関する第二のメッセージと、の一貫性をチェックするゲートウェイ装置。
2. 前記第一のメッセージは、ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージである、請求項１に記載のゲートウェイ装置。
3. 前記第二のメッセージは、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージである、請求項１または２に記載のゲートウェイ装置。
4. 前記第一のメッセージは、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅを含む、請求項１乃至３のいずれか１つに記載のゲートウェイ装置。
5. 前記第一のメッセージは、登録に関するメッセージであり、
   前記第二のメッセージは、確立に関するメッセージである、請求項１乃至４のいずれか１つに記載のゲートウェイ装置。
6. 前記登録に関するメッセージは、移動局を前記ゲートウェイ装置に登録するために前記基地局が前記ゲートウェイ装置に送信するメッセージである、請求項５に記載のゲートウェイ装置。
7. 前記確立に関するメッセージは、前記コアネットワーク装置が前記ゲートウェイ装置に送信するメッセージである、請求項５または６に記載のゲートウェイ装置。
8. 基地局とコアネットワーク装置とに接続するゲートウェイ装置による通信方法であって、
   前記基地局と通信するステップと、
   前記コアネットワーク装置と通信するステップと、
   緊急呼に関する第一のメッセージと、緊急呼に関する第二のメッセージと、の一貫性をチェックするステップと、を有する通信方法。
9. 前記第一のメッセージは、ＵＥ ＲＥＧＩＳＴＥＲ ＲＥＱＵＥＳＴメッセージである、請求項８に記載の通信方法。
10. 前記第二のメッセージは、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴメッセージである、請求項８または９に記載の通信方法。
11. 前記第一のメッセージは、Ｒｅｇｉｓｔｒａｔｉｏｎ Ｃａｕｓｅを含む、請求項８乃至１０のいずれか１つに記載の通信方法。
12. 前記第一のメッセージは、登録に関するメッセージであり、
    前記第二のメッセージは、確立に関するメッセージである、請求項８乃至１１のいずれか１つに記載の通信方法。
13. 前記登録に関するメッセージは、移動局を前記ゲートウェイ装置に登録するために前記基地局が前記ゲートウェイ装置に送信するメッセージである、請求項１２に記載の通信方法。
14. 前記確立に関するメッセージは、前記コアネットワーク装置が前記ゲートウェイ装置に送信するメッセージである、請求項１２または１３に記載の通信方法。