Emergency information sending method and user equipment

Abstract

An emergency information sending method and a user equipment (UE) are provided. The method includes making an initial emergency call (eCall) automatically or manually to a network device; receiving a call from the network device after the initial emergency call ends; determining whether an identifier of the initial emergency call is the same as an identifier of the call from the network device; in response to determine that the identifier of the initial emergency call is the same as the identifier of the call from the network device, sending emergency information to the network device. The method can enhance safety to deliver emergency information from the UE to a network device.

Description

EMERGENCY INFORMATION SENDING METHOD AND USER EQUIPMENTTECHNICAL FIELD

[0001] The present application relates to wireless communication, and more particularly, to an emergency information sending method and a user equipment (UE) .BACKGROUND ART

[0002] In wireless communication, a user equipment (UE) in 5th-generation (5G) communication systems may make an emergency call for help automatically or manually and may transmit emergency information to a network device upon a request from the network device. However, how to ensure safety to transmit the emergency information to the network device is a problem needed to be concerned.SUMMARY

[0003] An object of the present application is to propose an emergency information sending method and a user equipment, which can enhance safety to deliver emergency information from the UE to a network device.

[0004] In a first aspect of the present application, provided is an emergency information sending method, performed by a user equipment (UE) , including making an initial emergency call (eCall) automatically or manually to a network device; receiving a call from the network device after the earlier-made (initial) emergency call ends; determining whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device; in response to determine that the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, sending emergency information to the network device.

[0005] In a second aspect of the present application, provided is a user equipment (UE) , including at least one memory configured to store program instructions; and at least one processor configured to execute the program instructions, which cause the at least one processor to make an initial emergency call (eCall) automatically or manually to a network device; receive a call from the network device after the earlier-made (initial) emergency call ends; determine whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device; in response to determine that the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, send emergency information to the network device.

[0006] In an embodiment of the present application, the method further includes storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request for an emergency sent by the UE as the identifier of the earlier-made (initial) emergency call after successful establishment of an emergency call, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device.

[0007] In an embodiment of the present application, the method further includes emptying the stored URN / URI after a timer expires.

[0008] In an embodiment of the present application, the URN / URI is stored to a memory field in an IP multimedia subsystem (IMS) protocol machine or a non-access stratum (NAS) protocol machine.

[0009] In an embodiment of the present application, the method further includes storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request sent by the UE, regardless if the invite request is for an emergency or a non-emergency, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device.

[0010] In an embodiment of the present application, the determining whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device includes checking if the address of the network device making the call matches one of the addresses obtained by resolving URN / URI from an invite request for an emergency sent by the UE.

[0011] In an embodiment of the present application, the earlier-made (initial) emergency call is an emergency call over IMS (IMS-eCall) .

[0012] In an embodiment of the present application, the emergency information includes a minimum set of emergency related data (MSD) .

[0013] In an embodiment of the present application, the network device includes a public safety answering point (PSAP) .

[0014] In an embodiment of the present application, the UE includes an in-vehicle system (IVS) .

[0015] In a third aspect of the present application, a user equipment includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The processor is configured to perform the above method.

[0016] In a fourth aspect of the present application, a base station includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The processor is configured to perform the above method.

[0017] In a fifth aspect of the present application, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above method.

[0018] In a sixth aspect of the present application, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above method.

[0019] In a seventh aspect of the present application, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above method.

[0020] In an eighth aspect of the present application, a computer program product includes a computer program, and the computer program causes a computer to execute the above method.

[0021] In a ninth aspect of the present application, a computer program causes a computer to execute the above method.

[0022] In the embodiments of the present application, the UE (or IVS) makes an initial emergency call (eCall) automatically or manually to a network device (e.g., PSAP) . When the UE receives a call from the network device after the earlier-made (initial) emergency call ends, the UE determines whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device. If they are the same, the UE sends emergency information to the network device. That is, the UE (or IVS) detects earlier made emergency call to the network device to allow for subsequent request for the emergency information from the network device. One of many advantages for this solution is to increase safety to deliver the emergency information from the UE / IVS to the network device (e.g., PSAP) .DESCRIPTION OF DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present application or related art, the following figures that will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present application, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

