Communication method and apparatus

Abstract

Embodiments of the present application relate to the field of communications, provide a communication method and apparatus, and can reduce power consumption of terminal devices supporting a plurality of DC applications and enable free message and notification transmitting and receiving of the DC applications. The method comprises: when a terminal device registers to an IP multimedia subsystem (IMS) network on the basis of a session initiation protocol (SIP) message, a push server receives a first push message from a server of a DC application and triggers a first SIP message on the basis of the first push message, wherein the first push message is used for requesting to send a push notification to the DC application on the terminal device, and the first SIP message is used for sending the push notification to the DC application. Therefore, on the basis of an existing SIP persistent connection established based on a call, the SIP persistent connection is reused to send a push notification to a DC application in a closed state or tombstone state by means of an SIP message, such that power consumption is reduced, and free message and the notification transmitting and receiving can be achieved.

Description

Communication method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 29, 2023, with application number 202311868393.3 and application name “Communication Method and Device,” the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communications, and in particular to communication methods and devices. Background Art

[0003] The new call service (5G New Calling) under the fifth-generation (5G) mobile communication system is an enhanced voice call service based on the 5G network. It transmits the service through an additional data channel (DC) between the terminal device and the Internet Protocol (IP) Multimedia Subsystem (IMS). The 3rd Generation Partnership Project (3GPP) protocol (Release 18) proposed that DC should be established on the basis of IMS calls, while Release 19 proposed standalone DC (SADC). SADC allows multiple DC applications to run independently of calls in parallel.

[0004] Currently, for non-DC applications on terminal devices, when an application enters the background, the system records the current application state, terminates the program, and releases the resources used by the application. This prevents background applications from competing with foreground applications for resources. For applications in this state, the application server can provide message push notifications to the application through a push server. This push server maintains a system-level persistent connection with the terminal device to send push messages to applications in the tombstone state. This system-level persistent connection cannot be canceled on the terminal device side, which increases the power consumption of the terminal device to maintain the connection.

[0005] However, for the IMSDC scenario, it is still unclear how to deliver push messages with low power consumption.

[0006] Summary of the Invention

[0007] The present application provides a communication method and apparatus that can reduce the power consumption of a terminal device supporting multiple DC applications while enabling DC applications to flexibly send and receive messages and notifications.

[0008] To achieve the above objectives, this application adopts the following technical solutions:

[0009] In a first aspect, a communication method is provided. The method can be executed by a push server, or by a component of the push server, such as a processor, chip, or chip system of the push server, or by a logic module or software that can implement all or part of the push server. The method includes: in the process of a terminal device registering with an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message, the push server receives a first push message from a server of a DC application, and triggers a first SIP message based on the first push message. The first push message is used to request the sending of a push notification to the DC application on the terminal device, and the first SIP message is used to send the push notification to the DC application.

[0010] Based on this communication method, the push server can reuse the existing SIP long connection established based on the call, and send push messages to DC applications in the closed state or tombstone state through SIP messages. There is no need to add a system-level long connection to implement message push. This not only reduces the complexity of terminal device connections, thereby reducing the power consumption of terminal devices, but also enables DC applications to send and receive messages or notifications in a timely and flexible manner.

[0011] In one possible design, before the push server receives the first push message from the server of the data channel DC application, the method described in the first aspect may also include: the push server receives a first registration message. The first registration message is used to request registration of the push notification service of the DC application. The push server sends a registration response corresponding to the first registration message. Thus, the registration of the push notification service of the DC application is completed on the push server, so that the above-mentioned push notification service can be implemented based on the registration.

[0012] In a possible design solution, the first registration message may include an identifier of the terminal device and an identifier of the DC application.

[0013] In one possible design, the terminal device identifier and the DC application identifier are integrity-protected and carried in the first registration message. Thus, by integrity-protecting the push service registration request information, information security can be ensured. For example, integrity protection can be implemented using a JWT.

[0014] In one possible design, the registration response may include push registration information, which includes the terminal device identifier, the DC application identifier, a token, and / or the token's expiration date. The token is used to authenticate push notifications. The push server then returns the push registration information for subsequent push service initiation.

[0015] In one possible design, the push server triggering the first SIP message based on the first push message may include: the push server authenticating the first push message based on the push registration information. If the first push message is authenticated, the push server triggers the first SIP message based on the first push message. To ensure message reliability, the push server may authenticate the received first push message based on the stored push registration information.

[0016] In one possible design, the registration response may also include the push server's location information, which can be used by the DC application's server to subsequently determine the push server to initiate push notifications. In some scenarios, the push server's location information may be pre-configured on the DC application's server. In this case, the registration response may not include the push server's location information, eliminating the need for the terminal device to obtain the push server's location information from the registration response and then report it to the DC application's server.

[0017] In one possible design, the location information of the push server can be integrity-protected and carried in the registration response to ensure the security of the information. For example, the integrity protection can be implemented using a JWT.

[0018] In one possible design, the push server may be an IMS application server (AS), and the first registration message may be a second SIP message. In this design, the push server may receive the first registration message from the serving-call session control function (S-CSCF). After receiving the first push message, the push server may directly reuse the SIP connection to initiate a push notification to the DC application using a SIP message.

[0019] In one possible design, the push server is deployed on the Data Channel Signaling Function (DCSF). The process of registering a terminal device with the IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message may also include: the push server receiving a second registration message from the IMS AS. The second registration message is used to instruct the terminal device to register with the IMS AS. Thus, in the IMSDC architecture, during the IMS network registration process for a DC-enabled terminal device, the push server can determine which IMS AS the terminal device is registered with, facilitating subsequent push registration and push notification initiation.

[0020] In one possible design, the push server triggering the first SIP message based on the first push message may include: the push server sending a second push message to the IMS AS based on the first push message. The second push message is used to request that the first SIP message be sent to the DC application. In this design, the push server may receive the first registration message from the IMS AS. At this time, the push server triggers the IMS AS to reuse the SIP connection and initiate a push notification to the DC application using a SIP message.

[0021] In a possible design solution, the second push message may include the identifier of the terminal device, the identifier of the DC application, and the push notification.

[0022] In one possible design solution, the second push message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0023] In a possible design solution, the first push message and the first SIP message may include an identifier of the terminal device, an identifier of the DC application, and a push notification.

[0024] In a possible design solution, the first push message and the first SIP message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0025] In a possible design solution, the first push message, the first registration message, and the second registration message may be Hypertext Transfer Protocol (HTTP) messages.

[0026] In one possible design, one or more of the terminal device identifier, DC application identifier, token, token expiration time, and push notification can be integrity protected and carried in the first SIP message to ensure information security.

[0027] In one possible design, integrity protection can be in the form of JWT.

[0028] A second aspect provides a communication method. The method can be executed by a terminal device, or by a component of the terminal device, such as a processor, chip, or chip system of the terminal device, or by a logic module or software that implements all or part of the terminal device. In the case of a process in which a terminal device registers with an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message, the method includes: the terminal device receives a first SIP message, and executes a DC application push based on the first SIP message. The first SIP message is used to send a push notification to the DC application on the terminal device.

[0029] Based on this communication method, the terminal device receives the first SIP message on the basis of the existing SIP long connection established based on the call, wakes up and pulls up the DC application in the closed state or tombstone state according to the first SIP message to send a push message. There is no need to add a system-level long connection to implement message push. This not only reduces the complexity of the terminal device connection, thereby reducing the power consumption of the terminal device, but also enables the DC application to send and receive messages or notifications in a timely and flexible manner.

[0030] In a possible design scheme, the method described in the second aspect may also include: the terminal device sends a second SIP message, wherein the second SIP message is used to request registration of the push notification service of the DC application. The terminal device receives a third SIP message, wherein the third SIP message is used to indicate the completion of registration of the push notification service of the DC application, and the third SIP message includes push registration information. The terminal device sends a first notification message, wherein the first notification message is used to notify the server of the DC application to push registration information. Thus, the terminal device can also reuse the existing SIP long connection established based on the call to initiate the push registration process through the second SIP message, and obtain the push registration information through the third SIP message, so as to realize the push service with low power consumption.

[0031] In one possible design, the terminal device sending the first notification message may include: establishing a DC bearer channel between the terminal device and a DC application server. The terminal device sends the first notification message via the DC bearer channel. Thus, after obtaining the push registration information, the terminal device may establish a DC bearer channel with the DC application server and send the push registration information to the DC application server, so that the DC application server can subsequently initiate push notifications.

[0032] In a possible design solution, the second SIP message may include an identifier of the terminal device and an identifier of the DC application.

[0033] In a possible design solution, the identifier of the terminal device and the identifier of the DC application may be integrity protected and then carried in the second SIP message.

[0034] In a possible design solution, the push registration information may include the identifier of the terminal device, the identifier of the DC application, the token and / or the expiration time of the token, and the push token is used to authenticate the push notification.

[0035] In a possible design solution, the push registration information may be integrity protected and then carried in a third SIP message.

[0036] In one possible design solution, the third SIP message may further include location information of the push server.

[0037] In a possible design solution, the location information of the push server may also be integrity protected and carried in the third SIP message.

[0038] In a possible design solution, the push server may be an IMS application server AS or deployed on a data channel signaling function DCSF.

[0039] In a possible design solution, the first SIP message may include an identifier of the terminal device, an identifier of the DC application, and a push notification.

[0040] In a possible design solution, the first SIP message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0041] In a possible design solution, one or more of the terminal device identifier, DC application identifier, token, token expiration time, and push notification may be integrity protected and carried in the first SIP message.

[0042] In one possible design, integrity protection can be in the form of JWT.

[0043] On the third aspect, a communication method is provided, which can be executed by a server of a DC application, or by a component of a server of a DC application, such as a processor, chip, or chip system of a server of a DC application, or can be implemented by a logic module or software that can implement all or part of a server of a DC application. In the case of a process in which a terminal device registers to an IP Multimedia Subsystem IMS network based on a Session Initiation Protocol SIP message, the method includes: the server of the data channel DC application obtains a first notification message, and the first notification message is used to notify the server of the DC application to push registration information. In the case where a push needs to be initiated to the DC application, the server of the DC application sends a first push message to the push server according to the push registration information. The first push message is used to send a push notification to the DC application on the terminal device.

[0044] Based on this communication method, when it is necessary to initiate a push to the DC application on the terminal device, the server of the DC application can send a first push message according to the push registration information of the DC application, so as to trigger the push service through the first push message. On the basis of the existing SIP long connection established based on the call, the SIP long connection is reused, and push messages are sent to the DC application in the closed state or tombstone state through the SIP message, thereby reducing the power consumption of the terminal device, and enabling the DC application to send and receive messages or notifications in a timely and flexible manner.

[0045] In one possible design, the need to initiate a push to the DC application may include: the DC application server does not receive a response from the DC application within a preset time. In other words, if the DC application server sends a message to the DC application but does not receive a response from the DC application within a preset time, the DC application server may initiate a push to the DC application.

[0046] In a possible design solution, the DC application server obtaining the first notification message may include: the DC application server establishing a DC bearer channel with the terminal device, and the DC application server receiving the first notification message through the DC bearer channel.

[0047] In a possible design solution, the push registration information may include the identifier of the terminal device, the identifier of the DC application, a token and / or the expiration time of the token, and the token is used to authenticate the push notification.

[0048] In one possible design solution, the first notification message may further include location information of the push server.

[0049] In a possible design solution, the first push message may include the identifier of the terminal device, the identifier of the DC application, and the push notification.

[0050] In a possible design solution, the first push message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0051] In a possible design solution, the first notification message may be a Hypertext Transfer Protocol (HTTP) message.

[0052] In one possible design solution, the first push message may be an HTTP message.

[0053] Among them, the description of the technical effects of the method described in the second aspect or the third aspect can refer to the description of the technical effects of the method described in the first aspect, and will not be repeated here.

[0054] In a fourth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the push server described in the first aspect, or a device comprising the push server, or a device contained in the push server, such as a chip. The communication device includes corresponding modules, units, or means for implementing the method described in the first aspect. The modules, units, or means may be implemented by hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0055] In some possible designs, the communication device includes a processing module and a transceiver module. Specifically, when a terminal device registers with an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message, the transceiver module is configured to receive a first push message from a server of a DC application. The processing module is configured to trigger a first SIP message based on the first push message. The first push message is configured to request a push notification to be sent to a DC application on the terminal device, and the first SIP message is configured to send the push notification to the DC application.

[0056] In one possible design, before the transceiver module receives a first push message from a server of a data channel DC application, the transceiver module is further configured to receive a first registration message. The first registration message is used to request registration for the DC application's push notification service. The transceiver module is further configured to send a registration response corresponding to the first registration message.

[0057] In a possible design solution, the first registration message may include an identifier of the terminal device and an identifier of the DC application.

