Communication method and apparatus

Abstract

A communication method and apparatus, which are used for ensuring security when a rendering entity requests an avatar model from a BAR network element during an avatar-related call. In the present application, the method comprises: a first terminal sending a capability negotiation request, wherein the capability negotiation request carries an identifier of a first avatar, and the capability negotiation request is used for negotiating the rendering of the first avatar; the first terminal receiving a capability negotiation response, wherein the capability negotiation response comprises information of a first entity, the first entity is an entity used for downloading a first avatar model, and the first avatar model is used for the rendering of the first avatar; and on the basis of the information of the first entity, the first terminal generating a token, wherein the token is used for authorizing the first entity to download the first avatar model.

Description

A communication method and apparatus

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510138178.0, filed on February 7, 2025, entitled "A Method and Apparatus for Communication", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of wireless communication, and more particularly to a communication method and apparatus. Background Technology

[0004] A digital human is a virtual character with a digital appearance, displayed through a display device, such as a mobile phone, television, augmented reality (AR) glasses, or virtual reality (VR) glasses. For example, Figure 1 illustrates a scenario of a digital human-related call. The first terminal acts as a data acquisition end, collecting user information from user 'a' and providing it to a rendering entity. The rendering entity generates video frames based on user 'a's user information and the digital human model corresponding to the first terminal. The video frames include the digital human corresponding to user 'a', and are displayed on a second terminal so that user 'b' on 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 (e.g., a media function (MF) network element). The user information can specifically include action information, language information, facial expression information, and text information.

[0005] Ensuring the safety of digital human models is a matter of concern. Summary of the Invention

[0006] This application provides a communication method and apparatus for ensuring the security of digital human models.

[0007] In a first aspect, this application provides a communication method, which can be executed by a first communication device, which may be a first terminal or a part of the first terminal (e.g., a chip in the first terminal).

[0008] When the first communication device is a 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 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 antenna), for example, the information is sent by the DC AS to the first terminal.

[0009] For ease of description, the following explanation will use the example of the first communication device being the first terminal.

[0010] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes:

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

[0012] The information of the first entity may include, for example, the identifier of the first entity and / or the type of the first entity.

[0013] In the above technical solution, the first terminal issues a token based on the information of the first entity (i.e., the entity downloading the first digital human model). Compared to generating a token based on coarse-grained information (such as information about all entities that might use the token, including terminal type, MF entity type, and DC AS type), the first terminal generates a token based on fine-grained information (i.e., the information of the first entity). This token is used by the first entity to download the first digital human model and cannot be used by other entities to download the first digital human model, thus preventing the abuse of the right to download the digital human model and improving security. Therefore, 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 based on the token. For example, if the BAR network element determines that the first entity has passed the identity verification, it provides the first digital human model to the first entity; if the BAR network element determines that the first entity has failed the identity verification, it does not provide the first digital human model to the first entity. Thus, by issuing a token through the first terminal, the security of the process of requesting the digital human model is improved.

[0014] Furthermore, during the capability negotiation process, the first terminal obtains information about the first entity, which helps to save the number of signaling interactions.

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

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

[0017] In one possible implementation, a first application data channel (ADC) is established between the first terminal and the DC AS. For example, the capability negotiation request is sent from the first terminal to the DC AS via the first ADC; for instance, the first terminal sends the capability negotiation request to the MF network element, and the MF network element forwards the capability negotiation request to the DC AS. As another example, the capability negotiation response is sent from the DC AS to the first terminal via the first ADC. In other words, the capability negotiation response is information received by the first terminal from the DC AS via the first ADC; for example, 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.

[0018] In one possible implementation, the capability negotiation response also includes information about the entity storing the first digital human model, and the token includes this information. In another possible implementation, the entity storing the first digital human model is a first BAR network element; exemplarily, the information of the first BAR network element is its identifier.

[0019] In the above technical solution, the first terminal carries information about the entity storing the first digital human model (e.g., 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 storing the first digital human model in the token is the information of the second BAR network element, and thus determine whether to provide the first digital human model to the first entity. For example, if the second BAR network element determines that the information about the entity storing the first digital human model included in the token is the same as the information of the second BAR network element (i.e., the first BAR and the second BAR are the same BAR), it provides the first digital human model to the first entity; if the second BAR network element determines that the information about the entity storing the first digital human model included in the token is different from the information of the second BAR network element (i.e., the first BAR and the second BAR are different BARs), it does not provide the first digital human model to the first entity. This helps to further ensure the security of the digital human model in the BAR network element. Furthermore, compared to the first terminal generating a token based on coarse-grained information (such as information about all entities that may provide digital human models), the first terminal generates a token based on fine-grained information (such as information about the first BAR network element). This token is used by the first entity to request the first digital human model from the first BAR, but cannot be used by 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 regarding the digital human model is more accurate, avoiding the abuse of the right to provide the digital human model and further ensuring security.

[0020] In one possible implementation, the token is carried in the re-invitation message. For example, the first terminal sends a re-invitation message including the token. For example, this re-invitation message is used to establish a second ADC between the first terminal and the DC AS. The second ADC is used to transmit service data, such as data between the first and second terminals (e.g., data used for rendering entities (e.g., user information), or the rendered digital human). In the above technical solution, the first terminal carries the token in the re-invitation message without adding other messages, which helps to save the number of signaling interactions.

[0021] In one possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal associated with the call. For example, the first entity is a rendering entity, such as one of the MF network element, first terminal, and second terminal. As another example, the first entity is a proxy entity, which can be used to request the first digital human model from the BAR network element on behalf of the rendering entity; the proxy entity is, for example, the DC AS.

[0022] In one possible implementation, the capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capabilities of the first terminal and / or candidate entities recommended by the first terminal; the candidate entities include one or more of the MF network elements related to the call, the first terminal, and the second terminal. For example, the negotiation parameters of the first terminal can be used to determine information about the first entity.

[0023] The above technical solution helps to improve the flexibility of identifying information about the first entity.

[0024] Secondly, this application provides a communication method, which can be executed by a second communication device, which may be a DC AS or a part of a DC AS (e.g., a chip in a DC AS).

[0025] 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 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 antenna), for example, the information is sent by the first terminal to the DC AS.

[0026] For ease of description, the following explanation will use DC AS as an example of the second communication device.

[0027] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes:

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

[0029] In one possible implementation, the capability negotiation response also includes information for storing the entity of the first digital human model. This information, for example, is the identifier of the first BAR network element.

[0030] In one possible implementation, the capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capabilities of the first terminal and / or candidate entities recommended by the first terminal; the candidate entities include one or more of the MF network elements related to the call, the first terminal, and the second terminal. After receiving the capability negotiation request, the DC AS also determines the information of the first entity based on the negotiation parameters of the first terminal.

[0031] For example, when the DC AS determines the information of the first entity based on the negotiation parameters of the first terminal, it can specifically involve the DC AS obtaining the negotiation parameters of the MF network element and the negotiation parameters of the second terminal from the MF network element; the DC AS then determines the information of the first entity based on the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal. The negotiation parameters of the MF network element include the rendering capabilities 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 capabilities of the second terminal and / or the candidate entities recommended by the second terminal.

[0032] In one possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal associated with the call.

[0033] In one possible implementation, when the DC AS 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 requirements, it also sends a first request to the network repository function (NRF) network element. The first request includes the preset rendering requirements and is used to request a first entity that meets the preset rendering requirements. Furthermore, the DC AS receives a first response from the NRF, which includes information about the first entity.

[0034] 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 the information of the first entity from the NRF network element to ensure the normal progress of the rendering process.

[0035] For example, the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal all fail to meet the preset rendering requirements. Specifically, the rendering capabilities of the first terminal, the MF network element, and the second terminal all fail to meet the preset rendering requirements.

[0036] In one possible implementation, the rendering capabilities of the first terminal include one or more of the following:

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

[0038] (2) The rendering data requirements of the first terminal, wherein 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.

[0039] (3) The remaining computing resources of the first terminal, wherein the remaining computing resources of the first terminal include one or more of the following: the currently available resources of the central processing unit (CPU) of the first terminal, the currently available power consumption of the graphics processing unit (GPU), the currently available computing power of the GPU, or the currently available memory resources.

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

[0041] In one possible implementation, a first ADC is established between the first terminal and the DC AS. For example, a capability negotiation request is sent from the first terminal to the DC AS via the first ADC; in other words, the capability negotiation request is information received by the DC AS from the first terminal via the first ADC. For instance, the first terminal sends a capability negotiation request to an MF network element, and the MF network element forwards the capability negotiation request to the DC AS. As another example, a capability negotiation response is sent from the DC AS to the first terminal via the first ADC; for example, the DC AS sends a capability negotiation response to an MF network element, and the MF network element forwards the capability negotiation response to the first terminal.

[0042] Thirdly, this application provides a communication method that can be executed by a third communication device, which may be a second BAR network element or a part of the second BAR network element (e.g., a chip in the second BAR network element).

