WO2013151484A1

WO2013151484A1 - Call -back to a ue that has made an emergency call via a visited ims network

Info

Publication number: WO2013151484A1
Application number: PCT/SE2013/050281
Authority: WO
Inventors: Ralf Keller; Fredrik Lindholm
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-04-03
Filing date: 2013-03-15
Publication date: 2013-10-10
Also published as: EP2835027A1; US9294618B2; US20150181033A1; EP2835027B1

Abstract

The 3GPP Technical Specifications stipulate that when an emergency call is made to an emergency centre such as a Public Safety Access Point (PSAP), special procedures are applied to ensure that the call is correctly routed and not interrupted. However, there may be situations where the PSAP might want to call-back the UE after the call has been terminated (intentionally or unintentionally terminated). As specified in the standards, an emergency call that is established over the IMS is anchored in the IMS entities that serve the UE through the access network at which the UE was attached when the emergency call was established (i.e. in the visited network, not in the user's Home Network as would be the case for a normal call). The current procedures for call-back to a particular device require the PSAP to call back to the right device by indicating an equipment identifier or instance ID or Globally Routable User Agent Uniform Resource Identifier (GRUU) provided by the UE during emergency call establishment (see TS 24.229). However, this requires an IP-PSAP with enhanced functionality, something unlikely to be deployed in many countries. This problem is solved in that the S-CSCF is informed that an emergency call takes place in the visited network without having to route the initial emergency call through the home network. The P- CSCF (23) in the visited network (21) informs the S-CSCF (26) in the user's home network (22) that the user has established an emergency call with a particular equipment identifier (e.g., contact address, instance ID or GRUU). The S-CSCF (26) uses this information to route a terminating emergency call-back to the right device.

Description

CALL -BACK TO A UE THAT HAS MADE AN EMERGENCY CALL VIA A VISITED IMS NETWORK

Technical Field

The present disclosure relates to methods and apparatus in a telecommunications network for enabling an emergency call centre to call back to a user equipment that originally established an emergency call via an IMS network.

Background

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person- to-person communication experience through the integration and interaction of services. IMS allows person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) and Session Description Protocol (SDP) to set up and control calls or sessions between user terminals (or user terminals and application servers). Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.

Figure 1 illustrates schematically how the IMS fits into the mobile General Packet Radio Service (GPRS) network architecture. As shown in Figure 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1 , also referred to as the bearer plane and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network (IP-CAN). The GPRS network includes various GPRS Support Nodes (GSNs). The middle layer is the Control Layer 4, and at the top is the Application Layer 6.

The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1 , and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 include Serving CSCFs (S-CSCF) and Proxy CSCFs (P-CSCF), which operate as SIP proxies within the IMS in the middle, Control Layer 4. Other IMS core network entities shown include a Media Resource Function Controller (MRFC), a Border Gateway Control Function BGCF and a Media Gateway Control Function, (MGCF). The top, Application Layer 6 includes the IMS service network 3b with Application Servers (ASs) 7 for implementing IMS service functionality.

As shown in Figure 1 , a User Equipment (UE) can access the IMS by attaching to an access network and then over the Connectivity Layer 1 , which is part of a Packet Switched (PS) domain. For example, the UE may attach via an Evolved Packet Core (EPC)/Long Term Evolution (LTE) access. In that case an IMS session can be set up by the UE using SIP signalling. However, a UE may also access IMS services via a Circuit Switched (CS) domain 8. Although the CS domain will not handle SIP, procedures are well established for dealing with the provision of media and services between the IMS and a UE using a CS access. 3GPP has established standardised procedures specified in Technical Specifications (TS). For example TS 23.228 relates to IMS SIP, TS 23.203 relates to the Policy and Charging Control (PCC) architecture, and TS 23.167 relates to Emergency Calls for IMS. In addition the so-called Single Radio Voice Call Continuity (SRVCC) specifications (TS 23.216 and TS 23.237) deal with the handover of calls from a PS to a CS access network, and specify how emergency calls are routed.

