Method and apparatus for processing emergency call, and network-side device

By acquiring the relay terminal identifier in the first network element and sending an emergency call request carrying the identifier to the second network element, the emergency call failure problem caused by the relay terminal being unable to provide location information is solved, and the emergency call is successfully processed.

WO2024255673A1PCT designated stage expired Publication Date: 2024-12-19VIVO MOBILE COMM CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/097702
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-06-12
Filing Date
2024-06-06
Publication Date
2024-12-19

AI Technical Summary

Technical Problem

When the relay terminal provides relay services to the remote terminal, when the remote terminal initiates an IMS emergency call, the emergency call session control function refuses the emergency call because it cannot obtain the location information of the remote terminal, resulting in the emergency call failure.

Method used

The first network element receives the emergency call request from the remote terminal, obtains the identification of the relay terminal, and sends an emergency call request carrying the identification of the relay terminal to the second network element, thereby obtaining the location information of the relay terminal to process the emergency call .

Benefits of technology

Ensures successful processing of emergency calls and avoids emergency call failures due to inability to obtain remote terminal location information.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024097702_19122024_PF_FP_ABST
    Figure CN2024097702_19122024_PF_FP_ABST
Patent Text Reader

Abstract

The present application belongs to the technical field of wireless communications. Disclosed are a method and apparatus for processing an emergency call, and a network-side device. The method comprises: a first network element receiving a first emergency call request which is sent by a remote user equipment; the first network element acquiring an identifier of a relay user equipment corresponding to the remote user equipment; and the first network element sending a second emergency call request to a second network element, wherein the second emergency call request carries the identifier of the relay user equipment.
Need to check novelty before this filing date? Find Prior Art

Description

Emergency call processing method, device and network side equipment

[0001] Cross-references

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on June 12, 2023, with application number 202310696965.8 and application name “Method, device and network-side equipment for processing emergency calls”. The entire contents of the application are incorporated by reference into this application. Technical Field

[0003] The present application belongs to the field of wireless communication technology, and specifically relates to a method, apparatus, and network-side equipment for processing emergency calls. Background Art

[0004] With the development of network informatization, in order to expand network coverage, the current mainstream solution is to use relay terminals (relay UE) to enable terminals at the edge of the cell or outside the network coverage to access the network through the relay terminal (relay UE) and obtain network services. In the Layer 3 relay communication scenario (Layer-3 UE-to-Network relay), the relay terminal (relay UE) can provide relay services for the remote terminal (remote UE). For example, the relay terminal (relay UE) receives service data from the remote terminal (remote UE) and forwards it to the network, or the relay terminal (relay UE) receives data sent by the network to the remote terminal (remote UE) and forwards it to the remote terminal (remote UE).

[0005] When a terminal initiates an Internet Protocol (IP) Multimedia Subsystem (IMS) emergency call, the emergency call session control function (CSCF) receives the emergency call request sent by the UE and sends a request to the location retrieval function (LRF) to verify the location information carried by the UE (for example, the cell ID), or to obtain the location information of the UE (for example, the UE does not carry location information).

[0006] During the process of the relay terminal (relay UE) providing relay service for the remote terminal (Remote UE), when the remote terminal (Remote UE) initiates a (multimedia subsystem) emergency call through the relay terminal (relay UE), since the remote terminal (Remote UE) is connected to the 4G or 5G network through the relay terminal, the remote terminal may not be registered in the 4G or 5G network. Therefore, the location retrieval function (LRF) may not be able to obtain the location information of the remote terminal, resulting in the emergency call session control function (Emergency CSCF, E-CSCF) rejecting the IMS emergency call initiated by the remote terminal because it cannot obtain the location of the remote terminal, resulting in the failure of the emergency call.

[0007] Summary of the Invention

[0008] The embodiments of the present application provide an emergency call processing method, apparatus, and network-side device, which can solve the problem that an E-CSCF rejects an IMS emergency call initiated by a remote terminal because it cannot obtain the location of the remote terminal, thereby causing the emergency call to fail.

[0009] In the first aspect, a method for processing an emergency call is provided, the method comprising: a first network element receiving a first emergency call request sent by a remote terminal; the first network element obtaining an identifier of a relay terminal corresponding to the remote terminal; the first network element sending a second emergency call request to a second network element, wherein the second emergency call request carries the identifier of the relay terminal.

[0010] In the second aspect, a method for processing an emergency call is provided, which includes: a second network element receiving a second emergency call request sent by a first network element, wherein the second emergency call request carries an identifier of a relay terminal; and the second network element sending the identifier of the relay terminal to a fourth network element.

[0011] In the third aspect, an emergency call processing device is provided, which includes: a first receiving module for receiving a first emergency call request sent by a remote terminal; an acquisition module for acquiring an identifier of a relay terminal corresponding to the remote terminal; and a first sending module for sending a second emergency call request to a second network element, wherein the second emergency call request carries the identifier of the relay terminal.

[0012] In the fourth aspect, an emergency call processing device is provided, which includes: a second receiving module for receiving a second emergency call request sent by a first network element, wherein the second emergency call request carries an identifier of a relay terminal; and a second sending module for sending the identifier of the relay terminal to a fourth network element.

[0013] In the fifth aspect, a network side device is provided, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented, or the steps of the method described in the second aspect are implemented.

[0014] In a sixth aspect, a readable storage medium is provided, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented, or the steps of the method described in the second aspect are implemented.

