System and method for managing emergency requests

ES 2 393 301 T3

DESCRIPTION

System and method to manage emergency requests.

BACKGROUND

The IP Multimedia Subsystem (Internet Protocol - "Internet Protocol") (IMS - "IP Multimedia Subsystem") is a standardized architecture for providing multimedia services and voice over IP calls to user equipment (UE - "user equipment") both mobile and fixed. The Session Initiation Protocol (SIP - “Session Initiation Protocol”) has been standardized and governed fundamentally by the Internet Engineering Task Force (IETF - “Internet Engineering Task Force”) as a protocol for the establishment and management of calls. based on IMS. As used herein, the term "UE" can refer to mobile devices such as mobile phones, personal digital assistants, handheld or laptop computers, as well as similar devices that have telecommunication capabilities. Such a UE may consist of a wireless device and its Universal Integrated Circuit Card (UICC - "Universal Integrated Circuit Card"), which includes a Subscriber Identity Module (SIM - "Subscriber Identity Module") application, a Universal Subscriber Identity Module (USIM - "Universal Subscriber Identity Module") application or a Removable User Identity Module (R-UIM - "Removable User Identity Module") application, or it may consist of the device itself, without such a card. The term "UE" can also refer to devices that have similar capabilities but are not transportable, such as landline phones, desktop computers, or terminal equipment boxes. The term "UE" can also refer to any hardware or software component that can terminate a SIP session.

Nokia Siemens Networks et al document: “Corrections for emergency procedures”, 3GPP Draft; C1-072991_24229CR1997R2_EMC1_REL-8_ Procedure, 3^RD Generation Partnership Project (3GPP -Third Generation Partnership Project), Mobile Compétanse Center; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedes; France, Vol. CT WG1, no. Sophia Antipolis, France; 20071112, November 12, 2007 (11-12-2007), XP050027161, discloses various change requests to 3GPP standards at the time of submission, which refer to IMS emergency services.

SUMMARY OF THE INVENTION

Aspects of the present invention are defined in claims 1, 2, 17 and 18.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this invention, reference will now be made to the following brief description, taken in connection with the accompanying drawings and the detailed description, in which the same reference numerals represent similar parts.

Figure 1 is a diagram of an illustrative IP network including a UE and a PSAP [Public Safety Answering Point - "Public Safety Answering Point"] in accordance with one embodiment of the invention.

Figure 2 is a diagram of an illustrative IP network including a UE and a PSAP in accordance with another embodiment of the invention.

Figure 3 is a diagram illustrating a method for a UE to respond to an emergency related message, in accordance with one embodiment of the invention.

Figure 4 is a diagram of a wireless communication system that includes operable user equipment for some of the various embodiments of the invention.

Figure 5 is an operable user equipment block diagram for some of the various embodiments of the invention.

Figure 6 is a diagram of a software or programming environment that can be implemented on operable user equipment for some of the various embodiments of the invention.

Figure 7 is an illustrative computer system suitable for some of the various embodiments of the invention.

DETAILED DESCRIPTION

It is to be understood from the outset that, while illustrative implementations of one or more embodiments of the present invention are provided below, the disclosed systems and / or methods may be implemented using any number of techniques, as are presently known. or to know. The invention should not be limited in any way to the illustrative implementations, drawings and techniques that are

ES 2 393 301 T3 illustrated below, including exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the accompanying claims, together with their full scope of equivalents .

In one embodiment, user equipment is provided. The user equipment includes a component such that, in response to an emergency request or request that is rejected, the component has been configured to receive a message containing information that associates the emergency request with an emergency center. combined.

In another embodiment, a network component is provided that includes a component such that, upon receiving an emergency request from a user equipment, the component is configured to determine whether the emergency request is related to a central station. combined emergencies and to send the user equipment a message containing information indicating that the emergency request has been related to a combined emergency center.

A user of a UE, such as an IMS-capable UE, can typically make an emergency call by dialing 911 (in North America), 112 (in most of Europe), 999 (in United Kingdom), 110, 118 or 119 (Japan), or some other specific number for emergencies. Such a call can be handled by a Public Safety Answering Point (PSAP), which may consist of an emergency call center or a system that can coordinate an appropriate response to the emergency. Any call made to a PSAP will be referred to herein as an emergency call. In this document, a PSAP can also be an emergency center or emergency centers.

In some cases, a UE may not realize that a call that was made was an emergency call. For example, a UE manufactured for use in North America may have been programmed to recognize that a 911 call is an emergency call. If such an UE is brought to a country where a number other than 911 is used for emergency calls, and the UE user dials that other emergency number, the UE may not recognize that the call is a call. of emergency. Unintended consequences can occur if the UE does not recognize that a call is an emergency call. For example, the UE may fail to provide relevant information to the PSAP, the UE may treat the call as a normal call and place it on hold or call waiting, the call may be blocked, or the UE may fail to another way to handle the call appropriately. In addition, the network may not apply special treatment, for example in a congested network or cell, and the emergency call that has not been recognized may not be subjected to emergency call procedures (for example, it may not receive priority) .

The present invention makes it possible to indicate to a UE that a call made by the UE was an IMS emergency call, by including in a message to the Ue an indicator that the call was an emergency call. The indicator may be included in a SIP message which may be, but is not, limited to a SIP 2xx or SIP 1xx message sent to the UE in response to an initial SIP request for a single or isolated transaction or dialogue, or to an unknown method (eg a SIP INVITE request) or similar message, which the UE sends when trying to set up the emergency call. Hereinafter, the term "SIP message" may refer to a SIP request (including, for example, a request for re-INVITATION or a request to refresh Target for a dialogue or an initial SIP request for a dialogue or isolated transaction, or an unknown method) or a SIP response. It should be appreciated that the request for the re-INVITATION method can only be sent when the conditions documented in the Request for Comments (RFC - “Request for Comments”) of the Internet Engineering Task Force (IETF - “Internet Engineering Task Force”) are satisfied. ") 3261. The SIP message including the indicator may be sent by the PSAP or by a component of a network through which the PSAP and the UE communicate with each other. Examples of such components are P-CSCF and E-CSCF.

The emergency indicator can be encoded in SIP using the following alternatives: a) SIP bodies such as “application / 3gpp-ims + xml” (application / 3gpp-ims + xml) have been used in the IMS to indicate additional information or guidelines for receiving UAs. It is possible to extend it to also indicate to the UE that, upon receiving the input of an INVITATION or similar request, the request has to be considered as an emergency call or a callback or PSAP callback, and that it has to resort to the functional capacity associated with calls of this type. This functional capability may include alerting the user by visual, audible, or other methods, as well as including positional information in the response, but is not limited to these functions. It may be necessary to define a new content layout header field value. b) A new SIP header may be defined, or an existing SIP header may be upgraded. The PSAP itself or the S-CSCF that handles the PSAP callback on behalf of the PSAP or another network element such as a handshake, or signaling gateway, may introduce an indicator. c) The indicator may be a new SIP header field. d) The indicator may consist of a new SIP header field value, for example a standard SIP URN [uniform resource name - “Uniform Resource Name”] indicating the role of PSAP (for example mountain rescue or coast guard, or a general 911) or

ES 2 393 301 T3 an emergency center function, or an emergency personnel function. e) The indicator may be a new URI field [Uniform Resource Identifier - "Uniform Resource Identifier"]. f) The indicator can be a new URI field value, for example, user = psap, where 'user' is a SIP URI field and 'psap' is a new value that can be placed within the header field of Contact. g) The normalized SIP URN can be placed in the P-Declared-Identity (“P-Asserted-Identity”) by the trusted domain in which the PSAP or emergency center or emergency personnel resides. h) The indicator may be contained in the FROM header field value, and the FROM header field value may be declared in accordance with RFC 4474 or RFC 3893. This solution is based on certificates.

As indicated above, it is possible to use various possibilities to indicate that a session is, in effect, an emergency session. It has been noted that the PSAP may be on a visited network, such as a VPLMN network, and that it does not have any trusting relationship with the home network, such as an HPLMN (Home Public Land Mobile Network). ). Assuming this is the case when the UE is establishing an emergency session that the UE does not recognize, or when a mobile communication termination request is received that contains an indication in the SIP message (e.g. 1xx or 2xx responses or a SIP target refresh request, or a similar message) referring to the request being a callback from the PSAP, the PSAP or the network can also send back a token or token that the UE will store. The network can provide this token when the UE registers with the iM Core Network (CN). The witness can be stored in a memory, which can be internal or removable. In the event that the emergency call is disconnected or turned off or the UE needs to be informed that it is requesting an emergency session, the network or the PSAP can include this token. Upon receipt of the token from the network, the UE can compare it to the shared token. If the witnesses do not match, the UE knows that the call is not related to an emergency.

The SIP “priority” header field set to “emergency” has so far not been used as a confidence indicator for an emergency call [RFC 3261]. The installed base of SIP UAs will have a divergent and different treatment for this headend, if there is treatment.

In the event that the PSAP callback or emergency call signaling response is received over a Circuit Switched network, The solution may allow establishing a correspondence relationship or correlation between Caller Category fields (“Calling-Party-Fields”) that is sometimes used to carry the indication of an emergency call in systems based on ISUP / TUP (Part of ISDN User - “ISDN User Part” / Telephony User Part - “Telephone User Part”). Typically, ISUP / TUP signaling information does not allow as fine granularity as the urn: service: sos identifiers defined in RFC 5031.

Figure 1 illustrates a system 10 that includes one or more components associated with an IMS network 120. A UE 110 can be any end user device or system that can connect to the IMS network 120. Examples of the UE 110 may include mobile phones, landline phones, mobile wireless devices (including digital, cellular or dual-mode devices), personal digital assistants (“personal digital assistants”), laptop / tablet-type / laptop-type computers. agenda or handheld, and desktop computers. The UE 110 may communicate via the IMS network 120 with a PSAP 130, which may consist of a 911 system or another central or emergency call system.

The IMS network 120 can include any well-known set of components, such as base stations and other radio transmitting and receiving equipment that can promote an IMS-based connection between the UE 110 and the PSAP 130. Other components that may be present in the IMS network 120 but not shown include a P-CSCF (Representative Call Session Control Function), which can be the first point of contact. for UE 110; a CSCF (CSCF in Service - “Serving CSCF”) that can carry out session control, uploading and downloading of user profiles as well as other functions; an E-CSCF (Emergency CSCF - “Emergency CSCF) that can provide session control functions for the PSAP 130; and other well-known components for starting and maintaining IMS-based sessions.

To make an emergency call, the UE 110 may send an initial SIP request for an isolated dialogue or transaction, or unknown method (eg, a SIP INVITE request) 140, or a similar invitation message, to the PSAP 130 through the IMS network 120. The PSAP 130 typically responds to the invitation message 140 with a 1xx SIP or 2xx SIP response message 150 (eg, SIP CONFORMITY 200 - "SIP 200 OK"), or a similar response message. Alternatively, the PSAP 130 may transmit a target refresh request (eg, a re-INVITE request). Standard SIP procedures can then be followed to establish the emergency call between the UE 110 and the PSAP 130.