[0024] FIG. 1 is a block diagram of one or more user equipments (UEs) and a network device (e.g., P-CSCF, PSAP) of communication in a communication network system according to an embodiment of the present application.

[0025] FIG. 2 is a flowchart of an emergency information sending method according to an embodiment of the present application.

[0026] FIG. 3 is a flowchart of an illustrated example of an emergency information sending method according to an embodiment of the present application.

[0027] FIG. 4 is a block diagram of a wireless communication device according to an embodiment of the present application.

[0028] FIG. 5 is a block diagram of a system for wireless communication according to an embodiment of the present application.DETAILED DESCRIPTION OF EMBODIMENTS

[0029] Embodiments of the disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present application are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

[0030] In this document, the term “ / ” should be interpreted to indicate “and / or. ” A combination such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” or “A, B, and / or C” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any combination may contain one or more members of A, B, or C.

[0031] The following table includes some abbreviations used in some embodiments of the present application:

[0032] This application proposes solution (s) to enhance safety to deliver emergency information from a user equipment (UE) to a network device. This involves detecting earlier made emergency call to the network device to allow for subsequent request for the emergency information. More specifically, after successful establishment of an emergency call, the UE “remembers” that an emergency call had been made and / or  stores an identifier of the earlier-made (initial) emergency call. If the network device calls back, the UE can check if it is safe to deliver the emergency information to the caller.

[0033] FIG. 1 illustrates that, in some embodiments, one or more user equipments (UEs) 10 and a network device 20 in a communication network system 30 according to an embodiment of the present application are provided. The communication network system 30 includes the one or more UEs 10 and the network device 20. The one or more UEs 10 may include a memory 12, a transceiver 13, and a processor 11 coupled to the memory 12 and the transceiver 13. The network device 20 may include a memory 22, a transceiver 23, and a processor 21 coupled to the memory 22 and the transceiver 23. The processor 11 or 21 may be configured to implement proposed functions, procedures and / or methods described in this description. Layers of radio interface protocol may be implemented in the processor 11 or 21. The memory 12 or 22 is operatively coupled with the processor 11 or 21 and stores a variety of information to operate the processor 11 or 21. The transceiver 13 or 23 is operatively coupled with the processor 11 or 21, and the transceiver 13 or 23 transmits and / or receives a radio signal.

[0034] The processor 11 or 21 may include application-specific integrated circuit (ASIC) , other chipset, logic circuit and / or data processing device. The memory 12 or 22 may include read-only memory (ROM) , random access memory (RAM) , flash memory, memory card, storage medium and / or other storage device. The transceiver 13 or 23 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the memory 12 or 22 and executed by the processor 11 or 21. The memory 12 or 22 can be implemented within the processor 11 or 21 or external to the processor 11 or 21 in which case those can be communicatively coupled to the processor 11 or 21 via various means as is known in the art.

[0035] In some embodiments, the processor 11 is configured to make an initial emergency call (eCall) automatically or manually to a network device; receive a call from the network device after the earlier-made (initial) emergency call ends; determine whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device; in response to determine that the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, send emergency information to the network device. This can enhance safety to deliver the emergency information from the UE to the network device.

[0036] In some embodiments, the program instructions further cause the at least one processor to store uniform resource name (URN)  / uniform resource identifier (URI) from an invite request for an emergency sent by the UE as the identifier of the earlier-made (initial) emergency call after successful establishment of an emergency call, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device.

[0037] In some embodiments, the program instructions further cause the at least one processor to empty the stored URN / URI after a timer expires.

