Communication method and device

Abstract

A communication method and device are used for guaranteeing the security of a digital human model. The method is applied to a scene in which a first terminal and a second terminal carry out a digital human related call, and comprises the following steps: an NRF receives information of a first entity from a DC AS, the first entity is an entity determined by the DC AS after receiving a capability negotiation request and used for downloading a first digital human model, and the DC AS is related to the call; the NRF receives a token request, wherein the token request carries information of a second entity and an identifier of the first digital person; the NRF generates a first token when determining that the second entity is the first entity; and the NRF sends a first token, the first token is used for authorizing a second entity to download a first digital human model, and the first digital human model is used for rendering of a digital human.

Description

Technical Field

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

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

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

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

[0005] In a first aspect, the present application provides a communication method, which can be executed by a first communication device. The first communication device can be a network repository function (NRF) network element, or a part of the NRF network element (such as a chip in the NRF network element). The first communication device can also be a network exposure function (NEF) network element, or a part of the NEF network element (such as a chip in the NEF network element).

[0006] When the first communication device is an NRF network element, for example, the first communication device may receive information from a data channel application server (DC AS). When the first communication device is a module in the NRF network element, the first communication device may receive information from other modules (such as a radio frequency module or an antenna), for example, the information is sent by the DC AS to the NRF network element. When the first communication device is a NEF network element, for example, the first communication device may receive information from the DC AS. When the first communication device is a module in the NEF network element, the first communication device may receive information from other modules (such as a radio frequency module or an antenna), for example, the information is sent by the DC AS to the NEF network element.

[0007] The method is applied to the scenario where a first terminal and a second terminal conduct a digital human-related call. The method includes: the first communication device receives information of a first entity from the DC AS, where the first entity is an entity determined by the DC AS after receiving a capability negotiation request and is used to download a first digital human model, and the DC AS is related to the call; the first communication device receives a token request, and the token request carries information of a second entity and an identifier of the first digital human; the first communication device generates a first token when determining that the second entity is the first entity; the first communication device sends the first token, and the first token is used to authorize the second entity to download the first digital human model, and the first digital human model is used for the rendering of the first digital human.

[0008] In the above technical solution, when the first communication device receives the token request, if it determines that the second entity sending the token request is the first entity (that is, the entity capable of downloading the first digital human model), it issues the first token to the second entity. Compared with the first communication device generating the first token based on coarse-grained information, for example, generating the first token for all entities that may use the first token (such as entities of terminal type, MF entity type, and DC AS type), in this application, the first communication device generates the first token based on fine-grained information. The first token is used for the first entity (or the second entity) to download the first digital human model and cannot be used for other entities to download the first digital human model, avoiding the abuse of the permission to download the first digital human model and improving security. Thus, 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 according to the first token and provide the first digital human model to the second entity. By the first communication device issuing the first token, the security in the process of requesting the digital human model is improved.

[0009] Further, 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.

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

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

[0012] In the above technical solution, the first token carries the information of the first entity and the identifier of the first digital human. Equivalently, the first entity is 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 during the process of requesting the first digital human model.

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

[0014] In the above technical solution, the first communication device carries the information of the entity for storing the first digital human model (such as the identifier of the first BAR network element) in the first token. When the second BAR network element receives a request from a second entity to download the first digital human model, the second BAR network element can determine whether the information of the entity for storing the first digital human model in the first token is the information of the second BAR network element, and then determine whether to provide the first digital human model to the second entity. Exemplarily, when the second BAR network element determines that the information of the entity for storing the first digital human model included in the first token is the same as the information of the second BAR network element (that is, the above first BAR and the second BAR are the same BAR), the second BAR network element provides the first digital human model to the second entity; when the second BAR network element determines that the information of the entity for storing the first digital human model included in the first token is different from the information of the second BAR network element (that is, the above first BAR and the second BAR are different BARs), the second BAR network element does not provide the first digital human model to the second entity. In this way, it helps to further ensure the security of the first digital human model in the BAR network element.

[0015] Further, compared with the first communication device generating the first token based on coarse-grained information (such as information of all entities that may provide the first digital human model), the first communication device generates the first token based on fine-grained information (such as information of the first BAR network element). This first token is used for the second entity to request the first digital human model from the first BAR, and cannot be used for 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. The authorization regarding the first digital human model is more accurate, avoiding the abuse of the permission to provide the first digital human model and further ensuring security.

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

[0017] In a possible implementation manner, the token request also carries a second token, which is generated by the first terminal. When the first communication device generates the first token, specifically, the first communication device generates the first token according to the information of the first entity and the second token.

[0018] In a second aspect, the present 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 the NRF network element (such as a chip in the NRF network element). The first communication device can also be an NEF network element, or a part of the NEF network element (such as a chip in the NEF network element).

[0019] When the first communication device is an NRF network element, for example, the first communication device can receive information from the DC AS. When the first communication device is a module in the NRF network element, the first communication device can receive information from other modules (such as a radio frequency module or an antenna), for example, this information is sent by the DC AS to the NRF network element. When the first communication device is an NEF network element, for example, the first communication device can receive information from the DC AS. When the first communication device is a module in the NEF network element, the first communication device can receive information from other modules (such as a radio frequency module or an antenna), for example, this information is sent by the DC AS to the NEF network element.

[0020] The method is applied to the scenario of a digital human-related call between a first terminal and a second terminal. The method includes: a first communication device receives information of a first entity from a DC AS, where the first entity is an entity determined by the DC AS after receiving a capability negotiation request and is used to download a first digital human model, and the DC AS is related to the call; the first communication device receives a verification request from a BAR network element, where the verification request includes information of a second entity, and the verification request is sent by the BAR network element after receiving a digital human model download request of the second entity, and the digital human model download request is used for the second entity to request to download the first digital human model; the first communication device sends a verification response to the BAR network element, and the verification response is used to indicate that the second entity is the first entity. Exemplarily, based on the verification response, the BAR network element sends the first digital human model to the second entity.

[0021] In the above technical solution, after receiving the digital human model download request of 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 (that is, the entity that downloads the first digital human model). If so, providing the first digital human model to the second entity helps to improve the security during the process of requesting the first digital human model. Further, 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.

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

[0023] When the second communication device is a DC AS, for example, the second communication device can send information to 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 a radio frequency module or an antenna). For example, the information is sent by the DC AS to the NRF network element, or the second communication device can receive information from other modules, and the information is sent by the first terminal to the DC AS.

[0024] The method is applied to the scenario of a digital human-related call between a first terminal and a second terminal. The method includes: the second communication device receives a capability negotiation request, where the capability negotiation request carries an identifier of a first digital human, and the capability negotiation request is used to negotiate the rendering of the first digital human; the second communication device determines information of a first entity, where the first entity is an entity used to download a first digital human model, and the first digital human model is used for the rendering of the first digital human; the second communication device sends the information of the first entity; the second communication device is a DC AS or a part of the DC AS related to the call.

[0025] In a possible implementation, the second communication device also sends information about the entity for storing the first digital human model according to the identifier of the first digital human. The information about the entity for storing the first digital human model is, for example, the identifier of the first BAR network element.

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

[0027] In a possible implementation, the token request also includes a second token generated by the first terminal, and the first token is generated according to the second token and the information about the first entity. Exemplarily, the second communication device also receives the second token from the first terminal.