In one embodiment, the response message 150 includes an indicator 160 indicating that the call made by the UE 110 was an emergency call. The indicator 160 may be a bit, a tag or token or some other data element that is recognizable by the UE as a designation that a call made by the UE 110 was an emergency call (for example, emergency service URNs as specified in RFC 5031, such as urn: service: sos [urn: service: sos], urn: service: sos.animal-control [urn: service: sos.control-animal],

ES 2 393 301 T3 or the urn: service: sos.pólice [urn: service: sos.policía], if it is determined that the call that was made can be classified as, for example, a call from urn: service: sos, a call from urn: service: sos.animal-control, or a call from urn: service: sos.police). When the UE 110 receives the response message 150 including the indicator 160, the UE 110 identifies that the call it made was an IMS emergency call and can then take the appropriate actions and appeal or call upon the functional capability for a call. of emergency. One of the actions that the UE 110 can take is to indicate to the user of the UE the nature of the initial call. That is, the UE 110 can alert the user that the call was an emergency call. The alert may consist of a message that appears on the UE 110's display screen, a visual or audible alert , or some other type of environmental status or indication of the nature of the call. Other actions taken by the UE 110 may involve the transmission of a SIP request message 170, such as a SIP CONFIRMATION ("SIP ACK") or "SIP RACK" message, or any subsequent SIP request part of the dialogue. (including target refresh requests) or request for new dialogue, in such a way that the dialogue request uses the SIP Target Dialog header field ("SIP Target-Dialog") with a set of values ​​identical to the value of the corresponding dialogue identifier for the emergency session. In the case of sending a request for a new dialogue message 170 with the SIP Target Dialog header field set, this can indicate to the recipient that the sender is aware of an existing dialogue with the recipient, either due to because the sender is on the other side of the dialogue, either because he has accessed the dialogue identifiers, and the recipient can then authorize the request based on this finding. Within the limitations of the SIP, some of these messages can include information within the request as part of the information available to the PSAP 130 in the case that the recipient is the PSAP 130. As already mentioned, the message 170 can be a SIP target refresh request, a SIP UPDATE, a SIP re-INVITE message 170, or a similar (confirmation) message (eg, SIP PRACK). Message 170 may include information 180 about UE 110, which will be described in detail later. Due to limitations in the SIP protocol, information 180 can be spread across multiple SIP messages; For example, certain information may be in SIP PRACK requests, true in responses to requests originating from the PSAP or the network, or SIP UPDATE requests (“SIP UPdAtE”), and some more in other refresh requests SIP target. The information 180 may be intended for the PSAP 130 or one or more components of the IMS network 120. The information 180 may optionally include a label or other indicator indicating that certain information related to an emergency, such as identification, network access, or location information, is not to be shared (for example, with the PSAP 130 ). If one or more privacy flags are set, the network might still be able to use the information related to an emergency for routing purposes or to provide an anonymous callback or callback.

In another embodiment, a policy or criteria can be stored in the UE 110. The criteria or criteria can be used to determine whether to allow the inclusion of one or more indicators to request privacy when a PSAP makes a callback or a callback. , or if privacy is allowed when emergency-related information is provided in response to a return call from the PSAP. Criterion can be queried when the UE 110 wishes to disclose information that is privacy sensitive, such as location, but is not limited by location. The criteria can be user-supplied, operator-supplied, or both. When the information is provided by both the user and the operator, the operator may provide a default criterion, but the user may be able to override this criterion if he wishes to do so. The criteria can be stored in memory, which is internal or external with respect to the device.

It is possible that the criterion / preference may be established in a way that is contrary to the regulatory requirements of the PSAP. For example, the UE 110 may come from a country where it is able to choose whether or not to provide user-related or event-related information, and the criteria / preference may be set such that the information will not be provided. Alternatively, the criteria / preference may be set such that the information can be provided (eg, for the purposes of determining the closest PSAP), but a request may be made that the information not be delivered. The UE 110 can subsequently go to a country where, by law, the information must be provided if it is available. In such cases, the network may signal to the UE 110 that the preference has been ignored or relegated and that the information is to be provided. This notification of relegation can be indicated as a symbol or token within a message from the network. For example, a SIP message can contain a token that has been encoded as a new feature tag, a new URI parameter, an XNL body, an SDP [digital signal processor - “signal digital processor”] parameter, or a similar encoding feature. The witness may also require the property to be trusted by the UE 110.

The following illustrates one possible embodiment of how the UE 110 can behave.

The basic procedure will be:

Criterion / Preference Setting

Message received from the network, containing a relegation token

ES 2 393 301 T3

Consult preference / criteria

Allow to provide position information

Not allowed; determine if indicator has been received

Received witness ascertains the authenticity of the witness and, if valid, provide positional information

If the received token is false, provide indication to the network that a false token has been received; not providing position information.

The token can be carried on a call from PSAP 130, such as a SIP INVITE. Alternatively, the token may be provided at the time the UE 110 performs its registration with the network 120, such that, in the IMS, the token may be provided in a 200OK (CONFORMITY200) message in response to a registration of emergency. With 200OK, if the token has been encoded as a new feature tag, a new URI parameter, or an XML body, the token can be a secure token. In an LTE / SAE network, the 200OK message can be transmitted in response to a request to latch onto the network or as part of the UE 110 authentication sequence.

Another embodiment is that the VPLMN criteria can be broadcast in a system message indicating the behavior of the UE in case it receives a callback or emergency callback.

The facilitation of the criteria can be carried out in one of the following ways, but not limited to them: OMA DM, CP, OTA, owned or others. At the time of being contributed, it is possible to use any of the following means of transport: Cellular broadcasting (“Cell Broadcast”), SMS, USSD, MBMS, generic IP conduction (“Generic IP pipe”) or others.

The criteria can be stored in an internal or external memory. External memory can be PC Card PCMCIA [PCMCIA PC card], CompactFlasch I CF-I, CompactFlash II CF-II, SmartMedia SM / SMC, Memory Stick MS [memory stick MS], Memory Stick Duo MSC, Memory Stick PRO Duo MSPD, Memory Stick PRO-hG Duo MSPdX, Memory Stick Micro M2, Multimedia Card MMC [MMC multimedia card], Multimedia Card RS-MMC [rS-MMC multimedia card], MMCmicro Card MMCmicro [MMCmicro card], Secure Digital Card SD [SD secure digital card], SxS SxS, Universal Flash Storage UFS [UFS universal flash storage device], miniSD Card miniSD [miniSD card], microSD Card microSD [microSD card], xD-Picture Card xD [xD image card], Intelligent Stick iStick [iStick smart pen ], Serial Flash Module SFM [serial flash module SFM], μCard μCard [micro card μCard], NT Card NT NT + [NT NT + card], USIM, R-UIM, etc., although it is not limited by these.

In one embodiment of the criteria information, there will be a file in removable memory consisting of eight bits for each file. Bit 1 (the Least Significant Bit) can be set to 1 to indicate that position information is to be provided, or to 0 to indicate that information is not to be provided. position. The remaining seven bits can be reserved (RFU). The user's preference file can be under the control of the PIN [Personal Identification Number - “Personal Identification Number”] (that is, the user can, after entering the PIN, control the content of the file), and the file The operator may be under the control of ADM (Administrative), thus preventing any third party other than the administrator (the card issuer, usually the holder) from altering the content of the file.

In various embodiments, the criteria can be implemented in different formats. An example of a format for the criteria is provided below, but the formats should not be limited by this example, since other formats are contemplated.

/ <X> / Emergency Location Policy upon PSAP call back / (/ <X> / Emergency Location Policy upon PSAP call back /)

The Emergency Criteria specification indicates whether the UE provides emergency information or not for an emergency callback.

• Occurrence: One (Occurrence: One) • Format: boolean (Format: bool) • Access types: Get, Replace

ES 2 393 301 T3 (Access Types: Get, Replace) • Values: 0, 1 (Values: 0, 1)

-UE provides emergency information.

-UE does not provide emergency information.

<Node>

(<Node>) <NodeName> criterion Emergency Position </NodeName>

(<NodeName> Emergency Location policy </NodeName>) <PropiedadesDF>

(<DFProperties>) <AccessType>

(<AccessType>) <Get />

(<Get />) <Replace />

(<Replace />) </TypeAccess>

<DFFormat>

<boolean />

</DFFormat>

<Occurrence>

<One />

</Occurrence>

<TitleDF> criterion Emergency Position </ TitleDF>

(<DFTitle> Emergency Location policy </DFTitle>) <DFType>

(<DFType>) <MIME> text / full / MIME>

(<MIME> text / plain> / MIME>) </DFType>

</PropertiesDF>

(</DFProperties>) </ Node