[0043] For ease of description, the following example uses the third communication device as the second BAR network element.

[0044] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes:

[0045] The second BAR network element receives a token from the second entity. This token authorizes the first entity to download the first digital human model. The token is generated by the first terminal based on the information of the first entity. The first digital human model is used for rendering 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.

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

[0047] In one possible implementation, the token also includes information about the entity storing the digital human model (e.g., the identifier of the first BAR element). The second BAR element can also determine whether the information about the entity storing the digital human model in the token is the information of the second BAR element. Further, when the second BAR element determines that the information about the entity storing the digital human model in the token is the information of the second BAR element, and the information of the second entity is the same as the information of the first entity in the token, the first digital human model is sent to the second entity.

[0048] Fourthly, this application provides a communication method, which can be executed by a fourth communication device, which may be an NRF network element or a part of an NRF network element (e.g., a chip in an NRF network element).

[0049] For ease of description, the following explanation uses an NRF network element as the fourth communication device.

[0050] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes:

[0051] 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, which includes information about the first entity.

[0052] Fifthly, embodiments of this application provide a communication device.

[0053] The device has the function of implementing the first communication device in the first aspect or any possible implementation of the first aspect. The communication device may also have the function of implementing the second communication device in the second aspect or any possible implementation of the second aspect. The communication device may also have the function of implementing the third communication device in the third aspect or any possible implementation of the third aspect. The communication device may also have the function of implementing the fourth communication device in the fourth aspect or any possible implementation of the fourth aspect.

[0054] The functions of the aforementioned 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 aforementioned functions.

[0055] In one possible implementation, the device includes a processing module and a transceiver module.

[0056] The processing module is configured to support the device in performing the functions of the first communication device in the first aspect or any possible implementation of the first aspect, or in performing the functions of the second communication device in the second aspect or any possible implementation of the second aspect, or in performing the functions of the third communication device in the third aspect or any possible implementation of the third aspect, or in performing the functions of the fourth communication device in the fourth aspect or any possible implementation of the fourth aspect.

[0057] The transceiver module supports communication between the device and other communication devices; for example, when the device is a first communication device, it can send capability negotiation requests. The communication device may also include a storage module coupled to the processing module, which stores the necessary program instructions and data for 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, which may be integrated with or separate from the processor.

[0058] In another possible implementation, the device includes a processor and may also include a memory. The processor is coupled to the memory and can be used to execute computer program instructions stored in the memory to cause the device to perform the methods of the first aspect or any possible implementation thereof, or to perform the methods of the second aspect or any possible implementation thereof, or to perform the methods of the third aspect or any possible implementation thereof, or to perform the methods of the fourth aspect or any possible implementation thereof. Optionally, the device further includes a communication interface, to which the processor is coupled. 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 a device, the communication interface may be the chip's input / output interface. Optionally, the transceiver may be a transceiver circuit, and the input / output interface may be an input / output circuit.

[0059] Sixthly, embodiments of this application provide a chip system, including: a processor and a memory, the processor being coupled to the memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, causing the chip system to perform the method in the first aspect or any possible implementation of the first aspect, or perform the method in the second aspect or any possible implementation of the second aspect, or perform the method in the third aspect or any possible implementation of the third aspect, or perform the method in the fourth aspect or any possible implementation of the fourth aspect.

[0060] Optionally, the chip system also includes an interface circuit for exchanging code instructions with the processor.

[0061] Optionally, the chip system may include one or more processors, which can be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor that reads software code stored in memory.

[0062] Optionally, the chip system may contain one or more memories. These memories may be integrated with the processor or disposed separately. For example, the memory may be a non-transitory processor, such as read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on separate chips.

[0063] In a seventh aspect, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a communication device, cause the communication device to perform the method in the first aspect or any possible implementation thereof, or to perform the method in the second aspect or any possible implementation thereof, or to perform the method in the third aspect or any possible implementation thereof, or to perform the method in the fourth aspect or any possible implementation thereof.

[0064] Eighthly, this application provides a computer program product comprising a computer program or instructions that, when executed by a communication device, implement the method in the first aspect or any possible implementation of the first aspect, or implement the method in the second aspect or any possible implementation of the second aspect, or implement the method in the third aspect or any possible implementation of the third aspect, or implement the method in the fourth aspect or any possible implementation of the fourth aspect.

[0065] Ninthly, embodiments of this application provide a communication system, which includes one or more of a first communication device, a second communication device, a third communication device, or a fourth communication device, wherein the first communication device implements the method in the first aspect or any possible implementation of the first aspect, the second communication device implements the method in the second aspect or any possible implementation of the second aspect, the third communication device implements the method in the third aspect or any possible implementation of the third aspect, and the fourth communication device implements the method in the fourth aspect or any possible implementation of the fourth aspect.

[0066] The technical effects achievable by any of the second to ninth aspects described above can be referred to the description of the beneficial effects in the first aspect, and will not be repeated here. The technical solutions in the first to ninth aspects can be referenced interchangeably. Attached Figure Description

[0067] Figure 1 is a schematic diagram of a scenario involving a digital human-related call;

[0068] Figure 2A is a schematic diagram of a network architecture provided in this application;

[0069] Figure 2B is a schematic diagram of another network architecture provided in this application;

[0070] Figure 2C is a schematic diagram of another network architecture provided in this application;

[0071] Figure 3 is a flowchart illustrating the first communication method provided in this application;

[0072] Figure 4 is a flowchart illustrating the second communication method provided in this application;

[0073] Figure 5 is a flowchart illustrating the third communication method provided in this application;

[0074] Figure 6 is a flowchart illustrating the fourth communication method provided in this application;

[0075] Figure 7 is a flowchart illustrating the fifth communication method provided in this application;

[0076] Figure 8 is a flowchart illustrating the sixth communication method provided in this application;

[0077] Figure 9 is a flowchart illustrating the seventh communication method provided in this application;

[0078] Figure 10 is a schematic diagram of the structure of a communication device provided in this application;

[0079] Figure 11 is a schematic diagram of another communication device provided in this application. Detailed Implementation

[0080] The relevant technical features involved in the embodiments of this application will be explained below. 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 on the scope of protection claimed by this application.

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

[0082] The following describes the network architecture to which the communication method proposed in this application is applicable.

[0083] Referring to Figure 2A, which is a schematic diagram of a network architecture provided by this application, the network architecture shown in Figure 2A includes a first terminal, a communication network, and a second terminal. The first terminal and the second terminal can communicate via the communication network. For example, the first terminal and the second terminal can communicate via the communication network regarding digital avatars.

[0084] A digital human (also known as an animated avatar) refers to a personal virtual image or avatar on the internet. Digital human technology maps a user's facial expressions, movements, and voice into a digital human model (avatar representation, also known as an avatar model, base avatar, etc.) in real time to generate a digital human, enabling the digital human to mimic and respond to the user's real-time behavior.

[0085] In this context, a call, also known as a communication service, refers to a service where a terminal, acting as the originating party or the terminating party, engages in voice calls, video calls, or data interactions with one or more other terminals via a communication network. A call can encompass the entire process from call establishment (e.g., dialing) to call termination, or it can cover a portion of that process. Calls can be one-to-one or one-to-many (e.g., conference calls); this application uses a one-to-one call as an example, but related solutions can be used for one-to-many calls.

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

[0087] For example, as shown in Figure 2B, the communication network may include call session control function (CSCF) network elements, IMS access media gateway (AGW), home subscriber server (HSS) network elements, IMS application server (AS), MF network elements, etc.

[0088] The communication network shown in Figure 2C adds some data channel (DC) related network elements to the communication network shown in Figure 2B, such as the data channel signaling function (DCSF) network element, the data channel application repository (DCAR) network element, and DC AS. Optionally, the communication system shown in Figure 2C also includes network exposure function (NEF) network elements, NRF network elements, and BAR network elements.

[0089] This section provides a brief introduction to the network elements (or functional network elements, functional entities, nodes, devices, etc.) shown in Figures 2A to 2C:

[0090] 1. Terminal: A terminal can be referred to as user equipment (UE), terminal device, terminal unit, access terminal, user unit, user station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, wireless communication equipment, user agent, or user equipment, etc., and is a device with wireless or wired communication capabilities. For example, a terminal can connect to a wireless access device via an air interface, or it can connect to a wired access device via a wired interface. In terms of product form, a terminal can include handheld devices with communication functions, vehicle-mounted devices, wearable devices, or computing devices, etc. For example, a terminal can be a mobile phone, tablet, computer with wireless communication capabilities (such as a laptop, PDA, etc.), mobile internet device (MID), virtual reality (VR) terminal, augmented reality (AR) terminal, smartwatch, smart bracelet, smart glasses, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, SIP phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication capabilities, other processing devices connected to a wireless modem, terminal in Internet of Things (IoT) system, desktop computer, or third-generation partnership. Terminals defined by the 3GPP (3GPP) standard specifications are not restricted.

