Method and device for media communication in communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. A method performed by a device included in a core network in a communication system according to one embodiment of the present disclosure may comprise the steps of: receiving, from a first terminal, a first message for an avatar call between the first terminal and a second terminal, wherein the first message includes a first avatar media list available on the first terminal in relation to the avatar call; updating the first message to further include a second avatar media list which can be provided by the core network in relation to the avatar call; transmitting the updated first message to the second terminal; receiving a second message including one or more avatar media from the second terminal, wherein each of the avatar media is included in the first avatar media list or the second avatar media list; and setting the avatar call on the basis of the one or more avatar media.

Description

Method and device for media communication in a communication system

[0001] The present disclosure relates generally to wireless communication systems, and more specifically to methods and devices for media communication in wireless communication systems.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] Various embodiments of the present disclosure may provide methods and devices for media communication in a wireless communication system.

[0009] Various embodiments of the present disclosure may provide a step-by-step method for transmitting and receiving avatar call / communication data. For example, various embodiments of the present disclosure may be related to video / voice calls and data transmission using IMS (Internet Protocol Multimedia Subsystem) and WebRTC (Web Real-Time Communication).

[0010] The technical problems to be achieved in various embodiments of the present disclosure are not limited to those mentioned above, and other technical problems not mentioned can be considered by a person having ordinary skill in the art from various embodiments of the present disclosure described below.

[0011] A method performed by a device in a wireless communication system according to the present disclosure may include a step of determining whether to perform first-stage data transmission, a step of performing first-stage data transmission when it is determined to perform first-stage data transmission, a step of confirming completion of first-stage data transmission, and a step of performing second-stage data transmission.

[0012] A method performed by a device included in a core network in a communication system according to one embodiment of the present disclosure comprises the steps of: receiving a first message for an avatar call between the first terminal and a second terminal from a first terminal, the first message including a first avatar media list available to the first terminal in relation to the avatar call; updating the first message to further include a second avatar media list available to the core network in relation to the avatar call; transmitting the updated first message to the second terminal; receiving a second message from the second terminal including one or more avatar media, each avatar media included in the first avatar media list or the second avatar media list; and establishing the avatar call based on the one or more avatar media.

[0013] According to one embodiment of the present disclosure, the method further includes a step of confirming that the call requested from the first terminal is the avatar call based on the first message, wherein the confirmation that the call is the avatar call is based on: call type information included in the first message indicating that the call requested from the first terminal is the avatar call, or based on the first message including indication information about a base avatar related to the avatar call.

[0014] According to one embodiment of the present disclosure, the first message further includes a list of solutions related to the base avatar associated with the avatar call or the first avatar media list and a type of each avatar media included in the first avatar media.

[0015] According to one embodiment of the present disclosure, one or more media function (MF) instances for the avatar call are allocated on the core network, each MF instance corresponding to one or more of AS (avatar storage), ADG (animation data generation), AA (avatar animation), BAG (base avatar generation), SM (scene management), Renderer, or APBM (avatar processing block management), and the second avatar media list is associated with the one or more MF instances.

[0016] According to one embodiment of the present disclosure, the avatar call is based on first data including a base avatar associated with the avatar call and second data including avatar motion commands associated with the avatar call.

[0017] According to one embodiment of the present disclosure, the first data is indicated based on indication information for a base avatar related to the avatar call included in the updated first message or content order information related to the avatar call included in the updated first message.

[0018] According to one embodiment of the present disclosure, the updated first message further includes information instructing to skip reception of the corresponding data if the corresponding data is stored.

[0019] In a communication system according to one embodiment of the present disclosure, a device included in a core network includes a transceiver; and a processor connected to the transceiver, wherein the processor is configured to: receive a first message for an avatar call between the first terminal and a second terminal from a first terminal, the first message including a first avatar media list available to the first terminal in relation to the avatar call; update the first message to further include a second avatar media list available to the core network in relation to the avatar call; transmit the updated first message to the second terminal; receive a second message including one or more avatar media from the second terminal, each avatar media included in the first avatar media list or the second avatar media list; and establish the avatar call based on the one or more avatar media.

[0020] According to one embodiment of the present disclosure, the method further includes a step of confirming that the call requested from the first terminal is the avatar call based on the first message, wherein the confirmation that the call is the avatar call is based on: call type information included in the first message indicating that the call requested from the first terminal is the avatar call, or based on the first message including indication information about a base avatar related to the avatar call.

[0021] According to one embodiment of the present disclosure, the first message further includes a list of solutions associated with the base avatar or the first avatar media list associated with the avatar call and a type of each avatar media included in the first avatar media.

[0022] According to one embodiment of the present disclosure, one or more media function (MF) instances for the avatar call are allocated on the core network, each MF instance corresponding to one or more of AS (avatar storage), ADG (animation data generation), AA (avatar animation), BAG (base avatar generation), SM (scene management), Renderer, or APBM (avatar processing block management), and the second avatar media list is associated with the one or more MF instances.

[0023] According to one embodiment of the present disclosure, the avatar call is based on first data including a base avatar associated with the avatar call and second data including avatar motion commands associated with the avatar call.

[0024] According to one embodiment of the present disclosure, the first data is indicated based on indication information for a base avatar related to the avatar call included in the updated first message or content order information related to the avatar call included in the updated first message.

[0025] According to one embodiment of the present disclosure, the updated first message further includes information instructing to skip reception of the corresponding data if the corresponding data is stored.

[0026] A method performed by a first terminal in a communication system according to one embodiment of the present disclosure comprises the steps of: transmitting a first message for an avatar call between the first terminal and the second terminal to the second terminal through a core network, the first message including a first avatar media list available in the first terminal in relation to the avatar call; receiving the avatar call from the core network; and performing the avatar call.

[0027] According to one embodiment of the present disclosure, the avatar currency is based on one or more avatar media, each avatar media being included in the first avatar media list or a second avatar media list provable by the core network.

[0028] According to one embodiment of the present disclosure, based on the first message, it is indicated that the call requested from the first terminal is the avatar call, and the indication that it is the avatar call is based on: call type information included in the first message indicating that the call requested from the first terminal is the avatar call, or based on the first message including indication information about a base avatar related to the avatar call.

[0029] According to one embodiment of the present disclosure, the first message is updated in the core network to further include the second avatar media list and transmitted to the second terminal.

[0030] According to one embodiment of the present disclosure, the first message further includes a list of solutions associated with the base avatar or the first avatar media list associated with the avatar call and a type of each avatar media included in the first avatar media.

[0031] In a communication system according to one embodiment of the present disclosure, a first terminal includes a transceiver; and a processor connected to the transceiver, wherein the processor is configured to: transmit a first message for an avatar call between the first terminal and a second terminal to the second terminal through a core network, the first message including a first avatar media list available in the first terminal in relation to the avatar call; receive the avatar call from the core network; and perform the avatar call.

[0032] According to one embodiment of the present disclosure, the avatar currency is based on one or more avatar media, each avatar media being included in the first avatar media list or a second avatar media list provable by the core network.

[0033] According to one embodiment of the present disclosure, based on the first message, it is indicated that the call requested from the first terminal is the avatar call, and the indication that it is the avatar call is based on: call type information included in the first message indicating that the call requested from the first terminal is the avatar call, or based on the first message including indication information about a base avatar related to the avatar call.

[0034] The various embodiments of the present disclosure described above are only some of the preferred embodiments of the present disclosure, and various embodiments reflecting the technical features of the various embodiments of the present disclosure can be derived and understood by a person having ordinary skill in the art based on the detailed description to be described below.

[0035] Various embodiments of the present disclosure may provide methods and devices for media communication in a wireless communication system.

[0036] Various embodiments of the present disclosure may provide a step-by-step method for transmitting and receiving avatar call / communication data. For example, various embodiments of the present disclosure may be related to video / voice calls and data transmission using IMS (Internet Protocol Multimedia Subsystem) and WebRTC (Web Real-Time Communication).

[0037] The effects that can be obtained from various embodiments of the present disclosure are not limited to the effects mentioned above, and other effects not mentioned can be clearly derived and understood by a person having ordinary skill in the art based on the detailed description below.

[0038] FIG. 1 is a diagram illustrating an example of an avatar call scenario between user A and user B according to various embodiments of the present disclosure.

[0039] FIG. 2 is a diagram illustrating an example of an avatar processing block and an avatar media processing procedure according to various embodiments of the present disclosure.

[0040] FIG. 3 is a diagram illustrating an example of a network structure including a data channel server in a communication system according to various embodiments of the present disclosure.

[0041] FIG. 4 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0042] FIG. 5 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0043] FIG. 6 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0044] FIG. 7 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0045] FIG. 8 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0046] FIG. 9 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0047] FIG. 10 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0048] FIG. 11 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0049] FIG. 12 is a flowchart illustrating an example of a procedure according to various embodiments of the present disclosure.

[0050] FIG. 13 is a diagram comparing Early-session according to various embodiments of the present disclosure with a conventional Early-session.

[0051] FIG. 14 is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0052] FIG. 15 is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0053] FIG. 16A is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0054] FIG. 16b is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0055] FIG. 16c is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0056] FIG. 17 is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0057] FIG. 18a is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0058] FIG. 18b is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0059] FIG. 18c is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0060] FIG. 18d is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0061] FIG. 18e is a flowchart illustrating an example of a procedure for avatar calling according to various embodiments of the present disclosure.

[0062] FIG. 19 illustrates an example of a functional structure of a terminal according to embodiments of the present disclosure.

[0063] FIG. 20 illustrates an example of a functional structure of a core network object according to embodiments of the present disclosure.

[0064] The terms used in this disclosure are used only to describe specific embodiments and may not be intended to limit the scope of other embodiments. The singular expression may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by those of ordinary skill in the art described in this disclosure. Terms defined in general dictionaries among the terms used in this disclosure may be interpreted as having the same or similar meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure. In some cases, even if a term is defined in this disclosure, it cannot be interpreted to exclude embodiments of the present disclosure.

[0065] The various embodiments of the present disclosure described below illustrate a hardware-based approach as an example. However, since the various embodiments of the present disclosure include techniques utilizing both hardware and software, the various embodiments of the present disclosure do not exclude a software-based approach.

[0066] In the present disclosure, a / b / c may be understood as at least one of a, b, or c.

[0067] In the present disclosure, in a mobile communication network-based multimedia call service, in which different data is transmitted in stages, and data transmitted in a first stage (e.g., a transmission stage performed in advance or immediately before a call) is utilized based on data transmitted in a second stage (e.g., a transmission stage performed after a call session is established), one or more of the following may be provided:

[0068] - According to various embodiments of the present disclosure, a method for negotiation and allocation of computing resources of a mobile communication network through a mobile communication network for data transmission for a multimedia call between terminals can be provided.

