Communication methods and communication devices

Abstract

Provided are communication methods and communication devices. A method comprises: a terminal device sends a first request to a first device, the first request being used for requesting testing an emergency call, and the first request comprising a URN used for testing the emergency call.

Description

Communication methods and communication equipment Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a communication method and a communication device. Background Technology

[0002] Vehicle emergency call (eCall) systems are gradually becoming an important tool for ensuring road safety. By integrating mobile communication technology and satellite positioning, this system can automatically or manually activate after an accident to quickly establish contact with a public safety answering point (PSAP), providing accurate accident information and significantly improving rescue response speed and life-saving efficiency.

[0003] Currently, the European Committee for Standardization (CEN) has introduced new requirements for 3GPP specifications, stipulating that the testing process for emergency calls should not interfere with the emergency services provided by PSAP.

[0004] Summary of the Invention

[0005] This application provides a communication method and a communication device. The various aspects covered by this application are described below.

[0006] In a first aspect, a communication method is provided, comprising: a terminal device sending a first request to a first device, the first request being used to request a test emergency call, the first request including a uniform resource name (URN) for testing the emergency call.

[0007] In a second aspect, a communication method is provided, comprising: a first device receiving a first request sent by a terminal device, the first request being used to request a test emergency call, the first request including a URN for testing the emergency call.

[0008] Thirdly, a communication device is provided, the communication device being a terminal device, the communication device comprising: a communication module, configured to send a first request to a first device, the first request being used to request a test emergency call, the first request including a URN for testing the emergency call.

[0009] Fourthly, a communication device is provided, the communication device being a first device, the communication device comprising: a communication module, configured to receive a first request sent by a terminal device, the first request being for requesting to conduct a test emergency call, the first request including a URN for testing the emergency call.

[0010] Fifthly, a communication device is provided, including a transceiver, a memory, and a processor, wherein the memory is used to store a program, the processor is used to invoke the program in the memory, and to control the transceiver to receive or transmit signals, so that the communication device performs the method as described in the first or second aspect.

[0011] A sixth aspect provides an apparatus including a processor for calling a program from a memory to cause the apparatus to perform the method as described in the first or second aspect.

[0012] A seventh aspect provides a chip including a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in the first or second aspect.

[0013] Eighthly, a computer-readable storage medium is provided having a program stored thereon that causes a computer to perform the method as described in the first or second aspect.

[0014] Ninth aspect, a computer program product is provided, characterized in that it includes a program that causes a computer to perform the method as described in the first or second aspect.

[0015] In a tenth aspect, a computer program is provided that causes a computer to perform the method as described in the first or second aspect.

[0016] This application defines a URN for testing emergency calls. The introduction of this URN facilitates the establishment of test emergency calls between terminal devices and nodes other than the PSAP, thereby avoiding interference with the emergency services provided by the PSAP. Attached Figure Description

[0017] Figure 1 is a system architecture example diagram of a wireless communication system applicable to embodiments of this application.

[0018] Figure 2 is a structural example of the eCall system.

[0019] Figure 3 is a structural example of the eCall system shown in Figure 2.

[0020] Figure 4 is a flowchart illustrating the communication method provided in an embodiment of this application.

[0021] Figure 5 is a schematic diagram of the structure of a communication device provided in one embodiment of this application.

[0022] Figure 6 is a schematic diagram of the structure of a communication device provided in another embodiment of this application.

[0023] Figure 7 is a schematic diagram of a device applicable to embodiments of this application. Detailed Implementation

[0024] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0025] Wireless communication system

[0026] Figure 1 is a system architecture example diagram of a wireless communication system 100 applicable to embodiments of this application. The wireless communication system 100 may include a network device 110 and a terminal device 120. The network device 110 may be a device that communicates with the terminal device 120. The network device 110 can provide network coverage for a specific geographical area and can communicate with the terminal device 120 located within that coverage area. The terminal device 120 can access a network (such as a wireless network) through the network device 110. Optionally, the wireless communication system 100 may also include other network entities such as a network controller and a mobility management entity; this embodiment of the application does not limit this.

[0027] It should be understood that the technical solutions of the embodiments of this application can be applied to various communication systems, such as 5G systems or new radio (NR), long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided in this application can also be applied to future communication systems, such as sixth-generation mobile communication systems, satellite communication systems, and so on.

[0028] The terminal device in this application embodiment can also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user device. The terminal device in this application embodiment can be a device that provides voice and / or data connectivity to a user, and can be used to connect people, objects, and machines, such as a handheld device with wireless connectivity, vehicle-mounted device, etc. The terminal devices in the embodiments of this application can be mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, self-driving, remote medical surgery, smart grids, transportation safety, smart cities, and smart homes, etc. Optionally, the terminal device can act as a base station. For example, the terminal device can act as a scheduling entity, providing sidelink signals between terminal devices in vehicle-to-everything (V2X) or device-to-device (D2D) systems. For instance, cellular phones and cars communicate with each other using sidelink signals. Cellular phones and smart home devices communicate without relaying communication signals through base stations.