[0091] 2. The CSCF (Customer Service Provider) network element is a functional entity within IMS and the core of the entire IMS system. It is primarily responsible for signaling control during multimedia call sessions. It manages IMS user authentication, IMS bearer plane quality of service (QoS), control of session initiation protocol (SIP) sessions in cooperation with other network elements, and service negotiation and resource allocation. The CSCF network element can communicate with terminals and gateway devices. For example, it can select the gateway device to communicate with the terminal, and it can allocate routing information, such as IP addresses or ports, between the terminal and the gateway device.

[0092] As an example, and not a limitation, CSCF network elements are categorized by function into proxy CSCF elements (P-CSCF elements), interrogating CSCF elements (I-CSCF elements), and serving CSCF elements (S-CSCF elements). Among these, the P-CSCF element is the entry point for users accessing the IMS network, primarily responsible for forwarding SIP signaling between IMS users and their home network. The I-CSCF element is the unified entry point for the IMS user's home network, responsible for allocating or querying S-CSCF elements serving the user. The S-CSCF element is also the unified entry point for the IMS user's home network, responsible for allocating or querying S-CSCF elements serving the user.

[0093] It is understood that the aforementioned P-CSCF network elements, S-CSCF network elements, and I-CSCF network elements can be configured independently in different entities or integrated into the same entity, and this application does not impose any restrictions.

[0094] 3. IMS AGW: IMS AGW can provide IMS network access gateway and media gateway functions.

[0095] 4. DCSF network element: used to provide signaling control functions for data channels.

[0096] 5. DCAR network element: A repository used to store data channel applications (DC Apps).

[0097] 6. HSS Network Element: The HSS network element serves as a database for storing user information within IMS, where users store their data. As an example and not a limitation, user data may include information about the data channel services the user has contracted with the operator.

[0098] 7. IMS AS: The IMS AS is the top-level application layer device in the IMS system, providing basic and supplementary services such as multimedia conferencing, converged communications, SMS gateways, and standard operator consoles. The IMS network is an open system based on IP that provides various multimedia services to users. The IMS AS interacts with CSCF network elements to trigger and execute various network services. Furthermore, the terminal communicates with the IMS AS, and the IMS AS can establish data channels for the terminal.

[0099] For example, the IMS AS can be a multimedia telephony application server (MMTEL AS) or a telephone application server (TAS).

[0100] 8. DC AS: Also known as Extended Reality Application Server (XR AS). DC AS is used to provide data channel service logic. It can be understood that DC AS can be deployed within the IMS network, in which case it can be directly connected to other network elements in the IMS network through interfaces (such as service interfaces); or, DC AS can be deployed outside the IMS network, in which case it can be connected to other network elements in the IMS network through NEF network elements (or IMS border network management).

[0101] For example, the DC AS can download a list of avatar IDs from the BAR network element and send it to the terminal. For example, the DC AS can also download a avatar model from the BAR network element based on the avatar IDs.

[0102] 9. NEF Network Element: The NEF network element is used to securely expose various services of the 5GC network to third parties.

[0103] 10. MF Network Element: Also known as a media server, it provides media resource management functions, including media resource management for media channels and data channels. Furthermore, the MF network element can drive the rendering of animated digital humans based on digital human models and user information (e.g., motion information, language information, facial expression information, text information, etc.). For example, the MF network element can also download digital human models from the BAR network element based on the digital human's identifier.

[0104] 11. BAR Network Element: Used to store digital human models and their identifiers (which can be represented as Avatar IDs). Furthermore, a terminal corresponds to one or more digital human models, each identified by an Avatar ID. The BAR network element also stores a list of digital human identifiers for each terminal (which can be represented as an Avatar ID list).

[0105] 12. NRF Network Element: Used to register, manage, and monitor the status of network function (NF) network elements. Each NF must be registered through an NRF network element before it can be provided with services.

[0106] The network architecture described above for the embodiments of this application is merely an example. The network architecture applicable to the embodiments of this application is not limited to this. Any network architecture capable of implementing the functions of the aforementioned network elements is applicable to the embodiments of this application. That is, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will understand that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems. The network elements or devices listed in the above network architecture are merely illustrative examples. The network architecture applicable to this application may also include other network elements or devices, and this application does not limit them. The naming of the above network elements or devices is defined only to facilitate the differentiation of different functions and should not constitute any limitation on this application. Other names may be used in other network architectures.

[0107] Furthermore, similar to video calls, digital human calls offer visual, interactive communication, providing users with real-time images of their emotions, attention, and other social information. However, unlike video calls, digital human calls present the other user with a virtual, animated digital human (digital avatar) processed by a terminal or network device (such as an MF network element), rather than the real avatar seen in a video call.

[0108] 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 a digital human model from the BAR network element and obtains user information from the first terminal. The MF network element renders the digital human into a 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 then sends the scene-integrated rendered digital human to the second terminal.

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

[0110] User information comes from the sensing devices of the first terminal, such as cameras and specialized motion capture devices. These devices can capture the movement information of the user's head (face), body, legs, hands, etc., and the microphone can capture the language information of the user. The first terminal sends this processed user information (used to generate digital humans) to the MF network element.

[0111] It is important to note that the digital human can also be generated by either the first or second terminal. In this case, either the first or 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 sensors, and then sends it to the second terminal after considering 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 considering the scene.

[0112] In this application, rendering and driving are regarded as the same operation, that is, an entity needs to generate a digital human based on the digital human model and user information and add environmental information. The English name is animate, and the following text will use rendering to describe it.

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

[0114] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. For example, the first terminal, as the caller, initiates a digital human-related call to the second terminal, and the second terminal, as the called party, receives the digital human-related call.

[0115] Figure 3 is a schematic flowchart of a communication method exemplarily provided in this application. This communication method can be executed interactively by a first communication device and a second communication device. The first communication device can be a first terminal or a part of a first terminal (e.g., a chip); the second communication device can be a DC AS or a part of a DC AS (e.g., a chip). For ease of description, the following explanation uses the example of a first terminal as the first communication device and a DC AS as the second communication device. Furthermore, this method focuses on how the first terminal obtains information about a first entity and then generates a token based on that information.

[0116] The network devices involved in this method include DC AS and MF network elements related to calls.

[0117] For example, the DC AS related to the call refers to the DC AS used to provide data channel service logic for this call. For instance, when the first terminal and the second terminal are deployed in the same IMS network, the DC AS related to the call can be a DC AS within that 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 a DC AS deployed in the same IMS network as the first terminal. The MF network element related to the call refers to the MF network element used to provide media resource management functions for this call.

[0118] Specifically, a first ADC is established between the first terminal and the DC AS, and the first ADC is used for rendering negotiation. The first terminal establishes end-to-end protection with the MF network element, and the MF network element establishes end-to-end protection with 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 within 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 within the MF network element.

[0119] Step 301: The first terminal sends a capability negotiation request to the DC AS.

[0120] Accordingly, the DC AS receives a capability negotiation request from the first terminal.

[0121] For example, a capability negotiation request can also be called a negotiation request, a rendering negotiation request, a driving negotiation request, an animation negotiation request, etc.

[0122] Capability negotiation requests are used to negotiate the rendering of the digital human. For example, a capability negotiation request is used to negotiate the rendering data types and rendering entities used in the digital human rendering process. Here, a rendering entity refers to the entity used to generate the digital human based on user information and the digital human model. The rendering entity can be a first terminal, a second terminal, or an MF network element related to digital human communication between the first terminal and the second terminal. Rendering data types include, for example, text, language, and actions. For ease of description, the digital human being negotiated and rendered in this instance will be referred to as the first digital human, and the model used to generate the first digital human will be 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.

[0123] The capability negotiation request carries an avatar ID for the first digital human. For example, the avatar ID is used to retrieve the first digital human model; the avatar ID can also be referred to as the identifier of the first digital human model or the model identifier. For example, the capability negotiation request may also carry negotiation parameters for the first terminal. For example, the negotiation parameters for the first terminal include the rendering capability of the first terminal and / or candidate entities recommended by the first terminal (referred to as "prefer" in this application), wherein the candidate entities include one or more of the MF network element, the first terminal, and the second terminal.

[0124] The rendering capabilities of the first terminal include one or more of the following:

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

[0126] (2) The rendering data requirements of the first terminal, wherein 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., 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., rendering the first digital human). For example, the rendering data requirements of the first terminal include action types, and the minimum number of sensors corresponding to the action types is 3. That is, when the first terminal renders the first digital human, the data type required is action type, and this type of data needs to be collected by at least 3 sensors.

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

[0128] (4) Scoring of the remaining computing resources of the first terminal. This score can be obtained by the first terminal scoring its remaining computing resources according to a preset scoring system. For example, this preset scoring system is unified by the first terminal, the second terminal, and the MF network element.