As mentioned above, when the UE 110 receives the response message 150 that includes the flag 160, the UE 110 can transmit information 180 about itself to the PSAP 130. If the criteria allow, a chunk or fragment of the information 180 that the UE 110 can include in the SIP message 170 are the public user identities of the UE (such as the Tel URI, the SIP URI, or the International ISDN Number 7

ES 2 393 301 T3 of Mobile Station (MSISDN - “Mobile International ISDN Number”)), or some other identification symbol. The inclusion of such information may be subject to discretion or may be accompanied by an indicator that private information is not being shared with the PSAP or emergency center, or with network elements that are not trusted. Public user identities may be in GRUU format or may contain sufficient information that a callback or callback is possible by Circuit Switching technology, for example, in URI format. The PSAP 130 may use the identifier to make a call back to the UE 110 if necessary, as described below. Another piece of information 180 that the UE 110 can transmit in the confirmation message 170 is the type of access that the UE 110 is using. For example, if the emergency call is being made over a local area network (LAN - " local area network ") wireless, the UE 110 can include this fact in the information 180, as well as a cell ID, a line ID and / or a wireless LAN access node ID. During the dialogue, the attachment points to the IP Connectivity Access Network (IP-CAN - "IP-Connectivity Access Network") of the UE may change (for example, the UE connects to different cells). The UE may populate the P Access Network Information header ("P-Access-Network-Info") in any request or response, within a dialogue for which the transmission of such information is supported (eg, excluding CONFIRMATION requests (“ACK”) and CANCEL requests (“CANCEL”), with the point of attachment at that moment to the IP-CAN (for example, the information of the cell in progress at that moment).

If the UE 110 is aware of geographical position, for example by using a global positioning system (GPS), the UE 110 can include its position as another piece or fragment of the information 180, such as the Global Cell Identity (CGI - “Cell Global Identity”), the Service Set Identifier (SSID - “Service Set Identifier”), waypoints such as reference points or landmarks, as well as the signal intensity of the adjacent cells, with the corresponding CGIs, although it is not limited by these. In case the UE 110 is not aware of its geographical position, data regarding the position is not included in the information 180. If a URI (uniform resource identifier - "uniform resource identifier") of GRUU (UA (user agent - "user agent") capable of being globally routed - "globally routable UA") is associated with the UE 110, the GRUU of the UE can be included as another piece of information 180. Depending on the user's privacy settings, the GRUU can be a P-GRUU or a T-GRUU, although a public GRUU (P-GRUU - "public GRUU") is preferred over a temporary GRUU (T-GRUU - " temporary GRUU ”).

Other items that may be included in the information 180 may include the capabilities of the UE 100, the radio access technology being used by the UE 110, the battery life of the UE 110, the signal strength and the identity of the network (for example, CGI, SSID, SID). The UE 110 may also call upon what is commonly known as electronic call capability ("ecall") to be sent to the PSAP 130.

Before the emergency request reaches the PSAP 130, it can be handled by one or more components of the IMS network 120. Examples of such components are the P-CSCF, E-CSCF, AS and IBCF (Interconnect Border Control Function). An IMS network component, such as the PCSCF, AS, and E-CSCF, can inspect all requests to determine if they are related to emergencies. If a request is determined to be related to an emergency, based on the settings and regulatory criteria, the network component can determine to reject the request or update the request, or include the emergency call indicator 160 in a SIP response that is sent to UE 110. The update of the request can be carried out if the UE provides a T-GRUU and the settings of the network operator criteria (eg in the P-CSCF) indicate that the public user identities should be provided. In such a case, the T-GRUU can be replaced by the GRUU. Furthermore, the update of the messages to be routed to the PSAPs can be carried out if the message contains header fields of Preferred-Service-P (“P-Preferred-Service”), header fields of Service-Declared-P ( "PAsserted-Service"), header fields of Accept-Contact (“Accept-Contact”) that contain one or more IMS Communication Service Identifier (ICSI) values ​​(encoded as specified in subclass 7.2A.8.2 of the TS [Technical Specification - “Technical Specification”] of 3GPP 24.229), or one or more IMS Application Reference Identifier (IARI) values ​​(encoded as specified in subclass 7.2A.9.2 of 3GPP TS 24.229) that are related to the request in a g.3gpp.app_ref feature tag. Note that the network element may be playing the role of Mutual Support User Agent (B2BUA - “Back to Back User Agent”) or of representative when updating these SIP requests or responses. It is to be appreciated that if the network element is an AS, there is a need for a new reference point between the AS and at least one of the IBCF, the E-CSCF or the P-CSCF, since, at that time, There is only a single reference point for service control between the AS and the S-SCSF or I-CSF. The header fields of Service-Preferred-P as well as the header fields of Service-Declared-P should not be forwarded to the PSAP or the emergency center. The Accept-Contact header fields must be primed for ICSI values ​​and for IARI values, as they can cause interactions when a SiP user agent is selected that terminates the PSAP session. If the header field of Accept-Contact contains media feature labels g.3gpp.app_ref, these and their values ​​will be removed. If the Accept-Contact header field contains IARII tags of media characteristics g.3gpp.app_ref, these and their values ​​will be removed.

ES 2 393 301 T3

In other words, what has been called an "update" may include changing the GRUU from a temporary GRUU to a public GRUU. This is done because a temporary GRUU is invalid if the UE has disconnected and has to re-register. A PSAP cannot make a call back to a temporary GRUU after the UE has unregistered and re-registered. Public GRUUs, on the other hand, have the property that they are capable of being forwarded even after the UE deregisters and registers again (which makes a call back from the PSAPD to that public GRUU have a higher probability to complete). The "update" may also include non-propagation of ICSI or IARI feature labels, P-Preferred-Service header fields and / or P-Declared-Service header fields. The presence of such tags or fields can distort the handling of the request in the PSAP and cause the request to be routed based on services that are supported in the UE, rather than, for example, on the geographic proximity service. and type requested. Since there is typically no S-SCSF and no Application Server (Multimedia Telephony) in the session path between the UE, the P-CSCF, the E-CSCF and the PSAP, these services those supported by the UE are generally not available during the emergency call. Thus, signaling them as part of an emergency request (even when the UE has not realized that it is an emergency call and includes ICSI or IARI feature labels, Service-Preferred_P header fields) and / or header fields of Service-Declared-P, because it believes that the request it makes is a normal request) does not serve any purpose and can only distort / have the result that the requests are routed to other PSAPs or PSAP User Agents other than those determined based on the position, in the type of service requested and in the procedures of RFC 3261. In a worst-case scenario, if a PSAP User Agent registers its support for such services, it may receive a higher load of requests for emergency services than other PSAP User Agents, possibly leading to a delay in the response to the emergency.

In embodiments where a component of the IMS network 120 rejects the request for emergency service, it may respond with a 3xx SIP message, such as message 300 (Multiple Options), 301 (Permanently Moved), 302 (Temporarily Moved), 380 (Alternate Service), or a 4xx response from SIP or a 6xx response from SIP. A SIP 380 (Alternate Service) is preferably used to indicate that the UE should try another access technology, such as CS, or use / create another secure registry / context, such as the context created by the emergency registry. The message can also be used to inform the UE not to use the present context (which may have been created as a result of an emergency registration).

The following are cases where the network may have been configured to reject the request: a) the network is not capable of handling emergency sessions; b) the IM CN subsystem to which the P-CSCF belongs is not capable of handling emergency sessions; c) due to local criteria, the network does not take over emergency sessions; d) the network only handles certain types of emergency session requests; e) the UE is in roaming displacement; f) the P-CSCF is on a different network than the UE's home operator network; g) the network does not support emergency sessions for some geographical location where the UE is located or the IP-CAN to which the UE is hooked.

It is to be appreciated that a 3xx redirect response may be valid or routable only on the currently hooked network. For example, the urn: service: sos.animal-control may be valid in the address book only for some networks that the UE 110 can hook into / register with. The use of an address from the address book may be dependent on the operator or the region to which the UE 110 is hooked / registered. A 3xx response that forces the UE to use another address for this request related to an emergency or a request that has been determined not to be related to an emergency, should not be followed by a simple change of the corresponding entry in the book address book, if present in the address book.

Two examples can illustrate cases where the network rejects the request because the emergency session request type is not supported. In the first example, RFC 5031 defines the urn: service: sos.animal-control as follows: animal control enforces laws and ordinances pertaining to animal control and management, investigates cases of animal abuse educates the community in responsible pet ownership and wildlife care, and provides shelter and care for homeless animals, among other animal-related services. In some jurisdictions, a request for urn: service: sos.animal-control may not be classified as an emergency in the sense that it is subject to network and operator emergency procedures (for example, allowing or disabling a request to the urn: service: sos.animal-control when the UE has not registered or does not have insufficient credentials). If configured this way, the network can either reject it with an indication that the call is not really an emergency call, or it can reject it with an indication that the call is not an emergency call and offer alternative steps for its execution, such as offering a different URI to contact and / or a different Circuit Switched (CS - “Circuit Switched”) network address, such as a string of digits. It is to be appreciated that since emergency service URNs are not routable and are not E.164 numbers, the UE may not be able to proceed if it lacks knowledge of routable addresses or numbers. In those jurisdictions, it would be inappropriate for emergency procedures carried out by the UE (as specified in 3GPP TS 24.008) and a UE not to automatically contact, for example, “911” or “112” at receive a rejection when they contact, for example, with the urn: service: sos.animal-control.

ES 2 393 301 T3

Note that a CS-enabled UE may have received a list of local CS emergency numbers (eg, received as a result of the Location Update procedure). A UE may indicate the type of emergency service requested in a CS emergency request and be connected to the requested PSAP using procedures of the 3GPP TS 24.008. For example, there is the following table:

Table 10.5.135d / 3GPP TS 24.008: Service Category information element

Emergency Service Category Value (octet 3)

The meaning of the Emergency Category Value is deduced from the following adjustments (please see 3GPP TS 22.101, clause 8):

Bit 1 Criterion

Bit 2 Ambulance

Bit 3 Fire Department

Bit 4 Marine Guard

Bit 5 Mountain Rescue

Bits 6, 7, 8 are spare space and return to "0"

The mobile station may set one or more bits to "1".

If more than one bit is set to “1”, routing to a combined Emergency Center (eg ambulance and fire department in Japan) is necessary. If the MSC [Mobile Switching Center - "Mobile Switching Center"] cannot match the category of service received with any of the emergency centers, it will route the call to a default emergency center defined by the operator.

If no bit is set to "1", the MSC will route the Emergency call to a default emergency center defined by the operator.

However, there is currently no match for the urn: service: sos.animal-control. A mapping or correlation relationship can be carried out for some other emergency services as defined in RFC 5031 (for example, urn: service: sos.police), by setting the corresponding bit of the Emergency Category Value (for example, urn: service: sos.police). For example, the urn: service: sos.police corresponds to Bit 1 of the Emergency Service Category Value, the urn: service: sos.ambulance [urn: service: sos.ambulance] corresponds to Bit 2 of the Emergency Service Category Value, the urn: service: sos.fire [urn: service: sos.fuego] is corresponds to Bit 3 of the Emergency Service Category Value, the urn: service: sos.marine [urn: service: sos.marino] corresponds to Bit 4 of the Emergency Service Category Value, and the urn: service: sos.mountain [urn: service: sos.montaña] corresponds to Bit 5 of the Emergency Service Category Value). The urn: service: sos.animal-control, urn: service: sos.physician [urn: service: sos.physician], urn: service: sos.poison [urn: service: sos.veneno], urn: service: sos .gas [urn: service: sos.gas] and others can be correlated with an Emergency Service Category Value in which no bit has been set to "1", which causes the call to be routed to an emergency center by default defined by the operator. Alternatively, for requests for which no PSAP is supported on the network, the UE can be instructed to either make a normal SIP request (using 2GPP TS procedures 24.228) or establish a normal CS call (using procedures of 3GPP Ts 24.008). The network can achieve this by not indicating an alternate address that cannot be mapped to the Emergency Service Category Value (that is, not one of the URNs in urn: service: sos for which a map has been normalized). When an emergency request is received from the PSAP but the PSAP cannot take over the request and returns a SIP 380 or similar message, if there is a correlation in the UE from the URN given to a Service Category Value of Emergency, a call to that PSAP CS E.164 number will be established automatically.

In the second example: the P-CSCF can determine that the emergency request has been made to the urn: service: sos: police. However, for example in the Netherlands, contacting the police does not by definition guarantee the activation of emergency procedures. Instead, a special number other than "112" has been set: 0900-8844. Other examples are “19” for Police (Albania), “112” (Police and Ambulance (Italy)), “112” (general emergency call, all categories (Sweden)), “115” ( Fire Department (Italy)), “144” (Ambulance (Austria)), “* 377” (local police station or Department of Public Safety office, non-emergency race assistance, in Texas). Such a number can be a preferred service. It might be inappropriate for you to automatically contact the UE, for example “911” or “112” if the network

ES 2 393 301 T3 rejects the call to the urn: service: sos.police, and it could be inappropriate for it to automatically contact the network, for example, 0900-8844 as a normal call, since the user could then, inadvertently, automatically receive preferred category charges. The P-CSCF can provide alternate steps such as providing a string of digits, eg 0900-8844, in a SIP 3xx response. However, the string of digits may be part of a message indicating that the string of digits is to be displayed visually and / or that a text message is to be displayed to indicate the nature of the call that has been made and the nature of the number provided.

In one embodiment, the P-CSCF has configurable lists with roaming partner emergency service identifiers, which indicate handling by each emergency service identifier. When a request is rejected, a configurable list of alternative emergency services URIs may be included in the response, eg, signaled as part of the SIP Contact header field. These alternative emergency services can be annotated with alphanumeric information that can be displayed visually, for example, when flagged as part of the SIP Contact header field. Alternative emergency services can also be identified, using an XML body with XML elements and XML attributes, so that they are presented visually only if required.

In some cases, the network may reject a request made to a conventional emergency center or perhaps a combined PSAP or a combined emergency center, where a combined PSAP or a combined emergency center is a PSAP that accepts calls from multiple types of emergencies. For example, a combined PSAP or combined emergency center can accept calls regarding police emergencies, fire emergencies, ambulance emergencies, and other types of emergencies. A request made to a combined emergency call center may include bits, flags, or other indicators (such as a PSAP address (for example, "119" in some countries) or part of a PSAP address) that specify the responding entities to the emergency to which the request is to be directed. For example, if a request is made for the fire service and ambulance service, the request may include a “fire” badge and an “ambulance” badge. By reading these badges, the combined emergency central can route the request to the appropriate emergency response entities.

