AU2012203527B2 - Mobile communication system - Google Patents

Abstract

Abstract A mobile communication system of the present invention includes: a mobile station; a base station wirelessly communicating with the mobile station; and a gateway apparatus connected to the base station and a core network. The base station includes: first transmission 5 means for transmitting a registration message for registering the mobile station in the gateway apparatus; and second transmission means for transmitting a message pertaining to establishment of an emergency call originated by the mobile station. The gateway apparatus includes: first reception means for receiving the registration message from the base station; second reception means for receiving an establishment message pertaining to establishment of 10 the emergency call from the base station; and check means for checking consistency between the registration message and the establishment message. Fig.1 circuit switching packet switching 5 0 Station station (MSC) (SGSN) femto base station 3 0 gateway (HNB-GW) femto base station (HNB) mobile station unauthorized mobile 1 0 - 2 supporting 3rd station supporting 1 0 - 1 generation 3rd generation

Description

AUSTRALIA Regulation 3.2 Patents Act 1990 Complete Specification Standard Patent DIVISIONAL APPLICANT: NEC Corporation Invention Title: MOBILE COMMUNICATION SYSTEM The following statement is a full description of this invention, including the best method of performing it known to me: Description Title of Invention: MOBILE COMMUNICATION SYSTEM 5 Technical Field [0001] The present invention relates to a mobile communication system. Background Art 10 [00021 It is considered that industrial utilization forms of a femto base station (Home Node B; hereinafter abbreviated as HNB) include, for example, a form of utilization as a small wireless base station intended for home use, and a form of utilization as a small wireless base station in a corporation. 15 [0003] A case of providing service by the HNB includes, for example, the following advantages: [0004] (1) Capability for providing a call service in a blind zone, where radio waves from a 20 macro base station do not reach; (2) Capability for providing a billing service less expensive than typical services provided by the macro base station; (3) Capability for taking advantage of speed-enhancement technologies of 64QAM (64 Quadrature Amplitude Modulation) and MIMO (Multiple Input Multiple Output) and thereby 25 allowing a high-speed packet service subordinate to the IHNB to be provided, because the distance between a base station and a mobile station is short and the mobile station can attain high wireless quality (Ec/Io); and (4) Capability for providing a specific content service taking advantage of locality of the HNB. 30 As described above, service by HNB includes a lot of advantages. Accordingly, it is preferable to provide the service only for subscribers having signed a contract with a carrier and subscribers that the owner of the HNB permits. [0005] Thus, the 3GPP (3rd Generation Partnership Project), in release 8, has introduced a 2 CSG (Closed Subscriber Group) such that only mobile stations in a permitted group can access the HNB and enjoy the service. [0006] The CSG will herein be described in detail with reference to Figure 1. 5 [0007] A third generation mobile communication system shown in Figure 1 includes HNB 20, femto base station gateway (Home Node B GW; hereinafter abbreviated as HNB-GW) 30, circuit switching station (Mobile Switching Center; hereinafter abbreviated as MSC) 40, packet switching station (Serving GPRS Support Node; hereinafter abbreviated as SGSN) 50, and third 10 generation mobile stations 10-1 and 10-2. [0008] In Figure 1, mobile station 10-1 among mobile stations 10-1 and 10-2 residing in an area subordinate to HNB 20 is an authorized mobile station. On the other hand, mobile station 10-2 is a mobile station that intends to receive a service by HNB 20 in an unauthorized manner, 15 and hereinafter is referred to as unauthorized mobile station 10-2. In the case of a mobile station that does not identify itself, such a mobile station will be referred to as mobile station 10. [0009] HNB 20 is connected to a core network of an operator via HNB-GW 30. 20 [0010] The core network, which is a core network apparatus, includes MSC 40 that controls circuit switching and SGSN 50 that controls packet switching. [00111 If HNB 20 supports a CSG function, HNB 20 notifies mobile station 10 residing in an 25 area subordinate to HNB 20 of the CSG identifier (CSG identity) of the own CSG cell. [0012] Mobile station 10-1 decodes the CSG identifier notified from HNB 20, and determines whether the CSG identifier is included in a CSG list included in mobile station 10-1. [0013] 30 If the CSG identifier is included in the CSG list, mobile station 10-1 camps on a CSG cell where mobile station 10-1 resides, and is capable of enjoying various services, such as origination of a call and reception of an incoming call. [0014] On the other hand, if the CSG identifier is not included in the CSG list, mobile station 3 10-1 does not camp on the CSG cell where mobile station 10-1 resides, but performs an operation of selecting an appropriate CSG cell other than the CSG cell concerned. [00151 This mechanism enables only selected mobile station 10-1 with CSG identifier of the 5 CSG cell of HNB 20 to access HNB 20. [0016] However, a case can be supposed where it is intended to receive a service in an unauthorized manner in an originally inaccessible CSG cell of HNB 20 as with unauthorized mobile station 10-2 shown in Figure 1 even though the CSG function is supported. 10 [0017] In such a case, MSC 40 or SGSN 50 checks the IMSI (International Mobile Subscriber Identity) of mobile station 10 and the CSG identifier of the CSG cell where mobile station 10 resides, and thereby performs access regulation that regulates access from mobile station 10 to HNB 20 (3GPP TS25.467 Ver 8.0.0 Section 5.1.3). 15 [0018] On the other hand, because the CSG function has been introduced from release 8 of 3GPP, there was a case where mobile station 10-1, before release 8, did not support the CSG function. Further, there is a case where HNB 20 does not support the CSG function. [0019] 20 In these cases, HNB 20 performs an identification procedure (3GPP TS24.008 Ver 8.4.0) on mobile station 10-1 in order to inquire about the IMSI of mobile station 10-1. HNB 20 performs an HNBAP (HNB Application Part): UE REGISTER REQUEST procedure (3GPP TS25.469 Ver 8.0.0) on HNB-GW 30 in order to register mobile station 10-1 in HNB-GW 30. Here, HNB-GW 30 checks whether the IMSI of mobile station 10-1 is accessible or not to HNB 25 20, and thereby regulates access. [0020] When HNB-GW 30 determines that mobile station 10-1 is accessible to HNB 20, HNB-GW 30 notifies HNB 20 that access is permitted, by means of an HNBAP: UE REGISTER ACCEPT message. Accordingly, the service by HNB 20 is provided for mobile 30 station 10-1. [0021] On the other hand, if mobile station 10 is unauthorized mobile station 10-2 shown in Figure 1, the IMSI of unauthorized mobile station 10-2 will not have been registered to be accessible to the CSG. Accordingly, HNB-GW 30 determines that unauthorized mobile station 4 10-2 cannot access HNB 20, and notifies HNB 20 that access cannot be permitted, by means of HNBAP: UE REGISTER REJECT message. This terminates an RRC (Radio Resource Control) connection between unauthorized mobile station 10-2 and HNB 20 (3GPP TS25.467 Ver 8.0.0 Section 5.1.2). 5 [0022] As described above, in a case of providing the service by HNB 20, if unauthorized mobile station 10-2 whose access to HNB 20 is not permitted originates a call, the mobile communication network rejects access to HNB 20 in a signal establishment process because MSC 40, SGSN 50 or HNB-GW 30 regulates access on the basis of the IMSI of mobile station 10 10. [0023] On the other hand, 3GPP standardization specifies that even mobile station 10 originally inaccessible to HNB 20 can originate a call if the call type is an emergency call (3GPP TS22.011 Ver 8.6.0 Section 8.5.1). 15 [00241 If the call type is an emergency call, mobile station 10-1 sets "Emergency Call" to an Establishment Cause parameter representing the cause of an establishment request in RRC: RRC CONNECTION REQUEST message or RRC: INITIAL DIRECT TRANSFER to be transmitted to HNB 20 on a RRC connection establishment request or a signaling connection 20 establishment request (3GPP TS25.331 Ver 8.5.0 Section 10.3.3.11, Patent Literature 1). [0025] HNB 20 then sets an "Emergency Call" value to a Registration Cause parameter in a HNBAP: UE REGISTER REQUEST message to be transmitted to HNB-GW 30. [0026] 5 f the Registraon Cause parameter gency Cal-, -GWC 30 does not perform access regulation based on the IMSI (3GPP TS25.467 Ver 8.0.0 Section 5.1.2). [0027] This method enables even mobile station 10 that originally is unable to access to HNB 20 to skip the access regulation of HNB-GW 30 and to access HNB 20 if the call type is an 30 emergency call. [0028] Here, Figure 2 shows a configuration of an RRC: RRC CONNECTION REQUEST message; Figure 3 shows a configuration of an RRC: INITIAL DIRECT TRANSFER message; Figure 4 shows a configuration of the Establishment Cause parameter of an RRC protocol; 5 Figure 5 shows a configuration of an HNBAP: UE REGISTER REQUEST message; and Figure 6 shows a configuration of a Registration Cause parameter of an HBNAP protocol. Citation List 5 Patent Literature [0029] Patent Literature 1: JP 2 003-244284A Summary of Invention 10 Technical Problem [0030] The aforementioned technique skips the access regulation of HNB-GW 30 and permits mobile station 10 to access HNB 20 if mobile station 10 has originated a call as an emergency call. 15 [00311 Thus, this enables even mobile station 10 that originally is unable to access to HNB 20, such as unauthorized mobile station 10-2, to access HNB 20, by misrepresenting the Establishment Cause parameter in the RRC protocol as "Emergency Call" and by being out of the access regulation of HNB-GW 30. 20 [0032] It is considered that such unauthorized mobile station 10-2 can easily be created by modifying software so as to falsify only the Establishment Cause parameter. [0033] Instead, there is a case that an apparatus exists among authorized mobile station 10-1 25 and HNB 20, in which the apparatus decodes an RRC: RRC CONNECTION REQUEST message, that is to be transmitted from authorized mobile station 10-1 to a common channel (RACH: Random Access Channel) and is not concealed or subjected to measures against falsification, replaces the Establishment Cause parameter with "Emergency Call", encodes RRC: RRC CONNECTION REQUEST message, and transmits it to HNB 20. In this case, 30 even the authorized mobile station 10-1 is treated the same way that aforementioned unauthorized mobile station 10-2 is treated. [0034] Such unauthorized mobile station 10-2 causes following problems. [0035] 6 (1) HNB 20 installed in a home or a corporation is used by unauthorized mobile station 10-2 in an unauthorized manner. (2) Unauthorized mobile station 10-2 can enjoy a billing service that is less expensive than a normal billing service by originating a call via HNB 20 in an unauthorized manner. 5 (3) A content service dedicated to specific users is enjoyed by unauthorized mobile station 10-2 in an unauthorized manner. A method for solving these problems is considered where, when mobile station 10 has originated a call as an emergency call, the core network apparatus performs a call releasing process on mobile station 10. This requires that the core network apparatus knows that mobile 10 station 10 has originated the call as an emergency call. [0036] However, in the present configuration, the core network apparatus cannot know that mobile station 10 has originated a call as an emergency call. [0037] 15 Instead, it is also considered that HNB-GW 30 performs the call releasing process on mobile station 10 that has originated the call as an emergency call. This requires that HNB-GW 30 knows whether the type of the call that is actually originated by mobile station 10 is an emergency call or not. [0038] 20 However, in the present configuration, HNB-GW 30 cannot know the type of call that is actually originated by mobile station 10. [0039] It is an object of the present invention to provide a mobile communication system where a core network apparatus is capable of knowing that a mobile station has originated a call 25 as an emergency call [0040] It is another object of the present invention to provide a mobile communication system where a gateway apparatus is capable of knowing the type of a call that is actually originated by a mobile station. 30 Solution to Problem [0041] A mobile communication system of the present invention includes:: a mobile station; 7 a base station wirelessly communicating with the mobile station; and a gateway apparatus connected to the base station and a core network, wherein the base station includes: first transmission means for transmitting a registration message for registering the 5 mobile station in the gateway apparatus; and second transmission means for transmitting a message pertaining to establishment of an emergency call that is originated by the mobile station, the gateway apparatus includes: first reception means for receiving the registration message from the base station; 10 second reception means for receiving an establishment message pertaining to establishment of the emergency call from the base station; and check means for checking the consistency between the registration message and the establishment message. [0042] 15 A gateway apparatus of the present invention is a gateway apparatus connecting a base station to a core network, including: first reception means receiving a registration message for registering a mobile station in the gateway apparatus from the base station; second reception means receiving an establishment message pertaining to an 20 emergency call that is originated by the mobile station from the base station; and check means for checking the consistency between the registration message and the establishment message. [0043] A first communication method of the present invention is a communication method by 25 a mobile communication system including: a mobile station; a base station wirelessly communicating with the mobile station; and a gateway apparatus connected to the base station and a core network, wherein the base station transmits a registration message for registering the mobile 30 station in the gateway apparatus, the base station transmits a message pertaining to establishment of an emergency call that is originated by the mobile station, -the gateway apparatus receives the registration message from the base station, the gateway apparatus receives an establishment message pertaining to establishment 8 of the emergency call from the base station; and the gateway apparatus performs a check of consistency between the registration message and the establishment message. (0044] 5 A second communication method of the present invention is a communication method by a gateway apparatus connecting a base station to a core network, including: receiving a registration message for registering a mobile station in the gateway apparatus from the base station; receiving an establishment message pertaining to establishment of an emergency call 10 that is originated by the mobile station from the base station; and performing a check of consistency between the registration message and the establishment message. Advantageous Effects of Invention 15 [0045] According to the first mobile communication system, the base station or the gateway apparatus includes information indicating that the mobile station has originated an emergency call into a message and transmits the message to the core network apparatus. [0046] 20 Accordingly, an advantageous effect allowing the core network apparatus to know that the mobile station has originated a call as an emergency call can be obtained. [0047] - According to the second mobile communication system, the core network apparatus includes information indicating that the type of the call that is originated by the mobile station 25 is an emergency call into a message and transmits the message to the gateway apparatus. [0048] Accordingly, an advantageous effect allowing the gateway apparatus to know that the type of the call that is actually originated by the mobile station is an emergency call can be obtained. 30 Brief Description of Drawings [0049] Figure lis a diagram showing a configuration of a third generation mobile communication system.

9 Figure 2 is a diagram showing a configuration of an RRC CONNECTION REQUEST message. Figure 3 is a diagram showing a configuration of an INITIAL DIRECT TRANSFER message. 5 Figure 4 is a diagram showing a configuration of an Establishment Cause parameter. Figure 5 is a diagram showing a configuration of a UE REGISTER REQUEST message. Figure 6 is a diagram showing a configuration of a Registration Cause parameter. Figure 7 is a block diagram showing a configuration of an HNB of a first exemplary 10 embodiment. Figure 8 is a block diagram showing a configuration of an HNB-GW of the first exemplary embodiment. Figure 9 is a block diagram showing a configuration of an MSC of the first exemplary embodiment. 15 Figure 10 is a block diagram showing a configuration of an SGSN of the first exemplary embodiment. Figure 11 is a block diagram showing a configuration of an HNB of a second exemplary embodiment. Figure 12 is a block diagram showing a configuration of an HNB-GW of the second 20 exemplary embodiment. Figure 13 is a block diagram showing a configuration of an MSC of the second exemplary embodiment. Figure 14 is a block diagram showing a configuration of an SGSN of the second exemplary embodiment. 25 Figure 15 is a sequence diagram illustrating an operation of a mobile communication system of the second exemplary embodiment. Figure 16 is a diagram showing a configuration of a CM SERVICE REQUEST message. Figure 17 is a diagram showing a configuration of a CM Service Type parameter. 30 Figure 18 is a flowchart showing a process of determining a Registration Cause parameter by the HNB. Figure 19 is a diagram showing a configuration of an INITIAL UE MESSAGE message where an Emergency Cause parameter according to the present invention has been added.

10 Figure 20 is a flowchart showing an anti-fraud process by the MSC of the second exemplary embodiment. Figure 21 is a flowchart showing an anti-fraud process by the SGSN of the second exemplary embodiment. 5 Figure 22 is a block diagram showing a configuration of an MSC of a third exemplary embodiment. Figure 23 is a block diagram showing a configuration of an SGSN of the third exemplary embodiment. Figure 24 is a block diagram showing a configuration of an HNB-GW of the third 10 exemplary embodiment. Figure 25 is a block diagram showing a configuration of an MSC of a fourth exemplary embodiment. Figure 26 is a block diagram showing a configuration of an SGSN of a fourth exemplary embodiment. 15 Figure 27 is a diagram showing a configuration of an HNB-GW of a fourth exemplary embodiment. Figure 28 is a sequence diagram illustrating an operation example 1 of a mobile communication system of the fourth exemplary embodiment. Figure 29 is a flowchart of a process of determining a call type parameter by the MSC 20 of the fourth exemplary embodiment. Figure 30 is a diagram showing a configuration of a COMMON ID message according to the present invention. Figure 31 is a diagram showing a table for determining a process in the HNB-GW according to a call type of the fourth exemplary embodiment. 25 Figure 32 is a flowchart of showing a process of determining a Call Type parameter by the SGSN of the fourth exemplary embodiment. Figure 33 is a sequence diagram illustrating an operation example 2 of the mobile communication system of the fourth exemplary embodiment. Figure 34 is a diagram showing a configuration of a DIRECT TRANSFER message 30 according to the present invention. Figure 35 is a sequence diagram illustrating an operation example 3 of the mobile communication system of the fourth exemplary embodiment. Figure 36 is a diagram showing a configuration of an RAB ASSIGNMENT REQUEST message according to the present invention.

11 Figure 37 is a sequence diagram illustrating an operation of a mobile communication system of a fifth exemplary embodiment. Figure 38 is a sequence diagram illustrating an operation of a mobile communication system of a sixth exemplary embodiment. 5 Figure 39 is a diagram showing a parameter of an Allocation/Retention Priority according to a seventh exemplary embodiment. Figure 40 is a flowchart showing a call type setting process by an MSC of the seventh exemplary embodiment. Figure 41 is flowchart showing a call type setting process by SGSN of the seventh 10 exemplary embodiment. Figure 42 is a sequence diagram illustrating an operation of a mobile communication system of the seventh exemplary embodiment. Figure 43 is a sequence diagram illustrating an operation of a mobile communication system of an eighth exemplary embodiment. 15 Description of Embodiments [0050] Exemplary embodiments will hereinafter be described with reference to the drawings. [0051] 20 The overall configuration of a mobile communication system of the exemplary embodiments, which will be described below, is identical to that of the mobile communication system shown in Figure 1. [0052] (First Exemplary Embodiment) 25 Figures 7 to 10 show configurations of" HNB 20, HNB-GW 30, MSC 40 and SGSN 50 of this exemplary embodiment, respectively. [0053] Referring to Figure 7, HNB 20 of this exemplary embodiment includes: controller 21A that includes information indicating that mobile station 10 has originated a call as an emergency 30 call in an RANAP (Radio Access Network Application Part) protocol message; and transmitter 22A that transmits the RANAP protocol message to HNB-GW 30. The RANAP protocol message is a message in an application layer of a wireless access network, and includes, for example, a function of transparently transferring in an RAN a CC/MM signal to be transmitted and received between a UE and a core network apparatus.

12 [0054] Referring to Figure 8, HNB-GW 30 of this exemplary embodiment includes: receiver 3 1A that receives the RANAP protocol message from HNB 20; controller 32A extracting the RANAP protocol message; and transmitter 33A that transmits the RANAP protocol message to 5 MSC 40 or SGSN 50. [0055] Referring to Figure 9, MSC 40 of this exemplary embodiment includes: receiver 41A receiving the RANAP protocol message from HNB-GW 30; and controller 42A that, when information indicating that mobile station 10 has originated a call as an emergency call is 10 included in the RANAP protocol message, determines whether the type of the call that is actually originated by mobile station 10 is an emergency call or not, and performs a call releasing process if the type is not an emergency call. [0056] Referring to Figure 10, SGSN 50 of this exemplary embodiment includes: receiver 15 51 A receiving the RANAP protocol message from HNB-GW 30; and controller 52A that, when information indicating that mobile station 10 has originated a call as an emergency call is included in the RANAP protocol message, determines whether the type of the call that is actually originated by mobile station 10 is an emergency call or not, and performs a call releasing process if the type is not an emergency call. 20 [0057] Accordingly, in this exemplary embodiment, MSC 40 or SGSN 50 is capable of knowing that mobile station 10 has originated a call as an emergency call. [00581 As a result, when mobile station 10 has falsified the Establishment Cause and 25 misrepresented the call as an emergency call, MSC 40 or SGSN 50 can perform the call releasing process on mobile station 10. Accordingly, this can prevent a service by HNB 20 from being enjoyed in an unauthorized manner. [0059] (Second Exemplary Embodiment) 30 Figures 11 and 14 show configurations of HNB 20, HNB-GW 30, MSC 40, and SGSN 50 of this exemplary embodiment, respectively. This exemplary embodiment is an example where the configurations and operations of HNB 20, HNB-GW 30, MSC 40 and SGSN 50 of the first exemplary embodiment in Figures 7 to 10 are represented in a further specified manner. [0060] 13 Referring to Figure 11, HNB 20 of this exemplary embodiment includes: transmitter/receiver 201 A of signals to and from the mobile station; RUA (RANAP User Adaption) message processor 202A; transmitter/receiver 203A of signals to and from the HNB-GW; HNBAP message processor 204A; call controller 205A; RRC message processor 5 206A; and RANAP message processor 207A. [00611 In Figure 11, RUA message processor 202A, HNBAP message processor 204A, call controller 205A, RRC message processor 206A and RANAP message processor 207A configure controller 21A shown in Figure 7. Transmitter/receiver 203A of signals to and from 10 the HNB-GW is an example of transmitter 22A shown in Figure 7. [0062] Transmitter/receiver 201 A of signals to and from the mobile station includes, as functions for transmitting and receiving the RRC protocol message to and from mobile station 10: a concealment function of concealing (coding and decoding) the message; a signal delivery 15 confirmation function of confirming delivery of the message; and a signal distribution function of distributing the message. [0063] Transmitter/receiver 203A of signals to and from the HNB-GW includes, as functions for transmitting and receiving an HNBAP protocol message or an RUA protocol message to and 20 from HNB-GW 30: a concealment function; a signal delivery confirmation function; and a signal distribution function. [0064] RRC message processor 206A includes: a function of encoding the RRC protocol message to be transmitted to mobile station 10; and a function of decoding the RRC protocol 25 message received from mobile station 10. [0065] HNBAP message processor 204A includes: a function of encoding an HNBAP protocol message to be transmitted to HNB-GW 30; and a function of decoding the HNBAP protocol message received from HNB-GW 30. 30 [0066] RANAP message processor 207A includes: a function of encoding an RANAP message to be transmitted to HNB-GW 30; and a function of decoding the RANAP protocol message received from HNB-GW 30. [0067] 14 The RUA protocol serves to transfer the RANAP protocol message. RUA message processor 202A includes: a function of encoding an RUA protocol message to be transmitted to HNB-GW 30; and a function of decoding the RUA protocol message received from HNB-GW 30. 5 [0068] Call controller 205A initiates various call processes, such as establishment of RRC connection, establishment of a bearer, and mobility management on the basis of the RRC protocol message and the RANAP protocol message. Further, call controller 205A initiates the HNBAP protocol and performs a process of registering mobile station 10 in HNB-GW 30. 10 The above functions are typically included in a call controller implemented in HNB 20. [0069] In addition thereto, call controller 205A includes a function of setting the Emergency Cause value of the RANAP protocol message to be transmitted to HNB-GW 30 on the basis of the Registration Cause parameter of the HNBAP protocol message received from HNB-GW 30, 15 as a function specific to this exemplary embodiment. [0070] Referring to Figure 12, HNB-GW 30 of this exemplary embodiment includes: transmitter/receiver 301A of signals to and from the HNB; RUA message processor 302A; transmitter/receiver 303A of signals to and from the SGSN; transmitter/receiver 304A of signals 20 to and from the MSC; HNBAP message processor 305A; call controller 306A; RANAP message processor 307A; and station data storage 308A. [0071] In Figure 12, RUA message processor 302A, HNBAP message processor 305A, call controller 306A, RANAP message processor 307A and station data storage 308A configure 25 controller 32A shown in Figure 8. Transmitter/receiver 301A of signals to and from the HNB is an example of receiver 31A shown in Figure 8. Transmitter/receiver 303A of signals to and from the SGSN, and transmitter/receiver 304A of signals to and from the MSC are examples of transmitter 33A shown in Figure 8. [0072] 30 Transmitter/receiver 301A of signals to and from the HNB includes, as functions for transmitting and receiving the RUA protocol message and the HNBAP protocol message to and from HNB 20: a concealment function and a signal delivery confirmation function. [0073] Transmitter/receiver 304A of signals to and from the MSC includes, as functions for 15 transmitting and receiving the RANAP protocol message to and from MSC 40: a sequence control function of controlling a sequence of messages; and a delivery confirmation function. [0074] Transmitter/receiver 303A of signals to and from the SGSN includes, as functions for 5 transmitting and receiving the RANAP protocol message to and from SGSN 50: a delivery confirmation function; and a sequence control function. [0075] HNBAP message processor 305A includes: a function of encoding the HNBAP protocol message to be transmitted to HNB 20; and a function of decoding the HNBAP protocol 10 message received from the HNB. [0076] RUA message processor 302A includes: a function of encoding the RUA protocol message to be transmitted to HNB 20; and a function of decoding the RUA protocol message received from HNB 20. 15 [0077] RANAP message processor 307A includes a function of encoding the RANAP protocol message to be transmitted to MSC 40; and a function of decoding the RANAP protocol message received from MSC 40. [0078] 20 Call controller 306A performs a process of registering HNB 103, and a process of registering mobile station 10. Call controller 306A is capable of accessing station data stored in station data storage 308A. In the station data, a list of the accessible IMSI is set for each CSG. HNB-GW 30 regulates access to HNB 20 on the basis of this IMSI list. The above functions are typically included in a call controller implemented in HNB-GW 30. 25 [0079] Referring to Figure 13, MSC 40 of this exemplary embodiment includes: transmitter/receiver 401 A of signals to and from the HNB-GW; RANAP message processor 402A; NAS (Non Access Stratum) message processor 403A; call controller 404A; and station data storage 405A. 30 [0080] In Figure 13, RANAP message processor 402A, NAS message processor 403A, call controller 404A, and station data storage 405A configure controller 42A shown in Figure 9. Transmitter/receiver 401A of signals to and from the HNB-GW is an example of receiver 41A shown in Figure 9.

16 [00811 Transmitter/receiver 401A of signals to and from the HNB-GW includes, as functions for transmitting and receiving the RANAP protocol message to and from HNB-GW 30: a delivery confirmation function and a sequence control function. 5 [0082] RANAP message processor 402A includes: a function of encoding RANAP message to be transmitted to HNB-GW 30; and a function of decoding the RANAP protocol message received from HNB-GW 30. [0083] 10 NAS message processor 403A includes a function of transmitting and receiving NAS protocol (CC (Call Control) protocol and MM (Mobility Management) protocol) message to and from mobile station 10. [0084] Call controller 404A includes: a call processing of function performing call processes, 15 such as call establishment and call releasing; a mobility management function of performing mobility management, such as location registration and handover; and further an access regulation function of regulating access to HNB 20. Call controller 404A is capable of accessing station data stored in station data storage 405A. In the station data, a list of the accessible IMSI is set for each CSG. MSC 40 regulates access to HNB 20 on the basis of this 20 IMSI list. The above function is a function typically included in the call controller implemented in MSC 40. [0085] In addition thereto, call controller 404A includes, as a function specific to this exemplary embodiment: a function of analyzing the NAS message and determining whether the 25 type of the call that is originated by mobile station 10 is the an emergency call or not when the Emergency Cause parameter is set in the RANAP protocol message received from HNB-GW 30. If the call is not emergency call, call controller 404A performs the call releasing process. [0086] Referring to Figure 14, SGSN 50 of this exemplary embodiment includes: 30 transmitter/receiver 501 A of signals to and from the HNB-GW; RANAP message processor 502A; NAS message processor 503A; call controller 504A; and station data storage 505A. [0087] In Figure 14, RANAP message processor 502A, NAS message processor 503A, call controller 504A and station data storage 505A configure controller 52A shown in Figure 10.

17 Transmitter/receiver 501 A of signals to and from the HNB-GW is an example of receiver 51 A shown in Figure 10. [0088] Transmitter/receiver 501A of signals to and from the HNB-GW includes, as functions 5 for transmitting and receiving the RANAP protocol message to and from HNB-GW 30: a delivery confirmation function; and sequence control function. [0089] RANAP message processor 502A includes: a function of encoding the RANAP message to be transmitted to HNB-GW 30; and a function of decoding the RANAP protocol 10 message received from HNB-GW 30. [0090] NAS message processor 503A includes a function of transmitting and receiving NAS protocol (CC protocol and MM protocol) message to and from mobile station 10. [0091] 15 Call controller 504A includes: a call processing function; a mobility management function; and further, an access regulation function. Call controller 504A is capable of accessing the station data stored in station data storage 505A. In the station data a list of the accessible IMSI is set for each CSG. SGSN 50 regulates access to HNB 20 on the basis of this IMSI list. The above functions are typically included in the call controller implemented in 20 SGSN 50. [0092] In addition thereto, call controller 504A includes, as a function specific to this exemplary embodiment, a function of analyzing the NAS message and determining whether the call that is originated from mobile station 10 is an emergency call or not when the Emergency 25 Cause parameter is set in the RANAP protocol message received from the HNB-GW 30. If the call is not an emergency call, call controller 504A performs the call releasing process. [0093] An operation of the mobile communication system of this exemplary embodiment will hereinafter be described. 30 [0094] (A) A case of a circuit switching call First, an operation example of a case where mobile station 10 originates a call as a circuit switching emergency call is described along with a sequence diagram, of Figure 15, [0095] 18 Referring to Figure 15, mobile station 10 in step S101 sets the Establishment Cause (Figure 4) to be the RRC: RRC CONNECTION REQUEST message (Figure 2); and in step S102 transmits the RRC: RRC CONNECTION REQUEST message to HNB 20. [0096] 5 After establishment of wireless resources, in step S103, HNB 20 notifies mobile station 10 of this by means of an RRC: RRC CONNECTION SETUP message. [0097] After establishment of an RRC connection, in step S 104, mobile station 10 notifies HNB 20 of this by means of an RRC: RRC CONNECTION SETUP COMPLETE message. 10 [0098] Subsequently, in step S 105, mobile station 10 sets the CM Service Type parameter (Figure 17) of the CM SERVICE REQUEST message (Figure 16), which is the MM protocol message, to be "Emergency call establishment", and includes the CM SERVICE REQUEST message into the RRC: INITIAL DIRECT TRANSFER message (Figure 3). 15 [0099] Further, in step S106, mobile station 10 sets the Establishment Cause (Figure 4) of the RRC: INITIAL DIRECT TRANSFER message to be "Emergency Call", and transmits the RRC: INITIAL DIRECT TRANSFER message (Figure 3) to HNB 20. [0100] 20 In HNB 20, RRC protocol message processor 707A decodes the RRC: RRC CONNECTION REQUEST message transmitted in step S 102, and the RRC: INITIAL DIRECT TRANSFER message transmitted in step S 106. [0101] Further, in HNB 20, call controller 205A stores the Establishment Cause value (Figure 25 4) transmitted from mobile station 1V by means of an RRC: RRC CONNECTION REQUEST message and the RRC: INITIAL DIRECT TRANSFER message; and in step S107 determines the Registration Cause parameter on the basis of the Establishment Cause value and sets the parameter in the HNBAP: UE REGISTER REQUEST message (Figure 5). [0102] 30 Figure 18 shows a flowchart of a process of determining the Registration Cause parameter. [0103] ' Referring to Figure 18, call controller 205A in step S201 determines wheher the Establishment Cause value is the "Emergency Call" or not; when the value is the "Emergency 19 Call", in step S202 call controller 205A determines the Registration Cause parameter to be the "Emergency Call"; when the value is not "Emergency Call", in step S203 call controller 205A determines that the Registration Cause parameter is the "Normal Call". [0104] 5 Referring again to Figure 15, in step S 108, HNB 20 transmits the HNBAP: UE REGISTER REQUEST message (Figure 5) set with the Registration Cause parameter to HNB-GW 30, [0105] In HNB-GW 30, transmitter/receiver 301 A of signals to and from the HNB receives 10 the HNBAP: UE REGISTER REQUEST message. HNBAP message processor 305A decodes the HNBAP: UE REGISTER REQUEST message. In step S109, call controller 306A determines whether to perform the access regulation (step S 110) or not on the basis of the Registration Cause parameter set in the HNBAP: UE REGISTER REQUEST message. [0106] 15 If the Registration Cause parameter is "Emergency Call", HNB-GW 30 does not regulate access. In this case, call controller 306A assigns a context ID to applicable mobile station 10; HNBAP message processor 305A encodes the HNBAP: UE REGISTER ACCEPT message; and in step S 11 transmitter/receiver 30 LA of signals to and from the HNB transmits the HNBAP: UE REGISTER ACCEPT message to HNB 20. 20 [0107] In HNB 20, after reception of the HNBAP: UE REGISTER ACCEPT message, in step S112, call controller 205A determines whether the Registration Cause parameter is "Emergency Call" or not; if the parameter is "Emergency Call", in step S 113 call controller 205A generates an Emergency Cause parameter, which is introduced in the present invention (Figure 19). 25 RANAP message processor 207A encodes the RANAP: INITIAL UE MESSAGE message including the Emergency Cause parameter. Further, RANAP message processor 207A sets an NAS-PDU (Protocol Data Unit) parameter to the RANAP: INITIAL UE MESSAGE message, and sets the CM SERVICE REQUEST message of the MM protocol received from mobile station 10 to the NAS-PDU parameter. RUA message processor 703A generates an RUA: 30 CONNECT message including the RANAP: INITIAL UE MESSAGE message. That is, in step S 114, the RANAP: INITIAL UE MESSAGE message is transmitted from HNB 20 to HNB-GW 30 by means of RUA: CONNECT message. [0108] In HNB-GW 30, RUA message processor 302A decodes the CONNECT message of 20 the RUA protocol. Call controller 306A extracts the RANAP: INITIAL UE MESSAGE message that has already been encoded in HNB 20. In step S115, RANAP message processor 307A transmits the RANAP: INITIAL UE MESSAGE message to MSC 40 on the basis of routing information, such as a CN Domain ID. 5 [01091 In MSC 40, RANAP message processor 402A decodes the RANAP: INITIAL UE MESSAGE message. Further, NAS message processor 403A decodes the CM SERVICE REQUEST message set in the NAS-PDU. These decoded results are notified to call controller 404A. In step S116, call controller 404A determines whether the Emergency Cause parameter, 10 which is introduced in the present invention, is set or not. If the Emergency Cause parameter is set, in step S 117, call controller 404A initiates an anti-fraud process dedicated to the CS (Circuit Switching) service. [0110] Figure 20 shows a flowchart of the anti-fraud process dedicated to the CS service. 15 [0111] Referring to Figure 20, in step S301, call controller 404A checks whether the CM Service Type parameter (TS24.008 Ver 8.5.0 Section 10.5.3.3) set in the CM SERVICE REQUEST message (TS24.008 Ver 8.5.0 Section 9.2.9) of the MM protocol transmitted from mobile station 10 is "Emergency Call Establishment" or not. 20 [0112] Next, in step S302, call controller 404A checks whether a telephone number (TS24.008 Ver 8.5.0 Section 10.5.4.7) of the SETUP (TS24.008 Ver 8.5.0 Section 9.3.23 Setup) message of the CC protocol, which is an originating signal transmitted from MSC 40, is an emergency number or not. More specifically, in Figure 10.5.91/3GPP TS 24.008 Called party BCD 25 number information element of TS24.008 Ver 8.5.0, Number digit 1, Number digit 2, Number digit 3 and the like correspond to the telephone number. A check is made to determine whether these telephone numbers are emergency numbers or not. Called Party BCD Number in Section 10.5.4.7 of TS24.008 indicates the incoming number. BCD (BCD; Binary-coded decimal) is a representation form of a numerical value in a computer, and indicates what 30 represents one digit in a decimal notation as four'binary numbers, each of which represents one of 0 to 9. [0113] Next, in step S303, call controller 404A checks whether the EMERGENCY SETUP procedure (TS24.008 Ver 8.5.0 Section 9.3.8) is performed in mobile station 10 or not. For 21 example, on reception of a message for initiating "emergency call establishment" from mobile station 10, call controller 404A checks whether the EMERGENCY SETUP procedure is performed or not from information element "Emergency setup message type". [0114] 5 If any one of checks in steps S301 to S303 matches, call controller 404A determines that the call type is an emergency call, and continues the call process for the emergency call. On the other hand, if none of the checks matches, in step S304, call controller 404A determines that the call type is a normal call, determines that it is unauthorized mobile station 10-2 and initiates the call releasing process. 10 [0115] This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20. [0116] 15 (B) A case of a packet switching call Next, an operation example in a case where mobile station 10 originates a call as a packet switching emergency call will be described. [0117) The operation sequence of the case of the packet switching call is the same as in the 20 above case except that the processes performed in MSC 40 in the case of the circuit switching call are performed in SGSN 50. However, in the packet switching, an SM (Session Management) protocol message and a GMM (GPRS Mobility Management) protocol message are applied as NAS messages. Accordingly, the anti-fraud process initiated in step S117 is an anti-fraud process dedicated to PS (Packet Switching) service. The method in this process for 25 identifying an emergency call is different from the method of the CS service. Further, in a case where audio is used for packet switching, a VoWIP (Voice over IP) method is used. The GMM is a protocol for Mobility Management in the packet service (PS). [0118] Figure 21 shows a flowchart of the anti-fraud process dedicated to the PS service. 30 [0119] Referring to Figure 21, in step S40 1, call controller 504A of SGSN 50 checks whether an APN(Access Point Name)(3GPP TS24.008 9.5.1 10.5.6.1) set in the Activate PDP (Packet Data Protocol) context; request message (3GPP TS24.008 Ver 8.5.0 Section 9.5.1) of the SM protocol transmitted from mobile station 10 is specific to the emergency call or not.

22 [0120] Next, in step S402, call controller 504A checks whether an GMM procedure performed in mobile station 10 is an Emergency Attach procedure (TR23.869 Ver 9.0.0) or not. [0121] 5 Next, in step S403, call controller 504A checks whether a PDP Context active in SGSN 50 is a PDP Context dedicated to the emergency call or not. For example, call controller 504A checks whether the PDP Context active in SGSN 50 is an emergency PDP Context in TR23.869 Ver 9.0.0 or not. [0122] 10 If any one of checks in steps S401 to S403 matches, call controller 504A determines that the call type is an emergency call, and continues the call process for the emergency call. On the other hand, if none of the checks matches, in step S504, call controller 504A determines that the call type is a normal call, determines that it is unauthorized mobile station 10-2 and initiates the call releasing process. 15 [0123) Also in the case of the packet switching VoIP, this can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20. [0124] 20 (Third Exemplary Embodiment) Figures 22 to 24 show configurations of MSC 40, SGSN 50 and HNB-GW 30 of this exemplary embodiment, respectively. [0125] Referring to Figure 22, MSC 40 of this exemplary embodiment includes: controller 25 41B that determines whether the type of a call that is actually originated by mobile station 10 is an emergency call or not and includes information representing that the call type is an emergency call in the RANAP protocol message; and transmitter 42B that transmits the RANAP protocol message to HNB-GW 30. [0126] 30 Referring to Figure 23, SGSN 50 of this exemplary embodiment includes: controller 51 B that determines whether the type of a call that is actually originated by mobile station 10 is an emergency call or not and includes information representing that the call type is an emergency call in the RANAP protocol message; and transmitter 52B that transmits the RANAP protocol message to HNB-GW 30.

23 [0127] Referring to Figure 24, HNB-GW 30 of this exemplary embodiment includes: receiver 31 B that receives the RANAP protocol message from MSC 40 or SGSN 50; and controller 32B that performs the call releasing process when the information representing that the call type is 5 an emergency call is included in the RANAP protocol message. [0128} Accordingly, in this exemplary embodiment, HNB-GW 30 is capable of knowing that the type of the call that is actually originated by mobile station 10 is an emergency call. [0129] 10 As a result, when mobile station 10 has falsified the Establishment Cause and misrepresented the call as an emergency call, HNB-GW 30 can perform the call releasing process on mobile station 10. Accordingly, this can prevent a service by HNB 20 from being enjoyed in an unauthorized manner. [0130] 15 (Fourth Exemplary Embodiment) Figures 25 to 27 show configurations of MSC 40, SGSN 50 and HNB-GW 30 of this exemplary embodiment, respectively. This exemplary embodiment is an example where the configurations and operations of SC 40, SGSN 50 and HNB-GW 30 of the third exemplary embodiment in Figures 22 to 24 are represented in a further specified manner. 20 [0131] Referring to Figure 25, MSC 40 of this exemplary embodiment includes: transmitter/receiver 401B of signals to and from HNB-GW; RANAP message processor 402B; NAS message processor 403B; call controller 404B; and station data storage 405B. [0132] 25 In Figure 25, RANAP message processor 402B, NAS message processor 403B, call controller 404B and station data storage 405B configure controller 41B shown in Figure 22. Transmitter/receiver 401 B of signals to and from the HNB-GW is an example of transmitter 42B shown in Figure 22. [0133] 30 Transmitter/receiver 401B of signals to and from HNB-GW, RANAP message processor 402B, NAS message processor 403B and station data storage 405B include functions analogous to those of transmitter/receiver 401A of signals to and from the HNB-GW, RANAP message processor 402A, NAS message processor 403A and station data storage 405A shown in Figure 13, respectively.

24 [0134] Call controller 404B includes a function typically included in the call controller implemented in MSC 40 as with call controller 404A shown in Figure 13. [0135] 5 In addition thereto, call controller 404B includes, as a function specific to this exemplary embodiment, a function of analyzing the NAS message, determining whether the type of the call that is actually originated by mobile station 10 is an emergency call or not, and setting Call Type parameter of the RANAP protocol message to be transmitted to I-INB-GW 30 on the basis of the determined result. 10 [0136] Referring to Figure 26, SGSN 50 of this exemplary embodiment includes: transmitter/receiver 501B of signals to and from the HNB-GW; RANAP message processor 502B; NAS message processor 503B; call controller 504B; and station data storage 505B. [0137] 15 In Figure 26, RANAP message processor 502B, NAS message processor 503B, call controller 504B and station data storage 505B configure controller 511B shown in Figure 23. Transmitter/receiver 501B of signals to and from the HNB-GW is an example of transmitter 52B shown in Figure 23. [0138] 20 Transmitter/receiver 501B of signals to and from the HNB-GW signal, RANAP message processor 502B, NAS message processor 503B and station data storage 505B include functions analogous to those of transmitter/receiver 501 A of signals to and from H-NB-GW, RANAP message processor 502A, NAS message processor 503A and station data storage 505A shown in Figure 14, respectively. 25 [0139] Call controller 504B includes a function typically included in the call controller implemented in SGSN 50, as with call controller 504A shown in Figure 14. [0140] In addition thereto, call controller 504B includes, as a function specific to this 30 exemplary embodiment, a function of analyzing the NAS message, determining whether the type of the call that is actually originated by mobile station 10 is an emergency call or not, and setting Call Type parameter of the RANAP protocol message to be transmitted to HNB-GW 30 on the basis of the determined result. [0141] 25 Referring to Figure 27, HNB-GW 30 of this exemplary embodiment includes: transmitter/receiver 301 B of signals to and from HNB; RUA message processor 302B; transmitter/receiver 303B of signals to and from the SGSN; transmitter/receiver 304B of signals to and from the MSC; HNBAP message processor 305B; call controller 3068; RANAP 5 message processor 307B; and station data storage 308B. [0142] In Figure 27, RUA message processor 302B, HNBAP message processor 305B, call controller 3068, RANAP message processor 307B and station data storage 308B configure controller 32B shown in Figure 24. Transmitter/receiver 303B of signals to and from the 10 SGSN and transmitter/receiver 304B of signals to and from the MSC are examples of receiver 31B shown in Figure 24. [0143] Transmitter/receiver 301 B of signals to and from HNB, RUA message processor 302B, transmitter/receiver 303B of signals to and from the SGSN, transmitter/receiver 304B of signals 15 to and from the MSC, HNBAP message processor 305B, RANAP message processor 307B and station data storage 308B include functions analogous to those of transmitter/receiver 301 A of signals to and from the HNB, RUA message processor 302A, transmitter/receiver 303A of signals to and from the SGSN , transmitter/receiver 304A of signals to and from the MSC , HNBAP message processor 305A, RANAP message processor 307A and station data storage 20 308A shown in Figure 12, respectively. [0144] Call controller 306B includes a function typically included in the call controller implemented in HNB-GW 30 as with call controller 306A shown in Figure 12. [0145] 25 In addition thereto, call controller 306B includes, as a function specific to this exemplary embodiment, a function that, when the Call Type parameter of the RANAP protocol message that is received from MSC 40 or SGSN 50 is set to be a Normal Call, determines that the type of call that is originated by mobile station 10 is a normal call, and performs the call releasing process if mobile station 10 has originated the call as the emergency call. 30 [0146] The configuration of HNB 20 of this exemplary embodiment may be analogous to that in Figure 9. Note that call controller 205A of HNB 20 is required to have a function typically included in the call controller implemented in HNB 20 [0147] 26 Operations of the mobile communication system of this exemplary embodiment will hereinafter be described. [0148] (1) Operation Example I 5 This operation example is an example where the determination result of the call type determined in MSC 40 or SGSN 50 is notified by means of a COMMON ID message of RANAP (3GPP TS25.413). [0149] (1-A) A case of a circuit switching call 10 First, an operation example of a case where MSC 40 notifies the determination result of the call type of the circuit switching call by means of a COMMON ID message of the RANAP is described along with a sequence diagram of Figure 28. Figure 28 shows an operation after completion of the process shown in Figure 15. However, the processes in steps S112, S113, S116 and S117 shown in Figure 15 are not performed. Further, the Emergency 15 Cause parameter is not included in the RANAP: INITIAL UE MESSAGE message transmitted in steps S114 and S115. [0150] Typically, as described in 3GPP TS25.413, core network apparatus transmits an RANAP: COMMON ID message to H!NB-GW 30 after establishment of a signaling connection. 20 [0151] Accordingly, referring to Figure 28, in MSC 40, in step S501 call controller 404B establishes the signaling connection, and subsequently in step S502 initiates a process of determining the Call Type parameter. [0152] 25 Figure 29 shows a flowchart of the process of determining the Call Type parameter in MSC 40. [0153] Referring to Figure 29, in step S601, call controller 404B checks whether the CM Service Type parameter (TS24.008 Ver 8.5.0 Section 10.5.3.3) set in the CM SERVICE 30 REQUEST message (TS24,008 Ver 8.5.0 Section 9.2.9) of the MM protocol transmitted from mobile station 10 is "Emergency Call Establishment" or not. [0154] Next, in step S602, call controller 404B checks whether the telephone number (TS24.008 Ver 8.5.0 Section 10.5.4.7)of the SETUP (TS24.008 9.3.23 Ver 8.5.0 Section Setup) 27 message of the CC protocol, which is an originating call signal transmitted by MSC 40, is an emergency number or not. More specifically, in Figure 10.5.91/3GPP TS 24.008 Called party BCD number information element of TS24.008 Ver 8.5.0, Number digit 1, Number digit 2, Number digit 3 and the like correspond to the telephone number, and call controller 404B 5 checks whether the telephone number is an emergency number or not. The Called Party BCD Number in TS24.008 Section 10.5.4.7 indicates an incoming number. BCD is a representation form of a numerical value in a computer, and indicates what represents one digit in a decimal notation as four binary numbers, each of which represents one of 0 to 9. [0155] 10 Next, in step S603, call controller 404B checks whether an EMERGENCY SETUP procedure (TS24.008 Ver 8.5.0 Section 9.3.8) has been performed in mobile station 10 or not. For example, on reception of a message for initiating "emergency call establishment" from mobile station 10, call controller 404B checks whether the EMERGENCY SETUP procedure has been performed or not from an information element "Emergency setup message type". 15 [0156] If any one of checks in steps S601 to S603 matches, in step S604 call controller 404B determines that the call type is the emergency call, and determines that the Call Type parameter is "Normal Call". On the other hand, if none of the checks matches, in step S605 call controller 404B determines that the call type is a normal call, and determines that the Call Type 20 parameter is "Emergency Call". [0157] Referring to Figure 28 again, in MSC 40, in step S503 call controller 404B specifies the Call Type parameter if the call type parameter is determined when transmitting the RANAP: COMMON ID message to HNB-GW 30. Figure 30 shows a configuration of the RANAP: 25 COMMON ID message according to the present invention. [0158] In HNB-GW 30, in step S504 if the Call Type parameter is included when RANAP: COMMON ID message is received, in step 8505 call controller 306B comparers the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: UE REGISTER REQUEST 30 message (Figure 5) when mobile station 10 has accessed HNB-GW 30. [0159] Figure 31 is a diagram showing a table for determining a process in HNB-GW 30 according to the call type of this exemplary embodiment. [0160] 28 For example, in case 2 shown in Figure 3 1, the Call Type parameter notified by MSC 40 is a "Normal Call" even though the Registration Cause parameter of the HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, HNB-GW 30 determines that mobile station 10 has falsified the call as an emergency call and accessed HNB 5 20 in an unauthorized manner, and performs the'call releasing process. [0161] This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20. 10 [0162] (I-B) A case of a packet switching call Next, an operation example of a case where SGSN 50 notifies the determination result of the call type of the packet switching call by means of the COMMON ID message of the RANAP is described. 15 [0163] An operation sequence of the case of the packet switching call is analogous to the above case except that the processes performed in MSC 40 in the case of the circuit switching call are performed in SGSN 50. However, a process of determining the Call Type parameter initiated in step S502 is different. 20 [0164] Figure 32 shows a flowchart of the process of determining the Call Type parameter in SGSN 50. [0165] Referring to Figure 32, in step S70 1, call controller 504B checks whether an APN 25 (3GPP TS24.008 9.5.1 10.5.6.1) set in an Activate PDP context request message (3GPP TS24.008 Ver 8.5.0 Section 9.5.1) set in the SM protocol transmitted from mobile station 10 is specific to an emergency call or not. [0166] Next, in step S702, call controller 504B checks whether the GMM procedure 30 performed in mobile station 10 is the Emergency Attach procedure (TR23.869 Ver 9.0.0) or not. [0167] Next, in step S703, call controller 504B checks whether the PDP Context active in SGSN 50 is the PDP Context dedicated to an emergency call or not. For example, call controller 504B checks whether the PDP Context active in SGSN 50 is the Emergency PDP 29 Context of TR23.869 Ver 9.0.0 or not. [0168] If any one of the checks in steps S701 to S703 matches, in S704 call controller 504B determines that the call type is the emergency call, and determines that the Call Type parameter 5 is a "Normal Call". On the other hand, if none of the checks matches, in step S705 call controller 504B determines that the call type is a normal call, and determines that the Call Type parameter as "Emergency Call". [0169] When the RANAP: COMMON ID message is transmitted to HNB-GW 30, if the call 10 type parameter has been determined, in SGSN 50 call controller 504B specifies this Call Type parameter. The configuration of the RANAP: COMMON ID message according to the present invention is the same as in the case of MSC 40 as shown in Figure 30. [01701 If the Call Type parameter is included when RANAP: COMMON ID message is 15 received, in HNB-GW 30 call controller 306B compares the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: UE REGISTER REQUEST message (Figure 5) when the mobile station 10 accesses HNB-GW 30. [0171] For example, in the case 2 shown in Figure 31, the Call Type parameter notified by 20 SGSN 50 is a "Normal Call" even though the Registration Cause parameter of HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, HNB-GW 30 determines that mobile station 10 misrepresents the call as an emergency call and accesses HNB 20 in an unauthorized manner, and performs the call releasing process. [0172] 25 This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20 even in the case of the packet switching VoIP. [0173] (2) Operation Example 2 30 This operation example is an example where the determination result of the call type determined in MSC 40 or SGSN 50 is notified by means of the DIRECT TRANSFER message of the RANAP (3GPP TS25.413). [0174] ' (2-A) A case of a circuit switching call 30 First, an operation example of a case where MSC 40 notifies a determination result of the call type of a circuit switching call by means of a DIRECT TRANSFER message of the RANAP is described along with a sequence diagram of Figure 33. Figure 33 shows the operation after completion of the process shown in Figure 15. However, the processes in steps 5 S112, S113, S116 and Sl17 shown in Figure 15 are not performed. Further, the Emergency Cause parameter is not included in the RANAP: INITIAL UE MESSAGE message transmitted in steps 8114 and S115. [0175] Typically, as described in 3GPP TS25.413, when the core network apparatus transmits 10 NAS messages, such as the CC protocol and the MM protocol, the core network apparatus transmits the RANAP: DIRECT TRANSFER message to HNB-GW 30. [0176 Accordingly, referring to Figure 33, in MSC 40, in step S801 call controller 404B transmits the NAS message, and subsequently in step S802 initiates a process of determining 15 the Call Type parameter. The process of determining the Call Type parameter in MSC 40 is the same as with operation example I and as described in Figure 29. [0177] In MSC 40, when call controller 404B transmits the RANAP: DIRECT TRANSFER message to HNB-GW 30, if the Call Type parameter is determined, in step S803 call controller 20 404B specifies this Call Type parameter. Figure 34 shows the configuration of the RANAP: DIRECT TRANSFER message according to the present invention. [0178] In HNB-GW 30, in a case where call controller 306B receives the RANAP: DIRECT TRANSFER message, if in step 8804 the Call Type parameter is included, in step S805 call 25 controller 306B compares the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: UE REGISTER REQUEST message (Figure 5) when mobile station 10 has accessed HNB-GW 30. [0179] For example, in the case 2 shown in Figure 31, the Call Type parameter notified from 30 MSC 40 is a "Normal Call" even though the Registration Cause parameter of HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, HNB-GW 30 determines that mobile station 10 misrepresents the call as an emergency call and accesses HNB 20 it. an unauthorized manner, and performs the call releasing process. [0180] 31 This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20. [0181] 5 (1 -B) A case of a packet switching call Next, an operation example of a case where SGSN 50 notifies the determination result of the call type of the packet switching call by means of the DIRECT TRANSFER message of the RANAP is described. [0182] 10 An operation sequence of the case of the packet switching call is analogous to the above case except that the processes performed in MSC 40 in the case of the circuit switching call are performed in SGSN 50. However, the process of determining the Call Type parameter initiated in step S802 is different. The process of determining the Call Type parameter in SGSN 50 is the same as with operation example 1 and as described in Figure 32. 15 [0183] In SGSN 50, in a case where call controller 504B transmits the RANAP: DIRECT TRANSFER message to HNB-GW 30, if the Call Type parameter is determined, call controller 504B sets this Call Type parameter. The configuration of the RANAP: DIRECT TRANSFER message according to the present invention is the same as with the case of MSC 40 as shown in 20 Figure 34. [0184] In HNB-GW 30, in a case where call controller 306B receives the RANAP: DIRECT TRANSFER message, if the Call Type parameter is included, call controller 306B compares the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: UE REGISTER 25 REQUEST message (Figure 5) when mobile station 10 has accessed HNB-GW 3. [0185] For example, in the case 2 shown in Figure 31, the Call Type parameter notified from SGSN 50 is a "Normal Call" even though the Registration Cause parameter of HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, HNB-GW 30 30 determines that mobile station 10 misrepresents the call as an emergency call and accesses HNB 20 in an unauthorized manner, and performs the call releasing process. This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause; misrepresenting the call as an emergency call and enjoying the service by HNB 20 even in the case of the packet switching VoIP.

32 [0186] (3) Operation Example 3 This operation example is an example where the determination result of the call type determined in MSC 40 or SGSN 50 is notified by means of the RAB (Radio Access Bearer) 5 ASSIGNMENT REQUEST message of the RANAP (3GPP TS25.413). [0187] (3-A) A case of a circuit switching call First, an operation example of a case where MSC 40 notifies a determination result of the call type of a circuit switching call by means of an RAB ASSIGNMENT REQUEST 10 message of the RANAP is described along with a sequence diagram of Figure 35. Figure 35 shows the operation after completion of the process shown in Figure 15. However, the processes in steps S112, S113, S116 and S117 shown in Figure 15 are not performed. Further, the Emergency Cause parameter is not included in the RANAP: INITIAL UE MESSAGE message transmitted in steps S114 and S 115. 15 [0188) Typically, as described in 3GPP TS25.413, when the core network apparatus receives a call establishment request from mobile station 10 and establishes a wireless access bearer, the core network apparatus transmits the RANAP: RAB ASSIGNMENT REQUEST message to HNB-GW 30. 20 [0189] Accordingly, referring to Figure 35, in MSC 40, in step S901 call controller 404B receives the call establishment request from mobile station 10, and subsequently in step S902 determines a QoS (Quality of Service) for a wireless access bearer, and then in step S903 initiates a process of determining the Call Type parameter. The process of determining the 25 Call Type parameter in MSC 40 is the same as with operation example 1 and as described in Figure 29. [0190] In MSC 40, when in step S904 call controller 404B transmits the RANAP: RAB ASSIGNMENT REQUEST message to HNB-GW 30, if the Call Type parameter is determined, 30 call controller 404B sets this Call Type parameter. Figure 36 shows the configuration of the RANAP: RAB ASSIGNMENT REQUEST message according to the present invention. [0191] In HNB-GW 30, in case where call controller 306B receives the RANAP: RAB ASSIGNMENT REQUEST message, if in step S905 the Call Type parameter is included, in 33 step S906 call controller 306B compares the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: UE REGISTER REQUEST message (Figure 5) when mobile station 10 has accessed HNB-GW 30. [0192] 5 For example, in case 2 shown in Figure 31, the Call Type parameter notified from MSC 40 is a "Normal Call" even though the Registration Cause parameter of HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, HNB-GW 30 determines that mobile station 10 misrepresents the call as an emergency call and accesses HINB 20 in an unauthorized manner, and performs the call releasing process. 10 [0193] This can prevent unauthorized mobile station 10-2 that is originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20. [0194] 15 (1-B) A case of a packet switching call Next, an operation example of a case where SGSN 50 notifies the determination result of the call type of the packet switching call by means of the RAB ASSIGNMENT REQUEST message of the RANAP is described. [0195] 20 An operation sequence of the case of the packet switching call is analogous to the above case except that the processes performed in MSC 40 in the case of the circuit switching call are performed in SGSN 50. However, a process of determining the Call Type parameter initiated in step S802 is different. The process of determining the Call Type parameter in SGSN 50 is the same as with operation example 1 and as described in Figure 32. 25 [0196] In SGSN 50, in a case where call controller 504B transmits the RANAP: RAB ASSIGNMENT REQUEST message to HNB-GW 30, if the Call Type parameter is determined, call controller 504B sets this Call Type parameter. The configuration of the RANAP: RAB ASSIGNMENT REQUEST message according to the present invention is the same as with the 30 case of MSC 40 as described in Figure 36. [0197] In HNB-GW 30, in a case where call controller 306B receives the RANAP: RAB ASSIGNMENT REQUEST messageif the Call Type parameter is included, call controller 306B compares the parameter with the Registration Cause parameter (Figure 6) of the HNBAP: 34 UE REGISTER REQUEST message (Figure 5) when mobile station 10 has accessed HNB-GW 30. [0198] In case 2 shown in Figure 31, the Call Type parameter notified from SGSN 50 is a 5 "Normal Call" even though the Registration Cause parameter of HNBAP: UE REGISTER REQUEST message is an "Emergency Call". Based thereon, INB-GW 30 determines that mobile station 10 misrepresents the call as an emergency call and accesses HNB 20 in an unauthorized manner, and performs the call releasing process. [0199] 10 This can prevent unauthorized mobile station 10-2 originally inaccessible to HNB 20 from falsifying the Establishment Cause, misrepresenting the call as an emergency call and enjoying the service by HNB 20 even in the case of the packet switching VoIP. [0200] The methods performed in HNB 20, HNB-GW 30, MSC 40 and SGSN 50 of the 15 present invention may be applied to programs to be performed by a computer. The program can be stored in a storing medium, and provided for the outside via a network. [0201] (Fifth Exemplary Embodiment) In second exemplary embodiment, the anti-fraud process is performed in MSC 40 or 20 SGSN 50. However, in this exemplary embodiment the anti-fraud process is performed in HNB-GW 30. [0202] Figure 37 shows a sequence in this case. Figure 37 shows a case where HNB-GW has preliminarily been notified of Registration Cause = Emergency Call in a UE Register 25 procedure and HNB-GW checks the contents of the NAS message and initiates an anti-fraud process. This corresponds to a case where, when MSC has been notified from HNB-GW that UE has originated a call as an emergency call in Figure 15, MSC performs a process of checking a message of the MM or the CC protocol in Figure 20. Likewise, this corresponds to a case where, when HNB-GW indicates that UE has originated a call as an emergency call, 30 SGSN performs a process of checking a message of the GMM or SM protocol in Figure 21. The NAS message indicates Non Access Stratum, and indicates a protocol independent from a wireless access system. [0203] This exemplary embodiment exerts the following advantageous effects.

35 The HNG-GW performs the anti-fraud process, thereby negating the need of accompanied modification on the MSC or the SGSN. Accordingly, the MSC or the SGSN having already been operated is not modified when the femto is introduced. This enables the femto system to be easily introduced. 5 e Compared with the second exemplary embodiment, it is not necessary to add a new parameter to the RANAP protocol. This allows the size of the message of the RANAP protocol to be reduced, and enables the amount of signaling that is communicated between the HNB-GW and the MSC or the SGSN to be reduced. - The HNB-GW is capable of knowing whether a call is an emergency call or a normal call by 10 taking a quick look at the NAS message. Accordingly, the HNB-GW is capable of raising the priority of the emergency call procedure higher than that of the normal call with respect to resource assignment and traffic scheduling, even without notification of the call type from the MSC or the SGSN. [0204] 15 (Sixth Exemplary Embodiment) In the fifth exemplary embodiment, in a case where a terminal has originated a call as an emergency call, HNB-GW takes a quick look at the NAS message, thereby realizing the anti-fraud process. In this exemplary embodiment, this anti-fraud process is performed in HNB. That is, as shown in Figure 38, HNB takes a quick look at the NAS message and 20 initiates the anti-fraud process. [0205] This exemplary embodiment exerts following advantageous effects. * Since the HNB performs the anti-fraud process, communication with an unauthorized terminal can be terminated faster than that in a case where a higher-level device performs the 25 anti-fraud process. This allows usability of network resources to be improved, and enables the amount of signaling between the HNB and the HNB-GW to be reduced. * The HNB is capable of recognzing whether a call is an emergency call or a normal call by taking a quick look at the NAS message. Accordingly, the HNB is capable of raising the priority of the emergency call procedure higher than that of the normal call with respect to 30 resource assignment and traffic scheduling, without notification of the call type from the MSC or the SGSN. [0206] (Seventh Exemplary Embodiment) In the third exemplary embodiment, the MSC or SGSN notifies the HNB-GW of the 36 information of the emergency call, the HNB-GW verifies whether the UE has tried access as an emergency call or not. In the fourth exemplary embodiment, the parameter of the Call Type is used in the RANAP protocol. [0207] 5 This exemplary embodiment employs a parameter that is already defined in the 3GPP TS25.413 as information representing the emergency call of the RANAP and that is referred to as Allocation/Retention Priority (see Figure 39). [0208] The method of using the Allocation/Retention Priority is well known as a 10 publicly-known technique and thus is outside the scope of the present invention. For example, this technique is used for pre-emption in which, when resources for assigning a new bearer cannot be secured, another bearer that has less priority is released and the resources are vacated, thereby allowing the new bearer to acquire the resources. [0209] 15 In a case of an emergency call, the MSC or the SGSN sets this Allocation/Retention Priority parameter in the RAB ASSIGNMENT REQUEST message as follows. [0210] Priority Level = 1 Pre-emption Capability = "may trigger pre-emption" ?0 Pre-emption Vulnerability = not pre-emptable Notification can be made that the call is to be established as an emergency call according to such setting. Further, a message other than the RAB ASSIGNMENT REQUEST message of the RANAP may be used. In this case, logic of setting the Allocation/Retention Priority parameter as an emergency call in the MSC or the SGSN is analogous to that in Figures 25 29 and 32, and the same as with Figures 40 and 41. [0211] In Figures 40 and 41, this Allocation/Retention Priority parameter indicates a normal call. However, in a case where the Registration Cause value in the UE Registration procedure indicates an emergency call, the HNB-GW determines that the UE has falsified the 30 Establishment Cause and tried access, and performs call releasing. Figure 42 shows an operation sequence in this case. [0212] This exemplary embodiment exerts the following advantageous effects, * Notification is made whether the call is an emergency call or not using the existing 37 Allocation/Retention Priority, thereby making unnecessary accompanied modification on the MSC or the SGSN. Accordingly, the MSC or the SGSN having already been operated is not modified when the femto is introduced. This enables the femto system to be easily introduced. * Compared with the fourth exemplary embodiment, it is not necessary to add a new parameter 5 to the RANAP protocol. This allows the size of the message of the RANAP protocol to be reduced, and enables the amount of signaling that is communicated between the HNB-GW and the MSC or the SGSN to be reduced. [0213] (Eighth Exemplary Embodiment) 10 In the seventh exemplary embodiment, the HNB-GW determines the Allocation/Retention Priority parameter, and realizes the anti-fraud process. However, in this exemplary embodiment, this anti-fraud process is performed in the HNB. That is, as shown in Figure 43, when the HNB receives the RAB ASSIGNMENT REQUEST message of the RANAP, the HNB determines the Allocation/Retention Priority; in a case where the 15 determination indicates the normal call, if the Registration Cause in the UE Registration procedure is an emergency call, the HNB-GW determines that the UE has misrepresented the Establishment Cause and tried access, and performs call releasing. [0214] In the third and fourth exemplary embodiments, the HNB-GW performs the process of 20 comparing the call type notified from the MSC or the SGSN and the Registration Cause when the UE has tried access with each other. However, this process of comparison may be performed in the HNB. [0215] This exemplary embodiment exerts following advantageous effects. 25 The H1NB-GW terminates the RANAP protocol message, and makes it unnecessary to determine the call type by means of the Allocation/Retention Priority. This enables the process in the HNB-GW to be simplified. [0216] As described above, the present invention has been illustrated in a specified manner on 30 the basis of the exemplary embodiments. The present invention is not limited to the above cases. Needless to say, various modifications may be made within a scope without departing the gist thereof. [02171 For example, in the second exemplary embodiment, setting of the Emergency Cause 38 value to the RANAP protocol message is made in HNB 20. However, this may be made in HNB-GW30. [0218] Further, in the first to fourth exemplary embodiments, the information representing that 5 mobile station 10 has originated a call as an emergency call or the information representing that the actual type of the call that is originated by mobile station 10 is an emergency call, is communicated between HNB 20, HNB-GW 30 and the core network apparatus (MSC 40 or SGSN 50) using the RANAP protocol message. However, it is not limited to the RANAP protocol message. The message may be another message capable of communicating a ) message between HNB 20 and HNB-GW 30 or the core network apparatus. [0219] The present application claims priority from Japanese patent application No. 2009-229391 filed on October 1, 2009, the disclosure of which is herein incorporated by reference in its entirety. [0220] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps. [0221] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge in Australia.