[0058] In one possible design scheme, the identifier of the terminal device and the identifier of the DC application are carried in the first registration message after being integrity protected.

[0059] In one possible design, the registration response may include push registration information, which includes the identifier of the terminal device, the identifier of the DC application, the token and / or the expiration time of the token, and the token is used to authenticate the push notification.

[0060] In one possible design, a processing module configured to trigger a first SIP message based on a first push message specifically includes: a processing module configured to authenticate the first push message based on push registration information; and, if the first push message is authenticated, the processing module further configured to trigger the first SIP message based on the first push message.

[0061] In one possible design solution, the registration response may further include location information of the push server.

[0062] In one possible design, the location information of the push server may be integrity protected and carried in the registration response.

[0063] In a possible design solution, the push server may be an IMS application server AS, and the first registration message may be a second SIP message.

[0064] In one possible design, the push server is deployed on the Data Channel Signaling Function (DCSF). The process of registering a terminal device with the IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message may further include: the push server receiving a second registration message from the IMS AS. The second registration message is used to instruct the terminal device to register with the IMS AS.

[0065] In one possible design, the processing module is configured to trigger the first SIP message based on the first push message, and specifically includes: a processing module configured to control the transceiver module to send a second push message to the IMSAS based on the first push message, wherein the second push message is used to request that the first SIP message be sent to the DC application.

[0066] In a possible design solution, the second push message may include the identifier of the terminal device, the identifier of the DC application, and the push notification.

[0067] In one possible design solution, the second push message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0068] In a possible design solution, the first push message and the first SIP message may include an identifier of the terminal device, an identifier of the DC application, and a push notification.

[0069] In a possible design solution, the first push message and the first SIP message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0070] In a possible design solution, the first push message, the first registration message, and the second registration message may be Hypertext Transfer Protocol (HTTP) messages.

[0071] In a possible design solution, one or more of the terminal device identifier, DC application identifier, token, token expiration time, and push notification may be integrity protected and carried in the first SIP message.

[0072] In one possible design, integrity protection can be in the form of JWT.

[0073] In one possible design solution, the transceiver module may include a receiving module and a sending module, wherein the sending module is used to implement the sending function of the communication device described in the fourth aspect, and the receiving module is used to implement the receiving function of the communication device described in the fourth aspect.

[0074] In one possible design solution, the communication device described in the fourth aspect may further include a storage module, wherein the storage module stores a program or instruction. When the processing module executes the program or instruction, the communication device described in the fourth aspect may execute the method described in the first aspect.

[0075] In a fifth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the terminal device described in the second aspect, or a device including the terminal device, or a device included in the terminal device, such as a chip. The communication device includes corresponding modules, units, or means for implementing the method described in the second aspect. The modules, units, or means may be implemented in hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0076] In some possible designs, the communication device includes a processing module and a transceiver module. Specifically, when a terminal device registers with an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message, the transceiver module is configured to receive a first SIP message. The processing module is configured to execute a DC application push based on the first SIP message. The first SIP message is used to send a push notification to a DC application on the terminal device.

[0077] In one possible design, the transceiver module is further configured to send a second SIP message, wherein the second SIP message is used to request registration for the DC application's push notification service. The transceiver module is further configured to receive a third SIP message, wherein the third SIP message is used to indicate completion of registration for the DC application's push notification service, and the third SIP message includes push registration information. The transceiver module is further configured to send a first notification message, wherein the first notification message is used to notify the DC application's server of the push registration information.

[0078] In one possible design, the transceiver module is further configured to send the first notification message, specifically including: the transceiver module is further configured to establish a DC bearer channel with a DC application server under the control of the processing module. The transceiver module is further configured to send the first notification message via the DC bearer channel.

[0079] In a possible design solution, the second SIP message may include an identifier of the terminal device and an identifier of the DC application.

[0080] In a possible design solution, the identifier of the terminal device and the identifier of the DC application may be integrity protected and then carried in the second SIP message.

[0081] In a possible design solution, the push registration information may include the identifier of the terminal device, the identifier of the DC application, the token and / or the expiration time of the token, and the push token is used to authenticate the push notification.

[0082] In a possible design solution, the push registration information may be integrity protected and then carried in a third SIP message.

[0083] In one possible design solution, the third SIP message may further include location information of the push server.

[0084] In a possible design solution, the location information of the push server may also be integrity protected and carried in the third SIP message.

[0085] In a possible design solution, the push server may be an IMS application server AS or deployed on a data channel signaling function DCSF.

[0086] In a possible design solution, the first SIP message may include an identifier of the terminal device, an identifier of the DC application, and a push notification.

[0087] In a possible design solution, the first SIP message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0088] In a possible design solution, one or more of the terminal device identifier, DC application identifier, token, token expiration time, and push notification may be integrity protected and carried in the first SIP message.

[0089] In one possible design, integrity protection can be in the form of JWT.

[0090] In one possible design solution, the transceiver module may include a receiving module and a sending module, wherein the sending module is used to implement the sending function of the communication device described in the fifth aspect, and the receiving module is used to implement the receiving function of the communication device described in the fifth aspect.

[0091] In one possible design solution, the communication device described in the fifth aspect may further include a storage module, wherein the storage module stores a program or instruction. When the processing module executes the program or instruction, the communication device described in the fifth aspect may execute the method described in the second aspect.

[0092] In a sixth aspect, a communication device is provided for implementing the various methods described above. The communication device may be the server for the DC application described in the third aspect, or a device comprising the server for the DC application, or a device, such as a chip, included in the server for the DC application. The communication device includes corresponding modules, units, or means for implementing the method described in the third aspect. The modules, units, or means may be implemented in hardware, software, or by executing corresponding software implementations in hardware. The hardware or software includes one or more modules or units corresponding to the above functions.

[0093] In some possible designs, the communication device includes: a processing module and a transceiver module. Specifically, in the case of a process in which a terminal device registers with an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message, the processing module is configured to obtain a first notification message, which is used to notify a server of a data channel (DC) application to push registration information. In the case of a need to initiate a push to the DC application, the transceiver module is configured to send a first push message to the push server based on the push registration information. The first push message is used to send a push notification to the DC application on the terminal device.

[0094] In a possible design solution, it is necessary to initiate a push to the DC application, which may include: the DC application server does not receive a response from the DC application within a preset time.

[0095] In one possible design, the processing module, configured to obtain the first notification message, specifically includes: a processing module, configured to establish a DC bearer channel with the terminal device; and a processing module, configured to control the transceiver module to receive the first notification message through the DC bearer channel.

[0096] In a possible design solution, the push registration information may include the identifier of the terminal device, the identifier of the DC application, a token and / or the expiration time of the token, and the token is used to authenticate the push notification.

[0097] In one possible design solution, the first notification message may further include location information of the push server.

[0098] In a possible design solution, the first push message may include the identifier of the terminal device, the identifier of the DC application, and the push notification.

[0099] In a possible design solution, the first push message may further include a token and / or an expiration time of the token, where the token is used to authenticate the push notification.

[0100] In a possible design solution, the first notification message may be a Hypertext Transfer Protocol (HTTP) message.

[0101] In one possible design solution, the first push message may be an HTTP message.

[0102] In one possible design solution, the transceiver module may include a receiving module and a sending module, wherein the sending module is used to implement the sending function of the communication device described in the sixth aspect, and the receiving module is used to implement the receiving function of the communication device described in the sixth aspect.

[0103] In one possible design solution, the communication device described in the sixth aspect may further include a storage module, wherein the storage module stores a program or instruction. When the processing module executes the program or instruction, the communication device described in the sixth aspect may execute the method described in the third aspect.

[0104] In a seventh aspect, a communication device (for example, the communication device may be a chip or a chip system) is provided. The communication device includes: a processor configured to implement the functions involved in the first aspect, the second aspect, or the third aspect.

[0105] In one possible design, the communication device may further include a memory for storing necessary program instructions and data. A processor is coupled to the memory, and the processor is configured to execute the computer program or instructions stored in the memory, causing the communication device to perform the method described in the first, second, or third aspects.

[0106] In one possible design solution, the communication device described in the seventh aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used for the communication device described in the seventh aspect to communicate with other communication devices.

[0107] In one possible design, the processor can be integrated with the memory.

[0108] In some possible designs, when the device is a chip system, it can be composed of a chip or include a chip and other discrete devices.

[0109] In an eighth aspect, a communication device is provided, which includes a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or to send signals from the processor to other communication devices outside the communication device, and the processor being used to implement the method described in the first aspect, the second aspect, or the third aspect through a logic circuit or executing code instructions.

[0110] In the ninth aspect, a communication device is provided. The communication device can be a push server, or a module or unit (for example, a chip, or a chip system, or a circuit) in the push server that corresponds to the method / operation / step / action described in the first aspect, or can be used in combination with a push server. Alternatively, the communication device can be a terminal device, or a module or unit (for example, a chip, or a chip system, or a circuit) in the terminal device that corresponds to the method / operation / step / action described in the second aspect, or can be used in combination with a terminal device. Alternatively, the communication device can be a server for a DC application, or a module or unit (for example, a chip, or a chip system, or a circuit) in the server for a DC application that corresponds to the method / operation / step / action described in the third aspect, or can be used in combination with a server for a DC application.

[0111] It can be understood that when the communication device provided in any one of the seventh aspect or the ninth aspect is a chip, the above-mentioned sending action / function can be understood as output, and the above-mentioned receiving action / function can be understood as input.

[0112] In the tenth aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer-readable storage medium is run on a communication device, the communication device can execute the method described in the first aspect, the second aspect, or the third aspect.

[0113] In the eleventh aspect, a computer program product containing instructions is provided, including computer program code, which, when the computer program code runs on a communication device, enables the communication device to execute the method described in the first aspect, the second aspect, or the third aspect above.

[0114] In the twelfth aspect, a communication system is provided, comprising: a communication device for implementing the method described in the first aspect above, a communication device for implementing the method described in the second aspect above, and a communication device for implementing the method described in the third aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0115] Figure 1 is a framework diagram of a DC workflow;

[0116] FIG2 is a schematic diagram of an IMSDC architecture;

[0117] FIG3 is a schematic diagram of a basic IMS registration process;

[0118] FIG4 is a schematic diagram of a third-party registration process;

[0119] FIG5 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0120] FIG6 is a schematic diagram of an architecture of a terminal device supporting DC applications provided by an embodiment of the present application;

[0121] FIG7 is a flow chart of a communication method provided in an embodiment of the present application;

[0122] FIG8 is a flow chart of another communication method provided in an embodiment of the present application;

[0123] FIG9 is a flow chart of another communication method provided in an embodiment of the present application;

[0124] FIG10 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0125] FIG11 is a schematic structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0126] The embodiments of the present application will present various aspects, embodiments, or features around a system that may include multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Furthermore, combinations of these solutions may also be used.

[0127] The technical solutions of the embodiments of the present application can be applied to various communication systems, such as wireless fidelity (Wi-Fi) systems, vehicle-to-everything (V2X) communication systems, device-to-device (D2D) communication systems, Internet of Vehicles communication systems, world-wide interoperability for microwave access (WiMAX) communication systems, 4th generation (4G) mobile communication systems, such as long term evolution (LTE) systems, world-wide interoperability for microwave access (WiMAX) communication systems, 5G mobile communication systems, such as new radio (NR) systems, and future communication systems, such as sixth generation (6G) mobile communication systems.

[0128] For ease of understanding, the technical terms involved in the embodiments of this application are first introduced below.

[0129] 1. DC

[0130] 3GPP Release 16 defines a framework diagram for the DC workflow. For the data channel network function, it only defines the data channel server functionality, the data channel application repository (DCAR), and the conceptual process of their interaction with user equipment (UE). However, the relationship between DC and the IMS network is not clearly defined. As shown in Figure 1, DC-related applications are uploaded to the network by the UE's authorized party and stored in the DCAR. During a call, DC-related applications are downloaded from the DCAR. DC-related applications are sent to the local UE via the bootstrap DC. DC-related applications are sent to the remote UE via the bootstrap data channel. Other data channels used by DC-related applications can be established between the local and remote UEs.

[0131] Furthermore, in R18, a microservices-based interface (SBA) architecture is used to interconnect with the IMS network. Furthermore, R18 stipulates that the establishment of a DC is related to an IMS multimedia telephony (MMTel) session. A DC is a newly added DC based on the existing video, audio, and signaling channels between the terminal device and the IMS, forming an IMSDC architecture for an enhanced voice call service based on the 5G network, namely 5G New Calling. 5G New Calling provides more features around traditional voice call services, such as intelligent translation, fun calls, intelligent customer service, content sharing, and remote assistance.

[0132] In addition, standalone DC (SADC) is proposed in R19. SADC will greatly increase the scenarios in which multiple DC applications run in parallel, and can enable multiple DC applications to run in parallel without relying on calls.