In one embodiment, the UE may send a request to an emergency center or perhaps a combined emergency center, and the UE is not aware that the request is related to an emergency center and, for various reasons, the network rejects or does not handle the request in some other way. In this case, the network can identify the request as related to a combined emergency center. The network then sends a message to the UE containing information indicating that the request relates to a combined emergency exchange. The UE can then use this information to send the request to a combined emergency center or to a combined PSAP or other emergency center or alternative PSAP. In some embodiments, the alternate PSAP is in the circuit-switched domain. The information contained in the message that the network sends to the UE may include information identifying the combined emergency exchange, bits, flags, or other indicators that specify the emergency response entities to which the initial request has been routed. Upon receiving this message, the UE may send an alternate request to the alternate or combined PSAP, and may include bits, flags, or other flags so that the alternate PSAP can route the alternate request to the appropriate emergency response entities. The bits, flags, or other flags may be the bits specified in Table 10.5.135d of 3GPP TS 24.008.

More specifically, a network element such as a P-CSCF checks whether the requests it receives contain emergency service identifiers. The P-CSCF may determine that an appropriate emergency call request has been made, but that the local network does not support the PSAP for the requested emergency (for example, if a request has been made to urn: service: sos.gas ). The P-CSCF may also determine that the UE has failed to recognize the request as an emergency call request. The P-CSCF may then have been configured to reject the request and provide enough information for the UE to route the request to an alternative answering point, since the user of the UE is under the impression that it is reporting a situation that requires attention. However, a PSAP / emergency center is not supported on the network for such an emergency.

Today, in the CS network, Service Categories have been assigned to the Police, Ambulance, Fire Department, Marine Guard and Mountain Rescue. However, in the event that a 380 (Alternative Service) is returned by the P-CSCF, one of the options the UE has is to initiate an emergency call in the CS domain using appropriate access technology specific procedures. . However, the UE, upon receiving the 380, still does not know if the initial request with the emergency service identifier that was not recognized by the UE, was destined to a default PSAP, to a Police PSAP, to a Ambulance PSAP, Fire Department PSAP, Combined PSAP, etc.

In one embodiment, in the event that the P-CSCF has been configured to recognize the request as corresponding to a particular type of emergency, the P-CSCF then informs the UE that the request was for that type of emergency. In addition, if the P-CSCF rejects the request because the requested emergency type is not supported, the P-CSCF may provide additional information. The UE can be upgraded to take over

ES 2 393 301 T3 380 messages (Alternate Service) for unacknowledged emergency requests for particular PSAPs. When trying to connect to a particular PSAp using the CS Domain, a mapping relationship can be established with the correct Emergency Category Value (see 3GPP TS 24.008, subclause 10.5.4.33). The P-CSCF can be enhanced to reject requests for emergency services to unsupported PSAPs, eg urn: service: sos.gas, based on local criteria.

The following is an example of an XML body that indicates to the UE that an emergency service request has been detected and instructs the UE to connect to the particular PSAP.

<ims-3gpp version = "...">

(<ims-3gpp version = "...">) <alternative-service>

(<alternative-service>) <alternative type = "tel: 119; telephone-context = + 81 (<type alternate =" tel: 119; put-context = + 81) urn: service: sos.fire-urn: service : sos.ambulance ”>

<emergency />

(<emergency />) </type>

(</type>) <reason />

(<reason />) </alternative-service>

</ims-3gpp>

In Table 10.5.135d of the 3GPP TS 24.008 mentioned previous proposals are presented that indicate the recognition by the IMS network of a request to a combined emergency center and the correlation from the value indicated that represents a combined emergency center, up to one or more bits present in Table 10.5.135d of 3GPP TS 24.008. The 3GPP TS 24.008 is the GSM / UMTS specification, and the GSM / UMTS supports different normal Settings versus an Emergency Setting (i.e. without digit dialing), In CDMA [Division Multiple Access in Code - “Code Division Multiple Access”], from “IS-2000 release A” onwards, there is also a field called GLOBAL_EMERGENCY_CALL (GLOBAL_EMERGENCY_CALL) that can be included in an Origin message in order to make such a call independent of a dial string. The protocol revision level that supports this is 7 and higher. Previous UEs, with a "protocol revision level currently in use that is less than 7", did not distinguish between emergency calls and normal calls. In this way, such UEs may have to correlate, say, "tel: 119; put-context = + 81" with 119 and dial 119 as a normal call.

Also, CDMA does not support routing to Combined Emergency Centers or Specialized Emergency Centers (for example, only for “police”). 3GPP2 only documents the routing mode to PSAPs by default. Thus, in an alternative embodiment, a CDMA UE detects that the IMS network has determined that the initial request to the IMS network was for a non-default PSAP. The CDMA UE can then, instead of sending an emergency call with the GLOBAL_EMERGENCY_CALL set to "1" (instead of routing it to the PSAP by default), support one or more of the following possibilities: an emergency call with the Global_Emergency set to "1" and, in the address field, a phone number: say 119, if "the protocol revision level currently in use is NOT less than 7"; an emergency call with Global_Emergency set to “0” and, in the address field, a phone number: say 119, if “the protocol revision level currently in use is NOT less than 7”; and / or an emergency call with a phone number in the address field: for case 119, if "the protocol revision level currently in use is less than 7".

ES 2 393 301 T3

Current proposals add an "alternative attribute" to the existing XML Schema. In one embodiment, the alternative attribute includes several alternative addresses, one of which (the last element) can be an indicator that encodes the need to route the call to a combined emergency exchange 'mixing' together emergency services URNs: for example, “Urn: service: sos.ambulance-Urn: service: sos.fire”. Alternative embodiments may encode the alternative addresses differently in the SIP response, for example in the Contact header fields or in a new separate XML. Another alternative may be a different encoding, such that the pointer will remain a URN or a tel URI or a SIP URI. For example, urn: service: sos.fire.ambulance (for example, 'tap' emergency subtypes together).

An emergency number can be interpreted in different ways in different countries. For example, the address "119" can be translated to police + navy in one country and fire-ambulance in another. If both countries have operators that are roaming partners with a roaming user's home network, the UE or the network needs to recognize the address as an emergency request, but the network may not know which translation is intended for the 119. In one embodiment, in such a situation, the network selects one of the translations after further interaction with the UE.

Such additional interaction includes, for example, the sending of information by the network to the UE indicating that the address is associated with different types of emergencies in different jurisdictions. Such information includes a correlation between the address, a telephony context, and one or more types of optional emergency identifiers, and is known as alternate address information. An emergency identifier type is optional in case the telephony context does not correlate with an emergency type but "emergency" or "urgent" alternatives are known.

The alternate address information comprises a mapping between an address, a telephony context, and one or more types of optional emergency identifiers. The address indicates the emergency number dialed, which can be a telephone number such as '119', for example. The telephony context indicates a relevant state of the U, such as the position or country in which the UE is located, and can be a number or a string such as '+81', the text string 'Japan' (Japan ), a combination of a number and a string or other information that can be resolved or defined for a position, for example. The text string (eg 'Japan') can be received in multiple languages ​​and in multiple character encodings, including Japanese and other non-ASCII character sets. The type of emergency identifier (say 'police', 'fire' or 'ambulance', for example) is extensible and indicates the type of emergency service associated with the address for a given telephony context. The country or region in which emergency services are applied can be identified using applicable ITU, IANA, ISO codes, although, in some cases, certain emergency services are provided in an area that does not coincide with a “country” or region, in which case an ITU, IANA, ISO standard code may not have been assigned. Some of the ITI, IANA, ISO or other applicable codes for coding positions, countries or regions are extensible, such as ISO 3166-1 and ISO 3166 / MA.

The alternate address information may additionally contain a reason element, such as a <reason> XML element (as described, for example, in the 3GPP IMS XML body as defined in the 3GPP TS 24,229), for example. A reason element is populated or populated with information that can be presented to a user of a UE to identify, for example, the location, the types of emergency services supported, and / or the service numbers of emergency. Such a reason element can be conveyed in an application / 3gpp-ims + xml enhancement body (as defined in 3GPP TS 24.229). The content of a reason element can be specified in multiple languages, using the xml: lang attribute. For example, a reason element can be presented by the following body (which corresponds to an improved mL Scheme according to 3GPP TS 24.229).

<ims-3gpp version = "2">

<alternative-service>

<type><emergency/> </type>

<reason lang = "in"> emergency </ reason>

<reason lang = "nl"> noodgeval </reason>

</alternative-service>

</ims-3gpp>

