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

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

Info

Publication number
JP5648762B2
JP5648762B2 JP2014137453A JP2014137453A JP5648762B2 JP 5648762 B2 JP5648762 B2 JP 5648762B2 JP 2014137453 A JP2014137453 A JP 2014137453A JP 2014137453 A JP2014137453 A JP 2014137453A JP 5648762 B2 JP5648762 B2 JP 5648762B2
Authority
JP
Japan
Prior art keywords
message
call
hnb
mobile station
core network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014137453A
Other languages
English (en)
Other versions
JP2014209782A (ja
Inventor
佳央 植田
佳央 植田
林 貞福
貞福 林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2014137453A priority Critical patent/JP5648762B2/ja
Publication of JP2014209782A publication Critical patent/JP2014209782A/ja
Application granted granted Critical
Publication of JP5648762B2 publication Critical patent/JP5648762B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/02Access restriction performed under specific conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2242/00Special services or facilities
    • H04M2242/04Special services or facilities for emergency applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • H04W84/042Public Land Mobile systems, e.g. cellular systems
    • H04W84/045Public Land Mobile systems, e.g. cellular systems using private Base Stations, e.g. femto Base Stations, home Node B

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法に関する。
フェムト基地局(Home NodeB、以下、HNBと略す)の産業上の利用形態としては、例えば、家庭用の小型無線基地局として利用する形態や、企業内における小型無線基地局として利用する形態が考えられている。
HNBによりサービスを提供する場合には、例えば、以下のような利点がある。
(1)マクロ基地局の電波が届かない不感地帯での通話サービスを提供することができる
(2)マクロ基地局が提供する通常の課金サービスよりも安い課金サービスを提供することができる
(3)基地局と移動局との距離が近く、移動局が高い無線品質(Ec/Io)を得ることができるため、64QAM(64 Quadrature Amplitude Modulation)やMIMO(Multiple Input Multiple Output)の高速化技術を活かすことができ、HNB配下において高速パケットサービスを提供することができる
(4)HNBの局所性を活かした特有のコンテンツサービスを提供することができる
このように、HNBによるサービスは、多くの利点を有するため、通信事業者と契約を結んだ加入者や、そのHNBの所持者が許容した加入者のみに提供されるべきである。
そこで、3GPP(3rd Generation Partnership Project)では、許容されたグループの移動局のみがHNBにアクセスし、サービスを受けられるようにするために、リリース8において、CSG(Closed Subscriber Group)を導入している。
ここで、CSGについて、図1を参照して詳細に説明する。
図1に示す第3世代の移動通信システムは、HNB20と、フェムト基地局ゲートウェイ(Home NodeB GW、以下、HNB−GWと略す)30と、回線交換局(Mobile Switching Center、以下、MSCと略す)40と、パケット交換局(Serving GPRS Support Node、以下、SGSNと略す)50と、第3世代対応の移動局10−1,10−2と、を有している。
なお、図1において、HNB20の配下に在圏する移動局10−1,10−2のうち、移動局10−1は、正当な移動局である。これに対し、移動局10−2は、HNB20によるサービスを不正に受けようとする移動局であり、以下、不正移動局10−2と称す。また、以下、どちらの移動局かを特定しない場合は、移動局10と称す。
HNB20は、HNB−GW30を介してオペレータのコアネットワークに接続されている。
コアネットワークは、コアネットワーク装置として、回線交換を制御するMSC40と、パケット交換を制御するSGSN50と、を含んでいる。
HNB20は、CSG機能をサポートしている場合には、自身のCSGセル(CSG Cell)のCSG識別子(CSG identity)を、自身の配下に在圏する移動局10に報知する。
移動局10−1は、HNB20から報知されたCSG識別子をデコードし、自身の持っているCSGリストにそのCSG識別子が含まれているかどうかを判断する。
CSGリストにCSG識別子が含まれていれば、移動局10−1は、自身が在圏するCSGセルにキャンプオンし、発信、着信といった様々なサービスを受けることができる。
一方、CSGリストにCSG識別子が含まれていなければ、移動局10−1は、自身が在圏するCSGセルにはキャンプオンせずに、そのCSGセルとは別の適切なCSGセルを選択する動作を行う。
このようなメカニズムによって、HNB20には、そのHNB20のCSGセルのCSG識別子を持つ限られた移動局10−1のみがアクセス可能になる。
ただし、図1に示した不正移動局10−2のように、CSG機能をサポートしているにも関わらず、本来、アクセスできないHNB20のCSGセルにて、不正にサービスを受けようとするケースが考えられる。
このようなケースにおいては、MSC40あるいはSGSN50が、移動局10のIMSI(International Mobile Subscriber Identity)とその移動局10が在圏しているCSGセルのCSG識別子とをチェックすることによって、その移動局10によるHNB20へのアクセスを規制するアクセス規制を行う(3GPP TS25.467 Ver8.0.0 5.1.3節)。
一方、CSG機能は、3GPPのリリース8より導入されている機能であるため、リリース8以前の移動局10−1がCSG機能をサポートしていないケースがある。また、HNB20がCSG機能をサポートしていないケースもある。
このようなケースにおいては、HNB20は、移動局10−1のIMSIを問い合わせるために、移動局10−1に対してIdentification手順(3GPP TS24.008 Ver8.4.0)を実施し、また、移動局10−1をHNB−GW30に登録するために、HNB−GW30に対してHNBAP(HNB Application Part):UE REGISTER REQUEST手順(3GPP TS25.469 Ver8.0.0)を実施する。この際に、HNB−GW30は、移動局10−1のIMSIがHNB20にアクセスできるものかどうかをチェックすることによって、アクセス規制を行う。
HNB−GW30は、移動局10−1がHNB20にアクセスできると判断した場合には、アクセスが許可されることを、HNBAP:UE REGISTER ACCEPTメッセージによってHNB20に通知する。これにより、HNB20によるサービスが移動局10−1に対して提供される。
一方、移動局10が図1に示した不正移動局10−2である場合には、不正移動局10−2のIMSIはCSGにアクセスできるように登録されていない。そのため、HNB−GW30は、不正移動局10−2がHNB20にアクセスできないと判断し、アクセスが許可されないことを、HNBAP:UE REGISTER REJECTメッセージによってHNB20に通知する。これにより、不正移動局10−2とHNB20との間のRRC(Radio Resource Control)コネクションは切断される(3GPP TS25.467 Ver8.0.0 5.1.2節)。
上記により、HNB20によるサービスを提供するに際しては、MSC40、SGSN50、あるいはHNB−GW30が、移動局10のIMSIを基に、アクセス規制を行っているため、HNB20へのアクセスが許容されていない不正移動局10−2が仮に発信を行ったとしても、信号確立手順中に移動通信ネットワーク側によりHNB20へのアクセスが拒絶されることとなる。
一方、3GPPの標準化においては、本来、HNB20へのアクセスが許容されていない移動局10であっても、呼種別が緊急呼である場合は発呼を可能とすることが定められている(3GPP TS22.011 Ver 8.6.0 8.5.1節)。
呼種別が緊急呼である場合、移動局10−1は、RRCコネクション確立要求時あるいはシグナリングコネクション確立要求時にHNB20に送信するRRC:RRC CONNECTION REQUESTメッセージあるいはRRC:INITIAL DIRECT TRANSFERにおいて、確立要求の要因を示すEstablishment Causeパラメータに“Emergency call”と設定する(3GPP TS25.331 Ver8.5.0 10.3.3.11節、特許文献1)。
そして、HNB20は、HNB−GW30に送信するHNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータを“Emergency call”値に設定する。
Registration Causeパラメータが“Emergency call”である場合には、HNB−GW30は、IMSIに基づくアクセス規制を実施しない(3GPP TS25.467 Ver8.0.0 5.1.2節)。
この手法によって、本来、HNB20にアクセスしてはならない移動局10であっても、呼種別が緊急呼である場合には、HNB−GW30のアクセス規制をスキップし、HNB20へのアクセスが可能となる。
ここで、図2に、RRC:RRC CONNECTION REQUESTメッセージの構成を示し、また、図3に、RRC:INITIAL DIRECT TRANSFERメッセージの構成を示し、また、図4に、RRCプロトコルにおける、Establishment Causeパラメータの構成を示し、また、図5に、HNBAP:UE REGISTER REQUESTメッセージの構成を示し、また、図6に、HBNAPプロトコルにおける、Regsitration Causeパラメータの構成を示す。
特開2003−244284号公報
ところで、上述した技術は、移動局10が緊急呼として発呼を行った場合には、HNB−GW30のアクセス規制をスキップし、移動局10によるHNB20へのアクセスを許可するものである。
そのため、不正移動局10−2のように、本来はHNB20へアクセスできない移動局10であっても、RRCプロトコルにおける、Establishment Causeパラメータを“Emergency call”と偽り、HNB−GW30のアクセス規制の対象外となることによって、HNB20へのアクセスが可能となってしまう。
このような不正移動局10−2は、Establishment Causeパラメータのみを改ざんするようにソフトウェアを改造することによって、容易に作ることができると考えられる。
あるいは、正当な移動局10−1から共通チャネル(RACH:Random Access Channel)上に送信される、秘匿も改ざん対策もされていないRRC:RRC CONNECTION REQUESTメッセージをデコードし、Establishment Causeパラメータを“Emergency call”に置き換えて、RRC:RRC CONNECTION REQUESTメッセージをエンコードしてHNB20に送信する装置が介在する場合もある。この場合、正当な移動局10−1であっても、上述のような不正移動局10−2と同視されることになる。
このような不正移動局10−2により、以下のような問題が生じる。
(1)家庭用あるいは企業に設置されたHNB20が、不正移動局10−2により不正に使用されてしまう
(2)不正移動局10−2は、HNB20を介した発信を行うことによって、通常の課金サービスよりも安い課金サービスを不正に受けることができてしまう
(3)特定のユーザ向けへのコンテンツサービスを不正移動局10−2が不正に受けてしまう
このような問題を解決する方法としては、移動局10が緊急呼として発呼を行った場合に、コアネットワーク装置側で、その移動局10の呼解放処理を行うことが考えられる。そのためには、コアネットワーク装置は、移動局10が緊急呼として発呼を行ったことを知る必要がある。
しかし、現状の構成では、コアネットワーク装置は、移動局10が緊急呼として発呼を行ったことを知ることができない。
あるいは、HNB−GW30側で、緊急呼と偽って発呼を行った移動局10の呼解放処理を行うことも考えられる。そのためには、HNB−GW30は、移動局10が実際に発呼した呼種別が緊急呼であるかを知る必要がある。
しかし、現状の構成では、HNB−GW30は、移動局10が実際に発呼した呼種別を知ることができない。
本発明の目的は、コアネットワーク装置が、移動局が緊急呼として発呼を行ったことを知ることができる移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法を提供することにある。
本発明の他の目的は、ゲートウェイ装置が、移動局が実際に発呼した呼種別を知ることができる移動通信システム、ゲートウェイ装置、コアネットワーク装置、通信方法を提供することにある。
本発明の第1の移動通信システムは、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムであって、
前記基地局は、
前記移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含める制御部と、
前記メッセージを前記コアネットワーク装置に送信する送信部と、を有し、
前記コアネットワーク装置は、
前記基地局から送信されてきた前記メッセージを受信する受信部を有する。
本発明の第2の移動通信システムは、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムであって、
前記ゲートウェイ装置は、
前記移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含める制御部と、
前記メッセージを前記コアネットワーク装置に送信する送信部と、を有し、
前記コアネットワーク装置は、
前記ゲートウェイ装置から送信されてきた前記メッセージを受信する受信部を有する。
本発明の第3の移動通信システムは、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムであって、
前記コアネットワーク装置は、
前記移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含める制御部と、
前記メッセージを前記ゲートウェイ装置に送信する送信部と、
前記ゲートウェイ装置は、
前記コアネットワーク装置から送信されてきた前記メッセージを受信する受信部を有する。
本発明の基地局は、
ゲートウェイ装置を介して、コアネットワークに配置されたコアネットワーク装置に接続される基地局であって、
移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含める制御部と、
前記メッセージを前記コアネットワーク装置に送信する送信部と、を有する。
本発明の第1のゲートウェイ装置は、
基地局を、コアネットワークに配置されたコアネットワーク装置に接続するゲートウェイ装置であって、
移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含める制御部と、
前記メッセージを前記コアネットワーク装置に送信する送信部と、を有する。
本発明の第2のゲートウェイ装置は、
基地局を、コアネットワークに配置されたコアネットワーク装置に接続するゲートウェイ装置であって、
前記コアネットワーク装置から送信されてきた、移動局が発呼した呼種別が緊急呼であることを示す情報を含むメッセージを受信する受信部を有する。
本発明の第1のコアネットワーク装置は、
コアネットワークに配置されたコアネットワーク装置であって、
基地局から送信されてきた、移動局が緊急呼として発呼を行ったことを示す情報を含むメッセージを受信する受信部を有する。
本発明の第2のコアネットワーク装置は、
コアネットワークに配置されたコアネットワーク装置であって、
ゲートウェイ装置から送信されてきた、移動局が緊急呼として発呼を行ったことを示す情報を含むメッセージを受信する受信部を有する。
本発明の第3のコアネットワーク装置は、
コアネットワークに配置されたコアネットワーク装置であって、
前記移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含める制御部と、
前記メッセージをゲートウェイ装置に送信する送信部と、を有する。
本発明の第1の通信方法は、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムによる通信方法であって、
前記基地局が、前記移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めるステップと、
前記基地局が、前記メッセージを前記コアネットワーク装置に送信するステップと、
前記コアネットワーク装置が、前記基地局から送信されてきた前記メッセージを受信するステップと、を有する。
本発明の第2の通信方法は、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムによる通信方法であって、
前記ゲートウェイ装置が、前記移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めるステップと、
前記ゲートウェイ装置が、前記メッセージを前記コアネットワーク装置に送信するステップと、
前記コアネットワーク装置が、前記ゲートウェイ装置から送信されてきた前記メッセージを受信するステップと、を有する。
本発明の第3の通信方法は、
移動局と、前記移動局と無線通信を行う基地局と、前記基地局をコアネットワークに接続するゲートウェイ装置と、前記コアネットワークに配置されたコアネットワーク装置と、を有してなる移動通信システムによる通信方法であって、
前記コアネットワーク装置が、前記移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めるステップと、
前記コアネットワーク装置が、前記メッセージを前記ゲートウェイ装置に送信するステップと、
前記ゲートウェイ装置が、前記コアネットワーク装置から送信されてきた前記メッセージを受信するステップと、を有する。
本発明の第4の通信方法は、
ゲートウェイ装置を介して、コアネットワークに配置されたコアネットワーク装置に接続される基地局による通信方法であって、
移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めるステップと、
前記メッセージを前記コアネットワーク装置に送信するステップと、を有する。
本発明の第5の通信方法は、
基地局を、コアネットワークに配置されたコアネットワーク装置に接続するゲートウェイ装置による通信方法であって、
移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めるステップと、
前記メッセージを前記コアネットワーク装置に送信するステップと、を有する。
本発明の第6の通信方法は、
基地局を、コアネットワークに配置されたコアネットワーク装置に接続するゲートウェイ装置による通信方法であって、
前記コアネットワーク装置から送信されてきた、移動局が発呼した呼種別が緊急呼であることを示す情報を含むメッセージを受信するステップを有する。
本発明の第7の通信方法は、
コアネットワークに配置されたコアネットワーク装置による通信方法であって、
基地局から送信されてきた、移動局が緊急呼として発呼を行ったことを示す情報を含むメッセージを受信するステップを有する。
本発明の第8の通信方法は、
コアネットワークに配置されたコアネットワーク装置による通信方法であって、
ゲートウェイ装置から送信されてきた、移動局が緊急呼として発呼を行ったことを示す情報を含むメッセージを受信するステップを有する。
本発明の第9の通信方法は、
コアネットワークに配置されたコアネットワーク装置による通信方法であって、
移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めるステップと、
前記メッセージをゲートウェイ装置に送信するステップと、を有する。
本発明の第1あるいは第2の移動通信システムによれば、基地局あるいはゲートウェイ装置は、移動局が緊急呼として発呼を行ったことを示す情報をメッセージに含めて、コアネットワーク装置に送信する。
したがって、コアネットワーク装置は、移動局が緊急呼として発呼を行ったことを知ることができるという効果が得られる。
本発明の第3の移動通信システムによれば、コアネットワーク装置は、移動局が発呼した呼種別が緊急呼であることを示す情報をメッセージに含めて、ゲートウェイ装置に送信する。
したがって、ゲートウェイ装置は、移動局が実際に発呼した呼種別が緊急呼であることを知ることができるという効果が得られる。
第3世代の移動通信システムの構成を示す図である。 RRC CONNECTION REQUESTメッセージの構成を示す図である。 INITIAL DIRECT TRANSFERメッセージの構成を示す図である。 Establishment Causeパラメータの構成を示す図である。 UE REGISTER REQUESTメッセージの構成を示す図である。 Registration Causeパラメータの構成を示す図である。 本発明の第1の実施形態のHNBの構成を示すブロック図である。 本発明の第1の実施形態のHNB−GWの構成を示すブロック図である。 本発明の第1の実施形態のMSCの構成を示すブロック図である。 本発明の第1の実施形態のSGSNの構成を示すブロック図である。 本発明の第2の実施形態のHNBの構成を示すブロック図である。 本発明の第2の実施形態のHNB−GWの構成を示すブロック図である。 本発明の第2の実施形態のMSCの構成を示すブロック図である。 本発明の第2の実施形態のSGSNの構成を示すブロック図である。 本発明の第2の実施形態の移動通信システムの動作を説明するシーケンス図である。 CM SERVICE REQUESTメッセージの構成を示す図である。 CM Service Typeパラメータの構成を示す図である。 HNBよるRegistration Causeパラメータの決定処理を示すフローチャートである。 本発明に係るEmergency Causeパラメータが追加されたINITIAL UE MESSAGEメッセージの構成を示す図である。 本発明の第2の実施形態のMSCによる不正対策処理を示すフローチャートである。 本発明の第2の実施形態のSGSNによる不正対策処理を示すフローチャートである。 本発明の第3の実施形態のMSCの構成を示すブロック図である。 本発明の第3の実施形態のSGSNの構成を示すブロック図である。 本発明の第3の実施形態のHNB−GWの構成を示すブロック図である。 本発明の第4の実施形態のMSCの構成を示すブロック図である。 本発明の第4の実施形態のSGSNの構成を示すブロック図である。 本発明の第4の実施形態のHNB−GWの構成を示すブロック図である。 本発明の第4の実施形態の移動通信システムの動作例1を説明するシーケンス図である。 本発明の第4の実施形態のMSCによるCall Typeパラメータの決定処理を示すフローチャートである。 本発明に係るCOMMON IDメッセージの構成を示す図である。 本発明の第4の実施形態のHNB−GWにおける処理を、呼種別に応じて決定するためのテーブルを示す図である。 本発明の第4の実施形態のSGSNによるCall Typeパラメータの決定処理を示すフローチャートである。 本発明の第4の実施形態の移動通信システムの動作例2を説明するシーケンス図である。 本発明に係るDIRECT TRANSFERメッセージの構成を示す図である。 本発明の第4の実施形態の移動通信システムの動作例3を説明するシーケンス図である。 本発明に係るRAB ASSIGNMENT REQUESTメッセージの構成を示す図である。
以下に、本発明を実施するための最良の形態について図面を参照して説明する。
なお、以下で説明する実施形態において、移動通信システムの全体構成自体は、図1の移動通信システムと同様であるとする。
(第1の実施形態)
図7〜図10に、本実施形態のHNB20、HNB−GW30、MSC40、およびSGSN50の構成をそれぞれ示す。
図7を参照すると、本実施形態のHNB20は、移動局10が緊急呼として発呼を行ったことを示す情報をRANAP(Radio Access Network Application Part)プロトコルメッセージに含める制御部21Aと、そのRANAPプロトコルメッセージをHNB−GW30に送信する送信部22Aと、を有している。なお、RANAPプロトコルメッセージとは、無線アクセスネットワークのアプリケーション層のメッセージであり、例えば、UEとコアネットワーク装置間で送受信されるCC/MM信号をRAN内で透過的に転送する昨日を有するものである。
また、図8を参照すると、本実施形態のHNB−GW30は、HNB20からRANAPプロトコルメッセージを受信する受信部31Aと、そのRANAPプロトコルメッセージを取り出す制御部32Aと、そのRANAPプロトコルメッセージをMSC40あるいはSGSN50に送信する送信部33Aと、を有している。
また、図9を参照すると、本実施形態のMSC40は、HNB−GW30からRANAPプロトコルメッセージを受信する受信部41Aと、そのRANAPプロトコルメッセージに移動局10が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を行う制御部42Aと、を有している。
また、図10を参照すると、本実施形態のSGSN50は、HNB−GW30からRANAPプロトコルメッセージを受信する受信部51Aと、そのRANAPプロトコルメッセージに移動局10が緊急呼として発呼を行ったことを示す情報が含まれている場合に、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、緊急呼でなければ呼解放処理を実施する制御部52Aと、を有している。
したがって、本実施形態においては、MSC40あるいはSGSN50が、移動局10が緊急呼として発呼を行ったことを知ることができる。
その結果、MSC40あるいはSGSN50は、移動局10がEstablishment Causeを改ざんして緊急呼と偽っていた場合には、その移動局10の呼解放処理を実施することができるため、HNB20によるサービスを不正に受けることを防止することができる。
(第2の実施形態)
図11〜図14に、本実施形態のHNB20、HNB−GW30、MSC40、およびSGSN50の構成をそれぞれ示す。本実施形態は、図7〜図10の第1の実施形態のHNB20、HNB−GW30、MSC40、およびSGSN50の構成および動作をより具体化した例である。
図11を参照すると、本実施形態のHNB20は、対移動局信号送受信部201Aと、RUA(RANAP User Adaption)メッセージ処理部202Aと、対HNB−GW信号送受信部203Aと、HNBAPメッセージ処理部204Aと、呼制御部205Aと、RRCメッセージ処理部206Aと、RANAPメッセージ処理部207Aと、を有している。
なお、図11においては、RUAメッセージ処理部202A、HNBAPメッセージ処理部204A、呼制御部205A、RRCメッセージ処理部206A、およびRANAPメッセージ処理部207Aにより、図7に示した制御部21Aを構成している。また、対HNB−GW信号送受信部203Aは、図7に示した送信部22Aの一例である。
対移動局信号送受信部201Aは、移動局10との間でRRCプロトコルメッセージを送受信するための機能として、メッセージを秘匿(暗号化、復号化)する秘匿機能、メッセージの送達を確認する信号送達確認機能、メッセージを分配する信号分配機能等を有している。
対HNB−GW信号送受信部203Aは、HNB−GW30との間でHNBAPプロトコルメッセージやRUAプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能、信号分配機能等を有している。
RRCメッセージ処理部206Aは、移動局10へ送信するRRCプロトコルメッセージをエンコードする機能、および、移動局10から受信するRRCプロトコルメッセージをデコードする機能を有している。
HNBAPメッセージ処理部204Aは、HNB−GW30へ送信するHNBAPプロトコルメッセージをエンコードする機能、および、HNB−GW30から受信するHNBAPプロトコルメッセージをデコードする機能を有している。
RANAPメッセージ処理部207Aは、HNB−GW30へ送信するRANAPメッセージをエンコードする機能、および、HNB−GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。
RUAプロトコルは、RANAPプロトコルメッセージを転送する働きをするプロトコルであり、RUAメッセージ処理部202Aは、HNB−GW30に送信するRUAプロトコルメッセージをエンコードする機能、および、HNB−GW30から受信するRUAプロトコルメッセージをデコードする機能を有している。
呼制御部205Aは、RRCプロトコルメッセージやRANAPプロトコルメッセージを基に、RRCコネクションの確立、ベアラの確立、移動制御などの様々な呼処理を起動する。さらに、呼制御部205Aは、HNBAPプロトコルを起動して、HNB−GW30への移動局10の登録処理を実施する。以上の機能は、HNB20に実装される呼処理部が一般に有する機能である。
その他にも、呼制御部205Aは、本実施形態の特徴的な機能として、HNB−GW30から受信したHNBAPプロトコルメッセージのRegistration Causeパラメータを基に、HNB−GW30に送信するRANAPプロトコルメッセージのEmergency Cause値を設定する機能を有している。
また、図12を参照すると、本実施形態のHNB−GW30は、対HNB信号送受信部301Aと、RUAメッセージ処理部302Aと、対SGSN信号送受信部303Aと、対MSC信号送受信部304Aと、HNBAPメッセージ処理部305Aと、呼制御部306Aと、RANAPメッセージ処理部307Aと、局データ格納部308Aと、を有している。
なお、図12においては、RUAメッセージ処理部302A、HNBAPメッセージ処理部305A、呼制御部306A、RANAPメッセージ処理部307A、および局データ格納部308Aにより、図8に示した制御部32Aを構成している。また、対HNB信号送受信部301Aは、図8に示した受信部31Aの一例であり、また、対SGSN信号送受信部303Aおよび対MSC信号送受信部304Aは、図8に示した送信部33Aの一例である。
対HNB信号送受信部301Aは、HNB20との間でRUAプロトコルメッセージやHNBAPプロトコルメッセージの送受信を行うための機能として、秘匿機能、信号送達確認機能等を有している。
対MSC信号送受信部304Aは、MSC40との間でRANAPプロトコルメッセージの送受信を行うための機能として、メッセージの順序を制御する順序制御機能、送達確認機能等を有している。
対SGSN信号送受信部303Aは、SGSN50との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
HNBAPメッセージ処理部305Aは、HNB20へ送信するHNBAPプロトコルメッセージをエンコードする機能、および、HNBから受信するHNBAPプロトコルメッセージをデコードする機能を有している。
RUAメッセージ処理部302Aは、HNB20へ送信するRUAプロトコルメッセージをエンコードする機能、および、HNB20から受信するRUAプロトコルメッセージをデコードする機能を有している。
RANAPメッセージ処理部307Aは、MSC40に送信するRANAPプロトコルメッセージをエンコードする機能、および、MSC40から受信するRANAPプロトコルメッセージをデコードする機能を有している。
呼制御部306Aは、HNB103の登録処理や、移動局10の登録処理を行う。また、呼制御部306Aは、局データ格納部308Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、HNB−GW30は、HNB20へのアクセス規制を実施する。以上の機能は、HNB−GW30に実装される呼処理部が一般に有する機能である。
また、図13を参照すると、本実施形態のMSC40は、対HNB−GW信号送受信部401Aと、RANAPメッセージ処理部402Aと、NAS(Non Access Stratum)メッセージ処理部403Aと、呼制御部404Aと、局データ格納部405Aと、を有している。
なお、図13においては、RANAPメッセージ処理部402A、NASメッセージ処理部403A、呼制御部404A、および局データ格納部405Aにより、図9に示した制御部42Aを構成している。また、対HNB−GW信号送受信部401Aは、図9に示した受信部41Aの一例である。
対HNB−GW信号送受信部401Aは、HNB−GW30との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
RANAPメッセージ処理部402Aは、HNB−GW30に送信するRANAPメッセージをエンコードする機能、および、HNB−GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。
NASメッセージ処理部403Aは、移動局10との間でNASプロトコル(CC(Call Control)プロトコル、MM(Mobility Management)プロトコル)のメッセージの送受信を行うための機能を有している。
呼制御部404Aは、呼確立、呼解放などの呼処理を行う呼処理機能や、位置登録やハンドオーバなどの移動制御を行う移動制御機能、さらに、HNB20へのアクセスを規制するアクセス規制機能を有している。呼制御部404Aは、局データ格納部405Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、MSC40は、HNB20へのアクセス規制を実施する。以上の機能は、MSC40に実装される呼処理部が一般に有する機能である。
その他にも、呼制御部404Aは、本実施形態の特徴的な機能として、HNB−GW30から受信するRANAPプロトコルメッセージにEmergency Causeパラメータが設定されている場合に、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部404Aは、呼解放処理を行うことになる。
また、図14を参照すると、本実施形態のSGSN50は、対HNB−GW信号送受信部501Aと、RANAPメッセージ処理部502Aと、NASメッセージ処理部503Aと、呼制御部504Aと、局データ格納部505Aと、を有している。
なお、図14においては、RANAPメッセージ処理部502A、NASメッセージ処理部503A、呼制御部504A、および局データ格納部505Aにより、図10に示した制御部52Aを構成している。また、対HNB−GW信号送受信部501Aは、図10に示した受信部51Aの一例である。
対HNB−GW信号送受信部501Aは、HNB−GW30との間でRANAPプロトコルメッセージの送受信を行うための機能として、送達確認機能や順序制御機能等を有している。
RANAPメッセージ処理部502Aは、HNB−GW30に送信するRANAPメッセージをエンコードする機能、および、HNB−GW30から受信するRANAPプロトコルメッセージをデコードする機能を有している。
NASメッセージ処理部503Aは、移動局10との間でNASプロトコル(CCプロトコル、MMプロトコル)のメッセージの送受信を行うための機能を有している。
呼制御部504Aは、呼処理機能や移動制御機能、さらに、アクセス規制機能を有している。呼制御部504Aは、局データ格納部505Aに格納された局データにアクセスすることができる。局データには、CSG毎に、アクセス可能なIMSIのリストが設定されている。このIMSIリストを基に、SGSN50は、HNB20へのアクセス規制を実施する。以上の機能は、SGSN50に実装される呼処理部が一般に有する機能である。
その他にも、呼制御部504Aは、本実施形態の特徴的な機能として、HNB−GW30から受信するRANAPプロトコルメッセージにEmergency Causeパラメータが設定されている場合に、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別する機能を有している。もし、緊急呼でなければ、呼制御部504Aは、呼解放処理を行うことになる。
以下に、本実施形態の移動通信システムの動作について説明する。
(A)回線交換呼の場合
まず、移動局10が回線交換の緊急呼として発呼を行った場合の動作例を、図15のシーケンス図に沿って説明する。
図15を参照すると、移動局10は、ステップS101において、Establishment Cause(図4)をRRC:RRC CONNECTION REQUESTメッセージ(図2)に設定し、ステップS102において、そのRRC:RRC CONNECTION REQUESTメッセージをHNB20に送信する。
HNB20は、無線リソースを確保した後、ステップS103において、その旨をRRC:RRC CONNECTION SETUPメッセージにて移動局10に通知する。
移動局10は、RRCコネクションを確立した後、ステップS104において、その旨をRRC:RRC CONNECTION SETUP COMPLETEメッセージにてHNB20に通知する。
続いて、移動局10は、ステップS105において、MMプロトコルメッセージであるCM SERVICE REQUESTメッセージ(図16)のCM Service Typeパラメータ(図17)を“Emergency call establishment”と設定し、そのCM SERVICE REQUESTメッセージをRRC:INITIAL DIRECT TRANSFERメッセージ(図3)に含める。
さらに、移動局10は、ステップS106において、そのRRC:INITIAL DIRECT TRANSFERメッセージのEstablishment Cause(図4)を“Emergency Call”と設定し、そのRRC:INITIAL DIRECT TRANSFERメッセージ(図3)をHNB20に送信する。
HNB20では、RRCプロトコルメッセージ処理部707Aは、ステップS102で送信されてきたRRC:RRC CONNECTION REQUESTメッセージおよびステップS106で送信されてきたRRC:INITIAL DIRECT TRANSFERメッセージをデコードする。
また、HNB20では、呼制御部205Aは、移動局10から、RRC:RRC CONNECTION REQUESTメッセージおよびRRC:INITIAL DIRECT TRANSFERメッセージにて通知されたEstablishment Cause値(図4)を保存しておき、ステップS107において、Establishment Cause値を基に、Registration Causeパラメータを決定し、HNBAP:UE REGISTER REQUESTメッセージ(図5)に設定する。
図18に、Registration Causeパラメータの決定処理のフローチャートを示す。
図18を参照すると、呼制御部205Aは、ステップS201において、Establishment Cause値が“Emergency Call”であるか判断し、“Emergency Call”である場合は、ステップS202において、Registration Causeパラメータを“Emergency Call”と決定し、“Emergency Call”でない場合は、ステップS203において、Registration Causeパラメータを“Normal Call”と決定する。
再度図15を参照すると、HNB20は、ステップS108において、Registration Causeパラメータを設定したHNBAP:UE REGISTER REQUESTメッセージ(図5)をHNB−GW30に送信する。
HNB−GW30では、対HNB信号送受信部301Aは、HNBAP:UE REGISTER REQUESTメッセージを受信し、HNBAPメッセージ処理部305Aは、HNBAP:UE REGISTER REQUESTメッセージをデコードし、呼制御部306Aは、ステップS109において、HNBAP:UE REGISTER REQUESTメッセージに設定されているRegistration Causeパラメータを基に、アクセス規制(ステップS110)を実施するかどうかを判断する。
HNB−GW30では、Registration Causeパラメータが“Emergency Call”であれば、アクセス規制をしない。この場合、呼制御部306Aは、該当する移動局10に対してコンテキストIDを割り当て、HNBAPメッセージ処理部305Aは、HNBAP:UE REGISTER ACCEPTメッセージをエンコードし、対HNB信号送受信部301Aは、ステップS111において、そのHNBAP:UE REGISTER ACCEPTメッセージをHNB20に送信する。
HNB20では、呼制御部205Aは、HNBAP:UE REGISTER ACCEPTメッセージの受信後、ステップS112において、Registration Causeパラメータが“Emergency Call”であるか判断し、“Emergency Call”であれば、ステップS113において、本発明によって導入されるEmergency Causeパラメータ(図19)を生成する。RANAPメッセージ処理部207Aは、Emergency Causeパラメータを含むRANAP:INITIAL UE MESSAGEメッセージのエンコードを行う。さらに、RANAPメッセージ処理部207Aは、RANAP:INITIAL UE MESSAGEメッセージにNAS−PDU(Protocol Data Unit)パラメータを設定し、NAS−PDUパラメータには、移動局10から受信したMMプロトコルのCM SERVICE REQUESTメッセージを設定する。RUAメッセージ処理部703Aは、そのRANAP:INITIAL UE MESSAGEメッセージを含むRUA:CONNECTメッセージを生成する。すなわち、RANAP:INITIAL UE MESSAGEメッセージは、ステップS114において、HNB20からHNB−GW30に対して、RUA:CONNECTメッセージによって転送される。
HNB−GW30では、RUAメッセージ処理部302Aは、RUAプロトコルのCONNECTメッセージをデコードし、呼制御部306Aは、HNB20で既にエンコードされているRANAP:INITIAL UE MESSAGEメッセージを取り出し、RANAPメッセージ処理部307Aは、ステップS115において、RANAP:INITIAL UE MESSAGEメッセージを、CN Domain ID等のルーチング情報を基にMSC40に送信する。
MSC40では、RANAPメッセージ処理部402Aは、RANAP:INITIAL UE MESSAGEメッセージをデコードし、さらに、NASメッセージ処理部403Aは、NAS−PDUに設定されているCM SERVICE REQUESTメッセージをデコードする。これらのデコード結果は呼制御部404Aに通知される。呼制御部404Aは、ステップS116において、本発明で導入されるEmergency Causeパラメータが設定されているかどうかを判断し、Emergency Causeパラメータが設定されている場合には、ステップS117において、CS(Circuit Switching)サービス向けの不正対策処理を起動する。
図20に、CSサービス向けの不正対策処理のフローチャートを示す。
図20を参照すると、呼制御部404Aは、ステップS301において、移動局10から送信されてきたMMプロトコルのCM SERVICE REQUESTメッセージ(TS24.008 Ver8.5.0 セクション9.2.9)に設定されているCM Service Typeパラメータ(TS24.008 Ver8.5.0 セクション10.5.3.3)が“Emergency Call Establishment”であるかどうかをチェックする。
次に、呼制御部404Aは、ステップS302において、MSC40が送信する発呼信号であるCCプロトコルのSETUP(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桁の二進数で表したものを示す。
次に、呼制御部404Aは、ステップS303において、移動局10にてEMERGENCY SETUP手順(TS24.008 Ver8.5.0 セクション9.3.8)が行われているかどうかをチェックする。例えば、移動局10から“emergency call establishment”を開始するためのメッセージを受信すると、インフォメーションエレメント“Emergency setup message type”からEMERGENCY SETUP手順が行われているかどうかをチェックする。
ステップS301〜S303のいずれかのチェックに合致すれば、呼制御部404Aは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部404Aは、ステップS304において、呼種別が通常呼であると判断し、不正移動局10−2であるとみなし、呼解放処理を起動する。
これによって、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(B)パケット交換呼の場合
次に、移動局10がパケット交換の緊急呼として発呼を行った場合の動作例を説明する。
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、パケット交換では、NASメッセージとして、SM(Session Management)プロトコルメッセージおよびGMM(GPRS Mobility Management)プロトコルメッセージが適用される。そのため、ステップS117で起動する不正対策処理は、PS(Packet Switching)サービス向けの不正対策処理となる。この処理は、緊急呼の識別方法がCSサービスとは異なる。また、パケット交換で音声が使用される場合には、VoIP(Voice over IP)の手法が用いられる。なお、GMMとは、パケットサービス(PS)での移動制御(Mobility Management)のためのプロトコルである。
図21に、PSサービス向けの不正対策処理のフローチャートを示す。
図21を参照すると、SGSN50の呼制御部504Aは、ステップS401において、移動局10から送信されてきたSMプロトコルのActivate PDP(Packet Data Protocol) context requestメッセージ(3GPP TS24.008 Ver8.5.0 セクション9.5.1)に設定されているAPN(Access Point Name)(3GPP TS24.008 9.5.1 10.5.6.1)が緊急呼に特有のものであるかどうかをチェックする。
次に、呼制御部504Aは、ステップS402において、移動局10にて行われているGMM手順がEmergency Attach手順(TR23.869 Ver9.0.0)であるかどうかをチェックする。
次に、呼制御部504Aは、ステップS403において、SGSN50にて起動しているPDP Contextが緊急呼用のPDP Contextであるかどうかをチェックする。例えば、SGSN50にて起動しているPDP ContextがTR23.869 Ver9.0.0のEmemergency PDP Contextであるかどうかをチェックする。
ステップS401〜S403のいずれかのチェックに合致すれば、呼制御部504Aは、呼種別が緊急呼であると判断し、緊急呼のための呼処理を継続する。一方、いずれのチェックにも合致しなければ、呼制御部504Aは、ステップS504において、呼種別が通常呼であると判断し、不正移動局10−2であるとみなし、呼解放処理を起動する。
これによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(第3の実施形態)
図22〜図24に、本実施形態のMSC40、SGSN50、およびHNB−GW30の構成をそれぞれ示す。
図22を参照すると、本実施形態のMSC40は、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をRANAPプロトコルメッセージに含める制御部41Bと、そのRANAPプロトコルメッセージをHNB−GW30に送信する送信部42Bと、を有している。
また、図23を参照すると、本実施形態のSGSN50は、移動局10が実際に発呼した呼種別が緊急呼であるか判別し、呼種別が緊急呼であることを示す情報をRANAPプロトコルメッセージに含める制御部51Bと、そのRANAPプロトコルメッセージをHNB−GW30に送信する送信部52Bと、を有している。
また、図24を参照すると、本実施形態のHNB−GW30は、MSC40あるいはSGSN50からRANAPプロトコルメッセージを受信する受信部31Bと、そのRANAPプロトコルメッセージに呼種別が緊急呼であることを示す情報が含まれている場合に、呼解放処理を行う制御部32Bと、を有している。
したがって、本実施形態においては、HNB−GW30は、移動局10が実際に発呼した呼種別が緊急呼であることを知ることができる。
その結果、HNB−GW30は、移動局10がEstablishment Causeを改ざんして緊急呼と偽っていた場合には、その移動局10の呼解放処理を実施することができるため、HNB20によるサービスを不正に受けることを防止することができる。
(第4の実施形態)
図25〜図27に、本実施形態のMSC40、SGSN50、およびHNB−GW30の構成をそれぞれ示す。本実施形態は、図22〜図24の第3の実施形態のSC40、SGSN50、およびHNB−GW30の構成および動作をより具体化した一例である。
図25を参照すると、本実施形態のMSC40は、対HNB−GW信号送受信部401Bと、RANAPメッセージ処理部402Bと、NASメッセージ処理部403Bと、呼制御部404Bと、局データ格納部405Bと、を有している。
なお、図25においては、RANAPメッセージ処理部402B、NASメッセージ処理部403B、呼制御部404B、および局データ格納部405Bにより、図22に示した制御部41Bを構成している。また、対HNB−GW信号送受信部401Bは、図22に示した送信部42Bの一例である。
対HNB−GW信号送受信部401B、RANAPメッセージ処理部402B、NASメッセージ処理部403B、および局データ格納部405Bは、それぞれ、図13に示した対HNB−GW信号送受信部401A、RANAPメッセージ処理部402A、NASメッセージ処理部403A、および局データ格納部405Aと同様の機能を有している。
呼制御部404Bは、図13に示した呼制御部404Aと同様に、MSC40に実装される呼処理部が一般に有する機能を有している。
その他にも、呼制御部404Bは、本実施形態の特徴的な機能として、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、HNB−GW30に送信するRANAPプロトコルメッセージのCall Typeパラメータを設定する機能を有している。
また、図26を参照すると、本実施形態のSGSN50は、対HNB−GW信号送受信部501Bと、RANAPメッセージ処理部502Bと、NASメッセージ処理部503Bと、呼制御部504Bと、局データ格納部505Bと、を有している。
なお、図26においては、RANAPメッセージ処理部502B、NASメッセージ処理部503B、呼制御部504B、および局データ格納部505Bにより、図23に示した制御部51Bを構成している。また、対HNB−GW信号送受信部501Bは、図23に示した送信部52Bの一例である。
対HNB−GW信号送受信部501B、RANAPメッセージ処理部502B、NASメッセージ処理部503B、および局データ格納部505Bは、それぞれ、図14に示した対HNB−GW信号送受信部501A、RANAPメッセージ処理部502A、NASメッセージ処理部503A、および局データ格納部505Aと同様の機能を有している。
呼制御部504Bは、図14に示した呼制御部504Aと同様に、SGSN50に実装される呼処理部が一般に有する機能を有している。
その他にも、呼制御部504Bは、本実施形態の特徴的な機能として、NASメッセージを解析して、移動局10が発呼した呼種別が緊急呼であるか判別し、その判別結果を基に、HNB−GW30に送信するRANAPプロトコルメッセージのCall Typeパラメータを設定する機能を有している。
また、図27を参照すると、本実施形態のHNB−GW30は、対HNB信号送受信部301Bと、RUAメッセージ処理部302Bと、対SGSN信号送受信部303Bと、対MSC信号送受信部304Bと、HNBAPメッセージ処理部305Bと、呼制御部306Bと、RANAPメッセージ処理部307Bと、局データ格納部308Bと、を有している。
なお、図27においては、RUAメッセージ処理部302B、HNBAPメッセージ処理部305B、呼制御部306B、RANAPメッセージ処理部307B、および局データ格納部308Bにより、図24に示した制御部32Bを構成している。また、対SGSN信号送受信部303Bおよび対MSC信号送受信部304Bは、図24に示した受信部31Bの一例である。
対HNB信号送受信部301B、RUAメッセージ処理部302B、対SGSN信号送受信部303B、対MSC信号送受信部304B、HNBAPメッセージ処理部305B、RANAPメッセージ処理部307B、および局データ格納部308Bは、それぞれ、図12に示した対HNB信号送受信部301A、RUAメッセージ処理部302A、対SGSN信号送受信部303A、対MSC信号送受信部304A、HNBAPメッセージ処理部305A、RANAPメッセージ処理部307A、および局データ格納部308Aと同様の機能を有している。
呼制御部306Bは、図12に示した呼制御部306Aと同様に、HNB−GW30に実装される呼処理部が一般に有する機能を有している。
その他にも、呼制御部306Bは、本実施形態の特徴的な機能として、MSC40あるいはSGSN50から受信するRANAPプロトコルメッセージのCall TypeパラメータにNormal Callが設定されている場合に、移動局10が発呼した呼種別が通常呼であると判断し、このときに移動局10が緊急呼として発呼を行っていれば、呼解放処理を行う機能を有している。
なお、本実施形態のHNB20の構成は、図9と同様で構わない。ただし、HNB20の呼制御部205Aは、HNB20に実装される呼処理部が一般に有する機能を有していればよい。
以下に、本実施形態の移動通信システムの動作について説明する。
(1)動作例1
本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP(3GPP TS25.413)のCOMMON IDメッセージにて通知する例である。
(1−A)回線交換呼の場合
まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのCOMMON IDメッセージにて通知する場合の動作例を、図28のシーケンス図に沿って説明する。なお、図28は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIAL UE MESSAGEメッセージにはEmergency Causeパラメータが含まれないものとする。
通常、3GPP TS25.413に記述されるように、コアネットワーク装置は、シグナリングコネクションが確立された後に、RANAP:COMMON IDメッセージをHNB−GW30に送信する。
そのため、図28を参照すると、MSC40では、呼制御部404Bは、ステップS501において、シグナリングコネクションの確立後、ステップS502において、Call Typeパラメータの決定処理を起動する。
図29に、MSC40におけるCall Typeパラメータの決定処理のフローチャートを示す。
図29を参照すると、呼制御部404Bは、ステップS601において、移動局10から送信されてきたMMプロトコルのCM SERVICE REQUESTメッセージ(TS24.008 Ver8.5.0 セクション9.2.9)に設定されているCM Service Typeパラメータ(TS24.008 Ver8.5.0 セクション10.5.3.3)が“Emergency Call Establishment”であるかどうかをチェックする。
次に、呼制御部404Bは、ステップS602において、MSC40が送信する発呼信号であるCCプロトコルのSETUP(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桁の二進数で表したものを示す。
次に、呼制御部404Bは、ステップS603において、移動局10にてEMERGENCY SETUP手順(TS24.008 Ver 8.5.0 セクション9.3.8)が行われているかどうかをチェックする。例えば、移動局10から“emergency call establishment”を開始するためのメッセージを受信すると、インフォメーションエレメント“Emergency setup message type”からEMERGENCY SETUP手順が行われているかどうかをチェックする。
ステップS601〜S603のいずれかのチェックに合致すれば、呼制御部404Bは、ステップS604において、呼種別が緊急呼であると判断し、Call Typeパラメータを“Normal Call”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部404Bは、ステップS605において、呼種別が通常呼であると判断し、Call Typeパラメータを“Emergency Call”に決定する。
再度図28を参照すると、MSC40では、呼制御部404Bは、ステップS503において、RANAP:COMMON IDメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:COMMON IDメッセージの構成を、図30に示す。
HNB−GW30では、呼制御部306Bは、ステップS504において、RANAP:COMMON IDメッセージ受信時に、Call Typeパラメータが含まれていた場合、ステップS505において、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
図31は、本実施形態のHNB−GW30における処理を、呼種別に応じて決定するためのテーブルを示す図である。
例えば、図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、MSC40から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。
これによって、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(1−B)パケット交換呼の場合
次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのCOMMON IDメッセージにて通知する場合の動作例を説明する。
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS502で起動するCall Typeパラメータの決定処理は異なっている。
図32に、SGSN50におけるCall Typeパラメータの決定処理のフローチャートを示す。
図32を参照すると、呼制御部504Bは、ステップS701において、移動局10から送信されてきたSMプロトコルのActivate PDP context requestメッセージ(3GPP TS24.008 Ver8.5.0 セクション9.5.1)に設定されているAPN(3GPP TS24.008 9.5.1 10.5.6.1)が緊急呼に特有のものであるかどうかをチェックする。
次に、呼制御部504Bは、ステップS702において、移動局10にて行われているGMM手順がEmergency Attach手順(TR23.869 Ver9.0.0)であるかどうかをチェックする。
次に、呼制御部504Bは、ステップS703において、SGSN50にて起動しているPDP Contextが緊急呼用のPDP Contextであるかどうかをチェックする。例えば、SGSN50にて起動しているPDP ContextがTR23.869 Ver9.0.0のEmemergency PDP Contextであるかどうかをチェックする。
ステップS701〜S703のいずれかのチェックに合致すれば、呼制御部504Bは、ステップS704において、呼種別が緊急呼であると判断し、Call Typeパラメータを“Normal Call”に決定する。一方、いずれのチェックにも合致しなければ、呼制御部504Bは、ステップS705において、呼種別が通常呼であると判断し、Call Typeパラメータを“Emergency Call”に決定する。
SGSN50では、呼制御部504Bは、RANAP:COMMON IDメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:COMMON IDメッセージの構成は、図30に示すように、MSC40の場合と同様である。
HNB−GW30では、呼制御部306Bは、RANAP:COMMON IDメッセージ受信時に、Call Typeパラメータが含まれていた場合、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
例えば、図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、SGSN50から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。
これによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(2)動作例2
本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP(3GPP TS25.413)のDIRECT TRANSFERメッセージにて通知する例である。
(2−A)回線交換呼の場合
まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのDIRECT TRANSFERメッセージにて通知する場合の動作例を、図33のシーケンス図に沿って説明する。なお、図33は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIAL UE MESSAGEメッセージにはEmergency Causeパラメータが含まれないものとする。
通常、3GPP TS25.413に記述されるように、コアネットワーク装置は、CCプロトコルやMMプロトコルのようなNASメッセージを送信する場合に、RANAP:DIRECT TRANSFERメッセージをHNB−GW30に送信する。
そのため、図33を参照すると、MSC40では、呼制御部404Bは、ステップS801において、NASメッセージの送信後、ステップS802において、Call Typeパラメータの決定処理を起動する。MSC40におけるCall Typeパラメータの決定処理は、動作例1と同様であり、図29に示される通りである。
MSC40では、呼制御部404Bは、ステップS803において、RANAP:DIRECT TRANSFERメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:DIRECT TRANSFERメッセージの構成を、図34に示す。
HNB−GW30では、呼制御部306Bは、RANAP:DIRECT TRANSFERメッセージ受信時に、ステップS804において、Call Typeパラメータが含まれていた場合、ステップS805において、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
例えば、図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、MSC40から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。
これによって、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(1−B)パケット交換呼の場合
次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのDIRECT TRANSFERメッセージにて通知する場合の動作例を説明する。
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS802で起動するCall Typeパラメータの決定処理は異なっている。このSGSN50におけるCall Typeパラメータの決定処理は、動作例1と同様であり、図32に示される通りである。
SGSN50では、呼制御部504Bは、RANAP:DIRECT TRANSFERメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:DIRECT TRANSFERメッセージの構成は、図34に示すように、MSC40の場合と同様である。
HNB−GW30では、呼制御部306Bは、RANAP:DIRECT TRANSFERメッセージ受信時に、Call Typeパラメータが含まれていた場合、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
例えば、図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、SGSN50から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(3)動作例3
本動作例は、MSC40あるいはSGSN50において判別した呼種別の判別結果を、RANAP(3GPP TS25.413)のRAB(Radio Access Bearer) ASSIGNMENT REQUESTメッセージにて通知する例である。
(3−A)回線交換呼の場合
まず、MSC40が回線交換呼の呼種別の判別結果をRANAPのRAB ASSIGNMENT REQUESTメッセージにて通知する場合の動作例を、図35のシーケンス図に沿って説明する。なお、図35は、図15に示した処理が終了した後の動作を示すものであるが、図15に示したステップS112,S113,S116,S117の処理は行われず、また、ステップS114,S115において送信されるRANAP:INITIAL UE MESSAGEメッセージにはEmergency Causeパラメータが含まれないものとする。
通常、3GPP TS25.413に記述されるように、コアネットワーク装置は、移動局10からの呼確立要求を受信して、無線アクセスベアラを確立する場合に、RANAP:RAB ASSIGNMENT REQUESTメッセージをHNB−GW30に送信する。
そのため、図35を参照すると、MSC40では、呼制御部404Bは、ステップS901において、移動局10からの呼確立要求の受信後、ステップS902において、無線アクセスベアラにためのQoS(Quality of Service)を決定し、その後、ステップS903において、Call Typeパラメータの決定処理を起動する。MSC40におけるCall Typeパラメータの決定処理は、動作例1と同様であり、図29に示される通りである。
MSC40では、呼制御部404Bは、ステップS904において、RANAP:RAB ASSIGNMENT REQUESTメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:RAB ASSIGNMENT REQUESTメッセージの構成を、図36に示す。
HNB−GW30では、呼制御部306Bは、RANAP:RAB ASSIGNMENT REQUESTメッセージ受信時に、ステップS905において、Call Typeパラメータが含まれていた場合、ステップS906において、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
例えば、図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、MSC40から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う。
これによって、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
(1−B)パケット交換呼の場合
次に、SGSN50がパケット交換呼の呼種別の判別結果をRANAPのRAB ASSIGNMENT REQUESTメッセージにて通知する場合の動作例を説明する。
パケット交換呼である場合の動作シーケンスは、回線交換呼である場合にMSC40で行っていた処理を、SGSN50で行う点以外は同様である。ただし、ステップS802で起動するCall Typeパラメータの決定処理は異なっている。このSGSN50におけるCall Typeパラメータの決定処理は、動作例1と同様であり、図32に示される通りである。
SGSN50では、呼制御部504Bは、RANAP:RAB ASSIGNMENT REQUESTメッセージをHNB−GW30に送信する際に、Call Typeパラメータが決定されていれば、本Call Typeパラメータを設定する。本発明による、RANAP:RAB ASSIGNMENT REQUESTメッセージの構成は、図36に示すように、MSC40の場合と同様である。
HNB−GW30では、呼制御部306Bは、RANAP:RAB ASSIGNMENT REQUESTメッセージ受信時に、Call Typeパラメータが含まれていた場合、移動局10がHNB−GW30にアクセスした際の、HNBAP:UE REGISTER REQUESTメッセージ(図5)のRegistration Causeパラメータ(図6)と比較する。
図31に示すケース2では、HNBAP:UE REGISTER REQUESTメッセージのRegistration Causeパラメータが“Emergency Call”であるに関わらず、SGSN50から通知されたCall Typeパラメータは、“Normal Call”である。このことからHNB−GW30は、移動局10が緊急呼と偽って、不正にHNB20にアクセスしてきたと判断し、呼解放処理を行う
これによって、パケット交換のVoIPのケースにおいても、本来、HNB20にアクセスできない不正移動局10−2が、Establishment Causeを改ざんして緊急呼と偽り、HNB20によるサービスを受けることを防止することができる。
なお、本発明のHNB20、HNB−GW30、MSC40、およびSGSN50にて行われる方法は、コンピュータに実行させるためのプログラムに適用してもよい。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
以上、本発明を、好適な実施形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
例えば、第2の実施形態では、Emergency Cause値のRANAPプロトコルメッセージへの設定をHNB20にて行っているが、HNB−GW30にて行うこととしてもよい。
また、第2の実施形態では、不正対策処理をMSC40あるいはSGSN50にて行っているが、HNB−GW30にて行うこととしてもよい。この場合、第4の実施形態と同様に、HNB−GW30は、MSC40あるいはSGSN50から、移動局10が発呼した実際の呼種別が緊急呼であることを示す情報を受信し、図31のテーブルを用いて不正対策処理を実施することになる。
また、第1〜第4の実施形態によれば、RANAPプロトコルメッセージを用いて、移動局10が緊急呼として発呼を行ったことを示す情報または移動局10が発呼した実際の呼種別が緊急呼であることを示す情報を、HNB20、HNB−GW30およびコアネットワーク装置(MSC40またはSGSN50)間で通信した。しかし、RANAPプロトコルメッセージに限らず、HNB20、HNB−GW30またはコアネットワーク装置間で通信可能なメッセージであれば他のメッセージであってもよい。
本出願は、2009年4月17日に出願された日本出願特願2009−101130を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (14)

  1. 基地局とコアネットワーク装置とに接続するゲートウェイ装置であって、
    前記基地局から第一のメッセージを受信する第一の信号送受信部と、
    前記コアネットワーク装置から第二のメッセージを受信する第二の信号送受信部と、を有し、
    前記第一のメッセージと前記第二のメッセージとに含まれる緊急呼に関する情報の一貫性をチェックするゲートウェイ装置。
  2. 前記第一のメッセージは、UE REGISTER REQUESTメッセージである、請求項1に記載のゲートウェイ装置。
  3. 前記第二のメッセージは、RAB ASSIGNMENT REQUESTメッセージである、請求項1または2に記載のゲートウェイ装置。
  4. 前記第一のメッセージは、Registration Causeを含む、請求項1乃至3のいずれか1つに記載のゲートウェイ装置。
  5. 前記第一のメッセージは、登録に関するメッセージであり、
    前記第二のメッセージは、確立に関するメッセージである、請求項1乃至4のいずれか1つに記載のゲートウェイ装置。
  6. 前記登録に関するメッセージは、移動局を前記ゲートウェイ装置に登録するために前記基地局が前記ゲートウェイ装置に送信するメッセージである、請求項5に記載のゲートウェイ装置。
  7. 前記確立に関するメッセージは、前記コアネットワーク装置が前記ゲートウェイ装置に送信するメッセージである、請求項5または6に記載のゲートウェイ装置。
  8. 基地局とコアネットワーク装置とに接続するゲートウェイ装置による通信方法であって、
    前記基地局から第一のメッセージを受信するステップと、
    前記コアネットワーク装置から第二のメッセージを受信するステップと、
    前記第一のメッセージと前記第二のメッセージとに含まれる緊急呼に関する情報の一貫性をチェックするステップと、を有する通信方法。
  9. 前記第一のメッセージは、UE REGISTER REQUESTメッセージである、請求項8に記載の通信方法。
  10. 前記第二のメッセージは、RAB ASSIGNMENT REQUESTメッセージである、請求項8または9に記載の通信方法。
  11. 前記第一のメッセージは、Registration Causeを含む、請求項8乃至10のいずれか1つに記載の通信方法。
  12. 前記第一のメッセージは、登録に関するメッセージであり、
    前記第二のメッセージは、確立に関するメッセージである、請求項8乃至11のいずれか1つに記載の通信方法。
  13. 前記登録に関するメッセージは、移動局を前記ゲートウェイ装置に登録するために前記基地局が前記ゲートウェイ装置に送信するメッセージである、請求項12に記載の通信方法。
  14. 前記確立に関するメッセージは、前記コアネットワーク装置が前記ゲートウェイ装置に送信するメッセージである、請求項12または13に記載の通信方法。
JP2014137453A 2009-04-17 2014-07-03 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法 Active JP5648762B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014137453A JP5648762B2 (ja) 2009-04-17 2014-07-03 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2009101130 2009-04-17
JP2009101130 2009-04-17
JP2014137453A JP5648762B2 (ja) 2009-04-17 2014-07-03 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2013188233A Division JP5605482B2 (ja) 2009-04-17 2013-09-11 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2014219003A Division JP2015043615A (ja) 2009-04-17 2014-10-28 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Publications (2)

Publication Number Publication Date
JP2014209782A JP2014209782A (ja) 2014-11-06
JP5648762B2 true JP5648762B2 (ja) 2015-01-07

Family

ID=42982397

Family Applications (5)

Application Number Title Priority Date Filing Date
JP2011509238A Active JP5375954B2 (ja) 2009-04-17 2010-03-01 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2013188233A Active JP5605482B2 (ja) 2009-04-17 2013-09-11 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2014137453A Active JP5648762B2 (ja) 2009-04-17 2014-07-03 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2014219003A Pending JP2015043615A (ja) 2009-04-17 2014-10-28 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2015167924A Pending JP2016021766A (ja) 2009-04-17 2015-08-27 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2011509238A Active JP5375954B2 (ja) 2009-04-17 2010-03-01 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2013188233A Active JP5605482B2 (ja) 2009-04-17 2013-09-11 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2014219003A Pending JP2015043615A (ja) 2009-04-17 2014-10-28 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP2015167924A Pending JP2016021766A (ja) 2009-04-17 2015-08-27 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法

Country Status (10)

Country Link
US (2) US9241247B2 (ja)
EP (2) EP2421286A4 (ja)
JP (5) JP5375954B2 (ja)
KR (3) KR101779458B1 (ja)
CN (2) CN102396249B (ja)
AU (1) AU2010237984C1 (ja)
BR (1) BRPI1006629B1 (ja)
CA (2) CA2758430C (ja)
RU (2) RU2503141C2 (ja)
WO (1) WO2010119728A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101779458B1 (ko) 2009-04-17 2017-09-18 닛본 덴끼 가부시끼가이샤 이동 통신 시스템, 이동국, 기지국, 게이트웨이 장치, 코어 네트워크 장치, 통신 방법
US9544943B2 (en) 2010-11-04 2017-01-10 Qualcomm Incorporated Communicating via a FEMTO access point within a wireless communications system
JP5936435B2 (ja) 2012-05-07 2016-06-22 株式会社Nttドコモ 移動局
KR101365588B1 (ko) * 2012-07-25 2014-02-21 에스케이텔레콤 주식회사 기지국게이트웨이장치 및 기지국게이트웨이장치의 동작 방법
US9265084B2 (en) * 2012-09-11 2016-02-16 Apple Inc. Data buffering based on access stratum conditions in a call having both circuit-switched and packet-switched components
US9578508B2 (en) * 2013-03-13 2017-02-21 Qualcomm Incorporated Method and apparatus for wireless device countermeasures against malicious infrastructure
EP3228134B1 (en) 2014-12-04 2021-10-20 Telefonaktiebolaget LM Ericsson (publ) Position determination of a wireless device
US10341822B2 (en) 2015-03-30 2019-07-02 Nec Corporation Broadcast delivery system, gateway device, broadcast delivery method and storage medium
CN105101246B (zh) * 2015-07-27 2018-10-12 中国联合网络通信集团有限公司 一种确定存在覆盖空洞的小区的方法及装置
US9711521B2 (en) * 2015-08-31 2017-07-18 Taiwan Semiconductor Manufacturing Co., Ltd. Substrate fabrication method to improve RF (radio frequency) device performance
US9761546B2 (en) 2015-10-19 2017-09-12 Taiwan Semiconductor Manufacturing Co., Ltd. Trap layer substrate stacking technique to improve performance for RF devices

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5010A (en) * 1847-03-13 Improvement in hemp-brakes
JP2535939B2 (ja) 1987-08-27 1996-09-18 日本電気株式会社 多方向多重通信システム
JPS6455927A (en) 1987-08-27 1989-03-02 Nec Corp Multi-direction multiplex communication system
US7623447B1 (en) * 2000-04-10 2009-11-24 Nokia Corporation Telephony services in mobile IP networks
GB0015365D0 (en) * 2000-06-22 2000-08-16 Nokia Networks Oy Location services interworking with intelligent network
JP4026118B2 (ja) 2002-02-20 2007-12-26 日本電気株式会社 移動端末、緊急呼管理装置、緊急呼管理システム及び緊急呼の管理方法
EP1387589A1 (de) * 2002-07-29 2004-02-04 Siemens Aktiengesellschaft Media Gateway zur Bereitstellung der PSTN/ISDN Dienste in Netzwerken der nächsten Generation
US7333795B2 (en) * 2003-10-24 2008-02-19 Motorola Inc. Emergency call placement method
GB0326264D0 (en) 2003-11-11 2003-12-17 Nokia Corp Emergency call support for mobile communications
JP2005236703A (ja) * 2004-02-20 2005-09-02 Hitachi Hybrid Network Co Ltd Ip電話網への再呼び出しシステム及び再呼び出し方法
JP4269983B2 (ja) * 2004-03-12 2009-05-27 沖電気工業株式会社 中継装置、中継方法、および中継プログラム
BRPI0614520B1 (pt) 2005-08-02 2019-07-09 Qualcomm Incorporated Suporte de chamada de emergência voip
EP1768337A1 (en) * 2005-09-26 2007-03-28 Alcatel Intelligent border element
JP4672571B2 (ja) * 2006-02-24 2011-04-20 日本電信電話株式会社 VoIPネットワークにおける緊急呼呼び返し方法、緊急呼呼び返しシステム、VoIPノード装置およびプログラム
ATE435577T1 (de) 2006-02-24 2009-07-15 Ericsson Telefon Ab L M Gebührenberechnung- und ortsindikationen in einem generischen zugangsnetz
US20090061877A1 (en) * 2006-07-14 2009-03-05 Gallagher Michael D Generic Access to the Iu Interface
US20080076392A1 (en) 2006-09-22 2008-03-27 Amit Khetawat Method and apparatus for securing a wireless air interface
JP2008141490A (ja) * 2006-12-01 2008-06-19 Mitsubishi Electric Corp 緊急通報制御装置、無線通信端末および基地局
CN101222750B (zh) 2007-01-09 2014-07-09 华为技术有限公司 处理紧急呼叫、紧急呼叫回叫中被叫用户的方法及其应用
US8019331B2 (en) * 2007-02-26 2011-09-13 Kineto Wireless, Inc. Femtocell integration into the macro network
WO2008111001A2 (en) 2007-03-13 2008-09-18 Nokia Corporation System for establishing and controlling emergency priority in a communication system
US8072953B2 (en) * 2007-04-24 2011-12-06 Interdigital Technology Corporation Wireless communication method and apparatus for performing home Node-B identification and access restriction
CN101068279B (zh) * 2007-06-13 2011-01-19 中兴通讯股份有限公司 一种紧急呼叫的回呼实现方法
EP2180728B1 (en) * 2007-07-20 2017-12-20 Fujitsu Limited Emergency call number information acquiring system
CN101466083B (zh) 2007-12-18 2010-12-08 华为技术有限公司 一种紧急呼叫方法和装置
CN101500213B (zh) 2008-02-03 2011-04-20 华为技术有限公司 一种用户设备紧急接入的方法、设备和系统
CN101448232B (zh) * 2008-04-30 2013-05-08 中兴通讯股份有限公司 紧急呼叫实现方法及系统、用户设备
JP4755223B2 (ja) 2008-05-26 2011-08-24 富士通株式会社 無線通信システム
US20120069737A1 (en) * 2009-03-27 2012-03-22 Telefonaktiebolaget L M Ericsson (Publ) Overload avoidance with home node b gateway (henb gw) in lte
KR101779458B1 (ko) 2009-04-17 2017-09-18 닛본 덴끼 가부시끼가이샤 이동 통신 시스템, 이동국, 기지국, 게이트웨이 장치, 코어 네트워크 장치, 통신 방법

Also Published As

Publication number Publication date
CA2872131A1 (en) 2010-10-21
WO2010119728A1 (ja) 2010-10-21
JP2014209782A (ja) 2014-11-06
JP5375954B2 (ja) 2013-12-25
EP3306966A1 (en) 2018-04-11
RU2011146642A (ru) 2013-06-27
CN104507090A (zh) 2015-04-08
US20150111518A1 (en) 2015-04-23
KR20150013937A (ko) 2015-02-05
BRPI1006629B1 (pt) 2021-07-20
EP3306966B1 (en) 2020-07-22
CA2758430A1 (en) 2010-10-21
KR20130119508A (ko) 2013-10-31
BRPI1006629A2 (pt) 2020-12-22
JPWO2010119728A1 (ja) 2012-10-22
CN102396249A (zh) 2012-03-28
CN102396249B (zh) 2015-07-29
JP2014039280A (ja) 2014-02-27
CA2872131C (en) 2017-01-10
AU2010237984A1 (en) 2011-10-13
JP5605482B2 (ja) 2014-10-15
RU2013140444A (ru) 2015-03-10
RU2503141C2 (ru) 2013-12-27
RU2632906C2 (ru) 2017-10-11
US20120015620A1 (en) 2012-01-19
AU2010237984C1 (en) 2015-01-22
CN104507090B (zh) 2019-02-12
JP2016021766A (ja) 2016-02-04
US9241247B2 (en) 2016-01-19
AU2010237984B2 (en) 2014-07-03
EP2421286A4 (en) 2016-10-12
KR20110138239A (ko) 2011-12-26
US9560508B2 (en) 2017-01-31
EP2421286A1 (en) 2012-02-22
KR101779458B1 (ko) 2017-09-18
RU2015155588A (ru) 2017-06-28
CA2758430C (en) 2016-08-23
JP2015043615A (ja) 2015-03-05

Similar Documents

Publication Publication Date Title
JP5648762B2 (ja) 移動通信システム、基地局、ゲートウェイ装置、コアネットワーク装置、通信方法
JP4957864B2 (ja) 移動通信システム
RU2574388C2 (ru) Система мобильной связи, базовая станция, устройство шлюза, устройство базовой сети и способ связи
AU2014208327B2 (en) Mobile communication system, base station, gateway apparatus, core network apparatus, communication method
AU2012203527B2 (en) Mobile communication system

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140919

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141014

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141027

R150 Certificate of patent or registration of utility model

Ref document number: 5648762

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150