The 3GPP Technical Specifications stipulate that when an emergency call is made to an emergency centre such as a Public Safety Access Point (PSAP), special procedures are applied to ensure that the call is correctly routed and not interrupted. However, there may be situations where the PSAP might want to call-back the UE after the call has been terminated (intentionally or unintentionally terminated). As specified in the standards, an emergency call that is established over the IMS is anchored in the IMS entities that serve the UE through the access network at which the UE was attached when the emergency call was established (i.e. in the visited network, not in the user's Home Network as would be the case for a normal call).

The current procedures for call-back to a particular device require the PSAP to call back to the right device by indicating an equipment identifier or instance ID or Globally Routable User Agent Uniform Resource Identifier (GRUU) provided by the UE during emergency call establishment (see TS 24.229). However, this requires an IP-PSAP with enhanced functionality, something unlikely to be deployed in many countries.

WO03/049467 A1 discloses a method and system for call-back in case of an emergency session. The document suggests an emergency call setup similar to the setup of a normal call, thus involving an S-CSCF located in the home network of the UE making the emergency call. However, shown system result in an inefficient emergency call setup that is not in accordance with preferred procedures for emergency call setup. Summary

It is therefore an object to provide methods and apparatuses that enable call-back to a UE that has made an emergency call via a visited IMS network in an efficient and reliable manner. According to a first aspect, there is provided a method of performing a call-back from an emergency call-centre to a UE that has established an emergency call to the call centre routed via a visited IMS network. The method includes notifying an S-CSCF in the user's IMS Home Network that the UE has established the emergency call, and providing the S-CSCF with an equipment identifier of the UE. When an emergency call-back request towards the user is received from the emergency call centre at the S-CSCF, the S-CSCF routes the emergency call-back to a UE using the identification information provided.

In particular the first aspect comprises an emergency call and an emergency call- back for a first UE connected to a visited IMS network. The method comprises an establishment of an emergency call by the first UE by sending an emergency call request to a P-CSCF in the visited IMS network. The P-CSCF provides information to an S-CSCF in a home IMS network for the first UE, the information comprising an indication that the emergency call has been performed and an equipment identifier of the first UE. Then the S-CSCF receives an emergency call-back request from an emergency call-centre, whereby the S-CSCF uses the information comprised in the received emergency call-back and the information previously provided by the P- CSCF to route the emergency call-back to the first UE and/or to a second UE. According to a second aspect a method of establishing an emergency call for a first UE connected to a visited IMS network is provided. The method is performed at a P- CSCF in the visited IMS network and begins with receiving a call-request from the first UE. The P-CSCF determines the received call-request to be an emergency call and sends an invite signal to an E-CSCF in the visited IMS network thereby enabling routing of the emergency call through the E-CSCF. The P-CSCF also provides information to an S-CSCF in a home IMS network for the first UE, the information comprising an indication that the emergency call has been performed and an equipment identifier of the first UE, thereby enabling emergency call back to the first UE. According to a third aspect a method of performing emergency call-back at an S- CSCF located in a home IMS, network for a first UE is provided. The method begins by receiving information from a P-CSCF located in an IMS network in which the first UE is visiting. The received information comprises an indication that the first UE is making an emergency call in the visited IMS network and an equipment identifier of the first UE. The S-CSCF then receives an emergency call-back request from an emergency call-centre and uses the information comprised in the received

emergency call-back request with the information received from the P-CSCF in order to route the emergency call-back to the first UE and/or to a second UE. According to a fourth aspect, there is provided a telecommunications network entity of a visited IMS network. The network entity includes an interface through which SIP signalling is received and sent, a memory storing data and programming instructions and a processor for implementing the program instructions. On receiving a request to establish an emergency call from a user equipment, UE, accessing the visited network, the network entity is configured to route the emergency call to an emergency call-centre. The network entity is further configured to inform an S-CSCF in the user's IMS Home network that an emergency call has been established.

In particular, the fourth aspect provides a P-CSCF of an IMS network. The P-CSCF comprises an interface transmitting and receiving SIP messages, a memory storing data and programming instructions and a processor for implementing the program instructions. The processor is coupled to the interface and configured to receive a call request from a first UE visiting in the IMS network of the P-CSCF; determine the received call-request to be an emergency call; send an invite signal to an E-CSCF in the IMS network of the P-CSCF, thus enabling routing of the emergency call through the E-CSCF. The processor is also configured to provide information to an S-CSCF in a home IMS network for the first UE, the information comprising an indication that the emergency call has been performed as well as an equipment identifier of the first UE, thereby enabling emergency call back to the first UE.

According to a fifth aspect there is provided a S-CSCF entity of an IMS network that is a home network of a user. The S-CSCF includes an interface through which SIP signalling is received and sent, a memory storing data and programming instructions and a processor for implementing the program instructions. The program instructions configure the S-CSCF to store in its memory a received indication that a UE of the user has established an emergency call which has been routed to an emergency call centre via a visited network, and an equipment identifier of the UE. The S-CSCF is further configured, when receiving an emergency call-back request towards the user sent from the emergency call-centre, to use the stored information to route the call back to the identified UE.

In particular the fifth aspect provides an S-CSCF of an IMS network, the IMS network being a home IMS network for a first UE. The S-CSCF comprises an interface transmitting and receiving SIP messages, a memory storing data and programming instructions and a processor for implementing the program instructions. The processor is coupled to the interface and configured to receive information from a P- CSCF located in an IMS network in which the first UE is visiting. The information comprises an indication that the first UE is making an emergency call in the visited IMS network and an equipment identifier of the first UE from. The processor is further configured to receive an emergency call-back request from an emergency call-centre and to use the information comprised in the received emergency call-back with the information received from the P-CSCF in order to route the call-back to the first UE and/or to a second UE. Thus, when the establishment of an IMS emergency call is detected, for example by the P-CSCF, then the P-CSCF sends a message (e.g., a SIP I NFO message) to the S-CSCF of the user's Home Network where the UE is registered in, to inform the S- CSCF that an emergency call has been established by this subscriber, and to include the equipment identifier of the UE. The S-CSCF then uses this information to route a call-back from an emergency call-centre/PSA P to ensure that it is routed to the right device. The S-CSCF can also suppress any services that should not be invoked for a user during an emergency call-back.

Brief Description of Drawings

Figure 1 is a schematic illustration showing how the IMS fits into the mobile General Packet Radio Service (GPRS) network architecture.

Figure 2 is a signal diagram illustrating a procedure for an Emergency Registration; Figure 3 is a signal diagram illustrating a procedure for establishing an Emergency call on an Emergency Registration;

Figure 4 is a signal diagram illustrating a procedure for an Emergency Call-back. Figure 5 is a flow diagram illustrating the steps in an Emergency Call-back procedure.

Figure 6 is a flow diagram illustrating a procedure performed by a P-CSCF during establishment of an emergency call.

Figure 7 is a flow diagram illustrating the method steps performed by an S-CSCF during establishment of an emergency call from a UE as well as during a call-back procedure. Figure 8 is a schematic block diagram of a network entity, such as a P-CSCF, configured to implement aspects of the Emergency Call-back procedures.

Figure 9 is a schematic block diagram of a network entity, such as an S-CSCF, configured to implement aspects of the Emergency Call-back procedures.

Detailed Description

Figure 2 illustrating a procedure for an Emergency Registration. As shown, a UE 20 accesses a serving, or visited IMS network 21. The UE 20 is a subscriber to a Home IMS network 22. Signal 201 is a SIP Register request sent from the UE 20 to a P- CSCF 23 in the visited network 22. The Register request 201 is a request to register an Emergency call/session and includes an emergency (SOS) parameter. The registration proceeds with the P-CSCF 23 forwarding a Register Request 202, with the emergency parameter, to an l-CSCF 24 in the UE's Home network 22. The I- CSCF 24 maps the emergency parameter to an IMS Emergency Registration by setting an appropriate flag, or flags. The l-CSCF 24 sends a User Authorisation Request (UAR) message 203 to the HSS 25 in the Home network 22 together with the appropriate Emergency registration flags. Because it is for an Emergency call, the HSS skips the usual check for call barring or other restrictions and responds with a User Authorisation Answer (UAA) signal 204. The Registration procedure continues with a SIP register signal sent to an S-CSCF 26 in the Home network 22, which completes the registration by performing applicable authentication procedures, and provides the UE with applicable public user identities from a subscriber profile. Note that this is consistent with the normal registration procedures, where an S- CSCF 26 is assigned to handle the session. If this was a normal registration and not an Emergency registration, the S-CSCF 26 would then be linked into the call path. However, as it is an Emergency call, then in accordance with the specified procedures, it will instead be routed from the P-CSCF 23 to the PSAP via an E-CSCF in the visited network, rather than via the Home network 22.

Signal 205 also includes an indication of a timeout at which the emergency registration will expire. Also, as noted in Figure 2, if the UE already had a normal registration, then the emergency registration contact information is not overwritten at the S-CSCF 26, so that the normal registration will continue after the emergency registration has timed out. Signals 206 represent the completion of the SIP authentication procedures. Following exchange of Service Authorisation Request (SAR) signals 207 and 208 between the S-CSCF 26 and the HSS 25, the S-CSCF 26 returns a SIP 200 OK signal 209 to the l-CSCF 24, which is forwarded to the P-CSCF 23. As noted in Figure 2, because this is an emergency registration, the S-CSCF skips the usual initial Filter Criteria (iFC) check for any third party registration. In signal 209 the S- CSCF 26 may include an indication that it supports an emergency call-back indication. The P-CSCF 23 returns a SIP 200 OK signal 210 to the UE 20. As noted in Figure 2, the P-CSCF 23 maintains stored information relating to the registration, and uses the emergency parameter to mark the registration as an emergency registration. Referring to Figure 3, where the same entities have the same reference numerals as in Figure 2, the UE 20 initiates the emergency call by sending a SIP Invite 301 , which is directed to the P-CSCF 23 in the serving (visited) network 21. As indicated in the figure, the Invite signal 301 comprises a URN string "urn.services:sos". By recognizing the URN string the Invite is treated as an emergency call. The signalling shown follows the specified procedures set out in TS 29.213, and includes an exchange of Authorisation signals - Authentication and Authorisation Request (AAR) 302 and Authentication and Authorisation Answer (AAA) 303, with a Policy and Charging Rules Function (PCRF) 31. As indicated in the figure, the AAR 302 may be sent upon receipt of an Invite or at Session Description Protocol (SDP) answer. An Invite signal 304 is then sent to the Emergency-CSCF (E-CSCF) 32 in the serving network 21 , and thereafter the emergency session is routed through the E-CSCF 32 and not through the home network 22. An Invite signal 305 is also sent to a Location Register Function (LRF) 33, from which the E-CSCF obtains the address of the PSAP 34 to which the emergency call is to be sent. However, as indicated in the Figure, there are other possible ways that the address of the PSAP 34 could be obtained, e.g. the PSAP address may be fetched from a local table. If the LRF alternative is chosen a proprietary Sh interface may be used. Further, the LRF may provide the location of the UE in case this information is missing. Finally, P-CSCF 23 sends a SIP INFO message 306 to the S-CSCF 26 in the home network 22, which includes an emergency call indication, the calling party identity and the Equipment Identity of the UE 20, in the form, for example, of an equipment identifier provided in an instance ID or Globally Routable User Agent URI (GRUU) as provided by the UE during emergency call establishment. An instance ID is a Uniform Resource Name (URN) generated by a device that uniquely identifies the specific device amongst all other devices, and does not contain any information pertaining to the user. The S- CSCF 26 stores information received in the message 306 for a predetermined or configurable amount of time. The P-CSCF 23 may use other SIP methods, such as SIP MESSAGE to convey the information to the S-CSCF 26, instead of using SIP INFO 306. The information may also be provided to the S-CSCF 26 using a plurality of messages 306.

Referring now to Figure 4, where the same entities have the same reference numerals as in Figures 2 and 3, the PSAP 34 attempts to make a call back to the UE 20 after the initial call has been terminated, either intentionally or unintentionally. The PSAP 34 sends an Invite 401 towards the user of UE 20, the Invite 401 comprising the called party identity i.e. the calling party identity of the user that initiated the emergency call. Unless the PSAP is an IP-PSAP with such functionality, the Invite will not comprise any equipment identity for the UE 20. In accordance with normal procedures for call routing via the IMS, the Invite is sent to the S-CSCF 26 that is serving the user of UE 20 and is in the user's home network 22. Now, at step 402, the S-CSCF 26 performs a check as to whether it has been informed of an emergency call performed by a subscriber with a calling party identity equal to the called party identity of the Invite 401 , i.e. it is checked if the S-CSCF 26 has a registered public user identity equal to the called party identity of the Invite 401 and if so, an equipment identity of UE 20. If it has, then it can use the information to match the called party identity in the incoming Invite with the public user identity and equipment identity of the UE and then to route the call back to the UE. The S-CSCF 26 then forwards an Invite 403 to the P-CSCF 23 in the visited network, which forwards it on to the UE 20 (signal 404). The called-back call can then continue in the normal manner via the S-CSCF 26. Note that, sometimes, the S-CSCF only needs to know the equipment identifier. However, many times the equipment identifier does not always identify the user very well, and so it is preferable that it knows both the public user identity and the equipment identifier. In that case, when an incoming request is received for call-back to the user, the called party identity of the incoming Invite can first be used to find the user, and then for that user the equipment identifier can be used to select the terminal to route the call-back to.

When the PSAP 34 establishes a call-back (signal 401), this may arrive at the S- CSCF 26 either as a normal terminating call (without a call-back indication) or as a terminating call with a call-back indication, but in both cases without any equipment identifier of the UE 20 (i.e. the address includes only the user identity of the user). Where there is a call-back indication, the S-CSCF 26 checks (action 402) whether it has a record that this subscriber, i.e. user, has performed an emergency call and if so it tries to select a contact that fits to the equipment identifier of the user (e.g. by matching it to a GRUU, contact address or instance ID). If no such call-back indication is received, the S-CSCF 26 checks whether it has a record that this subscriber has performed an emergency call, but in some embodiments it only uses that information if a predefined/configured timeout has not expired. According to embodiments it may thus be defined for how long the S-CSCF 26 should keep the information provided by the P-CSCF. Also, if the S-CSCF 26 determines (e.g. based on the INFO previously sent) that an emergency call back is being performed, it may also suppress any services that should not be invoked during the call back. If the check in action 402 results in an equipment identity for the UE 20, the S-CSCF 26 sends an Invite 403 to the P-CSCF 23 in the visited network, which thereafter forwards it on to the UE 20 (signal 404).

According to some embodiments, the S-CSCF 26 also checks a database of preferred devices/numbers to call in addition to (parallel or sequential calling) or instead (alternative calling) in case of a call-back. This may be configured to always occur in the event of an emergency call-back, or to be used in cases where the originating UE 20 does not respond. This list of devices/numbers may be configured by the user or operator to ensure that an additional or alternative number is called in case of call-back. For example this number could be that of another device sharing the same IP Multimedia Public Identity, IMPU. E.g. in case of a home with several fixed phones, each being registered separately, this list could include all the IP Multimedia Private Identities, IMPIs, for these phones), thereby ensuring that the callback reaches all phones in the same house. Other examples might include a parental number in case a child dials an emergency call, or a facility service in case of an emergency call dialled from a corporate phone. In such cases, the call is routed (signals 405 and 406 in Figure 4) to the selected contact (illustrated by UE 20a in figure 4) either instead of, or in addition to routing the call (signals 403 and 404 in Figure 4) to the UE 20. The terms phone and device should of course be seen as encompassed by the term UE.

