CN117998346A

CN117998346A - IMS service request method, terminal and core network equipment

Info

Publication number: CN117998346A
Application number: CN202211634708.3A
Authority: CN
Inventors: 程思涵; 王文
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2022-11-04
Filing date: 2022-12-19
Publication date: 2024-05-07

Abstract

The application discloses a request method, a terminal and core network equipment of IMS service, belonging to the wireless communication field, the request method of IMS service of the embodiment of the application comprises the following steps: the remote terminal acquires public network address information from the relay terminal; and the remote terminal sends an IMS service request to network side equipment, wherein the IMS service request carries the public network address information.

Description

IMS service request method, terminal and core network equipment

Technical Field

The application belongs to the technical field of wireless communication, and particularly relates to a request method, a terminal and core network equipment of an Internet protocol (Internet Protocol, IP) multimedia subsystem (IP Multimedia Subsystem, IMS) service.

Background

In order to expand network coverage, terminals at the cell edge or outside the network coverage may access the network through relay terminals to obtain network services, which may be referred to as relay communications.

In a Layer-3UE-to-Network relay scenario, a relay terminal (relay UE) may provide a relay service for a Remote terminal (Remote UE). For example, the relay UE receives the service data from the Remote UE and forwards the service data to the network, or the relay UE receives the data sent by the network to the Remote UE and forwards the data to the Remote UE. In the process that the relay UE provides relay service for the Remote UE, the relay UE allocates an IP address for the Remote UE, and the Remote UE generates an IP packet by using the IP address allocated by the relay UE. If the relay UE has only the IPv4 address, the relay UE allocates a private network IP address to the remote UE, and after the relay UE receives an IP packet containing the private network address of the remote UE, the relay UE converts the private network address into a public network address through network address conversion (Network Address Translation, NAT) and sends the public network address to the network.

Currently, layer three relay communication only studies how remote UE transmits data traffic through relay UE, and no solution is provided for specific IMS traffic, such as IMS emergency call traffic.

Disclosure of Invention

The embodiment of the application provides a request method of IMS service, a terminal and core network equipment, which can solve the problem of how a far-end terminal realizes IMS service.

In a first aspect, a method for requesting an IMS service is provided, including: the remote terminal acquires public network address information from the relay terminal; and the remote terminal sends an IMS service request to network side equipment, wherein the IMS service request carries the public network address information.

In a second aspect, an IMS call method is provided, including: the remote terminal acquires the identification information of the relay terminal for positioning; and the remote terminal sends an IMS call request, wherein the IMS call request carries the identification information of the relay terminal.

In a third aspect, an IMS call method is provided, including: the remote terminal sends an IMS call request carrying first information through the relay terminal, wherein the first information is used for indicating the remote terminal to access the network through the relay terminal.

In a fourth aspect, a method for processing an IMS call is provided, including: the method comprises the steps that core network equipment receives a request message, wherein the request message is used for establishing an IMS call for a first terminal or distributing a special bearer corresponding to the IMS call; and under the condition that the core network equipment determines that the first terminal accesses the network through the relay terminal and establishes a first special bearer corresponding to the IMS call for the relay terminal, the core network equipment establishes a second special bearer corresponding to the IMS call for the first terminal or uses the first special bearer to transmit the data of the IMS call of the first terminal.

In a fifth aspect, there is provided a request device for an IMS service, including: the first acquisition module is used for acquiring public network address information from the relay terminal; the first sending module is used for sending an IMS service request to the network side equipment, wherein the IMS service request carries the public network address information.

In a sixth aspect, an IMS call device is provided, including: the second acquisition module is used for acquiring the identification information of the relay terminal for positioning; and the second sending module is used for sending an IMS call request, wherein the IMS call request carries the identification information of the relay terminal.

In a seventh aspect, an IMS call device is provided, including: and the third sending module is used for sending an IMS call request carrying first information through the relay terminal, wherein the first information is used for indicating the remote terminal to access the network through the relay terminal.

An eighth aspect provides an IMS call processing device, including: the receiving module is used for receiving a request message, wherein the request message is used for establishing an IMS call for the first terminal or distributing a special bearer corresponding to the IMS call; and the processing module is used for establishing a second special bearer corresponding to the IMS call for the first terminal or transmitting the data of the IMS call of the first terminal by using the first special bearer under the condition that the first terminal is determined to access the network through the relay terminal and the first special bearer corresponding to the IMS call is established for the relay terminal.

In a ninth aspect, there is provided a terminal comprising a processor and a memory storing a program or instructions executable on the processor, which when executed by the processor, implement the steps of the method according to any one of the first to third aspects.

In a tenth aspect, a terminal is provided, comprising a processor and a communication interface, wherein the processor is configured to implement the steps of the method according to any of the first to third aspects, and the communication interface is configured to communicate with an external device.

In an eleventh aspect, there is provided a core network device comprising a processor and a memory storing a program or instructions executable on the processor, which when executed by the processor, implement the steps of the method as described in the fourth aspect.

In a twelfth aspect, a core network device is provided, which includes a processor and a communication interface, where the processor is configured to implement the steps of the method according to the fourth aspect, and the communication interface is configured to communicate with an external device.

In a thirteenth aspect, an IMS call system is provided, comprising: a terminal operable to perform the steps of the method according to any of the first to third aspects, and a core network device operable to perform the steps of the method according to the third aspect.

In a fourteenth aspect, there is provided a readable storage medium having stored thereon a program or instructions which when executed by a processor, implement the steps of the method according to any one of the first to third aspects, or implement the steps of the method according to the fourth aspect.

In a fifteenth aspect, there is provided a chip comprising a processor and a communication interface, the communication interface and the processor being coupled, the processor being for running a program or instructions, implementing the steps of the method according to any one of the first to third aspects, or implementing the steps of the method according to the fourth aspect.

In a sixteenth aspect, there is provided a computer program/program product stored in a storage medium, the computer program/program product being executable by at least one processor to perform the steps of the method according to any one of the first to third aspects or to perform the steps of the method according to the fourth aspect.

In the embodiment of the application, the remote terminal can acquire the public network address information from the relay terminal, and then carry the public network address information in the IMS service request sent to the network side equipment, for example, IMS registration and/or IMS call is initiated, so that the network side equipment can complete IMS registration and/or IMS call according to the public network address information, thereby realizing IMS service of the remote terminal.

Drawings

Fig. 1 shows a block diagram of a wireless communication system to which embodiments of the present application are applicable;

Fig. 2 shows a flow diagram of a method for requesting an IMS service in an embodiment of the application;

fig. 3 shows a schematic flow diagram of IMS registration in an embodiment of the application;

fig. 4 shows a schematic flow diagram of a processing procedure of an IMS message in an embodiment of the application;

fig. 5 shows a schematic flow chart of an IMS call method in an embodiment of the application;

fig. 6 shows a flow chart of an IMS call method in an embodiment of the application;

Fig. 7 is a schematic flow chart of another IMS call method in an embodiment of the application;

fig. 8 is a flow chart of yet another IMS call method according to an embodiment of the application;

Fig. 9 is a schematic flow chart of a method for processing an IMS call in an embodiment of the application;

Fig. 10 is a flow chart of yet another IMS call method according to an embodiment of the application;

Fig. 11 is a flow chart of yet another IMS call method according to an embodiment of the application;

fig. 12 is a flow chart of yet another IMS call method according to an embodiment of the application;

Fig. 13 is a schematic structural diagram of an IMS service requesting device according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of an IMS call device according to an embodiment of the present application;

fig. 15 is a schematic diagram illustrating another structure of an IMS call device in an embodiment of the application;

fig. 16 is a schematic structural diagram of an IMS call processing device according to an embodiment of the present application;

Fig. 17 is a schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 18 shows a schematic hardware structure of a terminal according to an embodiment of the present application;

Fig. 19 shows a schematic hardware structure of a core network device according to an embodiment of the present application.

Detailed Description

The technical solutions of the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which are derived by a person skilled in the art based on the embodiments of the application, fall within the scope of protection of the application.

The terms first, second and the like in the description and in the claims, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the application are capable of operation in sequences other than those illustrated or otherwise described herein, and that the "first" and "second" distinguishing between objects generally are not limited in number to the extent that the first object may, for example, be one or more. Furthermore, in the description and claims, "and/or" means at least one of the connected objects, and the character "/" generally means a relationship in which the associated object is an "or" before and after. The term "indicated" in the description and claims of the present application may be either an explicit indication or an implicit indication. The explicit indication may be understood as that the sender explicitly informs the receiver of the operation or request result that needs to be performed in the sent indication; the implicit indication is understood as that the receiving side judges according to the indication sent by the sending side, and determines the operation or the request result to be executed according to the judging result.

It should be noted that the techniques described in the embodiments of the present application are not limited to long term evolution (Long Term Evolution, LTE)/LTE evolution (LTE-Advanced, LTE-a) systems, but may also be used in other wireless communication systems, such as code division multiple access (Code Division Multiple Access, CDMA), time division multiple access (Time Division Multiple Access, TDMA), frequency division multiple access (Frequency Division Multiple Access, FDMA), orthogonal frequency division multiple access (Orthogonal Frequency Division Multiple Access, OFDMA), single carrier frequency division multiple access (Single-carrier Frequency Division Multiple Access, SC-FDMA), and other systems. The terms "system" and "network" in embodiments of the application are often used interchangeably, and the techniques described may be used for both the above-mentioned systems and radio technologies, as well as other systems and radio technologies. The following description describes a New Radio (NR) system for exemplary purposes and NR terminology is used in much of the following description, but these techniques may also be applied to applications other than NR system applications, such as 6 th Generation (6G) communication systems.

Fig. 1 shows a block diagram of a wireless communication system to which an embodiment of the present application is applicable. The wireless communication system includes a relay terminal 11, a network device 12, and a remote terminal 13. In the embodiment of the present application, the remote terminal 13 and the relay terminal 11 communicate through a PC5 (sidelink) interface, and the relay terminal 11 and the network side device 12 communicate through a Uu interface.