[0028] In a possible implementation, when the DC AS is inside the IMS network, the second communication device sends the information about the first entity. Specifically, the second communication device sends the information about the first entity to the NRF network element. When the DC AS is outside the IMS network, the second communication device sends the information about the first entity. Specifically, the second communication device sends the information about the first entity to the NEF network element or the NRF network element. Alternatively, when the second communication device sends the information about the first entity, specifically, the second communication device sends the information about the first entity to the home subscriber server (HSS) network element or the resource owner function (ROF) network element.

[0029] In a possible implementation, the negotiation parameters of the first terminal are carried in the capability negotiation request. The negotiation parameters of the first terminal include the rendering capability of the first terminal and / or the candidate entities recommended by the first terminal. The candidate entities include one or more of the MF network element related to the call, the first terminal, and the second terminal. When the second communication device determines the information about the first entity, specifically, the second communication device determines the information about the first entity according to the negotiation parameters of the first terminal. Exemplarily, when the second communication device determines the information about the first entity according to the negotiation parameters of the first terminal, specifically, the second communication device obtains the negotiation parameters of the MF network element and the negotiation parameters of the second terminal. The second communication device determines the information about the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal.

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

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

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

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

[0034] (3) The remaining computing resources of the first terminal, where the remaining computing resources of the first terminal include one or more of 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.

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

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

[0037] In a 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 do not meet the preset rendering requirements, the second communication device may also send a first request to the NRF network element. The first request includes the preset rendering requirements, and the first request is used to request a first entity that meets the preset rendering requirements. The second communication device receives a first response from the NRF network element, and the first response 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 do not meet the preset rendering requirements, the DC AS can also request information about the first entity from the NRF network element to ensure the normal progress of the rendering process.

[0038] In a possible implementation, the capability negotiation request is information received by the second communication device from the first terminal through the first application data channel (ADC); where the first ADC is a channel between the first terminal and the second communication device.

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

[0040] In a fourth aspect, an embodiment of the present application provides a communication device. The communication device has the functions of the first communication device in the first aspect or any possible implementation manner of the first aspect described above. The communication device may also have the functions of the first communication device in the second aspect or any possible implementation manner of the second aspect described above. The communication device may also have the functions of the second communication device in the third aspect or any possible implementation manner of the third aspect described above. The functions of the above communication device may be implemented by hardware or by hardware executing corresponding software, and the hardware or software includes one or more modules, units, or means corresponding to the above functions.

[0041] In a possible implementation manner, the structure of the device includes a processing module and a transceiver module. Among them, the processing module is configured to support the device to execute the corresponding functions of the first communication device in the first aspect or any possible implementation manner of the first aspect, or to execute the corresponding functions of the first communication device in the second aspect or any possible implementation manner of the second aspect, or to execute the corresponding functions of the second communication device in the third aspect or any possible implementation manner of the third aspect.

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

[0043] In another possible implementation manner, the structure of the device includes a processor and may further include a memory. The processor is coupled to the memory and can be used to execute computer program instructions stored in the memory, so that the device executes the method in the first aspect or any possible implementation manner of the first aspect described above, or executes the method in the second aspect or any possible implementation manner of the second aspect described above, or executes the method in the third aspect or any possible implementation manner of the third aspect described above.

[0044] Optionally, the device further includes a communication interface, and the processor is coupled to the communication interface. When the device is a device, the communication interface may be a transceiver or an input / output interface; when the device is a chip included in the device, the communication interface may be an input / output interface of the chip. Optionally, the transceiver may be a transceiver circuit, and the input / output interface may be an input / output circuit.

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

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

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

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

[0049] In a sixth aspect, the present application provides a computer-readable storage medium, in which computer programs or instructions are stored. When the computer programs or instructions are executed by a communication device, the communication device is caused to execute the method in the first aspect or any possible implementation manner of the first aspect above, or execute the method in the second aspect or any possible implementation manner of the second aspect above, or execute the method in the third aspect or any possible implementation manner of the third aspect above.

[0050] In a seventh aspect, the present application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a communication device, the methods in the above first aspect or any possible implementation manner of the first aspect are implemented, or the methods in the above second aspect or any possible implementation manner of the second aspect are implemented, or the methods in the above third aspect or any possible implementation manner of the third aspect are implemented.

[0051] In an eighth aspect, an embodiment of the present application provides a communication system, which includes a first communication device and a second communication device. The first communication device implements the method in the above first aspect or any possible implementation manner of the first aspect, and the second communication device implements the method in the above third aspect or any possible implementation manner of the third aspect; or the first communication device implements the method in the above second aspect or any possible implementation manner of the second aspect, and the second communication device implements the method in the above third aspect or any possible implementation manner of the third aspect.

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

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

[0054] Figure 2A It is a schematic diagram of a network architecture provided by the present application;

[0055] Figure 2B It is another schematic diagram of a network architecture provided by the present application;

[0056] Figure 2C It is yet another schematic diagram of a network architecture provided by the present application;

[0057] Figure 3 It is a schematic flowchart of the first communication method provided by the present application;

[0058] Figure 4 It is a schematic flowchart of the second communication method provided by the present application;

[0059] Figure 5 It is a schematic flowchart of the third communication method provided by the present application;

[0060] Figure 6 It is a schematic flowchart of the fourth communication method provided by the present application;

[0061] Figure 7Schematic diagram of the fifth communication method provided by this application;

[0062] Figure 8 Schematic diagram of the sixth communication method provided by this application;

[0063] Figure 9 Schematic diagram of the seventh communication method provided by this application;

[0064] Figure 10 Schematic diagram of the eighth communication method provided by this application;

[0065] Figure 11 Schematic diagram of the ninth communication method provided by this application;

[0066] Figure 12 Schematic diagram of the tenth communication method provided by this application;

[0067] Figure 13 Schematic diagram of the eleventh communication method provided by this application;

[0068] Figure 14 Schematic diagram of a communication device provided by this application;

[0069] Figure 15 Schematic diagram of another communication device provided by this application. Detailed implementation manners

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

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

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

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

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

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

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

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

[0078] Figure 2C The shown communication network is in Figure 2BBased on the communication network shown, some additional network elements related to the data channel (DC) are added, such as the data channel signaling function (DCSF) network element, the data channel application repository (DCAR) network element, the DC AS. Optionally, Figure 2C The communication system shown also includes a network exposure function (NEF) network element, an NRF network element, and a BAR network element.

[0079] Here, a brief introduction is given to Figures 2A to 2C each of the network elements shown (or referred to as functional network elements, functional entities, nodes, devices, etc.):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0103] This application provides a communication method for ensuring security during the rendering process. This method is applied to the scenario where the first terminal and the second terminal conduct a digital human-related call. Exemplarily, the first terminal, as the calling side (or initiator), initiates a digital human-related call to the second terminal, and the second terminal, as the called side (or terminator), receives the digital human-related call.

[0104] Figure 3 It is a schematic flowchart of a communication method provided exemplarily for this application.

[0105] The communication method may be executed by a first communication device and a second communication device. Herein, the first communication device may be an NRF network element, or a part of the NRF network element (such as a chip). Alternatively, the first communication device may be an NEF network element, or a part of the NEF network element (such as a chip). The second communication device may be a DC AS related to a call, or a part of the DC AS (such as a chip). For ease of description, hereinafter, it is described by taking the first communication device as an NRF network element or an NEF network element, and the second communication device as a DC AS as an example.

[0106] Exemplarily, the DC AS related to a call refers to the DC AS that provides data channel service logic for the current call.