Figure 5 is a flow diagram illustrating the method steps in an emergency call-back procedure. At step 501 a UE has established an emergency call, in accordance with current 3GPP specifications, i.e. an invite signal has been sent from the UE to a P- CSCF in a IMS network visited by the UE. At step 502 the P-CSCF through which the emergency call was established informs the S-CSCF in the UE user's Home Network that an emergency call has been established by the UE, i.e. after receipt of the invite signal from the UE, one or more messages informing the S-CSCF in the home IMS network of the emergency call is sent from the P-CSCF. Also, as shown at step 503, the P-CSCF provides the S-CSCF with an equipment identifier of the UE. The information provided in steps 502 and 503 comprises thereby at least an indication of the emergency call and an equipment identifier of the UE. This information can be provided in the form of one or more messages. At step 504 an emergency call-back request (Invite) is received in the S-CSCF in the UE user's Home IMS network. At step 505, the S-CSCF uses the UE identifier information it received from the P-CSCF in step 503 to route the emergency call-back to the UE. I.e. the S-CSCF matches the information comprised in the received emergency callback request from the emergency call-centre with the UE equipment identifier information received from the P-CSCF to route the call-back to a UE.

Figure 6 is a flow diagram illustrating the method steps performed by a P-CSCF during establishment of an emergency call. In step 601 the P-CSCF receives an invite signal from a UE making an emergency call, i.e. an emergency call-request. In step 603 the P-CSCF determines the received invite signal to be an emergency call, e.g. by recognizing a URN string "urn.services:sos" in the invite signal. In step 605, after determining that the call is an emergency call, the P-CSCF sends an invite signal to an E-CSCF, enabling routing of the emergency call through the E-CSCF. In this way the steps 601-605 can be seen as the establishment of the emergency call from the UE. In step 607 the P-CSCF provides information to an S-CSCF, in a home IMS network for the UE. The information is preferably in the form of a notification comprising an indication of the emergency call and an equipment identifier of the UE. The information can be provided using one or more messages and should comprise that the user has established an emergency call with a particular equipment identifier (e.g., contact address, instance ID or GRUU). Step 607 may be performed after receiving the invite signal from the UE (step 601) and is performed after, or at the same time as, the invite is sent to the E-CSCF (step 605).