[0029] The network device in this application embodiment can be a device for communicating with terminal devices. This network device can be, for example, an access network device or a wireless access network device. For instance, the network device can be a base station. The term "base station" can broadly encompass various names, or be replaced by, the following: NodeB, evolved NodeB (eNB), next-generation NodeB (gNB), relay station, access point, transmitting and receiving point (TRP), transmitting point (TP), home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. A base station can be a macro base station, micro base station, relay node, donor node, or the like, or a combination thereof.

[0030] In traditional communication systems (such as traditional NR systems), network devices periodically send system information (such as system information blocks (SIBs)). This system information is very important for idle terminal devices because they can use it to access the cell.

[0031] However, some information in the periodically transmitted system messages is wasted (for example, at a certain moment, a network device sends system information, but no terminal device needs to receive it at that time). Furthermore, because network devices need to constantly maintain system information, they cannot enter deep sleep mode to save power. According to operator statistics, electricity consumption is one of the main sources of operators' operating costs. Therefore, reducing the power consumption of network devices would not only help to better operate future cellular systems but also benefit the ecosystem (such as reducing carbon emissions and thus slowing down global warming).

[0032] However, if network devices directly delete system information, idle terminal devices will be unable to access the cell. Therefore, an ideal approach is for terminal devices to request cell system information on demand, while network devices transmit system information to terminal devices only when necessary.

[0033] Therefore, the embodiments of this application are concerned with how to effectively communicate with a cell while considering network energy saving. This solution can be applied to communication systems provided by related technologies, such as NR systems, and can also be applied to future communication systems, such as sixth-generation (6G) communication systems.

[0034] eCall system

[0035] Figure 2 shows the system architecture of the eCall system used in this application embodiment. The eCall system includes: an in-vehicle terminal device 120, a network 130, and a public safety answering point (PSAP) 140. The in-vehicle terminal device 120 includes an in-vehicle system (IVS). When the IVS in the in-vehicle terminal device detects a traffic accident, it initiates an eCall. Voice data is sent to the PSAP via voice channel 100, and relevant information such as the vehicle's current global positioning system (GPS) coordinates, the time of the accident, and vehicle description are sent to the PSAP in minimum set of data (MSD) format via data channel 110. It should be noted that the PSAP can be implemented using a server.

[0036] Specifically, as shown in Figure 3, the IVS in the vehicle-mounted terminal equipment 120 may include one or more of the following: an MSD information source, an IVS data modern, a GPS receiver, a microphone and speaker, a speech codec, and a radio modern. The network 130 may include a public land mobile network (PLMN) and a public switched telephone network (PSTN) / global switched telephone network (GSTN). The PLMN may include one or more of the following: a base station controller (BTS), a transcoding and rate adaptation unit (TRAU), and a mobile switching center (MCS). The PSAP 140 may include a PSAP data modern, an MSD display, and a speaker. The PSAP data modern, MSD display, and speaker may be integrated into the same device or be separate physical entities. When a vehicle accident occurs, the terminal device initiates an eCall to the PSAP via the network and sends the voice data and MSD format data of the eCall to the PASP.

[0037] CEN Requirements for eCall Systems

[0038] On March 12, 2024, CEN sent a liaison statement (LS) to the 3rd Generation Partnership Project (3GPP) technical specification group (TSG) system architecture (SA) and the 3GPP TSG core network and terminals (CT) to notify the 3GPP organization in Europe of new regulations or standards regarding eCall and Internet Protocol Multimedia Subsystem (IMS)-eCall (see CP-241245). These regulations specify the requirements of CEN member countries for PSAP, vehicles, and IVS.

[0039] Currently, CEN member states include: all EU member states; three EFTA member states: Iceland, Norway, and Switzerland; and other countries such as the UK, North Macedonia, Turkey, and Serbia.

[0040] In addition, the current CEN member states include Albania, Armenia, Azerbaijan, Belarus, Bosnia and Herzegovina, Egypt, Georgia, Israel, Jordan, Lebanon, Moldova, Montenegro, Morocco, Tunisia, and Ukraine.

[0041] In addition, CEN's current partner standardization bodies include Australia, Canada, Mongolia, and Kazakhstan.

[0042] In LS (CP-241245), CEN requires 3GPP TSG to modify 3GPP specifications to meet CEN's new requirements for emergency systems. The 3GPP specifications mentioned here mainly refer to 3GPP TS 24.229 (within the scope of responsibility of the 3GPP CT1 working group) and 3GPP TS 23.167 (within the scope of responsibility of the 3GPP SA2 working group).

[0043] In response to CEN's LS, 3GPP TSG CT and SA also issued a liaison statement. This statement requests that the 3GPP CT1 working group (WG) take the lead in investigating the differences between the requirements put forward by CEN and the provisions in the 3GPP specification (3GPP TS 24.229). See 3GPP TSG CT's LS (CP-241307) and 3GPP TSG SA's LS (SP-240973).

