TECHNICAL FIELD The present invention relates generally to wireless communications systems, and in particular to deriving the location of a P-CSCF in an IMS network for greater speed and efficiency of routing emergency calls.

BACKGROUND Mobile, wireless communications have become ubiquitous. To support large numbers of mobile (roaming) subscribers, a number of Public Land Mobile Networks (PLMN) have been established and are operative. Each PLMN is identified by a Mobile Country Code (MCC) and a Mobile Network Code (MNC). PLMNs may communicatively connect to other PLMNs; to fixed, land-wired Public Switched Telephone Networks (PSTN); and to data networks such as the Internet. From the point of view of a mobile terminal, or User Equipment (UE), the PLMN to which it is currently attached is the Registered network (R-PLMN). The R-PLMN may be a UE's Home network (H-PLMN) or a Visited network (V-PLMN). Most modern PLMNs are packet-switched networks, in which data are routed in autonomous units called packets using shared channels. Packet-switched networks are characterized by high speed, low latency, and high network resource utilization efficiency. Two examples of packet-switched PLMN technologies are the General Packet Radio Service (GPRS) of the Global System for Mobile communications (GSM), and the Evolved Packet System (EPS), also commercially known as the Long Term Evolution (LTE), of the Universal Mobile Telecommunications System (UMTS). The Internet Protocol (IP) is a widely-deployed protocol for data communications in packet-switched networks. The IP Multimedia System (IMS) is an industry standard framework for delivering voice and multimedia communications over IP networks. Communications between nodes within an IMS network utilize the Session Initiation Protocol (SIP). SIP is a signaling protocol for Internet conferencing, telephony, presence, events notification, instant messaging, and the like. SIP signaling uses a long-term stable identifier, the SIP Universal Resource Indicator (URI).

An IMS network includes one or more Application Servers (AS) providing various services, such as audio and video broadcast or streaming, push-to-talk, videoconferencing, games, file sharing, e-mail, and the like. SIP signaling packets in an IMS network are processed by SIP servers or proxies collectively called Call Session Control Function (CSCF). Different types of CSCFs perform specific functions.

A Proxy-CSCF (P-CSCF) is a SIP proxy that is the first point of contact for an IMS terminal (UE). The P-CSCF may reside in the terminal's H-PLMN or a V-PLMN. In either case, a P-CSCF is assigned to a UE during registration, which does not change for the duration of the registration. All SIP messages to and from the UE pass through the P-CSCF, which can inspect them. The P-CSCF performs authentication and security functions for the UE, and maintains records of communications for billing. A Serving-CSCF (S-CSCF) is the central SIP proxy in a UE's H-PLMN that performs

SIP services and session control. Based on information from a Home Subscriber Server (HSS) database, the S-CSCF handles SIP registrations, in which it binds the UE IP address to a SIP address. The S-CSCF also can intercept and inspect all SIP messages to and from the UE. The S-CSCF decides to which AS SIP messages will be forwarded, to obtain their services. The S-CSCF also provides routing services, typically using Electronic Numbering (ENUM) lookups, and it enforces network operator policies.

An Interrogating-CSCF (I-CSCF) is a SIP proxy located at the edge of an administrative domain. The IP address of the I-CSCF is published in the Domain Name System (DNS) of the domain, so that remote servers can find it, and use it as a forwarding point for SIP packets into the l-CSCF's domain. The I-CSCF retrieves the subscriber location from the HSS, and then routes SIP requests to its assigned S-CSCF.

