Communication method and apparatus

Abstract

A communication method and apparatus, which are used for ensuring the security of an avatar model. The method is applied to a scenario in which a first terminal and a second terminal perform an avatar-related call. The method comprises: an NRF receiving information of a first entity from a DC AS, wherein the first entity is determined by the DC AS after receiving a capability negotiation request and is an entity used for downloading a first avatar model, and the DC AS is related to a call; the NRF receiving a token request, wherein the token request carries information of a second entity and an identifier of a first avatar; when determining that the second entity is the first entity, the NRF generating a first token; and the NRF sending the first token, wherein the first token is used for authorizing the second entity to download the first avatar model, and the first avatar model is used for avatar rendering.

Description

A communication method and apparatus

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510138713.2, 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 include, for example, 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, wherein the first communication device may be a network repository function (NRF) network element, or a part of an NRF network element (e.g., a chip in an NRF network element). The first communication device may also be a network exposure function (NEF) network element, or a part of a NEF network element (e.g., a chip in a NEF network element).

[0008] When the first communication device is an NRF network element, for example, it can receive information from a data channel application server (DC AS). When the first communication device is a module within an NRF network element, it can receive information from other modules (such as RF modules or antennas), for example, information sent from the DC AS to the NRF network element. When the first communication device is a NEF network element, for example, it can receive information from a DC AS. When the first communication device is a module within a NEF network element, it can receive information from other modules (such as RF modules or antennas), for example, information sent from the DC AS to the NEF network element.

[0009] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes: a first communication device receiving information from a first entity from a DC AS (Digital Human Assistance System), the first entity being determined by the DC AS after receiving a capability negotiation request and used to download a first digital human model, wherein the DC AS is related to the call; the first communication device receiving a token request, the token request carrying information about a second entity and an identifier of the first digital human; the first communication device generating a first token if it determines that the second entity is the first entity; and the first communication device sending the first token, the first token being used to authorize the second entity to download the first digital human model, the first digital human model being used for rendering the first digital human.

[0010] In the above technical solution, when the first communication device receives a token request, if it determines that the second entity sending the token request is the first entity (i.e., the entity capable of downloading the first digital human model), it issues a first token to the second entity. Compared to the first communication device generating a first token based on coarse-grained information, such as generating a first token for all entities that might use the first token (e.g., entities belonging to terminal type, MF entity type, and DC AS type), in this application, the first communication device generates a first token based on fine-grained information. This first token is used by the first entity (or the second entity) to download the first digital human model, but cannot be used by other entities to download the first digital human model, thus preventing the abuse of the right to download the first digital human model and improving security. Therefore, when the second entity requests the first digital human model from the base avatar repository (BAR) network element based on the first token, the BAR network element can verify the identity of the second entity based on the first token and provide the first digital human model to the second entity. Issuing the first token through the first communication device improves the security of the process of requesting the digital human model.

[0011] Furthermore, the information of the first entity is determined by the DC AS during the capability negotiation process, which helps to reduce the number of signaling interactions.

[0012] In one possible implementation, when the DC AS is located inside an Internet Protocol (IP) Multimedia Subsystem (IMS) network, the first communication device is an NRF network element, or a part of an NRF network element; when the DC AS is located outside an IMS network, the first communication device is an NRF network element (e.g., when the DC AS communicates with an NRF network element, the message is forwarded by an NEF network element), or a part of an NRF network element, or the first communication device is an NEF network element, or a part of a NEF network element.

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

[0014] In the above technical solution, the first token carries the information of the first entity and the identifier of the first digital human. 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 first token, which helps to improve the security of the process of requesting the first digital human model.

[0015] In one possible implementation, the first communication device also receives information from the DC AS regarding an entity for storing the first digital human model, and the first token includes the information regarding the entity for storing the first digital human model.

[0016] In the above technical solution, the first communication device carries information about the entity storing the first digital human model (e.g., the identifier of the first BAR network element) in the first token. When the second BAR network element receives a request from the second 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 first token is the information of the second BAR network element, and thus determine whether to provide the first digital human model to the second 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 first 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 second entity; if the second BAR network element determines that the information about the entity storing the first digital human model included in the first 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 second entity. This helps to further ensure the security of the first digital human model in the BAR network element.

[0017] Furthermore, compared to the first communication device generating a first token based on coarse-grained information (such as information about all entities that may provide the first digital human model), the first communication device generates a first token based on fine-grained information (such as information about the first BAR network element). This first token is used by the second entity to request the first digital human model from the first BAR, but cannot be used by the second entity to request the first digital human model from other entities. In other words, this first 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 first digital human model is more accurate, avoiding the abuse of the right to provide the first digital human model and further ensuring security.

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

[0019] In one possible implementation, the token request also carries a second token, which is generated by the first terminal. Specifically, when the first communication device generates the first token, it may do so based on information about the first entity and the second token.

[0020] Secondly, this application provides a communication method, which can be executed by a first communication device. The first communication device can be an NRF network element, or a part of an NRF network element (e.g., a chip in an NRF network element). The first communication device can also be an NEF network element, or a part of a NEF network element (e.g., a chip in a NEF network element).

[0021] When the first communication device is an NRF network element, for example, it can receive information from a DC AS. When the first communication device is a module within an NRF network element, it can receive information from other modules (such as RF modules or antennas), for example, information sent from the DC AS to the NRF network element. When the first communication device is a NEF network element, for example, it can receive information from a DC AS. When the first communication device is a module within a NEF network element, it can receive information from other modules (such as RF modules or antennas), for example, information sent from the DC AS to the NEF network element.

[0022] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes: a first communication device receiving information about a first entity from a DC AS (Digital Human Provider Interface). The first entity is determined by the DC AS after receiving a capability negotiation request and is used to download a first digital human model. The DC AS is associated with the call. The first communication device receives a verification request from a BAR (Browser Access Provider) element. The verification request includes information about a second entity. The verification request is sent by the BAR element after receiving a digital human model download request from the second entity. The digital human model download request is used by the second entity to request the download of the first digital human model. The first communication device sends a verification response to the BAR element. The verification response indicates that the second entity is the first entity. For example, based on the verification response, the BAR element sends the first digital human model to the second entity.

[0023] In the above technical solution, after receiving the digital human model download request from the second entity, the BAR network element sends a verification request to the first communication device to determine whether the second entity is the first entity (i.e., the entity downloading the first digital human model). If so, the first digital human model is provided to the second entity, which helps improve the security of the process of requesting the first digital human model. Furthermore, the information of the first entity is determined by the DC AS in the capability negotiation process, which helps to save the number of signaling interactions.

[0024] Thirdly, 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 an NRF network element, 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 radio frequency modules or antennas), for example, the information is sent by the DC AS to an NRF network element, or the second communication device can receive information from other modules, the information is sent by the first terminal to the DC AS.

[0026] This method is applied to scenarios where a first terminal and a second terminal conduct digital human-related calls. The method includes: a second communication device receiving a capability negotiation request, the capability negotiation request carrying the identifier of a first digital human, the capability negotiation request being used to negotiate the rendering of the first digital human; the second communication device determining information about a first entity, the first entity being an entity used to download a first digital human model, the first digital human model being used for rendering the first digital human; the second communication device sending information about the first entity; the second communication device being a DC AS or a part of a DC AS related to the call.