[0044] In LS (CP-241245), CEN sets forth the following requirements for the testing process of next-generation (NG) IMS-eCall:

[0045] (a) Testing NG IMS-eCall should include MSD;

[0046] (b) Testing NG IMS-eCall should be performed as a regular IMS-eCall so that testing NG IMS-eCall does not interfere with the emergency services provided by PSAP. Currently, 3GPP TS 24.229 does not specify how terminal equipment should perform testing NG IMS-eCall.

[0047] To address the aforementioned issues, this application defines a URN for testing emergency calls. When a terminal device requests to perform a test emergency call, this URN can be included in the request. By defining this URN, it is easier to establish test emergency calls between the terminal device and other nodes besides PSAP (such as a newly defined test node dedicated to performing test emergency calls), thereby avoiding interference with the emergency services provided by PSAP.

[0048] The embodiments of this application will be described in detail below with reference to Figure 4. It should be noted that the emergency call (eCall) mentioned in the embodiments of this application can refer to an emergency call initiated automatically or manually by a vehicle (or other terminal device capable of initiating an emergency call). This emergency call may carry an MSD (Missing Data Point). The test emergency call mentioned in the embodiments of this application refers to a call initiated to determine whether an emergency call is valid.

[0049] Referring to Figure 4, in step S410, the terminal device sends a first request to the first device. This first request can be used to request to make or initiate a test emergency call. The test emergency call can be, for example, an IMS-based test emergency call (i.e., test IMS-eCall).

[0050] This first request can be called an initial request, an initial INVITE request, or an initial request for a dialog session. This first request may include a URN. This URN can be carried in the request URI of the first request. This URN can be a URN used for testing emergency calls, or in other words, a URN specifically designed for testing emergency calls. For example, this URN can contain one or more fields such as "sos," "ecall," and "test." The specific form of the URN includes both "sos" and "test," thus indicating that this URN corresponds to testing an emergency call. As a more concrete example, the URN could be "urn:service:sos.ecall.test." Of course, the URN can also take other forms, as long as the two parties executing the emergency call test agree on them beforehand.

[0051] In some implementations, the aforementioned test emergency call can be a normal call (i.e., the test emergency call is treated as a non-emergency call, such as a normal IMS call). That is, during the test emergency call process, the terminal device does not need to perform emergency registration; instead, it can use the same registration method as the terminal device initiating a normal call (such as a normal IMS call). The main difference between a test emergency call and other normal IMS calls is that the test emergency call carries a special URN defined specifically for the test emergency call.

[0052] In some implementations, the first request may include a Data Storage Device (MSD). This MSD can be a real MSD; that is, the data in the MSD is real data. However, if the data in the MSD is real data, it may contain private information that does not need to be transmitted during the testing phase of an emergency call. Therefore, in some implementations, the data in the MSD can be replaced with test data or dummy data to protect sensitive data within the MSD.