The relay terminal 11 may also be called a relay (relay) terminal device or a relay User terminal (UE), the remote terminal 13 may also be called a remote terminal device or a remote (remote) UE, the relay terminal 11 and the remote terminal 13 may be a Mobile phone, a tablet Computer (Tablet Personal Computer), a Laptop Computer (Laptop Computer) or a terminal-side device called a notebook Computer, a Personal digital assistant (Personal DIGITAL ASSISTANT, PDA), a palm Computer, a netbook, an ultra Mobile Personal Computer (ultra-Mobile Personal Computer, UMPC), a Mobile internet device (Mobile INTERNET DEVICE, MID), a wearable device (Wearable Device) or a vehicle-mounted device (VUE), a pedestrian terminal (PUE), and the wearable device includes: a bracelet, earphone, glasses, etc. In addition to the above terminal device, a Chip in the terminal, such as a Modem (Modem) Chip, a System on Chip (SoC), may be used. Note that, the specific types of the relay terminal 11 and the remote terminal 13 are not limited in the embodiment of the present application.

The network side device 12 may be a base station or a core network, where the base station may 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 node B, an evolved node B (eNB), a home node B, a home evolved node B, a WLAN access Point, a WiFi node, a transmission and reception Point (TRANSMITTING RECEIVING Point, TRP), or some other suitable terminology in the field, and the base station is not limited to a specific technical vocabulary so long as the same technical effect is achieved, and 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. The core network device may include, but is not limited to, at least one of: core network nodes, core network functions, mobility management entities (Mobility MANAGEMENT ENTITY, MME), access Mobility management functions (ACCESS AND Mobility Management Function, AMF), session management functions (Session Management Function, SMF), user plane functions (User Plane Function, UPF), policy control functions (Policy Control Function, PCF), policy and Charging Rules Function (PCRF), edge application service discovery functions (Edge Application Server Discovery Function, EASDF), unified data management (Unified DATA MANAGEMENT, UDM), unified data warehousing (Unified Data Repository, UDR), home subscriber server (Home Subscriber Server, HSS), centralized network configuration (Centralized network configuration, CNC), network storage functions (Network Repository Function, NRF), network opening functions (Network Exposure Function, NEF), local NEF (Local NEF, or L-NEF), binding support functions (Binding Support Function, BSF), application functions (Application Function, AF), and the like. It should be noted that, in the embodiment of the present application, only the core network device in the NR system is described as an example, and the specific type of the core network device is not limited.

The following describes in detail, with reference to the attached drawings, a request scheme of an IMS service provided by the embodiment of the application through some embodiments and application scenarios thereof.

In the related art, when a terminal initiates an IMS registration procedure, the terminal initiates a registration request through a session initiation protocol (Session initialization Protocol, SIP) registration message, where the registration request includes identification information of the terminal itself, for example, information such as a SIP uniform resource identifier (SIP Uniform Resource Identifier, SIP URI) and an IP address, and the SIP URI includes domain name information of the terminal itself. The registration request is routed to a query call session control function (Interrogating Call Session Control Function, I-CSCF) to query a home subscriber server (Home Subscriber Server, HSS) that serves the terminal, the HSS provides the I-CSCF with subscription information for the terminal, the I-CSCF selects a serving call session control function (SERVING CALL Session Control Function, S-CSCF) and sends the registration request to the S-CSCF, the S-CSCF obtains the subscription information for the terminal from the HSS that serves the terminal, determines the service subscribed by the terminal according to the subscription information for the terminal, for example, whether to allow an emergency call or not, and the S-CSCF replies with a200 OK message to complete the registration process. It follows that during IMS registration, the terminal needs to provide information such as its SIP URI and IP address. The IP address herein refers to an IP address that can be routed over a public network, such as the internet, abbreviated as a public network address or a public network IP address. The main function of the IP address information is to route SIP signaling sent to a terminal to the terminal, e.g. when the S-CSCF receives a SIP message sent to the terminal device, the S-CSCF converts the SIP URI information of the terminal contained in the SIP message into the IP address of the terminal and routes the SIP message to the terminal through the IP address. It follows that the IP address needs to be a public network address. However, if the terminal has only a private network address, for example, the remote terminal obtains only the private network address from the relay terminal, the network side may reject the registration request message of the terminal, so that the terminal cannot perform the end IMS registration. Aiming at the problem, the embodiment of the application provides a request method of IMS service.

It should be noted that, the private network address may also be referred to as a private network IP address, specifically, an IP address that can be used only in the local area network and cannot be used on the public network, for example, IP addresses with IP address fields of 10.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255 are private network addresses.

Fig. 2 shows a flow diagram of a method for requesting an IMS service in an embodiment of the application, which method 200 may be performed by a remote terminal. In other words, the method may be performed by software or hardware installed on the remote terminal. As shown in fig. 2, the method may include the following steps.

S210, the remote terminal acquires public network address information from the relay terminal.

In order to implement IMS services, the remote terminal may obtain public network address information from the relay terminal.

In one possible implementation, the remote terminal may obtain the public network address information by sending request information to the relay terminal. Thus, in this possible implementation, S210 may comprise the steps of:

and step 1, the remote terminal can send a first request message to the relay terminal under the condition that the address information obtained from the relay terminal is determined to be a private network address, wherein the first request message is used for requesting to obtain public network address information corresponding to the private network address.

For example, the relay UE may allocate a private network IP address to the remote UE, where the private network IP address is valid in the local area network, and the public network cannot provide a route for the private network IP address, and before initiating the IMS service, the remote UE may send the first request message to the relay terminal to request public network address information corresponding to the private network IP address. Optionally, the remote terminal may carry first indication information in the first request message, where the first indication information is used to indicate that the public network address information requested by the first request message is used to establish an IMS emergency call service or establish an IMS call service, so that the relay terminal may learn the purpose that the remote terminal requests the public network address information, thereby providing the remote terminal with public network address information corresponding to the private network IP address.

Optionally, the first request message may further carry identification information of the remote terminal, for example, information of a SIP URI of the remote terminal, so that the relay terminal may obtain the remote terminal that sends the first request message. For example, in the case that a plurality of remote terminals access the network through the same relay terminal, in order to subsequently receive an IMS message sent to one of the plurality of remote terminals at the network side, the correct remote terminal can be accurately routed. For example, when the relay terminal receives the SIP INVITE message sent by the network side, if the SIP INVITE message is not encrypted, the relay terminal may determine to which remote terminal it should send according to the SIP URI in the destination address of SIP INVITE. The remote terminal may carry the SIP URI of the remote terminal in a first request message.

For convenience of description, the present application takes a SIP URI as an example, and a Tel (Telephone) URI may be used instead of the SIP URI in practical use.

And step 2, the remote terminal receives the public network address information sent by the relay terminal.

For example, after receiving the first request message, the relay terminal may convert the private network IP address of the remote terminal into a public network address through network address conversion (Network Address Translation, NAT), thereby obtaining the public network address information. Namely, the relay terminal sends the public network address after NAT to the far-end terminal.

Optionally, the Relay UE may record the correspondence between the IP address and the port number and the remote UE, where the correspondence may be used for forwarding data of the remote UE subsequently.

Alternatively, the public network address information may include an IP address and a port number.

Alternatively, the public network address information may include only an IP address.

In another possible implementation manner, the remote terminal may send a relay service Code (RELAY SERVICE Code, RSC) corresponding to the emergency service to the relay terminal, and the remote terminal receives public network address information of an emergency (urgent) protocol data unit (Protocol Data Unit, PDU) session corresponding to the RSC sent by the relay terminal. Thus, in this possible implementation, S210 may comprise the steps of:

In step 1, the remote terminal may send a direct link establishment request (DIRECT LINK Establishment Request) message to the relay terminal in case of determining that the emergency service is initiated through the relay terminal, where the DIRECT LINK Establishment Request message is used to request to establish a direct link between the remote terminal and the relay terminal, and the DIRECT LINK Establishment Request message includes an RSC corresponding to the emergency service.

After receiving the DIRECT LINK Establishment Request message, the relay terminal knows that an emergency PDU session needs to be established for the remote terminal according to the RCS. And the relay terminal acquires parameters of the PDU session corresponding to the RCS according to the locally stored Policy information, and initiates an emergency PDU session establishment request to the network side equipment. After receiving the PDU session establishment acceptance message, the establishment procedure of the emergency PDU session is completed. In the process of establishing the emergency PDU session, the relay terminal can obtain the public network address corresponding to the emergency PDU.

It should be noted that, the RSC corresponding to the emergency service may also be understood as the RSC of the emergency service, or the emergency RSC (emergency RSC).

After receiving DIRECT LINK Establishment Request the relay terminal can send the public network address corresponding to the emergency PDU session to the remote terminal through a direct link establishment acceptance (DIRECT LINK Establishment Accept) message after completing the establishment of the emergency PDU session corresponding to the RCS; or alternatively

After receiving DIRECT LINK Establishment Request the relay terminal can send DIRECT LINK Establishment Accept message to the remote terminal after finishing the establishment of the emergency PDU session corresponding to the RCS; and after receiving the DIRECT LINK Establishment Accept message, the remote terminal sends a request message for requesting to acquire the IP address to the relay terminal, and the relay terminal sends public network address information of the emergency PDU session to the remote terminal.

It should be noted that the public network address information may include only an IP address, or the public network address information may include an IP address and a port number.

Optionally, the Relay UE records a correspondence between the emergency PDU session and the remote UE, where the correspondence may be used for forwarding data of the remote UE subsequently.

Optionally, the request message for requesting to obtain the IP address is a dynamic host configuration protocol version 4 (Dynamic Host Configuration Protocol Version, dhcpv 4) request message, or a dynamic host configuration protocol version 6 (Dynamic Host Configuration Protocol Version, dhcpv 6) request message, or an internet protocol version 6 (Internet Protocol Version, ipv 6) address configuration message.

S212, the remote terminal sends an IMS service request to the network side equipment, wherein the IMS service request carries the public network address information.

In the embodiment of the application, after the remote terminal obtains the public network address information from the relay terminal, the public network address information is used for initiating the IMS service request, so that the network side equipment can correctly process the IMS service request of the remote terminal, thereby realizing the IMS service of the remote terminal.

In one possible implementation, the IMS service request may be an IMS registration (REGISTER) request. In this possible implementation, S212 may include: and sending an IMS registration request to the network side equipment, wherein the IMS registration request carries the IP address in the public network address information. By adopting the possible implementation manner, the remote terminal can realize IMS registration, and then IMS service can be realized.

In the present application, for convenience of description, an IMS registration request is taken as an example to describe the method of the present application, which can also be used for IMS emergency registration, and the following steps are the same and will not be repeated.