The network sends such alternative address information to the UE, for example, as part of the body of a SIP 300 (Multiple Choice) response, in one or more headers of the Contact field of the SIP 300 (Multiple Choice) response or in another 3cc response from SIP (for example, a 380 (Alternate Service) response from SIP.

The following is an example of an XML body included in a response to a request from a web service.

ES 2 393 301 T3 emergency that indicates to the UE that an address ('119', for example) is associated with one type of emergency or a combination of different emergency types ('fire', 'ambulance' or 'police', for example) in different telephony contexts ('+81', for example). Note that the emergency types are obtained from the emergency service URN of RFC 5031 (that is, the urn: service: sos and its subtypes, police, ambulance, gas, fire, etc., where <police /> can be correlated with the ballot box: service: sos.policía, etc.). Note that the emergency type <sos /> can be mapped to the generic service URN urn: service: sos. Note that <sos /> can be mapped to the dial string "112" or to the emergency call setup in the GSM / UMTS CS domain, with all the Emergency Service Category Value bits set to '0' (see Table 10.5.135d / 3GPP TS 24.008: Service Category information element), in such a way that the call is routed to a default emergency center defined by the operator or equivalent signaling is performed in other CS domain technologies such as CDMA. Note that <police /> can also be correlated with the setting of bit 1 of the Emergency Service Category Value when making a GSM / UMTS emergency call through the CS domain.

<ims-3gpp version = "...">

<alternative-service>

<type>

<emergency />

</type>

<reason />

<action>

<alternative>

<URIalternative> tel: 112; telephony-context = + 57 </URIalternative>

<sos />

</alternative>

<alternative>

<URIalternative> tel: 123; telephony-context = + 57 </URIalternative>

<ambulance />

<fire />

<police />

</alternative>

<alternative>

<URIalternative> tel: 119; telephony-context = + 81 </URIalternative>

<URIalternative> tel: 119; telephony-context = + 82 </URIalternative>

<URIalternative> tel: 119; telephony-context = + 886 </URIalternative>

<ambulance />

<fire />

</alternative>

<alternative>

<URIalternative> tel: 119; telephony-context = + 94 </URIalternative>

<URIalternative> tel: 119; telephony-context = + 1876 </URIalternative>

<police />

</alternative>

ES 2 393 301 T3 <alternative>

<URIalternative> tel: 119; telephony-context = + 57 </URIalternative>

<URIalternative> tel: 119; telephony-context = + 86 </URIalternative>

<fire />

</alternative>

<alternative>

<URIalternative> tel: 119; telephony-context = + 62 </URIalternative>

<URIalternative> tel: 118; telephony-context = + 62 </URIalternative>

<ambulance />

</alternative>

</ action>

</alternative-service>

</ims-3gpp>

The XML body provided by way of example above indicates that the address '119' may be translated to a different type of emergency in a different jurisdiction. For example, the address '119' is associated with 'fire' and 'ambulance' emergency services when the UE is in a jurisdiction that has a telephony context of '+81' (Japan) or '+82' ( Korea). The address '119' is alternatively associated with 'police' emergency services when the UE is in a jurisdiction that has a telephony context of '+94' (Sri Lanka).

If a country code or location code is included in an emergency service request that can be correlated to multiple types of emergency services, it is assumed that the handheld is specifically trying to route the request to the type of service. associated with the emergency service address of the indicated country or region.

In another embodiment, the UE or the network has been configured to select or reduce the alternatives in the response and to eliminate some of the less likely possibilities. Such selection or reduction may be achieved based on, for example, the current network of a UE, the home network of the UE, the nationality of the UE user or the past travel plans of the UE user. A UE that performs a selection or reduction may include a criterion that performs a “hard” encoding [with incorporation of data in source code] of a correlation between an address, an emergency type and a telephony context, thereby the UE is allowed to explicitly select the desired emergency type when making an emergency call through the CS domain or the PS domain. In the PS domain, an emergency type can be indicated either by a URN from RFC 5031 or by a TEL URL that includes a country or region indicator such as a 'telephony context'. An emergency type selection function in the UE can be further enhanced if the UE is aware of the country or region where it is located and if a stored or received correlation of emergency types, position indicators and emergency call addresses is present . The emergency type selection function can then determine that in certain countries or regions a certain correlation does NOT apply, or that the correlation applies universally (for example, for UMTS / GSM handsets, the number "112" can be mapped to an emergency call setup in the GSM / UMTS CS domain, with all bits of the Emergency Service Category Value set to '0' (see Table 10.5.135d / 3GPP TS 24.008: Service Category information element)).

Such additional interaction between the network and the UE to select a translation will also include, for example, placing the options for the translation in a text field intended to be displayed in the UE (such as the <reason> element of the XML body of IMS according to 3GPP). The UE user can then select one of the options, the selection can be transmitted to the network, and the network can translate the emergency number based on the selection. Alternatively, the network may make the selection in the following order: map the address (eg, 119) as defined in the home network; if the address has not been defined in the home network, mapping the address as defined in the currently visited network; if the address has not been defined in the currently visiting network, map the address as defined for roaming partners or route the call to the default or higher capacity PSAP. Alternatively, the request can always be routed to the PSAP by default or with higher capacity.

A similar problem can occur for the UE when it tries to recognize the address marked as a

ES 2 393 301 T3 emergency identifier. In one embodiment, the UE has been configured with a translation in order to prevent this problem from occurring. Alternatively, the UE can interact with the user to select a desired translation. Alternatively, the UE may have been configured to route the call to the higher capacity or default PSAP. Alternatively, the UE may route the call based on the network and bind to, and may map the digits according to, the rules of that network. The UE can also interact with the network and use any ad or ad it gets.

In yet another embodiment, the P-CSCF will not reject the request for an unsupported type of emergency service (such as urn: service: sos.poison (urn: service: sos.veneno)), but instead prepares it for referral to the user's home S-CSCF using normal procedures (as opposed to referral to an E-CSCF). The SCSCF of the user's home network must then have been configured to take care of the Request URI value not routable. The IMS network may also have been configured to take into account roaming users requesting a session with the urn: service: sos.police, such that the service requested by a UE that may be midway anywhere part of the world can still be managed in a timely and effective way. The IMS network may provide an indication in a SIP message to the UE that it has been determined that the call is not an emergency call and that its handling will be different. The indication may consist of a badge and / or alphanumeric information. Possible encodings for this type of indicator are provided in this document.

Returning to the case where a component of the IMS network determines that the UE 110 has initiated an emergency call without recognizing it as such, in some applications, the IMS network 120 includes the emergency call indicator 160 in a SIP response which is sent to the UE 110. In this case, the indicator 160 is provided during the signaling or signaling phase for call setup. In other embodiments, the emergency call indicator 160 is included in a message originating from the PSAP 130. The IMS network 120 then transfers the message from the PSAP 130 to the UE 110.

In other embodiments, if a component of the IMS network 120 includes the emergency call indicator 160 in the SIP response that is sent to the UE 110, the UE 110 may abort the signaling currently in progress and initiate normal procedures of emergency call establishment, which may imply that a call originates over a Circuit Switched network, if it has the capacity to do so or is available, or after initiating emergency registration procedures, or sending a SIP INVITE request that contains an indicator indicating that the SIP INVITATION request is an emergency-related call request and that contains information about itself, related with the emergency.

Information that is similar to information 180 that UE 110 includes in SIP message 170, can be included by UE 110 in a message sent under different circumstances. This is illustrated in Figure 2, where the UE 110, the IMS network 120, and the PSAP 130 are again present. However, in this case, the PSAP 130 initiates a call back to the UE 110. As is well known in the art, once an emergency call has been terminated, the PSAP 130 can place a call back to the UE 110 for various reasons. For example, if the emergency call appears to have ended abnormally, the PSAP 130 may call the UE 110 back in order to determine if the user of the UE wishes to convey any additional information. Alternatively, the PSAP 130 may call the user back to request information that was not inadvertently requested on the initial call. Other reasons for a call back from the PSAP 130 to an emergency caller upon termination of an emergency call may be familiar to one of ordinary skill in the art.

The PSAP 130 may initiate the call back by sending a SIP INVITE message 210 or a similar message to the UE 110 through the IMS network 120. In one embodiment, SIP INVITE message 210 contains an indicator 220 indicating that SIP INVITE message 210 is related to an emergency return call. Indicator 220 may be substantially similar to indicator 160 of Figure 1, or it may be some other type of indicator. The UE 110 may recognize that the indicator 220 is an indication of an emergency callback from the PSAP 130 and may respond appropriately to the indicator 220 by appealing to an emergency callback functional capability, subject to certain criteria. In one embodiment, the response of the UE 110 to the receipt of the flag 220 is substantially similar to the response that the UE 110 had to the receipt of the flag 160 of Figure 1.

For example, one action that the UE 110 may take upon recognizing the flag 220 is to indicate, visually or audibly, the nature of the session to the user. That is, the UE 110 can alert the user that the incoming call is an emergency call. The alert may consist of a message that appears on the UE 110's display screen or some other type of indication of the nature of the call. Other actions taken by the UE 110 may involve the transmission of a 2xx or 1xx response from SIP (for example, the response 200 (OK) from SIP) 320, or a similar message, including information 240 about the UE 110, submitted to certain criteria. Alternatively, due to SIP limitations, information 240 may be transmitted via various SIP messages or network messages (for example, the IP-CAN identity information provided by the UE may not be completely reliable and therefore Therefore, a mechanism based on the provision of network (for example, using Control of Criteria and Charging (PCC - “Policy Control and Charging”)) can provide such information), or within a target refresh request such as a request for re-INVITATION OF

ES 2 393 301 T3

SIP or UPDATE request, or partially in a SIP PRACK request. Information 240 may be substantially similar to information 180 provided by UE 110 upon receiving indicator 160 of Figure 1.

A fragment of the information 140 that the UE 110 can send to the PSAP 130 is the public user identity of the UE or some other identification symbol. Another piece of information 240 that the UE 110 can transmit to the SIP 200OK message 230 is the type of access that the UE 110 used for the initial emergency call. For example, if the emergency call was made over a wireless LAN, the UE 100 may include that fact in the information 240, as well as a cell ID, line ID, and / or access node ID of Wireless LAN.

In the event that the UE 110 is aware of its geographical position by using, for example, a GPS system, the UE 110 can include its position as another piece of information 240. If the UE 110 is not aware of its geographical position, no data regarding the position is included in the information 240. If there is a GRUU associated with the UE 110, the GRUU of the UE can be included as another piece of the information 240.

In an alternative embodiment, the PSAP 130 may establish a Circuit Switched (CS) call and a CS gateway may then convert the call and the handshake or signaling to packet switched technology if the CS call is routed to. the CS catwalk. Triggered or activated by the incoming call from the PSAP 130, the gateway CS can initiate the callback or callback via packet switched technology, by sending a SIP INVITE message 210, or a similar message, to the UE 110 to through the IMS network 120.

Figure 3 illustrates one embodiment of a method 300 for a UE to respond to an emergency related message sent to the UE. At block 310, the UE receives a message containing an indicator indicating that an emergency related call has been made. In some cases, the call related to an emergency may have been made by the UE without the UE being aware that the call was related to an emergency. In other cases, the call related to an emergency may be a call back from a PSAP to the UE, in response to a previous emergency call from the UE. At block 320, the UE recognizes the flag as an indication that its first message (initial SIP request for a single or isolated dialogue or transaction, or an unknown method or similar message) is related to an emergency. Optionally, at block 330, the UE provides a visual, audible, or other indication to the user of the UE that the call related to an emergency is related to an emergency. At block 340, the UE sends a message containing emergency-related information about itself.

The invention described herein may be implemented in the form of one or more modifications in the Technical Specification (TS - "Technical Specification") of the Third Generation Partnership Project (3GPP - "Third Generation Partnership Project") 24.229 “Internet Protocol (IP) Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 2 "(" Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 "). Proposed addenda and modifications to TS 24,229 are provided below, in accordance with various embodiments of the present invention.

The following addendum to 3GPP TS 24.229 applies to the initial INVITE request in the event that a call initiation originates from the UE:

In the event that the UE receives a 380 response (Alternative Service) to an INVITE request, such that the response contains an XML body that includes an <alternative service> element in which the "alternative" attribute of the child element <type> contains one or more emergency service URIs, the UE may attempt to make a normal call as described in subclause 5.1.3.1. using an emergency service URI or using a call setup according to the procedures described in 3GPP TS 24.008 [8]. The behavior of the UE is implementation specific in case the "alternative" attribute of the child <type> element is absent, or does not contain any emergency service URIs.

The following modification of 3GPP TS 24.229 applies to general emergency service:

The P-CSCF will store a configurable list of local emergency services identifiers, ie emergency numbers and the URN of the emergency service, which are valid for the operator to which the P-CSCF belongs. In addition, the P-CSCF will store a configurable list of roaming partner emergency services identifiers. Configurable lists with emergency service identifiers for local and roaming partners will indicate the deal for each emergency service identifier. When the deal indicates that the request would be rejected, a configurable list of alternative emergency services URIs could be included in the response.

The following addendum to 3GPP TS 24.229 applies to the general treatment for all dialogues and isolated transactions, excluding the REGISTER method after emergency registration:

If the P-CSCF detects that the Request URI of the initial request for a dialogue, or an isolated transaction, or an unknown method, matches an emergency type that is not supported in the service identifiers

ES 2 393 301 T3 emergency of VPLMN or HPLMN, the P-CSCF:

- it will respond to the INVITATION request with a response of 380 (Alternative Service);

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the 3GPPP IMS XML body is not supported in the Accept header; and

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7.6.1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) if the Acceptance header indicates that version 2 of the XML Schema is supported for the IM CN subsystem body, or then, a child element <type>, with an "alternative" attribute set to a list from alternative emergency services URIs;

or otherwise, a child element <type>, set to "emergency";

c) a child element <reason>, set to an operator-configurable reason.

The following alternative addendum to 3GPP TS 24.229 applies to the general treatment of all dialogues and isolated transactions, excluding the REGISTER method after emergency registration:

If the P-CSCF detects that the Request URI of the initial request for a dialog, or an isolated transaction, or an unknown method, matches an emergency type that is not supported in the VPLMN emergency service identifiers or from HPLMN, the P-CSCF:

- it will respond to the INVITATION request with a response of 380 (Alternative Service);

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the 3GPPP IMS XML body is not supported in the Accept header; and

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7.6.1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) a child element <type>, with an "alternative" attribute set to a list of alternative emergency services URIs;

c) a child element <reason>, set to an operator-configurable reason.

The following modification of 3GPP TS 24.229 applies to the general treatment of all dialogues and isolated transactions, excluding the REGISTER method for a non-emergency registration:

If the P-CSCF receives an initial request or request for a dialog, or an isolated transaction, or an unknown method, for a registered user, the P-CSCF will inspect the Request URI regardless of the values ​​of possible entries in the headers of the Paths received for known emergency services identifiers, that is, emergency numbers and the emergency service URM, from these configurable lists. If the P-CSCF detects that the Request URI of the initial request for a dialogue, or an isolated transaction, or an unknown method, matches one of the emergency services identifiers from any of these lists, the P-CSCF:

0) will determine the geographic position of the UE. Specific access technology procedures are described in each specific access technology annex. If the P-CSCF is unable to handle emergency sessions or, due to local criteria, does not handle emergency sessions or only handles a certain type of emergency session request, or the IP-CAN to the one that the UE is hooked on or in which it is

ES 2 393 301 T3 roaming the UE or in which the P-CSCF is, is a different network from the UE's home operator network, then the P-CSCF:

- reject the request by returning a 380 (Alternative Service) response to the UE;

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the IMS XML body is not supported according to 3GPP in the Accept header; and

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7. 6. 1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) if the Acceptance header indicates that version 2 of the XML Schema is supported for the XML body of the IM CN subsystem, then:

or a child element <type> with an "alternative" attribute set to a list of alternative emergency services URIs, and if the initial request of a dialogue, or isolated transaction, or unknown method, was for an emergency type to which supported, the child element <type> is set to “emergency” to indicate that it was a supported emergency call, or else a child element <type>, set to "emergency";

c) a child element <reason>, set to an operator-configurable ratio; Y

d) a child element <action>, set to "emergency record" if the request included an emergency service URN in the Request URI.

NOTE 1: Roaming is when a UE is in a geographic area that is outside the geographic service area of ​​the home IM CN subsystem.

NOTE 1a: "sip: 911@example.com; user = phone" can be an alternate emergency service URI.

"Urn: service: sos.animal-control" may be an unsupported type of emergency call.

NOTE 2: Emergency service URN in the Request URI indicates to the network that the emergency call attempt has been acknowledged by the UE.

The following modification of 3GPP TS 24.229 applies to the general treatment of all dialogues and isolated transactions, excluding the REGISTER method for a non-emergency registration:

If the P-CSCF receives an initial request or request for a dialogue, or an isolated transaction, or an unknown method, for a logged in user, the P-CSCF will inspect the Request URI regardless of the values ​​of possible entries in the header of the Paths received for known emergency services identifiers, that is, emergency numbers and the emergency service URM, from these configurable lists. If the P-CSCF detects that the Request URI of the initial request for a dialogue, or an isolated transaction, or an unknown method, matches one of the emergency services identifiers from any of these lists, the P-CSCF:

0) will determine the geographic position of the UE. Specific access technology procedures are described in each specific access technology annex. If the P-CSCF is unable to handle emergency sessions or, due to local criteria, does not handle emergency sessions or only handles a certain type of emergency session request, or the IP-CAN to the one the UE is hooked on or the one the UE is roaming in or the P-CSCF is on, is a different network from the UE's home operator network, then the P-CSCF:

- reject the request by returning a 380 (Alternative Service) response to the UE;

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the IMS XML body is not supported according to 3GPP in the Accept header; and

ES 2 393 301 T3

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7. 6. 1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) a child element <type> with an "alternative" attribute set to a list of alternative emergency services URIs, and

- if the initial request for a dialogue, or isolated transaction, or unknown method, were for a supported emergency type, the child element <type> is set to “emergency” to indicate that it was an emergency call that was supported,

c) a child element <reason>, set to an operator-configurable ratio; Y

d) a child element <action>, set to "emergency record" if the request included an emergency service URN in the Request URI.

NOTE 1: Roaming is when a UE is in a geographic area that is outside the geographic service area of ​​the domestic CN subsystem.

NOTE 2: Emergency service URN in the Request URI indicates to the network that the emergency call attempt has been acknowledged by the UE.

The following modification of the 3GPP TS 24.229 applies to abnormal cases:

If the IM CN subsystem to which the P-CSCF belongs is not capable of handling emergency sessions or, due to local criteria, does not handle emergency sessions or only handles a certain type of call request. emergency session or does not take over emergency sessions for the geographical position in which the UE is located or for the IP-CAN to which the UE is hooked, the P-CSCf will not forward the INVITE request. The P-CSCF:

- it will respond to the INVITATION request with a response of 380 (Alternative Service);

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the IMS XML body is not supported according to 3GPP in the Accept header; and

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7. 6. 1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) if the Acceptance header indicates that version 2 of the XML Schema is supported for the XML body of the IM CN subsystem, then:

or a child element <type> with an "alternative" attribute set to a list of alternative emergency services URIs, and if the initial request of a dialogue, or isolated transaction, or unknown method, was for an emergency type to which supported, the child element <type> is set to “emergency” to indicate that it was a supported emergency call, or else a child element <type>, set to "emergency";

c) a child element <reason>, set to an operator-configurable ratio; Y

d) a child element <action>, set to "emergency record" if the request included an emergency service URN in the Request URI.

NOTE 1: Emergency service URN in the Request URI indicates to the network that the emergency call attempt has been acknowledged by the UE.

ES 2 393 301 T3

NOTE 1a: "sip: 911@example.com; user = phone" can be an alternate emergency service URI.

"Urn: service: sos.animal-control" may be an unsupported type of emergency call.

NOTE 2: Some networks only allow session requests with a Request URI that contains an emergency service URN, that is, a service URN with a higher level service type of “sos”, as specified in the draft -ietf-ecrit-service-urn [69].

The following alternative modification of 3GPP TS 24.229 applies to abnormal cases:

If the IM CN subsystem to which the P-CSCF belongs is not capable of handling emergency sessions or, due to local criteria, does not take charge of emergency sessions or only handles a certain type of call request. emergency session or does not take over emergency sessions for the geographical position where the UE is located or for the IP-CAN to which the UE is hooked, the P-CSCf will not forward the INVITE request. The P-CSCF:

- it will respond to the INVITATION request WITH a response of 380 (Alternative Service);

- assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body, if the IMS XML body is not supported according to 3GPP in the Accept header; and

- will include in the response of 380 (Alternative Service):

or a Content Type header field, with the value set to the associated MIME type of the 3GPP IMS XML body, as described in subclause 7. 6. 1.

The body will contain:

a) an <alternative service> element, adjusted to the alternative service parameters;

b) a child element <type> with an "alternative" attribute set to a list of alternative emergency services URIs, and

- if the initial request for a dialogue, or isolated transaction, or unknown method, were for a supported emergency type, the child element <type> is set to “emergency” to indicate that it was an emergency call that was supported,

c) a child element <reason>, set to an operator-configurable ratio; Y

d) a child element <action>, set to "emergency record" if the request included an emergency service URN in the Request URI.

NOTE 1: Emergency service URN in the Request URI indicates to the network that the emergency call attempt has been acknowledged by the UE.

NOTE 2: Some networks only allow session requests with a Request URI that contains an emergency service URN, that is, a service URN with a higher level service type of “sos”, as specified in the draft -ietf-ecrit-service-urn [69].

The following modification can be made to the IM CN subsystem XML Body XML Schema according to 3GPP, in order to implement one or more of the embodiments described herein:

<xs: name ComplexType = “tType”>

(<xs: complexType name = "tType">) <xs: sequence>

(<xs: sequence>) <xs: element name = "emergency" Min Occurrence = "0" Max Occurrence = "1">

(<xs: element name = "emergency" minOccurs = "0" maxOccurs = "1">) <xs: ComplexType />

(<xs: complexType />)

ES 2 393 301 T3 </ xs: element>

(</ xs: element>) <xs: any namespace = "## any" Process content = "lax" Occurrencemin = "0" Occurrencemax = "unbound" />

(<xs: any namespace = "## any" processContents = "lax" minOccurs = "0" maxOccurs = "unbonded" />) </ xs: sequence>

<xs: attribute name = "alternative" type = "anyURIlist" />

(<xs: attribute name = "alternate" type = "anyURIlist" />) <xs: anyAttribute />

(<xs: anyAttribute />) </ xs: ComplexType>

The <action> element contains the attribute “alternative” and only the value “emergency record” in this document. The "alternative" attribute can match a list of alternative emergency services URIs.

The following two addenda to 3GPP TS 24.229 apply to generic procedures applicable to all methods, except for the REGISTRATION method:

When generating an initial request for a dialog, isolated transaction, or unknown method, excluding ACK and CANCEL, the UE will include the Accept header with “application / sdp” (“application / sdp”), the MIME type associated with the IMS XML body according to 3GPP (see subclause 7.6.1) and any other type of MIME that the UE wants and is able to accept.

In the event that the UE receives a 380 (Alternate Service) response to an initial request for a dialogue, or an isolated transaction, or an unknown method, the response including an XML body from the IM CN subsystem as described above. described in subclause 7.6 including an <alternative service> element with the child element <type> set to “emergency”, the UE will attempt an emergency call as described in clause 5.1.6.

If the 1xx or 2xx response to an initial request for a dialogue, or an isolated transaction, or an unknown method, contains an emergency session indicator, then the UE will send a re-INVITE request method according to RFC 3261 [26], and:

1) the UE will indicate the nature of the session to the user;

NOTE 17: The UE does not change the From header to include a public user identity or the tel URI associated with the public user identity, in this version of the specification.

2) if available to the UE, and if defined for the type of access as specified in subclause 7.2A.4, the UE shall include an Info-Network-Access-P header (“P-Access- Network-Info ”), and it will contain a position identifier such as the cell id, the line id or the identity of the I-WLAN access node;

NOTE 18: The IMS emergency specification of 3GPP TS 23.167 [4B] describes various methods by which the UE can obtain its position information from the access network or from a server. Such methods are not within the scope of this specification.

3) the UE will insert a Preferred-Identity-P (“P-Preferred-Identity”) that includes the public user identity or the tel URI associated with the public user identity, as described in subclause 4.2;

4) If the UE has its position information available, then the URI will include it as follows:

or if the UE is aware of the URI that points to where the UE's position is stored, include the URI in the Geolocation header according to draft-ietf-siplocation-conveyance [89]; oo if the UE's geographic location information is available to the UE, include your geographic location information as a PIDF location object in accordance with RFC 4119 [90], and include the location object in a message body with the application / pidf + xml

ES 2 393 301 T3 ("application / pidf + xml") of content type according to draft-ietf-sip-location-conveyance [89]; Y

5) if the UE does not have any geographic position information available, the UE will not include any geographic position information, as specified in draft-ietf-sip-location-conveyance [89]; Y

6) If a public GRUU value (pub-gruu) associated with the public user identity has been saved and the UE does not indicate the privacy of the P-Declared-Identity (“P-Asserted-Identity”), then the UE insert the public GRUU value (pub-gruu) in the Contact header, as specified in draft-ietf-sip-gruu [93]; otherwise,

NOTE 19: According to RFC 3261 [26], a re-INVITE request cannot be sent while another INVITE transaction is in progress, in either direction.