[0053] If the 3GPP specification adopts the solution provided in this application, some chapters of the 3GPP specification need to be adjusted to adapt to the new requirements proposed by CEN. It should be noted that the requirements specified in the 3GPP specification need to be adopted by all countries that have deployed mobile systems. However, the new requirements proposed by CEN will not be universally adopted globally. That is, the new requirements may only be adopted by CEN member countries, and other countries do not need to comply with them. Therefore, the modification of the 3GPP specification needs to explicitly state that it only applies to the PLMNs of CEN member countries (and may later apply to CEN's allies or partners), and should not force all 3GPP member countries to comply with the requirements. The following section proposes five modifications to 3GPP TS 24.229, of which the first and fifth modifications involve adding two subsections. The first modification mainly reflects CEN's requirements for testing emergency calls. The fifth modification mainly defines the content of the MSD carried in the test emergency call. The second to fourth modifications are partial adjustments to existing chapters in 3GPP TS 24.229. These adjustments are all related to the newly defined URN specifically for testing emergency calls. The introduction of this URN allows terminal devices to establish test emergency calls with a dedicated server (such as a server specifically set up for testing emergency calls, rather than PSAP), thereby avoiding interference with the emergency services provided by PSAP.

[0054] First revision

[0055] A new section 5.1.3.2 has been added to section 5.1.3 (Call initiation-UE-originating case) of 3GPP TS 24.229. The content of this section is as follows:

[0056] 5.1.3.2 CEN requirements for a Test IMS-eCall

[0057] If CEN requirements apply, the Test IMS-eCall is performed as a regular IMS call, meaning the UE must not attempt emergency registration. Therefore, Section 5.1.3.1 applies. The only difference is that, as specified in Sections 5.1.6.8.1, 5.1.6.11.1, 5.1.6.11.2, and 5.1.6.11.2A, the request URI for the initial request of the dialogue should include the specific service URN. (If CEN requirements apply,Ta test IMS-eCall is performed as an ordinary IMS call,ie the UE shall not try to make an emergency registration.Therefore,provisions of the subclause 5.1.3.1apply.The only difference is,the Request-URI of the initial request for a dialog shall include specific service URN,as specified in subclauses 5.1.6.8.1,5.1.6.11.1,5.1.6.11.2 and 5.1.6.11.2A.)

[0058] The service URN mentioned in the first modification above refers to the URN used for testing emergency calls mentioned in the previous embodiments, or a URN specifically designed for testing emergency calls. "If CEN requirements apply" means that new CEN requirements for emergency calls apply, such as CEN requiring that testing emergency calls should not interfere with the services provided by PSAP. Whether CEN requirements apply depends on whether the UE is a CEN member country. For specific determination methods, please refer to the description of the first information below. Defining this URN in the 3GPP specification helps establish test emergency calls between the UE and other nodes besides PSAP (such as the newly defined test node specifically designed for performing test emergency calls), thereby avoiding interference with the emergency services provided by PSAP.

[0059] Second revision

[0060] Section 5.1.6.8.1 (General) of Section 5.1.6.8 (Emergency session setup) of 3GPP TS 24.229 contains the following:

[0061] the Request-URI of the initial request for a dialog or the standalone transaction,or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service URNs:

[0062] -"urn:service:sos","urn:service:sos.ambulance","urn:service:sos.police","urn:service:sos.fire","urn:service:sos.marine","urn:service:sos.mountain","urn:service:sos.ecall.manual","urn:service:sos.ecall.automatic".If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service type corresponding to the type of emergency service.

[0063] The second paragraph above can be modified as follows (the underlined part is new content, i.e., if CEN requirements apply, the UE should add the following URN address: "urn:service:sos.ecall.test" to test NG IMS-eCall):

[0064] -"urn:service:sos","urn:service:sos.ambulance","urn:service:sos.police","urn:service:sos.fire","urn:service:sos.marine","urn:service:sos.mountain","urn:service:sos.ecall.manual", "urn:service:sos.ecall.automatic".If CEN requirements apply, to make an test NG IMS-eCall the UE shall include the following URN: "urn:service:sos.ecall.test". If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service type corresponding to the type of emergency service.

[0065] The URN mentioned in the second modification above is the same URN used for testing emergency calls mentioned in the previous embodiments, or a URN specifically used for testing emergency calls. The second modification provides a specific form of the URN: "urn:service:sos.ecall.test". This URN contains both "sos" and "test", indicating that it is a URN corresponding to testing emergency calls. Of course, the URN can also take other forms, as long as the two parties performing the emergency call test agree on them beforehand. "If CEN requirements apply" refers to the application of new CEN requirements for emergency calls, such as CEN requiring that testing emergency calls should not interfere with the services provided by PSAP. Whether CEN requirements apply depends on whether the UE is a CEN member country. See the description of the first information below for the specific determination method. Defining this URN in the 3GPP specification helps establish test emergency calls between the UE and other nodes besides PSAP (such as the newly defined test node specifically used for performing emergency call tests), thereby avoiding interference with the emergency services provided by PSAP.

[0066] Third revision

[0067] Section 5.1.6.11 (eCall type of emergency service) of 3GPP TS 24.229 includes Section 5.1.6.11.1 (General). Section 5.1.6.11.1 contains the following:

[0068] If the upper layers request establishment of an IMS emergency call of the manually initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.manual" as specified in RFC 8147

[0244] .

[0069] If the upper layers request establishment of an IMS emergency call of the automatically initiated eCall type of emergency service, the service URN shall be "urn:service:sos.ecall.automatic" as specified in RFC 8147

[0244] .

[0070] You can add a new paragraph after the above content, as follows:

[0071] If the CEN requirements apply and the upper layers request the establishment of a test IMS emergency call, the service URN shall be "urn:service:sos.ecall.test", as specified in subclause 5.1.6.8.1 (see also subclause 5.1.3.2).

[0072] The URN mentioned in the third modification above is the same URN used for testing emergency calls mentioned in the previous embodiments, or a URN specifically used for testing emergency calls. The third modification provides a specific form of the URN: "urn:service:sos.ecall.test". This URN contains both "sos" and "test", indicating that it is the URN corresponding to testing emergency calls. Of course, the URN can also take other forms, as long as the two parties performing the emergency call test agree on them beforehand. "If CEN requirements apply" refers to the application of new CEN requirements for emergency calls, such as CEN requiring that testing emergency calls should not interfere with the services provided by PSAP. Whether CEN requirements apply depends on whether the UE is a CEN member country. See the description of the first information below for the specific determination method. Defining this URN in the 3GPP specification helps establish test emergency calls between the UE and other nodes besides PSAP (such as the newly defined test node specifically used for performing emergency call tests), thereby avoiding interference with the emergency services provided by PSAP.

[0073] Fourth revision

[0074] Section 5.1.6.11.2 (Initial INVITE request) of 3GPP TS 24.229 contains the following:

[0075] 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 INVITErequest as specified in the procedures in subclause 5.1.6.8 with the following additions:

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

[0077] The second paragraph above can be modified as follows (the underlined part is new content; that is, if CEN requirements apply, then URN should be set to "urn:service:sos.ecall.test"):

[0078] 1) the UE shall set the Request-URI to "urn:service:sos.ecall.automatic", or "urn:service:sos.ecall.manual", or if the CEN requirements apply, the URN shall be set to "urn:service:sos.ecall.test";