[0107] Exemplarily, the first terminal and the second terminal are located in the same IMS network. When the DC AS related to the call is located inside the IMS network, the first communication device is an NRF network element. When the DC AS related to the call is located outside the IMS network, the first communication device is an NRF network element or an NEF network element. Additionally, exemplarily, the first terminal and the second terminal are located in different IMS networks. When the DC AS related to the call is located in the same IMS network as the first terminal, the first communication device is an NRF network element. When the DC AS related to the call is located in different IMS networks from the first terminal, the first communication device is an NRF network element or an NEF network element.

[0108] For ease of description, hereinafter, mainly taking the NRF network element as an example, the "DC AS related to a call" is simply referred to as the DC AS.

[0109] Figure 3 It focuses on describing that the NRF network element verifies the identity of the second entity, and then generates a first token for the second entity.

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

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

[0112] Herein, the first entity is an entity determined by the DC AS after receiving a capability negotiation request and is used to download a digital human model. The manner in which the DC AS determines the entity (i.e., the first entity) for downloading the first digital human model can be referred to Figure 7 the description in the relevant embodiments.

[0113] Exemplarily, the first entity may be one of the following: the DC AS related to the current call between the first terminal and the second terminal, the MF network element related to the current call between the first terminal and the second terminal, the first terminal, and the second terminal. Exemplarily, the MF network element related to the call refers to the MF network element that provides media resource management functions for this call. The "MF network element related to the call" is abbreviated as the MF network element.

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

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

[0116] Exemplarily, the DC AS also sends the information of the entity for storing the first digital human model to the NRF network element. Correspondingly, the NRF network element receives the information of the entity for storing the first digital human model from the DC AS. Among them, the information of the entity for storing the first digital human model is, for example, the identity of the first BAR network element. The specific implementation manner for the DC AS to determine the information of the entity for storing the first digital human model can be referred to Figure 7 the description in the relevant embodiments.

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

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

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

[0120] Exemplarily, the second entity directly sends a token request to the NRF network element. The second entity 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).

[0121] Another exemplarily, 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.

[0122] Exemplarily, 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. Further, the first digital human model is used for the rendering of the first digital human.

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

[0124] In addition, when the NRF network element determines that the second entity is not the first entity, it does not generate the first token.

[0125] The first token includes information of the first entity (or information of the second entity) and the identifier of the first digital human. The first token is used to authorize the first entity to request to download the first digital human model. Exemplarily, the first token also includes information of the entity for storing the first digital human model. The first token is used to authorize the first entity to download the first digital human model from the entity for storing the first digital human model. The entity for storing the first digital human model is, for example, the first BAR network element, and the information of the first BAR network element is, for example, the identifier of the first BAR network element.

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

[0127] Presentation form 1. The first token includes an authorized avatar field, an issuer field, a subject field, an audience (service provider) field, and an expiration time field. Among them, the avatar field includes the identifier of the first digital human, 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 identifier of the first BAR network element, and the expiration time field includes t1.

[0128] Presentation form 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 position of each piece of information is preset 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 respectively.

[0129] In addition, in another possible implementation, the token request may also carry a second token generated by the first terminal. The NRF network element generates the first token. Specifically, the NRF network element generates the first token according to the information of the first entity and the second token. For example, the NRF network element verifies the second token, and after determining that the second token passes the verification, generates the first token according to the information of the first entity and the second token.

[0130] Exemplarily, 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. Among them, 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 the verification according to 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 further includes a subject field, and the subject field includes the information of the entity (denoted as entity 1) authorized to download the first digital human model. When the NRF network element verifies the second token, it may further include: Verification (3), the NRF network element determines whether the information of entity 1 is the information of the first entity; Optionally, the second token further includes an audience field, and the audience field includes the information of the entity (denoted as entity 2) authorized to provide the first digital human model. When the NRF network element verifies the second token, it may further include: Verification (4), the NRF network element determines whether the information of entity 2 is the information of the first BAR network element.

[0131] Exemplarily, 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 passes the verification. When generating the first token based on the information of the first entity and the second token, the NRF network element can reuse the content in the avatar field, the subject field, and the 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.

[0132] For another 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 verifications (1) and (2), it determines that the second token passes the verification. When generating the first token based on the information of the first entity and the second token, the NRF network element can reuse the content in 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.

[0133] Step 304, the NRF network element sends the first token to the second entity. Correspondingly, the second entity receives the first token from the NRF network element.

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

[0135] Exemplarily, the NRF network element directly sends the first token to the second entity, and the second entity 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).

[0136] For another example, the NRF network element sends the first token to the second entity through the DC AS. Correspondingly, the second entity receives the first token from the NRF network element. Among them, 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.

[0137] Exemplarily, the DC AS may also send the information of 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, where the third entity may be an HSS network element or a ROF network element. As Figure 4 Exemplarily provides a schematic flowchart of a second communication method. The HSS network element in this method may also be replaced by a ROF network element.

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

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

[0140] Exemplarily, the HSS network element stores the information of the first entity. Exemplarily, the DC AS sends the information of the entity for storing the first digital human model to the HSS network element, and correspondingly, the HSS network element receives the information of the entity for storing the first digital human model from the DC AS. Optionally, the HSS network element stores the information of the entity for storing the first digital human model. Optionally, the HSS network element also sends a reception response to the DC AS.

[0141] For the specific implementation, reference may be made to the description in step 301.

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

[0143] For the specific implementation, reference may be made to the description in step 302.

[0144] Step 403, the NRF network element sends an authorization request to the HSS network element, and correspondingly, the HSS network element receives the authorization request from the NRF network element, where the authorization request includes the information of the second entity. The authorization request is used to determine whether the second entity is the first entity.

[0145] Step 404, when the HSS network element determines that the second entity is the first entity, it sends an authorization response to the NRF network element, and correspondingly, the NRF network element receives the authorization response from the HSS network element. The authorization response can be used to indicate that the second entity is the first entity.

[0146] In addition, after the HSS network element determines that the second entity is not the first entity, it may also send an authorization response to the NRF network element, and the authorization response can be used to indicate that the second entity is not the first entity.

[0147] Step 405, the NRF network element generates a first token.

[0148] That is, the NRF network element generates a first token when it determines that the second entity is the first entity.

[0149] For the specific implementation, refer to the description in step 303.

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

[0151] For the specific implementation, refer to the description in step 304.

[0152] Subsequently, the second entity can request the first digital human model from the entity for storing the first digital human model (taking the first BAR network element as an example below) based on the first token. For the specific details, refer to Figure 5 the schematic flowchart of the third communication method provided exemplarily.

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

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

[0155] Exemplarily, the second entity sends a digital human model download request (download avatar representation) to the first BAR network element, and the digital human model download request includes the first token.

[0156] Exemplarily, the digital human model download request may further include the identifier of the first digital human and the identifier of the first terminal.

[0157] Based on whether the second entity is an agent entity or a rendering entity, the following exemplarily describes the cases separately:

[0158] Case 1: The second entity is an agent entity, that is, the second entity is the DC AS. The DC AS agent 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. For the specific verification method, refer to the description in step 502.

[0159] Case 2: The second entity is a rendering entity:

[0160] Case 2.1: The second entity is the first terminal. The first terminal sends a digital human model download request to the MF network element; the MF network element sends a digital human model download request to the DC AS; the DC AS sends a digital human model download request to the first BAR network element.

[0161] Exemplarily, after receiving the digital human model download request, the MF network element may further perform the following verification 1 and / or verification 2. It can be understood that when the MF network element determines that any one of the verifications fails, the MF network element may no longer forward the digital human model download request to the DC AS.

[0162] 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 Figure 7 related embodiments).

