Emergency call support for mobile communications

[0001] The present invention relates to the support of calls to emergency telephone numbers in communication systems, and particularly in communication systems where network access is controlled, such as where shared network access is provided for different operators for example.

[0002] So-called third generation (3G) mobile communication networks are currently being deployed. In Europe such networks conform to various standards formalized by the 3^rd Generation Partnership Project (3GPP), which has a number of versions, generally known as releases.

[0003] The high price paid for the licenses to operate 3G networks, in particular in Europe, together with the potential high cost of 3G network infrastructure deployment, has motivated network operators to develop innovative strategies in network infrastructure deployment.

[0004] One effective way to reduce the investment costs and risks of a fast 3G network deployment is for operators to share parts of, or the whole of, their 3G network infrastructure. In the current dynamic market place, as a result of partnerships, acquisitions, creative agreements and such like amongst operators, equipment manufacturers and service providers, the need for tools that enable various degrees of network sharing is becoming more and more important.

[0005] Typically sharing partners have their own dedicated networks, and a further shared network is provided in which all the sharing partners provide services. In 3GPP release 5 (REL-5), a concept known as UTRAN (UMTS terrestrial radio access network) sharing has been introduced in order to bring mobility and access control features to allow correct operation of shared networks. In “UTRAN sharing” the radio access network is divided into shared network areas, which shared network areas further consist of one or more location areas. A user equipment is allowed access to a network area only if it is authorized to. Thus networks must be provided with means for determining whether network access by a particular user equipment is allowed, and preventing a call being established if it is not. Thus a call may not be established if the user equipment is not authorized for the network, or a call may be dropped if a user equipment moves to an unauthorized network.

[0006] A basic principle in mobile communication networks, however, is that an emergency call should never be dropped or caused to be dropped due to roaming or other access control restrictions applicable for normal roaming, calls, packet-switched sessions, or other types of transactions.

[0007] The proposals for UTRAN sharing in 3GPP REL-5, however, provide for authorization checks to be performed in shared networks such that a call may be terminated if a user equipment (UE) is currently in, or moves into, a network area for which calls are not authorized. This presents the possibility of the shared network control features terminating an emergency call.

[0008] In proposals for shared networks, it has been proposed that as part of the establishment of the call, a core network returns to a radio access network the shared network area (SNA) access information (AI) for the UE associated with the call establishment. The radio access network may then use this information to reject the call initially, or ‘drop’ the call if the UE moves to a network for which call connections are not authorized.

[0009] More specifically, in current proposals the core network provides SNA AI to the UTRAN after the signaling connection establishment. SNA AI consists of a set of PLMN (public land mobile network) identities (PLMN-ID), and a set of shared network area codes (SNAC) for each PLMN, which codes indicate the areas the UE is allowed to access. The UTRAN performs access control based on the received user specific SNA AI. That is, the UTRAN allows the UE to access only those shared network areas identified in the SNA AI. If there are no allowed shared network areas available, or if the UE is currently in a ‘forbidden’ network, then the UTRAN initiates connection release towards the core network and the call is released according to 3GPP REL-5 specifications.

[0010] However, as discussed above in the event of an emergency call, the call should not released even if there are no allowed shared network areas available.

[0011] In accordance with current 3GPP REL-5 specifications, there is a proposal for handling (circuit switched) emergency voice calls if the RNC and the circuit-switched domain of the core network know that the call is an emergency call. In such circumstances, the circuit switched core network sends a RANAP:COMMON ID message as soon as the IMSI is known, but does not send the SNA AI for the UE. By not transmitting the SNA AI, it is intended that this access information cannot be used to terminate the emergency call, and hence the emergency call will not be dropped due to the SNA access restraints for the UE.

[0012] However a problem may arise with this proposal, where a new call between the UE and the network is established in the packet switched domain of the core network, whilst the emergency call in the circuit switched domain is ongoing. The establishment of the packet-switched call may result in the SNA AI being provided to the radio network controller (RNC) of the UTRAN. Thus the RNC may obtain the SNA AI and use this information, potentially leading to the emergency call being dropped.

[0013] A further problem may arise if relocation occurs, and the call is transferred to a different network. In such a case, a handover to a target network is performed for the circuit switched emergency call, and its connection (Iu-cs) is relocated to a given target RNC. As a result of this relocation, and as proposed by 3GPP REL-5, the packet switched core network may send the SNA AI for the UE to the target RNC. Thus the target RNC is provided with SNA AI which may cause the emergency call to be dropped.