The above described method performed by the P-CSCF enable an emergency call- back to a UE making an emergency call, even if the emergency call-centre, that for some reason needs to make a call-back, does not support sending a call-back identifier or an equipment identifier. Further, the S-CSCF is informed that an emergency call takes place in the visited network without having the call to be routed through the home network. In this way the establishment of the emergency call does not involve excessive signalling and also being in accordance with current regulations.

Figure 7 is a flow diagram illustrating the method steps performed by an S-CSCF during establishment of an emergency call from a UE as well as during a call-back procedure. In step 701 the S-CSCF receives information from a P-CSCF located in a network that the UE is visiting. The received information comprises an indication that an emergency call has been made and an equipment identifier of the UE. In step 703 the information regarding the emergency call and the equipment identifier of the UE may be stored/cached in a memory. The S-CSCF may set a timer, or the information received from the P-CSCF may include timer information, defining how long the information should be kept in the memory.

The above described steps 701 and 703 are performed by the S-CSCF during the setup of the emergency call. After establishment of the emergency call, an emergency call-centre, such as a PSAP, may need to initiate a call-back to the UE making the emergency call. Then the S-CSCF, in step 705, receives the emergency call-back request from the emergency call-centre, the call-back comprising at least the called party identity, i.e. the public user identity of the user the call-back is to be sent to, but lacks equipment identifier information for the UE that made the emergency call. In step 707 the S-CSCF checks whether the called party identity matches any emergency call record. I.e. a check is performed determining if the called party identity included in the call-back request matches any information that was received in step 701 and subsequently stored in the memory in step 703. If there is a match, the S-CSCF is able to route the call-back to the P-CSCF in the network in which the UE is located and further to the UE by using the information provided by the P-CSCF and the information in the call-back request. According to some embodiments the step 707 further includes a step 708 in which a database is checked, the database comprising preferred devices and/or numbers to call in addition to or instead of the UE that made the emergency call. This step may be configured to always occur in the event of an emergency call-back, or to be used in cases where the originating UE does not respond. This database may be in the form of a table and may be associated with, or incorporated in, the memory comprising the information stored in step 703. In step 709, if the S-CSCF has the necessary information, i.e. if there is a match, the S-CSCF routes the call-back to a UE based on said matching. The database as well as the memory may be provided in the S- CSCF or in a separate entity.

