WO2024096390A1 - 미디어 콜 서비스를 수행하기 위한 방법 및 장치 - Google Patents

미디어 콜 서비스를 수행하기 위한 방법 및 장치 Download PDF

Info

Publication number
WO2024096390A1
WO2024096390A1 PCT/KR2023/016253 KR2023016253W WO2024096390A1 WO 2024096390 A1 WO2024096390 A1 WO 2024096390A1 KR 2023016253 W KR2023016253 W KR 2023016253W WO 2024096390 A1 WO2024096390 A1 WO 2024096390A1
Authority
WO
WIPO (PCT)
Prior art keywords
avatar
information
terminal
sdp
movement
Prior art date
Application number
PCT/KR2023/016253
Other languages
English (en)
French (fr)
Inventor
배재현
이지철
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Publication of WO2024096390A1 publication Critical patent/WO2024096390A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/50—Business processes related to the communications industry
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T13/00—Animation
    • G06T13/20—3D [Three Dimensional] animation
    • G06T13/40—3D [Three Dimensional] animation of characters, e.g. humans, animals or virtual beings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/20—Analysis of motion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices

Definitions

  • This disclosure relates to audio or video media call services, and more specifically, to a method and apparatus for processing an avatar call service.
  • 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and includes sub-6 GHz ('Sub 6GHz') bands such as 3.5 gigahertz (3.5 GHz) as well as millimeter wave (mm) bands such as 28 GHz and 39 GHz. It is also possible to implement it in the ultra-high frequency band ('Above 6GHz') called Wave.
  • 'Sub 6GHz' sub-6 GHz
  • mm millimeter wave
  • Wave ultra-high frequency band
  • 6G mobile communication technology which is called the system of Beyond 5G
  • Terra is working to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low delay time that is reduced to one-tenth. Implementation in Terahertz bands (e.g., 95 GHz to 3 THz) is being considered.
  • ultra-wideband services enhanced Mobile BroadBand, eMBB
  • ultra-reliable low-latency communications URLLC
  • massive machine-type communications mMTC
  • numerology support multiple subcarrier interval operation, etc.
  • dynamic operation of slot format initial access technology to support multi-beam transmission and broadband
  • definition and operation of BWP Band-Width Part
  • New channel coding methods such as LDPC (Low Density Parity Check) codes for data transmission and Polar Code for highly reliable transmission of control information
  • L2 pre-processing L2 pre-processing
  • dedicated services specialized for specific services. Standardization of network slicing, etc., which provides networks, has been carried out.
  • V2X Vehicle-to-Everything
  • NR-U New Radio Unlicensed
  • UE Power Saving NR terminal low power consumption technology
  • NTN Non-Terrestrial Network
  • IAB provides a node for expanding the network service area by integrating intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, and wireless backhaul links and access links.
  • Intelligent factories Intelligent Internet of Things, IIoT
  • Mobility Enhancement including Conditional Handover and DAPS (Dual Active Protocol Stack) handover
  • 2-step Random Access (2-step RACH for simplification of random access procedures)
  • Standardization in the field of wireless interface architecture/protocol for technologies such as NR is also in progress
  • 5G baseline for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technology Standardization in the field of system architecture/services for architecture (e.g., Service based Architecture, Service based Interface) and Mobile Edge Computing (MEC), which provides services based on the location of the terminal, is also in progress.
  • NFV Network Functions Virtualization
  • SDN Software-Defined Networking
  • FD-MIMO full dimensional MIMO
  • array antennas to ensure coverage in the terahertz band of 6G mobile communication technology.
  • multi-antenna transmission technology such as Large Scale Antenna, metamaterial-based lens and antenna to improve coverage of terahertz band signals, high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum), RIS ( In addition to Reconfigurable Intelligent Surface technology, Full Duplex technology, satellite, and AI (Artificial Intelligence) to improve the frequency efficiency of 6G mobile communication technology and system network are utilized from the design stage and end-to-end.
  • 3D Volumetric content users can create 3D data (3D Asset) files in the form of 3D objects using images shot with a multi-camera, allowing users to combine real environments and virtual 3D objects in AR and metaverse environments. You can place the object in the desired location and view the image in three dimensions in any desired direction.
  • 3D Asset 3D data
  • 3D volumetric content still uses traditional 2D video codecs or binary compression methods for compression, but support for 3D volumetric content requires new technologies in the end-to-end workflow.
  • These technologies include scene description technology to form a scene and define its components; A new format that supports 3D object geometry information and texture information constituting a 3D object and the connection and compression of these 3D object components; A new format that expresses the movement (animation, etc.) of a 3D object and includes connection with 3D object data and expression information to support it; Media processing techniques to reduce format redundancy; New delivery protocols and mechanisms to increase the efficiency of content delivery may be included.
  • 3D Volumetric content e.g. 3D avatars
  • IMS IP Multimedia Subsystem
  • the present disclosure provides a method and device for providing an interactive service using data of avatar media (eg, 3D avatar).
  • avatar media eg, 3D avatar
  • the present disclosure relates to a method of performing a media call service of an originating terminal in a wireless communication network, including information indicating the content type of at least one avatar and whether the originating terminal supports movement of the at least one avatar.
  • receiving an SDP response message from the called terminal including information on whether the called terminal supports movement of the at least one avatar
  • SDP session description protocol
  • the present disclosure relates to a method of performing a media call service of a terminating terminal in a wireless communication network, including information indicating the content type of at least one avatar and the originating terminal regarding the movement of the at least one avatar.
  • SDP session description protocol
  • the present disclosure provides an originating terminal that performs a media call service in a wireless communication network, comprising: a transceiver; And controlling the transceiver to propose a first SDP (session description protocol) that includes information indicating the content type of at least one avatar and information about whether the sending terminal supports movement of the at least one avatar.
  • a message is transmitted to a terminating terminal, and in response to the first SDP offer message, an SDP response message containing information on whether the terminating terminal supports the movement of the at least one avatar is sent to the receiving terminal.
  • Received from a terminal based on the support information of the called terminal included in the SDP response message, generates motion information of the at least one avatar, and uses the generated motion information to provide an avatar call service with the called terminal.
  • a terminal including a processor configured to perform is provided.
  • the present disclosure provides a receiving terminal that performs a media call service in a wireless communication network, comprising: a transceiver; And controlling the transceiver to receive a first SDP offer message from the calling terminal, including information indicating the content type of at least one avatar and information about whether the calling terminal supports movement of the at least one avatar, In response to the first SDP offer message, an SDP response message containing information on whether the called terminal supports the movement of the at least one avatar is transmitted to the calling terminal, and the incoming terminal included in the SDP response message is transmitted.
  • a terminal including a processor configured to generate motion information of the at least one avatar based on information on whether the terminal is supported, and to perform an avatar call service with the calling terminal using the generated motion information.
  • a method of a transmitting device comprising: transmitting, to a receiving device, a Session Description Protocol (SDP) offer message for negotiation of parameters associated with avatar data and related motion information; And, from the receiving device, an SDP answer including avatar data provided by the receiving terminal and related motion data information generated based on the avatar data and related motion information provided by the transmitting terminal in the related information included in the SDP offer message. It may include receiving a message.
  • SDP Session Description Protocol
  • a method of a receiving device comprising: receiving, from a transmitting device, a Session Description Protocol (SDP) offer message for negotiation of parameters associated with avatar data and related motion information; Based on the avatar data and related motion data related information provided by the transmitting terminal included in the SDP offer message, generating an SDP answer message including avatar data and related motion data related information of the receiving terminal; And it may include transmitting the SDP answer message to the transmitting device.
  • SDP Session Description Protocol
  • a transmitting device comprising: a transceiver; and a controller, wherein the controller: transmits, to a receiving device, an SDP (Session Description Protocol) offer message for negotiation of parameters associated with avatar data and related motion information, included in the SDP offer message, from the receiving device; It can be configured to receive an SDP answer message containing avatar data and related motion data-related information of the receiving device generated based on the avatar data and related motion data-related information.
  • SDP Session Description Protocol
  • a transceiver In a receiving device according to another aspect of the present disclosure, a transceiver; and a controller, wherein the controller: receives, from a transmitting device, a Session Description Protocol (SDP) offer message for negotiation of parameters associated with avatar data and related motion information, and an avatar of the transmitting device included in the SDP offer message. Based on the data and related motion data-related information, an SDP answer message containing avatar data and related motion data-related information of the receiving device may be generated, and the SDP answer message may be transmitted to the transmitting device.
  • SDP Session Description Protocol
  • the service can be used through the provision of avatar data provided by each terminal and movement change amount information of the corresponding avatar object.
  • Figure 1A illustrates the structure of a third generation (3G) network.
  • FIG. 1b illustrates the structure of a long term evolution (LTE) network.
  • LTE long term evolution
  • FIG. 2a shows the structure of the voice and video codec and RTP (Real-time Transport Protocol)/UDP (User Datagram Protocol)/IP (Internet Protocol) protocol of a VoLTE (voice over LTE) support terminal according to an embodiment of the present disclosure. Illustrate.
  • RTP Real-time Transport Protocol
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • CMR Codec Mode Request
  • FIG. 3 illustrates the structure of a Temporary Maximum Media Bit-Rate Request (TMMBR) message transmitted through the RTCP protocol according to an embodiment of the present disclosure.
  • TMBR Temporary Maximum Media Bit-Rate Request
  • FIG. 4 illustrates the structure of a 5th Generation (5G) network for transmitting avatar content and related motion information according to an embodiment of the present disclosure.
  • 5G 5th Generation
  • Figure 5 illustrates the protocol architecture of a 5G network for transmitting avatar content and related motion information according to an embodiment of the present disclosure.
  • FIG. 6 shows that in a method of transmitting avatar content using an IP multimedia subsystem according to an embodiment of the present disclosure, a transmitting terminal (UE A) and a receiving terminal (UE B) negotiate parameters and related motion information, and wired Alternatively, a procedure for securing quality of service (QoS) of a wireless transmission path is exemplified.
  • QoS quality of service
  • Figure 7 shows that a transmitting terminal (UE A) and a receiving terminal (UE B) negotiate avatar content and related motion information using an IP multimedia subsystem according to an embodiment of the present disclosure, and use different This illustrates the procedure for transmission through a type of protocol.
  • Figure 8 shows that in a method of transmitting avatar content using an IP multimedia subsystem according to an embodiment of the present disclosure, a transmitting terminal (UE A) and a receiving terminal (UE B) provide parameters and related motion information, a codec for additional video calls, and When preparing for avatar call setup, such as negotiating parameters and transmitting avatar data, the procedure for using the service using 2D video call and then switching to avatar call is exemplified.
  • UE A transmitting terminal
  • UE B receiving terminal
  • Figure 9 shows an example of an SDP offer according to an embodiment of the present disclosure.
  • Figure 10 shows an example of an SDP offer according to an embodiment of the present disclosure.
  • Figure 11 is a diagram illustrating a method of performing a media call by a calling terminal according to the present disclosure.
  • Figure 12 is a diagram illustrating a method of performing a media call by a receiving terminal according to the present disclosure.
  • FIG. 13 is a diagram illustrating the configuration of a terminal (UE) device according to the present disclosure.
  • Figure 14 is a diagram illustrating the device configuration of an IMS entity according to the present disclosure.
  • each block of the processing flow diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions.
  • These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions.
  • These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory
  • the instructions stored in may also be capable of producing manufactured items containing instruction means to perform the functions described in the flow diagram block(s).
  • Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). Additionally, it should be noted that in some alternative execution examples it is possible for the functions mentioned in the blocks to occur out of order. For example, it is possible for two blocks shown in succession to be performed substantially at the same time, or it may be possible for the blocks to be performed in reverse order depending on the corresponding function.
  • ' ⁇ unit' used in this embodiment refers to software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and ' ⁇ unit' performs certain roles. do.
  • ' ⁇ part' is not limited to software or hardware.
  • the ' ⁇ part' may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Therefore, according to some embodiments, ' ⁇ part' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and processes. Includes scissors, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.
  • components and 'parts' may be combined into a smaller number of components and 'parts' or may be further separated into additional components and 'parts'. Additionally, components and 'parts' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card. Additionally, according to some embodiments, ' ⁇ unit' may include one or more processors.
  • terminal' or 'device' used in this specification refers to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), and terminal. , referred to as a Subscriber Unit, Subscriber Station (SS), wireless device, wireless communication device, Wireless Transmit/Receive Unit (WTRU), mobile node, mobile, or other terms. It can be.
  • Various embodiments of the terminal include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, and a digital camera with a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include devices, gaming devices with wireless communication functions, music storage and playback home appliances with wireless communication functions, Internet home appliances capable of wireless Internet access and browsing, as well as portable units or terminals that integrate combinations of such functions.
  • the terminal may include, but is not limited to, an M2M (Machine to Machine) terminal and an MTC (Machine Type Communication) terminal/device.
  • M2M Machine to Machine
  • MTC Machine Type Communication
  • the terminal may be referred to as an electronic device or simply a device.
  • the present disclosure provides multimedia content capturing, processing, pre-processing, post-processing, metadata delivery, 3D avatar (face, full body) including geometry information of a 3D object and related texture information. , half body etc.), etc., and decoding and rendering of 3D object content.
  • the 3D avatar content is a 3D asset file in the form of a mesh consisting of 3D object geometry and texture, or a 3D file in the form of point cloud compression (PCC) consisting of a 3D projection image and 3D object geometry information. It can refer to an Asset file.
  • PCC point cloud compression
  • 3D content can be consumed using head mounted devices (HMD) and Augmented Reality (AR).
  • HMD head mounted devices
  • AR Augmented Reality
  • the user cannot view the entire 360-degree 3D content at once, and only a portion of it is visible through the user's perspective, referred to as a random camera in a virtual space, taking into account the view direction. can see.
  • the entire 3D object requires a very high resolution to provide sufficiently high quality content considering view direction, etc. at any location.
  • a 3D content transmission device requires a lot of bandwidth to send the entire 3D object to a high-definition multi-camera, it can receive input from the multi-camera and express one or multiple objects in space.
  • the 3D content transmission device generates the input as a 3D object based on the corresponding multi-camera information, and can be transformed into a mesh or PCC form to compress each 3D object in a way that is easy to transmit, and the relationship between 3D objects is unified. It can be expressed as a scene description, etc.
  • a 3D content transmission device compresses images/videos and compresses content so that mesh-shaped objects have appropriate parameters (geometry point and texture resolution) considering the bandwidth and rendering performance of the terminal (display resolution, memory, etc.).
  • 3D object content that reflects the requirements of the network and transmitting/receiving terminals can be created by adjusting the number of points to express the object.
  • Interactive services require very low latency to support two-way communication, and when used to transmit high-quality 3D objects mentioned above, additional requirements arise.
  • high-quality 3D object content is generated, and when using an interactive service, only the movement change amount of the object can be transmitted and the movement of the 3D object can be output.
  • This disclosure introduces a delivery technique for 3D object content and related motion change information for an interactive 3D avatar object.
  • SDP session description protocol
  • the sending terminal enables interactive 3D avatar delivery without the need to continuously send its 3D avatar object to the recipient.
  • Bandwidth can be saved by delivering only the movement change amount information of the 3D avatar object required by the receiving terminal.
  • the sending terminal can transmit a 2D image/video to allow the receiving terminal to calculate the actual change amount of the received 3D avatar object.
  • the amount of movement change of the 3D avatar object of the sending terminal may be rendered on the receiving terminal.
  • 1A illustrates the structure of a 3G network.
  • the 3G network 100a includes a user equipment (UE) 110a, a NodeB 120a, a Radio Network Controller (RNC) 130a, and a Mobile Switching Center (MSC) 140a.
  • the 3G network 100a is connected to other mobile communication networks and public switched telephone network (PSTN).
  • PSTN public switched telephone network
  • voice is compressed/restored using an Adaptive Multi-Rate (AMR) codec, and the AMR codec is used by the terminal (UE) (110a) and the MSC to provide a two-way call service. It is installed at (140a).
  • AMR Adaptive Multi-Rate
  • the MSC 140a converts the voice compressed with the AMR codec into PCM (Pulse Code Modulation) format and transmits it to the PSTN, or vice versa, the MSC 140a receives voice in the PCM format from the PSTN and transmits it to the PSTN. It is compressed with AMR codec and transmitted to the base station (NodeB) 120a.
  • the RNC 130a can control the call bit rate of the voice codec installed in the UE 110a and the MSC 140a in real time using a Codec Mode Control (CMC) message.
  • CMC Codec Mode Control
  • the voice codec is only installed in the terminal, and voice frames compressed at an interval of 20 ms at the sending terminal are transmitted to the base station or in the middle of the transmission path. It is not restored at the network node located in , but is transmitted to the counterpart terminal.
  • Figure 1B illustrates the structure of an LTE network.
  • the LTE (4G) network is at least one of the UE (110b), eNodeB (120b, 130b), and Serving Gateway (S-GW)/Packet Data Network Gateway (P-GW) (140b, 150b) may include.
  • S-GW Serving Gateway
  • P-GW Packet Data Network Gateway
  • the voice codec is only installed in the UE 110b, and each terminal (UE) 110b can adjust the voice bit rate of the other terminal using a Codec Mode Request (CMR) message.
  • CMR Codec Mode Request
  • the base station eNodeB (120b, 130b)
  • eNodeB 120b, 130b
  • RRH Remote Radio Head
  • DU Digital Unit
  • eNodeB 120b, 130b
  • S-GW S-GW
  • P-GW P-GW
  • FIG. 2A shows the structure of the voice and video codec and RTP/UDP/IP protocol of a VoLTE support terminal and the Stream Control Transmission Protocol (SCTP)/UDP/IP protocol for transmitting the media-related additional information according to an embodiment of the present disclosure. exemplifies.
  • SCTP Stream Control Transmission Protocol
  • the IP protocol 23 located at the bottom of this structure is connected to PDCP (Packet Data Convergence Protocol) located at the top of the protocol structure.
  • media data e.g., speech, video, text
  • SCTP protocol (24)/ It can be transmitted via UDP protocol (22)/ IP protocol (23).
  • the RTP/UDP/IP header is attached to the compressed media frame (media data) of the voice and video codec, and the STCP/UDP/IP header is attached to media-related additional information to be transmitted to the other terminal through the LTE network. You can.
  • the other terminal can receive compressed and transmitted media packets (media data) from the network, restore the media, listen to it through a speaker, and display and view the media.
  • the timestamp information in the RTP protocol header can be used to synchronize the two media (voice and video).
  • Figure 2b illustrates a CMR message
  • the CMR message may be a CMR message used to adjust the bit rate at which the other terminal compresses voice according to changes in transmission status during a call.
  • the upper portion of FIG. 2B corresponds to the payload format 210, a CMR field 211, a Table of Contents (ToC) field 212, and a compressed media field containing compressed media data. 213 and/or a padding bit field 214 containing padding bits.
  • ToC Table of Contents
  • a 4-bit CMR field 211 is added to the voice frame (media data) compressed in the voice codec indicated by speech to display the bit rate requested to be used by the voice codec of the other terminal,
  • a 4-bit ToC field 212 may be added to indicate the bit rate and type of compressed and transmitted frame (media data).
  • VoLTE can support voice codecs such as Adaptive Multi-Rate (AMR), Adaptive Multi-Rate Wideband (AMR-WB), and Enhanced Voice Services (EVS).
  • AMR Adaptive Multi-Rate
  • AMR-WB Adaptive Multi-Rate Wideband
  • EVS Enhanced Voice Services
  • the CMR message may be transmitted through the RTCP protocol (RTP Control Protocol) in addition to the payload protocol.
  • RTCP RTP Control Protocol
  • Figure 3 illustrates the structure of a TMMBR message transmitted through the RTCP protocol according to an embodiment of the present disclosure.
  • the TMMBR message may be included in RTCP to dynamically adjust the bit rate of the image codec installed in the other terminal during the call.
  • the TMMBR message may include an Exp field 310 indicating the value of Exp and a Mantissa field 320 indicating the value of Mantissa.
  • the UE (terminal) receiving the TMMBR message can maintain the bit rate of the compressed image below “Mantissa ⁇ 2Exp” bps based on the Exp field 310 and the Mantissa field 320. This "Mantissa ⁇ 2Exp" value can be set equal to or less than the bit rate negotiated before starting the video call.
  • Figure 4 illustrates the structure of a 5G network for transmitting avatar data and related movement information according to an embodiment of the present disclosure.
  • 3D avatar data can be captured and generated by a multi-camera configured as a sphere ball rig. Additionally, the 3D avatar-related movement information is obtained from an infrared camera-based depth camera mounted on the UE 410 (a type of camera that can calculate the depth of pixels to display a 3D image) or the amount of change in movement in a general image. It can be created based on
  • the 5G network 400 may include at least one of a UE 410, a gNodeB (gNB) 420, 430, and a User Plane Function (UPF) 440.
  • UE 410 may be connected to a 360 degree camera.
  • 5G nodes corresponding to eNodeB, S-GW, and P-GW of LTE are gNB (410), UPF (440), and DN (Data Network).
  • 3D avatar data is transmitted between devices through LTE, 5G sidelink, or Wi-Fi Direct using unlicensed frequency bands without passing through a base station (e.g., gNB), or through a USB-C cable. It can be transmitted directly between livers. When USB-C is used, large amounts of data can be transferred at low rates without errors, and video can be compressed on the device rather than the camera.
  • Figure 5 illustrates the protocol architecture of a 5G network for transmitting avatar data and related movement information according to an embodiment of the present disclosure.
  • Images captured from multi-cameras are reconstructed into various 3D asset data types (Mesh or PCC, etc.) according to the requirements negotiated between the sender (transmitting terminal) and the receiver (receiving terminal), and the creation type of the 3D object is PCC.
  • the projection image created in the form of a patch is compressed using a video codec (511) (such as AVC (Advanced Video Coding) or HEVC (High Efficiency Video Coding)), or if the creation type of the 3D object is Mesh, the 3D object
  • the geometry information is stored in binary form and compressed using a binary compression codec (such as Draco), and the texture image can be compressed using a video codec (such as AVC or HEVC).
  • 3D object-related animation information (e.g. change in facial feature points when the 3D object is a human face, etc.) can be stored in binary form and transmitted along with 3D data or transmitted using a separate data channel.
  • the generated 3D Asset data is delivered using various transport protocols 512, such as RTP and Internet Protocol 513, including the address of the receiving terminal, and transmitted to a 5G NR (New Radio) modem. , can be transmitted to the receiving terminal through the uplink.
  • transport protocols 512 such as RTP and Internet Protocol 513, including the address of the receiving terminal
  • 5G NR New Radio
  • the NR modem has a new protocol called SDAP (Service Data Adaptation Protocol) 521, which is located on top of PDCP.
  • SDAP Service Data Adaptation Protocol
  • the receiving terminal obtains a payload by removing the header of each protocol from the received PDU (protocol data unit) and restores the payload in the form of compressed 3D data (3D Asset) fed into the 3D object renderer ( recover) is possible.
  • the restored 3D data is 3D modeled (if necessary), and the data can be placed in 3D form in virtual space.
  • a view matching the user's current viewport may be rendered on a display connected to the receiving terminal.
  • the user's current view port may vary depending on the application and service provider. For example, in the case of a 3D avatar call, it can be assumed that the user looks at the 3D avatar from the front at a specific spatial location depending on the user's viewpoint.
  • the method of setting a specific spatial location is to actually measure it by taking into account the distance between the user and the display, the size of the space, and the size of the 3D avatar, or to adjust and set it to a certain size according to the display resolution size and provide it to the user based on the corresponding setting value.
  • 3D content can be displayed.
  • Figure 6 shows a transmission method for performing an avatar-type video call using an IP multimedia subsystem (IMS) according to an embodiment of the present disclosure, where a transmitting terminal (UE A) and a receiving terminal (UE B) negotiate parameters. (negotiate) and illustrates a procedure for ensuring QoS of a wired or wireless transmission path.
  • IMS IP multimedia subsystem
  • the transmitting terminal (UE A) 630 and the receiving terminal (UE B) 632 use an SDP message (SDP offer message 602/SDP answer message 604) to display the 3D avatar data type and related information.
  • Information e.g., 3D avatar type (Face or half body or full body), avatar-related texture resolution, etc.
  • animation-related information of the 3D avatar e.g., amount of change in movement of feature point
  • SDP-based negotiation may be performed to negotiate parameter(s) for 3D avatar data between the transmitting terminal (UE A) and the receiving terminal (UE B).
  • the transmitting terminal (UE A) 630 selects a video call using a 3D avatar as a service when connecting an interactive service with the receiving terminal (UE B) 632. You can.
  • the transmitting terminal 630 may determine at least one of codec(s) and 3D avatar-related parameter(s) and insert it into the payload of the SDP message.
  • the inserted codec(s) or 3D avatar-related parameter(s) may reflect terminal performance of the transmitting terminal 630 and user preference for supportable sessions (such as the user's selection in step 601).
  • the transmitting terminal 630 may create an SDP message (eg, SDP offer) including bandwidth requirements and each characteristic, and allocate a local port number for each possible media flow.
  • the transmitting terminal 630 may include the SDP payload in a SIP (Session Initiation Protocol) invite message and transmit it to the receiving terminal 632.
  • SIP Session Initiation Protocol
  • the transmitting terminal 630 may transmit the SIP invite message to a Proxy Call Session Control Function (P-CSCF) (e.g., P-CSCF#1 640) assigned to the transmitting terminal 630. .
  • P-CSCF Proxy Call Session Control Function
  • P-CSCF#1 can examine media parameters (components). If P-CSCF#1 640 contains bandwidth authorization limitation information from the P-CSCF local policy, or (if available) from the Policy and Charging Rules Function (PCRF) or Policy Control Function (PCF) Based on , if it is confirmed that use of the media parameter is not permitted within an IMS session, a session initiation attempt (i.e., the SIP invite message) may be rejected. This rejection is originating to re-attempt session initiation using media parameters permitted by the network's local policy in P-CSCF#1 640, according to the procedures specified in IETF RFC 3261 [12]. It may contain sufficient information about the UE (e.g., UE A 630).
  • PCRF Policy and Charging Rules Function
  • PCF Policy Control Function
  • P-CSCF#1 640 may allow the initial session start attempt to continue. At this stage, whether the P-CSCF should interact with the PCRF/PCF is based on operator policy. P-CSCF#1 (640) can forward the INVITE message to S-CSCF (Session Call Session Control Function) #1 (642). S-CSCF#1 (642) can check media parameters (components).
  • S-CSCF Session Call Session Control Function
  • S-CSCF#1 642 may reject the session start attempt. . This rejection re-attempts session initiation using media parameters permitted by the calling user's subscriber profile and the local policy of the network in S-CSCF#1 642, according to the procedures specified in IETF RFC 3261 [12]. It may contain sufficient information about the sending UE to do so.
  • S-CSCF#1 642 may allow the initial session start attempt to continue.
  • S-CSCF#1 642 can transmit an INVITE message to S-CSCF#2 (652) through I-CSCF (Interrogating Call Session Control Function) #2 (654) through the S-S session flow procedure.
  • I-CSCF Interrogating Call Session Control Function
  • S-CSCF#2 can check media parameters (components). If S-CSCF#2 652 confirms that the media parameter is not permitted to be used within an IMS session, based on local policy or the subscriber profile of the terminating user (e.g., UE B 632) , an attempt to start a session can be rejected. This rejection re-attempts session initiation using media parameters permitted by the calling user's subscriber profile and the local policy of the network in S-CSCF#2 652, according to the procedures specified in IETF RFC 3261 [12]. It may contain sufficient information about the called UE to do so.
  • S-CSCF#2 652 may allow the initial session start attempt to continue.
  • S-CSCF#2 (652) can transmit the INVITE message to P-CSCF#2 (650).
  • P-CSCF#2 (650) can examine media parameters (components). If P-CSCF#2 650 (based on P-CSCF local policy, or bandwidth authorization limitation information from PCRF or PCF (if available)) media parameters are used within the IMS session, If it is confirmed that this is not allowed, the session initiation attempt may be rejected locally in the network of P-CSCF#2 650, according to the procedures specified in IETF RFC 3261 [12]. It may contain sufficient information about the originating UE to re-attempt session start using media parameters allowed by policy.
  • P-CSCF#2 650 may allow the initial session start attempt to continue. At this stage, whether the P-CSCF should interact with the PCRF/PCF is based on operator policy. P-CSCF#2 (650) can transmit the INVITE message to UE B (632).
  • SDP payload information including avatar-related parameters transmitted from UE A (630) to P-CSCF#1 (640) through the above process is contained in the SIP INVITE message and is sent to S-CSCF#1 (642) and I-CSCF#2 It is transmitted to the IMS entity (e.g., S-CSCF#2, P-CSCF#2) connected to the other terminal UE B (632) through nodes such as (654) and transmitted to the receiving terminal (UE B) (632). You can.
  • the IMS entity e.g., S-CSCF#2, P-CSCF#2
  • the receiving terminal (UE B) 632 uses a 3D avatar when accepting an interactive service connection according to user preference or predefined settings, similar to the operation of the transmitting terminal (UE A) 630 in step 601. You can choose to make a video call.
  • Receiving terminal (UE B) 632 may determine the complete set of codec or avatar related parameters supportable for this session.
  • UE B (632) determines the intersection with those appearing in the SDP (SDP offer) in the INVITE message, or selects avatar-related parameters that can be supported by the sending terminal and then provides avatar-related parameters and related information that can be supported by the receiving terminal. can be determined respectively and sent to the transmitting terminal.
  • 3D data information Desired 3D media (contents) type
  • FACS support indication etc movement support information
  • UE B sends an SDP (SDP response/answer) containing at least one of information listing common media flow and codec, avatar-related parameters, and avatar movement support information (FACS support indication). It can be transmitted to UE A (630).
  • SDP SDP response/answer
  • FACS support indication information listing common media flow and codec
  • FACS support indication FACS support indication
  • IMS entities e.g., P-CSCF, S-CSCF, I-CSCF, etc.
  • the UE B may transmit the SDP (SDP response/answer) to P-CSCF#2 (650).
  • P-CSCF#2 (650) can authorize QoS resources for selection of media flow and codec/avatar related parameters.
  • P-CSCF#2 (650) can transmit the SDP response/answer to S-CSCF#2 (652).
  • S-CSCF#2 (652) can transmit the SDP response/answer to S-CSCF#1 (642) through I-CSCF#2 (654).
  • S-CSCF#1 (642) can transmit the SDP response/answer to P-CSCF#1 (640).
  • P-CSCF#1 640 can authorize QoS resources for selection of media flow and codec/avatar related parameters. P-CSCF#1 (640) can transmit the SDP response/answer to UE A (630).
  • UE A 630 may determine which media flow should be used for this session, and which codec and avatar-related parameters should be used for each of the media flows.
  • UE A sends another offer to UE B (632) to determine one codec and avatar related parameter.
  • the codecs and avatar-related parameters can be negotiated with UE B (632), or the priority related to the requested codec and avatar-related parameters in UE B's response message can be viewed and determined.
  • the transmitting terminal (UE A) sees the motion support information (FACS support indication) in the initial request message and, if the receiving terminal (UE B) supports avatar-related motion expression, motion-related parameters through additional procedures (steps 605 and 606).
  • the receiving terminal (UE B) may send motion-related information in the response message 604, including information that transmission is possible.
  • the transmitting terminal (UE A) checks whether the receiving terminal supports supportable movement-related parameters in the response message 604 and receives only the corresponding information (not the entire 3D avatar data, but movement-related information) of the receiving terminal (UE B) when rendering the avatar.
  • an avatar call service can be provided to the user of the transmitting terminal.
  • both terminals support rendering of data related to the 3D avatar and support movement expression parameters based on 3D avatar-related parameters for a 3D avatar call
  • both terminals establish an initial connection for the 3D avatar call service.
  • a 3D avatar call can be made in real time using the user's movement information (FACS info. or facial feature point coefficient etc.).
  • FACS info. or facial feature point coefficient etc. the user's movement information
  • the 3D avatar call service is selected, but at least one terminal does not provide separate user movement information or does not provide movement expression information (FACS type) suitable for the other terminal in the process of 604
  • the corresponding 3D avatar In order to perform a call, the entire 3D avatar data can be captured, created, and transmitted in real time to a terminal that does not provide movement expression information.
  • 3D avatar data may be shared or exchanged in advance between UE A and UE B and stored, or may be downloaded and stored when using the service in the past. If the other terminal does not possess the other party's 3D avatar data, after the initial parameter negotiation is completed through steps 602 and 604, each terminal can exchange its own 3D avatar data with each other through step 610. Also, depending on the user's choice, if the other user wants to update the existing avatar data, connect the service first using 3D avatar data that has been downloaded in advance, or use the service using an animated avatar, etc. After exchanging the updated 3D avatar data in step 610, the 3D avatar can be replaced using the 3D avatar data to provide and use an interactive 3D avatar call service.
  • the receiving terminal (UE B) 632 can obtain (fetch) the SDP offer received through step 602.
  • the receiving terminal selects avatar content with appropriate parameters (e.g. number of points constituting a 3D object, Texture resolution, etc.) based on this value (allowed value). You can.
  • appropriate parameters e.g. number of points constituting a 3D object, Texture resolution, etc.
  • the rendering performance of the receiving terminal may be low-quality rendering (e.g. HD or FHD (full HD) resolution texture ) or if there are performance limitations of the terminal in real-time services, etc., the receiving terminal can request and receive 3D avatar content with low quality resolution from the transmitting terminal.
  • the 3D avatar content when selecting and requesting 3D avatar content in steps 602 and 604, can be classified and provided in a defined form according to type or profile according to the type of the 3D avatar content, as shown in Table 1. If the profile of specific 3D avatar data (e.g., when the content type is 3D asset Face) has a value of 0, as in the example in Table 1, the 3D avatar data has face-related data (3gpp_3DAsset_FACE), and the avatar-related It can be seen that the 3D object is composed of 3000 points and is composed of a texture with 2K resolution.
  • the specific 3D avatar data (e.g., when the content type is 3D asset Face) is more similar to 3D content depending on the detail expression method of the avatar-related 3D object, but can be expressed with 12,000 points for elaborate expression, which is shown in Table 1 corresponds to profile 1.
  • profiles 0 and 1 are 3D avatar data that allow for elaborate expression or movement assuming the same 3D avatar object (e.g., in the case of 3D asset Face), but have the same 2K texture resolution.
  • the same 3D avatar type can be configured with different profiles, as shown in Table 1, depending on the codec and 3D asset-related parameters in the SDP message, and the texture resolution and object detail expression method of the terminal depending on the bandwidth. You can select different profiles depending on your selection, such as (Number of the 3d object points). For example, even with the same avatar type, the resolution of the receiving terminal in the virtual space is determined by considering LoD (Level of Detail), etc. depending on the resolution of the rendering device, the 3D object to be rendered, and the virtual camera (the position of the other user in the virtual space).
  • LoD Level of Detail
  • 3D content with the same texture resolution and 3D object composed of the same number of points is provided, depending on the type of content as above, if it is service content using VR devices, movement at a high frame rate such as 90fps or 120fps is required. If you do this, you will be able to express user movements in more detail and render natural facial expressions.
  • the terminal can use a 3D Asset profile that can render natural facial expressions by expressing user movements in more detail (e.g., profile number 2 in Table 1, which expresses relatively low detail/facial expressions) or a relatively low-detail profile that can render natural facial expressions, etc. It may be possible to select an avatar content profile related to movement associated with avatar data by selecting profile number 3) that expresses high detailed expression/facial expression.
  • the terminal is defined as a point for expressing the same movement while having the same LoD for the same object, taking into account rendering performance, resolution of the terminal, and transmission bandwidth, but the value of the texture resolution expressing this can be selected differently. If the bandwidth of both terminals is sufficient for interactive service, but the terminal's performance supports high-definition 3D avatar data considering the rendering performance or resolution of the terminal, select profile 2 with 4K resolution and based on this, select profile 2 and create a 3D avatar. You can use interactive services by exchanging and storing data, but if the terminal's performance is poor or the user's choice, you can also use the service by requesting 3D avatar data with 2K texture resolution. In this way, depending on the performance of the terminal, etc., the selection of the 3D avatar-related profile of the transmitting terminal and the receiving terminal may be different even in a network environment such as the same bandwidth.
  • Table 1 illustrates the profile and movement expression parameters when the avatar's content type is 3D Asset Face and 3D Asset Full Body.
  • the 3D avatar-related movement (animation) expression information can be provided together with 3D avatar content characteristics and movements associated with them, as shown in Table 1, depending on the 3D avatar content creation method, or can be provided in a promised form separately from the 3D avatar content. .
  • 3D avatar-related movement expression information can be generated in various forms (FACS or H-ANIM (humanoid animation) etc.) and can be expressed using representative characteristics as shown in Table 2 below.
  • avatar movement information (hereinafter referred to as 'motion information') is data used by a terminal performing an avatar call service to render an avatar's movement, and may be, for example, FACS information.
  • the avatar-related movement expression information is information about an avatar expression method predefined to express the movement of the 3D avatar, and may be the FACS type of Table 2.
  • the terminal may generate 3D avatar movement information based on the avatar-related movement expression information and render the movement of the 3D avatar using the avatar movement information.
  • each IMS node may begin to reserve the transmission resources of the wired and/or wireless network required for this service, and the sending terminal Through an additional procedure, it is determined whether the receiving terminal supports avatar-related movement expression information in the previous process, and specific movement expression information (e.g. feature point information expressing animation of the 3D avatar data) is provided based on the corresponding 3D avatar data.
  • specific movement expression information e.g. feature point information expressing animation of the 3D avatar data
  • a method of expressing movement based on animation feature points of the avatar, etc. can be agreed upon.
  • the feature point-based motion expression method is not expressed in the response message of step 604, and the sending terminal only receives information about whether feature point-based motion expression for an avatar call is supported (i.e., FACS support indication) and communicates with the receiving terminal. It was assumed that specific movement expression parameters would be agreed upon through a separate agreement. In this case, avatar-related movement expression information and parameters provided by each terminal can be negotiated through separate additional requests (steps 605 and 606).
  • the transmitting terminal 630 may obtain information on whether motion expression is supported (FACS support indication) within the SDP answer message received in step 604. If the receiving terminal (UE B) 632 supports 3D avatar-related motion expression information, the transmitting terminal 630 sends 3D avatar data (step 605) within a SIP UPDATE request including an SDP offer message. Specific 3D avatar-related movement (animation) expression information (e.g. FACS type in Table 2) associated with (negotiated through 602 and 604) can be transmitted to the receiving terminal 632.
  • FACS support indication information on whether motion expression is supported
  • the transmitting terminal 630 sends 3D avatar data (step 605) within a SIP UPDATE request including an SDP offer message.
  • Specific 3D avatar-related movement (animation) expression information e.g. FACS type in Table 2 associated with (negotiated through 602 and 604) can be transmitted to the receiving terminal 632.
  • the 3D avatar-related motion expression information in step 605 is provided by the transmitting terminal (UE A) in step 602 by providing avatar motion expression information and parameters (e.g. FACS type or Number of Feature point) related to 3D avatar data (e.g. 3gpp_3DAsset_Face) supported by the transmitting terminal. & FACS Expression type etc.) and, additionally, it may include movement expression information related to the 3D avatar of the receiving terminal that the transmitting terminal requests from the receiving terminal based on the 3D avatar data information supported by the receiving terminal.
  • 3D avatar-related movement expression information is information on how to finely move the 3D avatar data depending on the parameters of the 3D avatar data (Number of feature points), or information on how to express the movement of the points (Expression type) It can be defined as, etc.
  • the 3D avatar-related movement expression information includes information on how to finely move the 3D avatar data depending on the type of 3D avatar data (Number of feature points) and information on how to express the movement of those points (Expression type). Based on the information, it can be defined in the form of a dictionary-defined profile.
  • face-related movement expression information is expressed using FACS (Facial action coding system), which defines points within the face to express facial expressions based on muscle movement information related to the human face, etc., or is expressed in an application or It can be expressed in a separate promised form for each service provider.
  • FACS Joint action coding system
  • the expression of 3D avatar data may vary depending on the transmission bandwidth of steps 602 and 604.
  • the type of motion expression information may also vary depending on the type of 3D avatar according to the transmission bandwidth.
  • 3D avatar-related parameter negotiation process in the case of a 3D avatar with a high-resolution texture, 3D avatar data consisting of many feature points is provided, and in order to express the movement of the avatar, movement is based on many feature points. Only by expressing it can you convey natural facial expression information.
  • the expression method (Expression type: e.g. emotion type, feature point coefficient type etc.) is the same based on the 3D avatar, but in order to express the avatar's expression in more detail, the number of feature points to express facial movement is changed. There could be more.
  • Table 2 illustrates the case where 3D avatar-related motion expression information (FACS type) having the same motion expression type (Expression type) 'Intensity' is 2 and 3.
  • FACS type 3D avatar-related motion expression information
  • Example type Motion expression type
  • Table 2 in order to use interactive services based on low-resolution 3D object content consisting of 3000 points, considering user preferences, terminal rendering performance, bandwidth information obtained during the SDP negotiation process, and the type of 3D content that the other terminal can provide, etc. If the value of the 3D avatar-related motion expression information (FACS type) is set to 2, the facial motion expression of the low-resolution 3D avatar content can be expressed using 51 facial feature point information and the amount of change in the feature point.
  • avatar facial movement expression information is required to express the high-definition 3D avatar content.
  • the value of may need to be changed to 3 and expressed using 86 feature points and change amount information of the feature points.
  • information for expressing the movement of the 3D avatar is provided in steps 605 and 606. Additional negotiations may be conducted based on this information.
  • Table 2 illustrates FACS type as an example of avatar-related movement expression information.
  • the receiving terminal can determine whether the receiving terminal supports the 3D avatar motion expression information transmitted by the transmitting terminal in step 606, and the receiving terminal
  • the requested 3D avatar-related movement expression information e.g., FACS type
  • Movement expression information related to the 3D avatar supported by the receiving terminal to be transmitted from the receiving terminal to the transmitting terminal may be transmitted to the transmitting terminal through a response message (eg, 200 OK message).
  • the transmitting terminal/receiving terminal completes negotiation of 3D avatar data and related motion expression information and then completes session establishment.
  • step 610 if the transmitting terminal and the receiving terminal do not have the other terminal's 3D avatar data, they request 3D avatar data from the other terminal based on the priorities of the 3D avatar-related data and related parameters in steps 602 and 604, respectively. It can be exchanged. If a 3D avatar call service user already possesses the other person's avatar data, the 3D avatar call service can be provided using the avatar data after negotiating 3D avatar call-related information. However, if the 3D avatar call service user does not have the other party's avatar data, the user and business operator may perform a procedure to receive (or download) the corresponding 3D avatar data first, depending on the selection of the user and business operator.
  • 3D avatar call When the service user does not have the other person's 3D avatar and is downloading the corresponding 3D avatar, an avatar call connection is created based on an avatar without character or cartoon animation, depending on the user's selection, and the other person's 3D avatar is downloaded. Once you complete receiving (downloading) the avatar data, you can switch from an animation-based 3D avatar call to an actual image-based 3D avatar call.
  • the transmitting terminal 630 and the receiving terminal 632 may each generate motion information based on the 3D avatar-related motion expression information negotiated in steps 605 and 606.
  • the 3D avatar-related movement expression information can be generated by extracting facial feature points in the form of depth based on a ToF (time of flight) camera or a structure-type infrared camera depending on the capability of the terminal. In this case, points 605 and 606 above are used.
  • the transmitting terminal 630 and the receiving terminal 632 Based on the expression type in Table 2 received from , express information on feature points for expressing expression information, etc. among all points representing the face and the amount of change in movement of the corresponding feature point. It is created including information such as method (expression type).
  • the promised facial expression e.g., happy, fear, sad, etc.
  • simple facial expression information e.g., 7 facial expressions
  • 51 facial feature points are extracted based on the user's captured facial information and the value of the change in movement of the corresponding point (e.g. type 1 - Floating value or type 2 - intensity (Integer Value) )) It can be expressed as .
  • 3D avatar data and feature point information to express facial movements can be specified and provided by the settings of the terminal and service provider in the form promised when generating 3D avatar data for each FACS type.
  • feature point information e.g., mapped position between live action and avatar
  • 3D avatar Data and 3D avatar-related movement expression information are provided in a related form. Therefore, the feature point information in the 3D avatar information and the 3D avatar-related movement expression information may have different generation methods (e.g. method of extracting feature points from the image) depending on the terminal, but have a certain type of common features.
  • the transmitting terminal 630 and the receiving terminal 632 may transmit avatar movement information in step 612. Based on the avatar movement information, the transmitting terminal 630 and the receiving terminal 632 can perform a real-time 3D avatar call.
  • the transmitting terminal 630 and the receiving terminal 632 can terminate the RTP session for exchanging the corresponding 3D avatar data.
  • FIG. 7 shows a transmission method for performing an avatar-type video call using an IP multimedia subsystem (IMS) according to an embodiment of the present disclosure, where a transmitting terminal (UE A) and a receiving terminal (UE B) set parameters. Illustrates a procedure for negotiating and ensuring QoS of a wired or wireless transmission path.
  • avatar data and avatar-related movement information may be transmitted through separate paths.
  • information related to media content using a codec is transmitted using the RTP protocol, and although no additional codec is used, data to support interactive services can be transmitted through a WebRTC-based data channel.
  • the transmitting terminal (UE A) 630 may select a video call using a 3D avatar when connecting a video call.
  • the transmitting terminal 630 determines at least one of codec(s) and 3D avatar-related parameter(s) based on the RTP protocol and inserts the 3D avatar data into the payload of the SDP message, and Motion information can be used to request a connection by determining the parameter(s) using a WebRTC-based data channel, inserting it into the payload of the SDP message, and transmitting it to the receiving terminal 632.
  • the codec(s) or 3D avatar-related parameter(s) inserted in the payload of the SDP message may reflect the terminal performance of the sending terminal and user preference for supportable sessions (user selection, etc. as in step 701). there is.
  • the transmitting terminal 630 may create an SDP message (eg, SDP offer) including bandwidth requirements and each characteristic, and allocate a local port number for each possible media flow.
  • the receiving terminal (UE B) 632 makes a video call using a 3D avatar when accepting an interactive service connection according to user preference or predefined settings, such as the operation of the transmitting terminal (UE A) 630 in step 701. You can select .
  • UE B 632 may determine the complete set of codec or 3D avatar related parameters supportable for this session.
  • UE B 632 may determine the intersection with those appearing within the SDP (SDP offer) in the INVITE message.
  • UE B sends an SDP (SDP response/answer) listing common media flow and codec, 3D avatar related parameters, and 3D avatar movement support information (FACS support indication) to UE A (630). It can be passed on.
  • SDP SDP response/answer
  • FACS support indication 3D avatar movement support information
  • UE A (630) makes another offer to UE B (632) to determine one of the codec, 3D avatar related parameters. You can negotiate the codecs and 3D avatar-related parameters with UE B (632) or determine the priority related to the requested codec and 3D avatar-related parameters in UE B's response message.
  • the transmitting terminal looks at the motion support information (FACS support indication) in the initial request message and, if the receiving terminal (UE B) supports motion expression related to the 3D avatar, expresses motion through additional procedures (steps 705 and 706). Parameter negotiation can be performed.
  • the transmitting terminal 630 may obtain information about whether motion expression is supported (FACS support indication) within the SDP answer message received in step 704. If the receiving terminal (UE B) 632 supports 3D avatar-related movement expression information (e.g. FACS type), the transmitting terminal 630 sends 3D avatar data in a SIP UPDATE request including an SDP offer message in step 705. Specific 3D avatar-related movement (animation) expression information (e.g., FACS type for Bootstrap data channel) (see 920 in FIG. 9 and 1050 in FIG. 10) associated with (negotiated through steps 702 and 704) is transmitted to the receiving terminal. You can.
  • 3D avatar-related movement expression information e.g., FACS type for Bootstrap data channel
  • the receiving terminal may determine whether the receiving terminal supports the 3D avatar motion expression information transmitted by the transmitting terminal in step 706, and the corresponding reception Movement expression information (e.g., FACS type for Bootstrap data channel) related to 3D avatars that can be supported and provided by the terminal can be prioritized and transmitted in the form of a list. Movement expression information related to the 3D avatar to be transmitted from the receiving terminal to the transmitting terminal may be transmitted to the transmitting terminal through a response message (eg, 200 OK message).
  • a response message eg, 200 OK message
  • the transmitting terminal/receiving terminal completes negotiation of 3D avatar-related data information and related motion expression information and then completes session establishment.
  • the transmitting terminal and the receiving terminal negotiate parameters for exchanging 3D avatar data supported by each terminal and parameters for exchanging 3D avatar-related movement information (e.g., FACS type for Bootstrap data channel), and negotiation is completed.
  • 3D avatar-related movement information e.g., FACS type for Bootstrap data channel
  • a session can be established for 3D avatar-related data based on RTP, and for 3D avatar-related movement information, a session can be established using a WebRTC-based Data channel (DC).
  • DC WebRTC-based Data channel
  • step 710 if one or both terminals (the sending terminal and the receiving terminal) do not already possess 3D avatar data, an animation-based 3D avatar call may first be established and serviced according to the user's selection. Through step 710, the process of exchanging 3D avatar-related data provided by each terminal can be completed.
  • the transmitting terminal 630 and the receiving terminal 632 each generate 3D avatar-related movement information in step 711. can do.
  • the 3D avatar-related movement information generated in step 711 can be exchanged through a WebRTC-based data channel.
  • Each terminal provides a real-time 3D avatar call service by reflecting the feature point change information to express the movement of the 3D avatar based on the 3D avatar data received in step 710 and the 3D avatar-related movement information exchanged through the data channel in step 712. It can be done.
  • the RTP session for exchanging the corresponding 3D avatar data may be terminated through steps 713 and 714.
  • Figure 8 shows a transmission method for performing an avatar-type video call using an IP multimedia subsystem (IMS) according to an embodiment of the present disclosure, where a transmitting terminal (UE A) and a receiving terminal (UE B) negotiate parameters. (negotiate) and illustrates a procedure for ensuring QoS of a wired or wireless transmission path.
  • the transmitting terminal or the receiving terminal can select a pre-connection method (video or voice call) before connecting the avatar call (when connection is delayed due to the 3D avatar data download process, etc.).
  • the transmitting terminal (UE A) 630 may select a video call using a 3D avatar when connecting a video call according to the user's selection or predefined settings.
  • the transmitting terminal 630 determines at least one of codec(s) and 3D avatar related parameter(s) and inserts it into the payload of the SDP message, and determines the 3D avatar call connection due to 3D avatar data download, etc. Determination and insertion of at least one of codecs and parameters related to the existing video or audio-based call connection method to be used during delay may also be performed.
  • the inserted codec(s) or 3D avatar-related parameter(s) may reflect terminal performance of the transmitting terminal and user preference for sessions capable of supporting this session (such as the user's selection in step 801).
  • the transmitting terminal 630 may allocate a local port number for each possible media flow, create an SDP message (SDP offer) including bandwidth requirements and each characteristic, and transmit it to the receiving terminal (UE B) 632.
  • the receiving terminal (UE B) 632 makes a video call using a 3D avatar when accepting an interactive service connection according to user preference or predefined settings, such as the operation of the transmitting terminal (UE A) 630 in step 801. You can select .
  • UE B 632 may determine the complete set of codec or 3D avatar related parameters supportable for this session.
  • the receiving terminal 632 uses a codec related to an existing video or audio-based call connection method to be used when a 3D avatar call connection using a 3D avatar is delayed depending on the selection of the service provider or the receiving terminal. and determination and selection of parameters.
  • UE B 632 may determine the intersection with those appearing within the SDP (SDP offer) in the INVITE message.
  • UE B sends an SDP (SDP response/answer) containing at least one of information listing common media flow and codec, 3D avatar related parameters, and 3D avatar movement support information (FACS support indication). ) can be transmitted to UE A (630).
  • SDP SDP response/answer
  • FACS support indication 3D avatar movement support information
  • UE A sends another offer to UE B 632 to determine one codec and 3D avatar related parameter. You can negotiate the codecs and 3D avatar-related parameters with UE B (632), or you can decide by looking at the priority of the requested codec and 3D avatar-related parameters in UE B's response message.
  • the transmitting terminal looks at the motion support information (FACS support indication) in the initial request message and, if the receiving terminal (UE B) supports motion expression related to the 3D avatar, expresses motion through additional procedures (steps 805 and 806). Parameter negotiation can be performed.
  • the transmitting terminal 630 may obtain information on whether motion expression-related information is supported (FACS support indication) in the SDP answer message received in step 804. If the receiving terminal (UE B) 632 supports 3D avatar-related movement expression information (e.g. FACS type), the transmitting terminal 630 sends 3D avatar data in a SIP UPDATE request including an SDP offer message in step 805. Specific 3D avatar-related movement (animation) expression method information (eg, FACS type for Bootstrap data channel) associated with (negotiated through steps 802 and 804) may be transmitted to the receiving terminal.
  • 3D avatar-related movement (animation) expression method information eg, FACS type for Bootstrap data channel
  • the receiving terminal determines whether the receiving terminal supports the 3D avatar motion expression information transmitted by the transmitting terminal in step 806 and supports the corresponding receiving terminal. And the available 3D avatar-related movement expression information (e.g., FACS type for Bootstrap data channel) can be prioritized and transmitted in the form of a list. Movement expression information related to the 3D avatar to be transmitted from the receiving terminal to the transmitting terminal may be transmitted to the transmitting terminal through a response message.
  • the available 3D avatar-related movement expression information e.g., FACS type for Bootstrap data channel
  • the transmitting terminal/receiving terminal completes negotiation of 3D avatar-related data information and related motion expression information and then completes session establishment.
  • the transmitting terminal and the receiving terminal negotiate parameters for exchanging 3D avatar data supported by each terminal and parameters for exchanging movement information related to the 3D avatar (e.g., FACS type for Bootstrap data channel), and the 3D avatar If the call connection is delayed, the voice or video call-related parameters to be used during the initial connection can also be negotiated to complete the establishment of each session.
  • 3D avatar data e.g., FACS type for Bootstrap data channel
  • step 810 if one or both terminals (the sending terminal and the receiving terminal) do not already have 3D avatar data, a video call connection can be established first according to the user's selection.
  • step 811 the process of exchanging 3D avatar-related data provided by each terminal can be completed.
  • the transmitting terminal 630 and the receiving terminal 632 each make 3D avatar-related movements. Information can be generated.
  • the transmitting terminal 630 and the receiving terminal 632 can exchange movement information related to the 3D avatar generated in step 812 through step 813.
  • Each terminal can perform a real-time 3D avatar call service by reflecting the change amount information based on the 3D avatar data received in step 811 and the 3D avatar-related movement information exchanged in step 812.
  • steps 814 and 815 the video call-related session and the RTP session for exchanging the 3D avatar data may be terminated.
  • Figure 9 shows an example of an SDP offer according to an embodiment of the present disclosure.
  • the SDP offer may be an SDP offer (SDP offer message) transmitted by the transmitting terminal in the case of single stream media session configuration.
  • an operation for identifying 3D avatar data is performed based on the SDP attribute 3gpp_3DAsset_Face (910) and the parameters (3D avatar-related SDP attribute parameters) included in the SDP attribute 3gpp_3DAsset_Face (910).
  • the SDP attribute 3gpp_3DAsset_Face may be expressed as 3DAsset_Face .
  • the SDP attribute 3gpp_3DAsset_Face can be used to indicate/identify face data among 3D avatar objects.
  • Immersive Teleconferencing and Telepresence for Remote Terminals may support the 3gpp_3DAsset_Face attribute and may support the following procedures:
  • the ITT4RT-Tx (transmitting) client can include the 3gpp_3DAsset_Face attribute in the media description for the video in the SDP offer.
  • the ITT4RT-Rx (receiving) client can include the 3gpp_3DAsset_Face attribute in the media description for the video within the SDP answer if the 3gpp_3DAsset_Face attribute is received within the SDP offer.
  • the Multimedia Telephony Service for IMS (MTSI) client sends a 3D Avatar Asset Data configuration information SD (Scene description) message with an RTP-based texture image/texture image containing HEVC or AVC.
  • RTP-based geometry information including video streams and binary data, can be exchanged.
  • ITT4RT-Tx transmitting clients that support both 3D avatar data (full body (FB) or half body (HB) of the avatar) and 3D avatar face data (avatar face only) include 3gpp_3DAsset, 3gpp_3DAsset_Face, and All 3gpp_3DAsset_FB, 3gpp_3DAsset_HB attributes may be included, but the ITT4RT-Rx (receiving) client may include only one of the attributes ( 3gpp_3DAsset, 3gpp_3DAsset_Face, 3gpp_3DAsset_FB, 3gpp_3DAsset_HB attributes, based on support or selection) in the SDP answer.
  • the media type for transmitting data of the avatar's face can be expressed as 3gpp_3DAsset_Face or 3DAsset_Face .
  • the media type for transmitting data of the avatar's half body can be expressed as 3gpp_3DAsset_FB or 3DAsset_FB .
  • the type can be expressed as 3gpp_3DAsset_HB or 3DAsset_HB .
  • ITT4RT is an MTSI client that supports ITT4RT features.
  • the ITT4RT-Tx client may refer to an ITT4RT client that is only capable of sending 3D avatar (face) data.
  • the ITT4RT-Rx client may refer to an ITT4RT client that is only capable of receiving 3D avatar (face) data.
  • An MTSI client may be a function within a terminal or network entity (e.g., Media Resource Function Processor (MRFP)) that supports MTSI.
  • MRFP Media Resource Function Processor
  • Media-line level parameters are intended to describe 3D avatar face data, such as that identified by the 3gpp_3DAsset_Face attribute, as well as to establish a session between ITT4RT-Tx (sending) and ITT4RT-Rx (receiving) clients for 3D avatar face data. It may also be defined to support .
  • packing of 3D avatar face data in the stream may be negotiated between the sending terminal and the receiving terminal.
  • This parameter in the SDP offer indicates the number of points constituting the 3D object related to avatar face data.
  • This parameter in the SDP offer indicates the resolution of the texture that makes up the 3D object related to avatar face data.
  • This parameter in the SDP offer indicates the number of feature points in the avatar face to express the movement of the avatar face data.
  • Figure 10 is an example of an SDP offer according to an embodiment of the present disclosure.
  • the SDP offer may be an SDP offer (SDP offer message) including 3D avatar face data.
  • 3D avatar face data supports a payload type divided into two types of texture and geometry (e.g., 3gpp_3DAsset_Face_Texture, 3DAsset_Face_Geometry).
  • a method of generating an SDP answer when the receiving terminal receives the Offer illustrated in FIG. 8 may be illustrated as follows.
  • the receiving terminal may signal that it will not receive 3D avatar data as in normal SDP media negotiation (e.g., set the port number to 0 set to ).
  • the receiving terminal uses the 3D avatar provided in the SDP Offer
  • the 3D avatar face data payload type (e.g., texture, geometry) may be selected based on face data-related parameters, and information related to the selection may be included in the SDP answer.
  • the parameters related to 3D avatar face data include at least 3D object data compression method (e.g. PCC or Mesh etc.), number of points representing the 3D data, texture encoding method, and texture resolution. It can contain one.
  • the receiving terminal can select one or two 3D avatar face data payload types within the SDP answer.
  • the receiving terminal sends a media line (or SDP attribute 3gpp_3DAsset_Face) within the SDP answer, taking into account the processing capabilities of the receiving terminal and/or 3D avatar face-related parameters (of the sending terminal).
  • a media line or SDP attribute 3gpp_3DAsset_Face
  • Figure 11 is a diagram illustrating a method of performing a media call by a calling terminal according to the present disclosure.
  • the sending terminal may transmit a first SDP offer message including information indicating the content type of at least one avatar and information on whether the sending terminal supports movement of the at least one avatar to the called terminal (1100, 602) , 702, 802).
  • the first SDP offer message may further include a profile of the content type of the at least one avatar, and the number of points, the number of feature points, or the texture resolution of the at least one avatar are identified by the content type and the profile ( can be identified.
  • the first SDP offer message may further include video media information or audio media information.
  • the video media information or the audio media information may be used to establish a call connection until the calling terminal receives data of the at least one avatar media (eg, 3D avatar).
  • the calling terminal may receive an SDP response message containing information on whether the called terminal supports the movement of the at least one avatar from the called terminal. (1102, 604, 704, 804).
  • the calling terminal may transmit a second SDP offer message including movement expression information of the at least one avatar to the called terminal based on information on whether the called terminal supports it (605, 705, 805).
  • the calling terminal may receive a response message containing movement expression information of the at least one avatar from the called terminal (606, 706, 806).
  • the movement expression information of the at least one avatar may include at least one of a FACS type, the number of feature points, or an expression type of the feature points.
  • the movement expression information of the at least one avatar may indicate a separate data channel through which the movement information will be transmitted.
  • the sending terminal may generate movement information of the at least one avatar based on the support information of the called terminal included in the SDP response message (1104, 611, 711, 812).
  • the calling terminal can perform an avatar call service with the called terminal using the generated motion information (1106). Specifically, the calling terminal transmits the generated motion information to the called terminal, receives avatar motion information of the called terminal from the called terminal, and uses the avatar motion information of the called terminal to control the called terminal. By rendering an avatar and using the rendered avatar of the called terminal, the avatar call service can be performed with the called terminal.
  • Figure 12 is a diagram illustrating a method of performing a media call by a receiving terminal according to the present disclosure.
  • the receiving terminal may receive a first SDP offer message from the calling terminal, including information indicating the content type of at least one avatar and information on whether the calling terminal supports the movement of the at least one avatar (1200, 602, 702, 802).
  • the first SDP offer message may further include a profile of the content type of the at least one avatar, and the number of points, the number of feature points, or the texture resolution of the at least one avatar may be identified by the content type and the profile. You can.
  • the first SDP offer message may further include video media information or audio media information. The video media information or the audio media information may be used to establish a call connection until the called terminal receives data of the at least one avatar media (eg, 3D avatar).
  • the receiving terminal may transmit an SDP response message containing information on whether the receiving terminal supports the movement of the at least one avatar to the calling terminal (1202, 604) , 704, 804).
  • the receiving terminal receives a second SDP offer message including movement expression information of the at least one avatar from the sending terminal (605, 705, 805), and in response to the second SDP offer message, the A response message containing movement expression information of at least one avatar may be transmitted to the sending terminal (606, 706, 806).
  • the movement expression information of the at least one avatar may include at least one of a FACS type, the number of feature points, or an expression type of the feature points.
  • the movement expression information of the at least one avatar may indicate a data channel through which the movement information will be transmitted.
  • the receiving terminal may generate movement information of the at least one avatar based on the support information of the receiving terminal included in the SDP response message (1204, 611, 711, 812).
  • the called terminal can perform an avatar call service with the calling terminal using the generated motion information (1206). Specifically, the called terminal transmits the generated motion information to the calling terminal, receives avatar motion information of the calling terminal from the calling terminal, and uses the avatar motion information of the calling terminal to create an avatar for the calling terminal. By rendering and using the rendered avatar of the calling terminal, the avatar call service can be performed with the calling terminal.
  • FIG. 13 is a diagram illustrating the configuration of a terminal (UE) device according to the present disclosure.
  • the UE 1300 may include a transceiver 1305 that transmits and receives signals from other UEs or network entities, and a control unit 1310 that controls all operations of the UE 1300. All methods performed by the calling terminal 630 and the called terminal 632 described above in this disclosure can be understood as being performed under the control of the control unit 1310.
  • control unit 1310 and the transceiver unit 1305 do not necessarily have to be implemented as separate devices, and of course, they can be implemented as a single component in the form of a single chip.
  • the control unit 1310 may be implemented within the UE 1300 as a single processor.
  • Figure 14 is a diagram illustrating the device configuration of an IMS entity according to the present disclosure.
  • IMS entity 1400 in FIG. 14 illustrates the device configuration of several network entities P-CSCF, S-CSCF, I-CSCF, etc. described in this disclosure.
  • the IMS entity 1400 may include a transceiver 1405 that transmits and receives signals with other IMS entities or UEs, and a control unit 1410 that controls all operations of the IMS entity 1400. In the present disclosure, all methods performed by the IMS entity may be understood as being performed under the control of the control unit 1410.
  • control unit 1410 and the transceiver unit 14005 do not necessarily have to be implemented as separate devices, and of course, they can be implemented as a single component in the form of a single chip.
  • the control unit 1410 may be implemented within the IMS entity 1400 with a single processor.
  • FIGS. 1 to 14 are not intended to limit the scope of the present disclosure. That is, all configurations or operations described in FIGS. 1 to 14 should not be construed as essential components for implementing the present disclosure, and may be implemented within the scope that does not impair the essence of the present disclosure even if only some components are included. You can.
  • a computer-readable storage medium that stores one or more programs (software modules) may be provided.
  • One or more programs stored in a computer-readable storage medium are configured to be executable by one or more processors in an electronic device (configured for execution).
  • One or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.
  • These programs include random access memory, non-volatile memory including flash memory, read only memory (ROM), and electrically erasable programmable ROM.
  • EEPROM Electrically Erasable Programmable Read Only Memory
  • magnetic disc storage device Compact Disc-ROM (CD-ROM: Compact Disc-ROM), Digital Versatile Discs (DVDs), or other types of It can be stored in an optical storage device or magnetic cassette. Alternatively, it may be stored in a memory consisting of a combination of some or all of these. Additionally, a plurality of each configuration memory may be included.
  • the program can be accessed through a communication network such as the Internet, Intranet, LAN (Local Area Network), WLAN (Wide LAN), or SAN (Storage Area Network), or a combination of these. It may be stored in an attachable storage device that can be accessed. This storage device can be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communications network may be connected to the device performing embodiments of the present disclosure.
  • a communication network such as the Internet, Intranet, LAN (Local Area Network), WLAN (Wide LAN), or SAN (Storage Area Network), or a combination of these. It may be stored in an attachable storage device that can be accessed. This storage device can be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communications network may be connected to the device performing embodiments of the present disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computer Graphics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 보다 높은 데이터 전송률을 지원하기 위한 5G 또는 6G 통신 시스템에 관련된 것이다. 본 개시는 발신 단말의 방법에 있어서, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP offer 메시지를 착신 단말에게 전송하는 동작; 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP response 메시지를 상기 착신 단말로부터 수신하는 동작; 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하는 동작; 및 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하는 동작을 포함하는 방법을 제공한다.