[0163] 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 previously verified by the DC AS (see Figure 7 related embodiments).

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

[0165] Exemplarily, the MF network element may perform verification 1 and / or verification 2 based on the following methods:

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

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

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

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

[0170] Scenario 2.3, the second entity is the MF network element. The MF network element sends a digital human model download request to the DC AS. The DC AS sends a digital human model download request to the first BAR network element.

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

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

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

[0174] Case 1, the second entity is an agent 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, the first BAR network element confirms the identity of the DC AS; further, after the first BAR network element determines that the information of the first entity in the first token is the information of the DC AS, it determines that the verification is passed.

[0175] Case 2, the second entity is a rendering entity:

[0176] Case 2.1, the second entity is the first terminal. When the first terminal and the first BAR network element perform end-to-end communication, the first BAR network element confirms the identity of the first terminal when establishing TLS with the first terminal. Further, 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 determines that the verification is passed.

[0177] The second entity is the first terminal. When the first terminal performs end-to-end communication 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 the first BAR network element verifies that the subject in the first token is the information of the first terminal in the CCA, it determines that the verification is passed.

[0178] Case 2.2, when the second entity is the MF network element and the MF network element and the first BAR network element perform end-to-end communication, the first BAR network element confirms the identity of the MF network element when establishing a TLS channel with the MF network element. Further, after the first BAR network element determines that the information of the first entity in the first token is the information of the MF network element, it determines that the verification is passed.

[0179] The second entity is an MF network element. When the MF network element conducts end-to-end communication with the first BAR network element through the DC AS proxy, when the first BAR network element establishes a TLS channel with the DC AS, it confirms the identity of 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 the first BAR network element verifies that the subject in the first token is the information of the MF network element in the CCA, it determines that the verification passes.

[0180] Case 2.3: The second entity is a second terminal. When the second terminal conducts end-to-end communication with the first BAR network element, when the first BAR network element establishes a TLS with the second terminal, it confirms the identity of the second terminal. Further, 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 determines that the verification passes.

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

[0182] In addition, the first token may also include information about the first BAR network element. The first BAR network element can also determine that it is the network element authorized by the first token to provide the first digital human model based on the information about the first BAR network element included in the first token. That is, when the first BAR network element determines, based on the information of 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 determines, based on the information about the first BAR network element included in the first token, that it is the network element authorized by the first token to provide the first digital human model, it determines that the verification passes.

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

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

[0185] 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 an agent 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.

[0186] It should be added that Figure 5 In the related embodiments, the first BAR network element (i.e., the entity providing the first digital human model) is taken as an example for illustration. In this embodiment, it is also described 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 the 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 (that is, to determine whether the second BAR network element is the first BAR network element). Further, if the second BAR network element determines that the second entity is the entity authorized by the first token to download the first digital human model and itself is the BAR network element indicated by the first token, it determines that the verification passes and provides the first digital human model to the second entity; otherwise, it determines that the verification fails and does not provide the first digital human model to the second entity. It can be understood that Figure 5 The related embodiments can be executed by a third communication device, and the third communication device can be the second BAR network element or a part (such as a chip) in the second BAR network element.

[0187] Figure 6 It is a schematic flowchart of the fourth communication method provided exemplarily for this application. This communication method can be executed by a first communication device, a second communication device, and a third communication device. For the descriptions of the first communication device, the second communication device, and the third communication device, reference can be made to Figures 3 to 5 the descriptions in the related embodiments. Taking the third communication device as the first BAR network element as an example for illustration.

[0188] Figure 6 This focuses on the NRF network element verifying the identity of the second entity and instructing the first BAR network element to provide the first digital human model to the second entity.

[0189] 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 the specific implementation, reference can be made to the description in Step 301.

[0190] 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. Exemplarily, the digital human model download request includes the identifier of the first digital human, and the digital human model download request is used for the second entity to request to download the first digital human model. At this time, the digital human model download request does not include the first token.

[0191] Step 603: The first BAR network element sends a verification request to the NRF network element. Correspondingly, the NRF network element receives the verification request from the first BAR network element. The verification request includes information about the second entity.

[0192] Step 604: The NRF network element sends a verification response to the first BAR network element. The verification response is used to indicate that the second entity is the first entity.

[0193] Exemplarily, after determining that the second entity is the first entity, the NRF network element sends a verification response to the first BAR network element. The verification response is used to indicate that the second entity is the first entity (or, is used to indicate that the first BAR network element provides the first digital human model to the second entity). In addition, 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. This verification response is used to indicate that the second entity is not the first entity (or, is used to indicate that the first BAR network element does not provide the first digital human model to the second entity).

[0194] For the method by which the NRF network element determines whether the second entity is the first entity, refer to the descriptions in steps 301 and 302.

[0195] In addition, when the DC AS also sends information about the entity for storing the first digital human model to the NRF network element, after receiving the verification request, the NRF network element may further determine whether the first BAR network element is the entity for storing the first digital human model according to the identifier of the first BAR network element in the verification request (that is, the information about the entity sending the verification request). Further, when the NRF network element determines that the first BAR network element is the entity for 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 is used to indicate that the first BAR network element provides the first digital human model to the second entity. For the method by which the NRF network element determines whether the entity sending the verification request is the entity for storing the first digital human model, refer to the descriptions in steps 301 and 302.

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

[0197] Further, when the second entity is a rendering entity, the second entity generates a digital human according to the first digital human model; when the second entity is an agent 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 according to the first digital human model.

[0198] Figure 7Schematic diagram of the fifth communication method provided exemplarily for this application. This communication method is specifically a way for a second communication device to determine information of 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 (such as a chip). For ease of description, the following takes the second communication device being a DC AS as an example for illustration.

[0199] Furthermore, a first ADC is established between the first terminal and the DC AS, and the first ADC is used for rendering negotiation. Among them, end-to-end protection is established between the first terminal and the MF network element, and end-to-end protection is established between the MF network element and the DC AS. When the first terminal sends a message to the DC AS through the first ADC, specifically, the first terminal sends a message to the MF network element, and the MF network element forwards the message to the DC AS. 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 in the MF network element.

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

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

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

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

[0204] The identifier (avatar id) of the first digital human is carried in the capability negotiation request. Exemplarily, negotiation parameters of the first terminal may also be carried in the capability negotiation request. Exemplarily, the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or candidate entities preferred (which may also be replaced with "not preferred" in this application) by the first terminal, where the candidate entities include one or more of the MF network element, the first terminal, and the second terminal.

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

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

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

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

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

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

[0211] Exemplarily, when a first ADC is established between a first terminal and a DC AS, and the first terminal sends a capability negotiation request to the DC AS, specifically, the first terminal may send the capability negotiation request to an 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.

[0212] Optionally, after step 701, one or more of the following steps A, B, and C are further included:

[0213] Step A, in response to the capability negotiation request, the DC AS determines information about a first entity.

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

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

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

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

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

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

[0220] Among them, the DC AS includes preset rendering requirements, such as the minimum requirements for rendering a digital human. When the DC AS determines whether the MF network element can be used as a rendering entity, specifically, the DC AS determines whether the rendering capability of the MF network element can meet the preset rendering requirements. If the DC AS determines that the rendering capability of the MF network element meets the preset rendering requirements, it determines that 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, it determines that 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 the description of the rendering capabilities of the MF network element, the first terminal, and the second terminal, refer to the description in Implementation Mode 2 below.

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

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