[0069] - According to various embodiments of the present disclosure, a method for transmitting and receiving first-stage data and / or second-stage data may be provided. For example, a method for identifying first-stage data may be provided, determining whether data identified as first-stage data has already been stored, and if no data has been stored, initiating and completing transmission, and if data has been stored, initiating transmission of second-stage data without receiving first-stage data may be provided.

[0070] According to various embodiments of the present disclosure, a method for identifying a data type (Base Avatar) and specific data (Model ID) belonging to the first stage may be provided.

[0071] According to various embodiments of the present disclosure, a method for providing information and a method for determining whether or not a portion or all of the data belonging to the first step has been received may be provided.

[0072] According to various embodiments of the present disclosure, a method for initiating transmission of data belonging to a second stage after reception of data belonging to a first stage is completed and a method for instructing the same can be provided.

[0073] According to various embodiments of the present disclosure, a method for performance negotiation and computing resource allocation of a mobile communication network can be provided when transmitting data belonging to the second stage between terminals.

[0074] [Avatar Currency Service]

[0075] The present disclosure may provide a method for transmitting second-stage data upon completion of transmission of the first-stage data in a multimedia call service that displays a result generated by combining first-stage data and second-stage data. For example, the first data and the second data, when used alone, may be insufficient or impossible to use as a means of communicating user intent, but may be capable of communicating user intent when combined with the first and second data. Another characteristic is that the first data is discontinuously transmitted, that is, a large amount of data is transmitted in a one-time transmission and is relatively vulnerable to loss occurring during transmission, whereas the second data is real-time transmitted, that is, a relatively small amount of data is continuously transmitted, requires a low transmission delay time, and may be negligible even if loss occurs. The above-described characteristics of the first data and the second data are examples and the present disclosure is not limited thereto.

[0076] An example of a multimedia call service with these characteristics is the avatar call service currently under consideration by the 3rd generation partnership project (3GPP). In this case, the first stage of data may include avatar model data, and one of the second stage data may include command information for avatar movement.

[0077] The present disclosure may provide a method for transmitting avatar model data having a user's actual or intended appearance as first-stage data.

[0078] In one embodiment, the avatar model data may be a 3D object and a mesh, texture, metadata, etc. for specifying the same.

[0079] In another embodiment, the avatar model data may be the trained artificial intelligence (AI) model itself or an app and executable code that includes the AI ​​model.

[0080] Since 3GPP has decided to use the term "Base Avatar" to collectively refer to avatar model data, this disclosure will also use the term "Base Avatar" to collectively refer to avatar model data. In this disclosure, all data that possesses a user's actual or intended appearance and can change based on additional input, without being limited to a specific technology, are referred to as "Base Avatar" and are classified as first-stage data in this disclosure.

[0081] In this disclosure, avatar motion commands that can be used in combination with avatar model data to change avatar model data according to a user's posture or facial expression are classified as second-stage data.

[0082] In one embodiment, the animation data may be a Blendshape command (e.g., a description of a facial expression, e.g., raise a left eyebrow), a Facial Landmark command (e.g., how many IDs of facial landmarks should be moved in the XYZ direction by a certain amount), a Skeleton animation command (e.g., rotate the right elbow joint by a certain number of degrees), or a Text description (e.g., a text sentence describing the user's appearance). It may also be voice-triggered and / or voice may also be used as input.

[0083] Since 3GPP has decided to use the term "Animation data" for avatar motion commands, this disclosure will also use the term "Animation data" for avatar motion commands. This disclosure is not limited to a specific technology, and all input data that allows the Base Avatar to change according to the user's appearance or intention is referred to as "Animation data" and classified as second-stage data in this disclosure.

[0084] In avatar communication to which the present disclosure applies, either the first-stage data (Base Avatar) or the second-stage data (Animation data) alone makes it impossible or unnatural for the user to communicate their intentions. Therefore, it may be desirable for the second-stage data transmission to begin after the first-stage data transmission is complete. However, the present disclosure is not necessarily limited to this.

[0085] [Service Configuration]

[0086] The scenario assumed in the description of various embodiments of the present disclosure is an avatar call between User A and User B. However, this is for convenience of explanation and the present disclosure is not limited thereto. For example, the present disclosure can also be applied to avatar communication between a first device and a second device within a communication system.

[0087] In an avatar call scenario between User A and User B, the Base Avatar pre-created by User A (or the sender) is displayed on the Remote UE (or receiving terminal) of User B (or the receiver) by moving based on User A's facial expressions and movements captured on the UE (user equipment, or transmitting terminal). The reverse, that is, User B's Base Avatar is displayed on User A's terminal in the same manner, is obvious and will not be described separately to avoid overly complex explanations.

[0088] FIG. 1 is a diagram illustrating an example of an avatar call scenario between users A and B according to various embodiments of the present disclosure. More specifically, FIG. 1 illustrates that when users A and B make an avatar call using a UE and a Remote UE, respectively, a connection is attempted within the service of an avatar call service provider and the connection is established through the mediation of a mobile communication network.

[0089] Users A and B can be discovered and connected within the same avatar currency service provider (e.g., metaverse service). The network providers (e.g., mobile service providers) used by Users A and B may be the same or different.

[0090] In the present disclosure, a mobile communication network may exist between the UE and the Remote UE. An avatar call service provider may use network services to mediate avatar calls.

[0091] In the present disclosure, the avatar call service can be formed by combining the first stage data, Base Avatar, and the second stage data, Animation data, and other real-time data, such as video, voice, and motion, can belong to one of the Animation data or can be transmitted according to the video call service method.

[0092] In the present disclosure, the Base Avatar can be stored in the Avatar Storage included in the sender terminal (UE), the network, the receiver terminal (Remote UE), etc., and can be newly or additionally received and updated during the avatar call initiation process. That is, the Base Avatar can be stored in at least one of the Avatar Storage of the sender terminal, the Avatar Storage of the network, and the Avatar Storage of the receiver terminal, and can be newly or additionally received and updated during the avatar call initiation process.

[0093] At least one of the following Base Avatar, Animation Data, Animated Avatar, Scene, and Rendered Scene is exchanged between the UE and the Remote UE.

[0094] [process]

[0095] FIG. 2 is a diagram illustrating an example of an avatar processing block and an avatar media processing procedure according to various embodiments of the present disclosure.

[0096] Referring to Fig. 2, avatar processing blocks that can be considered for expressing a user's facial expressions or gestures as an avatar are indicated by gray blocks, and the processing procedures between them and the main input / output, avatar media, are indicated by white blocks. Each process can be executed in a UE, a network, or a remote UE, and the execution location can be determined as a result of a separate judgment and negotiation process. For example, when executed in a network, it can be executed in an MF (media function) within the network, but is not limited thereto.

[0097] Captured data refers to information such as video, audio, and motion sensors based on the user's facial expressions and / or postures. For example, if User A displays an avatar on a Remote UE that mimics his or her facial expressions and postures, User A's terminal captures User A's facial expressions and postures and generates captured data.

[0098] If a pre-generated Base Avatar isn't available, users can record key facial expressions, dialogue, and other information following the avatar app's instructions. The captured data from the recorded actions is then applied to the Base Avatar Generation module to create a Base Avatar. Base Avatars offer a variety of options, ranging from real-time to requiring hours of post-processing, depending on the solution and quality. Therefore, it's common for them to be created and stored in advance of the avatar call.

[0099] Avatar Storage stores Base Avatars and provides them upon request. For example, when users A and B make an avatar call, Avatar Storage can be the local storage of user A's terminal (UE), the storage on the mobile network (IMS) that mediates the avatar call, the storage of an over-the-top (OTT) operator that mediates the avatar call using the mobile network, or the local storage of user B's terminal (Remote UE) that previously made an avatar call with user A.

[0100] Animation data is generated from captured data and is a command to move the Base Avatar in response to the user's movements. Depending on the technology applied to the Base Avatar, the technology applied to the Animation data may vary. For example, if the Base Avatar is a generative AI model, the Animation data could be a lengthy text description (prompt) acceptable to the AI ​​model. Another example is if the Base Avatar is a 3D graphic model, the Animation data could be a list of XYZ coordinate movement information for moving each point of the graphic object.

[0101] Therefore, the Animation Data Generation (Animation Data Generation Unit) that generates Animation Data can communicate with the Avatar Animation (Avatar Motion Unit) and Avatar Storage to determine whether the technology applied to the Base Avatar and Avatar Animation can support the technology (technology applied to the Base Avatar).

[0102] An Animated Avatar is a Base Avatar modified according to the instructions of Animation Data. As a result of the modification, User A's Animated Avatar can replicate User A's posture and facial expression. The Animated Avatar can be contained within a Scene containing Users A and B, or other users, and objects representing virtual or real spaces. The Renderer generates a Rendered Scene such that the projection plane at a position determined by considering the relative positions of a specific user, such as User B and the Remote UE, with respect to the Scene constitutes all or part of the Remote UE's Display.

[0103] Captured data, Base Avatar, Animation data, Animated Avatar, Scene, and Rendered Scene applied to the aforementioned processing blocks and generated from the processing blocks are collectively referred to as avatar media in this disclosure. In the description of various embodiments of the present disclosure, avatar media may include at least one of Captured data, Base Avatar, Animation data, Animated Avatar, Scene, and Rendered Scene. Unless specifically stated otherwise, media in the description of various embodiments of the present disclosure may be avatar media.

[0104] The aforementioned UE, IMS network, and processing unit can be represented as an architecture as illustrated in FIG. 3, which will be described later. In the present disclosure, descriptions of components of a conventional IMS network that do not require modification are omitted, and additional operations are described for cases where processing blocks specified in the present disclosure are included under the MF (Media Function).

[0105] [IMS Network Structure]

[0106] FIG. 3 is a diagram illustrating an example of a network structure including a data channel server in a communication system according to various embodiments of the present disclosure. Reference is made to the contents of FIGS. 1 and 2, and any duplicate descriptions are omitted.

[0107] Referring to FIG. 3, a UE (User Equipment) can communicate with other UEs and IM CN subsystem components located in a remote IMS network through an IM CN (IP Multimedia Core Network) subsystem. The IM CN subsystem can include a P-CSCF, an I / S-CSCF, an IMS AS, an IMS HSS, an IMS AGW, a DCSF, an MF, a NEF, a DCAS (Data Channel Application Server) and / or a DCAR (Data Channel Application Repository), and the components can perform the following functions.

[0108] - P-CSCF (Proxy Call Session Control Function): P-CSCF can perform the function of the first contact point for UE to access IMS.

[0109] - I / S-CSCF (Interrogating / Serving CSCF): The I-CSCF can function as a point of contact for subscribers of a network operator or roaming users currently located in the network operator's service area. The S-CSCF can handle the actual user session state of the network.

[0110] - IMS AS (Application Server): IMS AS can provide and execute IM (Internet Multimedia) value-added services. Additionally, IMS AS can influence SIP (Session Initiation Protocol) sessions by acting on behalf of services supported by the operator network.

[0111] - IMS HSS (Home Subscriber Server): IMS HSS can act as a database that stores information about users.

[0112] - IMS-AGW (Access Gateway): IMS-AGW is located in the media transmission path and can manage network addresses associated with inbound and outbound media streams.

[0113] - DCSF (Data Channel Signaling Function): It can perform the following functions:

[0114] - Management and control of data channels, including bootstrap data channels.

[0115] - - Data channel management and event creation / reception through communication with IMS AS

[0116] - - Management and distribution control of data channel applications

[0117] - Communication with 5G network functions (NF) for providing data channel application services

[0118] - - Proxy role for resource distribution of data channel application server

[0119] - MF (Media Function): Can perform the following functions:

[0120] - - Management and control of media resources to be transmitted over data channels, including bootstrap data channels.

[0121] - - End point of the data channel connected to the terminal and proxy role for data exchange with other end points

[0122] - NEF (Network Exposure Function): may provide a means to securely expose services and capabilities provided by 3GPP network functions, for example, 3rd party, internal exposure / re-exposure, application functions, and Edge Computing. The NEF may receive information from other NF(s) (based on the exposed capability(s) of other NF(s)). The NEF may store the received information as structured data using a standardized interface to a data storage network function. The stored information may be re-exposed by the NEF to other NF(s) and AF(s) and used for other purposes, such as analysis.

[0123] - DCAS (Data Channel Application Server): It can be located in the IMS operator network or a third-party network. In the present disclosure, the web application provided by the data channel application server can be referred to as a data channel application (DCA). A terminal participating in a service provided by the data channel application (e.g., real-time interaction service) can exchange data required by the service directly or through an intermediate node with another terminal participating in the same service using a data channel (DC: Data Channel), and can communicate with the data channel application server using a bootstrap data channel (BDC).

[0124] - DCAR (Data Channel Application Repository): Data channel applications can be stored and managed, and can be located inside or outside the data channel server.

[0125] The interfaces between the above components can be expressed in IMS as the following reference points.

[0126] - Mb: Reference point supporting IMS media transfer between IMS components

[0127] The interface between the above components can be expressed by the following reference points that support data channel services in IMS.

[0128] - DC1: Reference point between DCSF and IMS AS

[0129] - DC2: Reference point between IMS AS and MF

[0130] - DC4: Reference point between DCSF and DC Application Server

[0131] The interface between the above components can be represented by the following reference points that handle data channel media in IMS.

[0132] - MDC1: Reference point for transmission of data channel media between data channel media function (may be MF) and DCSF.

[0133] - MDC2: Reference point for transferring data channel media between data channel media function (may be MF) and DC Application Server.

[0134] The above SIP is an application layer signaling protocol that specifies the procedures for intelligent terminals that want to communicate on the Internet to identify each other, locate each other, and create, delete, or modify multimedia communication sessions between them. SIP is a request / response structure that controls the creation, modification, and termination of multimedia service sessions such as Internet-based conferences, telephones, voice mail, event notifications, and instant messaging. It can be used on both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). By using a SIP URL (Uniform Resource Locator), similar to an email address, to distinguish each user, services are provided independent of IP addresses. SIP is text-based and was developed using many parts of HTTP (Hypertext Transfer Protocol) and SMTP (Simple Mail Transfer Protocol), making it easy to implement. It also provides the flexibility and extensibility to create various services by combining it with many other protocols used on the Internet. SIP is a simpler protocol corresponding to ITU-T's H.323. It was proposed as RFC 2543 by the IETF (Internet Engineering Task Force) MMUSIC (Multiparty Multimedia Session Control) working group in 1999. Afterwards, a separate IETF SIP working group conducted revision work, and the RFC3261 standard was established in July 2002.