[0027] In one possible implementation, the second communication device further transmits information about the entity storing the first digital human model, based on the identifier of the first digital human. This information about the entity storing the first digital human model may, for example, be the identifier of the first BAR network element.

[0028] In one possible implementation, the second communication device also sends a token request, for example, to an NRF network element or a NEF network element. The token request includes information about the second entity and the identifier of the first digital human. If the second entity is the first entity, the second communication device also receives a first token, which is used to authorize the second entity to download the first digital human model.

[0029] In one possible implementation, the token request also includes a second token generated by the first terminal, the first token being generated based on the second token and information from the first entity. For example, the second communication device also receives the second token from the first terminal.

[0030] In one possible implementation, when the DC AS is located within the IMS network, the second communication device sends information about the first entity; specifically, the second communication device sends the information about the first entity to an NRF network element. When the DC AS is located outside the IMS network, the second communication device sends information about the first entity; specifically, the second communication device sends the information about the first entity to an NEF network element or an NRF network element. Alternatively, the second communication device sends information about the first entity; specifically, the second communication device sends the information about the first entity to a Home Subscriber Server (HSS) network element or a Resource Owner Function (ROF) network element.

[0031] 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 element related to the call, the first terminal, and the second terminal. When determining the information of the first entity, the second communication device may specifically determine the information of the first entity based on the negotiation parameters of the first terminal. For example, when the second communication device determines the information of the first entity based on the negotiation parameters of the first terminal, it may specifically obtain the negotiation parameters of the MF 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 MF network element, and the negotiation parameters of the second terminal.

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

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

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

