RU2574388C2 - Mobile communication system, base station, gateway device, bearer network device and communication method - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: invention relates to a mobile communication system, which comprises a mobile station, a base station which wirelessly communicates with the mobile station, a gateway device which connects the base station to a bearer network and a bearer network device located on the bearer network. The base station comprises a control unit which includes in a message, information indicating that the mobile station has initiated a call as an emergency call, and a transmission unit which transmits the message to the bearer network device. The bearer network device also includes a receiving unit which receives the message transmitted from the base station.

EFFECT: preventing unauthorised access to network services.

14 cl, 36 dwg

Description

FIELD OF TECHNOLOGY

[0001] The present invention relates to a mobile communication system, a base station, a gateway device, a core network device, and a communication method.

BACKGROUND OF THE INVENTION

[0002] Forms of use of a femto base station (Home Node B, hereinafter abbreviated as "HNB") in industry that may be considered include, for example, forms of use such as a compact wireless base station for use in residential buildings and a compact wireless base station in business.

[0003] The provision of services through the HNB has the following advantages:

[0004] (1) communications services may be provided in dead zones beyond the reach of macrobase station radio waves,

(2) a paid service may be offered that is cheaper than normal paid services offered by macrobase stations,

(3) since high line quality (Ec / Io) can be obtained by the mobile station when the distance between the base station and the mobile station is small, high-speed technologies such as 64 QAM (64 quadrature amplitude modulation) or MIMO (multiple inputs - multiple outputs) can be used to provide a high-speed packet service package service under the control of HNB,

(4) a special content service may be offered that takes advantage of the HNB locality.

Since the services sold through the HNB have many advantages, as indicated above, the services should only be provided to subscribers who have contracted with a regular carrier or to subscribers who have permission from the owner of the HNB.

[0006] Accordingly, CSG (closed-end subscriber group) was introduced in Release 8 in 3GPP (3rd Generation Partnership Project) to restrict access and reception of HNB services only to mobile stations of groups that have permission.

[0006] Details regarding the CSG are further described with reference to FIG. 1.

[0007] The 2nd generation mobile communication system shown in FIG. 1 comprises: an HNB 20, a femto base station gateway (gateway (GW) of a home Node B (NodeB), hereinafter abbreviated as HNB-GW) 30, a switching station ( The Mobile Switching Center, hereinafter abbreviated as MSC) 40, a packet switching station (Serving GPRS Support Node, hereinafter abbreviated as SGSN) 50, and mobile stations 10-1 and 10-2 compatible with the 3rd generation.

[0008] Of the mobile stations 10-1 and 10-2 that are within range and controlled by the HNB 20 in FIG. 1, the mobile station 10-1 is an authorized mobile station. In contrast, the mobile station 10-2 is a mobile station that attempts to obtain the service provided by the HNB 20 without authorization, and is hereinafter referred to as an unauthorized mobile station 10-2. In the following description, the term “mobile station 10” is used when any mobile station is defined.

[0009] the HNB 20 is connected to the core network of the operator through the HNB-GW 30.

[0010] The core network includes, as devices of the core network, an MSC 40 that controls the switching of communication channels, and an SGSN 50 that controls packet switching.

[0011] When the CSG function is supported, the HNB 20 reports the CSG identifier (CSG identity) of its own CSG cell to the mobile station 10, which is in range and is controlled by the HNB 20.

[0012] The mobile station 10-1 decodes the CSG identifier, which is reported from the HNB 20, and determines whether the CSG identifier is included in the CSG list supported by the mobile station 10-1.

[0013] If the CSG identifier is included in the CSG list, the mobile station 10-1 can anchor in the CSG cell within which it is within range, and then receive various services, such as initiating a call or receiving incoming calls.

[0014] On the other hand, if the CSG identifier is not included in the CSG list, the mobile station 10-1 is not fixed to the CSG cell in which it is located at a range, and realizes the selection of a suitable CSG cell different from this CSG cell.

[0015] Through this mechanism, only limited mobile stations 10-1 that have a CSG CSG identifier of the cell of this HNB 20 can access the HNB 20.

[0016] However, a case may be considered in which an entity, such as an unauthorized mobile station 10-2 shown in FIG. 1, attempts to obtain a service without authorization in the CSG cell of the HNB 20, for which access is assumed to be unavailable, regardless Whether the CSG function is supported.

[0017] In this case, the MSC 40 or SGSN 50 checks the IMSI (International Mobile Subscriber Identity) of the mobile station 10 and the CSG identifier of the CSG of the cell in which the mobile terminal 10 is located to implement access control in order to regulate access to the mobile HNB 20 Station 10 (3GPP TS25.467 Ver 8.0.0, Section 5.1.3).

[0018] On the other hand, since the CSG function is the function introduced by 3GPP Release 8, there will be cases in which the mobile terminal 10-1 that precedes the Release 8 does not support the CSG function. Alternatively, there will also be cases in which the HNB 20 does not support the CSG function.

[0019] In such cases, the HNB 20 implements an identification procedure (3GPP TS24.008 Ver 8.4.0) with respect to the mobile station 10-1 to query for the IMSI of the mobile terminal 10-1, or the HNB 20 implements the HNBAP (Part of the HNB Application) : UE REGISTRATION REQUEST procedure (3GPP TS25.469 Ver 8.0.0) with respect to the HNB-GW 30 to register the mobile station 10-1 with the HNB-GW 30. At this time, the HNB-GW 30 perform access control, checking if whether the IMSI mobile station 10-1 gain access to the HNB 20.

[0020] If the HNB-GW 30 determines that the mobile station 10-1 can access the HNB 20, the HNB-GW 30 notifies the HNB 20 that access is allowed through an HNBAP message: ACCEPT UE REGISTRATION. Thus, the service implemented by the HNB 20 is provided to the mobile station 10-1.

[0021] On the other hand, if the mobile station 10 is an unauthorized mobile station 10-2 shown in FIG. 1, the IMSI of the unauthorized mobile station 10-2 is not registered to allow access to the CSG. As a result, the HNB-GW 30 determines that the unauthorized mobile station 10-2 cannot access the HNB 20 and notifies the HNB 20 via an HNBAP message: DENY UE REGISTRATION that access is not allowed. Thus, the RRC (Radio Resource Management) connection between the unauthorized mobile station 10-2 and the HNB 20 is disconnected (3GPP TS25.467 Ver 8.0.0, Section 5.1.2).

[0022] As described above, when the service is provided by the HNB 20, the MSC 40, the SGSN 50, or the HNB-GW 30 implements access control based on the IMSI of the mobile station 10, while access to the HNB 20 is denied on the mobile network side during the establishment procedure signal, even if an unauthorized mobile station 10-2, which is not allowed to access the HNB 20, must initiate a call.

[0023] However, in 3GPP standards, the ability to initiate a call is prescribed if the call type is an emergency call, even for a mobile station 10 that is not allowed to access the HNB 20 (3GPP TS22.011 Ver 8.6.0, Section 8.5.1).

[0024] When the type of call is an emergency call, the mobile station 10-1 sets up an “Emergency Call” in the Establishment Cause parameter, which indicates the reason for the establishment request in the RRC message: CONNECTION RRC REQUEST or RRC: START TRANSFER which is transmitted to the HNB 20 during a request to establish an RRC connection or during a request to establish a signaling connection (3GPP TS25.331 Ver 8.5.0, Section 10.3.3.11, Patent Document 1).

[0025] The HNB 20 then sets the value to "Emergency Call" in the Reason for Logging HNBAP message: REGISTRATION REQUEST UE, which is transmitted to the HNB-GW 30.

[0026] When the Registration Reason parameter is “Emergency Call,” the HNB-GW 30 does not implement IMSI-based access control (3GPP TS25.467 Ver 8.0.0, Section 5.1.2).

[0027] By this method, even a mobile station 10 that is not allowed access to the HNB 20 can skip access control of the HNB-GW 30 and gain access to the HNB 20 when the type of call is Emergency Call.

[0028] The composition of the RRC message: CONNECTION RRC REQUEST is shown in FIG. 2 here, the composition of the RRC message: START DIRECT TRANSFER is shown in FIG. 3, the composition of the Setting Cause parameter in the RRC protocol is shown in FIG. shown in FIG. 5, and the composition of the Registration Reason parameter in HBNAP is shown in FIG. 6.

BACKGROUND OF THE INVENTION

PATENT DOCUMENTS

[0029] Patent Document 1: JP-A-2003-244284.

SUMMARY OF THE INVENTION

PROBLEM SOLVED BY THE INVENTION

