Method and apparatus for managing storage and access of user data in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. The present disclosure relates to a wireless communication system and, more particularly, to a method for acquiring an avatar identity (ID) list from an avatar repository through a network, selecting an avatar ID from the avatar ID list, acquiring avatar data associated with the avatar ID from the avatar repository through the network, generating avatar media on the basis of the avatar data and animation data, and transmitting the avatar media to a second UE, and an apparatus therefor.

Description

Method and device for managing storage and access of user data in a wireless communication system

[0001] The present disclosure relates to a method and apparatus for managing storage and access of user data in a wireless communication system.

[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] To meet the growing demand for wireless data traffic following the commercialization of 4G communication systems, efforts are being made to develop improved 5G or pre-5G communication systems. For this reason, 5G or pre-5G communication systems are also referred to as "Beyond 4G Network" or "Post-LTE" systems. The 5G communication system specified by 3GPP is called the New Radio (NR) system.

[0009] To achieve high data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., the 60 GHz band). To mitigate radio path loss and increase the transmission range of radio waves in ultra-high frequency bands, beamforming, massive MIMO (massive MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antenna technologies have been discussed and applied to NR systems in 5G communication systems.

[0010] Additionally, to improve the network of the system, technologies such as evolved small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation are being developed in 5G communication systems.

[0011] In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed in 5G systems.

[0012] Meanwhile, the Internet is evolving from a human-centric network where humans create and consume information to an Internet of Things (IoT) network where information is exchanged and processed between distributed components, such as objects. The Internet of Everything (IoE) is also emerging, combining IoT technologies with big data processing technologies, such as those connected to cloud servers. To implement the IoT, technological elements such as sensing technologies, wireless and wired communication and network infrastructure, service interface technologies, and security technologies are required. Recently, research is being conducted on technologies such as sensor networks, Machine-to-Machine (M2M), and Machine-Type Communication (MTC) for connecting objects. In the IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated from connected objects to create new value for human life. IoT can be applied to areas such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services through the convergence and integration of existing IT (Information Technology) technologies with various industries.

[0013] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, 5G communication such as sensor networks, machine-to-machine (M2M), and machine-type communication (MTC) are being implemented using techniques such as beamforming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN), a big data processing technology described above, can also be considered an example of the convergence of 5G and IoT technologies.

[0014] One embodiment of the present disclosure may provide a device and method capable of providing an IMS (Internet Protocol Multimedia Subsystem) data channel-based service experience in a wireless communication system.

[0015] As one aspect of the present disclosure, a method performed by a first UE (User Equipment) in a wireless communication system is provided, the method comprising: obtaining a list of avatar IDs (identities) from an avatar repository through a network; selecting an avatar ID from the list of avatar IDs; obtaining avatar data associated with the avatar ID from the avatar repository through the network; generating avatar media based on the avatar data and animation data; and transmitting the avatar media to a second UE.

[0016] As one aspect of the present disclosure, in a wireless communication system, a first UE (user equipment) includes a transceiver; and at least one processor coupled to the transceiver, wherein the at least one processor is configured to obtain a list of avatar IDs (identities) from an avatar repository through a network, select an avatar ID from the list of avatar IDs, obtain avatar data associated with the avatar ID from the avatar repository through the network, generate avatar media based on the avatar data and animation data, and transmit the avatar media to a second UE.

[0017] FIG. 1 illustrates a 5G system structure according to one embodiment of the present disclosure.

[0018] FIG. 2 illustrates an Internet Protocol Multimedia Subsystem (IMS) network structure according to one embodiment of the present disclosure.

[0019] FIG. 3 illustrates an example of a network structure including a data channel server in a communication system according to one embodiment of the present disclosure.

[0020] FIG. 4 illustrates an example of a network structure including a connection relationship between a 5G core network and an IMS network in a communication system according to one embodiment of the present disclosure.

[0021] FIG. 5 illustrates an example of a negotiation procedure between a User Equipment (UE) and an IMS Core Network (CN) for the ability to support storage and access of data in a communication system according to one embodiment of the present disclosure.

[0022] FIGS. 6A and 6B illustrate examples of procedures between an Application Function (AF) and a 5GS / IMS CN for managing application information that supports storage and access of data in a communication system according to one embodiment of the present disclosure.

[0023] FIGS. 7a, 7b, and 7c illustrate examples of authentication procedures between a UE and an IMS CN to support storage and access of data in a communication system according to one embodiment of the present disclosure.

[0024] FIG. 8 illustrates the structure of a UE according to one embodiment of the present disclosure.

[0025] FIG. 9 illustrates the structure of a network entity according to one embodiment of the present disclosure.

[0026] FIG. 10 illustrates a flowchart for UE operation according to one embodiment of the present disclosure.

[0027] FIG. 11 illustrates a flowchart for S-CSCF operation according to one embodiment of the present disclosure.

[0028] FIG. 12 illustrates a flowchart for a DCSF operation according to one embodiment of the present disclosure.

[0029] FIG. 13 illustrates an example of a network structure including a data channel server and an avatar data storage in a communication system according to one embodiment of the present disclosure.

[0030] FIG. 14 illustrates an example of a procedure between a UE and an IMS CN for supporting a registration procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0031] FIGS. 15a, 15b, and 15c illustrate examples of procedures between a UE and an IMS CN for establishing a Bootstrap DC session for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0032] FIGS. 16a and 16b illustrate examples of procedures between a UE and an IMS CN for performing an Application DC session establishment procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0033] FIGS. 17a and 17b illustrate examples of a negotiation procedure between a UE and an IMS CN for performing an Application DC session establishment procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0034] FIG. 18 illustrates an example of a procedure between a UE and an IMS CN for performing a UE-centric avatar communication establishment procedure based on an IMS service in a communication system according to one embodiment of the present disclosure.

[0035] FIGS. 19a and 19b illustrate examples of negotiation procedures between a UE and an IMS CN for performing a network-centric avatar communication establishment procedure based on an IMS service in a communication system according to one embodiment of the present disclosure.

[0036] The operating principle of the present invention will be described in detail with reference to the attached drawings below.

[0037] In describing the embodiments, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to avoid obscuring the gist of the present disclosure by omitting unnecessary explanations and to convey the gist more clearly.

[0038] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0039] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the present disclosure is complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined solely by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0040] At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0041] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0042] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. In addition, the components and '~units' may be implemented to play one or more CPUs (Central Processing Units) within the device or secure multimedia card. In addition, in the embodiment, the '~unit' may include one or more processors.

[0043] The terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, and terms referring to various identification information are provided for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms referring to objects with equivalent technical meanings may be used.

[0044] For convenience of explanation, this disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP) LTE (3rd Generation Partnership Project Long Term Evolution) standard and the 3GPP 5G standard. However, the present invention is not limited to these terms and names and can be equally applied to systems conforming to other standards.

[0045] Hereinafter, preferred embodiments of the present disclosure will be described in detail with reference to the attached drawings. It should be noted that, where possible, identical components are represented by identical reference numerals throughout the attached drawings. Furthermore, the attached drawings of the present disclosure are provided to aid understanding of the present disclosure, and it should be noted that the present invention is not limited to the forms or arrangements illustrated in the drawings.

[0046] FIG. 1 illustrates a 5G system structure according to one embodiment of the present disclosure.

[0047] Referring to FIG. 1, the 5G system architecture may include various components (i.e., network functions (NFs)). FIG. 1 illustrates some of them, including an authentication server function (AUSF) device (110), an access and mobility management function (AMF) device (103), a session management function (SMF) device (104), a policy control function (PCF) device (107), an application function (AF) device (108), a unified data management (UDM) device (106), a data network (DN) (112), a user plane function (UPF) device (105), a (radio) access network (R)AN) (102), and a terminal, i.e., a user equipment (UE) (101). In addition, in FIG. 1, a Network Slice Selection Function (NSSF) device (109) and a Network Slice Specific Authentication and Authorization Function (NSSAAF) device (111) are exemplarily illustrated.

[0048] Each of the devices illustrated in FIG. 1 may be implemented as a single server or device, or as a network slice instance. When implemented as a network slice instance, two or more identical or different network slice instances may be implemented within a single server or device, or a single network slice instance may be implemented across two or more servers or devices.

[0049] Each NF can support the following functions:

[0050] AUSF (110) can process and store data for UE authentication.

[0051] AMF (103) can provide functions for access and mobility management per UE, and one UE can be connected to one AMF by default. Specifically, the AMF (103) provides signaling between core network (CN) nodes for mobility between 3GPP access networks, termination of radio access network (RAN) Control Plane (CP) interface (i.e., N2 interface), termination (N1) of Non Access Stratum (NAS) signaling, NAS signaling security (NAS ciphering and integrity protection), Access Stratum (AS) security control, registration management (registration area management), connection management, idle mode UE reachability (including control and performance of paging retransmission), mobility management control (subscription and policy), intra-system mobility and inter-system mobility support, support for network slicing, SMF selection, lawful intercept (for AMF events and interfaces to LI systems), provision of forwarding of session management (SM) messages between UE and SMF, and transparent routing of SM messages. It may support functions such as transparent proxy, access authentication, access authorization including roaming permission check, provision of SMS message delivery between UE and Short Message Service Function (SMSF), security anchor function (SAF) and / or security context management (SCM).Some or all of these AMF (103) functions may be supported within a single AMF instance operating as one AMF.

[0052] DN (112) may mean, for example, an operator service, Internet access, or a third-party service. DN (112) may transmit a downlink protocol data unit (PDU) to UPF (105) or receive a PDU transmitted from UE (101) through UPF (105).

[0053] PCF (107) can receive information about packet flow from an application server and provide a function to determine policies such as mobility management and session management. Specifically, PCF (107) can support functions such as supporting a unified policy framework for controlling network operations, providing policy rules so that control plane functions (e.g., AMF, SMF, etc.) can enforce the policy rules, and implementing a front end for accessing related subscription information for policy determination within a user data repository (UDR).

[0054] The SMF (104) provides session management functions, and when a UE has multiple sessions, each session can be managed by a different SMF. Specifically, the SMF (104) can support functions such as session management (e.g., session establishment, modification, and termination, including tunnel maintenance between the UPF and the AN node), UE IP address allocation and management (optionally including authentication), selection and control of UP functions, traffic steering configuration for routing traffic from the UPF to the appropriate destination, termination of interfaces toward policy control functions, enforcement of the control portion of policies and QoS (quality of service), lawful intercept (for SM events and interfaces to the LI system), termination of the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information (delivered to the AN via N2 via the AMF), determination of the SSC mode of the session, and roaming functions. As described above, some or all of the functions of SMF (104) may be supported within a single SMF instance operating as a single SMF.

[0055] The UDM (106) can store user subscription data, policy data, etc. The UDM (106) can include two parts, namely, an application front end (FE) (not shown) and a user data repository (UDR) (not shown).

