Communication method and device

Abstract

The invention discloses a communication method and device, which are used for guaranteeing the security when a rendering entity requests a digital human model from a BAR network element in a digital human related call. In the application, the method comprises the following steps: a first terminal sends a capability negotiation request, the capability negotiation request carries an identifier of a first digital person, and the capability negotiation request is used for negotiating rendering of the first digital person. The first terminal receives a capability negotiation response, the capability negotiation response comprises information of a first entity, the first entity is an entity used for downloading a first digital human model, and the first digital human model is used for rendering the first digital human. The first terminal generates a token according to the information of the first entity, and the token is used for authorizing the first entity to download the first digital human model.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of wireless communication, and in particular, to a communication method and apparatus. Background Art

[0002] A digital human is a virtual human image with a digitalized appearance, and is displayed by relying on a display device. For example, the display effect can be presented through devices such as a mobile phone, a television, augmented reality (AR) technology, or virtual reality (VR) glasses. Exemplarily, Figure 1 FIG. 1 is a schematic diagram of a scenario related to a digital human call. The first terminal can be used as a collection end to collect user information of user a and provide it to a rendering entity. The rendering entity generates video frames according to the user information of user a and the digital human model corresponding to the first terminal. The video frames include the digital human corresponding to user a, and the video frames are displayed on the second terminal so that user b of the second terminal can see the digital human corresponding to user a. The rendering entity can be the first terminal, the second terminal, or a network device (such as a media function (MF) network element). Among them, the user information can specifically be action information, language information, expression information, text information, etc.

[0003] Obtaining the security of the digital human model is an issue worthy of attention. Summary of the Invention

[0004] The present application provides a communication method and apparatus for ensuring the security of the digital human model.

[0005] In a first aspect, the present application provides a communication method, which can be executed by a first communication device. The first communication device can be the first terminal or a part of the first terminal (for example, a chip in the first terminal).

[0006] When the first communication device is the first terminal, for example, the first communication device can send information to a data channel application server (DC AS), or the first communication device can receive information from the DC AS. When the first communication device is a module in the first terminal, the first communication device can send information to other modules in the first terminal (such as a radio frequency module or an antenna). For example, the information is sent by the first terminal to the DC AS; or the first communication device can receive information from other modules (such as a radio frequency module or an antenna). For example, the information is sent by the DC AS to the first terminal.

[0007] For ease of description, the following takes the first communication device being the first terminal as an example for illustration.

[0008] The method is applied to the scenario where a first terminal and a second terminal conduct a digital human-related call. The method includes:

[0009] The first terminal sends a capability negotiation request, which carries the identifier of the first digital human. The capability negotiation request is used to negotiate the rendering of the first digital human. The first terminal receives a capability negotiation response, which includes information about the first entity. The first entity is the entity for downloading the first digital human model, and the first digital human model is used for the rendering of the first digital human. The first terminal generates a token based on the information about the first entity. The token is used to authorize the first entity to download the first digital human model. The first terminal sends the token.

[0010] Among them, the information about the first entity is, for example, the identifier and / or the type of the first entity.

[0011] In the above technical solution, the first terminal issues a token based on the information about the first entity (that is, the entity for downloading the first digital human model). Compared with the first terminal generating a token based on coarse-grained information (such as the information of all entities that may use the token, for example, including the terminal type, MF entity type, and DC AS type), the first terminal generates a token based on fine-grained information (that is, the information about the first entity). This token is used for the first entity to download the first digital human model and cannot be used for other entities to download the first digital human model, avoiding the abuse of the permission to download the digital human model and improving security. Thus, when the first entity requests the first digital human model from the base avatar repository (BAR) network element based on the token, the BAR network element can verify the identity of the first entity according to the token. For example, when the BAR network element determines that the first entity passes the identity verification, it provides the first digital human model to the first entity. When the BAR network element determines that the first entity fails the identity verification, it does not provide the first digital human model to the first entity. In this way, by the method of the first terminal issuing a token, the security in the process of requesting the digital human model is improved.

[0012] Moreover, in the capability negotiation process, the first terminal obtains the information about the first entity, which helps to save the number of signaling interactions.

[0013] In a possible implementation, the token includes the information about the first entity and the identifier of the first digital human.

[0014] In the above technical solution, the first terminal carries the information about the first entity and the identifier of the first digital human in the token. Equivalently, the first entity is authorized to download the first digital human model corresponding to the identifier of the first digital human. Correspondingly, the BAR network element can perform verification based on the token, which helps to improve the security in the process of requesting the digital human model.

[0015] In a possible implementation, a first application data channel (ADC) is established between the first terminal and the DC AS. Exemplarily, a capability negotiation request is sent by the first terminal to the DC AS through the first ADC. For example, the first terminal sends a capability negotiation request to the MF network element, and the MF network element forwards the capability negotiation request to the DC AS. Also exemplarily, a capability negotiation response is sent by the DC AS to the first terminal through the first ADC. In other words, the capability negotiation response is information received by the first terminal from the DC AS through the first ADC. For example, the DC AS sends a capability negotiation response to the MF network element, and the MF network element forwards the capability negotiation response to the first terminal.

[0016] In a possible implementation, the capability negotiation response further includes information about the entity for storing the first digital human model, and the token includes information about the entity for storing the first digital human model. In a possible implementation, the entity for storing the first digital human model is the first BAR network element. Exemplarily, the information about the first BAR network element is the identifier of the first BAR network element.

[0017] In the above technical solution, the first terminal carries information about the entity for storing the first digital human model (such as the identifier of the first BAR network element) in the token. When the second BAR network element receives a request from the first entity to download the first digital human model, the second BAR network element can determine whether the information about the entity for storing the first digital human model in the token is the information of the second BAR network element, and then determine whether to provide the first digital human model to the first entity. Exemplarily, when the second BAR network element determines that the information about the entity for storing the first digital human model included in the token is the same as the information of the second BAR network element (that is, the above first BAR and this second BAR are the same BAR), the second BAR network element provides the first digital human model to the first entity; when the second BAR network element determines that the information about the entity for storing the first digital human model included in the token is different from the information of the second BAR network element (that is, the above first BAR and this second BAR are different BARs), the second BAR network element does not provide the first digital human model to the first entity. In this way, it helps to further ensure the security of the digital human model in the BAR network element. Further, compared with the first terminal generating a token based on coarse-grained information (such as information about all entities that may provide the digital human model), the first terminal generates a token based on fine-grained information (such as information about the first BAR network element). This token is used for the first entity to request the first digital human model from the first BAR and cannot be used for the first entity to request the first digital human model from other entities. In other words, this token indicates that the first BAR can provide the first digital human model, while other entities cannot provide the first digital human model. The authorization for the digital human model is more accurate, avoiding the abuse of the permission to provide the digital human model and further ensuring security.

[0018] In a possible implementation, the token is carried in a reinvite message. Exemplarily, the first terminal sends a reinvite message, and the reinvite message includes the token. Exemplarily, the reinvite message is used to establish a second ADC between the first terminal and the DC AS, and the second ADC is used to transmit service data. For example, it transmits data between the first terminal and the second terminal (such as data for rendering an entity for rendering (such as user information), and transmits the digital human after rendering, etc.). In the above technical solution, the first terminal carries the token in the reinvite message without adding other messages, which helps to save the number of signaling interactions.

[0019] In a possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal related to the call. Exemplarily, the first entity is a rendering entity, and the rendering entity is, for example, one of the MF network element, first terminal, and second terminal. Again exemplarily, the first entity is an agent entity, and the agent entity can be used to proxy the rendering entity to request the first digital human model from the BAR network element. The agent entity is, for example, the DC AS.

[0020] In a possible implementation, the negotiation parameters of the first terminal are carried in the capability negotiation request; the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entities recommended by the first terminal; the candidate entities include one or more of the MF network element, first terminal, and second terminal related to the call. Exemplarily, the negotiation parameters of the first terminal can be used to determine the information of the first entity.

[0021] The above technical solution helps to improve the flexibility of determining the information of the first entity.

[0022] In a second aspect, the present application provides a communication method, which can be executed by a second communication device. The second communication device can be a DC AS or a part of the DC AS (such as a chip in the DC AS).

[0023] When the second communication device is a DC AS, for example, the second communication device can send information to the first terminal, or the second communication device can receive information from the first terminal. When the second communication device is a module in the DC AS, the second communication device can send information to other modules in the DC AS (such as a radio frequency module or an antenna). For example, the information is sent by the DC AS to the first terminal; or the second communication device can receive information from other modules (such as a radio frequency module or an antenna). For example, the information is sent by the first terminal to the DC AS.

[0024] For ease of description, the following takes the second communication device being a DC AS as an example for illustration.

[0025] The method is applied to the scenario where a digital human-related call is made between a first terminal and a second terminal. The method includes:

[0026] The DC AS receives a capability negotiation request, which carries the identifier of the first digital human. The capability negotiation request is used to negotiate the rendering of the first digital human. The DC AS sends a capability negotiation response, which includes information about the first entity. The first entity is the entity used to download the first digital human model, and the first digital human model is used for the rendering of the first digital human. The information about the first entity is used to generate a token, and the token is used to authorize the first entity to download the first digital human model. For example, the information about the first entity is used by the first terminal to generate a token.

[0027] In a possible implementation, the capability negotiation response further includes information about the entity used to store the first digital human model. Among them, the information about the entity used to store the first digital human model is, for example, the identifier of the first BAR network element.

[0028] In a possible implementation, the capability negotiation request carries the negotiation parameters of the first terminal. The negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entities recommended by the first terminal. The candidate entities include one or more of the MF network element related to the call, the first terminal, and the second terminal. After receiving the capability negotiation request, the DC AS also determines the information about the first entity according to the negotiation parameters of the first terminal.

[0029] Exemplarily, when the DC AS determines the information about the first entity according to the negotiation parameters of the first terminal, specifically, the DC AS obtains the negotiation parameters of the MF network element and the negotiation parameters of the second terminal from the MF network element. The DC AS determines the information about the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal. Among them, the negotiation parameters of the MF network element include the rendering capability of the MF network element and / or the candidate entities recommended by the MF network element; the negotiation parameters of the second terminal include the rendering capability of the second terminal and / or the candidate entities recommended by the second terminal.

[0030] In a possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal related to the call.

[0031] In a possible implementation, when the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal do not meet the preset rendering requirements, the DC AS also sends a first request to the network repository function (NRF) network element. The first request includes the preset rendering requirements, and the first request is used to request a first entity that meets the preset rendering requirements. Further, the DC AS receives a first response from the NRF, and the first response includes information about the first entity.

[0032] In the above technical solution, when the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal do not meet the preset rendering requirements, the DC AS can also request information about the first entity from the NRF network element to ensure the normal progress of the rendering process.

[0033] Exemplarily, when the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal do not meet the preset rendering requirements, specifically, it may be that the rendering capabilities of the first terminal, the MF network element, and the second terminal do not meet the preset rendering requirements.

[0034] In a possible implementation, the rendering capability of the first terminal includes one or more of the following:

[0035] (1) Whether the first terminal supports rendering, that is, whether the first terminal has the ability to be a rendering entity.

[0036] (2) The rendering data requirements of the first terminal, where the rendering data requirements of the first terminal include the data types required by the first terminal when rendering the first digital human and / or the minimum number of sensors corresponding to the data types required when rendering the first digital human.

[0037] (3) The remaining computing resources of the first terminal, where the remaining computing resources of the first terminal include one or more of the current available resources of the central processing unit (CPU) of the first terminal, the current available power consumption of the graphics processing unit (GPU), the current available computing power of the GPU, or the current available memory resources.

[0038] (4) The score of the remaining computing resources of the first terminal. The score can be obtained by the first terminal scoring the remaining computing resources of the first terminal according to a preset scoring system.

[0039] In a possible implementation, a first ADC is established between the first terminal and the DC AS. Exemplarily, a capability negotiation request is sent by the first terminal to the DC AS through the first ADC. In other words, the capability negotiation request is information from the first terminal received by the DC AS through the first ADC. For example, the first terminal sends a capability negotiation request to the MF network element, and the MF network element forwards the capability negotiation request to the DC AS. Also exemplarily, a capability negotiation response is sent by the DC AS to the first terminal through the first ADC. For example, the DC AS sends a capability negotiation response to the MF network element, and the MF network element forwards the capability negotiation response to the first terminal.

[0040] In a third aspect, the present application provides a communication method, which can be executed by a third communication device. The third communication device can be a second BAR network element, or a part of the second BAR network element (for example, a chip in the second BAR network element).

[0041] For ease of description, the following takes the third communication device as the second BAR network element as an example for illustration.

[0042] This method is applied to the scenario where the first terminal and the second terminal conduct a digital human-related call. The method includes:

[0043] The second BAR network element receives a token from a second entity. The token is used to authorize the first entity to download a first digital human model. The token is generated by the first terminal according to the information of the first entity. The first digital human model is used for the rendering of the first digital human. When the second BAR network element determines that the information of the second entity is the same as the information of the first entity in the token, it sends the first digital human model to the second entity; when the second BAR network element determines that the information of the second entity is different from the information of the first entity in the token, it does not send the first digital human model to the second entity.