[0015] In a seventh aspect, a wireless communication system is provided, comprising: a network side device, wherein the network side device can be used to execute the steps of the method described in the first aspect, or implement the steps of the method described in the second aspect.

[0016] In an eighth aspect, a chip is provided, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the first aspect, or to implement the method described in the second aspect.

[0017] In a ninth aspect, a computer program / program product is provided, wherein the computer program / program product is stored in a storage medium, and the program / program product is executed by at least one processor to implement the steps of the method according to the first aspect, or to implement the steps of the method according to the second aspect.

[0018] In an embodiment of the present application, after receiving the first emergency call request sent by the remote terminal, the first network element obtains the identifier of the relay terminal corresponding to the remote terminal, and then sends a second emergency call request carrying the identifier of the relay terminal to the second network element, so that the network side can obtain the corresponding location information based on the identifier of the relay terminal for emergency call processing, thereby solving the problem that the E-CSCF rejects the IMS emergency call initiated by the remote terminal because it cannot obtain the location of the remote terminal, resulting in the failure of the emergency call. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG1 shows a block diagram of a wireless communication system to which embodiments of the present application may be applied;

[0020] FIG2 is a schematic flow chart showing a method for processing an emergency call provided in the related art;

[0021] FIG3 shows a schematic flow chart of a method for processing an emergency call according to an embodiment of the present application;

[0022] FIG4 shows another flow chart of a method for processing an emergency call according to an embodiment of the present application;

[0023] FIG5 shows another flow chart of a method for processing an emergency call according to an embodiment of the present application;

[0024] FIG6 shows a schematic structural diagram of an emergency call processing device provided in an embodiment of the present application;

[0025] FIG7 shows another schematic structural diagram of an emergency call processing device provided in an embodiment of the present application;

[0026] FIG8 shows a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0027] FIG9 shows a schematic diagram of the hardware structure of a network-side device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of this application to clearly describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field are within the scope of protection of this application.

[0029] The terms "first", "second", etc. in this application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable where appropriate, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same type, and do not limit the number of objects, for example, the first object can be one or more. In addition, "or" in this application represents at least one of the connected objects. For example, "A or B" covers three options, namely, Option 1: including A but not including B; Option 2: including B but not including A; Option 3: including both A and B. The character " / " generally indicates that the objects associated before and after are in an "or" relationship.

[0030] The term "indication" in this application can be either a direct indication (or explicit indication) or an indirect indication (or implicit indication). A direct indication can be understood as the sender explicitly informing the receiver of specific information, the operation to be performed, or the requested result, etc. in the instruction sent; an indirect indication can be understood as the receiver determining the corresponding information based on the instruction sent by the sender, or making a judgment and determining the operation to be performed or the requested result, etc. based on the judgment result.

[0031] It is worth noting that the technology described in the embodiments of the present application is not limited to the Long Term Evolution (LTE) / LTE-Advanced (LTE-A) system, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA) or other systems. The terms "system" and "network" in the embodiments of the present application are often used interchangeably, and the technology described can be used for the systems and radio technologies mentioned above, as well as for other systems and radio technologies. The following description describes a New Radio (NR) system for illustrative purposes, and NR terminology is used in most of the following description, but these technologies can also be applied to systems other than NR systems, such as 6th generation (6G) systems. th Generation, 6G) communication system.

[0032] Figure 1 shows a block diagram of a wireless communication system applicable to embodiments of the present application. As shown in Figure 1 , the wireless communication system includes a relay terminal 11, a network-side device 12, and a remote terminal 13. In this embodiment of the present application, remote terminal 13 communicates with relay terminal 11 via the PC5 (secondary link) interface, while relay terminal 11 communicates with network-side device 12 via the Uu interface.

[0033] Among them, the relay terminal 11 can also be called a relay terminal device or a relay user terminal (UE), and the remote terminal 13 can also be called a remote terminal device or a remote UE. The relay terminal 11 and the remote terminal 13 can be terminal-side devices such as a mobile phone, a tablet personal computer, a laptop computer or a notebook computer, a personal digital assistant (PDA), a handheld computer, a netbook, an ultra-mobile personal computer (UMPC), a mobile Internet device (MID), a wearable device (Wearable Device) or a vehicle-mounted device (VUE), a pedestrian terminal (PUE), etc. Wearable devices include: bracelets, headphones, glasses, etc. In addition to the above-mentioned terminal devices, it can also be a chip in the terminal, such as a modem chip or a system-on-chip (SoC). It should be noted that the specific types of the relay terminal 11 and the remote terminal 13 are not limited in the embodiments of the present application. The network side device 12 can be a base station or a core network, where the base station can be called a node B, an evolved node B, an access point, a base transceiver station (Base Transceiver Station, BTS), a radio base station, a radio transceiver, a basic service set (Basic Service Set, BSS), an extended service set (Extended Service Set, ESS), a B node, an evolved B node (eNB), a home B node, a home evolved B node, a WLAN access point, a WiFi node, a transmitting and receiving point (Transmitting Receiving Point, TRP) or other appropriate terms in the field. As long as the same technical effect is achieved, the base station is not limited to a specific technical vocabulary. It should be noted that in the embodiment of the present application, only the base station in the NR system is taken as an example, but the specific type of the base station is not limited.