Regulatory agencies in many countries establish a single emergency telephone number {e.g., 91 1 ) that works throughout the country to connect a UE dialing the number to an emergency services dispatcher or law enforcement agency. Special rules may apply to the emergency number. For example, in many countries, PLMNs are required to accept and route calls placed using the emergency number, even for UE without billing data (e.g., a valid SIM card) or UE that have never been registered to the PLMN and are otherwise inoperative for communications. Another requirement for PLMNs may be to automatically ascertain the location (to varying levels of specificity) of a UE dialing the emergency number. Furthermore, the UE may also be required to be registered to a P-CSCF and to a Gateway (GGSN or PDN GW) in the local R-PLMN, i.e., in the PLMN whose MME/SGSN the UE is currently using, when making normal IMS telephony calls, as the operator may be required to be able to supply, e.g., Legal Intercept services to the authorities. To support this requirement, the Third Generation Partnership Program (3GPP), the standards body for mobile telecommunications, states in Technical Standards (TS) that an emergency call should always be placed in the UE's local network. Thus, an emergency call by a roaming user should be placed in the R-PLMN, not the H-PLMN.

3GPP TS 24.229, version 9.1 .0, contemplates that UE always use dedicated emergency bearers. However, if the UE needs to establish an emergency session and the UE is currently registered and is engaged in a non-emergency activity, the current standard requires additional bearers to be established by the UE, and additional emergency registration. This is slow and complicated. For example, it requires multiple IPsec security associations between the UE and two P-CSCFs, multiple EPS bearers (in EPS) or PDP contexts (in GPRS), and the like. This overhead may require several seconds to complete, and imposes signaling on the PLMN.

These problems may be avoided, and the emergency call placed more quickly and with less system overhead, if the UE could re-use the existing non-emergency registration for the emergency call. The problem with this approach is that the UE may not know whether the P-CSCF it is using resides in the local PLMN. For example, the UE may reside in a V-PLMN but be registered to a P-CSCF in the H-PLMN. As another example, a UE in a V-PLMN may register with a local P-CSCF, and later roam to another network. If underlying mobility mechanisms allows the UE to keep its IP-address, the UE will not register using a P-CSCF in the new network and will continue being registered using the previously used P-CSCF. Furthermore, the UE may be simultaneously registered to two or more P-CSCFs. Accordingly, a UE may not know in which PLMN its attached P-CSCF resides, and hence will be unable to take advantage of the existing registration for an emergency call if the P-CSCF is indeed in the R-PLMN.

SUMMARY

According to one or more embodiments disclosed and claimed herein, upon performing SIP registration in an IMS system, a mobile UE obtains and stores an identifier of the PLMN of the P-CSCF. The identifier of the PLMN of the P-CSCF may be included in a SIP URI obtained when discovering a P-CSCF with which to register. Alternatively, the identifier of the PLMN of the P-CSCF may be included in a SIP URI obtained in a SIP registration response from the UE's S-CSCF. As the UE roams, it periodically obtains and stores an identifier of the R-PLMN, i.e., the PLMN whose radio network UE is currently using. Upon receiving a command to place an emergency call, the UE compares the stored identifier of the PLMN of the P-CSCF with the most recently obtained R-PLMN identifier. If the identifiers match, the UE is registered to a P- CSCF operating in R-PLMN of the UE, and UE may place the emergency call using the current registration, without the need to perform an emergency registration. If the PLMN identifiers do not match, then the UE is operating in a PLMN other than PLMN of the P-CSCF, and UE must perform an emergency registration with the local V-PLMN, and place the emergency call using the emergency registration.

One embodiment relates to a method of placing an emergency call by a UE in a PLMN. The UE registers using a server in a PLMN, and periodically obtains and stores an identifier of a R-PLMN in which the UE is operating. The UE receives a command to place an emergency call. In response to the command to place an emergency call, the UE ascertains whether the server to which it is registered is associated with the R-PLMN in which it is currently operating. If so, the UE places the emergency call using the current registration, without performing an emergency registration. If not, the UE performs an emergency registration with a server in the R-PLMN, and places the emergency call using the emergency registration.