[0044] In a possible implementation, the token includes the information of the first entity and the identifier of the first digital human.

[0045] In a possible implementation, the token further includes the information of the entity for storing the digital human model (for example, the identifier of the first BAR network element). The second BAR network element can also determine whether the information of the entity for storing the digital human model in the token is the information of the second BAR network element. Further, when the second BAR network element determines that the information of the entity for storing the digital human model in the token is the information of the second BAR network element, and the information of the second entity is the same as the information of the first entity in the token, it sends the first digital human model to the second entity.

[0046] In a fourth aspect, the present application provides a communication method, which can be executed by a fourth communication device. The fourth communication device can be an NRF network element, or a part of the NRF network element (for example, a chip in the NRF network element).

[0047] For ease of description, the following takes the fourth communication device as an NRF network element as an example for illustration.

[0048] This method is applied to the scenario where a first terminal and a second terminal conduct a digital human-related call. The method includes:

[0049] The NRF network element receives a first request, which includes a preset rendering requirement. The first request is used to request a first entity that meets the preset rendering requirement. The first request is sent by the DC AS when it determines that the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal do not meet the preset rendering requirement; the NRF network element sends a first response, and the first response includes information about the first entity.

[0050] In a fifth aspect, an embodiment of the present application provides a communication device.

[0051] This device has the functions of the first communication device in the above-mentioned first aspect or any possible implementation manner of the first aspect. This communication device may also have the functions of the second communication device in the above-mentioned second aspect or any possible implementation manner of the second aspect. This communication device may also have the functions of the third communication device in the above-mentioned third aspect or any possible implementation manner of the third aspect. This communication device may also have the functions of the fourth communication device in the above-mentioned fourth aspect or any possible implementation manner of the fourth aspect.

[0052] The functions of the above-mentioned communication device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules, units, or means corresponding to the above functions.

[0053] In a possible implementation manner, the structure of the device includes a processing module and a transceiver module.

[0054] Among them, the processing module is configured to support the device to execute the corresponding functions of the first communication device in the above-mentioned first aspect or any possible implementation manner of the first aspect, or execute the corresponding functions of the second communication device in the above-mentioned second aspect or any possible implementation manner of the second aspect, or execute the corresponding functions of the third communication device in the above-mentioned third aspect or any possible implementation manner of the third aspect, or execute the corresponding functions of the fourth communication device in the above-mentioned fourth aspect or any possible implementation manner of the fourth aspect.

[0055] The transceiver module is used to support the communication between the device and other communication devices. For example, when the device is the first communication device, it can send a capability negotiation request. The communication device may further include a storage module, which is coupled to the processing module and stores necessary program instructions and data of the device. As an example, the processing module may be a processor, the communication module may be a transceiver, and the storage module may be a memory. The memory may be integrated with the processor or separately provided from the processor.

[0056] In another possible implementation, the structure of the device includes a processor and may further include a memory. The processor is coupled to the memory and can be used to execute the computer program instructions stored in the memory, so that the device executes the method in the first aspect or any possible implementation of the first aspect above, or executes the method in the second aspect or any possible implementation of the second aspect above, or executes the method in the third aspect or any possible implementation of the third aspect above, or executes the method in the fourth aspect or any possible implementation of the fourth aspect above. Optionally, the device further includes a communication interface, and the processor is coupled to the communication interface. When the device is a device, the communication interface may be a transceiver or an input / output interface; when the device is a chip included in the device, the communication interface may be the input / output interface of the chip. Optionally, the transceiver may be a transceiver circuit, and the input / output interface may be an input / output circuit.

[0057] In a sixth aspect, an embodiment of the present application provides a chip system, including: a processor and a memory. The processor is coupled to the memory, and the memory is used to store programs or instructions. When the programs or instructions are executed by the processor, the chip system executes the method in the first aspect or any possible implementation of the first aspect above, or executes the method in the second aspect or any possible implementation of the second aspect above, or executes the method in the third aspect or any possible implementation of the third aspect above, or executes the method in the fourth aspect or any possible implementation of the fourth aspect above.

[0058] Optionally, the chip system further includes an interface circuit, which is used to interact code instructions to the processor.

[0059] Optionally, the processor in the chip system may be one or more, and the processor may be implemented by hardware or by software. When implemented by hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented by software, the processor may be a general-purpose processor and is implemented by reading the software code stored in the memory.

[0060] Optionally, there may also be one or more memories in the chip system. The memory may be integrated with the processor or separately provided from the processor. Exemplarily, the memory may be a non-transitory processor, such as a read only memory (ROM), which may be integrated with the processor on the same chip or separately provided on different chips.

[0061] In a seventh aspect, the present application provides a computer-readable storage medium storing a computer program or instruction. When the computer program or instruction is executed by a communication device, the communication device is caused to execute the method in the first aspect or any possible implementation manner of the first aspect, or execute the method in the second aspect or any possible implementation manner of the second aspect, or execute the method in the third aspect or any possible implementation manner of the third aspect, or execute the method in the fourth aspect or any possible implementation manner of the fourth aspect.

[0062] In an eighth aspect, the present application provides a computer program product including a computer program or instruction. When the computer program or instruction is executed by a communication device, it implements the method in the first aspect or any possible implementation manner of the first aspect, or implements the method in the second aspect or any possible implementation manner of the second aspect, or implements the method in the third aspect or any possible implementation manner of the third aspect, or implements the method in the fourth aspect or any possible implementation manner of the fourth aspect.

[0063] In a ninth aspect, an embodiment of the present application provides a communication system including one or more of a first communication device, a second communication device, a third communication device, or a fourth communication device. Among them, the first communication device implements the method in the first aspect or any possible implementation manner of the first aspect, the second communication device implements the method in the second aspect or any possible implementation manner of the second aspect, the third communication device implements the method in the third aspect or any possible implementation manner of the third aspect, and the fourth communication device implements the method in the fourth aspect or any possible implementation manner of the fourth aspect.

[0064] The technical effects that can be achieved by any of the second aspect to the ninth aspect may refer to the description of the beneficial effects in the first aspect, and will not be repeated here. The technical solutions in the first aspect to the ninth aspect may refer to each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 It is a schematic diagram of a scenario related to a digital human call;

[0066] Figure 2A A schematic diagram of a network architecture provided for this application;

[0067] Figure 2B Another schematic diagram of a network architecture provided for this application;

[0068] Figure 2C Yet another schematic diagram of a network architecture provided for this application;

[0069] Figure 3 A schematic flowchart of the first communication method provided for this application;

[0070] Figure 4 A schematic flowchart of the second communication method provided for this application;

[0071] Figure 5 A schematic flowchart of the third communication method provided for this application;

[0072] Figure 6 A schematic flowchart of the fourth communication method provided for this application;

[0073] Figure 7 A schematic flowchart of the fifth communication method provided for this application;

[0074] Figure 8 A schematic flowchart of the sixth communication method provided for this application;

[0075] Figure 9 A schematic flowchart of the seventh communication method provided for this application;

[0076] Figure 10 A schematic diagram of the structure of a communication device provided for this application;

[0077] Figure 11 Another schematic diagram of the structure of a communication device provided for this application. Detailed implementation manners

[0078] First, the relevant technical features involved in the embodiments of this application will be explained. It should be noted that these explanations are for the purpose of making the embodiments of this application easier to understand, and should not be regarded as a limitation of the protection scope required by this application.

[0079] The communication method provided in this application can be applied to various communication systems, such as: the fifth-generation (5G) communication system (or the new radio (NR) system), the fourth-generation (4G) communication system (or the long-term evolution (LTE) system), the LTE frequency division duplex (FDD) system, the LTE time division duplex (TDD) system, etc. The technical solution provided in this application can also be applied to future communication systems.

[0080] The following introduces the network architecture applicable to the communication method proposed in this application.

[0081] See Figure 2A , which is a schematic diagram of a network architecture exemplarily provided for this application. Figure 2A The shown network architecture includes a first terminal, a communication network, and a second terminal. The first terminal and the second terminal can make calls through the communication network. Exemplarily, the first terminal and the second terminal can make calls related to an avatar through the communication network.

[0082] An avatar (also known as an animated avatar) refers to a personal virtual image or avatar on the network. Avatar technology is to map the user's facial expressions, actions, and voice to an avatar model (also known as an avatar model, base avatar, etc.) in real time, and generate an avatar, enabling the avatar to imitate and respond to the user's real-time behavior.

[0083] Among them, a call can also be called a communication service, which means that the terminal participates as an originating party (or initiating party) or a terminating party, and through the communication network connection, conducts services such as voice calls, video calls, or data interactions with one or more other terminals. A call can cover the entire process from call establishment (such as dialing) to call termination in terms of time, or can also cover a part of the process from call establishment to call termination. A call can be a one-to-one call or a one-to-many (such as a conference) call; the embodiments of this application take a one-to-one call as an example, but the relevant solutions can be used for one-to-many calls.

[0084] The communication network may be an Internet Protocol (IP) Multimedia Subsystem (IMS) network. Among them, the IMS network is an open system based on IP bearer and providing various multimedia services to users. Further, the communication network may include one or more network devices.

[0085] For example, see Figure 2B As shown, the communication network may include a Call Session Control Function (CSCF) network element, an IMS Access Media Gateway (AGW), a Home Subscriber Server (HSS) network element, an IMS Application Server (AS), an MF network element, etc.

[0086] Figure 2C The communication network shown in Figure 2B On the basis of the communication network shown, some network elements related to the data channel (DC) are additionally added, such as a Data Channel Signaling Function (DCSF) network element, a Data Channel Application Repository (DCAR) network element, a DC AS. Optionally, Figure 2C The communication system shown also includes a Network Exposure Function (NEF) network element, an NRF network element, and a BAR network element.

[0087] Here, a brief introduction is given to Figures 2A to 2C each network element (or called functional network element, functional entity, node, device, etc.) shown:

[0088] 1. Terminal: A terminal can be referred to as a user equipment (UE), terminal device, terminal apparatus, access terminal, user unit, user station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent, or user apparatus, etc., which is a device with wireless or wired communication capabilities. For example, a terminal can be connected to a wireless access device through an air interface, or a terminal can be connected to a wired access device through a wired interface. In terms of product form, a terminal can include a handheld device with communication functions, a vehicle-mounted device, a wearable device, or a computing device, etc. Exemplarily, a terminal can be a mobile phone, a tablet (pad), a computer with wireless communication functions (such as a laptop computer, a handheld computer, etc.), a mobile internet device (MID), a virtual reality (VR) terminal, an augmented reality (AR) terminal, a smart watch, a smart bracelet, smart glasses, a wireless terminal in industrial control, a wireless terminal in self-driving, 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 cellular phone, a cordless phone, a SIP phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device with wireless communication functions, other processing devices connected to a wireless modem, a terminal in an internet of things (IoT) system, a desktop computer, or a terminal defined by the 3rd generation partnership project (3GPP) standard specifications, etc., without limitation.

[0089] 2. The CSCF network element is a functional entity within IMS and is the core of the entire IMS. It is mainly responsible for processing signaling control during multimedia call sessions. It manages user authentication in IMS, the quality of service (QoS) of the IMS bearer plane, cooperates with other network elements to control session initiation protocol (SIP) sessions, and conducts service negotiation and resource allocation, etc. Among them, the CSCF network element can communicate with terminals, and the CSCF network element can communicate with gateway devices. For example, the CSCF network element can select the gateway device for communicating with the terminal, and the CSCF network element can allocate routing information for the terminal and the gateway device, such as IP addresses or ports.

[0090] By way of example and not limitation, the CSCF network element is classified into a proxy CSCF network element (P-CSCF network element), an interrogating CSCF network element (I-CSCF network element), a serving CSCF network element (S-CSCF network element), etc. according to its functions. Among them, the P-CSCF network element is the entry node for users to access the IMS network and is mainly responsible for forwarding SIP signaling between IMS users and the home network. The I-CSCF network element is the unified entry point of the IMS user home network and is responsible for allocating or querying the S-CSCF network element that serves the user. The S-CSCF network element is the unified entry point of the IMS user home network and is responsible for allocating or querying the S-CSCF network element that serves the user.

[0091] It can be understood that the above P-CSCF network element, S-CSCF network element, and I-CSCF network element can be independently configured in different entities or integrated into the same entity, which is not limited in this application.

[0092] 3. IMS AGW: The IMS AGW can provide the functions of an IMS network access gateway and a media gateway.

[0093] 4. DCSF network element: It is used to provide data channel signaling control functions.

[0094] 5. DCAR network element: It is a repository for storing data channel applications (DC Apps).

[0095] 6. HSS network element: The HSS network element serves as a database for storing user information in IMS and stores user data. By way of example and not limitation, the user data can include information about the data channel services subscribed to by the user with the operator.