The above described method performed by the S-CSCF enables and performs an emergency call-back to a UE having made an emergency call, despite the UE being located in a visited IMS network. Further the method is able to perform an emergency call-back to a UE having made an emergency call even if the emergency call-centre, that for some reason needs to make the call-back, does not support sending a call- back identifier or an equipment identifier to the S-CSCF. Further, the S-CSCF is informed that an emergency call takes place in the visited network without having to route the initial emergency call through the home network. In this way the establishment of the emergency call does not involve excessive signalling while being in accordance with current regulations.

Figure 8 is a schematic block diagram of a network entity 800, configured to implement aspects enabling the emergency call-back procedures described above. The network entity 800 includes an interface 802 for receiving and transmitting signals to/from other network entities. A memory 806 stores data and program instructions. A processor 804 is configured to process the program instructions. In one embodiment, the network entity 800 is an entity in a visited IMS network, preferably a P-CSCF 23. The program instructions stored in the memory 806 and processed by the processor 804 detect receipt of a request to establish an emergency call from a UE accessing the visited network, and route the emergency call to an emergency call-centre. The program instructions also configure the network entity to inform an S-CSCF in the user's IMS Home network that an emergency call has been established in the visited IMS network as well as the identity of the UE.

In some embodiments the processor 804 is configured to inform the S-CSCF of the established emergency call and the equipment identity after the emergency call has been routed to an emergency call-centre, i.e. after an invite signal 304 has been sent to the E-CSCF.