[0014] It is an aim of the invention to address one or more of the above-stated problems.

[0015] In principle, embodiments of the invention may be considered to generally introduce enhancements to allow the UTRAN to know when the call is an emergency call, and to specify the UTRAN behaviour in the case of an emergency call.

[0016] In one aspect the invention provides a method of supporting emergency calls in a mobile communications network, comprising: receiving, in a network, a network access from a user equipment; selectively controlling access to the network in dependence on network access information, and disabling the step of selectively controlling access to the network for an emergency call network access.

[0017] In one embodiment, the method may include the step of checking if network access information is available. If the network access information is available, then the step of controlling access to the network in dependence on network access information may be selected. If the network access information is not available, then the step of controlling access to the network in dependence on network access information may not be selected.

[0018] In another embodiment, the method may not involve a step of checking if network access information is available. The absence of network access information would simply mean that the step of controlling access to the network in dependence on network access information may consider the permitted network access to be unlimited. It may be considered that the absence of network access information is equivalent to the presence of network access information which is indicative of unrestrictive access. The invention does not depend, therefore on the provision of network access information.

[0019] The network access information may be shared network area access information.

[0020] The method may further include the step of determining if said network access is an emergency call. The step of determining if said network access is for an emergency call may include receiving an indication of the type of network access. The method may further include the step of receiving the indication of the type of network access from the user equipment or from the network.

[0021] The network preferably comprises an access network and a core network. The steps of controlling and disabling the access to the network are preferably performed in the access network.

[0022] The access network preferably determines if said network access is an emergency call in dependence on receipt of an indication of the type of network access from the core network.

[0023] On receipt of an indication of the type of network access being an emergency call, the method may further comprise activating the step of disabling the step of selectively controlling access to the network.

[0024] The method may further comprise detecting a network access initiation, and responsive thereto disabling the step of selectively controlling access to the network. Said disabling step may be for a predetermined time period. The method may further comprise the step of detecting establishment of a radio access bearer, and responsive thereto activating the step of disabling the step of selectively controlling access to the network for an emergency call network access. The method may further comprise activating the step of disabling the step of selectively controlling access to the network for an emergency call network access associated with that radio access bearer. Said disabling step may be terminated responsive to a control signal.

[0025] The method may further comprise the step of receiving the network access information from the core network.

[0026] The method may further include the step of detecting termination of an emergency call, and responsive thereto the step of enabling the means for selectively controlling access to the network.

[0027] The method is preferably implemented in a 3GPP mobile communication system.

[0028] In another aspect the invention provides a computer program product including computer program code adapted to perform the method.

[0029] In another aspect the invention provides a computer program adapted to perform the method.

[0030] In a further aspect, the invention provides a network element for enabling emergency calls in a network comprising: network access request receiving means for receiving a network access request from a user equipment; selection means for selectively controlling network access for the user equipment in dependence on network access information; and disabling means for disabling the selection means for an emergency call network access.

[0031] The network access information may be shared network area access information.

[0032] The network element may further include determining means for determining if said network access is an emergency call.

[0033] The determining means may include receiving means for receiving an indication of the type of call.

[0034] The indication of the type of network access may be received from the user equipment or from the network.

[0035] The network may comprise an access network and a core network. The network element may be in the access network.

[0036] The determining means may determine if said network access is an emergency call in dependence on receipt of an indication of the type of network access from the core network.

[0037] The network element may further include activating means for activating the disabling means responsive to receipt of an indication of the type of network access being an emergency call.

[0038] The network element may comprise means for detecting a network access initiation, and further disabling means responsive to said detecting means for disabling the step of selectively controlling access to the network.

[0039] The network element may further include timer means, wherein said further disabling means is activated for a predetermined time period determined by said timer means.

[0040] The network element may further comprise detecting means for detecting establishment of a radio access bearer, and activating means responsive thereto for activating the disabling means.

[0041] The network element may further comprise means for receiving the network access information from the core network.

[0042] The network element may further include detection means for detecting termination of an emergency call, and enabling means responsive thereto for enabling the selection means.

[0043] The network element may be a radio network controller of a radio access network.