[0223] Among them, the negotiation parameters of the MF network element include the rendering capability of the MF network element and / or the candidate entities recommended by the MF network element. The negotiation parameters of the second terminal include the rendering capability of the second terminal and / or the candidate entities recommended by the second terminal. Among them, for the negotiation parameters of the MF network element or the second terminal, refer to the description of the negotiation parameters of the first terminal in step 701. For the candidate entities recommended by the MF network element or the second terminal, refer to the description of the candidate entities recommended by the first terminal in step 701.

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

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

[0226] For another example, the DC AS sends a retrieval request to the MF network element. The retrieval request is used to request the negotiation parameters of the second terminal, and the identification of the second terminal is included in the retrieval request. Correspondingly, the MF network element forwards the retrieval request to the second terminal. The second terminal sends a retrieval response to the MF network element, and the negotiation parameters of the second terminal are included in the retrieval response. When forwarding the retrieval response, the MF network element carries its own negotiation parameters in the retrieval response.

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

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

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

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

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

[0232] Furthermore, a certain entity may not carry the rendering capability of the entity in the negotiation parameters. In this case, the DC AS may deem that the entity does not support rendering. Then the DC AS selects an entity with stronger rendering capability from the entities that support rendering as the first entity. For example, the negotiation parameters of the first terminal do not carry the rendering capability of the first terminal, the negotiation parameters of the second terminal carry the rendering capability of the second terminal, and the negotiation parameters of the MF network element carry the rendering capability of the MF network element. The DC AS may assume that the first terminal does not support rendering, and then select an entity with stronger rendering capability (such as the MF network element) as the first entity based on the rendering capability of the second terminal and the rendering capability of the MF network element.

[0233] Example 2: The negotiation parameters of each entity carry the candidate entity recommended by the entity, but do not carry the rendering capability of the entity. Exemplarily, the DC AS determines the first entity based on the candidate entity 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, the first terminal recommends the MF network element and the first terminal as the first entity, the second terminal recommends the MF network element and the second terminal as the first entity, and the MF network element recommends the MF network element as the first entity. Then, the DC AS determines that the MF network element has the most votes and selects the MF network element as the first entity.

[0234] Example 3: The negotiation parameters of each entity carry the candidate entity recommended by the entity and the rendering capability of the entity, and the DC AS selects the recommended entity that supports rendering.

[0235] In conjunction with an example of a negotiation parameter of a first terminal, a negotiation parameter of an MF network element, and a negotiation parameter of a second terminal provided in Table 1, the first entity determined by the DC AS is illustrated.

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

[0237] For another example, when the negotiation parameters of the first terminal include "support rendering, and the recommended entity is the first terminal or the MF network element", the negotiation parameters of the second terminal include "support rendering, and the recommended entity is the second terminal or the MF network element", and the negotiation parameters of the MF network element include "support rendering, and 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 the terminals all support rendering and recommend other entities 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 also be seen in Table 1, and will not be elaborated one by one.

[0238] Table 1

[0239]

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

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

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

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

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

[0245] In a possible example, the DC AS includes preset rendering requirements, which can be regarded as the minimum requirements for rendering a digital human. For example, the data types required for rendering and the minimum number of sensors corresponding to the data types required for rendering.

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

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

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

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

[0250] Alternatively, the NRF network element can determine a dedicated entity for rendering (also known as the compute node function (CNF) network element) from the network according to the preset rendering requirements, use the CNF network element as the first entity, and then send the information of the first entity to the DC AS.

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

[0252] Alternatively, when the NRF network element determines that there is no network element in the network that can meet the preset rendering requirements according to 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.

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

[0254] Exemplarily, the NRF network element stores the information of the first entity.

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

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

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

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

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

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

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

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

[0263] For example, the DC AS includes a list of identifiers of digital humans corresponding to each of the terminals 1 to 3. The list of identifiers of the digital human corresponding to terminal 1 includes the identifiers of digital humans 1 to 3. The list of identifiers of the digital human corresponding to terminal 2 includes the identifiers of digital humans 2 to 3. The list of identifiers of the digital human corresponding to terminal 3 includes the identifiers of digital humans 1 to 4. Further, 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 identifiers of the digital human corresponding to terminal 1 includes the identifier of the first digital human (i.e., the identifier of digital human 1), and determine that the first terminal has the permission to use the first digital human model. For another example, the first terminal is terminal 1 and the first digital human is digital human 4. The DC AS determines that the list of identifiers of the digital human corresponding to terminal 1 does not include the identifier of the first digital human (i.e., the identifier of digital human 4), and determines that the first terminal does not have the permission to use the first digital human model.

[0264] In this way, it is avoided that the identifier sent by the first terminal is that of the digital human of other terminals, which may cause the rendering entity to render the digital human of other terminals or cause the leakage of the digital human model of other terminals.

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

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

[0267] After step 701, the DC AS sends the information of the first entity to the NEF network element (or the NRF network element), or sends the information of the first entity and the information of the entity for storing the first digital human model, which is equivalent to step 301 or step 601 above; or, after step 701, the DC AS can send the information of the first entity to the HSS network element (or the ROF network element), or send the information of the first entity and the information of the entity for storing the first digital human model, which is equivalent to step 401 above.

[0268] Optionally, it further includes:

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

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

[0271] Exemplarily, the capability negotiation response includes information about the first entity. Exemplarily, the capability negotiation response can also be referred to as a negotiation response, a rendering negotiation response, a driving negotiation response, an animation negotiation response, etc.

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

[0273] Exemplarily, a first ADC is established between the first terminal and the DC AS, and 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 the capability negotiation response to the MF network element, and the MF network element forwards the capability negotiation response to the first terminal. For example, the MF network element does not parse the capability negotiation response, and the capability negotiation response is transparently transmitted in the MF network element.

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

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

[0276] Optionally, it further includes:

[0277] Step 703, the first terminal generates a second token.

[0278] Exemplarily, the information of the first entity is included in the second token. Exemplarily, the identifier of the first digital human may also be carried in the second token.

[0279] When the DC AS also determines the information of the entity for storing the first digital human model (for example, the information of the first BAR network element), the information of the entity for storing the first digital human model may also be included in the second token.

[0280] Optionally, it further includes:

[0281] Step 704, the first terminal sends the second token.

[0282] When the first terminal sends the second token, specifically, the first terminal sends a re-invite message, and the second token is included in the re-invite message, and the re-invite message is used to establish a second ADC.

[0283] It can be 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, and the first ADC 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, and the second ADC is used for transmitting service data. For example, it transmits the data between the first terminal and the second terminal (such as the data for rendering the entity for rendering (such as user information), and transmits the digital human after rendering, etc.).

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

[0285] It should be noted that if the first entity is the second MF network element (Implementation Mode 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.

[0286] Based on the first entity being an MF network element, DC AS, second terminal, or first terminal, the method for the first entity to obtain the second token is exemplarily described. Further, the first entity may request the first token from the NRF network element (or NEF network element) according to the second token.

[0287] When the first entity is an MF network element, the first terminal may first send a re-invite message to the IMS AS, and then the IMS AS sends a media resource reserving message to the MF network element, and the second token is included in the media resource reserving message.

[0288] It should be noted that after receiving the media resource reservation message, the MF network element may 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 verified by the previous 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 verified by the previous DC AS.

[0289] The description of verification 1 and / or verification 2 can be found in the above step 501.

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

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

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

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

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

[0295] Combined with the above Figure 3 、 Figure 5 、 Figure 7 descriptions in the related embodiments, such as Figure 8 is a schematic flowchart of the sixth communication method provided exemplarily in this application. In this communication method, specifically, the DC AS determines the information of the first entity according to the first configuration information. Among them, 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 the first token from the NRF network element, requests the first digital human model from the first BAR network element based on the first token, and generates the first digital human according to the first digital human model.

[0296] Figure 8 In , "NRF network element" can also be replaced with "NEF network element".

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

[0298] Step 802, the first terminal sends a capability negotiation request to the DC AS. Correspondingly, the DC AS receives the capability negotiation request from the first terminal. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. Among them, the specific implementation of step 802 can refer to the description in step 701.

[0299] Step 803, the DC AS determines that the first terminal has the permission to use the first digital human model. Among them, the specific implementation of step 803 can refer to the description in step C.

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

[0301] Step 805: The DC AS sends the information of the first entity (i.e., the information of the MF network element) 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 MF network element) and the information of the first BAR network element from the DC AS. Herein, the specific implementation of step 805 can be referred to the description in step 301.