[0030] However, the above method skips the access control of the HNB-GW 30 and allows access to the HNB 20 by the mobile station 10 when the mobile station 10 initiates a call as an emergency call.

[0031] As a result, the mobile station 10, such as an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20, may falsely set the Reason for Setting to “Emergency Call” in the RRC protocol and thus evade access control HNB-GW 30 and access the HNB 20.

[0032] An unauthorized mobile station 10-2 of this type is assumed to be easily configurable by changing the software such that only the Reason for Setting is falsified.

[0033] Alternatively, there are cases in which a device that decodes an RRC message is inserted: an RRC CONNECTION REQUEST that has not been countermeasured for masking or tampering and which is transmitted on a common channel (RACH: Random Access Channel) from an authorized mobile station 10 -1, which replaces the Emergency Call Establishment parameter, encodes the RRC message: CONNECTION RRC REQUEST and sends to HNB 20. In such cases, even an authorized mobile station 10-1 can be considered equivalent to the above unauthorized mobile station 10-2.

[0034] An unauthorized mobile station 10-2 of these types causes the following problems:

[0035] (1) HNB 20, which is installed for use in a residential building or office use, is used in an unlawful manner by an unauthorized mobile station 10-2,

(2) an unauthorized mobile station 10-2, by initiating a call through the HNB 20, is able to illegally receive a paid service, which is less expensive than a normal paid service,

(3) an unauthorized mobile station 10-2 illegally receives a content service that is intended for specific users.

One method that has been considered to solve these problems involves the implementation of the call initiation process of the mobile station 10 on the device side of the core network when this mobile station 10 initiates a call as an emergency call. To this end, the core network device should recognize that the mobile station 10 has initiated a call as an emergency call.

[0036] However, the core network device in its current configuration is not able to detect that the mobile station 10 has initiated a call as an emergency call.

[0037] Alternatively, the implementation on the HNB-GW 30 of the call disconnection process of the mobile station 10 that falsely initiated the call as an emergency call can also be considered. To this end, the HNB-GW 30 must determine whether the type of call that was initiated by the mobile station 10 is actually an emergency call.

[00387] However, the HNB-GW 30 in its current configuration is not able to detect the type of call that is actually initiated by the mobile station 10.

[0039] Therefore, an object of the present invention is to provide a mobile communication system, a base station, a gateway device, a core network device and a communication method by which the core network device can recognize that the mobile station has initiated a call as an emergency call.

[0040] Another objective of the present invention is to provide a mobile communication system, a gateway device, a core network device and a communication method by which the gateway device can recognize the type of call that was actually initiated by the mobile station.

MEANS FOR SOLVING THE PROBLEM

[0041] The first mobile communication system of the present invention is a mobile communication system that comprises a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and a core network device that is located in a core network, the base station comprising:

a control unit that includes in the message information indicating that the mobile station has initiated the call as an emergency call, and a transmission unit that transmits the message to the core network device; and

The core network device contains:

a receiving unit that receives a message that has been transmitted from the base station.

[0042] The second mobile communication system of the present invention is a mobile communication system that comprises a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and a core network device that is located in core network, moreover:

The gateway device contains:

a control unit that includes in the message information indicating that the mobile station has initiated the call as an emergency call, and a transmission unit that transmits the message to the core network device; and

The core network device contains:

a receiving unit that receives a message that has been transmitted from the gateway device.

[0043] A third mobile communication system of the present invention is a mobile communication system that comprises a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and a core network device that is located in core network, moreover:

The core network device contains:

a control unit that includes in the message information indicating that the type of call for the call initiated by the mobile station is an emergency call; and

a transmission unit that transmits said message to the gateway device; and

The gateway device contains:

a receiving unit that receives said message that has been transmitted from the core network device.

[0044] A base station of the present invention is a base station that is connected by a gateway device to a core network device that is located in the core network and comprises:

a control unit that includes in the message information indicating that the mobile station has initiated a call as an emergency call; and

a transmission unit that transmits a message to a core network device.

[0045] A first gateway device of the present invention is a gateway device that connects a base station to a core network device that is located in a core network and comprises:

a control unit that includes in the message information indicating that the mobile station has initiated a call as an emergency call; and

a transmission unit that transmits a message to a core network device.

[0046] The second gateway device of the present invention is a gateway device that connects the base station to a core network device that is located in the core network and comprises:

a receiving unit that receives a message that is transmitted from the core network device and contains information that indicates that the type of call for the call initiated by the mobile station is an emergency call.

[0047] The first core network device of the present invention is a core network device that is located in the core network and contains a receiving unit that receives a message that is transmitted from the base station and which contains information that indicates that the mobile station has initiated a call as an emergency call.

[0048] The second core network device of the present invention is a core network device that is located in the core network and contains a receiving unit that receives a message that is transmitted from the gateway device and which contains information that indicates that the mobile station has initiated a call as an emergency call .

[0049] A third core network device of the present invention is a core network device that is located in a core network and comprises:

a control unit that includes in the message information that indicates that the type of call for the call initiated by the mobile station is an emergency call; and

a transmission unit that transmits a message to the gateway device.

[0050] A first communication method of the present invention is a communication method implemented by a mobile communication system that includes a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and the core network device, which is located in the core network, the communication method comprising the steps of:

the base station includes in the message information indicating that the mobile station has initiated a call as an emergency call;

the base station transmits a message to the core network device; and

the core network device receives a message that has been transmitted from the base station.

[0051] A second communication method of the present invention is a communication method implemented by a mobile communication system that comprises a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and the core network device, which is located in the core network, the communication method comprising the steps of:

the gateway device includes in the message information indicating that the mobile station has initiated a call as an emergency call;

the gateway device transmits a message to the core network device; and

the core network device receives a message that has been transmitted from the gateway device.

[0052] A third communication method of the present invention is a communication method implemented by a mobile communication system that comprises a mobile station, a base station that performs wireless communication with a mobile station, a gateway device that connects the base station to the core network, and the core network device, which is located in the core network, the communication method comprising the steps of:

the core network device includes in the message information indicating that the type of call for the call initiated by the mobile station is an emergency call;

the core network device transmits a message to the gateway device; and

the gateway device receives a message that has been transmitted from the core network device.

[0053] A fourth communication method of the present invention is a communication method implemented by a base station that is connected through a gateway device to a core network device that is located in a core network, the communication method comprising the following steps:

including in the message information indicating that the mobile station has initiated a call as an emergency call; and

sending a message to the core network device.

[0054] A fifth communication method of the present invention is a communication method implemented by a gateway device that connects a base station to a core network device that is located in a core network, the communication method comprising the following steps:

the inclusion in the message of information that indicates that the mobile station has initiated a call as an emergency call; and

sending a message to the core network device.

[0055] A sixth communication method of the present invention is a communication method implemented by a gateway device that connects a base station to a core network device that is located in a core network, the communication method comprising the following steps:

receiving a message that is transmitted from a core network device and which contains information that indicates that the type of call for the call initiated by the mobile station is an emergency call.

[0056] A seventh communication method of the present invention is a communication method implemented by a core network device that is located in a core network, the communication method comprising the step of receiving a message that is transmitted from the base station and which contains information indicating that the mobile station has initiated a call as emergency call.

[0057] An eighth communication method of the present invention is a communication method implemented by a core network device that is located in a core network, the communication method comprising the step of receiving a message that is transmitted from the gateway device and which contains information indicating that the mobile station has initiated a call as emergency call.

[0058] The ninth communication method of the present invention is a communication method implemented by a core network device that is located in a core network, the communication method comprising the following steps:

including in the message information indicating that the type of call for the call initiated by the mobile station is an emergency call, and

sending a message to the gateway device.

RESULT PROVIDED BY THE INVENTION

[0059] According to the first or second mobile communication system of the present invention, the base station or the gateway device includes information in the message that indicates that the mobile station has initiated the call as an emergency call and transmits the message to the core network device.

[0060] Accordingly, a result is provided that the core network device can recognize that the mobile station has initiated a call as an emergency call.

[0061] According to the third mobile communication system of the present invention, the core network device includes in the message information indicating that the type of call for the call initiated by the mobile station is an emergency call, and transmits the message to the gateway device.

[0062] Accordingly, a result is provided that the gateway device can recognize that the type of call for the call actually initiated by the mobile station is an emergency call.

BRIEF DESCRIPTION OF THE DRAWINGS

[0063] FIG. 1 shows a configuration of a 3rd generation mobile communication system.

[00647] Figure 2 shows the configuration of the RRC CONNECTION REQUEST message.

[0065] FIG. 3 shows the configuration of the START DIRECTION message.

[0066] FIG. 4 shows a configuration of a Setup Reason parameter.