[0096] 7. IMS AS: IMS AS is the application layer device at the top layer in the IMS system, providing basic services and supplementary services, such as multimedia conferencing, converged communication, SMS gateway, standard operator console and other services. The IMS network is an open system based on IP bearer and providing various multimedia services to users. IMS AS interacts with CSCF network elements to trigger and execute various network services. Moreover, there is a communication connection between the terminal and IMS AS, and IMS AS can establish a data channel for the terminal.

[0097] Exemplarily, IMS AS can be a multimedia telephony application server (MMTEL AS) or a telephony application server (TAS).

[0098] 8. DC AS: Also known as the extended reality application server (XRAS). DC AS is used to provide data channel service logic. It can be understood that DC AS can be deployed in the IMS network. In this case, DC AS can be directly connected to other network elements in the IMS network through an interface (such as a service-based interface); or, DC AS can also be deployed outside the IMS network. In this case, DC AS can be connected to other network elements in the IMS network through the NEF network element (or the IMS border network management).

[0099] Exemplarily, DC AS can download the avatar ID list from the BAR network element and send it to the terminal. Exemplarily, DC AS can also download the digital human model from the BAR network element based on the avatar ID.

[0100] 9. NEF network element: The NEF network element is used to securely open various services of the 5GC network to third parties.

[0101] 10. MF network element: It can also be called a media server and is used to provide media resource management functions, including media resource management of media channels and media resource management of data channels. Further, the MF network element can drive the rendering of an animated digital human based on the digital human model and user information (such as action information, language information, expression information, text information, etc.). Exemplarily, the MF network element can also download the digital human model from the BAR network element based on the avatar ID.

[0102] 11. BAR Network Element: It is used to store the digital human model and the identifier of the digital human (which can be represented as Avatar ID). Further, one terminal corresponds to one or more digital human models, and each digital human model is identified by an Avatar ID. The BAR network element also stores the identifier list of the digital humans of each terminal (which can be represented as Avatar ID list).

[0103] 12. NRF Network Element: It is used to register, manage, and detect the status of network function (NF) network elements. Each NF must be registered through the NRF network element when it starts up in order to be provided with services.

[0104] The network architecture applied to the embodiments of this application is only an example. The network architecture applicable to the embodiments of this application is not limited to this. Any network architecture that can implement the functions of the above-mentioned network elements is applicable to the embodiments of this application. That is, the network architecture and service scenarios described in the embodiments of this application are for more clearly explaining the technical solutions of the embodiments of this application, and do not constitute a limitation to the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of this application are equally applicable to similar technical problems. The network elements or devices listed in the above network architecture are only for illustrative purposes. The network architecture applicable to this application may also include other network elements or devices, and this application does not make any limitations in this regard. The naming of the above network elements or devices is only defined for the convenience of distinguishing different functions and should not constitute any limitation to this application. There may be other names in other network architectures.

[0105] Further, digital human calls are similar to video calls. Both provide visual and interactive communications and provide real-time images of the communicator's emotions, attention, and other social information to the communication users. Different from video calls, digital human calls present a digital human (digital human image) of a virtual animation processed by the terminal or network device (such as the MF network element) to the opposite user, rather than the real image in video calls.

[0106] In a possible digital human call process, after the first terminal initiates a digital human call to the second terminal, the MF network element downloads the digital human model from the BAR network element and obtains user information from the first terminal. The MF network element renders the digital human based on the digital human model and user information, and then combines the digital human with the scene for rendering. The MF network element sends the digital human after combining with the scene rendering to the second terminal.

[0107] Furthermore, the digital human model is a 2D or 3D model or graphic of the first terminal generated online or offline (simply understood as a digital human template), which can be stored in the BAR network element (alternatively, a digital asset repository (DAR), a digital asset container (DAC), or a DCAR network element). The BAR network element can be provided by a network, a third-party entity outside the network, or a local storage device of the terminal.

[0108] The user information comes from the sensing devices of the first terminal, such as cameras and dedicated motion capture devices, which can capture the motion information of the head (face), body, legs, hands, etc. of the user using the first terminal. The microphone can capture the language information of the user using the first terminal. The first terminal sends the processed (for generating the digital human) user information to the MF network element.

[0109] It should be noted that the digital human can also be generated by the first terminal or the second terminal. In this case, the first terminal or the second terminal needs to download the digital human model from the BAR network element and generate the digital human. If the digital human is generated by the first terminal, the first terminal generates the digital human based on the downloaded digital human model and the user information collected by the sensor, and sends it to the second terminal after combining with the scene; if the digital human is generated by the second terminal, the second terminal can generate the digital human based on the downloaded digital human model and the user information from the first terminal, and then display the digital human after combining with the scene.

[0110] In this application, rendering and driving are regarded as the same operation, that is, a certain entity needs to generate a digital human based on the digital human model and user information and match it with environmental information, and the English name is animate. Rendering will be used to describe it hereinafter.

[0111] This application provides a communication method for ensuring security during the rendering process.

[0112] This method is applied to the scenario where the first terminal and the second terminal conduct a digital human-related call. Exemplarily, the first terminal initiates a digital human-related call to the second terminal as the calling party, and the second terminal receives the digital human-related call as the called party.

[0113] Figure 3Schematic diagram of a communication method provided exemplarily for this application. This communication method can be executed interactively by a first communication device and a second communication device. Among them, the first communication device can be a first terminal or a part of the first terminal (such as a chip); the second communication device can be a DC AS or a part of the DC AS (such as a chip). For the convenience of description, the following takes the first communication device as the first terminal and the second communication device as the DC AS as an example. Further, this method focuses on how the first terminal obtains the information of the first entity and then generates a token according to the information of the first entity.

[0114] The network devices involved in this method include a DC AS and an MF network element related to the call.

[0115] Exemplarily, the DC AS related to the call refers to the DC AS used to provide the data channel service logic for this call. For example, when the first terminal and the second terminal are deployed in the same IMS network, the DC AS related to the call can be the DC AS inside this IMS network; when the first terminal and the second terminal are deployed in different IMS networks, the DC AS related to the call can be the DC AS inside the IMS network where the first terminal is deployed. The MF network element related to the call refers to the MF network element used to provide the media resource management function for this call.

[0116] Among them, a first ADC is established between the first terminal and the DC AS, and the first ADC is used for rendering negotiation. Among them, end-to-end protection is established between the first terminal and the MF network element, and end-to-end protection is established between the MF network element and the DC AS. When the first terminal sends a message to the DC AS through the first ADC, specifically, the first terminal sends a message to the MF network element, and the MF network element forwards the message to the DC AS. For example, the MF network element does not parse the message, and the message is transparently transmitted in the MF network element. When the DC AS sends a message to the first terminal through the first ADC, specifically, the DC AS sends a message to the MF network element, and the MF network element forwards the message to the first terminal. For example, the MF network element does not parse the message, and the message is transparently transmitted in the MF network element.

[0117] Step 301, the first terminal sends a capability negotiation request to the DC AS.

[0118] Correspondingly, the DC AS receives the capability negotiation request from the first terminal.

[0119] Exemplarily, the capability negotiation request can also be referred to as a negotiation request, a rendering negotiation request, a driving negotiation request, an animation negotiation request, etc.

[0120] The capability negotiation request is used to negotiate the rendering of the digital human. Exemplarily, the capability negotiation request is used to negotiate the rendering data type, rendering entity, etc. used in the digital human rendering process. Among them, the rendering entity refers to the entity used to generate the digital human according to the user information and the digital human model. The rendering entity can be the first terminal, the second terminal, or the MF network element related to the digital human call between the first terminal and the second terminal. The rendering data type is, for example, text, language, action, etc. For the convenience of description, the digital human negotiated for rendering hereinafter is referred to as the first digital human, and the model used to generate the first digital human is referred to as the first digital human model. That is, the first digital human model is used for the rendering of the first digital human.

[0121] The capability negotiation request carries the identifier (avatar id) of the first digital human. Exemplarily, the identifier of the first digital human is used to retrieve the first digital human model, and the identifier of the first digital human can also be referred to as the identifier of the first digital human model, the identifier of the model. Exemplarily, the capability negotiation request may also carry the negotiation parameters of the first terminal. Exemplarily, the negotiation parameters of the first terminal include the rendering capability (capability) of the first terminal and / or the candidate entities recommended (represented as prefer in English, and in this application, "recommend" can also be replaced by "not recommend") by the first terminal. Among them, the candidate entities include one or more of the MF network element, the first terminal, and the second terminal.

[0122] Among them, the rendering capability of the first terminal includes one or more of the following:

[0123] (1) Whether the first terminal supports rendering, that is, whether the first terminal has the ability to be a rendering entity. For example, the rendering capability of the first terminal includes 1 bit of indication information. When the value of this 1 bit is 1, it indicates that the first terminal supports rendering; when the value of this 1 bit is 0, it indicates that the first terminal does not support rendering. Of course, there can be other indication methods, and this application will not give examples anymore.

[0124] (2) The rendering data requirements of the first terminal, where the rendering data requirements of the first terminal include the data types required by the first terminal when generating the first digital human (i.e., when rendering the first digital human) and / or the minimum number of sensors corresponding to the data types required when generating the first digital human (i.e., when rendering the first digital human). For example, the rendering data requirements of the first terminal include an action type, and the minimum number of sensors corresponding to the action type is 3. That is, when the first terminal renders the first digital human, the data type required is the action type, and at least 3 sensors are required to collect this type of data.

[0125] (3) The remaining computing resources of the first terminal, where the remaining computing resources of the first terminal include one or more of the current available resources of the CPU of the first terminal, the current available power consumption of the GPU, the current available computing power of the GPU, or the current available memory resources.

[0126] (4) The scoring of the remaining computing resources of the first terminal. The scoring can be obtained by the first terminal scoring the remaining computing resources of the first terminal according to a preset scoring system. Exemplarily, the preset scoring system is unified for the first terminal, the second terminal, and the MF network element.

[0127] Exemplarily, the negotiation parameters of the first terminal include "support rendering, recommended entity is the first terminal", which means that the first terminal supports rendering and recommends itself as the rendering entity; again exemplarily, the negotiation parameters of the first terminal include "does not support rendering, recommended entity is the MF network element", which means that the first terminal does not support rendering and recommends the MF network element as the rendering entity.

[0128] Exemplarily, when the first terminal establishes a first ADC with the DC AS and the first terminal sends a capability negotiation request to the DC AS, specifically, the first terminal can send a capability negotiation request to the MF network element, and the MF network element forwards the capability negotiation request to the DC AS. For example, the MF network element does not parse the capability negotiation request, and the capability negotiation request is transparently transmitted in the MF network element.

[0129] Step 302, the DC AS sends a capability negotiation response to the first terminal.

[0130] Correspondingly, the first terminal receives the capability negotiation response from the DC AS.

[0131] Among them, the capability negotiation response includes information about the first entity. The information about the first entity can specifically be the type of the first entity and / or the identity (ID) of the first entity.

[0132] Exemplarily, the capability negotiation response can also be referred to as a negotiation response, a rendering negotiation response, a driving negotiation response, an animation negotiation response, etc. Exemplarily, the information of the first entity can also be referred to as the information of the user (which can be expressed as "subject" in English), the information of the authorized entity, the rendering negotiation parameter, the rendering negotiation result, etc.

[0133] The first entity is the entity for downloading the first digital human model. Exemplarily, the first entity is one of the DC AS, the MF network element, the first terminal, and the second terminal related to the current call between the first terminal and the second terminal.

[0134] It can be understood that the first entity can be a rendering entity or a proxy entity of the rendering entity. Exemplarily, when the first entity is a rendering entity, the first entity can be the first terminal, the second terminal, or the MF network element, and the rendering entity can request to download the first digital human model; when the first entity is a proxy entity of the rendering entity, the first entity can be the DC AS. Further, the rendering entity can be the first terminal, the second terminal, or the MF network element, and the DC AS can proxy the rendering entity to request to download the first digital human model.

[0135] In addition, the capability negotiation response also includes the information of the entity for storing the first digital human model. Exemplarily, the entity for storing the first digital human model is the first BAR network element. Exemplarily, the information of the first BAR network element can specifically be the identifier of the first BAR network element.

[0136] Exemplarily, a first ADC is established between the first terminal and the DC AS, and the first terminal can send a message to the DC AS through the first ADC. When the DC AS sends a capability negotiation response to the first terminal, specifically, the DC AS sends the capability negotiation response to the MF network element, and the MF network element forwards the capability negotiation response to the first terminal. For example, the MF network element does not parse the capability negotiation response, and the capability negotiation response is transparently transmitted in the MF network element.

[0137] Optionally, before step 302, one or more of the following steps A, B, and C are further included:

[0138] Step A, the DC AS determines the information of the first entity in response to the capability negotiation request.

[0139] That is, "the DC AS receives the capability negotiation request" serves as the trigger condition for "the DC AS determines the information of the first entity". When determining the information of the first entity, the DC AS can determine the information of the first entity in combination with the parameters in the capability negotiation request, or can also determine the information of the first entity without combining the parameters in the capability negotiation request. The following is explained in implementation mode 1 to implementation mode 3.