[0302] Step 806: The NRF network element sends a reception response to the DC AS. Correspondingly, the DC AS receives the reception response from the NRF network element. Herein, the specific implementation of step 806 can be referred to the description in step 301.

[0303] 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. Herein, the specific implementation of step 807 can be referred to the description in step 302.

[0304] Step 808: The NRF network element determines that the MF network element is the first entity. Herein, the specific implementation of step 808 can be referred to the description in step 303.

[0305] 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. Herein, the specific implementation of step 809 can be referred to the descriptions in step 303 and step 304.

[0306] 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. Herein, the specific implementation of step 810 can be referred to the description in step 501.

[0307] 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 a first digital human model. The specific implementation of step 811 can refer to the description in step 503. Exemplarily, before step 811, the first BAR network element can also determine that the verification is passed after determining that the subject field in the first token is the information of the MF network element and the audience field is the information of the first BAR network element. The specific details can refer to the description in step 502.

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

[0309] Figure 8 In related embodiments, 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 can be understood that Figure 8 Only exemplary steps related to the present application are shown. In the rendering capability negotiation process, ADC establishment process, and digital human rendering process, there may also be other steps, which are not listed in the present application.

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

[0311] Combined with the above Figure 3 、 Figure 5 、 Figure 7 In the description of related embodiments, such as Figure 9 is a schematic flowchart of the seventh communication method provided exemplarily in the present application. In this communication method, the DC AS determines the information of the first entity according to the first configuration information. Here, both the first entity and the second entity are proxy entities (i.e., the DC AS), 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, sends the first digital human model to the first terminal, and the first terminal generates a first digital human according to the first digital human model.

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

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

[0314] 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. Exemplarily, the capability negotiation request includes the identifier of the first digital human and the negotiation parameters of the first terminal. Among them, the specific implementation of step 902 can refer to the description in step 701.

[0315] Step 903, the DC AS determines that the first terminal has the permission to use the first digital human model. Among them, the specific implementation of step 903 can refer to the description in step C.

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

[0317] 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. Among them, the specific implementation of step 905 can refer to the description in step 301.

[0318] Step 906, the NRF network element sends a reception response to the DC AS. Correspondingly, the DC AS receives the reception response from the NRF network element. Among them, the specific implementation of step 906 can refer to the description in step 301.

[0319] 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. Among them, the specific implementation of step 907 can refer to the description in step 302.

[0320] Step 908, the NRF network element determines that the DC AS is the first entity. Among them, the specific implementation of step 908 can refer to the description in step 303.

[0321] 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 the specific implementation of step 909, reference can be made to the descriptions in steps 303 and 304.

[0322] 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 the specific implementation of step 910, reference can be made to the description in step 501.

[0323] 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 the specific implementation of step 911, reference can be made to the description in step 503. Exemplarily, before step 911, the first BAR network element can also determine that the verification is passed after determining that the subject field in the first token is the information of the DC AS and the audience field is the information of the first BAR network element. For the specific implementation, reference can be made to the description in step 502.

[0324] Step 912: The DC AS sends the first digital human model to the first terminal. Exemplarily, the DC AS sends the first digital human model to the first terminal through the second ADC.

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

[0326] Figure 9 In related embodiments, 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 can be understood that Figure 9 Only exemplary steps related to this application are shown. In the rendering capability negotiation process, the ADC establishment process, and the digital human rendering process, other steps may also be included, which are not listed in this application.

[0327] 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 before step 910.

[0328] Combined with the above Figure 4 、Figure 5 , Figure 7 As described in the related embodiments, such as Figure 10 is a schematic flowchart of the eighth communication method provided exemplarily in this application. Specifically, in this communication method, DC AS determines the information of the first entity according to the first configuration information. Herein, both the first entity and the second entity are MF network elements, and DC AS sends the information of the first entity to the HSS network element. Further, the MF network element requests the first token from the NRF network element, requests the first digital human model from the first BAR network element based on the first token, and generates the first digital human according to the first digital human model.

[0329] Figure 10 In it is also possible to replace the "NRF network element" with the "NEF network element". Figure 10 In it is also possible to replace the "HSS network element" with the "ROF network element".

[0330] Steps 1001 to 1004 respectively correspond to the above steps 801 to 804 and will not be elaborated herein.

[0331] Step 1005, DC AS sends the information of the first entity (i.e., the information of the MF network element) and the information of the first BAR network element to the HSS network element. Correspondingly, the HSS network element receives the information of the first entity (i.e., the information of the MF network element) and the information of the first BAR network element from DC AS. Herein, for the specific implementation of step 1005, reference may be made to the description in step 301.

[0332] Step 1006, the HSS network element sends a reception response to DC AS. Correspondingly, DC AS receives the reception response from the HSS network element. Herein, for the specific implementation of step 1006, reference may be made to the description in step 301.

[0333] 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. Herein, for the specific implementation of step 1007, reference may be made to the description in step 302.

[0334] Step 1008, 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.

[0335] Step 1009, when 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.

[0336] Step 1010, the NRF network element determines that the MF network element is the first entity. Herein, for the specific implementation of step 1010, reference may be made to the description in step 303.

[0337] 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 refer to the description in steps 303 and 304.

[0338] Step 1012 to step 1014 correspond to the above-mentioned steps 810 to step 812 respectively, and will not be repeated here.

[0339] Figure 10 In the relevant embodiment, 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 the steps related to the present application are shown as examples. The rendering capability negotiation process, ADC establishment process and digital human rendering process may also include other steps, which will not be listed in the present application.

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

[0341] In addition, Figure 10 In a related embodiment, the first entity may also be a DC AS. The DC AS acts as an agent entity to request the first digital human model from the first terminal or the second terminal to the first BAR network element. Figure 9 and Figure 10 Got it, no more details.

[0342] Combined with the above Figure 3 , Figure 5 , Figure 7 The description in the relevant embodiments, such as Figure 11 The flow chart of the ninth communication method provided as an example in the present application is that the DC AS determines the information of the first entity according to the negotiation parameters of the first terminal, the negotiation parameters of the second terminal and the negotiation parameters of the MF network element, wherein the first entity and the second entity are both MF network elements, and the DC AS sends the information of the first entity to the NRF network element. Further, the MF network element requests the first token from the NRF network element, requests the first digital human model from the first BAR network element based on the first token, and generates the first digital human according to the first digital human model.

[0343] Step 1101 to step 1103 correspond to step 801 to step 803 respectively, and will not be repeated here.

[0344] 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 the negotiation parameters of the second terminal. The negotiation parameters of the second terminal include the rendering capability of the second terminal and the candidate entities recommended by the second terminal. For the specific implementation of step 1104, refer to the description in step A.