[0135] In order to provide a service (e.g., a real-time interaction service) in a communication system according to various embodiments of the present disclosure, there must be an agreement on the media session that constitutes the service between user UEs participating in the service. In a communication system according to various embodiments of the present disclosure, agreement on the media session may be achieved through Session Description Protocol (SDP) negotiation to provide the service (e.g., a real-time interaction service).

[0136] The above SDP can be included in a SIP message. The SDP is an ASCII-based protocol for describing multimedia sessions and related scheduling information. SDP conveys information about the media streams of a multimedia session so that a session can be joined. A multimedia session is defined as a set of media streams for a duration, and the duration of the session does not need to be continuous. A multicast-based session on the Internet basically has two purposes: a means of notifying the existence and duration of the session and a means of conveying session joining information. In a unicast environment, the latter purpose is the purpose. The SDP information content can include the session name and purpose, session duration, session composition media, and media reception information.

[0137] Hereinafter, various embodiments of the present disclosure are described assuming that the service provided in the communication system is a real-time interaction service, but the present disclosure is not limited thereto.

[0138] [Terminal-Network-Terminal Performance Negotiation Method]

[0139] The information and input / output interfaces provided by each processing block to set up the process flow can be configured as follows in the IMS network.

[0140] FIGS. 4 to 9 are flowcharts illustrating examples of procedures according to various embodiments of the present disclosure. Specifically, FIGS. 4 to 9 illustrate flowcharts for a case where an IMS network, which is an intermediary, determines and executes execution of part or all of an avatar processing block in response to an avatar call request from a UE. Various modifications may be made to the methods illustrated in the flowcharts of FIGS. 4 to 9. For example, although illustrated as a series of steps, the various steps in each drawing may overlap, occur in parallel, occur in different orders, or occur multiple times. In other examples, steps may be omitted or replaced with other steps.

[0141] Referring to FIG. 4, a procedure according to one embodiment of the present disclosure is described.

[0142] 1. The UE sends an INVITE message to the IMS AS for an avatar call with a Remote UE. The message includes a list of avatar media available to the UE (including the applicable solutions, codecs, and profiles).

[0143] 2. The IMS AS stores the list of media received from the UE and adds it to the list of media available on the network after checking it. The IMS AS may store the list of avatar media included in the received INVITE message and / or add it to the list of avatar media available on the network.

[0144] 3. The IMS AS forwards a modified INVITE message to the Remote UE, which includes a list of network-providable media. The IMS AS can generate / obtain a modified INVITE message, which includes a list of network-providable avatar media added to the list of avatar media included in the INVITE message received from the UE, and forward it to the Remote UE.

[0145] 4. The Remote UE selects media available to the Remote UE from the list of received media and responds.

[0146] 5. IMS AS selects and sets the solution to be supported in the network by applying priorities among the media responded from Remote UE and the MF to support it.

[0147] Referring to FIG. 5, step 1 of FIG. 4 can be performed in more detail as follows.

[0148] 1. The UE sends an INVITE message to the IMS AS for an avatar call. The INVITE message includes call type information indicating that the call is an avatar call, identification information that identifies the specific Base Avatar to be used in the avatar call, and a list of solutions applied to the avatar media to be used in the avatar call. The following parameters can be specified, and at least some of them may be included in the INVITE message:

[0149] - 1. Conversation-Type: Specifies the type of call to be conducted. Conventionally, voice, video, etc. can be identified as the types of media included in the session. However, in order to conduct a new third-party call that is not a voice / video call while using conventional media types such as voice and video, it is necessary to separately specify the call type. For example, if the value of the Conversation-Type field is 3gpp-avatar-call, it can indicate that the type of call intended by the UE is an avatar call, even if only voice and video are transmitted.

[0150] - 2. Base-Avatar-Identifier: This is an identifier that can identify the Base Avatar to be used in the call. The identifier can be the identifier for the entire set of components for representing the Base Avatar, or the identifier of a manifest file that describes the set of components. The manifest file can contain information that can identify all or some of the components of the configuration. If Conversation-Type is not used, the presence of the Base-Avatar-Identifier field can be used to determine that the type of call to be conducted is an avatar call.

[0151] - 3. List of Solutions: A list of identifiers for solutions applied to the Base Avatar and Avatar Media. The list of solutions may be provided as a single list of all solutions applied to one or more Avatar Media, or as a sub-property of each Avatar Media within the Avatar Media list.

[0152] - 4. List of Avatar Media Candidate Descriptors: This is a list of profiles and transmission information of avatar media that the UE wishes to provide. The UE can provide at least one avatar media and profile information of the media. The network or remote UE that selects to receive one of the avatar media from the UE executes an appropriate avatar processing block to process the received avatar media. The selection of one of the multiple avatar media provided by the UE is determined by considering the availability of network resources and the user charging system.

[0153] - 5. AvatarMedia-Type: Indicates the type of each avatar media. For example, 3gpp-avatar-media-captured-data, 3gpp-avatar-media-base-avatar, 3gpp-avatar-media-animation-data, 3gpp-avatar-media-animated-avatar, 3gpp-avatar-media-scene, 3gpp-avatar-media-rendered-scene can represent Base Avatar, Animation data, Animated Avatar, Scene, and Rendered Scene, respectively.

[0154] - 6. List of requested QoE metrics: The performance attainment targets (QoE, quality of experience) for an avatar call are specified from end-to-end (UE-mobile network-Remote UE). Alternatively, the resource or performance attainment targets of an avatar processing block created and executed in the network or Remote UE to process each avatar media are indicated as a list of pairs of items (metrics type) and target values. At least some of the following may be included in the List of requested QoE metrics and / or may be understood as requested QoE metrics.

[0155] - - End-to-end-latency: This indicates the difference between the time an event occurs as measured on a terminal and the time the event is displayed on the other terminal.

[0156] - - Sending-UE-processing-delay: Indicates the difference between the time an event occurs as measured at the transmitting terminal and the time the event is transmitted from the terminal to the network.

[0157] - - Sending-UE-delivery-latency: Indicates the delay time when transmitting data between the transmitting terminal and the network.

[0158] Referring to FIG. 6, step 2 of FIG. 4 can be performed in more detail as follows.

[0159] 2-1. The IMS AS determines that the call requested from the UE is an avatar call based on whether the value of Conversation-Type in the INVITE message is 3gpp-avatar-call or the presence of Base-Avatar-Identifier. The IMS AS can determine whether the requested call is an avatar call based on the parameters included in the INVITE message. For example, if the Conversation-Type included in the INVITE message is 3gpp-avatar-call and / or the INVITE message includes Base-Avatar-Identifier, the requested call can be determined to be an avatar call.

[0160] 2-2. IMS AS identifies the list of avatar media available from the UE in the INVITE message, and the profile and solution information applied to each avatar media.