[0140] Implementation mode 1, the DC AS determines the information of the first entity according to the first configuration information. In this implementation mode, the DC AS does not determine the information of the first entity in combination with the parameters in the capability negotiation request.

[0141] Exemplarily, the first configuration information includes one of the following configurations:

[0142] Configuration 1, select the MF network element as the rendering entity. That is, when the first configuration information of the DC AS is this Configuration 1, the DC AS can determine the MF network element as the rendering entity. In addition, the "MF network element" in Configuration 1 can also be replaced by the "first terminal" or the "second terminal".

[0143] Configuration 2, the priority ranking of multiple entities among the DC AS, MF network element, first terminal, and second terminal.

[0144] For example, the priority ranking included in Configuration 2 is the MF network element, first terminal, and second terminal in sequence. When the first configuration information of the DC AS is this Configuration 2, the DC AS can first determine whether the MF network element can be used as the rendering entity according to the priority ranking. Further, if the DC AS determines that the MF network element can be used as the rendering entity, it determines the MF network element as the rendering entity; if the DC AS determines that the MF network element cannot be used as the rendering entity, it continues to determine whether the first terminal can be used as the rendering entity until the rendering entity is determined.

[0145] Among them, the DC AS includes a preset rendering requirement, for example, the minimum requirement for rendering a digital human. When the DC AS determines whether the MF network element can be used as the rendering entity, specifically, the DC AS determines whether the rendering capability of the MF network element can meet the preset rendering requirement. If the DC AS determines that the rendering capability of the MF network element meets the preset rendering requirement, it determines that the MF network element can be used as the rendering entity; if the DC AS determines that the rendering capability of the MF network element does not meet the preset rendering requirement, it determines that the MF network element cannot be used as the rendering entity. The method for the DC AS to determine whether the first terminal or the second terminal can be used as the rendering entity is similar to that of the MF network element. For the description of the rendering capabilities of the MF network element, first terminal, and second terminal, see the description in the following implementation mode 2.

[0146] Implementation manner 2: The DC AS determines the information of the first entity according to the negotiation parameters of the first terminal in the capability negotiation request.

[0147] In a possible example, the DC AS also obtains the negotiation parameters of the MF network element and the negotiation parameters of the second terminal, and then determines the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal.

[0148] Among them, the negotiation parameters of the MF network element include the rendering capability of the MF network element and / or the candidate entities recommended by the MF network element. The negotiation parameters of the second terminal include the rendering capability of the second terminal and / or the candidate entities recommended by the second terminal. Among them, for the negotiation parameters of the MF network element or the negotiation parameters of the second terminal, reference can be made to the description of the negotiation parameters of the first terminal in step 301. For the candidate entities recommended by the MF network element or the candidate entities recommended by the second terminal, reference can be made to the description of the candidate entities recommended by the first terminal in step 301.

[0149] Exemplarily, the DC AS obtains the negotiation parameters of the MF network element and the negotiation parameters of the second terminal from the MF network element.

[0150] For example, the DC AS sends a first acquisition request to the MF network element. The first acquisition request is used to request the negotiation parameters of the MF network element and the negotiation parameters of the second terminal. The first acquisition request includes the identifier of the MF network element and the identifier of the second terminal. Correspondingly, the MF network element sends a first acquisition response to the DC AS. The first acquisition response includes the negotiation parameters of the MF network element and the negotiation parameters of the second terminal. Exemplarily, when receiving the first acquisition request, the MF network element first sends a second acquisition request to the second terminal according to the first acquisition request. The second acquisition request is used to request the negotiation parameters of the second terminal. The second acquisition request includes the identifier of the second terminal. Correspondingly, the second terminal sends a second acquisition response to the MF network element. The second acquisition response includes the negotiation parameters of the second terminal. The MF network element then sends a first acquisition response to the DC AS according to the second acquisition response.

[0151] For another example, the DC AS sends an acquisition request to the MF network element. The acquisition request is used to request the negotiation parameters of the second terminal. The acquisition request includes the identifier of the second terminal. Correspondingly, the MF network element forwards the acquisition request to the second terminal. The second terminal sends an acquisition response to the MF network element. The acquisition response includes the negotiation parameters of the second terminal. When forwarding the acquisition response, the MF network element carries the negotiation parameters of the MF network element in the acquisition response.

[0152] Exemplarily, negotiation parameters of the MF network element are preconfigured in the DC AS. The DC AS obtains the negotiation parameters of the second terminal from the MF network element. For example, the DC AS sends a retrieval request to the MF network element. The retrieval request is used to request the negotiation parameters of the second terminal, and the identification of the second terminal is included in the retrieval request. Correspondingly, the MF network element forwards the retrieval request to the second terminal. Subsequently, the second terminal sends a retrieval response to the MF network element, and the MF network element forwards the retrieval response to the DC AS. The negotiation parameters of the second terminal are included in the retrieval response.

[0153] Among them, the retrieval request can also be referred to as an animation capability request, and correspondingly, the retrieval response can also be referred to as an animation capability response.

[0154] When the DC AS determines the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal, at least the following examples can be included:

[0155] Example 1: The negotiation parameters of each entity carry the rendering capability of the entity, but do not carry the candidate entities recommended by the entity. Then, the DC AS can select the entity with a stronger rendering capability as the first entity according to the rendering capabilities of each entity.

[0156] For example, the DC AS selects the entity (such as the MF network element) with a stronger rendering capability as the first entity according to the rendering capabilities of the first terminal, the second terminal, and the MF network element.

[0157] Furthermore, a certain entity may not carry the rendering capability of the entity in the negotiation parameters. At this time, the DC AS can consider that the entity does not support rendering. Then, the DC AS selects the entity with a stronger rendering capability from the entities that support rendering as the first entity. For example, the negotiation parameters of the first terminal do not carry the rendering capability of the first terminal, the negotiation parameters of the second terminal carry the rendering capability of the second terminal, and the negotiation parameters of the MF network element carry the rendering capability of the MF network element. The DC AS can default that the first terminal does not support rendering, and then select the entity (such as the MF network element) with a stronger rendering capability from the rendering capabilities of the second terminal and the MF network element as the first entity.

[0158] Example 2: The negotiation parameters of each entity carry the candidate entities recommended by that entity, but do not carry the rendering capabilities of that entity. Exemplarily, the DC AS determines the first entity based on the candidate entities recommended by the first terminal. For example, the DC AS selects the candidate entity recommended by the first terminal as the first entity. Or, the DC AS determines which entity has the most votes and selects that entity as the first entity. For example, the first terminal recommends the MF network element and the first terminal as the first entity, the second terminal recommends the MF network element and the second terminal as the first entity, and the MF network element recommends the MF network element as the first entity. Then the DC AS determines that the MF network element has the most votes and selects the MF network element as the first entity.

[0159] Example 3: The negotiation parameters of each entity carry the candidate entities recommended by that entity, as well as the rendering capabilities of that entity. The DC AS selects the recommended entities that support rendering.

[0160] Combined with the examples of the negotiation parameters of a first terminal, an MF network element, and a second terminal provided exemplarily in Table 1, the first entity determined by the DC AS is explained.

[0161] For example, when the negotiation parameters of the first terminal include "support rendering, recommended entity is the first terminal", the negotiation parameters of the second terminal include "support rendering, recommended entity is the second terminal", and the negotiation parameters of the MF network element include "support rendering, recommended entity is the MF network element", the DC AS can select any one of the MF network element, the first terminal, and the second terminal as the first entity. That is, when each entity supports rendering and recommends itself as the first entity, the DC AS can select any one of the MF network element, the first terminal, and the second terminal as the first entity.

[0162] Another example, when the negotiation parameters of the first terminal include "support rendering, recommended entity is the first terminal or the MF network element", the negotiation parameters of the second terminal include "support rendering, recommended entity is the second terminal or the MF network element", and the negotiation parameters of the MF network element include "support rendering, recommended entity is the MF network element", the DC AS can select any one of the MF network element, the first terminal, and the second terminal as the first entity. That is, when the terminals all support rendering and recommend other entities except the peer as the first entity, the DC AS can select any one of the MF network element, the first terminal, and the second terminal as the first entity. Other examples can also be seen in Table 1 and will not be listed one by one.

[0163] Table 1

[0164]

[0165]

[0166] It should be added that in the negotiation parameters of the first terminal, "the candidate entity recommended by the first terminal" can also be replaced by "the candidate entity not recommended by the first terminal". For example, the negotiation parameters of the first terminal include "not recommend the second terminal"; or, it can also be replaced by "whether the first terminal recommends the second terminal and / or the MF network element". For example, the negotiation parameters of the first terminal include "recommend the second terminal and the MF network element as the first entity", and for another example, the negotiation parameters of the first terminal include "recommend the MF network element as the first entity and do not recommend the second terminal as the first entity". Among them, the negotiation parameters of the MF network element or the second terminal are similar to those of the first terminal and will not be elaborated.

[0167] In addition, the DC AS can also obtain one or more of the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal, and then determine the information of the first entity according to the negotiation parameters obtained by the DC AS. For example, the DC AS obtains the negotiation parameters of the first terminal from the capability negotiation request, and obtains the negotiation parameters of the MF network element from the acquisition response. Then, the DC AS determines the information of the first entity according to the negotiation parameters of the first terminal and the negotiation parameters of the MF network element. For the specific implementation, reference can be made to the above Examples 1 to 3.

[0168] In this implementation manner 2, the first entity can specifically be a rendering entity.

[0169] Of course, the above are all exemplary descriptions, and the present application may also have other implementation manners, which will not be exemplified one by one.

[0170] Implementation manner 3, the DC AS requests the information of the first entity from the NRF network element.

[0171] In a possible example, the DC AS includes a preset rendering requirement, which can be considered as the minimum requirement for rendering a digital human. For example, the data type required for rendering, the minimum number of sensors corresponding to the data type required for rendering.

[0172] In a possible example, when the DC AS determines that the rendering capabilities in the negotiation parameters it obtains do not meet the preset rendering requirements, it sends a first request to the NRF network element. The first request includes the preset rendering requirements, and the first request is used to request the information of the first entity that meets the preset rendering requirements. Correspondingly, the NRF network element receives the first request, determines the information of the first entity according to the preset rendering requirements in the first request, and sends a first response to the DC AS. The first response includes the information of the first entity. The DC AS receives the first response from the NRF network element.

[0173] Exemplarily, when the DC AS obtains the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal, and determines that the rendering capabilities in the negotiation parameters of the first terminal, the rendering capabilities in the negotiation parameters of the MF network element, and the rendering capabilities in the negotiation parameters of the second terminal do not meet the preset rendering requirements, it requests information about the first entity from the NRF network element.

[0174] Exemplarily again, when the DC AS obtains the negotiation parameters of the first terminal and the negotiation parameters of the MF network element, and determines that the rendering capabilities in the negotiation parameters of the first terminal and the rendering capabilities in the negotiation parameters of the MF network element do not meet the preset rendering requirements, it requests information about the first entity from the NRF network element.

[0175] For the NRF network element, the NRF network element can determine a new MF network element from the network according to the preset rendering requirements, use the new MF network element as the first entity, and then send the information of the first entity to the DC AS. Exemplarily, the first terminal also needs to establish a second ADC with the DC AS based on the new MF network element (instead of establishing a second ADC with the DC AS based on the original MF). Exemplarily, the first request can specifically be an MF network element modification request message, and the first response can specifically be an MF network element modification response message. For ease of description below, the original MF network element can be denoted as the first MF network element, and the new MF network element can be denoted as the second MF network element. The first MF network element and the second MF network element are different. That is, the MF network element used for information transmission in the first ADC is the first MF network element, and the MF network element used for information transmission in the second ADC is the second MF network element.

[0176] Alternatively, the NRF network element can determine a dedicated entity for rendering (also known as a compute node function (CNF) network element) from the network according to a preset rendering requirement, use the CNF network element as the first entity, and then send the information of the first entity to the DC AS. Further, the information of the CNF network element (i.e., the information of the first entity) is carried in the capability negotiation response. The first terminal can also generate a token based on the information of the CNF network element. Thus, the CNF network element requests the first digital human model from the BAR network element according to the token, and then generates the first digital human according to the first digital human model. In addition, in this case, the NRF network element can also determine a CNF network element from the network according to a preset rendering requirement, and then send the information of the CNF network element to the DC AS. The DC AS sends the information of the CNF network element to the first MF network element and uses the first MF network element as the first entity. Further, the information of the first MF network element is carried in the capability negotiation response. Subsequently, the first terminal can generate a token based on the information of the first MF network element. The first MF network element requests the first digital human model according to the token, sends the requested first digital human model to the CNF network element, and the CNF network element generates the first digital human according to the first digital human model and sends the first digital human to the first MF network element.