[0133] 2. IMSDC Architecture

[0134] IMS is a core technology for network communications and a new form of multimedia service. It can meet the needs of terminal devices for newer and more diverse multimedia services. It is an important way to achieve the convergence of mobile and fixed networks and introduce differentiated services such as triple-convergence of voice, data, and video.

[0135] The IMSDC architecture is an IMS architecture that supports DC applications and can synchronously transmit any multimedia and data information, such as audio, video, images, text, hypertext markup language 5 (H5), location, expression, action, augmented reality (AR), virtual reality (VR), etc.

[0136] As shown in Figure 2, unlike the traditional IMS architecture, the IMSDC architecture adds a data channel signaling function (DCSF) and a media function (MF), and uses the SBA architecture to interoperate with the IMS network to support DC applications.

[0137] Among them, the UE communicates with the proxy-call session control function (P-CSCF) through the Gm interface (Gm for short); the P-CSCF communicates with the serving-call session control function (S-CSCF) through the Mw interface (Mw for short); the P-CSCF communicates with the IMS access gateway (IMS-AGW) through the Iq interface (Iq for short); the IMS-AGW communicates with the remote IMS and MF respectively through the Mb interface (Mb for short); the S-CSCF communicates with the home subscriber server (HSS) through the N70 / Cx interface (N70 / Cx for short); the S-CSCF communicates with the IMS application server (AS) through the ISC interface (ISC for short); the IMS AS communicates with the HSS interface through the N71 / Sh interface (N71 / Sh for short); the IMS AS communicates with the DCSF through the DC1 interface (DC1 for short); IMS The AS communicates with the MF via the DC2 interface (DC2 for short); the DCSF communicates with the network exposure function (NEF) via the DC3 interface (DC3 for short); the DCSF communicates with the data channel application server (DCAS) via the DC4 interface or the MDC3 interface (DC3 or MDC3 for short); the DCSF communicates with the DCAR via the DC5 interface (DC5 for short); the DCSF communicates with the MF via the MDC1 interface (MDC1 for short); the MF communicates with the DCAS via the MDC2 interface (MDC2 for short); and the HSS communicates with the DCSF via the N72 / Sc interface (N72 / Sc for short). Furthermore, the IMS AS, DCSF, MF, or NEF functions shown in Figure 2 interact using service-based interfaces. For example, the service-based interface provided by the IMS AS is Nimsas; the service-based interface provided by the DCSF is Ndcsf; the service-based interface provided by the NEF is Nnef; and the service-based interface provided by the MF is Nmf.

[0138] The functions of each network element in the IMSDC architecture are as follows:

[0139] P-CSCF: It is the entry point for Session Initiation Protocol (SIP) users to access the IMS network and is mainly responsible for forwarding SIP signaling between SIP users and the home network.

[0140] S-CSCF: It is the central node of the IMS network and is responsible for user registration, authentication, session, routing, and service triggering.

[0141] IMS-AGW: It is the IMS access gateway, responsible for media plane intercommunication between user and network interfaces.

[0142] HSS: It is the main database for IMS user contracts. It is responsible for managing user contract data and mobile user location information, and is responsible for storing the following key user-related contract information: user identity (ID), such as IMS private identity (IMPI) and IMS public identity (IMPU); user authentication-related information; S-CSCF information where the user is registered; and transparent data stored by the AS in the HSS, such as the UE's call forwarding number.

[0143] IMS AS: Generally refers to the server network element in the IMS network that processes upper-layer voice services, including basic audio and video services and supplementary services. Specifically, the AS may include MMTelAS (for processing basic audio and video services and supplementary services) and / or Service Centralization and Continuity (SCC) AS (responsible for signaling control and called access domain selection for enhanced single radio voice call continuity (eSRVCC)). These two ASs can be set up independently or together.

[0144] DCSF: A signaling control function that provides data channel control logic. The DCSF supports the following functions: receiving event reports from the IMS AS and deciding whether to allow data channel services during an IMS session; managing the bootstrapping data channel and (if applicable) application data channel resources at the MF or MRF via the IMS AS; supporting the Hypertext Transfer Protocol (HTTP) web server function to download data channel applications (bootstrapping) to the UE via the MF and / or media resource function (MRF) based on UE subscription; and downloading data channel applications from the data channel application repository.

[0145] MF: Provides media resource management and forwarding of data channel media services. The MF supports the following functions: managing data channel media resources (both bootstrap and application data channel resources, if applicable) under the control of the IMS AS; terminating the bootstrap data channel from the UE and forwarding HTTP services between the UE and the DCSF via MDC1; anchoring the application data channel in a P2P scenario if necessary and forwarding application data services from the UE to the UE; and relaying services on the application to person (A2P) / person to application (P2A) application data channel between the UE and the DC application server via MDC2.

[0146] NEF: Mainly used to support the opening of capabilities and events.

[0147] DCAS: Mainly used to provide DC-related application services.

[0148] In the embodiment of the present application, the P-CSCF may also be referred to as a P-CSCF entity or a P-CSCF network element; the S-CSCF may also be referred to as an S-CSCF entity or an S-CSCF network element, without limitation.

[0149] 3. IMS basic registration process (also known as IMS initial registration process)

[0150] The IMS basic registration process is initiated by the UE. From the time the UE initiates IMS basic registration upon power-on until IMS basic registration is successful, the user has basic call rights.

[0151] FIG3 is a flow chart of the basic IMS registration process. As shown in FIG3 , the basic IMS registration process is as follows:

[0152] S301: UE sends a SIP register message to P-CSCF. Correspondingly, P-CSCF receives the SIP register message from UE.

[0153] The SIP register message can be used by the UE to request registration to the IMS network. The SIP register message mainly includes at least one of the following header fields: request address (request-URI), To, Contact, or Via.

[0154] The request address may be a component of a request line in a SIP register message, and is used to indicate the destination of the request, that is, the address of the registrar. An example is sip:c8.huawei.com.

[0155] To can be used to register the user's public identity identifier (IMPU). It should be noted that the maximum length of the IMPU supported by the CSCF is 127 characters. For example, if the user successfully registers, the registrar can obtain the public user identity (sip:+8675520000001@c8.huawei.com).

[0156] Contact can be used as the contact address of the registered user. Contact and To can be used together. If the registration is successful, the registrar can route all subsequent request messages sent to the registered user to this address.

[0157] Via can be used to save the path that the request has taken so that the response can be returned according to the requested path.

[0158] The UE can obtain the IP address of the P-CSCF in the following ways:

[0159] Method 1: The UE obtains the P-CSCF domain name and domain name system (DNS) server address through the Dynamic Host Configuration Protocol (DHCP), and then queries the DNS server to obtain the IP address corresponding to the P-CSCF domain name.

[0160] Method 2: The P-CSCF domain name is directly configured on the UE, and then the DNS server address is obtained through DHCP. The DNS server is queried to obtain the IP address corresponding to the P-CSCF domain name.

[0161] Method 3: Directly configure the IP address of the P-CSCF on the UE.

[0162] Method 4: For UEs centrally managed by the network management system, the IP address of the P-CSCF can be configured through the web portal.

[0163] S302: The P-CSCF sends a SIP registration message to an interrogating-call session control function (I-CSCF). Correspondingly, the I-CSCF receives the SIP registration message from the P-CSCF.

[0164] The P-CSCF can query the DNS server according to the domain name in the Request-URI header field, obtain the home domain network entry I-CSCF address, and forward the SIP registration message to the I-CSCF.

[0165] When the P-CSCF forwards the SIP registration message, it adds the following header fields to the SIP registration message:

[0166] Path: The P-CSCF inserts this header into the SIP registration message and puts its own address into it to pass it to the registrar.

[0167] P-Visited-Network-ID: When the P-CSCF queries the local PACN table, it prioritizes the local network ID from this data table and fills it in the P-Visited-Network-ID field. If the local network ID is not available, the P-Visited-Network-ID header field is filled with the local network ID to identify the user's current visited network information to the registering user's home network. The P-CSCF inserts this header into the SIP register message to convey the visited network ID to the registrar.

[0168] P-Charging-Vector: The P-CSCF inserts this header into the SIP registration message and places the charging identifier in it to complete the transmission of charging point information on the network.

[0169] P-Access-Network-Info: The P-CSCF inserts this header into the SIP registration message to provide the access network information to the IMS network.

[0170] S303: The I-CSCF sends a user authorization request (UAR) message to the HSS. Correspondingly, the HSS receives the UAR message from the I-CSCF.

[0171] Upon receiving the SIP REGISTER message, the I-CSCF first obtains the P-CSCF address or host name from Via and checks whether the address or host name is in the Trusted Domain Manager (TDMI) or Local Domain Manager (LDMI). If a record is found, the user's visited network is trusted, and the I-CSCF allows the user to register. If no record is found, the user's visited network is untrusted, and the I-CSCF directly returns a SIP response code 403, indicating "Request From Untrusted Domain," rejecting the user's registration request.

[0172] After the I-CSCF determines that the user's visited network is trustworthy, it selects the HSS with the highest priority based on the "Priority" parameter setting in the local IHSS (Peer HSS for I-CSCF) table; it then queries the IHSSL (Link Between I-CSCF and Peer HSS) table to obtain the IP address of the HSS network element, and sends a UAR message to the HSS to request the address of the S-CSCF.

[0173] S304: The HSS sends a user authorization answer (UAA) message to the I-CSCF. Correspondingly, the I-CSCF receives the UAA message from the HSS.

[0174] After receiving the UAR message, the HSS determines that the user has opened an account based on the user account opening information in the local database, and then sends a UAA message to the I-CSCF, returning the address or capability set of the S-CSCF.

[0175] S305: The I-CSCF sends a SIP registration message to the S-CSCF. Correspondingly, the S-CSCF receives the SIP registration message from the I-CSCF.

[0176] The I-CSCF selects an appropriate S-CSCF based on the result returned by the HSS and forwards the SIP REGISTER message to the S-CSCF. If the HSS returns an S-CSCF capability set, the I-CSCF queries the ISCAP (S-CSCF Capabilities for I-CSCF) table, selects an S-CSCF that meets the capability set requirements, and forwards the SIP REGISTER message to the S-CSCF. The S-CSCF capability set attribute value pair (AVP) contains the S-CSCF address, and the I-CSCF directly forwards the SIP REGISTER message to the S-CSCF.

[0177] S306: The S-CSCF sends a multimedia authentication request (MAR) message to the HSS. Correspondingly, the HSS receives the MAR message from the S-CSCF.

[0178] The MAR message requests to obtain the authentication vector (AV) and notifies the HSS that the current S-CSCF serves the user. The AVP in the MAR message is basically the same as that in the UAR message.

[0179] S307: The HSS sends a multimedia authentication answer (MAA) message to the S-CSCF. Correspondingly, the S-CSCF receives the MAA message from the HSS.

[0180] The MAA message includes the authentication quintuple: the expected response (XRES), random number (RAND), authentication token (AUTN), integrity key (IK), and cipher key (CK). The AVPs in the MAA message and the UAA message are essentially the same and are not included here.

[0181] S308: The S-CSCF sends a response message to the SIP register message to the I-CSCF. Correspondingly, the I-CSCF receives the response message to the SIP register message from the S-CSCF.

[0182] The S-CSCF saves the parameter XRES for subsequent verification of the user's authentication response. Other authentication elements are returned to the P-CSCF along with the response message.

[0183] S309: The I-CSCF sends a response message of the SIP registration message to the P-CSCF. Correspondingly, the P-CSCF receives the response message of the SIP registration message from the I-CSCF.

[0184] S310: The P-CSCF sends a response message to the SIP registration message to the UE. Correspondingly, the UE receives the response message to the SIP registration message from the P-CSCF.

[0185] The P-CSCF takes out the IK and CK from the response message and saves them, and forwards the remaining authentication elements RAND and AUTN in the message to the UE.

[0186] The response code of the response message of the SIP registration message in S308 to S310 may be 401, so the response message may also be called a SIP 401 message.

[0187] S311. The UE verifies the network.

[0188] S312: The UE sends a SIP registration message to the P-CSCF. Correspondingly, the P-CSCF receives the SIP registration message from the UE.

[0189] S313: The P-CSCF sends a SIP registration message to the I-CSCF. Correspondingly, the I-CSCF receives the SIP registration message from the P-CSCF.

[0190] S314, I-CSCF sends a UAR message to HSS. Correspondingly, HSS receives the UAR message from I-CSCF

[0191] S315: The HSS sends a UAA message to the I-CSCF. Correspondingly, the I-CSCF receives the UAA message from the HSS.

[0192] S316: The I-CSCF sends a SIP registration message to the S-CSCF. Correspondingly, the S-CSCF receives the SIP registration message from the I-CSCF.