NOTE 20: It is not necessary to change the session parameters for this re-INVITE request.

NOTE 21: It is suggested that the UE only use the option to provide a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is one aspect in which the network operator needs to provide a guide or guideline to the end user. A URI that is only resolvable to the UE making the emergency call is undesirable.

NOTE 22: During the dialogue, the hook points to the IP-CAN of the UE may change (for example, the UE connects to different cells). The UE will populate or populate the Info-Red-Acceso-P header in any request (except for ACK requests and CANCELLATION requests) or response (except CANCELLATION responses) within a dialog with the point of attachment at that time to the IP-CAn (for example, the current cell information at that time).

Privacy enforcement, including removal of location and access network information, if the PSAP is within the trusted domain of the network, can be carried out by IMS network elements such as the E-CSCF, the IBCF and others. It may be preferred that "session" privacy be requested (that is, the Privacy header field is set to include the "session" value, since the Info-Network-Access-P header field is present in most SIP messages). It may be preferable for the E-CSCF to receive location information so that it can determine the most applicable PSAP and use it when routing the request to the PSAP or the emergency response center. Privacy requirements in accordance with RFC 4244 may also apply, but no procedure at present provides for including history information in a request for emergency services. The following two addenda to 3GPP TS 24.229 apply to Procedures in E-CSCF:

When the E-CSCF receives a request for a dialogue requesting privacy, or an isolated transaction requesting privacy, or any request or response related to a dialogue originated by the UE and requesting privacy, or isolated transaction requesting privacy, and if the operator local allows the user to request the deletion of public user identifiers and location information, the E-CSCF:

- apply any privacy required by RFC 3323 [33] regarding privacy and by RFC 3325 [34] to the Identity-Declared-P header;

- if present, remove the header field from INFO-NETWORK-ACCESS-P;

- if present, it will remove the position object from the body of the message and remove the content type app / pifd + xml from the Content Type header field;

- if present, it will remove the Geoposition header field.

NOTE: Operator criteria (for example, requirements to support emergency communications) may take precedence over user request for suppression.

6) select, based on the position information and optionally on the type of emergency service:

or a PSAP connected to the IM CN subsystem network, and will add the PSAP URI to the uppermost Route header; or

NOTE 3: If the user has not requested privacy, the E-CSCF carries the P-Access-Network-Info header containing the location identifier, if defined for the access type as specified in subclause 7.2A. 4, to the PSAP.

or a PSAP from the PSTN, and will append the BGCF URI to the uppermost Route header, and add a PSAP URI in the format of tel URI to the Request URI, so that an entry is used

ES 2 393 301 T3 in the PSTN / CS domain for PSAP addressing;

NOTE 4: If the user has not requested privacy, the E-CSCF carries the Info-Network-Access-P header containing the position identifier, if it has been defined for the type of access as specified in subclause 7.2A .4, towards the MGCF. The MGCF can translate the position information if it is included in the INVITE (that is, both the geographic position information contained in PIDF-LO and the position identifier contained in the header of Info-Network-Access-P), to signaling from ISUP; see 3GPP TS 29,163 [11B].

NOTE 5: The E-CSCF can request position information and route the information from the LRF. The E-CSCF can send, for example, the position identifier to the LRF and the LRF maps the position identifier with the corresponding geographic position information, which the LRF sends to the E-CSCF. The LRF may invoke or call upon an RDF to convert the location information to a suitable PSAP / EC URI. Both the location information and the PSAP URI are returned to the E-CSCF.

NOTE 6: How the C-CSCF determines the next hop address when the PSAP address is a tel URI is implementation dependent.

7) If the user has not requested privacy and if the E-CSCF receives a reference number from the LRF, the ECSCF will include the reference number in the Identity-Declared-P header;

NOTE 7: The reference number is used in communication between the PSAP and the LRF.

Figure 4 illustrates a wireless communication system that includes an embodiment of the UE 110. The UE 110 is operable to implement aspects of the invention, but the invention should not be limited by these implementations. Although it has been illustrated as a mobile phone, the UE can take various forms including a wireless handheld device, a portable pager or pager, a personal digital assistant (PDA), a laptop, a computer kind of tablet or laptop. Many suitable devices combine some or all of these functions. In some embodiments of the invention, the UE 110 is not a general-purpose computing device such as a laptop, laptop, or tablet computer, but is instead a special-purpose communications device, such as such as a mobile phone, a cordless handheld, a portable pager or pager, or a PDA. In another embodiment, the UE 110 can be a laptop, portable computer, or other computing or computing device. The UE 110 can support specialized activities such as games, inventory control, job control and / or task management functions, and more.

The UE 110 includes a display device 402. The UE also includes a touch-sensitive surface, keyboard, or other input keys generally referred to as 404, for input by a user. The keyboard may be a full or reduced alphanumeric keyboard, such as QWERTY, Dvorak, AZERTY and sequential type, or a traditional number key plate or pad with the letters of the alphabet associated with a telephone key box. The input keys can include a track wheel, an exit or escape key, a track ball, and other scroll or function keys, which can be pressed or pressed inward to provide additional input function. The UE 110 may present options for selection by the user, controls for operation by the user, and / or cursors or other indicators for the user to direct. The UE 110 may additionally accept user input, including numbers to dial or various parameter values ​​to configure the operation of the UE 110. The UE 110 may additionally perform one or more more software or firmware applications, or software permanently installed on hardware, in response to user commands. These applications can configure the UE 110 to perform various custom functions in response to user interaction. Additionally, the UE 110 can be programmed and / or configured over the air, for example, from a wireless base station, wireless access point, or similar UE 110.

Among the various applications that can be executed by the UE 110, there is a web browser, which enables the display device 402 to display a web page. The web page can be obtained through wireless communications with a wireless network access node, a cell tower, a similar UE 110, or any other wireless communication network or system 400. The network 400 is connected to a network 408 with facility cables, such as the Internet. Through the wireless link and the wired network, the UE 110 has access to information on various servers such as the server 410. The server 410 can provide content that can be displayed on the display 402. Alternatively, the UE 110 can accessing the network 400 through a similar UE 110 acting as an intermediary, in a relay type or hop type connection.

Figure 5 shows a block diagram of the UE 110. While a variety of known components of UEs 110 have been depicted, in one embodiment, a subset of the listed components and / or additional unlisted components may be included in the UE 110. The UE 110 includes a digital signal processor (DSP) 502 and a memory 504. As shown, the UE 110 may include,

Additional ES 2 393 301 T3, an antenna unit and front terminal 506, a radio frequency (RF) transceiver, or transceiver 508, an analog baseband treatment unit 510, a microphone 512, an earpiece speaker 514, an access or port 516 for helmets, an I / O interface 518, a removable memory card 520, a port 522 of universal serial bus (USB - “Universal Serial Bus”), a subsystem of wireless communication of short scope 524, an alarm 526, a keypad 528, a liquid crystal display (LCD), which may include a touch-sensitive surface 530, an LCD controller 532, a device camera 534 charge-coupled device (CCD), a camera controller 536, and a global positioning system (GPS) 538 sensor. In one embodiment, the UE 110 may include another class of display device that does not provide a touch-sensitive screen. In one embodiment, DSP 502 can communicate directly with memory 504, bypassing input / output interface 518.

DSP 502 or some other form of controller or central processing unit functions to control the various components of UE 110 in accordance with embedded software or firmware, stored in memory 504 or stored in memory contained within DSP 502 itself. In addition to the embedded software or firmware, the DSP 502 can run other applications stored in memory 504 or made available through information-carrying media such as portable data storage media, such as removable memory card 520, or via wired or wireless network communications. The application software may comprise a compiled set of machine-readable instructions, which configures the DSP 502 to provide the desired functionality, or the application software may consist of high-level software instructions intended to be processed or handled by an interpreter or compiler in order to indirectly configure the DSP 502.

The front terminal and antenna unit 506 may have been provided for conversion between wireless signals and electrical signals, allowing the UE 110 to send and receive information from a cellular network or some other available wireless communication network, or from such a UE 110. . In one embodiment, the antenna and front terminal unit 506 may include multiple antennas in order to support beamforming and / or multiple input-multiple output (MIMO) operations. As is known to those of skill in the art, MIMO operations can provide spatial diversity that can be used to overcome difficult channel conditions and / or increase channel data transfer. The antenna and front terminal unit 506 may include antenna tuning and / or impedance matching components, RF power amplifiers, and / or low noise amplifiers.

The RF transceiver 508 provides frequency shifting, conversion of received RF signals to baseband, and conversion of transmitted baseband signals to RF. In some descriptions, a radio transceiver or RF transceiver may be understood to include other functional signal processing capabilities, such as modulation / demodulation, encoding / decoding, interleaving / reverting, spreading / dispersion reversal, the inverse fast Fourier transform (IFFT - “inverse fast Fourier transform”) / fast Fourier transform (FFT), cyclical prefix addition / removal, as well as other signal processing functions. For the sake of clarity, the description provided herein separates the description of this signal processing from the RF and / or radio stage and conceptually assigns that signal processing to the analog baseband processing unit 510 and / or or to the DSP 502 or other central processing unit. In some embodiments, the RF Transceiver 508, certain parts of the Antenna, and the Front Terminal 506, as well as the analog baseband processing unit 510 can be combined into one or more processing units and / or specific ICs. the application (ASICs - “application specific integrated circuits”).

Analog baseband processing unit 510 can provide various analog processing of inputs and outputs, for example, analog processing of inputs from microphone 512 and headphones 516, and outputs to earphone 514 and headphones. helmets 516. To this end, the analog baseband processing unit 510 may have ports to connect to the built-in microphone 512 and the speaker 514 of the headphones, which allow the UE 110 to be used as a cellular telephone. Analog baseband processing unit 510 may additionally include a port for connecting to a headset or other hands-free microphone and speaker setup. The analog baseband processing unit 510 can provide a digital-to-analog conversion in one direction of the signals, and an analog-to-digital conversion in the opposite direction of the signals. In some embodiments, at least some of the functional capabilities of the analog baseband processing unit 510 may be provided by digital processing components, for example, by DSP 502 or by other central processing units.

The DSP 502 can carry out modulation / demodulation, encoding / decoding, interleaving / reversion of interleaving, dispersion / reversion of dispersion, inverse fast Fourier transform (IFFT "inverse fast Fourier transform") / fast transform of Fourier (FFT), cyclic prefix addition / removal, as well as other signal processing functions associated with wireless communications. In one embodiment, for example, in a code division multiple access (CDMA) technology application, for a transmitter function, the DSP 502 can perform modulation, encoding,

ES 2 393 301 T3 interleaving and spreading, and for a receiver function, the DSP 502 can perform spreading reversion, interleaving reversion, decoding and demodulation. In another embodiment, for example, in an application of orthogonal frequency division multiple access (OFDMA) technology, for the transmitter function, the DSP 502 can carry out modulation, coding, interleaving, inverse fast Fourier transform and cyclic prefix addition, and for a receiver function, the DSP 502 can carry out cyclic prefix elimination, fast Fourier transform, reversal of interleaving, decoding, and demodulation. In other wireless technology applications, still other signal processing functions and combinations of signal processing functions may be carried out by the DSP 502.