[0034] The core network equipment may include but is not limited to at least one of the following: core network node, core network function, mobility management entity (MME), access mobility management function (AMF), session management function (SMF), user plane function (UPF), policy control function (PCF), policy and charging rules function unit (PCRF), edge application service discovery function (EASDF), unified data management (UDM), unified data repository (UDR), home user server (HSS), centralized network configuration (CNC), network storage function (NRF), network exposure function (NEF), local NEF (L-NEF), binding support function (BSF), application function ( It should be noted that in the embodiments of the present application, only the core network device in the NR system is introduced as an example, and the specific type of the core network device is not limited.

[0035] In a Layer-3 UE-to-Network relay scenario, a relay terminal (relay UE) can provide relay services for a remote terminal (Remote UE). For example, the relay UE receives service data from the remote UE and routes it to the network, or the relay UE receives data sent by the network to the remote UE and routes it to the remote UE. When the relay UE provides relay services for the remote UE, the relay UE assigns an IP address to the remote UE, and the remote UE generates an IP packet using the IP address assigned by the relay UE. If the relay UE itself only has an IPv4 address, the relay UE will assign a private IP address to the remote UE. For example, the assigned private IP address is IP-A. After the relay UE receives the IP packet containing IP-A from the remote UE, it converts IP-A to IP-B through NAT (Network Address Translation) and sends it to the network. IP-B can be the IP address assigned by the network to the relay UE.

[0036] FIG2 is a flow chart showing a method for processing an emergency call provided in the related art. As shown in FIG2 , the method may include the following steps:

[0037] S201: The UE is in a registered state in the 5G network, and the UE establishes an emergency protocol data unit (PDU) session. It is worth noting that the 5G network is used as an example here, but it is also applicable to 4G or 6G networks.

[0038] S202: The UE initiates an IMS emergency call through an Invite message. The Invite message includes the UE's IMS identification information and the UE's location information, such as the UE's cell identity (ID).

[0039] S203: The Proxy CSCF (P-CSCF) obtains the UE identity according to the IMS identity, and sends the Invite message and the UE identity to the Emergency CSCF (E-CSCF).

[0040] S204: The Emergency CSCF (E-CSCF) sends a request to the LRF, carrying the UE identity. This message is used to verify the cell ID carried by the UE, or to request the location of the UE.

[0041] S205: The LRF obtains the Access and Mobility Management Function (AMF) that provides services for the UE based on the UE identifier, and requests the UE location information from the AMF.

[0042] S206: The AMF requests the location information of the UE from the Location Management Function (LMF).

[0043] S207: LMF performs the Positioning function to obtain the UE's location information.

[0044] S208: LMF sends the UE location information to AMF.

[0045] S209: The Access and Mobility Management Function (AMF) sends the UE location information to the LRF.

[0046] S210: The LRF sends the UE's location information or verification result to the E-CSCF.

[0047] S211: The E-CSCF obtains the PSAP (Public Safety Access Point) serving the UE according to the location of the UE, and completes the subsequent emergency call process.

[0048] However, in the relay communication scenario, when the Remote UE initiates an IMS emergency call through the relay UE, the E-CSCF will send a request to the LRF (Location Retrieval Function) after receiving the emergency call request sent by the UE to verify the location information (e.g., cell ID) carried by the UE, or to obtain the UE's location information (e.g., the UE does not carry location information). Since the remote UE is connected to the 4G or 5G network through the relay UE, the remote UE itself may not be registered in the 4G or 5G network. Therefore, the LRF cannot obtain the remote UE's location information, causing the E-CSCF to reject the IMS emergency call initiated by the remote UE because it cannot obtain the remote UE's location.

[0049] To solve the above technical problems, the present application provides an emergency call processing method, apparatus and network-side equipment.

[0050] The following describes in detail an emergency call processing method, apparatus, and network-side device provided by an embodiment of the present application through some embodiments and their application scenarios in conjunction with the accompanying drawings.

[0051] Figure 3 shows a flow chart of a method for handling an emergency call in an embodiment of the present application. The method 300 may be executed by a first network element. In other words, the method may be executed by software or hardware installed on the first network element.

[0052] In the embodiment of the present application, the first network element may be a functional entity in the core network for proxy call session control, for example, the first network element may be a proxy call session control function (Proxy CSCF, P-CSCF) in the core network. As shown in FIG3 , the method may include the following steps.

[0053] S310: A first network element receives a first emergency call request sent by a remote terminal.

[0054] For example, the remote terminal may send the first emergency call request through an Invite message, and the first network element receives the first emergency call request.

[0055] In an embodiment of the present application, the remote terminal may send the above-mentioned first emergency call request through a relay terminal, and the relay terminal forwards the first emergency call request to the network side.

[0056] For example, the remote terminal can establish a PC5 connection with the relay terminal, which is in a registered state in the network. Then the remote terminal sends a first emergency call request to the relay terminal through the PC5 interface. After the relay terminal receives the first emergency call request through the PC5 interface, it forwards the first emergency call request to the network side.

[0057] Optionally, the first emergency call request may carry the following information:

[0058] (1) IMS identification information of the remote UE; for example, the IP address allocated by the relay UE to the remote UE.

[0059] (2) The location information of the relay UE, such as the cell ID of the UE, where the remote UE can obtain the location information of the relay UE from the relay UE;

[0060] (3) access type "3GPP-NR-ProSe-L3UNR"; where access type "3GPP-NR-ProSe-L3UNR" indicates that the value of access type is "3rd Generation Partnership Project - New Radio - Short Range Service - Layer 3 User Equipment to Network Relay (3GPP-NR-ProSe-L3UNR)", which can also be expressed as access type = "3GPP-NR-ProSe-L3UNR";

[0061] (4) access type "3GPP-E-UTRAN-ProSe-UNR"; wherein, access type "3GPP-E-UTRAN-ProSe-UNR" indicates that the value of access type is "3rd Generation Partnership Project Evolved Universal Terrestrial Radio Access Network - Short Range Service - User Equipment to Network Relay (3GPP-E-UTRAN-ProSe-UNR)", which can also be expressed as access type = "3GPP-E-UTRAN-ProSe-UNR".

[0062] It should be noted that the access type carried in the first emergency call request may be included in the access network information (P-Access-Network-Info) header of the IMS message.

[0063] It should be noted that in the 5G communication system, when the remote UE sends the first emergency call request through the relay UE, the value of the access type carried is 3GPP-NR-ProSe-L3UNR; in the 4G communication system, when the remote UE sends the first emergency call request through the relay UE, the value of the access type carried is 3GPP-E-UTRAN-ProSe-UNR; similarly, in the 6G communication system, when the remote UE sends an IMS message through the relay UE, the value of the access type carried can be 3GPP-6G-ProSe-L3UNR, where 6G can be replaced according to the actual name of the 6G communication system. For example, when 6G is named FR, the value of the access type can be 3GPP-FR-ProSe-L3UNR.

[0064] S312: The first network element obtains an identifier of the relay terminal corresponding to the remote terminal.

[0065] In the embodiment of the present application, the first network element may obtain the identifier of the relay terminal according to the value of the access type carried in the first emergency call request.

[0066] For example, the first network element determines, based on the access type "3GPP-NR-ProSe-L3UNR" carried in the first emergency call request, that the first emergency call request is sent by the remote UE through the relay UE, and obtains the ID of the relay UE.

[0067] In one implementation, the first network element may obtain the identifier of the relay terminal locally.

[0068] For example, before S310, the first network element receives an IMS registration request from the remote terminal, which carries the IP address assigned by the relay terminal to the remote terminal. The first network element requests the third network element (e.g., PCF) for the UE identifier corresponding to the IP address based on the IP address. The third network element determines that the IP address is the address assigned to the relay terminal, and therefore returns the identifier of the relay terminal to the first network element, which stores the identifier of the relay terminal. Upon receiving the first emergency call request sent by the remote terminal, the relay terminal identifier is obtained from the locally stored data.

[0069] It should be noted that when the relay terminal establishes a PDU session, the 5G network can allocate a group of IP addresses to the relay terminal, such as 10 IPs. When the remote terminal is connected to the relay terminal, the relay terminal allocates one of the IP addresses to the remote terminal (for example, one of the 10 IPs). The remote terminal carries the IP address in the first emergency call request. The first network element can determine the relay terminal corresponding to the remote terminal based on the IP address.

[0070] In another implementation, the first network element may also obtain the identifier of the relay terminal from the third network element.

[0071] For example, the first network element requests the UE identifier corresponding to the IP address carried in the first emergency call request from the third network element (for example, PCF). The third network element determines that the IP address is the address assigned to the relay terminal, and therefore returns the identifier of the relay terminal to the first network element.

[0072] For example, the first network element may send one of the following message requests to the third network element:

[0073] Npcf_PolicyAuthorization_Create;

[0074] Npcf_PolicyAuthorization_Update.

[0075] The message request may include the IP address of the relay UE.

[0076] In an embodiment of the present application, the identifier of the relay terminal may include at least one of the following:

[0077] The Mobile Station international ISDN number (MSISDN) of the relay terminal;

[0078] The Generic Public Subscription Identifier (GPSI) of the relay terminal;

[0079] The International Mobile Subscriber Identity (IMSI) of the relay terminal;

[0080] The Subscription Permanent Identifier (SUPI) of the relay terminal.

[0081] S314, the first network element sends a second emergency call request to the second network element, where the second emergency call request carries the identifier of the relay terminal.

[0082] It should be noted that the second emergency call request is obtained based on the first emergency call request and carries the identifier of the relay terminal on the basis of the first emergency call request.

[0083] In an embodiment of the present application, the first network element makes the second network element able to execute the subsequent procedures of the emergency call according to the identifier of the relay terminal by carrying the identifier of the relay terminal in the second emergency call request message, so as to ensure the normal execution of the emergency call.

[0084] In an embodiment of the present application, the second network element may be a functional entity in the core network for processing emergency call control. For example, the second network element may be an Emergency Call Session Control Function (E-CSCF).

[0085] In one implementation, the identifier of the relay terminal may be carried in the message header of the second emergency call request.

[0086] Optionally, the message header may include at least one of the following:

[0087] (1) Contact message header; for example, contact: <relay UE identifier>; indication.

[0088] (2) From header; for example, From: <relay UE identifier>; indication.

[0089] Among them, the indication in (1) or (2) is used to indicate that the content within <> is the identifier of the relay UE, for example, relay UE ID.

[0090] (3) Access network information (P-Access-Network-Info) header, for example, P-Access-Network-Info: Access type “3GPP-NR-ProSe-L3UNR”, relay UE identifier. Among them, access type is a parameter of P-Access-Network-Info. In this implementation, a new information for carrying the relay UE ID is added to the access type parameter; or, a new parameter for carrying the relay UE ID is added to P-Access-Network-Info.

[0091] In one implementation, the first network element can determine to send the second emergency call request carrying the identifier of the relay terminal to the second network element according to the value of the access type in the first emergency call request. For example, the second network element can obtain the ID of the relay UE according to access type “3GPP-NR-ProSe-L3UNR” and determine to send the identifier of the relay UE to the second network element.

[0092] It should be noted that the first network element can determine to send the second emergency call request carrying the identifier of the relay terminal to the second network element according to the value of the access type in the first emergency call request, and it can also be understood that: the first network element can determine to send the second emergency call request carrying the identifier of the relay terminal to the second network element according to the access type in the first emergency call request.

[0093] Through the above emergency call processing method provided by the embodiments of the present application, when the first network element receives an emergency call request sent by a remote terminal, it can obtain the identifier of the relay terminal corresponding to the remote terminal, and then send the emergency call request carrying the identifier of the relay terminal to the second network element, so that the second network element can process the subsequent process of the emergency call according to the identifier of the relay terminal and ensure the success of the emergency call.

[0094] FIG. 4 shows another schematic flowchart of the method for processing an emergency call in the embodiments of the present application. This method 400 can be executed by the second network element. In other words, the method can be executed by software or hardware installed on the second network element.

[0095] In an embodiment of the present application, the second network element may be a functional entity in the core network for emergency call session control. For example, the second network element may be the Proxy Call Session Control Function (P-CSCF) in the core network. As shown in FIG. 4, the method may include the following steps.

[0096] S410. The second network element receives a second emergency call request sent by the first network element, where the second emergency call request carries an identifier of a relay terminal.

[0097] In an embodiment of the present application, the second emergency call request may be sent by the first network element after receiving a first emergency call request sent by a remote terminal. The first network element may send the second emergency call request in the manner described in the above method 300. For specific details, refer to the description in the above method 300 and will not be elaborated here.

[0098] In one implementation, the identifier of the relay terminal may be carried in the message header of the second emergency call request.

[0099] Optionally, the message header may include at least one of the following:

[0100] (1) Contact message header; for example, contact: <relay UE identifier>; indication.

[0101] (2) From message header; for example, From: <relay UE identifier>; indication.

[0102] Among them, the indication in (1) or (2) is used to indicate that the content within <> is the identifier of the relay UE, for example, relay UE ID.

[0103] (3) Access network information (P-Access-Network-Info) message header, for example, P-Access-Network-Info: Access type “3GPP-NR-ProSe-L3UNR”, relay UE identifier. Here, access type is a parameter of P-Access-Network-Info. In this implementation, a new information for carrying the relay UE ID is added to the access type parameter; or a new parameter for carrying the relay UE ID is added to P-Access-Network-Info.

[0104] S412. The second network element sends the identifier of the relay terminal to the fourth network element.

[0105] In an embodiment of the present application, the fourth network element may be a functional entity for location acquisition, for example, the fourth network element may be a location retrieval function (LRF) or a gateway mobile location center (GMLC).

[0106] In one implementation, the second emergency call request may carry an access type, where the access type may take any one of the following values:

[0107] 3rd Generation Mobile Partnership Project - New Radio - Short Range Services - Layer 3 User Equipment to Network Relay (3GPP-NR-ProSe-L3UNR);

[0108] 3rd Generation Partnership Project Evolved Universal Terrestrial Radio Access Network - Short Range Services - User Equipment to Network Relay (3GPP-E-UTRAN-ProSe-UNR).

[0109] In one implementation, before the second network element sends the relay terminal identifier to the fourth network element, the second network element may determine and obtain the relay terminal identifier carried in the second emergency call request according to the value of the access type.

[0110] Optionally, the second network element determines, based on the value of the access type, that the second emergency call request is triggered by a remote terminal accessed through the relay terminal; the second network element obtains the identifier of the relay terminal carried in the second emergency call request. For example, the second network element obtains the ID of the relay UE based on the access type "3GPP-NR-ProSe-L3UNR" and sends the identifier of the relay UE to the fourth network element. The second network element may obtain the ID of the relay UE from the message header of at least one of the above in the second emergency call request.

[0111] In an embodiment of the present application, the second network element sends the identifier of the relay UE to the fourth network element, so that the location information corresponding to the identifier of the relay UE can be obtained through the fourth network element. Then, based on the location information, the public safety access point (PSAP) providing service for the remote UE is obtained, and the subsequent emergency call process is completed.

[0112] For example, after S412, the fourth network element can obtain the AMF that provides services for the relay UE based on the identifier of the relay terminal, and request the location information of the Relay UE from the AMF. Then the AMF requests the location information of the Relay UE from the LMF (Location Management Function), and returns the obtained location information of the Relay UE to the fourth network element. The fourth network element returns the location information or verification result to the second network element. The second network element obtains the public safety answering point (Public Safety Access Point, PSAP) that provides services for the UE based on the location information, and completes the subsequent emergency call process.

[0113] In the technical solution provided in the embodiment of the present application, after receiving the second emergency call request carrying the identifier of the relay terminal, the second network element sends the identifier of the relay terminal to the fourth network element to obtain the location information corresponding to the identifier, thereby providing emergency call service for the remote terminal.

[0114] The following describes the technical solution provided in the embodiment of the present application by taking the first network element as a P-CSCF and the second network element as an E-CSCF as an example.

[0115] FIG5 shows another flow chart of the method for processing an emergency call according to an embodiment of the present application. As shown in FIG5 , the method mainly includes the following steps:

[0116] S501. The remote UE establishes a PC5 connection with the relay UE.

[0117] In this embodiment of the present application, the Relay UE is in a registered state within the 5G network, and the Relay UE has established an emergency Protocol Data Unit (PDU) session.

[0118] S502. The Remote UE initiates an IMS emergency call via an Invite message.

[0119] The Invite message can include the following information:

[0120] (1) IMS identification information of the remote UE;

[0121] (2) The location information of the relay UE, such as the cell ID of the UE; the remote UE obtains the location information of the relay UE from the relay UE.

[0122] (3)access type “3GPP-NR-ProSe-L3UNR”

[0123] Among them, access type "3GPP-NR-ProSe-L3UNR" indicates that the value of access type is "3GPP-NR-ProSe-L3UNR", which can also be expressed as access type = "3GPP-NR-ProSe-L3UNR".

[0124] S503. The P-CSCF obtains the ID of the relay UE.

[0125] The relay UE identifier may include at least one of the following:

[0126] MSISDN (Mobile Station international ISDN number);

[0127] GPSI (Generic Public Subscription Identifier);

[0128] IMSI (International Mobile Subscriber Identity);

[0129] SUPI (SUbscription Permanent Identifier).

[0130] Among them, the P-CSCF determines that the invite request is sent by the remote UE through the relay UE based on the access type "3GPP-NR-ProSe-L3UNR", and then obtains the ID of the relay UE.

[0131] The ID of the relay UE may be obtained locally by the P-CSCF (for example, the ID of the relay UE obtained when the remote UE performs IMS registration); or

[0132] The P-CSCF may also request the Relay UE ID from the PCF. Specifically, the P-CSCF may request the PCF through the Npcf_PolicyAuthorization_Create or Npcf_PolicyAuthorization_Update message. The request includes the IP address of the Relay UE, thereby obtaining the Relay UE ID from the PCF.

[0133] S504. The P-CSCF receives the ID of the relay UE sent by the PCF.

[0134] S505. The P-CSCF sends an invite message to the E-CSCF, carrying the ID of the relay UE in the invite message.

[0135] Among them, the carrying methods of the ID of the relay UE include at least one of the following:

[0136] (1) Carried through the Contact header: For example, contact: <relay UE identifier>; indication.

[0137] (2) Carried through the From header: For example, From: <relay UE identifier>; indication

[0138] Among them, the above indication is used to indicate that the content within <> is the identifier of the relay UE, for example, relay UE ID.

[0139] (3) Carried through the P-Access-Network-Info header: For example, P-Access-Network-Info: Access type “3GPP-NR-ProSe-L3UNR”, relay UE identifier.

[0140] Among them, access type is a parameter of P-Access-Network-Info. In the embodiments of this application, a new information for carrying the relay UE ID is added to the access type parameter; or, a new parameter for carrying the relay UE ID is added to P-Access-Network-Info.

[0141] S506. The E-CSCF obtains the ID of the relay UE according to the access type “3GPP-NR-ProSe-L3UNR” and sends the identifier of the relay UE to the LRF.

[0142] Among them, the E-CSCF can obtain the ID of the relay UE from the message header described in S505.

[0143] S507. Perform the subsequent processes according to S205-211 in Figure 2.

[0144] Through the above-mentioned technical solution of the embodiment of the present application, after the P-CSCF receives the emergency call request sent by the remote UE, it obtains the identifier of the relay UE corresponding to the remote UE, carries the identifier of the relay UE in the emergency call request and sends it to the E-CSCF. The E-CSCF sends the identifier of the relay UE to the LRF, so that the location verification or acquisition process can be executed correctly, ensuring that the emergency call is executed correctly.

[0145] The emergency call processing method provided in the embodiment of the present application can be executed by an emergency call processing device. In the embodiment of the present application, the emergency call processing device provided in the embodiment of the present application is described by taking the emergency call processing method executed by the emergency call processing device as an example.

[0146] FIG6 shows a structural diagram of an emergency call processing device provided in an embodiment of the present application. As shown in FIG6 , the device 600 mainly includes: a first receiving module 601 , an acquiring module 602 and a first sending module 603 .

[0147] In an embodiment of the present application, the first receiving module 601 is used to receive a first emergency call request sent by a remote terminal; the acquisition module 602 is used to obtain the identifier of the relay terminal corresponding to the remote terminal; the first sending module 603 is used to send a second emergency call request to the second network element, wherein the second emergency call request carries the identifier of the relay terminal.

[0148] In one implementation, the first emergency call request carries an access type, and the value of the access type includes any one of the following: 3GPP-NR-ProSe-L3UNR; 3GPP-E-UTRAN-ProSe-UNR.

[0149] In one implementation, the obtaining module 602 obtains the identifier of the relay terminal, including: obtaining the identifier of the relay terminal according to the value of the access type.

[0150] In one implementation, the obtaining module 602 obtains the identifier of the relay terminal corresponding to the remote terminal according to the access type, including:

[0151] Determining, according to a value of the access type, that the first emergency call request is sent by the remote terminal through the relay terminal;

[0152] Obtain an identifier of the relay terminal.

[0153] In one implementation, the obtaining module 602 obtains the identifier of the relay terminal, including one of the following:

[0154] Obtaining the identifier of the relay terminal locally;

[0155] Acquire the identifier of the relay terminal from a third network element.

[0156] In one implementation, the second emergency call request carries the identifier of the relay terminal, including:

[0157] The identifier of the relay terminal is carried in a message header of the second emergency call request.

[0158] In one implementation, the message header includes at least one of the following:

[0159] Contact message header;

[0160] From message header;

[0161] P-Access-Network-Info message header.

[0162] In one implementation, the first sending module 603 sends the second emergency call request to the second network element, including: sending the second emergency call request carrying the identifier of the relay terminal to the second network element according to the value of the access type.

[0163] In one implementation, the identifier of the relay terminal includes at least one of the following:

[0164] The mobile station International Integrated Services Digital Network (ISDN) number of the relay terminal;

[0165] The universal public user identity of the relay terminal;

[0166] The international mobile subscriber identity code of the relay terminal;

[0167] The permanent identifier of the user of the relay terminal.

[0168] Through the above-mentioned device provided in the embodiment of the present application, when an emergency call request sent by a remote terminal is received, the identifier of the relay terminal corresponding to the remote terminal can be obtained, and the identifier of the relay terminal can be carried in the emergency call request, so that the emergency call of the remote terminal can be processed according to the location of the relay terminal, thereby ensuring the success of the emergency call of the remote terminal.

[0169] FIG7 shows another structural diagram of an emergency call processing device provided in an embodiment of the present application. As shown in FIG7 , the device 700 mainly includes: a second receiving module 701 and a second sending module 702 .

[0170] In an embodiment of the present application, the second receiving module 701 is used to receive a second emergency call request sent by the first network element, wherein the second emergency call request carries an identifier of the relay terminal; the second sending module 702 is used to send the identifier of the relay terminal to the fourth network element.

[0171] In one implementation, the second emergency call request carries an access type, and the value of the access type includes any one of the following:

[0172] 3GPP-NR-ProSe-L3UNR;

[0173] 3GPP-E-UTRAN-ProSe-UNR.

[0174] In one implementation, the method further includes: an acquisition module configured to acquire the identifier of the relay terminal carried in the second emergency call request according to the value of the access type.

[0175] In one implementation, obtaining the identifier of the relay terminal carried in the second emergency call request according to the value of the access type includes:

[0176] determining, according to a value of the access type, that the second emergency call request is triggered by a remote terminal accessed through the relay terminal;

[0177] Obtain the identifier of the relay terminal carried in the second emergency call request.

[0178] In one implementation, the identifier of the relay terminal is carried in a message header of the second emergency call request.

[0179] In one implementation, the message header includes one of the following:

[0180] Contact message header;

[0181] From the From message header;

[0182] Access network information P-Access-Network-Info message header.

[0183] Through the above-mentioned device provided in the embodiment of the present application, when an emergency call carrying the identifier of the relay terminal is received, the identifier of the relay terminal is sent to the fourth network element, so that the location information of the relay terminal can be obtained from the fourth network element, and the emergency call of the remote terminal can be realized according to the location information of the relay terminal.

[0184] The emergency call processing device in the embodiments of the present application can be an electronic device, such as an electronic device with an operating system, or a component of an electronic device, such as an integrated circuit or chip. The electronic device can be a server, a network attached storage (NAS), etc., and the embodiments of the present application do not specifically limit this.

[0185] The emergency call processing device provided in the embodiment of the present application can implement the various processes implemented in the method embodiments of Figures 3 to 5 and achieve the same technical effects. To avoid repetition, they will not be described here.

[0186] As shown in Figure 8, an embodiment of the present application also provides a communication device 800, including a processor 801 and a memory 802, and the memory 802 stores programs or instructions that can be run on the processor 801. For example, when the communication device 800 is a network side device, the program or instruction is executed by the processor 801 to implement the various steps of the above-mentioned emergency call processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0187] Specifically, an embodiment of the present application further provides a network-side device. As shown in FIG9 , the network-side device 900 includes a processor 901, a network interface 902, and a memory 903. The network interface 902 is, for example, a common public radio interface (CPRI).