[0193] In S311-S316 above, after receiving the SIP 401 message, the UE authenticates the AUTN using the shared key stored in its local IMS subscriber identity module (ISIM). Successful authentication indicates that the SIP 401 message originated from the user's actual home network. The RES (Response) is then calculated based on the shared key and RAND. A SIP REGISTER message is reconstructed, carrying the RES, and sent to the S-CSCF along the same path as the initial SIP REGISTER message.

[0194] S317: The network verifies the UE.

[0195] S318: The S-CSCF sends a server assignment request (SAR) message to the HSS. Correspondingly, the HSS receives the SAR message from the S-CSCF.

[0196] Upon receiving the authentication response, the S-CSCF compares the locally calculated XRES with the received authentication response RES. If the two match, the UE passes network authentication. After authentication, the S-CSCF sends a SAR message to the HSS, requesting the download of the user's subscription data.

[0197] S319: The HSS sends a server assignment answer (SAA) message to the S-CSCF. Correspondingly, the S-CSCF receives the SAA message from the HSS.

[0198] The SAA message carries the user's subscription data.

[0199] S320: The S-CSCF sends a response message to the SIP register message to the I-CSCF. Correspondingly, the I-CSCF receives the response message to the SIP register message from the S-CSCF.

[0200] S321: The I-CSCF sends a response message to the SIP register message to the P-CSCF. Correspondingly, the P-CSCF receives the response message to the SIP register message from the I-CSCF.

[0201] S322: The P-CSCF sends a response message to the SIP registration message to the UE. Correspondingly, the UE receives the response message to the SIP registration message from the P-CSCF.

[0202] The response code of the SIP registration message in steps S320 through S322 can be 200, and therefore this response message can also be referred to as a SIP 200 message. The S-CSCF returns a 200 (OK) response to the UE, indicating a successful registration. The message carries the key header field "service route," which contains the S-CSCF address. The P-CSCF stores the S-CSCF address for subsequent call routing. After successful registration, the relevant network elements store the information shown in Table 1 for subsequent message routing when the user is the calling or called party.

[0203] Table 1

[0204] As shown in Figure 3, the IMS registration process is initiated and completed by the terminal device based on SIP messages. Non-SIP message interactions may exist between network elements in the IMS network.

[0205] 4. Third-party registration process

[0206] After S320 in the IMS basic registration shown in Figure 3, the S-CSCF can initiate a third-party registration with the IMS AS on behalf of the UE. As shown in Figure 4, the third-party registration process includes:

[0207] S401: The S-CSCF sends a third-party registration request to the IMS AS. Correspondingly, the IMS AS receives the third-party registration request from the S-CSCF.

[0208] After the UE is authenticated successfully in S320 and a 200 (OK) response is returned, the S-CSCF determines whether the user's subscription information downloaded from the HSS contains initial filter criteria (iFC) data for third-party registration requests. The S-CSCF then sends the third-party registration request to the IMS AS based on the IMS AS address in the iFC. If the user's subscription information contains multiple iFC data items for third-party registration requests, the S-CSCF sends them to the IMS AS addresses in the iFCs in descending order of priority.

[0209] Among them, the third-party registration request mainly includes the following header fields:

[0210] Request-URI: IMSAS address.

[0211] From: The S-CSCF acts as a third party to register the user's public user identity, so the From message header contains the S-CSCF's address. The tag parameter in the From message is used to identify and distinguish a conversation.

[0212] To: is the public user identity that the user has registered.

[0213] Contact: The address of the S-CSCF to ensure that the IMS AS does not directly route to the user terminal UE, but always contacts the S-CSCF first.

[0214] S402: The IMS AS sends a user data request (UDR) message to the HSS. Correspondingly, the HSS receives the UDR message from the IMS AS.

[0215] The IMS AS finds that the user is registering for the first time and sends a UDR message to the HSS, requesting user data (including user identity data, service subscription data, etc.).

[0216] S403: The HSS sends a user data answer (UDA) message to the IMS AS. Correspondingly, the IMS AS receives the UDA message from the HSS.

[0217] The UDA message carries user data.

[0218] S404: IMSAS sends an SNR message to HSS. Correspondingly, HSS receives the SNR message from IMSAS.

[0219] S405: HSS sends an SNA message to IMSAS. Correspondingly, IMSAS receives the SNA message from HSS.

[0220] In response to the above S404 and S405, the IMS AS sends an SNR message to the HSS to request subscription to user data, and receives an SNA subscription success response message returned by the HSS.

[0221] S406: The IMS AS sends a 200 (OK) success response to the third-party registration request to the S-CSCF. Correspondingly, the S-CSCF receives a 200 (OK) success response to the third-party registration request from the IMS AS.

[0222] The IMS AS authenticates the user based on the received user data. After authentication, the IMS AS saves the user data to the local database and returns a 200 (OK) success response to the third-party registration request to the S-CSCF.

[0223] 5. IMS re-registration process

[0224] During the UE registration process, the UE and the network negotiate a re-registration period. The re-registration period is carried in the expires field of the SIP register message. This time range is defined by the "minimum registration duration" and "maximum registration duration" fields in the MOD SREG command on the CSC3300. During the re-registration period, the UE initiates a re-registration process. The UE's re-registration behavior is defined in Request for Comments (RFC) 3261 and 3GPP Technical Specification (TS) 24.229, and is not detailed here.

[0225] 6. Tombstone mechanism and push function

[0226] When an application (APP) on a terminal device enters the background, the system records the current application's status, much like recording an event on a tombstone. The system then terminates the application, releasing the resources it was using, including memory and the central processing unit (CPU). This prevents background applications from competing with foreground applications for these resources. When the application needs to return to the foreground, the program is restored to its pre-interruption state based on the contents of the tombstone. This mechanism is called the "tombstone mechanism."

[0227] For applications in the tombstone state, a push server can be configured to provide corresponding message push notifications. This push server maintains a system-level persistent connection with the terminal device's operating system. This system-level persistent connection cannot be canceled on the terminal device side. Once the connection is authorized, a connection is initiated to the push server. Thus, the application server can send push notifications to the push server, which then pushes them to the application on the terminal device through this system-level persistent connection.

[0228] The above describes the push mechanism for non-DC applications. For IMSDC applications, in scenarios that support multiple DC applications, if the above push mechanism for non-DC applications is not adopted, the terminal device needs to keep the DC application in the background all the time. Each DC application maintains a system-level long connection, and multiple DC applications correspond to multiple long connections in order to send push messages to the DC application. For DC applications that are in tombstone state or are closed in the background, the application server cannot connect to them and cannot send push messages, which will increase the power consumption cost of the terminal device to maintain the connection.

[0229] In addition, if the push mechanism of the above-mentioned non-DC application is adopted, since the terminal device maintains a SIP basic connection based on 4G high-definition call (voice over LTE, VoLTE) / 5G high-definition call (voice over NR, VoNR) / IMS by the coprocessor (CP) of the terminal device after it is turned on and registered with the IMS network, the connection will always be maintained regardless of whether the user turns on the traffic (it always maintains the signaling connection through IMS APN QCI / 5QI=5, no matter when and where). This will cause the terminal device to add a new long connection to the push server through the application processor (AP) at the SIP long connection level that needs to be maintained by the existing CP, which will also cause the power consumption of the terminal device to increase significantly.

[0230] Therefore, it can be seen that how to provide a low-power push mechanism for DC applications in the tombstone mechanism or closed state has become a technical problem that needs to be solved urgently. To this end, the embodiments of the present application provide a communication method and apparatus that can reduce the power consumption of terminal devices supporting multiple DC applications while enabling DC applications to freely send and receive messages and notifications.

[0231] In order to better understand the embodiments of the present application, the following explanations are made before introducing the embodiments of the present application.

[0232] First, in the embodiments of the present application, "used to indicate" can include being used for direct indication and being used for indirect indication. When describing a certain "indication information" as being used to indicate A, it can include the indication information directly indicating A or indirectly indicating A, and does not necessarily mean that the indication information carries A.

[0233] The information indicated by the indication information is called the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as but not limited to, directly indicating the information to be indicated, such as the information to be indicated itself or the index of the information to be indicated. The information to be indicated can also be indirectly indicated by indicating other information, wherein there is an association between the other information and the information to be indicated. It is also possible to indicate only a part of the information to be indicated, while the other parts of the information to be indicated are known or agreed in advance. For example, it is also possible to use the arrangement order of each piece of information agreed in advance (such as specified in the protocol) to achieve the indication of specific information, thereby reducing the indication overhead to a certain extent. At the same time, it is also possible to identify the common parts of each piece of information and indicate them uniformly to reduce the indication overhead caused by indicating the same information separately.

[0234] In addition, the specific indication method can also be various existing indication methods, such as but not limited to the above-mentioned indication methods and various combinations thereof. The specific details of the various indication methods can be referred to the prior art and will not be repeated herein. As can be seen from the above, for example, when it is necessary to indicate multiple information of the same type, there may be a situation where the indication methods for different information are different. In the specific implementation process, the required indication method can be selected according to specific needs. The embodiment of the present application does not limit the selected indication method. In this way, the indication method involved in the embodiment of the present application should be understood to cover various methods that can enable the party to be indicated to obtain the information to be indicated.

[0235] The information to be indicated can be sent as a whole, or divided into multiple sub-information and sent separately, and the sending period and / or sending time of these sub-information can be the same or different. The specific sending method is not limited in this application. Among them, the sending period and / or sending time of these sub-information can be predefined, for example, predefined according to the protocol, or configured by the transmitting device by sending configuration information to the receiving device. Among them, the configuration information can, for example, but not limited to, include one or a combination of at least two of radio resource control (RRC) signaling, media access control (MAC) layer signaling and physical layer signaling. Among them, MAC layer signaling, for example, includes MAC-control element (CE); physical (PHY) layer signaling, for example, includes downlink control information (DCI).

[0236] Second, in the embodiments of the present application, the first, second, and various numerical numbers are merely distinctions for ease of description and are not intended to limit the scope of the embodiments of the present application. For example, different indication information is distinguished. For another example, the first indication information and the second indication information are merely for distinguishing different indication information and do not limit their order. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit them to be different.

[0237] Third, in the embodiments of the present application, descriptions such as "when...", "in the case of...", "if" and "if" all mean that the device (such as a terminal device or an access network device) will make corresponding processing under certain objective circumstances. It does not limit the time, and does not require the device (such as a terminal device or an access network device) to have a judgment action when implementing it, nor does it mean that there are other limitations.

[0238] At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0239] Finally, the network architecture and business scenarios described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0240] Please refer to Figure 5, which is an architectural diagram of the communication system used in the embodiment of the present application. As an example, as shown in Figure 5, the communication system can be applied to the above-mentioned IMSDC architecture, and the communication system includes: a terminal device, a push server, and a DC application server, and the three can communicate with each other. Among them, the push server is a server that cooperates with the operator network and the IMS network to provide message notifications and application wake-up for the DC application server. It can be deployed as the IMS AS in the above-mentioned IMSDC architecture, or it can be deployed on the above-mentioned DCSF, and there is no limitation on this. The DC application server is an application server that provides corresponding DC application-related services, and can be the DCAS in the above-mentioned IMSDC architecture.

[0241] In the embodiments of the present application, the terminal device may be one or more, such as a first terminal device, a second terminal device, a third terminal device, etc. The terminal device may be a terminal device with transceiver functions, or may be a chip or chip system provided in the terminal device. The terminal device may also be referred to as a UE, an access terminal, a subscriber unit (subscriber unit), a user station, a mobile station (MS), a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user device. The terminal device in the embodiments of the present application can be a mobile phone, a cellular phone, a smart phone, a tablet computer, a wireless data card, a personal digital assistant (PDA), a wireless modem, a handheld device (handset), a laptop computer, a machine type communication (MTC) terminal, a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a smart home device (for example, a refrigerator, a television, an air conditioner, an electric meter, etc.), an intelligent robot, a robotic arm, a workshop equipment, a wireless terminal in unmanned driving, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, a vehicle-mounted terminal, a roadside unit with terminal function, a roadside control unit (ROU), ... The terminal device of the present application may also be an onboard module, onboard module, onboard component, onboard chip or onboard unit built into a vehicle as one or more components or units. The terminal device may also be other devices with terminal functions, for example, a terminal device may also be a device that functions as a terminal in D2D communication.

[0242] The embodiments of this application do not limit the device form factor of the terminal. The device used to implement the functions of the terminal device can be the terminal device; it can also be a device that supports the terminal device to implement the functions, such as a chip system. The device can be installed in the terminal device or used in conjunction with the terminal device. In the embodiments of this application, the chip system can be composed of chips or include chips and other discrete devices.