[0035] (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.

[0036] (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.

[0037] (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.

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

[0039] In one possible implementation, when the second communication device 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 all fail to meet the preset rendering requirements, it can also send a first request to the 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. The second communication device receives a first response from the NRF network element, which includes information about the first entity. 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 all fail to meet the preset rendering requirements, the DC AS can also request information about the first entity from the NRF network element to ensure the normal progress of the rendering process.

[0040] In one possible implementation, the capability negotiation request is information received by the second communication device from the first terminal via the first application data channel (ADC); wherein the first ADC is the channel between the first terminal and the second communication device.

[0041] For example, the capability negotiation request is sent by 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 the MF network element, and the MF network element forwards the capability negotiation request to the DC AS.

[0042] Fourthly, embodiments of this application provide a communication device. This communication device has the functions of implementing the first communication device in the first aspect or any possible implementation of the first aspect described above. This communication device may also have the functions of implementing the first communication device in the second aspect or any possible implementation of the second aspect described above. This communication device may also have the functions of implementing the second communication device in the third aspect or any possible implementation of the third aspect described above. The functions of the above-described communication device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules, units, or means corresponding to the above-described functions.

[0043] In one possible implementation, the device includes a processing module and a transceiver module. 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 thereof, or in performing the functions of the first communication device in the second aspect or any possible implementation thereof, or in performing the functions of the second communication device in the third aspect or any possible implementation thereof.

[0044] The transceiver module supports communication between the device and other communication devices. For example, when the device is a first communication device, it can receive information from a first entity. The communication device may also include a storage module coupled to the processing module, which stores 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. The memory may be integrated with the processor or separated from it.

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

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

[0047] Fifthly, 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 to perform the method in the second aspect or any possible implementation of the second aspect, or to perform the method in the third aspect or any possible implementation of the third aspect.

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

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

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

[0051] Sixthly, 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.

[0052] In a seventh aspect, 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.

[0053] Eighthly, embodiments of this application provide a communication system, which includes a first communication device and a second communication device. The first communication device implements the method in the first aspect or any possible implementation of the first aspect, and the second communication device implements the method in the third aspect or any possible implementation of the third aspect; or the first communication device implements the method in the second aspect or any possible implementation of the second aspect, and the second communication device implements the method in the third aspect or any possible implementation of the third aspect.

[0054] The technical effects achievable by any of the second to eighth 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 eighth aspects can be referenced interchangeably. Attached Figure Description

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

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

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

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

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

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

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

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

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

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

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

[0066] Figure 10 is a flowchart illustrating the eighth communication method provided in this application;

[0067] Figure 11 is a flowchart illustrating the ninth communication method provided in this application;

[0068] Figure 12 is a flowchart illustrating the tenth communication method provided in this application;

[0069] Figure 13 is a flowchart illustrating the eleventh communication method provided in this application;

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

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

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

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

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

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

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

[0077] In this context, a call, also known as a communication service, refers to a service where a terminal, acting as either 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 embodiment uses a one-to-one call as an example, but related solutions can be used for one-to-many calls.

[0078] 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. For example, the communication network may include one or more network devices.

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

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

[0081] 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:

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

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

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

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

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

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

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

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

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

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

[0092] 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).

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

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

[0095] 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. For example, the MF network element can drive the rendering of an animated digital human based on a digital human model and user information (e.g., motion information, language information, facial expression information, text information, etc.). For example, the MF network element can also download a digital human model from the BAR network element based on the digital human's identifier.

[0096] 11. BAR Network Element: Used to store digital human models and their identifiers (which can be represented as Avatar IDs). For example, a terminal may correspond 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).

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

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

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

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

[0101] A digital human model is a 2D or 3D model or graphic of a first-endpoint 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 local storage device of the terminal.

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

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

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

[0105] This application provides a communication method to ensure security during the rendering process. The 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 calling party (or initiator), initiates a digital human-related call to the second terminal, and the second terminal, as the called party (or terminating party), receives the digital human-related call.

[0106] Figure 3 is a flowchart illustrating a communication method provided by this application.

[0107] The communication method can be executed by a first communication device and a second communication device. The first communication device can be an NRF network element or a part of an NRF network element (e.g., a chip), or it can be a NEF network element or a part of a NEF network element (e.g., a chip). The second communication device can be a DC AS associated with the call or a part of that DC AS (e.g., a chip). For ease of description, the following example uses an NRF network element or a NEF network element as the first communication device and a DC AS as the second communication device.

[0108] For example, the DC AS associated with a call refers to the DC AS used to provide data channel business logic for this call.

[0109] For example, when the first terminal and the second terminal are located in the same IMS network, the first communication device is an NRF network element when the DC AS associated with the call is located inside the IMS network; when the DC AS associated with the call is located outside the IMS network, the first communication device is an NRF network element or a NEF network element. For another example, when the first terminal and the second terminal are located in different IMS networks, the first communication device is an NRF network element when the DC AS associated with the call and the first terminal are located in the same IMS network; when the DC AS associated with the call and the first terminal are located in different IMS networks, the first communication device is an NRF network element or a NEF network element.

[0110] For ease of description, the following mainly uses NRF network elements as an example, and "DC AS related to the call" will be abbreviated as DC AS.

[0111] Figure 3 focuses on how the NRF network element verifies the identity of the second entity and then generates a first token for the second entity.

[0112] Step 301: DC AS sends the information of the first entity to the NRF network element.

[0113] Accordingly, the NRF network element receives information from the first entity of the DC AS.

[0114] The first entity is the entity determined by the DC AS after receiving the capability negotiation request, and is used to download the digital human model. The method by which the DC AS determines the entity used to download the first digital human model (i.e., the first entity) can be found in the description of the relevant embodiment in Figure 7.

[0115] For example, the first entity can be one of the following: a DC AS associated with the current call between the first terminal and the second terminal, an MF network element associated with the current call between the first terminal and the second terminal, the first terminal, and the second terminal. For example, the MF network element associated with the call refers to an MF network element used to provide media resource management functions for this call. The term "MF network element associated with the call" is simply referred to as an MF network element.

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

[0117] The information of the first entity can be the type of the first entity and / or the identity (ID) of the first entity. The information of the first entity can also be referred to as the information of the user (which can be expressed as subject in English), the information of the authorized entity, the animation negotiation parameter, the animation negotiation result, etc.

[0118] For example, the DC AS also sends information about the entity used to store the first digital human model to the NRF network element, and correspondingly, the NRF network element receives the information about the entity used to store the first digital human model from the DC AS. The information about the entity used to store the first digital human model is, for example, the identifier of the first BAR network element. The specific implementation of how the DC AS determines the information about the entity used to store the first digital human model can be found in the description of the relevant embodiments in Figure 7.

[0119] Optionally, after receiving information about the first entity from the DC AS, the NRF network element stores the information about the first entity. Optionally, after receiving information about the entity used to store the first digital human model from the DC AS, the NRF network element stores the information about the entity used to store the first digital human model. Optionally, the NRF network element also sends a reception response to the DC AS to indicate that the NRF network element has successfully received the information about the first entity (or the information about the first entity and the information about the entity used to store the first digital human model).

[0120] Step 302: The second entity sends a token request to the NRF network element, and the NRF network element receives the token request from the second entity.

[0121] The token request carries information about the second entity and the identifier (avatar id) of the first digital human. The token request is used to request a first token, which is used to download the first digital human model, and the first digital human model is used to render the first digital human.

[0122] For example, the second entity directly sends a token request to the NRF network element, wherein the second entity may be the first terminal, the second terminal, the MF network element related to the call, the DC AS related to the call, or other network elements (or terminals).

[0123] For example, the second entity sends a token request to the NRF network element through the DC AS. Correspondingly, the NRF network element receives the token request from the second entity. The second entity can be the first terminal, the second terminal, the MF network element related to the call, or other network elements (or terminals). That is, the second entity does not communicate directly with the NRF network element, but forwards messages through the DC AS.

[0124] For example, the identifier of the first digital human is used to retrieve the first digital human model; the identifier of the first digital human can also be referred to as the identifier of the first digital human model or the identifier of the model. Furthermore, the first digital human model is used for rendering the first digital human.

[0125] Step 303: If the NRF network element determines that the second entity is the first entity, it generates the first token.

[0126] Furthermore, NRF network elements do not generate a first token when they determine that the second entity is not the first entity.

[0127] The first token includes information about a first entity (or a second entity) and an identifier for the first digital human. The first token authorizes the first entity to request the download of the first digital human model. For example, the first token may also include information about an entity storing the first digital human model, authorizing the first entity to download the first digital human model from that entity. The entity storing the first digital human model may be, for example, a first BAR network element, and the information of the first BAR network element may be, for example, an identifier for the first BAR network element.

[0128] The following examples provide two representations of the first token:

[0129] In representation 1, the first token includes an authorized digital person (avatar) field, an issuer field, a user field, a service provider field, and an expiration time field. Specifically, the avatar field includes the identifier of the first digital person, the issuer field includes the identifier of the NRF network element, the subject field includes information about the first entity, the audience field includes the identifier of the first BAR network element, and the expiration time field includes t1.

[0130] In representation 2, the first token includes the identifier of the first digital human, the identifier of the NRF network element, the information of the first entity, the identifier of the first BAR network element, and t1. That is, the location of each piece of information is pre-set in the first token, and then the first terminal fills the identifier of the first digital human, the identifier of the NRF network element, the information of the first entity, the identifier of the first BAR network element, and t1 into the corresponding positions of the first token.

[0131] Furthermore, in another possible implementation, the token request may also carry a second token, which is generated by the first terminal. The NRF network element generates the first token, specifically by generating it based on the information of the first entity and the second token. For example, the NRF network element verifies the second token; after determining that the second token passes verification, it generates the first token based on the information of the first entity and the second token.

[0132] For example, the second token includes a payload field and the signature of the first terminal. The payload field further includes an avatar field and an issuer field, wherein the avatar field includes the identifier of the first digital human, and the issuer field includes the identifier of the first terminal. The NRF network element verifies the second token, which may specifically include one or more of the following: verification (1), the NRF network element determines whether the signature of the first terminal passes verification based on the public key of the first terminal; verification (2), the NRF network element determines whether the identifier of the digital human in the token request is the same as the identifier of the digital human in the avatar field of the second token. Optionally, the second token also includes a subject field, which includes information about the entity authorized to download the first digital human model (denoted as entity 1). The NRF network element verifies the second token and may further include: verification (3), whereby the NRF network element determines whether the information of entity 1 is the information of the first entity; Optionally, the second token also includes an audience field, which includes information about the entity authorized to provide the first digital human model (denoted as entity 2). The NRF network element verifies the second token and may further include: verification (4), whereby the NRF network element determines whether the information of entity 2 is the information of the first BAR network element.

[0133] For example, the second token includes an avatar field, an issuer field, a subject field, and an audience field. When the NRF network element determines that the second token passes the above verifications (1) to (4), it determines that the second token has passed the verification. When the NRF network element generates the first token based on the information of the first entity and the second token, it can reuse the contents of the avatar field, subject field, and audience field in the second token, and determine that the issuer field includes the identifier of the NRF network element and the expiration time field includes t1, and generate the first token based on the above fields.

[0134] For example, the second token includes an avatar field and an issuer field (excluding the subject field and the audience field, or the subject field and the audience field are empty). When the NRF network element determines that the second token passes the above verification (1) and verification (2), it determines that the second token has passed the verification. When the NRF network element generates the first token based on the information of the first entity and the second token, it can reuse the content of the avatar field in the second token, and determine that the issuer field includes the identifier of the NRF network element, the subject field includes the information of the first entity, the audience field includes the information of the first BAR network element, and the expiration time field includes t1, and generate the first token based on the above fields.

[0135] Step 304: The NRF network element sends the first token to the second entity, and the second entity receives the first token from the NRF network element.

[0136] The first token is used to authorize the second entity (or the first entity) to download the first digital human model.

[0137] For example, the NRF network element directly sends the first token to the second entity, which can be the first terminal, the second terminal, the MF network element related to the call, the DC AS related to the call, or other network elements (or terminals).

[0138] For example, the NRF network element sends a first token to the second entity through the DC AS, and the second entity receives the first token from the NRF network element. The second entity can be a first terminal, a second terminal, an MF network element related to the call, or other network elements (or terminals). That is, the second entity does not communicate directly with the NRF network element, but forwards messages through the DC AS.

[0139] For example, the DC AS can also send information about the first entity to a third entity, and the NRF network element sends an authorization request to the third entity to determine whether the second entity is the first entity. The third entity can be an HSS network element or a ROF network element. Figure 4 provides an exemplary flowchart of the second communication method. The HSS network element in this method can also be replaced with an ROF network element.

[0140] Step 401: DC AS sends the information of the first entity to the HSS network element.

[0141] Correspondingly, the HSS network element receives information from the first entity of the DC AS.

[0142] For example, the HSS network element stores information about a first entity. For example, the DC AS sends information about the entity used to store the first digital human model to the HSS network element, and correspondingly, the HSS network element receives the information about the entity used to store the first digital human model from the DC AS. Optionally, the HSS network element stores the information about the entity used to store the first digital human model. Optionally, the HSS network element also sends a reception response to the DC AS.

[0143] For a detailed implementation, please refer to the description in step 301.

[0144] Step 402: The second entity sends a token request to the NRF network element, and the NRF network element receives the token request from the second entity.

[0145] For a detailed implementation, please refer to the description in step 302.

[0146] Step 403: The NRF network element sends an authorization request to the HSS network element. Correspondingly, the HSS network element receives the authorization request from the NRF network element. The authorization request includes information about the second entity. The authorization request is used to determine whether the second entity is the first entity.

[0147] In step 404, if the HSS network element determines that the second entity is the first entity, it sends an authorization response to the NRF network element, and the NRF network element receives the authorization response from the HSS network element. This authorization response can be used to indicate that the second entity is the first entity.

[0148] In addition, after determining that the second entity is not the first entity, the HSS network element can also send an authorization response to the NRF network element, which can be used to indicate that the second entity is not the first entity.

[0149] Step 405: The NRF network element generates the first token.

[0150] In other words, the NRF network element generates the first token when it determines that the second entity is the first entity.

[0151] For a detailed implementation, please refer to the description in step 303.

[0152] Step 406: The NRF network element sends the first token to the second entity, and the second entity receives the first token from the NRF network element.

[0153] For a detailed implementation, please refer to the description in step 304.

[0154] Subsequently, the second entity can request the first digital human model from the entity used to store the first digital human model (taking the first BAR network element as an example below) based on the first token. For details, please refer to the flowchart of the third communication method provided in Figure 5.

[0155] Step 501: The second entity sends the first token to the first BAR network element.

[0156] Correspondingly, the first BAR network element receives the first token from the second entity.

[0157] For example, the second entity sends a digital avatar representation download request to the first BAR network element, and the digital avatar representation download request includes the first token.

[0158] For example, the digital human model download request may also include the identifier of the first digital human and the identifier of the first terminal.

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

[0160] In scenario 1, the second entity is a proxy entity, that is, the second 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 the first terminal, the second terminal, or the MF network element. The digital human model request also carries the client credentials assertion (CCA) corresponding to the rendering entity. The specific verification method is described in step 502.

[0161] Case 2, the second entity is a rendered entity:

[0162] In scenario 2.1, the second entity is the first 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.

[0163] For example, after receiving a digital human model download request, the MF network element may also perform the following verification 1 and / or verification 2. It is understood that if the MF network element determines that either verification fails, the MF network element may choose not to forward the digital human model download request to the DC AS.

[0164] Verification 1: The MF network element verifies whether the digital human identifier in the first token is consistent with the digital human identifier previously verified by the DC AS (see the relevant embodiment in Figure 7);

[0165] Verification 2: The MF network element verifies whether the digital human identifier in the digital human model download request is consistent with the digital human identifier verified by the DC AS previously (see the relevant embodiment in Figure 7).

[0166] For ease of description, the following explanation will use verification 1 and verification 2 as examples. Here, the digital human identifier in the first token or the digital human model download request can be collectively referred to as the digital human identifier to be verified.

[0167] For example, an MF network element can perform check 1 and / or check 2 in the following manner:

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

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

[0170] In scenario 2.2, the second 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.

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

[0172] Case 2.3: The second 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.

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

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

[0175] Depending on whether the second entity is a proxy entity or a rendering entity, the following examples illustrate different cases:

[0176] In scenario 1, the second entity is a proxy entity, that is, the second 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 first token is the information of the DC AS, it confirms that the verification is successful.

[0177] Case 2, the second entity is a rendered entity:

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

[0179] The second entity is the first terminal. When the first 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 first terminal. After verifying that the subject in the first token is the information of the first terminal in the CCA, the first BAR network element determines that the verification is successful.

[0180] In scenario 2.2, when the second 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 first token is the information of the MF network element, it determines that the verification has passed.

[0181] The second 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 information about the MF network element. After verifying that the subject in the first token is the information of the MF network element in the CCA, the first BAR network element determines that the verification is successful.

[0182] In scenario 2.3, the second 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 confirms the identity of the second terminal by establishing TLS with the second terminal. Furthermore, after the first BAR network element determines that the information of the first entity in the first token is the information of the second terminal, it confirms that the verification has passed.

[0183] The second entity is the second terminal. 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 verifying that the subject in the first token is the information of the second terminal in the CCA, the first BAR network element determines that the verification is successful.

[0184] Furthermore, the first 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 first token, that it is the network element authorized by the first token 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 first token, that the entity sending the first token is the entity authorized by the first token to download the first digital human model, and based on the information included in the first token, that it is the network element authorized by the first token to provide the first digital human model, the verification is successful.

[0185] Step 503: The first BAR network element sends the first digital human model to the second entity.

[0186] For example, after determining that the verification has passed based on the first token, the first BAR network element sends the first digital human model to the second entity. For example, the first BAR network element sends a digital human model response to the second 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 first token, the first BAR network element sends a verification failure response to the second entity.

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

[0188] It should be added that the relevant embodiments in Figure 5 are illustrated 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 first 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 first token to download the first digital human model, but also needs to determine whether it is the BAR network element indicated by the first 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 first token to download the first digital human model and that it is the BAR network element indicated by the first 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. It can be understood that the relevant embodiments in Figure 5 can be executed by a third communication device, which can be the second BAR network element or a part of the second BAR network element (such as a chip).

[0189] Figure 6 is a schematic flowchart of a fourth communication method exemplarily provided in this application. This communication method can be executed by a first communication device, a second communication device, and a third communication device. The descriptions of the first, second, and third communication devices can be found in the relevant embodiments shown in Figures 3 to 5. The example given is that the third communication device is a first BAR network element.

[0190] Figure 6 highlights the NRF network element's verification of the second entity's identity, instructing the first BAR network element to provide the second entity with a first digital human model.

[0191] Step 601: The DC AS sends the information of the first entity to the NRF network element. Correspondingly, the NRF network element receives the information of the first entity from the DC AS. For a detailed implementation, please refer to the description in step 301.

[0192] Step 602: The second entity 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 entity. For example, the digital human model download request includes the identifier of the first digital human, and the digital human model download request is used by the second entity to request the download of the first digital human model. At this time, the digital human model download request does not include the first token.

[0193] Step 603: The first BAR network element sends an authentication request to the NRF network element, and correspondingly, the NRF network element receives the authentication request from the first BAR network element. The authentication request includes information about the second entity.

[0194] Step 604: The NRF network element sends an authentication response to the first BAR network element. The authentication response is used to indicate that the second entity is the first entity.

[0195] For example, after determining that the second entity is the first entity, the NRF network element sends a verification response to the first BAR network element. This verification response indicates that the second entity is the first entity (or, instructs the first BAR network element to provide the first digital human model to the second entity). Alternatively, after determining that the second entity is not the first entity, the NRF network element may also send a verification response to the first BAR network element, indicating that the second entity is not the first entity (or, instructing the first BAR network element not to provide the first digital human model to the second entity).

[0196] The method by which an NRF network element determines whether a second entity is the first entity can be found in the descriptions of steps 301 and 302.

[0197] Furthermore, when the DC AS sends information about the entity storing the first digital human model to the NRF network element, the NRF network element, upon receiving the verification request, can also determine whether the first BAR network element is the entity storing the first digital human model based on the identifier of the first BAR network element in the verification request (i.e., the information of the entity sending the verification request). Further, when the NRF network element determines that the first BAR network element is the entity storing the first digital human model, and the second entity is the first entity, it sends a verification response to the first BAR network element. The verification response instructs the first BAR network element to provide the first digital human model to the second entity. The method by which the NRF network element determines whether the entity sending the verification request is the entity storing the first digital human model can be found in the descriptions of steps 301 and 302.

[0198] Step 605: The first BAR network element sends the first digital human model to the second entity.

[0199] Furthermore, when the second entity is a rendering entity, the second entity generates a digital human based on the first digital human model; when the second entity is a proxy entity of the rendering entity, the second 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.

[0200] Figure 7 is a schematic flowchart of the fifth communication method provided by this application. This communication method is specifically a way in which a second communication device determines information about a first entity. The second communication device can be a DC AS related to a call, or a part of a DC AS related to a call (e.g., a chip). For ease of description, the following description uses a DC AS as an example of a second communication device.

[0201] Furthermore, a first ADC is established between the first terminal and the DC AS, and the first ADC is used for rendering negotiation. Specifically, 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. 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 transmitted in the first ADC; that is, the message is transparently transmitted within the MF network element.

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

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

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

[0205] 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 the digital human's communication. Rendering data types include, for example, text, language, and actions.

[0206] The capability negotiation request carries the identifier (avatar ID) of the first digital human. For example, the capability negotiation request may also carry negotiation parameters of the first terminal. For example, the negotiation parameters of 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.

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

[0208] (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.

[0209] (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.

[0210] (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.

[0211] (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.

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

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

[0214] Optionally, after step 701, one or more of the following steps A, B, and C may be included:

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

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

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

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

[0219] 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".

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

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

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

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

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

[0225] 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 701. 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 701.

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

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

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

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

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

[0231] 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:

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

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

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

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

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

[0237] Using 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 as examples, the first entity determined by the DC AS is illustrated.

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

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

[0240] Table 1

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

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

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

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

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

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

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

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

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

[0250] 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 with the DC AS based on the original MF network element; the second ADC is described in the following embodiments). 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.

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

[0252] In another implementation, when the 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 determined network element information (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 preset rendering requirements.

[0253] Alternatively, when an NRF network element determines, based on preset rendering requirements, 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 no network element in the current network that can meet the preset rendering requirements.

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

[0255] For example, an NRF network element stores information about a first entity.

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

[0257] 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".

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

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

[0260] 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 both the information of the first entity and the information of the first BAR network element, both the information of the first entity and the information of the first BAR network element can be considered as rendering negotiation parameters or rendering negotiation results.

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

[0262] 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".

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

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

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

[0266] 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 subsequent sending of the first entity's information and / or the first BAR network element's information to the NRF network element, as well as subsequent rendering processes, which helps to save message transmission resources.

[0267] 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 identifier of the first digital human does not need to be carried again in the second token sent by the first terminal in the future.

[0268] After step 701, the DC AS sends the information of the first entity to the NEF network element (or NRF network element), or sends the information of the first entity and the information of the entity used to store the first digital human model, equivalent to step 301 or step 601 above; or, after step 701, the DC AS may send the information of the first entity to the HSS network element (or ROF network element), or send the information of the first entity and the information of the entity used to store the first digital human model, equivalent to step 401 above.

[0269] Optional, also includes:

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

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

[0272] For example, the capability negotiation response includes information about the first entity. For example, the capability negotiation response may also be referred to as a negotiation response, rendering negotiation response, driving negotiation response, animation negotiation response, etc.

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

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

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

[0276] In another example, if the second terminal acts as the rendering entity, and the user information and the second token are forwarded by the MF network element, the second 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 second 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.

[0277] Optional, also includes:

[0278] Step 703: The first terminal generates the second token.

[0279] For example, the second token includes information about the first entity. For example, the second token may also carry the identifier of the first digital human.

[0280] 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 second token may also include the information about the entity used to store the first digital human model.

[0281] Optional, also includes:

[0282] Step 704: The first terminal sends the second token.

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

[0284] It is understood that steps 701 to 703 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.).

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

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

[0287] Based on the premise that the first entity is an MF network element, DC AS, a second terminal, or a first terminal, the method by which the first entity obtains the second token is illustrated. Furthermore, the first entity may request the first token from an NRF network element (or NEF network element) based on the second token.

[0288] 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 second token.

[0289] It should be noted that after receiving the media resource reservation message, the MF network element can also perform verification 1 and / or verification 2: Verification 1, the MF network element verifies whether the digital human identifier in the second token is consistent with the digital human identifier previously verified by DC AS; 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 previously verified by DC AS.

[0290] For an explanation of verification 1 and / or verification 2, please refer to the description in step 501 above.

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

[0292] 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 second token. After obtaining the second 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 second token to the DC AS.

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

[0294] When the first entity is the first terminal, the first terminal can directly save the second token without sending it (that is, step 704 is an optional step).

[0295] For example, steps 701 to 703 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 can involve negotiating who will perform the rendering during the digital human rendering process and what data type will be used for rendering. For example, step 704 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 in the rendering process, and the first terminal can send a second token based on the re-invitation message requesting the establishment of the second ADC.

[0296] Referring to the descriptions in the embodiments of Figures 3, 5, and 7 above, and as shown in Figure 8, which is a flowchart illustrating the sixth communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining information about a first entity based on first configuration information. Both the first entity and the second entity are MF network elements. The DC AS sends the information of the first entity to the NRF network element. Further, the MF network element requests a first token from the NRF network element, requests a first digital human model from the first BAR network element based on the first token, and generates a first digital human based on the first digital human model.

[0297] In Figure 8, “NRF network element” can also be replaced with “NEF network element”.

[0298] 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 bootstrap data channel (BDC) between the first terminal and the DC AS.

[0299] 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 701.

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

[0301] Step 804: 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 804, please refer to the descriptions in steps A and B.

[0302] In step 805, the DC AS sends information about the first entity (i.e., the information about the MF network element) and the information about the first BAR network element to the NRF network element. Correspondingly, the NRF network element receives the information about the first entity (i.e., the information about the MF network element) and the information about the first BAR network element from the DC AS. The specific implementation of step 805 can be found in the description of step 301.

[0303] Step 806: The NRF network element sends a receive response to the DC AS. Correspondingly, the DC AS receives the receive response from the NRF network element. For a detailed description of step 806, please refer to step 301.

[0304] Step 807: The MF network element sends a token request to the NRF network element. Correspondingly, the NRF network element receives the token request from the MF network element. The specific implementation of step 807 can be found in the description of step 302.

[0305] Step 808: The NRF network element determines that the MF network element is the first entity. For a detailed description of step 808, please refer to step 303.

[0306] In step 809, the NRF network element generates a first token and sends the first token to the MF network element. Correspondingly, the MF network element receives the first token from the NRF network element. For a detailed implementation of step 809, please refer to the descriptions in steps 303 and 304.

[0307] Step 810: The MF network element sends a digital human model download request to the first BAR network element. Correspondingly, the first BAR network element receives the digital human model download request from the MF network element. The digital human model download request includes the identifier of the first terminal, the first token, and the identifier of the first digital human. For a detailed implementation of step 810, please refer to the description in step 501.

[0308] Step 811: 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 811, please refer to the description in step 503. For example, before step 811, the first BAR network element may also determine that the verification is successful after determining that the subject field in the first token is information from the MF network element and the audience field is information from the first BAR network element; for details, please refer to the description in step 502.

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

[0310] In the relevant embodiments shown in Figure 8, steps 802 to 806 belong to the rendering capability negotiation process, steps 807 and 809 belong to the second ADC establishment process, and steps 810 to 812 belong to the digital human rendering process. It is understood that Figure 8 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.

[0311] It should be added that steps 807 to 809 can be after the first terminal sends the re-invite message and before the second ADC is established; in addition, in another possible way, steps 807 to 809 can also be after the second ADC is established. For example, steps 807 to 809 belong to the digital human rendering process and can be located before step 810.

[0312] Referring to the descriptions in the embodiments of Figures 3, 5, and 7 above, and as shown in Figure 9, which is a flowchart illustrating the seventh communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining the information of a first entity based on first configuration information. Both the first entity and the second entity are proxy entities (i.e., the DC AS), and the rendering entity is the first terminal. The DC AS sends the information of the first entity to the NRF network element. Further, the DC AS requests a first token from the NRF network element, requests a first digital human model from the first BAR network element based on the first token, and sends the first digital human model to the first terminal. The first terminal then generates a first digital human based on the first digital human model.

[0313] In Figure 9, "first terminal" can also be replaced with "second terminal". In Figure 9, "NRF network element" can also be replaced with "NEF network element".

[0314] Step 901: 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 901, the method further includes: establishing a BDC between the first terminal and the DC AS.

[0315] Step 902: 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 902 can be found in the description of step 701.

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

[0317] Step 904: 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 DC AS, such as the DC AS's identifier. 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 904, please refer to the descriptions in steps A and B.

[0318] In step 905, the DC AS sends the information of the first entity (i.e., the information of the DC AS) and the information of the first BAR network element to the NRF network element. Correspondingly, the NRF network element receives the information of the first entity (i.e., the information of the DC AS) and the information of the first BAR network element from the DC AS. The specific implementation of step 905 can be found in the description of step 301.

[0319] Step 906: The NRF network element sends a receive response to the DC AS. Correspondingly, the DC AS receives the receive response from the NRF network element. For a detailed description of step 906, please refer to step 301.

[0320] Step 907: The DC AS sends a token request to the NRF network element. Correspondingly, the NRF network element receives the token request from the DC AS. The specific implementation of step 907 can be found in the description of step 302.

[0321] Step 908: The NRF network element determines that the DC AS is the first entity. For a detailed description of step 908, please refer to step 303.

[0322] In step 909, the NRF network element generates a first token and sends the first token to the DC AS. Correspondingly, the DC AS receives the first token from the NRF network element. For a detailed implementation of step 909, please refer to the descriptions in steps 303 and 304.

[0323] Step 910: The DC AS 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 DC AS. The digital human model download request includes the identifier of the first terminal, the first token, and the identifier of the first digital human. For a detailed implementation of step 910, please refer to the description in step 501.

[0324] Step 911: The first BAR network element sends a digital human model response to the DC AS. Correspondingly, the DC AS 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 911, please refer to the description in step 503. For example, before step 911, the first BAR network element may also determine that the verification is successful after determining that the subject field in the first token is information from the DC AS and the audience field is information from the first BAR network element; for a detailed implementation, please refer to the description in step 502.

[0325] Step 912: The DC AS sends the first digital human model to the first terminal. For example, the DC AS sends the first digital human model to the first terminal via a second ADC.

[0326] Step 913: The first terminal generates the first digital human based on the first digital human model.

[0327] In the relevant embodiments shown in Figure 9, steps 902 to 906 belong to the rendering capability negotiation process, steps 907 and 909 belong to the second ADC establishment process, and steps 910 to 912 belong to the digital human rendering process. It is understood that Figure 9 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.

[0328] It should be added that steps 907 to 909 can be after the first terminal sends the re-invite message and before the second ADC is established; in addition, in another possible way, steps 907 to 909 can also be after the second ADC is established. For example, steps 907 to 909 belong to the digital human rendering process and can be located before step 910.

[0329] Referring to the descriptions in the embodiments of Figures 4, 5, and 7 above, and as shown in Figure 10, which is a flowchart illustrating the eighth communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining information about a first entity based on first configuration information. Both the first entity and the second entity are MF network elements. The DC AS sends the information of the first entity to the HSS network element. Further, the MF network element requests a first token from the NRF network element, requests a first digital human model from the first BAR network element based on the first token, and generates a first digital human based on the first digital human model.

[0330] In Figure 10, “NRF network element” can also be replaced with “NEF network element”. In Figure 10, “HSS network element” can also be replaced with “ROF network element”.

[0331] Steps 1001 to 1004 correspond to steps 801 to 804 above, and will not be repeated here.

[0332] In step 1005, the DC AS sends information about the first entity (i.e., information about the MF network element) and information about the first BAR network element to the HSS network element. Correspondingly, the HSS network element receives the information about the first entity (i.e., information about the MF network element) and information about the first BAR network element from the DC AS. The specific implementation of step 1005 can be found in the description of step 301.

[0333] Step 1006: The HSS network element sends a receive response to the DC AS. Correspondingly, the DC AS receives the receive response from the HSS network element. For a detailed description of step 1006, please refer to step 301.

[0334] Step 1007: The MF network element sends a token request to the NRF network element. Correspondingly, the NRF network element receives the token request from the MF network element. The specific implementation of step 1007 can be found in the description of step 302.

[0335] Step 1008: The NRF network element sends an authorization request to the HSS network element, and the HSS network element receives the authorization request from the NRF network element.

[0336] In step 1009, if the HSS network element determines that the second entity is the first entity, it sends an authorization response to the NRF network element. Correspondingly, the NRF network element receives the authorization response from the HSS network element. This authorization response can be used to indicate that the second entity is the first entity.

[0337] Step 1010: The NRF network element determines that the MF network element is the first entity. For a detailed description of step 1010, please refer to step 303.

[0338] In step 1011, the NRF network element generates a first token and sends the first token to the MF network element. Correspondingly, the MF network element receives the first token from the NRF network element. The specific implementation of step 1011 can be found in the descriptions of steps 303 and 304.

[0339] Steps 1012 to 1014 correspond to steps 810 to 812 above, and will not be repeated here.

[0340] In the relevant embodiments shown in Figure 10, steps 1002 to 1006 belong to the rendering capability negotiation process, steps 1007 and 1011 belong to the second ADC establishment process, and steps 1012 to 1014 belong to the digital human rendering process. Figure 10 only illustrates the steps related to this application. 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.

[0341] It should be added that steps 1007 to 1011 can be after the first terminal sends the re-invite message and before the second ADC is established; in addition, in another possible way, steps 1007 to 1011 can also be after the second ADC is established. For example, steps 1007 to 1011 belong to the digital human rendering process and can be located before step 1012.

[0342] Furthermore, in the relevant embodiments of Figure 10, the first entity can also be a DC AS. The DC AS acts as a proxy entity to request the first digital human model from the first BAR network element on behalf of the first terminal or the second terminal. This can be obtained by referring to Figures 9 and 10, and will not be described in detail here.

[0343] Referring to the descriptions in the embodiments of Figures 3, 5, and 7 above, and as shown in Figure 11, which is a flowchart illustrating the ninth communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining information about a 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. Both the first and second entities are MF network elements. The DC AS then sends the information of the first entity to the NRF network element. Further, the MF network element requests a first token from the NRF network element, requests a first digital human model from the first BAR network element based on the first token, and generates a first digital human based on the first digital human model.

[0344] Steps 1101 to 1103 correspond to steps 801 to 803 respectively, and will not be described again.

[0345] Step 1104: 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 1104, please refer to the description in step A.

[0346] Step 1105: 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 1105, please refer to the description in step A.

[0347] Step 1106: 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 1106, please refer to the description in step A.

[0348] Step 1107: 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 1107, please refer to the description in step A.

[0349] In step 1108, 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 1108, please refer to the descriptions in steps A and B.

[0350] Steps 1109 to 1116 correspond to steps 805 to 812 respectively, and will not be described again.

[0351] Referring to the descriptions in the embodiments of Figures 3, 5, and 7 above, and as illustrated in Figure 12, which is a flowchart of the tenth 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 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. Correspondingly, the NRF network element determines and stores the information of the first entity. The first entity is a new MF network element (i.e., the second MF network element). The second MF network element requests a first token from the NRF network element, requests a first digital human model from the first BAR network element based on the first token, and generates a first digital human based on the first digital human model.

[0352] Steps 1201 to 1207 correspond to steps 1101 to 1107 respectively, and will not be described again.

[0353] In step 1208, 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 1208, please refer to the descriptions in steps A and B.

[0354] Step 1209: 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.

[0355] For a detailed description of step 1209, please refer to step A.

[0356] In step 1210, 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). Optionally, the NRF network element also stores the information about the first entity.

[0357] In a specific example, the NRF network element determines the information of the second MF network element according to the preset rendering requirements and sends the first response to the DC AS.

[0358] Specifically, the information of the second MF network element is used by the DC AS to update the MF network element, so that the first terminal can establish a second ADC based on the second MF network element and the DC AS. For example, the DC AS can also send the information of the second MF network element to the DCSF network element, and this information is used by the DCSF network element to update the MF network element, so that the first terminal can establish a second ADC based on the second MF network element and the DC AS.

[0359] For a detailed description of step 1210, please refer to step A.

[0360] Following step 1210, the process may further include steps 1211 to 1218. Steps 1211 to 1218 correspond to steps 1109 to 1116, respectively, except that the first MF element is replaced by the second MF element. Steps 1208 to 1210 pertain to the rendering capability negotiation process. It is understood that Figure 12 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.

[0361] Referring to the descriptions in the embodiments of Figures 3, 5, and 7 above, and Figure 13 being a flowchart illustrating the eleventh communication method exemplarily provided in this application, this communication method specifically involves the DC AS determining information about a first entity based on first configuration information. Both the first and second entities are proxy entities (i.e., the DC AS), and the rendering entity is the first terminal. The DC AS sends the information of the first entity to the NRF network element. Further, the DC AS receives a second token from the first terminal, requests a first token from the NRF network element based on the second token, and then requests a first digital human model from the first BAR network element based on the first token. The DC AS then sends the first digital human model to the first terminal, and the first terminal generates a first digital human based on the first digital human model.

[0362] In Figure 13, "first terminal" can also be replaced with "second terminal" or "MF network element". In Figure 13, "NRF network element" can also be replaced with "NEF network element".

[0363] Steps 1301 to 1306 correspond to steps 901 to 906 respectively, and will not be described again.

[0364] In step 1307, the first terminal sends a re-invitation message to the DCSF. Correspondingly, the DCSF receives the re-invitation message from the first terminal. The re-invitation message includes a second token and the identifier of the first digital human. For example, the issuer field in the second token is the identifier of the first terminal. The specific implementation of step 1307 can be found in the description of step 304. For example, prior to step 1307, the first terminal also generates a second token; the specific implementation of this can be found in the description of step 304.

[0365] In step 1308, DCSF sends a get avatar animation information request to DC AS, and correspondingly, DC AS receives the get avatar animation information request from DCSF. The get avatar animation information request includes a second token and a first digital identifier.

[0366] Step 1309: DC AS sends a token request to the NRF network element. The token request includes a second token and the identifier of the first digital human.

[0367] In step 1310, the NRF network element generates a first token based on the second token and sends the first token to the DC AS. For a detailed implementation of step 1310, please refer to the description in step 304.

[0368] After step 1310, steps 1311 to 1314 may also be included.

[0369] Steps 1311 to 1314 correspond to steps 910 to 913, respectively. Steps 1307 to 1310 belong to the second ADC establishment process. It is understood that Figure 13 only illustrates the steps relevant to this application. 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.

[0370] 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. The first terminal can carry the information of the first entity in the capability negotiation request or directly send the information of the first entity to the NRF network element. 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 NRF network element. 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 it. The other network element then determines the information of the first entity and forwards it to the NRF network element through the DC AS, or the other network element directly sends the information of the first entity to the NRF network element. Here, the NRF network element can also be replaced by a NEF network element, an HSS network element, or a ROF network element.

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

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

[0373] Based on the above content and the same concept, Figures 14 and 15 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 an NRF network element (or a module (e.g., a chip) in any of Figures 2A to 2C, or the communication device can be a NEF network element (or a module (e.g., a chip) in any of Figures 2A to 2C), or it can also be a DC AS (or a module (e.g., a chip) in Figure 2C).

[0374] As shown in Figure 14, the communication device 1400 includes a processing module 1401 and a transceiver module 1402.

[0375] When the communication device 1400 is used to implement the function of the first communication device in the method embodiment of FIG3 above:

[0376] The transceiver module 1402 is used to receive information from a first entity from the DC AS. The first entity is an entity determined by the DC AS after receiving the capability negotiation request and is used to download the digital human model. The DC AS is related to the call.

[0377] The transceiver module 1402 is also used to receive token requests, which carry information about the second entity and the identifier of the digital human.

[0378] Processing module 1401 is used to generate a first token when it is determined that the second entity is the first entity;

[0379] The transceiver module 1402 is also used to send a first token, which is used to authorize the second entity to download the digital human model, and the digital human model is used for rendering the digital human.

[0380] In one possible implementation, the transceiver module 1402 is further configured to receive information from the DC AS for storing the entity of the digital human model, wherein the first token includes the information for storing the entity of the digital human model.

[0381] In one possible implementation, the token request also carries a second token, which is generated by the first terminal; when generating the first token, the processing module 1401 is specifically used to generate the first token based on the information of the first entity and the second token.

[0382] When the communication device 1400 is used to implement the function of the first communication device in the method embodiment of FIG6 above:

[0383] The transceiver module 1402 is used to receive information from a first entity from the DC AS. The first entity is an entity determined by the DC AS after receiving the capability negotiation request and is used to download the digital human model. The DC AS is related to the call.

[0384] The transceiver module 1402 is also used to receive a verification request from the BAR network element. The verification request includes information about the second entity. The verification request is sent by the BAR network element after receiving the digital human model download request from the second entity. The digital human model download request is used by the second entity to request the download of the digital human model.

[0385] The transceiver module 1402 is also used to send a verification response to the BAR network element when the processing module 1401 determines that the second entity is the first entity. The verification response is used to indicate that the second entity is the first entity.

[0386] When the communication device 1400 is used to implement the function of the second communication device in the above method embodiment:

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

[0388] Processing module 1401 is used to determine the information of the first entity, which is the entity used to download the digital human model, and the digital human model is used for rendering the digital human.

[0389] The transceiver module 1402 is also used to send information about the first entity.

[0390] In one possible implementation, the transceiver module 1402 is also configured to send information about the entity used to store the digital human model, based on the digital human's identifier.

[0391] In one possible implementation, the transceiver module 1402 is further configured to send a token request, which includes information about the second entity and the identifier of the digital human; and, if the second entity is the first entity, to receive a first token, which is used to authorize the second entity to download the digital human model.

[0392] In one possible implementation, the token request also includes a second token, which is generated by the first terminal, and the first token is generated based on the second token and information from the first entity.

[0393] In one possible implementation, when the DC AS is located inside the IMS network, the transceiver module 1402, when sending the information of the first entity, is specifically used to send the information of the first entity to the NRF network element; when the DC AS is located outside the IMS network, the transceiver module 1402, when sending the information of the first entity, is specifically used to send the information of the first entity to the NEF network element or the NRF network element; or, the transceiver module 1402, when sending the information of the first entity, is specifically used to send the information of the first entity to the HSS network element or the ROF network element.

[0394] 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 element related to the call, the first terminal, and the second terminal; when determining the information of the first entity, the processing module 1401 is specifically used to determine the information of the first entity based on the negotiation parameters of the first terminal. In another possible implementation, when determining the information of the first entity based on the negotiation parameters of the first terminal, the processing module 1401 is specifically used to obtain the negotiation parameters of the MF network element and the negotiation parameters of the second terminal; and 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.

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

[0396] In one possible implementation, the capability negotiation request is information received from the first terminal by the second communication device via the first ADC; wherein the first ADC is the channel between the first terminal and the second communication device.

[0397] Figure 15 shows a device 1500 provided in an embodiment of this application. The device shown in Figure 15 can be a hardware circuit implementation of the device shown in Figure 10. This device 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 15 only shows the main components of the device.

[0398] The device 1500 shown in Figure 15 includes a communication interface 1510, a processor 1520, and a memory 1530, wherein the memory 1530 is used to store program instructions and / or data. The processor 1520 may operate in conjunction with the memory 1530. The processor 1520 may execute the program instructions stored in the memory 1530. When the instructions or program stored in the memory 1530 are executed, the processor 1520 is used to perform the operations performed by the processing module 1401 in the above embodiments, and the communication interface 1510 is used to perform the operations performed by the transceiver module 1402 in the above embodiments.

[0399] The memory 1530 and the processor 1520 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 1530 may be included in the processor 1520.

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

[0401] Device 1500 may also include a communication line 1540. The communication interface 1510, processor 1520, and memory 1530 can be interconnected via the communication line 1540. The communication line 1540 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication line 1540 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 15, but this does not indicate that there is only one bus or one type of bus.

[0402] Based on the above content and the same concept, this application also provides a computer-readable storage medium storing a computer program or instructions. When the computer program or instructions are executed by a communication device, they implement the method executed by the NRF network element in the above method embodiments, or the method executed by the DC AS in the above method embodiments.

[0403] 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 NRF network element in the above method embodiments, or implement the method executed by the DC AS in the above method embodiments.

[0404] 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 NRF network element in the above method embodiment, and the second communication device implements the method executed by the DC AS in the above method embodiment.

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

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

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

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

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

[0410] 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 receives information from a first entity from a data channel application server. The first entity is an entity determined by the data channel application server after receiving a capability negotiation request, used for downloading a digital human model. The data channel application server is associated with the call. The first communication device receives a token request, which carries information about the second entity and the identifier of the digital human. The first communication device generates a first token when it determines that the second entity is the first entity; The first communication device sends the first token, which is used to authorize the second entity to download the digital human model, and the digital human model is used for rendering the digital human.

2. The method as described in claim 1, characterized in that, When the data channel application server is located within the Internet Protocol Multimedia Subsystem (IMS) network, the first communication device is a network storage function network element, or a part of the network storage function network element. When the data channel application server is located outside the IMS network, the first communication device is a network storage function network element, or a part of the network storage function network element; or, the first communication device is a network open function network element, or a part of the network open function network element.

3. The method as described in claim 1 or 2, characterized in that, The first token includes information about the first entity and the identifier of the digital human.

4. The method according to any one of claims 1-3, characterized in that, Also includes: The first communication device receives information from the data channel application server regarding the entity used to store the digital human model, and the first token includes the information regarding 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 token request also carries a second token, which is generated by the first terminal; The first communication device generates a first token, including: The first communication device generates the first token based on the information of the first entity and the second token.

7. 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 first communication device receives information from a first entity from a data channel application server. The first entity is an entity determined by the data channel application server after receiving a capability negotiation request, used for downloading a digital human model. The data channel application server is associated with the call. The first communication device receives a verification request from a basic digital human repository network element. The verification request includes information about a second entity. The verification request is sent by the basic digital human repository network element after receiving a digital human model download request from the second entity. The digital human model download request is used by the second entity to request the download of the digital human model. The first communication device sends a verification response to the basic digital human repository network element, the verification response being used to indicate that the second entity is the first entity.

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 determines information about the first entity, which is an entity used to download a digital human model, the digital human model being used for rendering the digital human; The second communication device sends information about the first entity; The second communication device is a data channel application server or a part of the data channel application server related to the call.

9. The method as described in claim 8, characterized in that, Also includes: The second communication device sends information about the entity storing the digital human model based on the digital human's identifier.

10. The method as described in claim 8 or 9, characterized in that, Also includes: The second communication device sends a token request, which includes information about the second entity and the identifier of the digital human; If the second entity is the first entity, the second communication device receives a first token, which is used to authorize the second entity to download the digital human model.

11. The method as described in claim 10, characterized in that, The token request also includes a second token, which is generated by the first terminal. The first token is generated based on the second token and the information of the first entity.

12. The method according to any one of claims 8-11, characterized in that, The second communication device sends information about the first entity, including: When the data channel application server is located inside the IMS network, the second communication device sends the information of the first entity to the network storage function element; when the data channel application server is located outside the IMS network, the second communication device sends the information of the first entity to the network open function element or the network storage function element; or... The second communication device sends the information of the first entity to the home user server network element or the resource-all-function network element.

13. The method according to any one of claims 8-12, 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; The second communication device determines information about the first entity, including: The second communication device determines the information of the first entity based on the negotiation parameters of the first terminal.

14. The method as described in claim 13, 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.

15. The method according to any one of claims 8-14, 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.

16. The method as described in claim 14, 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.

17. The method according to any one of claims 8-16, 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.

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

19. A communication device, characterized in that, The device includes a processor and an interface circuit. 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 6 through logic circuits or executable code instructions, or the processor implements the method as described in claim 7 through logic circuits or executable code instructions, or the processor implements the method as described in any one of claims 8 to 17 through logic circuits or executable code instructions.

20. 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 6, or the method as described in claim 7, or the method as described in any one of claims 8 to 17.

21. 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 6, or implement the method as described in claim 7, or implement the method as described in any one of claims 8 to 17.

22. 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 6; The second communication device is used to implement the method as described in any one of claims 8 to 17; or, the first communication device is used to implement the method as described in claim 7; and the second communication device is used to implement the method as described in any one of claims 8 to 17.

Images