In some embodiments the processor 804 is configured to inform the S-CSCF of the established emergency call and the equipment identity in form of a SIP message. The information may also comprise a public user identity of the calling party. Figure 9 is a schematic block diagram of a network entity 900, configured to implement aspects of the emergency call-back procedures described above. The network entity 900 includes an interface 902 for receiving and transmitting signals to/from other network entities. A memory 906 stores data and program instructions. A processor 904 is configured to process the program instructions. The network entity 900 is an entity in a home network of a subscriber, preferably an S-CSCF 26. The program instructions configure the entity to receive an indication that a UE of the subscriber/user has established an emergency call which has been routed to an emergency call centre via a visited network, together with an equipment identifier of the UE, and preferably store the received indication in the memory 906. The above mentioned information could also be stored in an entity separate from the network entity 900 - however this would cause more signalling in the network. The program instructions also configure the network entity 900, when receiving an emergency callback request sent from the emergency call-centre, to use the stored UE equipment identifier information to route the call back to the UE. In some embodiments the processor 904 is configured to use information comprised in the received emergency call-back request in order to match an identity of a called party included in the emergency call-back request with an equipment identifier of the UE, and then route the call-back to the UE.

In some embodiments the processor 904 is configured to use information comprised in the received emergency call-back request in order to match an identity of a called party included in the emergency call-back request with an equipment identifier of the UE; thereafter check if an alternative or additional call is to be made to a further UE; and if so route the alternative or additional call to the further UE.

