WO2013160465A2 - Appels de service d'urgence améliorés - Google Patents

Appels de service d'urgence améliorés Download PDF

Info

Publication number
WO2013160465A2
WO2013160465A2 PCT/EP2013/058794 EP2013058794W WO2013160465A2 WO 2013160465 A2 WO2013160465 A2 WO 2013160465A2 EP 2013058794 W EP2013058794 W EP 2013058794W WO 2013160465 A2 WO2013160465 A2 WO 2013160465A2
Authority
WO
WIPO (PCT)
Prior art keywords
emergency
request
session
ims
service
Prior art date
Application number
PCT/EP2013/058794
Other languages
English (en)
Other versions
WO2013160465A3 (fr
Inventor
Afshin Abtin
David Castellanos Zamora
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Publication of WO2013160465A2 publication Critical patent/WO2013160465A2/fr
Publication of WO2013160465A3 publication Critical patent/WO2013160465A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]

Definitions

  • Mechanisms for enhancing Emergency Service calls are presented. These include support of enriched indications of type of Emergency Service. In particular the mechanisms relate to emergency calls over an IP Multimedia Subsystem (IMS) network.
  • IMS IP Multimedia Subsystem
  • the IP Multimedia Subsystem is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks.
  • the IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers).
  • SIP Session Initiation Protocol
  • SDP Session Description Protocol
  • SIP Session Description Protocol
  • SIP was created as a user-to-user protocol
  • the IMS introduces additional functionality for e.g. subscription handling, security and charging to allow operators and service providers to control user access to services and to charge users accordingly.
  • FIG. 1 is a network diagram illustrating schematically how the IMS fits into mobile network architecture in the case of a General Packet Radio Service (GPRS) access network.
  • the IMS 3 includes a core network 3a, and a Service Network 3b.
  • Call/Session Control Functions (CSCFs) 4 operate as SIP proxies within an IMS core network 3a.
  • CSCFs Call/Session Control Functions
  • User Equipment (UE) 2 accesses the IMS 3 via an IP Connectivity Access Network (IP-CAN) and gateway nodes in a connectivity layer 1 .
  • IP-CAN IP Connectivity Access Network
  • a Home Subscriber Server HSS 8 keeps a log of users' subscription profiles that define the services that the user has subscribed to. After registering, the user is able to establish a communication session with other peers, making use of the multimedia capabilities of the IMS.
  • the 3GPP architecture defines a number of types of CSCFs including: a Proxy CSCF (P-CSCF) which is the first point of contact for the user within the IMS core network 3a; a Serving CSCF (S-CSCF) controls the provision of services to the users in accordance with the user's subscription; an Interrogating CSCF (l-CSCF) whose role is to identify the correct S-CSCF, based on the user's subscription profile which it obtains from the user's HSS 8, and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
  • P-CSCF Proxy CSCF
  • S-CSCF Serving CSCF
  • l-CSCF Interrogating CSCF
  • 3GPP 3 Generation partnership project
  • TS 23.167 3GPP Technical Specification (TS)
  • PSAPs Public Safety Answering Points
  • TS 24.229 The related detailed mechanisms are defined in TS 24.229 including the means by which a UE indicates that an IMS Registration is triggered for the purpose of establishing an emergency session; and the means by which an IMS emergency session is established.
  • a UE is required to match the digits dialed by the user with a list of known emergency numbers in order to trigger emergency sessions using the emergency service URN.
  • TS 24.229 defines the means by which the IMS serving network detects that an IMS session is established for the emergency service. The P-CSCF must be prepared to detect an emergency session even if the UE does not use the emergency service URN.
  • the UE or the P-CSCF may also include an additional sub-service type (e.g. ambulance, police) if information on the type of emergency service is known. This information about the type of emergency service is relevant in order to route the emergency call to the most suitable PSAP/Emergency Centre (e.g. fire department instead of police department or general emergency centre).
  • an additional sub-service type e.g. ambulance, police
  • This information about the type of emergency service is relevant in order to route the emergency call to the most suitable PSAP/Emergency Centre (e.g. fire department instead of police department or general emergency centre).
  • Embodiments provide a method of establishing an emergency session between a User Equipment, UE, accessing an IP Multimedia Subsystem, IMS, network, and an emergency service centre.
  • the emergency service centre relates to one of a plurality of emergency sub-services.
  • a Session Initiation Protocol, SIP, request is received in the IMS network from the UE, the request including the dialled digits of an emergency number.
  • the digits of the dialled emergency number are analysed, to determine a corresponding emergency sub-service.
  • the session establishment request is then routed to an emergency service centre of the corresponding emergency sub-service.
  • the method is preferably performed in an IMS network entity, such as a P-CSCF or Emergency CSCF (E-CSCF).
  • E-CSCF Emergency CSCF
  • the dialled emergency number may include a privacy prefix.
  • the need for privacy in relation to the emergency session is forwarded to the emergency service centre.
  • the dialled emergency number and/or privacy prefix digits may be included in a header field in the session establishment request.
  • the method which is based on the definition of new IMS network controlled mechanisms, enhances emergency session requests with information of the type of emergency service requested in support for more accurate and optimal selection of PSAPs.
  • the mechanisms facilitate the extension of the emergency session request with the information related to the emergency service requested, even if the UE is not initially able to identify the dialled number with a particular type of emergency service. A much more effective selection of an appropriate PSAP is then possible, based on the added information.
  • Embodiments may also provide a UE operable to communicate over an IMS and/or a method of operating a UE.
  • the UE comprises a user interface for conveying information to a user and for receiving input data and instructions from the user; a transceiver interface for transmitting signals to and receiving signals from the IMS network; a memory storing data and program instructions, and a processor for executing the program instructions in response to user input and signals received.
  • the UE is configured, when initiating an emergency session, to send a SIP request to the IMS, including the dialled digits of an emergency number dialled relating to an emergency sub-service in a header of the SIP Request in a pre-defined header field, or a header field that has been agreed between the UE and IMS network.
  • the UE may also include a dialled privacy prefix of the session initiation request.
  • Embodiments may also provide an IMS network entity that includes an input/output over which signals are sent to/from other network entities and to/from a UE accessing the IMS network.
  • the network entity also includes a memory storing data and programming instructions and a processor for executing the programming instructions, which cause the entity to analyse a SIP request received from a UE, which includes digits of an emergency number dialled at the UE, and to determine a corresponding emergency sub-service.
  • the network entity is further configured to route the request to an emergency service centre of the corresponding emergency sub-service.
  • the network entity may also be configured to recognise a privacy prefix in the digits, and to include a privacy indication in the session establishment request routed to the emergency service centre.
  • the network entity is a Proxy Call Session Control Function, P-CSCF.
  • the network entity may be an Emergency CSCF, E-CSCF.
  • FIG. 1 is a network diagram illustrating schematically how the IMS fits into mobile network architecture in the case of a General Packet Radio Service (GPRS) access network.
  • GPRS General Packet Radio Service
  • Figure 2 is a signalling diagram illustrating PSAP selection without considering type of emergency service.
  • Figures 3A and 3B are signalling diagrams illustrating PSAP selection considering the type of emergency service, in accordance with the mechanisms described herein.
  • FIG. 4 is a block diagram illustrating the principal functional components of a User equipment (UE) embodiment.
  • UE User equipment
  • FIG. 5 is a block diagram illustrating the principal functional components of an IMS network entity.
  • Figure 6 is a flow diagram illustrating procedures followed in an IMS network.
  • Figure 7 is a flow diagram illustrating procedures followed at a UE.
  • TS 24.229 specifies the means by which a UE indicates that:
  • An IMS Registration is triggered for the purpose of establishing emergency sessions (i.e. including a Contact header field with a "sos" SIP Uniform resource Identifier (URI) parameter that indicates that this is an emergency registration);
  • URI Uniform resource Identifier
  • An IMS session is established for the purpose of an emergency service (i.e. including a Request-URI sent to an emergency service Uniform Resource Name (URN) - a service URN with a top-level service type of "sos").
  • an emergency service i.e. including a Request-URI sent to an emergency service Uniform Resource Name (URN) - a service URN with a top-level service type of "sos").
  • a UE is required to match the digits dialed by the user with the list of known emergency numbers in order to trigger emergency sessions using the emergency service URN.
  • the list of known emergency numbers at the UE can comprise:
  • TS 24.229 specifies how the IMS serving network detects that an IMS session is established for an emergency service, when the Request URI is an emergency number or an emergency service URN configured in the P-CSCF.
  • the P-CSCF must be prepared to detect an emergency session even if the UE does not use the emergency service URN. This is a backup for those cases when the UE (e.g. when roaming) does not have all the information about all local emergency call numbers, and initiates a normal call (referred to as a UE undetected Emergency call in 3GPP TS 23.167).
  • TS 24.229 also defines the means by which the IMS serving network rejects an emergency session establishment request and instructs the UE to retry the emergency session after executing an IMS Emergency Registration, when required by the IP-CAN. (This involves sending a 380 (Alternative Service) response to a SIP INVITE request containing a P-Asserted-ldentity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response containing a 3GPP IP Multimedia Core Network (IM CN) subsystem XML (Extensible Markup Language) body that includes an ⁇ ims-3gpp> element, including a version attribute, with an ⁇ alternative-service> child element with the ⁇ type> child element set to "emergency").
  • IM CN IP Multimedia Core Network
  • the UE or the P-CSCF may also include an additional sub-service type (e.g. ambulance, police) if information on the type of emergency service is known.
  • an additional sub-service type e.g. ambulance, police
  • the UE this could be available if pre-configured in the Universal Services Identity Module, USIM, (for home emergency numbers), and if received (optional IE) from the serving network over Mobility Management procedures (related to local emergency numbers/services).
  • USIM Universal Services Identity Module
  • IE Mobility Management procedures
  • This information about the type of emergency service is relevant in order to route the emergency call to the most suitable PSAP/Emergency Centre (e.g. fire department instead of police department or general emergency centre).
  • the available types of emergency services as defined in 3GPP TS 24.008, are the following:
  • any emergency call number may not be available in the emergency session request, and the call is managed as a generic emergency call (i.e. routed to a generic or operator defined default emergency centre). This may occur for example when: the serving IP-CAN does not provide the list of local emergency numbers to the UE; the list of local emergency numbers is provided to the UE but without indicating which type of emergency service an emergency number is related to; and/or there is the possibility for the user to be anonymous during an emergency call, which is a regulatory requirement in some countries (e.g.
  • Japan Japan
  • the user will dial a privacy prefix together with the emergency number which will make it impossible for the UE to recognize the dialled number as an emergency call even if the UE is able to recognize the emergency number.
  • Another situation that could arise is where the list of local emergency numbers provided to the UE has conflicts with the UE's list of emergency numbers for its home network - e.g. dialled digits in home network correspond to "fire” while in the local network the same dialled digits correspond to "police".
  • the UE may be configured to use the top level SOS indication (i.e. a generic emergency number rather than any of the possible emergency sub-service types).
  • Figure 2 is a signal diagram showing the sequence of signals and actions carried out by: a UE 10; entities of a serving IMS network 1 1 , including a P-CSCF 12, Emergency CSCf (E-CSCF) 13, Location Register Function (LRF) 14 and Border Gateway Control Function/Media Gateway Control Function (BGCF/MGCF) 15; a generic PSAP 16 and a specific PSAP 27 (in this example a fire department PSAP).
  • a P-CSCF 12 Public Access Management Function
  • E-CSCF Emergency CSCf
  • LRF Location Register Function
  • BGCF/MGCF Border Gateway Control Function/Media Gateway Control Function
  • a user of UE 10 dials a local emergency number with the intention to reach e.g. the closest fire department. Potentially, the user may prefer to stay anonymous and use an optional privacy preference by dialing the local privacy prefix.
  • the UE 10 is not be able to recognize the local emergency number as an emergency number so it will initiate a normal IMS session instead over a normal Registration. Note that even when the UE 10 is aware of local emergency numbers, the potential use of a privacy prefix (as shown) may prevent the UE 10 from identifying the session request as an emergency request.
  • the serving IMS network 1 1 i.e.
  • the P-CSCF 12 will however detect that this is an emergency session attempt and will instruct the UE 10 to retry the session after executing an IMS Emergency Registration.
  • the P-CSCF 12 is configured to be aware of local emergency numbers. It is assumed that the P-CSCF 12 is also aware of the privacy prefix used in the local network, if the user has included this at step 21 .
  • the UE 10 will follow instructions from the serving IMS Network 1 1 , and after completing an emergency registration (step 25) will initiate an emergency session request 26 (including a Request-URI sent to an emergency service URN, i.e. a service URN with a top-level service type of "sos").
  • the P-CSCF 12 will not include any instructions requiring the UE 10 to include any indication of the specific type of emergency service, nor any privacy preferences. Therefore, it is not expected that the UE 10 indicates any additional information regarding the type of emergency service the emergency call is intended for as there is no particular indication for that provided by the P-CSCF in the previous steps. Furthermore, from 3GPP TS 24.229, it is unclear whether the UE 10 will simply include the emergency service URN in the "To" header field or if the UE 10 will insert a dialstring URI or a tel URL representing the dialled digits since it cannot perform local dialstring interpretation for the dialled digits.
  • 3GPP TS 24.229 does not specify any particular handling of type of emergency services, or use of privacy preferences at the P-CSCF 12 (nor at the E-CSCF 13). Therefore these indications are not included by the UE 10 in the re-sent INVITE at step 26.
  • the PSAP selection process which involves the E-CSCF 13 and the LRF 14, as shown at steps 27a and 28, will not take into account the type of emergency service that the emergency call is intended for. Therefore, even if the user is willing to get urgent access to a specific type of emergency personnel, the emergency session will be routed (steps 29a and 29b) via the BGCF/MGCF 15 towards a generic, or operator defined, default emergency centre (i.e. PSAP 16) instead of the specific fire department PSAP 17, as originally requested at step 21 . Additionally, the user's preferences regarding privacy will not be taken care of.
  • the URI is used for the SOS indication and does not include the dialled digits.
  • the mechanisms provide that, in addition to the emergency service URN in the Request-URI, the UE also includes a dialstring URI or a tel URL representing the dialled digits (both the emergency number and the privacy prefix in this example) within a header field of the emergency session request. This is shown at step 33.
  • This could be any available header field in the request, provided that the P-CSCF is configured to know in which header field of the request it should look for the dialled digits. It should therefore be a pre-defined header field, or one that has been agreed between the UE 10 and IMS network 1 1 .
  • the P-CSCF 12 when the P-CSCF 12 receives the emergency session request (i.e. including the emergency service URN in the Request-URI and the privacy prefix), the P-CSCF 12 analyses the content of the request header field in order to identify if additional information regarding the type of emergency service might be added to the emergency session request.
  • the emergency session request i.e. including the emergency service URN in the Request-URI and the privacy prefix
  • the P-CSCF 12 performs a local dialstring interpretation for the dialled digits inserted by the UE 10 in the header field of the emergency session request.
  • the P-CSCF 12 is also able to recognize any other aspect of the dialled digits that may influence the emergency session. For example, in the case that a privacy indicator is used for the emergency session, the P-CSCF 12 is able to recognize this prefix in combination with the local emergency number.
  • the P-CSCF 12 Before progressing the emergency session request to the E-CSCF 13, the P-CSCF 12 enhances the request with additional information relevant for the selection of PSAPs and/or the correct handling of the session.
  • the P-CSCF 12 could include such information now, as identified during the analysis of the dialed digits previously proposed (e.g. service. "sos".fire_brigade).
  • any other relevant aspect for the handling of the emergency session that may be inferred by the P-CSCF 12 during the analysis of the dialed digits could be included in the request.
  • the P-CSCF 12 could include a privacy header in the request. If any of the information inferred by the P-CSCF 12 during the analysis of the dialed digits is already available in the request, the P-CSCF 12 will not need to modify the request at all. The P-CSCF 12 may check the presence of this type of information in the request even before executing the analysis of the dialed numbers. At step 35, the enhanced Request is then sent to the E-CSCF 13.
  • the E-CSCF 13 When received by the E-CSCF 13, selection of PSAP and handling of the emergency session request will be managed as currently specified, but now takes into consideration the type of emergency service and additional characteristics included by the P-CSCF 12. This is shown at steps 36 and 37. Finally, at steps 38a and 38b the Request (INVITE) is routed to the selected PSAP, which in this example is the fire department PSAP 17, as originally requested by the UE 10.
  • the UE 10 recognizes the number as an emergency number and so performs an emergency registration. It then uses the SOS indication in the URI of the INVITE at step 33. However, there may be instances where the UE does not recognize the number as an emergency number and does not perform an emergency registration.
  • FIG. 3B A procedure for dealing with this situation is shown in Figure 3B, where an initial session initiation request 301 received from the UE 10 does not indicate that it is a request for an emergency session but does include the dialed digits that correspond to an emergency number known by the serving network 1 1 .
  • the UE 10 sends an INVITE without performing an emergency registration.
  • Figure 3B depicts the case where the user has also dialed an optional privacy prefix.
  • the P-CSCF 12 recognizes the dialed digits as being those of an emergency number and analyses these to determine the particular emergency sub- service type.
  • the serving network 1 1 may handle the request.
  • the initial request INVITE 302 from the UE 10 is rejected and at step 304 the serving network (P-CSCF 12) sends a response to the UE 10 rejecting the session.
  • the response sent to the UE 10 at step 304 indicates that the UE 10 should send the request again after performing an IMS Emergency Registration, using an emergency URN and additionally indicating the specific emergency subservice type corresponding to the dialed digits sent originally.
  • the response to the UE 10 may include an indication that it needs to include the privacy indicator (i.e. privacy prefix) in the re-sent request.
  • the UE 10 then re-sends the request, including all the appropriate information (i.e. emergency service URN including appropriate subservice type and optionally privacy indicator), after performing an emergency registration (not shown).
  • the serving network 1 1 then routes the request to the appropriate PSAP 17, in the normal way (steps 306 to 309b, which are the same as steps 35-38b of Figure 3A).
  • the P-CSCF 12 is able to determine from the dialed digits that the call relates to a specific emergency sub-service type.
  • the P-CSCF 12 adds an appropriate emergency indication and subservice type in the session establishment request sent to the E-CSCF.
  • the P-CSCF 12 after analyzing the dialed digits, determines that the call should be routed to a particular emergency sub-service, and so the P-CSCF 12 does not reject the session (as at step 304), but instead inserts the relevant information into the INVITE, including an emergency SOS indication in the URI and an indication that privacy is to be used for the session (if originally requested by the UE 10).
  • FIG. 4 is a block diagram illustrating the principal functional components of a User equipment (UE) 40 operable to communicate over an IP Multmedia Subsystem, IMS.
  • UE User equipment
  • the UE 40 includes an input/output by which signalling/messages are sent and received, a processor 44, a memory 46 storing data and programming instructions that are executed by the processor 44, and a user interface through communications are provided to and from a user.
  • the user interface includes a means by which a user can input digits when dialling.
  • the UE 40 is configured, when initiating an emergency session, to send a session initiation request to the IMS via the input/output 42.
  • the request includes, in a header field, the digits of an emergency number dialled on the user interface 48.
  • the UE may also include a dialled privacy prefix in the header field of the session initiation request.
  • FIG. 5 is a block diagram illustrating the principal functional components of an IMS network entity 50.
  • the IMS network entity 50 includes an input/output 52 over which signals are sent to/from other network entities and to/from a UE accessing the IMS network.
  • the network entity 50 also includes a memory 56 storing data and programming instructions and a processor 54 for executing the programming instructions, which cause the entity to analyse an emergency session initiation request received from a UE, which includes digits of an emergency number dialled at the UE, and to determine a corresponding emergency sub-service.
  • the network entity 50 is further configured to route the session establishment request to an emergency service centre of the corresponding emergency sub-service.
  • the network entity 50 may also be configured to recognise a privacy prefix in the digits, and to include a privacy indication in the session establishment request routed to the emergency service centre.
  • FIG. 6 is a flow diagram illustrating procedures performed in the IMS network, in this example at the P-CSCF.
  • the P-CSCF receives a session initiation request from a UE for an emergency session.
  • the P-CSCF determines if the request includes an emergency indication and the dialing digits used for making the call. If not, then at step 62 the P-CSCF sends a response back to the UE suggesting that it re-sends a request including the dialing digits of the number called, after performing an emergency registration. The process then returns to step 60 where the P-CSCF receives the re-sent request from the UE, which this time should include the emergency indication and the dialed digits.
  • the P-CSCF When the P-CSCF has received the request with the emergency indication and the dialed digits, then at step 63 it analyses the digits to determine the emergency sub-service to which the call should be routed and any other additional information, such as use of privacy, contained in the request. Finally, at step 62, the request is routed to the PSAP of the appropriate sub-service together with any additional information.
  • FIG. 7 is a flow diagram illustrating the procedures followed at the UE.
  • a number is dialed by the user of the UE.
  • the UE recognizes the number as an emergency number it performs an emergency registration (not shown) and at step 72 sends a request to the IMS network to initiate the emergency session.
  • the UE does not recognize the dialed number as an emergency number, then at step 73 and the UE sends a SIP request to the visited IMS network to initiate a session over a normal registration.
  • the session can continue over the normal registration (and by implication it is a normal session, not an emergency session).
  • a response rejecting the session is received from the IMS network together with a suggestion to retry following an emergency registration (because the IMS has recognized the URN in the request as an emergency URN)
  • the UE follows the instructions in the response, which includes performing an emergency registration at step 76 and then proceeding to step 72 to send the request to the IMS together with the dialing digits in a header of the request. If the User included a privacy prefix in the dialed number, then this will be included with dialing digits at step 72. Also, if a response from the IMS received at step 74 indicates the need to use privacy, the UE will include a privacy prefix in the request sent at step 72.
  • the P-CSCF as the entity executing the analysis of the dialed digits, and including the additional information before sending the request to the E-CSCF.
  • the analysis could be executed at another IMS network entity such as the E-CSCF instead.
  • the P-CSCF option is preferred as a base for dialed number analysis is already in place in the P-CSCF.
  • the P-CSCF could enrich the information provided to the UE within the XML schema included in the 380 response (step 24 in Figure 2).
  • This enriched information should include a request to the UE to add the specific type of emergency service in the Request URI and/or to use privacy preferences. This is a less-preferred option to that described above, which is seen as optimal as it does not place so many requirements on the UE.
  • Another optional feature is to provide indications regarding type of emergency service as known in the Home network.
  • the UE will initiate an emergency session appropriately (i.e. including the emergency service URN in the Request-URI). This is basically the goal of the concept of using the service URN; i.e. that a roaming user does not need to know the local emergency numbers.
  • the emergency call will be routed to a generic or default configured PSAP. Therefore, an extension of the procedures described above is to make it possible for the P-CSCF to include the information of the type of emergency service also in this case.
  • the P-CSCF is made aware of the relation of emergency numbers and emergency service types managed at the user ' s home network during the user ' s emergency registration procedure.
  • the S-CSCF should have this information configured locally and should include it in the Registration flow when it detects that the user is roaming.
  • the P-CSCF could keep this information on a per roaming partner basis. It will be apparent that the mechanisms described hereabove facilitate an effective PSAP selection and an appropriate handling of the emergency session according to user preferences when triggering the session which otherwise will not be possible in the scenarios addressed.

Abstract

Des modes de réalisation de la présente invention concernent un procédé d'établissement d'une session d'urgence entre un UE accédant à un réseau IMS et un centre de service d'urgence. Le centre de service d'urgence (ou PSAP) se met en relation avec un sous-service d'une pluralité de sous-services d'urgence. Une demande d'initiation de session, envoyée de l'UE à l'IMS, contient les chiffres composés d'un numéro d'urgence. Les chiffres du numéro d'urgence composé sont analysés de façon à déterminer un sous-service d'urgence correspondant. La demande d'établissement de session est alors routée jusqu'à un centre de service d'urgence du sous-service d'urgence correspondant.
PCT/EP2013/058794 2012-04-27 2013-04-26 Appels de service d'urgence améliorés WO2013160465A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261639167P 2012-04-27 2012-04-27
US61/639,167 2012-04-27

Publications (2)

Publication Number Publication Date
WO2013160465A2 true WO2013160465A2 (fr) 2013-10-31
WO2013160465A3 WO2013160465A3 (fr) 2013-12-19

Family

ID=48184214

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/058794 WO2013160465A2 (fr) 2012-04-27 2013-04-26 Appels de service d'urgence améliorés

Country Status (1)

Country Link
WO (1) WO2013160465A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014114777A3 (fr) * 2013-01-28 2014-10-30 Nokia Solutions And Networks Oy Traitement d'appel d'urgence non détecté d'équipement utilisateur
EP3073771A1 (fr) * 2015-03-26 2016-09-28 Deutsche Telekom AG Procédé et système pour une gestion améliorée d'appels d'urgence dans un scénario d'itinérance, réseau de télécommunications, programme informatique et produit logiciel
EP3048782A4 (fr) * 2013-09-18 2017-04-26 NTT DoCoMo, Inc. Système de communication mobile, équipement utilisateur, commutateur du service mobile et procédé de communication mobile

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014114777A3 (fr) * 2013-01-28 2014-10-30 Nokia Solutions And Networks Oy Traitement d'appel d'urgence non détecté d'équipement utilisateur
EP3048782A4 (fr) * 2013-09-18 2017-04-26 NTT DoCoMo, Inc. Système de communication mobile, équipement utilisateur, commutateur du service mobile et procédé de communication mobile
EP3073771A1 (fr) * 2015-03-26 2016-09-28 Deutsche Telekom AG Procédé et système pour une gestion améliorée d'appels d'urgence dans un scénario d'itinérance, réseau de télécommunications, programme informatique et produit logiciel
WO2016150998A1 (fr) * 2015-03-26 2016-09-29 Deutsche Telekom Ag Procédé pour une meilleure gestion des appels d'urgence dans un scénario d'itinérance, réseau de télécommunications, programme et produit de programme d'ordinateur
US10382931B2 (en) 2015-03-26 2019-08-13 Deutsche Telekom Ag Method for improved handling of emergency calls in a roaming scenario, telecommunications network, program and computer program product

Also Published As

Publication number Publication date
WO2013160465A3 (fr) 2013-12-19

Similar Documents

Publication Publication Date Title
EP2835027B1 (fr) Rappel d'un equipement utilisateur ayant effectué un appel d'urgence dans un réseau ims visité
US8478226B2 (en) Updating a request related to an IMS emergency session
US8305210B2 (en) Coding and behavior when receiving an IMS emergency session indicator from authorized source
US20090296689A1 (en) Privacy-Related Requests for an IMS Emergency Session
AU2011374206A1 (en) Methods and apparatuses for enabling an Single Radio Voice Call Continuity (SRVCC) access transfer of an emergency call back session
US8437342B2 (en) Providing location information in an IP multimedia subsystem network
US10009747B2 (en) Emergency contact notification in IP multimedia subsystem (IMS)
US8335485B2 (en) Call routing
US9277382B2 (en) Emergency service in communication system
EP2497259B1 (fr) Signalisation d'urgence dans un réseau de sous-système multimédia IP
EP2752039B1 (fr) Procédés et appareil pour déterminer la compatibilité du réseau avec d'autres supports pendant des sessions ims de secours
WO2011142703A1 (fr) Procédé permettant de configurer une connexion à partir d'un ue non enregistré dans un sous-système ims
WO2013160465A2 (fr) Appels de service d'urgence améliorés
CN102857892B (zh) 紧急呼叫接入方法及系统
EP2502431B1 (fr) Service d'urgence dans un système de communication
US9560509B2 (en) Emergency signalling in an IP multimedia subsystem network
US20230156122A1 (en) Emergency call handling in a telecommunications network
WO2010092147A1 (fr) Appel d'urgence efficace dans l'architecture ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13718591

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 13718591

Country of ref document: EP

Kind code of ref document: A2