[0056] The FE may include a UDM FE, which is responsible for location management, subscription management, and credential processing, and a PCF-FE, which is responsible for policy control. The UDR may store data required for the functions provided by the UDM-FE and policy profiles required by the PCF. Data stored in the UDR may include user subscription data and policy data, including subscription identifiers, security credentials, access and mobility-related subscription data, and session-related subscription data. The UDM-FE may access subscription information stored in the UDR and support functions such as authentication credential processing, user identification handling, access authentication, registration / mobility management, subscription management, and SMS management.

[0057] UPF (105) can transmit a downlink PDU received from DN (112) to UE (101) via (R)AN (102), and can transmit an uplink PDU received from UE (101) via (R)AN (102) to DN (112). Specifically, the UPF (105) may support an anchor point for intra / inter RAT mobility, an external PDU session point for interconnection to a Data Network, a user plane portion of packet routing and forwarding, packet inspection and policy rule enforcement, an uplink classifier to support lawful intercept, traffic usage reporting, and routing of traffic flows to the Data Network, a branching point to support multi-homed PDU sessions, QoS handling for the user plane (e.g., packet filtering, gating, uplink / downlink rate enforcement), uplink traffic validation (service data flow (SDF) to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering and downlink data notification triggering functions, etc. Some or all of these functions of UPF (105) may be supported within a single UPF instance operating as a single UPF.

[0058] The AF (108) can interact with the 3GPP core network to provide services (e.g., support functions such as application impact on traffic routing, access to network capability exposure, and interaction with policy frameworks for policy control).

[0059] (R)AN(102) may be a general term for a new radio access network that supports both evolved E-UTRA, an evolved version of 4G radio access technology, and new radio (NR) (e.g., gNB).

[0060] The gNB provides functions for radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to the UE in uplink / downlink (i.e., scheduling), IP (internet protocol) header compression, encryption and integrity protection of user data streams, selection of an AMF (103) upon attachment of the UE (101) if routing to the AMF (103) is not determined from information provided to the UE (101), routing of user plane data to the UPF (105)(s), routing of control plane information to the AMF (103), connection setup and teardown, scheduling and transmission of paging messages (originating from the AMF), scheduling and transmission of system broadcast information (originating from the AMF or operating and maintenance (O&M)), measurement and measurement reporting configuration for mobility and scheduling, It can support functions such as transport level packet marking in uplink, session management, support for network slicing, QoS flow management and mapping to data radio bearers, support for UEs in inactive mode, NAS message distribution, NAS node selection, radio access network sharing, dual connectivity, and tight interworking between NR and E-UTRA.

[0061] UE (101) may refer to a user equipment. The user equipment may be referred to by terms such as terminal, mobile equipment (ME), or mobile station (MS). Furthermore, the user equipment may be a portable device such as a laptop, mobile phone, personal digital assistant (PDA), smartphone, or multimedia device, or may be a non-portable device such as a personal computer (PC) or vehicle-mounted device. Hereinafter, the user equipment (UE) or terminal will be referred to as such.

[0062] For clarity of explanation, the network exposure function (NEF) device and the NF repository function (NRF) device are not illustrated in FIG. 1, but all NFs illustrated in FIGS. 2 to 5 described below can interact with the NEF and NRF as needed.

[0063] Let's take a look at NRF. NRF (not shown in Figure 1) can support service discovery functionality. When receiving a second NF discovery request from a first NF instance, it can perform a second NF discovery operation and provide information about the discovered second NF instance to the first NF instance. It can also maintain a list of available NF instances and the services they support.

[0064] Meanwhile, for convenience of explanation, FIG. 1 illustrates a reference model for a case where a UE accesses one DN using one PDU session, but the present disclosure is not limited thereto.

[0065] A UE (101) can access two (i.e., local and central) data networks simultaneously using multiple PDU sessions. In this case, two SMFs can be selected for different PDU sessions. However, each SMF can have the ability to control both the local UPF and the central UPF within the PDU session.

[0066] Additionally, the UE (101) may simultaneously access two (i.e., local and central) data networks provided within a single PDU session.

[0067] The control plane components of 5GC can be considered as virtualized network functions (VNFs), and communication between these VNFs can be considered as RESTful-based API exchange, where one VNF provides services to other VNFs. This API-based communication interface between VNFs is called the Service Based Interface (SBI).

[0068] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. The following illustrates a reference point included in the 5G system architecture depicted in Figure 1.

[0069] - N1: Reference point between UE and AMF

[0070] - N2: Reference point between (R)AN and AMF

[0071] - N3: Reference point between (R)AN and UPF

[0072] - N4: Reference point between SMF and UPF

[0073] - N5: Reference point between PCF and AF

[0074] - N6: Reference point between UPF and data network

[0075] - N7: Reference point between SMF and PCF

[0076] - N8: Reference point between UDM and AMF

[0077] - N9: Reference point between two core UPFs

[0078] - N10: Reference point between UDM and SMF

[0079] - N11: Reference point between AMF and SMF

[0080] - N12: Reference point between AMF and AUSF

[0081] - N13: Reference point between UDM and authentication server function (AUSF)

[0082] - N14: Reference point between two AMFs

[0083] - N15: Reference point between PCF and AMF for non-roaming scenarios, reference point between PCF and AMF in visited network for roaming scenarios.

[0084] In the following description, the term "terminal" may refer to UE (101), and the terms "UE" and "terminal" may be used interchangeably. In this case, unless specifically defined additionally, the term "terminal" should be understood as "UE (101).

[0085] A terminal establishes a session by connecting to a data network (e.g., a network providing Internet services) through a 5G system, and can distinguish each data network using an identifier called a Data Network Name (DNN). The DNN can be used to determine NFs, inter-NF interfaces, and operator policies related to the user plane when the terminal connects to a network system and a session. The DNN can be used, for example, to select SMFs and UPF(s) for a PDU session, and to select interface(s) (e.g., N6 interface) between a data network and UPF for a PDU session. In addition, the DNN can be used to determine a mobile communication operator's policy to be applied to a PDU session.

[0086] FIG. 2 illustrates an Internet Protocol Multimedia Subsystem (IMS) network structure according to one embodiment of the present disclosure.

[0087] Refer to the contents of Fig. 1, and duplicate explanations are omitted.

[0088] Referring to FIG. 2, a UE (User Equipment) (101) can communicate with other UEs (not shown) located in a remote IMS network (260) and IM CN subsystem components through an IM CN (IP Multimedia Core Network) subsystem. The IM CN subsystem can include a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), and / or an MRF (270), and the components can perform the following functions.

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

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

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

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

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

[0094] - MRF (Media Resource Function)(270): MRF can perform various processing tasks related to media streams. MRF can be divided into MRFC (Multimedia Resource Function Controller), which is in charge of control, and MRFP (Multimedia Resource Function Processor), which is in charge of media processing.

[0095] Referring to Fig. 2, the interfaces between the above components can be expressed by the following reference points.

[0096] - Gm: Reference point Gm can support communication between the UE and the IM CN subsystem. For example, the UE can request network registration and session control through the Gm reference point. SIP, described below, can be used for the Gm reference point.

[0097] - Mw: Reference point Mw can support the exchange and transmission of signaling messages between CSCFs.

[0098] - ISC: Reference Point ISC can support the exchange of information required for services provided by the service platform (e.g., IMS AS) between the S-CSCF and the service platform.

[0099] - Sh: Reference point Sh can support the exchange of information required for the service provided by the service platform between the HSS and the service platform (e.g., IMS AS).

[0100] - Cx: Reference point Cx can support information transfer between HSS and CSCF.

[0101] - Mr' / Cr: Reference point Mr' can support interaction for session control between IMS AS and MRFC, and reference point Cr can support interaction for media control between IMS AS and MRFC.

[0102] - Iq: Reference point Iq can support the exchange of information required for allocation and release of transport addresses between P-CSCF and IMS AGW.

[0103] - Mb: Reference point Mb can support IMS media transfer between IMS components.

[0104] Referring to Fig. 2, a P-CSCF (210) supporting a Service Based Interface (SBI) can communicate with a Policy Control Function (PCF) (107), which can be represented by reference point N5. The PCF (107) can support policy establishment and distribution for managing network operations, and the P-CSCF (210) supporting the SBI can be considered an application function (AF: Application Function) that uses a service that the PCF (107) provides to other VNFs.

[0105] An HSS (240) supporting SBI can communicate with an I / S-CSCF (220) supporting SBI through reference point N70, and can communicate with an IMS AS (230) supporting SBI through reference point N71. Similarly, the I / S-CSCF (220) supporting SBI and the IMS AS (230) supporting SBI can be regarded as AFs that use services provided by the HSS (240) supporting SBI, and the functions provided by reference points N70 and N71 can be equivalent to the functions provided by reference points Cx and Sh, respectively.

[0106] The above SIP is an application-layer signaling protocol that specifies the procedures for intelligent terminals wishing 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, voicemail, event notifications, and instant messaging. It can be used on both TCP and UDP, and by using SIP URLs, similar to email addresses, to distinguish each user, services are provided independent of IP addresses. SIP is text-based and was developed using many parts of HTTP and SMTP, making it easy to implement. It also offers 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 MMUSIC (Multiparty Multimedia Session Control) Working Group in 1999, and later revised by the separate ITEF SIP Working Group, and the RFC3261 standard was established in July 2002.

[0107] 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. The communication system according to various embodiments of the present disclosure can perform an agreement on the media session through Session Description Protocol (SDP) negotiation to provide the service (e.g., a real-time interaction service).

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

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

[0110] FIG. 3 illustrates an example of a network structure including a data channel server in a communication system according to one embodiment of the present disclosure.

[0111] Refer to the contents of Figures 1 and 2, and duplicate explanations are omitted.

[0112] In a communication system according to various embodiments of the present disclosure, a web application for providing a service (e.g., a real-time interaction service) may be provided from a Data Channel Application Server (DCAS). The Data Channel Application Server may be located in an IMS operator network or a third-party network. In the present disclosure, the web application provided by the Data Channel Application Server may be referred to as a Data Channel Application (DCA). A terminal participating in a service (e.g., a real-time interaction service) provided by the Data Channel Application may 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), and may communicate with the Data Channel Application Server using a Bootstrap Data Channel (BDC).

[0113] Referring to FIG. 3, a communication system may include a UE (101) and an IM CN subsystem. The UE (101) may communicate with other UEs located in a remote IMS network (260) and components of the IM CN subsystem via the IM CN subsystem. The IM CN subsystem may include a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), a Data Channel Signaling Function (DCSF) (310), a Media Function (321), a NEF (330), a Data Channel Application Server (DCAS) (340), and / or a Data Channel Application Repository (DCAR) (350).

[0114] The above data channel signaling function (310) can perform the following functions:

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

[0116] - Data channel management and event generation / reception through communication with IMS AS

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

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

[0119] - Proxy role for resource distribution of data channel application server (340)

[0120] The above data application storage (350) can store and manage data channel applications and can be located inside or outside the above data channel application server (340).

[0121] The above media function (321) and MRF (270) can perform the following functions:

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