In one embodiment, if the P-CSCF handling the registration is in the home network of the UE, the P-CSCF includes the identifier of the PLMN of the P-CSCF in the registration response and the UE stores this identifier, if provided. When the UE receives a command to place an emergency call, it ascertains whether the server to which it is registered is associated with the R-PLMN in which it is currently operating by comparing the stored identifiers of the PLMNs. If (a) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and if the identifier of the PLMN of the P-CSCF provided in the registration response is the same as the most recently stored identifier of the R-PLMN or if (b) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and if the registration response did not the identifier of the PLMN of the P-CSCF, then the UE determines that the server to which it is registered is associated with the R-PLMN in which it is currently operating, and it places the emergency call using the current registration. If the identifier of the PLMN associated with the server does not match the most recently stored identifier of the R-PLMN or if the identifier of the PLMN of the P-CSCF provided in the registration response is different than the most recently stored identifier of the R-PLMN, then the UE determines that the server to which it is registered is not associated with the R-PLMN in which it is currently operating, and an emergency registration in the R-PLMN is required.

In one embodiment, the UE and the P-CSCF in the home network of the UE are pre- configured with a unique token. The UE is also preconfigured with the identifier of the home PLMN. The UE registers with a server in a PLMN and obtains and stores an identifier of the PLMN of radio network used at registration. Additionally, when the P-CSCF handling the registration is in the home network of the UE, the P-CSCF includes the unique string in the registration response. When the UE receives a command to place an emergency call, it ascertains whether the server to which it is registered is associated with the R-PLMN in which it is currently operating by comparing the stored identifiers of the PLMNs. If (a) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and the identifier of the PLMN of radio network used at registration matches the preconfigured identifier of the home PLMN or if (b) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and the identifier of the PLMN of radio network used at registration does not match the preconfigured identifier of the home PLMN and if the registration response did not contain the preconfigured token, then the UE determines that the server to which it is registered is associated with the R- PLMN in which it is currently operating, and it places the emergency call using the current registration, without performing an emergency registration. Otherwise the UE the UE determines that the server to which it is registered is not associated with the R-PLMN in which it is currently operating, and an emergency registration in the R-PLMN is required prior to placing the emergency call.

Yet another embodiment relates to a UE operative in a PLMN. The UE includes a transceiver operative to communicate with one or more PLMNs, memory operative to store at least PLMN identifiers, a user interface operative to receive a command to place an emergency call, and a controller. The controller is operative to control the transceiver to register using a server in a PLMN, to periodically control the transceiver to obtain an identifier of a R-PLMN in which the UE is operating, and to store and the update R-PLMN identifier in memory as it is received. The controller is further operative, in response to receiving from the user interface a command to place an emergency call, to ascertain whether the server to which the UE is registered is associated with the R-PLMN in which the UE is currently operating. If the server to which the UE is registered is associated with the R-PLMN in which the UE is currently operating, the controller is operative to control the transceiver to place the emergency call using the current registration, without performing an emergency registration. If the server to which the UE is registered is not associated with the R-PLMN in which the UE is currently operating, the controller is operative to control the transceiver to perform an emergency registration with a server in the R-PLMN, and place the emergency call using the emergency registration.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a functional block diagram of a wireless communication system comprising a plurality of interconnected PLMNs.

Figure 2 is a flow diagram of a method of placing an emergency call by a UE in a PLMN.

Figure 3 is a call flow diagram of a UE registering in a V-PLMN. Figure 4 is a functional block diagram of a wireless UE.

DETAILED DESCRIPTION Figure 1 depicts a representative wireless communication system 10 comprising a plurality of operationally interconnected PLMNs 12, 14, 16. The PLMNs 12, 14, 16 are depicted as IMS overlaid on GPRS networks, although the present invention is applicable to wireless communication protocols other than GPRS. The PLMN 12 is the home PLMN to a mobile, wireless UE 18, which is controlled by a S-CSCF 20 in the H-PLMN 12. As a representative example, the UE 18 may be powered-on in a geographic area served by a visited PLMN, V-PLMN ₁ 14. Using SIP procedures, the UE 18 discovers the SIP URI of a P-SCSF 22 in V-PLMN ₁ 14, and registers using the P-SCSF 22. Connectivity is established to the UE 18 via a PDN gateway GW 24 and Serving GPRS Support Node (SGSN) and Mobility Management Entity (MME) 26, all under the control of the S-CSCF 20 in the H-VPLM 12 of the UE 18.