[0177] In addition, in another implementation, when the NRF network element determines a new MF network element or CNF network element, it does not need to consider the preset rendering requirement. Instead, the DC AS determines whether the new MF network element or CNF network element meets the preset rendering requirement. Exemplarily, the NRF network element returns the information (such as the identifier and rendering capability) of the determined network element to the DC AS through the first response. The DC AS determines whether the rendering capability of the network element can meet the preset rendering requirement according to the preset rendering requirement. If so, the network element is determined as the first entity. Otherwise, the DC AS sends the first request to the NRF network element again until the DC AS requests an entity from the NRF network element whose rendering capability can meet the preset rendering requirement. In this scenario, the first request may not carry the preset rendering requirement. Alternatively, when the NRF network element determines that there is no network element in the network that can meet the preset rendering requirement according to the preset rendering requirement, it can return a failure indication to the DC AS. The failure indication is used to indicate that there is no network element in the current network that can meet the preset rendering requirement.

[0178] In addition, before sending the first request to the NRF network element, the DC AS may not need to determine whether the rendering capability in the negotiation parameters it obtains meets the preset rendering requirement. Exemplarily, in response to the capability negotiation request, the DC AS sends the first request to the NRF network element. Exemplarily, the first request includes the preset rendering requirement. The NRF network element sends the first response to the DC AS, and the first response includes the information of the first entity.

[0179] Step B, the DC AS determines the information of the first BAR network element in response to the capability negotiation request.

[0180] That is, "the DC AS receives the capability negotiation request" serves as the trigger condition for "the DC AS determines the information of the first BAR network element".

[0181] When the DC AS determines the information of the first BAR network element, specifically, the DC AS determines the information of the first BAR network element according to the identifier of the first digital human and the second configuration information in the capability negotiation request. The information of the first BAR network element may specifically be the identifier of the first BAR network element.

[0182] Exemplarily, there are multiple BAR network elements in the network, and each BAR network element stores its own digital human model. Further, the DC AS includes the second configuration information, and the second configuration information includes a list of identifiers of the digital human models stored in each BAR network element (that is, the identifiers of the digital humans corresponding to the digital human models). For example, BAR network element 1 stores digital human models 1 to 10, and BAR network element 2 stores digital human models 11 to 20. The second configuration information includes list 1 corresponding to BAR network element 1 and list 2 corresponding to BAR network element 2. Among them, list 1 includes the identifiers of the digital humans corresponding to digital human models 1 to 10 respectively; list 2 includes the identifiers of the digital humans corresponding to digital human models 11 to 20 respectively. Further, the DC AS can determine the identifier of the BAR network element (i.e., the first BAR network element) storing the first digital human model according to the identifier of the first digital human and the list of identifiers of the digital human models (that is, the identifiers of the digital humans) stored in each BAR network element. Combining the above example, if the first digital human is digital human 5, then the first BAR network element is BAR network element 1.

[0183] Among them, the information of the first BAR network element may also be referred to as the information of the service provider (which can be expressed in English as "audience") and the information of the serving entity. Exemplarily, when the capability negotiation response includes the information of the first entity and the information of the first BAR network element, both the information of the first entity and the information of the first BAR network element can be regarded as rendering negotiation parameters or rendering negotiation results.

[0184] Step C, the DC AS determines whether the first terminal has the permission to use the first digital human model in response to the capability negotiation request.

[0185] That is, "the DC AS receives the capability negotiation request" serves as the trigger condition for "the DC AS determines whether the first terminal has the permission to use the first digital human model".

[0186] Exemplarily, based on the identifier of the first terminal, the DC AS determines whether the identifier of the first digital human is in the list of identifiers of digital humans corresponding to the first terminal. Exemplarily, the DC AS stores a list of identifiers of digital humans that each terminal has permission to use (that is, the list of identifiers of digital humans corresponding to each terminal). The DC AS can determine the list of identifiers of digital humans corresponding to the first terminal according to the identifier of the first terminal. Furthermore, the DC AS determines whether the identifier of the first digital human is in the list of identifiers of digital humans corresponding to the first terminal. If so, it is determined that the first terminal has the permission to use the first digital human model; otherwise, it is determined that the first terminal does not have the permission to use the first digital human model.

[0187] For example, the DC AS includes the list of identifiers of digital humans corresponding to each of Terminal 1 to Terminal 3. The list of identifiers of digital humans corresponding to Terminal 1 includes the identifiers of Digital Human 1 to Digital Human 3. The list of identifiers of digital humans corresponding to Terminal 2 includes the identifiers of Digital Human 2 to Digital Human 3. The list of identifiers of digital humans corresponding to Terminal 3 includes the identifiers of Digital Human 1 to Digital Human 4. Further, the first terminal is Terminal 1 and the first digital human is Digital Human 1. The DC AS can determine, according to the identifier of the first terminal (i.e., Terminal 1), that the list of identifiers of digital humans corresponding to Terminal 1 includes the identifier of the first digital human (i.e., the identifier of Digital Human 1), and determines that the first terminal has the permission to use the first digital human model. Also for example, the first terminal is Terminal 1 and the first digital human is Digital Human 4. The DC AS determines that the list of identifiers of digital humans corresponding to Terminal 1 does not include the identifier of the first digital human (i.e., the identifier of Digital Human 4), and determines that the first terminal does not have the permission to use the first digital human model.

[0188] In this way, it is avoided that the identifier sent by the first terminal is that of a digital human of another terminal, which may lead to the rendering entity rendering the digital human of another terminal or the leakage of the digital human model of that other terminal.

[0189] Furthermore, after receiving the capability negotiation request, the DC AS immediately determines whether the first terminal has the permission to use the first digital human model. The DC AS can discover as early as possible that the first terminal does not have the permission to use the first digital human model, avoiding subsequent return of the information of the first entity and / or the information of the first BAR network element to the first terminal, as well as subsequent rendering processes, etc., which helps to save message transmission resources.

[0190] In addition, in step C, after determining that the first terminal has the permission to use the first digital human model, the DC AS can also store the mapping relationship between the identifier of the first terminal and the identifier of the first digital human. Subsequently, the identifier of the first digital human does not need to be carried again in the token sent by the first terminal.

[0191] Further, when the DC AS selects the MF network element or the second terminal as the first entity, the DC AS can also send the rendering data requirements of the first entity (e.g., the data types required by the first entity when generating the first digital human) as parameters in the capability negotiation response to the first terminal. Correspondingly, when the first terminal collects user information, it can specifically collect the corresponding user information according to the data types required by the first entity, which helps to reduce the workload of the first terminal; or, the first terminal collects all types of user information and then sends the corresponding user information according to the data types required by the first entity, which helps to reduce the data volume of network transmission messages.

[0192] In another example, if the second terminal is the rendering entity and the user information and the token are forwarded by the MF network element, the data types required for the second terminal's rendering can also be added to the token generated by the first terminal. Thus, the MF network element can receive all types of user information collected by the first terminal and, based on the data types required for the second terminal's rendering in the token, delete all types of user information to obtain the data types required by the second terminal, and send the data types required by the second terminal to the second terminal, which helps to reduce the data volume of transmission messages.

[0193] Step 303, the first terminal generates a token according to the information of the first entity.

[0194] The token is used to authorize the first entity to download the first digital human model. Exemplarily, the token includes the information of the first entity. Exemplarily, the token can also carry the identifier of the first digital human.

[0195] When the DC AS also determines the information of the entity for storing the first digital human model (e.g., the information of the first BAR network element), the token can also include the information of the entity for storing the first digital human model. Correspondingly, the token is used to authorize the first entity to download the first digital human model from the information of the entity for storing the first digital human model.

[0196] The following provides two exemplary forms of the token:

[0197] Form 1, the token includes fields for the authorized digital human (which can be expressed in English as avatar), the issuer, the subject, the service provider (which can be expressed in English as audience), and the expiration time field. Among them, the avatar field includes the identifier of the first digital human, the issuer field includes the identifier of the first terminal, the subject field includes the identifier of the first entity, the audience includes the identifier of the first BAR network element, and the expiration time field includes t1.

[0198] Presentation form 2. The token includes the identifier of the first digital person, the identifier of the first terminal, the identifier of the first entity, the identifier of the first BAR network element, and t1. That is, the positions of each piece of information are preset in the token, and then the first terminal fills in the identifier of the first digital person, the identifier of the first terminal, the identifier of the first entity, the identifier of the first BAR network element, and t1 into the corresponding positions of the token respectively.

[0199] Step 304, the first terminal sends the token.

[0200] When the first terminal sends the token, specifically, the first terminal sends a re-invite message, and the re-invite message includes the token. The re-invite message is used to establish the second ADC.

[0201] It can be understood that steps 301 to 303 belong to the rendering capability negotiation process. Before the rendering capability negotiation process, the first terminal and the DC AS have established the first ADC, which is used for rendering capability negotiation. After the rendering capability negotiation process, the first terminal and the DC AS still need to establish the second ADC, and the second ADC is used for transmitting service data. For example, it transmits data between the first terminal and the second terminal (such as data for rendering an entity for rendering (such as user information), and transmits the rendered digital person, etc.).

[0202] Exemplarily, after the rendering capability negotiation process, the first ADC is removed.

[0203] It should be noted that if the first entity is the second MF network element (implementation method 3 of step A), then after the rendering capability negotiation process, the first terminal needs to establish the second ADC with the DC AS based on the second MF network element.

[0204] Based on the first entity being an MF network element, a DC AS, a second terminal, or a first terminal, explain the way for the first entity to obtain the token:

[0205] When the first entity is an MF network element, the first terminal can first send a re-invite message to the IMS AS, and then the IMS AS sends a media resource reserving message to the MF network element. The media resource reserving message includes the token.

[0206] It should be pointed out that after receiving the media resource reserving message, the MF network element can also perform the following verification 1 and / or verification 2:

[0207] Verification 1, the MF network element verifies whether the digital person identifier in the token is consistent with the digital person identifier verified by the previous DC AS;

[0208] Check 2. The MF network element checks whether the digital human identifier in the media resource reservation message is the same as the digital human identifier previously verified by the DC AS.

[0209] For ease of description, Check 1 and Check 2 are used as examples below. Here, the digital human identifier in the token or the digital human identifier in the media resource reservation message can be collectively referred to as the digital human identifier to be verified.

[0210] Exemplarily, the MF network element can perform Check 1 and / or Check 2 based on the following methods:

[0211] Method (1). The MF network element sends a digital human identifier verification result request to the DC AS. The digital human identifier verification result request carries the identifier of the digital human to be verified and the identifier of the first terminal. The DC AS returns the digital human identifier verification result, which is used to indicate whether the identifier of the digital human to be verified is successfully verified.

[0212] Method (2). The MF network element sends a digital human identifier list request to the DC AS / DCSF network element. The digital human identifier list request carries the identifier of the first terminal. The DC AS / DCSF network element returns the digital human identifier list corresponding to the first terminal to the MF network element. Subsequently, the MF network element determines whether the identifier of the digital human to be verified is in the digital human identifier list corresponding to the first terminal.

[0213] It can be understood that when the MF network element determines that Check 1 and / or Check 2 fails, the MF network element may no longer execute the subsequent rendering process.

[0214] When the first entity is the DC AS, the first terminal may first send a re-invitation message to the IMS AS, and then the IMS AS sends media resource reservation to the MF network element. The media resource reservation includes a token. After obtaining the token, the MF network element forwards the token to the DC AS. Exemplarily, after receiving the media resource reservation message, the MF network element may also perform Check 1 and / or Check 2. It can be understood that when the MF network element determines that Check 1 and / or Check 2 fails, the MF network element may no longer forward the token to the DC AS.

[0215] When the first entity is the second terminal, the first terminal may first send a re-invitation message to the IMS AS, and then the IMS AS sends a re-invitation message to the second terminal. Exemplarily, the communication between the terminal and the IMS AS is forwarded via the P / S-CSCF network element. That is, the first terminal may first send a re-invitation message to the P / S-CSCF network element, and the P / S-CSCF network element then sends a re-invitation message to the IMS AS; the IMS AS sends a re-invitation message to the P / S-CSCF network element, and the P / S-CSCF network element then sends a re-invitation message to the second terminal.

[0216] When the first entity is the first terminal, the first terminal can save the token without sending it (i.e., step 304 is an optional step).

[0217] Exemplarily, steps 301 to 303 belong to the steps in the rendering capability negotiation process. In the scenario where the first terminal and the second terminal have a digital human-related call, the first terminal can negotiate the rendering capability with the network through the first ADC. Specifically, it can be negotiated who will perform the rendering during the digital human rendering process and what data type will be used for rendering. Exemplarily, step 304 belongs to the establishment process of the second ADC. After the first terminal negotiates the rendering capability with the network, it can further request to establish the second ADC. The second ADC is used for data transmission in the rendering process, and the first terminal can send the token based on the re-invitation message for requesting to establish the second ADC.

[0218] In Figure 3 the relevant process, the first entity obtains the token. Subsequently, the first entity can request the first digital human model based on the token. Specifically, reference can be made to Figure 4 the schematic flowchart of the second communication method provided exemplarily. This method can be executed by the first entity and the first BAR network element.