[0161] 2-3. The IMS AS communicates with the DCSF to request identification of whether the avatar processing block, which takes as input the avatar media specified / indicated in the INVITE message of the UE and outputs the avatar media of the subsequent step, can be supported as an MF instance in the network.

[0162] - A mobile network can provide instances (and computing resources) for general purposes, such as media conversion or network computing, and the allocated (or instantiated) instances can execute processes for specific purposes, such as encoding or transcoding.

[0163] - In the IMS network, which is an example of a mobile communication network, the Data Channel Signaling Function (DCSF) is responsible for allocating instances to MFs and managing instance states to execute processes used in the communication process, and the MF can execute MF instances. In Edge computing, which is another example of a mobile communication network, the Edge Enabler Server (EES) can be responsible for allocating instances, and the Edge Application Server (EAS) can be responsible for executing instances. In WebRTC, which is another example of a mobile communication network, the Application Function (AF) is responsible for allocating instances, and the Application Server (AS) is responsible for executing instances.

[0164] - In the case of avatar currency, when DCSF allocates MF instances, it may allocate special-purpose MFs for avatar currency, such as Avatar Storage, ADG (Animation Data Generation), AA (Avatar Animation), SM (Scene Management), BAG (base avatar generation), and Renderer, rather than general-purpose calculations. In addition, it may be considered that an Avatar Processing Block Management (APBM) for managing the above avatar processing blocks is allocated as an MF instance.

[0165] - The IMS AS can build a list of avatar media that can be generated in the network using the list of avatar media indicated as being supported as input from the UE. From the list of input avatar media and the list of output avatar media, a list of combinations of avatar processing blocks that can connect them, i.e., generate output from the input, can be built.

[0166] - IMS AS asks DCSF whether each combination of the list of combinations of avatar processing blocks it has created can be created as an MF instance.

[0167] An IMS AS can request the creation or allocation of one or more integrated MF instances. For example, a resource request function such as Nmf_MRM_Create can be used. The request can include at least some of the following arguments:

[0168] - - Base Avatar Identifier

[0169] - - Avatar Media Candidate Descriptors

[0170] - - List of Solutions

[0171] - - List of Avatar Processing Blocks to be combined

[0172] - - List of requested QoE metrics

[0173] 2-4. DCSF can communicate with HSS and other providers via IMS AS to select MF instance types and resources appropriate for the user's billing system. MF instance types and / or resources can be configured and selected based on the user's billing system. For example, even for the same Renderer instance, allocation of high-spec computing resources may not be permitted for low-cost subscriber plans. Alternatively, the Renderer MF may not be supported by the local operator network in the user's roaming area.

[0174] 2-5. DCSF requests the MF to allocate the combinations requested from the IMS AS as instances.

[0175] - Each combination of avatar processing blocks can be allocated and executed in the form of an MF instance.

[0176] - The MF instance that DCSF requests to be created can be an individual avatar processing block or a concatenation of multiple avatar processing blocks. That is, the processes of ADG, BAG (base avatar generation), AA, AS (Avatar Storage), SM, and Renderer can each be assigned to a different individual MF instance, or an integrated MF instance can be assigned for all possible combinations of cases, such as a combination of ADG and AA, a combination of ADG, AA, and AS, or a combination of ADG, AA, SM, and Renderer, or at least some of all possible combinations.

[0177] 2-6. DCSF can provide, in response to an IMS AS request, a list of avatar media that can be output (generated) for each input avatar media, including individual and aggregate MF instances that have been identified as being capable of being generated in the MF.

[0178] - The list of printable avatar media provided by DCSF includes information about each avatar media and access information for the individual or combined MFs that can create the avatar media.

[0179] Referring to FIG. 7, step 3 of FIG. 4 can be implemented in more detail as follows. FIG. 7 illustrates a portion of the procedure in step 2 of FIG. 4 (a procedure for adding a list of avatar media available on the network). 3-1 and 3-2 of FIG. 7 can also be understood as a portion of the procedure in step 2 of FIG. 4.

[0180] 3-1. The IMS AS analyzes the response received from the DCSF to identify a list of avatar media and profiles that the network can support for each avatar media that can be provided from the UE, as well as access information for individual or aggregated MF instances that can generate the corresponding avatar media.

[0181] 3-2. The IMS AS creates a new INVITE message by adding a list of avatar media that can be supported and generated in the network to the list of avatar media that can be provided from the UE.

[0182] - For example, after the IMS AS receives an INVITE message from the UE in which only captured data among avatar media is transmitted, the IMS AS may receive a response from the DCSF indicating that two types of avatar media, Animation data and Animated Avatar, can be generated.

[0183] - At this time, Animation data is generated from an individual MF instance that supports ADG, and Animated Avatar is generated from an integrated MF instance that supports ADG and AA.

[0184] - IMS AS can provide captured data transmitted from UE, Animation data avatar media transmitted from ADG MF instance, and Animated Avatar avatar media transmitted from ADG-AA integrated MF instance to Remote UE.

[0185] - The unified MF instance may not provide data exchanged between individual MF instances in the form of avatar media for internal data processing. For example, in an example where a first unified MF instance is created with ADG and AA connected, and a second unified MF instance is created with Scene management and a Renderer connected, Animation data between ADG and AA may or may not be created. Similarly, a Scene may or may not be created between Scene management and a Renderer.

[0186] - Avatar Media acts as a standard interface between different Avatar Processing Block solutions, and accordingly, for solutions combining two or more Avatar Processing Blocks, it is up to the solution provider to decide whether intermediate data generated during processing conforms to the Avatar Media standard, whether it is exposed to other processing blocks, etc.

[0187] 3-3. IMS AS sends the INVITE message generated in step 3-2, including the UE's SIP address, to the Remote UE.

[0188] Referring to FIG. 8, step 4 of FIG. 4 can be performed in more detail as follows.

[0189] 4-1. The Remote UE receives the INVITE message and identifies that it is for an avatar call. For example, the Remote UE can identify that the INVITE message is for an avatar call based on at least one of the information / parameters included in the INVITE message.

[0190] 4-2. The Remote UE checks the avatar media list and determines whether the avatar media can be received by the Remote UE. The Remote UE can determine whether the avatar media included in the avatar media list can be received / will be received. For example, at least some of the avatar media included in the avatar media list may be determined to be receivable / will be received, and / or at least some of the avatar media included in the avatar media list may be determined to be unreceivable / will not be received. For example, depending on the type of avatar media, if there are many avatar processing blocks to be processed after reception by the Remote UE or if high performance is required, the Remote UE may select or not select the media based on the performance it can provide.

[0191] 4-3. The Remote UE replies to the IMS AS with a list of avatar media that it determines it will receive. For example, the reply message of the Remote UE may use, but is not limited to, a 200 OK (successful response status code) message. The reply message of the Remote UE may include an avatar media list along with Conversation-Type: 3gpp-avatar-call, which indicates that the Remote UE can receive avatar calls, and the list of avatar media conveys the selection of which avatar media the Remote UE will receive. In other words, the list of avatar media may include avatar media that the Remote UE will receive / select. Alternatively, the reply message of the Remote UE may include an avatar media list but not indicate that it can receive avatar calls.

[0192] Referring to FIG. 9, step 5 of FIG. 4 can be performed in more detail as follows.

[0193] 5-1. IMS AS checks the list of avatar media selected by Remote UE from the reply message (e.g. 200 OK message) received from Remote UE.

[0194] 5-2. IMS AS determines the priority of avatar media. Avatar call services of avatar call service providers and network operators can operate with priority. These priorities can be determined in real time or in advance based on dynamic conditions, such as overall network conditions and computing resource status, or static conditions, such as the user's subscriber plan and the operating costs of processing solutions running within the MF instance. Furthermore, if processing by a determined individual or integrated MF incurs costs such as usage fees, and a limit (e.g., daily data cap) is applied to the corresponding charges, even after the avatar call has been initiated, avatar media connected to another MF instance can be selected through an UPDATE operation if the limit is exceeded.

[0195] 5-3. The IMS AS selects one (or at least some) of the avatar media list presented / selected by the Remote UE according to the above priorities, and selects an individual or integrated MF instance that generates the corresponding avatar media.

[0196] 5-4. The IMS AS notifies the DCSF of the selected MF instance. The MF instance may have been identified as executable by the DCSF, or it may have been allocated but is not running.

[0197] 5-5. DCSF allocates or executes the notified MF and cancels the allocation for the remaining MF.

[0198] 5-6. The IMS AS replies with the selected avatar media to the UE. For example, the IMS AS's reply message may use, but is not limited to, a 200 OK message. The IMS AS's reply message includes information about the MF instance for receiving the avatar media, along with the Conversation-Type: 3gpp-avatar-call attribute, indicating that the IMS AS can receive avatar calls. The IMS AS's reply message may include information about the avatar media selected by the IMS AS and information about the MF instance for the avatar media.

[0199] 5-7. UE transmits avatar media to MF instance.

[0200] 5-8. The MF instance generates output avatar media from the input avatar media received from the UE.

[0201] 5-9. The MF instance transmits the avatar media generated in MF to the Remote UE.

[0202] 5-10. Remote UE processes the avatar processing block inside and outputs the avatar to display on a display device, etc.

[0203] FIGS. 10 to 12 are flowcharts illustrating examples of procedures according to various embodiments of the present disclosure. More specifically, FIGS. 10 to 12 diagrammatically illustrate the process of determining an integrated MF instance of an avatar function according to the aforementioned terminal-network-terminal negotiation.

[0204] Referring to FIGS. 10 to 12, according to one embodiment, one or more types of avatar media that a UE can provide may be specified / indicated / displayed / indicated. These are illustrated by white circles in FIGS. 10 to 12.

[0205] In one embodiment, one or more avatar media may be added that the network can generate using the Media Function. These are depicted by gray circles in FIGS. 10 to 12 .

[0206] According to one embodiment, a Remote UE may select one or more avatar media to receive. In FIGS. 10 to 12 , a case in which a Scene is selected is exemplified.

[0207] According to one embodiment, for the selection of a Remote UE, the network can determine a path (as exemplified by 101, 102, 103, and 104 in FIG. 11) that can be generated from avatar media provided by the UE. The path corresponds to an avatar media processing procedure and can be configured to include at least a portion of avatar processing blocks. The path can be determined / judged based on the type of avatar media that the UE can provide, the avatar media that the network can generate using the Media Function, and / or the avatar media that the Remote UE wishes to receive.

[0208] In one example, if the Remote UE selects a Scene, routes 101, 102, 103, and 104 can be determined to be possible.

[0209] For example, for route 101, captured data provided by the UE can be received from the network, generated as Animation Data, Animated Avatar, and Scene by the MF instance, and transmitted to the Remote UE.

[0210] For example, for route 102, Animation Data provided by UE can be received from the network, created as Animated Avatar and Scene by MF instance, and transmitted to Remote UE.