[0038] In some embodiments, the URN / URI is stored to a memory field in an IP multimedia subsystem (IMS) protocol machine or a non-access stratum (NAS) protocol machine.

[0039] In some embodiments, the program instructions further cause the at least one processor to store uniform resource name (URN)  / uniform resource identifier (URI) from an invite request sent by the UE, regardless if the invite request is for an emergency or a non-emergency, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device.

[0040] In some embodiments, the program instructions further cause the at least one processor to check if the address of the network device making the call matches one of the addresses obtained by resolving URN / URI from an invite request for an emergency sent by the UE.

[0041] In some embodiments, the earlier-made (initial) emergency call is an emergency call over IMS (IMS-eCall) .

[0042] In some embodiments, the emergency information includes a minimum set of emergency related data (MSD) .

[0043] In some embodiments, the network device includes a public safety answering point (PSAP) .

[0044] In some embodiments, the UE includes an in-vehicle system (IVS) .

[0045] FIG. 2 is a flowchart of an emergency information sending method according to an embodiment of the present application. FIG. 3 is a flowchart of an illustrated example of an emergency information sending method according to an embodiment of the present application. Referring to FIGs. 2 and 3, the emergency information sending method 100 includes the following steps.

[0046] Step 100: making an initial emergency call (eCall) automatically or manually to a network device;

[0047] In this step, the UE makes an initial emergency call (eCall) to a network device. The UE may be any type of UE. In an example, the UE can be an in-vehicle system (IVS) in a vehicle, that is, the call may be made from a car, truck, bus, etc. The network device is for example a public safety answering point (PSAP) , which receives the emergency call. The initial emergency call may be an emergency call over IMS (IMS-eCall) . IMS defines an architecture of logical elements using a session initiation protocol (SIP) for call signaling between network elements and provides a layered approach with defined service, control, and transport planes. The UE may make the eCall or IMS-eCall automatically or manually to the network device (e.g., PSAP) . More specifically, the UE / IVS may transmit an invite request (e.g., SIP INVITE) for an emergency to establish the emergency call with the network device, as that shown in Step a1 of FIG. 3. The invite request may include uniform resource name (URN)  / uniform resource identifier (URI) directed to the PSAP. When the network device accepts the invite request, the emergency call is established (Step a2 of FIG. 3) . The emergency call is ongoing between the UE / IVS and the network device and in due time the emergency call ends (Step a3 of FIG. 3) .

[0048] Step 200: receiving a call from the network device after the earlier-made (initial) emergency call;

[0049] In this step, after the earlier-made (initial) emergency call ends, the UE will receive a call from the network device if the network device calls back (see also Step b of FIG. 3) in response to the emergency  call made by the UE. Conversely, if the network device does not call back in response to the emergency call made by the UE, the UE will not receive the call from the network device. If the UE has the callback from the network device, an identifier of the call from the network device is also received by the UE.

[0050] Step 300: determining whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device;

[0051] In this step, the UE compares an identifier of the earlier-made (initial) emergency call with an identifier of the call from the network device and determines whether they are the same. More specifically, the UE / IVS may determine whether it has an earlier-made (initial) eCall to a PSAP which calls the UE / IVS (see Step c of FIG. 3) . For example, the UE may have URN / URI address of the network device when transmitting the invite quest for an emergency to the network device at the time of making the earlier-made (initial) emergency call. The UE may have the identifier of the call from the network device once receiving a callback from the network device. The URN / URI of the network device may be used to compare with the identifier of the call from the network device to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device.

[0052] Step 400: in response to determine that the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, sending emergency information to the network device.

[0053] In this step, the UE will send emergency information to the network device if the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device. The emergency information may include or may be a minimum set of emergency related data (MSD) . The MSD forms the data component of an eCall sent from a vehicle to a PSAP or other designated emergency call centre. This includes the location information of the vehicle, direction of travel, number of passengers with fastened seat belts, vehicle information, and other information deemed relevant for the emergency service agencies. Only when the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, the UE sends out the emergency information via eCall. In one of the advantages, this can ensure safety to deliver emergency information from the UE to the network device.