[0129] For example, the negotiation parameters of the first terminal include "supports rendering, the recommended entity is the first terminal", which means that the first terminal supports rendering and the first terminal recommends itself as the rendering entity; and for another example, the negotiation parameters of the first terminal include "does not support rendering, the recommended entity is the MF network element", which means that the first terminal does not support rendering and the first terminal recommends the MF network element as the rendering entity.

[0130] For example, 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 sends the 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.

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

[0132] Accordingly, the first terminal receives a capability negotiation response from the DC AS.

[0133] The capability negotiation response includes information about the first entity, which may specifically be the type of the first entity and / or the identity (ID) of the first entity.

[0134] For example, a 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. For example, the information of the first entity can also be referred to as the user's (or subject's) information, the authorized entity's information, the animation negotiation parameter, the animation negotiation result, etc.

[0135] The first entity is the entity used to download the first digital human model. For example, the first entity is one of the DC AS, MF network element, first terminal, and second terminal associated with the current call between the first terminal and the second terminal.

[0136] It is understood that the first entity can be a rendering entity or a proxy entity of a rendering entity. For example, when the first entity is a rendering entity, the first entity can be a first terminal, a second terminal, or an 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 a rendering entity, the first entity can be a DC AS, and further, the rendering entity can be a first terminal, a second terminal, or an MF network element, and the DC AS can proxy the rendering entity to request to download the first digital human model.

[0137] In addition, the capability negotiation response also includes information about the entity used to store the first digital human model. For example, the entity used to store the first digital human model is a first BAR network element, and specifically, the information about the first BAR network element may be its identifier.

[0138] For example, a first ADC is established between the first terminal and the DC AS. The first terminal can send messages 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 a 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.

[0139] Optionally, prior to step 302, one or more of the following steps A, B, and C may be included:

[0140] Step A: In response to the capability negotiation request, DC AS determines the information of the first entity.

[0141] In other words, "DC AS receiving a capability negotiation request" serves as the trigger condition for "DC AS determining the information of the first entity". When determining the information of the first entity, DC AS can determine the information of the first entity by combining the parameters in the capability negotiation request, or it can determine the information of the first entity without combining the parameters in the capability negotiation request. The following explanations are for implementation methods 1 to 3.

[0142] In implementation method 1, the DC AS determines the information of the first entity based on the first configuration information. In this implementation method, the DC AS does not combine the parameters in the capability negotiation request to determine the information of the first entity.

[0143] For example, the first configuration information includes one of the following configurations:

[0144] Configuration 1 selects the MF network element as the rendering entity. That is, when the first configuration information of the DC AS is Configuration 1, the DC AS can determine the MF network element as the rendering entity. Furthermore, "MF network element" in Configuration 1 can also be replaced with "first terminal" or "second terminal".

[0145] Configuration 2: Priority sorting of multiple entities among DC AS, MF network element, first terminal and second terminal.

[0146] For example, in configuration 2, the priority order is MF network element, first terminal, and second terminal. When the first configuration information of DC AS is configuration 2, DC AS can determine whether MF network element can be used as a rendering entity according to the priority order. If DC AS determines that MF network element can be used as a rendering entity, then it determines that MF network element is used as a rendering entity. If DC AS determines that MF network element cannot be used as a rendering entity, then it continues to determine whether the first terminal can be used as a rendering entity, until a rendering entity is determined.

[0147] The DC AS includes preset rendering requirements, such as the minimum requirements for rendering a digital human. When determining whether an MF network element can be used as a rendering entity, the DC AS specifically determines whether the rendering capability of the MF network element meets the preset rendering requirements. If the DC AS determines that the rendering capability of the MF network element meets the preset rendering requirements, then the MF network element can be used as a rendering entity; if the DC AS determines that the rendering capability of the MF network element does not meet the preset rendering requirements, then the MF network element cannot be used as a rendering entity. The method by which the DC AS determines whether the first terminal or the second terminal can be used as a rendering entity is similar to that of the MF network element. For a description of the rendering capabilities of the MF network element, the first terminal, and the second terminal, please refer to the description in Implementation Method 2 below.

[0148] Implementation Method 2: DC AS determines the information of the first entity based on the negotiation parameters of the first terminal in the capability negotiation request.

[0149] In one 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 based on the negotiation parameters of the first terminal, the negotiation parameters of the MF network element and the negotiation parameters of the second terminal.

[0150] The negotiation parameters for the MF network element include its rendering capabilities and / or the candidate entities recommended by the MF network element. The negotiation parameters for the second terminal include its rendering capabilities and / or the candidate entities recommended by the second terminal. The negotiation parameters for either the MF network element or the second terminal can be found in the description of the negotiation parameters for the first terminal in step 301. The candidate entities recommended by either the MF network element or the second terminal can also be found in the description of the candidate entities recommended by the first terminal in step 301.

[0151] For example, 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.

[0152] For example, the DC AS sends a first acquisition request to the MF network element. This first acquisition request requests the negotiation parameters of the MF network element and the second terminal. The first acquisition request includes the identifiers of the MF network element and the second terminal. Correspondingly, the MF network element sends a first acquisition response to the DC AS, which includes the negotiation parameters of the MF network element and the second terminal. For instance, upon receiving the first acquisition request, the MF network element first sends a second acquisition request to the second terminal, which requests the negotiation parameters of the second terminal and includes the identifier of the second terminal. Correspondingly, the second terminal sends a second acquisition response to the MF network element, which includes the negotiation parameters of the second terminal. The MF network element then sends the first acquisition response back to the DC AS based on the second acquisition response.

[0153] For example, the DC AS sends an acquisition request to the MF network element. This acquisition request requests the negotiation parameters of the second terminal and includes the identifier of the second terminal. Correspondingly, the MF network element forwards the acquisition request to the second terminal, and the second terminal sends an acquisition response to the MF network element, which includes its negotiation parameters. When forwarding the acquisition response, the MF network element includes its own negotiation parameters in the response.

[0154] For example, the DC AS is pre-configured with negotiation parameters for the MF network element. The DC AS obtains the negotiation parameters for the second terminal from the MF network element. For instance, the DC AS sends an acquisition request to the MF network element, requesting the negotiation parameters for the second terminal, and the acquisition request includes the identifier of the second terminal. Accordingly, the MF network element forwards the acquisition request to the second terminal. Subsequently, the second terminal sends an acquisition response to the MF network element, and the MF network element forwards the acquisition response to the DC AS, the acquisition response including the negotiation parameters for the second terminal.

[0155] The request to obtain the data can also be called an animation capability request, and the response to obtain the data can also be called an animation capability response.

[0156] When the DC AS determines the information of the first entity based on the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal, it can include at least the following examples:

[0157] Example 1: The negotiation parameters for each entity carry the entity's rendering capabilities, but do not include recommended candidate entities. Therefore, DC AS can select the entity with the strongest rendering capabilities as the first entity based on these capabilities.

[0158] For example, DC AS selects the entity with stronger rendering capabilities (such as the MF network element) as the first entity based on the rendering capabilities of the first terminal, the second terminal, and the MF network element.

[0159] Furthermore, an entity may not include its rendering capabilities in the negotiation parameters. In this case, the DC AS can assume that the entity does not support rendering. The DC AS then selects the entity with stronger rendering capabilities from among the entities that support rendering as the first entity. For example, the negotiation parameters of the first terminal do not include its rendering capabilities, while the negotiation parameters of the second terminal do, and the negotiation parameters of the MF network element do. The DC AS can assume that the first terminal does not support rendering, and then select the entity with stronger rendering capabilities (e.g., the MF network element) as the first entity based on the rendering capabilities of the second terminal and the MF network element.

[0160] Example 2: The negotiation parameters for each entity carry the candidate entities recommended by that entity, but not the rendering capabilities of that entity. For instance, 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. Alternatively, the DC AS determines which entity has the most votes and selects that entity as the first entity. For example, if 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 itself as the first entity, then the DC AS determines that the MF network element has the most votes and selects it as the first entity.

[0161] Example 3: The negotiation parameters of each entity carry the recommended candidate entities and the rendering capabilities of the entity. DC AS selects the recommended entity that supports rendering.

[0162] The first entity determined by DC AS is explained by referring to the examples of negotiation parameters of a first terminal, negotiation parameters of an MF network element, and negotiation parameters of a second terminal provided in Table 1.

[0163] For example, when the negotiation parameters of the first terminal include "supports rendering, the recommended entity is the first terminal", the negotiation parameters of the second terminal include "supports rendering, the recommended entity is the second terminal", and the negotiation parameters of the MF network element include "supports rendering, the 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.

[0164] For example, when the negotiation parameters of the first terminal include "supports rendering, recommended entity is the first terminal or MF network element", the negotiation parameters of the second terminal include "supports rendering, recommended entity is the second terminal or MF network element", and the negotiation parameters of the MF network element include "supports 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 all terminals support rendering and recommend entities other than 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 be found in Table 1, and will not be listed here again.

[0165] Table 1