[0211] For example, for route 103, an Animated Avatar provided by a UE can be received from the network, created as a Scene by an MF instance, and transmitted to a Remote UE.

[0212] For example, for route 104, the Scene provided by the UE can be transmitted to the Remote UE over the network.

[0213] The network can select one of the paths 101, 102, 103, and 104 in Fig. 11. The priority of selection is as described in 5-2.

[0214] The network can create a single unified avatar function (or unified MF instance) for segments that require multiple avatar functions. Figure 12 shows an example of this.

[0215] In one example, 1101, 1102, and 1103 of FIG. 11 may be generated and provided by Avatar Function A, Avatar Function B, and Avatar Function C of FIG. 12, respectively. If the network chooses to provide Avatar Function B, it may negotiate with the UE to have the UE provide Animation Data to the network, negotiate with DCSF, MF, etc. to allocate and execute an MF instance for Avatar Function B, and negotiate with the Remote UE to receive a Scene generated by Avatar Function B.

[0216] [Step 1: How to Identify, Transmit, and Store Data]

[0217] As described above, data transmitted in a multimedia call service, such as avatar calling, which forms the background of the problem to be solved by the present disclosure, is realized by combining Base Avatar, the first-stage data characterized by one-time transmission and reusability, with Animation data, the second-stage data characterized by real-time acquisition, generation, and transmission. Since the first-stage data can be reused in future calls, including the current call, it can be stored for future reuse.

[0218] The location of the Base Avatar storage may be the storage of an avatar communication service provider that mediates communication, a mobile communication network to which the user subscribes, a mobile communication network to which the other party subscribes, the user's terminal, or the other party's terminal. In this disclosure, the storage is referred to as Avatar Storage.

[0219] In a typical video or voice call, specified video or voice data is transmitted after a call negotiation between terminals. However, in one embodiment of the present disclosure, a method for identifying first-stage data is provided, and a step of determining whether data identified as first-stage data is already stored in Avatar Storage is included. If data identified as first-stage data is stored in Avatar Storage, transmission of second-stage data can be initiated without receiving first-stage data. If data identified as first-stage data is not stored in Avatar Storage, transmission of first-stage data can be initiated, and transmission of second-stage data can be initiated after transmission is completed.

[0220] The method for identifying the first stage data in an avatar call according to the present disclosure is as follows:

[0221] - [1] Distinguish the Base Avatar as an identifier.

[0222] - [2] It is distinguished as a manifest file that describes the structure of the Base Avatar.

[0223] - [3] The syntax of the SDP message transmitted by the terminal for avatar calls is distinguished by specifying that some of the contents are in the first stage.

[0224] - The syntax of messages sent by terminals for avatar calls is distinguished by specifying that some content must be transmitted and completed before other content. The content that must be transmitted / completed first can be identified as first-stage data.

[0225] A combination of one or more of the above-described methods may be used, as described in detail below.

[0226] [1] The method to distinguish the Base Avatar as an identifier is as follows.

[0227] Provide a Base_Avatar_Identifier field and indicate an identifier as the field value. The identifier may be a combination of the avatar call service provider identifier, the user identifier, and the user's avatar identifier.

[0228] When a Base_Avatar_Identifier is specified / included in an SDP message transmitted from a transmitting terminal to a receiving terminal or signaling server (e.g., IMS AS in an IMS network, WebRTC Signaling Server in a WebRTC network, etc.), the multipart, session, or media containing the Base_Avatar_Identifier is designated / identified as the first data and is a part, session, or media for transmitting the Base Avatar.

[0229] The first data, i.e. the Base Avatar, is identified to indicate that it must be transmitted prior to the Avatar call, so the receiving terminal or signaling server checks if there is a matching identifier among the previously received Base Avatars, and if it is a Base Avatar that has not been stored, initiates transmission of the corresponding part, session, or media.

[0230] Additionally, since the first data, i.e. the Base Avatar, is identified to indicate that transmission must be completed before the Avatar call is concluded, other parts, sessions, or media are identified as the second data and do not initiate transmission until the transmission of the first data is completed.

[0231] If there is a stored data, the transmission of the second stage data is initiated without receiving it. Accordingly, the transmission of the part, session, or media containing the first data may not be performed.

[0232] [2] The method of distinguishing it as a manifest file that describes the structure of the Base Avatar is as follows.

[0233] The manifest file describes the properties and structure of the Base Avatar and the properties of the component files that make up the Base Avatar. The properties of the Base Avatar may include the Base_Avatar_Identifier.

[0234] When the Base_Avatar_Manifest_URL is specified in a message transmitted from a transmitting terminal to a receiving terminal or signaling server, a manifest for the Base Avatar is received when the manifest indicated by the Base_Avatar_Manifest_URL is received. The Base Avatar may be composed of one or more files, and each file may have one or more alternatives, and the manifest file includes the properties of these files and the properties of their mutual alternative relationships. Accordingly, the receiving terminal or MF of the network can determine whether all or part of the files are stored for the Base Avatar designated for use in avatar calls, and can update all or part of the Base Avatar components by receiving the alternative files specified as the alternative properties.

[0235] Table 1 is an example of a manifest file that represents the properties and components of a Base Avatar.

[0236] [Table 1]

[0237]

[0238] When specifying a Base Avatar to be used in UE, a manifest file is transmitted, and the intermediary and receiver can read the manifest file to determine reception and updates for all or some components.

[0239] Base_Avatar_Identifier is the identifier for the Base Avatar. This identifier may be unique within the user's terminal, unique within the mobile network mediating the avatar call, unique within the avatar call service provider's service, or unique across avatar call service providers.

[0240] Avatar_Service_Provider_Identifier: Provides identification information to identify the avatar call service provider.

[0241] Avatar_Service_Provider_API_URL: Provides the API (Application Programming Interface) URL for connecting to the avatar call service provider server.

[0242] Base_Avatar_Solutions represents the solutions applied to the Base Avatar. One or more solutions are specified as sub-properties.

[0243] Base_Avatar_Solution represents the solution applied to the Base Avatar.

[0244] Base_Avatar_Solution_Provider: Provides provider identification information for the solution applied to the Base Avatar.

[0245] Base_Avatar_Solution_Identifier represents the identifier of the solution. It is an identifier given to the solution by the solution provider and can be unique among solution providers.

[0246] Base_Avatar_Solution_Profile represents a profile within a solution. Even within the same solution, profiles can be distinguished based on the level of functional requirements (e.g., high-quality, low-quality, etc.).

[0247] The User_Identifier is an identifier used to identify the user of the Base Avatar. For universal Base Avatars (i.e., avatars available to anyone), the User_Identifier property may not be provided or may be specified as "common," indicating that it does not belong to a specific user. In cases other than "common," the user can be identified by an identifier unique to the mobile network or within the avatar call service provider's service. Users can provide a Base Avatar without a User_Identifier if they do not want or need it. Even after specifying a User_Identifier, they can delete it by directly modifying the manifest file or sending a Revoke command to the Avatar Storage located on the network, etc.

[0248] Base_URL is not specified by default, but if specified, it can provide an absolute Base for cases where the data location of the component referenced within the manifest file is specified as a relative path. That is, you can combine Base_URL (e.g., https: / 10.10.10.10 / Base / ) with the relative path of the component (e.g., Avatar / Components / Alternatives / file1-1-1.bin) to express https: / 10.10.10.10 / Base / Avatar / Components / Alternatives / file1-1-1.bin as the absolute path of the component.

[0249] Components provides a list of components for the Base Avatar.

[0250] Component provides properties of the components of the Base Avatar.

[0251] Component_ID is the ID of a component of the Base Avatar.

[0252] Component_Type indicates the format of the components of the Base Avatar. The format can be a unique type registered with another international organization, such as MIME_type, or a format unique to the solution provider. Component_Types that can be considered in solutions for avatar currency include scene graph formats such as glTF (GL Transmission Format), USD (Universal Scene Description), MPEG-SD (MPEG (Moving Picture Experts Group)-I Scene Description), or 3D mesh resources such as texture, mesh, occupancy, attribute, skeleton, or motion, haptic, or video, audio.

[0253] Component_Base_URL represents the absolute or relative path of the component of the Base Avatar. If it is an absolute path, the Base_URL in the manifest file is ignored. If it is a relative path, the Base_URL and Component_Base_URL in the manifest file are combined and used as the base of the component path. If Component_Alternative_URL is a relative path, the Base_URL, Component_Base_URL, and Component_Alternative_URL in the manifest file are combined. If Component_Alternative_URL is an absolute path, the Base_URL and Component_Base_URL in the manifest file are ignored.

[0254] Alternatives provide a first plan and an alternative for a Component. A Component can consist of one first plan and alternatives that can replace the first plan. A system (UE, Remote UE, network MF, etc.) including an Avatar Animation unit that generates an Animated Avatar using a Base Avatar and other avatar processing blocks can determine and receive an alternative for a component by considering the reception latency required to receive alternatives for each component of the Base Avatar, processing resources for appropriately processing the received alternative for the component, processing time and energy efficiency, the quality of the generated Animated Avatar, and the display specifications of the Remote UE for displaying it. A network intermediary or Remote UE that has received and stored a Base Avatar from a previous call can analyze the manifest file to compare the Base Avatar stored in the Avatar Storage with the Base Avatar to be used in the current call, determine a more appropriate alternative for the same component, and receive the alternative component.

[0255] Alternative indicates the first option or an alternative to it.

[0256] Alternative_ID is the identifier of the alternative, using an integer system starting from 0. An Alternative_ID value of 0 indicates the first option.

[0257] Component_Alternative_URL indicates an alternative receiving path. As mentioned above, it can be an absolute or relative path.

[0258] Properties provides alternative properties.

[0259] Resolution provides alternative resolution information.

[0260] x is provided for images / videos / 3D (3-dimension) and represents the size of the horizontal axis.

[0261] y is provided for images / videos / 3D and represents the size of the vertical axis.

[0262] z is provided for 3D and represents the size of the z-axis.

[0263] z_min and z_max are provided for depth, and represent the minimum and maximum depth values, respectively.

[0264] Color-space is provided for images / videos and represents the reference color gamut.

[0265] Density is provided for images / videos / 3D, and indicates density information that is relative (e.g. dense or sparse) or absolute (e.g. 300dpi (Dots per inch), 600dpi).

[0266] Codec_Profile represents an alternative encoding profile or profiles.

[0267] File_size represents the size of the alternative file or data.

[0268] Creation_date indicates the creation time of the alternative file or data. A network intermediary or remote UE that received and stores the Base Avatar from a previous call can analyze the manifest file to compare the Base Avatar stored in Avatar Storage with the Base Avatar to be used in the current call. If different times are indicated for the same alternative, the manifest file can be updated to the more recent alternative.