[0219] Step 401, the first entity sends the token to the first BAR network element. Correspondingly, the first BAR network element receives the token from the first entity.

[0220] Exemplarily, the first entity sends a digital human model download request (download avatar representation) to the first BAR network element. The digital human model download request includes the token. The digital human model download request may also include the identifier of the first digital human and the identifier of the first terminal.

[0221] Based on whether the first entity is an agent entity or a rendering entity, the following is an exemplary description by cases:

[0222] Case 1, the first entity is an agent entity, that is, the first entity is a DC AS. The DC AS acts as an agent for the rendering entity to send a digital human model download request to the first BAR network element. The rendering entity can be the first terminal, the second terminal, or the MF network element. The digital human model download request also carries the client credentials assertion (CCA) corresponding to the rendering entity. The specific verification method is described in step 402.

[0223] Case 2, the first entity is a rendering entity:

[0224] Case 2.1, the first entity is the first terminal, and the first terminal sends a digital human model download request to the MF network element; the MF network element sends a digital human model download request to the DC AS; the DC AS sends a digital human model download request to the first BAR network element.

[0225] Exemplarily, after receiving the digital human model download request, the MF network element may further perform the above-mentioned verification 1 and / or verification 2. It can be understood that when the MF network element determines that verification 1 and / or verification 2 fails, the MF network element may no longer forward the digital human model download request to the DC AS.

[0226] Case 2.2, the first entity is the second terminal, and the second terminal sends a digital human model download request to the MF network element; the MF network element sends a digital human model download request to the DC AS; the DC AS sends a digital human model download request to the first BAR network element.

[0227] Exemplarily, after receiving the digital human model download request, the MF network element may further perform the above-mentioned verification 1 and / or verification 2. It can be understood that when the MF network element determines that verification 1 and / or verification 2 fails, the MF network element may no longer forward the digital human model download request to the DC AS.

[0228] Case 2.3, the first entity is the MF network element, and the MF network element sends a digital human model download request to the DC AS; the DC AS sends a digital human model download request to the first BAR network element.

[0229] Step 402, the first BAR network element determines that the verification is passed according to the token.

[0230] In a possible example, the token includes information of the first entity. The first BAR network element may determine, according to the information of the first entity included in the token, that the entity sending the token is the entity authorized to download the first digital human model by the token, and then determine that the verification is passed.

[0231] Combined with whether the first entity is an agent entity or a rendering entity, the following exemplary cases are described separately:

[0232] Case 1, the first entity is an agent entity, that is, the first entity is the DC AS. When the first BAR network element establishes a transport layer security (TLS) channel with the DC AS, it confirms the identity of the DC AS; further, after the first BAR network element determines that the information of the first entity in the token is the information of the DC AS, it determines that the verification is passed.

[0233] Case 2, the first entity is a rendering entity:

[0234] Case 2.1: The first entity is the first terminal. The first BAR network element verifies that the signature of the token passes based on the public key of the first terminal (equivalent to determining that the issuer in the token is the first terminal), further determines that the issuer and the subject in the token are consistent, and thus determines that the verification passes.

[0235] Case 2.2: When the first entity is the MF network element and the MF network element communicates end-to-end with the first BAR network element, the first BAR network element confirms the identity of the MF network element when establishing a TLS channel with the MF network element. Further, after the first BAR network element determines that the information of the first entity in the token is the information of the MF network element, it determines that the verification passes.

[0236] When the first entity is the MF network element and the MF network element communicates end-to-end with the first BAR network element through the DC AS proxy, the first BAR network element confirms the identity of the DC AS when establishing a TLS channel with the DC AS, and then obtains the CCA from the digital human model download request, where the CCA includes the information of the MF network element. After the first BAR network element verifies that the subject in the token is the information of the MF network element in the CCA, it determines that the verification passes.

[0237] Case 2.3: The first entity is the second terminal. When the second terminal communicates end-to-end with the first BAR network element, the first BAR network element confirms the identity of the second terminal when establishing a TLS with the second terminal. Further, after the first BAR network element determines that the information of the first entity in the token is the information of the second terminal, it determines that the verification passes.

[0238] When the first entity is the second terminal and the second terminal communicates end-to-end with the first BAR network element through the DC AS proxy, the first BAR network element confirms the identity of the DC AS when establishing a TLS channel with the DC AS, and then obtains the CCA from the digital human model download request, where the CCA includes the information of the second terminal. After the first BAR network element verifies that the subject in the token is the information of the second terminal in the CCA, it determines that the verification passes.

[0239] In addition, the token may also include the information of the first BAR network element. The first BAR network element can also determine that it is the network element authorized to provide the first digital human model based on the information of the first BAR network element included in the token. That is, when the first BAR network element determines that the entity sending the token is the entity authorized to download the first digital human model based on the information of the first entity included in the token, and determines that it is the network element authorized to provide the first digital human model based on the information of the first BAR network element included in the token, it determines that the verification passes.

[0240] Step 403: The first BAR network element sends the first digital human model to the first entity.

[0241] Exemplarily, after the first BAR network element determines that the verification is passed according to the token, it sends the first digital human model to the first entity. Exemplarily, the first BAR network element sends a digital human model response to the first entity, and the digital human model response includes the first digital human model. In addition, when the first BAR network element determines that the verification fails according to the token, the first BAR network element sends a response indicating verification failure to the first entity.

[0242] Step 404, when the first entity is a rendering entity, the first entity generates a digital human according to the first digital human model; when the first entity is an agent entity of the rendering entity, the first entity sends the first digital human model to the rendering entity, and the rendering entity generates a digital human according to the first digital human model.

[0243] It should be added that Figure 4 The related embodiments are described by taking the first entity (i.e., the entity that authorizes the first terminal to download the first digital human model) as an example. In this embodiment, it is also described that the second entity sends a token to the first BAR network element. Correspondingly, the first BAR network element can determine whether the second entity is the entity authorized by the token (i.e., the first entity). If the first BAR network element determines that the second entity is the entity authorized by the token, it determines that the verification is passed; if the first BAR network element determines that the second entity is not the entity authorized by the token, it determines that the verification fails.

[0244] Figure 4 The related embodiments are described by taking the first BAR network element (i.e., the entity that provides the first digital human model) as an example. In this embodiment, it is also described that the second entity sends a token to the second BAR network element. The second BAR network element not only needs to determine whether the second entity is the entity authorized by the token, but also needs to determine whether it is the BAR network element indicated by the token (i.e., determine whether the second BAR network element is the first BAR network element). Further, if the second BAR network element determines that the second entity is the entity authorized by the token and it is the BAR network element indicated by the token, it determines that the verification is passed and provides the first digital human model to the second entity; otherwise, it determines that the verification fails and does not provide the first digital human model to the second entity.

[0245] It can be understood that Figure 4 The related embodiments can be executed by a third communication device, and the third communication device can be the second BAR network element or a part (such as a chip) in the second BAR network element.

[0246] Combined with the above Figure 3 and Figure 4 descriptions in the related embodiments, such as Figure 5Schematic diagram of the process of the third communication method provided exemplarily for this application. Specifically, in this communication method, the DC AS determines the information of a first entity according to first configuration information, where the first entity is an MF network element. Further, the MF network element requests a first digital human model from a first BAR network element and generates a first digital human based on the first digital human model.

[0247] Step 501: Establish a first ADC between the first terminal and the DC AS. The first ADC is used for rendering negotiation. Exemplarily, before step 501, the following is further included: Establish a bootstrap data channel (BDC) between the first terminal and the DC AS.

[0248] Step 502: The first terminal sends a capability negotiation request to the DC AS. Correspondingly, the DC AS receives the capability negotiation request from the first terminal. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. The specific implementation of step 502 can refer to the description in step 301.

[0249] Step 503: The DC AS determines that the first terminal has the permission to use the first digital human model. The specific implementation of step 503 can refer to the description in step C.

[0250] Step 504: The DC AS determines the information of the first entity according to the first configuration information; the DC AS determines the information of the first BAR network element according to the second configuration information. The first configuration information and the second configuration information can be collectively referred to as configuration information. The information of the first entity is also the information of the MF network element, for example, the identifier of the MF network element. The information of the first BAR network element is, for example, the identifier of the first BAR network element. The specific implementation of step 504 can refer to the descriptions in step A and step B.

[0251] Step 505: The DC AS determines the capability negotiation result. Exemplarily, the DC AS determines the type of rendering data used by the MF network element during the rendering of the first digital human according to the rendering data requirements of the MF network element. The capability negotiation result includes this type of rendering data.

[0252] Step 506: The DC AS sends a capability negotiation response to the first terminal. Correspondingly, the first terminal receives the capability negotiation response from the DC AS. The capability negotiation response includes the capability negotiation result, the information of the MF network element, and the information of the first BAR network element. The specific implementation of step 506 can refer to the description in step 302.

[0253] Step 507, the first terminal sends a re-invitation message to the IMS AS. Correspondingly, the IMS AS receives the re-invitation message from the first terminal. The re-invitation message includes a token and the identifier of the first digital human. Exemplarily, the subject field in the token is the information of the MF network element, the issuer field is the identifier of the first terminal, and the audience field is the information of the first BAR network element. Among them, the specific implementation of step 507 can be referred to the description in 304. Exemplarily, before step 507, the first terminal can also generate a token according to the information of the MF network element and the information of the first BAR network element, and the specific implementation can be referred to the description in 303.

[0254] Step 508, the IMS AS sends a media resource reservation message to the MF network element. Correspondingly, the MF network element receives the media resource reservation message from the IMS AS. The media resource reservation message includes a token and the identifier of the first digital human. The specific implementation of step 508 can be referred to the description in 304.

[0255] Step 509, the MF network element sends a digital human model download request to the first BAR network element. Correspondingly, the first BAR network element receives the digital human model download request from the MF network element. The digital human model download request includes the identifier of the first terminal, the token, and the identifier of the first digital human. Among them, the specific implementation of step 509 can be referred to the description in 401.

[0256] Step 510, the first BAR network element sends a digital human model response to the MF network element. Correspondingly, the MF network element receives the digital human model response from the first BAR network element. Among them, the digital human model response includes the first digital human model. Among them, the specific implementation of step 510 can be referred to the description in 403. Exemplarily, before step 510, the first BAR network element can also determine that the verification is passed after determining that the subject field in the token is the information of the MF network element and the audience field is the information of the first BAR network element, and the specific implementation can be referred to the description in 402.

[0257] Step 511, the MF network element generates the first digital human according to the first digital human model.

[0258] Figure 5 In related embodiments, steps 502 to 506 belong to the rendering capability negotiation process, steps 507 and 508 belong to the second ADC establishment process, and steps 509 to 511 are the digital human rendering process. It can be understood that Figure 5 Only exemplary steps related to the present application are shown. In the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, other steps may also be included, which are not listed in the present application.

[0259] Combined with the above Figure 3 andFigure 4 as described in the related embodiments, such as Figure 6 FIG. 559 is a schematic flowchart of a fourth communication method provided exemplarily for this application. In this communication method, specifically, DC AS determines the information of a first entity according to first configuration information. Further, the first entity is a first terminal, and the first terminal requests a first digital human model from a first BAR network element and generates a first digital human based on the first digital human model.

[0260] Step 601: Establish a first ADC between the first terminal and DC AS. The first ADC is used for rendering negotiation. Exemplarily, before step 601, it further includes: establishing a BDC between the first terminal and DC AS.

[0261] Step 602: The first terminal sends a capability negotiation request to DC AS. Correspondingly, DC AS receives the capability negotiation request from the first terminal. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. The specific implementation of step 602 can refer to the description in step 301.

[0262] Step 603: DC AS determines that the first terminal has the permission to use the first digital human model. The specific implementation of step 603 can refer to the description in step C.

[0263] Step 604: DC AS determines the information of the first entity according to the first configuration information; DC AS determines the information of the first BAR network element according to the second configuration information. The first configuration information and the second configuration information can be collectively referred to as configuration information. The information of the first entity is also the information of the first terminal, for example, the identifier of the first terminal. The information of the first BAR network element is, for example, the identifier of the first BAR network element. The specific implementation of step 604 can refer to the descriptions in step A and step B.

[0264] Step 605: DC AS determines the capability negotiation result. Exemplarily, DC AS determines the type of rendering data used by the first terminal during the rendering of the first digital human according to the rendering data requirements of the first terminal. The capability negotiation result includes this type of rendering data.

[0265] Step 606: DC AS sends a capability negotiation response to the first terminal. Correspondingly, the first terminal receives the capability negotiation response from DC AS. The capability negotiation response includes the capability negotiation result, the information of the first terminal, and the information of the first BAR network element. The specific implementation of step 606 can refer to the description in step 302.