In one possible implementation, the IMS service request may also be an IMS call request, and in this possible implementation, S212 may further include: and the remote terminal sends an IMS call request to network side equipment, wherein the IMS call request carries the IP address or the IMS call request carries the IP address and the port number. For example, the remote terminal may initiate SIP INVITE a request, including in the SIP INVITE the NAT-back IP address and port number that the relay UE sent to the remote UE. The session description protocol (Session Description Protocol, SDP) of SIP INVITE messages may contain address information of the media transport, including IP address and port number information. When the subsequent PSAP sends the voice service data to the UE, the subsequent PSAP may send the data to the IP address and the port number included in the SDP, and the relay UE sends the received data to the remote UE according to the information allocated in step 2.

In one possible implementation, in a case where IMS registration is required to be completed before IMS is initiated, the remote terminal may first send an IMS registration request, and after registration is completed, send an IMS call request to the network side device.

In one possible implementation, after the remote terminal sends an IMS service request, such as an IMS registration request, to the network-side device, the network-side device may send an IMS message to the remote terminal, which may be forwarded to the remote terminal via the relay terminal. In one possible implementation manner, if the remote terminal performs IMS registration before, in an IMS registration process, an authentication and authentication process is performed between the remote terminal and the network, in which process, the remote terminal may obtain a security key for an IMS message, so the IMS message may be an encrypted IMS message, after receiving the IMS message, the relay terminal cannot determine to which remote terminal the relay terminal should send the IMS message, and the relay terminal forwards the IMS message to all the remote terminals connected thereto, only the correct remote terminal uses the security key to decrypt, so that the IMS message sent to the remote terminal by the network device may be obtained, and content information of the IMS message is obtained.

In another possible implementation manner, before the network side device sends the IMS message, the remote terminal may not perform IMS registration, and then the IMS message may be plaintext information, and after receiving the IMS message, the relay terminal forwards the IMS message to the corresponding remote terminal according to the destination SIP URI of the IMS message.

In the present application, for convenience of description, IMS emergency call is taken as an example, and the method of the present application may also be used for common IMS call, which is the same as the following, and will not be described again.

According to the technical scheme provided by the embodiment of the application, the remote terminal can acquire the public network address information from the relay terminal before initiating the IMS service request, and then initiates the IMS service request by the public network address information, so that the network side can correctly process the IMS service request of the remote terminal according to the public network address information, and realize the IMS service initiated by the remote terminal.

The following describes a method for requesting IMS service provided in the embodiment of the present application, taking an IMS service request as an IMS registration request and an IMS emergency call request as an example, respectively.

Fig. 3 is a schematic diagram of an IMS registration process in an embodiment of the present application, as shown in fig. 3, where the IMS registration process mainly includes steps S301, S302, and S303:

S301, the Remote UE sends a request message to the relay UE, wherein the request message is used for requesting the Remote UE to provide the address after NAT.

Optionally, the request message includes indication information for establishing an emergency call service.

Optionally, the request message includes information of the SIP URI of the remote UE.

S302, the Relay UE provides the IP address after NAT to the remote UE, and optionally, the Relay UE also comprises port number information.

The Relay UE may record the correspondence between the IP address and the port number and the remote UE, and use the correspondence to forward the data of the remote UE.

In another possible implementation, the IMS registration procedure mainly includes steps S301', S302', and S303:

S301', the Remote UE sends DIRECT LINK Establishment Request a message to the relay UE, and the request message contains RSC corresponding to the emergency service.

After receiving the DIRECT LINK Establishment Request message, the Relay UE knows from the RCS that the remote terminal requests to establish the emergency PDU session. And the Relay UE acquires parameters of the PDU session corresponding to the RCS according to the locally stored Policy information, and initiates an emergency PDU session establishment request to the network side equipment. After receiving the PDU session establishment acceptance message, the establishment procedure of the emergency PDU session is completed. In the process of establishing the emergency PDU session, the relay terminal can obtain the IP address corresponding to the emergency PDU session.

S302', the Relay UE sends the IP address corresponding to the emergency PDU session to the Remote UE through DIRECT LINK Establishment Accept message.

The Relay UE may record a correspondence between the emergency PDU session and the remote UE, which may be used for forwarding data of the remote UE subsequently.

In another possible implementation, the IMS registration procedure mainly includes steps S301", S302" and S303:

Before S301", the Remote UE sends DIRECT LINK Establishment Request a message to the relay UE, where the request message includes the RSC corresponding to the emergency service. After receiving the DIRECT LINK Establishment Request message, the Relay UE knows from the RCS that the remote terminal requests to establish the emergency PDU session. And the Relay UE acquires parameters of the PDU session corresponding to the RCS according to the locally stored Policy information, and initiates an emergency PDU session establishment request to the network side equipment. After receiving the PDU session establishment acceptance message, the establishment procedure of the emergency PDU session is completed. In the process of establishing the emergency PDU session, the relay terminal can obtain the IP address corresponding to the emergency PDU session. And the Relay UE sends DIRECT LINK Establishment Accept information to the Remote UE to complete the establishment of a direct link between the Remote UE and the Relay UE.

S301", remote UE sends a request for requesting to obtain an IP address to Relay UE.

S302', the Relay UE transmits the IP address corresponding to the emergency PDU session to the Remote UE.

In the embodiment of the present application, S303 includes S303a, or includes S303b, or includes S303a and S303b, or includes S303c.

S303a, the Remote UE initiates an IMS registration request, and the registration request comprises the IP address after NAT, which is sent to the Remote UE by the relay UE.

In an embodiment of the application, as shown in fig. 3, the method may further include:

S303b, the Remote UE initiates a SIP INVITE (INVITE) request (the SIP INVITE request may be an emergency call request), and the SIP INVITE request includes the NAT-back IP address and port number sent by the relay UE to the Remote UE.

In another possible implementation:

S303c: the Remote UE initiates SIP INVITE a request (the SIP INVITE request may be an emergency call request), and the SIP INVITE request includes the IP address sent by the relay UE to the Remote UE.

Optionally, SIP INVITE requests for initiating a call, and when the emergency call indication information is included in the SIP INVITE message, SIP INVITE requests for initiating an emergency call.

Alternatively, for the scenario in which the SIP INVITE request is performed without IMS registration, the remote UE may perform S303b after S302. For scenarios where IMS registration is required to perform SIP INVITE requests, the remote UE may perform S303b after S303 a.

The SDP of SIP INVITE message contains address information of media transmission, which contains IP address and port number information. When the subsequent PSAP sends voice service data to the UE, the subsequent PSAP sends data to the IP address and the port number included in the SDP, and the relay UE sends the received data to the remote UE according to the information allocated in S302.

Fig. 4 is a schematic flow chart of processing a SIP INVITE request sent by a network side device, as shown in fig. 4, where the flow mainly includes the following steps:

S401, the Relay UE receives the message sent by the IMS network, and if the IMS message is encrypted, the Relay UE cannot analyze the message.

S402a and S402b, the Relay UE determines, according to the destination address of the message, for example, the destination SIP URI, a remote UE corresponding to the destination address, and sends the IMS message to the remote UE. If the relay UE has only one IPv4 address, the addresses of the relay UE after NAT for the plurality of remote UEs are the same IPv4 address, and the port numbers are different, that is, different remote UEs are distinguished by the port numbers.

S403, the target remote UE may parse the SIP message and reply.

Through the technical scheme provided by the embodiment of the application, remote UE can realize IMS service.

In the related art, the terminal may carry EMERGENCY URI information in SIP INVITE messages when initiating an emergency call request. Optionally, the SIP INVITE message includes location information of the UE, and a network side device in the IMS network, for example, a P-CSCF or an Emergency call session control function (E-CSCF) may obtain the location of the terminal from the function (Location Retrieval Function, LRF), or verify the location reported by the terminal, and the LRF obtains information of a Public Safety Answering Point (PSAP) for providing services to the terminal according to the location of the UE, so that the P-CSCF or the E-CSCF may route an Emergency call request of the terminal to the PSAP. However, for the Remote UE, if an IMS emergency call is initiated, the network side needs to obtain location information from the Remote UE and verify the location of the Remote UE, and if the Remote UE does not currently have a signal, the Remote UE cannot initiate providing location information, which results in an emergency call failure. In order to solve the technical problem, the application also provides an IMS emergency call method.

Fig. 5 shows a flowchart of an IMS call method according to an embodiment of the present application, and the method 500 may be performed by a remote terminal. In other words, the method may be performed by software or hardware installed on the remote terminal. As shown in fig. 5, the method may include the following steps.

S510, the remote terminal acquires the identification information used for positioning by the relay terminal.

In the embodiment of the application, the remote terminal can acquire the identification information of the relay terminal for positioning before initiating the IMS call request under the condition that the remote terminal accesses the network through the relay terminal.

In one possible implementation, the remote terminal may obtain the identification information used for positioning by the relay terminal, for example, the SIP URI of the relay terminal, by sending a request to the relay terminal; or an IP address; or a general public user identity (Generic Public Subscription Identifier, GPSI) of the relay terminal; or a pseudo (Pseudonym) identity of the relay terminal.

The GPSI of the relay terminal may also be understood as the mobile station international subscriber identity (Mobile Subscriber International ISDN number, MSISDN) of the relay terminal

In this possible implementation, S510 may include the steps of:

step 1, a remote terminal sends a second request message to the relay terminal, wherein the second request message is used for requesting the relay terminal to provide identification information for positioning.

Optionally, the second request message may further carry second indication information, where the second indication information indicates that the identification information requested by the second request message is used to establish an IMS call service. I.e. the second indication information indicates that said identification information requested is used for performing an IMS call service. Through the alternative implementation manner, the relay terminal can acquire the purpose of requesting the identification information by the remote terminal, so as to send the identification information for positioning to the remote terminal.

And 2, the remote terminal receives a response message sent by the relay terminal, wherein the response message carries the identification information for positioning.

After receiving the second request message of the remote terminal, the relay terminal may send identification information for positioning, for example, a SIP URI of the relay terminal, to the remote terminal; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal.

Optionally, the second request message may be further used to request to obtain location information of the relay terminal, where the response message carries the location information of the relay terminal. Therefore, when the remote terminal initiates the IMS call, the position information of the relay terminal can be reported to the network for verification. In this alternative implementation, the relay terminal may request the LRF to locate the relay terminal, and transmit the result of the location (i.e., the location information of the relay terminal) to the remote terminal.

S512, the remote terminal sends an IMS call request, wherein the IMS call request carries the identification information.

Optionally, in the case that the remote terminal obtains the location information of the relay terminal from the relay terminal, the IMS call request may also carry the location information of the relay terminal.