[0243] It should be understood that the communication system shown in FIG5 may also include other functional entities or network elements, other terminal devices or other access network devices, such as P-CSCF, S-CSCF, etc., without limitation thereto.

[0244] In addition, exemplarily, an embodiment of the present application also provides an architectural diagram of a terminal device supporting DC services. Based on this architecture, the terminal device can wake up or pull up the DC application to execute push services, send push registration requests, etc. The specific implementation process can be found in the relevant description in the following method embodiments, such as S704 and S700-1 to S700-2 below, which will not be repeated here.

[0245] As shown in Figure 6, the terminal device may include a SIP module, a DC module, a DC operating environment module and a DC application. The SIP module, the DC module and the DC operating environment module may be factory-preset modules for the terminal device, and the DC application may be downloaded and executed from the network side during the system operation of the terminal device.

[0246] Among them, the SIP module is responsible for real-time processing of SIP signaling and is usually implemented on a dedicated chip.

[0247] The DC module is a new function added to terminal devices after supporting DC. It is responsible for the implementation of the DC layered protocol stack, including the implementation of DC, stream control transmission protocol (SCTP), datagram transport layer security (DTLS), user datagram protocol (UDP) and other protocol stacks. Similar to the SIP module, it processes requests in real time after receiving them.

[0248] The DC runtime environment module, also known as the DC Framework module, is used for the lifecycle management of DC applications on the terminal device side (such as DC application switching, application background exit, multitasking, tombstone mechanism, etc.), and provides the upper-level DC with an application programming interface (API) for establishing DC.

[0249] A DC application corresponds to a DC application server and is an application developed by a developer. A DC application can also be called an IMSDC Web App, an IMSDC application, etc., without limitation.

[0250] In addition, the names of nodes, modules, devices or network elements in different scenarios or architectures or systems, as well as the names of communication interfaces between nodes, modules, devices or network elements are given as examples in the embodiments of the present application, and the possibility of name changes in future communication systems, scenarios or architectures is not excluded.

[0251] The communication method provided in the embodiment of the present application will be described in detail below with reference to Figures 7 to 9.

[0252] For example, FIG7 is a flow chart of a communication method provided in an embodiment of the present application. The communication method is illustrated by taking the communication between the terminal device, the push server and the DC application server shown in FIG5 as an example. Of course, the subject that executes the terminal device action in the method can also be a device / module in the terminal device, such as a chip, a processor, a processing unit, etc. in the terminal device; the subject that executes the push server action in the method can also be a device / module in the push server, such as a chip, a processor, a processing unit, etc. in the push server; the subject that executes the DC application server action in the method can also be a device / module in the DC application server, such as a chip, a processor, a processing unit, etc. in the DC application server; the embodiment of the present application does not make specific limitations on this.

[0253] The communication method provided in the embodiment of the present application is executed under the process of registering the terminal device to the IMS network based on the SIP message (hereinafter referred to as the IMS network registration process), or is executed after the IMS network registration process. The IMS network registration process includes the IMS initial registration of the terminal device and / or the IMS re-registration of the terminal device, wherein the IMS initial registration of the terminal device includes the registration interaction between the terminal device and the P-CSCF and the P-CSCF and the S-CSCF, and is the initial registration of the terminal device to the IMS initiated based on the SIP message. The IMS network registration process is a necessary step for IMS voice calls. During this registration process, the terminal device completes the authentication and authorization with the IMS network, so that in the subsequent process, the terminal device can initiate and receive calls and perform the next paging process. Please refer to the relevant description in the IMS basic registration process shown in Figure 3 above, which will not be repeated here. Furthermore, the initial IMS registration of the terminal device also includes registration between the S-CSCF and the IMS AS (third-party registration), which is used to clarify which IMS AS the terminal device is registered with, as described in the third-party registration process shown in FIG4 above, which will not be repeated here.

[0254] The IMS re-registration of the terminal device can be periodic. The terminal device refreshes and maintains the connection with the network by periodically registering with the IMS network. The IMS re-registration process can refer to the re-registration process defined in RFC3261 and 3GPP TS24.229, which will not be described in detail.

[0255] In one possible scenario, the push server is deployed on the DCSF. After the registration between the S-CSCF and the IMS AS, the IMS network registration process also includes the registration between the IMS AS and the DCSF. That is, the IMS AS can send a third-party registration notification to the push server (DCSF) based on the default user contract to indicate which IMS AS the terminal device is registered on. Exemplarily, the IMS AS sends a second registration message to the push server. Correspondingly, the push server receives the second registration message from the IMS AS. The second registration message is used to instruct the terminal device to register on the IMS AS, and the second registration message can be an HTTP message. It should be understood that the second registration message can also be called a third-party registration message, a registration notification message, etc., without limitation.

[0256] Therefore, after the terminal device completes the IMS network registration or re-registration based on the SIP message, it establishes and maintains a SIP long connection with the IMS network. The SIP long connection is mainly used for calls, and can also be used for rich media communication (rich communication suite, RCS), etc. The communication method provided in the embodiment of the present application completes the push service of the DC application by reusing the SIP long connection.

[0257] Exemplarily, as shown in FIG7 , the communication method includes:

[0258] S701. A DC application server obtains a first notification message.

[0259] The first notification message is used to notify the server of the DC application to push registration information. Specifically, the first notification message carries the push registration information.

[0260] A DC application server refers to an application server that provides DC application services, and may be referred to as a DCAS, a server corresponding to a DC application, a DC application server, etc., without limitation.

[0261] The push registration information is used to indicate that the terminal device has completed the registration for the push notification service corresponding to the DC application. The registration information obtained can be used by the DC application server to initiate the push service. In other words, the push registration information is information used to initiate the push service for the DC application, DC application service registration information, DC application push information, etc., which are not limited to this. In other words, the DC application server can obtain the terminal device's registration information related to the DC application's push service through the first notification message, and use it to subsequently initiate push notifications for the DC application on the terminal device.

[0262] In an embodiment of the present application, the push registration information may include at least one of the following: an identifier of the terminal device, an identifier of the DC application, a token, and / or an expiration time of the token. Among them, the identifier of the terminal device is used to uniquely identify the terminal device, such as IMPU, IMPI, SIP-URI, etc., the identifier of the DC application is used to uniquely identify a DC application, the identifier of the terminal device and the identifier of the DC application can be used to identify which DC application on which terminal device, and in some scenarios, the identifier of the terminal device or the identifier of the DC application can also be used to identify which DC application on which terminal device; the token is used to authenticate the push notification, verify the legitimacy of the push notification for authorization, and can also be called a push token; the expiration time of the token can also be called the validity period of the token, indicating how long the token is valid, or after which point in time the token is invalid.

[0263] The push registration information can be sent by the terminal device to the DC application server. In one possible implementation, the DC application server establishes a DC bearer channel with the terminal device and receives the first notification message through the DC bearer channel. In other words, the terminal device establishes a DC bearer channel with the DC application server, and the terminal device can send the first notification message through the DC bearer channel. Correspondingly, the DC application server can receive the first notification message through the DC bearer channel.

[0264] Exemplarily, after the terminal device obtains the push registration information, it negotiates with the server of the DC application through P-CSCF, S-CSCF, MF, etc. to establish a DCA2P channel, and sends the push registration information to the server of the DC application based on the established DCA2P channel. For example, the first notification message is an HTTP message. The terminal device can send the first notification message to the IMS-AGW on the edge of the network through the DCA2P channel, and forward it to the MF via the IMS-AGW. The MF checks the first notification message of the HTTP type that requires the proxy user, removes the DC outer layer, and sends the first notification message after removing the DC outer layer to the server of the DC application as an HTTP client. Thus, the server of the DC application records and stores the push registration information. Optionally, the server of the DC application can also return a response message corresponding to the first notification message to inform it that the push registration information has been obtained.

[0265] The specific process of the terminal device obtaining the push registration information can be found in the relevant description of the push registration process of the DC application below, which will not be repeated here.

[0266] In one possible implementation, the push registration information can be carried in the first notification message after being integrity protected. For example, the integrity protection can be in the JWT (JSON Web Token) method. The push registration information is digitally signed and carried in the first notification message to securely transmit the push registration information.

[0267] Optionally, the first notification message may also include the location information of the push server. For example, the location information of the push server may be the uniform resource locator (URL) of the push server, which is used to indicate the address or location of the push server, so that the DC application server can accurately access the push server and initiate a push notification.

[0268] Therefore, after obtaining the push registration information, the DC application server can also send data or messages to the DC application on the terminal device through the DC bearer channel.

[0269] S702: When a push message needs to be initiated to a DC application, the server of the DC application sends a first push message to the push server according to the push registration information. Correspondingly, the push server receives the first push message from the server of the DC application.

[0270] In an embodiment of the present application, the DC application server determining that a push message needs to be initiated to the DC application may include: the DC application server not receiving a response from the DC application within a preset time. For example, because the DC application on the terminal device is exited or entered or is in a tombstone state due to certain operations, resulting in the DC application server not receiving a response or message from the DC application within a preset time period, the DC application server may initiate a DC application push, such as determining a first push message based on the acquired push registration information, and sending the first push message based on the location information of the push server.

[0271] Among them, the first push message is used to request to send a push notification to the DC application on the terminal device, that is, the server of the DC application can push the notification to the DC application on the terminal device through the first push message. The first push message may include the identifier of the terminal device, the identifier of the DC application and / or the push notification. The push notification is used to indicate the specific content of this push. In other words, when the DC application determines that it needs to initiate a push to the DC application, the server of the DC application can send the push registration information corresponding to the stored DC application, such as the identifier of the terminal device where the DC application is located and / or the identifier of the DC application, in the first push message.

[0272] Optionally, the push registration information may further include a token and / or the token's expiration time. To ensure the legitimacy and security of the push, the first push message may further include a token and / or the token's expiration time for authenticating the push notification.

[0273] In a possible implementation, the first push message may be an HTTP message.

[0274] S703: The push server triggers a first SIP message according to the first push message. Correspondingly, the terminal device receives the first SIP message.

[0275] The first SIP message is used to send a push notification to the DC application.

[0276] In an embodiment of the present application, after the push server obtains the first push message, it can authenticate the first push message. In a possible implementation, the push server can authenticate the first push message based on the push registration information. When the first push message authentication is passed, the push server triggers the first SIP message based on the first push message. Thus, the push server compares the identifier of the terminal device, the identifier of the DC application, the token and / or the expiration time of the token, etc. in the stored push registration information with the identifier of the terminal device, the identifier of the DC application, the token and / or the expiration time of the token carried in the first push message, and determines whether the identifiers are consistent and whether the token information is consistent, thereby achieving authentication of the first push message. For the push registration information stored by the push server, please refer to the description of the subsequent registration process. Exemplarily, the push server determines whether the token in the first push message is valid, and determines whether the push object corresponding to the first push message is authorized based on the stored identifier of the terminal device, the identifier of the DC application and the third-party registration information, and verifies the legitimacy of the message to ensure the reliability of the message.

[0277] In a possible scenario 1, the push server is deployed as an IMS AS. In this case, after completing the authentication of the first push message, the push server can directly generate and send the first SIP message.

[0278] In a possible scenario 2, the push server is deployed on the DCSF. At this time, after the push server completes the authentication of the first push message, it triggers the IMS AS to send a first SIP message to send a push notification to the DC application on the terminal device. In a possible implementation, the push server sends a second push message to the IMS AS based on the first push message. Correspondingly, the IMS AS receives the second push message from the push server. The second push message is used to request that the first SIP message be sent to the DC application. For example, the second push message can be an HTTP message. In some possible situations. The second push message can also be the first push message, which is not limited to this.

[0279] The first SIP message may include the terminal device identifier, the DC application identifier, and / or the push notification. Optionally, the terminal device identifier, the DC application identifier, and / or the push notification may also be integrity-protected and carried in the first SIP message, such as carried in a header field in the first SIP message, such as adding a p-dc-app-push-service header field to the SIP message to carry the integrity-protected information. The integrity protection may be implemented using the JWT method described above.

[0280] Optionally, the first SIP message may further include the token and / or the expiration time of the token. The token and / or the expiration time of the token may also be integrity protected and carried in the header field of the first SIP message.

[0281] It should be understood that the above content carried by the first SIP message may be determined according to the first push message.

[0282] Furthermore, the first SIP message is sent to the terminal device via a network element in the IMS network. For example, the first SIP message is sent by the IMS AS to the S-CSCF, which is then routed by the S-CSCF to the P-CSCF, which is then routed by the P-CSCF to the terminal device to send a push notification to the DC application on the terminal device. In the above scenario 1, the push server deployed on the IMS AS can communicate with the S-CSCF using a SIP ISC interface or a Restful interface.