[0266] Step 607, the first terminal sends a digital human model download request to the first BAR network element. Correspondingly, the first BAR network element receives the digital human model download request from the first terminal. The digital human model download request includes the identifier of the first terminal, a token, and the identifier of the first digital human. Exemplarily, the subject field in the token is the information of the first terminal, the issuer field is the identifier of the first terminal, and the audience includes the information of the first BAR network element. Among them, the specific implementation of step 607 can be referred to the description in 304. Exemplarily, before step 607, the first terminal can also generate a token according to the information of the first terminal and the information of the first BAR network element, and the specific implementation can be referred to the description in 303.

[0267] Step 608, the first BAR network element sends a digital human model response to the first terminal. Correspondingly, the first BAR network element receives the digital human model response from the first BAR network element. Among them, the digital human model response includes the first digital human model. Among them, the specific implementation of step 608 can be referred to the description in 403. Exemplarily, before step 608, after the first BAR network element determines that the subject field in the token is the information of the first terminal and the audience field is the information of the first BAR network element, it determines that the verification is passed, and the specific implementation can be referred to the description in 402.

[0268] Step 609, the first terminal generates the first digital human according to the first digital human model.

[0269] Among them, steps 602 to 606 belong to the rendering capability negotiation process, and steps 607 to 609 are the digital human rendering process. It can be understood that Figure 6 Only exemplary steps related to the present application are shown. In the rendering capability negotiation process and the digital human rendering process, other steps may also be included. Before the digital human rendering process, the first terminal will also send a re-invite message to the IMS AS to request the establishment of a second ADC, which is not listed in the present application.

[0270] Such as Figure 7 As shown in the flowchart of the fifth communication method provided exemplarily in the present application, in this communication method, specifically, the DC AS determines the information of the first entity according to the first configuration information. Further, the first entity is the second terminal, and the second terminal also requests the first digital human model from the first BAR network element and generates the first digital human based on the first digital human model.

[0271] Step 701, establish a first ADC between the first terminal and the DC AS. Exemplarily, before step 701, it further includes: establishing a BDC between the first terminal and the DC AS.

[0272] Step 702: The first terminal sends a capability negotiation request to the DC AS. Correspondingly, the DC AS receives the capability negotiation request from the first terminal. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. For the specific implementation of step 702, refer to the description in step 301.

[0273] Step 703: The DC AS determines that the first terminal has the permission to use the first digital human model. For the specific implementation of step 703, refer to the description in step C.

[0274] Step 704: The DC AS determines the information of the first entity according to the first configuration information; the DC AS determines the information of the first BAR network element according to the second configuration information. The first configuration information and the second configuration information can be collectively referred to as configuration information. The information of the first entity is also the information of the second terminal, for example, the identifier of the second terminal. The information of the first BAR network element is, for example, the identifier of the first BAR network element. For the specific implementation of step 704, refer to the descriptions in steps A and B.

[0275] Step 705: The DC AS determines the capability negotiation result. Exemplarily, the DC AS determines the type of rendering data used by the second terminal during the rendering of the first digital human according to the rendering data requirements of the second terminal. The capability negotiation result includes this type of rendering data.

[0276] Step 706: The DC AS sends a capability negotiation response to the first terminal. Correspondingly, the first terminal receives the capability negotiation response from the DC AS. The capability negotiation response includes the capability negotiation result, the information of the second terminal, and the information of the first BAR network element. For the specific implementation of step 706, refer to the description in step 302.

[0277] Step 707: The first terminal sends a re-invite message to the IMS AS. Correspondingly, the IMS AS receives the re-invite message from the first terminal. The re-invite message includes a token and the identifier of the first digital human. Exemplarily, the subject field in the token is the information of the second terminal, the issuer field is the identifier of the first terminal, and the audience includes the information of the first BAR network element. For the specific implementation of step 707, refer to the description in 304. Exemplarily, before step 707, the first terminal can also generate a token according to the information of the second terminal and the information of the first BAR network element. For the specific implementation, refer to the description in 303.

[0278] Step 708: The IMS AS sends a re-invite message to the P / S-CSCF network element. Correspondingly, the P / S-CSCF network element receives the re-invite message from the IMS AS.

[0279] Step 709, the P / S-CSCF network element sends a re-invitation message to the second terminal. Correspondingly, the second terminal receives the re-invitation message from the P / S-CSCF network element.

[0280] Step 710, the second terminal sends a digital human model download request to the first BAR network element. Correspondingly, the first BAR network element receives the digital human model download request from the second terminal. The digital human model download request includes the identifier of the first terminal, the token, and the identifier of the first digital human. Among them, the specific implementation of step 710 can be referred to the description in 401.

[0281] Step 711, the first BAR network element sends a digital human model response to the second terminal. Correspondingly, the second terminal receives the digital human model response from the first BAR network element. Among them, the digital human model response includes the first digital human model. Among them, the specific implementation of step 711 can be referred to the description in 403. Exemplarily, before step 711, the first BAR network element can also determine that the verification is passed after determining that the subject field in the token is the information of the second terminal and the audience field is the information of the first BAR network element. The specific implementation can be referred to the description in 402.

[0282] Step 712, the second terminal generates a first digital human according to the first digital human model.

[0283] Among them, steps 702 to 706 belong to the rendering capability negotiation process, steps 707 to 709 belong to the second ADC establishment process, and steps 710 to 712 are the digital human rendering process. It can be understood that Figure 7 Only exemplary steps related to the present application are shown. In the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, other steps may also be included, which are not listed in the present application.

[0284] Such as Figure 8 This is a schematic flowchart of the sixth communication method provided exemplarily by the present application. In this communication method, specifically, the DC AS determines the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the second terminal, and the negotiation parameters of the MF network element. Further, the first entity is the MF network element, and the MF network element also requests the first digital human model from the first BAR network element and generates a first digital human based on the first digital human model.

[0285] Step 801, establish a first ADC between the first terminal and the DC AS. The first ADC is used for rendering negotiation. Exemplarily, before step 801, it further includes: establishing a BDC between the first terminal and the DC AS.

[0286] Step 802, the first terminal sends a capability negotiation request to the DC AS. Correspondingly, the DC AS receives the capability negotiation request from the first terminal. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. The specific implementation of step 802 can be referred to the description in step 301.

[0287] Step 803, the DC AS determines that the first terminal has the permission to use the first digital human model. The specific implementation of step 803 can be referred to the description in step C.

[0288] Step 804, the DC AS sends a rendering capability request to the MF network element. Correspondingly, the MF network element receives the rendering capability request from the DC AS. The rendering capability request includes the identifier of the second terminal and is used to request the negotiation parameters of the second terminal. The negotiation parameters of the second terminal include the rendering capability of the second terminal and the candidate entities recommended by the second terminal. The specific implementation of step 804 can be referred to the description in step A.

[0289] Step 805, the MF network element sends a rendering capability request to the second terminal. Correspondingly, the second terminal receives the rendering capability request from the MF network element. The specific implementation of step 805 can be referred to the description in step A.

[0290] Step 806, the second terminal sends a rendering capability response to the MF network element. Correspondingly, the MF network element receives the rendering capability response from the second terminal. The rendering capability response of the second terminal includes the negotiation parameters of the second terminal. The specific implementation of step 806 can be referred to the description in step A.

[0291] Step 807, the MF network element sends a rendering capability response to the DC AS. Correspondingly, the DC AS receives the rendering capability response from the MF network element. The rendering capability response of the MF network element includes the negotiation parameters of the second terminal and the negotiation parameters of the MF network element. The negotiation parameters of the MF network element include the rendering capability of the MF network element and the candidate entities recommended by the MF network element. The specific implementation of step 807 can be referred to the description in step A.

[0292] Step 808, the DC AS determines the information of the first entity (i.e., the information of the MF network element) according to the negotiation parameters of the first terminal, the negotiation parameters of the second terminal and the negotiation parameters of the MF network element. And, the DC AS determines the information of the first BAR network element according to the second configuration information. The specific implementation of step 808 can be referred to the descriptions in step A and step B.

[0293] Step 809, the DC AS determines the result of the capability negotiation. Exemplarily, the DC AS determines the type of rendering data used by the MF network element during the rendering of the first digital human according to the rendering data requirements of the MF network element, and the rendering data type is included in the result of the capability negotiation.

[0294] Step 810, the DC AS sends a capability negotiation response to the first terminal. Correspondingly, the first terminal receives the capability negotiation response from the DC AS. The capability negotiation response includes the result of the capability negotiation, information about the MF network element, and information about the first BAR network element. For the specific implementation of step 810, reference may be made to the description in step 302.

[0295] After step 810, steps 507 to 511 may further be included. Steps 802 to 810 belong to the rendering capability negotiation process. It can be understood that Figure 8 Only exemplary steps related to the present application are shown. In the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, other steps may further be included, which are not listed in the present application.

[0296] In addition, in Figure 8 related embodiments, if the first entity is the first terminal, steps 607 to 609 may further be included after step 810. If the first entity is the second terminal, steps 707 to 712 may further be included after step 810. Details are not described one by one.

[0297] As Figure 9 shown in the flowchart of the seventh communication method provided exemplarily for the present application, in this communication method, specifically, the DC AS fails to determine the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the second terminal, and the negotiation parameters of the MF network element, and the DC AS requests the information of the first entity from the NRF network element. Further, the first entity is a new MF network element (i.e., the second MF network element), and the second MF network element also requests the first digital human model from the first BAR network element and generates the first digital human based on the first digital human model.

[0298] Figure 9 The difference between the related embodiments in Figure 8 related embodiments is that after step 807, the DC AS determines that the rendering capabilities of the first terminal, the second terminal, and the first MF network element do not meet the preset rendering requirements. The following description starts from after step 807:

[0299] Step 901, the DC AS determines that the rendering capabilities of the first terminal, the second terminal, and the first MF network element do not meet the preset rendering requirements. The DC AS determines the information of the first BAR network element according to the second configuration information. For the specific implementation of step 901, reference may be made to the description in steps A and B.

[0300] Step 902, the DC AS sends a first request to the NRF network element. Correspondingly, the NRF network element receives the first request from the DC AS. The first request includes a preset rendering requirement. The first request is used to request information about a first entity that meets the preset rendering requirement from the NRF network element. For the specific implementation of step 902, refer to the description in step A.

[0301] Step 903, the NRF network element sends a first response to the DC AS. Correspondingly, the DC AS receives the first response sent by the NRF network element. The first response includes information about the first entity (i.e., information about the second MF network element). In a specific example, the NRF network element determines the information about the second MF network element according to the preset rendering requirement and sends a first response to the DC AS. For the specific implementation of step 903, refer to the description in step A.

[0302] Step 904, the DC AS sends the information of the second MF network element to the IMS AS. The information of the second MF network element is used by the DC AS to update the MF network element so that a second ADC is established between the first terminal and the DC AS based on the second MF network element. Exemplarily, the DC AS may also send the information of the second MF network element to the DCSF network element. The information of the second MF network element is used by the DCSF network element to update the MF network element so that a second ADC is established between the first terminal and the DC AS based on the second MF network element. For the specific implementation of step 904, refer to the description in step A.

[0303] After step 904, it may further include: steps 507 to 511, with the difference that the first MF therein is replaced by the second MF. Among them, steps 901 to 904 belong to the rendering capability negotiation process. It can be understood that Figure 9 Only exemplary steps related to this application are shown. In the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, there may be other steps, which are not listed in this application.

[0304] It should also be supplemented that the above embodiments are all described by taking the determination of the information of the first entity by the DC AS as an example. In other possible examples, it may also be the MF network element, the first terminal, the second terminal, or other network elements that determine the information of the first entity. Exemplarily, in the case where the MF network element determines the information of the first entity, when the capability negotiation request of the first terminal is sent to the MF network element, the MF network element can determine the information of the first entity. Exemplarily, in the case where the first terminal determines the information of the first entity, the first terminal can determine the information of the first entity before the capability negotiation. Exemplarily, in the case where the second terminal determines the information of the first entity, after receiving the capability negotiation request, the DC AS can request the information of the first entity from the second terminal. Correspondingly, the second terminal can return the information of the first entity to the DC AS, or directly send the information of the first entity to the first terminal. Exemplarily, in the case where other network elements determine the information of the first entity, after receiving the capability negotiation request, the DC AS can forward the capability negotiation request to the other network element, and the other network element determines the information of the first entity. Then, the other network element forwards the information of the first entity to the first terminal through the DC AS, or the other network element directly sends the information of the first entity to the first terminal.

[0305] The step numbers in the flowcharts described in the above multiple embodiments are only an example of the execution process, and do not constitute a limitation on the order of execution of the steps. There is no strict execution order between the steps that have no timing dependence relationship in the embodiments of the present application. The steps shown in each flowchart are not all steps that must be executed. Some steps can be deleted based on the actual needs on the basis of each flowchart, or other possible steps can be added based on the actual needs on the basis of each flowchart.

[0306] The above focuses on describing the differences between the embodiments. Except for the differences, the other contents between the embodiments can be referred to each other; in addition, in the same embodiment, different implementation manners or different examples can also be referred to each other.