The UE 18 may subsequently move to a different geographic area, this one served by a second visited PLMN, V-PLMN ₂ 16, as indicated by dashed lines in Fig. 1 . The UE remains registered with the P-SCSF 22 in V-PLMN ₁ 14, and under the control of the S-CSCF 20 in the H-VPLM 12. Connectivity is maintained to the UE 18 via a connection between the SGSN/MME 28 in the V-PLMN ₂ 16 and the GW 24 in the V-PLMN ₁ 14.

While in the area served by V-PLMN ₂ 16, the user of UE 18 may need to place an emergency call. Due to a regulatory requirement that emergency calls should be placed in the local network, the UE 18 would need to perform an emergency registration with the V-PLMN ₂ 16 - that is, discover the SIP URI of a P-CSCF (not shown) in V-PLMN ₂ 16, and perform a SIP registration procedure to the discovered P-CSCF SIP URI, as well as establish a new PDN connection to a GW (not shown) in V-PLMN ₂ 16 - and then place the emergency call using the emergency registration. In general, this is necessary because the UE 18 remains registered to the same P-CSCF 22, and as the UE 18 visits different PLMNs, it does not know whether the P-CSCF 22 to which it is registered is part of its current V-PLMN 16.

Consider the case that the UE 18 moves back to the V-PLMN ₁ 14 (or never left it), prior to the need to place an emergency call. Since the P-SCSF 22, to which the UE 18 is registered, is a local P-SCSF to the V-PLMN ₁ 14, the requirement that the UE 18 perform an emergency registration in V-PLMN ₁ 14 adds unnecessary delay and overhead - the UE 18 can simply use its existing SIP registration to the P-SCSF 22 to place the emergency call. However, the UE 18 must be able to verify that the P-SCSF 22 used during registration is in fact part of the current PLMN 14. Figure 2 depicts a method 30 of placing an emergency call by UE 18 in a

PLMN 12, 14, 16. As described above, the UE 18 registers with a server 22 in a PLMN 14 (block 32). As the UE 18 roams, it periodically obtains and stores an identifier of the R-PLMN 16 - that is, the PLMN who's MME/SGSN the UE is currently using (block 34). The identifier may comprises the MCC and MNC of the PLMN. Upon receiving, e.g., from a user, a command to place an emergency call (block 36), the UE 18 ascertains whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (block 38). There are several ways the UE 18 may make this determination, as described in greater detail below. If the UE 18 determines that the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating, it may place the emergency call using the current registration, without the need to perform an emergency registration

(block 40). If, however, the UE 18 determines that the server 22 to which it is registered is not associated with the R-PLMN 16 in which it is currently operating, then the UE 18 must perform an emergency registration with the local R-PLMN 16, and place the emergency call using the emergency registration (block 42).

As mentioned above, the UE 18 may ascertain whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating in a number of ways. In one embodiment, as part of the registration, the UE 18 obtains and stores an identifier of the PLMN 14 of the server 22. In one embodiment, the identifier comprises both the MCC and MNC of the PLMN. In another embodiment, the identifier is only the MCC. The UE 18 may obtain this identifier in several ways, as disclosed in greater detail herein. Upon receiving the command to place an emergency call, the UE 18 compares the stored identifier of the PLMN 14 obtained at registration with the last-received identifier of the R-PLMN 16 received from the radio network (alternatively, the UE 18 may obtain a "fresh" R-PLMN 16 identifier in response to receiving the emergency call command). If the identifiers match, the UE 18 determines that the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38), and it may place an emergency call without performing an emergency registration (Fig. 2, block 40). If the stored PLMN 14 identifier obtained at registration does not match the last-received identifier of the R-PLMN 16 received from the radio network, then the UE 18 determines that the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38), and it must perform an emergency registration with a server in the R-PLMN 16, and place an emergency call without using the emergency registration (Fig. 2, block 42).