[0079] The URN mentioned in the fourth modification above is the same URN used for testing emergency calls mentioned in the previous embodiments, or a URN specifically used for testing emergency calls. The fourth modification provides a specific form of the URN, namely "urn:service:sos.ecall.test". This URN contains both "sos" and "test", thus indicating that it is the URN corresponding to testing emergency calls. Of course, the URN can also take other forms, as long as the two parties performing the test emergency call agree in advance. "If CEN requirements apply" refers to the application of new requirements for emergency calls proposed by CEN, such as CEN requiring that testing emergency calls should not interfere with the services provided by PSAP. Whether CEN requirements apply may depend on whether the UE is a CEN member country. For the specific determination method, please refer to the description of the first information later. By defining this URN in the 3GPP specification, it is helpful to establish test emergency calls between the UE and other nodes besides PSAP (such as the newly defined test node specifically used for performing test emergency calls), thereby avoiding interference with the emergency services provided by PSAP.

[0080] Fifth revision

[0081] Section 5.1.6.11.2A can be added to 3GPP TS 24.229. The content of this section is as follows:

[0082] 5.1.6.11.2A Transfer of an MSD during a Test NG IMS-eCall

[0083] If the CEN requirements apply, in order to transfer an MSD during a test NG IMS-eCall, the UE shall apply the procedures specified in subclauses 5.1.3.2, 5.1.6.8.1, 5.1.6.11.1, and 5.1.6.11.2. When performing a test NG IMS-eCall, the UE may be configured to populate the MSD with either real data or test data (in the latter case, sensitive MSD data will be protected).

[0084] The phrase "if CEN requirements apply" in the fifth amendment above refers to the application of new CEN requirements for emergency calls, such as CEN requirements to test the carrying of MSDs in emergency calls. Whether CEN requirements apply depends on whether the UE is a CEN member country. For specific determination methods, please refer to the description of the first information below. Furthermore, the fifth amendment specifies the specific form of data in the MSD carried in the emergency call during testing. For example, the data in the MSD can include real data or test data. Test data can be understood as virtual data or fake data; setting the data in the MSD as virtual data helps protect privacy.

[0085] It should be understood that the terminal devices mentioned in the preceding embodiments can be any type of terminal device capable of making eCalls. For example, the terminal device can be an in-vehicle terminal device or an IVS.

[0086] It should also be understood that the first device mentioned in the preceding embodiments can be any type of device responsible for receiving test eCalls. For example, the first device can be a server specifically designed to receive test eCalls.

[0087] Before sending the first request, the terminal device needs to determine whether it is in a CEN member country or whether it is subject to CEN's requirements for testing emergency calls. Therefore, embodiments of this application introduce first information. This first information can be sent to the terminal device by a first device (such as a network device or server). This first information can be used to determine (or indicate) one or more of the following: whether the terminal device is in a CEN-associated country (or whether the terminal device is attached to, resides in, or is registered in a network in a CEN-associated country), and whether the terminal device is subject to CEN's corresponding emergency call requirements for making an emergency call. If the terminal device determines that it is in a CEN-associated country or is subject to CEN's corresponding emergency call requirements for making an emergency call, when the terminal device initiates an emergency call, it should follow the emergency call procedure as required by CEN. The introduction of the aforementioned first information helps the terminal device clarify whether CEN's requirements for emergency calls apply, thereby improving the robustness of the communication process.

[0088] In some implementations, the first information is used to determine (or indicate) whether the terminal device is located in a CEN-associated country. The CEN-associated countries mentioned in the embodiments of this application may include CEN member states. Further, in some implementations, the CEN-associated countries may also include CEN's allied countries and / or partners. There are various ways for the first information to determine (or indicate) whether the terminal device is located in a CEN-associated country. For example, the first information may indicate whether the PLMN currently registered to the terminal device belongs to a PLMN of a CEN-associated country. As another example, the first information may indicate the mobile country code (MCC) of the CEN-associated country; for instance, the first information may include a list of MCCs for CEN-associated countries. The terminal device can compare the MCC in its currently registered PLMN with the MCC indicated by the first information. If the MCC in the currently registered PLMN belongs to the MCC indicated by the first information, then it can be determined that the terminal device is located in a CEN-associated country.

[0089] In some implementations, the first information can be used to indicate whether the emergency call requirement corresponding to CEN is applicable or not. For example, the first information can directly indicate "the emergency call requirement corresponding to CEN is applicable". As a more specific example, the first information can be 1 bit. If the value of this 1 bit is 1, it indicates that the emergency call requirement corresponding to CEN is applicable; if the value of this 1 bit is 0, it indicates that the emergency call requirement corresponding to CEN is not applicable.