It will be appreciated that at least the following new procedures have been introduced to support the SRVCC emergency service.

• The P-CSCF 23 in the visited network 21 informs the S-CSCF 26 in the user's home network 22 that the user has established an emergency call with a particular equipment identifier (e.g., contact address, instance ID or GRUU).

• The S-CSCF 26 uses this information to route a terminating emergency callback to the right device.

• The S-CSCF 26 can have an additional list of numbers/UEs to which the call should be "forked" to, i.e. routed to either in parallel or in sequence, e.g. in case the UE from which the emergency call was made do not respond.

It is a particular advantage that these procedures enable an emergency call-back to a UE/device, even if the PSAP does not support sending a call-back identifier or an equipment identifier. I.e. the above mentioned procedures can be used even in systems having legacy emergency call-centres and without unnecessary involvement of an S-CSCF in the home network.

Claims

A method of establishing an emergency call and an emergency call-back for a first User Equipment, UE, (20), connected to a visited Internet Protocol Multimedia Subsystem, IMS, network (21), the method comprising:

establishing (501) an emergency call by the first UE (20) sending an emergency call request to a Proxy Call Session Control Function, P- CSCF, (23) in the visited IMS network (21);

- providing (502, 503), from the P-CSCF (23) to a Serving CSCF, S-CSCF, (26), in a home IMS network (22) for the first UE (20), information (306) comprising an indication that the emergency call has been performed and an equipment identifier of the first UE (20);

receiving (504), in the S-CSCF (26), an emergency call-back request (401) from an emergency call-centre (34); and

using (505), in the S-CSCF (26), information comprised in the received emergency call-back (401) and the information (306) provided by the P- CSCF (23) to route the emergency call-back to the first UE (20) and/or to a second UE (20a).

A method of establishing an emergency call for a first User Equipment, UE, (20) connected to a visited Internet Protocol Multimedia Subsystem, IMS, network (21), the method enabling emergency call-back to the first UE (20) and comprising, at a Proxy Call Session Control Function, P-CSCF (23) in the visited IMS network (21):

- receiving (601), from the first UE (20), a call-request (301);

determining (603) the received call-request to be an emergency call;

- sending (605), to an Emergency CSCF, E-CSCF (32) in the visited IMS network, an invite signal (304) enabling routing of the emergency call through the E-CSCF (32); and

- providing (607) information (306) to a Serving CSCF, S-CSCF (26), in a home IMS network (22) for the first UE (20), the information comprising an indication that the emergency call has been performed and an equipment identifier of the first UE (20), thereby enabling emergency call back to the first UE (20).

3. Method according to claim 2, wherein said information (306) is provided (607) to the S-CSCF (26) after the invite signal (304) has been sent (605) to the E- CSCF (32).

Method according to claim 2 or 3, wherein said information (306) is provided (607) in form of a Session Initiation Protocol, SIP, message, the information (306) further comprising a public user identity of the calling party.

A method of performing emergency call-back, the method comprising, at a Serving Call Session Control Function, S-CSCF, (26) located in a home Internet Protocol Multimedia Subsystem, IMS, network (22) for a first User Equipment, UE (20):

receiving (701) information (306) from a Proxy Call Session Control Function, P-CSCF, (23) located in an IMS network (21) in which the first UE (20) is visiting, the information (306) comprising an indication that the first UE (20) is making an emergency call in the visited network (21) and an equipment identifier of the first UE (20);