The SIP registration of the UE 18 with a R-PLMN (Fig. 2, block 32) comprises three basic steps. First, the UE 18 must attach to the packet-switched radio network (e.g., GPRS or EPS) implementing the IMS protocol. For example, to attach to a GPRS network, the UE 18 must activate a Packet Data Protocol (PDP) context in the GPRS network. As another example, to attach to an EPS network, the UE 18 receives a default EPS bearer activated by the network, over which the UE 18 may send and receive IP data traffic. Once attached to the underlying packet-switched radio network, the UE 18 discovers the SIP URI of a P-CSCF 22 in the R-PLMN 14 {e.g., using DHCP). Third, after the UE 18 has the P-CSCF SIP URI, it initiates a SIP registration towards the discovered SIP URI. As part of the SIP registration, the UE 18 is informed about the P-CSCF SIP URI which the S-CSCF 20 uses to reach the P-CSCF 22. This P-CSCF SIP URI is contained in the Path header field of the received SIP 2xx response for the SIP REGISTER request.

Figure 3 depicts the SIP call flow 50 for the registration step (i.e., after the UE 18 has attached to a radio network and discovered the SIP URI of a P-CSCF 22). The UE 18 sends a SIP REGISTER request to the discovered P-CSCF 22 (step 51 ), which forwards a request to an I-CSCF (not shown in Fig. 1 ) of the H-PLMN 12 of the UE 18 (step 52). The I-CSCF queries a Home Subscriber Server (HSS) database (not shown in Fig. 1 ) to request subscriber information (step 53), and the HSS responds with the requested information (step 54). The I-CSCF then send a SIP REGISTER request to the S-CSCF 20 associated with the UE 18 (step 55). Based on additional information obtained from the HSS (steps 56 and 57), the S-CSCF 20 performs service control functionality (step 58), and propagates a SIP 200 OK acknowledgement back to the UE 18 (steps 59-61 ).

According to embodiments of the present invention, during either the P-CSCF SIP URI discovery or the SIP registration process, the UE 18 obtains an identifier of the PLMN 14 associated with the P-CSCF 22 to which the UE 18 registers. In one embodiment, the discovered P-CSCF SIP URI contains an identifier of the PLMN 14 associated with the P-CSCF 22, such as the MCC/MNC of the PLMN 14. For example, the host part of the P-CSCF SIP URI can be structured as the host part of the temporary public user identity. Alternatively, there may be a URI parameter containing the host part of the temporary public user identity. In one embodiment, the identifier of the PLMN 14 associated with the P-CSCF 22 is contained in the SIP URI that the S-CSCF 20 used to reach the P-CSCF 22, which is sent to the UE 18 in a SIP response as part of the SIP registration procedure. In either case, the UE 18 stores the identifier of the PLMN 14 associated with the P-CSCF 22 for future use. As the UE 18 roams through various PLMNs, it obtains, and periodically updates, an identity of the current R-PLMN 16, such the MCC/MNC, from Mobility Management interactions with the packet-switched radio network {e.g., from the SGSN/MME 28 in a GPRS domain). In some cases, the UE 18 may additionally obtain a number of identities {e.g., MCC/MNC) of equivalent PLMNs.