[0269] Version provides version information.

[0270] Major and Minor indicate the versions of the alternative. If different versions of the same alternative are indicated, the recipient can update to the more recent one.

[0271] [3] One example of a method for distinguishing between first-stage and second-stage communication by specifying some content in the syntax of an SDP message transmitted by a terminal for an avatar call is as follows.

[0272] In the present disclosure, Content-Ringing, Content-Required, and Content-Order can be used together with the aforementioned Conversation-Type, Base-Avatar-Identifier, and Base-Avatar-Manifest-URL as instructions for instructing a new action to be performed by the receiving party (terminal, server, etc.) for an avatar call.

[0273] Content-Ringing is intended to indicate when a receiving terminal should initiate user notification of a call request, such as a ringtone. If the value of the Content-Ringing field indicated in a part is After-Completion, the user notification, which would normally be initiated upon transmission and reception of that part, will be initiated after the completion of transmission of that part.

[0274] Content-Required is an attribute of media. For example, if the value of the Content-Required field indicated in a media is Skip-If-Exist, the media will not be transmitted again if it has already been transmitted. Additional attributes of Media may be provided, such as Base-Avatar-Identifier and Base-Avatar-Manifest-URL. The receiving terminal or server can determine whether the Base Avatar has been previously received using the Base-Avatar-Identifier, or determine whether to add or update components after receiving the manifest. If the media has not been received, the media cannot be skipped, and transmission cannot be canceled midway.

[0275] Content-Order is a method for indicating each part as Stage 1 or Stage 2, etc., when providing multipart in SDP. The SDP multipart format is a method for dividing the body into multiple parts using boundaries. The SDP multipart format allows a single message to contain multiple sessions, with each session divided into parts. However, the existing SDP standard does not explicitly define conditions or methods for how each part is connected to each other. In a multipart SDP, each part is interpreted independently, and there are no specific rules for which part should be converted to which other part.

[0276] - Therefore, in order to configure the first and second steps as intended in the present disclosure, to transmit the first step first, and to transmit the second step after the transmission of the first step is completed, additional operation instruction information is required in addition to Multipart.

[0277] - In this disclosure, in order to configure the first and second stages as multipart, stage information is provided for each part. An example is shown in Table 2 below. One example of a method for providing stage information may be to provide Content-Order information for each part. Content-Order:<signed integer> and display it like this<signed integer> You can specify which number of times a part should be executed by assigning an integer value starting from 0 to the value of . The order is from smallest to largest for integer values ​​greater than or equal to 0. If -1 is assigned, it means that the part will not be executed automatically unless otherwise specified.

[0278] - In order to transmit the first step first, the present disclosure can assign a unique number or duplicate numbers to the Content-Order information for each part and provide execution order information according to the size of the numbers. For example, if the Content-order value of one part is 0 and the remaining parts are 1, only the part designated as 0 can be transmitted first, and the remaining parts with a value of 1 can be transmitted. However, as described above, the part with a value of -1 can be excluded from the sequential execution target.

[0279] [Table 2]

[0280]

[0281] One embodiment of a method for constructing a multipart SDP message using the above directives is as follows.

[0282] Multipart can be configured as an SDP message into multiple parts, as shown in Table 2. Or, it can be configured as shown in Table 3.

[0283] [Table 3]

[0284]

[0285] Since the existing standards do not specify explicit conditions or methods for executing transmission by part, the present disclosure uses Conversation-Type: 3gpp-avatar-call as shown in Table 3 to indicate that the call is an avatar call, specifies Content-Order: 0 or 1 for each part to indicate that it is the first and second stages, and specifies Content-Required: Skip-If-Exist for the part corresponding to the first stage to indicate that the transmission of the media belonging to the part cannot be interrupted and does not need to be received again. In addition, Base-Avatar-Identifier and Base-Avatar-Manifest-URL are provided as attributes of the media belonging to the part corresponding to the first stage to provide information for determining and updating whether the Base Avatar is stored.

[0286] Here's how to configure steps 1 and 2 using the directives described above in Multipart / Early Session:

[0287] One of the prior technologies is Early Session among Multipart, which is defined in RFC 3959. According to RFC 3959, when the content of SDP is divided into Multipart, it provides a method to transmit the corresponding part first and then transmit the remaining parts using Content-Disposition: Early-session. The prior technology is characterized in that, upon initiating the Early session, the media (e.g., coloring) designated by the receiver is transmitted to the sender, and at the same time as the sender starts playing the media designated by the receiver, the receiver terminal is notified of an incoming call (a ringtone is generated). When the receiver presses the call button or picks up the handset, the Early session is immediately terminated and a 200 OK message is transmitted from the receiver terminal to the sender terminal.

[0288] When using Early-session to send the Base Avatar before a call begins, which allows for media transmission before the call arrives, the following problems arise. First, since the user's ringtone rings simultaneously with the Base Avatar transmission from the sender to the receiver, the Early-session is immediately interrupted if the recipient presses the call button or picks up the handset. Furthermore, if the recipient is forced to wait for the Base Avatar transmission to complete while the ringtone is still ringing, the Early-session feature becomes meaningless.

[0289] In this disclosure, the aforementioned directive Content-Required:Skip-If-Exist is used as shown in Table 4 to indicate that the Early session is a session for transmitting data that must be completely transmitted.

[0290] [Table 4]

[0291]

[0292] Accordingly, according to one embodiment of the present disclosure, the Early Session is not interrupted even if the user presses the call button or makes an incoming call, and continues until the transmission is completed.

[0293] Additionally, the aforementioned directive, Content-Ringing:After-Completion, is used to instruct that the ringing be initiated after the Early Session transmission is completed. Therefore, a transmitting terminal according to the present disclosure can initiate the ringing after the Base Avatar transmission is completed in the Early Session established following a call request, and can then proceed to the transmission of the second-stage data after the user receives the call.

[0294] FIG. 13 is a diagram comparing Early-session according to various embodiments of the present disclosure with a conventional Early-session. Any content that overlaps with the above description will be omitted.

[0295] Figure 13(a) illustrates a conventional Early session case. When Early media is received, a ringtone is initiated at the receiving terminal. Regardless of the complete transmission of Early media, if the user decides to receive the call, i.e., presses the call button, the transmission of Early media is immediately interrupted. Therefore, it is not suitable for transmission of a Base Avatar.

[0296] Figure 13(b) illustrates that when Content-Required:Skip-If-Exist and Content-Ringing are specified, the receiving terminal does not initiate a ringing sound until transmission is complete, but initiates a ringing sound after transmission is complete, thereby ensuring transmission of early media. Therefore, it is suitable for transmission of Base Avatar.

[0297] [Terminal-Network-Terminal First Data, Second Data Transmission Method]

[0298] Figures 14 through 18e are flowcharts illustrating examples of procedures for avatar calls according to various embodiments of the present disclosure. Various modifications may be made to the methods illustrated in the flowcharts of Figures 14 through 18e. For example, although illustrated as a series of steps, the various steps in each drawing may overlap, occur in parallel, occur in different orders, or occur multiple times. In other examples, steps may be omitted or replaced with other steps.

[0299] The process of executing an avatar call using an Early session between a terminal (UE) and a remote terminal (Remote UE) via the IMS network above is as follows: First, the terminal requests an avatar call with the remote terminal to the IMS network, and the IMS network reuses the Base Avatar indicated to be used in the avatar call if it exists in the network, or transmits and receives it before the call. Next, the IMS network requests an avatar call to the remote terminal, and if the Base Avatar does not exist in the remote terminal, transmits it before the call. The Base Avatar transmitted in the Early session by the indicator is not canceled until the transmission is completed, and the ringtone of the remote terminal is initiated after the transmission is completed.

[0300] Referring to FIGS. 14 to 18e, the detailed process is as follows.

[0301] 1. Referring to FIG. 14, the UE transmits a SIP INVITE message to the IMS AS for an avatar call with a remote UE. The message includes, in addition to a normal call request, type information indicating that it is an avatar call, Conversation-Type, an identifier of the base avatar related to the first stage data, a complete transmission flag, Content-Required:Skip-If-Exist, and session information for transmitting animation data.

[0302] 2. Referring to Figure 15, the IMS AS searches the Avatar Storage to determine whether the corresponding Base Avatar information exists on the network.

[0303] - 2-1. IMS AS->NRF: Find AS (Avatar Storage). For example, you can search for the Avatar Storage feature of MF or search for NF (Network Function) registered as Avatar Storage. As another example, you can search for and query DCSF, not AS, to inquire about the storage of the Base Avatar.

[0304] - - If no search results are found:

[0305] - - - 2-2. NRF->IMS AS: Responds that no NF was found.

[0306] - - - 2-3. IMS AS->DCSF: Requests creation of AS.

[0307] - - - 2-4. DCSF->MF: Transmits AS creation request.

[0308] - - - 2-5. MF?MF: Create AS.

[0309] - - - 2-6. MF<->NRF: Register the created AS with NRF.

[0310] - - - 2-7. MF->DCSF: Returns information about the created AS.

[0311] - - - 2-8. DCSF->IMS AS: Transmits AS information.

[0312] - - If you have:

[0313] - - - 2-9. NRF->IMS AS: Returns the searched AS information.

[0314] 3. Referring to FIGS. 16A to 16C, the IMS AS checks whether data identifiable as a Base-Avatar-Identifier is stored in the Avatar Storage. In another embodiment, if more than one Avatar Storage is available in the IMS network, the DCSF may respond to the request of the IMS AS by querying multiple Avatar Storages.

[0315] - 3-1. IMS->AS: Request to check if there is data with the value of Base-Avatar-Identifier as an identifier.

[0316] - - If not present: Option A / Early-session

[0317] - - - 3-2. AS->IMS AS: Responds that there is none.

[0318] - - - 3-3. IMS AS->AS: Requests storage space allocation for storing the Base Avatar (ID: Base-Avatar-ID, Owner: UE)

[0319] - - - 3-4. AS?AS: Allocates storage space and issues AS-data-ID, which is a storage space identifier. AS-data-ID is an identifier for storage space allocated by the storage, and indicates space allocated and managed by the storage to manage network storage for general purposes, not limited to avatar currency and base avatar.

[0320] - - - 3-5. AS->IMS AS: Returns storage space access information and AS-data-ID.

[0321] - - - 3-6. IMS AS?IMS AS: IMS has identified that it is an Avatar call by Conversation-Type, knows which Base Avatar will be used by Base-Avatar-Identifier, and confirms that there is no Base Avatar in the Avatar Storage, so it decides to create an Early-session to request the transfer of the Base Avatar. IMS AS creates an Early-OFFER and configures the sender to be the UE and the receiver to be the AS.