[0067] FIG. 5 shows a configuration of a UE REGISTRATION REQUEST message.

[0068] FIG. 6 shows a configuration of a Registration Cause parameter.

[0069] FIG. 7 is a block diagram showing an HNB configuration of a first exemplary embodiment of the present invention.

[0070] FIG. 8 is a block diagram showing an HNB-GW configuration of a first exemplary embodiment of the present invention.

[0071] FIG. 9 is a block diagram showing an MSC configuration of a first exemplary embodiment of the present invention.

[0072] FIG. 10 is a block diagram showing an SGSN configuration of a first exemplary embodiment of the present invention.

[0073] FIG. 11 is a block diagram showing an HNB configuration of a second exemplary embodiment of the present invention.

[0074] FIG. 12 is a block diagram showing an HNB-GW configuration of a second exemplary embodiment of the present invention.

[0075] FIG. 13 is a block diagram showing an MSC configuration of a second exemplary embodiment of the present invention.

[0076] FIG. 14 is a block diagram showing an SGSN configuration of a second exemplary embodiment of the present invention.

[0077] FIG. 15 is a sequence diagram for describing an operation of a mobile communication system of a second exemplary embodiment of the present invention.

[0078] Fig. 16 shows a configuration of a CM REQUEST message.

[0079] FIG. 17 shows a configuration of a CM Service Type parameter.

[0080] FIG. 18 is a flowchart showing a process for determining a Registration Cause by an HNB.

[0081] FIG. 19 shows an START MESSAGE configuration of a UE to which an Emergency Cause parameter has been added according to the present invention.

[0082] FIG. 20 is a flowchart showing a process for countering unauthorized access implemented by an MSC of a second exemplary embodiment of the present invention.

[0083] FIG. 21 is a flowchart showing a process for countering unauthorized access implemented by an SGSN of a second exemplary embodiment of the present invention.

[0084] FIG. 22 is a block diagram showing an MSC configuration of a third exemplary embodiment of the present invention.

[0085] FIG. 23 is a block diagram showing an SGSN configuration of a third exemplary embodiment of the present invention.

[0086] FIG. 24 is a block diagram showing an HNB-GW configuration of a third exemplary embodiment of the present invention.

[0087] FIG. 25 is a block diagram showing an MSC configuration of a fourth exemplary embodiment of the present invention.

[0088] FIG. 26 is a block diagram showing an SGSN configuration of a fourth exemplary embodiment of the present invention.

[0089] FIG. 27 is a block diagram showing an HNB-GW configuration of a fourth exemplary embodiment of the present invention.

[0090] FIG. 28 is a sequence diagram for describing an example of operation 1 of a mobile communication system of a fourth exemplary embodiment of the present invention.

[0091] FIG. 29 is a flowchart for describing a process for determining a Call Type parameter by an MSC of a fourth exemplary embodiment of the present invention.

[0092] FIG. 30 shows a configuration of a GENERAL ID message according to the present invention.

[0093] FIG. 31 shows a table for determining according to a type of a processing call in the HNB-GW of a fourth exemplary embodiment of the present invention.

[0094] FIG. 32 is a flowchart showing a process for determining a Call Type parameter by an SGSN of a fourth exemplary embodiment of the present invention.

[0095] FIG. 33 is a sequence diagram for describing an example of operation 2 of a mobile communication system of a fourth exemplary embodiment of the present invention.

[0096] FIG. 34 shows a configuration of a DIRECT TRANSMISSION message according to the present invention.

[0097] FIG. 35 is a sequence diagram for describing an example of operation 3 of a mobile communication system of a fourth exemplary embodiment of the present invention.

[0098] FIG. 36 shows a configuration of a RAB APPOINTMENT REQUEST message according to the present invention.

The best modes of carrying out the invention

[0099] The best implementation modes of the present invention are described below with reference to the illustrative drawings.

[0100] In the exemplary embodiments described below, the overall configuration of the mobile communication system is equivalent to the configuration of the mobile communication system of FIG. 1

[0101] FIRST EXAMPLE EMBODIMENT

7-10 show the configurations of HNB 20, HNB-GW 30, MSC 40 and SGSN 50, respectively.

[0102] According to FIG. 7, the HNB 20 of the present exemplary embodiment comprises a control unit 21A that includes information indicating that the mobile station 10 has initiated a call as an emergency call in a RANAP protocol message (Radio Access Network Application Part), and a transmission unit 22A which transmits the RANAP protocol message to the HNB-GW 30. Further, the RANAP protocol messages are application level messages of the wireless access network and, for example, have functions for transparently transmitting CC / MM signals that are transmitted and received between the UE and the device The core network within the RAN.

[0103] Referring to FIG. 8, the HNB-GW 30 of the present exemplary embodiment comprises a reception unit 31A that receives a RANAP protocol message from HNB 20, a control unit 32A that retrieves a RANAP protocol message, and a transmission unit 33 that transmits a RANAP protocol message to MSC 40 or SGSN 50.

[0104] According to FIG. 9, the MSC 40 of the present exemplary embodiment comprises a receiving unit 41A that receives a RANAP protocol message from the HNB-GW 30; and a control unit 42A which, when the RANAP protocol message contains information indicating that the mobile station 10 has initiated the call as an emergency call, distinguishes whether the type of call for the call that was initiated by the mobile station 10 is truly an emergency call and performs the disconnection process call if the call is not an emergency call.

[0105] Furthermore, according to FIG. 10, the SGSN 50 of the present exemplary embodiment comprises a receiving unit 51A that receives a RANAP protocol message from the HNB-GW 30; and a control unit 52A, which, when the RANAP protocol message contains information indicating that the mobile station 10 initiated the call as an emergency call, distinguishes whether the type of call for the call initiated by the mobile station 10 is truly an emergency call and performs the call disconnection process, when the call is not an emergency call.

[0106] Accordingly, the MSC 40 or SGSN 50 in the present exemplary embodiment can recognize that the mobile station 10 has initiated a call as an emergency call.

[0107] As a result, when the mobile station 10 falsely changed the Reason for Establishing an emergency call, the MSC 40 or SGSN 50 can carry out the process of disconnecting the call to the mobile station 10 and thus prevent the unauthorized reception of the service provided by the HNB 20.

[0108] SECOND EXAMPLE EMBODIMENT

11-14 show configurations of HNB 20, HNB-GW 30, MSC 40, and SGSN 50, respectively, of the present exemplary embodiment. The present exemplary embodiment is an example in which the configurations and operations of the HNB 20, HNB-GW 30, MSC 40 and SGSN 50 of the first exemplary embodiment of FIG. 7 and FIG. 10 are made more specific.

[0109] Referring to FIG. 11, the HNB 20 of the present exemplary embodiment comprises a mobile station signal transceiver 201A, an RUA message processor 202A (User RANAP Adaptation), an HNB-GW signal transceiver 203A, an HNBAP message processor 204A, a call control unit 205A, a processor 206A RRC messages and RANAP message processor 207A.

[0110] In FIG. 11, the control unit 21A shown in FIG. 7 is constituted by an RUA message processor 202A, an HNBAP message processor 204A, a call control unit 205A, an RRC message processor 206A, and an RANAP message processor 207A. In addition, the HNB-GW signal transceiver 203A is one example of the transmission unit 22A shown in FIG. 7.

[0111] As functions of transmitting and receiving RRC protocol messages to and from the mobile station 10, the mobile station signal transceiver 201A includes, for example, a masking function that masks (encrypts and decrypts) the messages, a signal delivery verification function that verifies message delivery, and a signal distribution function that distributes messages.

[0112] As functions for transmitting and receiving HNBAP protocol messages and RUA protocol messages to and from HNB-GW 30, the HNB-GW signal transceiver 203A includes functions such as a masking function, a signal delivery verification function, and a signal distribution function.

[0113] The RRC message processor 206A comprises a function for encoding RRC protocol messages to be transmitted to the mobile station 10, and a function for decoding RRC protocol messages that are received from the mobile station 10.

[0114] The HNBAP message processor 204A has a function for encoding HNBAP protocol messages to be transmitted to the HNB-GW 30, and a function for decoding HNBAP protocol messages that are received from the HNB-GW 30.

[0115] The RANAP message processor 207A has a function for encoding RANAP messages to be transmitted to the HNB-GW 30 and a function for decoding RANAP messages that are received from the HNB-GW 30.

[0116] The RUA protocol is a protocol for performing the action of transmitting RANAP protocol messages, and the RUA message processor 202A has a function for encoding RUA protocol messages to be transmitted to the HNB-GW 30, and a function for decoding RUA protocol messages that are received from the HNB- GW 30.