A user indicates to the UE 18 a need to place an emergency call, such as by entering a unique emergency phone number {e.g., 91 1 ) into a keypad, by selecting a previously stored contacts list entry or speed dial entry containing the unique emergency phone number, or by similar mechanism, as known in the art. In response to the command to place an emergency call, the UE 18 ascertains whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38). In one embodiment, this is determined by comparing the stored identifier of the PLMN 14 associated with the P-CSCF 22, obtained during SIP registration, with the most recently obtained identifier of the R-PLMN 14 in which the UE 18 is currently operating (that is, the PLMN 14 whose radio resources the UE 18 is using). Based on this determination, the UE 18 either places the emergency call using the current registration (block 40), or performs an emergency registration and then places the emergency call using the emergency registration (block 42). The process of emergency registration to a local P-CSCF is defined in the 3GPP technical standards, and hence is known in the art. In the case that the UE 18 obtained a list of equivalent PLMNs, the stored identifier of the PLMN 14 associated with the P-CSCF 22 is compared to all of the equivalent PLMN identifiers, and any match indicates the UE 18 may use the existing SIP registration to place the emergency call.

The UE 18 may ascertain whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38) in different ways. In one embodiment, only if the P-CSCF to which the UE 18 registers is in the home PLMN 12 of the UE 18, is the PLMN identifier included in the P-CSCF SIP URI obtained during SIP registration (i.e., in the discovered P-CSCF SIP URI or in the P-CSCF SIP URI obtained in an registration response from the S-CSCF 20). This embodiment may be selectively implemented in an individual PLMN 12, without regard to whether other PLMNs 14, 16 implement it, as these may be operated by different entities. In addition, in this embodiment the UE 18 obtains and stores an identifier of the PLMN used at the registration, obtained from Mobility Management interactions with the underlying radio network (e.g., GPRS or EPS) at the time of the SIP registration. As described above, as it roams throughout the system 10, the UE 18 obtains and periodically updates an identifier of the R-PLMN 16 in which it is currently operating (and, in some cases, a list of equivalent PLMN identifiers).

Upon receiving a command to place an emergency call (Fig. 2, block 36), the UE 18 must ascertain whether it is in its home PLMN 12, or has roamed into another PLMN 14, 16. In this embodiment, the UE 18 ascertains whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38) by making two comparisons. If (a) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and if the identifier of the PLMN of the P-CSCF 22 provided in the registration response is the same as the most recently stored identifier of the R-PLMN (that is, the UE 18 is in its home PLMN 12), or if (b) the identifier of the PLMN of radio network used at registration matches the most recently stored identifier of the R-PLMN and if the registration response did not the identifier of the PLMN of the P-CSCF (that is, the UE 18 registered in a PLMN other than its home PLMN, but it is still in that PLMN), then the UE determines that the server to which it is registered is associated with the R-PLMN in which it is currently operating (Fig. 2, block 38), and it places the emergency call using the current registration (Fig. 2, block 40). If the identifier of the PLMN associated with the server does not match the most recently stored identifier of the R-PLMN or if the identifier of the

PLMN of the P-CSCF provided in the registration response is different than the most recently stored identifier of the R-PLMN, then the UE 18 determines that the server 22 to which it is registered is not associated with the R-PLMN in which it is currently operating (Fig. 2, block 38), and an emergency registration in the R-PLMN is required to place the emergency call (Fig. 2, block 42).

In another embodiment, the UE 18 is provisioned with an operator-specific, unique token. If the P-CSCF to which the UE 18 registers is in the home PLMN 12 of the UE 18, the UE 18 obtains a token during the registration process, by either of the mechanisms disclosed above {i.e., in the discovered P-CSCF SIP LJRI or in the P-CSCF SIP URI obtained in a response from the S-CSCF 20). Additionally, the UE 18 is provisioned with its home PLMN 12 identifier, such as the MCC/MNC. If the P-CSCF 22 to which the UE 18 registers is not in the home PLMN 12 of the UE 18, there is no restriction on the contents of its SIP URI (although it will not include the same token with which the UE 18 is provisioned). In addition, the UE 18 obtains a PLMN identifier at the time of registration from Mobility Management interactions with the packet-switched radio network (e.g., GPRS or EPS). As described above, as it roams throughout the system 10, the UE 18 obtains and periodically updates an identifier of the R-PLMN 14, 16 in which it is currently operating (and, in some cases, a list of equivalent PLMN identifiers).

