Communication method and device

Abstract

The embodiment of the invention provides a communication method and device, relates to the field of communication, and can enable DC applications to freely transmit and receive messages and notifications while reducing the power consumption of a plurality of DC applications supported by terminal equipment. The method comprises the following steps: under the condition that a terminal device registers to a flow of an IP multimedia subsystem (IMS) network based on a session initiation protocol (SIP) message, a push server receives a first push message from a server of a DC application, and triggers the first SIP message according to the first push message. Wherein the first push message is used for requesting to send a push notification to a DC application on the terminal equipment, and the first SIP message is used for sending the push notification to the DC application. Therefore, on the basis of the existing SIP long connection established based on the call, the SIP long connection is multiplexed to send the push notification to the DC application in the closed state or the tombstone state through the SIP message, so that the power consumption is reduced, and the message and the notification can be freely received and transmitted.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular, to a communication method and apparatus. Background Art

[0002] The new call service under the 5th generation (5G) mobile communication system (hereinafter referred to as 5G New Calling) is an enhanced voice call service based on the 5G network, which realizes service transmission through an additional data channel (DC) between a terminal device and an Internet Protocol (IP) Multimedia Subsystem (IMS). In the 3rd generation partnership project (3GPP) protocol release (R) 18, it is proposed that the DC needs to be established based on an IMS call, and in R19, a standalone DC (SADC) is proposed. The SADC enables multiple DC applications to run in parallel without relying on a call.

[0003] Currently, for non-DC applications of a terminal device, when an application enters the background, the system records the current state of the application program, then aborts the program and releases the resources used by the application, so that the application in the background does not compete for resources with the application in the foreground. For an application in this state, an application server can provide a message push notification function for the application through a push server. The push server maintains a system-level long connection with the terminal device to send push messages to the application in the tombstone state. This system-level long connection cannot be cancelled on the terminal device side, which increases the power consumption cost of the terminal device for maintaining the connection.

[0004] However, for the IMS DC scenario, how to transmit push messages with low power consumption is not clear yet. Summary of the Invention

[0005] This application provides a communication method and apparatus, which 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.

[0006] To achieve the above object, this application adopts the following technical solutions:

[0007] In a first aspect, a communication method is provided. This method can be executed by a push server, or by components of the push server, such as a processor, a chip, or a chip system of the push server, etc. It can also be implemented by a logic module or software that can implement all or part of the push server. The method includes: in the case where a terminal device registers to an IP Multimedia Subsystem (IMS) network based on a Session Initiation Protocol (SIP) message process, the push server receives a first push message from a server of a Data Channel (DC) application, and triggers a first SIP message according to the first push message. Among them, the first push message is used to request to send a push notification to the DC application on the terminal device, and the first SIP message is used to send a push notification to the DC application.

[0008] Based on this communication method, the push server can reuse the existing SIP long connection established based on a call, and send push messages to a DC application in a closed state or tombstone state through SIP messages, without adding a system-level long connection to implement message push. This can not only reduce the complexity of the connection of the terminal device, thereby reducing the power consumption of the terminal device, but also enable the DC application to receive and send messages or notifications in a timely and flexible manner.

[0009] In a possible design, before the push server receives the first push message from a server of a Data Channel (DC) application, the method described in the first aspect may further include: the push server receives a first registration message. Among them, the first registration message is used to request to register 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, and the above-mentioned push notification service can be implemented based on this registration.

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

[0011] In a possible design, the identifier of the terminal device and the identifier of the DC application are carried in the first registration message after integrity protection. Thus, by performing integrity protection on the registration information of the requested push service, the security of the information can be guaranteed. For example, the integrity protection can adopt the JWT method.

[0012] In a possible design, the registration response may include push registration information, and the push registration information includes an identifier of the terminal device, an identifier of the DC application, a token, and / or an expiration time of the token. The token is used to authenticate the push notification. Thus, the push server feeds back the push registration information for use in initiating subsequent push services.

[0013] In a possible design solution, the push server triggers a first SIP message according to a first push message, which may include: the push server authenticates the first push message according to push registration information. When the authentication of the first push message passes, the push server triggers a first SIP message according to the first push message. Thus, in order to ensure the reliability of the message, the push server can authenticate the received first push message according to the stored push registration information.

[0014] In a possible design solution, the registration response may further include the location information of the push server, and the location information of the push server can be used by the server of the subsequent DC application to determine the push server, so as to facilitate the initiation of push notifications. In some scenarios, the location information of the push server can be pre-configured in the server of the DC application. At this time, the registration response may not carry the location information of the push server, and thus there is no need for the terminal device to obtain the location information of the push server from the registration response and then report it to the server of the DC application.

[0015] In a possible design solution, the location information of the push server can be carried in the registration response after integrity protection to ensure the security of the information. For example, the integrity protection can adopt the JWT method.

[0016] In a possible design solution, the push server can be an IMS application server AS. At this time, the first registration message can be a second SIP message. In this design solution, the push server can receive a first registration message from a serving-call session control function S-CSCF. At this time, after the push server receives the first push message, it can directly reuse the SIP connection and initiate a push notification to the DC application using SIP messages.

[0017] In a possible design solution, the push server is deployed on a data channel signaling function DCSF. The process of the terminal device registering to the IP multimedia subsystem IMS network based on the session initiation protocol SIP message may further include: the push server receives a second registration message from the IMS AS. The second registration message is used to indicate that the terminal device registers to the IMS AS. Thus, in the IMS DC architecture, during the IMS network registration process of the terminal device supporting DC, the push server can know which IMS AS the terminal device registers to, so as to facilitate subsequent push registration and push notification.

[0018] In a possible design solution, the push server triggers a first SIP message based on a first push message, which may include: the push server sends a second push message to the IMS AS according to the first push message. The second push message is used to request to send the first SIP message to the DC application. In this design solution, the push server may receive a first registration message from the IMS AS. At this time, the push server needs to trigger the IMS AS to reuse the SIP connection and initiate a push notification to the DC application using the SIP message.

[0019] 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.

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

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

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

[0023] 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.

[0024] In a possible design solution, one or more of the identifier of the terminal device, the identifier of the DC application, the token, the expiration time of the token, and the push notification may be carried in the first SIP message after integrity protection to ensure the security of the information.

[0025] In a possible design solution, the integrity protection may be in the form of JSON Web Token (JWT).

[0026] In a second aspect, a communication method is provided. This method may be executed by a terminal device, or by components of the terminal device, such as the processor, chip, or chip system of the terminal device, or may also be implemented by a logic module or software that can implement all or part of the terminal device. In the case of the process of the terminal device registering to the IP Multimedia Subsystem (IMS) network based on the Session Initiation Protocol (SIP) message, the method includes: the terminal device receives a first SIP message and performs DC application push according to the first SIP message. The first SIP message is used to send a push notification to the DC application on the terminal device.

[0027] Based on this communication method, the terminal device receives a first SIP message on the basis of an existing SIP long connection established based on a call, and wakes up and launches a DC application in a closed state or tombstone state according to the first SIP message to send a push message. Without adding a system-level long connection to implement message push, it can not only reduce the complexity of the connection of the terminal device, thereby reducing the power consumption of the terminal device, but also enable the DC application to receive and send messages or notifications in a timely and flexible manner.

[0028] In a possible design solution, the method described in the second aspect may further include: The terminal device sends a second SIP message, where 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, where 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. The terminal device sends a first notification message, where the first notification message is used to notify the server of the DC application of the push registration information. Thus, the terminal device can also reuse the existing SIP long connection established based on the call to initiate a push registration process through the second SIP message, and obtain the push registration information through the third SIP message, so as to implement the push service with low power consumption.

[0029] In a possible design solution, the terminal device sending the first notification message may include: The terminal device establishes a DC bearer channel with the server of the DC application. The terminal device sends the first notification message through the DC bearer channel. Thus, after obtaining the push registration information, the terminal device can send the push registration information to the server of the DC application by establishing a DC bearer channel with the server of the DC application, so as to facilitate the subsequent push by the server of the DC application.

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

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

[0032] 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 push token is used to authenticate the push notification.

[0033] In a possible design solution, the push registration information may be carried in the third SIP message after integrity protection.

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

[0035] In a possible design solution, the location information of the push server can also be carried in the third SIP message after integrity protection.

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

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

[0038] In a possible design solution, the first SIP message can also include a token and / or the expiration time of the token, and the token is used to authenticate the push notification.

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

[0040] In a possible design solution, the integrity protection can be in the form of JWT.

[0041] In a third aspect, a communication method is provided. This method can be executed by the server of the DC application, or by components of the server of the DC application, such as the processor, chip, or chip system of the server of the DC application, etc., and can also be implemented by a logic module or software that can implement all or part of the server of the DC application. In the case of the process where the terminal device registers to the IP multimedia subsystem IMS network based on the 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 of the push registration information. When a push to the DC application is required, the server of the DC application sends a first push message to the push server according to the push registration information. Among them, the first push message is used to send a push notification to the DC application on the terminal device.

[0042] Based on this communication method, when a push to the DC application on the terminal device is required, 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 to reuse the SIP long connection established based on the call through the first push message, and send a push message 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 can also enable the DC application to receive and send messages or notifications in a timely and flexible manner.