[0166] It should be added that in the negotiation parameters of the first terminal, "candidate entities recommended by the first terminal" can also be replaced with "candidate entities not recommended by the first terminal". For example, the negotiation parameters of the first terminal include "not recommending the second terminal"; or, it can be replaced with "whether the first terminal recommends the second terminal and / or MF network element". For example, the negotiation parameters of the first terminal include "recommending the second terminal and MF network element as the first entity", or "recommending the MF network element as the first entity, not recommending the second terminal as the first entity". The negotiation parameters of the MF network element or the negotiation parameters of the second terminal are similar to those of the first terminal and will not be described again.

[0167] Furthermore, 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 based on 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, and then the DC AS determines the information of the first entity based on the negotiation parameters of the first terminal and the negotiation parameters of the MF network element. For specific implementation, please refer to Examples 1 to 3 above.

[0168] In this second implementation, the first entity can specifically be a rendered entity.

[0169] Of course, the above are all illustrative examples. This application may have other implementation methods, which will not be listed one by one.

[0170] Implementation method 3: DC AS requests information about the first entity from the NRF network element.

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

[0172] In one possible example, when the DC AS determines that none of the rendering capabilities in the negotiated parameters it has obtained meet the preset rendering requirements, it sends a first request to the NRF network element. This first request includes the preset rendering requirements and requests information about a first entity that meets those requirements. Correspondingly, the NRF network element receives the first request, determines the information of the first entity based on the preset rendering requirements in the first request, and sends a first response to the DC AS, which includes the information of the first entity. The DC AS receives the first response from the NRF network element.

[0173] For example, 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. When it determines that the rendering capabilities in 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, it requests information about the first entity from the NRF network element.

[0174] For another example, 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 negotiation parameters of the MF network element do not meet the preset rendering requirements, it requests the information of the first entity from the NRF network element.

[0175] For an NRF network element, it can determine a new MF network element from the network based on preset rendering requirements, use this new MF network element as the first entity, and then send the information of the first entity to the DC AS. For example, the first terminal also needs to establish a second ADC with the DC AS based on this new MF network element (instead of establishing a second ADC based on the original MF). For example, 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, the original MF network element can be referred to as the first MF network element, and the new MF network element 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, an NRF network element can determine a dedicated entity for rendering (also known as a compute node function (CNF) network element) from the network based on preset rendering requirements, use this CNF network element as the first entity, and then send the information of the first entity to the DC AS. Furthermore, the capability negotiation response carries information about the CNF network element (i.e., the information of the first entity). The first terminal can also generate a token based on the CNF network element information, so that the CNF network element requests the first digital human model from the BAR network element according to the token. The CNF network element then generates the first digital human based on 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 preset rendering requirements, and then send the CNF network element information to the DC AS. The DC AS sends the CNF network element information to the first MF network element and regards the first MF network element as the first entity. Furthermore, the capability negotiation response carries information about the first MF network element. Subsequently, the first terminal can generate a token based on the first MF network element information. 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, the CNF network element then generates the first digital human based on the first digital human model, and the CNF network element sends the first digital human to the first MF network element.

[0177] In another implementation, when an NRF network element determines a new MF or CNF network element, it does not need to consider preset rendering requirements. Instead, the DC AS determines whether the new MF or CNF network element meets the preset rendering requirements. For example, the NRF network element returns the information of the determined network element (e.g., identifier and rendering capabilities) to the DC AS via a first response. The DC AS determines whether the rendering capabilities of the network element can meet the preset rendering requirements. If so, the network element is identified as the first entity; otherwise, the DC AS sends a first request to the NRF network element again until the DC AS requests an entity from the NRF network element whose rendering capabilities meet the preset rendering requirements. In this scenario, the first request may not carry the preset rendering requirements. Alternatively, when the NRF network element determines that there is no network element in the network that can meet the preset rendering requirements, it can return a failure indication to the DC AS. The failure indication is used to indicate that there is currently no network element in the network that can meet the preset rendering requirements.

[0178] Furthermore, before sending the first request to the NRF network element, the DC AS may not need to determine whether the rendering capabilities in the negotiated parameters it obtains meet the preset rendering requirements. For example, in response to the capability negotiation request, the DC AS sends a first request to the NRF network element, which, for example, includes the preset rendering requirements. The NRF network element sends a first response to the DC AS, which includes information about the first entity.

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

[0180] In other words, the "DC AS reception capability negotiation request" serves as the trigger condition for "DC AS to determine the information of the first BAR network element".

[0181] When determining the information of the first BAR network element, the DC AS may specifically determine the information of the first BAR network element based on 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] For example, the network includes multiple BAR network elements, each storing its own digital human model. Further, the DC AS includes second configuration information, which includes a list of identifiers (i.e., identifiers of the digital humans corresponding to each digital human model) stored in each BAR network element. For instance, 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. List 1 includes the identifiers of the digital humans corresponding to each of digital human models 1 to 10; list 2 includes the identifiers of the digital humans corresponding to each of digital human models 11 to 20. Furthermore, DC AS can determine the identifier of the BAR network element (i.e., the first BAR network element) that stores the first digital human model based on the identifier of the first digital human and the list of identifiers of the digital human models stored in each BAR network element (i.e., the identifiers of the digital human). In the example above, if the first digital human is digital human 5, then the first BAR network element is BAR network element 1.

[0183] The information of the first BAR network element can also be referred to as the information of the service provider (or audience), or the information of the serving entity. For example, when the capability negotiation response includes information of the first entity and information of the first BAR network element, both information of the first entity and information of the first BAR network element can be considered as rendering negotiation parameters or rendering negotiation results.

[0184] In step C, the DC AS responds to the capability negotiation request and determines whether the first terminal has permission to use the first digital human model.

[0185] In other words, the "DC AS reception capability negotiation request" serves as the trigger condition for "DC AS to determine whether the first terminal has the right to use the first digital human model".

[0186] For example, the DC AS determines whether the identifier of the first digital human is in the list of digital human identifiers corresponding to the first terminal based on the identifier of the first terminal. For example, the DC AS stores a list of digital human identifiers that each terminal has the right to use (that is, the digital human identifiers corresponding to each terminal). The DC AS can determine the list of digital human identifiers corresponding to the first terminal based on the identifier of the first terminal, and then determine whether the identifier of the first digital human is in the list of digital human identifiers corresponding to the first terminal. If it is, the DC AS determines that the first terminal has the right to use the first digital human model; otherwise, the DC AS determines that the first terminal does not have the right to use the first digital human model.

[0187] For example, the DC AS includes a list of digital human identifiers corresponding to each of terminals 1 to 3. The list of digital human identifiers corresponding to terminal 1 includes the identifiers of digital human 1 to digital human 3, the list of digital human identifiers corresponding to terminal 2 includes the identifiers of digital human 2 to digital human 3, and the list of digital human identifiers corresponding to terminal 3 includes the identifiers of digital human 1 to digital human 4. Further, if the first terminal is terminal 1 and the first digital human is digital human 1, the DC AS can determine, based on the identifier of the first terminal (i.e., terminal 1), that the list of digital human identifiers corresponding to terminal 1 includes the identifier of the first digital human (i.e., the identifier of digital human 1), thus determining that the first terminal has the permission to use the first digital human model. As another example, if the first terminal is terminal 1 and the first digital human is digital human 4, the DC AS determines that the list of digital human identifiers corresponding to terminal 1 does not include the identifier of the first digital human (i.e., the identifier of digital human 4), thus determining that the first terminal does not have the permission to use the first digital human model.

[0188] This avoids the situation where the first terminal sends the identifier of a digital human from another terminal, which could lead to the rendering entity rendering a digital human from another terminal, or the digital human model of that other terminal being leaked.

[0189] Furthermore, upon receiving the capability negotiation request, the DC AS determines whether the first terminal has the permission to use the first digital human model. The DC AS can detect as early as possible that the first terminal does not have the permission to use the first digital human model, thus avoiding the need to return 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, which helps to save message transmission resources.

[0190] Furthermore, 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 identifiers of the first terminal and the first digital human, so that the tokens sent by the first terminal do not need to carry the identifier of the first digital human again.

[0191] Furthermore, if 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 type required by the first entity when generating the first digital human) as a parameter in the capability negotiation response to the first terminal. Correspondingly, when collecting user information, the first terminal can collect the corresponding user information based on the data type required by the first entity, thus reducing the workload of the first terminal; alternatively, the first terminal can collect all types of user information and then send the corresponding user information based on the data type required by the first entity, thus reducing the amount of data transmitted over the network.

[0192] In another example, if the second terminal acts as the rendering entity and the user information and token are forwarded by the MF network element, the token generated by the first terminal can also include the data types required for rendering by the second 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 rendering by the second terminal in the token, reduce 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 amount of data transmitted.

[0193] Step 303: The first terminal generates a token based on the information of the first entity.

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