Upon receiving a command to place an emergency call (Fig. 2, block 36), the UE 18 must ascertain whether it is in its home PLMN 12, or has roamed into another PLMN 14, 16. In this embodiment, the UE 18 ascertains whether the server 22 to which it is registered is associated with the R-PLMN 16 in which it is currently operating (Fig. 2, block 38) by making two comparisons. If (a) the identifier of the PLMN of the radio network used at registration matches the most recently stored identifier of the R-PLMN 16, and the identifier of the PLMN of radio network used at registration matches the preconfigured identifier of the home PLMN 12 (that is, the UE 18 is in its home PLMN 12), or if (b) the identifier of the PLMN of the radio network used at registration matches the most recently stored identifier of the R-PLMN 16 and the identifier of the PLMN of the radio network used at registration does not match the preconfigured identifier of the home PLMN 12 and if the registration response did not contain the preconfigured token (that is, the UE 18 registered in a PLMN other than its home PLMN 12, but it is still in that PLMN), then the UE determines that the server to which it is registered is associated with the R-PLMN in which it is currently operating (Fig. 2, block 38), and it places the emergency call using the current registration (Fig. 2, block 40). Otherwise, the UE 18 determines that the server 22 to which it is registered is not associated with the R-PLMN in which it is currently operating (Fig. 2, block 38), and an emergency registration in the R-PLMN is required to place the emergency call (Fig. 2, block 42). The PLMN identifiers discussed herein may comprise both the MCC and MNC of a

PLMN. In some embodiments, the comparison of PLMN identifiers comprises comparing both the MCC and MNC portions. In some embodiments, only the MCC portion is compared. In these embodiments, a UE 18 may use the P-CSCF 22 of a different operator, but ensure it is in the same country. However, in such embodiments, additional logic may be required in the routing of SIP messages, as it may not be possible to use a Cell Identity to find the appropriate Public Safety Access Point (PSAP). In one embodiment, an entity monitors and identifier of the R-PLMN of the UE 18 - that is, the PLMN of the packet-switched wireless network the UE 18 is currently using. The entity responsible for monitoring the R-PLMN identifier could be the UE 18 or a network 10 node. If the responsible entity is the UE 18, it will, upon certain instances, receive an updated R-PLMN identifier, and compare it to the stored R-PLMN identifier (that is, the previously used

R-PLMN). The UE 18 may receive the updated R-PLMN and make the comparison, e.g., in response to an indication from network that the MME or SGSN changed, in response to a user command to place a call, or periodically. If the new (i.e., current) R-PLMN identifier is different than the stored (i.e., previous) R-PLMN identifier, then the UE 18 performs a new registration to the R-PLMN local network. This may include activating a new PDP context or EPS bearer towards a new GW (GGSN or PDN GW) in the local PLMN. The UE 18 also performs a new IMS registration towards a new P-CSCF located in the R-PLMN.

As noted above, the R-PLMN identifiers may comprise both an MCC and MNC. In one embodiment, the UE 18 only compares the MCC of the updated and stored R-PLMN identifiers, thus performing a new registration only if the UE 18 moved to a new country. In another embodiment, the UE 18 compares both the MCC and the MMC of the updated and stored R-PLMN identifiers, thus performing a new registration every time the UE 18 moves into a network operated by a different operator.