[0123] - Acts as a proxy for data exchange with the endpoint of the data channel connected to the terminal and other endpoints.

[0124] The above media function (321) and MRF (270) provide equivalent functions with different interfaces, and the operator may include only one of the media function (321) and the MRF (270) in the data channel server (340), or may include both, taking into consideration compatibility with other network equipment and user terminals.

[0125] FIG. 4 illustrates an example of a network structure including a connection relationship between a 5G core network and an IMS network in a communication system according to one embodiment of the present disclosure.

[0126] Refer to the contents of Figures 1 to 3, and duplicate descriptions are omitted.

[0127] The terminal (101) can send a SIP INVITE message to the P-CSCF (210) to establish an IMS session for making an IMS call. Thereafter, according to the IMS session establishment procedure, the IMS session can be established through communication among the P-CSCF (210), S-CSCF (220), I-CSCF (220), IMS AS (230), and HSS (240).

[0128] If the IMS call of the terminal is structured to pass through the 5G system, in other words, if the data is transmitted through the 5G PDU session, the PCF (107) can be in charge of PDU session policy management including data resource management between the UE (101), RAN (102), UPF (105), and IMS-AGW (250). To this end, the P-CSCF (210) can provide the PCF (107) with IMS session information necessary for data resource management of the IMS session. At this time, the P-CSCF (210) can operate as an AF (108) to the PCF (107) and use the N5 interface. Based on the IMS session information, the PCF (107) can perform terminal policy or session policy management including data resource reservation, policy information determination including QoS rule determination, and Policy Control Request Trigger (PCRT) generation. PCF (107) can establish or identify a PDU session associated / corresponding to the IMS session based on IMS session information.

[0129] That is, when the terminal (101) successfully establishes an IMS call, (1) an IMS session is established between IMS nodes, (2) a PDU session is established between 5G CN NFs, and the relationship between (1) the IMS session and (2) the PDU session can be identified by the PCF (107) based on the IMS session information provided by the P-CSCF (210) to the PCF (107).

[0130] If the IMS call of the terminal (101) is structured to pass through a 4G system, that is, a structure in which data is transmitted through an EPS PDN session, the role of the PCF (107) in the above content can be performed by the PCRF (not shown).

[0131] In the conventional IMS (IP Multimedia Subsystem) data channel-based multimedia call, the status and conditions of the terminal and 5G network are checked during the call establishment procedure to see if they are in a state and condition that can provide an IMS data channel-based multimedia call. If the conditions cannot be met, the call is not established, or the call is monitored after establishment and the call is released if the conditions cannot be met.

[0132] For the IMS data channel-based multimedia call service currently being discussed in 3GPP, the service must be provided without restrictions between users using terminals that do not support IMS data channels and users using terminals that support IMS data channels.

[0133] Therefore, there is a need for a method to provide an IMS data channel-based service experience by providing a method for terminals that do not support IMS data channels to connect to a server that provides IMS data channel-based services indirectly without using the IMS data channel.

[0134] According to one embodiment of the present disclosure, a method is disclosed for connecting to a server that provides an IMS data channel-based service indirectly without using an IMS data channel for a terminal that does not support an IMS (IP Multimedia Subsystem) data channel, and an IMS session and IMS Data Channel session establishment procedure capable of providing an IMS data channel-based service experience are disclosed.

[0135] FIG. 5 illustrates an example of a negotiation procedure between a UE and an IMS CN for the ability to support storage and access of data in a communication system according to one embodiment of the present disclosure.

[0136] Referring to FIG. 5, the terminal and the network can perform a registration procedure for using the IMS service through the following procedure.

[0137] In step S501, the UE (101) may transmit a Register message to the P-CSCF (210). This message may include at least one of a User ID (e.g., a user's external ID, a user's Public User Identities, a user's Private User Identities, an IMPU, an IMPI, etc.), a UE IMS data channel capability (whether the UE supports an IMS data channel capability), and a UE data store and access capability (whether the UE supports a capability to store the user's data (e.g., an avatar) in the network and access the user data stored in the network).

[0138] The user's external ID may be an identifier for the user managed externally, for example, by a 3rd party service provider, rather than an ID used within the IMS or mobile carrier network.

[0139] User information included in a Register message may include one or more user identifiers.

[0140] In step S502, the P-CSCF (210) can forward the Register message received in step S501 to the I-CSCF (510).

[0141] In step S503, the I-CSCF (510) may request information to find the S-CSCF (520) from the HSS / UDM (410). The request for information to find the S-CSCF (520) may use a Cx-Query or Cx-Select-Pull message.

[0142] In step S504, the HSS / UDM (410) may provide information about the S-CSCF (250) to the I-CSCF (510). The Cx-Query Response or Cx-Select-Pull Response message may be used to provide information about the S-CSCF (250).

[0143] In step S505, the I-CSCF (510) can forward the Register message received in step S502 to the S-CSCF (520).

[0144] In step S506, the S-CSCF (520) may request subscriber information of the UE from the HSS / UDM (410) in the Register message received in step S505. The terminal subscription information request message may include a terminal ID. The terminal ID may be determined based on the user information received in step S505. For example, the S-CSCF (520) may include the terminal ID received in step S505 in the terminal subscription information request message. Alternatively, for example, the S-CSCF (520) may change the terminal ID (e.g., external ID, etc.) received in step S505 to a terminal ID used in an IMS or mobile communication operator network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the message of step S506. A Cx-Put or Cx-Pull message may be used to request subscriber information. The subscriber information request message may additionally include information requesting confirmation of whether the user is subscribed to an IMS data channel service and / or whether the user is subscribed to a data store and access service.

[0145] In step S507, the HSS / UDM (410) may provide subscriber information of the UE (101) to the S-CSCF (520). A Cx-Put Response or Cx-Pull Response message may be used to provide the subscriber information. The subscriber information provision message may include at least one of information on whether the user subscribes to the IMS data channel service (Allowance of IMS DC), information on whether the user subscribes to the data store and access service (Allowance of data store and access in network), and information on whether the user requires a secondary authentication procedure to use the data store and access service (Need of Secondary authentication for data store and access). The S-CSCF (520) may perform the following judgment based on the subscriber information received from the HSS / UDM (410).

[0146] (1) Whether to subscribe to IMS DC service: If the UE (101) supports the IMS DC service in the Register message of step S505, but the user is not subscribed to the IMS DC service in the Response message of step S507, the S-CSCF (520) can determine that the IMS DC capability is not allowed to the UE (101).

[0147] (2) Data Store and Access service subscription status: Data Store and Access service subscription status can be classified as Allowed, Allowed (Store only), Allowed (Access only), Allowed (Store and Access), Not Allowed, Unknown, etc. In the Register message of step S505, if the UE (101) supports the Data Store and Access service, but in the Response message of step S507, if the user is not subscribed to the Store and Access service (Not Allowed), the S-CSCF (520) can determine that the Data Store and Access service is not allowed to the UE (101).

[0148] (3) Whether secondary authentication is required for Data Store and Access service: If the UE (101) supports Data Store and Access service in the Register message of step S505, and the user is subscribed to Data Store and Access service in the Response message of step S507 (Allowed, Allowed(...)) and secondary authentication is required for Data Store and Access service, the S-CSCF (520) can determine that secondary authentication for Data Store and Access is required for the UE (101).

[0149] In step S507a, the S-CSCF (520) may perform an authentication procedure for the UE (101). The authentication procedure may use a terminal ID. The terminal ID may be determined based on the user information received in step S505. For example, the S-CSCF (520) may use the terminal ID received in step S505. Alternatively, for example, the S-CSCF (520) may change the terminal ID (e.g., external ID, etc.) received in step S505 to a terminal ID used in the IMS or mobile communication operator network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the step S507a message. The authentication procedure may include a process of requesting an Authentication Vector from the HSS / UDM (410) and a process of performing security verification with the UE (101) using security information including the Authentication Vector.

[0150] In step S508, the S-CSCF (520) provides registration information to the service control platform so that it can perform procedures required for service control.

[0151] In step S509, the S-CSCF (520) may send a 200 OK message to the I-CSCF (510). The 200 OK message may include at least one of whether the IMS DC service can be provided to the UE (101) (IMS DC capability), whether the Data Store and Access service can be provided to the UE (101) (data store and access capability), and whether a secondary authentication procedure is required to use the Data Store and Access service (secondary authentication for data store and access), depending on the results of steps S506 to S508. The Data store and access capability may be provided together with specific information (Allowed, Allowed (Store only), Allowed (Access only), Allowed (Store and Access), Not Allowed, Unknown, etc.) provided by the HSS / UDM (410) in step S507.

[0152] In step S510, the I-CSCF (510) can forward the 200 OK message received in step S509 to the P-CSCF (210).

[0153] In step S511, the P-CSCF (210) can forward the 200 OK message received in step S510 to the UE (101).

[0154] In step S512, UE (101) can perform the following judgment based on the information included in the 200 OK message received in step S511.

[0155] (1) Whether IMS DC service can be provided to UE (101) (IMS DC capability): If this information is received, UE (101) can perform a Bootstrap DC session establishment request for IMS DC service.

[0156] (2) Whether Data Store and Access service can be provided to UE (101) (data store and access capability): If this information is received, UE (101) can request to store Avatar information of UE (101) in IMS CN or request to provide Avatar information stored in IMS CN. If the data store and access capability received in step S511 indicates specific information, the following judgment can be performed.

[0157] ㆍ Allowed (Store only): UE (101) can provide Avatar information of UE (101) to IMS CN and request that it be stored in IMS CN. UE (101) cannot access Avatar information stored in IMS CN or download Avatar information stored in IMS CN.

[0158] ㆍ Allowed (Access only): UE (101) can request or download Avatar information stored in IMS CN. UE (101) cannot upload Avatar information of UE (101) to IMS CN.

[0159] ㆍ Allowed (Store and Access): UE (101) can provide Avatar information of UE (101) to IMS CN, request storage, and access or download Avatar information stored in IMS CN.

[0160] (3) Whether a secondary authentication procedure is required to use the Data Store and Access service (secondary authentication for data store and access): If this information is received, the UE (101) may recognize that a secondary authentication procedure is required when making a request related to storage and access to Avatar information and prepare for it. An example of preparation for the secondary authentication procedure may include providing a service account ID required for the secondary authentication procedure when the UE (101) requests establishment of a Bootstrap DC session including storage and access functions for Avatar information. This service account ID may be the ID of an account permitted to the user by the Avatar service provider. The user may have installed an Avatar service application supporting the data store and access function on the UE (101) and created a user account (identified by account ID and account password).

[0161] FIGS. 6A and 6B illustrate examples of procedures between AF and 5GS / IMS CN for managing application information supporting storage and access of data in a communication system according to one embodiment of the present disclosure.

[0162] Referring to Figures 6a and 6b, the IMS CN can manage IMS DC application information through the following procedures.

[0163] In step S601, the DC AS (AF) (340) may request registration of a DC application profile to the NEF (330). The DC application information may include at least one of the following information:

[0164] (1) ID of the service provided by the DC application (Service ID: e.g., IMS Communication Service Identifier, ICSI)

[0165] (2) User ID providing DC application (User ID: e.g., user's external ID, user's Public User Identities, Private User Identities, IMPU, IMPI, etc.)

[0166] (3) DC application profile:

[0167] (3)-a. DC application ID: ID of the DC application

[0168] (3)-b. DC control policy: Types of DC services provided by DC applications (P2A, P2P, A2P, P2A2P)

[0169] (3)-c. DC application authentication policy: Whether secondary authentication is required, whether authentication using a service account ID is required, whether it should be performed in the bootstrap DC procedure, or whether it should be performed in the application DC procedure.

[0170] (3)-d. DC AS address: DC AS address

[0171] The user's external ID may be an identifier for the user managed externally, for example, by a 3rd party service provider, rather than an ID used within the IMS or mobile carrier network.

[0172] An external group ID may be an identifier representing a group containing one or more users. The users identified by the group ID may be users who use / subscribe to the same service. The "same service" may be a service identified by the Service ID included in the DC session setup request message in step S601.

[0173] User information included in an AF request message may include one or more user identifiers.

[0174] The group information included in the AF request message may include one or more external group identifiers.

[0175] The service provided by the IMS AS (230) or the indicator indicating the service provided by the IMS AS (230) may be the IMS Communication Service (ICS Identifier (ICSI)) provided by the IMS AS (230). Table 1 shows examples of ICSI values. The services provided by the IMS AS (230) may include the IMS DC service and the Store and Access service.

[0176]

[0177]

[0178] In step S602, NEF (330) may obtain terminal subscription information from UDM / HSS (410). NEF (330) may transmit a terminal subscription information request message to UDM / HSS (410). The terminal subscription information request message may include a terminal ID. The terminal ID may be determined based on the user information received from DC AS (340) in step S601. For example, NEF (330) may include the terminal ID received in step S601 in the terminal subscription information request message. Alternatively, for example, NEF (330) may change the terminal ID (e.g., external ID, etc.) received in step S601 to a terminal ID used in IMS or a mobile communication service provider network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the terminal subscription information request message. Alternatively, NEF (330) may change the group ID received in step S601 to a group ID or terminal ID (e.g., Public User Identity, Private User Identity, etc.) used in the IMS or mobile communication operator network, and include the changed group ID or terminal ID in the terminal subscription information request message.

[0179] UDM (106) can reply to NEF (330) with a list of services to which a user is subscribed, referred to by terminal ID or group ID.

[0180] In step S603, the NEF (330) can authenticate the request of the DC AS (AF) (340). The NEF (330) can verify whether the request for storing DC application information is from an NF or an AF. The NEF (330) can verify whether the terminal corresponding to the user ID included in the AF request message is a terminal that can use the requested service, i.e., a terminal that is subscribed to the service. The NEF (330) can verify whether the user group corresponding to the group ID included in the AF request message or the terminal corresponding to the group ID is a group or terminal that can use the requested service, i.e., a group or terminal that is subscribed to the service. The NEF (330) can verify whether the requested service is a service related to / corresponding to a data channel.

[0181] In step S604, NEF (330) can transmit the request message of AF of step S601 to DCSF (310) via UDR (610) (step S604a) or directly (step S604b).

[0182] In step S604a, NEF (330) may store the AF's request message in UDR (610). UDR (610) may notify DCSF (310) of any change in service information of a specific Service ID or service information / subscriber information of a specific User ID by notifying DCSF (310) of the change. This operation requires DCSF (310) to request a subscription to UDR (610) for notification of information changes in advance.

[0183] In step S604b, NEF (330) can directly transmit the AF request message to DCSF (310). This operation may be preceded by a process in which NEF (330) searches for DCSF (310) through NRF (not shown).

[0184] In step S605, DCSF (310) can register the information included in the registration request message of DC application information received in step S604 with HSS / UDM (410). This registration message can be a Sc-Put message using the Sc interface or a message using the N72 interface.

[0185] In step S606, the HSS / UDM (410) can store and manage the information received in step S605. The HSS / UDM (410) can respond to the DCSF (310). This response message can be a Sc-Put Response message using the Sc interface or a message using the N72 interface.

[0186] In step S607, DCSF (310) can register information included in the registration request message of DC application information received in step S604 to DC AR (350).

[0187] In step S608, DC AR (350) can respond to the request of DCSF (310).

[0188] In step S609, if there is a DC application that requires a secondary authentication procedure in the Bootstrap DC procedure (which may be a DC application supporting store and access functions), the DCSF (310) may store relevant information required for secondary authentication. The relevant information required for secondary authentication may include a DC application authentication policy and a DC AS address.

[0189] In step S610, when the DCSF (310) receives a request related to a DC application from an IMS entity including a UE (101), an MF (321), or a Remote UE, the DCSF (310) can determine whether secondary authentication is required during the Bootstrap DC procedure (step S610a), whether secondary authentication is required during the Application DC procedure (step S610b), and whether all UEs can receive the service in the Application DC procedure for P2P communication (step S610c) based on the DC application profile information.

[0190] In step S610a, if the DCSF (310) receives a request for a Bootstrap DC procedure, it can determine whether secondary authentication is necessary based on the information related to secondary authentication stored in step S609 and initiate it. If the information related to secondary authentication of step S609 is not stored in the DCSF (310) (or is not set in the DCSF (310)), it can be obtained from the HSS / UDM (410) (reuse of steps S605-S606), UDR (610), DC AR (350) (reuse of steps S607-S608), or DC AS (340). When DCSF (310) cannot specify the target DC application when obtaining information related to secondary authentication from another entity (for example, when the Bootstrap DC procedure request message does not include a DC application ID), DCSF (310) can obtain information related to secondary authentication based on the User ID or Service ID.

[0191] In step S610b, if the DCSF (310) receives a request for an Application DC procedure, it can determine whether secondary authentication is required based on the DC application profile and initiate it. If the DC application profile is not stored in the DCSF (310) (or is not set in the DCSF (310)), it can be obtained from the HSS / UDM (410), UDR (610), DC AR (350), or DC AS (340).

[0192] In step S610c, DCSF (310) can determine whether a DC application can be provided to an entity that requested the Application DC procedure based on the DC application profile.

[0193] (1) For example, when DCSF (310) receives a request from UE (101) regarding establishment of a DC session using a P2P DC application with Remote UE, it can determine whether P2P service (DC control policy of DC application profile) can be provided to UE (101) (User ID of UE) based on the profile of the DC application. When DC application profile for Remote UE can also be acquired (when Remote UE is connected to the same PLMN as UE (101)), it can determine whether P2P service is available to Remote UE (User ID of Remote UE), and specifically determine whether the DC application can be provided to both UE (101) and Remote UE.

[0194] FIGS. 7a, 7b, and 7c illustrate examples of authentication procedures between a UE and an IMS CN to support storage and access of data in a communication system according to one embodiment of the present disclosure.

[0195] Referring to FIGS. 7a, 7b, and 7c, the terminal and the network can perform the Bootstrap DC session establishment procedure for using the IMS service through the following procedures. Any content overlapping with that described in FIG. 5 may be omitted. The procedures for initiating and performing secondary authentication described in FIGS. 7a and 7b can be similarly applied to the Bootstrap DC session modification procedure and the Application DC session establishment / modification procedure.

[0196] In step S701, the UE (101) may transmit an INVITE (or re-INVITE) message to the P-CSCF (210). This message may include at least one of an SDP offer for audio and / or video, and an SDP offer for a Bootstrap DC. If the UE (101) intends to use avatar communication using the IMS DC service and data store and access function, the SDP offer for the Bootstrap DC may include at least one of the following information. Some or all of the following information may be included in the SIP message, but may be outside the SDP offer. For example, the User ID for secondary authentication may be included in the INVITE message, in the SDP offer for the Bootstrap DC, or may be provided as separate information in the INVITE message.

[0197] (1) SDP offer information for IMS DC-based avatar media

[0198] (2) Information required to support IMS DC-based store and access function: For example, if the UE confirms that it can receive data store and access function service in the procedure described in FIG. 5, it may include the store and access supported indicator.

[0199] (3) User ID

[0200] (4) User ID for secondary authentication: May include Service account ID.

[0201] In step S702, the P-CSCF (210) can forward the INVITE message received in step S701 to the S-CSCF (520) via the I-CSCF (510).

[0202] In step S703, the S-CSCF (520) may request subscriber information of the UE (101) from the HSS / UDM (410).

[0203] In step S704, the S-CSCF (520) may receive subscriber information of the UE (101) from the HSS / UDM (410). The subscriber information of the UE (101) may include information (Allowance of IMS DC, Allowance of data store and access in network, Need of Secondary authentication for data store and access) described in step S507 of FIG. 5.

[0204] In step S705, the S-CSCF (520) may determine whether a secondary authentication procedure is required to provide avatar communication using the IMS DC service and data store and access functions. If the S-CSCF (520) determines that the secondary authentication procedure must be performed during the bootstrap DC establishment procedure, it may request secondary authentication from the DCSF (310) via the IMS AS (230).

[0205] In step S706, the S-CSCF (520) may forward the INVITE message received in step S702 to the IMS AS (230) and request secondary authentication. The request for secondary authentication may be sent in a format in which at least one of the following information is added to the information described in step S701 in the SDP offer for the Bootstrap DC of the INVITE message in step S702, or in a format provided separately from the INVITE message.

[0206] (1) More specific information related to support for IMS DC-based store and access functions: Allowed, Allowed (store only), Allowed (access only), Allowed (store and access), Unknown

[0207] (2) Indicator indicating that secondary authentication is required

[0208] In step S707, the IMS AS (230) may perform DCSF routing decision and DCSF search procedures.

[0209] In step S708, the IMS AS (230) may provide the request information of the UE received in step S706 to the DCSF (310).

[0210] In step S709, the DCSF (310) may determine and initiate whether secondary authentication is required in establishing a Bootstrap DC session based on the information received in step S708 (which may include at least one of store and access related information, an indicator indicating that secondary authentication is required, and a User ID required for secondary authentication) and information related to secondary authentication stored (or set) in the DCSF (310) (if not stored, it may be obtained from the HSS / UDM (410), UDR (610), DC AR (350), and DCAS (340) as described in step S610a of FIG. 6b).

[0211] In step S710, DCSF (310) may initiate secondary authentication.

[0212] In step S710a, the DCSF (310) may request the DC AS (340) (via the NEF (330)) to perform secondary authentication for the User ID of the UE (101). This request may include a Service ID and a User ID (which may be a User ID for secondary authentication).

[0213] In step S710b, DC AS (340) can perform a secondary authentication procedure with UE (101) through DCSF (310), IMS AS (230), S-CSCF / I-CSCF (220), and P-CSCF (210) (via NEF (330)).

[0214] In step S710c, DC AS (340) can provide the authentication result for the User ID of the step S710a message to DCSF (310).

[0215] In step S711, if the secondary authentication is successful, the DCSF (310) may provide an indicator to the IMS AS (230) informing that the secondary authentication is successful.