[0188] Specifically, the network side device 900 of the embodiment of the present application also includes: instructions or programs stored in the memory 903 and can be run on the processor 901. The processor 901 calls the instructions or programs in the memory 903 to execute the methods executed by each module shown in Figure 6 or Figure 7, and achieves the same technical effect. To avoid repetition, it will not be repeated here.

[0189] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned emergency call processing method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0190] The processor is the processor in the terminal described in the above embodiment. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. In some examples, the readable storage medium may be a non-transitory readable storage medium.

[0191] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned emergency call processing method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0192] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0193] An embodiment of the present application further provides a computer program / program product, which is stored in a storage medium. The computer program / program product is executed by at least one processor to implement the various processes of the above-mentioned emergency call processing method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0194] An embodiment of the present application also provides an emergency call processing system, including a first network element and a second network element. The first network element can be used to execute the steps of the emergency call processing method described in Figure 3 above, and the second network element can be used to execute the steps of the emergency call processing method described in Figure 4 above.

[0195] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0196] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of a computer software product plus a necessary general-purpose hardware platform, or of course, by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes a number of instructions for enabling a terminal or network-side device to execute the methods described in each embodiment of the present application.

[0197] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms of implementation methods without departing from the purpose of this application and the scope of protection of the claims. These implementation methods are all within the protection of this application.