[0322] - - - 3-7. IMS AS->UE: Sends an Early Offer and requests session establishment by sending an ANSWER that includes only the Data Channel for transmitting the Base Avatar. The Early Offer may request the transmission of an Early ANSWER that includes the Data Channel for transmitting the Base Avatar.

[0323] - - - 3-8. UE->IMS AS: Responds to the transmission request by including Early ANSWER in PRACK (Provisional Response ACK (acknowledgement)). Early ANSWER only includes Early-Session for transmitting Base Avatar. In response to Early OFFER, Early ANSWER including Data Channel for transmitting Base Avatar can be transmitted through PRACK.

[0324] - - - 3-9. IMS AS->AS: Notifies that data identified by the storage space identifier AS-data-ID and Base-Avatar-Identifier is connected. The AS can respond to future storage inquiries using the Base-Avatar-Identifier.

[0325] - - - 3-10. UE->AS: Transmits Base Avatar data.

[0326] - - - 3-11. AS->UE: When transmission is complete, reply OK.

[0327] - - - 3-12. UE->IMS AS: Transmit ACK.

[0328] - - - 3-13. IMS AS->AS: ACK is transmitted. AS considers the storage of the Base Avatar to be complete in the storage space identified by AS-data-ID.

[0329] - - If not present: Option B / SIP UPDATE

[0330] - - - 3-14. AS->IMS AS: None. Notifies that there is no Base Avatar found.

[0331] - - - 3-15. IMS AS->AS: Requests storage space allocation for storing the Base Avatar (ID: Base-Avatar-ID, Owner: UE)

[0332] - - - 3-16. AS?AS: Allocates storage space and issues AS-data-ID, which is a storage space identifier.

[0333] - - - 3-17. AS->IMS AS: Repository Access Information and AS-data-ID Reply

[0334] - - - 3-18. IMS AS?IMS AS: Since the IMS AS has identified that this is an Avatar call by Conversation-Type and knows which Base Avatar will be used by Base-Avatar-Identifier, and since it has confirmed that there is no Base Avatar in the Avatar Storage, it decides to request the UE to send the Base Avatar. The IMS AS creates an ANSWER requesting the reception of the Base Avatar and configures it so that the sender is the UE and the receiver is the AS.

[0335] - - - 3-19. IMS AS->AS: Notifies that data identified by the storage space identifier AS-data-ID and the Base-Avatar-Identifier is connected. The AS can respond to future storage inquiries using the Base-Avatar-Identifier.

[0336] - - - 3-20. IMS AS->UE: Requests session establishment by sending an ANSWER containing only the Data Channel for transmitting the Base Avatar. The ANSWER may include the Data Channel for transmitting the Base Avatar. The receiving side is the AS.

[0337] - - - 3-21. UE?UE: Determines whether there is an abnormality in the IMS request.

[0338] - - - - If there is any abnormality

[0339] - - - - - 3-22. UE->IMS AS: Sends a SIP UPDATE message with some attributes modified. Normally, no ANSWER is required.

[0340] - - - - If there is no abnormality

[0341] - - - - - 3-23. UE->AS: Transmits Base Avatar data.

[0342] - - - - - 3-24. AS->UE: When transmission is complete, reply OK.

[0343] - - - - - 3-25. UE->IMS AS: Transmit ACK.

[0344] - - - - - 3-26. IMS AS->AS: ACK is transmitted. AS considers the storage of the Base Avatar to be complete in the storage space identified by AS-data-ID.

[0345] - - If there is

[0346] - - - 3-27. AS->IMS AS: Responds to the request for confirmation that the requested Base Avatar exists. The response includes information indicating that it is being stored / managed (e.g., true / false), information about the Base Avatar (e.g., at least one of the Base-Avatar-Identifier, Base Avatar data, data version information, and data storage time).

[0347] 4. Referring to FIG. 17, the IMS AS creates / obtains / generates an Avatar call request to be delivered to the Remote UE. The SIP INVITE message created / obtained / generated by the IMS AS includes Conversation-Type, which is type information indicating that it is an Avatar call requested by the UE, Base-Avatar-Identifier, which is an identifier of the Base Avatar related to the first stage data, Content-Required:Skip-If-Exist, which is a complete transmission flag, and / or session information for transmitting Animation data.

[0348] - 1. Option A / Early Session

[0349] - - IMS AS->Remote UE: Transmits Base-Avatar-Identifier, which is the first stage data, and second stage data transmission information (session information). This is to enable the receiving side according to the present disclosure to determine whether the first stage data is necessary and, if necessary, request an early session to receive it. The INVITE message includes Conversation-Type: 3gpp-avatar-call, Base-Avatar-Identifier, Content-Required: Skip-If-Exist, and / or Content-Ringing: After-Completion to instruct an action for the first stage data.

[0350] - 2. Option B / SIP UPDATE

[0351] - - IMS AS->Remote UE: Transmits data channel information for receiving the Base-Avatar-Identifier and Base Avatar, which are the first-stage data, and second-stage data transmission information (session information). This is to enable the receiving side according to the present disclosure to determine whether the first-stage data is necessary and, if not necessary, not to receive the corresponding session. The INVITE message includes Conversation-Type: 3gpp-avatar-call, Base-Avatar-Identifier, Content-Required: Skip-If-Exist, and Content-Ringing: After-Completion to instruct an action for the first-stage data.

[0352] 5. Referring to FIGS. 18a to 18e, the Remote UE searches the Avatar Storage within the Remote UE to determine whether it has received and stored the Base Avatar from a previous Avatar call.

[0353] - 5-1. Remote UE--Remote UE: Check if there is data with the value of Base-Avatar-Identifier as an identifier.

[0354] - - If not, Option A / Early Session

[0355] - - - 5-2. Remote UE->IMS AS: Remote UE requests an early session to transmit the base avatar to IMS.

[0356] - - - 5-3. IMS AS->Remote UE: IMS AS UPDATE to insert Ringing and Skip related tags Content-Required:Skip-If-Exist, Content-Ringing: After-Completion

[0357] - - - 5-4. Remote UE->AS: Request to send Base Avatar to AS

[0358] - - - 5-5. AS->Remote UE: Base Avatar transmission.

[0359] - - - 5-6. Remote UE--Remote UE: According to Content-Ringing: After-Completion, the Remote UE does not ring until transmission is complete and waits for the ringing sound until completion.

[0360] - - - 5-7. Remote UE--Remote UE: Ringing starts upon completion of transmission

[0361] - - - 5-8. Remote UE--Remote UE: User call reception

[0362] - - - 5-9. Remote UE->IMS AS: User incoming signal transmission (e.g. 200 OK)

[0363] - - - 5-10. IMS AS->UE: User incoming signal transmission (e.g. 200 OK)

[0364] - - - 5-11. UE->Remote UE: Animation data transmission begins

[0365] - - - 5-12. UE->(MF)->Remote UE: Initiate transmission of data generated from MF.

[0366] - - If not present, Option B / SIP UPDATE

[0367] - - - 5-13. Remote UE->IMS AS: The Remote UE transmits an ANSWER containing only the Base Avatar transmission to the IMS AS. The transmission of the second stage data does not begin until the Base Avatar transmission is complete.

[0368] - - - 5-14. IMS AS->Remote UE: A reply message (e.g. 200 OK) is sent.

[0369] - - - 5-15. Remote UE->AS: Request to send Base Avatar to AS

[0370] - - - 5-16. AS->Remote UE: Base Avatar transfer.

[0371] - - - 5-17. Remote UE--Remote UE: According to Content-Ringing: After-Completion, the Remote UE does not ring until transmission is completed, and starts ringing after completion.

[0372] - - - 5-18. Remote UE--Remote UE: Ringing starts upon completion of transmission

[0373] - - - 5-19. Remote UE--Remote UE: User call reception

[0374] - - - 5-20. Remote UE->IMS AS: User incoming signal transmission (e.g. 200 OK)

[0375] - - - 5-21. IMS AS->UE: User incoming signal transmission (e.g. 200 OK)

[0376] - - - 5-22. UE->Remote UE: Animation data transmission begins

[0377] - - - 5-23. UE->(MF)->Remote UE: Initiate transmission of data generated from MF.

[0378] - - If not available, send together with Option B2

[0379] - - - The Remote UE transmits the first data and the second data simultaneously. According to Content-Ringing: After-Completion, the ringtone does not sound until the first data is completely received. After the ringtone is initiated, the first data and the second data can be combined and played simultaneously with the user's incoming call.

[0380] - - - 5-24. Remote UE ->IMS AS: Transmit ANSWER containing both step 1 and step 2 data

[0381] - - - 5-25. IMS AS->AS: ANSWER transmission

[0382] - - - 5-26. IMS AS->UE: ANSWER delivery

[0383] - - - 5-27. AS->Remote UE: Base Avatar Transfer

[0384] - - - 5-28. Remote UE--Remote UE: Start ringing when transmission is complete

[0385] - - - 5-29. Remote UE--Remote UE: User call reception

[0386] - - - 5-30. Remote UE->IMS AS: User incoming signal transmission (e.g. 200 OK)

[0387] - - - 5-31. IMS AS->UE: User incoming signal transmission (e.g. 200 OK)

[0388] - - - 5-32. UE->Remote UE: Animation data transmission begins

[0389] - - - 5-33. UE->(MF)->Remote UE: Initiate transmission of data generated from MF

[0390] - - If there is

[0391] - - - 5-34. Remote UE--Remote UE: Start ringing

[0392] - - - 5-35. Remote UE--Remote UE: User Incoming Call

[0393] - - - 5-36. Remote UE->IMS AS: User incoming signal delivery (e.g. 200 OK)

[0394] - - - 5-37. IMS AS->UE: User incoming signal transmission (e.g. 200 OK)

[0395] - - - 5-38. UE->Remote UE: Animation data transmission begins

[0396] - - - 5-39. UE->(MF)->Remote UE: Initiate transmission of data generated from MF.

[0397] Fig. 19 illustrates an example of the functional structure of a terminal according to embodiments of the present disclosure. The configuration illustrated in Fig. 19 may be understood as the configuration of the transmitter terminal and / or receiver terminal described above. Terms such as "...unit" and "...unit" used hereinafter refer to a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software.

[0398] Referring to FIG. 19, the terminal includes a communication unit (1905), a storage unit (1910), and a control unit (1915).

[0399] The communication unit (1905) performs functions for transmitting and receiving signals via a wireless channel. For example, the communication unit (1905) performs a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the communication unit (1905) generates complex symbols by encoding and modulating the transmission bit stream. In addition, when receiving data, the communication unit (1905) restores the reception bit stream by demodulating and decoding the baseband signal. In addition, the communication unit (1905) upconverts the baseband signal to an RF band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna to a baseband signal. For example, the communication unit (1905) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc.