receiving (705) an emergency call-back request (401) from an emergency call-centre (34);

using (707) information comprised in the received emergency call-back (401) with the received information from the P-CSCF (23) when routing (709) the call-back to the first UE (20) and/or to a second UE (20a).

Method according to claim 5, wherein the step of using (707) information comprised in the received emergency call-back (401) comprises matching an identity of a called party included in the emergency call-back request with an equipment identifier of the first UE (20), and

said routing (709) comprises routing the call-back to the first UE(20)

Method according to claim 5 or 6, wherein the step of using (707) information comprised in the received emergency call-back (401) further comprises checking (708) if an alternative or additional call is to be made to a second UE (20a); and if so

routing (709) the alternative or additional call to the second UE (20a).

8. Method according to any of the preceding claims 5-7, further comprising the step of storing (703) the information comprised in the received emergency call-back (401) in a memory.

9. Method according to any preceding claim 1-8, wherein the equipment

identifier is provided in an instance identity, ID, or a Globally Routable User Agent Uniform Resource Identifier, GRUU.

10. A Proxy Call Session Control Function, P-CSCF (23, 800) of an Internet Protocol Multimedia Subsystem, IMS, network (21), the P-CSCF (23, 800) comprises an interface (802) transmitting and receiving Session Initiation Protocol, SIP, messages, a memory (806) storing data and programming instructions and a processor (804) for implementing the program instructions, the processor (804) being coupled to the interface (802) and configured to: receive (601), from a first User Equipment UE (20) visiting in the IMS network (21) of the P-CSCF (23, 800), a call-request (301);

determine (603) the received call-request (301) to be an emergency call; - send (605), to an Emergency CSCF, E-CSCF (32) in the IMS network (21) of the P-CSCF (23, 800), an invite signal (304) enabling routing of the emergency call through the E-CSCF (32); and

- provide (607) information (306) to a Serving CSCF, S-CSCF (26), in a home IMS network (22) for the first UE (20), the information comprising an indication that the emergency call has been performed and an equipment identifier of the first UE (20), thereby enabling emergency call back to the first UE (20).

1 1. The P-CSCF (23, 800) according to claim 10, wherein the processor (804) is further configured to provide said information (306) to the S-CSCF (26) after the invite signal (304) has been sent (605) to the E-CSCF (32).

12. The P-CSCF (23, 800) according to claim 10 or 11 , wherein the processor (804) is further configured to provide said information (306) to the S-CSCF (26) in form of a SIP message, the information (306) further comprising a public user identity of the calling party.

13. A Serving Call Session Control Function, S-CSCF (26, 900) of an Internet Protocol Multimedia Subsystem, IMS, network (22), the IMS network (22) being a home IMS network for a first User Equipment, UE (20), the S-CSCF (26, 900) comprises an interface (902) transmitting and receiving Session

Initiation Protocol, SIP, messages, a memory (906) storing data and programming instructions and a processor (904) for implementing the program instructions, the processor (904) being coupled to the interface (902) and configured to:

- receive (701) information (306) from a Proxy Call Session Control

Function, P-CSCF (23) located in an IMS network (21) in which the first UE (20) is visiting, the information (306) comprising an indication that the first UE (20) is making an emergency call in the visited IMS network (21) and an equipment identifier of the first UE (20);

- receive (705) an emergency call-back request (401) from an emergency call-centre (34);

use (707) information comprised in the received emergency call-back (401) with the information received from the P-CSCF (23) to route (709) the call-back to the first UE (20) and/or to a second UE (20a).

14. The S-CSCF (26, 900) according to claim 13, wherein the processor (904) i further configured to: use (707) information comprised in the received emergency call-back (401) in order to match an identity of a called party included in the emergency call-back request with an equipment identifier of the first UE (20), and route (709) the call-back to the first UE(20)

15. The S-CSCF (26, 900) according to claim 13 or 14, wherein the processor (904) is further configured to: use (707) information comprised in the received emergency call-back (401) in order to match an identity of a called party included in the emergency call-back request with an equipment identifier of the first UE (20); check (708) if an alternative or additional call is to be made to a second UE (20a); and if so

route (709) the alternative or additional call to the second UE (20a).

16. The S-CSCF (26, 900) according to any of the preceding claims 13-15, wherein the processor (904) is further configured to store (703) the information comprised in the received emergency call-back (401) in the memory (906).