[0044] In a still further aspect the invention provides a communication system comprising: an access network; a core network; and at least one user equipment for connection to the core network through the access network, the access network comprising: means for receiving a request for a network access from the user equipment; means for receiving network access information from the core network; means for selectively controlling access to the core network for the UE in dependence on said network access information; means for identifying a request for an emergency call; and means for disabling the means for selectively controlling access to the network responsive to identification of an emergency call.

[0045] The access network may further include means for identifying termination of an emergency call, and means for enabling the means for selectively controlling access to the network responsive to termination of an emergency call.

[0046] The means for identifying a request for an emergency call may comprise input means for receiving an emergency call indicator from the user equipment.

[0047] The means for identifying a request for an emergency call may comprise input means for receiving an emergency call indicator from the core network.

[0048] The access network may further comprise means for disabling the means for selectively controlling access to the network on initiation of a call.

[0049] Said means for disabling the means for selectively controlling access to the network on initiation of a call may be activated for a predetermined time period.

[0050] The communication system may further comprise detecting means for detecting establishment of a radio access bearer, wherein said means for disabling the means for selectively controlling access to the network on initiation of a call is activated until establishment of a radio access bearer.

[0051] The access network may further include detection means for detecting termination of an emergency call, and enabling means responsive thereto for enabling the selection means.

[0052] The communication system may further include means for receiving an indication of an emergency call on relocation of the call to the access network.

[0053] The communication system may further include means for transmitting an indication of an emergency call on relocation of the call to another access network.

[0054] The communication system preferably comprises a 3GPP mobile communication system.

[0061] The invention is described herein by way of reference to specific examples, which illustrate the principles of the present invention in the context of preferred embodiments. In particular, the invention is described in the context of shared network techniques proposed in 3GPP-Rel.5. The invention, however, is not limited to such an environment, and may be more broadly applicable.

[0062] In the described environment, it is assumed that a user equipment (UE) establishes a call through a radio access network to a core network. The handling of the call in the radio access network, for the purposes of the described embodiments, is by a radio network controller (RNC) of a UTRAN. The handling of the call in the core network, for the purposes of the described embodiments, is by a mobile switching centre (MSC) server (MSS).

[0063] In proposals for shared networks, it is proposed that as part of the establishment of the call, the core network returns to the radio access network the shared network area (SNA) access information for the UE associated with the call establishment. The radio access network may then use this information to ‘drop’ the call if the UE moves to a forbidden network, or to a forbidden area within a network, for which call connections are not authorized.

[0064] Two preferred embodiments of the invention are described herein below for two example scenarios where the user equipment (UE) initiates an emergency call to a core network. In the first example scenario, it is assumed that the UE is aware that the call being made is an emergency call. In the second example scenario it is assumed that the UE is not aware that the call being made is an emergency call.

[0065] A first embodiment considered is where the UE is aware that the call being made is an emergency call. The first embodiment is described with reference to FIGS. 1 and 2.

[0066] The configuration of a network environment incorporating a UE 10, an RNC 20, and a MSS 30 are well known to a skilled person, and outside the scope of the present invention, and therefore not described herein.

[0067] The UE 10 may know the call is to an emergency number, based on a comparison of the called number to a set of numbers held in an emergency call number database in the UE. In such case, the UE is adapted to indicate the emergency nature of the call in the initial connection establishment with the mobile network. As represented by step 102, the UE initiates an emergency call.

[0068] In a subsequent RRC Connection Establishment between the UE and the radio network controller (RNC) 20 of the UTRAN, as represented by step 104, the signaling 202 from the UE identifies the call as an emergency call. As such, the RNC is notified that the call is an emergency call, as represented by step 106.

[0069] After the RRC Connection Establishment, the MSS receives a CM Service Request 204 from the UE in a step 108, via the RNC.

[0070] An indication that the call is an emergency call is provided in the CM Service Type parameter in the CM Service Request message sent by the UE. Thus the core network is notified that the call is an emergency call, as represented by step 110, at the very beginning of the call establishment.

[0071] The MSS may then initiate security procedures, as represented by signaling 206, in accordance with the provisions of any applicable standard. Preferably at least a security mode setting procedure is performed.

[0072] The MSS of the core network determines the IMSI (international mobile subscriber identity) of the UE, and then returns a RANAP: COMMON ID message 208 to the RNC of the UTRAN, as per the 3GPP REL-5 proposals.