Optionally, the IMS call request includes an IMS emergency call request.

According to the technical scheme provided by the embodiment of the application, the remote terminal carries the identification information of the relay terminal for positioning in the IMS call request, so that the network side equipment can acquire the corresponding position information according to the identification information, and the IMS call request sent by the remote UE cannot be refused by the network due to the position problem. In addition, the IMS call request may also carry location information of the relay terminal, so that the network side device may verify the location information, thereby avoiding a situation that the IMS call request of the remote terminal is rejected due to the absence of the location information.

Fig. 6 is a schematic flow chart of an IMS emergency call method according to an embodiment of the present application, and as shown in fig. 6, a procedure of making an IMS emergency call by a remote terminal may include the following steps:

S601, a remote UE sends a request message to a relay UE, wherein the request message is used for requesting identification information, such as SIP URI, of the relay UE for positioning; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal.

Optionally, the request message may carry indication information for acquiring the location of the relay UE, that is, the request message is further used for requesting location information of the relay UE.

Optionally, the request message further includes indication information for establishing an emergency call service, through which the information requested by the relay terminal for obtaining the request message is used for the emergency call service, so as to avoid that the relay terminal refuses the request of the remote terminal.

S602, the relay UE sends identification information for positioning to the remote UE, and optionally, the relay UE can also request the LRF to position itself and send the positioning result to the remote UE.

S603, the UE initiates an emergency call request by carrying EMERGENCY URI and identification information for positioning of the relay UE in SIP INVITE messages. Optionally, the SIP INVITE message includes location information of the relay UE

And S604, the P-CSCF or the E-CSCF acquires the position information of the UE from the LRF or verifies the position information reported by the UE, thereby acquiring the PSAP serving the remote terminal. The message includes identification information of the relay UE.

S605, the E-CSCF routes the remote terminal' S emergency call request to the PSAP, which serves the remote terminal.

In the IMS emergency call process of the terminal, the network side establishes a special bearing special for transmitting voice service for the terminal, and in the related technology, one terminal can only have one voice special bearing. If the remote UE initiates the emergency call service, the relay UE is also currently performing the emergency call service, and the network side will reject the remote UE because the voice dedicated bearer for the emergency call cannot be established for the remote UE, resulting in the failure of the emergency call of the remote UE. In order to solve the problem, the embodiment of the application provides another IMS calling method.

Fig. 7 shows a flow diagram of another IMS call method according to an embodiment of the application, which method 700 may be performed by a remote terminal. In other words, the method may be performed by software or hardware installed on the remote terminal. As shown in fig. 7, the method may include the following steps.

S710, the remote terminal sends an IMS call request carrying first information through the relay terminal, wherein the first information is used for indicating the remote terminal to access the network through the relay terminal.

In the embodiment of the application, when the remote terminal sends the IMS call request through the relay terminal, the remote terminal can carry the first information in the IMS call request, and the remote terminal is indicated to be accessed to the network through the relay terminal through the first information, namely the first information indicates that the terminal sending the IMS call request is the remote terminal, so that the network side can know that the currently received IMS call request is sent by the remote terminal, and further can allocate corresponding special bearing for the remote terminal under the condition that the relay terminal has established voice bearing, instead of rejecting the request of the remote terminal, thereby ensuring the realization of the IMS call of the remote terminal.

Optionally, the IMS call may include an IMS emergency call.

In one possible implementation, the first information may include identification information of the relay terminal, for example, a SIP URI; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal. The network side equipment can determine the relay terminal accessed by the remote terminal through the identification information of the relay terminal. Currently, the first information may not include identification information of the relay terminal, and the network side device may determine the relay terminal to which the remote terminal accesses through an IMS emergency call request forwarded by the relay terminal, or the network side device may determine the relay terminal to which the remote terminal accesses through an IP address used by the remote terminal when performing IMS registration.

In the foregoing possible implementation manner, the remote terminal may acquire the identification information of the relay terminal by sending a request to the relay terminal, so optionally, before S710, the method may further include: the remote terminal requests the identification information from the relay terminal.

It should be noted that, the above method 200, method 500 and method 700 provided in the embodiments of the present application may be combined by two or three, for example, the remote terminal may acquire public network address information in a manner described in the method 200, may also acquire identification information for positioning of the relay terminal in a manner of the method 500, and may carry the public network address information and the identification information for positioning in an IMS emergency call request when sending the IMS emergency call request. For another example, the remote terminal may acquire public network address information in the manner described in the method 200, and when sending an IMS emergency call request, the public network address information and the first information in the method 700 may be carried in the IMS emergency call request, so that the network side device may learn that the remote terminal uses the public network address information with the identity of the remote UE, and still allocate a dedicated bearer for the IMS emergency call request of the remote terminal in the case that the corresponding relay terminal has established the dedicated bearer. For another example, the remote terminal may acquire the identification information for positioning of the relay terminal in the method 500, and when sending the IMS emergency call request, the IMS emergency call request may carry the identification information for positioning and the first information in the method 700, etc.

Fig. 8 illustrates a method for processing an IMS call according to an embodiment of the present application, where the method 800 may be performed by a core network device. In other words, the method may be performed by software or hardware installed on the core network device. As shown in fig. 8, the method may include the following steps.

S810, the core network equipment receives a request message, wherein the request message is used for establishing an IMS call for the first terminal or distributing a special bearer corresponding to the IMS call.

In the embodiment of the present application, the core network device may be one or more functional entities in the core network, for example, may be a session control function, a policy control function, or a session management function in the core network.

The dedicated bearer refers to a dedicated transport channel provided for a specific service, which satisfies a certain quality of service (Quality of Service, qoS). In the 4G communication system, an Evolved packet system (Evolved PACKET SYSTEM, EPS) bearer (bearer); in a 4G communication system, qoS flows (flows) may be used. Taking voice service as an example, the dedicated bearer herein refers to EPS bearer or QoS flow with quality of service class 1.

S812, when the core network device determines that the first terminal accesses the network through the relay terminal and the first dedicated bearer corresponding to the IMS call is established for the relay terminal, the core network device establishes the second dedicated bearer corresponding to the IMS call for the first terminal or uses the first dedicated bearer to transmit the data of the IMS call of the first terminal.

Optionally, the first dedicated bearer corresponding to the IMS call is established for the relay terminal, which may specifically mean that the relay terminal has the IMS call, so that the network establishes the dedicated bearer for the relay terminal; or other remote terminals initiate IMS calls through the relay terminal, so the network establishes a dedicated bearer for the relay terminal.

In the embodiment of the application, when receiving the request message for establishing the IMS call for the first terminal or distributing the special bearer corresponding to the IMS call, if the first terminal is determined to be connected to the network through the relay terminal, the core network device establishes the second special bearer for the first terminal or uses the first special bearer to transmit the data of the IMS call of the first terminal under the condition that the first special bearer corresponding to the IMS call is established for the relay terminal, so that the remote relay IMS call of the relay terminal can be realized even if the first special bearer corresponding to the IMS call is established for the relay terminal.

In one possible implementation manner, the request message may carry first information, where the first information is used to instruct the first terminal to access the network through the relay terminal. The first information is the same as the first information in the method 700, and specific reference may be made to the related description in the method 700, which is not repeated here. The core network device may determine that the first terminal accesses the network through the relay terminal based on the first information in S812 described above.

Optionally, the IMS call may include an IMS emergency call.

In the embodiment of the present application, the process of establishing, by the core network device, the second dedicated bearer corresponding to the IMS call for the first terminal may refer to a process of establishing, by the core network device, the dedicated bearer for the call for the UE in the related art, and fig. 9 is a schematic flow chart showing the process of establishing, by the core network device, the second dedicated bearer corresponding to the IMS emergency call for the first terminal in the embodiment of the present application, where the process is preceded by the procedure that the relay UE is currently performing the emergency call. As shown in fig. 9, the method mainly comprises the following steps:

S901, a remote UE requests information of a relay UE, such as a SIP URI, from the relay UE; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal. This step may be an optional step, and the remote UE may not request the information of the relay UE from the relay UE.

S902, when the Remote UE initiates an IMS emergency call, the request is initiated through SIP INVITE message, and the requested SDP carries information of a voice media to be established, emergency call indication information, and first information, where the first information is used to indicate that the request is the Remote UE, or the first information is used to indicate that the request is accessed to the network through a relay, or the first information is information of the relay UE, such as SIP URI; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal.

The P-CSCF sends the invite message to the PSAP via the E-CSCF S903.

The PSAP replies to the SIP 183 message with an SDP answer (answer) via the E-CSCF at S904.

S905, the P-CSCF sends Npcf _ PolicyAuthorization _update message to the PCF, and the message contains the first information, the connection information (connection information) of the remote UE and the media negotiation result.

Wherein the connection information (connection information) includes IP address and port information used when making an emergency call between the remote UE and the PSAP.

S906, the PCF determines that a second voice bearer is established for the relay UE according to the first information, and generates PDR and quality of service (Quality of Service, qoS) rule (rule) according to connection information and sends the PDR and the QoS rule (rule) to the SMF; and the PCF generates QoS parameters of the voice bearer according to the final media negotiation result and sends the QoS parameters to the SMF.

S907, the SMF sends PDU session modification information to the remote UE, and the QoS rule is sent to the remote UE; the SMF simultaneously modifies the QoS parameters of the second voice bearer of the relay UE.

Here, the voice bearer is a dedicated bearer for transmitting voice traffic data of a user, and is QoS flow (flow) in 5G and EPS bearer (bearer) in 4G.

S908, the SMF sends the PDR to the UPF through an N4session modification message; the SMF simultaneously modifies the QoS parameters of the second voice bearer via the message,

S909, the SMF sends a response message to the PCF.

S910, the PCF sends a response message to the P-CSCF.

S911, the P-CSCF sends the response message to the remote UE.

S912, the call setup procedure is completed.

It should be noted that the above procedure is also applicable to the case where the remote UE first establishes an emergency call and the relay UE then establishes an emergency call. In this case, the relay UE carries second information in the request, where the second information is used to indicate that it is the relay UE, or the second information is information of the remote UE. And under the condition that the core network equipment determines that the remote UE accesses the network through the relay UE and a first special bearing corresponding to the IMS emergency call is established for the remote UE, the core network equipment establishes a second special bearing corresponding to the IMS emergency call for the relay UE or uses the first special bearing to transmit the data of the emergency call of the relay UE.

In the embodiment of the present application, the transmission of the IMS call data of the first terminal using the first dedicated bearer may be controlled by different functional entities in the core network, which are described below.