[0283] In one possible implementation, the first SIP message may be a SIP notify message, which may be a message within a SIP session (a SIP session may have multiple applications) or a message outside a SIP session (for SADC). Furthermore, the first SIP message may be other SIP messages, such as a SIP request message, a SIP Info / Option / Message message, etc., without limitation.

[0284] S704. The terminal device executes DC application push according to the first SIP message.

[0285] Specifically, the terminal device can wake up or pull up the corresponding DC application to the foreground, and push the specific content of the push notification in the first SIP message to the DC application.

[0286] For example, after the terminal device obtains the first SIP message, if the information carried in the first SIP message is integrity protected, the terminal device can decrypt the integrity-protected information, and then use the stored push registration information to authenticate the parsed information, such as whether the token is valid, whether the token is correct, etc. If the authentication is passed, the corresponding DC application is woken up or pulled to the foreground according to the DC application identifier, and the specific content of the push notification in the first SIP message is sent to the DC application.

[0287] Under the architecture of the terminal device shown in Figure 6, after the SIP module of the terminal device receives the first SIP message, it parses the first SIP message to obtain a push notification, calls the interface to notify the DC operating environment module, and then the DC operating environment module pulls up or wakes up the corresponding DC application to the foreground. After the DC application is pulled up, the DC operating environment module sends a push notification to the DC application.

[0288] Optionally, after completing the push, the terminal device may feedback a response, such as a SIP response message with a response code of 200, to indicate that the push is completed or successful.

[0289] According to the solution provided in this application, the push server can reuse the existing SIP long connection established based on the call, and send push messages to DC applications in a closed state or tombstone state through SIP messages. There is no need to add a system-level long connection to implement message push. This not only reduces the complexity of the terminal device connection and the power consumption of the terminal device, but also enables DC applications to send and receive messages or notifications in a timely and flexible manner.

[0290] The above describes the process of the DC application server initiating push for the DC application. Before initiating push, the communication method provided in the embodiment of the present application may also include a push registration process for the DC application, which may include the following steps:

[0291] S700-1: The terminal device sends a second SIP message. Correspondingly, the push server receives the first registration message.

[0292] The second SIP message is a SIP request message initiated by the terminal device to register the push notification service of the DC application, such as the second SIP message is used to request registration of the push notification service of the DC application. The second SIP message includes the identifier of the terminal device and / or the identifier of the DC application. It should be understood that the first registration message includes the identifier of the terminal device and / or the identifier of the DC application. Optionally, the identifier of the terminal device and / or the identifier of the DC application can also be carried in the header field of the second SIP message after integrity protection, such as a newly added p-dc-app-push-service header field to carry the integrity-protected information. The integrity protection can adopt the JWT method as mentioned above.

[0293] Under the architecture of the terminal device shown in Figure 6 above, when the terminal device opens the DC application, the DC application can call the API of the DC operating environment module to initiate push notification service registration. When calling the API, the terminal device identifier and the DC application identifier are provided, so that the DC operating environment module can continue to call the underlying API after being awakened, initiate scheduling to the SIP module, and then the SIP module generates and sends a second SIP message.

[0294] In the scenario where the push server is deployed as an IMSAS, the second SIP message can be the first registration message. Exemplarily, the terminal device can send a second SIP message to the P-CSCF in the IMS network, and the P-CSCF routes the second SIP message to the S-CSCF, which then routes it to the push server deployed as an IMSAS. For example, the S-CSCF sends the second SIP message to the IMS AS based on the user's third-party registration principle and the configured iFC. Thus, after receiving the second SIP message, the push server parses the SIP-based registration request to obtain the terminal device identifier and / or DC application identifier, generates a token and / or token expiration time for the DC application on the terminal device corresponding to the identifier, and records the push registration information of the DC application. The push registration information includes the terminal device identifier, DC application identifier, token and / or token expiration time, etc.

[0295] In the scenario where the push server is deployed on the DCSF, the second SIP message is not the first registration message. In other words, the first registration message is not a SIP-type message. In this scenario, similar to the above scenario, after the second SIP message from the terminal device is routed to the IMS AS through the P-CSCF and S-CSCF, the IMS AS reports the registration information in the second SIP message to the push server deployed on the DCSF in the form of an event notification based on the user's default subscription rules. For example, if the first registration message is an HTTP message, the first registration message is used to request registration for the push notification service of the DC application. The first registration message includes the registration information in the second SIP message, such as the terminal device identifier and / or the DC application identifier.

[0296] In this scenario, in a possible implementation, the identifier of the terminal device and / or the identifier of the DC application may also be integrity protected and carried in the first registration message before being sent.

[0297] Thus, the push server registers the push notification service for the DC application on the terminal device based on the first registration message, for example, storing the push registration information to facilitate subsequent provision of push services to the DC application. Furthermore, the push server may return a response message corresponding to the first registration message carrying the push registration information to indicate that the push notification service registration for the DC application is complete, such as by executing S700-2 below.

[0298] S700-2: The push server sends a registration response corresponding to the first registration message. Correspondingly, the terminal device receives a third SIP message.

[0299] Among them, the registration response corresponding to the first registration message is used to indicate that the push notification service registration of the DC application is completed. The registration response corresponding to the first registration message may include the above-mentioned push registration information, that is, the push registration information includes the identification of the terminal device, the identification of the DC application, the token and / or the expiration time of the token.

[0300] In a possible implementation, the push registration information may be integrity protected and then carried in a registration response corresponding to the first registration message and sent.

[0301] Optionally, the registration response corresponding to the first registration message may also include the location information of the push server. In other words, the push server may also inform the DC application corresponding to the DC application identifier of the location information of its associated application server (i.e., the DC application server) for subsequent push service execution. Optionally, the location information of the push server may also be integrity protected and carried in the registration response corresponding to the first registration message before being sent.

[0302] In the scenario where the push server is deployed as an IMS AS, the registration response corresponding to the first registration message can be a third SIP message, which is a SIP response message corresponding to the second SIP message. Similar to the transmission method of the second SIP message, after completing the push notification service registration of the DC application, the push server deployed as an IMS AS sends a registration response (third SIP message) corresponding to the first registration message to the S-CSCF, which is then routed by the S-CSCF to the P-CSCF, and then routed by the P-CSCF to the terminal device. At this time, the response message corresponding to the first registration message or the third SIP message can be a SIP response message with a response code of 200 (which can be SIP20). In other words, the push server deployed as an IMS AS pushes registration information through SIP message feedback.

[0303] In the scenario where the push server is deployed on DCSF, the response message corresponding to the first registration message is not the third SIP message. For example, the response message corresponding to the first registration message may be an HTTP response message, and the response message corresponding to the first registration message carries the push registration information. Different from the above scenario, the push server deployed on DCSF sends a response message corresponding to the first registration message to IMS AS to trigger IMS AS to send a third SIP message. The third SIP message is used to indicate the completion of the registration of the push notification service of the DC application, and the third SIP message includes push registration information. In other words, IMS AS converts the first registration message into a SIP message to send the push registration information. For example, IMS AS routes the push registration information in the form of SIP signaling to the terminal device through S-CSCF and P-CSCF in sequence as described in the above scenario. At this time, the third SIP message serves as the response message corresponding to the above-mentioned second SIP message, such as SIP 200.

[0304] Thus, after receiving the third SIP message, the terminal device can determine that the registration of the push notification service of the corresponding DC application has been completed, and parse the third SIP message to obtain the push registration information. Optionally, the third SIP message can also include the location information of the push server.

[0305] Furthermore, after the terminal device obtains the push registration information, it can inform the push registration information to the DC application server, so that the DC application server can subsequently provide push services for the DC application on the terminal device.

[0306] In one possible design, after obtaining the push registration information, the terminal device can establish a DC bearer channel with the DC application server and send the push registration information to the DC application server via the DC bearer channel, such as sending the first notification message via the DC bearer channel in S701 above. In other words, the terminal device can establish the DC bearer channel with the DC application server based on the triggering of the third SIP message, that is, the terminal device establishes the DC bearer channel with the DC application server in response to the third SIP message.

[0307] Similarly, in the terminal device architecture shown in FIG6 , the SIP module in the terminal device receives the third SIP message, and the SIP module then calls the API response interface layer by layer to notify the DC application of the push registration information. When sending the push registration information to the DC application's server, the DC application calls the API of the DC runtime module to initiate the notification process to the DC application's server. The DC runtime module then establishes a DC bearer channel and triggers the DC module to send the first notification message over the established DC bearer channel.

[0308] In the push registration process for the DC application described above, in one possible implementation, the second SIP message may also be a SIP notify message. This SIP notify message may be an intra-SIP session message (a SIP session may have multiple applications) or an extra-SIP session message (for SADC). In addition, the second SIP message may also be other SIP messages, such as a SIP request message, a SIP register message, or a SIP Info / Option / Message, without limitation.

[0309] Therefore, the communication method shown in Figure 6 is based on the IMS network characteristics. On the basis of the existing SIP long connection established based on the call, the SIP long connection is reused, the push registration of the DC application is completed through the SIP message, and the push notification is sent to the DC application in the closed state or tombstone state through the SIP message. It can not only reduce the complexity of the terminal device connection and reduce the power consumption of the terminal device, but also enable the DC application to send and receive messages or notifications in a timely and flexible manner.

[0310] It should be understood that in the embodiment of the present application, the newly added functions of the reused SIP message can be indicated by setting indication information in the SIP message. For example, if the third SIP message mentioned above reuses the SIP notification message, a new information for indicating that the push notification service registration of the DC application is completed can be added to the SIP notification message. There is no limitation on this.

[0311] The communication method shown in FIG7 is described in detail below in conjunction with the IMSDC architecture. Taking the terminal device as a UE, the push server as an IMS AS deployment, and the DC application server as a DCAS as an example, FIG8 is a flow chart of a communication method provided in an embodiment of the present application, which includes:

[0312] S800: IMS network registration process based on SIP messages between UE and P-CSCF, S-CSCF, and IMSAS.

[0313] After the UE completes IMS network registration, the SIP connection established with the IMS network is maintained, mainly for IMS voice calls. The specific implementation process can be found in the relevant descriptions of the IMS network registration and re-registration processes shown in Figures 3 to 5 above, and will not be described in detail here.

[0314] S801: The DC application in the UE sends a Create Push Session message to the SIP module via the DC runtime module. Correspondingly, the SIP module receives the Create Push Session message from the DC application via the DC runtime module.

[0315] After opening the DC application, the UE calls the API of the DC runtime module and, through this API, sends a push session establishment message to the DC runtime module to register for the push notification service. This push session establishment message includes the UE ID and the DC application ID. In one possible implementation, the UE identifier can be replaced with the DC runtime ID. At this point, the DC runtime module is awakened and continues to call the underlying API to send the push session establishment message to the SIP module. The SIP module then generates and sends SIP Notification Message #1 based on this push session establishment message, as described in S802 below.

[0316] S802: The SIP module sends a SIP Notify message #1 to the P-CSCF. Correspondingly, the P-CSCF receives the SIP Notify message #1 from the SIP module.

[0317] SIP Notify Message #1 is used to request registration for the DC application's push notification service. It includes information indicating registration for the push notification service, the UE ID, and the DC application ID. To ensure information security, the SIP module can digitally sign the UE ID and DC application ID with a JWT and include them in the header of SIP Notify Message #1.

[0318] Optionally, the SIP notification message #1 may be a message within a SIP session or a message outside a SIP session, which is not limited.

[0319] The specific implementation process of the above S801 and S802 can be found in the relevant description in the above S700-1, which will not be repeated here.

[0320] S803: The P-CSCF sends a SIP Notify message #1 to the IMS AS via the S-CSCF. Correspondingly, the IMS AS receives the SIP Notify message #1 from the P-CSCF via the S-CSCF.

[0321] After receiving SIP Notify message #1, P-CSCF sends SIP Notify message #1 to S-CSCF according to the UE's registration information. S-CSCF then routes SIP Notify message #1 to IMS AS according to the UE's third-party registration information.

[0322] S804: The IMS AS sends SIP 200#1 to the P-CSCF via the S-CSCF. Correspondingly, the P-CSCF receives SIP 200#1 from the IMS AS via the S-CSCF.

[0323] After receiving SIP Notify Message #1, the IMS AS parses the SIP Notify Message #1, obtains the UE ID and DC application ID, and can authenticate the UE information based on the third-party registration information. If the authentication is successful, the UE's DC application is registered for the push notification service, a token and token expiration time are generated, and SIP 200#1 is sent to push the registration information back. SIP 200#1 is used to indicate that the push notification service registration of the DC application is complete, and the SIP 200#1 is routed to the P-CSCF via the S-CSCF. Among them, SIP 200#1 includes the UE ID, DC application ID, token, and token expiration time. Optionally, SIP 200#1 can also include the URL of the IMS AS.