[0073] The message 208 additionally sends, in step 112, the SNA Access Information for the UE to the RNC in the UTRAN.

[0074] In this preferred embodiment of the invention, the SNA access information is sent to the RNC. This transmission of the SNA access information is consistent with REL-5 proposals for the processing of a ‘normal’ call (i.e. non-emergency call).

[0075] This conformity with applicable standard techniques for normal telephone calls requires no adaptation to the core network operation configured for normal telephone calls, and thus enables the core network implementation to be simplified.

[0076] In an embodiment, the core network is adapted such that an indication that the call is an emergency call is transmitted in the RAB Assignment Request, for example by use of a flag. Such an embodiment simplifies the UTRAN implementation. The feature of the core network transmitting such a flag to the UTRAN is discussed herein below in the context of the second embodiment. It should be understood, however, that such a feature offers advantages when used in this first embodiment.

[0077] As long as the emergency call is ongoing, as detected in step 114, the UTRAN does not perform access control by using the SNA Access Information. Thus, the RNC in the UTRAN inhibits itself in a step 116 from any call termination associated with shared network access control whilst an identified emergency call is proceeding.

[0078] In the event that a relocation takes place whilst an emergency call is in progress, as discussed further herein below, steps should be taken to apply similar initializing steps in the RNC to which the call is transferred.

[0079] The establishment of the call, including the radio access bearer establishment, then continues in accordance with the applicable standard techniques, which are outside the scope of the present invention.

[0080] Once the emergency call is released, the UTRAN may perform access control in a step 118 as it does for all other type calls/sessions/etc in accordance with the applicable standard techniques. Thus the inhibiting of the access control in the RNC is maintained until termination of the emergency call.

[0081] As noted, contrary to 3GPP REL-5 it is proposed that where the call is identified as an emergency call, the SNA Access Information is returned to the UTRAN. The adaptation proposed in accordance with the invention allows the SNA Access Information to be transmitted to the UTRAN, whilst still supporting emergency calls, by inhibiting access control based on the SNA Access Information whilst the emergency call is in use. The invention may also be used in combination with the technique proposed in 3GPP REL-5, where the SNA Access Information is not returned to the UTRAN if an emergency call is identified. In such case, the SNA Access Information is not available in the UTRAN, so a UTRAN adapted as above may still be deployed. The inhibiting of the access control does not affect the operation of this feature.

[0082] Furthermore, a UTRAN adapted to inhibit the access control during an emergency call is advantageous in a network implemented in accordance with 3GPP REL-5, since in the event that the establishment of a packet switched communication causes the SNA Access Information which would not otherwise be made available to the RNC to reach the RNC, any access control based on such Access Information is inhibited pending the completion of the emergency call.

[0083] A second embodiment for the scenario where the UE does not know that the call being established is an emergency call is now described with reference to FIGS. 3 and 4.

[0084] When the UE does not know itself that the call is an emergency call, it cannot provide an emergency call indication to the UTRAN in the radio resource control (RRC) connection setup signaling. In a step 302, the UE initially prepares to initiate a call generally towards the RNC of the UTRAN.

[0085] Thereafter in a step 304 the connection setup signaling takes place as represented by the RRC Connection Establishment communications 402 in FIG. 4. In this embodiment, the UE does not indicate that the signaling connection is established due to an emergency call, and the signaling 402 is conventional signaling in accordance with any applicable standard.

[0086] After establishment of the RRC Connection, in a step 306 the UE transmits a CM Service Request message 404 to the MSS, via the RNC. The CM Service Request is transparent to the RNC.

[0087] Once again, as the UE does not know that the call is an emergency call, the CM Service Request contains no indication of such. The CM service Request message to the MSS indicates “Mobile Originated call establishment” in the CM Service Type in the CM Service Request message, identifying that the call has been originated by the UE.

[0088] The MSS may then initiate security procedures, as represented by signaling 406, in accordance with the provisions of any applicable standard. Preferably at least a security mode setting procedure is performed.

[0089] After the security procedures, the MSC of the MSS sends a RANAP:Common ID message 408 to the RNC. The Common ID message 408 includes any SNA Access Information specified for the user, as represented by step 308. This information identifies the shared network areas that the UE may access. If the UE is not authorized to share any common networks, then an indication of this is returned from the core network to the UTRAN.