[0054] In the embodiments of the present application, the UE (or IVS) makes an earlier-made (initial) emergency call (eCall) automatically or manually to a network device (e.g., PSAP) . When the UE receives a call from the network device after the earlier-made (initial) emergency call, the UE determines whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device. If they are the same, the UE sends emergency information to the network device. That is, the UE (or IVS) detects earlier made emergency call to the network device to allow for subsequent request for the emergency information from the network device. One of many advantages for this solution is to increase safety to deliver the emergency information from the UE / IVS to the network device (e.g., PSAP) .

[0055] In some embodiments, the emergency information sending method 100 may further include storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request for an emergency sent by the UE as the identifier of the earlier-made (initial) emergency call after successful establishment  of an emergency call, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device. More specifically, in an exemplary example, in a case that the earlier-made (initial) emergency call is an emergency call over IMS (i.e., IMS-eCall) , after successful establishment of an IMS emergency call (the "urn: service: sos. ecall. automatic" or "urn: service: sos. ecall. manual" as the Requested URI in the SIP INVITE request by the UE) , the UE can store the requested emergency URN as “Last Dialled / Requested URN / URI” . Then, the “Last Dialled / Requested URN / URI” can be used to compare with the identifier of the call from the network device (e.g., PSAP) . This can ensure the possible request from the a PSAP to send the emergency information (e.g., MSD) is indeed a callback from the PSAP.

[0056] In some embodiments, the emergency information sending method 100 may further include emptying the stored URN / URI after a timer expires. More specifically, in an exemplary example, the UE may empty the stored emergency URN after an implementation dependent timer expires. This can limit the duration between the earlier-made (initial) emergency call by the UE and the callback from the network device, thereby further ensuring that the emergency information (e.g., MSD) is sent indeed in response to a callback from the network device (e.g., PSAP) . This may also shorten the time for the UE to wait for a callback from the network device (e.g., PSAP) .

[0057] In some embodiments, the URN / URI is stored to a memory field in an IP multimedia subsystem (IMS) protocol machine or a non-access stratum (NAS) protocol machine. More specifically, in an exemplary example, to determine the last call made was to a PSAP is to introduce with the UE's IMS protocol machine (or NAS protocol machine) a new memory field which the UE can store an indication “Last Dialled / Requested URN / URI” of the last call made.

[0058] In some embodiments, the emergency information sending method 100 may further include storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request sent by the UE, regardless if the invite request is for an emergency or a non-emergency, wherein the stored URN / URI is used to determine whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device. More specifically, in an exemplary example, when an INVITE request is sent out by the UE for establishing a call with another party, the UE always stores the requested URI in the “Last Dialled / Requested URN / URI” , regardless if the INVITE request is for an emergency or a non-emergency.

[0059] In some embodiments, the determining whether the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device may include checking if the address of the network device making the call matches one of the addresses obtained by resolving URN / URI from an invite request for an emergency sent by the UE. More specifically, in an exemplary example, the UE may check if the SIP address of the caller matches one of the PSAP addresses obtained by resolving the emergency URN.

[0060] FIG. 4 illustrates a wireless communication device 1000 according to an embodiment of the present application. The wireless communication device 1000 includes an eCall making part 1001 configured to  make an initial emergency call (eCall) automatically or manually to a network device; a call receiving part 1002 configured to receive a call from the network device after the earlier-made (initial) emergency call; a determining part 1003 configured to determine whether an identifier of the earlier-made (initial) emergency call is the same as an identifier of the call from the network device; a sending part 1004 configured to, in response to determine that the identifier of the earlier-made (initial) emergency call is the same as the identifier of the call from the network device, send emergency information to the network device. This can enhance safety to deliver the emergency information from the UE to the network device.