[0216] In step S712, the IMS AS (230) may search for and select an MF (321) or MRF (270) based on the request message received in step S706 and the secondary authentication result received in step S711. For example, an MF (321) or MRF (270) capable of processing avatar media and supporting data store and access functions may be searched for or selected.

[0217] In step S713, the IMS AS (230) may request the MF (321) / MRF (270) to reserve media resources for the calling party and the called party. The MF (321) / MRF (270) may allocate MDC1 resources for the calling party and the called party. The MF (321) / MRF (270) may allocate resources for the following types of data store and access functions at the request of the IMS AS (230).

[0218] (1) Resources required to store the user's avatar

[0219] (2) Resources required for users to upload avatars

[0220] (3) Resources required for users to download avatars

[0221] (4) Resources required for IMS entities to access the user's avatar information.

[0222] In step S714, the IMS AS (230) may respond to step S711 to the DCSF (310).

[0223] At step S715, DCSF (310) may respond to step S708 to IMS AS (230).

[0224] In step S716, the IMS AS (230) may modify the SDP offer for the Bootstrap DC from the message received in step S706 and provide it to the S-CSCF / I-CSCF (220). The modification in the SDP offer may mean adding resource information (which may include resources for data store and access functions) allocated by the MF (321) / MRF (270) in step S713 and / or excluding the User ID for secondary authentication.

[0225] In step S717, the S-CSCF / I-CSCF (220) can forward the message received in step S716 to the Remote UE (710) through the terminating network.

[0226] In step S718, the terminating network may perform a Bootstrap DC procedure for the Remote UE (710). This procedure may include all or part of steps S701 to S716.

[0227] In step S718a, the S-CSCF of the terminating network can initiate a secondary authentication procedure for the Remote UE (710). The Remote UE (710) can perform the secondary authentication procedure through the S-CSCF, IMS AS, DCSF, and DC AS of the terminating network. The User ID for the secondary authentication of the Remote UE (710) can be provided to the S-CSCF by the Remote UE (710) by adding it when it receives the message of step S717, or the S-CSCF can obtain mapping information from the HSS / UDM of the terminating network and specify it.

[0228] At step S719, the terminating network may provide an appropriate intermediate response to the step S717 message.

[0229] In step S720, if the Remote UE (710) completes the secondary authentication and the Bootstrap DC procedure for avatar media, it may provide a 200 OK message to the I-CSCF / S-CSCF (220). This message may include an indicator indicating that the Bootstrap DC procedure for avatar media has been successfully accepted and / or an indicator indicating that the secondary authentication has been successful.

[0230] In step S721, I-CSCF / S-CSCF (220) may forward the message of step S720 to IMS AS (230).

[0231] At step S722, the IMS AS (230) may provide an indication to the DCSF (310) that the Bootstrap DC procedure for the avatar media was successfully accepted, and / or an indication that the secondary authentication was successful.

[0232] In step S723, DCSF (310) may respond to the notification of IMS AS (230).

[0233] In step S724, the IMS AS (230) may complete the Bootstrap DC procedure by transmitting a 200 OK message to the UE (101).

[0234] FIG. 8 illustrates the structure of a terminal (800) according to one embodiment of the present disclosure.

[0235] Referring to FIG. 8, a terminal (800) may represent a UE (101). The terminal (800) may include a transceiver (820), a memory (830), and a processor (810). Depending on the communication method of the terminal (800) described above, the transceiver (820), the memory (830), and the processor (810) of the terminal (800) may operate. However, the components of the terminal (800) are not limited to the examples described above. For example, the terminal (800) may include more or fewer components than the components described above. In addition, the transceiver (820), the memory (830), and the processor (810) may be implemented in the form of a single chip.

[0236] The transceiver (820) can transmit and receive signals with a base station or network entity. Here, the signals may include control information and data. To this end, the transceiver (820) may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. However, this is only one embodiment of the transceiver (820), and the components of the transceiver (820) are not limited to the RF transmitter and RF receiver.

[0237] Additionally, the transceiver (820) can receive a signal through a wireless channel and output it to the processor (810), and transmit a signal output from the processor (810) through the wireless channel.

[0238] The memory (830) can store programs and data necessary for the operation of the terminal. In addition, the memory (830) can store control information or data included in signals transmitted and received by the terminal (800). The memory (830) can be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. In addition, there can be multiple memories (830).

[0239] Additionally, the processor (810) may control a series of processes so that the terminal (800) can operate according to the aforementioned embodiments. For example, the processor may control components of the terminal (800) to transmit and receive signals in a wireless communication system according to embodiments of the present disclosure. There may be multiple processors (810), and the processors (810) may perform component control operations of the terminal (800) by executing a program stored in the memory (830).

[0240] FIG. 9 illustrates the structure of a network entity (900) according to one embodiment of the present disclosure.

[0241] Referring to FIG. 9, a network entity (900) may include at least one of an AUSF (110), an AMF (103), an SMF (104), an SMSF, a PCF (107), an AF (108), a UDM (106), a DN (112), an UPF (105), an (R)AN (102), an NSSF (109), an NSSAAF (111), a Network Slice Admission Control Function (NSACF) (113), an NEF (330), an NRF, a P-CSCF (210), an I / S-CSCF (220), an IMS AS (230), an IMS HSS (240), an IMS AGW (250), an MRF (270), a Remote IMS (260), an MF DCAR (350), a DCSF (310), a DC AS (340), a UDM (106), a UDR (610), and a DC AR (350).

[0242] According to one embodiment, the network entity (900) may include a transceiver (920), a memory (930), and a processor (910). Depending on the communication method of the network entity (900) described above, the transceiver (920), the memory (930), and the processor (910) of the network entity (900) may operate. However, the components of the network entity (900) are not limited to the examples described above. For example, the network entity (900) may include more or fewer components than the components described above. In addition, the transceiver (920), the memory (930), and the processor (910) may be implemented in the form of a single chip.

[0243] The transceiver (920) can transmit and receive signals with a terminal or network entity. Here, the signals may include control information and data. To this end, the transceiver (920) may be configured with an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. However, this is only one embodiment of the transceiver (920), and the components of the transceiver (920) are not limited to the RF transmitter and RF receiver.

[0244] Additionally, the transceiver (920) can receive a signal through a wireless channel and output it to the processor (910), and transmit a signal output from the processor (910) through the wireless channel.

[0245] The memory (930) can store programs and data necessary for the operation of the terminal. Furthermore, the memory (930) can store control information or data included in signals transmitted and received by the network entity (900). The memory (930) may be configured as a storage medium or a combination of storage media, such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD. Furthermore, there may be multiple memories (930).

[0246] Additionally, the processor (910) may control a series of processes so that the network entity (900) can operate according to the aforementioned embodiments. For example, the processor may control components of the network entity (900) to transmit and receive signals in a wireless communication system according to embodiments of the present disclosure. There may be multiple processors (910), and the processors (910) may perform component control operations of the network entity (900) by executing a program stored in the memory (930).

[0247] FIG. 10 illustrates a flowchart for terminal operation according to one embodiment of the present disclosure.

[0248] Referring to FIG. 10, in step 1010, a terminal (800) may transmit a registration message to a network entity (900). In one embodiment, the registration message may include at least one of a user identifier, information on support for an IMS (IP Multimedia Subsystem) data channel function of the terminal, and information on support for a data storage / access function of the terminal.

[0249] In step 1020, the terminal (800) may receive a message from the network entity (900) including at least one of information on whether an IMS data channel service can be provided, whether a data storage / access service can be provided, and whether a secondary authentication procedure is required for using the data storage / access service.

[0250] In step 1030, the terminal (800) may perform a bootstrap data channel session establishment request based on the received message, request storage of avatar information in the IMS CN (Core Network), request provision of stored avatar information to the IMS CN, or perform a secondary authentication procedure.

[0251] FIG. 11 illustrates a flowchart for S-CSCF operation according to one embodiment of the present disclosure.

[0252] Referring to FIG. 11, in step 1110, the S-CSCF (520) may receive a registration message from the I-CSCF (510). In one embodiment, the registration message may include at least one of a user identifier, IMS (IP Multimedia Subsystem) data channel function support information of the terminal, and data storage / access function support information of the terminal.

[0253] In step 1120, the S-CSCF (520) may transmit a subscriber information request message of the terminal to the HSS / UDM (410) using the user identifier included in the registration message. In one embodiment, the subscriber information request may use a Cx-Put or Cx-Pull message. In one embodiment, the subscriber information request message may include at least one of confirmation request information on whether the user is subscribed to an IMS data channel service and confirmation request information on whether the user is subscribed to a data storage / access service.

[0254] In step 1130, the S-CSCF (520) may receive a subscriber information provision message of the terminal from the HSS / UDM (410). In one embodiment, a Cx-Put Response or Cx-Pull Response message may be used to provide the subscriber information. In one embodiment, the subscriber information provision message may include at least one of information on whether the user subscribes to an IMS data channel service (Allowance of IMS DC), information on whether the user subscribes to a data storage / access service (Allowance of data store and access in network), and information on whether a secondary authentication procedure is required for the user to use the data storage / access service (Need of Secondary authentication for data store and access).

[0255] In step 1140, the S-CSCF (520) may perform an authentication procedure for the user identifier included in the registration message. The authentication procedure may include a process of requesting an authentication vector from the HSS / UDM (410) and a process of performing security verification with the terminal using security information including the authentication vector.

[0256] In step 1150, the S-CSCF (520) may send a message to the I-CSCF (510) including at least one of information on whether an IMS data channel service can be provided, whether a data storage / access service can be provided, and whether a secondary authentication procedure is required for using the data storage / access service.

[0257] FIG. 12 illustrates a flowchart for a DCSF operation according to one embodiment of the present disclosure.

[0258] Referring to FIG. 12, in step 1210, DCSF (310) may receive information from IMS AS (230) including at least one of storage / access-related information, an indicator indicating that secondary authentication is required, and a user identifier required for secondary authentication.

[0259] At step 1220, DCSF (310) may determine and initiate whether secondary authentication is required to establish a bootstrap data channel session based on the received information and information related to stored secondary authentication.

[0260] In step 1230, the DCSF (310) may transmit a request message to the DC AS (340) requesting secondary authentication for the user identifier of the terminal (800). In one embodiment, the request message may include a service identifier and a user identifier (GPSI, a user identifier for secondary authentication).

[0261] At step 1240, DCSF (310) may receive an authentication result message for a user identifier for secondary authentication from DC AS (340).

[0262] At step 1250, DCSF (310) may send a message to IMS AS (230) including an indicator that the secondary authentication was successful.

[0263] Contents that overlap with those in Figures 1 to 12 may be omitted. Contents that are consistent with those in TS 23.288 may be omitted.

[0264] FIG. 13 illustrates an example of a network structure including a data channel server and an avatar data storage in a communication system according to one embodiment of the present disclosure.