[0090] According to Release 5 3GPP specifications, upon reception of SNA Access Information, the RNC should perform access control, and immediately initiate release of the connection if the UE does not have any access right in the current location area. However, in accordance with the principles of the invention, the RNC is adapted as discussed hereinafter.

[0091] Upon reception of the SNA Access Information, the RNC inhibits the access control procedures in a step 322. The RNC is thus adapted such that it does not, at this stage, initiate a release of any established connection even if the UE has entered a forbidden area.

[0092] The RNC further, in a step 318, starts an emergency call timer, which has a count Tec. The operation of the emergency call timer is described in further detail hereinafter.

[0093] The UE then initiates a call establishment by sending a CALL CONTROL Setup message 410 to the MSS via the RNC, as represented by step 310. This Setup message identifies the number called by the UE.

[0094] At the MSS, the MSC analyses the called number. Where the called number is an emergency number, the MSC identifies the called number as an emergency number, as represented by step 312.

[0095] A RAB Assignment Request message 412 is sent to the RNC in a step 314, and the MSC indicates to the UTRAN that the RAB is to be established for an emergency call, as represented by step 316.

[0096] Thereafter, in a step 318 RAB establishment and call establishment continues normally, in accordance with any applicable standard technique, as represented by signaling 414.

[0097] However, as described hereinabove the UTRAN is adapted such that the access controls have been inhibited in step 322. The UTRAN is further adapted such that it does not release the established connection as long as an emergency call is ongoing, even if the UE enters a forbidden area. A forbidden area is an area for which the UE does not have shared network access.

[0098] Thus, as illustrated by step 321, after RAB establishment the RNC monitors an established emergency call. As long as the emergency call remains established, the access control is inhibited in step 322. When the RNC detects termination of the emergency call, then in a step 324 the RNC reverts to normal operation and applies any access control mechanism in accordance with applicable techniques. If the RAB establishment is not for an emergency call in the first place, then the process moves immediately to step 324.

[0099] A scenario may arise where a collision occurs with another RAB establishment, for example an incoming voice or data call RAB establishment. In such a scenario, the RNC may be adapted to apply SNA access control for the other RAB, it not being an emergency call. Alternatively, the RNC may inhibit SNA access control for all calls until the determination of whether an emergency call is present is made, and then apply SNA access control to non-emergency calls.

[0100] As discussed hereinabove, in this embodiment for all UE initiated transactions, the RNC starts the emergency call timer, preferably at the time the SNA access information is returned to the RNC. The purpose of the emergency call timer is to provide a time-out operation in the event that an emergency call is not established within a fixed time period. For example, the call which the UE wishes to establish may not be a voice call, but may be a SMS (short messaging service) network access. The SMS call does not require establishment of any access bearers, and thus the RNC may wait at step 318 whilst the UE proceeds with SMS services. Where the UE is not authorized to access the network, such SMS messages need to be prevented and the connection terminated.

[0101] This potential problem is overcome in this embodiment of the invention by providing the emergency call counter. The time count of the emergency call counter Tec is set to be an appropriate period to allow for initialization of an emergency call. If an emergency call has not been established in that time period, then the network access which the UE is attempting to establish is not an emergency call.

[0102] Thus, referring to FIG. 3, in a step 320 the count Tec is monitored, and when the count expires the method moves on to query step 316 wherein it is determined if an emergency call has been established. If no emergency call has been established, then in step 324 normal access control is applied.

[0103] In the embodiment in which the emergency call timer is used, the implementation may be summarized as follows. The Tec timer may only start when the SNA access control function rejects the access, and the RNC does not have any indication that an emergency call is ongoing for which access control should be inhibited. Whilst the Tec timer is running, the RNC does not release and radio access bearers or any RRC/Iu connection independently, the SNA access control is inhibited. The Tec timer then may only expire when: i) the RNC receives a RAB ASSIGNMENT with an emergency call flag set; ii) the RNC receives the IU RELEASE COMMAND from the core network; or iii) the configured time expires. For (ii), if there are two domains the RNC only releases the Iu toward the domain that initiates the Iu release.

[0104] It will be understood from the above that the purpose of the emergency call timer is to prevent the inhibiting of access control for an emergency call resulting in a user establishing calls of other types in a network. This is envisaged as one possibility for achieving this, and the invention is not limited to the use of the emergency call timer as described herein. Other techniques may be provided to address this problem.