[0117] Based on the RRC protocol messages and the RANAP protocol messages, the call control unit 205 initiates various call processes, such as establishing RRC connections, establishing carrier channels, and managing mobile communications. The call control unit 205A further initiates the HNBAP protocol and implements the registration process of the mobile station 10 with respect to the HNB-GW 30. The above functions are functions that are typically supported by the call processor that is installed in the HNB 20.

[0118] As special functions of the present exemplary embodiment, the call control unit 205A further comprises a function for setting the Cause of Emergency RANAP Protocol message transmitted to the HNB-GW 30 based on the Cause of Logging HNBAP Protocol message received from the HNB-GW 30 parameter .

[0119] Referring to FIG. 12, the HNB-GW 30 of the present exemplary embodiment comprises an HNB signal transceiver 301A, an RUA message processor 302A, an SGSN signal transceiver 303A, an MSC signal transceiver 304A, an HNBAP message processor 305A, a call control unit 306A, a message processor 307A RANAP and station data storage unit 308A.

[0120] In FIG. 12, in addition, the control unit 32A shown in FIG. 8 is constituted by the RUA message processor 302A, the HNBAP message processor 305A, the call control unit 306A, the RANAP message processor 307A, and the data storage unit 308A. The HNB signal transceiver 301A is one example of the reception unit 31A shown in FIG. 8, and the SGSN signal transceiver 303A and the MSC signal transceiver 304A are examples of the transmission unit 33 shown in FIG.

[0121] The HNB signal transceiver 301A is provided with a masking function and a signal delivery verification function as functions of transmitting and receiving RUA protocol messages and HNBAP protocol messages to and from HNB 20.

[0122] The MSC signal transceiver 304A is provided, for example, with a sequence control function for controlling message sequence and a delivery verification function as functions of transmitting and receiving RANAP protocol messages to and from the MSC 40.

[0123] The SGSN signal transceiver 303A is provided, for example, with a delivery verification function and a sequence control function as functions of transmitting and receiving RANAP protocol messages to and from SGSN 50.

[0124] The HNBAP message processor 305A is provided with a function for encoding HNBAP protocol messages to be transmitted to the HNB 20, and a function for decoding HNBAP protocol messages that are received from the HNB.

[0125] An RUA message processor 302A is provided with a function for encoding RUA protocol messages to be transmitted to the HNB 20, and a function for decoding RUA protocol messages that are received from the HNB 20.

[0126] The RANAP message processor 307A is provided with a function for encoding the RANAP protocol messages to be transmitted to the MSC 40, and a function for decoding the RANAP protocol messages that are received from the MSC 40.

[0127] The call control unit 306A performs the HNB registration process 103 and the registration process of the mobile station 10. In addition, the call control unit 306A can access station data stored in the station data storage unit 308A. An IMSI list that can be accessed is set for each SG in the station data. Based on this IMSI list, the HNB-GW 30 implements access control to the HNB 20. The above functions are functions that are typically supported by a call processor that is installed in the HNB-GW 30.

[0128] Referring to FIG. 13, the MSC 40 of the present exemplary embodiment comprises an HNB-GW signal transceiver 401A, RANAP message processor 402A, NAS message processor (Lack of access level), call control unit 404A, and station data storage unit 405A.

[0129] In FIG. 13, the control unit 42A shown in FIG. 9 is constituted by a RANAP message processor 402, a NAS message processor 403A, a call control unit 404A, and a data storage unit 405A. The HNB-GW signal transceiver 401A is one example of the reception unit 41A shown in FIG. 9.

[0130] The HNB-GW signal transceiver 401A is provided, for example, with a delivery check function and a sequence control function as functions for transmitting and receiving RANAP messages to and from the HNB-GW 30.

[0131] The RANAP message processor 402A is provided with a function for encoding RANAP messages to be transmitted to the HNB-GW 30 and a function for decoding the RANAP protocol that are received from the HNB-GW 30.

[0132] The NAS message processor 403A has a function for transmitting and receiving NAS protocol messages (CC (Call Control) and MM (Mobility Management) protocol) to and from the mobile station 10.

[0133] The call control unit 404A has call processing functions for performing call processing, such as making a call and disconnecting a call, mobility management functions for performing mobility management, such as position registration and handover, and furthermore, access control functions for adjusting access to the HNB 20. The call control unit 404A may access the station data stored in the station data storage unit 405A. The IMSI list that can be accessed for each CSG is set in the station data. Based on this IMSI list, the MSC 40 implements access control to the HNB 20. The above functions are functions commonly supported by the call processing processor that is installed in the MSC 40.

[0134] Furthermore, as a special function of the present exemplary embodiment, the call control unit 404A is provided with a function for analyzing NAS messages to distinguish whether the type of call for the call that is initiated by the mobile station 10 is an emergency call when the Emergency Cause parameter is set in a RANAP protocol message that is received from the HNB-GW 30. If the call type is not an emergency call, the call control unit 404A performs a call disconnect process.

[0135] Referring to FIG. 14, the SGSN 50 of the present exemplary embodiment is provided with an HNB-GW signal transceiver 501A, RANAP message processor 502A, NAS message processor 503A, call control unit 504A and station data storage unit 505A.

[0136] In Fig. 14, the control unit 52A shown in Fig. 10 is constituted by a RANAP message processor 502A, a NAS message processor 503A, a call control unit 504A, and a station data storage unit 505A. The HNB-GW signal transceiver 501A is one example of the reception unit 51A shown in FIG. 10.

[0137] The HNB-GW signal transceiver 501A is provided, for example, with a delivery verification function and a sequence control function as functions for transmitting and receiving RANAP messages to and from the HNB-GW 30.

[0138] The RANAP message processor 502A is provided with a function for encoding RANAP messages to be transmitted to the HNB-GW 30, and a function for decoding RANAP messages that are received from the HNB-GW 30.

[0139] The NAS message processor 503A is provided with a function for transmitting and receiving NAS protocol messages (CC protocol and MM protocol) to and from mobile station 10.

[0140] The call control unit 504A has call processing functions, mobility management functions, and further access control functions. Call control unit 504A may access station data that is stored in station data storage unit 505A. An IMSI list that can be accessed is set for each CSG in the station data. Based on this IMSI list, the SGSN 50 implements access control to the HNB 20. The functions described above are functions that are typically supported by a call processor that is installed in the SGSN 50.

[0141] In addition to the above, as a special function of the present exemplary embodiment, the call control unit 504A is further provided with a NAS message analysis function to distinguish whether the type of call for the call initiated by the mobile station 10 is an emergency call when the Emergency Cause parameter is set to a RANAP protocol message that is received from the HNB-GW 30. If the call type is not an emergency call, the call control unit 504A performs a call disconnect process.

[0142] The operation of the mobile communication system of the present exemplary embodiments is described below.

[0143] (A) Cases of circuit-switched calls

An example of operations when the mobile station 10 initiated the call as an emergency circuit-switched call is first described using the flowchart of FIG. 15.

[0144] Referring to Fig. 15, the mobile station 10 sets the Reason for Establishment (Fig. 4) in the RRC message: CONNECTION RRC REQUEST (Fig. 2) in step S101 and in step S102 transmits the RRC: CONNECTION RRC REQUEST message to the HNB 20.

[0145] After providing the wireless resource, the HNB 20 notifies the mobile station 10 of the wireless resource in an RRC: SET RRC CONNECTION message in step S103.

[0146] The mobile station 10, having established the RRC connection, notifies the HNB 20 of the establishment in the RRC message: SET RRC MESSAGE COMPLETED in step S104.

[0147] In step S105, the mobile station 10 further sets the CM Service Type parameter (FIG. 17) of the CM SERVICE REQUEST message (FIG. 16), which is an MM protocol message, to “Establish an emergency call” and includes this CM SERVICE REQUEST message in RRC message: INITIAL DIRECT TRANSMISSION (FIG. 3).

[0148] In step S106, the mobile station 10 further sets the Reason for Establishment (FIG. 4) in this RRC: INITIAL DIRECT message to the “Emergency Call” and transmits this RRC message: INITIAL DIRECT (Fig.3) to the HNB 20.

[0149] In HNB 20, the RRC protocol message processor 707A decodes the RRC message: CONNECTION RRC REQUEST, which was transmitted in step S102, and the RRC: START-UP DIRECT message that was transmitted in step S106.

[0150] In HNB 20, the call control unit 205A stores the Establishment Reason value (FIG. 4), which was reported in the RRC message: CONNECTION RRC REQUEST and the RRC message: START DIRECTION from the mobile station 10 and then, in step S107, determines the parameter The Reason for Registration is based on the value of the Reason for Establishment and sets the parameter to the HNBAP message: REQUEST FOR REGISTRATION UE (Fig. 5).