In one possible implementation, the core network device may be a session control function, and in this possible implementation, transmitting the data of the IMS call of the first terminal using the first dedicated bearer may include the steps of:

Step 1, the core network device receives a first request message, where the first request message is used to establish an IMS call for the first terminal.

And step 2, the core network device sends a first message to a policy function entity, wherein the first message is used for modifying the first dedicated bearer of the relay terminal so as to transmit the data of the IMS call of the first terminal by using the first dedicated bearer.

For example, the session control function receives SIP INVITE a message sent by the first terminal, where the message carries EMERGENCY URI information, and optionally, the message may also carry the first information. The session control function controls the first terminal to use the first special bearer to transmit the number of IMS calls of the first terminal, and after receiving SIP INVITE information sent by the first terminal, the session control function determines that the first terminal is a relay terminal, and instructs the strategy functional entity to modify the first special bearer so as to use the first special bearer to transmit the data of the IMS calls of the first terminal.

In the foregoing possible implementation manner, optionally, the first message may carry a target media negotiation result, where the target media negotiation result is generated by the core network device according to the media negotiation result of the first terminal and the media negotiation result of the relay terminal. The media negotiation result of the first terminal may be determined according to the connection information of the first terminal carried in the received first request message. Wherein the media negotiation result includes QoS parameters.

In the foregoing possible implementation manner, optionally, the core network device may store a binding relationship between a first IMS session corresponding to an IMS call of the first terminal and a second IMS session corresponding to an IMS call of the relay terminal and a target session, where the target session is a session between the core network device and a policy function entity. By storing the binding relationship, the core network device can perform corresponding processing in a subsequent flow.

For example, upon receiving an end message of one of the first IMS session and the second IMS session, the core network device may send a second message to the policy function entity, where the second message is used to indicate modification of the first dedicated bearer of the relay terminal, and the modified first dedicated bearer does not need a bearer end message to indicate an end IMS session.

For another example, when receiving the end message of all IMS sessions bound by the target session, the core network device sends a third message to the policy function entity, where the third message is used to instruct deletion of the first dedicated bearer of the relay terminal.

Taking the 5G network as an example, the session control function may be a P-CSCF, and fig. 10 shows a further flow chart of a processing method of an IMS emergency call in an embodiment of the present application, where the P-CSCF controls the remote UE to use a dedicated bearer of the remote UE to transmit data of the emergency call of the remote UE on the premise that the remote UE is currently making the emergency call. As shown in fig. 10, the method mainly includes the steps of:

S1001, a remote UE requests information of a relay UE, such as a SIP URI, from the relay UE; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal. This step is optional.

S1002, when the Remote UE initiates an IMS emergency call, the request is initiated through SIP INVITE message, and the requested SDP carries information of a voice media to be established, emergency call indication information, and first information, where the first information is used to indicate that the request is the Remote UE, or the first information is used to indicate that the request is accessed to the network through a relay, or the first information is information of the relay UE, such as SIP URI; or an IP address; or GPSI of the relay terminal; or Pseudonym identity of the relay terminal.

The P-CSCF sends the invite message to the PSAP via the E-CSCF S1003.

S1004, the PSAP replies to the SIP 183 message via the E-CSCF, which includes SDP ANSWER therein.

S1005, when the P-CSCF determines that the relay UE has a voice call currently, the P-CSCF sends Npcf _ PolicyAuthorization _update message to the PCF/PCRF according to the first information, wherein the message contains connection information of the remote UE and a final media negotiation result.

Wherein connection information contains the IP address and port information used when making an emergency call between the remote UE and the PSAP.

The final media negotiation result is generated by the P-CSCF according to the media negotiation result of the remote UE and the media negotiation result of the relay UE, for example, the guaranteed bit rate (Guaranteed Bit Rate, GBR) parameter negotiated by the relay UE is 64kbps, the GBR parameter negotiated by the remote UE is 64kbps, and the GBR parameter sent by the P-CSCF to the PCF is 128kbps.

Alternatively, the P-CSCF may record 2 IMS sessions (one for each of remote UE and relay UE) bindings (binding) to one Application Session. Subsequently, when the P-CSCF receives Bye messages of 1 IMS session, the P-CSCF sends Npcf _ PolicyAuthorization _update messages to the PCF/PCRF for modifying the voice bearer; when the P-CSCF judges that Bye messages of all IMS sessions are received, a request for deleting the session is sent to the PCF, and the PCF further triggers the SMF to delete the voice bearer.

S1006, PCF generates packet detection rule (Packet Detection Rule, PDR) and QoS rule according to connection information and sends to SMF; the PCF may generate QoS parameters for the voice bearer based on the final media negotiation result and send the QoS parameters to the SMF.

S1007, SMF sends PDU session modification (session modification) information to UE, and QoS rule is sent to UE; the SMF simultaneously modifies QoS parameters of the voice bearer of the relay UE.

S1008, the SMF sends the PDR to the UPF through an N4session modification message; the SMF simultaneously modifies the QoS parameters of the voice bearer through the message,

S1009, the SMF sends a response message to the PCF.

S1010, PCF sends response message to P-CSCF.

S1011, the P-CSCF sends a response message to the remote UE.

S1012, completing the call establishment process.

It should be noted that, the method is also applicable to the case where the remote UE establishes an emergency call first and then establishes an emergency call after the relay UE. In this case, the relay UE carries second information in the request, where the second information is used to indicate that it is the relay UE, or the second information is information of the remote UE. And under the condition that the core network equipment determines that the remote UE accesses the network through the relay UE and a first special bearing corresponding to the IMS emergency call is established for the remote UE, the core network equipment establishes a second special bearing corresponding to the IMS emergency call for the relay UE or uses the first special bearing to transmit the data of the emergency call of the relay UE.

In another possible implementation, the core network device may also be a policy control function. In this possible implementation, transmitting the data of the IMS call of the first terminal using the first dedicated bearer may include the steps of:

Step 1, the core network device receives a second request message, where the second request message is used to allocate a dedicated bearer corresponding to an IMS call to the first terminal.

For example, the policy control function accesses the Npcf _ PolicyAuthorization _create message sent by the session control function to Create application session, where the message includes the first information, connection information, and the media negotiation result of the remote UE.

And step 2, the core network device sends a fourth message to the session function, wherein the fourth message is used for indicating to modify the first dedicated bearer of the relay terminal so as to transmit the data of the IMS call of the first terminal by using the first dedicated bearer.

Optionally, the fourth message carries a target QoS parameter, where the target QoS parameter is generated by the core network device according to a QoS parameter of a dedicated bearer corresponding to the IMS call of the first terminal and a QoS parameter of the first dedicated bearer of the relay terminal.

For example, the policy control function generates a PDR according to connection information of the remote UE sent by the session control function and sends the PDR to the SMF, and generates a final media negotiation result according to the media negotiation result of the remote UE sent by the session control function. The final media negotiation result is generated by the policy control function according to the media negotiation result of the remote UE and the media negotiation result of the relay UE, for example, the GBR parameter negotiated by the relay UE is 64kbps, the GBR parameter negotiated by the remote UE is 64kbps, and the GBR parameter sent by the P-CSCF to the PCF is 128kbps.

Optionally, the core network device may store a binding relationship between a first target session corresponding to the first terminal and a second target session corresponding to the relay terminal and the first dedicated bearer, where the first target session and the second target session are sessions between the core network device and a policy function entity. By storing the binding relationship, reasonable processing can be performed when the related operation is received later.

For example, upon receiving a delete message for one of the first target session and the second target session, the core network device sends a fifth message to a session management function, wherein the fifth message is used to instruct modification of the SMF to modify the first dedicated bearer of the relay terminal.

For another example, after receiving the deletion message of all target sessions bound by the first dedicated bearer, the core network device sends a sixth message to the session management function, where the sixth message is used to instruct deletion of the first dedicated bearer of the relay terminal.

Taking a 5G network as an example, the policy control function may be a PCF, and fig. 11 shows a further flowchart of a processing method of an IMS emergency call in an embodiment of the present application, where, on the premise that a relay UE is currently making an emergency call, the PCF controls the remote UE to use a dedicated bearer of the relay UE to transmit data of the emergency call of the remote UE. As shown in fig. 11, the method mainly includes the steps of:

s1101-1104. Steps S1001-S1004 of fig. 10.

S1105, the P-CSCF sends Npcf _ PolicyAuthorization _create message to the PCF to Create an application session (application session), where the message contains the first information, connection information, and the media negotiation result of the remote UE.

Connection information contains the IP address and port information used in making the emergency call between the remote UE and the PSAP.

S1106, the PCF maps application session of both the relay UE and the remote UE to the voice bearer of the relay UE according to the first information. The PCF generates PDR according to connection information of remote UE sent by P-CSCF and sends the PDR to SMF.

The PCF generates a final media negotiation result according to the media negotiation result of the remote UE sent by the P-CSCF. The final media negotiation result is generated by the PCF according to the media negotiation result of the remote UE and the media negotiation result of the relay UE, for example, the GBR parameter negotiated by the relay UE is 64kbps, the GBR parameter negotiated by the remote UE is 64kbps, and the GBR parameter sent by the P-CSCF to the PCF is 128kbps.

Wherein, the PCF may record that 2 application session (remote UE and relay UE each have a session) map to one voice bearer. When the PCF receives the delete message of 1 session, the PCF sends a request to the SMF to modify the voice bearer; when the PCF judges that delete messages of all session are received, a request for deleting the voice bearer is sent to the SMF.

S1107-S1111, as in S1007-S1011 of FIG. 10.

It should be noted that, the above is described taking 5G as an example, the method is equally applicable to 4G, and the policy control function in 4G may be a policy charging control function (Policy Charging Control Function, PCRF).

In yet another possible implementation, the core network device may also be a session management function. In this possible implementation, transmitting the data of the IMS call of the first terminal using the first dedicated bearer may include:

Step 1, the core network device receives a third request message, where the third request message is used to allocate a dedicated bearer corresponding to an IMS call to the first terminal.

For example, the session management function receives a request sent by the policy management function, where the request is used to allocate a dedicated bearer corresponding to the IMS call to the first terminal.

And 2, the core network equipment modifies the first special bearer to transmit the IMS call data of the first terminal by using the first special bearer.

By the possible implementation manner, the session management function may enable the first terminal to transmit IMS call data of the first terminal using the first dedicated bearer through modification of the first dedicated bearer.