[0061] It should be noted that CEN requirements are not universally adopted globally. Whereas 3GPP specifications set out requirements for all countries deploying mobile systems based on 3GPP specifications, some, many, of these countries do not or are not obliged to follow CEN requirements. Therefore, it is not possible to modify the existing 3GPP specifications by mandating CEN requirements upon non-CEN abiding countries and regulatory bodies. 3GPP specifications shall rather make clear that these requirements are applicable only to the PLMNs in CEN member countries (may later become applicable also to the affiliated and partner countries) .

[0062] With the proposed solution applied, 3GPP TS 24.229 subclauses 5.1.6.11.2 and 5.1.6.11.3 may be changed as below.

[0063] 5.1.6.11.2 Initial INVITE request

[0064] If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service or of the manually initiated eCall type of emergency service and if allowed by IP-CAN specific annex, the UE shall send an INVITE request as specified in the procedures in subclause 5.1.6.8 with the following additions:

[0065] 1) the UE shall set the Request-URI to "urn: service: sos. ecall. automatic" or "urn: service: sos. ecall. manual" ; and

[0066] 2) if the IP-CAN indicates the eCall support indication, the UE shall:

[0067] a) insert a multipart / mixed body containing an "application / EmergencyCallData. eCall. MSD" MIME body part as defined in RFC 8147

[0244] , containing the MSD not exceeding 140 bytes and encoded in binary ASN. 1 PER as specified in CEN EN 15722: 2015

[0245] and include a Content-Disposition header field with a "handling" header field parameter with an "optional" value, as described in RFC 3261

[0026] ;

[0068] b) insert an Accept header field indicating the UE is willing to accept an "application / EmergencyCallData. Control+xml" MIME type as defined in RFC 8147

[0244] ; and

[0069] c) insert a Recv-Info header field set to "EmergencyCallData. eCall. MSD" as defined in RFC 8147

[0244] .

[0070] NOTE: Further content for the INVITE is as defined in RFC 8147

[0244] .

[0071] Then the UE shall proceed as follows:

[0072] 1) if the UE receives a 200 (OK) response to the INVITE request not containing:

[0073] a) a multipart / mixed body containing an "application / EmergencyCallData. Control+xml" MIME body part as defined in RFC 8147

[0244] with an "ack" element containing:

[0074] i) a "received" attribute set to "true" ; and

[0075] ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

[0076] then the UE shall send the MSD using audio media stream encoded as described in 3GPP TS 26.267 [9C] ;

[0077] 2) if the UE receives a 200 (OK) response to the INVITE request containing:

[0078] a) a multipart / mixed body containing an "application / EmergencyCallData. Control+xml" MIME body part as defined in RFC 8147

[0244] with an "ack" element containing:

[0079] i) a "received" attribute set to "true" ; and

[0080] ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

[0081] then the UE shall consider the initial MSD transmission as successful;

[0082] 3) if the UE receives a 486 (Busy Here) , 600 (Busy Everywhere) or 603 (Decline) response to the INVITE request containing:

[0083] a) a multipart / mixed body containing an "application / EmergencyCallData. Control+xml" MIME body part as defined in RFC 8147

[0244] with an "ack" element containing:

[0084] i) a "received" attribute set to "true" ; and

[0085] ii) a "ref" attribute set to the Content-ID of the MIME body part containing the MSD sent by the UE;

[0086] then the UE shall consider the initial MSD transmission as successful and shall perform domain selection to re-attempt the eCall as specified in 3GPP TS 23.167 [4B] ; and

[0087] 4) in all other cases, the UE shall perform domain selection to re-attempt the eCall as specified in 3GPP TS 23.167 [4B] .

[0088] If the CEN requirements apply, after successful establishment of an IMS emergency call, the UE shall store the requested emergency URN (see subclause 5.1.6.8.1) . This is necessary to ensure the possible request to send the MSD is indeed a callback from a PSAP (see subclause 5.1.6.11.3) . As an implementation option, the UE checks if the SIP address of the caller matches one of the PSAP addresses obtained by resolving the emergency URN. UE may empty the stored emergency URN after an implementation dependent timer expires.