Description

미디어 콜 서비스를 수행하기 위한 방법 및 장치
본 개시는 오디오 또는 비디오 미디어 콜 서비스에 관한 것으로, 보다 상세하게는, 아바타 콜 서비스를 처리하기 위한 방법 및 장치에 관한 것이다.
5G 이동통신 기술은 빠른 전송 속도와 새로운 서비스가 가능하도록 넓은 주파수 대역을 정의하고 있으며, 3.5 기가헤르츠(3.5GHz) 등 6GHz 이하 주파수('Sub 6GHz') 대역은 물론 28GHz와 39GHz 등 밀리미터파(㎜Wave)로 불리는 초고주파 대역('Above 6GHz')에서도 구현이 가능하다. 또한, 5G 통신 이후(Beyond 5G)의 시스템이라 불리어지는 6G 이동통신 기술의 경우, 5G 이동통신 기술 대비 50배 빨라진 전송 속도와 10분의 1로 줄어든 초저(Ultra Low) 지연시간을 달성하기 위해 테라헤르츠(Terahertz) 대역(예를 들어, 95GHz에서 3 테라헤르츠(3THz) 대역과 같은)에서의 구현이 고려되고 있다.
5G 이동통신 기술의 초기에는, 초광대역 서비스(enhanced Mobile BroadBand, eMBB), 고신뢰/초저지연 통신(Ultra-Reliable Low-Latency Communications, URLLC), 대규모 기계식 통신 (massive Machine-Type Communications, mMTC)에 대한 서비스 지원과 성능 요구사항 만족을 목표로, 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위한 빔포밍(Beamforming) 및 거대 배열 다중 입출력(Massive MIMO), 초고주파수 자원의 효율적 활용을 위한 다양한 뉴머롤로지 지원(복수 개의 서브캐리어 간격 운용 등)와 슬롯 포맷에 대한 동적 운영, 다중 빔 전송 및 광대역을 지원하기 위한 초기 접속 기술, BWP(Band-Width Part)의 정의 및 운영, 대용량 데이터 전송을 위한 LDPC(Low Density Parity Check) 부호와 제어 정보의 신뢰성 높은 전송을 위한 폴라 코드(Polar Code)와 같은 새로운 채널 코딩 방법, L2 선-처리(L2 pre-processing), 특정 서비스에 특화된 전용 네트워크를 제공하는 네트워크 슬라이싱(Network Slicing) 등에 대한 표준화가 진행되었다.
현재, 5G 이동통신 기술이 지원하고자 했던 서비스들을 고려하여 초기의 5G 이동통신 기술 개선(improvement) 및 성능 향상(enhancement)을 위한 논의가 진행 중에 있으며, 차량이 전송하는 자신의 위치 및 상태 정보에 기반하여 자율주행 차량의 주행 판단을 돕고 사용자의 편의를 증대하기 위한 V2X(Vehicle-to-Everything), 비면허 대역에서 각종 규제 상 요구사항들에 부합하는 시스템 동작을 목적으로 하는 NR-U(New Radio Unlicensed), NR 단말 저전력 소모 기술(UE Power Saving), 지상 망과의 통신이 불가능한 지역에서 커버리지 확보를 위한 단말-위성 직접 통신인 비 지상 네트워크(Non-Terrestrial Network, NTN), 위치 측위(Positioning) 등의 기술에 대한 물리계층 표준화가 진행 중이다.
뿐만 아니라, 타 산업과의 연계 및 융합을 통한 새로운 서비스 지원을 위한 지능형 공장 (Industrial Internet of Things, IIoT), 무선 백홀 링크와 액세스 링크를 통합 지원하여 네트워크 서비스 지역 확장을 위한 노드를 제공하는 IAB(Integrated Access and Backhaul), 조건부 핸드오버(Conditional Handover) 및 DAPS(Dual Active Protocol Stack) 핸드오버를 포함하는 이동성 향상 기술(Mobility Enhancement), 랜덤액세스 절차를 간소화하는 2 단계 랜덤액세스(2-step RACH for NR) 등의 기술에 대한 무선 인터페이스 아키텍쳐/프로토콜 분야의 표준화 역시 진행 중에 있으며, 네트워크 기능 가상화(Network Functions Virtualization, NFV) 및 소프트웨어 정의 네트워킹(Software-Defined Networking, SDN) 기술의 접목을 위한 5G　베이스라인 아키텍쳐(예를 들어, Service based Architecture, Service based Interface), 단말의 위치에 기반하여 서비스를 제공받는 모바일 엣지 컴퓨팅(Mobile Edge Computing, MEC) 등에 대한 시스템 아키텍쳐/서비스 분야의 표준화도 진행 중이다.
이와 같은 5G 이동통신 시스템이 상용화되면, 폭발적인 증가 추세에 있는 커넥티드 기기들이 통신 네트워크에 연결될 것이며, 이에 따라 5G 이동통신 시스템의 기능 및 성능 강화와 커넥티드 기기들의 통합 운용이 필요할 것으로 예상된다. 이를 위해, 증강현실(Augmented Reality, AR), 가상현실(Virtual Reality, VR), 혼합 현실(Mixed Reality, MR) 등을 효율적으로 지원하기 위한 확장 현실(eXtended Reality, XR), 인공지능(Artificial Intelligence, AI) 및 머신러닝(Machine Learning, ML)을 활용한 5G 성능 개선 및 복잡도 감소, AI 서비스 지원, 메타버스 서비스 지원, 드론 통신 등에 대한 새로운 연구가 진행될 예정이다.
또한, 이러한 5G 이동통신 시스템의 발전은 6G 이동통신 기술의 테라헤르츠 대역에서의 커버리지 보장을 위한 신규 파형(Waveform), 전차원 다중입출력(Full Dimensional MIMO, FD-MIMO), 어레이 안테나(Array Antenna), 대규모 안테나(Large Scale Antenna)와 같은 다중 안테나 전송 기술, 테라헤르츠 대역 신호의 커버리지를 개선하기 위해 메타물질(Metamaterial) 기반 렌즈 및 안테나, OAM(Orbital Angular Momentum)을 이용한 고차원 공간 다중화 기술, RIS(Reconfigurable Intelligent Surface) 기술 뿐만 아니라, 6G 이동통신 기술의 주파수 효율 향상 및 시스템 네트워크 개선을 위한 전이중화(Full Duplex) 기술, 위성(Satellite), AI(Artificial Intelligence)를 설계 단계에서부터 활용하고 종단간(End-to-End) AI 지원 기능을 내재화하여 시스템 최적화를 실현하는 AI 기반 통신 기술, 단말 연산 능력의 한계를 넘어서는 복잡도의 서비스를 초고성능 통신과 컴퓨팅 자원을 활용하여 실현하는 차세대 분산 컴퓨팅 기술 등의 개발에 기반이 될 수 있을 것이다.고해상도 비디오 멀티미디어(standard definition (SD), high definition (HD), ultra high definition (UHD))의 추구(pursuit)에 이어, 멀티미디어의 다음 몰입형 경험은 360도 비디오 및 3D 입체(volumetric) 컨텐트 이다.
3D Volumetric 컨텐트를 활용함으로서 사용자는 멀티 카메라로 촬영한 영상을 3D 오브젝트 형태로 3D 데이터 (3D Asset) 파일을 제작함으로써, 사용자는 AR 및 메타버스 환경에서 실제 환경과 가상의 3D 오브젝트를 결합하여 사용자가 원하는 위치에 해당 오브젝트를 위치시키며 원하는 임의의 방향으로 입체감 있게 영상을 볼 수 있다.
3D Volumetric 컨텐트 역시 압축을 위해 여전히 종래의 2D 비디오 코덱이나 바이너리 압축 방식을 사용하고 있지만, 3D volumetric 컨텐트의 지원은 종단 간(end-to-end) 워크 플로우에서 새로운 기술을 요구한다. 이러한 기술에는, 하나의 씬(Scene)을 구성하며 구성 요소들을 정의하기 위한 씬 디스크립션 (Scene description) 기술; 3D 오브젝트를 구성하는 3D 오브젝트 지오메트리(geometry) 정보 및 텍스쳐(texture) 정보 및 이러한 3D 오브젝트 구성요소들의 연결 및 압축을 지원하는 새로운 포맷; 3D 오브젝트의 움직임(애니메이션 등)을 표현하며 이를 지원하기 위한 3D 오브젝트 데이터와의 연결 및 표현 정보 등을 포함하는 새로운 포맷; 포맷의 리던던시를 줄이기 위한 미디어 처리 기술; 새로운 딜리버리 프로토콜 및 컨텐트 딜리버리의 효율성을 증가시키기 위한 메커니즘이 포함될 수 있다.
비록 3D Volumetric 컨텐트에 대한 최근 메타버스 및 AR등과 관련하여 많은 작업(work)과 연구(research)가 있지만, 3D Volumetric 컨텐트(e.g. 3D 아바타)에 대한 대화형(conversational) 서비스가 아직 자세히 고려되지 않고 있다. IMS(IP Multimedia Subsystem)를 사용하는 대화형 멀티미디어 서비스에 대한 5G의 기존 인프라(infrastructure)를 사용함으로써, 미디어 및 사용 예(use case)의 각 새로운 형태에 대해 추가적인 파라미터 및 절차가, 멀티미디어의 다양한 형태를 지원하기 위해 요구될 수 있다.
본 개시는 아바타 미디어(예, 3D 아바타)의 데이터를 이용한 대화형 서비스를 제공하기 위한 방법 및 장치를 제공한다.
본 개시는 무선 통신 네트워크에서 발신(originating) 단말의 미디어 콜 서비스를 수행하는 방법에 있어서, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 착신(terminating) 단말에게 전송하는 동작; 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 착신 단말로부터 수신하는 동작; 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하는 동작; 및 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하는 동작을 포함하는 방법을 제공한다.
본 개시는 무선 통신 네트워크에서 착신(terminating) 단말의 미디어 콜 서비스를 수행하는 방법에 있어서, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 발신(originating) 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 상기 발신 단말로부터 수신하는 동작; 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 발신 단말에게 전송하는 동작; 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하는 동작; 및 상기 생성된 움직임 정보를 이용하여 상기 발신 단말과 아바타 콜 서비스를 수행하는 동작을 포함하는 방법을 제공한다.
본 개시는 무선 통신 네트워크에서 미디어 콜 서비스를 수행하는 발신(originating) 단말에 있어서, 송수신부; 및 상기 송수신부를 제어하여, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 착신(terminating) 단말에게 전송하고, 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 착신 단말로부터 수신하고, 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하고, 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하도록 구성되는 프로세서를 포함하는 단말을 제공한다.
본 개시는 무선 통신 네트워크에서 미디어 콜 서비스를 수행하는 착신 단말에 있어서, 송수신부; 및 상기 송수신부를 제어하여, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 발신 단말의 지원 여부 정보를 포함하는 제1 SDP offer 메시지를 상기 발신 단말로부터 수신하고, 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP response 메시지를 상기 발신 단말에게 전송하고, 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하고, 상기 생성된 움직임 정보를 이용하여 상기 발신 단말과 아바타 콜 서비스를 수행하도록 구성된 프로세서를 포함하는 단말을 제공한다.
본 개시의 일 양상(aspect)에 따른 송신 장치의 방법에 있어서, 수신 장치로, 아바타 데이터와 관련 움직임 정보와 연관된 파라미터의 협상을 위한 SDP(Session Description Protocol) offer 메시지를 전송하는 단계; 및 상기 수신 장치로부터, 상기 SDP offer 메시지에 포함된 관련 정보에 송신 단말이 제공하는 아바타 데이터와 관련 움직임 정보에 기초하여 생성된 수신 단말이 제공하는 아바타 데이터와 관련 움직임 데이터 관련 정보를 포함하는 SDP answer 메시지를 수신하는 단계를 포함할 수 있다.
본 개시의 다른 양상 따른 수신 장치의 방법에 있어서, 송신 장치로부터, 아바타 데이터와 관련 움직임 정보와 연관된 파라미터의 협상을 위한 SDP(Session Description Protocol) offer 메시지를 수신하는 단계; 상기 SDP offer 메시지에 포함된 송신 단말이 제공한 아바타 데이터와 관련 움직임 데이터 관련 정보에 기초하여, 수신 단말의 아바타 데이터와 관련 움직임 데이터 관련 정보를 포함하는 SDP answer 메시지를 생성하는 단계; 및 상기 송신 장치로, 상기 SDP answer 메시지를 전송하는 단계를 포함할 수 있다.
본 개시의 또 다른 양상에 따른 송신 장치에 있어서, 트랜시버; 및 컨트롤러를 포함하며, 상기 컨트롤러는: 수신 장치로, 아바타 데이터와 관련 움직임 정보와 연관된 파라미터의 협상을 위한 SDP(Session Description Protocol) offer 메시지를 전송하고, 상기 수신 장치로부터, 상기 SDP offer 메시지에 포함된 아바타 데이터와 관련 움직임 데이터 관련 정보에 기초하여 생성된 수신 장치의 아바타 데이터와 관련 움직임 데이터 관련 정보를 포함하는 SDP answer 메시지를 수신하도록 구성 할 수 있다.
본 개시의 또 다른 양상에 따른 수신 장치에 있어서, 트랜시버; 및 컨트롤러를 포함하며, 상기 컨트롤러는: 송신 장치로부터, 아바타 데이터와 관련 움직임 정보와 연관된 파라미터의 협상을 위한 SDP(Session Description Protocol) offer 메시지를 수신하고, 상기 SDP offer 메시지에 포함된 송신 장치의 아바타 데이터와 관련 움직임 데이터 관련 정보에 기초하여, 수신 장치의 아바타 데이터와 관련 움직임 데이터 관련 정보를 포함하는 SDP answer 메시지를 생성하고, 상기 송신 장치로, 상기 SDP answer 메시지를 전송하도록 구성할 수 있다.
본 개시의 실시예에 따르면, 아바타 미디어(예, 3D 아바타)를 이용한 대화형 서비스를 위해서 각 단말의 제공하는 아바타 데이터 및 해당 아바타 오브젝트의 움직임 변화량 정보의 제공을 통해 서비스 이용이 가능해진다.
도 1a는 3G(third generation) 네트워크의 구조를 예시한다.
도 1b는 LTE(long term evolution) 네트워크의 구조를 예시한다.
도 2a는 본 개시의 일 실시예에 따른 VoLTE(voice over LTE) 지원 단말의 음성 및 비디오 코덱 및 RTP (Real-time Transport Protocol)/UDP (User Datagram Protocol)/IP (Internet Protocol) 프로토콜의 구조를 예시한다.
도 2b는 본 개시의 일 실시예에 따른 CMR(Codec Mode Request) 메시지를 예시한다.
도 3은 본 개시의 일 실시예에 따른 RTCP 프로토콜을 통해 전송되는 TMMBR(Temporary Maximum Media Bit-Rate Request) 메시지의 구조를 예시한다.
도 4는 본 개시의 일 실시예에 따른 아바타 컨텐트 및 관련 움직임 정보 를 전송하기 위한 5G(5th Generation) 네트워크의 구조를 예시한다.
도 5는 본 개시의 일 실시예에 따른 아바타 컨텐트 및 관련 움직임 정보 를 전송하기 위한 5G 네트워크의 프로토콜 아키텍쳐를 예시한다.
도 6은 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템을 사용하여 아바타 컨텐트 전송 방법에서 송신 단말(UE A) 및 수신 단말(UE B)이 파라미터 및 관련 움직임 정보를 협상(negotiate)하고, 유선 또는 무선 전송 경로(path)의 QoS(quality of service)를 보장(secure)하기 위한 절차를 예시한다.
도 7은 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템을 사용하여 송신 단말(UE A) 및 수신 단말(UE B)이 아바타 컨텐트 및 관련 움직임 정보를 협상(negotiate)하고, 서비스 개시 시 서로 다른 종류의 프로토콜을 통해 전송되기 위한 절차를 예시한다.
도 8는 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템을 사용하여 아바타 컨텐트 전송 방법에서 송신 단말(UE A) 및 수신 단말(UE B)이 파라미터 및 관련 움직임 정보와 추가적인 영상 통화를 위한 코덱 및 파라미터를 협상(negotiate)하고, 아바타 데이터 전송 등 아바타 콜 셋업을 위한 준비 시 2D 영상 통화를 이용하여 서비스를 이용하다 아바타 콜로 전환하기 위한 절차를 예시한다.
도 9는 본 개시의 일 실시예에 따른 SDP offer의 예를 나타낸다.
도 10는 본 개시의 일 실시예에 따른 SDP offer의 예를 나타낸다.
도 11은 본 개시에 따른 발신 단말의 미디어 콜 수행 방법을 예시하는 도면이다.
도 12은 본 개시에 따른 착신 단말의 미디어 콜 수행 방법을 예시하는 도면이다.
도 13은 본 개시에 따른 단말(UE) 장치의 구성을 예시하는 도면이다.
도 14는 본 개시에 따른 IMS 엔터티의 장치 구성을 예시하는 도면이다.
이하, 본 개시의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 개시가 속하는 기술 분야에 익히 알려져 있고 본 개시와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 개시의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 개시의 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다.
이때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능할 수 있다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능할 수 있다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능할 수 있다.
이때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일부 실시 예에 따르면 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 일부 실시 예에 따르면, '~부'는 하나 이상의 프로세서를 포함할 수 있다.
본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS; mobile station), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자 장치 또는 단순히 장치라 지칭할 수도 있다.
후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 개시는 멀티미디어 컨텐트 캡쳐링, 프로세싱, 프리-프로세싱, 포스트-프로세싱, 메타데이터 딜리버리, 3D 오브젝트(Object)의 지오메트리(Geometry) 정보 및 관련 텍스쳐(texture) 정보를 포함하는 3D 아바타 (얼굴, 풀바디, 하프 바디 etc.) 등의 딜리버리, 3D 오브젝트 컨텐트의 디코딩 및 렌더링에 관한 것이다. 본 개시에서, 3D 아바타 컨텐트는 3D 오브젝트 Geometry 및 texture 등으로 구성된 메쉬(Mesh) 형태의 3D 애셋(Asset) 파일이나, 3D 프로젝션 이미지 및 3D 오브젝트 Geometry 정보 등으로 구성된 PCC(point cloud compression) 형태의 3D Asset 파일을 지칭할 수 있다.
3D 컨텐트는 HMD (head mounted devices) 및 AR (Augmented Reality) 들을 사용하여 소비될 수 있다. 그러나, 컨텐트의 특성 때문에, 사용자는 한번에 전체 360도로 구성된 3D 컨텐트를 볼 수 없고, 가상의 공간에 임의의 카메라로 지칭된 사용자의 시점을 통해 보여지는 뷰 다이렉션(view direction)등을 고려한 일부만을 볼 수 있다. 이러한 이유로, 전체 3D 오브젝트는 임의의 위치에서 충분히 높은 품질의 뷰 다이렉션 등을 고려한 컨텐트를 제공하기 위해 매우 높은 해상도(resolution)가 요구된다.
3D 오브젝트 컨텐트의 고 해상도 요구사항으로 인해, 딜리버리를 위한 대역폭(bandwidth: BW)의 절약을 시도하는 많은 기술이 있다. 3D 컨텐트 송신 장치는 전체의 3D 오브젝트를 고화질의 멀티 카메라로 보내기에는 많은 대역폭이 필요하기 때문에 멀티 카메라의 인풋을 받아서 공간 내의 하나 또는 다수의 오브젝트를 표현할 수 있다. 또한 3D 컨텐트 송신 장치는 해당 멀티 카메라 정보를 바탕으로 상기 인풋을 3D 오브젝트로 생성하며 3D 오브젝트 각각을 전송하기 용이한 방법으로 압축하기 위하여 Mesh 나 PCC 형태로 변형이 가능하며 3D 오브젝트들의 관계성을 하나의 Scene description 등으로 표현할 수 있다. 예를 들어, 3D 컨텐트 송신 장치는, Mesh 형태의 object를 대역폭 및 단말의 렌더링 성능 (디스플레이 레졸루션, 메모리 등)을 고려하여 적절한 파라미터 (geometry point 및 texture resolution)를 가지도록 이미지/비디오 압축 및 컨텐트를 생성하여 주며, PCC의 경우 해당 오브젝트를 표현하기 위한 point의 개수를 조절하여 네트워크 및 송신/수신 단말의 요구사항을 반영한 3D 오브젝트 컨텐트를 생성할 수 있다.
대화형 서비스는 양방향(two way) 통신을 지원하기 위해 매우 낮은 레이턴시(latency)를 요구하고, 위에 언급된 고품질 3D object 전송에 이용 시, 추가적인 요구사항이 발생한다. 본 개시에서는, 3D 오브젝트 컨텐트를 캡쳐 시 고화질의 3D 오브젝트 컨텐트를 생성하며, 대화형 서비스 이용 시 해당 오브젝트의 움직임 변화량만을 전달하여 해당 3D 오브젝트의 움직임을 출력할 수 있다.
본 개시는 대화형 3D 아바타 오브젝트를 위한 3D 오브젝트 컨텐트 및 관련 움직임 변화량 정보의 딜리버리 기법을 소개한다. SDP(session description protocol) 시그널링을 위한 새로운 파라미터를 정의함으로써, 수신기(receiver)는 뷰어의 현재 뷰포트(viewport)의 랜더링을 위해 요구되는 3D 아바타 오브젝트의 컨텐트를 요청할 수 있다. 각 단말에서 최초 연결 시 3D 오브젝트의 한 번의 전송 및 수신이 이루어지고 이후 해당 오브젝트의 움직임에 따른 변화량만 전송되기 때문에, 프로세싱 파워 및 대역폭이 모두 절약될 수 있다.
본 개시에서 발신 단말은 자신의 3D 아바타 오브젝트를 수신자에게 지속적으로 보낼 필요 없이 대화형 3D 아바타 딜리버리를 가능하게 한다. 수신 단말에 의해 요구되는 3D 아바타 오브젝트의 움직임 변화량 정보만 딜리버리하게 함으로써, 대역폭이 절약될 수 있다. (필요하다면) 발신 단말은 2D 이미지/비디오를 전송하여 수신단말이 수신한 3D 아바타 오브젝트의 실제 변화량를 계산하게 할 수 있다. 이로써 발신 단말의 3D 아바타 오브젝트의 움직임 변화량이 수신자 단말에서 렌더링될 수도 있다.
도 1a는 3G 네트워크의 구조를 예시한다.
도 1a의에서, 3G 네트워크 (100a)는 사용자 장치(UE) (110a), NodeB (120a), RNC(Radio Network Controller) (130a) 및 MSC(Mobile Switching Center) (140a)를 포함한다. 3G 네트워크 (100a)는 다른 모바일 통신 네트워크 및 PSTN(public switched telephone network)와 연결된다. 이러한 3G 네트워크 (100a)에서, 음성은 AMR(Adaptive Multi-Rate) 코덱을 이용하여 압축 또는 복원되고(compressed/restored), AMR 코덱은 양방향 call 서비스를 제공하기 위해 단말 (UE) (110a) 및 MSC (140a)에 인스톨된다. MSC (140a)는 AMR 코덱으로 압축된 음성을 PCM(Pulse Code Modulation) 포맷으로 변환하고, 이를 PSTN으로 전송하거나, 그 반대도 마찬가지로, MSC (140a)는 PSTN으로부터 PCM 포맷 내의 음성을 전송받고, 이를 AMR 코덱으로 압축하고, 기지국 (NodeB) (120a)으로 전송한다. RNC (130a)는 CMC(Codec Mode Control) 메시지를 이용하여 실시간으로 UE (110a) 및 MSC (140a)에 인스톨된 음성 코덱의 call 비트 레이트를 제어할 수 있다.
그러나, 4G (LTE)에서 패킷-교환 네트워크(packet-switched network)가 도입됨에 따라, 음성 코덱은 단지 단말에 인스톨되고, 발신 단말에서 20ms의 인터벌로 압축된 음성 프레임은, 기지국 또는 전송 경로의 중간에 위치된 네트워크 노드에서 복원되지 않고, 상대방 단말(counterpart terminal)로 전송된다.
도 1b는 LTE 네트워크의 구조를 예시한다.
도 1b에서, LTE(4G) 네트워크 (100b)은 UE (110b), eNodeB (120b, 130b) 및 S-GW(Serving Gateway)/P-GW(Packet Data Network Gateway) (140b, 150b) 중 적어도 하나를 포함할 수 있다.
도 1b에서, 음성 코덱은 단지 UE (110b)에 인스톨되고, 각 단말(UE) (110b)은 CMR(Codec Mode Request) 메시지를 이용하여 상대방 단말의 음성 비트 레이트를 조정할 수 있다.
도 1b에서, 기지국인, eNodeB (120b, 130b)는 RF 기능(function)을 전담하는(dedicated to) RRH(Remote Radio Head) (120b) 및 모뎀 디지털 신호 처리를 전담하는 DU(Digital Unit) (130b)로 구분될 수 있다. eNodeB (120b, 130b)는 S-GW (140b) 및 P-GW (150b)를 통해 IP 백본(backbone) 네트워크에 연결될 수 있다. IP 백본 네트워크는 다른 서비스 프로바이더(provider)의 이동 통신 네트워크 또는 인터넷에 연결된다.
도 2a는 본 개시의 일 실시예에 따른 VoLTE 지원 단말의 음성 및 비디오 코덱 및 RTP/UDP/IP 프로토콜과 상기 미디어 관련 부가 정보를 전송하기 위한 SCTP(Stream Control Transmission Protocol)/UDP/IP 프로토콜의 구조를 예시한다.
도 2a를 참조하면, 이 구조의 하단(bottom)에 위치한 IP 프로토콜 (23)은 프로토콜 구조의 상단에 위치한 PDCP (Packet Data Convergence Protocol)와 연결된다. 도 2a에서, 미디어 데이터(예컨대, speech, video, text)는 RTP 프로토콜 (21)/UDP 프로토콜 (22)/ IP 프로토콜 (23)을 통해 전송될 수 있고, 미디어와 관련된 부가 정보는 SCTP 프로토콜 (24)/ UDP 프로토콜 (22)/ IP 프로토콜 (23)을 통해 전송될 수 있다. RTP/UDP/IP 헤더는 음성 및 비디오 코덱의 압축된 미디어 프레임(미디어 데이터)에 부가되고(attached), STCP/UDP/IP 헤더는 미디어 관련 부가 정보에 부가되어 LTE 네트워크를 통해 상대방 단말에 전송될 수 있다. 또한, 상대방 단말은 네트워크로부터 압축되어 전송된 미디어 패킷(미디어 데이터)을 수신하고, 미디어를 복원하고, 스피커를 통해 듣고, 미디어를 디스플레이하고, 볼 수 있다. 이때, 압축된 음성 패킷 및 비디오 패킷이 동시에 도착하지 않더라도, RTP 프로토콜 헤더의 타임스탬프 정보가 두 미디어(음성 및 비디오)를 동기화하기 위해 사용될 수 있다.
도 2b는 CMR 메시지를 예시한다.
도 2b에서, CMR 메시지는 call 동안 전송 상태의 변경에 따라 상대방 단말이 음성을 압축하는 비트 레이트를 조정하기 위해 사용되는 CMR 메시지일 수 있다.
도 2b를 참조하면, 도 2b의 상단 부분은 페이로드 포맷 (210)에 대응하고, CMR 필드 (211), ToC(Table of Contents) 필드 (212), 압축된 미디어 데이터를 포함하는 압축된 미디어 필드 (213) 및/또는 패딩 비트들을 포함하는 패딩 비트 필드 (214)를 포함할 수 있다.
도 2b에서, 4-비트 CMR 필드 (211)가 상대방 단말의 음성 코덱에 의해 사용될 것이 요청되는 비트 레이트를 디스플레이하기 위해 speech에 의해 지시된 음성 코덱에서 압축된 음성 프레임 (미디어 데이터)에 추가되고, 4-비트 ToC 필드 (212)가 압축 및 전송된 프레임(미디어 데이터)의 비트 레이트 및 타입을 지시하기 위해 추가될 수 있다. VoLTE는 AMR(Adaptive Multi-Rate), AMR-WB(Adaptive Multi-Rate Wideband), 및 EVS(Enhanced Voice Services)와 같은 음성 코덱을 지원할 수 있다.
CMR 메시지는 페이로드 프로토콜 외에 RTCP 프로토콜(RTP Control Protocol)을 통해 전송될 수도 있다.
도 3은 본 개시의 일 실시예에 따른 RTCP 프로토콜을 통해 전송되는 TMMBR 메시지의 구조를 예시한다.
도 3을 참조하면, TMMBR 메시지는 상대방 단말에 인스톨된 이미지 코덱의 비트 레이트를 call 동안 동적으로 조정하기 위해, RTCP에 포함될 수 있다. 실시예에서, TMMBR 메시지는 Exp의 값을 지시하는 Exp 필드 (310) 및 Mantissa 의 값을 지시하는 Mantissa 필드 (320)를 포함할 수 있다. TMMBR 메시지를 수신하는 UE(단말)는 Exp 필드 (310) 및 Mantissa 필드 (320)에 기초하여, 압축된 이미지의 비트 레이트를 "Mantissa Х 2Exp" bps 이하로 유지할 수 있다. 이 "Mantissa Х 2Exp" 값은 비디오 call을 시작하기 전에 협상된 비트 레이트와 같거나 또는 작게 설정될 수 있다.
도 4는 본 개시의 일 실시예에 따른 아바타 데이터와 관련 움직임 정보를 전송하기 위한 5G 네트워크의 구조를 예시한다.
도 4에서, 3D 아바타 데이터는 구형 리그(sphere ball rig)로 구성된 멀티 카메라에 의해 캡쳐링되고 생성될 수 있다. 또한 3D 아바타 관련 움직임 정보는 UE(410)에 장착된 적외선 카메라 기반의 깊이 카메라(depth camera: 3D 이미지를 나타내기 위해 픽셀의 깊이를 계산할 수 있는 카메라의 일종) 또는 일반 이미지에서 그 움직임의 변화량을 기반으로 생성될 수 있다.
도 4를 참조하면, 5G 네트워크 (400)은 UE (410), gNodeB (gNB) (420, 430) 및 UPF (User Plane Function) (440)중 적어도 하나를 포함할 수 있다. 실시예에서, UE (410)은 360도 카메라에 연결될 수 있다.
LTE의 eNodeB, S-GW 및 P-GW에 대응하는 5G 노드들은 gNB (410), UPF (440) 및 DN(Data Network)이다. 3D 아바타 데이터는 기지국 (예컨대, gNB)을 통과하지 않고 비면허(unlicensed) 주파수 대역을 사용하는 LTE, 5G의 사이드링크 또는 Wi-Fi 다이렉트를 통해 단말간에 전송되거나, 또는, USB-C 케이블을 통해 단말간에 직접 전송될 수 있다. USB-C가 사용되는 경우, 많은 양의 데이터가 에러 없이 낮은 레이트로 전송될 수 있고, 비디오는 카메라가 아닌 단말에서 압축될 수 있다.
도 5는 본 개시의 일 실시예에 따른 아바타 데이터 및 관련 움직임 정보를 전송하기 위한 5G 네트워크의 프로토콜 아키텍쳐를 예시한다.
멀티 카메라로부터 캡쳐 된 이미지는 송신자(송신 단말)와 수신자(수신 단말) 사이에 협상된 요구사항에 따라 다양한 3D Asset 데이터 형태 (Mesh or PCC 등)로 재구성되고, 해당 3D object의 생성 형태가 PCC인 경우 패치 형태로 생성된 프로젝션 이미지가 비디오 코덱 (511) (AVC(Advanced Video Coding) 또는 HEVC(High Efficiency Video Coding)와 같은)을 이용하여 압축되거나, 해당 3D object의 생성 형태가 Mesh 인 경우 3D object의 geometry 정보는 바이너리 형태로 저장되어 (Draco 등) 바이너리 압축 코덱을 이용하여 압축되며 텍스쳐 이미지는 비디오 코덱 (511) (AVC 또는 HEVC와 같은) 을 이용하여 압축될 수 있다. 또한 3D object 관련 애니메이션 정보 (e.g. 3D object가 Human Face일 경우 얼굴의 특징점 변화량 등)는 바이너리 형태로 저장되어 3D 데이터와 같이 전송되거나 별도의 Data channel을 이용하여 전송될 수 있다. 이후 상기 생성된 3D Asset 데이터는 수신 단말의 주소를 포함하는 RTP 및 인터넷 프로토콜(513)과 같은 다양한 전송 프로토콜(transport protocols)(512)을 사용하여 딜리버리되고, 5G NR(New Radio) 모뎀으로 전송되고, 업링크를 통해 수신 단말로 전송될 수 있다. LTE 모뎀의 프로토콜 구조와 달리, NR 모뎀(modem)은 PDCP의 상단에 위치하는 SDAP(Service Data Adaptation Protocol) (521)라 불리는 새로운 프로토콜을 갖는다.
수신 단말은 수신 PDU(protocol data unit)에서 각 프로토콜의 헤더를 제거하여 페이로드를 획득하고 상기 페이로드를 3D object 렌더러에 제공되는(fed into) 압축된 3D 데이터 (3D Asset)의 형태로 복원(recover)할 수 있다. 복원된 3D 데이터는 (필요하다면) 3D 모델링되고, 해당 데이터는 가상의 공간에 3D 형태로 배치될 수 있다. 사용자의 현재 뷰포트에 매칭되는 뷰(view)가 수신 단말에 연결된 디스플레이 상에 랜더링될 수 있다. 사용자의 현재 뷰 포트는 어플리케이션 및 서비스 사업자에 의해서 달라질 수 있다. 예를 들어, 3D 아바타 콜의 경우 사용자가 3D 형태의 아바타를 정면에서 사용자의 시점에 따라 특정 공간 위치에서 바라본다고 가정을 할 수 있다. 또한 특정 공간 위치를 설정하는 방법은 사용자와 디스플레이상의 거리 및 공간의 크기와 3D 아바타의 크기 등을 고려하여 실제로 측정하거나 디스플레이 해상도 크기에 맞춰 일정한 크기로 조정 및 설정하여 해당 설정 값을 바탕으로 사용자에게 3D 컨텐트가 보여질 수 있다.
도 6는 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템(IMS)을 사용하여 아바타 형태의 비디오 콜을 수행하기 위한 전송 방법에서 송신 단말(UE A) 및 수신 단말(UE B)이 파라미터를 협상(negotiate)하고, 유선 또는 무선 전송 경로(path)의 QoS를 보장하기 위한 절차를 예시한다.
도 6에서, 송신 단말 (UE A)(630) 및 수신 단말 (UE B)(632) 는 SDP 메시지(SDP offer 메시지 (602)/SDP answer 메시지 (604))를 사용하여 3D 아바타 데이터 타입 및 관련 정보 (예를 들어, 3D avatar type (Face or half body or full body), 아바타 관련 텍스쳐 해상도 (texture resolution) 등)와 해당 3D 아바타의 애니메이션 관련 정보 (예컨대, 특징점 (Feature point) 의 움직임에 대한 변화량 (coefficient))에 대한 파라미터의 협상을 수행할 수 있다. 다시 말해, SDP 기반 협상이 송신 단말 (UE A) 및 수신 단말 (UE B) 사이에 3D 아바타 데이터에 대한 파라미터(들)을 협상하기 위해 수행될 수 있다.
단계 601에서, 사용자의 선택 또는 사전에 정의한 설정에 따라 송신 단말 (UE A)(630)은 수신 단말(UE B)(632)과 대화형 서비스 연결 시 3D 아바타를 이용한 비디오 콜을 서비스로 선택 할 수 있다.
단계 602에서, 송신 단말(630)은 코덱(들), 3D 아바타 관련 파마미터(들) 중 적어도 하나를 결정하고 SDP 메시지의 페이로드에 삽입할 수 있다. 삽입된 코덱(들) 또는 3D 아바타 관련 파마미터(들)은 송신 단말(630)의 단말 성능 및 지원 가능한 세션에 대한 사용자 선호도(단계 601 과 같이 사용자의 선택 등)를 반영할 수 있다. 송신 단말(630)은 대역폭 요구사항 및 각 특성을 포함하는 SDP 메시지 (예, SDP offer)를 만들고, 각 가능한 미디어 플로우에 대한 로컬 포트 넘버를 할당할 수 있다.
대화형 서비스에 여러(multiple) 미디어 플로우가 제공될 수 있고, 각 미디어 플로우(m=line in SDP)에 대하여, 여러 코덱 또는 여러 아바타 관련 파마미터(예, 3D 아바타 관련 파라메터)의 선택이 제공될 수 있다. 아바타 관련 파마미터는 3D 데이터 관련 정보 (e.g. Media (Contents) type = 3gpp_3DAsset_Face), 및 움직임 지원 여부 판단 정보 (e.g. FACS(Facial action coding system) support indication) 중 적어도 하나를 포함할 수 있다. 상기 송신 단말(630)은 상기 SDP 페이로드를 SIP(Session Initiation Protocol) invite 메시지 내에 포함시켜 상기 수신 단말(632)에게 전송할 수 있다. 이하에서는 상기 송신 단말과 상기 수신 단말 사이에서 메시지 송수신에 관여하는 IMS 엔터티들의 동작에 관하여 설명할 것이나, 이는 본 개시의 통신 환경에 대한 이해를 돕기 위한 것일 뿐이며, 상기 송신 단말과 상기 수신 단말은 직접적으로 상대방과 통신하는 것으로 간주될 수 있다.
상기 송신 단말(630)은 상기 송신 단말(630)에게 에 할당된 P-CSCF(Proxy Call Session Control Function) (예를 들어, P-CSCF#1 (640))로 상기 SIP invite 메시지를 전송할 수 있다.
P-CSCF#1(640)은 미디어 파라미터(컴포넌트)를 검사(examine)할 수 있다. 만일 P-CSCF#1(640)가, P-CSCF 로컬 정책, 또는 (이용 가능하다면) PCRF(Policy and Charging Rules Function) 또는 PCF(Policy Control Function)로부터 온 대역폭 인증 제한 정보(bandwidth authorization limitation information)에 기초하여, IMS 세션 내에서 상기 미디어 파라미터의 사용이 허용되지 않음을 확인한다면, 세션 시작 시도(session initiation attempt)(즉, 상기 SIP invite 메시지)를 거절할 수 있다. 이 거절은 IETF　RFC　3261　[12]에 지정된 절차들에 따라, P-CSCF#1(640)의 네트워크의 로컬 정책에 의해 허용되는 미디어 파라미터를 이용하여 세션 시작을 재-시도하기 위해 발신(originating) UE(예컨대, UE A(630))에 대한 충분한 정보를 포함할 수 있다.
도 6에서, P-CSCF#1(640)는 초기 세션 시작 시도가 계속되도록 허용할 수 있다. 이 단계에서, P-CSCF가 PCRF/PCF와 상호작용하여야 하는지 여부는 오퍼레이터 정책에 기초한다. P-CSCF#1(640)은 S-CSCF (Session Call Session Control Function)#1(642)로 INVITE 메시지를 전달(forward)할 수 있다. S-CSCF#1(642)은 미디어 파라미터(컴포넌트)를 검사할 수 있다.
S-CSCF#1(642)이, 로컬 정책 또는 발신(originating) 사용자의 가입자 프로파일에 기초하여, 미디어 파라미터가 IMS 세션 내에서 사용되는 것이 허용되지 않음을 확인한다면, 세션 시작 시도를 거절할 수 있다. 이 거절은 IETF RFC 3261 [12]에 지정된 절차들에 따라, S-CSCF#1(642)의 네트워크의 로컬 정책 및 발신 사용자의 가입자 프로파일에 의해 허용되는 미디어 파라미터를 이용하여 세션 시작을 재-시도하기 위해 발신 UE에 대한 충분한 정보를 포함할 수 있다.
도 6에서, S-CSCF#1(642)는 초기 세션 시작 시도가 계속되도록 허용할 수 있다. S-CSCF#1(642)는 S-S 세션 플로우 절차를 통해, I-CSCF (Interrogating Call Session Control Function) #2(654) 를 거쳐 S-CSCF#2(652)로 INVITE 메시지를 전달할 수 있다.
S-CSCF#2(652)는 미디어 파라미터(컴포넌트)를 검사할 수 있다. 만일 S-CSCF#2(652)가 로컬 정책 또는 착신(terminating) 사용자(예컨대, UE B(632))의 가입자 프로파일에 기초하여, 미디어 파라미터가 IMS 세션 내에서 사용되는 것이 허용되지 않음을 확인한다면, 세션 시작 시도를 거절할 수 있다. 이 거절은 IETF RFC 3261 [12]에 지정된 절차들에 따라, S-CSCF#2(652)의 네트워크의 로컬 정책 및 발신 사용자의 가입자 프로파일에 의해 허용되는 미디어 파라미터를 이용하여 세션 시작을 재-시도하기 위해 착신 UE에 대한 충분한 정보를 포함할 수 있다.
도 6에서, S-CSCF#2(652)는 초기 세션 시작 시도가 계속되도록 허용할 수 있다. S-CSCF#2(652)는 P-CSCF#2(650)로 INVITE 메시지를 전달할 수 있다. P-CSCF#2(650)는 미디어 파라미터(컴포넌트)를 검사(examine)할 수 있다. 만일 P-CSCF#2(650)가 (P-CSCF 로컬 정책, 또는 (이용 가능하다면) PCRF 또는 PCF로부터 온 대역폭 인증 제한 정보(bandwidth authorization limitation information에 기초하여) 미디어 파라미터가 IMS 세션 내에서 사용되는 것이 허용되지 않음을 확인한다면, 세션 시작 시도(session initiation attempt)를 거절할 수 있다. 이 거절은 IETF RFC 3261 [12]에 지정된 절차들에 따라, P-CSCF#2(650)의 네트워크의 로컬 정책에 의해 허용되는 미디어 파라미터를 이용하여 세션 시작을 재-시도하기 위해 발신(originating) UE에 대한 충분한 정보를 포함할 수 있다.
도 6 에서, P-CSCF#2(650)는 초기 세션 시작 시도가 계속되도록 허용할 수 있다. 이 단계에서, P-CSCF가 PCRF/PCF와 상호작용하여야 하는지 여부는 오퍼레이터 정책에 기초한다. P-CSCF#2(650)는 INVITE 메시지를 UE B(632)로 전달할 수 있다.
상기 과정을 통해 UE A(630)에서 P-CSCF#1(640)로 전송된 아바타 관련 파라미터를 포함한 SDP 페이로드 정보는 SIP INVITE 메시지에 담겨 S-CSCF#1(642) 및 I-CSCF#2(654)와 같은 노드들을 통해 상대방 단말 UE B(632)에 연결된 IMS 엔터티(예, S-CSCF#2, P-CSCF#2)로 전송되고, 수신 단말 (UE B)(632)로 전송될 수 있다.
단계 603에서 수신 단말(UE B)(632)은, 단계 601의 송신 단말 (UE A)(630)의 동작과 같이, 사용자 선호도 또는 사전에 정의한 설정에 따라 대화형 서비스 연결 수락 시 3D 아바타를 이용한 비디오 콜을 선택할 수 있다. 수신 단말 (UE B)(632)는 이 세션에 대해 지원 가능한 코덱 또는 아바타 관련 파라미터들의 완전한 세트를 결정할 수 있다. UE B(632)는 INVITE 메시지 내의 SDP (SDP offer) 내에서 나타나는 것들과의 교집합(intersection)을 결정하거나, 송신 단말에서 지원가능한 아바타 관련 파라미터를 선택한 뒤 수신 단말이 지원가능한 아바타 관련 파라미터와 관련 정보를 각각 결정하여 이를 송신 단말에 보낼 수 있다.
수신 단말(UE B)은 송신 단말(UE A)에 의해 단계 602에서 제공된 정보에 따라 3D 아바타 관련 3D 데이터 정보 (Desired 3D media (contents) type) 및 해당 아바타 관련 움직임 지원 여부 정보 (FACS support indication etc.) 를 바탕으로 수신 단말이 지원하는 아바타 관련 3D 데이터 정보 및 움직임 지원 여부 정보를 선택할 수 있다. 지원되지 않는 각 미디어 플로우에 대하여는, 수신 단말(UE B)는 port=0인 미디어(m=line)에 대한 SDP 엔트리를 삽입할 수 있다. 지원되는 각 미디어 플로우에 대하여는, 수신 단말(UE B)는 송신 단말(UE A)으로부터의 SDP 내의 것들과 동일한 코덱 또는 아바타 관련 파라미터들, 할당된 포트를 갖는 SDP 엔트리를 삽입할 수 있다.
단계 604에서 UE B(632)는 공통(common) 미디어 플로우 및 코덱, 아바타 관련 파라미터, 아바타 움직임 지원 여부 정보 (FACS support indication)를 리스팅하는 정보 중 적어도 하나를 포함하는 SDP(SDP response/answer) 를 UE A(630)에게 전송할 수 있다. 이하에서는 상기 수신 단말과 상기 송신 단말 사이에서 메시지 송수신에 관여하는 IMS 엔터티들(예, P-CSCF, S-CSCF, I-CSCF 등)의 동작에 관하여 설명할 것이나, 이는 본 개시의 통신 환경에 대한 이해를 돕기 위한 것일 뿐이며, 상기 수신 단말과 상기 송신 단말은 직접적으로 상대방과 통신하는 것으로 간주될 수 있다.
상기 UE B(632)는 상기 SDP(SDP response/answer) 를 P-CSCF#2(650)로 전송할 수 있다.
P-CSCF#2(650)는 미디어 플로우 및 코덱/아바타 관련 파라미터의 선택에 대한 QoS 리소스를 승인(authorize)할 수 있다. P-CSCF#2(650)는 SDP response/answer을 S-CSCF#2(652)로 전달할 수 있다. S-CSCF#2(652)는 SDP response/answer을 I-CSCF#2(654)를 통해 S-CSCF#1(642)로 전달할 수 있다. S-CSCF#1(642)는 SDP response/answer을 P-CSCF#1(640)로 전달할 수 있다.
P-CSCF#1(640)는 미디어 플로우 및 코덱/아바타 관련 파라미터의 선택에 대한 QoS 리소스를 승인(authorize)할 수 있다. P-CSCF#1(640)는 SDP response/answer을 UE A(630)로 전달할 수 있다.
UE A(630)는 어떤 미디어 플로우가 이 세션에 대하여 사용되어야 하는지를 결정하고, 어떤 코덱, 아바타 관련 파라미터가 미디어 플로우의 각각에 대하여 사용되어야 하는지를 결정할 수 있다.
하나 이상의 미디어 플로우가 있다면, 또는 미디어 플로우에 대한 코덱, 아바타 관련 파라미터의 하나 이상의 선택이 있다면, UE A(630)은 코덱, 아바타 관련 파라미터 하나를 결정하기 위해 다른 offer를 UE B(632)에게 전송하여 UE B(632)와 코덱들, 아바타 관련 파라미터들을 협상하거나 UE B의 응답 메시지 내 요청하는 코덱, 아바타 관련 파라미터 관련 priority를 보고 결정할 수 있다.
또한 송신 단말 (UE A)는 초기 요청 메시지 내의 움직임 지원 정보 (FACS support indication)을 보고 아바타 관련 움직임 표현을 수신 단말 (UE B)가 지원한다면 추가 절차 (단계 605 및 단계 606)를 통해서 움직임 관련 파라미터 협상을 진행할 수 있다. 수신 단말 (UE B)은 응답 메시지(604) 내 움직임 관련 정보를 전송 가능하다는 정보를 포함하여 보낼 수 있다. 송신 단말(UE A)은 응답 메시지(604) 내의 수신 단말의 지원 가능한 움직임 관련 파라미터 지원 여부를 보고 아바타 렌더링시 수신 단말(UE B)의 해당 정보(전체 3D 아바타 데이터가 아니고 움직임 관련 정보)만을 수신하여 송신 단말 의 사용자에게 아바타 콜 서비스를 제공할 수 있다. 만약 3D 아바타 관련 지원을 할 수 있으나 위의 움직임 관련 지원 정보 등이 별도로 지원 되지 않을 경우 전체 3D 아바타 데이터를 실시간으로 전송 해야 하며, 이 경우 해당 환경 (대역폭 요구사항 등)을 고려한 새로운 미디어 플로우 협상이 필요할 수 있다.
예를 들어, 만약 3D 아바타 콜을 위한 3D 아바타 관련 파라미터를 바탕으로 양 단말이 해당 3D 아바타 관련 데이터 렌더링을 지원하며 움직임 표현 파라미터를 지원한다면, 양 단말은 해당 3D 아바타 콜 서비스를 위해서 초기 연결 설정 후 각 사용자의 3D 아바타를 주고 받은 뒤, 실시간으로 사용자의 움직임 정보 (FACS info. or facial feature point coefficient etc.)로 해당 3D 아바타 콜을 수행할 수 있다. 하지만 3D 아바타 콜의 서비스 수행을 선택하였으나, 604의 과정에서 적어도 하나의 단말이 별도의 사용자 움직임 정보를 제공하지 않거나 상대의 단말에 적합한 움직임 표현 정보 (FACS type)을 제공하지 않을 경우, 해당 3D 아바타 콜 수행을 위해 움직임 표현 정보를 제공하지 않은 단말에 실시간으로 전체 3D 아바타 데이터를 캡쳐 및 생성하여 전송할 수도 있다. 또한, 3D 아바타 콜 서비스 이용 시 3D 아바타 데이터는 UE A 및 UE B가 사전에 공유하거나 교환하여 저장되어 있거나 예전의 서비스 이용 시 기 다운로드되어 저장되어 있을 수 있다. 만약 상대의 3D 아바타 데이터를 보유하고 있지 않을 경우 단계 602와 단계 604를 통해 상기 초기 파라미터 협상이 완료된 후 단계 610 과정을 통해 각 단말이 가지고 있는 자신 3D 아바타 데이터를 서로 교환할 수 있다. 또한 사용자의 선택에 따라 상대의 사용자가 기존의 보유하고 있는 아바타 데이터를 업데이트하기 원할 경우, 사전에 기 다운로드 되어 있는 3D 아바타 데이터를 이용하여 먼저 서비스를 연결하거나, 애니메이션 아바타 등을 이용하여 서비스를 이용하는 도중에 단계 610 과정에서 업데이트된 3D 아바타 데이터를 교환한 후 해당 3D 아바타 데이터를 이용하여 해당 3D 아바타를 교체하여 대화형 3D 아바타 콜 서비스를 제공 및 이용할 수 있다.
수신 단말 (UE B)(632)은 단계 602를 통해 수신한 SDP offer를 획득(fetch) 할 수 있다. 단계 602에서, 수신 단말은 SDP offer 내의 b=AS(도 9의 910 참고)를 수신/획득하고, b=AS가 허용되는지를 결정할 수 있다. 실시예에서, 수신 단말은 수신 단말에 허용된 최대 비트 레이트 값과 b=AS의 값을 비교함으로써, b=AS가 허용되는지를 결정할 수 있다. 여기서, b=AS는 AS(application specific) 대역폭 속성을 의미한다. 실시 예로서, SDP offer 내의 b=AS는 송신 단말에 의해 지정된 대응 미디어(어플리케이션)와 관련된 최대 대역폭을 지시할 수 있다.
만일 수신 단말에 허용된 최대(maximum) 비트 레이트 값과 비교하여 b=AS의 값이 허용되지 않는(unacceptable) 경우, 수신 단말은 그 값을 감소시켜서 SDP response (604) 메시지에 포함시켜 송신 단말에게 보낼 수 있다. 이후 수신 단말은 송신 단말로부터 다시 제공되는 b=AS의 값이 허용되는지를 결정할 수도 있다.
만일 b=AS의 값이 허용된다면, 수신 단말은 이 값(허용된 값)에 기초하여 적당한(appropriate) 파라미터(e.g. 3D object를 구성하는 point의 개수, Texture resolution etc.)를 가지는 아바타 컨텐트를 선택할 수 있다.
만약 서로 연결을 요청하는 상대의 아바타 데이터를 보유하고 있지 않을 경우, 아바타 데이터의 송신을 요청하게 된다. 수신 단말은 단계 602에서 전달 받은 대역폭 (b=AS) 및 관련 단말의 요구사항 (UE 렌더링 요구사항 등)을 고려하여 전송 대역폭이 충분하며 단말의 렌더링 성능이 고화질 3D 오브젝트 렌더링이 가능하다면, 이를 바탕으로 4K 의 텍스쳐 등 고화질 해상도를 가지는 3D 아바타 데이터를 요청하며 수신할 수 있다. 하지만, 송신 단말의 전송 대역폭의 제한 등으로 인하여 고화질 해상도를 가지는 컨텐트를 제공하지 못하거나 송신 단말이 보유하고 있지 않을 경우, 수신 단말의 렌더링 성능이 저화질 렌더링 (e.g. HD or FHD(full HD) 해상도 텍스쳐)만을 지원하거나 실시간 서비스 등에서 단말의 성능 제약이 있다면, 수신 단말은 저화질 해상도를 가지는 3D 아바타 컨텐트를 송신 단말에 요청하여 이를 수신할 수 있다.
예를 들어, 단계 602 및 단계 604에서 3D 아바타 컨텐트 선택 및 요청 시 표 1 과 같이 3D 아바타 컨텐트의 타입(type)에 따라 종류 또는 프로파일(profile) 형태로 분류 및 정의된 형태로 제공이 가능하다. 만약 표 1의 예와 같이 특정 3D 아바타 데이터 (예, 컨텐트 타입이 3D 어셋 Face인 경우)의 프로파일이 0의 값을 가진 경우 해당 3D 아바타 데이터는 얼굴 관련 데이터(3gpp_3DAsset_FACE)를 가지고 있으며, 해당 아바타 관련 3D 오브젝트는 3000개의 포인트로 구성되어 있으며, 2K 해상도를 가지는 텍스쳐로 구성되어 있음을 알 수 있다. 또한 상기 특정 3D 아바타 데이터 (예, 컨텐트 타입이 3D 어셋 Face인 경우)는 아바타 관련 3D 오브젝트의 디테일 표현 방법 등에 따라서 좀 더 유사한 3D 컨텐트이지만 정교한 표현을 위해서 12,000 개의 포인트로 표현이 가능하며 이는 표 1에서 프로파일 1에 해당된다. 표 1에서 프로파일 0과 1은 동일한 3D 아바타 오브젝트(예, 3D 어셋 Face의 경우)를 가정할 경우 정교한 표현이나 움직임이 가능하지만 동일한 2K 텍스쳐 해상도 (Texture resolution)을 가지는 3D 아바타 데이터임을 알 수 있다.
상기와 같이 단계 602 및 604에서 SDP 메시지내의 코덱 및 3D 에셋 관련 파라미터에 따라 표 1 과 같이 동일한 3D 아바타 종류에서도 서로 다른 프로파일로 구성될 수 있으며, 또한 대역폭에 따라 단말의 텍스쳐 해상도 및 오브젝트 디테일 표현 방식 (Number of the 3d object points) 등의 선택에 따라 서로 다른 프로파일을 선택할 수 있다. 예를 들어, 동일한 아바타 종류에서도 렌더링 디바이스의 해상도 및 렌더링 될 3D 오브젝트와 가상의 카메라 (가상의 공간에서 상대 사용자의 위치)에 따라 LoD (Level of Detail) 등을 고려하여 가상의 공간에서 수신 단말의 사용자가 가까운 위치에서 송신 단말의 3D 아바타 오브젝트를 관찰할 경우 더 많은 디테일 정보를 가지는 프로파일 1을 선택하거나 만약 먼 거리에서 수신 단말의 사용자가 송신 단말의 3D 오브젝트를 바라 볼 경우 더 적은 정보의 디테일을 가지는 프로파일 0을 선택하여 대화형 아바타 서비스를 사용할 수 있다.
만약 동일한 개수의 포인트로 구성된 3D 오브젝트와 동일한 텍스쳐 해상도를 가지는 3D 컨텐트 들이 제공되고 있을 경우, 상기와 같이 컨텐트 종류에 따라 VR 기기 등을 이용하는 서비스 컨텐트일 경우 90fps or 120fps 등 높은 프레임 레이트의 움직임을 필요하게 되면 사용자 움직임을 좀 더 디테일(detail)하게 표현하여 자연스러운 얼굴 표정 등을 렌더링 할 수 있을 것이다. 예를 들어, 단말은 사용자 움직임을 좀 더 디테일하게 표현하여 자연스러운 얼굴 표정 등을 렌더링 할 수 있는 3D Asset 프로파일(예, 표 1에서 상대적으로 낮은 디테일 표현/얼굴 표정을 표현하는 프로파일 2번) 또는 상대적으로 높은 디테일한 표현/얼굴 표정을 표현하는 프로파일 3번)을 선택하여 아바타 데이터와 연계된 움직임에 관련된 아바타 컨텐트 프로파일 선택이 가능할 수 있다.
또한 단말은 렌더링 성능이나 단말의 해상도 및 전송 대역폭 등을 고려하여 동일한 오브젝트에 동일한 LoD를 가지면서 동일한 움직임 표현을 위한 포인트로 정의되어 있지만 이를 표현하는 텍스쳐 해상도의 값을 다르게 선택할 수 있다. 만약 대화형 서비스를 위한 양 단말의 대역폭이 충분하나, 단말의 렌더링 성능이나 해상도 등을 고려하여 단말의 성능이 고화질 3D 아바타 데이터를 지원한다면 4K 해상도를 가지는 프로파일 2번을 선택하며 이를 기반으로 3D 아바타 데이터를 교환 및 저장하여 대화형 서비스를 이용할 수 있으나, 단말의 성능이 떨어지거나 사용자의 선택 등으로 2K 텍스쳐 해상도로 구성된 3D 아바타 데이터를 요청을 선택하여 서비스를 이용할 수도 있다. 이와 같이 단말의 성능 등에 따라 동일한 대역폭 등 네트워크 환경에서도 송신 단말 및 수신 단말의 3D 아바타 관련 프로파일의 선택은 다를 수 있다.
표 1은 아바타의 컨텐트 타입이 3D Asset Face인 경우와 3D Asset Full Body인 경우의 프로파일과 움직임 표현 파라미터들을 예시한다.
Number of point for 3D object Number of feature point (If 3D object animation supported) Texture Resolution Profile
3D Asset (Face) 3000 51 2K 0
3D Asset (Face) 12000 51 2K 1
3D Asset (Face) 12000 51 4K 2
3D Asset (Face) 12000 86 4K 3
3D Asset (Full Body) 1,000,000 38 2K 0
3D Asset (Full Body) 4,000,000 294 2K 1
3D Asset (Object) ... ...
... ... ...
상기 3D 아바타 관련 움직임(animation) 표현 정보는 3D 아바타 컨텐트 생성 방식에 따라서 표 1과 같이 3D 아바타 컨텐트 특성과 그와 연계된 움직임과 같이 함께 제공되거나 3D 아바타 컨텐트와 별도로 약속된 형태로 제공이 가능하다. 3D 아바타 관련 움직임 표현 정보는 여러가지 형태 (FACS or H-ANIM(humanoid animation) etc.)로 생성이 가능하며 아래 표 2와 같이 대표적인 특성을 이용하여 표현이 가능하다.
본 개시에서 아바타 움직임 정보(이하, '움직임 정보')는 아바타 콜 서비스를 수행하는 단말이 아바타의 움직임을 렌더링 하는데 이용하는 데이터로써 예를 들어 FACS 정보(information)일 수 있다. 본 개시에서 아바타 관련 움직임 표현 정보는 상기 3D 아바타의 움직임을 표현하기 위해 미리 정의된 아바타 표현 방식에 대한 정보로써 표 2의 FACS type 일 수 있다. 단말은 상기 아바타 관련 움직임 표현 정보에 기반하여 3D 아바타 움직임 정보를 생성할 수 있고, 상기 아바타 움직임 정보를 이용하여 3D 아바타의 움직임을 렌더링 할 수 있다.
송신 단말(UE A)(630)로 SDP answer 메시지(604)를 전송하는 프로세스에서, 각 IMS 노드는 이 서비스를 위해 요구되는 유선 및/또는 무선 네트워크의 전송 리소스를 예약하기 시작할 수 있고, 송신 단말은 추가 절차를 통해 앞의 과정에서 수신 단말이 아바타 관련 움직임 표현 정보를 지원하는지 여부를 판단하여, 해당 3D 아바타 데이터를 바탕으로 구체적인 움직임 표현 정보 (e.g. 해당 3D 아바타 데이터의 애니메이션을 표현하는 특징점 정보, 해당 아바타의 애니메이션 특징점 기반 움직임 표현 방법 등)를 합의할 수 있다. 도 6에서는 단계 604의 응답 메시지 내에 특징점 기반 움직임 표현 방법을 표현하지 않고, 송신 단말은 아바타 콜을 위한 특징점 기반 움직임 표현의 지원 여부에 대한 정보(즉, FACS support indication)만 전달 받으며 수신 단말과의 별도의 합의를 통해 구체적인 움직임 표현 파라미터를 합의한다고 가정하였다. 이 경우 별도의 추가 요청 (단계 605 및 606)을 통해 각 단말이 제공하는 아바타 관련 움직임 표현 정보 및 파라미터를 협상할 수 있다.
송신 단말(630)은 604 단계에서 수신한 SDP answer 메시지 내에 움직임 표현 지원 여부에 대한 정보 (FACS support indication)을 획득할 수 있다. 수신 단말 (UE B)(632)가 3D 아바타 관련 움직임 표현 정보를 지원할 경우 송신 단말(630)은 단계 605에서, SDP 제안 (offer) 메시지를 포함하는 SIP UPDATE(갱신) 요청 내에 3D 아바타 데이터(단계 602 및 604를 통해 협상된)와 연계된 구체적인 3D 아바타 관련 움직임 (애니메이션) 표현 정보 (e.g. 표 2의 FACS type)을 수신 단말(632)로 전송할 수 있다.
상기 605 단계에서 3D 아바타 관련 움직임 표현 정보는, 송신 단말 (UE A)가 단계 602에서 송신 단말이 지원하는 3D 아바타 데이터 (e.g. 3gpp_3DAsset_Face) 관련 아바타 움직임 표현 정보 및 파라미터 (e.g. FACS type or Number of Feature point & FACS Expression type etc.) 와, 추가적으로 수신 단말이 지원하는 3D 아바타 데이터 정보를 바탕으로 송신 단말이 수신 단말에게 요청하는 수신 단말의 3D 아바타 관련 움직임 표현 정보를 포함할 수 있다. 3D 아바타 관련 움직임 표현 정보는 3D 아바타 데이터의 파라미터에 따라 해당 3D 아바타 데이터를 얼마나 미세하게 움직일 건지에 대한 관련 정보 (Number of feature point), 또는 해당 포인트들의 움직임을 어떻게 표현할 것인지에 대한 정보 (Expression type) 등으로 정의될 수 있다.
이때 3D 아바타 관련 움직임 표현 정보는 3D 아바타 데이터의 종류 등에 따라 3D 아바타 데이터를 얼마나 미세하게 움직일 건지에 대한 관련 정보 (Number of feature point) 및 해당 포인트들의 움직임을 어떻게 표현할 것인지에 대한 정보 (Expression type) 등의 정보를 바탕으로 사전의 정의된 프로파일 형태로 정의 가능하다. 3D 아바타 데이터에서 얼굴 관련 움직임 표현 정보는 사람 얼굴 관련 근육 움직임 정보 등을 바탕으로 표정을 표현하기 위한 얼굴 내 포인트 (Feature point)등을 정의 해둔 FACS (Facial action coding system)을 이용하여 표현되거나 어플리케이션이나 서비스 사업자 별로 별도의 약속된 형태로 표현될 수 있다.
또한 상기 단계 602 및 604의 전송 대역폭에 따라 3D 아바타 데이터의 표현이 달라질 수 있는데 3D 아바타 관련 움직임 표현 정보 요청 시 전송 대역폭에 따른 3D 아바타의 종류에 따라 움직임 표현 정보의 종류도 달라질 수 있다. 예를 들어, 상기 3D 아바타 관련 파라미터 협상 과정 중 고해상도의 텍스쳐를 가지는 3D 아바타의 경우 많은 특징점 (feature point)로 구성된 3D 아바타 데이터를 제공하며, 해당 아바타의 움직임을 표현하기 위해서는 많은 특징점 기반으로 움직임을 표현해주어야 자연스러운 표정 정보 등을 전달이 가능하다. 상기와 같은 경우 3D 아바타 기반으로 표현 방식 (Expression type: e.g. emotion type, feature point coefficient type etc.)은 동일하지만 해당 아바타 표정을 좀 더 detail 하게 표현하기 위해서 얼굴 움직임을 표현하기 위한 feature point의 개수가 더 많을 수 있다.
예를 들어, 표 2의 예시에서 동일한 움직임 표현 타입(Expression type) 'Intensity' 를 갖는 3D 아바타 관련 움직임 표현 정보 (FACS type)가 2 및 3인 경우에 대해 예시한다. 사용자의 preference, 단말 렌더링 성능, SDP 협상 과정에서 얻은 대역폭 정보, 상대 단말이 제공 가능한 3D 컨텐트 종류 등을 고려하여 3000개의 point로 구성된 저해상도 3D 오브젝트 컨텐트를 바탕으로 대화형 서비스를 이용하기 위해 표 2에서 3D 아바타 관련 움직임 표현 정보 (FACS type)의 값을 2로 결정한 경우, 해당 저해상도 3D 아바타 컨텐트의 얼굴 움직임 표현을 위해서는 51개의 얼굴 특징점 정보 및 해당 특징점의 변화량을 이용하여 표현할 수 있다. 그런데, 서비스 이용 도중 네트워크 환경의 변화 등으로 인하여 대역폭이 향상되어 12000개의 point로 구성된 고해상도의 3D 오브젝트 컨텐트를 바탕으로 서비스를 할 수 있을 때, 해당 고화질 3D 아바타 컨텐트의 표현을 위해 아바타 얼굴 움직임 표현 정보의 값을 3으로 변경하여 86개의 특징점 및 해당 특징점의 변화량 정보를 이용하여 표현하여야 할 수 있다. 위와 같이 상기 단계 602와 604에서 수신한 단말의 렌더링 성능 및 3D 아바타 데이터의 정보 (3D 아바타 의 texture resolution 등)을 바탕으로 단계 605 및 606에서 해당 3D 아바타의 움직임을 표현하기 위한 정보를 제공하며 해당 정보를 바탕으로 추가 협상을 진행하게 될 수도 있다.
표 2는 아바타 관련 움직임 표현 정보의 예로써 FACS type 을 예시한다.
FACS Type Number of Feature Point Expression type
0 7 Emotion (Happy, Fear ,Sad etc)
1 51 Coefficient Value (Float)
2 51 Intensity
3 86 Intensity
… … …
상기 단계 605에서 송신 단말이 지원하는 3D 아바타 관련 움직임 표현 정보를 바탕으로, 단계 606에서 수신 단말은 송신 단말이 전송하는 3D 아바타 움직임 표현 정보에 대한 수신 단말의 지원 여부를 판단할 수 있고, 수신 단말이 요청하는 3D 아바타 관련 움직임 표현 정보(예, FACS type)를 우선 순위를 정하여 리스트 형태로 전송할 수 있다. 수신 단말이 송신 단말로 전송할 수신 단말이 지원하는 3D 아바타 관련 움직임 표현 정보는 응답 메시지(예, 200 OK 메시지)를 통해 송신 단말로 전달될 수 있다.
단계 607, 단계 608, 및 단계 609에서 송신 단말/수신 단말은 3D 아바타 데이터와 관련 움직임 표현 정보의 협상을 완료한 뒤 세션 수립을 완료하게 된다.
단계 610에서는 만약 송신 단말 및 수신 단말이 상대방의 3D 아바타 데이터를 가지고 있지 않다면, 상기 단계 602 및 604에서 3D 아바타 관련 데이터 및 관련 파라미터의 우선 순위를 바탕으로, 3D 아바타 데이터를 각각 상대 단말에게 요청 및 교환할 수 있다. 3D 아바타 콜 서비스 사용자가 이미 상대의 아바타 데이터를 보유하고 있으면 3D 아바타 콜 관련 정보를 협상 후 해당 아바타 데이터를 가지고 3D 아바타 콜 서비스를 제공할 수 있을 것이다. 하지만, 3D 아바타 콜 서비스 사용자가 상대의 아바타 데이터를 가지고 있지 않을 경우, 사용자 및 사업자의 선택에 따라, 해당 3D 아바타 데이터를 먼저 수신(또는 다운로드)하는 절차를 수행할 수 있다, 또한, 3D 아바타 콜 서비스 사용자가 상대의 3D 아바타를 가지고 있지 않아서 해당 3D 아바타를 다운로드 하는 중에는, 사용자의 선택에 따라, 캐릭터 또는 카툰(cartoon) 형태의 애니메이션이 없는 아바타를 바탕으로 아바타 콜 연결을 생성하고, 상대방의 3D 아바타 데이터 수신(다운로드)을 완료하면 애니메이션 기반의 3D 아바타 콜에서 실사(actual image) 기반의 3D 아바타의 콜로 전환할 수도 있다.
단계 611에서 송신 단말(630)과 수신 단말(632) 각각은 단계 605 및 606의 과정에서 협상된 3D 아바타 관련 움직임 표현 정보를 바탕으로 움직임 정보를 생성할 수 있다. 이때 3D 아바타 관련 움직임 표현 정보는 단말의 Capability에 따라 ToF (time of flight) 카메라 또는 Structure 형태의 적외선 카메라를 바탕으로 depth 형태로 얼굴의 특징점을 추출하여 포인트를 생성할 수 있으며, 이때 상기 605 및 606에서 수신한 표 2의 expression type 기반으로, 송신 단말(630)과 수신 단말(632)는 얼굴을 표현하는 전체 포인트 중 표정 정보 등을 표현하기 위한 특징점 (feature point)의 정보 및 해당 특징점 움직임 변화량 표현 방법 (expression type) 등의 정보를 포함하여 생성하게 된다.
예를 들어, 표 2에서 type 0의 경우 약속된 표정(예, happy, fear, sad 등) 정보를 전달하여 주는데 이때 약속된 feature 포인트의 움직임을 알려주거나 또는 단순한 표정 정보 (예, 7가지 표정)으로 알려 줄 수 있다. 또는 표 2에서 type 1 or 2의 경우 사용자의 캡쳐된 얼굴 정보를 기반하여 51개의 얼굴의 특징점을 추출하여 해당 포인트의 움직임의 변화량의 값 (e.g. type 1 - Floating value or type 2 - intensity (Integer Value)) 으로 표현 가능하다.
3D 아바타 데이터와 얼굴의 움직임을 표현할 특징점 정보는 FACS type 별로 3D 아바타 데이터 생성시 약속된 형태로 단말 및 서비스 사업자의 설정에 의해 지정되어 제공될 수 있다. 3D 아바타 데이터의 생성 시 단말 및 3D 아바타 어플리케이션에 따라 특징점 정보(예, 실사와 아바타 사이에서 매핑되는 위치)는 다를 수 있으나 특징점 포인트의 개수 및 움직임 표현 방법 등은 약속된 형태로 제공되기 때문에 3D 아바타 데이터와 3D 아바타 관련 움직임 표현 정보는 연관된 형태로 제공된다. 따라서, 3D 아바타의 정보 및 3D 아바타 관련 움직임 표현 정보에서 특징점 정보는 단말에 따라 서로 생성 방식 (e.g. 이미지에서 특징점 추출하는 방식) 등은 다를 수 있으나 일정한 형태의 공통된 특징을 가지게 된다.
단계 604 및 605에서 3D 아바타 관련 움직임 표현 파라미터 협상 과정을 통해 얻은 정보를 바탕으로, 송신 단말(630)과 수신 단말(632)은 단계 612에서 아바타 움직임 정보를 전송할 수 있다. 상기 아바타 움직임 정보를 바탕으로 송신 단말(630)과 수신 단말(632)은 실시간 3D 아바타 콜을 수행할 수 있다.
이후 단계 613 및 614 과정을 통해서 송신 단말(630)과 수신 단말(632)은 해당 3D 아바타 데이터를 주고 받기 위한 RTP 세션을 종료할 수 있다.
도 7은 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템(IMS)을 사용하여 아바타 형태의 비디오 콜을 수행하기 위한 전송 방법 방법에서 송신 단말(UE A) 및 수신 단말(UE B)이 파라미터를 협상(negotiate)하고, 유선 또는 무선 전송 경로(path)의 QoS를 보장하기 위한 절차를 예시한다. 도 7에서는 아바타 데이터와 아바타 관련 움직임 정보가 별도의 경로로 전송될 수 있다. 현재 IMS 구조에서, 코덱을 이용하는 미디어 컨텐트 관련 정보는 RTP 프로토콜을 이용하여 전송되고, 추가적인 코덱을 사용하지 않지만 대화형 서비스 지원을 위한 데이터는 WebRTC 기반의 Data channel을 통해 전송될 수 있다.
단계 701에서, 사용자의 선택 또는 사전에 정의한 설정에 따라 송신 단말 (UE A)(630)은 비디오 콜 연결 시 3D 아바타를 이용한 비디오 콜을 선택할 수 있다.
단계 702에서 송신 단말(630)은, 3D 아바타 데이터는 RTP 프로토콜을 기반으로 코덱(들) 및 3D 아바타 관련 파마미터(들) 중 적어도 하나를 결정하고 SDP 메시지의 페이로드에 삽입하며, 3D 아바타 관련 움직임 정보는 WebRTC 기반의 Data channel을 이용하여 파마미터(들)을 결정하고 SDP 메시지의 페이로드에 삽입하고, 수신 단말(632)에게 전송함으로써 연결 요청을 수행할 수 있다. 상기 SDP 메시지의 페이로드 내에 삽입된 코덱(들) 또는 3D 아바타 관련 파마미터(들)은 송신 단말의 단말 성능 및 지원 가능한 세션에 대한 사용자 선호도(단계 701 과 같이 사용자의 선택 등)를 반영할 수 있다. 송신 단말(630)은 대역폭 요구사항 및 각 특성을 포함하는 SDP 메시지 (예, SDP offer)를 만들고, 각 가능한 미디어 플로우에 대한 로컬 포트 넘버를 할당할 수 있다.
단계 703에서 수신 단말(UE B)(632)은 단계 701의 송신 단말 (UE A)(630)의 동작과 같이 사용자 선호도 또는 사전에 정의한 설정에 따라 대화형 서비스 연결 수락 시 3D 아바타를 이용한 비디오 콜을 선택할 수 있다. UE B(632)는 이 세션에 대해 지원 가능한 코덱 또는 3D 아바타 관련 파라미터들의 완전한 세트를 결정할 수 있다. UE B(632)는 INVITE 메시지 내의 SDP (SDP offer) 내에서 나타나는 것들과의 교집합(intersection)을 결정할 수 있다.
단계 704에서 UE B(632)는 공통(common) 미디어 플로우 및 코덱, 3D 아바타 관련 파라미터 및 3D 아바타 움직임 지원 여부 정보 (FACS support indication) 를 리스팅하는 SDP(SDP response/answer)를 UE A(630)로 전달할 수 있다. UE A(630)는 어떤 미디어 플로우가 이 세션에 대하여 사용되어야 하는지를 결정하고, 어떤 코덱, 3D 아바타 관련 파라미터가 미디어 플로우의 각각에 대하여 사용되어야 하는지를 결정할 수 있다.
하나 이상의 미디어 플로우가 있다면, 또는 미디어 플로우에 대한 코덱, 3D 아바타 관련 파라미터의 하나 이상의 선택이 있다면, UE A(630)은 코덱, 3D 아바타 관련 파라미터 하나를 결정하기 위해 다른 offer를 UE B(632)에게 전송하여 UE B(632)와 코덱들, 3D 아바타 관련 파라미터들을 협상하거나 UE B의 응답 메시지 내 요청하는 코덱, 3D 아바타 관련 파라미터 관련 priority를 보고 결정할 수 있다.
또한 송신 단말 (UE A)는 초기 요청 메시지내의 움직임 지원 정보 (FACS support indication)을 보고 3D 아바타 관련 움직임 표현을 수신 단말 (UE B)가 지원한다면 추가 절차 (단계 705 및 단계 706)를 통해서 움직임 표현 파라미터 협상을 수행할 수 있다.
송신 단말(630)은 704 단계에서 수신한 SDP answer 메시지 내에 움직임 표현 지원 여부에 대한 정보 (FACS support indication)을 획득할 수 있다. 수신 단말 (UE B)(632)가 3D 아바타 관련 움직임 표현 정보 (e.g. FACS type)을 지원할 경우 송신 단말(630)은 단계 705에서, SDP 제안 (offer) 메시지를 포함하는 SIP UPDATE 요청 내에 3D 아바타 데이터(단계 702 및 704를 통해 협상된)와 연계된 구체적인 3D 아바타 관련 움직임 (애니메이션) 표현 정보 (예, FACS type for Bootstrap data channel)(도 9의 920, 도 10의 1050 참고)를 수신 단말로 전송할 수 있다.
상기 단계 705에서 송신 단말이 지원하는 3D 아바타 관련 움직임 표현 정보를 바탕으로, 단계 706에서 수신 단말은 송신 단말이 전송하는 3D 아바타 움직임 표현 정보에 대한 수신 단말의 지원 여부를 판단할 수 있고, 해당 수신 단말의 지원 및 제공 가능 한 3D 아바타 관련 움직임 표현 정보(예, FACS type for Bootstrap data channel)를 우선 순위를 정하여 리스트 형태로 전송할 수 있다. 수신 단말이 송신 단말로 전송할 3D 아바타 관련 움직임 표현 정보는 응답 메시지(예, 200 OK 메시지)를 통해 송신 단말로 전달될 수 있다.
단계 707, 단계 708, 및 단계 709에서 송신 단말/수신 단말은 3D 아바타 관련 데이터 정보 및 관련 움직임 표현 정보의 협상을 완료한 뒤 세션 수립을 완료하게 된다.
상기 단계들을 통하여 송신 단말과 수신 단말은 각 단말이 지원하는 3D 아바타 데이터를 주고 받기 위한 파라미터와 3D 아바타 관련 움직임 정보를 주고 받기 위한 파라미터(예, FACS type for Bootstrap data channel)를 협상하며, 협상 완료된 정보를 바탕으로 3D 아바타 관련 데이터는 RTP 기반으로 세션 수립하며 3D 아바타 관련 움직임 정보는 WebRTC 기반의 Data channel(DC)로 세션을 수립할 수 있다.
이후 단계 710에서 하나 또는 두 단말 (송신 단말 및 수신 단말)이 3D 아바타 데이터를 기 보유하지 않을 경우 사용자 선택에 따라 먼저 애니메이션 기반 3D 아바타 콜을 먼저 수립하여 서비스 할 수 있다. 단계 710과정을 통하여 각 단말이 제공하는 3D 아바타 관련 데이터를 서로 주고 받는 과정이 완료될 수 있다.
단계 704 및 705에서 얻은 3D 아바타 관련 움직임 표현 정보, 각 서비스 사용자의 얼굴 특징점 움직임 변화량 정보 등을 바탕으로, 단계 711에서 송신 단말(630)과 수신 단말(632) 각각은 3D 아바타 관련 움직임 정보를 생성할 수 있다. 이후 단계 712 과정을 통하여 상기 711 단계에서 생성된 3D 아바타 관련 움직임 정보를 WebRTC 기반의 Data channel을 통해 주고 받을 수 있다. 각 단말에서는 710 단계에서 수신한 3D 아바타 데이터 및 712단계에서 Data channel을 통해 주고 받은 3D 아바타 관련 움직임 정보를 바탕으로 해당 3D 아바타의 움직임을 표현하기 위한 특징점 변화량 정보를 반영하여 실시간 3D 아바타 콜 서비스를 수행할 수 있다.
이후 단계 713 및 714 과정을 통해서 해당 3D 아바타 데이터를 주고 받기 위한 RTP 세션이 종료될 수 있다.
도 8은 본 개시의 일 실시예에 따른 IP 멀티미디어 서브시스템(IMS)을 사용하여 아바타 형태의 비디오 콜을 수행하기 위한 전송 방법에서 송신 단말(UE A) 및 수신 단말(UE B)이 파라미터를 협상(negotiate)하고, 유선 또는 무선 전송 경로(path)의 QoS를 보장하기 위한 절차를 예시한다. 도 8에서 송신 단말 또는 수신 단말은 아바타 콜 연결 전 (3D 아바타 데이터 다운로드 과정 등으로 인한 연결 지연 시)에 사전 연결 방식 (비디오 또는 보이스 콜)을 선택 할 수 있다.
단계 801에서 송신 단말 (UE A)(630)은 사용자의 선택 또는 사전에 정의한 설정에 따라 비디오 콜 연결시 3D 아바타를 이용한 비디오 콜을 선택할 수 있다.
단계 802에서 송신 단말(630)은, 코덱(들)및 3D 아바타 관련 파마미터(들) 중 적어도 하나를 결정하고 SDP 메시지의 페이로드에 삽입하며, 3D 아바타 데이터 다운로드 등으로 인하여 3D 아바타 콜 연결의 지연 시에 사용할 기존 비디오 또는 오디오 기반 콜 연결 방식 관련 코덱 및 파라미터들 중 적어도 하나의 결정 및 삽입도 수행할 수 있다. 삽입된 코덱(들) 또는 3D 아바타 관련 파마미터(들)은 송신 단말의 단말 성능 및 이 세션을 지원 가능한 세션에 대한 사용자 선호도(단계 801 과 같이 사용자의 선택 등)를 반영할 수 있다. 송신 단말(630)은 각 가능한 미디어 플로우에 대한 로컬 포트 넘버를 할당하고, 대역폭 요구사항 및 각 특성을 포함하는 SDP 메시지 (SDP offer)를 만들어 수신 단말(UE B)(632)에게 전송할 수 있다.
단계 803에서 수신 단말(UE B)(632)은 단계 801의 송신 단말 (UE A)(630)의 동작과 같이 사용자 선호도 또는 사전에 정의한 설정에 따라 대화형 서비스 연결 수락 시 3D 아바타를 이용한 비디오 콜을 선택할 수 있다. UE B(632)는 이 세션에 대해 지원 가능한 코덱 또는 3D 아바타 관련 파라미터들의 완전한 세트를 결정할 수 있다. 또한 상기 단계 802의 송신 단말(630)과 같이, 수신 단말(632)은 서비스 제공자 또는 수신 단말의 선택에 따라 3D 아바타을 이용한 3D 아바타 콜 연결이 지연될 경우 사용할 기존 비디오 또는 오디오 기반 콜 연결 방식 관련 코덱 및 파라미터들의 결정 및 선택을 수행할 수 있다. UE B(632)는 INVITE 메시지 내의 SDP (SDP offer) 내에서 나타나는 것들과의 교집합(intersection)을 결정할 수 있다.
단계 804에서 UE B(632)는 공통(common) 미디어 플로우 및 코덱, 3D 아바타 관련 파라미터, 3D 아바타 움직임 지원 여부 정보 (FACS support indication) 를 리스팅하는 정보 중 적어도 하나를 포함하는 SDP(SDP response/answer)를 UE A(630)로 전송할 수 있다. UE A(630)는 어떤 미디어 플로우가 이 세션에 대하여 사용되어야 하는지를 결정하고, 어떤 코덱, 3D 아바타 관련 파라미터가 미디어 플로우의 각각에 대하여 사용되어야 하는지를 결정할 수 있다.
하나 이상의 미디어 플로우가 있다면, 또는 미디어 플로우에 대한 코덱/3D 아바타 관련 파라미터의 하나 이상의 선택이 있다면, UE A은 코덱, 3D 아바타 관련 파라미터 하나를 결정하기 위해 다른 offer를 UE B(632)에게 전송하여 UE B(632)와 코덱들, 3D 아바타 관련 파라미터들을 협상하거나 UE B의 응답 메시지 내 요청하는 코덱, 3D 아바타 관련 파라미터 관련 priority를 보고 결정할 수 있다.
또한 송신 단말 (UE A)는 초기 요청 메시지내의 움직임 지원 정보 (FACS support indication)을 보고 3D 아바타 관련 움직임 표현을 수신 단말 (UE B)가 지원한다면 추가 절차 (단계 805 및 단계 806)를 통해서 움직임 표현 파라미터 협상을 수행할 수 있다.
송신 단말(630)은 804 단계에서 수신한 SDP answer 메시지 내에 움직임 표현 관련 정보 지원 여부에 대한 정보 (FACS support indication)을 획득할 수 있다. 수신 단말 (UE B)(632)가 3D 아바타 관련 움직임 표현 정보 (e.g. FACS type)을 지원할 경우 송신 단말(630)은 단계 805에서, SDP 제안 (offer) 메시지를 포함하는 SIP UPDATE 요청 내에 3D 아바타 데이터(단계 802 및 804를 통해 협상된)와 연계된 구체적인 3D 아바타 관련 움직임 (애니메이션) 표현 방법 정보 (예, FACS type for Bootstrap data channel) 를 수신 단말로 전송할 수 있다.
상기 단계 805에서 송신 단말이 지원하는 3D 아바타 관련 움직임 표현 정보를 바탕으로, 단계 806에서 수신 단말은 송신 단말이 전송하는 3D 아바타 움직임 표현 정보에 대한 수신 단말의 지원 여부를 판단하여 해당 수신 단말의 지원 및 제공 가능 한 3D 아바타 관련 움직임 표현 정보(예, FACS type for Bootstrap data channel)를 우선 순위를 정하여 리스트 형태로 전송할 수 있다. 수신 단말이 송신 단말로 전송할 3D 아바타 관련 움직임 표현 정보는 응답 메시지를 통해 송신 단말로 전달될 수 있다.
단계 807, 단계 808, 및 단계 809에서 송신 단말/수신 단말은 3D 아바타 관련 데이터 정보 및 관련 움직임 표현 정보의 협상을 완료한 뒤 세션 수립을 완료하게 된다.
상기 단계를 통하여 송신 단말과 수신 단말은 각 단말이 지원하는 3D 아바타 데이터를 주고 받기 위한 파라미터와 3D 아바타 관련 움직임 정보를 주고 받기 위한 파라미터(예, FACS type for Bootstrap data channel)를 협상하며, 3D 아바타 콜 연결이 지연될 경우 초기 연결 시 사용할 보이스 또는 영상 콜 관련 파라미터 또한 협상을 완료하여 각 세션 수립을 완료할 수 있다.
이후 단계 810에서 하나 또는 두 단말 (송신 단말 및 수신 단말)이 3D 아바타 데이터를 기 보유하지 않을 경우 사용자 선택에 따라 먼저 영상 콜 연결을 수립할 수 있다.
이후 단계 811과정을 통하여 각 단말이 제공하는 3D 아바타 관련 데이터를 서로 주고 받는 과정이 완료될 수 있다.
단계 804 및 805에서 3D 아바타 관련 움직임 표현 파라미터 협상 과정을 통해 얻은 정보, 사용자의 얼굴 특징점 움직임 변화량 정보 등을 바탕으로, 단계 812에서 송신 단말(630)과 수신 단말(632) 각각은 3D 아바타 관련 움직임 정보를 생성할 수 있다. 송신 단말(630)과 수신 단말(632) 상기 812 단계에서 생성된 3D 아바타 관련 움직임 정보를 단계 813 과정을 통하여 주고 받을 수 있다. 각 단말에서는 811 단계에서 수신한 3D 아바타 데이터 및 812단계에서 주고 받은 3D 아바타 관련 움직임 정보를 바탕으로 해당 변화량 정보를 반영하여 실시간 3D 아바타 콜 서비스를 수행할 수 있다.
이후 단계 814 및 815 과정을 통해서 해당 영상 콜 관련 세션 및 해당 3D 아바타 데이터를 주고 받기 위한 RTP 세션이 종료될 수 있다.
도 9는 본 개시의 일 실시예에 따른 SDP offer의 예를 나타낸다.
도 9의 실시예에서, SDP offer는 단일 스트림 미디어 세션 설정(single stream media session configuration)의 경우에 송신 단말에 의해 전송된 SDP offer (SDP offer 메시지)일 수 있다.
도 9를 참조하면, SDP offer는 SDP offer 내 미디어 디스크립션 (예: m=lines) 내에 SDP 속성 3gpp_3DAsset_Face (a=3gpp_3DAsset_Face) (910)을 포함할 수 있다. 이하에서는, SDP 속성 3gpp_3DAsset_Face (910) 및 SDP 속성 3gpp_3DAsset_Face (910) 에 포함된 파라미터들 (3D 아바타 관련 SDP 속성 파라미터들)에 기초하여 3D 아바타 데이터(또는, 3D 아바타 얼굴 데이터)를 식별하기 위한 동작이 설명된다. 상기 SDP 속성 3gpp_3DAsset_Face 는 3DAsset_Face 와 같이 표현될 수도 있다.
<실시예 1: 3D 아바타 얼굴 데이터 스트림 식별>
SDP 속성(attribute) 3gpp_3DAsset_Face는 3D 아바타 오브젝트 중 얼굴 데이터를 지시/식별하기 위해 사용될 수 있다.
위 속성의 시맨틱(semantics)은 아래와 같을 수 있다.
3D 아바타 얼굴 데이터를 지원하는 ITT4RT(Immersive Teleconferencing and Telepresence for Remote Terminals) (송신 및 수신) 클라이언트는 3gpp_3DAsset_Face 속성을 지원할 수 있고, 다음 절차들을 지원할 수 있다:
- SDF offer를 전송하는 경우, ITT4RT-Tx (송신) 클라이언트는 SDP offer 내 비디오에 대한 미디어 디스크립션(description) 내에 3gpp_3DAsset_Face 속성을 포함 시킬 수 있다.
- SDP answer를 전송하는 경우, ITT4RT-Rx (수신) 클라이언트는 3gpp_3DAsset_Face 속성이 SDP offer 내에서 수신되었다면, SDP answer 내 비디오에 대한 미디어 디스크립션 내에 3gpp_3DAsset_Face 속성을 포함 시킬 수 있다.
- SDP 내의 3gpp_3DAsset_Face 속성의 성공적인 협상 이후에, MTSI(Multimedia Telephony Service for IMS) 클라이언트는 3D Avatar Asset Data 구성 정보 SD (Scene description) 메시지와 함께(with) HEVC 또는 AVC를 포함하는 RTP-기반 텍스쳐 이미지/비디오 스트림과 바이너리 데이터를 포함하는 RTP-기반 Geometry 정보를 교환할 수 있다.
3D 아바타 데이터 (아바타의 전신(full body; FB) 또는 반신(half body; HB) 및 3D 아바타 얼굴 데이터 (아바타 얼굴 한정) 모두를 지원하는 ITT4RT-Tx (송신) 클라이언트는 SDP offer 내에 3gpp_3DAsset, 3gpp_3DAsset_Face, 3gpp_3DAsset_FB, 3gpp_3DAsset_HB 속성들을 모두 포함할 수 있지만, ITT4RT-Rx (수신) 클라이언트는 단지 하나의 속성 (지원 또는 선택에 기초한, 3gpp_3DAsset, 3gpp_3DAsset_Face, 3gpp_3DAsset_FB, 3gpp_3DAsset_HB 속성)들 중 하나를 SDP answer에 포함시킬 수 있다. 아바타 얼굴의 데이터를 전송하기 위한 미디어 타입은 3gpp_3DAsset_Face 또는 3DAsset_Face 로 표현될 수 있다. 아바타 전신의 데이터를 전송하기 위한 미디어 타입은 3gpp_3DAsset_FB 또는 3DAsset_FB 으로 표현될 수 있다. 아바타 반신의 데이터를 전송하기 위한 미디어 타입은 3gpp_3DAsset_HB 또는 3DAsset_HB 으로 표현될 수 있다.
본 개시에서, ITT4RT는 ITT4RT 특징을 지원하는 MTSI 클라이언트이다. 본 개시에서 ITT4RT-Tx 클라이언트는 3D 아바타 (얼굴) 데이터를 송신하는 것만 가능한(only capable of sending) ITT4RT 클라이언트를 지칭할 수 있다. ITT4RT-Rx 클라이언트는 3D 아바타 (얼굴) 데이터를 수신하는 것만 가능한(only capable of receiving) ITT4RT 클라이언트를 지칭할 수 있다. MTSI 클라이언트는 MTSI를 지원하는 단말 또는 네트워크 엔티티(예: MRFP (Media Resource Function Processor)) 내의 기능일 수 있다.
<실시예 2: 3D 아바타 얼굴 데이터 SDP 속성 파라미터>
미디어-라인 레벨 파라미터는 3gpp_3DAsset_Face 속성에 의해 식별된 것과 같은 3D 아바타 얼굴 데이터를 설명하기 위한 것일 뿐만 아니라, 3D 아바타 얼굴 데이터에 대한 ITT4RT-Tx (송신) 및 ITT4RT-Rx (수신) 클라이언트 사이의 세션 설정을 지원하기 위해 정의될 수도 있다.
·3D 아바타 얼굴 데이터의 스트림 패킹 (Stream packing of 3D Avatar Facial Data)
단말 장치 성능 및 대역폭 가용성(bandwidth availability)에 의존하여, 스트림 내의 3D 아바타 얼굴 데이터의 패킹이 송신 단말 및 수신 단말 사이에 협상될 수 있다.
- Number of 3D object (Avatar Facial) points : SDP offer 내의 이 파라미터는 아바타 얼굴 데이터 관련 3D 오브젝트를 구성하고 있는 포인트의 수를 나타낸다.
- Texture Resolution : SDP offer 내의 이 파라미터는 아바타 얼굴 데이터 관련 3D 오브젝트를 구성하고 있는 텍스쳐의 해상도를 나타낸다.
- Number of Feature point in Avatar face : SDP offer 내의 이 파라미터는 아바타 얼굴 데이터의 움직임을 표현하기 위한 아바타 얼굴 내 특징점의 개수를 나타낸다.
도 10은 본 개시의 일 실시예에 따른 SDP offer의 예이다.
도 10의 실시예에서, SDP offer는 3D 아바타 얼굴 데이터를 포함하는 SDP offer (SDP offer 메시지)일 수 있다.
도 10에서는, 3D 아바타 얼굴 데이터가 텍스쳐 및 지오메트리의 2개의 종류 (예: 3gpp_3DAsset_Face_Texture, 3DAsset_Face_Geometry)로 나누어진 페이로드 타입을 지원하는 것으로 가정한다.
3D 아바타 얼굴 데이터 중 텍스쳐 관련 데이터를 3gpp_3DAsset_Face_Texture로 video 관련 미디어 디스크립션으로 정의할 때, SDP offer는 a=sendonly 에 대응하는 제1 미디어 디스크립션 (m=lines #1) (1010)및 a=recvony 에 대응하는 제2 미디어 디스크립션 (m=lines #2) (1020)를 포함할 수 있다. 제1 미디어 디스크립션은 제1 SDP 속성인 3gpp_3DAsset_Face_Texture (a=3gpp_3DAsset_Face_Texture) (1010) 및 제2 SDP 속성인 3gpp_3DAsset_Face_Texture (a=3gpp_3DAsset_Face_Texture) (1020)을 포함할 수 있다.
또한 3D 아바타 얼굴 데이터 중 지오메트리 관련 데이터를 3gpp_3DAsset_Face_Geometry로 Text 관련 미디어 디스크립션으로 별도 정의할 때, SDP offer는 a=sendonly 에 대응하는 제3 미디어 디스크립션 (m=lines #3) (1030)및 a=recvony 에 대응하는 제4 미디어 디스크립션 (m=lines #4) (1040)를 포함할 수 있다. 제3 미디어 디스크립션은 제3 SDP 속성인 3gpp_3DAsset_Face_Geometry (a=3gpp_3DAsset_Face_Geometry) (1030) 및 제4 SDP 속성인 3gpp_3DAsset_Face_Geometry (a=3gpp_3DAsset_Face_Geometry) (1040)을 포함할 수 있다.
도 10의 제5 미디어 디스크립션 (m=lines #5)(1050)은, 송신 단말이 아바타 얼굴 관련 3D 오브젝트 데이터 움직임을 정보를 별도의 DC(data channel)로 지원하는 것을 예시한다.
수신 단말이 도 8에 예시된 Offer를 수신한 경우에 SDP answer를 생성하는 방법은 다음과 같이 예시될 수 있다.
1. 3D 아바타 얼굴 데이터가 수신 단말에서 지원되지 않는 케이스 (케이스 1): 수신 단말은 통상적인(normal) SDP media negotiation 처럼 3D 아바타 데이터를 수신하지 않을 것으로 시그널링할 수 있다 (예: port 번호를 0으로 설정).
2. 3D 아바타 얼굴 데이터가 수신 단말에서 지원되고, 수신 단말의 3D 아바타 얼굴 데이터 처리 및 렌더링 성능의 특성들이 SDP offer 내의 해당 특성들과 동일한 케이스 (케이스 2): 수신 단말은 SDP Offer에서 제공된 3D 아바타 얼굴 데이터 관련 파라미터를 바탕으로 3D 아바타 얼굴 데이터 페이로드 타입(예, 텍스쳐, 지오메트리)을 선택하고, SDP answer 내에 상기 선택에 관련된 정보를 포함할 수 있다. 여기서 3D 아바타 얼굴 데이터 관련 파라미터는 3D 오브젝트 데이터 압축 방법 (e.g. PCC or Mesh etc.) 및 해당 3D 데이터를 표현하는 포인트의 개수, 텍스쳐 압축 방식 (Texture encoding method), 및 텍스쳐 해상도 (Texture Resolution) 중 적어도 하나를 포함할 수 있다. 예를 들면, 수신 단말은 SDP answer 내에 하나 또는 두 개의 3D 아바타 얼굴 데이터 페이로드 타입을 선택할 수 있다.
3. 3D 아바타 얼굴 데이터의 송신 및 수신이 지원되지만, 수신 단말의 3D 아바타 얼굴 데이터 처리 및 렌더링 성능의 특성들이 SDP offer 내의 해당 특성들과 상이한 케이스 (케이스 3): 수신 단말은 a=sendonly 및 a=recvonly로 각각 설정된 두 개의 3D 아바타 얼굴 데이터 미디어 라인(m=)으로 응답할 수 있다.
일 실시예에서, a=recvonly로 설정된 미디어 라인(3D 아바타 얼굴 데이터 미디어 라인)에 대하여, 수신 단말은 케이스 2에 예시된 것과 동일하게 SDP offer에서 제공한 3D 아바타 얼굴 데이터 관련 파라미터를 바탕으로 3D 아바타 얼굴 데이터 페이로드 타입을 선택하고, 이 선택에 관련된 정보를 SDP answer에 포함시킬 수 있다. 이 경우, SDP answer 내의 3D 아바타 얼굴 데이터 페이로드 타입은 한 개 또는 한 개 이상이 선택될 수 있다.
다른 실시예에서, a=sendonly로 설정된 미디어 라인에 대하여, 수신 단말은 수신 단말의 처리 능력 및/또는 (송신 단말의) 3D 아바타 얼굴 관련 파라미터를 고려하여 SDP answer 내에 미디어 라인(또는 SDP 속성 3gpp_3DAsset_Face)를 기술할 수 있다. 이 경우, 수신 단말에 의해 전송된 SDP answer의 a=sendonly로 설정된 미디어 라인의 교섭을 위하여, 추가적인 SDP 교환이 요구될 수 있다.
도 11은 본 개시에 따른 발신 단말의 미디어 콜 수행 방법을 예시하는 도면이다.
발신 단말은 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP offer 메시지를 착신 단말에게 전송할 수 있다(1100, 602, 702, 802). 상기 제1 SDP offer 메시지는 상기 적어도 하나의 아바타의 컨텐트 타입의 프로파일을 더 포함할 수 있는데, 상기 컨텐트 타입 및 상기 프로파일에 의해 상기 적어도 하나의 아바타의 포인트 개수, 특징점 개수, 또는 텍스처 해상도가 식별(identify)될 수 있다. 추가적으로, 상기 제1 SDP offer 메시지는 비디오 미디어 정보 또는 오디오 미디어 정보를 더 포함할 수도 있다. 선택적으로, 상기 비디오 미디어 정보 또는 상기 오디오 미디어 정보는 상기 발신 단말이, 상기 적어도 하나의 아바타 미디어(예, 3D 아바타)의 데이터를 수신하기 전까지, 콜 연결을 수립하는 데에 이용될 수 있다.
상기 발신 단말은, 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 착신 단말로부터 수신할 수 있다(1102, 604, 704, 804).
추가적으로, 상기 발신 단말은 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 제2 SDP offer 메시지를 상기 착신 단말에게 전송할 수도 있다(605, 705, 805). 상기 발신 단말은, 상기 제2 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 응답 메시지를 상기 착신 단말로부터 수신할 수도 있다(606, 706, 806). 상기 적어도 하나의 아바타의 움직임 표현 정보는 FACS 타입, 특징점의 개수, 또는 상기 특징점의 표현 타입(expression type) 중 적어도 하나를 포함할 수 있다. 상기 적어도 하나의 아바타의 움직임 표현 정보는 상기 움직임 정보가 전송될 별도의 데이터 채널을 지시할 수도 있다.
상기 발신 단말은, 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성할 수 있다(1104, 611, 711, 812).
상기 발신 단말은 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행할 수 있다(1106). 구체적으로, 상기 발신 단말은, 상기 생성된 움직임 정보를 상기 착신 단말에게 전송하고, 상기 착신 단말로부터 상기 착신 단말의 아바타 움직임 정보를 수신하고, 상기 착신 단말의 아바타 움직임 정보를 이용하여 상기 착신 단말의 아바타를 렌더링 하고, 상기 렌더링된 상기 착신 단말의 아바타를 이용함으로써 상기 착신 단말과 상기 아바타 콜 서비스를 수행할 수 있다.
도 12은 본 개시에 따른 착신 단말의 미디어 콜 수행 방법을 예시하는 도면이다.
착신 단말은 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 발신 단말의 지원 여부 정보를 포함하는 제1 SDP offer 메시지를 상기 발신 단말로부터 수신할 수 있다(1200, 602, 702, 802). 상기 제1 SDP offer 메시지는 상기 적어도 하나의 아바타의 컨텐트 타입의 프로파일을 더 포함할 수 있고, 상기 컨텐트 타입 및 상기 프로파일에 의해 상기 적어도 하나의 아바타의 포인트 개수, 특징점 개수, 또는 텍스처 해상도가 식별될 수 있다. 상기 제1 SDP offer 메시지는 비디오 미디어 정보 또는 오디오 미디어 정보를 더 포함할 수도 있다. 상기 비디오 미디어 정보 또는 상기 오디오 미디어 정보는 상기 착신 단말이 상기 적어도 하나의 아바타 미디어(예, 3D 아바타)의 데이터를 수신하기 전까지 콜 연결을 수립하는 데에 이용될 수 있다.
상기 착신 단말은, 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP response 메시지를 상기 발신 단말에게 전송할 수 있다(1202, 604, 704, 804).
추가적으로, 상기 착신 단말은 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 제2 SDP offer 메시지를 상기 발신 단말로부터 수신하고(605, 705, 805), 상기 제2 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 응답 메시지를 상기 발신 단말에게 전송할 수 있다(606, 706, 806). 상기 적어도 하나의 아바타의 움직임 표현 정보는 FACS 타입, 특징점의 개수, 또는 상기 특징점의 표현 타입(expression type) 중 적어도 하나를 포함할 수 있다. 상기 적어도 하나의 아바타의 움직임 표현 정보는 상기 움직임 정보가 전송될 데이터 채널을 지시할 수도 있다.
상기 착신 단말은, 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성할 수 있다(1204, 611, 711, 812).
상기 착신 단말은 상기 생성된 움직임 정보를 이용하여 상기 발신 단말과 아바타 콜 서비스를 수행할 수 있다(1206). 구체적으로, 상기 착신 단말은 상기 생성된 움직임 정보를 상기 발신 단말에게 전송하고, 상기 발신 단말로부터 상기 발신 단말의 아바타 움직임 정보를 수신하고, 상기 발신 단말의 아바타 움직임 정보를 이용하여 상기 발신 단말의 아바타를 렌더링 하고, 상기 렌더링된 상기 발신 단말의 아바타를 이용함으로써 상기 발신 단말과 상기 아바타 콜 서비스를 수행할 수 있다.
도 13은 본 개시에 따른 단말(UE) 장치의 구성을 예시하는 도면이다.
UE(1300)는 타 UE 또는 네트워크 엔터티 신호 송수신을 수행하는 송수신부(1305)와, 상기 UE(1300)의 모든 동작을 제어하는 제어부(1310)을 포함할 수 있다. 본 개시에서 상술된 발신 단말(630) 및 착신 단말(632)에서 수행되는 모든 방법들은 상기 제어부(1310)의 제어에 의해 수행되는 것으로 이해될 수 있다.
상기 제어부(1310) 및 상기 송수신부(1305)는 반드시 별도의 장치로 구현되어야 하는 것은 아니고, 단일 칩과 같은 형태로써 하나의 구성부로 구현될 수 있음은 물론이다.
상기 제어부(1310)는 하나의 프로세서로 상기 UE(1300) 내에서 구현될 수 있다.
도 14는 본 개시에 따른 IMS 엔터티의 장치 구성을 예시하는 도면이다.
도 14의 IMS 엔터티(1400)는 본 개시에 설명된 여러 네트워크 엔터티 P-CSCF, S-CSCF, I-CSCF 등의 장치 구성을 예시한다.
IMS 엔터티(1400)는 타 IMS 엔터티 또는 UE와 신호 송수신을 수행하는 송수신부(1405)와, 상기 IMS 엔터티(1400)의 모든 동작을 제어하는 제어부(1410)을 포함할 수 있다. 본 개시에서 IMS 엔터티에 의해 수행되는 모든 방법들은 상기 제어부(1410)의 제어에 의해 수행되는 것으로 이해될 수 있다.
상기 제어부(1410) 및 상기 송수신부(14005)는 반드시 별도의 장치로 구현되어야 하는 것은 아니고, 단일 칩과 같은 형태로써 하나의 구성부로 구현될 수 있음은 물론이다.
상기 제어부(1410)는 하나의 프로세서로 상기 IMS 엔터티(1400) 내에서 구현될 수 있다.
상기 도 1 내지 도 14가 예시하는 시스템 구성도, 프로토콜 예시도, 방법 예시도, 장치 구성도 등은 본 개시의 권리범위를 한정하기 위한 의도가 없음을 유의하여야 한다. 즉, 상기 도 1 내지 도 14에 기재된 모든 구성 또는 동작이 본 개시의 실시를 위한 필수 구성요소인 것으로 해석되어서는 안되며, 일부 구성요소 만을 포함하여도 본 개시의 본질을 해치지 않는 범위 내에서 구현될 수 있다.
본 개시의 청구항 또는 명세서에 기재된 실시예들에 따른 방법들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합의 형태로 구현될(implemented) 수 있다.
소프트웨어로 구현하는 경우, 하나 이상의 프로그램(소프트웨어 모듈)을 저장하는 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장되는 하나 이상의 프로그램은, 전자 장치(device) 내의 하나 이상의 프로세서에 의해 실행 가능하도록 구성된다(configured for execution). 하나 이상의 프로그램은, 전자 장치로 하여금 본 개시의 청구항 또는 명세서에 기재된 실시 예실시예들에 따른 방법들을 실행하게 하는 명령어(instructions)를 포함한다.
이러한 프로그램(소프트웨어 모듈, 소프트웨어)은 랜덤 액세스 메모리 (random access memory), 플래시(flash) 메모리를 포함하는 불휘발성(non-volatile) 메모리, 롬(ROM: Read Only Memory), 전기적 삭제가능 프로그램가능 롬(EEPROM: Electrically Erasable Programmable Read Only Memory), 자기 디스크 저장 장치(magnetic disc storage device), 컴팩트 디스크 롬(CD-ROM: Compact Disc-ROM), 디지털 다목적 디스크(DVDs: Digital Versatile Discs) 또는 다른 형태의 광학 저장 장치, 마그네틱 카세트(magnetic cassette)에 저장될 수 있다. 또는, 이들의 일부 또는 전부의 조합으로 구성된 메모리에 저장될 수 있다. 또한, 각각의 구성 메모리는 복수 개 포함될 수도 있다.
또한, 프로그램은 인터넷(Internet), 인트라넷(Intranet), LAN(Local Area Network), WLAN(Wide LAN), 또는 SAN(Storage Area Network)과 같은 통신 네트워크, 또는 이들의 조합으로 구성된 통신 네트워크를 통하여 접근(access)할 수 있는 부착 가능한(attachable) 저장 장치(storage device)에 저장될 수 있다. 이러한 저장 장치는 외부 포트를 통하여 본 개시의 실시예를 수행하는 장치에 접속할 수 있다. 또한, 통신 네트워크 상의 별도의 저장 장치가 본 개시의 실시예를 수행하는 장치에 접속할 수도 있다.
상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 무선 통신 네트워크에서 발신(originating) 단말의 미디어 콜 서비스를 수행하는 방법에 있어서,
    적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 착신(terminating) 단말에게 전송하는 동작;
    상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 착신 단말로부터 수신하는 동작;
    상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하는 동작; 및
    상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하는 동작을 포함하는 방법.
  2. 제1항에 있어서,
    상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 제2 SDP offer 메시지를 상기 착신 단말에게 전송하는 동작; 및
    상기 제2 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 응답 메시지를 상기 착신 단말로부터 수신하는 동작을 더 포함하는 방법.
  3. 제1항에 있어서, 상기 제1 SDP offer 메시지는 상기 적어도 하나의 아바타의 컨텐트 타입의 프로파일을 더 포함하되,
    상기 컨텐트 타입 및 상기 프로파일에 의해 상기 적어도 하나의 아바타의 포인트 개수, 특징점 개수, 또는 텍스처 해상도가 식별됨을 특징으로 하는 방법.
  4. 제2항에 있어서, 상기 적어도 하나의 아바타의 움직임 표현 정보는 FACS(facial action coding system) 타입, 특징점의 개수, 또는 상기 특징점의 표현 타입(expression type) 중 적어도 하나를 포함함을 특징으로 하는 방법.
  5. 제1항에 있어서, 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하는 동작은:
    상기 생성된 움직임 정보를 상기 착신 단말에게 전송하는 동작;
    상기 착신 단말로부터 상기 착신 단말의 아바타 움직임 정보를 수신하는 동작;
    상기 착신 단말의 아바타 움직임 정보를 이용하여 상기 착신 단말의 아바타를 렌더링 하는 동작; 및
    상기 렌더링된 상기 착신 단말의 아바타를 이용하여 상기 착신 단말과 상기 아바타 콜 서비스를 수행하는 동작을 포함하는 방법.
  6. 제2항에 있어서, 상기 적어도 하나의 아바타의 움직임 표현 정보는 상기 움직임 정보가 전송될 데이터 채널을 지시함을 특징으로 하는 방법.
  7. 제1항에 있어서, 상기 제1 SDP offer 메시지는 비디오 미디어 정보 또는 오디오 미디어 정보를 더 포함하며,
    상기 적어도 하나의 아바타의 데이터를 수신하기 전까지 상기 비디오 미디어 정보 또는 상기 오디오 미디어 정보를 이용하여 콜 연결을 수립하는 동작을 더 포함함을 특징으로 하는 방법.
  8. 무선 통신 네트워크에서 착신(terminating) 단말의 미디어 콜 서비스를 수행하는 방법에 있어서,
    적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 발신(originating) 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 상기 발신 단말로부터 수신하는 동작;
    상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 발신 단말에게 전송하는 동작;
    상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하는 동작; 및
    상기 생성된 움직임 정보를 이용하여 상기 발신 단말과 아바타 콜 서비스를 수행하는 동작을 포함하는 방법.
  9. 제8항에 있어서,
    상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 제2 SDP offer 메시지를 상기 발신 단말로부터 수신하는 동작; 및
    상기 제2 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임 표현 정보를 포함하는 응답 메시지를 상기 발신 단말에게 전송하는 동작을 더 포함하는 방법.
  10. 제8항에 있어서, 상기 제1 SDP offer 메시지는 상기 적어도 하나의 아바타의 컨텐트 타입의 프로파일을 더 포함하되,
    상기 컨텐트 타입 및 상기 프로파일에 의해 상기 적어도 하나의 아바타의 포인트 개수, 특징점 개수, 또는 텍스처 해상도가 식별됨을 특징으로 하는 방법.
  11. 제9항에 있어서, 상기 적어도 하나의 아바타의 움직임 표현 정보는 FACS(facial action coding system) 타입, 특징점의 개수, 또는 상기 특징점의 표현 타입(expression type) 중 적어도 하나를 포함함을 특징으로 하는 방법.
  12. 제8항에 있어서, 상기 생성된 움직임 정보를 이용하여 상기 발신 단말과 아바타 콜 서비스를 수행하는 동작은:
    상기 생성된 움직임 정보를 상기 발신 단말에게 전송하는 동작;
    상기 발신 단말로부터 상기 발신 단말의 아바타 움직임 정보를 수신하는 동작;
    상기 발신 단말의 아바타 움직임 정보를 이용하여 상기 발신 단말의 아바타를 렌더링 하는 동작; 및
    상기 렌더링된 상기 발신 단말의 아바타를 이용하여 상기 발신 단말과 상기 아바타 콜 서비스를 수행하는 동작을 포함하는 방법.
  13. 제9항에 있어서, 상기 적어도 하나의 아바타의 움직임 표현 정보는 상기 움직임 정보가 전송될 데이터 채널을 지시함을 특징으로 하는 방법.
  14. 제8항에 있어서, 상기 제1 SDP offer 메시지는 비디오 미디어 정보 또는 오디오 미디어 정보를 더 포함하며,
    상기 적어도 하나의 아바타의 데이터를 수신하기 전까지 상기 비디오 미디어 정보 또는 상기 오디오 미디어 정보를 이용하여 콜 연결을 수립하는 동작을 더 포함함을 특징으로 하는 방법.
  15. 무선 통신 네트워크에서 미디어 콜 서비스를 수행하는 발신(originating) 단말에 있어서,
    송수신부; 및
    상기 송수신부를 제어하여, 적어도 하나의 아바타의 컨텐트 타입을 지시하는 정보 및 상기 적어도 하나의 아바타의 움직임에 관한 상기 발신 단말의 지원 여부 정보를 포함하는 제1 SDP(session description protocol) 제안(offer) 메시지를 착신(terminating) 단말에게 전송하고, 상기 제1 SDP offer 메시지에 대한 응답으로써, 상기 적어도 하나의 아바타의 움직임에 관한 상기 착신 단말의 지원 여부 정보를 포함하는 SDP 응답(response) 메시지를 상기 착신 단말로부터 수신하고, 상기 SDP response 메시지에 포함된 상기 착신 단말의 지원 여부 정보에 기반하여, 상기 적어도 하나의 아바타의 움직임 정보를 생성하고, 상기 생성된 움직임 정보를 이용하여 상기 착신 단말과 아바타 콜 서비스를 수행하도록 구성되는 프로세서를 포함하는 단말.
PCT/KR2023/016253 2022-11-03 2023-10-19 미디어 콜 서비스를 수행하기 위한 방법 및 장치 WO2024096390A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0145308 2022-11-03
KR1020220145308A KR20240065355A (ko) 2022-11-03 2022-11-03 미디어 콜 서비스를 수행하기 위한 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2024096390A1 true WO2024096390A1 (ko) 2024-05-10

Family

ID=90930924

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/016253 WO2024096390A1 (ko) 2022-11-03 2023-10-19 미디어 콜 서비스를 수행하기 위한 방법 및 장치

Country Status (2)

Country Link
KR (1) KR20240065355A (ko)
WO (1) WO2024096390A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110020131A (ko) * 2009-08-21 2011-03-02 에스케이텔레콤 주식회사 영상통화 중 상대방의 표정 인식을 통한 감정 전달 시스템 및 방법
KR20190101835A (ko) * 2018-02-23 2019-09-02 삼성전자주식회사 얼굴에 대응하는 3차원 아바타를 이용하여 얼굴의 움직임이 반영된 3차원 아바타를 포함하는 이미지를 생성하는 전자 장치 및 그 동작 방법
KR20200081062A (ko) * 2018-12-27 2020-07-07 주식회사 케이티 아바타를 이용한 통화 연결 영상을 제공하는 단말, 서버 및 방법
KR20210127054A (ko) * 2020-04-10 2021-10-21 삼성전자주식회사 증강 현실에서 커뮤니케이션을 위한 전자 장치 및 그에 관한 방법
KR20210149674A (ko) * 2019-03-13 2021-12-09 주식회사 케이티 아바타를 이용하여 영상 통화를 수행하는 사용자 단말, 통화 중계 서버 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110020131A (ko) * 2009-08-21 2011-03-02 에스케이텔레콤 주식회사 영상통화 중 상대방의 표정 인식을 통한 감정 전달 시스템 및 방법
KR20190101835A (ko) * 2018-02-23 2019-09-02 삼성전자주식회사 얼굴에 대응하는 3차원 아바타를 이용하여 얼굴의 움직임이 반영된 3차원 아바타를 포함하는 이미지를 생성하는 전자 장치 및 그 동작 방법
KR20200081062A (ko) * 2018-12-27 2020-07-07 주식회사 케이티 아바타를 이용한 통화 연결 영상을 제공하는 단말, 서버 및 방법
KR20210149674A (ko) * 2019-03-13 2021-12-09 주식회사 케이티 아바타를 이용하여 영상 통화를 수행하는 사용자 단말, 통화 중계 서버 및 방법
KR20210127054A (ko) * 2020-04-10 2021-10-21 삼성전자주식회사 증강 현실에서 커뮤니케이션을 위한 전자 장치 및 그에 관한 방법

Also Published As

Publication number Publication date
KR20240065355A (ko) 2024-05-14

Similar Documents

Publication Publication Date Title
EP3202137B1 (en) Interactive video conferencing
US11711550B2 (en) Method and apparatus for supporting teleconferencing and telepresence containing multiple 360 degree videos
US8614732B2 (en) System and method for performing distributed multipoint video conferencing
JP6940587B2 (ja) マルチメディア通信におけるコンパクト並列コーデックの使用のための方法および装置
KR102115922B1 (ko) 영상 통신 방법 및 그 영상 통신 시스템
US11290512B2 (en) Codec selection for end-to-end communication without intermediate transcoding
CN102611871A (zh) 视频通话的方法、系统、移动终端及数字电视接收终端
US20180013812A1 (en) Method, system and apparatus for the transmission and adaption of data
WO2017003768A1 (en) Methods and apparatus for codec negotiation in decentralized multimedia conferences
CN103414867B (zh) 多媒体通话控制方法、终端及系统
WO2024096390A1 (ko) 미디어 콜 서비스를 수행하기 위한 방법 및 장치
US11805156B2 (en) Method and apparatus for processing immersive media
EP4338407A1 (en) Methods and apparatus for application service relocation for multimedia edge services
CN111654909B (zh) 一种通信方法及系统
WO2024080840A1 (en) Method and apparatus for providing ai/ml media services
WO2024096562A1 (ko) 이동 통신 시스템에서 데이터 채널 응용 제공 방법 및 장치
WO2024035010A1 (en) Method and apparatus of ai model descriptions for media services
WO2024101720A1 (en) Method and apparatus of qoe reporting for xr media services
WO2023003354A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2023014085A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2023101510A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
US20240236268A1 (en) Video connection continuity between devices
KA et al. Dynamic association and participant based adaptive streaming in small base station for live video conference on 5G networks.
CN117411991A (zh) 基于无流量网络的视频通话方法
JP6119220B2 (ja) メディア通信装置及びメディア通信システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23886087

Country of ref document: EP

Kind code of ref document: A1