[0105] One example of another technique is described hereinafter. In current 3GPP REL-5 SNA control function, if the access for a given UE is rejected by the RNC as a result of the SNA access information, the RNC sends an IU RELEASE REQUEST message to the core network, with a cause value of ‘access restricted due to shared network’ and the RNC may drop the call immediately i.e. the RRC and Iu connection. In a proposed alternative, the RNC will only release the RRC and Iu connection after it receives a RANAP:IU RELEASE COMMAND from the core network.

[0106] Where this proposed alternative is implemented, the Tec timer described above becomes unnecessary. In this alternative, either the core network sends the RANAP:RAB ASSIGNMENT REQUEST message with the emergency call flag set, or it sends the RANAP:IU RELEASE COMMAND message. The core network releases the Iu with the RANAP:IU RELEASE COMMAND message after some NAS signaling. The NAS signaling may be via a RANAP:DIRECT TRANSFER message, such as a NAS indication of an LAU (local area update) reject).

[0107] Thus, this alternative solution ensures that the UTRAN waits for a command from the core network before releasing the RRC and Iu connection, and may be used in environments where the RNC can rely upon receiving a command from the core network. The RNC is not allowed to release the RRC/Iu connection before the IU RELEASE COMMAND is received from the core network.

[0108] If, at the expiry of the RAB assignment, and after determination that the call is not an emergency call, in step 324 the UTRAN is allowed to initiate connection release whenever the UE enters a forbidden area, in accordance with the applicable techniques for access control.

[0109] In a preferred embodiment, the RNC is adapted to apply the techniques described herein to all network access requests. Thus, if a UE has an ongoing emergency call, and is in a forbidden area, access control is applied to any other network accesses made by the mobile. This would prevent, for example, a user making an emergency call in a forbidden area from using the emergency call override functionality provided by this invention to also surf the Internet. Whilst in current implementation it is envisaged that emergency calls are made through the circuit switched domain, the embodiments of the invention may be applied to all network accesses, whether they originate in the circuit switched domain or the packet switched domain. The RNC is preferably adapted such that in general it inhibits network access control for emergency calls, but performs access control for other network accesses or for connections originating in the core network.

[0110] The two embodiments described hereinabove with reference to FIGS. 1 to 4 concern the case where an emergency call is detected on establishment of a new call by a UE, to ensure that the SNA AI does not cause such call to be dropped. It is also important to ensure that the emergency call is not dropped as a result of SNA AI techniques if the call is relocated from one network to another due to the UE moving, and embodiments of the invention permit this.

[0111] In the case of relocation of the RAB for the emergency call, whilst the call is ongoing, in the described embodiments of the invention the source RNC knows the call is an emergency call, i.e. has an emergency call indicator. The emergency call indicator being set effectively inhibits any access control techniques.

[0112] In order to ensure appropriate handling of the call on relocation, the emergency call indicator is preferably provided to the target RNC by the core network in an adapted RELOCATION REQUEST message, in addition to the SNA Access Information.

[0113] The RELOCATION REQUEST message is a message used in 3GPP for handling a relocation, and specifically in 3GPP REL-5 for additionally providing, if available, the SNA Access Information of the UE with which the call is established to the target RNC. The relocation mechanism itself is outside the scope of the present invention, and will be familiar to one skilled in the art. This embodiment of the invention proposes inserting an indication of whether the call is an emergency call in this message, and more generally this may be considered to be a step of notifying the target RNC as to whether the relocated call is an emergency call.

[0114] Thus the target RNC may handle the emergency call in the same way as the source RNC adapted in accordance of the first and second embodiments of the invention as described hereinabove, in dependence on receiving an indication that the call is an emergency call.

[0115] This applies for either case, independent of whether the UE originally knew of the emergency call or not. Where the UE knew of the emergency call, the information is available to the original RNC through the RRC Connection Setup signaling. Where the UE did not know of the emergency call, the information is available in the RANAP:RAB ASSIGNMENT REQUEST message provided to the RNC.

[0116] In a further arrangement, the RNC may have already been relocated once or more on relocation, in which case the RNC may have become aware of the emergency status of the call through any technique described hereinabove.

[0117] Referring now to FIG. 5, there is illustrated in block diagram form the main functional elements required in the UTRAN and the core network for implementing the described embodiments of the invention. Only those functional elements required for implementing the invention are described. One skilled in the art will appreciate that other functional elements are required for the correct implementation of the system.