[0043] In a possible design solution, to initiate a push to the DC application, it may include: the server of the DC application does not receive a response from the DC application within a preset time. In other words, when the server of the DC application sends a message to the DC application but does not receive a response from the DC application within the preset time, the server of the DC application can initiate a push to the DC application.

[0044] In a possible design solution, for the server of the DC application to obtain the first notification message, it may include: the server of the DC application establishes a DC bearer channel with the terminal device. The server of the DC application receives the first notification message through the DC bearer channel.

[0045] 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 token is used to authenticate the push notification.

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

[0047] 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.

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

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

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

[0051] Among them, for the description of the technical effects of the method in the second aspect or the third aspect, reference may be made to the description of the technical effects of the method in the first aspect, and details will not be elaborated here.

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

[0053] In some possible designs, the communication device includes a processing module and a transceiver module. Among them, in the case where the terminal device registers to the IP Multimedia Subsystem (IMS) network based on the Session Initiation Protocol (SIP) message process, the transceiver module is used to receive a first push message from the server of the DC application. The processing module is used to trigger a first SIP message according to the first push message. Among them, the first push message is used to request to send a push notification to the DC application on the terminal device, and the first SIP message is used to send a push notification to the DC application.

[0054] In a possible design, before the transceiver module is used to receive the first push message from the server of the data channel (DC) application, the transceiver module is further used to receive a first registration message. Among them, the first registration message is used to request to register the push notification service of the DC application. The transceiver module is further used to send a registration response corresponding to the first registration message.

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

[0056] In a possible design, the identifier of the terminal device and the identifier of the DC application are carried in the first registration message after integrity protection.

[0057] In a possible design, the registration response may include push registration information, and 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, and the token is used to authenticate the push notification.

[0058] In a possible design, the processing module is used to trigger a first SIP message according to the first push message, specifically including: the processing module is used to authenticate the first push message according to the push registration information. In the case where the authentication of the first push message passes, the processing module is further used to trigger a first SIP message according to the first push message.

[0059] In a possible design, the registration response may further include the location information of the push server.

[0060] In a possible design, the location information of the push server may be carried in the registration response after integrity protection.

[0061] In a possible design, the push server may be an IMS application server (AS), and at this time the first registration message may be a second SIP message.

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

[0063] In a possible design solution, a processing module is configured to trigger a first SIP message according to a first push message. Specifically, the processing module is configured to control a transceiver module to send a second push message to the IMS AS according to the first push message. The second push message is used to request to send the first SIP message to a DC application.

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

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

[0066] 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.

[0067] 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. The token is used to authenticate the push notification.

[0068] 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.

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

[0070] In a possible design solution, the integrity protection may be in the form of JSON Web Token (JWT).

[0071] In a possible design solution, the transceiver module may include a receiving module and a sending module. 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.

[0072] In a possible design, the communication device described in the fourth aspect may further include a storage module that stores programs or instructions. When the processing module executes the programs or instructions, the communication device described in the fourth aspect can execute the method described in the first aspect.

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

[0074] In some possible designs, the communication device includes: a processing module and a transceiver module. Among them, in the case of the process in which the terminal device registers to the IP Multimedia Subsystem (IMS) network based on the Session Initiation Protocol (SIP) message, the transceiver module is used to receive a first SIP message. The processing module is used to perform DC application push according to the first SIP message. The first SIP message is used to send a push notification to the DC application on the terminal device.

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

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

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

[0078] In a possible design, the identifier of the terminal device and the identifier of the DC application may be carried in the second SIP message after integrity protection.

[0079] 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.

[0080] In a possible design solution, the push registration information may be carried in the third SIP message after integrity protection.

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

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

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

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

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

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

[0087] In a possible design solution, the integrity protection may be in the form of JWT.

[0088] In a possible design solution, the transceiver module may include a receiving module and a sending module. Among them, 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.

[0089] In a possible design solution, the communication device described in the fifth aspect may further include a storage module that stores programs or instructions. When the processing module executes the programs or instructions, the communication device described in the fifth aspect can execute the method described in the second aspect.

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

[0091] In some possible designs, the communication device includes: a processing module and a transceiver module. Among them, in the case of the process where the terminal device registers to the IP Multimedia Subsystem (IMS) network based on the Session Initiation Protocol (SIP) message, the processing module is used to obtain a first notification message, and the first notification message is used to notify the server for the data channel (DC) application to push registration information. When it is necessary to initiate a push to the DC application, the transceiver module is used to send 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.

[0092] In a possible design solution, the need to initiate a push to the DC application may include: the server for the DC application does not receive a response from the DC application within a preset time.

[0093] In a possible design solution, the processing module is used to obtain the first notification message, specifically including: the processing module is used to establish a DC bearer channel with the terminal device. The processing module is used to control the transceiver module to receive the first notification message through the DC bearer channel.

[0094] 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.

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

[0096] 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.

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

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

[0099] In a possible design, the first push message may be an HTTP message.

[0100] In a possible design, the transceiver module may include a receiving module and a sending module. Among them, 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.

[0101] In a possible design, the communication device described in the sixth aspect may further include a storage module, and the storage module stores programs or instructions. When the processing module executes the programs or instructions, the communication device described in the sixth aspect can execute the method described in the third aspect.

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

[0103] In a possible design, the communication device may further include a memory, and the memory is used to store necessary program instructions and data. The processor is coupled to the memory, and the processor is configured to execute the computer programs or instructions stored in the memory, so that the communication device executes the methods described in the first aspect, the second aspect, or the third aspect.

[0104] In a possible design, 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.

[0105] In a possible design, the processor may be integrated with the memory.

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

[0107] In an eighth aspect, a communication device is provided. The communication device includes a processor and an interface circuit. The interface circuit is 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 is configured to implement the methods described in the first aspect, the second aspect, or the third aspect through logic circuits or by executing code instructions.

[0108] In a ninth aspect, a communication device is provided. The communication device may be a push server, or a module or unit (such as a chip, or a chip system, or a circuit) that respectively corresponds to the methods / operations / steps / actions described in the first aspect and executes them in the push server, or a device that can be used in combination with the push server. Alternatively, the communication device may be a terminal device, or a module or unit (such as a chip, or a chip system, or a circuit) that respectively corresponds to the methods / operations / steps / actions described in the second aspect and executes them in the terminal device, or a device that can be used in combination with the terminal device. Alternatively, the communication device may be a server for DC applications, or a module or unit (such as a chip, or a chip system, or a circuit) that respectively corresponds to the methods / operations / steps / actions described in the third aspect and executes them in the server for DC applications, or a device that can be used in combination with the server for DC applications.

[0109] 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.

[0110] In a tenth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program or instruction. When it runs on the communication device, the communication device can execute the methods described in the first aspect, the second aspect, or the third aspect above.

[0111] In an eleventh aspect, a computer program product including instructions is provided, including computer program code. When the computer program code runs on the communication device, the communication device can execute the methods described in the first aspect, the second aspect, or the third aspect above.

[0112] In a twelfth aspect, a communication system is provided, including: 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. Description of the Drawings

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

[0114] Figure 2 It is a schematic diagram of an IMSDC architecture;

[0115] Figure 3 It is a schematic diagram of an IMS basic registration process;

[0116] Figure 4 It is a schematic diagram of a third-party registration process;

[0117] Figure 5 Schematic diagram of the architecture of a communication system provided by an embodiment of the present application;

[0118] Figure 6 Schematic diagram of the architecture of a terminal device supporting DC application provided by an embodiment of the present application;

[0119] Figure 7 Schematic diagram of the process flow of a communication method provided by an embodiment of the present application;

[0120] Figure 8 Schematic diagram of the process flow of another communication method provided by an embodiment of the present application;

[0121] Figure 9 Schematic diagram of the process flow of yet another communication method provided by an embodiment of the present application;

[0122] Figure 10 Schematic diagram of the structure of a communication device provided by an embodiment of the present application;

[0123] Figure 11 Schematic diagram of the structure of another communication device provided by an embodiment of the present application. Detailed implementation manners

[0124] 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 the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. In addition, combinations of these solutions may also be used.

[0125] The technical solutions of the embodiments of this 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, vehicle networking communication systems, worldwide interoperability for microwave access (WiMAX) communication systems, 4th generation (4G) mobile communication systems, such as long term evolution (LTE) systems, worldwide 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, etc.

[0126] For ease of understanding, the technical terms involved in the embodiments of this application will be introduced first below.

[0127] 1. DC

[0128] In 3GPP R16, a framework diagram of a DC workflow is defined. For the data channel network function, only the data channel server functionality, the data channel application repository (DCAR), and the conceptual process of its interaction with the user equipment (UE) are defined, but the relationship between DC and the IMS network is not clearly defined. As Figure 1 shown, DC-related applications are uploaded to the network side by the UE licensee, and DC-related applications are stored in the DCAR; during a call, DC-related applications are downloaded from the DCAR; DC-related applications are sent to the local UE by the bootstrap DC; DC-related applications are sent to the remote UE through the bootstrap data channel; other data channels used by DC-related applications can be established between the local and remote UEs.