If the R-PLMN identifier is monitored by a network node, the node will, at appropriate times, examine if the current R-PLMN of the UE 18 is different from that of the previously used R-PLMN If so, the network may deactivate the PDP contexts or EPS bearers related to the IMS communication, with an indication that they need to be re-activated. Alternatively, the P- CSCF (or other network 10 entity) may send an error message to the UE 18, indicating that the UE 18 is required to activate a new PDN connection and register to a newly discovered P- CSCF. As discussed above, the R-PLMN identifier may comprise the MCC/MNC of the network 10. If a network 10 node has the responsibility to check whether the UE 18 has moved to another operator or if the UE 18 has moved to a new country, other checks than checking the MCC/MNC can be made. For example, a GGSN or PDN GW can use any serving network identifier, e.g., the IP address of the SGSN or MME, to understand whether there is a need to trigger a deactivation of the PDP contexts or EPS bearers related to the IMS communication (i.e. PDN connection used for the IMS communication).

In these embodiments, where the UE 18 maintains IMS registration to a P-CSCF in the local R-PLMN while roaming, not only IMS emergency calls are ensured to be placed in the local network, but also all IMS telephony calls are ensured to be placed in the local network. This ensures that services such as Legal Intercept are enabled.

Figure 4 depicts a UE 18 operative to implement embodiments of the present invention. The UE 18 includes a transceiver 70, antenna 72, controller 74, memory 76, and user interface 78. The UE 18 may include additional circuits, modules, and functional blocks not depicted in Figure 4 for clarity. The transceiver 70, which may be connected to one or more antennas 72, is operative to send and receive data packets to and from one or more PLMNs 12, 14, 16, in conformance with one or more radio network protocols (e.g., GPRS, EPS, or the like). Operation of the transceiver 70, as well as overall operation of the UE 18, is controlled by a controller 74, which may comprise a general-purpose, stored-program microprocessor executing software programs; a Digital Signal Processor; a logical state machine; or other controller as known in the art. The controller 74 is operatively connected to memory 76, which may store one or more software modules operative to implement embodiments of the present invention on the controller 74. The memory 76 is further operative to store one or more PLMN identifiers, such as an MCC or MCC/MNC pair, and in one embodiment is operative to store a provisioned, operator-specific, unique token.

A user interface 78 allows a user to interact with and control the operation of the UE 18. The user interface 78 may include a direct connection to the transceiver 70, allowing it to send voice signals to, and receive audio from, the transceiver 70, under control of the controller 74. The user interface 78 may include input means such as a keypad, keyboard, buttons, switches, touchscreen, microphone, camera, or the like, and may further include output means such as one or more display screens, LEDs, a speaker, or the like, as known in the art. At a minimum, the user interface 78 includes means for a user to command the UE 18 to place a call to a predetermined emergency phone number {e.g., 91 1 ).

Embodiments of the present invention provide a UE 18, operating in a wireless communication system 10, the ability to ascertain whether a P-CSCF 22, to which the UE 18 has an existing SIP registration, is in the local PLMN 14 serving the geographic location of the UE 18. If so, in environments where it is a regulatory requirement that an emergency call placed in the PLMN local to the UE 18, the UE 18 may use the existing SIP registration to place an emergency call, without the need to perform an emergency registration. This increases the speed of connection of the emergency call, and reduces system overhead signaling. If the UE 18 is not registered to the local PLMN, embodiments of the present invention indicate that fact as well, allowing the UE 18 to perform emergency registration to the local PLMN, to place the emergency call in conformance with the regulatory requirements.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein. The following documents are incorporated by reference herein, each in its entirety:

3GPP TS 23.060 "General Packet Radio Service (GPRS); Service description; Stage 2"

3GPP TS 23.167 "IP Multimedia Subsystem (IMS) emergency sessions" 3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for Evolved

Universal Terrestrial Radio Access Network (E-UTRAN) access"

3GPP TS 24.008 "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"

3GPP TS 24.173 "IMS Multimedia telephony service and supplementary services; Stage 3"

3GPP TS 24.229 "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3"

3GPP TS 24.301 "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3" 3GPP S2-094393, available at http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_74_Sophia_Anti polis/Docs/S2-094393.zip

3GPP S2-095663, available at http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_75_Kyoto/Docs/ S2-095663.zip