Claims

1. A method for processing an emergency call, comprising: The first network element receives a first emergency call request sent by a remote terminal; The first network element obtains an identifier of a relay terminal corresponding to the remote terminal; The first network element sends a second emergency call request to the second network element, wherein the second emergency call request carries an identifier of the relay terminal.

2. The method according to claim 1, wherein: The first emergency call request carries an access type, and the value of the access type includes any one of the following: 3rd Generation Mobile Communications Partnership Project - New Radio - Short Range Services - Layer 3 User Equipment to Network Relay 3GPP-NR-ProSe-L3UNR; 3rd Generation Partnership Project Evolved Universal Terrestrial Radio Access Network - Short Range Services - User Equipment to Network Relay 3GPP-E-UTRAN-ProSe-UNR.

3. The method according to claim 1 or 2, wherein: The first emergency call request carries an access type, and the first network element obtains the identifier of the relay terminal, including: The first network element obtains the identifier of the relay terminal according to the value of the access type.

4. The method according to claim 3, wherein: The first network element acquiring, according to the access type, an identifier of a relay terminal corresponding to the remote terminal, including: The first network element determines, according to a value of the access type, that the first emergency call request is sent by the remote terminal through the relay terminal; The first network element obtains the identifier of the relay terminal.

5. The method according to any one of claims 1 to 4, wherein: The first network element obtains the identifier of the relay terminal, including one of the following: The first network element obtains the identifier of the relay terminal locally; The first network element obtains the identifier of the relay terminal from the third network element.