[0129] Furthermore, in Release 18, a service based interface (SBA) architecture is used to interoperate with the IMS network. Also, in Release 18, it is specified that the establishment of the DC is related to the IMS multimedia telephony (MMTel) session. Here, the DC is a newly added DC on the basis of the existing video channel, audio channel, and signaling channel between the terminal device and the IMS, forming the IMS DC architecture for use in an enhanced voice call service based on the 5G network, namely 5G New Calling. 5G New Calling provides more functions around the traditional voice call service, such as intelligent translation, fun calls, intelligent customer service, content sharing, remote assistance, etc.

[0130] In addition, in Release 19, a standalone DC (SADC) is proposed. The SADC greatly increases the scenarios where multiple DC applications can run in parallel and enables multiple DC applications to run in parallel without relying on calls.

[0131] 2. IMS DC Architecture

[0132] IMS is one of the core technologies of network communication and also a new form of multimedia service. IMS can meet the needs of more novel and diverse multimedia services of terminal devices and is an important way to solve the integration of mobile and fixed networks and introduce differentiated services such as the triple integration of voice, data, and video.

[0133] The IMS DC architecture is an IMS architecture that supports DC applications and can synchronously transmit any multimedia and data information, such as audio, video, pictures, text, hyper text markup language 5 (H5), location, expressions, actions, augmented reality (AR), virtual reality (VR), etc.

[0134] As Figure 2 shown, different from the traditional IMS architecture, the IMS DC 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 the implementation of DC applications.

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

[0136] The functions of each network element in this IMS DC architecture are as follows:

[0137] P-CSCF: It is the entry node 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.

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

[0139] IMS-AGW: The IMS access gateway, mainly responsible for media plane interworking of the user-network interface.

[0140] HSS: The main database for IMS user subscriptions, responsible for managing user subscription data and location information of mobile users, and for storing the following main subscription information related to users: user identities (identity, ID), such as IMS private identity (IMPI), IMS public identity (IMPU), etc.; information related to user authentication; information on the S-CSCF where the user is registered; transparent data stored in the HSS by the AS, such as the call forwarding number of the UE, etc.

[0141] IMS AS: Generally refers to the server network element in the IMS network that processes upper-layer voice services, including the processing of basic audio and video services and supplementary services, etc. The AS can specifically include MMTel AS (processing basic audio and video services and supplementary services) and / or service centralization and continuity (SCC) AS (responsible for the signaling control of enhanced single radio voice call continuity (eSRVCC) and the called access domain selection). These two ASs can be set up independently or jointly.

[0142] DCSF: Provides the signaling control function for data channel control logic. DCSF supports the following functions: receiving event reports from the IMS AS and deciding whether to allow data channel services during the IMS session; managing the bootstrap 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 the data channel application (bootstrap) to the UE via the MF and / or media resource function (MRF) based on UE subscription; downloading data channel applications from the data channel application repository.

[0143] MF: Provide media resource management and forwarding of data channel media services. MF supports the following functions: manage data channel media resources under the control of the IMS AS (bootstrap and apply data channel resources if applicable); terminate the bootstrap data channel from the UE and forward the HTTP traffic between the UE and the DCSF via MDC1; anchor the application data channel in the P2P scenario if needed and forward the application data service from the UE to the UE; relay traffic on the application to person (A2P) / person to application (P2A) application data channel between the UE and the DC application server via MDC2.

[0144] NEF: Mainly used to support the openness of capabilities and events.

[0145] DCAS: Mainly used to provide services for DC-related applications.

[0146] In the embodiments of this application, the P-CSCF may also be referred to as the P-CSCF entity or the P-CSCF network element; the S-CSCF may also be referred to as the S-CSCF entity or the S-CSCF network element, and no limitation is made thereto.

[0147] 3. IMS basic registration process (which can also be called the IMS initial registration process)

[0148] The IMS basic registration process is initiated by the UE. After the UE initiates the IMS basic registration from power-on until the IMS basic registration is successful, the user has the basic call permission.

[0149] Figure 3 For the process schematic diagram of the IMS basic registration process, as Figure 3 shown, the IMS basic registration process is as follows:

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

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

[0152] Among them, the request address can be a component of the request line in the SIP register message, used to indicate the destination of the request, that is, the address of the registrar. One example: sip:c8.huawei.com.

[0153] The To can be used as the public identity identifier IMPU for registering users. It should be noted that the maximum length of the IMPU supported by the CSCF is a string of 127 characters. An example: If the user successfully registers, the registrar can know the public user identity sip:+8675520000001@c8.huawei.com.

[0154] The Contact can be used as the contact address for registering users. The Contact and the To can cooperate. If the registration is successful, the registrar can then route all subsequent request messages sent to the registered user to this address.

[0155] The Via can be used to save the path through which the request has passed, enabling the response to be returned according to the path of the request.

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

[0157] Method 1: The UE obtains the P-CSCF domain name and the 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.

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

[0159] Method 3: The IP address of the P-CSCF is directly configured on the UE.

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

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

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

[0163] Among them, when the P-CSCF forwards the SIP registration message, the P-CSCF will add the following header fields to the SIP registration message:

[0164] Path: The P-CSCF inserts this header into the SIP registration message and puts its own address in it to bring to the Registrar.

[0165] P-Visited-Network-ID: When the P-CSCF queries the local PACN table, it will preferentially use the home network identifier in this data table to fill in the P-Visited-Network-ID. If there is no home network identifier, it will fill in the identifier for obtaining the home network in the P-Visited-Network-ID header field, which is used to identify the current visited network information of the registered user to the home network of the registered user. The P-CSCF inserts this header into the SIP registration message and brings the network identifier of the visited network to the Registrar.

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

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

[0168] 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.

[0169] When the I-CSCF receives the SIP registration message, it first obtains the address or hostname of the P-CSCF from the Via and checks whether the address or hostname is in the Trusted Domain (TDMI) or the Local Domain Table (LDMI). If a record is found, it indicates that the user's current visited network is trusted and the I-CSCF allows the user to register; if no record is found, it indicates that the user's current visited network is not trusted and the I-CSCF directly returns a SIP response with a response code of 403, prompting "RequestFromUntrustedDomain" to reject the user's registration request.

[0170] After the I-CSCF determines that the user's visited network is trusted, it selects the HSS with the highest priority according to the setting of the "priority" parameter in the local IHSS (Peer HSS for I-CSCF) table; then it 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.

[0171] S304. The S304, HSS sends a User Authorization Answer (UAA) message to the I-CSCF. Correspondingly, the I-CSCF receives the UAA message from the HSS.

[0172] Upon receiving the UAR message, the HSS determines that the user is already subscribed according to the user subscription information in the local database, and then sends a UAA message to the I-CSCF, returning the address or capabilities set of the S-CSCF.

[0173] 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.

[0174] The I-CSCF selects a suitable S-CSCF based on the result returned by the HSS and forwards the SIP registration message to the S-CSCF. If the HSS returns a capabilities set of the S-CSCF, the I-CSCF queries the ISCAP (S-CSCF Capabilities for I-CSCF) table, selects an S-CSCF that meets the capabilities set requirements, and forwards the SIP registration message to the S-CSCF. The S-CSCF address is included in the Attribute Value Pair (AVP) of the S-CSCF capabilities set, and the I-CSCF directly forwards the SIP registration message to the S-CSCF.

[0175] 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.

[0176] The MAR message requests to obtain an Authorization Vector (AV) and notifies the HSS that the current S-CSCF is serving this user. The MAR message is basically the same as the AVP in the UAR message.

[0177] 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.

[0178] The MAA message includes an authentication quintuple, namely, the Expected Response (XRES), Random Number (RAND), authentication token (AUTN), integrity key (IK), and cipher key (CK). The AVP of the MAA message and the UAA message is basically the same, and no examples are given here.

[0179] S308. The S-CSCF sends a response message to the I-CSCF for the SIP registration message. Correspondingly, the I-CSCF receives the response message for the SIP registration message from the S-CSCF.

[0180] 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.

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

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

[0183] The P-CSCF extracts 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.

[0184] The response code of the response message for the SIP registration message in S308 to S310 above can be 401, so this response message can also be called a SIP 401 message.

[0185] S311. The UE verifies the network.

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

[0187] 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.

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

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

[0190] 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.

[0191] For the above S311 - S316, after the UE receives the SIP 401 message, it authenticates the AUTN based on the shared key stored in the local IMS subscriber identity module (ISIM). If the authentication is successful, it indicates that the SIP 401 message comes from the user's true home network. Then, it calculates the RES (Response) based on the shared key and RAND, reconstructs the SIP registration message, carries the RES, and sends it to the S-CSCF along the path of the initial SIP registration message.

[0192] S317. The network verifies the UE.

[0193] 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.

[0194] After the S-CSCF receives the authentication response, it compares the locally calculated XRES with the actually received authentication response RES. If the two match, the UE passes the network authentication. After the authentication is passed, the S-CSCF sends a SAR message to the HSS to request downloading the user's subscribed data.

[0195] 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.

[0196] The SAA message carries the user's subscribed data.

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

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

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