[0307] Based on the above content and the same concept, Figure 10 and Figure 11 are the structural schematic diagrams of possible communication devices provided by the present application. These communication devices can be used to implement the functions of the first terminal or the DC AS in the above method embodiments, and thus can also achieve the beneficial effects possessed by the above method embodiments. In the present application, the communication device can be, for example, Figures 2A to 2C the first terminal in any one of the figures (or a module in the first terminal (such as a chip)), or it can also be Figure 2C the DC AS in

[0308] such as Figure 10As shown, the communication device 1000 includes a processing module 1001 and a transceiver module 1002.

[0309] When the communication device 1000 is used to implement Figures 3 to 9 the function of the first terminal in any of the illustrated method embodiments:

[0310] The transceiver module 1002 is configured to send a capability negotiation request, where the capability negotiation request carries the identifier of the digital human, and the capability negotiation request is used to negotiate the rendering of the digital human; and, receive a capability negotiation response, where the capability negotiation response includes information about the first entity, and the first entity is the entity for downloading the digital human model, and the digital human model is used for the rendering of the digital human;

[0311] The processing module 1001 is configured to generate a token according to the information about the first entity, and the token is used to authorize the first entity to download the digital human model;

[0312] The transceiver module 1002 is further configured to send the token.

[0313] In a possible implementation, the token includes the information about the first entity and the identifier of the digital human.

[0314] In a possible implementation, the token is carried in a re-invitation message.

[0315] In a possible implementation, the capability negotiation response further includes information about the entity for storing the digital human model, and the token includes the information about the entity for storing the digital human model.

[0316] In a possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal related to the call.

[0317] In a possible implementation, the capability negotiation request carries the negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entities recommended by the first terminal; the candidate entities include one or more of the MF network element, first terminal, and second terminal related to the call.

[0318] In a possible implementation, the capability negotiation request is sent by the transceiver module 1002 to the DCAS through the first ADC, and the first ADC is the channel between the transceiver module 1002 and the DC AS.

[0319] When the communication device 1000 is used to implement Figures 3 to 9 the function of the DC AS in any of the illustrated method embodiments:

[0320] The transceiver module 1002 is used to receive an ability negotiation request, where the digital human identifier is carried in the ability negotiation request, and the ability negotiation request is used to negotiate the rendering of the digital human;

[0321] The processing module 1001 is used to determine the information of the first entity;

[0322] The transceiver module 1002 is further used to send an ability negotiation response, where the information of the first entity is included in the ability negotiation response. The first entity is the entity used to download the digital human model, and the digital human model is used for the rendering of the digital human;

[0323] Among them, the information of the first entity is used for the first terminal to generate a token, and the token is used to authorize the first entity to download the digital human model.

[0324] In a possible implementation manner, the information of the entity used to store the digital human model is further included in the ability negotiation response.

[0325] In a possible implementation manner, the negotiation parameter of the first terminal is carried in the ability negotiation request; the negotiation parameter of the first terminal includes the rendering ability of the first terminal and / or the candidate entity recommended by the first terminal; the candidate entity includes one or more of the MF network element related to the call, the first terminal, and the second terminal; in a possible implementation manner, when determining the information of the first entity, the processing module 1001 is specifically used to determine the information of the first entity according to the negotiation parameter of the first terminal.

[0326] In a possible implementation manner, when determining the information of the first entity according to the negotiation parameter of the first terminal, the processing module 1001 is specifically used to obtain the negotiation parameter of the MF network element and the negotiation parameter of the second terminal from the MF network element; determine the information of the first entity according to the negotiation parameter of the first terminal, the negotiation parameter of the MF network element, and the negotiation parameter of the second terminal.

[0327] In a possible implementation manner, the first entity is one of the DC AS, MF network element, first terminal, and second terminal related to the call.

[0328] In a possible implementation manner, when the processing module 1001 determines that the negotiation parameters of the first terminal, the MF network element, and the second terminal do not meet the preset rendering requirements, the transceiver module 1002 is further used to send a first request to the NRF network element. The first request includes the preset rendering requirements, and the first request is used to request the first entity that meets the preset rendering requirements; and receive a first response from the NRF network element, where the information of the first entity is included in the first response.

[0329] In a possible implementation, the capability negotiation request is sent by the first terminal to the transceiver module 1002 through the first ADC; wherein, the first ADC is the channel between the first terminal and the transceiver module 1002. In other words, the capability negotiation request is the information received from the first terminal by the transceiver module 1002 through the first ADC.

[0330] As Figure 11 shown in the apparatus 1100 provided by the embodiment of the present application, Figure 11 the shown apparatus may be Figure 10 a hardware circuit implementation of the shown apparatus. The apparatus is applicable to the flowchart shown above and executes the functions of the first terminal or the DC AS in the above method embodiment. For the sake of convenience of description, Figure 11 only the main components of the apparatus are shown.

[0331] Figure 11 The shown apparatus 1100 includes a communication interface 1110, a processor 1120, and a memory 1130, wherein the memory 1130 is used to store program instructions and / or data. The processor 1120 may cooperate with the memory 1130. The processor 1120 may execute the program instructions stored in the memory 1130. When the instructions or programs stored in the memory 1130 are executed, the processor 1120 is used to execute the operations performed by the processing module 1001 in the above embodiments, and the communication interface 1110 is used to execute the operations performed by the transceiver module 1002 in the above embodiments.

[0332] The memory 1130 and the processor 1120 are coupled. The coupling in the embodiment of the present application is an indirect coupling or communication connection between devices, units, or modules, which may be electrical, mechanical, or other forms, and is used for information interaction between devices, units, or modules. At least one of the memory 1130 may be included in the processor 1120.

[0333] In the embodiment of the present application, the communication interface may be a transceiver, a circuit, a bus, a module, or other types of communication interfaces. In the embodiment of the present application, when the communication interface is a transceiver, the transceiver may include an independent receiver, an independent transmitter; or a transceiver integrating transceiver functions, or a communication interface.

[0334] The apparatus 1100 may further include a communication line 1140. Among them, the communication interface 1110, the processor 1120, and the memory 1130 may be interconnected through the communication line 1140; the communication line 1140 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication line 1140 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 11 it is only represented by a thick line in the figure, but it does not mean that there is only one bus or one type of bus.

[0335] Based on the above content and the same concept, the present application further provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed by a communication device, it implements the method executed by the first terminal in the above method embodiment, or implements the method executed by the DC AS in the above method embodiment.

[0336] Based on the above content and the same concept, the present application further provides a computer program product. The computer program product includes a computer program or instruction. When the computer program or instruction is executed by a communication device, it implements the method executed by the first terminal in the above method embodiment, or implements the method executed by the DC AS in the above method embodiment.

[0337] Based on the above content and the same concept, the present application further provides a communication system, including: a first communication device and / or a second communication device; the first communication device implements the method executed by the first terminal in the above method embodiment, and the second communication device implements the method executed by the DC AS in the above method embodiment.

[0338] In the embodiments of the present application, for the number of nouns, unless otherwise specified, it means "singular noun or plural noun", that is, "one or more". "At least one" means one or more, and "multiple" means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally represents that the associated objects before and after are an "or" relationship. For example, A / B means: A or B. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (item) or plural items (items). For example, at least one (item) of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0339] In the embodiments of the present application, "send" and "receive" indicate the direction of signal transmission. For example, "sending information to XX" can be understood as the destination of the information being XX. "Receiving information from YY" can be understood as the source of the information being YY. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can be carried out between devices. For example, between an MF network element and a terminal, or can be carried out within a device. For example, sending or receiving between components, modules, chips, software modules or hardware modules within a device through a bus, trace or interface.

[0340] In the embodiments of the present application, "when", "if", and "in case" all refer to the device making corresponding processing under certain objective circumstances, not limited to time, and do not require the device to have a judgment action when implemented, nor does it mean there are other limitations. Unless otherwise specified, "if" and "in case" can be replaced, and "when" can be replaced with "in the case of". "When" can be replaced with "if" / "in case".

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

[0342] The ordinal numbers such as "first" and "second" mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority or importance of multiple objects. For example, the first indication information and the second indication information refer to two different indication information, and do not indicate differences in the priority or importance of these two indication information.

[0343] It can be understood that the various numerical numbers involved in the embodiments of the present application are only for the convenience of description and do not limit the scope of the embodiments of the present application. The magnitudes of the sequence numbers of the above processes do not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic.

Claims

1. A communication method, applied to a scenario where a first terminal and a second terminal conduct a digital human-related conversation, characterized in that: include: The first communication device sends a capability negotiation request, the capability negotiation request carries an identifier of the digital human, and the capability negotiation request is used to negotiate the rendering of the digital human; The first communication device receives a capability negotiation response, wherein the capability negotiation response includes information of a first entity, wherein the first entity is an entity used to download a digital human model, and the digital human model is used for rendering the digital human; The first communication device generates a token according to the information of the first entity, wherein the token is used to authorize the first entity to download the digital human model; The first communication device sends the token; The first communication device is the first terminal, or a part of the first terminal.

2. The method according to claim 1, characterized in that The token includes information of the first entity and an identification of the digital person.

3. The method according to claim 1 or 2, characterized in that The token is carried in the re-invite message.

4. The method according to any one of claims 1 to 3, characterized in that: The capability negotiation response also includes information of an entity used to store the digital human model, and the token includes the information of the entity used to store the digital human model.

5. The method according to any one of claims 1 to 4, characterized in that: The first entity is one of a data channel application server, a media function network element, the first terminal and the second terminal related to the call.

6. The method according to any one of claims 1 to 5, characterized in that: The capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entity recommended by the first terminal; The candidate entities include one or more of a media function network element related to the call, the first terminal, and the second terminal.

7. The method according to any one of claims 1 to 6, characterized in that: The capability negotiation request is sent by the first communication device to a data channel application server via an application data channel; The application data channel is a channel between the first communication device and the data channel application server.

8. A communication method, applied to a scenario where a first terminal and a second terminal conduct a digital human-related conversation, characterized in that: include: The second communication device receives a capability negotiation request, the capability negotiation request carries an identifier of the digital human, and the capability negotiation request is used to negotiate the rendering of the digital human; The second communication device sends a capability negotiation response, wherein the capability negotiation response includes information of a first entity, wherein the first entity is an entity used to download a digital human model, and the digital human model is used to render the digital human; The information of the first entity is used to generate a token, and the token is used to authorize the first entity to download the digital human model, and the second communication device is a data channel application server related to the call or a part of the data channel application server.

9. The method according to claim 8, characterized in that The capability negotiation response also includes information of an entity used to store the digital human model.

10. The method according to claim 8 or 9, characterized in that The capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entity recommended by the first terminal; The candidate entity includes one or more of a media function network element related to the call, the first terminal, and the second terminal; After the second communication device receives the capability negotiation request, the method further includes: The second communication device determines the information of the first entity according to the negotiation parameters of the first terminal.

11. The method according to claim 10, characterized in that The second communication device determines the information of the first entity according to the negotiation parameter of the first terminal, including: The second communication device obtains a negotiation parameter of the media function network element and a negotiation parameter of the second terminal; The second communication device determines the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the media function network element and the negotiation parameters of the second terminal.

12. The method according to any one of claims 8 to 11, characterized in that: The first entity is one of a data channel application server, a media function network element, the first terminal and the second terminal related to the call.

13. The method according to claim 11, characterized in that Also includes: When determining that the negotiation parameters of the first terminal, the negotiation parameters of the media function network element, and the negotiation parameters of the second terminal do not meet the preset rendering requirement, the second communication device sends a first request to the network storage function network element, where the first request includes the preset rendering requirement, and the first request is used to request a first entity that meets the preset rendering requirement; The second communication device receives a first response from the network storage function network element, and the first response includes information of the first entity.

14. The method according to any one of claims 8 to 13, characterized in that: The capability negotiation request is information received by the second communication device from the first terminal through the application data channel; The application data channel is a channel between the first terminal and the second communication device.

15. A communication device, characterized in that: The method comprises a module for executing the method as claimed in any one of claims 1 to 7, or comprises a module for executing the method as claimed in any one of claims 8 to 14.

16. A communication device, characterized in that: The method comprises a processor and an interface circuit, wherein the interface circuit is used 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, and the processor implements the method as described in any one of claims 1 to 7 through a logic circuit or by executing code instructions, or the processor implements the method as described in any one of claims 8 to 14 through a logic circuit or by executing code instructions.

17. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or an instruction. When the computer program or the instruction is executed by the communication device, the method according to any one of claims 1 to 7 is implemented, or the method according to any one of claims 8 to 14 is implemented.

18. A computer program product, characterized in that The computer program product comprises a computer program or instructions, and when the computer program or instructions are executed by a communication device, the method according to any one of claims 1 to 7 is implemented, or the method according to any one of claims 8 to 14 is implemented.

19. A communication system, characterized in that: include: a first communication device and a second communication device; Wherein, the first communication device is used to implement the method according to any one of claims 1 to 7; The second communication device is used to implement the method according to any one of claims 8 to 14.

Images