[0151] FIG. 18 shows a flowchart of a process for determining a Registration Cause parameter.

[0152] Referring to FIG. 18, the call control unit 205A determines in step S201 whether the Establishment Reason value is “Emergency Call”, and if the Establishment Reason value is “Emergency Call”, it determines the Registration Reason parameter as “Emergency Call” in step S202, and if the Establishment Reason value is not an “Emergency call”, it determines the Registration Reason parameter as “Normal call” in step S203.

[0153] According to FIG. 15, the HNB 20 transmits an HNBAP: REGISTRATION REQUEST UE message (FIG. 5) in which the Registration Reason parameter is set to the HNB-GW 30 in step S108.

[0154] In the HNB-GW 30, the HNB signal transceiver 301A receives the HNBAP message: REGISTRATION REQUEST UE, the HNBAP message processor 305A decodes the HNBAP message: REGISTRATION REQUEST UE, and in step S109, the call control block 306A decides whether to implement access control (step step S110) based on the Registration Reason parameter that is set in the HNBAP message: UE REGISTRATION REQUEST.

[0155] In the HNB-GW 30, if the Registration Cause parameter corresponds to "Emergency Call", then access control is not performed. In this case, the call control unit 306A assigns the context ID of the relevant mobile station 10, the HNBAP message processor 305A encodes the HNBAP: ACCEPT UE REGISTRATION message, and in step S111, the HNB signal transceiver 301A transmits the HNBAP: ACCEPT UE REGISTRATION message to the HNB 20.

[0156] In HNB 20, after receiving the HNBAP message: ACCEPT UE REGISTRATION, the call control unit 205A determines that the Registration Cause parameter is an "Emergency Call" in step S112, and if the Registration Cause parameter is an "Emergency Call", then the control unit 205A by calling, the Cause of Emergency parameter (FIG. 19) is generated, which is entered according to the present invention in step S113. The RANAP message processor 207A encodes the RANAP: INITIAL MESSAGE message of the UE, which contains the Emergency Cause parameter. The RANAP message processor 207A additionally sets the NAS-PDU (Protocol Data Unit) parameter in the RANAP: START MESSAGE message of the UE and sets the MM Service Request SMS message received from the mobile station 10 to the NAS-PDU parameter. An RUA message processor 703A generates an RUA: CONNECTION message that contains a RANAP: INITIAL MESSAGE message of the UE. In other words, the RANAP: INITIAL MESSAGE message of the UE is transmitted from the HNB 20 to the HNB-GW 30 through the RUA: CONNECTION message in step S114.

[0157] In the HNB-GW 30, the RUA message processor 302A decodes the RUA protocol CONNECTION message, the call control unit 306A retrieves the RANAP: START MESSAGE message of the UE that has already been encoded in the HNB 20, and in step S115, the RANAP message processor 307A transmits the RANAP message : INITIAL UE MESSAGE to MSC 40 based on routing information such as domain CN ID.

[0158] In the MSC 40, the RANAP message processor 402A decodes the RANAP: INITIAL MESSAGE message of the UE, and then the NAS message processor 403A decodes the CM SERVICE REQUEST message that is set in the NAS-PDU. The result of this decoding is reported to the call control unit 404A. The call control unit 404A determines whether the Cause of Emergency parameter, which is inputted according to the present invention, is set in step S116, and if the Cause of Emergency parameter is set, activates the process of countering unauthorized access for the CS (Switching Channels) service in step S117.

[0159] FIG. 20 shows a flowchart of a process for countering unauthorized access for a CS service.

[0160] Referring to FIG. 20, the call control unit 404A checks whether the CM Service Type parameter (TS24.008 Ver 8.5.0 section 10.5.3.3) that is set in the CM SERVICE REQUEST message (TS24.008 Ver 8.5.0, Section 9.2.9) of the MM protocol, which was transmitted from the mobile station 10, “Establishing an Emergency Call”, in step S301.

[0161] The call control unit 404A then checks whether the telephone number (TS24.008 Ver 8.5.0, Section 10.5.4.7) of the INSTALL message (TS24.008 Ver 8.5.0, Section 9.3.23 Installation) of the CC protocol, which is the call initiation signal transmitted by the MSC 40, the emergency call number, in step S302. More specifically, digit 1 numbers, digit 2 numbers, digit 3 numbers, etc. 10.5.91 of the called party BCD information element TS24.008 Ver 8.5.0 / 3GPP TS24.008 is relevant to the phone number, and the call control unit 404A checks whether this phone number is an emergency number. The called party BCD number of Section 10.5.4.7 of TS24.008 refers to the connection number, and the BCD (binary coded decimal number) indicates that one digit in decimal is expressed as a 4-bit binary number, which expresses from 0 to 9 and is one method expressions of numbers in computers.

[0162] In step S303, the call control unit 404A then checks whether the EMERGENCY INSTALL procedure (TS24.008 Ver 8.5.0, Section 9.3.8) is performed in the mobile station 10. For example, after receiving a message from the mobile station 10 to initiate the "establishment emergency call ", the call control unit 404A checks, based on the information element" type of emergency setting message ", whether the emergency setup procedure is being performed. If any of the checks in steps S301-S303 are satisfied, the call control unit 404A determines that the type of call is an emergency call and continues to process the call for the emergency call. On the other hand, if any of the checks is not satisfied, the call control unit 404A determines that the type of call is a normal call, considers the mobile station 10 as an unauthorized mobile station 10-2, and initiates the call disconnection process in step S304.

[0164] Thus, it is possible to prevent an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20 and which has changed the Cause of the Establishment to misrepresent its emergency call, to receive the service implemented by the HNB 20.

[0165] (B) Case of a packet switched call

An example of operations when the mobile station 10 initiates a call as an emergency packet-switched call is described below.

[0166] The sequence of operations in the case of a packet switched call is similar to the operation for a circuit switched call, except that the process that was performed by the MSC 40 in the case of a circuit switched call is performed by the SGSN 50. However, in the case of a packet switched call the SM protocol message (Session Management) and the GMM protocol message (GPRS Mobility Management) are used as the NAS message. As a result, the process of counteracting unauthorized access that was initiated in step S117 is counteracting unauthorized access for the PS (Packet Switching) service. The emergency call identification method in this process is different from the corresponding method in the CS service. In addition, when it is used in packet switching, the VoIP (Voice over IP) method is used. GMM is a protocol for mobility management in a packet service (PS).

[0167] FIG. 21 shows a flowchart of a process for countering unauthorized access for a PS service.

[0168] Referring to FIG. 21, the SGSN 50 call control unit 504A checks in step S401 whether the APN (Access Point Name) (3GPP TS24.008 Ver 9.5.1, Section 10.5.6.1) set in the PDP Activation Context Request message (Packet Data Protocol) (3GPP TS24.008 Ver 8.5.0, Section 9.5.1) of the SM protocol, which was transmitted from the mobile station 10, characteristic of an emergency call.

[0169] Then, the call control unit 504A checks in step S402 whether the GMM procedure that is performed in the mobile station 10 is an Emergency Joining procedure (TR23.869 Ver 9.0.0).

[0170] The call control unit 504A then checks in step S403 whether the PDP context that is activated in the SGSN 50 is a PDP context for an emergency call. For example, the call control unit 504A checks whether the PDP context activated in the SGSN 50 is a PDP emergency context for TR23.869 Ver 9.0.0.

[0171] If any of the steps S401-S403 is satisfied, then the call control unit 504A determines that the type of call is an emergency call and continues to process the call for the emergency call. On the other hand, if any of the checks is not satisfied, the call control unit 504A determines that the call type is a normal call, considers the mobile station 10 as an unauthorized mobile station 10-2, and activates the call disconnection process in step S504.

[0172] Thus, it is possible to prevent an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20, change the Cause of the Establishment for a false representation of the emergency call and get the service implemented by the HNB 20, even in the case of packet-switched VoIP .

[0173] THIRD EXAMPLE EMBODIMENT

22-24 show configurations of MSC 40, SGSN 50, and HNB-GW 30, respectively, for the present exemplary embodiment.

[0174] Referring to FIG. 22, the MSC 40 of the present exemplary embodiment comprises a control unit 41B that determines whether a call type for a call that is actually initiated by the mobile station 10 is an emergency call and includes information that indicates whether the call type is an emergency a call to the RANAP protocol message, and a transmission unit 42B that transmits the RANAP protocol message to the HNB-GW 30.