[0200] The response code of the response message of the SIP registration message in S320 - S322 above can be 200, so this response message can also be called a SIP 200 message. The S-CSCF feeds back a 200 (OK) response to the UE side, indicating successful registration. The key header field service route is carried in the message, containing the address of the S-CSCF. The P-CSCF saves the address of the S-CSCF for subsequent call routing. After successful registration, the relevant network elements will respectively save the information shown in Table 1 for message routing when the user acts as the caller or the callee subsequently.

[0201] Table 1

[0202] Network element Stored information UE P-CSCF address P-CSCF MPU, UE address, S-CSCF address I-CSCF No information stored S-CSCF MPU, user's subscribed data, HSS address, P-CSCF address, UE address HSS S-CSCF address, UE registration status

[0203] From Figure 3 it can be seen that the IMS registration process is initiated and completed by the terminal device based on SIP messages, and there can be interactions of non-SIP messages between the network elements in the IMS network.

[0204] 4. Third-party registration process

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

[0206] 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.

[0207] If the UE authentication is passed in S320 above and a 200 (OK) response is returned, the S-CSCF judges that there is initial filter criteria (iFC) data for the third-party registration request in the user subscription information downloaded from the HSS, and then sends a third-party registration request to the IMS AS according to the IMS AS address in the iFC. If there are multiple iFC data for the third-party registration request in the user subscription information, the S-CSCF will send them to the IMS AS addresses in the iFC in order from high to low priority.

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

[0209] Request-URI: The address of the IMS AS.

[0210] From: At this time, the S-CSCF acts as a third party to register the user's public user identity on behalf of the user. Therefore, the address of the S-CSCF is in the From header. The "tag" parameter in the From message is used to identify and distinguish a session.

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

[0212] Contact: It is 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.

[0213] 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.

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

[0215] 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.

[0216] The UDA message carries user data.

[0217] S404. The IMS AS sends an SNR message to the HSS. Correspondingly, the HSS receives the SNR message from the IMS AS.

[0218] S405. The HSS sends an SNA message to the IMS AS. Correspondingly, the IMS AS receives the SNA message from the HSS.

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

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

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

[0222] 5. IMS Re-registration Process

[0223] During the UE registration process, the UE negotiates the re-registration period with the network. The re-registration time is carried by the expires of the SIP register message, and this time range is defined by the "minimum registration duration" and "maximum registration duration" of the MOD SREG command on the CSC3300. During the re-registration period, the UE initiates the re-registration process. The behavior of the UE initiating re-registration is defined by Request for Comments (RFC) 3261 and 3GPP Technical Specification (TS) 24.229, which will not be elaborated here.

[0224] 6. Tombstone Mechanism and Push Function

[0225] When the application (APP) on the terminal device enters the background, the system records the current state of the application, just like recording an event on a tombstone, and then aborts the program and releases the resources it is using, including memory, central processing unit (CPU), etc. In this way, the application in the background will not compete for resources with the application in the foreground. When the application needs to resume to the foreground, according to the content on the "tombstone", the program is restored to the state before interruption. Such a mechanism is the "tombstone mechanism".

[0226] For an application in the tombstone state, the corresponding message push notification function can be provided through the configured push server. There is always a system-level long connection maintained between the push server and the operating system of the terminal device. This system-level long connection cannot be cancelled on the terminal device side. Once authorized to connect, a connection is initiated to the push server. Thus, the application server can send a push notification to the push server, and then the push server initiates a push to the application on the terminal device through this system-level long connection.

[0227] The above describes the push mechanism for non-DC applications. For IMS DC applications, in a scenario supporting multiple DC applications, if the above push mechanism for non-DC applications is not adopted, the terminal device needs to keep the DC applications in the background all the time. Each DC application maintains a system-level long connection, and multiple DC applications correspond to multiple long connections to send push messages to the DC applications. For a DC application in the tombstone state or a DC application with its background closed, the application server cannot connect to it and thus cannot send push messages, which will increase the power consumption cost of the terminal device for maintaining connections.

[0228] In addition, if the above-mentioned push mechanism for non-DC applications is adopted, since the coprocessor (CP) of the terminal device maintains a SIP basic connection based on Voice over LTE (VoLTE) / Voice over NR (VoNR) / IMS all the time after the terminal device is powered on and registered to the IMS network, the connection will be maintained all the time regardless of whether the user enables the traffic (it always maintains the signaling connection through the IMS APN QCI / 5QI = 5, anytime and anywhere). This will cause the terminal device to need to add a long connection to the push server through the application processor (AP) at the SIP long connection level maintained by the existing CP, thus also significantly increasing the power consumption of the terminal device.

[0229] It can be seen from this that how to provide a low-power push mechanism for DC applications in the tombstone mechanism or the closed state has become a technical problem to be solved urgently. For this reason, the embodiments of the present application provide a communication method and device, which can reduce the power consumption of the terminal device supporting multiple DC applications while enabling the DC applications to freely send and receive messages and notifications.

[0230] To better understand the embodiments of the present application, the following points are explained before introducing the embodiments of the present application.

[0231] First, in the embodiments of the present application, "for indicating" may include for directly indicating and for indirectly indicating. When it is described that a certain "indication information" is used to indicate A, it may include that the indication information directly indicates A or indirectly indicates A, and it does not mean that A must be carried in the indication information.

[0232] 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. For example, but not limited to, the information to be indicated can be directly indicated, such as the information to be indicated itself or the index of the information to be indicated, etc. It can also indirectly indicate the information to be indicated by indicating other information, where there is an association relationship between the other information and the information to be indicated. It can also only indicate a part of the information to be indicated, while the other parts of the information to be indicated are known or pre-agreed. For example, the indication of specific information can also be achieved by relying on the arrangement order of each information pre-agreed (such as protocol regulations), thereby reducing the indication overhead to a certain extent. At the same time, the common parts of each information can be identified and indicated uniformly to reduce the indication overhead caused by separately indicating the same information.

[0233] 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 their various combinations, etc. The specific details of various indication methods can refer to the prior art and will not be elaborated herein. As can be seen from the above description, for example, when multiple pieces of information of the same type need to be indicated, there may be a situation where the indication methods of different information are different. In the specific implementation process, the required indication method can be selected according to specific needs, and the embodiments of the present application do not limit the selected indication method. In this way, the indication methods involved in the embodiments 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.

[0234] The information to be indicated can be sent together as a whole or divided into multiple sub-information and sent separately, and the sending periods and / or sending opportunities of these sub-information can be the same or different. The specific sending method is not limited in the present application. Among them, the sending periods and / or sending opportunities of these sub-information can be predefined, such as predefined according to a protocol, or can be configured by the transmitting device by sending configuration information to the receiving device. Among them, the configuration information can include, for example but not limited to, 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).

[0235] Second, in the embodiments of the present application, the first, second, and various numerical numbers are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. For example, to distinguish different indication information. For another example, the first indication information and the second indication information are only for distinguishing different indication information and do not limit their order. Those skilled in the art can 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 to be different.

[0236] Third, in the embodiments of the present application, descriptions such as "when...", "in the case of...", "if", and "when" all refer to that in a certain objective situation, the device (such as a terminal device or an access network device) will perform corresponding processing, which is not to limit the time, and it is not required that the device (such as a terminal device or an access network device) must have a judgment action during implementation, nor does it mean that there are other limitations.

[0237] Meanwhile, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner for easy understanding.

[0238] Finally, the network architecture and service scenarios described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art will know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0239] Please refer to Figure 5 , Figure 5 which is a schematic diagram of an architecture of the communication system to which the embodiments of the present application are applied. As an example, as Figure 5 shown, the communication system can be applicable to the above IMSDC architecture. The communication system includes: a terminal device, a push server, and a server for DC applications. The three can communicate with each other pairwise. Among them, the push server is a server that cooperates with the operator network and the IMS network to provide message notification and application wake-up for the server for DC applications. Its function can be deployed as the IMS AS in the above IMSDC architecture, or can be deployed on the above DCSF, and no limitation is made thereto. The server for DC applications is an application server that provides services related to the corresponding DC applications and can be the DCAS in the above IMSDC architecture.

[0240] In the embodiments of the present application, the terminal device(s) may be one or more, such as the first terminal device, the second terminal device, the third terminal device, etc. The terminal device may be a terminal device with transceiver functions, or may also be a chip or a chip system disposed in the terminal device. The terminal device may also be referred to as a UE, an access terminal, a subscriber unit, a user station, a mobile station (MS), a mobile unit, 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 may be a mobile phone, a cellular phone, a smartphone, a tablet computer (Pad), a wireless data card, a personal digital assistant (PDA), a wireless modem, a handset, a laptop computer, a machine type communication (MTC) terminal, a computer with wireless transceiver functions, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a smart home device (such as a refrigerator, a television, an air conditioner, an electric meter, etc.), a smart robot, a robotic arm, a workshop device, a wireless terminal in self-driving, a wireless terminal in industrial control, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, a vehicle-mounted terminal, a road side unit (RSU) with terminal functions, etc., a flying device (such as a smart robot, a hot air balloon, a drone, an airplane), etc. The terminal device in the present application may also be an in-vehicle module, an in-vehicle module group, an in-vehicle component, an in-vehicle chip, or an in-vehicle 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, the terminal device may also be a device that serves as a terminal function in D2D communication.