[0400] Additionally, the communication unit (1905) may include multiple transmit / receive paths. Furthermore, the communication unit (1905) may include at least one antenna array composed of multiple antenna elements. In terms of hardware, the communication unit (1905) may be composed of digital circuits and analog circuits (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuits and analog circuits may be implemented in a single package. Additionally, the communication unit (1905) may include multiple RF chains. Furthermore, the communication unit (1905) may perform beamforming.

[0401] The communication unit (1905) transmits and receives signals as described above. Accordingly, all or part of the communication unit (1905) may be referred to as a "transmitter," a "receiver," or a "transmitting and receiving unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean processing performed by the communication unit (205) as described above.

[0402] The storage unit (1910) stores data such as basic programs, application programs, and setting information for the operation of the terminal. The storage unit (1910) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (210) provides stored data upon request from the control unit (1915).

[0403] The control unit (1915) controls the overall operations of the terminal. For example, the control unit (1915) transmits and receives signals through the communication unit (1905). In addition, the control unit (1915) records and reads data in the storage unit (1910). In addition, the control unit (1915) can perform the functions of the protocol stack required by the communication standard. To this end, the control unit (1915) may include at least one processor or microprocessor, or may be a part of a processor. In addition, a part of the communication unit (1905) and the control unit (1915) may be referred to as a CP (communication processor). According to various embodiments, the control unit (1915) may control the terminal to perform synchronization using a wireless communication network. For example, the control unit (1915) may control the terminal to perform operations according to various embodiments described below.

[0404] According to various embodiments of the present disclosure, a terminal may be composed of a mobile equipment (ME) and a universal mobile telecommunications service (UMTS) subscriber identity module (USIM). The ME may include a mobile terminal (MT) and terminal equipment (TE). The MT may be a part where a wireless access protocol operates, and the TE may be a part where a control function operates. For example, in the case of a wireless communication terminal (e.g., a mobile phone), the MT and the TE may be integrated, and in the case of a laptop, the MT and the TE may be separated. The present disclosure may express the ME and the USIM as distinct entities depending on the operation of each component, but is not limited thereto, and may express the ME and the USIM as a terminal (e.g., UE) including the ME, or it is of course possible to describe various embodiments of the present disclosure by expressing the ME as a terminal.

[0405] FIG. 20 illustrates an example of a functional structure of a core network object according to embodiments of the present disclosure. It illustrates a configuration of a core network object in a wireless communication system according to various embodiments of the present disclosure. The configuration illustrated in FIG. 20 can be understood as a configuration of a device having the function of at least one of the network entities including the NF (network function) in the description of various embodiments of the present disclosure described above. Terms such as '... unit', '... device', etc. used hereinafter mean a unit that processes at least one function or operation, and this can be implemented by hardware, software, or a combination of hardware and software.

[0406] Referring to FIG. 20, the core network object is configured to include a communication unit (2040), a storage unit (2045), and a control unit (2050).

[0407] The communication unit (2040) provides an interface for communicating with other devices within the network. That is, the communication unit (2040) converts a bit string transmitted from a core network object to another device into a physical signal, and converts a physical signal received from another device into a bit string. That is, the communication unit (2040) can transmit and receive signals. Accordingly, the communication unit (2040) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit (2040) enables the core network object to communicate with other devices or systems via a backhaul connection (e.g., wired backhaul or wireless backhaul) or via a network.

[0408] The storage unit (2045) stores data such as basic programs, application programs, and configuration information for the operation of the core network object. The storage unit (2045) may be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (2045) provides the stored data upon request from the control unit (2050).

[0409] The control unit (2050) controls the overall operations of the core network object. For example, the control unit (2050) transmits and receives signals through the communication unit (2040). Additionally, the control unit (2050) records and reads data from the storage unit (2045). For this purpose, the control unit (2050) may include at least one processor. According to various embodiments of the present disclosure, the control unit (2050) may control synchronization using a wireless communication network. For example, the control unit (2050) may control the core network object to perform operations according to various embodiments described below.

[0410] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0411] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure.

[0412] These programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage device, magnetic cassette. Or, they may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0413] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network, such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0414] In the specific embodiments of the present disclosure described above, components included in one embodiment are expressed singularly or plurally, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in plural may be composed of singular elements, or components expressed in singular may be composed of plural elements.

[0415] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples to easily explain the technical content of the present disclosure and facilitate understanding of the present disclosure, and are not intended to limit the scope of the present disclosure. In other words, it will be apparent to those skilled in the art to which the present disclosure pertains that other modifications based on the technical concept of the present disclosure are possible. Furthermore, each of the above embodiments can be combined and operated as needed.

[0416] Meanwhile, the order of description in the drawings explaining the method of the present disclosure does not necessarily correspond to the order of execution, and the order of precedence may be changed or executed in parallel.

[0417] Alternatively, the drawings illustrating the method of the present disclosure may omit some components and include only some components without detracting from the essence of the present disclosure.

[0418] In addition, the method of the present disclosure may be implemented by combining some or all of the contents included in each embodiment within a scope that does not harm the essence of the present disclosure.

[0419] Various embodiments of the present disclosure have been described above. The foregoing description of the present disclosure is for illustrative purposes only, and the embodiments of the present disclosure are not limited to the disclosed embodiments. Those skilled in the art will appreciate that the present disclosure can be readily modified into other specific forms without altering the technical spirit or essential characteristics of the present disclosure. The scope of the present disclosure is indicated by the claims described below rather than the detailed description above, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included within the scope of the present disclosure.

Claims

1. A method performed by a device included in a core network in a communication system, A step of receiving a first message for an avatar call between the first terminal and the second terminal from the first terminal, the first message including a first avatar media list available in the first terminal in relation to the avatar call; Updating said first message to further include a list of second avatar media that can be provided by said core network in connection with said avatar currency; A step of transmitting the updated first message to the second terminal; A step of receiving a second message from the second terminal, wherein each avatar media is included in the first avatar media list or the second avatar media list; and A method comprising the step of establishing said avatar currency based on said one or more avatar media.

2. In paragraph 1, Further comprising a step of confirming that the call requested from the first terminal is the avatar call based on the first message, wherein the confirmation that it is the avatar call is as follows: The call type information included in the first message indicates that the call requested from the first terminal is the avatar call, or A method based on the first message including instruction information for a base avatar associated with the avatar call.

3. In paragraph 1, A method according to claim 1, wherein said first message further comprises a list of solutions related to said base avatar or said first avatar media list associated with said avatar call and a type of each avatar media included in said first avatar media.

4. In paragraph 1, A method wherein one or more MF (media function) instances for the avatar call are allocated on the core network, each MF instance corresponding to one or more of AS (avatar storage), ADG (animation data generation), AA (avatar animation), BAG (base avatar generation), SM (scene management), Renderer or APBM (avatar processing block management), and the second avatar media list is associated with the one or more MF instances.

5. In paragraph 1, The above avatar call is based on first data including a base avatar related to the avatar call and second data including avatar movement commands related to the avatar call, The first data is indicated based on the instruction information for the base avatar related to the avatar call included in the updated first message or the content order information related to the avatar call included in the updated first message, A method according to claim 1, wherein the updated first message further includes information instructing to skip reception of the corresponding data if the corresponding data is stored.

6. In a device included in a core network in a communication system, Transmitter and receiver; and A processor coupled to the transceiver, the processor comprising: Receiving a first message for an avatar call between the first terminal and the second terminal from the first terminal, the first message including a first avatar media list available in the first terminal in relation to the avatar call; Update said first message to further include a list of second avatar media that can be provided by said core network in connection with said avatar currency; Transmitting the above updated first message to the second terminal; Receiving a second message from the second terminal, wherein each avatar media is included in the first avatar media list or the second avatar media list; and A device configured to establish said avatar currency based on said one or more avatar media.

7. In paragraph 6, Further comprising a step of confirming that the call requested from the first terminal is the avatar call based on the first message, wherein the confirmation that it is the avatar call is as follows: The call type information included in the first message indicates that the call requested from the first terminal is the avatar call, or A device based on the first message including instruction information for a base avatar associated with the avatar call.

8. In paragraph 6, A device wherein said first message further comprises a list of solutions related to said base avatar or said first avatar media list associated with said avatar call and a type of each avatar media included in said first avatar media.

9. In paragraph 6, A device wherein one or more MF (media function) instances for the avatar call are allocated on the core network, each MF instance corresponding to one or more of AS (avatar storage), ADG (animation data generation), AA (avatar animation), BAG (base avatar generation), SM (scene management), Renderer or APBM (avatar processing block management), and the second avatar media list is associated with the one or more MF instances.

10. In paragraph 6, The above avatar call is based on first data including a base avatar related to the avatar call and second data including avatar movement commands related to the avatar call, The first data is indicated based on the instruction information for the base avatar related to the avatar call included in the updated first message or the content order information related to the avatar call included in the updated first message, A device wherein the updated first message further includes information instructing to skip reception of the corresponding data if the corresponding data is stored.

11. In a method performed by a first terminal in a communication system, A step of transmitting a first message for an avatar call between the first terminal and the second terminal to the second terminal through a core network, the first message including a first avatar media list available in the first terminal in relation to the avatar call; A step of receiving the above avatar currency from the core network; and Comprising the steps of performing the above avatar call, A method wherein said avatar currency is based on one or more avatar media, each avatar media being included in a first avatar media list or a second avatar media list available to the core network.

12. In paragraph 11, Based on the first message, it is indicated that the call requested from the first terminal is the avatar call, and the indication that it is the avatar call is: The call type information included in the first message indicates that the call requested from the first terminal is the avatar call, or A method based on the first message including instruction information for a base avatar associated with the avatar call.

13. In paragraph 11, The first message is updated in the core network to further include the second avatar media list and transmitted to the second terminal, A method according to claim 1, wherein said first message further comprises a list of solutions related to said base avatar or said first avatar media list associated with said avatar call and a type of each avatar media included in said first avatar media.

14. In the first terminal of the communication system, Transmitter and receiver; and A processor coupled to the transceiver, the processor comprising: Transmitting a first message for an avatar call between the first terminal and the second terminal to the second terminal through a core network, the first message including a first avatar media list available in the first terminal in relation to the avatar call; Receive the above avatar currency from the above core network; and is set to perform the above avatar call, A first terminal, wherein the above avatar currency is based on one or more avatar media, each avatar media being included in the first avatar media list or the second avatar media list provided by the core network.

15. In paragraph 14, Based on the first message, it is indicated that the call requested from the first terminal is the avatar call, and the indication that it is the avatar call is: The call type information included in the first message indicates that the call requested from the first terminal is the avatar call, or A first terminal based on the first message including instruction information for a base avatar related to the avatar call.

Images