[0324] To ensure information security, the UE ID, DC application ID, token, token expiration time, and IMS AS URL can be digitally signed with JWT and carried in SIP 200#1.

[0325] S805: The P-CSCF sends SIP 200#1 to the SIP module. Correspondingly, the SIP module receives SIP 200#1 from the P-CSCF.

[0326] The P-CSCF receives SIP 200#1 and sends SIP 200#1 to the SIP module in a routing form.

[0327] S806: The SIP module sends a Create Push Session response message to the DC application via the DC runtime module. Correspondingly, the DC application receives the Create Push Session response message from the SIP module via the DC runtime module.

[0328] After receiving SIP 200#1, the SIP module calls the API response interface, converts SIP 200#1 into a push session establishment response message, and informs the DC application through the DC operating environment module that its push notification service registration is complete. It also obtains and stores the UE ID, DC application ID, token, token expiration time, and IMSAS URL.

[0329] The specific implementation process of the above S804 to S806 can refer to the relevant description of the above S700-2, which will not be repeated here.

[0330] S807: The DC application sends a Push Token Notify message to the DC runtime module. Correspondingly, the DC runtime module receives the Push Token Notify message from the DC application.

[0331] After obtaining the push notification service registration information, the DC application can send a push token notification message to the DC runtime environment module to inform the DCAS of the DC application's push registration information, enabling subsequent push services. The push token notification message includes the UE ID, DC application ID, token, and token expiration time. Optionally, the push token notification message can also include the IMS AS URL.

[0332] S808. The DC operating environment module establishes a DCA2P channel with the DCAS.

[0333] After receiving the push token notification message, the DC operating environment module triggers the establishment of a DC A2P channel with the DCAS. The establishment process of the DC A2P channel can be found in the relevant description of the existing implementation method and will not be repeated here.

[0334] S809: The DC operating environment module sends an HTTP request message #1 to the DC module. Correspondingly, the DC module receives the HTTP request message #1 from the DC operating environment module.

[0335] After completing the DC A2P channel, the DC operating environment module sends an HTTP request message #1 to the DC module through the DC A2P channel to inform the DC module of the push registration information of the DC application corresponding to the DCAS.

[0336] The specific implementation of HTTP request message #1 can be found in the relevant description of the first notification message above, which will not be repeated here.

[0337] S810: The DC module sends an HTTP request message #1 to the IMS-AGW via the DC A2P channel. Correspondingly, the IMS-AGW receives the HTTP request message #1 from the DC module via the DC A2P channel.

[0338] The HTTP request message #1 received by the DC module is sent to the IMS-AGW at the network edge based on the established DCA2P channel.

[0339] S811. The IMS-AGW sends an HTTP request message #1 to the MF. Correspondingly, the MF receives the HTTP request message #1 from the IMS-AGW.

[0340] The IMS-AGW forwards the HTTP request message #1 to the MF.

[0341] S812: The MF sends an HTTP request message #1 to the DCAS. Correspondingly, the DCAS receives the HTTP request message #1 from the MF.

[0342] MF checks the HTTP message that needs to be proxied by the user, removes the DC outer layer, and initiates HTTP request message #1 to DCAS as the HTTP Client to inform DCAS of the push registration information of the corresponding DC application to complete the subsequent push service.

[0343] S813. DCAS stores and pushes registration information.

[0344] DCAS parses HTTP request message #1 and stores the UE ID, DC application ID, token, token expiration time, and IMS AS URL. Optionally, the IMS AS URL can be pre-stored in DCAS. In this case, the HTTP request message does not need to carry the IMS AS URL.

[0345] S814: DCAS sends HTTP response message #1 to the UE. Correspondingly, the UE receives HTTP response message #1 from the DCAS.

[0346] After DCAS stores the push registration information of the DC application, it can send HTTP response message #1 to the UE to inform it that the push registration information has been successfully obtained. After that, DCAS can send messages or notifications to the DC application in the foreground or background on the UE through the DCA2P channel.

[0347] S815: DCAS sends HTTP request message #2 to IMS AS. Correspondingly, IMS AS receives HTTP request message #2 from DCAS.

[0348] When the DC application on the UE is shut down or tombstoned due to certain operations and is unable to receive messages or respond, the DCAS may not receive responses from the DC application for a long time. In this case, the DCAS can send HTTP request message #2 to the IMS AS based on the URL of the IMS AS to send a push notification to the DC application. This push notification may contain content of interest to the UE. HTTP request message #2 may include the UE ID, DC application ID, token, token expiration time, and the push notification.

[0349] The specific implementation process of S815 can refer to the relevant description in the above S702 and will not be repeated here.

[0350] S816: The IMS AS sends a SIP notification message #2 to the P-CSCF via the S-CSCF. Correspondingly, the P-CSCF receives the SIP notification message #2 from the IMS AS via the S-CSCF.

[0351] After receiving HTTP Request Message #2, the IMS AS parses it and authenticates it based on the UE's third-party registration information. Using the authentication channel, it sends SIP Notify Message #2 to the S-CSCF, which sends a push notification to the DC application. The S-CSCF then routes SIP Notify Message #2 to the P-CSCF. SIP Notify Message #2 includes the UE ID, DC application ID, token, token expiration time, and push notification information.

[0352] To ensure information security, the UE ID, DC application ID, token, token expiration time, and push notification can also be digitally signed with JWT and carried in the header field of SIP notification message #2.

[0353] The specific implementation process of S816 can refer to the relevant description in the above S703 and will not be repeated here.

[0354] S817: The P-CSCF sends a SIP notification message #2 to the SIP module. Correspondingly, the SIP module receives the SIP notification message #2 from the P-CSCF.

[0355] After receiving the SIP notification message #2, the P-CSCF may also route the SIP notification message #2 to the SIP module according to the registration information of the UE.

[0356] S818. The SIP module notifies the DC runtime environment module to wake up the DC application.

[0357] The SIP module parses the SIP notification message #2, and calls the interface according to the SIP notification message #2 to notify the DC runtime environment module to wake up the DC application, and pulls the DC application that is closed or in the tombstone state to the foreground.

[0358] S819. The DC operating environment module sends a push notification to the DC application.

[0359] After the DC application is pulled to the foreground, the DC runtime environment sends a push notification carried in SIP notification message #2 to the DC application. Further, after completing the push notification, the DC runtime environment module can feedback a push completion response to indicate that the push is completed.

[0360] In the scenario shown in FIG8 , the push server is deployed as an IMS AS in the IMS network, and reuses the SIP connection used for IMS voice calls to register and provide push services for DC applications, thereby reducing the complexity of UE connections and lowering power consumption.

[0361] As another example, taking the terminal device as UE, the push server deployed in DCSF, and the DC application server as DCAS as an example, as shown in FIG9 , a flow chart of a communication method provided in an embodiment of the present application includes:

[0362] S900-1. IMS network registration process based on SIP messages between UE and P-CSCF, S-CSCF, and IMS AS.

[0363] The specific implementation process of S900-1 can refer to the relevant description in the above S800 and will not be repeated here.

[0364] S900-2. The IMS AS sends a third-party registration message to the DCSF. Correspondingly, the DCSF receives the third-party registration message from the IMS AS.

[0365] The third-party registration message is used to instruct the UE to register with the IMS AS. The specific implementation of the third-party registration message can refer to the relevant description of the second registration message above, which will not be repeated here.

[0366] S901: The DC application in the UE sends a Create Push Session message to the SIP module via the DC runtime module. Correspondingly, the SIP module receives the Create Push Session message from the DC application via the DC runtime module.

[0367] S902: The SIP module sends a SIP Notify message #1 to the P-CSCF. Correspondingly, the P-CSCF receives the SIP Notify message #1 from the SIP module.

[0368] S903: The P-CSCF sends a SIP Notify message #1 to the IMS AS via the S-CSCF. Correspondingly, the IMS AS receives the SIP Notify message #1 from the P-CSCF via the S-CSCF.

[0369] The specific implementation process of S901 to S903 can refer to the relevant description in the above S801 to S803, which will not be repeated here.

[0370] S904: The IMS AS sends an HTTP request message #3 to the push server. Correspondingly, the push server receives the HTTP request message #3 from the IMS AS.

[0371] After receiving SIP Notify message #1, the IMS AS reports the push session registration information in SIP Notify message #1 to the push server as an event notification based on the user's default subscription rules. For example, this information is sent via HTTP Request message #3 to the push server, requesting the push server to register the DC application's push notification service. HTTP Request message #3 includes the UE ID and DC application ID. To ensure information security, the UE ID and DC application ID can also be digitally signed with a JWT and carried in HTTP Request message #3.

[0372] S905: The push server sends an HTTP response message #3 to the IMS AS. Correspondingly, the IMS AS receives the HTTP response message #3 from the push server.

[0373] Among them, HTTP response message #3 is used to instruct the DC application to complete the registration of the push notification service.

[0374] After receiving HTTP response message #3, the push server parses it, obtains the UE ID and DC application ID, and authenticates the UE's information based on the third-party registration information. If authentication succeeds, the server registers the UE's DC application for the push notification service, generates a token and token expiration time, and sends HTTP response message #3 to return the push registration information. HTTP response message #3 includes the UE ID, DC application ID, token, and token expiration time. Optionally, HTTP response message #3 may also include the URL of the IMS AS.

[0375] S906: The IMS AS sends SIP 200#1 to the P-CSCF via the S-CSCF. Correspondingly, the P-CSCF receives SIP 200#1 from the IMS AS via the S-CSCF.

[0376] After receiving HTTP response message #3, the IMS AS may also authenticate the HTTP response message #3 according to the third-party registration information. If the authentication is successful, it sends SIP 200 #1 to instruct the DC application to complete the registration of the push notification service.

[0377] SIP 200#1 includes UE ID, DC application ID, token, and token expiration time. Optionally, SIP 200#1 may also include the URL of the IMS AS.

[0378] To ensure information security, the UE ID, DC application ID, token, token expiration time, and IMS AS URL can be digitally signed with JWT and carried in SIP 200#1.

[0379] The specific implementation process of S906 can refer to the relevant description in the above S804, which will not be repeated here.

[0380] S907: The P-CSCF sends SIP 200#1 to the SIP module. Correspondingly, the SIP module receives SIP 200#1 from the P-CSCF.

[0381] S908: The SIP module sends a push session establishment response message to the DC application via the DC operating environment module. Correspondingly, the DC application receives the push session establishment response message from the SIP module via the DC operating environment module.

[0382] S909: The DC application sends a push token notification message to the DC runtime module. Correspondingly, the DC runtime module receives the push token notification message from the DC application.

[0383] S910 and the DC operating environment module establish a DCA2P channel with the DCAS.

[0384] S911: The DC operating environment module sends an HTTP request message #1 to the DC module. Correspondingly, the DC module receives the HTTP request message #1 from the DC operating environment module.

[0385] S912: The DC module sends an HTTP request message #1 to the IMS-AGW via the DC A2P channel. Correspondingly, the IMS-AGW receives the HTTP request message #1 from the DC module via the DC A2P channel.

[0386] S913: The IMS-AGW sends an HTTP request message #1 to the MF. Correspondingly, the MF receives the HTTP request message #1 from the IMS-AGW.

[0387] S914: The MF sends an HTTP request message #1 to the DCAS. Correspondingly, the DCAS receives the HTTP request message #1 from the MF.

[0388] S915. DCAS stores and pushes registration information.

[0389] S916: DCAS sends HTTP response message #1 to the UE. Correspondingly, the UE receives HTTP response message #1 from the DCAS.

[0390] S917: DCAS sends HTTP request message #2 to the push server. Correspondingly, the push server receives HTTP request message #2 from DCAS.

[0391] The specific implementation process of S907 to S917 can refer to the relevant description in the above S805 to S815, which will not be repeated here.

[0392] S918: The push server sends HTTP request message #2 to the IMS AS. Correspondingly, the IMS AS receives HTTP request message #2 from the push server.

[0393] The push server receives the HTTP request message #2 and may authenticate the HTTP request message #2 according to the third-party registration information and the push registration information. If the authentication is successful, the push server sends the HTTP request message #2 to the IMSAS.

[0394] S919: The IMS AS sends a SIP Notify message #2 to the P-CSCF via the S-CSCF. Correspondingly, the P-CSCF receives the SIP Notify message #2 from the IMS AS via the S-CSCF.

[0395] S920: The P-CSCF sends a SIP notification message #2 to the SIP module. Correspondingly, the SIP module receives the SIP notification message #2 from the P-CSCF.

[0396] S921. The SIP module notifies the DC runtime environment module to wake up the DC application.

[0397] S922. The DC operating environment module sends a push notification to the DC application.

[0398] The specific implementation process of S919 to S922 can be found in the relevant descriptions in the above S816 to S819, which will not be repeated here.