[0175] According to FIG. 23, the SGSN 50 of the present exemplary embodiment includes a control unit 51B that determines whether the type of call for the call that is actually initiated by the mobile station 10 is an emergency call and includes information indicating that the type of call is emergency a call to the RANAP protocol message, and a transmission unit 52B that transmits the RANAP protocol message to the HNB-GW 30.

[0176] Furthermore, according to FIG. 24, the HNB-GW 30 of the present exemplary embodiment comprises a receiving unit 31B that receives a RANAP protocol message from the MSC 40 or SGSN 50, and when information indicating that the type of call is an emergency call is contained in a RANAP protocol message, implements a call disconnect process.

[0177] Accordingly, in the present exemplary embodiment, the HNB-GW 30 may recognize that the type of call for the call actually initiated by the mobile station 10 is an emergency call.

[0178] As a result, when the mobile station 10 changes the Reason for Establishment to falsely present an emergency call, the HNB-GW 30 may implement the call disconnect process of the mobile station 10 and thereby prevent the mobile station 10 from improperly receiving the service implemented by the HNB 20.

[0179] FOURTH EXAMPLE EMBODIMENT

25-27 show configurations of MSC 40, SGSN 50, and HNB-GW 30, respectively, of the present exemplary embodiment. The present exemplary embodiment is an example in which the configurations and operations of the MSC 40, SGSN 50, and HNB-GW 30 of the third exemplary embodiment of FIGS. 22-24 are described with more specificity.

[0180] Referring to FIG. 25, the MSC 40 of the present exemplary embodiment comprises an HNB-GW signal transceiver 401B, a RANAP message processor 402B, a NAS message processor 403B, a call control unit 404B and a station data storage unit 405B.

[0181] In FIG. 25, the control unit 41B shown in FIG. 22 is constituted by a RANAP message processor 402B, a NAS message processor 403B, a call control unit 404B, and a station data storage unit 405B. In addition, the HNB-GW signal transceiver 401B is one example of a transmission unit 42B shown in FIG.

[0182] HNB-GW signal transceiver 401B, RANAP message processor 402B, NAS message processor 403B and station data storage unit 405B each have the same functions as the HNB-GW signal transceiver 401A, RANAP message processor 402A, processor 403A NAS messages and station data storage unit 405A, respectively, which are shown in FIG.

[0183] Like the call control unit 404A shown in FIG. 13, the call control unit 404B has functions typically performed by a call processing processor that is installed in the MSC 40.

[0184] In addition to the previous description, the call control unit 404B also has, as a special function of the present exemplary embodiment, a NAS message analysis function to determine whether the type of call initiated by the mobile station 10 is an emergency call, and based on the result determining, setting the RANAP Protocol Call Type parameter, which are transmitted to the HNB-GW 30.

[0185] Furthermore, according to FIG. 26, the SGSN 50 of the present exemplary embodiment includes an HNB-GW signal transceiver 501B, a RANAP message processor 502B, a NAS message processor 503B, a call control unit 504B and a station data storage unit 505B.

[0186] In FIG. 26, the control unit 51B shown in FIG. 23 is constituted by a RANAP message processor 502B, a NAS message processor 503B, a call control unit 504B, and a station data storage unit 505B. In addition, the HNB-GW signal transceiver 501B is one example of the transmission unit 52B shown in FIG.

[0187] HNB-GW signal transceiver 501B, RANAP message processor 502B, NAS message processor 503B, and station data storage unit 505B each have the same functions as the HNB-GW signal transceiver 501A, RANAP message processor 502A, processor 503A of the NAS message and station data storage unit 505A, respectively, shown in FIG.

[0188] Like the call control unit 504A shown in FIG. 14, the call control unit 504B has functions typically performed by a call processing processor that is installed in the SGSN 50.

[0189] In addition to the previous description, the call control unit 504B has, as special functions of the present exemplary embodiment, functions for analyzing the NAS message to determine whether the type of call for the call initiated by the mobile station 10 is an emergency call, and based on the determination result, setting the RANAP Protocol Call Type parameter, which is transmitted to the HNB-GW 30.

[0190] Referring to FIG. 27, the HNB-GW 30 of the present exemplary embodiment comprises an HNB signal transceiver 301B, an RUA message processor 302B, an SGSN signal transceiver 303B, an MSC signal transceiver 304B, an HNBAP message processor 305B, a call control unit 306B, a message processor 307B RANAP and station storage unit 308B.

[0191] In FIG. 27, the control unit 32B shown in FIG. 24 is constituted by the RUA message processor 302B, the HNBAP message processor 305B, the call control unit 306B, the RANAP message processor 307B, and the station data storage unit 308B. In addition, the SGSN transceiver 303B and the MSC signal transceiver 304B are examples of the reception unit 31B shown in FIG. 24.

[0192] Each of the HNB signal transceiver 301B, the RUA message processor 302B, the SGSN signal transceiver 303B, the MSC signal transceiver 304B, the HNBAP message processor 305B, the RANAP message processor 307B, and the data storage unit 308B have the same functions as the transceiver 301A HNB signal, RUA message processor 302A, SGSN signal transceiver 303A, MSC signal transceiver 304A, HNBAP message processor 305A, RANAP message processor 307A, and station data storage unit 308B, respectively, shown in FIG. 12.

[0193] The call control unit 306B has functions that are generally supported by the call processing processor installed in the HNB-GW 30, similar to the call control unit 306A shown in FIG. 12.

[0194] In addition to the above description, the call control unit 306B further has, as special functions of the present exemplary embodiment, functions for determining that the type of call for the call initiated by the mobile station 10 is a normal call when the “Normal Call” is set to The RANAP Protocol Call Type received from the MSC 40 or SGSN 50, and whether the mobile station 10 initiated the call as an emergency call at this time to complete the call disconnection process.

[0195] The configuration of the HNB 20 of the present exemplary embodiment may be the same as in FIG. 9. However, the call control unit 205A in the HNB 20 may have functions typically performed by a call processing processor that is installed in the HNB 20.

[0196] The operation of the mobile communication system of the present exemplary embodiment is described below.

[0197] (1) Example 1

This operation example is an example in which the result of determining the type of call that was defined in the MSC 40 or SGSN 50 is reported in the RANAP GENERAL ID (3GPP TS25.413) message.

[0198] (1-A) circuit switched call case

An operation example for the case where the MSC 40 reports the result of determining the type of call for a circuit switched call in the RANAP GENERAL ID message is first described using the flowchart in FIG. 28. FIG. 28 shows the operations that follow the completion of the processes shown in FIG. 15, but it is assumed that the processes of steps S112, S113, S116 and S117 shown in FIG. 15 are not executed, and further that the Cause of Emergency parameter is not contained. in the RANAP message: INITIAL MESSAGE of the UE, which is transmitted in steps S114 and S115.

[0199] Typically, as described in 3GPP TS25.413, after the signaling connection is established, the core network device transmits a RANAP: GENERAL ID message to the HNB-GW 30.

[0200] Referring to FIG. 28, in the MSC 40, after establishing a signaling connection in step S501, the call control unit 404B starts the process of determining the Call Type parameter in step S502.

[0201] FIG. 29 is a flowchart of a process for determining a Call Type parameter in the MSC 40.

[0202] According to FIG. 29, the call control unit 404B checks whether the CM Service Type parameter (TS24.008 Ver 8.5.0, Section 10.5.3.3), which is set in the CM SERVICE REQUEST message (TS24.008 Ver 8.5.0), is checked. , Section 9.2.9) of the MM protocol, which was transmitted from the mobile station 10 in step S601, “Establishing an Emergency Call”.

[0203] In step S602, the call control unit 404B then checks whether the telephone number (TS24.008 Ver 8.5.0, Section 10.5.4.7) of the INSTALL message (TS24.008 9.3.23 Ver 8.5.0, Section Installation) of the CC protocol , which is the trigger signal transmitted by the MSC 40, an emergency number. More specifically, numeral 1 Numbers, numeral 2 Numbers, numeral 3 Numbers in the BCD Calling Party information element TS24.008 Ver 8.5.0 FIG. 10.5.91 / 3GPP TS24.008 correspond to the telephone number, and the call control unit 404B checks whether this phone number is an emergency number. The BCD Number of the Called Party TS24.008, Section 10.5.4.7 refers to the connected number, and the BCD is one method of expressing numbers in computers, in which one position of the decimal expression is represented by a binary number with four positions (digits), which represents from 0 to 9.

[0204] In step S603, the call control unit 404B then checks whether the EMERGENCY INSTALL procedure (TS24.008 Ver 8.5.0, Section 9.3.8) was performed in the mobile station 10. For example, after receiving a message to initiate an “emergency call setup” from the mobile station 10, the call control unit 404B checks whether the EMERGENCY INSTALL procedure is performed from the information element "emergency message type".