[0241] Embodiments of this application do not limit the device form of the terminal. The device for implementing the functions of the terminal device can be the terminal device; it can also be a device capable of supporting the terminal device to implement this function, such as a chip system. This device can be installed in the terminal device or used in matching with the terminal device. In the embodiments of this application, the chip system can be composed of chips or can also include chips and other discrete devices.

[0242] It should be understood that Figure 5 The shown communication system may also include other functional entities or network elements, other terminal devices or other access network devices, etc., such as P-CSCF, S-CSCF, etc., which are not limited herein.

[0243] In addition, by way of example, embodiments of this application also provide a schematic diagram of the architecture for a terminal device to support DC services. Based on this architecture, the terminal device can wake up or launch a DC application to execute a push service, send a push registration request, etc. The specific implementation process can refer to the relevant descriptions in the following method embodiments, such as S704 and S700-1 to S700-2 below, which will not be elaborated herein.

[0244] Such as Figure 6 As shown, 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 can be modules preset by the terminal device at the factory. The DC application can be downloaded from the network side and executed during the system operation of the terminal device.

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

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

[0247] The DC operating environment module can also be called the DC Framework module and is used for the life cycle management of DC applications on the terminal device side (such as DC application switching, application background exit, multitasking, tombstone mechanism, etc.), and provides an application programming interface (API) for establishing DC to the upper layer DC.

[0248] The DC application corresponds to the DC application server and is an application program developed by developers. The DC application can also be called an IMSDC Web App, an IMSDC application, etc., and there is no limitation in this regard.

[0249] In addition, in the embodiments of the present application, the names of nodes, modules, devices, or network elements in different scenarios, architectures, or systems, as well as the names of communication interfaces between two of nodes, modules, devices, or network elements, are exemplarily given. There is no exclusion of the possibility of name changes in future communication systems, scenarios, or architectures.

[0250] Next, Figures 7 - 9 The communication method provided in the embodiments of the present application will be specifically described.

[0251] Exemplarily, Figure 7 is a schematic flowchart of a communication method provided in the embodiments of the present application. This communication method is described by taking the communication between the terminal device, the push server, and the DC application server shown in Figure 5 as an example. Of course, the entity performing the actions of the terminal device in this 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 entity performing the actions of the push server in this 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 entity performing the actions of the DC application server in this 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; there is no specific limitation in the embodiments of the present application.

[0252] The communication method provided in the embodiments of the present application is executed when the terminal device registers to the IMS network based on SIP messages (hereinafter referred to as the IMS network registration process), or is executed after this IMS network registration process. This IMS network registration process includes the IMS initial registration of the terminal device and / or the IMS re-registration of the terminal device. Among them, the IMS initial registration of the terminal device includes the registration interaction between the terminal device and the P-CSCF, and between the P-CSCF and the S-CSCF. It is the initial registration of the terminal device to the IMS based on SIP messages. This IMS network registration process is a necessary step for IMS voice calls. During this registration process, the terminal device completes authentication, authorization, etc. with the IMS network, so that in subsequent processes, the terminal device can initiate and receive calls, and perform the next paging process. Reference can be made to the above Figure 3The relevant descriptions in the IMS basic registration process shown are not elaborated here. Further, the IMS initial registration of the terminal device also includes registration between the S-CSCF and the IMS AS (third-party registration) to determine which IMS AS the terminal device is registered to, as described above. Figure 4 The relevant descriptions of the third-party registration process shown are not elaborated here.

[0253] The IMS reregistration of the terminal device can be periodic. The terminal device refreshes and maintains the connection with the network through periodic registration with the IMS network. The IMS reregistration process can refer to the reregistration process defined in RFC3261 and 3GPP TS24.229, which is not elaborated here.

[0254] In a 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 further includes 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) according to the default user subscription to indicate which IMS AS the terminal device is registered to. 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 indicate that the terminal device is registered to 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 referred to as a third-party registration message, a registration notification message, etc., which is not limited herein.

[0255] Thus, after the terminal device completes IMS network registration or reregistration based on SIP messages, a SIP long connection is established and maintained with the IMS network. The SIP long connection is mainly used for calls and can also be used for rich communication suite (RCS), etc. The communication method provided in the embodiments of the present application completes the push service of the DC application by multiplexing the SIP long connection.

[0256] Exemplarily, as Figure 7 shown, the communication method includes:

[0257] S701. The server of the DC application obtains a first notification message.

[0258] 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.

[0259] The server of the DC application refers to the application server that provides DC application services, and can be referred to as DCAS, the server corresponding to the DC application, the DC application server, etc., which is not limited herein.

[0260] The push registration information is used to indicate the registration information obtained by the terminal device for completing the push notification service registration corresponding to the DC application, and can be used by the server of the DC application to initiate a push service. Or rather, the push registration information is information for initiating a push service for the DC application, DC application service registration information, DC application push information, etc., and there is no limitation on this. That is to say, the server of the DC application can obtain the registration information related to the push service of the DC application of the terminal device through the first notification message for subsequent initiating a push notification for the DC application on the terminal device.

[0261] In the embodiments of the present application, the push registration information may include at least one of the following: the identifier of the terminal device, the identifier of the DC application, the token and / or the 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., and 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. 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 legality 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 valid duration of the token, indicating how long the token is valid, or after which time point the token is invalid.

[0262] The push registration information can be sent by the terminal device to the server of the DC application. In a possible implementation, the server of the DC application establishes a DC bearer channel with the terminal device and receives the first notification message through the DC bearer channel. That is to say, the terminal device and the server of the DC application establish a DC bearer channel, and the terminal device can send the first notification message through this DC bearer channel. Correspondingly, the server of the DC application can receive the first notification message through this DC bearer channel.

[0263] Exemplarily, after the terminal device obtains the push registration information, it negotiates with the server of the DC application through the P-CSCF, S-CSCF, MF, etc. to establish a DC A2P channel, and sends the push registration information to the server of the DC application based on the established DC A2P channel. For example, if the first notification message is an HTTP message, the terminal device can send the first notification message to the IMS-AGW on the network edge side through the DC A2P channel, and the IMS-AGW forwards it to the MF. The MF checks the first notification message of the HTTP type that needs to proxy the 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 that it has obtained the push registration information.

[0264] Among them, for the specific process of the terminal device obtaining the push registration information, reference can be made to the relevant descriptions in the following push registration process of the DC application, which will not be elaborated here.

[0265] In a possible implementation, the push registration information can be carried in the first notification message after integrity protection. For example, the integrity protection can be in the form of JWT (JSON Web Token). The push registration information is digitally signed and then carried in the first notification message to securely transmit the push registration information.

[0266] Optionally, the first notification message can also include the location information of the push server. For example, the location information of the push server can 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 server of the DC application can accurately access the push server and initiate a push notification.

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

[0268] S702. 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. Correspondingly, the push server receives the first push message from the server of the DC application.

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

[0270] 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 a 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, and the push notification is used to indicate the specific content of this push. That is to say, in the case where it is determined that a push needs to be initiated to the DC application, the server of the DC application may, according to the stored push registration information corresponding to the DC application, such as the identifier of the terminal device where the DC application is located and / or the identifier of the DC application, carry and send it in the first push message.

[0271] Optionally, the push registration information may further include a token and / or the expiration time of the token. To ensure the legality and security of the push, the first push message may further include the token and / or the expiration time of the token, which is used to authenticate the push notification.

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

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

[0274] Among them, the first SIP message is used to send a push notification to the DC application.

[0275] In the embodiments of the present application, after the push server obtains the first push message, it can authenticate the first push message. In one possible implementation, the push server can authenticate the first push message according to the push registration information. When the authentication of the first push message passes, the push server triggers the first SIP message according to 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 to determine whether the identifiers are consistent and whether the token information is consistent, so as to realize the authentication of the first push message. For the push registration information stored by the push server, 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 according to the stored identifier of the terminal device, the identifier of the DC application and the third-party registration information, etc., and verifies the legality of the message to ensure the reliability of the message.

[0276] In one possible scenario 1, the push server is deployed as an IMS AS. At this time, after the push server completes the authentication of the first push message, it can directly generate and send the first SIP message.

[0277] In one 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 the first SIP message to send a push notification to the DC application on the terminal device. In one possible implementation, the push server sends a second push message to the IMS AS according to 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 to send the first SIP message to the DC application. For example, the second push message can be an HTTP message. In some possible cases, the second push message can also be the first push message, and this is not limited.

[0278] The first SIP message may include the identifier of the terminal device, the identifier of the DC application, and / or the push notification. Optionally, the identifier of the terminal device, the identifier of the DC application, and / or the push notification may also be carried in the first SIP message after integrity protection, such as carried in the header field of the first SIP message. For example, a p-dc-app-push-service header field is added to the SIP message to carry the information after integrity protection. The integrity protection can adopt the above-mentioned JWT method.

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

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