[0265] FIG. 13 is a structural diagram illustrating an example of a network structure including a data channel server in a communication system according to one embodiment of the present disclosure, with an Avatar Data Repository (ADR) (1310) added to the structure of FIG. 3. The MF (321) may be an MRF (270).

[0266] The Avatar Data Repository (ADR) (1310) can communicate with the DCSF (310) using the DCx interface. The Avatar Data Repository (1310) can be located in the DC Application Server (340) depending on the network implementation environment, and in this case, can communicate with the NEF (330) / DCSF (310) / MF (321) using the N33 / DC3 / DC4 / MDC1 / MDC2 / MDC3 interface. In this way, the location of the Avatar Data Repository (1310) can be another location depending on the environment, for example, the DCSF (310), the MF (321) / MRF (270), or can operate as an independent NF.

[0267] The Avatar Data Repository (1310) is a repository that stores Avatar Data corresponding to media and related data that constitute the user's Avatar, and Avatar ID, which is an identifier required for the user and network configuration devices to access the Avatar Data.

[0268] A user's avatar may be registered and managed by the user's UE and / or the service provider providing the avatar communication service. The avatar ID may be assigned and managed by the user and / or the service provider providing the avatar communication service.

[0269] The Avatar Data Repository (1310) may store one or more Avatars for each user. An Avatar ID List may be stored to manage these. Users can access the Avatar ID List, Avatar ID, and Avatar data using their 3GPP service subscriber ID (e.g., SUPI) and / or IMS service subscriber ID (e.g., IMPU, IMPI) and Avatar communication service subscriber ID (e.g., Service Level User ID).

[0270] Avatar data can consist of a Base Avatar and Avatar metadata:

[0271] - Base Avatar can refer to 3D visualization data of the face and body of a user (or an object including objects, for convenience, a human user will be described). Base Avatar can refer to basic 3D model data that does not reflect facial expressions or gestures that change over time, and therefore can be the user's own media. Users can use one or more Base Avatars depending on various forms of selection, such as usage purposes (e.g., work, home, specific applications), usage settings (e.g., hairstyle, accessories, clothing), etc.

[0272] - Avatar metadata can refer to information that further describes the Base Avatar. For example, it can include the Base Avatar's media format, codec information, data creation / modification time, compatible avatar communication applications, and data version information.

[0273] Avatar media can be expressed in a format consisting of a Base Avatar and Animation data (Format A), or in a format consisting of an Animated Avatar, where the Base Avatar and Animation data are combined and processed. Animation data can refer to data generated based on information acquired through user devices such as cameras and various sensor devices. Animation data can be recorded as feature points of facial expressions or gestures that change over time. The Base Avatar and Animation data can be combined to create moving avatar media.

[0274] The Avatar Data Repository (1310) may store, but is not limited to, the Base Avatar and Avatar metadata, and the Avatar ID and Avatar ID List, which are identifiers that can access them.

[0275] Users and networks can use Service Level User IDs to provide Avatar data only to authorized terminals and / or network devices.

[0276] Users and networks can efficiently send and receive necessary Avatar data using Avatar ID and Avatar ID List.

[0277] FIG. 14 illustrates an example of a procedure between a UE and an IMS CN for supporting a registration procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0278] Referring to Figure 14, the terminal and the network can perform a registration procedure for using the IMS service through the following procedure.

[0279] In step S1401, the UE (101) may transmit a Register message to the P-CSCF (210). This message may include at least one of a User ID (e.g., a user's external ID, a user's Public User Identities, a Private User Identities, an IMPU, an IMPI, etc.), a Service Level User ID (an ID that identifies a user in an application for avatar communication, including a service account ID described in FIG. 5), a UE IMS data channel capability (whether the UE supports an IMS data channel function), and a UE avatar communication capability (whether the UE supports avatar communication, including a data store and access capability described in FIG. 5). The UE IMS data channel capability and the UE avatar communication capability may each be provided as media feature tags in the Contact header field of the Register request message.

[0280] In step S1402, the P-CSCF (210) can forward the Register message received in step S1401 to the I-CSCF (510).

[0281] In step S1403, the I-CSCF (510) may request information to find the S-CSCF (520) from the HSS / UDM (410). The request for information to find the S-CSCF (520) may use a Cx-Query or Cx-Select-Pull message.

[0282] In step S1404, the HSS / UDM (410) may provide information about the S-CSCF (520) to the I-CSCF (510). The Cx-Query Response or Cx-Select-Pull Response message may be used to provide information about the S-CSCF (520).

[0283] In step S1405, I-CSCF (510) can forward the Register message received in step S1402 to S-CSCF (520).

[0284] In step S1406, the S-CSCF (520) may request subscriber information of the UE (101) from the HSS / UDM (410) in the Register message received in step S1405. The terminal subscription information request message may include a terminal ID and a Service Level User ID. The terminal ID may be determined based on the user information received in step S1405. For example, the S-CSCF (520) may include the terminal ID received in step S1405 in the terminal subscription information request message. Alternatively, for example, the S-CSCF (520) may change the terminal ID (e.g., external ID, etc.) received in step S1405 to a terminal ID used in an IMS or mobile communication operator network (e.g., Public User Identity, Private User Identity, etc.) and include the changed terminal ID in the message of step S1406. A Cx-Put or Cx-Pull message may be used to request subscriber information. The subscriber information request message may additionally include information requesting confirmation of whether the user is subscribed to an IMS data channel service and / or whether the user is subscribed to an avatar communication service.

[0285] In step S1407, the HSS / UDM (410) may provide subscriber information of the UE (101) to the S-CSCF (520). The Cx-Put Response or Cx-Pull Response message may be used to provide the subscriber information. The subscriber information provision message may include at least one of information on whether the user is subscribed to the IMS data channel service (Allowance of IMS DC) and information on whether the user is subscribed to the avatar communication service (Allowance of data avatar communication service). Whether the user is subscribed to the avatar communication service may correspond to whether the user is permitted to use the service using the Service Level User ID of step S1406.

[0286] In step S1408, the S-CSCF (520) provides registration information to the service control platform so that it can perform procedures required for service control.

[0287] In step S1409, the S-CSCF (520) may transmit a 200 OK message to the I-CSCF (510). The 200 OK message may include at least one of whether IMS DC service can be provided to the UE (101) (IMS DC capability) and whether avatar communication service can be provided to the UE (101), depending on the results of steps S1406 to S1408. Whether the IMS DC service and / or avatar communication service can be provided to the UE (101) may be determined based on whether the user has subscribed to the corresponding service (as determined by the results of steps S1406 to S1407) and / or whether the current IMS network is implemented to support the corresponding service. The IMS data channel capability of the network and the avatar communication capability of the network may be provided through the Feature-Caps header field of the 200 OK message, respectively.

[0288] In step S1410, the I-CSCF (510) may forward the 200 OK message received in step S1409 to the P-CSCF (210).

[0289] In step S1411, P-CSCF (210) can forward the 200 OK message received in step S1410 to UE (101).

[0290] In step S1412, UE (101) can perform a procedure for establishing (establish, initiate, add), modifying (modify, add), and releasing (release, remove) an IMS session (including an IMS data channel session) for avatar communication based on the information included in the 200 OK message received in step S1411.

[0291] FIGS. 15a, 15b, and 15c illustrate examples of procedures between a UE and an IMS CN for establishing a Bootstrap DC session for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0292] Referring to FIGS. 15a, 15b, and 15c, the terminal and the network can perform a Bootstrap DC session establishment procedure for using an IMS service through the following procedure.

[0293] In step S1501, UE#1(1510) may send an INVITE (or re-INVITE) message to P-CSCF(210). This message may include at least one of an SDP offer for audio and / or video, an SDP offer for Bootstrap DC, and a Service Level User ID of UE#1(1510). UE#1(1510) may be an ID determined to be allowed to use the avatar communication service in the IMS Registration procedure described in FIG. 14. The Service Level User ID of UE#1(1510) may be included within the SDP offer or outside the SDP offer. The INVITE message may be provided to IMS AS(230) through P-CSCF(210), I-CSCF(510), and S-CSCF(520).

[0294] In step S1502, the IMS AS (230) may perform DCSF routing decision and DCSF search procedures.

[0295] In step S1502a, the IMS AS (230) can verify subscriber information and / or internal policies / settings related to avatar data for UE#1 (1510). Based on the verification result, the DCSF (310) can be selected. For example, the DCSF (310) implemented to support functions for avatar communication services can be selected. Subscriber information can be verified through the HSS / UDM (410).

[0296] In step S1503, the IMS AS (230) may transmit a Bootstrap Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1501. This message may include the Service Level User ID of UE#1 (1510).

[0297] In step S1504, DCSF (310) can determine whether a data channel can be provided and the DC control policy based on the information received in step S1503.

[0298] In step S1505, DCSF (310) can generate DC media information for the sender and receiver based on the judgment in step S1504.

[0299] In step S1505a, DCSF (310) may obtain a list of Avatar IDs (Avatar ID List) that may be provided to UE#1 (1510) from Avatar Data Repository (1310) using the Service Level User ID of UE#1 (1510). If DCSF (310) determines that it is not appropriate to obtain the list of Avatar IDs for UE#1 (1510) from the calling network or that it is appropriate for the called network / UE#2 (1520) to obtain it, DCSF (310) may not obtain the list of Avatar IDs for UE#1 (1510) from Avatar Data Repository (1310). Additionally, DCSF (310) may determine that it is appropriate to obtain a list of Avatar IDs for UE#1 (1510) from both the originating network and the destination network, in which case it may obtain a list of Avatar IDs for UE#1 (1510) from the Avatar Data Repository (1310), and may decide to provide appropriate information (including a Service Level User ID for UE#1 (1510)) to UE#2 (1520) so that it can also be performed on the UE#2 (1520) side.

[0300] In step S1506, DCSF (310) may send a media instruction message for media control to IMS AS (230) to request that appropriate resources be allocated to MF / MRF (1530). This message may include a replacement HTTP URL, which is an address that replaces the root HTTP URL so that the terminal can access the Avatar ID List.

[0301] In step S1507, the IMS AS (230) may search for and select an MF / MRF (1530) (or DCMF, enMRF). The IMS AS (230) may select an MF / MRF (1530) implemented to support functions for avatar communication services.

[0302] In step S1508, the IMS AS (230) may provide the information received in step S1506 to the MF / MRF (1530), so as to request the MF / MRF (1530) to reserve media resources for the sender and receiver. The MF / MRF (1530) may allocate MDC1 resources for the sender and receiver. The MF / MRF (1530) may provide media resource allocation information to the IMS AS (230).

[0303] In step S1509, the IMS AS (230) may provide the media resource allocation information received from the MF / MRF (1530) to the DCSF (310).

[0304] In step S1510, DCSF (310) may respond to the session event control notification to IMS AS (230). This response may include information determined or judged in steps S1504, S1505, and S1505a, and information received in step S1509.