[0195] When the DC AS also determines information about the entity used to store the first digital human model (e.g., information about the first BAR network element), the token may also include that information about the entity used to store the first digital human model. Accordingly, the token authorizes the first entity to download the first digital human model from the information of the entity used to store the first digital human model.

[0196] The following examples provide two token representation formats:

[0197] In representation 1, the token includes fields for authorized digital person (avatar), issuer, user, service provider, and expiration time. Specifically, the avatar field includes the identifier of the first digital person, the issuer field includes the identifier of the first terminal, the subject field includes the identifier of the first entity, the audience field includes the identifier of the first BAR network element, and the expiration time field includes t1.

[0198] In representation 2, the token includes the identifier of the first digital human, 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 token pre-sets the location of each piece of information, and then the first terminal fills the identifier of the first digital human, 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.

[0199] Step 304: The first terminal sends a token.

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

[0201] It is 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 a first ADC, which is used for rendering capability negotiation. After the rendering capability negotiation process, the first terminal and the DC AS also need to establish a second ADC, which is used to transmit business data, such as transmitting data between the first terminal and the second terminal (e.g., data used for rendering entities (e.g., user information), transmitting the rendered digital human, etc.).

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

[0203] It is worth noting 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 a second ADC with the DC AS based on the second MF network element.

[0204] Based on whether the first entity is an MF network element, DC AS, second terminal, or first terminal, explain how the first entity obtains the token:

[0205] When the first entity is an MF network element, the first terminal can first send a re-invitation 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 a token.

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

[0207] Verification 1: Check whether the digital human identifier in the MF network element verification token is consistent with the digital human identifier verified by the previous DC AS;

[0208] Verification 2: The MF network element verifies whether the digital human identifier in the media resource reservation message is consistent with the digital human identifier verified by the DC AS in the previous verification.

[0209] For ease of description, the following explanation will use Verification 1 and Verification 2 as examples. 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] For example, an MF network element can perform check 1 and / or check 2 in the following manner:

[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. The digital human identifier verification result is used to indicate whether the identifier of the digital human to be verified has been successfully verified.

[0212] In method (2), the MF network element sends a digital human identifier list request to the DC AS / DCSF network element, carrying the identifier of the first terminal in the request. The DC AS / DCSF network element then 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 is understandable that when an MF element determines that it has failed verification 1 and / or verification 2, the MF element may no longer execute the subsequent rendering process.

[0214] When the first entity is a DC AS, the first terminal can first send a re-invitation message to the IMS AS. The IMS AS then sends a media resource reservation to the MF network element, which includes a token. After obtaining the token, the MF network element forwards it to the DC AS. For example, after receiving the media resource reservation message, the MF network element can also 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 has failed, the MF network element may not forward the token to the DC AS.

[0215] When the first entity is the second terminal, the first terminal can first send a re-invitation message to the IMS AS, and then the IMS AS can send a re-invitation message to the second terminal. For example, communication between the terminal and the IMS AS is forwarded via the P / S-CSCF network element; that is, the first terminal can first send a re-invitation message to the P / S-CSCF network element, and then the P / S-CSCF network element 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 then the P / S-CSCF network element sends a re-invitation message to the second terminal.

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

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

[0218] In the relevant process shown in Figure 3, the first entity obtains a token. Subsequently, the first entity can request the first digital human model based on the token, as illustrated in the flowchart of the second communication method provided in Figure 4. This method can be executed by the first entity and the first BAR network element.

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

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

[0221] Depending on whether the first entity is a proxy entity or a rendered entity, the following examples illustrate different cases:

[0222] Scenario 1: The first entity is a proxy entity, that is, the first entity is a DC AS. The DC AS proxy rendering entity sends a digital human model download request to the first BAR network element. The rendering entity can be a first terminal, a second terminal, or an 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 the rendered entity:

[0224] Case 2.1: The first entity is the first terminal. 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] For example, after receiving a digital human model download request, the MF network element can also perform the aforementioned verification 1 and / or verification 2. It can be understood that when the MF network element determines that verification 1 and / or verification 2 has failed, the MF network element may no longer forward the digital human model download request to the DC AS.

[0226] In scenario 2.2, the first entity is the second terminal, which 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; and the DC AS sends a digital human model download request to the first BAR network element.

[0227] For example, after receiving a digital human model download request, the MF network element can also perform the aforementioned verification 1 and / or verification 2. It can be understood that when the MF network element determines that verification 1 and / or verification 2 has failed, 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, MF network element, sends a digital human model download request to DC AS; DC AS sends a digital human model download request to the first BAR network element.

[0229] Step 402: The first BAR network element confirms that the verification has passed based on the token.

[0230] In one possible example, the token includes information about the first entity. The first BAR network element can determine, based on the information about the first entity included in the token, that the entity that sent the token is the entity authorized to download the first digital human model, and thus confirm that the verification has passed.

[0231] Depending on whether the first entity is a proxy entity or a rendered entity, the following examples illustrate different cases:

[0232] Scenario 1: The first entity is a proxy 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 verifies the identity of the DC AS; furthermore, after the first BAR network element confirms that the information of the first entity in the token is the information of the DC AS, it confirms that the verification is successful.

[0233] Case 2, the first entity is the rendered entity:

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

[0235] In scenario 2.2, when the first entity is an MF network element and the MF network element and the first BAR network element are communicating end-to-end, the first BAR network element verifies the identity of the MF network element when establishing a TLS channel with the MF network element. Furthermore, after the first BAR network element confirms that the information of the first entity in the token is the information of the MF network element, it determines that the verification has passed.

[0236] The first entity is the MF network element. When 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. The CCA includes the information of the MF network element. After the first BAR network element verifies that the subject in the verification token is the information of the MF network element in the CCA, it confirms that the verification is successful.

[0237] In scenario 2.3, the first entity is the second terminal, and when the second terminal and the first BAR network element conduct end-to-end communication, the first BAR network element verifies the identity of the second terminal by establishing TLS with the second terminal. Furthermore, after the first BAR network element confirms that the information of the first entity in the token is the information of the second terminal, it determines that the verification has passed.

[0238] The first entity is the second terminal, and when 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. The CCA includes the information of the second terminal. After the first BAR network element verifies that the subject in the verification token is the information of the second terminal in the CCA, it determines that the verification is successful.

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

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

[0241] For example, after determining that the verification has passed based on the token, the first BAR network element sends a first digital human model to the first entity. For example, the first BAR network element sends a digital human model response to the first entity, the digital human model response including the first digital human model. Furthermore, when the first BAR network element determines that the verification has failed based on the token, the first BAR network element sends a verification failure response to the first entity.

[0242] Step 404: When the first entity is a rendering entity, the first entity generates a digital human based on the first digital human model; when the first entity is a proxy 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 based on the first digital human model.

[0243] It should be noted that the relevant embodiment in Figure 4 uses the first entity (i.e., the entity authorized by the first terminal to download the first digital human model) as an example for illustration. This embodiment also describes the second entity sending a token to the first BAR network element. Accordingly, the first BAR network element can determine whether the second entity is a token-authorized entity (i.e., the first entity). If the first BAR network element determines that the second entity is a token-authorized entity, then the verification is deemed successful; if the first BAR network element determines that the second entity is not a token-authorized entity, then the verification is deemed unsuccessful.