[0281] Furthermore, the first SIP message is sent to the terminal device by a network element in the IMS network. Exemplarily, the first SIP message is sent from the IMS AS to the S-CSCF, then routed by the S-CSCF to the P-CSCF, and further routed by the P-SCSF to the terminal device to send a push notification for 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 the SIP ISC interface or the Restful interface.

[0282] In a possible implementation, the first SIP message may be a SIP notify message. This SIP notify message may be an in-SIP-session message (a SIP session has multiple applications), or an out-of-SIP-session message (for SADC). In addition, the first SIP message may also be other SIP messages, such as SIP request messages, SIP Info / Option / Message messages, etc., which are not limited herein.

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

[0284] Specifically, the terminal device may wake up or launch 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.

[0285] Exemplarily, after the terminal device obtains the first SIP message, if the information carried in the first SIP message is integrity protected, the terminal device may decrypt the integrity protected information, and then authenticate the parsed information using the stored push registration information, such as whether the token is valid and whether the token is correct. In the case of passing the authentication, the corresponding DC application is woken up or launched to the foreground according to the identifier of the DC application, and the specific content of the push notification in the first SIP message is sent to the DC application.

[0286] In Figure 6 Under the architecture of the terminal device shown, after the SIP module of the terminal device receives the first SIP message, it parses the first SIP message to obtain the push notification, calls the interface to notify the DC runtime environment module, and then the DC runtime environment module wakes up or launches the corresponding DC application to the foreground. After the DC application is launched, the DC runtime environment module sends the push notification to the DC application.

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

[0288] According to the solution provided in this application, the push server may reuse the existing SIP long connection established based on a call, and send a push message to a DC application in a closed state or tombstone state through a SIP message, without adding a system-level long connection to implement message push. This can not only reduce the complexity of the connection of the terminal device to reduce the power consumption of the terminal device, but also enable the DC application to receive and send messages or notifications in a timely and flexible manner.

[0289] The above describes the process of the server of the DC application initiating a push for the DC application. Before initiating the push, the communication method provided in the embodiments of this application may further include a push registration process for the DC application, which may include the following steps:

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

[0291] The second SIP message is a SIP request message for the terminal device to initiate the registration of the push notification service of the DC application, such as the second SIP message is used to request the 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 may also be carried in the header field of the second SIP message after integrity protection, such as adding a p-dc-app-push-service header field to carry the information after integrity protection, and the integrity protection may adopt the JWT method as described above.

[0292] In the architecture of the terminal device shown above Figure 6 When the terminal device opens the DC application, the DC application may call the API of the DC runtime environment module to initiate the registration of the push notification service. When calling the API, the identifier of the terminal device and the identifier of the DC application are provided, so that after being awakened by the DC runtime environment module, the underlying API is continuously called, and a scheduling is initiated to the SIP module, and then the SIP module generates and sends the second SIP message.

[0293] In the scenario where the push server is deployed as an IMS AS, the second SIP message can be the first registration message. Exemplarily, the terminal device can send the second SIP message to the P-CSCF in the IMS network. The P-CSCF routes the second SIP message to the S-CSCF, and then the S-CSCF routes it to the push server deployed as an IMS AS. For example, the S-CSCF sends the second SIP message to the IMS AS according to 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 identifier of the terminal device and / or the identifier of the DC application, generates a token and / or the expiration time of the token 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 identifier of the terminal device, the identifier of the DC application, the token, and / or the expiration time of the token, etc.

[0294] In the scenario where the push server is deployed in 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 of the terminal device is routed through the P-CSCF and the S-CSCF to the IMS AS, the IMS AS reports the registration information in the second SIP message to the push server deployed in the DCSF in the form of an event notification according to the user's default subscription rules. For example, the first registration message is an HTTP message, and the first registration message is used to request the registration of the push notification service for the DC application. The first registration message includes the registration information in the second SIP message, such as the identifier of the terminal device and / or the identifier of the DC application.

[0295] In this scenario, in one possible implementation, the identifier of the terminal device and / or the identifier of the DC application can also be sent in the first registration message after integrity protection.

[0296] Thus, the push server registers the push notification service for the DC application on the terminal device according to the first registration message, for example, stores the push registration information to facilitate subsequent push services for the DC application. Further, the push server can feedback a response message corresponding to the first registration message carrying the push registration information to indicate that the registration of the push notification service for the DC application is completed, such as executing S700-2 below.

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

[0298] Among them, the registration response corresponding to the first registration message is used to indicate the completion of the push notification service registration of the DC application. 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 identifier of the terminal device, the identifier of the DC application, the token, and / or the expiration time of the token.

[0299] In a possible implementation, the push registration information may be sent in the registration response corresponding to the first registration message after integrity protection.

[0300] Optionally, the registration response corresponding to the first registration message may further include the location information of the push server. That is to say, the push server may also inform the DC application corresponding to the identifier of the DC application of the location information of its associated application server (i.e., the server of the DC application) for subsequent execution of the push service. Optionally, the location information of the push server may also be sent in the registration response corresponding to the first registration message after integrity protection.

[0301] In the scenario where the push server is deployed as an IMS AS, the registration response corresponding to the first registration message may be the third SIP message, as the SIP response message corresponding to the second SIP message. Similar to the transmission method of the second SIP message, after the push server deployed as an IMS AS completes the push notification service registration of the DC application, it sends the registration response (the third SIP message) corresponding to the first registration message to the S-CSCF, and then the S-CSCF routes it to the P-CSCF, and then the P-CSCF routes it to the terminal device. At this time, the response message corresponding to the first registration message or the third SIP message may be a SIP response message with a response code of 200 (which can be called SIP20). That is to say, the push server deployed as an IMS AS feeds back the push registration information through SIP messages.

[0302] In the scenario where the push server is deployed in the 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 push registration information is carried in the response message corresponding to the first registration message. Different from the above scenario, the push server deployed in the DCSF sends the response message corresponding to the first registration message to the IMS AS to trigger the IMS AS to send the third SIP message, and the third SIP message is used to indicate the completion of the push notification service registration of the DC application. The third SIP message includes the push registration information. That is to say, the IMS AS converts the first registration message into a SIP message to send the push registration information. For example, the IMS AS routes the push registration information to the terminal device in the form of SIP signaling through the S-CSCF and the P-CSCF in turn as described in the above scenario. At this time, the third SIP message is used as the response message corresponding to the above second SIP message, such as SIP 200.

[0303] Thus, after receiving the third SIP message, the terminal device can determine that the registration of the push notification service for the corresponding DC application has been completed, and parse the push registration information from the third SIP message. Optionally, the third SIP message may further include the location information of the push server.

[0304] Furthermore, after obtaining the push registration information, the terminal device can inform the DC application server of the push registration information, so that the DC application server can provide push services for the DC applications on the terminal device subsequently.

[0305] In a possible design, after obtaining the push registration information, the terminal device can establish a DC bearer channel with the DC application server to send the push registration information to the DC application server through the DC bearer channel, such as sending the first notification message through the DC bearer channel in S701 above. In other words, the terminal device can establish a DC bearer channel with the DC application server triggered by the third SIP message, that is, the terminal device responds to the third SIP message and establishes a DC bearer channel with the DC application server.

[0306] Similarly, in the architecture of the terminal device shown above Figure 6 the SIP module in the terminal device receives the third SIP message, and then layer by layer calls the API response interface of the SIP module to inform the DC application of the push registration information. When sending the push registration information to the DC application server, the DC application calls the API of the DC runtime environment module to initiate a notification process to the DC application server, and then the DC runtime environment module establishes a DC bearer channel and triggers the DC module to send the first notification message based on the established DC bearer channel.

[0307] In the push registration process of the above DC application, in a possible implementation, the second SIP message can also be a SIP notify message, and this SIP notify message can be a SIP in-session message (there are multiple applications in one SIP session), or a SIP out-of-session message (for SADC). In addition, the second SIP message can also be other SIP messages, such as SIP request messages, SIP registration messages, SIP Info / Option / Message, etc., which are not limited here.

[0308] Thus, Figure 6The communication method shown, based on the IMS network characteristics, on the basis of the existing SIP long connection established for a call, multiplexes this SIP long connection, completes the push registration of the DC application through SIP messages, and sends push notifications for the DC application in the closed state or tombstone state through SIP messages. This can not only reduce the complexity of the connection of the terminal device to reduce the power consumption of the terminal device, but also enable the DC application to receive and send messages or notifications in a timely and flexible manner.

[0309] It should be understood that in the embodiments of this application, the newly added functions of the multiplexed SIP messages can be indicated by setting indication information in the SIP messages. For example, if the third SIP message multiplexes the SIP notification message, an information for indicating the completion of the push notification service registration of the DC application can be newly added to the SIP notification message. There is no limitation on this.

[0310] The following will describe in detail the above Figure 7 shown communication method in combination with the IMS DC architecture. Taking the terminal device as the UE, the push server is deployed as the IMS AS, and the server of the DC application is the DCAS as an example, as Figure 8 shown, is a schematic flowchart of a communication method provided by an embodiment of this application. The communication method includes:

[0311] S800, The IMS network registration process between the UE, the P-CSCF, the S-CSCF, and the IMS AS based on SIP messages.