[0345] 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 the specific implementation of step 1105, refer to the description in step A.

[0346] 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 of the second terminal includes the negotiation parameters of the second terminal. For the specific implementation of step 1106, refer to the description in step A.

[0347] 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 rendering capability response of the MF network element includes the negotiation parameters of the second terminal and the negotiation parameters of the MF network element. Among them, the negotiation parameters of the MF network element include the rendering capability of the MF network element and the candidate entities recommended by the MF network element. For the specific implementation of step 1107, refer to the description in step A.

[0348] Step 1108: The DC AS determines the information of the first entity (i.e., the information of the MF network element) according to the negotiation parameters of the first terminal, the negotiation parameters of the second terminal, and the negotiation parameters of the MF network element. And, the DC AS determines the information of the first BAR network element according to the second configuration information. For the specific implementation of step 1108, refer to the descriptions in step A and step B.

[0349] Steps 1109 to 1116 respectively correspond to steps 805 to 812, and will not be elaborated here.

[0350] Combined with the above Figure 3 、 Figure 5 、 Figure 7 descriptions in the relevant embodiments, such as Figure 12Schematic diagram of the tenth communication method provided exemplarily for this application. Specifically, in this communication method, the DC AS fails to determine 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. Then, the DC AS requests the information of the first entity from the NRF network element. Correspondingly, the NRF network element determines the information of the first entity 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 the first token from the NRF network element, requests the first digital human model from the first BAR network element based on the first token, and generates the first digital human according to the first digital human model.

[0351] Steps 1201 to 1207 respectively correspond to steps 1101 to 1107 and will not be elaborated further.

[0352] 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 determines the information of the first BAR network element according to the second configuration information. For the specific implementation of step 1208, refer to the descriptions in steps A and B.

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

[0354] Step 1210, the NRF network element sends a first response to the DC AS. Correspondingly, the DC AS receives the first response sent by the NRF network element. The first response includes the information of the first entity (that is, the information of the second MF network element). Optionally, the NRF network element also stores the information of the first entity.

[0355] 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 a first response to the DC AS.

[0356] Among them, the information of the second MF network element is used for the DC AS to update the MF network element so that the first terminal establishes a second ADC with the DC AS based on the second MF network element. Exemplarily, the DC AS may also send the information of the second MF network element to the DCSF network element, and the information of the second MF network element is used for the DCSF network element to update the MF network element so that the first terminal establishes a second ADC with the DC AS based on the second MF network element.

[0357] For the specific implementation of step 1210, refer to the description in step A.

[0358] After step 1210, the following may be included: step 1211 to step 1218. Wherein, step 1211 to step 1218 correspond to step 1109 to step 1116 respectively, except that the first MF network element is replaced by the second MF network element. Wherein, step 1208 to step 1210 belong to the rendering capability negotiation process. It can be understood that Figure 12 Only the steps related to the present application are shown as examples. The rendering capability negotiation process, ADC establishment process and digital human rendering process may also include other steps, which will not be listed in the present application.

[0359] Combined with the above Figure 3 , Figure 5 , Figure 7 The description in the relevant embodiments, such as Figure 13 The flowchart of the eleventh communication method provided as an example in the present application is that the DC AS determines the information of the first entity according to the first configuration information, the first entity and the second entity are both proxy entities (i.e., DC AS), the rendering entity is the first terminal, and the DC AS sends the information of the first entity to the NRF network element. Further, the DC AS receives the second token from the first terminal, requests the first token from the NRF network element based on the second token, and then requests the first digital human model from the first BAR network element based on the first token, sends the first digital human model to the first terminal, and the first terminal generates the first digital human according to the first digital human model.

[0360] Figure 13 The "first terminal" can also be replaced by the "second terminal" or the "MF network element". Figure 13 You can also replace "NRF network element" with "NEF network element".

[0361] Step 1301 to step 1306 correspond to steps 901 to step 906 respectively and will not be described in detail.

[0362] In step 1307, the first terminal sends a re-invitation message to the DCSF. Accordingly, the DCSF receives the re-invitation message from the first terminal. The re-invitation message includes the second token and the identifier of the first digital person. Exemplarily, the issuer field in the second token is the identifier of the first terminal. For the specific implementation of step 1307, please refer to the description in step 304. Exemplarily, before step 1307, the first terminal also generates a second token, and for the specific implementation, please refer to the description in step 304.

[0363] Step 1308: DCSF sends a get avatar animation information request to DC AS. Correspondingly, DC AS receives the get avatar animation information request from DCSF. The get avatar animation information request includes the second token and the first digital identifier.

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

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

[0366] After step 1310 , the following steps may also be included: step 1311 to step 1314 .

[0367] Among them, step 1311 to step 1314 correspond to step 910 to step 913 respectively. Among them, step 1307 to step 1310 belong to the second ADC establishment process. It can be understood that, Figure 13 Only the steps related to the present application are shown as examples. The rendering capability negotiation process, ADC establishment process and digital human rendering process may also include other steps, which will not be listed in the present application.

[0368] It should also be supplemented that the above embodiments are described by taking the determination of the information of the first entity by the DC AS as an example. In other possible examples, it may also be the MF network element, the first terminal, the second terminal or other network elements that determine the information of the first entity. Exemplarily, in the case where the MF network element determines the information of the first entity, when the capability negotiation request of the first terminal is sent to the MF network element, the MF network element can determine the information of the first entity. Exemplarily, in the case where the first terminal determines the information of the first entity, the first terminal can determine the information of the first entity before the capability negotiation. 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. Exemplarily, in the case where the second terminal determines the information of the first entity, after receiving the capability negotiation request, the DC AS can request the information of the first entity from the second terminal. Correspondingly, the second terminal can return the information of the first entity to the DC AS, or directly send the information of the first entity to the NRF network element. Exemplarily, in the case where other network elements determine the information of the first entity, after receiving the capability negotiation request, the DC AS can forward the capability negotiation request to the other network element, and the other network element determines the information of the first entity. Then, the other network element forwards the information of the first entity to the 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 the NEF network element, the HSS network element or the ROF network element.

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

[0370] The above focuses on describing the differences between the embodiments. For other content except the differences, the embodiments can refer to each other; in addition, in the same embodiment, different implementation manners or different examples can also refer to each other.

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

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

[0373] When the communication device 1400 is used to implement the functions of the first communication device in the above Figure 3 related method embodiments:

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

[0375] The transceiver module 1402 is further configured to receive a token request, and the token request carries information of a second entity and an identifier of the digital human;

[0376] The processing module 1401 is configured to generate a first token when determining that the second entity is the first entity;

[0377] The transceiver module 1402 is further configured to send the first token, and the first token is used to authorize the second entity to download the digital human model, and the digital human model is used for the rendering of the digital human.

[0378] In a possible implementation manner, the transceiver module 1402 is further configured to receive information of an entity for storing the digital human model from the DC AS, and the first token includes information of the entity for storing the digital human model.

[0379] In a possible implementation manner, the token request further carries a second token generated by the first terminal; when generating the first token, the processing module 1401 is specifically configured to generate the first token according to the information of the first entity and the second token.

[0380] When the communication device 1400 is used to implement the functions of the first communication device in the above Figure 6 related method embodiments:

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

[0382] The transceiver module 1402 is further configured 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 a digital human model download request from the second entity. The digital human model download request is used for the second entity to request to download a digital human model.

[0383] The transceiver module 1402 is further configured 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.

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