[0089] 5.1.6.11.3 Transfer of an updated MSD

[0090] After an emergency session for eCall type of emergency service is over as described in subclause 5.1.6.11.2, if a PSAP calls back, the following shall apply. If the UE receives an INFO request with:

[0091] 1) an Info-Package header field set to "EmergencyCallData. eCall. MSD" as defined in RFC 8147

[0244] ;

[0092] 2) a multipart / mixed body including:

[0093] a) an "application / EmergencyCallData. Control+xml" MIME body part as defined in RFC 8147

[0244] containing a "request" element with an "action" attribute set to "send-data" and a "datatype" attribute set to "eCall. MSD" ; and

[0094] b) a Content-Disposition header field set to "By-Reference" associated with the "application / EmergencyCallData. Control+xml" MIME body part; and

[0095] 3) a Content-Disposition header field set to "Info-Package" associated with the multipart / mixed body;

[0096] the UE shall proceed as follows:

[0097] 1) if the UE is able to provide an updated MSD, the UE shall send an INFO request containing:

[0098] a) an Info-Package header field set to "EmergencyCallData. eCall. MSD" as defined in RFC 8147

[0244] ;

[0099] b) a multipart / mixed body including:

[0100] i) an "application / EmergencyCallData. eCall. MSD" MIME body part as defined in RFC 8147

[0244] containing the MSD not exceeding 140 bytes and encoded in binary ASN. 1 as specified in CEN EN 15722: 2015

[0245] ; and

[0101] ii) a Content-Disposition header field set to "By-Reference" associated with the "application / EmergencyCallData. eCall. MSD" MIME body part; and

[0102] c) a Content-Disposition header field set to "Info-Package" associated with the multipart / mixed body; and

[0103] 2) if the UE is not able to provide an updated MSD, the UE shall send an INFO request containing:

[0104] a) an Info-Package header field set to "EmergencyCallData. eCall. MSD" as defined in RFC 8147

[0244] ;

[0105] b) a multipart / mixed body including:

[0106] i) an "application / EmergencyCallData. Control+xml" MIME body part as defined in RFC 8147

[0244] with an "ack" element containing:

[0107] - a "ref" attribute set to the Content-ID of the "application / EmergencyCallData. Control+xml" MIME body part in the INFO request received by the UE; and

[0108] - an "actionResult" child element containing:

[0109] A) an "action" attribute set to "send-data" ;

[0110] B) a "success" attribute set to "false" ; and

[0111] C) a "reason" attribute set to an appropriate value as defined in RFC 8147

[0244] ; and

[0112] ii) a Content-Disposition header field set to "By-Reference" associated with the "application / EmergencyCallData. Control+xml" MIME body part; and

[0113] c) a Content-Disposition header field set to "Info-Package" associated with the multipart / mixed body.

[0114] NOTE: Further content for the INFO request is as defined in RFC 8147

[0244] .

[0115] FIG. 5 is a block diagram of an example system 700 for wireless communication according to an embodiment of the present application. Embodiments described herein may be implemented into the system using any suitably configured hardware and / or software. FIG. 5 illustrates the system 700 including a radio frequency (RF) circuitry 710, a baseband circuitry 720, an application circuitry 730, a memory / storage 740, a display 750, a camera 760, a sensor 770, and an input / output (I / O) interface 780, coupled with each other at least as illustrated. The application circuitry 730 may include a circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general-purpose processors and dedicated processors, such as graphics processors, application processors. The processors may be coupled with the memory / storage and configured to execute instructions stored in the memory / storage to enable various applications and / or operating systems running on the system.