[0312] After the UE completes the IMS network registration, the SIP connection established with the IMS network is kept all the time, which is mainly used for IMS voice calls. The specific implementation process can refer to the relevant descriptions in the above Figures 3 - 5 shown IMS network registration and re-registration processes, and details are not described here.

[0313] S801, The DC application in the UE sends a push session establishment (CreatePush Session) message to the SIP module through the DC runtime environment module. Correspondingly, the SIP module receives the push session establishment message from the DC application through the DC runtime environment module.

[0314] After the UE opens the DC application, it calls the API of the DC runtime environment module, and sends a push session establishment message to the DC runtime environment module through this API for the registration of the push notification service. The push session establishment message includes the UE ID and the DC application ID. In a possible implementation, the identifier of the UE can be replaced by the DC runtime environment ID. At this time, the DC runtime environment module is awakened and continues to call the underlying API to send this push session establishment message to the SIP module. Then, the SIP module generates and sends a SIP notification message #1 according to this push session establishment message, as described in S802 below.

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

[0316] Among them, the SIP Notify message #1 is used to request to register the push notification service of the DC application. The SIP Notify message #1 includes information for indicating the registration of the push notification service, the UE ID, and the DC application ID. To ensure the security of the information, the SIP module can carry the UE ID and the DC application ID in the header field of the SIP Notify message #1 after digital signature through JWT.

[0317] Optionally, the SIP Notify message #1 can be an in-SIP-session message or an out-of-SIP-session message, and there is no limitation on this.

[0318] For the specific implementation processes of the above S801 and S802, reference can be made to the relevant descriptions in the above S700-1, and details are not elaborated here.

[0319] S803. The P-CSCF sends the SIP Notify message #1 to the IMS AS through the S-CSCF. Correspondingly, the IMS AS receives the SIP Notify message #1 from the P-CSCF through the S-CSCF.

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

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

[0322] After the IMS AS receives the SIP notification message #1, it parses the SIP notification message #1 to obtain the UE ID and the DC application ID, and can authenticate the UE's information based on the third-party registration information. In the case of successful authentication, it registers the push notification service for the DC application of the UE, generates a token and the expiration time of the token, and sends SIP 200#1 to return the push registration information. SIP 200#1 is used to indicate that the push notification service registration of the DC application is completed, and this SIP 200#1 is routed to the P-CSCF through the S-CSCF. Among them, SIP 200#1 includes the UE ID, the DC application ID, the token, and the expiration time of the token. Optionally, SIP200#1 can also include the URL of the IMS AS.

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

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

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

[0326] S806. The SIP module sends a push session establishment response (CreatPushSession response) message to the DC application through the DC runtime environment module. Correspondingly, the DC application receives the push session establishment response message from the SIP module through the DC runtime environment module.

[0327] After the SIP module receives SIP 200#1, it calls the API response interface, converts SIP 200#1 into a push session establishment response message, and notifies the DC application through the DC runtime environment module that its push notification service registration is completed, and obtains and stores the UE ID, the DC application ID, the token, the expiration time of the token, and the URL of the IMS AS.

[0328] The specific implementation processes of the above S804 - S806 can refer to the relevant descriptions of the above S700-2, which will not be elaborated here.

[0329] S807. The DC application sends a push token notification (Push TokenNotify) message to the DC runtime environment module. Correspondingly, the DC runtime environment module receives the push token notification message from the DC application.

[0330] After the DC application obtains the information related to the registration of the push notification service, it can send a push token notification message to the DC operating environment module to inform the DC application corresponding to the DCAS of the push registration information to complete the subsequent push service. Among them, the push token notification message includes the UE ID, DC application ID, token, and the expiration time of the token. Optionally, the push token notification message may also include the URL of the IMSAS.

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

[0332] 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 refer to the relevant descriptions in the existing implementation methods and will not be elaborated here.

[0333] 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.

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

[0335] The specific implementation of the HTTP request message #1 can refer to the relevant descriptions of the above first notification message and will not be elaborated here.

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

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

[0338] 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.

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

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

[0341] If the MF check requires the HTTP messages of the proxy user, the outer layer of the DC is removed, and an HTTP request message #1 is sent to the DCAS as an HTTP Client to inform the DCAS of the push registration information of the corresponding DC application, so as to complete the subsequent push service.

[0342] S813. The DCAS stores the push registration information.

[0343] The DCAS parses the HTTP request message #1 and stores the UE ID, DC application ID, token, expiration time of the token, and the URL of the IMS AS. Optionally, the URL of the IMS AS can be pre-stored in the DCAS. At this time, the above HTTP request message may not carry the URL of the IMS AS.

[0344] S814. The DCAS sends an HTTP response message #1 to the UE. Correspondingly, the UE receives the HTTP response message #1 from the DCAS.

[0345] After the DCAS stores the push registration information of the DC application, it can send an HTTP response message #1 to the UE to inform it that the acquisition of the push registration information is successful. After that, the DCAS can send messages or notifications to the DC applications on the UE that are in the foreground or background through the DC A2P channel.

[0346] S815. The DCAS sends an HTTP request message #2 to the IMS AS. Correspondingly, the IMS AS receives the HTTP request message #2 from the DCAS.

[0347] When the DC application on the UE is closed due to certain operations or enters the tombstone state and cannot receive messages and respond, resulting in the DCAS not receiving responses from the DC application for a long time. At this time, the DCAS can send an HTTP request message #2 to the IMS AS according to the URL of the IMS AS for sending a push notification to the DC application, and the push notification can be content of interest to the UE. Among them, the HTTP request message #2 may include the UE ID, DC application ID, token, expiration time of the token, and push notification.

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

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

[0350] After the IMS AS obtains the HTTP request message #2, it parses the HTTP request message #2 and authenticates the HTTP request message #2 based on the third-party registration information of the UE, etc. In the case of an authentication channel, it sends a SIP notification message #2 to the S-CSCF for sending a push notification to the DC application, and then the S-CSCF routes the SIP notification message #2 to the P-CSCF. Among them, the SIP notification message #2 includes the UE ID, DC application ID, token, expiration time of the token, and push notification.

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

[0352] For the specific implementation process of S816, reference can be made to the relevant description in S703 above, which will not be elaborated here.

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

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

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

[0356] 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 up the DC application in the closed or tombstone state to the foreground.

[0357] S819. The DC runtime environment module sends a push notification to the DC application.

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

[0359] In Figure 8 In the scenario shown, the push server is deployed as the IMS AS in the IMS network, and the SIP connection used for IMS voice calls is reused for the push service registration and push service provision of the DC application, which can reduce the complexity of the UE connection and thus reduce power consumption.

[0360] Exemplarily, taking the terminal device as a UE, the push server is deployed in the DCSF, and the server of the DC application is the DCAS as an example, as Figure 9 shown, a schematic flowchart of a communication method provided by an embodiment of the present application, the communication method includes:

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

[0362] For the specific implementation process of S900-1, reference can be made to the relevant description in S800 above, which will not be elaborated here.

[0363] 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.

[0364] Among them, the third-party registration message is used to indicate that the UE is registered on the IMS AS. For the specific implementation of the third-party registration message, reference can be made to the relevant description of the second registration message above, which will not be elaborated here.

[0365] S901. The DC application in the UE sends a Push Session Establishment (CreatPush Session) message to the SIP module through the DC runtime environment module. Correspondingly, the SIP module receives the push session establishment message from the DC application through the DC runtime environment module.

[0366] 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.

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

[0368] For the specific implementation processes of S901 to S903, reference can be made to the relevant descriptions in S801 to S803 above, which will not be elaborated here.

[0369] 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.

[0370] After the IMS AS receives the SIP notification message #1, it will report the push session registration information in the SIP notification message #1 to the push server in the form of an event notification according to the user's default subscription rules, such as the HTTP request message #3 to the push server, to request the push notification service for registering the DC application. Among them, the HTTP request message #3 includes the UE ID and the DC application ID. To ensure information security, the UE ID and the DC application ID can also be digitally signed through JWT and carried in the HTTP request message #3 for sending.

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

[0372] Among them, the HTTP response message #3 is used to indicate that the DC application has completed the registration of the push notification service.

[0373] After the push server receives the HTTP response message #3, it parses the HTTP response message #3 to obtain the UE ID and the DC application ID, and can authenticate the UE's information according to the third-party registration information. If the authentication passes, it registers the push notification service for the DC application of the UE, generates a token and the expiration time of the token, and sends the HTTP response message #3 to return the push registration information. The HTTP response message #3 includes the UE ID, the DC application ID, the token, and the expiration time of the token. Optionally, the HTTP response message #3 can also include the URL of the IMS AS.

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

[0375] After the IMS AS receives the HTTP response message #3, it can also authenticate the HTTP response message #3 according to the third-party registration information. If the authentication passes, it sends SIP 200#1, which is used to indicate that the DC application has completed the registration of the push notification service.

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

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

[0378] For the specific implementation process of S906, refer to the relevant description in S804 above, which will not be elaborated here.

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

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

[0381] S909. The DC application sends a push token notification message to the DC operating environment module. Correspondingly, the DC operating environment module receives the push token notification message from the DC application.

