Source: http://patents.com/us-9462616.html
Timestamp: 2018-07-22 10:18:16
Document Index: 134727578

Matched Legal Cases: ['art 1', 'art 4', 'art 3', 'art 2', 'Application No. 12172479', 'Application No. 12177729', 'Application No. 13162547', 'Application No. 13162615', 'Application No. 15156206', 'Application No. 200980130796', 'Application No. 09759257', 'Application No. 61', 'Application No. 61']

US Patent # 9,462,616. System and method for managing emergency requests - Patents.com
United States Patent 9,462,616
Bakker , et al. October 4, 2016
Bakker; Jan Hendrik Lucas (Keller, TX), Buckley; Adrian (Tracy, CA), Allen; Andrew Michael (Hallandale Beach, FL)
Family ID: 1000002149473
14/968,686
US 20160100435 A1 Apr 7, 2016
12937199 9215734
PCT/US2009/045990 Jun 2, 2009
12131785 Jul 2, 2013 8478226
61061507 Jun 13, 2008
61081576 Jul 17, 2008
Current CPC Class: H04W 76/007 (20130101); H04L 65/1006 (20130101); H04L 65/1016 (20130101); H04L 65/1069 (20130101); H04L 65/40 (20130101); H04M 3/42348 (20130101); H04W 4/22 (20130101); H04M 3/42068 (20130101); H04M 7/006 (20130101); H04M 2242/04 (20130101)
Current International Class: H04M 11/04 (20060101); H04W 4/22 (20090101); H04L 29/06 (20060101); H04W 76/00 (20090101); H04M 7/00 (20060101); H04M 3/42 (20060101)
Field of Search: ;455/404.1,404.2,456.1,456.3
6198914 March 2001 Saegusa
6766159 July 2004 Lindholm
7050785 May 2006 Islam et al.
7116967 October 2006 Kauppinen et al.
7245900 July 2007 Lamb et al.
7336962 February 2008 Levitan
7738855 June 2010 Jang et al.
8040862 October 2011 Rosenberg et al.
8200185 June 2012 Edge et al.
8305210 November 2012 Bakker et al.
8369824 February 2013 Bakker et al.
8442479 May 2013 Bakker et al.
8478226 July 2013 Bakker et al.
8755765 June 2014 Bakker et al.
2005/0233727 October 2005 Poikselka et al.
2007/0117539 May 2007 Harris
2007/0260739 November 2007 Buckley et al.
2008/0008157 January 2008 Edge et al.
2008/0267171 October 2008 Buckley et al.
2009/0047922 February 2009 Buckley et al.
2011/0099281 April 2011 Bakker et al.
2011/0119340 May 2011 Van Elburg et al.
1222807 Jul 1999 CN
101132623 Feb 2008 CN
1906638 Apr 2008 EP
2005-525030 Aug 2005 JP
2007-172625 Jul 2007 JP
2009-535944 Oct 2009 JP
03009627 Jan 2003 WO
03094563 Nov 2003 WO
2007016695 Mar 2007 WO
2007127991 Nov 2007 WO
2008022554 Feb 2008 WO
"All-IP Network Emergency Call Support," 3GPP2, 3GPP2 X. P0049-0, Version 1.0, Nov. 7, 2007, pp. 1-68, XP06210045, retrieved from the Internet: URL:http://ftp.3gpp2.org/TSGX/Working/2007/TSG-X-2007-11-Osaka/TR45.2-200- 7-11-Osaka/452-20071108-19TIA-1111ballot/ [retrieved on Nov. 7, 2007], paragraphs [7.2.1], [8.1.2], [08.3], [08.6]. cited by applicant .
"Presence Information Data Format (PIDF)," Internet Engineering Task Force (IETF) Network Working Group, Request for Comments: 3863, pp. 1-28, Aug. 2004, [retrieved on Dec. 19, 2012 from: http://tools.ietf.org/html/rfc3863]. cited by applicant .
"Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)," Internet Engineering Task Force (IETF) Network Working Group, Request for Comments: 3455, pp. 1-34, Jan. 2003. cited by applicant .
"SIP: Session Initiation Protocol," Internet Engineering Task Force (IETF) Network Working Group, Request for Comments: 3261, pp. 1-269, Jun. 2002, [retrieved on Dec. 19, 2012 from: http://tools.ietf.org/html/rfc3261]. cited by applicant .
3GPP ETSI TS 124 008, Apr. 2008, version 7.11.0, pp. 1-551. cited by applicant .
3GPP TS 24.229 V7.11.0, Technical Specification Group Core Network and Terminals, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Release 7, Mar. 2008, 434 pages. cited by applicant .
3GPP TS 24.229 V7.11.0, Technical Specification Group Core Network and Terminals, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Release 7, Section 5.1.2A, Mar. 2008, pp. 1-15 and 49-53. cited by applicant .
3GPP TS 24.229 V8.3.0 Release 8, ETSI TS 124 229 v8.3.0, Digital Cellular Telecommunications System (Phase 2+): Universal Mobile Telecommunications System (UMTS), Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Apr. 2008, 498 pages. cited by applicant .
3GPP TS 24.229 v8.3.0, Release 8, ETSI TS 124 229 v8.3.0, Digital Cellular Telecommunications System (Phase 2+): Universal Mobile Telecommunications System (UMTS), Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Apr. 2008, 1-125, Part 1. cited by applicant .
3GPP TS 24.229 v8.3.0, Release 8, ETSI TS 124 229 v8.3.0, Digital Cellular Telecommunications System (Phase 2+): Universal Mobile Telecommunications System (UMTS), Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Apr. 2008, 376-497, Part 4. cited by applicant .
3GPP TS 24.229 v8.3.0, Release 8, ETSI TS 124 229 v8.3.0, Digital Cellular Telecommunications System (Phase 2+): Universal Mobile Telecommunications System (UMTS), Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Apr. 2008, 251-375, Part 3. cited by applicant .
3GPP TS 24.229 v8.3.0, Release 8, ETSI TS 124 229 v8.3.0, Digital Cellular Telecommunications System (Phase 2+): Universal Mobile Telecommunications System (UMTS), Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Apr. 2008, 126-250, Part 2. cited by applicant .
3GPP TS 24.229 v8.3.0, Technical Specification Group Core Network and Terminals, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Release 8, Mar. 2008, 495 pages. cited by applicant .
3GPP TS 24.403 v1.8.1, Technical Specification Group Core Network and Terminals, Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN), IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), Stage 3, Release 7, Dec. 2007, 96 pages. cited by applicant .
3GPP TS 24.403, v1.8.1, Technical Specification Group Core Network and Terminals, Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN), IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SOP), Dec. 1, 2007, XP050365362, pp. 1-96, paragraphs [5.2.6.3], [5.2.7.2], [5.2.10.2]. cited by applicant .
3GPP TSG CT WG1 24.229 v8.4.1 Meeting #54, 24.229, Change Request, CR 2321, C1-082335, Zagreb, Croatia, Jun. 23-27, 2008, 20 pages. cited by applicant .
3GPP TSG CT WG1 Meeting #49, "Corrections for Emergency Procedures," C1-072991, Nokia Siemens Networks, Nokia, Ericsson, Kobe, Japan, Oct. 8-12, 2007, 8 pages. cited by applicant .
3GPP TSG SA WG2 Architecture--S2 #50, Basic Call Flow of North America IMS Emergency Session Establishment, S2-060406, Jan. 16-20, 2005. cited by applicant .
Jennings et al., "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks," RFC 3325, Nov. 1, 2002, XP015009093, ISSN: 0000-0003, 19 pages. cited by applicant .
Nokia Siemens Networks et al., "Corrections for emergency procedures," 3GPP Draft; C1-072991.sub.--24229CR1997R2.sub.--EMC1.sub.--REL-8 Procedure, 3rd Generation Partnership Project (3GPP), vol. CTWG1, Nov. 12, 2007, XP050027161, 7 pages. cited by applicant .
Rosen et al., "Best Current Practices for Communications Services in Support of Emergency Calling," Feb. 27, 2006, draft-rosen-sos-phonebcp-00.txt. cited by applicant .
Schulzrinne, "A Uniform Resource Name (URN) for Emergency and other Well-Known Services," Jan. 2008, RFC 5031, pp. 1-15. cited by applicant .
Taylor et al., "Security Threats and Requirements for Emergency Call Marking and Mapping," Jan. 2008, RFC 5069, 13 pages. cited by applicant .
European Search Report in European Application No. 12172479.3, dated Sep. 11, 2012, 6 pages. cited by applicant .
European Search Report in European Application No. 12177729.6, dated Sep. 3, 2012, 9 pages. cited by applicant .
European Search Report in European Application No. 13162547.7, dated Jul. 11, 2013, 10 pages. cited by applicant .
European Search Report in European Application No. 13162615.2, dated Jul. 15, 2013, 8 pages. cited by applicant .
European Search Report in European Application No. 15156206.3, dated Jun. 16, 2015, 5 pages. cited by applicant .
International Preliminary Report on Patentability in International Application No. PCT/US2009/045987, dated Dec. 6, 2010, 7 pages. cited by applicant .
International Preliminary Report on Patentability in International Application No. PCT/US2009/045990, dated Dec. 6, 2010, 6 pages. cited by applicant .
International Preliminary Report on Patentability in International Application No. PCT/US2009/045992, dated Dec. 6, 2010, 8 pages. cited by applicant .
International Search Report in International Application No. PCT/US2009/045987, dated Sep. 7, 2009, 3 pages. cited by applicant .
International Search Report in International Application No. PCT/US2009/045990, dated Sep. 7, 2009, 3 pages. cited by applicant .
International Search Report in International Application No. PCT/US2009/045992, dated Sep. 15, 2009, 3 pages. cited by applicant .
International Written Opinion in International Application No. PCT/US2009/045987, dated Sep. 7, 2009, 6 pages. cited by applicant .
International Written Opinion in International Application No. PCT/US2009/045990, dated Sep. 7, 2009, 6 pages. cited by applicant .
International Written Opinion in International Application No. PCT/US2009/045992, dated Sep. 15, 2009, 7 pages. cited by applicant .
SIP: More Than You Ever Wanted to Know About; Mar. 2007; 242 pages. cited by applicant .
RFC 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP); Aug. 2006; 38 pages. cited by applicant .
RFC 5012 Requirements for Emergency Context Resolution with Internet Technologies; Jan. 2008; 22 pages. cited by applicant .
Office Action issued in related Chinese Application No. 200980130796.X on Apr. 11, 2016. cited by applicant .
Communication Pursuant to Article 94(3) EPC issued in European Application No. 09759257.0 on Jul. 6, 2016. cited by applicant.
This application is a continuation of U.S. patent application Ser. No. 12/937,199 filed on Jan. 13, 2011, which is a filing under 35U.S.C. 371 of International Application No. PCT/US2009/045990 filed Jun. 2, 2009, entitled "System and Method for Managing Emergency Requests" claiming priority to U.S. patent application Ser. No. 12/131,785 filed on Jun. 2, 2008, and claiming priority to U.S. Provisional Application No. 61/061,507 filed on Jun. 13, 2008, and claiming priority to U.S. Provisional Application No. 61/081,576 filed on Jul. 17, 2008 which these applications are incorporated by reference herein in their entirety.
1. An network component, comprising: a receiver configured to receive from a user equipment ("UE") a Session Initiation Protocol ("SIP") request message for a dialog that is an emergency-related request; one or more processors configured to update header information of the SIP request message for a dialog; an interface configured to forward the SIP request message for a dialog toward a Public Safety Answering Point ("PSAP"); and a transmitter configured to send to the UE a SIP response message in response to the SIP request message, the SIP response message containing a P-Asserted-ldentity header field indicating that the network component is part of a trust domain, the P-Asserted-Identity header field including an indicator indicating that the SIP request message for a dialog, sent by the UE, is an emergency-related request, and that the UE should include emergency-related information associated with the UE in a SIP request message within the dialog in response to the SIP response message, the emergency-related information comprising location information; wherein the indicator comprises a number.
2. The network component of claim 1, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises a UE identity.
3. The network component of claim 1, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises a UE location.
4. The network component of claim 1, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises UE access network information.
5. The network component of claim 1, wherein the network component is an E-CSCF (emergency call session control function).
6. The network component of claim 1, wherein the SIP response message is one of a SIP 1xx or 200 (OK) response.
7. The network component of claim 1, wherein the SIP request message within the dialog is one of: a SIP ACK; a SIP PRACK; a SIP target refresh; a SIP UPDATE; or a SIP RE-INVITE request.
8. The network component of claim 7, wherein the SIP request message is a SIP INVITE request.
9. The network component of claim 2, wherein the UE identity is a globally routable user agent uniform resource identifier (GRUU).
10. The network component of claim 3, wherein a geolocation header field of the SIP request message within the dialog includes a URI (Uniform Resource Identifier) that points to the UE location.
11. The network component of claim 1, wherein a message body of the SIP request message within the dialog includes geographical location information of the UE as a PIDF location object.
12. The network component of claim 1, wherein a contact header field of the SIP request message within the dialog includes a public GRUU value associated with a public user identity.
13. The network component of claim 4, wherein the UE access network information is included in a P-Access-Network-lnfo header field in the SIP request message within the dialog and comprises one of a location identifier, a cell identifier or an identity of an WLAN access node.
14. The network component of claim 1, wherein the emergency-related information associated with the UE is not contained in the SIP request message for a dialog.
15. The network component of claim 1, wherein the indicator indicating that a SIP request message for a dialog is an emergency-related request comprises a Uniform Resource Name ("URN").
16. The network component of claim 1, wherein the indicator indicates a PSAP function.
17. The network component of claim 1, wherein the indicator indicates 911.
18. A method for a network component to manage emergency-related information, comprising: receiving from a user equipment ("UE") a Session Initiation Protocol ("SIP") request message for a dialog that is an emergency-related request; updating header information of the SIP request message for a dialog; forwarding the SIP request message for a dialog toward a Public Safety Answering Point ("PSAP"); and sending from the network component to the UE a SIP response message in response to the SIP request message, the SIP response message containing a P-Asserted-ldentity header field indicating that the network component is part of a trust domain, the P-Asserted-ldentity header field including an indicator indicating that the SIP request message for a dialog, sent by the UE, is an emergency-related request, and that the UE should include emergency-related information associated with the UE in a SIP request message within the dialog in response to the SIP response message, the emergency-related information comprising location information; wherein the indicator comprises a number.
19. The method of claim 18, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises a UE identity.
20. The method of claim 18, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises a UE location.
21. The method of claim 18, wherein the emergency-related information associated with the UE contained in the SIP request message within the dialog comprises UE access network information.
22. The method of claim 18, wherein the network component is an E-CSCF (emergency call session control function).
23. The method of claim 18, wherein the SIP response message is one of a SIP 1xx or 200 (OK) response.
24. The method of claim 18, wherein the SIP request message within the dialog is one of: a SIP ACK; a SIP PRACK; a SIP target refresh; a SIP UPDATE; or a SIP RE-INVITE request.
25. The method of claim 24, wherein the SIP request message is a SIP INVITE request.
26. The method of claim 19, wherein the UE identity is a globally routable user agent uniform resource identifier (GRUU).
27. The method of claim 20, wherein a geolocation header field of the SIP request message within the dialog includes a URI (Uniform Resource Identifier) that points to the UE location.
28. The method of claim 18, wherein a message body of the SIP request message within the dialog includes geographical location information of the UE as a PIDF location object.
29. The method of claim 18, wherein a contact header field of the SIP request message within the dialog includes a public GRUU value associated with a public user identity.
30. The method of claim 21, wherein the UE access network information is included in a P-Access-Network-lnfo header field in the SIP request message within the dialog and comprises one of a location identifier, a cell identifier or an identity of an WLAN access node.
31. The method of claim 18, wherein the emergency-related information associated with the UE is not contained in the SIP request message for a dialog.
32. The method of claim 18, wherein the indicator indicating that a SIP request message for a dialog is an emergency-related request comprises a Uniform Resource Name ("URN").
33. The method of claim 18, wherein the indicator indicates a PSAP function.
34. The method of claim 18, wherein the indicator indicates 911.
35. A non-transitory computer readable medium storing instructions to cause a processor to perform operations comprising: receiving from a user equipment ("UE") a Session Initiation Protocol ("SIP") request message for a dialog that is an emergency-related request; updating header information of the SIP request message for a dialog; forwarding the SIP request message for a dialog toward a Public Safety Answering Point ("PSAP"); and sending from the network component to the UE a SIP response message in response to the SIP request message, the SIP response message containing a P-Asserted-ldentity header field indicating that the network component is part of a trust domain, the P-Asserted-ldentity header field including an indicator indicating that the SIP request message for a dialog, sent by the UE, is an emergency-related request, and that the UE should include emergency-related information associated with the UE in a SIP request message within the dialog in response to the SIP response message, the emergency-related information comprising location information; wherein the indicator comprises a number.
36. The computer readable medium of claim 35, wherein the indicator indicates 911.
37. The computer readable medium of claim 35, wherein the emergency-related information associated with the UE is not contained in the SIP request message for a dialog.
38. The computer readable medium of claim 35, wherein the indicator indicating that a SIP request message for a dialog is an emergency-related request comprises a Uniform Resource Name ("URN").
39. The computer readable medium of claim 35, wherein the indicator indicates a PSAP function.
40. The computer readable medium of claim 35, wherein the indicator indicates 911.
The emergency-related indicator can be encoded in SIP using the following alternatives: a) SIP bodies such as "application/3gpp-ims+xml" have been used in IMS to indicate additional information or directives to receiving UAs. It can be extended to also indicate to the UE that, upon receipt in an INVITE or similar request, the request is to be taken as an emergency call or PSAP callback and that the functionality associated with calls of such type is to be invoked. This functionality may include but it not limited to alerting the user by visual, audible, or other methods as well as including location information in the response. A new content-disposition header field value may need to be defined. b) A new SIP header could be defined or an existing SIP header could be enhanced. The PSAP itself or the S-CSCF handling the PSAP call back on behalf of the PSAP or another network element such as a signaling gateway can introduce an indicator. c) The indicator could be a new SIP header field. d) The indicator could be a new SIP header field value, e.g., a standardized SIP URN indicating the PSAP function (e.g. mountain rescue or coast guard or general 911) or emergency centre function or emergency personnel function. e) The indicator could be a new URI field. f) The indicator could be a new URI field value, e.g., user=psap, where `user` is a SIP URI field and `psap` is a new value that might be put in the Contact header field. g) The standardized SIP URN could be put in the P-Asserted-Identity by the trust domain in which the PSAP or emergency centre or emergency personnel resides. h) The indicator could be contained in the FROM header field value and the FROM header field value can be asserted according to RFC 4474 or RFC 3893. This solution is based on certificates.
The policy might be stored in internal or external memory. External memory might be, but is not limited to, PC Card PCMCIA, CompactFlash I CF-I, CompactFlash II CF-II, SmartMedia SM/SMC, Memory Stick MS, Memory Stick Duo MSD, Memory Stick PRO Duo MSPD, Memory Stick PRO-HG Duo MSPDX, Memory Stick Micro M2, Multimedia Card MMC, Multimedia Card RS-MMC, MMCmicro Card MMCmicro, Secure Digital Card SD, SxS SxS, Universal Flash Storage UFS, miniSD Card miniSD, microSD Card microSD, xD-Picture Card xD, Intelligent Stick iStick, Serial Flash Module SFM, .mu. card .mu. card, NT Card NT NT+, USIM, R-UIM, etc.
TABLE-US-00002 /<X>/Emergency Location policy upon PSAP call back/ The Emergency Location policy leaf indicates whether the UE provides emergency information or not for emergency call back. .cndot. Occurrence: One .cndot. Format: bool .cndot. Access Types: Get, Replace .cndot. Values: 0, 1 0 - UE provides emergency information. 1 - UE does not provide emergency information. <Node> <NodeName> Emergency Location policy </NodeName> <DFProperties> <AccessType> <Get/> <Replace/> </AccessType> <DFFormat> <bool/> </DFFormat> <Occurrence> <One/> </Occurrence> <DFTitle> Emergency Location policy </DFTitle> <DFType> <MIME>text/plain</MIME> </DFType> </DFProperties> </Node
Two examples can illustrate cases where the network rejects the request because the type of emergency session request is not supported. In the first example, RFC 5031 defines urn:service:sos.animal-control as follows: Animal control typically 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 for the housing and care of homeless animals, among other animal-related services. In some jurisdictions, a request to urn:service:sos.animal-control may not be classified as an emergency in the sense that it is subjected to network and operator emergency procedures (e.g. allow or disallow a request to urn:service:sos.animal-control when the UE didn't register or has insufficient credentials). If so configured, the network could either reject with an indication that the call is not actually an emergency or it could reject with an indication that the call is not an emergency and offer alternative steps to be executed such as offering a different URI to contact and/or a different Circuit Switched (CS) network address such as a digit string. Note that, since emergency service URNs are not routable and are not E.164 numbers, the UE may not be able to proceed lacking knowledge of routable addresses or numbers. In those jurisdictions, it would be inappropriate if the UE executed emergency procedures (as specified in 3GPP TS 24.008) and a UE should not automatically contact, for example, "911" or "112" upon receiving a rejection when contacting, e.g., urn:service:sos.animal-control.
However, at present no mapping for urn:service:sos.animal-control exists. A mapping for some other emergency services as defined in RFC 5031 (e.g. urn:service:sos.police) can be made by setting the corresponding bit in Emergency Category Value (e.g. urn:service:sos.police maps to Bit 1 of the Emergency Service Category Value, urn:service:sos.ambulance maps to Bit 2 of the Emergency Service Category Value, urn:service:sos.fire maps to Bit 3 of the Emergency Service Category Value, urn:service:sos.marine maps to Bit 4 of the Emergency Service Category Value, urn:service:sos.mountain maps to Bit 5 of the Emergency Service Category Value). urn:service:sos.animal-control, urn:service:sos.physician, urn:service:sos.poison, urn:service:sos.gas, and others could map to an Emergency Service Category Value with no bits set "1", causing the call to be routed to an operator-defined default emergency centre. Alternatively, for requests for which no PSAP is supported in the network, the UE could be instructed to make a normal SIP request (using procedures in 3GPP TS 24.228) or setup a normal CS call (using procedures in 3GPP TS 24.008). The network could accomplish such by not indicating an alternative address that cannot be mapped to an Emergency Service Category Value (i.e. not one of the urn:service:sos URNs for which a mapping is standardized). When an emergency request is received by the PSAP but the PSAP cannot handle the request and returns a SIP 380 or a similar message, if a mapping exists on the UE from the given URN to an Emergency Service Category Value, a call shall be setup to that CS PSAP E.164 number automatically.
In the second example: the P-CSCF may determine that the emergency request is made to urn:service:sos.police. However, for example in the Netherlands, contacting the police does not per definition warrant activating emergency procedures. Instead, a special number different from "112" is configured: 0900-8844. Other examples are "19" Police (Albania)", "100" (Police and Fire Brigade (Greek cities)), "100" (Ambulance and Fire Brigade (Belgium)), "112" (Police and Ambulance (Italy)), "112" (General emergency call, all categories (Sweden)), "115" (Fire Brigade (Italy)), "144" (Ambulance (Austria)), "*377" (local police agency or Department of Public Safely office, non-emergency roadside assistance in Texas). Such a number may be a premium service. It could be inappropriate if the UE automatically contacted, for example, "911" or "112" if the network rejects the call to urn:service:sos.police, and it could be inappropriate if the network automatically contacted, for example, 0900-8844 as a regular call as the user, without realizing it, may then automatically receive premium charges. The P-CSCF could provide alternative steps such as providing a digit string, e.g., 0900-8844, in a SIP 3xx response. However, the digit string may be part of a message that identifies that the digit string should be displayed and/or that a textual message should be displayed to indicate the nature of the call that was made and the nature of the number provided.
Current proposals add an "alternate attribute" to the existing XML Schema. In an embodiment, the alternate attribute includes a number of alternative addresses, one of which (the last element) could be an indicator encoding the need to route the call to a combined emergency centre by `dashing` together emergency service URNs: e.g. "Urn:service:sos.ambulance-Urn:service:sos.fire". Alternative embodiments could encode the alternative addresses differently in the SIP response, e.g., in the Contact header fields or in a separate, new XML body. Another alternative could be a different encoding such that the indicator would still be a URN or tel URI or SIP URI. For example, urn:service:sos.fire.ambulance (e.g., `dotting` together the emergency sub types).
Alternate address information comprises a mapping between an address, a phone context and one or more optional emergency identifier types. The address indicates the emergency number dialed which could be a telephone number such as `119` for example. The phone context indicates a relevant condition of the UE, such as the location or country the UE is in, and could be a number or a string such as `+81`, the textual string `Japan`, a combination of a number and a string or other information that can be resolved to a location, for example. The textual string (e.g. `Japan`) can be received in multiple languages and multiple character encodings, including Japanese and other non ASCII character sets. The emergency identifier type (e.g. `police`, `fire` or `ambulance` for example) is extendible and indicates the type of emergency service associated with the address for a given phone context. The country or region where the emergency services apply can be identified using applicable ITU, IANA, ISO codes, however, in some cases certain emergency services are provided in an area not coinciding with a "country" or region, in which case a standard ITU, IANA, ISO code might not have been allocated. Some ITI, IANA, ISO or other codes applicable for encoding locations, countries or regions are extendible, such as ISO 3166-1, and the ISO 3166/MA.
The following is an example of an XML body included in a response to a request for an emergency service indicating to the UE that an address (`119` for example) is associated with a different, or a combination of, emergency types (`fire`, `ambulance` or `police` for example) in different phone contexts (`+81` for example). Note that the emergency types are derived from RFC 5031's emergency service URN (i.e. urn:service:sos and its subtypes, police, ambulance, gas, fire, etc., where <police/> can map to urn:service:sos.police, etc.) Note that the emergency type <sos/> can map to the generic service URN urn:service:sos. Note that <sos/> can map to the dial string "112" or to a GSM/UMTS CS domain emergency call setup with all Emergency Service Category Value bits set to `0` (see Table 10.5.135d/3GPP TS 24.008: Service Category information element) such that the call is routed to an operator defined default emergency centre or equivalent signaling in other CS domain technologies such as CDMA. Note that <police/> could also map to setting bit 1 of the Emergency Service Category Value when making a GSM/UMTS emergency call over the CS domain.
The above exemplary XML body indicates that the address `119` can be translated to a different emergency type in a different jurisdiction. For example, the address `119` is associated with `fire` and `ambulance` emergency services when the UE is in a jurisdiction having a phone context of `+81` (Japan) or `+82` (Korea). The address `119` is alternatively associated with `police` emergency services when the UE is in a jurisdiction having a phone context of `+94` (Sri Lanka).
In another embodiment, the UE or network are configured to select or reduce the alternatives in the response and to remove some of the less probable possibilities. Such selection or reduction can be achieved based on the current network of a UE, the home network of the UE, the nationality of the user of the UE, or past travel plans of the user of the UE for example. A UE which performs selection or reduction, could include a policy which hard codes a mapping between an address, an emergency type and phone context, thereby enabling the UE to explicitly select the intended emergency type when making an emergency call over the CS domain or PS domain. On the PS domain, an emergency type can be either indicated per a RFC 5031 URN or per a TEL URL including a country or region indicator such as `phone context`. An emergency type selection function on the UE could be further enhanced if the UE is aware of the country or region it is in and if a locally stored or received mapping of emergency types, location indicators and emergency call addresses is present. The emergency type selection function could then determine that that in certain countries or regions a certain mapping does or does NOT apply, or the mapping applies universally (e.g. for UMTS/GSM handsets the number "112" can map to a GSM/UMTS CS domain emergency call setup with all Emergency Service Category Value bits set to `0` (see Table 10.5.135d/3GPP TS 24.008: Service Category information element)).
shall respond to the INVITE request with a 380 (Alternative Service) response; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML, body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) if the Accept header indicates support for version 2 of the XML Schema for the IM CN subsystem XML body then, a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, otherwise, a <type> child element, set to "emergency"; c) a <reason> child element, set to an operator configurable reason.
shall respond to the INVITE request with a 380 (Alternative Service) response; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML, body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, c) a <reason> child element, set to an operator configurable reason.
If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user the P-CSCF shall inspect the Request URI independent of values of possible entries in the received Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from these configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF shall: 0) determine the geographical location of the UE. Access technology specific procedures are described in each access technology specific annex. If the P-CSCF is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or the IP-CAN to which the UE is attached or the UE is roaming or the P-CSCF is in a different network than the UE's home operator's network, then the P-CSCF: shall reject the request by returning a 380 (Alternative Service) response to the UE; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML, body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) if the Accept header indicates support for version 2 of the XML Schema for the IM CN subsystem XML body then, a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, and if the initial request for a dialog, or standalone transaction, or unknown method was for a supported type of emergency, the <type> child element is set to "emergency" to indicate that it was a supported emergency call, otherwise, a <type> child element, set to "emergency"; c) a <reason> child element, set to an operator configurable reason; and d) an <action> child element, set to "emergency-registration" 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 serving geographic area of the home IM CN subsystem. NOTE 1a: "sip:911@example.com;user=phone" could be an alternate emergency service URI. "urn:service:sos animal-control" could be an unsupported type of emergency call. NOTE 2: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE.
If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown method, for a registered user the P-CSCF shall inspect the Request URI independent of values of possible entries in the received Route headers for known emergency service identifiers, i.e. emergency numbers and the emergency service URN from these configurable lists. If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF shall: 0) determine the geographical location of the UE. Access technology specific procedures are described in each access technology specific annex. If the P-CSCF is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or the IP-CAN to which the UE is attached or the UE is roaming or the P-CSCF is in a different network than the UE's home operator's network, then the P-CSCF: shall reject the request by returning a 380 (Alternative Service) response to the UE; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, and if the initial request for a dialog, or standalone transaction, or unknown method was for a supported type of emergency, the <type> child element is set to "emergency" to indicate that it was a supported emergency call; c) a <reason> child element, set to an operator configurable reason; and d) an <action> child element, set to "emergency-registration" 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 serving geographic area of the home IM CN subsystem. NOTE 2: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE.
If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or does not support emergency sessions for either the geographical location of the UE is located or the IP-CAN to which the UE is attached, the P-CSCF shall not forward the INVITE request. The P-CSCF: shall respond to the INVITE request with a 380 (Alternative Service) response; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML, body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) if the Accept header indicates support for version 2 of the XML Schema for the IM CN subsystem XML body then, a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, and if the initial request for a dialog, or standalone transaction, or unknown method was for a supported type of emergency, the <type> child element is set to "emergency" to indicate that it was a supported emergency call, otherwise, a <type> child element, set to "emergency"; c) a <reason> child element, set to an operator configurable reason; and d) an <action> child element, set to "emergency-registration" if the request included an emergency service URN in the Request-URI. NOTE 1: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE. NOTE 1a: "sip:911@example.com;user=phone" could be an alternate emergency service URI. "urn:service:sos animal-control" could be an unsupported type of emergency call. NOTE 2: Some networks only allow session requests with a Request-URI containing an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in draft-ietf-ecrit-service-urn [69].
If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions or due to local policy does not handle emergency sessions or only handles certain type of emergency session request or does not support emergency sessions for either the geographical location of the UE is located or the IP-CAN to which the UE is attached, the P-CSCF shall not forward the INVITE request. The P-CSCF: shall respond to the INVITE request with a 380 (Alternative Service) response; shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem XML body if support for the 3GPP IMS XML body in the Accept header is not indicated; and shall include in the 380 (Alternative Service) response: a Content-Type header field with the value set to associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. The body shall contain: a) an <alternative-service> element, set to the parameters of the alternative service; b) a <type> child element with an "alternate" attribute set to a list of alternate emergency service URIs, and if the initial request for a dialog, or standalone transaction, or unknown method was for a supported type of emergency, the <type> child element is set to "emergency" to indicate that it was a supported emergency call; c) a <reason> child element, set to an operator configurable reason; and d) an <action> child element, set to "emergency-registration" if the request included an emergency service URN in the Request-URI. NOTE 1: Emergency service URN in the request-URI indicates for the network that the emergency call attempt is recognized by the UE. NOTE 2: Some networks only allow session requests with a Request-URI containing an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in draft-ietf-ecrit-service-urn [69].
The <action> element contains the "alternate" attribute and only the value "emergency-registration" in the present document. The "alternate" attribute can be set to a list of alternate emergency service URIs.
Upon generating an initial request for a dialog, or a standalone transaction, or an unknown method, excluding ACK and CANCEL, the UE shall include the Accept header with "application/sdp", the MIME type associated with the 3GPP IMS XML body (see subclause 7.6.1) and any other MIME type the UE is willing and capable to accept. In the event the UE receives a 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method, the response including an IM CN subsystem XML body as described in subclause 7.6 that includes an <alternative service> element with the <type> child element set to "emergency", the UE shall attempt an emergency call as described in subclause 5.1.6. If 1xx or 2xx response to an initial request for a dialog, or a standalone transaction, or an unknown method, contains an emergency session indicator, then the UE shall send a re-INVITE request method according to RFC 3261 [26], and: 1) the UE shall 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 access type as specified in subclause 7.2A.4, the UE shall include a P-Access-Network-Info header and it shall contain a location identifier such as the cell id, line id or the identity of the I-WLAN access node; NOTE 18: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the access network or from a server. Such methods are not in the scope of this specification. 3) the UE shall insert a 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 location information available, then the UE shall include it in the following way: if the UE is aware of the URI that points to where the UE's location is stored, include the URI in the Geolocation header in accordance with draft-ietf-sip-location-conveyance [89]; or if the geographical location information of the UE is available to the UE, include its geographical location information as PIDF location object in accordance with RFC 4119 [90] and include the location object in a message body with the content type application/piDf+xml in accordance with draft-ietf-sip-location-conveyance [89]. The Geolocation header is set to a Content ID in accordance with draft-ietf-sip-location-conveyance [89]; and 5) if the UE has no geographical location information available, the UE shall not include any geographical location information as specified in draft-ietf-sip-location-conveyance [89]; and 6) if a public GRUU value (pub-gruu) has been saved associated with the public user identity and the UE does not indicate privacy of the P-Asserted-Identity, then the UE shall insert the public GRUU (pub-gruu) value in the Contact header as specified in draft-ietf-sip-gruu [93]; otherwise the UE shall include the protected server port in the address in the Contact header. NOTE 19 according to RFC 3261 [26], a reINVITE request can not be sent while another INVITE transaction is in progress in either direction. NOTE 20 it is not necessary for this reINVITE request to change the session parameters. NOTE 21: It is suggested that UE's only use the option of providing a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is not desirable. NOTE 22: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header in any request (except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).
Applying privacy, including removing location and access network information, if the PSAP is within the network's trust domain, can be performed by IMS network elements such as E-CSCF, IBCF or others. It may be preferred that "session" privacy is requested (i.e. Privacy header field set to include the value "session" since P-Access-Network-Info header field is present in most SIP messages). It may be preferred that the E-CSCF receives location such that it can determine the most applicable PSAP and use it in routing the request to the PSAP or emergency response centre. Privacy requirements according to RFC 4244 may also apply but at present no procedures foresee including history information in an emergency services request. The following two additions to 3GPP TS 24.229 apply to Procedures at the E-CSCF: When the E-CSCF receives a request for a dialog requesting privacy or standalone transaction requesting privacy or any request or response related to a UE-originated dialog requesting privacy or standalone transaction requesting privacy, and if local operator policy allows user request for suppression of public user identifiers and location information, the E-CSCF shall: apply any privacy required by RFC 3323 [33] relating to privacy and RFC 3325 [34] to the P-Asserted-Identity header; if present, remove the P-ACCESS-NETWORK-INFO header field; if present, remove the location object from the message's body and remove the content type application/pidf+xml from the Content-Type header field; if present, remove the Geolocation header field. NOTE: Operator policies (e.g. requirements for support of emergency communications) may over-ride the user request for suppression. 6) select, based on location information and optionally type of emergency service: a PSAP connected to the IM CN subsystem network and add the PSAP URI to the topmost Route header; or NOTE 3: If the user did not request privacy, the E-CSCF conveys 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. a PSAP in the PSTN, add the BGCF URI to the topmost Route header and add a PSAP URI in tel URI format to the Request-URI with an entry used in the PSTN/CS domain to address the PSAP; NOTE 4: If the user did not request privacy, the E-CSCF conveys the P-Access-Network-Info header containing the location identifier, if defined for the access type as specified in subclause 7.2A.4, towards the MGCF. The MGCF can translate the location information if included in INVITE (i.e. both the geographical location information in PIDF-LO and the location identifier in the P-Access-Network-Info header) into ISUP signalling, see 3GPP TS 29.163 [11B]. NOTE 5: The E-CSCF can request location information and routeing information from the LRF. The E-CSCF can for example send the location identifier to LRF and LRF maps the location identifier into the corresponding geographical location information that LRF sends to E-CSCF. The LRF can invoke an RDF to convert the location information into a proper PSAP/EC URI. Both the location information and the PSAP URI are returned to the E-CSCF. NOTE 6: The way the E-CSCF determines the next hop address when the PSAP address is a tel URI is implementation dependent. 7) If the user did not request privacy and if the E-CSCF receives a reference number from the LRF the E-CSCF shall include the reference number in the P-Asserted-Identity header; NOTE 7: The reference number is used in the communication between the PSAP and LRF.
FIG. 6 illustrates a software environment 602 that may be implemented by the DSP 502. The DSP 502 executes operating system drivers 604 that provide a platform from which the rest of the software operates. The operating system drivers 604 provide drivers for the node hardware with standardized interfaces that are accessible to application software. The operating system drivers 604 include application management services ("AMS") 606 that transfer control between applications running on the UE 110. Also shown in FIG. 6 are a web browser application 608, a media player application 610, and Java applets 612. The web browser application 608 configures the UE 110 to operate as a web browser, allowing a user to enter information into forms and select links to retrieve and view web pages. The media player application 610 configures the UE 110 to retrieve and play audio or audiovisual media. The Java applets 612 configure the UE 110 to provide games, utilities, and other functionality. A component 614 might provide functionality described herein.
Previous Patent US 9,462,615 | Next Patent US 9,462,617