[0244] Figure 4 illustrates the relevant embodiment using the first BAR network element (i.e., the entity providing the first digital human model) as an example. This embodiment further describes 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 an entity authorized by the token, but also needs to determine whether it is the BAR network element indicated by the token (i.e., 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 an entity authorized by the token and that it is the BAR network element indicated by the token, then the verification is successful, and the first digital human model is provided to the second entity; otherwise, the verification is unsuccessful, and the first digital human model is not provided to the second entity.

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

[0246] Based on the descriptions in the relevant embodiments of Figures 3 and 4 above, Figure 5 is a flowchart illustrating the third communication method provided by this application. Specifically, the DC AS determines the information of the first entity based on the first configuration information, wherein the first entity is an MF network element. Further, the MF network element 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.

[0247] Step 501: Establish a first ADC between the first terminal and the DC AS. The first ADC is used for rendering negotiation. For example, prior to step 501, the method further includes: establishing 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. For example, 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 be found in the description of step 301.

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

[0250] Step 504: The DC AS determines the information of the first entity based on the first configuration information; the DC AS determines the information of the first BAR network element based on the second configuration information. The first and 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, such as 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. For a detailed implementation of step 504, please refer to the descriptions in steps A and B.

[0251] Step 505: The DC AS determines the capability negotiation result. For example, the DC AS determines the rendering data type used by the MF network element in the rendering process of the first digital human based on the rendering data requirements of the MF network element, and the capability negotiation result includes the rendering data type.

[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, information about the MF network element, and information about the first BAR network element. For a detailed implementation of step 506, please 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. For example, the subject field in the token is information about the MF network element, the issuer field is the identifier of the first terminal, and the audience field is information about the first BAR network element. The specific implementation of step 507 can be found in the description in 304. For example, before step 507, the first terminal may also generate a token based on the information of the MF network element and the first BAR network element; the specific implementation can be found in 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. For a detailed implementation of step 508, please refer 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, a token, and the identifier of the first digital human. For a detailed implementation of step 509, please refer to the description in section 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. The digital human model response includes the first digital human model. For a detailed implementation of step 510, please refer to the description in 403. For example, before step 510, the first BAR network element may also determine that the verification is successful after confirming that the subject field in the token is information from the MF network element and the audience field is information from the first BAR network element; for a detailed implementation, please refer to the description in 402.

[0257] Step 511: The MF network element generates the first digital human based on the first digital human model.

[0258] In the relevant embodiments shown in Figure 5, 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 is understood that Figure 5 only illustrates the steps related to this application. Other steps may also be included in the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, which will not be listed in this application.

[0259] Referring to the descriptions in the embodiments of Figures 3 and 4 above, and as illustrated in Figure 6, which is a flowchart of the fourth communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining the information of the first entity based on the first configuration information. Further, the first entity is a first terminal, which requests a first digital human model from the 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 the DC AS. The first ADC is used for rendering negotiation. For example, prior to step 601, the method further includes: establishing a BDC between the first terminal and the DC AS.

[0261] Step 602: 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. For example, 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 be found in the description of 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 be found in the description of step C.

[0263] Step 604: The DC AS determines the information of the first entity based on the first configuration information; the DC AS determines the information of the first BAR network element based on the second configuration information. The first and 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, such as 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. For a detailed implementation of step 604, please refer to the descriptions in steps A and B.

[0264] Step 605: DC AS determines the capability negotiation result. For example, DC AS determines the rendering data type used by the first terminal in the rendering process of the first digital human based on the rendering data requirements of the first terminal, and the capability negotiation result includes the rendering data type.

[0265] Step 606: 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, information about the first terminal, and information about the first BAR network element. For a detailed implementation of step 606, please 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. For example, the subject field in the token contains information about the first terminal, the issuer field contains the identifier of the first terminal, and the audience field includes information about the first BAR network element. The specific implementation of step 607 can be found in the description in 304. For example, before step 607, the first terminal may also generate a token based on the information of the first terminal and the information of the first BAR network element; the specific implementation can be found in 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 a digital human model response from itself. The digital human model response includes a first digital human model. For a detailed implementation of step 608, please refer to the description in 403. For example, before step 608, the first BAR network element may also determine that the verification is successful after confirming that the subject field in the token is information from the first terminal and the audience field is information from the first BAR network element; for a detailed implementation, please refer to the description in 402.

[0268] Step 609: The first terminal generates the first digital human based on the first digital human model.

[0269] Steps 602 to 606 constitute the rendering capability negotiation process, while steps 607 to 609 constitute the digital human rendering process. It is understood that Figure 6 only exemplifies the steps relevant to this application. Other steps may also be included in the rendering capability negotiation process and the digital human rendering process. Furthermore, before the digital human rendering process, the first terminal will send a re-invitation message to the IMS AS to request the establishment of a second ADC; these will not be listed in this application.

[0270] Figure 7 is a flowchart illustrating the fifth communication method exemplarily provided in this application. Specifically, in this communication method, the DC AS determines the information of the first entity based on the first configuration information. Further, the first entity is a second terminal, which also requests a first digital human model from the first BAR network element and generates a 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. For example, prior to step 701, the method 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. For example, 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 702 can be found in the description of step 301.

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

[0274] Step 704: The DC AS determines the information of the first entity based on the first configuration information; the DC AS determines the information of the first BAR network element based on the second configuration information. The first and 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, such as 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 a detailed implementation of step 704, please refer to the descriptions in steps A and B.

[0275] Step 705: DC AS determines the capability negotiation result. For example, DC AS determines the rendering data type used by the second terminal in the rendering process of the first digital human based on the rendering data requirements of the second terminal, and the capability negotiation result includes the rendering data type.

[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, information about the second terminal, and information about the first BAR network element. For a detailed implementation of step 706, please refer to the description in step 302.

[0277] Step 707: 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. For example, the token's subject field contains information about the second terminal, the issuer field contains the identifier of the first terminal, and the audience field includes information about the first BAR network element. The specific implementation of step 707 can be found in the description in 304. For example, before step 707, the first terminal may also generate a token based on the information of the second terminal and the information of the first BAR network element; the specific implementation can be found in the description in 303.

[0278] Step 708: The IMS AS sends a re-invitation message to the P / S-CSCF network element. Correspondingly, the P / S-CSCF network element receives the re-invitation 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, a token, and the identifier of the first digital human. For a detailed implementation of step 710, please refer to the description in section 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. The digital human model response includes the first digital human model. For a detailed implementation of step 711, please refer to the description in 403. For example, before step 711, the first BAR network element may also determine that the verification is successful after determining that the subject field in the token is information from the second terminal and the audience field is information from the first BAR network element; for a detailed implementation, please refer to the description in 402.

[0282] Step 712: The second terminal generates the first digital human based on the first digital human model.

[0283] Steps 702 to 706 constitute the rendering capability negotiation process, steps 707 to 709 constitute the second ADC establishment process, and steps 710 to 712 constitute the digital human rendering process. It is understood that Figure 7 only illustrates the steps relevant to this application, and other steps may also be included in the rendering capability negotiation process, ADC establishment process, and digital human rendering process, which will not be listed in this application.

[0284] Figure 8 is a flowchart illustrating the sixth communication method exemplarily provided in this application. Specifically, in this method, the DC AS determines the information of the first entity based on 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, which also requests a 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. For example, prior to step 801, the method 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. For example, 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 found in the description of step 301.

[0287] Step 803: 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 found in the description of 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 negotiation parameters for the second terminal. The negotiation parameters of the second terminal include the rendering capabilities of the second terminal and the candidate entities recommended by the second terminal. For a detailed implementation of step 804, please refer to the description in step A.

[0289] In 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. For a detailed implementation of step 805, please refer 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 from the second terminal includes the negotiation parameters of the second terminal. For a detailed implementation of step 806, please refer 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 MF network element's rendering capability response 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 its rendering capabilities and the candidate entities recommended by the MF network element. For a detailed implementation of step 807, please refer to the description in step A.

[0292] In step 808, the DC AS determines the information of the first entity (i.e., the information of the MF network element) based on the negotiation parameters of the first terminal, the negotiation parameters of the second terminal, and the negotiation parameters of the MF network element. Additionally, the DC AS determines the information of the first BAR network element based on the second configuration information. For a detailed implementation of step 808, please refer to the descriptions in steps A and B.

[0293] Step 809: The DC AS determines the capability negotiation result. For example, the DC AS determines the rendering data type used by the MF network element in the rendering process of the first digital human based on the rendering data requirements of the MF network element, and the capability negotiation result includes the rendering data type.

[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 capability negotiation result, information about the MF network element, and information about the first BAR network element. For a detailed implementation of step 810, please refer to the description in step 302.

[0295] Following step 810, steps 507 to 511 may also be included. Steps 802 to 810 pertain to the rendering capability negotiation process. It is understood that Figure 8 only exemplifies the steps relevant to this application; other steps may also be included in the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, which are not listed here.

[0296] Furthermore, in the relevant embodiments shown in Figure 8, if the first entity is a first terminal, steps 607 to 609 may be included after step 810. If the first entity is a second terminal, steps 707 to 712 may be included after step 810. Further details will not be provided.

[0297] Figure 9 is a flowchart illustrating the seventh communication method exemplarily provided in this application. Specifically, in this method, the DC AS determines the information of the first entity based on the negotiation parameters of the first terminal, the negotiation parameters of the second terminal, and the negotiation parameters of the MF network element. The DC AS then 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). The second MF network element also requests a first digital human model from the first BAR network element and generates a first digital human based on the first digital human model.

[0298] The difference between the related embodiments in Figure 9 and those in Figure 8 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 begins 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 then determines the information of the first BAR network element based on the second configuration information. For a detailed implementation of step 901, please refer to the descriptions in steps A and B.

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

[0301] Step 903: The NRF network element sends a first response to the DC AS, and correspondingly, the DC AS receives the first response from 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 of the second MF network element based on preset rendering requirements and sends the first response to the DC AS. The specific implementation of step 903 can be found in the description of step A.

[0302] Step 904: The DC AS sends information about the second MF network element to the IMS AS. This information is used by the DC AS to update the MF network element, enabling the first terminal to establish a second ADC with the DC AS based on the second MF network element. For example, the DC AS may also send information about the second MF network element to the DCSF network element. This information is used by the DCSF network element to update the MF network element, enabling the first terminal to establish a second ADC with the DC AS based on the second MF network element. For a detailed implementation of step 904, please refer to the description in step A.

[0303] Following step 904, steps 507 to 511 may be included, the difference being that the first MF is replaced with the second MF. Steps 901 to 904 pertain to the rendering capability negotiation process. It is understood that Figure 9 only exemplifies the steps relevant to this application; other steps may also be included in the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, which are not listed here.

[0304] It should also be noted that the above embodiments are all illustrated using the DC AS determining the information of the first entity as an example. In other possible examples, the MF network element, the first terminal, the second terminal, or other network elements can also determine the information of the first entity. For example, in the case where the MF network element determines the information of the first entity, the MF network element can determine the information of the first entity when the capability negotiation request of the first terminal is sent to the MF network element. For example, 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 capability negotiation. For example, in the case where the second terminal determines the information of the first entity, the DC AS can request the information of the first entity from the second terminal after receiving the capability negotiation request. 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. For example, in the case where other network elements determine the information of the first entity, the DC AS can forward the capability negotiation request to the other network element after receiving the capability negotiation request. The other network element determines the information of the first entity, and then 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 embodiments are merely examples of the execution flow and do not constitute a restriction on the order of step execution. In the embodiments of this application, there is no strict execution order between steps that do not have temporal dependencies. Not all steps shown in the flowcharts are mandatory; some steps can be deleted or added as needed.

[0306] The above description focuses on the differences between the various embodiments. Apart from the differences, the various embodiments can be referred to each other. In addition, different implementations or different examples in the same embodiment can also be referred to each other.

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

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

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

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

[0311] Processing module 1001 is used to generate a token based on the information of 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 also used to send tokens.

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

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

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

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

[0317] In one possible implementation, the capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capabilities 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 elements related to the call, the first terminal, and the second terminal.

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

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

[0320] The transceiver module 1002 is used to receive capability negotiation requests, which carry the digital human's identifier and are used to negotiate the rendering of the digital human.

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

[0322] The transceiver module 1002 is also used to send a capability negotiation response, which includes information about the first entity. The first entity is the entity used to download the digital human model, which is used for rendering the digital human.

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

[0324] In one possible implementation, the capability negotiation response also includes information about the entity used to store the digital human model.

[0325] In one possible implementation, the capability negotiation request carries negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capabilities 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 elements related to the call, the first terminal, and the second terminal; in one possible implementation, when determining the information of the first entity, the processing module 1001 is specifically used to determine the information of the first entity based on the negotiation parameters of the first terminal.

[0326] In one possible implementation, when the processing module 1001 determines the information of the first entity based on the negotiation parameters of the first terminal, it is specifically used to obtain the negotiation parameters of the MF network element and the negotiation parameters of the second terminal from the MF network element; and to determine the information of the first entity based on the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal.

[0327] In one possible implementation, the first entity is one of the DC AS, MF network element, first terminal, and second terminal associated with the call.

[0328] In one possible implementation, when the processing module 1001 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 requirements, the transceiver module 1002 is further configured to send a first request to the NRF network element, the first request including the preset rendering requirements, the first request being used to request a first entity that meets the preset rendering requirements; and to receive a first response from the NRF network element, the first response including information about the first entity.

[0329] In one possible implementation, the capability negotiation request is sent by the first terminal to the transceiver module 1002 via 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 information received by the transceiver module 1002 from the first terminal via the first ADC.

[0330] Figure 11 shows the apparatus 1100 provided in an embodiment of this application. The apparatus shown in Figure 11 can be a hardware circuit implementation of the apparatus shown in Figure 10. This apparatus can be applied to the flowcharts shown above to perform the functions of the first terminal or DC AS in the above method embodiments. For ease of explanation, Figure 11 only shows the main components of the apparatus.

[0331] The device 1100 shown in Figure 11 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 operate in conjunction with the memory 1130. The processor 1120 may execute the program instructions stored in the memory 1130. When the instructions or program stored in the memory 1130 are executed, the processor 1120 is used to perform the operations performed by the processing module 1001 in the above embodiments, and the communication interface 1110 is used to perform 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 this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. At least one of the memories 1130 may be included in the processor 1120.

[0333] In this embodiment, the communication interface can be a transceiver, circuit, bus, module, or other type of communication interface. In this embodiment, when the communication interface is a transceiver, the transceiver can include an independent receiver, an independent transmitter, or a transceiver integrating transceiver functions, or simply a communication interface.

[0334] Device 1100 may also include a communication line 1140. The communication interface 1110, processor 1120, and memory 1130 can be interconnected via the communication line 1140. The communication line 1140 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication line 1140 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in Figure 11, but this does not indicate that there is only one bus or one type of bus.

[0335] Based on the above content and the same concept, this application also provides a computer-readable storage medium storing a computer program or instructions, which, when executed by a communication device, implement the method executed by the first terminal in the above method embodiments, or implement the method executed by the DC AS in the above method embodiments.

[0336] Based on the above content and the same concept, this application also provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a communication device, they implement the method executed by the first terminal in the above method embodiments, or implement the method executed by the DC AS in the above method embodiments.

[0337] Based on the above content and the same concept, this application also 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 embodiments, and the second communication device implements the method executed by the DC AS in the above method embodiments.

[0338] In this application embodiment, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one 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, and c can be single or multiple.

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

[0340] In the embodiments of this application, "when," "if," and "if" all refer to the device taking corresponding actions under certain objective circumstances, and are not time-limited, nor do they require the device to perform a judgment action, nor do they imply any other limitations. Unless otherwise specified, "if" and "if" can be substituted, and "when" and "in the case of" can be substituted. "When" and "if" / "if" can be substituted.

[0341] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0342] In this application, the ordinal numbers such as "first" and "second" are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority, or importance of the multiple objects. For example, "first instruction information" and "second instruction information" refer to two different instruction information, and do not indicate a difference in priority or importance between the two instruction information.

[0343] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order 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 are conducting digital human-related calls, characterized in that, include: The first communication device sends a capability negotiation request, which carries the identifier of the digital human and is used to negotiate the rendering of the digital human. The first communication device receives a capability negotiation response, which includes information about a first entity, the first entity being an entity used to download a digital human model, the digital human model being used for rendering the digital human; The first communication device generates a token based on the information of the first entity, and 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 as described in claim 1, characterized in that, The token includes information about the first entity and the identifier of the digital human.

3. The method as described in claim 1 or 2, characterized in that, The token is carried in the re-invitation message.

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

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

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

7. The method according to any one of claims 1-6, characterized in that, The capability negotiation request is sent by the first communication device to the data channel application server through the application data channel; The application data channel is the 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 are conducting a digital human-related call, characterized in that, include: The second communication device receives a capability negotiation request, which carries the identifier of the digital human and is used to negotiate the rendering of the digital human. The second communication device sends a capability negotiation response, which includes information about a first entity, which is an entity used to download a digital human model, and the digital human model is used for rendering the digital human. The information of the first entity is used to generate a token, which is used to authorize the first entity to download the digital human model. The second communication device is a data channel application server or a part of the data channel application server associated with the call.

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

10. The method as described in claim 8 or 9, characterized in that, The capability negotiation request carries the negotiation parameters of the first terminal; the negotiation parameters of the first terminal include the rendering capabilities of the first terminal and / or the candidate entities recommended by the first terminal. The candidate entities include one or more of the media function network elements related to the call, the first terminal, and the second terminal; Following the second communication device's capability negotiation request, the following is also included: The second communication device determines the information of the first entity based on the negotiation parameters of the first terminal.

11. The method as described in claim 10, characterized in that, The second communication device determines the information of the first entity based on the negotiation parameters of the first terminal, including: The second communication device obtains the negotiation parameters of the media function network element and the negotiation parameters of the second terminal; The second communication device determines the information of the first entity based on 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-11, characterized in that, The first entity is one of the data channel application server, media function network element, first terminal, and second terminal associated with the call.

13. The method as described in claim 11, characterized in that, Also includes: When the second communication device determines 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 all fail to meet the preset rendering requirements, it sends a first request to the network storage function network element. The first request includes the preset rendering requirements and is used to request a first entity that meets the preset rendering requirements. The second communication device receives a first response from the network storage function element, the first response including information about the first entity.

14. The method according to any one of claims 8-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 the channel between the first terminal and the second communication device.

15. A communication device, characterized in that, It includes a module for performing the method as described in any one of claims 1 to 7, or includes a module for performing the method as described in any one of claims 8 to 14.

16. A communication device, characterized in that, The device includes a processor and an interface circuit, wherein the interface circuit is used to receive signals from other communication devices besides the communication device and transmit them to the processor, or to send signals from the processor to other communication devices besides the communication device. The processor implements the method as described in any one of claims 1 to 7 through logic circuits or executable code instructions, or the processor implements the method as described in any one of claims 8 to 14 through logic circuits or executable code instructions.

17. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a communication device, implement the method as described in any one of claims 1 to 7, or implement the method as described in any one of claims 8 to 14.

18. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a communication device, implement the method as described in any one of claims 1 to 7, or implement the method as described in any one of claims 8 to 14.

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

Images