[0090] The content of the first piece of information has been introduced above. The following section provides detailed examples illustrating how the first piece of information is carried.

[0091] In some implementations, the first information is carried in a wireless signal or wireless channel provided by the wireless system. For example, if the first device is an access network device, the first information is carried in a broadcast channel or system information transmitted by the access network device. Exemplarily, the access network device may broadcast the identifier of a CEN member country. This identifier may be carried in a bit field; or it may be man-machine readable text; or it may be other information that the mobile system or terminal device can understand or use.

[0092] In some implementations, the first information can be carried in IMS-level signaling. For example, the first information can be carried in SIP signaling (SIP signaling used by the 3GPP IMS system), such as in the SIP session description protocol (SDP). As a more concrete example, the SIP SDP can carry a list of MCCs for CEN-associated countries or a string such as "CEN requirements apply" or something similar. The first information can also be carried in SIP signaling as defined in 3GPP TS 24.229.

[0093] In some implementations, the first information can be carried in NAS signaling. This NAS signaling can be carried in one or more of the following: a registration acceptance message, a downlink NAS transport message, a service acceptance message, or other messages sent from the network to the terminal device as defined in Section 8 of 3GPP TS 24.501. In addition to the aforementioned NAS signaling, the first information can also be transmitted via NAS signaling defined in 3GPP TS 24.301 or 3GPP TS 24.008.

[0094] Furthermore, in some implementations, NAS signaling may include a network feature support information element (NFI), such as a 5GS NFI. This NFI can be used to indicate first information. For example, the NFI may include spare bits, which can be used to carry the first information. Taking the 5GS NFI as an example, the 6th byte of the 5GS NFI includes one or more spare bits, which can be used to carry the first information, either partially or entirely. As a specific example, the first information can be carried in the first bit (which can be any bit among the one or more spare bits, such as the 5th, 6th, 7th, or lower 8 bits of the 6th byte of the 5GS NFI) of the NFI. If the first bit is a first value (e.g., 1), it indicates that the CEN requirements for emergency calls apply; if the first bit is a second value (e.g., 0), it indicates that the CEN requirements for emergency calls do not apply. The following section, using 3GPP TS 24.501, provides a more specific example illustrating the indication method for the first information.

[0095] For example, the following modifications can be made to section 9.11.3.5 of 3GPP TS 24.501 (taking 3GPP TS 24.501v18.7.0 as an example) (the underlined parts are new content):

[0096] 9.11.3.5 5GS network feature support

[0097] The purpose of the 5GS network feature support information element is to indicate whether certain features are supported by the network.

[0098] The 5GS network feature support information element is coded as shown in figure 9.11.3.5.1 and table 9.11.3.5.1.

[0099] The 5GS network feature support is a type 4 information element with a minimum length of 3 octets and a maximum length of 6 octets.

[0100] If:

[0101] -the length of 5GS network feature support contents field is set to one,then the UE shall interpret this as a receipt of an information element with all bits of octet 4,octet 5 and octet 6 coded as zero.

[0102] -the length of 5GS network feature support contents field is set to two,the UE shall interpret this as a receipt of an information element with all bits of octet 5 and octet 6 coded as zero.

[0103] -the length of 5GS network feature support contents field is set to three,the UE shall interpret this as a receipt of an information element with all bits of octet 6 coded as zero.

[0104] Table 9.11.3.5.1:5GS network feature support information element

[0105] In the example above, the 5GS network feature support information element has added "CEN eCall availability," which indicates whether CEN requirements for emergency calls apply. This element can be used to indicate whether CEN requirements for emergency calls are applicable. Table 9.11.3.5.1 explains "CEN eCall availability": if the bit corresponding to "CEN eCall availability" is 0, it means that CEN requirements for emergency calls are not applicable; if the bit corresponding to "CEN eCall availability" is 1, it means that CEN requirements for emergency calls are applicable.

[0106] In some implementations, the initial information can be carried in the MO (the MO defined in the 3GPP specification). This MO can be an IMS MO (see 3GPP TS 24.167) or a NAS MO (see 3GPP TS 24.368).