[0116] The baseband circuitry 720 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include a baseband processor. The baseband circuitry may handle various radio control functions that enables communication with one or more radio networks via the RF circuitry. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, the baseband circuitry may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry may support communication with an evolved universal terrestrial radio access network (EUTRAN) and / or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) . Embodiments in which the baseband circuitry is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0117] In various embodiments, the baseband circuitry 720 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. The RF circuitry 710 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. In various embodiments, the RF circuitry 710 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[0118] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to the user equipment, eNB, or gNB may be embodied in whole or in part in one or more of the RF circuitry, the baseband circuitry, and / or the application circuitry. As used herein, “circuitry” may  refer to, be part of, or include an Application Specific Integrated Circuit (ASIC) , an electronic circuit, a processor (shared, dedicated, or group) , and / or a memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, some or all of the constituent components of the baseband circuitry, the application circuitry, and / or the memory / storage may be implemented together on a system on a chip (SOC) . The memory / storage 740 may be used to load and store data and / or instructions, for example, for a system. The memory / storage for one embodiment may include any combination of suitable volatile memory, such as dynamic random access memory (DRAM) , and / or non-volatile memory, such as flash memory.

[0119] In various embodiments, the I / O interface 780 may include one or more user interfaces designed to enable user interaction with the system and / or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface. In various embodiments, the sensor 770 may include one or more sensing devices to determine environmental conditions and / or location information related to the system. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry and / or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0120] In various embodiments, the display 750 may include a display, such as a liquid crystal display and a touch screen display. In various embodiments, the system 700 may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, an AR / VR glasses, etc. In various embodiments, a system may have more or less components, and / or different architectures. Where appropriate, methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

[0121] A person having ordinary skill in the art understands that each of the units, algorithm, and steps described and disclosed in the embodiments of the present application are realized using electronic hardware or combinations of software for computers and electronic hardware. Whether the functions run in hardware or software depends on the condition of application and design requirement for a technical plan. A person having ordinary skill in the art can use different ways to realize the function for each specific application while such realizations should not go beyond the scope of the present application. It is understood by a person having ordinary skill in the art that he / she can refer to the working processes of the system, device, and unit in the above-mentioned embodiment since the working processes of the above- mentioned system, device, and unit are basically the same. For easy description and simplicity, these working processes will not be detailed.

[0122] It is understood that the disclosed system, device, and method in the embodiments of the present application can be realized with other ways. The above-mentioned embodiments are exemplary only. The division of the units is merely based on logical functions while other divisions exist in realization. It is possible that a plurality of units or components are combined or integrated in another system. It is also possible that some characteristics are omitted or skipped. On the other hand, the displayed or discussed mutual coupling, direct coupling, or communicative coupling operate through some ports, devices, or units whether indirectly or communicatively by ways of electrical, mechanical, or other kinds of forms.

[0123] The units as separating components for explanation are or are not physically separated. The units for display are or are not physical units, that is, located in one place or distributed on a plurality of network units. Some or all of the units are used according to the purposes of the embodiments. Moreover, each of the functional units in each of the embodiments can be integrated in one processing unit, physically independent, or integrated in one processing unit with two or more than two units.

[0124] If the software function unit is realized and used and sold as a product, it can be stored in a readable storage medium in a computer. Based on this understanding, the technical plan proposed by the present application can be essentially or partially realized as the form of a software product. Or, one part of the technical plan beneficial to the conventional technology can be realized as the form of a software product. The software product in the computer is stored in a storage medium, including a plurality of commands for a computational device (such as a personal computer, a server, or a network device) to run all or some of the steps disclosed by the embodiments of the present application. The storage medium includes a USB disk, a mobile hard disk, a read-only memory (ROM) , a random access memory (RAM) , a floppy disk, or other kinds of media capable of storing program codes.

[0125] While the present application has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present application is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