[0382] S910. The DC operating environment module establishes a DCA2P channel with the DCAS.

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

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

[0385] 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.

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

[0387] S915. The DCAS stores the push registration information.

[0388] S916. The DCAS sends an HTTP response message #1 to the UE. Correspondingly, the UE receives the HTTP response message #1 from the DCAS.

[0389] S917. The DCAS sends an HTTP request message #2 to the push server. Correspondingly, the push server receives the HTTP request message #2 from the DCAS.

[0390] For the specific implementation processes of S907 to S917, reference may be made to the relevant descriptions in S805 to S815 above, which will not be elaborated here.

[0391] 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.

[0392] After receiving HTTP request message #2, the push server may also authenticate HTTP request message #2 based on the third-party registration information and the push registration information. If the authentication is passed, it sends HTTP request message #2 to the IMS AS.

[0393] S919. The IMS AS sends SIP notification message #2 to the P-CSCF via the S-CSCF. Correspondingly, the P-CSCF receives SIP notification message #2 from the IMS AS via the S-CSCF.

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

[0395] S921. The SIP module notifies the DC operating environment module to wake up the DC application.

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

[0397] For the specific implementation processes of S919 to S922, reference may be made to the relevant descriptions in S816 to S819 above, which will not be elaborated here.

[0398] In Figure 9 In the scenario shown, the push server is deployed on the DCSF, reusing the SIP connection for IMS voice calls to register for the push service of the DC application, and the DCSF triggers the IMS AS to reuse the SIP connection for IMS voice calls to provide the push service, which can reduce the complexity of the UE connection and thus reduce power consumption.

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

[0400] The above mainly introduces the solution provided by this application. Correspondingly, this application also provides a communication device, which is used to implement various methods in the above method embodiments. The communication device can be the push server in the above method embodiments, or a device including the push server, or a component applicable to the push server, such as a chip or a chip system. Or, the communication device can be the terminal device in the above method embodiments, or a device including the terminal device, or a component applicable to the terminal device, such as a chip or a chip system. Or, the communication device can be the server for DC applications in the above method embodiments, or a device including the server for DC applications, or a component applicable to the server for DC applications, such as a chip or a chip system.

[0401] In some embodiments, in order to implement the above functions, the communication device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily realize that, combining the units and algorithm steps of each example described in the embodiments disclosed herein, this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving the hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

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

[0403] Taking the communication device as the push server or the terminal device or the server for DC applications in the above method embodiments as an example, Figure 10 is a schematic structural diagram of a communication device provided by the embodiments of this application. As Figure 10 shown, the communication device 1000 includes: a processing module 1001 and a transceiver module 1002. Among them, the processing module 1001 is used to execute the processing functions of the push server or the terminal device or the server for DC applications in the above method embodiments. The transceiver module 1002 is used to execute the transceiver functions of the push server or the terminal device or the server for DC applications in the above method embodiments.

[0404] Among them, all relevant content of each step involved in the above method embodiments can be cited in the function descriptions of the corresponding functional modules, and will not be elaborated here.

[0405] Since the communication device 1000 provided in this embodiment can execute the above method, the technical effects it can obtain can refer to the above method embodiments, and will not be elaborated here.

[0406] In a possible design solution, in the embodiments of the present application, the transceiver module 1002 may include a receiving module and a transmitting module ( Figure 10 not shown in the figure). Among them, the transmitting module and the receiving module are respectively used to implement the transmitting function and the receiving function of the communication device 1000.

[0407] In a possible design solution, the communication device 1000 may further include a storage module ( Figure 10 not shown in the figure), and this storage module stores programs or instructions. When the processing module 1001 executes this program or instruction, the communication device 1000 can execute Figures 7 - 9 the functions of the push server or the terminal device or the server of the DC application in any of the methods shown in the figure.

[0408] In some embodiments, the processing module 1001 involved in the communication device 1000 may be implemented by a processor or processor-related circuit components, and may be a processor or a processing unit; the transceiver module 1002 may be implemented by a transceiver or transceiver-related circuit components, and may be a transceiver or a transceiver unit.

[0409] Exemplarily, Figure 11 is a schematic structural diagram of another communication device provided in the embodiments of the present application. This communication device may be the push server or the terminal device or the server of the DC application in the above method embodiments, or may be a chip (system) or other components or assemblies that can be set in the push server or the terminal device or the server of the DC application. As Figure 11 shown, the communication device 1100 may include a processor 1101. In a possible design solution, the communication device 1100 may further include a memory 1102 and / or a transceiver 1103. Among them, the processor 1101 is coupled to the memory 1102 and the transceiver 1103, and may be connected through a communication bus, for example.

[0410] Next, in combination with Figure 11 each component of the communication device 1100 will be specifically introduced:

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

[0412] In a possible design solution, the processor 1101 can 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.

[0413] In a specific implementation, as an embodiment, the processor 1101 can include one or more CPUs. For example Figure 11 the CPU0 and CPU1 shown in

[0414] In a specific implementation, as an embodiment, the communication device 1100 can also include multiple processors. For example Figure 11 the processor 1101 and the processor 1104 shown in

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

[0416] In a 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 may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium, or other magnetic storage device, or any other medium that can be used to carry or store the 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 may exist independently and be coupled to the processor 1101 through the interface circuit of the communication device 1100 ( Figure 11 not shown in the figure), and the embodiments of the present application do not make specific limitations on this.

[0417] The transceiver 1103 is used for communication with other communication devices. For example, when the communication device 1100 is a terminal device, the transceiver 1103 can be used to communicate with an access network device or with another terminal device. Another example is that when the communication device 1100 is a network device, the transceiver 1103 can be used to communicate with a terminal device or with another network device.

[0418] In a possible design, the transceiver 1103 may include a receiver and a transmitter ( Figure 11 not shown separately). Among them, the receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0419] In a possible design, the transceiver 1103 may be integrated with the processor 1101 or may exist independently and be coupled to the processor 1101 through the interface circuit of the communication device 1100 ( Figure 11 not shown in the figure), and the embodiments of the present application do not make specific limitations on this.

[0420] It should be noted that Figure 11 the structure of the communication device 1100 shown in the figure does not constitute a limitation on the communication device. The actual communication device may include more or fewer components than shown in the figure, or combine certain components, or have a different component layout.

[0421] In addition, for the technical effects of the communication device 1100, reference may be made to the technical effects of the method described in the foregoing method embodiments, which will not be elaborated herein.

[0422] An embodiment of this application also 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 foregoing method embodiments are implemented.

[0423] An embodiment of this application also provides a computer program product, which implements the functions of the foregoing method embodiments when executed by a computer.

[0424] In the foregoing embodiments, all or part of them may be implemented by software, hardware, firmware, or any combination thereof. When implemented using a software program, all or part of it may 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, the processes or functions according to the embodiments of this application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired manner (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or a wireless manner (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more media integrated therein. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0425] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician may use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0426] Those skilled in the art can clearly understand that for the sake of convenience and brevity of description, the specific working processes of the systems, devices, and units described above may refer to the corresponding processes in the foregoing method embodiments, which will not be elaborated herein.

[0427] In several embodiments provided by the present 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 illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, 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 displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in electrical, mechanical, or other forms.

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

[0429] In addition, in each embodiment of the present application, each functional unit can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0430] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable 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 methods described in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, ROM, random access memory RAM, magnetic disks, or optical discs that can store program codes.

[0431] Although the present application has been described in conjunction with various embodiments herein, however, in the process of implementing the claimed present application, those skilled in the art can understand and implement other variations of the disclosed embodiments by viewing the drawings, the disclosure content, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "one" does not exclude a plurality of cases. A single processor or other unit can implement several functions listed in the claims. Certain measures are recited in mutually different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0432] Although the present application has been described in connection with specific features and their embodiments, it will be apparent that various modifications and combinations can be made thereto without departing from the spirit and scope of the present application. Accordingly, the present specification and the drawings are merely exemplary illustrations of the present application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of the present application. Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these changes and modifications.

Claims

1. 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 Session Initiation Protocol (SIP) messages, the method includes: Receiving a first push message from a server of a Data Channel (DC) application, the first push message being 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, the first SIP message being 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, the first registration message being 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, wherein 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, the push registration information including the identifier of the terminal device, the identifier of the DC application, a token, and / or an expiration time of the token, the token being used to authenticate the push notification.

5. The method according to claim 4, wherein The triggering of the first SIP message according to the first push message includes: Authenticating the first push message according to the push registration information; In the case where the authentication of the first push message passes, triggering the first SIP message according to the first push message.

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 of a terminal device registering 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, the second registration message being used to indicate that the terminal device registers to the IMS AS.

9. The method according to claim 8, characterized in that, The triggering of 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, the second push message being used to request sending the first SIP message to the DC application.

10. The method according to claim 9, characterized in that, 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, the token being 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, the token being used to authenticate the push notification.

14. 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 Session Initiation Protocol (SIP) messages, the method includes: Receiving a first SIP message, the first SIP message being 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, wherein 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, characterized in that, 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, wherein 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; When it is necessary to initiate a push to the DC application, sending a first push message to the 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 situation of needing 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, It 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