[0118] As shown in FIG. 5, the RNC includes an emergency call detector block 502, an inhibit access control block 506, an access control block 508, a call processing block 510, a call control block 512, and a Tec timer 504. The MSS includes a call processing block 514 and a call control block 516.

[0119] The emergency call detector detects an emergency call, as discussed in the embodiments above, either by direct notification from the UE on a line 518, or by notification from the MSS on a line 524. When notification is received from the MSS, the call control block 516 of the MSS detects the emergency call in an emergency call detector ECD 517 thereof, and sets the notification signal on line 524.

[0120] The emergency call detector block 502 sets a control line SET to the inhibit access control block 506 to inhibit access control, when an emergency call is detected. The Tec timer block 504 similarly sets a control line SET to the inhibit access control block 506 to inhibit access control during call initialization.

[0121] When set, the inhibit access control block 506 controls the access control block 508 to inhibit access control, and the access control block does not carry out any processing.

[0122] In FIG. 5, the call processing block 510 of the RNC represents the block through which calls are set-up, in the direction of the UE on line 520 and in the direction of the core network on lines 526. The control processing block 512 of the RNC represents the block through which control signaling is exchanged, in the direction of the UE on line 522 and in the direction of the core network on lines 528.

[0123] The call processing block 514 of the MSS represents the block through which calls are set-up in the direction of the RNC on line 526. The control processing block 516 of the MSS represents the block through which control signaling is exchanged, in the direction of the RNC on line 528.

[0124] As illustrated further in FIG. 5, the inhibit access control block 506 is reset by a RESET signal from either the Tec timer 504 (provided the signal is not set from the emergency call detector block 502), or the call control block 512 when the emergency call is terminated.

[0125] The arrangement of FIG. 5 is suitable for implementation of either the first or second described embodiment. The embodiments may be implemented in combination, to cater for any eventuality.

[0126] It should be noted that the invention is described herein with reference to exemplary embodiments. In particular the embodiments described are for supporting emergency calls in 3GPP REL-5 shared network area environments. The invention is not, however, limited to such environments.

[0127] The Release 5 Shared Networks Access Control is specified in the following 3GPP specifications: 3GPP TS 25.413: “UTRAN Iu interface RANAP signalling”; 3GPP TS 25.410: “UTRAN Iu Interface: General Aspects and Principles”; 3GPP TS 25.401: “UTRAN Overall Description”; 3GPP TS 23.003: “Numbering, addressing and identification”; —3GPP TS 23.009: “Handover procedures”; and 3GPP TS 48.008: “Mobile Switching Centre—Base Station System (MSC-BSS) interface; Layer 3 specification”.

[0128] More generally, the invention is applicable in any network environment where some access control to the network is required, and where emergency calls must be supported.

[0129] Thus whilst the environment in which the invention is deployed is preferably one in which a UE, or a user associated with a UE, must have authority to utilize a shared network area, the inventive principles extend to deployment in any network environment where authorization is required to establish a call.

[0130] Although in the embodiments the access control is facilitated in the access network, this is because current proposed standards all rely upon such location of the control mechanism. Alternatively the principles of the present invention may be readily applied, where the implementation requires, elsewhere in the network, such as in elements of the core network.

[0131] Furthermore, the invention is not limited to any specific access network or core network implementation. Whilst the described embodiments relate to the use of an RNC of a UTRAN and an MSS of a core network, generally the functionality described may be implemented in any network element of the radio access network or the core network.

[0132] For the implementation of embodiments of the invention, communication systems supporting shared network areas require adaptation in one and/or the other of the RNC and the MSC/MSS.

[0133] It should be noted that the invention may be utilized in roaming scenarios, where agreements between operators allow use of each others networks. However, the invention is not limited to roaming scenarios. The invention applies to any scenario where a mobile terminal or user equipments attempts to establish a call to a network. In embodiments, the mobile may have moved under a scenario other than a roaming scenario. However in attempting to make a connection, whether the mobile has moved, by roaming or otherwise, is irrelevant.

[0134] One skilled in the art will appreciate the modifications and adaptations which may be made to the described embodiments, and principles which may be extended to other implementations, without departing from the scope of the invention, which is defined by the appended claims.