Optionally, the core network device may generate the target QoS parameter according to the QoS parameter of the dedicated bearer corresponding to the IMS call of the first terminal and the QoS parameter of the first dedicated bearer of the relay terminal; when the core network device modifies the first dedicated bearer, the QoS parameter corresponding to the first dedicated bearer may be modified to the target QoS parameter.

Alternatively, the core network device may record that the first dedicated bearer is applied to the first terminal and the relay terminal. So that the core network device can execute correct operation when receiving the related instruction subsequently.

For example, in the case of receiving one of a request for deleting the dedicated bearer of the first terminal and a request for deleting the dedicated bearer of the relay terminal, the core network device transmits a seventh message for indicating modification of the first dedicated bearer.

For another example, after receiving the deletion instruction of the dedicated bearers of all the terminals bound to the first dedicated bearer, the core network device sends an eighth message, where the eighth message is used to instruct deletion of the first dedicated bearer.

Taking the 5G network as an example, the session management function may be an SMF, and fig. 12 is a schematic flow chart illustrating a further processing method of an IMS emergency call in an embodiment of the present application, where on the premise that a relay UE is currently making an emergency call, the SMF controls the remote UE to use a dedicated bearer of the relay UE to transmit data of the emergency call of the remote UE. As shown in fig. 12, the method mainly includes the steps of:

s1201-1204, steps S1001-S1004 of fig. 10.

S1205, the P-CSCF sends Npcf _ PolicyAuthorization _create message to the PCF/PCRF to Create application session, where the message contains the first information, connection information and the media negotiation result of the remote UE.

S1206, PCF sends request to SMF for providing service for remote UE, and requests to establish voice bearer, and the request carries media negotiation result and first information of remote UE

S1207, the SMF generates a final media negotiation result according to the first information and the media negotiation result of the remote UE. For example, the GBR parameter negotiated by the relay UE is 64kbps, the GBR parameter negotiated by the remote UE is 64kbps, and the GBR parameter sent by the P-CSCF to the PCF is 128kbps.

The SMF may record the voice bearer for 2 UEs, and when receiving a deletion instruction sent by the PCF for one of the UEs, the SMF modifies the voice bearer, for example, sends a modification message; when the SMF determines that deletion requests of all UEs are received, deleting the corresponding voice bearer, for example, sending a deletion message.

S1208-1211, like S1007-S1011 in FIG. 10.

It should be noted that, the above is taken as an example of 5G, the method is equally applicable to 4G, and the session management function in 4G may be a packet data Network Gateway (PGW) or PGW-C.

According to the IMS service request method provided by the embodiment of the application, the execution main body can be the IMS service request device. In the embodiment of the application, the request device for the IMS service provided by the embodiment of the application is described by taking the request method for executing the IMS service by the request device for the IMS service as an example.

Fig. 13 is a schematic structural diagram of an IMS service requesting device according to an embodiment of the present application, where, as shown in fig. 13, the device mainly includes: a first acquisition module 1301 and a first transmission module 1302.

In the embodiment of the present application, a first obtaining module 1301 is configured to obtain a public network address message from a relay terminal; a first sending module 1302, configured to send an IMS service request to a network side device, where the IMS service request carries the public network address information.

In one possible implementation, obtaining public network address information from a relay terminal includes:

If the address information obtained from the relay terminal is determined to be a private network address, a first request message is sent to the relay terminal, wherein the first request message is used for requesting to obtain public network address information corresponding to the private network address;

And receiving the public network address information sent by the relay terminal.

In one possible implementation manner, the first request message carries first indication information, where the first indication information is used to indicate that the public network address information requested by the first request message is used to establish an IMS call service.

In one possible implementation manner, the first request message carries identification information of the remote terminal.

In one possible implementation, the public network address information includes: a port number and an IP address.

In one possible implementation manner, sending an IMS service request to a network side device includes:

An IMS registration request is sent to network side equipment, wherein the IMS registration request carries the IP address; and/or the number of the groups of groups,

And sending an IMS call request to network side equipment, wherein the IMS call request carries the IP address and the port number.

In one possible implementation, the method further includes: a receiving module, configured to receive an IMS message forwarded by the relay terminal to at least one remote terminal; decrypting the IMS message to obtain the content information of the IMS message.

In one possible implementation manner, the first obtaining module 1301 is further configured to obtain, from a relay terminal, identification information used for positioning by the relay terminal; the first sending module 1302 is further configured to send an IMS call request, where the IMS call request carries identification information of the relay terminal.

In one possible implementation manner, obtaining, from a relay terminal, identification information of the relay terminal includes:

Sending a second request message to the relay terminal, wherein the second request message is used for requesting the identification information of the relay terminal for positioning;

And receiving the identification information for positioning, which is sent by the relay terminal.

In one possible implementation manner, the second request message carries second indication information, where the second indication information indicates that the identification information requested by the second request message is used for establishing an IMS call service.

In one possible implementation, the second request message is further used to request to obtain location information of the relay terminal.

In one possible implementation, the IMS call request also carries the location information.

In one possible implementation, the first sending module 1302 is further configured to send, through a relay terminal, an IMS call request carrying first information, where the first information is used to instruct the remote terminal to access a network through the relay terminal.

In one possible implementation, the first information includes identification information of the relay terminal.

In one possible implementation, the first obtaining module 1301 is further configured to request the identification information from the relay terminal.

According to the IMS calling method provided by the embodiment of the application, the execution main body can be an IMS calling device. In the embodiment of the present application, a method for executing an IMS call by an IMS call device is taken as an example, and the IMS call device provided by the embodiment of the present application is described.

Fig. 14 is a schematic structural diagram of an IMS call device according to an embodiment of the present application, and as shown in fig. 14, the device 1400 mainly includes: a second acquisition module 1401 and a second transmission module 1402.

In the embodiment of the present application, a second obtaining module 1401 is configured to obtain identification information used for positioning by the relay terminal; a second sending module 1402, configured to send an IMS call request, where the IMS call request carries identification information of the relay terminal.

In one possible implementation manner, the method for obtaining the identification information of the relay terminal from the relay terminal includes:

And receiving a response message sent by the relay terminal, wherein the response message carries the identification information for positioning.

In one possible implementation manner, the second request message is further used for requesting to acquire the location information of the relay terminal; the response message also carries the position information.

Fig. 15 is a schematic diagram of another structure of an IMS call device according to an embodiment of the present application, and as shown in fig. 15, the device 1500 mainly includes: a third acquisition module 1501 and a third transmission module 1502.

In the embodiment of the application, the third obtaining module 1501 is configured to obtain first information; the third sending module 1502 is configured to send, through a relay terminal, an IMS call request carrying first information, where the first information is used to instruct the remote terminal to access a network through the relay terminal.

In one possible implementation, the third obtaining module 102 is further configured to request the identification information from the relay terminal.

The request device and the IMS call device for the IMS service in the embodiment of the application may be an electronic device, for example, an electronic device with an operating system, or may be a component in the electronic device, for example, an integrated circuit or a chip. The electronic device may be a terminal, or may be other devices than a terminal. By way of example, the terminals may include, but are not limited to, the types of terminals 11 listed above, other devices may be servers, network attached storage (Network Attached Storage, NAS), etc., and embodiments of the present application are not limited in detail.

The IMS service requesting device and the IMS calling device provided in the embodiments of the present application can respectively implement each process implemented by the remote terminal in the method embodiments of fig. 2 to 12, and achieve the same technical effects, so that repetition is avoided, and no further description is given here.

According to the IMS call processing method provided by the embodiment of the application, the execution main body can be an IMS call processing device. In the embodiment of the present application, the processing device for IMS call provided in the embodiment of the present application is described by taking the processing device for IMS call to execute the processing of IMS call as an example.

Fig. 16 shows a schematic structural diagram of an IMS call processing device according to an embodiment of the present application, and as shown in fig. 16, the device 1600 mainly includes: a receiving module 1601 and a processing module 1602.

In the embodiment of the present application, a receiving module 1601 is configured to receive a request message, where the request message is used to establish an IMS call for a first terminal or allocate a dedicated bearer corresponding to the IMS call; a processing module 1602, configured to, when it is determined that the first terminal accesses the network through the relay terminal and a first dedicated bearer corresponding to an IMS call has been established for the relay terminal, establish a second dedicated bearer corresponding to the IMS call for the first terminal, or transmit data of the IMS call of the first terminal using the first dedicated bearer.

In one possible implementation manner, the request message carries first information, where the first information is used to instruct the first terminal to access a network through a relay terminal;

determining that the first terminal accesses to a network through a relay terminal comprises: and determining that the first terminal accesses the network through the relay terminal according to the first information.

In one possible implementation manner, the transmitting the data of the IMS call of the first terminal using the first dedicated bearer includes:

Receiving a first request message, wherein the first request message is used for establishing an IMS call for the first terminal;

And sending a first message to a policy function entity, wherein the first message is used for modifying the first special bearer of the relay terminal so as to transmit the data of the IMS call of the first terminal by using the first special bearer.

In one possible implementation manner, the first message carries a target media negotiation result, where the target media negotiation result is generated by the core network device according to the media negotiation result of the first terminal and the media negotiation result of the relay terminal.

In one possible implementation, the method further includes: and the storage module is used for storing the binding relation between a first IMS session corresponding to the IMS call of the first terminal and a second IMS session corresponding to the emergency call of the relay terminal and a target session, wherein the target session is a session between the core network equipment and a strategy functional entity.

In a possible implementation, the processing module 1602 is further configured to send a second message to the policy function entity upon receiving an end message of one of the first IMS session and the second IMS session, where the second message is used to indicate modification of the first dedicated bearer of the relay terminal; or alternatively

And when receiving the ending information of all IMS sessions bound by the target session, sending a third message to the strategy functional entity, wherein the third message is used for indicating the deletion of the first special bearer of the relay terminal.

Receiving a second request message, wherein the second request message is used for distributing special bearing corresponding to the IMS call for the first terminal;

And sending a fourth message to a session function, wherein the fourth message is used for indicating to modify the first special bearer of the relay terminal so as to use the first special to transmit the data of the IMS call of the first terminal.

In one possible implementation manner, the fourth message carries a target QoS parameter, where the target QoS parameter is generated by the core network device according to a QoS parameter of a dedicated bearer corresponding to the IMS call of the first terminal and a QoS parameter of the first dedicated bearer of the relay terminal.