[0385] The transceiver module 1402 is configured to receive a capability negotiation request. The capability negotiation request carries an identifier of a digital human. The capability negotiation request is used to negotiate the rendering of the digital human.

[0386] The processing module 1401 is configured to determine information about the first entity. The first entity is the entity used to download a digital human model. The digital human model is used for the rendering of the digital human.

[0387] The transceiver module 1402 is further configured to send the information about the first entity.

[0388] In a possible implementation, the transceiver module 1402 is further configured to send information about the entity used to store the digital human model according to the identifier of the digital human.

[0389] In a possible implementation, the transceiver module 1402 is further configured to send a token request. The token request includes information about the second entity and the identifier of the digital human. And, when the second entity is the first entity, receive a first token. The first token is used to authorize the second entity to download the digital human model.

[0390] In a possible implementation, the token request further includes a second token. The second token is generated by the first terminal. The first token is generated according to the second token and the information about the first entity.

[0391] In a possible implementation, when the DC AS is inside the IMS network, when the transceiver module 1402 sends the information about the first entity, it is specifically configured to send the information about the first entity to the NRF network element. When the DC AS is outside the IMS network, when the transceiver module 1402 sends the information about the first entity, it is specifically configured to send the information about the first entity to the NEF network element or the NRF network element. Or, when the transceiver module 1402 sends the information about the first entity, it is specifically configured to send the information about the first entity to the HSS network element or the ROF network element.

[0392] In a possible implementation, negotiation parameters of the first terminal are carried in the capability negotiation request; the negotiation parameters of the first terminal include the rendering capability of the first terminal and / or 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 configured to determine the information of the first entity according to the negotiation parameters of the first terminal. In a possible implementation, when determining the information of the first entity according to the negotiation parameters of the first terminal, the processing module 1401 is specifically configured 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 according to the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal.

[0393] In a possible implementation, the transceiver module 1402 is further configured to, when the negotiation parameters of the first terminal, the negotiation parameters of the MF network element, and the negotiation parameters of the second terminal determined by the processing module 1401 do not meet the preset rendering requirements, send a first request to the NRF network element, where the first request includes the preset rendering requirements, and the first request is used to request a first entity that meets the preset rendering requirements; and receive a first response from the NRF network element, where the first response includes the information of the first entity.

[0394] In a possible implementation, the capability negotiation request is information from the first terminal received by the second communication device through the first ADC; where the first ADC is a channel between the first terminal and the second communication device.

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

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

[0397] The memory 1530 and the processor 1520 are coupled. The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms for information interaction between devices, units or modules. At least one of the memories 1530 may be included in the processor 1520.

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

[0399] The device 1500 may further include a communication line 1540. Among them, the communication interface 1510, the processor 1520 and the memory 1530 may be interconnected through the communication line 1540; the communication line 1540 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication line 1540 may be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 15 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0400] Based on the above content and the same concept, the present application further provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed by a communication device, the method executed by the NRF network element in the above method embodiments is implemented, or the method executed by the DC AS in the above method embodiments is implemented.

[0401] Based on the above content and the same concept, the present application further provides a computer program product, which includes a computer program or instruction. When the computer program or instruction is executed by a communication device, the method executed by the NRF network element in the above method embodiments is implemented, or the method executed by the DC AS in the above method embodiments is implemented.

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

[0403] In the embodiments of the present application, for the number of nouns, unless otherwise specified, it means "singular noun or plural noun", that is, "one or more". "At least one" means one or more, and "a plurality of" means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can 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 means that the associated objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item or plural items. For example, at least one (item) of a, b, or c means: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c can be single or multiple.

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

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

[0406] In the embodiments of the present application, words such as "exemplary" or "for example" are used to give examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, using words such as "exemplary" or "for example" aims to present relevant concepts in a specific way.

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

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

Claims

1. A communication method, applied to a scenario where a first terminal and a second terminal conduct a digital human-related conversation, characterized in that: include: The first communication device receives information of a first entity from a data channel application server, the first entity being an entity for downloading a digital human model determined by the data channel application server after receiving a capability negotiation request, the data channel application server being related to the call; The first communication device receives a token request, wherein the token request carries information of the second entity and an identifier of the digital person; The first communication device generates a first token when determining that the second entity is the first entity; The first communication device sends the first token, where the first token is used to authorize the second entity to download the digital human model, where the digital human model is used for rendering the digital human.

2. The method according to claim 1, characterized in that When the data channel application server is located inside an 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 according to claim 1 or 2, characterized in that The first token includes information of the first entity and an identification of the digital person.

4. The method according to any one of claims 1 to 3, characterized in that: Also includes: The first communication device receives information of an entity for storing the digital human model from the data channel application server, and the first token includes the information of the entity for storing the digital human model.

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

6. The method according to any one of claims 1 to 5, characterized in that: The token request also carries a second token, where the second token is generated by the first terminal; The first communication device generates a first token, comprising: The first communication device generates the first token according to 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 conduct a digital human-related conversation, characterized in that: include: The first communication device receives information of a first entity from a data channel application server, the first entity being an entity for downloading a digital human model determined by the data channel application server after receiving a capability negotiation request, the data channel application server being related to the call; The first communication device receives a verification request from a basic digital human warehouse network element, wherein the verification request includes information of a second entity, and the verification request is sent by the basic digital human warehouse network element after receiving a digital human model download request from the second entity, wherein the digital human model download request is used by the second entity to request to download the digital human model; The first communication device sends a verification response to the basic digital human warehouse network element, where the verification response is 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 conduct a digital human-related conversation, characterized in that: include: The second communication device receives a capability negotiation request, the capability negotiation request carries an identifier of the digital human, and the capability negotiation request is used to negotiate the rendering of the digital human; The second communication device determines information of a first entity, the first entity being an entity used to download a digital human model, the digital human model being used for rendering the digital human; The second communication device sends information of the first entity; The second communication device is a data channel application server related to the call or a part of the data channel application server.

9. The method according to claim 8, characterized in that Also includes: The second communication device sends information of an entity storing the digital human model according to the identification of the digital human.

10. The method according to claim 8 or 9, characterized in that Also includes: The second communication device sends a token request, wherein the token request includes information of the second entity and an identification of the digital person; In the case that the second entity is the first entity, the second communication device receives a first token, where the first token is used to authorize the second entity to download the digital human model.

11. The method according to claim 10, characterized in that The token request also includes a second token, where the second token is generated by the first terminal, and the first token is generated according to the second token and information of the first entity.

12. The method according to any one of claims 8 to 11, characterized in that: The second communication device sending the information of the first entity includes: 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 network 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 network element or the network storage function network element; or, The second communication device sends the information of the first entity to a home subscriber server network element or a resource ownership function network element.

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

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

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

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

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

18. A communication device, characterized in that: The method comprises a module for executing the method according to any one of claims 1 to 6, or comprises a module for executing the method according to claim 7, or comprises a module for executing the method according to any one of claims 8 to 17.

19. A communication device, characterized in that: The method comprises a processor and an interface circuit, wherein the interface circuit is used to receive signals from other communication devices other than the communication device and transmit them to the processor or send signals from the processor to other communication devices other than the communication device, wherein the processor implements the method as claimed in any one of claims 1 to 6 through a logic circuit or by executing code instructions, or the processor implements the method as claimed in any one of claims 1 to 6 through a logic circuit or by executing code instructions, or the processor implements the method as claimed in any one of claims 8 to 17 through a logic circuit or by executing code instructions.

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

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

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

Images