[0107] In some implementations, the initial information can be provided to the terminal device by the Home PLMN (HPLMN) operator during activation (e.g., when activating the Universal Subscriber Identity Module (USIM). Alternatively, the initial information can be downloaded remotely after using the USIM.

[0108] In some implementations, the first information can be transmitted using a roaming-guided method. For example, see Appendix C of 3GPP TS 23.122 for the process of transmitting the first information using a roaming-guided method.

[0109] In some implementations, the first information can be transmitted based on the subscriber identity module (SIM) toolkit (STK) technology. For a specific implementation of this technology, please refer to 3GPP TS 31.115 (Secure Data Structures for (U)SIM Tool Applications).

[0110] In some implementations, the initial information can be carried within an application-layer message. Alternatively, the initial information can be transmitted via application-to-application signaling. As an example, this initial information can be transmitted using over-the-top technology.

[0111] The method embodiments of this application have been described in detail above with reference to Figures 1 to 4. The apparatus embodiments of this application will be described in detail below with reference to Figures 5 to 7. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the preceding method embodiments.

[0112] Figure 5 is a schematic diagram of a communication device provided in one embodiment of this application. The communication device 500 shown in Figure 5 can be any of the terminal devices mentioned in the preceding embodiments. The communication device 500 includes a communication module 510. The communication module 510 is used to send a first request to a first device, the first request being used to request a test emergency call, and the first request including a URN for testing the emergency call.

[0113] In some implementations, the first request contains a minimal dataset.

[0114] In some implementations, the data in the minimum dataset is test data or dummy data.

[0115] In some implementations, the first request is an initial INVITE request.

[0116] In some implementations, the test emergency call is an IMS-based test emergency call.

[0117] In some implementations, the terminal device does not perform emergency registration during the test emergency call process.

[0118] In some implementations, the URN is used to make the test emergency call between the terminal device and a node other than PSAP.

[0119] In some implementations, the communication module is further configured to: receive first information before the terminal device sends a first request to the first device, the first information being used to determine one or more of the following: whether the terminal device is located in a country associated with CEN; whether the terminal device is subject to the emergency call requirements corresponding to CEN for making an emergency call.

[0120] In some implementations, the first information indicates the Mobile Country Code (MCC) of the country associated with the CEN.

[0121] In some implementations, the first information indicates whether or not the emergency call requirement corresponding to CEN applies.

[0122] In some implementations, the terminal device is an in-vehicle system.

[0123] Figure 6 is a schematic diagram of a communication device provided in another embodiment of this application. The communication device 600 shown in Figure 6 can be the first device mentioned in any of the preceding embodiments. The communication device 600 may include a communication module 610. The communication module 610 is used to receive a first request sent by a terminal device, the first request being used to request to conduct a test emergency call, and the first request including a URN for testing the emergency call.

[0124] In some implementations, the first request contains a minimal dataset.

[0125] In some implementations, the data in the minimum dataset is test data or dummy data.

[0126] In some implementations, the first request is an initial INVITE request.

[0127] In some implementations, the test emergency call is an IMS-based test emergency call.

[0128] In some implementations, the terminal device does not perform emergency registration during the test emergency call process.

[0129] In some implementations, the URN is used to make the test emergency call between the terminal device and a node other than PSAP.

[0130] In some implementations, the terminal device is an in-vehicle system.

[0131] Figure 7 is a schematic structural diagram of a communication device applicable to embodiments of this application. The dashed lines in Figure 7 indicate that the unit or module is optional. This device 700 can be used to implement the methods described in the above method embodiments. Device 700 can be a chip, a terminal device, or a network device.

[0132] The apparatus 700 may include one or more processors 710. The processor 710 may support the apparatus 700 in implementing the methods described in the preceding method embodiments. The processor 710 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0133] The apparatus 700 may also include one or more memories 720. The memories 720 store a program that can be executed by the processor 710, causing the processor 710 to perform the methods described in the preceding method embodiments. The memories 720 may be independent of the processor 710 or integrated within the processor 710.

[0134] The device 700 may also include a transceiver 730. The processor 710 can communicate with other devices or chips via the transceiver 730. For example, the processor 710 can send and receive data with other devices or chips via the transceiver 730.

[0135] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal device or network device provided in this application, and the program causes a computer to execute the methods performed by the communication device in various embodiments of this application.

[0136] This application also provides a computer program product. The computer program product includes a program. This computer program product can be applied to a terminal device or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the communication device in various embodiments of this application.

[0137] This application also provides a computer program. This computer program can be applied to the terminal device or network device provided in this application, and the computer program causes the computer to execute the methods performed by the communication device in various embodiments of this application.

[0138] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0139] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0140] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0141] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0142] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0143] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0144] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0145] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0146] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0147] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0148] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0149] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0150] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