[0305] In step S1511, the IMS AS (230) may transmit an INVITE message to be sent to UE#2 (1520) to the S-CSCF (520). This message may include a modified SDP offer for the bootstrap DC, in which media resource information for the called party (including MDC1 resource allocation information) is reflected in the SDP offer for the bootstrap DC included in the INVITE message received in step S1501. In addition, this message may additionally include a Service Level User ID for UE#1 (1510).

[0306] In step S1512, the S-CSCF (520) can forward the INVITE message of step S1511 to the destination network side through the I-CSCF (510).

[0307] In step S1513, necessary negotiation procedures may be performed between the destination network and UE#2 (1520).

[0308] At step S1514, an 18X / PRACK / 200 OK (PRACK) / UPDATE message may be exchanged between the called network / UE#2 (1520) and the calling network UE#1 (1510).

[0309] In step S1515, the called network / UE#2 (1520) may send a 200 OK message to the S-CSCF (520). This message may additionally include a Service Level User ID for UE#2 (1520) based on the result determined for UE#2 (1520) by the called network / UE#2 (1520) as described in step S1505a.

[0310] In step S1516, the S-CSCF (520) may forward the 200 OK message of step S1515 to the IMS AS (230).

[0311] In step S1516a, if the 200 OK message includes a Service Level User ID for UE#2 (1520), the IMS AS (230) can determine whether it can accept the request from the UE#2 (1520) side (including obtaining the Avatar ID for UE#2 (1520) from the calling side) by checking the subscriber information / internal policy / setting for UE#2 (1520) as described in step S1502a.

[0312] In step S1517, the IMS AS (230) may transmit a Bootstrap Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1516. This message may include media resource allocation information provided by the UE#2 (1520) side and a Service Level User ID for the UE#2 (1520).

[0313] In step S1517a, if DCSF (310) receives a Service Level User ID for UE#2 (1520) in step S1517, it can obtain an Avatar ID List that can be provided to UE#2 (1520) from the Avatar Data Repository.

[0314] In step S1518, DCSF (310) may respond to the session event control notification to IMS AS (230).

[0315] In step S1519, the IMS AS (230) may transmit a 200 OK message to the UE (101).

[0316] In step S1520, a Bootstrap DC session can be established between the calling / receiving MF / MRF (1530) and UE#1(1510) / UE#2(1520). The DC Application List can be downloaded from the DCSF (310) to the UE (101) via the MF / MRF (1530). The UE (101) can request the network to download a designated DC Application, and the designated DC Application can be downloaded from the calling / receiving DCSF (310) to the UE (101) via the MF / MRF (1530). The Avatar ID List can be downloaded to the UE#1(1510) / UE#2(1520) via the calling / receiving DCSF (310). UE#1(1510) / UE#2(1520) can download or obtain a list of Avatar IDs (Avatar ID List) through DCSF (310). DCSF (310) can transmit the list of Avatar IDs (Avatar ID List) to UE#1(1510) / UE#2(1520).

[0317] In step S1521, subsequent procedures (e.g., application DC session procedures) may be performed.

[0318] FIGS. 16a and 16b illustrate examples of procedures between a UE and an IMS CN for performing an Application DC session establishment procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0319] Referring to FIGS. 16a and 16b, the terminal and the network can perform the Application DC session establishment procedure for using the IMS service through the following procedure.

[0320] At step S1600, an IMS session and a Bootstrap DC session can be established.

[0321] In step S1601, UE#1 (1610) may transmit a reINVITE (or INVITE) message to P-CSCF (210). This message may include at least one of an SDP offer for audio and / or video, an SDP offer for Application DC, and an Avatar ID of UE#1 (1610). UE#1 (1610) may provide an ID of an avatar selected by a user for avatar communication with UE#2 (1620) from among a list of Avatar IDs that may be provided to UE#1 (1610) in the Bootstrap DC procedure described in FIGS. 15a, 15b, and 15c as the Avatar ID of UE#1 (1610). The Avatar ID of UE#1 (1610) may be included within the SDP offer or outside the SDP offer. The INVITE message can be provided to the IMS AS (230) via the P-CSCF (210), I-CSCF (510), and S-CSCF (520).

[0322] In step S1602, the IMS AS (230) may perform DCSF routing decision and DCSF search procedures.

[0323] In step S1603, the IMS AS (230) may transmit an Application Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1601. This message may include the Avatar ID of UE#1 (1610). The Avatar ID of UE#1 (1610) may be included inside or outside the MediaInfoList included in the notification message.

[0324] In step S1604, DCSF (310) can determine whether a data channel can be provided and the DC control policy based on the information received in step S1603.

[0325] In step S1605, DCSF (310) may allow the DC end-to-end application stream to be exposed to the remote side.

[0326] In step S1605a, DCSF (310) can obtain avatar data corresponding to the Avatar ID from Avatar Data Repository (1310) using the Avatar ID of UE#1 (1610). DCSF (310) can apply the content corresponding to the determination on whether to obtain the Avatar ID List described in step S1505a of FIG. 15a to the determination on whether to obtain the Avatar data. In addition, if it is determined that it is appropriate or necessary for the called party to obtain the Avatar ID List in the procedures corresponding to FIGS. 15a, 15b, and 15c, it can be determined that it is appropriate or necessary for the called party to obtain the Avatar data corresponding to the Avatar ID of UE#1 (1610).

[0327] In step S1606, DCSF (310) may respond to the session event control notification to IMS AS (230). This response may include information determined or determined in steps S1604, S1605, and S1605a.

[0328] In step S1607, the IMS AS (230) may transmit a reINVITE message to the S-CSCF (520) to be sent to UE#2 (1620). This message may additionally include the Avatar ID of UE#1 (1610).

[0329] In step S1608, the S-CSCF (520) can forward the reINVITE message of step S1607 to the destination network side through the I-CSCF (510).

[0330] At step S1609, necessary negotiation procedures may be performed between the destination network and UE#2 (1620).

[0331] In step S1610, the called network / UE#2 (1620) may send a 200 OK message to the S-CSCF (520). This message may additionally include the Avatar ID of UE#2 (1620) based on the result determined for UE#2 (1620) by the called network / UE#2 (1620) as described in step S1605a.

[0332] In step S1611, the S-CSCF (520) may forward the 200 OK message of step S1610 to the IMS AS (230).

[0333] In step S1612, the IMS AS (230) may transmit an Application Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1611. This message may include the Avatar ID of UE#2 (1620).

[0334] In step S1612a, if DCSF (310) receives the Avatar ID of UE#2 (1620) in step S1612, it can obtain Avatar data corresponding to the Avatar ID from the Avatar Data Repository (1310).

[0335] In step S1613, DCSF (310) may respond to the session event control notification to IMS AS (230).

[0336] In step S1614, the IMS AS (230) may transmit a 200 OK message to the S-CSCF (520). This message may include information indicating that Avatar data for the Avatar ID of UE#1 (1610) has been successfully acquired (the answer for Avatar ID of UE#1).

[0337] In step S1615, the S-CSCF (520) may forward the 200 OK message of step S1614 to the P-CSCF (210).

[0338] In step S1616, a DC QoS flow can be set.

[0339] In step S1617, P-CSCF (210) may forward the 200 OK message of step S1615 to UE#1 (1610).

[0340] In step S1618, ACK messages can be exchanged between the sending side and the called side.

[0341] In step S1619, an application data channel between UE#1 (1610) and UE#2 (1620) can be activated.

[0342] In step S1619a, the Avatar data of UE#1 (1610) acquired from the Avatar Data Repository (1310) in step S1605a may be provided to UE#1 (1610) through a Bootstrap data channel for UE#1 (1610). In other words, it may be downloaded from DCSF (310) to MF / MRF (1530), and downloaded from MF / MRF (1530) to UE#1 (1610).

[0343] In step S1619b, the Avatar data of UE#2 (1620) acquired from the Avatar Data Repository (1310) in step S1612a may be provided to UE#2 (1620) through a Bootstrap data channel for UE#2 (1620). In other words, it may be downloaded from DCSF (310) to MF / MRF (1530), and downloaded from MF / MRF (1530) to UE#2 (1620).

[0344] In step S1620, application data channel traffic can be exchanged between UE#1 (1610) and UE#2 (1620).

[0345] FIGS. 17a and 17b illustrate examples of a negotiation procedure between a UE and an IMS CN for performing an Application DC session establishment procedure for using an IMS service in a communication system according to one embodiment of the present disclosure.

[0346] Referring to Figures 17a and 17b, the terminal and the network can perform the Application DC session establishment procedure for using the IMS service through the following procedure.

[0347] At step S1700, an IMS session and a Bootstrap DC session can be established.

[0348] In step S1701, UE#1 (1710) may transmit a reINVITE (or INVITE) message to P-CSCF (210). This message may include at least one of an SDP offer for audio and / or video, an SDP offer for Application DC, and an Avatar ID of UE#1. UE#1 (1710) may provide an ID of an avatar selected by a user for avatar communication with UE#2 (1720) from among a list of Avatar IDs that may be provided to UE#1 (1710) in the Bootstrap DC procedure described in FIGS. 15a, 15b, and 15c as the Avatar ID of UE#1 (1710). The Avatar ID of UE#1 (1710) may be included within the SDP offer or outside the SDP offer. The INVITE message can be provided to the IMS AS (230) via the P-CSCF (210), I-CSCF (510), and S-CSCF (520).

[0349] In step S1702, the IMS AS (230) may perform DCSF routing decision and DCSF search procedures.

[0350] In step S1703, the IMS AS (230) may transmit an Application Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1701. This message may include the Avatar ID of UE#1 (1710). The Avatar ID of UE#1 (1710) may be included inside or outside the MediaInfoList included in the notification message.

[0351] In step S1704, DCSF (310) can determine whether a data channel can be provided and the DC control policy based on the information received in step S1703.

[0352] In step S1705, DCSF (310) can generate MDC2 media information required for MF / MRF (1530) (including DCMF) of the calling party and the called party.

[0353] In step S1705a, DCSF (310) can obtain avatar data corresponding to the Avatar ID from Avatar Data Repository (1310) using the Avatar ID of UE#1 (1710). DCSF (310) can apply the content corresponding to the determination on whether to obtain the Avatar ID List described in step S1505a of FIG. 15a to the determination on whether to obtain the Avatar ID. In addition, if it is determined that it is appropriate or necessary for the called party to obtain the Avatar ID List in the procedures corresponding to FIGS. 15a, 15b, and 15c, it can be determined that it is appropriate or necessary for the called party to obtain the Avatar data corresponding to the Avatar ID of UE#1 (1710).

[0354] In step S1706, DCSF (310) may send a media indication message for media control to IMS AS (230) to request that appropriate resources be allocated to MF / MRF (1530).

[0355] In step S1707, the IMS AS (230) may provide the information received in step S1706 to the MF / MRF (1530) to request the MF / MRF (1530) to reserve media resources for the sender and receiver. The MF / MRF (1530) may allocate MDC2 resources for the sender and receiver. The MF / MRF (1530) may provide media resource allocation information to the IMS AS (230).

[0356] In step S1708, the IMS AS (230) may provide the media resource allocation information received from the MF / MRF (1530) to the DCSF (310).