[0205] If any of the checks in steps S601-S603 is satisfied, then the call control unit 404B determines that the call type is an emergency call and determines the Call Type parameter as “Normal Call” in step S604. On the other hand, if any of the checks is not satisfied, then the call control unit 404B determines that the call type is a normal call, and determines the Call Type parameter as “Emergency Call” in step S605.

[0206] Referring to FIG. 28, in the MSC 40, if the Call Type parameter has been determined when the call control unit 404B transmits a RANAP message: GENERAL ID to the HNB-GW 30 in step S503, this Call Type parameter is set. The configuration of the RANAP: GENERAL ID message according to the present invention is shown in FIG.

[0207] In HNB-GW 30, when the Call Type parameter is turned on while receiving RANAP messages: GENERAL ID in step S504, the call control unit 306B in step S505 compares the Call Type parameter with the Registration Reason parameter (FIG. 6) of the HNBAP message: REQUEST REGISTRATION UE (FIG. 5) when the mobile station 10 accesses the HNB-GW 30.

[0208] FIG. 31 shows a table for determining processing according to a call type in the HNB-GW 30 of the present exemplary embodiment.

[0209] For example, in case 2 shown in Fig. 31, the Call Type parameter reported from the MSC 40 is a "Normal Call" even though the HNBAP Message Registration Cause: UE REGISTRATION REQUEST parameter is an "Emergency Call". Therefore, the HNB-GW 30 determines that the mobile station 10 falsely presented an emergency call and illegally accesses the HNB 20, while the HNB-GW 30 performs the call disconnection process.

[0210] Thus, it is possible to prevent an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20 and which has changed the Establishment Cause for the false presentation of an emergency call, to receive the service through the HNB 20.

[0211] (1-B) Case of a packet switched call

An example of operations is further described for the case in which the SGSN 50 reports the result of determining the type of packet switched call in the RANAP GENERAL ID.

[0212] The process for the case of a packet-switched call is similar to the case of a circuit-switched call, except that the processes that were executed in the MSC 40 are now executed in the SGSN 50. However, the process of determining the Call Type parameter that is activated in step S502 is different .

[0213] FIG. 32 is a flowchart of a process for determining a Call Type parameter in an SGSN 50.

[0214] Referring to FIG. 32, in step S701, the call control unit 504B checks whether the APN (3GPP TS24.008 9.5.1, Section 10.5.6.1) that is set in the PDP Context Activation request message (3GPP TS24.008 Ver 8.5 .0, Section 9.5.1) of the SM protocol, which was transmitted from the mobile station 10 specific to an emergency call.

[0215] Then, in step S702, the call control unit 504B checks whether the GMM procedure that is performed in the mobile station 10 is an Emergency Joining procedure (TR23.869 Ver 9.0.0).

[0216] In step S703, the call control unit 504B then checks whether the PDP Context that was activated in the SGSN 50 is a PDP Context for using an emergency call. For example, the call control unit 504B checks whether the PDP Context that is activated in the SGSN 50 is the Emergency PDP Context TR23.869 Ver 9.0.0.

[0217] If any of the checks in steps S701-S703 are satisfied, the call control unit 504B determines that the call type is an emergency call, and determines the Call Type parameter as “Normal Call” in step S704. On the other hand, if none of the checks is satisfied, then the call control unit 504B determines that the call type is a normal call and determines the Call Type parameter as “Emergency Call” in step S705.

[0218] In the SGSN 50, if the Call Type parameter is determined when the RANAP: GENERAL ID message is transmitted to the HNB-GW 30, the call control unit 504B sets this Call Type parameter. The structure of the RANAP message: GENERAL ID according to the present invention is the same as in the case of the MSC 40, as shown in FIG.

[0219] In the HNB-GW 30, if the Call Type parameter is enabled while receiving a RANAP: GENERAL ID message, the call control unit 306B compares this Call Type parameter with the Registration Reason parameter (FIG. 6) of the HNBAP message: REGISTRATION REQUEST UE (FIG. 5) during the access of the mobile station 10 to the HNB-GW 30.

[0220] For example, in case 2 shown in FIG. 31, the Call Type parameter reported from the SGSN 50 is a “Normal Call” even though the HNBAP Message Registration Cause parameter: UE REGISTRATION REQUEST is an “Emergency Call” . Based on these circumstances, the HNB-GW 30 determines that the mobile station 10 falsely presented the emergency call and illegally accesses the HNB 20, and therefore implements the call disconnection process.

[0221] Thus, in the case of packet-switched VoIP, for an unauthorized mobile station 10-2, which is supposed to have no access to the HNB 20 and which has changed the Emergency Cause to falsely present an emergency call, it can be prevented from receiving the service via HNB twenty.

[0222] (2) Example 2

This operation example is an example in which the result of determining the type of call that was defined in the MSC 40 or SGSN 50 is reported in the RANAP message (3GPP TS25.413) DIRECT TRANSMISSION.

[0223] (2-A) Circuit-switched call case

An operation example for a case in which the MSC 40 reports the result of determining the type of call for a circuit switched call in the RANAP DIRECT TRANSMISSION message is first described using the sequence diagram of FIG. Fig. 33 shows the operations that follow the completion of the processing shown in Fig. 15, but it is assumed here that the processes of steps S112, S113, S116 and S117 shown in Fig. 15 are not performed, and that the Cause of Emergency parameter is not included in RANAP message: INITIAL UE MESSAGE, which is transmitted in steps S114 and S115.

[0224] Typically, as described in 3GPP TS25.413, when transmitting an NAS message, such as CC protocol or MM protocol, the core network device transmits a RANAP: DIRECT TRANSMISSION message to the HNB-GW 30.

[0225] Referring to FIG. 33, in the MSC 40, after transmitting the NAS message in step S801, the call control unit 404B starts the process of determining the Call Type parameter in step S802. The process of determining the Call Type parameter in the MSC 40 is the same as in Operation Example 1, and is as shown in FIG. 29.

[0226] In the MSC 40, if the Call Type parameter is determined when the RANAP: DIRECT TRANSMISSION message is transmitted to the HNB-GW 30 in step S803, the call control unit 404B sets this Call Type parameter. RANAP: DIRECT TRANSMISSION message configuration according to the present invention is shown in FIG. 34.

[0227] In the HNB-GW 30, if the Call Type parameter is enabled while receiving the RANAP: DIRECT transmission in step S804, the call control unit 306B in step 805 compares this Call Type parameter with the Registration Reason parameter (Fig. 6) of the HNBAP message: REGISTRATION REQUEST UE (FIG. 5) when the mobile station 10 accesses the HNB-GW 30.

[0228] For example, in case 2 shown in Fig. 31, the Call Type parameter that was reported from the MSC 40 is a "Normal Call" even though the HNBAP Message Registration Cause parameter: UE REGISTRATION REQUEST is an "Emergency Call" . Based on these circumstances, the HNB-GW 30 determines that the mobile station 10 falsely presented an emergency call and illegally accesses the HNB 20, and therefore implements the call disconnection process.

[0229] As a result, for the unauthorized mobile station 10-2, which is assumed to be unable to access the HNB 20 and which has changed the Establishment Cause to misrepresent the emergency call, it is possible to prevent the service from being received by the HNB 20.

[0230] (1-B) Case of a packet switched call

An example of operations is described below for the case in which the SGSN 50 reports the result of determining the type of call for a packet switched call by means of a RANAP DIRECT TRANSMISSION message.

[0231] The sequence of operations in the case of a packet switched call is similar to the processes that were performed in the MSC 40 in the case of a circuit switched call, except that the processes are performed in SGSN 50. However, the process of determining the Call Type parameter that is activated in step S802, is different. The process of determining the Call Type parameter in the SGSN 50 is similar to Operation Example 1 and is as shown in FIG. 32.

[0232] In the SGSN 50, if the Call Type parameter is determined when the RANAP: DIRECT TRANSMISSION message is transmitted to the HNB-GW 30, the call control unit 504B sets this Call Type parameter. The configuration of the RANAP: DIRECT TRANSMISSION message according to the present invention is the same as that of the MSC 40, as shown in FIG. 34.

[0233] In the HNB-GW 30, when the Call Type parameter is turned on while receiving a RANAP: DIRECT TRANSMISSION call call block 306B compares this Call Type parameter and the Registration Reason parameter (FIG. 6) of the HNBAP message: UE REGISTRATION REQUEST (FIG. 5) when the mobile station 10 accesses the HNB-GW 30.