A communication method characterized by comprising: Comprising: The terminal device sends a first request to a first device, the first request being for requesting a test emergency call, the first request comprising a uniform resource name (URN) for the test emergency call. The method of claim 1, wherein The first request comprises a minimum data set. The method according to claim 2, characterized in that The data in the minimum data set is test data or dummy data. The method according to any one of claims 1 to 3, characterized in that The first request is an initial INVITE request. The method according to any one of claims 1 to 4, characterized in that The test emergency call is an Internet Protocol Multimedia Subsystem (IMS) based test emergency call. The method according to any one of claims 1 to 5, characterized in that The terminal device does not perform emergency registration during the test emergency call. The method according to any one of claims 1 to 6, characterized in that The URN is for the test emergency call between the terminal device and a node other than a Public Safety Answering Point (PSAP). The method according to any one of claims 1 to 7, characterized in that Before the terminal device sends the first request to the first device, the method further comprises: The terminal device receives first information, the first information being for determining one or more of: Whether the terminal device is in a European Committee for Standardization (CEN) associated country; Whether the terminal device is adapted to perform an emergency call according to a CEN corresponding emergency call requirement. The method of claim 8, wherein The first information indicates a mobile country code (MCC) of the CEN associated country. The method according to claim 8 or 9, characterized in that The first information indicates that the CEN corresponding emergency call requirement is applicable or not applicable. The method according to any one of claims 1 to 10, characterized in that The terminal device is an in-vehicle system. A communication method characterized by comprising: Comprising: A first device receives a first request sent by a terminal device, the first request being for requesting a test emergency call, the first request comprising a uniform resource name (URN) for the test emergency call. The method of claim 12, wherein The first request comprises a minimum data set. The method of claim 13, wherein The data in the minimum data set is test data or dummy data. The method according to any one of claims 12 to 14, characterized in that The first request is an initial INVITE request. The method according to any one of claims 12 to 15, characterized in that The test emergency call is an Internet Protocol Multimedia Subsystem (IMS) based test emergency call. The method according to any one of claims 12 to 16, characterized in that The terminal device does not perform emergency registration during the test emergency call. The method according to any one of claims 12 to 17, characterized in that The URN is for the test emergency call between the terminal device and a node other than a Public Safety Answering Point (PSAP). The method according to any one of claims 12 to 18, characterized in that The terminal device is an in-vehicle system. A communication device characterized by comprising: The communication device is a terminal device, the communication device comprising: A communication module configured to send a first request to a first device, the first request being for requesting a test emergency call, the first request comprising a uniform resource name (URN) for the test emergency call. The communication device according to claim 20, characterized in that The first request comprises a minimum data set. The communication device according to claim 21, characterized in that The data in the minimum data set is test data or dummy data. The communication device according to any one of claims 20 to 22, characterized in that The first request is an initial INVITE request. The communication device according to any one of claims 20 to 23, characterized in that The test emergency call is an Internet Protocol Multimedia Subsystem (IMS) based test emergency call. The communication device according to any one of claims 20 to 24, characterized in that The terminal device does not perform emergency registration during the test emergency call. The communication device according to any one of claims 20 to 25, characterized in that The URN is for the test emergency call between the terminal device and a node other than a Public Safety Answering Point (PSAP). The communication device according to any one of claims 20 to 26, characterized in that The terminal device is an in-vehicle system. A communication device characterized by The communication device is a first device, the communication device comprising: A communication module configured to receive a first request sent by a terminal device, the first request being for requesting a test emergency call, the first request comprising a uniform resource name (URN) for the test emergency call. The communication device according to claim 28, characterized in that The first request comprises a minimum data set. The communication device according to claim 29, characterized in that The data in the minimum data set is test data or dummy data. The communication device according to any one of claims 28 to 30, characterized in that The first request is an initial INVITE request. The communication device according to any one of claims 28 to 31, characterized in that The test emergency call is an Internet Protocol Multimedia Subsystem, IMS, based test emergency call. The communication device according to any one of claims 28 to 32, characterized in that During the test emergency call, the terminal device does not perform emergency registration. The communication device according to any one of claims 28 to 33, characterized in that The URN is used for the test emergency call between the terminal device and a node other than a Public Safety Answering Point, PSAP. The communication device according to any one of claims 28 to 34, characterized in that The communication module is further configured to: Before the terminal device sends a first request to a first device, receive first information, the first information being used to determine one or more of: whether the terminal device is in a European Committee for Standardization, CEN, associated country; whether the terminal device is adapted to perform an emergency call according to a CEN corresponding emergency call requirement. The communication device according to claim 35, characterized in that The first information indicates a Mobile Country Code, MCC, of the CEN associated country. The communication device according to claim 35 or 36, characterized in that The first information indicates that the CEN corresponding emergency call requirement is applicable or not applicable. The communication device according to any one of claims 28 to 37, characterized in that The terminal device is an in-vehicle system. A communication device characterized by comprising: A communication device comprising a transceiver, a memory and a processor, the memory being configured to store a program, the processor being configured to invoke the program in the memory and control the transceiver to receive or send a signal, so that the communication device performs the method according to any one of claims 1 to 19. An apparatus, characterized in that A device comprising a processor configured to invoke a program from a memory, so that the device performs the method according to any one of claims 1 to 19. A chip characterized by comprising: A chip comprising a processor configured to invoke a program from a memory, so that a device installed with the chip performs the method according to any one of claims 1 to 19. A computer-readable storage medium, characterized by, A computer program product having stored thereon a program, the program causing a computer to perform the method according to any one of claims 1 to 19. A computer program product, characterized in that A computer program product having stored thereon a program, the program causing a computer to perform the method according to any one of claims 1 to 19. A computer program, characterized in that, A computer program product having stored thereon a program, the program causing a computer to perform the method according to any one of claims 1 to 19.

Images