[0357] In step S1709, DCSF (310) can communicate with DC Application Server (340) for DC resource control.

[0358] In step S1710, DCSF (310) may respond to the session event control notification to IMS AS (230). This response may include information determined or judged in steps S1704, S1705, and S1705a, and information received in steps S1708 and S1709.

[0359] In step S1711, the IMS AS (230) may transmit a reINVITE message to the S-CSCF (520) to be sent to UE#2 (1720). This message may additionally include the Avatar ID of UE#1 (1710).

[0360] In step S1712, the S-CSCF (520) can forward the reINVITE message of step S1711 to the destination network side through the I-CSCF (510).

[0361] In step S1713, necessary negotiation procedures may be performed between the destination network and UE#2 (1720).

[0362] In step S1714, the called network / UE#2 (1720) may send a 200 OK message to the S-CSCF (520). This message may additionally include the Avatar ID of UE#2 (1720) based on the result determined for UE#2 (1720) by the called network / UE#2 (1720) as described in step S1705a.

[0363] In step S1715, a DC QoS flow can be set.

[0364] In step S1716, the S-CSCF (520) may forward the 200 OK message of step S1714 to the IMS AS (230).

[0365] In step S1717, the IMS AS (230) may transmit an Application Session Event Control Notification message to the DCSF (310) based on the information included in the message received in step S1716. This message may include the Avatar ID of UE#2 (1720).

[0366] In step S1718, DCSF (310) can update media resource information of MF / MRF (1530) through IMS AS (230).

[0367] In step S1718a, if DCSF (310) receives the Avatar ID of UE#2 (1720) in step S1717, it can obtain Avatar data corresponding to the Avatar ID from the Avatar Data Repository (1310).

[0368] In step S1719, DCSF (310) may respond to the session event control notification to IMS AS (230).

[0369] In step S1720, the IMS AS (230) may transmit a 200 OK message to the S-CSCF (520). This message may include information indicating that Avatar data for the Avatar ID of UE#1 (1710) has been successfully acquired (the answer for Avatar ID of UE#1).

[0370] In step S1721, the S-CSCF (520) may forward the 200 OK message of step S1714 to the P-CSCF (210).

[0371] In step S1722, a DC QoS flow can be set.

[0372] In step S1723, P-CSCF (210) may forward the 200 OK message of step S1715 to UE#1 (1710).

[0373] In step S1724, ACK messages can be exchanged between the sending side and the called side.

[0374] In step S1725, an application data channel may be activated between UE#1 (1710) and MF / MRF (1530), and between MF / MRF (1530) and DC Application Server (340) (for UE#1 (1710)).

[0375] In step S1726, an application data channel between MF / MRF (1530) and UE#2 (1720), and between MF / MRF (1530) and DC Application Server (340) (for UE#2 (1720)) can be activated.

[0376] FIG. 18 illustrates an example of a procedure between a UE and an IMS CN for performing a UE-centric avatar communication establishment procedure based on an IMS service in a communication system according to one embodiment of the present disclosure.

[0377] Referring to FIG. 18, the terminal and the network can perform a UE-centric avatar communication establishment procedure based on an IMS service through the following procedure.

[0378] In step S1801, an IMS session and a Bootstrap DC session can be established.

[0379] In step S1802, an RTP and Application DC session can be established between UE-A (1810) and UE-B (1860).

[0380] In step S1803, UE-A (1810) can capture, render, and encode avatar data. For example, UE-A (1810) can generate animated avatar media by combining and processing avatar data of UE-A (1810) received from the network through the procedure described in FIG. 14 and animation data consisting of facial expression information, gestures, etc. obtained through the camera, various sensors, etc. of UE-A (1810).

[0381] In step S1804, UE-A (1810) may provide animated avatar media (e.g., audio / video rendered encoded media) of UE-A (1810) to UE-B (1860) via RTP.

[0382] In step S1805, UE-B (1860) may provide animated avatar media (e.g., audio / video rendered encoded media) of UE-B (1860) to UE-A (1810) via RTP.

[0383] In step S1806, UE-A (1810) can decode and render the animated avatar media (e.g., audio / video rendered encoded media) of UE-B (1860) received in step S1805, and display it on the user device of UE-A (1810).

[0384] FIGS. 19a and 19b illustrate examples of negotiation procedures between a UE and an IMS CN for performing a network-centric avatar communication establishment procedure based on an IMS service in a communication system according to one embodiment of the present disclosure.

[0385] Referring to FIGS. 19a and 19b, the terminal and the network can perform a network-centric avatar communication establishment procedure based on an IMS service through the following procedure.

[0386] In step S1901, an IMS session and a Bootstrap DC session can be established.

[0387] In step S1902, UE-A (1910) may decide to request to perform media rendering on the network depending on the state of UE-A (1910).

[0388] In step S1903, UE-A (1910) and the IMS network may negotiate the necessary avatar media rendering. This negotiation may include information exchange necessary for performing the operation of generating animated avatar media described in step S1803 of FIG. 18 in the IMS network, rather than in UE-A (1910).

[0389] In step S1903a, UE-B (1920) and the IMS network may negotiate the necessary avatar media rendering. This negotiation may include information exchange necessary for performing the operation of generating animated avatar media described in step S1903 of FIG. 18 in the IMS network, rather than in UE-B (1920).

[0390] In step S1904, UE-A (1910) and the IMS network may establish an Application DC session for avatar communication based on the negotiation procedure of step S1903. The Application DC session establishment may follow the DC session procedure described in FIGS. 17a and 17b.

[0391] In step S1904a, UE-B (1920) and the IMS network may establish an Application DC session for avatar communication based on the negotiation procedure of step S1903a. The Application DC session establishment may follow the DC session procedure described in FIGS. 17a and 17b.

[0392] In step S1905, UE-A (1910) and the IMS network may negotiate to anchor at least one of the audio, video, and avatar media of UE-A (1910) to MF / MRF (1530).

[0393] In step S1906, UE-B (1920) and the IMS network may negotiate to anchor at least one of the audio, video, and avatar media of UE-A (1910) to MF / MRF (1530).

[0394] In step S1907, UE-A (1910) can transmit animation data of UE-A (1910) described in step S1803 of FIG. 18 to MF / MRF (1530).

[0395] In step S1908, MF / MRF (1530) can generate animated avatar media of UE-A (1910) by combining and processing the Avatar data of UE-A (1910) downloaded from the Avatar Data Repository (1310) through the DCSF (310) and the animation data of UE-A (1910) received in step S1907.

[0396] In step S1909, MF / MRF (1530) can transmit the animated avatar media of UE-A (1910) generated in step S1908 to UE-B (1920) via RTP.

[0397] In step S1910a, [Option A] UE-B (1920) can transmit animation data of UE-B (1920) described in step S1803 of FIG. 18 to MF / MRF (1530).

[0398] In step S1911a, [Option A] MF / MRF (1530) can generate animated avatar media of UE-B (1920) by combining and processing the Avatar data of UE-B (1920) downloaded from the Avatar Data Repository (1310) through the DCSF (310) and the animation data of UE-B (1920) received in step S1910.

[0399] In step S1912a, [Option A] MF / MRF (1530) can transmit the animated avatar media of UE-B (1920) generated in step S1911 to UE-A (1910) via RTP.

[0400] In step S1913b, [Option B] UE-B (1920) can transmit animated avatar media of UE-B (1920) to UE-A (1910) via RTP.

[0401] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples to easily explain the technical contents of the present disclosure and to help the 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 that other modified examples based on the technical idea of ​​the present disclosure are possible. In addition, each of the above embodiments can be combined and operated with each other as needed. For example, parts of one embodiment of the present disclosure and another embodiment can be combined with each other to operate a base station and a terminal. In addition, other modified examples based on the technical idea of ​​the above embodiments can be implemented in various systems such as an FDD LTE system, a TDD LTE system, a 5G or NR system, etc.

Claims

1. A method performed by a first UE (user equipment) in a wireless communication system, A step of obtaining a list of avatar IDs (identities) from an avatar repository through a network; A step of selecting an avatar ID from the above avatar ID list; A step of obtaining avatar data associated with the avatar ID from the avatar storage through the network; A step of generating avatar media based on the above avatar data and animation data; and A method comprising the step of transmitting the above avatar media to a second UE.

2. In paragraph 1, A method wherein the avatar storage includes at least one of the avatar ID list, the avatar ID, and the avatar data.

3. In paragraph 1, The step of obtaining the list of avatar IDs from the avatar storage through the above network is as follows: A method comprising the step of receiving, from the DCSF, the list of avatar IDs obtained from the avatar storage by means of the DCSF (Data Channel Signaling Function).

4. In paragraph 1, The step of obtaining avatar data associated with the avatar ID from the avatar storage through the above network is as follows. A method comprising the step of receiving the avatar data acquired from the avatar storage by the MF (Media Function).

5. In paragraph 1, A method wherein the above animation data includes data generated based on information acquired through a sensor.

6. In paragraph 1, A method wherein the above avatar media is animated avatar media generated by processing and rendering the avatar data and the animation data.

7. In paragraph 1, A step of determining whether to request avatar animation to be performed on the above network; A step of performing negotiation between the above network and avatar animation; Based on the above negotiation, a step of establishing an application data channel related to avatar communication; and Further comprising a step of transmitting the above animation data to MF, The above avatar media is generated by the MF based on the animation data and the avatar data, A method wherein the generated avatar media is transmitted to the second UE by the MF.

8. In paragraph 1, A method further comprising the step of downloading the avatar data through a bootstrap data channel using the avatar ID and the ID of the first UE.

9. In a wireless communication system, the first UE (user equipment) Transmitter and receiver; and At least one processor coupled to the transceiver, At least one processor of the above, Obtain a list of avatar IDs (identities) from the avatar repository over the network, Select an avatar ID from the above avatar ID list, Obtaining avatar data associated with the avatar ID from the avatar storage through the above network, Generate avatar media based on the above avatar data and animation data, A first UE transmitting the above avatar media to a second UE.

10. In paragraph 9, The above avatar storage is a first UE including at least one of the avatar ID list, the avatar ID, and the avatar data.

11. In paragraph 9, At least one processor of the above, A first UE that receives the avatar ID list obtained from the avatar storage by means of DCSF (Data Channel Signaling Function).

12. In paragraph 9, At least one processor of the above, A first UE that receives the avatar data acquired from the avatar storage by the MF (Media Function).

13. In paragraph 9, The above animation data includes data generated based on information acquired through a sensor, a first UE.

14. In paragraph 9, The above avatar media is an animated avatar media generated by processing and rendering the avatar data and the animation data, the first UE.

15. In paragraph 9, At least one processor of the above, Decide to request that the above network perform avatar animation, Performs network and avatar animation negotiations above, Based on the above negotiation, an application data channel related to avatar communication is established, The above animation data is sent to MF, The above avatar media is generated by the MF based on the animation data and the avatar data, The above generated avatar media is transmitted to the second UE by the MF, the first UE.

Images