In one possible implementation, the method further includes: and the storage module is used for storing a binding relation between a first target session corresponding to the first terminal and a second target session corresponding to the relay terminal and the first special bearer, wherein the first target session and the second target session are sessions between the core network equipment and a policy function entity.

In one possible implementation, the processing module 1602 is further configured to send a fifth message to a session management function upon receiving a delete message of one of the first target session and the second target session, where the fifth message is configured to instruct modification of the SMF to modify the first dedicated bearer of the relay terminal; or after receiving the deletion message of all target sessions bound by the first dedicated bearer, sending a sixth message to the session management function, wherein the sixth message is used for indicating that the first dedicated bearer of the relay terminal is deleted.

receiving a third request message, wherein the third request message is used for distributing special bearing corresponding to the IMS call for the first terminal;

and modifying the first special bearing to transmit the IMS call data of the first terminal by using the first special bearing.

In one possible implementation, the processing module 1602 is further to:

A target QoS parameter generated according to the QoS parameter of the special bearer corresponding to the IMS call of the first terminal and the QoS parameter of the first special bearer of the relay terminal;

modifying the first dedicated bearer includes: and modifying the QoS parameters corresponding to the first special bearer into the target QoS parameters.

In one possible implementation, the method further includes: and the storage module is used for storing that the first special bearer is applied to the first terminal and the relay terminal.

In one possible implementation manner, the processing module 1602 is further configured to send a seventh message, where one of a request for deleting the dedicated bearer of the first terminal and a request for deleting the dedicated bearer of the relay terminal is received, where the seventh message is used to instruct modification of the first dedicated bearer; or after receiving the deletion instruction of the dedicated bearers of all terminals bound to the first dedicated bearer, sending an eighth message, where the eighth message is used to instruct deletion of the first dedicated bearer.

The processing device for IMS call provided in the embodiment of the present application can implement each process implemented by the core network device in the method embodiments of fig. 2 to 12, and achieve the same technical effects, and for avoiding repetition, a detailed description is omitted here.

Optionally, as shown in fig. 17, the embodiment of the present application further provides a communication device 1700, including a processor 1701 and a memory 1702, where the memory 1702 stores a program or an instruction that can be executed on the processor 1701, for example, when the communication device 1700 is a terminal, the program or the instruction implements the steps of the foregoing method embodiments 200, 500 or 700 when executed by the processor 1701, and the same technical effect can be achieved. When the communication device 1700 is a core network device, the program or the instructions, when executed by the processor 1701, implement the steps of the method embodiment 800 described above, and achieve the same technical effects, and are not repeated herein.

The embodiment of the application also provides a terminal, which comprises a processor and a communication interface, wherein the processor is used for realizing the steps of the method embodiment 200, 500 or 700, and the communication interface is used for communicating with external equipment. The terminal embodiment corresponds to the terminal-side method embodiment, and each implementation process and implementation manner of the method embodiment can be applied to the terminal embodiment, and the same technical effects can be achieved. Specifically, fig. 18 is a schematic diagram of a hardware structure of a terminal for implementing an embodiment of the present application.

The terminal 1800 includes, but is not limited to: at least some of the components of the radio frequency unit 1801, the network module 1802, the audio output unit 1803, the input unit 1804, the sensor 1805, the display unit 1806, the user input unit 1807, the interface unit 1808, the memory 1809, the processor 1810, and the like.

Those skilled in the art will appreciate that the terminal 1800 may also include a power source (e.g., a battery) for powering the various components, which may be logically connected to the processor 1810 by a power management system so as to perform functions such as managing charging, discharging, and power consumption by the power management system. The terminal structure shown in fig. 18 does not constitute a limitation of the terminal, and the terminal may include more or less components than shown, or may combine some components, or may be arranged in different components, which will not be described in detail herein.

It should be appreciated that in embodiments of the present application, the input unit 1804 may include a graphics processing unit (Graphics Processing Unit, GPU) 18041 and a microphone 18042, with the graphics processor 18041 processing image data of still pictures or video obtained by an image capture device (e.g., a camera) in a video capture mode or an image capture mode. The display unit 1806 may include a display panel 18061, which may be configured in the form of a liquid crystal display, organic light emitting diodes, or the like, for the display panel 18061. The user input unit 1807 includes at least one of a touch panel 18071 and other input devices 18072. Touch panel 18071, also referred to as a touch screen. Touch panel 18071 may include two parts, a touch detection device and a touch controller. Other input devices 18072 may include, but are not limited to, a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and so forth, which are not described in detail herein.

In the embodiment of the present application, after receiving downlink data from the core network device, the radio frequency unit 1801 may transmit the downlink data to the processor 1810 for processing; in addition, the radio frequency unit 1801 may send uplink data to the core network device. In general, the radio frequency unit 1801 includes, but is not limited to, an antenna, an amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like.

The memory 1809 may be used to store software programs or instructions and various data. The memory 1809 may mainly include a first memory area storing programs or instructions and a second memory area storing data, wherein the first memory area may store an operating system, application programs or instructions (such as a sound playing function, an image playing function, etc.) required for at least one function, and the like. Further, the memory 1809 may include volatile memory or nonvolatile memory, or the memory 1809 may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM), static random access memory (STATIC RAM, SRAM), dynamic random access memory (DYNAMIC RAM, DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate Synchronous dynamic random access memory (Double DATA RATE SDRAM, DDRSDRAM), enhanced Synchronous dynamic random access memory (ENHANCED SDRAM, ESDRAM), synchronous link dynamic random access memory (SYNCH LINK DRAM, SLDRAM), and Direct random access memory (DRRAM). Memory 1809 in embodiments of the present application includes, but is not limited to, these and any other suitable types of memory.

The processor 1810 may include one or more processing units; optionally, the processor 1810 integrates an application processor that primarily processes operations involving an operating system, user interface, application programs, and the like, and a modem processor that primarily processes wireless communication signals, such as a baseband processor. It will be appreciated that the modem processor described above may not be integrated into the processor 1810.

Wherein, the processor 1810 is configured to obtain public network address information from the relay terminal;

the radio frequency unit 1801 is configured to send an IMS service request to a network side device, where the IMS service request carries the public network address information.

Or a processor 1810, configured to obtain identification information of the relay terminal for positioning;

And a radio frequency unit 1801, configured to send an IMS call request, where the IMS call request carries identification information of the relay terminal.

Or a radio frequency unit 1801, configured to send, through a relay terminal, an IMS call request carrying first information, where the first information is used to instruct the remote terminal to access a network through the relay terminal.

The embodiment of the application also provides a core network device, which comprises a processor and a communication interface, wherein the processor is used for realizing the steps of the embodiment 800 of the method, and the communication interface is used for communicating with external devices. The core network device embodiment corresponds to the core network device method embodiment, and each implementation process and implementation manner of the method embodiment can be applied to the core network device embodiment, and the same technical effects can be achieved.

Specifically, the embodiment of the application also provides core network equipment. As shown in fig. 19, the core network device 1900 includes: a processor 1901, a network interface 1902, and a memory 1903. The network interface 1902 is, for example, a common public radio interface (common public radio interface, CPRI).

Specifically, the core network device 1900 according to the embodiment of the present invention further includes: instructions or programs stored in the memory 1903 and executable on the processor 1901, the processor 1901 invokes the instructions or programs in the memory 1903 to perform the methods performed by the modules shown in fig. 16, and achieve the same technical effects, and are not repeated here.

The embodiment of the present application further provides a readable storage medium, where a program or an instruction is stored, where the program or the instruction, when executed by a processor, implements each process of each step of the foregoing method embodiment 200, 500, 700, or 800, and the same technical effect can be achieved, so that repetition is avoided, and no description is repeated here.

Wherein the processor is a processor in the terminal described in the above embodiment. The readable storage medium includes computer readable storage medium such as computer readable memory ROM, random access memory RAM, magnetic or optical disk, etc.

The embodiment of the present application further provides a chip, where the chip includes a processor and a communication interface, where the communication interface is coupled to the processor, and the processor is configured to execute a program or an instruction, to implement each step of the foregoing method embodiment 200, 500, 700, or 800, and to achieve the same technical effect, and to avoid repetition, details are not described herein.

It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, or the like.

The embodiments of the present application further provide a computer program/program product stored in a storage medium, where the computer program/program product is executed by at least one processor to implement the steps of the method embodiments 200, 500, 700 or 800, and achieve the same technical effects, and are not repeated herein.

The embodiment of the application also provides an IMS calling system, which comprises: a remote terminal operable to perform the steps of method embodiment 200, 500 or 700 described above, and a core network device operable to perform the steps of method embodiment 800 described above.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present application is not limited to performing the functions in the order shown or discussed, but may also include performing the functions in a substantially simultaneous manner or in an opposite order depending on the functions involved, e.g., the described methods may be performed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a computer software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method according to the embodiments of the present application.

The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are to be protected by the present application.

Claims

1. A method for requesting an IMS service, comprising:

the remote terminal acquires public network address information from the relay terminal;

And the remote terminal sends an IMS service request to network side equipment, wherein the IMS service request carries the public network address information.

2. The method of claim 1, wherein the remote terminal obtaining public network address information from a relay terminal comprises:

If the remote terminal determines that the address information obtained from the relay terminal is a private network address, a first request message is sent to the relay terminal, wherein the first request message is used for requesting to obtain public network address information corresponding to the private network address;

and the remote terminal receives the public network address information sent by the relay terminal.

3. The method of claim 1, wherein the remote terminal obtaining public network address information from a relay terminal comprises:

and under the condition that the remote terminal sends a Relay Service Code (RSC) corresponding to the emergency service to the relay terminal, the remote terminal receives public network address information of an emergency Protocol Data Unit (PDU) session corresponding to the RSC sent by the relay terminal.

4. The method according to claim 3, wherein the remote terminal receiving public network address information of an emergency protocol data unit PDU session corresponding to the RSC sent by the relay terminal, includes:

The remote terminal sends a direct link establishment request to the relay terminal, wherein the direct link establishment request comprises RSCs corresponding to emergency services; the remote terminal receives a direct link establishment acceptance message sent by the relay terminal, wherein the direct link establishment acceptance message comprises public network address information of an emergency PDU session corresponding to the RSC; or alternatively

And the remote terminal sends a request message for requesting to acquire the IP address to the relay terminal, and the remote terminal receives public network address information of the emergency PDU session corresponding to the RSC sent by the relay terminal.

5. The method of claim 2, wherein the first request message carries first indication information, where the first indication information is used to indicate that the public network address information requested by the first request message is used to establish an IMS service.

6. The method according to claim 2, wherein the first request message carries identification information of the remote terminal.

7. The method according to any one of claims 1 to 6, the public network address information comprising: an IP address; or a port number and an IP address.

8. The method according to claim 7, wherein the remote terminal sends an IMS service request to a network side device, comprising:

The remote terminal sends an IMS registration request to network side equipment, wherein the IMS registration request carries the IP address; or alternatively, the first and second heat exchangers may be,

The remote terminal sends an IMS call request to network side equipment, wherein the IMS call request carries the IP address; or alternatively, the first and second heat exchangers may be,

And the remote terminal sends an IMS call request to network side equipment, wherein the IMS call request carries the IP address and the port number.

9. The method according to any one of claims 1 to 8, wherein after the remote terminal sends an IMS service request to a network side device, the method further comprises:

Receiving IMS information forwarded by the relay terminal to at least one far-end terminal;

decrypting the IMS message to obtain the content information of the IMS message.

10. The method according to claim 1, wherein the method further comprises:

The remote terminal acquires the identification information of the relay terminal for positioning from the relay terminal;

And the remote terminal sends an IMS call request, wherein the IMS call request carries the identification information of the relay terminal.

11. The method of claim 10, wherein the remote terminal obtaining the identification information of the relay terminal from the relay terminal comprises:

The remote terminal sends a second request message to the relay terminal, wherein the second request message is used for requesting the identification information of the relay terminal for positioning;

And the remote terminal receives the identification information for positioning, which is sent by the relay terminal.

12. The method of claim 11, wherein the second request message carries second indication information, and the second indication information indicates that the identification information requested by the second request message is used for establishing an IMS call service.

13. The method of claim 11, wherein the second request message is further used to request acquisition of location information of the relay terminal.

14. The method of claim 13, wherein the location information is also carried in the IMS call request.

15. The method according to claim 1, wherein the method further comprises:

and the remote terminal sends an IMS call request carrying first information through a relay terminal, wherein the first information is used for indicating the remote terminal to access a network through the relay terminal.

16. The method of claim 15, wherein the first information comprises identification information of the relay terminal.

17. The method of claim 16, wherein prior to the remote terminal sending the IMS call request carrying the first information, the method further comprises:

the remote terminal requests the identification information from the relay terminal.

18. The method according to any one of claims 10 to 17, wherein the identification information of the relay terminal comprises at least one of:

a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) of the relay terminal;