1.An emergency information sending method, performed by a user equipment (UE) , comprising:making an initial emergency call (eCall) automatically or manually to a network device;receiving a call from the network device after the initial emergency call ends;determining whether an identifier of the initial emergency call is the same as an identifier of the call from the network device;in response to determine that the identifier of the initial emergency call is the same as the identifier of the call from the network device, sending emergency information to the network device.2.The method of claim 1, further comprising:storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request for an emergency sent by the UE as the identifier of the initial emergency call after successful establishment of an emergency call,wherein the stored URN / URI is used to determine whether the identifier of the initial emergency call is the same as the identifier of the call from the network device.3.The method of claim 2, further comprising:emptying the stored URN / URI after a timer expires.4.The method of claim 2 or 3, wherein the URN / URI is stored to a memory field in an IP multimedia subsystem (IMS) protocol machine or a non-access stratum (NAS) protocol machine.5.The method of claim 1, further comprising:storing uniform resource name (URN)  / uniform resource identifier (URI) from an invite request sent by the UE, regardless if the invite request is for an emergency or a non-emergency,wherein the stored URN / URI is used to determine whether the identifier of the initial emergency call is the same as the identifier of the call from the network device.6.The method of any of claims 1 to 5, wherein the determining whether the identifier of the initial emergency call is the same as the identifier of the call from the network device comprises:checking if the address of the network device making the call matches one of the addresses obtained by resolving URN / URI from an invite request for an emergency sent by the UE.7.The method of any of claims 1 to 6, wherein the initial emergency call is an emergency call over IMS (IMS-eCall) .8.The method of any of claims 1 to 7, wherein the emergency information comprises a minimum set of emergency related data (MSD) .9.The method of any of claims 1 to 8, wherein the network device comprises a public safety answering point (PSAP) .10.The method of any of claims 1 to 9, wherein the UE comprises an in-vehicle system (IVS) .11.A user equipment (UE) , comprising:at least one memory configured to store program instructions; andat least one processor configured to execute the program instructions, which cause the at least one processor to:make an initial emergency call (eCall) automatically or manually to a network device;receive a call from the network device after the initial emergency call ends;determine whether an identifier of the initial emergency call is the same as an identifier of the call from the network device;in response to determine that the identifier of the initial emergency call is the same as the identifier of the call from the network device, send emergency information to the network device.12.The user equipment of claim 11, wherein the program instructions further cause the at least one processor to:store uniform resource name (URN)  / uniform resource identifier (URI) from an invite request for an emergency sent by the UE as the identifier of the initial emergency call after successful establishment of an emergency call,wherein the stored URN / URI is used to determine whether the identifier of the initial emergency call is the same as the identifier of the call from the network device.13.The user equipment of claim 12, wherein the program instructions further cause the at least one processor to:empty the stored URN / URI after a timer expires.14.The user equipment of claim 12 or 13, wherein the URN / URI is stored to a memory field in an IP multimedia subsystem (IMS) protocol machine or a non-access stratum (NAS) protocol machine.15.The user equipment of claim 11, wherein the program instructions further cause the at least one processor to:store uniform resource name (URN)  / uniform resource identifier (URI) from an invite request sent by the UE, regardless if the invite request is for an emergency or a non-emergency,wherein the stored URN / URI is used to determine whether the identifier of the initial emergency call is the same as the identifier of the call from the network device.16.The user equipment of any of claims 11 to 15, wherein the program instructions further cause the at least one processor to:check if the address of the network device making the call matches one of the addresses obtained by resolving URN / URI from an invite request for an emergency sent by the UE.17.The user equipment of any of claims 11 to 16, wherein the initial emergency call is an emergency call over IMS (IMS-eCall) .18.The user equipment of any of claims 11 to 17, wherein the emergency information comprises a minimum set of emergency related data (MSD) .19.The user equipment of any of claims 11 to 18, wherein the network device comprises a public safety answering point (PSAP) .20.The user equipment of any of claims 11 to 19, wherein the UE comprises an in-vehicle system (IVS) .21.A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 10.22.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 10.23.A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 10.24.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 10.25.A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 49.

Images