[0234] For example, in case 2 shown in FIG. 31, the Call Type parameter that is reported from the SGSN 50 is a “Normal Call” even though the HNBAP Message Registration Cause parameter: UE REGISTRATION REQUEST is an “Emergency Call” . Based on this circumstance, the HNB-GW 30 determines that the mobile station 10 falsely presented an emergency call and illegally accesses the HNB 20, and therefore implements the call disconnection process. Thus, for an unauthorized mobile station 10-2, which is assumed to be unable to access the HNB 20 and which has changed the Establishment Cause to misrepresent an emergency call, it can be prevented from receiving services through the HNB 20 even for circuit switched VoIP.

[0235] (3) Operation Example 3

This operation example is a case in which the result of determining the type of call that is defined in the MSC 40 or SGSN 50 is reported in the RANAP DESTINATION REQUEST message (RANAP carrier channel) (3GPP TS25.413).

[0236] (3-A) Circuit-switched call case

An example of operation for the case in which the MSC 40 reports the result of determining the type of circuit switched call in the RAB RANAP APPLICATION REQUEST message is described along with the sequence diagram in FIG. 35. Fig. 35 shows the operations that follow the completion of the processes shown in Fig. 15, and here it is assumed that the processes of steps S112, S113, S116 and S117 have not been completed, and further that the Cause of Emergency parameter is not included in the RANAP message: INITIAL MESSAGE The UE that is transmitted in steps S114 and S115.

[0237] Typically, as described in 3GPP TS25.413, when the core network device receives a call setup request from mobile station 10 and establishes a wireless access bearer, the core network device transmits a RANAP: RAB APPOINTMENT REQUEST message to the HNB-GW 30.

[0238] Referring to FIG. 35, in the MSC 40, after receiving a call setup request from the mobile station 10 in step S901, the call control unit 404B determines the QoS (Quality of Service) for the wireless access bearer and then activates the Call Type parameter determination process on step S903. The process of determining the Call Type parameter in the MSC 40 is the same as in Operation Example 1, and is as shown in FIG. 29.

[0239] In the MSC 40, if the Call Type parameter is determined when the RANAP: RAB APPOINTMENT REQUEST message is transmitted to the HNB-GW 30 in step S904, the call control unit 404B sets this Call Type parameter. RANAP message configuration: RAB APPLICATION REQUEST according to the present invention is shown in FIG.

[0240] In the HNB-GW 30, if the Call Type parameter is turned on in step S905 while receiving a RANAP message: RAB APPOINTMENT REQUEST, the call control unit 306B in step S906 compares this Call Type parameter with the Registration Reason parameter (FIG. 6) of the HNBAP message : REQUEST FOR REGISTRATION UE (figure 5), when the mobile station 10 was gaining access to the GW HNB-30.

[0241] For example, in case 2 shown in Fig. 31, the Call Type parameter reported from the MSC 40 is a "Normal Call" even though the HNBAP Message Registration Cause: UE REGISTRATION REQUEST parameter is an "Emergency Call". Based on these circumstances, the HNB-GW 30 determines that the mobile station 10 falsely presented an emergency call and illegally accesses the HNB 20, and therefore implements the call disconnection process.

[0242] Thus, for an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20 and which has changed the Establishment Cause to misrepresent an emergency call, it is possible to prevent the service from being received by the HNB 20.

[0243] (1-B) Case of a packet switched call

An example operation is described below for the case in which the SGSN 50 reports the result of determining the type of packet switched call in the RANAP message RAB APPOINTMENT REQUEST.

[0244] The sequence of operations in the case of a packet switched call is similar to a circuit switched call, except that the processes performed in the MSC 40 are performed in the SGSN 50. However, the process of determining the Call Type parameter that is activated in step S802 is different. This process of determining the Call Type parameter in the SGSN 50 is the same as in Operation Example 1, and is as shown in FIG. 32.

[0245] In the SGSN 50, if the Call Type parameter is determined when the RANAP: RAB APPLICATION REQUEST message is transmitted to the HNB-GW 30, the call control unit 504B sets this Call Type parameter. RANAP Message Configuration: RAB PURPOSE REQUEST according to the present invention is the same as with the MSC 40, as shown in FIG.

[0246] In HNB-GW 30, if the Call Type parameter is enabled while receiving a RANAP message: RAB APPOINTMENT REQUEST, the call control unit 306B compares this Call Type parameter and the Registration Reason Parameter (FIG. 6) of the HNBAP message: UE REGISTRATION REQUEST (FIG. .5) at a time when the mobile station 10 was accessing the HNB-GW 30.

[0247] In case 2 shown in Fig. 31, the Call Type parameter that was reported from the SGSN 50 is a "Normal Call" even though the HNBAP Message Registration Cause parameter: UE REGISTRATION REQUEST is an "Emergency Call". Based on these circumstances, the HNB-GW 30 determines that the mobile station 10 falsely presented an emergency call and illegally accesses the HNB 20, and therefore, the call disconnection process is implemented.

[0248] Thus, for an unauthorized mobile station 10-2, which is supposed to be unable to access the HNB 20 and which has changed the Cause of Establishment to misrepresent the emergency call, it can be prevented from receiving the service via the HNB 20 even in the case of packet VoIP switching.

[0249] The methods performed in the HNB 20, HNB-GW 30, MSC 40, and SGSN 50 according to the present invention can be applied to a program to be executed by a computer. In addition, this program can be stored on a recording medium and can be provided externally via a network.

[0250] Although the present invention has been described above in specific terms based on preferred exemplary embodiments, the present invention is not limited to the above exemplary embodiments and is obviously open to various modifications without departing from the gist of the invention.

[0251] For example, in the second exemplary embodiment, the setting of the Cause of Emergency value in the RANAP protocol message was performed by the HNB 20, but this setting can also be performed by the HNB-GW 30.

[0252] Furthermore, in the second exemplary embodiment, countermeasures to unauthorized access were performed in the MSC 40 or SGSN 50, but these countermeasures can also be performed in the HNB-GW 30. In this case, as in the fourth exemplary embodiment, the HNB- The GW 30 receives information from the MSC 40 or SGSN 50 indicating that the actual type of call for the call that was initiated by the mobile station 10 is an emergency call, and uses the table in FIG. 31 to implement measures to counter unauthorized access.

[0253] Furthermore, according to first to fourth exemplary embodiments, RANAP messages are used to transmit information indicating that the mobile station 10 initiated the call as an emergency call, or information indicating that the actual type of call was for the call initiated by the mobile station 10 is an emergency call between the HNB 20, the HNB-GW 30 and the core network device (MSC 40 or SGSN 50). However, messages are not limited to RANAP messages, and other messages can be used if messages can be transmitted between the HNB 20, the HNB-GW 30, and the core network device.

[0254] This application claims priority based on Japanese Patent Application 2009-1011130, which was filed April 17, 2009, and the full disclosure of which is incorporated herein by reference.

Claims (14)

1. A gateway device connected to a core network device and a base station, the gateway device comprising:
a first signal transceiver that communicates with a base station, and
a second signal transceiver that communicates with a core network device, wherein
the gateway device checks the consistency between the first message related to the emergency call and the second message related to the emergency call. 2. The gateway device according to claim 1, wherein the first message is a UE REGISTRATION REQUEST message. 3. The gateway device according to claim 1 or 2, wherein the second message is a RAB APPOINTMENT REQUEST message. 4. The gateway device according to claim 1, wherein the first message includes a Registration Reason. 5. The gateway device according to claim 1, in which the first message is a message related to registration, and the second message is a message related to the establishment. 6. The gateway device according to claim 5, wherein the message related to registration is a message that is transmitted to the gateway device from the base station in order to register the mobile station with the gateway device. 7. The gateway device according to claim 5, in which the message related to the establishment is a message that is transmitted to the gateway device from the core network device. 8. A mobile station in a mobile communication system that comprises a mobile station, a base station, a core network device and a gateway device connected to a base station and a core network device, the mobile station comprising:
a communication unit that communicates with a base station;
wherein the gateway device communicates with the base station and the core network device and checks for consistency between the first message related to the emergency call and the second message related to the emergency call. 9. The mobile station of claim 8, wherein the first message is a UE REGISTRATION REQUEST message. 10. The mobile station of claim 8 or 9, wherein the second message is a RAB APPOINTMENT REQUEST message. 11. The mobile station of claim 8, wherein the first message includes a Registration Reason. 12. The mobile station of claim 8, wherein the first message is a registration related message and the second message is an establishment related message. 13. The mobile station of claim 12, wherein the registration-related message is a message that is transmitted to the gateway device from the base station in order to register the mobile station with the gateway device. 14. The mobile station of claim 12, wherein the establishment-related message is a message that is transmitted to the gateway device from the core network device.

Images