6. The method according to claim 5, wherein: The third network element includes: a policy control function PCF.

7. The method according to claim 1, wherein: The second emergency call request carries the identifier of the relay terminal, including: The identifier of the relay terminal is carried in a message header of the second emergency call request.

8. The method according to claim 7, wherein: The message header includes at least one of the following: Contact message header; From the From message header; Access network information P-Access-Network-Info message header.

9. The method according to claim 2, wherein: The first network element sending a second emergency call request to the second network element includes: The first network element sends a packet carrying the identifier of the relay terminal to the second network element according to the value of the access type. The second emergency call request.

10. The method according to any one of claims 1 to 8, wherein: The identifier of the relay terminal includes at least one of the following: The mobile station International Integrated Services Digital Network (ISDN) number of the relay terminal; The universal public user identity of the relay terminal; The international mobile subscriber identity code of the relay terminal; A permanent identifier of a user of the relay terminal.

11. The method according to any one of claims 1 to 10, wherein: The first network element includes a proxy call session control function P-CSCF, and the second network element includes an emergency session control function E-CSCF.

12. A method for processing an emergency call, comprising: The second network element receives a second emergency call request sent by the first network element, wherein the second emergency call request carries an identifier of the relay terminal; The second network element sends the identifier of the relay terminal to the fourth network element.