[0399] In the scenario shown in Figure 9, the push server is deployed on the DCSF, and the SIP connection used for IMS voice calls is reused to register the push service of the DC application. The DCSF triggers the IMS AS to reuse the SIP connection used for IMS voice calls to perform push service provision, which can reduce the complexity of UE connection and reduce power consumption.

[0400] In each of the above embodiments, the methods and / or steps implemented by the push server may also be implemented by components that can be used for the push server (such as a processor, chip, chip system, circuit, logic module, or software); the methods and / or steps implemented by the terminal device may also be implemented by components that can be used for the terminal device (such as a processor, chip, chip system, circuit, logic module, or software); the methods and / or steps implemented by the server of the DC application may also be implemented by components that can be used for the server of the DC application (such as a processor, chip, chip system, circuit, logic module, DU or software).

[0401] The above mainly introduces the solution provided by the present application. Accordingly, the present application also provides a communication device, which is used to implement the various methods in the above method embodiments. The communication device can be the push server in the above method embodiments, or a device including a push server, or a component that can be used for a push server, such as a chip or a chip system. Alternatively, the communication device can be the terminal device in the above method embodiments, or a device including a terminal device, or a component that can be used for a terminal device, such as a chip or a chip system. Alternatively, the communication device can be the server of the DC application in the above method embodiments, or a device including a server of the DC application, or a component that can be used for a server of the DC application, such as a chip or a chip system.

[0402] In some embodiments, in order to implement the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily appreciate that, in combination with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0403] The embodiment of the present application can divide the functional modules of the communication device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.

[0404] Taking the communication device as the push server or terminal device or DC application server in the above method embodiment as an example, Figure 10 is a structural diagram of a communication device provided in an embodiment of the present application. As shown in Figure 10, the communication device 1000 includes: a processing module 1001 and a transceiver module 1002. Among them, the processing module 1001 is used to perform the processing function of the push server or terminal device or DC application server in the above method embodiment. The transceiver module 1002 is used to perform the transceiver function of the push server or terminal device or DC application server in the above method embodiment.

[0405] Among them, all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0406] Since the communication device 1000 provided in this embodiment can execute the above method, the technical effects that can be obtained can refer to the above method embodiments and will not be repeated here.

[0407] In one possible design solution, in an embodiment of the present application, the transceiver module 1002 may include a receiving module and a sending module (not shown in FIG10 ), wherein the sending module and the receiving module are respectively used to implement the sending function and the receiving function of the communication device 1000 .

[0408] In one possible design, the communication device 1000 may further include a storage module (not shown in FIG10 ) storing a program or instruction. When the processing module 1001 executes the program or instruction, the communication device 1000 may perform the functions of a push server, a terminal device, or a DC application server in any of the methods shown in FIG7 to FIG9 .

[0409] In some embodiments, the processing module 1001 involved in the communication device 1000 can be implemented by a processor or a processor-related circuit component, which can be a processor or a processing unit; the transceiver module 1002 can be implemented by a transceiver or a transceiver-related circuit component, which can be a transceiver or a transceiver unit.

[0410] For example, Figure 11 is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. The communication device can be a push server or terminal device or DC application server in the above-mentioned method embodiment, or it can be a chip (system) or other parts or components that can be set in a push server or terminal device or DC application server. As shown in Figure 11, the communication device 1100 may include a processor 1101. In a possible design scheme, the communication device 1100 may also include a memory 1102 and / or a transceiver 1103. Among them, the processor 1101 is coupled to the memory 1102 and the transceiver 1103, such as by a communication bus.

[0411] The following is a detailed introduction to the various components of the communication device 1100 with reference to FIG11 :

[0412] The processor 1101 is the control center of the communication device 1100 and can be a single processor or a collective term for multiple processing elements. For example, the processor 1101 includes one or more CPUs, or can be an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more microprocessors (digital signal processors, DSPs) or one or more field programmable gate arrays (FPGAs).

[0413] In one possible design, the processor 1101 may execute various functions of the communication device 1100 by running or executing software programs stored in the memory 1102 and calling data stored in the memory 1102 .

[0414] In a specific implementation, as an embodiment, the processor 1101 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG11 .

[0415] In a specific implementation, as an embodiment, the communication device 1100 may also include multiple processors, such as the processor 1101 and the processor 1104 shown in Figure 11. Each of these processors may be a single-core processor or a multi-core processor. The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0416] Among them, the memory 1102 is used to store the software program for executing the solution of this application, and the execution is controlled by the processor 1101. The specific implementation method can refer to the above method embodiment and will not be repeated here.

[0417] In one possible design, the memory 1102 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1102 may be integrated with the processor 1101 or exist independently and be coupled to the processor 1101 via an interface circuit (not shown in FIG. 11 ) of the communication device 1100. This embodiment of the present application does not specifically limit this.

[0418] Transceiver 1103 is used for communication with other communication devices. For example, if communication device 1100 is a terminal device, transceiver 1103 can be used to communicate with an access network device or another terminal device. For another example, if communication device 1100 is a network device, transceiver 1103 can be used to communicate with a terminal device or another network device.

[0419] In one possible design, transceiver 1103 may include a receiver and a transmitter (not separately shown in FIG11 ), wherein the receiver is configured to implement a receiving function, and the transmitter is configured to implement a transmitting function.

[0420] In one possible design scheme, the transceiver 1103 can be integrated with the processor 1101, or it can exist independently and be coupled to the processor 1101 through the interface circuit of the communication device 1100 (not shown in Figure 11). This embodiment of the present application does not specifically limit this.

[0421] It should be noted that the structure of the communication device 1100 shown in FIG11 does not constitute a limitation on the communication device. An actual communication device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0422] In addition, the technical effects of the communication device 1100 can refer to the technical effects of the methods described in the above method embodiments, and will not be repeated here.

[0423] An embodiment of the present application further provides a computer-readable storage medium on which a computer program or instruction is stored. When the computer program or instruction is executed by a computer, the functions of the above-mentioned method embodiment are realized.

[0424] The embodiments of the present application also provide a computer program product, which implements the functions of the above method embodiments when executed by a computer.

[0425] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0426] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0427] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0428] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0430] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0431] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or an access network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a random access memory RAM, a magnetic disk, or an optical disk.

[0432] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in the claims. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0433] Although the present application has been described with reference to specific features and embodiments thereof, it is apparent that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely illustrative of the present application as defined by the appended claims and are deemed to cover any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, the present application is intended to include such modifications and variations as fall within the scope of the claims of the present application and their equivalents.

Claims

1. A communication method, characterized in that, In the case of the process in which a terminal device registers to an IP Multimedia Subsystem (IMS) network based on Session Initiation Protocol (SIP) messages, the method includes: Receiving a first push message from a server of a Data Channel (DC) application, where the first push message is used to request sending a push notification to the DC application on the terminal device; Triggering a first SIP message according to the first push message, where the first SIP message is used to send the push notification to the DC application.

2. The method according to claim 1, characterized in that, Before receiving the first push message from the server of the Data Channel (DC) application, the method further includes: Receiving a first registration message, where the first registration message is used to request registering the push notification service of the DC application; Sending a registration response corresponding to the first registration message.

3. The method according to claim 2, characterized in that, The first registration message includes an identifier of the terminal device and an identifier of the DC application.

4. The method according to claim 2 or 3, characterized in that, The registration response includes push registration information, where the push registration information includes the identifier of the terminal device, the identifier of the DC application, a token, and / or an expiration time of the token, and the token is used to authenticate the push notification.

5. The method according to claim 4, characterized in that, The triggering the first SIP message according to the first push message includes: Authenticating the first push message according to the push registration information; Triggering the first SIP message according to the first push message when the authentication of the first push message passes.

6. The method according to claim 4 or 5, characterized in that The method is executed by a push server, and the registration response further includes location information of the push server.

7. The method according to any one of claims 2-6, characterized in that, The method is executed by an IMS Application Server (AS); The first registration message is a second SIP message.

8. The method according to any one of claims 2-6, characterized in that, The method is executed by a Data Channel Signaling Function (DCSF), and the process in which the terminal device registers to an IP Multimedia Subsystem (IMS) network based on Session Initiation Protocol (SIP) messages further includes: Receiving a second registration message from the IMS AS, where the second registration message is used to indicate that the terminal device registers to the IMS AS.

9. The method according to claim 8, wherein The triggering the first SIP message according to the first push message includes: Sending a second push message to the IMS AS according to the first push message, where the second push message is used to request sending the first SIP message to the DC application.

10. The method according to claim 9, wherein The second push message includes the identifier of the terminal device, the identifier of the DC application, and the push notification.

11. The method according to claim 10, wherein The second push message further includes a token and / or an expiration time of the token, and the token is used to authenticate the push notification.

12. The method according to any one of claims 1-11, characterized in that, The first push message and the first SIP message include the identifier of the terminal device, the identifier of the DC application, and the push notification.

13. The method according to claim 12, wherein The first push message and the first SIP message further include a token and / or an expiration time of the token, and the token is used to authenticate the push notification.

14. A communication method, characterized in that, In the case of the process in which a terminal device registers to an IP Multimedia Subsystem (IMS) network based on Session Initiation Protocol (SIP) messages, the method includes: Receiving a first SIP message, where the first SIP message is used to send a push notification to a DC application on the terminal device; Performing DC application push according to the first SIP message.

15. The method according to claim 14, characterized in that, The method further includes: Sending a second SIP message for requesting to register the push notification service of the DC application; Receiving a third SIP message for indicating the completion of the registration of the push notification service of the DC application, where the third SIP message includes push registration information; Sending a first notification message for notifying the server of the DC application of the push registration information.

16. The method according to claim 15, wherein, The sending of the first notification message includes: Establishing a DC bearer channel with the server of the DC application; Sending the first notification message through the DC bearer channel.

17. The method according to claim 15 or 16, characterized in that, The second SIP message includes the identifier of the terminal device and the identifier of the DC application.

18. The method according to any one of claims 15 - 17, characterized in that, The push registration information includes the identifier of the terminal device, the identifier of the DC application, a token and / or the expiration time of the token, where the push token is used for authenticating the push notification.

19. The method according to claim 18, characterized in that, The third SIP message further includes the location information of the push server.

20. The method according to claim 19, wherein The push server is an IMS application server AS or is deployed on a data channel signaling function DCSF.

21. The method according to any one of claims 14-20, characterized in that, The first SIP message includes the identifier of the terminal device, the identifier of the DC application and the push notification.

22. The method according to claim 21, wherein The first SIP message further includes a token and / or the expiration time of the token, where the token is used for authenticating the push notification.

23. A communication method, characterized in that, In the case of the process of a terminal device registering to an IP multimedia subsystem IMS network based on a session initiation protocol SIP message, the method includes: Obtaining a first notification message for notifying the server of the DC application of the push registration information; In the case of needing to initiate a push to the DC application, sending a first push message to a push server according to the push registration information, where the first push message is used for sending a push notification to the DC application on the terminal device.

24. The method according to claim 23, wherein The need to initiate a push to the DC application includes: Not receiving a response from the DC application within a preset time.

25. The method according to claim 23 or 24, characterized in that The obtaining of the first notification message includes: Establishing a DC bearer channel with the terminal device; Receiving the first notification message through the DC bearer channel.

26. The method according to any one of claims 23-25, characterized in that, The push registration information includes the identifier of the terminal device, the identifier of the DC application, a token and / or the expiration time of the token, where the token is used for authenticating the push notification.

27. The method according to claim 26, wherein The first notification message further includes the location information of the push server.

28. The method according to any one of claims 23-27, characterized in that, The first push message includes the identifier of the terminal device, the identifier of the DC application and the push notification.

29. The method according to claim 28, wherein The first push message further includes a token and / or the expiration time of the token, where the token is used for authenticating the push notification.

30. A communication device, characterized in that, Includes a module for executing the method according to any one of claims 1 - 29.

31. A communication device, characterized in that, Comprising a processor and an interface circuit, the interface circuit being configured to receive signals from other communication devices outside the communication device and transmit them to the processor or send signals from the processor to other communication devices outside the communication device, the processor being configured to implement the method according to any one of claims 1-29 through logic circuits or by executing code instructions.

32. A communication device, characterized in that, Comprising: A processor; The processor is configured to run a computer program or instructions to implement the method according to any one of claims 1-29.

33. A communication chip, characterized in that, Instructions are stored therein, which cause the method according to any one of claims 1-29 to be implemented when the chip runs on a communication device.

34. A computer-readable storage medium, characterized in that, A computer program or instructions are stored in the storage medium, and when the computer program or instructions are executed by a communication device, the method according to any one of claims 1-29 is implemented.

35. A computer program product, characterized in that, Comprising computer program code, when the computer program code runs on a communication device, the communication device implements the method according to any one of claims 1-29.

Images