the IP address of the relay terminal;

the general public user identifier GPSI of the relay terminal;

And the pseudo identification of the relay terminal.

19. An IMS call method, comprising:

The remote terminal acquires the identification information of the relay terminal for positioning;

and the remote terminal sends an IMS call request, wherein the IMS call request carries the identification information.

20. The method of claim 19, wherein the remote terminal obtaining the identification information of the relay terminal from the relay terminal comprises:

And the remote terminal receives a response message sent by the relay terminal, wherein the response message carries the identification information for positioning.

21. The method of claim 19, wherein the second request message carries second indication information, and the second indication information indicates that the identification information requested by the second request message is used for establishing an IMS call service.

22. The method according to claim 20, wherein the second request message is further used for requesting acquisition of location information of the relay terminal; the response message also carries the position information.

23. The method of claim 22, wherein the location information is also carried in the IMS call request.

24. The method according to any one of claims 19 to 23, wherein the identification information of the relay terminal comprises at least one of:

the IP address of the relay terminal;

the general public user identifier GPSI of the relay terminal;

And the pseudo identification of the relay terminal.

25. An IMS call method, comprising:

the remote terminal sends an IMS call request carrying first information through the relay terminal, wherein the first information is used for indicating the remote terminal to access the network through the relay terminal.

26. The method of claim 25, wherein the first information comprises identification information of the relay terminal.

27. The method of claim 26, wherein before the remote terminal sends the IMS call request carrying the first information, the method further comprises:

28. The method according to any one of claims 25 to 27, wherein the identification information of the relay terminal comprises at least one of:

the IP address of the relay terminal;

the general public user identifier GPSI of the relay terminal;

And the pseudo identification of the relay terminal.

29. A method for processing an IMS call, comprising:

The method comprises the steps that core network equipment receives a request message, wherein the request message is used for establishing an IMS call for a first terminal or distributing a special bearer corresponding to the IMS call;

and under the condition that the core network equipment determines that the first terminal accesses the network through the relay terminal and a first special bearer corresponding to the IMS call is established for the relay terminal, a second special bearer corresponding to the IMS call is established for the first terminal, or the first special bearer is used for transmitting the data of the IMS call of the first terminal.

30. The method of claim 29, wherein the step of providing the first information comprises,

The request message carries first information, and the first information is used for indicating the first terminal to access a network through a relay terminal;

The core network device determining that the first terminal accesses to a network through a relay terminal includes: and the core network equipment determines that the first terminal accesses the network through the relay terminal according to the first information.

31. The method according to claim 29 or 30, wherein said transmitting data of an IMS call of the first terminal using the first dedicated bearer comprises:

The core network device receives a first request message, wherein the first request message is used for establishing an IMS for the first terminal;

The core network device sends a first message to a policy function entity, wherein the first message is used for modifying the first dedicated bearer of the relay terminal so as to transmit data of an IMS call of the first terminal by using the first dedicated bearer.

32. The method of claim 31, wherein the first message carries a target media negotiation result, the target media negotiation result being generated by the core network device according to a media negotiation result of the first terminal and a media negotiation result of the relay terminal, wherein the media negotiation result includes a quality of service QoS parameter.

33. The method of claim 31, further comprising:

The core network device stores a binding relation between a first IMS session corresponding to the IMS call of the first terminal and a second IMS session corresponding to the IMS call of the relay terminal and a target session, wherein the target session is a session between the core network device and a strategy functional entity.

34. The method of claim 33, wherein the method further comprises:

Upon receiving an end message of one of the first IMS session and the second IMS session, the core network device sends a second message to the policy function entity, where the second message is used to instruct modification of the first dedicated bearer of the relay terminal; or alternatively

And when receiving the ending information of all IMS sessions bound by the target session, the core network equipment sends a third message to the strategy functional entity, wherein the third message is used for indicating the deletion of the first special bearing of the relay terminal.

35. The method according to claim 29 or 30, wherein said transmitting data of an IMS call of the first terminal using the first dedicated bearer comprises:

the core network equipment receives a second request message, wherein the second request message is used for distributing special bearing corresponding to the IMS call for the first terminal;

the core network device sends a fourth message to a session function, where the fourth message is used to instruct modification of the first dedicated bearer of the relay terminal to transmit data of an IMS call of the first terminal using the first dedicated bearer.

36. The method according to claim 35, wherein the fourth message carries a target QoS parameter, and the target QoS parameter is generated by the core network device according to a QoS parameter of a dedicated bearer corresponding to the IMS call of the first terminal and a QoS parameter of the first dedicated bearer of the relay terminal.

37. The method of claim 35, wherein the method further comprises:

The core network device stores a binding relationship between a first target session corresponding to the first terminal and a second target session corresponding to the relay terminal and the first dedicated bearer, wherein the first target session and the second target session are sessions between the core network device and a policy function entity.

38. The method of claim 35, wherein the method further comprises:

Upon receiving a delete message for one of the first target session and the second target session, the core network device sends a fifth message to a session management function, wherein the fifth message is used to instruct modification of the SMF to modify the first dedicated bearer of the relay terminal; or alternatively

After receiving the deletion message of all target sessions bound by the first dedicated bearer, the core network device sends a sixth message to the session management function, where the sixth message is used to instruct deletion of the first dedicated bearer of the relay terminal.

39. The method according to claim 29 or 30, wherein said transmitting data of an IMS call of the first terminal using the first dedicated bearer comprises:

the core network device receives a third request message, wherein the third request message is used for distributing special bearing corresponding to the IMS call for the first terminal;

The core network device modifies the first dedicated bearer to use the first dedicated to transmit data of the IMS call of the first terminal.

40. The method of claim 39, wherein the step of,

The method further comprises the steps of: the core network equipment generates target QoS parameters according to the QoS parameters of the special bearer corresponding to the IMS call of the first terminal and the QoS parameters of the first special bearer of the relay terminal;

The core network device modifying the first dedicated bearer includes: and modifying the QoS parameters corresponding to the first special bearer into the target QoS parameters.

41. The method of claim 39, further comprising:

the core network device records that the first dedicated bearer is applied to the first terminal and the relay terminal.

42. The method of claim 41, further comprising:

In the case of receiving one of a request for deleting the dedicated bearer of the first terminal and a request for deleting the dedicated bearer of the relay terminal, the core network device transmits a seventh message for indicating modification of the first dedicated bearer; or alternatively

After receiving the deletion instruction of the dedicated bearers of all terminals bound to the first dedicated bearer, the core network device sends an eighth message, where the eighth message is used to instruct deletion of the first dedicated bearer.

43. An IMS service requesting device, comprising:

the first acquisition module is used for acquiring public network address information from the relay terminal;

The first sending module is used for sending an IMS service request to the network side equipment, wherein the IMS service request carries the public network address information.

44. An IMS call device, comprising:

The second acquisition module is used for acquiring the identification information of the relay terminal for positioning;

and the second sending module is used for sending an IMS call request, wherein the IMS call request carries the identification information of the relay terminal.

45. An IMS call device, comprising:

And the third sending module is used for sending an IMS call request carrying first information through the relay terminal, wherein the first information is used for indicating the remote terminal to access the network through the relay terminal.

46. An IMS call processing device, comprising:

the receiving module is used for receiving a request message, wherein the request message is used for establishing an IMS call for the first terminal or distributing a special bearer corresponding to the IMS call;

And the processing module is used for establishing a second special bearer corresponding to the IMS call for the first terminal or transmitting the data of the IMS call of the first terminal by using the first special bearer under the condition that the first terminal is determined to access the network through the relay terminal and the first special bearer corresponding to the IMS call is established for the relay terminal.

47. A terminal comprising a processor and a memory storing a program or instructions executable on the processor, which when executed by the processor, performs the steps of the method of any one of claims 1 to 25.

48. A core network device comprising a processor and a memory storing a program or instructions executable on the processor, which when executed by the processor, implement the steps of the method of any one of claims 26 to 37.

49. A readable storage medium, characterized in that it stores thereon a program or instructions, which when executed by a processor, implements the steps of the method according to any of claims 1 to 28 or the steps of the method according to any of claims 29 to 42.