13. The method according to claim 12, wherein: The second emergency call request carries an access type, and a value of the access type includes any one of the following: 3rd Generation Mobile Communications Partnership Project - New Radio - Short Range Services - Layer 3 User Equipment to Network Relay 3GPP-NR-ProSe-L3UNR; 3rd Generation Partnership Project Evolved Universal Terrestrial Radio Access Network - Short Range Services - User Equipment to Network Relay 3GPP-E-UTRAN-ProSe-UNR.

14. The method according to claim 13, wherein: The method further comprises: The second network element obtains the identifier of the relay terminal carried in the second emergency call request according to the value of the access type.

15. The method according to claim 14, wherein: The second network element obtains, according to the value of the access type, the identifier of the relay terminal carried in the second emergency call request, including: The second network element determines, according to the value of the access type, that the second emergency call request is triggered by a remote terminal accessed through the relay terminal; The second network element obtains the identifier of the relay terminal carried in the second emergency call request.

16. The method according to any one of claims 12 to 15, wherein: The identifier of the relay terminal is carried in a message header of the second emergency call request.

17. The method according to claim 16, wherein: The message header includes one of the following: Contact message header; From the From message header; Access network information P-Access-Network-Info message header.

18. The method according to any one of claims 12 to 17, wherein: The first network element includes a proxy call session control function P-CSCF, the second network element includes an emergency session control function E-CSCF, and the fourth network element includes a location reference function LRF.

19. An emergency call processing device, comprising: A first receiving module, used to receive a first emergency call request sent by a remote terminal; An acquisition module, used to acquire an identifier of a relay terminal corresponding to the remote terminal; The first sending module is configured to send a second emergency call request to a second network element, wherein the second emergency call request carries an identifier of the relay terminal.

20. An emergency call processing device, comprising: A second receiving module is used to receive a second emergency call request sent by the first network element, wherein the second emergency call request carries an identifier of the relay terminal; The second sending module is used to send the identifier of the relay terminal to the fourth network element.

21. A network side device, comprising a processor and a memory, wherein the memory stores a program or instruction that can be run on the processor, and when the program or instruction is executed by the processor, the steps of the emergency call processing method as described in any one of claims 1 to 18 are implemented.

22. A readable storage medium storing a program or an instruction, wherein the program or the instruction, when executed by a processor, implements the steps of the method for processing an emergency call according to any one of claims 1 to 18.

Citation Information

Patent Citations

  • State indication method, device and system

    CN113596804A

  • Emergency communication routing for non-cellular coverage

    CN114286325A

  • Calling method, device and system

    CN114520803A

  • State indication method, device, and system

    US20230012926A1