The DSP 502 can communicate with a wireless network through the analog baseband processing unit 510. In some embodiments, the communication can provide connectivity or connectivity to the Internet, allowing the user to access content on the Internet. Internet and send and receive email or text messages. The input / output interface 518 interfaces the DSP 502 and various memories and interfaces. Memory 504 and removable memory card 520 can provide programming or software and data to configure operation of DSP 502. Among the interfaces can be USB interface 522 and short-range wireless communication subsystem 524. The USB interface 522 can be used to charge the UE 110 and can also allow the UE 110 to function as a peripheral device in order to exchange information with a personal computer or other computer system. The short-range wireless communication subsystem 524 may include an infrared gate, a Bluetooth-type interface, a wireless interface in accordance with the IEEE 802.11 standard, or any other short-range wireless communication subsystem that can allow the UE 110 to communicate. wirelessly with other nearby UEs and / or wireless base stations.

I / O interface 518 may additionally connect DSP 502 to alarm 526, which, when triggered, causes UE 110 to provide a prompt to the user, for example, by ringing, playing a melody or vibrate. Alarm 526 can serve as a mechanism to alert the user to any of various events such as an incoming call, a new text message, and an appointment reminder, by vibrating silently or by playing a specific melody previously assigned for a particular caller.

Keybox 528 is connected to DSP 502 through interface 518 to provide a mechanism for the user to make choices, enter information, and otherwise provide inputs to UE 110. Keypad 528 may be an alphanumeric keyboard full or reduced, such as QWERTY, Dvorak, AZERTY, and sequential types. Or a traditional number key box with letters of the alphabet associated with a phone key box. The input keys can include a track wheel, an escape or exit key, a track ball, as well as other scroll or function keys, which can be depressed or pushed inward to provide additional input function. Another input mechanism may be the LCD 530, which may include touch screen capability and also the visual presentation of text and / or graphics to the user. LCD controller 532 connects DSP 502 to LCD 530.

The CCD camera 534, if installed, allows the UE 110 to take digital images. DSP 502 communicates with CCD camera 534 through camera controller 536. In another embodiment, a camera operating in accordance with a different technology than Charge Coupling Device cameras may be employed. The GPS sensor 538 is connected to the DSP 502 in order to decode signals from the global location system, thereby allowing the UE 110 to determine its position. Various other peripheral devices may also have been included to provide additional functions, eg, radio and television reception.

Figure 6 illustrates a software environment 602 that can be implemented by DSP 502. DSP 502 operates operating system drivers 604 that provide a platform from which to operate all other software. The operating system drive devices 604 provide drive devices for node hardware with standardized interfaces that are accessible to application software. Operating system drive devices 604 include application management services (AMS) 606 that transfer control between applications "running" or running on the UE 110. An application is also shown in Figure 6. Web browser 608, an information carrier media player application 610, and Java applets [application components executed in the context of another program] 612. The web browser application 606 configures the UE 110 to function as a web browser, allowing a user to enter information into forms and select links to retrieve and view web pages. The information bearing media player application 610 configures the UE 110 to retrieve and play audio or audiovisual media. Java 612 applets configure the UE 110 to provide games, utilities, and other functional capabilities. A component 614 can provide the functional capabilities described herein.

The UE 110 and other components described above may include a processing component that is capable of executing instructions related to the actions described above. Figure 7 illustrates an example of a system 1300 that includes a treatment component 1310 suitable for

ES 2 393 301 T3 implement one or more embodiments described herein. In addition to the 1310 processor (which may be referred to as a central processing unit or CPU), the 1300 system may include network connectivity devices 1320, random access memory (RAM). ”) 1330, read only memory (ROM) 1340, a secondary storage device 1350 and input / output devices (I / O -“ I / O (input / output) ”) 1360. In some cases, some of these components may not be present or may have been combined in various combinations with each other or with other components not shown. These components may have been mapped to a single physical entity or to more than one physical entity. Any actions described herein as being taken by processor 1310 may be taken by processor 1310 alone or by processor 1310 in combination with one or more components shown, or not shown, in the drawings.

Processor 1310 carries out instructions, codes, computer programs, or scripts that it can access from network connectivity devices 1320, RAM 1330, ROM 1340, or secondary storage device 1350 (which may include various systems based disk, such as a hard disk, floppy disk, or optical disk). While only one 1310 processor has been shown, multiple processors may be present. Thus, although the instructions have been explained as being executed by one processor, the instructions can be executed simultaneously, serially or otherwise, by one or multiple processors. Processor 1310 can be implemented as one or more integrated circuits or CPU chips.

Network connectivity devices 1320 can take the form of modems or modulator-demodulators, modem banks, Ethernet devices, universal serial bus (USB) interface devices, serial interfaces, ring network devices, fiber distributed data interface (FDDI), wireless local area network (WLAN) devices, radio transceiver devices, such as code division multiple access (CDMA) and / or global system for mobile communications (GSM) radio transmitter-receiver devices, as well as other well-known devices for connection to networks. These network connectivity devices 1320 can allow a processor 1310 to communicate with the Internet or with one or more telecommunications networks or other networks from which the processor 1310 can receive information or to which the processor 1310 can output information.

Network connectivity devices 1320 may also include one or more transmitter-receiver components 1325, capable of wirelessly transmitting and / or receiving data in the form of electromagnetic waves, such as radio frequency signals or microwave frequency signals. Alternatively, data can propagate within or across the surface of electrical conductors, within coaxial cables, within waveguides, within optical media such as fiber optics, or in other media. Transceiver component 1325 may include independent transmitting and receiving units, or a single transceiver. The information transmitted or received by the transceiver 1325 can include data that has been processed by the processor 1310 or instructions that are to be executed by the processor 1310. Such information can be received from a network or provided as output to it in form of, for example, a computer database band signal, or a signal embedded in a carrier wave. The data can be ordered according to different sequences, as may be desirable, either for the processing or generation of the data or for the transmission or reception of the data. Reference can be made to the baseband signal, to the signal incorporated in the carrier wave or to other types of signals that are used today or that will be developed in the future, as the transmission medium, and can be generated according to with various methods well known to one of ordinary skill in the art.

The RAM 1330 can be used to store volatile data and, perhaps, to store instructions that are executed by the processor 1310. The ROM 1340 is a non-volatile memory device that typically has a smaller memory capacity than the memory capacity. memory of secondary storage device 1350. ROM 1340 can be used to store instructions and perhaps data that is read during execution of instructions. Access to both RAM 1330 and ROM 130 is typically faster than secondary storage device 1350. Secondary storage device 1350 typically consists of one or more disk drives or magnetic tape drives and can be used for non-volatile data storage or as an overflow or data storage device. overflow if 1330 RAM is not large enough to hold all job data. Secondary storage device 1350 can be used to store programs that are loaded into RAM 1330 when such programs are selected for execution.

1360 I / O devices may include liquid crystal displays (LCDs), touch screen displays, keyboards, keypads or boxes, switches, dials, mice, trackballs, speech recognizers, well known card readers, paper tape readers, printers, video displays or other input devices. Also, transceiver 1325 may be considered as a component of I / O devices 1320, rather than, or in addition to, being a component of network connectivity devices 1320. Some of the I / O devices 1360, or all of them, may be substantially similar to various components depicted in the previously described drawing of the UE 110, such as the display device 402 and the input 404.

ES 2 393 301 T3

In one embodiment, a method is provided for a network component to take over the requests sent to the network component. The network component inspects the requests sent to the network component to determine if the requests are related to emergencies and, if it is determined that one of the requests is related to an emergency, the network component updates the request.

When the request is determined to be related to an emergency, the network component is alternatively configured, based on configurations and regulatory criteria, to perform one of: accept the request; accepting the request and including an emergency call indicator in a Session Initiation Protocol (SIP) response sent to a user equipment (UE) that initiated the request; not accept the request, rejecting the request; not accept the request and provide alternative contact information for an emergency response center to which the request was directed.

In one embodiment, a SIP (Session Initiation Protocol) response is sent to the UE in response to the UE making a call that the UE is not aware of is an emergency call.

If there is a globally routable user agent uniform resource identifier (GRUU) associated with the UE, and if the GRUU is a temporary GRUU, the temporary GRUU is replaced by a non-temporary GRUU The temporary GRUU can be replaced by the GRUU not temporary only when no request has been made to keep the GRUU private.

If an IMS Communication Service Identifier (ICSI - "IMS Communication Service Identifier") or an IMS Application Reference Identifier (IARI - "IMS Application Reference Identifier") is present, before the Request is routed to a PSAP or emergency central, the network component performs at least one of: removing header fields from Preferred-Service-P ("P-Preferred-Service"); remove header fields from Service-Declared-P (“P-Asserted-Service”); remove ICSI feature tags and tag values ​​from Accept-Contact header fields; and removing IARI feature tags and tag values ​​from the Accept-Contact header fields.

When the network component does not accept the request, the network component responds with a 300 message (Multiple Choice), a 301 message (Permanently Moved), a 302 message (Temporarily Moved), a SIP 4xx response, a 6xx response from SIP, or a 380 response from SIP (Alternative Service).

In one embodiment, the network component does not accept the request due to at least one of these causes: the network is not able to take over emergency sessions; an Internet multimedia core network subsystem to which the network component belongs is not capable of handling emergency sessions; the network does not handle emergency sessions due to local policy or criteria; the network only handles certain types of emergency session requests; the UE is roaming; the network component is a different network than the UE's home operator network; and the network does not support emergency sessions for one of the geographical position where it is located in UE and the Internet Protocol Connectivity Access Network to which the UE is hooked.

In one embodiment, the network component includes a configurable list of roaming partners' emergency service identifiers, indicating handling of requests according to a pattern for each emergency service identifier. When the network component does not accept the request, a configurable list of alternative emergency services identifiers is sent to the UE. The at least one alternate emergency service URI may be presented to the UE user.

In one embodiment, the network component, instead of not accepting the request for an unsupported type of emergency service, prepares the request for forwarding to the UE's home network. The UE's home network may be configured to take over the URI value associated with the request.

In one embodiment, the network component is a proxy call session control function (P-CSCF).

In one embodiment, the requests comprise initial SIP requests from a dialogue, individual or isolated SIP transactions, or unknown SIP methods.

In an alternative embodiment, user equipment is provided. The user equipment comprises a component, in such a way that, in response to an emergency request that is rejected, the component has been configured to receive a message containing information that associates the emergency request with an emergency center. combined. The component may additionally have been configured to use the information for the purpose of making a subsequent emergency request to the combined emergency center.

In an alternative embodiment, a network component is provided. The network component comprises a component such that, upon receiving an emergency request from a user equipment, the component is

ES 2 393 301 T3 has been configured to determine if the emergency request is related to a combined emergency center, and to send the user equipment a message containing information indicating that the emergency request is related to a combined emergency center .

In an alternative embodiment, user equipment is provided. The user equipment comprises a component configured to receive a rejection message containing alternate address information that associates an emergency request with a plurality of emergency centers, non-emergency exchanges, or combined emergency centers. The alternate address information can be used to determine to which of the plurality of exchanges an emergency is to be routed.

In an alternative embodiment, a network component is provided. The network component comprises a component configured to determine whether a received request is an emergency request and whether the received request is related to one or more specific emergency exchanges, combined emergency exchanges or non-emergency exchanges, and to send a reject response that contains alternate address information. The alternate address information may comprise a mapping relationship between the received request, a telephony context, and one or more optional emergency identifier types.

The following Technical Specifications (TS - “Technical Specifications”) of the Third Generation Partnership Project (3GPP - “3rd Generation Partnership Project”) are hereby incorporated by reference: TS 24.229 V7.8.0 (12-2007) and TS 24.008.